Camera support

[jrevillard]

I see that there is some activity here: jakeday/linux-surface#145

I think it's better to trace it here isn't it ?

Best,
Jerome

---

Maintainer note: There is a BountySource bounty available for this issue. If you'd like to see a camera driver consider donating to incentivise the work.

[mmalmeida]

I agree

[qzed]

Right, makes sense to track this here.

[archseer]

Copying my old comment here:

---

I found libcamera based on this bug report, it seems to have the required userspace code to have ipu3 working on 5.0. libcamera FOSDEM slides

• ov7251 is upstream
• ov5693 could probably be derived from ov5695
• ov8865 could probably be derived with some work from ov8856

[archseer]

Unlikely to get anywhere without someone stepping up and putting some work into it though.

I was hoping to work on the cameras before buying my Surface Laptop 3, but since the newest generation's cameras are available via USB it just worked out of the box -- I don't have hardware to develop against.

I think @GrayHatter was taking a look at things a while ago.

[koroki]

Also Surface go has not support for camera.

It helps to me a lot because I use Surface Go basically for working outside the office and, sometime I have to do some Skype videocall... And I should do in my mobile.

[Doridian]

Well, I managed to find datasheets for the two missing drivers at least. Never done kernel dev, but I mean, how hard could it be? (sarcasm).
Eh, due to obvious current events I have a bit more free time than usual, so let's see where I can get...
Put random stuff in my repo here: https://github.com/Doridian/sb2-linux-cameras
Will probbaly put random C files in there if I managed to get anywhere at all.

[qzed]

I wish you the best of luck! For reference, here are the (I think) most relevant links from the other discussion:

• https://www.kernel.org/doc/html/latest/media/v4l-drivers/ipu3.html
• https://www.mail-archive.com/linux-media@vger.kernel.org/msg133794.html
• Surface Pro 4 / 2017 and Books: Cameras are not working jakeday/linux-surface#145 (comment) (might contain outdated info)

Getting started with the ovXXXX drivers is probably the best idea.

[archseer]

@Doridian Feel free to message us on IRC (freenode @ ##linux-surface) or the Matrix bridge (might be easier to join), we can always help out!

I also recommend starting with #91 (comment) and doing the OV drivers first. Once we have those we can figure out how to integrate with ipu3/libcamera. I was searching for comparable drivers by looking at the product brief's functional diagram. I see that you also found the datasheet for both which is pretty great.

[GrayHatter]

@Doridian highlight me with nearly anything you think is relevant, I'm currently working on getting it working, but haven't had the spare cycles lately.

That's awesome to find the datasheets for the cameras, I'm pouring through them now.

Currently, my understanding, and thus next step, is to figure out what magic windows is using to load the cameras after boot, the DSDT is incomplete on the SB2. I originally thought you'd have to load a custom DSDT at boot up, but https://www.kernel.org/doc/html/v5.2/firmware-guide/acpi/method-customizing.html seems to imply we can do what windows does and inject our fixes at runtime.

Then IIRC we write an i2c driver for the cameras to control them, and then wire them up to ipu3, like @archseer said

It's all been done before, so it shouldn't be too much actual work, once we find the right magic to apply.

[Doridian]

@GrayHatter Good ideas. I'm currently just poking around the Windows driver package. There seems to be quite a bit of hardcoding some things going on in there...
I think the MSHW01*(0,1,2) are power related, because they are close to CAMP in the DSDT but...
I still haven't found how they map the ipu3 to the cameras, but I assume all the same silliness...

[qzed]

Based on the DSDT it looks like MSHW014x/MSHW015x are the subsystem IDs (_SUB) for the CAMF/CAMR/CAM3 devices (x=0 is CAMF, x=1 is CAMR, x=3 is CAM3). They don't look like own devices as those names are provided as return values to the GCSM function which is only called from _SUB and _DSM. The CAMx seem to be the actual I2C sensor controllers, as they have a _CRS with an I2cSerialBusV2 resource. Thus the function you've posted seems to check if the camera controller is supported (or at least if it's any "valid" combination of sensor and subsystem ID). I'm not quite sure why they don't just use the OVxxxx ID (or the _HID field) but additionally rely on the other IDs.

[Doridian]

@qzed Ah, makes sense. Is there and HWIDs for the ipu3 interface or other things I could try searching for in the driver to see how it fetches those devices?
This is the first DSDT I have ever looked at, and I am kind of learning as I go here.

[qzed]

I haven't really figured out much more than that. There are also the INT3472 devices that I mentioned in the other thread, but they seem to be controllers for the camera flashes/LEDs. I have no idea how the sensors are matched up to the ipu3 interface. The ipu3 itself is a PCIe device, but I haven't found anything for it specifically in the DSDT.

[theGeekyLad]

What's the approach like to get the camera working on the Surface Go? I ain't no pro but is there some kind of support that I can provide? Also the readme mentions partial support - any idea how it's enabled?

[spoorun]

Happy to fund this if someone wants to get it resolved speedily...
Bountysource? Or what's best?
£60//$75/€70

[qzed]

The process on the Go isn't any different than for the other devices, except that it uses a different sensor (OV2740).

[archseer]

@olantrust IssueHunt or Bountysource are all fine. IssueHunt seems to do some reward matching on their end as well to increase the bounty.

[fabwu]

I've copied the ov5675.c and replaced the ACPI id on line 1226 with INT33BE.

Now I see the following error message

ov5693 i2c-INT33BE:00: can't get clock frequency
ov5693 i2c-INT33BE:00: failed to check HW configuration: -22
ov5693: probe of i2c-INT33BE:00 failed with error -22

but at least the probe function gets called ^^

[spoorun]

@olantrust IssueHunt or Bountysource are all fine. IssueHunt seems to do some reward matching on their end as well to increase the bounty.

Great.
If you or one of the crew can add the repo to the Issue Hunter app, then we'd happily support what we can financially with this and maybe other issues...

[spoorun]

$75 Dollar bounty provided:

https://www.bountysource.com/issues/88806607-camera-support

[mmalmeida]

$75 Dollar bounty provided:

https://www.bountysource.com/issues/88806607-camera-support

Contributed!

[kbingham]

@PhilDevProg https://src.fedoraproject.org/rpms/libcamera/blob/rawhide/f/libcamera.spec doesn't seem to mention it so I guess it's not packaged by Fedora. I'll ask for it to be included.
Meanwhile - you could self build libcamera ...

[PhilDevProg]

@kbingham I tried building libcamera but I get this error:

FAILED: src/apps/cam/cam.p/file_sink.cpp.o 
ccache c++ -Isrc/apps/cam/cam.p -Isrc/apps/cam -I../src/apps/cam -Iinclude -I../include -Iinclude/libcamera -I/usr/include/libdrm -I/usr/include/SDL2 -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror -std=c++17 -O0 -g -Wshadow -include /home/phil/libcamera/build/config.h -D_REENTRANT -DHAVE_TIFF -DHAVE_KMS -DHAVE_SDL -DHAVE_LIBJPEG -MD -MQ src/apps/cam/cam.p/file_sink.cpp.o -MF src/apps/cam/cam.p/file_sink.cpp.o.d -o src/apps/cam/cam.p/file_sink.cpp.o -c ../src/apps/cam/file_sink.cpp
../src/apps/cam/file_sink.cpp: In member function 'void FileSink::writeBuffer(const libcamera::Stream*, libcamera::FrameBuffer*, const libcamera::ControlList&)':
../src/apps/cam/file_sink.cpp:117:45: error: possibly dangling reference to a temporary [-Werror=dangling-reference]
  117 |                 const FrameMetadata::Plane &meta = buffer->metadata().planes()[i];
      |                                             ^~~~
../src/apps/cam/file_sink.cpp:117:81: note: the temporary was destroyed at the end of the full expression '(& buffer->libcamera::FrameBuffer::metadata())->libcamera::FrameMetadata::planes().libcamera::Span<const libcamera::FrameMetadata::Plane>::operator[](((libcamera::Span<const libcamera::FrameMetadata::Plane>::size_type)i))'
  117 |                 const FrameMetadata::Plane &meta = buffer->metadata().planes()[i];
      |                                                                                 ^
cc1plus: all warnings being treated as errors
[15/35] Compiling C++ object src/apps/qcam/qcam.p/meson-generated_moc_main_window.cpp.o
ninja: build stopped: subcommand failed.

This is the output of meson setup build -Dpipelines=uvcvideo,vimc,ipu3 -Dipas=vimc,ipu3 -Dprefix=/usr -Dgstreamer=enabled:

The Meson build system
Version: 1.0.1
Source dir: /home/phil/libcamera
Build dir: /home/phil/libcamera/build
Build type: native build
Project name: libcamera
Project version: 0.0.4
C compiler for the host machine: ccache cc (gcc 13.1.1 "cc (GCC) 13.1.1 20230426 (Red Hat 13.1.1-1)")
C linker for the host machine: cc ld.bfd 2.39-9
C++ compiler for the host machine: ccache c++ (gcc 13.1.1 "c++ (GCC) 13.1.1 20230426 (Red Hat 13.1.1-1)")
C++ linker for the host machine: c++ ld.bfd 2.39-9
Host machine cpu family: x86_64
Host machine cpu: x86_64
Header "unistd.h" has symbol "issetugid" : NO (cached)
Header "locale.h" has symbol "locale_t" : YES (cached)
Header "stdlib.h" has symbol "secure_getenv" : YES (cached)
Compiler for C supports arguments -Wno-c99-designator: NO (cached)
Dependency lttng-ust found: YES 2.13.5 (cached)
Program ./parser.py found: YES (/home/phil/libcamera/utils/ipc/./parser.py)
Program ./generate.py found: YES (/home/phil/libcamera/utils/ipc/./generate.py)
Program ./extract-docs.py found: YES (/home/phil/libcamera/utils/ipc/./extract-docs.py)
Program ./gen-tp-header.py found: YES (/home/phil/libcamera/utils/tracepoints/./gen-tp-header.py)
Configuring version.h using configuration
Program openssl found: YES (/usr/bin/openssl)
Library atomic found: YES
Dependency threads found: YES unknown (cached)
Dependency libdw found: YES 0.189 (cached)
Dependency libunwind found: YES 1.6.2 (cached)
Header "execinfo.h" has symbol "backtrace" : YES (cached)
Checking for function "dlopen" : YES (cached)
Dependency libudev found: YES 253 (cached)
Dependency yaml-0.1 found: YES 0.2.5 (cached)
Dependency gnutls found: YES 3.8.0 (cached)
Dependency libexif skipped: feature android disabled
Dependency libjpeg skipped: feature android disabled
Dependency libevent_pthreads found: YES 2.1.12-stable (cached)
Dependency libtiff-4 found: YES 4.4.0 (cached)
Dependency gtest found: YES 1.13.0 (cached)
Dependency libdrm found: YES 2.4.114 (cached)
Dependency libjpeg found: YES 2.1.4 (cached)
Dependency SDL2 found: YES 2.26.3 (cached)
Found pkg-config: /usr/bin/pkg-config (1.8.0)
Run-time dependency qt5 (modules: Core, Gui, Widgets) found: YES 5.15.8 (pkg-config)
Header "QOpenGLWidget" has symbol "QOpenGLWidget" with dependencies Qt5Core, Qt5Core, Qt5Gui, Qt5Widgets: YES (cached)
Detecting Qt5 tools
Run-time dependency qt5 (modules: Core) found: YES 5.15.8 (pkg-config)
Program /usr/lib64/qt5/bin/moc found: YES 5.15.8 (/usr/lib64/qt5/bin/moc)
Program /usr/lib64/qt5/bin/uic found: YES 5.15.8 (/usr/lib64/qt5/bin/uic)
Program /usr/lib64/qt5/bin/rcc found: YES 5.15.8 (/usr/lib64/qt5/bin/rcc)
Program /usr/lib64/qt5/bin/lrelease found: YES 5.15.8 (/usr/lib64/qt5/bin/lrelease)
Dependency glib-2.0 found: YES 2.76.2 (cached)
Dependency gstreamer-video-1.0 found: YES 1.22.2 (cached)
Dependency gstreamer-allocators-1.0 found: YES 1.22.2 (cached)
Dependency python3 skipped: feature pycamera disabled
Program doxygen found: YES (/usr/bin/doxygen)
Program dot found: YES (/usr/bin/dot)
Configuring Doxyfile using configuration
Program sphinx-build-3 found: YES (/usr/bin/sphinx-build-3)
Configuring config.h using configuration
Program python3 (jinja2, ply, jinja2, yaml) found: YES (/usr/bin/python3) modules: jinja2, ply, jinja2, yaml
Build targets in project: 52

libcamera 0.0.4

  Versions
    Sources                  : 0.0.4+73-ad1cd9e3

  Paths
    LIBCAMERA_DATA_DIR       : "/usr/share/libcamera"
    LIBCAMERA_SYSCONF_DIR    : "/etc/libcamera"
    IPA_PROXY_DIR            : "/usr/libexec/libcamera"
    IPA_CONFIG_DIR           : "/etc/libcamera/ipa:/usr/share/libcamera/ipa"
    IPA_MODULE_DIR           : "/usr/lib64/libcamera"

  Configuration
    IPA modules signed with  : gnutls
    Enabled pipelines        : uvcvideo
                               vimc
                               ipu3
    Enabled IPA modules      : vimc
                               ipu3
    Tracing support          : YES
    Android support          : NO
    GStreamer support        : YES
    Python bindings          : NO
    V4L2 emulation support   : NO
    cam application          : YES
    qcam application         : YES
    lc-compliance application: YES
    Unit tests               : NO

  User defined options
    prefix                   : /usr
    gstreamer                : enabled
    ipas                     : vimc,ipu3
    pipelines                : uvcvideo,vimc,ipu3

Found ninja-1.11.1 at /usr/bin/ninja

[kbingham]

@PhilDevProg You're building with GCC-13 which needs fixes ... that are about to be merged in the release I'm trying to make.
You could change your compiler, wait, or use this branch as a 'pre-release'

• https://github.com/kbingham/libcamera/tree/kbingham/for-next
  And make sure you actually build the V4L2 compatibility layer with: -Dv4l2=true

[PhilDevProg]

@kbingham Thanks! Your branch works

[StollD]

For building with meson you might want to add -Dbuildtype=release so that libcamera is compiled with optimizations enabled.

[OmegaRogue]

How can i capture an IR image on the surface pro 6 again? I've done it before, but I can't find the script anymore

[PhilDevProg]

@djrscally Since the image quality of the cameras (especially the rear camera) isn't really good at the moment, I have a question: Is there a way to improve the image quality? Maybe via some configs in libcamera? Or will it have to stay this way forever since it's just not possible on Linux without the optimizations done by Microsoft?

[kbingham]

The quality can be improved. It requires someone to do work on tuning and possibly improvements to the algorithms.

I had started exploring adding lens shading calibration to the IPU3 quite some time ago but I haven't ever got round to continuing it. If someone's interested, that's a good starting point for exploring the algorithm development on the IPU3.

There's some early development I've just rebased here https://github.com/kbingham/libcamera/tree/kbingham/ipu3/lsc that might be interesting to play with - but it's a complete WIP development branch - don't expect it to work out of the box.

[werdahias]

I still have issue #906 with debian bookworm. imo there are two issues here:

• the bookworm version of dkms does not ship the sign_helper.sh since it was dropped
  Not a big issue, got the bullseye one
• The script calls sign-file (/lib/modules/6.2.14-surface/build/scripts/sign-file in this case) which was linked against libssl1 whereas the current version is debian is libssl3

This leads to an error, naturally. Symlinking libcrypto.so.3 to libcrypto.so.1.1 also does not work:

/lib/x86_64-linux-gnu/libcrypto.so.1.1: version `OPENSSL_1_1_0' not found (required by /lib/modules/6.2.14-surface/build/scripts/sign-file

Please consider linking against the newer libssl so the module can be signed.

[qzed]

@werdahias Unfortunately, it's not that easy. We build our kernels on Ubuntu 20.04, so any library versions required for the kernel's user-space tooling are based on that. If we would switch to something newer, we would have problems with DKMS not being usable at all (see e.g. here). The long-term solution would be to compile the kernel images for each distro specifically, like we already do for Fedora.

[Lucaacer]

@werdahias Unfortunately, it's not that easy. We build our kernels on Ubuntu 20.04, so any library versions required for the kernel's user-space tooling are based on that. If we would switch to something newer, we would have problems with DKMS not being usable at all (see e.g. here). The long-term solution would be to compile the kernel images for each distro specifically, like we already do for Fedora.

I juat put in to say that I appreciate your work and understand that supporting newer gcc compilers and libraries must be a pain.

For that reason I want to confirm that Ubuntu 22.04 with 6.2.14-surface kernel (installed via extrepo) has got both cameras working either in chrome and in firefox via V4L loopback.

I just had to compile libcamera from source and install it and place the ipu firmware to the intel folder.

Please note that I don't need any longer to add quees to let the gstreaming go, as you may see in my script so it's definitely a step forward, comparing to 6 months ago (when running Ubuntu 21).

#!/bin/bash ESEC=ps aux | grep gst | wc -l if [ $ESEC -gt 1 ]; then pkill gst-launch-1.0; else gst-launch-1.0 libcamerasrc camera-name='\\_SB_.PCI0.LNK1' ! video/x-raw,width=1280,height=720,framerate=30/1,format=NV12 ! videoconvert ! video/x-raw,format=YUY2 ! videoconvert ! v4l2sink device=/dev/video42 ; exit 0; fi

Let's say that enabling cameras is slowly becoming easy.

Thanks.

Luca

[kbingham]

Let's say that enabling cameras is slowly becoming easy.

Getting there! - Once Firefox 114 is released you can also use the cameras I believe with just
libcamerify firefox
now. (or with the https://www.mozilla.org/en-GB/firefox/channel/desktop/#nightly releases)

I'm still awaiting full integration with pipewire for true seamless integration with both chrome/chromium and firefox though.

[werdahias]

@qzed thanks, that what I'd feared. Appreciate all you guys did. Looks like I can't use cameras for the time being :(

[StollD]

You could try modifying the sign_helper script to call the sign-file binary of a stock debian kernel. With some luck the binary is not kernel specific.

Or disable secureboot and don't sign the DKMS modules at all.

[FletcherD]

Hello, I'm trying to follow the instructions in the guide to create the loopback device and use the camera in other applications. When running the command
gst-launch-1.0 libcamerasrc camera-name='\\\_SB_.PCI0.I2C2.CAMF' ! \ video/x-raw,width=1280,height=720,framerate=30/1,format=NV12 \ ! videoconvert ! video/x-raw,format=YUY2 ! queue ! \ v4l2sink device=/dev/video42
I receive the output
ERROR: pipeline could not be constructed: no element "libcamerasrc".
I have the latest libcamera fully built and installed, v4l2loopback module loaded, and all other steps of the guide completed successfully. I ran ldconfig and the cameras are working in qcam. Any idea why gstreamer can't find the libcamera I just installed?

[kbingham]

I would guess that your build/configuration has either not built the gstreamer component or not installed it at the location gstreamer expects to find it. Check the output when you run meson setup, to verify gstlibcamerarc is being built and check if you needto set -Dprefix=/usr or such to make sure you install on paths that gstreamer will look for plugins.

[Lucaacer]

@FletcherD

The capture plugin gstreamer looks for should be here

/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibcamera.so

[PhilDevProg]

I just experienced something very weird on my Go 3 (I'm on Fedora): In Qcam I can switch between the front and back camera without any issues but in Cheese, I get an error message and have to reopen Cheese every time I change between the front and back camera... This wasn't an issue before. Snapshot has a similar issue: It opens and I can use the front camera but if I want to switch to the back camera, I get an error message.

Update: It works now again.

[djrscally]

I just experienced something very weird on my Go 3 (I'm on Fedora): In Qcam I can switch between the front and back camera without any issues but in Cheese, I get an error message and have to reopen Cheese every time I change between the front and back camera... This wasn't an issue before. Snapshot has a similar issue: It opens and I can use the front camera but if I want to switch to the back camera, I get an error message.

I'm getting this now too; it looks like a format negotiation error. I'll try to get to the bottom of it, but I'm a bit busy over the next week so might be a while.

Bit of news, as Kieran mentioned integration between Pipewire and Chrome/Firefox through WebRTC has been in the works for a while. As of about a week ago the support for WebRTC in Firefox is in Nightly. I tried it (which on my Ubuntu 22.04 meant first getting mainline pipewire for the libcamera support) and it worked with some fiddling. So not quite there, but extremely close.

[kbingham]

Wow - I didn't think Firefox would win that race - I was expecting Chromium to be first - but that's great news - finally 'hack/workaround' free video calling on IPU3 without performance impacts from copying through v4l2-loopbacks and software format conversions! \o/

[lukexi]

Hi @kbingham! I'm trying to programmatically set exposure time on the IPU3 SB2 rear camera, but trying request->controls().set(controls::ExposureTime, 500); seems to have no effect no matter how high I crank it, and other values I've tried (e.g. controls::ExposureValue) are rejected as not valid for this camera. The root issue I'm trying to solve is the cameras are really dark (white levels are OK, black levels are too black). Do you have any ideas, and is there sample code to just list which controls are supported by a libcamera camera? I haven't been able to figure that out from the API docs... thanks so much!

[kbingham]

@lukexi The Surface cameras and IPU3 remain 'untuned' - and there's not been a lot of development gone on with the algorithms there. Someone with a keen interest and device needs to work through and look at the tuning processes for the surface cameras and I suspect the manual controls aren't yet implemented in the IPA for the IPU3 - so that also needs exploration.

[lukexi]

Thanks much Kieran! I'll poke around and see if I can figure out improvements with the hardcoded parameters in the IPU3 IPA

[afalout]

Hi all,

do we still need to compile libcamera from source on Jammy (22.04) or can we use apt:
libcamera0/jammy 0~git20200629+e7aa92a-9 amd64

I would like to try the "libamerify firefox" thing...

Also - was there any luck with IR camera and Howdy tooling?

Thanks!

[ttoommxx]

Hey everyone, the latest build of Firefox (116) introduced experimental support for libcamera over pipewire, and I am glad to report that it works almost out of the box :)
Enable pipewire camera support flag in Firefox and install the libcamera plugin (updated the guide).

After a quick test, the back camera works, the front camera is pitch black (but works on Qcam), and switching cameras crashes Firefox. Far from perfect but still, a huge improvement :)

[Ramen-LadyHKG]

Hey everyone, the latest build of Firefox (116) introduced experimental support for libcamera over pipewire, and I am glad to report that it works almost out of the box :) Enable pipewire camera support flag in Firefox and install the libcamera plugin (updated the guide).

After a quick test, the back camera works, the front camera is pitch black (but works on Qcam), and switching cameras crashes Firefox. Far from perfect but still, a huge improvement :)

Sadly, the pipewire-plugin-libcamera package is not available in AUR

[StollD]

It is only a plugin in the sense that it is a loadable module. It is built together with pipewire, and Arch does have it enabled in their package. Fedora just decided to put the resulting files into a subpackage so that not every install has to pull in libcamera.

[Ramen-LadyHKG]

It is only a plugin in the sense that it is a loadable module. It is built together with pipewire, and Arch does have it enabled in their package. Fedora just decided to put the resulting files into a subpackage so that not every install has to pull in libcamera.

So do I have to install pipewire-git-0.3.77.2.g1daae4c36-1 from AUR or the regular package from Official repositories?

because I enabled the option in Firefox(116), no camera were found.

[StollD]

Judging from https://archlinux.org/packages/extra/x86_64/pipewire/ the official package already enables it.

[Ramen-LadyHKG]

Judging from https://archlinux.org/packages/extra/x86_64/pipewire/ the official package already enables it.

OK, I tried it. Firefox instantly crashed when I gave camera access permission.

❯ firefox
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::GenerateDump cloned child 69449
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.

╭─    / ························································································································································· 11 ✘  42s   00:02:22  ─╮
╰─ Failed to open curl lib from binary, use libcurl.so instead                                                                                                                                     ─╯
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
❯ 
❯ firefox --verbos
^C
❯ 
❯ firefox --verbose
ExceptionHandler::GenerateDump cloned child 71176ExceptionHandler::WaitForContinueSignal waiting for continue signal...

ExceptionHandler::SendContinueSignalToChild sent continue signal to child
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.

╭─    / ······················································································································································ 11 ✘  1m 29s   00:04:44  ─╮
╰─ Failed to open curl lib from binary, use libcurl.so instead