rx__: most of the kms work is for intel hw
rx__: i guess glisse is doing the radeon equivalent
stefanb: Ahhh MostAwesomeDude isn't online...
stefanb: just tested video on my Mobility X1300 for him...
MostAwesomeDude: airlied: Congrats on Fedora 9?
stefan2: MostAwesomeDude: I tried video now. Freshrpms has released F9 packages, so I now have mplayer
stefan2: MostAwesomeDude: -vo xv: works OK, even with glxgear running
MostAwesomeDude: stefan2: Sweet.
stefan2: MostAwesomeDude: -vo gl: no output, busy looping?, -vo gl2: black window
MostAwesomeDude: So your only problem is the glxgears tri on the inside of glxgears.
stefan2: MostAwesomeDude: Yes.
MostAwesomeDude: Yeah, -vo gl doesn't work for reasons I don't fully understand.
MostAwesomeDude: -vo gl2 should work with the new FP code.
stefan2: MostAwesomeDude: FP?
MostAwesomeDude: stefan2: Programmable fragment shader program compiler.
MostAwesomeDude: We've agreed on FP because US (universal shader) is ambiguous.
MostAwesomeDude: It's the chip that determines the final color of pixels, and on r5xx it has to be programmed with ucode to work.
reppel: Hi, do you think it is possible to write a composite manager which does blit to screen using Xv?
stefan2: MostAwesomeDude: OK, I only get audio and a black video window. mplayer is not stuck though like with -vo gl
owen__: reppel: possible? or a good idea?
owen__: reppel: the first.. sure. The second ... definitely not.
stefan2: MostAwesomeDude: I get this output from Mesa with -vo gl2 (don't know if it helps you):
stefan2: # Fragment Program/Shader
stefan2: 0: TXP TEMP, INPUT, texture, 2D;
stefan2: 1: MUL OUTPUT, TEMP, INPUT;
stefan2: 2: END
reppel: owen__: could you explain me why it is a bad idea?
owen__: reppel: Well, you have to copy the data back into the compositing manager from the X server, do the compositing there in software, convert it into an Xv-compatible format, then push it back to the X server
owen__: reppel: or something like that.
owen__: reppel: maybe the more useful question is: why do you think it is a good idea?
MostAwesomeDude: stefan1: That's a fragment program. That particular one is the standard Mesa program for textures.
reppel: owen__: i have to better understand where and how compositing works to answer your last question :)
MostAwesomeDude: TXP is tex proj, MUL is multiply, and END is, well...
MostAwesomeDude: That one should work alright, but there's bugs elsewhere that prevent it from being perfect.
stefan1: MostAwesomeDude: Ok. But at least -vo xv seems to work fine
reppel: owen__: isn't xcompmgr doing the same except for the last step?
reppel: owen__: I mean, it doesn't use Xv to blit but plain x11
owen__: reppel: No. all the data stays in the server and is composited together with the render extension
owen__: reppel: so xcompmgr just says "draw the pixmap for window X with 50% opacity, and then the pixmap for window Y with 75% opacity" and the X server does it
reppel: owen__: ok so the actual mixing is done by the server driven with render
reppel: now i understand
owen__: reppel: Yes. Other cm's use GL and do the mixing with GL
owen__: reppel: there the "texture from pixmap" extension to GL also allows keeping the data on the server and not copying it around
reppel: wonderful, i didn't hope copying being avoided this much :)
owen__: The alternative ansswer to your question might be: Xv barely works as is, it's a bad idea to make it the fundamental output path :-)
reppel: owen__: do you know if there are plans to release a new xserver in the near future? I'm fighting with mesa and xserver. Basically, my IGP (x1250) is only supported by mesa in git, and it seems that mesa git _wants_ a git version of the server (and the server wants a git version of mesa). So i'm waiting to see xserver 1.5 and mesa 7.0.4 :)
owen__: reppel: I'm not expert, but, yes, 1.5 should be out soonish. The X server in Fedora 9 is 1.5 in all but name.
stefan2: MostAwesomeDude: Speaking of the devil: now kernel panic (blinking LED) when I resized the mplayer xv window
MostAwesomeDude: stefan2: !?!?
MostAwesomeDude: Never had that one happen to me.
reppel: owen__: thanks
stefan2: MostAwesomeDude: Let me try. First resize was OK, but second resize was when I tried to resize over another window
stefan2: MostAwesomeDude: Hmm, can't reproduce it
stefan2: MostAwesomeDude: BTW: do you need a screenshot from the glxgears triangle errors?
MostAwesomeDude: stefan2: Tell me if this is what you see: http://home.aweenet.net/~simpson/snapshot47.png
stefan1: MostAwesomeDude: Similiar. the large wrong triangle starts in the middle of the window in my case
stefan1: MostAwesomeDude: In your case it starts at the left edge of the window
MostAwesomeDude: Well, it turns with the gears.
stefan1: Yes, mine too. two corners are connected to the inside of the red gear. the last corner is connected to the middle of the window
stefan1: MostAwesomeDude: and the color changes between red and dark red/black. I guess that is caused by the lighting
stefan1: the lighting looks correct, i.e. when the triangle is on the top it is black
stefan1: OK, gotta run. CU
reppel: airlied: does F9 (or F10 devel) include your latest work on compiz on r690?
airlied: agd5f: the RS600 look more like an RS480 MC :)
agd5f: airlied: seem about equally wonky
airlied: agd5f: well the registers appears to be in a similiar place.
airlied: you're chipset teams need to like talk to each other ;-)
agd5f: airlied: the problem is the RS600 is intel NB and RS690 is AMD
airlied: agd5f: I do wonder is Intel RS4xx is different than AMD RS4XX
airlied: I only ever did work on AMD RS4xx
agd5f: airlied: probably. there are 3 different RS4xx variations
agd5f: actually 4
agd5f: airlied: looks like Intel RS4xx have different MC setup from AMD RS4xx, currently we only support AMD ones in the drm
airlied: agd5f: that explains lots of hangs that were reported ;-)
agd5f: the intel RS4xx's and the RS600's looks similar, but I haven't a clue as to how to the GART setup. they are REAL weird
agd5f: airlied: looks like RS480/2/5, RC410/5 are AMD based and should work with the current drm. RS400 is Intel and needs work
agd5f: so it looks like 5A41/5A42 look to be the intel ids
airlied: so we should rip those out if they exist..
airlied: I don't think I added them to the drm in any case.
agd5f: airlied: yeah they're in there
spstarr: airlied: ok let's see if i can track down this bug
spstarr: ugh, slow enough debuginfo mirror :/
spstarr: kinda doesn't help not having any symbols
spstarr: here we go let's crash it