Ok finally arrived back from my trip to japan. The last week of which since i was travelling i didn't have much internet access so i'll try to respond to some of these points now.
3 and 7: I've been thinking about the whole format thing recently and i believe we really should just stick to the formats supported by the bridge. Which for the moment would be jpeg format and raw format(with sensors set to use bayer). This would make things in the driver somewhat simpler and also seems to be what most of the webcam drivers in the kernel do as well. It would however mean we would not implement format changing at a sensor level(no yuv422 for omnivision). I'm not sure that there is that much advantage to natively supporting yuv or rgb formats since libv4l seems to do a pretty good job of doing any conversions necessary. Even if we want to be able to change things at the sensor level i think each sensor should define its own list of supported formats rather then a default one that gets memcpy'd among other things the v4l2 portion of the driver assumes that any format defined in the array of formats is vakid and they way things work now that is not the case meaning it will tell you the driver supports YUYV even when it does not. 5. Yes i'll try to work on that when i have abit of time now that i'm back. 6. This is a good idea as well. Do we have any documentation on the exact format of those custom yuv formats? 9. I'm not quite sure about where the jpeg decoding issues are coming from. The easiest solution was a quick modifcation to libv4l to drop all bad jpeg frames then the issue went away. It actually aleady does this for the pixart jpeg format. On Wed, Dec 17, 2008 at 3:18 PM, GWater <[email protected]> wrote: > I don't know what everyone is working on right now but here are a few issues > (might call them bugs) that need taking care of: > > 1. For the following devices support has been requested (new sensors): > - 6240 (MT9M001) > - 624c (MT9M112) > - 627c (HV7131R) > > 2. The follwing devices need a bit of adjusting and fixing: > - 6242/6282 (MT9M111) > > 3. Support for multiple sn9c20x-based devices simultaniously on one machine > needs to be restored: > - main problem is the image format-handling in microdia-dev.c > > 4. The whole V4L2 extended controls crap. > - Otherwise we can't set auto-exposure with v4l2ucp which wuold be a shame > for the everyone. > > 5. the table used to translate usb-ids to sensors can be included in some > descriptor in microdia-usb.c > - Brian knows the details here > > 6. Define custom V4L fmts for the sn9c20x-included YUV422 and YUV420, then > ask libv4l to integrate the old decoders. > - there have been reports that JPEG decoding uses nearly 10-times as much > cpu as the old decoding mechanism. > > 7. Get YUV422 working for omnivision sensors: > - Brian had already made a patch for that a while ago - just needs to be > adjusted and pushed. > > 8. Get started on SXGA > > 9. Figure out where the white flashes in JPEG come from > - difficult - maybe we can just filter the frames with evil huffman codes? > > 10. ??? > > > Let's make this a nice new years present to everyone ;) . > > GWater > > --~--~---------~--~----~------------~-------~--~----~ Lets make microdia webcams plug'n play, (currently plug'n pray) To post to this group, send email to [email protected] Visit us online https://groups.google.com/group/microdia -~----------~----~----~----~------~----~------~--~---
