On Jan 11, 2008 1:51 AM, Meik Hellmund <[EMAIL PROTECTED]> wrote: > I would really appreciate some more documentation about Xnewt + keyboards. > How does Xnewt autodetect the keyboard layout? If this autodetection > fails, how can we define the keyboard layout manually? Why have invocations of > xmodmap those strange side effects? Are there any special things in the > implementation of the XKB extension? And so on ...
USB keyboards are supposed to report a layout code that tells the Sun Ray what the keyboard layout is. Whenever the Sun Ray reports a key event to the server (in this case Xnewt) it includes the keyboard's layout code in the report. SRSS delivers a set of key tables. Each table defines the key mappings that Xnewt should use to process a key event coming from a keyboard with a particular layout. The keytables reside in /opt/SUNWut/lib/keytables on Linux. A file named keytable.map in that directory tells Xnewt which table to use for each layout code. The keytable.map file is copied from Solaris and it contains a lot of stuff that Sun Ray doesn't care about. 'grep ^6 keytable.map' will show you the lines that Sun Ray uses. The second column is the layout code, the third column is the key table that is used when key events are received from a keyboard of that layout. (This is the non-XKB explanation. When XKB is turned on the xkbtable.map file is used instead of keytable.map and the keytables are loaded from someplace under /etc/X11/xkb, I think. I don't know much about the XKB implementation.) At startup Xnewt loads the keytable associated with layout code 0. Whenever Xnewt gets a key report whose layout code is different from the layout code of the currently-loaded table it moves the currently-loaded table aside (into an in-memory cache) and then loads the table for the new layout code (from the in-memory cache if that layout has been seen before, otherwise from the keytable file) before processing the key event report. This lets you have, say, French and German keyboards plugged into your Sun Ray and both of them work correctly. If Xnewt gets a layout code that has no matching entry in keytable.map then it uses the table for layout code 0. Keyboards made for the PC market typically don't report a proper layout code, they report 0, so they get the table for layout code 0 too. (Sun keyboards report a proper layout code. This is one reason why they're more expensive, there's extra manufacturing work to get the layout code to match what's printed on the keys.) In keytable.map as delivered, code 0 gets the US keytable. If you use non-US PC (code 0) keyboards on your Sun Rays then you'll probably want to edit keytable.map and match a suitable keytable to layout code 0. This is a system-wide setting, there's no way to set it on a per-DTU or per-token or per-anything-else basis. Customers don't seem to be annoyed by this, perhaps because they use Sun keyboards with their Sun Rays or perhaps because when they use code 0 keyboards those keyboards all have the same layout so a system-wide setting is OK. One reason why xmodmap can be strange is that xmodmap always works against Xnewt's current keytable. That's the keytable for the layout code in the most recent key event that Xnewt has processed. If Xnewt later sees input from a different layout, the modmap'ed keytable will be moved aside and the key event will be processed according to the keytable for the new event. That new keytable might be fresh from disk or might itself have been modmap'ed in the past at some point when it was the current keytable. In early releases of Sun Ray the keytable was always loaded fresh from disk and therefore xmodmap changes never survived a layout change, but the Linux version has always had the in-memory cache so xmodmap changes made to a given layout's keytable persist across layout changes. This behaviour can be important if you try to use xmodmap very early in the session, before the user has touched the keyboard. In that case it's quite possible that your xmodmap updates will be made to a keytable (the initial code 0 keytable) that will be moved aside as soon as the first keystroke from a non-code-0 keyboard is received, making the xmodmap changes ineffective. The big reason why xmodmap is particularly strange on Linux is that many Linux distros have an unconditional invocation of xmodmap at login time, and that invocation makes the unwarranted assumption that the user is using a PS/2 keyboard. Applying PS/2 modmaps to a Sun Ray is probably not going to produce sane results. (This whole xmdomap-after-login thing is a ridiculous hack in the first place. If the console keyboard mapping is busted then the right solution is to configure the console X server to get the mapping right, not to blindly remake every X server's mappings whenever anybody logs in.) Does that help? OttoM. __ ottomeister Disclaimer: These are my opinions. I do not speak for my employer. _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
