gitlab.freedesktop.org

lnxtx, to linux in libcamera v0.2.0 released!
@lnxtx@feddit.nl avatar

libcamera:

A complex camera support library for Linux, Android, and ChromeOS

Cameras are complex devices that need heavy hardware image processing operations. Control of the processing is based on advanced algorithms that must run on a programmable processor. This has traditionally been implemented in a dedicated MCU in the camera, but in embedded devices algorithms have been moved to the main CPU to save cost. Blurring the boundary between camera devices and Linux often left the user with no other option than a vendor-specific closed-source solution.

To address this problem the Linux media community has very recently started collaboration with the industry to develop a camera stack that will be open-source-friendly while still protecting vendor core IP. libcamera was born out of that collaboration and will offer modern camera support to Linux-based systems, including traditional Linux distributions, ChromeOS and Android.

iturnedintoanewt,
@iturnedintoanewt@lemm.ee avatar

Any idea on whether is there more devices supported now? Those release notes are quite gibberish to me. My Surface SP7 camera isn’t compatible as of yet :(

Molecular0079,

SP7 camera isn’t going to be supported until we get IPU4 Linux drivers, so it isn’t a libcamera issue.

github.com/linux-surface/…/Camera-Support

iturnedintoanewt,
@iturnedintoanewt@lemm.ee avatar

Thanks for the clarification! I thought they were related.

kingmongoose7877,
@kingmongoose7877@lemmy.ml avatar

Thank you for that.

pastermil, to linux in Wlroots 0.17.0 released

How would wlroots relate to the compositors such as KWin & GNOME Shell?

russjr08,
@russjr08@outpost.zeuslink.net avatar

As far as I know, it wouldn’t - I do not believe KWin nor Mutter is built on top of wlroots.

FarLine99,

They are not

Laser, (edited )

As pointed out, they don’t use it. However, there are loose plan for KWin to migrate to wlroots one day, and in fact a hostile fork exists that is exactly that (KWinFT). So a compositor can make use of wlroots to implement Wayland functionality, sway for example does exactly that, unsurprisingly since they’re sister projects by the same author.

It should be noted that libwayland (mentioned in the patch notes) also exist, and wlroot actually depends on it, so I guess libwayland is like the lower level stuff while wlroots saves you some work to integrate libwayland into your compositor; the motto is “Pluggable, composable, unopinionated modules for building a Wayland compositor; or about 60,000 lines of code you were going to write anyway.”

ultra,

Just a note, you said that libwayland is a higher level abstraction for libwayland.

Laser,

Thanks, I corrected it

starman,
@starman@programming.dev avatar

libwayland is like the lower level stuff while libwayland saves you some work to integrate libwayland

LeFantome,

Makes sense. You have to factor in libwayland though.

Chewy7324,

wlroots is a library that can be used to implement a compositor like KWin or mutter (GNOME). In practice wlroots is used in Sway, Hyprland, river, and more.

What wlroots-based compositors, KWin, and mutter share is that they implement a similar set of the display protocol Wayland. E.g. KWin and Sway implement the Wayland extension wlr_layer_shell

Chewy7324, to linux in Wlroots 0.17.0 released
  • wp-fractional-scale-v1 to allow clients to submit buffers with a non-integer scale factor matching the output.

This hopefully means Sway and similar will support real fractional scaling for applications, not just the compositor fractional scaling we already have.

But I don’t know much about application support. Qt and Electron might support it; GTK 4 does not, possibly in a future version).

wayland.app/protocols/fractional-scale-v1

  • tearing-control to allow clients to opt-in for tearing page-flips.

That’s great for those who need it. Anyone with a modern display should probably just use variable refresh rate (vrr), but even today some devices don’t support it. E.g. there’s been 240Hz laptops without vrr.

wayland.app/protocols/tearing-control-v1

Atemu,
@Atemu@lemmy.ml avatar

GTK 4 does not, possibly in a future version

That would be news to me. Has GTK finally managed to switch away from using actual real hardware pixels as its base unit for measurement?

Chewy7324,

I was sure I read that GTK wants to support true fractional scaling in GTK 5, but I can’t find a source to it. So it was probably just speculation. As far as I understand it, it would require big changes to GTK because everything is build with integer scaling in mind.

At least GTK 4 already has support for this fractional scaling protocol.

www.phoronix.com/news/GTK-4.11.1

independantiste,
@independantiste@sh.itjust.works avatar

At least it does not look blurry with fractional scaling enabled, which is the biggest issue IMO. The current hacky way is not ideal I agree but at least it is functional

  • All
  • Subscribed
  • Moderated
  • Favorites
  • localhost
  • All magazines
  • Loading…
    Loading the web debug toolbar…
    Attempt #