> I also thought I’d message the vendor and ask them if they could share any specifications or docs regarding their protocol. To my surprise, Nanoleaf tech support responded to me within 4 hours, with a full description of the protocol that’s used both by the Desk Dock as well as their RGB strips. How cool is that? Too many vendors still think that they have valuable intellectual property in such relative trivialitie…
I have a solar inveter from a company, aparticular German brand. I wanted to use home assistant with it so I needed rs232 data.. tried the support and they asked me to sign an NDA. 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…
Writing a basic Linux device driver when you know nothing about Linux drivers
31–40 of 72 posts
Re: Writing a basic Linux device driver when you know nothing about Linux drivers
#32I wish this was done in C so I didn't have to learn Rust. But maybe it is time to learn Rust.
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.
Re: Writing a basic Linux device driver when you know nothing about Linux drivers
#33There are many innovative OSes that are killed by the lack of Device Drivers. 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.
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.
Re: Writing a basic Linux device driver when you know nothing about Linux drivers
#34The title was misleading because the author wrote a userspace Rust driver and not a Linux kernel driver in C.
Re: Writing a basic Linux device driver when you know nothing about Linux drivers
#35The author should probably have implemented support in OpenRGB instead to better benefit others, but this is cool nonetheless.
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.
Re: Writing a basic Linux device driver when you know nothing about Linux drivers
#36Re: Writing a basic Linux device driver when you know nothing about Linux drivers
#37Earlier quoted context omitted.
I sometimes think about this, starting from scratch with a computer hardware and software stack that disallowed all of the layers of abstraction that have built up over the decades. Yeah many of the abstractions help with performance but maybe there's value giving up much of that performance in exchange for simplicity.
It would be neat to design a whole new contemporary stack from scratch.
Re: Writing a basic Linux device driver when you know nothing about Linux drivers
#38> I also thought I’d message the vendor and ask them if they could share any specifications or docs regarding their protocol. To my surprise, Nanoleaf tech support responded to me within 4 hours, with a full description of the protocol that’s used both by the Desk Dock as well as their RGB strips. How cool is that? Too many vendors still think that they have valuable intellectual property in such relative trivialitie…
Maybe this kind of thing should be enforced in the GPL (as many devices use Linux under the hood).
Re: Writing a basic Linux device driver when you know nothing about Linux drivers
#39Re: Writing a basic Linux device driver when you know nothing about Linux drivers
#40The author should probably have implemented support in OpenRGB instead to better benefit others, but this is cool nonetheless.
I think they wrote the code more for the challenge of it than anything else. The final code doesn't seem to do more than the bare basics (which is probably enough for the author). 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.
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.