digigr8 driver sends wrong command to camera which causes it to enter capture mode and lock up

[KrisSlyka]

Describe the bug The digigr8 driver sends command 0x1440 with parameter 0x110f to the camera during initialization which causes the controller to enter webcam mode. This causes the next commands to fail and the controller to lock up in webcam mode.

Refer to drivers/media/usb/gspca/sq905c.c in the Linux kernel for a rough protocol reference for the webcam function.

I have also captured the USB traffic of the official software running on a windows XP VM and command 0x1440 is not part of the initialization procedure performed for picture listing and download.

I have uploaded the capture here: https://slyka.net/~sly/stuff/empty.pcapng And here is a simple patch: https://slyka.net/~sly/stuff/0001-Fix-camera-crash-caused-by-digigr8-camlib.patch

Name the camera This applies to call cameras using the SQ Technologies SQ905C controller IC and maybe some of it's variants, in my case it was a Praktica Slimpix.

libgphoto2 and gphoto2 version gphoto2 2.5.28 gcc, popt(m), exif, no cdk, no aa, jpeg, readline libgphoto2 2.5.30 standard camlibs, gcc, no ltdl, EXIF libgphoto2_port 0.12.1 iolibs: disk ptpip serial usb1 usbdiskdirect usbscsi, gcc, no ltdl, EXIF, USB, serial without locking

To Reproduce Any command resulting in camera initialization causes the problem, like gphoto2 -L or gphoto2 -P.

Remarks I remember using this camera successfully with libgphoto2 in around 2009 or 2010, but according to git blame this command was there since the beginning, so I'm not entirely sure what causes this regression.

I was able to talk to the camera from a Ubuntu 9.04 VM, which also sends the erroneous command but where it doesn't result in the camera crashing. The only major difference between these two is the switch from libusb0 to libusb1 and the presence of the webcam driver in the current kernel, though I'm not entirely sure how those interact.

[msmeissn]

will add the patch as-is , thanks :)