From: Hans de Goede <hdegoede@redhat.com>
To: "Enrico Weigelt, metux IT consult" <lkml@metux.net>,
leo60228 <leo@60228.dev>,
platform-driver-x86@vger.kernel.org, linux-leds@vger.kernel.org,
linux-input@vger.kernel.org
Subject: Re: [PATCH v2] platform/x86: add support for Acer Predator LEDs
Date: Wed, 16 Jun 2021 19:50:07 +0200 [thread overview]
Message-ID: <0148a2e3-c91e-7422-df3d-6942c38334ed@redhat.com> (raw)
In-Reply-To: <62d2de8d-e539-5b4f-447a-5e6116844992@metux.net>
Hi,
On 6/16/21 7:20 PM, Enrico Weigelt, metux IT consult wrote:
> On 16.06.21 17:56, leo60228 wrote:
>>> Can you please tell a bit more what these LEDs are actually used for ?
>>> Do they have some names or symbols ? Are they also controlled by
>>> something else (e.g. numlock or shiftlock leds)
>>
>> They're used for the keyboard backlight. This functionality is pretty common on gaming laptops.
>
> hmm, keyboard backlight ... don't we already have something for that
> in input subsys ? I believe that some lone LEDs aren't the right subsys
> for those stuff.
Actually the standardized userspace API for exporting keyboard backlights
is using the LED class sysfs API, e.g.:
cat /sys/class/leds/tpacpi\:\:kbd_backlight/brightnes
And the same for Dell and other kbd backlights, also the upower
daemon even has code for dealing with kbd-backlights:
https://gitlab.freedesktop.org/upower/upower/-/blob/master/src/up-kbd-backlight.c
exporting them over its dbus API so that non-root users can
control them.
Basically using the LED class for kbd-backlight functionality
basically is the defacto standard under Linux, so exposing this
through the LED class is definitely the right thing to do.
Since these are zones however, we probably wat to avoid the
kbd_backlight suffix of the name, otherwise upower will
pick the first device it enumerates and control that, while
leaving the other zones alone, which is not what we want.
Regards,
Hans
next prev parent reply other threads:[~2021-06-16 17:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210615221931.18148-1-leo@60228.dev>
[not found] ` <20210616005147.26212-1-leo@60228.dev>
[not found] ` <87e6f17f-3d82-ac63-b5eb-e7f3205f59e8@metux.net>
[not found] ` <ae4e7db3-ffc5-b8f3-c08c-bba6882d44ad@60228.dev>
2021-06-16 17:20 ` [PATCH v2] platform/x86: add support for Acer Predator LEDs Enrico Weigelt, metux IT consult
2021-06-16 17:50 ` Hans de Goede [this message]
2021-06-21 19:23 ` Enrico Weigelt, metux IT consult
2021-06-21 19:43 ` Hans de Goede
2021-06-22 10:19 ` input devices vs. keyboard backlights [WAS: [PATCH v2] platform/x86: add support for Acer Predator LEDs] Enrico Weigelt, metux IT consult
2021-06-22 10:46 ` Hans de Goede
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=0148a2e3-c91e-7422-df3d-6942c38334ed@redhat.com \
--to=hdegoede@redhat.com \
--cc=leo@60228.dev \
--cc=linux-input@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=lkml@metux.net \
--cc=platform-driver-x86@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).