sojan@xxxxxxxxxxxxxxxx wrote: > Hi, > The current definition of the VIDIOC_S_FMT for the VBI makes a > restriction that, requiring the calling application to define a RANGE of > lines. It also does not specify how the API for sliced data should look. > > Also, it is possible to have multiple formats in different lines. The > driver should be able to simultaneously capture different formats. > > Here are some ideas to address these, > > 1. Each open should be configurable for a SET of lines and the > format. For example, the user should be able to use one open instance > to read Closed Caption data and use another open for say, WSS. Sounds a bit over-engineered to me. Why do you need sets instead of ranges? Are the lines for different data types interleaved or something like that? > 2. Rather than setting a range of lines in the VIDIOC_S_FMT, we should be > able to request a SET of lines. This can be done without altering the > current API by making the VIDIOC_S_FMT cumulative, i.e. the previously > set range of lines is "remembered". Sorry, but changing the semantics of VIDIOC_S_FMT does break the API. > 3. 2 Byte header for Sliced data. > If we follow 2, it would be necessary to indicate to the reader, to > which line of video data, the data in the buffer belongs to. Why? The application should know which data lines it has asked for ... Gerd -- Damn lot people confuse usability and eye-candy.
