Announcement

Collapse
No announcement yet.

There's Finally An Experimental Driver For Native Wayland Support Within Wine

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

  • #21
    Originally posted by ix900 View Post

    Do you really need to turn Wine/Wayland into an Nvidia hate post? Seriously?

    You do understand even with AMD, Wine has a lot of code built for X11? What juice are you drinking? Leave the hate group. You would be better off without it.
    Well, for a long time the wine devs had primarily developed it on nVidia hardware and while that's not true anymore it used to be true. The problem with it was that nVidia's OpenGL driver has a whole lot of quirk fixes for numerous games and it's not compliant at all with OpenGL specifications. And for a long time wined3d only really worked well on nVidia's hardware because of it. It put a bad taste in a lot of peoples mouths because it was entirely artificial based on wine devs developing on nVidia's non-standards compliant driver. Although wined3d is in better shape today it still doesn't work quite right on anything else besides nVidia's OpenGL driver.

    AMD had a bad reputation for compatibility with games running on wine, but it wasn't their fault, it was actually nVidia's fault. Thank god for Vulkan wrappers, they help remove wined3d from the equation and things are running much, much better on all non-nVidia hardware now.

    I'm just explaining it because it's where a lot of nVidia hate started...

    Comment


    • #22
      Originally posted by StarAurryon View Post
      That's not how wine is designed. Basically, when a GUI is open through wine, wine uses a "GDI32" driver. On Linux "GDI32" uses winex11.drv that provides, keyboard and mouse input, surface blitting ("See WindowPosChanging and FlushSurface functions"), window position, clipboard and vulkan/opengl bridge.

      All of this is indeed portable (in most cases) from libX11, etc to SDL2 that is already integrated to wine for gamepad inputs. There could be one single backend for possibly, android, linux, osx, etc.
      Even on the GDI32 part there is stuff there you cannot really convince SDL2 todo. When wine started using SDL2 for gamepads this idea was brought up in the mailing list and there are a stack of limitations. Horrible more than porting to native wayland. SDL2 is not a perfect solution it does have some serous limitations by its abstractions that do disagree with what windows applications want. Yes SDL2 is suitable for particular areas of wine just its not a total back end solution.

      Originally posted by duby229 View Post
      It wasn't solved at all, they implemented a cgroups policy to hide input latency.... It wasn't a solution, it was a hack.... Brute force isn't a solution....

      EDIT: It looks like Gnome 40 might actually solve it partially though... (Although it looks like they are breaking both themes and extensions, again....)
      Giving the scheduler more information so it can make better allocations is part of the solution to fix input latency long term. So its was not exactly hack it was less than half the solution but it could show over 60% of the gains.

      Originally posted by ix900 View Post
      Do you really need to turn Wine/Wayland into an Nvidia hate post? Seriously?

      You do understand even with AMD, Wine has a lot of code built for X11? What juice are you drinking? Leave the hate group. You would be better off without it.
      Interested in all the work the open source consulting firm Collabora are doing with Valve to help improve Linux gaming? We've got you covered.


      The reality here is like it or not collabora is working with Valve. Valve is getting very annoyed with Nividia that they are not releasing Xwayland stuff. Valve want gamescope so they can sandbox games better and give users better experiences this need either Wayland or Xwayland support in the game/wine.

      Sorry this is not hate ix900. This is the reality. Reason why the Wayland work on wine has been brought forwards is Nvidia not doing Xwayland drivers.

      So if someone thinks this is wasting development time doing a Wayland back end for wine because the X11 backend was good enough they really should be told who is to blame and why its happening. This is funded development companies don't fund this stuff without reason.

      Comment


      • #23
        This was one of the main issues I had with Wine on a Wayland desktop. XWayland works quite well now, but native Wayland support in Wine would be fantastic. Can't wait to see it merged into Wine&Proton! I'm sure this will help Wayland adoption too.

        Edit: It doesn't support Vulkan yet. But the developer mentioned that he has the hope to hopefully join forces with the Wine-wayland for Vulkan project.
        Last edited by R41N3R; 15 December 2020, 05:09 PM.

        Comment


        • #24
          Originally posted by Weasel View Post
          Waste of time.
          And why is that, exactly?

          Comment


          • #25
            Originally posted by Weasel View Post
            Waste of time.
            Working on X is waste of time.

            Comment


            • #26
              Originally posted by Weasel View Post
              Waste of time.
              Maybe for you, but this is great, IMO. Less dependency on XWayland.

              Comment


              • #27
                Originally posted by duby229 View Post

                AMD had a bad reputation for compatibility with games running on wine, but it wasn't their fault, it was actually nVidia's fault. Thank god for Vulkan wrappers, they help remove wined3d from the equation and things are running much, much better on all non-nVidia hardware now.

                I'm just explaining it because it's where a lot of nVidia hate started...
                Actually it was game developers faults for releasing broken games that didn't use OpenGL/DirectX correctly. Nvidia's driver detects certain games on runtime according to their executable signature and then hot patches the game so it runs correctly.

                You can't blame NVidia for this, its the game developers that released their games in a broken state and then didn't fix it (which happens quite commonly). With Vullkan this at least isn't possible, because unlike OpenGL it doesn't have a concept of warnings, if you don't use the Vulkan API correctly than it will just refuse to run so it forces to game devs to code the games properly.

                Comment


                • #28
                  I state that I often use the plasma-wayland session, which is undoubtedly the future, however I find it unbearable those who think that already today we should all use wayland, letting Xorg die. This post is another testament to the fact that Wayland is not ready for the transition yet, not because Wayland is not stable, but because there is still a lot of software that does not have stable support for Wayland yet and wine is the example. , but not the only one. This is an experimental driver only ...

                  Comment


                  • #29
                    Originally posted by mdedetrich View Post
                    You can't blame NVidia for this, its the game developers that released their games in a broken state and then didn't fix it (which happens quite commonly). With Vullkan this at least isn't possible, because unlike OpenGL it doesn't have a concept of warnings, if you don't use the Vulkan API correctly than it will just refuse to run so it forces to game devs to code the games properly.
                    This is a mixed bag. Nvidia supported games have used Opengl incorrect it also does not help that some of the documentation Nvidia wrote on how to use opengl was also wrong. Also AMD and ATI and Intel has also released some wrong documentation on how to use Opengl if you are game developer who follows the wrong documentation your screwed. So its wrong to put it all on the game developers head there have been multi levels of screw ups.

                    Vulkan has the layers system designed in to deal with applications doing the wrong thing in a generic way this is another thing Opengl is missing.

                    Originally posted by mdedetrich View Post
                    Nvidia's driver detects certain games on runtime according to their executable signature and then hot patches the game so it runs correctly.
                    This here is a long term problem. No one bothered with opengl or dx to develop a generic system to deal with these nightmares. This is where vulkan is different with layers. So with Vulkan distributor like valve can directly deal with the problem. This is also some of Valve backing of Zink is so they can directly deal with problems and not depend on the blessing of some video card vendor for the fix. Basically there is a problem with Nvidia solution games not blessed by Nvidia who followed Nvidia incorrect documentation are basically screwed over. Same goes with AMD and Intel as well.

                    Its really simple to forgot with games in a lot of cases we have 3 parties.

                    Video card vendor, Game developer and the Distributor. Video card vendor can patch their drivers, Game creator can patch the source code of game and fix it. Where does this leave the distributor who is selling the games to customers. Valve is Distributor in most cases. Vulkan layer system suites distributors so they can patch a vulkan game doing something wrong with a vulkan layer without the blessing of video card vendor or game developer.

                    There is serous part of the customer base for Nvidia with games that Nvidia is pissing off by not providing what they need or want. Its really important to miss the Distributor who provided games to users is who Nvidia missing what they want to-do. Yes what distributors want todo is be able to provide custom patch work around to badly made games so they can keep on selling them. Yes custom patches without having to beg video card vendors to-do it..

                    Comment


                    • #30
                      Originally posted by Charlie68 View Post
                      I state that I often use the plasma-wayland session, which is undoubtedly the future, however I find it unbearable those who think that already today we should all use wayland, letting Xorg die. This post is another testament to the fact that Wayland is not ready for the transition yet, not because Wayland is not stable, but because there is still a lot of software that does not have stable support for Wayland yet and wine is the example. , but not the only one. This is an experimental driver only ...
                      There is a point to bite the big one. Xwayland does in fact run most wine applications without a problem. Just is horrible slow for Nvidia users because it drops back to software rendering because Nvidia has not provided the libglnvd libraries required. There is very little software at this point that is not either have native Wayland or works Xwayland without a hitch other than Nvidia.


                      This is more a case of Nvidia being a jackass stalling the migration to Wayland by not providing what is need. Yes eglstreams is missing functionality that a Wayland compositor needs to work well. We would have migrated to wayland a lot faster if Nvidia had not been the dominate GPU vendor.

                      Comment

                      Working...
                      X