4 ms·

Wayland seems pretty good to me now. There are still the odd issues with HiDPI but I think that's mainly down to XWayland support in apps that don't support Wa

by Lio 4y ago

Wayland seems pretty good to me now. There are still the odd issues with HiDPI but I think that's mainly down to XWayland support in apps that don't support Wayland natively yet. e.g. If I'm running VLC and I move it from a 1:1 screen to a HiDPI screen then my mouse pointer goes tiny as it passes over it. It's a similar situation for some older Electron based apps too. Support for XWayland is OKish but not seamless. Hopefully time will solve that, for VLC I think that should happen in version 4.

Gigachad 4y ago
Mixed DPI is basically unusable on Wayland due to X11 apps but last I checked, X doesn't even support this at all. I gave up waiting because years later still almost every non Gnome app is electron or otherwise running in XWayland. Just changed my monitors to have the same dpi scale.
- harshitaneja 4y ago
  Been away from linux GUI systems for some time but isn't that resolved now with ozone in chromium which brings wayland support. I remember using electron beta with ozone and building vscode with it for proper wayland support. It worked quite well then.
  - Gigachad 4y ago
    I saw that it was supposedly fixed a while ago but as of this year I can confirm that Steam, Spotify, Telegram, Discord, and VS code do not DPI scale properly. The most offensive one is that Telegram _used_ to scale properly and somehow they broke it about a year ago. GTK also still does not support fractional scailing despite the majority of monitors being sold right now are optimal at 125% or 150%.
- deleted 4y ago
  [deleted]
- ryandrake 4y ago
  I have had a set up with a “retina” iMac (5120 × 2880) surrounded by two Thunderbolt displays (2560 × 1440) for close to a decade. No Linux distribution I’ve tried has managed to handle the different DPIs properly during this entire time period. There may be a way to cobble it together but I gave up many times. Neither the display layer, the window manager, nor the apps seem to be able to take full responsibility for figuring it out. Windows (through Bootcamp) barely understands the setup and even still, dragging windows across the DPI borders results in horrible jank and artifacts. Only macOS has this “multiple DPI monitors wizardry” figured out, and it worked from day one.
  - Gigachad 4y ago
    These days the distros themselves all support it fine and the built in programs all work correct. But any program which relies on the XWayland compatibility layer does not work as X11 has no support for live switching dpi without killing the window and recreating it. Apple has the advantage of forcing programs to use new apis while on the Linux side you have boomers insisting on using obsolete tech until they die because it lets them use gimp over telnet.
  - Nursie 4y ago
    It is a pain in Xorg, and a manual process, but doable with xrandr. Effectively you can over-render and scale to make things consistent. But it is a pain in the ass and I have to run the script every session.
- badsectoracula 4y ago
  > Mixed DPI is basically unusable on Wayland due to X11 apps but last I checked, X doesn't even support this at all. Xorg/RandR provides the necessary info, but it is up to the apps (really, toolkits) to work with that and to do it properly it needs the cooperation of both window managers and applications(toolkits) to define some messages/events for scaling, etc. It shouldn't be any different than the other common stuff between X clients, like ICCCM and EWMH (if anything, it should be part of a new version of EWMH), but nobody has bothered so far. Also there is the -separate- issue where under XWayland, Wayland is lying to X about DPI so apps cannot scale themselves if needed. E.g. Lazarus/LCL has its own scaling logic which works even with the Gtk2 backend (Gtk2 has no scaling logic itself) under Xorg but under XWayland the compositor is lying to the program that is running at 96 (or whatever "non-hidpi") DPI and does bitmap scaling instead (so applications appear blurry). Or at least this is how it is under KDE (which is the only DE i have installed on my PC to use as a secondary environment for testing out stuff - i mainly use Window Maker myself as my main environment).

by Lio 4y ago

Gigachad 4y ago

Mixed DPI is basically unusable on Wayland due to X11 apps but last I checked, X doesn't even support this at all. I gave up waiting because years later still almost every non Gnome app is electron or otherwise running in XWayland. Just changed my monitors to have the same dpi scale.

harshitaneja 4y ago
Been away from linux GUI systems for some time but isn't that resolved now with ozone in chromium which brings wayland support. I remember using electron beta with ozone and building vscode with it for proper wayland support. It worked quite well then.
- Gigachad 4y ago
  I saw that it was supposedly fixed a while ago but as of this year I can confirm that Steam, Spotify, Telegram, Discord, and VS code do not DPI scale properly. The most offensive one is that Telegram _used_ to scale properly and somehow they broke it about a year ago. GTK also still does not support fractional scailing despite the majority of monitors being sold right now are optimal at 125% or 150%.
deleted 4y ago
[deleted]
ryandrake 4y ago
I have had a set up with a “retina” iMac (5120 × 2880) surrounded by two Thunderbolt displays (2560 × 1440) for close to a decade. No Linux distribution I’ve tried has managed to handle the different DPIs properly during this entire time period. There may be a way to cobble it together but I gave up many times. Neither the display layer, the window manager, nor the apps seem to be able to take full responsibility for figuring it out. Windows (through Bootcamp) barely understands the setup and even still, dragging windows across the DPI borders results in horrible jank and artifacts. Only macOS has this “multiple DPI monitors wizardry” figured out, and it worked from day one.
- Gigachad 4y ago
  These days the distros themselves all support it fine and the built in programs all work correct. But any program which relies on the XWayland compatibility layer does not work as X11 has no support for live switching dpi without killing the window and recreating it. Apple has the advantage of forcing programs to use new apis while on the Linux side you have boomers insisting on using obsolete tech until they die because it lets them use gimp over telnet.
- Nursie 4y ago
  It is a pain in Xorg, and a manual process, but doable with xrandr. Effectively you can over-render and scale to make things consistent. But it is a pain in the ass and I have to run the script every session.
badsectoracula 4y ago
> Mixed DPI is basically unusable on Wayland due to X11 apps but last I checked, X doesn't even support this at all. Xorg/RandR provides the necessary info, but it is up to the apps (really, toolkits) to work with that and to do it properly it needs the cooperation of both window managers and applications(toolkits) to define some messages/events for scaling, etc. It shouldn't be any different than the other common stuff between X clients, like ICCCM and EWMH (if anything, it should be part of a new version of EWMH), but nobody has bothered so far. Also there is the -separate- issue where under XWayland, Wayland is lying to X about DPI so apps cannot scale themselves if needed. E.g. Lazarus/LCL has its own scaling logic which works even with the Gtk2 backend (Gtk2 has no scaling logic itself) under Xorg but under XWayland the compositor is lying to the program that is running at 96 (or whatever "non-hidpi") DPI and does bitmap scaling instead (so applications appear blurry). Or at least this is how it is under KDE (which is the only DE i have installed on my PC to use as a secondary environment for testing out stuff - i mainly use Window Maker myself as my main environment).