GNOME Bugzilla – Bug 498333
GDM does not respond to keyboard input on FreeBSD
Last modified: 2017-09-05 20:04:15 UTC
Please describe the problem: I could have sworn this was working in gdm-2.21.1, but I just downgraded, and I can reproduce the problem still. Basically, when gdm starts (testing with 2.21.2), everything looks okay, but the password field no longer responds to keyboard inputs. In fact, nothing keyboard related on the console works anymore once GDM starts up. The problem seems to stem from the fact that gdm is trying to open the wrong terminal device. It opens /dev/ptyp0 instead of /dev/ttyv8. The way this used to work in gdm-2.20 and earlier was the "vtX" argument would be passed to Xorg. I see that GDM still has support for "vtX" but I'm not sure how to pass this argument correctly to GDM given the new config layout. It would be nice if GDM brought back some of the code that could detect the correct VT number, but if not, being able to specify this in the config would be sufficient. Steps to reproduce: 1. Start GDM on FreeBSD at boot-time 2. Try to do anything keyboard-related 3. Actual results: The keyboard does not respond. Expected results: All keyboard input should be processed much like things used to work in gdm-2.20. Does this happen every time? Yes. Other information: If GDM is started from a console VTY after the OS is fully booted, then it works just fine. It has something to do with the way gdm is started using the RC subsystem.
I believe in GDM 2.21, the idea is that GDM automagically figures out your console device, and does this via ConsoleKit. ConsoleKit has some special logic where it tries to use HAL to figure out displays you have attached to the system, and it also tries to manage VT displays. Is the console-kit-daemon running on your machine? If not, this perhaps could be the problem. If you have console-kit-daemon running, then your problem may be that your device isn't properly recognized by ConsoleKit, or it doesn't know how to properly talk to VT on your system. Or perhaps your device doesn't work with the HAL interfaces that ConsoleKit uses to identify installed monitors (I suspect they might not work well with USB monitors). You'll need to investigate. Or perhaps it is some other bug. Perhaps you could attach the gdm related debug output you see in your system log (/var/log/messages) and this could help us to analyze the situation? You might also try running console-kit-daemon with the "--debug" argument (instead of however you run it currently) and see if there is any useful debugging output there. The old GDM allowed you to specify the command to start the Xserver in a per-display fashion via the [servers] and [server-foo] sections. This is no longer supported. If it turns out that your setup is one which really needs this sort of ability to specify the X-command without ConsoleKit automagic, then we'll need to figure out how to get this working again. Not sure if it makes the most sense to make this work better in ConsoleKit or in GDM directly. Probably in ConsoleKit, if possible.
I do have ConsoleKit running (0.2.3), and I did the porting of CK to FreeBSD. It works in that it does provide the TTY on which X is running, but only after X starts up (this seems to be the same way CK works on Linux). The X server is not started with a vtX argument which means it's left to the server to figure out which VTY to bind to. Therefore, I was asking if this functionality could be restored to accommodate such systems. Note: CK 0.2.3 does not appear to use HAL at all. I can post the debugging output from CK, but from what I've seen in the GDM output, CK is only invoked after X is started. Since X is not properly bound to a VTY, any output from CK will be incorrect. Stated a different way, GDM appears to be working. It's just not starting X in a way that X will work on FreeBSD. FreeBSD needs to vtX hint to figure out which VTY line to start on.
Hi Joe, You are correct that this doesn't really involve ConsoleKit at all. The idea with not using the vt arguement to xorg was so that we wouldn't have as much of a race for the VT device and since we can't guarantee that we get that VT even though we request it. It also allows us to avoid some messy vt allocation accounting that we have a really hard time keeping in sync with reality / the kernel. Can you help me understand why FreeBSD needs the hint to figure out which VTY to start on?
I haven't really figured out exactly why it wants to grab a PTY when starting from rc.d. I've even tried starting GDM last, and this still fails. The only thing that works is to start GDM outside of rc.d (which sort of defeats the purpose of a nice graphical console at boot time). The problem most likely stems from the fact that the rc.d subsystem is started before the syscons infrastructure initializes (i.e. before the VTYs are actually created). What would be nice, is if there was a command line argument to gdm that would allow one to specify additional arguments to the X server if needed. This would allow our users to start GDM from both rc.d as well as the proper way without the Xorg hint.
Okay, I've tracked down the cause for this. Xorg's VT probing code is working just fine. The problem is that FreeBSD's init runs the rc scripts before it spawns the gettys on the various TTYs. The result is that Xorg thinks ttyv1 (i.e. VT 2) is free. When init then spawns a getty on that TTY, all hell breaks loose. This is why the "first free VT" hint in GDM <= 2.20 was so important. This hint tells Xorg where to start looking for free VTs (not necessarily the explicit VT to bind to).
I have fixed this locally in our GDM with the attached patchset. I know it needs work, but I'm hoping it will server as a foundation to get an official fix committed upstream. Basically, it allows one to re-add the vt hint using a configuration directive.
Created attachment 102648 [details] [review] Add back the vt hint as a configuration directive
This bug is also relevant on Gentoo, since openrc (our init system) does something similar. CCing gnome@gentoo.org for tracking purposes
to be more precise this is not limited to freebsd platform on gentoo it hits linux as well.
@marcus: Is there an updated patch for 2.26? I can't find this in the FreeBSD ports CVS.
Alright, our downstream bug[1] has the updated patch now. Thanks to Tiziano Müller. 1. http://bugs.gentoo.org/show_bug.cgi?id=261339
We had some trouble with this patch and user switching. It forces all Xorg instances to the same VT, which does not work on some (all?) cards. Please see http://bugs.gentoo.org/show_bug.cgi?id=312017#c9 for another solution.
Presumably this is no longer an issue?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!