> >> What I cannot find is *where* those fake scancodes are generated
> >> and how they are mapped to 0x81-0x84....
> Ivan> xc/programs/Xserver/hw/xfree86/common/xf86Events.c
> Ivan> xf86PostKbdEvent() subroutine
> Ok.  From that it looks like I need e0/01 thru e0/04, but as far as I
> can tell, X does not see real raw codes from linux, but must reverse
> engineer them.  

Excuse me, you are talking something about raw-codes, emulated scan-codes
and X's keycodes, etc. but I still can't (my fault) understand what codes you
have and what keycodes you want to get from the Xserver.

Let me explain.
1. Xserver gets key codes from the 'system' keyboard driver.
2. The system keyboard driver (that works in a 'console' mode) was firstly
designed for an AT keyboard.   I means it produces simple one-byte scan-codes
for most of keys (such as alphabetic keys) and 'extended scan-codes' that
are a prefix code 0xE0 and some other code, for some additional keys.
3. The X's keyboard driver has to convert all scancodes it get from the system
driver to one-byte codes named "keycodes".
4. The X's driver assumes that one-byte scan-codes don't cover all range of
one-byte values (0-255) and there is some gap of such values that can be 
used for the 'extended' scan-codes.  Therefore it converts 0xE0+smth extended
scan-codes to one-byte codes that (as it assumes) can't be generated by
a keyboard as one-byte sacn-codes.  For such conversion the X's driver uses
a 'switch' statement although a simple table can be used for that task.

Unfortunately, keyboards that have some extra keys (such as 'Internet keys')
can generate for such keys one-byte scan-codes which are codes from the range
that Xserver driver uses for the extended keys.

Thus the algorithm of the X's keyboard driver is:
- get a scan-code from the sytem driver
- if it is 0xE0 code, remember this fact and get the next code
- if a code is a continuation of an extended scan-code (0xe0 is already
  received) recode it to some one-byte code using a special table (actually
  a switch statement does it);
- if the code is a single one-byte code there are two ways
  - if it isn't one that can fall into range used for a representation of
    the extended scan-codes, it goes to the next step without any changes
  - otherwise (the code is one from range of the values used for
    a representation of extended scancodes) it is also converted to some
    other code (by a switch statement).

And finaly the the X's keyboard driver adds 8 to each code got from the
previous step.

Lets return to your Linux.  If it use non-AT keyboard the Linux  keyboard
driver anyway emualtes 'raw scan-codes' as if they are got from an AT keyboard.

Thus if it emulates for additional keys (that the current X's driver doesn't
recognize) extended scan-codes, you have to update the table (actually a
'switch' statement) that converts extended scan-codes to X's keycodes.
But if the system driver emulates for the extra keys one-byte codes:
- you should do nothing (but remember that the keycodes the Xserver generates
  are greater by 8 than the sacn-code it got from the 'system' driver)
- or (if the keys ommit the keycodes that are in range used for extended
  scan-codes) update the table (a 'switch' operator again) that converts such
  codes to another ones that are not used for a representation of the extended

And now, what do you have and what do you want?

What codes the Linux driver emulates for your extended keys?
What problem do you have with their conversion to keycodes?
What keycodes you would like to have for your keys?

 Ivan U. Pascal         |   e-mail: [EMAIL PROTECTED]
   Administrator of     |   Tomsk State University
     University Network |       Tomsk, Russia

Devel mailing list

Reply via email to