On Sun, 24 Feb 2002, Christoph Egger wrote: > Hi! > > On IRC there came up some problems. > > Please comment: > ------------------------------------------------------------------ > [15:35] <al3x> hi > [15:35] <al3x> i've got some problems with ggi :( > [15:36] <al3x> any coders there ? > [15:37] <bughunter> yep > [15:38] <al3x> a friend of mine uses libggi 2.0b3 with x-target > [15:38] Action: bughunter sent mail with compiler errors and warnings to > alex > [15:38] <bughunter> Your friend should update to libggi 2.0.1. > [15:38] <al3x> it uses async mode on default but it doesnt sets ggiflags > to async > [15:39] <bughunter> Which target does he use? > [15:39] <al3x> x > [15:39] <al3x> also when i force ggiflush it works fine > [15:40] <bughunter> Which version do _you_ use? > [15:40] <al3x> also this was only 1 problem, 2 reamining :( > [15:40] <al3x> i use 2.0.1 > [15:40] <al3x> debian woody default > [15:40] <al3x> he uses 2.0b3, freebsd ports default > [15:41] <bughunter> in 2.0b4 some freebsd port fixes went in. > [15:41] <bughunter> Your friend should really try 2.0.1. > [15:41] <al3x> yes, i said him this for hours ;) > [15:42] <bughunter> And what are the other 2 problems? > [15:42] <al3x> is there any version control available? > [15:43] <al3x> i used GT_ByPP, it isn't there in 2.0b3, so i decided to > use GT_SIZE, and what about the older versions? compilation will break > [15:44] <bughunter> GT_ByPP is a new macro introduced in version 2.0.1, > which returns the size in bytes per pixel. > [15:44] <bughunter> GT_SIZE returns the size in bits per pixel. > [15:44] <al3x> yes, this isnt the problem :) > [15:45] <al3x> the problem is the absent version control > [15:46] <bughunter> Ah - you mean, that the application can check, which > version is installed? > [15:46] <al3x> yes > [15:47] <al3x> and the latest (most annoying) problem: > [15:47] <al3x> i check with ggiCheckMode if 32bpp is available on fbdev > [15:47] <bughunter> I fear, that must say, that there is no version > control. > [15:47] <bughunter> But adding a proper #define should do it, no?
I propose some #defines for providing this: #define <libname>_VERSION_CVS (marks CVS versions) #define <libname>_VERSION_2_0_2 (next planned official release) etc... Comments? > [15:47] <al3x> it says it isn't available, if i use ggiSetMode it can set > 32bpp and it works fine > [15:48] <bughunter> which driver do you use? > [15:48] <al3x> fbdev, as i said > [15:48] <al3x> on x there are no problems > [15:48] <bughunter> I mean which fbdev driver you use. > [15:48] <bughunter> matroxfb? vesafb? directfb? > [15:48] <al3x> no matrox, directfb target isn't installed, i think vesafb > ;) > [15:49] <bughunter> When you're sure, then it might be a vesafb fault and > no GGI one. > [15:50] <al3x> vesafb target's fault > [15:50] <al3x> and what about adding ggiGetModelist ? > [15:52] <bughunter> I think, we should discuss that on the GGI list as > there are more developers. > [15:52] <bughunter> IMO, that is a good idea. > [15:52] <bughunter> But I don't want to make decissions alone. > [15:52] <bughunter> There might come up even better ideas. > [15:53] <bughunter> I'll write a mail to the ML about we this discussion > here. > [15:54] <al3x> it would return the all available modes (for given > width/height), and i could select easily the best of them > [15:54] <al3x> sorry, i must leave now, comming back in a hour Uhmmm sorry. I must have been brain-damaged at that time. libgalloc is the way to go. It's targets knows what they can do. You can request resources (video modes, buffers, etc.) and libgalloc tries hard to get the best out of the target. Check out http://www.ggi-project.org/docs/libgalloc.html for detailed information. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
