Explicit GPU Synchronization Merged For XWayland

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • bhptitotoss
    replied
    VERBLUFFEND

    finally the flicker hell will gone

    Leave a comment:


  • Forge
    replied
    Originally posted by schmidtbag View Post
    I'm a Wayland fan but from what I understand, multi-monitor seems to be the most problematic feature regardless of DE. Not sure if that's still true since I haven't used Linux and multiple extended displays in years (I've cloned displays in the past year but that's not really the same thing).
    4K 144HZ 43" on the wall, 1440p 165Hz down here on my desk, both working correctly and without issues under Wayland. Under X11, I had so many issues with scaling, refresh rates, window movement and monitor orientation. Under Wayland, it has all "just worked".

    Leave a comment:


  • marlock
    replied
    IMHO Wayland is already on a different path from X11, just like Vulkan is on a different path from OpenGL, because it isn't as naive as its predecessor project, even if for no other reason...

    there is people thinking it up with an eye on security by design, so it shouldn't fall into the same horrible traps that made an X11 protocol replacement so direly necessary

    there is governance so extensions aren't added to core without being necessary and well designed and proven as an extension somewhere first (with competing implementations actually serving this purpose well, such as gamescope implementing draft version protocol extensions for HDR but totally willing to replace it once a final design is agreed on), all the while signaling this draft state well enough that nobody walks into a trap without prior warni

    there is also nowadays a wider base of commongly agreed on requirements for desktops, workstations, servers, render farms, mobile, iot, vr, etc partly born from FOSS software development model winning hearts and minds all around the world and different industries (see Automotive Grade Linux, Academy Software Foundation, etc)

    also the issues of the past are well known and the devs that worked on X.org are present in wayland development, so it's much less likely they'll be repeated now

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Khrundel View Post
    Btw, even their lexicon tells you about their main goal. Wayland is main artifact of development and it is a protocol while weston is just a reference implementation. And it wasn't only candidate to replace xorg, there was another, Mir. And it was a display server with its own client protocol, which wasn't mentioned much.

    MIR was mentioned a lot back in the day. The reality is the Canonical choice of CLA and GPLv3 fairly much shot itself in foot with Mir.


    Guess how many X11 windows managers/X11 compositors projects were GPLv3 accepting even up to the current day.

    The reality is Mir changing to a Wayland compositor and fixed up CLA did not change the fact it was licensed wrong to bring the normal X11 Windows manager developers in.

    wlroots is MIT Weston is MIT X.org Xserver is MIT. Notice a kind of trend here. The reality here is MIR was not going to be competition it was not licensed right to be competition for the core role. Having Canonical marketing department Mir just made a lot of noise about it presence.

    Originally posted by Khrundel View Post
    Even smaller teams prefer to write wayland support library from scratch instead of using and improving weston.
    The fun part is this behavior with Wayland is a repeat. When the X11 protocol was fairly new and still fairly simple it was still common to see all the different Unix vendors to write their own X11 server than use the reference X11 server as well. This is history that has repeated over and over again while a protocol is simple you end up with a stack of competing implementations that is just the way it is.

    While the wayland protocol is still simple enough to implement we should expect to see fragmentation. But remember the Wayland protocol with extensions is progressively growing and applications expect more of those extensions so the complexity to make Wayland solution is growing. At some point using a common core will come the only practical way if you are not a large project to implement Wayland. Then even for large projects there is going to be pressure to use the common core and that is if Wayland follows the same live cycle X11 protocol did so far it seams to be following exactly the same path.

    Leave a comment:


  • Khrundel
    replied
    Originally posted by oiaohm View Post
    That is a side effect of a early stated goal. Prevent Wayland protocol turning into X11 protocol stack of random added on garbage has implemented a strict policy that any protocol extension has to prove it functionality. You have to remember X11 protocol end up with a stack of useless items added to it that people put into the protocol without checking if they were really a good idea.
    Oh, just stop it.
    The goal was to be able to implement simple functions themselves. All your fantasies is just meant to not to notice an elephant in the room. There is nothing wrong with "random added garbage" ie "lots of convenient functions" unless your intention is to make independent implementations easier to create.

    Btw, even their lexicon tells you about their main goal. Wayland is main artifact of development and it is a protocol while weston is just a reference implementation. And it wasn't only candidate to replace xorg, there was another, Mir. And it was a display server with its own client protocol, which wasn't mentioned much. An idea of a new alternative display server have lost the competition. Some time ago mir was transformed to DS for wayland and still nobody want to use it, even smaller projects prefer implement it semi-independently using wlroots. And, another btw, you can suspect some "malicious" intention from gnome or kde, but there is wlroots. Even smaller teams prefer to write wayland support library from scratch instead of using and improving weston. This tells about sanity of keeping some common display server in stack.

    I mean every interface point brings some additional complexity and limits freedom of internal architecture. When you have simple enough client protocol it is easier to implement this protocol instead of maintaining DS and its additional interface from both sides.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by MrCooper View Post
    You're losing me. Xwayland uses the same glamor code as the rest of xserver, it's not possible for any glamor patches of mine to be in Xwayland but not in xserver.
    You really need to look.

    For ALUs which may leave the alpha channel at values other than 1.0. Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1615 v2: * List safe ALUs instead of unsafe ones (cherry picked from commit e5a3f3e84dbbc1484d56d9a64f14508a4bf8af19)

    This patch is in xwayland but is not in the server branch.

    Yes look at the server-21.1-branch and they are missing.

    The patches from Peter Hutterer that should both side of those 3 glamor patches exist in both branches but the 3 glamor patches are only in one branch.

    So the maintainer of the xserver branch has not been merging your patches there is a divergence you have not noticed in the glamor code.




    Really you need to stop claiming this is not happening. Did you have a disagreement with the party who is maintaining the server branch.

    You are not the only developer who working what is a shared part between all who patches are making it into the xwayland branch and not into the server branch.

    Leave a comment:


  • diegodamohill
    replied
    Do we really have to entertain trolls with another wayland vs x11 discussion? Again?

    My dude, you don't like Wayland? Want to keep using x11, to get new features? GO FOR IT, the code is right there! write something, make a merge request. Hire someone to do it for you, no one will stop you.

    The rest of us will use Wayland while you shout at the clouds.

    Leave a comment:


  • MrCooper
    replied
    Originally posted by oiaohm View Post

    It absolutely happening. We are watching current maintainer of x.org from Oracle just adding security update after security update to the old version..
    So? Backporting fixes isn't "diverging".

    Just because normal xserver and Xwayland are sharing the same master this does not mean Diverging cannot happen.
    Yes it does, since the non-Xwayland-specific code in the Xwayland binary is shared with the other DDXen.

    All the Explicit GPU sync stuff only has Xwayland implementation at this stage.
    One DDX supporting a feature other DDXen don't isn't divergence. There's no incompatibility.

    Like one of the clear ones of trouble that is recent is glamor is a generic part shared between server and xwayland. Why does xwayland have Michel Dänzerand glamor patches xserver does not.
    You're losing me. Xwayland uses the same glamor code as the rest of xserver, it's not possible for any glamor patches of mine to be in Xwayland but not in xserver.

    Look, I explicitly designed the Xwayland-only release process to prevent the issue you're worried about. So can we please stop wasting time on this? Thanks.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Khrundel View Post
    Their intention was built into protocol itself: barest minimum of features hints that goal: еvery server should be able to implement in independently.
    That is a side effect of a early stated goal. Prevent Wayland protocol turning into X11 protocol stack of random added on garbage has implemented a strict policy that any protocol extension has to prove it functionality. You have to remember X11 protocol end up with a stack of useless items added to it that people put into the protocol without checking if they were really a good idea.


    This is a classic example. Xprint is lets just duplicate what IPP is https://dl.acm.org/doi/pdf/10.1145/338183.338184 ISO 10175(is kind of a early name for IPP) without any really good reason and even then forward everything we do to IPP so just adding extra complex for no good reason. Of course there are worst features that were deleted from X11 server where they were added to x11 server code and they never worked..

    Remember that any new functionally being added to Wayland core protocol has to prove it functionality goal is still in effect and this is what makes some of the debates about adding Wayland features take so long as the checking that the design is sane end up finding design flaws requiring the feature to be redone over and over again until in the end it agreed to be right.

    This is the problem the early stated goals of Wayland are not for every server should implement their own thing. Side effect of keeping the Wayland protocol clean and compact makes everyone who already had massive complex X11 compositor dealing with stack of X11 quirks to say this looks simple to implement in our existing X11 compositor instead of using someone else solution....

    There are side effects to the Wayland stated core goals and most of those core goals are still in effect.

    Originally posted by Khrundel View Post
    They have evaluated pros and cons of usage of shared code and have chosen not to. That is pretty smart, when you have simple protocol.

    See problem even you. A simple cleanly design protocol if that you implement this goal one of the annoy side effects is people getting the idea to implement their own version instead of using the provided shared solution. This is why was not a goal of the Wayland project to have this happen with fragmentation but a side effect of a core goal. This is just annoying side effect of effort to keep Wayland protocol clean of garbage so it does not turn into X11 protocol that required at one point a developer spending 10 years just deleting stuff..

    Of course as Wayland protocol grows the cost of doing own thing increases and this in theory should encourage smaller items do joint development. Bad luck for Wayland developers is that most people doing joint development have gone wlroots instead of Weston. Lets say wlroots had not appeared as Wayland compexity grew many parties would have been forced into Weston as the option and we would not be looking down the same fragmentation problem.

    This is more what can go wrong has.

    Last edited by oiaohm; 11 April 2024, 08:19 AM.

    Leave a comment:


  • Khrundel
    replied
    Originally posted by oiaohm View Post

    The stated goal by the Wayland core developer was to implement something that fixed the core issue with X11.
    Sure. And one of the "corest" issue with x11 is an existence of xorg in the stack, which brings almost no useful functions but requires a tons of babysitting. Haven't you read this statement in their rationale? Every programmer had met a situation when some library does in project some petty function while requiring a bunch of support code, so after another struggle with it he decides "why don't rewrite this feature myself?".
    Xorg could look fine for some bootleg DE developer, almost everything already here, you can get some existing components, write some configs and all will work almost without issues. But to somebody who tries to develop a solid stable DE all these features like "every program can take any DS responsibility" are another source of disturbance which can lead to falling apart.
    Originally posted by oiaohm View Post
    Do note X11 protocol lets you go and implement it yourself as well.
    No, it doesn't. And no need to. If you are already breaking compatibility, why not to develop protocol which suits modern use cases?
    You will find that the state goal you have just claimed was not a stated goal of early Wayland. The choice was provided where they could have choose to work on Weston or work on their own. Gnome and KDE choose to work on their own.
    Sure. They have evaluated pros and cons of usage of shared code and have chosen not to. That is pretty smart, when you have simple protocol.
    The plugin system of weston makes no sense if it was not designed to be a universal yes parties have implemented like wlroots panels and other things using weston plugins.
    Nobody forbids you from using weston in your project and I believe samsung was using it in production. That doesn't mean it was intended as single implementation.
    Their intention was built into protocol itself: barest minimum of features hints that goal: еvery server should be able to implement in independently.

    Single wayland DS is dumbest idea ever: you've just got rid of monstrous blob which could break everything and developed nice and compact protocol which allow clients to do their GUI while leaving DS free to implement anything as it wants. Why anybody would choose to create another "fits for all" blob with complicated API to control it?

    The whole Idea of "lets gather together and concentrate our efforts" works in child cartoons only. That is what wayland critics can't understand. Every another developer added to project brings less utility and this works for projects with single well-defined set of functions. When new developer does not implement existing set of functions but brings just another feature nobody asked because he needs it within his experimental DE, his work will slowdown project's development.

    Leave a comment:

Working...
X