On Mon, Dec 10, 2001 at 12:31:43PM -0500, Paul Fox wrote:
> > > and when xkb is disabled (which i assume is what XkbDisable does), where
> > > does the mapping come from then?
> > 
> > When XKB is disabled, the mapping comes from the OS; take a look
> > at programs/Xserver/hw/xfree86/common/xf86KbdLnx.c in xf86KbdGetMapping.
>
>thank you keith.
>
>i guess i'm beginning to understand.  a little bit.  :-)
>
>it seems the server will only map the scancodes it already knows
>about, since it starts from a known list of AT keycodes.  if a new
>scancode comes along, there's no way to get it mapped through to an X
>event.  :-(

The XFree86 keyboard code tries to pass through unrecognised
scancodes (see xf86PostKbdEvent() around line 402 of xf86Events.c):

  if (xf86Info.scanPrefix == KEY_Prefix0) {
    switch (scanCode) {

      ...

    default:
      xf86MsgVerb(X_INFO, 4, "Unreported Prefix0 scancode: 0x%02x\n",
                  scanCode);
      /*
       * "Internet" keyboards are generating lots of new codes.  Let them
       * pass.  There is little consistency between them, so don't bother
       * with symbolic names at this level.
       */
      scanCode += 0x78;
    }


and this seems to work for most keyboards with extra keys.  By
"pass through", I mean generate a keycode for them.  Mapping that
keycode to a keysym is done through xkb by default, with the mappings
for different keyboards described in xkbcomp/symbols/inet.  I take it
from your comments that no keycode is being generated in your case?

The XFree86 keyboard handling code does need to be rewritten.  It
has evolved over time from code that was written around ten years
ago, but has largely escaped several much-needed rewrites.  Probably
it's best feature at this point is that it does work in the vast
majority of cases on a range of platforms.

There are various strongly held opinions about how the code should
work.  My own opinion is that we should be making better use of
XKB rather than throwing it away because it's difficult to understand
and poorly/sparsely documented.  If integrated properly, it should
be easier for end users than many of the alternatives.

>in a different message, assuming xkb is enabled, you wrote:
>
> >  > > so, reading between the lines, i guess the mapping i'm looking for
> >  > > from hardware scancodes to X11 keycodes, in the XFree86 server, is
> >  > > hard-coded in a platform-specific driver somewhere?
> >  >
> >  > The mapping is all contained in keyboard specific files found in
> >  > /usr/X11R6/lib/X11/xkb.  The organization of those files is probably
> >  > only obvious to the original XKB authors.
>
>but again, since there are no scancode values in any of those files,
>i think there must be a hard-coded set of assumptions in this path
>as well.

At a very basic level, the file keycodes/xfree86 maps X keycodes
to key tokens that basically represent the key's location on the
keyboard.  The mapping files in the symbols directory map those
key tokens into keysyms in a manner that should be largely independent
of the keyboard/platform.  A combination of a keycodes file and a
symbols file gives the XKB keycode->keysym mapping.

David
-- 
David Dawes                                      Email: [EMAIL PROTECTED]
Founder/President, Release Engineer              Phone: +1 570 764 0288
The XFree86 Project, Inc                         http://www.xfree86.org/~dawes
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Reply via email to