[HN Gopher] Initial mainline video capture and camera support fo...
___________________________________________________________________
Initial mainline video capture and camera support for Rockchip
RK3588
Author : mfilion
Score : 68 points
Date : 2026-04-13 13:23 UTC (9 hours ago)
(HTM) web link (www.collabora.com)
(TXT) w3m dump (www.collabora.com)
| Aurornis wrote:
| 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.
| Palomides wrote:
| 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
| packetlost wrote:
| 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?
| mcmcmc wrote:
| > all of their software is a mess and the hardware has some
| bugs/issues
|
| Is that not enough of a reason?
| packetlost wrote:
| Fair!
| Aurornis wrote:
| 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.
| le-mark wrote:
| Is there a SOC you prefer, why? Linux support seems about on
| par with most?
| yjftsjthsd-h wrote:
| > 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.
| Aurornis wrote:
| The part I quoted was from a team that was working with
| upstream, not the RockChip team.
|
| They were experienced with working with upstream and it still
| took them that long to do it.
| tov_objorkin wrote:
| The product has a typical lifespan of 3-5 years, they just
| don't need LTS. RKISP(ImageSignalProcessor) is piece of code
| glued to the kernel, fast and cheap. The mainstream version
| provides proper integration with Linux multimedia subsystems.
| bullen wrote:
| 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!
| 4fterd4rk wrote:
| 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?
| EdNutting wrote:
| 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.
| MisterTea wrote:
| 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.
| Manuel_D wrote:
| So that they can sell licenses to proprietary software
| implementations on top of selling the hardware.
| jauntywundrkind wrote:
| 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.
| ironman1478 wrote:
| I work in this field and this is 100 percent true. It's really
| hard to learn about too. A lot of textbooks go over the
| algorithms in the chips in an idealized form. The actual
| versions are so messy and different that the textbooks aren't
| even useful sometimes, especially if you work on custom ISPs.
| It's cursed, but it's fun.
| skoocda wrote:
| Are there any resources you would recommend for learning
| about real implementations?
| XorNot wrote:
| Wait is IPU6 working now? My work laptop has it and the only
| thing I know is it _might_ work provided I use some user space
| relay driver and a bunch of other things.
|
| Has this situation improved?
| jauntywundrkind wrote:
| I looked and looked and looked. I don't know why but IPU7 is
| reported to be pretty good. But IPU6 might still be in
| perpetual limbo; I don't know. What kernel are you on btw?
| Sorry for your pain.
| ACCount37 wrote:
| Good. Video capture on second grade Linux SoCs is hell - lots of
| blobs and 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.
___________________________________________________________________
(page generated 2026-04-13 23:00 UTC)