4 ms·

> This actually works seamlessly on X wherein one can scale down lower DPI displays down from a higher resolution so everything is drawn the same size. Where d

> This actually works seamlessly on X wherein one can scale down lower DPI displays down from a higher resolution so everything is drawn the same size. Where does it work seamlessly? Yes, Chrome can do that. Gimp and myriad of other X11 apps can't. I will repeat the point from the previous comment: from the point of compositor there is no way to tell, whether the X11 client does support dpi properly or not. And since it cannot tell (short of guessing), it assumes they don't. In theory, you could invent a new protocol for X11 apps announcing their capabilities. But good luck with adoption, you may switch to an entirely incompatible protocol as well. > To be charitable one would suppose that its just a low priority as fewer people have high dpi displays Strictly speaking, it is not a problem with hidpi. It is problem with fractional scaling. With hidpi on and fractional scaling off (not set to 200%, entirely turned off), you get all the 1:1 pixel glory. If some app doesn't adjust to dpi, you will see that immediately (basically everything except gtk3+, qt5+ and current firefox/chrome/electron). I actually prefer the blurry one, it makes the apps at least usable. > If one was less charitable making X apps work slightly shittier serves as motivation for developers to support the new standard. IMO it is actually too nice anyway. Should have gone XDarwin all the way -- i.e. to run X11, you have to manually launch separate application, and that server does not support hidpi at all. > If you listen to these people talk the less charitable interpretation sounds entirely plausible. AFAIK there were multiple approaches tried. Even theone, where whitelisted (i.e. the ones that passed manual test) applications would be allowed to run hidpi and the rest upscaled. It went nowhere. But as they say, patches welcome.

michaelmrose 4y ago
Apps in general either directly support high DPI or if dumb can be set to an integer scaling factor via environment. 99% of people are going to need exactly one variable for gtk apps that wouldn't be needed if gtk was just a tad smarter. Smaller changes can be handled with scale and mixed dpi by scaling down from higher res. Note the end result is again not blurry. You spend 30 seconds setting it up then every works including mixed dpi. In fact one could trivialize this at installation and write configuration to xorg.conf or xorg.conf.d One in general doesn't need to worry after setup if a particular app will work, if it will be wayland native or xwayland, if it will look different on different DPI displays, if it will be blurry, if all functionality will work. All high and mixed DPI concerns are front loaded into a tiny amount of time setting it up in a way that will just work well without compromise. A tiny amount of effort by your distro could easily erase even that by simply doing it for you. >IMO it is actually too nice anyway. Should have gone XDarwin all the way -- i.e. to run X11, you have to manually launch separate application, and that server does not support hidpi at all. This is an example of user hostility that goes a long way towards destroying adoption. Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you. Then you can call them all luddites for caring more about working hardware than plumbing.
- vetinari 4y ago
  > Apps in general either directly support high DPI or if dumb can be set to an integer scaling factor via environment. I will again repeat myself there: and how does the display server know, if the app won't tell? > 99% of people are going to need exactly one variable for gtk apps that wouldn't be needed if gtk was just a tad smarter. Variables do not work in dynamic environment, where hotplug is a thing. Like personal computing in last 25 years or so. > You spend 30 seconds setting it up then every works including mixed dpi. In fact one could trivialize this at installation and write configuration to xorg.conf or xorg.conf.d So you are telling here, that: - there should be a database of apps; ignoring that the display server won't be able to recognize them solely on socket connection and it won't have another info available (no, Xresources is not a solution) - that database would be local system-specific - and it would be static, so if the user hot-plugs some hardware, it won't reflect the current system state anymore - and it would be static at runtime. If you want a change for a running app, you have to restart the app. Do you see some problems with that? The problem with this kind of thinking is putting hacks on top of another hacks and then wondering when the mountain goes down. > This is an example of user hostility that goes a long way towards destroying adoption. Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you. How exactly did XDarwin destroy adoption of Quartz? If anything, it drove adoption. Instead of trying to hide the shortcomings, it exposed them and offered another solution, without them. > Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you. Only those who prefer long pain; those who prefer short pain would do exactly the same. > Then you can call them all luddites for caring more about working hardware than plumbing. The entire point is that it does not work. Remember that when someone will complain that the monitor they plugged into their laptop doesn't do the right thing, unlike their Windows or Mac.
  - michaelmrose 4y ago
    This is the totality of my present configuration In my shell config set -gx GDK_SCALE 2 Run once xrandr --dpi 163 --output DP-0 --scale 1.75x1.75 --output HDMI-0 --pos 3360x0 --mode 3840x2160 --output DVI-D-0 --pos 7200x0 --scale 1.75x1.75 Then saved to xconfig. This isn't automated because I really don't care because like many devices it only actually has one configuration but it would be trivial to do so by computing the exact scale based on difference in DPI. The one thing that can't be determined automatically is the physical layout. There are 17 different GUIs that amount to dragging around iconic representations of your screens. Autoscaling mixed dpi configurations could be a check box checked by default and writing to xconfig could be a button like it is in nvidia-settings. Other people prefer to simply switch between different named configurations with one of the 17 scripts that have been written to do this. The gist of why this arrangement needs to app specific configuration for proper behavior per screen is that as far as apps are concerned every monitor has the exact same DPI. Scaling is done by X not the app so if you were to say drag a window from monitor to monitor you would note that the window and its elements remains exactly the same size between monitor not because the app is smart but because X is. This is true enough that you can drag a window halfway between and notice no discontinuity between a line of text across both monitors. Note that this functionality isn't new nor does it require massive coordination or anything new at all. It has probably worked longer than you've used Linux.

michaelmrose 4y ago

Apps in general either directly support high DPI or if dumb can be set to an integer scaling factor via environment. 99% of people are going to need exactly one variable for gtk apps that wouldn't be needed if gtk was just a tad smarter. Smaller changes can be handled with scale and mixed dpi by scaling down from higher res. Note the end result is again not blurry. You spend 30 seconds setting it up then every works including mixed dpi. In fact one could trivialize this at installation and write configuration to xorg.conf or xorg.conf.d One in general doesn't need to worry after setup if a particular app will work, if it will be wayland native or xwayland, if it will look different on different DPI displays, if it will be blurry, if all functionality will work. All high and mixed DPI concerns are front loaded into a tiny amount of time setting it up in a way that will just work well without compromise. A tiny amount of effort by your distro could easily erase even that by simply doing it for you. >IMO it is actually too nice anyway. Should have gone XDarwin all the way -- i.e. to run X11, you have to manually launch separate application, and that server does not support hidpi at all. This is an example of user hostility that goes a long way towards destroying adoption. Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you. Then you can call them all luddites for caring more about working hardware than plumbing.

vetinari 4y ago
> Apps in general either directly support high DPI or if dumb can be set to an integer scaling factor via environment. I will again repeat myself there: and how does the display server know, if the app won't tell? > 99% of people are going to need exactly one variable for gtk apps that wouldn't be needed if gtk was just a tad smarter. Variables do not work in dynamic environment, where hotplug is a thing. Like personal computing in last 25 years or so. > You spend 30 seconds setting it up then every works including mixed dpi. In fact one could trivialize this at installation and write configuration to xorg.conf or xorg.conf.d So you are telling here, that: - there should be a database of apps; ignoring that the display server won't be able to recognize them solely on socket connection and it won't have another info available (no, Xresources is not a solution) - that database would be local system-specific - and it would be static, so if the user hot-plugs some hardware, it won't reflect the current system state anymore - and it would be static at runtime. If you want a change for a running app, you have to restart the app. Do you see some problems with that? The problem with this kind of thinking is putting hacks on top of another hacks and then wondering when the mountain goes down. > This is an example of user hostility that goes a long way towards destroying adoption. Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you. How exactly did XDarwin destroy adoption of Quartz? If anything, it drove adoption. Instead of trying to hide the shortcomings, it exposed them and offered another solution, without them. > Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you. Only those who prefer long pain; those who prefer short pain would do exactly the same. > Then you can call them all luddites for caring more about working hardware than plumbing. The entire point is that it does not work. Remember that when someone will complain that the monitor they plugged into their laptop doesn't do the right thing, unlike their Windows or Mac.
- michaelmrose 4y ago
  This is the totality of my present configuration In my shell config set -gx GDK_SCALE 2 Run once xrandr --dpi 163 --output DP-0 --scale 1.75x1.75 --output HDMI-0 --pos 3360x0 --mode 3840x2160 --output DVI-D-0 --pos 7200x0 --scale 1.75x1.75 Then saved to xconfig. This isn't automated because I really don't care because like many devices it only actually has one configuration but it would be trivial to do so by computing the exact scale based on difference in DPI. The one thing that can't be determined automatically is the physical layout. There are 17 different GUIs that amount to dragging around iconic representations of your screens. Autoscaling mixed dpi configurations could be a check box checked by default and writing to xconfig could be a button like it is in nvidia-settings. Other people prefer to simply switch between different named configurations with one of the 17 scripts that have been written to do this. The gist of why this arrangement needs to app specific configuration for proper behavior per screen is that as far as apps are concerned every monitor has the exact same DPI. Scaling is done by X not the app so if you were to say drag a window from monitor to monitor you would note that the window and its elements remains exactly the same size between monitor not because the app is smart but because X is. This is true enough that you can drag a window halfway between and notice no discontinuity between a line of text across both monitors. Note that this functionality isn't new nor does it require massive coordination or anything new at all. It has probably worked longer than you've used Linux.