rx__: oo.. new tirdc post
eboettcher: :)
Benkinooby: hi, i'm installing linux on a md94100 laptop, which is equipped with a radeon xpress 200M? for linux, which driver is best: radeon, fglrx or is there a special driver for mobile ati cards?
rx__: do you care about power?
rx__: or performance?
eboettcher: I don't know how well fglrx works on 200M at all.
eboettcher: I've never run it on my laptop.
eboettcher: I could try it out... uptime on my laptop is 55 days.
eboettcher: the X server used seems to have a memory leak :/ and it constantly consumes cpu.
Benkinooby: i set VIDE_CARD to fglrx, will tell you the result
Benkinooby: rx__: ofc i want best performance/power but i don't need to play highresolution :)
rx__: oh i mean.. do you want to be able to adjust power settings
rx__: i.e. battery save
Benkinooby: rx__: y
Benkinooby: rx__: i think the fglrx (closesource by ati) will handle this better than the opensource driver ( called radeon i think)
rx__: uhh
Benkinooby: ?
rx__: yeah.. just try both and see what you like
eboettcher: I'd prefer not
eboettcher: because when some 200M bug comes up, and there will be one, there isn't much I'd be able to do about it
eboettcher: using fglrx that is
MostAwesomeDude: Evening, folks.
MostAwesomeDude: Fedora + high-powered box = all kinds of fun issues. Prolly bad blocks somewhere.
MostAwesomeDude: On the plus side, the 1900
MostAwesomeDude: X1900XT I dug out of the closet appears to work.
MostAwesomeDude: And hopefully whatever r6xx I get will work as well.
MostAwesomeDude: But sleep now, code later seems like a goood idea. 'night.
reppel: Hi, does xf86-video-ati enable hdmi audio on r690?
funda3: reppel: i think there is an alsa driver for the hdmi on abit fatality boards which have ati IGPs, not sure about the r690, might want to ask in #alsa
reppel: thanks
stefanb: airlied: wake?
stefanb: airlied: I was just wondering if "BuildRequires: gcc-c++" should be added to Fedora's mesa.spec
surfer: keeping a 1900xt in ur closet
surfer: makes me hate u
mcgreg: lol
mcgreg: I've got a x1300pro .. which is probbably extremely slow compared to a x1900xt :)
mcgreg: at least I can play wow with it ;)
surfer: yea
surfer: if u turn it down to cartoon graphics
mcgreg: unfortunately still on window ...
mcgreg: surfer: well, no, wow works fine.. I use to play 1440x900 with rather good quality, but then , wow is not really demanding
mcgreg: I wonder how long it'll take until I can play wow with wine. thats actually what I really wait for ;)
airlied: you can play wow on wine now from what I know.
airlied: not sure on r500 yet :) but I've heard people playing it on wine on other dirvers.
mcgreg: airlied: no, r500 doesnt do it yet
mcgreg: I've tested that already of course :)
airlied: mcgreg: wierd crash, or just misrender?
mcgreg: airlied: but warctaft3 works finje :)
mcgreg: airlied: neither.. due to something it is baaaadly slow, like it wouldnt use 3d acceleration at all
airlied: mcgreg: either vblank or fallbacks maybe.
mcgreg: I could paste you the few errors/warning(whatever) if you arfe interested, but I'm not sure if they would be any helpful at all
airlied: did you try disable_lowimpact_fallback?
mcgreg: I havent done this yet, but I could test that
adamk: So what needs to be done to get AGP cards working? :-)
airlied: adamk: its wierd R500 agp doesn't work.
airlied: adamk: I can't think what might be different on them than r300.
adamk: Heh.
adamk: Just my luck :-)
airlied: adamk: you said writeback failed didn't you?
adamk: Yes, that showed up in dmesg... X never fully starts up, and consumes 100% of my CPUs.
stefanb: airlied: I was just wondering if "BuildRequires: gcc-c++" should be added to Fedora's mesa.spec
airlied: stefanb: not sure. probably, no idea if other packages do that.
airlied: stefanb: I'm not sure what the minimum build root is.
stefanb: airlied: Default install doesn't have c++ compiler and therefore SRPM rebuild fails
MrCooper: disable_lowimpact_fallback should probably be enabled by default, seeing as the fallbacks tend not to work correctly anyway...
airlied: MrCooper: yeah I'm going to turn it on for Fedora.
airlied: its pointless erally.
airlied: MrCooper: it should be strict_correctness or something ;)
MrCooper: airlied: nothing's different except for the fact the chip is PCIe and there's a PCIe-AGP bridge in between ;)
airlied: adamk: could you get a dmesg with debug enabled?
airlied: MrCooper: I wonder do we detect it as PCIE :)
stefanb: airlied: but I guess default koji mock setup provides gcc-c++ and therefore you don't see the problem there
airlied: adamk: insmod drm with debug=1 then modprobe radeon. then start X
MrCooper: airlied: I don't think so, but the bridge may need to be accounted for
adamk: airlied, I can certainly try.
MrCooper: though I thought it just worked at least with some such cards
adamk: airlied, Is that the same as 'echo "1" > /sys/module/drm/parameters/debug' , btw?
airlied: adamk: I just want that before radeon is loaded ...
airlied: stefanb: http://fedoraproject.org/wiki/PackagingGuidelines#Exceptions
adamk: Gotcha.
airlied: stefanb: that says no.
stefanb: airlied: OK. I was guessing something like that was behind it...
mcgreg: airlied: with .drirc having disable_lowimpact_fallback - it starts but is like software-rendered (totally slow) .. with .drirc disable_lowimpact_fallback it doesnt strart with an error :
mcgreg: aik
mcgreg: airlied: http://rafb.net/p/kEZG5g49.html
airlied: mcgreg: wierd.. maybe it needs FBOs or something.
mcgreg: airlied: argh .. I mean, with*out* dirc it does start
mcgreg: this is what my .drirc looks like .. autoconfigured http://rafb.net/p/8MliJo57.html
onestone: I fully understand that without a memory manager we need to copy data back to system memory if we use glCopyTex(Sub)Image. But why is it soooooooo slow in the radeon driver even with PCIe? Even intel is faster here.
MrCooper: onestone: intel has the shared memory advantage
MrCooper: onestone: and it actually accelerates this with TTM
onestone: MrCooper: It is also faster with the old code without ttm
MrCooper: mcgreg: that error probably isn't directly related to .drirc
onestone: MrCooper: If I use my compiz mag plugin as example and see the compiz framerate then I'm getting something like 3.2 MB/s
onestone: compared to 4GB/s PCIe 16x
MrCooper: there's more to it than just a simple copy; anyway, while this probably could be improved, I'm not sure it's worth it vs. getting it properly accelerated
onestone: The quesion is, how long will it take to get a working memory manager
adamk: MrCooper, http://pastebin.ca/1033928
MrCooper: adamk: I think airlied asked for that...
adamk: D'oh.
adamk: airlied, http://pastebin.ca/1033928 :-)
adamk: I have to step away from my machine for a bit... I'll be back, though.
airlied: adamk: oh and the Xorg log :)
airlied: nothing looks out of place in that log..
airlied: which sounds like we are missing something else :-(
reppel: Does the xorg driver have something to do with hdmi audio on x1250 igps?
airlied: reppel: I've heard the gpu driver may have to do some enabling.
airlied: someone posted some patches on radeonhd recently.
reppel: airlied: i'll try to port them into xf86-video-ati
reppel: airlied: are they in radeonhd git already?
airlied: reppel: don't think so.. they were just on the mailing list.
reppel: ok
airlied: not even sure what they did just saw them pass by.
reppel: thanks
airlied: somenoe mentioned fglrx was needed to enable audio.
airlied: adamk: oh maybe I see something :)
adamk: airlied, Cool.. I'll get you the X log in a minute.
reppel: airlied: do you refer to this? http://lists.opensuse.org/radeonhd/2008-05/msg00095.html
airlied: reppel: yup that was it.
elbeardmorez: hi, has anybody else struggled with the latest radeon driver .. 'EE No connected devices found!'. I know there was a big rework of detecting connected devices, are there any options that I must enable nowadays? I'm trying xserver 1.499 too.
airlied: adamk: try master drm now ...
adamk: airlied, Here's the X log... http://pastebin.ca/1033952
adamk: Updating now.
airlied: adamk: gotta go bbl to see if it worked ;)
adamk: I'll be around :-)
adamk: Odd... Now X is saying it can't dlopen /opt/xorg/lib/dri/r300_dri.so (libdricore.so: cannot open shared object file: No such file or directory)... libdricore.so does exist in /opt/xorg/lib/dri (as does r300_dri.so)
adamk: Should libdricore.so be installed to a regular shared library directory?
adamk: Never mind... User error :-)
MrCooper: yeah, there's no libdricore.so upstream
adamk: Alright, direct rendering works now.
adamk: ut2004 works great.
adamk: So AGP cards should now be working thanks to airlied :-)
adamk: Or, at least, mine.
adamk: I get some visual distortion with compiz... Same that I had on Wednesday with my x700, but disappeared yesterday after rebuilding everything... This is very odd.
legume: airlied: whoo AGP progress - had the same problems as adamk and can get past writeback fail with new drm :-)
adamk: Yeah, he just fixed it in the last hour or so :-)
legume: airlied: xv crashed it though and there is a seperate regression since I last tried in march (could always get OK 2d by blacklisting nvidia-agp but screen is green now)
adamk: legume, xv is working here.
legume: adamk: yea it's great - was reading via radeonhd.org logs.
MrCooper: legume: saw that once (with totem, mplayer was fine even then) but haven't seen it again
adamk: Yeah, I should clarify. xv works here with mplayer.
legume: adamk: I will have to sort out my config - maybe it's because it's empty and using XAA or some other messup on my part.
legume: early days will start playing - was using mplayer. The green screen thing is a bit distracting :-)
legume: maybe I could play with bios AGP aperture size aswell - fglrx doesn't work unless it's at 512
MrCooper: legume: we only use 8 by default, so that's unlikely to be an issue
adamk: Anyone have an idea what might cause this distortion with compiz with the latest driver: http://68.32.29.130/Screenshot.png ?
legume: ahh OK - just seems like many people on phoronix with AGP 5xx cards need to change that setting.
adamk: (Sorry for the slow connection) :-)
azuwis: does r500 3D support need xserver 1.5?
adamk: Odd.. Even after setting AGPMode to 2, I still get "AGP 4x" reported in the renderer string from glxinfo.
legume: got to go for a while - bye and thanks
MrCooper: adamk: AGPv3 only supports 4x and 8x
adamk: Ahhh.
stefanb: How can I see if my chip is using AGP? I think it is a PCIe chip
stefanb: (II) RADEON(0): PCIE card detected
MrCooper: that's how
adamk: It's interesting... lspci shows my x700 as PCIE, but Xorg detects it as AGP (which is correct).
adamk: I guess the PCIE and AGP versions share PCI ids.
MrCooper: adamk: all R500 and newer chips (and some older ones) are PCIe; the AGP cards use a PCIe-to-AGP bridge
adamk: Ahhh, right.
MrCooper: it's the card that matters - try plugging an AGP card into a PCIe slot or vice versa ;)
stefanb: MrCooper: I was just worried, because xorg.log also shows (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000
MrCooper: stefanb: the AGP stuff should just be ignored with a PCIe card
azuwis: Trying r500 3D support, get a '(EE) Screen(s) found, but none have a usable configuration.'
azuwis: full log here http://www.mediafire.com/?xgjdyiktp0d
azuwis: could someone examine the log?
adamk: I'm not a developer, but I'm guessing this is an issue: "(WW) RADEON(0): Unrecognized BIOS signature, BIOS data will not be used"
adamk: Also, some people might be turned off from looking at the log file by that website. You're better off using something like http://pastebin.ca/ :-) Fast, simple, and no annoying popups.
azuwis: adamk: rarely use irc, thanks for the tip.
adamk: That's the only video card in that machine, correct?
azuwis: Yes, it's a Lenovo Thinkpad 60 laptop.
adamk: (II) RADEON(0): Attempting to read un-POSTed bios
adamk: That suggests that the video card was not posted when the machine booted up... Which, presumably, is not the case.
adamk: I had a similar problem on Tuesday or Wednesday...
azuwis: how did you fix it?
adamk: One of the dev's offered a patch...
adamk: But, interestingly, even without that patch, it works fine for me now on that machine.
adamk: Give me a second to see if I can find the patch.
adamk: http://www.botchco.com/alex/xorg/stefanb.diff
adamk: It came from agd5f. I make no promises that it will fix anything, or that your problem is even the exact same as what I had :-)
adamk: But, it probably can't hurt anything.
adamk: cd
adamk: D'oh.
azuwis: thanks, adamk. I'll try the patch.
azuwis: My X log on pastebin.ca, http://pastebin.ca/1034004
adamk: azuwis, FYI, You could check with agd5f when he's around... For the past few days, I've seen him answering questions on here in the the afternoon EST (roughly 6 hours from now).
stefanb: adamk: Oh, the BIOS problem? Yes I have that patch in there...
adamk: Yeah, I was giving the URL to azuwis since he's getting errors about the video card having an unposted BIOS.
adamk: Interestingly, I don't need that patch any more.
adamk: I'm not sure what was up with my machine that day.
azuwis: cool! apply the patch and reboot, X start now. not sure if the patch or reboot solve the problem.
adamk: Yay
elbeardmorez: hi, could anybody look at my log pretty please? http://pastebin.com/m7931a93c ..Unknown DDC Type etc.. i'm stuck.
azuwis: compiz now running, happy :) ~~
mikkoc: has anyone tested composite with kwin on kde4? with the new mesa, drm etc?
adamk: mikkoc, Both kwin and compiz are compositing window managers that use texture_from_pixmap, so I imagine that if it works well with compiz (which it does), it should work well with kde4.
mikkoc: that's what i hope
mikkoc: i should upgrade to xserver from git to have working aiglx...
mikkoc: i don't know if it's worth the trouble tho :)
adamk: I might try KDE4 later today..
adamk: It's not difficult to do, if everything works properly... Just time consuming :-)
mikkoc: yea, compiling isnt the problem.. but i think i will have problems with it
mikkoc: i installed it 2 days ago, when i was trying to get dri to work.. it kept freezing when logging out from kde4
mikkoc: i had to downgrade
legume: I got mplayer xv to work - set exa and restarted from power off. I can still get it to crash by using -fs. It could be a git xorg/twm thing I suppose - quake3 demo couldn't get fullscreen either, but ran OK (1/2 fglrx fps) in a window.
adamk: onestone had a problem with fullscreen mplayer yesterday too. Not sure if it was crashing, locking X, etc...
legume: tried compiz - background image/window decoration is corrupted, but it didn't crash. On exit r300mem.c has thrown a message about running out of GART memory and to increase GARTsize option - anyone know where to do that please?
legume: adamk: maybe was just an X lock ctrl alt bs didn't work but SysRq did. One time I tried it played OK but not fullscreen it was unscaled in a slightly larger window. twm window placenment is not respected they endup top center.
legume: Oh yes - everything is still green!
spstarr_work: Alex Deucher returned to xf86-video-ati development
spstarr_work: great
spstarr_work: welcome back agd5f :)
mikkoc: meh
mikkoc: as i activate composite effects on kde4 my pc freeze
mikkoc: how can i debug this? if i can..
AMF|DJ-N: i'm really down. yesterday i had the system running with 3d support, after restart today the system only has mesa 7.0.3-rc2 :(
AMF|DJ-N: i reinstalled drm and mesa but no changes
spstarr_work: mikkoc: which caed?
spstarr_work: card
mikkoc: mobilty x1400
spstarr_work: mikkoc: if its an r3xx you may experience badness
mikkoc: mesa drm xserver radeon from git
agd5f: spstarr_work: where did I go?
spstarr_work: agd5f: you came back to ati development ;)
dmb: when did he leave?
spstarr_work: the blogs
spstarr_work: "Alex Deucher returned to xf86-video-ati development. He is doing bugfixes mostly so it might show a glimpse of an upcoming release."
agd5f: I don't remember leaving...
Magnade: agd5f: nice to have you back aways ;P
Magnade: s/aways/anyways/
z3ro_: hmm maybe someone can explain this to me... it's a bit weird... 0x4e28 is being set to 0xc0000000 (the start of the FB memory as lspci reports it)
z3ro_: so which reg tells the gpu where to draw within the FB?
z3ro_: 0x4e28 is RB3D_COLOROFFSET0 btw.
agd5f: z3ro_: 0x4e28
z3ro_: agd5f: that just points to the start of the FB though.
z3ro_: is it the pitch reg that controls where on the visible fb/screen the drawing happens.
agd5f: z3ro_: pitch reg defines teh pitch of the surface
z3ro_: hmm ok
agd5f: vertices define where stuff gets drawn
z3ro_: but aren't they relative to some kind of "base" reg? I'm probably completely wrong.
agd5f: offset reg defines the offset of the surface and pitch defines the width in bytes, so relative to that, barring clipping
z3ro_: ok. I'm just trying to work how I need to adjust the cmd buffer so that it's portable to other systems (and even X restarts)
z3ro_: I've had some cases where a dump taken from this box locked up after it had been rebooted (so I guess X configured something a bit different)
z3ro_: taking a new dump of the same test then works fine.
agd5f: all the offset registers take MC addresses
agd5f: so the MC fb location may be different between fglrx and radeon
z3ro_: this was on the same driver (r500 dri)
agd5f: ok, weird
z3ro_: yeah. I'm just comparing some dumps of the same demo, but ran at different locations on the screen (bottom left vs bottom right) now.
dudeman: so 3d specs are now open?
z3ro_: dudeman: yep
dudeman: think in a year or two we could have a 3d oss driver for r5xx?
adamk: dudeman, We have one now.
dudeman: 'stable' is the word
Ori_B: dudeman: you mean like the one that was just committed?
z3ro_: SC_CLIP_0_[A-B] and VAP_VPORT_XOFFSET changed... so I guess it's the VAP reg thats interesting.
adamk: I'm running compiz on the open source radeon driver with an x1300 even as I type this.
z3ro_: actually both would need to be correct, but thats the reg I was looking for.
dudeman: adamk, I know but I was told i'd have to build everything including Xorg/mesa from GIT
dudeman: adamk, painful :)
adamk: dudeman, I didn't say it was easy to get, just that we already have a 3d oss driver for r500 cards :-)
dudeman: jeje
dudeman: I meant easy for dumbasses like me
dudeman: already packaged and everything
dudeman: hehe, brb
adamk: I imagine that most distros will include it in their next release.
fpoibaf: Hi, I am testing current mesa git with r500 3D driver
fpoibaf: All appears to work fine, exept the game sauerbraten (Ubuntu 0.0.20071227.dfsg-1 version). The problem is that is really slow about 1 frame every 10-20 seconds.
fpoibaf: It appears to get a software callback:
fpoibaf: File r300_render.c function r300Fallback line 377
fpoibaf: Software fallback:ctx->Line.SmoothFlag
adamk: fpoibaf, Use driconf to disable low-impact fallbacks.
adamk: fpoibaf, And run sauerbraten with the -p0 option (I believe that's the correct one).
fpoibaf: Yes, I alredy tried disabling low-impact fallbacks
fpoibaf: but I see all grey. I'll try -p0 option
fpoibaf: -p0 option don't exist, however it run fine in windowed mode (-t) with low-impact fallbacks disabled, but it's very slow (7fps)
adamk: There's some option to completely disable shaders...
adamk: I *thought* it was -p0, but apparently not :-)
adamk: Ahhh.
adamk: -f0
adamk: http://megahurts.dk/rune/r300_status.html
adamk: There's another tip there to improve performance.
adamk: As I recall, I also had to disable some water effects to get decent performance.
fpoibaf: Also found this page:
fpoibaf: http://sauerbraten.org/docs/config.html
fpoibaf: tried with -f0 but I get about the same fps
adamk: Hmmm... It doesn't look like there are sauerbraten packages for Fedora 9...
fpoibaf: Anyway I was just testing the new driver with some games...
fpoibaf: ...and report the problem I found.
adamk: I've only tested a few things, but it seems to work as well as my x850, which I guess isn't surprising.
fpoibaf: Are the problems here: http://www.phoronix.com/scan.php?page=article&item=ati_r500_gaming&num=1 known to the developers?
elbeardmorez: spstarr_work: hi, where can I read about 'if its an r3xx you may experience badness' please (struggling r3xx owner)
spstarr_work: elbeardmorez: depends on the problem
elbeardmorez: spstarr_work: no connected devices (apparantly) .. http://pastebin.com/m7931a93c
spstarr_work: different situation this is with 3D :)
elbeardmorez: so i've got that to come :D great
elbeardmorez: is it possible to build old pre 6.8 radeon code against the latest xserver git do you think??
adamk: I doubt it...
adamk: elbeardmorez, One of the dev's can probably help you, but you might have to be patient and wait till one of them stop idling :-)
adamk: elbeardmorez, And it can't hurt to ask on the appropriate mailing list.
elbeardmorez: adamk: which dev would you suggest?
adamk: agd5f, airlied are probably the best suited to help you.
elbeardmorez: adamk: any chance you could tell me what kind of fps you can pull with glxgears (no benchmark I know) with your x850 please ..I've got another rig with a X850GT AGP and am not that happy..
adamk: elbeardmorez, Sorry, it's not in the machine at the moment.
elbeardmorez: adamk: np, thanks.
adamk: Bah, I'm being called to a meeting.
adamk: bbl.
agd5f: elbeardmorez: is this a secondary card?
agd5f: looks like either the card isn't posted or your bios is hosed
elbeardmorez: agd5f: hi. yes it is.
agd5f: elbeardmorez: you may want to try the version in git
elbeardmorez: agd5f: i think I tried that yesterday.. ..I will try again though.
dudeman: oh man halal chicken and rice w/ white sauce from this dude outside school is better than radeon 3d opensource
dudeman: I'm sorry
dudeman: :)
syntropy: any significant changes to r300 git so far?
elbeardmorez: agd5f: just tried and no joy. could you tell me whether compiling old pre 6.8 code (or the version prior to this detection rework) against the new xorg git would work?? thanks.
agd5f: elbeardmorez: it will work, but you still may get issues with secondary cards
agd5f: the issue isn't detection, this issue is card is not getting posted properly and/or the bios isn't getting read properly
surfer: sup
elbeardmorez: agd5f: I had a near perfect setup with dual xservers (accelerated ati and accelerated nvidia together!) using an older radeon driver, I needed to upgrade the xserver due to a bug in xserver's sharevts option. i'll give it a whirl anyway. thanks for helping.
agd5f: sure
agd5f: elbeardmorez: it may be an xserver thing depending on what version you're using
elbeardmorez: agd5f: the new driver doesn't work for me on 1.3, 1.499 or 1.5.99 rc2 (todays)
agd5f: elbeardmorez: on a secondary card? 6.8.0 or git or both?
elbeardmorez: agd5f: the new driver doesn't work for me on 1.3, 1.499 or 1.5.99.1 (todays)
elbeardmorez: adg5f: the last working set i had with r300 as secodary card was 1.3 and ..? ..fc8 stock
agd5f: elbeardmorez: I don't recall what fc8 shipped. not sure if it was 6.8.0 or 6.7.19x. If you are so inclined, you could bisect in git and see what broke it.
agd5f: unfortunately, I can't reporduce it here
elbeardmorez: agd5f: i'm just trying a few things here, I've switched primary display in my bios to AGP.. and booted.. the server crashes immediately as expected (it's trying to load nvidia glx etc) ..but then switching to vt1 and starting another xserver.. ..well it produces the same issue..
stefan1: Ahh int10 option. That'll solve it :-)
stefan1: agd5f: I wonder if the logic is wrong. man page says "default is on" but code shows default FALSE
stefan1: BRB
stefan1: Good, -ati git master works out of the box on my T60 again.
elbeardmorez: agd5f: ..I will try the bisecting git regarding the secondary card issue. Also, ignore my comment about the card giving the same problems when primary. I was looking the wrong logfile.
elbeardmorez: ..regarding logfiles.. learnt something new. start X with 'X' creates no log file by default now (i'm sure it used to).. also, gdm starts a default xserver but writes a log to /var/log/gdm/:x/log ..not the default place. ../var/log/Xorg.x.log must be written to only after you've logged into the dm.. ..difficult to keep track now.
elbeardmorez: also, as I mentioned, the reason for actually causing all these problems (upgrading xserver to git) was for a fix to xserver sharevts option. my testing shows this is not fixed. nobody answers on xorg channel.. ..could this be the driver though? If anybody cares to try and start a second xserver using -sharevts option does this new process go to 100% cpu load immediately and stay there?
elbeardmorez: suppose you'd need a dual card setup to test though.
elbeardmorez: the issue where killing an xserver on a radeon display would render the display useless is now fixed though (which is great! ..I can test without need to reboot everytime).
MostAwesomeDude: Arg, this is soo annoying.
MostAwesomeDude: Foxconn boards + Fedora 9 = intermittent freezes.
MostAwesomeDude: Just doing something like scaling the CPU causes a freeze.
MostAwesomeDude: Does anybody else have similar problems? Is there an IRC channel where we can complain about Foxconn?
agd5f: MostAwesomeDude: try scaling back your ram timings or bumping the ram voltage
MostAwesomeDude: agd5f: Will try. I did run the full memtest, and 40 minutes later, came back clean.
agd5f: MostAwesomeDude: lots boards tend to be picky about the ram. my DDR800 ram only works reliably at DDR667
MostAwesomeDude: agd5f: Well, this board runs just fine w/Windows, and a lot of Googling suggests that some of the chips on Foxconn boards might not be supported w/Linux.
surfer: just completed my gentoo reinstall... it took like 24 hours!
surfer: but now /home is encrypted
surfer: MAD: if ur trying to rule out ur memory and cpu... use mprime
surfer: if that doesn't crash for awhile then ur system is ok
MostAwesomeDude: Huh, Fedora finally booted.
MostAwesomeDude: Yay.
MostAwesomeDude: Let's see if I can log in now, lawl.
Ori_B: then look.
MostAwesomeDude: agd5f: Forcing RAM down to 533MHz and bumping voltage by 0.05 did the trick, I guess.
Ori_B: oops.
Ori_B: up-enter in wrong window.
mcgreg: will the future development of r500-mesa code go directly into master or will you continue to use the r500-support-branch?
adamk: I heard on here yesterday that the r500 branch is dead.l
MostAwesomeDude: mcgreg, adamk: airlied, agd5f, and I are all committing to master now.
MostAwesomeDude: I may start a new branch for r500-glsl, depending on whether or not we are on Gallium by then.
mcgreg: what does glsl stand for?
mattst88: graphics library shading language
mcgreg: thank you
stefan1: agd5f: int10 option fixed the BIOS reading problem for my T60/Mobility X1300
agd5f: stefan1: yeah. it's the default. you may have to rurn it off for secondary cards
stefan1: agd5f: well if I ever will graft another graphics card to this laptop then this will probably help :-)
MostAwesomeDude: XD @ grafting
stefan1: So currently the only problem left for me with r500 is a visual one: "tearing" at the right hand side of the laptop LCD when I move the mouse cursor a lot e.g. over a web page in Firefox with lots of links, i.e. mouse cursor changes and bottom status bar updates
surfer: any idea why my dpi is going crazy?
surfer: (**) RADEON(0): Display dimensions: (445, 278) mm
surfer: (**) RADEON(0): DPI set to (95, 146)
surfer: it should be ~ 96 x 96
surfer: then... when i check the actual one!
surfer: $ xdpyinfo | grep dimension dimensions: 1680x1050 pixels (433x271 millimeters)
stefan1: surfer: I think RandR takes over. My xdpyinfo shows the correct info:
stefan1: dimensions: 1400x1050 pixels (287x215 millimeters)
stefan1: resolution: 124x124 dots per inch
stefan1: surfer: try "xrandr --query --verbose"
stefan1: LVDS connected 1400x1050+0+0 (0x4e) normal (normal left inverted right x axis yaxis) 287mm x 215mm
surfer: lol
surfer: let me install it real fast
stefan1: That's what's reported by xdpyinfo for screen #0
surfer: DVI-1 connected 1680x1050+0+0 (0x4e) normal (normal left inverted right x axis y axis) 433mm x 271mm
stefan1: surfer: There you go :-)
surfer: there i go what?
stefan1: surfer: That's what you see in xdpyinfo
stefan1: surfer: and that's what counts
surfer: here's the thing
stefan1: surfer: Unless of course your monitor has a broken EDID
surfer: i'm setting display size to 445 278
surfer: but it's getting set to 433x271
surfer: which is
surfer: 99x98
surfer: not 96x96
stefan1: surfer: Uhhh I guess RandR or the driver throws your Monitor entry away
stefan1: surfer: you should see that in the X log
surfer: DVI-1 connected 1680x1050+0+0 (0x4e) normal (normal left inverted right x axis y axis) 433mm x 271mm
surfer: err
surfer: (**) RADEON(0): Display dimensions: (445, 278) mm
surfer: (**) RADEON(0): DPI set to (95, 146)
surfer: the math is wrong
stefan1: surfer: That DPI is not used. Look at the DPI from xdpyinfo
stefan1: surfer: xdpyinfo | fgrep -e dimension -e resolution
surfer: dude
surfer: let me break it down
surfer: i'm setting it to 96x96
surfer: but i'm getting 99x98
surfer: i dont care if the log says the right number
stefan1: surfer: Dude, your setting is *IGNORED*
surfer: it's giving me the wrong dpi
surfer: it shouldn't be
surfer: it should let me set whatever i want
stefan1: surfer: but it is
surfer: that's the problem
stefan1: surfer: and from the discussions I remember this has to do with RandR
stefan1: Maybe this helps:
stefan1: Option "IgnoreEDID" "boolean"
stefan1: Do not use EDID data for mode validation, but DDC is still used
stefan1: for monitor detection. This is different from NoDDC option.
agd5f: stefan1: that option doesn't help. it just ignores the edid from the monitor. you you want to overrride the display size, add DisplaySize xxx yyy to the monitor section associated with the output in question
agd5f: this didn't work properly on older xservers
surfer: just in case i tried it anyway
surfer: no change
surfer: the driver doesn't even mention that i used the option
surfer: not it's inused or anything at all
stefan1: surfer: agd5f xserver <1.5?
surfer: X.Org X Server 1.5.99.1
stefan1: surfer: Ah, you are from the future my friend :-)
agd5f: stefan1: 1.3 is broken. 1.4 should be ok IIRC
stefan1: X.Org X Server 1.4.99.901 (1.5.0 RC 1)
surfer: so?
surfer: if it says
surfer: my max image size is
surfer: 433 x 271
surfer: does that mean i can't set display size any higher?
agd5f: what says that?
surfer: cus the numbers i'm using used to work fine and i had exactly 96 dpi
surfer: the xorg.log
surfer: (II) RADEON(0): Max Image Size [cm]: horiz.: 43 vert.: 27
surfer: (II) RADEON(0): Gamma: 2.20
surfer: it says that too
agd5f: what does xrandr and xdpyinfo show?
surfer: which would be 430 x 270
stefan1: surfer: Did you set DisplaySize in the Monitor section, e.g. like this:
stefan1: # For radeonhd only - EDID fails...
stefan1: Section "Monitor"
stefan1: Identifier "PANEL"
stefan1: DisplaySize 287 215
stefan1: EndSection
surfer: agd5f: dimensions: 1680x1050 pixels (433x271 millimeters)
surfer: agd5f: resolution: 99x98 dots per inch
agd5f: surfer: looks good those are the numbers from your edid
surfer: agd5f: DVI-1 connected 1680x1050+0+0 (0x4e) normal (normal left inverted right x axis y axis) 433mm x 271mm
surfer: so does that mean i should just leave it at ~99 dpi instead of 96?
agd5f: surfer: if you want to change it add the DisplaySize option
stefan1: 1680x1050 pixels (433x271 millimeters) is 99x98 DPI
surfer: dude
agd5f: 433x271 is what your monitor claims it dimensions are
surfer: ohh forgot i changed who i was talking to
surfer: it's not using the dispaly size i set
surfer: that's the problem
agd5f: surfer: how did you set it?
surfer: $ grep DisplaySize /etc/X11/xorg.conf DisplaySize 445 278
surfer: in the Monitors section
agd5f: surfer: what output did you associated that monitor section with?
surfer: Section "Monitor" Identifier "Monitor0" VendorName "Samsung" ModelName "SyncMaster 205BW" HorizSync 31.4 - 80.0 VertRefresh 56.000 - 75.000
surfer: # Modeline "1680x1050" 146.25 1680 1784 1960 2240 1050 1053 1059 1089 DisplaySize 445 278 Option "DPMS" "true"
surfer: EndSection
surfer: Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0"
stefan1: surfer: in the Device section: Option "Monitor-DVI-1" "Monitor0"
agd5f: surfer: http://wiki.debian.org/XStrikeForce/HowToRandR12
agd5f: you can also change it on the fly with xrandr --fbmm 445x278
surfer: agd5f:
surfer: so i guess my problem is
surfer: why isn't it using the one in the config file?
surfer: when i do it by hand it works fine
surfer: shouldn't the driver call xrandr after reading my option?
surfer: screen #0: print screen: no dimensions: 1680x1050 pixels (445x278 millimeters) resolution: 96x96 dots per inch
agd5f: surfer: did you assocaited the monitor section with an output?
surfer: i don't get what u mean, Monitor0 is the one i'm using in my screen section
surfer: nevermind
surfer: let me check that web site real fast
surfer: before i ask again
agd5f: surfer: in the device section. you need to associate your monitor sections with an output since your card may have multiple outputs (DVI, VGA, etc.)
stefan1: surfer: Monitor is no longer set in Screen section
stefan1: agd5f: Good web page.
surfer: ahh
surfer: i will admit i have been using the same config file
surfer: for a long time
surfer: ththis seems important
surfer: (II) RADEON(0): Output DVI-1 has no monitor section
surfer: (II) RADEON(0): TMDS PLL from BIOS: 16500 a019a
surfer: (II) RADEON(0): I2C bus "DVI-1" initialized.
surfer: (II) RADEON(0): Output DVI-0 has no monitor section
surfer: (II) RADEON(0): TMDS PLL from BIOS: 16500 a019a
stefan1: surfer: Rename your Monitor section to "DVI-0" and it should use that as default for that output
surfer: ok
surfer: "Monitor-DVI-0"
surfer: ?
surfer: nm
surfer: u mean DVI-0
stefan1: No, just "DVI-0"
stefan1: Any other name and you have to use Option "Monitor-