Messages in this thread | | | Date | Sun, 5 Apr 1998 16:05:22 -0400 (EDT) | From | MenTaLboY <> | Subject | Re: SUMMARY: GGI/X : the other way?? |
| |
On Sun, 5 Apr 1998, Raul Miller wrote: > linux-kernel is the wrong list for this. Then again, there doesn't seem > to be a correct list (X lists and GGI lists would also consider this > outside of scope).
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
| |