Mapping pointer events to keys and the other way around?

[Peter Hutterer]

On 28/03/11 21:56 , Michal Suchanek wrote:
> On 28 March 2011 12:56, Peter Hutterer<peter.hutterer at who-t.net>  wrote:
>> 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.
>
> I don't see why there is a need to send keycodes rather than keysyms.
>
> The keysyms are what the user wants, not the keycodes.

see Julien's reply.

>> 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.
>
> Configurable to the point that when I press mouse button 1 on "Lite-On
> Technology USB Productivity Option Keyboard" the screen locks or when
> I press mouse button 8 on the same device it produces the string "©
> 2011 Michal Suchanek"?
>
> I don't think this is going to work yet both are quite valid use cases
> for the additional buttons on the keyboard that produce mouse clicks
> for some reason.

just because there's a valid use-case for it doesn't mean we have to 
support it.

Cheers,
   Peter