heh, finally I got the log working great stuff Foske anything you say now will be in the official kgi log :-P foSke: Time to invite the people? :) foSke: I guess, you know, what I mean.. :) look at quiet it is after that anouncement :-) s/at/at how/ :) oki bughunter: Yeah, I get bounces, too. So we'll have to find Parish (I think that was his name) and find out why the account got nixed. philbo: had some trouble reading the BitchX docs how to get logging enabled Very inconvenient time for the GGI ml to go down :-( skids: I already informed irish. skids: But still no answer from him.... Right, Irish, that was it. what just happened? (other than .debs) (for ggi) Well, lately I've just been fixing/enhancing minor things, so nothing drastic. (And working on KGI targets, but since there's no .deb yet for KGI that's less pertanant to fresco) meiljp: I did put the TIDYBUF stuff into the devel CVS for X, so that mouse cursor slowness could be fixed now. I so want to have kgi debs. But I don't have the time required to read even a fraction of debian policies and understand their tools... philbo: maybe you want to speak to 'may' ;) hrm. may :No such nick/channel. I think we should hold off anyway until we can give a stable console environment. philbo: the ggi .deb-er skids: there is no 'slowness' wrt the mouse-pointer, just no pointer ;) skids: well at least people could see that it does *something*. ùíù mitchell_ [~mitchell@dsl231-055-100.sea1.dsl.speakeasy.net] has joined #kgi hi philbo: I dunno, I think having a .deb at this point would cause people's expectations to be rasied too high. hey folks, I'm just here to camp if nobody minds. mitchell_: Your "camping" time comes *just* right. :) skids: I think we're getting to the point where we need people to get interested and help out. I'm more than willing to answer all newbie questions mitchell_: np. hmm, cool. ùíù philbo_ [phil@HSE-Ottawa-ppp237685.sympatico.ca] has joined #kgi stupid xchat crashed on me. mitchell_: When you follow the discussion - the next hours in particular - you don't sorry it. :) My hidden motive is that I want to learn more about graphics progamming in linux. what's the relationship between kgi and ggi? here's one for a FAQ ð bughunter starts inviting people now. :) mitchell_: ggi is the userspace library for kgi (though it can do a lot more) That's what I figured. philbo: WRT AGP, I guess we have a choice of either mapping AGP sections entirely out of the AGP space when a process is not focused, or just making sure no other processes invoke commands that touch that AGP mapping (this is beside the subject of revoking the mmap for committed buffers, of course.) well, I'd say the reverse ;) kgi is one 'target device' for ggi :) philbo: I guess the former is more appropriate, but I don't know how CPU consuming that would be. mitchell_: kgi has a concept of accelerator pipes though which the userspace programs can safely send commands to the graphics card. But for the sake of sanity the commands are graphic card specific. So to make it actually useable we need to have userspace library that knows the different cards and sends the right commands. libggi has a very cool concept of acceleration libraries which get dynamically loaded and in case of kgi know what command send through the pipe neiljp: this is #kgi, we always twist things our way. For instance, fresco is one of window environments that can run on kgi :-) philbo_: fresco runs on kgi?! first I knew ;) ð neiljp grins skids: I think we should not touch the gart after the initial setup neiljp: well, I don't think anyone has tried yet, but if it runs on other ggi targets I don't see any reason why it shouldn't philbo_: well, the linux API does seem to be set up to map stuff in and out. skids: I think it would be way to expensive and I wouldn't be surprised if we encountered hardware bugs along the way philbo_: oh sure, I just meant that fresco runs on ggi, ie. that's the api it sees ;) ok, the linux folk was not that easily to make curious about kgi, when saying KGI has been redesigned and rewritten from scratch. Ok, I also said, the IRC meeting starts in about 150 minutes, so we will see... :) philbo_: and to take the contrarian position, not removing stuff from the GART will require us to do more expensive proofreading of buffers before allowing them to pass to the hw. ð bughunter starts inviting the bsd folk neiljp: hehe right, well, we're *extremely* kgi centric here :-) philbo_: oh, really? I hadn't noticed ;D ð neiljp wonders why the channel is called #kgi... ;) philbo_: and as far as expense, I guess we're only talking about doing it during VC switch. skids: I don't understand. How does a vc switch come in play there? I got only one quick reply from #debian. Namely a question, if KGI does ANYTHING ... :) If the card has an accel buffer owned by process A, and a VC switch occurs to process B's focus, then unless we map out the GART mapping for process A's buffers, they are accessible by process B through the GPU (again unless we do extensive editing of the command stream) Same reason why we should be setting all VRAM to 0 during vc switches. skids: yikes. that will require some serious pondering. Yeah, well, the security aspect is part of the KGI charter which we've been totally ignoring, IMO. ð mitchell_ tries to figue out how long from now 150 minutes is. skids: well the thing is that you'd only get access to the other process' agp space which is not as big a deal. We should stay true to the charter though mitchell_: about 150 minutes :-) I think we should for now avoid the idea that we can "save" on unmap/map operations by somehow protecting unused portions of AGP/VRAM, and start with a design where all state is cleared on vc switch. It's expensive, but simpler on the brain at this stage of development. philbo: Not a big deal unless that AGP space has a nice nude photo of Carmen Electra in it :-) mitchell_: In which channel are you present? :) skids: right, we wouldn't want a rouge applications adding some unappropriate appendages to pictures in a picture viewer :-) philbo_: even better :-) why do you guys discuss AGP BEFORE the meeting :) Out of boredom, actually :-) I'm on debian, redhat, lad, ggi and kgi Besides, you;re already logging, so you can cut a few "pre-show" bits from the log before the meeting. as for the meeting, I think we should start with the stuff that can be decided the fastest and progress to the more drawn out subjects. I.e., AGP the last. That way we might actually accomplish something. philbo_: sounds like a plan to me. indeed :) we should start with issues that need to be fixed to attract users Oooh, attracting users. I can speak to that. ð mitchell_ is a lUSER. :) mitchell_: cool. what attracted you? (so that we know what to do more) How about attracting lots of young female teenage users? :O) lol How about attracting Carmen Electra the keymapping issue, the deadlocks in the accellerator, the SMP issues philbo_: The fact that you guys actually have people on your IRC channel!!! "Crayon Electra" <-- what they called her in the Battlebots pit. the restoring previous console on closing a console (Cause "she's not the sharpest pencil in the box") skids: ahahaha redrawing a console when taking over Foske: I'll try to make a list philbo: see kgi-wip.sourceforge.net/news.html Foske: ok. I got some more of my own. oki and an important issue: snapshots, releases ð bughunter invited the free/open/netbsd folk. Let's see what will happen... hmm, how soon is it now? 2 hours? yup ok, well, I'm logging-off soon, so I might catch y'all then :) You know, I really like the framebuffer 'mmap' style of programming, but I don't know how I could get blt acceleration. Well, if we're going to be looking to do snapshots/releases/debs we'll have to address the keymap and linux VT emulation stuff, so we don't barf everywhere when the user's init scripts run loadkeys. ùíù soren [~blef@12-228-148-17.client.attbi.com] has joined #kgi mitchell_: direct mmap of the FB is overused and overrated, for various reasons: oh I'm glad I'm here to hear this. 1) if you're not working through a library, then you have to make all your code alter it's behavior based on the pixel format and pixel layout of the fb. michell_: GGI provides blt accelleration and framebuffer access, but framebuffer access is not needed, though many people shout they want it ah, see skids :) 2) If you do work with accels, you have to be sure not to draw under unfinished accels. 3) You tend to rely on stuff that's not portable. soren: Welcome to the KGI world. skids: very true. Often working directly on the framebuffer is more expensive than doing the stuff in the ram and then dma blitting it. Write's are slow and overdraw is a killer. 4) You don't bother to make the application capable of doing screen redraws, so it's very hard to port to a windowed environment. And probably some other good reasons I've missed. Those are all very good reasons. ð bughunter got a suggestion from a #openbsd guy why not going to #freenode and asking for a wallops announcement... that would catch _ALL_ channels! What if I want to write something for myself though and don't care really if it's portable or if it works nicely in a windowing environment. bughunter: don't overdo it. The discussion is meant to be technical, we don't want it to be flooded by 'what is kgi' questions bughunter, that'd be a bit overdone, don't you think? cow: Sure. Was just an idea from an #openbsd guy. You know, #openbsd guys tend to make things *sure* :) mitchell_: Ah, I knew I was missing the most important of all reasons not to directly use the fb: because instead of coding all those little subroutines you'll need, you could be enhancing a common code base (like GGI) that does it. skids: Furthermore, I use a very old computer and am constantly concerned that "portable" programming is going to make programs unportable to my machine, because it's old and slow, and there is always some overhead involved in portability. hmmm, but it might be a good idea for a irc net: have a bot which lists official events (meetings) skids: That is an extremely good reason. mitchell_: well, hopefully you will find GGI to be modular enough to keep your app's memory profile down. soren: In our meeting, that starts in about 2 hours, we will discuss about AGP and DMA transfers. Could you provide us with some ideas, how to do them in a *portable* fashion cross along many different OS's, please? mitchell_: No. Portability doesn't not necessarily mean slow. mitchell_: Have a look into this: http://derbian.org/pppoe/ bughunter: ok. mitchell_: It has nothing to do with graphics, but it shows, that NetBSD, which is intended to be *extremely* portable, is NOT slow... I see. mitchell_: The trick is to do things right. :) bughunter: as always :) mitchell_: soren here is a NetBSD guy, in case you have some (deeper) questions about it. bughunter: I'm not a netbsd developer, though :) ð skids will return in about an hour. I may be able to answer questions, but don't count on it cool. Thanks for talking to me man. soren: can you take over some more (net)bsd guys to join in here? :) soren: ... to fill in your lacks ... :) the accellerator code in the actual drivers for instance, uses some pointers where it can find the data it needs. the underlying OS layer makes sure those pointers point to something valid. this can be done very fast, and is very portable. ùíù testuser_ [~testuser@HSE-Sherbrooke-ppp121892.qc.sympatico.ca] has joined #kgi portability usually means: use a lot of pointers :-) bughunter: btw, in response to your DMA/AGP transfer portability thing. isn't that a non-issue because the core is supposed to be operating system dependent? foSke: ... or #defines :) the entire design of GGI is based on a fantastic usage of pointers hunty: your nick completion lags :) soren: It is an issue, because we need an interface, which a) abstracts the dependent OS code and b) it shouldn't cause too much overhead. soren: the core is OS dependant, but to the kgi driver side, we need an abstraction soren: Also note, that different OS's uses different API's and different mechanisms. we got the kgi core, which translates OS related issues to the generic KGI API. The actual drivers all use this API. foSke: I just do tab completion as I do on the shell. :) meeting topics: http://www.student.math.uwaterloo.ca/~fspacek/meeting.txt ùíù [Users(#kgi:13)] [ testuser_ ] [ soren ] [ philbo_ ] [ mitchell_ ] [ neiljp ] [ Foske ] [ ekix ] [ popel ] [ bughunter ] [ golbez ] [ skids ] [ philbo ] [ cow ] philbo: in that order ? right. you might benefit from looking at netbsd's dma interface philbo_: Third line: "borken" ? bughunter: 1337 speak ùíù anaki [lyc@terrato.org] has joined #kgi Foske: more or less. Feel free to suggest rearrangements soren: I did: http://kgi-wip.sourceforge.net/documentation.html soren: I just don't know, if the other people do. s/do/did/ ah. my mistake. didn't look at the web page. wow, I am no longer at the top of the user channel list. :) bughunter: we're not quite there yet. there are so many other things to fix before tackling dma ah... now we have an openbsd guy here. ð bughunter awaits nsouch then we have a guy from freebsd here, too. :) philbo: the memory leak in the accel code. donnow if that is Gx00 related, though and switching console crashed the accel system on my Gx00 SMP system. donnow if it is Gx00 or SMP related, or both, or neighter Foske: I'll add it to the list. (I'm suspecting that it might be related to our not maitaining the resource usage statistics properly more than actually leaking memory. i.e. top's memory useage includes mmaped memory) philbo: my "fix" of the fast_ procedures might not be perfect, was a mail from rodolphe about it on the list i'm not opposed to drop fast_, but i (currently) do not see why it would buy us, fwiw cow: maintainability? ùíù neiljp is now known as neiljp_offline hopefully be back later to eavesdrop :) Foske: well the book might say it can't do it, but the source quite clearly shows that the non fast_ versions work just fine. ùíù SignOff: neiljp_offline (Read error: 104 (Connection reset by peer)) philbo, you mean cutting down lines of code? that one for sure. apart from that (non-issue, imho) not much. contrarily it does a in my mind superfluous addition locking-pair. *shrug* cow: for we reinvented the wheel, made messy code of it that caused crashes on SMP systems philbo, as said, ok with me to drop it cow: the fast_ functions seem to have the greatest density of #ifdefs from the whole graphic.c, I fear that it's not going to get better cow: the code was really outdated and a wonder to work on UP systems anyone here, who has access to a UP system? philbo: it still used instructions that were more ore less invalid since 2.3 bughunter: anyone has when you compile your kernel without SMP support foSke: :) at any rate. Let's make the decision during the actual meeting to give other people a fair chance to object to it. philbo, '- libggi's kii target' libg_g_i? haven't seen that one, what was it? I object to any objections :-P philbo, sure cow: err. damn all those i's and g's. Fixed :-) wonders how to get rid of philbo philbo_: When you are about it, you can fix the "borken" spelling... :) /kill bughunter: no. It makes me feel cool. ùíù You can't do that, you're no deity :) cow: /kill doesn't work. Apparently I'm no deity. (now that one is new to me :-) lol.. radeon driver needs lots of work.. the ViRGE driver even more bughunter, btw, your so called fix to configue in ggi-core which was s/k.i64_t/__k.64_t/ doesn't sound proper to me. that one should be fixed for real and not bypassed bughunter, but that is just me nitpicking oh, and the NVidia driver.... we should drop it out of principle cow: Do you mean of libgii or libggi? Foske, yeah that one needs adjusting to the current cursor API. gimme hardware and i'd think about looking at it ;) cow: the NVidia one ? I can hand you some S3 hardware Foske, TNT2. i won't spell out that company loudly. especially not here ð philbo_ traded his TNT for a Rage128. Not that I have time to write a rage 128 driver of course :-) ð Foske puts some TNT under the companies main building *boom* ooops HE DID IT ! ð Foske got it on log... sorry, didn't intend to kill you guys. :) pretty quiet here, suddenly... ð Foske is cleaning up the mess buggyhunted made another point i like to hear peoples opinion is w.ether we should strive to build in drivers or not ? cow: That would be nice for sure. I don't know how much of a priority it is though. Foske, what was so cryptic about that one]. should we provide the possibility to have drv/ not only modular but built-in? philbo, i don't know either. tell me :) cow: how much work do you think it would be? philbo, not too much i think. i'd look at it mid-term, though as it is not too appealing todo and my sparetime is rather limited currently cow: I suspect that just getting it to work woudl be fairly doable, but getting it to work right would be quite hard (adjusting the build system and the kgi core) I was just working out ideas to make it much more modular :) philbo, the buildstuff is trivial, the core is more involved, agreed. oh, and we need more drivers too :) ð cow starts a build to test if the crt driver works proper for self and kgi should work on non-intel linux too Foske: I would like to do that one if I had a non intel box foSke: porting kgi over to netbsd would quickly open kgi to many hw-archs... :) and some should donate a nice non-intel box to cow, yeah ;) sorry, my G4 and G3 are not for donation Foske: I guess you'll have to do the work then ;-) neither my G4 ð bughunter awaits nsouch selfish human beings wherever you look :P nsouch said, there were two donations for the kgi project. a mach64 and one another graphic card. philbo_: willing to do that, though dpy-powermac.c will be a though one Foske: is that just an ATI card or something fancier? foSke: dpy-macintosh is more generic. :) and I have no clue how kii should link to the keyboard drivers I don't want to make the same mess of it as the ps/2 keyboard driver is philbo_: the oldworld G3s use onboard Mach64s And the current Apple iBooks comes with a Rage128. newworld G3s ship with normal AGP Rage128s. G4s ship with Nvidia Geforce or ATI Radeons Foske: getting the driver working as a boot driver would do it then. Though I can bet you'll have a hell of a time getting it to work on a big endian system (unfortunately when I wrote it I had hard enough time just getting it to work without worrying about endianess) ð bughunter has a ATI Radeon Mobility 7500 in his PowerBook ð philbo_ has a rage128 The latest PowerBooks come with a ATI Radeon Mobility 9000 Pro. usually fixing endianness is mostly fixing a bit in the pci config space and some chip specific bits And the latest PowerMacs come with a NVidia GeForce 4 MX or GeForce Ti 4 foSke: I think, anything that has to do with pci or agp space should go into a bus actraction. if only the register access is correct: framebuffer endianness errors are easy to find in 32 bit mode :) foSke: Note, as soon as someone comes up with porting kgi to a OS running on a sparc machine, for example... there's no pci nor a agp bus. foSke: Sparc machines have the sbus. foSke: and the upa bus for graphics (133MHz CPU <-> GPU connection) foSke: You see to not bloat the kgi drivers with code accessing the bus space, we need an bus abstraction. foSke: I think, NetBSD's bus abstraction layer is what we want. ok, then implement it foSke: All what we need to handle are two cases: foSke: a) the driver searches its card by searching through the bus space (that's the way linux and windows goes) ùíù nsouch [~nsouch@nas-cbv-8-62-147-159-172.dial.proxad.net] has joined #kgi foSke: b) the bus driver finds the card and the driver gets loaded. wnsouch, olla nsouch: hi hi there hi nsouch ! nsouch: may I introduce anaki (OpenBSD representant) and soren (NetBSD representant) ? foSke: b) is the way, *BSD go. Nice to meet them anaki: have you heard about the french guy working on openbsd port? nsouch: you mean soyt? ð bughunter wonders, where soyt remains... skids: please don't ask on which display... ;-) no, I'm looking for his name... nsouch: you mean soyt's real name? yes nsouch: Eric Faurot Exactly! So, he's soyt, ok. anaki: are you in touch with him? nsouch, he is used to hangout on this ircnetwork in #ggi cow: no, when soyt joins this irc network, he joins in #ggi AND #kgi members.aon.at/berny_f/kgi/kgi-0.9-buildsys_cleanup-O2-20030201-0.diff some linux-guy willing to test if that cleanup does no b0rk the build? ð philbo_ goes give it a try oh, and if there is someone who is aware how one sanely extracts cflags i would be glad to hear about it nsouch: how much people are now actually working on KGI/FreeBSD? cow: touch: creating `init/blErg.c': No such file or directory shall I answer? /me for code, pedro for advocacy philbo, hm. does blErg.c exist after it? if so i would tend to just 2>/dev/null touch there bughunter: there's no bug to hunt, but anyone can join :) cow: it's there. .o as well. k cow: that's a pretty evil way of getting the flags :-) philbo, after configure, does drv/display/.config have proper ..OPT_TARGET? philbo, potentially fragile, but i assume it is good enough for any linux-2.4. in 2.5 we (i) just patch a spitout_those_damn_flags target in kbuild, which is much more nice imho cow: it says only -D__MODULE__ (that doesn't sound enough) philbo, that won't work, yes. oh joy. -MysticOne- mysticone@mysticone.staff.freenode [GlobalNotice] Good day, everybody. My apologies for sending this as a notice, but we felt it was important enough to let everyone know. Freenode Radio is currently on the air, and is re-broadcasting CSPAN coverage of the Columbia accident today. If you're interested in tuning in, point your media player to http://stream.wopn.org:10000/modem.ogg or http://stream.wopn.org:10000/broadband.ogg additional topic in the medium category: general gripes or ideas about the build system -MysticOne- mysticone@mysticone.staff.freenode [GlobalNotice] Further messages regarding this stream will be given over wallops. If you'd like to receive them, simply make sure your client is +w, otherwise -w. Thanks for your time. skids: I fear that one might deteriorate into "do it cow", which wouldn't be fair skids, .. including putting the chipset specifics to ggi's include hierarchy ùíù soren [~blef@12-228-148-17.client.attbi.com] has left #kgi "sorry, had to run" cow: yeah that one is definitely needed but seems just impossible accel: memory mappyng versus block copy. the latter is faster in most cases mapping too skids: Did you read the bus space stuff, I said above? philbo, hm? we would just have an install target (st like make all install) which would make all "drivers" and put the necessary includes to where we agree they belong, nack? nsouch: soyt is currently busy with reworking the GGI site. Foske: that's the big question I guess. It's full of trade-offs and we need some hard evidence about exactly what the speed difference is philbo, (guess who would be the only idio^Wvolunteer to do the install stuff. hrmpf) nsouch: You can visit the new site (which is not ready yet) at: http://users.info.unicaen.fr/~faurot/ggi/ bughunter: I think we need to meet the challenge of getting it to work on i386 first, then worry about bus abstraction. It's too soon for that, unless someone drops fully working code right in our laps. cow: Hrm. yeah, I guess that would work. For some reason I was always thinking up ways of coordinating the ggi and kgi trees to pull the header but I guess installing it would work just fine philbo: it is, cause Linus said so :-P philbo: well, it might automagically be the solution to our memory leak Foske: Linus also said that kgi sucks (or rather ggi as it was called at the time) :-) Foske: That's just because you are using small chunks. cow: do you have some sort of introduction about the whole architecture of the build system? I'm personally quite lost in it. I'd be willing to help out a bit with some direction (even though my sed skills are definitely lacking) philbo, coordinating the kgi an dggi tree does work today already.. just configure ggi --with-ectra-includes="path/to/kgi/include:path/to/kgi/drv/display/chipset/*/" is enough for freestanding. an installed base might be more easy to handle for casual builders, i guess philbo, s/ectra/extra/ of course bughunter: simple and nice, I like it. skids: indeed. in 2.5 kernels, you flush the entire cache system, while a block copy automatically flushes only the small block used this is aparently a very huge gain Foske, you have to flush the whole mm there, yes. sucks big time, imo cow: sucks bigtime, though the reasons are good (flushing only a part was nothing faster) ùíù SWAP: Window 1 is not hidden! Foske, stupidity and conveniance dumbass attidu_d_e never was a good reason in my eyes, but ok. futile to argue about it anyways Foske: May make sense to implement that for short accel groups. Foske: flushing cache is a noop on intel huh ??? Perhaps it would help if we knew where the break-even point between flushing the tlb and # of blocks block-copied. s/./was./ that inv* instructions aren't exactly noops philbo, no. flushing the tlbs is very expensive Foske: intel's cache is smart enough (just grep include/asm-i386/pgtable for flush_cache). tlb's are a different thing though. skids: that break even point depends on cpu speed, bus speed, memory bus width... Anyway, t- 15 minutes and counting, so let's save this discussion for the meeting. Foske: I think we owe it to do both, whichever is faster. skids: we are definitely on the wrong side of the break-even point as for the size of our accel buffers every operation is done entirely in cache really an eager to find that leak as a sidenote before the official fun starts, i think iff we would split the graph device in two, we could make the easy --non-accel-- part through macros, fwiw ð cow feels stupid to repeatedly express thos obvious crap, but anyways cow: I don't get it. What part though what macros from where? ð bughunter expects ortalo, soyt and t0dd joining in soon. erm, /part/part os independant/ what time do we start dudes 10 minutes golbez! from now golbez: hi hi golbez hello 10 minutes.. I thought I had an hour. No beer for me :( golbez: though foSke is already logging for about two hours... :) cow: I see. yes, we could. The ping-pong nastiness would be quite separate which would make the porting much easier. I'm even toying with the idea of using the standard write interface to write to the accel pipe stoopid log has ANSI codes in it... thanks BitchX :) bughunter: Iè have been logging for about 4 months... golbez: are you kgi's IRC bot? ð bughunter tries !pizza 5 bughunter, please... will ya? :%/^*m//g eh :%s/^*m//g lol philbo, if nothing else, it would make porting easier for nsouch philbo, are there any reasons against using the generic write intercafe? ð cow grins interface ùíù ortalo [ortalo@pppport12.laas.fr] has joined #kgi ortalo: hi welcome Rodolphe, glad you could make it Hello everyone. ortalo: you here on *the* minute. still missing soyt and t0dd maybe ? ùíù [Users(#kgi:14)] [ ortalo ] [ nsouch ] [ anaki ] [ testuser_ ] [ philbo_ ] [ mitchell_ ] [ Foske ] [ ekix ] [ popel ] [ bughunter ] [ golbez ] [ skids ] [ philbo ] [ cow ] yes :) cow: you don't get a per-mapping context okay. for everyone here already: http://www.student.math.uwaterloo.ca/~fspacek/meeting.txt for a little agenda philbo, hm. that's suboptimal then philbo_: regarding "crt driver should become default" : philbo_: Tomorrow, I'll do some more tests with the mach64/crt driver bughunter: glad to hear that give those lazy guys 5 minutes, or shhall we start ? philbo_: Maybe, it works, when I start the GGI app from console 1-4. philbo_: The reported issue happens, when I start the GGI app from console > 5. >= 5. philbo, what does it say if you manually make -f Makefile init/blErg.o ? ùíù SignOff: nsouch (Read error: 110 (Connection timed out)) philbo, i'm still intrigued that it doesn't work for you for some odd reason oh nice, connection issues ùíù nsouch [~nsouch@nas-cbv-7-62-147-155-249.dial.proxad.net] has joined #kgi ùíù njs [njs@12-232-144-227.client.attbi.com] has joined #kgi ð bughunter didn't notice, that nsouch left. Testing the crt driver is on my next list of todo things. welcome njs crt driver works almost flawlessly for me 'ello. I'll just lurk, I think. Are we started then? ok. donnow if soyt will make it First I want to make compliments about the progress we made in the last months ok. (someone volunteer to coordinate?) ok.. top of the list: the crt driver is it good enough to replace everything else éI think so. I am fine with the CRT driver being the default, but a few caveats: 1) Should be integrated smoothly into build system 2) Failure to set valid timing when DDC1 fails on Radeon (valid timing negotaited, but doesn't take) 3) DDC2 would be really nice (otherwise people have to power cycle monitors if they run a DDC2 app.) IMHO it is, though we need an option to tell the driver not to do ddc How does it handle plasma, lcd, tft displays? bughunter: My tft eats the mode just fine ok someone here is plasma and/or lcd displays? s/is/with/ though there is a minor issue that I want in future... skids: 1) assumedly fixed once it becomes default 2) will need to work on that, any help appreciated (i.e., works here) I am working on DDC2. can't do anything more than say that :) bughunter: crt will be better on a lcd than the other drivers, because at least it bothers to ask the lcd what it can do, the other drivers just fly off and send what they think is a "standard" mode but the LCD might have a different opinion on that matter. a) what was that stuff with reversed order of found modes from monitor? b) who will (? needed?) fix the mode-negotiation loop regarding LOWER/RAISE? A tft has a "preferred mode", for me it is 1280x1024 @ 60 Hz. this is part of the DDC data. this means if the user requests a default mode, the monitor driver should propose it, not the chipset driver Ok. Since nobody seems to be radically against it, it's agreed on. I volunteer to do the work of getting rid of the rest (should be a good exercise in understanding the build system). Any concerns should be directed to me. I should really try something different from the SVGA driver for the monitor! ;-) then the crt driver should have a name sounding more generic like "unimon" or something like that, to not confuse users. ð skids agrees. bughunter: good idea I am pretty sure, that user will come and ask "can I use it on my tft?" ð Foske has seen the stars already in 1280x1024 :) ð ortalo Trying an "action" but they all support crt timings! it's a driver for all display devices that support the crt way of setting display mode bughunter, ortalo, i tend to agree with philbo that "crt" does match quite well okay. philbo_ will start the cleanup. what about my comment ? ð ortalo wonders how you can really see the stars at such resolution Does it really matter when the monitor driver is compiled into the display driver. It is rather transparent to the user... no reactions ? i do not see why we should rename a directory (in cvs!) as users are _NOT_ supposed to be bothered with it when it is the default monitor driver. Foske: I'm for transferring the responsibility for setting the default resolution on TC_PROPOSE from the chipset driver to the monitor driver crt definitely is wrong, but ok. make it general for now ? Keeping the dir is fine IMO, just the configure system should call it something other than crt. philbo_: Independent of the common technical base, user thinks, those are different (because they look different?) it is in the monitor dir already As in, the front page menu where you select the driver. cow: what do you mean by the fixing of the mode negotiation loop If there is not DDC, can the monitor propose a decent default mode? ortalo: only with parameters about the monitor applied ortalo: if you tell it it's limits via insmod. ortalo: only if you manually specify limits because ther is no decent default that all monitors will support okay, details will follow in a document I'm going to write on the driver. skids, the config-system will not provide a choice for selecting the "monitor"stuff anymore. just the boards which have to build (which should be "all" sooner than later anyways; e.g. either fix or hide the TNT2 thing from configure) philbo: can you rearrange the proposal loop while you work on the cleanup ? I'll do the ddc2 stuff asap more comments that need everyones attention ? Foske: should be trivial, I'll add to your document what change to the chipset drivers is neede (basically only matter of *not* setting the resolution when it is 0,0) OK, then the last thing is, what do we do with all those hard-earned timing lists and frequency ranges? philbo: ok cow: When you are about fixing up the dialog - could you fix it up for 80 column textmodes, please? skids: there are no hard earned timing lists (the crt driver has the greatest list of all the drivers in cvs), for the range we need a .spec->arg script ùíù fraggle [~fraggle@tuneless.plus.com] has joined #kgi skids: imho they were crazy from the beginning, for now we could store them somewhere, so we could use them in a user level config tool philbo, the mode negotiation currently checks against the monitor if all other subsys already agreed. iirc i locally had to run through four loops to get a (somewhat) proper mode as my crap monitor is limited to a quite low resolution which the other subsys need to be lowered to match fraggle: hi philbo_: I don't know about you, but I spent a good deal of googling trying to get the HP timing list. hiya philbo: it isn't that easy maybe. has to be checked out. That database isn't exactly complete, but it does have some data well worth preserving. skids: ok. Let's make a script for those too then. (the crt driver has a parameter for specifying extra timings) okay. please keep the database for later use on the command line, but remove everything else not crt-related Should the CRT driver have an option to build-in timings, top be used as a boot driver? fraggle: Which OS/hw-arch do you run? ohm and someone should document the module params thoroughly and in depth cow: I will next subject ? yes (if no one objects) default keymap is broken ð cow listens to ortalo skids: I suppose, yes. Let's leave that till we can actually use the drivers as boot drivers. What is this problem? (First time I hear of it I think.) when you compile KGI from scratch, starting an app on ALT-F1 opens a graph that maps to ALTGR-F2 With graphic minor at 0? ð bughunter agrees with skids indeed Foske: is that keymap related? ð Foske uses /dev/event and /dev/graphics minor 0 for weeks now nsouch: someone here said that, I assumed it was an off by one calculation somewhere That's a compiled-in keymap? (I usually need to use loadkeys myself before ALTGR works) ð bughunter reminds, that the AT->PS/2 scancode conversion is broken ortalo: yes, the .de keymap actually from my experiments, it is indeed keymap related. The default keymap has altgr mappings wrong philbo: I'm fine with waiting on bootable-crt, too. kgi still finds two keyboards - one AT and one PS/2 is minor 0 trusted even on non-devfs systems, btw? if so we should reflect this in cvs.... cow: it is trusten completely now Is there an opensource "keymap editor"? though I have physically one AT keyboard connected to ps/2 via an at->ps/2 adapter. (just did a quick check and pressing altgr-f4 wants to go to console 66, one off) philbo: exactly, that is the issue where one can find loadkeys by the way? nsouch: console-tools. Look for it on sourceforge should be 67 Foske: 65 actually no, 64 + 4 - 1 ùíù oxygene [~oxygene@195.227.14.232] has joined #kgi oxygene: hi hey bughunter Foske: right. My bad. whe need someone to look at this we too I'm lost in the keyboard code... philbo_: you and I just made the same thinko. Scary. I've done some keycode stuff lately, so I guess I can fix that. philbo_: oh, you can add that to your list ? Foske: sure. It should be quite easy to fix anyways. next subject then: snapshotting / releasing kgi. who will focus on satisfying loadkeys and fixing keymaps as soon as possible? that one really should be top priority, although it is unsexy to fix, granted Regarding "debian packages, snapshots. too early?": There are several possibilities: cow: you mean strings? a) we go the BSD way: Develop deep changes in a branch and merge it to -current, where -current is the main cvs tree (advantage: main CVS tree is always stable) b) we make a snapshot, break everything, stable everything, make another snapshot c) we make a snapshot and open a devel and a stable branch as we do for GGI ð cow nods philbo bughunter hold back a little... bughunter: that's awfuly involved. We just need something that woudl be easy for people to try. Right now just get a kgi enabled kernel is a pretty major pain. c) I vote for c for now, and we should have a list what to do before we release a real version c) Debian users pretty much expect .debs to be drop-in and more or less production quality. At the very least, any .deb package set should create all the device files and deal with any init/config file conflicts like loadkeys. (Or we could just FIX the loadkeys thing :-) c) but what about loadkeys? i won't do it.. so any takers? anyone feeling to take this one ? with sourceforge help it should be easy c) for me as well. Isn't it KGI, not loadkeys, that's broken? kgi-wip standing for -current, kgi for -stable? cow: I can look into it, but can't promis anything. Is it really that necessary? i.e. Linux VT emulation? It would be nice to have something like a kgi-kernel Debian package too. But maybe it is a pretty difficult task (that's the kernel). ð golbez thinks c too nsouch: we have no control of kgi tree, but we can abuse the cvs of it as the stable tree, yes c) with "stable" and "HEAD" that is. anything else is unacceptable. string-nitpick, though ;) ortalo: It is, because to do it right your patch has to be reversable. skids: why? philbo, we really have to fix it asap, yes Shouldn't you be keeping both the stable and development trees in a single cvs repo, to make merges easier? nsouch: We can do so, once steffen is back (at least, when he gave us CVS write access) It has to work with make-kpkg utility, which allows you to choose the patch-set. a few of us has write acces, don't they ? njs: you're right well ok.. single cvs repo I could try write access again but last time I did I think my auths were stale or something. kgi-0.9 tree and a kgi-current tree ? cow: ok. I'll put it higher on my list then. single cvs repo is probably much wiser... skids, i think it is KGI, yes. we need to \"satisfy loadkeys\" e.g. verify and write the fn_string stuff proper, somehow philbo, great Foske: no same repo, same trees okay, volunteers for the cvs tree stuff ? just tags to maintain branches Foske, kgi-0.9 module, branch "stable" and our normal HEAD. i will tag the stable branch, soon, if nobody objects okay. cvs "split" assigned to cow ack Shouldn't it BE stable first? :-) note that branch points are needed to track branches skids: didn't you hear? assigned to cow :-) For the branch tag we should use a clean namespace to not come into naming conflicts later with multiple branches. skids, indeed. that's the 'soon' part :) skids: we should rework some of the core stuff, I don;'t want to do that while we're so close to something stable Probably... Cow, please, do a full committers roundtable before actually create the tag... philbo, heh! ortalo, ok I suggest to use the 'branch_' or 'branch_' scheme for branch tag names. bughunter, no veto :-P details have to be worked out later (we got real issues later on, so I want to keep this short now) I' rather tag with "kgi_0_9" , "kgi_0_9_2", etc. cow will be on it. Untill "kgi_1_0" of course... ortalo: yep OK, so we make it stable, and then cow tags it stable... next subject? issues that need to be said about this now ? ùíù neiljp [~neil@du-069-0655.access.clara.net] has joined #kgi neiljp: hi libggi's kii target needs fixing the kii issue is kind of selfish, because I need it to have a working xggi on kgi ;-) When I added the auto-open of the KII target I found that it will open /dev/event twice if GGI_INPUT is also set. Got to figure out how to keep it from doing that... bughunter: hi bughunter: is this something for you ? did I miss the entire meeting? foSke: libggi's ? You mean libgii's kii target. neiljp: ongoing bughunter, it already is -0.9; that is enough. fix it up for good, combined with a rewrite of hairy parts and we could argue about an kgi-0.10 module, if you really want cool :) err of course njs: ta filip made a typo :) neiljp: no, but you missed the first two topics... :) neiljp: We're not even through with the "quick and easy" topics yet! :-) s/two/three/ skids: ah, damn, I knew I should have been here just for those topics ;) okay, what is the issue with it ? the kii's target .label field on events is totally bogus the inspiration for fix should probably come from linux_kbd Is that why enter don't work in demo? skids: could be. cow: oh, don't forget to make some snapshots too :) anyone on the ggi site that wants to look at it ? It's a mess but it's the last part of making libggi/libgii fully useable on kgi philbo_: Or linux_evdev... ð skids thinks we should change the splash screen. bughunters todo list is still empty ? :) sorry, random thought there. bughunter: say, you seem to know a lot about that :-) He wisely became silent foSke: hehe - no. It is full. bughunter: too full to take this one extra ? cow: and tags before huge changes foSke: I am working on targets for macosx/darwin, I am working on libgpf... well, lets move on. People know about the issue. If anyone has nothing to do at some point in the future, they can look a it. oki philbo_: I'll take it. example from freebsd tree: RELENG_5_0_0_RELEASE: 1.26 RELENG_5_0: 1.26.0.2 RELENG_5_0_BP: 1.26 RELENG_4_7_0_RELEASE: 1.20.2.1 okay. asigned to skids skids: great philbo_: Today, I had a deeper look into linux_evdev for improving libgii's input driver for macosx/darwin. :) next subject: restorint previous devices after closing one restoring too bughunter: don't you have vgl under darwin? after closing a graphical device, it remains displayed The proposed fix is to just go back to where the app was started from. But what if there is no such device (app started remotely) or it disappears in the meantime (higly unlikely) philbo_, skids: But I am there, when I get bitten by bugs by libgii's kii... :) nsouch: no. nsouch: There's no vgl under darwin. I liked the model where each console "slot" had a graphics and a text device associated with it, and when a graphics app terminated it would go back to the corresponding text vc, skids: I second this behavior. you could switch between graphics/text with another key (maybe ALT-ESC) and the system remembered with mode (graphics or text) each slot was in. s/with/which/ However, as philbo pointed out, we need to think about how this would work in each of the various configurations multi-head can assume. skids: even if the graphics device opened doesn't correspond? I can open /dev/graphic4 from console 1. Would that thow me back to the login screen on console 4? easy: opened from console 1, so return to console 1 ? err hmzz Foske: righ. But what about apps run remotely? skids: You mean, to display a (text) menu with ALT-ESC as like as Novell Netware does with CTRL+ESC? well, I assume the login was displayed before on the display... I think the problem is that we haven't even considered the basics of multihead console switching, nevermind text vs graphics. skids: you don't have an xterm for every X appli... nsouch: true, but that's a UI decision. I think the above gives a natural "multiple DOS 6.2 boxes" feel. s/2/22/ I think, go back to whatever was displayed before, will do it How bout going back to where the app was started from and if there is no such device then just go back to the first device on the display (which would be the first console). Arbitrary choice seems better than no device being mapped whatsoever (especially since this cases is unlikely, who needs to run graphical applications remotely) bughunter: no, alt-escape would go to text from graphics, or from text to graphics if there was a graphics app running in that slot. what is text if no text mode support by the board? philbo: Well, if you're going to do it that way, you probably should just go back to the last text VC explicitly requested. if whatever displayed before doesn;t exist, go to related console. if related console doesn;t exist, display last console mapped to that device. If no consoles mapped to the device display nothing or a KGI logo is that what i mean by (asummed there is vt, that is) how to trap openvt -s -- logout nsouch: if no text mode is supported by the board, then naturally the app must have not been started from a vc on the board so... ... KGI logo. ð skids moves to break this topic out into a committee -- let's rope some random unsuspecting users in some discussion group somewhere into arguing about it. ortalo: text or graphic? :p skids: you think so? For example currently when x crashes it throws you back to where it was started form no matter which vt you were on most recently. Seems pretty intuitive to me. if a board supports no consoles, it switches back to the previous graphic mode set, if no such mode (no graphic consoles left open on that display), power management seems a good option :) we're hanging in the void for that case, currently as the kbd handler has no focus or the like philbo: Actually I find that more annoying than intuitive, like when I kill X from the command line and it chucks me to another VT. cow: I'm not quite sure about what would that do. I suppose I should experiment with that skids: you forget X has no focus then ! Foske: ? you kill ANOTHER console, so nothing should happen if that maps to the same display skids: hrm good point. another (graphical) console philbo, i experimented with that one a while ago and as long as we do not have a 'global' active kbd handler we probably should fallback to the last (whatever this might be) focus It seems to me there are pro and cons to every behavior. But, globablly, the thing that emerges, is to go back to the last known mode on the head. if (has no focus(killed_display)) do nothing or something err if (not displayed()) Shouldn't the console system be a loadable module itself anyway? Like so you can choose your flavor? maybe the strategy should be configurable philbo, i'd be interrested to help in handling that case, though. it's an interresting problem, or design problem if you like ð ortalo checks why the baby is angry. cow: well, I have no idea about the issues involved here (and I suspect neither has anyone else here besides you) so lets defer that till more of us gather some information about the problem There's no reason not to have it N ways. among static rules of course philbo, k yeah ! have it N ways ! so noone can work on somebody elses computer ! :) anyway, somebody wanting to volunteer to check this out ? ortalo: last known mode requires an arbitrarily large stack of 'previous' as they can disappear set -o vi and see what happens! I guess the problem is clear so what about the logo thingy? What's the easiest one to implement in the short term? cow: is nice, though DPMS power management is a nice one too. Foske: I can take it as I have pretty good idea where it would go philbo: you are not overloading your todo list ? Foske, philbo? nah, he never would :P :) okay then Foske: no no, most of the things I volunteered for are simple fixes once agreed on. (except for the crt stuff that is) oki cow: you want a new logo? this one is easy too (except for the rare non-console cases) skids, what exactly were you thinking of (logo-wise, iiuc) name noted. SMP issues and fast_ functions philbo, skids seems to my favourite :) cow: well, "The Right Thing To Do" is a bit preachy IMO, but mainly, s/GGI/KGI/ skids: we might want to put a smiley there Foske: mine as well okay. as you all might have read on the mailinglist, I fixed SMP related issues by removing our own code, and replacing it by official kernel code philbo, that'd be proper, yes I have always been in favor of a big orange "It is now safe to turn *ON* your computer" not everything is set now, but basic SMP support should work. But that should wait until we have high security/stability. It becomes very clear to me that we have always ignored the need of locking I propose removing the fast_ functions. They are old hard to maintain and we don't really get much benefit from them shouldn't we start with a giant lock? then reduce the grain philbo: I agree, though we shouldn;t ignore ortalos remarks regarding the accel skids, so.. want to remove the kernel-config option for now until we settle on a new logo as it is likely that no new users will be interrested to debug eraly boot? nsouch: like (re)introducing the "Big Kernel Lock" ? Foske: the source code for remap_page_range clearly shows that it is safe to use them no matter what the book says philbo: yes and have arch abstraction in VM management nsouch: we should lock every bit of code that accesses registers Foske: safe in the sense that they do the same thing as the fast_ version philbo: ok, but it doesn't explain the memory leak somehow cow: Yeah the real reason for the logo was to slow down to read boot messages. Since the boot driver no longer seems to need debugging, it could probably just be removed and later we'll do some sort of logo like the fbdev pengiun. having a logo is useful if only so it's immediately obvious that your kernel patch has succeeded... I will start to work out locking abstraction skids, k. i'll simply drop the menuconfig option for now skids: thanks for the info, I love historical reasons nsouch: I was meaning to have a talk with you about what exactly is needed now that I'm toying with splitting /dev/graphic but I suppose that should probably be done outside this meeting please keep things together guys I think we should really do more attempts to use the native remap_page_range() functions. ortalo: sorry ? we do it already now ? hard, I think. graphic is *very* OS dependent, first because of the unix API (open, ioctl, mmap...) Foske, ortalo, philbo agree on removal, cow doesn't care either way. But (changing the way we) playing with the VM is always touchy. We should kill them for now, and concentrate any effort along these lines, if any is needed, on the BSD and Linux 2.5 VM. Arch independency and OS independency shall be addresses in parallel .... fast_ .. fwiw, as said before ok with me to drop, although i do not see an advantage. otoh it probably would be well received to reuse existing (but sometimes suboptimal) infrastruc I'm willing to look on the locking, but if someone else could track the leaks ? nsouch: right. Well /dev/graphic is just one of possible mappers. But anyways. I'll email you about all my ideas so that you can tell me what would help the FreeBSD port. might be Gx00 related I can try to locate these leaks. (As soon as I can reproduce the thing.) oki Foske: once my Tyan bi-AMD has CPU and memory ;) ð skids won't volunteer for any heavy kernel work -- 2 SCSI controller BIOSes serving lots of devices take > 1 minute Foske, can you quickly descibe an easy way to reproduce/observe 'em? philbo: ok nsouch: thanks, will assign it to ortalo for now So I take it we are agreed on removing fast_ functions. At least we should try to remove them. philbo, well, looks like cow: my setup : SMP kernel, Gx00 (G400 AGP) display=1, top on a console on display=0, accel demo running full speed on ALTGR-F5 and see the memory counter growing Foske, k Foske: for kernel or for the accel demo? not tested wheter it is SMP or Gx00 specific for the kernel mem, accel stays fine accel demo Can you send me the offending program (unless it is one of the LibGGI programs)? ortalo: abused libggi/programs/demos/demo removed the 3 seconds check on the random box drawing foSke: I thought, you used the stars demo? bughunter: wasn't sure that one was accellerated okay... fine. next proposed point or point in agenda is ? CONFIG_INPUT philbo ? what about it ? foSke: Just guessed, because you said again and again: "I saw the stars" :) I have a fix that makes sure kgi doesn't use kii/keysyms.h (leaves them for userspace0 Do people think this is a good way to go? something we should put in HEAD right after the having tagged? I suppose use of all the K_ stuff is very specific Every time I look at KII I get depressed, so don't look to me for solutions. nsouch: do you have any opinions about how linux specific kii is? We need K_ syms as long as we have our own console implementation, and as a result, we have this huge set of #defines that varies from OS to OS. skids, :) disgusting it really is indeed ð ortalo thinks that this baby really wants to use ggiPutBox()! bughunter: ah! smoking while hacking... :) philbo: it's not so, removing it is not an option ? ð bughunter is a militant non-smoker I've ported KII + written input drivers and a device for FreeBSD console bughunter: militant? starts working except that console switching is not yet managed by KII i.e this entire thing is a non-issue, besides that KII needs a cleanup :) Foske, yes, i think it's not. we should rather look at something like a "console-stackker" mid- or rather long-term, imho ok. let's move on then. ð Foske hears someone whispering about long-term great... one issue not on the agenda: skids: why so? KII is not that bad. skids: s/militant/unyieldingly/ :) VT switching causes Accel deadlock. At least on SMP systems with the Gx00 accellerator, though I think it is a design flaw bughunter: As long as you keep your militant tendencies to yourself I guess that's OK. Foske: do you know the cause? seems not to be solved with locking, is a race: cpu 1 assumes something still to come while CPU 2 has passed it wait_idle in the graph_accel_nomap (iirc) waits forever nsouch: I think we are trying to do too much with KII. I'd prefer to see the OS mainstream decide on their console system, and if they pick a lame one, they suffer. So the "wake_up()" does not go though. ortalo: maybe an issue for you ? you got SMP and are known with the accel code ? Are you sure that the buffer was indeed executed and that you got the SOFTRAP end-of-buffer IRQ? but KGI must know about special keys (switching at least) ùíù scanlime [~micah@aden2-42-dhcp.resnet.Colorado.EDU] has joined #kgi The problem is that I do not have SMP hardware, so maybe I will not reproduce the bug. But if I can reproduce it, yes I can try to track it down. it is perfectly reproducable for me, just switch away and back ùíù SignOff: scanlime (Client Quit) it might occur on single CPU too never checked it though ùíù scanlime [~micah@aden2-42-dhcp.resnet.Colorado.EDU] has joined #kgi ok. please let me know if you need help now... the big issues AGP support ð Foske shuts up wisely nsouch: If we ship it as is. We could also just ship a KGI that has an in-kernel API, and then as a separate project console systems could be hooked in to use as much of the KGI API as their design limits them to. ð bughunter made already his statements about bus space abstraction... :) I think most people view AGP-GART, PCI-GART and other DMA stuff as being "for accel". There are more uses, and I consider accel FIFO itself to be perhaps the least important: My list: 1) Textures 2) Vector lists 3) various LUTs 4) Accel FIFO skids: agreed Okay, what is new with AGP-GART ? or is it just yet another bus system ? ùíù SignOff: philbo (Ping timeout: 14400 seconds) skids: right. But do OSes have better console than KII? NetBSD is supposed to AFAIK. ùíù philbo_ is now known as philbo Note that 1) and 3) never need to be mapped out (except for focus changes) even when they are committed, and with proper driver coding we can make it so that 2) never needs to be mapped out. indeed. There are two separate issues here. How to use it in kernel and how to expose it to userspace. I suggest we start by discussing how to use it in kernel. are we there with bus abstraction ? nsouch: whether theirs is better or not is not the point. The point is that KGI has a boundary, and it's the mainstream developers (or sidestream devels) that are responsible for taking advatage of what KGI has to offer. 0) Pictures (putbox) nsouch: and openbsd, too... skids: wrt kii, how about we strive to make kii just another one of the possible console layers? Foske: AGP also has another specific translation table... philbo: works for me. guys, can we leave KII now please ? of course, they share lot of code. ortalo: I was considering putbox to be texture Foske: done. IMO, in-kernel, AGP raises the problem of "graphic-capable" buffers. ð bughunter wonders, how to access busses (agp, pci) from kgi driver side. ... because there are two cases to take over: a) the driver finds the card by searching through the bus b) the bus driver finds the card and loads the driver AFAIK, b) is the *BSD way. bughunter: that's not very relevant to agp a) is no case, it is on top of b) ~bughunter, non-issue. is (will be) abstracted in drv/display/system/whatever/system cow: ok. but that's relevent to arch/OS independency (which is everywhere :) what we need to figure out is where/what sets up the gart, how is the driver notified about it and how is this memory managed (be it for accel buffers or to expose for userspace) We can't support a new bus with addressing arch issues. -the detection system should be removed from the chipset driver, wich is a part of the bus abstraction issue, which might solve some AGP issues as well I would say that AGP buffers should be mmapped above the VRAM on /dev/accel, even if they are textures. When the mmap happens, OS facilities for allocating the space are invoked, and if successful, the mmap is successful... is that simple enough? We need some management functions in-kernel so that a driver can check that some memory area referenced in the accel FIFO refers really to some "KGI graphic buffer" and extract the characteristic of the area (AGP capable or not, DMA, etc.) real question is about the silly impl details involved with it or rather policy Foske: Ack. nsouch: I like NetBSD's bus and DMA abstraction layer. so maybe buggyhunter wasn't so wrong at all maybe we should implement bus abstraction first before we deal with AGP issues Foske: AGP is not the only issue there! skids, too fast for me but does sound simple enough for me at a first read and as buggyhunt likes it, I also declare him the volunteer to do that hm Foske: currently, even via regular PCI accesses, we do not know in KGI how to use in-host textures... Maybe we should just start with a kgi_agp_* set of functions which implement the least common denominator of the immediately available OS facilities. Then, someday when we are sprucing things up, we can change that API to be a bus abstraction layer. ortalo: so true, this sounds more and more as a need of an abstraction layer links to NetBSD's bus/dma abstraction layer are available at http://kgi-wip.sourceforge.net/documentation.html Does everyone agree, when we use this API as is? skids: you the agp code, buggyhunt the bus abstraction ? :) bughunter: Anyway, prototyping AGP does not need full x86 independency bughunter: I expect a lot from a future NetBSD port for Arch issues... philbo, a gart resource is nothing more than a resource. a drv does not (?) need to be aware of type, shuold it? bughunter: might be nice to use it, saves a lot of efford on bsd systems If we do go for a bus abstraction during the first pass, then we should not try to make it work for anything but AGP. Once it works for AGP, we let it be. I don't want to see us side-tracked into become also the "KBI Project" nsouch: How much does NetBSD's API differ from FreeBSD's one? cow: a driver's resrouce? Is it the card driver that sets up the gart? bughunter: not much USB, ISDN, sound systems are shared with compile conditions. The card driver should only need to request GART regions from the kernel and poke a register or two. skids, a bus abstraction naturally has to be bus agnostic, so i don't see your point in KBI at all? please explain skids: Once a guy comes up, who wanna port KGI to the sparc architecture.... On sparc, there's no AGP nor PCI. Suppose we decide we want a "bus abstraction", and we go implement KGI for an OS that doesn't have one. We should NOT spend time making the back end of buses we won;t ever use. skids: sparc has its own bus: SBUS. And UPA for the graphic board. skids: so the driver would during init setup the gart using kgi_apg_ functions, setup its own registers and then export the agp memory as another mmio region? Actually, I started with FreeBSD because I know it quite well, but NetBSD is the best target for lots of reasons philbo, well right, not a driver resource but a resource used by the driver. still a bus abstracted resource used by the driver philbo: More like during mmap than during init. ð cow starts to get headache being reminded of the issues involved skids: you can mmap only already available resources philbo: and during vc switch. I think the driver does not need to be involved into the mmap and export to userspace. NetBSD VM has numerous improvements over Mach, valuable for KGI. KGI can do this directly per-se, without driver intervention. philbo: what consititutes an "available" resource? Doing anything other than on-demand allocation of AGP RAM won't fly. ortalo: should the GART be handled has an other tlb? nsouch: OpenBSD implements NetBSD's UVM, btw. Afterwards, when the AGP (or regular PCI) memory areas get used. The driver will need some info about them. philbo, /mmio region/resource/ yes, no? nsouch: I don't know in fact. cow: mmio resource yes nsouch: Does FreeBSD also implements NetBSD's UVM? Or is it still based on 4.4BSD/Mach VM? ortalo: can you use agp witout ever telling the driver about it? bughunter: OK, so we change the prefix for kgi_agp_* to kgi_somethingelse_* Still, I don't want to become the KBI Project. philbo: no, but the driver only wants to know if ONE bit should be set or not set. maybe some discussion on the mailinglist should be involved in this before we can settle it. we're mow comparing this os to that os, and my conclusion is simply that the differences are big enough to show the need for some abstraction bughunter: no, unfortunately. FreeBSD chose the stability. nsouch: NetBSD, too. :) ortalo: doesn't it need to know about where and how much of agp memory there is? Foske: agreed. bughunter: I did not mean the opposite :) maybe bughunter can show us a little what the implications are by mail and I guess not everyone has read the docs well, for they were mostly just dumped on the website without comment philbo: that's the other way round: the driver sees a request to tranfer some memory area. He wants to check if this is AGP or "correct" memory, to setup the hardware transfer. philbo, i think it doesn't. if it is else it isn't ok. Let's leave it for an email discussion as it isn't pressing and it would be beneficial to have long pauses to think about issues involved OK, onto how AGP looks in userspace? cow: the Radeons for example have AGP_BASE and AGP_TOP registers for specifying region in the internal Radeon address space that should generate agp requests bughunter: could you please pull this heavy wagon ? At least initiate the discussion with some practical talking instead of "we should do bus abstraction" ? foSke: I can give it a try. thanks any comments one cannot keep for himself now ? :) I hate AGP. foSke: First I must get the mach64/crt driver combination get to work in order to have a stable base to work on. lol. ortalo: :) philbo, so it is using a resource which happens to call a callback in the worst (but common) case. i still do not grok it rightly, i guess Foske, none. move on :P foSke: Though, my PC has no AGP. So for AGP support, I need assistance. okay. someone else that starts the agp code in the mean time ? cow: I suppose it's all just anoying implementation issues.... bunhunter: ATI cards have a GART for PCI built in. I really think we should focuss on ggiPutBox() before trying to do it via AGP. I assume buggyhunt can use assistance on the bus stuff oki philbo, probably. real world always sucks :P ortalo: what do you mean? agp skipped till the bus abstraction basics are there next subject ggiPutBox ? I mean: sending data from host memory to the framebuffer using the accel engine. Uhuh, not that easy, userspace buffers were deemed to be a different subject, so now I want to talk about those. ah, ok ð cow goes for a ten minute brk 10 minute pee break ? ok ortalo: Versus what, I thought that was what we were talkinga bout/ Foske, if you feel like, yes :) peeeeeesa 10 XX:55 we will continue !sleep 5 :) ð philbo could use 10 minute break. Big issues are yet ahead !time OK for the break. It is 0:49 CET :) Yes. Me too. :) my freenode server says 02:46 am ð Foske notes nsouch' todo list is still empty :-P ... still have lot of dip (debug in progress) :) foSke: testuser_'s, anaki's, ekix's and golbez's todo lists are also empty... :) foSke: same for njs, neiljp, mitchell_, fraggle, oxygene, popel and scanlime :) yeah, but for the three first we should be happy now if they are willing to test kgi :) foSke: yes... :) ð Foske invites all named users to wake up :) ð bughunter sends pings At this level of abstraciton I'm just a spectator :-) ùíù [Users(#kgi:18)] [ scanlime ] [ neiljp ] [ oxygene ] [ fraggle ] [ njs ] [ nsouch ] [ ortalo ] [ anaki ] [ testuser_ ] [ philbo ] [ mitchell_ ] [ Foske ] [ ekix ] [ popel ] [ bughunter ] [ golbez ] [ skids ] [ cow ] we never were so crowded here :) 18 users here. the record on #ggi was 14 or 15... bughunter: ho ho ho :) njs: that's ok :) what OS/Hardware do you use ? bus-abstraction is not a subject anymore, or bunghunter want's to continue the demonstration? :) Foske: linux, dual x86, G400 oh great ! Foske: but I'm not sure I can actually do much testing; my kernel setup is a bit touchy right now. njs: that must be the best supported platform at the moment (besides the SMP issues we discussed earlier) ð neiljp wonders about support for rage128 neiljp: you wanna have the docs for the rage128 cards? ð Foske points to the G Bush side of the Atlantic.... those guys seem to know more about that 2 minutes before meeting time bughunter: the docs are available? not that I'd understand a word of them, but... neiljp: philbo, golbez and I have them. buggy: I can donate you a Rage 128 :-P neiljp: I have the docs on a CD, which is at home... so I haven't it at hand right now. a new item for philbo's TODO list then. foSke: Is it PCI? yup foSke: great. Your pee is ready (to be flushed) hunty: mail me your address ð philbo would like to write the rage128 driver but time is lacking oki... ortalo ? philbo: cool :) apart from the lack of time ;) foSke: ok next subject: vt_switching is based on kii_devices... i.e. if you open the wrong (or no) /dev/event, things go wrong ------------------------------------------------------------ =S Uhuh, next subject is userspace accel buffers. oh ? what are userspace accel buffers? Foske, indeed The second half of the AGP discussion. sorry, missed that one Foske we urgently have to settle those njs: the possability for an outside-kernel piece of code to accellerate graphics full speed by having access to the accellerator unit thought / quick intros? cow: of people, or topic? skids: could we move that to the mailing list as well? I think the same applies (not as pressing and people need to make themselves a good idea of what the issues are) ok:) skipped ! skids, people always are void. only topic is real Hrm, well I can reduce the discussion to this point and continue on the mailing list: I'd really like to see an mmap control page set for controlling the accel so the other CPU can grab a finished buffer on SMP systems w/o the context switch. Also this pertains to certain types of vsync stuff, but I'll wait till that topic for that part. skids will introduce this to the mailing list nsouch: AFAIK, you said, FreeBSD has addressed the VM issues to allow access to hw resources from userspace. Is that right? If yes, can you elaborate on them, please? now, next subject ? foske, useles. just paste a strip to the list with names omitted if you feel the list to be involved ? Re: vt switching then... what gets restored? skids: wait, that's the next one Oh, sorry. RIght, /dev/event. so how does that one look like at a glance. write only ping read only pong i guess? sane counter-example? bughunter: yes... trying to find a starting point. err ELOST ùíù SignOff: ortalo (Read error: 110 (Connection timed out)) I won't be annoying and point out that this problem is just another result of KII. Oops. I guess I just did. Basically, I can't think of a good solution to the /dev/event+vt swithing problem. Suggestions are welcome. ð skids hides. bunghunter: in terms of differences with Linux graphic mapper implementation? okay, skids volunteers to rewrite KII :) NEXT :-P nsouch: yes. foSke: shouldn't we wait until ortalo is back? :) Foske: skids is willing to rip KII, not rewrite it. oh ok, well I suppose people aren't very familiar with the issue. Moving to mailing list with ample background information. ortalo must have prostate problems, to pee so long :-) almost the same good idea skids: maybe his baby makes some noices now... :) think the next subject is actually discussable... :) s/baby/babies next topic: can libggi solve all of our vt swithchin/restoring issues? a shared one sounds dangerous to me, personally. urgently needed but odd to my untrained mind philbo: IMO, this is a target issue of libggi. Umm, I think there are some things that KGI should restore beyond mode... bughunter: does libggi have a way of telling the app that something happened and it should probably redraw? ð Foske still doesn't see the reason for background buffers :) bughunter: most of the differences stand in the fact that there's no per process data in the vnode system and philbo: GII has expose events. philbo: and UNIX has sigwinch. skids: ok. Is that enough? if kgi sends sigwinch, we're there :) philbo: Have you read the last mails from the GGI ML (the ones from the heating discussion) bughunter: for a given vnode, the VM management is centralized by pagers. nsouch, and? the "I hate amiga kiddies by default" one :) ùíù ortalo [ortalo@pppport15.laas.fr] has joined #kgi wb ortalo Can we get agreement that any data in VRAM is definitely NOT preserved by KGI? ortalo: vt switching based on event: moved to mailng list. topic: what to restore on vt switch bughunter: well, that one wasn't all that constructive. I think people here have a better understanding of kgi and the complexity of implementation details bughunter: thus difficult to distinguinsh two different mappings of different processes when time comes to handle faults. skids: Sounds reasonable to me skids: I agree there, if an app is slow it should draw in RAM instead of vram then it can continue to draw when moved to the background skids: sounds ok to me too. except maybe some very special cases (like cursor shape if stored in VRAM). skids, in my simple-minded mind it is not, right. ortalo: I think the text vc system should maybe have a cursor shape stored, but I'm not too sure about graphics apps. ortalo: sounds hard. I don't think it's unreasonable to ask the app to restore it. Console does it. mwaah.. graphic apps just should restore everything It makes it a lot simpler for our first few releases if we know we never have to protect anything in VRAM from another process. nsouch: I think, you told that on the KGI ML... Am I right? bughunter: I did. nsouch: ok ok. so kgi should send a signal when a app should redraw (App gets sigcont already, by the way) so: everything is assumed lost on a vt switch. libggi provides a good interface for apps to react to such event. Anything to add? I will take care of the signalling Well, I'm not so sure about graphics context. skids: you mean the accelerator context? That one is per mapping and is preserved. Including things like texture LUTs? that one is tricky and furthermore dangerous, yeah. skids: but I guess you're getting to the question of what happens if your accel buffers are in agp space... philbo: No I was saving that one to whollop people over the head later :-) philbo: that requires decent handling of the signals... won't be easy, but must be done The problem is, GPU contexts are getting bigger and bigger. so less and less reasons to keep things in back buffers ;) (as in, non-VRAM register values). OK, so we are then agreed that the app needs to restore GPU context? don't forget: switching away an applicatin that utilizes 128 MB video mem is not a MUST for the user, it is a CAN DO from KGI skids: GPU context switching is not a problem on highend cards. skids: right, though I don't think I have a good idea about the exact scale of the problem Well, yes, I am kinda hiding the "but then"... here goes "but then the accel pipe cannot resume execution until the app's GPU reload is done." skids: yes, I think gpu context is preserved. KGI was built around that assumption and it is just too hard otherwise. We'll deal with practical problems when we encounter them. And since the app may be reloading the GPU using the accel pipe.... skids: hey, how many times a sec do you swap away heavy graphic apps ? anyway Foske: It's not the performance, it's the amount of kernel-side code to maintain/debug. I'll take care of the signals, and it's up to the ggi guys to deal with it. (volunteers ?) I'll take care of sending the signals that is Foske: luckily, the trend is *away* from write-only registers, aliased registers and such, but the register load/reload can end up being a pretty big (and thus bug-infested) section of code. skids: I never said supporting swapping away accellerators was going to be easy :) next subject.... Foske: I'd prefer we do, I just want to make sure everyone knows the implications before agreeing to it. synchronisation of accelleration: is polling /dev/kgi/device0/accel the best ? Foske: I'll take care of GII issuing an expose event. skids: good, though you should also catch the sigttou and sigttin we *need* synchronization. As far as I understand things, that's the best solution so far. Any suggestions? everyone still here ??? yes yes though sleeping a little... :-) ð bughunter expected some more "yes" :) philbo: Mostly we *need* to be able to queue certain commands for execution during vsync. huh :) The rest is gravy. skids: ugh. That a whole other can of worms mjammy, worms... I volunteer to add the API to LibGGIMISC for issuing flip-on-retrace and such. ok noted:) back to the isse issue well, before people start falling asleep on the old continent, lets move to splitting /dev/graphic Apparently, FreeBSD needs this (IIUC). :) oki Are people opposed to the idea? Anybody feels it is useless waste of major numbers? Maybe it is not so urgent under Linux? I'm getting the impression that we are too tied to the fd's somehow, and we need (don't say it, no!!!) and abstraction layer. philbo: I guess, Linus thinks so. wasting majors will be a reason to decline KGI once mores ortalo: yes, this was the conclusion on the ML It's not the major numbers that worry me, it is more the additional code for new device types in Linux. this works for Linux, that works for BSD.... does devfs make matters better or worse? skids: good point. :) njs: neighter ortalo: it is hard to wait for an accel to go idle if you don't have a fd for each accel to wait on njs: it prevents you from wasting minors, though not majors I think we should use devfs when available but not require it. I progressed on the FreeBSD side and a new mapper command is used for accessing a particular device from a /dev/graphic 16 bit majors will solve the issue for us An attach command that differenciate the graphic minor from the device number. iirc that is linux 2.5 code We should be concentrating on 2.5 and on as far as Linux is concerned IMO. KGIC_MAPPER_ATTACH, with a device_id as parameter skids: for the wip branch yes, for the stable branch no i'm not sure we need (additional) majors. since we (seem to be freed) from pressure by minors we could push one level and do away with only one (or two for conveniance) majors and a shifted minor for non-accel, acce. This trick avoids the /dev/graphic breakage for now. Foske: sure, but for the stable branch any kludge that works is fair game IMO. cow: I think this issue doesn't count for linux right now. it works there, so please keep the stable tree this way nsouch: For completeness, is there a KGIC_MAPPER_DETACH, too ? so there are at least two solutions for the major number contention. Hence splitting /dev/graphic is a good idea? Foske, the stable is out of discussion fro my POV mmmmmmmmm bughunter: no, the close is responsible for the detach. into how many mayors ? graphic, accel, fb /me's keyboard has a wackelkontakt :-/ philbo: I'd just cuation to try to keep the code that figures out what "thing" is being accessed from becoming completely entangled to the extent possible -- it may become an issue later. skids: very true. I'm trying to mirror the kgi interface there (only a single attach/detach pair, should be very clean) skids, may but should not. yea .....next? I got nothing. Anyone? My brain is fried. VGA driver? mine too ? what about it ? ð cow is devastated It's still broken, no? Maybe we should refrain from splitting /dev/graphic too early then, no? yes. Who works on the VGA driver? ortalo: I'm working on a sample implementation. If people disagree, I'm perfectly willing to throw it away. anyone feeling able to make a (pre-) summary of what we have discussed? nsouch vga-text is in cvs. pülease try it out and get back to me or the list iff problems arise (apart from absent features which you ought to implenment() bughunter: i'm about to sleep now, gf is waiting cow: ok ð Foske misses 3d accel in the text driver Foske: are you going to write up a summary? (later) tomorrow philbo: I guess it will be useful. Maybe it's something that will re-appear soon. But it changes the way we were used to look at KGI devices... it might appear in FreeBSD soon, and in Linux later If no other solution found in the middle. ortalo: yeah, I know. I think it is worthwhile to have something working so that people can see what it does to the code and make a better judgement of whether it is a good idea or not ortalo: I'm not fully convinced myself, hence my willingness to throw it away when I'm done and it doesn't satisfy my desires nsouch, i did not forget about the FreeBSD integration, but that one may take some time. i don't have it locally, so playing with it is cumbersome, thus time-intensive. i'm sure you see my point. okay.. I'm off to sleep now, log will continue to run, don't talk too much, only got 223 MB left :) good night Foske cow: I do. summary will follow soon I guess I need some sleep too now. i do too If you don't mind, I'd rather say you good bye now... :-) ð philbo declares the meeting over. pleased to have met you all. see you .. (Have to install FreeBSD 5.0 tomorrow... :è) see you. and good night when (where) applicable. :-) skids: do you have any agp links besides the agp specs? (getting ready for the discussion :-) good night cow, ortalo ð ortalo sneaks into Morpheus arms... ùíù ortalo [ortalo@pppport15.laas.fr] has left #kgi bye guys. See you on the ML. ùíù SignOff: nsouch ("*monkey grin*") philbo: Have you already read http://netbsd.gw.com/cgi-bin/man-cgi/man?bus_space+9+NetBSD-current and http://netbsd.gw.com/cgi-bin/man-cgi/man?bus_dma+9+NetBSD-current ? will do. ùíù bughunter is now known as bughunter_sleep ùíù testuser_ is now known as testuser_is_awak ùíù neiljp is now known as neiljp_offline philbo: no, i don't even have the specs. Tomorrow I'll probably resume reading through the linux source. skids: specs are at http://developer.intel.com/technology/agp/info.htm but they are not very useful from the software side ùíù SignOff: neiljp_offline (Read error: 110 (Connection timed out)) ð golbez stirs ð philbo goes to do some of the promised coding ùíù SignOff: testuser_is_awak ("Client Exiting") ùíù SignOff: skids (Remote closed the connection) ùíù bughunter_sleep is now known as bughunter IRC log ended Sun Feb 2 13:51:37 2003