Re: [iPAQ] Button/keycode mapping and handling

This message is clearly of general interest.

> Sender: ipaq-admin_at_handhelds.org
> From: "Merle F. McClelland" <mfm_at_cts.com>
> Date: Thu, 10 Aug 2000 19:18:24 -0700
> To: ipaq_at_handhelds.org
> Subject: [iPAQ] Button/keycode mapping and handling
> -----
> Today I was investigating the mapping of the external buttons to key
> events in the handhelds.org XServer sources. Currently, the keyboard
> driver in the server detects button presses, and translates them into
> various key events, using a mix of regular and XFree86 extended
> KeySyms. The latest XFree86 sources add a set of KeySyms that
> represent "macro" or "system" type keys and buttons found on newer
> keyboards and PDAs.
>
> I believe that only the input focus window receives these key events.
> That makes sense for the keysyms that map to normal key functions
> that applications would expect to receive (Up, Left, Right, and
> Down), since you would want the arrow keys to move the cursor around
> in a text editing window.
>
> But how are the keysyms that represent system functions, such as
> Record, to be handled in a way that is transparent to the window with
> the input focus? Presumably you don't want to have to code every
> program to know what to do with these special codes.

This is what a "grab" means in X terminology: an application can grab a
mouse or button independent of input focus. Then the event gets sent
to the grabbing client rather than to where the input focus is set.

>
> Is it assumed that it is the responsibility of the window manager to
> capture all KeyPress events on all client windows, and filter-out the
> extended codes? For example, if the window manager saw an incoming
> event containing any of extended codes, it would lookup what to do
> (presumably via a resource or config file) the appropriate action,
> perform it, and not pass the KeyPress event to the client window. All
> other KeySyms would be passed on to the focus application for normal
> processing.

A window manager might do so, or individual applications, or a mixture.

>
> Does this make sense (is it even possible?). Or is there some other
> method that would work on a global basis that allows for capturing
> these events and mapping them to the appropriate function? In the
> window managers I've seen, the XSendEvent is used to relay
> intercepted events, and this sets the send_event flag in the event.
> The downside to this is that I've seen some applications (e.g. xterm
> and Tk/TCL) ignore these synthetic events, so this might not allow
> the arrow buttons to work with such applications if they are
> intercepted by the window manager.

Usually SendEvent isn't what you want....
>
> For the LinuxCE MIPS VR41XX X11 environment I've been working with
> (which has a /dev/buttons device) I created two daemons. Both monitor
> the buttons device, and both have separate config files that tells
> each daemon what to do for each button.

You don't need a separate device and / or daemon: X can do what you
want by mapping the buttons to keysyms in concert with the "grab"
functionality.

>
> The system button daemon is designed to invoke processes, so its
> config file maps each button of interest to a Linux command line that
> gets invoked. For example, I set it up to invoke a shutdown handler
> for the Power button. The Record button might invoke an X record
> application. By default, the config file is set up to ignore the
> buttons that normally act like keyboard keys.
>

Yup. The appropriate app can "grab" the right button.

> Conversely, the X button daemon's config file is a button to KeySym
> lookup table. The daemon gets the KeySym for the pressed button, and
> looks up the KeyCode via the server for the specified KeySym. This
> KeyCode is sent to the server via the XTest extension, which in turn
> appears to the input focus window as a normal (nonsynthetic) KeyPress
> event. The X button handler is designed to handle the buttons that
> act like keyboard keys (up, down, enter, etc.), and thus its config
> file is set up to ignore the Power, Record, etc. buttons (but could
> handle them if desired).

You don't need all this hair: X can do what you want in the first place:
its input model is perfectly fine. Just give the X server the event
in the first place and let the window manager and/or clients sort it out.

>
> I'm not advocating changing the way the handhelds.org server handles
> the buttons, but I'd like to implement the appropriate support for
> handling the "system" key events in a way that allows for the user to
> remap what function is performed for each button (much like what is
> available under WinCE on many devices). I'd like to implement it in a
> way that works with the server design, and also doesn't require
> changes to regular X11 applications. Suggestions as to the proper way
> to do this with the ARM X server would be appreciated! Hopefully I'm
> not missing something obvious. :^)
>

No, this isn't obvious if you've not dealt with X before. Sorry you
spent time implementing something you didn't need to.
                                - Jim

--
Jim Gettys
Technology and Corporate Development
Compaq Computer Corporation
jg_at_pa.dec.com