spstarr: airlied: i had a lockup
spstarr: non-kms + EXA comp w/ AGP 4x.. solid lockup
spstarr: rare..
ossman: http://git.infradead.org/users/drzeus/xf86-video-ati?a=shortlog;h=refs/heads/vsync
ossman: agd5f, everything fixed up and ready to go
agd5f: ossman: works well for you? works great here.
ossman: works perfectly
ossman: did you test on r500 though?
agd5f: yup
ossman: great
ossman: then I don't see anything holding this back
MostAwesomeDude: Sorry, I haven't been around much. What's in this?
agd5f: MostAwesomeDude: ossman finished my vsync code and got it working
agd5f: and finished fixed the r3xx bicubic stuff
MostAwesomeDude: Oh, cool.
MostAwesomeDude: I should get back into the loop. Only one more week...
ossman: now if someone could just fix it so that I can use my R600. the rs690 is too damn slow ;)
agd5f: ossman: coming soon :)
ossman: is it the same display controller on that, just a new 3d engine?
ossman: I'm wondering how much of the last few days of work needs to be redone :)
MostAwesomeDude: ossman: Basically, just recompile the shader for R600. That's it, I think.
MostAwesomeDude: Everything else is already done or being worked on.
agd5f: ossman: same display controller
agd5f: I've got most of EXA/Xv implemented alrady
ossman: so I'll have vsync goodness from day one then :)
ossman: is the next version of the driver due with the next X release? or will there be one before that?
ossman: or should I just poke airlied with something pointy until these patches show up in fedora? :)
airlied: I think we might try and get 6.9.1 out soon, we have lots of nice stuff now.
airlied: I should get the hotness into F10 then.
rbrett: spstarr: hows f10 and rv350 working for you? I think I'm getting character corruption.
nille_: airlied i have problem with screen not turning of when i close the lid on my laptop
nille_: is this an known issue
nille_: it works on 6.8.0 but not 6.9.0
nille_: i use the ati driver
agd5f: ossman: merged!
ossman: weee
ossman: I've asked this question before, but didnt' get an answer, so I'll try again :)
ossman: is there some way of profiling the gpu?
ossman: e.g. see how much stuff is in the fifo currently
ossman: top doesn't show me gpu load ;)
agd5f: ossman: there are ways
agd5f: lots of status regs and perf counters
ossman: I'm having jerky video sometimes. I'd like to determine why
agd5f: you can also write to scratch regs at various points in the command stream and poll them to see when they come up
ossman: that's an idea
ossman: the ideal would be to be able to time how long things take
ossman: but polling card regs, no risk of that slowing the card down in a substantial manner?
agd5f: the scratch regs can be shadowed in memory
ossman: agd5f, updated by the card at some interval?
agd5f: yeah
ossman: also, this is an integrated card, which I guess muddies things a bit
agd5f: ossman: take a look at the drm writeback test
ossman: in the drm tree I assume?
agd5f: yeah, radeon_cp.c
glisse: btw does anyone did run benchmark with vsync stuff enabled ? to see if it's slow done or not
glisse: well i expect it to slown down, so it's more about how much does it slows down
airlied: glisse: thats why we kept if off for EXA just in case
airlied: I think people using Xv would rather not tear.
airlied: but we should benchmark
glisse: yup benchmark would be nice
glisse: i am especialy interested in char renderin
glisse: but i guess i can do somebenchmark on my own once i find time
fpoibaf: Hi, I just tried latest Xv tear free -ati, but I get a screen corruption: https://bugs.freedesktop.org/show_bug.cgi?id=18542#c39
ossman: fpoibaf, that one was a bit odd
ossman: could you do a screen shot of the entire screen?
ossman: and elaborate on how you produce this
fpoibaf: I just noticed that in full screen the image is fine
ossman: there seems to be some scissoring problem
fpoibaf: to get the corruption just start vlc with any file
ossman: as it does render the video as a triangle, but you're not supposed to see that :)
ossman: have you tried some other player?
ossman: and what hw?
fpoibaf: I have a RV530 on a MacBook Pro. Also tried with mplayer, where I get a different type of corruption.
ossman: could you make screen shots of the entire desktop with both apps please
fpoibaf: with vlc: http://img126.imageshack.us/img126/1809/schermataet8.png
ossman: the noise up over the title bar is also part of the video?
fpoibaf: with mplayer: http://img154.imageshack.us/img154/3315/schermata1qq2.png
fpoibaf: I get the noise in various place on the screen when the video is playing (e.g. the gnome application menu)
ossman: ok
ossman: does the problem go away if you turn off compiz?
fpoibaf: OK. Disabling compiz make the problem disappear
ossman: great. so we need to do something differently when we're rendering offscreen
ossman: I'm at work right now, so I can't really look at it until tonight or tomorrow
ossman: but perhaps you can poke one of the regular devs when they wake up
fpoibaf: OK. I added these info on the fdo bug, since I will be away for some days in 2 hours.
ossman: fpoibaf, ok. hopefully I'll be able to reproduce it on r300. otherwise I'll poke airlied and agd5f with some testing
agd5f: glisse: yes, it does slow down rendering
agd5f: aa10text for example goes from 800000 chars/sec to 250000 chars/sec when you enable it
agd5f: for exa
quicksilver: I've never seen tearing using Xv on a radeon 9250
quicksilver: (which I do a lot, because it's my main TV)
ossman: but that generation uses overlay
agd5f: quicksilver: if you are uing the overlay you won't see it
ossman: agd5f, don't you ever sleep? :)
quicksilver: that's very interesting, why's that?
agd5f: ossman: I slept :)
ossman: you've barely had time to make a dent in the pillow
agd5f: quicksilver: the overlay can pageflip asynchonously from the crtc
quicksilver: clever.
ossman: agd5f, did you see fpoibaf's comments above?
agd5f: ossman: yeah
quicksilver: agd5f: thanks. Interesting stuff.
quicksilver: video cards are always more complicated than I expect.
ossman: I assume scissoring and 3d coords work differently off screen
ossman: which is not that surprising
agd5f: ossman: should work the same. a surface is a surface
ossman: no special treatment of the framebuffer?
ossman: if you have the time, could you see if you can reproduce it?
agd5f: yeah, I can reproduce it
ossman: good. does it need compiz or is xcompmgr sufficient?
agd5f: xcompmgr works fine
ossman: bummer... that makes testing for me a bit of a pain
glisse: agd5f: i exepect that things get even slower if you have a video running while benchmarking
glisse: of course compared to no sync with same video running
agd5f: yeah
agd5f: GL will slow down as well
otaylor: agd5f: so, does this all become a no-op if you have a decent compositor running?
agd5f: otaylor: we only stall if the dst is the front buffer
otaylor: (by decent, I mean, one that is handling vblank sync itself)
agd5f: otaylor: yeah, we can disable it when we do it "right" whatever taht ends up being
otaylor: agd5f: how does it interact with an AIGLX client doing SwapBuffers?
agd5f: otaylor: haven't tried that yet
otaylor: OK, well, as long as it doesn
otaylor: 't cause a hlaf-frame-rate or something :-)_
otaylor: (My basic feeling on this is that if you aren't running composited, there's too much excess drawing noise going on anyways to make tearing obvious, so why risk a pretty major change and performance regressions; on the other hand it's a neat hack...)
agd5f: otaylor: it's off by default
agd5f: except for Xv
peterz: agd5f: ping
agd5f: peterz: pong
peterz: +++ b/src/radeon_output.c
peterz: @@ -1175,7 +1175,7 @@ radeon_create_resources(xf86OutputPtr output)
peterz: }
peterz: }
peterz: - if (OUTPUT_IS_DVI || (radeon_output->type == OUTPUT_HDMI)) {
peterz: + if (IS_DCE3_VARIANT && (OUTPUT_IS_DVI || (radeon_output->type == OUTPUT_HDMI))) {
peterz: coherent_mode_atom = MAKE_ATOM("coherent_mode");
peterz: agd5f: that brings back one head
peterz: no clue on the second yet
agd5f: peterz: your connectors are DVI correct?
peterz: agd5f: yes, two 24" dell with dvi on a hd2600
agd5f: then that code should already be getting executed
peterz: I'm not claiming to understand any of it - I bisected it to a5c5ce96279d01eb519bfb92b94c06a58acb7f07
peterz: and this bit made the primary head come back
peterz: I poked a lot at atombios_output_digital_setup, because the old code used LVDS_ENCODER_CONTROL_PS_ALLOCATION for everything, whereas thenew code uses _V2
peterz: bit non of that helped any
peterz: s/bit//
agd5f: peterz: what card again?
peterz: 01:00.0 VGA compatible controller: ATI Technologies Inc RV630 [Radeon HD 2600 Series]
agd5f: ah, ok, looks like your monitors do not need coherent mode then
peterz: I'd say, have an active dislike of ;-)
peterz: ah, clone mode works btw
peterz: just not the useful, side-by-side, mode
agd5f: or you need coherent mode rather
dmb: what exactly is video tearing anyway?
peterz: dmb: you seeing half of the old image and half of the new one
peterz: due to lack of vsync
peterz: agd5f: any clues as to where to poke to get my second head behaving?
dmb: :/ i'v never seen that before
MrCooper: airlied: so I didn't give any input on the tearing avoidance stuff? ;)
spstarr_work: rbrett: non-kms its stable, although i had a lockup with X yesterday
spstarr_work: 6.9.1 eh? aren't all the changes in Fedora effectively '6.9.0' + 6.9.1 patches ?
agd5f: MrCooper: still can :)
agd5f: scissoring is busted on offscreen rendering
spstarr_work: agd5f: i wonder if the corruption i've been seeing is tearing
MrCooper: agd5f: I thought I did...
agd5f: MrCooper: sorry, I misunderstood
MrCooper: anyway, afk for a bit, bbl
agd5f: changing back to quads fixes composite, so something is up with the scissors
orkid: the newly announced xv acceleration stuff, will it work for r600/700? (eg. rv770), or not yet b/c there is no accel for r6/7 (see topic)
spstarr_work: That's just for video though :-)
orkid: (the tear-free xv accel)
Trou: the blog post says "no r600"
orkid: spstarr_work: u mean there is no 3d accel for r6/r7, but there is now (nearly) tear free xv for them?
orkid: Trou: what blog post
Trou: http://airlied.livejournal.com/63565.html
Trou: 'No we don't have any r600 support for Xv yet, stay tuned hopefully :)"
orkid: :( ok thanks for the link/info
orkid: i guress that include r7 as well
agd5f: ossman: switching back to quads fixes it and doesn't seem to tear diagonally, at least not for me
agd5f: http://www.botchco.com/alex/xorg/switch_back_to_quads.diff
ossman: agd5f, unfortunately that has already been tested and is insufficient
ossman: at least on rs690
ossman: the tearing is reduced, but not eliminated
ossman: no idea why it goes bonkers with compiz?
gentooer: so i'm looking to buy a r500 card to play around with KMS and do a little gaming, but need the card to be quiet. is radeon or radeonhd able to adjust fan speed?
agd5f: ossman: not off hand. I suppose we could switch between the tris and quads depending on where we are rendering, but that seems like a hack
ossman: indeed
ossman: have you tested any more compositors?
agd5f: also, with the tri it breaks even without a compmgr if you move it partially off the left side of the screen
agd5f: just xcompmgr
ossman: doesn't like negative coords I guess
agd5f: yeah, we should clip
ossman: yes
ossman: but you didn't find any way of provoking it with xcompmgr?
agd5f: it happens with xcompmgr too
agd5f: any compositor it seems
ossman: ok. you said it worked fine before, which confused me a bit :)
gentooer: so does anyone know if fanspeed adjustment is possible on r500?
gentooer: or if the card at least adjusts it based on temperature?
airlied: MrCooper: oops....
MrCooper: no worries, but you owe me a Guinness now ;)
nille_: i was goint to file an bug report and in bugzilla when i shall choose component: i wonder if i should choose Driver/Radeon? in xorg.conf i use driver ati
nille_: s/goint/going
airlied: yes.
ossman: agd5f, ok now I'm home. let's see if we can get this offscreen stuff working
agd5f: ossman: when I said xcompmgr works fine I meant that it works fine at reproducing the problem
agd5f: sorry about that :)
ossman: ah
ossman: you need to work on your communication skills ;)
arekm: wonders what's the status of switchable graphics activation (not actuall switching, just activating radeon one if bios set to support both), any ideas?
flo|linux: hi guys
adamk: Hey folks... (and airlied, specifically), flo|linux is getting a "drmMap of framebuffer failed" error on F10.
flo|linux: thx ^^
flo|linux: i just wanted to ask on my own ^^
airlied: flo|linux: what card? can you post xorg logfile.
flo|linux: and x reverts me to software rasterizing, and compiz (and i, too) doesn't like that
flo|linux: ati radeon mobile 9800
adamk: Oh, heh, I didn't think airlied would be around now :-)
flo|linux: home.arcor.de/michael.jung11/
flo|linux: any of these files is named xorg.blah.blubb, that's the logfile :D
owen_: adamk: does rebooting help?
flo|linux: nope
owen_: flo|linux: and what about without modesetting?
airlied: flo|linux: make sure you are on the latest kernel/-ati from updates testing.
airlied: updates even.
flo|linux: i boot without modesetting
flo|linux: from testing oO
adamk: owen_: I recommended that, because I had the same problem at one poiint, couldn't figure out what the problem was, but came back after a reboot and it was working.
flo|linux: uhm, when i do yum update, there's no radeon driver
adamk: owen_: But it didn't help him :-)
adamk: t
flo|linux: how can i get my radeon working with hw rendering again?
flo|linux: it's possible that a yum-update caused that problem
adamk: flo|linux: If i understand airlied , he wants you to make sure you are using the latest from the "Updates" repo. Is that enabled in your software sources?
flo|linux: uhm... i'm not familiar at all with yum's repos ...
adamk: Start up gpk-application and go to system --> software sources, and see if the "Fedora 10 - i386 - Updates" repo is enabled (or amd64, if that's what you're on).
flo|linux: all repos except the rawhides are activated
adamk: Well then I'm assuming you are using the latest version.
flo|linux: yep
adamk: Where's the Xorg log file again?
airlied: bbl, flo|linux file a bug on bugila.redhat.com
flo|linux: home.arcor.de/michael.jung11/
airlied: I get perms.
flo|linux: wtf
adamk_: flo|linux, There's no Xorg.0.log file there.
flo|linux: my bugzilla password is expired?
flo|linux: wtf oO?
flo|linux: forbidden oO
flo|linux: http://home.arcor.de/michael.jung11/Xorg.0.log.old
adamk_: Make sure you include that in your bug report, as well as the output of 'LIBGL_DEBUG=verbose glxinfo'
ossman: agd5f, I think I've found the problem
ossman: and I think I caused it :)
ossman: it renders the video based on the framebuffer position, not the position in the target pixmap
ossman: I probably broke it when I removed the box struct thingy
ossman: should be simple enough to fix. I'll have a patch in abit
flo|linux: er xD
flo|linux: how do i file a bug ^^
flo|linux: ok, i have it ^^
adamk_: Create an account, if you don't have one. Then "Enter a new bug report"
flo|linux: oh... that site is SLOW!
adamk_: Xorg as the product, and Driver/Radeon as the component.
flo|linux: can't choose xorg as product
flo|linux: only fedora/rethat etc
flo|linux: but xorg-x11-drv-radeonhd as component
adamk_: Oh, did he give you the fedora bugtracker URL? My computer crashed right after he said that :-)
flo|linux: yep, you gave
flo|linux: i'll do that tomorrow...
flo|linux: i have to go now
flo|linux: cya, and thx :D
flo|linux: cu tomorrow ^^
ossman: agd5f, maybe not. I did not change anything when it comes to coords
ossman: I wonder why quads work...
flo|linux: hi xD
flo|linux: what option should i use for the glxinfo output?
flo|linux:
adamk_: LIBGL_DEBUG=verbose glxinfo
flo|linux: kay, thx ^^
agd5f: ossman: I tried the GL scissors as well, but same behavior, works for front, not for offscreen
ossman: ?
ossman: please elaborate
agd5f: SC_CLIP_0_A/SC_CLIP_0_B
agd5f: same as the main scissors
ossman: I don't follow. doesn't scissors work at all for offscreen?
agd5f: ossman: they should
ossman: I've determined two problems so far:
flo|linux: huh?
flo|linux: what xorg version should i enter there?
ossman: 1. there is something wrong with the coords
flo|linux: Xorg -version says 1.x.y
ossman: 2. we can't do scissoring outside the clip box loop as we need to adjust it for each clip box
agd5f: ossman: good point
ossman: agd5f, are you familiar with the pixmap struct?
agd5f: yeah
ossman: needs to have some fields explained
ossman: screen_x and screen_y?
agd5f: ossman: not sure
ossman: heh
ossman: how about drawable?
agd5f: something composite related IIRC
ossman: yes, it's inside a #ifdef COMPOSITE
flo|linux: here the bug: http://bugs.freedesktop.org/show_bug.cgi?id=18904
flo|linux: cya
ossman: agd5f, I am confused...
ossman: shouldn't PutImage() be called with dst coords relative the drawable?
ossman: it gets called with the final coords on the framebuffer
agd5f: ossman: that might be an Xv thing
ossman: so how do I figure out pixmap relative coords?
ajax: if screen_[xy] are non-zero, it's because the pixmap is a redirected window.
ajax: and then they indicate where it is in the logical screen
ossman: ok
ossman: logical screen?
ajax: the thing you see.
ossman: but the pixmap is not part of some huge buffer, where the frontbuffer is one area, right?
ossman: I'm trying to understand why pixmaps have coords at all
ajax: it's a detail to make Composite work right, really.
ajax: normal client-created pixmaps don't exist in the screen coordinate system. the only reason composite pixmaps do is because X's drawing rules are weird.
ajax: what are you trying to do?
tlp: ajax: are you the ajax who knows Daniel Reed (naim)?
ossman: ajax, figure out why the rendering engine draws stuff with an offset
ossman: the exact same offset the window has when it's put back on the front buffer
ajax: tlp: well, he might know some other ajaxes. but yeah, i know him.
ossman: the way I see it, it should have no knowledge of where the pixmap ends up
ossman: everything should be relative the target pixmap. the framebuffer should not be a concern
ossman: but I may be naïve :)
ossman: ajax, so PutImage seems to get coords that have been adjusted for the drawable's position on screen. how do those coords relate to the coords of the offscreen pixmap?
ajax: if the PutImage origin is in screen space, and you want it in drawable space, subtract screen_[xy] from the origin.
nbaum: Hi. Anyone know if there is there a way to completely disable OpenGL _hardware_ acceleration for a particular program? On my hardware, r300 has a bug which renders Blender unusable, but it's usable (although very slow) with software-only GL.
ossman: ajax, so that means that screen_[xy] contains the "target" coords of the pixmap on the screen, right?
ossman: agd5f, airlied, do you have access to more complete docs on r300 3d than the public ones?
ajax: right. they're the offset from the top-left corner of the user's screen, to the top-left corner of where the compositor will draw the window.
ossman: ajax, I thought that the X server didn't really know much about what the compositor is up to. how does this work when the compositor doesn't have a simple 2d target?
ossman: e.g. compiz with the cube
ajax: grr, hard to explain this.
ajax: imagine the compositor isn't doing any funny transforms
ossman: IOW, I might regret asking :)
agd5f: ossman: yeah
ajax: actually the easiest thing to say is they're the translation from drawable space to screen space, and then just acknowledge that the compositor is free to paint something other than screen space.
ossman: agd5f, as we can clearly test, the hardware treats coords for quads and triangle lists very differently. could you see if you have some information about the difference?
ossman: ajax, so it's basically a convenient storage for the compositor to keep track of windows, but not something it has to use?
agd5f: it shouldn't, other then there being one less coordinate
ossman: agd5f, here it has an offset that is related to the target offset on the framebuffer
agd5f: ossman: before we switched to quads, we used triangle list with two triangles to render the rect and that worked
ossman: odd
ajax: ossman: well, the compositor doesn't _need_ to show you anything, right? but the X server is obligated to maintain at least enough pixels to generate the image of screen space.
ajax: so when the server draws stuff into those pixels on behalf of clients, it needs to know where those pixmaps are in screen space.
ossman: ajax, so it's more about keeping track of the X11 window model, than any kind of pixel buffer handling?
ossman: as for drawing, aren't all X11 operations of that nature relative a drawable? i.e. nothing is in absolute coords (unless you use the root window as the reference)
ajax: it's relative to whatever drawable you named to draw on. since X has subwindows, you're allowed to choose how you want to treat them, you can either have drawing clipped by inferior windows or not.
ajax: and, since composite lets you redirect drawing at any point in the window tree, drawing that includes inferiors might need to walk into the pixmap of one of your child windows...
ossman: but there is no connection between window coords and buffer memory positions?
ajax: uncomposited, there's a trivial mapping between window coordinates and address in memory.
ossman: yes, but in that case there is just the framebuffer
ajax: composited, there's a nasty disjoint mapping.
ajax: which isn't really useful to think about, i suppose.
ossman: I've just been thinking about pixmap as a chunk of memory. I didn't really consider the interactions with the window model
ajax: most of the time, that's very wise ;)
ossman: heh
ossman: I don't like not having the complete picture though
ajax: i'd like to get X to the point where drivers never have to know anything about the window model
ossman: that would be nice
ajax: and just draw where they're told
ajax: ... which is what Windows does, the lucky bastards
ossman: I don't think I'd call them lucky bastards considered the API:s in that world...
ossman: been there, done that, not going back
ossman: what is the reference point that exaGetPixmapOffset() gives you an offset against?
spstarr_work: airlied: i dont think you have any AGP stuff pushed to koji from last night for me to test?
ajax: start of video memory
spstarr_work: otherwise til Sunday (your monday)
ossman: I'm trying to figure out what this computes: dst_offset = exaGetPixmapOffset(pPixmap) + info->fbLocation + pScrn->fbOffset;
ossman: I don't see how the framebuffer gets into the picture for an arbitrary pixmap though
ajax: "the framebuffer" is all of video memory
ajax: part of it is the front buffer, the thing you scan out on your screen
ajax: other parts of it are offscreen pixmaps, either client- or server-created
ossman: ah
ossman: I figured framebuffer and front buffer were the same thing
ajax: actually i should have said "scanout buffer", not "front buffer"
ossman: Pixmap->drawable.[xy] is the offset of the drawable inside the containing pixmap?
ajax: those are always zero for pixmaps.
ajax: for windows, they're the offset within the containing window.
ossman: RADEONDisplayTexturedVideo feels like it needs to adjust for it though
ajax: well sure, since you're only ever allowed to put video images to Windows, iirc.
ossman: agd5f, ehm.... ooookay?! this was a bit odd
ossman: I fixed up the scissoring so that it does it inside the while loop
ossman: and suddenly the coords start working
ossman: are there some conditions where the CP won't do things properly in the order specified in the FIFO?
ossman: 'cause the only difference now is that we set up scissoring after the wait, instead of before
ossman: hmm.. otoh, this is offscreen so we won't be waiting
ossman: gets more confused
agd5f: ossman: we need to reset the scissors for each sub-triangle for the cliprects
ossman: of course
ossman: but when there is no clipping, there should be no difference
agd5f: yeah, that is odd
ossman: but now it works, and before it didn't
agd5f: scissor regs might not be pipelined
ossman: agd5f, hang on... perhaps this does make sense
ossman: sketches
ajax: i thought we had multiple hardware cliprects
ajax: three? six? some weird number.
ajax: in that i remember infuriating bugs about GL performance going through the floor when using the shaped window theme in metacity and clipping your gears window with the top corners
ajax: because you run out of hardware clips and have to start iterating
agd5f: ajax: 4 GL clippers and 1 scissor set
ossman: agd5f, ok, all makes sense now :)
agd5f: ossman: do tell
ossman: since it is offscreen, we should render to coord 0,0
ossman: but the scissoring was set up based on screen coords, not relative the pixmap
ossman: now for the interesting part
ossman: since we had an offset for the scissoring, we had a width that exceeded the pitch of the pixmap
ossman: the result was that the engine started rendering stuff that logically was outside the pixmap, but because of the pitch it got rendered to memory that was inside the pixmap
ossman: hence we started seeing stuff that was supposed to be outside the window
ossman: I'll update my tree and you can merge the fix to master
agd5f: cool
ossman: http://git.infradead.org/users/drzeus/xf86-video-ati?a=shortlog;h=refs/heads/vsync
ossman: it's just one commit, so a pull is probably overkill
agd5f: just point me to the patch if you want
ossman: agd5f, http://git.infradead.org/users/drzeus/xf86-video-ati?a=commitdiff_plain;h=2c3c99c14129ea5c4039f55c5237452691c4d064
cb400f: hey. I'm looking into buying an x800 pro.. and I'm wondering what level of tv-out support I could expect. The info here http://www.x.org/wiki/radeonTV and here http://www.x.org/wiki/radeon on the subject seems a bit old and unclear
agd5f: cb400f: not supported at the moment
ossman: agd5f, the licensing issues from gantos never got sorted out?
cb400f: ok, thanks
agd5f: ossman: yeah, we support integrated tv-out on r1xx-r3xx
agd5f: r4xx changes some tv-out bits
agd5f: gpio related iirc
ossman: are there docs though? or is it macrovision silliness in the way?
agd5f: no one ever merged the theatre-out support though
agd5f: ossman: I haven't found any
agd5f: I figured it out from some code snippets and tracing the bios
ossman: k
ossman: it wasn't part of the work order when producing the rest of the docs? :)
agd5f: ossman: the open beos driver is pretty well documented and has a thorough tv-out implementation
ajax: agd5f: for transmitter clock select in atom, does XTALIN mean external genlock?
ossman: k
agd5f: xtal is core ref clock IIRC
agd5f: wait, nevermind
agd5f: er, yeah, it's the ref clk
cb400f: thinks he'll look for r3xx then
cb400f: since I'm here.. any big kde4 problems with the radeon driver that you know of?
agd5f: ossman: on r4xx and newer you can use atombios, just no one has had the time to sort it all out
ossman: k
ossman: agd5f, btw, you missed a .TP in you man page update
ossman: +r
agd5f: dave and I had it working to various degrees at one point, but never quite got it perfect
ossman: fortunately, analog TV is soooo last week :)
agd5f: yeah, so much setup for little
ossman: agd5f, better put that fix up on master before the angry masses start demanding my head for breaking their video support :)
agd5f: ossman: way ahead of you :)
ossman: has anyone ever observed that kondemand gets a lot of cpu usage attributed to it when the radeon driver has too much to do?
ossman: specifically when you've managed to fill the fifo
ossman: it's fairly easy to provoke with the vsync stuff turned on. at least on rs690
ossman: just move windows around rapidly
ossman: so if anyone has too little to do, looking at more graceful handling of a full fifo would be nice :)
marv: I recently upgrading my x.org on gentoo and now it's telling me MergeFB isn't supported, that I have to use RandR, but i can't use RandR because i have 3 monitors and 2 cards. What should i do? Is there a way to get xinerama to work?
arekm: weird reason for "can't use"
agd5f: marv: zaphod mode should work
marv: agd5f: thanks, although i've not heard of zaphod mode before now
agd5f: marv: it's teh old screen-based multi-head stuff
agd5f: like pre-mergedfb
arekm: could someone enlighten me why randr isn't able to deal with this?
marv: does it work like xinerama, or will they be independent displays?
agd5f: marv: you can enable xinerama if you want one big desktop
marv: would the two devices use the same pci id or would the second one use the second id?
arekm: hm, weird, I heard noise coming from inside of my thinkpad when scrolling screen in a browser or switching desktops
arekm: I didn't have that with older ati driver afaik (checking, right now using today git master)
Guest24294: agd5f, does the ati catalyst control panel enable xinerama when you tell it use one big desktop?
marv: actually looks like you said use the same pci id in a forum post
arekm: now at fa496d7b0397d9be57db90d0860928e9ced73cca and no noise
arekm: weird
arekm: one of december patches is noise maker
arekm: back to master to confirm
arekm: master and noise is back 8)
marv: hm, when i add Screen 0 and 1 to each device, and have them be the same bus id, i x fails to start, i get a backtrace
marv: although I'm using xf86-video-ati-6.8.0-r1 which i think should be new enough to support Zaphrod mode
arekm: airlied: any idea why fc079c5267baf431bbecee7744e484783d393152 could cause noises from a notebook when scrolling in a browser?
arekm: actually the noise is even before fc07... but this patch makes is much stronger
scsiraider: airlied: how far down on your list is adding eedid support to your kms tree
funda3: is there any difference between the xserver master/server-1.6-branch for exa?
scsiraider: does anyne which commits in master added eedid support
scsiraider: nm