[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9851a06d-956e-4b57-be63-e10ff1fce8b4@tuxedocomputers.com>
Date: Tue, 30 Jan 2024 19:09:51 +0100
From: Werner Sembach <wse@...edocomputers.com>
To: Hans de Goede <hdegoede@...hat.com>, Pavel Machek <pavel@....cz>
Cc: Jani Nikula <jani.nikula@...ux.intel.com>, jikos@...nel.org,
Jelle van der Waa <jelle@...aa.nl>,
Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Lee Jones <lee@...nel.org>,
linux-kernel@...r.kernel.org,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
linux-input@...r.kernel.org, ojeda@...nel.org, linux-leds@...r.kernel.org
Subject: Re: Implement per-key keyboard backlight as auxdisplay?
Hi Hans,
resend because Thunderbird htmlified the mail :/
Am 30.01.24 um 18:10 schrieb Hans de Goede:
> Hi Werner,
>
> On 1/30/24 12:12, Werner Sembach wrote:
>> Hi Hans,
>>
>> Am 29.01.24 um 14:24 schrieb Hans de Goede:
<snip>
>> I think that are mostly external keyboards, so in theory a possible cut could also between built-in and external devices.
> IMHO it would be better to limit /dev/rgbledstring use to only
> cases where direct userspace control is not possible and thus
> have the cut be based on whether direct userspace control
> (e.g. /dev/hidraw access) is possible or not.
Ack
<snip>
>> So also no basic driver? Or still the concept from before with a basic 1 zone only driver via leds subsystem to have something working, but it is unregistered by userspace, if open rgb wants to take over for fine granular support?
> Ah good point, no I think that a basic driver just for kbd backlight
> brightness support which works with the standard desktop environment
> controls for this makes sense.
>
> Combined with some mechanism for e.g. openrgb to fully take over
> control as discussed. It is probably a good idea to file a separate
> issue with the openrgb project to discuss the takeover API.
I think the OpenRGB maintainers are pretty flexible at that point, after all
it's similar to enable commands a lot of rgb devices need anyway. I would
include it in a full api proposal.
On this note: Any particular reason you suggested an ioctl interface instead of
a sysfs one? (Open question as, for example, I have no idea what performance
implications both have)
<snip>
>> I opened an issue regarding this:https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916
> Great, thank you.
First replies are in.
> Regards,
>
> Hans
Kind regards,
Werner
Powered by blists - more mailing lists