xf86-input-synaptics:master: 1 commit(s)

[Peter Hutterer]

On Thu, Sep 11, 2008 at 08:44:01PM +0200, Sascha Hlusiak wrote:
> > I'd say XI_MOUSE is wrong. JOYSTICK would be good, alternatively you could
> > also think about having JOYSTICK, GAMEPAD, and whatnot, although as the XI_XYZ
> > atoms show too many aren't that great either.
> Isn't it more important for applications to know what _driver_ provides
> the device, so they know about capabilities and things to set? The
> _nature_ of the device seems only to be useful for displaying an image
> of what the device might look like. Even if mouse, kbd and evdev provide
> similar devices there might be a difference for the application. How are
> combo-devices (tablet with keys through evdev) recognized and exposed to
> applications? Isn't it dangerous for drivers other than evdev/mouse to
> export XI_MOUSE, even if it is a mouse?

My understanding of the spec is that it is merely a hint what the device is.
As you say, this may only be useful for a few things but I don't believe that
it should serve to expose which driver is running.

In theory, any device-specific modifications should respone with appropriate
error codes if the modification cannot be performed. Think of DeviceControls,
they both provide appropriate errors if you're trying to change on that isn't
there. Furthermore, there are quite a few settings that are provided by
multiple drivers anyway.
 
> > It does leaves the question - should we merge JOYSTICK (etc.) into XI.h as
> > defaults, or do you think it is better to provide them as part of the joystick
> > driver?
> For consistency and ease, I'm for merging it to XI.h.
> 
> But I don't think it makes much sense, if it is a per-driver setting.
> Leave it to the drivers then, that makes adding new types easier.

I tend to lean towards the XI.h approach, simple because it keeps the numbers
of different device types low. And there's the classic
monkey-banana-experiment reasoning: "because we've always done it like that"
:)

Cheers,
  Peter