On Wednesday 13 January 2016 20:10:30 Pavel Machek wrote:
> On Wed 2016-01-13 20:07:36, Pavel Machek wrote:
> > On Wed 2016-01-13 09:54:55, Pali Rohár wrote:
> > > On Tuesday 12 January 2016 22:58:04 Pavel Machek wrote:
> > > > Hi!
> > > >
>
> > > > Next question is.. apparently there are some keyboards that have
> > > > per-key RGB backlight... but maybe we can just call that "weird
> > > > enough" and ignore...
> > >
> > > First we need to defines stable kernel ABI for keyboard backlight. And I
> > > suggest to use existing convention used by upower/console-kit and other
> > > userspace apps...
> >
> > Hmm... I'm not sure that can be done. What were the masks used by
> > upower again? Will upower write to all 6 leds if we present them?
>
> Got it...
>
> It has function up_kbd_backlight_find() which do:
>
> /* find a led device that is a keyboard device */
> while ((filename = g_dir_read_name (dir)) != NULL) {
> if (g_strstr_len (filename, -1, "kbd_backlight") != NULL) {
> dir_path = g_build_filename ("/sys/class/leds",
> filename,
> NULL);
> break;
>
> That suggests that it stops at the first matching device. Adding new
> "virtual" led controlling 6 physical leds would be ugly. So... new
> interface should be done.
>
> Pavel
Yes, it would be ugly, but lp5523 is already ugly... it can accept
numeric value, trigger and also program in bytecode either via sysfs or
via request_firmware... Another virtual led control should not be
problem for this :-)
--
Pali Rohár
pali.rohar@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
