Bug 441398 - default layout set to us+inet
default layout set to us+inet
Product: Fedora
Classification: Fedora
Component: xkeyboard-config (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Kristian Høgsberg
Fedora Extras Quality Assurance
: Reopened
: 439969 (view as bug list)
Depends On:
Blocks: F9Blocker
  Show dependency treegraph
Reported: 2008-04-07 16:40 EDT by jmccann
Modified: 2018-04-11 03:22 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-14 23:59:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch (562 bytes, patch)
2008-04-08 14:40 EDT, Matthias Clasen
no flags Details | Diff
alternative hack (674 bytes, patch)
2008-04-08 20:15 EDT, Matthias Clasen
no flags Details | Diff
another iteration of the first patch (1011 bytes, patch)
2008-04-09 00:15 EDT, Matthias Clasen
no flags Details | Diff
enable navigation keys (254 bytes, patch)
2008-04-10 17:41 EDT, petrosyan
no flags Details | Diff

  None (edit)
Description jmccann 2008-04-07 16:40:11 EDT

Seems to set the default layout to us+inet instead of us.

One result of this change is that the gnome-panel keyboard indicator applet
shows "us+inet" instead of "USA".  Also this shows up in the screensaver unlock
dialog because it uses the same widget as the applet.

Not sure if this is a libgnomekbd bug or a xorg-x11-drv-keyboard one.
Comment 1 Matěj Cepl 2008-04-08 07:41:15 EDT
I think Gnome, us+inet is IMHO The Right Thing™ and the issue how to display the
name in Gnome. Reassigning.
Comment 2 Matěj Cepl 2008-04-08 07:41:50 EDT
*and the issue is ...
Comment 3 Matthias Clasen 2008-04-08 09:54:14 EDT
I have 

[mclasen@localhost devel]$ xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc105", "us+inet", "", ""
_XKB_RULES_NAMES(STRING) = "xorg", "dellm65", "us,de", ",nodeadkeys",

And it still shows up as "USA" in the keyboard indicator
Comment 4 jmccann 2008-04-08 10:48:08 EDT
I have:
xprop -root | grep XKB
_XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc105", "us+inet", "", ""
_XKB_RULES_NAMES(STRING) = "xorg", "pc105", "us+inet", "", ""

So according to svu (on irc):
<svu> mccann: first of all, that patch is wrong. there is no sensible default
variant in inet. and it should not be used like that
<mccann> ajax says that us+inet has some "special internet keys" or something?
<svu> mccann: ajax is right BUT these keys depend on the particular model. you
never use them like "us+inet" instead you should specify correct xkb model
<svu> for example
<svu> XkbModel "cymotionlinux"
<mccann> so should we translate us+inet to something more understandable perhaps?
<svu> no please
<svu> this is simply incorrect use of xkb
<mccann> oh ok
<svu> technically correct but semantically totally wrong
<svu> in that case all I promise is to do my best not to crash:)
<svu> mccann: if ajax is around, may be he could come here and we could discuss
what's really required
Comment 5 Matthias Clasen 2008-04-08 11:40:53 EDT
So, the issue here is that this makes the keyboard selector show up in the lock
dialog with two choices of "us+inet" and "?" which is really broken. And the
keyboard indicator applet will show the same brokenness, should the user add it
to his panel config. Note that the problem does only occur if you don't select
your own keyboard layouts in the keyboard capplet (like I did in the example above)

I assume our options here are to

a) go back to "us" and live with broken inet keys

b) patch libgnomekbd or xklavier to treat us+inet like us (might not be trivial,
haven't investigated)

c) take the keyboard selector out of the lock dialog and live with the broken
keyboard indicator applet, since it is not in the default panel config

Comment 6 Jesse Keating 2008-04-08 13:49:51 EDT
We fixed a lot of complaints when we went to +inet, I'd hate to revert that.
Comment 7 Matthias Clasen 2008-04-08 14:39:50 EDT
Ok, so how about this hack instead...
We switch the kbd driver back to use "us", and then we teak the xkb rules to
declare our default keyboard model (pc105) to be an inetkbd ?

I think that is what the patch below does...
Comment 8 Matthias Clasen 2008-04-08 14:40:22 EDT
Created attachment 301686 [details]
Comment 9 Matthias Clasen 2008-04-08 14:48:19 EDT
Of course, option c) may still be the safer bet at this time in the cycle.
Comment 10 Matthias Clasen 2008-04-08 20:14:36 EDT
Here is the alternative hack to make libgnomekbd display "USA" instead of us+inet.
I still have to track down the "?" and how to make that go away.
Comment 11 Matthias Clasen 2008-04-08 20:15:05 EDT
Created attachment 301734 [details]
alternative hack
Comment 12 Matthias Clasen 2008-04-09 00:15:43 EDT
Created attachment 301747 [details]
another iteration of the first patch

With this patch I still have my multmedia keys working with pc105 and us.
Comment 13 Matěj Cepl 2008-04-09 05:57:28 EDT
I think this is a way beyond NEW.
Comment 14 Matthias Clasen 2008-04-09 11:22:47 EDT
* Wed Apr  9 2008 Matthias Clasen  <mclasen@redhat.com> - 1.2-2
- Make pc105 have inet keys, not 100% correct, but better than
  having the kbd driver report "us+inet" which confused XKB and
  higher layers (#441398)
Comment 15 petrosyan 2008-04-10 17:41:42 EDT
Created attachment 302078 [details]
enable navigation keys

This simple patch enables web browser navigation keys ('Back' and 'Forward') on
all ThinkPad laptops as well as over 30 other keyboard models which have those
navigation keys.

I tested this patch on 04/10/2008 Fedora rawhide, with Firefox 3 on ThinkPad
X61 and it works pefectly. Please consider applying it before Fedora 9 release.

(Run 'grep nav_common /usr/share/X11/xkb/symbols/inet | wc -l' to find the
number of keyboard models which have navigation keys)
Comment 16 petrosyan 2008-04-11 00:17:38 EDT
*** Bug 439969 has been marked as a duplicate of this bug. ***
Comment 17 Matthias Clasen 2008-04-14 23:59:43 EDT
I've added this patch and proposed the build for f9

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