Hans,
I'll have more later, but I can say, if LED API is what we agree to, we should have infrastructure in v4l2 at a level higher than gspca for helping drivers use the LED interface and triggers.
Specifically this is needed to make discovery and association of v4l2 devices, exposed v4l2 LEDs, and v4l2 LED triggers easier for userspace, and to provide a logical, consistent naming scheme. It may also help with logical association to a v4l2 media controller later on.
Sysfs entry ownership, unix permissions, and ACL permissions consistency with /dev/videoN will be the immediate usability problem for end users in any case.
Sucessfully setting up or disabling LED triggers without much documentation will likely be the other largest hurdle for the average user. (To disable an indicator LED that is manipulated automatically by a driver using its own Default LED trigger, the end user must disable the trigger in addition to setting the brightness to 0.)
I still want to add trigger use to my prototype to discover the nuances.
BTW, what did you mean by uvc discovering an LED control?
Regards,
Andy
Hans Verkuil <hverkuil@xxxxxxxxx> wrote:
>
>> Hi,
>>
>> On 09/09/2010 08:55 AM, Peter Korsgaard wrote:
>>>>>>>> "Hans" == Hans Verkuil<hverkuil@xxxxxxxxx> 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
>
��.n��������+%������w��{.n�����{��g����^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
