input-evdev patch adding option to override XDevice type Atom, option to force EV_REL events being treated as absolute values.
Daniel Stone
daniel at fooishbar.org
Tue Mar 11 03:54:37 PDT 2008
[Greg, xorg@ is subscribers-only, so you'll get a bounce; sorry in
advance for the noise.]
On Tue, Mar 11, 2008 at 11:13:15AM +0100, Wolfgang Draxinger wrote:
> Am Dienstag, 11. März 2008 schrieb Daniel Stone:
> > The problem is that we don't want to encourage people to fix up
> > this kind of insanity in the evdev driver.
>
> And GKH tries to get rid of all quirks in the kernel, that's gonna be
> a circular dependency :-) I can already see his argumentation: "Do it
> in the user space. A program that uses event interface might so it
> just like this:
>
> if( EV_ABS == ev.type ||
> quirks_rel_absolute && EV_REL == ev.type ) {
> ProcessAbsEvent(device, ev);
> } else if ( EV_REL == ev.type ) {
> /* ... */
> }
Greg, true? (Background: Some devices send REL events when they really
mean to send ABS. Wolfgang suggested an option in xf86-input-evdev,
whereas I suggested that the kernel should just have a quirk table based
on vendor/device ID to deal with this itself and send correct events to
_all_ of userspace, not just Xorg.)
> > If you provide the
> > option, then people will come up with the most daft uses for it.
>
> So be it. I don't really see a problem there.
I didn't, but now I've seen the full gamut of awful 'solutions' people
are prepared to put up with.
> > You can use TimerSet/TimerCancel to fire arbitrary timers.
>
> :-) somehow this has slipped me grepping for timer
> in /usr/include/xorg
>
> ATM the headers are my only API documentation on X.Org server
> development, as I have found no in depth reference docs yet. At least
> the function names are obvious.
Yeah, we don't really have anything better, sorry.
> > Right, but the device database should be in the kernel, as a quirk
> > table.
>
> Well, put the functionality into the kernel: Yes
> Put the quirks table into the kernel: No!
>
> There's no need for a table in the kernel anyway, such things can be
> done with UDev in a perfectly safe way from userspace. The evdev
> would just need an aditional IOCTL, for setting the quirks,
> eventually with an additional IOCTL to freeze quirks settings for a
> device until it's unplugged/driver unloaded.
Umm, why would you have _two_ drivers? The point of evdev is to provide
an abstraction layer, so if you need to have layering violations to
provide userspace a way to say 'hey, I think your driver needs a fix,
please do _this_', then you have two drivers (usbhid in the kernel and
HAL or whatever in userspace), not one.
Quirk tables are all through the USB code[0], IDE, etc, already, so this
would be the accepted practice.
> > Have you got a link? I'd be interested in picking one up ...
>
> http://www.3dconnexion.com/buy/locate_reseller.php
>
> To know if there's a discount currently running somewhere, ask the
> little box in Google, or one of the resellers. OTOH this device is
> also affordable without a discount, costs less than a good Keyboard
> (good like in IBM Model M).
Okay, I'll get on it. Hopefully I can pick up a Wacom for a decent
price as well, as I'm trying to get back on the input bandwagon,
although I suspect my next few months will just involve XKB.
Cheers,
Daniel
[0]: On the hal list today or last night, I saw one for a GSM modem
which provided a CD device with Windows device drivers; the kernel
has a quirk to disable this and only provide serial.
-------------- 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/887fe430/attachment.pgp>
More information about the xorg
mailing list