/*\
|*| This probably needs to be edited.
\*/


-:- Starting logfile ggi_meeting_980920.log
IRC log started Sun Sep 20 23:47:20 1998
-:- Value of LOG set to ON
<core> andy- before we start the meeting, do you agree to call for a new webmaster officially? looks like meadors has been abducted by aliens or by directX weenies :)
-:- mars [[email protected]] has joined #ggi
<mars> Morning
<core> hey mr. mars :)
<ShadowX> I'm interested.  School work -- can't hack GGI code as much as before.
-:- xer^jly [[email protected]] has joined #ggi
-:- mode/#ggi [+o mars] by core
<Macarena> DOn't know. If he ain't reachable any more, we should at least place a temporary new one ...
<Macarena> Hi Stefan !
<core> macarena: yeah.. i'm not too good at web design (to be nice with myself :)
<core> shadowx: it'll require constant attention though.. following the ML and updating the site accordingly (ie. what willie did fine)
<ShadowX> core: I'm a HTML 'purist' who validates all HTML and makes it totally correct, so...
<mars> That's what I say about myself too Core. But still people tell me otherwise :)
<core> shadowx: you'll probably have an heart attack at the pages :)
<core> mars: um, your pages are like, viewable, as opposed to mine ;)
<mars> core: You have one?
<Macarena> Hmm - so seems we already have two volunteers .-)
-:- SignOff xer^jly: #ggi (xer^jly has no reason)
<ShadowX> core: sure, I have to read it the ML anyway
<core> mars: yup, always did, http://www.core.netnation.org :)
<core> macarena: who's the other? :)
<Macarena> core: Shadowx and mars I suppose :-) They said they can do HTML :-)
-:- tan [[email protected]] has joined #ggi
<tan> hi
<core> macarena: oh, right.. i logged that too, so they can't deny it
<ShadowX> Hello
<core> hi mr. tanner
-:- mode/#ggi [+o tan] by core
<ShadowX> core: heh.
<mars> macarena: Oh no.. give it to ShadowX
-:- xer^jly [[email protected]] has joined #ggi
<core> see, he's backpedaling away already ;)
<ShadowX> mars: why
<Macarena> Hi Thomas
* core/#ggi likes the BPS (backpedals per second) measurement system :)
<ShadowX> can't we have two (tmp) webmaster
<mars> shadowx: So that I don't have to, that's why :)
<ShadowX> ok, never mind
<ShadowX> core: unfortunately on some bikes if you backpedal it won't go backwards!
<core> stefan, how's the ggi today going? :)
<core> shadowx: tell Steffen about it :)
<mars> core: I am reworking it, has run into a bit of a problem with the db though. It will get back up though
* Adamel/#ggi is back
<core> mars: okay.. i have delinked it from the main website in the meantime, to reduce the frustration of dead links :)
<Adamel> Hi people!
<core> hey marcus :)
<Macarena> Hi Marcus !
<Adamel> Right on time I believe ;)
<ShadowX> core, macarena: ok, how do I get started?
<core> adamel: yup, perfect timing
<ShadowX> hello
-:- core has changed the topic on channel #ggi to: H +0.3 ns
-:- SignOff xer^jly: #ggi (xer^jly has no reason)
<andrew> okidoke
-:- xer^jly [[email protected]] has joined #ggi
<core> okay .. shall we start? most 'core' people are here i guess :P
<Macarena> What's with Steffen ?
<xer^jly> i hate it when the power goes down.. =)
<core> oi - yeah, steffen and jason should be talking about their work today.. hmm
-:- mod [[email protected]] has joined #ggi
<ShadowX> core, macarena: ok, how do I get started?
<Macarena> xer^jly == wouter ??
<core> i don't think so :/ I PMed wouter, didn't get any reply
<Macarena> Shaowx for the webjob ?
<ShadowX> yeah
<core> shadowx: i'll make it so that you can just cvs commit pages, if andy is ok
<xer^jly> anybody logging this?
<core> xer: yeah, 'degas' is, if noone else
<Macarena> core: O.K.
<core> shadowx: i'll make a repository for the site or something; i'll give you access together with andy
<core> then ideally the mirrors would update from it too.
-:- BitchX+Deb1an: Now logging messages to: /home/pauld/.BitchX/BitchX.away
� Fatal is away: (Auto-Away after 10 mins) [BX-MsgLog On]
-:- You have been marked as being away.
<Macarena> core: o.k. so we have a fallback in case shadowx disappears :-)
<core> heheh, yeah, maybe someone is abducting our webmasters :)
<Macarena> core: Yeah ... M$
<ShadowX> who knows, someday I might die from a car crash and you never know
<ShadowX> no one here knows computers or linux
<core> macarena: yeah, they must be trying to get all information from chris for their NT5 drivers as we type this :)
<core> well, someone good at electronics (*looks at andy*) make some device we can connect to you, that informs us of your health ;)
<Macarena> core: Probably using chinese water torture. Theys once tried on me, but I just kept explaining the rules of cricket to them .-). I won.
<core> you just need a cap with a small satellite dish on top of it that'll transmit info to us every ten seconds
<mars> core: Such devices already exist. Are expensive though
<core> macarena: look at what you've done! NT4 is so unstable now!
<core> :)
<Macarena> mars: SHould we ask NASA ?
<mars> macarena: *chuckles*
<Macarena> O.K. - shall we get serious ?
<core> i'll put the webpages in cvs early this week.. they used to checkout from steffen's box anyway.
-:- SignOff der_fisch: #ggi (Remote closed. [0kb/12pks(0q)] [16kb/207pks(0q)])
* core/#ggi puts the serious hat on
-:- Macarena has changed the topic on channel #ggi to: Ouch - the Licensing thing ...
<ShadowX> Ok, what's the stuff that needs to be updated?  The Who-is-who list, FAQ,news, docs...
<ShadowX> what is considered 'news' ?
<core> shadowx: basically everything.. :)
* Macarena/#ggi takes off the silly fools hat he's been waering ...
<ShadowX> would you call 'display-tele' target committed news?
>>> xer^jly [[email protected]] requested PING 906300769 404288 from #ggi
<andrew> shadowx: not really
<mars> shadowx: Yes
<core> shadowx: not something to make the front page, but mentioning it in a whole batch of news would be good i suppose
<core> well, for licensing, we seem to have pretty much agreed, didn't we?
<ShadowX> core: I suggest just a vote
<ShadowX> we had enough discussion already
* ShadowX/#ggi really tires of it
<core> gpl license for linux kgi/drivers, two-clause bsd license for *bsg kgi/drivers (etc), libggi under lgpl
-:- ernie [[email protected]] has joined #ggi
<Macarena> O.K. - that's how it stands.
<core> shadowx: we all are. i'm just mentioning that apparently, i got no "no, because my neighbor uses gcc on bsd" type of reply
<xer^jly> Macarena: no, i'm not wouter...
<ShadowX> core: i suppose there is a difference betwwen linux kgi and bsd kgi?
<ShadowX> I mean they use different code?
<core> shadowx: yes, as kgi is the os-specific part :)
<Macarena> xer: Pity - I'd have liked him here ...
<core> shadowx: uh-uh. that's what interfaces the drivers with the underlying os/console/whatno
<core> s/whatno/whatnot/
<Adamel> Does anyone know if we need to have both BSD or GPL for the drivers, or if BSD is enough?
<core> next step is to change the license headers on all files and make sure they are legal?
-:- SignOff mod: #ggi (ircII2.8.2-EPIC3.004 --- Bloatware at its finest.)
<core> adamel: you need GPL too, as you can't statically link BSD code with the linux GPL kernel
<Macarena> From all I know, 2-clause BSD is sublicenseable to GPL.
<ShadowX> that's what I think (marcus), just sublicense GPL from BSD (2-clause) drivers
<ShadowX> that is allowed
<Macarena> I suggest simply using the X license, which is more or less that.
<Adamel> core: I know, I was thinking of sublicensing the BSD code.
<core> macarena: right
<ShadowX> Yes, lessen confusion.
<core> adamel: yes, sorry, what i meant too.
<Macarena> O.K. - so here we go for a vote ... are all o.k. with :
<ShadowX> If you call it BSD you will have people flaming GGI because they chose some advertisement clause (though they never have actually read the license)
<Macarena> 1. KGI drivers take copyright at authors discretion. Our own drivers should be X-licensed
<ShadowX> Yes
<Adamel> Agreed
<andrew> yes
<core> agreed.
<mars> Yes
<core> my drivers will conform to whatever license we use, which seems to be X.
<Macarena> 2. KGI-to-kernel glue layers take a license as appropriate for the host OS. If this defeats the use of some KGI drivers - tough luck for that OS.
* ShadowX/#ggi notes that this is big news :-)
<tan> yes
<mars> Yes
<ShadowX> yes
<core> yes
<andrew> ok
<Adamel> yes
<Macarena> 3. LibGGI stays LGPL, except if we could all agree to put it under X license, too
<mars> Yes
<ShadowX> X license is OK with me, though I prefer LGPL
<Adamel> ok
<tan> lgpl
<ShadowX> That's a yes.
<andrew> LGPL
<core> i haven't contributed much code to libggi, so i agree to follow any license you'll use
<Macarena> O.K. - I have seen no NOs, so we should record, that it has been decided to use:
* ShadowX/#ggi whispers to core: am I being log-summariser today again?  you have logs right?
<Macarena> 1. X license for KGI drivers or others at the authors discretion, but those might need to be distributed separately, then.
<core> (shadowx: if you don't mind, yes. i'll email you the log as usual)
<Macarena> 2. OS-KGI glue layers take a license as appropriate for the OS.
<Macarena> 3. LibGGI stays LGPL.
<Adamel> Yes.
<ShadowX> Yes
<tan> yes
<core> agreed on all. phew.
<andrew> Yep
<Adamel> Common KGI headers will be X licensed too, right?
<core> oh yeah. headers. public domain?
<Macarena> And maybe (forgot that) other Libs: At authors discretion, X preferred - o.k. ?
<core> ok
<mars> Thank god the license argument finally settles.. :)
<andrew> which libs?
<core> andrew: libggi[2D/3D], libgwt.. i assume
<andrew> ah, ok
<Macarena> andrew: Anything one might want to add on - see what core suggest for examples
<core> do we all agree to put headers, makefiles, makerules, and scripts, as public domain ?
<Macarena> yes
<tan> core: yes
<ShadowX> fine.
<andrew> ok
<ShadowX> I say demos should be put into public domain too because someone might use it to code a proprietory game...
-:- Macarena has changed the topic on channel #ggi to: Phew - licensing thing seems settled ...
<ShadowX> I mean libggi demos
<core> okay, so this is finally settled. naysayers will have to fork or do something else, although i believe everyone will follow.
<mars> I suggest demos license is decided by their respective author
<core> shadowx: that's author's discretion i believe. i have no problem putting warp in PD.
<Adamel> core: Sure, except ones that are already copyrighted ofcourse (degas/config/scripts/install for example)
<ShadowX> ok.
<core> mars: agreed
<Macarena> shadowx: yes. My parts may be PD.
<core> okay, so next step is to change all headers
* xer^jly/#ggi is away: (Auto-Away after 10 mins) [BX-MsgLog On]
<core> i assume KGI drivers authors will change theirs, who will take care of libggi (it seems we miss a paragraph) ?
<Macarena> Yes - who will do the "legwork" ?
<Adamel> What to do with all the "Copyright by GGI project" files?
<core> (and makefiles/scripts ?)
* xer^jly/#ggi is back from the dead. Gone 0 hrs 0 min 18 secs
<core> yes, GGI cannot hold a copyright, we don't exist.
<core> that must be transferred to a physical person in every case.
<ShadowX> I think just copyright it as maintainer
<ShadowX> hopefully nobody would object ?
<Adamel> Most of them doesn't have a maintainer...
<Macarena> put it back to the authors, if they can be found, if not, put someone in ... (--- delete this from the records --- this may be illegal :-)
<core> i believe we can make all uncopyrighted parts, (c) andreas beck
<ShadowX> you have to do actual paperwork to transfer copyright, I believe.
<core> (uncopyrighted as only copyrighted by ggi)
<core> well, (c) ggi is invalid.
<tan> (c) copyright by joe smith :)
------------------------------------------------
| tan ([email protected]) (Germany)
| ircname  : *Unknown*
| channels : @#ggi
| server   : irc.ggi-project.org (The GGI project aircd server)
| idle     : 0 hours 0 mins 11 secs (signon: Mon Sep 21 00:02:09 1998)
<ShadowX> Could we leave it out?  Copyright is automatic in any work, so...
<core> heh, no, there might be some joe smith who will change all of our licenses then :P
<Macarena> tan: This is Jon Doe  I believe ...
<core> well, most files have a maintainer or copyright to both ggi and someone else. just get rid of the ggi. else (c) 'it to andy. is that ok?
<andrew> core: OK with me
<ShadowX> that is fine.
<core> andy as in someone who can speak for all of us.
<Adamel> fine with me
<tan> ok
<core> okay, then we'll do that. now who will be lucky to change all libggi headers ?
<core> :)
<Macarena> o.k. ... hope not too many complaints about what s***ing code I have written come in :-)
<core> macarena: we all trust you to uphold the copyrights, hence the suggestion :)
<ShadowX> If someone decides to maintain an unmaintained file, just change the copyright..
<core> someone said that our source headers aren't valid, we miss a paragraph of sorts
<core> no, you can't transfer the copyright once set just like that. anyway, all 'uncopyrighted' files are small pieces, i don't really care who owns them
<Adamel> core: That was some of the GPLed parts I believe.
<core> it's things as mission-critical as debug.c i believe ;)
<core> adamel: yes. that doesn't apply to LGPL?
<ShadowX> ok, never mind.
<Adamel> core: yes it does, but I _think_ all libggi headers are valid
<core> adamel: ok.. we need to recheck from the GPL license text that they are though, we can't afford putting out a release with improper copyrights that anyone can rip out :)
* Macarena/#ggi thinks about adding a paragraph, that forbids lawyers to use GGI :-)
* core/#ggi adds one that explicitly allows for mass murder of lawyers using GGI ;)
<Adamel> btw, IMO we should try to standardize the header format of all files in the repostitory. Gives a more proffessional look.
-:- yazz [[email protected]] has joined #ggi
<ShadowX> core: just add the relevent text from LGPL, it already says what to include.
<mars> macarena: Interesting idea :)
<core> adamel: probably. i think the current one is fine, but at least unify them, right
<Macarena> core: But only if all victims are lawyers ...
<core> hey mr. larsson :)
<Macarena> core: never mind :-)
<yazz> Hi!
<ShadowX> hello
<Macarena> Hi !
<Adamel> core: There isn't a current "one". more like current five or so :)
<core> okay, so who wants to take care of checking the validity of source headers, eventually modifying/unifying them, removing all (c) ggi's and replacing them where appropriate ?
<yazz> Ok, i apparantly just missed the licencing. What were the result?
<core> adamel: heheh.. right
<ShadowX> adamel: maybe we should run a pretty printer on the code?  some of it is unreadable..
<core> yazz: we all agreed ;)
<yazz> core: Agreed to agree or what? :)
<tan> shadowx: you mean obfuscator ? ;-)
<ShadowX> andrew's code is the prettiest, all abstract, just I don't agree with his coding style :-)
<Adamel> I suggest that we agree on a header format (I'll make a proposal and make it available via http during the meeting)
<core> yazz: what i posted on the list which was what andy posted a year ago already or so :) KGI drivers use X license (or at authors discretion, preferably X), the kernel glue code uses the appropriate license for the OS, and libggi stays lgpl
<Adamel> Then whenever someone changes a file they change the header and copyright too.
<core> adamel: okay, good
<andrew> shadowx: LOL
<yazz> core: Ok, nice.
<core> doesn't tell me who wants to change all headers tho ;)
<Macarena> O.K. - do we have a volunteer that changes the headers ?
<Macarena> We can split work if desired ...
* Adamel/#ggi cuts and pastes
<Adamel> Then whenever someone changes a file they change the header and copyright too.
<core> well, KGI drivers will be changed by their authors (or someone, if the driver maintainer has been abducted, like probably half of them). demos, same. kgi targets, same. remains common libggi code
<ShadowX> kgi targets?
<core> s/kgi/libggi/ :)
<core> so, i slept 3 hours ;)
<Macarena> O.K. - to make a start: I'll take care of the demos. Most are by me, so I'll put them PD. Are all who contributed to demo.c o.k. to put it PD, too ?
<andrew> maca: yeah
<ShadowX> yes, mine (well, not really, just the initial version) is already
<core> macarena: warp isn't checked in the repository, but i don't mind making it PD, it's not rocket science. want me to check it in?
<Adamel> Not suer if I contributed anything, but sure :)
<Adamel> s/suer/sure
<Macarena> Adamel: Freudian typo ?
<core> i have a version of it using libgbm actually, but libgbm is too buggy :/
<Adamel> Macarena: No ;)
<tan> btw: could be remove the CVS logs from all files?
<Adamel> tan: YES!
<Adamel> Just use $Id: irc-980920-log,v 1.1.1.1 1998/09/25 05:36:29 emarty Exp $
<core> i guess .. we can browse the changes on degas now
<Macarena> tan : Good idea. Or at least strip them down to less than 10 lines every now and then.
<ShadowX> tan, adamel: I guess it will have to be done, but I like CVS logs having historical value
<core> i'll add a 'last changes' thing on degas, although you have a cvs command for that.
<ShadowX> some funny things there :-)
-:- ernie [[email protected]] has left #ggi []
<core> shadowx: cvs still keeps the info - whether you have it in the source itself or not
<core> shadowx: look at cvs commit info for READMEs for example :)
<ShadowX> core: I know, but whenever CVS repos is 'cleaned up' it disappears
<core> shadowx: that only happened once..
<Fatal> cant cvs be set up to auto generate a Changelog file? we should have one in the 'major' directories
<core> shadowx: and we could get the repo from steffen, if he ever replies about that
<core> fatal: cvs isn't a daemon running permanently, it starts as developers connect to it. but i can crontab something like that, yes
<tan> fatal: yes, good idea! it�s GNU standard anyway
-:- ernie [[email protected]] has joined #ggi
<Fatal> core: i mean it generates one as somebody makes the changes
<ShadowX> yes, easier to look at changes
<core> fatal: there's cvs history, but i'll make a Changelog, ok
<Macarena> O.K. - again - who takes the rest of the tree ?
<ShadowX> I thought it was called ChangeLog, but all well
* core/#ggi chants 'marcus, marcus' :)
* andrew/#ggi joins in ;)
<Fatal> yeah ChangeLog :)
* Adamel/#ggi looks behind him to see what Marcus they mean
<core> cvs -d :pserver:[email protected]:/projects/ggi/cvsdevel history -c -a -D "1 day ago" | sort -r > ChangeLog
<core> :)
<xer^jly>
* core/#ggi quickly places a mirror behind Marcus
-:- miri_ [[email protected]] has joined #ggi
<Adamel> core: ;)
<miri_> Hello. Late?
<core> miri: 45 minutes, but that's ok :)
<Macarena> Hi Miri ... Nor very late ...
<Macarena> s/nor/not/
<core> (okay, so it doesn't look like a ChangeLog, but i'll perlitize it :)
<tan> another idea: currently all target drivers are in libggi/display. If I want to write a libggi2d driver for e.g X I need to share some data between the two drivers (X-window etc.) Could we move all target drivers to a /target ...
<tan> directory so that the files for a target are not splitted over the whole repository?
<core> (i assume you all know about cvs diff -u too :)
<ShadowX> that makes it difficult to separate them
<Macarena> O.K. - is the following statement o.k. for placing the demos in PD : ?
<Macarena>    This is placed into the public domain.  Use for anything you want.
* ShadowX/#ggi recognizes something there :)
<core> macarena: we need a proper disclaimer too (use at your own risk, don't sue us if it sets your hair on fire, yadda yadda)
<Macarena> Someone got such a disclaimer handy ?
<core> umm.. yeah
<core> want it here?
<ShadowX> I had one on the new libggi docs about killing your cat ;-)
<tan> shadowx: ?? I mean, for example, target/X11, target/X11/libggi, target/X11/libggi2d ...
<Macarena> core: yes - send it along.
<core> okay, brace yourself..
<core>  *   THIS SOFTWARE IS PROVIDED FREE OF CHARGE AND CAN BE USED FREELY
<core>  *   FOR ANY PURPOSE. IT COMES WITHOUT ANY KIND OF WARRANTY, EITHER
<core>  *   EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO THE IMPLIED
<core>  *   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. USE
<core>  *   IT AT YOUR OWN RISK. THE AUTHOR IS NOT RESPONSIBLE FOR ANY DAMAGE OR
<core>  *   CONSEQUENCES RAISED BY USE OR INABILITY TO USE THIS PROGRAM.
<core> is that ok?
<Adamel> "Dealing with this code in any way may cause ANYTHING to happen, if it does we do not take any responsibility in it"
<ShadowX> Just change free of charge to public domain
<mars> ok
<tan> ok
<core> yeah, just change the first sentence to "this software is placed in the public domain" or something.
<core> (in all caps so that deaf lawyears can hear it)
<ShadowX> I hate that! (the caps)
<Macarena> Should I decp it ?
<Macarena> s/decp/decap/
<core> it's supposed to be in caps i think, i'm not sure why
<ShadowX> It ruins our art :-)
<Fatal> what i think is stupid is that if you DONT have this disclaimer at the top of your files then it somehow implies that you WILL take responsiblity for anything the code causes to happen :/
<core> probably some American who sued a company because the warning was in lowercase and not visible enough and won the trial :-)
<Macarena> core: ROTFL
<core> (same as "putting cats in your microwave is AT YOUR OWN RISK" or "objects in mirror are closer than they appear" or "warning, you're going to burn yourself if you drop coffee on your lap" :)
<Macarena> core: Though some american companies are masters of fine print ...
<ShadowX> We're using monospace fonts here, hello!?
<core> macarena: oh, some french ones too, wait and see :-)
<ShadowX> core: I love that coffee one :)
<core> well, if you lowercase it, make sure andy is set as the responsible person ;)
* Macarena/#ggi chuckles
<ShadowX> core: about the mirror one, that is sort of ambiguous, not "objects in mirror" but "objects shown on mirror"
<ShadowX> never quite understood that when I was younger :)
<core> shadowx: ah yeah.. sorry, haven't seen an american car for 3-4 months :)
<Macarena> Shadowx: ROTFL ... you should be a lawyer
<core> anyway, is the fineprint above fine for you andy?
� Fatal is away: (logging rest of meeting while i sleep) [BX-MsgLog On]
-:- You have been marked as being away.
<ShadowX> core: no cars really have the ambiguous phrase above
<core> one will have to change the makefiles and such to use it too.
<Macarena> O.K. - I'll decap it - o.k. ?
<ShadowX> yes!
<core> macarena: umm.. sure ....... :)
<ShadowX> core: i meant cars have that phrase, not no cars :)
<core> shadowx: oh ok. time to sue them then :)
<Macarena> O.K. - is the following o.k. for all :
<Macarena>  * shmdemo.c - (c) 1998 Andreas Beck   [email protected]
<Macarena>  *
<Macarena>  * This is a demonstration of LibGGI's functions and can be used as a
<Macarena>  * reference programming example.
<Macarena>  *
<Macarena>  * Permission is granted to use this source as a reference for your own
<Macarena>  * applications.
<Macarena>  *
<Macarena>  *   This software is placed in the public domain and can be used freely
<Macarena>  *   for any purpose. It comes without any kind of warranty, either
<Macarena>  *   expressed or implied, including, but not limited to the implied
<Macarena>  *   warranties of merchantability or fitness for a particular purpose.
<Macarena>  *   Use it at your own risk. the author is not responsible for any damage
<Macarena>  *   or consequences raised by use or inability to use this program.
<ShadowX> The Permission is granted part implies that there's some other restrictions...
<core> yeah, except i suppose that "by Andreas Beck, 1998" rather than (c) is in order, since it's PD
<Adamel> I don't think we should have any notice in the Makefiles
<Macarena> shadowx: Yes - will remove that one.
<core> adamel: if theren't any already, i guess not
<core> but we have to change headers, still
<xer^jly>
<Adamel> I've already started to remove copyrightnotices from makefiles... (before this meeting)
<core> adamel: yeah, the $id$ you put instead of cvs changes/(c) is better
<core> okay, *dread*, i'll do the libggi common part.
-:- ursetto [[email protected]] has joined #ggi
<ShadowX> hello
<core> hey mr ursetto :)
-:- toddf [[email protected]] has joined #ggi
<ursetto> hi all
<core> hey todd :)
-:- mode/#ggi [+oo ursetto toddf] by core
<ShadowX> ohayo- :)
<tan> hi todd, hi ursetto
<toddf> hey. I can't stay long, must work in a few hours and am not prepared for it. *sigh* .
<core> toddf: sounds familiar
<StevenE> UIUC.  neat.
<toddf> StevenE: that's close to me ..
<core> okay, so i'll take care of libggi common code; becka of the demos; marcus of the headers and makefiles (right? :). KGI drivers will be changed by their authors. what else is remaining?
<ShadowX> I can do targets, if you need.
<core> yeah, since we aren't changing copyright schemes, i suppose you can do them all
<Adamel> core: Sure :)
-:- SignOff Macarena: #ggi (Socket error: Connection reset by peer. [5kb/93pks(0q)] [41kb/455pks(2q)])
<core> adamel: so you only miss to change headers :)
<toddf> hmm, apparently I missed some of the meeting..
<Adamel> Btw, did anyone notice the autoconf stuff in libggi yet?
<ShadowX> really?
<core> adamel: yes, i was freaking out at all the U's :)
<core> adamel: great!
<ShadowX> good! (only I don't know how to use autoconf)
<core> shadowx: really what? :) i mean, we are just checking (c) is ok
<ShadowX> core: I  meant the autoconf stuff
<core> andrew: cool, you replaced all $Log: irc-980920-log,v $
<core> andrew: cool, you replaced all Revision 1.1.1.1  1998/09/25 05:36:29  emarty
<core> andrew: cool, you replaced all Initial checkin
<core> andrew: cool, you replaced all by $Id: irc-980920-log,v 1.1.1.1 1998/09/25 05:36:29 emarty Exp $ in libggi already? thanks
<core> shadowx: oh
<ShadowX> core: but we have to include the correct legalese, no?
<tan> adamel: yes, very good. I�m just learning autoconf/libtool too
<core> shadowx: yes, that's what you should check (and that they aren't (c) the ggi-project, etc)
-:- becka [[email protected]] has joined #ggi
<Adamel> It's not really complete yet, but the old make/config system can be used independently.
-:- becka is now known as Macarena
<Macarena> Sorry - dropped off ... tripped over my own timeout ...
<toddf> adamel: sigh. I guess that's what I get for not spending time maintaining it.
<ShadowX> core:ok, apparently it has been changed, good.
<core> adamel: should we use the header scheme as in lib/libggi/mode.c (ie. Id$ first, then the description ?)
<core> shadowx: yeah, that's what i'm looking at :)
<Macarena> Last two questions were :
<Macarena> > Is nathan strong here ? The stars demo has another 8though acceptable
<Macarena> +Copyright -I'd like to know, if I should change it.
<Macarena> > Andrew: te_demo- o.k. to PD it ?
<xer^jly> BitchX-75p1+ by panasync - Linux 2.1.122
<xer^jly> sorry
<ShadowX> macarena: I love that description on stars.c, keep it for now :)
<andrew> maca: yep, and flying_ggis too
<core> andrew: cool, you replaced all $Log: irc-980920-log,v $
<core> andrew: cool, you replaced all Revision 1.1.1.1  1998/09/25 05:36:29  emarty
<core> andrew: cool, you replaced all Initial checkin
<core> andrew: cool, you replaced all by $Id: irc-980920-log,v 1.1.1.1 1998/09/25 05:36:29 emarty Exp $ in libggi already? thanks
<core> what header scheme should we adopt?
<andrew> core: some (I not sure I did all...)
<core> andrew: i'm checking that, no worries
<Adamel> core, andrew: No, I did a bunch of them for kgicon
<Macarena> Hartmut here ? What about testpattern.c ?
<core> adamel: what scheme should we use?
<core> adamel: granted, there are like, 5
<Adamel> core: http://www.stacken.kth.se/~mackan/ggi/headersuggestion.txt
<core> adamel: ok thanks
<Adamel> If you call me overpedantic I'll take it as a complement ;-)
<core> i think we had enough namecalling this week :-)
<ShadowX> adamel: yes :)
<core> adamel: works for me. i'll update libggi to use them now
<core> macarena: should we move on to discussing the release of libggi/kgicon ?
<core> (while we patch headers :)
<ShadowX> adamel: to make it even more pedantic , it's not complement, but compliment :)
<Macarena> marcus: checkmode.c ?
<Adamel> Macarena: I didn't write that... :)
<Macarena> marcus: Uh - you are in the $Id ... I think Hartmut was that ...
<tan> has anyone read my question about /target ~200 before?
<tan> s/200/200 lines/
<Adamel> target 200 lines ?
<Macarena> Chris here ? dots.c ?
<ShadowX> yeah, but I don't quite agree.
<tan> adamel: the question was whether we can move all display target drivers in directory under /target rather than storing them in libggi/display
<Macarena> Marcus: Findleaks o.k. ?
<ShadowX> macarena: never seen him.
<core> tan: what for?
<Adamel> Macarena: Sure
<Adamel> tan: No, I think they should remain
<tan> core: If I want to write a libggi2d driver for e.g X11, I need to share some data between the drivers (Xwindow etc)
<core> oh, to be pedantic: should we all agree on either using int functioname (param, param) {\n or int functionname (param, param)\n{ :)
<ShadowX> I follow the latter
<Macarena> The latter
<core> doh :)
<andrew> core: the latter
<core> doh! :)
<Adamel> Actually I prefer int\nfunctionname (param, param)\n{
<ursetto> ewwww
<ShadowX> Sometimes for long if blocks I use if(...)\n{ rather than if(...) {\n even
<core> okay, i guess it was a bad question ;-)
<Adamel> Makes the return type more readable
<core> i'm just wondering if we should unify that too..
<core> probably only my code uses {\n :)
<ShadowX> I just think it obscures the function
<Adamel> core: Yes I think we should unify that
<core> adamel: ok.. if we see code that doesn't conform, make it conform
<ShadowX> there used to be a coding-style document (Steffen?) but it's long gone
<core> right, does someone want to write a new coding-style thing?
<tan> this way we would have all system/target dependant stuff in separate directories
<andrew> core: no, leave it to the `developers discretion' :-) [or it'll be on for young and old ;]
<ShadowX> core: I think I got stuff in libggi hackers guide,, but as usual it doesn't get updated :-(
<Adamel> tan: What we should do is move all target-specific headers to libggi/include/ggi/internal/<targetname> (and libggi/include/*.h to libggi/include/ggi/internal/*.h as that's how it is installed)
-:- SignOff hvr: #ggi (BitchX-75 -- just do it.)
<core> okay - what about the real release of libggi 2.0 and kgicon (all of that being "Degas", I assume) ?
<Adamel> core: I would do fine if we used the same coding style as the Linux kernel.
<core> if you're all ok to talk about that while we patch headers around :)
<ShadowX> adamel: agree
<core> adamel: yeah.. or at least if we used just one :)
<ShadowX> adamel: plug--> K&R rules :)
<Macarena> O.K. commiting newly headered demos ...
<Macarena> On to next topic ?
<core> macarena: if you don't mind :)
<core> an hour and half on licenses is fine ;)
<Macarena> We are actually already there : LibGGI-set-in-stone topics.
<Macarena> There are 2 points form my side : LibGII integration and DB structs
<Adamel> And Andrews key event scheme
<core> ok, so we are talking on what is left before we can label libggi "2.0", and release it for public view, knowing we won't change the external API, correct ?
<Macarena> core: yep.
<Macarena> adamel: What scheme ?
<andrew> macarena: changing the modifiers a bit
<Adamel> Some changes with regard to modifiers.
<Macarena> a/a: Is it on the list ?
<andrew> maca: 2-3 weeks ago iirc
* ShadowX/#ggi bangs his head, can't remember
<Macarena> andrew: probably missed that in the 1600 mails ... Topic ? will look it up in the archives.
* ursetto/#ggi  (Auto-Away after 10 mins) [BX-MsgLog On]
<andrew> macarena: :) the main thing I think was fixing the SHIFT,SHIFTL,SHIFTR and CTRL,CTRLL,CTRLR mess
<core> who wrote patchlib.c already? marcus?
<Adamel> core: yes
<core> ok, i'll just add an header stating (c) by you then, there is none :)
* xer^jly/#ggi is away: (Auto-Away after 10 mins) [BX-MsgLog On]
<ShadowX> sorry what does it do, never looked at it
<Adamel> ShadowX: it changes the path to libggi.conf in a binary libggi.so
<andrew> macarena: topic was `Re: Keyboard.h changes'
<Macarena> a/a: I'll look it up. Let's start with DB first, as I think we can have a quick agreement here.
<Adamel> ShadowX: Nice little hack Andy and I came up with IIRC ;)
<andrew> macarena: (august BTW)
<core> i knew marcus wrote it, and it's easy to figure out, from the return type above the function name ;)
<Adamel> Short license question: Is this what we mean by the X license:Permission is hereby granted, free of charge, to any person obtaining a copy
<Adamel> of this software and associated documentation files (the "Software"), to deal
<Adamel> in the Software without restriction, including without limitation the rights
<Adamel> to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
<Adamel> copies of the Software, and to permit persons to whom the Software is
<Adamel> furnished to do so, subject to the following conditions:
<Adamel> The above copyright notice and this permission notice shall be included in
<Adamel> all copies or substantial portions of the Software.
<Adamel> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
<Adamel> IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
<Adamel> FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
<Adamel> GGI PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
<Adamel> AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
<Adamel> CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
<ShadowX> yes
<Macarena> s/GGI PROJECT/the respective copyright holder
<ShadowX> but do we use the:
<ShadowX> Except as contained in this notice, the name of the X Consortium shall not be
<ShadowX> used in advertising or otherwise to promote the sale, use or other dealings in
<ShadowX> this Software without prior written authorization from the X Consortium.
* xer^jly/#ggi is back from the dead. Gone 0 hrs 3 min 51 secs
<ShadowX> ?
<andrew> shadowx: ROFL
<Adamel> ShadowX: I think we should skip that part...
-:- tomaasz [[email protected]] has joined #ggi
<ShadowX> Just the opposite of BSD :)
<core> adamel: there is no such thing as "the ggi project" though
<Adamel> Macarena: I suggest we just write "THE AUTHOR(S)"
<core> yeah, what marcus says :)
<Adamel> ping? ;)
<core> pong :)
<ShadowX> pong.
* ShadowX/#ggi oh, duplicated ppackets!
<mars> Sorry for being silent, has been in a _long_ conversation over phone, and now I've got to leave :( Party on though dudes, and send a magic log my way will ya?
<core> hehehe
<core> mars: i'll make it available from the site, yes :)
-:- SignOff mars: #ggi (Leaving)
* ShadowX/#ggi too late to say goodbye
<core> okay, all changes to libggi base files commited.
-:- der_fisch [[email protected]] has joined #ggi
<Macarena> Could someone OP me ?
<core> macarena: oops..
!irc.ggi-project.org!! Operator core sets mode: +o Macarena on #ggi
-:- ServerMode/#ggi [+o Macarena] by irc.ggi-project.org
-:- mode/#ggi [-o Macarena] by degas
<core> doh
-:- mode/#ggi [+o Macarena] by core
<core> stupid bot :)
<Adamel> Hmm, one more license issue... Parts of the svgalib wrapper is copied from SVGAlib. Anyone knows what license SVGAlib is under ???
<Macarena> core: *grin*
<ShadowX> it's not GPL, some BSD/X like
-:- Macarena has changed the topic on channel #ggi to: Setting LibGGI API in stone ... DirectBuffer
<Adamel> IIRC I didn't find any license in the SVGAlib sources...
<ShadowX> The debian has it...
<ShadowX> something like.
<ShadowX> This library is free software; you can redistribute it and/or
<ShadowX> modify it without any restrictions. This library is distributed
<ShadowX> in the hope that it will be useful, but without any warranty.
<ShadowX> don't even know if it's valid...
<ShadowX> There's something from XFree86 as well
<core> shadowx: that's LGPL.
<toddf> core: no its not
<Macarena> Adamel: Shall we sort that BD thing out ?
<toddf> core: not unless it says specifically
<Macarena> s/BD/DB/
<toddf> core: LGPL places more restrictions
<Adamel> Macarena: Yes, sure
<core> toddf: i mean, that looks like an excerpt from it :)
<toddf> exerpt, maybe
<Macarena> O.K. - in your mail we agree quit -right ? The remaining points :
<ShadowX> core: that's true, but not the whole license at all
<Macarena> BM_BIT allows for up to 256 bits. It is not a mask, but the bitnumber. Should suffice - right ?
<Macarena> I like your idea of having both descriptors. Simple things shown easily, complex ones more complex.
<Adamel> Macarena: BM_BIT: Yeah, thinko on my side :)
<andrew> maca: yeah, both would be good
<Macarena> Adamel: Maybe we should even add the shift for even easier access ?
<Macarena> Adamel: for the "REVERSE-endian" thing :
<Adamel> Macarena: Yes that's a good idea. The color-generic library already has the shifts, so we might as well put them in the pixelformat amd make them public.
<andrew> macarena: yeah, a shift would also be good
<Macarena> Adamel: the old scheme easily allowed for a completely generic swapping algorithm - just go through the bits and swap bytes, words, dwords etc as required. I think we should have a separate entry for that, so flags are free for the really weird things like
<Macarena> HM mode
-:- SignOff tomaasz: #ggi (Leaving)
<Macarena> Adamel: And for the alignment:
* xer^jly/#ggi is away: (bbl) [BX-MsgLog On]
<toddf> Macarena: on the XFree lists they are recently talking about macros for accessing memory of video cards to swap endian-ness if necessary because there are 'reverse' endian machines with pci busses that have graphics cards that don't have endian flipping
<toddf> capability
<andrew> toddf: similiar talks on linux-m68k
<Adamel> toddf: Actually libggi already has some macros for bit/byte swapping
<toddf> which reminds me ... do we have someone working on a kgicon X driver now that XFree 4.0 is going to have entirely loadable hw modules?
<Macarena> Adamel: The alignment is _very_ important e.g. for the alpha. You have to access the PCI memory differently, if you want to access in a non-32bit manner.
<toddf> there is an fbcon developer in XFree but I don't think that's the same..
<Adamel> Macarena: How about a swap entry with flags like: SWAP_2BIT, SWAP_4BIT, SWAP_BYTES, SWAP_WORDS?
-:- SignOff Macarena: #ggi (Socket error: Connection reset by peer. [2kb/43pks(0q)] [20kb/225pks(0q)])
<Adamel> oops...
<ShadowX> core: i should start working on web site now. where do i get it?
<Adamel> core: reminds me, did you get my PM about updating the mirrors?
<andrew> adamel: the swap field was more generic (each bit is 2^bitnum groups to swap)
-:- Macarena [[email protected]] has joined #ggi
-:- mode/#ggi [+o Macarena] by core
<Macarena> ARGH ! don't be so quiet :-) ...
<core> adamel: yes, i did, thanks, i updated the stupid ftp site, and it'll be in cvs soon :)
<Macarena> Last quote: > Adamel: If the application tries to access these areas in a
<Macarena> +non-32-bit-aligned manner, you get a SIGBUS.
<core> shadowx: you can download from the ftp site, else i'll send a tarball. graphic improvement could be nice too :)
<core> macarena: my alpha (21064A) will sigbus if it's not 64-bit aligned i believe :)
<ShadowX> core: afraid not good with graphics, at least not those :-(
* ShadowX/#ggi downloads now
<core> i mean, looking OK at least ;)
<Adamel> Macarena: I know the Alpha has alignment restrictions, but isn't that a CPU issue, not a gfx hardware issue.
<Macarena> core: PCI is 32 bit - I suppose they tricked around that somehow ...
<core> macarena: hmm, i thought they just spaced all registers every 64-bit
<core> boundary
<Adamel> andrew: (swap entry) Ok, I never really understood how it was laid out, but that sounds ok
<core> i know the 21264 doesn't have this problem anymore, but mine is like, old.
<core> probably a raid in the pcibios 'emulation' of linux-alpha kernel should be good :)
<Macarena> Adamel: well - yes, but we should tell the application. On some architectures it depends on the backend it is using.
<ShadowX> core: sending a tarball is easier, I have only a poor 28.8 modem :-(  can you?
<core> shadowx: okay, just let me finish my headers :)
<Adamel> Macarena: Ok, the question then is how should we lay this entry out?
<Macarena> Adamel: The old one was quite as the swap-entry : Bit x on says, that access at 2^x byte boundaries is o.k.
* xer^jly/#ggi is back from the dead. Gone 0 hrs 12 min 11 secs
<Macarena> Adamel: That o.k. ? Just another int ?
<andrew> macarena: ok with me, so long as we put `if (swap != XXX && align != YYY) return GGI_DL_ERROR' in the visual.c of all the generic-linear-* libraries
<Macarena> Now for the "hard part" ... Andrew - give me a hand here ... the "enum" thingy ...
<Adamel> Macarena: That doesn't look flexible enough to me. If we have such an entry it should cover everything. Suppose 32-bit and 64-bit ints must be aligned on a 32-bit boundary, but 16-bit ints can be aligned on a 8-bit boundary?
<Macarena> andrew: yeah - we should do that.
<andrew> macarena: the hard part will be writing all the non-generic-linear-* libraries :-)
<Macarena> Adamel: Hmm - yes ... I had though about that, but I couldn't imagine who could be so sick to build something like that ...
<Macarena> Adamel: We could make an array, then ...
<andrew> macarena: please, no array
<Adamel> You're probably right... How about: bit 0 means bytes must be 8-bit aligned, bit 1 means 16-bit ints must be 16-bit aligned, etc...
<Macarena> Adamel: like bla[x]=y where 2^x is the access width and y is what i just described ...
<Macarena> Adamel: That's how I meant it.
<Macarena> O.K. - agree on no array, with meaning as Adamel just put it - o.k. ?
<andrew> and a clear bit means `access on byte boundary permitted' ?
<Adamel> andrew: Yes
<Macarena> a/a: stop ! How do you express 32/32 alignment only ?
<Macarena> I say clear means "not allowed" .
<andrew> macarena: other field that enables/disable access at each size ?
-:- SignOff der_fisch: #ggi (Ping timeout: 720s ping, 360s timeout.)
<Adamel> Macarena: You mean all accesses have to be 32-bits? I suggest we have one "access" and one "align" field, just as before then.
<Macarena> a/a o.k. - seems that's it, then.
<Macarena> A/A: Now for the "hard part" ... Andrew - give me a hand here ... the "enum" thingy ...
* xer^jly/#ggi is away: (Auto-Away after 10 mins) [BX-MsgLog On]
<andrew> hehe, maybe I've been converted...
* xer^jly/#ggi is back from the dead. Gone 0 hrs 0 min 16 secs
<xer^jly>
<Macarena> A/A: I don't want it for applications, just for things like the CrossBlit that needs to decide _quickly_, if both directbuffers are the same ...
<Adamel> One more thing: I suggest that a set bit in the access field means access NOT allowed, and a set bit in the align field means "must be aligned".
<Adamel> This way apps can do if ((access | align) == 0) support everything;
<Macarena> Adamel: Why ? The "NOT" seems counter-intuitive ...
<Macarena> Adamel: Ah - I see ...
<ShadowX> just use ~ ?
<andrew> adamel: sounds ok (access restrictions and align restrictions)
-:- ernie [[email protected]] has left #ggi []
<Macarena> Hmm - we should either call it noaccess or accessrestrict then :-)
* tan/#ggi is sleeping and dreaming about 32 bit aligned bytes ...
<Adamel> Macarena: Quite right ;) noaccess sounds bettet to me
<andrew> access_constraints ? etc
<Macarena> A/a: o.k. ... Third try at the enum stuff :-)
<andrew> I think it isn't too bad right now
<Adamel> Macarena: Ok, enum - yes, you have a point there.
<andrew> without the enum that is
<Adamel> Macarena: on the other hand, most information is available in the graphtype already
<Macarena> andrew: Tell me how to make a _fast_ crossblit, then.
<Macarena> Adamel: How do I know, if a 32/32 blit isn't between little and big endian ?
<Adamel> GT_SUB_REVERSE_ENDIAN
<toddf> there are other endians besides big and little.
<toddf> REVERSE ? reverse of what? big or little?
<core> middle endian? ;)
<toddf> 4123 or somesuch.
<andrew> toddf: CPU vs CARD (normal or reverse endian)
<Macarena> Adamel: How about a KGI driven card that exports _both_ kinds of buffers. I need to decide on the buffer level ...
<toddf> ah.
<core> neverendian? :)
<andrew> macarena: isn't it sanest to choose endian buffer == CPU endianness ?
<toddf> what is reverse of endians that are neither big or little?
<ShadowX> but then neither does unix support it.
<core> toddf: like what arch?
<Macarena> andrew: yes, as this decides whether you need to convert.
<Macarena> core: can't remember, but I have seen some autoconf scripts test for things like 3412 and such ... there was even stated which sick arch does that, but I can't remember ...
<toddf> core: I'm looking...
<core> macarena: hmm, we should look then (that's "middle endian") :)
-:- xer^jly_ [[email protected]] has joined #ggi
* core/#ggi creates a processor with a neverendian scheme
<xer^jly_> re all
<toddf> so by these copyright updates I see inlibggi it looks to me as if libggi is forever to be lgpl ?
<andrew> xer: called the `license debate' ?
<Adamel> toddf: Any problems with that?
<toddf> only that bsd can't use it.
<toddf> no biggie.
<xer^jly_> andrew: huh?
<toddf> we didn't want everybody to play anway.
<core> toddf: better have a lgpl libggi for bsd that none at all *shrug*
<toddf> core: you don't understand. this means that libggi is ONLY for linux.
<core> toddf: it's not kernel code, just a library.. we'll see..?
<toddf> or the hurd. *sigh*.
<Macarena> toddf: I asked, but had a few vots that said LGPL ... well ...
<andrew> xer: the license debate has been neverendian ;)
<Adamel> toddf: Yes they can. If they don't _want_ to because it is LGPL I'm sorry for them.
<toddf> core: did you read my mailing list post yesterday quoting bsd goals and statements?
<core> well, if they are stubborn and only use gcc 1.0 because it's BSD, what can we do?
<core> toddf: hmm, let me look it up..
<xer^jly_> andrew: =)
<toddf> I give up.
<toddf> core: stubborn is not the issue.
<toddf> I tried to make that cleear.
<toddf> optional pieces can be gpl.
<toddf> a compiler is not required to boo.
<toddf> boot.
<core> toddf: the issue is that either we make the library BSD and most developers leave, or bsd integrists will not want to use it
<Adamel> toddf: neither is libggi
<Macarena> todd: Neither is LibGGI ...
<core> toddf: neither is libggi
<Adamel> core ;-)
<core> copycats :)
* Macarena/#ggi looks for the surface that produces all those echos ...
<toddf> core: um, lgpl. not much difference.
<toddf> still encumbered.
* xer^jly/#ggi is away: (Auto-Away after 10 mins) [BX-MsgLog On]
<toddf> it is not bSD as I wrongly said but unencumbered. ut ohwell. as I said decide. you have made your decision.
<core> toddf: libggi isn't required for a bootable bsd system, we mean. not more than gcc is.
<toddf> um, if your graphics uilities use it, you have textmode, or you use ggi. hrm,,..
<Macarena> todd: I see your point, and I would have liked to see it "totally free", but decision has been made ...
<core> toddf: *shrug* we are already moving the drivers to X license so that they can be used inside BSD. they can live with a little bit of lgpl, no?
<toddf> core: give me one reason bsd wants to use kgi of they can't use libggi?
<Adamel> toddf: They CAN use libggi
<core> toddf: xf68_fbdev ?
<toddf> core: huh? does that use kgicon or am I missing something? that's not kgi/ggi to my knowledge.
<core> they can use libggi too, unless there is a daemon under bsd that deletes all [l]gpl code
<toddf> core: you missed my mail obviously.
<toddf> core: any bsd person can download and use it sure.
<toddf> core: but for kgi to work the userland that supports it should be there.
<Macarena> O.K. - A/A: What about that "enum" ...
<core> toddf: well, it can be in /usr/src/gnu/lib/libggi, i really don't see what is wrong with it. but then again i'm not a bsd user for the most part..
<toddf> I can guarantte you that no bsd developers will import it into their sources. it will forever be a hack and a burr to the bsd side. I am sorry for this.
<core> *shrug* we'll see. maybe if all developers someday want to switch to X we will.
<toddf> forget it. nobody is going to budge, just like on the mailing lists. I'll say no more.
* ShadowX/#ggi injects:  it's like trying to shove a proprietary library to Linux distributions.  Users can use it, but it's not standard.
<andrew> macarena: so long as it remains internal to LibGGI, then it doesn't affect pushing 2.0 out the door either way
<core> (X license that is)
<toddf> core: someday? that's just like saying 'well put off the licensing issues till later' once again. this is why this is such a heated debate as it is. nobody was ever told in the beginning andnow we are all with our own assumptions that clash.
<toddf> core: I hope you keep track of ever developer that ever worked on libggi then. incase permission must be given to do that.
<Macarena> A/a: Can we agree on making it an "int setupid" which is undocumented except for "if two DBs have the same value here, the format is identical" ?
<core> well, most of the licensing is up to the authors. we can't force everyone to relicense their code under the X one, unless we want to spend nights rewriting bits. (ie. i don't think andrew would like that)
<toddf> no can't force anyone to do anything. that is why it must be unanimous or no go.
<core> well, right now it's no go.
<toddf> I guarantee you that there will be a bsd version of libggi implemented from the specs.
<toddf> which might even point out how well the specs are written. *shrug*.
<toddf> if bsd is interested in kgi.
<toddf> they're looking at separating console and keyboard/input devices. that's a start. along a long road.
<Macarena> toodf: If they do that, It's fine, and we even might adopt that :-) ... Right now we can't. Sad, but that's how it is. Period. Could we stop that discussion ?
<Adamel> Macarena: Well, if it's there it might as well be public...
* xer^jly_/#ggi is away: (Auto-Away after 10 mins) [BX-MsgLog On]
<toddf> Macarena: sure. I guess we all know where we all stand.  I've got work if ggi will compile on bsd anyway.  it seems someone once again broke it ..
* xer^jly_/#ggi is back from the dead. Gone 0 hrs 0 min 51 secs
<core> toddf: would you provide a *BSD host if i setup tinderbox ?
<toddf> core: I have pmax, i386, sparc, alpha and soon mac68k at your service.
<andrew> macarena: yeah, setupid (non-public) is fine with me
<core> toddf: really? great! that would be to have hosts that compile the tree all the time, and report when it breaks on a specific platform - you know
<Macarena> A/a: O.K. I'll do it that way, then.
<core> so if you have linux and you commit something, you'll still know quickly if it breaks irix or bsd
<toddf> core: i am aware of what tinderbox does. I'll have to get it to compile on more than i386 first I imagine.
-:- Macarena has changed the topic on channel #ggi to: Setting LibGGI API in stone ... LibGII integration
<Adamel> Macarena: Which way? Andrew and I said different things...
<toddf> like right now OpenBSD/alpha is not shared.
<core> i can provide linux libc5/glibc, solaris/x86, irix 6.x, and in two weekends, i'm acquiring a sparc server 20, so i can provide solaris/sparc then.
<core> toddf: just summing up for everyone :)
-:- syndrome [[email protected]] has joined #ggi
<toddf> core: heh.
<syndrome> hi there
<Macarena> Adamel: Making it public/non-public is just a question of where to put the enum definition ... we can decide whatever we like. I like public, but ...
<toddf> ok guys I found it. here is 3 lines of endian possibilities
<toddf> #define LITTLE_ENDIAN   1234    /* least-significant byte first (vax)         */
<toddf> #define BIG_ENDIAN      4321    /* most-significant byte first (IBM, net)     */
<toddf> #define PDP_ENDIAN      3412    /* LSB first in word, MSW first in long (pdp) */
<toddf> hmm, I wonder if anything but pdp does that last one.
<toddf> heh.
<core> oh, PDP.
<toddf> ggi on pdp. whee! it would be a historic occasion.
<core> lol
<Macarena> Yeah - that I had in memory, too ... PDP (Pretty Dumb Product :-)
<Macarena> Hi syn ...
<core> header change is starting to get on my nerves :)
<core> but i'm almost done changing all freaking libggi sources :P
<toddf> let me konw when you're done. I'll do another mirror just for the occasion ..
<core> toddf: yeah, just a couple more minutes
<andrew> macarena: making it public means maintaining an extra API, and applications have the time to do the slow checks
<core> toddf: do you have bandwidth stats for the mirror? just to scare all of us..
<Adamel> toddf: Btw, has the permission bits issue been resolved for the CVS mirror?
<toddf> core: um, I've not setup any bandwidth monitoring programs .. lemme see what I can dig up though.
<core> the devel repository itself without cvsweb takes about 1 GB/month, that's quite okay for me
<core> toddf: no, that's ok, it was just a question :)
-:- SignOff syndrome: #ggi (syndrome has no reason)
<Macarena> A/a: O.K. - we hide it for now. We can still make it public, if we see need.
<andrew> maca: yup
<toddf> Adamel: I think it is cvs trying to do something it assumes it's running as root for and obviously it can't.
<toddf> Adamel: I have it running chroot'ed as a unique userid.
<core> the local copy on synergy repatches the bits, but the anonymous mirror, i don't know
<core> toddf: i thought you just updated by ftp mirror?
<Adamel> toddf: Could you please try to fix that. It's _very_ important to get the bits right.
<toddf> I updated by ftp mirror yes ..
<core> toddf: so the exec bits should be copied along?
<toddf> Adamel: huh? please elaborate. perhap we're talking about another issue.
<Macarena> O.K. A/a: What about LibGII integration - did you read my last mail on that ? The one regarding size ?
<toddf> last I communicated I said 'I will try chmod'ing these two to 555 not 444 and see' it seemed to checkout as executable. now, if someone would kindly tell me what files in the master repo have 'o+x' .. I'll adjust my mirror accordingly.
<core> OK. I believe all of libggi now uses the unified headers and license. just the targets need to be fixed (steve ?). the demos have been fixed by andy.
* core/#ggi sighs
<core> cvs updates will show a scary number of P's :)
<ShadowX> core: ok.
* ShadowX/#ggi just working on my own website before :)
* xer^jly_/#ggi is away: (Auto-Away after 10 mins) [BX-MsgLog On]
<core> hmm, i wish we could contact Jarno Panaanen so he could fix iXalance to use the new libggi :(
<toddf> core: P is better than U. U = more efficient to get the whole thing than to send patches. P = sending patches ..
<Adamel> toddf: The exec bit's were missing on executables on the mirror before. Have that been fixed?
* xer^jly_/#ggi is back from the dead. Gone 0 hrs 1 min 12 secs
<core> toddf: i know.. oh - something i always wanted to ask you: cvs keeps versions by diffing, right. so the older the tree gets, the slower it becomes to produce diffs, right?
<andrew> macarena: apart from the runtime space-saving, what are the benefits of the GII integration ?
<toddf> core: somewhat. especially if it is actively developed.
<core> toddf: degas was starting to be real slow to do cvs updates. I upgraded it physically a month ago or so and now it's much faster, but it had fallen at the speed of steffen's old mirror
* ShadowX/#ggi eat lunch . (away)
<core> toddf: ahh.. how can that be improved? besides cvs importing again?
<toddf> I have had since august 4th 2840 pserver connections
<core> grep pserver /var/log/syslog | wc -l ? :-)
<toddf> core: well, I suppose if things were terribly slow, one could archive the old repository and re-import the sources. but that really screws any hopes of looking at past changes without alot of effort.
<Macarena> andrew: 1. Overrideable inputs. We can attach say a console input to a memvisual. 2. Allow to unify that sick Linux one-file-per-device thing.
<toddf> core: basically yes
<core> toddf: yes, that's the problem.. it was tremendously faster when we re-imported. any other way?
<core> toddf: maybe when degas is out, reimport the new tree, keeping the old one online?
<toddf> core: sorry. every file,v is literally a listing of changes. so to get the current version it must start with the original file and 'patch up' so to speak. each time you do an update or a diff or anything.
<core> toddf: yes, that's what i understand
<toddf> core: did we keep the old repo online? not that I know of. *sigh*. if we DO keep the old repo .. maybe like have degas-98 subdir or something so all the mirrors have it avail too?
<core> toddf: we didn't because steffen had disappeared, but i do intend to get his old repo and put it online, for history.
<andrew> macarena: in other words, more flexibility, right ?
<core> toddf: hmm, well, degas is scheduled for hardware upgrade, we'll see how it goes then..
<Macarena> andrew: yes. the joining allows to let multiple input sources look as one. Would also help things like display-multi.
<Macarena> core: BTW update give 102xP and 60xU ...
<andrew> macarena: now you've lost me. display-multi ?
<toddf> core: OpenBSD has been developing on the same 300mb subtree for several years. david miller's linux source tree has every revision of the linux kerenl plus local diffs dating back to 1.3.43
<core> macarena: yes, that's marcus autoconf stuff too :)
<Macarena> andrew: That "show on multiple visuals" target.
<core> toddf: how do they cope? it's not like updating takes an HOUR, it's just a shame it can't be faster :)
<toddf> core: try anoncvs.ca.openbsd.org or anoncvs.usa.openbsd.org sometime. *shrug*. it works.
<andrew> macarena: hehe, I know it, but how does _that_ relate to gii ?
<toddf> core: how does my server feel in terms of speed?
<core> toddf: i'm sure. well, degas is the only box of suntech that doesn't have an scsi disk :P (shame, horror :) (i'm already glad i could almost dedicate a pII/266 to ggi tho.. :)
<toddf> core: I know it works. it grinds when I have 2 or more cvs pserver connections, but at 128mb I'm good to go.
<core> toddf: no complaints :)
<Macarena> andrew: For now disp-multi only takes input from the first visual. Using the "join" function, we can just join the inputs together.
<toddf> btw, I just made 2 symbollic links. maybe at some point we can advertise their use.
-:- SignOff StevenE: #ggi (Leaving)
<andrew> macarena: neat. display-tile would benefit from this too.
<core> toddf: which are?
<Macarena> andrew: To the user this looks like a unified input source. Same goes for all that linux-madness with /dev/joy*,/dev/mouse,/dev/tty, ...
<toddf> in the 'jail' of chroot I did a mkdir /projects/ggi .. then a ln -s ../../cvs ../../cvsdevel /projects/ggi
<core> oh
<core> copycat :-)
<toddf> so if one simply sets their cvsroot to :pserver:anoncvs.us.ggi-project.org:/projects/ggi/cvsdevel .. one can update from anon, and set seme vars and commit to the real repo.
<core> toddf: btw, do you want to install cvsweb on your mirror too? j/w
<core> toddf: yup, cool :)
* ShadowX/#ggi back
<toddf> hmm, point www.us.ggi-project.org to me and I might ..
<core> toddf: hm, no, that's for a website, but http://anoncvs.. should do :)
<core> (like you can try http://cvs.ggi-project.org)
<toddf> core: doesn't www.us look better?  I have the ftp mirror as the www dir
<core> toddf: yeah it does, but that's the naming scheme of the website mirrors
<core> (ie, www.uk, www.pl ..)
<toddf> core, I am a mirror!
<toddf> checkout http://anoncvs.us.ggi-project.org ..
<core> ? how come you aren't listed anywhere then
<toddf> because I was waiting till I got around to asking you to change it to www.us.ggi-project.org ..
<toddf> :-)
<toddf> unless the mirrors don't use the ftp subdirs for the web pages ..
<core> oh, i see. sure, the only other US mirror we have hasn't been updated till dinosaurs ruled the earth anyway
<ShadowX> uhhh.. in the lib/libggi/demos...
<Macarena> A/a: The idea is to separate out the individual /dev/sth drivers and
<ShadowX> It says (c) Author even though it's public domain...
<core> shadowx: yeah, i know. i told andy already ;)
<toddf> anyway, regarding the ln -s trick I just did .. it is very useful to me as an OpenBSD developer.  I can update from the anon servers, do diffs, etc, then commit to the 'primary server' .. only becase the part after the ':' in the Repository setting is
<toddf> the same path
<Macarena> A/a: have the targets just GiiOpen and giiJoin those it would have traditionally handled by itself.
<core> toddf: i thought CVS kept the full path?
<andrew> macarena: ok, consider me a convert ;)
<toddf> core: CVS/ does .. however, you can use tricks to switch repos if they appear to use the same local path to the repository. that's why I made the /project/ggi/.. links
<core> toddf: ohh, okay
<toddf> I just do a:
<Macarena> andrew: O.K. - do you remember who else objected ?
<toddf> export CVS_IGNORE_REMOTE_ROOT
<toddf> then
<toddf> cvs -d <another cvsroot> <some cvs command>
<toddf> and as long as the subdir on both remote machines is the same, it works
<Adamel> Macarena: Ok, I agree to this too.
<core> toddf: www.us.ggi-project.org you are
<core> (give it a couple minutes to propagate tho :)
<core> toddf: nice to know :)
<Macarena> A/a: O.K. I'll do the changes, then. Shouldn't break anything (I hope :-) ...
<Adamel> Btw, speaking of events... Memory allocated in evqueue.inc is not freed anywhere.
<core> noone has complaints relative to the repository speed or anything? (esp. since i installed cvsweb, it is _heavily_ requested.. not something that can put the 4 mbps we have down yet tho.. :)
<core> (seriously, i won't be upset :)
<Macarena> Adamel: Yeah - we should fix that.
<toddf> I've not had bandwidth problems yet and I'm on isdn so ..
<core> yeah, but the cvsweb thing is linked from the main site and therefore.. ;)
-:- SignOff tan: #ggi (changing servers)
-:- Macarena has changed the topic on channel #ggi to: Setting LibGGI API in stone ... other topics ?
<andrew> macarena: how are you going to handle vtswitching ? Currently Linux_common/vtswitch.inc opens the /dev/ttyN file (and does magic) and Linux_common/keyboard.inc uses _that_ filedescriptor.
<yazz> core: CVS always keeps the latest version and uses diffs to get older ones (reverse delta)
-:- tan [[email protected]] has joined #ggi
<core> yazz: oh? hmmm. i thought it was the other way around.
<tan> oops
<yazz> core: No, that would be *stupid*
<core> yazz: *shrug* it does seem to slow down with time.
<andrew> Yeah, I'd like to see some improvement in the LibGGI events, most importantly *joystick* events
<core> degas needs to be beefed up anyway. oh well.
<yazz> core: Dunno why...
<Macarena> andrew: got to look into this. Would opening two descriptors cause a problem ?
<core> all: what name will we use after Degas is out? :=)
<toddf> virtele?
<andrew> macarena: I doubt it (unless it's a `controlling tty' problem)
-:- StevenE [[email protected]] has joined #ggi
<Adamel> IMO joysticks should not be handled by libggi at all. For _that_ I still suggest a separate libgii.
<core> um, something not too far away in alphabetical order (andy said duerer.. :)
<Macarena> Adamel: The idea is to just use the LibGII drivers in LibGGI (and eventually delivering the most important ones directly with LibGGI).
<andrew> adamel: I think a separate libgii isn't workable -- events are usually associated with the output device (like in X), and linux crap is the exception
<toddf> nothing like a forced named cache reload :-) .. it works locally for me.
<StevenE> I just wanted to announce that I am working on the Win32 VC++ port of libggi and a directx 3 target right now.  I've gotten a good amount to compile, and soon I will start providing source code and eventually Makefile diff's to keep the tree up-to-date.
<toddf> well guys, I need to be heading to work. cya around. I'll leave this up to log ... heh.
<Macarena> Cu, todd
<Adamel> Speaking of filedescriptors vis->select_fd will be replaced by your GII stuff, right Andy? I suggest we remove vis->fd too and let targets store whatever they need to store in vis->targetpriv, to prevent code from making assumptions about what it is used for.
<core> toddf: okay
<StevenE> is there any other work on a directx target in progress?
<andrew> adamel: yeah vis->fd can go.
<core> stevene: marcus mentioned something with win32, but i believe it's GDI (?)
<Adamel> StevenE: No, not that is known to us at least
<Macarena> Adamel: Yes. the idea is to request a whole fd_set from LibGII _or_ better register your own input things with LibGII.
<Adamel> core: You mean my mail today?
<Macarena> A/a: And yes, I think the vis->fd can go ...
<core> adamel: right
<Adamel> core: That was Steven I was talking about
<StevenE> ahh, well then i'll continue trying to struggle through making this target ... however, i have to go.  You can reach me at [email protected], I'd be glad to accept help on writing this target.
<core> adamel: oh :)
* core/#ggi bangs his head
<core> stevene: cool! feel free to ask on the ML anyway, it's the best place for that :)
<StevenE> ok, i will, as soon as my school fixes their NFS server.
<StevenE> goodbye
<Adamel> cya steven
-:- SignOff StevenE: #ggi (Leaving)
<core> see ya steven
<Macarena> ping ?
<tan> ping?
<Macarena> All quiet ?
<Adamel> pong
<Macarena> What further LibGGI set in stone topics are there ?
<core> dong
<Adamel> Fixing kgi headers currently ;)
<andrew> How about evJoyAbsolute, evJoyButtonPress and evJoyButtonRelease events ?
<core> was mapping www.at and www.us and updating the webpages :P
<Macarena> O.K. then let's move on ...
<Macarena> andrew: These are valuators.
<andrew> macarena: but valuators are meaningless (and no buttons)
<core> mm. release of Degas ? (libggi 2.0, you talked about it.. kgicon, and what else remains? and what name to use for next release :)
<andrew> (mice are valuators too...)
<Macarena> andrew: wrong - buttons=keys and you should let the user _configure_ what device to use. That's the whole point about valuators.
<Macarena> andrew: As long as device-id is unique - all is well.
<Macarena> andrew: The only thing that needs to be added is a small protocol for querying what devices are there, and how their axis should be labeled ...
<andrew> macarena: then you're happy to remove evPtr* events and use valuators there too ?
<Macarena> andrew: I would be, but many won't. This is why we left those ...
<andrew> macarena: well, I'm not happy using valuators for joysticks either...
<Macarena> andrew: shall we add yet another event type for every possible device ?
<Macarena> andrew: The idea in the scheme is, that anything a computer can handle is basically either a key (as some degenerated case) i.e. something that can be on or off and a valuator, something that can have a numeric value.
<andrew> macarena: no, but having joystick and tablet events would cover nearly everything
<Macarena> andrew: spaceballs ?
<andrew> maca: spaceball == joystick
<Macarena> andrew: No. 6D, 10 buttons, ...
<andrew> maca: yup, 6D joystick, 10 button joystick
<Macarena> If spaceball==joystick, then joysick==tablet==mouse, too ...
<Macarena> andrew: The app needs to make up a configuration anyway, or the spaceball would interfere with the joystick, if you have both.
<andrew> macarena: valuators lack _semantics_.  A joystick has a negative<->positive range centred on 0, whereas tablets have a range from 0..<N> for each axis, and mice are relative.
<andrew> maca: interfere ?  they have different device-ids
<Macarena> Rel/abs is there ... And I would like to put "metadata" outside the events themselves (i.e. in the axis-identification protocol).
<Macarena> andrew: reg interfere: How many programmers would check that, if they already check for EV_JOYSTICK ? With EV_RELVALUATOR, they must.
<andrew> maca: same argument for multible mice.  We allow that, no ?
<Macarena> andrew: In EvStack aka GGICONs, the idea was, that even mice send VAL events, and there is a universal convertor that selects the "mouse device" and converts.
<Macarena> The mouse events are just there for old fashioned programmers that expect them to be there ...
<Macarena> And they keep konfiguration of the most common graphical input device out of the application for ports and stupid programs.
<andrew> joysticks are pretty common :-))  Anyway, what's this metadata ?
<Macarena> andrew: Some human-readable name of device and axis, range, type of physical quantity it measures (temperature, force, length, luminosity, ...)
<Macarena> andrew: This comes in handy for descent style configuration ...
<andrew> macarena: where's the code ? :)  I mean, I'm keen to actually use joystick/spaceorb with LibGGI.
<Macarena> andrew: EvStack had Spaceorb code ...
<andrew> macarena: wonder who wrote that ? :-))
<Macarena> andrew: While I'm putting that LibGII code in, I'll add the code.
<andrew> macarena: no, I'm wondering what the actual API will look like.  Is it still `up for grabs' ?
<Macarena> andrew: basically yes, though I got some idea of how to do it. Basically just a info-type event
<andrew> macarena: Okidoke, but one more thing.  I really dislike using _key- events.  Can we at least have evValButtonPress and evValButtonRelease ?
-:- wlfshmn [[email protected]] has joined #ggi
<Macarena> O.K. folks I got to go now - I promised afriend to help him a little with some electrical wiring stuff ...
<andrew> macarena: bye
<Macarena> andrew: We'll sort the rest out on the list. I see your point, but am not sure, if oit is a good idea ...
<Adamel> Macarena: Bye!
<core> bye andy.. may the 3D penguin etc :)
<Macarena> O.K. bye folks - was a quite productive meeting ... licensing got settled ...
<Macarena> core: ROTFL ...
<core> macarena: yup, even fixed-in-place :)
<Macarena> CU, ANdy
-:- SignOff Macarena: #ggi (Leaving)
<core> adamel: i've put a tarball of the www site on synergy as you asked.. until i check it in in cvs
<wlfshmn> ohh. we got a license finally... ;)
<core> wlfshmn: yeah, license to draw :)
<wlfshmn> core: oh.. none to plot?
<wlfshmn> ;)
<Adamel> core: Ok, thanks. Btw, how about removing vgadoc, ggi 0.0.8 and those things from the http tree... Should be enough to have them in ftp
<core> wlfshmn: mm.. i guess we can sublicense it to plot, draw lines, circles, and 3D texturemapped penguins..
<core> adamel: heh.. yeah.. most definitely (i forgot to squash the references to the stable repository from the cvs explanation too..)
<core> adamel: Steve Cheng is supposed to overhaul the site quite massively.. if he doesn't i will
<core> there is half a ton of docs in the repository that need to be put on the site too..
<Adamel> Yeah, and we should do something about that one+ year old FAQ too...
<ShadowX> core: i don't know...
<core> shadowx: i have put the tarball there for you
<core> shadowx: mind doing some massive upgrades to the site? :)
<core> (since you self-designated yourself as webmaster ;)
<ShadowX> ok.  Let me finish the headers first.
<core> shadowx: sure :)
<core> should we end the 'formal' (ie logged) meeting, or are there topics you want to discuss still, andrew, marcus?
<andrew> BTW, are we getting rid of ggiGT2BPP and ggiBPP2GT ?
<Adamel> Nothing that I can think of right now...
<Adamel> andrew: Yes, definitely...
<andrew> adamel: ah good.
<ShadowX> core: why stop?  Something to read when nothign to do :)
<core> shadowx: so we can start calling eachother names and such :-)
<core> (more like i can give you the log for your summary and such :)
<yazz> Adamel: You did the autoconf stuff?
-:- bri [[email protected]] has joined #ggi
<ShadowX> just going over vgagl now
<ShadowX> reminds me, why ggiFillscreen instead of ggiFillScreen ?
<core> hey mr. Julin :)
<bri> hi
<ShadowX> gosh, two line headers needs 30 line legalese ..
<bri> so I assume someone has a log -- where at?
<Adamel> yazz: Yes
<yazz> Adamel: How come all the Makefiles are still in the cvs tree?
<Adamel> yazz: Because the autoconf stuff isn't done yet. The old make/configure system is still fully operational. When autoconf works 100% I'll remove them.
-:- Asbel [[email protected]] has joined #ggi
<yazz> Adamel: Ok. Do you plan to use libtool?
<Adamel> yazz: Not in libtool's current state. It's way to unflexible for libggi.
<tan> adamel: why?
<Adamel> Well, for one thing it doesn't let me version the library 1.4.99... ;)
<tan> -release 1:4:99
<yazz> By the way. I saw Mesa 3.0 is out. Does anyone know if ggi works in it?
<Adamel> But a more important issue is that you can't choose _which_ symbols are to be exported. This will break libggi on at least digital Unix.
<tan> yazz: no. I believe its ggi code is outdated
<andrew> adamel: how does it break ?
<yazz> tan: I guessed so. Everything older than a week is outdated :), guess that's gotta stop soon.
<Adamel> tan: (about -release) That's definitely not what we want. -release creates a libggi-1.4.99.so library instead of a libggi.so.version
<Adamel> yazz: It will stop in two weeks or so.
<tan> adamel: how about -version-info?
-:- SignOff wlfshmn: #ggi (ircII EPIC4pre2 -- Accept no limitations)
<Adamel> andrew: The dynamic linker mixes the GGI* functions up if you have more than one library with the same symbols (like X and meomory target loaded at the same time)
<Adamel> tan: -version-info is what doesn't allow me to name it 1.4.99 ...
-:- bse [[email protected]] has joined #ggi
<bse> wow.. some ppl here
-:- SignOff core: #ggi (brb)
<bse> for a change
<Adamel> tan: libtool is an excelent example of the GNU attitude - our way is the best, and there's no point in supporting anything else
<tan> adamel: IIRC there was an option to choose the exported symbols... the only problem is that libtool�s maintainer has quit :-(
[bse([email protected])] you're not the same fatal who's been annoying me in #gedit?
<bri> bse: your coming in on the tail end of a scheduled meeting :)
<bse> ack... i missed it?
<bri> (Actually it's been over for a while )
-:- Logic [[email protected]] has joined #ggi
<Adamel> tan: You could choose to export all symbols in a library. That's what's causing trouble...
<bse> oh, yeah... 2:00pm GMT... doh...
<bse> its 7:05 now... ack
<bse> has the 'loading graphic file types (bmp, jpg, etc)' been discussed?
<Adamel> bse: Well it's not much to discuss. ;) Someone just has to write an extension that does that.
<bse> oh, right.. yeah.. heh...
<tan> adamel: hmm, wouldn�t it be possible to fix this problem in libtool rather than doing our own probably (in general) less portable and less comfortable makefile system?. I really like libtool, it automatically shared+static ...
<tan> libraries etc.
<tan> bse: IIRC it was Willie Daniel who wrote libgbm
<bse> and it comes with ggv, i know...
<Adamel> tan: Yes that might be an option.
<Asbel> Is there now a timescale for a stable LibGGI release then?
<andrew> asbel: christmas ;-)
<Asbel> A present for xmas. How nice ;)
<Adamel> Asbel: With a beta being released at the beginning of October
<Asbel> That's good.
* ShadowX/#ggi big commit now.
* ShadowX/#ggi just Linux_common and tele left
<Asbel> Not to be critical, but I have been wondering what was taking you guys so long :) I've been watching for some time, and LibGGI looked good right the way back at the time of 0.0.8/9 ...
<ShadowX> too lazy, and I had some code in tele that shouldn't be in CVS yet...
<Adamel> Asbel: Well, libggi development were basicly stalled for the first 6 months of this year.
<Asbel> Yes, I noticed
<Adamel> Asbel: First by discussing API issues, and then by CVS closing down.
<ShadowX> excuse me . is there a way to back out a file after I committed?
<Asbel> I *am* pleased to see things are speeding up again though
<ShadowX> I did a cvs commit and didn't notice some files I modified that shouldn't go in there -- sory
<Asbel> If I didn't have n+1 projects already I'd be right in there myself
<Adamel> ShadowX: There must be, but I don't know what it is ;)
<andrew> shadowx: there is a way...
* andrew/#ggi is thinking...
* Logic/#ggi  is away: (Auto-Away after 10 mins) [BX-MsgLog On]
<bri> noone answered -- anyone got a log of the meeting?
<ShadowX> core said it will be on website
<andrew> shadowx: IIRC, it goes like this: use `cvs log' to get the revision _before_ committing, then `cvs commit -r REV -p > newcopy', then replace the file with newcopy and commit it.
<andrew> shadowx: (i.e. the revision of the good file)
<ShadowX> ok, thanks a lot
<andrew> shadowx: if it works, _then_ thank me :-)
<andrew> shadowx: typo in above!  `cvs checkout -r REV -p > newcopy'.  sorry
<tan> bri: @degas is our log daemon. Be careful: big degas is watching you :-)
<ShadowX> ah, thought something was wrong there ...
<ShadowX> was info cvs just in case:)
<andrew> hehe
<andrew> shadowx: make that `cvs update ...'.  Argh!
<ShadowX> how do you get a single file
<ShadowX> whoops
-:- bse [[email protected]] has left #ggi []
<ShadowX> good, it works. Thanks!!
* andrew/#ggi wipes forehead ;)
* Adamel/#ggi is getting _really_ hungry
<Adamel> I'll go get something to eat, be back in 45 minutes or so.
<andrew> adamel: ciao
<ShadowX> already ate :)
-:- MenTaLguY [[email protected]] has joined #ggi
<ShadowX> see ya
<MenTaLguY> Good afternoon, everybody.
<ShadowX> what happen to every body else
<andrew> hi
<ShadowX> hello
<tan> hi
<bri> heya
<MenTaLguY> so, what did I miss?
<andrew> mental: license issue is decided.
<tan> mental: almost everything ...
<MenTaLguY> what happened with licensing?
<andrew> mental: kgi drivers: X-style license. KGI-OS-layer: same as OS. LibGGI: LGPL
* MenTaLguY/#ggi nods
<MenTaLguY> that sounds sane.
<MenTaLguY> I hadn't really thought much about X license for the drivers, but that's a lot better than dual/triple/whatever licensing to match all the OSes.
<Asbel> Indeed. I saw license problems on the list archives and was a little worried about the possibility of a split...
<Asbel> Which would have been a great shame after this much time
<MenTaLguY> yes, it really did need to be settled.
* ShadowX/#ggi is glad we don't have any more stupid discussions on the list
* andrew/#ggi doubts that :-))))
<MenTaLguY> don't be so sure that that's the last of the stupid discussions :)
<bri> I'm sure we'll come up with some more :( ...
<MenTaLguY> maybe the last of the stupid licensing discussions.
* Logic/#ggi is back from the dead. Gone 0 hrs 16 min 37 secs
<Logic> is someone summarizing the meeting to the list?
<Asbel> It's a lesson people unfortunately seem to learn only by experience that the "stupid licensing discussions" need to be had and *settled* early, or you don't have a project...
* MenTaLguY/#ggi nods sadly
<ShadowX> logic: I'm supposed to, but I don't have a log yet.
<ShadowX> and I haven't caught much of the later discussion, so it may take me a while ...
* Logic/#ggi nods.
-:- massacre [[email protected]] has joined #ggi
<massacre> hi, did I miss anything?
<massacre> =)
-:- SignOff xer^jly_: #ggi (Ping timeout: 720s ping, 360s timeout.)
<MenTaLguY> lots, I would expect.
<MenTaLguY> I just got here myself.
<bri> Wow is this like the convention for people who sleep in on Sunday or what ? :)
<ShadowX> speaking of which, core didn't give me the website cvs password --
<MenTaLguY> at least we got the licensing issue settled?
<MenTaLguY> bri: exactly.
<MenTaLguY> s/?$/./
<massacre> yeah!
<massacre> I love sleeping in..
<Logic> bri: bingo.
<massacre> actually, now that I do the GMT conversion, I probably went to sleep right when the meeting started =)
<ShadowX> I set my alarm clock yesterday just in case :)
* massacre/#ggi had a fun night...
-:- massacre is now known as MassacrE
* Logic/#ggi needs to go, but will look forward to the summary. :-)
-:- SignOff Logic: #ggi (BitchX: the headache medicine.)
-:- MassacrE is now known as Mass-
-:- SignOff Mass-: #ggi (massacre has no reason)
-:- massacre [[email protected]] has joined #ggi
<massacre> what happened?//
-:- massacre is now known as MassacrE
<bri> massacre: bit of an identity crisis there?
<MassacrE> It stop sending or letting me see what was going on
-:- Asbel [[email protected]] has left #ggi []
<ShadowX> so besides DB structs and licensing, what else did you people discuss?
<MassacrE> hehe, is there another server up besides 'irc.ggi-project.org'? =)
<bri> yeah was there any kgi/driver pertanant stuff discussed?
<MassacrE> anyone know about writing a display driver? I still have some questions..
<MassacrE> I'm trying to get the S3 Vision driver working, it is acting strange though
<bri> Well, I do know a lot about writing a display driver, and even I have questions :)
<bri> What's it doing wrong?
<MassacrE> If I am at 32bpp mode, it displays fine.. but at 16 bpp mode, it displays two columns, it shrinks the screen to half width and shows it twice
<andrew> shadowx: gii integration, joystick events, not much really
-:- SignOff xer^jly: #ggi (Ping timeout: 720s ping, 360s timeout.)
<bri> That sounds like a chipset register is not being set right, there's nothing in libggi that would do that...
<MassacrE> right! The way I got it to that point was to take the X server (XF86_S3) and hack at it so that when it sets the mode, it prints out the registers on the Ramdac and the registers on the S3
<MassacrE> I was able to get it to that point by hacking at it until (afaik) all those registers match. So now I'm stuck =)
<MassacrE> good news is 16 bpp and 32 bpp modes both appear to work perfectly other than some wierd horizontal timing prob.
<bri> Actually it's a bit mystifying as to why it would do that... normally the
<bri> screen would repeat horizontally if your video memory was wrapping...
<MassacrE> it only does that in two very-high modes. (640x480 and 800x600, both at 50 and 75 mhz respectively)
<MassacrE> with most monitor drivers, it won't display anything at all, the monitor will just go to sleep
<MassacrE> If I take the horizontal timing registers and divide them by two before they are written, 16 bpp mode works
<bri> Does that effect the refresh rate??
<bri> Sounds strange.
<MassacrE> yeah
<MassacrE> I haven't figured it out yet
<MassacrE> =)
<bri> Note if it works fine in 640x400 but not in 640x480 that's probably
<bri> something to do with the fact that 640x400 is near the boundary of
<bri> memory (be it 256K, 512K, or 1M).
<MassacrE> I think part of the problem is taht the S3 driver was written for a ramdach that always puts out a Pixel clock.. mine puts out a serial clock (like, 32 bpp divides it by two, so that it sends 64 bits of color info every clock)
<MassacrE> which one you working on?
<bri> Nothing quite so advanced -- WD
<bri> (The old ones, right now the laptop LCD controller).
<bri> Are you perhaps maybe writing values into the status bits for how much ram is installed on the card?
<MassacrE> nope
<MassacrE> Actually the driver was set up to allow writes to those registers, I fixed that
<bri> Also, if you write an alternating pattern of dots, does it show
<MassacrE> that I haven't tried
<bri> up in both columns or does one color go on one column and the other on the other side?
<MassacrE> I corrected something with my first change that made it go to two columns.. before it was fullscreen, but still clocked wrong
<bri> If the latter, check the odd-even chaining registers (there's one for VGA compat and probably an override for hi/true color.
<MassacrE> well, text is readable.. so I'm imagining that it is just redrawing twice
<bri> Hmm -- what size font?
<MassacrE> 8x16 I would guess
<bri> That's not it then :(
<MassacrE> code editing is *really* nice when you are in a 1152x894x16 bit textmode
<MassacrE> =)
<MassacrE> well I didn't delete the X server yet, so I'll just make some diffs between 8 and 16 bit modes (both at say, 1024x768)
<MassacrE> good news is my ramdac/clock driver appears to be working 100% =)
<bri> The chip _has_ to be feeding the DAC the line twice.  So it can't be the DAC I don't think.
<andrew> I'm gonna go and hit the SAK ;-), so goodbye everyone.
<bri> chow
<MassacrE> right
<MassacrE> latah!
<ShadowX> see ya
-:- andrew [[email protected]] has left #ggi []
<MassacrE> yeah.. it appears to be someting with the horizontal timing registers
<MassacrE> I can't get 8bpp mode working in any case, but I think that is because there isn't a palette set =)
<bri> Are you in MMIO mode or legacy VGA PIO?
<tan> bye!
-:- SignOff tan: #ggi (using ircII/tkirc)
<bri> Hmmm... note that libGGI likes to write things like 0x0a0a in 16-bit mode-- so perhaps you have two 8-bit modes going there?
<bri> If you change the libGGI colormapping code to write 0x0a00 and it gives you one black screen that would be the case I guess.
<bri> Still -- that would mean you're actually running in 1280x
<bri> So there is some lclk/mclk/vclk stuff wrong I guess.
<MassacrE> yeah probly
<MassacrE> (sorry) left
<MassacrE> I am in MMIO mode
<MassacrE> all colors seem to work in 32 bit mode (And 16-bit mode, with the hack). Except for mandel, which crashes the computer =P
<MassacrE> At this point I'm sure that all the CR registers match up.. if there are any other registers that don't match, I don't know about them yet
<MassacrE> either way, I'm gonna send a patch to the maintainer so they cna look at it. All the S3 documentation assumes you are a VGA prodigy.. I dunno how vga works at all so it is all very annoying to me
<bri> Tried vgadoc?
<MassacrE> where is that?
<bri> It's linked on http://www.ggi-project.org/resources.html
<MassacrE> ahh.. then brb =)
<Adamel> bri: Btw, do you know if the WD drivers should work on a 90c23 chipset?
-:- SignOff MassacrE: #ggi (MassacrE has no reason)
<bri> Do you have full vertical resolution or are you perhaps missing 1/2 the screen?/
<bri> I wasn't aware of a wd90c23 -- I'm working on 24a right now.
-:- massacre [[email protected]] has joined #ggi
<Adamel> I have an old Toshiba laptop with that chipset. SuperProbe thinks it is a 90c00, so it might not be a very common one.
<bri> massacre: Do you have full vertical resolution or are you perhaps missing 1/2 the
-:- Karmic [[email protected]] has joined #ggi
<bri>            screen?
<bri> Very odd -- I'll work up a BIOS scan/ PIO scan if you'll run it for me.  Is
<bri> it a grayscale or color display?
<massacre> vertical resolution seems fine. Actually, it does shrink short if I remember correctly- but it displays everything
<Adamel> The LCD is grayscale, but if you hook up an external monitor you get a colordisplay.
<bri> Maybe the c23 is a support chip for a 24 or 26 then -- what model Toshiba?
<Adamel> T3300SL
<bri> Actually looking at the chip list it's probably a wd90c20 or 22
<bri> They do grayscale displays only + crt
<massacre> my screen might get short, but I thought it was just because of the multisync monitor driver.
<vertigo> gottah go, later!
-:- SignOff vertigo: #ggi (lnx)
<Adamel> Might be... I haven't disassembled the box completely, but the only visible WD chip says 90c23
-:- SignOff yazz: #ggi (Remote closed. [11kb/319pks(0q)] [140kb/1499pks(0q)])
<bri> What's you're e-mail -- I'll send you a program to probe the chipset model out of the super-top-secret undocumented WD PIO registers :)
-:- SignOff Karmic: #ggi (Karmic has no reason)
<Adamel> bri: [email protected]
<bri> massacre: you may be at 1/2 resolution and seeing 8x8 font slices?  Try drawing horizontal stripes.
<massacre> ok.. but things like 'testpattern' work perfectly too
<bri> Hmm -- actually just tru an underscore character I think that's only one pixel high.
<massacre> an underscore char?
<bri> _
<massacre> here, I'll load the driver =) gotta get out of X
<massacre> doh, gotta compile it =)
<massacre> oh, I get ya..
<massacre> Actually, I tried changing the horizontal width registers (CR13) to double the value, and drew all the characters 8x8 (because the other slice was offscreen)
<bri> Oh, so the display _is_ slice up then ?
<massacre> yeah, but that helped absolutely nothing, so I ste it back. the two halves both displayed the same slice, also
<massacre> its very wierd. I'm voting on the horizontal sync registers being set wrong.. I need to see that vgadoc though so I know what the heck they are *supposed* to be set to
<massacre> haha, the whole reason I'm tring to get this working is because I *really* want to play with gsnes9x and ggimame fullscreen =)
<bri> Hey motivation of any form is still motivation, right :)
<bri> What's the chipset model number?
<massacre> and, I had been working on the ramdac/clock driver since like *December*, and everyone was always like 'yeah, that S3 driver works perfectly, we recommend people look at the code to see how things are supposed to be done", yadda yadda yadda.. then I find out the thing is completely whapped
<bri> What's 3c4 index 15 set to?
<massacre> on mine?
<massacre> its a Vision 968, S3 86c968. The ramdac/clock is an IBM RGB 524/220MHz (bad INVSCLK revision)
<massacre> 3c4 index 15? justasec
<massacre> 0x15?
<bri> BTW, check out suisnife from my GGI projects page -- less useful for you in MMIO mode but should allow some register pokes.  Yes 0x15.
<massacre> thats the Sequencer right? it doesn't go up that high
<bri> Hmm.  It does on the 7xx series...
<massacre> ack! now its giving me problems with including <kgi/*>
<MenTaLguY> bleah. I'm working on libega right now, and I'm having some design issues...
<massacre> ahh, fixed.. no <kgi/version.h>
<MenTaLguY> main problem being that when I'm emulating the textmode, I need to redirect everything, but otherwise, it needs to fall through to the normal visual.
-:- SignOff massacre: #ggi (Socket error: Connection reset by peer. [2kb/51pks(0q)] [8kb/109pks(0q)])
<MenTaLguY> creating a second visual for the underlying stuff when emulating doesn't work so well, and I can't really override ggiSetMode very well, as I still need to call the old implementation.
<ShadowX> just save a pointer to it
* MenTaLguY/#ggi shakes his head
<MenTaLguY> if the extension or whatever that pointer points to is detached for some reason, boom.
<MenTaLguY> won't do to rely on other extensions
<ShadowX> hmmm....
-:- massacre [[email protected]] has joined #ggi
<massacre> bwahaha..
<massacre> 86c96x.c:1338: CRT[0x13]=0xa0, mode->request.virt.x=640
<massacre> MISC:  ef
<massacre> FCTRL: 00
<massacre> --- 00  01  02  03  04  05  06  07  08  09  0a  0b  0c  0d  0e  0f
<massacre> SEQ:
<massacre> 00: 03, 01, 0f, 20, 02, 00, 00, 00, 06, 80, 00,
<massacre> CRT:
<massacre> 00: 14, 13, 14, 97, 13, 97, 0a, 3e, 00, 40, 00, 1f, 00, 00, ff, ff,
<massacre> 10: e9, 0b, df, a0, 1f, e7, 03, e3, ff, 00, 00, 00, 00, 00, 00, 00,
<massacre> 20: 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
<massacre> 30: e1, 09, 00, 20, 10, 00, 9e, ff, 48, a0, 35, 17, 06, 00, 00, 00,
<massacre> 40: 31, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
<massacre> 50: 50, 00, 00, 18, 38, 00, 00, 00, 53, f8, 00, 00, 00, 00, 40, 00,
<massacre> 60: 0f, 80, a1, 00, 00, 00, 00, 00, ec, 00, 00, 00, 00, 00, 00, 00,
<massacre> 70: 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00,
<massacre> GRC:
<massacre> 00: 00, 00, 00, 00, 00, 40, 05, 00, ff,
<massacre> ATC:
<massacre> 00: 00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 0a, 0b, 0c, 0d, 0e, 0f,
<massacre> 10: 85, 00, 0f, 00, 00,
<MenTaLguY> actually, it may just be best, instead of egaAttach() and egaDetach() functions, just to have a function that creates a new ggi visual with the ega extension attached that is "based" on a visual that you pass as a parameter.
<MenTaLguY> that'd make doing a libega-based target more difficult ... oh, unless I separate the initialization stuff, create the "basis" visual, and attach libega to the visual that's publicly visible.
<Adamel> massacre: You have access to the main repository?
<massacre> yeah
<Adamel> Could you do an update and see that kgicon still compiles? I just commited a little cleanup together with the license changes, and I don't have a Linux box nearby.
-:- gith [[email protected]] has joined #ggi
<bri> massacre CRT[0x31] bit 2??
<massacre> when? I just did an update like three seconds ago =)
<massacre> ok, no prob
<Adamel> Ok, fine.
-:- mks [[email protected]] has joined #ggi
<MenTaLguY> oh, also ... one other issue with libega -- is using a visual to access the ega font data a good idea, or not, do you think?
-:- smoke [[email protected]] has joined #ggi
<smoke> Hello
<MenTaLguY> hey.
<smoke> i missed all the fun?
* MenTaLguY/#ggi nods
<massacre> it's set to 0, that changes it to use a wider ram image I think
<MenTaLguY> we got licensing ironed out, anyway.
<smoke> MenTaLguY: good. :)
<massacre> oh good.. hopefully nobody got pissed off and was like 'well, I'm pulling xxx code then..'
<MenTaLguY> X-style for KGI drivers, same license (or, I expect, sometimes just a compatible one) as OS for the OS-KGI interfaces, and LGPL for LibGGI
<massacre> =)
<bri> What happens if you poke it 1?  It could just be bus width or could be internal transfer -- docs aren't too specific.
<bri> BTW, your text mode is it graphical or hardware text?
<massacre> graphicall.. how do you set a hardware text mode again?
<bri> Well, that's a long story....
<massacre> hehe, fbset -g 80 25 80 25 13?
<bri> Yeah, if the driver supports it.
<massacre> it didn't set for me, I'm looking
<massacre> I know I told the clock and ramdac to support it (that used to be the only mode I could get working)
<massacre> ahh, I see the changes now, I musta checked out right before they were put in
<mks> hmm
<mks> can someone tell me what this mean:
<mks> debian:/usr/src/degas# cd kgicon/kgi
<mks> debian:/usr/src/degas/kgicon/kgi# make config
<mks> ./configure
<mks> make: execvp: ./configure: Permission denied
<mks> make: *** [config] Error 127
<massacre> means that ./configure doesn't have the execute bit set
<MenTaLguY> you need to chmod a+x ./configure
<MenTaLguY> or something to that effect.
<massacre> chmod a+x ./configure =)
<mks> =)
<massacre> isn't that whole thing a cvs mirroring problem?
<MenTaLguY> now... I recall someone saying on the list that that particular problem couldn't be fixed -- why?
<MenTaLguY> yes, CVS mirroring problem.
<mks> ahh
<massacre> its a CVS mirroring problem. I thought there was a new version of CVS though that fixed that..
<mks> it is working
<ShadowX> it was mentioned earlier
<mks> :=)
<ShadowX> don't remember what the result was.
<bri> Hmm -- vgadoc doesn't list it for the 968 only the 964 but there's some funky thing called split transfer mode that allows you to transfer lines in two stripes of data, if I read it right.
<mks> looks great everybody.
<mks> monitors and all
<mks> tough luck though..the only letters on this monitor is the label MultiSync :)
<bri> There's a caveat to slpit transfer mode when using with certain RAMDACS, too.
<bri> What RAMDAC again?
<massacre> IBM RGB 52x
<mks> is S3 Trio64V2 DX fixed or prog clock?
<massacre> I think that has a programmable Trio clock
<bri> Well, on a lark you might want to try CRT[0x65] = 0x40
<massacre> I don't know.. I'm not familiar with what the state of other S3 chipsets is
<mks> ./configure: ../util/detectcard: Permission denied
<mks> massacre: k
<massacre> same problem, chmod a+x ../util/detectcard
-:- SignOff gith: #ggi (Leaving)
<mks> yea :)
<massacre> nah, I definately have that set correctly, its a 64 bit Serial SID
<bri> One step ahead of me then :)
<mks> massacre: prog s3idac is S3Trio/virge yes.
<massacre> hehe
<bri> Maybe you should just write a ditty to poke bits for 0.5 seconds and then set them back :)
<bri> That's how I first got the WD drivers to work, I strolled through PIO space until I hit the bit that did the trick :)
-:- xer^jly [[email protected]] has joined #ggi
<bri> Hmmm... why do you have CRT[0x67] set to 0? Is it not documented for the 968?
<smoke> Has there been any progress on Vertical Retrace handling in kgi ?
-:- xer^jly_ [[email protected]] has joined #ggi
<bri> Ahhh... vgadoc says the docs from S3 just say this is a reserved register...
<xer^jly_> is the meeting still going on?
<Adamel> xer^jly: The official meeting ended long ago...
<massacre> Adamel: the header files don't appear to work.
<massacre> oh, lemme look
<Adamel> massacre: Oh, darn! What's wrong ?
<xer^jly_> Adamel: ow.. =)
<massacre> CR67 is a specifier, is VCLK in phase or 180^ out of phase with DCLK
-:- Adamel has changed the topic on channel #ggi to: Offical meeting is over - misc GGI discussions in progress
-:- SignOff smoke: #ggi (changing servers)
<bri> Right but bits 4-7 are as follows
<massacre> Adamel: after I get this driver to recompile, I'll remove the files and try to scrap them
<massacre> oh, it doesn't tell me 4-7, whats it say?
* bri/#ggi pauses and wishes gpm cut/paste buffer could be made network transperent....
-:- smoke [[email protected]] has joined #ggi
<smoke> re
<xer^jly_> smoke!
<mks> thanks for ggi!
<mks> bye
-:- SignOff mks: #ggi (Remote closed. [0kb/26pks(0q)] [9kb/111pks(0q)])
<smoke> (perhaps for the 2nd time:) Has there been any progress on Vertical Retrace handling in kgi ?
<xer^jly_> smoke: i've made a free directional tunnel with libggi!
<bri>      1-7  Documented as reserved, however:
<bri>      4-7  Pixel format.
<bri>              0  Mode  0: 8bit (1 pixel/VCLK)
<bri>              1  Mode  8: 8bit (2 pixels/VCLK)
<bri>              3  Mode  9: 15bit (1 pixel/VCLK)
<bri>              5  Mode 10: 16bit (1 pixel/VCLK)
<bri>              7  Mode 11: 24/32bit (2 VCLKs/pixel)
<bri>             13  (732/764) 32bit (1 pixel/VCLK)
<smoke> xer^jly: woohoo! :)
<xer^jly_> smoke: want to see it?
<smoke> xer^jly: yeah of course! :) dcc
-:- weigon [[email protected]] has joined #ggi
<weigon> hy all
<weigon> I�m a little bit late i think
<smoke> weigon: yeah :)
<massacre> this is CR67?
<bri> massacre: yup. 0x67h
-:- rdawes [[email protected]] has joined #ggi
<massacre> wierd!
<bri> vgadoc rules.
-:- rdawes is now known as Rogan
<massacre> if that is true, I *really* hate S3 now =)
<weigon> why do you ahte s3 ??
<bri> There's undocumented stuff in almost every VGADOC file... it's an endemic industry problem :)
<massacre> hehe
<Rogan> Hi folks,  what'd I miss?
<massacre> that still wouldn't be the problem though, I don't think =(
<massacre> also, the X server doesn't set that either ;)
<Adamel> Rogan: Well, just about everything. ;)
<weigon> hey david, what are you talking about ??
<weigon> BTW: i�m jan
<bri> True, but couldn't hurt (except maybe your monitor :)
<Rogan> Adamel: Well, had to keep the GF happy ;-)
<ShadowX> anyone knows where I can get a log?
<ShadowX> the current website is quite depressing, so I'd better do the summarizing first. :)
<Rogan> ShadowX: Try a forest?
<Rogan> :-)
<Adamel> ShadowX: Ask degas ;)
<ShadowX> heh, but it won't talk :)
<ShadowX> !give me log :)
<Adamel> Btw, didn't Emmanuel say "brb" 3 hours ago or so :)
-:- SignOff massacre: #ggi (Socket error: Connection reset by peer. [4kb/87pks(0q)] [15kb/190pks(0q)])
<ShadowX> I don't know, missed most of the technical talk there
-:- mks [[email protected]] has joined #ggi
<xer^jly_> Adamel: when will degas be released? any eta known yet?
<bri> Oh, BTW folks a couple of days ago I got e-mail which suggests the
<bri> next round of Debian compiles will put a XF86_fbdev in the
<mks> bri: alright :)
<Adamel> xer^jly: No, not really. Degas == kgicon btw. A libggi beta will be released in two weeks or so
<bri> development (unstable) distrib.... But I may have been wishfully misinterperating it....
<ShadowX> adamel: what remains to be done?
<ShadowX> (libggi)
<xer^jly_> Adamel: what version will that be?
<mks> bri: 2.1 is slink right?
<bri> Yeah.
<bri> It's not there yet bt there's a source upload in Incoming -- since I want the
<bri> binary though I haven't bothered downloading the .dsc etc and compiling it to see.
<mks> great. Although debian still hasnt got mesa release 3 yet :)
-:- weigon [[email protected]] has left #ggi []
<mks> that was silly <g>
<bri> This is what the e-mail said:
<bri> Source: xfree86
<Adamel> ShadowX: Andrews keyboard modifier changes, the DB stuff we discussed today. Probably something I forgot
<bri> Binary: xserver-i128 xfntscl xslib xmanpages xlib6 xext xslibg xfnt75
<bri> xserver-svga xfntpex xserver-8514 xfntcyr xprt xbase xserver-p9000 xbooks
<bri> xserver-tga xlib6g-dev xserver-agx xserver-mach64 xserver-vga16 xserver-s3
<bri> xserver-fbdev xlib6g xserver-mach8 xfnt100 xfntbig xnest xlib6-altdev
<bri> xserver-mono xvfb xserver-w32 xserver-s3v xserver-mach32 xfntbase
<bri> Architecture: source i386 all
<mks> bri: are you busy, can I ask you a question re kgicon.o?
* bri/#ggi needs to put on clothes like a civilized human being, but that can wait till dinner.
-:- SignOff Rogan: #ggi (bye folks)
<mks> :)
<mks> hello anybody :) so what do I do when this happen:
<mks> debian:/usr/src/degas/kgicon/kgi# insmod kgicon
<mks> S3 86c765 (Trio64) chipset driver rev $Revision: 1.1.1.1 $
<mks> error: failed to detect Trio64V+!
<mks> error: kgim_chipset_init failed
<mks> error: init_kgi() failed, bailing out....
<mks> ./kgicon.o: init_module: Device or resource busy
<bri> Hmm... Well first turn on Debugging in the S3 Makefile, then go into the source and make sure it doesn't get redefined at the top of the file :) then check your kernel messages and hope the developer left some clues in there for you.
* xer^jly_/#ggi is away: (Auto-Away after 10 mins) [BX-MsgLog On]
<bri> Also helps if you have lspci
<bri> (pci-utils is the package name I think)
<mks> yea do you want to know? - VGA compatible controller reported to be?
<mks> 00:0a.0 VGA compatible controller: S3 Inc. Trio64V2/DX or /GX (rev 04)
<bri> Well, check that the model numbers match the ones the driver probes for...
<bri> mks: try lspci -n
<mks> 00:0a.0 Class 0300: 5333:8901 (rev 04)
<Adamel> bri: Where can one find pci-utils?
<bri> I just got mine as debian package -- don't know where sunsite stores the source.
<bri> mks: Definitely recompile with DEBUG_LEVEL=3 and dmesg -n 3 before inserting.  There's plenty of debug information -- also are you specifying a law_base?
-:- massacre [[email protected]] has joined #ggi
<massacre> (oops)
<mks> bri: is that in subsdir?
<bri> edit kgicon/kgi/chipset/S3/Makefile _and_ kgicon/kgi/chipset/S3/86c765.c it is defined in both ( :-( )
<mks> bri: alright :--()
<massacre> sup?
<massacre> damnit, I got hung up on and couldn't get back on until now.. I really wanted to talk to Jan too
<massacre> =P
<bri> But definitely try specifying a law_base first -- that's one of the reasons why s3_verify_86c765 might fail.
<massacre> dmesg -n 1
<xer^jly_> is there a function similar to waitVerticalRetrace in ggi? and if not, why not?
<massacre> many reasons:
<massacre> not all hardware supports it, so encouraging people to use a feature that few new cards supports is a bad idea
<Adamel> xer^jly: Sure. ggiWaitRayPos() is in the misc extension
<massacre> interrupts in Linux are way too slow, it responds after the vertical retrace is over
<massacre> =)
<smoke> ehm.. using a vertical retrace handler should be considered a `good idea` imho
<smoke> using rtLinux one could do a nice vertical retrace handler, but i haven't had time nor skill to figure out how exactly
<massacre> I like the idea of having kgi do vertical retrace handling =)
<Adamel> There will also be a flag you can set to make ggiSetDisplayFrame() wait until vretrace before switching frames
<bri> smoke has done a bit with this, right smoke?
<massacre> hey, I'm in that wierd 2-screen mode now =)
<massacre> _ appears on both halves
<massacre> | does too
<bri> Cool.  Intoxication without alcohol :)
<smoke> yeah, i've actually done some vertical retrace handling with rtLinux, but i'm not experienced enough with KGI to make it blit, and i haven't found a way to tell userspace -fast- that flipping has occured.
<smoke> Would it be possible to make a userspace prog sleep (waitRayPos(VERTICAL) ) and then let ggi wake it ?
<bri> Anyone else here think that the HZ setting in the kernel source is a tad bit conservative?
<smoke> (at ~70 hz or more)
<massacre> HZ?
<smoke> bri: no it's good for intel
<mks> bri: make result is too few arguments
<smoke> #define HZ 100 (in kernel sources)
<smoke> for Alpha it's 1000, and it's supposed to be this low for iNTELs because they `suck` :)
<bri> mks?? are you making from inside the subdir, or from kgicon/kgi??
<mks> bri: /kgi
<massacre> HZ? =)
<bri> Always wondered why they didn't choose a power of 2 for that :)
<massacre> ack, this mode hurts my eyes ;)
<Adamel> bri: Yeah. IIRC someone on the list changed it to 1000 and tried it on an intel box, and didn't notice any performance decrease. I suppose you would get a performance decreas on a 386 though...
<smoke> There still is no vertical retrace handler then? I started asking for this more than a year ago now :) .. think i really should do it myself :(
-:- link [[email protected]] has joined #ggi
<mks> bri: the same error both time
<bri> massacre: HZ is a #define when building kernel that changes timeslice granularity.
<massacre> ahh
<bri> smoke: go for it :)
* xer^jly_/#ggi is back from the dead. Gone 0 hrs 24 min 5 secs
<massacre> so no clues why my vard goes into stereogram mode? =)
<massacre> vard=card
<bri> mks: that's weird -- it built fine before though?  Did you do a CVS update in the meantime?
<smoke> Does anyone here know a great deal about user<>kernelspace signaling ?
<bri> Enough to know it's too slow -- even blocking on fds is slow.  IMO shared memory + fd blocking is the only way to go.
<mks> bri: no I did make config..although I didnt change save..then make
<bri> mks:  What's the exact error message Make gives?
<bri> ^M&m
<massacre> I'll definately get vgadoc though, its right off the ggi main page?
<smoke> And what function should be called from userspace to do a ggiPutBox() ?
<bri> Under devlopers resources, second link on the page.
<massacre> ahh ok
<bri> ummm..  ggiPutBox?  :) I don't understand...
<bri> Someday we all have to get Finn Thoergerson a case of beer.
<massacre> haha, a case each?
<smoke> I want to do some doublebuffered thing on the vertical retrace.. I already have a vr-handler of some sort using rtLinux. Problem #1: getting ggi to blit a buffer of memory in kernelspace, #2 Getting the framecounter to userspace. Any suggestions ? :)
<bri> Well, that would probably prihibit him from releasing vgadoc 4c or something :)
<MenTaLguY> well, I must go. see you folks around.
<Adamel> bye mental
<smoke> later mentalguy
* MenTaLguY/#ggi waves
-:- SignOff MenTaLguY: #ggi (ircII EPIC4pre2 -- Accept no limitations)
<massacre> aww.. I was hoping I could increase the horizontal size to like double what it is now.. get working video and just say that the problem is a 'known issue with a workaround'
<massacre> (man, I've been around Microsoft too much)
<massacre> hey! bri...
<bri> Yeah?
<massacre> Its drawing first on the second line.. with a horizontal bar, its going
<massacre> ______________---------------------
<massacre> (one pixel though, of course)
<Adamel> smoke: Well, the current KGI is somewhat limited. What you could do is open a display with virtual height == 2*visible, and then do a setorigin on retrace
<massacre> can you just open two framebuffer regions, of the same size?
<smoke> Adamel: that's a good idea
<bri> #1 requires each chipset driver to have a page flip function -- which would probably be best stored by expanding fb_ops.  #2 Would be best to MMAP certain parts of the GC for realtime communication... Becka may have played with doing this I don't know.
<smoke> Adamel: but how can i make a kernelmodule that calls ggiSetOrigin() ? (i'm not that much of a kernelhacker..)
-:- SignOff mks: #ggi (Remote closed. [1kb/29pks(0q)] [14kb/151pks(0q)])
<massacre> I think it would be best just to allow multiple framebuffers in a display, and to make sure people know they may not be turned on..
-:- mks [[email protected]] has joined #ggi
<bri> smoke: just add it to kgi module.
<massacre> then just flip to them.. There might be one 640x1600 screen or something, but it is broken down into four framebuffer pointers (four 640x400 screns)
<smoke> bri: ehm.. it should be a rtKGI module then i guess..
<massacre> or, it could be left so that they don't have to be contiguous..
<smoke> bri: or some option with a whole load of #defining?
<bri> smoke: That would be cool -- might even make me install RTLinux :)
<smoke> bri: rtlinux is worth installing -anyway- :)
<Adamel> massacre: Well, we're currently waiting for Steffens new KGI API, and until that there's not much point in messing too much with KGI. Libggi supports multiple framebuffers just fine though.
<massacre> where is rtlinux?
<smoke> bri: ftp.rtlinux.org bears the latest patches for 2.0.35
<massacre> ahh
<massacre> =)
<massacre> answer my question why don'tcha
<ShadowX> lastlog 50
* ShadowX/#ggi whoops
<Adamel> massacre: What question? Sorry, must have missed that...
<bri> But if not, your module should have an extern to the  KGI structures, figure out what kgi_display is currently mapped, and then call  dpy->set_origin()
<massacre> the rtlinux one =)
<mks> bri: its funny..when I use the original Makefile and 86c765.c
<mks> bri: it has another message that only is one line
<mks> debian:/usr/src/degas/kgicon/kgi# insmod kgicon
<mks> ./kgicon.o: init_module: Device or resource busy
<bri> What's the top of the makefile now say for -D DEBUG_LEVEL ??
<mks> 0
<bri> That's probably because you did dmesg -n 3 (to avoid having tons of stuff dumped to the screen.)  Look in /var/log/messages or /var/log/kern.log for the output.
<bri> mks: I meant, precisely, the whole line?
<mks> bri: right. I am changing it back to DEBUG_LEVEL=3
<massacre> do you already have kgicon.o inserted?
<Adamel> Yikes! I just moved the libggi internal includes to libggi/include/ggi/internal, over 200 changed files. :-)
<mks> no. debian:/usr/src/degas/kgicon/kgi# insmod kgicon
<mks> ./kgicon.o: init_module: Device or resource busy
<massacre> Adamel: have any clues to how I can remove kgicon.o ? =)
-:- SignOff smoke: #ggi (changing servers)
<mks> when I change it to 3 make result is, sorry for flooding:
-:- smoke [[email protected]] has joined #ggi
<mks> 86c765.c: In function `s3_examine_chipset':
<mks> 86c765.c:312: warning: passing arg 1 of `dump_state' from incompatible pointer type
<mks> 86c765.c:312: too few arguments to function `dump_state'
<mks> 86c765.c: In function `kgim_chipset_set_mode':
<mks> 86c765.c:1443: warning: passing arg 1 of `dump_state' from incompatible pointer
<mks> type
<mks> 86c765.c:1443: too few arguments to function `dump_state'
<mks> s3_mmio.inc: At top level:
<mks> s3_mmio.inc:794: warning: `save_state' defined but not used
<bri> If it segfaulted you can't.  insmod another (insmod kgicon -o kgicon2) :)
<smoke> re
<Adamel> massacre: Insert another fbcon module and map the consoles to that one, then you can remove the first one.
<smoke> Anyone said something useful on the vr or user/kernel things?
<bri> Oh, the header is broke.  Hold on...
<bri> Looks like you'll have to edit the 2 calls to dump_state (just commenting them out should work for now.)  Lines 312 and 1443.
<massacre> Adamel: actually it still says there is one reference to kgicon.o (kgi.o!)
<mks> bri: ok 312 and 1443: ohh I forgot which file :)
<massacre> I renamed it to kgi.o, insert it, and it apparently requires kgicon.o
<bri> mks: kgicon/kgi/chipset/S3/86c765.c
<mks> bri: right :)
<massacre> I dunno, I can't wait to finish this S3 driver though. My harddrive keeps getting corrupted from the debug text
<mks> im too silly
-:- SignOff link: #ggi (Leaving)
<bri> massacre: that should _not_ happen; haven't had a corrupt even though segfaulting kernel for some time now..
<mks> bri: I gotta leave, cya
-:- SignOff mks: #ggi (Remote closed. [1kb/26pks(0q)] [6kb/77pks(0q)])
<massacre> it keeps corrupting on me =(
<bri> Have you tries Magic SysRq?
<massacre> I haven't figured out if it happens as I use the harddrive (and it just thinks the drive is clean and doesn't check it), or if it only happens after something causes the computer to hang
<massacre> Magic SysRq?
<bri> New kernel options, lets you sync disks and stuff with commands using alt+sysrq key.
<bri> It works sometimes....
<massacre> ahh nice, like a SAK?
<massacre> =)
<bri> Not quite, the SAK is different.  It's under the kernel tweaking section in menuconfig.
<massacre> well when the computer has crashed lately, its been really annoying, because its obvoiusly a keyboard rpoblem, like asymbol table being overwrote
<massacre> ahh =)
<massacre> I gotta run, I might show up later. Thanks for the help!
<bri> no prob... have fun seeing double.
-:- SignOff massacre: #ggi (massacre has no reason)
<ShadowX> cvs server slow...
<Adamel> ShadowX: Well, I just did a huge commit...
<ShadowX> yeah i see, ggi-dl.h -> ggi/internal/ggi-dl.h or something like that?
<Adamel> ShadowX: Yes, over 200 files changed ;)
-:- SignOff xer^jly_: #ggi (ciao!)
-:- SignOff ShadowX: #ggi (Excessive lameness: 435015 (my clones are bigger than yours.))
-:- ShadowX [[email protected]] has joined #ggi
<ShadowX> nobody here now?
<ShadowX> !degas !give me log
<bri> here, but not checking this vc too often.
<bri> (me too.  want log.)
-:- BitchX+Deb1an: Unknown command: LOG
IRC log ended Mon Sep 21 07:49:06 1998

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.