lkml.org 
[lkml]   [1999]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectIt's done right.. don't change it. Re: [OFF-TOPIC] Re: Linux Graphics Architecture (format fixed)
Hello folks, 

There was a time people would crash the console simply by switching in and
out of X a few too many times to a TEXT console. I'm quite happy now that
the kernel is handling that now, the calls of "Gerhard the computer broke
again" or finding evidence of somone cycling the power in the logs were
down right aggravating. I'm essentially very lazy and prefer to spend my
time tweaking the system (when I feel like it) and don't like the work
involved in dealing with fs damage caused by a power cycle while something
was writing to disk.

My problems satsfatorally solved by the fb handling the mode switching,
the old way of having whatever device wanting to use anything other than
text mode handle it's own switching was down right stupid and the result
was quite nasty on my system.

Several months ago I flamed several people on this list out of
frustration, to the point of using harsher words than I should have.
I am happy to say the problems are now fixed on my system, I care very
little that the kernel driver doesn't do accelleration, in fact I don't
care much at all about the short term speed loss while I wait for an x
driver that uses fb for mode changes and does accelleration directly.

To summarise: I don't want to go back to the old way, it works fine now,
please don't try breaking it again. The kernel seems to be doing just
enough work to make the system run exremely well.


Gerhard

PS I now only reboot for kernel changes. :)

Good job folks!!!!!!
On Mon, 8 Feb 1999, Paul Jakma wrote:

> On Mon, 8 Feb 1999, Shawn Leas wrote:
>
> You still want to go the way of DOS. I remember downloading a JPG
> veiwer called QPEG, and it had video drivers bundled with it.
>
> Sounds a little like X, eh?
>
> then again, use the right tool for the right job, and don't let
> principles get in the way of practicalities.
>
> Is the hassle of implementing full-blown, accelerated, concurrent
> access, graphics drivers in kernel worth the effort?
>
> how many people really need to have several processes
> concurrently writing to the graphics hardware? As it stands i can
> think of only two: X and a direct render graphics layer - which
> would have to co-operate with each other to be of practical use
> anyway.
>
> [X is the de facto UNIX graphics standard for the foreseeable
> future, for better of worse. {better imho}.]
>
> If it was for a single platform with a reasonably limited range
> of graphics hardware - then maybe yes. But for an OS that covers
> so many platforms? and those platforms cover how many weird and
> wonderful different graphics hardware?
>
> And which cards are capable of what? How do you present a uniform
> interface? How would a uniform, rich, in-kernel, 3d & graphics
> implementation run on my P133 with Trident TGUI graphics card?
> Keep it too simple and you're wasting the more exotic hardware.
>
> So perhaps it's best to let the kernel stick to a limited
> knowledge of the graphics hardware, so that it can always
> clean-up if needs be. And let the higher level stuff sort it out
> between themselves as to what they want to do.
>
> If needs be, some basic functions can always be migrated from the
> higher level into the kernel. but let X and co worry about
> concurrency and arbitration and things like that. The kernel has
> enough of that kind of stuff to worry about already.
>
> Eg, DEC faced this issue when they tried to go head to head with
> SGI with their PowerStorm graphics card. Their solution was to
> implement direct rendering with the X server handling concurrency
> issues. X can then arbitrate between multiple X protocol and
> direct render clients, as it sees fit. Only that with direct
> render clients the X server doesn't need to do any rendering
> work, the direct render client and the X server just need to set
> things up via the X protocol.
>
> X is already an arbitrator, why reinvent the wheel when it can
> just be extended to arbitrate between more types of clients?
>
> (Direct render clients can be anything by the way. Doesn't have
> to be OpenGL.)
>
> This way, we keep a standard and already uniform graphical
> interface, X. And we can write extensions to it to support a
> uniform high-performance graphics layer, "direct render" for more
> advanced graphics cards. And we don't clutter the kernel with
> highly complicated code that could run in user-space.
>
> [eg: why can't the kernel do sound mixing? - so that 2 or more
> processes could write to /dev/dsp concurrently and produce a real
> mixed sound? the implementation itself exists.....]
>
> regards,
>
> Paul Jakma.
>
> (perhaps this thread should be on another list.).
>
> --
> Paul Jakma paul@clubi.ie
> PGP5 key: http://www.clubi.ie/publickey.txt
> -------------------------------------------
> Fortune:
>
> [FORTRAN] will persist for some time -- probably for at least the next decade.
> -- T. Cheatham
>

--
gmack@imag.net

As a computer I find your faith in technology amusing.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site