How to customize input device behaviors?

[Peter Hutterer]

On Mon, Jun 03, 2013 at 02:16:53PM -0700, Alex Stewart wrote:
> I've recently started using a Monoprice MP1060-HA60 (aka UC-Logic TWHA60)
> graphics tablet, which thanks to the (really cool) DIGImend stuff, worked
> right out of the box using the evdev driver on my Ubuntu 13.04 system..
> 
> There are a couple of things I'd like to be able to do with it which X.Org
> doesn't appear to support by default, though:
> 
> a) I'd like to change "mouse" buttons 2 and 3 (the buttons on the pen) to
> act as "modifiers" instead of buttons, such that to press the middle button
> I would hold down the appropriate pen button and then tap the pen tip (i.e.
> button 2 = nothing by itself, button 2+1 = middle click/drag), etc.
> 
> b) Use a strip of the tablet active area (for example, the top 3/4 inch)
> for a bunch of "soft buttons", which could appear as keyboard keys, (or
> extra buttons, or something), which could then be mapped to application
> functions.

> I've looked around and don't see any software out there that seems to do
> either of these things already, so I've started looking at hacking
> something up myself. The problem I'm having, however, is that there are so
> many levels to the Linux/X input subsystem that it's not clear to me the
> best way to go about this sort of thing.
> 
> The options I see thus far:
> 
> 1. Modify the kernel evdev driver
> 
> 2. Create a userland utility which reads from the actual evdev device and
> uses uinput to fake a "wrapper" device which Xorg then reads from instead
> 
> 3. Modify the Xorg evdev input driver
 
'problem' with both a and b is that from an X perspective that device suddenly
not only has axis and buttons, but also keys. they need to be set up
correctly, mapped, etc. most of the bugs we had regarding dual-function
devices are now sorted, but there's still the odd bug here and there.

I'd really rather see this handled on the client side, because X shouldn't
be messing with this other than forwarding the button event to the right
client.
 
> 4. Write a new Xorg input driver specifically for evdev-based tablets

no. seriosly, more pain than it's worth.
 
> 5. Add support for these tablets to the wacom driver, and then add this
> functionality to the wacom driver
> 
> 6. Write a utility which uses Xinput2 to detach the tablet pointer device,
> filter the events, and re-insert them using another "fake" device
> (basically the same as option 2, but per-user-session inside the X server)

That's essentially what gnome does.

> 7. Try to add support for this sort of thing to GTK/Qt/etc instead

there's a bug open in the gnome bugzilla regarding semantic events. Reason
is that most of the time users don't want to have a key event when they
press a button, the rather have it trigger some functionality in the
application. Thus, rather than have a button trigger ctrl+z usually users
want this button mapped to 'undo'. semantic action events would cater for
this but aren't close to being implemented yet. Can't find the bug number
either, sorry.

Cheers,
   Peter

> All of these options seem to have pros and cons, and it's a little unclear
> whether there's a "best" or "preferred" way to do the sort of input
> filtering I want to do (or if I'm missing something entirely), so I was
> hoping there were some folks out there with more experience in this area of
> things who might be able to offer some advice on how I should approach this?
> 
> -alex