Responding to the thread about mapping hardware scan codes --> X key codes and keyboards with > 248 keys.
Perhaps the solution is to take the hardware scan code --> Symbol problem out of the X layer entirely. Let the OS deal with that in its own manner. Simpler is better? (Please flame/reply to me in private [email protected]) -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Sunday, July 26, 2009 3:21 AM To: [email protected] Subject: xorg Digest, Vol 48, Issue 59 Send xorg mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://lists.freedesktop.org/mailman/listinfo/xorg or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of xorg digest..." Today's Topics: 1. Re: Kernel 2.6.30.1 Oops on Alpha Architecture when starting Xserver (Dave Airlie) 2. Re: XI2 = moving target? (Jim Gettys) 3. Re: XI2 = moving target? (Alan Cox) 4. Re: XI2 = moving target? (Jim Gettys) 5. Re: XI2 = moving target? (Peter Hutterer) 6. Re: XI2 = moving target? (Maxim Levitsky) 7. Re: XI2 = moving target? (Nicolas Mailhot) 8. Re: XI2 = moving target? (Peter Hutterer) 9. Re: XI2 = moving target? (Maxim Levitsky) ---------------------------------------------------------------------- Message: 1 Date: Sun, 26 Jul 2009 08:54:27 +1000 From: Dave Airlie <[email protected]> Subject: Re: Kernel 2.6.30.1 Oops on Alpha Architecture when starting Xserver To: Michael Cree <[email protected]> Cc: [email protected], [email protected], [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1 >>> The kernel oops is: >>> >> >> So its a machine check, >> > > So, does this indicate a software fault (e.g. inconsistencies in kernel data > structures) or does it imply a hardware fault? > >> Well X is trying to post the graphics card you have installed, and the >> machine >> is falling over when it does it. >> > > SRM (the equivalent of a BIOS) cannot post the card on startup. ?But I have > had the card (radeon rv610) post correctly and working in the past when I > compiled the complete 1.5.3 Xserver myself. ?I had it working with both the > radeon and radeonhd drivers and a 2.6.29.x kernel patched to support > libpciaccess. There is no -ati card in that machine, its got some SiS card which is completely different, maybe its some onboard card or something. Dave. ------------------------------ Message: 2 Date: Sat, 25 Jul 2009 19:30:20 -0400 From: Jim Gettys <[email protected]> Subject: Re: XI2 = moving target? To: Nicolas Mailhot <[email protected]> Cc: "Timothy S. Nelson" <[email protected]>, [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=UTF-8; format=flowed Nicolas, In the original X11 design and keyboard system, keycodes are arbitrary, and need not have anything to do with the codes produced by the hardware (which are often quite baroque, and often formed by multiple character transmissions from the keyboard to the host). Just because the hardware sends some byte, doesn't mean it needs to be used as its keycode. It is often convenient to do so, but not necessary... And they may have nothing to do with PS/2 keyboards at all; in fact, most workstation keyboards were entirely different. For example, some keyboards (at the hardware level) have sent a bit vector of all the keys that are down as a set of bytes, and that has then been translated to a sequence of keycodes that changed. Others transmit a few bytes that talk about X/Y coordinates in the scan matrix, and whether the key went up or down. There may be something in our current implementations that deal with PC style keyboards that do magic with keycodes > 255 and translate them, but that is different than what gets encoded into a keyboard event as a keycode. Usually, when one is trying to distinguish what the hardware sends from the X protocol layer (or if you actually talk about what keyboards send), the bytes a keyboard transmits are called "scancodes". It has been convenient on many keyboards to just use them as keycodes if the keyboard makes it easy, but not necessary. Ergo my question on whether anyone has ever actually seen in captivity a keyboard with more than 248 keys... - Jim Nicolas Mailhot wrote: > Le samedi 25 juillet 2009 ? 13:31 -0400, Jim Gettys a ?crit : >> That isn't a good reason: keycodes are arbitrary, a simple table lookup >> to remap them to 8-255 is an easy solution, much easier than the >> alternatives, unless I'm missing something... > > keycodes are not arbitrary, the codes > 255 have a standardised meaning, > if you remap them they don't behave like they should according to the > symbol printed on them. > > Also it is very common to have multiple input devices nowadays that all > have some keycodes > 255 so any remapping solution would need to be able > to manage parallel hotplug of devices with different requirements (in > fact what is un-common is devices that only use keycodes < 255, I tried > to buy one last time I was in the local chinatown to avoid dealing with > this issue ? they don't exist anymore) > ------------------------------ Message: 3 Date: Sun, 26 Jul 2009 00:44:50 +0100 From: Alan Cox <[email protected]> Subject: Re: XI2 = moving target? To: Jim Gettys <[email protected]> Cc: "Timothy S. Nelson" <[email protected]>, [email protected], Nicolas Mailhot <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=US-ASCII > Ergo my question on whether anyone has ever actually seen in captivity a > keyboard with more than 248 keys... I'm not sure that is a useful question. I have a collection of keyboards and remotes. All of them have different functions above 255 which could be remapped. All of them are hot pluggable. Trying to manage a mapping of all the devices randomly on the fly plugged into a system and map them into a tiny space is rather more difficult than you make out. If you had to map a set of devices, once, to a fixed mapping it wouldn't be a big deal, but the world has moved on from that. Alan ------------------------------ Message: 4 Date: Sat, 25 Jul 2009 20:29:40 -0400 From: Jim Gettys <[email protected]> Subject: Re: XI2 = moving target? To: Alan Cox <[email protected]> Cc: "Timothy S. Nelson" <[email protected]>, [email protected], Nicolas Mailhot <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed I guess I'm still confused... So they'd show up as different devices with time; each time you get notification that the keysym mapping for the keycodes have changed. Why is there a problem? - Jim Alan Cox wrote: >> Ergo my question on whether anyone has ever actually seen in captivity a >> keyboard with more than 248 keys... > > I'm not sure that is a useful question. > > I have a collection of keyboards and remotes. All of them have different > functions above 255 which could be remapped. All of them are hot > pluggable. > > Trying to manage a mapping of all the devices randomly on the fly plugged > into a system and map them into a tiny space is rather more difficult > than you make out. > > If you had to map a set of devices, once, to a fixed mapping it wouldn't > be a big deal, but the world has moved on from that. > > Alan > > > ------------------------------ Message: 5 Date: Sun, 26 Jul 2009 10:37:27 +1000 From: Peter Hutterer <[email protected]> Subject: Re: XI2 = moving target? To: Maxim Levitsky <[email protected]> Cc: "Timothy S. Nelson" <[email protected]>, [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=us-ascii On Sat, Jul 25, 2009 at 07:59:54PM +0300, Maxim Levitsky wrote: > On Sat, 2009-07-25 at 12:12 -0400, Jim Gettys wrote: > > For curiosity's sake, have people actually seen keyboards with more than > > 248 keys? > > No, but plenty with keycodes > 256 > (Most TV remotes fail in this category, and I still am waiting for limit > of 256 keycodes to be lifted) keycodes are 32 bit in XI2, though to get full support for that we also need XKB2. Right now, we still cap at keycodes > 255. this is an implementation issue though, not a protocol restriction. Cheers, Peter ------------------------------ Message: 6 Date: Sun, 26 Jul 2009 04:11:00 +0300 From: Maxim Levitsky <[email protected]> Subject: Re: XI2 = moving target? To: Peter Hutterer <[email protected]> Cc: "Timothy S. Nelson" <[email protected]>, [email protected] Message-ID: <1248570660.6786.2.ca...@maxim-laptop> Content-Type: text/plain On Sun, 2009-07-26 at 10:37 +1000, Peter Hutterer wrote: > On Sat, Jul 25, 2009 at 07:59:54PM +0300, Maxim Levitsky wrote: > > On Sat, 2009-07-25 at 12:12 -0400, Jim Gettys wrote: > > > For curiosity's sake, have people actually seen keyboards with more than > > > 248 keys? > > > > No, but plenty with keycodes > 256 > > (Most TV remotes fail in this category, and I still am waiting for limit > > of 256 keycodes to be lifted) > > keycodes are 32 bit in XI2, though to get full support for that we also need > XKB2. Right now, we still cap at keycodes > 255. this is an implementation > issue though, not a protocol restriction. > > Cheers, > Peter Nice, and while at it, I have few questions: 1) will XKB2 allow 32 bit scancodes transparently for all Xlib applicatuions, or at least for all Qt/GTK applications with small modifications 2) When this will happen? Best regards Maxim Levitsky ------------------------------ Message: 7 Date: Sun, 26 Jul 2009 07:06:43 +0200 From: Nicolas Mailhot <[email protected]> Subject: Re: XI2 = moving target? To: Jim Gettys <[email protected]> Cc: "Timothy S. Nelson" <[email protected]>, [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" Le samedi 25 juillet 2009 ? 19:30 -0400, Jim Gettys a ?crit : > Nicolas, > > In the original X11 design and keyboard system, keycodes are arbitrary, > and need not have anything to do with the codes produced by the hardware > (which are often quite baroque, and often formed by multiple character > transmissions from the keyboard to the host). Modern scan codes are not arbitrary and when there are quirks they are hidden by the kernel input layer so right now xorg needs to talk to devices that use all the same keycodes (with many > 255). -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= Url : http://lists.freedesktop.org/archives/xorg/attachments/20090726/ac0e7e91 /attachment-0001.pgp ------------------------------ Message: 8 Date: Sun, 26 Jul 2009 18:41:37 +1000 From: Peter Hutterer <[email protected]> Subject: Re: XI2 = moving target? To: Jim Gettys <[email protected]> Cc: "Timothy S. Nelson" <[email protected]>, Nicolas Mailhot <[email protected]>, [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=us-ascii On Sat, Jul 25, 2009 at 08:29:40PM -0400, Jim Gettys wrote: > I guess I'm still confused... > > So they'd show up as different devices with time; each time you get > notification that the keysym mapping for the keycodes have changed. > > Why is there a problem? It makes things overly complicated. We use a number of shortcuts to simplify the keycode handling. One is that we don't actually use the keycode range as an actual range but rather use the keycodes in a way similar to keysyms. If you're using the evdev driver, each keycode is already defined to a specific symbol with hardware-specific quirks being done in the kernel or in HAL (possibly udev now, I still haven't looked into that). You could free the keycodes completely but then you'd have to have a Kcgst mapping for xkeyboard-config for every single device. Which means that the maintainance of xkeyboard-config becomes a nightmare, together with the myriads of things that can go wrong when users select the wrong keyboard model. By having a standardised set of keycodes this becomes much easier. In fact these days it is irrelevant what you select as your keyboard model in the evdev ruleset - they all map to the evdev model (there are a few exceptions that do require separate models). So the XKB configuration mostly deals with the actual layouts, taking one layer of complexity out. You could treat the keycode range as intended in the original X protocol, but then you'd have to have a model for every keyboard, remote, magic other device ever manufactured. We sort-of do that (look at the xorg/xfree86 ruleset) but it's not pretty. So by upping the keycode range to 32 bits we enable a larger standardised set of keycodes without the nightmare of maintaining loads of different keyboard models and requiring the user to configure them correctly. Note that a keycode still doesn't stand for a symbol. KEY_Q is still an 'a' if you have an azerty group. Cheers, Peter > Alan Cox wrote: > >> Ergo my question on whether anyone has ever actually seen in captivity a > >> keyboard with more than 248 keys... > > > > I'm not sure that is a useful question. > > > > I have a collection of keyboards and remotes. All of them have different > > functions above 255 which could be remapped. All of them are hot > > pluggable. > > > > Trying to manage a mapping of all the devices randomly on the fly plugged > > into a system and map them into a tiny space is rather more difficult > > than you make out. > > > > If you had to map a set of devices, once, to a fixed mapping it wouldn't > > be a big deal, but the world has moved on from that. > > > > Alan ------------------------------ Message: 9 Date: Sun, 26 Jul 2009 13:20:53 +0300 From: Maxim Levitsky <[email protected]> Subject: Re: XI2 = moving target? To: Peter Hutterer <[email protected]> Cc: "Timothy S. Nelson" <[email protected]>, [email protected], Nicolas Mailhot <[email protected]> Message-ID: <1248603653.6285.5.ca...@maxim-laptop> Content-Type: text/plain On Sun, 2009-07-26 at 18:41 +1000, Peter Hutterer wrote: > On Sat, Jul 25, 2009 at 08:29:40PM -0400, Jim Gettys wrote: > > I guess I'm still confused... > > > > So they'd show up as different devices with time; each time you get > > notification that the keysym mapping for the keycodes have changed. > > > > Why is there a problem? > > It makes things overly complicated. And besides, this even doesn't work. The older keyboard driver will read from underlying tty, while putting it in raw mode. It actually assumes it always talks to standard PC keyboard controller, (and kernel emulates it) And newer evdev will pass keycodes as is to X, thus only way around today is to make kernel driver remap the keycodes, and not all kernel drivers support this, and there is no standard way to set such. So, when we see 32 keycodes? Best regards, Maxim Levitsky > > We use a number of shortcuts to simplify the keycode handling. One is that > we don't actually use the keycode range as an actual range but rather use > the keycodes in a way similar to keysyms. If you're using the evdev driver, > each keycode is already defined to a specific symbol with hardware-specific > quirks being done in the kernel or in HAL (possibly udev now, I still > haven't looked into that). > > You could free the keycodes completely but then you'd have to have a Kcgst > mapping for xkeyboard-config for every single device. Which means that the > maintainance of xkeyboard-config becomes a nightmare, together with the > myriads of things that can go wrong when users select the wrong keyboard > model. > > By having a standardised set of keycodes this becomes much easier. > In fact these days it is irrelevant what you select as your keyboard model > in the evdev ruleset - they all map to the evdev model (there are a few > exceptions that do require separate models). So the XKB configuration mostly > deals with the actual layouts, taking one layer of complexity out. > > You could treat the keycode range as intended in the original X protocol, > but then you'd have to have a model for every keyboard, remote, magic other > device ever manufactured. We sort-of do that (look at the xorg/xfree86 > ruleset) but it's not pretty. > > So by upping the keycode range to 32 bits we enable a larger standardised > set of keycodes without the nightmare of maintaining loads of different > keyboard models and requiring the user to configure them correctly. > > Note that a keycode still doesn't stand for a symbol. KEY_Q is still an 'a' > if you have an azerty group. > > Cheers, > Peter > > > Alan Cox wrote: > > >> Ergo my question on whether anyone has ever actually seen in captivity a > > >> keyboard with more than 248 keys... > > > > > > I'm not sure that is a useful question. > > > > > > I have a collection of keyboards and remotes. All of them have different > > > functions above 255 which could be remapped. All of them are hot > > > pluggable. > > > > > > Trying to manage a mapping of all the devices randomly on the fly plugged > > > into a system and map them into a tiny space is rather more difficult > > > than you make out. > > > > > > If you had to map a set of devices, once, to a fixed mapping it wouldn't > > > be a big deal, but the world has moved on from that. > > > > > > Alan > > _______________________________________________ > xorg mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xorg ------------------------------ _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg End of xorg Digest, Vol 48, Issue 59 ************************************ _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
