If I had no problem with devoting the time and money, contributing to the kernel (especially in a topic as obscure as making the extra buttons work on a 20-year-old laptop) is at the top of my bucket list, and I am definitely going to be doing it in the near future when my calendar clears up a bit.
Exquisite write-up and OP's simple writing has a motivating ring to it, and I'm now on the local used marketplace looking for pieces of tech like this :-)
We might have a different definition of issue.. I think 100% compatibile working would be launching bloatware installed by the manufacturer. I'm happy not to have the pavlovian training that may some day cause me to click one of these things on someone's windows machine.
I think it's more of the buttons perform specialized tricks to launch bloatware in Windows.
Some of the issue here is the keys themselves have almost no standardization, even across models. Hell, possibly in the same model sometimes. Some backend windows driver captures these signals via a 50 mile long series of if statements that make grown men weep when viewed. This later can mean your totally working fix for the kernel doesn't actually work on a 1/3rd of that fleet of laptops.
> I think it's more of the buttons perform specialized tricks to launch bloatware in Windows.
The linked article is discussing play/pause buttons as well as a "mode-switch" button that allows the play/pause button to have a second function. I do not understand how any of these regular functions become bloatware in your estimation.
> Some of the issue here is the keys themselves have almost no standardization, even across models.
There is actually widespread standardization, which is why many important keys work by default. Laptops sometimes have buttons to disable the internal wifi or adjust the keyboard brightness. These keys are less universal, but still hard to categorize as bloatware.
> ome backend windows driver captures these signals via a 50 mile long series of if statements that make grown men weep when viewed.
I don't know any grown men who would weep when viewing this. I'm confused that you do not like a simple solution (if statements, which a computer has zero problems following precisely even if it is complex to you) nor the complex solution ("bloatware")
> This later can mean your totally working fix for the kernel doesn't actually work on a 1/3rd of that fleet of laptops.
Most devices used in fleets are well-supported in linux after a few years, specifically because of users like the linked article who spend time making buttons worked when pressed.
This was a fun read, and well written. Thanks for sharing! Adding/improving support for some niche piece of hardware sounds like an ideal way to get started with kernel development, and something I'd like to try myself sometime.
This was an absolutely awesome post, and it makes me want to do the work to fix the functionality on my Lenovo laptop. Though I'm sure the Lenovo drivers are a little more closely watched, so I'll make sure to do my due diligence first. Thank you for the write up!
I too went on this adventure with my laptop. Sadly I hit a wall while reverse engineering the ACPI stuff. With no logs, error messages or tools on the Windows side to intercept the ACPI events, I was at a loss but eventually gave up. Massive respect for managing it with your own laptop!!
I did manage to reverse engineer the keyboard's LEDs and drive them from user space! Studied the kernel to make a contribution but decided not to do so when I saw comments saying it is better to keep functionality in user space if at all possible.
I've been procrastinating a trivial fix for years, thanks for having listed the commands to run to format and send the patch, that might help me find my way out from procrastination because this is exactly what's been blocking me.
Thanks! I haven't, but I probably should, since you're the second person asking about it. The site is built with Zola[0], and it's using the Radion[1] theme, with small modifications.
This is the easiest way to hire engineers with high quality open source contributions with a public track record.
All it takes is just to check that the commit shows up in upstream projects such as Linux and anyone can see the code, the reviews and the authors email in the AUTHORS file which verify that this contribution / patch is indeed from the author who committed that change.
This is a very old form of social proof which saves lots time and makes Leetcode redundant. (Which can now be completely cheated with LLMs.)
Exquisite write-up and OP's simple writing has a motivating ring to it, and I'm now on the local used marketplace looking for pieces of tech like this :-)
Maybe you won't find an issue as simple as fixing a button, though.
Every laptop I've used with linux has had a few non-functioning buttons and keys. I think you underestimate the widespread issue.
Making a physical button work requires bloatware in your understanding?
> I'm happy not to have the pavlovian training that may some day cause me to click one of these things on someone's windows machine.
Do you know what you're trying to say here? I do not.
Some of the issue here is the keys themselves have almost no standardization, even across models. Hell, possibly in the same model sometimes. Some backend windows driver captures these signals via a 50 mile long series of if statements that make grown men weep when viewed. This later can mean your totally working fix for the kernel doesn't actually work on a 1/3rd of that fleet of laptops.
The linked article is discussing play/pause buttons as well as a "mode-switch" button that allows the play/pause button to have a second function. I do not understand how any of these regular functions become bloatware in your estimation.
> Some of the issue here is the keys themselves have almost no standardization, even across models.
There is actually widespread standardization, which is why many important keys work by default. Laptops sometimes have buttons to disable the internal wifi or adjust the keyboard brightness. These keys are less universal, but still hard to categorize as bloatware.
> ome backend windows driver captures these signals via a 50 mile long series of if statements that make grown men weep when viewed.
I don't know any grown men who would weep when viewing this. I'm confused that you do not like a simple solution (if statements, which a computer has zero problems following precisely even if it is complex to you) nor the complex solution ("bloatware")
> This later can mean your totally working fix for the kernel doesn't actually work on a 1/3rd of that fleet of laptops.
Most devices used in fleets are well-supported in linux after a few years, specifically because of users like the linked article who spend time making buttons worked when pressed.
Seeing your name in the Linux changelog must be awesome!
I too went on this adventure with my laptop. Sadly I hit a wall while reverse engineering the ACPI stuff. With no logs, error messages or tools on the Windows side to intercept the ACPI events, I was at a loss but eventually gave up. Massive respect for managing it with your own laptop!!
I did manage to reverse engineer the keyboard's LEDs and drive them from user space! Studied the kernel to make a contribution but decided not to do so when I saw comments saying it is better to keep functionality in user space if at all possible.
[0]: https://www.getzola.org/ [1]: https://github.com/micahkepe/radion
All it takes is just to check that the commit shows up in upstream projects such as Linux and anyone can see the code, the reviews and the authors email in the AUTHORS file which verify that this contribution / patch is indeed from the author who committed that change.
This is a very old form of social proof which saves lots time and makes Leetcode redundant. (Which can now be completely cheated with LLMs.)
Did you try to use any AI tools during their process?