• 0 Posts
  • 39 Comments
Joined 1 year ago
cake
Cake day: June 11th, 2023

help-circle

  • The 1 second present timeout still only works for XWayland

    Oof, I thought the corresponding MR for Wayland was merged… But it was from Sebastian and after he got into a heated discussion again and started cursing, the MR got closed by someone else :|

    realistically unless SDL2, GLFW or whatever engine a gamedev is using handles it for them they just don’t have the time to worry about what GTK, Qt, or XDG shell does

    SDL does handle it, but only for OpenGL; it can’t do anything about Vulkan. GLFW doesn’t do anything about it either, so that is pretty annoying.

    I believe in the glorious Wayland future… I just wish it would get here a bit faster

    Don’t we all. Let’s hope the current upstream approach to fix this issue gets somewhere sooner than later…







  • What are the not-a-bugs? Things like covering up a Wayland window will block it’s rendering thread indefinitely with no way to detect it happens to handle it. This can lock up some games, or cause you to time out in a networked application. Some Wayland core folks don’t want applications to know if their window is visible or not because it’s mild information about a user’s attention that should be private. Every game dev on the other hand is asking “WTF!?” as it causes their games to break randomly

    Please don’t make up what “Wayland core folks” think. You don’t know it, and your claims are waay off.

    It’s not about security. It was intended to allow the compositor to throttle apps to improve efficiency… Which of course in practice doesn’t work like this at all, because OpenGL swap buffers and Vulkan FIFO presentation modes were never intended to be used this way.

    As for why that hasn’t been fixed yet, it’s not as big of a problem anymore:

    • Mesa (at least for Vulkan) and Xwayland gurantee one frame per second as a minimum refresh rate
    • toolkits and libraries use mailbox presentation internally and check frame callbacks themselves for when to render
    • xdg shell now contains a flag for apps to know to inhibit rendering because they’re hidden. That doesn’t guarantee that presentation won’t otherwise block though
    • a (set of) protocol(s) is being worked on to replace frame callbacks with a mechanism actually suited for OpenGL and Vulkan

    Another mild example is that windows cannot be raised except by the user or by launching them. This is supposed to be a mild security precaution so a program can’t pop up a legitimate looking dialog over another application and trick the user. Realistically it means that applications can’t open and focus URL in your web or file browser. Instead they have to give you a notification telling you “Firefox is Ready” and make you do it manually.

    That’s not even close to how activation works on Wayland, and no, it’s not just a security thing, it’s a usability thing. Apps can only raise themselves if the currently focused app gives them focus, so that random apps can’t cover up what you’re working on just cause they need to show you an ad or an “important” pop up question or whatever. If it doesn’t work for a specific app, make a bug report about it to the app.










  • All it ever was intended for was to make us feel like something was being done while doing absolutely nothing.

    It certainly does help a little bit. But it’s of course still not a coincidence that companies are pushing for it instead of more effective measures… It’s not just cheap but it also pushes people to believe that measures to save the environment are all useless and annoying, and makes them less likely to want more to happen.



  • While I agree with your conclusion, your explanation is not right.

    X11 is the 11th version of the X protocol, it is not an implementation. The Xorg server is the only relevant implementation for the server side of things, and for X11 window managers and X11 compositors there’s only libx11 (which is very horrible) or libxcb (slightly less horrible). Both of those are about as high level as libwayland-server + libwayland-scanner - which is to say, nearly as low level as it gets.

    wlroots in contrast provides comparatively high level libraries / components, which make the implementation of compositors less of a headache than having to mess around with barely documented xcb functions.