agd5f: vladc: does ddcprobe work on non-x86?
agd5f: vladc: actually if it's a mac card it wouldn't
agd5f: no x86 bios
spstarr: i installed .212 will give it a go tomorrow when i power up :)
airlied: agd5f: https://bugzilla.redhat.com/show_bug.cgi?id=431872
vladc: agd5f: It seems that ddcprobe actually did work on Imac G3s at some point, and people got useful output from it: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/22976/comments/15
airlied: agd5f: any idea on that .. more macmodel powerbook stuff
vladc: agd5f: Checking a bit further, xresprobe/ddcprobe contains a file called of.c which I guess is supposed to read info from OpenFirmware on PowerPC. Also, Debian's xresprobe page, states that "ddcprobe only works on i386 and powerpc."
vladc: http://packages.debian.org/unstable/x11/xresprobe
moondrake: vladc: I do not know about fedora's ddcprobe but most of those tools on ppc read the EDID file in /proc/device-tree I guess.
vladc: moondrake: thanks for the tip, I have a bunch of files under /proc/device-tree. I'll try to track down which one contains monitor info.
moondrake: or even get it from X (mandriva's tool does that)
moondrake: vladc: it is called EDID, but the exact subdir depends on your setup
vladc: moondrake: Unfortunately X doesn't start without any modlines (it says Error no screens found). I'm searching or EDID...
vladc: moondrake: Bingo! Found it under /proc/device-tree/pci@f0000000/ATY,Rage128P2ks@10/EDID. Now to find out why ddcprobe can't get to this info...
agd5f: airlied: no edid, randr is picking a bad mode, for some reason the panel mode is notgetting added or randr is overrriding it
agd5f: Option "PanelSize" "1440x960" or whatever it's supposed to be may fix it.
agd5f: airlied: yeah, looks like the lack of an edid is the problem. RADEONFPNativeMode() is adding a null mode since we don't store the dotclock when we derive the panel size on macs
agd5f: airlied: some commit may have broken ddc on powerbooks. It's be useful to get a previous log when it worked
airlied: agd5f: I'll see what I can get..
agd5f: also, it might work if he adds his panel mode to the modes section of the display subsection of the screen section of his config
agd5f: airlied: also if he upgraded his rom or had any apple service done, they might have killed his panel's edid. I've heard of that happening
parabelboi: skype quält ;-)
parabelboi: ups, wrong window
josef: i'm looking at the x.org wiki page for this driver and i cant find a link to a svn/hg/git tree anywhere
ejs1920: http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=summary
josef: awesome thank you
mikkoc: guys, can someone write a small howto to install
mikkoc: nvm
mikkoc: guys, can someone write a small howto to get 3d with radeon, on r500 cards?
mikkoc: and put it on phoronix maybe?
mikkoc: that'd be great :D
PSYCHO___: mikkoc: it is about geting git version of drm and driver and it's distro based
mikkoc: afaik not really
mikkoc: you need the r500test branch of mesa
mikkoc: and i'm not sure but you need to specify the chip of your card?
mikkoc: this is what i read in #radeonhd
agd5f: mikkoc: about all it does is run gears at the moment
mikkoc: ah
mikkoc: does it do 2d?
mikkoc: i'd like to play xmoto :D
MrCooper: xmoto is a much more complex 3D app than gears
mikkoc: is xmoto 3d?
mikkoc: but ok, i guess i'll wait
ejs1920: here's an interesting bug
ejs1920: if i run fireflies, afterwards it makes textured video go wobbly
ejs1920: which can be fixed by running extreme tuxracer
tigerchen: agd5f: ok, i got xv working as it seems but, gl doesn't somehow, error-message is unknown chip id 0x7145, can't guess.
tigerchen: libGL warning: 3D driver returned no fbconfigs.
tigerchen: libGL error: InitDriver failed
agd5f: tigerchen: still using the old mesa driver
tigerchen: hmm, i thought i had the correct one,
agd5f: LIBGL_DEBUG=verbose glxinfo
tigerchen: agd5f: http://rafb.net/p/ZyzEfI92.html
agd5f: tigerchen: when you built mesa where did you install it?
tigerchen: i made "make install" but i think i should have symlinks set
agd5f: check to see that /usr/lib/dri/r300_dri.so is the new version
tigerchen: k
tigerchen: ok copied it
tigerchen: direct rendering: No
tigerchen: but no error mesage
tigerchen: libGL: XF86DRIGetClientDriverName: 5.3.0 r300 (screen 0)
tigerchen: libGL: OpenDriver: trying /usr/lib/dri/r300_dri.so
tigerchen: libGL error: dlopen /usr/lib/dri/r300_dri.so failed (/usr/lib/dri/r300_dri.so: undefined symbol: drmBOUnreference)
tigerchen: libGL error: unable to load driver: r300_dri.so
tigerchen: when i set verbose
tigerchen: agd5f: ok new error messages: libGL error: __driCreateNewScreen_20050727 not defined in r300_dri.so!
tigerchen: Your driver may be too old for this libGL.
tigerchen: libGL error: unable to load driver: r300_dri.so
minor_change: how do i enable kernel mode setting ?
agd5f: tigerchen: I'm not sure. could be several things. how did you build mesa?
minor_change: (oh, and hello all :)
tigerchen: agd5f: like described here: http://dri.freedesktop.org/wiki/Building#head-b3fb665c9f24b4a32424b78428c082e830832250
agd5f: tigerchen: good. hmmm
tigerchen: i try building the modules and copying them again (1.4-1.6)
tigerchen: shouldn't be that long
agd5f: tigerchen: can you pastebin the full error log from LIBGL_DEBUG=verbose glxinfo
tigerchen: sure
tigerchen: http://rafb.net/p/u1xi5j82.html
tigerchen: ok build just failed
tigerchen: radeon_screen.c: In function ‘radeonCreateScreen’:
tigerchen: radeon_screen.c:723: error: ‘RADEON_PARAM_FB_LOCATION’ undeclared (first use in this function)
tigerchen: radeon_screen.c:723: error: (Each undeclared identifier is reported only once
tigerchen: radeon_screen.c:723: error: for each function it appears in.)
agd5f: tigerchen: build and install latest libdrm
agd5f: and make sure mesa is looking for the lastest drm headers
agd5f: *latest
tigerchen: k
tigerchen: hmm, new build, same error
glisse: tigerchen: double check that is use proper header you should see that in compiler command
glisse: tigerchen: it works for other so definitly somethings wrong on your side
tigerchen: glisse: ok might be
tigerchen: glisse: tell me what to do and I'll do it
glisse: tigerchen: i have no idea double check that you don't have older header
glisse: double check that you properly install libdrm
tigerchen: glisse: i made it again and copied it like said on http://dri.freedesktop.org/wiki/Building#head-b3fb665c9f24b4a32424b78428c082e830832250
glisse: tigerchen: pastebin the full compiler error
tigerchen: no more compiler errors, sry
tigerchen: seems you got me wrong
tigerchen: http://rafb.net/p/u1xi5j82.html
glisse: tigerchen: you are using mesa from git ?
tigerchen: yes
glisse: then you need xserver from git
tigerchen: 1.4.0.90-r3 is not new enough?
glisse: no, git
tigerchen: k, fetching
tigerchen: and again a monster-pull ^^
tigerchen: hmm strange
tigerchen: is dri2proto something different then xf86driproto-2.0.3 ?
glisse: yrd
glisse: tigerchen: yes, its a new module
glisse: tigerchen: jhbuild is really nice to build xorg
tigerchen: nice, 1 problem less, there is a live-x11-overlay for gentoo ^^
eboettcher: tigerchen: I'm about to put gentoo on my new box (just got home)
eboettcher: nice to know I don't have to make my own overlay for everything
tigerchen: eboettcher: layman -a x11 and this in /etc/portage/package.unmask: http://rafb.net/p/eOx1LW98.html
eboettcher: tigerchen: thanks -- right now I'm busy trying to make space to install everything.
tigerchen: /dev/mapper/root 90G 78G 7,2G 92% /
tigerchen: and >44G of that are /home
eboettcher: I have a mess of stuff to clean up :/
eboettcher: I may just make a 20GB hole and worry about moving stuff around when school cools down -- just spend a sunday afternoon doing some spring cleaning :)
tigerchen: i know that, i was freed of that mess by a dieing backup-hdd
tigerchen: so i had to reinstall the whole system
eboettcher: what's the state of r500 2d?
tigerchen: working, here and in radeonhd
tigerchen: and here is even first steps of 3d
eboettcher: tigerchen: do you know if recent linux radeonfb supports r500?
tigerchen: eboettcher: i have better results with uvesafb
tigerchen: radeonfb somehow doesn't set up the display in it's native 1400x1050
glisse: eboettcher: radeonfb is dead end
eboettcher: glisse: well it served me well enough before on my r300 based cards.. I couldn't get vesafb (due to vesa's limted resolutions) to do 1920x1200 on this display
tigerchen: eboettcher: try uvesafb
eboettcher: 240x150 console is nice for three-way sdiff
tigerchen: Warning, R520 detected, 3D HAHAHAHAHA!!.
tigerchen: that looks quite good
tigerchen: hmm, but glxgears won't start
tigerchen: libGL warning: 3D driver claims to not support visual 0x54
tigerchen: some more of that with 0x21 0x22 0x54
tigerchen: Error: couldn't get an RGB, Double-buffered visual
federico1: hi everyone
federico1: I set up an xorg.conf for an RV280 with a modeline for 1440x900, but the server starts up at 1440x1024. The log says "Virtual size is 1440x1024 (pitch 1472)", but I didn't configure that size anywhere... does someone know what's going on?
agd5f: tigerchen: almost there. that error sounds like krh's dri stuff. I think dri1 stuff is broken at the moment. he would know better
agd5f: *dri2
glisse: agd5f: i think krh pushed a fix yesterday
agd5f: glisse: oh cool
federico1: probably stupid question - does the radeon driver support randr? I just started a server and it doesn't have the randr extension
rx__: yes it does
federico1: rx__: any clues on why it may be disabled? :)
rx__: xrandr doesn't display anything?
federico1: rx__: one sec
federico1: champignon$ xrandr
federico1: Xlib: extension "RANDR" missing on display ":0.0".
federico1: and xdpyinfo doesn't list it, either
rx__: you're using radeon driver?
federico1: rx__: yeah
federico1: rx__: I hand-built an xorg.conf from two known-good configurations, so as to get two video cards in
federico1: (I'm running a multihead hackfest for opensuse, but first need to get this going) :)
rx__: what radeon driver version ships with opensuse?
rx__: 6.7.197?
agd5f: federico1: sounds like you built the xserver without xrandr support
rx__: o
federico1: rx__: hmmm, the SRPM is kind of weird; it has the source tarballs for 6.6.193, 6.6.3, and 6.8.0 -- I'm not sure yet how the package is actually built
federico1: rx__: I'll poke our X people
federico1: agd5f: nope, normally randr works just fine; it's something with this dual-head configuration
otaylor: federico1: Is randr-1.2 supposed to work with two cards?
otaylor: doubts it
airlied: otaylor: sounds like a different hang you are seeing now, does it always happen on server recycle or in general?
otaylor: airlied: I saw it twice on server restart, once on vt switch (I think, on the vt switch, I might have killed gdm and had it restart without noticingit)
otaylor: airlied: Not while the server was running
otaylor: airlied: When I get home I can step through the init process and try to get a handle on when it hangs .. to see if it's at the initial point where it locks DRI or not
agd5f: otaylor: nope, not yet
federico1: otaylor: no idea
federico1: otaylor: I have two cards because both monitors have VGA inputs only - should I get a dvi->vga converter and use a single card? :)
agd5f: federico1: randr doesn't support multiple carads yet
agd5f: cards even
otaylor: federico1: probably, yes. I think basically all dvi ports have vga pins, so it's just an electrical thing. Other people would know better
federico1: but how did people do this before? certainly video cards from 5 years ago didn't have multiple outputs?
otaylor: federico1: you know how xinerama works, right?
otaylor: federico1: Every X primitive is just executed twice, once for each video card
otaylor: federico1: With a coordinate offset
otaylor: federico1: it's a dreadful hack, but it does make it easy to get things working across multiple video cards
federico1: otaylor: now I know :)
otaylor: federico1: multihead these days is typically one big frame buffer scanned out to multiple devices ...so that's what randr-1.2 implementation was written to support
federico1: I mean, how did people make multihead work at all a few years ago - how come multiple cards were supported then?
otaylor: federico1: Because people used xinerama
otaylor: federico1: Another option you could investigate is Xdmx
federico1: oh god
otaylor: federico1: That makes a multihead setup from multiple x servers
federico1: otaylor: sounds like I'll try to find a converter... I wanted to Get Stuff Fixed(tm), but if I can't even get the stupid X server to work...
agd5f: federico1: before xrandr drivers loaded twice on multi-head cards and we used xinerama to tie them together.
otaylor: agd5f: I figured describing multihead was enough weird stuff for one time, without describing "pretend one card is two cards. Now make it look like one card again"
agd5f: otaylor: the wonders of X
airlied: randr 1.2 works on multi-card just not with xinerama
federico1: airlied: "not just with xinerama" - does that mean I can use two cards with randr, but not have a continuous desktop?
federico1: (i.e. just two X screens?)
airlied: federico1: in theory that should work.
mattmatteh: anyone know what would cause blue dots (pixels) all over the screen ? seems like garbage or noise. mostly happenes when something on the screen is being updated. noticeable in console when typing or any output to the screen, and noticeable when i watch a movie if the screen has alot of black in it
agd5f: mattmatteh: sounds like a bandwidth issue
mattmatteh: agd5f, i thought there were a few times that it wasnt there
mattmatteh: agd5f, is there a way to test that or fix ?
mattmatteh: agd5f, also, i ordered a dvd calibration disc to see if i can correct the color problem i had ( dvd's and dark browns displayed as blues and greens)
agd5f: mattmatteh: try a smaller mode?
mattmatteh: agd5f, not sure how to do that. i just let the driver figure it out with edid
mattmatteh: left the defaults
mattmatteh: the lcd only works with 1920 x 1200 i think
mattmatteh: agd5f, seems to go away sometimes. like now, i noticed it when i booted, started X, quit X and doenst seem to be there
agd5f: mattmatteh: probably is 9550's have low mem bandwidth
agd5f: s/probably/problem/
mattmatteh: agd5f, i thought i read that those can work with a large display
mattmatteh: like more than what i have
agd5f: mattmatteh: yeah, it probably needs to be tuned a bit depending on what you are doing
agd5f: each part of the chip contends for memory bandwidth
mattmatteh: agd5f, i am using radeonfb in the kernel, would that matter or make a difference ?
agd5f: mattmatteh: shouldn't but radeonfb is generally bad news when mixed with X
mattmatteh: i kinda have to use radeonfb
mattmatteh: else i dont have much for console
airlied: mattmatteh: offb..
agd5f: or uvesafb
mattmatteh: airlied, hmm ??
agd5f: mattmatteh: powerpc thing
airlied: mattmatteh: the only place radeonfb is necessary is on powerpc
mattmatteh: airlied, oh.. i have that too, works fine
mattmatteh: agd5f, seems that restarting mplayer removes the blue dot noise
mattmatteh: airlied, i have of fb, and radeonfb. never had a problem
agd5f: mattmatteh: right radeonfb works ok on powerpc, it's just on the newer radeons on the x86 side where there are issues
mattmatteh: agd5f, yeah i didnt think the newer cards would be supported as well, thats why i bought an older model
mattmatteh: agd5f, and seem that the problem is not alwas present
agd5f: mattmatteh: your card may be ok, but if you get strange lock ups or other problems it may be radeonfb related
eboettcher: indeed
agd5f: mattmatteh: like I said, it's bandwidth related
mattmatteh: agd5f, havent locked up at all
eboettcher: on my xpress200m laptop, if radeonfb is running then there will be crashes every once in a while when leaving X
mattmatteh: agd5f, works great except for the blue dots and dvd problem but might just need to be calibrated
agd5f: the overlay, the crtc, the blitter are all contending for mem bandwidth
eboettcher: considering there's a specific place it happens, I may look into it more closely.
agd5f: mattmatteh: does Option "DisplayPriority" "HIGH" help?
mattmatteh: agd5f, i can try that.
agd5f: that option boosts the display controller's priority in the memory controller among other things
mattmatteh: agd5f, just restared X, but was thinking .. the blue dots were happening at boot
mattmatteh: and i have radeonfb compiled into the kernel <*>
mattmatteh: agd5f, i see the large ugly text like 1980 DOS, then it reads the edid, and i get niced modern pretty letters using the widescreen full resolution, but the blue dot noise
mattmatteh: thats well before i log in or X
agd5f: mattmatteh: I don't think radeondb touches the diplay priority
mattmatteh: no change
mattmatteh: i still get the noise
agd5f: mattmatteh: try a smaller mode
mattmatteh: what does the U, S, V, D mean from modes in /sys/class/graphics/fb0/ ?
federico1: airlied: yeah, that works - but separate screens is so nineties ;)
federico1: airlied: anyway - I'll look for a dvi->vga dongle
federico1: meanwhile, back to the laptop
leio: oh great, EXA is slow, XAA has rendering corruptions...
airlied: agd5f: hmm we are carrying a patch from ajax that rips out the crazy DDC wrapper.
airlied: which appears to amybe break the macbooks.
agd5f: airlied: ah yes
agd5f: that should do it
agd5f: the macs need some of those bit twiddled to enable i2c
agd5f: for ddc
agd5f: much of that loop can be cut
agd5f: airlied: I think you can cut the for (j = 0; j < 3; j++) { loop, but you need the rest
agd5f: airlied: I think we may have to leave tcl enabled for randr/textured video. if you run gears and textured video, you periodically get bad vertexs in the textured video.
agd5f: no luck so far avoiding it
airlied: agd5f: bah.. yeah I suppose it makes sense to not switch byp[ass on /off so often
airlied: wonders can you do the transforms in vertex shader.
agd5f: airlied: actually, that'd probably be pretty easy
airlied: we'd still need vapless code but at least we'd be using the VAP for something :)
agd5f: airlied: we already have vapless code ;)
airlied: agd5f: any ideas on redner 16-bit stuff.. or should we just disable it
airlied: agd5f: the rendering to 5.6.5 or 5.5.5.1 seems busted
agd5f: airlied: haven't test it yet. I'll take a look
airlied: agd5f: rendercheck spews a lot
glisse: airlied: did you change the alu output for 5.6.5 ?
airlied: glisse: I played with it a bit.. the US_OUT_FMT is wierd..
glisse: we always had trouble with 16bts rendering as far i remember
airlied: it seems like it can't do 5.5.5.1
glisse: bte what is a good benchmark for exa ?
glisse: 10=C_6_5_6
airlied: glisse: gtkperf, render_bench, firefox trender
airlied: glisse: no 5.5.5.1 thgough
agd5f: airlied: fixed. just disabling the 565 code in output_fmt seems to work fine
agd5f: just use the 8888 format
glisse: hopefully tomorow i redo the exa cmd submission and i can run some test see if fencing is costly or not
carldani: hi
carldani: is there any release of xf86-video-ati pending?
agd5f: carldani: probably not immanently, too much accel stuff in flux at the momenet
carldani: yes, the git tree has seen quite some changes since the last release
airlied: we also have to do mach64 and r128 releases ..
airlied: just once :)
carldani: agd5f: I read the git logs, but I'm not sure whether r3xx accel stuff has changed noticeably since the last release...
carldani: heh
airlied: carldani: we've got one big regression in r300 EXA speeds we'd like to sort outl
agd5f: carldani: there have been a lot of improvements since the last release
mattmatteh: is there any support for radeonfb here ? or is that a different channel ?
airlied: mattmatteh: radeonfb is not really supported anymore.
mattmatteh: :(
mattmatteh: airlied, do you know why ?
airlied: mattmatteh: because the maintainer had no time.
mattmatteh: hmm
airlied: mattmatteh: and it worked well enough on the Macs he needed it on.
airlied: mattmatteh: kernel modesetting will replace it eventually
mattmatteh: airlied, seems that it is the only way to get framebuffer on macs or of machines?
mattmatteh: airlied, is modesetting in the kernel now?
airlied: mattmatteh: offb works fine.
airlied: mattmatteh: not yet..
airlied: mattmatteh: also only on older Macs, so it shouldn't regress..
mattmatteh: airlied, i think i have both on my ibook
mattmatteh: airlied, but wanted to use radeonfb on my x86 desktop
mattmatteh: since that seems to work best with my widescreen lcd
airlied: mattmatteh: well that is the area where it gets less supported..
mattmatteh: but as we discussed earlier, not sure what my options are for my wide screen
airlied: don't use text mode :)
mattmatteh: that was most of the reason i got the radon
mattmatteh: airlied, not that i use it alot, but i do use it
mattmatteh: console mode that is
airlied: on x86 you can uvesafb maybe if your BIOS supports the widescreen modes
mattmatteh: airlied, that needs a user space daemon?
mattmatteh: airlied, i was avoiding that
mattmatteh: airlied, seemed silly to have a user space daemon for that, and one that is a virtual x86 emulator too
airlied: mattmatteh: yeah.. well you can either fix radeonfb or wait for modesetting.
airlied: gotta go bbl..
airlied: l bneing 4 days.
mattmatteh: airlied, thanks for your help :)
carldani: mattmatteh: I have hacked a bit on radeonfb in the past
mattmatteh: carldani, do you know what would cause random blue dots (pixels) all over or noise ?
carldani: mattmatteh: mostly to get suspend working reliably on the rv350 in my laptop
mattmatteh: carldani, i was thinking it was related to radeon x driver, but niticed it happening at boot
mattmatteh: and by restarting mplayer, X, or switching vt's i can get it to go away
mattmatteh: carldani, i was almost thinking perhaps a modeline is wrong ? but thats a complete guess
carldani: mattmatteh: sorry, that question is too advanced for me. but ...
mattmatteh: not sure how to investigate this
carldani: mattmatteh: let me guess... you use a dvi cable
mattmatteh: and was googling and could not fine anything about the new modesettings for the kernel ?
mattmatteh: carldani, yes, dvi
carldani: mattmatteh: which rxx series?
carldani: (lspci will tell)
mattmatteh: rv350 as radeon 9550
carldani: ah yes, I know that problem.
carldani: mattmatteh: try a cheaper DVI cable
carldani: yes, right, a cheaper DVI cable
mattmatteh: carldani, i have read that different cables can make a difference
mattmatteh: but.. i have an nividia card before and never had this problem (but was using vesa-tng) and seems to go away if i mess with it
carldani: basically, the problem goes away if you use a DVI cable without analog wiring
mattmatteh: carldani, and i am using the cable that came with the lcd ( dell 24 inch high color)
mattmatteh: hmmmmm
mattmatteh: that might make sence
mattmatteh: analog noise messing up the digital
mattmatteh: carldani, you had that problem ?
carldani: the analog signal somehow causes blue snow on screen if you use the digital wires of DVI
mattmatteh: carldani, wow....
mattmatteh: thought i would be stuck with that problem
carldani: mattmatteh: yes, and a cheaper DVI cable without analog wires fixed it. Before that, I had a really expensive cable
mattmatteh: carldani, ill have to start browsing newegg
carldani: of course, being able to turn off the analog output on a given DVI connector would fix this as well
mattmatteh: carldani, thanks for the info and tip, i will try that. !!!!!!!
carldani: agd5f: is that possible?
mattmatteh: carldani, do you know how to turn off the analog ?
mattmatteh: i thought it would be off if it wasnt detected
carldani: mattmatteh: you're welcome. I only found that explanation after my monitor and graphics combo had been in repair a few times and the shop could never reproduce until they used my cable
mattmatteh: carldani, and perhaps something is turning it off when i switch console, X, vt's, or restart mplayer ?
carldani: mattmatteh: could be
mattmatteh: carldani, i spent 3 months researching my lcd before i bought it, i have read several threads about different cables working differently. most suggested the more expensive
carldani: yaeh, a really bad trap
mattmatteh: looks at newegg
carldani: I'm pretty sure agd5f has a way to disable analog output on a given connector for r3xx
mattmatteh: carldani, ok. i was looking for a friend too. i told him i would look at hdmi prices for his dvd player
otaylor: agd5f: Once in a debugger, with a R100, it is in fact really obvious what was going ... I was using info->texW/texH for my tile size, but they aren't set to texture w/h on the R100
leio: http://dev.gentoo.org/~leio/xorg/xf86-video-ati-XAA-font-rendering.png
leio: http://dev.gentoo.org/~leio/xorg/xf86-video-ati-XAA-rendering.png
leio: as for the XAA regressions that are laughing at me while I await the under discussion EXA improvements on r200...
leio: night
carldani: good night!
mattmatteh: night