Future handling of complex RGB devices on Linux v2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux