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.
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.
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.
>> I had the impression that people had finally realised the
>> acceleration belongs in user space and were now porting libGGI to
>> use this - seems like I was wrong ;-( Basically you are telling us
>> that libGGI will never be fast as it can never ustilize accelration
>> - this is a real shame.
linker> No, he's saying that people who dont wish to use accelerated
linker> drivers with libGGI can never have acceleration on the current
linker> FBCON driver. You could write your own libggi target that
linker> banged the hardware and got acceleation.
Same thing, no difference.
>> 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.
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.
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.
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).
>> 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.
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.
>> 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.
Jes
-
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