Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

RadeonHD IRC Logs For 2008-11-27

Search This Log:

Nightwulf|work: hi all
ndim: leox_: Depends on what you need from it, and when you need it.
ndim: leox_: Older (R5xx, i.e. X1nnn series) cards if you need Xv or OpenGL right now.
leox_: ndim: tbanks! what model of ati have R5xx?
libv: leox_: anything that says 1xxx
libv: except 1100 i think, as that'S some f-ed up IGP version based on r300/r400
leox_: libv: ok, any HD with dvi for PCIe socket?
FuzzyTheBear: well .. im trying to use radeonhd, i seem to be missing information on how to properly configure xorf.conf for dual head on a sapphire x1650 pro . Is there a true , easy to understand , complete how to configuring for radeonhd ? devices are making me specially nervous cause of the naming convention
FuzzyTheBear: distro is gentoo
FuzzyTheBear: thanks for any help
libv: leox_: HD is usually r600 and up
leox_: libv: ok, how can I see if the card is r500/r600?
libv: HD is never used for an r500
libv: X1xxx except express 1100 should be ok
leox_: libv: but where can I see if a card is based on r500 or whatever?
libv: f.
libv: http://en.wikipedia.org/wiki/Radeon_R520
adamk: leox_, 'lspci | grep -i vga' will usually list the family...
adamk: For example: "01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R350 [Radeon 9800 Pro]"
libv: http://en.wikipedia.org/wiki/Comparison_of_ATI_Graphics_Processing_Units
libv: leox_: if that _still_ does not answer your question, talk to a psychic
FuzzyTheBear: libv : radeonhd is at least as far as readings around are concerned totally supported and the only one with 3d support atm ..
FuzzyTheBear: from phoronix and suse's sites at least
FuzzyTheBear: for the 500 series that is
FuzzyTheBear: and both of those sites lack any meaningfull instructions for the configuration , which is rather unnerving
leox_: libv: LOL, many thanks for the answer
FuzzyTheBear: seems like a psychic is the only way to configure x for it too :DDDD
FuzzyTheBear: good day :)
libv: FuzzyTheBear: option "DRI" "True"
libv: heh.
SR_: wheeeee
SR_: not sure why, but for some reason, after coming back from software suspend, using Xv-accelerated video causes my laptop to lock up hard
SR_: I get jumpy audio for a few seconds, no video
SR_: and my laptop does not respond to Alt+SysRq+B
yangman: SR_: do you see (EE) RADEONHD(0): DRMCPStart: stale buffer present!
yangman: in the log?
SR_: looks
SR_: no, but there are some messages about
libv: SR_: so we don't set up the CP properly after resume?
SR_: is not sure /which/ suspend-to-ram mechanism is being used, though
SR_: libv: it
yangman: libv: I'm seeing that in my .log.old haven't tested it thoroughly, but getting hard lockup after resume
SR_: 's not entirely clear to me what "DRMCPIdle: DRM CP IDLE returned BUSY!" should mean to me :P
SR_: it appears it's trying ususpend-ram
SR_: (then it would try "UseSysfsPowerState mem", not sure which one it actually uses)
yangman: SR_: that would be `echo mem > /sys/power/state`
yangman: SR_: standard kernel method unless you're running some of the other forked projects
SR_: yangman: is it likely to be my suspend-to-ram config, or the obligatory "try a different suspend-to-ram solution and see if that breaks less", or something to do with radeonhd?
yangman: SR_: are you looking at /var/log/pm-suspend.log?
SR_: (II) RADEONHD: version 1.2.3, built from dist of git branch master, commit 57aca005
SR_: ^version of radeonhd I have
SR_: looks
SR_: hibernate: Running /usr/sbin/s2ram -f -p -m...
SR_: from hibernate.log
SR_: running debian lenny, btw
libv: yangman: ah, right, didn't you open a bug on that one already?
SR_: there's a bunch of other lines in that log file, but they all appear to be informational, not error messages
yangman: libv: did I? the hibernate issue I've had before was resolved. the only other lockup one is general accel. this is new
libv: there is one lockup when reinitialising the 3d engine all the time
libv: that one i know of, and i know how to reproduce, although it is nontrivial to fix :)
libv: but the resume issue, if it isn't in the fd.o bugzilla, is new to me
SR_: (obviously, I should note that I've not restarted the X server after resuming, when this happens)
yangman: libv: I don't think it's in fd.o. I haven't been keeping up with master lately, so I don't know when it showed up. I'll try bisecting when I have time after the weekend
yangman: libv: well, actually, I'll know if it's a consistent problem when I get to work and resume my laptop today ;)
SR_: ah, so you're going to find out if it
libv: yangman: try looking around the 1.2.2 (before and after) and around 1.2.3 (before and after)
SR_: 's my fault or a glitch in the version I'm running?
yangman: libv: around 1.2.3 is fine. this is very recent. in the last 2 weeks or so
yangman: SR_: there was a suspend bug around the time 1.2.3 was released. it was fixed, but I don't remember if it was before or after the release
SR_: is using a Thinkpad T60, with Radeon Mobility X1400
yangman: SR_: same here, with a X1300 :)
yangman: anyways, I'll try and track this down, sometime soon
SR_: returns with 38 jumpers, since she was getting cold
libv: yangman: ok... hrm...
ndim: libv: BTW, why is "DRI" "true" not default on R5xx? Because it hangs with EXA?
libv: ndim: initially we weren't really sure whether it was solid enough, and there indeed are still issues that prohibit us from changing this
ndim: OK, makes sense. I just wanted to ask as sometimes things fall through the cracks.
libv: not really, i have a major bug open on the engine lockup
udovdh: hello
udovdh: anybody awake?
udovdh: I do have slightly offtopic question
udovdh: about xorg
udovdh: (radeonhd works fine)
udovdh: I upgraded to fedora 10
udovdh: and got
udovdh: "Reconfigure HAL" or "disable AllowEmptyInput" in xorg.log
udovdh: of course the allowemptyinput works
udovdh: but waht is the thing to do to hal to make keyboard and mouse work?
leox_: libv: RV530, RV534 and RV560 works?
udovdh: BTW: just did a git pull
udovdh: and now it doesn't compile:
udovdh: radeon_drm.h:718: warning: struct has no members
udovdh: make[3]: *** [radeonhd_drv_la-rhd_cs.lo] Error 1
udovdh: I did do the autogen etc
yangman: hm, ok, suspend bug is probably due to dbus/hal not starting properly during my last boot
yangman: I'll see if it happens again in the next few days
udovdh: hmm. fresh (total!) pull works better
udovdh: oh no, notat all
udovdh: same error
udovdh: anyone?
udovdh: http://rafb.net/p/N8p4v158.html
udovdh: compile error
yangman: radeon_drm.h:583: error: expected �:�, �,�, �;�, �}� or �__attribute__� before �*� token
yangman: er...
yangman: udovdh: is that rafb.net screwing up or do you get the same thing?
yangman: udovdh: oh, ISO-8859-1 instead of UTF-8. n/m :p
yangman: udovdh: works fine here. your gcc may be setup to be more pedandic about it. you should be able to just comment out line 583 and 584
udovdh: about my paste:
udovdh: I just went to fedora 10
udovdh: so gcc etc may be different
udovdh: and/or new
sytse: maybe you should remove -pedantic from CFLAGS?
sytse: btw, where would the definition of 'DEPRECATED' be? I only see an _X_DEPRECATED in Xfuncproto.h
sytse: oh, drm kernel headers
sytse: hmmm, wait, radeon_drm.h has no includees
sytse: this would seem to be a bug :-)
sytse: oh, drm.h defines it as __attribute__((deprecated)) if __GNUC__ is set, nm. Udovdh has left anyway
ndim: udovdh, sytse: Take a look at the RPM's spec file.
ndim: http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-drv-radeonhd/F-10/xorg-x11-drv-radeonhd.spec?revision=HEAD&view=markup
ndim: %{__make} %{?_smp_mflags} CPPFLAGS='-D__user="" -DDEPRECATED="__attribute__ ((deprecated))"'
stianj: it's my understanding that xv with radeonhd needs dri, since the hardware is missing an hardware scaler (or something). That does mean that it's impossible to get xvideo with my RV635, right?
stianj: before I waste more time on trying to fix it...
ndim: stianj: On R6xx, you need to wait for DRI to get ANY type of acceleration. That is depending on technical feasibility and IP release from AMD.
ndim: Some people have speculated about a christmas present IP release, but I would not bet on it.
stianj: oh, ok. So RV and R is the same in this manner?
udovdh: ndim, thanks. shouldn't git be adapted as well so it compiles?
udovdh: should I file a bug?
udovdh: I'll try again this afternoon (CET)
udovdh: ndim, adding the CPPFLAG line does not fix the issue in git