[SOLVED] mouse RGB lighting to be set during boot

archuser_9999 · 2024-09-03 09:50:26

Couldn't see any answers after searching this forum, so:

had to buy a new mouse recently. Ended up with a major-ish brand - SteelSeries Rival 3 not only for reliability (and low cost) but because I'd been struggling with a cheap no-brand Chinese mouse, and felt that firmware/hardware might be better for a more common device.

NOT that I really care about rgb lighting effects, but I thought I'd at least set up the mouse to use a static, single colour to match the keyboard. I can do this using either OpenRGB or rivalcfg, although the former seems unnecessarily bloated for the single purpose, and the latter only works inside a user session (because it appears to not override anything set during boot/udev). I much prefer not to cmd OpenRGB via .xinitrc, I want the mouse colour to be set while Xorg is setting up the devices - assuming this is possible. I note that my keyboard firmware seems to do this during boot.

The relevant section of my /etc/X11/xorg.conf looks like this

Section "ServerLayout"
	Identifier     "X.org Configured"
	Screen      0  "Screen0" 0 0
	InputDevice    "Mouse0" "CorePointer"
	InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
	ModulePath   "/usr/lib/xorg/modules"
	FontPath     "/usr/share/fonts/misc"
	FontPath     "/usr/share/fonts/TTF"
	FontPath     "/usr/share/fonts/OTF"
	FontPath     "/usr/share/fonts/Type1"
	FontPath     "/usr/share/fonts/100dpi"
	FontPath     "/usr/share/fonts/75dpi"
EndSection

Section "Module"
	Load  "glx"
EndSection

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "kbd"
EndSection

Section "InputDevice"
	Identifier  "Mouse0"
	Driver      "mouse"
	Option	    "Protocol" "auto"
	Option	    "Device" "/dev/input/mice"
	Option	    "ZAxisMapping" "4 5 6 7"
EndSection

My question is:

am I correct in thinking that I can/should be adding an option to "Mouse0" as a drop in at e.g. /etc/X11/xorg.conf.d/10-mouse.conf ? or do I achieve this some other way? Or is this not possible in fact?

Last edited by archuser_9999 (2024-09-03 10:51:42)

V1del · 2024-09-03 10:08:35

Xorg is absolutely and entirely irrelevant for any LED ligthing purposes. Moreover that xorg config as it is written only contains deprecated tooling and shouldn't be used as such in any way, get rid of it.

For the actual issue, openrgb is both a GUI client and a server component, the server component will do what you want. You can configure the static info in the GUI client, save that and enable the openrgb server to load said config on startup, via

systemctl enable openrgb

If you consider that overkill, starting rivalcfg as part of your .xinitrc sounds fine, if you want this to be more dynamic you'd have to get into udev rules (potentially DBUS/xorg session variables...)

Edit: looking at the rivalcfg tool, it should come with tooling to directly enable this, i.e. if you run your corresponding led change command as root together with --update-udev will likely correctly configure such a drop-in) ... or if it doesn't you can create a udev rule that executes the corresponding rivalcfg command: https://wiki.archlinux.org/title/Udev#About_udev_rules

Last edited by V1del (2024-09-03 10:31:50)

archuser_9999 · 2024-09-03 10:41:06

Oh! Thank you, how extremely helpful!

I'd somehow missed the part about using OpenRGB as a system unit. Will do this now.

You have however raised another interesting, possibly important issue in that you say the Xorg config file "only contains deprecated tooling". Fine, I have no trouble at all accepting this, but as someone who only ever looks into the documentation around Xorg out of absolute necessity (and even then it's dense, and layered, and I end up reading everything three times) I just this morning generated a new config file following the current page on the ArchWiki. I copied this file into /etc/X11/xorg.conf. Now I learn that it's irrelevant because deprecated? Do I need anything in this file at all? (being serious). The complete file below (it's not long). If there's anything I shouldn't be using, please feel free to let me know. I simply trusted the Xorg server to set everything up for me I update daily):

Section "ServerLayout"
	Identifier     "X.org Configured"
	Screen      0  "Screen0" 0 0
	InputDevice    "Mouse0" "CorePointer"
	InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
	ModulePath   "/usr/lib/xorg/modules"
	FontPath     "/usr/share/fonts/misc"
	FontPath     "/usr/share/fonts/TTF"
	FontPath     "/usr/share/fonts/OTF"
	FontPath     "/usr/share/fonts/Type1"
	FontPath     "/usr/share/fonts/100dpi"
	FontPath     "/usr/share/fonts/75dpi"
EndSection

Section "Module"
	Load  "glx"
EndSection

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "kbd"
EndSection

Section "InputDevice"
	Identifier  "Mouse0"
	Driver      "mouse"
	Option	    "Protocol" "auto"
	Option	    "Device" "/dev/input/mice"
	Option	    "ZAxisMapping" "4 5 6 7"
EndSection

Section "Monitor"
	Identifier   "Monitor0"
	VendorName   "Monitor Vendor"
	ModelName    "Monitor Model"
EndSection

Section "Device"
        ### Available Driver options are:-
        ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
        ### <string>: "String", <freq>: "<f> Hz/kHz/MHz",
        ### <percent>: "<f>%"
        ### [arg]: arg optional
        #Option     "Accel"              	# [<bool>]
        #Option     "AccelMethod"        	# <str>
        #Option     "Backlight"          	# <str>
        #Option     "CustomEDID"         	# <str>
        #Option     "DRI"                	# <str>
        #Option     "Present"            	# [<bool>]
        #Option     "ColorKey"           	# <i>
        #Option     "VideoKey"           	# <i>
        #Option     "Tiling"             	# [<bool>]
        #Option     "LinearFramebuffer"  	# [<bool>]
        #Option     "HWRotation"         	# [<bool>]
        #Option     "VSync"              	# [<bool>]
        #Option     "PageFlip"           	# [<bool>]
        #Option     "SwapbuffersWait"    	# [<bool>]
        #Option     "TripleBuffer"       	# [<bool>]
        #Option     "XvPreferOverlay"    	# [<bool>]
        #Option     "HotPlug"            	# [<bool>]
        #Option     "ReprobeOutputs"     	# [<bool>]
        #Option     "XvMC"               	# [<bool>]
        #Option     "ZaphodHeads"        	# <str>
        #Option     "VirtualHeads"       	# <i>
        #Option     "TearFree"           	# [<bool>]
        #Option     "PerCrtcPixmaps"     	# [<bool>]
        #Option     "FallbackDebug"      	# [<bool>]
        #Option     "DebugFlushBatches"  	# [<bool>]
        #Option     "DebugFlushCaches"   	# [<bool>]
        #Option     "DebugWait"          	# [<bool>]
        #Option     "BufferCache"        	# [<bool>]
	Identifier  "Card0"
	Driver      "intel"
	BusID       "PCI:0:2:0"
EndSection

Section "Screen"
	Identifier "Screen0"
	Device     "Card0"
	Monitor    "Monitor0"
	SubSection "Display"
		Viewport   0 0
		Depth     1
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     4
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     8
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     15
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     16
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     24
	EndSubSection
EndSection

And, while I'm here and a part of all of this I've never really understood anyway... in attempting to solve this for myself, I read the docs, and installed the xf86-input-evdev driver as an alternative to [xf86-input-libinput just in case that somehow picked up the mouse better? I note that after a restart, Xorg still defaults to the former and not the latter. Maybe I can now remove xf86-input-libinput - which of course I couldn't do while it was the only input driver - and it will use xf86-input-evdev. Or... maybe I'm making things worse and should just leave as default?

It's never ever been at all clear to me why the results of

$ grep -e "Using input driver" $HOME/.local/share/xorg/Xorg.0.log

[    11.963] (II) Using input driver 'libinput' for 'Power Button'
[    11.984] (II) Using input driver 'libinput' for 'Video Bus'
[    11.986] (II) Using input driver 'libinput' for 'Power Button'
[    11.988] (II) Using input driver 'libinput' for 'Sleep Button'
[    11.991] (II) Using input driver 'libinput' for 'SteelSeries SteelSeries Rival 3'
[    12.065] (II) Using input driver 'libinput' for 'SteelSeries SteelSeries Rival 3 Keyboard'
[    12.082] (II) Using input driver 'libinput' for 'Drevo keyboard Drevo keyboard'
[    12.092] (II) Using input driver 'libinput' for 'Drevo keyboard Drevo keyboard Keyboard'
[    12.101] (II) Using input driver 'libinput' for 'Drevo keyboard Drevo keyboard Mouse'
[    12.126] (II) Using input driver 'libinput' for 'SteelSeries SteelSeries Rival 3 Keyboard'
[    12.127] (II) Using input driver 'libinput' for 'Drevo keyboard Drevo keyboard Keyboard'

Do please feel free to direct me to any relevant documentation - I've been reading whatever the Wiki points me to. And perhaps nothing in the above is unusual, but I do not understand why libinput creates both a mouse and keyboard entry for each device, despite of course

 [12.065] 'SteelSeries SteelSeries Rival 3 Keyboard'

is no such device and does not exist, and is not therefore plugged in! Likewise

[12.101] 'Drevo keyboard Drevo keyboard Mouse'

doesn't exist either.

So, issue solved thanks - will mark post accordingly - but now that I'm into this, I would really like to understand what's going on with the Xorg server setting things up in this way.

V1del · 2024-09-03 11:11:38

archuser_9999 wrote:

I'd somehow missed the part about using OpenRGB as a system unit. Will do this now.

See also my edit if you want to opt to do this with rivalcfg directly

Do I need anything in this file at all? (being serious).

The file doesn't need to exist, at all (also serious ) The historical reason is that the xorg configure command stems from a time where the xorg server was not yet able to autoconfigure itself properly and is basically a relict of the time. There even was a time period where the configure command was broken and didn't work, so little relevant usage did it still see. The keyboard and mouse drivers it sets up do not actually exist anymore, and the static config will lead to e.g. new monitors not getting set up automatically.

The "best" course of action unless you know better (or have a specific need, in which case a targeted drop-in is better than a full blown config) is to simply not create any config file, xorg has gotten pretty good at configuring the necessary devices on it's own.

Which also brings us to...

And, while I'm here and a part of all of this I've never really understood anyway... in attempting to solve this for myself, I read the docs, and installed the xf86-input-evdev driver as an alternative to [xf86-input-libinput just in case that somehow picked up the mouse better? I note that after a restart, Xorg still defaults to the former and not the latter. Maybe I can now remove xf86-input-libinput - which of course I couldn't do while it was the only input driver - and it will use xf86-input-evdev. Or... maybe I'm making things worse and should just leave as default?

As before unless you have a specific reasoning, you should stick to xf86-input-libinput. evdev is also deprecated and not further developed anymore (though it's not that old and dead as the "mouse" and "keyboard" drivers are -- and is technically still functional).

As for why it's picked up by default, there are drop-in configs that will pick up libinput first.

It's never ever been at all clear to me why the results of

$ grep -e "Using input driver" $HOME/.local/share/xorg/Xorg.0.log

[    11.963] (II) Using input driver 'libinput' for 'Power Button'
[    11.984] (II) Using input driver 'libinput' for 'Video Bus'
[    11.986] (II) Using input driver 'libinput' for 'Power Button'
[    11.988] (II) Using input driver 'libinput' for 'Sleep Button'
[    11.991] (II) Using input driver 'libinput' for 'SteelSeries SteelSeries Rival 3'
[    12.065] (II) Using input driver 'libinput' for 'SteelSeries SteelSeries Rival 3 Keyboard'
[    12.082] (II) Using input driver 'libinput' for 'Drevo keyboard Drevo keyboard'
[    12.092] (II) Using input driver 'libinput' for 'Drevo keyboard Drevo keyboard Keyboard'
[    12.101] (II) Using input driver 'libinput' for 'Drevo keyboard Drevo keyboard Mouse'
[    12.126] (II) Using input driver 'libinput' for 'SteelSeries SteelSeries Rival 3 Keyboard'
[    12.127] (II) Using input driver 'libinput' for 'Drevo keyboard Drevo keyboard Keyboard'

Does your mouse just have the wheel and the mouse buttons? If not and it has more, then that's the "keyboard" part of the device (... also if the buttons are freely reassignable). similarly, if the "keyboard" has e.g. a "nipple" that would be the mouse part. Or even simpler, the HW manufacturer just using some generic controller that just advertises everything, even if nothing is attached at the "keyboard" or "mouse".

archuser_9999 · 2024-09-03 11:36:15

very cool. Again many thanks - all so much clearer now. Also rather begs the question as to how a basic user such as myself would know to essentially ignore totally whatever the Wiki currently says as, in the case of the page here

Configure Xorg

which I gather should not then exist?

Anyway yes, all finally clear now! Basically the keyboard - a Drevo Tyrfing 88 key mechanical - is something I bought many years ago now, at a time when it was very rare to see a sub 100 euro mechanical keyboard. I still have it (obviously) but many have since entered this price point. So I can accept that it contains 'generic' firmware to some degree (although, to its credit, it does maintain its own colour scheme across poweroffs with no external help), and will upgrade to something with better support when I have the budget.

This mouse is just a standard six button mouse, but now that I understand your further clarifications, I may indeed get busy with creating some macros. With just six buttons I wouldn't normally want to reassign any of these basic functions for obvious reasons. However, because I use the mouse in my DAW a lot... I can see how I could create much more complex keyboard shortcuts, and map them to the "mouse keyboard" in some manner!!

V1del · 2024-09-03 12:43:48

The section you linked to contains at the very beginning

Xorg configuration section wrote:

Note: Arch supplies default configuration files in /usr/share/X11/xorg.conf.d/, and no extra configuration is necessary for most setups.

implying you should only follow the rest of this setup if you have something specific in mind. (you might also want to look at the files that Arch puts there, to see how minimal and targeted configs would look like)

Generally speaking the wiki should contain it as it is an option that might have use, but there's a reason it's listed last and that the section as a whole has that note.

Last edited by V1del (2024-09-03 12:55:20)

Arch Linux

#1 2024-09-03 09:50:26

[SOLVED] mouse RGB lighting to be set during boot

#2 2024-09-03 10:08:35

Re: [SOLVED] mouse RGB lighting to be set during boot

#3 2024-09-03 10:41:06

Re: [SOLVED] mouse RGB lighting to be set during boot

#4 2024-09-03 11:11:38

Re: [SOLVED] mouse RGB lighting to be set during boot

#5 2024-09-03 11:36:15

Re: [SOLVED] mouse RGB lighting to be set during boot

#6 2024-09-03 12:43:48

Re: [SOLVED] mouse RGB lighting to be set during boot

Board footer