I'm afraid this discussion has decided it must happen somewhere -- I'd
really rather it not be on linux-kernel, since it gets in the way of more
immediately important kernel development traffic, but it seems enough people
find the merits/demerits of KGI significant to the kernel's future that
we're kinda stuck here. Either KGI is a good idea, in which case kernel
inclusion is important, or it's a very bad, wasteful idea, in which case it
really shouldn't be included.
> Peter-Paul Witta <paul@ping.at> wrote:
> > *) X is somehow monolithic and not modularized enough. there are many
> > options, GLX, DGA, Xmitshm, and "standard X" - and, last but not
> > least, XAA. some of this options can be demand loaded, some cannot.
>
> This is an implementation detail, not an architectural implication.
True. It's one X is going to become more burdened with, now that X11R6.4 has
arrived, though... good architectures can be broken by poor implementations.
> > *) X should be as fast as SVGALib using DGA, shouldn't it? DGA is
> > AFAIK full screen with accelerated bitmap access.
>
> I don't know about DGA.
IIRC, DGA requires root access on the part of the client (the X server
simply gives the DGA client an offset into /dev/mem, and the client is
responsible for actually mmapping it), since it needs to mmap /dev/mem to
get at the framebuffer ... from there, we get back to mostly the same
problems as in SVGALib.
> > *) most people do even play doom, quake, or other high performance
> > games windowed using local X.
>
> No.
>
> Either they play the games unwindowed, or they play them using local X.
Unwindowed (that is, direct to the hardware instead of through a windowing
system) is always at least slightly faster. I don't really have many
complaints about X, except that most of the implementations I've used have
seemed a little to unstable for something that has root access, and that X
really isn't suited to full screen applications like most games. Plus, for
those types of uses, X usually means an awful lot of uneccesary overhead.
Like it or not, it's big, and that's one aspect of X that is impossible to
fix (and besides, we really do need that functionality when running GUI
apps, so wrt GUI apps, it's not that broken)
> > *) local X is somewhat not as fast as it could be
>
> This is mostly an issue of card support, as I understand it. There's
> plenty of room for improvement here.
Yeah, pretty much, although IIRC, DGA apps really don't have any good way to
access acceleration at all anyway.
> > *) console-switching is not completely handled in kernel space
>
> Yes, but this statement is almost content-free.
Yeah, that was rather ambiguous. He might have been referring to the kernel
relying on the X server to take over some aspects of console switching... I
have been rather frustrated sometimes by the inability to switch consoles
when my X server hangs ... thank God for serial ports ...
X does fine for me for GUI apps, though; although none of the X
implementations I've seen so far is completely stable, that's not to say a
stable X implmentation is impossible (as Linus points out). The size and
complexity of X just make that task a little more difficult.
> > *) GGI takes over handling. KGI does cosnole switching, GGI does
> > accelearation in userspace(??).
>
> Sortof.
As much functionality as is possible ends up in userspace ... if anything at
all related to acelleration gets put in the KGI side, it's only to wrap
insecure hardware functions that an unpriveleged user could use to hang or
even damage the hardware. Some cards are so poorly designed that they mix
secure and dangerous registers closer than mmap() granularity can separate
them, preventing them from being mmap()ed through...
> > *) GGI would perform as fast as X with DGA(??)
>
> Currently, X is faster than GGI.
For what uses? And specifically, what were you comparing?
Not poor currently unaccelerated XGGI with an accelerated XFree86 server, I
hope? :)
> > *) GGI would be like X with DGA and console switching completely done
> > by the kernel.
>
> No.
>
> GGI would be like SVGALIB, except GGI programs could run under X as well
> as on the console. Then again, presumably you could write an SVGALIB
> which would let programs run under X as well?
Ehh... not really. I suppose SVGALib is a slightly better comparison than
DGA, though.
It might help to separate out the independent sub-components of the GGI
project somewhat, if we are going to keep on discussing this here.
LibGGI - user space library, runs on top of X, SVGAlib (although to run on
top of SVGALib, it'd need root, unlike the other targets), KGI, and
assorted other targets (work on an fbcon target has begun, too).
LibGGI really doesn't need KGI, even though it supports it.
KGI - the kernel stuff we're all fighting over :) basically just wraps
security-sensitive graphics functionality and exports the rest through
to userspace as directly as possible
EvStacks - really sort of a misnomer, unfortunately. it's basically just
an extremely modular console/input device system that allows
good multihead support, a compatibility layer for the old Linux
behavior, and the ability to move a lot of that sort of thing
into user processes, if you wanted to. It's really a subject for
a whole other post, though.
Kind of the point of EvStacks was to aid in a compatibility layer
and to have a way to logically deal with input focus in a
multiheaded setup (i.e. one keyboard, three monitors)
> > *) AFAIK fbcon is like X with console switching done by the kernel?
>
> No.
>
> For example, fbcon doesn't deal with mouse issues (focus, ...). fbcon is
> Fa mechanism for stuffing pixels onto the screen.
Yep. fbcon does basically what KGI does, although it doesn't support
accelleration, nor a modular driver architecture. (to my knowledge -- I need
to take a better look at it). Anyway, fbcon drivers could probably become
KGI drivers extremely easily.
> > *) GGI would require the linux team to get accelerated graphics
> > drivers. now the X team handles this. does the linux team have enough
> > manpower to over-take this work as well???
>
> Actually, this would probably be the GGI team, since the drivers would
> still be in user space.
There'd be userspace stubs for various drivers, which would definitely be
maintained by the GGI folks. For most cards, that code would represent the
bulk of the work -- little if anything extra would have to go in a kernel
driver module. Drivers for specific cards are in kernel modules, but they
could still easy be maintained separately. Stock KGI is relatively simple,
and unlikely to change too much once complete, so it shouldn't be a very big
headache to maintain.
Another nice aspect of the KGI driver modules is that they're broken up into
drivers for individual components of the card (i.e. clock, RAMDAC, etc...),
so supporting a new card can sometimes be just a matter of mixing and
matching existing driver modules.
Also, it is important to note that emulation of acceleration features not
supported in the hardware goes in the userspace end of things, LibGGI, and
not KGI. That's really the only reason the KGI code can get away with
being as small as it is.
> > (i left out stuff like console pairing, multiple keyboards, multiple
> > mice and so on on the ggi side. i don't believe this would affect many
> > users. multilple screens is more interesting, but this can be relized
> > with X too.)
>
> Presumably all of it could be dealt with in X. However, there are some
> things which have been included in the X standard which aren't supported
> by XFree86, and there are some things that would have to be added to the
> X standard.
>
> There's a lot of graphic talent on the GGI team, I wonder what would
> happen if they started hacking on X.
We're doing that too, with XGGI. Sadly, XGGI isn't accellerated yet, only
because we don't have enough people with a good enough understanding of X
internals to implmement the X acceleration framework on top of LibGGI.
Because of the X LibGGI target, XGGI also has the unusual (although not
entirely unique, as I understand it) ability to run nested within other X
servers, including itself.
-=MenTaLboY=-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu