Re: mt9t031 (was RE: [PATCH] adding support for setting bus parameters in sub device)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>
>
> On 06/11/2009 11:33 AM, Hans Verkuil wrote:
>>>
>>> On 06/11/2009 10:35 AM, Hans Verkuil wrote:
>
> <snip (a lot)>
>
>>> Hmm,
>>>
>>> Why would we want the *application* to set things like this *at all* ?
>>> with sensors hsync and vsync and other timing are something between
>>> the bridge and the sensor, actaully in my experience the correct
>>> hsync / vsync timings to program the sensor to are very much bridge
>>> specific. So IMHO this should not be exposed to userspace at all.
>>>
>>> All userspace should be able to control is the resolution and the
>>> framerate. Although controlling the framerate in many cases also
>>> means controlling the maximum exposure time. So in many cases
>>> one cannot even control the framerate. (Asking for 30 fps in an
>>> artificially illuminated room will get you a very dark, useless
>>> picture, with most sensors). Yes this means that with cams with
>>> use autoexposure (which is something which we really want where ever
>>> possible), the framerate can and will change while streaming.
>>
>> I think we have three possible use cases here:
>>
>> - old-style standard definition video: use S_STD
>>
>
> Ack
>
>> - webcam-like devices: a combination of S_FMT and S_PARM I think?
>> Correct
>> me if I'm wrong. S_STD is useless for this, right?
>>
>
> Ack
>
>> - video streaming devices like the davinci videoports where you can hook
>> up HDTV receivers or FPGAs: here you definitely need a new API to setup
>> the streaming parameters, and you want to be able to do that from the
>> application as well. Actually, sensors are also hooked up to these
>> devices
>> in practice. And there you also want to be able to setup these
>> parameters.
>> You will see this mostly (only?) on embedded platforms.
>>
>
> I agree we need an in kernel API for this, but why expose it to
> userspace, as you say this will only happen on embedded systems,
> shouldn't the info then go in a board_info file / struct ?

These timings are not fixed. E.g. a 720p60 video stream has different
timings compared to a 1080p60 stream. So you have to be able to switch
from userspace. It's like PAL and NTSC, but then many times worse :-)

Regards,

         Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux