12 ms·

Ancient X11 scaling technology

284 points by todsacerdoti 1y ago

cpach 1y ago
Love this post. Reminds me of my former coworker G. He had exactly this attitude, and it made it possible for him to deliver results on most tasks that he set out for.
- sho_hn 1y ago
  It's actually a somewhat bad and uninformed post, or perhaps the mistake (unclear whether knowingly or not) is to disprove a claim made by uninformed people. No one with a good grasp of the space ever claimed that it wasn't possible on X11 to call into APIs to retrieve physical display size and map that to how many pixels to render. This has been possible for decades, and while not completely trivial is not the hard part about doing good UI scaling. Doing good UI scaling requires infrastructure for dynamic scaling changes, for different scale factors per display within the same scene, for guaranteeing crisp hairlines at any scale factor, and so on and so forth. Many of these problems could have been solved in X11 with additional effort, and some even made it to partial solutions available. The community simply chose to put its energy into bringing it all together in the Wayland stack instead.
  - kvemkon 1y ago
    > to disprove a claim made by uninformed people KDE developer wrote recently: > X11 isn’t able to perform up to the standards of what people expect today with respect to .., 10 bits-per-color monitors,.. multi-monitor setups (especially with mixed DPIs or refresh rates),... [1] Multi-monitor setups are working since 20+ years. 10 bits are also supported (otherwise how would the PRO versions of graphic cards support this feature). > chose to put its energy into bringing it all together in I cannot recall, was there any paper analyzing why working and almost working X11 features do not fit, few additional X11 extensions cannot be proposed anymore and another solution from scratch is inevitable. What is a significant difference of a X11 and a wayland protocol extension. [1] https://pointieststick.com/2025/06/21/about-plasmas-x11-session/ https://pointieststick.com/2025/06/21/about-plasmas-x11-sess...
    - sho_hn 1y ago
      Nate (the author of the blog post you linked), who I know personally very well, is a QA/product person focused on integration and fit and finish issues. What he means to say is that as a polished product, this is now available in the form of a Wayland-based desktop session without fiddling, while the same cannot be said of X11-based ones. It's meant as a pragmatic take, not as a history lesson. That's quite similar to how I chose to phrase is, and comes down to where the community chose to spend the effort to solve all the integration issues to make it so. Did the community decide that after a long soul-seeking process that ended with a conclusion that things were impossible to make happen in X11, and does that paper you invoke exist? No, not really. Conversations like this certainly did take place, but I would say more in informal settings, e.g. discussions on lists and at places like the X.org conference. Plenty of "Does it make sense to that in X11 still or do we start over?" chatter in both back in the day. If I recall right, the most serious effort was a couple of people taking a few weeks to entertain a "Could we fix this in an X12 and how much would that break?" scenario. Digging up the old fdo wiki pages on that one would for sure be interesting for the history books. The most close analogue I can think of that most in the HN audience are familiar with is probably the Python 2->3 transition and decision to clean thing up at the expense of backward compat. To this day, you will of course find folks arguing emotionally on either side of the Python argument as well. For the most part, the story of how this happened is a bit simpler: It used to be that the most used X11 display server was a huge monolith that did many things the kernel would not, all the way to crazy things like managing PCI bus access in user space. This slowly changed over the years, with strengthening kernel infra like DRM, the appearance of Kernel Mode Setting, with the evolution of libraries like Mesa. Suddenly implementing a display server became a much simpler affair that mostly could call into a bunch of stuff elsewhere. This created an opening for a new smaller project fully focused on the wire protocol and protocol semantics part, throwing away a lot of old baggage and code. Someone took the time to do that and demonstrate how it looks like, other people liked what they saw and Wayland was born. This also means: Plenty of the useful code of the X11 era actually still exists. One of the biggest myths is that Wayland somehow started over from scratch. A lot of the aforementioned stuff that over the years migrated from the X11 server to e.g. the kernel is obviously still what makes things work now, and libraries such as libinput, xkbcommon that nearly every Wayland display server implementation uses are likewise factored out of the X11 stack.
wosined 1y ago
Very nice.
pedrocr 1y ago
That's probably better than most scaling done on Wayland today because it's doing the rendering directly at the target resolution instead of doing the "draw at 2x scale and then scale down" dance that was popularized by OSX and copied by Linux. If you do it that way you both lose performance and get blurry output. The only corner case a compositor needs to cover is when a client is straddling two outputs. And even in that case you can render at the higher size and get perfect output in one output and the same downside in blurryness in the other, so it's still strictly better. It's strange that Wayland didn't do it this way from the start given its philosophy of delegating most things to the clients. All you really need to do arbitrary scaling is tell apps "you're rendering to a MxN pixel buffer and as a hint the scaling factor of the output you'll be composited to is X.Y". After that the client can handle events in real coordinates and scale in the best way possible for its particular context. For a browser, PDF viewer or image processing app that can render at arbitrary resolutions not being able to do that is very frustrating if you want good quality and performance. Hopefully we'll be finally getting that in Wayland now.
- wmf 1y ago
  None of the toolkits (Motif, Tk, Gtk, Qt, etc.) could handle fractional scaling so if Wayland had taken the easy way out it would break every app.
  - lostmsu 1y ago
    Why is Wayland trying to monkey patch something that's broken elsewhere?
    - wmf 1y ago
      Do you want to be right or do you want to display apps.
      - lostmsu 1y ago
        How many apps will you display if you don't display them right? Are you ready to tell me poor graphics is not one of the reasons people not use Linux? You won't display apps to the users you lost. Instead Windows will.
DonHopkins 1y ago
[flagged]
- arp242 1y ago
  This does not address anything from the article and is a (seemingly copy/pasted) generic tangent about X11.
  - DonHopkins 1y ago
    If you'd read both the article and my post, you'd realize it does actually address the article. It's a quote from the chapter about X-Windows I wrote in the Unix Haters handbook in 1994. https://en.wikipedia.org/wiki/The_UNIX-HATERS_Handbook https://en.wikipedia.org/wiki/The_UNIX-HATERS_Handbook https://web.archive.org/web/20201120053257/http://www.simson.net/ref/ugh.pdf https://web.archive.org/web/20201120053257/http://www.simson... And a description of the screen spanning ruler app (or rather "Desk Accessory") that the Mac had around 1987 or so (I specifically remember Hugh showing it to me a few months before Black Monday). https://en.wikipedia.org/wiki/Desk_accessory https://en.wikipedia.org/wiki/Desk_accessory https://en.wikipedia.org/wiki/Black_Monday_(1987) https://en.wikipedia.org/wiki/Black_Monday_(1987) Just like the article you apparently didn't read mentioned: >With my new knowledge, I also wrote an onscreen ruler using the shape extension. Somewhat tautological for measuring the two inch circle, but in the event anyone asks, I can now tell them my terminal line height is 1/8”, and yes, I measured. https://humungus.tedunangst.com/r/xtoys/v/tip/f/ruler.c https://humungus.tedunangst.com/r/xtoys/v/tip/f/ruler.c Now 38 years later, is there a ruler app for X-Windows that can span multiple screens yet? Or Wayland, even? Why don't you write one!
    - arp242 1y ago
      [flagged]
      - DonHopkins 1y ago
        [flagged]
wmf 1y ago
Drawing a circle is kind of cheating. The hard part of scaling is drawing UI elements like raster icons or 1px hairlines to look non-blurry.
- phkahler 1y ago
  >> The hard part of scaling is drawing UI elements like raster icons or 1px hairlines to look non-blurry. And doing so actually using X not OpenGL.
  - kllrnohj 1y ago
    Yeah this is kinda the big elephant in the room here? They didn't prove what they set out to prove. Yes obviously OpenGL does scaling just fine, the entire point of Wayland is to get the compositor to just being a compositor. They didn't do any scaling with X. They didn't do anything at all with X other than ask it some basic display information.
    - slackfan 1y ago
      X shouldn't be displaying anything that isn't a right angle anyway. All circular UI elements are haram.
  - kelnos 1y ago
    Toolkits don't use X to do much (if any) drawing these days. They all use something like cairo or skia or -- yes -- OpenGL to render offscreen, and then upload to X for display (or in the case of OpenGL, they can also do direct rendering).
    - sprash 1y ago
      If you use Cairo on X11 rendering automatically happens with the XRender extension. This is a rather efficient wire protocol that supports sub-pixel coordinates, transparency, gradients and more. No off-screen rendering required. (Some of the older gtk2 theme engines worked that way and allowed beautiful UIs with fast remote capabilities.)
creatonez 1y ago
> Perhaps not the most exciting task, but I figure it’s isomorphic to any other scaling challenge And doing this for everything in the entire ecosystem of ancient GUI libraries? And dealing with the litany of different ways folks have done icons, text, and even just drawing lines onto the screen? That's where you run into a lot of trouble.
- q3k 1y ago
  Right, it's much easier to also re-engineer all of X11 into Wayland at the same time :).
  - kllrnohj 1y ago
    The whole point of Wayland is to not include all of X11. There's a lot of X11 that's just obsolete cruft, like the entire drawing model
lelandbatey 1y ago
I admire your tenacity. I think folks say "X11 doesn't support DPI scaling" when they should say "most programs written against X11 to use official Xlib functionality don't understand scaling". In the article, the author uses OpenGL to make sure that they're interacting with the screen at a "lower level" than plenty of apps that were written against X. But that's the rub, I think the author neatly sidestepped by mostly using stuff that's not in "vanilla" X11. In fact, the "standard" API of X via Xlib seems to only expose functions for working in raw pixels and raw pixel coordinates without any kind of scaling awareness. See XDrawLine as an example: https://www.x.org/releases/current/doc/man/man3/XDrawLine.3.xhtml https://www.x.org/releases/current/doc/man/man3/XDrawLine.3.... It seems to me that the RandR extension through xrandr is the thing providing the scaling info, not X11 itself. You can see that because the author calls `XRRGetScreenResourcesCurrent()` a function that's not a part of vanilla X11 (see list of X library functions here as example: https://www.x.org/releases/current/doc/man/man3/ https://www.x.org/releases/current/doc/man/man3/ ) Now, xrandr has been a thing since the early 2000s hence why xrandr is ubiquitous, but due to it's nature as an extension and plenty of existing code sitting around that's totally scale-unaware, I can see why folks believe X11 is scale unaware.
- arp242 1y ago
  So on my laptop I've been doing: xrandr --output eDP --scale 0.8x0.8 For years and years, and I never really noticed any problems with it. Guess I don't run any "bad" scale-unaware programs? Or maybe I just never noticed(?) At least from my perspective, for all practical purposes it seems to "just work".
  - nixosbestos 1y ago
    Good luck if you plug in an external monitor. (Not to speak of refresh rates)
    - rwmj 1y ago
      At the office I plug in a monitor over USB-C and that just works on my X11 laptop. If something in a browser on the monitor was too large or too small I'd just zoom in/out until it was fine.
kunzhi 1y ago
Interesting article, I'll admit when I first saw the title I was thinking of a different kind of "scaling" - namely the client/server decoupling in X11. I still think X11 forwarding over SSH is a super cool and unsung/undersung feature. I know there are plenty of good reasons we don't really "do it these days" but I have had some good experiences where running the UI of a server app locally was useful. (Okay, it was more fun than useful, but it was useful.)
- xioxox 1y ago
  It's certainly very useful. I do half my work using X11 over ssh and it works reasonably well over a LAN (at least using emacs, plotting, etc).
  - DonHopkins 1y ago
    I worked on the NeWS drivers for Emacs (both "Evil Software Hoarder" Gosling UniPress Emacs 2.20 and later "Free" Gnu Emacs 18), which were extremely efficient and smoothly interactive over low baud rate modems (which we called "thin wire" as opposed to i.e. the "thick wire" coaxial 10BASE5 Ethernet of the time), because instead of using the extraordinarily inefficient, chatty, pong-pongy X-Windows protocol, Emacs could simply download PostScript code to the window server that defined a highly optimized application specific client/server protocol and intelligent front-end (now termed "AJAX"), which performed as much real time interaction in the window system as possible, without any network activity, like popping up and tracking pie menus, and providing real time feedback and autoscroll when selecting and highlighting text. For example, both versions of Emacs would download the lengths of each line on the screen when you started a selection, so you could drag and select the text and animation the selection overlay without any network traffic at all, without sending mouse move events over the network, only sending messages when you autoscrolled or released the button. http://www.bitsavers.org/pdf/sun/NeWS/800-5543-10_The_NeWS_Toolkit_Reference_Manual_Mar1991.pdf http://www.bitsavers.org/pdf/sun/NeWS/800-5543-10_The_NeWS_T... document page 2, pdf page 36: >Thin wire >TNT programs perform well over low bandwidth client-server connections such as telephone lines or overloaded networks because the OPEN LOOK components live in the window server and interact with the user without involving the client program at all. >Application programmers can take advantage of the programmable server in this way as well. For example, you can download user-interaction code that animates some operation. UniPress Emacs NeWS Driver: https://github.com/SimHacker/NeMACS/blob/b5e34228045d544fcb719a412c7ba51cc281f4a3/src/D.term/TrmPS.cps https://github.com/SimHacker/NeMACS/blob/b5e34228045d544fcb7... Selection support with local feedback: https://github.com/SimHacker/NeMACS/blob/b5e34228045d544fcb719a412c7ba51cc281f4a3/src/D.term/TrmPS.cps#L3013 https://github.com/SimHacker/NeMACS/blob/b5e34228045d544fcb7... Gnu Emacs 18 NeWS Driver (search for LocalSelectionStart): https://donhopkins.com/home/code/emacs18/src/tnt.ps https://donhopkins.com/home/code/emacs18/src/tnt.ps https://news.ycombinator.com/item?id=26113192 https://news.ycombinator.com/item?id=26113192 DonHopkins on Feb 12, 2021 | parent | context | favorite | on: Interview with Bill Joy (1984) >Bill was probably referring to what RMS calls "Evil Software Hoarder Emacs" aka "UniPress Emacs", which was the commercially supported version of James Gosling's Unix Emacs (aka Gosling Emacs / Gosmacs / UniPress Emacs / Unimacs) sold by UniPress Software, and it actually cost a thousand or so for a source license (but I don't remember how much a binary license was). Sun had the source installed on their file servers while Gosling was working there, which was probably how Bill Joy had access to it, although it was likely just a free courtesy license, so Gosling didn't have to pay to license his own code back from UniPress to use at Sun. https://en.wikipedia.org/wiki/Gosling_Emacs https://en.wikipedia.org/wiki/Gosling_Emacs >I worked at UniPress on the Emacs display driver for the NeWS window system (the PostScript based window system that James Gosling also wrote), with Mike "Emacs Hacker Boss" Gallaher, who was charge of Emacs development at UniPress. One day during the 80's Mike and I were wandering around an East coast science fiction convention, and ran into RMS, who's a regular fixture at such events. >Mike said: "Hello, Richard. I heard a rumor that your house burned down. That's terrible! Is it true?" >RMS replied right back: "Yes, it did. But where you work, you probably heard about it in advance." >Everybody laughed. It was a joke! Nobody's feelings were hurt. He's a funny guy, quick on his feet! In the late 80's, if you had a fast LAN and not a lot of memory and disk (like a 4 meg "dickless" Sun 3/50), it actually was more efficient to run X11 Emacs and even the X11 window manager itself over the LAN on another workstation than on your own, because then you didn't suffer from frequent context switches and paging every keystroke and mouse movement and click. The X11 server and Emacs and WM didn't need to context switch to simply send messages over the network and paint the screen if you ran emacs and the WM remotely, so Emacs and the WM weren't constantly fighting with the X11 server for memory and CPU. Context switches were really expensive on a 68k workstation, and the way X11 is designed, especially with its outboard window manager, context switching from ping-ponging messages back and forth and back and forth and back and forth and back and forth between X11 and the WM and X11 and Emacs every keystroke or mouse movement or click or window event KILLED performance and caused huge amounts of virtual memory thrashing and costly context switching. Of course NeWS eliminated all that nonsense gatling gun network ping-ponging and context switching, which was the whole point of its design. That's the same reason using client-side Google Maps via AJAX of 20 years ago was so much better than the server-side Xerox PARC Map Viewer via http of 32 years ago. https://en.wikipedia.org/wiki/Xerox_PARC_Map_Viewer https://en.wikipedia.org/wiki/Xerox_PARC_Map_Viewer Outboard X11 ICCCM window managers are the worst possible most inefficient way you could ever possibly design a window manager, and that's not even touching on their extreme complexity and interoperability problems. It's the one program you NEED to be running in the same context as the window system to synchronously and seamlessly handle events without dropping them on the floor and deadlocking (google "X11 server grab" if you don't get what this means), but instead X11 brutally slices the server and window manager apart like King Solomon following through with his child-sharing strategy. https://tronche.com/gui/x/xlib/window-and-session-manager/XGrabServer.html https://tronche.com/gui/x/xlib/window-and-session-manager/XG... While NeWS not only runs the window manager efficiently in the server without any context switching or network overhead, but it also lets you easily plug in your own customized window frames (with tabs and pie menus), implement fancy features like rooms and virtual scrolling desktops, and all kinds of cool stuff! At Sun were even managing X11 windows with a NeWS ICCCM window manager written in PostScript, wrapping tabbed windows with pie menus around your X-Windows! https://donhopkins.com/home/archive/NeWS/owm.ps.txt https://donhopkins.com/home/archive/NeWS/owm.ps.txt https://donhopkins.com/home/archive/NeWS/win/xwm.ps https://donhopkins.com/home/archive/NeWS/win/xwm.ps https://www.donhopkins.com/home/catalog/unix-haters/x-windows/i39l.html https://www.donhopkins.com/home/catalog/unix-haters/x-window...
kragen 1y ago
I think it was yesterday that people's on HN were saying GLX doesn't work over the network?
- rwmj 1y ago
  $ ssh <remote> glxgears runs fine!
  - Ballas 1y ago
    Wow, when did that happen? A couple of years ago I could not get anything OpenGL working over ssh, no matter how hard I tried. Ever since I just accepted that as fact. But I tested it now and it just works!
    - krackers 1y ago
      hasn't this always been the case? I thought one of the whole reasons for the weird design of OpenGL API was that it was a client-server sort of thing to allow for network transparency
      - simoncion 1y ago
        My understanding matches your own. I was doing this circa 2005 with an OpenGL program running on a Linux box in a server closet and a Windows machine running on my desk running some X11 server. Before I did that, I did research into the remote-draw capability of both X11 and OpenGL and came to the conclusion that what I eventually ended up doing would work just fine.
- jeffbee 1y ago
  Are there people who believe this? What do they think Indirect GLX is? XQuartz as the server and some Linux box as the client has always worked perfectly for me, GLX included.
rwmj 1y ago
It's like the "oh no, X11 suffers from tearing video" problem that they pull out all the time. (A) I have no idea what "video tear" is and (B) I play video all the time on my crappy laptop running X11 and it seems fine for me. But can I ssh to my remote server and run emacs or another program completely transparently yet with Wayland? Nope. I do that with X11 continuously.
- toast0 1y ago
  I've seen video tearing on X. Usually it doesn't happen, often it's hard to notice anyway; and when it did happen and was annoying, I just was missing some setting or other. No big deal.
- ndiddy 1y ago
  > But can I ssh to my remote server and run emacs or another program completely transparently yet with Wayland? Nope. Yes, you can! Waypipe came out 6 years ago. Its express purpose is to make a Wayland equivalent to ssh -X. https://gitlab.freedesktop.org/mstoeckl/waypipe/ https://gitlab.freedesktop.org/mstoeckl/waypipe/
  - aragilar 1y ago
    Except: 1. It's Wayland-to-Wayland (which means you're much more limited to where it can run than X-to-X, where's the MacOS or Windows or BSD Wayland build?). 2. It's not integrated with ssh (X forwarding is part of the protocol). 3. You need it on both the client and the server, so you need to work out how to get it onto the server.
- nullc 1y ago
  If someone shows it to you, you'll recognize it. It's when one frame shows part of the prior frame and part of the next. It's most visible in moderate speed horizontal pans as an interruption in vertical lines in the picture. It's nice to not have tearing. But IMO the functionality loss vs X11 isn't worth it for anything but a dedicated media playback/editing device.
  - 1y ago
jekwoooooe 1y ago
It’s astounding to me that in Linux, in 2025, I can’t just simply output a custom resolution. You are probably typing a response right now with some xrandr nonsense and I PROMISE you, it won’t do it. I can’t even scale my screen within a normal resolution to make it fit within a boundary. But I can do this in windows with an nvidis gpu. Crazy
- throw39304949 1y ago
  [flagged]
  - jekwoooooe 1y ago
    Nope I can output 4k just fine. That’s not the issue. The issue is I want a 2.35:1 aspect resolution. I can do this on windows and nvidia but not on Linux (steam deck, intel nuc, etc)
  - komali2 1y ago
    > As for xrandr nonsense, get AMD card! CUDA, and ray tracing performance. I get it, I've heard the same from the sway maintainer, maintaining their crusade against Nvidia for a couple years now (the --unsupported-gpu flag used to be something like --my-next-gpu-will-be-amd), with some good arguments about how anti-foss Nvidia is. And if that's how sway wants to be then that's how sway's gonna be. But with steamdeck and now steam os showing better performance than windows on handheld gaming devices, and with people getting more and more annoyed with Microsoft's bullshit in windows (like unwanted AI integrations), I think all of us Linux enthusiasts have a really good opportunity here to pull a huge influx of people in, if we're willing to budge just a bit on some of our dogmatic crusades against companies like Nvidia. There's more Nvidia cards in the wild than AMD, according to steam surveys by a huge margin. If we can get Wayland display managers working well on Nvidia thenthat's a lot of new people we can bring into the fold!
- deleted 1y ago
  [deleted]
- lmm 1y ago
  > You are probably typing a response right now with some xrandr nonsense and I PROMISE you, it won’t do it. Skill issue. You probably held your keyboard wrong or something. Simple xrandr commands work fine like they have for decades. (Of course if you've moved to Wayland then who knows).
compiler-devel 1y ago
Brilliant. This is another piece of evidence on the pile of why we got Wayland: it's because people who understood X11 mostly retired and everyone else couldn't be bothered to learn X11 because it's "yucky C code" or something. And it bothers me that we lose remote rendering with Wayland (unless one fights with waypipe) that was just built-in to X11. Yes, it was slow, but actually if you're running a VM on your local system and using SSH to connect to it, then it works great. Sigh. I'm an old person yelling at clouds.
- sho_hn 1y ago
  This is nonsensical myth-making. Despite the clickbait title, the APIs called in those code samples are very basic and not some forgotten wizardry.
  - compiler-devel 1y ago
    What part is nonsensical? Because Wayland is basically a fulfillment of jwz's CADT.
    - sho_hn 1y ago
      The part where we got Wayland because we lost a magic caste of rockstar engineers who could call XRRGetOutputInfo/XRRGetCrtcInfo.
- nullc 1y ago
  > Yes, it was slow, Not particularly if you are on a low latency network. Modern UI toolkits make applications way less responsive that classical X11 applications running across gigabit ethernet. And even on a fast network the wayland alternative of 'use RDP' is almost unusable.
  - kllrnohj 1y ago
    the approach used in this blog post requires rdp. It's not drawing using X, so there's no vector network transparency.
jchw 1y ago
Sigh. And now that it's been long enough, everyone will conveniently forget all of the reasons why this wound up being insufficient, and think that all of the desktop environment and toolkit developers are simply stupid. (Importantly, applications actually did do this by default at one point. I remember a wonky-looking nvidia-xsettings because of this.) The thing X11 really is missing (at least most importantly) is DPI virtualization. UI scaling isn't a feature most display servers implement because most display servers don't implement the actual UI bits. The lack of DPI virtualization is a problem though, because it leaves windows on their own to figure out how to logically scale input and output coordinates. Worse, they have to do it per monitor, and can't do anything about the fact that part of the window will look wrong if it overlaps two displays with different scaling. If anything doesn't do this or does it slightly differently, it will look wrong, and the user has little recourse beyond searching for environment variables or X properties that might make it work. Explaining all of that is harder than saying that X11 has poor display scaling support. Saying it "doesn't support UI/display scaling" is kind of a misnomer though; that's not exactly the problem.
- zozbot234 1y ago
  > can't do anything about the fact that part of the window will look wrong if it overlaps two displays with different scaling It's silly that people keep complaining about this. It's a very minor effect, and one that can be solved in principle only by moving to pure vector rendering for everything. Generally speaking, a window will only ever span a single screen. It's convenient to be able to drag a window to a separate monitor, but having that kind of overlap as a permanent feature of one's workflow is just crazy. > The thing X11 really is missing (at least most importantly) is DPI virtualization. Shouldn't that kind of DPI virtualization be a concern for toolkits rather than the X server or protocol? As long as X is getting accurate DPI information from the hardware and reporting that to clients, what else is needed?
  - jchw 1y ago
    > It's silly that people keep complaining about this. It's a very minor effect, and one that can be solved in principle only by moving to pure vector rendering for everything. If you have DPI virtualization, a very sufficient solution already exists: pick a reasonable scale factor for the underlying buffer and use it, then resample for any outputs that don't match. This is what happens in most Wayland compositors. Exactly what you pick isn't too important. You could pick whichever output overlaps the most with the window, or the output that has the highest scale factor, or some other criteria. It will not result in perfect pixels everywhere, but it is perfectly sufficient to clean up the visual artifacts. Another solution would be to simply only present the surface on whatever output it primarily overlaps with. MacOS does this and it's seemingly sufficient. Unfortunately, as far as I understand, this isn't really trivial to do in X11 for the same reasons why DPI virtualization isn't trivial: whether you render it or not, the window is still in that region and will still receive input there. > Generally speaking, a window will only ever span a single screen. It's convenient to be able to drag a window to a separate monitor, but having that kind of overlap as a permanent feature of one's workflow is just crazy. The issue with the overlap isn't that people routinely need this; if they did, macOS or Windows would also need a more complete solution. In reality though, it's just a very janky visual glitch that isn't really too consequential for your actual workflow. Still, it really can make moving windows across outputs super janky, especially since in practice different applications do sometimes choose different behaviors. (e.g. will your toolkit choose to resize the window so it has the same logical size? will this impact the window dragging operation?) So really, the main benefit of solving this particular edge case is just to make the UX of window management better. While UX and visual jank concerns are below concerns about functionality, I still think they have non-zero (and sometimes non-low) importance. Laptop users expect to be able to dock and manage windows effectively regardless of whether the monitors they are using have the same ideal scale factor as the laptop's internal panel; the behavior should be clean and effective and legacy apps should ideally at least appear correct even if blurry. Being able to do DPI virtualization solves the whole set of problems very cleanly. MacOS is doing this right, Windows is finally doing this right, Wayland is doing this right, X11 still can't yet. (It's not physically impossible, but it would require quite a lot of work since it would require modifying everything that handles coordinate spaces I believe.) > Shouldn't that kind of DPI virtualization be a concern for toolkits rather than the X server or protocol? As long as X is getting accurate DPI information from the hardware and reporting that to clients, what else is needed? Accurate DPI information is insufficient as users may want to scale differently anyways, either due to preference, higher viewing distance, or disability. So that already isn't enough. That said, the other issue is that there already exists applications that don't do perfect per monitor scaling, and there doesn't exist a single standard way to have the per-monitor scaling preferences propagated in X11. It's not even necessarily a solved problem among the latest versions of all of the toolkits, since it at minimum requires support for desktop environment settings daemons and etc.
GranPC 1y ago
Can this handle the case in which you have two displays with different DPIs side-by-side, and a window is placed in the middle of them both?
amiga386 1y ago
It's not "can you provide the screen DPI to a window?" people bemoan, it's "can you draw one window across two screens with differing DPIs, transparent to the application?"
- kelnos 1y ago
  You can absolutely do that on X11, but you have to do it in the client, and no one cares to do it.
  - em-bee 1y ago
    if you have to do it in the client, aka the application, then it's not transparent to the application
    - p_l 1y ago
      It's not transparent on Wayland or Windows (no idea about mac) either if you want actually properly drawn stuff. Well, ok, on Windows if you keep to certain standard elements of Windows API and only use standard widgets you could get close to transparency.
    - rbanffy 1y ago
      It'll not be transparent to an application using basic X APIs, but nothing prevents a higher level UI toolkit from implementing it properly.
    - yjftsjthsd-h 1y ago
      If we can require applications to draw their own window controls, I think we can ask them to handle their pixel densities.
      - em-bee 1y ago
        that's a good point. window controls should be at the proper scale too.
  - 1y ago
erlkonig 1y ago
This whole issue just seems so pathetic. PostScript and DPS, notably NeWS, have device-independent scaling from the outset - you can completely omit even mentioning pixels, even though they're 2D. Wayland braying on about scalability here just highlights how they don't even understand the game. Going to OpenGL is a nice tactic, since OpenGL doesn't give a flip about screen coördinates anyway. I miss NeWS - it actually brought a number of great capabilities to a window system - none of which, AFAIK, are offered by Wayland.
NooneAtAll3 1y ago
I hope XLibre will keep making X11 better
sumuyuda 1y ago
Related to the LG TV size, isn’t the size the length of the diagonal? The author seemed to think it was the width of the screen.
- timeinput 1y ago
  In his terminal output with screen dimensions it lists a monitor 1600mm wide which is about 63 inches wide.
buster 1y ago
Regarding this thread: I find it kind of funny how a group of adults can obsess over pixel perfect placement of terminal characters (or whatever) on screens that have so tiny pixels, no other human being would even see a difference without some kind of magnification and obsessive pixel peeping.

284 points by todsacerdoti 1y ago

Love this post. Reminds me of my former coworker G. He had exactly this attitude, and it made it possible for him to deliver results on most tasks that he set out for.

sho_hn 1y ago
It's actually a somewhat bad and uninformed post, or perhaps the mistake (unclear whether knowingly or not) is to disprove a claim made by uninformed people. No one with a good grasp of the space ever claimed that it wasn't possible on X11 to call into APIs to retrieve physical display size and map that to how many pixels to render. This has been possible for decades, and while not completely trivial is not the hard part about doing good UI scaling. Doing good UI scaling requires infrastructure for dynamic scaling changes, for different scale factors per display within the same scene, for guaranteeing crisp hairlines at any scale factor, and so on and so forth. Many of these problems could have been solved in X11 with additional effort, and some even made it to partial solutions available. The community simply chose to put its energy into bringing it all together in the Wayland stack instead.
- kvemkon 1y ago
  > to disprove a claim made by uninformed people KDE developer wrote recently: > X11 isn’t able to perform up to the standards of what people expect today with respect to .., 10 bits-per-color monitors,.. multi-monitor setups (especially with mixed DPIs or refresh rates),... [1] Multi-monitor setups are working since 20+ years. 10 bits are also supported (otherwise how would the PRO versions of graphic cards support this feature). > chose to put its energy into bringing it all together in I cannot recall, was there any paper analyzing why working and almost working X11 features do not fit, few additional X11 extensions cannot be proposed anymore and another solution from scratch is inevitable. What is a significant difference of a X11 and a wayland protocol extension. [1] https://pointieststick.com/2025/06/21/about-plasmas-x11-session/ https://pointieststick.com/2025/06/21/about-plasmas-x11-sess...
  - sho_hn 1y ago
    Nate (the author of the blog post you linked), who I know personally very well, is a QA/product person focused on integration and fit and finish issues. What he means to say is that as a polished product, this is now available in the form of a Wayland-based desktop session without fiddling, while the same cannot be said of X11-based ones. It's meant as a pragmatic take, not as a history lesson. That's quite similar to how I chose to phrase is, and comes down to where the community chose to spend the effort to solve all the integration issues to make it so. Did the community decide that after a long soul-seeking process that ended with a conclusion that things were impossible to make happen in X11, and does that paper you invoke exist? No, not really. Conversations like this certainly did take place, but I would say more in informal settings, e.g. discussions on lists and at places like the X.org conference. Plenty of "Does it make sense to that in X11 still or do we start over?" chatter in both back in the day. If I recall right, the most serious effort was a couple of people taking a few weeks to entertain a "Could we fix this in an X12 and how much would that break?" scenario. Digging up the old fdo wiki pages on that one would for sure be interesting for the history books. The most close analogue I can think of that most in the HN audience are familiar with is probably the Python 2->3 transition and decision to clean thing up at the expense of backward compat. To this day, you will of course find folks arguing emotionally on either side of the Python argument as well. For the most part, the story of how this happened is a bit simpler: It used to be that the most used X11 display server was a huge monolith that did many things the kernel would not, all the way to crazy things like managing PCI bus access in user space. This slowly changed over the years, with strengthening kernel infra like DRM, the appearance of Kernel Mode Setting, with the evolution of libraries like Mesa. Suddenly implementing a display server became a much simpler affair that mostly could call into a bunch of stuff elsewhere. This created an opening for a new smaller project fully focused on the wire protocol and protocol semantics part, throwing away a lot of old baggage and code. Someone took the time to do that and demonstrate how it looks like, other people liked what they saw and Wayland was born. This also means: Plenty of the useful code of the X11 era actually still exists. One of the biggest myths is that Wayland somehow started over from scratch. A lot of the aforementioned stuff that over the years migrated from the X11 server to e.g. the kernel is obviously still what makes things work now, and libraries such as libinput, xkbcommon that nearly every Wayland display server implementation uses are likewise factored out of the X11 stack.

wosined 1y ago

Very nice.

pedrocr 1y ago

That's probably better than most scaling done on Wayland today because it's doing the rendering directly at the target resolution instead of doing the "draw at 2x scale and then scale down" dance that was popularized by OSX and copied by Linux. If you do it that way you both lose performance and get blurry output. The only corner case a compositor needs to cover is when a client is straddling two outputs. And even in that case you can render at the higher size and get perfect output in one output and the same downside in blurryness in the other, so it's still strictly better. It's strange that Wayland didn't do it this way from the start given its philosophy of delegating most things to the clients. All you really need to do arbitrary scaling is tell apps "you're rendering to a MxN pixel buffer and as a hint the scaling factor of the output you'll be composited to is X.Y". After that the client can handle events in real coordinates and scale in the best way possible for its particular context. For a browser, PDF viewer or image processing app that can render at arbitrary resolutions not being able to do that is very frustrating if you want good quality and performance. Hopefully we'll be finally getting that in Wayland now.

wmf 1y ago
None of the toolkits (Motif, Tk, Gtk, Qt, etc.) could handle fractional scaling so if Wayland had taken the easy way out it would break every app.
- lostmsu 1y ago
  Why is Wayland trying to monkey patch something that's broken elsewhere?
  - wmf 1y ago
    Do you want to be right or do you want to display apps.
    - lostmsu 1y ago
      How many apps will you display if you don't display them right? Are you ready to tell me poor graphics is not one of the reasons people not use Linux? You won't display apps to the users you lost. Instead Windows will.

DonHopkins 1y ago

[flagged]

arp242 1y ago
This does not address anything from the article and is a (seemingly copy/pasted) generic tangent about X11.
- DonHopkins 1y ago
  If you'd read both the article and my post, you'd realize it does actually address the article. It's a quote from the chapter about X-Windows I wrote in the Unix Haters handbook in 1994. https://en.wikipedia.org/wiki/The_UNIX-HATERS_Handbook https://en.wikipedia.org/wiki/The_UNIX-HATERS_Handbook https://web.archive.org/web/20201120053257/http://www.simson.net/ref/ugh.pdf https://web.archive.org/web/20201120053257/http://www.simson... And a description of the screen spanning ruler app (or rather "Desk Accessory") that the Mac had around 1987 or so (I specifically remember Hugh showing it to me a few months before Black Monday). https://en.wikipedia.org/wiki/Desk_accessory https://en.wikipedia.org/wiki/Desk_accessory https://en.wikipedia.org/wiki/Black_Monday_(1987) https://en.wikipedia.org/wiki/Black_Monday_(1987) Just like the article you apparently didn't read mentioned: >With my new knowledge, I also wrote an onscreen ruler using the shape extension. Somewhat tautological for measuring the two inch circle, but in the event anyone asks, I can now tell them my terminal line height is 1/8”, and yes, I measured. https://humungus.tedunangst.com/r/xtoys/v/tip/f/ruler.c https://humungus.tedunangst.com/r/xtoys/v/tip/f/ruler.c Now 38 years later, is there a ruler app for X-Windows that can span multiple screens yet? Or Wayland, even? Why don't you write one!
  - arp242 1y ago
    [flagged]
    - DonHopkins 1y ago
      [flagged]

wmf 1y ago

Drawing a circle is kind of cheating. The hard part of scaling is drawing UI elements like raster icons or 1px hairlines to look non-blurry.

phkahler 1y ago
>> The hard part of scaling is drawing UI elements like raster icons or 1px hairlines to look non-blurry. And doing so actually using X not OpenGL.
- kllrnohj 1y ago
  Yeah this is kinda the big elephant in the room here? They didn't prove what they set out to prove. Yes obviously OpenGL does scaling just fine, the entire point of Wayland is to get the compositor to just being a compositor. They didn't do any scaling with X. They didn't do anything at all with X other than ask it some basic display information.
  - slackfan 1y ago
    X shouldn't be displaying anything that isn't a right angle anyway. All circular UI elements are haram.
- kelnos 1y ago
  Toolkits don't use X to do much (if any) drawing these days. They all use something like cairo or skia or -- yes -- OpenGL to render offscreen, and then upload to X for display (or in the case of OpenGL, they can also do direct rendering).
  - sprash 1y ago
    If you use Cairo on X11 rendering automatically happens with the XRender extension. This is a rather efficient wire protocol that supports sub-pixel coordinates, transparency, gradients and more. No off-screen rendering required. (Some of the older gtk2 theme engines worked that way and allowed beautiful UIs with fast remote capabilities.)

creatonez 1y ago

> Perhaps not the most exciting task, but I figure it’s isomorphic to any other scaling challenge And doing this for everything in the entire ecosystem of ancient GUI libraries? And dealing with the litany of different ways folks have done icons, text, and even just drawing lines onto the screen? That's where you run into a lot of trouble.

q3k 1y ago
Right, it's much easier to also re-engineer all of X11 into Wayland at the same time :).
- kllrnohj 1y ago
  The whole point of Wayland is to not include all of X11. There's a lot of X11 that's just obsolete cruft, like the entire drawing model

lelandbatey 1y ago

I admire your tenacity. I think folks say "X11 doesn't support DPI scaling" when they should say "most programs written against X11 to use official Xlib functionality don't understand scaling". In the article, the author uses OpenGL to make sure that they're interacting with the screen at a "lower level" than plenty of apps that were written against X. But that's the rub, I think the author neatly sidestepped by mostly using stuff that's not in "vanilla" X11. In fact, the "standard" API of X via Xlib seems to only expose functions for working in raw pixels and raw pixel coordinates without any kind of scaling awareness. See XDrawLine as an example: https://www.x.org/releases/current/doc/man/man3/XDrawLine.3.xhtml https://www.x.org/releases/current/doc/man/man3/XDrawLine.3.... It seems to me that the RandR extension through xrandr is the thing providing the scaling info, not X11 itself. You can see that because the author calls `XRRGetScreenResourcesCurrent()` a function that's not a part of vanilla X11 (see list of X library functions here as example: https://www.x.org/releases/current/doc/man/man3/ https://www.x.org/releases/current/doc/man/man3/ ) Now, xrandr has been a thing since the early 2000s hence why xrandr is ubiquitous, but due to it's nature as an extension and plenty of existing code sitting around that's totally scale-unaware, I can see why folks believe X11 is scale unaware.

arp242 1y ago
So on my laptop I've been doing: xrandr --output eDP --scale 0.8x0.8 For years and years, and I never really noticed any problems with it. Guess I don't run any "bad" scale-unaware programs? Or maybe I just never noticed(?) At least from my perspective, for all practical purposes it seems to "just work".
- nixosbestos 1y ago
  Good luck if you plug in an external monitor. (Not to speak of refresh rates)
  - rwmj 1y ago
    At the office I plug in a monitor over USB-C and that just works on my X11 laptop. If something in a browser on the monitor was too large or too small I'd just zoom in/out until it was fine.

kunzhi 1y ago

Interesting article, I'll admit when I first saw the title I was thinking of a different kind of "scaling" - namely the client/server decoupling in X11. I still think X11 forwarding over SSH is a super cool and unsung/undersung feature. I know there are plenty of good reasons we don't really "do it these days" but I have had some good experiences where running the UI of a server app locally was useful. (Okay, it was more fun than useful, but it was useful.)

xioxox 1y ago
It's certainly very useful. I do half my work using X11 over ssh and it works reasonably well over a LAN (at least using emacs, plotting, etc).
- DonHopkins 1y ago
  I worked on the NeWS drivers for Emacs (both "Evil Software Hoarder" Gosling UniPress Emacs 2.20 and later "Free" Gnu Emacs 18), which were extremely efficient and smoothly interactive over low baud rate modems (which we called "thin wire" as opposed to i.e. the "thick wire" coaxial 10BASE5 Ethernet of the time), because instead of using the extraordinarily inefficient, chatty, pong-pongy X-Windows protocol, Emacs could simply download PostScript code to the window server that defined a highly optimized application specific client/server protocol and intelligent front-end (now termed "AJAX"), which performed as much real time interaction in the window system as possible, without any network activity, like popping up and tracking pie menus, and providing real time feedback and autoscroll when selecting and highlighting text. For example, both versions of Emacs would download the lengths of each line on the screen when you started a selection, so you could drag and select the text and animation the selection overlay without any network traffic at all, without sending mouse move events over the network, only sending messages when you autoscrolled or released the button. http://www.bitsavers.org/pdf/sun/NeWS/800-5543-10_The_NeWS_Toolkit_Reference_Manual_Mar1991.pdf http://www.bitsavers.org/pdf/sun/NeWS/800-5543-10_The_NeWS_T... document page 2, pdf page 36: >Thin wire >TNT programs perform well over low bandwidth client-server connections such as telephone lines or overloaded networks because the OPEN LOOK components live in the window server and interact with the user without involving the client program at all. >Application programmers can take advantage of the programmable server in this way as well. For example, you can download user-interaction code that animates some operation. UniPress Emacs NeWS Driver: https://github.com/SimHacker/NeMACS/blob/b5e34228045d544fcb719a412c7ba51cc281f4a3/src/D.term/TrmPS.cps https://github.com/SimHacker/NeMACS/blob/b5e34228045d544fcb7... Selection support with local feedback: https://github.com/SimHacker/NeMACS/blob/b5e34228045d544fcb719a412c7ba51cc281f4a3/src/D.term/TrmPS.cps#L3013 https://github.com/SimHacker/NeMACS/blob/b5e34228045d544fcb7... Gnu Emacs 18 NeWS Driver (search for LocalSelectionStart): https://donhopkins.com/home/code/emacs18/src/tnt.ps https://donhopkins.com/home/code/emacs18/src/tnt.ps https://news.ycombinator.com/item?id=26113192 https://news.ycombinator.com/item?id=26113192 DonHopkins on Feb 12, 2021 | parent | context | favorite | on: Interview with Bill Joy (1984) >Bill was probably referring to what RMS calls "Evil Software Hoarder Emacs" aka "UniPress Emacs", which was the commercially supported version of James Gosling's Unix Emacs (aka Gosling Emacs / Gosmacs / UniPress Emacs / Unimacs) sold by UniPress Software, and it actually cost a thousand or so for a source license (but I don't remember how much a binary license was). Sun had the source installed on their file servers while Gosling was working there, which was probably how Bill Joy had access to it, although it was likely just a free courtesy license, so Gosling didn't have to pay to license his own code back from UniPress to use at Sun. https://en.wikipedia.org/wiki/Gosling_Emacs https://en.wikipedia.org/wiki/Gosling_Emacs >I worked at UniPress on the Emacs display driver for the NeWS window system (the PostScript based window system that James Gosling also wrote), with Mike "Emacs Hacker Boss" Gallaher, who was charge of Emacs development at UniPress. One day during the 80's Mike and I were wandering around an East coast science fiction convention, and ran into RMS, who's a regular fixture at such events. >Mike said: "Hello, Richard. I heard a rumor that your house burned down. That's terrible! Is it true?" >RMS replied right back: "Yes, it did. But where you work, you probably heard about it in advance." >Everybody laughed. It was a joke! Nobody's feelings were hurt. He's a funny guy, quick on his feet! In the late 80's, if you had a fast LAN and not a lot of memory and disk (like a 4 meg "dickless" Sun 3/50), it actually was more efficient to run X11 Emacs and even the X11 window manager itself over the LAN on another workstation than on your own, because then you didn't suffer from frequent context switches and paging every keystroke and mouse movement and click. The X11 server and Emacs and WM didn't need to context switch to simply send messages over the network and paint the screen if you ran emacs and the WM remotely, so Emacs and the WM weren't constantly fighting with the X11 server for memory and CPU. Context switches were really expensive on a 68k workstation, and the way X11 is designed, especially with its outboard window manager, context switching from ping-ponging messages back and forth and back and forth and back and forth and back and forth between X11 and the WM and X11 and Emacs every keystroke or mouse movement or click or window event KILLED performance and caused huge amounts of virtual memory thrashing and costly context switching. Of course NeWS eliminated all that nonsense gatling gun network ping-ponging and context switching, which was the whole point of its design. That's the same reason using client-side Google Maps via AJAX of 20 years ago was so much better than the server-side Xerox PARC Map Viewer via http of 32 years ago. https://en.wikipedia.org/wiki/Xerox_PARC_Map_Viewer https://en.wikipedia.org/wiki/Xerox_PARC_Map_Viewer Outboard X11 ICCCM window managers are the worst possible most inefficient way you could ever possibly design a window manager, and that's not even touching on their extreme complexity and interoperability problems. It's the one program you NEED to be running in the same context as the window system to synchronously and seamlessly handle events without dropping them on the floor and deadlocking (google "X11 server grab" if you don't get what this means), but instead X11 brutally slices the server and window manager apart like King Solomon following through with his child-sharing strategy. https://tronche.com/gui/x/xlib/window-and-session-manager/XGrabServer.html https://tronche.com/gui/x/xlib/window-and-session-manager/XG... While NeWS not only runs the window manager efficiently in the server without any context switching or network overhead, but it also lets you easily plug in your own customized window frames (with tabs and pie menus), implement fancy features like rooms and virtual scrolling desktops, and all kinds of cool stuff! At Sun were even managing X11 windows with a NeWS ICCCM window manager written in PostScript, wrapping tabbed windows with pie menus around your X-Windows! https://donhopkins.com/home/archive/NeWS/owm.ps.txt https://donhopkins.com/home/archive/NeWS/owm.ps.txt https://donhopkins.com/home/archive/NeWS/win/xwm.ps https://donhopkins.com/home/archive/NeWS/win/xwm.ps https://www.donhopkins.com/home/catalog/unix-haters/x-windows/i39l.html https://www.donhopkins.com/home/catalog/unix-haters/x-window...

kragen 1y ago

I think it was yesterday that people's on HN were saying GLX doesn't work over the network?

rwmj 1y ago
$ ssh <remote> glxgears runs fine!
- Ballas 1y ago
  Wow, when did that happen? A couple of years ago I could not get anything OpenGL working over ssh, no matter how hard I tried. Ever since I just accepted that as fact. But I tested it now and it just works!
  - krackers 1y ago
    hasn't this always been the case? I thought one of the whole reasons for the weird design of OpenGL API was that it was a client-server sort of thing to allow for network transparency
    - simoncion 1y ago
      My understanding matches your own. I was doing this circa 2005 with an OpenGL program running on a Linux box in a server closet and a Windows machine running on my desk running some X11 server. Before I did that, I did research into the remote-draw capability of both X11 and OpenGL and came to the conclusion that what I eventually ended up doing would work just fine.
jeffbee 1y ago
Are there people who believe this? What do they think Indirect GLX is? XQuartz as the server and some Linux box as the client has always worked perfectly for me, GLX included.

rwmj 1y ago

It's like the "oh no, X11 suffers from tearing video" problem that they pull out all the time. (A) I have no idea what "video tear" is and (B) I play video all the time on my crappy laptop running X11 and it seems fine for me. But can I ssh to my remote server and run emacs or another program completely transparently yet with Wayland? Nope. I do that with X11 continuously.

toast0 1y ago
I've seen video tearing on X. Usually it doesn't happen, often it's hard to notice anyway; and when it did happen and was annoying, I just was missing some setting or other. No big deal.
ndiddy 1y ago
> But can I ssh to my remote server and run emacs or another program completely transparently yet with Wayland? Nope. Yes, you can! Waypipe came out 6 years ago. Its express purpose is to make a Wayland equivalent to ssh -X. https://gitlab.freedesktop.org/mstoeckl/waypipe/ https://gitlab.freedesktop.org/mstoeckl/waypipe/
- aragilar 1y ago
  Except: 1. It's Wayland-to-Wayland (which means you're much more limited to where it can run than X-to-X, where's the MacOS or Windows or BSD Wayland build?). 2. It's not integrated with ssh (X forwarding is part of the protocol). 3. You need it on both the client and the server, so you need to work out how to get it onto the server.
nullc 1y ago
If someone shows it to you, you'll recognize it. It's when one frame shows part of the prior frame and part of the next. It's most visible in moderate speed horizontal pans as an interruption in vertical lines in the picture. It's nice to not have tearing. But IMO the functionality loss vs X11 isn't worth it for anything but a dedicated media playback/editing device.
- 1y ago

jekwoooooe 1y ago

It’s astounding to me that in Linux, in 2025, I can’t just simply output a custom resolution. You are probably typing a response right now with some xrandr nonsense and I PROMISE you, it won’t do it. I can’t even scale my screen within a normal resolution to make it fit within a boundary. But I can do this in windows with an nvidis gpu. Crazy

throw39304949 1y ago
[flagged]
- jekwoooooe 1y ago
  Nope I can output 4k just fine. That’s not the issue. The issue is I want a 2.35:1 aspect resolution. I can do this on windows and nvidia but not on Linux (steam deck, intel nuc, etc)
- komali2 1y ago
  > As for xrandr nonsense, get AMD card! CUDA, and ray tracing performance. I get it, I've heard the same from the sway maintainer, maintaining their crusade against Nvidia for a couple years now (the --unsupported-gpu flag used to be something like --my-next-gpu-will-be-amd), with some good arguments about how anti-foss Nvidia is. And if that's how sway wants to be then that's how sway's gonna be. But with steamdeck and now steam os showing better performance than windows on handheld gaming devices, and with people getting more and more annoyed with Microsoft's bullshit in windows (like unwanted AI integrations), I think all of us Linux enthusiasts have a really good opportunity here to pull a huge influx of people in, if we're willing to budge just a bit on some of our dogmatic crusades against companies like Nvidia. There's more Nvidia cards in the wild than AMD, according to steam surveys by a huge margin. If we can get Wayland display managers working well on Nvidia thenthat's a lot of new people we can bring into the fold!
deleted 1y ago
[deleted]
lmm 1y ago
> You are probably typing a response right now with some xrandr nonsense and I PROMISE you, it won’t do it. Skill issue. You probably held your keyboard wrong or something. Simple xrandr commands work fine like they have for decades. (Of course if you've moved to Wayland then who knows).

compiler-devel 1y ago

Brilliant. This is another piece of evidence on the pile of why we got Wayland: it's because people who understood X11 mostly retired and everyone else couldn't be bothered to learn X11 because it's "yucky C code" or something. And it bothers me that we lose remote rendering with Wayland (unless one fights with waypipe) that was just built-in to X11. Yes, it was slow, but actually if you're running a VM on your local system and using SSH to connect to it, then it works great. Sigh. I'm an old person yelling at clouds.

sho_hn 1y ago
This is nonsensical myth-making. Despite the clickbait title, the APIs called in those code samples are very basic and not some forgotten wizardry.
- compiler-devel 1y ago
  What part is nonsensical? Because Wayland is basically a fulfillment of jwz's CADT.
  - sho_hn 1y ago
    The part where we got Wayland because we lost a magic caste of rockstar engineers who could call XRRGetOutputInfo/XRRGetCrtcInfo.
nullc 1y ago
> Yes, it was slow, Not particularly if you are on a low latency network. Modern UI toolkits make applications way less responsive that classical X11 applications running across gigabit ethernet. And even on a fast network the wayland alternative of 'use RDP' is almost unusable.
- kllrnohj 1y ago
  the approach used in this blog post requires rdp. It's not drawing using X, so there's no vector network transparency.

jchw 1y ago

Sigh. And now that it's been long enough, everyone will conveniently forget all of the reasons why this wound up being insufficient, and think that all of the desktop environment and toolkit developers are simply stupid. (Importantly, applications actually did do this by default at one point. I remember a wonky-looking nvidia-xsettings because of this.) The thing X11 really is missing (at least most importantly) is DPI virtualization. UI scaling isn't a feature most display servers implement because most display servers don't implement the actual UI bits. The lack of DPI virtualization is a problem though, because it leaves windows on their own to figure out how to logically scale input and output coordinates. Worse, they have to do it per monitor, and can't do anything about the fact that part of the window will look wrong if it overlaps two displays with different scaling. If anything doesn't do this or does it slightly differently, it will look wrong, and the user has little recourse beyond searching for environment variables or X properties that might make it work. Explaining all of that is harder than saying that X11 has poor display scaling support. Saying it "doesn't support UI/display scaling" is kind of a misnomer though; that's not exactly the problem.

zozbot234 1y ago
> can't do anything about the fact that part of the window will look wrong if it overlaps two displays with different scaling It's silly that people keep complaining about this. It's a very minor effect, and one that can be solved in principle only by moving to pure vector rendering for everything. Generally speaking, a window will only ever span a single screen. It's convenient to be able to drag a window to a separate monitor, but having that kind of overlap as a permanent feature of one's workflow is just crazy. > The thing X11 really is missing (at least most importantly) is DPI virtualization. Shouldn't that kind of DPI virtualization be a concern for toolkits rather than the X server or protocol? As long as X is getting accurate DPI information from the hardware and reporting that to clients, what else is needed?
- jchw 1y ago
  > It's silly that people keep complaining about this. It's a very minor effect, and one that can be solved in principle only by moving to pure vector rendering for everything. If you have DPI virtualization, a very sufficient solution already exists: pick a reasonable scale factor for the underlying buffer and use it, then resample for any outputs that don't match. This is what happens in most Wayland compositors. Exactly what you pick isn't too important. You could pick whichever output overlaps the most with the window, or the output that has the highest scale factor, or some other criteria. It will not result in perfect pixels everywhere, but it is perfectly sufficient to clean up the visual artifacts. Another solution would be to simply only present the surface on whatever output it primarily overlaps with. MacOS does this and it's seemingly sufficient. Unfortunately, as far as I understand, this isn't really trivial to do in X11 for the same reasons why DPI virtualization isn't trivial: whether you render it or not, the window is still in that region and will still receive input there. > Generally speaking, a window will only ever span a single screen. It's convenient to be able to drag a window to a separate monitor, but having that kind of overlap as a permanent feature of one's workflow is just crazy. The issue with the overlap isn't that people routinely need this; if they did, macOS or Windows would also need a more complete solution. In reality though, it's just a very janky visual glitch that isn't really too consequential for your actual workflow. Still, it really can make moving windows across outputs super janky, especially since in practice different applications do sometimes choose different behaviors. (e.g. will your toolkit choose to resize the window so it has the same logical size? will this impact the window dragging operation?) So really, the main benefit of solving this particular edge case is just to make the UX of window management better. While UX and visual jank concerns are below concerns about functionality, I still think they have non-zero (and sometimes non-low) importance. Laptop users expect to be able to dock and manage windows effectively regardless of whether the monitors they are using have the same ideal scale factor as the laptop's internal panel; the behavior should be clean and effective and legacy apps should ideally at least appear correct even if blurry. Being able to do DPI virtualization solves the whole set of problems very cleanly. MacOS is doing this right, Windows is finally doing this right, Wayland is doing this right, X11 still can't yet. (It's not physically impossible, but it would require quite a lot of work since it would require modifying everything that handles coordinate spaces I believe.) > Shouldn't that kind of DPI virtualization be a concern for toolkits rather than the X server or protocol? As long as X is getting accurate DPI information from the hardware and reporting that to clients, what else is needed? Accurate DPI information is insufficient as users may want to scale differently anyways, either due to preference, higher viewing distance, or disability. So that already isn't enough. That said, the other issue is that there already exists applications that don't do perfect per monitor scaling, and there doesn't exist a single standard way to have the per-monitor scaling preferences propagated in X11. It's not even necessarily a solved problem among the latest versions of all of the toolkits, since it at minimum requires support for desktop environment settings daemons and etc.

GranPC 1y ago

Can this handle the case in which you have two displays with different DPIs side-by-side, and a window is placed in the middle of them both?

amiga386 1y ago

It's not "can you provide the screen DPI to a window?" people bemoan, it's "can you draw one window across two screens with differing DPIs, transparent to the application?"

kelnos 1y ago
You can absolutely do that on X11, but you have to do it in the client, and no one cares to do it.
- em-bee 1y ago
  if you have to do it in the client, aka the application, then it's not transparent to the application
  - p_l 1y ago
    It's not transparent on Wayland or Windows (no idea about mac) either if you want actually properly drawn stuff. Well, ok, on Windows if you keep to certain standard elements of Windows API and only use standard widgets you could get close to transparency.
  - rbanffy 1y ago
    It'll not be transparent to an application using basic X APIs, but nothing prevents a higher level UI toolkit from implementing it properly.
  - yjftsjthsd-h 1y ago
    If we can require applications to draw their own window controls, I think we can ask them to handle their pixel densities.
    - em-bee 1y ago
      that's a good point. window controls should be at the proper scale too.
- 1y ago

erlkonig 1y ago

This whole issue just seems so pathetic. PostScript and DPS, notably NeWS, have device-independent scaling from the outset - you can completely omit even mentioning pixels, even though they're 2D. Wayland braying on about scalability here just highlights how they don't even understand the game. Going to OpenGL is a nice tactic, since OpenGL doesn't give a flip about screen coördinates anyway. I miss NeWS - it actually brought a number of great capabilities to a window system - none of which, AFAIK, are offered by Wayland.

NooneAtAll3 1y ago

I hope XLibre will keep making X11 better

sumuyuda 1y ago

Related to the LG TV size, isn’t the size the length of the diagonal? The author seemed to think it was the width of the screen.

timeinput 1y ago
In his terminal output with screen dimensions it lists a monitor 1600mm wide which is about 63 inches wide.

buster 1y ago

Regarding this thread: I find it kind of funny how a group of adults can obsess over pixel perfect placement of terminal characters (or whatever) on screens that have so tiny pixels, no other human being would even see a difference without some kind of magnification and obsessive pixel peeping.