Re: [sqcam-devel] Advice wanted on producing an in kernel sq905 driver

From: Adam Baker <linux@baker-net.org.uk>
To: sqcam-devel@lists.sourceforge.net
Cc: video4linux-list@redhat.com, kilgota@banach.math.auburn.edu
Subject: Re: [sqcam-devel] Advice wanted on producing an in kernel sq905 driver
Date: Sat, 22 Nov 2008 00:05:34 +0000	[thread overview]
Message-ID: <200811220005.34321.linux@baker-net.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.64.0811211658290.4727@banach.math.auburn.edu>

On Friday 21 November 2008, kilgota@banach.math.auburn.edu wrote:
> > Unfortunately libusb doesn't include a
> > corresponding attach method for libgphoto2 to use when it has finished so
> > it can't re-instate the kernel driver.
>
> True. But what I am wondering is, if it would be possible to write the
> kernel driver in such a way that it does not need to get detached, then it
> would be possible to solve the problem in both directions,

I don't believe that that is possible because if I understand correctly libusb 
detects that a driver has been loaded that has claimed that device and so it 
needs to be involved in the communication to get the kernel driver to allow 
access.

To acheive what you are suggesting the kernel driver would have to return 
false from its xxx_probe routine and not create it's endpoints but still call 
video_register_device to create the /dev/videox dev file. The problem is I 
don't believe there exists a mechanism whereby it could then obtain access to 
the USB device within it's xxx_open routine and it certainlywouldn't receive 
USB disconnect events so couldn't clean up properly.

The libusb attach/detach mechanism definitely looks like the cleanest solution 
if we can get a shipping version of libusb that implements attach.

Adam

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list