Re: [PATCH] Illuminators and status LED controls

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

 



Hans de Goede,

The uvc API that creates v4l2 ctrls on behalf of userspace could intercept those calls and create an LED interface instead of, or in addition to, the v4l2 ctrl.

Until udev, hal, pam, and polkit userspace configurations catch up, one still has the problem of the sysfs LED files not being usable by the user due to permissions.

Regards,
Andy

Hans de Goede <hdegoede@xxxxxxxxxx> wrote:

>Hi,
>
>On 09/09/2010 03:29 PM, Hans Verkuil 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.
>>
>
>Unfortunately no, some uvc cameras have "proprietary" controls. The uvc driver
>knows nothing about these but offers an API to map these to v4l2 controls
>(where userspace tells it the v4l2 cid, type, min, max, etc.).
>
>Currently on logitech cameras the userspace tools if installed will map
>the led control to a private v4l2 menu control with the following options:
>On
>Off
>Auto
>Blink
>
>The cameras default to auto, where the led is turned on when video
>is being streamed and off when there is no streaming going on.
>
>Regards,
>
>Hans
��.n��������+%������w��{.n�����{��g����^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�

[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