mcgreg: can anybody tell me what version the "new" radeon module should have if I make itout of the current drm-git?
airlied: mcgreg: 6.7.196 most likely..
mcgreg: hmm well, I booted an older kernel , where I had all headers, compiled the modules and I got that -> (II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.28.0 (II) RADEON(0): [DRI] installation complete
mcgreg: so, in theory I have DRI now
airlied: mcgreg: oh kernel module. is 1.28.0
mcgreg: something is wring here?
mcgreg: wrong even
airlied: mcgreg: what?
mcgreg: is there something wrong with the version I pasted or is that normal?
airlied: no should be normal..
mcgreg: ok
mcgreg: hmm I see the flickering again .. on at least 2 positions it is
kdekorte: airlied, any progress on laptop panels working on the r500 ?
tilman: airlied: alex blogged that you fixed atombios-support for r400. it doesn't work for me though
tilman: airlied: it doesn't hard lock anymore, but the mode setting is severely b0rked
tilman: it claims to set the right mode according to xrandr, but the vertical and horizontal freqs are off
tilman: both outputs are dvi, btw
tilman: only one monitor shows my desktop, but i don't know whether it's due to the output programming or due to the monitor
tilman: agd5f: http://3209502b2c8c1273.paste.se/ any ideas?
agd5f: tilman: got a log?
tilman: agd5f: http://exodus.xmms.se/~tilman/Xorg.0.log
agd5f: tilman: does moving RADEONRestoreFP2Registers(pScrn, &info->ModeReg); before atombios_external_tmds_setup(output, mode); help in legacy_mode_set() in radeon_output.c??
agd5f: tilman: also, are both heads borked or just one?
tilman: both
tilman: trying now
tilman: damn, operating a system without seeing anything sucks. halted it by accident ;p
tilman: agd5f: that gives me the exact same behaviour
agd5f: tilman: how about removing the call to atombios_external_tmds_setup() all together?
tilman: nope
tilman: agd5f: can i get a dump of the important regs using radeontool?
tilman: or is it likely that it's the order in which they are written breaks things here? :p
agd5f: tilman: not sure yet. works fine on my dual dvi
agd5f: tilman: another thing to try, leave the call to atombios_external_tmds_setup(), but in radeon_crtc.c::legacy_crtc_mode_set(), comment out lines 910-912 and 919-921
agd5f: and see if that helps
agd5f: Magnade: what does /proc/cpuinfo show for your mac mini?
Magnade: agd5f: got a place to paste it?
agd5f: Magnade: pastebin.ca?
Magnade: http://pastebin.ca/801888
Magnade: i dont know any of the paste sites since i usally use a private one
agd5f: Magnade: thanks! no worries
tilman: agd5f: you're the man -- that's fixing it
agd5f: tilman: seems the set pll atom call doesn't work properly on your chip
agd5f: the atom r4xx stuff tends to be a bit flakey since it was still being polished at that point
Magnade: agd5f: np
agd5f: Magnade: I should have automatic fix for you chip committed shortly
Magnade: agd5f: k it need testing?
agd5f: Magnade: sure I'll let you know when it's committed
tilman: agd5f: nice. so this chip needs atombios to power up the outputs correctly, and !atombios to set the plls \o/
agd5f: tilman: seems to be the case. I wish we had a good way of knowing which ones which atom functions worked on
agd5f: Magnade: committed
Magnade: patched and compiling
Magnade: agd5f: works
agd5f: Magnade: excellent!
Magnade: interesting bit is the way it was before seemed to have a side effect
Magnade: vncviewer would add scroll bars like the window wouldnt fit on the screen
Magnade: now it seems to know the screen size fine
agd5f: strange
Magnade: screwy to say the least
Magnade: agd5f: thanks for the fix
agd5f: np
Magnade: i notice plenty of talk on r4xx and r5xx in here but ive not seen much talk of r6xx is it just too new?
agd5f: Magnade: it works more or less, just no accel
agd5f: tilman: from the looks of it, the atom code is doing the same stuff on both or our cards, but there's something about your pll that the monitor doesn't like
agd5f: s/or/of/
Magnade: figures since thats what i was thinking of upgrading too at some point
OipOS: Does Mesa-7.0.2 offer accel for the Xpress series yet?
agd5f: tilman: if you leave the atom pll code in, can you switch modes and does the monitor sync?
agd5f: Magnade: we should have 2D accel on r6xx pretty soon
Magnade: agd5f: cool thats the important bit to me
Magnade: seems i only use 3d for render ;)
tilman: agd5f: the legacy code path gives me 80 khz/75 hz. the atombios code gives me 84 khz/79 hz
tilman: agd5f: cycling modes doesn't help
agd5f: tilman: hmmm, maybe there are fbdivs that the atom code doesn't like
agd5f: tilman: does it work if you force fb_div to 16 in atombios_crtc_set_pll() in atombios_output.c?
agd5f: tilman: actually I think I may have a fix
tilman: agd5f: fought with hw for a bit, i'll try the fb_div thing now
tilman: agd5f: fb_div=16 works, but that ends up with another signal than which was requested (< 70 hz)
agd5f: brb
rx__: airlied
rx__: you were right
rx__: arg
rx__: anyway
rx__: airlied you were right
rx__: it was LVDS
rx__: i copied the values from regs 0x7af0/0x7af4 and the vt showed up
agd5f: tilman: weird. that particular pll is broken for me too
rx__: hmm.. those are lvtma cntl and state regs..
rx__: how are lvtma registers restored in VT?
agd5f: rx__: radeon_driver.c:: avivo_save() and avivo_restore()
rx__: takes a looky..
rx__: thanks :)
agd5f: np
tilman: agd5f: there's only one pll that maps to fb_div==16?
agd5f: tilman: no, I just tried setting 135 Mhz pixel clock
tilman: ah
tilman: hehe
agd5f: like the one your card is trying
rx__: i need to get off this shitty wireless
egore: I finally found a reproducible case for the mouse cursor flickering: move it over the gnome-volume-control tray icon
egore: and what I also noticed I can't move the cursor to the top left corner ... there are always like 5x5 pixels missing
libv: egore: a lot of people are complaining about this flickering cursor issue. we at radeonhd are looking at other issues first, but this cursor issue should be something for next week
airlied: egore: yeah I think we have a cornering issue I only noticed it myself..
airlied: rx__: cool.. wanna play around with save/restore to see if it can be fixed?
egore: libv, airlied: no big issue just wanted to point out a reproducible test case
libv: egore: what text mode are you using?
libv: egore: vesa?
libv: egore: or plain vga?
egore: plain vga
egore: no fb driver within the kernel
libv: ok :)
egore: I think the applet is redrawing very, very often
Magnade: egore: the older gnome-volume-control checked the current volume level several times a second it might refresh itself that often also
egore: Magnade: I guess that's still the case
egore: muting in alsamixer "immediately" is shown in gnome-volume-control
egore: and I guess the redraw the same icon over and over when nothing changed
egore: but I'm to lazy to look into the source :-)
Magnade: i dont recall what version was suppose to fix that
egore: nope, I was wrong ... the "flickerer" is the clock ....
egore: yeap the aera left of the clock causes the flickering
egore: no it wasn't the clock ...
egore: *sigh*
egore: no, it's when the cursor is between 1520 and 1530 in horizontal orientation (starting left)
egore: y doesn't matter
agd5f: egore: I fixed the cursor offset issue last night
rx__: airlied; in progress.. is it safe to assume this need only be applied to mobility cards?
rx__: avivo + mobility
rx__: is LVTMA used at all in !mobility cards?
libv: rx__: yes
libv: rx__: it can be either an LVDS output or a TMDS output
rx__: libv; thanks ;)