Back to News
Advertisement
Advertisement

⚡ Community Insights

Discussion Sentiment

54% Positive

Analyzed from 715 words in the discussion.

Trending Topics

#mainline#linux#hardware#software#more#chips#support#vendor#why#chip

Discussion (13 Comments)Read Original on HackerNews

ACCount3713 minutes ago
Good. Video capture on second grade Linux SoCs is hell - lots of weird custom vendor SDKs that work with the vendor's own happy path use case demos and nothing else.

I hope that the more SoCs get mainline V4L2, the more likely the future SoCs are going to be to use it instead of doing something non-standard and awful.

Aurornisabout 4 hours ago
Great to see progress on mainlining more support for common and powerful chips.

The work required to get this one piece into mainline over 5-6 years reveals why most chip vendors aren’t aiming for mainline by default:

> A few iterations of the rkcif driver later, the basic driver providing support for the PX30 VIP and the RK3568 VICAP was accepted (October 2025). After more than five years of development, including 25 iterations and three renamings, this was a major milestone. On the other hand, there was still a lot to do, of course. For instance, the Rockchip MIPI CSI-2 receiver unit that is coupled closely to the VICAP required a mainline driver as well.

It’s never as simple as submitting existing work upstream and making a few changes. It takes a lot of development and a willingness to rewrite everything, possibly multiple times, to track the goals of upstream.

Palomidesabout 3 hours ago
I really feel like that should be table stakes if your entire business is making chips to run Linux, though

after working professionally with their stuff I'm really not a fan of Rockchip

Aurornisabout 3 hours ago
I wish everything was mainlined right away, too, but I’m realistic about what it takes to get that done.

There are chip providers that put more emphasis on mainline support but even those aren’t fully mainlined and their chips are generally much more expensive.

packetlostabout 3 hours ago
Why is that? IME pretty much all of their software is a mess and the hardware has some bugs/issues iirc but is otherwise ok?
mcmcmcabout 2 hours ago
> all of their software is a mess and the hardware has some bugs/issues

Is that not enough of a reason?

yjftsjthsd-habout 2 hours ago
> why most chip vendors aren’t aiming for mainline by default:

> It’s never as simple as submitting existing work upstream and making a few changes.

If they had started by working with upstream, then they wouldn't have to go through unnecessary revisions trying to adapt the thing they already wrote.

4fterd4rkabout 3 hours ago
I guess I don't understand... why would the SOC manufacturer spend the money on integrating this stuff if they don't intend on also spending the money to enable it on the software side?
EdNuttingabout 3 hours ago
Software != Linux Mainline.

Software exists from the vendor, but it’s not open source and/or not part of Linux mainline.

Hence the effort to develop an open source (and mainlined) alternative.

Whether this is a good use of effort and/or whether you believe the vendor should be doing the Linux development or not, and/or whether they should open-source their proprietary drivers, will depend on your personal views.

Manuel_D9 minutes ago
So that they can sell licenses to proprietary software implementations on top of selling the hardware.
MisterTeaabout 2 hours ago
They did, jut not mainline. People forget these are embedded chips - they are intended to go inside of something and do one thing. These chips lack auto hardware discovery because the manufacturer assumes the customer will only turn on the hardware peripherals they need for their specific use case and build a static kernel image to meet that requirement. They ship a product that will likely see few, if any software updates and end up in a landfill.

It's because of the Raspberry Pi foundation we have this perception that embedded Arm chips are like general purpose desktop computers that run Linux desktops. The original Pi SoC was designed for TV set top boxes, STB's hence the loopy booting from GPU which was likely part of some obfuscated secure boot chain to thwart STB hackers. The Pi was a throw away hobby toy based on a chip Broadcom was going to scrap so they got a dumpster deal. It took a lot of effort for the community to fully reverse the Broadcom SoC and bring all the Pi hardware to mainline.

jauntywundrkindabout 2 hours ago
Worth noting that, well, alas, camera support is incredibly incredibly incredibly cursed, period. It feels like, broadly, with all the image blocks, everyone makes really neat really good hardware thats chock-a-block full of capabilities that are un- or poorly documented or really hard to support for reasons, etc. Its a pretty bespoke high throughput pipeline with a lot of special domain knowledge very unlike anything else on computing.

Intel's IPU6 has been a ~4 year travail to get going (thankfully IPU7 landed fairly quickly however!) https://www.phoronix.com/news/Intel-IPU6-Camera-Challenge-25 https://www.phoronix.com/news/Intel-IPU7-Linux-6.17

AMD similarly has only just gotten the Strix Halo ISP near working: https://www.phoronix.com/news/AMD-ISP4-For-Linux-7.2

The whole video world seems like a nightmare. Difficult world of hardware. Just the worst Intellectual Property hostage taking banditry from awful awful valent legally predatory people everywhere, a dark forest ready to leap out of the dark and attack you if you dare use a computing to deal in bits that represent moving images.

bullenabout 3 hours ago
Some 3588 CMs are sold out.

So it might be too late as 3688 will be too hot...

Just like routers get dd-wrt when sold out!