Re: Xorg keymap and wskbd keymap

[Matthieu Herrb <matthieu.herrb%laas.fr@localhost>]

May I try to share my views on the subject ?

- 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
  anymore.

- 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.
-- 
Matthieu Herrb