Re: Anchor Chips V4L2 driver

[John McMaster <johndmcmaster@gmail.com>]

On 06/06/2011 12:43 AM, Hans de Goede wrote:
> Hi,
>
> On 06/06/2011 07:40 AM, John McMaster wrote:
>> On 06/03/2011 06:22 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 06/03/2011 02:15 PM, Mauro Carvalho Chehab wrote:
>>>> Em 03-06-2011 02:40, John McMaster escreveu:
>>>>> I'd like to write a driver for an Anchor Chips (seems to be bought by
>>>>> Cypress) USB camera Linux driver sold as an AmScope MD1800.  It seems
>>>>> like this implies I need to write a V4L2 driver.  The camera does not
>>>>> seem its currently supported (checked on Fedora 13 / 2.6.34.8) and I
>>>>> did
>>>>> not find any information on it in mailing list archives.  Does anyone
>>>>> know or can help me identify if a similar camera might already be
>>>>> supported?
>>>>
>>>> I've no idea. Better to wait for a couple days for developers to
>>>> manifest
>>>> about that, if they're already working on it.
>>>>
>>>>> lsusb gives the following output:
>>>>>
>>>>> Bus 001 Device 111: ID 0547:4d88 Anchor Chips, Inc.
>>>>>
>>>>> I've started reading the "Video for Linux Two API Specification"
>>>>> which
>>>>> seems like a good starting point and will move onto using source
>>>>> code as
>>>>> appropriate.  Any help would be appreciated.  Thanks!
>>>>
>>>> You'll find other useful information at linuxtv.org wiki page. The
>>>> better
>>>> is to write it as a sub-driver for gspca. The gspca core have already
>>>> all
>>>> that it is needed for cameras. So, you'll need to focus only at the
>>>> device-specific
>>>> stuff.
>>>
>>> I can second that you should definitely use gspca for usb webcam(ish)
>>> device
>>> drivers. As for how to go about this, first of all grep through the
>>> windows drivers
>>> for strings which may hint on the actual bridge chip used, chances are
>>> good
>>> there is an already supported bridge inside the camera.
>>>
>>> If not then make usb dumps, and start reverse engineering ...
>>>
>>> Usually it is enough to replay the windows init sequence to get the
>>> device
>>> to stream over either an bulk or iso endpoint, and then it is time to
>>> figure out what that stream contains (jpeg, raw bayer, some custom
>>> format ???)
>>>
>>> Regards,
>>>
>>> Hans
>> Thanks for the response.  I replayed some packets (using libusb) and am
>> able to get something resembling the desired image through its bulk
>> endpoint.  So now I just need to figure out how to decode it better,
>> options, etc.  I'll post back to the list once I get something
>> moderately stable running and have taken a swing at the kernel driver.
>>
>
> Hmm, bulk you say and cypress and 8mp usb2.0 have you tried looking
> at the gspca-ovfx2 driver? Likely you've an ovfx2 cam with an as of
> yet unknown usb-id. Chances are just adding the id is enough, although
> your sensor may be unknown.
>
> Regards,
>
> Hans
If it helps, I should have also mentioned that with a small amount of
digging I found that the camera unit is put together by ScopeTek.  My
reference WIP implementation is at
https://github.com/JohnDMcMaster/uvscopetek which I'm comparing to
2.6.39.1 drivers.

Anyway, looking at reg_w() I see that it likes to make 0x00, 0x02, or
0x0A requests where as mine makes 0x01, 0x0A, and mostly 0x0B requests. 
I do see that it tends to want a byte back though like mine (0x0A except
at end).  My code has a few 3 byte returns (byte 0 varies, byte 1 fixed
at 0x00, byte 2 fixed at 0x08 like others), so I'm not sure if its a
good match for reg read.  Following that I tried to grep around some
more for a number of the more interesting numbers (eg: 90D8 as opposed
to 0001) in the $SRC/drivers/media/video dir and could only find
scattered matches.  I do realize that a lot of the more esoteric numbers
could be specific settings and not registers, commands, etc.  Or maybe
tofx2 is related and I'm not understanding the bridge concept?

John