GGI team IRC meeting, Sunday June 7th
 HTMLized by Emmanuel Marty (core@ggi-project.org)

Developers nicknames
andrew: Andrew J. Apted
asvogler: Andreas Vogler
bri: Brian S. Julin
bkosse: Ben Kosse
core: Emmanuel Marty
fries: Todd T. Fries
Hartmut: Hartmut Niemann
Jason_McM: Jason McMullan
MacArena: Andreas Beck
MentalGuy: himself
mars: Stefan Mars
Mat: Matthieu Guillaume
ortalo: Rodolphe Ortalo
ShadowX: Steve Cheng
tan: Thomas Tanner

Covered topics
New CVS repository
New directory layout
New LibGGI extension scheme
LibGGI issues (as pointed out by Hartmut)
  • Multiple buffering
  • Optimizing targets emulating DirectBuffer
  • ggiInit() nested calls
  • switch-away/switch-back behavior
  • alpha values management
  • "display-" prefix
  • memory visuals
  • buffer opacity
    GGI licensing
  • Include files
  • LibGGI subsystem
  • KGI subsystem
    Discussion end

    Session starts - New CVS repository (15:00 GMT)
    [MacArena] O.K. Then let's start ... could we please schedule ongoing discussion for after the "official part" or moved then to /msg ? TNX.
    [Mat] Anyone logging the meeting ?
    [Jason_McM] Ok - I'll keep comitting...
    [core] mat: yes, it is being logged
    [core] please everyone keep personal discussion to /msg until the official meeting is complete
    [MacArena] O.K. - first point. CVS.
    [Jason_McM] How do you use /msg? (I don't use IRC often)
    [MacArena] Is everything working again for all ? Please only report problems. 20x yes is a bit too much :-)
    [core] jason_mcm: /msg nickname message, or /query nickname, then talk as usual, and redo /query again to end it
    [core] I have suspended anonymous CVS access until the official meeting is complete because of the massive bandwidth of the initial checkouts currently happening, but other than that, it works for people who type their CVSROOT right :)
    [tan] how do I set my email address?
    [MacArena] O.K. Now for the new CVS scheme.
    [MacArena] As you have noticed, there are _two_ repositories. The devel and the stable one.
    * ShadowX commit done
    [MacArena] Only few people will have access to the stable repository, while all can Play around in the devel one.
    [Erich] sorry
    [mars] Will everyone have _read_ access to the stable if they want to check it out?
    [Yazz] Is it two branches or two separate trees?
    [core] mars: yes, you can use the guest access for it
    [fries] two separate trees .. I've been made aware of that
    [MacArena] The way we do changes to the stable repository will be radically different from the earlier method:
    [core] yazz: two seperate trees, as Andreas want people to explicitly check their code (what he'll explain in a second)
    [MacArena] It is done by sending diffs.
    [MacArena] Yes - this sounds like stoneage, but there is a reason.
    [Hartmut] It's not about being modern or not, it'a abut at least one person
    [MacArena] The reason is, that the maintainers with RW access to the stable tree are encouraged to check the diffs thoroughly
    [Hartmut] proofreading changes :-)
    [fries] MacArena: the reason being you want to control what goes in the stable repo. I hope you know the amount of work you're asking of those with access :-)
    [core] yes - this is not to be seen as headgrowing symptoms. just to avoid uncoordinated changes
    [MacArena] and only commit, if they are _complete_. This will avoid having inconsistent state like after the DPP change.
    [asvogler] won't this slow development?
    [ShadowX] makes sense
    [core] our goal is to provide our 'customers', like Berlin, with a tree they know they can compile and use, all the time
    [mars] It's not different from the way used by the linux-kernel people Fries, and they are doing an excellent job
    [core] asvogler: development will go on full speed in the devel tree. only the stable versions will get completed, not half-complete, changes
    [core] devel snapshots will be generated as well, therefore not hindering any development
    [MacArena] asvogler: A bit - maybe. But it should get us better "reputation" regarding having always a stable, compileable version.
    [fries] mars: I guess. but torvalds just likes proofing patches and doesn't see the 'light' of cvs.
    [core] fries: well, the result is that people do trust the 2.0.x versions - i don't see that as being bad
    [mars] fries: It still works. I think it's an excellent idea for us to use
    [asvogler] MacArena: I guess we just have to tri this out to see if it works good
    [bri] it also would cut down on the autocommenting of each revision even for typo fixes.
    [fries] mars: I can't complain very much as I'm not the person maintaining the link between development and stable. I just am scared it will become a nightmare.
    [MacArena] well - with well done diffs, this shouldn't be a big problem ...
    [core] fries: we are five persons to maintain the stable repository.. if we aren't enough, we'll call for more
    [mars] fries: We can always increase the number of people will write access to the stable tree. And it doesn't matter if the stable lags a few days behind since the rest of us use the devel tree
    [MacArena] O.K. - so much for the "split repositories".

    New directory layout (15:13 GMT)
    [MacArena] Now for the new directory layout
    [Yazz] fries: If stuff is merged over 'quite often' it shouldn't be a problem
    [andrew] macarena, it's a shame that "cvs diff" doesn't produce nice diff files
    [fries] andrew: try 'cvs diff -u ' :-)
    [MacArena] The aim is to aid packaging the independent parts LibGGI, KGI, Documentation, ...
    [Yazz] andrew: What's un-nice about them?
    [andrew] yazz: it chops off the directory paths
    [bri] beware of cvs diff -- always make sure local copy is most recent revision, it will diff against the same rev as the local copy
    [Yazz] andrew: Yeah, i remember i got bitten by that one sometime...
    [knghtbrd] MacArena - this is greatly appreciated by the package-based dists, I assure you
    [fries] bri: unless you use '-r rev1 -r rev2' :-)
    [core] well, all one will have to do is to update the stable tree and diff your work against it
    [MenTaLguY] whew. afternoon folks; I just remembered the meeting :P
    [core] then check the patch carefully, and send it to one of the five persons mentioned
    [core] ah well, now for the new directory layout yes :)
    [MacArena] For this, the KGI-specific parts of LibGGI have been moved to the kgi directory
    [Hartmut] About the parts: what will that be. libggi-base for one, and the others?
    [MacArena] The patches directory will probably be renamed to something more generic and will hold all "OS-addendums" we need to make KGI drivers run on a particular OS.
    [MacArena] Has anyone who already checked the tree out seen some obvious flaw in the organization ?
    [fries] MacArena: ah, so like X targets and such will still be in libggi
    [ShadowX] i still see display/kgi in libggi, so what have been moved?
    [core] macarena: having moved the kgi-backend libraries into kgi is a good idea.
    [MenTaLguY] that sounds like a wise move
    [MenTaLguY] putting the KGI-dependent libggi stubs in the KGI section of the tree, I mean
    [MacArena] Seems this is not the case ...
    [MacArena] O.K. - a few words about the /doc/ tree.
    [bri] ShadowX -- the driver-libs
    [fries] ShadowX: is that an empty subdir?
    [fries] have to use 'cvs update -P' to prune empty subdirs
    [ShadowX] bri: ah ok
    [Hartmut] The 'such' is a good point. What targets will be part of the 'base'?
    [core] shadowx: the KGI target for libggi is of course still there, but the backend vendor libraries moved to their rightful place, under kgi/
    [Jason_McM] I think the docs should be in their target directory, ie libggi/doc
    [Jason_McM] that way you can just `tarball' off a tree and it'll be documented
    [Jason_McM] (which still leaves the includes for KGI in the wrong place...)
    [MacArena] Hartmut will maintain this, and it will take all _complex_ documentation.
    [MacArena] _Very_ basic docs like README,INSTALL,TODO and Manpages are allowed in the individual subtrees.
    [ShadowX] jason: however some parts are intermix in docs
    * MenTaLguY nods slowly
    [ShadowX] ???
    [Jason_McM] Actually, why not move the whole KGI backend pieces form libGGI?
    [core] jason_mcm: including the KGI target?
    [Jason_McM] They won't compile w/out the KGI includes, anyway.
    [core] jason_mcm: true, it doesn't have much use without KGI
    [Jason_McM] Including the KGI target.
    [Hartmut] What about the sgml doc for KGI: where is the txt and html file going? Same directory? subdirectories (as now)?
    [MenTaLguY] could always symlink libggi/doc in, and use -h with tar to pull in the docs
    * MenTaLguY blinks
    [MenTaLguY] ohhh... MacArena ... I was reading that "Mac Arena", and was wondering what the heck was going on :P
    [MenTaLguY] maca: maybe you should avoid bicapitalizing that to avoid confusion?
    [MenTaLguY] MacArena: if you think that client is bad, try using M$ Comic Chat sometime
    [asvogler] when can we expect the kgi-parts to appear in CVS?
    [ShadowX] why have to m$?
    [core] asvogler: jason is commiting evstack
    [ortalo] Please: no m$... forget about it...
    [asvogler] core: now?
    [MenTaLguY] MacArena: M$ CC broke the CTCP protocol entirely in the first versions, dropped it subesquently, and only now is it back and sort of working (although afaik there's no way for the user to use it themselves)
    [Hartmut] Jason: you put kgi.sgml into kgi/doc. Where would you like to have kgi.txt go?
    [ortalo] Why do you think the KGI-target should go outstide of libggi/
    [core] asvogler: yes, but please don't do CVS activity until after the meeting :)
    [Jason_McM] KGI will appear in CVS in about an hour - I just recently
    [MacArena] Hartmut : I leave the decision about where to put .txt,.html,.??? to you ...
    [Jason_McM] got where to put it from Andreas...
    [mars] Hmm.. can't we make a special include-package that is used by all other packages for those who compiles themselves?
    [MacArena] asv: As soon as Steffen is back from USA. Should be next week.
    [MenTaLguY] mmm ... that's a thought
    [ShadowX] mars: sgmltools not easy
    [Jason_McM] Hartmut: Wherever you want. What I was thinking of was that all
    [MacArena] core: Yeah - and my money ...
    [fries] we should've arranged for Steffen to have a us isp for this chat :-)
    [Jason_McM] sgml would be at the top, a html dir for the html, a text dir for the
    [MenTaLguY] we need to think about making life easier for those intrepid souls who want to compile libggi targets and stubs outside of the libggi tree
    [Jason_McM] text, etc...
    [MacArena] Are there more questions about the CVS directory structure ?
    [fries] ShadowX: you know how easy it would be to setup Makefiles to generate the stuff from sgml?
    [core] macarena: i guess it's being heavily debated :)
    * MenTaLguY nods thoughtfully
    [fries] MacArena: the base module name?
    [core] macarena: about KGI - will evstack form the base of the new KGI, or will steffen go for someting entirely new?
    [Hartmut] fries: no problem, they exist. One problem is different directories, but with my autogenerated makefiles I can do that. I did in the old tree.
    [ShadowX] fries: but new sgmltools seem to require Perl 5.something, may be it's not that important
    [bkosse] I'm sorry, I missed it, but why did you want the libggi KGI target outside of the libggi dir, Jason_McM?
    [fries] ShadowX: perl5 has been around for greater than a year. if you haven't upgraded now is as good a time as any.
    [fries] kbosse: so libggi could be distributed separately
    [Hartmut] shadowx: you mean sgml-tools 1.0.?, don't you? Yes, Perl 5.004 and up. annoying, but not too bad. Worse is that the txt target has some problems.
    [MacArena] core: don't really know. I think the idea is to use the fbcon version as the primary port.
    [mars] bkosse: Because the KGI target wouldn't compile anyway
    [Jason_McM] bosse: fries said it..
    [fries] :-)
    [ShadowX] fries: yeah perl 5.004, don't have that
    [core] macarena: ah, ok. i'm asking, because drivers will not be able to work with both the evstack and the dali interface, a choice has to be made now
    [MacArena] ortalo: separating the kgi specific parts from LibGGI eases compiling and keeps things together, that belong together.
    [MenTaLguY] so, how _are_ we going to allow people to compile libggi targets and stubs outside the libggi tree?
    [bri] Lots of targets won't compile w/o extra headers, anyway, why should it be different?
    [bkosse] But, isn't that supposed to be just a target, like X, SVGALib, etc?
    [Yazz] macarena: Should we remove the X target too? Some people doesn't have X, or svgalib or glide?
    [fries] Mentalguy: sounds like headers get installed somewhere
    [MenTaLguY] afaiK, the KGI target stays, but just the hw-specific libggi stubs get moved into the KGI part of the tree
    [MacArena] Another thing about includes and docs. In case one needs them in a central place or in the local directories, one should change the Makefiles to make symlinks.
    [MenTaLguY] fries: like, where?
    [fries] kbosse: a target for specific hardware.
    [Hartmut] What would be the 'core' (no pun) libggi target(s)? I vote for X and Xlib, and package everything seperately.
    [MenTaLguY] fries: well, more like the stubs for specific hardware
    [ortalo] It is the same for X in fact: I don't use X, don't have it installed, so the X-target should be removed from libggi/ (No I am kidding of course, but I could have said the truth speaking of SVGAlib)
    [bkosse] mental: That makes sense. Sorry I'm slow today, I just woke up.
    [MenTaLguY] fries: they'd all get loaded by the KGI target
    [fries] mentalguy: the default, /usr/local/include/ggi or /usr/local/lib for libs ..
    [mars] I say it again, I really think we should move all includes into a special package that people have to download to compile. That would make it possible to leave the KGI target in libggi, and still be able to compile it
    [Jason_McM] I agree with Hartmut about packaging... However, I am beginning to
    [Yazz] hartmut: I'll rather have most targets in the distribution, but they don't have to be compiled when you compile.
    [Jason_McM] think that having them in the same place _in_CVS_ may be a good idea...
    [fries] btw that reminds me .. the Makefiles I need to mod so they allow 'make install DESTDIR=/usr/local' or 'DESTDIR=/usr' or wherever a person wants .. for easier package building too ..
    [MenTaLguY] fries: but targets and stubs need the stuff in ggi/lib/libggi/include, but ggi/lib/libggi/include/ggi is what actually gets installed -- unless that's changed with the new directory tree
    [MenTaLguY] mmm
    [MacArena] STOP.
    [fries] mars: can't do that and have separate libggi and kgi packages
    [core] well, maybe having a top-level include/ subdir, making a seperate package, as Stefan is suggesting, would be a good idea. this way the KGI target could remain part of libggi package, and the KGI backend libs can be moved to the kgi package
    [ShadowX] fries: i thought it already has that... it asks that with the dialog install... may be i've been tricked ? :)
    [mars] fries: Why not?
    [MacArena] The KGI TARGET will not be moved out. The vendor-IBM-vga16 and such will be.
    [MenTaLguY] mmm
    [MenTaLguY] DESTDIR= also needs dealing with
    [MenTaLguY] guys, maybe we should consider switching to autoconf and automake?
    [fries] Jason_McM: sounds like to me the real action will be in the development tree. once things stabalize it will be moved to the stable tree in massive updates so the 'stable stuff' is what people see and come to rely on being reliable.
    [Jason_McM] I agree w/MacArena now...
    [mars] macarena: I don't think they should be, because they are in fact parts of LibGGI
    [MacArena] core: Yes. This is how it is, and how it was intended.
    [Yazz] mantalbuy: Autoconf maybe, but automake, no.
    [MenTaLguY] I mean, a lot of the stuff in the current configure script is just reinventing the wheel
    [core] macarena: yes, i saw that in the tree. suits me.
    [MenTaLguY] for instance, my detect_library() hack in configure does the same job as autoconf's AC_CHECK_LIB, but is MUCH less reliable
    [MenTaLguY] Yazz: what's wrong with automake, just out of curiousity?
    [MacArena] mars: They are taylored for specific KGi drivers. Though they are technically part of LibGGI, they have to be engineered to meet the KGI driver. Thus they should be close to it.
    [core] just one thing about includes, all libraries should use the same system.h file - i don't want to spend 3 days reporting every single system.h to IRIX for example, and that makes no sense
    [Yazz] mentalguy: Well, it tries to be smart. For an 'normal' app it's ok. But it can be hard to make it do 'special' things.
    [andrew] macarena: does KGI specific color code (e.g. palette) move too ?
    [MacArena] core: Exactly. I have moved Makefile customization to a toplevel directory.
    [Jason_McM] That's been all moved to the ggi/types.h file in my commit...
    [core] macarena: oh. great :)
    [MenTaLguY] Yazz: I've been playing with it a while, and that's only partially true
    [fries] ah, so the libggi extensions that are specifically for a type of hardware will be developed along with the kgi hardware drivers?
    [MacArena] mars: And another thing. LibGGI would some day overflow with vendor-*-* files ...
    [Jason_McM] fries: Yes, that's the plan.
    [MenTaLguY] Yazz: you can fall back on doing everything yourself in Makefile.am where necessary
    [core] jason: the one i had ported from dali in the patch on my page? allright
    [MenTaLguY] Yazz: but it sure does make doing relatively conventional things a lot easier
    [fries] mentalguy: soon as I figure out what module to co I will be working on the DESTDIR thing
    [mars] macarena: Is it better if KGI becomes overflowed. Then we should rather make a package for each vendor
    [MacArena] andrew: no - such things are relatively generic. BTW: they really are now ...
    [Jason_McM] core: Yep, that's the one (I think.. ;^)
    [MenTaLguY] Yazz: and I daresay building libggi and stubs would be facilitated greatly by the use of libtool
    [fries] mentalguy: can we postpone autoconf/automake discussion until we finish new directory layout?
    [core] jason_mcm: okay, just wondering :)
    [mars] Keep the vga libs with KGI and move evrything else out
    [Yazz] mentalguy: Yes, i use it for the app i'm currently working on. Works like a charm, libtool is not perfect though.
    [MenTaLguY] fries: oh, sure
    [core] by the way, should we use GCC word sizing when __gcc__ is defined, rather than writing one per arch? (ie. you can request an exactly 32-bit int and such)
    [MenTaLguY] that sounds like a good idea
    [bkosse] Mars: why keep the VGA libs there? They're worthless on a SLinux or mklinux, etc, right?
    [MacArena] mars: Yes. And if they are already together in /kgi, this makes it easier ...
    [MenTaLguY] I'd better go check out the new tree
    [Yazz] It seems a lot of thins are 'moved out'. Where exactly are they moved?
    [MacArena] mars: Yes - this might be an option in the near future.
    [MenTaLguY] Yazz: re: moving the hw-specific libggi stubs (not the KGI target itself, though) into the KGI portion of the tree
    [Hartmut] macarena: in the long run we must be prepared for including sub-trees for single vendors, or exclude them, and probably auto-adjust the menu system. Why should one with a Millennium have the S3 tree installed?
    [Yazz] MentalguY: Ok.
    [MacArena] O.K. - looks like directory structure is discussed enough - right ?
    [fries] mentalguy: the one thing that autoconf doesn't do that the makefile customization can do is eventually support gnu make and bsd make transparently w/out having to require one or the other
    [bkosse] Hartmut: Why should I download the linux/drivers/sgi or /linux/drivers/scsi then?
    [ShadowX] the other problem is binary-only kgi drivers? you can't put that in the tree, but could it be integrated in the tree by the user?
    [Jason_McM] bkosse: Good question. ;^)
    [mars] bkosse: Just because the standard kernel isn't modularized into different packages, doesnt make it a bad idea for us
    [MenTaLguY] fries: hold that thought
    [fries] ShadowX: binary drivers would be almost like a package of their own, wouldt they be?
    [bkosse] The answer is because the computer could A) be shared B) be replaced, C) get HW added, and a few other less essential reasons.
    [Hartmut] bkosse: because Linus doesn't have a volunteer to split up the tree.
    [bri] Is the OS dependent configuration stuff that was new in degas way back long time ago still in there and working? Otherwise I'm happy to end discuss of source tree.
    [mars] bkosse: The answer to that is that when you get new hardware you get the new necessary libs
    [MenTaLguY] patches also get weird with a partial source tree
    [chris] mars: I have seen some tools that try to remove things from the kernel that you don't need to save space. Perhaps something like that built default into GGI would be nice. And have configure smart enough to remove the missing parts from the menus.
    [bkosse] Good lord, do you know how annoying that would be? Let's see here, what do I need to D/L:
    [ShadowX] fries: obviously, but if we want nice trees, someone might want to download a separate binary driver and have it auto configure along with the rest... may be that's too much to ask for?
    [MenTaLguY] some sort of tool to facilitlate that would make life rather easier
    [bkosse] Kernel base, now I've got to pick all my drivers individually....
    [fries] shadowx: that or you have it installed, thenyou download the binary package, that auto-adds itself to /etc/ggi/libggi.conf
    [mars] bkosse: But the current way is a huge waste of diskspace on most systems. It takes an etermity to download for most people
    [core] well, okay, so current problems before we close discussion on directory tree are :
    [core] 1) where and should we put binary-only drivers
    [core] 2) should we include all drivers to everything all the time
    * MenTaLguY nods
    [korey] if the driver packages are separate, it would facilitate vendors providing thier own drivers
    [core] one at a time :)
    [MenTaLguY] and if the kernel gets split, someone is going to make a web-based tool for picking and combining driver sets, or if nobody does, I'll suggest it
    [core] (problem that is)
    [Mat] Shouldn't binary-only drivers go directly to /lib/modules/whatever ?
    [Hartmut] core: ad 1: that leaves another point open: is make clean in the KGI tree smart enough not to remove binary drivers that come as .o files only?
    [MenTaLguY] well, probably a real application would be more useful than something web-based
    [MenTaLguY] that'd be a relatively simple PERL hack, I suppose
    [ShadowX] mat: not enough, there may also be libggi drivers
    [bkosse] That's the thing, Mentalguy. To support something like breaking apart the tree, a *VERY* good system would need to be in place for picking the drivers.
    [bri] Well let's be clear developers should have a mostly complete tree, but non-developers should be able to download/compile their part only without too much hassle deciding what to download. You can't make everyone happy on this, so KISS.
    [MenTaLguY] bkosse: yep. and for applying patches to an incomplete tree
    [core] bri: i agree, that's mostly a snapshot generation problem that we don't have to tackle now
    [ortalo] I have a last stupid question: where do I put the file cl546xio.inc in the source tree ? (To make it simpler: where are the KGI source files in CVS, RIGHT NOW ?)
    [fries] bri: ya, that is the plan as I understand it. all src in 1 of 2 trees (stable/development) and the individual parts are split for distribution
    [MacArena] I think that hits the point.
    [core] ortalo: nowhere right now, be patient :)
    [MacArena] I'd suggest to do the following about it:
    [Jason_McM] I'm about 10 min away from the KGI commit - there's still
    [MacArena] Split things to several packages that can be downloaded seperately. The goes for Libs and such.
    [Jason_McM] some problems with kernel patching and driver building, but it's
    [chris] MenTaLguY: DOSEmu supplies multiple diffs and a script to apply them. Something like that could be used to upgrade incomplete trees between versions.
    [Jason_McM] all patchname changes...
    [Jason_McM] (pathname changes)
    [MacArena] For KGI, I suggest to have a "please give/compile me a module for ???" server somewhere. E.g. using a Web based interface.
    [bri] And have a second package with the same name "blah"-distrib which gets the extra bits a non-developer would need to compile just that part?
    [MenTaLguY] chris: mm... that works
    [MenTaLguY] chris: be nice to have a tool that could take an existing patch and apply it only to what exists
    [MenTaLguY] chris: of course, that's difficult to deal with adding files via patch, then
    [erich] MacArena: wouldn't be a huge problem. especiall using PHP3 and perhaps mysql
    [MacArena] O.K.: So we can summarize :
    [core] macarena: yes
    [chris] MenTaLguY: Yeah, I had thought of that too. Probally just create the new file and clean it off again if it isn't needed when you build. Not quite sure how to work that.
    [MacArena] The tree as it is is rather o.k. for developers. It might need some filling in of missing files, and we can try to separate vendor trees out, if it gets too large.
    [MacArena] Users will typically want to use snapshots anyway, as CVS needs some thought to set up.
    [MacArena] Thus we should have a rather "full" tree for developers and small packages for users
    [bkosse] MacArena: I know what you mean. :)
    [core] and auto-snapshosts generated every night will reflect the CVS trees, but it can be made so that an user downloads what it needs from them, with a web-based interface.
    [Hartmut] MacArena: And we need a make system that can adjust itself to what is actually present.
    [MenTaLguY] chris: probably the best way is to preprocess the patch before passing it to patch proper, stripping out all information related to non-included files ... I think some simple heuristics can determine if a particular chunk is adding a complete file or not
    [Jason_McM] Ie ggi-libggi-1.1.0.i386.rpm, ggi-kgi-1.1.0.i386.rpm, ggi-vendor-Matrix.i386.rpm, etc..
    [MacArena] from which they can choose what they need. In the areas where needs differ much, we can use something like a "make my KGI module server".
    [bri] Since we recently picked up a Debian developer maybe we could involve him in choosing what/how to divide into packages.
    [andrew] hartmut: definitely -- i'm sick of editing ./configure every time I add a new display target
    [bkosse] core: Would you like to send me some specs on how you'd like the web-based thing to work and I'll see what I can do WRT building the interface?
    [fries] while we're talking about packages, we should have a subdir or something to provide for different packaging methods for different os's. lesstif,for example, has RedHat, Debian, Slackware, and FreeBSD.
    [core] macarena: yes, this is all a problem local to the www server once it cvs updated from the repositories
    [Jason_McM] (rpm makes building multiple target RPMS from one source tree rather easy)
    [mars] andrew: That can be automated
    [chris] core: A web based interface will need some sort of CGI scripting behind the scenes. Will all mirrors be able to provide that? If not when GGI becomes popular how much of a load will be put on the only servers than can do the CGI?
    [core] bkosse: if you want to tackle it, we will sure do
    [andrew] mars: yeah ;-)
    [MacArena] hartmut/andrew: Yes. Any volunteer to make such an "autodetect drivers" system ?
    [core] chris: we will try to have at least an US and EU machine
    [fries] andrew: sorry about the configure stuff, it was the best I could come up with at the time
    [MenTaLguY] mmm...
    [MacArena] Shouldn't be too hard. A bit of find, grep, sed, ...
    [core] chris: and bandwidth in the US is much larger than for poor europeans here
    [MenTaLguY] sounds like we should address this autoconf thing now
    [ShadowX] chris: how much space is needed for a mirror? I have CGI scripting on my ISP server and I can mirror if necessary
    [fries] mentalguy: topic is still 'new dir layout' :-)
    [bkosse] chris: you are very right. Hrm, if the mirrors are updated, then the CGI script could also ask for a mirror location.
    [andrew] fries: no worries
    [MenTaLguY] fries: but we're talking about the configure script, and autodetection
    [core] most mirrors can use the CGI present on synergy and on an european mirror
    [erich] chris: i hope to be able to provide a server with php scripting in some weeks/months. No promises, sorry. i just hope to.
    [tan] macarena: AFAIK steffens new scheme is already able to do this
    [core] mat: will you host that EU mirror? my bandwidth/cpu resources on the degas server are already well used by CVS
    [MacArena] O.K. - next topic ?
    [erich] i would also be interested in writing the script - as i'm not too used to C yet and thus not programming in the tree.
    [MenTaLguY] maca: autoconf, or not to autoconf?
    [fries] mentalguy: to not.
    [tan] macarena: you just have to "touch .configure" in the directory and it will be compiled
    [core] erich: ok, make sure to see that with ben kosse then
    [core] ok for me to move on to next topic
    [MenTaLguY] fries: what are the specific problems with using autoconf with gnu and bsd make?
    [Mat] core: I don't think I can, my CVS was hosted on the machine I work on, a poor little P166/32M RAM/IDE disks, and a 64Kbps link. Not big enough I'm afraid.
    [Hartmut] Mentalguy: just implement a solution and we'll discuss then??
    [core] mat: 64 kbps, ouch :)
    [core] mat: i'll ask the french www/ftp mirror at ens, they have 34 mbps
    [Mat] core: or maybe 128, but still not much...
    [MenTaLguY] Hartmut: that's why I'm asking fries about it, now
    [fries] mentalguy: you develop makefiles for gmake with autoconf. bsd guys would have to write a wrapper if they wanted libggi in their tree proper.
    [Mat] core: yeah, but isn't this renater ? Not very fast.
    [MacArena] ment: Hmm - I had quite a lot of strange trouble with autoconf, so I am biased and will keep out of the discussion on that :-)
    [ocre] mat: renater is bloody fast.. the exchangers in paris are slow
    [fries] MacArena: it works well until a new os or issue crops up then a wise individual must modify it.
    [MenTaLguY] fries: what gnu-specific features does autoconf use that are incompatible with bsd make?
    [fries] mentalguy: gmake syntax that isn't in bsd make
    [MacArena] Ok - ready for next topic ?
    [core] ready.
    * fries nods
    [MenTaLguY] ready.
    [ortalo] ready
    [ShadowX] i have specific technical question
    [bkosse] Sure.
    [tan] ready
    [mars] fries: The BSD people would be better off fixing the make instead. A lot of packages use autoconf
    [mars] ready
    [fries] mars: fixing? sorry. they have a quite complete make implementation.
    [core] (we'll debate gnu vs bsd make after the official meeting)
    [fries] mars: there is a complete implementation for the same thing with 2 different methods between bsd make and gmake
    [bri] Re: distribution packaging files andy answered that by qualifying them to go under the same subdirectories other OS build files do, but unfortunately I talked with the new Debian maintainer and his devel machine has not networking to keep his debianization files in CVS.
    [MenTaLguY] fries: and actually, dealing with new issues in automake isn't that bad if you write an aclocal.m4
    [fries] mars: choose 1 over the other and you alienate the 'other' crowd
    [MenTaLguY] fries: but yes, incompatibilty with bsd make is too serious to get around
    [core] we'll debate gnu vs bsd make after the official meeting.
    [fries] if you ever hope the 'other' crowd to have your stuff in their tree.
    [fries] every gnu app has to have a Makefile.bsd-wrapper .. now if you want me to write that, feel free to do autoconf
    [fries] ok I'm done.
    [core] macarena: ready to proceed with next topic
    [MacArena] O.K. - then for the LibGGI changes. I'll start with the new extension scheme
    [Jason_McM] Now commitiing KGI/GGI Console changes...

    New libggi extension scheme (15:56 GMT)
    [MenTaLguY] fries: are you sure it isn't automake responsible for the gnu-specific syntax?
    [ortalo] So what is the objective of this new extension scheme ?
    [MacArena] I have changed the extension scheme as described in my recent mail. Anyone not read it ?
    [bkosse] Quick question, does anyone know how the SVGALib bridge is going? Specifically, can it play Quake?
    [bkosse] :P
    [MenTaLguY] fries: I've been looking at generated files as we speak, and all the gnu-specific syntax in teh resulting makefile seems to be coming from automake
    [ortalo] I think I did not read it completely, could you summarize the objective of the new ext scheme ?
    [core] mentalguy: please, talk about that later or in /msg :)
    * erich wants to play quake, too.
    [tan] it's better now but I still dislike that the extension data is stored in the ggi_visual
    [MenTaLguY] MacArena: yes, I read it ... it looks good, although I havn't thought about it that much since
    [MacArena] O.K. - seems all know what I did. As it allows to extend depending on the target, I'd like to move a few things out of LibGGI to make it even smaller, simpler and look more "generic".
    [MacArena] One thing that gets hit by this is ggi*Raypos ...
    [Hartmut] I second that motion.
    [MenTaLguY] sounds wise.
    [MacArena] I'd like to move that out to a small extension like LibGGICRT that deals with the peculiarities of having a CRT
    [MenTaLguY] or, at least, having direct control of one :)
    [MacArena] The things I see in there are Raypos hacks, Mode tweaking and such.
    [core] i'd second that - brian?
    [MacArena] Do you like the general idea of moving as much as possible out of LibGGI to ease porting ?
    [tan] macarena: I agree
    [MenTaLguY] yes.
    [andrew] macarena: yes
    [mars] I think it is a problem that we are creating so many small libs. Whenever someone wants something new that isn't implemented someone says hey make a new lib. I would say that things should rather be moved into LibGGI than from it
    [core] macarena: yes - this way we can have a base display running, and then, we can port the rest when relevant, already having a work basis
    [ShadowX] yeah, now that make sense -- mode tweaking -- i just don't like the name :)
    [MenTaLguY] the people who want GGI on PDAs will love us for it, too
    [Jason_McM] Also, it looks like we'd only need one vendor .so to support libGGI, libGGI2D, libGGI3D, etc...
    [Jason_McM] All approve, say Aye! (Aye!)
    [Kor^] Aye!
    [bkosse] er, Aye, I think.
    [Hartmut] Aye!
    [mars] What do I say if I am against?
    [Jason_McM] mars: libGGI must remain small. Needed of PDAs and install-disks.
    [Kor^] mars: nothing
    [core] mars: "i have pictures of you with your secretary"
    [ShadowX] mars: why problem with small libs
    [andrew] mars: walk the plank !
    [tan] mars: no, we would get a too bloated libggi
    [MenTaLguY] mars: as long as the small libraries are built and installed relatively automatically, that's not too bad
    [Jason_McM] mars: Good concern.
    [mars] core: Those pictures doesn't really bother me :)
    [core] mars: no, that's what you're supposed to say :)
    [MenTaLguY] ow.
    [Jason_McM] mars: It also make a app writer think twice about using `odd' stuff,
    [ortalo] I would say Aye! iff I can override the existing functions of libggi2d within something like, say libgwt... I guess it is still possible. Is it easier ?
    [Jason_McM] like the mode tweaking..
    [Kor^] have u already discussed the KGI today?
    [core] macarena: no, everyone agrees, and Stefan is concerned about having too many libs around
    [mars] jason: Why should an app writer think twice about something odd???
    [Jason_McM] Yep -it's currently being ocmitted....
    [Mat] Many small libraries are ok as long as precompiled packages bundle them in not too many packages.
    [MenTaLguY] core: well, maybe then, everyone but Stefan agrees :)
    [core] mentalguy: he has a valuable opinion tho :)
    [Jason_McM] mars: So that when he says `hey. i'll just wait for vretrace like on DOS!' we'll realize - wait a second - this libGGICRT only works on KGI, and I want people to use my app under X too... lemme rethink why I want to use that...
    [ortalo] So: we speak about API "extension", what about API "overriding" ? (w/ the new extension scheme ?)
    [Jason_McM] s/we'll/he'll/
    [chris] Jason_McM: Is there a vretrace in an X window?
    [bri] I don't like the "tweaking", and in interest of keeping the number of ancillary libraries low, I think mode tweaking and advanced use of Real-Time features should be lumped into a library of a different name, otherwise Aye!
    [Jason_McM] chris: Nope.
    [mars] maca: I don't know if you saw it, but I am very concerned about moving a lot of stuff into several small extension libs. I actually prefer a few larger that makes sense. In my mind, DirectBuffer stuff should be in LibGGI for example. I think it belon
    [ShadowX] mars: directbuffer is moved out of libggi?
    [MacArena] mars: AFAIK one can easily link multiple libs into a single bigger one, so there shouldn't be much of a problem - or ?
    [Jason_McM] On the specific point of DirectBuffer, I have to agree with Stefan Mars...
    [MacArena] shadowx: No
    [mars] shadowx: Ok, bad example :)
    [weigon] oops, i´m too late
    [ShadowX] you gave me a scare with the DB :)
    [core] what? DirectBuffer _is_ part of libggi, or it was when I checked last :)
    [Kor^] mars: the many smaller libs will be needed on small memory machines, and they can easily be linked in: digitals new PDA toy would benefit grately from GGI, they even mentioned it in their slide show
    [Jason_McM] core: it is - it's just that Stefan was getting kinda paranoid...
    [core] jason: ahh :)
    [MacArena] kor: Have seen it at LE98 ... funny thing :-)
    [mars] shadowx: I can rephrase. They just suggested to move the get ray position functions out of LibGGI (well, they are hardvly there yet). But I think they beling there
    [Jason_McM] KGI commit complete - checking that it's all in there...
    [core] we'll have to link small libs directly in on low-memory systems anyway, if you consider 4K page alignment waste that occurs from splitting them
    [Kor^] macarena: yeah :) i cant wait to mess with one
    [bri] Ahh I missed the name GGICRT, that I like. Just because It's named that doesn't mean non-KGI targets can't be allowed to implement backends as long as the extension mechanism allows it technically
    [MacArena] mars: The point is that only few targets support it. SVGAlib, KGI and SUIDKGI. All windowed ones don't ...
    [ShadowX] mars: i understand. just that the directbuffer stuff to stay.
    [core] bri: right.. and you'll have a whole extension to yourself to work on :)
    [MenTaLguY] mars: they assume very specific properties of certain specialized display targets -- those that have direct control over a CRT -- for other targets, not only can they not be implemented on other targets, they're meaningless for those targets as well
    [core] macarena: and on top of that, we might even have targets that don't have a crt as display medium - printers..
    [MenTaLguY] mars: to my mind, that suggests that they go somewhere else than LibGGI, which is supposed to be the base _common_ functionality
    [Jason_McM] KGI Commit Complete - now patching pathname problems. libGGI should work - although I copuldn't test the `compilability' of the AAlib or Virge targets...
    [MenTaLguY] core: terminfo :)
    [bri] core :) goody
    [mars] mental: Ok, let's move all color-related stuff out of LibGGI into LibGGIcolor. After all there are systems with monochrmatic displays, and they don't have to bother
    [fries] jason: is that devel or stable?
    [core] mentalguy: heh, i thought of that, but technically it's still a crt display.. i meant, a display with different properties even :)
    [MacArena] core: X doesn't make much sense either except maybe for vretrace ...
    [ortalo] Where did you commit KGI ? (devel or stable ?)
    [fries] mars: um, that is a bpp issue which is handled by different display targets
    [Jason_McM] mars: Now you're just being facetious..(sic) ;^)
    [ShadowX] mars: almost all targets support color
    [Jason_McM] KGI was committed to devel
    [core] ortalo: devel - but please wait for the end of the meeting :)
    [MenTaLguY] mars: color is still relatively meaningful for monochrome displays; although they cannot represent it except as shades of some color
    [ortalo] okay, no problem, I wait.
    [mars] Fine, I am outvoted anyway so let's just continue
    [MacArena] mars: the libGGICRT was just a "wild guess" we can make a single bigger "libGGImisc" one, if you prefer ...
    [bri] Andy: yeah we could at last have an Xrouach program that didn't flicker :)
    [MenTaLguY] mars: ray position is not only meaningless for non-direct-CRT targets, it's quite simply undefined
    [bri] ^Xrouach Xroach
    [ortalo] Andreas: finally, I support the idea of having libggi rather small, and taking the risk of small libs.
    [core] mars: please, no sulking :) i agree with the splitting problem.. but it eases libggi porting and adapting ..
    [ortalo] I say so because I think that _development_ of libraries will be easier.
    [ShadowX] i have different question now, that the DB issue has been raised: how to support targets that have no DirectBuffer?
    [bri] But let's not go overboard dividing up the libraries beyond that
    * MenTaLguY nods
    [core] mars: stuff should be more "together" in KGI, than libggi.. and this is just a load-time problem - once loaded, it makes no runtime difference ?
    [ortalo] (Yes: porting also.)
    [Kor^] core: about the splitting, many of the newer small memmory devices use StrongARMs, those have variable page sizes (although i dun know the minumum size :()
    [MacArena] As someone asked about API override: This is possible using the new extension thing, as it will load the extensions in order. It requires that you know about the internals of the API you override, but it is technically possible.
    [MenTaLguY] yes, the dividing thing could go too far
    [mars] mental: Not if it is only black and white (or more common only a green ray on a black background)
    [core] kor^: default page size is 32K, that's where Stefan's remark is very valid
    [bri] Try to lump them together a little
    [MenTaLguY] mars: then it can be faked very poorly with thresholding :)
    [Kor^] core: yes, that would be a problem
    [MenTaLguY] mars: but there's no way to fake raypos on non-direct-CRT displays -- what meaning or definition could it possibly have on them, anyway?
    [core] kor^: but stuff can always be linked in directly then
    [ortalo] Thank you to let me override... (I will override anything I can within libgwt, until I hit hard points such as the ray position issue which surely is bizarre in a windowing context.)
    [core] kor^: just like linus "suggests" not using modules on strongARM because of 32K page waste
    [Kor^] core: yeah, that might be a good idea (i am just very attached to runtime linking)
    [mars] mental: No, but the point is that we can drive this way to far. We can make a library for each function we have, so that only those an app need gets loaded. But that wouldn't be a good solution after all
    [ortalo] BTW: Is Jonas Anderson here (Sorry, Private remark ?)
    [core] kor^: i am too.. but the way shared libraries are handled in ELF is not the best solution ever found by man :P
    [Jason_McM] core: That brings up an interesting question - should it be possible
    [bri] mantalguy: consider VNC, you could use knowlege of when frames are sent over the network. The implementation would obviously be far from complete.
    [MenTaLguY] mars: well, certainly. my only contention is that hw-specific (and really, target-specific) stuff doesn't belong in libggi proper
    [Jason_McM] (on architectures like Linux a.out) to build a static libGGI with all
    [Kor^] core: yeah, guess I can deal with static linking on the SAs until something better then elf comes around
    [core] jason_mcm: yes, it has to be - some targets will not support dl loading
    [ortalo] mars: no, this is a dynamic library, but we might make a lib for each hardware we have, and it might be (a litlle) more reasonable.
    [Jason_McM] the extensions loaded and one (or more) targets `build in'
    [fries] jason_mcm: that is an interesting question, is it possible to build an all static libggi.a?
    [core] jason_mcm: DOS, for one, i don't think djgpp does.
    [fries] core: prime example, OpenBSD/alpha
    [core] fries: it will have to be possible
    [Jason_McM] It should be with Andrea's new extension scheme.
    [tan] jason: it is possible with my library loader
    [ortalo] Andreas: apart from the shrinking of libggi, do you have other reasons to favour the "small libs" approach ?
    [fries] core. hehe. the way things are done though, I will be interested to see how
    [MenTaLguY] Jason: we'll HAVE to allow for static linking if we want a DOS LibGGI
    [MenTaLguY] Jason: which I believe someone put on the agenda recently
    [Kor^] ortalo: quicker porting
    [core] fries: there's a naming space problem, but i know how to resolve it i think
    [MacArena] ortalo: I wasn't talking of "small libs". Just of _one_ small lib. LibGGI. The smaller it is, the easier it is to port and the more developers will like it.
    [tan] mental: yes. that was me
    [core] mentalguy: Andreas did
    [fries] core: coolies
    [core] fries: i'm sure we'll have surprises, but nothing a chainsaw can't fix :)
    [MenTaLguY] Although I daresay a dynamic loader for DJGGP (for DOS) might not be a bad idea, if DOS survives long enough to make developing that practical
    [tan] the generic library loader works. i've send it to andy
    [ortalo] In this sense, Andy, I fully agree with you: let make libggi small, and we'll debate again for the others.
    * bkosse2 has to agree with MacArena on that one.
    [MenTaLguY] ahh
    [MenTaLguY] I'm with ortalo.
    [bkosse2] Mentalguy: DOS is still one of the most frequently used realtime and embedded systems platform.
    [ortalo] MenTalBiduleTruc: you can call me Rodolphe. ;-)
    [MenTaLguY] bkosse2: good point
    [core] well, DOS can be hard-rebooted, linux and windoze have a problem with it.
    [MacArena] core: FAT ain't too happy about that ...
    [bkosse] Hehe, core, turn on smartdrv w/write-back caching and hard boot it.
    [core] macarena: not if you don't use write cache, which is fine for embedded crap :-)
    [ortalo] Can't you forget about DOS and Win and M$, just to focuss the discussion currently ?
    [core] bkosse: that's what i mean
    [MenTaLguY] at least windoze finally took a clue from *nix and now does disk check if it isn't cleanly rebooted, instead of working with a potentially corrupted disk and screwing it over worse
    [bkosse] It's not a problem when you can write the buffers on *ANY* system. :)
    [fries] ortalo: that topic will come up however
    [wlfshmn] FAT doesn't care about hard-rebooting as long as it doesn't occur while writing. Nothing likes hard reboots while writing to a permanent storage device.
    [MacArena] core: Still tends to bring a bunch of lost clusters ...
    [ortalo] fries: Yes, but we are not ready for this topic yet.
    [core] ortalo: it was just about porting libggi to non-dl systems.
    [MacArena] O.k. - let's stop glorifying DOS ... back to schedule ...
    [ortalo] core: doesn't this mean only DOS in fact ?
    [weigon] will dos-ggi be based on real or protected mode ??
    [MenTaLguY] ortalo: or StrongARM, possibly, as mentioned before
    [MenTaLguY] weigon: protected mode, I would imagine
    [core] ortalo: dos, openbsd/alpha, linux/strongarm ...
    [fries] ortalo: OpenBSD/alpha is not dynamic libs yet .. I'm sure other os's and arch's are in the same boat
    [weigon] i just mention this for the embedded 286 systems
    [MenTaLguY] weigon: DJGPP is the only DOS compiler that's reasonably sane and also free
    [Jason_McM] I vote for DJGPP - that way we don't have to write video drivers. ;^)
    [wlfshmn] weigon: Protected, or memory access would slow down to a crawl.
    [MacArena] I think porting to non-dl systems shouldn't be too hard after all. We have done it for SANE, and I have written DL loaders for DOS a while ago (not for GGI, but ...) - so I don't see a big problem.
    [6:22) [mars] core: Doesn't linux/strongarm support dl??
    [6:22) [MacArena] weigon: protected mode. DJGPP or something.
    [ortalo] Okay, okay... But why not make it run under Linux first ? ;-))))
    [Kor^] core: could we not just change the oage size?
    [Kor^] s/oage/page
    [MenTaLguY] weigon: mmm... there does seem to be a 16-bit DJGPP compiler, too
    [core] kor^: that's an hardware thing.
    [core] ortalo: we are redesigning libggi a bit, therefore trying to think a bit for the future
    [MenTaLguY] weigon: http://www.delorie.com/djgpp/16bit/
    [core] ortalo: libggi does run just fine on linux already
    [mars] ortalo; Design question. The more problems we can sort out now, the better it will be. Otherwise we have the risc of having to do it _all_ again
    * MenTaLguY nods
    [Kor^] core: I thought the SA has variable page size as in an asm instruction (but i shouldnt get much into this, because there are static system in need of GGI nonetheless)
    * fries nods enthusiastically at mars.
    [ortalo] To summarize: do we agree to try to make libggi smaller and move things in some ext libs (BTW: this will enable potential porters to try the port.)
    [Yazz] yupp!
    [tan] yes
    [MenTaLguY] yes.
    [Kor^] Aye! for the smaller/ext libs
    * bri pokes self in eyeball (appropriate IRC newbie first time gesture)
    [bkosse] fries: so, a configurable 'make STATICLIB=true' type thing.
    [ortalo] Nice agreement, BTW it seems Andy already did it this way... :-)
    [mars] core: I don't think SA is a problem. Some others might be though
    [MacArena] O.K. - now for more of the open LibGGI issues - o.k. ?
    [fries] bkosse: that would be a possible makefile implementation. but first the developers who know what to do must make the code do it :-)
    [andrew] maca: ok
    [ShadowX] macarena: ok -- I still have that DB issue, shall I ask?
    [MacArena] First thing : More complex mode negotiation.
    [ortalo] PRIVATE: Now that I have all of you here, did someone ever hear of Jonas Anderson wrt/ libgwt ?
    [bkosse] fries: I'm just making sure we agree that it's not the default. :)
    [MacArena] The new extension scheme allows to connect into the communications channel established by the LibGGI display-* module.
    [weigon] what about the kgi-changes ??
    [ortalo] PRIVATE: (Or should I keep on using what I have already ?)
    [fries] bkosse: heh. that's kinda rhetorical at this point. of course :-)
    [Mat] MacArena: could you explain a bit what that means ? (sorry, I'm not a graphics experts...)
    [MacArena] Mat: Yes ... just a second ...
    [bri] The current system is very primitive. That state of the industry isn't much better
    [bri] After all how many emails have you seen about displays being shifted to the left and stuff
    [MacArena] This means, that we can link into the communication LibGGI->X or LibGGI->KGI and thus even change very basic things like mode negotiation.
    [ShadowX] hmmm.. this gets me thinking ... would it be possible to have 'plug-in' mode negotiation 'drivers' with different characteristics
    [ShadowX] e.g. one negotiates up, down, etc.
    [chris] If I go to a KGI target my display will be shifted, it is okay now in SVGA and X.
    [Kor^] I was wondering if their will be an extension lib similar to rasters lib. A virtual 24 bit color mode, where all dithering, and color conversion is handled by the extension (that will make programming MUCH easier just color = ColorFromRGB(r,g,b)?
    [MacArena] This enables us to schedule the complex mode negotiation for later and make mode negotiation schems that fit the current application (3D, video, ...)
    [bri] A thorough system would be way too complex for some people especially companies writing binary-only drivers; so we should have 2 or 3 suggested systems of different levels of complexity and vendors should be able to write their own system as long as they provide a monitor driver themselves that's compatible with it.
    [Kor^] :/ doht, i might have seen something like that already in GGI, eh...
    [andrew] kor: :)
    [MenTaLguY] that would be the trueemu target
    [Kor^] thankyou :/ just forget i said that
    [bri] Lowest level of complexity would be just to choose VESA/VGA timelists by their BIOS number, above that is the system we have now with a few tweaks and then above that the do-it-all approach.
    [MenTaLguY] the magic of a large free software project: if you can think of it, someone's already started it
    [MacArena] bri: I think we are talking about two different things. I am talking about ggiSetMode*, while you are into monitor timings.
    [MacArena] bri: Let's schedule your point a bit. I have thought about it (connected to LibGGICRT).
    [bri] Yes, OK sort talk on CRT but I yeild to framebuffer negotiation as being more important
    [bri] ^sort^short
    [tan] mental: I think about everything. Who has started it? ;-)
    [MenTaLguY] heh.
    [MenTaLguY] http://www.everything-project.org
    [MenTaLguY] j/k
    [Kor^] tan: String Theory, theory of everything
    * wlfshmn moves a stack of 18 WC C3x boards to get to the keyboard.
    [ortalo] What is the next topic ? (Don't you think this one is over ? ;-)
    [tan] t-offline! ;)
    [MenTaLguY] indeed.
    [MacArena] ortalo: looks this way ... Now for the various libggi-issues Hartmut had collected.
    [bkosse] Sounds good to me.
    [MacArena] Could someone go through them please ? I don't have them around, because I'm under M$ and don't dare to open a webbrowser ...
    [bri] OK

    libggi issues (16:39 GMT)
    [MacArena] Core ? Could you bring them up one-by-one ?
    [bkosse] hehehe....
    [ortalo] What about a "Linus's attitude" report in the meantime ?
    [ShadowX] i don't know if this is a issue hartmut collected: but I want to ask about how to handle no-DB targets
    [andrew] shadowx: what in particular ?
    [ShadowX] it was debated on the list a long time ago but there wan't any clear conclusion
    [ortalo] (Maybe we can affort editing the minutes of this discussion...:-)
    [core] i would have ditched it but that was a really desperate call
    [core] :)
    [fries] ortalo: last I heard he was warning that if stuff gets in the kernel it must be supported.
    [ShadowX] some targets have no DB, but some applications insist on DB...
    [andrew] shadowx: those that insist are just broken
    [bkosse] fries: This is getting better.
    [Jason_McM] Well, apps that insist on DB should use display-memory and blit it to the
    [ShadowX] some targets try to emulate a DB which results in poor performance (trueemu)
    [ortalo] Woaw... So, he waits for us to prove ourselves...
    [Jason_McM] don-db display.
    [ShadowX] andrew: what about Xggi

    libggi: #1 - Multiple Buffering
    [core] okay, problem one then:
    [core] "
    [core] Currently SetMode specifies one frame buffer.
    [core] For double-and triple-buffering we need several buffers,
    [core] which is currently implemented with larger virtual.y and
    [core] setOrigin. This is (a) VGA-centric (not everybody supports
    [core] setOrigin) and (b) even where it works not necessarily optimal.
    [core] "
    [ortalo] I have a topic also: what are the main issues to porting new drivers to degas ?
    [ShadowX] jason: that's not all. some non-db targets can emulate a DB which is still better than if application just blits from mem-visual
    [andrew] shadowx: yeah, I know that's a hard one
    [core] ortalo: this is planned for discussion :)
    [ortalo] s/new/old in fact
    [core] okay, problem #1 - double/triple/multiple buffering.
    [MacArena] O.K. - I think we should add that "frames" argument to the SetMode calls and make SetDisplayedFrame and SetDrawingFrame.
    [ortalo] I'd say: request N buffers at SetMode, then provide a "switch buffer function" and "show buffer". Is it enough ?
    [andrew] maca: agreed
    [MacArena] This is only a slight change and it will abstract the doublebuffering mechanism.
    [Yazz] agreed
    [core] that'll do well. agreed
    [tan] I've a idea concerning DB: how about introducing ggi[Un]Lockrect, you call lockrect before drawing and after drawing unlock, which updates only the region you've drawed on. this would make the x-target a lot faster...
    [ortalo] s/buffer/frame
    [Jason_McM] agrered
    * bkosse knows I will Sounds good.
    [bri] yes this is a nice simple API
    [ShadowX] andrew: reason I'm asking this is, I plan to redo the VNC target to make more efficient. But will need to stop providing the DirectBuffer. I think GGI should try to provide functionality as much as it can , so...
    [bkosse] ....
    [bkosse] Ahem. It sounds good
    [core] tan: that's a valid point indeed
    [bkosse] (never flip VC's when you have a partial line written... the brain is incompatible with that....)
    [Yazz] It will break source compatibility if we change setmode though.
    [ortalo] yazz: good point.
    [MacArena] Yazz yes ... this is why I hesitate ...
    [ShadowX] tan: so why would that be 'direct' buffer? the app might just as well putbox .
    [Jason_McM] Not setmode - setGrpahmode would break compat....
    [andrew] the "frames" field is already in ggi_mode, yeah ?
    [core] we can introduce a new ggiSetExtMode or so ?
    [Yazz] But i like it anyway, then we have to change all the demos to show people how it should be done.
    [chris] MacArena: But this is only 0.1.0 isn't this the time to break things?
    [Mat] I think we can break source compatibility at this stage.
    [MacArena] andrew: yes. But should we add a set of new calls just for one additional param ?
    [core] whereas internally, ggiSetMode will call ggiExtMode with a frames argument of 1
    [Jason_McM] No - not the `ext' stuff - just use the ggiSetMode() call
    [ShadowX] core: not a good idea : see the mess with m$ windows *Ex calls
    [core] ShadowX: i know, but there are a LOT of libggi applications ..
    [core] okay, then can't we make use of C variable parameter passing?
    [Jason_McM] Why not put that in libGGI 2.0 ? Major rev...
    [Yazz] It is stupid to leave old vga'isms in the API.
    [knghtbrd] core - is there a graphics viewer comparable to zgv yet? =>
    [bkosse] Yazz, but is this not a *GOOD* thing that VGA is doing?
    [wlfshmn] Can't a function name be overloaded?
    [core] knghtbrd: ggv is improving.. and one could port zgv to GGI
    [knghtbrd] core - one could, if that one weren't me =>
    [fries] knghtbrd: hrm, xggi works, therefore xv, gimp, etc? :-)
    [Jason_McM] I once got zgv to work under the svgalib -] ggi bridge...
    [MacArena] Jason's point ain't bad ... we could make a LibGGI.1.so that will convert to LibGGI.2.so - couldn't we ?
    [core] knghtbrd: you just designated yourself ;)
    [Jason_McM] Yep - it's not a problem, esp. considering that all libGGI 1.0 is is
    [bri] I'm for changing ggiSetMode over adding a call for just one param -- but we aren't talking about doing that are we (mode has frames member) just adding the SetDraw/Displayed frame functions so you don't have to calculate the frame pointer in a vga-centric fashion in the app.
    [knghtbrd] fries - I don't have resources for X routinely---and if I did I can't READ X..
    [core] jason: hmm, why not
    [Yazz] bkosse: No, having to use larger virtual screen to have multiple frames is stupid (on other architectures/cards than vga)
    [fries] knghtbrd: heh.
    [Jason_McM] shims, we could have the default display for libGGI 1.0 be set to `display-libGGI2.0' when 2.0 comes out...
    [Yazz] bri: Mode has frames parameter, but not setmode call.
    [knghtbrd] core - ummm, I better UNdesignate myself.. Patching term.c so epic3 compiled under glibc (1 line) was a MAJOR victory for me.. (was 1 line I had to add)
    [core] knghtbrd: heheh
    [core] knghtbrd: i was just kidding.
    [bkosse] BRB, my face sprouted a faucet between my eyes and my mouth. (I HATE ALLERGIES!)
    [knghtbrd] core - no you weren't. =] Standard programming practices: you want it? you write it. =p
    [bri] yazz: doh. Now I remember.
    [core] knghtbrd: you aren't supposed to figure me out so quickly ;)
    [ShadowX] should we just drop the "convenience" functions ggiSetMode() etc.
    [ShadowX] and no body treats the struct as transparent anymore
    [ShadowX] s/transparent/opaque :)
    [core] well, why don't we set the number of frames needed in mode->frames and use setMode, anyway ?
    [Yazz] ShadowX: Nah, everyone will just write such a function themselves then.
    [andrew] shadowx: it is SetMode that passes the struct, and SetGraphMode and SetTextMode that are the convience functions, and yeah dropping them would be fine by me.
    [Jason_McM] I'm ok with ggi_mode being transparent in libGGI 2.0 IF AND ONLY IF it has a `version' at the top of it... (ie mode.version=GGI_VERSION) so that we can easily be backwards-compatible in the future.
    [MacArena] core: Not a bad point. Could we agree on that ?
    [Yazz] MacArena: It's ok for me...
    [ortalo] I do agree.
    [core] i agree on my own proposition :-)
    [bkosse] Hehehe.
    [andrew] maca: yup
    [bkosse] OK, I have a question about how something would work.
    [bkosse] (it's even related to this discussion :)
    [Mat] Can't we add a parameter to setMode which would be 1 by default, or is it already a function which has a variable number of arguments ?
    [bri] macarena: agreed.
    [MacArena] O.k. - so for that point we will do: Use SetMode to set up multi-buffered modes, and introduce two new calls to use the multiple frames - right ?
    [Mat] I mean, it would be 1 if not specified
    [ShadowX] i'm sorry, what is the conclusion?
    [andrew] mat: neither in C (C++ has such things I think)
    [core] mat: setmode takes a ggi_mode structure with a frames count anyway
    [Kor^] macarena: yeah
    [MacArena] Mat: This is a compile-time C++ feature ...
    [core] macarena: Get and SetDisplayFrame, as you suggested, yes
    [MacArena] Mat: It doesn't work, once things are compiled ...
    [bri] wow -- I think that soultion weaseled us out of a corner.... cool!
    [Mat] MacArena: but it could be interpreted at compile-time. I mean, isn't if what printf does for instance ?
    [MacArena] Mat: Short course on how C works :
    [bkosse] I have a 640x480x8bit frame (OK, I have 3 of them). I need to copy between them. This is possible on VGA, but will it be possible on generic libggi[2d]?
    [chris] How slow would the multiple frames be if they all weren't in the video RAM?

    libggi: #1.B- Optimizing targets emulating DirectBuffer
    [core] okay, now that we agreed on setMode - could we spend a second on what Thomas brought up? namely, having ggiFlush() precise the region to update of sorts (for the X and VNC target, mainly)
    [ortalo] Could we start to think to the next topic also now (Core, could give us an idea of it) ?
    [MacArena] Mat: variable numbers of arguments need to be determined by some other means. The number of %-sequences in the case of Printf, the trailing NULL for ggiOpen, etc.
    [core] chris: much faster to draw via CPU and much slower to transfer
    [knghtbrd] core - I've done programming, just not in C.. Gimmie 6 hours, a 21 day book, and a day after that to play with specifics related to gcc... I'll start patching the kernel or something.. =>
    [andrew] core: could'nt setting the clip region do this ?
    [ShadowX] core: VNC target: server does not control the flushes. All updates and (x,y) are request by client
    [core] knghtbrd: i'll have my anti-antomic thing by then :)
    [Jason_McM] I like the lock/unlock concept - but it MUST be enforced. (Ie ste clipping to the locked region, and if nothing is locked, clip out everything)
    [core] shadowX: oh
    * Mat is disappointed with C... :)
    [knghtbrd] problem: who has a day and a half to devote to just learning c?
    [core] jason: again, we have to preserve compatibility
    [Jason_McM] Not for 2.0 we don't ;^)
    [bri] bkosse: monkeywrench. damn. Well maybe we should offer a "read" and a "write" Drawing frame, but then you shouldn't using DB :-)
    [core] jason: we aren't designing 2.0 today
    [MacArena] Mat: The "default" option for C++ works at compile-time by just substituting missing parameters.
    [core] jason: not yet :)
    [bkosse] bri: tile-based game. :)
    [MenTaLguY] kngthbrd: most of us found it -- we just had to spread it out over the course of a few weeks :)
    [tan] it might also be useful when several apis access the directbuffer at the same time
    [Jason_McM] Ok... We'll then I say call ggiFlush(). And get busy on the 2.0 feature list ;^)
    [Kor^] Jason: wouldnt it be setFlushRegion, not lock/unlock? and wasnt there supposed to be a smaller flush, like update/refresh()?
    [bkosse] bri: lots a layers. Much faster this way than redrawing the entire screen every time (especially since the VGA cards have the latch registers).
    [core] could we have some kind of clipping list which is initialized to the full display, and reinitialized to that after a ggiFlush() .. ? and modified by a new call ?
    [core] this way, old applications will still update the full framebuffer, while applications aware of the new call can restrict changes..?
    [Jason_McM] core: Oooh... Nice idea... And the function wrappers in libGGI can handle that easy, without having to re-write all the targets...
    [Kor^] core: yeah, new function to set flush region, if no region is set just flush everything
    [ortalo] It seems you are trying to steal ideas from libgwt...
    * MenTaLguY grins
    [core] ortalo: we would never do that :)
    [ShadowX] hey that's what free sw is about :)
    [core] ortalo: seriously - this isn't for window management - just reducing X overhead
    [MacArena] O.K. - looks like we found some solution for that, too.
    [ortalo] The problem is: libgwt is software only so this is handled in software.
    [core] ortalo: libgwt could make use of that new region-reduction management?
    [ortalo] However, if you want to flush/manage hardware display lists, it will be more difficult, no ?
    [MacArena] core: press "next" :-)
    [core] macarena: shush ;)
    [tan] btw: could we move ggiSetSplitline out to libGGICRT, too?
    [core] ortalo: again that's merely for reducing application overhead.. it would be the same if it updates the full screen
    [ortalo] In fact, the point is that: true region management issues really arise with "overlapping" "buffer/windows".
    [core] tan: yes, this is correct by our current state of mind :)
    [ShadowX] tan: yeah that seems VGA centric -- I just think "GGICRT" is not a good name
    [core] ortalo: no, we aren't to handle that - just reducing what is updated by ggiFlush
    [Jason_McM] tan: I agrre.... (and I wish I could set my window manager to `focus follows eyes')
    [MacArena] tan: Hmm - not sure ... E.g. X can do it ... but it might be a good idea. It is quite VGA-centric ...
    [core] macarena: well, not VGA centric - amiga, atari etc can do it
    [Mat] Jason_McM: use VTs, it does the trick :)
    [core] macarena: it's more CRT-centric
    [bri] libGGWhw (HardWare)
    [bri] ??
    [mtorni] vga modes are phasing out, don't you think?
    [MacArena] JM: Get a cheap eye-tracking system and write a small EvStack for it :-)
    [core] okay, let's try that, and hopefully Rodolphe can help out :)

    libggi: #2- ggiInit() nested calls
    [core] problem #2 is...
    [MacArena] bri: rather LibGGImisc. Can take lots of "not so common" things ...
    [core] ggiInit() nested calls.
    [andrew] maca: like ggiSetGammaMap :-)
    [ShadowX] this is decided already, no?
    [core] "
    [core] - Will the first ggiExit terminate the library, or need they
    [core] be nested *properly*,
    [core] - will a secong ggiInit() be allowed?, will it have an effect?
    [core] - If we nest them, should we give ggiExit a return value, and
    [core]   you can do (in an emergency exit routine)
    [core] "
    [ortalo] core: one list can do that easily on a single buffer, if you have several buffers possibly active, it might be different. In fact, what you need is to make the assumption that one buffer only will be writable at one moment.
    [Mat] I thought this was resolved in yours and Andreas' mails.
    [tan] core: but e.g. printers can't do it. we could move to a special libGANI - animation interface. How about that? Together with ggiSetFrame ...?
    [ortalo] core: forget about that. I'm off-topic now.
    [core] ortalo: this is just barely to set nonoverlapping rectangular regions to be updated when ggiFlush() is called
    [MacArena] Yes. I might change returncodes, so you can detect it was the last "Exit" that actually cleaned things up.
    [MacArena] Next topic.
    [core] ortalo: okay, we'll talk about it some more later :)
    [bri] I meant, libGGIhw, meaning hardware related "features" or emulation thereof, with a "feature" being a less used thing. I think libGGImisc is a bit generic... decide later.
    [mtorni] we shouldn't have any vga-isms anywhere...
    [MenTaLguY] not in libggi proper, anyway
    [knghtbrd] MenTaLguY - [MacArena] mtorni: We should. People want to use them. However they shouldn't be surprised, if it doesn't work.
    [core] macarena: current applications don't check return code of ggiExit() anyway, so this is not a problem
    [tan] bri: I think we should separete the different types of hardware, i.e make a libGGICRT, libGGIprinter...
    [mtorni] even games (which used low resolutions before) are now using high resolutions as a consequence of increased cpu power..
    [ShadowX] core: but should they? It seems like checking the value of printf :)
    [ortalo] Next topic ? (suggestion: issues in porting drivers to degas)
    [Jason_McM] Ok - I'm on that one...
    [core] umm, i have quite a bunch of libggi issues under the hood still.. :)
    [MacArena] Core: next from Hartmuts list, please
    [mtorni] MacArena: when ggi 1.0.0 ships out, vgas are history :)
    [core] yup

    libggi: #3- switch-away/switch-back behavior
    [core] "
    [core] " What has to be done when a program is switched away (either the window
    [core] " (in X) becomes inactive, or the VT is switched), and on re-activation?
    [core] "
    [core] aka, switch-away/switch-back behavior.
    [bri] Hartmut brought up a very well put point.
    [MacArena] I will add a callback mechanism (Extensions already have it) that handles this.
    [bkosse] Well, the program either must A) be told or B) tell the library what should happen on switch-away.
    [Jason_McM] On switch-away (loss of input focus) a libGGI app gets SIGTSTP.
    [core] his proposal was :
    [core] "
    [core] - when a program is deactivated, *EVERYTHING* ( i mean: at least
    [core]
    [core]   z-Buffers, if any. everything) is saved _by_the_libggi_.
    [core] - when the program is activated again, everything is resored.
    [core] - All drawing requests are blocked while not active, so if the
    [core]   program does calculations, fine, if it draws: stop.
    [core] "
    [mtorni] leave program running - just issue an event/call-back..
    [Jason_McM] On regain of focus, libGGI app gets SIGCONT
    [MenTaLguY] hmm
    [Jason_McM] if the app has to redraw, gets SIGWINCH
    [bri] If it's CPU intensive enough to not be able to redraw, using a userspace buffer won't hurt it.
    [ortalo] There is a difference between a full-screen app being switch away, and a window becoming inactive (but that may still need to be redrawn).
    [Jason_McM] I agree with
    [MacArena] JM: For KGI, yes. We should abstract it in LibGGI however.
    [bkosse] Something (either LibGGI or the program) should be able to create a buffer and let the program write to it.
    [chris] On this one. What happens if you are using an X Window target and the window looses/gets focus?
    [ortalo] I'd say, nothing.
    [Jason_McM] it will stop getting input events.
    [mtorni] how about a stack of events ?-)
    [bri] So I'd say the only guaranteed behavior should be the SIGSTOP, but that all that stuff about switching to memory visibles should be in the API, but not guaranteed to be implemented, a la Directbuffer. It will end up being the same apps that need both anyway (ports)
    [Yazz] Ok, gotta go. Be back later.
    [weigon] i think the drawroutine shouldn#T just stop (block), it should return with a diffetr returncode
    [Mat] What about iconification ? Would that be a SIGWINCH or SIGSTOP ?
    [ortalo] SIGSTOP on iconification, if we want to be homogeneous with VC-switch away (but, then, no animated icons).
    [MenTaLguY] you mean, SIGTSTP on iconification ...
    [mtorni] Mat: SIGWINCH on iconification : program keeps running a bit smaller, cool :)
    [Kor^] if the draw routine were to block then a GGI based program like (net-mon) would stop loggin what it should be logging?
    [bkosse] ortalo: doesn't the WM handle the animated icons?
    [Kor^] s/what/when
    [bkosse] Kor^: thus my suggestion that something be allowed to set up a mem-visual.
    [weigon] that´s why i said non blocking draw-routine
    [bkosse] The program could continue to draw to that (transparently).
    [Jason_McM] Hmm.. iconficiation is a good question. How about: SIGSTOP - stop drawing SIGTSTOP - no more input events - SIGCONT - you can draw AND/OR get input events - SIGWINCH - you must refresh your screen.
    [bri] bkosse: would be nice if apps _could_ roll their own
    [Kor^] bkosse: that would work, a mem visual
    [MenTaLguY] SIGSTOP will stop _everything_ though, not just drawing, and the app can't really do much about it
    * bkosse doesn't have to worry with my current project, but 3d renderers and similar would *NEED* to do that.
    [ortalo] Why not: send an event to the app when its output become invisible to the user. (An event like: drawing impossible).
    [bud] quit
    [bud] exit
    [Kor^] yeah, just let it know it isnt visible, then it can decide how to respond
    [Jason_McM] What if the app is in the MIDDLE of scribbling to a directBUffer?
    [bkosse] Jason: hang on a sec. This will be a touch large.
    [Kor^] oh :/
    [bri] jason: app should be prepared to catch a segv, I guess -- does that work on all OSes?
    [chris] I think the iconify and the switch away should do the same thing. So a program doesn't have to know about so many different things that can happen to it.
    [ortalo] Once this event is delivered, output should have been flushed, and every drawing after that is lost until the "drawing visible" event.
    [mtorni] make libggi multithreaded; one thread handles the events, others do drawing and stuff (a la beos)
    [andrew] bri: that would be really hairy (and not worth it IMHO)
    [bkosse] OK, an app is drawing to a DB. When the context is switched, the library can then redirect everything to an off-screen direct buffer.
    [Jason_McM] mtorni: That was the oroginal intent - multithreading has been turned off due to problems with the X tagret, but we _really_ should get it to work again. All the support should be there...
    [MacArena] bkosse: Note that switchaways can happen in the middle of a drawing operation ...
    * bri curses at beeper, hope this isn't another wrong numbet cause he hates being paged
    [bkosse] Mac: this isn't a problem, if the switch handling happens at a lower level than the drawing apps.
    [ShadowX] side topic: multithreading: we should have wrappers for mutexes,etc.
    [mtorni] Jason_McM: X is a stone-aged slow big (etc) construct anyway, if someone has useless non-threadable X libs, who cares?-)
    [MacArena] bkosse: Now say a drawing primitive is using DB. At switchaway the address of the DB might change (on Linux we can work around, but ...) ... now things get hairy ...
    [fries] mtorni: some os's dont have the luxury of threadsafe xlibs
    [Jason_McM] Everyone who is still using libC 5....
    [bkosse] Mac: if the db library is told about this, then it can transparently update pointers.
    [mtorni] fries: that's exactly what I'm talking about.
    [tan] mtorni: yes. multithreading is very important. otherwise ggi wont be noticeable faster on smp-systems. I'm planning to make libggi2d multithreaded.
    [bkosse] Mac: a touch dicy maybe, but it should work.
    [MacArena] bkosse: The access can be in progress on a _CPU_ level. Plus making the basepointer "volatile" would hurt performance badly ...
    [fries] tan: yes, it can take advantages of speed with multi-threading, but not require it. I think. is it possible to do both and speedup w/out threads? that is how libggi has always been to my knowledge
    * mtorni reminds that it will be a while until ggi-1.0.0, so multithreading shouldn't be a problem anymore..
    [Jason_McM] Well, libGGI will only be threaded _per_open_visual_ - ie, each visual can only have two threads on it - one to suck events, and one to draw pixels.
    * knghtbrd yawns
    [bkosse] Mac: some things just might have to be atomic, too.
    [knghtbrd] good night everybody, it's 10am locally, waaaay past my bedtime..
    [bkosse] Mac: there is probably no way we can avoid that until video cards support rollback and such.
    [bkosse] Gnight, knghtbrd.
    [mtorni] solution: at switchaway give app ~3s time to respond to event, if it doesn't then stop it.
    * bri scribbles number on list of people who page him looking for someone else, so he can later call them all six times at 5am in the morning.
    [ortalo] Why not let the app. specify at init time what it wants ?
    [ortalo] Either: its framebuffer being saved in memory at switch-away (then, it could be used cleanly)
    [MacArena] O.K. - I think we should move on. For the protocol : No decision reached. Needs discussion ..
    [core] allright
    [ortalo] Or: the fb is discarded (and the app. is responsible for redrawing it fully).
    [bkosse] Sounds good.
    [ortalo] (I also agree to proceed)
    [core] next hot topic.. /me covers ..

    libggi: #4- alpha values management
    [core] "
    [core] There was the suggestion to enhance ggi_color, which currently holds
    [core] three shorts for r,g, and b, with an additional alpha value
    [core] (transparency).  Chris Meadors asked this recently again.
    [core] "
    [core] the alpha values
    [MacArena] Actually only few targets have the switching-problem, so ...
    [Kor^] i think it should have alpha channel support
    [MacArena] O.K. - so should Alpha go into ggi_color ?
    [ortalo] There's a hungry woman in my apartment. I think I will have to leave shortly.
    [fries] the struct yes. otherwise another wrapper struct is necessary for anything that wants to use it. however, basic libggi ignores it. are there any issues with that approach?
    [andrew] macarena: yes, simply because some modes have spare bits (b8r8g8A8 etc).
    * bkosse thinks we should quickly address ortalo's issue and return to the color thing after he's gone.
    [tan] no - it has nothing to with colors.
    [weigon] is there another meaning of alpha then just for fading ??
    [ortalo] bkosse: do you want me to invite you ?
    [core] ortalo: your Fridge To Desk Female Transportation Device you mean?
    [MacArena] fries: sounds good. Just wanted to advocate that, too.
    [bkosse] No, I meant your issues with GGI real quickly.
    [chris] If ggi_color was extended to include alpha that would increase the memory requirements by 25%.
    [Mat] Anything that handles alpha should go in libggi[23]d I think.
    [MacArena] ortalo: I you got to leave shortly, we might just make a quick break for your topic - all agree ?
    [Mat] sure
    [bkosse] I agree.
    [fries] ok by me
    [andrew] chris: yeah - not a big hit imho
    [ortalo] thank you
    [core] okay
    * ShadowX not much involved in topic
    [MacArena] Rudolphe: O.K. - What's the topic ?
    [ortalo] Then, I owe you all a dinner (just to make everyone involved)..
    [MenTaLguY] actually, it'd increase 33%, not 25%
    [bkosse] I'll take breakfast instead.
    [ortalo] (PS: She's a _very_ good cooker [even according to french standards]=
    [MacArena] ortalo: Where will we have to go to get this dinner ?
    [ortalo] Topic: main issues to porting hw-driver to degas
    [core] ortalo: remember i'm seeing you in Toulouse soon? :) i'll bring my Female Device :-)
    * bkosse will get breakfast now. Be back in a bit.
    [weigon] next topic ??
    [core] macarena: when you visit me in France, we can go see Rodolphe, he's a 2 hours drive from here :)
    [chris] A 1024x768 screen goes from 4608k to 6144k, that is a pretty big increase to me. I don't know I have a 16MB system.
    [MacArena] O.K. - I think this is up to Jason and/or Steffen - right ?
    [mtorni] how about using /topic to tell about the current hot issue?
    [ortalo] (NB: Be careful, she's watching...)
    [core] mtorni: i had started, but .. :)
    [core] ortalo: okay, so, what did you want to discuss, Rodolphe :)
    [Kor^] chris: it is too much of a memmory increase, and I just realised alpha would help libGGI much, its more for layered stuff
    [andrew] chris: who stores a whole screen with ggi_color ?
    [Kor^] s/would/wouldnt!
    [MenTaLguY] but you're probably not going to be storing a whole screen in a ggi_color array?
    [ortalo] TOPIC (proposal): what are the main issues with porting drivers to degas ?
    [tan] IMHO DB should support alpha and maybe some function like ggiS/GetAlpha(x,y,alpha)
    [ortalo] (If you are aware of these issues) ?
    [MenTaLguY] keep in mind that ggi_color is typically just going to be mostly used in a few local variables
    [core] ok ok ok, now for driver porting
    [Mat] What drivers are working at the moment ? VGA only ?
    [ortalo] No: let's say VirGE class drivers.
    [Mat] Cool, I'll get to try it :)
    [bkosse] OK, food.
    [ortalo] mat: sorry I missed the point.
    [weigon] does degas driver mean : removing driver ,too ?
    [bkosse] Anyone know the status of the Mystique driver?
    [bri] weigon even evstack-0.2 could remove the driver
    [Mat] weigon: only with the setuid stub I believe.
    [MacArena] weigon: It was always meant that way. However few drivers cared about, as the old KGI patch didn't allow it ...
    [ShadowX] just out of curiosity: what was the main problem that prevented dali drivers from removing?
    [Kor^] what about Matrox Millenium II AGP or PCI? i was going to get one as my Diamond FireGL1000 isnt GPL friendly
    [ortalo] So, to clarify, here are my questions: Did the KGI API changed for drivers ? What is the impact of EvStack on drivers (if any) ?
    [bri] shadowx: wasn't it something like no graceful re-hook of the mini-kgi?
    [weigon] i just wanna say that removing works whhit the suidkgi target.
    [bkosse] Kor^ There are some rather unfriendly X Bugs (which may affect us as well) with the Millenium II's.
    [core] Jason? around?
    [andrew] shadowx: just the kgi_unregister_display() didn't work properly
    [Jason_McM] core: sorry - busy patching...
    [jonas] Kor: Millennium driver Works in dali..
    [Kor^] bkosse: do u have a suggestion fro a video card? i will get whatever works best with KGI
    [chris] Exactly how hard is to write a driver? I really want to try out a KGI target but no S3 911A support. :( I would give it a shot myself if it wasn't too bad.
    [core] ortalo: the KGI API changes, yes. but not like restarting from scratch. minor structure differences and replacement of text16 stuff by a textop/scroller system that most of the driver doesn't have to care about
    [core] jason: can you answer? we are talking about porting drivers
    [bkosse] Kor^ Not really.
    [Jason_McM] Anyway, yes there are a log of differences. The struct kgi_display has changed, the struct kgi_mode has changed, and the rules for what you can attach to the structures has changed to be much more strict.
    [Jason_McM] s/log/lot/
    [bri] chris: wait for someone to fully port an S3 driver, the codes rather unstable/partly functional except for in Dali IIRC.
    [ortalo] Whay are the text16 stuff not to be cared about ?
    [bkosse] Jason: actually, a LOG of differences would be nice, too. :)
    [MacArena] Jason: How's the "conversion guide" coming along ?
    [Jason_McM] I'm still working on the KGI Display Driver Guide, but it's progressing...
    [core] jason: btw, weren't i supposed to whack you if it wasn't online by friday? :)
    [chris] Jason_McM: Yeah, I was reading that a few days ago. Good work so far.
    [Jason_McM] I have the general outline done and the KGI kernel interface described
    * MacArena hands core a nice wet towel ...
    [Mat] core: just slap him with a big trout...
    [ortalo] Do the changes to kgi_display or kgi_mode simply imply a renaming/recompilation, or are there new fields to furnish ?
    [Jason_McM] (which telly you most of the logic behind it all)
    [weigon] is their a place in the net where you can get old graph-card. i wanna get an old 868/864. i´ve writen the driver but can´t test it .(
    [Jason_McM] New fields, all the timing info is now in kgi_mode.tm, there's a
    [Jason_McM] textop function table, versioning, etc...
    * andrew wonders what BOFH stands for
    [Kor^] bastard operator from hell
    [bkosse] Andrew: Bastard Operator From Hell.
    [andrew] ah :-)
    [bkosse] Andrew: "Went and bounced the servers for 2 hours today. Left night crew wondering what was wrong."
    [ortalo] What is "etc." ?
    [core] http://www.networkweek.com/bofh
    [core] the bible of any sysadmin in the world :)
    [core] how to tell your users that network problems come from "lunar interference", etc :-)
    [ortalo] Remark: how do evstack interact with the driver now ? (Do they provide something visible, or just nice new functionalities).
    [ortalo] (visible = something the driver should do for them to work)
    [bri] ortalo: the interface is the scroller. If you have a scroller, your driver will work.
    [ortalo] bri: what is a scroller ?
    [core] [oops.. http://www.networkweek.com/bofh.shtml rather]
    [Jason_McM] GGI Console (the new name for `EvStack') uses the driver's textop virtual function table to provide a lot of the functionality for drawing on the framebuffer. Eventually, a set of in-kernel `this is how you draw text on a linear-X framebuffer' textop
    [Jason_McM] structures will be in place, a la textop_linear_text16
    [Yazz] 'lo again
    [ortalo] okay
    [andrew] a la struct display_switch in fbcon.h ?
    [Jason_McM] A scroller is what aterminal emulator uses to draw on the screen. It provides a backbuffer (UTF 16 currently)
    [core] andrew: yes, pretty much
    [bri] ortalo: what jason said, see the new CVS and read scroll.h and scroll_struct.h
    [ortalo] If the card provides a text fb, are there generic functions to implement these textop(s) ?
    [core] basically a scroller lets you render in graphics or text consoles, use hardware scrolling etc without any difference to the driver
    [core] ortalo: yes, they are in already
    * ShadowX must eat :( :)
    [Mat] Tell me if I understand correctly: KGI and evstack are integrated, and fbcon is just another display target ?
    [ortalo] So: in short, I should put the timing info elswhere, and change a few things wrt text16 management.
    [core] mat: actually fbcon and KGI are both display targets of the GGI console (ex evstack)
    [ortalo] (Meal has arrived. ;-)
    [Jason_McM] oralto: Currently hard-coded in console-scroll-kgi, but soon to be migrated out.
    [andrew] mat: fbcon is framebuffer consoles originally for linux/m68k, but now work on x86 (with a vesa 2.0 driver)
    [ortalo] In very short: you made a good job and we have nearly nothing to do. No ? (Apart from making it compile.)
    [core] andrew: and with all KGI drivers soon *hint hint*
    [bri] Yes, jason did a great job IMO...
    [core] ortalo: that's what i suggested :)
    [ortalo] PS: Good new. I will be able to eat therefore.
    [core] ortalo: i didn't get the "NO !" in Helvetica-125 yet, but it should come anytime now
    [andrew] core: hint taken :-)
    [core] andrew :)
    [Kor^] bbl
    [Mat] And I thought computer people didn't need to eat... :)
    [bkosse] Sure we do, Mat: pizza, chips, pop....
    [Jason_McM] Hmmm... And you need to be very sure of where you set things up...
    [core] mat: their girlfriends
    [core] mat: their girlfriends do, i mean :P
    [Jason_McM] See the current documention in degas/kgi/doc for some hints... It'll be fully fleshed out soon..
    [Mat] core: I think there's an upgrade somewhere around :)
    [mtorni] better eat still, after 5 days without eating or drinking you have to go to the hospital... if you wake up.
    [ortalo] core: okay. bkosse: don't you want something else ? jason: we'll set up some adequate place.
    [core] mtorni: i have a Meal Preparation Device
    [chris] Well I've been up for about 22 hours. I'm not getting anything out of the text scrolling in front of my eyes anymore. Someone e-mail me where to get the transcript and I'll put it on the site.
    [bkosse] Samn, missed him.
    [core] chris: i'll rework it a bit to outline what has been decided, okay
    [mtorni] core: cat /dev/mealpreparator ] /dev/mouth?-)
    [chris] core: Cool, later...
    [core] goodnight, chris
    [Jason_McM] Committed more bugfixes to cvsdevel...
    [Mat] Shall we move on to the alpha topic ?
    [core] shall we go back to libggi issues, or do you want to do a 15 minute break?
    [MacArena] Think so.
    [mtorni] break would be nice.
    [bkosse] Sure.
    * bkosse is flexable.
    [Jason_McM] Breking....
    [core] okay - 15 minutes? have a drink, get a couple of kisses from your Meal and Bed Preparation Device, etc.
    [Mat] A break then. Time to brew some more coffee :)
    [Mat] core: bed warming device ? :)
    [core] mat: right :)
    [wlfshmn] core: enable gues cvs during break? *hint*
    [MacArena] O.K. - so let's move topic to "Ramblin' GGI" for that time :-) ...
    [core] okay, it's 7:50 at my clock. everyone be back at 20:05
    [wlfshmn] core: uhm.. that's over 12h ;)
    [core] lol. shut up
    [core] 8:05 then
    [core] and i'm just kidding, I love my girlfriend to bits.
    [fries] heh.
    * rdawes wonders if, while we are rambling, anyone has access to an AIX box?
    [Mat] whatever for ???
    [bkosse] There's one at work. Of course, if I touch the thing, I'm out of a job.... :)
    * wlfshmn has, but it's so aincent I'm not sure it supportd TEXT16
    [rdawes] Seeing as how I haven't heard anything about ports of libGGi recently
    * ShadowX no longer away, break now?
    [wlfshmn] I use this AIX box to heat up my office..
    [wlfshmn] And the screen gives me a nifty tan even during winter...
    [rdawes] I did the original AIX libggi port, and was wondering if anyone had tried it recently
    [fries] rdawes I fixed it on the machine I have at work to almost work with the aix's cc
    [rdawes] Since I no longer have access to one, I was kind of hoping to pass on the reins
    * fries ducks
    [Rogan] fries, which model do you have at work?
    [Mat] Anyone tried mesa-ggi lately ? Does it still work ?
    [fries] 43P-132
    * wlfshmn notes that he just finished moving all his gfx boards, never thought I had 82 of them... I'm one big junk yard over here...
    [fries] 4.1.5 currently, soon 4.3.1
    [Rogan] I was using a RS6000/340 with 3.2.5 and also 4.1
    [Rogan] Fries: are you interested in trying it?
    [tan] mat: I think so. uwe has ported it to mesa-3.0beta
    [Rogan] I've kept all of my porting notes : Mostly mail to the guy who wrote the libdl for AIX :-)
    [Mat] tan: you're the one dealing with libggi2d, right ?
    [ShadowX] rogan: you actually have "notes"?? I'm surprised
    [fries] Rogan: trying it? I practically have it working. I want to get Xggi working on AIX to do a -query. however, xggi, unless I missed something, doesn't do -query currently
    [tan] mat: yes.
    [Rogan] Just saved mail
    [core] i remember back when i ported libggi to IRIX, i was just starting on GGI.
    [Rogan] fries: thats great!
    [Rogan] Good to know that someone actually uses what one creates :-)
    [fries] heh.
    [Rogan] Not that porting is really creative :-(
    * Mat wonders if one can mix mesa/opengl with something else. Draw with mesa on an existing framebuffer without screwing everything.
    [fries] but I didn't have gcc at the time so I had to redo part of it for aix's compilers
    * Mat only just began the red book.
    [core] rogan: well, i think it is - it lets you spot where we are biased
    [Rogan] Fries: actually compiling libggi on AIX, then running XGGI under X?
    [MacArena] Mat: No problem.
    [core] fries: be happy i went there first and smoothed most of gcc stuff out for irix port, on sgi's cc :)
    * Rogan takes a bow : thanks core!
    * wlfshmn notes the vga driver is acting up again.
    [Mat] MacArena: cool, that's what I want to do, what a nice coincidence :)
    [fries] core: woah:-)
    [core] fries: it took me an entire night to do that, and i probably called Andy and Jason names :)
    [core] rogan :) glad to see you again too :)
    [wlfshmn] re-sync on each new line is kinda annoying...
    * Rogan was cursing the funky AIX linker!
    [Rogan] Damn thing requires axport lists and import lists :-(
    [Mat] Anyone knows anything about the new 2D/3D Matrox cards ? Will the 2D be compatible with existing drivers ? (Yeah, I know, dream on...)
    [MacArena] core: Seems we have to put a "spy virus" in the distribution to gain evidence of such behaviour .... You know the punishment ...
    [Rogan] core: I've been lurking, but without much programming knowledge, and a detailed list of debugging steps, my ET4000 is not much use :-(
    [core] macarena: i was speaking in my beard - but i'm nicely shaved now thanks to the crontabbed Bugging Female Device, so i should pay attention :)
    [Rogan] MacArena? punishment?
    [wlfshmn] Mat: The MGA engine has not change too much since it was introduced back in 93 or so, some extentions have been made and it's quite a bit faster now, the new matrox cards however are built on the G-x00 chipset, and I don't think these are MGA at all, so new drivers will have to be written.
    [core] (yes, that's what BFD libraries stand for)
    [Mat] wlfshmn: too bad, they lseem nice as graphics cards go.
    [core] mat: wlf wants to write drivers
    [bkosse] Well, I have access to the development information for Matrox if someone needs it.
    * bkosse will see what the guy who was doing the Mystique is up to.
    [Jason_McM] back
    [Mat] wlfshmn: could you have the drivers ready by the time I buy one please ? :)
    [wlfshmn] Mat: If matrox release the prgramming specs like for the 1x64 and 2x64 MGA chipsets, I think they will be the fastes in GGI's arsenal, both in 2D and 3D if programmed correctly.
    [MacArena] rogan: Disobedience of the big masters as well as calling them names is subject to severe punishment. In case I am in a mild mood, I might want to dance macarena on him, while he is stretched out between two posts :-)
    [Mat] cruel...
    [bkosse] Matrox gives away the information but you have to tell them what you're doing it for. They let me in with the knowledge it was going into Linux.
    [MacArena] s/sever/severe
    * Rogan chortles
    [wlfshmn] Mat: I'm not good enough to write such a driver, since I'm still learning, I stick to the old MGA chipsets, that not too many people need now anyway, that way I don't have the preasure on me ;)
    [core] macarena: if my girlfriend calls me "silly", should i apply that to her? stretch her and dance macarena on her?.. that's an idea..
    * Mat believes the break is over.
    [MacArena] core: I am not sure if she falls under GGI legislation. I working hard on imposing that on my new one ...
    [MacArena] core: It seems I have some bad influence on your life outside GGI :-).
    [fries] wlfshmn: I have 3 mga video cards and 3 pc's. hint hint hint.
    [core] macarena: i am an influencable kind of person :)
    [Jason_McM] core: Current topic is?
    [core] okay, according to my clock we'll have to be serious again 2 minutes ago.
    * mtorni 's coffee is ready, so the break IS over.
    [core] back to libggi fights?
    [core] I'll assume a yes.

    libggi: #5- "display-" prefix
    [core] Problem #5 :
    [core] "
    [core]   It was suggested to drop the "display-" prefix from all LIBGGI_DISPLAY
    [core]   parameters. There was a very easy solution suggested (editing
    [core]   libggi.conf), so it's the political question: with the prefix or not,
    [core]   allow both and recommend one, then which?
    [core] "
    [core] The display- prefix in libggi.
    [ShadowX] not this again :)
    [Mat] ditch the prefix !
    [andrew] I vote for supporting both, having both in libggi.conf
    [mtorni] kill the prefix
    [mtorni] destroy the prefix
    [Jason_McM] I think in /etc/ggi/libggi.conf it should stay the way it is, and the dynamic loader should try `display-??' if '??' can't be found.
    [ShadowX] support both
    [MenTaLguY] I'd say keep it, and if we really want to avoid having to deal with display- in the environment variables, make it implied there
    [mtorni] smash the prefix !
    [MacArena] O.k. - quick decision - Have both by using /etc/ggi/libggi.conf set up accordingly. Official version as used in overriding libs and such is display-*
    [core] i agree with jason and andrew
    [MacArena] Is that o.k. ?
    [MenTaLguY] i.e. add missing "display-" in the routine that parses the environment variable
    * ShadowX agree with macarena
    [core] macarena: okay
    [andrew] maca: yes
    [mtorni] MacArena: ok
    [MacArena] Fine. Next one.
    [core] this one is very heated.
    [Mat] aaaaaaaarrrrrrrrggggggghhhhhh color modes ?
    [mtorni] MenTaLguY
    [MenTaLguY] mtorni: yes?
    [bkosse] What's the issue?

    libggi: #6- memory visuals
    [core] problem #6: memory visuals
    [core] "
    [core]   A memory visual will typically be used to draw in-memory and then
    [core]   transfer to some 'real' visual. If the memory layout (byte order ...)
    [core]   of this memory visual is exactly like the layout of the frame buffer,
    [core]   copying will be far faster than otherwise.
    [core] "
    [smoke] hiya :)
    [bkosse] Allo.
    [smoke] is it over already ? :(
    [MacArena] Aloha !
    [MenTaLguY] nope. not over yet.
    [MacArena] smoke: We've just began :-).
    [Jason_McM] Also know as a) use standard packed-pixel types for memory visual buffers or b) add lots of code for emualtion of everything supported by directbuffer
    [bri] surely you jest -- we'll be at this forever :)
    [bkosse] Nope. We're just about to argue about whether we should do memory layout exactly like the screen or what?
    [Jason_McM] I vote (a)
    [fries] is there a reason why we would not want to?
    [core] smoke: don't worry, the topic we just started will last for a couple of days.
    [MenTaLguY] I'm with Jason
    [core] jmcc: that's a biased way of explaining things ;)
    [ShadowX] if option (b) , why have to add lots of code for emulation of directbuffer types
    [fries] jason_mcm is emulation easier than the other way is why you want that?
    [Jason_McM] Of course it is. First principle of debasing...
    [MenTaLguY] because that IS the option b
    [ShadowX] don't we already have driver-libs (linear 8,etc.)
    [Jason_McM] s/debasing/debating/
    [MenTaLguY] different DB formats won't stop crossblits
    [bkosse] Doing A) will be hideous for anyone trying to do a double-buffered thing with only enough video ram for the one frame.
    [core] and using A) will be terrible for anyone having sprites or other graphical objects in a memory visual
    [MenTaLguY] mmm
    [core] using B), there is no need for emulation as we indeed have linear libraries
    [Mat] Couldn't we have different formats for memory visuals ?
    [bkosse] Good point, core. I'm doing that and I forgot about it. :(
    [Jason_McM] Option (b) simply requires a lot of code....
    [MenTaLguY] well, you could always load specialized stubs into the memory visual to use a different layout, couldn't you?
    [fries] aside from preferences, is it doable in both cases?
    [core] jason: that we already have..
    * fries grins
    [core] mentalguy: that's what libggi does
    [MenTaLguY] yes ... that was my point
    [MacArena] Andrew had suggested a more complex Mode setup scheme (well actually just a few more GT_* which should nicely solve the problem. Shouldn't they ?
    [Jason_McM] I like andrew's proposal....
    [andrew] :)
    [core] andrew: can you explain it to all of us again? :)
    [core] i have your mail under my eyes but..
    [Jason_McM] (just ned to come up with a good naming scheme and throw the new code in libggi/default)
    [andrew] Ok - the graphtypes are just "GT_XXX + depth" e.g. GT_RGB + 16
    [MenTaLguY] I like that
    [ShadowX] yeah, now I remember, i like that one
    [Jason_McM] Ie linear-rbg-16 for the lib?
    [MacArena] And it doesn't mean we have to rewrite all the linear-* libs. Just separate out the color mapping like it is with generic-ramdac and such ...
    [bkosse] One question on 16-bit depth: do all cards use 6-bits for green or do some have the ability to change that extra bit?
    [andrew] The resulting mode still could be r5g5b5, or r5g6b5, or r6g6b6, with or without byte swapping, or ...
    [core] okay, so that's just more libs.
    [bri] bkosse: one of mine can even reorder rgb I think...
    [tan] yes! I definitely need this information for alpha blending in libggi2d
    [core] that's fine to me.. i want to avoid conversion at all costs
    [Mat] What does it imply ? Some kind of automated stubs ?
    [andrew] I've been thinking of using DB names for the libs: linear-r5g6b5 etc...
    [MacArena] andrew: no need.
    * smoke has got to go in a minute ;(
    [smoke] will there be a log ? :)
    [Jason_McM] andrew: That's probably a good idea
    [MenTaLguY] smoke: yes
    [core] smoke: there is
    [MacArena] andrew: at mode setup you just load linear-16 and color-fixed-r5g6b5 etc.
    [andrew] e.g. linear-r5g6r5 would load a generic linear-16 (for pixel-stuffing drawing), and contain code for ggiMapColor() etc.
    * MacArena might drop out soon, as I seem to start getting problem with the power supply due to a thunderstorm nearby ...
    [Jason_McM] Macarena brings up a good point, andrew...
    [core] macarena: c'mon, we just have one point left after that one :)
    [andrew] it amounts to the same thing really
    [MacArena] core: Let's hope electricity lasts :-) ...
    [Jason_McM] Anyhow, it's agreed - use the new GT_* types and load in libs, right?
    [core] macarena: just plug your bike on your computer and bike really fast :)
    [MenTaLguY] yep
    [bkosse] Hehehehe.
    [core] jason: yes
    [fries] hah
    [ShadowX] rotfl
    [mtorni] hey, how about the 32k page alignment with newer strongarms?
    [Jason_McM] Next?
    [bkosse] No UPS and generator? Shame on you.

    libggi: #7- buffer opacity
    [core] okay, next and last for libggi rants:
    [core] [ducks]
    [core] "
    [core] ggiGet/PutHLine and friends have no documented buffer layout.
    [core] The only guarantee is that the size of the buffer is
    [core] width*height*sizeof (ggi_pixel).
    [core] This is bad because one can't prepare a buffer 'offline' and then blit
    [core] onto the screen.
    [core] "
    [MacArena] core: Don't tell that my /dev/female ... luckily she ain't around now ...
    [Jason_McM] mtorni: I though we were going to use a static libGGI on the strongarms?
    [mtorni] Jason_McM: ok, sorry if I missed that..
    [core] macarena: yeah, one really starts to get used to mount /dev/female.. i understand ;)
    [Jason_McM] Use the MapPixels() call to build your buffer...
    [MacArena] O.K. - what about my proposal of extending DirectBuffer ?
    [mtorni] MacArena: which is...?
    [bri] Macarena: I liked that.
    [ShadowX] sorry, what is that, don't see it
    [core] macarena: refresh my DRAM, i have been sort of skipping through messages with all that licensing crap lately :)
    [bkosse] shist, weren't we going to talk about that, too?
    [andrew] I'm thinking just use the ggi_common_plb_setup values (e.g. sp16r5g6b5 and friends) to specify get/put buffer format (packed linearly)
    [MacArena] Basically having the getbuffer call accept a new exported pointer as the "get first" parameter (which is yet defined to be NULL) and thus allow it to query any buffer format, not only the screen one.
    [MacArena] andrew: Exactly and use DB calls to query it.
    [bkosse] MacArena: I think that is absolutely essential that getbuffer be able to query any buffer.
    [MacArena] bkosse: That is what I was suggesting. anyone have the prototype around ?
    * MacArena is searching for a .EXE version of XBill ...
    [bkosse] hehehe.
    [ShadowX] just use your toaster :)
    [bkosse] When libGGI runs on top of Windows, you can play XBill on XGGI on Windows.... :)
    [MenTaLguY] it's probably be faster than a native XBill :P
    [andrew] macarena, how about labelling directbuffers, like DB_FRAMEBUFFER, DB_GETPUTBUFFER, DB_ZBUFFER, ... ?
    [bri] O.K, so does anyone see any problems with Macarena's proposal?
    [MacArena] shadowx: I have tuned my toaster a bit to make that harder. slices come out at Mach 0.9, which makes it an excellent device for chasing burglars :-)
    [MacArena] andrew: It's something like it.
    [mtorni] bri: no, considering I haven't seen it :)
    [bkosse] MacArena: our toaster here literally throws single slices of toast.
    [andrew] BTW, should ggi_info_fb be removed from the LibGGI API ?
    [mtorni] happy lingering...
    [MacArena] andrew: I'd say leave it for compatibility, but mark it as "deprecated - will go away !".
    [Jason_McM] andrew: Yep, it probably should. It's achient.
    [MacArena] Does anything still use it ?
    [ShadowX] how will targets communicate linear fb then?
    [Mat] Do we really need compatibility at this stage ?
    [andrew] shadowx: DirectBuffer.
    [core] mat: from the application point of view yes, there are quite a bunch, and everything should be done to at least give a chance to developers to adapt to changes :)
    [ShadowX] andrew: is that right. i hoped for that all along :-) but it's not implemented yet? I don't see targets using it now...
    [bri] It should be specified that even when Directbuffer isn't available a request for the framebuffer fills in the DB structs description with the layout, just leaves no pointer
    * MenTaLguY nods
    [Mat] core: but will they change it if we leave it in ?
    [MenTaLguY] that'd probably be appropritate
    [core] mat: it'll be "marked as deprecated" ;)
    [core] mat: ie. warning at compile time or so
    [wlfshmn] mark it and make sure it is removed, not just an empty threat.
    [andrew] shadowx: the targets that use VIS_LINEAR_FB probably need fixing (or at least, make ggi_info_fb internal)
    [Mat] core: yeah, that's what I said :)
    * wlfshmn has horrible osociations between DirectX and DirectBuffer
    [MacArena] O.K. - so let's mark it and put a warning in there at compile time, and I'd even suggest one at runtime, so users bug the authors ...
    [Mat] In big friendly letters :)
    [ShadowX] do it everytime it setMode() , and wait 10 AND press any key :)
    [core] works for me
    [core] (what macarena said, not shadowx ;)
    * bkosse hopes ShadowX was being facitious. :)
    [Mat] Seems like there are no objections
    [core] allright.
    [bri] phew
    [MacArena] O.K. moving on ...

    GGI licensing (18:39 GMT)
    [core] now for the last topic of the day - unless someone sees another ..
    [core] GGI licensing.
    [fries] xggi tooo
    [ShadowX] i thought you all hate lawyers
    [Mat] The war begins...
    [mtorni] I'm hit, i'm hit!!!
    [bkosse] AAAAAAA! RUN IN TERROR!
    [MacArena] Quick help mtorni ... !
    [core] as in, should we stick to GPL or switch to BSD, where, and why.
    * yazz is back into the realm of linux, after a nightmare of M$.
    [fries] the main question is, do we want to allow vendors to encorporate the sources of libggi and friends into their os, or do we want to force them to release source (and discourage BSD os's in the process)
    [Jason_McM] libGGI - LGPL, degas/os/* - BSD (esque), degas/kgi/* - BSD (esque)
    [bkosse] Well, let me suggest we keep KGI (the Linux internal kernel type stuff) as GPL.
    [bkosse] As long as we keep the interfaces public, we shouldn't have any problems....
    [MenTaLguY] yes, the Linux-specific kernel portions ought to be GPL
    [Jason_McM] ok, degas/os/* - as appropriate for target os
    [fries] no reason not, as long as they can be purused for bsd kernel implementation
    [MacArena] O.K. - let's go "step-by-step".

    GGI licensing: include files
    [Jason_McM] include/* - public domain
    [bkosse] That way, teh BSD-guys can make a BSD-KGI, Sun can make a Solaris-KGI, etc. which all use the same drivers, but aren't using the same implementation.
    [Mat] Jason_McM: what about the kgi target of libggi ? *duck*
    [fries] LGPL is still restrictive and part of my 'main question' above
    [MenTaLguY] I still don't see what the problem with LibGGI and the other libraries being LGPL would be, and a modified BSD license would be ... _okay_ for the rest
    [bkosse] Jason: not PD.
    [Jason_McM] well - BSD esque?
    [bkosse] That'd be better. PD means we give up any chance of getting it back, basically.
    [MacArena] Let's start with #includes and programming samples. We should make those as free as possible - right ?
    [andrew] ok
    [ShadowX] yes
    [Jason_McM] Rigth
    [yazz] y
    [fries] mentalguy: Idon't personally have a prob with lgpl, but the spirit of *BSD's is to not be restrictive, lgpl is restrictive, therefore they would have to decide to have restrictive in their tree to support a kernel feature or re-implement libggi (and some might opt for the 2nd)
    [bkosse] Mac: The samples should be something where we keep copyright but make it totally unrestricted.
    [Jason_McM] Anything related to the IBM vga driver will fall under the same roof
    [MenTaLguY] fries: relative to GPL, BSD doesn't have many teeth in it to prevent the libraries from being abused or co-opted
    [MacArena] O.K. - so we should use BSD licensing with the "give CREDITS" removed - o.k. ?
    * MenTaLguY nods
    [ShadowX] yes
    [bkosse] fries: Doesn't BSD use GCC? It seems silly for them to use that if they're so hell bent on this freedom thing.
    [fries] metalguy: and that same fear prevents commercial people from touching the src of the libs.
    [andrew] ok
    [MenTaLguY] fries: as long as they release their modifications, I really don't see what the problem would be
    [fries] bkosse: the wish is a non gpl app/lib. however, gcc is not essential for the os to work.
    [fries] therefore it is in a gnu/ subdir along with perl and libgmp and libg++ ,etc..

    GGI licensing: libggi
    [MacArena] O.K. - then for LibGGI. I think this is the least troublesome. We can keep it LGPL, or make it BSD - how about double-licensing it ?
    [fries] macarena how can you do a double license?
    [bkosse] fries: We are talking about making a *L*GPL, not a *GPL* which means commercial people can use the lib.
    [core] macarena: what's the point in double licensing? people will take the less restrictive license anyway - BSD
    [fries] at the user's option use either?
    [Jason_McM] Keep it LGPL (libGGI)
    [ShadowX] i don't we should doublelicense the library
    [andrew] I vote to keep it LGPL
    [MacArena] core: "keeping everyone happy :-)"
    [yazz] Double-licencing means everyone who contributes new stuff must be willing to contribute with their stuff under both licences, yes?
    * bkosse votes to keep it LGPL.
    * yazz votes for lgpl
    * wlfshmn votes LGPL
    [MenTaLguY] LGPL
    * fries is 1 vote against the masses.
    [MacArena] O.K. - looks like LGPL is decided.
    [core] macarena: hehe.. yeah, but this'd be the only practical use ;)
    [core] fries: that's only fair, you are a *BSD person ;)
    [core] yeah, LGPL for me
    * bkosse wants to know what is so terrible about LGPL.
    * Mat abstains (easy way out)
    [fries] not totally. but I have to feel the responsibility to represent them since no one else is here.
    [MacArena] Actually as we are heavily using dynamic linking, it is no problem to write non-GPL plugin modules.
    [MenTaLguY] it'd be nice if BSD was better represented here
    [ShadowX] one problem: lgpl: does it have any requirements a commercial app ship with source for libggi?
    [MenTaLguY] LGPL should be fine with linking in any case
    * mtorni one vote against fries
    [core] fries: actually i'd be interested if you could take Theo de Raadt to one of our discussions sometime - for openBSD port
    [MenTaLguY] ShadowX: no
    [Jason_McM] Not a problem if they suppy the URL to get it from...
    [fries] hrm, lemme check ..
    [bkosse] ShadowX: I think it's not an issue as much with dynamic libs.
    [MenTaLguY] ShadowX: unless it ships with the app
    [MacArena] shadowx: they'd need to at least supply information about where to get it IIRC.
    [MenTaLguY] ShadowX: and that could just take the form of supplying a URL
    [ShadowX] mentalguy: that's sounds reasonable to me, then
    [MenTaLguY] really, maybe someone should write up a very short little guide to practical commercial use of LibGGI, allaying these sorts of concerns
    [bkosse] IIRC LGPL requires you to make "object code" available to support relinking (or has that changed). With dynamic libs, this happens automatically.
    [bkosse] But, you don't have to distribute said object code.
    [Mat] bkosse: what about system where we have to use static links.
    [Jason_McM] For the `static only' os's we can have an exception clause...
    [bkosse] I think that may fall back to the release object code (hell, Sun does this already!)
    [core] mat: then they can provide an URL where to download the sources and object code i suppose.
    [mtorni] Jason_McM: with lgpl we can't -- it self-prevents its modification
    [bkosse] Don't need the sources.
    [bkosse] mtorni: GGI-GPL which is LGPL with that clause removed?
    [Jason_McM] Why not make a `GGI GPL' that covers these concerns?
    [core] on static lib systems, there'll be a libggi.a or so to distribute along, that's it.
    [andrew] jason: yet another license ?
    [ShadowX] jason: we don't have lawyers to make licenses.
    [bkosse] andrew: it's just a thought.
    [Jason_McM] all: point about lawyers...
    [core] jason: we can't pay a lawyer.
    [andrew] :)
    [Mat] There's always Bruce Perens, I think he may help us there.
    [core] and the LGPL has been well-tested
    [Jason_McM] Hmmmm... Bruce seemed like a nice guy when I talked to him at LinuxExpo (and helped his team win the Linux Bowl)
    [bkosse] When you think about it, though, there's (right now) a very limited number of apps which would use LibGGI directly.
    [mtorni] core: on static lib systems there'll be libggi.a and app.a
    [core] mtorni: app.a ?
    [core] mtorni: oh - right.
    [core] mtorni: well, even better then. no space wasted.
    [bkosse] Most things still use X (except on *BSD and Linux) in the commercial world so it would be a case of moving X to LibGGI and the apps would still use X to write.
    [Jason_McM] all: I like mtorni's suggestion - it'll also allow people to `upgrade' their app to the newest version of libGGI by doing a `/opt/AppName/bin/relink'
    * MenTaLguY nods slowly
    [MenTaLguY] sounds neat :)
    [core] yup, that works for me. just provide some inane Makefile that does that during make install or so
    [yazz] Jason_McM: Thats just what LGPL is about, if you use static linking, make sure people can upgrade/fix the lgpl lib.
    [Mat] core: seems like you just volunteered to write it :)
    [MacArena] O.k. - so it looks like that now: demo/stubs code : BSD minus credits, LibGGI LGPL Now for KGI ?
    [core] mat: well, i'm not a big fan of high-level stuff, but even I could write it ;) just one line.

    GGI licensing: KGI
    [core] yup, now for the tough part - KGI.
    [MenTaLguY] mmm
    * bkosse votes KGI is GPL pure.
    [MenTaLguY] I'd say the shared portions (between different OSes) of KGI should be BSD
    [mtorni] bkosse: how about *BSD kgi?
    [MenTaLguY] I really don't like doing that, but it's necessary
    [mtorni] bkosse: or someotheros-kgi?
    [andrew] how much of KGI is really portable ?
    [core] well, it goes like this:
    * bkosse reiterates his point about *BSD guys, and Sun guys, etc. writing their own KGI.
    [fries] any kernel stuff in BSD will definately have to be BSD license.
    [core] 1) if we make KGI GPL, it will never make it into bsd
    [bkosse] The drivers plug in to a specified interface.
    [Jason_McM] degas/kgi/* - BSD
    [Jason_McM] degas/include/kgi - LGPL
    [core] 2) if we make KGI BSD, it can be built as a linux kernel module [only].
    [MacArena] STOP - we have to differenciate here :
    [MenTaLguY] that won't do either
    [Jason_McM] degas/os/Linux/* [kgi patches] GPL
    [mtorni] kgi/linux - gpl
    [ShadowX] core: get rid of the credits clause then..?
    [mtorni] kgi/bsd/ - bsd
    [MacArena] 1. The OS specific portions. My opinion on that is having a license compatible with the host OS.
    [MenTaLguY] uh, let maca speak
    [core] shadowx: no, that's not it. you can't link *BSD code with GPL code, to the exception of kernel modules
    [mtorni] kgi/drivers/* - some funky license.
    * wlfshmn agrees with MacArena
    [bkosse] kgi/drivers/* - dependant upon the driver.
    * MenTaLguY agrees with MacArena as well -- it's just common sense
    [MacArena] 2. The KGI drivers themselves : We NEED to put them under some license that is compatible with _all_ OSes we want them to run on ... though problem ...
    [core] macarena: yes, the 2) was the bit i was talking about
    [mtorni] MacArena: how about binary-only drivers?
    [bkosse] Wouldn't these qualify as "plugins"?
    [core] basically, if KGI driver/OS interaction code is put as BSD, we can only build it as a module under Linux
    [MacArena] We should allow all driver authors to use whatever license they want.
    [core] like ppp compression code.
    [MacArena] However I think we should propose a very free license as the default.
    [core] if we put it as GPL, it cannot be built at all into BSD.
    [andrew] macarena, we could have two copies (one GPL, one BSDish). Maintaining them both will be a pain though.
    [yazz] MacArena: If the linux-part of kgi (linux-i388.o or whatever) is GPL and the drivers are BSD they can't be statically linked to each other, or?
    [MenTaLguY] andrew: or dual license, which would be _less_ of a pain
    [bkosse] core: This is where I think the BSD-guys should write their own GGI handler if they wish to.
    [Mat] How about a "Same license as whatever it's linked against" license ?
    [mtorni] wouldn't it be just great if the graphics drivers would be PD?
    [core] yazz: no, they can't.
    [ixx] macarena, how can that work? the license chosen could conflict could it not?
    [MenTaLguY] andrew: although dual license would eventualy cause a split anyway
    [MenTaLguY] now that I think about
    [mtorni] it could make driver support on all OSs a bit better..?
    [core] macarena: it won't work, you can't link GPL code to anything else than GPL code
    [core] bkosse: that's not viable - imagine how many times we'd have to implement non-OS-specific code? that would be like rewriting libggi entirely for every platform
    [vertigo] but they linked stuff like Qt and KDE together, the one being non-gpl and the other GPL. is that legal then ?
    [yazz] qt is dynamic lib.
    [ShadowX] core: is that true? How about things like libjpeg, that's not GPL
    [core] vertigo: that's LGPL, it's not the same
    [core] shadowx: that's a shared library. it's not the same
    [MenTaLguY] mmm
    [bkosse] core: we do that already with damn near everything (TCP/IP, POSIX, etc)
    [vertigo] ah..
    [MacArena] Well - that's sick ... whatever we do, we are screwed. The only compatible license I see is some kind of "nolicense", i.e. PD.
    [ShadowX] core: there seems to be no legal difference between static / dynamic linking (ref. RMS)
    [fries] with bsd there is no restrictions on what you can do.with gpl there is. that is all.
    [yazz] PD is BAAAAAAAAAD
    [core] bkosse: if we don't write KGI for solaris/openbsd/etc ourselves, it won't appear on those platforms, and we don't have the resources/motivation to rewrite completely different code every time ourselves
    [core] shadowx: there is, considered those dynamic libs are placed under _LGPL_
    [yazz] fries: With bsd, no static linking to gpl code of linux =] need to be module ONLY
    [bkosse] core: I was under the impression that the OS-specific stuff would talk to the drivers.
    [mtorni] what does freeware imply?
    [bkosse] core: if we keep it at that level and don't screw around with any other mixing, we should be OK.
    [core] bkosse: not at all - platform independent code, KGI itself, will talk to the drivers, and the OS. that's the whole point
    [fries] Yazz if you want to maintain 100% freedom as bsd does using gpl is not good. in the absence of a 100% free something gpl will do.
    [yazz] mtorni: freeware implies nothing, it's not a licence. Just a word.
    [bkosse] Hrm, did this change with EvStack or something or have I been completely mistaken this whole time?
    [fries] "OpenSource" heh.
    [MenTaLguY] sure, bsd license is free. the only problem is that it leaves us open to exploitation, or I'd be just fine with BSD
    [core] bkosse: there will be specific parts in KGI, but evstack (aka the GGI console) is not going to be explicitly rewritten on a per-os basis for example
    [MenTaLguY] GPL is the only license with any teeth in it to protect us
    [yazz] I feel that a dual licence GPL + (BSD - adverticement clause) is needed.
    [MenTaLguY] it's the old security/convenience tradeoff
    [fries] mentalguy let me restate what I said at the beginning
    [core] yazz: again, it won't protect us from anything - people will use the least restrictive license
    [yazz] execept the parts that are clearly linux-only, like the console stuff of course.
    * bkosse remembers when GGI was Linux-only.
    [yazz] core: Yeah, but the least restrictive licence (BSD) don't let us be in the linux kernel :(
    [core] yazz: it does, but only as a module.
    [core] yazz: i.e. we can be in the kernel source tree, just not built into the kernel image itself.
    [fries] the main question is, do we want to allow vendors to encorporate the sources of libggi and friends into their os, or do we want to force them to release source (and discourage BSD os's in the process)
    [Mat] core: but drivers will be modules, won't they ?
    [core] yazz: it's annoying for embedded systems and such, though.
    [yazz] core: Lot's o people don't like/use modules. Linus is one.
    [fries] Yazz bsd license in linux is fine last I checked.
    [bkosse] fries: LibGGI is *NOT* under GPL.
    [core] mat: ideally they could be linked in the kernel as well.
    [MenTaLguY] No, we don't want vendors incorporating LIBGGI into their OS kernel
    [bkosse] Sun already distributes a small pile of LGPL stuff with their OS.
    [fries] mentalguy really?
    [MenTaLguY] what the hell would LibGGI be doing in the kernel anyhow?
    [mtorni] fries: letting some commercial companies integrate ggi into their OSs wouldn't be bad, now would it?
    [fries] mentalguy so we want to say 'free osses rule, have a unix standard, and commercial os's can't have it .. naaah..' ?
    [bkosse] fries: *LIB*GGI does *NOT* belong in a kernel.
    [core] ok, stop everyone
    [MacArena] Ment: We aren't talking about LIBggi ...
    [core] todd fries meant, distributing libggi in the OS, not the kernel
    [core] there is a misreading somewhere.
    * MenTaLguY blinks
    [MacArena] O.K. - I'll set us back on track ...
    [MenTaLguY] okay, yes, let's backtrack a bit
    [yazz] BSD licenced drivers would let commercial os's use the drivers. They (or someone) would only have to do write some glue internally in their os.
    [MacArena] The point is : KGi drivers are linked from an OS-specific and a card-specific part.
    [weigon] linux 2.1.105 is out.
    [core] and GPL will not allow us to use different licensing scheme for them.
    [core] s/scheme/schemes/
    [MacArena] This has bad consequences due to the BSD<->GPL licensing dilemma ...
    [MenTaLguY] mmm
    [core] the only thing i can see is have the kernel-patch part of KGI as GPL, and the drivers/KGI module part as BSD
    [core] as GPL, or any other license the host kernel uses, i mean.
    [MacArena] We have to link to a GPL part (the linux-kernel glue) and eventually to a BSD part (the BSD-kernel glue) plus maybe a bunch of other licenses.
    [bkosse] I think everyone can agree that the "kernel-patch" part should be GPL, right?
    [MenTaLguY] how about, for KGI, a slightly more restrictive BSD-ish license, that requires any modifications made to _our_ code to be released
    [core] which means we are stuck to using modules under linux for drivers, though.
    [yazz] bkosse: Yepp
    [MenTaLguY] bkosse: for the Linux kernel, sure
    [MacArena] bkosse: It has to.
    [bkosse] OK. And LibGGI itself is LGPL, right?
    [fries] mentalguy: then that might as well be gpl or lgpl.
    [core] bkosse: or any license used by the kernel
    [yazz] core: linus won't like a modules-only solution...
    [bkosse] (I think there are 2 layers we have to deal with between the two)
    [MenTaLguY] fries: not really ... it still woudln't have the linking restrictions at all
    [fries] mentalguy: the objection bsd people have regarding gpl/lgpl is it restricts the freedom of the code.
    [bkosse] (the two being the kernel code and the LibGGI)
    [ShadowX] yazz: i don't like modules-only either
    [MenTaLguY] fries: it restricts the freedom of people to abuse the code by taking it and turning it into something proprietary, yes.
    [MacArena] O.K. - it looks like we have to make a special license for the card-specific part ...
    [mtorni] let's look at this way: What (kind of) licences can we have if we want to be linked into the kernel?
    [core] on another interesting topic, not using modules basically restricts you to 1 (ONE) driver.
    [core] i.e. no multihead unless it's with the same board.
    [MacArena] mtorni: Only GPL.
    [fries] bkosse: you can do whatever licensing stuff you want. but my point is simply this: if you use gpl and/or lgpl BSD people will look twice at it before using it.
    [core] fries: they won't use it, you mean
    [yazz] MacArena: Cannot the special licence be: Use GPL v2 or BSD minus advertisment clause, whichever you want.
    [mtorni] core: why? is the current ggi designed so? (hint?)
    [bkosse] "kernel stuff"->"card interface"->"card driver"->"LibGGI" Is that right?
    [core] mtorni: no, there is a namespace problem.
    * MenTaLguY thinks a bit
    [MacArena] We would need to make something that is guaranteed to be linkable with everything ...
    [ixx] Can there not be a license which says use BSD license on a *BSD system and GPL on Linux?
    [MenTaLguY] what about a modified GPL without the linking restrictions?
    [core] macarena: this is not at all possible, because the host license on linux (GPL) prevents us from doing it
    [core] macarena: ie. prevents any linking to anything not exactly under GPL
    [fries] linking restrictions should not be an issue no matter how you license it.
    [MacArena] bkosse place LibGGI on the other side of the chain. LibGGI communicates with the card driver through the OS kernel.
    [ixx] Is there something in the licenses that would not allow somethign like that?
    [core] ixx: yes - you can link GPL to GPL only
    [fries] the issue I present is whether or not we want to make it enticing or less than enticing to BSD people.
    [MenTaLguY] mmm
    [MenTaLguY] right
    [MenTaLguY] modified GPL still wouldn't do for Linux
    [fries] core: you are saying gpl prohibits linking with non-gpl code?
    [ixx] core, I thought I saw something that said GPL refers to a specific release.
    [bkosse] "LibGGI"->"kernel stuff"->"card interface"->"card driver" and the biggest licensing issues are the "card interface" and "card driver", then?
    [MacArena] core: tough luck for Linux, then. I'm actually getting upset about such silly licensing ...
    [andrew] I'll say it again: two copies of the drivers - one under GPL, the other under BSDish. This would work I think.
    [core] fries: yes. that's the truth
    [core] mentalguy: no, we'll still be stuck at modules. so better use an existing license then - BSD
    [fries] core: "restriction of freedom that the BSD people do not like"
    [MacArena] bkosse: right.
    [ixx] so the GPL could be applied to a Linux release... and BSD otherwise
    [core] andrew: it will be a nightmare to maintain, i'd rather live with modules and BSD licensing
    [Silk] can you relicense something under bsd to gpl directly?
    [yazz] fries: Linux is gpl =] link to GPL only, but linus the copyright-holder has made an exception and allows binary-only modules.
    [weigon] As far as i can see we need both licences. to convince people if they they can " why 2 licences" we just have toexplain it at out web-page.
    [core] and two sets of unsynced sources - who wants to maintain them?
    * MenTaLguY nods slowly
    [yazz] Is there a problem having the same source under two licences?
    [bkosse] See, I think the "card interface" belongs in the "kernel stuff" part of everything. This would actually solve all the problems.
    [ixx] core, why is it a nightmare? from what i have seen you can make an exact copy of your code and release under a diff license
    [core] yazz: yes, you have to have two sources
    [yazz] The copyright-holders can do whatever to their stuff?
    [core] ixx: well, the kgi/ subtree will be twice as big, and we have to make sure the sources stay in sync?
    [Mat] core: GPL often says 'GPL version 2 or later' in the license, can't we do the same thing with 'GPL or BSD' and have only a single source tree ?
    [MacArena] core: is that actually a problem ? As we hold the copyright on the sources, we can make them available under both licenses at any stage- can't we ?
    [MenTaLguY] well, only that changes/fixes committed under one licence couldn't be put under both licenses without the copyright holder's permission
    [ixx] eg. I put my code on the net under gpl, then put my code on the net under bsd
    [yazz] core: Why, linus allows binary modules as an 'exception'...
    [core] macarena: does the GPL allow for linking something from "both GPL and BSD" licensing ?
    [MenTaLguY] so especially changes by the BSD folks are likely to fragment the tree
    [andrew] core: it would be pain, but it solves the problem. I really want to link my graphics driver into my Linux kernel.
    [fries] macarena: the subject of changing licenses must rely on everyone who contributed to agree.
    [core] andrew: i want too
    [weigon] maintaining isn´t the prob. the cvs-version is the bsd-version. the gpl-version is generated from cvs by replacing the licence-header
    [core] andrew: i'm just trying to figure out a non-painful solution
    [ixx] core, well staying in sync should be easy... just copy over..... the only diff would be bsd specifics which would not be in the linux tree
    [ixx] gpl tree
    [MenTaLguY] we could, of course, require transferring copyright to "the GGI consortium" or something. but I don't like that.
    [bkosse] How would we get the card drivers to run under Solaris, people?
    [MenTaLguY] ixx: but what if BSD people contribute bug fixes, and aren't willing to GPL the code?
    [mtorni] does the bsd license allow re-licensing under the gpl? Or why is the bsd "free" otherwise?-)
    [bkosse] This has a serious impact on this discussion.
    [MacArena] core: No, but we can put a REAME in the source directory, stating that this is a double release and all files contained therein are to be considered as being under BSD license or GPL at the option of the user ...
    [fries] mtorni: if you mention the bsd copyright and that it contains contributions from xxx .. it is ok
    [core] the problem is that - i hope i'm wrong - GPL won't allow you to link to code put under a two-headed license. i can ask RMS.
    [ixx] mentalguy, hmmmmm i think all non-os specific bug fixes should be gpl'd
    [core] macarena: will that work?
    [MenTaLguY] ixx: but what if some BSD folks won't agree?
    [ShadowX] core: that's what perl does (gpl, artistic)
    [ixx] actually there needs to be a pre-license...
    [yazz] I still don't understand why you cannot have like 'either version 2 of the License, or (at your option) any later version' in gpl-copyright notice ''either version 2 of the GPL licence or, (at your option) xxx some nice BSD-like licence here.'?
    [ixx] and all code goes under that
    [core] well, if that works, why not
    [ixx] they must be willing to except the dual license out come
    [bkosse] Erm, how do we get a GGI-card driver to run under Solaris?
    [MacArena] core: It should. GPL would be unusable for anything, if it wouldn't allow to bring out another release ...
    [yazz] bkosse: BSD allows use under solaris...
    [bkosse] No, I'm talking technically here.
    [core] bkosse: we write a solaris-license os-specific part
    [andrew] by two separate sources, we have TWO separate packages (pieces of software). This is different I think from "dual BSD and GPL at user or distributors discretion".
    [mtorni] yazz: gpl is copyrighted - it cannot be modified
    [bkosse] How do we take over the screen?
    [core] macarena: well if that'd work, i guess that's fine
    [ixx] I think it should be gpl or bsd not another os license
    [core] bkosse: there is a framebuffer target
    [ixx] solaris should be fine w/bsd
    [MacArena] bkosse: Solarisx86 has some sort of video driver scheme we can hook into. Ask core about that ...
    [yazz] mtorni: I don't mean we change the GPL licence. Just the copyright notice at the top of our source files. It was such a notice i copied.
    [MenTaLguY] BSD should be fine for all other OSes but Linux
    [core] bkosse: for now, the goal is more to get solaris to display its own X server on KGI drivers rather than its builtin display drivers; it isn't too hard from what i could see yet
    [MenTaLguY] so provided we get BSD and GPL both covered somehow, we should be okay.
    [core] bkosse: basically we just have to write a solaris display-driver which is actually a KGI front-end
    [fries] core: however, they would want to have proprietary access (nda) access to video drivers and either not rely on our implementation of kgi or be able to develop their own drivers
    [bkosse] Well, see, I think you just solved your problem.
    [core] ie. solaris display driver calls will be transformed into KGI calls which will call the driver
    [core] freies: i have the proprietary stuff handy.
    [core] freies: sun have released their drivers specs publicly now anyway
    [MenTaLguY] This stuff is giving me a headache. I'm going to go get something to eat.
    * MenTaLguY is away (food)
    [mtorni] My common sense would say that double-licensing would be a legal problem.
    [core] s/frei/fri/
    [bkosse] It does mean more coding for us, but it allows everything to work.
    [core] mtorni: that's what i think too, but...
    [fries] core: for the latest gui cards and everything?
    [Jajcus] What about just adding solaris driver target in libGGI?
    [yazz] mtorni: I don't understand why. The GPL itself is dual-licensed 'or at your option any later version'
    [core] jajcus: yes, that's the _other_ end of the chain
    [core] jajcus: that goes to the framebuffer subsystem of solaris
    [MacArena] Jaj: It's there. Via X and via /dev/fb
    [core] fries: they don't release the source of their own drivers (except a couple of examples),
    [fries] jajcus someone told me they were working on opening /dev/fb and writing ..
    [core] fries: but you have the specs, and can work out one from examples.
    [fries] MacArena: X uses a fb, but no ggi graphics apps can use that
    [core] fries: sure they can
    [fries] core: if they use X display target
    [mtorni] yazz: but gpl's "licenses" are compatible
    [core] fries: no, of course. but if they use solaris fb target, they do
    [fries] core there are libggi fb targets?
    [core] fries: yes.
    [fries] core: doit! I am missing out!
    [MacArena] fries/core : I have some patches lying around for better Solaris support. Will commit ASAP.
    [core] fries: there's a patch somewhere in beta-stage, i'll merge it sometime soon if i can maintain and improve it on my slowaris box
    [fries] core: I have bwtw0, cgsix0, cgeight0, cgrdi0 .. for testing and I didn't even know it was in there
    [bkosse] Solaris supports module-type drivers, right?
    [core] macarena: great!
    [core] fries: woop :)
    [fries] Macarena solaris fb suppport and OpenBSD/sparc fb support should be identical
    [yazz] Ok, what about this: We include at the top of every file a notice that says that the licence text is in $buildroot/LICENCE. Then we make two distributions, one with LICENCE==GPl, one with LICENCE==BSD
    [core] bkosse: yes, most of the kernel is like that
    [fries] Yazz can we do that?
    [core] yazz: that's a possibility, but i think we'll simply go for a header saying "GPL or BSD" thing.
    [mtorni] consider this license "If you want, this specific piece of software can be sold. But if you don't like that, then it's not sellable."
    [yazz] fries: I suppose so. IANAL
    [bkosse] OK, so the simplest way to deal with this is to make the "card interface" part of the "kernel stuff". You can link GPL into propriatary stuff.
    [ixx] gota go eat. I think that a GGI license is the only way.... that allows the use of GPL or BSD depending on OS. maybe use the license of the OS if its "free" else use BSD.
    [ixx] bbl
    [bkosse] The only difference is that the BSD guys will have to go build their own interface.
    [bkosse] Either that, or they can build modules.
    [yazz] Another problem is that whatever licence we choose everyone contributiong must 'like' that and licence their code under the same licence(s)
    [ixx] What about just something like the Debian license guidlines.... choose a free license... maybe it could be used.
    [mtorni] on the other hand we can take the current approach; every OS vendor does their own device drivers...
    [yazz] ixx: Better just choose 2 licences that are ok.
    [yazz] mtorni: What do we need kgi for then?
    [bkosse] mtorni: the problem we are trying to solve is that card vendors don't write drivers for many OS's.
    [mtorni] yazz: kgi is an optimization :)
    [andrew] I think the idea of a driver as "one piece of software under two licenses" won't work. I'm convinced two _separate_ versions of a driver, one under GPL and the other under BSDish (i.e. TWO pieces of software) will. /me will shut up now :)
    [fries] kgi is an interface?
    [yazz] mtorni: If sun writes the drivers? i doubt so.
    [mtorni] yazz: kgi is an optimizati, and "The Right Thing To Do", it avoids suid-root binaries.
    * Mat is lost
    [bkosse] fries: somewhat. There was talk about using KGI drivers on any OS which supported it. That's why we're having this problem.
    [yazz] mtorni: Is sun-X binaries suid? don't they have a /dev/fb?
    [mtorni] yazz: you (we?) aren't using sun.
    [fries] bkosse talk? I thought the kgi drivers would link into any os? or just that the same src would compile on any os
    [mtorni] yazz: it's basically linux we're trying to fix, right?
    [fries] Yazz: sun X uses /dev/fb w/out being suid
    [yazz] fries: Yeah, i thougt so...
    [yazz] mtorni: Yes.
    [bkosse] fries: the KGI video card drivers were going to be able to run on any OS (or at least compile onto any OS so as to deal with endian issues).
    [mtorni] yazz: so why say "it ain't a sun problem"?
    [MacArena] mtorni - but not only ...
    [mtorni] does anyone know how bad(?) sun /dev/fb is?
    [yazz] I think someone should ask RMS about the dual licensing issues. I think one source + 2 licences is possible. We (ie. the copyright-holders) can do whatever we please with our code.
    [mtorni] if it has even some resemblance to kgi, cannot libGGI just cover up the differences between the two?
    [MacArena] mtorni: depends. On their native HW it is quite good. However driver base lacks for Solarisx86 ...
    [mtorni] it would mean a lot of saved effort...
    [MacArena] mtorni: It already does.
    [yazz] mtorni: A friend of mine has done a libggi target for sun /dev/fb already.
    [bkosse] However, if we were to develop an interface that a card manufacturer could write to, then we gain substantial bonuses.
    [MacArena] LibGGI runs fine on sun'S FB device.
    [Silk] bkosse: afaik isn't that what's already happening with the permedia drivers?
    [bkosse] So, the thing to do, IMO, is to make the driver handle the interface to the card drivers.
    [mtorni] so let's leave sun out of this, ok?
    [bkosse] Silk: mostly, yes.
    [MacArena] The problem is: We _have_ to link the card part to some OS glue layer. And if it is only to have the modul_init() or whatever the OS in question wants.
    [MacArena] Now if this linking poses a licensing problem, then lawyers are weird. Conclusion : Lawyers are weird ...
    [mtorni] isn't PD really linkable to the linux kernel?
    [Silk] MacArena: thus, the question isn't how the driver is licensed, but how the interface to the driver is licensed?
    [bkosse] That layer should be quite small. Rewriting it per OS isn't that big of a deal (in fact, couldn't we create a public module_init() function within the driver?)
    [yazz] MacArena: As i see there are two solutions. two trees + two licences or (maybe) 1 tree and two licences.
    [fries] you can compile anything and link it with the linux kernel.
    [MacArena] I think we should postpone this discussion, as it doesn't seem to lead to anything... we should check with some people with experience in that field (bruce ? eric ? Richard ? ...) O.K. ?
    [andrew] righteo
    [vertigo] thats maybe the wisest decision
    [mtorni] MacArena: I think this is quite interesting :)
    [ShadowX] yes
    [yazz] MacArena: I agree. WANL (We Are Not Lawyers)
    [fries] mtorni: but quite circular
    [bkosse] Just to recap: drivers are whatever and LibGGI is *L*GPL, right?
    [Mat] Sure. It would be nice to have a summary of what's been decided and what remains too... Just for us lost people
    [yazz] bkosse: YES½
    [mtorni] fries: the time has to be spent somewhere?-)
    [bkosse] the kernel level in Linux is GPL, and we're just screwed tryign to figure out this card interface layer.
    [mtorni] fries: isn't code-debug-run-code-debug-run-code... quite a cycle, too?-)
    [MacArena] Yep. And #include and demo-code/stubs are BSD minus credits ...
    [bkosse] phew. that was a small mess.
    [Mat] still is :)
    [yazz] MacArena: what "#include"? libggi or kgi?
    [bkosse] Hey, we got 4 of the 5 figured out.... :)
    [MacArena] O.K. - next topic ... what is on schedule still ?

    All topics covered (19:38 GMT)
    [mtorni] how about a break again?
    [Mat] is there anything left ?
    [bkosse] Erm, is SetOrigin guaranteed to work on any platform (with the exception of aalib possibly)?
    [andrew] yep, all
    [MacArena] bkosse: Nothing is guaranteed to work on any platform. Check returncodes ...
    [bkosse] OK, let me try this again: "should it work on all platforms"
    [fries] yes.
    [fries] that is the goal I would hope.
    [MacArena] bkosse: If technically possible - yes.
    [andrew] bkosse: so long as setmode with virt ] vis succeeded.
    [Mat] We can even find platforms where it's guaranteed nothing will work !
    [MacArena] mat: FridgeOS 1.0 ?
    [bkosse] Should one be able to copy from one part of the virt to another on all platforms?
    [MacArena] bkosse: as long as the visuals are readable ...
    [Mat] MacArena: dunno, I didn't try it yet :)
    [mtorni] MacArena: fridgeos supports origins...
    [bkosse] MacArena: which ones don't have readable visuals?
    [MacArena] Mat: YOu have tried it. It is what turn the light inside on and off ...
    [MacArena] bkosse: display-printer-bjc4000 e.g.
    [bkosse] Well, geeze, trying to play a game on a printer would be tough.
    [fries] bkosse: use alot of paper
    [mtorni] how are printers going to be implemented? They have quite a resolution...
    [bkosse] No kidding.
    [Mat] How many fps do you get on such a thing anyway ? :)
    [andrew] 0.0000001 :)
    [MacArena] bkosse: It all boils down to: Everything should work everywhere. But in case it doesn't, you should expect that ...
    [mtorni] Mat: my laser puts out 6fpm :)
    [MacArena] Mat: around 0.1 for MY LJ 5MP.
    [bkosse] That's .1 fps, mtorni
    [mtorni] bkosse: hey, I can count myself.
    [mtorni] that's not too bad... I have tried running quake test release on my 486 :)
    [fries] MacArena: at the printer around the corner from my cubicle 25 fpm
    [bkosse] OK, MacArena. I'm trying to make sure I don't do something which will break on relatively common systems. It looks like my plan will work OK.
    [MacArena] For better performance I'd recommend the 4SI which will go to 0.2 fps
    [bkosse] Hehehe.
    [mtorni] ggiSpitOutPaper()?
    [Mat] I can just see an article "Doom port" on comp.hardware.printers.laserjet :)
    [MacArena] Yeah - I'll have to go soon, too ... Important things left ?
    [Mat] Yeah, who pays my phone bill ? :)
    [mtorni] Doom port for a laser's LCD wouldn't be bad.. =)

    End of formal session (19:44 GMT)