You can think of me as "Old School", and take my feedback in that context. My main reason for participating in this discussion is to give some historical perspective.
Jon Smirl wrote:
--- Jens Owen <[EMAIL PROTECTED]> wrote:
2) We wanted the bare minimum services in the kernel layer for efficient and fast graphics support, and felt as much of the driver code as possible should stay in user space.
Linux kernel people are strongly in favor of changing Xfree to never touch the hardware except through device drivers. I have to agree with that, Xfree is doing a lot of things that are never going to work in a hotplug system. The only way to make hotplug work is for Xfree to tell the kernel what it is doing.
Six years ago, most devices could not handle this type of restriction efficiently. Things have improved on the high end; but the low end devices, are still very similar to what we had back in the day. Even today, I would be very cautious of deploying an architecture where no devices can be touched from user space. This will really box many driver developers into a corner they can't get out of. Is that worth it for support of graphics pipeline hot plugging? If you would like to get a flavor for the issue I'm writing about, simply unmap the framebuffer from your Mesa-solo 3D driver and give it a go. I think you'll find many difficult issues crop up related to software fall backs and efficient readback pixel data.
3) GPL License. We needed a BSD style license to allow IHV's the option of a closed source driver.
Top proposal right now is to merge FB and DRM. FB has the GPL license with too many developers so it probably can't be converted to BSD.
There are many advatanges to merging FB/DRM. Top ones include SAK, secure attention key, kdbg support, OOPS while X is running, mode support for mesa-solo, etc....
I guess it really just depends on who your target user base is for your architecture. I'm a strong supporter of open source, especially at the infrastructure level; but I have a pragmatic view of IHV's and their need (or perceived need) to withold sources at the module level. If you're not targetting an all inclusive base of IHV's and kernels, then life is much easier for you, and you don't have to worry about the licensing issue.
What is the state of the FB equivalent on BSD?
It's certainly further along than it was in 1998, but I'm not the right person to ask. If you don't make any progress on their kernel lists, contact me directly, and I can put you in touch with my BSD contacts.
--
/\
Jens Owen / \/\ _
[EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado-------------------------------------------------------
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
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
