Kernel Mode-Setting, GEM, DRI Progresses On FreeBSD

[phoronix]

Phoronix: Kernel Mode-Setting, GEM, DRI Progresses On FreeBSD

BSD users can be excited this week not only for the release of FreeBSD 8.2, but their open-source graphics stack is finally beginning to catch-up with Linux too. Kernel mode-setting is finally becoming a reality with the FreeBSD kernel and with that support for the Graphics Execution Manager (GEM) memory management under BSD and updating the Intel DRI graphics driver...

http://www.phoronix.com/vr.php?view=OTEzMg

[pingufunkybeat]

Aren't most of the drivers BSD-licensed for this exact reason? I haven't checked everything, but at least the radeon kernel drivers seem to be under a BSD-like license.

Of course, there is still lots of porting to be done, but all the hardware-specific bits are in there, and BSD folks do not have to start from scratch.

[Shining Arcanine]

Phoronix: Kernel Mode-Setting, GEM, DRI Progresses On FreeBSD

BSD users can be excited this week not only for the release of FreeBSD 8.2, but their open-source graphics stack is finally beginning to catch-up with Linux too. Kernel mode-setting is finally becoming a reality with the FreeBSD kernel and with that support for the Graphics Execution Manager (GEM) memory management under BSD and updating the Intel DRI graphics driver...

http://www.phoronix.com/vr.php?view=OTEzMg

The other option is to modify the Radeon and Nouveau drivers to use GEM. At the same time, I think that the code would need to be BSD licensed. While BSD licensed code is compatible with GPL licensed code, the reverse is not true.

Aren't most of the drivers BSD-licensed for this exact reason? I haven't checked everything, but at least the radeon kernel drivers seem to be under a BSD-like license.

Of course, there is still lots of porting to be done, but all the hardware-specific bits are in there, and BSD folks do not have to start from scratch.

I thought it was all GPL licensed.

[kraftman]

Aren't most of the drivers BSD-licensed for this exact reason? I haven't checked everything, but at least the radeon kernel drivers seem to be under a BSD-like license.

I doubt someone waited for bsd to catch up and thus licensed most of the drivers under the bsd license. Most of the drivers are probably MIT licensed.

[allquixotic]

Any source files that live in the mainline Linux kernel are licensed under the GPLv2-Only.

That includes KMS, GEM, TTM, DRM.

The user-space bits' licenses are not as important because the user/kernel separation is a widely recognized boundary across which licenses do not propagate. If FreeBSD does their work correctly, then they can pull libdrm, mesa master, and xf86-video-* with minimal changes there for FreeBSD, and the kernel bits will "just work" behind the ring 0 iron curtain. But if they use any code from the Linux kernel's GPLv2 sources, or even just look at the Linux sources, they could be liable for violating the GPLv2 as well as the copyright licenses of every kernel contributor to the files viewed.

Not sure who would sue them over that, except the SFLC, but it's still a theoretical legal liability, which I'm sure they will avoid. So no copy-pasting convenient parts of the kernel code that work equivalently in BSD kernels. You have to look at the user space interfaces to these components and then figure out how they work, by reading documentation, specifications, ML messages, and the code comments in the userspace libs.

The only other downside is that your typical Linux-focused graphics driver developer (Red Hat, VMware, PathScale and Intel employees) are probably not going to contribute to BSD kernels whenever they bump the user<->kernel DRI2 or libkms interfaces. So the userspace code will change; the updates eventually make their way into BSD distros; and it's up to the BSD graphics stack maintainers to ensure that any ABI bumps have been implemented kernel-side on BSD as well, or else figure out how to use a legacy path (or contribute a legacy path) to the userspace bits.

[some-guy]

Any source files that live in the mainline Linux kernel are licensed under the GPLv2-Only.

That includes KMS, GEM, TTM, DRM.

That is incorrect, they need to be GPLv2 compatible. The MIT/X11 license is GPLv2 compatible.

[pingufunkybeat]

Any source files that live in the mainline Linux kernel are licensed under the GPLv2-Only.

nope.

/*
   2  * Copyright 2008 Advanced Micro Devices, Inc.
   3  * Copyright 2008 Red Hat Inc.
   4  * Copyright 2009 Jerome Glisse.
   5  *
   6  * Permission is hereby granted, free of charge, to any person obtaining a
   7  * copy of this software and associated documentation files (the "Software"),
   8  * to deal in the Software without restriction, including without limitation
   9  * the rights to use, copy, modify, merge, publish, distribute, sublicense,
  10  * and/or sell copies of the Software, and to permit persons to whom the
  11  * Software is furnished to do so, subject to the following conditions:
  12  *
  13  * The above copyright notice and this permission notice shall be included in
  14  * all copies or substantial portions of the Software.
  15  *
  16  * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
  17  * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
  18  * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
  19  * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
  20  * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
  21  * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  22  * OTHER DEALINGS IN THE SOFTWARE.
  23  *
  24  * Authors: Dave Airlie
  25  *          Alex Deucher
  26  *          Jerome Glisse
  27  */

Don't ask me what exactly it is, but it's BSD-like: copyright notice, liability waiver and ability to relicense at wish. I count MIT/X11 under this.

[pingufunkybeat]

I'm referring to r600-specific stuff here.

The KMS core is probably GPL-licensed, but this is so deep inside the kernel that it will have to be reimplemented for each kernel separately. The hardware-specific stuff should mostly be MIT/X11/BSD/whatever licensed, though.

[smitty3268]

So the userspace code will change; the updates eventually make their way into BSD distros; and it's up to the BSD graphics stack maintainers to ensure that any ABI bumps have been implemented kernel-side on BSD as well, or else figure out how to use a legacy path (or contribute a legacy path) to the userspace bits.

The code already implements versioning, so that new drivers are able to work on older kernels without forcing you to update both at once. The BSD devs would only need to bump their kernel code version when they want new features implemented or bug fixes that require the changes.

[icyh]

Well now that FreeBSD is getting support, it should be about time for the linux folks to scrap it and write something new and completely incompatible... like they always do.