3 ms·

No. Even the X.org developers disagree with you here. Messing with the DPI will cause lots of clients to break even further. See this merge request for more inf

No. Even the X.org developers disagree with you here. Messing with the DPI will cause lots of clients to break even further. See this merge request for more info on this: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/792 https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests... X11 simply isn't built to do this. If you want this to work, then the last 35 years of clients don't do the right thing and still would need to be changed to use a new extension that behaves more like Wayland does it.

bandrami 3y ago
And yet, it works better than in Wayland.
- E1Q6Y57O 3y ago
  No it actually doesn't, I've heard tons of complaints about X clients not scaling correctly. Sure it might work for the subset of clients that are reading the DPI value the way you intended, but in doing so you've silently broke a lot of other clients.
  - deleted 3y ago
    [deleted]
  - bandrami 3y ago
    The "subset" of clients using Xcb or Qt? I'm fine with only counting them, personally...
    - E1Q6Y57O 3y ago
      This comment makes no sense, XCB isn't a toolkit. You might be thinking of something else with a similar acronym. But anyway, any solution that tells users to only use a small subset of compatible clients is about as disruptive as just switching wholesale to Wayland. It's not the reason anyone is hanging on to the X server.
      - bandrami 3y ago
        I didn't say it was a "toolkit", it's a library that largely replaces Xlib, and it uses xrandr correctly to allow multiple pitches https://xcb.freedesktop.org https://xcb.freedesktop.org
        E1Q6Y57O 3y ago
        Yes, I know what it is. Here are some corrections. 1. XCB is a low level binding to the X11 protocol. It doesn't really replace Xlib. Originally that was the intention, but it's non-trivial to take an Xlib program and port it to XCB. 2. XCB doesn't know anything about scaling or even about XRandR, besides the wire protocol. Just because a client uses XCB is no guarantee that it even uses XRandR. It's definitely not a guarantee that it implements scaling. 3. There is no way to use XRandR correctly to allow multiple pitches, because XRandR doesn't have that functionality. All it does is report an estimated size of the monitor. 4. The scaling you're talking about is happening in the client, not in XCB or XRandR, and if it's ever going to work at all it needs to be controlled by some other setting or environment variable. Someone else in the thread posted a big set of those environment variables. Ideally you wouldn't use XRandR at all, there would be another extension. 5. None of the above applies to Qt, because Qt is a toolkit that does (mostly) implement the scaling for you. That's why it was weird you grouped it with XCB.
        bandrami 3y ago
        That's a whole lot of "nothing" it has to do with randr: https://xcb.freedesktop.org/manual/group__XCB__RandR__API.html https://xcb.freedesktop.org/manual/group__XCB__RandR__API.ht... But, yes, software using Xcb does have to actually do it correctly for it to work, like nearly all aspects of software development.
        E1Q6Y57O 3y ago
        Like everything else in XCB, those are just stubs autogenerated from the wire protocol definition. The client has to actually implement the protocol semantics including duplicating a lot of logic that's already present in Xlib. There's no performance benefit to this either. For that reason XRandR is probably one of the most useless and least beneficial things to use XCB for. Signed, someone who actually did try this at one point and ended up reverting back to Xlib. >But, yes, software using Xcb does have to actually do it correctly for it to work, There isn't a way to do this correctly, it's a hack. The difference is that Qt attempts to do it automatically, compared to XCB that intentionally does nothing for the programmer because it's a low-level binding.

bandrami 3y ago

And yet, it works better than in Wayland.

E1Q6Y57O 3y ago
No it actually doesn't, I've heard tons of complaints about X clients not scaling correctly. Sure it might work for the subset of clients that are reading the DPI value the way you intended, but in doing so you've silently broke a lot of other clients.
- deleted 3y ago
  [deleted]
- bandrami 3y ago
  The "subset" of clients using Xcb or Qt? I'm fine with only counting them, personally...
  - E1Q6Y57O 3y ago
    This comment makes no sense, XCB isn't a toolkit. You might be thinking of something else with a similar acronym. But anyway, any solution that tells users to only use a small subset of compatible clients is about as disruptive as just switching wholesale to Wayland. It's not the reason anyone is hanging on to the X server.
    - bandrami 3y ago
      I didn't say it was a "toolkit", it's a library that largely replaces Xlib, and it uses xrandr correctly to allow multiple pitches https://xcb.freedesktop.org https://xcb.freedesktop.org
      - E1Q6Y57O 3y ago
        Yes, I know what it is. Here are some corrections. 1. XCB is a low level binding to the X11 protocol. It doesn't really replace Xlib. Originally that was the intention, but it's non-trivial to take an Xlib program and port it to XCB. 2. XCB doesn't know anything about scaling or even about XRandR, besides the wire protocol. Just because a client uses XCB is no guarantee that it even uses XRandR. It's definitely not a guarantee that it implements scaling. 3. There is no way to use XRandR correctly to allow multiple pitches, because XRandR doesn't have that functionality. All it does is report an estimated size of the monitor. 4. The scaling you're talking about is happening in the client, not in XCB or XRandR, and if it's ever going to work at all it needs to be controlled by some other setting or environment variable. Someone else in the thread posted a big set of those environment variables. Ideally you wouldn't use XRandR at all, there would be another extension. 5. None of the above applies to Qt, because Qt is a toolkit that does (mostly) implement the scaling for you. That's why it was weird you grouped it with XCB.
        bandrami 3y ago
        That's a whole lot of "nothing" it has to do with randr: https://xcb.freedesktop.org/manual/group__XCB__RandR__API.html https://xcb.freedesktop.org/manual/group__XCB__RandR__API.ht... But, yes, software using Xcb does have to actually do it correctly for it to work, like nearly all aspects of software development.
        E1Q6Y57O 3y ago
        Like everything else in XCB, those are just stubs autogenerated from the wire protocol definition. The client has to actually implement the protocol semantics including duplicating a lot of logic that's already present in Xlib. There's no performance benefit to this either. For that reason XRandR is probably one of the most useless and least beneficial things to use XCB for. Signed, someone who actually did try this at one point and ended up reverting back to Xlib. >But, yes, software using Xcb does have to actually do it correctly for it to work, There isn't a way to do this correctly, it's a hack. The difference is that Qt attempts to do it automatically, compared to XCB that intentionally does nothing for the programmer because it's a low-level binding.