How cool is that? Too many vendors still think that they have valuable intellectual property in such relative trivialities. And that handing out the specs freely helps their competitors more than themselves.
I can think of only a few companies that bother to publish any details... And most of them are focused on industrial customers where it isn't unreasonable to need certain protocol details for integration or even just compliance with certain regulatory systems.
Maybe things are changing?
I have noticed that some of the LED light controllers you see on AliExpress are leaning in to open firmware standards. 5 years ago, you bought the controller and had to flash your own firmware. Now, there's an option at checkout to select an open source firmware. Some even have a USB port built in for flashing!
I emailed them saying I'd be interested in developing drivers for their hardware for Linux as I was a happy customer and was immediately put in touch with one of the managers and their engineering team.
Made quite a bit of progress before the whole thing was shut down because one of their component vendors threatened them saying it'd be a breach of their contract with them.
Apparently that vendor sold a "datacenter" (non consumer) version of that hardware for which they charged a hefty license fee for the management software (which was Linux compatible).
Jokes on them, someone reverse engineered the whole thing with a USB analyzer years later and published it XD. (not me)
I did the same thing back in college, when I was in a lab. We wanted to do some research on Wi-Fi signals, and I happened to own a bunch of Wi-Fi adaptors produced by SomeSmallTech Co. Ltd., which featured relatively new Atheros chips and didn't have Linux drivers at the time.
So I sent an email to the company's public email address, asking for some datasheets, "for science". To my disappointment, presumably a PR person replied that they "don't have a company policy to collaborate with academic research". (But they did send a quick reply, kudos to that.)
Funnily enough, years later I ended up working for said company. Naturally, when I first logged into the company network, I searched for the datasheets I asked for. There were "classified" watermarks all over the PDFs :)
Okay, cool. I did with a fake name, address and everything and they sent a file..
Turns out the file is available online.
Facepalm pro Max.
So my question is, what kind of "IP" is in a data sheet that needs protection ? And this isnt even some secret product but a generic solar product sold by millions.
Rs-232 protocol ? Really ?
So, the safest thing to do is not give details at all, or "leak" them like another reply in this thread mentions.
But it also makes me a little bit sad. The original parallel port and even ISA interface seemed so simple by comparison, with less layers of abstraction. Just run a wire, and write to a port.
I remember when I was a kid, I found a breakout board in an electronics store's random clearance parts bin, with an ISA header on an edge. On a whim I took it home and wire-wrapped a 7-segment LED onto it. Power and ground were easy. Each segment was hooked to a data line, through a simple buffer IC. I cheated and used only a minimal number of address lines to feed the enable port (guessing through a simple AND gate or something). I was amazed when I wrote to that address and it worked the first time!
I look at a protocol like USB, with hundreds of pages, and instead of that curious excitement and enablement I felt back then, I feel a bit overwhelmed.
Yeah many of the abstractions help with performance but maybe there's value giving up much of that performance in exchange for simplicity.
As a community we must find a way for tackling this issue.
Micro-Kernels are a solution where one can run different OSes but they will reuse the same device driver servers.
But it requires co-ordination and determination.
Rust can be a solution for sure.
If you don't want to learn a different programming language, you can take the exact same approach in any language you prefer and play along. You may need to turn the more object oriented calls into libusb_* calls, but if you're used to programming in C you probably won't have a problem getting that to work.
In this case, the cross-platform libusb should make this code work on either Linux or Windows (if you install the signed Windows drivers). If other operating systems port libusb, they get this code for free.
Most "real" drivers still run in kernel mode, though, and not even Linux can keep their ABI stable (Windows has to, between releases, with the aid of compatibility wrappers that only work for a certain amount of releases).
It would probably be worth it more forbBespoke operating systems to implement either the Windows API (like ReactOS does) or the Linux API (pick an LTS version) to get existing drivers to work. Unless you pay them, most driver programmers aren't going to bother with anything than Windows, maybe Linux, possibly macOS.
Plus, to port this to OpenRGB, you'd need to rewrite the code into C++ (ugly, old C-inspired C++, at that: https://github.com/CalcProgrammer1/OpenRGB/blob/master/CONTR...) which would take most of the joy out of it for me at least.
Maybe this kind of thing should be enforced in the GPL (as many devices use Linux under the hood).
I thoroughly enjoy rust, but I doubt not being able to use it should be grounds for avoiding contributing to a project. Unless you are going to write async heavy code, libusb is pretty easy to use in C.
All those layers of abstraction is likely what allows us to hook up a single wire to our laptops and get multiple very fast ports from the docking station along with power and display output.
You get some, you lose some.