Re: [PATCH 1/3] add feedback LED control

[Jean-Francois Moine <moinejf@free.fr>]

On Sun, 28 Feb 2010 20:38:00 +0100
Németh Márton <nm127@freemail.hu> wrote:

> With a bitfield on and off state can be specified. What about the
> "auto" mode? Should two bits grouped together to have auto, on and
> off state? Is there already a similar control?
> 
> Is the brightness of the background light LEDs adjustable or are they
> just on/off? If yes, then maybe the feedback LEDs and the background
> light LEDs should be treated as different kind.

OK. My idea about switching the LEDs by v4l2 controls was not good. So,
forget about it.

Instead, some job of the led class may be done in the gspca main,
especially register/unregister.

I propose to add a LED description in the gspca structure (level
'struct cam'). There would be 'nleds' for the number of LEDS and
'leds', a pointer to an array of:

	struct gspca_led {
		struct led_classdev led_cdev;
		char led_name[32];
		struct led_trigger led_trigger;
		char trigger_name[32];
	};

(this array should be in the subdriver structure - I don't show the
#ifdef's)

Then, this would work as:

- on probe, in the 'config' function of the subdriver, this one
  initializes the led and trigger fields. The 'led_cdev.name' and
  'led_trigger.name' should point to a sprintf format with one
  argument: the video device number (ex: "video%d::toplight").

- then, at the end of gspca_dev_probe(), the gspca main creates the real
  names of the leds and triggers, and does the register job.

- all led/trigger events are treated by the subdriver, normally by a
  workqueue. This one must not be the system workqueue.

- on disconnection, the gspca main unregisters the leds and triggers
  without calling the subdriver. In the workqueue, the disconnection
  can be simply handled testing the flag 'present' after each subsystem
  call.

Cheers.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/