the-me: I'm using an HP Compaq 6715s notebook. all fine first. But my additional lower/upper brightness buttons on my notebook dont work with radeonhd. This wonders me, because they are working in the BIOS, too. I thought they are going completly about the hardware.
yangman: the-me: it's a known limitation of the driver. it should be mentioned in the FAQ section of the wiki page
the-me: yangman, this limitation isn't there.
yangman: "Panel brightness cannot be changed because ACPI events aren't handled properly. Workaround: Switch to a different virtual terminal for that. Affects backlight on a number of laptops, e.g. from the IBM/Lenovo ThinkPad series. "
yangman: under Known Bugs and Limitations
egbert: just pushed a fix for what CornedBee pointed out earlier.
udovdh: hello...
libv: TGEN: ok, i will, as soon as i get to it
aneas_: is there a way to get the contents of my gpu registers?
udovdh: Maybe through atombios?
ndim: Hmm... https://bugzilla.redhat.com/show_bug.cgi?id=435376
marcheu: if aneas comes back, tell him about radeontool :)
udovdh: will that fix the 162 > 160 Mhz?
marcheu: no, radeontool is "a way to get the contents of my gpu registers"
marcheu: hmm, you were refering to the previous link...
udovdh: https://bugzilla.redhat.com/show_bug.cgi?id=435489
udovdh: no progress on that other one: https://bugzilla.redhat.com/show_bug.cgi?id=434695
udovdh: nor the ones from gnome or xorg
libv: udovdh: go reduced?
udovdh: dunno, I am no expert
udovdh: BTW: is tha 160 Mhz clock really a common limit nowadays?
udovdh: s/tha/the/
udovdh: for dotclock that is
libv: udovdh: what resolution are you trying to work at?
udovdh: I am not; it is not my problem
libv: yeah, DVI only goes up to 165 for single link
udovdh: just thinking about the bugzilla post by ndim
udovdh: aha.
libv: udovdh: could this be a samsung monitor with broken edid data?
udovdh: what was the analog limit?
libv: udovdh: none :)
udovdh: maybe.
libv: udovdh: but in reality, 400Mhz
udovdh: if the limit is 165 and we expect to cut off at 160 to be safe...
udovdh: so say 50% more
libv: but only very few are actually able to handle that
udovdh: to be practical and make stuff work anywhere
libv: i think the 24" sony got close to 400
udovdh: cabling, impedance etc
libv: udovdh: i think in this case that it is a monitor issue
udovdh: even with DVI cabling is an issue
libv: udovdh: it advertises a non-reduced blanking mode
udovdh: while it should be reduced
libv: while it cannot handle the bandwidth of this mode
udovdh: to stay i=udner 160 Mhz
udovdh: with that one connection...
libv: but if you force it to use the reduced blanking mode, it is happy
udovdh: hmmm. strange
udovdh: faulty firmware?
udovdh: hmm. that would be something. fw update for my lcd...
libv: yeah, this is not too uncommon
libv: yeah, would be nice if this was possible
udovdh: so if I understand all oK for this bug:
libv: but manufacturers don't make the magic knocking sequence for mqking it write capable available
udovdh: one can work around it with some xorg.conf magic?
libv: yup
udovdh: hardcoding the mode
udovdh: and forcing that on the lcd
libv: and forcing the driver to allow reduced blanking on this panel, yes
udovdh: no edid or ddc
udovdh: ok
udovdh: that is the good news
udovdh: so in dual link you get some sort of digital interlace?
udovdh: with dubblee bandwidth?
udovdh: s/dubblee/double/
libv: yeah, two subsequent pixels get pushed out
libv: and then i believe the dvi links are allowed to go to 172 or so per link as well
libv: so you effectively can get up to 344 MHz modes
ajax: 165MHz is the crossover frequency.
soc: hi
plectrum: egbert: I tried out your new patch and it looks good
plectrum: hmm, I am afraid that load detection of my VGA monitor is not working on a 3870X2. known inssue?
libv: plectrum: hrm, no load detection?
libv: plectrum: hrm... does it even run the sense function on the given dac?
plectrum: thats what it looks like I put up the bug
plectrum: libv: don't know, it will sense a hotplugged DVI
libv: ok, trawling through the log
libv: right... LVTMA has no load detection... so lack of anything on DACA means that it thinks it has LVTMA detected
libv: let me get the 3850 out and check there, before i go and look further
soc: hi
soc: http://www.ubuntuusers.de/paste/53126
soc: what's my mistake?
soc: my script looks like this: http://www.ubuntuusers.de/paste/53128
soc: anyone?
ndim: soc: "git pull" suffices.
soc: thx
libv: plectrum: seems to be working quite nicely on the 3850 :(
libv: plectrum: is this a special monitor, long cable, or something else in that area?
plectrum: libv: well could it be something I am doing?
libv: don't think so :(
plectrum: no nothing special at all just a DVI->VGA adapter in the mix
libv: right... so that cannot be it :(
plectrum: libv: any other test I should run?
libv: let me compare the atombios load detection routines, maybe there's something there
plectrum: you have the BIOS dump from a different bug report
libv: yup
egbert: plectrum: could you please dump the rom from the 3850x2 and send it to us?
egbert: ah, ok.
plectrum: did you guys find it? called 950F.1022.2042.vga.rom
libv: soc: ?
libv: soc: nm :)
egbert: soc: when you give a url to pull from you also need to specify the branches
egbert: soc: from and to which you merge.
egbert: soc: if you leave out the url it will take what's in the configuration
egbert: soc: like ndim suggested.
dmb: does ati provide firmware/bios updates for there cards anymore?
libv: plectrum: both atombios functions are exactly the same :(
plectrum: libv: so does this mean atombios is at fault???
libv: no, i am wondering what the issue could be
libv: because there seems no hardware level difference :(
plectrum: ah now I understand, you mean between your card and mine, right?
libv: plectrum: yup, rv670 atombios load detection is the same as rv680, works here, so this is quite weird
plectrum: well you saw my logs, it does look to be load detection that is the problem, right?
libv: plectrum: what does conntest say btw?
plectrum: its in the bug report description
libv: urgh, ok, didn't look close enough apparently :)
libv: hrm, i should also go and sync up the conntest utility still
libv: plectrum: hrm :(
soc: hi libv, egbert!
egbert: hi soc!
libv: plectrum: rhd_conntest: we write DACA_CONTROL1 in DACALoadDetect
libv: plectrum: can you make this read RegWrite(map, DACA_CONTROL1, 0x00202002);
plectrum: sure can, let me fire up that machine and test it
plectrum: libv: I updated line 524 but it did not help. Load Detection: RHD_OUTPUT_NONE
plectrum: libv: the HotPlug line does change from RHD_HPD_NONE to RHD_HPD_1 with and without the patch
plectrum: ...if I connect the VGA that is
libv: plectrum: eh?
libv: hpd changes with an adjusted DACxCONTROL1 value?
libv: wtf is going on :)
plectrum: libv: yeah there is not load detect but the HDP and DDC fields change if I disconnect the cable
libv: oh, of course
plectrum: with and without the patch
libv: right
libv: plectrum: are there other monitors around you can try this with?
plectrum: well I can always borrow from those not in the office ;)
libv: :)
plectrum: hey look, my two monitors had a baby and now I have three...and load detection!!!! I wonder if it was going through that KVM (which I forgot to mention)
libv: plectrum: pffff :ppp
plectrum: sweet, it was my fault as I expected
plectrum: bad KVM no cookie for you
libv: plectrum: but still... why is the kvm giving through DDC while the load detection fails ...
egbert: plectrum: is this a mechanical or electronic switch?
plectrum: electrical
plectrum: yep, it looks like the KVM as I tried the monitor attached to the KVM but this time I connected directly to it and it works fine
egbert: plectrum: was the monitor connected to the card at that time?
plectrum: at which time?
egbert: when you did load detection.
plectrum: yes
libv: ah, dug a kvm out of the cabinet
libv: this seems like a mechanical one though
egbert: maybe the kvm switch doesn't connect the line when no signal is coming from the card.
plectrum: still shouldn't the KVM be the load on the line?
egbert: plectrum: depends on the manufacturer.
egbert: kvm could do load detection itself and place a load on the line for the card.
egbert: but, does the manucaturer expect this?
libv: mechanical one sees daca np
libv: as expected :(
egbert: i would expect that it has signal amp and the input impedance isn't 75 ohm but way higher.
plectrum: away for some coffee
ndim: egbert: input impedance != 75 ohms would be silly, as that provokes reflections in the cable.
aneas: i went through http://ati.amd.com/developer/vendorid.html and compared all r500/r600 pci ids with utils/conntest/rhd_conntest.c and there are 68 ids missing
aneas: i would add those and send anyone responsible a patch
aneas: struct RHDDevice { CARD16 vendor; CARD16 device; int bar; chipType type; } <- i don't know what bar means, but its =2 in all currently existing entries
aneas: is it safe to use 2 blindly?
aneas: oh, base address register?
s3phiroth: hi there. i have a new laptop with an ati radeon mobility x2300. is the radeonhd driver right for me ?
s3phiroth: lspci or lshw don't tell me what kind of chip this card has and i haven't had much luck googling
aneas: should be, yes
aneas: your chip is M54
s3phiroth: oops
s3phiroth: yeah
aneas: ->r500
s3phiroth: just saw it on the wiki
s3phiroth: i'll try installing it
s3phiroth: btw, has anyone tried it on hardy heron ?
michaellarabel: RadeonHD on Hardy Heron? Yes, it works.
^^MAg^^: hardy got 1.1.0 packages
s3phiroth: oh...nice
s3phiroth: yeah...aptitude shows them. let me try that
michaellarabel: s3phiroth: you really should build from source though, 1.1 was from quite a while ago.
s3phiroth: ok, i'll do it
^^MAg^^: how far till 3d and aiglx will be working?
s3phiroth: by the way i haven't much luck with this on #ubuntu+1, but does anyone knows how can i actually configure graphics on hardy heron ?
^^MAg^^: vim /etc/X11/xorg.conf :)
s3phiroth: the thing is, dpkg-reconfigure xserver-xorg doesn't asks for any graphic card details like it used tu
s3phiroth: *to
s3phiroth: ^^MAg^^: yeah...i was trying to avoid that :)
michaellarabel: Do it manually or displayconfig-gtk, but I don't know if that supports RadeonHD yet
s3phiroth: even because things seem to have changed a little regarding configuration files...
s3phiroth: michaellarabel: that would be impossible as i can't even start x
^^MAg^^: yup, you just need a minimal xorg.conf
s3phiroth: so i'll have to go the manual way
^^MAg^^: all input devices are recgonized automaticly
s3phiroth: ^^MAg^^: but i can still add things to it like before ?
michaellarabel: oh, didn't know you couldn't start X.
^^MAg^^: s3phiroth: yup, you can keep old xorg.conf and just monify driver/options
s3phiroth: oh, ok
s3phiroth: i though they had changed things to some other file
s3phiroth: that's why i was reluctant in editing it
s3phiroth: so...erm...what should i put on the driver section of xorg.conf ?
s3phiroth: Driver "radeonhd" ?
s3phiroth: oh...found the example
s3phiroth: well...it compiles perfectly but xorg can't seem to find the driver, according to the log. what could i be doing wrong ?
ndim: s3phiroth: Not installed the driver, installed to wrong location, not given Xorg the right -modulepath, ...
ndim: ... not given the right modulepath in xorg.conf...
ndim: a number of things come to mind.
s3phiroth: well...whatever it was it's not complaining about that anymore but i still can't start X server. getting a "screens found but none have a usable configuration"
libv: aneas: yes, base address register, we haven't seen any other location but that for the mmio bar, yes
aneas: libv, can i send you a patch for review in ~20 minutes?
s3phiroth: hum...for some reason it's falling back to xorg.conf.failsafe
s3phiroth: whoa !
s3phiroth: i have X
s3phiroth: i ran the command that the ubuntu default has for replacing the original xorg.conf
s3phiroth: and it must have found the radeonhd automatically
aneas: libv, i took all the information from http://ati.amd.com/developer/vendorid.html and merged it with the current ids in utils/conntest/rhd_conntest.c adding some information where available. this is the result: http://aneas.org/ids.txt
Ryszu: It's not quite correct, info wise
aneas: ok, whats wrong?
Ryszu: HD 38xx is RV670, not RV630
aneas: http://ati.amd.com/developer/vendorid.html says otherwise. are you sure?
aneas: too bad if that list is wrong
Ryszu: Yeah, I'm sure
Ryszu: HD 36xx is RV635, and HD 34xx is RV620, if I remember rightly too
aneas: i have a x1700 in my laptop. that list says m56, pciutils says m66-p, wikipedia m56
Ryszu: heh
aneas: should i remove all the info?
aneas: i didnt c/p it by hand, i wrote a converter
Ryszu: It's good to have that stuff in there
Ryszu: If it was me, I'd just fixup the handful of entries by hand
aneas: but if one is wrong you cant trust the rest
aneas: :/
aneas: btw, who would be the person i should send it to?
ordchar: aneas, you would send it in patch form to the mailinglist
aneas: k
ordchar: well that would make the most sense to me anyways, ... not that i am that involved in here
libvde: aneas: i'm sorry; but this patch is rather wrong
libvde: aneas: for rv620, 635, we cannot depend on the same code as for anything earlier
libvde: aneas: as all that is conntest underneath has changed completely
libvde: it just doesn't make sense to do this sort of thing
libvde: it only makes sense to keep conntest in sync with the actual driver
aneas: mh, too bad
aneas: i just thought it would be useful after looking at luc verhaegens latest commit
libvde: aneas: also, C++ style comments are not really appreciated by the compiler flags we use
aneas: i posted a patch to the mailing list with c style comments
libvde: aneas: i am that person btw :p
aneas: oh, hehe
libvde: and i just synced up the list to what our driver has
aneas: ok, didnt know that
aneas: if you like the comments i could add them to all existing ids without introducing new ones
libvde: no, conntest is just a quickish and dirtyish tool
libvde: we carry comments in rhd_id.c already
aneas: damn, i should have seen that file
aneas: well, i'll find other ways to contribute :)
libvde: aneas: :)
libvde: aneas: there's plenty of things to fix, so no worries there :)
aneas: radeonhd was pretty quiet during the last days, so i just wanted to see more changes ^^
libvde: aneas: we have quite a big pile of rv620/635 things in the pipeline
aneas: is r500 dri anywhere in there, too? :D
libvde: yup, the driver side drm support is being ported over
aneas: great :)
DanaG: Hmm, I couldn't find (at first look) any estimated timeline on the wiki. Does anybody have any estimate for where this driver may be by summer (June)? I'll be looking then into buying something new, and I'm sick of the issues I've had with nvidia.
dli: DanaG, http://www.phoronix.com/forums/showthread.php?t=7652 , Kano is right, it's funny to ask a question like this
DanaG: I'd mostly be using just compiz-fusion; I run games under Windows.
Soul_keeper: windows gaming is dead :)
DanaG: Not as long as Wine doesn't get along with PulseAudio.
DanaG: I mean, not for me, as long as...
Soul_keeper: only runs linux native games/apps
Soul_keeper: less stress that way
DanaG: I'm also not a hardliner against closed-source, as long as it works well enough.
DanaG: Oh, and I forgot to mention: it'd be a laptop with midrange of whatever generation is current then.