Hi, After upgrade to Gnome 3.16 I've seen something very strange : it is impossible for me to use the "s" key into the textbox component. I tried using both the visual keyboard and the real keyboard and the same happens. The "S" key works, but not the "s". And when I switch to VT the "s" works again, so it is definitely not my keyboard which is faultly there. So I cannot use anymore the GUI to login and have no way to use Gnome nor KDE. For example if as your login you use "samantha" you'll see "amantha", however if you use "Samantha" it works. The same for the password field. Note that in GDM 3.14 the issue did not appear I'm using Gentoo in the following conditions : - Arch : AMD64 - Within VirtualBox 5.0.4 - Locale : fr_FR, keyboard layout : fr Build : gnome-base/gdm-3.16.2::gentoo USE flags : "branding introspection ipv6 systemd tcpd -accessibility -audit -debug -fprint yplymouth (-selinux) -smartcard -test -wayland -xinerama" ABI_X86="64" Could you please fix it or give me a workaround, as even though it looks ridiculous is is critically annoying.
This is really strange... and I cannot reproduce it. How do you have X configured? I mean, do you have a /etc/X11/xorg.conf file? What is the content of xorg.conf.d/00-keyboard.conf? I would try to switch the keymap using "localectl" to ensure it's set properly
Hello, Yes. Its content is below : Section "InputClass" Identifier "system-keyboard" MatchIsKeyboard "on" Option "XkbLayout" "fr" EndSection
It looks ok to me :/, I guess you don't have any other settings in other files at /etc/X11/xorg.conf.d/ that could collide, right? Can you try to switch to, for example, and english keymap temporally for X: # localectl set-x11-keymap en and try to see if it makes "s" key to work?
Unfortunately this does not work even with locale en. Note that with GDM 3.14 there was no issue.
Well, a workaround is to use "passwd" command in the text console to change your password. Then log in using gdm, install x11-apps/xev, run xev from the terminal, point your mouse cursor inside the window, and press "s". In theory, you should see something like this: KeyPress event, serial 36, synthetic NO, window 0x2000001, root 0x1d0, subw 0x0, time 1894955840, (153,109), root:(2201,273), state 0x10, keycode 39 (keysym 0x73, s), same_screen YES, XLookupString gives 1 bytes: (73) "s" XmbLookupString gives 1 bytes: (73) "s" XFilterEvent returns: False KeyRelease event, serial 36, synthetic NO, window 0x2000001, root 0x1d0, subw 0x0, time 1894955959, (153,109), root:(2201,273), state 0x10, keycode 39 (keysym 0x73, s), same_screen YES, XLookupString gives 1 bytes: (73) "s" XFilterEvent returns: False
One possibility is that virtualbox is doing something strange with key filtering. Please check your virtualbox settings.
Looks like my "s" key is actually bound to the visual keyboard since GNOME 3.16. How could I remove this ? Thanks
(In reply to gojul91 from comment #7) > Looks like my "s" key is actually bound to the visual keyboard since GNOME > 3.16. What do you mean? And what is the xev output for pressing "s"?
Update : the bug is clearly gnome-related. With KDE no problem.
I mean that if I press "s" under a GNOME-based app it will start the visual keyboard, while under anything else it behaves normally. There are two problems there : - The issue started to appear with Gnome 3.16 (no change in 3.14) - No way to remove the shortcut...
Again, please provide the xev output when you press "s". As for shortcuts - check the following: gnome-control-center → region and language (check that the input source preview matches what you have on your keyboard) gnome-control-center → keyboard → shortcuts gnome-tweak-tool → typing
The "s" key appears nowhere here... :'(
I'm running into this (have been for a while, but finally working on it). I'm currently on gnome 3.18.2, and I'm having problems with the 7 key on the top row of the keyboard. The number pad still works. If I use super+7 in Terminal, it works. Here's the output of xev doing 6+7+super7+8: KeyPress event, serial 36, synthetic NO, window 0xe00001, root 0x1e1, subw 0x0, time 1860965, (761,818), root:(798,892), state 0x10, keycode 15 (keysym 0x36, 6), same_screen YES, XLookupString gives 1 bytes: (36) "6" XmbLookupString gives 1 bytes: (36) "6" XFilterEvent returns: False KeyRelease event, serial 36, synthetic NO, window 0xe00001, root 0x1e1, subw 0x0, time 1861126, (761,818), root:(798,892), state 0x10, keycode 15 (keysym 0x36, 6), same_screen YES, XLookupString gives 1 bytes: (36) "6" XFilterEvent returns: False FocusOut event, serial 36, synthetic NO, window 0xe00001, mode NotifyGrab, detail NotifyAncestor FocusIn event, serial 36, synthetic NO, window 0xe00001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 36, synthetic NO, window 0x0, keys: 64 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 FocusOut event, serial 36, synthetic NO, window 0xe00001, mode NotifyGrab, detail NotifyAncestor FocusIn event, serial 36, synthetic NO, window 0xe00001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 36, synthetic NO, window 0x0, keys: 2 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 32 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 KeyPress event, serial 36, synthetic NO, window 0xe00001, root 0x1e1, subw 0x0, time 1863798, (761,818), root:(798,892), state 0x50, keycode 16 (keysym 0x37, 7), same_screen YES, XLookupString gives 1 bytes: (37) "7" XmbLookupString gives 1 bytes: (37) "7" XFilterEvent returns: False KeyRelease event, serial 36, synthetic NO, window 0xe00001, root 0x1e1, subw 0x0, time 1863910, (761,818), root:(798,892), state 0x50, keycode 16 (keysym 0x37, 7), same_screen YES, XLookupString gives 1 bytes: (37) "7" XFilterEvent returns: False KeyRelease event, serial 36, synthetic NO, window 0xe00001, root 0x1e1, subw 0x0, time 1864446, (761,818), root:(798,892), state 0x50, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 36, synthetic NO, window 0xe00001, root 0x1e1, subw 0x0, time 1865886, (761,818), root:(798,892), state 0x10, keycode 17 (keysym 0x38, 8), same_screen YES, XLookupString gives 1 bytes: (38) "8" XmbLookupString gives 1 bytes: (38) "8" XFilterEvent returns: False KeyRelease event, serial 36, synthetic NO, window 0xe00001, root 0x1e1, subw 0x0, time 1865982, (761,818), root:(798,892), state 0x10, keycode 17 (keysym 0x38, 8), same_screen YES, XLookupString gives 1 bytes: (38) "8" XFilterEvent returns: False localectl looks like this (was pc105, but set to microsoft4000 after seeing it available, and it's what I'm using, with not change): System Locale: LANG=en_US.utf8 VC Keymap: us X11 Layout: us X11 Model: microsoft4000 /etc/X11/xorg.conf.d/00-keyboard.conf is the following: Section "InputClass" Identifier "system-keyboard" MatchIsKeyboard "on" Option "XkbLayout" "us" Option "XkbModel" "microsoft4000" EndSection As others have said, on VT it works fine. Also, I found that if I'm in a virtual machine through VMM (Spice Channel), inside the VM is not affected. There also seems to be a few Forum postings about this as well: https://forums.gentoo.org/viewtopic-p-7859746.html https://forums.gentoo.org/viewtopic-t-1036094.html I've double checked gnome-control-center: region and language, and keyboard -> shortcuts, and gnome-tweak-tool shows everything as disabled. This did happen after some system updates a while ago, but sadly I've just been dealing with it that I couldn't tell you which one. I think it was an update to Gnome, but again, I'm not 100% sure.
I have been able to reproduce this strange bug, on a fresh install (amd64) (I decided to try GNOME on Gentoo's stable branch.) GDM nor GNOME (started from startx, because I was also unable to log in via gdm) recognizes the 's' key, and, for some reason, user interface buttons, etc. have gotten smaller. (DPI change? I don't have a high DPI monitor.) I can confirm that the "S" key (uppercase) does work. Although, I am surprised that it occurred in VirtualBox for gojul91. In my situation, I am not using VirtualBox. I have switched back to the testing branch. GNOME 3.18 doesn't have this problem, at least, in my case.
I am also unable to type the lowercase "s" key, but can get around it by turning on caps-lock and holding shift. The output of xev is: KeymapNotify event, serial 36, synthetic NO, window 0x0, keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 FocusOut event, serial 36, synthetic NO, window 0xc00001, mode NotifyGrab, detail NotifyAncestor FocusOut event, serial 36, synthetic NO, window 0xc00001, mode NotifyUngrab, detail NotifyPointer FocusIn event, serial 36, synthetic NO, window 0xc00001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 36, synthetic NO, window 0x0, keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 FocusOut event, serial 36, synthetic NO, window 0xc00001, mode NotifyGrab, detail NotifyAncestor FocusOut event, serial 36, synthetic NO, window 0xc00001, mode NotifyUngrab, detail NotifyPointer FocusIn event, serial 36, synthetic NO, window 0xc00001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 36, synthetic NO, window 0x0, keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 I was experiencing this problem with Gnome 3.16, and am still with 3.18. It occur both when using startx, and gdm. It is running on a physical computer with an AMD x86_64 CPU. An additional problem I am having is that the "r" key does not work at the login screen (but works fine the rest of the time) - though I am not sure it is related. It can also be entered using the caps lock method described at the start of this post.
I am able to use the "s" key in gnome after disabling "media-keys" using gnome-base/dconf-editor as suggested here: https://forums.gentoo.org/viewtopic-t-1034240.html and setting the "active" value to false here: org/gnome/settings-daemon/plugins/media-keys/ Looking through the assigned keys there I do not see the "s" key being bound to any action.
I would try to report to upstream to see if they know more about where is really the problem: https://bugzilla.gnome.org/enter_bug.cgi?product=gnome-settings-daemon (with "media-keys" as component) Then, please, post here the link to the report for letting us to track the issue Thanks
Did you report this finally? :/
Hello Pacho, Sorry but no, I have not - in the mean time I have just been using KDE.
Hello! Previously, I've commented on how I switched to the testing branch to see if GNOME 3.18 would have fixed the problem. Recently, I noticed that 3.18 was brought to the stable branch. After, switching back again to stable, the lowercase 's' key still does not work. (In reply to boarder_dougca from comment #16) Thank you for sharing this. Disabling 'media-keys' in dconf-editor does help. I also mentioned something about text looking unusually small. After enabling 'media-keys' using dconf-editor, and pressing the 's' key, the text size decreases. Somehow, GNOME is confusing the 's' key as a media key that is somehow bound to "decrease-text-size" in dconf-editor. Replacing the value of decrease-text-size from nothing to one white space is a workaround to this problem, while allowing me to use my other media keys. :) Keeping this value blank would lead to the s key functioning as a "decrease-text-size" media key. However, I don't know why this does not happen on the testing branch. I haven't seen this reported anywhere else.
*** Bug 582356 has been marked as a duplicate of this bug. ***
The problem persists with gnome 3.20 as well as its workaround. On fedora, everything works fine
I have started to suffer this with 3.20 :S
I think this is caused by the installation of some package. I mean, while that X package is not installed, gdm/gnome-shell work ok, but when it's present on the system, it gets used and messes all up. The problem is that I don't know what is the package :S, my guess is that it's some package from app-accesibility category from this list: http://euscan.gentooexperimental.org/maintainers/gnome@gentoo.org/ If anyone could help on finding that (probably unmerging the package and restarting gnome-shell to try (gnome-shell is the one that is behaving badly I think, not gdm) it would be really helpful as I don't have much time to affort all this :( Thanks a lot
The thing is that the contents of: /usr/share/glib-2.0/schemas/org.gnome.desktop.a11y.applications.gschema.xml should set this things off :/
(In reply to Pacho Ramos from comment #23) > I have started to suffer this with 3.20 :S I have the same issue on 3.20. Deactivating media-keys with dconf-editor does not help for the login screen.
I'm running 3.20 on Wayland, and can report using "s" key with no issues. Unfortunately I didn't run Gnome on X at all before, so can't compare. But wondering if this bug is contained to xorg-server?
This is a shame, I cannot reproduce any more :S, but I haven't yet depcleaned anything and, then, I have the same full list of our gnome maintained packages installed The change has been that, of course, most gnome packages are now finally bumped to 3.20 versions :/ Then, I don't know if this is caused by that or, the more harder to debug one, caused by a package that needs to be rebuilt after other one is updated (and we are failing to detect it :S) Regarding wayland vs. X, I am running X
(In reply to Pacho Ramos from comment #28) > This is a shame, I cannot reproduce any more :S, but I haven't yet > depcleaned anything and, then, I have the same full list of our gnome > maintained packages installed > > The change has been that, of course, most gnome packages are now finally > bumped to 3.20 versions :/ > > Then, I don't know if this is caused by that or, the more harder to debug > one, caused by a package that needs to be rebuilt after other one is updated > (and we are failing to detect it :S) > > Regarding wayland vs. X, I am running X Same with me. After updating several packages to 3.20 I can't reproduce this anymore. This problem is gone, for now. I'm and was on X too.
I've been running Gnome on X 3.26 -> 3.32 now, and have yet to see this issue. I recommend closing it as INVALID or similar.
