Gerd Knorr wrote: > While thinking about the attributes I'm not sure they really should be > part of the device context. For video input, video format, video norm > every application needs it's own set. For the bright/contrast/audio/... > settings this isn't required. In fact there are perfectly legal and > useful szenarios where it is good _not_ having them in the device > context. You might want to adjust the contrast for your webcam. Just > start up xawtv and do so -- without stopping/restarting your webcam. > Have some fancy, generic GUI tool for all sorts of v4l2 controls. Brightness, contrast, etc. should be per input. Brightness is the opinion of the user for the particular video source. The user's opinion does not change between xawtv and streamer, for example, so brightness is the same across all contexts. But may be different between the webcam and TV tuner, for example. Video norm is per input. If the camera connected to composite input #1 is NTSC, then that is true for all application contexts. It's obvious when you think about it. Some video decoders are programmed slightly differently if the source is from a VCR, if you have that setting, then that should be per input. Etc. You see where I'm going. The capture format, e.g. image width and height in pixels, pixel format, etc. are determined by the requirements of the particular application, so must be per device context. > Of course one needs a way to lock access to these controls, > if some application is going to record something important it probably > does'nt want allow others to f*ck up the movie by setting the contrast > control to zero. Controls would only be set by the user to his preference via some graphical control 'knob'. Nothing will happen that the user doesn't want to happen. The driver doesn't need that extra code-- just give access to the device, and manage the data flow. Bill.
