5 ms·

> Functioning Wayland support on anything outside of GNOME (common retort: we do not need Wayland.) Wayland is -trying to be- a means to an end, not an end by

> Functioning Wayland support on anything outside of GNOME (common retort: we do not need Wayland.) Wayland is -trying to be- a means to an end, not an end by itself. > Fractional scaling (common retort: Wayland does it, but see above) This is really a toolkit (and to some extent window manager) issue, not a window system issue. You can have fractional scaling in both Wayland and X11, as long as the underlying toolkit (or the framework above it) can do it. For example Lazarus / LCL applications support fractional scaling in X11 even with the Gtk2 backend (which itself doesn't support fractional scaling) by doing the scaling. Window manager support for some common messages/hints (ala EWMH) so that the window manager is responsible for telling applications how to scale would improve things (e.g. being able to have per-window, per-application, per-output scaling values, independent of each other and independent of the DPI - after all i may want to scale some windows at 300% on a "regular DPI" monitor because i am taking a screencast that i want to be readable on YouTube even at bitrates). > VR support Last time i checked the issue was mainly that the space is very dependent on proprietary technologies - at least for the headsets that people would want to use. Valve has done some low level work (or, paid external people to do low level work, anyway) but even them have their own solution which i think is bound to Steam instead of some standardized way that can be used by any application. > Lack of tearing across all 3 GPU vendors (common retort: see your comment, "I don't need it". Wayland does it, but Wayland bad) Lack of tearing where? Depending on where you mean it, this can be a feature instead of a problem (or at least any solution would introduce unacceptable problems). For example i prefer (i.e. it isn't a case of not caring, i actively prefer it) to have tearing on my desktop when moving/resizing windows, etc than have everything tied to the monitor's refresh rate because it makes the desktop feel much more responsive. Similarly for games where i use the mouse, i also prefer tearing to vsync because it reduces input lag (especially with some FP games that have their own issues, but the lag is there even with perfectly written games - this isn't just a workaround to the problem if badly written games, the badly written games are making it worse, but the problem is there even with good written games). On the other hand tearing during video playback is undesirable to me, of course (though with a high refresh rate monitor it isn't very noticeable - but i do not always use one). In all cases, tearing is controllable through the vblank_mode setting via the .drirc file in your home directory and the vblank_mode environment variable. My approach is simple: in the .drirc file i have the vblank_mode to 0 which forces all applications to ignore any requests for synchronizing with the refresh rate, but when playing a video (or want to run some game or application with vsync for some reason) i run it as vblank_mode=3 vlc filename (actually i use a script for that that is launched by my file manager so i don't really type it but the same idea). > * Variable Refresh Rate interface across all 3 GPU vendors (common retort: I just need this option in xorg.conf, if you're on NVIDIA it's your problem) Well, yes, it is your problem, whose problem would it be when it was your choice to buy from a vendor who has repeatedly shown disdain towards working with the community? My AMD GPU works perfectly fine with my VRR monitor under Xorg and i'm certain that the Intel iGPU on my laptop would also work fine if i connected the monitor to it - but both of these GPUs have open source drivers with support from their vendors. > But please be mindful that what works for you, doesn't work for anybody. There's a selfishness and clique mindset that is very hard to like among Linux users. [...] We're slowly getting to a better Linux desktop despite its users constantly bickering and pushing back any form of change that might improve their OS. It's a collective Stockholm Syndrome. You realize that with the latter part you are basically doing the exact same thing you describe with the first part, right? The people who you see "constantly bickering and pushing back any form of change" may actually see things that change in ways that do not work for them, thus making their experience of using their computers worse. This is why when making such "improvements" it is important to do it ways that doesn't invalidate existing practices - which also implies doing things in modular and replaceable ways instead of moving towards monolithic designs. (also i'm going to assume that in the first sentence you meant "doesn't work for everybody", not "anybody" since that wouldn't make logical sense unless you wanted to say "what works for you works only for you and nobody else")

Crysstalis 4y ago
>Window manager support for some common messages/hints (ala EWMH) so that the window manager is responsible for telling applications how to scale Adding this to X window managers would be a flawed and inferior experience, this method would only work correctly with composited X or with XWayland. >For example i prefer to have tearing on my desktop... In all cases, tearing is controllable through the vblank_mode setting via the .drirc file in your home directory >Well, yes, it is your problem This is also doing the same thing that the parent post is asking you not to do. It is not moving the discussion forward. The rest of your comment has very little in the way of meaningful suggestions that I can parse, you could have edited it down to maybe 4 or 5 sentences and gotten your point across.
- badsectoracula 4y ago
  > Adding this to X window managers would be a flawed and inferior experience, this method would only work correctly with composited X or with XWayland. You'll need to explain why and how it is "flawed and inferior", because the way i see it a Window Manager is responsible for managing windows and has an overview of all (toplevel) windows on the system (as a result of being responsible for them) and its placement and setup (e.g. in which monitor it is, what state -minimized, rolled up, maximized, etc- it is, etc). As such, like how it moves windows around, updates its state (minized, rolled, etc) it can also update the window's scale factor. The main difference here is that the window needs to know how to scale itself, but this isn't that different from knowing how to handle arbitrary sizes when getting resized. The idea isn't that weird (and honestly Windows does something similar so toolkits that work on Windows would need little change to support the same functionality on X): 1. Applications/toolkits that do not support the protocol will be scaled by the window manager, if possible (via, e.g, composition, note that a window can be composed without composing the full desktop - though there might be some corner cases here that need tweaks on the X server - a full desktop compositor will have no issues here however) 2. Applications/toolkits that do support the protocol but are running under a window manager that doesn't support it will do their scaling themselves by using the appropriate X APIs (RandR provides per-output DPI info that can be scaled, though a toolkit can also have user-wide settings for providing DPI-independent scaling settings per monitor) and geometry notifications 3. Applications/toolkits that do support the protocol and are running under a window manager that does support it (which can be known by a root window attribute and the application can also use a window attribute to specify that the window "speaks" the protocol) will receive scaling events from the window manager. The logic for these scaling values would be up to the window manager (e.g. per-output, per-monitor, per-application scaling but also could be some option in a context menu in the titlebar that provides scaling values and/or have some shortcut keys to scale up/down). For #3 there could also be a message for the window manager to request scaling for a window so that, e.g. something like xdotool could provide such requests via the command like. > It is not moving the discussion forward. The rest of your comment has very little in the way of meaningful suggestions that I can parse, you could have edited it down to maybe 4 or 5 sentences and gotten your point across. Then i suggest making better effort towards understanding what others write or at least ask clarifications (like i did at my first response in this comment) because making the assumption that it doesn't move a discussion forward.

Crysstalis 4y ago

>Window manager support for some common messages/hints (ala EWMH) so that the window manager is responsible for telling applications how to scale Adding this to X window managers would be a flawed and inferior experience, this method would only work correctly with composited X or with XWayland. >For example i prefer to have tearing on my desktop... In all cases, tearing is controllable through the vblank_mode setting via the .drirc file in your home directory >Well, yes, it is your problem This is also doing the same thing that the parent post is asking you not to do. It is not moving the discussion forward. The rest of your comment has very little in the way of meaningful suggestions that I can parse, you could have edited it down to maybe 4 or 5 sentences and gotten your point across.

badsectoracula 4y ago
> Adding this to X window managers would be a flawed and inferior experience, this method would only work correctly with composited X or with XWayland. You'll need to explain why and how it is "flawed and inferior", because the way i see it a Window Manager is responsible for managing windows and has an overview of all (toplevel) windows on the system (as a result of being responsible for them) and its placement and setup (e.g. in which monitor it is, what state -minimized, rolled up, maximized, etc- it is, etc). As such, like how it moves windows around, updates its state (minized, rolled, etc) it can also update the window's scale factor. The main difference here is that the window needs to know how to scale itself, but this isn't that different from knowing how to handle arbitrary sizes when getting resized. The idea isn't that weird (and honestly Windows does something similar so toolkits that work on Windows would need little change to support the same functionality on X): 1. Applications/toolkits that do not support the protocol will be scaled by the window manager, if possible (via, e.g, composition, note that a window can be composed without composing the full desktop - though there might be some corner cases here that need tweaks on the X server - a full desktop compositor will have no issues here however) 2. Applications/toolkits that do support the protocol but are running under a window manager that doesn't support it will do their scaling themselves by using the appropriate X APIs (RandR provides per-output DPI info that can be scaled, though a toolkit can also have user-wide settings for providing DPI-independent scaling settings per monitor) and geometry notifications 3. Applications/toolkits that do support the protocol and are running under a window manager that does support it (which can be known by a root window attribute and the application can also use a window attribute to specify that the window "speaks" the protocol) will receive scaling events from the window manager. The logic for these scaling values would be up to the window manager (e.g. per-output, per-monitor, per-application scaling but also could be some option in a context menu in the titlebar that provides scaling values and/or have some shortcut keys to scale up/down). For #3 there could also be a message for the window manager to request scaling for a window so that, e.g. something like xdotool could provide such requests via the command like. > It is not moving the discussion forward. The rest of your comment has very little in the way of meaningful suggestions that I can parse, you could have edited it down to maybe 4 or 5 sentences and gotten your point across. Then i suggest making better effort towards understanding what others write or at least ask clarifications (like i did at my first response in this comment) because making the assumption that it doesn't move a discussion forward.