input-evdev patch adding option to override XDevice type Atom, option to force EV_REL events being treated as absolute values.

[Daniel Stone]

Hi,

On Tue, Mar 11, 2008 at 12:51:50AM +0100, Wolfgang Draxinger wrote:
> last week I got one of those nifty spaceballs from 3Dconnexion and 
> started implementing support for Blender. There's been another 
> project with the same goal, and my first attempts to use it failed. 
> For two simple reasons: The Linux Event API doesn't tell us, what 
> kind of device is connected, other than product and vendor ID* so 
> evdev simply uses the atom MOUSE for everything that provides 
> valuators. Since a spaceball is not a mouse and the type Atom is 
> simply a string I figured it might be a good idea, to have an option 
> to override the atom determined by the initialization code.
> Option "ForceType" "whatever"
>   *) Actually I think it might be a good idea to have such as a option 
> of the X.Org core, so that this can be done with all input devices.

Sounds good, thanks. :)

> The other problem I had was, that the 3Dconnextion SpaceNavigator 
> sends relative motion events (already in the USB-HID protocol) and 
> Linux just passes this on. However technically a spaceball is a "6DOF 
> joystick", which generates absolute values. Since the Linux kernel 
> can't tell if the stuff sent by USB-HID devices is what it should be, 
> it's upon the program reading the events (i.e. the X.Org driver), to 
> process them correctly. So another option
> Option "ForceAbsolute" "True|False"
> which will make EV_REL events generate absolute motion events.

This really belongs as a quirk in the kernel (just have a vendor/device
ID quirk table), rather than in the driver.

> As a further suggestion, I'd like to throw in the idea of a device 
> database that ships with input-evdev, from which it reads device 
> parameters (like ForceType, ForceAbsolute) based on the IDs reported 
> from the OS.

Well, the kernel should do pretty much all of it as quirks, but we
already have a device database called HAL, which can provide arbitrary
information.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20080311/e3fac821/attachment.pgp>