Mapping pointer events to keys and the other way around?
peter.hutterer at who-t.net
Mon Mar 28 03:56:25 PDT 2011
On 28/03/11 20:09 , Michal Suchanek wrote:
> On 28 March 2011 07:20, Peter Hutterer<peter.hutterer at who-t.net> wrote:
>> On Thu, Mar 24, 2011 at 02:08:44PM +0100, Michal Suchanek wrote:
>>> There was some Wacom-specific support in their driver but that does
>>> not work for plain mice and is probably non-functional in current
>>> version of the driver anyway.
>>> Is there just documentation missing in xinput(1) and evdev(4) or is
>>> there no such feature?
>> no, it's a wacom-specific feature and quite painful to maintain anyway. I
>> don't have any plans to add this to any other driver, it's too flimsy.
> The fact that this is a feature specific to the wacom driver and not
> supported in the X server/xinput is most likely the reason why it is
> so flimsy and painful to maintain. The driver developer has to compete
> with X internals changes to keep this feature working.
no, it's because it's simply a pain. once you start dealing with keys,
you have to start dealing with keyboard layouts, at which point you have
to deal with modifiers. it's quite trivial to make the driver spit out
keycodes (after all, any keyboard does it), but people would rather
configure it as "ctrl shift a", or whatever. and that again depends on
the layout. I'm not saying it's impossible, it's merely annoying, a
source of bugs and a questionable use case to begin with.
Because in the end, what you're trying to do is to cope for missing UI
features by adding a hack to the driver. Hardly any configuration I have
seen so far wants the button do send "ctrl +". They want the button to
zoom, but that's only possible by making it send "ctrl+". The right fix
to the issue is to fix the applications so that button actions are
More information about the xorg-devel