Re: New proposed DRM interface design

From: Dave Airlie (airlied_at_linux.ie)
Date: 09/04/04

  • Next message: Axel Suppantschitsch: "Serious e1000 timeout problem with kernel 2.6.8-1.521" 
    Date:	Sat, 4 Sep 2004 08:52:00 +0100 (IST)
To: Jon Smirl <jonsmirl@gmail.com>

    > 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
    > coders.

    Well I've been thinking we'll need to rob a lot of code from X11, a fair
    bit of code in fbdev is taken from X anyways.. I'm not so sure it
    wouldn't be that hard to move the rest...

    From what I can see we make the core in-kernel and library sections under
    BSD and then the driver can probably choose their license... I just think
    this work is pretty ugly work and I would hate for another OS to have to
    go do it again from scratch just because we decided to use GPL, I would
    also like to make the interface as standard as possible.. (maybe ReactOS
    could port it to Windows :-)

    > 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

    All the current code is X licensed, I think we should try and get code
    from X where we can and if not maybe ask fb people about it ..

    > 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.

    But the future isn't set in stone, if BSD gets these features this
    statement is insigificant...

    > 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
    > swap.

    For the cards the DRM supports, we could just reimplement the fb
    functionality, the only card I'm aware of that really matters is the
    radeon, there is no fbdev for i830/915 (I'm going to do one under the BSD
    license when time permits, Dave Dawes did one half in half, part GPL part
    BS but it was for 2.4 and he's abandoned it now .. the mach64 fb doesn't
    work very well (my mobility chip craps it out..).. maybe the matrox is
    another useful one, we probably should work on a dmacon interface rather
    than fbcon, again this isn't obvious yet what we do...

    Dave.
    >
    > On Sat, 4 Sep 2004 05:52:37 +0100 (IST), Dave Airlie <airlied@linux.ie> 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?
    >
    >
    > -------------------------------------------------------
    > This SF.Net email is sponsored by BEA Weblogic Workshop
    > FREE Java Enterprise J2EE developer tools!
    > Get your free copy of BEA WebLogic Workshop 8.1 today.
    > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
    > --
    > _______________________________________________
    > Dri-devel mailing list
    > Dri-devel@lists.sourceforge.net
    > https://lists.sourceforge.net/lists/listinfo/dri-devel
    > 

    -- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
  • Next message: Axel Suppantschitsch: "Serious e1000 timeout problem with kernel 2.6.8-1.521"

    Relevant Pages

    • Re: New proposed DRM interface design
      ... > pieces of the existing fbdev code to DRM in order to implement printk ... permission to put it under a less restrictive license. ... gave that permission for his components of the matroxfb code. ...
      (Linux-Kernel)
    • Re: OpenGL-based framebuffer concepts
      ... devices to userspace via sysfs, though I don't know if there is a good ... Load an fbdev driver and look in sysfs. ... Plus there is no guarantee that BSD ... will even use your code if you keep the license clean. ...
      (Linux-Kernel)
    • Re: New proposed DRM interface design
      ... >> the BSD license and turn it into GPL. ... Then how am I going to merge fbdev and DRM so that we don't have two ...
      (Linux-Kernel)
    • Re: New proposed DRM interface design
      ... There are 80,000 lines of code in the fbdev directory. ... and mode setting code from the GPL fbdev radeon driver into the DRM ... How many DRM users are there on FreeBSD? ... > I think we have to remember licensing at all stages of this, ...
      (Linux-Kernel)
    • Re: OpenGL-based framebuffer concepts
      ... fbdev-chip depends on fbdev-core ... RIght now drm and fbdev can be loaded independently. ... I will not accept patches to make DRM drivers rely on fbdev drivers in ...
      (Linux-Kernel)