management
Hi there! My ftp access to ibiblio works ok and the http server config suits my needs. However, I won't change anything officialy before I get 1) cvs access, and 2) pop or imap or whatever access to the [EMAIL PROTECTED] mailbox. I can keep asking to Emmanuel and Steve, but there are desparately quiet. So I'd really like to know who manages this. Can't the guys at ibiblio or anybody else do something about it? Another topic : docs. I would suggest to use a tool like doxygen. It makes the code easier to read and the API documentation easier to maintain. Of course user doc, FAQs and HOWTOs are still necessary. Thoughts? Regards Eric.
Re: EVAS - A better acceleration model?
Quoting Jim Peters [EMAIL PROTECTED]: Jason McMullan wrote: The main difference between EVAS and GGI hardware acceleration is that GGI draw objects, and EVAS manages objects. I had a look at EVAS. it looks quite nice but it seems to much bound to a mixture of X, Open GL for X and imlib2... which doesn't look very promising for genericity.
Re: problem with dlopen - no: with disfunctionnal brain...
Quoting Xavier Hienne [EMAIL PROTECTED]: r=calloc(sizeof(*r),0); should be r=calloc(1, sizeof(*r)); shame on me! It's really strange that a call to calloc with a 0 argument returns a valid value (i.e. not NULL)... This call corrupts your heap and it makes [cm]alloc segfault some time later during ggiOpen. libc bug ? No, I should have checked errno value instead of return value... And above all, I should have read the man with opened eyes! Anyway thanks...
Re: EVAS - A better acceleration model?
Quoting Jason McMullan [EMAIL PROTECTED]: I've been considering working on EVAS as a rendering engine for the Display PS section of GNU OpenStep. Although it doesn't handle all cases (stippled lines, etc), it should be a good speedup compared to the current DPS model (redraw everything, IIRC). Did you have a look at libart? The rendering model is pretty well suited to implement postscript over. And it provides a lightweight microtile array structure dedicated to mark regions that needs to be updated. This could be used to write a scene graph render. The only thing is to glue the different components of the API together. Actually, a 2D shoot-em-up is the perfect example of a good use of a scene-graph architecture. Just put all the ships, bombs, enemies, etc. in the scene graph as `hidden' objects, and move them into position as required. Please see the `evas_test' demo that comes with the EVAS package. It's a pretty good example of everything you'd want to do in a shoot-em-up. That's very true. i shot myself! The best part of a scene graph is the fact that the renderer of the scene graph can take care of all the hardware acceleration presented to it. Using a jump-table override system like GGI, along with an acceleration hints system (argh. DirectX argh.) the renderer would be able to self-optimize for the hardware features available. I think it is basicaly the idea behind libbggi3d: abstract a rendering pipeline, then the renderer try to make use available accelerations to optimize things. No need for each app developer to attempt to reinvent the wheel. No, but I wonder if rasterman is not the kind of guy who likes to do so. Regards.
problem with dlopen (?)
hi all!
I experience strange crashes with programs I'm working on, and
I strongly suspect that this has something to do with the dynamic
code loading process.
I'm working on a modular image loader based on libgffd, which dlopens
drivers. When I test without linking with ggi it works ok. If I link with
ggi to load into a visual it segfault badly.
If I create the visual first, my code crashes when I call a dlsym'ed function,
and if I call my dl code first, it works well but ggi crashes on ggiOpen
GGI debug doesn't go beyond:
LibGII: Debugging=255
LibGGI: Debugging=255
LibGGI: ggiOpen("(null)") called
LibGGI: ggiOpen("x") called
Segmentation fault
Am I completely missing something about dlopen?
gdb trace:
Program received signal SIGSEGV, Segmentation fault.
0x4008426a in malloc () from /lib/libc.so.6
(gdb) bt
#0 0x4008426a in malloc () from /lib/libc.so.6
#1 0x40085935 in calloc () from /lib/libc.so.6
#2 0x40029b1c in _ggiNewVisual () from /usr/local/lib/libggi.so.2
#3 0x40025be1 in ggiOpen () from /usr/local/lib/libggi.so.2
#4 0x40025b19 in ggiOpen () from /usr/local/lib/libggi.so.2
#5 0x80491a4 in main ()
#6 0x40045577 in __libc_start_main () from /lib/libc.so.6
Re: EVAS - A better acceleration model?
As far as I understand, EVAS defines a scene graph oriented rendering model. It's purpose is pretty much different from GGI's, and I would not call it 'better'. It's just a higher level display abstraction. I haven't checked EVAS and know nothing about it, but the problem I see is if rasterman defined his own rendering primitives and graph structure, how can he be sure that his model will fit well in every hardware or formal specification. I'm not only talking about primitives, but more importantly how you access and modify elements in the scene. Moreover this model is not handy in every situations (a good ol' shoot 'em up game). If he needs to add lower level access, the API has a good chance to become bloated. I think this kind of functionnality would rather can be added later to ggi via its extension system (see for example the libggi3d project). You could implement such a model by maintaining a SVG graph. Now the problem is to get hardware acceleration nicely. my 2 cts. Steffen probably has better thoughts on this since the scene graph concept is used in Berlin. I think it's used in Apple MacOsX too (aqua). Eric.
Re: QUO VADIS
Quoting "Jon M. Taylor" [EMAIL PROTECTED]: Probably the best thing you could do at this point is to get administration rights to the GGI SourceForge project and move our CVS, FTP and Eric's new web pages over. We need a properly functioning project management infrastructure, badly. It's really too bad we got stuck like this, since we had a 'virtually' working solution at ibiblio. I don't really like the idea to step right into the sourceforge mold, but it's obviously appealing. Ok so here is my wishlist (priority order) - I need to be able to read mails sent to [EMAIL PROTECTED] IMHO it's a good idea to keep the ggi-project.org domain name and mail account. Who manages this? - think about the cvs tree layout before commiting to sourceforge. - If we're moving to sourceforge, I'll need to be added to the member list to commit the site TODO later: - The ggi who's who should be updated and maybe re-written up from the ground. - The documentation section has to be completed. I listed the relevant documents we need on the temporary site. suggestions welcomed. Eric.
Re: GGI site
Quoting Tijs van Bakel [EMAIL PROTECTED]: Should i post to [EMAIL PROTECTED] or [EMAIL PROTECTED]? The webpages say [EMAIL PROTECTED], but i haven't had a reply, or seen anything change :) I don't know where these mails go. I suppose steve still get them but he doesn't seem to check his mailbox. This has to be sorted out.
Re: GGI site
Quoting Christoph Egger [EMAIL PROTECTED]: On Thu, 25 Jan 2001 [EMAIL PROTECTED] wrote: I think, I've found a bug in the snapshot-section at http://zimzum.info.unicaen.fr/ggi/download.php The link "latest snapshot" works, but not the "latest diff". The "latest diff"-link refers to ftp://ftp.ggi-project.org/pub/ggi/ggi-snapshots/ggi-devel-.diff.bz2 typo! (fixed) BTW: How about a printing the current file size. This makes it easier to figure out, if something has changed in the diff-file... hmm.. I actually wonder if the latest diff is really needed. For monthly release it's ok but I'm not sure it really makes sense for daily snapshots. Anyway, I added libxmi from John's submission. Now I think it would be better to start distributing extensions independently. Other submissions are welcome. Eric.
Re: GGI site
Quoting Christoph Egger [EMAIL PROTECTED]: On Mon, 29 Jan 2001 [EMAIL PROTECTED] wrote: BTW: How about a printing the current file size. This makes it easier to figure out, if something has changed in the diff-file... hmm.. I actually wonder if the latest diff is really needed. For monthly release it's ok but I'm not sure it really makes sense for daily snapshots. Well, the idea behind that is to see if something has been committed into CVS on the filesize ... ok but is it really practical to show this on the site. better check the ftp repository and look at the diff directly.
Re: software cursor
Quoting Tijs van Bakel [EMAIL PROTECTED]: Lee Brown [EMAIL PROTECTED] writes: there was some talk about this 2 years ago iirc, but i've never seen it. i'm not entirely sure but i think this could be integrated with a sprite library. for hardware mouse cursors this may be hackish. i'd be interested to help out on a sprite library; who else is interested? Andreas talked about a blit extension. I suggest to introduce sprite handling in this extension, since it's strongly related. Regarding the site, my developement version is up at http://zimzum.info.unicaen.fr/ggi/ I'll be working on the extension part this weekend. The documentation part should also be investigated. For now I'll put a link to the former documentation page. Don't know if IE renders correctly. I just tested with netscape 4.7x and mozilla. cu Eric.
various things
Hi all! I'm still working on the site, did a lot of code cleanup. However I still got no news from the front regarding any kind of cvs access. Second, I was thinking about an xml-driven ressource management strategy(!!) (for extensions, applications, link...) to allow dynamic query and 'easy' ressource maintaining. This would require php(4) to be built with xml support. Is there any chance for this to be ok? Does anyone know the server configuration? Lee, would it be possible to get an url or a snapshot for the latest release of your libgft or whatever the name has become? I had a quick look at freetype2 and I think the right way is to write a ggi rendering module for freetype, rather than a freetype extension to ggi. This holds for libart too actually... It seems that the only requirement for both projects is a way to render alpha-blended scanlines rapidly. Regards, Eric.
Re: site candidate + test
Hi all! Merry christmas(late) and happy new year (in 1 hour). I've been a bit silent cos I'm on holiday since last week and I don't have easy internet access. sorry about that. 1) When is your site going to be the official site? Well, as soon as I get back from holiday and catch up a bit with my university work. 2) You may want to add MESA and minigui to the list of links Ack. 3) If you wish to add info about my lib just ask for anything you need. Ok. for now just your name, mail, download or homepage url and a synopsis for your library. 4) How about a short description of the libs on the "Who's Who"-site? I don't think it's the right place. better make a link. Regards, Eric.
Re: ANNOUNCE: LibGGI Final Beta
Quoting Marcus Sundberg [EMAIL PROTECTED]: You mean with --enable-mutexes=pthread or --enable-mutexes=dynpthread ? Don't do that! ;) The INSTALL file clearly states: If you are compiling with gcc you definitely want to leave this untouched, which will give you the builtin mutexes. Woops... my mistake. Please fix the packages and I'll make them available. Done. Regards, Eric.
site candidate + test
This is a second post... It seems that some of my mails never reach their
destination... Sorry for the double post if it occurs.
Hi all!
I updated the forthcoming ggi site :
http://soyt.free.fr/ggi
The site is xhtml-1.0-transitional error-free.
I wish I could make better use of css but netscape 4.x
stylesheet support is really shitty...
Tell me if you have any rendering problem.
Here is a TODO list:
* Register the current working or actively maintained extensions.
* Update the Who's Who section
* Check the application page and remove outdated links or apps.
Maybe define a simple canonical description of ggi apps.('gnome-like')
Categories:
Description:
URL:
Last update:
* Re-organize the documentation part. My suggestion:
- GGI overview (concept and design)
- Installation and setup HOWTO (including target and input specific
options)
- FAQ (two parts : user - developer)
- ggi docbook for reference
* General contents review
Send me comments and things you'd like to add or remove.
I still don't have cvs access. If someone could contact emmanuel...
Otherwise I make a tarball of the site to be commited to cvs. Somebody?
CU,
Eric.
Re: extension limitation
Quoting Lee Brown [EMAIL PROTECTED]: Hmm... how would you make the following three functions happen? fnt_font_t fntInitFTFont(FT_Face ftface); fnt_font_t fntInitXFont(XFont xfont); IMHO you'd have to define a ggi_font struct (or fnt_font) which abstracts underlying font systems. Then the two functions merges into something like: ggi_font_t fntInitFont(const char * font,) where font describe a set of requested attributes (like : scalable?, name,slant,...), just like ggi_mode. int fntPrintChar(ggi_visual_t vis, fnt_font_t font, uint32 char_code, sint32 x,sint32 y); Simply(?!) calls the appropriate backend. It needs to be properly designed (font attributes,...) but that's the 'clean way'. Regards.
Re: [Berlin-design] GGIMesa updates
Quoting "Jon M. Taylor" [EMAIL PROTECTED]: Yep, that's what I'm seeing as well. I haven't been able to track down the problem yet. For now, I am hacking around the problem by manually editing Mesa/src/GGI/libMesaGGI.la and changing the line that reads: dependency_libs=' /usr/local/lib/libggi.la -lgii -lgg' to: dependency_libs=' -lggi -lgii -lgg' I had a similar problem some time ago with the .la files. The problem was: on 'make install' the lib paths are not correclty set in lib*.la. They still point to the lib in the build tree: from /usr/local/lib/libgii.la: - # Libraries that this one depends upon. dependency_libs=' ../gg/.libs/libgg.so' -- I don't know the actual reason but I had it working by manually changing the dependencies in *.la Hope it helps. Regards.
manpages sync
I looked through: gg.h gii.h gii-unix.h ggi.h ggi-unix.h ggi-unix.h ggi_ext.h in yesterday (26-10) snapshot and I found the following sync problems (some are minor): - *** libgg *** - libgg functions are not documented. (I suppose they are all 'private' though) *** libgii *** - giiGetConfDir,giiMTInit, giiQueryDeviceInfo,giiQueryDeviceInfoByNumber and giiQueryValInfo are not documented. - giiPanic prototype is: void giiPanic(char *format, ...) but documented as: int giiPanic(const char *format, ...); - first argument of giiEventSelect is 'gii_input_t' in source and 'gii_input *' in manpage (gii-unix.h) *** libggi *** - ggiEventSelect, giiGetConfDir, ggiExtension*, ggiGetAPI, ggiIndicateChange, are not documented - ggiPanic : same as gii. - ggiCrossBlit : args should be 'ggi_visual_t' instead of 'ggi_visual *' in man - ggiSetTextMode: the 'ggi_graphtype type' argument is not mentioned in manpage. - ggiCheckTextMode: int ggiCheckTextMode(ggi_visual_t visual,int cols,int rows, int vcols,int vrows, int fontx,int fonty, ggi_graphtype type, ggi_mode *suggested_mode); but stated in manpage as: int ggiCheckTextMode(ggi_visual_t visual, int cols, int rows, int vcols, int vrows, int fontx, int fonty, ggi_mode *suggested_mode, ...); - ggiCheckGraphMode: doesn't expect additionnal args, but ends with ... in manpage. The biggest problem is the ggi*Mode mess which is quite confusing. Regards.
Re: TODO
My first mail is apparently lost. I send it again. Sorry for the double-post (in case). Quoting Andreas Beck [EMAIL PROTECTED]: and it appears it hasn't been updated for years. I remember someone offering to work on the web site not so long ago. It seems the general silence discouraged the generous offer. Yes. I would like to know where that disappeared as well. Well, it's still ok for me. I just got no reply so I thought it was not really needed. My proposal is still there: http://soyt.free.fr/ggi/news.php3 Just give me your opinion on the layout/design. I'll probably have time in the next few months to help with the website, but I need to be sure that it is not vain. I'm also in the process of checking manpages consistency. I noticed a few fuction prototypes in includes and manpages are not always sync. Regards.
ggiart-0.2pre1
A new ggiart release is available at http://soyt.free.fr/get/ggiart-0.2pre1.tar.gz Lots of code cleanup. I also added rgb and rgba buffer affine function. However I have difficulties with cross visual rendering. It should work but I get weird things when reading alpha channel back from a visual. I'll try to solve this for 0.2 release.
Re: font update
Quoting Andreas Beck [EMAIL PROTECTED]: Looks good. Where are the functions to select and load/free fonts ? It looks like you have to use the freetype library. I'd like, if loading fonts could be done alternatively by font name or by an alias that is looked up through an alias database, maybe allowing to give alternatives at open, like on web FONT FACE="Helvetica, Arial, Verdana") - guess you get the point. We might as well want to define a bunch of standard aliases that are used like kind of "user preferences". Then it might be useful to define a 'ggi_font' abstraction. Just a comment on the api: since all functions require a font argument, wouldn't it be more convenient to keep a font context for each visual, accessed via Set/GetFont calls?
news from the ggiart front
I got a first functional release for ggiart at: http://soyt.free.fr/ggi/ggiart-0.1.tar.bz2 Note that ggiart requires libart_lgpl. You actualy need it to build your paths. ggiart is just a rendering backend for ggi visuals. libart summary: libart has two main parts: a set of functions that handle vector paths logicaly (path construction, intersection, affine transorms,...) and a set of functions on rgb or rgba arrays (rendering of vpaths, affine transform and alpha-compositing of buffers). All rendering operations are done on 8 bit rgb(a) or gray linear buffers. problems: - no acceleration possible for tha actual drawing - different targets require api duplication in 'user space' (rgb_, rgba_, gray_) So the idea is to use the ggi abstraction for color and visual to get a consistent rendering api and allow possible acceleration. For now, ggiart is only capable of rendering sorted vector path, both alpha and antialiased. I still need to work out a proper ArtRender abstraction, and the api for alpha-compositing and affine transorm of pixel buffers (and/or ggi_visual, kind of cross-blitting ?). The good thing is : the default stubs should work on _any_ visual, even those without a linear framebuffer. Now it can definitely be accelerated (at least through directbuffers). This leads me to this question: I suppose that some hardware allow to draw point or lines with an alpha value. Since ggi_color defines an alpha channel, why don't basic ggi drawing functions handle alpha-compositing internaly? Thanks for feedback. Regards.
Re: Where is the GGI project heading?
Quoting Andreas Beck [EMAIL PROTECTED]: Yeah, I know - all that sounds pretty pessimistic. And I always feel pretty sad, when it comes to that topic. GGI is "my baby" more than any other open source project. And there is quite some blood, sweat and tears I and several other people put into it, so it really hurts to see it fall in decay. I'm pretty busy these days juggling two jobs, so I don't have so much time left to work on GGI. While this is bad for GGI, it helps a little to distract me from my "broken heart" about the project's state. But maybe some folks here would like to cheer me up a little ? What GGI needs is a driving force. Look at the mailing list. It's quiet. Really quiet. The only postings are a few newbies seeking help or asking for features, and from time to time, me, Marcus or a few others that annouce a little new feature they coded up, because _they_ needed it. Come one folks ! A project as big as GGI doesn't live by half a dozen semi-active coders. At least we need some _motivation_. Tell us what you need, tell us _that_ you need it, give us a hand implementing it, report bugs, and so on ! Despair not for ggi is not dead! It is the foundation for Berlin which will probably get public attention sooner or later. If I recall well, there had discussions among the hurd people about using Berlin as the standard windowing system. I'd really like to get involved, interrested in ggi3d and kgi. I had (and still have) plan to first contribute a game and other apps but I don't have much time right now. (maybe within 2-3 months, PhD issues need to get sorted out a bit) For now the homepage just need a lifting : organisation, daily news, faqs, fancy boxes, weekly screenshots,... just what people love! Someone was supposed to work on this. Please show up before Adreas's breakdown! :)
GGI state
If the list is quiet it, maybe it's just because ggi is pretty stable and well documented so nobody has to complain :) I agree that the sources have to be split in different libs. I suggest updating the homepage as : "GGI and friends" with each lib in its own section with an official maintainer, a status, a wish list,a TODO list and of course doc. Concerning world domination, if ggi is the right thing (I think it is) it will naturally gets attention. However when a project suddenly becomes trendy, it might gets bloated and developement might get out of hand. I got this feeling when I see the gtk/gnome developpment. True they release often, but the documention really doesn't follow. And if they didn't rush like this, they would probably have made better choices like actually adding toolkit components in the toolkit library! (gnome canvas...) So better be slow but efficient and coherent. !! DISCLAIMER : I actually like gtk/gnome so no heavy flame please. They're great job. and python binding is sweet !! So my 2cts plan suggestion: - prepare a rock stable release without unmaintained/incomplete libs - establish a TODO list with pending issues like libgpf and GGIMesa status. AFAIK There had a discussion about introducing input callbacks to get non trivial composed characters like japanese kanji. - relook the homepage - have a coffee - keep the code clean, documented, amazingly well designed, and add new features with care When I have time I'd like to contribute to libgpf and maybe GGIMesa (but not before a month a fear) I can also help with the homepage if patrick coleman (was he?) happened to be MIA. cu.
Re: image loading
Quoting Christoph Egger [EMAIL PROTECTED]: On Fri, 7 Jul 2000 [EMAIL PROTECTED] wrote: Hi there. If I remember well (the mailing-list archive seems to be in alzeimer's terminal phase...), there was a discussion some time ago about a generic lib to load image files into a ggi visual. Are you talking about libgpf? probably. I'd like to know if somebody's still working on it and if there is some kind of functional code somewhere. No. Sorry. I must disappoint you. no worry. I can send you the API-headers, if you want. That's all what currently exists about it. But don't expect, that the API is finished and stabilized out... It's still in pre-pre-pre...-alpha state. Ok thanks, i'll have a look anyway. BTW, I found a small annoying ...feature in the CVS snapshot build process: The libgii.la shows the line "dependency_libs=' ../gg/.libs/libgg.so'" which must be changed manualy to get other stuff compiled properly (like SDL in my case).
image loading
Hi there. If I remember well (the mailing-list archive seems to be in alzeimer's terminal phase...), there was a discussion some time ago about a generic lib to load image files into a ggi visual. I'd like to know if somebody's still working on it and if there is some kind of functional code somewhere. Thank you.
Re: New source forge project ggitk
Quoting Bryan Patrick Coleman [EMAIL PROTECTED]: Is libGWT ready for use? And is windowing just placement of visuals or is there more involved than that. You'll also need input handling (mouse,kb...), focus management, X-like events to send to applications (expose,resize)... I don't know the state of libGWT.
Re: New source forge project ggitk
Quoting Bryan Patrick Coleman [EMAIL PROTECTED]: On Sun, 25 Jun 2000, Andreas Beck wrote: Should I just port GDK to raw LibGGI calls or should I use some other library underneath GDK such as SDL or something? If there is a port to SDL, you can of course just use that, as SDL can display on LibGGI. Other than that I'd rather port it directly to LibGGI. The problem is that gdk is pretty much tied to the X protocol which is a windowing system. AFAIK GGI by itself doesn't have anything to do with windowing. I'll have to sit down and dig through the code as I am not that familier with GDK. I was just not wanting to duplicate effort on the libgwt front. I already had this idea before, and I think we need to have a basic windowing system right on top of ggi (gwt might do the job) and then port gdk (which should be enough to get gtk working) to it. So I would say go for gwt! And you may even consider porting gtk to Berlin. (guts required!)
Re: Data sheets
Quoting Tomek [EMAIL PROTECTED]: Hi! Does anybody know where can i find informations about graphic (and music) file formats? www.wotsit.org has an awful lot.
Re: Page Design
Quoting Bryan Patrick Coleman [EMAIL PROTECTED]: News - for, you guessed it news. About - A more indepth look at what ggi is and why it is. Sceenshots - Ggi is graphics so this should be prominate. GGI Zen - This is going to be a "why use ggi" type of page, basicaly propaganda. Could'nt it be put in the Docs/FAQs or About part? Documentation - docs, faq, howtos GGI Xtras - Applications that use ggi, good ggi graphics cards berlin :) Graphics cards...hmmm... this should be left to the kgi homepage. Download - Download, tgz's rpm's Development - cvs browsing staff devel list that kninda thing. A really nice thing would be a 'state of the code' that list things being worked on, remaining issues, known bugs... Developers should be able to add/del/modify these entries easily (via forms) to get things up-to-date. Take a look at these catagories and see if they size up to beinging able to contain everythin. Each sub catagorie would be able to have other catagories as well but this is a start. Don't subcategorize too much. I think it's confusing and cumbersome for the user.
Re: Website ? What's up ?
Quoting [EMAIL PROTECTED]: What's up with the website ? Marcus has for now taken over and updated it a bit, but AFAIK we had two candidates for the new webmaster ... What happened to them ? Well, if they've been thrown in outer space for some reasons and nobody else shows up I'd be happy to help. I also plan to release a heavily multiplayer Stunt Car Racer-like game (I just loved it on Amiga) for GGI.
Re: ggi + mesa + doublebuffer
Quoting Niklas Höglund [EMAIL PROTECTED]: It'd be nice if it was possible to set what part of a visual and which frame a ggimesa context draws on. I just browsed through ggimesa source. please correct me if I'm wrong. Mesa first gets a linear fb lfb[0] from ggi_visual (ggiDBGetBuffer()) and creates another one lfb[1]. ggiMesaSwapBuffer() calls ggiFlush() and then memcpy() lbf[1] into lfb[0] if the dbflag is on. So I guess it renders in lfb[1] somewhow first but I can't find how. I suppose they ggiFlush before to prevent previous ggi Calls to draw over the buffer after the memcpy. I'm not sure if it's really a good design... I'm a bit clueless about both ggi and mesa internals, and I don't know what is the exact relationship between frames in ggi_visual and framebuffers associated with this visual, but i think mesa should always draw in the framebuffer of the current WriteDisplay. Doublebuffering could be handled eiher externally, or within mesa by switching Display (if more than one is available). I also think ggiFlush should not be called by mesa. soyt
