> >>>>> "Jon" == Jon M Taylor <taylorj@ecs.csus.edu> writes:
>
> 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.
Our divers are still KGI drivers. kgicon lets you use them as
fbcon drivers, but there priary reason for existence is still to be KGI
drivers. kgicon is useful while the new KGI is still being developed.
> 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.
You'll pardon us if we choose to keep our own counsel about that.
> >> 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 ;-(
Quite.
> Basically you are telling us that libGGI will
> never be fast as it can never ustilize accelration - this is a real
> shame.
There exists "suidkgi", which is KGI is userspace which bangs
right on the hardware like SVGALib. It has a LibGGI target. Use that if
you value speed abvoe all else.
> >> >> 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 think kgicon is useless, feel free not to use it. It'll go
in the kernel if/when it goes in the kernel, and until then it works just
fine as modules.
> If you want 100% safety, buy proper hardware, don't try to fix things
> inside the kernel with a sledgehammer.
"Proper" hardware is very rare (and quite expensive) on PCs. AFAIK
the only PC video hardware with true workstation-level features are Targa
truecolor boards. There may be others. It is not acceptable to not
support such a broad range of hardware.
> >> 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.
That "bloat" is usually about 5K.
> >> 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.
LibGGI does not depend on KGI, fbdev or any one other target.
There are about fifteen targets in LibGGI right now, and it builds on
almost every kind of Unix in existence and soon on Windows as well.
LibGGI is meant to be cross-platform.
> 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.
Hey, you guys can do whatever you want with fbcon/fbdev.
> 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.
We have never made a secret of our feelings that KGI is clearly
superior to fbdev and that wie still hope to get it into the kernel
someday. If you wish to regard kgicon as propaganda toward that end,
fine. Its primary purpose is to give people some x86 fbcon drivers and to
let GGI developers use and develop the KGI drivers while KGI is "in the
shop", but if people see how much better KGI drivers are than fbcon
drivers and get some enthusiasm for KGI/GGI as a whole, we certainly won't
complain.
> How are you going to disguise EvStack?
EvStack is called GGI Console now, and it will be so different and
revolutionary that no disguise will be possible.
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