4 ms·

It's good you are testing their experimental Wayland support, but there might be reasons it is not default yet. > Xorg is definitely going away Are you sure a

It's good you are testing their experimental Wayland support, but there might be reasons it is not default yet. > Xorg is definitely going away Are you sure about that? I mean Xorg is going away, but XWayland is not. I've heard alsa is going away too for decades. Pipewire still implements support for it's API. I don't think XWayland is going anywhere for the foreseeable future.

BrightGlow 5y ago
Use of the term "alsa" is confusing here because ALSA refers to both the kernel interface in /dev and the userspace API in alsalib. The ALSA userspace API is mostly not relevant to applications, new apps probably will not target that and will instead target Pulse, Jack or Pipewire. Of course, Pulse, Jack and Pipewire still use the ALSA kernel API internally, and do implement compatibility for its userspace API just so that older applications still work. You're correct that XWayland is likely not going away any time soon but I would suggest avoiding it if you can, it's only for compatibility with legacy apps. It still has some of the same security issues as Xorg but they're confined only to other concurrently-run XWayland apps.
hollerith 5y ago
On my install (Fedora 34, Gnome 40, Chrome Stable) if I run Chrome under XWayland (i.e., if I refrain from giving the flags -enable-features=UseOzonePlatform and -ozone-platform=wayland when starting Chrome) and set Gnome's scaling factor to 200% (gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']", then using the "display" tab of Gnome's Settings app), Chrome is blurry. Probably it is rendering into a framebuffer, then that buffer is being scaled up such that every pixel in the buffer becomes a 2-by-2 square of pixels on my screen, hence my experience of blurriness. I don't own a hi-DPI monitor, but if I did do you know how to avoid everything's being drawn twice as small as usual without blurriness, i.e., without essentially downgrading the hi-DPI monitor to a normal-DPI monitor? If (as I suspect) a person cannot do what I asked you how to do, i.e., a person cannot currently configure the set of software I described above to be normal sized on a hi-DPI display without blurriness and without "full Xorg" (i.e., not just XWayland, i.e., requiring parts of X11 that definitely aren't being maintained anymore), do you expect XWayland to be improved so that that becomes possible in the future?
- BrightGlow 5y ago
  If this is working correctly on other apps, then it's probable that Chrome's Wayland support is not complete yet.
  - hollerith 5y ago
    No, it works on no app (that hasn't been modified and configured to speak the Wayland protocol) because of a fundamental limitation of XWayland.
    - deleted 5y ago
      [deleted]
    - BrightGlow 5y ago
      Sorry I misread your comment, ignore me. Although I will add: It might be possible that someone gets high-DPI working eventually in XWayland. It's unlikely that X11 will ever support multi-DPI in the same way as Wayland. There is an open MR for something like it though: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/733 https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...

BrightGlow 5y ago

Use of the term "alsa" is confusing here because ALSA refers to both the kernel interface in /dev and the userspace API in alsalib. The ALSA userspace API is mostly not relevant to applications, new apps probably will not target that and will instead target Pulse, Jack or Pipewire. Of course, Pulse, Jack and Pipewire still use the ALSA kernel API internally, and do implement compatibility for its userspace API just so that older applications still work. You're correct that XWayland is likely not going away any time soon but I would suggest avoiding it if you can, it's only for compatibility with legacy apps. It still has some of the same security issues as Xorg but they're confined only to other concurrently-run XWayland apps.

hollerith 5y ago

On my install (Fedora 34, Gnome 40, Chrome Stable) if I run Chrome under XWayland (i.e., if I refrain from giving the flags -enable-features=UseOzonePlatform and -ozone-platform=wayland when starting Chrome) and set Gnome's scaling factor to 200% (gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']", then using the "display" tab of Gnome's Settings app), Chrome is blurry. Probably it is rendering into a framebuffer, then that buffer is being scaled up such that every pixel in the buffer becomes a 2-by-2 square of pixels on my screen, hence my experience of blurriness. I don't own a hi-DPI monitor, but if I did do you know how to avoid everything's being drawn twice as small as usual without blurriness, i.e., without essentially downgrading the hi-DPI monitor to a normal-DPI monitor? If (as I suspect) a person cannot do what I asked you how to do, i.e., a person cannot currently configure the set of software I described above to be normal sized on a hi-DPI display without blurriness and without "full Xorg" (i.e., not just XWayland, i.e., requiring parts of X11 that definitely aren't being maintained anymore), do you expect XWayland to be improved so that that becomes possible in the future?

BrightGlow 5y ago
If this is working correctly on other apps, then it's probable that Chrome's Wayland support is not complete yet.
- hollerith 5y ago
  No, it works on no app (that hasn't been modified and configured to speak the Wayland protocol) because of a fundamental limitation of XWayland.
  - deleted 5y ago
    [deleted]
  - BrightGlow 5y ago
    Sorry I misread your comment, ignore me. Although I will add: It might be possible that someone gets high-DPI working eventually in XWayland. It's unlikely that X11 will ever support multi-DPI in the same way as Wayland. There is an open MR for something like it though: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/733 https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...