On Thu, May 06, 2004 at 11:16:39AM -0700, Jon Smirl wrote:
At the X Developers Conference there was a discussion of the issues around
framebuffer and DRI. Theodore Ts'o suggested that I write it up and post it for
discussion. I'm going to try and list all of the issues I've heard from all
sides so some of the proposed solutions are in conflict. The goal of this list
is to provide direction for a topic discussion at the Ottawa Kernel Summit.
[...]
A major topic that I missed in the original list was how to handle BSD. DRM is
under the BSD license and FB is GPL. If these two code bases are merged, what
are we going to do about BSD? I don't know the appropriate BSD lists to post
this to so please forward as necessary.
What is exactly your question concerning licenses?
Another topic that I missed was, why did kgi fail and what can we do to avoid
repeating the same path this time around.
KGI failed to be accepted by linus/linux. You surely don't want repeating this ;)
Otherwise, its design is still valid, I believe.
--
Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--- Nicolas Souchu <nsouch@free.fr> wrote:
quoted
A major topic that I missed in the original list was how to handle BSD. DRM
is under the BSD license and FB is GPL. If these two code bases are merged,
what are we going to do about BSD? I don't know the appropriate BSD lists
to post this to so please forward as necessary.
What is exactly your question concerning licenses?
FB is GPL licensed. DRM is BSD licensed. If FB and DRM are merged the end result
will be GPL licensed code because of the way the licenses work. To change that
you would have to get permission from every FB contributor to relicense their
contribution from GPL to BSD. I suspect that it is pratically impossible to
track all of the FB contributors down and what do you do if some won't
cooperate? If the FB/DRM combo is GPL it can't be merged back into the BSD
kernels. What we could do is build a merged driver and continue to have some of
the source files licensed BSD and some GPL.
The big reason for merging is memory management. If FB supports multiple heads
it is forced into doing memory management. DRI has memory management needs that
go far beyond what FB needs so a merged system has to use DRM memory management.
Ian has made proposals on how to do this and he is working on improving them.
BenH and others have made proposals for pushing the mode setting code into a
user space library in order to reduce kernel footprint and ease debugging. Most
of the code needed for this library already exists in the current Linux FB
drivers. I'm not sure if this could be relicensed BSD when it is moved to user
space.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
What is exactly your question concerning licenses?
quoted
Another topic that I missed was, why did kgi fail and what can we do to avoid
repeating the same path this time around.
KGI failed to be accepted by linus/linux. You surely don't want repeating
this ;) Otherwise, its design is still valid, I believe.
My only complaint about KGI was the driver api was way to complex. I
believe that one of the BSD use it. I forgot which one. The idea of only
universal library never happened. Never will.
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3