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.

> There isn't a way to do this correctly, it's a hack

Hacks are often the correct way to do things.

JFC this is annoying. I'm telling you "it works for my professional use case on X11 and doesn't on Wayland" and you keep trying to gaslight me about this by saying it's impossible.

This doesn't work on Wayland. It does work on X11. You can stomp your feet until you're blue in the face but that won't change this basic fact.

If (for whatever reason; I'm still mystified why you care about this) you really really think it's important to get me to switch display servers, make it work on Wayland. Otherwise just let me have my preferences which I largely maintain and package.

>Hacks are often the correct way to do things.

In this case, it's not the correct way.

>I'm telling you "it works for my professional use case on X11 and doesn't on Wayland" and you keep trying to gaslight me about this by saying it's impossible.

No it's actually the other way around. You keep gaslighting and insisting that it's a valid solution because it works for a small subset of clients that you've picked for yourself. I'm telling you this isn't a valid solution for any X11 maintainer to put in place. I've already showed you where an X11 maintainer actually said this, but for some reason you think you know better. Well I'm sorry, but it's not a solution. When you maintain something like that, you don't get to pick and choose the clients you support. You have to support all of them. And yes, it is impossible for X11 maintainers to go and find and fix bugs in every single client from the last 35 years or port them all to XCB and rewrite the drawing code or whatever it is you'd like them to do.

>This doesn't work on Wayland. It does work on X11.

No, it doesn't work on X11 either. Refer back to the merge request I posted earlier. This isn't something you can just hack in. Your solution will break down if you ever need to use a different type of client.

>If (for whatever reason; I'm still mystified why you care about this) you really really think it's important to get me to switch display servers, make it work on Wayland. Otherwise just let me have my preferences which I largely maintain and package.

Where is this coming from? I've never said you should switch display servers. I'm only observing that you probably will once the limitations in your approach become apparent. You realistically don't get to even have preferences here, maintaining all of this is too much work for one person. Maybe you won't switch to Wayland, maybe it'll be something else entirely. Who knows? The point is, X11 doesn't do it.

And this is really my problem with talking about open source on HN. The well has been poisoned, I can't point out broken stuff without someone accusing me of having some kind of agenda. As if anyone who's developed for X11 for the last 36 years hasn't run into all these problems, repeatedly. Nothing is going to get fixed if everyone gets defensive and starts playing the blame game when bugs are pointed out. But that's all that happens here. If you ask me, it's yet another sign that the project is finished.