4 ms·

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 composito

by 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.
- zxzax 5y ago
  I mean in terms of developer interest, I haven't seen anybody working towards getting those patches (or similar things) merged. It would be easiest to get this working in a rootless server (like XWayland) first and then go backwards from there. In the case of compositing on multiple monitors, scaling isn't independent of DPI settings. They are the same problem, because at some point you will get an app that is mismatched and you'll have to scale it along with its input coordinates. The physical measurements could be used to inaccurately guess defaults, some Wayland servers might do that, but it's not preferred. The X server doesn't "misreport" DPI in the sense that it's purposefully sending a wrong value, there's a process that it does (I may not be remembering this exactly) where it tries to read from the EDID, which could be wrong values. If the values are there but wrong those will just get quietly passed through, if those are zero then it then tries to fill in measurements based on a default DPI. Random X clients with access to RandR can also change the measurements stored in the server for whatever reason -- basically there is no possible way for this value to always be correct if you just want a number that tells you what DPI to target. You're right this could be fixed, just like every bug could technically be fixed if given enough attention, but somebody needs to take the time to backport the Wayland method to X, which I don't have high hopes for it happening any time soon. The main thing you're missing in the server, as I said, is scaling of input coordinates. The compositor or the toolkit can't do this, it has to happen in the server, because those events are sent directly from the server to the client. It's probably a better approach to get that working, and then put a prop on the root window, and then hack kwin/mutter/whatever to use that, but I don't think anyone has tried to implement it that way yet.

by zxzax 5y ago

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.

zxzax 5y ago
I mean in terms of developer interest, I haven't seen anybody working towards getting those patches (or similar things) merged. It would be easiest to get this working in a rootless server (like XWayland) first and then go backwards from there. In the case of compositing on multiple monitors, scaling isn't independent of DPI settings. They are the same problem, because at some point you will get an app that is mismatched and you'll have to scale it along with its input coordinates. The physical measurements could be used to inaccurately guess defaults, some Wayland servers might do that, but it's not preferred. The X server doesn't "misreport" DPI in the sense that it's purposefully sending a wrong value, there's a process that it does (I may not be remembering this exactly) where it tries to read from the EDID, which could be wrong values. If the values are there but wrong those will just get quietly passed through, if those are zero then it then tries to fill in measurements based on a default DPI. Random X clients with access to RandR can also change the measurements stored in the server for whatever reason -- basically there is no possible way for this value to always be correct if you just want a number that tells you what DPI to target. You're right this could be fixed, just like every bug could technically be fixed if given enough attention, but somebody needs to take the time to backport the Wayland method to X, which I don't have high hopes for it happening any time soon. The main thing you're missing in the server, as I said, is scaling of input coordinates. The compositor or the toolkit can't do this, it has to happen in the server, because those events are sent directly from the server to the client. It's probably a better approach to get that working, and then put a prop on the root window, and then hack kwin/mutter/whatever to use that, but I don't think anyone has tried to implement it that way yet.