dancor: i'm trying to get 2560x1600 on second monitor (dell 3007WFP-HC) on radeon X1400. i can't get over 1280x800
dancor: ever when i use the "Supported additional Video Mode" modeline from Xorg.0.log, it says "mode clock too high"
dancor: i'm not sure what could be going on. is it something with the bios reporting the max clock wrong?
dancor: but then i thought that radeonhd could do arbitrary moeds (not bios constrained) anyway
dancor: i've tried a bunch of other modelines and playing with hsync/vrefresh even trying to set DacSpeed
dancor: is the next step to track down in the source where the MODE_CLOCK_HIGH is exactly coming from?
dancor: well if anyone sees this, i'll be checking back here periodcially as i continue to bumble around on my own
libv: dancor: yeah, sorry for that, we still haven't worked out all the mode validation details for that one yet
libv: dancor: we try to be very intelligent about what we do and do not allow, and in this case, it is working against us
libv: it does need an intelligent solution though
libv: dancor: can you send in a log to the mailinglist with -logverbose 7?
Rys: I could possibly try an X1400 with a 3007 this week, to help replicate/test
dmb: hows it going :D?
dmb: any tcore examples released yet?
Zhenech: do you mean what I think?
Zhenech: like accelerated 2d? :>
johnficc1: does this driver work with compiz ?
libv: Zhenech: yeah, somewhat :)
libv: some features require a bit more work, so there is room for improvement still
Zhenech: uhuh, sexy, but /me has to wait till monday to test
Zhenech: no r5xx here atm
johnficc1: I thought 3d was not there yet?
libv: but i'm going to do R680 first
libv: johnficc1: 3d is a big word
libv: johnficc1: we need the command processor for some things, and then we definitely need DMA up/down
johnficc1: is says on the wiki that 2d and 3d are not working yet
libv: johnficc1: i pushed this code seconds ago :p
libv: and it is r5xx only :)
johnficc1: what chip set is the ati mobility radeon x1400?
libv: johnficc1: m54 iirc, an r5xx
Ryszu: Ooh, what kind of acceleration, libv?
libv: Ryszu: XAA and EXA
Ryszu: Whee, that's great
libv: XAA will probably give you more bang per buck for normal use, and it is the default
Ryszu: I think it's about time I dropped an ATI card in here to try out the driver full-time, then
libv: anyway, i need to go spend an hour or so on the HD3870X2 support (R680, which is about adding IDs and such to Rv670)
Ryszu: Enjoy :)
libv: Ryszu: sndirsch has been running XAA for a few weeks now, but this was nastily hacked into the driver
johnficc1: so the x1400 should work with compiz then?
libv: johnficc1: i don't know, is compiz happy with EXA with slow up and download?
Ryszu: Not with radeonhd, johnficc1
libv: but then, pciexpress should be pretty decent bandwidth wise
johnficc1: has amd/ati release all of the info needed to get this driver working yet?
marcheu: libv: compiz can't run with exa
libv: marcheu: ah, right-o
snipex77: hey libv are you here ?
libv: snipex77: yes, but i am quite busy
marcheu: is the composite() hook coming up next ? :)
Ryszu: Hmm....what ATI board to choose to run
libv: snipex77: can you read the documentation of conntest, and then send a full runof all outputs to the mailinglist?
libv: marcheu: pushy, pushy!
marcheu: hmm, it's there ?
libv: you are pushy :p
marcheu: oh yes
snipex77: libv: you mean i should send rhd_conntest with -d and -s parameters ?
marcheu: I'll go back to playing with my nv30 video overlay
libv: snipex77: "can you read the documentation of conntest"
libv: snipex77: this reading business, it is important
libv: marcheu: :)
snipex77: libv: the problem is, i dont have any idea what PCI-tag is
libv: marcheu: this was no overlay, right, just shader work?
Tigerchen: libv: is there anything special to be done to use exa/xaa ? something to change in xorg.conf?
marcheu: libv: we've just discovered a nice table to plug in the filtering function in the hardware overlay on nv10->nv30... and we didn't set it up until now
snipex77: it says "PCI-tag : bus:dev.func
snipex77: whats that supposed to mean ?
marcheu: libv: yeah I'll also port the big shader thingie to nv30 after that
libv: marcheu: too bad that emmes is treading on kiwis atm, otherwise the pair of you could chatter away like washerwomen on this stuff again :p
libv: well, either killing kiwis or doing unspeakables to sheep :)
marcheu: he's in LCA ?
libv: no, the other island down under :)
marcheu: yeah but I was wondering, because it's close
marcheu: the other island being ?
libv: well, there are of course others... but that is the only plays where these endagered birds like :)
marcheu: yeah that's where I expected kiwis, I thought he's stop by at LCA :)
snipex77: libv : you could help me with rhd_conntest !
libv: place even
marcheu: libv: lazy git, help this dude !
libv: snipex77: you haven't even tried to read the README, have you
libv: marcheu: go and fix your overlays :p
libv: i have R680 ids to add :)
marcheu: if I show more pictures of bicubic movies you're going to cry
libv: Tigerchen: XAA is on per default on r5xx and rs6xx
snipex77: libv: ive read what it says when i run "rhd_conntest"
libv: Tigerchen: Option "AccelMethod" "shadowfb/exa/xaa/none" exists now
libv: Tigerchen: but i of course haven't documented it yet
libv: marcheu: yes, i am lazy :p
snipex77: libv : what readme ???
Tigerchen: libv: ok thanks, i'll modify my aorg.conf
libv: Tigerchen: xaa is on per default though, so no need to alter it if that is what you want
Tigerchen: no, i think i don't have to
libv: for r6xx, the default is of course still shadowfb
Ryszu: But we can try XAA?
Tigerchen: i don't know the difference actually but it would be nice to watch larger videos then youtube-size without -framedrop
snipex77: libv: where do i find rhd_conntest readme ???
libv: Ryszu: only on r5xx and related :)
snipex77: [boris@localhost ~]$ man rhd_conntest
snipex77: No manual entry for rhd_conntest
snipex77: [boris@localhost ~]$
libv: Tigerchen: i hope this helps there
libv: Tigerchen: no promises though :)
shosca: snipex77: its under utils/conntest
snipex77: ok, ty
libv: Tigerchen: but r680 and rv620/635 come first now
snipex77: libv : im a newb, you could have told me that, you know
libv: snipex77: "documentation of conntest"... "README" ... whatever...
Tigerchen: libv: sure, np with that
Tigerchen: libv: perhaps i will test randr again tomorrow, see if there are still whiteouts
libv: hrm... this one is for someone who oggles the logs and the ml all the time: michael: you're way fast :)
libv: Tigerchen: hrm... what hardware exactly?
Tigerchen: x1400 on a lenovo t60
libv: right, was this with the 1280x800 display?
dmb: Zhenech: yeh
libv: ah, ok
dmb: accelerated 2d
dmb: and the ability to watch videos
dmb: with r5xx
libv: dmb: does it really help?
dmb: is it possible?
libv: try it and find out
dmb: sorry, i'm talking about something different libv
libv: i haven't yet, i just know xaa and EXA look nice and solid
dmb: is 2d acceleration or xvideo working yet with radeon hd drivers for r5xx?
Tigerchen: hmm, xaa seems to be slower than shadowfb actually
libv: Tigerchen: right... one of the oldest things still in my inbox... still glaring at me
Tigerchen: libv: *g*
libv: Tigerchen: could very well be... shadowfb is good when you have a fast cpu and loads of bandwidth to spare
libv: it should become better when cp support is added (i hope to go through both drm and directly) and when we can dma
Tigerchen: I'll try a movie...
kdekorte: libv, want some benchmarks of git?
libv: sure :)
libv: but as said, there is tons of room for improvement :)
kdekorte: test machine is IBM t60p laptop
libv: no cp, no dma
kdekorte: right, I understand
kdekorte: video card is a M56GL (Mobility FireGL V5200)
kdekorte: compared radeon git vs radeonhd git...
libv: right, same card most of this code was initially tested on :)
kdekorte: and there is good and bad news.. bad news is probably due to lack of features
kdekorte: tested gtkperf -c 500 -a
libv: but it was more a question of getting the driver infrastructure into place
libv: the lowlevel calls are of course ported over from -radeon
Tigerchen: hmm, mplayer is still complaining that my sys is too slow *g* but it seems to work with much less "stuttering"
kdekorte: overall radeon is still faster, but radeonhd does beat it in XAA mode
kdekorte: in a few tests
kdekorte: which is great
libv: hrm, weird :)
kdekorte: that it even works at ll
libv: we shouldn't be able to beat it at all, we have no drm, so no command processor nor dma
libv: but this will come
kdekorte: radeonhd won in, gtkentry, spinbutton, progressbar, togglebutton textview- scroll (by alot) and Drawingarea - pixbufs
libv: Tigerchen: ok... it seems that RandR code seems to badly drive your panel?
kdekorte: so that is great!
Tigerchen: libv: not exactly
libv: kdekorte: ok...
libv: kdekorte: we write to io directly, no queueing or anything, only the hw fifo
kdekorte: I expected it to be slower because of all the stuff you said was missing, but congrats on the progress
Tigerchen: libv: query?
libv: Tigerchen: ?
Tigerchen: libv: can i explain in query in german, that's easier
libv: hrm, i am a native dutch speaker, and my german has barely progressed in the last 7months in .de, but do give it a try :)
Tigerchen: ok, well then i'll try in english
Tigerchen: thought you were german
Tigerchen: well. 1: startup without external display: works, can switch to console and back to x, no problem BUT can't get an external display to work
libv: hrm... startup being start up X or boot up the machine?
Tigerchen: 2: if i start x with external monitor i can (i think, no external here atm) drive the external with different resolutions and stuff
libv: i guess emmes already brought this up, but did you try to set a big enough virtual?
Tigerchen: but switching to console produces whiteouts and unplugging the eyternal and restarting x also
libv: hrm, that is bad.
libv: so we are not restoring something
libv: are you running vesafb or vga text mode?
Tigerchen: text mode only
libv: hrm... i can only go and try to reproduce this tomorrow, when i drag the m56 machine back over here, it was my xaa test machine at home for a while, and it still sits on my coffee table.
libv: let's hope it reproduces with 1680x1050 as well :)
Tigerchen: no problem, i don't need an external atm, but i think it would be nice if this was fixed sometime in the future
libv: because then it should be easy to test
libv: and then to fix
libv: right, your lcd being driven badly is not something that should be kept
Tigerchen: libv: i can give you ssh-access to the laptop tomorrow if you need
libv: let me first try to reproduce it here
Tigerchen: (btw: glxgears runs with 1200fps shadowfb vs. 1000fps with xaa (all tests on nearly idle machine))
Tigerchen: some minutes out with the dog
kdekorte: libv, I think the lack of queuing could cause problems with my wireless card. When I tried to connect to the net wirelessly when running radeonhd, it would not connect and the screen would stutter
rbmorse: libv: FYI. loaded 7e9b6ef0. R580+ Nothing blew up. No smoke. What worked before still works.
libv: kdekorte: right, we are stressing io quite heavily here
libv: rbmorse: :)
libv: is this x86 or ppc?
libv: because ppc i couldn't test
libv: kdekorte: r680, and then rv620/635 take precedence, but after that i shall work on improving matters in that respect
rbmorse: libv: I'm on X-86 Ubuntu 7.10
libv: ok :)
kdekorte: libv, no worries... I know that this stuff takes time, I'd rather it be right
Tigerchen: libv: ok back, any questions? else i would join my girlfriend in bed ^^
Uchi|Work: interesting fact that we all need to know hm yes. ^^
Tigerchen: Uchi|Work: not the way you are thinking, just sleeping....
Tigerchen: <-- off
mstrobert: Hello. I need to purchase 6 video cards for work. They need to be able to drive dual LCDs at 1680x1050 running Compiz on Ubuntu, and I want them to Just Work with the new unencumbered radeonhd driver sometime in 2008. My question is: Should I buy an R500 or R600 series card, or will they both work equally well? Right now I'm considering buying the Radeon X1650PRO if the R500 series will work equally well. Comments? Recommendations? Direction? I'
mstrobert: m not concerned with R600 possibly never supporting hardware video decoding.
graham: Hello. Been using the radeonhd driver a few months very happily, but since no Xv, would like to set resolution to 960x600 for DVD playback (monitor does 1920x1200)
graham: Have tried adding modeline to xorg.conf, nothing seems to work, or even add anything to Xorg.0.log
graham: Have tried using xrandr --newmode, and --addmode
graham: Sadly xrandr --addmode gives an "X Error...", even with the latest git xrandr
mo0n_sniper: is ati radeon xpress mobility x1150 supprted by radeonhd?
graham: Am using Ubuntu 7.10
graham: Any ideas?
graham: Not according to my Xorg.0.log mo0n_sniper
libv: mo0n_sniper: yes
graham: ah, good (sorry for small moment of negativity)
mo0n_sniper: it is an igp and i've heard that it won't be supported
mo0n_sniper: somenting about rs400
libv: graham: try Option NoRandR
graham: Will do...
libv: graham: and provide "960x600" in the modes directive
graham: OK thanks
libv: in your display subsection of your screen section
libv: if this fails, then there is something that is refusing to accept this mode
libv: if the driver accepts it, then it is more of an randr issue
graham: will rejoin after trying this...
mo0n_sniper: @libv what chipset is my card based on?
libv: mo0n_sniper: intel or amd cpu?
mo0n_sniper: but it's not a verry new card
mo0n_sniper: how can it be r600?
libv: how old is it?
mo0n_sniper: 2 years
mo0n_sniper: 1-2 years
libv: then it indeed cannot be an rs6xx
libv: check the output of lspci
Ryszu: X1150 is RS480
libv: Ryszu: urgh, yes
libv: read 1250
mo0n_sniper: ATI Technologies Inc RS480 Host Bridge (rev 10)...........
mo0n_sniper: so it's not supported?
mo0n_sniper: that's bad
Ryszu: The latest fglrx + RS480 = pretty bad
mo0n_sniper: anything + rs480 = pretty bad
graham: Tried that libv, did not work, did a git-pull and rebuilt radeonhd driver, still no result.
libv: graham: so this mode is refused with NoRandR?
graham: There is no mention of 960x600 in the Xorg.0.log file either, which I thought was odd
mo0n_sniper: fglrx is the only hope for me then..:(
graham: Once X is up, how should I get this mode activated? It comes up in 1920x1200
libv: graham: can you send in a log of a run with the stuff i stated before?
libv: can you run Xorg -logverbose with that, and then mail the log to radeonhd@
libv: please also explain your issue, because by the time i read it might not be up to speed any more
dmb: what exactly is xaa support?
libv: dmb: 2d hw acceleration
graham: Will do that, thanks. (Got to go look after baby now...)
dmb: libv: for r5xx?
dmb: ah, yes
dmb: libv: does that work with xvideo?
libv: dmb: this is not xvideo support no
libv: dmb: it is up to the xvideo client to work around this
dmb: libv: how did you do 2d acceleration when the docs/examples arn't available yet?
libv: dmb: while it might slightly improve matters, it does not provide you with the hardware video overlay support you want
libv: dmb: i ported -radeon code
dmb: i was told ati was going to release some 3d stuff in the future
libv: hence it only being r5xx support
libv: in future, yes
libv: no eta yet
dmb: libv: does that mean dri works?
dmb: (sorry, i'm not very good with this stuff)
libv: dmb: no, dri doesn't work yet for r5xx
libv: that requires a lot more -radeon archeology
dmb: i'v just got to the point where i am desperately seeking an alternate to the ati binary drivers, which are not working well for me
dmb: it goes into DPMI sleep, where the monitor turns off, but never comes back on
libv: dmb: right, this is what we are poised to become
libv: but we cannot go from nothing to full speed instantly
libv: these things need to be dug out and written
dmb: doesn't even care about speed, just stability
libv: right, this is radeonhds number one priority
dmb: thinks he will do a clone
dmb: is it git.freedesktop.org?
libv: dmb: all the necessary information is on the wiki page which is in the /topic
kdekorte: dmb, radeonhd with shadowfb or radeon seem to be resonably stable.. although acceleration is limited and no 3d or xv
kdekorte: dmb, I have not used the fglrx drivers for a couple of months now and I'm quite happy
soc: congrats to exa/xaa support!
libv: thanks :)
libv: i seem to have messed up virtual selection though :)
libv: people are falling into an endless loop it seems
libv: but i'm going home now, will be back as libvde in 20 or so
soc: guess i'll get some sleep too
dmb: libv: after you commit (or at least i think its your commit) some really weird stuff is going on
dmb: like everything is blurry and double
dmb: and there is lines
dmb: that move
dmb: it might be that i'm using an older xorg version
dmb: using 7.2 from ubuntu gutsy
libvde: dmb: hrm
libvde: dmb: the xorg version has nothing to do with it
libvde: dmb: about blurry and double, what does your cursor look like?
dmb: libvde: well, its double, kind of like shadowed
dmb: the screen is all pretty much corrupted
soc: sounds like maybe modesetting?
soc: when even the hw cursor is affected ...
dmb: well, its more then the cursor though
libvde: dmb: even the hw cursor? well well
libvde: what hardware is this?
dmb: when i run the X command by itself, there are horizontal blinking/moving lines
dmb: one sec
dmb: mobility X1400
libvde: ok... hrm
libvde: can you disable acceleration?
dmb: hw acceleration?
libvde: Option "AccelMethod" "None"
dmb: how exactly do I do that?
dmb: libvde: oh, maybe i should reboot first because i was using fglrx previously
dmb: still does it with accelmethod none
libvde: dmb: ah, of course
libvde: dmb: this is quite likely the cause
dmb: dmb = dumb :D
soc: no way to clean the fglrx remainings until now?
libvde: well; what if we do manage to fix things for some people... what will fglrx throw at us next?
soc: ok, understood your hint :-)
soc: stupid A*I ...
libvde: well, it would be nice if we could make some things go away
libvde: but we will never succeed completely
dmb: ahh, much better
libvde: dmb: :)
soc: received some useful docs again?
dmb: much larger improvement from the last time i tried it :D
libvde: soc: we should be moving ahead with rv620/35
soc: cool :-)
libvde: hopefully still manage DACs this week, not sure whether the digital blocks will be this week or next
soc: anything more useful than the usual card-stuff?
libvde: card-stuff is important :)
soc: anything hardware-accelerated?
libvde: we need to get this hardware up and running asap
soc: which models are they?
libvde: so that people can at least reliably run a driver on it :)
libvde: HD34xx and HD36xx
soc: any comments about crossfire?
soc: ah ok
soc: brandnew so to speak
libvde: we have no idea about crossfire
libvde: announced last wednesday
soc: mh ...
soc: hd3870x3 or what it was called
dmb: thinks he will stick with this so he doesn't have to worry about his display crashing
libvde: crossfire is for after 3D support, and i would think after power management
soc: do you think crossfire is a kernel/xorg-limitation?
soc: or ati being lazy?
libvde: i have no idea how crossfire works
libvde: i really have no idea
dmb: is there a way to tell if the accel is working?
soc: libvde: should i update rhd now?
libvde: dmb: well; sndirsch started complaining about seeing white flashes
soc: or should i wait if i want something remotely stable?
libvde: dmb: this is a memory bandwidth issue showing quite harshly :)
libvde: he didn't have that with shadowfb :)
libvde: dmb: but just check your log :)
soc: libvde: any additional config needed in xorg.conf if i update now?
dmb: (II) RADEONHD(0): Query for AtomBIOS Get Panel EDID: failed <-- is that bad?
dmb: grabs a bite to eat
gusta1: just fyi; I'm running debian sid, amd64 with radeonhd 1.1 and gnome... when starting open office and clicking its menu, X starts to eat 100% cpu and doesn't respond to anything (not even ctrl+alt+backspace). i.e. I need to ssh to the box and kill -9 Xorg.
gusta1: have no idea if this is "your fault" or anything else, it's just free information
soc: good night ...
gusta1: also, my cursor gets fcked up sometimes (very seldom tho).
libvde: gusta1: hrm
libvde: gusta1: does this happen with or without acceleration?
libvde: dmb: no, not necessarily
libvde: dmb: the driver should manage without that
gusta1: i'll check my xorg.conf
gusta1: In the Device section, I have no important options (only monitor namings and RROutputOrder)
libvde: gusta1: since when are you seeing these issues?
gusta1: the cursor has sometimes been messed up when I movie it between my two monitors, even back when I used fglrx, but also with radeonhd
libvde: and the 100% cpu issue?
gusta1: but usually it can be fixed by moving it back and forth between the monitors a couple dozen times. but today, the cursor got messed up in a different way and it would go back. don't care much, but anyway
gusta1: the cpu issue, since a couple weeks maybe. I almost never use open office, and that's the only app for when it happens.
libvde: so it is not something introduced with the acceleration changes pushed today
gusta1: sorry for interrupting that discussion(s)
gusta1: congrats tho
libvde: it happens each time you use openoffice?
gusta1: all three or four times yes. I just need to click the menu, and before I see the menu appearing X goes crazy
libvde: when it does; can you gdb attach to it?
gusta1: oh, and another thing. when that happens, my terminal gets fcked. ctrl+alt+f1 lets me see like a screenshot of an old X. I need to reboot to see the terminal
gusta1: oh, hmm.. I was afraid you'd say that. but ok, I will next time ;)
libvde: are you certain that this is the radeonhd driver you are talking about :)
gusta1: have a lot of windows open and important stuff, but tomorrow night I'll debug it to see where the hog is
gusta1: i mean, yes I use radeonhd, but I don't know what's causing it
gusta1: could be OOo, gnome, debian, X, etc
libvde: right, this is what i am thinking too, it seems like something not directly caused by our driver
libvde: but gdb will help, if it is a tight loop it should get you right on the money
gusta1: exactly... I have had issues debugging x before, debian seems to lack a lot of debug packages for X, so I don't see lots of the source code, but I'll try that tomorrow anyhow.
gusta1: so never mind until then, and continue to focus on exa/xaa ;)
libvde: there should be a package with debuginfo
gusta1: for radeonhd, there is, but for lots of the x packages there aren't it seems... or, there are, but ddd/gdb doesn't see them. dunno.
gusta1: perhaps the debug symbols are stored in the wrong place... that's the fun with using debian sid, anything can happen. the sky is the limit!
libvde: suse has that too... it's called stable :)
gusta1: isn't that more or less your employer you're talking about? :P
libvde: it's something that grew historically, and people just haven't bothered with renaming it :)
libvde: stable is actually what edbians unstable is
libvde: gusta1: i wear a debian tshirt to work :)
gusta1: haha that's rude
gusta1: but i agree if I read you right; debian unstable is freaking stable ususally
libvde: nah, i point to it all the time when i need to install a package :)
libvde: and then my colleagues all throw various remarks at me
gusta1: well, as long as you don't wear microsoft t-shirts I think you're safe
gusta1: I have one, and when people see me in it, they look another way
gusta1: goes to bed
slackern: libv there?
slackern: saw discussion on ml about problems with no working XAA and EXA, and i seem to have the same thing but it was a couple of hours ago the message was posted so i might be here too late :)
slackern: will check in tomorrow instead
dmb: yay, no crashes so far
dmb: working very well :D
dmb: ati binary driver would have crashed by now, requiring a hard reboot