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