| Message ID | 20100904131048.6ca207d1@tele (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers |
Return-path: <mchehab@localhost> Envelope-to: mchehab@localhost Delivery-date: Sat, 04 Sep 2010 09:05:59 -0300 Received: from mchehab by localhost with local (Exim 4.72) (envelope-from <mchehab@localhost>) id 1OrrVP-0004KK-3U for mchehab@localhost; Sat, 04 Sep 2010 09:05:59 -0300 Received: from bombadil.infradead.org [18.85.46.34] by localhost with IMAP (fetchmail-6.3.17) for <mchehab@localhost> (single-drop); Sat, 04 Sep 2010 09:05:59 -0300 (BRT) Received: from vger.kernel.org ([209.132.180.67]) by bombadil.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1OrqeE-0004uN-VK; Sat, 04 Sep 2010 11:11:03 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753643Ab0IDLKt (ORCPT <rfc822; kmpark@infradead.org> + 1 other); Sat, 4 Sep 2010 07:10:49 -0400 Received: from smtp5-g21.free.fr ([212.27.42.5]:49569 "EHLO smtp5-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752376Ab0IDLKs (ORCPT <rfc822;linux-media@vger.kernel.org>); Sat, 4 Sep 2010 07:10:48 -0400 Received: from tele (unknown [82.245.201.222]) by smtp5-g21.free.fr (Postfix) with ESMTP id 83D79D4805F for <linux-media@vger.kernel.org>; Sat, 4 Sep 2010 13:10:42 +0200 (CEST) Date: Sat, 4 Sep 2010 13:10:48 +0200 From: Jean-Francois Moine <moinejf@free.fr> To: linux-media@vger.kernel.org Subject: [PATCH] LED control Message-ID: <20100904131048.6ca207d1@tele> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/k9=agR0s76BWcZz/De93XEC" Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org Sender: Mauro Carvalho Chehab <mchehab@localhost> |
Commit Message
Jean-Francois Moine
Sept. 4, 2010, 11:10 a.m. UTC
Some media devices may have one or many lights (LEDs, illuminators,
lamps..). This patch makes them controlable by the applications.
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Comments
On Sat, 2010-09-04 at 13:10 +0200, Jean-Francois Moine wrote: > Some media devices may have one or many lights (LEDs, illuminators, > lamps..). This patch makes them controlable by the applications. > > Signed-off-by: Jean-Francois Moine <moinejf@free.fr> Jean-Francois, Thanks for the proposal. It looks OK to me. Acked-by: Andy Walls <awalls@md.metrocast.net> Regards, Andy > diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml > index 8408caa..c9b8ca5 100644 > --- a/Documentation/DocBook/v4l/controls.xml > +++ b/Documentation/DocBook/v4l/controls.xml > @@ -312,6 +312,13 @@ minimum value disables backlight compensation.</entry> > information and bits 24-31 must be zero.</entry> > </row> > <row> > + <entry><constant>V4L2_CID_LEDS</constant></entry> > + <entry>integer</entry> > + <entry>Switch on or off the LED(s) or illuminator(s) of the device. > + The control type and values depend on the driver and may be either > + a single boolean (0: off, 1:on) or the index in a menu type.</entry> > + </row> > + <row> > <entry><constant>V4L2_CID_LASTP1</constant></entry> > <entry></entry> > <entry>End of the predefined control IDs (currently > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h > index 61490c6..3807492 100644 > --- a/include/linux/videodev2.h > +++ b/include/linux/videodev2.h > @@ -1045,8 +1045,10 @@ enum v4l2_colorfx { > > #define V4L2_CID_CHROMA_GAIN (V4L2_CID_BASE+36) > > +#define V4L2_CID_LEDS (V4L2_CID_BASE+37) > + > /* last CID + 1 */ > -#define V4L2_CID_LASTP1 (V4L2_CID_BASE+37) > +#define V4L2_CID_LASTP1 (V4L2_CID_BASE+38) > > /* MPEG-class control IDs defined by V4L2 */ > #define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900) > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi all, On 09/04/2010 01:10 PM, Jean-Francois Moine wrote: > Some media devices may have one or many lights (LEDs, illuminators, > lamps..). This patch makes them controlable by the applications. > > Signed-off-by: Jean-Francois Moine<moinejf@free.fr> > > -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ > > > led.patch > > > diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml > index 8408caa..c9b8ca5 100644 > --- a/Documentation/DocBook/v4l/controls.xml > +++ b/Documentation/DocBook/v4l/controls.xml > @@ -312,6 +312,13 @@ minimum value disables backlight compensation.</entry> > information and bits 24-31 must be zero.</entry> > </row> > <row> > + <entry><constant>V4L2_CID_LEDS</constant></entry> > + <entry>integer</entry> > + <entry>Switch on or off the LED(s) or illuminator(s) of the device. > + The control type and values depend on the driver and may be either > + a single boolean (0: off, 1:on) or the index in a menu type.</entry> > + </row> 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. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>> "Hans" == Hans de Goede <hdegoede@redhat.com> writes: Hi, >> + <entry><constant>V4L2_CID_LEDS</constant></entry> >> + <entry>integer</entry> >> + <entry>Switch on or off the LED(s) or illuminator(s) of the device. >> + The control type and values depend on the driver and may be either >> + a single boolean (0: off, 1:on) or the index in a menu type.</entry> >> + </row> Hans> I think that using one control for both status leds (which is Hans> what we are usually talking about) and illuminator(s) is a bad Hans> idea. I'm fine with standardizing these, but can we please have 2 Hans> CID's one for status lights and one for the led. Esp, as I can Hans> easily see us supporting a microscope in the future where the Hans> microscope itself or other devices with the same bridge will have Hans> a status led, so then we will need 2 separate controls anyways. Why does this need to go through the v4l2 api and not just use the standard LED (sysfs) api in the first place?
Hi, On 09/05/2010 10:04 AM, Peter Korsgaard wrote: >>>>>> "Hans" == Hans de Goede<hdegoede@redhat.com> writes: > > Hi, > > >> + <entry><constant>V4L2_CID_LEDS</constant></entry> > >> + <entry>integer</entry> > >> + <entry>Switch on or off the LED(s) or illuminator(s) of the device. > >> + The control type and values depend on the driver and may be either > >> + a single boolean (0: off, 1:on) or the index in a menu type.</entry> > >> + </row> > > Hans> I think that using one control for both status leds (which is > Hans> what we are usually talking about) and illuminator(s) is a bad > Hans> idea. I'm fine with standardizing these, but can we please have 2 > Hans> CID's one for status lights and one for the led. Esp, as I can > Hans> easily see us supporting a microscope in the future where the > Hans> microscope itself or other devices with the same bridge will have > Hans> a status led, so then we will need 2 separate controls anyways. > > Why does this need to go through the v4l2 api and not just use the > standard LED (sysfs) api in the first place? > Quoting from the reply by Jean-Francois Moine to a patch adding illuminator control support to the cpia1 driver where this proposal is a result of: ### As many gspca users are waiting for a light/LED/illuminator/lamp control, I tried to define a standard one in March 2009: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/3095 A second, but more restrictive, attempt was done by Németh Márton in February 2010: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/16705 The main objection to that proposals was that the sysfs LED interface should be used instead: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/3114 A patch in this way was done by Németh Márton in February 2010: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/16670 but it was rather complex, and there was no consensus http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/17111 ### So using the sysfs interface for this is non trivial. Most cameras don't offer any hardware dimming / blinking features, but we do want to do an auto setting where the led goes on when streaming and goes off again when not streaming. So the sysfs interface is not a good match to what we need. A more important argument IMHO however is that the LED control is just one element of many things one can control on (some) webcams, things like focus, pan and tilt for the more fancy ones also come into play. Not to mention contrast, brightness etc. settings. Currently we have one central API for this which is the v4l2 ctrl API, and we have several apps which dynamically build up a UI for this depending on the ctrls advertised by the device. Adding a LED ctrl to the v4l2 API will make this automatically show up in these apps and give the user one central place to control everything related to the camera. Where as using the led sysfs API would mean that the led control will basically stay invisible to the end user unless we start patching all apps to also use support this API, requiring all v4l2 apps to grow code to support a whole new api just to turn on / off a led does not seem like a good idea to me. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. So, which is the better name? V4L2_CID_LAMPS? V4L2_CID_ILLUMINATORS? Cheers.
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 ? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 2010-09-05 at 10:04 +0200, Peter Korsgaard wrote: > >>>>> "Hans" == Hans de Goede <hdegoede@redhat.com> writes: > > Hi, > > >> + <entry><constant>V4L2_CID_LEDS</constant></entry> > >> + <entry>integer</entry> > >> + <entry>Switch on or off the LED(s) or illuminator(s) of the device. > >> + The control type and values depend on the driver and may be either > >> + a single boolean (0: off, 1:on) or the index in a menu type.</entry> > >> + </row> > > Hans> I think that using one control for both status leds (which is > Hans> what we are usually talking about) and illuminator(s) is a bad > Hans> idea. I'm fine with standardizing these, but can we please have 2 > Hans> CID's one for status lights and one for the led. Esp, as I can > Hans> easily see us supporting a microscope in the future where the > Hans> microscope itself or other devices with the same bridge will have > Hans> a status led, so then we will need 2 separate controls anyways. > > Why does this need to go through the v4l2 api and not just use the > standard LED (sysfs) api in the first place? It puts a larger burden on the application programmer. Video capture applications are already programmed to provide controls to the user using the V4L2 API for manipulating all aspects of the incoming video image. Using something different for turning on subject illumination would be an exceptional case. The V4L2 control API also allows applications to be written such that they need no apriori knowledge about a video driver's controls, and yet can still present all driver supported controls to the user for manipulation. The VIDIOC_QUERYCTL interface allows applications to discover controls and metadata to build a UI. Two applications that illustrate the point are 'qv4l2' (a Qt control GUI) and 'v4l2-ctl' (a CLI control UI) found here: http://git.linuxtv.org/v4l-utils.git?a=tree;f=utils;h=8d37309cc3b896d11fc77d9f275f82f02ee9c03d;hb=HEAD As an example, here is the output of v4l2-ctl -L for my QX3 microscope: $ v4l2-ctl -d /dev/video1 -L brightness (int) : min=0 max=100 step=1 default=50 value=50 contrast (int) : min=0 max=96 step=8 default=48 value=48 saturation (int) : min=0 max=100 step=1 default=50 value=50 light_frequency_filter (menu) : min=0 max=2 default=1 value=1 0: NoFliker 1: 50 Hz 2: 60 Hz compression_target (menu) : min=0 max=1 default=0 value=0 0: Quality 1: Framerate lamps (menu) : min=0 max=3 default=0 value=0 0: Off 1: Bottom 2: Top 3: Both And here is the output for my PVR-350 TV capture card: $ v4l2-ctl -d /dev/video2 -L User Controls brightness (int) : min=0 max=255 step=1 default=128 value=128 flags=slider contrast (int) : min=0 max=127 step=1 default=64 value=64 flags=slider saturation (int) : min=0 max=127 step=1 default=64 value=64 flags=slider hue (int) : min=-128 max=127 step=1 default=0 value=0 flags=slider volume (int) : min=0 max=65535 step=655 default=58880 value=58880 flags=slider mute (bool) : default=0 value=0 MPEG Encoder Controls stream_type (menu) : min=0 max=5 default=0 value=0 flags=update 0: MPEG-2 Program Stream 2: MPEG-1 System Stream 3: MPEG-2 DVD-compatible Stream 4: MPEG-1 VCD-compatible Stream 5: MPEG-2 SVCD-compatible Stream stream_vbi_format (menu) : min=0 max=1 default=0 value=0 0: No VBI 1: Private packet, IVTV format audio_sampling_frequency (menu) : min=0 max=2 default=1 value=1 0: 44.1 kHz 1: 48 kHz 2: 32 kHz audio_encoding (menu) : min=1 max=1 default=1 value=1 flags=update 1: MPEG-1/2 Layer II audio_layer_ii_bitrate (menu) : min=9 max=13 default=10 value=10 9: 192 kbps 10: 224 kbps 11: 256 kbps 12: 320 kbps 13: 384 kbps audio_stereo_mode (menu) : min=0 max=3 default=0 value=0 flags=update 0: Stereo 1: Joint Stereo 2: Dual 3: Mono audio_stereo_mode_extension (menu) : min=0 max=3 default=0 value=0 flags=inactive 0: Bound 4 1: Bound 8 2: Bound 12 3: Bound 16 audio_emphasis (menu) : min=0 max=2 default=0 value=0 0: No Emphasis 1: 50/15 us 2: CCITT J17 audio_crc (menu) : min=0 max=1 default=0 value=0 0: No CRC 1: 16-bit CRC audio_mute (bool) : default=0 value=0 video_encoding (menu) : min=0 max=1 default=1 value=1 flags=readonly 0: MPEG-1 1: MPEG-2 video_aspect (menu) : min=0 max=3 default=1 value=1 0: 1x1 1: 4x3 2: 16x9 3: 2.21x1 video_b_frames (int) : min=0 max=33 step=1 default=2 value=2 flags=update video_gop_size (int) : min=1 max=34 step=1 default=15 value=15 video_gop_closure (bool) : default=1 value=1 video_bitrate_mode (menu) : min=0 max=1 default=0 value=0 flags=update 0: Variable Bitrate 1: Constant Bitrate video_bitrate (int) : min=0 max=27000000 step=1 default=6000000 value=6000000 video_peak_bitrate (int) : min=0 max=27000000 step=1 default=8000000 value=8000000 video_temporal_decimation (int) : min=0 max=255 step=1 default=0 value=0 video_mute (bool) : default=0 value=0 video_mute_yuv (int) : min=0 max=16777215 step=1 default=32896 value=32896 spatial_filter_mode (menu) : min=0 max=1 default=0 value=0 flags=update 0: Manual 1: Auto spatial_filter (int) : min=0 max=15 step=1 default=0 value=0 flags=slider spatial_luma_filter_type (menu) : min=0 max=4 default=1 value=1 0: Off 1: 1D Horizontal 2: 1D Vertical 3: 2D H/V Separable 4: 2D Symmetric non-separable spatial_chroma_filter_type (menu) : min=0 max=1 default=1 value=1 0: Off 1: 1D Horizontal temporal_filter_mode (menu) : min=0 max=1 default=0 value=0 flags=update 0: Manual 1: Auto temporal_filter (int) : min=0 max=31 step=1 default=8 value=8 flags=slider median_filter_type (menu) : min=0 max=4 default=0 value=0 flags=update 0: Off 1: Horizontal 2: Vertical 3: Horizontal/Vertical 4: Diagonal median_luma_filter_minimum (int) : min=0 max=255 step=1 default=0 value=0 flags=inactive slider median_luma_filter_maximum (int) : min=0 max=255 step=1 default=255 value=255 flags=inactive slider median_chroma_filter_minimum (int) : min=0 max=255 step=1 default=0 value=0 flags=inactive slider median_chroma_filter_maximum (int) : min=0 max=255 step=1 default=255 value=255 flags=inactive slider insert_navigation_packets (bool) : default=0 value=0 v4l2-ctl needed no hardcoded knowledge of what the respective drivers (gspca_cpia1 and ivtv) supported to build a UI. Nor did the v4l2-ctl need to go rummaging about in sysfs to find which control applied to which video device node, because the driver simply tell the app upon request: "here are your options for controlling this device". No guesswork on where the control for this device may be located in sysfs, and no exceptional application code to be written just to toggle an illuminator on and off. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 2010-09-05 at 15:54 +0200, Hans de Goede wrote: > 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. I concur with ILLUMINATORS. The word makes it very clear the control is about actively putting light on a subject. A quick Goggle search shows that the term 'illuminator" appears to apply to photography and IR cameras as well. > 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. I saw two use cases mentioned for status LEDs: 1. always off 2. driver automatically controls the LEDs. Can't that choice be handled with a module option, is there a case where one needs more control? Regards, Andy > 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 ? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On 09/05/2010 08:43 PM, Andy Walls wrote: > On Sun, 2010-09-05 at 15:54 +0200, Hans de Goede wrote: >> 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. > > I concur with ILLUMINATORS. The word makes it very clear the control is > about actively putting light on a subject. A quick Goggle search shows > that the term 'illuminator" appears to apply to photography and IR > cameras as well. > > >> 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. > > I saw two use cases mentioned for status LEDs: > > 1. always off > 2. driver automatically controls the LEDs. > > Can't that choice be handled with a module option Sure, just like all other v4l2 controls could be a module option, that is not very userfriendly though. , is there a case where > one needs more control? Not really. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Andy, On Sunday 05 September 2010 20:43:27 Andy Walls wrote: > On Sun, 2010-09-05 at 15:54 +0200, Hans de Goede wrote: > > On 09/05/2010 10:56 AM, Jean-Francois Moine wrote: > > > On Sun, 05 Sep 2010 09:56:54 +0200 Hans de Goede 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. > > I concur with ILLUMINATORS. The word makes it very clear the control is > about actively putting light on a subject. A quick Goggle search shows > that the term 'illuminator" appears to apply to photography and IR > cameras as well. > > > 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. > > I saw two use cases mentioned for status LEDs: > > 1. always off > 2. driver automatically controls the LEDs. > > Can't that choice be handled with a module option, is there a case where > one needs more control? On Logitech UVC cameras, the status led can be set to - always on - always off - controlled by the camera - blinking (with a configurable frequency)
diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index 8408caa..c9b8ca5 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -312,6 +312,13 @@ minimum value disables backlight compensation.</entry> information and bits 24-31 must be zero.</entry> </row> <row> + <entry><constant>V4L2_CID_LEDS</constant></entry> + <entry>integer</entry> + <entry>Switch on or off the LED(s) or illuminator(s) of the device. + The control type and values depend on the driver and may be either + a single boolean (0: off, 1:on) or the index in a menu type.</entry> + </row> + <row> <entry><constant>V4L2_CID_LASTP1</constant></entry> <entry></entry> <entry>End of the predefined control IDs (currently diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h index 61490c6..3807492 100644 --- a/include/linux/videodev2.h +++ b/include/linux/videodev2.h @@ -1045,8 +1045,10 @@ enum v4l2_colorfx { #define V4L2_CID_CHROMA_GAIN (V4L2_CID_BASE+36) +#define V4L2_CID_LEDS (V4L2_CID_BASE+37) + /* last CID + 1 */ -#define V4L2_CID_LASTP1 (V4L2_CID_BASE+37) +#define V4L2_CID_LASTP1 (V4L2_CID_BASE+38) /* MPEG-class control IDs defined by V4L2 */ #define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)