Announcement

Collapse
No announcement yet.

XWayland 24.1 Planned For Release Next Month With Explicit Sync & Other Features

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

  • Hibbelharry
    replied
    Originally posted by mSparks View Post
    You can tell that is not true, because
    The proprietary NVidia driver doesn't support implicit sync at all
    Right, except that was workarounded. X11 is implicit sync.

    Originally posted by mSparks View Post
    That whole "wayland not working on nvidia is nvidias fault" nonesense was simply because they (nvidia) weren't willing to invest dev time in a substandard approach to graphics that wayland has been insisting on for the last decade and a half.
    Wayland basically just polonged the status quo and doesn't use the 'magic' of nvidias ddx. Together with other shortcomings in nvidias driver that got nvidia users a bad position.

    Originally posted by mSparks View Post
    But at least wayland is slowly making actual progress to fix its problems rather than just play the blame game.
    I guess the blame game didn't end yet...

    Leave a comment:


  • mSparks
    replied
    Originally posted by Hibbelharry View Post

    X11 is implicit sync, too.
    You can tell that is not true, because

    The proprietary NVidia driver doesn't support implicit sync at all

    That whole "wayland not working on nvidia is nvidias fault" nonesense was simply because they (nvidia) weren't willing to invest dev time in a substandard approach to graphics that wayland has been insisting on for the last decade and a half.

    It will take a while to get working, first they need to build the backend, then it needs adopting, then there will be the typical very long tail of bugs to fix.

    Then they will lose most of their developers because this stuff is hard and putting so much effort in to be almost as good as what exists already isn't that attractive a task to wake up to in the morning.

    But at least wayland is slowly making actual progress to fix its problems rather than just play the blame game.
    Last edited by mSparks; 14 April 2024, 06:46 PM.

    Leave a comment:


  • Hibbelharry
    replied
    Originally posted by mSparks View Post
    On the plus side, now wayland is taking steps to fix the whole implicit sync folly, maybe they will soon (5 or 6 years i guess) be able to par X11 in not producing frames full of glitches for the majority of users.
    X11 is implicit sync, too.

    Leave a comment:


  • mSparks
    replied
    Originally posted by oiaohm View Post

    using what is called undefined behavior.
    So in the middle of claiming otherwise you just decide to outright state Qt is chock full of bugs,

    hilarious.

    On the plus side, now wayland is taking steps to fix the whole implicit sync folly, maybe they will soon (5 or 6 years i guess) be able to par X11 in not producing frames full of glitches for the majority of users.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by oiaohm View Post
    That kmail configuration ui is window with all it contents provided by one process right.
    The main configuration UI is a window from the Kmail process itself but configuration UI of backend processes, e.g. IMAP account handler, are not.
    Kmail and the handler process use xdg-foreign to associate their windows such that the handler's window is considered by the compositor as if it where an in-process dialog of Kmail itself.

    They do a very similar trick on X11. I think there it is called setting a "transient for" hint on the handler's window.

    KDE has helper API for both display servers (and might even work beyond Linux) to do that: see the two variants of KWindowSystem::setMainWindow()

    Originally posted by oiaohm View Post
    Even the web browsers the buffers into their own window.
    I see.

    Originally posted by oiaohm View Post
    Hello everyone! This is a new attempt to resolve the issues clients designed for stacking window managers are facing when they want to set their own...


    The PCSX2 problem falls straight under 264 merge request problem.
    Thanks! Will do some reading.

    Originally posted by oiaohm View Post
    PCSX2 gui design is absolutely not a common design. Most GUI common designs(over 98%) don't have Button from one process and the pop window that button raised from a different process and requiring perfect alignment between those bits.
    So the other process' popup should appear adjecent at the main processes button?

    That is pretty easy to do with Wayland, especially in Qt.

    I have recently done that as a demo for a customer who wanted to have the UI of two existing applications integrated in such a way as to appear as one to the user.

    On X11 they try to fake this with specific rules of their window manager, but of course they are still two processes.
    So one application's modal dialog are not modal for the other.

    With Wayland you can simply create a nested compositor, in my case using the Qt Wayland Compositor framework.
    You can then place the surfaces of your clients (main window, dialogs, popups) anywhere in your window as you see fit.
    None of those are even "seen" by the user session's compositor.

    Any top level window you create is associated with your main window, e.g. on top of it and so on.
    Again you can place as many of your clients surfaces into those windows.

    In my demo I even have a switch to toggle, at runtime, between showing my client's windows inline and as the host compositor's windows.
    There is extreme flexibility for this "merging of other processes' UI" that way

    Leave a comment:


  • oiaohm
    replied
    Originally posted by anda_skoa View Post
    For example when you are in Kmail and create a new IMAP account, the backend service will create another IMAP handler.
    And Kmail will then ask (via D-Bus) that handler process to show its configuration UI.

    That UI appears to the user as a dialog of Kmail, because the two processes have exchanged the information necessary to associate the "foreign" window to be "transient to" Kmail's main window.

    Outside of Qt we have basically all web browsers which launch one process per tab and integrate their buffers into their own UI.
    PCSX2 is not doing any of the above. That kmail configuration ui is window with all it contents provided by one process right. PCSX2 this is not the case parts inside that window can own to different processes.

    Even the web browsers the buffers into their own window. Those buffers still come under the control of the one browser process. You are not looking at this with PCSX2.

    Originally posted by anda_skoa View Post
    I am somewhat curious how they are approaching their "foreign" process integration, but I guess I don't really want to spend that much time understanding a code base I am not used to
    Hello everyone! This is a new attempt to resolve the issues clients designed for stacking window managers are facing when they want to set their own...


    The PCSX2 problem falls straight under 264 merge request problem. There is not really foreign process integration and PCSX2 has it own iPC. PCSX2 is more one application tells another application by it IPC an absolute position and then it puts window/popup at absolute position..... Of course when qt decides to bogus of absolute position in way that works with a most applications this goes totally south with something like PCSX2.

    Originally posted by anda_skoa View Post
    I wonder why they are not using a more common approach then.
    Because PCSX2 like PCSX before it was not a normally constructed program. These are closer to GIMP of old where all different parts of the program are in fact different applications. PCSX2 use to allow third parties to provide applications replacing almost every single bit and modern fork PCSX PCSX-redux still does..

    PCSX2 gui design is absolutely not a common design. Most GUI common designs(over 98%) don't have Button from one process and the pop window that button raised from a different process and requiring perfect alignment between those bits.

    Stuff like PCSX2 when it comes to GUI construction is a true abomination even under X11 it technically using what is called undefined behavior. Yes PCSX2 problems are true corner case like it or not.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Quackdoc View Post
    Your link is broken for the PDF. but I would very much disagree with flutter + wayland being best practice for embedded. Well flutter at all. Flutter is great don't get me wrong, I
    Fixed link but that was not my personal option that the option from sony the one who does most of the development on Flutter.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by oiaohm View Post
    I should be more clear.

    Lot's of different possibilities how processes interact

    Originally posted by oiaohm View Post
    When I say multi progesses application. I mean multi progress GUI application in a very particular way that not common.
    I wonder why they are not using a more common approach then.

    Originally posted by oiaohm View Post
    You click on a button in pcsx2 and popup appears. You have a 80% that the popup that has just appeared is from a different progress to the button you clicked. Now what is the odds of this in 98%+ of all applications out there.
    While it might not be super wide spread, it is something you will have with KDE's PIM applications, when the user creates a new "connector".

    For example when you are in Kmail and create a new IMAP account, the backend service will create another IMAP handler.
    And Kmail will then ask (via D-Bus) that handler process to show its configuration UI.

    That UI appears to the user as a dialog of Kmail, because the two processes have exchanged the information necessary to associate the "foreign" window to be "transient to" Kmail's main window.

    Outside of Qt we have basically all web browsers which launch one process per tab and integrate their buffers into their own UI.

    Originally posted by oiaohm View Post
    That right this does not happen at all. PCSX2 GUI design in it code is a true odd ball.
    I am somewhat curious how they are approaching their "foreign" process integration, but I guess I don't really want to spend that much time understanding a code base I am not used to

    Originally posted by oiaohm View Post
    Yes I was not referring to service/ui process multi process or . I am referring to multi process inside the UI part with pcsx2 this makes is very different to all the KDE applications.
    There could still be similarities, see above

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by oiaohm View Post
    ...
    Your link is broken for the PDF. but I would very much disagree with flutter + wayland being best practice for embedded. Well flutter at all. Flutter is great don't get me wrong, I love flutters flexibility, relatively good performance and ease of development. However Flutter is still a lot heavier on drawing then a lot of other toolkits. This is fine for things like modern phones, even low end ones, but they still have, in relation ship to other "embedded devices" a quite powerful gpu. They also sit heavier on ram as well.

    Flutter is only a good option on the more powerful end of the embedded spectrum. Even on android I'm not the biggest fan of flutter applications on super low end phones.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by anda_skoa View Post
    I guess it depends on how one would define "multi process application"
    I should be more clear.

    Originally posted by mSparks View Post
    Seems you, me and him are all agreed, anybody who is not a qt core developer or a Wayland protocol developer should forget about wayland for a few decades until/if they get their shit together.
    No I don't agree. Many parties using QtWayland without any issues. What is unique about pcsx2 is something horrible. When I say multi progesses application. I mean multi progress GUI application in a very particular way that not common.

    You click on a button in pcsx2 and popup appears. You have a 80% that the popup that has just appeared is from a different progress to the button you clicked. Now what is the odds of this in 98%+ of all applications out there. That right this does not happen at all. PCSX2 GUI design in it code is a true odd ball.

    Originally posted by anda_skoa View Post
    Quite some KDE applications are split into a service and a UI process.
    Yes I was not referring to service/ui process multi process or . I am referring to multi process inside the UI part with pcsx2 this makes is very different to all the KDE applications.

    mSparks when something is having trouble it takes two to tango as they say. There are things about pcsx2 that make it not a common application design it hits a lot of corner cases that are not well supported at this stage.

    Fixed link this is a 2020 presentation that was given in a few different conferences.


    Flutter + Wayland is the best practice in embedded systems using Linux

    Yes that is 2020 and in 2020 we were already seeing new soc chips released for embedded without X11 support.

    Embedded Linux embedding for Flutter. Contribute to sony/flutter-embedded-linux development by creating an account on GitHub.

    And it gets more fun mSparks
    Display backend support

    Wayland
    Direct rendering module (DRM)
    Generic Buffer Management (GBM)
    EGLStream for NVIDIA devices

    That right for embedded usage the current version of flutter does not support X11 at all(yes it use to). Yes flutter has weston integration as it own shell/window manager.

    Users of flutter in embedded they don't have a healthy dose of X11 for quite a few years now.​

    mSparks like it or not there are a lot of use cases where wayland and weston are perfectly fine where X11 use to be but X11 in those use cases is no more.

    mSparks wounder how many other things that you claim everyone uses also turn out to be like flutter use to support X11 but today does not support X11 at all. This is part of why upstream X11 on bare metal is running out of developers.
    Last edited by oiaohm; 14 April 2024, 01:44 PM.

    Leave a comment:

Working...
X