Gerd Knorr wrote: > > > > Yes, of course. Last time I got responses along the lines "multiple opens > > > makes driver writing harder, that's why it is bad". That's why I wanted > > > make clear that supporting multiple opens isn't mandatory for the drivers. > > > > Well, it does support multiple opens, but it is spec'd that only one > > open can have capturing privileges. > > And exactly this I'd like to be changed. > > > Multiple capturing opens can produce subtle repercussions in the > > sematics of various ioctls. For example, suppose an app opens a driver > > and does a GET-FORMAT (or any other kind of query) while there are two > > capturing opens active. The format of which open should be returned? > > You have to keep the current capture format per filehandle (otherwise > you'll get alot of nasty races). Therefore GET-FORMAT will *not* return > the data of the other opens, it returns the settings for the current > handle (which in turn can be initialized at open() time with some default > format or with whatever the hardware currently uses). I have been thinking about this for a while now. Actually, the v4l2 vbi spec has mmultiple capturing opens, and I was trying to share as much code as possible. My thoughts were roughly: 1) Move all capture related info to the specific open. 2) Maintain a global format, that is changed on every S_FORMAT by any open. 3) Use the global format as the default on a new open. This should maintain compaitibility with all existing apps, while extending the driver to contain multiple capturing opens. > > If > > the driver requires both opens to use the same format, which open gets > > control, and will that mess up the app that doesn't have control? > > STREAMON will lock down the capture ressources, i.e. the driver guaranties > that nobody else can mess up the settings and that it will be able to > capture at full frame rate until it calls STREAMOFF. > > Means whoever calls STREAMON first has the control over the hardware, and > the other one will get a -EBUSY if the driver can't handle the request. > > > Of course, a driver writer can do whatever he pleases behind the scenes, > > as long the ioctl semantics are preserved such that apps, and therefore > > users, are happy. > > Yes. But I'd like to see the exact ressource locking semantics for > multiple opens in the API spec. As mentioned a few mails back I think > the current API is fine, it is just a documentation issue. Ditto - there are still some slightly vague areas in the v4l2 spec. -justin
