Linux LED subsystem development
 help / color / mirror / Atom feed
From: Werner Sembach <wse@tuxedocomputers.com>
To: linux-leds@vger.kernel.org
Subject: Clarification questions regarding multicolor leds
Date: Fri, 19 Aug 2022 09:45:02 +0200	[thread overview]
Message-ID: <30cbbf20-08cf-a69b-4f58-359a9802e86f@tuxedocomputers.com> (raw)

Hi,

I'm currently implementing the multicolors sysfs leds interface for 
several Clevo and Tongfang barebones, but I'm unsure how to actually map 
the leds to the multicolor interface:

The keyboards come in 5 variants:

Single zone RGB + Brightness

Single Zone RGB

3 Zone RGB + Shared Brightness

Per Key RGB

Per Key RGB + Shared Brightness

First question: How do I map multiple zones or per-key leds?

Should I register a seperate ::kbd_backlight for zone/key? resulting in 
::kbd_backlight, ::kbd_backlight_1, ::kbd_backlight_2, 
::kbd_backlight_3, etc?

Should I give them more desciptive names like ::kbd_backlight_left, 
::kbd_backlight_center, ::kbd_backlight_right, ::kbd_backlight_a, 
::kbd_backlight_b, ::kbd_backlight_enter?

Or Should I only create a single ::kbd_backlight instance and map the 
different zones to subleds? So there are number of zones * 3 subleds, 
with each tripplet controlling the rgb values of one zone/key? This 
would help performance, as for the per-key backlight, the firmware in 
the backend wants an array for all keys at once. So setting each key 
seperatly would mean sending the whole array for each key individually. 
And I think what most people want to do is to set the whole keyboard at 
once anyway and nit key by key.

Second question: For the keyboards with shared brightness, is it ok to 
have the brightness values of ::kbd_backlight, ::kbd_backlight_1 etc. 
just in sync? I did not see a way to have a ::kbd_backlight without the 
brightness sysfs entry (then I would have just given the brightness 
switch to ::kbd_backlight and not to ::kbd_backlight_1 and 
::kbd_backlight_2)

Third question: The 3 zone RGB and the per-key keyboards have firmware 
accelerated modes, like breathing and rainbow. How do I make them 
accessible via the multicolor leds interface? the blinking pattern 
interface does not really match the usecase as these modes are a simple 
single value toggle (0=static color, 1=breathing, 2=ignore color 
settings and play predefined moving rainbow pattern, etc).

Forth question: What is actual the purpose of mc_subled.brightness and 
mc_subled.channel?

Kind regards,

Werner


             reply	other threads:[~2022-08-19  7:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-19  7:45 Werner Sembach [this message]
2022-08-19 10:20 ` Clarification questions regarding multicolor leds Werner Sembach
2022-08-21 18:18 ` Pavel Machek
2022-08-22 12:33   ` Werner Sembach
2022-09-18 15:06 ` Jacek Anaszewski

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=30cbbf20-08cf-a69b-4f58-359a9802e86f@tuxedocomputers.com \
    --to=wse@tuxedocomputers.com \
    --cc=linux-leds@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