Weston 11.0: what's new, what's next (Collabora blog)

[Posted September 29, 2022 by jake]

Over on the Collabora blog, Marius Vlad writes about the recent Weston 11.0.0 release. Weston is the reference compositor for the Wayland display server protocol. Vlad looks at features of the release, including some things that are being deprecated and removed, as well as features coming in Weston 12.

Color management infrastructure code has landed that allows HDR [high dynamic range] characteristics to be delivered to an HDR-capable monitor by setting-up HDR metadata in a weston.ini configuration file and delivering that to KMS [kernel mode setting]. Once Weston gains the ability to produce HDR content in a future version, it will come naturally supported.
This new version brings in multiple RDP [remote desktop protocol] improvements, like clipboard pasting, various keyboard language support, bumped support for a newer version of FreeRDP library, and many more other improvements and fixes.

Weston 11.0: what's new, what's next (Collabora blog)

Posted Sep 30, 2022 6:50 UTC (Fri) by zdzichu (guest, #17118) [Link] (12 responses)

Great too see initial HDR support. Now it will be ported to gnome-shell in a few months, then Kodi will get support in a few iterations. I expect to be able to playback HDR content on my media machine in 2024 or so...

Weston 11.0: what's new, what's next (Collabora blog)

Posted Sep 30, 2022 7:22 UTC (Fri) by leromarinvit (subscriber, #56850) [Link] (10 responses)

Never mind HDR, I'm still waiting for basic color management to be specified and implemented (issue). This makes Wayland a complete non-starter for me personally for now - my 3 monitors need different ICC profiles loaded to look even roughly similar. Without that, the differences are so large they're almost unusable next to each other.

It seems to me that enabling accurate color rendering should be a core feature of display infrastructure - I'm a bit baffled this regression (vs X11) is hardly ever mentioned.

Weston 11.0: what's new, what's next (Collabora blog)

Posted Sep 30, 2022 8:34 UTC (Fri) by cortana (subscriber, #24596) [Link] (1 responses)

Not to mention a way for telephony applications to implement a global 'push to talk' button that works when other windows have the focus...

Weston 11.0: what's new, what's next (Collabora blog)

Posted Oct 13, 2022 19:42 UTC (Thu) by deltragon (guest, #159552) [Link]

This is now in xdg-desktop-portal, so should show work soonish: https://github.com/flatpak/xdg-desktop-portal/pull/711
Eg. KDE already has an implementation pending

Weston 11.0: what's new, what's next (Collabora blog)

Posted Sep 30, 2022 8:35 UTC (Fri) by rsidd (subscriber, #2582) [Link] (2 responses)

It is implemented in Weston 11 but is a WIP. From the release announcement:

- Continued work on color management infrastructure:
In Weston 11, if you enable the tentative, experimental and WIP color
management option, Weston will not only blend in linear light, but
you can also set up a monitor ICC profile and Weston will do some
kind of color mapping from sRGB to that profile. Furthermore, you can
configure a monitor into HDR mode and deliver HDR characteristics from
weston.ini to the monitor, but Weston will *not* produce proper HDR
content yet, meaning the display is incorrect.

There is also ongoing work in wlroots/sway, apparently delayed because of the upstream interest (ie the issue tracker you linked to).

This older article goes into some details.

Weston 11.0: what's new, what's next (Collabora blog)

Posted Sep 30, 2022 8:53 UTC (Fri) by leromarinvit (subscriber, #56850) [Link] (1 responses)

Thanks for pointing this out, I should have checked the announcement... I assumed that since the protocol merge request was still open, it hadn't been implemented yet and the quoted part was just about preliminary infrastructure work.

I guess that means I can now seriously try out Wayland some day without knowing beforehand I'll be moving back to Xorg anyway - that's progress at least!

Weston 11.0: what's new, what's next (Collabora blog)

Posted Sep 30, 2022 10:34 UTC (Fri) by rsidd (subscriber, #2582) [Link]

Yes, once the protocol is implemented, any compositor can use it (as I understand). There are (old-ish) patches for sway and wlroots but not merged because of the ongoing upstream work.

Weston 11.0: what's new, what's next (Collabora blog)

Posted Sep 30, 2022 14:03 UTC (Fri) by swick (subscriber, #110059) [Link] (3 responses)

There is no regression in wayland compared to X11 when it comes to color management because X11 doesn't have any kind of color management features. What you're describing is applying monitor calibration that can be stored in ICC profiles and both weston and mutter have had this feature for a long time.

What you're calling "basic color management" is something we never had on linux and isn't about calibrating your monitor but creating (perceptual) color transforms of client content to the outputs.

Weston 11.0: what's new, what's next (Collabora blog)

Posted Oct 1, 2022 4:18 UTC (Sat) by patrakov (subscriber, #97174) [Link]

There is/was a regression compared to special X11 compositors that do implement full-screen color correction, like Compiz 0.8 with the CompICC plugin loaded. Or compared to KWin from KDE4 era.

Weston 11.0: what's new, what's next (Collabora blog)

Posted Oct 17, 2022 10:05 UTC (Mon) by gwg (guest, #20811) [Link] (1 responses)

While X11 doesn't have any built in color management features, it doesn't stand in the way of color management either. It doesn't prevent accessing the hardware to do color calibration. It doesn't conceal which display is being rendered to, and it provides a mechanism to tag each display with a color profile. As a result, color management has been available under X11 for a very long time, applications provide support for it, and end users expect it and use it.
On the other hand, the architecture and the developers of Wayland have been actively hostile to many of the needs to color management (a fact easily verifiable to anyone who is prepared to look back at the mailing list). The result is that currently color management on Wayland is crippled at best, unusable at worst. Can you calibrate ? Can you profile ? Can you match color across different displays ? No, No and No.

Weston 11.0: what's new, what's next (Collabora blog)

Posted Oct 17, 2022 12:30 UTC (Mon) by pizza (subscriber, #46) [Link]

> The result is that currently color management on Wayland is crippled at best, unusable at worst. Can you calibrate ? Can you profile ? Can you match color across different displays ? No, No and No.

Eh?

My Fedora GNOME desktop has had this for quite some time now, under Wayland. It's certainly been available since Fedora switched to Wayland by default, but the features were there some time before that.

So, yes, yes, and yes.

Weston 11.0: what's new, what's next (Collabora blog)

Posted Oct 18, 2022 10:52 UTC (Tue) by daniels (subscriber, #16193) [Link]

Support for that (mapping the basic colourspaces e.g. sRGB to a profiled output device) has been there for a long time, similarly to X11. The further colour-management work is about allowing clients to specify their own colour properties which will allow for their buffers to reach the output in the least destructive way possible.

Weston 11.0: what's new, what's next (Collabora blog)

Posted Oct 3, 2022 21:41 UTC (Mon) by bartoc (guest, #124262) [Link]

Kodi may need a lot of work to deal with the HDR content from the player side. Right now only mpv has anything even approaching support for decent HDR playback, and even mpv can't read full enhancement layer metadata from HDR content yet. Still, it does read the static metadata and can tonemap properly, meaning UHD/HDR versions of stuff do actually look better than FHD versions even on SDR displays.

Weston 11.0: what's new, what's next (Collabora blog)

Posted Sep 30, 2022 7:50 UTC (Fri) by geert (subscriber, #98403) [Link] (12 responses)

> - The fbdev backend has been removed (superseded by KMS).

There are still +100 fbdev drivers without a DRM counterpart.

Weston 11.0: what's new, what's next (Collabora blog)

Posted Sep 30, 2022 8:49 UTC (Fri) by lkundrak (subscriber, #43452) [Link] (10 responses)

That's rather sad.

I guess weston can still be used with some of affected hardware via simpledrm over firmware initalized framebuffer (on DT-driven ARM platforms) or VESA (on x86).

Does anyone know which one of those have the most significant real world use and would be good candidates for porting?

Weston 11.0: what's new, what's next (Collabora blog)

Posted Sep 30, 2022 19:56 UTC (Fri) by tdz (subscriber, #58733) [Link] (5 responses)

All the 90s/2ks desktop chips are good candidates. The ones with PCI cards should still work in fairly recent PCs. AGP cards are harder to get working these days, but also still possible.

I once make a conversion helper to run fbdev drivers within DRM. I also wrote initial DRM support for maybe a dozen fbdev drivers. Source code is at

https://gitlab.freedesktop.org/tzimmermann/linux/-/commit...

The kernel is still 5.4, but once you have something working, you can port it to a recent kernel.

Weston 11.0: what's new, what's next (Collabora blog)

Posted Oct 1, 2022 11:41 UTC (Sat) by geert (subscriber, #98403) [Link] (4 responses)

The conversion do offer some help, thanks a lot!

You can hear/read about my experiences from my talk at ELCE2022:
https://osseu2022.sched.com/event/15z6T/trading-fbdev-for...

Weston 11.0: what's new, what's next (Collabora blog)

Posted Oct 2, 2022 18:18 UTC (Sun) by tdz (subscriber, #58733) [Link] (3 responses)

Thanks for reporting on your experience. Just a few thoughts below.

* fbconv will never be upstreamed. Although I proposed it back then, it'll remain out of mainline. We just want the resulting DRM drivers.

* Thanks for doing the legwork of adding support for the low-end formats

* When you say fbdev emulation is 1x slower, you mean the kernel's fbcon writing onto the screen? How exactly did you test? Did you also test performance for userspace code that operates on /dev/fb?

Weston 11.0: what's new, what's next (Collabora blog)

Posted Oct 2, 2022 18:24 UTC (Sun) by geert (subscriber, #98403) [Link]

I only benchmarked console operation (time cat big-file) on the ARAnyM emulator.

I had hoped to do the Amiga fbdev to drm conversion before my talk, so I could provide benchmark data on real hardware, but unfortunately I didn't get there in time.

Weston 11.0: what's new, what's next (Collabora blog)

Posted Oct 3, 2022 10:29 UTC (Mon) by geert (subscriber, #98403) [Link] (1 responses)

I had only benchmarked the console, using fbcon.
One reason for the slow console is that everything is rendered using chunky pixels, and converted to interleaved bitplanes later. Rendering text (monochrome expansion) and scrolling (copying memory) can be done much more efficiently when operating directly on interleaved bitplanes.
For an application (e.g. a GUI), this is different. But given the age of Ataris, they may be used mostly with a simple 16-color text console, so text console performance is what matters most...
I ran fbtest test012 (Filling squares) and test013 (Filling circles) on the ARAnyM emulator, with both atafb and the WIP atardrm driver. Results are in Mpixels/s:

                |   640x480/C4  |   640x480/C8  |320x240/RGB565
                | fbdev |  drm  | fbdev | drm   | fbdev |  drm
10x10 squares   |  0.29 |  0.43 |  0.24 |  0.40 |  7.99 |  6.30
20x20 squares   |  0.54 |  4.81 |  0.34 |  0.72 | 20.46 | 17.23
50x50 squares   |  0.94 | 17.05 |  0.67 | 12.79 | 47.03 | 37.87
100x100 squares |  1.16 | 40.08 |  0.73 | 29.66 | 68.20 | 60.18
200x200 squares |  1.23 | 64.90 |  0.70 | 40.08 | 87.09 | 74.39
R5 circles      |  0.12 |  0.09 |  0.11 |  0.11 |  3.62 |  3.73
R10 circles     |  0.32 |  0.75 |  0.16 |  0.23 |  8.72 |  8.16
R25 circles     |  0.37 |  1.21 |  0.18 |  0.43 | 21.14 | 21.42
R50 circles     |  0.20 |  1.67 |  0.58 |  3.29 | 37.82 | 34.93
R100 circles    |  0.91 | 27.22 |  0.67 |  9.57 | 57.39 | 52.70

The native layout for C4/C8 is interleaved bitplanes, so conversion is needed when updating (copying to) the hardware frame buffer. The native layout for RGB565 is big endian, so no conversion is needed, just a copy.
Due to the use of deferred I/O in DRM, the hardware frame buffer is not updated instantaneously. This is clearly visible when running these tests, even on ARAnyM, which does its own deferred I/O as part of the emulation.
Findings:

Drawing to a C4/C8 shadow buffer is much faster than drawing to interleaved bitplanes, especially as fbtest does not have drawing routines specific to interleaved bitplanes for lines/rectangles yet (IIRC, XFree86 has), so it falls back to drawing individual pixels, which is really slow. This clearly shows an advantage of DRM for applications, which don't have to care about exotic pixel formats anymore.
For RB565, no conversion is needed, but there is an extra copy step.

Note that due to running on an emulator, the impact of memory bus bandwidth for the various types of memory (main RAM vs. ST-RAM, as used for graphics) cannot be seen.

Weston 11.0: what's new, what's next (Collabora blog)

Posted Oct 4, 2022 11:16 UTC (Tue) by tdz (subscriber, #58733) [Link]

Thanks for posting these numbers. I once discovered that going from cfb_imageblit() to sys_imageblit() reduced performance by similar factors on x86-64. It turned out that I/O reads/write where 32 bits at once, while system-memory access was bytewise. I fixed code for the RGB formats, but not the C formats. I wonder if you hit one of the unoptimized conversion paths in sys_imageblit() et al.

Yes, using deferred I/O is required to get an idea which framebuffer locations need to be flushed. Otherwise, we'd have to flush the full screen each time. It's also required because the graphics buffer's SHMEM pages currently cannot be mapped easily to userspace. I tried to fix that but did not get something working so far. We we could map the graphics buffer directly, we'd save an intermediate memcpy.

Weston 11.0: what's new, what's next (Collabora blog)

Posted Oct 1, 2022 0:29 UTC (Sat) by flussence (guest, #85566) [Link] (3 responses)

IIRC, as far as x86-relevant parts go, there's active efforts to get VIA Chrome GPUs unbitrotted on modern kernels, and a narrow range of Matrox ones get to keep good support because new servers use white-label clones of them (without the 3D part).

Anything else that goes in a PCI, ISA or VLB slot and can't run Compiz or TuxRacer is probably in bad shape. The only ones that come to mind that might be worth fixing up are pre-Radeon ATi cards, a few S3 ones, onboard Intel chips from the Vista era, maybe Matrox ones that aren't already working. Anything else is probably too weak to run a useful GUI.

Weston 11.0: what's new, what's next (Collabora blog)

Posted Oct 1, 2022 9:32 UTC (Sat) by syrjala (subscriber, #47399) [Link] (2 responses)

The only unsupported Intel GPUs (excluding the PowerVR stuff obviously) are i740 (AGP card, released in 1998) and i810 (P3 chipset, released in 1999). Everything starting from i830 (released ca. 2001) is supported by the i915 driver.

Weston 11.0: what's new, what's next (Collabora blog)

Posted Oct 1, 2022 11:53 UTC (Sat) by geert (subscriber, #98403) [Link] (1 responses)

Linux runs not only on Intel desktops, which the DRM people tend to forget?...

Weston 11.0: what's new, what's next (Collabora blog)

Posted Oct 1, 2022 16:56 UTC (Sat) by syrjala (subscriber, #47399) [Link]

I guess you either didn't read what I wrote, or answered the wrong thread. I was specifically challenging the claim that there is some Vista era _Intel_ hardware that lacks a drm driver but has an fbdev driver. No such things exists.

Weston 11.0: what's new, what's next (Collabora blog)

Posted Sep 30, 2022 19:46 UTC (Fri) by tdz (subscriber, #58733) [Link]

I think it's fair to add that few people have shown up to port them. The ones that did, disappeared as soon as they realized that they are supposed to maintain and improve the code. (You're the exception from the rule here. :)