[lkml]   [2004]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: New proposed DRM interface design
    We're going to have to work out a GPL/BSD solution for the fbdev
    merge. There are 80,000 lines of code in the fbdev directory. It is
    impractical to rewrite them. It's probably also impractical to
    relicense the fbdev code BSD since we would have to locate all of the

    The proprietary drivers are ok. They don't have to use the GPL
    DRM/fbdev code; nothing stops them from writing their own version. I
    also don't see how a binary driver that links with drm_core and the
    kernel is any different than one that just links to the kernel. GPL
    will stop a vendor from taking the source for drm_core/lib and making
    a private version. But we want to stop that.

    So what do we do about FreeBSD? For example I need to bring in the I2C
    and mode setting code from the GPL fbdev radeon driver into the DRM
    one. I don't want to rewrite a 1,000 lines of working driver code.

    How many DRM users are there on FreeBSD? I've only run into three that
    I know of. I'm sure there are more but is it 1,000 people or 100,000?
    I don't think DRM CVS will even compile currently on FreeBSD. I think
    I broke it a week ago and no one has said anything.

    Would this work? drm/shared and drm/bsd directories are BSD licensed.
    drm/linux is GPL licensed. Any fbdev code I add will go into
    drm/linux. Then we patch up drm/bsd so that is continues to work given
    the changes in drm/linux. The other alternative is simply forking the
    tree. The licenses also allow chunks of DRM to be pulled into the
    fbdev directory but that's effectively a fork.

    The code is starting to drift further from BSD anyway. BSD is missing
    major OS features like hotplug and resource control that Linux DRM is
    starting to use.

    The only rational way we can fix the multiple drivers for the same
    video card is to merge fbdev and DRM functions. The other solution is
    device driver multi-tasking with a 256MB state to be saved on task

    On Sat, 4 Sep 2004 05:52:37 +0100 (IST), Dave Airlie <> wrote:
    > I think we have to remember licensing at all stages of this, the DRM is
    > X licensed, so I don't think we can just merge the fb code, I'm not sure
    > what peoples views on this, the main reason I see for using X licensing
    > is that we can share this stuff with FreeBSD and have an open source
    > graphics interface standard that the chipset designers can use, against it
    > is the fact that it allows for properitary drivers, - I personally don't
    > think we'll ever win that war.. will the prop drivers be derived works of
    > the DRM rather than the kernel anyone got a spare lawyer?
    > Dave.
    > On Fri, 3 Sep 2004, Jon Smirl wrote:
    > > As we work towards the merged DRM/fbdev goal the fbdev libraries are
    > > going to become part of DRM. The libraries will be used pretty much
    > > unchanged as it is the driver code that needs to be adjusted. How does
    > > this play with the new DRM model?
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:05    [W:0.023 / U:15.120 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site