Re: [Xpert]Video drivers and the kernel
Hi! > (Aside, is this because X uses keyboard in raw mode? would be nice to still > be able to ctrl-alt-del to rebood from console) Anyone know about > using alt-sysrq to restore console? Alt-SysRq-U,S,B. Should work as long as kernel is alive. It is not completely clean shutdown, but will prevent fsck. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xpert]Video drivers and the kernel
Hi! (Aside, is this because X uses keyboard in raw mode? would be nice to still be able to ctrl-alt-del to rebood from console) Anyone know about using alt-sysrq to restore console? Alt-SysRq-U,S,B. Should work as long as kernel is alive. It is not completely clean shutdown, but will prevent fsck. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xpert]Video drivers and the kernel
>(Aside, is this because X uses keyboard in raw mode? would be nice to >still be able to ctrl-alt-del to rebood from console) Anyone know about >using alt-sysrq to restore console? > >So, if the kernel had a card specific module that just knew enough >to put the card back into text mode, or if it used the card's bios >to do it like the int10.a module in XFree 4.0, we would lack for nothing. >(hmm vesafb could be extended?) Working on it. I already have it so you can go from vgacon to /dev/fb and back to vgacon. It is in the works to have vgacon restore the text mode, palette and fonts when switching away from the X server. One of the problems I have seen is under heavy load switching away from X often doesn't restore the text console properly. Vgacon could. This is also handy when the X server dies :-) As for using the card's BIOS. Yuck yuck!! We have other platforms to consider like PPC. PPC is a pretty popular platform. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Video drivers and the kernel
>I was wondering why video drivers are not part of the kernel like every >other piece of hardware. I would think if video drivers were part of the >kernel and had a nice API for X or any other windowing system, would not >only improve performance but would allow competing windowing systems >without having to develop drivers for each. Has anyone thought or >rejected this idea. Hi! Their are two schools of though which I have encountered. One is have everything in userland. The second is have everything in the kernel. Well both are wrong. What is really needed? Proper virtualization of the graphics engine. This means the graphics hardware state is private to each process and no other process can effect another process graphics hardware state. This is all that is needed. DRI attemptes to address this. Will their be more kernel support in the future. Yes if you every want to port high end graphic servers. Here you end up dealing with with pipes on different nodes in NUMA systems. Data is passed from node to node to allow really fast parallel rendering. Note even in this case you don't have the hardware programmed in the driver but only management of the pipe state per process. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Video drivers and the kernel
I was wondering why video drivers are not part of the kernel like every other piece of hardware. I would think if video drivers were part of the kernel and had a nice API for X or any other windowing system, would not only improve performance but would allow competing windowing systems without having to develop drivers for each. Has anyone thought or rejected this idea. Hi! Their are two schools of though which I have encountered. One is have everything in userland. The second is have everything in the kernel. Well both are wrong. What is really needed? Proper virtualization of the graphics engine. This means the graphics hardware state is private to each process and no other process can effect another process graphics hardware state. This is all that is needed. DRI attemptes to address this. Will their be more kernel support in the future. Yes if you every want to port high end graphic servers. Here you end up dealing with with pipes on different nodes in NUMA systems. Data is passed from node to node to allow really fast parallel rendering. Note even in this case you don't have the hardware programmed in the driver but only management of the pipe state per process. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xpert]Video drivers and the kernel
(Aside, is this because X uses keyboard in raw mode? would be nice to still be able to ctrl-alt-del to rebood from console) Anyone know about using alt-sysrq to restore console? So, if the kernel had a card specific module that just knew enough to put the card back into text mode, or if it used the card's bios to do it like the int10.a module in XFree 4.0, we would lack for nothing. (hmm vesafb could be extended?) Working on it. I already have it so you can go from vgacon to /dev/fb and back to vgacon. It is in the works to have vgacon restore the text mode, palette and fonts when switching away from the X server. One of the problems I have seen is under heavy load switching away from X often doesn't restore the text console properly. Vgacon could. This is also handy when the X server dies :-) As for using the card's BIOS. Yuck yuck!! We have other platforms to consider like PPC. PPC is a pretty popular platform. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Video drivers and the kernel
On 14 Feb 2001 01:09:10 -0500, Albert D. Cahalan wrote: > > I was wondering why video drivers are not part of the kernel like every > > other piece of hardware. I would think if video drivers were part of the > > kernel and had a nice API for X or any other windowing system, would not > > only improve performance but would allow competing windowing systems > > without having to develop drivers for each. Has anyone thought or > > rejected this idea. > > Yes. > > So then what, split X, with only the hardware access in the kernel? > This can actually reduce performance, by a small or great amount > depending on how it is done. Stability would improve a bit, assuming > the new drivers have Linux quality rather than XFree86 quality. > The gain is tiny, while the difficulty is large. At least we'd get > a safe and reliable way to print an oops though. This isn't an x86 world. For most other architectures, there *must* be a kernel driver. Check out linux/drivers/video. But what X is doing at this point is taking over access to the video card and using it's own driver. So see, there needs to be no split of X. I could also argue that if video was moved into the kernel in that manner, stability would decrease, but performance could be dramatically increased. > Both options cause political troubles. Currently the X server is > shared with OS/2 and other crummy systems. If the Linux kernel had > serious video drivers for PC hardware, then driver support for the > other operating systems would mostly go away. Linux would become > a better desktop OS, at the expense of various crummy systems. I find this to be a flawed argument. > Both options cause more work for Linus. This totally kills the idea. > See his past postings flaming the GGI/KGI developers. I think GGI/KGI were overkill -- especially at the time. But with the advent of embedded systems, you simply just can't say "use X" anymore. I believe that there needs to be basic 2D acceleration available in kernel space. They already have to be there for non-BIOS architectures, so why not take advantage of them? > If you ever write this, go ahead and throw in the rest. I mean the > window manager, xterm, and a GDK system call even. My hardware can > spare the memory, but CPU cycles are way too scarce. Clean design > can go screw itself when it eats CPU time. Don't worry about being > accepted into the main kernel, because that won't happen no matter > what you do. Have fun hacking, and whip XFree86's ass. Check out GTKFb and Embedded QT. Whip XFree86's ass? But the author was talking about writing kernel drivers *for* Xfree86... You are correct in the fact that this will never happen. But as far as video in the kernel, you are wrong. Brad Douglas [EMAIL PROTECTED] http://www.linux-fbdev.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xpert]Video drivers and the kernel
Please CC me if sending to xpert list. This is a big topic. I think I can contribute a whole two cents worth though... Interesting to note that NT's windowing system moved from being originally in userland to inside the kernel between V3.? and 4.0. Remember mom saying "If your friends all jump off a bridge..." The issue I understand is that context switching kernel<>user slows things down. And then there's trying to make an api... XFree just maps mmio/framebuffer and ioports into it's own address space and bangs the hardware, so it's fast and can do anything. DRI extends this to client 3D code in a sense. Bottom line for me, I don't care; as long as I still can use remote X apps, and Quake3 uses my 3D hardware, I'm happy to have people spend their time improving X how they see fit, and they're done an incredible job so far. My only complaint is when there's a problem with X: It's cool that I can just restart it rather than reboot like windows. (so you can play from console of a server right? :) This is a benefit of it being in userspace. But it would be nice if I didn't have to do it via telnet; sometimes I don't have a box on a network. (Aside, is this because X uses keyboard in raw mode? would be nice to still be able to ctrl-alt-del to rebood from console) Anyone know about using alt-sysrq to restore console? So, if the kernel had a card specific module that just knew enough to put the card back into text mode, or if it used the card's bios to do it like the int10.a module in XFree 4.0, we would lack for nothing. (hmm vesafb could be extended?) > On Tue, 13 Feb 2001, Louis Garcia wrote: > > > I was wondering why video drivers are not part of the kernel like every > > other piece of hardware. I would think if video drivers were part of the > > kernel and had a nice API for X or any other windowing system, would not > > only improve performance but would allow competing windowing systems > > without having to develop drivers for each. Has anyone thought or > > rejected this idea. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Video drivers and the kernel
** Reply to message from "Albert D. Cahalan" <[EMAIL PROTECTED]> on Wed, 14 Feb 2001 01:09:10 -0500 (EST) > Both options cause political troubles. Currently the X server is > shared with OS/2 and other crummy systems. If the Linux kernel had > serious video drivers for PC hardware, then driver support for the > other operating systems would mostly go away. Linux would become > a better desktop OS, at the expense of various crummy systems. First of all, I'm object to calling OS/2 a "crummy system". There are still some things that OS/2 can do better than Linux. But I don't want to get into a flame war. More importantly, just because the drivers move into the kernel doesn't mean that other OS's can't be supported. A video driver could be compiled for the kernel on Linux, but be compiled as something else for other OS's. In fact, on OS/2, a special driver is provided with XFree86 that effectively allows the X Server to run with the same capabilities as an OS/2 device driver. In fact, by strict standards, it's a security and reliability loophole, but it still works pretty well. So I wouldn't worry about OS/2. If we can port your audio drivers, we can port anything. xBSD, on the other hand, -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please direct the reply to the mailing list only. Don't send another copy to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Video drivers and the kernel
** Reply to message from "Albert D. Cahalan" [EMAIL PROTECTED] on Wed, 14 Feb 2001 01:09:10 -0500 (EST) Both options cause political troubles. Currently the X server is shared with OS/2 and other crummy systems. If the Linux kernel had serious video drivers for PC hardware, then driver support for the other operating systems would mostly go away. Linux would become a better desktop OS, at the expense of various crummy systems. First of all, I'm object to calling OS/2 a "crummy system". There are still some things that OS/2 can do better than Linux. But I don't want to get into a flame war. More importantly, just because the drivers move into the kernel doesn't mean that other OS's can't be supported. A video driver could be compiled for the kernel on Linux, but be compiled as something else for other OS's. In fact, on OS/2, a special driver is provided with XFree86 that effectively allows the X Server to run with the same capabilities as an OS/2 device driver. In fact, by strict standards, it's a security and reliability loophole, but it still works pretty well. So I wouldn't worry about OS/2. If we can port your audio drivers, we can port anything. xBSD, on the other hand, -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please direct the reply to the mailing list only. Don't send another copy to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xpert]Video drivers and the kernel
Please CC me if sending to xpert list. This is a big topic. I think I can contribute a whole two cents worth though... Interesting to note that NT's windowing system moved from being originally in userland to inside the kernel between V3.? and 4.0. Remember mom saying "If your friends all jump off a bridge..." The issue I understand is that context switching kerneluser slows things down. And then there's trying to make an api... XFree just maps mmio/framebuffer and ioports into it's own address space and bangs the hardware, so it's fast and can do anything. DRI extends this to client 3D code in a sense. Bottom line for me, I don't care; as long as I still can use remote X apps, and Quake3 uses my 3D hardware, I'm happy to have people spend their time improving X how they see fit, and they're done an incredible job so far. My only complaint is when there's a problem with X: It's cool that I can just restart it rather than reboot like windows. (so you can play from console of a server right? :) This is a benefit of it being in userspace. But it would be nice if I didn't have to do it via telnet; sometimes I don't have a box on a network. (Aside, is this because X uses keyboard in raw mode? would be nice to still be able to ctrl-alt-del to rebood from console) Anyone know about using alt-sysrq to restore console? So, if the kernel had a card specific module that just knew enough to put the card back into text mode, or if it used the card's bios to do it like the int10.a module in XFree 4.0, we would lack for nothing. (hmm vesafb could be extended?) On Tue, 13 Feb 2001, Louis Garcia wrote: I was wondering why video drivers are not part of the kernel like every other piece of hardware. I would think if video drivers were part of the kernel and had a nice API for X or any other windowing system, would not only improve performance but would allow competing windowing systems without having to develop drivers for each. Has anyone thought or rejected this idea. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Video drivers and the kernel
On 14 Feb 2001 01:09:10 -0500, Albert D. Cahalan wrote: I was wondering why video drivers are not part of the kernel like every other piece of hardware. I would think if video drivers were part of the kernel and had a nice API for X or any other windowing system, would not only improve performance but would allow competing windowing systems without having to develop drivers for each. Has anyone thought or rejected this idea. Yes. So then what, split X, with only the hardware access in the kernel? This can actually reduce performance, by a small or great amount depending on how it is done. Stability would improve a bit, assuming the new drivers have Linux quality rather than XFree86 quality. The gain is tiny, while the difficulty is large. At least we'd get a safe and reliable way to print an oops though. This isn't an x86 world. For most other architectures, there *must* be a kernel driver. Check out linux/drivers/video. But what X is doing at this point is taking over access to the video card and using it's own driver. So see, there needs to be no split of X. I could also argue that if video was moved into the kernel in that manner, stability would decrease, but performance could be dramatically increased. Both options cause political troubles. Currently the X server is shared with OS/2 and other crummy systems. If the Linux kernel had serious video drivers for PC hardware, then driver support for the other operating systems would mostly go away. Linux would become a better desktop OS, at the expense of various crummy systems. I find this to be a flawed argument. Both options cause more work for Linus. This totally kills the idea. See his past postings flaming the GGI/KGI developers. I think GGI/KGI were overkill -- especially at the time. But with the advent of embedded systems, you simply just can't say "use X" anymore. I believe that there needs to be basic 2D acceleration available in kernel space. They already have to be there for non-BIOS architectures, so why not take advantage of them? If you ever write this, go ahead and throw in the rest. I mean the window manager, xterm, and a GDK system call even. My hardware can spare the memory, but CPU cycles are way too scarce. Clean design can go screw itself when it eats CPU time. Don't worry about being accepted into the main kernel, because that won't happen no matter what you do. Have fun hacking, and whip XFree86's ass. Check out GTKFb and Embedded QT. Whip XFree86's ass? But the author was talking about writing kernel drivers *for* Xfree86... You are correct in the fact that this will never happen. But as far as video in the kernel, you are wrong. Brad Douglas [EMAIL PROTECTED] http://www.linux-fbdev.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Video drivers and the kernel
> I was wondering why video drivers are not part of the kernel like every > other piece of hardware. I would think if video drivers were part of the > kernel and had a nice API for X or any other windowing system, would not > only improve performance but would allow competing windowing systems > without having to develop drivers for each. Has anyone thought or > rejected this idea. Yes. Problem is, X is a big old wad of code. It wasn't designed to run in a kernel environment. It isn't easy to rewrite, and getting rid of it isn't currently reasonable for normal desktop Linux systems. So then what, split X, with only the hardware access in the kernel? This can actually reduce performance, by a small or great amount depending on how it is done. Stability would improve a bit, assuming the new drivers have Linux quality rather than XFree86 quality. The gain is tiny, while the difficulty is large. At least we'd get a safe and reliable way to print an oops though. Both options could eat some memory. (but NOT anything like the VM size of an X server, much of which is the video memory itself) Putting the whole thing in the kernel does allow for memory pressure hooks though. Both options cause political troubles. Currently the X server is shared with OS/2 and other crummy systems. If the Linux kernel had serious video drivers for PC hardware, then driver support for the other operating systems would mostly go away. Linux would become a better desktop OS, at the expense of various crummy systems. Both options would tend to hurt people who like to leave X running on a low-memory web or NFS server. For a kernel X server, swapping must be done more-or-less explicitly. Both options cause more work for Linus. This totally kills the idea. See his past postings flaming the GGI/KGI developers. If you ever write this, go ahead and throw in the rest. I mean the window manager, xterm, and a GDK system call even. My hardware can spare the memory, but CPU cycles are way too scarce. Clean design can go screw itself when it eats CPU time. Don't worry about being accepted into the main kernel, because that won't happen no matter what you do. Have fun hacking, and whip XFree86's ass. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Video drivers and the kernel
On Tue, 13 Feb 2001, Louis Garcia wrote: > I was wondering why video drivers are not part of the kernel like every > other piece of hardware. See linux/drivers/video and linux/drivers/char/drm in kernel 2.4. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xpert]Video drivers and the kernel
On Tue, 13 Feb 2001, Louis Garcia wrote: > I was wondering why video drivers are not part of the kernel like every > other piece of hardware. I would think if video drivers were part of the > kernel and had a nice API for X or any other windowing system, would not > only improve performance but would allow competing windowing systems > without having to develop drivers for each. Has anyone thought or > rejected this idea. You should drop this subject as it will only result in flame wars. They have in the past and the result is always the same... 1) XFree86 is about the X window system. We don't give a damn about competing window systems. 2) There isn't a single API that can encompass all hardware. 3) Kernel drivers are OS specific things and XFree86 runs on too many platforms so we won't be able to abandon user-space drivers. At least not any time soon. That said, there are fbdev drivers for XFree86 and there are some hardware-specific solutions like NVIDIA's binary drivers. If you want to do something else, that's your perrogative. But don't waste your time trying to get everybody to agree with you. I won't happen. Sorry to be a bit abrupt, but there have been a few other discussions of this nature in the past and it's best that it doesn't go much further. At least not on XFree86 lists. Mark. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Video drivers and the kernel
I was wondering why video drivers are not part of the kernel like every other piece of hardware. I would think if video drivers were part of the kernel and had a nice API for X or any other windowing system, would not only improve performance but would allow competing windowing systems without having to develop drivers for each. Has anyone thought or rejected this idea. Anyway, This was running though my head for a long time and just thought I ask. Lou - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Video drivers and the kernel
I was wondering why video drivers are not part of the kernel like every other piece of hardware. I would think if video drivers were part of the kernel and had a nice API for X or any other windowing system, would not only improve performance but would allow competing windowing systems without having to develop drivers for each. Has anyone thought or rejected this idea. Anyway, This was running though my head for a long time and just thought I ask. Lou - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xpert]Video drivers and the kernel
On Tue, 13 Feb 2001, Louis Garcia wrote: I was wondering why video drivers are not part of the kernel like every other piece of hardware. I would think if video drivers were part of the kernel and had a nice API for X or any other windowing system, would not only improve performance but would allow competing windowing systems without having to develop drivers for each. Has anyone thought or rejected this idea. You should drop this subject as it will only result in flame wars. They have in the past and the result is always the same... 1) XFree86 is about the X window system. We don't give a damn about competing window systems. 2) There isn't a single API that can encompass all hardware. 3) Kernel drivers are OS specific things and XFree86 runs on too many platforms so we won't be able to abandon user-space drivers. At least not any time soon. That said, there are fbdev drivers for XFree86 and there are some hardware-specific solutions like NVIDIA's binary drivers. If you want to do something else, that's your perrogative. But don't waste your time trying to get everybody to agree with you. I won't happen. Sorry to be a bit abrupt, but there have been a few other discussions of this nature in the past and it's best that it doesn't go much further. At least not on XFree86 lists. Mark. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Video drivers and the kernel
On Tue, 13 Feb 2001, Louis Garcia wrote: I was wondering why video drivers are not part of the kernel like every other piece of hardware. See linux/drivers/video and linux/drivers/char/drm in kernel 2.4. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Video drivers and the kernel
I was wondering why video drivers are not part of the kernel like every other piece of hardware. I would think if video drivers were part of the kernel and had a nice API for X or any other windowing system, would not only improve performance but would allow competing windowing systems without having to develop drivers for each. Has anyone thought or rejected this idea. Yes. Problem is, X is a big old wad of code. It wasn't designed to run in a kernel environment. It isn't easy to rewrite, and getting rid of it isn't currently reasonable for normal desktop Linux systems. So then what, split X, with only the hardware access in the kernel? This can actually reduce performance, by a small or great amount depending on how it is done. Stability would improve a bit, assuming the new drivers have Linux quality rather than XFree86 quality. The gain is tiny, while the difficulty is large. At least we'd get a safe and reliable way to print an oops though. Both options could eat some memory. (but NOT anything like the VM size of an X server, much of which is the video memory itself) Putting the whole thing in the kernel does allow for memory pressure hooks though. Both options cause political troubles. Currently the X server is shared with OS/2 and other crummy systems. If the Linux kernel had serious video drivers for PC hardware, then driver support for the other operating systems would mostly go away. Linux would become a better desktop OS, at the expense of various crummy systems. Both options would tend to hurt people who like to leave X running on a low-memory web or NFS server. For a kernel X server, swapping must be done more-or-less explicitly. Both options cause more work for Linus. This totally kills the idea. See his past postings flaming the GGI/KGI developers. If you ever write this, go ahead and throw in the rest. I mean the window manager, xterm, and a GDK system call even. My hardware can spare the memory, but CPU cycles are way too scarce. Clean design can go screw itself when it eats CPU time. Don't worry about being accepted into the main kernel, because that won't happen no matter what you do. Have fun hacking, and whip XFree86's ass. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
