X input and multimedia keyboards roadmap

What exists and what needs to be done.


Current situation, standard driver, AT keyboard and softraw=0

1. Kernel sends AT codes

   1.1 Drops key codes above 240

2. X detects AT keyboard and using rules/xfree86 it converts keycodes
   to internal 4 byte IDs without any relation to its meaning.

3. X maps internal 4 byte IDs to key symbols using one of tables in
   symbols/inet definitions altogether with national key mapping.

What is bad:
- inet decoding in too high level
- Codes above 240 are lost
- 4 byte IDs have no meaning
- Obsolete mode for 2.4 compatibility


Current situation, standard driver, softraw=1 or non-AT keyboard

1. Kernel detects keyboard and sends AT codes

   1.1 In case of AT keyboard, if nobody cares about calling of
       setkeycodes, it assumes MS Multimedia and detects key names.

   1.2 In case of USB, BT, RC or embedded keyboard it detects layout
       and key names.

   1.3 For unknown key codes it drops them.

   1.4 Drops key codes above 240.

2. X detects AT keyboard and using rules/xfree86 it converts keycodes
   to internal 4 byte IDs without any relation to its meaning.

3. X maps internal 4 byte IDs to key symbols using one of tables in
   symbols/inet definitions altogether with national key mapping.

What is bad:
- inet decoding in too high level
- Codes above 240 are lost
- 4 byte IDs have no meaning
- Translation AT code -> MS Multimedia button -> AT code -> 4 byte ID
  -> key symbol is lossy


Current situation, evdev driver

1. Kernel detects keyboard and sends evdev key names

   1.1 In case of AT keyboard, if nobody cares about calling of
       setkeycodes, it assumes MS Multimedia and detects key names.

2. X decodes evdev keys using rules/evdev to internal 4 byte IDs

3. X maps internal 4 byte IDs to key symbols using evdev table in
   symbols/inet definitions altogether with national key mapping

What is bad:
- 4 byte IDs are ugly
- tables are not correct and cause lossy translation
- evdev driver may contain bugs


Proposed situation, standard driver, AT keyboard and softraw=0

1. Kernel detects keyboard and sends AT codes

   1.1 It drops key codes above 240

2. X detects AT keyboard and using rules/xfree86+inet(foo) it converts
   keycodes to internal 4 byte IDs unique for each key.

3. X maps internal 4 byte IDs to key symbols using map defined in
   "basic" symbol table.

What needs to be done:
- Convert symbols/inet symbols to rules/inet_at

What is bad:
- Codes above 240 are lost
- Obsolete mode for 2.4 compatibility


Proposed situation, standard driver, softraw=1 or non-AT keyboard

1. Kernel detects keyboard and sends AT codes

   1.1 In case of USB, BT, RC or embedded keyboard it detects layout
       and key names.

   1.2 In case of AT keyboard and MS Multimedia incompatible keyboard,
     user must use setkeycodes.

   1.3 Drops key codes above 240

2. X detects AT keyboard and using rules/xfree86+linux_inet it
   converts keycodes to internal 4 byte IDs unique for each key.

3. X maps internal 4 byte IDs to key symbols using map defined in
   "basic" symbol table.

What needs to be done:
- Convert symbols/inet symbols to setkeycodes table
- Create rules/inet_linux

What is bad:
- Codes above 240 are lost
- Complicated button press path


Proposed situation, evdev driver

1. Kernel detects keyboard and sends evdev key names

   1.1 In case of AT keyboard and MS Multimedia incompatible keyboard,
     user must use setkeycodes.

2. X decodes evdev keys using extended rules/evdev to internal 4 byte
   IDs

3. X maps internal 4 byte IDs to key symbols using map defined in
   "basic" symbol table.

What needs to be done:
- Convert symbols/inet symbols to setkeycodes table

Everything is OK.


What needs to be done in any case

- Create 1:1 mapping Linux key name -> 4 byte ID -> X Key Symbol