Hacker News new | ask | show | jobs
by viraptor 1467 days ago
When you write drivers there's no such thing as portable code. You need to target different APIs, different environment assumptions, etc. Sure, there's some common core most likely, but I think this rant is misplaced when talking about a hardware company.

The software postprocessing is a different question and could be more common... But you're still specialising it for DX / v4l2+gui / whatever macos uses. That said... I'd kill for an independent library for video processing that specialises in camera outputs - beyond different profiles, there's no technical reason that couldn't be used independently of hardware.

3 comments

Maybe in 2002, but it's a USB webcam in 2022, if you're writing your own drivers from scratch on any platform rather than using the standards-compliant ones, I'd first wonder if you haven't got a case of NIH syndrome rather than an actual case of being constrained by the standards.

But maybe they genuinely cannot use standard protocols for some reason, then sure, writing a Linux driver might not be worth it.

I'm half assuming they do something special, half responding to the comment which describes them as a hardware company. But yes, ideally a webcam should have the basic functionality available just by plugging it in, no special software needed.
The postprocessing should be done in the cam though, IMO.. And it should just give the result back ideally in a standard format.

But I would prefer better optics and sensors over AI stuff like many others have mentioned. When you have good video you have much less need to fiddle with it.

I worked for a company that did pre-infiniband HPC interconnect drivers (Myricom) in the 2000s. We supported N-different *nixes (Linux, Solaris, FreeBSD, Tru64, Aix, and probably more I'm forgetting), Mac OS X and Windows in the same codebase. At least 50% of the driver and 95% of the userspace code was OS independent. In order to do this, our drivers were not "typical" drivers. Eg, we used ioctls everywhere (even on OSX) for driver/library communication.