4 ms·

> 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 ho

> 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.
- vetinari 4y ago
  Great. So you managed the easy part - to scale your screen. The elephant in the room that you still ignore after several comments in this thread is, that the display manager cannot know magic variables for misc clients, it can barely tell clients apart (and it certainly doesn't know their image names, linked libraries or environment or how they were launched), and it shouldn't know, the clients should tell what resolution they are using so the display manager can adjusts their display. Wayland clients do that, X11 don't. No, you can't paper over it with some scripts. Suggestions like that always remind me this: https://www.youtube.com/watch?v=ZTdUmlGxVo0 https://www.youtube.com/watch?v=ZTdUmlGxVo0
  - michaelmrose 4y ago
    Imagine you are sitting on a train in London with your friend on your way to work and you are having a conversation with your mom back in New York. Meanwhile your friend is loudly insisting that everyone knows that cellular connections can't cross oceans because cell towers just don't have that much range. He's sort of correct but he's missed the point. Let me try again. Here is an xrandr invocation that configures 3 screens [1080P 24"][4K 27"][1080p 24"] xrandr --dpi 163 --output HDMI-0 --mode 1920x1080 --scale 1.75x1.75 --pos 0x0 --output DP-4 --auto --pos 3360x0 --output DP-1 --mode 1680x1050 --scale 1.75x1.75 --pos 7200x0 One could simply run it at boot or better one can save the present configuration to xorg.conf. The nvidia-settings app both lets you do this with a GUI or can look what xrandr has set up and save THAT to your xorg.conf If one simply runs xrandr after one sees a curious thing. The 1080 monitors are listed as being 3360x1890. If we pop out our calculator we will note that the systems sees every screen as being about 161 DPI. Prove it to yourself if you like. https://www.sven.de/dpi/ https://www.sven.de/dpi/ This means that the most poorly written application on earth only has to contend with high dpi support not mixed DPI. X asks nothing of the client it needs no magic variables nor insight into its linked libraries or images. If you grasp the window metaphorically and move it from screen to screen its size won't perceptively flutter because the screen differential in DPI is as far as its concerned within 1%. If you open a fullscreen app it will draw its window to the whole perceptible 3360 width of the screen and X will scale it down to the actual width of 1920. X has taken sole responsibility for giving a fuck what the difference in DPI is. High DPI support at this point is very good and no scripts to "paper" over anything is required. xrandr --scale is a thing that would have worked in 2003 and still works in 2022 even if people have forgotten about it.

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.

vetinari 4y ago
Great. So you managed the easy part - to scale your screen. The elephant in the room that you still ignore after several comments in this thread is, that the display manager cannot know magic variables for misc clients, it can barely tell clients apart (and it certainly doesn't know their image names, linked libraries or environment or how they were launched), and it shouldn't know, the clients should tell what resolution they are using so the display manager can adjusts their display. Wayland clients do that, X11 don't. No, you can't paper over it with some scripts. Suggestions like that always remind me this: https://www.youtube.com/watch?v=ZTdUmlGxVo0 https://www.youtube.com/watch?v=ZTdUmlGxVo0
- michaelmrose 4y ago
  Imagine you are sitting on a train in London with your friend on your way to work and you are having a conversation with your mom back in New York. Meanwhile your friend is loudly insisting that everyone knows that cellular connections can't cross oceans because cell towers just don't have that much range. He's sort of correct but he's missed the point. Let me try again. Here is an xrandr invocation that configures 3 screens [1080P 24"][4K 27"][1080p 24"] xrandr --dpi 163 --output HDMI-0 --mode 1920x1080 --scale 1.75x1.75 --pos 0x0 --output DP-4 --auto --pos 3360x0 --output DP-1 --mode 1680x1050 --scale 1.75x1.75 --pos 7200x0 One could simply run it at boot or better one can save the present configuration to xorg.conf. The nvidia-settings app both lets you do this with a GUI or can look what xrandr has set up and save THAT to your xorg.conf If one simply runs xrandr after one sees a curious thing. The 1080 monitors are listed as being 3360x1890. If we pop out our calculator we will note that the systems sees every screen as being about 161 DPI. Prove it to yourself if you like. https://www.sven.de/dpi/ https://www.sven.de/dpi/ This means that the most poorly written application on earth only has to contend with high dpi support not mixed DPI. X asks nothing of the client it needs no magic variables nor insight into its linked libraries or images. If you grasp the window metaphorically and move it from screen to screen its size won't perceptively flutter because the screen differential in DPI is as far as its concerned within 1%. If you open a fullscreen app it will draw its window to the whole perceptible 3360 width of the screen and X will scale it down to the actual width of 1920. X has taken sole responsibility for giving a fuck what the difference in DPI is. High DPI support at this point is very good and no scripts to "paper" over anything is required. xrandr --scale is a thing that would have worked in 2003 and still works in 2022 even if people have forgotten about it.