Hi,
> >> 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
scan-codes.
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
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
