> Hi,
>
> On 09/09/2010 08:55 AM, Peter Korsgaard wrote:
>>>>>>> "Hans" == Hans Verkuil<hverk...@xs4all.nl> writes:
>>
>> Hi,
>>
>> >> - the status LED should be controlled by the LED interface.
>>
>> Hans> I originally was in favor of controlling these through v4l as
>> Hans> well, but people made some good arguments against that. The
>> main
>> Hans> one being: why would you want to show these as a control? What
>> is
>> Hans> the end user supposed to do with them? It makes little sense.
>>
>> Hans> Frankly, why would you want to expose LEDs at all? Shouldn't
>> this
>> Hans> be completely hidden by the driver? No generic application will
>> Hans> ever do anything with status LEDs anyway. So it should be the
>> Hans> driver that operates them and in that case the LEDs do not need
>> Hans> to be exposed anywhere.
>>
>> It's not that it *HAS* to be exposed - But if we can, then it's nice to
>> do
>> so as it gives flexibility to the user instead of hardcoding policy in
>> the kernel.
>>
>
> Reading this whole thread I have to agree that if we are going to expose
> camera status LEDs it would be done through the sysfs API. I think this
> can be done nicely for gspca based drivers (as we can put all the "crud"
> in the gspca core having to do it only once), but that is a low priority
> nice to have thingy.
>
> This does leave us with the problem of logitech uvc cams where the LED
> currently is exposed as a v4l2 control.
Is it possible for the uvc driver to detect and use a LED control? That's
how I would expect this to work, but I know that uvc is a bit of a strange
beast.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
