Hans de Goede wrote: > Hi, > > On 09/02/2009 06:32 PM, Simon Farnsworth wrote: >> I have a Hauppauge HVR1600 for NTSC and ATSC support, and it appears to >> simply not work with libv4l2, due to lack of mmap support. My code works >> adequately (modulo a nice pile of bugs) with a HVR1110r3, so it appears >> to be driver level. >> >> Which is the better route to handling this; adding code to input_v4l to >> use libv4lconvert when mmap isn't available, or converting the cx18 >> driver to use mmap? >> > > Or modify libv4l2 to also handle devices which can only do read. There have > been some changes to libv4l2 recently which would make doing that feasible. > Roughly what would I need to do to libv4l2?
I can see four new cases to handle: 1) driver supports read(), client wants read(), format supported by both. Just pass read() through to the driver. 2) driver supports read(), client wants mmap(), format supported by both. Allocate buffers when REQBUFs happens, handle QBUF and DQBUF by read()ing frame size chunks into the buffer at the head of the internal queue when a DQBUF happens, and passing it back out. 3) As 1, but needs conversion. read() into a temporary buffer, convert with libv4lconvert (I think this needs a secondary buffer), and supply data from the secondary buffer to read() 4) As 2, but needs conversion. Change DQBUF handling to read() frame size chunks into a temporary buffer, then use libv4lconvert to copy those chunks from the temporary buffer into the buffer you're about to pass out. Have I missed anything? >> If it's a case of converting the cx18 driver, how would I go about doing >> that? I have no experience of the driver, so I'm not sure what I'd have >> to do - noting that if I break the existing read() support, other users >> will get upset. > > I don't believe that modifying the driver is the answer, we need to either > fix this at the libv4l or xine level. > > I wonder though, doesn't the cx18 offer any format that xine can handle > directly? > Not sensibly; it offers HM12 only, and Xine needs an RGB format, YV12, or YUYV. With a lot of rework, I could have the cx18 encode video to MPEG-2, then have Xine decode the resulting MPEG-2 stream, but this seems like overkill for uncompressed video. I could also teach Xine to handle HM12 natively, but that would duplicate effort already done in libv4l2 and libv4lconvert, which seems a bit silly to me. -- Simon Farnsworth -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
