(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.
Hi, 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 functions. CRUSH. KILL. DESTROY. Cheers, Daniel, studiously not putting his fist through his laptop as he reads more of src/kbd.c
signature.asc
Description: Digital signature
_______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
