On Fri, Jan 19, 2024 at 12:51:21PM +0200, Jani Nikula wrote: > On Fri, 19 Jan 2024, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > > For per key controllable rgb LEDs we need to discuss a coordinate > > system. I propose using a fixed size of 16 rows of 64 keys, > > so 64x16 in standard WxH notation. > > > > And then storing RGB in separate bytes, so userspace will then > > always send a buffer of 192 bytes per line (64x3) x 14 rows > > = 3072 bytes. With the kernel driver ignoring parts of > > the buffer where there are no actual keys. > > > > I would then like the map the standard 105 key layout onto this, > > starting at x.y (column.row) coordinates of 16.6 (with 0.0 being > > the top left). Leaving plenty of space on the left top and right > > (and some on the bottom) for extra media key rows, macro keys, etc. > > > > The idea to have the standard layout at a fixed place is to allow > > userspace to have a database of preset patterns which will work > > everywhere. > > > > Note I say standard 105 key layout, but in reality for > > defining the standardized part of the buffer we should > > use the maximum amount of keys per row of all the standard layouts, > > so for row 6 (the ESC row) and for extra keys on the right outside > > the main block we use the standard layout as shown here: > > Doesn't the input stack already have to have pretty much all of this > already covered? I can view the keyboard layout in my desktop > environment, and it's a reasonably accurate match, even if unlikely to > be pixel perfect. But crucially, it has to have all the possible layouts > covered already. The kernel actually is not aware of the keyboard geometry, it had no idea if you are dealing with a standard full 101/102 keys keyboard, TKL or even smaller one, if it is split or not, maybe something like Kinesis Advantage360. Arguably, it could potentially know about 101/TLK if vendors would program accurate descriptors into their devices, but nobody does... And geometry is not a part of HID interface at all. So your desktop environment makes an [un]educated guess. > > And while I would personally hate it, you can imagine a use case where > you'd like a keypress to have a visual effect around the key you > pressed. A kind of force feedback, if you will. I don't actually know, > and correct me if I'm wrong, but feels like implementing that outside of > the input subsystem would be non-trivial. Actually I think it does not belong to the input subsystem as it is, where the goal is to deliver keystrokes and gestures to userspace. The "force feedback" kind of fits, but not really practical, again because of lack of geometry info. It is also not really essential to be fully and automatically handled by the kernel. So I think the best way is to have an API that is flexible enough for the userspace solution to control, and that is not restricted by the input core design. The hardware drivers are not restricted to using a single API, they can implement both an input device and whatever new "rgbled" and userspace can associate them by topology/sysfs. > > Cc: Dmitry, could we at least have some input from the input subsystem > POV on this? AFAICT we have received none. Sorry, I was not CCed and I missed this on the mainling list. Thanks. -- Dmitry
