[ANNOUNCE] xf86-input-mouse 1.4.0
daniel at fooishbar.org
Wed Jan 21 21:13:02 PST 2009
(Sorry for the late reply.)
On Wed, Jan 14, 2009 at 01:39:30PM -0800, Alan Coopersmith wrote:
> Daniel Stone wrote:
> > Erm, any reason to not just write a new driver? Some of evdev's features
> > (e.g. middle-button emulation, et al) could probably be moved into the
> > server after careful review and successful use by n > 1 drivers.
> Besides the obvious lack of time, I'm not sure what writing a new driver
> buys me over updating kbd & mouse. I'd lose the BSD & SCO code, but also
> lose the shared maintenance from the BSD guys helping fix it. I could
> probably live without all the ancient code to speak all the different
> ancient dialects of serial mouse, but it hasn't bothered me enough to nuke
> it and hose the three people out there who still have one.
> Either way I think looking at what code in evdev should be common to evdev,
> vmmouse, and either keyboard/mouse or new drivers would be worthwhile.
So I've been deleting half of the kbd driver while swearing at the
remaining half. (Describe the LED handling in 50 words or less.)
I assume Solaris has an API resembling evdev? If so, you could bring
Solaris up to feature parity with Linux by writing a driver to use the
native support there, and you wouldn't have to deal with that absolute
trainwreck of a driver.
Seriously, kbd_drv is the worst piece of X code I've ever seen. This
is including XKB, the loader, xtrans, and cfb8line.c. And that's even
without considering the fact that the entire src/kbd.c has a mixture
of two, three, four, and eight-space indentation. In the same
CRUSH. KILL. DESTROY.
Daniel, studiously not putting his fist through his laptop as he reads
more of src/kbd.c
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: Digital signature
More information about the xorg