Tom Zoerner <tomzo@xxxxxxxxxx> writes: > Any pro/cons to event handling in general? > > (I've added only what I consider useful for VBI apps so far, maybe > there's other significant global parameters for other capture types, > e.g. audio mute?) tuning changes (i.e. S_FREQUENCY triggers that one)? control changes (S_CTRL)? STREAMON/OFF? Control changes wouldn't be that simple through ... > BTW: any suggestions regarding handling of radio, in particular > the mode change upon open? (Possibly reject the device open with > EBUSY when a recording is active or delay radio mode change until > the first frequency is tuned?) -EBUSY when recording priority is active sounds sane to me. > > Anyway, bus_info should do the trick. > > Could we make this info mandatory for all v4l2 drivers then? If the > driver doesn't have anything like a bus_info it could still provide an > instance number instead. In combination with the driver name the info > should be unique. I think it shouldn't be a problem for the driver to provide bus_info. Every modern bus has some way to identify a device, so "bustype:identity" should be unique. Even for prehistoric ISA you can build something unique using the io port address of the device, i.e. "ISA:0x320" for example. Making that mandatory is fine with me. Gerd -- sigfault
