Re: User space background process blocking
the user pays for console switching on slow machines. The user doesn't have to switch, it is a feature. uhmm... I guess you mean: The user doesn't _need_ to switch... :-) Jos -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: GGIFLAG_TIDYBUF
Brian S. Julin wrote: Demo is not written to use tidy buffering mode. Berlin and that commercial web broswer ade is working on are examples of apps that will benefit from tidy buffering mode. Basically it is for directbuffer-using applications that want to alter small regions of the screen with directbuffer. So will this remove the problem (bug) fresco had with the new ggi and its pointers? Or is this related to something else? IIRC, fresco does neither acquire nor release the directbuffer it uses. If I am correct, then I must tell you: Sorry, no it won't fix the fresco problem. -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: User space background process blocking
On Tue, 21 Jan 2003, Andreas Beck wrote: The app has to specify anyway what it wants to do in case it is switched away. Yes, and often the app might want to _continue_ working even if it's switched away. That's the case, _if_ the application catches the signal. If the app will just be halted, if it doesn't handle the switchaway, this will do for 90% of apps. Halting the app won't solve the problem anyway: how do you handle halting when a VT switch is requested right in the middle of a piece of code which is writing to gfx card registers? That's an issue, that can be solved within the GGI target: Catch the signal, and wait until the accel is idle or in any other interruptable state (Note, high-end graphic hardware supports context switching in hardware and thus don't need to be really idle). What's difficult to get? The user should be able to make the app run on whatever target is available, even yet-to-write-ones-with-very-special-features, so having to write specific code for specific situations which arise only with specific targets defeats the whole point of ggi. If you are missing a graphic resource management system, then please check out http://www.ggi-project.org/xmldoc/bk01pt03ch05.html and follow the 'next' links. :) look there: vtswitch_request. So, does any ggi app have to implement that? If it wants other than the default behaviour of go to sleep if switched away, get a redraw message on switchback: IMHO yes. the switch away event is kgi-specific, No. All console based targets as svgalib (Linux), vgl (FreeBSD), aalib, vcsa (Linux) and fbdev (Linux) have this switch away. on windowed systems when you switch an app away, the app is not put to sleep! ... because there's an central management system being able to obtain the drawing operations. The app _doesn't_ have to care about where it runs, I should be able to run it on X and on KGI without having to touch one line of code. Your approach defeats the whole point of ggi. Don't tell _me_ about the point of GGI. Uhm? Sorry, but I know the point of ggi very well too. Fabio: Andreas is the GGI founder, in case you don't know... :-)) (Sorry, wouldn't blame you...) But tell me why the heck it would make a difference in the code? The app won't care if it was X telling it, that it has been iconified, oder KGI telling it, that a VT-switch is pending. Same thing to the app. If it wants something else than being stopped when switched away, it may as well introduce some code stating what it does want. Maybe I haven't been clear enough: what I don't like is the fact that the app gets put to sleep. [...] ... but don't tell me that the right solution in case it doesn't understand that is to put it to sleep! This behaviour is not a mandatory. It is the default option. If you don't like it, then just catch the signal... :-) AROs takes advantage of accelerated X functions: if it has to write in a backbuffer first it couldn't take advantage of such functions. You can't use accelerated drawing functions, when the app is switched away, independent whether it is put to sleep or not. Yes, the X apps continue to run, when iconified. But do you really believe, that X still uses accelerated drawing functions? In particular, when there's no more onboard gfx RAM available? I don't _demand_ anything! We were just discussing design decisions, weren't we? GGI and KGI is yours, far from me the idea of imposing design decisions, I just thought I'd spend my 2 cents and say something about the topic too. well... then thanks for the flame war. :-) Can't remember, when there was such a heat discussion the last time on this list before... :-) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: User space background process blocking
On Tue, 21 Jan 2003, Christoph Egger wrote: Yes, and often the app might want to _continue_ working even if it's switched away. That's the case, _if_ the application catches the signal. And that's wrong, imho, because usually apps will want to run in bg, and thus making that the default behaviour will force all apps to handle that case anyway. And it can continue running in background. The signal is just there to notify the application that it is aware of its state and that the framebuffer nor the accel commands are NOT accessable. _How_ the application deals with that situation (i.e. drawing into a backbuffer, storing drawing commands in a queue or do some calculations, etc.) is _completely_ up to itself. But you'll need to save the gfx card state somewhere, and restore it later on, hence you might just as well let the application continue running on a framebuffer, or just mmap /dev/null and use it as framebuffer in case the app didn't require a backingstore, or there's not enough memory to make it available to the app, in which case the app would get an expose event when switched back again. But let it run! That's stuff that can be done in the GGI target, which means this is transparently to the GGI application. :) Right, I had in mind kgi as the only console-based target, subsitute kgi-specific with console-specific. Wow! We make progress! A point of an agreement! :-)) on windowed systems when you switch an app away, the app is not put to sleep! ... because there's an central management system being able to obtain the drawing operations. ... which should be implemented in ggi as well, Well, that's already available. The difference to X and Fresco is, that GGI apps have multiple 'central management systems' called GGI targets. :-) and if galloc is such a thing, then it should be used. libgalloc is there to manage limited graphic resources GGI applications can request at runtime. I know that, nevertheless I follow ggi since it was born (you can still find one email of mine related to kgi in the archives), and I know it wery well. I think I have the right to say that I know what's the ggi purpose. ok. Second point of agreement. :-)) ... but don't tell me that the right solution in case it doesn't understand that is to put it to sleep! This behaviour is not a mandatory. It is the default option. And it shouldn't be. That's all I'm advocating: apps usually _don't want_ to be put to sleep when they're switched away uhmm... Do you know nixterm? It is terminal implemenation on top of libggi. What do you guess, what it does, when it runs in background? It is waiting until you press a key! What does waiting for keypress mean? That means, that it sleeps!! :-)) To wake it up, you must send it a key. How do you send it a key, when it runs in background? ... Do you really think, it makes _NEVER_ sense to put apps to sleep? If you do then please explain me, how a multitasking scheduler works... :) (I know, this is a little offtopic now, but... :-)) which means that every app will have to implement somecode to avoid that: if it's possible to make it automated, then it should be. What do you want to exactly avoid? The signal handler, which can be done within the GGI targets or the code, which lets the GGI app react on the event expose? If you wanna do the last case in the GGI target, too, how would you do that? nixterm definitely behaves different than ggidoom, when being in background. :-) But do you really believe, that X still uses accelerated drawing functions? In particular, when there's no more onboard gfx RAM available? No, of course not, and it's not what I said. Third point of agreement! :-)) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: User space background process blocking
On Mon, 20 Jan 2003, Fabio Alemagna wrote: On Mon, 20 Jan 2003, Brian S. Julin wrote: Stupid question from an outsider: couldn't it be possible to make the application still run by making it use an offscreen buffer while not visible because of VT switching? It would be really annoying, imho, if the application stopped altogether... Yeah, nice... My 32 MB Matrox deals with 4 devices, which means you need 4x32 MB = 128 MB offscreen for that one alone. Glad I don't own a 128 MB ATI 9700 ... my box got only 256 MB... And now serious: Nice idea, but doesn't work. As you can see above, fake framebuffers are no good but for text modes. If we really want to make a chance to make it in any kernel, we should come up with something better. How about using the memory target within libggi's kgi-target, when the application runs in background? This background mode can be done by copying first waiting until the accel is idle, then copying the framebuffer content into the userspace memory obtained by the memory target. Then the application can continue reading/ writing from/to the framebuffer in the background. Once it falls into foreground again, simply copy the emulated framebuffer to the real framebuffer. In short words: Framebuffer access should happen by transparent proxy from the GGI applications view. Transparently, because this proxy mechanism is within the kgi-target and thus hidden to the GGI application. The big question is, if this will still work, once libggiovl becomes useable and the GGI apps requests overlay resources such as hw-sprites and/or YUV-viewports... -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: User space background process blocking
On Tue, 21 Jan 2003, Christoph Egger wrote: How about using the memory target within libggi's kgi-target, when the application runs in background? That's basically what I mean. Then you were not precisely enough. By using the word offscreen, every- body thought, you mean an offscreen area of the onboard framebuffer... [...] The big question is, if this will still work, once libggiovl becomes useable and the GGI apps requests overlay resources such as hw-sprites and/or YUV-viewports... hw-sprites, I guess, would still be accessed trough an API, right? Hence when the visual is not visible just update the internal sprites' state, don't actually display them. The same goes for the YUV overlay: redirect it to a memory target. When the visual become visible again then refresh the display with the content of the various buffers and the sprites. That sounds a good idea. But then a) the memory-target must be extended to support overlay resources and b) the GGI application should be notified somehow, so that the GGI app can stop wasting CPU time with decoding a video, for example, when it knows that the result (the decoded video) gets no longer displayed... -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: User space background process blocking
On Sun, 19 Jan 2003, Jos Hulzink wrote: Hi, KGI used to set a task to sleep when it was mapped away from a display. This didn't work always, and with some help from #kernelnewbies, I came to the conclusion that it isn't even what you want. A task doesn't need to sleep, it only has to stop drawing. I came to a very simple, but (imho) ingenious solution: Send the task a signal. When reading the docs, I noticed that POSIX even defines a signal specially made for this, SIGTTOU. This signal is sent to a background process that tries to write to its controlling tty. (*) Question: What does happen, when a background running process wanna READ from its controlling tty? IMO, a SIGTTIN signal should be send to the tasks, then. The default behaviour of a process is that it is stopped. This looks a little ugly on its controlling text console (You see the same as when pressing ^Z), and with a fg the task starts writing again (without setting the mode back), but it is a start. LibGGI can catch this signal, and behave like it. It can block all drawing (maybe if a program requested a directbuffer, sleeping really is the only solution). When LibGGI catches this signal, the fg issue is over immediately. I'd like to know whether you like this idea, or I have to find another solution. Well, signal handling is up to the targets. So the kgi target need to install signal handlers for SIGTTOU and SIGTTIN. The question is, what should the signal handlers should do then. There must be a way to get informed when the kgi target can continue with reading/writing to its console. I think, the best way is to wait for a second SIGTTOU/SIGTTIN signal, which informs the kgi target to continue. Jos (*) SIGTTOU confirmed available on Linux, (Free,Open,Net)BSD, Solaris, MacOSX, other platforms untested. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: ggibench output
Hi, Here are the results I get on a Radeon 7500 with KGI and the Radeon sublib: 1024x768 (1024x768) // 16bit ggiDrawPixel: 481517 pixels/second ggiDrawLine:89335 lines/second ggiDrawHLine: 308350 lines/second ggiDrawVLine: 115966 lines/second ggiDrawBox: 21009 boxes/second ggiCopyBox: 899882 copies/second // ignome me ggiPutc:277100 characters/second ggiPuts:155406 strings/second All operation are accelerated except for DrawPixel and as previously mentioned CopyBox is a noop. Unfortunately I don't have any other targets setup on my test box to compare with. Plattform: MacOSX 10.2.3/PPC G4 800MHz Accelerator: ATI Radeon Mobility 7500 Target: X (windowed, XServer: XDarwin (rootless mode) - accelerated(?)) Mode: 1152x749.V1152x749.F1.D1x1.[C24/32] ggiDrawPixel: 6673 pixels/second ggiDrawLine:2425 lines/second ggiDrawHLine: 7012 lines/second ggiDrawVLine: 479 lines/second ggiDrawBox: 427 boxes/second ggiCopyBox: 351366 copies/second ggiPutc:2157 characters/second ggiPuts:957 strings/second Plattform: MacOSX 10.2.3/PPC G4 800MHz Accelerator: ATI Radeon Mobility 7500 Target: X (windowed, XServer: Apples X11 env (http://www.apple.com/macosx/x11/ (rootless mode) - partially accelerated through the Quartz engine) Mode: 1152x749.V1152x749.F1.D1x1.[C24/32] ggiDrawPixel: 10860 pixels/second ggiDrawLine:2054 lines/second ggiDrawHLine: 8037 lines/second ggiDrawVLine: 2596 lines/second ggiDrawBox: 437 boxes/second ggiCopyBox: 362359 copies/second ggiPutc:4003 characters/second ggiPuts:1023 strings/second Plattform: MacOSX 10.2.3/PPC G4 800MHz Accelerator: ATI Radeon Mobility 7500 Target: Quartz (fullscreen, unaccelerated) Check for mode: 1280x854.V1280x854.F1.D1x1.[C24/32] checkmode: truecolor mode Got mode: 1280x854.V1280x854.F1.D1x1.[C24/32] ggiDrawPixel: 147848 pixels/second ggiDrawLine:10625 lines/second ggiDrawHLine: 17484 lines/second ggiDrawVLine: 25177 lines/second ggiDrawBox: 88 boxes/second ggiCopyBox: 183502 copies/second ggiPutc:49548 characters/second ggiPuts:12755 strings/second :-) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Debian NEWS
Hi! libggiwmh has been packaged. I dunno, if it is already fetchable via aptget. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Hotfix for NetBSD users
Hi! It has been figured out that NetBSD = 1.5.x no longer needs a '_' prefix on symbolnames for dlsym() to work. The Hotfix #0 removes the '_' prefix and thus is a mandatory for all NetBSD users to apply. BIGNOTE Since NetBSD = 1.4.x is called to be dead, NetBSD = 1.4.x is no longer supported with this hotfix. /BIGNOTE Hotfix #0 is available on http://www.ggi-project.org/download.html. See also this site for more information about the hotfix. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
SourceForge NEWS!
Hi! http://sourceforge.net/ The SF staff selects only SIX!! news from hundreds(!) they get each day, which are worth to get mentioned on the news frontpage! And OUR ANNOUNCEMENT IS ON THE FRONT PAGE The front page has page view rates of millions per day! BTW: I just submitted the announcement on /. I hope, it will appear there soon. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
CVS trees - FAQ
Hi! libgii 0.8.2 and libggi 2.0.2 has been tagged in CVS with 'version_0_8_2' and 'version_2_0_2'. The stable branch has been opened as well. How do I checkout/update/commit from/in the devel tree? As usual. No additional params required. How do I checkout/update/commit from/in the stable tree? Use the additional param -r branch_major_minor after the commit/update command. branch tags follow the branch_major_minor semantic. For libgii the branch tag is 'branch_0_8' and for libggi 'branch_2_0_2'. 1. Example: cvs -z9 checkout -r branch_2_0_2 ggi-core/libggi 2. Example: cvs -z9 update -PAd -r branch_2_0_2 [files...] You can commit in the stable tree as you do in the devel tree. I am in the stable tree and forgot to use the -r param. What happened? Your working tree has been changed to the devel tree. Non-committed stuff has been merged in there. Check for possible conflicts to resolve. How can I undo that? Make another cvs update - but this time _with_ the -r param. Check for possible conflicts to resolve. I am in the devel tree and used the -r param. What happended? Your working tree has been changed to the stable branch. Non-committed stuff has been merged in there. Check for possible conflicts to resolve. How can I undo that? Make another cvs update - but this time _without_ the -r param. Check for possible conflicts to resolve. Check the cvs manual(s) for more information. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
GGI's CVS devel vs CVS stable tree
Hi! The CVS devel tree differs from the stable tree now. Changes happened in the devel tree: - Xlib target removed - added cocoa input driver to libgii (requires MacOSX 10.2 or newer) - added quartz target to libggi (requires MacOSX 10.2 or newer) Changes happended in the stable tree: nothing. :) CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
CVS stable branches
Hi! I plan to create two CVS stable branches immediately after the official releases are out. One branch is for libgii 0.8.x and the other for libggi 2.0.x. The main devel tree goes ahead to libgii 0.9.0 and libggi 2.1.0. While versions are tagged by the 'version_major_minor_subminor' semantic, branches should IMO be tagged with 'branch_major_minor'. What should go in the stable branches are: - bugfixes, bugfixes and bugfixes :) - target improvements, that has been proven stable What may go in the stable branches: - new targets, which are almost ready (will be marked as experimental) On the GGI site, I wanna have a 'CVS stable branch' section. This section should enlist user _visible_ changes and seperated ChangeLogs from the devel tree for the details. Further, it has to explain how to checkout/update from any branch and how to commit for the developers. Eric said on IRC, he will do some brainstorming about that during his holiday in Japan (He is away from Monday to... anywhere... :). Why the branches? 1. Branches allow us to make shorter release cycles. We don't need to wait until changes - deep changes in particular - has been proven stable. We make releases, whenever the ChangeLog is long or the changes are important enough (see above). People should NOT think, GGI defuncted (once) again, due to too long release delays... In short: This makes us more flexible for cases, where we MUST or CAN make releases. (/me thinks on the case, when a security whole was found and fixed) 2. Target developers rely on a working foundation. They can write GGI targets without worrying about internal instabilities, etc. 3. Packagers have the advantage to make releases from the stable branch tree at any time. (i.e. when they can't wait for a release to put in the latest x-target fixes in their packages...) 4. (Experimental) users are generally known to only use/try out almost or only stable things. The stable CVS branch allows us to get a more tester base, which (hopefully) means more feedback. Those, who affear doing double work are right, _if_ they port _every_ little patch they have. Thus, it is generally highly recommended to wait until there is something that is really worth the effort (i.e. a major target improvement proven being stable) unless the patch is interesting/important enough (i.e. a minor but important bugfix). Comments/Questions? CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: ggibench output
Hi, Here are the results I get on a Radeon 7500 with KGI and the Radeon sublib: 1024x768 (1024x768) // 16bit ggiDrawPixel: 481517 pixels/second ggiDrawLine:89335 lines/second ggiDrawHLine: 308350 lines/second ggiDrawVLine: 115966 lines/second ggiDrawBox: 21009 boxes/second ggiCopyBox: 899882 copies/second // ignome me ggiPutc:277100 characters/second ggiPuts:155406 strings/second All operation are accelerated except for DrawPixel and as previously mentioned CopyBox is a noop. Unfortunately I don't have any other targets setup on my test box to compare with. Plattform: MacOSX 10.2.3/PPC G4 800MHz Accelerator: ATI Radeon Mobility 7500 Target: X (windowed, XServer: XDarwin (rootless mode) - accelerated(?)) Mode: 1152x749.V1152x749.F1.D1x1.[C24/32] ggiDrawPixel: 6673 pixels/second ggiDrawLine:2425 lines/second ggiDrawHLine: 7012 lines/second ggiDrawVLine: 479 lines/second ggiDrawBox: 427 boxes/second ggiCopyBox: 351366 copies/second ggiPutc:2157 characters/second ggiPuts:957 strings/second Plattform: MacOSX 10.2.3/PPC G4 800MHz Accelerator: ATI Radeon Mobility 7500 Target: Quartz (fullscreen, unaccelerated) Check for mode: 1280x854.V1280x854.F1.D1x1.[C24/32] checkmode: truecolor mode Got mode: 1280x854.V1280x854.F1.D1x1.[C24/32] ggiDrawPixel: 147848 pixels/second ggiDrawLine:10625 lines/second ggiDrawHLine: 17484 lines/second ggiDrawVLine: 25177 lines/second ggiDrawBox: 88 boxes/second ggiCopyBox: 183502 copies/second ggiPutc:49548 characters/second ggiPuts:12755 strings/second :-) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
SF: Bug #656488
Hi! http://sourceforge.net/tracker/index.php?func=detailaid=656488group_id=16307atid=116307 Anybody, who wanna take over that? -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: libggigic
libggigic is a GGI library (no extension) on top of libgii - not libggi! Now, I am glad to tell you, that I just got it working on Darwin/MacOSX. libggigic is in the ggi-libs CVS module. Anyone to try out (on different platforms) ? Needs a time.h on Linux in one of the demos I think. Yep. Just verified that. Fixed in CVS. And could do with a better demo :-). The snazzymanager is nice, but the ggidemo is quite lame (I may say that I coded it :-). hehe -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
libggigl
Hi! libggigl an extension to allow users _any_ opengl implementation and not necessarily GGIMesa. libggigl has been discussed on IRC. It should only have targets with native opengl implementations (i.e. X with GLX, DirectX with wgl). A stub target should be there representating all other targets with NO native OGL implementation such as kgi, aa, etc. Those should run upon GGIMesa. We would quickly have something others do NOT have: Running OpenGL applications on various environments (even HW acceleratered!), switching targets on the fly, etc. So far, things look simple and simple doable. But it is NOT. The problem is LINKING! It must be possible to only and only link GGIGL applications against libggigl. Linking against any certain opengl implementation adds the dependence, they do not have to have in order to provide the above mentioned features. But if you don't, many symbols can't be solved by the linker. The major point is, _which_ ogl implementation should be linked against, when there are more than one ogl implementation on one platform? That situation is actually not rare: Mesa and GLX on Linux, GLX, WGL and Mesa under Win32, GLX and MacOSX under MacOSX, etc. For the linking issue, there has still been found no solution. Ideas, comments, etc... everything is appreciated. -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: LibGGI install issues
Hi folks, I just tested LibGGI installation into a private path (/tmp/eccet) and found a few annoying things we should fix: GII installs a binary called cpuinfo - that's too generic. Either don't install it, or call it giicpuinfo oder ggicpuinfo or something. I am not aware of an application that uses this name now, but I think I can imagine apps where the name fits much better. Fixed in CVS. I changed libgii/demos/Makefile.am, so that cpuinfo no longer get installed. GII installs a man section mana containing a Makefile. Strange. I'm not quite sure if GGI also does this - something to check out. Eric? -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
libggigic
Hi! For those, who don't know, what libggigic is: libggigic is a GGI library (no extension) on top of libgii - not libggi! It allows GGI applications to bind actions with input events at runtime. You probably know this feature from many games, where you can change the fire button at runtime. Now, I am glad to tell you, that I just got it working on Darwin/MacOSX. libggigic is in the ggi-libs CVS module. Anyone to try out (on different platforms) ? -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: World-Domination - was Re: multi threaded... Details: Names
Which widget library? Some of your own or something more general? One of my own. Basically something to do away with an ugly TCL/Tk script that is used to control eccet. The idea is to have something that can nicely live side by side with other stuff on a GGI visual. Existing libs made that cumbersome to integrate, as I want several LibGGI native windows that will display rendered 3D-stuff in realtime and accept mouse and key commands _plus_ one or more control windows - that may be as slow as they want - to give a GUI for stuff that is not easily controlled with keyboard and mouse. The reason for eccet itself not using a widget library is speed. I want highspeed access to the graphics frontend (X). LibGGI provides that nicely for me. And I don't want to bother with some intermediate layer for a widget lib like GTK. I have sped up a simple application (planeview) by around one order of magnitude by just porting it over from GTK. And to my knowledge the original implementor had already played tricks to make it fast on GTK. I can send you the code if you like. It has some special widgets I happen to like (e.g. dials like used in xv). How about uploading to our GGI ftp server and posting the URL here? -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: multi threaded... Details: Names
On Sunday 15 December 2002 16:01, Christoph Egger wrote: libbse, libgic and libgpf are NO extensions. Thus, how should we mark ggi libs, which are NO extensions? IMO, extensions should be distinguishable from non-extensions by their (package-)names. I clearly seem to fail to understand why this would be important, but anyway, this is not a problem (possibly an aesthetic issue, though). Well, ok... When there are no objections within the next 6 hours, I'll start to rename _all_ ggi libs (libgpf, libgic and libbse) and extensions (libgalloc, libbuf, libovl, libblt, libwmh, libgcp, libvideo, libxmi, etc.) to the form of libgginame. (i.e. libggigpf, libggigic, libggibse, libggigalloc, libggibuf, libggiovl, etc.) As far as packaging of gii goes, if I understand the issue correctly, it boils down to binary compatibility between libgii and its input targets. Currently if a binary incompatile change happens, the only way to keep both versions installed would be to do some very fancy libgii.conf cruft in order to make each of the version of libgii load the proper set of input targets. But given that the loading of input targets is fully under libgii control, I think it is safe to assume that if any such change happens, libgii will provide a mechanism for loading the different versions of input targets. Hence I would tend to think that libgii-target-x should be the right choice. After three days of psycho rollercoaster between putting it all in one package, giving up on it and having lots of packages nicely split, i had to decide that there is not much that i can do from my side _now_ to put all this on a stable basis within a short term. This one is libggi0-target-x now, proposing the illusion of the possiblility to have more than one generation of libsmods installed. Anyway, i'm not giving up and hope that we are able to find a midterm solution. /me started to put a script together, quoting the problems that i actually have and can see and we can try to fill in solutions. Mind you, the number of packages depending on libggi is sinking continously ... !!! I'm really wondering, what is WRONG with GGI... People seem to like the idea making the same efforts/work again and again on various projects by porting them to this and that plattform... So for the very moment i have only ONE point that I BEG should be tackled BEFORE any RELEASE: Please, consider how you really want to call your libs and extensions wrt. filenames! see above. What a nice plug, that even one of your core dev's had to find that the name of any lib had silently changed Well, Andy is the GGI founder, but core developer? hmm... ex core developer or core user seems to fit better... Sorry, Andy, but that is the picture about you you give us with your absence... Correct me, if I am wrong... I really don't know what is so hard to understand about my questions and the cases that i bring up to you as The Project. I'm really sorry if i make you feel uncomfortable from time to time ... No. We need people like you, who point us to the right direction... :) Again, i have my structures set up here so that i can put out _any_ of your libs in a short time, either from cvs or your tarballs. Getting it all right from Linux binary compatibility, shlibs issues, over Debian policies to the ggi project isn't the easiest thing to do if you pay 2 cents for each minute of internet connectivity. Ouch... Don't you have the ISDN XXL tariff? You can surf with no costs on Sunday's then... :) Besides getting the svgalib wrapper going, this is what i see as my part to give sth. back to you. But i know now, how much work it is to keep a ggi application going over time and i'm not willing to promote that to anybody who tries to get sth. else going too. /me now has to get sth. else going too, thanks for your time. The official maintainer of the svgalib wrapper is still Marcus Sundberg. I wonder, where he remains... Is there any volunteer taking over the maintainership? -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Fwd: What I tried to send to ggi
--- Weitergeleitete Nachricht / Forwarded Message --- Date: Mon, 16 Dec 2002 21:58:19 +0100 From: Jos Hulzink [EMAIL PROTECTED] To: [EMAIL PROTECTED] (Christoph Egger) Subject: What I tried to send to ggi Jos can't post to here for some reason... On Monday 16 December 2002 15:58, Christoph Egger wrote: I'm really wondering, what is WRONG with GGI... Devils advocate There are alternatives that are portable enough for most and that have a consistent and usable API, don't consist of a maze of many libs, provide 3D accelleration (or at least abstraction of it) and sound abstraction (essential for games) ? /me thinks that compiling the ggi stuff is a hell: First this tiny sublib (gii), then the next (ggi) then number three (galloc) then all extensions some of which are no extensions ... Besides ,I have never seen any advertising for GGI, it is not known on linuxgames, the last entry on freshmeat dates years back. I think I remember one interview in which ggi was mentioned, but that was years ago. Jos -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: multi threaded... Details: Names
On Sunday 15 December 2002 16:01, Christoph Egger wrote: libbse, libgic and libgpf are NO extensions. Thus, how should we mark ggi libs, which are NO extensions? IMO, extensions should be distinguishable from non-extensions by their (package-)names. I clearly seem to fail to understand why this would be important, but anyway, this is not a problem (possibly an aesthetic issue, though). Well, ok... When there are no objections within the next 6 hours, I'll start to rename _all_ ggi libs (libgpf, libgic and libbse) and extensions (libgalloc, libbuf, libovl, libblt, libwmh, libgcp, libvideo, libxmi, etc.) to the form of libgginame. (i.e. libggigpf, libggigic, libggibse, libggigalloc, libggibuf, libggiovl, etc.) I am done with that now. All is in CVS. libwmh and libgcp are repackaged (see http://www.ggi-project.org/modules.html) Martin: Now again, it is your turn :) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: multi threaded... Details: Names
On Sat, 14 Dec 2002, Filip Spacek wrote: On Sat, 14 Dec 2002, Martin Albert wrote: Sorry, if you find i'm insisting or sth. like that. I feel that i have unsolved problems (some more?: eg. module-versioning). Tell me to shut up or to try to do more mindreading about authors reasons for those choices (am i not correct with: building up GGI, concentrating on writing fine libs for the project with easy names, ...) I think your statement is correct and valid. I think libggiwmh has it all: distinction, elegance, few chars to type. Neither variant seems to be able to make both of us happy. Either i'm confused or there are unsolved issues that confuse (me). Decisions should be made before going further with release. Lay out a stable concept with v.2 giving developers a clear view of a stable GGI. Albert Einstein: Halte die Dinge so einfach wie moeglich, aber nicht einfacher. Keep things as simple as possible, but not simpler! If you don't take sth. upon yourself, somebody else _will have to_. greetings, martin (packaging gii, splitting x and really wondering / worrying about module-versions. libgii-target-x or libgii0-target-x is the question here, together with etc/ggi, lib/ggi all along). Well, I suppose my comment was directed more to authors of various extensions about the rather cryptic names of these extensions. Currently there is libwmh, libxmi, libbse, libgic, libgpf, libblt, libbuf, libovl in various stages of development. Maybe I'm just slower than most but meanings of a lot of these don't seem obvious to me. IMHO, flagging them as ggi extension by prepending their name with ggi is certainly a step in the right direction. libbse, libgic and libgpf are NO extensions. Thus, how should we mark ggi libs, which are NO extensions? IMO, extensions should be distinguishable from non-extensions by their (package-)names. As far as packaging of gii goes, if I understand the issue correctly, it boils down to binary compatibility between libgii and its input targets. Currently if a binary incompatile change happens, the only way to keep both versions installed would be to do some very fancy libgii.conf cruft in order to make each of the version of libgii load the proper set of input targets. But given that the loading of input targets is fully under libgii control, I think it is safe to assume that if any such change happens, libgii will provide a mechanism for loading the different versions of input targets. Hence I would tend to think that libgii-target-x should be the right choice. Ack. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: multi threaded... Details
Neil Pilgrim [EMAIL PROTECTED] wrote: I have tested your patch under Linux/i386 and Solaris 8/Sparc32. Tomorrow evening, I can test it under MacOS X/PPC32, too. I've tested this and it works fine for me with Fresco, after prompting from bughunter^WChristoph that it might fix the current problem we have with the rc's. It didn't, but it didn't break anything either :) Good. That's two thumbs up now. Commited. Great! Tnx a lot. I just verified the patch successfully under MacOSX/PPC32. -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: multi threaded... Details
On Sat, 14 Dec 2002, Andreas Beck wrote: Yet another update: 3. One of my applications doesn't correctly update its windows. It draws a picture and then a crosshatch above it and a small figure that can be moved together with the crosshatch. Moving down works fine while moving up/left leaves old crosshatch marks on the screen. That seems to be a real bug. The picture is set by calling ggiPutPixel, while the crosshatch is drawn using ggiDrawHLine and VLine. The Fun Thing is, that when I turn off the crosshatch everything is fine. When turning it back on, everything below the HLine stops updating - the VLine as well as the PutPixels. This goes away, if I use either -noaccel or -nobuffer. Another issue is seen when running a multithreaded part of the app: A visual is written to by two threads, each one calling ggiFlushRegion(state.visrender,0,y,rarg-w,1); for each line the thread has rendered. Funnily I test on a single-proceessor system, and I observe that only the _SECOND_ thread I start sometimes (about 1/3rd of the lines) fails to update the line. This goes away, if I use -nobuffer, but will stay when using -noaccel. Sounds like a broken MIT-SHM X extension. Please check out -noshm, -nobuffer:-noshm and -noaccel:-noshm CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: multi threaded... Details
On Sat, 14 Dec 2002, Andreas Beck wrote: My guess is, that the dirty region tracking code gets messed up by the Hline. Confirmed the GGI_X_CLEAN-Macro contains a bug (I think, it is pretty had to understand) Diff attached, please validate before I commit. Rationale for the changes: Old code was: [...] I spent quite a while thinking this code through, and suppose I got it right. I am not quite sure about the last two ifs in each chain. I think one could use greater/less-or-equal in the comparisions as well, thus correctly handling regions that just touch the borders. I have tested these changes with my application, and it fixes the problems I reported. Could you please go over the code and my comments and have a look, if the fix is right? That stuff is pretty complex to think into, so I am not absolutely positive I didn't mis anything. If a few people confirm my thought, I will commit. I have tested your patch under Linux/i386 and Solaris 8/Sparc32. Tomorrow evening, I can test it under MacOS X/PPC32, too. And your patch works fine for me, so far... Good work! BTW: Eric added a ggiGetCharSize manual page and documented the stuff you mentioned. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: display/kgi.h missing
Hi guys, I'm trying GGI rc5 with KGI target. Compiling display/kgi/mode.c complains that ggi/display/kgi.h is missing. Did I missed something? You found a bug in include/ggi/display/Makefile.am The kgi.h file was NOT mentioned there, thus it was ignored/missed when packaging... Fixed it in CVS now. TNX for reporting. -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: RFC: GGI with Debian
. And libwmh's x-target name would be libggi-extwmh-x-target or something. ggi libs are libs like libgpf and libgic. (libggi-libgpf) The difference between ggi libs and ggi extensions is, extensions are aware of the target, libggi's uses at runtime. In short (hey, you didn't expect that?): If no one answers, i will: - close all bugs wo. further notice, regarding the unavailability of 'visible' output, - hold on current practice: libggi2 'Recommends' libggi-target-... - make as many binary packages as seem necessary to me (promise to do it consciously and responsibly) - name them eg.: libgii, libggi, libggi-extwmh, libggi-libgalloc - still not know how to solve the dependancy issues for users and maint. that cannot read. Is ok with me. You may also have a look at libgcp (http://www.ggi-project.org/libgcp.html) Please, gimme input, i'll sort it out. Maintainers of GGI aware packages, please (re-)consider building with GGI enabled. -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] P.S.: Still haven't seen the buildlogs of -rc5. Not yet builded? +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: libggi2 static compiling
On Wednesday 11 December 2002 00:16, Cserna Zsolt wrote: Hi! I'm writting because I cannot compile my libggi using application statically. The compile command was: gcc -Wall -static -o mpointexample mpointexample.c -L/usr/lib -lggi -I/usr/include -lm -v (-lm for math) The error message: /usr/bin/ld: cannot find -lggi This means no libggi.a was found in /usr/lib. But the debian package doesn't contains libggi.a.. (sorry for my english :) Thanks, Zsolt Cserna ps: I'm using debian sid (last year's edition, from cd.. :) Also hi, my english isn't better ... ;-) Currently there is no provision whatsoever to use any libggi(/any GGI library?) as a static library, sorry. This is an open issue, that should generally be solved but it isn't yet. In general it seems at first glance quite pointless to even try to use libggi statically. Libgg and libggi would actually be linked into your binary, but every other module like display targets, etc. will be loaded at runtime. Besides verifying your interface to libgg and libggi there is no gain to be had when linking static for debugging purposes. There are other scenarios where it would actually be helpful to be able to build binaries that include the libraries and the modules used. Debian has other requirements to demand statically linkable libraries, currently libggi breaks this rule deliberately and as a consequence has to deal with a sticky 'Release-critical' bug report. Please tell the GGI Project why you need that, may be it will get them going ;-) I Cc'd this mail to [EMAIL PROTECTED], the mailing list of the GGI project. Try to return matters of general interest to them, but i assume that you must be a member of the list to write to it. Feel free to mail me, you're welcome. Thanks, martin As you already pointed out, GGI makes practically more useful when dynamically linked. Nonetheless, static linking is on our task list for libggi 2.1. -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: libggi-libwmh-target-x
and the rest finished that far, besides a small issue: IF ( TRUTH = what_you_claim( WMH_IsAn_EXTENSION) ) HOW COMES: it is in /usr/lib/libwmh.so.0.0.1 ? SHOULDN'T THAT BE: /usr/lib/ggi/*/*.so or sth.? No. /usr/lib/ is correct. Applications using it are linked against it, so you need to place it somewhere, where the dynamic linker can find and load it, when the application is starting. /usr/lib/ggi/*/*.so will only work, when this directory is in the linker's default search path. NOW WHAT: default: goto sleep() OR TRY: dlopen libgcp ? ;; BTW: everything else was fine with wmh. :-) ENDOF IT; -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
[ANNOUNCE]5th release candidates for libgii 0.8.2 and libggi 2.0.2 available!
Hi! The GGI Team is proud to welcome the 5th release candidates for libgii 0.8.2 and libggi 2.0.2. See http://www.ggi-project.org/download.html for download links. Please test them out and give us feedback on IRC [1] or here on this list. Changes from libgii 0.8.2-rc4 to libgii 0.8.2-rc5: - added debian's libtool fixes. 'make install prefix=/other/installpath/than/configure' works now. - kii input update from Rodolphe and Filip Changes from libggi 2.0.2-rc4 to libggi 2.0.2-rc5: - added debian's libtool fixes. 'make install prefix=/other/installpath/than/configure' works now. - DirectFB driver update to compile with DirectFB 0.9.13 - configure/build fix: -lXxf86dga_pic and -lXxf86vm_pic is used, if present. Otherwise fallback to -lXxf86dga and -lXxf86vm. Fixes compiling/linking issue on pa-risc archs. Found by debian. [1] irc.freenode.net:6667 channel #ggi -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: KGI, libgalloc and friends.
On Sun, 8 Dec 2002, Andreas Beck wrote: Exactly such an extension does exist: libwmh. Hrm... I always thought wmh was a subvisual window region manager... I guess I should have bothered to look at it :-) Nope. It's quite what you are looking for. I use it quite extensively in eccet. Only thing that I miss is how to query the window manager about decoration widths and how the WM inteprets positioning info (relative to decoration or relative to window content ...) Anyone knowing how to get that info easily and for all windowmanagers is very welcome. It's kind of annoying that my windows are spaced apart differently depending on the WM. BTW: Brian updated libwmh's X target to work with latest version of libggi. I think, you should try it. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: KGI, libgalloc and friends.
On Sat, 7 Dec 2002, Brian S. Julin wrote: On Sat, 7 Dec 2002, Filip Spacek wrote: The greatest issue seems to me how much libgalloc exposes to the exterior. Suppose you want to use overlays. You'd use libovl to do that. Now libovl will go and negotiate that with libgalloc. This means that libgalloc needs to understand overlays as well as libovl. So libgalloc become very complicated since it needs to understand everything about the graphics card. This is simply unnecessary, i.e. libovl should be the only one that understands overlays, it should be libovl that does the resource checking. What if you have more than one interface for using overlays? Well, they can both be capable of checking the overlay resource, as wasteful as it may seem, I seriously doubt we'll ever have two different interfaces for accessing overlays (this is just a practical note). It's actually quite funny that you chose this as your example. I was talking to neiljp of fresco and he may have a proposal for just that instance exactly -- an extension for GGI targets that are window system based to allow access to things like setting the title bar, resizing, and... pointers. If we did this we would have both LibOvl and this other extension potentially contending for any available overlays. Exactly such an extension does exist: libwmh. libwmh provides features for windowed only targets such as resizing, minimizing, window moving, etc. Those features have nothing to do with overlay resources. libwmh tells the window manager what to do with the GGI window. libovl handles overlay resources _within_ the GGI window. That's the difference. So what is so commonly used for us to need some central resource manager? Video RAM. In my opinion, libgalloc should only manage video RAM along with transfering between video RAM and system RAM (i.e. virtualize framebuffer). I one point I had hopes of virtualizing this directly in kgi, but there are too many obstacles to overcome and the benefits are not that obvious. Right now, libgalloc seems like the best place for this. LibGAlloc doesn't just allocate VRAM or other forms of RAM, it formalizes the capabilities that that RAM has. For example, say you had an application that wanted to use an ALPHA pixel channel which was capable of doing top/bottom style blending, but your graphics card only supports over/under style blending. LibGAlloc would be able to tell you this was the case. libgalloc knows _everything_ about the capabilities of its targets from its targets. The user can request resources and features of the resources of libgalloc. The user then knows _how_ to access the resource, but _where_ the resource is actually stored is left to libgalloc's resource management. libgalloc's users are NOT the GGI application writers. libgalloc's direct users are ggi extensions such as libovl, libbuf, libblt... CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: KGI, libgalloc and friends.
On Sat, 7 Dec 2002, Brian S. Julin wrote: On Sat, 7 Dec 2002, Christoph Egger wrote: Exactly such an extension does exist: libwmh. Hrm... I always thought wmh was a subvisual window region manager... I guess I should have bothered to look at it :-) A subvisual window region is/was Rodolphe's baby: libgwt. :-) CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: rc3.deb - final, more deb
in the output. I will, ASAP, close all of them, after i have again tested the relevant applications, that they run fine with GGI in any other respect. Again: -- Don't waste time on these bugs! -- All real bugs have been worked on. I didn't have time lately to _run_ apps ;), but - using svga without configuring svgalib correctly beforehand may make the mouse go wild and - it is clear to me, but users may be puzzled/annoyed by screen switching issues and behaviour after leaving a ggi app. Yeah, there's an known issue, when exiting. Some people say, it's crashing, other people say, it ends up in an endless loop of allocating more and more memory... Actually noone knows what's going wrong... Are there any volunteers, who wanna fix this? Often, another newline is needed to make the shell prompt reappear. I think, noone might reasonably blame ggi for that (and didn't to date). And, as far as i could see up to now, the behaviour is lots better than was with 2.0.1, with the demos at least - congrats! Thanks a lot. - I'm currently working on (new) ggi-doc. - Haven't checked yet, whether ggimisc needs an update. - And yes, the svga wrapper. Least important, though i like the idea very much. As soon as my time permits i'd like to look after it, evtly. have it integrated better with existing svgalib and svgalib-dummy. People have asked for that, me first. Mostly a debian issue, because those pkgs are not installable at the same time, but 'svgalib4libggi' would have to be more complete (and less bug plagued) to be really usable. But imagine, svgalib on a s390 - my own favourite still m68k. Sounds interesting. Unfortunately, svgalib4ggi is lacking a maintainer. So nothing but the common GGI buildsystem updates has been changed. Is/Are there any volunteer(s) on this? - Before going for more pkgs, i'd like to think about and set naming schemes, 'task packages', menus and such, to make it more easy and transparent for users to find all relevant GGI pkgs in debian ( 8000 pkgs). Ideas and suggestions always welcome! Great! - libgalloc (?) still under development. - Dreaming of a GGI driver for cthugha ... cthugha? What's that? - We're doing some shows in jails here between christmas and new year, lots of practicing and preparations still needed and - have a living ;) So, that's for today. May be we can once meet personally and may be i tell you then how GGI spells for me (would be DGA in french) and why i love it so. Keep up the good work and have fun! greetings, martin Tnx a lot. You are really the born packager. :-) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: build fails even quicker
On Tuesday 03 December 2002 06:11, Martin Albert wrote about build If you want to take a look during the day use url: http://buildd.debian.org/build.php?arch=pkg=libggi current version to look for is 2.0.1+rc3-2, and don't forget to think about why that page and the machinery behind it is quite nice ;) It is exciting to see, that things build nicely, even on plattforms where GGI has never been tested before... such as ia-64 and s390! :) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
[ANNOUNCE] 4th release candidates for libgii 0.8.2 and libggi 2.0.2 available!
Hi! The GGI Team is proud to welcome the 4th release candidates for libgii 0.8.2 and libggi 2.0.2. See http://www.ggi-project.org/download.html for download links. Please test them out and give us feedback on IRC [1] or here on this list. Changes from libgii 0.8.2-rc3 to libgii 0.8.2-rc4: - minor kii input update Changes from libggi 2.0.2-rc3 to libggi 2.0.2-rc4: - configure fails now, when libgii is not found or too old. A warning is not enough, since it is too easy overlooked/ignored by users... - Inform user when autoprobing for targets. People believe, they found a bug when an autoprobed target failed to load, just because it is NOT installed. - minor Solaris build fix (should finally compile on Solaris 8) - kgi target compiling fixes - generated manpages for cube3d, ggiteleserver and monitest (manpage volume 1) [1] irc.freenode.net:6667 channel #ggi -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: libggi202rc3 can't build w/o installed libggi
Good morning (TM)! Trying to build libggi ... Directfb has to be disabled, attached the least necessary patches to make it compile anyhow ... Tnx a lot. Directfb-target was last tested against Direct 0.9.12. Which one do you use? Brian: Could you check this issue, please? Here the relevant lines of the changelogs, i hope i've got the unification of display-x right: x, xlib, dga - x + dga? libgii (1:0.8.1+rc3-1) unstable; urgency=low . * New upstream source: upcoming 0.8.2 releases third test candidate. Libgg-0.0.8 comes with demo for cpuid detection in examples. Man pages of event structures install in man3 (closes: #159153). * ltmain.sh updated from Debian libtool 1.4.3-2 to be able to build libgii with uninstalled libgg. What's different between native libtool 1.4.3 and the Debian version? ... * This Debian package of Free Software was sponsored by Angela Jaschinski, feeding fish to the cats to promote packaging works. libggi (1:2.0.1+rc3-1) unstable; urgency=low . * New upstream source: upcoming 2.0.2 releases third test candidate. Display-fbdev includes DirectFB renderer now (disabled). Display-x and -xlib unified to display-x. All manpages no longer use 'ggi' after section. * ltmain.sh updated from Debian libtool 1.4.3-2 to be able to build without installed libggi. * Configure: diff patches a strange construction away, that kept configure from finding the X headers (lead to: -I module.c). Snippet from configure.in you probably refer to: -- dnl This is necessary as there are plattforms, where dnl $ac_x_includes does NOT belong to the default search dnl path. Darwin is such a system, for example. dnl $ac_x_includes contains the right path to the X dnl includes (/usr/X11R6/include on most systems). cflags_old=$CFLAGS cppflags_old=$CPPFLAGS CFLAGS=$CFLAGS -I$ac_x_includes CPPFLAGS=$CPPFLAGS -I$ac_x_includes --- Brian and Paul are Debian users. They didn't complain about such problems (yet). Why doesn't it work for you? I use Darwin/MacOS X, btw. $ac_x_includes is set by AC_PATH_XTRA. Please check, if $ac_x_includes is actually set (and not empty). If not, then there's something going wrong (broken autoconf?). Which autoconf version do you use? Autoconf versions 2.13 and above should work. * Debian/ggiteleserver.1: Add reference to (new) ggiteleserver.7. * Add ggiteleserver.7 to samples package. Move ggi-monitest man page from section 6 to 1. Remove display-xlib manpage from target-x. Eric: Could you change this manpage issue in CVS, please? (Except the xlib one) Any objections? Otherwise i'll upload these testpackages to debian tonight. see above. -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: Some compile problems with kii input
On Sat, 30 Nov 2002, Rodolphe Ortalo wrote: On Sat, 30 Nov 2002, Christoph Egger wrote: I just tried KGI, too. [...] Please update from CVS again. Done. libgii built fine wrt kii/kgi now. Thanks. libggi compiled *nearly* fine, however, libggi configure.in does a AC_CHECK_HEADER(kgi/kgi.h, ... ) in addition of the AC_TRY_COMPILE(..). Apparently, AC_CHECK_HEADER ignores user-provided CFLAGS parameters for gcc. In my case, '-I /usr/local/kgiwip/build/include', so it did not find the header... I removed the AC_CHECK_HEADER test and kept only the AC_TRY_COMPILE (the libgii way) and it ran... The ATI Mach64 compilation failed (due to the HOST_OS and HOST_CPU issue - this one really needs to be solved. I guess configure.in should define these macros based on /bin/arch and /bin/uname results [1]) but the rest went fine. I used the --with-extra-includes option for both libgii and libggi. Works fine for me. Try configure --with-extra-includes=/usr/local/kgiwip/build/include/ However, I also have problems with the man. :-) Have you rerun autogen.sh? make[3]: *** No rule to make target `filter-key.7gii', needed by `all-am'. Stop. make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive-am] Error 2 Rodolphe [1] Use CFLAGS=-DHOST_OS=HOST_OS_Linux -DHOST_CPU=HOST_CPU_i587 $CFLAGS if you want to overidde for Linux on i586 (see kgi/system.h), for some progress. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: Some compile problems with kii input
On Fri, 29 Nov 2002, Rodolphe Ortalo wrote: Hello, When trying to compile libggi libgii (a CVS version from Wednesday IIRC) --with-kii I have a few problems. Hi! I just tried KGI, too. Finally I got the star demo working using the Mach64 driver w/o acceleration. Unfortunately, libgii's input target didn't work, so I was forced to push the reset button to 'exit' the stars demo. I had to fix libgii's kii input target and libggi's kgi-target for this, plus some kii header. I've committed all changes. Up to now, I've been obliged to apply a few fixes to kii.h (see diff) and I'm wondering if there are correct. And as kgi/system.h should be included by kii.h, I now have the following error: /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../input/kii -I../.. -I../../../include -I../../include -I /usr/local/kgiwip/build/include -D_REENTRANT -D_THREAD_SAFE -DDEBUG -g -Wall -c ../../../input/kii/input.c gcc -DHAVE_CONFIG_H -I. -I../../../input/kii -I../.. -I../../../include -I../../include -I /usr/local/kgiwip/build/include -D_REENTRANT -D_THREAD_SAFE -DDEBUG -g -Wall -Wp,-MD,.deps/input.pp -c ../../../input/kii/input.c -fPIC -DPIC -o input.lo In file included from /usr/local/kgiwip/build/include/kii/kii.h:36, from ../../../input/kii/input.c:33: /usr/local/kgiwip/build/include/kgi/system.h:63: #error HOST_OS or HOST_CPU not defined /usr/local/kgiwip/build/include/kgi/system.h:100: #error check this, no type definitions included? /usr/local/kgiwip/build/include/kgi/system.h:112: #error kgi_udelay not implemented /usr/local/kgiwip/build/include/kgi/system.h:120: #error kgi_nanosleep not implemented make: *** [input.lo] Error 1 I got this error, too. That's why, I run the stars demo w/o acceleration. libgii's input driver missed some includes. However, it seems to me kgi/system.h is necessary for the KGI_SYS_DECLARE_INTEGRAL_TYPES(kii)... I must be doing something wrong, for sure. But well, what? Rodolphe PS: Concerning libggi, I get the following output (but well, it may be a little early to worry due to the gii error): Please update from CVS again. # /usr/local/bin/monitest LibGG: unable to open lib: /usr/local/lib/ggi/input/kii.so: cannot open shared object file: No such file or directory LibGGI: failed to load input: kii LibGGI: Failed to set mode: [P8/8] unable to set any mode at all, exiting! identified to mapper graphic-0.9.0-0 Trying mode [] Suggested mode [P8/8] # and an error in kern.log: kgim_display_check_mode:401:E:Unknown command fde8 from monitor. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
GGI on OSX (aka Jaguar) - Update
Hi! I have written a libggi target, that works. It uses the CoreGraphics API for fullscreen display. One known issue is a white background in paletted modes. In conjunction to this, I have also written a libgii input target. It uses the Cocoa API as this provides the needed functionality. Both stuff has been developed and tested under MacOS X Version 10.2.2. Thus, it is not expected to work under 10.1.x or earlier. The dlcompat package is NOT required. GGI uses the native OS loading functions. If you feel you can help out here, enjoy the development! For those, who wanna try them out, there are patches against the -rc2 releases available at ftp://ftp.ggi-project.org/pub/ggi/patches/libgii-0.8.2-rc3.macosx-0.diff ftp://ftp.ggi-project.org/pub/ggi/patches/libggi-2.0.2-rc3.macosx-0.diff The libggi target itself works for me, except for the only one above issue. The libgii input receives both mouse and keyboard inputs now. I am currently fighting with a segfault occuring, when pressing any modifier key or moving the mouse too much around. It hangs the machine on an iBook Another problem is that the received input events are NOT forwarded to libggi/the application. Help is very much appreciated! -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
[ANNOUNCE] 3nd release candidates for libgii 0.8.2 and libggi 2.0.2 available!
Hi! The GGI Team is proud to welcome the 3nd release candidates for libgii 0.8.2 and libggi 2.0.2. See http://www.ggi-project.org/download.html for download links. Please test them out and give us feedback on IRC [1] or here on this list. Changes from libgii 0.8.2-rc2 to libgii 0.8.2-rc3: - minor buildsystem update - moved manpages from volume 9 to volume 3 [2] - changed manpages from manXgii to manX [2] - configure should no longer fail, when no c++ compiler available [2] Changes from libggi 2.0.2-rc2 to libggi 2.0.2-rc3: - minor buildsystem update - moved manpages from volume 9 to volume 3 [2] - changed manpages from manXggi to manX [2] - improved display-X manpage documentation [1] irc.freenode.net:6667 channel #ggi [2] issues found by Martin (our debian maintainer) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: libgii082rc2 can't build w/o installed libgii
Now, i've built from cvs. First, i personally think Eric did the right thing to not move event manpages to 7 but 3, although they do not specifically describe library routines. The .so links still point to (nonexisting) manXggi sections under man. Fixed in -rc3. linux_evdev produces duplicate symbol warnings (uint16). Can't reproduce this under Darwin, so I can't fix it. Anyone else, who can reproduce them? g++ is no longer required: The removal of AC_PROG_CXX did it (thanks christoph). Is there a mailing list for cvs changes? Yes: http://sourceforge.net/mail/?group_id=16307 After several hours and giving up - one last try: libgii still wouldn't build without an already installed libgg. I libtoolized -c -f with debian unstable version - IT WORKS!! ltmain.sh is exactly 1h20 younger than the one in your tree. Version is 1.9.22.111 (yours .110). We use libtool 1.4.3. That's how far i could go today, we have shows to do on the weekend. I'll upload to private server for testing/review as soon as i'm able. In case noone objects, i try to build nice libgii-doc. 'd like to include some sort of a mirror of the mostly visible pages from www.ggi-p.o, they not only look good but have some info not easily found in the docs. I will send a link to the list a few days before actually uploading to debian, so anyone interested might have a look, as i'm (still) lacking any experience with sgml/xml and stuff. I'm now prepared to do cvs packages more frequently (todate i do only pkg released material). Really like to have your input on that matter. We plan to open a stable libgii 0.8.x and libggi 2.0.x CVS branch _after_ final libgii 0.8.2 and libggi 2.0.2 are out. -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
[ANNOUNCE] 2nd release candidates for libgii 0.8.2 and libggi 2.0.2 available!
Hi! The GGI Team is proud to welcome the 2nd release candidates for libgii 0.8.2 and libggi 2.0.2. See http://www.ggi-project.org/download.html for download links. Please test them out and give us feedback on IRC [1] or here on this list. Changes from libgii 0.8.2-rc1 to libgii 0.8.2-rc2: - updated manpages - fixed linking problem on OpenBSD Changes from libggi 2.0.2-rc1 to libggi 2.0.2-rc2: - updated manpages - fixed linking problem on OpenBSD - crossblitting operations are pixelcorrect in all pixelformats now. [1] irc.freenode.net:6667 channel #ggi -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
GGI on OSX (aka Jaguar) - Update
Hi! I have written a libggi target, that works. It uses the CoreGraphics API for fullscreen display. One known issue is a white background in paletted modes. In conjunction to this, I have also written a libgii input target. It uses the Cocoa API as this provides the needed functionality. Both stuff has been developed and tested under MacOS X Version 10.2.2. Thus, it is not expected to work under 10.1.x or earlier. The dlcompat package is NOT required. GGI uses the native OS loading functions. For those, who wanna have a look into the sources, there are patches against the -rc2 releases available at ftp://ftp.ggi-project.org/pub/ggi/patches/libgii-0.8.2-rc2.macosx-1.diff ftp://ftp.ggi-project.org/pub/ggi/patches/libggi-2.0.2-rc2.macosx-1.diff The libggi target itself works for me, except for the only one above issue. The libgii input receives both mouse and keyboard inputs now. I am currently fighting with a segfault occuring, when pressing any modifier key or moving the mouse too much around. Another problem is that the received input events are NOT forwarded to libggi/the application. Help is very much appreciated! -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
[ANNOUNCE] First release candidates of libgii 0.8.2 and libggi 2.0.2 available!
Hi! The GGI Team is proud to welcome the first release candidates of libgii 0.8.2 and libggi 2.0.2. The release candidates are available on our GGI ftp server: ftp://ftp.ggi-project.org/pub/ggi/ggi/v2.0/libgii-0.8.2-rc1.tar.bz2 ftp://ftp.ggi-project.org/pub/ggi/ggi/v2.0/libggi-2.0.2-rc1.tar.bz2 Please test them out and give us feedback on IRC [1] or here on this list. Changes from libgii 0.8.1 to libgii 0.8.2-rc1: - new input target Sharp Zaurus - new kii input target (experimental) - added CPU type detection (experimental) - many bugfixes for multi-visual multi-threaded GGI Applications - many build fixes for Solaris, *BSD - major build system improvements Changes from libggi 2.0.1 to libggi 2.0.2-rc1: - The X target has been rewritten from scratch, making the former x/xlib separation obsolete. The new code is potentially able to query and take advantage of available X extensions (only SHM is implemented right now) - the KGI target has been updated to work with KGI 0.9 Two ATI drivers (Mach64 and Radeon) are available. Note, that this target is still experimental. - added support for truecolor modes to the tele-target plus speed improvements. - added mach64 driver to the fbdev target (experimental) - first start of SWAR [2] support (highly experimental, thus disabled) [1] irc.freenode.net:6667 channel #ggi [2] http://www.tldp.org/HOWTO/Parallel-Processing-HOWTO-4.html -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Re: [ANNOUNCE] First release candidates of libgii 0.8.2 and libggi 2.0.2 available!
I have a question: Should the KGI driver work on a ati radeon 8500 ? The KGI Radeon driver has been developped and tested on rv200 chip based Radeons. The authors [1] say, it should work on rv100, too. I don't know, which chip the Radeon 8500 has. But you are surely welcome as tester. [1] Paul Redmond and Filip Spacek Thank you, Roland Nagtegaal [EMAIL PROTECTED] -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail, Messaging more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
GGI News
Hi! This email is intended for those, who do not follow the discussion on IRC and/or the development in the CVS tree and for those, who are looking forward to the next libgii and libggi releases. We are on the way to make one more bugfix releases of libgii (0.8.2) and libggi (2.0.2). We plan to make the final bugfix releases (after some release candidates) this year. Lots of improvements has been done to increase stability (in particular for multi-threaded and/or multi-visual applications) and performance. The deepest changes are the config.h fix [2] and the X-target [3] rewrite. Both fixes require to update any other GGI extension. Further the build system has been updated to work with recent versions of autoconf and automake. Common improvements for libgii and libggi: - The build system has been updated to work with autoconf versions 2.13 and 2.5x and automake 1.4/1.5/1.6. - libtool has been updated to version 1.4.2, which contains fixes for cygwin, mingw, MIPS archs and *BSD systems. - libtool has been patched with a fix from the KDE-on-Darwin project, to call gcc with the right options, so that libgii is built correctly. Recently, this patch has been accepted by the libtool developers and will be part of the coming libtool 1.4.3 or 1.5. libgii improvements: - libgii's sublib libgg has been ported to Darwin. [1] - multi-threading fixes - The kii-target has been updated to work with latest KGI/KII developments. But note: This target is still experimental. Use it at your own risk! libggi improvements: - The config.h file, which is created by the build system is no longer included from installed headers. It is included from the c-files now instead. [2] - lots of gcc 3.1 fixes - some work has been done for pixel-correct renderers - The X-target has been rewritten. [3] Note, that the Xlib target is still in source tree but is being moved to attic, but that dga is still the target to use for DGA for now until there's a native dga helper. - The KGI-target has been updated to work with latest KGI developments. It has even an ATI MACH64 accelerator. [4] But note: This target is still experimental. Use it at your own risk! - The directfb driver of the fbdev target has been updated to work with directfb 0.9.12. - An ATI Mach64 driver has been added to the fbdev driver. Read the README file before using it! - Truecolor mode support has been added to the tele-target. Some drawing operations has been optimized for speed (i.e. crossblitting) [1] Darwin is not aware of dlopen() friends, so appropriate wrappers has been implemented. The binding and loading system is crappy for the libtool guys :), but it works more like a plugin system with support for error handlers. [2] This has broken all of other GGI libs like libwmh, libggimisc, libgalloc, libbuf, etc. All of them has been updated to compile again. [3] This has broken all X-targets of all GGI extensions (libgalloc, libovl, libggimisc, libwmh and libxmi). The X-targets of these libs still requires an update to work again. The X-target rewrite was necessary to fix strange endianes issues and a design flaw in it. The design flaw forces everyone to write a completely new libggi target just to make use of yet another X-extension. The new X-target just requires a new X helper target using the X extension. The helper target can be seen as a plugin for the X-target. The X-target makes better use of hw accelerated Xlib functions, which really speeds up drawing operations. [4] In KGI, there's a new ATI Radeon driver. So, it is only a question of time, when a Radeon accelerator will follow... All users are encouraged to test the latest CVS versions and report any problems. Q: How to get the CVS version? A: Anonymous CVS access is available. Check out http://www.ggi-project.org/download.html for instructions. Q: I don't wanna risk to destroy and reinstall my current working GGI installation! A: Follow this instructions: mkdir $HOME/ggiroot autogen.sh configure --prefix=$HOME/ggiroot make make install export LD_LIBRARY_PATH=$HOME/ggiroot To uninstall them later simply remove the $HOME/ggiroot directory and reset LD_LIBRARY_PATH to the original value. Q: What's coming next then? A: Depending on the issues people will report us, we will make a libgii 2.0.3 release or we go ahead to libgii 2.1.0. Brian is working on a patch for libggi, which speeds up the software rendering by using MMX and SSE for x86. VIS for Sparc and Altivec for PPC are planned. I will write MacOS X-targets for libgii and libggi. Other planned stuff is mentioned in their TODO files. Q: How to become a GGI developer? A: Provide some patches and we will offer you to get CVS write access :) Documentation is available at http://www.ggi-project.org/documentation.html If you need any assistance, just contact us (http://www.ggi-project.org/contact.html) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] +++ GMX - Mail
Re: RFC: where to check cpuid?
On Sat, 28 Sep 2002, Alex Beregszaszi wrote: Hi, Does anyone know, if gcc 3.x already supports MMX, MMX2, SSE and/or SSE2 ? If yes, then there's absolutely no need to fiddle with asm code around. One way is simply to use Intels C/C++ compiler to make use of these x86 extensions, but it is not as widely used and available as gcc. icc isn't that cool one, hand optimized code is much better Nowadays, c compiler optimizes the code that good, that you can't gain much with handoptimized asm code, except your code uses asm commands, the c compiler is not aware of. Further, asm code forces you to use and maintain lots of #ifdef...#endif blocks to be portable. And that makes the code look more ugly and harder to maintain. And I don't call that hey cool!. I'd prefer to let do this job do the c compiler, whereever possible. Thus, if gcc 3.x supports them, then people just need to upgrade... do not prefer gcc3.x over gcc2.95.4 especially by graphical libs/apps gcc3 (and gcc 2.96.x) is a bit buggy yet with graphical codes. In other words: gcc 3.x supports MMX, MMX2, SSE, etc. but this code is buggy. Is that right? It makes more sense to include support for MMX/SSE optimized codes. Yes, unless the c compiler generates code, that is as good as the hand optimized one. See above. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: RFC: where to check cpuid?
On Sat, 28 Sep 2002, Andrew Pinski wrote: No the buggy code is actually caused by code not following the ISO C aliasing rules aka this is not valid: int temp=1000; double temp1 = *(double*)temp; Do you want to say, that there are sooo many lame coders? IMO, the ggi code is NOT that lame... CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: SIGSEGV bug.
There is a bug in libgii that causes programs to SIGSEGV, when there is no HOME environment variable. Problem is in function ggGetUserDir(). Here is one possible fix: diff -c libgii-0.8.1/gg/misc.c libgii-0.8.1.new/gg/misc.c *** libgii-0.8.1/gg/misc.cSun Aug 26 17:57:18 2001 --- libgii-0.8.1.new/gg/misc.cTue Sep 10 10:25:52 2002 *** *** 52,57 --- 52,59 int len; ptr = getenv(HOME); + if ( !ptr ) + ptr = /; len = strlen(ptr); if (len + APPENDLEN PATH_MAX) return NULL; Ah, great! You found a long outstanding NULL pointer bug! The question is what to do then. Some possibilities: - Should we fail with an error? - Which default path should we use (i.e. /tmp, /)? - Should we print out a warning or not, when using a default path? -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
Re: mingw linking problem
Hi! From IRC: xCabbage C:/mingw/BIN/../lib/gcc-lib/mingw32/2.95.3-6/../../../libmingw32.a(main.o)(.text xCabbage +0x8d):main.c: undefined reference to `WinMain@16' xCabbage ../libtool: .libs/impgen: No such file or directory xCabbage MAKE[2]: *** [libgii.la] Error 127 xCabbage MAKE[2]: Leaving directory `/mingw/libgii-0.8.1/gii' xCabbage MAKE[1]: *** [all-recursive] Error 1 xCabbage MAKE[1]: Leaving directory `/mingw/libgii-0.8.1' xCabbage MAKE: *** [all-recursive-am] Error 2 Does anyone have a glue, what's wrong? Are there sooo many (reading? lurking?) zombies here? :) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
[ANNOUNCE] libgpf alpha1.9
Hi! I am proud to annouce libgpf's alpha1.9 release. Download links are available on http://www.ggi-project.org/libgpf.html New in alpha1.9: * the transfer algorithm has been rewritten to fullfill realtime capabilities * existing targets has been updated to the new transfer algorithm * gcc 3.11 compiler fixes * several bugfixes Known bugs in alpha1.9: * There are visible artefacts, when the transfer speed is pretty slow. * gpftest demo doesn't work correctly on slow transfers. * When transfer speed is pretty high, then it seems to freeze (although it doesn't) instead of doing a constant transfer speed. I wasted some weeks with trying to fix these bugs. So I did the release and hope to get some help... (I can't do cross-thinking easily :) CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: Help wanted to fix g++ 3.11 warnings
box.c: In function `GGI_ati_mach64_fillscreen':
box.c:49: warning: unused variable `yadd'
All such warnings should be easy to fix. Remove the unused variable, or
stick a yadd = 0; in there somewhere so it stops complaining.
This sort of warnings procudes gcc 3, too.
crossblit.c: In function `crossblit_8_to_32':
crossblit.c:263: warning: unreachable code at beginning of switch
statement
Usually occurs if you try to declare a variable inside of a switch
statement.
switch(foo)
{
int bar;
case '. etc..
}
or can be caused by a line of code after a break; like so:
switch(foo)
{
case 1: printf(Hello world);
break;
printf(This will never be reached);
case 2: break;
}
All warning# warnings appear to be deliberately set by the authors of
the
respective source files.
I know of no compiler in existence that could tell you that you needed 1,
2, 4-bit compatibility (or whatever it said).
Yeah, that's a sort of a TODO list for the new X-target... :)
As for the non-system warnings, try this thread below. It seems that
GCC
3.x has a bug(?) that arises when you include an include path twice,
either deliberately or by accident.
http://gcc.gnu.org/ml/gcc/2001-07/msg00434.html
When reading this follow-up
http://gcc.gnu.org/ml/gcc/2001-07/msg00470.html
I think, that is more a feature... :)
libgii is free of these warnings, though. So we should compare the way how
libtool passes the include path's to gcc of libgii and libggi. There _must_ be
a difference, otherwise libggi would be free of these warnings, too!
I don't do much with your GGI source, but I use GGI for some graphics work
and like it a lot.
TNX. Do you use the latest official releases or the CVS version?
Best of luck!
RDB
--
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
A request to all GGI users using the X- and Xlib-target
Hi all! For those, who don't know: Recently, we rewrote the X-target. It is in our latest CVS version. The main intention for this was to get rid of a design mistake, that was made. It forced us to write a complete GGI target for each different functionality (use of an different extension (xf86dga), use hw-acceleration of the X-server (Xlib), emulation of a virtual framebuffer (X)). Thus, the maintainance of it was not that simply. And there are still some users (with some more or less exotic system-configurations), who have problems with getting GGI on X working. The new X-target is likely a hybrid by merging X- and Xlib-targets together. It makes better use of hw-acceleration of the X-server and it is possible to make use of the X-extensions without writing a complete new target such as the xf86dga one. Further, it fixes some endianness bugs, the (old) Xlib target has. The price for this is, that the new X-target is less tolerant to bugs within the X-server. The Xlib-target is currently not removed, but disabled in CVS. The xf86dga-target will be removed as soon as the X-target can duplicate its functionality. We are heading to a libgii 0.8.2 and a libggi 2.0.2 bugfix releases. The X-target of libggi 2.0.1 works fine you? Then you surely expect, that it will work for you once you upgraded to libggi 2.0.2. The X-target of libggi 2.0.1 annoys you with getting problems? Then you surely hope, that they are solved with libggi 2.0.2. In order to avoid you to make bad experiences with libggi 2.0.2, we interced for giving it a try. Note, that you need the latest CVS version of libgii for the CVS version of libggi, too. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: ggi for sale
On Fri, 15 Feb 2002, Andreas Beck wrote: www.ggi.org seems to be for sale for business purpose. File a complaint to internic. That's domain-hogging. www.ggi.org seemed to be selled to a GGI International Inc. Company. And www.kgi.net is for sale CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: DirectX question under cygwin
Well, there's a dinput.lib file, however the libtool message suggests that gcc needs a libdinput.a. Is there some nice conversion/wrapper/hack, then? Sounds to me, that libtool gives gcc wrong information... But I am not sure though... -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net " Description: Binary data
Re: fullscreen GGI window
On Wed, 5 Jun 2002, Kasper Souren wrote: Christoph Egger wrote: libggi itself doesn't provide more than the docs say. But libgalloc offers, what you want. Documentation about libgalloc is available at http://www.ggi-project.org/xmldoc/bk01pt03.html Be aware, that libgalloc is still alpha, so whenever you have problems, we will be glad to help you (by answering your questions, fixing bugs, etc...) There is some information about libgalloc at the link you mention, I know :) but I think I need more documentation to use it to get a fullscreen window. Well, if you mean a fullscreen _display_ by fullscreen window, then how about using fullscreen targets such as xf86dga, svgalib or fbdev? By the way, am I correct when thinking that libgalloc is part of the ggi core? Yes. But it hasn't been majored than libgii and libggi. I'm not sure if it's a good idea to use alpha stuff, That depends on what you want to do. :) If you wanna try out new things, then why not? We would be glad to get some feedback! since I'm finding this out, to help someone who was programming in Atari Pascal 1 month ago. Atari Pascal? Are you about in writing a GGI wrapper? CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: fullscreen GGI window
Hi, How can I open a maximum sized GGI window? The GGI manual doesn't really say how to do this. Or do I have to use a brute force way to do it? Like trying with very big resolutions, and gradually go down to lower resolutions. libggi itself doesn't provide more than the docs say. But libgalloc offers, what you want. Documentation about libgalloc is available at http://www.ggi-project.org/xmldoc/bk01pt03.html Be aware, that libgalloc is still alpha, so whenever you have problems, we will be glad to help you (by answering your questions, fixing bugs, etc...) -- Have fun, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net " Description: Binary data
Re: ggi with gtk - quick question
Peter Jay Salzman writes: hi there, i've seen a demo where an sdl screen is embedded in a gtk application. it stikes me as being a Very Good Idea, making SDL widget libraries obsolete. is it possible to embed a ggi screen (sorry, i don't know the right term here; i've never used ggi before) inside of a gtk application? if so, is there a code sample i can look at? AFAIK a gtk widget has an associated gdk window which itself hides an X window (maybe not still true for gtk 2). So it should be possible to use ggi on this window by using the X/Xlib target with this window id. See the x/xlib display doc on this. Another way is to write a ggi backend for gdk2. Which is maybe not too complicated. There's the GGItk project (http://ggitk.sourceforge.net/), that AFAIK, is trying to do that. Any interested guy should help out there :) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
libgg vs. aglibc
Hi! Tobias Hunger uses glibc 2.2.5. He noticed, that there is no longer an atexit() function, which is used by libgg. Replacing atexit() by on_exit() fixes the problem for him. Before we commit his patch, does anyone know, if on_exit() makes atexit() obselete in (g)libc at all? CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: libgg vs. aglibc
On Sat, 25 May 2002, Christoph Egger wrote: Hi! Tobias Hunger uses glibc 2.2.5. He noticed, that there is no longer an atexit() function, which is used by libgg. Replacing atexit() by on_exit() fixes the problem for him. Before we commit his patch, does anyone know, if on_exit() makes atexit() obselete in (g)libc at all? Usually, I don't reply myself, but just to keep you up-to-date: Talking with the BSD guys via IRC, we figured out, that this is a bug in glibc. It exists in i386-glibc, while it doesn't for arm-glibc. BSD has no on_exit() function in their libc, but they are able to use glibc as well. The BSD folk recommends us to stay at using atexit(), because it conforms to BSD 4.3 and ISO 9899, while on_exit() is very likely a GNU extension. Further, we should not use broken versions of glibc. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: Add default/color_r ??
My read of the current source tree is that there is no generic support for 16,24,32-bit reverse-endian pixfmts. 24 will require it's own renderer, but if we were to add a color_r.so we should be able to provide support for 16 and 32 with just that (assuming the fb base pointer is aligned, a relatively safe assumtion in the majority of cases.) Am I missing anything, or does this sound like the way to go? Doesn't the pixfmt's bit masks/shifts already include reversed endian support? (Christoph -- the old X code may imply that ImageByteOrder is something you set, but to me it looks as if it's something that is carved in stone. I don't know. I haven't looked deeply enough in the X code. It may take a color_r lib to get correct colors on your XCeed server.) Only the old Xlib-target is affected by wrong endianess assumption (little endian machine == LSBFirst). The old X-target works ok. BTW: Correct spelling is Exceed :-) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
ideas ggi_pixel expansion?
Hi!
Matrox and 3DLabs will release new chipsets in August - Parhelia and P10.
Parhelia uses 10bits for each color channel (r,g,b,a).
So the 32bits the ggi_pixel has won't be sufficient any longer to support
future chipsets.
ANSI C99 defines a long long integer type with 64 precision, which can be
used for that. The problem is, that there are still too many plattforms, that
don't complain the ANSI C99 really _completely_!
(Further, GGI applications assuming that ggi_pixel is always uint32
respectively unsigned int will get broken then. But that is a task for the GGI app
maintainers to fix up.)
So I suggest to expand ggi_pixel to unsigned long long for ANSI C99
compatible plattforms and (someting like) this for ANSI C89 (and older) plattforms:
typdef struct ggi_pixelfmt_t {
uint32 lowerpixel;
uint32 higherpixel;
};
extern ggi_pixelfmt_t pixelfmt;
#define ggi_pixel pixelfmt.lowerpixel
Another suggestion is to expand ggi_pixel as described above and say, that
non ANSI C99 compatible plattforms must live with the fact to not being able
to use the new features of future chipsets.
Is there somebody, who has better ideas?
--
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
Re: display-memory enhancements
Now in CVS for your enjoyment... numerous improvements to display-memory, some of which I needed for the new X target I'm working on: 1) frames support 2) new -pixfmt option for nontrivial pixelformats (bgr, etc.) 3) new -layout option for planar and strided framebuffer layouts 4) new -noblank option prevents buffer from being fillscreened black on setmode (for use with preallocated framebuffer.) The last one I haven't verified working yet, and of course you can never torture code enough these days. So have at it. Brian: I guess, you forgot to commit the changes of ggi/display/memory.h, because the memory target doesn't compile right now. -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net " Description: Binary data
Re: mac OSX
hello, im a Macintosh OSX user w/ little to no unix knowledge. i know since OSX is based in unix know you CAN run linux apps. ive been attempting to configure xscorch, a unix port of the old DOS game Scorched Earth, and requires libggi. i have tried to load this, but have encountered errors. these errors could very likely the result of my lack of knowledge, but i thought maybe someone on this list could help. is there an OSX 'version' of libggi? is there something else i need to load it? thanks for any assistance anyone out there can offer, Jack, we must tell you, that you are the _first_ guy, who ever tried to get GGI running under Mac OS. So this is a very new area for us as well. We have the Unix knowledge you lack of, and you have the Mac OS/PPC knowledge we need. :) Therefore, please give us as much information about your system as you can (both software and hardware). And thus, libggi has no target to for Mac OS to draw something on the screen. But that doesn't mean, that it is impossible to get running. For example, I know of an existance of a X-server for Mac OS X. It is called XDarwin. Once you get it running on your system, then you can use libggi's X-target, which should work. If not, we will fix it up (with your help about your system, of course). -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
findleaks
Hi! It seems, that we have some memory leaks in libggi. I have attached the outputs of GGI_DISPLAY=aa findleaks GGI_DISPLAY=terminfo findleaks GGI_DISPLAY=xlib findleaks in the given order. Can anyone confirm them? CU, Christoph Egger E-Mail: [EMAIL PROTECTED] ... ggiInit() Used before : 1404, after: 1408, Change: 4 Alloced before: 0, after: 0, Change: 0 .. ggiOpen() Used before : 2892, after: 2892, Change: 0 Alloced before: 0, after: 0, Change: 0 ggiCheckSimpleMode() Used before : 2892, after: 2988, Change: 96 Alloced before: 0, after: 0, Change: 0 ggiSetSimpleMode() Used before : 3212, after: 3240, Change: 28 Alloced before: 0, after: 0, Change: 0 uninitializing ggiExit() Used before : 1380, after: 1576, Change:196 Alloced before: 0, after: 0, Change: 0 ... ggiInit() Used before : 1404, after: 1408, Change: 4 Alloced before: 0, after: 0, Change: 0 ggiOpen() Used before : 1776, after: 1816, Change: 40 Alloced before: 0, after: 0, Change: 0 .. ggiCheckSimpleMode() Used before : 1816, after: 1816, Change: 0 Alloced before: 0, after: 0, Change: 0 Fatal error: Unable to set default mode! ... ggiInit() Used before : 1404, after: 1408, Change: 4 Alloced before: 0, after: 0, Change: 0 .. ggiOpen() Used before : 2476, after: 2476, Change: 0 Alloced before: 0, after: 0, Change: 0 .. ggiCheckSimpleMode() Used before : 2476, after: 2476, Change: 0 Alloced before: 0, after: 0, Change: 0 .. ggiSetSimpleMode() Used before : 2800, after: 2800, Change: 0 Alloced before: 0, after: 0, Change: 0 ggiExit() Used before : 1380, after: 1616, Change:236 Alloced before: 0, after: 0, Change: 0
Re: xcol palette problems
On 24 Apr 2002, Gerard Braad wrote: Set the env variable GGI_DEBUG=255 and send me the output, please. This helps me to track down the problem better. (run as root, with debug) Trying mode F1.[] Suggested mode 640x480.V640x480.F1.D1x1.[C16/16] Segmentation fault ldd dump: libggi.so.2 = /usr/local/lib/libggi.so.2 (0x40017000) libgii.so.0 = /usr/local/lib/libgii.so.0 (0x40022000) libgg.so.0 = /usr/local/lib/libgg.so.0 (0x40029000) libdl.so.2 = /lib/libdl.so.2 (0x4004d000) libc.so.6 = /lib/libc.so.6 (0x40051000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) The usual output. That says nothing about why it crashs. gdb dump: Starting program: /home/g_braad/files/devel/ggi/libggi/libggi-2.0.1/programs/demos/.libs/demo Trying mode F1.[] Suggested mode 640x480.V640x480.F1.D1x1.[C16/16] Program received signal SIGSEGV, Segmentation fault. 0x40031991 in GGI_X_flush (vis=0x804e900, x=0, y=0, w=640, h=480, tryflag=1) at mode.c:156 156 xcol.red = vis-palette[x].r; Ah - you use the X-target, because of the GGI_X_flush(). Which value has x here? Which values has priv-xwin.cmap_first and priv-xwin.cmap_last here? Have you tried latest CVS sources? There are some more bugfixes. tried those too... same problem... ok. Please set the environment variable export GGI_DEBUG=255 and send me the output. This helps me to track down the problem better. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: Mach64 fbdev driver for libggi
On Sat, 6 Apr 2002, [ISO-8859-1] Daniël Mantione wrote: On Fri, 5 Apr 2002, Christoph Egger wrote: That's really nice! I have looked through the code and it looks really good to me. I have a ATI Rage XL card, which belongs to the mach64 family. Unfortunately, I can't test your code, because the native mach64 driver doesn't work for me. It messes up my screen, when setting up the mode. (I use the 2.4.17 linux kernel) You mean the Atyfb? Yes. Well, I have done some work on that lately. The Atyfb did't support LCD monitors and that's quite annoying on a laptop; this is what started it all. Besides the LCD support I also did add the 4 bpp modes and fix a few bugs. Maybe it works better work you. Shall I send you it? Yes, please! What exactly goes wrong? I am trying the atyfb driver since kernel 2.4.10 to see if it works. (I am using 2.4.17 right now) When doing modprobe -a atyfb then a default mode is set, but the screen is blank. I see nothing then. I have to reboot my machine to be able to see something again. Here is the log: --- Dec 2 13:27:53 athene kernel: atyfb: 3D RAGE (XL) [0x4752 rev 0x27] 8M WRAM, 14.31818 MHz XTAL, 230 MHz PLL, 120 Mhz MCLK Dec 2 13:27:53 athene kernel: Console: switching to colour frame buffer device 80x30 Dec 2 13:27:53 athene kernel: fb0: ATY Mach64 frame buffer device on PCI Dec 2 13:27:57 athene kernel: not enough video RAM --- Well, I have a ATI Xpert 98 PCI graphic card: Chipset: 3D RAGE XL RamDAC: mach64 internal Clock: mach64 internal RAM: 8MB SDRAM BUS: PCI The driver detects everything correct, except the TYPE of onboard-RAM: I have SDRAM and no WRAM. And I don't know, why 8MB shouldn't be enough to set up a mode... As soon as it will work, I can test your code. BTW: I can give you CVS write access, when you send me your login name at SourceForge. Then you can add/commit your driver and further fixes yourself. It's dmantione. But I don't expect I'm going to be a big contributor to the project. hmmm who knows? :) A problem that it still has is that it only works in 8 bpp. Other pixel depths should work, but for some reason GT_DEPTH returns 18 in 16 and 32 bpp modes, so the engine is not correctly initialized. If this is fixed, I expect 16 and 32 bpp will work too. 24 bpp still needs some work. I CC' this mail to the GGI ML. Maybe that there is anyone, who knows a solution or can give you some hints at least. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: Mach64 fbdev driver for libggi
On Wed, 3 Apr 2002, [ISO-8859-1] Daniël Mantione wrote: Hello, This weekend I started programming on a fbdev acceleration driver for libggi. It was very easy, some procedures even worked without any debugging at all. I just came to the conclusion that I have already implemented all important procedures. So I would like to send your the code. That's really nice! I have looked through the code and it looks really good to me. I have a ATI Rage XL card, which belongs to the mach64 family. Unfortunately, I can't test your code, because the native mach64 driver doesn't work for me. It messes up my screen, when setting up the mode. (I use the 2.4.17 linux kernel) As soon as it will work, I can test your code. BTW: I can give you CVS write access, when you send me your login name at SourceForge. Then you can add/commit your driver and further fixes yourself. A problem that it still has is that it only works in 8 bpp. Other pixel depths should work, but for some reason GT_DEPTH returns 18 in 16 and 32 bpp modes, so the engine is not correctly initialized. If this is fixed, I expect 16 and 32 bpp will work too. 24 bpp still needs some work. I CC' this mail to the GGI ML. Maybe that there is anyone, who knows a solution or can give you some hints at least. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: more freebsd problems
On Sat, 30 Mar 2002, Jeffrey Drake wrote: I have just tried ggi with svgalib and it didn't freeze the computer this time, it rebooted it. I guess, this happens when exiting, right? There is a known bug in the svgalib target. On my machine, the app allocates continously memory until it gets killed by the OS or by me. On other Linux Boxes, the apps just crashs... I am thinking i will have to use X windows, but I would like to avoid that if I can. Can anyone offer some advice on what to do? Does something like Linux/fbdev also exist on FreeBSD? Also, I have tried to configure ggi with '--with-gii=/usr/local' and it does the same message. Any help here would be appreciated. I would really like to know if anyone has gotten ggi to work without X on freebsd. Nicolas Souchu [EMAIL PROTECTED] is the author of the vgl target. I guess, he did it. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: is this a kgi driver?
On Sat, 30 Mar 2002, Jeffrey Drake wrote: Is this a kgi style driver or is it a vgl? http://people.freebsd.org/~nsouch/download/ggi/s3pci.c According to http://people.freebsd.org/~nsouch/ggiport.html, this is a vgl driver he wrote to get rid of the VESA BIOS mess mentioned by Brian. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: ggi and freebsd
On Sat, 30 Mar 2002, Jeffrey Drake wrote: I am trying to get freebsd and ggi to work. I have downloaded the latest releases. I tried the cvs but couldn't get configure properly built and working. When you use the CVS sources, the configure script must be generated before. The autogen.sh script does this. If it makes you troubles, then please give us the output you get. Everything compiled find, with the exception that ggi's configure script complained (but not fatally) that it couldn't find gii, even though I installed gii right before hand. Try the --with-gii configure option. After compiling, and told it to use the kgl display target, and ran a program under the programs subdir. kgl? You mean the (obseleted) kgi target? The program would change display modes, the screen would turn green and freeze the entire machine. I have since loaded 'vesa.ko' kernel module, and it identified my card, but still caused the same problem. AFAIK, kgi on FreeBSD can't work, because the port of KGI to FreeBSD in a work in progress. Nicholas: What's the status of the port of KGI to FreeBSD? I do not have X installed let alone running. I imagine it is potentially possible that gii might not be found, but that shouldn't cause a freeze. Jeffrey: But there's a vgl target, you can/should try. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] libgpf - alpha1 release
Hi all! I am very pleased to announce the first official release of libgpf - alpha1. version: alpha1 Release-Date: 2002-03-29 Download links: http://ggi.sourceforge.net/ftp-data/libs/libgpf-0.1.0.tar.bz2 ftp://ftp.ggi-project.org/pub/ggi/libs/libgpf/libgpf-0.1.0.tar.bz2 The gpftest demo transfers for rectangles - red, green, blue and white in the given order with a yellow background - drawn onto a memory visual to a default visual. The image_viewer demo transfers the ggi_logo.ppm file onto a default visual. Both demos has been tested successful under various environments: - Linux/X with 16 and 24bit (rgba ordered) - Linux/X with 24bit (palemu target and rgba ordered) - WinNT/X with 32bit (abgr ordered) - Irix/X with 8bit (rgba ordered) - Linux/aalib - Linux/fbdev with 16,24 and 32bit @ 640x480 resolution Note: The fbdev tester changed image_viewer to use a 640x480 ppm file Great thanks to all testers - Paul Redmond, Cruz Vincent, Bernhard Fischer, Eric Faurot and all others. The documentation is included in the libgpf package. The documentation includes: * Introduction - What is the intention behind/of libgpf * The big picture - Overview about libgpf * User-Docs and -API - How to do what? * Developer-Docs - Deep insight into the deep dark magics 8) * Developer Writing Guides - How to make libgpf more popular ;-) Known-Issue: The resolution of the output must exactly equal with the source, otherwise the result appears wrapped. Removing this limitation is the main task for the alpha2 release. Have fun - be happy, Christoph Egger E-Mail: [EMAIL PROTECTED]
libgpf: Testers wanted (was: Re: libgpf: alpha1 release is veryclose)
On Tue, 26 Mar 2002, Christoph Egger wrote: Hi all! The alpha1 release of libgpf is very close. The gpftest demo works on all tested video modes (8,16,24 and 32bit). The documentation is up to date. The image_viewer shows the GGI logo. I have it from http://www.ggi-project.org/ and converted to a ppm file. image_viewer shows the GGI logo wrapped on all tested video modes (see gpftest). Further the colors are not correct: The first G is blue instead of red and the I is red instead of blue. The second G appears green and the background appears white, which is correct. As soon as image_viewer shows the GGI logo correct and no further bugs are found, I am going to release libgpf alpha1. I need as much help as possible for this. libgpf is in CVS. At http://www.ggi-project.org/download.php are instructions for anonymous CVS. Today (or better: yesterday as it is after midnight now :), I found and fixed the above bugs. I am going to package and release libgpf's alpha1 after I got some more testings. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
libgpf: alpha1 release is very close
Hi all! The alpha1 release of libgpf is very close. The gpftest demo works on all tested video modes (8,16,24 and 32bit). The documentation is up to date. The image_viewer shows the GGI logo. I have it from http://www.ggi-project.org/ and converted to a ppm file. image_viewer shows the GGI logo wrapped on all tested video modes (see gpftest). Further the colors are not correct: The first G is blue instead of red and the I is red instead of blue. The second G appears green and the background appears white, which is correct. As soon as image_viewer shows the GGI logo correct and no further bugs are found, I am going to release libgpf alpha1. I need as much help as possible for this. libgpf is in CVS. At http://www.ggi-project.org/download.php are instructions for anonymous CVS. -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net " Description: Binary data
Re: X targets
On Sun, 24 Mar 2002, Andreas Beck wrote: Brian S. Julin [EMAIL PROTECTED] wrote: In the case of x vs xlib, it strikes me that the back-buffer/flushing behavior and the Xlib accel behavior could cooexist happily as two options in the same driver, what when both enabled would provide the best performance in the genaral cases (same host or network). In principle yes, but you's need to sync the framebuffer contents with the accelerated drawing operations as well, as otherwise the next flush would overwrite already drawn contents. In the case of the DGA target, it appears to me that XQueryExtension() is a core Xlib function and could be used to enable/disable DGA support. Default behavior would then be to check to see if DGA will work, and if not, simultaneously draw in memory and using X primitives and turn on flushing if/when the directbuffer is aquired. Ah - I see. On IRC we (Brian and I) decided to create a bunch of helper-targets for the X one. For example, a helper-xsync using the SYNC X extension can replace the mansync helper, _if_ available. Having a helper-xbuffer target adds the functionality of the buffer X extension. It provides double-, multi- and stereo-buffering. The double/multi-buffer feature can be used for having _real_ directbuffers. The other features can be used in libgalloc/libbuf. Specifications of all _standard_ X extension can be downloaded from: ftp://ftp.x.org/pub/R6.6/xc/doc/specs/Xext/ I just don't know how he will structure the directories. Too many x-helpers shouldn't be in the display root directory. They should be in a sub-directory inside the x-target instead. The point is, I won't flood the display directory causing us loosing the overview, even when we make a 'ls', for example. Brian: Does GGI extensions X/Xlib-target (libggimisc and libwmh) require an update then? If yes, will it be a small task? Andy: libwmh is your baby AFAIK. In case of an required update and while you are about it then, you can write a helper-xshape target, which allows us to have windows with rounded corners, for example. :) Does someone know the original reason why the DGA target kept a private implementation of the XFDGA protocol extension? This is due to a horrid versionning nightmare while the XFree 3-4 Transition, where we found that many systems had broken headers and would not compile right. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: tree reorganisation - core/module separation
Christoph Egger writes: Extension sublibs source trees will use these files in order to access target-private structures. All the extensions may currently be ours and in GGI CVS, but there's no guarantee that things will stay that way. If company XYZ is developing an in-house extension technically they should be able to compile it with only the GGI development headers installed. If there is a way to still allow this with Eric's suggestion, then we go his way, IMO. Well, I see nothing wrong with keeping these headers in the module directories, and install them with the lib itself. But then we have to make sure, that both the lib and the headers are in the right directories to not break the compiling process for extension targets using them. Well, said app is so simple it isn't worth it's own inode, The application may not be very complicated but it can help installing modules automatically. That can also be done by providing a versioning system as suggested by Alex Beregszaszi on this list. but I agree with the major point, being discrete module build/install would be a neat feature. Being able to plop a target subdirectory into the source tree and include it in the build by only editing 1 or 2 simple files would be sweet. Indeed We could enforce this by taking the whole display/input dir out of the libs tree and create a separate 'modules' repository, with one subdir for each lib/extension. Then we could provide separate releases for driver updates. No, please don't. That would become too complicated and convusing for developers, IMO. The number of extensions and libs will increase in future and not reduced. We should rewrite/redesign the build system in a way, that we can package and release each driver separately from the whole GGI extension/lib instead. BTW, I'm not sure I understand the 'default/' in libgii. AFAIK, it's for generic code that can be shared by different targets. So it's ok for linear_*, but why fbdev is not in display? And there are lots of kgi stuff too... That's a really good question. I don't know, who did that. IIRC, that was already done before I tested GGI the first time years ago. :) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net " Description: Binary data
Re: LIBGGI: security patch
O.K. - this is the reasonable behaviour and I think we should check for it in the configure process. If it's not there, we might want to bring along a free implementation in the long run. IMO if it's going to be this much work to A) determine if snprintf is present, B) implement our own snprintf and C) actually figure out if the offered implementation is doing the right thing with the null terminators, or if it is an old crusty one that wasn't quite implemented right and noone ever noticed, we should just code around the whole problem and just rewrite things safely without using it. When we go this way, then libgg is IMO the right place. -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net " Description: Binary data
crash in libgii/gii/gii.c
Hi all! I am about testing the libgpf's image_viewer demo in my working tree. That demo should transfer a ppm picture to a ggi visual and then it waits for any key being pressed (via ggiGetc()). But the crash happens _before_ I press any key. I can reproce that bug just by restarting the demo again and again. Has anyone any idea, what goes wrong? Here are the last lines of the GGI_DEBUG=255 output plus the backtrace of gdb: - LibGGI: GGI_X_flush(0x804b090, 1) called LibGGI: _ggi_x_do_blit(0x8051290, 0x0, 209x100) called LibGII: giiEventPoll(0x8051440, 0xa0, (nil)) called LibGII: _giiPollAll(0x8051440, 0xa0, (nil)) called LibGII: GII_xwin_eventpoll(0x8051440) called LibGII: giiEventPoll: starting non-polled loop LibGII: _giiPollAll(0x8051440, 0xa0, 0xb4cc) called LibGII: GII_xwin_eventpoll(0x8051440) called LibGII: _giiPollAll(0x8051440, 0xa0, 0xb4cc) called LibGII: GII_xwin_eventpoll(0x8051440) called LibGII: GII_xwin_eventpoll: MouseMove 155,53 LibGII: _giiEvQueueAdd(0x8051440, 0xb1cc) called Program received signal SIGSEGV, Segmentation fault. 0x400e73d7 in chunk_alloc () from /lib/libc.so.6 (gdb) bt #0 0x400e73d7 in chunk_alloc () from /lib/libc.so.6 #1 0x400e6f64 in malloc () from /lib/libc.so.6 #2 0x400618a2 in _giiEvQueueSetup () at gii.c:98 #3 0x40061f25 in _giiEvQueueAdd (inp=0x8051440, ev=0xb1cc) at gii.c:393 #4 0x4019a951 in GII_xwin_eventpoll (inp=0x8051440, arg=0xb4cc) at input.c:398 #5 0x4006256e in _giiPollall (inp=0x8051440, mask=160, arg=0xb4cc) at gii.c:583 #6 0x40063ba8 in giiEventPoll (inp=0x8051440, mask=160, timeout=0x0) at unix.c:237 #7 0x40063053 in giiEventRead (inp=0x8051440, ev=0xb5a4, mask=160) at gii.c:1006 #8 0x40057a64 in ggiGetc (vis=0x804b090) at events.c:96 #9 0x8048bb0 in do_demo (vis=0x804b090, filename=0x8048d98 file:./ggi_logo.ppm) at image_viewer.c:60 #10 0x8048c90 in main (argc=1, argv=0xb78c) at image_viewer.c:117 #11 0x400907ee in __libc_start_main () from /lib/libc.so.6 (gdb) up #1 0x400e6f64 in malloc () from /lib/libc.so.6 (gdb) up #2 0x400618a2 in _giiEvQueueSetup () at gii.c:98 98 qp = malloc(sizeof(gii_ev_queue)); (gdb) up #3 0x40061f25 in _giiEvQueueAdd (inp=0x8051440, ev=0xb1cc) at gii.c:393 393 qp = _giiEvQueueSetup(); (gdb) up #4 0x4019a951 in GII_xwin_eventpoll (inp=0x8051440, arg=0xb4cc) at input.c:398 398 if (giiev.any.type) _giiEvQueueAdd(inp, giiev); (gdb) up #5 0x4006256e in _giiPollall (inp=0x8051440, mask=160, arg=0xb4cc) at gii.c:583 583 retmask |= (curr-GIIeventpoll(curr, arg) mask); (gdb) up #6 0x40063ba8 in giiEventPoll (inp=0x8051440, mask=160, timeout=0x0) at unix.c:237 237 tmpmask = _giiPollall(inp, mask, allfds); (gdb) up #7 0x40063053 in giiEventRead (inp=0x8051440, ev=0xb5a4, mask=160) at gii.c:1006 1006giiEventPoll(inp, mask, NULL); (gdb) up #8 0x40057a64 in ggiGetc (vis=0x804b090) at events.c:96 96 giiEventRead(vis-input, ev, emKeyPress | emKeyRepeat); (gdb) up #9 0x8048bb0 in do_demo (vis=0x804b090, filename=0x8048d98 file:./ggi_logo.ppm) at image_viewer.c:60 60 (void) ggiGetc(vis); -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net " Description: Binary data
Re: crash in libgii/gii/gii.c
I can reproce that bug just by restarting the demo again and again. Has anyone any idea, what goes wrong? That sounds like Heap corruption, because: Program received signal SIGSEGV, Segmentation fault. 0x400e73d7 in chunk_alloc () from /lib/libc.so.6 (gdb) bt #0 0x400e73d7 in chunk_alloc () from /lib/libc.so.6 #1 0x400e6f64 in malloc () from /lib/libc.so.6 #2 0x400618a2 in _giiEvQueueSetup () at gii.c:98 When something faults in an allocation-function, it is usually Heap corruption. Try linking with efence to find the offending code. Ah - TNX. That lead me back to the knowing libgpf bugs. :) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net " Description: Binary data
libgpf: Status
Hi all! Current state: It pipeline management is almost done. The gpftest demo transfers for rectangles - red, green, blue and white in the given order - drawn onto a memory visual to a default visual. RAW data transfer works. that, when you use a 16bit video mode. You should see that, when you use a 16bit display On non-16bit modes, conversion is enabled automatically. On RGBA-ordered displays, only the blue part works, the red and green part gets lost somehow. On ABGR-ordered displays, only the red part works. If you can consider, what could be wrong, I'd be glad to get your help. The image_viewer demo transfers the ggi_logo.ppm file onto a default visual. Only a blue pattern appears on the screen on RGBA-ordered displays. ABGR-ordered displays shows a red pattern. On 16bit modes, it segfaults. If you can consider here, what could be wrong, I'd be glad to get your help. As soon as these two demos works correctly, the alpha1 release will come out. Currently, it is only in CVS available including its documentation. I would be very pleased, if people starts reading the documentation and asking me remaining questions... -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net " Description: Binary data
Re: Query about an issue (a BUG): Any samples ?
We found a Bug listed in TODO list - Both X and Xlib targets don't handle the colors correctly, when Xserver uses ABGR insted of RGBA That is the bug, I found and added to the TODO list. Can somebody explain this with a sample ? Yep. Exceed is a Xserver for Win32. It uses the rgb colorspace, but not in the usual order: ABGR instead of RGBA. The bug is reproduceable, when you use such a Xserver. Just start any application using X or Xlib. On X, you'll notice, that the colors are _not_ correctly displayed. On Xlib you have to go through the tile-target to get the directbuffer. The directbuffer assumes that rgb-colorspaces are always RGBA ordered, which is _not_ always true. I don't know, if other targets than X/Xlib has this bug, too. That bug has been discussed last year in November/December. Go through the GGI ML and search for the subject libggi: Bugreport. Is anybody working on this (fixing this) ? Nope, because of lack of time. I am busy with other things (i.e. libgpf) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
libgii: empty configure file
Hi! I type autgen.sh, and get this output: --- configure.in:252: error: AC_LANG: unknown language: aclang.m4:124: _AC_LANG_SET is expanded from... aclang.m4:133: AC_LANG is expanded from... ./aclocal.m4:3456: AC_CHECK_WINFUNC is expanded from... ./aclocal.m4:3471: AC_CHECK_WINFUNCS is expanded from... configure.in:252: the top level autoconf: tracing failed automake: reading configure.in [...] configure.in:252: error: AC_LANG: unknown language: aclang.m4:124: _AC_LANG_SET is expanded from... aclang.m4:133: AC_LANG is expanded from... ./aclocal.m4:3456: AC_CHECK_WINFUNC is expanded from... ./aclocal.m4:3471: AC_CHECK_WINFUNCS is expanded from... configure.in:252: the top level --- Then I can't call configure, because it's an empty file... Is this a obscure bug in libgii's autoconf/automake build system or is this a configuration error of the machine, I am currently working on? -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
Re: GGI version and mode problems
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]
GGI version and mode problems
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? [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:53] bughunter ([EMAIL PROTECTED]) left irc: using sirc version 2.211+KSIRC/1.1 [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 [15:54] al3x ([EMAIL PROTECTED]) left irc: BitchX: it keeps going and going and going and going and... -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
GGI site is online (was: Re: Domain)
Hi all! Exciting news: I now have control on the domain and I set the new nameservers today. Every thing should be working within 24hrs. If somebody could set up a mail server for ggi this would be perfect! ftp.ggi-project.org works for me (tm) www.ggi-project.org refers to a ibiblio page Hi all! For those, who are NOT watching the IRC discussion: From IRC soyt www.ggi-project is back online! soyt .org of course. soyt hurray! soyt They commented out the virtual host settings since the dns were not responding. A more detailed explanation about what happened in the last episode is available on the GGI news site http://www.ggi-project.org/ :) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
Re: Domain
Hi all! Exciting news: I now have control on the domain and I set the new nameservers today. Every thing should be working within 24hrs. If somebody could set up a mail server for ggi this would be perfect! ftp.ggi-project.org works for me (tm) www.ggi-project.org refers to a ibiblio page -- Just to let you know, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
Re: config.h issue
Hi all. I'm polishing up the python wrapper before commiting it to cvs, but I'm stuck on this annoying issue: 'config.h' included in 'ggi/internal/gii.h' refers to the file generated by the configure script for libgii. The problem is that this file is only present in the build tree, so if another code requires this header (gii.h), the build will either break in the best case, or silently include another 'config.h' which IMHO is not desirable. Is there a workaround or is it a 'sad but true' thing I have to do with? There are two solutions: a) Write a README file, saying to build libgii before b) Rewrite the Python wrapper, so that it doesn't require any config.h file -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net " Description: Binary data
Re: ggi for sale
On Sat, 16 Feb 2002, Stefan Seefeld wrote: Emmanuel Marty wrote: Andy, I've accepted the transfer of ggi-project.org to another registrar (GANDI) so that Eric Faurot can manage it from now on, but for some reason network solutions rejected it twice. I'm in a similar position myself. We'v just got a new domain at netsol, 'fresco.org'. (yes, we are going to rename berlin to fresco in the coming weeks). The domain fresco.org existed, but I only got the domain two weeks ago. Now I tried to transfer it to gandi. This was refused by netsol, apparently because the domain needs to exist for at least 60 days. They probably mean by this the domain needs to be owned by the current owner for at least 60 days. I'll have to retry the move in two months again. And in case anybody cares, we are using zoneedit.net to manage our DNS... But the ggi-project.org exists far longer than 60 days, so I don't understand, why this should matter... CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: GGI and its future
On Mon, 28 Jan 2002, Curtis Veit wrote: On Sun, Jan 27, 2002 at 11:21:55AM +0100, Christoph Egger wrote: Curtis wrote: [...] I may actually get enough background to start fixing up and adding pieces to GGI. I'll be playing with libbuf and libblt and libovl quite a bit I think. The development of all these three libs is mainly bottlenecked by two things: 1) libgalloc needs to turn into a more major state Is discussion about this ongoing? Perhaps we should discuss what is needed on the GGI list. Not really. Sorry. Only Brian and I are involved in the todo list (and perhaps Eric a little). Brian left his latest work on libgalloc unfinished (i.e. releasing of resource issue, missing bugfixes). Then the targets needs an major update. Brian: Could you be a bit verbose on this points, please? 2) libovl, libbuf and libblt needs to interact on each other transparently to the user yes, I'll see how well these work in my situations soon. Any ideas are welcome. There are no stupid ideas, only stupid ways of implementations... :-)) These points done means a BIG milestone in the development of the whole GGI project. I also plan to use the batch-ops. Having at least a framework of the batch-ops working is a requirement to get point 2) done. I think batch-ops done correctly will be a key element in the foundation. I'll start rereading the docs from Brian to see if I really get it. Yep, that's right. To libgpf: I am shortly before getting it working again. The new pipeline managemnet allows to autooptimize the data-transfer for speed/memory-usage. That makes realtime stuff (i.e. video-play) much easier to realize. I plan to write a target, that uses gstreamers' plugins. That allows libgpf to transfer videos quickly. Perhaps, I'll try to write a SDL and a DirectFB target to show, how flexible libgpf is. Past this point, it should be possible to play videos - hw-assisted through SDL/DirectFB (hopefully even with sound, but can't promise yet). I have been very interested in the gstreamer project. They are doing some great work so this sounds excellent to me! Is there anything specific I can do to help on libgpf? Anybody can help out there in writing targets, protocols and pipe sublibs for it. MooZ (a guy on IRC) is working on a pcx target. He is also interested in writing a gif and jpeg target. For this week, I have been busy with fixing bugs, cleaning up the code. I'll play with all of this running under fbdev and kgi on matrox cards. I'll share any fix ups for system architecture as they become necessary. Have I already given you CVS write access? No, I don't think so. I haven't come up with enough help to be worth access up to now. I hope to change that though. If you feel confident in my ability go ahead and set it up. (Do I need a specific password?) First, you must be a registered user at SourceForge. Then I need your loginname to add you to the developer's list. Here's the latest doc about LibVideo: Introduction This is more of a mission statement than a specification for the LibVideo GGI extension, and it's associated extension LibGPF. Though an API has been presented for LibVideo, it is only a straw man, intended for improvement and revision. In addition, the LibGPF API is relatively new and will be adapting to better accomodate LibVideo. LibVideo is intended to provide video support on LibGGI visuals, with the capability for various levels of fallback to software implementations (including 3rd party software), depending on the level of hardware support available in the target. LibVideo tries to keep itself as far sepearated from audio processing as it can be, however, since audio processing is often entangled with video processing, LibVideo does contain audio related code -- however this functionality is limited to simple informational elements containing the information necessary to attach a third party sound library or application. Callback function support will be provided in cases where the audio is hopelessly entangled. How does this relate to specific audio implementations such as ALSA? I guess, you wonder how it will interact with sound libraries, concretely? Well, that isn't thought out in the deep. Only very roughly, namely as above explained. There is a project 'jack' which provides a callback style API on top of ALSA. Perhaps where meshing audio and video functionality this is needed or at least handy? (I don't know but will look into it as time permits.) If it's interface fits perfectly, probably we can use it directly. Let us look at some of the operational modes that LibVideo needs to support: 1) Full software fallback In this instance there is no actual hardware to accelerate video overlays or stream control operations. An example is playback of an encoded video file on disk, when the graphics card
Re: LIBGGI: security patch
On Sun, 27 Jan 2002, Andreas Beck wrote:
Hi,
case 3: if (GT_SCHEME(LIBGGI_GT(vis)) == GT_TEXT) {
- sprintf(apiname, generic-text-%d, size);
+ snprintf(apiname, GGI_MAX_APILEN,
+ generic-text-%d, size);
return 0;
Make sure to configure-test for snprintf and include an implementation when
it is not there. snprintf is non-ansi and only conforms to ISO/IEC 9899:1999
(`ISO C99''). This might be a portability problem, as snprintf cannot
easily be emulated.
Using sprintf in the above case is not a security problem, as the maximum
length is known, as size is in a limited range.
- strcpy(apiname, generic-planar);
+ strncpy(apiname, GGI_MAX_APILEN,
+ generic-planar);
return 0;
NEVER use strncpy without an explicit termination. A program failing to
load a library because its name is too long is o.k.
A program that either loads something wrong or segfaults, because a string
operation goes beyond the end because of a missing terminator is a security
risk.
In that specific case, a runtime check is useless, as a string of _constant_
length is put in the apiname. If you really really want to check that,
please check it at compile-/configure-time.
done.
if (priv-fix.type == FB_TYPE_INTERLEAVED_PLANES) {
- sprintf(apiname, generic-%s,
+ snprintf(apiname, GGI_MAX_APILEN,
+generic-%s,
(priv-fix.type_aux == 2) ?
iplanar-2p : ilbm);
similar here. Size is known. Why fix what aint broken?
- sprintf(apiname, generic-linear-%d, size);
+ snprintf(apiname, GGI_MAX_APILEN,
+ generic-linear-%d, size);
Same. As I can't derive it from the manpage, can anyone here say, what
snprintf is supposed to do on overflows ?
Will it write a trailing \0 ? If not, that should be generated, to avoid the
snip from the manual page:
Return value
These functions return the number of characters printed
(not including the trailing `\0' used to end output to
strings). snprintf and vsnprintf do not write more than
size bytes (including the trailing '\0'), and return -1 if
the output was truncated due to this limit. (Thus until
glibc 2.0.6. Since glibc 2.1 these functions follow the
C99 standard and return the number of characters (exclud
ing the trailing '\0') which would have been written to
the final string if enough space had been available.)
Same comment for the other changes.
-sprintf(apiname, display-libkgi);
+ snprintf(apiname, GGI_MAX_APILEN, display-libkgi);
IMHO rather strcpy instead of sprintf.
done.
-sprintf(apiname, display-libkgi-%s,
+ snprintf(apiname, GGI_MAX_APILEN, display-libkgi-%s,
LIBKGI_PRIV(vis)-suggest);
O.K. - that might be a bad one. Depending on whether snprintf does the \0
thing, I'd say that is a good fix.
-strcpy(apiname, generic-stubs);
+ strcpy(apiname, generic-stubs);
Huh ?
oh, that's just a replacement of 16 spaces by 2 tabs.
dest_un.sun_family = AF_UNIX;
- strcpy(dest_un.sun_path, addr);
+ strncpy(dest_un.sun_path, addr, strlen(addr)+1);
WHAT ? No - that one would limit by the _source_ size. Unless it is
explicitly made sure that dest_un.sun_path is large enough to handle
strlen(addr)+1 (in which case the strcpy would do), this is the wrong thing
to do. It might quieten that strange scanner software, but it doesn't do
anything good. It's a NOP.
fixed.
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
Status of GGI domain
Hi all! 'whois ggi-project.org' says, that our ggi domain is back right now and expires on 17-Jan-2003 again. But our website is still not accessable, because our webmaster - who payed the renewal - needs to configure the right DNS settings. But he is visiting his girlfriend's family in Japan for ten days from today on. Once he is back and did the configuration, our web- and ftp-services should work again. I also hope, he can point the eu.ggi-project.org to Andreas Reich's servers, so that we have even the mail service back. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: seg. fault when using ggi
)
LibGGI: hand.close = (nil)
LibGGI: _ggiLoadDL returned 0 (0x8062328)
LibGGI: 0 = dlh-open(0x805c400, 0x8062328, (null), 0x805f968, 0) -
/usr/lib/ggi/display/mansync.so
LibGGI: _GGI_mansync_init(): nrvisuals = 1
LibGGI: X-target fully up
LibGGI: 0 = dlh-open(0x805c400, 0x805e4c0, :0.0, (nil), 1) -
/usr/lib/ggi/display/X.so
LibGGI: ggiOpen: returning 0x805c400
LibGGI: Loading extra inputs/filters for display-x::0.0
LibGGI: Checking GGI_INPUT_DISPLAY_X_2 : (nil)
LibGGI: Checking GGI_INPUT_DISPLAY_X : (nil)
LibGGI: Checking GGI_INPUT : (nil)
Here, you reopened it. Why do close it before?
LibGGI: ggiCheckMode(0x805c400, 0xb374) called
LibGGI: _GGIbasiccheck: defgt = 0x2001010, tmgt = 0x0
LibGGI: Default visual - ID: 0x23, depth: 16, class: 4
LibGGI: ggiSetMode(0x805c400, 640x480.V640x480.F1.D1x1.[C16/16]) called
LibGGI: ggiSetMode: trying (vis 640x480 virt 640x480)
LibGGI: ggiSetMode: trying2 (vis 640x480 virt 640x480)
LibGGI: ggiSetMode: calling 0x400193ac
LibGGI: _GGIbasiccheck: defgt = 0x2001010, tmgt = 0x2001010
LibGGI: Default visual - ID: 0x23, depth: 16, class: 4
LibGGI: _GGIbasiccheck: gt = 0x2001010
LibGGI: Visual - ID: 0x23, depth: 16, class: 4
LibGGI: _GGIbasiccheck: defgt = 0x2001010, tmgt = 0x2001010
LibGGI: Default visual - ID: 0x23, depth: 16, class: 4
LibGGI: _GGIbasiccheck: gt = 0x2001010
LibGGI: Visual - ID: 0x23, depth: 16, class: 4
LibGGI: X: has window 0x326
LibGGI: X: Prepare to resize.
LibGGI: X: Resize
LibGGI: X: Creating shm image #0
LibGGI: X: shmat success at 0x405b.
LibGGI: X: ShmImage #0 allocated
LibGGI: X GC allocated.
LibGGI: X: About to map
LibGGI: X: Window Mapped
LibGGI: X: Sync
LibGGI: X: Sync done
Here you set a (default?) mode 640x480 16bit.
LibGGI: _ggiZapDL(0x805c400, 0x805e02c) called
LibGGI: _ggiZapDL(0x805c400, 0x805e11c) called
LibGGI: _ggiZapDL(0x805c400, 0x805e17c) called
LibGGI: _ggiAddDL(0x805c400, generic-stubs, , 0x1) called
LibGGI: _ggiLoadDL(/usr/lib/ggi/default/stubs.so, 0x1) called
LibGGI: hand.handle=0x80625b0
LibGGI: (GGIdl_stubs) = 0x40648da4
LibGGI: hand.open = 0x40648b60
LibGGI: hand.exit = (nil)
LibGGI: hand.close = (nil)
LibGGI: _ggiLoadDL returned 0 (0x8062838)
LibGGI: 0 = dlh-open(0x805c400, 0x8062838, , (nil), 4) -
/usr/lib/ggi/default/stubs.so
LibGGI: X: GGIsetmode: success in loading generic-stubs ()
LibGGI: _ggiAddDL(0x805c400, generic-color, , 0x1) called
LibGGI: _ggiLoadDL(/usr/lib/ggi/default/color.so, 0x1) called
LibGGI: hand.handle=0x80628c0
LibGGI: (GGIdl_color) = 0x4064cec8
LibGGI: hand.open = 0x4064cc78
LibGGI: hand.exit = (nil)
LibGGI: hand.close = 0x4064ce9c
LibGGI: _ggiLoadDL returned 0 (0x8062b60)
LibGGI: 0 = dlh-open(0x805c400, 0x8062b60, , (nil), 2) -
/usr/lib/ggi/default/color.so
LibGGI: X: GGIsetmode: success in loading generic-color ()
LibGGI: _ggiAddDL(0x805c400, generic-linear-16, , 0x1) called
LibGGI: _ggiLoadDL(/usr/lib/ggi/default/linear_16.so, 0x1) called
LibGGI: hand.handle=0x8062c20
LibGGI: (GGIdl_linear_16) = 0x40652500
LibGGI: hand.open = 0x40652380
LibGGI: hand.exit = (nil)
LibGGI: hand.close = (nil)
LibGGI: _ggiLoadDL returned 0 (0x8062eb0)
LibGGI: 0 = dlh-open(0x805c400, 0x8062eb0, , (nil), 4) -
/usr/lib/ggi/default/linear_16.so
LibGGI: X: GGIsetmode: success in loading generic-linear-16 ()
LibGGI: ggiIndicateChange(0x805c400, 0x1) called
LibGGI: ggiIndicateChange: 1 changed for 0x805c400.
LibGGI: ggiSetMode: set to frame 0, origin = {0,0}
LibGGI: ggiSetMode: set GC
LibGGI: _default_error() called
LibGGI: ggiSetMode: success (vis 640x480 virt 640x480)
Videomode is set successfully.
LibGGI: _default_error() called
LibGGI: _default_error() called
LibGGI: ggiSetMode: SetWriteFrame 0
LibGGI: ggiSetMode: frame address: 0x405b
LibGGI: ggiSetMode: FillScreen 0
LibGGI: GGI_X_flush(0x805c400, 1) called
and then Seg.fault occur.
The segfaults happens during a flush? hmm...
Does the segfault go away, when you _don't_ reopen the X-target?
Can somebody else confirm, that a segfault happens, when calling ggiOpen()
the
2nd time like this:
1. open X-target
2. close X-target
3. open X-target
4. close X-target
If so, then something in the (un)initialization code is wrong.
Can somebody else check that behaviour on other targets, please?
This help us to figure out, if the bug is in the X-target or if it is
somewhere in the
core lib.
However,there is no problem on my deskop computer,
which also use Debian sid with XFree86 4.1.0 using Banshee as
display card
I think, that has nothing to do with the X-server. It seems being a bug
libggi.
--
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
Sent through GMX FreeMail - http://www.gmx.net
"
Description: Binary data
Re: GGI domain expires again...
Hi all! I can't neither ping (www|ftp).ggi-project.org nor I can't resolve the DNS entries of these addresses as of this writing. Perhaps Internic removed its ggi-project.org zone data completely right now? Can anyone check/confirm that? If so, then Edward could go ahead creating a new zone for ggi-project.org without causing conflicts. -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] Sent through GMX FreeMail - http://www.gmx.net " Description: Binary data
Re: GGI domain expires again...
On Tue, Jan 01, 2002 at 11:16:31AM +0100, Christoph Egger wrote: That's exactly what Edward offers! (I don't know, how he manages that, but that's his own secret. :) Um, I was offering DNS zone hosting, not purchasing the domain with a domain registrar...I think there was some miscommunication there. Someone still needs to register or renew the domain at the root level with either NetSol (a renewal) or an alternative registrar. Since it's already expired, I don't think Network Solutions will let you transfer to another registrar to take advantage of a lower price. AAhh! Now I see! Andreas: What Edward offers, shouldn't make any trouble with your hosting package. I would say, let's go ahead! Having the www and ftp services back is the most important thing currently. The mail forwarding and the eu.ggi-project.org services have second priority. Sorry if anyone misinterpreted what I was offering. Well, sorry, we (Andreas and I) are german guys and no native english speakers. Sorry for our poor english. -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] Sent through GMX FreeMail - http://www.gmx.net
Re: GGI domain expires again...
On Tue, 1 Jan 2002, Andreas Reich wrote: Christoph Egger ([EMAIL PROTECTED]) wrote: On Mon, 31 Dec 2001, Edward S. Marshall wrote: Internic would delegate ggi-project.org to my nameservers. I'd set up A records for www and ftp over to their respective sourceforge IPs, and an MX record for the base domain over to Andreas. Then I could either delegate eu.ggi-project.org over to nameservers Andreas has access to, or I could set up the corresponding A records here. What I wanna know, if that is possible from Andreas' side, because he has no control over the DNS entries of his ISP :-( We could work something out. That's not the problem. :) However, if we do it the Internic way, somebody has to pay for the domain. (They are available at quite a low price at www.gandi.net) That's exactly what Edward offers! (I don't know, how he manages that, but that's his own secret. :) Happy new year! Happy new year, Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: GGI domain expires again...
On Mon, 31 Dec 2001, Edward S. Marshall wrote: On Mon, Dec 31, 2001 at 11:07:15AM +0100, Christoph Egger wrote: Edward hosts three DNS entries: www.ggi-project.org DNS entry pointing to 152.2.210.81 ftp.ggi-project.org DNS entry pointing to 152.19.254.81 An MX entry pointing to Andreas' mail server (IP-Adress), which handles the mail forwarding/pop3. Andreas hosts the www.eu.ggi-project.org and ftp.eu.ggi-project.org DNS entries, where 'eu' is for 'Europe'. Ok, so let me see if this is what you're suggesting: Internic would delegate ggi-project.org to my nameservers. I'd set up A records for www and ftp over to their respective sourceforge IPs, and an MX record for the base domain over to Andreas. Then I could either delegate eu.ggi-project.org over to nameservers Andreas has access to, or I could set up the corresponding A records here. Does this sound about right? :-) Yes, you got me. What I wanna know, if that is possible from Andreas' side, because he has no control over the DNS entries of his ISP :-( CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
