VERBLUFFEND
finally the flicker hell will gone
Explicit GPU Synchronization Merged For XWayland
Collapse
X
-
Originally posted by schmidtbag View PostI'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).
Leave a comment:
-
-
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:
-
-
Originally posted by Khrundel View PostBtw, 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 PostEven smaller teams prefer to write wayland support library from scratch instead of using and improving weston.
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:
-
-
Originally posted by oiaohm View PostThat 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.
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:
-
-
Originally posted by MrCooper View PostYou'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.
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:
-
-
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:
-
-
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..
Just because normal xserver and Xwayland are sharing the same master this does not mean Diverging cannot happen.
All the Explicit GPU sync stuff only has Xwayland implementation at this stage.
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.
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:
-
-
Originally posted by Khrundel View PostTheir intention was built into protocol itself: barest minimum of features hints that goal: еvery server should be able to implement in independently.
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 PostThey 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:
-
-
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.
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 PostDo note X11 protocol lets you go and implement it yourself as well.
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.
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.
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:
-
Leave a comment: