--- Log opened Чтв Сен 21 00:00:43 2006
00:12 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has joined #nouveau
00:27 -!- cetrox [i=cetrox@171-247-222-201.adsl.terra.cl] has quit [Read error: 60 (Operation timed out)]
00:28 -!- cetrox [i=cetrox@129-169-223-201.adsl.terra.cl] has joined #nouveau
00:31 -!- Duke` [n=gnu@ANantes-251-1-174-213.w90-12.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
00:34 -!- Duke` [n=gnu@ANantes-251-1-174-213.w90-12.abo.wanadoo.fr] has joined #nouveau
00:41 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Read error: 60 (Operation timed out)]
00:53 < marcheu> ok, nv11 dumps updated
01:08 -!- nael [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has quit [Read error: 110 (Connection timed out)]
01:21 -!- dagb [i=dagb@97.80-202-99.nextgentel.com] has joined #nouveau
01:29 -!- `Duke` [n=gnu@ANantes-251-1-144-127.w86-210.abo.wanadoo.fr] has joined #nouveau
01:32 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
01:32 < pmdata> marcheu> did you notice this (in test_viewport, first lines):
01:32 < pmdata> 6e8b   0x00000000   0x0000bee0             {size: 0x0   channel: 0x5   obj: beef5f01 opcode: METHOD offset: 1ee0}
01:32 < pmdata> 		2 NOPs skipped
01:32 < pmdata> 6e8e   0x00000000   0x00000400             {size: 0x0   channel: 0x0   obj: beef7b01 opcode: METHOD offset: 0400}
01:32 < pmdata> 6e8f   0x00000000   0x00000400             {size: 0x0   channel: 0x0   obj: beef7b01 opcode: METHOD offset: 0400}
01:32 < pmdata> 6e90   0x00000000   0x00042100             {size: 0x1   channel: 0x1   obj: beef5601 opcode: METHOD offset: 0100}
01:32 < pmdata> 6e91   0x00000000   0x00000000                       NV10_TCL_PRIMITIVE_3D_NOP = 0x00000000
01:33 -!- Duke` [n=gnu@ANantes-251-1-174-213.w90-12.abo.wanadoo.fr] has quit [Nick collision from services.]
01:33 -!- `Duke` is now known as Duke`
01:33 < marcheu> yeah, we see the same stuff on nv20, nv30, nv40 and g70
01:33 < marcheu> although nv30+ use a variant
01:34 < marcheu> it's related to window size, not sure why it doesn't fit within the object scheme
01:41 < pmdata> also present in test_startup, lines 189-18c 
01:44 -!- pmdata [i=patrice@ANantes-154-1-69-26.w86-195.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
02:03 -!- Myrizio [n=Myrizio@Linuz.sns.it] has joined #nouveau
02:08 -!- Duke` [n=gnu@ANantes-251-1-144-127.w86-210.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:24 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has quit [Remote closed the connection]
02:24 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
02:25 -!- Gusar [n=Gusar@e-3.vc-graz.ac.at] has quit [Read error: 110 (Connection timed out)]
02:40 -!- Myrizio [n=Myrizio@Linuz.sns.it] has quit ["I like core dumps"]
03:36 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
03:42 < marcheu> darktama: ping ?
04:08 -!- hiyuh_work [n=hiyuh@Y041248.ppp.dion.ne.jp] has joined #nouveau
04:21 < marcheu> ok, I think we need to setup the whole fifo runout and context stuff before we can get context switches
04:31 < darktama> marcheu: it's probably likely
04:31 < marcheu> I think it's just a matter of time until we get it
04:31 < marcheu> but
04:31 < marcheu> do you know how far is the reinit hack needed ?
04:32 < darktama> eh?
04:32 < marcheu> I hate that code :)
04:32 < marcheu> yes, what portion of it is needed
04:32 < marcheu> or rather, what breaks (and why)
04:34 < darktama> oh, pfifo_reinit?  we probably need all of it done once on init.
04:34 < darktama> on a mode switch (or any time it ResetGraphics() is called), it needs to be done because we powerup/powerdown pfifo
04:34 < darktama> swap those to power-down/power-up..
04:35 < darktama> I *think* thats why we need to do it, in any case, something in LoadStateEXT() kills the setup
04:35 < darktama> s/ResetGraphics/LoadStateEXT()/
04:35 < darktama> sorry, I just woke up :)
04:37 < marcheu> so that's just the two PMC writes, right ?
04:37 < darktama> yup
04:38 < marcheu> I think they do more harm than good anyway
04:38 < marcheu> we can probably remove those two
04:39 < marcheu> also, I've been dumping the whole PFIFO register range on context creation/deletion. nothing relevant else than FIFO_DMA changes happen
04:40 < darktama> haiku's comment above the PMC writes indicate that they do it to recover from a hung engine, we just kill X anyway.. so
04:40 < marcheu> well, we can have ours on X startup anyway
04:41 < darktama> yup, I think we do that anyway in NVCommonSetup().
04:41 < marcheu> well, it's disabled right now
04:41 < marcheu> we only power up
04:41 < darktama> ah
04:43 < marcheu> I'll play with that all anyway
04:43 < darktama> marcheu: does CACHE1_PUSH1 change too? those bits contain the active channel ID
04:44 < marcheu> no
04:45 < marcheu> hmm maybe sometimes it does
04:45 < marcheu> but it depends where you come from/where you go
04:45 < marcheu> since I'm only looking at the transition
04:46 < darktama> hmm, it *should* change on every context switch I believe
04:46 < marcheu> no, seems it stays at 0x100 here
04:46 < marcheu> I'm looking at context creation here
04:46 < marcheu> not switches
04:46 < darktama> ah, that's a bit different then :)
04:46 < marcheu> since I actually suspect we have creation wrong
04:47 < darktama> yeah, that's quite likely.
04:48 < marcheu> any luck with NV30_TCL ?
04:49 < darktama> nope, I haven't looked at it since yesterday.  I hope to get some time today, but there's other things that'll probably take most of my time :(
04:50 < darktama> my current code doesn't work on my C51 either, but that *could* be because nvidia's driver doesn't work correctly either
05:02 < marcheu> yeah, and of course VT switch breaks
05:03 < darktama> without the PMC code?
05:03 < marcheu> yup
05:03 < darktama> does normal mode switches work?
05:04 < marcheu> yeah
05:04 < marcheu> no
05:05 < marcheu> I mean, mode switches break
05:05 < darktama> ok, that's not good :(
05:07 < marcheu> yeah, maybe the reinit hack is needed
05:09 < marcheu> or maybe we should do modesetting in the kernel anyway
05:10 < darktama> I'm all for that idea, if X dies in a bad place - we can revert to a text mode.. not sure how much other people like that idea though..
05:11 < marcheu> well, the other advantage is we can have the kernel save/restore a bunch of things transparently
05:12 < darktama> it simplifies the ddx a lot too, we essentially have the ddx being "just another DRM client" instead of being half in-control of the hardware
05:13 < darktama> airlied: any thoughts on that?
05:14 < marcheu> yup, if we say "modesetting in the kernel" people might start getting angry
05:14 < marcheu> the bright side is we could potentially share the code with nvidiafb :)
05:14 < darktama> yes, that's my concern.. I recall many heated discussions about that topic :P
05:15 < mjg59> Well, there's no shortage of modesetting code in the kernel right now
05:15 < darktama> marcheu: can nvidiafb use our drm btw?
05:16 < marcheu> darktama: hmm, why could it ?
05:16 < marcheu> we're probably totally broken WRT sharing the card with nvidiafb anyway
05:17 < marcheu> since they have their own copy of the infamous nv_hw.c file erasing everything and the rest
05:17 < darktama> yup, in the future when we have ctx switching and such working - if nvidiafb can use drm, we can potentially have it playing nice with our ddx/dri driver
05:17 < airlied> darktama: it would be a future goal to have the fb and drm aware of each other..
05:17 < airlied> but moving all the modesetting into the kernel isn't always that nice..
05:17 < airlied> thing driving the i2c buses and tv-out stuff..
05:18 < airlied> there really isn't a great need for all of it to be in-kernel..
05:18 < airlied> and debugging gets a lot harder..
05:18 < airlied> if X can't get to a text-mode then what makes you think the kernel can..
05:18 < marcheu> airlied: a simple "restore mode on filp close"
05:19 < airlied> marcheu: but you might have left the rest of the card in a bad way..
05:19 < marcheu> but yeah, full featured modesetting in the kernel might get pretty big
05:19 < airlied> ideally I'd like to split X so that cardcontrol is a separate process to rendering and accel..
05:20 < darktama> airlied: I've had cases where X has segfaulted in the wrong place, and left the console ususable.
05:20 < darktama> though, that isn't likely to happen too often
05:20 < airlied> darktama: yes that happens a fair bit, but still you put a lot of code in the kernel to fix it...
05:21 < airlied> and the thing is you could probably get vbetool to fix it..
05:21 < marcheu> well, the advantage I see is that nvidia fb has to have it as well, so maybe sharing is a good idea
05:21 < airlied> the fb interface doesn't work for dual-head..
05:21 < airlied> or it works very badly..
05:22 < darktama> the fb driver could just clone
05:22 < marcheu> well actually, in its current state the fb driver is a cut and paste of a big chunk of X code
05:22 < marcheu> and a lot of it
05:22 < darktama> yup
05:23 < airlied> you also get a lot of ppl giving out if you made nvidiafb depend on drm as they like to complain..
05:24 < airlied> ideal world is to have a service that starts at boot, sets up the cards (including posting secondary heads), and waits for something to tell it set some modes..
05:24 < airlied> then when X server starts it asks the controller to set the mode..
05:24 < airlied> you try to make sure the mode service doesn't explode..
05:25 < airlied> the first missing piece if my gpu layer in the kernel..
05:25 < airlied> which I need to clean up for 2.6.20 and try and push in..
05:26 < airlied> the second is some sort of common memory manager so that when the X server asks for a different frontbuffer or something we can tell it where it is..
05:27 < darktama> what does the gpu layer involve?
05:27 < airlied> darktama: just a common layer that fb and drm drivers attach to..
05:28 < darktama> ah
05:28 < airlied> so they can kick each other on/off hardware and suspend/resume paths can be done properly..
05:28 < airlied> http://www.kernel.org/git/?p=linux/kernel/git/airlied/gpu-2.6.git;a=shortlog;h=gpu-branch
05:29 < airlied> it basically makes some virtual PCI devices really..
05:29 < marcheu> what's the advantage of that approach over making the nvidiafb a drm client ?
05:30 < airlied> marcheu: politics..
05:30 < marcheu> ah, that's what I feared
05:30 < airlied> try submitting a patch to the kernel that links an fb driver to the DRM..
05:30 < airlied> you get all these "embedded" hackers giving out.. 
05:31 < marcheu> well, I think we will ignore fb anyway
05:31 < marcheu> as long as it stomps all over the card there's not much we can do
05:31 < airlied> marcheu: I generally do unless I'm being paid for it, intelfb being due to money..
05:32 < marcheu> but I fear that you'll get the same issues with embedded people when adding that gpu layer
05:33 < airlied> marcheu: ah I've got enough power now :-)
05:33 < marcheu> well technically the issues are the same, maybe you only learnt to ignore complaints :)
05:34 < airlied> marcheu: no you can still build a kernel without the drm layer and have fb working..
05:34 < marcheu> also, do you think the drm mem manager will get bsd support at some point ?
05:34 < marcheu> ah ok you're only virtualizing the devices ?
05:34 < airlied> marcheu: it better get it ... but I generally ignore BSD as well.
05:35 < airlied> marcheu: yup initially, I'll also provide ways for the drm to know the fb driver is loaded etc..
05:35 < airlied> and also maybe a hook for the drm to kick the fb driver off the hardware if needs be,..
05:43 -!- cetrox [i=cetrox@129-169-223-201.adsl.terra.cl] has quit [Remote closed the connection]
05:43 -!- cetrox [i=cetrox@129-169-223-201.adsl.terra.cl] has joined #nouveau
06:19 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #nouveau
06:38 -!- jkolb [n=jkolb@c-24-128-85-102.hsd1.nh.comcast.net] has joined #nouveau
07:14 -!- johnnybuoy is now known as masked_stranger
07:16 -!- Quinn_Storm [n=quinn@pool-71-253-28-35.pitbpa.east.verizon.net] has joined #nouveau
07:18 -!- masked_stranger is now known as johnnybuoy
07:33 -!- mbiesz [n=mbiesz@camarillo-cuda1-24-55-84-236.ventca.adelphia.net] has joined #nouveau
08:01 -!- tibbs is now known as tibbs|h
08:01 < darktama> marcheu: I know you're asleep, but I just had a thought about why the driver didn't work without the PMC+pfifo_reinit()
08:03 < darktama> when ResetGraphics() is called on a mode switch, we reset the ddx's GET/PUT pointers back to the start of the FIFO because that's what the engine knows after the reset
08:03 < darktama> but, if we don't power down PFIFO, and don't call pfifo_reinit - the engine is still fetching from wherever it was fetching from *before* the modeswitch
08:18 < darktama> marcheu: ok, here's a hackish attempt at it: http://members.iinet.net.au/~darktama/nouveau_no_reinit.diff
08:18 < darktama> I can VT switch, and mode switch without problems with that
08:41 -!- johnnybuoy [n=void@nilus-268.adsl.datanet.hu] has quit ["Leaving"]
08:58 -!- predatorfreak [n=predator@adsl-75-46-41-247.dsl.sfldmi.sbcglobal.net] has quit ["<blank>"]
09:23 -!- Duke` [n=gnu@ANantes-251-1-144-127.w86-210.abo.wanadoo.fr] has joined #nouveau
10:30 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
10:42 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit ["Les choses que l'on possède, finissent par nous posséder"]
11:17 -!- Quinn_Storm [n=quinn@pool-71-253-28-35.pitbpa.east.verizon.net] has left #nouveau ["Konversation terminated!"]
11:17 -!- EdB [n=EdB@ARennes-251-1-46-55.w81-250.abo.wanadoo.fr] has joined #nouveau
11:50 -!- EdB [n=EdB@ARennes-251-1-46-55.w81-250.abo.wanadoo.fr] has quit [Remote closed the connection]
11:51 -!- EdB [n=EdB@ARennes-251-1-46-55.w81-250.abo.wanadoo.fr] has joined #nouveau
12:24 -!- Gusar [n=Gusar@e-87.vc-graz.ac.at] has joined #nouveau
14:14 < marcheu> darktama: hahaha good catch
14:25 < marcheu> hmm that memory manager will never be ported to BSD if they follow the current approach
14:25 < marcheu> s/current/discussed/
14:29 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
14:48 -!- EdB [n=EdB@ARennes-251-1-46-55.w81-250.abo.wanadoo.fr] has quit [Remote closed the connection]
14:49 -!- EdB [n=EdB@ARennes-251-1-46-55.w81-250.abo.wanadoo.fr] has joined #nouveau
14:53 -!- mbiesz [n=mbiesz@camarillo-cuda1-24-55-84-236.ventca.adelphia.net] has quit ["Leaving"]
15:20 -!- EdB [n=EdB@ARennes-251-1-46-55.w81-250.abo.wanadoo.fr] has quit ["Konversation terminated!"]
15:21 -!- EdB [n=EdB@ARennes-251-1-46-55.w81-250.abo.wanadoo.fr] has joined #nouveau
16:04 < glisse> marcheu, why BSD folks would do somethings similar ?
16:04 < glisse> s/would/wouldn't
16:50 -!- rem [i=rem@ALyon-252-1-20-35.w82-122.abo.wanadoo.fr] has joined #nouveau
16:50 < rem> hi
16:51 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has joined #nouveau
17:27 -!- ajmitch [n=ajmitch@ubuntu/member/ajmitch] has quit [Read error: 110 (Connection timed out)]
17:30 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has quit [Remote closed the connection]
17:42 -!- ajmitch [n=ajmitch@ubuntu/member/ajmitch] has joined #nouveau
18:08 -!- EdB [n=EdB@ARennes-251-1-46-55.w81-250.abo.wanadoo.fr] has quit ["Konversation terminated!"]
18:18 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #nouveau
18:18 < Duke`> "ATI has released the 8.29.6 version of its proprietary Linux drivers, with the announcement that the 9000, 9100, and 9200 IGP and Mobility Radeon chipsets are no longer supported by the new version. Radeon 8500, 9000, 9100, 9200, and 9250 devices are also dropped from support."
18:18 < Duke`> proprietary model powered \o/
18:19 < Duke`> the good news is that people with those cards will have to use the free driver and forget the binary-only crap forever \o/
18:21 -!- shenki [n=shenki@ppp131-170.lns3.adl2.internode.on.net] has joined #nouveau
18:25 -!- EdB [n=EdB@ARennes-251-1-46-55.w81-250.abo.wanadoo.fr] has joined #nouveau
18:27 < marcheu> glisse: because they don't have the same kernel interfaces for pages, I expect a port would be quite a lot of work
18:27 < marcheu> Duke`: r200 has been faster than fglrx for some time already :)
18:29 < Duke`> yep, it's a chance...
18:29 < marcheu> faster, and less buggy
18:29 < Duke`> it's still outrageous
18:29 < Duke`> (thaht they drop support for their own products)
18:30 -!- Gusar_ [n=Gusar@e-58.vc-graz.ac.at] has joined #nouveau
18:30 < marcheu> *cough* tnt/geforce/geforce 2 support 
18:31 < Duke`> :[
18:31 < Duke`> will there be a new driver for GLEXT_texture_from_pixmap ?
18:31 < Duke`> for these cards
18:32 < marcheu> I thought the redhat guys had a patch
18:33 -!- Gusar [n=Gusar@e-87.vc-graz.ac.at] has quit [Read error: 104 (Connection reset by peer)]
18:38 -!- marteus [n=marteus@0x50c475bf.albnxx8.adsl-dhcp.tele.dk] has joined #nouveau
18:38 < marcheu> darktama: ok, I can get mode switches to work here, but not VT switches
18:38 < marcheu> both with your patch and with a "clean" solution that removes the REINIT ioctl
18:39 -!- EdB|w [n=EdB@ARennes-251-1-46-55.w81-250.abo.wanadoo.fr] has joined #nouveau
18:41 -!- EdB|w [n=EdB@ARennes-251-1-46-55.w81-250.abo.wanadoo.fr] has quit [Client Quit]
19:24 -!- tezem [n=tezem@213.47.234.226] has joined #nouveau
19:34 -!- jkolb [n=jkolb@c-24-128-85-102.hsd1.nh.comcast.net] has quit ["Client exiting"]
19:38 -!- phh [n=phh@moi.phhusson.info] has joined #nouveau
19:40 -!- Gusar_ is now known as Gusar
19:43 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
19:57 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
19:57 -!- predatorfreak [n=predator@adsl-75-46-41-247.dsl.sfldmi.sbcglobal.net] has joined #nouveau
20:10 -!- jkolb [n=jkolb@c-24-128-85-102.hsd1.nh.comcast.net] has joined #nouveau
20:10 < marcheu> wohoo got it
20:10 < jkolb> sweet. i got the 2d driver working on my machine
20:11 < marcheu> good, you'll be able to update in a moment then :)
20:11 < marcheu> jkolb: no glitches in sight ?
20:12 < jkolb> marcheu: only when I switched to x from my vt. then i got a very brief screen corruption but it went away after half a second
20:13 < jkolb> all the snazzy e17 effects seem to be working fine
20:13 < marcheu> I just managed to remove the ugly REINIT ioctl
20:14 < phh> e17 is purely X11 so there won't be any problem with it ...
20:14 < phh> You can get more with KDE
20:14 < jkolb> phh: right but it's still a good sign
20:14 < marcheu> jkolb: you can even try xcompmgr -cC
20:14 < jkolb> hm no composite extension
20:15 < marcheu> so, you're using the wrong driver
20:15 < jkolb> ah i commented out the enable composite line
20:15 < marcheu> heh, that also
20:15 < jkolb> wrong driver?
20:15 < marcheu> no, right driver
20:16 < marcheu> composite should work fine (albeit some operations are sw fallbacks)
20:16 < phh> what means some ?
20:17 < marcheu> IN for example
20:17 < marcheu> and others that are not really used that often
20:17 < marcheu> UNDER..
20:18 < jkolb> marcheu: so I missed the conversation.... what's with the REINIT?
20:18 < marcheu> jkolb: I removed it
20:18 < marcheu> FIFO_REINIT
20:18 < marcheu> the ioctl
20:19 < jkolb> ah i see it
20:24 < jkolb> is it just the one line in nw_hw.c?
20:25 < marcheu> yes
20:25 < marcheu> well, there's more to do than just removing that line of course
20:27 < marcheu> hmm I get random crashes now
20:30 -!- jkolb [n=jkolb@c-24-128-85-102.hsd1.nh.comcast.net] has quit [Remote closed the connection]
20:35 -!- jkolb [n=jkolb@c-24-128-85-102.hsd1.ma.comcast.net] has joined #nouveau
20:35 < jkolb> composite works. it seems a little slow though
20:39 -!- jkolb [n=jkolb@c-24-128-85-102.hsd1.ma.comcast.net] has quit [Remote closed the connection]
20:40 -!- jkolb [n=jkolb@c-24-128-85-102.hsd1.nh.comcast.net] has joined #nouveau
20:41 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
20:44 < marcheu> darktama: ok, when we switch to text mode, since the fifo and the text mode data sit at the same place, well text mode chars overwrite parts of the fifo
20:54 < jkolb> how do we find out what all of these magic numbers are in the nv driver?
20:58 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
20:59 < marcheu> jkolb: heh, either through existing documentation, or through staring at the code for a long time with a fresh beer
20:59 < marcheu> 2nd method is prefered
21:06 -!- predatorfreak [n=predator@adsl-75-46-41-247.dsl.sfldmi.sbcglobal.net] has quit ["<blank>"]
21:08 < jkolb> yeah i think that's the only way
21:09 < marcheu> it is. but it gets easier with time, as more stuff is figured out
21:09 < marcheu> btw if you understand a non-obvious thing, even a comment describing it can be very useful
21:10 < marcheu> I think I did some commits that only add comments before :)
21:11 -!- predatorfreak [n=predator@adsl-75-46-41-247.dsl.sfldmi.sbcglobal.net] has joined #nouveau
21:30 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
21:42 -!- pmdata [i=patrice@ANantes-154-1-84-74.w81-48.abo.wanadoo.fr] has joined #nouveau
21:57 -!- __sha__ is now known as shaAway
22:00 -!- maydaytx [i=foobar@cpe-70-125-159-38.satx.res.rr.com] has joined #nouveau
22:14 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has joined #nouveau
22:15 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has quit ["Leaving"]
22:15 -!- tezem [n=tezem@213.47.234.226] has quit ["Kyle quit the band"]
22:25 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
22:28 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
22:31 -!- predatorfreak [n=predator@adsl-75-46-41-247.dsl.sfldmi.sbcglobal.net] has quit ["<blank>"]
22:32 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit [Remote closed the connection]
22:33 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #nouveau
22:42 -!- nael [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has joined #nouveau
22:48 -!- Myrizio [n=Myrizio@Linuz.sns.it] has joined #nouveau
22:55 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has quit ["Leaving"]
23:00 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #nouveau
23:05 < darktama> marcheu: oops, I didn't think of that problem :)
23:05 < marcheu> yeah, I'm not sure how we can solve it
23:06 < marcheu> I really would like to see the REINIT go away
23:06 < marcheu> that would help for the context switch work
23:06 < marcheu> well, we could place FB at the start
23:07 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has quit ["Leaving"]
23:07 < darktama> yeah, that seems acceptable.  I didn't see the issue because my FIFOs get put into AGP, and the FB gets VRAM+0x0
23:08 < marcheu> lucky boy :)
23:08 < marcheu> btw AGP is still broken here
23:08 < marcheu> X can't allocate it
23:08 < marcheu> anyway, context switches are more important
23:08 < darktama> it "magically" started working here again at some point, no idea why
23:09 < marcheu> ok, I'll see if I can allocate the FB first then
23:11 < marcheu> btw
23:11 < marcheu> we should tab-indent everything in the ddx as we touch it I think
23:11 < marcheu> it's mixed right now
23:12 < marcheu> and I can guess you use 4-space tabs :)
23:13 < darktama> hmm, good idea :) but, I can stick with 8 if that's what people usually use
23:14 < marcheu> no, we should indent everything with tabs instead
23:14 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #nouveau
23:15 < marcheu> it's just that running indent over the whole file will be an issue for our other trees
23:15 < darktama> that's what I meant, but I'd have vim set to use 8-chars for it - so things line up!
23:15 < darktama> space-indenting == yuck
23:19 < marcheu> why are setparam/getparam both WriteRead ?
23:19 < marcheu> and, why is drmCommandWriteRead not among the drm symlbols ?
23:19 < darktama> well.. no good reason really :S
23:19  * darktama hides
23:20 < darktama> btw, do you have anything against me adding the panel-range-hack.patch from fedora?  that is, if it gets me a native resolution on my c51
23:20 -!- phh [n=phh@moi.phhusson.info] has quit [Read error: 104 (Connection reset by peer)]
23:21 < marcheu> no, I've been contemplating doing that already
23:21 < marcheu> I just couldn't test
23:21 < darktama> I'm able to test that as soon as I figure out how to get it to build in ubuntu.. autotools is driving me mad
23:22 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
23:36 < marcheu> hmm also, it seems EXA is not protected against VT switches
23:39 < marcheu> i.e. if stuff is being drawn while a VT switch happens, you get a crash
23:39 < marcheu> we probably need to hook the same thing nv_video.c and some other places use
23:40 < darktama> hmm, what bit is that?
23:41 < marcheu> vtSema
23:42 < marcheu> I thought EXA was supposed to take care of that
23:42 < darktama> hmm, XAA doesn't seem to touch it.. yeah, I thought the same
23:43 < marcheu> well, I'll commit what I have now
23:44 < marcheu> but yeah, crashes happen within exa
23:45 < marcheu> I usually do ls -lR / and then ctrl-alt-f1 to trigger those
23:45 < marcheu> does that happen with the current git as well ?
23:46 -!- Duke` [n=gnu@ANantes-251-1-144-127.w86-210.abo.wanadoo.fr] has quit [Connection timed out]
23:47 -!- Duke` [n=gnu@ANantes-251-1-94-70.w86-203.abo.wanadoo.fr] has joined #nouveau
23:47 -!- Myrizio [n=Myrizio@Linuz.sns.it] has quit ["I like core dumps"]
23:50 < darktama> I cant trigger a lockup with current git, or with that patch I posted
23:55 -!- stringfellow [n=stringfe@a80-100-96-220.adsl.xs4all.nl] has joined #nouveau
--- Log closed Птн Сен 22 00:00:43 2006
