Is there a way to remap brightness fn keys on a laptop to run xbacklight?

As title says, I’m looking for a way to change how brightness up and down work on my MSI GT72 laptop. The problem is these keys are recognized by the system, the slider goes up and down, but the screen brightness is not increased or reduced at all. By the other hand, xbacklight works perfectly, but opening a console to increase or decrease the brightness is way slower than just pressing the proper keys.

I tried to add a shortcut on Settings App->Keyboard->Shortcuts->Custom Shortcuts; made one called brightness up and assigned ‘xbacklight -inc 10’ and mapped it to the fn+brightness up key, and did the same for brightness down. After doing that xbacklight command wasn’t being executed, just the old behaviour. Then I changed the mapping to ctrl+fn+brightness up/down using the same commands and the brightness successfully went up or down, but it didn’t trigger the brightness slider or the animation on screen when you increase or decrease brightness.

So I was wondering, as the title says, if there’s a way to change the command that is executed when you press fn + brightness up/down to always use xbacklight instead of whatever is actually running (I assume is doing the classic echo value to /sys/class/acpi_video/brightness and such) Is this possible?

Recommend you start by Googling “linux kernel map hardware keys”

IMO you can’t assume how things work, you’ll need to find information specific to your hardware.
It all starts with how your hardware keys are exposed, and likely at the BIOS level.

Years ago when I was investigating this, I found that at least for my manufacturer (HP) and many others, they wrote this code specifically supporting Windows OS, and then I found that the Linux kernel implemented a special section (I can’t locate the info now, but know it exists) that remaps these low level Windows commands to Linux(likely somewhere in /proc). The contents of this section contain no functionality, only simple configuration files containing mappings… and for the most part contributed by the manufacturers themselves which means spotty support, it’s up to the manufacturer to make these mappings available.

Once you’ve identified exactly how your hardware key functionality is implemented (if it’s available at all) then you can consider re-mapping.

TSU