From: Hans de Goede <hdegoede@redhat.com>
To: Jean-Francois Moine <moinejf@free.fr>
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH] LED control
Date: Sun, 05 Sep 2010 15:54:55 +0200 [thread overview]
Message-ID: <4C83A12F.1070009@redhat.com> (raw)
In-Reply-To: <20100905105627.0d5d3dab@tele>
Hi,
On 09/05/2010 10:56 AM, Jean-Francois Moine wrote:
> On Sun, 05 Sep 2010 09:56:54 +0200
> Hans de Goede<hdegoede@redhat.com> wrote:
>
>> I think that using one control for both status leds (which is what we
>> are usually talking about) and illuminator(s) is a bad idea. I'm fine
>> with standardizing these, but can we please have 2 CID's one for
>> status lights and one for the led. Esp, as I can easily see us
>> supporting a microscope in the future where the microscope itself or
>> other devices with the same bridge will have a status led, so then we
>> will need 2 separate controls anyways.
>
> Hi Hans,
>
> I was not thinking about the status light (I do not see any other usage
> for it), but well about illuminators which I saw only in microscopes.
>
Ah, ok thanks for clarifying. For some more on this see p.s. below.
> So, which is the better name? V4L2_CID_LAMPS? V4L2_CID_ILLUMINATORS?
I think that V4L2_CID_ILLUMINATORS together with a comment in the .h
and explanation in the spec that this specifically applies to microscopes
would be good.
Regards,
Hans
p.s.
I think it would be good to have a V4L2_CID_STATUS_LED too. In many drivers
we are explicitly controlling the led by register writes. Some people may very
well prefer the led to always be off. I know that uvc logitech cameras have
controls for the status led through the extended uvc controls. Once we have
a standardized LED control, we can move the logitech uvc cams over from
using their own private one to this one.
Once this is in place I would like to build some framework in to gspca
for supporting this control in gspca (the control would be handled by the core,
and sub drivers would have an sd_set_led function).
While at it could you write a proposal / patch for adding this control to the
spec as well ?
next prev parent reply other threads:[~2010-09-05 13:49 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-04 11:10 [PATCH] LED control Jean-Francois Moine
2010-09-04 19:50 ` Andy Walls
2010-09-05 7:56 ` Hans de Goede
2010-09-05 8:04 ` Peter Korsgaard
2010-09-05 8:19 ` Hans de Goede
2010-09-05 18:23 ` Andy Walls
2010-09-05 8:56 ` Jean-Francois Moine
2010-09-05 13:54 ` Hans de Goede [this message]
2010-09-05 18:43 ` Andy Walls
2010-09-05 19:34 ` Hans de Goede
2010-09-13 6:43 ` Laurent Pinchart
-- strict thread matches above, loose matches on Subject: below --
2009-03-14 11:59 Jean-Francois Moine
2009-03-14 12:17 ` Mauro Carvalho Chehab
2009-03-14 13:25 ` Jean-Francois Moine
2009-03-14 13:58 ` Andy Walls
2009-03-14 20:16 ` Trent Piepho
2009-03-15 9:50 ` Jean-Francois Moine
2009-03-15 10:16 ` Laurent Pinchart
2009-03-15 15:14 ` Trent Piepho
2009-03-17 8:28 ` Jean-Francois Moine
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C83A12F.1070009@redhat.com \
--to=hdegoede@redhat.com \
--cc=linux-media@vger.kernel.org \
--cc=moinejf@free.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.