tech-x11 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Xorg keymap and wskbd keymap

Hash: SHA1


On Jun 19, 2010, at 8:37 PM, Izumi Tsutsui wrote:

I'm looking at several sources around Xorg server keyboard driver
to switch several orphaned wsfb based ports from xfree86 to xorg.

In xsrc/external/mit/xf86-input-keyboard/dist/src/bsd_KbdMap.c
There are several wskbd keymaps (translating it to atKeymap?),
like wsUsbMap (ukbd), wsXtMap (pckbd), wsAdbMap (akbd) etc.

If we are going to add more other ports (like dreamcast, newsmips
do we have to add all machine dependent wskbd keymaps in this file
as old xfree86 servers have independent keymap sources?

Yes and no. We need to get rid of those MD wsevent codes anyway if we
ever want keyboard muxes to work properly ( as in - with devices using
different scancodes on the same mux, like an ADB keyboard and a USB
keypad. Right now there is no way to tell them apart. )
They should all emit USB scancodes since that seems to cover pretty
much everything.

Hmm, then what should actually be done for maple keyboard support?

1) add a map in bsd_KbdMap.c for maple keyboard keycode to convert
  it to AT keymap

That would probably be the easiest way to get a working Xserver.

2) modify maple (and all other) keyboard driver to emit pckbd compatible
  keycode in RAWKBD mode, as sys/dev/hpc/hpckbd.c does

I'd rather standardise the scancodes they emit in event mode so the Xserver doesn't need to know about different sets anymore. And for that USB seems to be the most sensible set.

3) add a magic to generate a map to translate wskbd keycode to keysym_t
4) or other?

I'm not all that familiar with the upper layers of wskbd - if there's a way to do it we probably should.

On dreamcast, a kernel can detect keyboard types (jp/us/uk) and
switches keymaps automatically. How should it be handled in
keymap translations in Xserver?

I think the same is possible with Sun keyboards and the driver doesn't really do anything about it - as far as I can tell the actual keyboard drivers have no real way to tell the upper layers about submodels or layout variants. That should probably be fixed too.

Is there any reason why we don't use wskbd(4)'s WSKBDIO_GETMAP ioctl
to get keymaps (with modifier) used in kernel?

The Xserver as it works right now would still need to know how to
interpret them. Or rather, the kbd driver would. The keyboard code
inherited from xf86 translates everything into something AT-like
before doing any further processing, that's what these tables are for.

In current wskbd(4) implementation, each wskbd drivers return
raw (device dependent) keycode and translation maps from keycode
to keysym_t can be retrieved by WSKBDIO_GETMAP ioctl
(though there is no document about these exported ioctls).

Then we should probably use them.

It looks WSKBDIO_GETMAP returns an array of struct wscons_keymap defined
in <sys/dev/wscons/wsksymvar.h> with device dependent keycode index.
struct wscons_keymap includes Cmd_foo values in the "command" member
and other keysym_t values in "group1[]" and "group2[]" members
(they include ones for normal, SHIFT, ALT, and ALT+SHIFT).

Xserver requires the similar translation maps, so with this ioctl,
I think the only thing we need is a translation map from
wskbd keysym_t (KS_foo) to X KeySyms (XK_foo) to generate keymaps
like one used in

Is there any problem to use it in Xserver?

None that I can see from here.

(I'm not sure if we can handle multiple keyboard that return different
MD keycode though)

Not through the mux device.

Or simply we should handle it in xkbcomp symbol files as hpcarm W-
(I don't know how files in external/mit/xkeyboard-config/dist/ symbols
should be declared though)

Didn't the xorg people declare xkb deprecated a while ago?

Probably I miss something (xkeyboard-config is not relevant to xkb?),
but Xorg server on hpcarm W-ZERO3 works with keymap files put in
without keymaps in bsd_KbdMap.c.

Hmm, looks more like I missed something ;)

have fun

Version: GnuPG v1.4.7 (Darwin)


Home | Main Index | Thread Index | Old Index