If the webcam is IPU based, which it likely is (otherwise it would be supported out of the box) then it may _never_ "get sorted" at all. Not for the useful life of the machine, that is.
If the webcam is IPU based, which it likely is (otherwise it would be supported out of the box) then it may _never_ "get sorted" at all. Not for the useful life of the machine, that is.
Not yet. Right. Some enthusiasts have patched the kernel to make it work though on expense of losing support of HDMI port and the brightness correction. I tried as well but failed -- got all the problems but the cam was not fixed, so I returned to the stock kernel
> Does this mean the camera stack is completely open?
> libcamera is open-source friendly which means all of libcamera itself is open source. libcamera uses a plugin system for Image Processing Algorithms (IPA) which are built as dynamically-linked shared objects, and are loaded at run-time. Open-source modules are identified based on digital signatures, while closed-source modules are isolated inside a Sandbox environment with restricted access to the system, reducing the impact of untrusted binary blobs.
I.e. libcamera needs ipu6-camera-hal (which is open-source, apache licensed) which in turn depends on ipu6-camera-bins (which is binary-only, closed source).
In order to use the camera, you need to have a bunch of closed-source libraries (ipu6-camera-bins).
The problem is that this generation of Intel platforms have migrated to a completely different approach to the handling of webcams. Previously, the webcams modules were intelligent black-boxes that transparently handled things like auto-focus and auto-exposure in their firmware. They presented themselves as just a framebuffer with a handful of tunable knobs. The v4l2 subsystem was a perfect fit for this approach.
Now with MIPI, things are very different. The OS must actively participate in tasks like autofocus (not rocket science, but not trivial either), be it by providing code that runs on the camera module, or by actively running algorithms on the CPU. No such thing exists right now, but as you pointed out, a few user-space projects are working on it. The big hurdle is the OS-level API. There is no successor for v4l2 yet, and kernel devs are still in the design phase. They recon it will take 1-2 years just to stabilize a reasonably general API [1]. There are proposals, but they are still controversial at the moment.
I dug into the issue because I considered buying this very laptop.
[1] https://lore.kernel.org/lkml/YvnybHVFmpUJs4qi@kroah.com/