6 ms·

> Note that the problem isn't really with X11 (or at least Xorg) since it does provide the necessary information via RandR to perform per-monitor scaling. It

> Note that the problem isn't really with X11 (or at least Xorg) since it does provide the necessary information via RandR to perform per-monitor scaling. It is issue with X11. If you have Wordperfect binary from 1999, it still has to work; it does not matter that RandR provides information, old clients will not ask for it and without it, they will be broken. That's why Xwayland does upscaling by itself. > mean hidpi displays themselves are very rare - if you check any desktop resolution stats they often barely are a blip - and having both a hidpi display and a regular dpi one is even less common than that Cause and effect. They are rare, because using them sucks, making them even rarer. On systems, where they do not suck, they are not that rare. This attitude makes entire platform worse off.

badsectoracula 5y ago
> It is issue with X11. If you have Wordperfect binary from 1999, it still has to work; it does not matter that RandR provides information, old clients will not ask for it and without it, they will be broken. This is why i wrote "so that compositing window managers can do it themselves for applications that do not support it, which is also why this needs to go through the window manager". You do not need X11 support for that, functionality that exist can be used right now to do it - assuming the applications and WMs cooperate to specify the necessary attributes and events, of course. > That's why Xwayland does upscaling by itself. You can also do this with a compositor for applications that do not support scaling themselves (which would be the default state - again this isn't any different than the 'supports close event' flag that already exists for decades now). Without a compositor you're out of luck (for the most part)... ...However! Keith Packard worked on server-side scaling some time ago [0] (not sure if it was merged with mainline) which would allow this to be done even without a compositor (well, kinda, technically the server does the compositing just for the scaled windows). So even without a regular desktop compositor this should still be implementable, assuming that functionality was (or will be) merged in mainline Xorg. But note that this is only for the case where one wants to run applications that do not support scaling and have hidpi scaling and also not using a compositor. The rest can already be implemented with Xorg as-is. [0] https://keithp.com/blogs/window-scaling/ https://keithp.com/blogs/window-scaling/
- zxzax 5y ago
  Those patches were never merged, and I doubt they will be, because there seems to be almost no interest in supporting high DPI displays on X without a compositor. If there was interest in those, at the very least somebody would have to adapt them and figure out how to use them with XWayland. In my opinion, any patch that doesn't fix this for Xwayland/Xwin/Xquartz is probably not going to fly. If you want this, you actually do need some level of protocol support for this, and I want to address a common misconception: >X11 provides the necessary information via RandR to perform per-monitor scaling This is not true. If it were true, it would be significantly easier to get DPI scaling to work on X11 and XWayland already. If you're referring to the physical size measurements, there are numerous problems with those, and they should never be used to do DPI scaling. If you're developing for Wayland, you should just ignore those measurements and use the scale provided by the server. If you mean that applications can draw themselves at arbitrary scales, they could always do that, without even bothering with RandR, but that will break down when you try to handle the compositing cases, e.g. stretching a window across monitors and expecting the display/input coordinates to scale correctly. So regardless of what you're trying to get the apps to do, some more work needs to be done there. Even if those problems were fixed, DPI scaling would still not work without more changes in the server. The major reason why it can't even work is because of input coordinate scaling -- the server needs to be able to scale coordinates based on a factor provided by the client, and RandR does not provide this, and it doesn't make sense to add it to RandR either. If you want to standardize how this is done, the best way would just be to copy the method used by Wayland back into the X server. Part of it might be merging those patches by Keith that you linked, part of it might be somebody finishing this MR: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/432 https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
  - badsectoracula 5y ago
    > Those patches were never merged, and I doubt they will be, because there seems to be almost no interest in supporting high DPI displays on X without a compositor. I don't know about that, though the only person i personally know with a HiDPI display uses X without a compositor (they just use a theme with everything being big). > If there was interest in those, at the very least somebody would have to adapt them These are only part of the puzzle, they are not really that useful by themselves without the rest of what i wrote, which would actually be the more involved problem. Having scaling without a compositor is more of a "cherry on top" than anything else. > This is not true. If it were true, it would be significantly easier to get DPI scaling to work on X11 and XWayland already. I think mixing DPI and scaling is the root of the problem here. Scaling is something independent from DPI settings, though DPI settings can be used for setting up the defaults. However scaling is useful regardless of DPI. > If you're referring to the physical size measurements, there are numerous problems with those, and they should never be used to do DPI scaling. Why not? They can be used to calculate defaults. I've heard that by default the official X server misreports DPI, but many distributions apply patches to fix that - not sure why the X server does this but it is something to be fixed. Personally i never had issues with how the X server reported my monitors' DPI and i've used a bunch of different monitors over the decades. Regardless this is something that can be fixed anyway - after all if Wayland can get the proper information, so can X11. > If you mean that applications can draw themselves at arbitrary scales, they could always do that, without even bothering with RandR, but that will break down when you try to handle the compositing cases, e.g. stretching a window across monitors and expecting the display/input coordinates to scale correctly. So regardless of what you're trying to get the apps to do, some more work needs to be done there. The idea is for RandR to be used by the window manager as an initial/default scaling setup for windows per monitor. The users should be able to alter that of course and even alter per-window (i mean toplevel window here) scaling (via their window manager). > Even if those problems were fixed, DPI scaling would still not work without more changes in the server. The major reason why it can't even work is because of input coordinate scaling -- the server needs to be able to scale coordinates based on a factor provided by the client, and RandR does not provide this, and it doesn't make sense to add it to RandR either. IIRC this was actually fixed some time ago to allow scaling via compositors. Outside compositors we're back to Keith's patches. But this is also an issue for applications that do not support scaling. Basically what i mean is this, to summarize it: * Applications can either support or not scaling. If they do support scaling they set some attribute to their toplevel windows to indicate that. * The Window Manager sends events to toplevel windows that support scaling to setup their scaling whenever the scaling changes (the window is dragged to another monitor, the user requests a different scale level via an icon menu or shortcut or whatever). If a window doesn't support scaling (note that an application can have windows that both support and not support scaling, not that it matters much but it is a good idea to avoid associating application support with window support) it gets scaled by either the window manager (if it is a compositor), a dedicated compositor (some compositors can work with other window managers) or the server (with Keith's patches). There could also be support for toolkits to do the scaling themselves if the window manager doesn't support scaling (e.g. window managers that support scaling can use an attribute in the root window to indicate that support), but that is more complex and may not be really necessary. Note that only the case where an X application doesn't support scaling and a compositor is not running is where the current server functionality isn't adequate. Everything else should already be there, but it needs support from toolkits (to support the relevant events and of course scaling their contents) and window managers (to implement scaling events). Perhaps RandR's DPI info isn't reliable (though that hasn't been my experience) but that can be fixed, the harder bits are getting toolkits and window managers to support that stuff.

badsectoracula 5y ago

> It is issue with X11. If you have Wordperfect binary from 1999, it still has to work; it does not matter that RandR provides information, old clients will not ask for it and without it, they will be broken. This is why i wrote "so that compositing window managers can do it themselves for applications that do not support it, which is also why this needs to go through the window manager". You do not need X11 support for that, functionality that exist can be used right now to do it - assuming the applications and WMs cooperate to specify the necessary attributes and events, of course. > That's why Xwayland does upscaling by itself. You can also do this with a compositor for applications that do not support scaling themselves (which would be the default state - again this isn't any different than the 'supports close event' flag that already exists for decades now). Without a compositor you're out of luck (for the most part)... ...However! Keith Packard worked on server-side scaling some time ago [0] (not sure if it was merged with mainline) which would allow this to be done even without a compositor (well, kinda, technically the server does the compositing just for the scaled windows). So even without a regular desktop compositor this should still be implementable, assuming that functionality was (or will be) merged in mainline Xorg. But note that this is only for the case where one wants to run applications that do not support scaling and have hidpi scaling and also not using a compositor. The rest can already be implemented with Xorg as-is. [0] https://keithp.com/blogs/window-scaling/ https://keithp.com/blogs/window-scaling/

zxzax 5y ago
Those patches were never merged, and I doubt they will be, because there seems to be almost no interest in supporting high DPI displays on X without a compositor. If there was interest in those, at the very least somebody would have to adapt them and figure out how to use them with XWayland. In my opinion, any patch that doesn't fix this for Xwayland/Xwin/Xquartz is probably not going to fly. If you want this, you actually do need some level of protocol support for this, and I want to address a common misconception: >X11 provides the necessary information via RandR to perform per-monitor scaling This is not true. If it were true, it would be significantly easier to get DPI scaling to work on X11 and XWayland already. If you're referring to the physical size measurements, there are numerous problems with those, and they should never be used to do DPI scaling. If you're developing for Wayland, you should just ignore those measurements and use the scale provided by the server. If you mean that applications can draw themselves at arbitrary scales, they could always do that, without even bothering with RandR, but that will break down when you try to handle the compositing cases, e.g. stretching a window across monitors and expecting the display/input coordinates to scale correctly. So regardless of what you're trying to get the apps to do, some more work needs to be done there. Even if those problems were fixed, DPI scaling would still not work without more changes in the server. The major reason why it can't even work is because of input coordinate scaling -- the server needs to be able to scale coordinates based on a factor provided by the client, and RandR does not provide this, and it doesn't make sense to add it to RandR either. If you want to standardize how this is done, the best way would just be to copy the method used by Wayland back into the X server. Part of it might be merging those patches by Keith that you linked, part of it might be somebody finishing this MR: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/432 https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
- badsectoracula 5y ago
  > Those patches were never merged, and I doubt they will be, because there seems to be almost no interest in supporting high DPI displays on X without a compositor. I don't know about that, though the only person i personally know with a HiDPI display uses X without a compositor (they just use a theme with everything being big). > If there was interest in those, at the very least somebody would have to adapt them These are only part of the puzzle, they are not really that useful by themselves without the rest of what i wrote, which would actually be the more involved problem. Having scaling without a compositor is more of a "cherry on top" than anything else. > This is not true. If it were true, it would be significantly easier to get DPI scaling to work on X11 and XWayland already. I think mixing DPI and scaling is the root of the problem here. Scaling is something independent from DPI settings, though DPI settings can be used for setting up the defaults. However scaling is useful regardless of DPI. > If you're referring to the physical size measurements, there are numerous problems with those, and they should never be used to do DPI scaling. Why not? They can be used to calculate defaults. I've heard that by default the official X server misreports DPI, but many distributions apply patches to fix that - not sure why the X server does this but it is something to be fixed. Personally i never had issues with how the X server reported my monitors' DPI and i've used a bunch of different monitors over the decades. Regardless this is something that can be fixed anyway - after all if Wayland can get the proper information, so can X11. > If you mean that applications can draw themselves at arbitrary scales, they could always do that, without even bothering with RandR, but that will break down when you try to handle the compositing cases, e.g. stretching a window across monitors and expecting the display/input coordinates to scale correctly. So regardless of what you're trying to get the apps to do, some more work needs to be done there. The idea is for RandR to be used by the window manager as an initial/default scaling setup for windows per monitor. The users should be able to alter that of course and even alter per-window (i mean toplevel window here) scaling (via their window manager). > Even if those problems were fixed, DPI scaling would still not work without more changes in the server. The major reason why it can't even work is because of input coordinate scaling -- the server needs to be able to scale coordinates based on a factor provided by the client, and RandR does not provide this, and it doesn't make sense to add it to RandR either. IIRC this was actually fixed some time ago to allow scaling via compositors. Outside compositors we're back to Keith's patches. But this is also an issue for applications that do not support scaling. Basically what i mean is this, to summarize it: * Applications can either support or not scaling. If they do support scaling they set some attribute to their toplevel windows to indicate that. * The Window Manager sends events to toplevel windows that support scaling to setup their scaling whenever the scaling changes (the window is dragged to another monitor, the user requests a different scale level via an icon menu or shortcut or whatever). If a window doesn't support scaling (note that an application can have windows that both support and not support scaling, not that it matters much but it is a good idea to avoid associating application support with window support) it gets scaled by either the window manager (if it is a compositor), a dedicated compositor (some compositors can work with other window managers) or the server (with Keith's patches). There could also be support for toolkits to do the scaling themselves if the window manager doesn't support scaling (e.g. window managers that support scaling can use an attribute in the root window to indicate that support), but that is more complex and may not be really necessary. Note that only the case where an X application doesn't support scaling and a compositor is not running is where the current server functionality isn't adequate. Everything else should already be there, but it needs support from toolkits (to support the relevant events and of course scaling their contents) and window managers (to implement scaling events). Perhaps RandR's DPI info isn't reliable (though that hasn't been my experience) but that can be fixed, the harder bits are getting toolkits and window managers to support that stuff.