> 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.
I dunno, if it's a loadable module.. Who cares? If were just an abstract
method of allowing userspace to quickly do accelleration it would be
better..
The fact remains that PC video hardware is not senceabily built and the
drivers really need to be in the kernel to do accelleration. There are
lots of weird issues with trying to do accelleration, there is no way a
process without all sorts of hardware access can do accelleration.
> 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.
No, he's saying that people who dont wish to use accelerated drivers with
libGGI can never have acceleration on the current FBCON driver. You could
write your own libggi target that banged the hardware and got acceleation.
> 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?
It should go into the kernel, thats the only place it can be multiplexed,
used fully (irqs,dmas, atomic operations), and used safely.
It doesn't waste much valuable resources since it's modular.. Unless you
think the video driver code should be swappable while it's in use.. If it
were in user space the process using it would have to be mlocked and
running with root privs..
Furthermore, the dumb frame buffer and the acceleration parts could be in
seperate modules (they might already be I havn't used kgicon, of KGI in a
long time).. You only get the acceleration functions loaded if you use an
accelerate app..
> If you want 100% safety, buy proper hardware, don't try to fix things
> inside the kernel with a sledgehammer.
Ok fine, I'll take your bet and double it. What PROPER hardware can I get
for X86 that can do FULL ACCELERATION safely from userspace? It would need
to have support for hardware context switches and be able to get steller
performance without the use of DMAs or IRQs. AFIK there is NONE, and if
there it it's not common..
> 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.
But again, you've wanted us to include various strange network drivers in
the kernel which never outta be included in the kernel. :)
Come on, this isn't a microkernel here. It's monilithic. We include
HARDWARE drivers in the kernel..
Does soundmodem need to be in the kernel? It needs to be there less then
the acceleration stuff!
Soundmodem coulde be done with a userspace daemon which uses a slip link
(ala diald) and talks to /dev/dsp. Though it prob wouldn't work on
anything less then a PII 300.. It's just a performance hack having it in
the kernel and it adds alot of code. But you and I just dont compile it
in, so we dont care.
kgicon accelleration is much more then just a performance hack (though
it's that too) and if you dont want it then dont use it..
>From what I've seen libggi gives you TONS of choices.
> How are you going to disguise EvStack?
>
> Jes
As descent multihead support perhaps? It would be nice to see good
multihead (/multi console) support on Linux. (yes, I know metrox and
accelx give you multi head, but what if I want two consoles, one with two
heads?)..
-
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