Announcement

Collapse
No announcement yet.

Microsoft Posts Updated "DXGKRNL" Linux Kernel Driver For WSL/WSA

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

  • Microsoft Posts Updated "DXGKRNL" Linux Kernel Driver For WSL/WSA

    Phoronix: Microsoft Posts Updated "DXGKRNL" Linux Kernel Driver For WSL/WSA

    Microsoft continues work on their controversial "DXGKRNL" driver they hope to mainline into the Linux kernel for benefiting their Windows Subsystem for Linux (WSL) and Windows Subsystem for Android (WSA) efforts...

    https://www.phoronix.com/scan.php?pa...oft-DXGKRNL-v2

  • #2
    I'm not sure why people think this controversial. It's much better than having no driver, or *ahem* a binary blob. If this wasn't Microsoft, no-one would even notice.

    If it bothers you, just disable/delete the module. Job done (well, there are probably a bunch of other modules you'll want to disable too realistically...)

    Comment


    • #3
      Originally posted by OneTimeShot View Post
      I'm not sure why people think this controversial. It's much better than having no driver, or *ahem* a binary blob. If this wasn't Microsoft, no-one would even notice.
      Because people can't stand companies that they are personally morally opposed to contributing to the Linux kernel even though according to GPL 2.0 there is no legal difference.

      Comment


      • #4
        Originally posted by OneTimeShot View Post
        I'm not sure why people think this controversial. It's much better than having no driver, or *ahem* a binary blob. If this wasn't Microsoft, no-one would even notice.
        Exactly. They actually did this exactly how I would have wanted them to. In fact, WSLg uses Wayland's Weston over RDP, and I was already using the same thing for a desktop under WSL before it was even announced. They just made it very much better. It was also fantastic to see them talking about the approach at XDC. I really enjoyed those sessions.

        I now use Xpra instead, but only because I use the graphical applications remotely from a different system. Weston allows that too, but Xpra is faster over a remote link.

        Comment


        • #5
          just merge the oneAPI without directx.

          Comment


          • #6
            Why does this thing has to be in the kernel repository?

            The way I see it, it is a solution used on a specific Microsoft product and maintained by Microsoft people.

            It is not that I am fundamentally against it or anything.. I just wonder..

            Comment


            • #7
              basically, if DXGKRNL get mainlined, the easiest way to have a fully accelerated 3D linux system will be to run WSL, right?

              I hate to admit that Microsoft is playing a very good strategy.

              Comment


              • #8
                Originally posted by cynic View Post
                basically, if DXGKRNL get mainlined, the easiest way to have a fully accelerated 3D linux system will be to run WSL, right?

                I hate to admit that Microsoft is playing a very good strategy.
                I don't think anyone willing to use WSL cares a lot about what's the easiest way to have a fully accelerated 3D Linux system. If you go for native Linux it's most likely because, for one reason or another, you wanted to avoid Windows in the first place. For those using WSL acceleration in the Linux subsystem is pretty much just a bonus IMO.

                Originally posted by zoomblab View Post
                Why does this thing has to be in the kernel repository?

                The way I see it, it is a solution used on a specific Microsoft product and maintained by Microsoft people.

                It is not that I am fundamentally against it or anything.. I just wonder..
                Essentially, it makes maintenance easier (no tracking of multiple kernel versions due to changing interfaces, no delay for support) and deployment as well in case arbitrary distros are allowed (I have no idea if that's the case).

                Originally posted by OneTimeShot View Post
                I'm not sure why people think this controversial. It's much better than having no driver, or *ahem* a binary blob. If this wasn't Microsoft, no-one would even notice.

                If it bothers you, just disable/delete the module. Job done (well, there are probably a bunch of other modules you'll want to disable too realistically...)
                You're thinking like a user here. Merging any kind of code in mainline means extra work for developers. That's why, by default, nobody wants your code. You need to make a point why it's actually a good tradeoff. If kernel developers and their clients (as in, the ones who actually do pay) don't use WSL2, would they care whether there is no driver, a binary blob or some other thing? I guess no. So the disabling, deleting, etc, of modules doesn't really cut it.

                That said, I think it's a good thing that you're right on people just being anti-MS. I don't think devs will refuse the patch, and those putting the hours get to decide what gets in. Everything else is, IMO, pure entitlement.

                Comment


                • #9
                  Originally posted by cynic View Post
                  basically, if DXGKRNL get mainlined, the easiest way to have a fully accelerated 3D linux system will be to run WSL, right?

                  I hate to admit that Microsoft is playing a very good strategy.
                  How dare you... Stop right there, return to the "not learning anything and not forgetting anything" state!

                  Comment


                  • #10
                    Originally posted by zoomblab View Post
                    ... The way I see it, it is a solution used on a specific Microsoft product and maintained by Microsoft people ...
                    This could be said about almost all Kernel drivers out there...
                    In the same sense you could say, why GPU drivers are embedded in the kernel, they're used on specific products, and maintained by their respective vendors.

                    Comment

                    Working...
                    X