Bug 859485 - G-C-C's « Region & Language » panel causes weird keyboard behavior by calling ioctl(fd, KDSKBMODE, K_UNICODE)
G-C-C's « Region & Language » panel causes weird keyboard behavior by calling...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
18
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
RejectedBlocker
: Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-21 12:18 EDT by Mathieu Bridon
Modified: 2013-10-09 20:55 EDT (History)
16 users (show)

See Also:
Fixed In Version: kernel-3.10.14-100.fc18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-09 10:14:32 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
« xmodmap -pke » before step 5 (11.23 KB, text/plain)
2012-09-21 12:19 EDT, Mathieu Bridon
no flags Details
And here's the same command after step 6. (9.60 KB, text/plain)
2012-09-21 12:20 EDT, Mathieu Bridon
no flags Details
Reproducer (2.45 KB, text/plain)
2012-10-16 09:36 EDT, Rui Matos
no flags Details

  None (edit)
Description Mathieu Bridon 2012-09-21 12:18:20 EDT
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.
Comment 1 Mathieu Bridon 2012-09-21 12:19:54 EDT
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.
Comment 2 Mathieu Bridon 2012-09-21 12:20:37 EDT
Created attachment 615496 [details]
And here's the same command after step 6.
Comment 3 Rui Matos 2012-09-25 18:02:25 EDT
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?
Comment 4 Mathieu Bridon 2012-09-26 19:50:39 EDT
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.
Comment 5 Matthias Clasen 2012-09-26 21:37:57 EDT
Nominating as beta blocker
Comment 6 Adam Williamson 2012-10-03 14:14:36 EDT
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.
Comment 7 Mathieu Bridon 2012-10-03 22:24:59 EDT
(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
Comment 8 Rui Matos 2012-10-16 09:36:09 EDT
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.
Comment 9 Lennart Poettering 2012-10-16 11:24:59 EDT
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.
Comment 10 Rui Matos 2012-10-16 12:00:06 EDT
(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.
Comment 11 Adam Williamson 2012-10-16 15:50:33 EDT
re-assigning to kernel, updating summary to hopefully be clearer: kernel guys, focus on comment #8 onwards.
Comment 12 Josh Boyer 2012-11-13 10:30:24 EST
(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?
Comment 13 Rui Matos 2012-11-13 14:30:07 EST
(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).
Comment 14 Josh Boyer 2012-11-14 08:17:19 EST
(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.
Comment 15 Josh Boyer 2012-11-14 08:38:43 EST
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.
Comment 16 Josh Boyer 2012-11-14 09:26:59 EST
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.
Comment 17 Josh Boyer 2012-11-14 10:34:21 EST
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.
Comment 18 Mathieu Bridon 2012-11-16 02:00:44 EST
(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
Comment 19 Mathieu Bridon 2012-11-16 06:08:45 EST
(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
Comment 20 Josh Boyer 2012-11-16 09:49:55 EST
(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.
Comment 21 Adam Jackson 2012-11-16 13:49:26 EST
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.
Comment 22 Josh Boyer 2012-11-20 09:42:13 EST
(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.
Comment 23 Arthur Taylor 2012-12-12 13:41:44 EST
(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.
Comment 24 Arthur Taylor 2012-12-12 14:05:29 EST
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?
Comment 25 Rui Matos 2012-12-12 15:32:23 EST
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.
Comment 26 Arthur Taylor 2012-12-12 16:42:16 EST
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.
Comment 27 Andrey Borzenkov 2013-02-03 00:13:01 EST
(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.
Comment 28 Josh Boyer 2013-09-27 08:45:35 EDT
We're still carrying a kernel patch for this.  It would be good to either get it upstream, or solved in another manner.

Adam?
Comment 29 Arthur Taylor 2013-09-27 14:21:16 EDT
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
Comment 30 Josh Boyer 2013-09-30 09:34:56 EDT
OK.  That code is in all of the systemd versions found in supported Fedora releases.  I'm dropping the patch.
Comment 31 Fedora Update System 2013-10-03 09:43:28 EDT
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
Comment 32 Fedora Update System 2013-10-03 09:45:42 EDT
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
Comment 33 Fedora Update System 2013-10-03 22:02:38 EDT
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).
Comment 34 Fedora Update System 2013-10-04 15:44:13 EDT
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
Comment 35 Fedora Update System 2013-10-05 21:29:08 EDT
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.
Comment 36 Fedora Update System 2013-10-05 21:31:13 EDT
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).
Comment 37 Fedora Update System 2013-10-09 10:14:32 EDT
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.
Comment 38 Fedora Update System 2013-10-09 20:55:33 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.