On Mon, 16 Oct 2023, Miguel Ojeda <miguel.ojeda.sandonis@xxxxxxxxx> wrote: > On Fri, Oct 13, 2023 at 9:56 PM Pavel Machek <pavel@xxxxxx> wrote: >> >> 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.) There's force feedback, there could be light feedback? There's also drivers/input/input-leds.c for the keycaps that have leds, like caps lock, num lock, etc. Anyway, just throwing ideas around, no strong opinions, really. BR, Jani. -- Jani Nikula, Intel