Razer HID Driver Coming To Linux 5.18 For Dealing With Non Spec Compliant Hardware

[phoronix]

Phoronix: Razer HID Driver Coming To Linux 5.18 For Dealing With Non Spec Compliant Hardware

Thanks to Red Hat engineer Jelle van der Waa, the hid-razer driver is set to be merged into Linux 5.18 next month for dealing with Razer hardware not complying with the HID standard...

https://www.phoronix.com/scan.php?page=news_item&px=Razer-HID-For-Linux-5.18

[kylew77]

Why help support a vendor who doesn't care about FLOSS software and operating systems? Seems like it is enabling them to produce other crap hardware that is not standards compliant.

[Ironmask]

Why help support a vendor who doesn't care about FLOSS software and operating systems? Seems like it is enabling them to produce other crap hardware that is not standards compliant.

Because if nothing works on Linux then nobody will use Linux so therefor nobody will make hardware that works on Linux, it's a vicious cycle. Linux cannot afford any clout on the desktop space, it's virtually non-existent there. If it doesn't go out of it's way to support things indifferent to it, then nobody will ever care about it.

[nazar-pc]

Why help support a vendor who doesn't care about FLOSS software and operating systems? Seems like it is enabling them to produce other crap hardware that is not standards compliant.

It is not about encouraging vendor, it is about helping users that ended up buying a hardware before they knew vendor didn't map buttons properly. Otherwise users will end up mad at Linux distro, Linux in general, will throw away the keyboard to get another one (if not selling second-hand) or will install Windows instead in the worst case.

Either way, it will be the user who suffers, not the vendor if this is not handled properly. I agree this is unfortunate, but it is what it is.

[Hi-Angel]

This new driver will ensure the macro keys are mapped to XF86tools and XF86Launch5

I read the commit otherwise though. It says, quoting:

by default, these are mapped to XF86Tools and XF86Launch5 - XF86Launch8. The driver remaps them by default to macro keys with an option to retain the old mapping

As I read, it's saying XF86tools..XF86Launch5 were the old mappings, whereas the driver maps them now to macro keys (whatever that is).

[kylew77]

It is not about encouraging vendor, it is about helping users that ended up buying a hardware before they knew vendor didn't map buttons properly. Otherwise users will end up mad at Linux distro, Linux in general, will throw away the keyboard to get another one (if not selling second-hand) or will install Windows instead in the worst case.

Either way, it will be the user who suffers, not the vendor if this is not handled properly. I agree this is unfortunate, but it is what it is.

This is a fair point, it is not fair but makes sense.

[gavron]

Long time FOSS evangelist, not first time poster.

Thank you to RedHat and Dev van der Waa. For making this happen. I've actually read everyone
else's posts before posting, to get more of a perspective.

A question I have is WHY nearly two decades after HID is a thing the keyboard (the USB/HID least
stressed member, not even with 8K refreshes) is not functional out of the box.

I get the part where people buy this, so we Linux/FOSS people want to make it work for them. Sure.
What I don't get is where the MFG 'chose' or 'misconfigured' or 'didn't do it right' so that the keyboard
wouldn't work out of the box.

WHY???

So good on RH and Mr. Van der Waa. It's always better to be liberal in what we accept, and another
in-kernel driver won't hurt. But why is it a thing that needs doing in 2022?

Ehud

[puleglot]

That way vendors can force users to install drivers and collect some telemetry I guess.

Personally I'm avoiding keyboards from gaming brands. And there are also good gaming mices that doesn't have a vendor driver even on Windows, e.g. Zowie.

[yump]

Long time FOSS evangelist, not first time poster.

Thank you to RedHat and Dev van der Waa. For making this happen. I've actually read everyone
else's posts before posting, to get more of a perspective.

A question I have is WHY nearly two decades after HID is a thing the keyboard (the USB/HID least
stressed member, not even with 8K refreshes) is not functional out of the box.

I get the part where people buy this, so we Linux/FOSS people want to make it work for them. Sure.
What I don't get is where the MFG 'chose' or 'misconfigured' or 'didn't do it right' so that the keyboard
wouldn't work out of the box.

WHY???

So good on RH and Mr. Van der Waa. It's always better to be liberal in what we accept, and another
in-kernel driver won't hurt. But why is it a thing that needs doing in 2022?

Ehud

The way I read it, the keyboard *is* essentially functional out of the box. It's just that, instead of the officially-defined macro keycodes, the macro keys send bogus keycodes that are specifically intended to be assigned to things like "expose" and "search". The thing is, anybody who wants to map macro keys to do something is going to have to set up the keybinding manually anyway. In which case, it barely matters what keycode the macro keys send, as long as they're all different and don't collide with any other key on the keyboard.