5 ms·

> Still, it does not seem a really fundamental problem, it must surely be solvable from within X? X gives you two options: set DPI per displays. The thing is,

> Still, it does not seem a really fundamental problem, it must surely be solvable from within X? X gives you two options: set DPI per displays. The thing is, you cannot drag windows between displays, the app has destroy it, connect to another one and recreate it here. There's even no mechanism to detect multiple displays other that user setting up the DISPLAY env variable. Or you can do, as the Xorg does: use multiple screens on a single display. Here, the limitation is, that all screens have to have same DPI. Neither of those are acceptable for modern display server. > it will break screen capture tools, It is a good thing that they are broken, because what they do is snooping on windows that do not belong to them. Just like it is unacceptable to integrate user address book to your app by going through its internal files, it is unacceptable to screen grab by snooping windows of other apps. In both scenarios, your app must go through API, which puts the user in the control, whether the app is allowed to do that. Wayland enforces such protocol for screen grabbing and input handling; those app who do not bother... well, the train will leave the station without them. > other things that are dear to us like xwit, xdotool and the like Same as previous, but for input handling. > Just for that silly mixed-resolution screen problem? No, there are multiple problems. For another, surely you would like screen lock that doesn't flash your desktop on unlock? > I have observed this problem, but to me is a minor, mostly irrelevant nuisance. Losing xwit would be a major problem. See even here on HN, it is important for many. Just few days ago there was a discussion under article about i3 and how to drag it into hidpi world in 2021. On the other hand, the mainstream user doesn't even know why they would use xwit, even if they knew it exists.

enriquto 6y ago
> It is a good thing that they are broken, because what they do is snooping on windows that do not belong to them. Don't want to derail this discussion anymore, but this argument is nuts. If you are so concerned that programs that you run can spy on other programs that you run, how do you deal that the fact that all of these running programs have full read-write access to all files on your $HOME? EDIT: I agree that being able to run selected programs inside a sandbox would be a good thing (maybe even all programs). But attacking the problem of visible display before that of hidden files seems ridiculous. Moreso if it cripples copy paste, screen capture, and similar basic stuff (which to me are just like unix pipes: ways to make programs work together!)
- vetinari 6y ago
  > t all of these running programs have full read-write access to all files on your $HOME? They don't necesarilly do; if you are running flatpak, chances are that they don't. For example, there is a flatpak for MS Teams. For application like this, you want it to be able to share your screen, but it doesn't have any access to your $HOME (in this specific case, only to ~/Downloads). More importantly, if you want to tight up your desktop, why do you criticize something that starts attacking it from one angle, that it is not 100% solution? It is not; others are working on the other angles, and then together it will be the 100% solution. In this case, Wayland is only one piece of puzzle, not the entire puzzle.
AshamedCaptain 6y ago
> [Xorg] limitation is, that all screens have to have same DPI. The limitation is not true. Yes, the core protocol gives you a single, global DPI value. However, who cares about the core protocol? You have XRandR, which gives you a per-screen DPI. Alternative, you could have a freedesktop standard/convention where the DPI is stored as a global property of the root window, in a array of values, one for each display, so that you can override them. Problem solved! I am actually running Gtk+ slightly patched to support that... trouble is, most of the toolkit is hardcoded to assume a fixed display or even process-wide global DPI, or at least it was when I last looked at it. Dunno what they did for wayland. I really don't understand why we need to throw away an entire 30 years of software development just because the current property for storing the DPI only has space for 1 value instead of 1 array of values, one per monitor. Just use a new property.
- vetinari 6y ago
  > Problem solved! Not so fast! Are you going to patch it to decade old binaries? How are you going to handle that Wordperfect from 1998? It certainly won't respect you new protocol. How the compositors are supposed to handle that? If you are not going to handle it, and just let it behave as it behaves today, you are still not achieving your goal of scaling all clients properly, and kind of throwing away that 30 years of development by making it unusable anyway.
  - AshamedCaptain 6y ago
    How are you going to change those decade old binaries to work with Wayland??? At least if you don't throw X11, those decade old binaries still work. If you throw X11, they will not! You need to put in some type of kludge which is the reason this article exists in the first place (e.g. copy paste will work randomly). And if the toolkit is linked dynamically, you are very lucky... Not to mention that a more realistic scenario is that you have to update a 20 year old toolkit to support multiple DPIs, in which case it is much easier if you just have to read the property from a different place rather than having to target a different display protocol entirely. You made the program vendors life easier at the cost of making yours harder...
cycomanic 6y ago
I've never used xwit before, but just looking at the description, I believe at least under sway the same should be achievable using sway's ipc protocol (I wouldn't be surprised if other compositors have similar options). I think the difference to xwit is that it does not work across windowmanagers/compositors, because much of what X11 used to do is now the job of the compositor, but I assume the users who script xwit likely also have a very tuned windowmanager, so it's unlike they switch window managers all the time and they could therefore just tune their environment for the same functionality as xwit.

enriquto 6y ago

> It is a good thing that they are broken, because what they do is snooping on windows that do not belong to them. Don't want to derail this discussion anymore, but this argument is nuts. If you are so concerned that programs that you run can spy on other programs that you run, how do you deal that the fact that all of these running programs have full read-write access to all files on your $HOME? EDIT: I agree that being able to run selected programs inside a sandbox would be a good thing (maybe even all programs). But attacking the problem of visible display before that of hidden files seems ridiculous. Moreso if it cripples copy paste, screen capture, and similar basic stuff (which to me are just like unix pipes: ways to make programs work together!)

vetinari 6y ago
> t all of these running programs have full read-write access to all files on your $HOME? They don't necesarilly do; if you are running flatpak, chances are that they don't. For example, there is a flatpak for MS Teams. For application like this, you want it to be able to share your screen, but it doesn't have any access to your $HOME (in this specific case, only to ~/Downloads). More importantly, if you want to tight up your desktop, why do you criticize something that starts attacking it from one angle, that it is not 100% solution? It is not; others are working on the other angles, and then together it will be the 100% solution. In this case, Wayland is only one piece of puzzle, not the entire puzzle.

AshamedCaptain 6y ago

> [Xorg] limitation is, that all screens have to have same DPI. The limitation is not true. Yes, the core protocol gives you a single, global DPI value. However, who cares about the core protocol? You have XRandR, which gives you a per-screen DPI. Alternative, you could have a freedesktop standard/convention where the DPI is stored as a global property of the root window, in a array of values, one for each display, so that you can override them. Problem solved! I am actually running Gtk+ slightly patched to support that... trouble is, most of the toolkit is hardcoded to assume a fixed display or even process-wide global DPI, or at least it was when I last looked at it. Dunno what they did for wayland. I really don't understand why we need to throw away an entire 30 years of software development just because the current property for storing the DPI only has space for 1 value instead of 1 array of values, one per monitor. Just use a new property.

vetinari 6y ago
> Problem solved! Not so fast! Are you going to patch it to decade old binaries? How are you going to handle that Wordperfect from 1998? It certainly won't respect you new protocol. How the compositors are supposed to handle that? If you are not going to handle it, and just let it behave as it behaves today, you are still not achieving your goal of scaling all clients properly, and kind of throwing away that 30 years of development by making it unusable anyway.
- AshamedCaptain 6y ago
  How are you going to change those decade old binaries to work with Wayland??? At least if you don't throw X11, those decade old binaries still work. If you throw X11, they will not! You need to put in some type of kludge which is the reason this article exists in the first place (e.g. copy paste will work randomly). And if the toolkit is linked dynamically, you are very lucky... Not to mention that a more realistic scenario is that you have to update a 20 year old toolkit to support multiple DPIs, in which case it is much easier if you just have to read the property from a different place rather than having to target a different display protocol entirely. You made the program vendors life easier at the cost of making yours harder...

cycomanic 6y ago

I've never used xwit before, but just looking at the description, I believe at least under sway the same should be achievable using sway's ipc protocol (I wouldn't be surprised if other compositors have similar options). I think the difference to xwit is that it does not work across windowmanagers/compositors, because much of what X11 used to do is now the job of the compositor, but I assume the users who script xwit likely also have a very tuned windowmanager, so it's unlike they switch window managers all the time and they could therefore just tune their environment for the same functionality as xwit.