Change keyboard backlight from cmd line?

MNT Pocket Reform
21

This works, thanks! Is there anyway to set the led brightness too?

22

Just use darker colours.

1 Like
23

The three numbers are the RGB components (red, green, blue) in hexadecimal, and each number goes from 0 to 255 intensity (but note that instead of RGB it reads BGR, and instead of using decimal numbers it reads hexadecimal values). So “0 0 FF” means no Blue, no Green and Red at full intensity.

2 Likes
24

I love being able to change the keyboard color to amber from the command line with…

printf 'xLRGB\x00\x11\x30' | sudo tee /dev/hidraw0

I’ve been trying to get the same effect via a cron job by adding the code below to my su crontab and have been getting mixed results

@reboot sleep 30 && test -c /dev/hidraw0 && printf 'xLRGB\x00\x11\x30' > /dev/hidraw0

If I use double quotation marks on either side of the xLRGB portion it doesn’t work.

If I use single quotation marks on either side of the xLRGB portion it works, but only changes the keyboard color to cyan no matter the value I’ve added.

Anyone have an idea as to why this may be happening?

25

Try to specify the path for printf, so you are not using any shell builtin, use /usr/bin/printf instead of printf.

1 Like
26

Bingo! That did it. Thanks a million!

For future reference to anyone else, the code below is what worked for in my su crontab. Change the sleep value and the RGB values to whatever you desire.

@reboot sleep 10 && test -c /dev/hidraw0 && /usr/bin/printf 'xLRGB\x00\x11\x30' > /dev/hidraw0
3 Likes
27

I may need to move this to a new thread. I have been playing with the firmware of the keyboard and I think we could edit the firmware to have the default config unless a file is present. If “File” is present the basic color, brightness and timeout for the backlight could be adjusted and polled by the firmware for changes. Would anyone else be interested in these changes?

1 Like
28

Sounds good. I have a script to update mine when I update my wallpaper (using imagemagick to determine a predominant colour, and to change the brightness & saturation) - just not quite happy enough with how it’s working to share it yet.

1 Like
29

I’ve been trying the approach with the different approaches from this thread:

(trying pure red to make the effect really obvious)

test -c /dev/hidraw0 && printf "xLRGB\x00\x00\xFF" > /dev/hidraw0

and

printf 'xLRGB\x00\x00\xFF' | tee /dev/hidraw0

When run from a root shell, both work as expected, but when run from root’s crontab with @reboot (with additional sleep and without) it always turns the light to a mid-brightness white.

Any ideas why?

EDIT:

Nevermind, I wasn’t using absolute paths for /usr/bin/printf as described earlier in this thread. That does the trick. Sorry

30

Man, I now want to make the backlight go red when I am running something as the root user, and back to whatever I’d set it previously when I drop back to my user permissions… (not for every sudo invocation, just when i was in a root shell – this seems very doable)

1 Like
31

I quickly hacked something together for this at uni today:

Æ.: "Neat little MNT Pocket Reform hack: When I launc…" - The Wandering Shop (Mastodon post with demo video)

I used root’s .bashrc and .bash_logout to trigger the color changes when launching and closing a root shell.

It’s not perfect because it’ll return to green when you exit one root shell regardless of whether other root shells are still open. But tbh when you have multiple root shells open at the same time, something else has gone very wrong already :smiley:

7 Likes
32

That’s very very cool.

Depending on the window manager that a given person is using, it may also be possible to do this based on window focus.

Essentially with e.g. sway you can list the set of current windows which will include metadata on which window has focus. If you set the shell profile for the root user to ensure that you’re setting the window title to include some indicator that it’s now a root shell, you can effectively write a polling script to do this based on window titles and focus :slight_smile:

I was thinking about doing something adjacent for being able to duplicate a terminal in Niri (which has RPC inspired by sway, so a solution should be adaptable) and have the new one pick up on the same remote host with the same pwd. If I get around to it I’ll try and loop back round with an example of doing this because I love the concept that y’all have come up with!

33

I tried to go back and give this another shot, but I seem not to understand where I should do this. I entered it in terminal, but that didn’t work. It looks like you have the right command, but how do you insert that line into your crontab?

34

You should be able to run sudo crontab -ewhich will open your su crontab in an editor. If you have multiple editors installed (vim, nano, etc.) and it’s your first time editing crontab, it will ask which editor you want to use.

Once editing crontab, enter this line at the bottom.

@reboot sleep 10 && test -c /dev/hidraw0 && /usr/bin/printf 'xLRGB\x00\x11\x30' > /dev/hidraw0

You may need to increase the sleep function, depending on how long it takes your system to boot.

You can change out xLRGB\x00\x11\x30for whatever color combination you like. Keep in mind that 00 is the absence of light.

Also, your keyboard is probably /dev/hidraw0 , but it could be /dev/hidraw1 or some other number.

35

It would probably be more reliable to look at the symlink /dev/input/by-id/usb-MNT_Pocket_Reform_Input_1.0_*-hidraw because then you know that whatever /dev/hidraw* it is pointing at, it will be a Pocket Reform keyboard.

This sounds super unreliable. Why not instead run the command once the device appears? If you have udev, you can do that via a udev rule, maybe something alone these lines (untested):

ACTION=="add", SUBSYSTEMS=="usb|hidraw", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="6d06", RUN+="printf .... $env{DEVNAME}"

At that point, you also can drop the test -c /dev/hidraw0 because you know that the device exists and it will be $env{DEVNAME}.

36

1.) Mine is “usb-MNT_Pocket_Reform_Input_RP2040-hidraw.” No 0 or 1 by hidraw in the file name. Does that mean I should leave off the number?

2.) Is the stuff in the curly brackets device-specific or is that entered just as you have it typed out?

3.) After printf where you have the “….”, is that where “xLRGB\” parameter goes?

4.) Is udev a separate program or do I access it through the terminal?

Thanks!

37

Yeah, I’m no expert. I cobbled this together from my hobbyist knowledge of linux. It seems to work for me now, but there are probably much better ways of doing it.

@josch maybe you have a better solution that @Khaaan can implement.

38

This works on my pocket:

ACTION=="add", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="6d06", RUN+="/bin/sh -c '/usr/bin/printf \"xLRGB\x00\x11\x30\" > $env{DEVNAME}'"

Wrapping inside a shell command is needed because an udev rule command does not run inside a shell, so piping into the device won’t work.

Used /usr/bin/printf because builtin shell printf, for some reason, does not work (at least for me).

4 Likes
39

Thank you @amospalla for implementing properly what I had in mind! :purple_heart:

Another option would be for reform-power-daemon to manage the backlight color because it’s already in the business of managing the backlight brightness. I left a comment about this on this MR: reform-power-daemon: allow configuring backlight setting (!157) · Merge requests · Reform / MNT Reform Tools · GitLab

3 Likes
40

Thank you Josch for showing how to do it, I just adjusted it a bit.