--- Log opened Пнд Сен 18 00:00:40 2006
00:03 -!- Myrizio [n=Myrizio@host93-102-static.104-80-b.business.telecomitalia.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
00:36 -!- nael_ is now known as nael
00:48 -!- EdB [n=EdB@ARennes-251-1-85-249.w86-199.abo.wanadoo.fr] has quit ["Konversation terminated!"]
00:57 -!- nael_ [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has joined #nouveau
01:00 -!- nael [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has quit [Read error: 104 (Connection reset by peer)]
01:46 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has quit [Remote closed the connection]
01:50 < marcheu> so, interrupts enable bits differ starting from nv40
01:52 < marcheu> it's pretty clear from looking at the intesting regs dumps
01:54 < Duke`> hehe, you kept secret the hardware on wich you are working in your mail
01:55 < marcheu> well, I was trying to focus the discussion on my question, not on what hardware we have
01:55 < marcheu> I think people know this project anyway
01:56 < marcheu> these new enable bits puzzle me...
02:01 < rem> good night^W^Wbye folks
02:01 -!- rem [i=rem@ALyon-252-1-55-192.w83-197.abo.wanadoo.fr] has quit ["dodo"]
02:03 -!- Duke` [n=gnu@ANantes-251-1-141-105.w86-210.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:11 -!- etzel_ [n=thisnuke@west-193.rcn.nmt.edu] has joined #nouveau
02:19 -!- caro [n=vincent@alf94-3-82-66-248-160.fbx.proxad.net] has quit ["My taylor is rich"]
02:26 -!- etzel [n=thisnuke@west-193.rcn.nmt.edu] has quit [Connection timed out]
02:27 -!- etzel_ is now known as etzel
02:44 -!- marteus_ [n=marteus@0x50c475bf.albnxx8.adsl-dhcp.tele.dk] has quit [Read error: 110 (Connection timed out)]
02:51 -!- nael_ [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has quit [Connection timed out]
02:57 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
03:04 < marcheu> ah well, can't get anything else than fifo error irq...
03:05 < airlied> so why do you think re-writing the FIFO loses the usefulness of hw contets?
03:05 < marcheu> because we don't have to go through the kernel right now
03:05 < marcheu> we can submit comands from user space, and don't need to parse a command buffer twice
03:05 < airlied> but the kernel has to schedule the FIFOs... so it is involved..
03:06 < marcheu> which would be stupid, given that the hardware can enfore all the security we want
03:06 < airlied> I'd wonder what exactly nvidia do for this... considering they have the same issue..
03:06 < marcheu> yes it has to schedule, but for example won't be involved when there is only one context
03:07 < marcheu> I think they do some pinnng/unpinning of areas in memory
03:07 < marcheu> client pins areas as long as it knows the hw will need it, unpins afterwards
03:08 < airlied> I can't see how pinning/unpinning can work with multiple clients..
03:08 < airlied> I can see how it works, I can see how it would work efficently..
03:08 < airlied> doh.. can't see how it would work efficently..
03:08 < marcheu> yeah, not sure either
03:09 < marcheu> but at least it works, as opposed to the current way
03:09 < marcheu> maybe you can just have a list of pinned areas, and a lock on it
03:09 < marcheu> it's probably not that expensive
03:11 < marcheu> we're talking about a memory contention situation anyway
03:12 < airlied> that's true. in which case we are probably in trouble already..
03:13 < marcheu> well, my point is that it's already slow at that point
03:13 < airlied> I wonder do the later chips have virtual VRAM stuff..
03:13 < marcheu> because of all the transfers going on, and thus the locking will probably be inexpensive compared with the transfers
03:13 < marcheu> I don't think so
03:14 < airlied> I think DX10 started asking for virtual graphics RAM..
03:14 < marcheu> no nvidia DX10 accelerator exists as of today
03:15 < airlied> ah..
03:15 < marcheu> likewise for ati...
03:15 < marcheu> DX10 is R600 and geforce 8xxx
03:17 < marcheu> also, I'm not sure how stable all that offset fixup code will be in the end
03:17 < marcheu> I guess I'll see how it fares with the other drivers
03:22 < airlied> marcheu: have you seen http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWPR05007_WinHEC05.ppt
03:22 < airlied> it isn't very in-depth though..
03:24 -!- dfryer|away is now known as dfryer
03:24 < marcheu> the virtualization part ?
03:24 < airlied> yup..
03:25 < marcheu> where do you see it uses paging ?
03:25 < airlied> advanced driver model..
03:25 < airlied> can fault pages in on demand..
03:25 < marcheu> hmm, that's not even possible on any hw I know of
03:26 < airlied> marcheu: I think the r5xx can do some of it..
03:27 < marcheu> so, microsoft invents the drm
03:28 < airlied> hehe.. yeah well they do design all the graphics cards..
03:28 < marcheu> well, nvidia had it for a long time
03:29 < marcheu> so, do you have an idea how we could solve our issue ?
03:30 < airlied> so we can't object re-write either.. if I read darktama's earlier sstuff..
03:30 < marcheu> well, we're not 100% sure about that but we both think that it's probably not possible
03:31 < airlied> I need to look at the texture object and what data are in them..
03:32 < airlied> it just seems like that is what objects should be for..
03:32 < airlied> so you have no address in the FIFO just object references..
03:32 < airlied> and you fixup the objects..
03:32 < marcheu> yeah, that's the hope
03:33 -!- profyy [n=zef@seg75-5-82-234-115-82.fbx.proxad.net] has quit ["Leaving"]
03:33 < marcheu> I still fail to get that context switch irq anyway
03:34 < airlied> if we can't do that then I can't see any other way than just pinning everything like a slightly more intelligent via/sis..
03:34 < marcheu> hmm, do via and sis pin the buffers ?
03:34 < airlied> and if we run ouf of VRAM we stop running more apps..
03:35 < airlied> I think the via/sis driver just hand out blocks to the usersspace..
03:35 < airlied> there is no texture aging or any of that stuff..
03:35 < marcheu> yeah, so these aren't converted to the new mem manager yet
03:35 < marcheu> has some driver been converted to do that stuff already ?
03:35 < airlied> marcheu: nope, Thomas has converted them to use handles properly..
03:36 < airlied> marcheu: i915 is the only one in converison at the moment..
03:36 < marcheu> ah, so i915 does fixup the fifo ?
03:36 < airlied> and that is on the branch and shared memory ..
03:36 < airlied> as i915 is sshared memory, the TTM stuff does a bit of both..
03:37 < airlied> it can page things sin and it re-writes the FIFO inside the lock..
03:37 < airlied> the via/sis updates Thomas did just fixed them up to use handles cleanly so userspace wasns't using addresses..
03:37 < marcheu> ok, so it's of no interest to us
03:37 < marcheu> only i915 is
03:38 < airlied> yup.. it's in the branch on drm git..
03:39 < marcheu> maybe we could do something like "if the current working set of an app is using up more than 70% of VRAM, kill it"
03:39 < airlied> drm-ttm-0-2-branch
03:39 < marcheu> and have the restriction known to user space as well
03:39 < airlied> but lots of games will do that..
03:39 < marcheu> user space would then have to use AGP or PCI-E access
03:39 < marcheu> yeah
03:41 < airlied> did you do some work already in extending sis/via type memory manager?
03:41 < marcheu> extending as in ?
03:41 < airlied> adding nv features?
03:41 < marcheu> for now our manager is a port of the i915 one, which has options for allocating AGP or VRAM, and mapping to user space
03:41 < marcheu> that's about it
03:42 < marcheu> it has the advantage of being used everywhere, so our code is drm-memory-manager-aware
03:42 < marcheu> plugging another one wouldn't be much of an issue
03:43 < airlied> marcheu: there is that I think once the ttm code is standard, changing over mightn't be that hard..
03:43 < marcheu> yeah, but if the ttm comes with an interface that disables interesting hardware features like hw context, it's not that interesting
03:44 < marcheu> therefore, we have to discuss that before it's standard
03:44 < airlied> marcheu: true.... hopefully Thomas or Keithw wake up and respond..
03:44 < marcheu> they both live in the .eu timezone
03:44 < marcheu> where it is almost 2am :)
03:44 -!- etzel [n=thisnuke@west-193.rcn.nmt.edu] has quit [Remote closed the connection]
03:45 < marcheu> I really hope we can do the object stuff
03:45 < marcheu> that would be really neat
03:45 < airlied> you live in .eu :-)
03:45 < airlied> do we have any usage of texture objects yet?
03:45 < marcheu> usage ? in our code ? no
03:46 < airlied> ah... I thought EXA might use them... 
03:46 < marcheu> well, darktama has some nv40-exa using the 3D engine which half-works
03:47 < marcheu> but I think he mentioned that the object was common to all texunits
03:47 < marcheu> on nv30+
03:48 -!- etzel [n=thisnuke@west-193.rcn.NMT.EDU] has joined #nouveau
03:48 < airlied> so NVDmaStart + Next + Kickoff just write things to the FIFO.?
03:49 < marcheu> you see, all those *TCL_PRIMITIVE_3DSET_* setup objects, some of which we don't know what they're for
03:49 < marcheu> yeah, Start/Next writes stuff, Kickoff writes the fifo PUT register
03:50 < dfryer> ... so, anyone tried any of this on powerpc?
03:50 < airlied> dfryer: keep meaning to..
03:50 < marcheu> dfryer: nope... you're welcome to
03:50 < dfryer> ok
03:50 < airlied> we don't have renovueu for macosx either..
03:50 < dfryer> hm
03:51 < dfryer> it would be.. different I think
03:51 < marcheu> not that different IMO
03:51 < marcheu> it's really only about mapping physical memory areas
03:51 < marcheu> the rest could be disabled (ioctl hooks, nvctrl extension...)
03:52 < dfryer> I suppose, was just thinking that the Mysterious Apple Mojo in between the opengl library and the back end would make things harder to interpret
03:52 < marcheu> no, you map the physical adress of the fifo and look there. you don't really care that the opengl calls travell through the west passage or the east one...
03:53 < dfryer> right
03:53 < dfryer> and what's the secret to finding where to mmap?
03:53 < dfryer> (I'm no kernel hacker, xnu or linux)
03:54 < marcheu> it's exported as a pci resource
03:54 < marcheu> hmm actually not all of it, only the regs
03:54 < marcheu> for the fifo, you have to find where it sits first
03:55 < marcheu> it will usually be in AGP area
03:55 < marcheu> or VRAM on PCI systems
03:55 < marcheu> the rigid packet format makes it easy to spot
03:55 < dfryer> well, I'm working on an AGP emac with a geforce2MX, so not exactly mysterious cutting edge hardware
03:57 < marcheu> so your AGP chipset should export some resources (the AGP area usually)
03:57 < marcheu> the fifo sits somewhere in there, usually at the beggining
03:57 < marcheu> the hw has multiple fifos, but once you find the first one they're contigous
03:57 < dfryer> and the fifo is a buffer of commands/data that the hardware reads out of?
03:57 < marcheu> yes
03:58 < marcheu> and renouveau reads there as well :)
03:58 < dfryer> mm, so it just scans what has been written before it is overwritten?
03:58 < marcheu> yup, it's a dumb "look for changes before/after" program
03:58 < dfryer> not sure that's so dumb :)
03:59 < marcheu> the very first versions were really dumb :)
03:59 < dfryer> probably easier than convincing the driver to write to renouveau's memory and passing that on to the hardware
03:59 < marcheu> yeah, that's way harder
04:03 < dfryer> and of course all this should be done without.. uh.. violating terms and conditions of system software
04:04 < dfryer> I'm not sure a macosx renouveau client would be that helpful though, as the "target audience" of nouveau probably has linux running somewhere
04:04 < dfryer> and wouldn't have too much trouble running linux on their mac
04:05 < marcheu> the mac nvidia driver has a couple of differences
04:05 < marcheu> it can do YUV textures, and some other stuff
04:05 < dfryer> ah..
04:05 < dfryer> so there would be more feature information
04:05 < marcheu> and is big endian, which the proprietary linux driver doesn't support
04:06 < dfryer> does that matter on the hardware end though?  I would assume that the command/data format is the same on either...
04:06 < dfryer> or can the card be instructed to accept things in big-endian order?
04:07 < marcheu> yup
04:07 < dfryer> ah
04:07 < dfryer> heh, I just clued into the fact that running renouveau on powerpc linux would be useless :)
04:07 < dfryer> since there's.. no driver to give it information
04:08 < dfryer> maybe I'm a little slow :)
04:08 < dfryer> no *3D* driver at least
04:11 < dfryer> in macosx, would it be hard to run tests with the window manager presumably spamming things?
04:12 < marcheu> well, there's one fifo per context
04:12 < marcheu> so, the window manager (and all 2D stuff) has its own
04:12 < marcheu> bedtime
04:12 < dfryer> gnight
04:28 -!- predatorfreak [n=predator@adsl-69-212-44-252.dsl.sfldmi.ameritech.net] has joined #nouveau
06:08 -!- predatorfreak [n=predator@adsl-69-212-44-252.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
06:37 -!- darktama [n=darktama@gentoo/contributor/darktama] has quit [Read error: 110 (Connection timed out)]
06:40 -!- darktama [n=darktama@gentoo/contributor/darktama] has joined #nouveau
06:45 -!- dfryer_ [n=dfryer@d207-216-29-18.bchsia.telus.net] has joined #nouveau
06:45 -!- dfryer_ [n=dfryer@d207-216-29-18.bchsia.telus.net] has quit [Remote closed the connection]
06:46 -!- dfryer [n=dfryer@d207-216-29-18.bchsia.telus.net] has quit [Remote closed the connection]
08:36 -!- Gusar [n=Gusar@cpe1-23-67.cable.triera.net] has quit ["leaving"]
08:41 -!- tibbs is now known as tibbs|h
09:33 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
09:33 -!- Duke` [n=gnu@ANantes-251-1-141-105.w86-210.abo.wanadoo.fr] has joined #nouveau
09:35 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Client Quit]
10:35 -!- caro [n=vincent@alf94-3-82-66-248-160.fbx.proxad.net] has joined #nouveau
10:48 -!- Koala_BR [n=KoalaBR|@195.227.227.59] has joined #nouveau
10:48 < Koala_BR> marcheu: ping
11:24 -!- darktama_ [n=darktama@124-168-238-39.dyn.iinet.net.au] has joined #nouveau
11:25 -!- EdB [n=EdB@ARennes-251-1-13-2.w83-195.abo.wanadoo.fr] has joined #nouveau
11:30 -!- darktama [n=darktama@gentoo/contributor/darktama] has quit [Read error: 113 (No route to host)]
11:31 < Koala_BR> marcheu: You wanted to talk to me? Just post it in this channel if I'm not there, I read the logs
11:41 -!- Gusar [n=Gusar@e-43.vc-graz.ac.at] has joined #nouveau
11:41 -!- Gusar [n=Gusar@e-43.vc-graz.ac.at] has quit [Client Quit]
11:43 -!- Gusar [n=Gusar@e-43.vc-graz.ac.at] has joined #nouveau
12:15 -!- Duke` [n=gnu@ANantes-251-1-141-105.w86-210.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
12:16 -!- Duke` [n=gnu@ANantes-251-1-85-201.w86-203.abo.wanadoo.fr] has joined #nouveau
12:55 < airlied> marcheu: heh.. keithw has same ideas as us... :-)
12:56 < airlied> or maybe :-(
14:57 -!- lumag_offline [n=mitya@chimpanzee.school.ioffe.ru] has joined #nouveau
14:57 -!- Topic for #nouveau: 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
14:57 -!- Topic set by sturmflut [] [Sun Aug 13 17:02:24 2006]
14:57 [Users #nouveau]
14:57 [@ChanServ] [ b33fc0d3 ] [ EdB     ] [ lumag_offline] [ shenki      ] 
14:57 [ Aexoden ] [ caro     ] [ etzel   ] [ marcheu      ] [ stillunknown] 
14:57 [ ag      ] [ cetrox_  ] [ fatal__ ] [ mjg59        ] [ tibbs|h     ] 
14:57 [ airlied ] [ darktama_] [ flex    ] [ monocle      ] [ titou       ] 
14:57 [ ajmitch ] [ ddl      ] [ Gusar   ] [ nano-        ] [ zoeloelip   ] 
14:57 [ anders_ ] [ Duke`    ] [ Koala_BR] [ rem          ] 
14:57 -!- Irssi: #nouveau: Total of 29 nicks [1 ops, 0 halfops, 0 voices, 28 normal]
14:57 -!- [freenode-info] if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
14:57 -!- Channel #nouveau created Sun Jun 25 07:52:56 2006
14:57 -!- Irssi: Join to #nouveau was synced in 5 secs
15:30 -!- lumag_of1line [n=mitya@chimpanzee.school.ioffe.ru] has joined #nouveau
15:30 -!- Topic for #nouveau: 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
15:30 -!- Topic set by sturmflut [] [Sun Aug 13 17:02:24 2006]
15:30 [Users #nouveau]
15:30 [@ChanServ] [ b33fc0d3 ] [ EdB     ] [ lumag_of1line] [ rem         ] 
15:30 [ Aexoden ] [ caro     ] [ etzel   ] [ lumag_offline] [ shenki      ] 
15:30 [ ag      ] [ cetrox_  ] [ fatal__ ] [ marcheu      ] [ stillunknown] 
15:30 [ airlied ] [ darktama_] [ flex    ] [ mjg59        ] [ tibbs|h     ] 
15:30 [ ajmitch ] [ ddl      ] [ Gusar   ] [ monocle      ] [ titou       ] 
15:30 [ anders_ ] [ Duke`    ] [ Koala_BR] [ nano-        ] [ zoeloelip   ] 
15:30 -!- Irssi: #nouveau: Total of 30 nicks [1 ops, 0 halfops, 0 voices, 29 normal]
15:30 -!- Channel #nouveau created Sun Jun 25 07:52:56 2006
15:30 -!- lumag_offline [n=mitya@chimpanzee.school.ioffe.ru] has quit [Read error: 104 (Connection reset by peer)]
15:30 -!- Irssi: Join to #nouveau was synced in 6 secs
16:18 -!- marteus [n=marteus@0x50c475bf.albnxx8.adsl-dhcp.tele.dk] has joined #nouveau
16:42 -!- cetrox_ is now known as cetrox
17:01 -!- stillunknown [n=stillunk@82-168-177-167.dsl.ip.tiscali.nl] has quit ["Words get written, words get twisted, old meanings change in the drift of time. (sung by Ian Anderson)"]
17:04 -!- stillunknown [n=stillunk@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
17:09 -!- jkolb [n=jkolb@wsi-128-213.wsi.com] has joined #nouveau
17:22 < darktama_> speaking of headers, how portable is it to use bitfield structs?  I was thinking I'd use them to represent shader instructions instead of dealing with shifts/masks
17:27 < rem> darktama_: just problems with big endian and little endian
17:28 < Koala_BR> If you want me to add some default defines to the generator - let me know
17:34 < darktama_> rem: ah, I see what you mean.. on a little endian machine this didn't act how I would expect :)
17:36 < darktama_> that can be dealt with easily enough I think, have a different struct for each.. with #if's around them
17:36 < darktama_> any other problems?
17:36 < darktama_> Koala_BR: such as?
17:37 < Koala_BR> Well bitmasks and some such which would make life easier
17:38 < darktama_> I personally don't like using bitmasks the way they are in nv_objects.h, much prefer *_SHIFT/*_MASK over that
17:39 < Koala_BR> marcheu wanted me to add an include feature into the generator, so if I am at it, I can add features you deem useful too
17:39 < rem> darktama_: but it's not too hard, just defining some #define BUILD_COMMAND( x, y, z ) depending on LE/BE and that's all.
17:41 < darktama_> Koala_BR: ahh, I thought you were replying to my comments about big/little endian :)
17:42 -!- shenki [n=shenki@ppp33-102.lns2.adl2.internode.on.net] has quit ["http://xkcd.com/comics/fourier.jpg"]
17:47 < Koala_BR> Well partly, I had the impression, that you were thinking about some "defaults" 
17:48 < Koala_BR> I could add something like that, if you think it's useful
17:58 -!- stillunknown [n=stillunk@82-168-177-167.dsl.ip.tiscali.nl] has quit ["Words get written, words get twisted, old meanings change in the drift of time. (sung by Ian Anderson)"]
17:59 -!- stillunknown [n=stillunk@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
18:01 < rem> stupid question, are you modifying nv driver or are rewriting it from scratch ?
18:02 < darktama_> xf86-video-nouveau is a heavily modified xf86-video-nv
18:02 < darktama_> the rest is from scratch
18:02 < rem> 'k
18:41 -!- phh [n=phh@moi.phhusson.info] has joined #nouveau
18:54 -!- shenki [n=shenki@ppp38-6.lns2.adl2.internode.on.net] has joined #nouveau
19:07 -!- Koala_BR [n=KoalaBR|@195.227.227.59] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.12/20050920]"]
19:19 -!- marteus [n=marteus@0x50c475bf.albnxx8.adsl-dhcp.tele.dk] has quit [Read error: 110 (Connection timed out)]
19:44 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
19:54 -!- predatorfreak [n=predator@adsl-69-212-44-252.dsl.sfldmi.ameritech.net] has joined #nouveau
20:02 -!- elsewhereunknown [n=elsewher@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
20:12 -!- stringfellow_ [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
20:14 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
20:21 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
20:26 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
20:29 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
20:40 -!- rem [i=rem@ALyon-252-1-67-242.w82-122.abo.wanadoo.fr] has quit ["out"]
20:55 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
21:02 -!- pmdata [n=patrice@ANantes-154-1-22-86.w81-53.abo.wanadoo.fr] has joined #nouveau
21:02 < pmdata> ping titou
21:08 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
21:08 < pmdata> titou> syscall are defined in include/asm-<arch/unistd.h in kernel sources, if you need to have a look
21:14 < phh> pmdata, in glibc they redefine this by themselves
21:14 < phh> there maybe be a reason
21:15 < pmdata> from what I read on lkml, all syscalls will be removed from kernel sources in future revisions
21:16 < phh> that's pretty strange ...
21:16 < phh> pmdata, what's the reason ?
21:18 < pmdata> avoid the temptation from using kernel stuff directly I think, so the userspace progs must go through libc
21:18 < pmdata> which is not what people messing with hw (like renouveau) need
21:26 < pmdata> so we should avoid including any stuff kernel from now on, and put it directly in renouveau
21:27 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
21:42 < titou> [19:08] <pmdata>  titou> syscall are defined in include/asm-<arch/unistd.h in kernel sources, if you need to have a look
21:42 < titou> there is no ioctl.c needed macros in this file!
21:43 < titou> i'm away
21:50 < pmdata> ah
22:00 -!- elsewhereunknown [n=elsewher@82-168-177-167.dsl.ip.tiscali.nl] has quit ["Bye"]
22:23 -!- shenki [n=shenki@ppp38-6.lns2.adl2.internode.on.net] has left #nouveau ["Leaving"]
22:30 < pmdata> marcheu> can I play again with dri? anything to add/fix?
22:34 -!- pmdata [n=patrice@ANantes-154-1-22-86.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
22:44 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
22:50 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Read error: 60 (Operation timed out)]
23:00 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit ["Les choses que l'on possède, finissent par nous posséder"]
23:08 -!- phh [n=phh@moi.phhusson.info] has quit [Read error: 104 (Connection reset by peer)]
23:20 -!- EdB [n=EdB@ARennes-251-1-13-2.w83-195.abo.wanadoo.fr] has quit ["Konversation terminated!"]
23:43 -!- etzel [n=thisnuke@west-193.rcn.NMT.EDU] has quit [Read error: 110 (Connection timed out)]
--- Log closed Втр Сен 19 00:00:41 2006
