Am 13.12.2012 19:16, schrieb Devin Heitmueller: > On Thu, Dec 13, 2012 at 12:56 PM, Frank Schäfer > <fschaefer.oss@xxxxxxxxxxxxxx> wrote: >> Am 13.12.2012 18:36, schrieb Devin Heitmueller: >>> On Sat, Dec 8, 2012 at 10:31 AM, Frank Schäfer >>> <fschaefer.oss@xxxxxxxxxxxxxx> wrote: >>>> This patch series refactors the frame data processing code in em28xx-video.c to >>>> - reduce code duplication >>>> - fix a bug in vbi data processing >>>> - prepare for adding em25xx/em276x frame data processing support >>>> - clean up the code and make it easier to understand >>> Hi Frank, >>> >>> Do you have these patches in a git tree somewhere that I can do a git >>> pull from? If not then that's fine - I'll just save off the patches >>> and apply them by hand. >> No, I have no public git tree. >> >>> I've basically got your patches, fixes Hans did for v4l2 compliance, >>> and I've got a tree that converts the driver to videobuf2 (which >>> obviously heavily conflicts with the URB handler cleanup you did). >>> Plan is to suck them all into a single tree, deal with the merge >>> issues, then issue a pull request to Mauro. >> Ahhh, videobuf2 ! >> Good to know, because I've put this on my TODO list... ;) > It's harder than it looks. There are currently no other devices > ported to vb2 which have VBI and/or radio devices. Hence I have to > refactor the locking a bit (since the URB callback feeds two different > VB2 queues). In other words, there's no other driver to look at as a > model and copy the business logic from. Yeah, that's one of the reasons why I decided to do it later ;) > >> Yes, there will likely be heavy merge conflicts... >> In which tree are the videobuf2 patches ? > It's in a private tree right now, and it doesn't support VBI > currently. Once I've setup a public tree with yours and Hans changes, > I'll start merging in my changes. I suggest to do the conversion on top of my patches, as they should make things much easier for you. I unified the handling of the VBI and video buffers, leaving just a few common functions dealing with the videobuf stuff. In any case, we should develop against a common tree with a minimum number of pending patches. And we should coordinate development. I don't work on further changes of the frame processing stuff at the moment. Some I2C fixes/changes will be next. After that, I will try to fix support for remote controls with external IR IC (connected via i2c). > Obviously it would be great for you to test with your webcam and make > sure I didn't break anything along the way. Sure, I will be glad to test your changes. > I've also got changes to support V4L2_FIELD_SEQ_TB, which is needed in > order to take the output and feed to certain hardware deinterlacers. > In reality this is pretty much just a matter of treating the video > data as progressive but changing the field type indicator. Ok, so I assume most of the changes will happen in em28xx_copy_video(). Maybe we can then use a common copy function for video and VBI. Placing the field data sequentially in the videobuf is what we already do with the VBI data in em28xx_copy_vbi() Regards, Frank > I'm generally pretty easy to find in #linuxtv or #v4l if you want to > discuss further. > > Cheers, > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
