> One of the unfortunate facts about open source operating systems like Linux is that specialized hardware support sometimes lags behind commercial operating systems like Windows and MacOS.
Well that's just because the manufacturer just doesn't write one, not because of some intrinsic factor of FOSS. That's an odd point to make when it's the manufacturers' fault.
I wonder if it might be time for some legislation around this. Manufacturers are already required to include operating instructions with products they release, so why not protocol specs? They don't need to release anything secret, just the instructions for software to interact with their hardware.
This is an interesting point. While this would be nice for some folks that just want drivers to be functional I could also see why a manufacturer might be reluctant to offer such information. One reason they could bring up is that it may put undue burden on them to document and provide such information. Another possible issue a manufacturer may have with this is that it offers a more direct route for abuse of their software/hardware (maybe?). Or in some cases it may be a liability to offer such information (if there is a potential for misuse)
Edit: or maybe they don’t want to release that kind of info for product/brand lock-in reasons?
> it may put undue burden on them to document and provide such information.
How can documenting something be an undue burden? In order to write the drivers that they do write, for say Windows, they must have written some documentation.
And if I want to abuse some piece of hardware, such as making a musical instrument out of a pile of floppy disk drives, what business is that of the manufacturer?
The documentation is not the burden as much as the requirement, or at least expectation, to adhere to the published specs once they are published. By not releasing any info they are not burdened with having to stay consistent on driver details from one product or version to the next.
I called my ebike company and apparently my year and make could have one of three different batteries. Seems infuriating, but hardware manufacturers don't have to be consistent I guess, just release some new/updated docs?
I wonder if it has to do with any underlying 3rd-party components. Otherwise, yeah, makes no sense.
It might be worth clarifying that Wacom is not taking that approach. But their statement there suggests that the underlying reason for lack of hardware support in Linux is the OpenSource nature of the software.
Well one way that comes to mind for why it could be considered a burden is breaking down internal documentation into public and private, and making sure that the private one is never exposed. As much as we don’t want to imagine business constraints on some manufacturers, they could always come up with reasons.
> And if I want to abuse some piece of hardware, such as making a musical instrument out of a pile of floppy disk drives, what business is that of the manufacturer?
As an example (maybe not a fair one) we can ask Tesla why they don’t want to expose some/all APIs that Tesla owners might want access to. I expect they would bring up a thousand reasons why, maybe safety related, maybe not.
I generally agree with you though, you paid and own something, and you wish to use it as you see fit. Unfortunately it seems like what we think we own and what we actually own are in some cases two separate things.
Some documentation, but when the guy who wrote the hardware is down the hall from the guy writing the documentation it typically isn't very good, saving a lot of effort
Some vendors might also be bundling spyware with their drivers. In that case, releasing hardware info would take the (unjust) power over the users away from them.
> This is an interesting point. While this would be nice for some folks that just want drivers to be functional I could also see why a manufacturer might be reluctant to offer such information.
Well, yeah, the point of regulations is to make companies do things that are not in their direct self-interest, but benefit wider society.
Manufacturers would also be reluctant to comply with planned obsolescence bans, or consumer safety regulations. That's why the regulations must have teeth to them.
They already have the documents. But releasing them would make it easier for a competitor to make a cheaper drop in replacement. It would be a win for consumers though.
Please no. Get the government and their violence out. No one has an inalienable right to APIs and such. You have the right to buy what you want. If the market is not serving you, then look in the mirror and pick your priorities.
The right compromise here is that if the government is going to "protect" the company from copyright infringement, and reverse engineering, and enforce the companies' patents, then the government also has the moral right to regulate the company for the benefit of the people.
Comments like yours seem to advocate a very beneficial situation for the companies where they have all protections, all authority, without any responsibilities.
If your serious about getting the government out, including out of copyright and patents, then let's talk. Until then, let's regulate these companies.
> If your serious about getting the government out, including out of copyright and patents, then let's talk. Until then, let's regulate these companies.
I'm all for eliminating all government privileges and cronyism (which are really rights violations of the competition). In this world, there is no way we're going to get a grand bargain where all things will simultaneously change in that way. For each proposed change, ask whether we increase or decrease natural rights (especially to life and property). "Intellectual" property is a creation wholly new in human history before a few hundred years ago. Property in land and goods goes back to evolutionary times: it's basic territoriality, and respecting that keeps the peace. Free trade is the way forward to widespread prosperity.
Wouldn't being required to release hardware specs support that healthy competition though? I'm sure the market will eventually settle on the better product either way, but it will happen faster if systems are documented and interoperable enough that people can easily switch to a better competitor. Companies withholding data that would let consumers make better decisions, or deliberately making their systems incompatible, is anti-competitive and wasteful.
Of course, people having control over the hardware and software that rule their lives is a net increase in natural rights.
There is absolutely no natural justification for "intellectual property", since this travesty runs absolutely contrary to actual property -- physical property cannot be freely duplicated, whereas intellectual property in most cases cannot be used without being duplicated in some form -- its knowledge is generally enough to do so.
All this to enforce laws that terribly hinder free-market, while being abusively enforced by the violence of government? Something smells fishy about this argument...
> For each proposed change, ask whether we increase or decrease natural rights (especially to life and property).
I asked myself and answered: Requiring companies to document their hardware for right-to-repair or right-to-utilize reasons has no effect on life, and some effect on property. It would give individuals more power over their own property - more power over their old school, physical possession, basic territoriality, property. The government protecting people's right to repair and utilize their physical possessions seems like a good thing.
At this point you seem, to me, to have reversed position. Are you now okay with requiring companies to document their APIs for the benefit of consumers (in some cases at least)?
Either way, this conversation is frustrating to me, and one I wont continue here (you're, of course, welcome to respond and debate with others). I'm frustrated because the "no regulation, no government" view hides a lot of nuance and shuts down conversations. It's so easy to throw out "no government" and so hard to talk past it, and I think this is one reason libertarian views like this often cause people to just roll their eyes and ignore. I'm sympathetic to a lot of libertarian ideas, but I wish people would give more acknowledgement to why people want regulation (in this case) before a drive-by "no government please" comment.
Two wrongs don't make a right. Please don't use one travesty to justify another.
Instead answer to yourself, why I should have any right to dictate the standards of the goods you may knowingly and willingly purchase, and particularly when the consequences of your substandard purchase are born by you? Should I literally be able to force you to upgrade to a product with iFixit-approved repairability? Under what moral code is that legitimate? Protect people from themselves, i.e., I may treat you as my child?
> why I should have any right to dictate the standards of the goods you may knowingly and willingly purchase, and particularly when the consequences of your substandard purchase are born by you?
They are not born by me, as I personally have a very low influence on the market. Market is dictated by the masses, and masses are manipulated (nudged) by media, which is again controlled by the corporations.
Your argument of blaming individuals for bad choices masses make is deeply flawed and skewed in favor of corporations.
Because we live in a society, and our choices affect each other, and we have democratic systems in place to collectively decide on things? You'd have a point if you alone were deciding these standards as a dictator-for-life, but that's not how it works.
Markets by themselves tend to explore only spaces where large parts of the population take them. Because of limited information, most of us often prefer clear short term benefits over long term uncertain and often unclear benefits. Legislation is a good tool to, at least temporarely, force markets to explore parts of the state space they are extremely unlikely to explore by themselves.
The hardware manufacturer does not want to make it any easier to compete with a similar product either. If you have the protocol, you make it easier to create a drop-in replacement without bothering with any drivers.
This is why good customer support and warranties are as important as the product itself. It doesn't matter how big the company is either. It's why people pay more for certain brands, especially in the enterprise and professional creative markets.
They are conflating two different issues: Linux' lack of stable binary interface for drivers, and Linux being open source. It's the lack of stable ABI that's preventing third parties from maintaining decent drivers for Linux (plus the lack of economic incentives of course).
You are conflating two issues as well: the manufacturers' insistence on closed-source drivers and Linux' non-stable (binary!) ABI. If the manufacturers were to upstream their drivers in the Linux kernel, they wouldn't need to update their drivers for every ABI change.
It's often not easy or even possible to simply open-source the drivers. What if there are any patents at play? How about third (fourth?) party dependencies? I'm sure the legal would take major offence with slapping GPL on the code and releasing it.
I can also imagine a company like Wacom fighting cheap Chinese copies - I can't imagine persuading the business folks to make the copycat's life way easier by open sourcing the logic.
As long as Linux says it's either mainline or the highway, well, companies will be reluctant to put in the resources I'm afraid.
Nevertheless, any trade secrets which are needed in the interface that is necessary for a device to be used by its owner, can easily be reverse engineered by someone with enough money, i.e. by all the important competitors.
So hoping that not providing documentation for the interface of your devices is a method to fight your powerful competitors is an illusion.
This method works only against your normal customers, by preventing them to find reasons to buy more of your products, for applications that you do not support, e.g. use under other operating systems.
Trade secrets are useful and they may be effectively protected when they do not concern the normal operation of a product, e.g. when they are used during the fabrication of a product.
Avoiding patent infringement claims is probably a significant motivation to stay closed source. There are just too many patents on obvious solutions any engineer would come up with.
But you don't always have the right to use them, or share them.
If company A owns a patent, and company B buys a license, company B may not have the rights to release their code to GPL and share it into mainline linux.
Hm, interesting, I hadn't thought of that. I know that Linux is fine mainlining drivers and updating them whenever the ABI changes, but what's the rationale behind not offering a stable ABI?
There's been various explanations and rationales provided over the years, but from Linus' own words in 1999 (see https://lwn.net/Articles/159313/):
Basically, I want people to know that when they use binary-only modules, it's THEIR problem. I want people to know that in their bones, and I want it shouted out from the rooftops. I want people to wake up in a cold sweat every once in a while if they use binary-only modules.
The less activist stance is simply that maintaining a stable ABI requires either accumulating lots of backwards compatibility layers over time, or to stop improving certain parts of the kernel. Neither option has won out over the current situation.
I know nothing about this topic. Is there a reasonable work around to this? To provide something stable for hardware manufacturers but allowing the current kernel practices to continue?
I always thought they insisted on breaking ABI specifically to incentivise open-sourcing and mainlining drivers. If given a stable ABI, manufacturers have shown (as seen on Windows) that they will just release a binary driver once and never touch it again. This is a big reason why old hardware support is so much better on Linux...for the hardware that was supported in the first place of course.
Well, my old laptop (HP nc8430 from 2006) graphic card worked perfectly up to some 3.x kernel, then it lost all sync with 3.y kernels (y > x). It was an ATI X1600. There were no more recent drivers so my take is that the kernel broke it and ATI didn't spend money to make their driver compatible with newer kernels. Actually AMD because they bought ATI in 2006. I downgraded the kernel and kept using the laptop for a while. BTW, the open source driver didn't work well.
Than I had to buy a new one in 2014. I told myself, no more ATI/AMD, let's buy one with an NVIDIA card. That card is a Quadro K1100M in a HP ZBook 15. The latest binary driver supporting that card is version 418. The newest driver is 510. Apparently the next Ubuntu 22.04 is shipping with kernel 5.15 and there is a 418 package for that kernel. I wonder what the latest compatible kernel will be. Is my laptop going to die of old age before I have to replace it because I won't be able to use its graphic card anymore? BTW, the open source driver doesn't work well. I don't check it again every year. All I remember is that I couldn't work with that the last time I tried.
On the other side, my USB scanner from the 90s still works perfectly well. Same for my mouse (I don't plugin it in every year) and any disk / pendrive I care to use.
I have a ThinkPad with a Quadro 1000M from 2011. The last Nvidia driver is 390. It still works on Arch with latest kernel somehow. I doubt it has much support left as pre-2010 GPUs have been abandoned. So I wouldn't be surprised if you have a few years left + time spent on an LTS with older kernel. I recently switched to Guix and have been using Nouveau there and it's fine but I also don't need my laptop to do much beyond display windows and play the occasional video.
Nowadays and into the future, your best bet will be AMD, since their AMDGPU driver is open source, and will therefore be kept up to date without any reliance on the company.
I have maintained for some time a Linux device driver a couple of years ago.
It was not official maintenance, it was just an unmaintained open-source device driver found somewhere, which was needed for my hardware. I had to update it after every Linux kernel release in order to be able to continue to use it.
What was annoying was not the fact that almost every kernel release required modifications in the device driver, but the lack of a documentation about the kernel changes that is usable by someone who does not follow every day the kernel mailing lists.
The 3 main reasons which broke the device driver after each new kernel release were:
1. Some reorganization of the kernel header files, which moved some definitions to other header files, which were not included in the previous driver code.
2. Some structures had members added or deleted
3. Some functions had parameters added or deleted
Point 1 was easily solved by a search through the entire Linux source tree.
When structure members or function parameters were deleted, it could be hoped that it is enough to also delete them in the device driver, even if in some cases some earlier-executed initialization code had to be modified to make everything work like before.
The worst was when there were new structure members or function parameters, as there was no way to guess which values should be put in them.
Because, at least then, but I suppose that nothing has changed, there was no centralized document with the changes that need to be applied to drivers, the only way was to search the kernel mailing lists, to discover where was the patch that changed that structure or function.
That search was not too difficult, but I have never seen a message with the changes that will also explain what values must be put in the new members/parameters.
So after finding who did the changes, the mailing lists had to be searched for messages with the same authors or similar subjects to find any relevant information.
In many cases the search was too long, so it could be simpler to pass to the final solution of anything, i.e. to reading the source code of various kernel subsystems or of other device drivers, where the offending structures or functions were also used, to discover what values might be expected.
None of these activities was too difficult, but they were quite time-consuming.
What I would have expected is that anyone who makes a kernel change like that, would also write a short migration guide, saying e.g. that whoever used the previous function with 5 parameters now has to put the X value in the 6th parameter to obtain the previous behavior.
With the right documentation of the kernel changes, I could have updated the device driver in a couple of minutes every time, but, unfortunately, I have never seen such documentation.
(The "ChangeLog" of the kernel is usually completely irrelevant for device driver maintenance, because it does not list the symbols affected by changes, so when your device driver compilation stops on function or structure XYZ, you cannot search it in the ChangeLog to discover which is the change that affected it.)
agreed with your points... as a user of the current ath9k wireless problems, code changes to address security issues completely broke the wireless - for over two kernel releases until people alarmingly realized that noone was coming to help, code changers not even aware it was broken nor checked; that the interfaces were abstract, misunderstood, that even Linus broke in and said that such breakage, regression violated the system, and decided the patches be reverted. Point is, little to no documentation, and in my opinion too much fiat, with shallow testing and confirmation, and only when people howled was noticed. And this is the second time for me where I once spent days bisecting the kernel* over a year or two of changes, finally getting the chip manufacturers involved - ooops, sorry, was the response. *I realize that is my cost as a free OS user, but still, I'm not a developer and they shouldn't be pulling the rug out under us.
Imagine if you could resolve such conflicts in a few minutes. The code editor should also be a collaboration tool.
Using an online editor, Mark a struct for changes…call a merge meeting with all affected module owners and everyone changes their code right there and then.
Even using email to talk about code is stupid and an unnecessary hurdle.
No need for an ABI with open-source drivers because Linux and drivers shall be open source. What matters is the API and modifications to this can be maintained by upstream. If your hardware drivers aren't open source the promises of the GPL break:
When this model works you get high quality support, performance, over long time. Example:
Sandy Bridge (GPU HD3000) from Intel:
Linux OpenGL 3.3
Windows OpenGL 3.1
MacOS OpenGL 3.2 // I'm not sure!
At time of the hardware availability that didn't matter much but with modern applications and engines it does. If you use Linux and Steam you may benefit from that.
Android "Google/Linux" failed here because Google didn't pushed neither ARM nor Qualcomm. This and separately maintained modifications through manufacturers are the reason that Android devices cannot be trusted and struggle with updates. You cannot bump the Linux kernel if you don't get an updated driver. And you cannot cannot bump the Google part because of the manufacturer patches which weren't upstreamed.
Android is an example of how open-source collaboration should not be done. Even Jolla failed and use closed-source drivers, which meant the need to remain ABI compatible, which meant the cannot upgrade the kernel, which meant the cannot fix issues within BTRFS. Purism avoided that all with much hard work together with NXP! They just need to make the device smaller and cheaper. Sorry Purism. But 800 bucks are even for a nerd/developer-device expensive. Valve did a clever thing with using AMD for the Steamdeck.
Noteworthy:
Linux and GLIBC provide stable APIs and ABIs for the userspace, hopefully also Systemd. External developers and users rely on the promise of API and ABI stability.
I believe USB HID drivers have been in userspace for quite some time, in part precisely to provide a stable interface. I'm not sure why the Wacom drivers are an exception though: https://linuxwacom.github.io/
They don't write one because of the size of the userbase. They end up supporting 99.99%+ of their potential customers by having Windows and MacOS support for something like a drawing tablet; the amount of money to support Linux doesn't justify the potentially low-four digit amount of customers that would buy the product if it had Linux support.
As a Linux power-user and the tech referral of my family, extended family and friends, if something works nicely on Linux I am obviously going to recommend it to everyone. That has to mean something...
It still either has to be a passion project for an engineer or it has to make business sense. Even if it only takes a collective week's worth of work in a year to keep it supported, that's 1/52 of an engineer's salary, and that has to be made up/exceeded by profit generated from the extra sales. Regarding this product, pens and drawing tables for personal computers are already a relatively niche category, so the subsection of those users who also use Linux is probably very small.
It's not necessarily just the hardware spec and the drivers, though. I ran Linux on a Fujitsu convertible tablet/laptop circa 2010, which had a stylus that worked directly on the screen. The Wacom stylus worked great, as long as I was just using the laptop. But when I plugged in an external monitor, linux tried to apply the stylus across the entire combined screen area of the laptop screen and external screen. It was a relatively rare use-case, but wasn't an issue in Windows. I'm not blaming Linux, just wanting to point out that sometimes systematic issues are overlooked.
Not necessarily. Ubuntu LTS kernel is often very far behind and you have to rely on Canonical to backport drivers for you.
e.g. Vulkan on my 5700 XT didn't work (despite AMD being very good at writing kernel drivers!) because the Ubuntu kernel was so far behind. Switching to an up-to-date vanilla kernel and all my problems went away...
"Well that's just because the manufacturer just doesn't write one, not because of some intrinsic factor of FOSS"
Linux wants to force the manufactors to open source their drivers by intentionally changing the ABI, which makes it harder to write a driver as a binary blob once.
I want open source drivers. But I am not sure this is the right way to get them.
Hardware makers feel forced to protect their trade secrets, this is the current buisness reality. Open hardware the rare exception.
Reality also is, I gave up with linux on many machines because of bad drivers. With more stable drivers avaiable, even if proprietary, I would have been able to convince many more people of linux as well as getting rid of windows on my laptops.
And more people using linux on a daily basis, means more people exposed to the idea of software freedom. And not just hackers.
Interesting; can you or someone please elaborate? I thought that device-specific drivers wouldn't be needed for the vast majority of audio interfaces, because they're connected via USB and all they need to do to ‘just work’ upon plugging in is implementing the relevant USB device class.
From my (programmer's) point of view, all I need to know to work with an audio interface is the number of input and output channels and the respective arrays of sample rates and bit depths. In theory, a generic USB driver can handle that. In practice, I observe that my Linux-using colleagues have 99 problems with audio, but none of those is related to plugging in a $1 dongle from AliExpress. (Therefore, I used to think that those audio interfaces ‘just work’, but now I'm curious about what I've been missing all along.)
Why is releasing Linux drivers for an audio interface even a thing?
That's true for the cheap dongles. Where it gets problematic are the high end "Audio Interfaces" for studio recording work. The USB Audio Class 1 standard was released in 1998 and supports 2 channels at 24/96, over USB 1.0. This is obviously anemic for all but the most basic work. The upgraded USB Audio Class 2 standard was released in 2009, but was unsupported in Microsoft Windows until an update to Windows 10 brought it in 2017. Therefore, prior to that, any manufacturer who wanted to support Windows were put in the position of writing their own drivers for anything with more than 2 channels.
Aha, that's a good point! It was silly of me to assume that if any cheap dongle works, that should mean ‘proper’ interfaces would work at least as well.
However, it seems like that explains why we needed Windows drivers, but not why device-specific Linux drivers are a thing? Unless the implication is that manufacturers who needed to make custom drivers anyway didn't bother to make their devices class compliant?
In many cases it's not necessary though. Most "pro" audio interfaces support MacOS because they are "class compliant" and therefore don't need extra drivers on MacOS. You could also say "no major audio interface company releases MacOS drivers".
Linux should support all these "class compliant" audio interfaces too, but I can't remember if you need extra software (like JACK?) for this.
Well that's just because the manufacturer just doesn't write one, not because of some intrinsic factor of FOSS. That's an odd point to make when it's the manufacturers' fault.