--- Log opened Птн Авг 04 00:00:05 2006
00:00 < pmdata> hum, 2bc = color_mask_enable on nv17
00:01 < pmdata> alpha byte is never used even on nv10
00:14 < pmdata> at least it is always set to 1
00:15 < pmdata> and nv17 always set it to 0
00:17 < marcheu> pmdata: I think so, I still use my own hack though
00:17  * pmdata need more b33r
00:18 < pmdata> I wonder why a color_mask_enable would be useful
00:18 < marcheu> pmdata: btw I have put tests online for nv11, 15, 18 & 28, and their 4 quadro counterparts
00:18 < pmdata> I saw that, finishing nv18, I wonder if it is useful to put dumps where all commands are known
00:18 < marcheu> nv18gl seems useless, the same driver path seems used
00:19 < marcheu> pmdata: I put everything to compare with/without quadro
00:19 < marcheu> Myrizio: that's what we do, we've got 2 tools actually
00:19 < Myrizio> marcheu: cool, what are those tools?
00:20 < marcheu> Myrizio: both are in cvs, renouveau is a stand alone tool to track the command fifo, and mmtrace is a valgrind plugin to track memory writes
00:21 < pmdata> marcheu> it seems there is no extra gl extension between nv10-15 and nv17-18, right?
00:21 -!- K [n=hazel@212.145.81.31] has quit [Remote closed the connection]
00:21 < marcheu> pmdata: nope, having a quadro never exposes new extensions
00:22 < marcheu> pmdata: it simply uses different paths for existing functionality
00:22 < Myrizio> ok, so mmtrace tracks application memory writes, but what about kernel memory writes?
00:22 < marcheu> Myrizio: we can't track them
00:22 < marcheu> yes, that's annoying
00:22 < Myrizio> ok
00:23 < Myrizio> long time ago i was trying to improve directfb nvidia drivers, but i did not even have a tool like mmtrace, so i achieved nothing :)
00:23 < Myrizio> about kernel writes maybe something could be done with qemu...
00:24 < marcheu> not really
00:25 < marcheu> existing virtualization solutions aren't good enough to expose an existing piece of hw through
00:25 < marcheu> in particular, once the card starts doing DMA, the virtualization software has 0 chance of tracking anything
00:26 < marcheu> I was thinking, maybe the iommus present on newer CPUs might help on that front
00:26 < Myrizio> ok, excuse my ignorance, but what is so bad about DMA?
00:26 < marcheu> when the CPU writes to an area to talk to the card, we can trap it, for example using a simple page fault
00:26 < Myrizio> yup
00:26 < marcheu> the page fault works because cpu writes have to go through the page table
00:27 < Myrizio> sure, i know this, at least :)
00:27 < marcheu> but if the card writes somewhere, it doesn't have to go through anything we control. it writes to memory directly
00:27 < marcheu> and we have no way to trap it
00:27 < pmdata> marcheu> nv18, arb_vbo: extra [0xd08/4], setup to same values as [0xd00/4] (display list start and count)
00:27 < pmdata> why send same data twice?
00:28 < Myrizio> ok, so the dma allows the card to read/write system memory?
00:28 < marcheu> Myrizio: yeah, that's what a dma is
00:28 < marcheu> pmdata: hmm, where ?
00:29 < marcheu> card_10de-0185_test_vbo.txt ?.
00:29 < pmdata> yes, but it is the start_display_list
00:30 < pmdata> hum, could you remake a dump with the single display_list test?
00:30 < marcheu> yea, d04 & d0C are the same
00:30 < marcheu> hmm, I have the nv28 now
00:31 < marcheu> was trying to make sense out of the quadro stuff
00:31 < pmdata> does it mean a display list for vertex, another one for color?
00:31 < marcheu> but what's wrong with the display_list I have put onlye ?
00:32 < marcheu> online
00:32 < marcheu> yeah, that could be two array sizes for 2 different properties
00:32 < marcheu> that's how it works from opengl anyway
00:33 < pmdata> on nv15, I have a single one with everything there
00:33 < pmdata> maybe nv17 can read 2 datas simultaneously at 2 different offsets?
00:34 < pmdata> it would double the datarate
00:34 < marcheu> does my nv15 do that as well ?
00:34 < pmdata> the display_list dump you did, well, I don't see any display list setup
00:35 < pmdata> yep, it does that
00:35 < pmdata> I'm still running 6106, maybe once again a quadro feature promoted to standard cards in 7xxx?
00:35 < Duke`> what is the difference between a quadro card and a standard card?
00:36 < pmdata> the driver
00:36 < pmdata> and the pci id
00:36 < marcheu> pmdata: I don't know... I'm on 71xx though
00:36 < pmdata> then I will put display_list0 and 1 in renouveau then
00:36 < marcheu> Duke`: all nvidia cards have the features, only quadro cards use them. but in the free driver we can use the quadro features everywhere
00:37 < Duke`> ok, and what are these features? (some examples?)
00:37 < marcheu> well, quadros are high end cards. so that's stuff like antialised lines & such...
00:38 < marcheu> another intersting part is that the driver sends vertices differently to a geforce and to a quadro. I suppose one ends up being faster...
00:39 < Duke`> ok, and for cards which are softquadroables, the nouveau driver will enable it by default? ;o)
00:40 < marcheu> we'll use the best of what's available, which is why we want to figure out what's available first
00:40 < Duke`> ok
00:40 < pmdata> marcheu> I think there is a START_DISPLAY_LIST_* for each vertex component (pos,col,col2,tx0,tx1,nor,fog,wgh)
00:41 < marcheu> pmdata: you know, I could have sworn display list triggered writes to the AGP area & a dma on my nv11
00:42 < marcheu> ah, nv28 does an indexed array like I'm used to !
00:42 < pmdata> time to check that
00:43 < marcheu> you'll see that if you change the display list size, the submission method changes
00:43 < marcheu> that's quite intersting, because it's probably correctly optimized
00:51 < marcheu> you're right, I can't make sense out of the nv1x display list output
00:52 < pmdata> bingo, I was right
00:52 < pmdata> time to add dX0,dX4 to nv10 tcl
00:54 < pmdata> done in cvs
00:58  * pmdata dumb, this is the offset, not the length
01:03 < pmdata> there was a document that was explaining the vertex_array format component, (stride, type, count), where it is?
01:06 < pmdata> rivatv.sf.net maybe?
01:07 < marcheu> the opengl functionality ?
01:08 < marcheu> or the hw functionality ?
01:08 -!- colberts [n=colby@ppp-69-219-34-217.dsl.chcgil.ameritech.net] has joined #nouveau
01:08 < marcheu> things like 0x32 means 3 floats ?
01:08 < marcheu> if so, that's cvs/doc/vertex_attributes
01:09 < pmdata> yes, that
01:10 < colberts> hi all
01:11 < Duke`> hi
01:12 < colberts> pmdata> have 2 dumps from someone last night, one of dumps is from a quadro i think,(have to check again)
01:13 < marcheu> colberts: you could put them on the sF.net website
01:13 < colberts> sure
01:13 < marcheu> we should put all these dumps at some central place, really
01:14 < marcheu> ok, I'll put mine
01:14 < colberts> had to take colberts as my uname on sf.net colbert was already taken
01:15 < colberts> where on the sf.net?
01:15 < marcheu> http://nouveau.sourceforge.net/tests/
01:16 < marcheu> which translates to yourusername@shell.sf.net:/home/groups/n/no/nouveau/htdocs/tests/
01:16 < marcheu> through ssh
01:16 < marcheu> please sort things in subdirs
01:17 < colberts> marcheu>ok, would you like to add me as a dev also?
01:17 < marcheu> colberts: you should be, that's the defauls permissions I think
01:17 < colberts> cool
01:18 < ajmitch> morning 
01:18 -!- marcheu changed the topic of #nouveau to: http://nouveau.freedesktop.org | open source 3D acceleration for nvidia cards | card dumps at http://nouveau.sourceforge.net/tests/ | http://perso.orange.fr/patrice.mandin/images/nv-kitten.jpg
01:18 < marcheu> ajmitch: so you're in .au ? :)
01:18 < ajmitch> marcheu: .nz
01:18 < marcheu> hehe :)
01:19  * ajmitch added his card to the wiki, just have to work out more details for clears on NV43 :)
01:23 < marcheu> ajmitch: btw an easy first project could be that you add 0x1740 & friends from http://nouveau.freedesktop.org/wiki/NV30VertexFormat into renouveau
01:24 < marcheu> it's already documented outside renouveau, just not recognized ATM
01:24 < ajmitch> ok
01:25 -!- Myrizio [n=Myrizio@host194-101.pool80104.interbusiness.it] has quit [Remote closed the connection]
01:29 < ajmitch> these will be in NV30_TCL_PRIMITIVE_3D ?
01:29 < marcheu> yep
01:30 -!- atcl [n=Universe@Lb837.l.pppool.de] has quit [Read error: 104 (Connection reset by peer)]
01:30  * airlied is slightly responsible for any influx of ppl I did mention nouveau at OLS :-)
01:31 < ajmitch> airlied: yes, interesting slides, I saw them online 
01:31 < marcheu> airlied: yeah, the situation is getting a bit out of control here :)
01:37 -!- Myrizio [n=Myrizio@host197-101.pool80104.interbusiness.it] has joined #nouveau
01:39 < marcheu> crap, I'm working on an outdated drm copy
01:50 < marcheu> pmdata: hmm, please check that the modelview matrix is not also the first matrix parameter like on nv30+
01:50 < marcheu> I mean, a vertex parameter
01:51 < marcheu> no actually it's not, nm
01:51 < pmdata> I also wonder if there is a second modelview/inverse for vertex weighting on nv20
01:52 < pmdata> I don't think so, because vertex program can provides same result
01:52 < marcheu> look for 64-byte size holes :)
01:53 < pmdata> this time the diff between modelview and inverse_modelview is 256, not 128
01:54 < pmdata> nv20[1da4] seems to be nv1xgl[d74]
01:55 < marcheu> which does ?
01:55 < pmdata> I don't know :)
01:55 < pmdata> it's nice nvidia setup the hw in the same order, whatever the chip
01:55 < pmdata> it's easier to guess the stuff
01:55 < marcheu> do we get d74 on nv11gl ?
01:56 < marcheu> I though it was some nv17 specific stuff
01:56 < pmdata> I did not check
01:56 < pmdata> compare the test_default between nv15 and nv28, you'll see what I mean
01:57 < pmdata> 1b0c,4c,8c,cc should be tx<n>_enable
01:57 < marcheu> ah, d74 is seen on nv15, but not nv11
01:58 < colberts> ls
01:58 < colberts> sorry, typing in the wrong window
01:58 < pmdata> debian warez cd key
01:59 < pmdata> oops
01:59 < marcheu> pmdata: too much linuxfr detected !
01:59 < pmdata> :)
01:59 < pmdata> anyway, I'll commit my nv10/20'compare'
01:59 < ajmitch> hm, getting the vertices printed with NV30_TCL_PRIMITIVE_3D_VERTEX_DATA was a bit too easy, there's more to the doc than that..
02:00 < marcheu> ajmitch: what do you mean ? do you have a patch you could commit ?
02:00 < ajmitch> marcheu: the only thing it does is print out the coordinates, just by changing PRINT_X32 to PRINT-FP32
02:00 < ajmitch> s/-/_/
02:01 < marcheu> ajmitch: yeah, what I had in mind is the vertex attrib description format
02:01 < ajmitch> yeah, that's what I'm figuring out
02:01 < marcheu> ajmitch: which I don't think is recognized in renouveau 
02:01 < marcheu> registers from 0x1740 
02:01 < ajmitch> is there a test that would currently use them?
02:02 < marcheu> no, you'd have to send some vertices with color, some only pos, some with textures...
02:02 < ajmitch> alright
02:02 < marcheu> that will enable/disable the vertx attributes
02:03  * ajmitch has 0x1740 being used at least once here, so that's a start
02:11 < pmdata> marcheu> in test_tex, we should use different min/mag filter for same tx unit
02:11 < marcheu> pmdata: point
02:12 < pmdata> 1b14,1b54,1b94,1bd4 seems to hold them, but can't tell which is where
02:12 < marcheu> well... you have commit rights, you know what to do :)
02:13 < pmdata> yea, but you are the one with a nv20 that could fix and update the dump
02:13 < marcheu> ok, that comes after the memory manager
02:13 < pmdata> 1b00 should be tx offset, 1b04 should be tx format
02:13 < marcheu> and I was hoping to go to bed early today :)
02:13  * pmdata will go now
02:14 < pmdata> and same for each tx unit, add 0x40*tx_unit
02:14 < marcheu> ok, will look at it
02:15 < pmdata> 1b1c is the npot size
02:15 < marcheu> that said, I thought we already had it
02:15 < pmdata> maybe for nv30?
02:16  * pmdata go now
02:16 -!- pmdata [i=patrice@ANantes-154-1-59-3.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
02:16 < marcheu> it's the same with nv30
02:16 -!- Duke` [n=gnu@ANantes-251-1-134-122.w86-210.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:26 < marcheu> darktama: ping ?
02:27 < marcheu> darktama: did you figure out a way of forcing the fifo adress ? or should I have a way of forcing the allocated memory adress instead ?
02:45 < marcheu> ok, I'll assume that works & move on :)
02:46 < marcheu> darktama: but really, we have to talk about that stuff
02:56 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
03:00  * colberts is away: colberts_dogwalk
03:00 -!- colberts is now known as colberts_dogwalk
03:12 -!- Myrizio [n=Myrizio@host197-101.pool80104.interbusiness.it] has quit ["Leaving"]
03:41 -!- colberts_dogwalk is now known as colberts
03:41  * colberts is back
03:53 < marcheu> airlied: any easy way I could find the AGP area from the drm ?
03:53 < marcheu> airlied: it seems to be pci resource 1, but can I generalize ?
03:59 < marcheu> anyway, too tired now
04:24 < colberts>  I cannot transfer any files to tests gives a "Couldn't get handle: Permission denied" is it something stupid on my side? ssh-key?
04:25 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has joined #nouveau
04:29 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
04:44  * colberts is away: colberts
05:07 < darktama> marcheu: as far as I can tell you can put the cmdbuf anywhere, it's just pointed to by a standard DMA object (NV_PFIFO_CACHE1_DMAI)
05:08 < darktama> the AGP cmdbuf code works, but you need to make the ddx alloc/bind the entire AGP aperture.. so, there's some AGP-foo which I don't know about - which is why the code is #ifdef'd out in cvs
05:37 < airlied> marcheu: the AGP area may not have any memory backing it..
05:37 < airlied> you need to have the DDX to all the setup for bits of it ..
05:44 < darktama> airlied: so the drm can't do that for the parts of agp it needs?
06:07 < airlied> not usually, the DDX sets up the bindings ...
06:09 < darktama> ah, fair enough
06:10 < darktama> actually, it'd make more sense for the app using the fifo to do the bindings.. instead of wasting memory for FIFO buffers that may go unused
08:11 -!- colberts [n=colby@ppp-69-219-34-217.dsl.chcgil.ameritech.net] has quit [Remote closed the connection]
08:12 -!- tibbs is now known as tibbs|h
08:13 -!- philv [n=bleep@cowpig.ca] has quit ["Lost terminal"]
08:13 -!- philv [n=bleep@cowpig.ca] has joined #nouveau
08:47 < airlied> darktama: apps can't really do that.. the new memory manager from TG will be able for it I'd hope..
08:48 < darktama> hm, ok.  so for now we'll need to make the ddx map all cmdbufs for all FIFOs (if in AGP) at once
08:48 < airlied> just make a big mapped AGP, I think radeon does 8MB for instance and splits it up..
08:48 < airlied> how much do you need?
08:49 < darktama> well, by default (setup by the BIOS) each FIFO gets 32KiB.. on nv40 there are 32 FIFOs
08:49 < darktama> I was hoping to increase the size of the cmdbuf though
08:50 < airlied> that doesn't seem too extreme... like 1MB.. 
08:51 < darktama> indeed, I was thinking of increasing the cmdbuf size significantly if there's sufficient video memory (or a large enough AGP aperture)
08:52 < darktama> according to x11perf, we get some nice speed increases by moving the cmdbuf out of vram and into agp..
09:08 -!- shavengerAway [n=sha@swarm.ulb.ac.be] has quit [Read error: 60 (Operation timed out)]
12:31 -!- Duke` [n=gnu@ANantes-251-1-82-220.w86-203.abo.wanadoo.fr] has joined #nouveau
12:45 < marcheu> hmm
13:08 < marcheu> airlied: I don't see why it would be impossible to have AGP managed from the drm
13:08 < marcheu> with a proper memory manager you can definitely do that
15:04 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has quit ["Leaving"]
15:32 < Duke`> how can someone write something like this (http://cm.bell-labs.com/sources/plan9/sys/src/cmd/aux/vga/nvidia.c) without any documentation? and there is no comment in the code :[
15:34 < marcheu> seems to be a copy of the "nv" driver from Xorg for the most part
15:35 < marcheu> see nv_hw.c for example
15:35 < marcheu> there are some blatant similarities
15:36 < Duke`> yes
15:37 < Duke`> but a lot of magic values...
15:37 < marcheu> ...which are exactly the same as in the Xorg nvidia driver
15:38 < marcheu> which was written by people from nvidia, so you know where these magic values come from
15:38 < Duke`> so with the nouveau driver, the nv driver will be completly deprecated?
15:38 < marcheu> well
15:38 < marcheu> we don't have the choice
15:39 < marcheu> basically the Xorg nv driver is maintained by nvidia people, and they refuse to merge stuff that "exposes hw functionality of the card"
15:39 < marcheu> so we have our own nv in cvs
15:41 < Duke`> today, all the changes for the nv driver are just for adding new chip ID? or does the driver can still grab some new features, time to time..?
15:41 < marcheu> changes in the last year or so were only pci ids, yes
15:41 < Duke`> ok
15:42 < Duke`> another question: what is exactly the framebuffer driver? I've seen that there is an option to enable it with the nv driver, what is the difference with fb disabled?
15:42 < marcheu> I think the long term solution is to rename our DDX, and let people choose between the 2
15:43 < marcheu> hmm, which option ?
15:43 < marcheu> shadowfb ?
15:44 < Duke`> no, UseFBDev
15:44 < Duke`> Enable or disable use of on OS-specific fb interface (and is not
15:44 < Duke`>               supported  on all OSs).  See fbdevhw(4) for further information.
15:44 < Duke`>               Default: off.
15:45 < marcheu> ah
15:45 < marcheu> yeah that uses the kernel fb driver
15:45 < marcheu> maybe we could slash that from our code
15:45 < Duke`> and what this framebuffer brings us?
15:46 -!- Myrizio [n=Myrizio@host98-96.pool80104.interbusiness.it] has joined #nouveau
15:46 < marcheu> it lets the Xorg driver cooperate nicely with the fb driver I guess...
15:47 < marcheu> I guess that's about to break when we start moving pieces in video memory with the new allocator
15:47 < marcheu> having 2 modules in the kernel (fb + drm) for the same piece of hw gets real complicated reald fast
16:05 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
16:09 -!- shenki [n=shenki@ppp167-129.lns3.adl4.internode.on.net] has joined #nouveau
16:39 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
16:40 < maxtoo> hi
16:41 < Duke`> hi
16:42 < maxtoo> Duke`, salut ;)
16:42 < maxtoo> Duke`, il y a moyen de tester nouveau ou pas ?
16:49 < Duke`> non, pas encore, pour le moment c'est la phase reverse engineering
16:51 < maxtoo> ok mais dans la matrix todo, on voit qu'il reste plus grand chose à faire
16:51 < maxtoo> enfin, il y a moyen d'aider ?
16:53 -!- shenki [n=shenki@ppp167-129.lns3.adl4.internode.on.net] has quit ["Leaving"]
17:00 < darktama> marcheu: so, have you made any progress with porting a mm?
17:09 < darktama> oh, wow.. babel fish makes a huge mess of that french above :S
17:13 < marcheu> darktama: yeah I am writing the mem code, I hope to have somethign to commint in the next days
17:14 < darktama> cool :)
17:16 < darktama> which driver are you porting from? or are you using the new mm?
17:16 < marcheu> I take the stuff from the via one. but they're mostly all the same, really
17:18 < marcheu> darktama: and that french mostly means "how can I help"
17:18 < marcheu> maxtoo: yeah, if you can code, you can definitely help
17:19 < darktama> ah, thanks :) my french is non-existant.. just english and *very* basic german here
17:19 < marcheu> yeah, lots of french guys in here...
17:20 < darktama> yup, I find it amazing that so many people from non-english-speaking countries speak english.. I don't know anyone (in person) who is fluent in another language
17:22 < toresbe> mais oui. Super timor est encore plus fort avec sa nouvelle formulle.
17:23 < marcheu> toresbe: only one "l" in formule :)
17:23 < toresbe> ah, merci. :)
17:23 < darktama> "yes. Super Timor is even stronger with its news formulle. " ... :)
17:23 < toresbe> Super Timor, vremand, vremand plus fort! Le numero une!
17:24 < marcheu> s/vremand/vraiment/ & s/une/un/
17:24 < toresbe> wow, it's a long time since I've written it :)
17:24 < toresbe> Le temps de sentir l'odeur SuperTimor, les insectes sont déjà mort...
17:24 < marcheu> toresbe: but wtf is that ? :)
17:25 < EdB|w> marcheu, meme moi je comprend pas de quoi il parle, si tu peut m'aclairer :o)
17:25 < EdB|w> éclairer
17:25 < marcheu> EdB|w: il semble que super timor soit un insecticide, il a l'air de conna�tre les pubs pour insecticide par coeur :)
17:25 < EdB|w> :o)
17:26 < toresbe> oral contraceptive, n.: The word "No".
17:26 < toresbe> oops
17:26 < toresbe> http://files.maunier.org/supertimor.mpeg *
17:27 < toresbe> It is by quite far my favorite advertisement.
17:34 < Duke`> il a peut-être été traumatisé par une pub francophone pour insecticide
17:34 < Duke`> rofl the video
17:41 -!- nano- [i=nano@exodus.xmms.se] has joined #nouveau
17:41 -!- nano [i=nano@debian.as] has quit ["leaving"]
17:55 -!- shenki [n=Joel@ppp167-129.lns3.adl4.internode.on.net] has joined #nouveau
18:01 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
18:01 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
18:06 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
18:11 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
18:13 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
18:14 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
18:14 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
18:14 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
18:14 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
18:18 -!- shenki [n=Joel@ppp167-129.lns3.adl4.internode.on.net] has quit ["Leaving"]
18:23 -!- shenki [n=shenki@ppp167-129.lns3.adl4.internode.on.net] has joined #nouveau
18:34 -!- shenki [n=shenki@ppp167-129.lns3.adl4.internode.on.net] has quit [Remote closed the connection]
18:37 -!- shenki [n=shenki@ppp167-129.lns3.adl4.internode.on.net] has joined #nouveau
18:47 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
19:05 -!- shenki [n=shenki@ppp167-129.lns3.adl4.internode.on.net] has quit [Remote closed the connection]
19:08 -!- philv [n=bleep@cowpig.ca] has quit ["Lost terminal"]
19:08 -!- philv [n=bleep@cowpig.ca] has joined #nouveau
19:26 -!- shenki [n=shenki@ppp167-129.lns3.adl4.internode.on.net] has joined #nouveau
19:28 -!- shenki [n=shenki@ppp167-129.lns3.adl4.internode.on.net] has quit [Remote closed the connection]
19:29 -!- shenki [n=shenki@ppp167-129.lns3.adl4.internode.on.net] has joined #nouveau
19:33 -!- shenki [n=shenki@ppp167-129.lns3.adl4.internode.on.net] has quit [Client Quit]
19:34 -!- shenki [n=shenki@ppp167-129.lns3.adl4.internode.on.net] has joined #nouveau
19:47 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
20:12 -!- stringfellow_ [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
20:26 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Read error: 110 (Connection timed out)]
21:18 -!- shenki [n=shenki@ppp167-129.lns3.adl4.internode.on.net] has quit ["Leaving"]
21:26 -!- atcl [n=Universe@L8aa2.l.pppool.de] has joined #nouveau
21:28 -!- pmdata [i=patrice@ANantes-154-1-100-226.w86-214.abo.wanadoo.fr] has joined #nouveau
21:29 < pmdata> hello
22:20 -!- shenki [n=shenki@ppp167-129.lns3.adl4.internode.on.net] has joined #nouveau
22:22 -!- pmdata [i=patrice@ANantes-154-1-100-226.w86-214.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
22:55 -!- pmdata [i=patrice@ANantes-154-1-100-226.w86-214.abo.wanadoo.fr] has joined #nouveau
23:01 -!- EdB|w [n=EdB@212.234.68.206] has quit ["Parti"]
23:53 < pmdata> ping anyone?
--- Log closed Сбт Авг 05 00:00:06 2006