Re: New proposed DRM interface design

[Jon Smirl]

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.

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

On Sat, 4 Sep 2004 05:52:37 +0100 (IST), Dave Airlie <airlied@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/