--- Log opened Чтв Авг 24 00:00:21 2006
00:01 < KoalaBR> pmdata: Want some more dumps with newest renouveau? Otherwise, I hear my bed calling :)
00:07 < KoalaBR> Well, will be back tomorrow, good night 
00:07 -!- KoalaBR [n=KoalaBR@port-83-236-14-45.dynamic.qsc.de] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.13/20060417]"]
00:08 < marcheu> the 16MB region is only the registers. the fifo is in VRAM or in AGP area, depending on the configuration
00:08 < marcheu> that's exposed as memory, but you can't really store anything here. writes to here are sent to the card which understands them as commands
00:09 < phh> ok
00:09 < marcheu> and I think the VRAM region is bigger to cope with having the same GPU and different amounts of VRAM
00:09 < phh> i find that pretty strange but there is more possibilities than an exception right (it's because x86 arch is strangely made i think)
00:10 < marcheu> it's not strange, it's just a way of reprenting I/
00:10 < marcheu> I/O
00:11 < phh> mwaif
00:39 < pmdata> anyone want to try my arb_point_parameters test on nv20+?
00:39 < marcheu> hmm, I can go & plug you the nv20
00:39 < marcheu> you asked for it 3 times
00:39 < marcheu> let's do it now :)
00:40 < marcheu> (3 times is the threshold of action with me :)
00:40 < pmdata> for i in 1 2 3 ; do echo "make coffee"; done
00:41 < phh> lol
00:44 -!- atcl [n=Universe@L8786.l.pppool.de] has joined #nouveau
00:50 < marcheu> ok, done
00:50 < pmdata> I think I should try reinstalling old driver to check nv_texgen_emboss, maybe they are done using those unknown bits in register combiners
00:51 < pmdata> on my box of course
00:51 < marcheu> I told you before about coffee
01:03 -!- Netsplit brown.freenode.net <-> irc.freenode.net quits: darktama, phh, Aexoden, zoeloelip, b33fc0d3
01:03 -!- Netsplit over, joins: b33fc0d3, phh, zoeloelip, Aexoden, darktama
01:10 < pmdata> marcheu> I updated the nv28sgl dumps on nouvea.sf.net/tests
01:11 < pmdata> http://nouveau.sourceforge.net/tests/nv28sgl/card_10de-0281_test_startup.txt the first object is class 0x0a55 (unknown) any idea?
01:11 < pmdata> we talked about it a while ago
01:11 < marcheu> it's not a 0x5 variant ?
01:11 < marcheu> it's not a 0x55 variant ?
01:11 < pmdata> maybe
01:13 < pmdata> I also see that on your nv28, 2 objects 177c are created
01:13 < marcheu> and ?
01:17 < pmdata> this is strange, given that 7c is the video display object
01:19 < marcheu> maybe quadro cards have multiple overlays :)
01:20 < pmdata> I was thinking about the 2nd crtc, but I'm not sure
01:20 < pmdata> maybe used for stereo then?
01:20  * pmdata wants stereo dumps
01:20 < marcheu> I think quadros have a YUV and a RGBA overlay
01:21 < marcheu> I don't know how to use the latter, though
01:27 < marcheu> hmm after a closer look at nv_hw.c, it's not that hard to understand
01:28 < pmdata> can you explain a bit?
01:28 < marcheu> well, the stuff in loadstate
01:28 < marcheu> it's possible to make sense out of it
01:29 -!- snez [n=snez@194.42.16.14] has left #nouveau []
01:30 < marcheu> darktama: btw you'll have to do Xv. no mplayer on this fedora...
01:48 -!- stringfellow_ [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
01:58 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
02:01 -!- pmdata [i=patrice@ANantes-154-1-103-218.w86-214.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
02:01 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Connection timed out]
02:07 -!- stringfellow_ [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Read error: 104 (Connection reset by peer)]
02:08 < stillunknown> is fedora a nice distro?
02:16 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
02:17 < marcheu> not sure, I use it for 3 days :)
02:22 < stillunknown> why doesn't it have mplayer?
02:25 < marcheu> patents
02:25 < marcheu> the same reason they don't have mp3 support
02:25 < marcheu> you need to setup an external repo for all that
02:25 < marcheu> and I've set it up, but it doesn't seem to work ATM
02:26 < marcheu> so...
02:28 < marcheu> also, I'm running the "testing" version right now. so don't blame fedora for these issues
02:28 < stillunknown> let me know how fedora works out for you, since most people i've read about/talked to tend to avoid fedora
02:41 -!- atcl [n=Universe@L8786.l.pppool.de] has quit ["Nobody needs a quit message :)"]
03:04 -!- phh [n=phh@moi.phhusson.info] has quit [Remote closed the connection]
03:36 < airlied> marcheu: you said nvidia do modesetting in the kernel, but if the kernel module is missing they still manage to set modes..
03:37 < airlied> and still do 2D, so do they have some sort of fallback object engine in the 2D driver I wonder..
03:37 < marcheu> uh, since when does their module works without kernel part ?
03:37 < airlied> marcheu: I'm sure I've ran just the 2D bit before when I upgraded a kernel..
03:37 < airlied> but maybe I haven't....
03:38 < marcheu> it usually complains loudly on X startup when the kernel module isn't there
03:38 < airlied> are we going to enforce requiring a drm module for nouveau?
03:38 < marcheu> yes
03:39 < marcheu> there was some discussion about it some time ago
03:39 < marcheu> the current EXA already required a kernel module...
03:40 < airlied> cool, how many ppl are committing to the DDX btw? you + darktama +??
03:40 < marcheu> and the "nv" DDX won't accept our changes anyway. so they can still support users who want 2D without a DRM
03:40 < marcheu> yeah I think us 2 for now
03:40 < airlied> I'd like to propose we move it to git on fd.o I've started to cleanup parts of nv_hw.c (like the vga register settings_ to use macros..
03:41 < marcheu> hmm, so we don't get flamed for that choice.. hehe...
03:41 < airlied> well considering every X driver is now using git, why be different :-)
03:41 < marcheu> no, the choice of enforcing a DRM
03:41 < marcheu> I think it's the first driver doing that
03:41 < airlied> marcheu: well I don't mind I'm the DRM maintainer I always have one :-)
03:42 < airlied> it is the first driver alright..
03:42 < airlied> but to be honest Linux/*BSD have one, who cares about anyone else..
03:42 < marcheu> yeah, solaris will have one as well
03:42 < airlied> marcheu: I wish they'd finish their code drop, I've talked to them a few times now..
03:43 < marcheu> about moving to git, I just need to ask pmdata if he wants to contribute to the DDX. he'd be able to I think but too shy or something :)
03:43 < airlied> marcheu: well with git he can contribute on his own machine and send patches if he doesn't want to go direct..
03:44 < airlied> local diff/commit means a lot of the reasons for requiring actual repo access go out the window..
03:44 < marcheu> anyway, neither darktama or me care about where the repo sits so...
03:44 < marcheu> not sure where I have to request git for nouveau.fd.o
03:44 < airlied> marcheu: I'll do it..
03:45 < marcheu> cool cos my fd.o key is still on that spare HD
03:45 < airlied> marcheu: I've got very direct fd.o admin access .. I probably should volunteer to be one :-)
03:46 < marcheu> yeah, feel free to do all that stuff that I don't really understand and would take me ages to do :)
03:46 < marcheu> btw did you see my latest commit to nv_hw.c ? I think I understood a couple of stuff
03:47 < marcheu> all in all, it is possible to make sense out of most of the register writes in there
03:48 < airlied> oh wow you've figured out some surface stuff....
03:48 < marcheu> yeah, after staring for some time...
03:49 < airlied> yeah I've a fair idea of the modesetting, I've decided to abandon starting from scratch and just hack on nouveau until it works..
03:49 < marcheu> yeah, I like that way. especially since I just got EXA to work here (finally !)
03:49 < marcheu> but you're right that a fair bit of hacking will be required
03:50 < marcheu> anyway, let's write that interesting register dumper before going to bed
03:56 -!- K [i=hazel@85-57-135-18.gij1.adsl.uni2.es] has quit [Remote closed the connection]
04:03 < marcheu> btw before you import, it'd be a good occasion to add darktama's copyright. he put none (bad boy)
04:04 < marcheu> hmm it mostly applies to drm I think..
04:04 < marcheu> we'll ask him I guess
04:05 < airlied> one reason I'd like to start again is I dislike that rather obnoxious nvidia license statement :-)
04:05 < marcheu> heh, yeah. I guess if we figure out everything in that file and reimplement, we can remove the file in the end
04:26 < marcheu> ok, the register dumper is in CVS, I'll happily take any dumps
04:26 < marcheu> it's just one more test for renouveau
04:41 -!- Myrizio [n=Myrizio@host54-101.pool80104.interbusiness.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
04:45 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has joined #nouveau
04:46 -!- Duke` [n=gnu@ANantes-251-1-141-157.w86-210.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
05:23 -!- Netsplit brown.freenode.net <-> irc.freenode.net quits: darktama, Aexoden, zoeloelip, b33fc0d3
05:23 -!- Netsplit over, joins: b33fc0d3, zoeloelip, Aexoden, darktama
05:34 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has joined #nouveau
08:57 -!- darktama [n=darktama@gentoo/contributor/darktama] has quit [Connection timed out]
09:02 -!- darktama [n=darktama@gentoo/contributor/darktama] has joined #nouveau
09:13 -!- darktama_ [n=darktama@124-168-238-39.dyn.iinet.net.au] has joined #nouveau
09:28 -!- darktama [n=darktama@gentoo/contributor/darktama] has quit [Read error: 110 (Connection timed out)]
09:53 -!- tibbs is now known as tibbs|h
11:14 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
11:35 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
11:53 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
11:57 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
12:01 -!- Unavowed [n=silent@host86-132-160-20.range86-132.btcentralplus.com] has joined #nouveau
12:36 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has joined #nouveau
12:56 -!- Duke` [n=gnu@ANantes-251-1-124-144.w86-210.abo.wanadoo.fr] has joined #nouveau
13:21 -!- etzel [n=thisnuke@west-193.rcn.NMT.EDU] has quit [Read error: 60 (Operation timed out)]
13:30 -!- etzel [n=thisnuke@west-193.rcn.nmt.edu] has joined #nouveau
16:15 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has quit ["Leaving"]
17:03 -!- scandium [n=scandium@pD9EEA08D.dip0.t-ipconnect.de] has joined #nouveau
17:15 -!- b33fc0d3_ [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
17:16 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Read error: 113 (No route to host)]
17:40 -!- pmdata [i=patrice@ANantes-154-1-15-159.w81-53.abo.wanadoo.fr] has joined #nouveau
18:18 < pmdata> http://lwn.net/Articles/195351/ some people comments quote nouveau
18:28 -!- Myrizio [n=Myrizio@host99-101.pool80104.interbusiness.it] has joined #nouveau
18:37 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Read error: 54 (Connection reset by peer)]
18:39 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
19:13 -!- scandium [n=scandium@pD9EEA08D.dip0.t-ipconnect.de] has quit ["using sirc version 2.211+KSIRC/1.3.12"]
19:17 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
19:24 -!- pmdata [i=patrice@ANantes-154-1-15-159.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
19:28 -!- pmdata [i=patrice@ANantes-154-1-15-159.w81-53.abo.wanadoo.fr] has joined #nouveau
19:40 < stillunknown> is darktama_ still asleep?
19:40 < darktama_> no, I'm here sort-of :)
19:42 < stillunknown> any chance you'll try to fix Xv today?
19:43 < stillunknown> forgot to trigger darktama_
19:43 < darktama_> I started on it earlier, and got it working in EXA.. but completely broke XAA :)  then I ran out of spare time.
19:43 < stillunknown> but xaa is being deprecated?
19:45 < darktama_> more or less.  but while we still support it I shouldn't break it :)  in any case, the breakage was my fault for rushing
19:46 < stillunknown> you haven't commited it, so no harm done
19:47 < darktama_> true
19:48 < stillunknown> you'll figure out how to get xaa back and then you'll tell me :-)
19:49 < darktama_> I've decided to just convert the entire DDX to use the memory manager.. which will fix Xv at the same time
19:49 < stillunknown> sounds like a longterm solution, which is good
19:50 < darktama_> yes, it needs to be done at some point anyway :)
19:50 < stillunknown> how much work is that, a day, a few days, a week, etc?
19:51 < stillunknown> (so i don't ask you every day :-) )
19:51 < darktama_> It depends how much time I have free really, I have parts of it done now.
19:54 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
19:55 < stillunknown> just don't say releasedate += 1 darktama_ :-)
19:56 < stillunknown> i mean releasedate = date + 1
19:56 < stillunknown> how late is it over there?
19:56 < marcheu> darktama_: if you don't have time to do it all yourself, we can tag current cvs, and work on that from here
19:56 < darktama_> stillunknown: 2am
19:57 < stillunknown> time to go to work?
19:57 < darktama_> no, got home from there a couple of hours ago
19:57 < darktama_> marcheu: it's not really a lot of work, just a lot of different places to change
19:59 < marcheu> darktama_: btw we should wrap MEM_ALLOC + drmMap into a single function
19:59 < darktama_> yup, I've called it NVAllocateMemory() already :)
19:59 < marcheu> ok, cool
19:59 < marcheu> I'll try to iron the mem allocator code in the drm then
19:59 < marcheu> I don't think it robust ATM
20:00 < darktama_> cool, it'd be useful so I can finish the setparam code.. so I can alloc the cmdbuf
20:01 < stillunknown> keep in mind that many people (including myself) would be pretty happy with a decent 2d driver
20:01 < darktama_> btw, if we have a setparam for AGP mode we're going to have to move the mm init out of firstopen().. or at least the part that inits AGP
20:01 < darktama_> stillunknown: that's what we're working on :)
20:02 < marcheu> hmm, would it be wise to defer mem init to the first alloc/free call ?
20:03 < darktama_> hm, that's possible.  as long as it's initialised before we allocate a FIFO it should be fine
20:04 < marcheu> "allocate a fifo" counts as the first alloc call for me
20:04 < darktama_> hehe, yes you have a point!
20:04  * darktama_ blames his empty cup of coffee
20:05 -!- Unavowed [n=silent@host86-132-160-20.range86-132.btcentralplus.com] has quit [Read error: 60 (Operation timed out)]
20:08 < stillunknown> is all development still happening in cvs?
20:11 < marcheu> yes
20:11 < stillunknown> is there anything that a "normal" person can help with, besides making dumps (still waiting on those new drivers)?
20:11 < marcheu> hmm write code ?
20:13 < stillunknown> my coding skills are limited (not joking), if there is anything specific that i can find some background info on, it could be nice to try out
20:13 < stillunknown> but i admit that most you talk about sounds like "magic"
20:14 < stillunknown> guess i'll start working on some ebuilds
20:16 < stillunknown> development will stay in cvs for the near future?
20:16 < stillunknown> (there has been some talk about git)
20:39 -!- darktama_ [n=darktama@124-168-238-39.dyn.iinet.net.au] has quit [Read error: 110 (Connection timed out)]
20:44 < stillunknown> marchue: is there any updated compile docs on xf86-video-nv?
20:45 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
20:45 < stillunknown> it seems to complain of a file called nouveau_drm.h
20:46 -!- Myrizio [n=Myrizio@host99-101.pool80104.interbusiness.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
20:46 < stillunknown> which suggest that during the compile process of the ddx the drm sourcecode is needed aswell
20:46 < stillunknown> anyone?
20:48 < marcheu> yes, you need the drm installed before compiling ddx
20:48 < stillunknown> the drm is installed
20:48 -!- darktama [n=darktama@gentoo/contributor/darktama] has joined #nouveau
20:49 < stillunknown> but for some strange reason none of the /usr/include/drm is nouveau drm
20:50 < marcheu> yes, nouveau_drm.h gets installed when you install libdrm
20:50 < darktama> ooh, 8774 was released
20:50 < marcheu> or else copy nouveau_drm.h to /usr/include/drm/
20:50 < stillunknown> marcheu: that didn't happen, it didn't install
20:51 < marcheu> stillunknown: you have two things in the drm package, the drm modules and libdrm
20:51 < marcheu> darktama: hmm ?
20:51 < darktama> ftp://download.nvidia.com/XFree86/Linux-x86_64/1.0-8774
20:52 < marcheu> hehe
20:53 < stillunknown> it seems i only installed/made a package file for libdrm
20:53 < stillunknown> but still that should include the header
20:53 < stillunknown> like every other header that is there
20:53 < marcheu> stillunknown: make install for libdrm gets the header, unless you have got your drm from the wrong place
20:54 < marcheu> or maybe that's some packaging issue... anyway it's enought to just copy nouveau_drm.h
20:55 < darktama> argh, EXA wants the front buffer and the offscreen memory in the same map
20:56 -!- K [i=hazel@tor/session/external/x-85fbb9e5c24a50d1] has joined #nouveau
20:59 < stillunknown> marcheu: the makefiles are not ok yet
20:59 < stillunknown> they do not copy the nouveau_drm.h
21:00 < stillunknown> can i just tell you where the problem is, or do i need to make a patch?
21:02 < stillunknown> marchue: trigger
21:05 < stillunknown> anyone with cvs acces here?
21:06 < stillunknown> darktama?
21:06 < darktama> yeah, if you make a patch I'll commit it
21:06 < stillunknown> even a patch patch? (i don't have the cvs equivalant of svn patch set up)
21:07 < darktama> as long as the "patch" command understands it, it'll be fine
21:08 < stillunknown> what diff style do you want?
21:08 < darktama> -u of course :)
21:09 < stillunknown> is there a place that lets someone upload small patches?
21:09 < stillunknown> (i always do -u, but maybe you wanted something specific)
21:19 < stillunknown> darktama: http://pastebin.co.uk/649
21:20 -!- KoalaBR [n=KoalaBR@port-83-236-13-6.dynamic.qsc.de] has joined #nouveau
21:20 < KoalaBR> Hi
21:20 -!- b33fc0d3_ is now known as b33fc0d3
21:21 < darktama> stillunknown: I'll do that in Makefile.am instead :)
21:23 < stillunknown> i kind of assumed that Makefile.am was not the source file, since it didn't contain anything usefull in the main folder
21:23 < stillunknown> but you're right
21:23 < KoalaBR> renouveau doesn't compile for me. the interesting register dump does interesting things with my compiler :)  uint32_t is an unknown type for me
21:23 < KoalaBR> (during compile). Changed it to Gluint
21:24 < KoalaBR> Is that ok?
21:25 < stillunknown> darktame: scream when it's applied, so i can try to compile the "nv" driver
21:25 < marcheu> KoalaBR: yup
21:25 < darktama> KoalaBR: add "#include <stdint.h>" to the top of tests.c
21:25 < marcheu> yeah, or that
21:26 < KoalaBR> Ok. Thanks
21:26 < KoalaBR> WIll use the include
21:26 < darktama> stillunknown: done, thanks
21:26 < KoalaBR> marcheu: Want a dump of those interesting regs?
21:26 < marcheu> KoalaBR: can you update your sf.net dumps ?
21:27 < KoalaBR> Well, I can try to put them on sf
21:27  * stillunknown forgot cvs anon is delayed :-(
21:27 < KoalaBR> Will ping you if I'm done
21:28 < marcheu> KoalaBR: yeah, we put dumps in the topic url usually
21:29 < marcheu> stillunknown: not by much
21:29 < KoalaBR> marcheu: Can I overwrite darktama's tests? I have the same type as he (NV43)
21:29 < marcheu> KoalaBR: is it the same pciid ?
21:29 < marcheu> KoalaBR: otherwise both can sit in the same dir
21:29 < KoalaBR> Oh, didn't think of this
21:29 < KoalaBR> Stupid me :)
21:32 < stillunknown> marcheu: seems so
21:33 < marcheu> stillunknown: btw, maybe you could document the build instructions on the wiki
21:33 < stillunknown> i will once i get them running mysefl
21:33 < marcheu> hehe :)
21:34 < marcheu> darktama: btw is your fd.o account workgin ?
21:34 < darktama> I haven't actually used it at all yet
21:34 < marcheu> you should be able to ssh gabe.fd.o
21:35 < stillunknown> but now i want to try to get the 8774 drivers running
21:35 < darktama> yup, that works
21:35 < darktama> stillunknown: just copy the ebuild for the last release
21:36 < stillunknown> and remove the xorg block :-)
21:36  * darktama cheated and used emerge --nodeps
21:36 < stillunknown> i like to things the right way
21:37 < darktama> I also got rid of the epatch line that adds some kernel updates, I imagine they're already applied in 8774
21:38 < darktama> anyway, sleep time for me
21:38 < darktama> night
21:39 < marcheu> hehe, you're almost on european time (8pm here :) good night 
21:43 < KoalaBR> marcheu: I get a permission denied if I try to scp to /home/groups/n/no/nouveau/htdocs/tests/nv40
21:43 < KoalaBR> Did I miss anything?
21:43 < marcheu> KoalaBR: the folder probably belongs to darktama... just go create another one
21:44 < KoalaBR> Ok
21:44 < marcheu> that way we don't even mix the files
21:50 < KoalaBR> marcheu: Done. nv40br contains the dumps
21:53 -!- stillunknown [n=madman20@82-168-177-167.dsl.ip.tiscali.nl] has quit []
21:56 < pmdata> people making dumps should change the group to nouveau, and give 664 permissions to files, so others can update
21:58 < KoalaBR> pmdata: I am sorry, obviously I'm an egoist (It's my preciousss) :)
21:59 -!- stillunknown [n=madman20@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
22:00 < pmdata> there are some uploads in test that don't have nouveau as group, so it's hard to update them with new renouveau
22:01 < KoalaBR> No problem at all, already changed it
22:02 < stillunknown> it's strange to have hardware accel again after more than a month again
22:02 < stillunknown> r/again/without
22:04 < pmdata> so we have c51,g71,nv18gl and nv40 still in group users
22:04 < marcheu> darktama: https://bugs.freedesktop.org/show_bug.cgi?id=6151
22:04 < marcheu> pmdata: is one of those from me ?
22:05 < pmdata> the c51 one
22:05 < pmdata> the others are from qfire,bware and darktama_
22:06 -!- phh [n=phh@moi.phhusson.info] has joined #nouveau
22:06 < marcheu> hehe, 1 out of 10, pretty good I think :)
22:06 < pmdata> there are 17 dirs currently
22:06 < marcheu> yeah, but 10 are from me
22:07 < pmdata> 11
22:07 < phh> Did someone looked for the rotations ?
22:07 < marcheu> pmdata: okay, 1 out of 11 ! even better
22:07 < marcheu> phh: rotations ?
22:08 < phh> marcheu, the NVIDIA driver can on geforce > 2MX and with 24bits do rotations of the screen
22:08 < KoalaBR> Well, just a small statistic from me: Yesterday we had 93 unknown NV40 commands. Today we are down to 80
22:08 < marcheu> phh: nope
22:08 < marcheu> phh: no one looked at that
22:08 < phh> ok i will, after kaamelott :D
22:08 < marcheu> KoalaBR: don't worry, there will always be unknown stuff
22:09 < phh> hum
22:09 < phh> i wonder if it isn't simulated (overlay "disappear"
22:09 < phh> )
22:09 < marcheu> ah
22:09 < phh> (at least that's what says the readme)
22:09 < marcheu> in any case, we learn how to rotate the overlay then
22:09 < KoalaBR> marcheu: I don't worry. But I will later move on and try my hands on the driver code
22:10 < pmdata> ah, arb_point_parameters done using vertex program on nv40
22:10 < phh> Workstation RGB or CI overlay visuals will function at lower performance and
22:10 < phh> the video overlay will not be available when RandRRotation is enabled.
22:10 < phh> hum
22:10 < KoalaBR> btw. has ddl reported back? I haven't read anything regarding BIOS parsing lately (Is this still a problem)?
22:10 < marcheu> phh: now, you'll probably have to look at the 2D fifo for that. in which case you'll need to patch renouveau I think
22:11 < phh> marcheu, aie.
22:11 < marcheu> phh: there's a piece of commented out code, re.c:450
22:12 < marcheu> it does that, with a fixed offset for the Xorg fifo. I have no better stuff than that
22:12 < phh> marcheu, but overlay tries does that already, isn't it ?
22:12 < marcheu> overlay tests ? do these even work ?
22:12 < phh> no idea.
22:12 < marcheu> overlays go through the Xorg fifo, which means it requires the same change
22:13 < marcheu> hmm, maybe it maps a fifo for Xv processes...
22:13 < marcheu> you'll have to ask pmdata I guess
22:13 < phh> pmdata, ?
22:14 < pmdata> yes?
22:15 < phh> pmdata, do renouveau have all needed to make 2D tests ?
22:15 < pmdata> hum, just remove the SDL_OPENGL flag when setting the video mode, and voila
22:16 < pmdata> that's what test_overlay comment say
22:16 < phh> marcheu, bon ben t'exagere un peu toi.
22:16 < marcheu> hehe :)
22:16 < marcheu> pmdata: so Xv maps a fifo into the process space to do its stuff ?
22:16 < pmdata> I never tested it again after I wrote it, because there were nothing outputted
22:16 < pmdata> but I should try again
22:16 < marcheu> ah !
22:17 < marcheu> nothing was output because you're not looking at the right fifo...
22:17 < marcheu> which proves my point I think
22:18 < pmdata> "FIFO channel couldn't be detected. PLEASE REPORT (0x2504 is 40000003/40000003)"
22:19 < phh> awake me when you will succeed.
22:19 < marcheu> phh: hmm, I think I told you how to do it..
22:20 < zoeloelip> is there are script that automates the dumps for all tests? I can do a dump of a NV31M
22:20 < phh> marcheu, it should be enough ?
22:20 < phh> just uncomment that ?
22:20 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit ["MOSFET"]
22:21 < phh> Oo
22:21 < phh> we can close a fd
22:21 < phh> after made a mmap()
22:21 < phh> without loosing this memory space ?
22:21 < pmdata> zoeloelip> you don't have a text editor to uncomment them in main.c ?
22:22 < zoeloelip> yes, I have. But maybe there was a script that runs each test and put's them in a file with a specific name
22:22 < phh> zoeloelip, with a true editor
22:22 < marcheu> phh: try it and see :) I don't run the proprietary driver here
22:22 < phh> it's easy.
22:22 < phh> marcheu, ok
22:23 < pmdata> zoe> of course, uncomment OUTPUT_TO_MULTIPLE_FILES in re.c
22:24 < marcheu> pmdata: maybe we should have all tests enabled by default in cvs ?
22:24 < marcheu> so that people can download, compile & run
22:25 < phh> mmap: Invalid argument
22:25 < phh> ol
22:25 < pmdata> yep, maybe
22:26 -!- shenki [n=shenki@121.44.69.112] has joined #nouveau
22:26 < zoeloelip> is it safe to run all tests uncommented? could they mess up each other results
22:28 < pmdata> it should be ok, except test_overlay at the end, which does not work :)
22:28 < pmdata> also uncomment dont_dump_changed_regs and dont_dump_above_40000 in re.c
22:29 < shenki> just incase someone hasn't mentioned it, it appears the new nvidia drivers are out :)
22:30 < stillunknown> anyone here have experience with something called drmstat?
22:30 < phh> shenki, Oo
22:30 < phh> something useful ?
22:30 < phh> (like Xorg 7.1 compatibliy)
22:30 < phh> or texture_from_pixmap
22:30 < shenki> phh: yes
22:30 < pmdata> "improve game XXX performance by 0.1%"
22:30 < phh> pmdata, pchut
22:30 < shenki> it doesn't mention texture_from_pixmap, trying to find out atm
22:30 < shenki> but 7.1, yes
22:31 < marcheu> shenki: it doesn't have it
22:31 < phh> shenki, if xorg 7.1 it should
22:31 < phh> WOW
22:31 < stillunknown> no
22:31 < phh> XVideo with composite
22:31 < stillunknown> texture_from_pixmap will not appear until 9xxx
22:31 < phh> i thaught xorg 7.1 impose t_f_p
22:31 < zoeloelip> I'm running the new version now on FC rawhide with renderaccel enabled
22:31 < zoeloelip> and I still have my fonts :)
22:32 < stillunknown> anyone know what drmstat is?
22:32 < phh> zoeloelip, :)
22:32 < marcheu> stillunknown: yeah, it's a program to test basic functionality of a drm device
22:32 < marcheu> outdated
22:33 < stillunknown> i'm trying to convert an existing ebuild and it breaks on that
22:33 < marcheu> only devs need it
22:33 < stillunknown> dristat outdated too?
22:34 < stillunknown> basicly i'm also curious why no .o files are created in libdrm during build
22:34 < stillunknown> (this is the complaint when building drmstat)
22:34 < stillunknown> only .lo files are created
22:36 < pmdata> search for a .libs dir
22:36 -!- phh [n=phh@moi.phhusson.info] has quit ["Quitte"]
22:36 < marcheu> stillunknown: dristat dead as well
22:37 < stillunknown> do i need to load both drm and nv module?
22:37 < zoeloelip> These are the results for my geforce go5650 (nv31m) http://bart.ulyssis.org/nv31m.tar.bz2
22:37 < marcheu> stillunknown: yes, but the kernel modules are "drm" and "nouveau"
22:38 < pmdata> I will put them on nouveau.sf.net/tests
22:40 < stillunknown> nouveau.ko isn'rt created :-(
22:40 < stillunknown> my fault :-)
22:41 < stillunknown> updating libdrm and xf86-video-nv was easy
22:41 -!- Myrizio [n=Myrizio@host139-102.pool80104.interbusiness.it] has joined #nouveau
22:41 < pmdata> done
22:41 < stillunknown> x11-drm, not so easy :-(
22:42 < pmdata> 1ec0-1edc seems to be nv30 point parameters
22:43 -!- phh [n=phh@moi.phhusson.info] has joined #nouveau
22:43 < stillunknown> one problem solved, question, anything specific in the xorg conf that differs from nv module?
22:43 < stillunknown> and does nvidia.ko interfere with the nouveau drivers
22:44 < phh> (WW) NVIDIA(0): Rotation is only supported in depth 24.
22:44 < phh> pccccccch
22:48 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
22:51 -!- phh [n=phh@moi.phhusson.info] has quit [Remote closed the connection]
22:52 < marcheu> stillunknown: maybe you could try EXA :)
22:52 < marcheu> stillunknown: I think nvidia.ko and drm.ko/nouveau.ko accept beigon loaded at the same time, but I suppose that's a big mistake, yes
22:52 -!- phh [n=phh@moi.phhusson.info] has joined #nouveau
22:56 < phh> in re.c ligne 253
22:56 < phh> 0xe0011000-2*0x8000 is universal
22:56 < phh> or has only been manually calculated for a specific computer ?
22:56 < marcheu> yeah, for mine :)
22:57 < marcheu> basically, look at your maps
22:57 < marcheu> get the physical adress for the fifo map
22:57 < marcheu> put it instead of 0xe0011000
22:57 < marcheu> I think that's it
22:57 < pmdata> can you explain why they are all nvtypefffff? http://nouveau.sourceforge.net/tests/nv31/card_10de-031b_test_startup.txt
22:57 < phh> the maps ?
22:58 < phh> in lspci?
22:58 < marcheu> phh: the ones displayed on renouveau strartup
22:58 < phh> agp aperture ?
22:58 < marcheu> pmdata: real weird
22:59 < pmdata> zoe dump
22:59 < zoeloelip> If I need to run some new tests, just give me a kick
22:59 < marcheu> ah, mobile card
22:59 < phh> FIFO channel couldn't be detected. PLEASE REPORT (0x2504 is 40000003/40000003)
22:59 < phh> beehhh
22:59 < phh> arf
23:00 < phh> ok forget
23:00 < stillunknown> marchue: how do i try exa?
23:00 < stillunknown> marcheu
23:00 < phh> pmdata, so it's the line map 4   from 0xaddaa000 to 0xadeac000 size 0x102000 (physical 0xc00e1000)       => fifo
23:00 < phh>  ?
23:01 < phh> and i set 0xaddaa000 instead of 0xe0011000 ?
23:01 < marcheu> stillunknown: in your device section, add Option "AccelMethod" "EXA"
23:01 < marcheu> phh: I said "physical adress"
23:01 < stillunknown> does the device accept all the usual nv options?
23:01 < marcheu> stillunknown: yes
23:01 < phh> arf read too quick
23:01 < phh> ok thks
23:03 < stillunknown> i'm going to try
23:03 < stillunknown> brb
23:03 -!- stillunknown [n=madman20@82-168-177-167.dsl.ip.tiscali.nl] has quit []
23:04 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
23:05 < marcheu> pmdata: really, it looks like everything works except display
23:05 < marcheu> pmdata: the objects are correctly guessed
23:05 < marcheu> maybe a renouveau bug
23:15 < zoeloelip> ah, I forgot to mention I had to uncomment the _syscall3(int, sys_ioctl, int, fd, int, request, void*, pointer) line in renouveau and put a #if 0 around ioctl both in the ioctl.c file
23:15 < zoeloelip> otherwise renouveau wouldn't compile
23:17 < KoalaBR> See you either tomorrow or saturday. Bye
23:17 -!- KoalaBR [n=KoalaBR@port-83-236-13-6.dynamic.qsc.de] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.13/20060417]"]
23:18 -!- stillunknown [n=madman20@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
23:19 < stillunknown> marcheu: didn't work (ddx or exa)
23:19 < stillunknown> i've got one question, why does it load dri module even if not specified?
23:20 < phh> because it needs it ?
23:21  * phh return to trying rotation
23:21 < stillunknown> guess that could be a reason for it to fail
23:22 < stillunknown> (i still have stock dri, since i didn't expect to do any 3d stuff for a while)
23:32 < pmdata> yep, only the test_startup shows this, the other dumps are ok
23:33 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
23:47 < pmdata> fun: nv31 uses texture matrix commands, whereas nv34 uses a fragment program for texture matrix
23:48 < phh> huhu
23:48 < stillunknown> is there a package which is similar to the nouveau dri module? (there seems to be no generic libdri)
23:48 < phh> pmdata, it means texture matrix no longer exists or ?
23:48 < phh> stillunknown, similar ?
23:48 < pmdata> maybe it still exists on nv34, they just maybe unused because fragment programs maybe faster
23:49 < phh> maybe
23:49 < stillunknown> phh: i mean something i can adjust to work with the nouveau dri module instead of making something from scratch
23:50 < phh> ah
23:50 < phh> http://people.freedesktop.org/~ajax/libdrm/libdrm-2.0.2.tar.gz ?
23:51 < stillunknown> i mean dri, not drm
23:51 < phh> it isn't the same ?
23:51 < phh> (my memory about dri/drm is a bit far)
23:52 < stillunknown> the problem is that gentoo uses this system for modular x that i don't know completely, so i prefer to adapt a package build file)
23:52 < stillunknown> they are not the same
23:52 < phh> i thaught that dri was the whole projects which includes agpgart + drm + X driver
23:53 < stillunknown> check the nouveau page
23:53 < stillunknown> it has it's own module on the cvs server
23:53 < phh> yes i know
23:54 < phh> ok i see
23:54 < phh> stillunknown, ok it's MesaLib
23:54 < phh> sourceforge.net/projects/mesa3d
23:56 < phh> i confirm it begins to build
23:56 < phh> (but don't go more far)
23:57 < phh> (more but not to end i mean)
--- Log closed Птн Авг 25 00:00:11 2006
