GNOME Bugzilla – Bug 694623
Show keyboard layout doesn't work
Last modified: 2021-06-09 16:13:27 UTC
We stopped depending on libgnomekbd long ago, but the show keyboard layout feature was never fixed. We should probably migrate the keyboard drawing code into gnome-desktop, where there rest of the xkb code lives, and use that in gnome-control-center (and by extension gnome-shell)
Created attachment 237319 [details] [review] Don't rely on libgnomekbd for drawing keyboards libgnomekbd is deprecated and is no longer guaranteed to be installed on all systems. Instead, use the new keyboard drawing widget from libgnome-desktop (which is mostly a ripoff of the same from libgnomekbd)
Created attachment 237320 [details] [review] region: Add support for showing a keyboard layout when launched Add a "show-layout" command line argument, that will allow the shell to launch the region panel showing a particular keyboard layout (usually, the current one)
(In reply to comment #2) > Created an attachment (id=237320) [details] [review] > region: Add support for showing a keyboard layout when launched > > Add a "show-layout" command line argument, that will allow > the shell to launch the region panel showing a particular keyboard > layout (usually, the current one) In that case, there's no reason for the layout code to live in gnome-desktop, it could be in gnome-control-center directly.
I noticed something about the keyboard layout preview widget today; it respects the xkb 'geometry' setting in determining what physical keys to draw. In practice, with the evdev ruleset - which I think everything uses these days - that setting will almost always be 'pc104', which is the geometry used by a US-style keyboard with Windows keys (pc101 is US-style without Windows keys). When drawing a preview of a layout which is more commonly associated with the 'pc105' or 'pc102' physical keyboard - where the enter key and one other key in that neighbourhood are different, and there is an extra key between the left 'shift' key and the first alphanumeric key on the row above space (Z on a US/UK layout, Y on German, probably something else on other layouts) - this looks rather odd and means one key is missing. If it just defaulted to 'pc105', though, I suppose the illustration of the normal US layout (and any other layouts which use the 101/104-key physical keyboard) would be wrong. To get it exactly right there'd need to be a source of data about which keyboard layouts are most commonly associated with which geometries, I guess, and the place to put that would probably be langtable. But there's a fairly simple approximation you can use that looks like it'd be correct most of the time: if the layout is a US variant then use the pc104 geometry, if it's anything else, use the pc105 geometry. From a quick peruse of https://en.wikipedia.org/wiki/QWERTY , https://en.wikipedia.org/wiki/QWERTZ , and https://en.wikipedia.org/wiki/AZERTY it looks like most everything that isn't a US variant uses the pc105 geometry, the exceptions being a few which use an oddball geometry which looks like pc104 around the Enter key but has the extra key between left shift and Z, and Vietnamese and "Turkish Q", which use the pc104 geometry.
(In reply to comment #4) > I noticed something about the keyboard layout preview widget today; it respects > the xkb 'geometry' setting in determining what physical keys to draw. This is a separate problem, please file another bug.
Comment on attachment 237319 [details] [review] Don't rely on libgnomekbd for drawing keyboards This should be a separate binary inside the gnome-control-center tree.
Comment on attachment 237320 [details] [review] region: Add support for showing a keyboard layout when launched This should be a separate binary inside the gnome-control-center tree.
(In reply to comment #4) > I noticed something about the keyboard layout preview widget today; it respects > the xkb 'geometry' setting in determining what physical keys to draw. In > practice, with the evdev ruleset - which I think everything uses these days - > that setting will almost always be 'pc104', which is the geometry used by a > US-style keyboard with Windows keys (pc101 is US-style without Windows keys). > When drawing a preview of a layout which is more commonly associated with the > 'pc105' or 'pc102' physical keyboard - where the enter key and one other key in > that neighbourhood are different, and there is an extra key between the left > 'shift' key and the first alphanumeric key on the row above space (Z on a US/UK > layout, Y on German, probably something else on other layouts) - this looks > rather odd and means one key is missing. > > If it just defaulted to 'pc105', though, I suppose the illustration of the > normal US layout (and any other layouts which use the 101/104-key physical > keyboard) would be wrong. > > To get it exactly right there'd need to be a source of data about which > keyboard layouts are most commonly associated with which geometries, I guess, > and the place to put that would probably be langtable. But there's a fairly > simple approximation you can use that looks like it'd be correct most of the > time: if the layout is a US variant then use the pc104 geometry, if it's > anything else, use the pc105 geometry. From a quick peruse of > https://en.wikipedia.org/wiki/QWERTY , https://en.wikipedia.org/wiki/QWERTZ , > and https://en.wikipedia.org/wiki/AZERTY it looks like most everything that > isn't a US variant uses the pc105 geometry, the exceptions being a few which > use an oddball geometry which looks like pc104 around the Enter key but has the > extra key between left shift and Z, and Vietnamese and "Turkish Q", which use > the pc104 geometry. Why is Debian Wheezy able to get this right, and Fedora Gnome cannot. We do not show the keyboard layout shown in my attachment that is coming or in what wikipedia shows as keyboard layouts.
Created attachment 271299 [details] Physical keyboard description from 1990 IBM standard layout Note the location of the left superkey and the extra keytop between the left shift and the Z key. This physical layout is used for latam, ca, and many other layouts. The graphical layout does not depict this layout.
Created attachment 271300 [details] wrong location for superkey Very frustrating when Gnome cannot get the location of the left super key in the right place.
Why is it that if the Gnome support person notices a problem with the bug, that he does not himself do the copy and paste. I am referring to comment 5 Essentially, the bug being reported probably never gets fixed, simply because we may miss the email with the "its not my problem" approach. How many years does it take to fix a problem? From other keyboard bug reports, issues are open since 2011.
"Why is Debian Wheezy able to get this right, and Fedora Gnome cannot." Did you check that it actually gets it right for all layouts? Getting it right for yours but wrong for 104-key layouts is still wrong, it's just wrong differently.
Hi Adam, I was asked to upload pictures of keyboards I use. Attached you will find latam and cafr ... xkb/Symbols/ca and as well the physical layout for xkb/symbols/latam. It seems that Debian recognizes the hardware and uses that to draw the layout. I used US keyboard layout and it still came up pc105. To be sure, I will attach a different keyboard and try that one to prove your conjecture.
Created attachment 275278 [details] The layout used on my Spanish Netbook (latam)
(In reply to comment #11) > Why is it that if the Gnome support person notices a problem with the bug, that > he does not himself do the copy and paste. I am referring to comment 5 Because I'm not your "support person". If you want support, pay for it. There are plenty of providers of such support. > Essentially, the bug being reported probably never gets fixed, simply because > we may miss the email with the "its not my problem" approach. This bug is to move a piece of code that still hasn't moved. Why your problem would be in any way relevant to moving this code is beyond me. > How many years does it take to fix a problem? From other keyboard bug reports, > issues are open since 2011. Seriously, if you're not happy with the "support" you're getting here, either pay for it, or use something else. I'm getting tired of your off-topic comments, here, or on desktop-devel-list.
Filed https://bugzilla.gnome.org/show_bug.cgi?id=729115 to cover the issue from comment #4. Please don't post about it further in this bug.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new bug report at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/ Thank you for your understanding and your help.