Page 1 of 2 12 LastLast
Results 1 to 10 of 17

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

  1. #1
    Join Date
    Jan 2007
    Posts
    15,646

    Default Kernel Mode-Setting, GEM, DRI Progresses On FreeBSD

    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

  2. #2
    Join Date
    Jun 2009
    Posts
    2,937

    Default

    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.

  3. #3

    Default

    Quote Originally Posted by phoronix View Post
    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.

    Quote Originally Posted by pingufunkybeat View Post
    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.

  4. #4

    Default

    Quote Originally Posted by pingufunkybeat View Post
    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.

  5. #5
    Join Date
    Sep 2008
    Posts
    989

    Default

    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.

  6. #6
    Join Date
    Apr 2008
    Location
    /dev/random
    Posts
    218

    Default

    Quote Originally Posted by allquixotic View Post
    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.

  7. #7
    Join Date
    Jun 2009
    Posts
    2,937

    Default

    Quote Originally Posted by allquixotic View Post
    Any source files that live in the mainline Linux kernel are licensed under the GPLv2-Only.
    nope.

    Code:
    /*
       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.

  8. #8
    Join Date
    Jun 2009
    Posts
    2,937

    Default

    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.

  9. #9
    Join Date
    Oct 2008
    Posts
    3,246

    Default

    Quote Originally Posted by allquixotic View Post
    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.

  10. #10
    Join Date
    Feb 2011
    Posts
    2

    Default

    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •