- the use of PC-AT inspired keycodes in X for all systems was a design
decision back in the XFreee86 times. It helped to keep the xf86 DDX
code for the non-xkb case simple.
But, given the limitations of this encoding (terrible "extended"
keycodes, lack of standard mappings for extra keys,...) this was
probably a mistake.
- Since then X.Org and Linux have gone a different way. Linux has
changed its console driver to provide a real event model: evdev
(similar to what sun vuid events or wscons event did for years). And
a new X input driver was developed to support it:
xf86-input-evdev. This driver doen't use PC-AT keycodes anymore.
At the same time, the X server has made XKB mandatory, and
xkeyboard-config is beeing maintained with the ability to handle
different keycodes tables without adding more code to the DDX.
So nothing in the current X.Org X server mandates PC-AT keycodes
- So I've been thinking about moving away from xf86-input-keyboard for
wscons too. This means writing a new xf86-input-wskbd input driver
(or add keyboard support to the existing xf86-input-ws driver
which can already replace xf86-input-mouse for wsmouse). This
driver, together with a set of xkb keycode descriptions would allow
to simplify the keyboard mapping process, by removing the
extra-layer of going through this awkward PC-AT emulation.
- In the context of the X server, wsmux is a terrible design
choice. It hides all keyboards behind one single device, with one
single keymap. With XInput2 and XKB, the X server has the
opportunity to configure each keyboard individually (with different
layouts for example, which is one of the reasons I sometimes keep 2
keyboards connected to a machine). Thus I think that BSD kernels
should either give up on wsmux or change the mux protocol to add an
identifier of the device that originally generated the event.
BTW the same remark applies to wsmux for pointing devices (wsmouse).
So if someone wants to grab the flag, and start implementing a wscons
specific X input driver, you'll have my support.