Hi Werner,
On 11/21/23 12:33, Werner Sembach wrote:
> Hi,
>
> Am 20.11.23 um 21:52 schrieb Pavel Machek:
>> Hi!
>>
>>>>> So... a bit of rationale. The keyboard does not really fit into the
>>>>> LED subsystem; LEDs are expected to be independent ("hdd led") and not
>>>>> a matrix of them.
>>>> Makes sense.
>>>>
>>>>> We do see various strange displays these days -- they commonly have
>>>>> rounded corners and holes in them. I'm not sure how that's currently
>>>>> supported, but I believe it is reasonable to view keyboard as a
>>>>> display with slightly weird placing of pixels.
>>>>>
>>>>> Plus, I'd really like to play tetris on one of those :-).
>>>>>
>>>>> So, would presenting them as auxdisplay be acceptable? Or are there
>>>>> better options?
>>>> It sounds like a fair use case -- auxdisplay are typically simple
>>>> character-based or small graphical displays, e.g. 128x64, that may not
>>>> be a "main" / usual screen as typically understood, but the concept is
>>>> a bit fuzzy and we are a bit of a catch-all.
>>>>
>>>> And "keyboard backlight display with a pixel/color per-key" does not
>>>> sound like a "main" screen, and having some cute effects displayed
>>>> there are the kind of thing that one could do in the usual small
>>>> graphical ones too. :)
>>>>
>>>> But if somebody prefers to create new categories (or subcategories
>>>> within auxdisplay) to hold these, that could be nice too (in the
>>>> latter case, I would perhaps suggest reorganizing all of the existing
>>>> ones while at it).
>>> One could also reasonably make the argument that controlling the
>>> individual keyboard key backlights should be part of the input
>>> subsystem. It's not a display per se. (Unless you actually have small
>>> displays on the keycaps, and I think that's a thing too.)
>> While it would not be completely crazy to do that... I believe the
>> backlight is more of a display and less of a keyboard. Plus input
>> subystem is very far away from supporting this, and we had no input
>> from input people here.
>>
>> I don't think LED subsystem is right place for this, and I believe
>> auxdisplay makes slightly more sense than input.
>>
>> Unless someone steps up, I'd suggest Werner tries to implement this as
>> an auxdisplay. [And yes, this will not be simple task. RGB on LED is
>> different from RGB on display. But there are other LED displays, so
>> auxdisplay should handle this. Plus pixels are really funnily
>> shaped. But displays with missing pixels -- aka holes for camera --
>> are common in phones, and I believe we'll get variable pixel densities
>> -- less dense over camera -- too. So displays will have to deal with
>> these in the end.]
>
> Another idea I want to throw in the mix:
>
> Maybe the kernel is not the right place to implement this at all. RGB stuff
> is not at all standardized and every vendor is doing completely different
> interfaces, which does not fit the kernel userpsace apis desire to be
> uniformal and fixed. e.g. Auxdisplay might fit static setting of RGB values,
> but it does not fit the snake-effect mode, or the raindrops mode, or the
> 4-different-colors-in-the-edges-breathing-and-color-cycling mode.
>
> So my current idea: Implement these keyboards as a single zone RGB
> kbd_backlight in the leds interface to have something functional out of the
> box, but make it runtime disable-able if something like
> https://gitlab.com/CalcProgrammer1/OpenRGB wants to take over more fine
> granular control from userspace via hidraw.
That sounds like a good approach to me. We are seeing the same with game
controllers where steam and wine/proton also sometimes use hidraw mode to get
access to all the crazy^W interesting features.
That would mean that all we need to standardize and the kernel <-> userspace
API level is adding a standard way to disable the single zone RGB kbd_backlight
support in the kernel.
Regards,
Hans
