Announcement

Collapse
No announcement yet.

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

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

  • mSparks
    replied
    Originally posted by Quackdoc View Post
    did you actually look at the src include folder?
    Thats not libdxcore, its a wrapper for it.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by mSparks View Post
    https://lkml.org/lkml/2022/2/5/64

    requires libdxcore. source?
    https://github.com/microsoft/libdxg

    Leave a comment:


  • mSparks
    replied
    Originally posted by Quackdoc View Post

    What do you mean you checked? any evidence? they have a foss kernel, and foss userland.

    also calling BS on ioctls, last time I checked, "one-patch-per-ioctl", does not mean they will be rejected

    https://lore.kernel.org/lkml/[email protected]/
    https://lkml.org/lkml/2022/2/5/64

    requires libdxcore. source?

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by mSparks View Post
    no there isnt a full oss path, i already checked.

    They were also told ioctls would be rejected and its rammed with them.
    What do you mean you checked? any evidence? they have a foss kernel, and foss userland.

    also calling BS on ioctls, last time I checked, "one-patch-per-ioctl", does not mean they will be rejected

    https://lore.kernel.org/lkml/[email protected]/

    Leave a comment:


  • mSparks
    replied
    Originally posted by Quackdoc View Post

    there is now a fully foss stack (linux side) that makes use of this. the main showstoppers right now are just how terrible of a patch series this is, im not talking about the code itself, but just stupid shit, posting the link, just read the various critisims, we won't even know if the patch series is any good for a long time at this rate LOL

    https://lore.kernel.org/lkml/[email protected]/
    no there isnt a full oss path, i already checked.

    They were also told ioctls would be rejected and its rammed with them.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by mSparks View Post
    Yet another press release saying the same thing that was said for the last two years isnt going to change upstreams mind from rejecting trying to bundle closed source dependencies into the linux kernel yet again, they really actually need to do what they were told.

    "upstream can remain stubborn longer than you can retain market share"
    there is now a fully foss stack (linux side) that makes use of this. the main showstoppers right now are just how terrible of a patch series this is, im not talking about the code itself, but just stupid shit, posting the link, just read the various critisims, we won't even know if the patch series is any good for a long time at this rate LOL

    https://lore.kernel.org/lkml/[email protected]/

    Leave a comment:


  • mSparks
    replied
    Yet another press release saying the same thing that was said for the last two years isnt going to change upstreams mind from rejecting trying to bundle closed source dependencies into the linux kernel yet again, they really actually need to do what they were told.

    "upstream can remain stubborn longer than you can retain market share"

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by rabcor View Post
    Why bloat the kernel with a bunch of crap like this that offers no benefits at all to linux users?
    what do you mean no benefit to linux users? are people who run linux on vsphere not "linux users" because they are in a hypervisor too? should we nuke that because it's proprietary? that is ridiculous. not to mention the d3d12 driver people have already contributed to mesa, and the OGL state tracker and have had discussions about the best direction that they and zink can take. so I would really quickly retract that statement if you use zink or opengl, as these two project's are related.

    If microsoft wants this kind of shit, they can just make their own modified linux kernel line or distro like how intel made their own in the form of clear linux. Unless this stuff can somehow be used to benefit Wine, there is no good reason to put this in the kernel.
    I have a good reason, this will be great for hyper-v.

    Originally posted by timofonic View Post
    This is ridiculous, but it's reality.

    Meanwhile, tons of driver issues get unaddressed.

    What about the opposite? Microsoft making a 100% DXG implementation for use in VM.
    what's ridiculous about this, linux implements plenty of hypervisor specific things, should we nuke "vmware" proprietary drivers?

    The issue you guys seem to be having is forgetting that linux is not just a desktop OS. people who run linux in a VM, are linux users too. this is directly beneficial to such people. you can moan about it all you want, but the stance the linux kernel devs have is clear. Linux is for everyone, Mr. Torvalds himself has already stated it. what he cares about is the resulting modification of linux being open source, not the use of it. which is explicitly why he said no to gplv3.

    if you don't like it, you are the ones who don't belong. go use some other gplv3 OS.

    Leave a comment:


  • Michael_S
    replied
    Thanks smitty3268 and
    Quackdoc
    that makes sense.

    rabcor - Microsoft donates $500k/year to the Linux Foundation, which pays for some of the Linux full time contributors. That's probably why their patches are in the main kernel. On top of that, this does benefit the Linux distributions on WSL. Having the features in the main kernel means they don't have to do extra work for people to use these features on WSL. That gives smaller distributions with fewer contributors an easier time supporting WSL.

    Leave a comment:


  • rabcor
    replied
    Why bloat the kernel with a bunch of crap like this that offers no benefits at all to linux users?

    If microsoft wants this kind of shit, they can just make their own modified linux kernel line or distro like how intel made their own in the form of clear linux. Unless this stuff can somehow be used to benefit Wine, there is no good reason to put this in the kernel.

    Leave a comment:

Working...
X