> >>>>> "linker" == linker <linker@z.ml.org> writes:
>
> linker> On 16 Aug 1998, Jes Sorensen wrote:
> >> Ahhh so thats why as few of you keep running around talking about
> >> kgicon instead of just porting your drivers to become real fbcon
> >> drivers. You have been told a million times here that acceleration
> >> belongs in user space and still you insist on putting it in the
> >> kernel where it does not belong.
>
> linker> I dunno, if it's a loadable module.. Who cares? If were just
> linker> an abstract method of allowing userspace to quickly do
> linker> accelleration it would be better..
>
> It may be simpler for user space application writers, however using a
> library like libGGI or a portable SVGAlib makes more sense from the
> application programmers view, thus he/she doesn't need to know how to
> fiddle with the registers.
If the target is fast, LibGGI is fast. If it is slow, so is
LibGGI.
> As for space I do care - imagine having to do Linux installation
> floppies and having to put 50 video drivers on there which includes
> acceleration code just to get a simple console display ... its bad
> enough with the amount of drivers as it is already.
An XF86_SVGA-style super-driver which could not do acceleration
but could do dumb framebuffering for most video chipsets could be written.
Would that satisfy you? That's basically the way XFree86 is structured.
> linker> The fact remains that PC video hardware is not senceabily
> linker> built and the drivers really need to be in the kernel to do
> linker> accelleration. There are lots of weird issues with trying to
> linker> do accelleration, there is no way a process without all sorts
> linker> of hardware access can do accelleration.
>
> Most cards do X fine in user space as it is now and it works pretty
> well. Having the kernel work as an arbiter telling the library and/or
> processes whether or not they can use acceleration will solve the
> problem.
It works marginally well right now. But, as many people have
mentioned, even now there are DMA/IRQ features of video cards that can't
be used in userspace. These will grow more common in the future. If
Linux can't put those features to good use, it will look bad next to OSes
that can.
> >> And now you are telling us that kgicon is useless and should never
> >> go into the kernel - why do you keep wasting your valuable
> >> resources?
>
> linker> It should go into the kernel, thats the only place it can be
> linker> multiplexed, used fully (irqs,dmas, atomic operations), and
> linker> used safely.
>
> And be slow.
Slow for what? X? Video Games? Video editing? People who want
as much speed as possible are probably game players, and they can use the
suidkgi or SVGALib targets if they want to. People who run X and apps
want GUI acceleration, but they don't need every last drop of efficiency.
For them you need stable, accelerated drivers. Drivers in the OS can be
accelerated. Maybe not as much as to-the-metal usersapce libraries, but
enough to accalerate a GUI with nicely.
> linker> It doesn't waste much valuable resources since it's
> linker> modular.. Unless you think the video driver code should be
> linker> swappable while it's in use.. If it were in user space the
> linker> process using it would have to be mlocked and running with
> linker> root privs..
>
> Ok lets put it another way: A lot of people use older installations
> and are not very much interested in upgrading kernels regularly due to
> the `if it works now, don't try to install something that may break
> something else' strategy. Thus if we tie the whole graphics
> acceleration stuff (which primarily means X) to the kernel it means
> that people will have to run and get new kernels to get the new and
> improved X servers that can run using acceleration on their hardware
> same goes for bug fixes.
Let them continue to use older versions of XFree86. They'll still
have an adequate solution. If it was enough of a hassle, people could
continue to work on developing XFree86 for us with those old kernels.
> So far X has developed parallel to the kernel and people have been
> able to run new X servers with older kernels - using something like
> vesafb will allow this to work in the future, ie. you can continue to
> use your known to be stable kernel to set the video modes and get the
> new accelerated X server when it becomes available. Afaik X servers
> often first become available in a non-accelerated version and later
> comes the smart and improved version.
But what if you don't want to run X?
> linker> Ok fine, I'll take your bet and double it. What PROPER
> linker> hardware can I get for X86 that can do FULL ACCELERATION
> linker> safely from userspace? It would need to have support for
> linker> hardware context switches and be able to get steller
> linker> performance without the use of DMAs or IRQs. AFIK there is
> linker> NONE, and if there it it's not common..
>
> Someone mentioned the Matrox cards, but admittedly I don't know PC
> graphics cards that well. Anyway what I am opposed to is the idea that
> because some PC hardware is broken, we degrade the performance for
> everybody by putting it in the kernel as default (I don't expect
> anybody to seriously want that we have two parallel developments of
> graphics drivers).
Of course KGI would be be a kernel *option*, which anyone could
ignore in favor of the old fbdev. Just like the "old IDE" driver which
was around for so long. This is a strawman. No one wants to force you
to use KGI if you don't want.
> >> But again, you just told us that you want to use kgicon to bloat
> >> the kernel with a ridiculous acceleration API which ought to never
> >> be included in the kernel.
>
> linker> But again, you've wanted us to include various strange network
> linker> drivers in the kernel which never outta be included in the
> linker> kernel. :)
>
> Those you can just decide not to compile in (I asume you are referring
> to the HIPPI stuff) - on the other hand if I want to build something
> generic I need to put in a ton of graphics drivers and the
> introduction of new PC graphics cards on the market seems to be going
> a lot faster than anybody can keep up with.
So use VESA 2.0/vesafb.
> linker> Come on, this isn't a microkernel here. It's monilithic. We
> linker> include HARDWARE drivers in the kernel..
>
> Just because its a hardware driver it doesn't necessarily need to go
> in the kernel.
Well yes actually it does. Userspace isn't designed for running
drivers in. It doesn't have the necessary locking, resource allocation,
or privilege systems. If you want to start adding features to the kernel
to work around these deficiencies, be prepared to turn Linux into a
microkernel OS because that is what you will have done by the time you get
it all nailed down tight.
> >> How are you going to disguise EvStack?
>
> linker> As descent multihead support perhaps? It would be nice to see
> linker> good multihead (/multi console) support on Linux. (yes, I know
> linker> metrox and accelx give you multi head, but what if I want two
> linker> consoles, one with two heads?)..
>
> I thought the EvStack concept was killed on linux-kernel earlier as
> multiheading could be done a lot simpler.
It can be, as fbcon (which can multihead now) shows. But GGI
Console is about a hell of a lot more than just multiheading. It is about
treating the console as a distributed, networked message passing system.
Jon
--- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
- 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.altern.org/andrebalsa/doc/lkml-faq.html