Re: [linux-usb-devel] Hotplug Driver Interface to User Level Programs: A Driver Example

[Linas Vepstas <linas@austin.ibm.com>]

On Sun, Sep 12, 2004 at 04:33:13AM +0400, Alexander N. Kozhushkin was heard to remark:
> 
>     Unfortunately, now I cannot present  a full list of device drivers
> which   use   the   first   and  second   approaches.   However,   the
> "drivers/input/mousedev.c"  file by  Vojtech Pavlik  is an  example of
> such a device driver. It  offers the first approach for the mouse-like
> devices with  the minor numbers from 0  to 30, and the  second one for
> the so-called "MOUSEDEV_MIX" device with minor number 31.
> 
>     Here is a  patch for kernel 2.6.7 which makes  that driver use the
> third approach for the devices  with minor numbers 0--30. Most likely,
> the patch  can be used  for kernels 2.6.8  and 2.6.9 too.  The archive
> "tests.tgz" contains some  very simple programs to test  the patch and
> the  original mouse  driver. The  description  of the  changes to  the
> "mousedev.c" file can be found in the "patch.txt" file.

Please don't gzip the patches, and please use 'unified diff' format 
(diff -up), this makes it easier to read the patch.

>     The  'gpm' program, properly  rewritten by  me to  support hotplug
> mice,  and the  above  tests work  reliably  on my  computer with  the
> modified mouse driver. The X-server  works reliably too if it uses the
> data supplied  by the  modified version of  the 'gmp', instead  of the
> real mouse data.

What happens if the x-server is connected directly to the mouse?  Can
I unplug one mouse, and plug in a different mouse and still have it
work?  I think you might want to cc the appropriate mailing list on
x.org about this. 

---
Another alkternative to returning -ENODEV is to have a zero-length read.
This is a traditional unix way of signifying that the remote end has
disconnected; e.g. for tcp sockets.  That is, select() will tell you
that there is something to read, and the read() call will suceed
(without error), and return zero bytes read.  For tcp, this is
understood to mean that the far side has closed its socket.

I'm not sure, but maybe this would also make sense for any USB device
that can be read with open(), read() calls? 

--linas



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel