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