Today I found that alt+tab was switching to a text tty from the GNOME desktop. And so did alt+f4, the super key, alt+down,... And a reboot fixed it. Here's a way to reproduce it 100%. ---------- 1. boot the system 2. launch a few applications 3. check that alt+tab, alt+f4, alt+down (the latter in xchat-gnome to switch channels) all work as expected 4. open the « Region & Language » panel in g-c-c Note: I only have one input source: « French (alternative) » 5. add the « English (US) » input source, and remove the « French (alternative) » one 6. copy the settings in the « System » tab 7. press alt+f4: you get sent to tty 4 8. come back to the graphical desktop 9. check that alt+tab, alt+down still work as expected 10. add the « French (alternative) » input source and remove the « English (US) » one 11. copy the settings in the « System » tab 12. press alt+f4: you get sent to tty 4 13. come back to the graphical desktop and try alt+tab: you get sent to tty 4 14. come back to the graphical desktop and try alt+down: you get sent to tty 4 15. reboot, and start again at 1. ---------- mclasen on IRC suggested to to report on this component as a starting point.
Created attachment 615495 [details] « xmodmap -pke » before step 5 hadess suggested I run « xmodmap -pke » before step 5 and after step 6. This is before step 5.
Created attachment 615496 [details] And here's the same command after step 6.
Hey, so I can't reproduce here on F17. On a different machine with F18 I could but then there was an update to the X server packages and I couldn't reproduce any longer. Can you confirm that?
I can still reproduce this with xorg-x11-server-Xorg-1.13.0-5.fc18.x86_64 That appears to be the latest available in the repositories here. I've also just updated everything and rebooted to be sure, before reproducing the bug.
Nominating as beta blocker
Discussed at 2012-10-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-03/f18-beta-blocker-review-2.2012-10-03-16.00.log.txt . We agreed this looks like a funky bug but we don't see any obvious grounds for taking it as a release blocker, it doesn't appear to hit any of the criteria and we don't see a reason it can't be fixed acceptably with a post-release update if it comes to that. Rejected as a Beta blocker. We note this might also have something to do with https://bugzilla.redhat.com/show_bug.cgi?id=858591 , just on general principles, that bug is highly suspicious in _absolutely any_ F18 Beta bug to do with locales at present.
(In reply to comment #6) > We note this might also have something to do with > https://bugzilla.redhat.com/show_bug.cgi?id=858591 , just on general > principles, that bug is highly suspicious in _absolutely any_ F18 Beta bug > to do with locales at present. I didn't install F18 with Anaconda, I upgraded from Fedora 17 (F18 wasn't even branched at the time). So it doesn't seem to be related to bug 858591
Created attachment 628161 [details] Reproducer Ok, I can now reproduce this reliably and have reduced it to this reproducer program which is basically a very stripped down version of systemd's vconsole-setup.c . This is what triggers the bug: ioctl(fd, KDSKBMODE, K_UNICODE) so I _think_ this is a kernel bug. Note that the reproducer has to be run while the X server VT is the currently active one.
Yes, it does appear to be a kernel issue. We need to be able to load a key console keymap in the bg if X is up, and that shouldn't affect X.
(In reply to comment #9) > Yes, it does appear to be a kernel issue. Ok, so this should be re-assigned to the kernel. I don't have the permission to do it though. > We need to be able to load a key > console keymap in the bg if X is up, and that shouldn't affect X. I don't think X is being affected. From the behavior, it seems that from the moment you call that ioctl, the kernel starts to handle key events itself and *also* passes them along to X. You can tell that because when pressing Alt+F4 in X you get taken to VT 4 and if you then come back to the X's VT you'll see that the focused window is now closed so Alt+F4 was also processed by X.
re-assigning to kernel, updating summary to hopefully be clearer: kernel guys, focus on comment #8 onwards.
(In reply to comment #8) > Created attachment 628161 [details] > Reproducer > > Ok, I can now reproduce this reliably and have reduced it to this reproducer > program which is basically a very stripped down version of systemd's > vconsole-setup.c . > > This is what triggers the bug: > > ioctl(fd, KDSKBMODE, K_UNICODE) > > so I _think_ this is a kernel bug. > > Note that the reproducer has to be run while the X server VT is the > currently active one. I ran this on my F18 machine (under sudo) and nothing happened. I did this from a gnome-terminal shell. I also tried from just a normal VT with similar lack of results. Strace showed /dev/tty0 being opened fine and the ioctl call returning 0. Are you still seeing this with kernel-3.6.6?
(In reply to comment #12) > I ran this on my F18 machine (under sudo) and nothing happened. I did this > from a gnome-terminal shell. I also tried from just a normal VT with > similar lack of results. Strace showed /dev/tty0 being opened fine and the > ioctl call returning 0. > > Are you still seeing this with kernel-3.6.6? Yes I am. Nothing happens when running it. What happens is that after running this, if you press Alt+F2, for instance, you'll be taken to VT2 which shouldn't happen. If you then go back to VT1 you'll also notice that gnome-shell's run dialog is up (because Alt+F2 gets processes by the shell as well).
(In reply to comment #13) > (In reply to comment #12) > > I ran this on my F18 machine (under sudo) and nothing happened. I did this > > from a gnome-terminal shell. I also tried from just a normal VT with > > similar lack of results. Strace showed /dev/tty0 being opened fine and the > > ioctl call returning 0. > > > > Are you still seeing this with kernel-3.6.6? > > Yes I am. Nothing happens when running it. What happens is that after > running this, if you press Alt+F2, for instance, you'll be taken to VT2 > which shouldn't happen. If you then go back to VT1 you'll also notice that > gnome-shell's run dialog is up (because Alt+F2 gets processes by the shell > as well). Ah, OK. I can see this on at least one machine. Some more questions: Do you know if this happens on F17 with the 3.6.6 kernels? Does it happen with 3.5? I have a feeling I'll be doing some git bisecting, so knowing when the last "good" kernel was will help.
Answering my own questions a bit, I can recreate it on f18 userspace with both the 3.5 and 3.4 kernels. I don't think this is a new kernel bug, but it would be interesting to see if something changed in userspace to bring it to the surface. I don't have an F17 userspace handy, but it would be good to know if this happens with these kernels and F17 or F16 userspace.
Also recreates with kernel 3.3 and 3.2. I found a 64-bit F17 KVM guest (running a 3.5 kernel) I had laying around, and running the test app from comment #8 results in the same behavior there.
I should point out that I've been running the test app under sudo privs the entire time. The vt ioctl checking checks for 2 things. 1) Is the caller the owner of the tty or 2) do they have CAP_SYS_TTY_CONFIG clearly root is going to have CAP_SYS_TTY_CONFIG, so it's going to let me change things out from under X. Basically, I think my tests have been fairly invalid. But at least they're all consistent. I'm not sure why g-c-c (or systemd-localed) would be calling the ioctl with root privs at this point. If it wasn't, the ioctl call would return -EPERM.
(In reply to comment #17) > I'm not sure why g-c-c (or systemd-localed) would be calling the ioctl with > root privs at this point. Doesn't systemd-localed run as root? (In reply to comment #15) > I don't have an F17 userspace handy, but it would be good to know if this > happens with these kernels and F17 or F16 userspace. Reproduced (with Rui's code from comment 8) on F16: $ uname -a Linux herebefrogs 3.6.2-1.fc16.x86_64 #1 SMP Wed Oct 17 05:30:01 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
(In reply to comment #18) > (In reply to comment #15) > > I don't have an F17 userspace handy, but it would be good to know if this > > happens with these kernels and F17 or F16 userspace. > > Reproduced (with Rui's code from comment 8) on F16: > > $ uname -a > Linux herebefrogs 3.6.2-1.fc16.x86_64 #1 SMP Wed Oct 17 05:30:01 UTC 2012 > x86_64 x86_64 x86_64 GNU/Linux And I can also reproduce it with: $ uname -a Linux herebefrogs 3.6.6-1.fc16.x86_64 #1 SMP Mon Nov 5 16:56:43 UTC 2012 x86_64
(In reply to comment #18) > (In reply to comment #17) > > I'm not sure why g-c-c (or systemd-localed) would be calling the ioctl with > > root privs at this point. > > Doesn't systemd-localed run as root? Apparently. > (In reply to comment #15) > > I don't have an F17 userspace handy, but it would be good to know if this > > happens with these kernels and F17 or F16 userspace. > > Reproduced (with Rui's code from comment 8) on F16: > > $ uname -a > Linux herebefrogs 3.6.2-1.fc16.x86_64 #1 SMP Wed Oct 17 05:30:01 UTC 2012 > x86_64 x86_64 x86_64 GNU/Linux Yeah, that's not as interesting. It will reproduce on all supported releases and kernels if you run it as root. Adam Jackson and I are working on a possible solution (well, mostly Adam). He can explain the details better than I, but I imagine he's busy actually working on it among other things.
I've sent patches for this to the relevant lists: https://lkml.org/lkml/2012/11/16/481 http://lists.freedesktop.org/archives/xorg-devel/2012-November/034459.html I don't expect they'll be controversial, so we'll get those built for Fedora until they're merged upstream.
(In reply to comment #21) > I've sent patches for this to the relevant lists: > > https://lkml.org/lkml/2012/11/16/481 > http://lists.freedesktop.org/archives/xorg-devel/2012-November/034459.html > > I don't expect they'll be controversial, so we'll get those built for Fedora > until they're merged upstream. I've updated the F18 and rawhide kernels to include (a slightly fixed version of) the kernel patch. This works on my local machine with an Xorg that also has the patch. I believe we just need that into the F18/rawhide xorg-x11-server package and we're set.
(from lkml) I'm confused why g-c-c is trying to set the virtual console keyboard mode, as it is completely the wrong thing to do. X never wants its virtual console set to K_UNICODE, which is the same as K_XLATE, but in unicode. Doing so causes the kernel to buffer lines and handle things like CTRL-C and ALT-Fn. As this is a per-virtual console setting, setting it on the current VT where X is running has no effect on other virtual consoles. Modern X uses the input event subsystem directly and has no need for the virtual console to be involved with input. Ancient X required that the virtual console be in K_RAW.
Correction: As this is a per-virtual *terminal* setting, setting it on the current VT where X is running has no affect on other virtual *terminals*. Virtual termainl vs virtual console can be confusing. While the keyboard mode is a virtual console setting, it is stored per virtual terminal. When switching the virtual console between virtual terminals the per-terminal console settings are saved and restored for each. The additional thought occurrs, what happens when using VC_MUTE with xf86-input-kbd as the keyboard driver for Xorg?
The bits that lead to this are: 1. http://git.gnome.org/browse/gnome-control-center/tree/panels/region/gnome-region-panel-system.c#n440 - g-c-c calls this dbus interface to set the X layout; 2. http://cgit.freedesktop.org/systemd/systemd/tree/src/locale/localed.c#n1195 - handler code for said interface; 3. http://cgit.freedesktop.org/systemd/systemd/tree/src/vconsole/vconsole-setup.c#n71 - and we eventually end up calling this ioctl here. Now, we do have the option of passing FALSE to the convert parameter on that dbus interface which wouldn't call into vconcole-setup. I can see that it makes some sense to try to set the VT keymap when the user exports the configuration to the "system" which is why that parameter is TRUE.
Is systemd updating the keymap for all virtual terminals? If not, there is no point updating the virtual console keymap for a virtual terminal which X is running on as either X doesn't use the virtual console for input at all or it uses K_RAW, and will trip if the mode is set to K_XLATE/K_UNICODE under it. (Also, I don't know for sure, does K_RAW use a keymap?) If so, is that such a wise idea? If I have interpretted this correctly that would mean that if one user logs into a graphical session with a different from default keymap, all the virtual terminals will have their virtual console keymaps changed too. About using K_RAW as input, people should probably not be using xf86-input-kbd anymore anyway.
(In reply to comment #26) > Is systemd updating the keymap for all virtual terminals? > No. It applies keyboard part to /dev/tty0 only which in this case translates to currently active VT. vconsole.c initially was created to apply default settings on system startup. It has some code now to push font to all active VTs, but keyboard settings are still applied to tty0 only. > If not, there is no point updating the virtual console keymap for a virtual > terminal which X is running on as either X doesn't use the virtual console > for input at all or it uses K_RAW, and will trip if the mode is set to > K_XLATE/K_UNICODE under it. (Also, I don't know for sure, does K_RAW use a > keymap?) > This sounds more like vconsole is being misused here.
We're still carrying a kernel patch for this. It would be good to either get it upstream, or solved in another manner. Adam?
It would appear the issue has been resolved by systemd not switching the console mode if it is in raw or off mode. This means the kernel patch is not currently needed. http://cgit.freedesktop.org/systemd/systemd/tree/src/vconsole/vconsole-setup.c#n70
OK. That code is in all of the systemd versions found in supported Fedora releases. I'm dropping the patch.
kernel-3.11.3-201.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/kernel-3.11.3-201.fc19
kernel-3.11.3-301.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.11.3-301.fc20
Package kernel-3.11.3-301.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.11.3-301.fc20' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-18268/kernel-3.11.3-301.fc20 then log in and leave karma (feedback).
kernel-3.10.14-100.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/kernel-3.10.14-100.fc18
kernel-3.11.3-201.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
Package kernel-3.10.14-100.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.10.14-100.fc18' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-18364/kernel-3.10.14-100.fc18 then log in and leave karma (feedback).
kernel-3.11.3-301.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
kernel-3.10.14-100.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.