Re: [Linux-fbdev-devel] Re: Current discussion about the future of free software graphics
On Tue, May 11, 2004 at 08:30:45PM -0700, Jon Smirl wrote: [...] So moving mode setting to user space is not the end of the world. Everything will still work. This is more like a monolithic vs microkernel type of decision. Which is why Linux is a monolithic kernel, it's by design. The net is plenty of linus' threads about this. -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] http://www.freebsd.org/~nsouch/kgi4BSD --- 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
Re: [Linux-fbdev-devel] Current discussion about the future of free software graphics
On Tue, May 11, 2004 at 01:09:48PM -0500, sottek wrote: [...] Well said! We are all behind you. -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] http://www.freebsd.org/~nsouch/kgi4BSD --- 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
Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
On Mon, May 10, 2004 at 07:28:37PM +0300, Ville Syrjälä wrote: [...] Rendering and mode switching are completely separate issues. Indeed and I guess we can even use the VESA mode setting and the HW engine of recent graphic boards concurrently. The console system is responsible for modesetting regarding the needs of text apps vs graphic apps vs kernel and the current focus. -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] http://www.freebsd.org/~nsouch/kgi4BSD --- 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
Re: [Mesa3d-dev] Re: [Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
On Mon, May 10, 2004 at 11:29:40AM -0700, Jon Smirl wrote: It's not just bloat, the network code is used millions of times per second. Mode setting happens occaisonally. But necessary some times. I think of oops and debugger. The other problem is memory management. What is going to happen when fbdev starts setting the mode for both heads? Who is going to mananage the VRAM when the buffers get resized? OpenGL has a very complex memory management scheme where things can migrate from VRAM to AGP to system memory. Do apps manage their swap? No. I think the OS should be responsible for placing the data (vertices, textures, commands) at the right/best place for the HW 3D engine and the client should only fill virtual memory. -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] http://www.freebsd.org/~nsouch/kgi4BSD --- 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
[Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
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 - [EMAIL PROTECTED] - [EMAIL PROTECTED] --- 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
[Dri-devel] Re: [Linux-fbdev-devel] Redesign of kernel graphics interface
On Thu, May 06, 2004 at 02:42:14PM -0700, Jon Smirl wrote: --- Nicolas Souchu [EMAIL PROTECTED] wrote: 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. But who cares? Do you really intend to keep a common BSD and Linux API/code base? Offering both solutions under BSD and GPL would be good for suggesting correct license usage in the embedded world. GPL is too often bypassed. 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. What is best? Bring modesetting to DRM or memory management to FB? 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. One advantage of true graphic drivers (opposed to VESA or more generally bios modes) is that they can boot some archs in graphic mode (no text mode) without bios. Exactly what linuxfb was originaly designed to. How do you perform this from userspace? -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] http://www.freebsd.org/~nsouch/kgi4BSD --- 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
