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

[Hans de Goede <j.w.r.degoede@hhs.nl>]

kilgota@banach.math.auburn.edu wrote:
> 
<snip>

>> Uhg, with 352x288 @ 30 fps (and yes some cams can do 30 fps at 
>> 352x288) this translates to 792 ms of each second being used just for 
>> the demosaic phase.
> 
> Yes, I know that some cameras can do 30 fps. I would also assume there 
> are cameras which can do much more than that. So one needs to be more 
> clever.

Well assuming 352x288 @ 30 fps for cams *which send raw bayer* seems like a 
good assumption, anything higher resolution usually uses jpg.

<snip>

>>
>>> Relative image quality of the methods:
>>>
>>> 1. straight bilinear interpolation is lousy on this image. Lots of 
>>> zippering.
>>>
>>
>> Ok, then maybe we do need to get something better.
> 
> If you want to see the results of this on the same photo that I was 
> using for the test, then you should go to my web page 
> www.auburn.edu/~kilgota and look at the comparison photos and also have 
> a look at the article which has done comparisons of the various methods 
> on the same photos, too.
> 

Ok, I went and looked at the article, I do see there is a huge difference 
between plain bi-linear and bi-linear with acrue edge detection. I must say the 
difference between bi-linear with acrue edge detection, and ahd is less 
convincing though.

>> It might just be that your system is slow, but if it turns out that 
>> bayer.c from libv4l is much faster then the bilinear code from 
>> libgphoto2, then IMHO going to AHD is speedwise not a good idea.
> 
> My system is an AMD Sempron 2600+ or 2800+ (forget which, and I am at 
> work, not at home) with 1 M of RAM. Not the fastest thing around, but 
> not slow at all, actually. We will just have to see what the libv4l code 
> does. I don't know yet.

Ok, that should actually be pretty comparable to one of the 2 cores of my dual 
core amd64 when clocked at 1Ghz (the default setting when not more is required, 
yeah for speedstep). So I think that libv4l's bilinear is much faster than, but 
that is not strange as it was written with speed in mind.


> Where I am coming from is, libgphoto2 uses libusb. When a kernel module 
> has "taken over" the device, then as things currently stand, or have 
> stood until recently, libgphoto2 has no access to the device unless and 
> until the kernel module has been rmmod-ed. I understand that there is a 
> partial solution for this. I am trying to figure out how there is a 
> complete solution which would make everyone happy, including users who 
> just want to plug in their cameras.
> 

I understand, but I'm afraid I don't have any answers here, I'm not familiar 
enough with the relevant usb stuff.

>> Basicly whenever we have a video input device, we want to have a 
>> kernel driver, so as to present a standard /dev/videoX device to 
>> userspace, so that all apps written for v4l can use the device.
> 
> Yes, that is quite clear. But insofar as the act of loading the kernel 
> module which creates that device causes the still camera functionality 
> of the same camera to be simultaneously inaccessible to the usual apps 
> which deal with stillcam mode stuff, we have a problem. The worst aspect 
> of the problem is, of course, that we have a bunch of people whom we 
> would like to convince to use our nice operating system, and they do not 
> understand why there has to be a problem because they do not face that 
> kind of problem if they are not using Linux.
> 

All I can say is: again I understand.

>>
>> However we do not want to do video format conversion (let alone 
>> decompression) in kernel space, so if the data is in an exotic format 
>> we simply indicate this in the pixelformat member of the exchanged 
>> structs, and let userspace deal with it.
>>
>> This is where libv4l comes in into play, libv4l is a convenience lib 
>> for applications, which can do conversion for them so that the app 
>> writers do not have to add support for each exotic webcam format 
>> themselves.
> 
> This is obviously a good idea. I can't imagine that anyone would have a 
> problem with it. Certainly, I don't. But my questions were about how to 
> address the userspace-kernelspace conflict which takes place when we try 
> to support dual-purpose devices, in which one of the modes requires 
> kernel support and the other mode does not.
> 

All I can say is: again I understand.

>> libusb does not interact with a kernel module for a specific device, 
>> it interacts directly with the device through the usb subsystem,
> 
> Indeed. The two lines above capture precisely what needs to be 
> addressed. The current situation certainly is described by 'does not.' I 
> am well aware of the 'does not.' Otherwise, I probably would not ask 
> 'why not' or, more precisely, 'what prevents.' So, back to the original 
> problem:
> 
> For a dual-mode device such as most of the cameras that I support in 
> libgphoto2 in stillcam mode, and you are trying to support in webcam 
> mode, this 'does not' causes nasty problems for the user, doesn't it?

Agreed.

> So 
> we should not ignore such difficulties but try to figure out how to 
> avoid them or work around them.

Agreed.

> Thus, possible solutions (at least so I 
> could imagine) are that libusb is changed, so that it is willing to 
> interact with the kernel module, or that the kernel module is so 
> constructed that it can run in some kind of 'pass-through' mode and 
> libusb can go ahead and access the device anyway, or libgphoto2 camera 
> drivers are changed so as to address a kernel module if it is present 
> instead of addressing the device directly through libusb.

I agree (and still understand) but I'm not aware of a way for a device driver 
to give up his claim on an usb device, perhaps such an option exists in the 
kernel usb subsystem, then adding an API to ask v4l to release the device 
should be possible, although IMHO not the best way forward, how I envision this 
to work is:

usb-drivers get 2 new optional driver callbacks which the usb-subsystem can 
call, called :

1) release_device() this returns 0 if the device is not in use, and disallows 
any new users from using the device through the driver (iow disallow new open's 
of /dev/videoX in our case).

2) reclaim_device(), the driver may now use the device again and allow users to 
open it.


The usb kernel<->userspace API used by libusb gets a new API, which makes it 
possible for libusb to send a release request to a driver holding a device

If the driver has release_device implemented and returns 0, the usb subsystem 
will allow libusb to use the device even though there is a driver for it,

When libusb is done with the device (closes the relevant filedescriptors, the 
drivers resume_access() method gets called.

Notes:
1 this is all a figment of my imagination / vaporware.
2 I think we must come up with something more KISS


Ok, so looking for a simpler solution, there is an kernel usb subsystem method 
called:
usb_driver_release_interface()

And another called :
usb_driver_claim_interface()

Using these 2 a driver could release a device when requested and then later 
(when told to) reclaim it.

No idea how well this will work though, and when we solve this completely at 
the driver level we will need some (none generic) driver API for libgphoto2 to 
ask us to release the device (and tell us whem it is ok to reclaim it).

Regards,

Hans

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