A couple of questions

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
I've begun the working investigating the possibility of converting the m5602 driver to the gspca framework.
I currently have the following questions:
1) From my understanding each driver implementing the gspca framework has a static list of v4l2 controls. In the m5602 driver, each sensor has its own set of v4l2 controls with different resolutions.
Is there a obious solution to this problem?

2) In the sd_desc struct, is it necessary to implement the dq_callback or does the gspca driver automagically requeue buffers?

Thanks,
Erik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFI19rhN7qBt+4UG0ERAl5wAJ9J/6kc6A2xYivmvl2hkT80ZVv0pgCfVSHR oVCp/TzbqoqPOo7l6bS3Ifk=
=Ky0r
-----END PGP SIGNATURE-----

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Great! You rock, really you do :)

Yes and no, for now the solution is to make your sd_desc non const and update the ctrls member to point to the right array. In the future I want to add a const struct sd_desc *sensor_ctrls to the main gspca struct, which you can then set at probe time, as there are more subdrivers with this issue.

Feel free todo that now in your patch if that suits you. My idea is to have per bridge controls in sd_desc, and per sensor controls in gspca_dev.

There is no need to implement this, its just a callback for when you want todo something each frame from a non interrupt contexts (like software autoexposure).

Don't hesitate to ask more questions!

Regards,

Hans

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list