Mapping pointer events to keys and the other way around?

[Peter Hutterer]

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 
configurable.

Cheers,
   Peter