Re: KGI IRC Meeting
On Thu, 22 Aug 2002, Rodolphe Ortalo wrote: > The "accelerator engine communication channel" is also a generic thing > common to all drivers in some sense. But its standardization may be (?) > less critical as it can only be useful for (hw-specific) software that > knows how to use it effectively (and fill it with binary ops that the > specific hw engine understands). Right, my point exactly. > The key issue in the standardization on a > generic channel from userspace down to the accelerator is more related to > the fact that it will be a (important) design decision. I think we need to just identify what facilities (mmap page-fault schemes, various types of kernel<->user locks) are needed as building blocks, and standardize them in a way that driver authors find them easy to use, not standardize the pipeline as a whole. > > The > > only exception to this IMO should be facilities which are easy to provide > > because they had to be implemented in order to provide the OS with > > a console/fb system, mainly mode-setting. Other than that, there > > should be a strict "validate only" policy. > > Oh. It seems we agree in fact. Right, I was considering the minimum requirements for VC's to be everything the OS needs to implement a 16 color and/or attribute, ASCII text terminal system, and the "optional" stuff to be basically the necessary enhancements to implement things like linux fbdev, and the mouse cursor and programmable console text fonts. > > 2) Absolute inter-process security > > Hmmm. You mean that we need to double check that the permissions on the > /dev/graphics devices and co. are really enforced by the code? Corner cases like leaving data in the video RAM after a console switch, possibly giving access to sensitive information. > > 3) Graphics driver system pause/resume due to VC-switch and/or system > > powersave or suspend-to-disk, > > Isn't this limited to text mode? In "VC-switch", there is the C for > console which means text (even if on a graphical fb)... Okay, that's just > a pun, but isn't my point valid anyway? It seems to me that, on one > graphical head, a switch should be handled the simple way (SIGSTOP? Can > be trapped no?). Much more complicated than that: what guarantees does KGI offer about preserving the state of the hardware? Will the GPU be flushed? Can an app arrange to have the fb and texture contents preserved by saving them aside? And, can all this be done in-kernel such that we do not have to play any complex double-clutch tricks (send a signal to the app, give it a small time-slice to prepare for the switch and ensure the app is scheduled for at least long enough to perform the needed operations, then block the app when the time limit is up.) And then we have save-to-disk where the state of the hardware has to be restored from power-on conditions. -- Brian
Re: KGI IRC Meeting
I hope I can be there on Saturday. Btw, at which hour is the meeting in France? It's 1pm eastern time, so 19:00 GMT? isn'it? Isn't it 7 or 8pm in France? Hmmm I'm not sure I can be there at that time (a 2-years-old boy that wants dinner is a pretty high-level interrupt - even with power-switch side-effects sometimes!). I'd rather 2 hours later or 3 hours earlier if possible? Well, do not bother too much only for me however. On Tue, 20 Aug 2002, Brian S. Julin wrote: > My 2 cents on a good topic for our upcoming IRC meeting: I think we > need to concentrate on creating a firmer definition of what a KGI driver > is and is not expected to do. Yep. It would be useful! > Not to get too in-depth before the meeting, but to summarise: > > IMO there are several areas where we have not limited the scope > enough. We need to be more minimalist. I agree too. The objective should be clearer, and feasible. > For example, since all > KGI kernel-side drivers must be accompanied by a userspace driver > which is specific to the chipset/hardware, Unless I missed something in the last few months (pretty possible), for me this is only true for hw-accelerated functions (either 2D or 3D). For the rest, it seems to me that the userspace driver should be generic. At least, this is true for mode-setting like you say. IMHO it should also be true for basic things like hw-cursor management, palette setting. Also for "standard information" (a "get_info" ioctl will also surely include a hw-specific extension part, but the standard piece should be generic). And also if possible for some "sync()" signaling. It could also be (sort-of) generic for VGA-text issues if we agree to standardize on the VGA-text subsystem (or a compatible one) to provide VGA text functionality (including font setting and hw cursor, the most useful things). The "accelerator engine communication channel" is also a generic thing common to all drivers in some sense. But its standardization may be (?) less critical as it can only be useful for (hw-specific) software that knows how to use it effectively (and fill it with binary ops that the specific hw engine understands). The key issue in the standardization on a generic channel from userspace down to the accelerator is more related to the fact that it will be a (important) design decision. > [...] This saves a lot of time and > effort trying to find standard ways of expressing things like > RAM configurations, and gives the driver author more freedom. I understand (and agree with) this. But there are simple things, like the hw cursor, the 8bpp palette, the gamma correction table, the basic characteristics of the board (available fb RAM size, flags indicating the availability of hw-cursor, gamma table, etc.), that can be standardized without too much thinking. And IMO this should be done because it would be beneficial in short term (driver writers would also get more applications for testing...). As an example, I think one should forget about the 16-color hw cursor of Matrox >=G200 and standardize a 3 color (or even 2-color) cursor. We'll see later on if the Matrox driver maintainer has the motivation to do a Matrox-specific dedicated lib for that unique feature ;-). Basically, the important thing is to have a decent-looking arrow and show(),hide(), set_position(x,y) functions! You can do a similar reasoning for the palette or gamma correction tables, even if the Parhelia (Matrox again!) comes with 10bits for R,G and B. (Fortunately, they did not release the specs for that beast! Well, :-(. Anyway back on topic.). > The > only exception to this IMO should be facilities which are easy to provide > because they had to be implemented in order to provide the OS with > a console/fb system, mainly mode-setting. Other than that, there > should be a strict "validate only" policy. Oh. It seems we agree in fact. What about a "two-level approach" to basic features: * Mandatory: - mode-setting (graphics) - mode setting (text, possibly augmented with some VGA-text facilities) - some standard informational data struct, including a list or bitfield indicating the absence/presence of some standard optional features, and a variable size area at the end for the hw-specific mess. * Optional: (the presence/absence of one feature is indicated by the list/bitfield in the information above) - hw-cursor: 3 colors, standard size and bit layout (whichever you want), show(), hide(), move(x,y), initially hidden. - palette: natural definition according to the mode (ie: 3 arrays of 256 bytes for usual 8bpp, etc.) - gamma correction: 3 arrays of 256 8-bits bytes - sync on frame - current kgi-0.9 pingpong buffers [really optional] - other kgi-1.0 generic accel channel [if already available] > Then there are the areas which we have so far not addressed enou
Re: KGI IRC Meeting
My 2 cents on a good topic for our upcoming IRC meeting: I think we need to concentrate on creating a firmer definition of what a KGI driver is and is not expected to do. Not to get too in-depth before the meeting, but to summarise: IMO there are several areas where we have not limited the scope enough. We need to be more minimalist. For example, since all KGI kernel-side drivers must be accompanied by a userspace driver which is specific to the chipset/hardware, KGI drivers should simply provide those peices of information, and kernel facilities, which the userspace driver cannot know/do on its own. This saves a lot of time and effort trying to find standard ways of expressing things like RAM configurations, and gives the driver author more freedom. The only exception to this IMO should be facilities which are easy to provide because they had to be implemented in order to provide the OS with a console/fb system, mainly mode-setting. Other than that, there should be a strict "validate only" policy. Then there are the areas which we have so far not addressed enough: 1) Absolute system stability precautions 2) Absolute inter-process security 3) Graphics driver system pause/resume due to VC-switch and/or system powersave or suspend-to-disk, and 4) handling funny corner cases safely even if it means killing or blocking the app (e.g. monitor swap during running application). -- Brian
Re: KGI IRC Meeting
On Fri, Aug 09, 2002 at 02:19:12PM -0400, Filip Spacek wrote: > Hello everyone, > > During the past couple of months, KGI has gone through quite a bit of > development in the WIP tree. Lot of the small issues have been fixed and > features added. We're getting to the point where big design questions > need to be addressed. So acting on Jos Hulzink's idea, I'm proposing we > organize an IRC meeting. Great. -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED]
KGI IRC Meeting
Hello everyone, During the past couple of months, KGI has gone through quite a bit of development in the WIP tree. Lot of the small issues have been fixed and features added. We're getting to the point where big design questions need to be addressed. So acting on Jos Hulzink's idea, I'm proposing we organize an IRC meeting. The meeting would happen on #kgi on openprojects IRC network. Currently, there's a bunch of us hanging around on that chanel at all times, but we need a time when everybody would be online. AFAIK most core developers are either on the east coast or western europe. This gives us a 6 hours difference so a time along the lines of early afternoon on the east coast and early evening in europe would work the best. It would seem that most people would prefer a weekend. How about saturday 24th of August at 1pm eastern time? This is perfectly flexible (personally I can make it almost anytime) so if anybody has a better idea feel free to suggest it. Here's a list of topic that I came up with that need adressing: * Multihead - proper design needs to be fleshed out. Should we be using images or redesign kgim to fit multiple displays on one board? - how does the monitor system tie in to multiple heads? What if each head uses a different ramdac? * Monitors - unifying the meta languages, separating the montior drivers from the board for easier loading * Core - VT switching between graphic/text * User space support - getting ggi and mesa drivers, resurrecting X server for ggi, generally making KGI actually useable for day to day use - getting some testers who would actually try the stuff out I'm certain there's a lot of other issues too. Everybody is invited to come, be it for discussing serious design issues or just catch up on KGI development or even just to chat with other KGI people. -Filip
Re: irc
Tijs van Bakel writes: > > I noticed that the webpages do not link to the #ggi IRC channel logs. > These are available from > http://vengeance.et.tudelft.nl/~smoke/log/ggi/ > > Christoph and Brian (as well as yours truly) are visiting the channel > frequently. Added. Thanks for this.
irc
I noticed that the webpages do not link to the #ggi IRC channel logs. These are available from http://vengeance.et.tudelft.nl/~smoke/log/ggi/ Christoph and Brian (as well as yours truly) are visiting the channel frequently. -- Tijs van Bakel, <[EMAIL PROTECTED]>
Re: comments to the IRC meeting
On Wed, 13 Dec 2000, John Fortin wrote: > > [20:14] For the other OSes I have no indication of status > > . anyone tested the Windows-DirectX-Stuff ? > > > > > > I can't, because I have no C-Compiler for Windows. > > Try > mingw (http://www.mingw.org) or > > cygwin (http://sources.redhat.com/cygwin/) > Both are win32 versions of the GNU toolchain. TNX a lot for that pointers. > > [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 > > > > > > > > IIRC John tested it on Win9x with DirectX 5. WinNT has an > > outdated DirectX 3. > > > There are 2 separate targets... One for NT4 and another for 95/98. > However, the CVS repository seems incomplete > and does not have them both. > > FYI, I was able to run XGGI with both versions Great! > > > > > > [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... > > > > > > > > AFAIR John said, that the directX-stuff, which is in CVS is outdated > > in comparison to his directX-tree. > > See above So could you commit your directX-tree into cvs, please? I hope, that it doesn't brake anything as we plan to make a final release... > > > > > > > I think, that's why people think, GGI is dead... > > > Also, Win32 people will not use it until it is clear that it is > cross-platform/Generic. That is why I was interested in it. However, > if the decision is really cross-platform/Generic meaning only linux/KGI, > then I'm not. I don't think so. As Andy said in the IRC, he prays the portability... ;-) Christoph Egger E-Mail: [EMAIL PROTECTED]
re: comments to the IRC meeting
On Wed, 13 Dec 2000, John Fortin wrote: > > [20:14] For the other OSes I have no indication of status > > . anyone tested the Windows-DirectX-Stuff ? > > > > > > I can't, because I have no C-Compiler for Windows. > > Try > mingw (http://www.mingw.org) or > > cygwin (http://sources.redhat.com/cygwin/) > Both are win32 versions of the GNU toolchain. Alternatively, you can do what I've done and run it on Linux using WINE's DirectX emulation. It requires some source tweaks and some additional WINE-specific init code, but it does work and is a LOT more convenient than setting up that huge Cygwin environment. And I never could get Mingw to work properly - apparently the project is only just now getting back on its feet. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
re: comments to the IRC meeting
> [20:14] For the other OSes I have no indication of status > . anyone tested the Windows-DirectX-Stuff ? > > > I can't, because I have no C-Compiler for Windows. Try mingw (http://www.mingw.org) or cygwin (http://sources.redhat.com/cygwin/) Both are win32 versions of the GNU toolchain. > > > [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 > > > > IIRC John tested it on Win9x with DirectX 5. WinNT has an > outdated DirectX 3. > There are 2 separate targets... One for NT4 and another for 95/98. However, the CVS repository seems incomplete and does not have them both. FYI, I was able to run XGGI with both versions > > > [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... > > > > AFAIR John said, that the directX-stuff, which is in CVS is outdated > in comparison to his directX-tree. See above > > > I think, that's why people think, GGI is dead... > Also, Win32 people will not use it until it is clear that it is cross-platform/Generic. That is why I was interested in it. However, if the decision is really cross-platform/Generic meaning only linux/KGI, then I'm not. John Fortin
Re: Comments to the IRC meeting
On Wed, 13 Dec 2000, Stefan Seefeld wrote: > Christoph Egger wrote: > > > I agree too. But how would you develop a higher-level lib without > > bloating it with lower-level-stuff? > > > > At first the lower-level ones have to be _finished_ and well > > done. Even the ones, which doesn't exist yet. > > right, to learn what a good extension mechanism is you have to actually > write an extension... What do you believe I am currently _doing_? :) > > LibXMI for example is a half-working one, because of some bugs > > (for example: ggiSetMode() doesn't work, _after_ xmiAttach() is > > called) and the software-rasterizer needs a _completly_ new rewrite > > to do it well. > > ...but the issue is not to care for extensions, but to separate > the generic parts from the extensions. That doesn't mean development > of the generic parts should be done without any care for the rest. You mean, libxmi is the generic 2d-extension and there should be extensions with special cases like libblit around it? Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: Comments to the IRC meeting
Christoph Egger wrote: > I agree too. But how would you develop a higher-level lib without > bloating it with lower-level-stuff? > > At first the lower-level ones have to be _finished_ and well > done. Even the ones, which doesn't exist yet. right, to learn what a good extension mechanism is you have to actually write an extension... > LibXMI for example is a half-working one, because of some bugs > (for example: ggiSetMode() doesn't work, _after_ xmiAttach() is > called) and the software-rasterizer needs a _completly_ new rewrite > to do it well. ...but the issue is not not to care for extensions, but to separate the generic parts from the extensions. That doesn't mean development of the generic parts should be done without any care for the rest. Regards,Stefan ___ Stefan Seefeld Departement de Physique Universite de Montreal email: [EMAIL PROTECTED] ___ ...ich hab' noch einen Koffer in Berlin...
Re: Comments to the IRC meeting
On Wed, 13 Dec 2000, John McCutchan wrote: > On Tue, Dec 12, 2000 at 10:23:12PM -0500, Stefan Seefeld wrote: > > Christoph Egger wrote: > > > > > [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 ... > > > > > > How about removing the current LibGGI2D from cvs and renaming libxmi > > > to libggi2d? > > > > this is a political decision. There are quite a number of 2d libraries, > > wasn't there even report of a libart based extension ? 'ggi2d' suggests > > that it is the one and only (official) 2d library for GGI. that might > > just not be true. (At least right now it is not true for ggi2d nor for > > ggi3d, and it wouldn't be true for any other 2d/3d library). > > To reiterate (and I think this is really important as a message to other > > people), I'd strongly suggest GGI to concentrate on the 'generic' part, > > and provide extension mechanisms to provide accelerated higher level > > libraries, without mandating any 'official' one. If nothing else, that > > will help keeping (or getting back, however you see it) GGI on scope. > > > > I completly agree. When ggi makes its official release the tree should > be cleaned of everthing but gii and ggi. Everything else is half-finished > and not working entirely, Its very important that people see that ggi > isn't dead and I don't think releasing an official release that has more > broken libraries then working ones is a mistake. I think Stefan is right > when he says that GGI needs to concentrate on providing a generic interface > that supports hardware acceleration through KGI. Everything else should > not be an official part of GGI. Perhaps add a section to the website > that contains projects such as libggi2d, etc. but in order to look > professional we can't have a bunch of half-working libraries which would > just distract people from ggi itself. > I agree too. But how would you develop a higher-level lib without bloating it with lower-level-stuff? At first the lower-level ones have to be _finished_ and well done. Even the ones, which doesn't exist yet. LibXMI for example is a half-working one, because of some bugs (for example: ggiSetMode() doesn't work, _after_ xmiAttach() is called) and the software-rasterizer needs a _completly_ new rewrite to do it well. Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: Comments to the IRC meeting
On Tue, 12 Dec 2000, Stefan Seefeld wrote: > Christoph Egger wrote: > > > Could you fix the permissions, please? I get a "permission denied", > > when I am looking to http://sourceforge.net/projects/ggi/ > > the project doesn't exist just yet. It's probably still waiting for > approval. (no idea why this is taking so long) The crond is running in an 6 hour intervall. But I think, sourceforge's infrastructure upgrade is the reason, why it isn't up yet... Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: Comments to the IRC meeting
On Tue, Dec 12, 2000 at 10:23:12PM -0500, Stefan Seefeld wrote: > Christoph Egger wrote: > > > Could you fix the permissions, please? I get a "permission denied", > > when I am looking to http://sourceforge.net/projects/ggi/ > > the project doesn't exist just yet. It's probably still waiting for > approval. (no idea why this is taking so long) > > > [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 ... > > > > How about removing the current LibGGI2D from cvs and renaming libxmi > > to libggi2d? > > this is a political decision. There are quite a number of 2d libraries, > wasn't there even report of a libart based extension ? 'ggi2d' suggests > that it is the one and only (official) 2d library for GGI. that might > just not be true. (At least right now it is not true for ggi2d nor for > ggi3d, and it wouldn't be true for any other 2d/3d library). > To reiterate (and I think this is really important as a message to other > people), I'd strongly suggest GGI to concentrate on the 'generic' part, > and provide extension mechanisms to provide accelerated higher level > libraries, without mandating any 'official' one. If nothing else, that > will help keeping (or getting back, however you see it) GGI on scope. > > Regards, Stefan I completly agree. When ggi makes its official release the tree should be cleaned of everthing but gii and ggi. Everything else is half-finished and not working entirely, Its very important that people see that ggi isn't dead and I don't think releasing an official release that has more broken libraries then working ones is a mistake. I think Stefan is right when he says that GGI needs to concentrate on providing a generic interface that supports hardware acceleration through KGI. Everything else should not be an official part of GGI. Perhaps add a section to the website that contains projects such as libggi2d, etc. but in order to look professional we can't have a bunch of half-working libraries which would just distract people from ggi itself. John
Re: Comments to the IRC meeting
Christoph Egger wrote: > Could you fix the permissions, please? I get a "permission denied", > when I am looking to http://sourceforge.net/projects/ggi/ the project doesn't exist just yet. It's probably still waiting for approval. (no idea why this is taking so long) > [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 ... > > How about removing the current LibGGI2D from cvs and renaming libxmi > to libggi2d? this is a political decision. There are quite a number of 2d libraries, wasn't there even report of a libart based extension ? 'ggi2d' suggests that it is the one and only (official) 2d library for GGI. that might just not be true. (At least right now it is not true for ggi2d nor for ggi3d, and it wouldn't be true for any other 2d/3d library). To reiterate (and I think this is really important as a message to other people), I'd strongly suggest GGI to concentrate on the 'generic' part, and provide extension mechanisms to provide accelerated higher level libraries, without mandating any 'official' one. If nothing else, that will help keeping (or getting back, however you see it) GGI on scope. Regards,Stefan ___ Stefan Seefeld Departement de Physique Universite de Montreal email: [EMAIL PROTECTED] ___ ...ich hab' noch einen Koffer in Berlin...
Comments to the IRC meeting
Hi all! [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:14] For the other OSes I have no indication of status ... anyone tested the Windows-DirectX-Stuff ? I can't, because I have no C-Compiler for Windows. [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 IIRC John tested it on Win9x with DirectX 5. WinNT has an outdated DirectX 3. [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... AFAIR John said, that the directX-stuff, which is in CVS is outdated in comparison to his directX-tree. [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. I think, that's why people think, GGI is dead... [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 Wrong. 3DtoolKit is a highlevel 3D-Scenegraph. Unfortunelty, the design still suffers on the old original development-work under DOS, but I plan to do a _completly_ redesign, when the current development-tree is finished. [20:22] Yes - thus I think we should strive for a release before Xmas or at least before the new year. [20:23] new year releases are good ;) new millenium releases are better ;-)) . [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? Well, I know, that this does _not_ work for me at all. It never worked for me since I am using GGI. Is any issue known, that a AT->PS2-adapter for the keyboard isn't handled correctly? [20:38] An easy one first: The map/unmap stuff c.Egger found ... [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:42] macarena: for the crossblit case it can be significant when blitting from a low bpp truecolor visual [20:48] Fixing it right would mean: Writing a bunch of "colormap-xxx" libs that [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. Andy (or should I say "macarena"?): You said, that unrolling the loop require to handle the different color schemes. How about moving the ggiUnmap()-handling into a linear_*/color.c, where we have no need for a switch()-case for the different color-schemes and we have no loop then. [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 f
IRC meeting 12 Dec 2000 summary
Summary of the irc session of Monday Dec 11, 2000 - This summary is available from the GGI webpage at http://www.ggi-project.org/irc/ The entire log for the discussion is available from http://vengeance.et.tudelft.nl/~smoke/log/ as are logs for each and every day of #demoscene/opn Introduction The meeting was held in #demoscene on the open projects irc network, see http://openprojects.nu/ for a list of servers. Four topics were discussed: 1 the new stable release 2 the future plans 3 progress on kgi 4 project management What follows is a summary of what was said regarding these topics. Please read the IRC log to find out more. Please report errors I made while summarizing as bugs. I will refer to people with their names as they appear in the log. A short list of realnames to help you out decrypting the logs: macarena - Andreas Beck seeger_s - Steffen Seeger stefan - Stefan Seefeld adamel - Marcus Sundberg soyt - Eric (he managed to hide his realname very well!) smoke - yours truly 1 the new stable release The API will not change before the first stable release of LibGGI. The most important targets (X, Xlib, DGA, memory, fbdev, glide, svgalib) only need some more testing. Regarding bug testing, see the last topic "4 project management". There are a few features that people would like to see added. Most important are messaging of changes to a SHM visual and event compression. Consensus has been reached to release ``beta3'' next weekend (16,17 Dec 2000). The release will feature binaries so that a broad audience can test it. A full release will appear before the end of the year! 2 the future plans -- Macarena explained that portability is of major concern. It is important to cover most unices using X11, but also a Windows port would be advantageous, as to make porting easier. The first plan is to get a release out. After that some volunteers are required to sort out maintenance. LibGGI2d and 3d need serious commitment, and it would be nice if more extensions would pop up, such as a sprite library. As LibGGI seems to fulfill Macarena's goals, he is losing interest a bit. Others obviously want more, so we will have to work on those projects ourselves. Especially regarding ports to other OS'es -- everyone is free to undertake such projects. 3 progress on kgi - Steffen told us he is lacking time, which is keeping KGI back. The main goals are to get an accelerated X server working and porting KGI to *BSD and The Hurd. A framebuffer-only version of X11 is semi functional. Getting XAA working proves hard, but it may be the best way to get decent acceleration. KGI is still healthy but progress is slow. 4 project management It seems important to set up a good bug tracking system. Adamel set up a sourceforge site for this. As for who's who: Macarena and Adamel will stay in charge of LibGGI and LibGII, all the other projects will (have to) be maintained by others. Soyt will take care of the website. Yours truly will maintain the IRC channel, please send newbies, developers and users there, so I can help them. -- Tijs van Bakel, a.k.a. Smoke/ECFh email: [EMAIL PROTECTED] webpage: http://vengeance.et.tudelft.nl/ecfh/
irc meeting about GGI's future
( This is sent to the GGI mailinglist as a reminder, and is CC'ed to the berlin-design mailinglist as an invitation. ) I'd hereby like to invite everyone who's interested in GGI's future to visit an IRC meeting at the Open Projects IRC Network. Interesting personalities such as Andreas Beck, Stefan Seefeld, Steffen Seeger, Marcus Sundberg will be there ;). Where: channel #ggi at such fine irc servers as irc.openprojects.net irc.debian.org irc.linux.org and many more, see http://openprojects.nu/ When: Sunday, December 10th, 2000 starting from 20:00 CET ( to figure out what time that is in your area, visit http://www.worldtimezone.com/, (thanks stefan :-) ) In order to get comfortable with IRC, and to get to meet the channelbot f00f, feel free to visit #ggi any time. Channel logs are and will be available from http://vengeance.et.tudelft.nl/~smoke/log/ Please send suggestions about topics to discuss either to the GGI mailinglist, or to me directly. I will have the list of topics handy on sunday, but I'm not planning to work out a perfect schedule. Hope to see you soon, -- Tijs van Bakel, <[EMAIL PROTECTED]>
Re: irc meeting about future of ggi
> ok, that will be December 10th, 20:00 CET > suits me fine and should be far enough from now for people to quit > making other appointments :) Ack - will be there. Cu, Andy -- = Andreas Beck| Email : <[EMAIL PROTECTED]>=
Re: irc meeting about future of ggi
Tijs van Bakel wrote: > > Marcus Sundberg <[EMAIL PROTECTED]> writes: > > > This weekend is bad for me. Weekend in two weeks is best I think. > > ok, that will be December 10th, 20:00 CET I'll try to be there, Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: irc meeting about future of ggi
Marcus Sundberg <[EMAIL PROTECTED]> writes: > This weekend is bad for me. Weekend in two weeks is best I think. ok, that will be December 10th, 20:00 CET suits me fine and should be far enough from now for people to quit making other appointments :) in order to get comfortable, feel free to visit the #ggi channel at the openprojects irc network, where the irc bot ``f00f'' will welcome you. note that the bot starts logging everything you say right away, keeping logs at: http://vengeance.et.tudelft.nl/~smoke/log/ -- Tijs van Bakel, <[EMAIL PROTECTED]>
Re: irc meeting about future of ggi
[EMAIL PROTECTED] (Tijs van Bakel) writes: > Steffen Seeger <[EMAIL PROTECTED]> writes: > > > Tijs van Bakel wrote: > > > > > > would anyone be interested in this? > > > it seems best to use the openprojects irc network > > > (http://openprojects.nu/) > > > > > > -- > > > Tijs van Bakel, <[EMAIL PROTECTED]> > > > > If you let me know when and where, I will try to attend. > > say sunday at 20:00 CET ? This weekend is bad for me. Weekend in two weeks is best I think. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 452062 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: irc meeting about future of ggi
Steffen Seeger <[EMAIL PROTECTED]> writes: > Tijs van Bakel wrote: > > > > would anyone be interested in this? > > it seems best to use the openprojects irc network > > (http://openprojects.nu/) > > > > -- > > Tijs van Bakel, <[EMAIL PROTECTED]> > > If you let me know when and where, I will try to attend. say sunday at 20:00 CET ? -- Tijs van Bakel, <[EMAIL PROTECTED]>
Re: irc meeting about future of ggi
Tijs van Bakel wrote: > > would anyone be interested in this? > it seems best to use the openprojects irc network > (http://openprojects.nu/) > > -- > Tijs van Bakel, <[EMAIL PROTECTED]> If you let me know when and where, I will try to attend. -- Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: irc meeting about future of ggi
On Tue, Nov 21, 2000 at 10:52:42PM +0100, Tijs van Bakel wrote: > > would anyone be interested in this? > it seems best to use the openprojects irc network > (http://openprojects.nu/) I'd be glad to attend to such discussions. Not that I have much to say about the subject yet, it's a bit early before being able to announce anything on a FreeBSD port, but just for listening purpose. This would be an open meeting? Nicholas -- Nicolas Souchu Alcôve - Open Source Software Engineer - http://www.alcove.fr
Re: irc meeting about future of ggi
Tijs van Bakel wrote: > > would anyone be interested in this? > it seems best to use the openprojects irc network > (http://openprojects.nu/) I would, and I would like to see it as soon as possible, with a possible (major) release following still before christmas. Things I'd like discussed are of course the release and the features going into it, as well as the short/medium term future, i.e. discussions about new stuff in linux 2.5 and how that may affect the project. Best regards, Stefan ___ Stefan Seefeld Departement de Physique Universite de Montreal email: [EMAIL PROTECTED] ___ ...ich hab' noch einen Koffer in Berlin...
irc meeting about future of ggi
would anyone be interested in this? it seems best to use the openprojects irc network (http://openprojects.nu/) -- Tijs van Bakel, <[EMAIL PROTECTED]>
Re: irc meetings - was Re: Where is the GGI project heading?
Andreas Beck <[EMAIL PROTECTED]> writes: > > Speaking of cube3d, I don't think I mentioned this screenshot here: > > http://www.stacken.kth.se/~mackan/ggi/ggidvd/pics/ggicube.jpg > > I shows ggidvd running on four sides of cube3d. (Don't try this at > > home unless you got a really fast machine...) > > Cool one. Can you do it with 4 different movies ? ;-). Define "can". You'd need at least a 4-way SMP-system to get full framerate on that... It might help if you ported cube3d to render from/to YUV, and use hardware YUV-RGB conversion for the final display. ;) //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 452062 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: irc meetings - was Re: Where is the GGI project heading?
> Speaking of cube3d, I don't think I mentioned this screenshot here: > http://www.stacken.kth.se/~mackan/ggi/ggidvd/pics/ggicube.jpg > I shows ggidvd running on four sides of cube3d. (Don't try this at > home unless you got a really fast machine...) Cool one. Can you do it with 4 different movies ? ;-). Even with only one: That one needs a place in the cube gallery. CU, ANdy -- = Andreas Beck| Email : <[EMAIL PROTECTED]>=
Re: irc meetings - was Re: Where is the GGI project heading?
[EMAIL PROTECTED] (Christoph Egger) writes: > > While i'm on a rant, if you want to impress individuals, create a GGI demo > > that users can see, that shows off GGI's capabilities. > > That's already quite done. Have a look at cube3d, etc... Speaking of cube3d, I don't think I mentioned this screenshot here: http://www.stacken.kth.se/~mackan/ggi/ggidvd/pics/ggicube.jpg I shows ggidvd running on four sides of cube3d. (Don't try this at home unless you got a really fast machine...) //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 452062 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: libggi showoff (was: irc meetings)
> > While i'm on a rant, if you want to impress individuals, create a > > GGI demo that users can see, that shows off GGI's capabilities. in > > fact, a excelent move would be to copule with some game developer > > (worldforge might be a good one), and help maintain the client. (of > > course makeing it a GGI client, so everyone has to install GGI). > > since they aren't really close to a release of their big system, > > they probably wouldnt care that there weren't any other working > > (non-ggi) targets, for a while. but while the "lightweight games" > > were being produced, you could get away with promoting GGI in > > exchange for developing the client. by the way, for those who don't know, i should mention that worldforge was a clone of ultima online, which now has more aggressive goals then the ultima series. > IMHO the main advantage in libggi might be its extendable design, but > this isn't exploited in too many ways, so I like your second option > much more. Personally I detest agressive games like Quake, but I'm > sure someone would like to take up this project. > > > Option #2: add mutiple camera support to quake. Those who have > > multi-monitor combinations would have a substantial advantage over > > everyone else, and soon multi-monitor would be a requirement to play > > over the net. > > A multimonitor pong would be interesting too. > (Oh and isn't this easily possible with Windows and/or X11 already?) i've been trying to get multi-monitor support working under Xfree86 since 1994 (was it called xfree then?) or so, but i've never gotten anything other then a mono card + a vga card working with the vga16 server. (i.e. unusuable). i've heard that xfree86 4.0 has some new support, but haven't investigated it. Corey
libggi showoff (was: irc meetings)
<[EMAIL PROTECTED]> writes: > While i'm on a rant, if you want to impress individuals, create a > GGI demo that users can see, that shows off GGI's capabilities. in > fact, a excelent move would be to copule with some game developer > (worldforge might be a good one), and help maintain the client. (of > course makeing it a GGI client, so everyone has to install GGI). > since they aren't really close to a release of their big system, > they probably wouldnt care that there weren't any other working > (non-ggi) targets, for a while. but while the "lightweight games" > were being produced, you could get away with promoting GGI in > exchange for developing the client. The linux demoscene may be able to do this. From my experience most people who care for nifty demonstrations prefer 3d fly-through demos. Note that using libggi for something like this would make you look like a fool compared to using Direct3d and DirectX or OpenGL. Libggi is pretty good at doing 2d graphics, but it adds nothing over svgalib or X11 in terms of speed. That could only be done by boosting KGI, and even then it would be quite hard (or senseless). IMHO the main advantage in libggi might be its extendable design, but this isn't exploited in too many ways, so I like your second option much more. Personally I detest agressive games like Quake, but I'm sure someone would like to take up this project. > Option #2: add mutiple camera support to quake. Those who have > multi-monitor combinations would have a substantial advantage over > everyone else, and soon multi-monitor would be a requirement to play > over the net. A multimonitor pong would be interesting too. (Oh and isn't this easily possible with Windows and/or X11 already?) -- Tijs van Bakel, <[EMAIL PROTECTED]>
Re: irc meetings - was Re: Where is the GGI project heading?
On Tue, 29 Aug 2000 [EMAIL PROTECTED] wrote: > > > PS: oh, and holding IRC meetings to get some synergy back into the group > > > is certainly helpful as well... > > > > I agree. But that may be for some people too expensive - especially for one, > > who lives in germany like me... (Wanna say: the telephone costs!) > > > > I prefer a mailing-list, because of the high telephone costs. > > when i was working with the dosemu team, we would have a IRC meeting every > other saturday, then keep a log (actually, i think they still hold them > without me). If we started up IRC meetings, we could find someone to > forward a log to the mailing list for each meeting, (then Christoph could read > though them ;) Great idea. I like it. > While i'm on a rant, if you want to impress individuals, create a GGI demo > that users can see, that shows off GGI's capabilities. That's already quite done. Have a look at cube3d, etc... > in fact, a excelent move would be to copule with some game developer > (worldforge might be a good one), and help maintain the client. (of course > makeing it a GGI client, so everyone has to install GGI). since they aren't > really close to a release of their big system, they probably wouldnt care > that there weren't any other working (non-ggi) targets, for a while. but > while the "lightweight games" were being produced, you could get away with > promoting GGI in exchange for developing the client. In generic: Helping out other projects, porting them to GGI would increase the GGI users a lot. > Option #2: > add mutiple camera support to quake. Those who have multi-monitor combinations > would have a substantial advantage over everyone else, and soon multi-monitor > would be a requirement to play over the net. A very good idea. Unfortunately, I can't do that, because: 1. I have only one monitor 2. I am busy with my own project (which uses GGI, of course :) CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
irc meetings - was Re: Where is the GGI project heading?
> > PS: oh, and holding IRC meetings to get some synergy back into the group > > is certainly helpful as well... > > I agree. But that may be for some people too expensive - especially for one, > who lives in germany like me... (Wanna say: the telephone costs!) > > I prefer a mailing-list, because of the high telephone costs. when i was working with the dosemu team, we would have a IRC meeting every other saturday, then keep a log (actually, i think they still hold them without me). If we started up IRC meetings, we could find someone to forward a log to the mailing list for each meeting, (then Christoph could read though them ;) While i'm on a rant, if you want to impress individuals, create a GGI demo that users can see, that shows off GGI's capabilities. in fact, a excelent move would be to copule with some game developer (worldforge might be a good one), and help maintain the client. (of course makeing it a GGI client, so everyone has to install GGI). since they aren't really close to a release of their big system, they probably wouldnt care that there weren't any other working (non-ggi) targets, for a while. but while the "lightweight games" were being produced, you could get away with promoting GGI in exchange for developing the client. Option #2: add mutiple camera support to quake. Those who have multi-monitor combinations would have a substantial advantage over everyone else, and soon multi-monitor would be a requirement to play over the net.
Re: IRC
Mardy <[EMAIL PROTECTED]> writes: > Is irc.ggi-project.org down? > Is there any place you met? I'm feeling very lonely in #ggi on the Open Projects Net IRC network, for some time now. Every now and then someone pops in. http://openprojects.nu/ has a list of servers -- Tijs van Bakel, <[EMAIL PROTECTED]>
IRC
Is irc.ggi-project.org down? Is there any place you met? Bye, Mardy
Re: joined irc meeting GGI - Berlin (fwd)
> Subject: joined irc meeting GGI - Berlin > since I'm not subscribed to any of the GGI mailing lists, > could you please forward this mail to an appropriate forum ? So he did > We'd like to design the appropriate structures/tools to be > able to process events from arbitrary input devices. Since > you probably already did some work in this direction, what > about an irc meeting with people from GGI and Berlin so that > we can learn a bit from your experience ? Fine with us. Please suggest a time/date and we will see to find a common denominator. > The current idea is to manage attribute lists so that individual > devices are flagged for each supported attribute. Each attribute > in this property list then hints at an entry of some type within > the event's attribute list. > Possible attributes would be (together with the corresponding > type in the event structure) > > telltale -> bitset > positional -> (2D/3D vertex) > key-> long (keysym) > value -> float > > so that *every* input device would be described as a combination > from the above elementary types. This is relatively similar to what LibGII does. The basic types are Keys (with Press/Release/Repeat events) which consist of three fields: Code (arbitrary number just unique for the device in question) Label (What is printed on the key ?) Symbol (What symbol should be produced by it given the current modifiers). and Valuators, which are sets of analog inputs divided into multiple "values" or axes. > An event would need (at least when > thought of as the most general thing which can happen) to hold > one such list (the changes triggering this event) and a set of lists > (one per connected device) to show the total state of the input devices. We decided to use a delta-only approach, as holding the complete device state is usually not needed. If an application wants to track state, it can, but most of the time it's just wasted ressources. BTW in case you wonder: LibGII can send events _to_ devices as well. This feature will be useful for force-feedback, and is now used for querying device and axis-properties. A libGGI device can tell you what the individual valuators mean, like if they are measuring angles, forces, > Well, this is all theory. How this can be made efficient and whether > we really need such a general approach is what we would like to discuss > with you. If possible, we'd like to have such an irc meeting as soon as > possible (before christmas that is) Sure. Suggest a date and time. Regarding timezones, we seem to have MET for the people on the GGI side I am thinking of (me and Marcus - others welcome as well of course), which will also suit your swedish member. Then we have US and CA, what probably calls for a time in the evening in Europe, so that the US people have a reasonable time as well. Graydon: Where are you from ? .com can be anywhere nowadays ... :-). > since a working input system is what > we need next to make text processing possible... Well - your ideas are pretty close to what LibGII provides. Hopefully we can make a very efficient interface layer. CU, Andy -- = Andreas Beck| Email : <[EMAIL PROTECTED]> =
joined irc meeting GGI - Berlin (fwd)
-- Forwarded message -- Date: Mon, 29 Nov 1999 19:24:04 + From: Stefan Seefeld <[EMAIL PROTECTED]> To: Jon M. Taylor <[EMAIL PROTECTED]>, Graydon Hoare <[EMAIL PROTECTED]>, Niklas Elmqvist <[EMAIL PROTECTED]> Subject: joined irc meeting GGI - Berlin Hi Jon, since I'm not subscribed to any of the GGI mailing lists, could you please forward this mail to an appropriate forum ? Thanks ! We'd like to design the appropriate structures/tools to be able to process events from arbitrary input devices. Since you probably already did some work in this direction, what about an irc meeting with people from GGI and Berlin so that we can learn a bit from your experience ? The current idea is to manage attribute lists so that individual devices are flagged for each supported attribute. Each attribute in this property list then hints at an entry of some type within the event's attribute list. Possible attributes would be (together with the corresponding type in the event structure) telltale -> bitset positional -> (2D/3D vertex) key-> long (keysym) value -> float so that *every* input device would be described as a combination from the above elementary types. An event would need (at least when thought of as the most general thing which can happen) to hold one such list (the changes triggering this event) and a set of lists (one per connected device) to show the total state of the input devices. Well, this is all theory. How this can be made efficient and whether we really need such a general approach is what we would like to discuss with you. If possible, we'd like to have such an irc meeting as soon as possible (before christmas that is) since a working input system is what we need next to make text processing possible... Best regards, Stefan
