Elmord's Magic Valley

Computers, languages, and computer languages. Às vezes em Português, sometimes in English.

Posts com a tag: x11

The day I almost switched to Wayland

2023-10-10 19:50 +0100. Tags: comp, unix, x11, wayland, in-english

A couple of days ago, I decided to give Wayland a go. For those of you who live under a rock, Wayland is meant to be the successor of X11, the traditional graphical server/protocol in the GNU/Linux world, responsible for things such as drawing windows on your screen, passing keyboard and mouse events to the correct programs, etc. (I live under a rock too, but sometimes I stretch my head out to see what is going on in the world, only to crawl back not long after.)

Like with most technology transitions, there is a lot of drama going around Wayland vs. X11 and their respective merits and demerits. Reading such discussions can be quite frustrating; not only people can have widely different usage and requirements from graphics functionality – gaming (with different kinds of games), watching videos with varying resolutions and refresh rates, different graphics cards, accessibility settings, desktop environments, etc. –, but people can also differ in how they perceive little functionality changes just because of variation in how their eyes or brains work. A relatively minor glitch (such as screen tearing while playing a video, a couple milliseconds extra delay to process a keystroke in a game, or a font that renders slightly differently) can be a huge annoyance to one person, barely noticeable to another, and literally invisible to a third one. The result is that such discussions feel like people are talking past one another, unable to understand why others would make a different choice from them and insist on being wrong on the internet. People in the GNU/Linux world are also used to enjoying immense freedom to choose, customize and build their own desktop environments, which also contributes to the wide variety of experiences and difficulties in switching from one graphical stack to another.

If you want to understand why Wayland exists, you can watch The real story behind Wayland and X, a Linux.conf.au presentation by Daniel Stone, a Wayland and former X.org developer. Basically, X.org contains a huge number of features that are not used by modern clients but have to be kept around for compatibility, and limit the ways in which problems with X can be solved. Originally, the X server used to be responsible for font rendering, drawing graphical primitives, and a variety of other functions that nowadays are done by the clients themselves; modern clients usually just want to send a fully rendered image for the server to display. All the old cruft accumulated across the four decades of X11’s existence make it hard to maintain for developers.

One thing that is noticeable in these discussions about X11 vs Wayland is that one hears a lot from X11 users defending X11, Wayland users defending Wayland, Wayland developers defending Wayland, but not much from X11 developers. The main reason for this is that X11 developers are Wayland developers by and large. The X.org server is pretty much in maintenance mode, and much if not most of development that still goes on in the xserver repo is related to Xwayland, the compatibility layer that allows X11 clients to run on Wayland. As much as we may like X.org, if developers don’t want to work on it, there’s not much we can do about it (and it seems that it’s pretty hard for new developers to get started on it, due to the accumulated complexity). Granted, X.org isn’t going away any time soon, but it’s also not going anywhere. Regardless of the technical merits of Wayland vs. X11, it seems pretty clear that Wayland is the future going forward.

First impressions

So far I have stayed in the comfort of my old X11 setup, mainly because I had no reason to put an effort into switching. A reason finally showed up, though: on my current laptop (a ThinkPad E14 4th generation), I see quite a bit more tearing while watching videos than on my previous PCs. Although it is within the range of what I can live with (after all I’ve been using this computer for almost a year like this), all else being equal, it’s something I would like to get rid of.

The first step into switching to Wayland is picking a compositor: the application responsible for managing windows and drawing on the screen. On X11, the window manager and the X server are two different programs; on Wayland, both of these roles are taken by the compositor. The idea here is to cut out the middleman since (1) nowadays the graphics card driver lives in the kernel, which exposes it as a framebuffer device, unlike in the olden days where you would have different X drivers to handle different graphics cards, and (2) most modern window managers do compositing anyway, so instead of having the window manager composite the image of the whole desktop, then give it to X to draw it on the screen, the compositor can write it directly to the graphics card.

This means that there are effectively as many Wayland servers as there are window managers out there. This is annoying because the compositor is not only responsible for managing windows, but also handling input devices, keyboard layouts, accessibility features, clipboard, and a variety of other things that were traditionally handled by the X server. Each compositor has to implement these features on its own, and although there are common libraries that are used by different compositors to implement some of these features (e.g., libinput), there is often no standard way to access those features that is portable across different compositors. For instance:

Some of these features may end up being standardized as protocol extensions (see wlr-protocols and wayland-protocols), but which protocols will be supported by each compositor will vary. This feels like the situation in Scheme with its various SRFIs that different implementations may or may not support, or XMPP where support for a feature depends on the client and server supporting the desired set of extensions. I suppose the situation will improve in the upcoming years as the set of protocol extensions gets more standardized, but the current situation is this. The thing is that this is a non-issue in X: new window managers don’t need to care about any of this, because the X server handles these the same way regardless of what is your window manager.

As soon as I open the Sway session and start up lxterminal, I notice an issue: lxterminal on Wayland is not honoring my FREETYPE_PROPERTIES='truetype:interpreter-version=35' environment variable. This setting changes the font rendering algorithm such that fonts look crispier, especially in non-HiDPI displays. This is well within the “some people won’t even notice” category, but for me the difference is noticeable (particularly in my external display), it took me ages to figure out this setting existed, and I’m not willing to give it up easily (at least not until I switch to an HiDPI external display, something that probably won’t happen within the next couple of years). I noticed that Emacs did not suffer from this issue, but it turns out Emacs was running under Xwayland. It’s nice indeed to see that X11 apps run seamlessly enough under Wayland that it took me some work to realize that it was running under Xwayland and not natively. (I figured it out by calling xprop: it only reacts to clicks on X11 windows.) I installed foot, a lightweight native Wayland terminal that is recommended by the sway package on Debian, and it also suffers from this issue. So it seems to be a general issue with Freetype under Wayland, which is weird because font rendering should be a client-side problem and should be the same under X11 and Wayland.

Finally, I tried to start up the NetworkManager applet. Just running nm-applet won’t show anything, because by default nm-applet uses the Xembed protocol to create a tray icon, which is not supported by Swaybar; you have to run nm-applet --indicator instead. However, clicking on the icon does nothing; it seems that the context menu on tray icons is currently not supported (as of Sway 1.7). It does work with Waybar (and the context menu has the same font rendering issue; in fact I’m not even sure it’s using the same font), but Waybar has a lot more bells and whistles I’m not interested in, plus I would have to figure out how to adapt my current status bar script to it (assuming it’s possible), which is pretty important to me as I use the i3 status bar to display desktop notifications.

The lack of Xembed tray icon support is a problem for another program I use as well: Thunderbird. As of 2023, I’m still using Thunderbird 52 (released in 2018) because it’s the last version that supports FireTray, which shows me a glorious tray icon with a number of unread messages whenever there are unread messages in selected folders, and no icon otherwise. I know that one day I will probably have to switch to a different mail client and/or workflow, but that day is not going to be now.

It does eliminate screen tearing, though. But also it turns out I could fix that on X.org by using picom --backend glx --vsync. [Update: Actually that doesn't fully fix it, and sometimes causes other glitches of its own. Wayland wins in this regard.]

Crawling back to under my rock

In The technical merits of Wayland are mostly irrelevant, Chris Siebenmann argues that everyone who would switch from X to Wayland by virtue of its technical merits has already switched. The people who haven’t done so fall into a bunch of categories, one of which is:

People using desktop environments or custom X setups that don’t (currently) support Wayland. Switching to Wayland is extremely non-transparent for these people because they will have to change their desktop environment (so far, to GNOME or KDE) or reconstruct a Wayland version of it.

I happen to be in this category. Sway can mostly replace i3, but then I have to find a replacement for nm-applet (or use Waybar and change my status bar script), a replacement for FireTray, rewrite my jump-to-window script, figure out what the heck is going on with the font rendering, change my scripts that currently use xrandr, etc. All of this to get a desktop just as good as my current X11 one; switching to Wayland does not really bring me any new functionality or improvements. Maybe a few years from now, as X.org starts to bit-rot and new stuff starts to be developed for Wayland exclusively, switching will become more compelling. As of 2023, though, I don’t really have much to gain from it, and I’d rather spend my time on other adventures, at least for now.

But I don’t share the Wayland hate I see in various places around the interwebs. When the time comes (or when I feel like it), I will make the switch. By then, hopefully some of the issues above will have been fixed (e.g., more standardized protocol extensions, menu support for Swaybar tray icons), hopefully I will have found a replacement for FireTray, and maybe I will have switched to a HiDPI external monitor. Until then, long live X.org.

2 comentários / comments

Lenovo L22e-20 screen brightness and XRandR mode

2021-02-07 12:41 +0000. Tags: comp, unix, x11, in-english

Computer screens are a complicated business for me: most screens are too bright for my eyes even at the zero brightness setting. I have had some luck with the most recent laptops I used, though – a Dell Latitude 7490 I bought second-hand last year, and an HP Pavillion Gaming Laptop provided by my company, both of which have excellent screens – so I wondered if maybe monitor technology had improved enough lately that I would be able to get an external monitor that won’t burn my eyes after a few hours use. So I decided to try my luck with a Lenovo L22e-20 monitor.

When it arrived, I tried it out and was immediately disappointed. It was just as bad brightness-wise as every other LCD external monitor I had used. Even at the zero brightness setting, the black background was not black, but dark grey, which made the contrast too low. The image quality was really good for watching videos, but for staring at text for extended periods of time, it was just not comfortable to look at; my laptop screen was much better. I was so disappointed that I decided I would return the monitor and order a different one.

A couple of days later, I decided to try it again, and to my great surprise, the monitor did not look bad at all. The black was really black, the brightness was pretty good (though I wish I could lower it a little bit further at night). I wondered if I had just gotten used to the new monitor, but the difference was so great that it was hard to believe it was just a psychological effect.

A few hours later, I wanted to see how i3 would handle workspaces when screens are disconnected or connected to a running session. So I disconnected the Lenovo monitor and connected it again – and to my even greater surprise the screen came back with the awful brightness of the first time. I tried to look at every setting in the monitor, but nothing had changed; I tried disconnecting and connecting again, to no avail; I tried to turn everything off and on again – nothing changed, same awful brightness.

The next day, I decided to look at XRandR settings – maybe it was some software-side gamma or brightness setting or something that was affecting the brightness. I ran xrandr --verbose, and gamma/brightness values were normal, but I noticed something else: there were five different 1920x1080 modes for the screen. This is the relevant part of the output:

  1920x1080 (0xa4) 148.500MHz +HSync +VSync *current +preferred
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  67.50KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  60.00Hz
  1920x1080 (0xa5) 174.500MHz +HSync -VSync
        h: width  1920 start 1968 end 2000 total 2080 skew    0 clock  83.89KHz
        v: height 1080 start 1083 end 1088 total 1119           clock  74.97Hz
  1920x1080 (0xa6) 148.500MHz +HSync +VSync
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  67.50KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  60.00Hz
  1920x1080 (0xa7) 148.500MHz +HSync +VSync
        h: width  1920 start 2448 end 2492 total 2640 skew    0 clock  56.25KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  50.00Hz
  1920x1080 (0xa8) 148.352MHz +HSync +VSync
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  67.43KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  59.94Hz

Here, besides the resolution, frequencies, and other characteristics, each mode is identified by a hexadecimal code in parentheses (0xa4, 0xa5, etc.). Turns out you can pass those codes to the xrandr --mode option instead of a resolution such as 1920x1080 to select one among multiple modes with the same resolution.

I decided to try the other modes, just to see what difference it would make – and lo and behold, the second mode made the screen brightness good again! All the other modes left the screen with the bright background. I don’t know what it is specifically about this mode that had an effect on brightness, but I notice two things: it is the mode with the highest frequency, and it is the only one with -VSync rather than +VSync (the xorg.conf manpage tells us this is the polarity of the VSync signal, whatever that is). Maybe one (or both) of these elements is involved in the trick.

Actually, even if you run xrandr without the --verbose option, it will list potentially multiple modes for each resolution, by showing all available refresh rates for each resolution:

HDMI-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 476mm x 268mm
   1920x1080     60.00 +  74.97*   60.00    50.00    59.94  
   1920x1080i    60.00    50.00    59.94  
   1680x1050     59.88  
   1280x1024     75.02    70.00    60.02  
   1440x900      59.90  
   1152x864      75.00  
   1280x720      60.00    60.00    50.00    59.94  
   1024x768      75.03    70.07    60.00  
   800x600       72.19    75.00    60.32  
   720x576       50.00    50.00    50.00  
   720x480       60.00    60.00    59.94    59.94    59.94  
   640x480       75.00    72.81    60.00    59.94    59.94  
   720x400       70.08  

I had never paid much attention to this, but you can actually select the specific mode you want by calling, for example, xrandr --output HDMI-1 --mode 1920x1080 --rate 74.97, specifying both the resolution and the refresh rate. In some cases, though, there are multiple modes with the same refresh rate (for example, the 720x576 line above has three different modes with the same refresh rate 50.00); in this case, I think the only way to choose a specific mode is to specify the hexadecimal code of the mode listed by the --verbose option.

If you don’t specify a refresh rate or give a specific mode hex code, XRandR will theoretically select the “preferred” mode, which is the one with a + sign after it in the output. For this Lenovo monitor, the preferred mode is a bad one, so you have to override it with these options.

The weirdest thing about this story is that, on the day the monitor was suddenly good, Xorg had apparently selected a non-preferred mode by pure chance for some reason. If that had not happened, I would probably have never discovered that the monitor had a good mode at all.

2 comentários / comments

Main menu

Recent posts

Recent comments


em-portugues (213) comp (148) prog (71) in-english (62) life (49) unix (38) pldesign (37) lang (32) random (28) about (28) mind (26) lisp (25) fenius (22) mundane (22) web (20) ramble (18) img (13) rant (12) hel (12) scheme (10) privacy (10) freedom (8) esperanto (7) music (7) lash (7) bash (7) academia (7) copyright (7) home (6) mestrado (6) shell (6) android (5) conlang (5) misc (5) emacs (5) latex (4) editor (4) etymology (4) php (4) worldly (4) book (4) politics (4) network (3) c (3) tour-de-scheme (3) security (3) kbd (3) film (3) wrong (3) cook (2) treta (2) poem (2) physics (2) x11 (2) audio (2) comic (2) lows (2) llvm (2) wm (2) philosophy (2) perl (1) wayland (1) ai (1) german (1) en-esperanto (1) golang (1) translation (1) kindle (1) pointless (1) old-chinese (1)


Quod vide

Copyright © 2010-2024 Vítor De Araújo
O conteúdo deste blog, a menos que de outra forma especificado, pode ser utilizado segundo os termos da licença Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International.

Powered by Blognir.