Dmitry Torokhov, le Thu 22 Jan 2015 16:51:16 -0800, a écrit :
> No. Please take a look at other users of platform data. Platform is the box
> we
> are running on, not parent device. Platform data is supposed to be constant,
> not changing between driver runs.
Ok, well, then we can just use to_in
On Friday, January 23, 2015 01:44:29 AM Samuel Thibault wrote:
> Dmitry Torokhov, le Thu 22 Jan 2015 16:37:02 -0800, a écrit :
> > On Friday, January 23, 2015 01:30:11 AM Samuel Thibault wrote:
> > > Samuel Thibault, le Fri 23 Jan 2015 01:10:38 +0100, a écrit :
> > > > Dmitry Torokhov, le Sun 04 Ja
Dmitry Torokhov, le Thu 22 Jan 2015 16:37:02 -0800, a écrit :
> On Friday, January 23, 2015 01:30:11 AM Samuel Thibault wrote:
> > Samuel Thibault, le Fri 23 Jan 2015 01:10:38 +0100, a écrit :
> > > Dmitry Torokhov, le Sun 04 Jan 2015 15:28:38 -0800, a écrit :
> > > > > + dev = cdev->dev->platf
On Friday, January 23, 2015 01:30:11 AM Samuel Thibault wrote:
> Samuel Thibault, le Fri 23 Jan 2015 01:10:38 +0100, a écrit :
> > Dmitry Torokhov, le Sun 04 Jan 2015 15:28:38 -0800, a écrit :
> > > > + dev = cdev->dev->platform_data;
> > >
> > > Umm, platform data is not the best place for
Samuel Thibault, le Fri 23 Jan 2015 01:10:38 +0100, a écrit :
> Dmitry Torokhov, le Sun 04 Jan 2015 15:28:38 -0800, a écrit :
> > > + dev = cdev->dev->platform_data;
> >
> > Umm, platform data is not the best place for storing this. Why not drvdata?
>
> Ah, actually led_classdev already makes use
Dmitry Torokhov, le Sun 04 Jan 2015 15:28:38 -0800, a écrit :
> > + dev = cdev->dev->platform_data;
>
> Umm, platform data is not the best place for storing this. Why not drvdata?
Ah, actually led_classdev already makes use of it, see the
device_create_with_groups call in led_classdev_register.
Dmitry Torokhov, le Mon 05 Jan 2015 09:42:05 -0800, a écrit :
> The input device's capabilities (with the exception of keymap) should
> not change after device registration. If uinput allows that we should
> fix it there.
Ah, I didn't notice the content of uinput_set_bit() there. It seems to
be m
Hi Samuel,
On Mon, Jan 05, 2015 at 12:45:01AM +0100, Samuel Thibault wrote:
> Dmitry Torokhov, le Sun 04 Jan 2015 15:28:38 -0800, a écrit :
> > I'd rather we did not have a separate config option for this. Do we really
> > need to
> > support case where LEDs are disabled?
>
> I don't really mind
Dmitry Torokhov, le Sun 04 Jan 2015 15:28:38 -0800, a écrit :
> I'd rather we did not have a separate config option for this. Do we really
> need to
> support case where LEDs are disabled?
I don't really mind.
> I'd rather stub it out instead of providing 2 separate code paths.
Ok.
> > +/* LED
Hi Samuel,
On Sat, Dec 27, 2014 at 12:23:10AM +0100, Samuel Thibault wrote:
> This permits to reassign input LEDs to something else than keyboard "leds"
> state, by adding a trigger and a led for each input leds, the former being
> triggered by EV_LED events, and the latter being by default trigge
This permits to reassign input LEDs to something else than keyboard "leds"
state, by adding a trigger and a led for each input leds, the former being
triggered by EV_LED events, and the latter being by default triggered by the
former. The user can then make the LED use another trigger, including ot
11 matches
Mail list logo
