Jon> On 13 Aug 1998, Jes Sorensen wrote:
>> >>>>> "Jon" == Jon M Taylor <taylorj@ecs.csus.edu> writes:
>>
Jon> But is has in fact done so, by allowing for driver-specific
Jon> ioctls. That is one thing those ioctls be be used for.
>> Its possible, but it was not the intention.
Jon> Nevertheless, it should work OK. kgicon drivers will
Jon> implement KGI acceleration ioctls as fbcon ioctls, and the LibGGI
Jon> fbdev display target will know how to use those ioctls for
Jon> acceleration.
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.
>> Or something like libGGI.
Jon> LibGGI does not do any direct hardware access. Or did I
Jon> misunderstand you?
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.
>> >> We did not do that on purpose, ioctl == context switch and we >>
>> don't want that.
>>
Jon> direct userspace access to accel registers == unsafe. *I* don't
Jon> want *that*. You can get quite acceptable speed out of ioctls.
Jon> Not the most speed possible, but in most cases that isn't a
Jon> concern.
>> Sorry, tough.
Jon> Well, you already gave us the tool we need to do this.
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?
If you want 100% safety, buy proper hardware, don't try to fix things
inside the kernel with a sledgehammer.
>> If you want to run X on broken hardware then you'll have to take
>> the risk.
Jon> Not really. All I need to do is use fbcon with a kgicon
Jon> accelerated driver, and then run XGGI using the fbdev display
Jon> target. Should work just fine.
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.
>> A context switch is not acceptable here and much worse, it will
>> require you to implement a zillion drivers for acceleration of
>> various chipsets which will lead to unnecessary code bloat.
Jon> The drivers are already implemented - they are the KGI
Jon> drivers. Through kgicon, I can use them with fbcon. No one else
Jon> needs to care about those acceleration ioctls if they do not want
Jon> to, and yet they can be used by usersapce code that knows about
Jon> them. Best of both worlds.
No, you are ruining a valuable resource like libGGI by letting it
depend on something that will hopefully never get included in the
kernel.
Personally I am really sad about this, I thought things were moving in
the right direction with fbdev on the PC now as well, seems
not. According to what you are telling us, you just want to disguise
KGI under abscon and then later use that as an argument to try and
push the `real' KGI into the kernel using the argument that its
already there.
How are you going to disguise EvStack?
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