Re: [Xpert]Video drivers and the kernel

Re: [Xpert]Video drivers and the kernel

[Pavel Machek]

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.

Video drivers and the kernel

[Louis Garcia]

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 

Re: [Xpert]Video drivers and the kernel

[Mark Vojkovich]

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.
   

Re: Video drivers and the kernel

[Jeff Garzik]

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

Re: Video drivers and the kernel

[Albert D. Cahalan]

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

Re: Video drivers and the kernel

[Timur Tabi]

** Reply to message from "Albert D. Cahalan" <acahalan@cs.uml.edu> 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 - ttabi@interactivesi.com
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.

Re: [Xpert]Video drivers and the kernel

[Jeremy Jackson]

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.

Re: Video drivers and the kernel

[Brad Douglas]

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
brad@neruo.com
http://www.linux-fbdev.org

Re: [Xpert]Video drivers and the kernel

[James Simmons]

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