Make EVDEV a driver which is acutally useful

[Oldřich Jedlička]

On Monday 30 August 2010 10:14:10 ManDay wrote:
> I'm deperately trying to solve a real world problem that is. Many
> applications do not have such sophisticated methods to use input devices
> (in my case: GIMP). If X/evdev gave me the option to arbitrarily remapw
> anything to anything (or just axes->buttons, for that matter) it would
> solve this problem for all these programs alltogether. the problem i see
> with evdev is simply that its not gerenic enough. i said that evdev has
> no "proper" support for enhanced devices because most of its options can
> only be used for X and Y axes and nothing beyond.

Can this comment be translated to a request to have a daemon translating mouse 
events to key events? For example translation of some mouse axe movement to 
key press/release? Or any other translation for events that the application 
cannot handle (depends on the application)?

Because as I understand it the X server provides just enough information for 
the application to handle the event. If the application cannot handle it, it 
doesn't look like an X server problem to me...

I'm not an X server developper, so I actually don't know if such daemon can be 
easilly written (capture mouse events, detect the application that should 
receive it and send translated key events to that application).

Maybe this is a nonsense, but those are just my 2 cents.

Cheers,
Oldřich.

> --MD
> 
> 
> On 08/30/2010 01:13 AM, Peter Hutterer wrote:/
> 
> > On Fri, Aug 27, 2010 at 02:48:22PM +0200, ManDay wrote:
> >> Currently the EVDEV driver for axes-input-devices has just a few
> >> pathetic options which are at best suitable for a mouse. But since there
> >> are more input devices beyond mice and 2 axes joystick X appears to have
> >> no proper support for them, whatsoever.
> > 
> > what's your basis for the "appears to have no proper support" argument?
> > evdev takes whatever the kernel provides, labels axes accordingly and
> > forwards events. Please provide an actual use-case of what is broken
> > right now, I'm quite happy to get evdev fixed for that case.
> > 
> >> Since last time I contacted the list with that issue, where I was more
> >> concerned about getting a generic HID driver which can handle it all
> >> properly, people were little eager to get into that, I think I'll try
> >> with something easier which even I could try myself at.
> >> 
> >> The only aim I set myself so far is supporting an arbitrary amount of
> >> axes in analogy to evdevs XYAxisMapping.
> >> 
> >> That means, an arbitrary axis can emulate a button (or eky, for that
> >> matter) of one's choice. It shouldn't be too difficult, generalizing
> >> what evdev does for two axes already.
> > 
> > why do you need this? mapping axes to buttons comes at a cost
> > (maintaining that code) and there's a high chance that this option
> > should rather be supported in the clients than in the driver.
> > 
> >> I hope you guys can give me tips where to start or whatever you can
> >> think of. Should I enhance the evdev driver to become more generic and
> >> support an arbitrary amount of axes or would it be better to write
> >> something like xmodmap which cannot only remap key but can also map
> >> keys/buttons to motion events?
> >> 
> >> So I get a motion even, say a 6 tuple and translate it to an arbitrarily
> >> reformatted motion event plus additional keystrokes.
> >> 
> >> if such a tool already exists it would be great, if not i think it will
> >> be extremely useful and can do almost anything you want, not to mention
> >> will deprecate the pathetic evdev and xmodmap.
> > 
> > again, _why_ do you want to do this? the wording chosen make it appear
> > like you're doing it out of academic interest, not to solve a real-world
> > problem. I care much more about the latter than the former.
> > 
> > Cheers,
> > 
> >   Peter
> > 
> > _______________________________________________
> > xorg-devel at lists.x.org: X.Org development
> > Archives: http://lists.x.org/archives/xorg-devel
> > Info: http://lists.x.org/mailman/listinfo/xorg-devel
> 
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel