Moving os-support/*/*_mouse.c to mouse input module?

[Adam Jackson]

On Thursday 21 July 2005 03:03, Matthieu Herrb wrote:
> Moreover, moving the os-specific code into the mouse driver will
> encourage other input modules to directly talk to os-specific functions
> to access the hardware and prevent them from being portable to different
> systems. (I know that this is already done today by some os-specific
> input modules, but I'd better see these module fixed to use a OS-neutral
> API to access the underlying hardware).

I can sorta see the argument there.  But my gut feeling is, if you have to 
have this support code in the server to support exactly one loadable but 
nothing else within the server, and the loadable doesn't work without it, 
then why didn't you put it in the loadable in the first place.

In the case of the solaris mouse code, we end up duplicating much of the 
loadable mouse code anyway, and occasionally doing it wrong.

The obvious non-portable input driver is evdev.  If you refactor that to do 
its work through generic input support exposed through the kernel, what have 
you won?  (Besides yet another translation layer.)  evdev still won't work on 
anything but linux because there's no equivalent functionality anywhere else.

On the other hand, fbdev versus wsfb should maybe possibly be one driver.

As a practical matter we don't have a consistently enforced policy here.  I'm 
not completely convinced either way.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-modular/attachments/20050725/a0693dec/attachment.pgp