Make EVDEV a driver which is acutally useful

[Peter Hutterer]

On Mon, Aug 30, 2010 at 10:14:10AM +0200, 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. 

I disagree that it will solve the problem. Once you start mapping axes to
buttons or buttons to axes, etc. you start having to deal with repeats,
delta movements, possible friction, etc. So instead of that simple axis to
button mapping, you end up having a zillion configuration options to make it
useful for the next person.

fix these things in the clients is what I'd recommend.

Cheers,
  Peter

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