lkml.org 
[lkml]   [1996]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: SVGA kernel chipset drivers.
On Sun, 2 Jun 1996, Bryn Paul Arnold Jones wrote:

> On Sat, 1 Jun 1996, Linus Torvalds wrote:
> >
> > On Fri, 31 May 1996, Albert Cahalan wrote:
> > >
> > > Kernel video is the _only_ complete solution. If you'd like to
> > > discuss this further, please join the Linux GGI mailing list.
> >
> > Sorry. You're wrong.

I beg to differ.

> > The ONLY solution is X, and anything else is just noise. They should be
> > supported, but not at the cost of extra complexity in the kernel.


The complexity you speak of has to go SOMEWHERE, and right now
that is individual X server executables. I do NOT want to be forced to
use X in order to be able to have pixel-level graphics. I don't really
like X all that much, but even that is beside the point. This isn't
really even an X-related issue, because X *should* be higher-level than
the basic video card drivers. Operating systems multiplex hardware
resource access, and if individual user-level programs have to do this
task themselves then IMHO something is wrong. Video output devices just
aren't that different from sound cards, printers, or other standard output
devices that they are somehow unworthy of proper OS control. Besides,
what about the situation with sound cards? Tweaky, non-standard and
complex, and yet they are integrated into the kernel, have /dev/ entries
and IOCTLs, and somehow it doesn't seem to be much of a problem.

The current state of affairs in Linux WRT pixel-level graphics is
a mess. Both SVGALib and the X servers have to be suid root in order to
be able to bang the requisite IO ports directly, which is a security hole
at best and a system-crasher at worst. I can't count the number of times
that X has frozen up and forced me to hit the reset switch to reboot.
Running SVGALib programs in one VC and X in another is always an
adventure, and all of this is because there is no one central authority
arbitrating all of this.

> > End of discussion.

Not really.

> > Linus
> >
>
> I'm sorry to you both, but your both wrong. GGI isn't the only way it
> should be done, and neither is X. Dismissing one, or the other out of
> hand is just small mindedness.

X is not a graphics card API, and of course the GGI isn't the only
way, but we are the only people doing anything about this issue at
present.

> I like X (much better than anything MS have come up with),

X is better than windows, I'll give it that. I still don't like
it. It is a slow, bloated memory hog. I want to be able to write small,
full-screen graphics apps that don't need all the overhead of X to run,
don't have to be suid root, and can be used at the same time as ANY
number of wildly varying types of graphical apps - an have the whole
thing run smooth as glass, like the REST of Linux.

> but I'd also like
> Linux to be more graceful about failing, eg, I keep having to reboot my
> box because I can't see what I'm doing, as a text mode <-> graphic mode
> switch just failed.
>
> GGI would handle such problems (and not just that ;), by knowing what
> the state the video card is, and how to get it back to a sane state,
> and it shouldn't add much (if anything) to the kernel due to the design (a
> generic module, a video card specific module, and the rest in user space
> libs).

It is a good idea to keep the actual graphics primitives in
userspace libraries, true, but unless you want to be stuck with plain-jane
unaccelerated framebuffering a bit more intelligence will be needed. Not
much, just maybe a way to export a list of acceleration ICOTLs that the
userspace libraries can use if present, but something.

> Even though the details are still unresolved, like the various
> /dev files names, and what they should do exactly, Ok, not small things,
> but not the basic ideas either.

Exactly. This needen't cause too much kernel bloat if done
properly, and it really does need to be done. Besides, there's already
quite a bit of video-card-specific code in the kernel, it just deals only
with textmodes. Still, it is a nice example of how taking advantage of
even a little bit of beyond-VGA functionality can add a lot to Linux:

- A standard way to use unused video card RAM as a cache. Impossible
right now due to lack of standardization, but desirable.

- Hugely expanded scrollback buffers that don't die on a VC switch

- The capacity to take advantage of whatever oddball types of acceleration
may go into video cards in the future. DirectX is spurring a quantum leap
in gaming power on PC video cards, and it would be a shame if Linux
couldn't take advantage of that.

What about all the other architectures the Linux now runs on that
have a framebuffer device standard on all machines? Hell, the Amiga and
Mac video architectures don't even HAVE PC-style text-only modes! Without
a standard kernel-level graphics API, those system will each have to do
things their own way, which is a BIG portability hit and means more code
that has to stay in arch/ rather than out in the big mass of
non-hardware-specific linux code.

Kernel video is a Good Thing, folks. It make sense.

Jon Taylor = <taylorj@gaia.ecs.csus.edu> | <http://gaia.ecs.csus.edu/~taylorj>
------------------------------------------------------------------------------
"Everything in excess! To enjoy the flavor of life, take big bites.
Moderation is for monks." - Lazarus Long



\
 
 \ /
  Last update: 2005-03-22 13:37    [W:1.167 / U:0.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site