[FEATURE] Querying rogauracore state

[thorhop]

Feature discussion

One thing I want to do is create a gnome extension, whereby settings can be adjusted through an applet in the upper bar. Set modes, select colours using a colour wheel, a brightness slider, all in the system menu. The idea poses a couple of problems however...

Problem

It requires that applications can query for the current state of rogauracore, i.e which mode, speed and colour(s) are in use. But how should that be done? rogauracore could for example run as a daemon in the background and receive changes through dbus. This might be a bit too much to begin with. An easier alternative is to add a status parameter to the commandline, which could output the data necessary to have an overview of the current state. For example:

Example solution

$ rogauracore status
mode: single_colourcycle
speed: 2
colours: null

This is simple and programatical. Since the mode is single_colourcycle there is no colour defined, i.e it outputs "null". Alternatively a state file could be setup in /tmp or /var/run called rogauracore.state, which is reset everytime rogauracore runs. This way the file only needs to be parsed instead of constantly launching rogauracore itself.

Ideally there should be a dbus implementation, but that is a hard nut to crack. Making rogauracore into a daemon or system service requires a fair bit of testing and coding. Relying on either a status command or a state file would be easier in regards to cross-platform compatibility (see #4 ).

I'm not that good at coding, but would gladly try to implement this feature. I just want to be sure of which direction to take.

[wroberts]

So reading the current state is going to be a bit tricky. I got the aura core protocol by reverse engineering, sniffing the USB packets sent by the Windows 10 app to the keyboard. I'm fairly confident I never saw Windows query the RGB state; rather, when the app starts up, the keyboard's state immediately changes to match what the app displays. It's possible that there are USB messages to fetch state, but I don't know what they are. The code may inspire someone to take an educated guess (0x5d followed by 0xb0 or 0xb1 or 0xb2?). The prototype directory has some Python code that's not hard to modify, and could allow some of these ideas to be tested. Personally, I'm a bit hesitant to experiment with this since my hardware is also my daily driver and a machine that I need for work. I'll leave this issue open in case we can make progress here.

I'd also have a preference for the status variant for querying, instead of a daemon process (although both would be technically possible). The reason for this is that rogauracore needs to detach the keyboard from the kernel to change the RGB state, so we only want to talk to the RGB controller for as long as we need to. During the time we're connected to the keyboard, the kernel won't get keyboard events; a background daemon that periodically chatted with the controller would manifest as mysteriously dropped keypress events, etc. Not worth it, IMHO. Better to have some daemon process (possibly attached to the dbus) that invokes rogauracore when the user needs to find out something or change something.

[thorhop]

Gotcha. A simple short-term solution would be to just set rogauracore at every login according to a user variable, or even a .desktop file in config somewhere. But a simple waking daemon would also be a cool idea. I'm actually interested in learning more about Linux administration (as I need to brush up), so I'll learn more about systemd daemons, dbus and udev. Once I've figured out a safe, minimal solution I'll get back to you.

[markusressel]

I would also be interested to know if this is possible.

I am currently trying to incorporate basic color and brightness functionality into my little project markusressel/keyboard-backlight-daemon. So far this repository has been extremely helpful in getting it to work, so thank you for your efforts :+1: