Bug #3344
closed
startx dies with ctrl-c
0%
Description
System effected:
DragonFly master 6.5 git dd711 (but seems that Jan and Feb 2023 as well)
Description:
Start the graphical user interface with 'startx'. Hit 'ctrl-c' and Xorg dies. You will even see the ctrl-c keystroke as '^C' on the console. Tested with a brand new test user, and WMs 'mate', 'xfce4', 'cinnamon'. All behave the same way.
Also, strings that were typed in the graphical user interface into a text editor, or any other window, are all replicated in the console. It seems as if startx is getting straight all the keystrokes. So no wonder it dies when the user hits 'ctrl-c'.
It might be related to earlier error reports (https://bugs.dragonflybsd.org/issues/3339) which I closed since I believed they are just symptoms of this issue.
Note 1: note that 'startx' or 'xinit' in the xinit package have not been changed since 2021, so it does not seem likely that they are the culprits.
Note 2: DragonFly bumped C standard to gnu11, c11 in git commit 6a8dae24. However, testing with world + kernel build with gnu99, c99 gives the same startx behavior, so bumping the C standard is not the cause of the problem.
Updated by peeter about 1 year ago
Experimenting with dragonfly 6.3 ea40b (23 AUG 2022) + 6.5 pkgs also has the issue. Whereas if I remember correctly, dragonfly 6.3 + 6.3 packages did not have the problem.
I conclude that the problem originates in Xorg and/or evdev/libinput rather than startx or DragonFly base system.
I run RX 550 which works with 'kldload amdgpu' + 'pkg install devfw-amdgpu'. The 'kldload amdgpu' cannot be done in /etc/rc.conf, that will panic kernel. When loading manually, all is fine.
However, one cannot switch back to ttyv0 when in Xorg. Also, leaving window manager leaves one with a blank screen. The machine is responsive and fine though.
Ideally, switching back to ttyvX should work.
Neither xdm nor slim work in any way (tried both setting xdm and slim in /etc/ttys, and slim via /etc/rc.conf, none work).
Updated by peeter about 1 year ago
This issue is resolved in
The probable reason was that switching from and to VT was not executed properly.
The commit will trickle to DPorts and packages in a couple of days.