[20:00] I got more of those ... 4 penguin total here - and one Dragon ... [20:00] Ahh, the KDE dragon? Whatever its name is. [20:01] Adamel (marcus@213.212.13.67) joined #ggi. [20:01] No - just some cute green Dragon I got from an ex-girlfriend. [20:01] Hi Marcus ! [20:01] macarena: Oh, all right. [20:02] I see the dragon. ;) [20:02] Yeah - I propped it you for you ... [20:02] are there any plans to cooperate with James for the new 2.5 stuff ? [20:02] What's up ? can only "act" ? [20:03] I mean, is there any lobbying to Do-It-Right-This-Time (tm) ? [20:03] James contacts me from time to time, but we don't officially cooperate for political reasons ... [20:03] ruy2 (trescuatro@62.37.158.4) joined #ggi. [20:03] seeger_s (s@tnt127.hrz.tu-chemnitz.de) joined #ggi. [20:03] hm is it 20:00 cet now? :) [20:03] wow [20:03] Yes. [20:03] Action: smoke hereby officially opens the irc discussion then :] [20:03] Yep ... Steffen is here as well now ... [20:03] Hi everybody :-) [20:03] just a formal gesture, do continue :) [20:04] Action: smoke greets everyone in random order [20:04] Adamel: Are you ready or should we wait for you to fix the client ? [20:05] Adamel - maybe switching Nicks might help ? [20:05] akawaka (akawaka@skynet.csn.ul.ie) joined #ggi. [20:05] Nick change: Adamel -> Adamel_ [20:05] Nick change: Adamel_ -> Adamel [20:06] i've got a very short list of things i'd like to hear peoples opinions on.. [20:06] #1 (when) will there be a stable release of the current version [20:06] #2 what are future plans, regarding linux, *bsd and other os'es [20:06] #3 what is up with kgi ? [20:06] O.K. - fits well with my schedule ... [20:07] Same with me... [20:07] #4 what is going to happen project management wise to keep up the project without mandating too much time on the coordinators [20:07] what is actually keeping back a new release now? [20:07] stefan: also very interesting [20:07] Let's wait till we get Marcus up and running here ... [20:08] ok [20:08] Especially the release stuff concerns him to quite some extent ... [20:08] I can talk a little about #2 in the meantime ... [20:08] soyt (eric@massy-2-10-18.dial.proxad.net) joined #ggi. [20:09] macarena: ah, please do [20:09] The whole idea of GGI is being generic, and thus I always like to see ports to anything - even windows *g*. [20:09] note that everything is being logged at http://vengeance.et.tudelft.nl/~smoke/log/ (Chanserv propably said that already :) [20:09] Action: macarena will try not to insult a well known OS too much *g*. [20:09] smoke: right, and don't forget to pretty print (format) that once it's over and post it somewhere... [20:10] what about macos(X) [20:10] ? [20:10] stefan: yup, that's the least i could do [20:10] Actually, I'd like to see a port. Does anyone know someone who is up to date with OSX? [20:10] Adamel_ (marcus@213.212.13.67) joined #ggi. [20:10] hi marcus (?) [20:10] Hi all [20:10] beos aswell [20:10] Action: macarena hopes that it works for Marcus now ... [20:11] i think that covers the "mainstream" os's [20:11] Nick change: Adamel_ -> Adamel__ [20:11] Nick change: Adamel -> Adamel_ [20:11] do i recall correctly that a freebsd port of libggi was functional already? [20:11] Nick change: Adamel__ -> Adamel [20:11] Ah, good. [20:11] *lol* - the old swap-two-variables-problem ... [20:11] yep ;) [20:11] Adamel: you are changing colors pretty quickly...:) [20:11] Welcome Marcus. [20:12] O.K. - regarding the ports. Everyone is welcome. We should cover most Unixes using X, but I'd like to see more supported on a lower level, where available. [20:12] thanks, I've seen everything you said since I joined, just couldn't speak [20:13] macarena: d'you have any particular lowlevel(?) OS in mind? [20:13] macarena: right, especially given that 'using X' is not precisely what GGI stands for... [20:13] For BSD such efforts are under way, and I hope others will follow. We had a driver for the sunfb once ... [20:14] For the other OSes I have no indication of status ... anyone tested the Windows-DirectX-Stuff ? [20:14] macarena: or did you mean GGI should be possible whereever X is at home ? [20:14] is windows support really important? [20:14] MacOSX has AFAIK not been tried yet, but I'd like to see it. [20:15] i've tried running libggi in directx in windows NT 3.51 once, but that didn't work out and i gave up; it didn't seem all too interesting to me [20:15] akawaka Yes - I think it will attract more people, if you can just recompile aour app and be done with porting it. [20:16] The DirectX stuff is very limited by the looks of it, but I suppose John got it to work on his machine at least... [20:16] macarena: that maybe true for an API the deals with more than just graphics input [20:16] NickElm (elm@jedi.hemmet.chalmers.se) left irc: Ping timeout for NickElm[jedi.hemmet.chalmers.se] [20:16] i think akawaka has a good point there. you'd need much more for most applications. for example game programmers would want to have sound and 3d libraries as well; i think SDL would be a better choice then [20:17] Sure, but I'd like to have GGI on the lower end of the API chain ... everywhere ... [20:17] smoke: or some systems facilities layer (posix, for example) [20:17] I, personally, think the ggi project would be better off concentrating on Unix-a-likes [20:18] We basically do. LibGGI is geared towards Posix and friends, but I like things being portable ... [20:18] macarena: right. It's about graphics, not about porting everything... [20:18] windows support is a real time consumer. Plus, I think if people look at the figures, windows users/developers rarely give a damn [20:19] XeF4 (xef4@merlin.maa.utu.fi) left irc: Hmmm. EPIC has another bug. Go figure... [20:19] i think point #4 would be very interesting with this respect.. who (should be/is) deciding the focus for ggi ? [20:19] i think lack of focus scares many people away from ggi [20:19] Yes ... [20:19] indeed [20:19] XeF4 (xef4@merlin.maa.utu.fi) joined #ggi. [20:19] smoke: or makes it difficult to keep hoping :) [20:19] As far as porting goes to OSes/platforms: noone [20:19] O.K. - as we are all on now, let's go through the stuff in sequence ... [20:20] some people think that it's very neat to have ggi support gtk+, others expect hardware drivers to pop up soon.. there's much uncertainty [20:20] #1 the pending release ... [20:20] macarena: ok [20:20] We have propably been a bit sparse with releases ... everything works well, and other would call what we have now [20:21] something like 8.0 or 2000 or whatever ... [20:21] We got to make a new release soon. [20:21] First and most important question: Are any possibly incompatible API-changes pending ? [20:21] releases attract attention - attention attracts users - users attract developers. shallow, but true [20:22] macarena: indeed. Not everybody knows that GGI is pretty useable. Most see that the latest beta is a year (?) old, and that not much has been discussed in public ever since. [20:22] then again, a big release with bells and whistles and slashdot interviews could harm ggi pretty bad; as there is no 3d library or anything in the higher level 2d field [20:22] Yes - thus I think we should strive for a release before Xmas or at least before the new year. [20:22] NickElm (elm@jedi.hemmet.chalmers.se) joined #ggi. [20:23] new year releases are good ;) [20:23] Not really. We release LibGGI and be done with it. [20:23] smoke: I don't see how a missing 3D lib relates to GGI. Besides, there is MesaGGI (well, if it works :) [20:23] smoke: you don't need a "big" release, just a release [20:23] Anyone can add 2D/3D stuff then. [20:23] macarena: well, some noise would be good though. [20:24] macarena: I mean, nothing pretentious, just to get people to realize that GGI exists and is well. [20:24] Yeah - we'd surely stir the usual pots ... cola, /., fm ... [20:24] as i tried to indicate before, most people do not have such clear vision on what ggi is focusing on. i think a lot of people expect 3d libraries and hardware support [20:24] macarena: I do mention whenever I can that we use GGI. [20:24] hardware support, more than 3d [20:25] i know a lot of people who would kill for a decent 2d accelerated API [20:25] Action: smoke personally doesn't expect any of the above [20:25] hardware support, especially for 3d is timeconsuming unfortunately [20:25] O.K. - so noone with pending API change requests ? [20:25] macarena: well, just the usual ones :) [20:25] Not for the immediate releases. [20:25] macarena: stefan had some iirc [20:26] well, I don't want to hold a release back at any rate. [20:26] Stefan: Which ones ? Please repeat them here - not sure [20:26] Stefan:just tell them we can then decide on important or not. [20:26] macarena: not for applications, extension-API is another story. but as we don't have any release-quality extensions yet - no problem [20:26] macarena: the shmvisual thing. It isn't complete without feedback. You can't require sampling [20:27] macarena: I have a couple of convenience propositions, but they are not at all essential [20:27] macarena: for example for event polling... [20:27] O.K. - shm is just one target - whatever the solutio is, it shouldn't break the API ... [20:27] macarena: of course not [20:28] We can probably easily fit that into expose events and such. [20:28] What about event polling ? [20:28] macarena: in berlin I want to compress mouse events [20:29] stefan: You mean making one of all queued one - right ? [20:29] macarena: Xlib provides a couple of functions that let you 'inspect' the queue [20:29] macarena: ? [20:30] stefan: Like in (+4,-3) (+7,+3) (-2,+5) => one event (+9,+5) [20:30] stefan: You mean looking into the queue without reading the stuff out ? [20:30] macarena: oh. No, that I'd like to do myself (i.e. inside berlin) [20:31] stefan: giiEventPoll() would be trivial to add [20:31] macarena: but asking to return events as long as they are of a specific type (mask) [20:31] macarena: i.e. to be able to do the compression on top of that. [20:31] um, giiEventPeek() I meant ofcourse [20:31] Adamel: yeah, something like that. [20:32] Hmm - my idea was that the application would always flush the LibGGI queues ASAP and then do anything like this itself. [20:32] macarena: well, that would mean that we'd need to copy the entire queue before we could process it, no ? [20:33] stefan: Basically yes. [20:33] macarena: while I want to process most events one at a time, just not positional events... [20:33] tesmako (tesmako@tunnelb092.sn.umu.se) joined #ggi. [20:33] How do you keep sequencing, then ? [20:34] macarena: well, I may copy a sequence of mouse events. [20:34] macarena: but not others. [20:34] macarena: or I just do the stuff you proposed, i.e. update the 'current' position before processing it (as a single event) [20:34] stefan: you can already extract mouse events from the queue [20:34] stefan: without affecting other events [20:35] Adamel: yeah. But can I ask how many there are (contigously) ? [20:35] stefan: you mean without intervening other events ? [20:35] macarena: yep [20:35] stefan: nope [20:35] Adamel: see. [20:36] stefan: I see. I still don't quite get what it will gain for you, but as Marcus said, adding a Peek() function wouldn't be a problem. [20:36] macarena: nice. [20:37] Marcus: Do you remember, if it would be a problem to keep sequencing right for that function ? [20:37] macarena: it shouldn't be a showstopper at all, I figured that myself. [20:37] so it seems that nothing is keeping back a new release? [20:37] stefan: Yeah - and as it is a _new function_ it is not introducing any incompatibilities. [20:37] smoke: Wait - a few other things are pending. [20:38] warp (warp@dialup139-145.superweb.nl) joined #ggi. [20:38] macarena: It should be identical to Read() except we don't change the queue pointers [20:38] An easy one first: The map7unmap stuff c.Egger found ... [20:38] macarena: did you read my second mail? [20:39] Adamel: Yeah, but I think stefan wants something like Peek(...,EvNum) - right ? [20:39] Adamel: Yes, though I didn't get you on the lower part of it ... [20:39] I thought he only wanted to know if the next event was something else than a mouse event or not, so he could stop processing mouse events? [20:40] macarena: a simple peek would already be fine. A second parameter to specify the index would be even finer :) [20:40] I think the map/unmap stuff is a minor nuisance that doesn't do much harm. If I got some time, I'll fix it right, if not, so what. [20:41] stefan: but you'll have to poll all the events sooner or later, right? I mean to unqueue them. [20:41] stefan: I'd like to keep LibGII as small as possible. the simple peek requires almost no extra code, while the index thing would require an entirely new function [20:42] Adamel: yeah, right. Peek is what I want. [20:42] macarena: for the crossblit case it can be significant when blitting from a low bpp truecolor visual [20:43] macarena (becka@Isis226.urz.uni-duesseldorf.de) left irc: Read error to macarena[Isis226.urz.uni-duesseldorf.de]: No route to host [20:44] oops, the infamous german university network bites again... ;) [20:44] we'll just wait then :) [20:45] in the meantime: has anyone been working on some interesting projects for which i can view websites ? :) [20:45] another thing is documentation. a HOWTO more specifically. All information about how to set it up is there. It's just difficult to spot at times. [20:46] stefan: for using libggi as an enduser or for developers? [20:46] there should be a single page with references to all the resources which explain how to set up input and output stuff. [20:46] smoke: well, to get GGI up and running, i.e. for the user. [20:46] stefan: true. for example, how many knows what ctrl-alt-m does on the x target? [20:47] smoke: more often than not I'v run into problems when my mouse was incorrectly configured, etc. [20:47] macarena (becka@Isis94.urz.uni-duesseldorf.de) joined #ggi. [20:47] adamel: wow, i didn't know :) [20:48] Adamel: also, I remember when Graydon and I were preparing our berlin talk for the Linux Symposium in Ottawa. [20:48] Sorry - seems my connect dropped unnoticed ... [20:48] macarena: last thing we got was: [20:48] I think the map/unmap stuff is a minor nuisance that doesn't do much [20:48] harm. If I got some time, I'll fix it right, if not, so what. [20:48] Maybe you didn't get those ... (hoping to survive flood protection ...) [20:48] Fixing it right would mean: Writing a bunch of "colormap-xxx" libs that [20:48] Adamel: Graydon wrote a little perl script that extracted the interesting data from the XFreeConfig file and produced output that was suitable for the fb driver. [20:48] stefan: mouse problems should be less frequent now when we check XF86Config, which most users have correctly setup [20:48] will have the map/unmap calls optimized for the current color scheme. Will as well come in handy for nonstandard schemes [20:49] like YUV. They'd be pretty trivial copies of the standard color.c Trickiest thing would be to put them into the APIlists correctly [20:49] Adamel: things like that are essential if you don't want to piss off people early. [20:49] everywhere. [20:49] stefan: the input-linux-mouse inputlib now can read XF86Config by it's own, if there is no input-linux-mouse config file [20:50] Adamel: cool. So document that feature prominently [20:50] Have some people here checked that it works ? I used to have the XF86Config for "decoration purposes" only *g*. [20:51] However the new system I am using now has a G400, and I am for now using the regular X server ... haven't even yet gotten around to reinstall LibGGI *gg*. [20:52] Ahemm... have we come to a conclusion about #1 yet? [20:52] Action: macarena is just cvs updating and will cure that "problem" while we chat *g*. [20:52] seeger_s: good point. I was going to ask that :) [20:52] to put it differently: when do you think you could ship GGI 2.0 ? [20:52] still this year ? [20:53] O.K. - Marcus: What important stuff did we have left that would hold us back ? [20:53] there is some little build nuissance: [20:54] to build all (from cvs), I run 'buildall'. [20:54] Action: macarena is just executing a ./buildall ... *g* [20:54] hi * [20:54] but to then compile the libGGI demos, I have to configure and make in libGGI again [20:54] huh ? the demos are not built ? [20:55] in other words, the buildall should at least create the Makefile in the demos. [20:55] macarena: no [20:55] macarena: For the memory/X/Xlib/DGA/fbdev/glide/svga targets not much except some more testing. Some other targets are sad reading though. [20:55] macarena: wait a minute or ten, and you are going to see :) [20:56] Action: macarena just gets pretty upset about his new NFS-homes messing up the make install ... argl ... fixing my perms ... [20:58] smoke: I'll lead ... [20:58] Adamel: Any iportant target affected ? I see all important ones in your list ... [20:59] So we could just package it up and be happy ? [21:00] yeay [21:02] O.K. - what about testing ... anyone tested the stuff ? [21:02] I had posted some kind of "questionnaire" about that a while ago ... [21:02] Action: smoke looks that up [21:03] hm, could you restate the most important ones? [21:03] macarena: any mansync-using pseudo-target running on top of xlib will lock up demo.c pretty quick on an SMP-machine [21:04] Adamel: Urks ... but sounds like an X/MT problem ... [21:04] macarena: yep, must be [21:05] then, we have the _ggi_malloc() ==> malloc() stuff... [21:06] ruy2 (trescuatro@62.37.158.4) left irc: Ping timeout for ruy2[62.37.158.4] [21:06] Action: macarena has got someone on the phone ... will be a bit slow ... [21:07] Adamel: yes, though that ain't really important - right ? [21:07] stefan (stefan@rubidium.BIOPHYS.UMontreal.CA) got netsplit. [21:08] macarena: not really I guess... [21:09] stefan (stefan@rubidium.BIOPHYS.UMontreal.CA) returned to #ggi. [21:09] hmm, seems you don't even need an SMP machine to lock up mansync-on-xlib [21:11] I don't want to seem bothering, but could we perhaps just note that there is this lock-up bug and do the debugging later? [21:12] Action: stefan agrees with seeger_s [21:12] macarena (becka@Isis94.urz.uni-duesseldorf.de) left irc: Ping timeout for macarena[Isis94.urz.uni-duesseldorf.de] [21:12] I am a bit constrained in my online time... [Just did an extrapolation to #3 and #4...] [21:13] seeger: please address macarena, he said he'll lead the irc session [21:13] i'd prefer if we could handle things faster too, but i have little to say i guess [21:13] sure [21:13] this brings back another point (which we might want to discuss as part of #4): how to report and manage bugs [21:13] macarena (becka@Isis211.urz.uni-duesseldorf.de) joined #ggi. [21:13] redroppen ... [21:14] macarena: sorry to say, but could we speed up the discussion a bit please? [21:14] macarena: if we first discuss all 4 points, we can go into details later [21:14] O.K. - so we just relase it ? [21:14] macarena: the fact that you sent your requests twice to the list, and that we are still discussing this issue (and even found a bug) indicates that GGI needs some sort of bug tracking system. [21:15] stefan: Yes. [21:15] even more i think it needs attention, as akawaka stated previously [21:15] yes, so what's good and simple to set up? [21:15] macarena: I mean one that lists open tasks, bugs, etc. on some publicly visible place. [21:15] stefan: Anyone to host a good one ... ? [21:15] Adamel: slashdot. [21:15] Adamel: berlin has two sites [21:16] Adamel: oups [21:16] Adamel: I mean, sourceforge :) [21:16] Adamel: sourceforge is nice for the things you are too lazy to do yourself [21:16] slashdot could also serve as a good bugtracking (read: feedback) system [21:16] Adamel: so you could maintain your own site for anything that you can't (or don't want to) do there [21:17] Adamel: so we use sourceforge's project management tools as long as we don't have any better system. [21:17] Adamel: some people play with new ideas, but as we always have sourceforge, there is no urgent need. [21:18] macarena: the good thing: you are not forced to use all or nothing. [21:18] macarena: you don't need to use their ftp/cvs services if you don't want to. [21:19] O.K. - who sets it up and maintains it ... ? [21:19] macarena: it's *trivial* [21:20] macarena: it's an hour's work to get it up and running, i.e. inclusively register everybody [21:20] I can register a sourceforge project for us [21:20] I can second that, though quite some effort is needed to figure out what works how... [21:20] seeger_s: I'd gladly help you to set things up, having done a lot of that stuff for berlin already [21:21] I would **very** much appreciate that. [21:21] Anyone here on host [21:22] Name: thyme.epix.net [21:22] Address: 199.224.86.36 [21:22] happily making my firewall upset ? [21:23] Again: Anything we need to do before relaseing LibGGI ? [21:23] macarena: set up the sourceforge site :) [21:24] macarena: seriously, if you release, you should be able to tell people the site where to send bug reports to etc. [21:24] *lol* - but right you are. Who does it and maintains it ? I sure have zero time ... [21:24] macarena: I'd like to do a bit more testing of things. How about making a beta3 release next weekend, and aim for a real release around new year? [21:25] is the pageflip demo working ok for everyone? [21:25] beg1: was last time I tried it [21:25] adamel, on FB, if i switch VT away and back, page0 is 'corrupted'.. [21:25] macarena: if it's only setting up a bugtracking system on sourceforge, that would be 5 minutes work i suppose; so i'd gladly do it if that's all [21:25] Adamel: Yes ... though I got my doubts I get more results, except if we made the beta3 public. should we do that ? [21:26] again, whoever does the sourceforge site administration, I'd gladly help. [21:26] but it should be a true GGI member, not a cheerleader like me :) [21:26] macarena: sure, that's what I meant [21:26] So smoke would take the maintenance of a sourceforge site for GGI ? [21:26] Action: smoke is also only a cheerleader :( [21:26] I'm applying for a new project at sourceforge right now [21:26] ok I can register ggi on sourceforge and see how it works [21:26] macarena: fine with me; as long as it doesn't take up too much time [21:26] Admel: ok you first :) [21:27] adamel: great [21:27] i'll try to maintain the irc channel to help newbies [21:27] O.K. - Adamel: Will you update docs about the IRC channel and the sourceforge site, then ? [21:28] I can also take care of that as soon as I have cvs access to the ggi site [21:29] soyt: Any news from steve ? [21:29] nope [21:29] soyt or from core regarding cvs ? [21:29] nope [21:29] next week I hope [21:29] Adamel: ok, if you register the project, you should add all the people (once they created an account there). [21:30] macarena: yep [21:30] Adamel: then you can assign coordinator status to others, and you can share the responsability. [21:30] stefan: My install went well - including the demos ... can't reproduce your problem ... [21:30] stefan: sure, I'd be happy to ;) [21:30] Adamel: ;) [21:30] stefan: You know that buildall build executables in the *.out directories - right ? [21:31] Btw, does anyone know what the rules for domain names in .org are? [21:31] Adamel - Isn't it pretty much still a free-for-all? [21:32] misaka: I meant what you have to do to keep a domain? [21:32] do you *only* have to pay the fee? [21:32] Action: misaka hasn't heard of any rules being successfully imposed on organizations wanting .org domains for a number of years. [21:32] Adamel - Yes. [21:32] too bad in that case... [21:33] Adamel: you mean because of the ggi.org ? [21:33] None of the nameservers listed for ggi.org can even look up themselves... [21:33] It's a shame indeed, but I think that NSI has had much bigger problems to deal with in their history than tracking [non-]profitable organizations, etc. [21:33] macarena: yes, too bad we missed it [21:33] stefan (stefan@rubidium.BIOPHYS.UMontreal.CA) left irc: Ping timeout for stefan[rubidium.BIOPHYS.UMontreal.CA] [21:34] macarena: used to belong to a Swedish gymnastics school at the time we registered ggi-project.org, but now it belongs to nicaragua.nu, whoever that is... [21:34] Ah. You were also wondering technically. I don't think there's any impositions in that regard either. Some kind of clause stating that you must continue to _use_ the domain would be nice, but rather unlikely. [21:35] Uh ... missed the window of opportunity *g*. [21:35] Looks like domain campers. That's a 3-letter domain, no big surprise. [21:36] It might not hurt to ask them if they're willing to give it up for an OSS project. [21:36] O.K. - so we get some infrastructure up and running and then release a beta-3 - right ? [21:36] macarena: I am sorry having to leave at 22:00 CET, so may I propose discussing #3 soon? [21:36] Yes - please. [21:36] Action: macarena gives the ceremonial hat to Steffen. [21:37] So, basically what's up with KGI is currently a massive lack of time on my side. [21:37] I have gotten my hands on the new alpha, though. [21:38] I have made some progress in figuring the environment stuff out and preparing a first [21:38] compile attempt, but nothing more. [21:38] Is there anyone who is familiare with Linux/alpha? [21:39] . [21:39] no [21:39] tesmako (tesmako@tunnelb092.sn.umu.se) left irc: Ping timeout for tesmako[tunnelb092.sn.umu.se] [21:39] seeger_s: I have two old 100MHz Alphastations which I can help you test things on when I have time, but I have really no experience of Linux/alpha. [21:40] [ 'new' means here new to me, it's macarena's old system, thanks again. ] [21:41] I was just asking if there would be someone willing to help with troubles, ... [21:41] Anyway, the other thing is getting an X server on top of KGI-0.9 running, [21:42] which succeeded to some extend. [21:42] I have a semi-working framebuffer only driver which actually works to some extend. [21:42] [ only palette setting is not implemented yet. ] [21:43] Funny sidenote for those that didn't notice before: http://bedatec.eyep.net/images/webcam.jpg [21:44] My plan was to get XAA running with minimal impact on the XAA sources, which turne [21:44] Action: Adamel expects a new macarena show now ;) [21:44] d out to be a bit difficult. It seems as if (due to historical reasons or two programmers) [21:45] there are three methods keeping global per-screen state, (static to the XAA source, server-global and screen-local). [21:45] So I have first to collect the relevant stuff in an xf86 environment emulation, before [21:46] being able to init XAA the first time. [21:46] Otherwise I don [21:47] [sorry] Otherwise I don't see big technical obstacles getting this running with PhoeniX. [21:47] If anybody could give a helping hand on that or point me to some useful information about [21:47] O.K. - so the basic problem is the lack of time on your side -right ? [21:47] short interruption: project purpose and goal for the sourceforge registration. Is the text on our web-page ok: [21:47] GGI stands for "General Graphics Interface", and it is a project that aims to develop a reliable, stable and fast graphics system that works [21:47] everywhere. We want to allow any program using GGI to run on any platform requiring at most a recompile. [21:48] Adamel: Yeah - I think that's good. It's from our webpages - right ? [21:48] the XF86 internals... [21:48] macarena: yes [21:49] hunger (hunger@alcatraz168.wohnheim.uni-kl.de) joined #ggi. [21:49] Having PhoeniX going, I can start on debugging the accelerator handling... [21:50] O.K. - we can probably write up a LibGGI target for "your" KGI quickly, then ... [21:50] Anyway, thats for my monologue, any questions? [21:50] . [21:50] seeger_s: Is XAA so good that it is a must to use it to get an accelerated X-server? [21:51] Adamel: I don't have a comparison to other sources (as the SGI code mentioned in all the [21:52] OpenGL papers) but it's one implementation of the DDX code that allows you to get a driver [21:52] going quickly. [21:52] And it has the side-effect that we respectively XF86 may recycle driver code. [21:53] KGI-0.9 is limited to cover the initialization of modes and establishing a (fast) communication channel/mechanism to a virtualized hardware. [21:54] . [21:55] Reason I'm asking is that a complete XFree4-based server with accelerated bitblits and truetype support built on tinyX is about 650k, while the standard XFree4 server is about 2.5 MB with all the required modules... [21:56] I don't have any figures for PhoeniX, but I guess it would be about 1MB. [21:56] However, most memory is consumed in the pixmaps etc. [21:57] Adamel: Are you involved with tinyX? [21:58] As of the future of KGI: [21:59] 1) First objective is to get kgi-0.9 with the features I had posted some time ago going. [21:59] That means a working accelerated X server using the KGI acceleration abstraction. [22:00] seeger_s: I'm using it for my work. I've written a driver for National's Geode chipset and stripped out stuff we don't need from the server. [22:01] seeger_s: I also plan to release a uXGGI ("micro XGGI") based on TinyX [22:01] 2) I currently see problems reaching that goal quickly, not because much has to be done to accomplish it, but rather because Linux is drawing from my time more than I would like to [ doing system administration for our department ]. [22:03] 3) However, if 0.9 is out, I want to get KGI over to *BSD and Hurd, seeing if it's portability is as expected. [22:04] So, as a summary, KGI continues and is alive, though a bit handicapped at the moment... [22:04] ;-) [22:04] . [22:06] is it hard to get kgi running on 2.4 kernels? [22:07] i'd say it is not. there were not too many substancial changes, imo, steffen? [22:07] For the console part I think not, actually there are some [22:07] semiworking patches from Jon et al. [22:07] "ggi" project is now waiting for approval on sourceforge. [22:08] I still have to look trough them, but if you like to get your hands on them, [22:08] just take and try. [22:09] [see the kgi-develop list archives] [22:10] macarena: Doin' the Tux-dance? [nice gimick, that webcam] [22:10] seeger: yeah ! [22:11] Any more things that need discussion? [22:12] #4 what is going to happen project management wise to keep up the [22:12] project without mandating too much time on the coordinators [22:12] #5 documentation [22:12] (#2 what are future plans, regarding linux, *bsd and other os'es [22:12] 1 [22:12] In terms of #4 related to KGI I had contact with some guy who wantet to [22:13] scout sourceforge and make some suggestions how to utilize resources there better. [22:13] However, he has some time constraints too, so this is put aside for a while. [22:13] i hear sourceforge had trouble keeping up with the amount of projects hosted there [22:14] I can't verify that with KGI. May be because of the Times when I use it normally... [22:14] i think defining explicit goals would be best. i find it hard to contribute to ggi as i have no idea what needs to be done. (apart from fixing bugs, which i can't seem to find) [22:14] smoke: haven't they fixed that? downloads form sourceforge used to be slow, but seem fine the last couple of weeks.... [22:15] warp: no clue [22:15] smoke: I think the sf site will partially take care of that ... [22:15] ehm.. i don't see how a sourceforge site can dictate goals :)) [22:16] smoke: No, but it can make them more public *g*. [22:16] Back to the source forge scout, I would definately appreciate if someone familiar with SF [22:16] macarena: could you state some personal goals? [22:17] manuel (manuel@195-23-162-135.nr.ip.pt) joined #ggi. [22:17] could have a look at the KGI site and give some hints and advices what more services are available. [22:17] Personal goals: 1. Make a release. 2. Find a few people doing maintenance stuff. [22:18] 3. Find a few people that want to seriously take LibGGI2D and -3D or GGIMesa ... [22:19] I am sorry guys, but I have to leave... [22:19] CU steffen ! [22:20] bye steffen! [22:20] macarena: Excellent. GGIMesa is one of Berlin's dependencies, so that would be good. [22:20] cu steffen [22:20] bye * [22:20] 4. See more extensions popping up, like the sprite/Overlay stuff, Blitting , ... [22:20] seeger_s (s@tnt127.hrz.tu-chemnitz.de) left irc: #ggi [22:21] For my personal needs LibGGI pretty much does all I want ... thus my motivation is a bit diminished ... [22:21] 5. Get a bigger penguin: http://www.stacken.kth.se/~mackan/image.jpg [22:21] sorry, couldn't resist ;) [22:22] *LOOOOOL* ! Great thing ! [22:22] Adamel: :) [22:22] isn't mine though, belongs to work [22:23] the sprite extension seems very interesting to me [22:23] manuel (manuel@195-23-162-135.nr.ip.pt) left irc: [22:23] has anybody been working on that already? [22:23] smoke: don't think so [22:23] it would be very useful as a base for guis and games [22:24] smoke: I used to have demos and stuff for a combined bse (blitting, sprites, emulated sprites) extension ... [22:24] haha :)) i can imagine a funny logo featuring a certain animal for that [22:24] smoke: Yeah - that was the intention *gg*. [22:24] :] [22:26] ouch. the search for the holy grail is on bbc2 now :/ [22:26] it gets very tempting to pay less attention now [22:26] What is still on schedule ? [22:26] stefan (stefan@rubidium.BIOPHYS.UMontreal.CA) joined #ggi. [22:27] macarena: i'd like to know more about who's who and who'll be who in the future [22:27] I'm sorry, my gateway... [22:27] macarena: as you said yourselves, you're interest is diminishing [22:27] O.K. - soyt will take the web stuff. [22:28] macarena: I'd recommend sourceforge to be used at least for the bug and task managers, and the mailing lists [22:28] macarena: and if the cvs server isn't too slow for you, even for cvs. [22:28] As I don't have much time, and Marcus neither, we would probably want some more people to do administrative stuff ... [22:28] stefan: moving CVS would loose logs - right ? [22:29] We should try to get some people that will take care of the various extensions ... [22:29] I think I and Marcus should stay for LibGGI and LibGII, but for everything else, I'd like to have separate people in charge ... [22:30] stefan: moving the mailinglist seems pointless to me. Sourceforges mailinglist archive is the worst on the planet. [22:31] Adamel: How's your workload ? Got time for GGI ? Mine is pretty high ... [22:31] stefan (stefan@rubidium.BIOPHYS.UMontreal.CA) left irc: Ping timeout for stefan[rubidium.BIOPHYS.UMontreal.CA] [22:31] macarena: I have full read access to the repository via ftp, so we can move it without loosing logs, but I want to wait with that decission for a while... [22:32] Adamel: what's wrong with the current cvs hosting? [22:32] Adamel: Ah - good. O.K. - as it works fine, not much of a point to move it. Mirrors would be good, though ... [22:33] macarena: I'll take my self time at least to wrap up the release tarballs next weekend. [22:33] macarena: Do you have time for a short private session then to discuss the details, and maybe writing up an announcement? [22:33] Adamel: Will you as well make the RPMs ? I think they would broaden the audience immensely ... [22:33] stefan (stefan@rubidium.BIOPHYS.UMontreal.CA) joined #ggi. [22:34] Adamel: sure. [22:34] soyt: missing anoncvs mostly. eman being hard to reach is also a problem sometimes. [22:34] Adamel: i see [22:34] macarena: Might be painful, I'm allergic to redhat [22:34] ;) [22:35] holy crap ! [22:35] (sorry) [22:35] macarena: did you see my reply ? [22:35] Adamel: I can do it - no biggie. [22:35] stefan: I saw your comments about using SF. [22:35] macarena: ok [22:35] macarena: the last remark was [22:35] macarena: for example nightly builds, use the compile farm to do some testing, etc. [22:36] stefan: Last we saw was: and if the cvs server isn't too slow for you, even for cvs. [22:36] macarena: oh [22:36] macarena: there could be a little script that posts to a special ML each time there is a new cvs checkin... [22:37] macarena: no, there is a way to move everything with history [22:37] macarena: I don't quite remember how it was done, but we did it [22:37] Adamel: I think the specs should work for rh and derivatives and suse - so only debian missing. [22:37] adamel: Maybe alien can handle that ? [22:37] macarena: the nice thing about having cvs there is that you automatize even more [22:38] macarena: for example nightly builds, use the compile farm to do some testing, etc. [22:39] macarena: not unlikely, or we can ask the maintainer of the current debian packages to send the build stuff [22:39] warp (warp@dialup139-145.superweb.nl) left irc: Ping timeout for warp[dialup139-145.superweb.nl] [22:39] macarena: debian had ggi packaged already AFAIK. just need to find the maintainer [22:39] Yeah - I'd like to have Beta3 to be tested by a broad audience ... thus binary releases ... [22:42] O.K. - what else is missing ? [22:43] A precise timeline for release? [22:43] hm what about documentation? [22:43] is there enough good documentation for a release? (trying to sound a little volunteerily to write some docs where necessary) [22:44] Adamel: Timeline ? Next weekend ? [22:44] next weekend for beta3 sounds fine [22:45] and then a final release around new year [22:45] smoke: I think docs are good ... suggestions welcome, though ... [22:46] I'm free from work the whole week between christmas and new year, so I should have some time for GGI-hacking then if neccesary. [22:46] Good - I'll probably have not much time, then, but well ... [22:46] macarena: could you send me a tarball of the ggi/www repository if it's not too big? before i get cvs access... [22:46] soyt: just a moment ... [22:51] soyt: We can do even better than that, I can give you the read-only account used by the web-server to check out the www tree. That way you can at least track the main repository with CVS. [22:52] Adamel: ok fine [22:52] soyt@free.fr, right? [22:53] Adamel: yep [22:53] macarena: hm, most docs seem fine to me too [22:53] Action: smoke has to go now.. [22:53] CU smoke ... [22:53] bye smoke [22:53] i'll write up a summary of this session, and post it to the ggi mailinglist, ok? [22:54] O.K. - anything important missing now ? [22:54] oh, and in case you are looking for ggi demos: http://die.die.ms/ecfh/ [22:54] macarena: i've personally seen most of my questions answered [22:54] thanks all, and hope to see you here again later :) [22:54] bye! [22:55] O.k. - biggest problem with our docs is that people don't read it, but I don't know how that can be helped ... [22:55] macarena: fixing up the web-site will do good on that I think [22:55] quick reference sheet? [22:55] macarena: no, not quite true. I for one did read it. But, as I said earlier, the HOWTO's are a bit dispersed [22:55] macarena: it's a problem for every projects I guess... [22:56] macarena: I mean, it took quite a while to figure out where the relevant stuff is, i.e. for example for all the driver config stuff. [22:56] macarena: so what I proposed was a meta HOWTO or something which references all the rest. As an entry point. [22:57] I wonder if there's not too much docs, actually. It's a bit cumbersome for users and difficult to know what is up to date. [22:57] Stefan: yeah. *g* - o.k. would have said quite that ... [22:58] soyt: right. It's not as well organized at it might [22:59] soyt: very true. most of the documentation on the web-site should simply be tossed... [23:01] we should define a few different documents and their scope then try to stick to this [23:03] Btw, anyone to write up a summary of this session afterwards? [23:03] Yeah - smoke will. [23:04] macarena: ah, good [23:05] O.K. - anything we need to discuss left ? [23:06] Quick summary up to now: KGI is healthy, but progress is slow. [23:06] LibGGI as well, but we'll make Beta3 next WE and then a full release at the end of the year. [23:08] macarena: yeah, and sourceforge will provide some more efficient means for project management etc. [23:09] macarena: (for the record for the summary) [23:09] does anybody have news from Jon ? [23:10] I didn't get any reply about my querry last week. I'm unable to run MesaGGI... [23:10] Not for a while ... only what he said on the list ... [23:10] hmm [23:10] it appears (from a quick look into Mesa source) he's start working on some accelerated triangle stuff [23:11] speaking of mesa... [23:11] s/start/started/ [23:11] today I commited an initial LibGGIGL, which is supposed to be a glue between OpenGL ang GGI visuals. [23:12] Adamel: how does it relate to MesaGGI ? [23:12] MesaGGI is about implementing OpenGL on a GGI visual, with or without hardware acceleration. [23:14] LibGGIGL is about gluing the OpenGL API to a GGI visual. For example it will glue GLX to the X and Xlib targets, and eventually 3dfxMesa on the glide target. [23:15] Adamel: so libGGIGL is a way to access hardware acceleration for openGL implementations ? [23:15] Meaning if you have a working GLX on your system you can use GGI to setup the mode and receive events, and hardware accelerated drawing using the OpenGL API. [23:16] Action: stefan still doesn't see the difference to MesaGGI [23:17] MesaGGI - currently software drawing on any GGI visual with a DirectBuffer. [23:17] XeF4 (xef4@merlin.maa.utu.fi) left #ggi. [23:18] LibGGIGL - currently hardware drawing on X or Xlib visuals if you allready have hardware accelerated GLX, for example DRI or Utah-GLX [23:20] When MesaGGI has hardware accelerated drawing that should also be accessible through the LibGGIGL API, by simply installing a new sublib. [23:22] The point being the same as the original point of LibGGI - you don't need to "GGI:ize" the whole graphics system to use the GGI API. [23:23] everyone got bored to death or? [23:23] I'm alive ... [23:24] Action: beg1 looks around [23:25] O.K. - end it here ? [23:25] Or do we have important stuff left ? [23:26] Not that I can think of now at least. [23:27] In that case I'll try to do something good for my phonebill *gg* ... [23:27] So we might as well end the session so I *can* think of them. ;) [23:27] Please note, that the wcam will stop working, then ... don't bother the poor guy who gets my IP next *gg*. [23:28] macarena: i'll send you a tarball of the site for next week release ok? [23:28] unless I can cvs it before [23:28] site ? You mean for upload ? [23:28] ya [23:29] O.K. - I'll try ... *g* - never touched it up to now ... [23:30] Or somebody else? [23:31] In case you use any special features, here's what the server seems to be using: Apache/1.3.14 (Unix) tomcat/1.0 mod_fastcgi/2.2.8 PHP/4.0.4-dev [23:32] Adamel: great. I thought I would not have php. I was planning to generate all the site local. [23:33] So I can write up a webform for anouncements and stuff [23:35] Did stefan leave? [23:36] ups - seems so ... maybe he's problems again ... [23:36] Ok, should we call it a night then? [23:36] Yeah ... CU ... [23:37] Last chance to see the elk-hat ... *g*. [23:37] cya! I'll send you pm about the release next we [23:38] O.K. - fine ... [23:38] Singing off now ... [23:38] macarena (becka@Isis211.urz.uni-duesseldorf.de) left #ggi. [23:39] bye all, I'll put up the full IRC log on the website right away, and the summary from smoke will come later. [23:39] Adamel (marcus@213.212.13.67) left irc: ... [23:40] bye all [23:40] soyt (eric@massy-2-10-18.dial.proxad.net) left #ggi.