5 ms·

Well it doesn't rely on using a giant buffer for multiple monitors so it supports hidpi scaling. Have you ever tried hidpi on xorg? It's a mess, even on Ubuntu

by perth 5y ago

Well it doesn't rely on using a giant buffer for multiple monitors so it supports hidpi scaling. Have you ever tried hidpi on xorg? It's a mess, even on Ubuntu where they tried their best to clean it up. The xorg apps from the compatibility layer still suffer from it, probably until they update to Wayland. Sidenote: Google tried to use xorg for ChromeOS and ended up writing their own UI system for hidpi scaling among other things when it didn't work Some relevant links for those curious about other people hitting into this: https://www.foell.org/justin/simple-hidpi-monitor-scaling-with-wayland-in-ubuntu-18-04/ https://www.foell.org/justin/simple-hidpi-monitor-scaling-wi... Gnome team: https://wiki.gnome.org/Initiatives/Wayland/XWayland https://wiki.gnome.org/Initiatives/Wayland/XWayland

jcelerier 5y ago
Setting DPI in .Xresources had worked fine for me since 2014 except for Firefox and Chrome which took a year or so to adapt
- perth 5y ago
  Try to set two different DPIs in that.
  - AshamedCaptain 5y ago
    You certainly can, but the problem is that there is no agreed standard from the toolkits to do it. E.g. Qt has its own way.
    - hulitu 5y ago
      Why does QT needs to be smarter ? Just asking.
      - jcelerier 5y ago
        Qt runs on platforms where there is literally only a kernel + the Qt app running, through for instance EGL for rendering. So it has to have its own way.
  - Izkata 5y ago
    I don't have a second monitor right now to double check, but I have this in a script for our office monitors to get a different dpi for one display (named eDP-1): xrandr --dpi 100/eDP-1
- DonHopkins 5y ago
  https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47 https://donhopkins.medium.com/the-x-windows-disaster-128d398... >My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why would you ever need to point to something that you’ve drawn in 3D?” >Of course, HP claims X has a mode which allows you to run X in the overlay planes and “see through” to the graphics planes underneath. But of course, after 3 months of calls to HP technical support, we agreed that that doesn’t actually work with my particular hardware configuration. You see, I have the top-of-the-line Turbo SRX model (not one, but two on a single workstation!), and they’ve only tested it on the simpler, less advanced configurations. When you’ve got a hip, forward-thinking software innovator like Hewlett-Packard, they think running X windows release 2 is pretty advanced.
- kaba0 5y ago
  That’s for a single monitor. Now try two monitors with different DPIs
sprash 5y ago
The final "composing" step in Wayland does require Wayland to use a "giant" buffer as well. Also My GPU has 16 GB of GDDR how can any frame buffer be "giant" in that context? The support of hidpi scaling is something Toolkits have to manage (on both Wayland and X11). On X11 all the necessary pitch information to do so is available via the xrandr extension.
- md8z 5y ago
  You really don't want to use Xrandr information to do scaling, it's not accurate. A better way would be to set a property on the window and have the compositor read that, AFAIK this is the solution that the Kwin developers were working on.
loxias 5y ago
What's hidpi? I mean, pragmatically. I can guess that that acronym means "high dots per inch", but I don't follow. One of my desktops uses 2x 4k monitors, is that hidpi? X works fine... X also worked fine on an older setup with 4 monitors. Also, I don't know Wayland internals, but I'm gonna assert without proof that any low level graphics interface is gonna involve a framebuffer at some point...
- perth 5y ago
  Basically: You have a Microsoft Surfacebook, Chromebook Pixel, or Macbook with retina display, let's say at 300 DPI, and you try to plug it into a monitor that is 70 DPI. The buffer will not be possible to adjust to properly handle both monitors because 1 is 300 DPI and 1 is 70 DPI. This is because xorg is internally designed around the philosophy that every monitor will have the same DPI. There are tricks and hacks that teams, specifically I've seen the canonical team pull this off, where they can "trick" xorg into displaying properly with some minor visual artifacting. The last time I tested this was with Ubuntu a few years ago, back when Wayland support was "experimental" and I had this exact sort of setup, and Wayland was easily able to pull this off 100% better in every way because it is not designed around this limitation.
  - loxias 5y ago
    Ah, I think I get it. You want to use a "point" abstraction, not a "pixel" abstraction, right? In your example, I imagine everything would work just fine, but images will be physically bigger on the 70 DPI monitor because, well, the pixels are bigger. I'm guessing that Wayland adds a layer of indirection, resampling the framebuffer based on the DPI to preserve the same point size across displays with different pixel sizes. I ascribe to "the end user is always right" philosophy, so, if you want that functionality, you should be able to have it. But I wonder how popular that desire is. It's far from universal. Personally, I find resampled images to be so distracting and distasteful that it makes a computer hard to use for more than a few minutes. I hate fuzzy text, fuzzy windows, and fuzzy pixels. Any time I've been forced to use a device at something other than its native resolution, I've gotten preoccupied with "how can i fix this ugly crap" until I get native resolution working, and I'm sure I'm not alone. It's cool that Wayland does that for you, because you want it, but consider that to others, it might be a bug, and not a feature. :)

by perth 5y ago

jcelerier 5y ago

Setting DPI in .Xresources had worked fine for me since 2014 except for Firefox and Chrome which took a year or so to adapt

perth 5y ago
Try to set two different DPIs in that.
- AshamedCaptain 5y ago
  You certainly can, but the problem is that there is no agreed standard from the toolkits to do it. E.g. Qt has its own way.
  - hulitu 5y ago
    Why does QT needs to be smarter ? Just asking.
    - jcelerier 5y ago
      Qt runs on platforms where there is literally only a kernel + the Qt app running, through for instance EGL for rendering. So it has to have its own way.
- Izkata 5y ago
  I don't have a second monitor right now to double check, but I have this in a script for our office monitors to get a different dpi for one display (named eDP-1): xrandr --dpi 100/eDP-1
DonHopkins 5y ago
https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47 https://donhopkins.medium.com/the-x-windows-disaster-128d398... >My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why would you ever need to point to something that you’ve drawn in 3D?” >Of course, HP claims X has a mode which allows you to run X in the overlay planes and “see through” to the graphics planes underneath. But of course, after 3 months of calls to HP technical support, we agreed that that doesn’t actually work with my particular hardware configuration. You see, I have the top-of-the-line Turbo SRX model (not one, but two on a single workstation!), and they’ve only tested it on the simpler, less advanced configurations. When you’ve got a hip, forward-thinking software innovator like Hewlett-Packard, they think running X windows release 2 is pretty advanced.
kaba0 5y ago
That’s for a single monitor. Now try two monitors with different DPIs

sprash 5y ago

The final "composing" step in Wayland does require Wayland to use a "giant" buffer as well. Also My GPU has 16 GB of GDDR how can any frame buffer be "giant" in that context? The support of hidpi scaling is something Toolkits have to manage (on both Wayland and X11). On X11 all the necessary pitch information to do so is available via the xrandr extension.

md8z 5y ago
You really don't want to use Xrandr information to do scaling, it's not accurate. A better way would be to set a property on the window and have the compositor read that, AFAIK this is the solution that the Kwin developers were working on.

loxias 5y ago

What's hidpi? I mean, pragmatically. I can guess that that acronym means "high dots per inch", but I don't follow. One of my desktops uses 2x 4k monitors, is that hidpi? X works fine... X also worked fine on an older setup with 4 monitors. Also, I don't know Wayland internals, but I'm gonna assert without proof that any low level graphics interface is gonna involve a framebuffer at some point...

perth 5y ago
Basically: You have a Microsoft Surfacebook, Chromebook Pixel, or Macbook with retina display, let's say at 300 DPI, and you try to plug it into a monitor that is 70 DPI. The buffer will not be possible to adjust to properly handle both monitors because 1 is 300 DPI and 1 is 70 DPI. This is because xorg is internally designed around the philosophy that every monitor will have the same DPI. There are tricks and hacks that teams, specifically I've seen the canonical team pull this off, where they can "trick" xorg into displaying properly with some minor visual artifacting. The last time I tested this was with Ubuntu a few years ago, back when Wayland support was "experimental" and I had this exact sort of setup, and Wayland was easily able to pull this off 100% better in every way because it is not designed around this limitation.
- loxias 5y ago
  Ah, I think I get it. You want to use a "point" abstraction, not a "pixel" abstraction, right? In your example, I imagine everything would work just fine, but images will be physically bigger on the 70 DPI monitor because, well, the pixels are bigger. I'm guessing that Wayland adds a layer of indirection, resampling the framebuffer based on the DPI to preserve the same point size across displays with different pixel sizes. I ascribe to "the end user is always right" philosophy, so, if you want that functionality, you should be able to have it. But I wonder how popular that desire is. It's far from universal. Personally, I find resampled images to be so distracting and distasteful that it makes a computer hard to use for more than a few minutes. I hate fuzzy text, fuzzy windows, and fuzzy pixels. Any time I've been forced to use a device at something other than its native resolution, I've gotten preoccupied with "how can i fix this ugly crap" until I get native resolution working, and I'm sure I'm not alone. It's cool that Wayland does that for you, because you want it, but consider that to others, it might be a bug, and not a feature. :)