Future handling of complex RGB devices on Linux v2

[Werner Sembach]

Hi,

so after more feedback from the OpenRGB maintainers I came up with an even more 
generic proposal: 
https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1753072869

Copy pasting the relevant part:

>Another, yet more generic, approach:
>
>```
>get-device-info ioctl returning:
>{
>    char name[64]                /* Device model name / identifier */
>    enum device_type            /* e.g. keyboard, mouse, lightbar, etc. */
>    char firmware_version_string[64]    /* if known to the driver, empty 
otherwise */
>    char serial_number[64]            /* if known to the driver, empty 
otherwise */
>    enum supported_commands[128]        /* comands supported by the firmware */
>}
>
>evaluate-set-command ioctl taking:
>{
>    enum command                /* one of supported_commands */
>    union data
>    {
>        char raw[3072],
>        {
>            <input struct for command 0>
>        },
>        {
>            <input struct for command 1>
>        },
>        ...
>    }
>}
>
>evaluate-get-command ioctl taking:
>{
>    enum command                /* one of supported_commands */
>    union data
>    {
>        char raw[3072],
>        {
>            <input struct for command 0>
>        },
>        {
>            <input struct for command 1>
>        },
>        ...
>    }
>}
>and returning:
>{
>    union data
>    {
>        char raw[3072],
>        {
>            <return struct for command 0>    /* not every command might have 
one */
>        },
>        {
>            <return struct for command 1>    /* not every command might have 
one */
>        },
>        ...
>    }
>}
>```
>
>- char name[64] still includes, if know to the driver, information about 
physical or even printed layout.
>- differentiation between evaluate-set-command and evaluate-get-command is 
mainly there for performance optimization for direct mode (for 
evaluate-set-command the kernel does not have to copy anything back to userspace)
>- commands without a return struct must not be used with evaluate-get-command
>- the input struct might be empty for very simple commands (or "int unused" to 
not confuse the compiler if neccessary)
>
>Now is the question: How does userspace know which commands takes/returns 
which structs? Define them in one big header file (as struct 
clevo_set_breathing_mode_1_input, struct tongfang_set_breathing_mode_1_input, 
etc.), or somehow dynamicaly? I'm warming up to Hans suggestion to just do it 
statically, unlike my suggestion yesterday.
>
>Min/Max values are documented in the header file (if not implied by variable 
type). With different max value -> different command, e.g. 
clevo_set_breathing_mode_1 for devices with speed from 0 to 7 and 
clevo_set_breathing_mode_2 for devices with speed from 1 to 10.

But at this point it is almost a generic interface that can be used to expose 
anything to userspace, looping back to the sanitized-wmiraw idea that was 
floating around earlier.

So a new approach (Please correct me if there is already something similar I'm 
not aware of):

New subsystem "Platform Device Commands" (short platdevcom) (I'm open for better 
name suggestions):

- Registers /sys/class/platdevcom/platdevcom[0-9]* (similar to hidraw)
- Has get-device-info ioctl, evaluate-set-command ioctl, and 
evaluate-get-command ioctl as described above
- device_type enum entries for rgb would be for example rgbleds_keyboard, 
rgbleds_mouse, etc.

On a high level this subsystem can be used to expose any platform functionality 
to userspace that doesn't fit another subsystem in a central location. This 
could be for example a nearly 1 to 1 sanitized mapping to wmi calls. Or writing 
a specific EC register to control OEM BIOS features like flexi charging (only 
charge battery to specific percentage to extend the live).

However I am aware that this is hardly an api. So Maybe it's best to just fall 
back on extending the leds subsystem with the deactivate command, and from there 
just implement the few rgb devices that are not hidraw as misc devices in a per 
OEM fasion without a unified api.