Radeon IRC Logs For 2009-11-12
happycube: airlied - awesome... (too bad it took 8hrs tho)
airlied: glisse: T60 resumes!! it has other issues b it does resume
airlied: glisse: I noticed if I resumed, unloaded radeon, ran atomtools, loaded radeon it all worked
airlied: then I enabled kernel atom debugging and it all worked
airlied: then I bisected kernel atom debugging down to the one printf that made it all work
airlied: realised stupid IIO MC register reading has issues, the printf delay was making it all work
airlied: no idea if the patch is 100% correct but really its not a fastpath I don't think
happycube: gah, timing bugs :P
airlied: EruditeHermit: ping new test patch on the bug
airlied: just a guess coming from fixing the other resume bug
EruditeHermit: airlied, on it
EruditeHermit: airlied, do you want me to get drm-next kernel and patch it?
Nightwulf|work: hi all
dileX: hi Nightwulf|work
Nightwulf|work: hi dileX
soreau: hi dileX, Nightwulf|work
dileX: hi soreau
MostAwesomeDude: hi soreau , dileX , Nightwulf|work
soreau: hi MostAwesomeDude
Nightwulf|work: hi soreau , MostAwesomeDude
dileX: soreau: compiling 2.6.32-rc6-git5 (incl. drm-linus)
dileX: hi MostAwesomeDude
soreau: dileX: Nice :)
dileX: MostAwesomeDude: yesterday, I was discussing about binutils-gold on #grml
soreau: MostAwesomeDude: Any gallium revelations lately?
dileX: MostAwesomeDude: says "A common problem seems to be calls to XOpenDisplay without directly linking to -lX11..."
dileX: MostAwesomeDude: with mesa is "binutils-gold-compatible"
dileX: MostAwesomeDude: shall I send that patch to ML?
MostAwesomeDude: soreau: Not particularly. Been working on some things here and there.
MostAwesomeDude: dileX: Looks good to me, but I have *zero* say in that stuff. Send it to ML, see what they think.
dileX: MostAwesomeDude: the patch is from 2009-05-08 07:27 and IIRC I talked with some guys of debian-x team about it. should look into my backlogs. but anyway, this record on debian QA gives me hope, that this patch was correct.
MostAwesomeDude: dileX: Well, again, you really need to get it to ML.
dileX: hehe, OK
dileX: Nightwulf|work: you recognized what we achieved :-)?
EruditeHermit: hey, I have a question about using the wiki drm-next instructions
Nightwulf|work: dileX: you talk about the 3D abilities for r6xx/r7xx?
EruditeHermit: is the part in "alternatively use drm-next as is" the whole kernel?
dileX: Nightwulf|work: no. much simpler.
Nightwulf|work: dileX: then I perhaps didn't follow the channel properly...what do you mean then?
dileX: Nightwulf|work: it tooks us some hi and hi that others followed :-)
Nightwulf|work: dileX: ahh...ok ;-)
dileX: EruditeHermit: drm-next is a "complete" 2.6.31 linus-tree with drm and especially drm-radeon-kms fixes
dileX: currently, the latest fixes get into drm-next first
glisse: airlied: sweet
EruditeHermit: dileX, I am trying to apply this patch to drm-next. But it seems there is no radeon_combios.c to patchhttp://people.freedesktop.org/~airlied/scratch/combios_readback.diff
dileX: EruditeHermit: come on, thats only two lines :-) change it manually.
EruditeHermit: ah I figured it out
dileX: how did you apply?
EruditeHermit: patch just couldn't find the file
EruditeHermit: it existed
EruditeHermit: specified the location manually
EruditeHermit: don't know why it couldn't find it
dileX: EruditeHermit: whats that patch fixing?
EruditeHermit: just something to test for resume
EruditeHermit: resuming from suspend
dileX: hmm, power-mngt (so long I wanted to test that on my box)
dileX: to follow with powertop
dileX: soreau: if you wanna compile linus-tree: apply
soreau: dileX: Thanks but I don't think I have a need to
soreau: I only have this lowly rv350 :)
glisse: airlied: btw i got a patch to add default 800x600 in face of broken edid
glisse: i will send it to you
glisse: it's attached to bug report
airlied: EruditeHermit: if it applies to whatever kernel you have that'll do
airlied: glisse: do we not do that?
airlied: if we find no modes and its connected we add 800x600
airlied: we are thinking of changing it to 1024x768 at some point
EruditeHermit: its building
EruditeHermit: has been for an hour
EruditeHermit: slow machine
airlied: EruditeHermit: cool, no hurry, I'm burned out after fixing one laptop ;-)
EruditeHermit: airlied, seems like the changes were simple
EruditeHermit: one liners
airlied: its always only one line
EruditeHermit: airlied, that must be frustrating
airlied: I reckon if I didn't get access to that hw today I'd be still tracking it down in a month
airlied: or glisse would
EruditeHermit: airlied, how did you get access to it?
EruditeHermit: basically I should just mail my laptop to you
airlied: EruditeHermit: he just happened to be visiting RH Brisbane for a meeting this week
EruditeHermit: al well
EruditeHermit: have to sleep
EruditeHermit: will let you know how it goes in the morning
glisse: airlied: i don't think we do that
glisse: at least i didn't see where it's done
glisse: well what happen if i am not mistaken is that we return connector disconnected if edid is broken
airlied: it gets called if we are connected and have no edid
airlied: or modes
glisse: airlied: thing is it get all only is connector return status connected
glisse: but we don't
glisse: get call
airlied: what do we return?
airlied: if its disconnected there should be no modes
glisse: default ret value
glisse: well it's not disconnected, it's connected but with wrong edid
airlied: I've tested that code on my monitor with broken edid before
airlied: and it always worked
airlied: maybe it an issue in dual-head configs
glisse: airlied: well it doesn't work anymore
glisse: i got report with single config monitor
glisse: i might missunderstand the code
glisse: but from what i grasp
glisse: if edid is null and there is a monitor we return disconnected
glisse: and edid is null if it's broken
glisse: my patch doesn't seem to add mode to non connected output
airlied: ah since we changed how we get edid
airlied: I don't think that patch is the correct way to fix it
glisse: what should i do then ?
glisse: just report connected with no mode
glisse: note that i add mode only if ddc_probe probed a monitor
glisse: so there is somethings connected but it hasn't valid edid
airlied: yeah I think conected with no mode is right
airlied: disconnected is definitely wrnog
glisse: ok will update
airlied: the problem on DVI is we don't know if analog or dig is connected unless we load detect
airlied: glisse: I tink it shuold call the load detect fallback path
airlied: when DDC respsonds but EDID is invalid
airlied: the problem is I've seen on box get DDC response when no monitor exists
glisse: yeah somethings i missed
airlied: stupid servers
glisse: i guess it's somethings designed for windows
airlied: granted the response was all garbage
airlied: another thing we should do is fixing the edid header and redoing the checksum like fb
airlied: dinner &
glisse: airlied: so the dvi detect code is ok
glisse: it was the vga which was wrong
airlied: glisse: oops
glisse: i am testing faking broken edid
glisse: of course my monitor doesn't support 800x600
glisse: airlied: what it's valid to have set_base called with a null fb ?
scarabeus: http://dev.gentoo.org/~scarabeus/render-issue.png <- i have slight issue with current xf86-video-ati head on r600
scarabeus: any ideas if the issue is Qt or the driver?
glisse: it's driver
glisse: so far i never reproduced it
glisse: i don't know why my kde refuse to break i need to retest
taiu: scarabeus: what's you chip and is it dri1 or dri2?
glisse: agd5f, airlied: why do we enable scaler on any lcd output ?
glisse: shouldn't we enable scaler only when the resolution is not the native screen resolution ?
scarabeus: RV670 ;; dri1, no kms :]
glisse: agd5f, airlied: thought on patch at: https://bugzilla.redhat.com/attachment.cgi?id=369204
Zajec: glisse: in "Add default 800x600 mode when getting bad EDID" you dropped printing drm_get_connector_name(connector), is that printed line before or sth?
glisse: yeah will print connector
Zajec: glisse: do you have some code locally to wait for engine idle? (kms)
Zajec: glisse: eventually could I copy this from KMS?
Zajec: glisse: want engine to be idle to reclock it
glisse: Zajec: suspend path of each asic has the code
glisse: basicly take the cp lock then call the asic function
glisse: Zajec: each asic should have it's pm function
glisse: i think best is one function for each asic in charge of pm
glisse: of course some asic might share a common function
glisse: r100/r200, r300/r400, rv515/r520, ...
Zajec: glisse: will think about it...
Zajec: glisse: so many details about PM there are, blah
Zajec: reclocking, idle, VBLANK, irq, callbacks...
Zajec: timer, schedules
Zajec: glisse: should I call resume myself after calling suspend?
Zajec: or will that be called by other code parts?
glisse: don't call resume
Zajec: glisse: ok
glisse: the code for idle is in resume function
glisse: well in each resume function
Zajec: glisse: should I lock rdev->cp.mutex? i can see there is also rdev->cs_mutex, but I guess i should just use rdev->cp.mutex, right?
Zajec: hope it's last question :)
Zajec: cp_mutex? in kms?
Zajec: err, moment
Zajec: glisse: did you mean cp.mutex?
crash2k_: anyone here?
biotube: you have a problem?
crash2k_: no a question :P
biotube: ask it
crash2k_: is there a tool to change the desktop color settings?
Terman: It looks like there is one outdated docuemnt on http://www.x.org/docs/AMD/
Terman: r600isa.pdf is version 0.31 (may 2007), the version on the AMD site is 0.35, (dec 2008)
glisse: Terman: yeah such thing happen
biotube: crash2k: multiple conversations happen
biotube: though I'm not sure what color schemes have to do with the driver
crash2k_: no i mean like gamma adjust
Zajec: xgamma --help
crash2k_: anything for saturation?
Terman: glisse: should I open a bug about that or how can this be fixed?
bridgman: Terman; we kept the older version up because it seemed easier to understand, all the new versions are on the stream site
bridgman: we're going to set up some pages that point to all the relevent areas
bridgman: for docs/code etc
bridgman: the old version of the isa doc might not be needed any more, will check
crash2k_: is there a gui tool for xgamma?
Terman: bridgman: ah, OK. I keep all versions anyway, so I indexed the file with the version and kept it
agd5f: glisse: I think we probably need two vars. rmx_type and rmx_enabled since users can select full/center/aspect/none
glisse: agd5f: i tried to cope with that
glisse: i set rmx off a connector creation and only force to full if there is no other rmx type selected
glisse: thus user selection is not overwritten
Zajec: would like to just see "1920x1080Scaled" mode for PANEL :|
Zajec: solution for dumps, like radeonhd
glisse: agd5f: also should this properites show up in xrandr ?
agd5f: glisse: they should
agd5f: Zajec: kms supports scaled modes. they just don't have "scaled" in the name
agd5f: that's the only way to get non-native modes on lvds
Zajec: agd5f: but it does not offer 1920x1080 for my 1600x900 PANEL, even if I connect my DVI monitor which is 1920x1080
agd5f: Zajec: ah, downscaling. It's trivial to implement, but generally confusing to most users
Zajec: hm, confusing? don't see what can be confusing about this :)
ajax: "why is my text unreadable"
Zajec: also don't remember any report from confused report on radeonhd
Zajec: ajax: it's the same with upscaling
ajax: no, that's "why is my text fuzzy"
Zajec: both confusing for me ;)
Zajec: not for me
Ghworg: would just like to have 4:3 modes have the correct aspect on his 16:10 panel
agd5f: Ghworg: already supported. set the scaler mode to aspect
Ghworg: agd5f: Ooh, excellent!
Ghworg: I do that through xrandr?
Zajec: maybe we could standarise that aspect property
agd5f: Ghworg: yes xrandr --outptut