happycube: also look @ radeon 9200 pci's?
happycube: (oops, out of context there)
happycube: "do some of your games not work? try this and enjoy" - tag for a gf2mx on ebay
DanaG: nvidia 96: *segfault*
hifi: ok, I want to try the IRQ patched kernel, does the patch apply to vanilla 2.6.32?
DanaG: Does 2.6.32 have IRQs, or were they way too late for 2.6.32?
agd5f: DanaG: too late
DanaG: hmm, will that and the powersavings thing in some form, end up in Linus's HEAD (heh) soonish? (Soonish as in, oh, a month.)
hifi: I'd like to build a kernel package with the patch
Nightwulf|work: hi all
DanaG: hmm, so will that powersavings code likely end up in 33?
soreau: You know better than to ask timing questions
soreau: It will get there when it's ready
Lutz_Ifer: oh, didn't know 2.6.32 was out
Nightwulf|work: is just compiling it :)
Nightwulf|work: hmm...first try with 2.6.32 wasn't very successful :-(
Nightwulf|work: before i had 22.214.171.124, built according to the radeonBuildHowto up and running with KMS and 3D accel on my hd3650
Nightwulf|work: with 2.6.32 KDM starts to bring up KDE and ends in KDM again...dmesg says this: http://pastebin.com/m2690b2a1
agd5f: Nightwulf|work: need newer mesa
agd5f: 7.6 branch or newer
Nightwulf|work: agd5f: penGL renderer string: Mesa DRI R600 (RV635 9598) 20090101 x86/MMX+/3DNow!+/SSE2 TCL DRI2
Nightwulf|work: OpenGL version string: 1.4 Mesa 7.6
Nightwulf|work: as i said, 3d accel (including kwin composite effects, although with artifacts) worked with 126.96.36.199 built as described in the howto
airlied: Nightwulf|work: need newr mesa
Nightwulf|work: airlied: this is what agd5f said already...but he said too, that i need 7.6 or up...and i have 7.6 ;-)
Nightwulf|work: so I need 7.7 branch?
airlied: not 7.6 release
airlied: 7.6 branch
Nightwulf|work: ah...should read properly ;-)
simplexe: airlied:http://upwap.ru/d/655336/0cd14590046dde9cf1d8dd8be8c49ee7/83478c49797311/%D1%81%D0%BA%D1%80%D0%B8%D0%BD2.jpeg - this bug already fixed?
MrCooper: agd5f: FWIW I think the problem with the X driver loading the kernel module with KMS was solved in the intel drivers
airlied: MrCooper: not really
airlied: MrCooper: we tried making radeon always load and it regressed some ums systems
airlied: intel didn't have that issue
Zajec: guys, could you try to help me with detecting start and end of modesetting in DRM?
Zajec: i posted mail on dri-devel@
airlied: Zajec: why detect end of modeset? just let the idle time kick it back
airlied: it looks like you mostly found start/end, crtc prepare/commit
airlied: dpms is separate as you noticed
airlied: but dpms is not modesetting
Zajec: airlied: when i do xrandr --output VGA --off, drm calls DPMS_OFF for crtc... and then may mean I have only 1 head now
Zajec: so i should try to resume PM
Zajec: but DPMS_OFF is also called in many other situations :/
Zajec: also by out prepare
Zajec: airlied: hm, so do you mean stopping PM on prepare and queue eventual resume right then?
Zajec: may work...
Zajec: but that's damn third work on queue :D
airlied: Zajec: pretty much
Zajec: i also think about improvement of encoders handling
Zajec: currently we disable already disabled encoders in every drm_disable_unused_functions
Zajec: if we would disable it only after disabling some output... could work
Zajec: airlied: ok, i'll try to implement your idea, shouldn't be so hard, just few lines of work_handler hopefully
Zajec: airlied: what delay should I use? how long modesetting usually takes?
airlied: Zajec: you could trigger it in commit
airlied: mjg59's code just took a mutex around modeset
Zajec: did it?
airlied: so the prepare/finish in atombios
Zajec: airlied: er, it still won't work...
Zajec: 1) on prepare I stop PM
Zajec: 2) on commit I start PM with delay
Zajec: 3) on xrandr X --off DPMS_OFF is called, so I should start PM with delay
Zajec: 4) radeon's prepare calls DPMS_OFF, which according to 3. would call start PM with delay
Zajec: I'll just do all in dpms_off
Zajec: should work
glisse: this PM scheme is too complex
glisse: there is no need to stop/start pm
MrCooper: airlied: so will your drm-radeon-next branch be rebased?
rehabdoll: im experiencing some screen corruption with my shiney new 4770 using the latest stable version of xf86-video-ati. are there any fixes in git?
taiu: rehabdoll: nope, that's unresolved afaik
taiu: although I think you can disable DownloadFromScreen which might help for now
eosie: may I use R300_CMD_PACKET3_CLEAR with KMS?
glisse: eosie: no
glisse: only true hw packet3
fabio: hi there
gabrimonfa: Hi all. I have a problem with dual head. With radeon driver my two displays start in cloning mode, instead of a big desktop. Using randr I can force them one to work. Using radeonhd driver all works. My xorg.conf is very simple. A virtual line is used to have dual head. How can I avoid to issue the randr command at each start with radeon?
mjr: I just use gnome which remembers the dual screen setup, but you can setup xrandr dual screen in xorg.conf too; don't recall the details
adamk: gabrimonfa, You need to have two monitor sections, one for each monitor, and use the RightOf or LeftOf option.
adamk: I'll show you my xorg.conf.
adamk: gabrimonfa, http://pastebin.com/m2a43f8d6
adamk: The Identifiers will, of course, have to be whatever xrandr detects them as.
gabrimonfa: adamk. Thx, but my xorg.conf is already quite the same. http://pastebin.com/m23c50370
gabrimonfa: I'm using radeon from git, a recent xserver and a r600 ati driver
gabrimonfa: using randr I'm able to get it work also with radeon. But at each start I've to reissue the command.
adamk: gabrimonfa, DVI-I_1/analog is not an identifier for the 'radeon' driver.
adamk: Nor is VGA_1, for that matter :-)
adamk: Check the output of 'xrandr' and see what the output names are. Those are what you have to use as identifiers.
gabrimonfa: These seems to be the identifiers of xrandr http://pastebin.com/d5dad62a6
adamk: You're not using the 'radeon' driver now, are you?
adamk: Can you pastebin your /var/log/Xorg.0.log file?
gabrimonfa: right now radeonhd
adamk: Well, yeah.
gabrimonfa: I'm lazy :)
adamk: You're not getting it.
adamk: For the placement to work properly with the radeon driver, you need to use the identifiers shown by xrandr while using the radeon drive.
adamk: radeonhd has it's own names for the ports on your video card.
gabrimonfa: adamk, ok. I've supposed that the identifiers would be the same.
gabrimonfa: adamk, thx. I'll try to start with radeon and use xrandr identifiers.
adamk: They will likely be VGA-0 and DVI-0
gabrimonfa: ok. I'll try
cire: I am using drm, mesa and xf86-video-ati from git master. Kernel is drm-next. I read at phoronix that the repositories would change. Is there a howto somewhere?
fabio: hi there
fabio: radeon is vry slow with EXA
mokoloko: Would kindly make quakelive work :)))))) Pleeeeeease
Luzipher: mokoloko: which chip ?
hifi: should work, I think
Luzipher: mokoloko: works perfectly on my 4870, I think it should work on yours too
mokoloko: it starts but menu doesn't show up
mokoloko: I can spectate but not join :(
Luzipher: mokoloko: hm, interesting ... do you use kms or ums and which mesa ?
mokoloko: kms and latest fedora packages
mokoloko: fedora 12
mokoloko: from koji buildsys
Luzipher: uh ... is that mesa 7.6 or 7.7 ?
Luzipher: don't know anything about fedora actually ;)
mokoloko: 7.6+ hellofalot backports so they should be pretty bleeding edge yet stable :)
Luzipher: hmm, well, then I don't have too much of an idea ... but it seems odd that spectating would work but not the menus ...
mokoloko: oh just noticed there's new mesa build :) gotta try it if it fixes things. Gotta love these weekly feature updates :P
Luzipher: good luck then :)
mokoloko: Luzipher: BTW how long it has worked for you?
Luzipher: at least 6 weeks ... probably even longer
Luzipher: mokoloko: I added Quake Live to the RadeonProgram wiki page on 2009-10-19 ... but I think it worked before that
tormod: on UMS what exactly causes the radeon drm module to be loaded?
mokoloko: It's weird that there's some "can't load menus" stuff from console after I updated from f11 to f12 and moved to free radeon drivers
MrCooper: tormod: X, or udev maybe
agd5f: tormod: the ddx
tormod: agd5f, where in the ddx
agd5f: tormod: might actually be the dri code in the server, don't recall off hand
tormod: agd5f, in that case, would the ddx tell the server to load "radeon"?
MrCooper: tormod: is there a particular issue you're getting at?
tormod: MrCooper, yes the background for my curiosity is that I try to see if there is a way to move that loading earlier, and wait for it to initialize _before_ checking for KMS
agd5f: tormod: one of the DRI* functions does it IIRC, but I can't seem to find it at the moment
tormod: what kind of call is it, so that I can look for it myself?
tormod: MrCooper, thanks
tormod: when do you want radeon to not load, if you use the radeon ddx?
MrCooper: tormod: src/radeon_dri.c: fd = drmOpen(RADEON_DRIVER_NAME, busId);
tormod: MrCooper, thanks again
tormod: MrCooper, when was that quote from? this channel?
MrCooper: yeah, earlier today
MrCooper: after I pointed out that the intel drivers supposedly solved this problem
tormod: yes intel somehow got this right
tormod: loading the module way before X starts is a workaround, but maybe you don't want to load that module sometimes
agd5f: well, you can still disable the dri via xorg.conf option
tormod: I meant sometimes in the sense of autodetected situations, not hand-tweaking
taiu1: can TXB be that easy - did i miss something http://cgit.freedesktop.org/~andrem/mesa/commit/?id=471a2f1e8f77ab28497a0c450210dff4b5e67368
tormod: but it's not a big problem, most people will want to probe and load radeon early to get KMS, for X or not
agd5f: taiu1: looks correct
tormod: I wonder if there is a way to wait for the radeon module to finish initialising before checking for KMS?
tormod: without getting stuck if radeon has not been loaded...
MrCooper: tormod: maybe the ioctl which queries for KMS could be delayed while KMS is being initialized
tormod: MrCooper, currently ddx is using libdrm, which agains looks up a sys file instead of any ioctl
tormod: drmCheckModesettingSupported just looks for the /sys/.../drm/configD* file
tormod: maybe there should have been a ioctl instead
Zajec: could someone try to review my PM?
mokoloko: It appears that that menu issue in quakelive with radeon is infact a fedora 12 issue so sorry for bothering and thanks for making it clear that it should work :)
mjt: hello. With 2.6.32 kernel, is CONFIG_STAGING needed for kms on radeon? The kconfig says "Enable modesetting on radeon by default" but the symbol is CONFIG_DRM_RADEON_KMS
agd5f: mjt: yes
mjt: agd5f: so it's just the kconfig text is misleading?
agd5f: mjt: misleading?
mjt: the symbol is DRM_RADEON_KMS, but the kconfig text is ""Enable modesetting on radeon by _default_ "
mjt: so by looking at the kconfig, one may think it's just the default value which gets changed
legume: mjt: DRM_RADEON_KMS just makes kms load on boot. I don't have it set and can choose ums/kms when I manually modprobe radeon
mjt: how it makes radeon load on boot?
mjt: who loads it? :)
mjt: oh, kms
mjt: so it should be s/load/enable/
legume: mjt: Yea - I guess, but my setup is a bit wierd so with that radeon would load at boot but without it doesn't.
mjt: hehe ok
spreeuw_: hey 2.6.32 release
spreeuw: hey 2.6.32 release
Jonimus: Hey I have a laptop with an mobility Radeon HD4670, I am running kernel version 2.6.32-rc8 and I have mesa and xf86-video-ati installed from git yet Hardware accel is not working
Jonimus: KMS is so I don't get why glxinfo is saying its using the software 3d
Jonimus: my dmesg says nothing about having issues
agd5f: Jonimus: you need mesa for 3D
Jonimus: I ave mesa installed from
Jonimus: both Mesa and xf86-video-ati are from git
BioTube: Jonimus: did you rebuild a git libdrm>
Jonimus: yes, but I'll rebuild it again just to check
soreau: Jonimus: You need to build libdrm with --enable-experimental-api then mesa and ddx against that libdrm
Jonimus: hmm ok, I know it was working before, is the --enable-exprimental-api thing new?
Jonimus: yeah its there
Jonimus: I'll try rebuilding libdrm and mesa and see if it helps
_moep_: hey should it possible to play openarena atm?
simplexe1: with r300, gimp show artefact's, like as on this screenshot http://pixs.ru/showimage/bagpng_1894936_368348.png
simplexe1: any ideas?
blathijs: agd5f: I take it you changed your mind on the merits of the patch on #22140 (e.g., you realized it wouldn't work)?
Jonimus: Ok I rebuilt both mesa and libdrm I'll reboot and see if it starts working
agd5f: blathijs: yeah, I read the macro, and it worked differently than I remembered
blathijs: Hehe, it's not really obvious. I read it the other way the first time as well :-)
Jonimus: hmm ok I rebuilt them both and still nothing
Jonimus: glxinfo still says I'm using the software rasterizer
blathijs: agd5f: I've also tried printing the registry values after setting them, but it seems they need some time to get updated.
BioTube: Jonimus: you're part of the video group, correct?
agd5f: blathijs: you might have to waitforfifo before reading them back
Jonimus: hmm I'll check but I should be
Jonimus: yup I am
blathijs: agd5f: Would it hurt to do that in legacy_crtc_dmps (or whatever the function is called)?
agd5f: blathijs: I don't think it will make a difference. I suspect the problem is vblank related
blathijs: agd5f: Care to expand on that? I'm pretty clueless as to (X) driver programming, but I have a fair amount of low-level experience :-)
Jonimus: hmm I updated ati-dri to the git branch also and will try again, I just wish I knew what the issue was :(
agd5f: blathijs: messing with vblanks when the crtc isn't enabled can cause a hang
cxo: drm-radeon-testing no longer merges with Linus' tree
Jonimus: hmm still nothing
agd5f: blathijs: your best bet is to migrate to kms :)
Jonimus: would posting my xorg.0.log help you guys figure out what was wrong?
simplexe1: any help please
blathijs: agd5f: Well, with just this change reverted things work well enough for now, and finding out how KMS should work is something for later :-)
blathijs: agd5f: Is the non-KMS way of modeswitching going to be completely removed in the near-future? Isn't there going to be any more work on it?
Jonimus: hmm I'm out of idea's there is no reason I should be getting software 3d accell when KMS is working and this many packages from git
agd5f: blathijs: eventually. mostly it's in maintainence mode at this point
Jonimus: there is my xorg.0.log according to that I should have working 3d...
Jonimus: any Idea's anyone??
Jonimus: should I try without an xorg.conf?
adamk_: That shows direct rendering as enabled.
adamk_: Pastebin the output of 'LIBGL_DEBUG=verbose glxinfo'
Jonimus: there is is
Jonimus: hmm now it says its working
Jonimus: but compositing still isn't
Jonimus: well thanks for the help then...
Jonimus: thats odd that compositing is still broken
adamk_: Well exactly how is compositing broken?
Jonimus: nvm I found it
Jonimus: It seems it somehow got disabled in my XFWM config
Jonimus: now everything is working, I guess rebuilding everything fixed it
spstarr: agd5f: the interrupt stuff works, there is stalls though, but it works with KMS
agd5f: spstarr: it only works with kms
spstarr: agd5f: oh :)
spstarr: agd5f: is that merged into drm-next/drm-radeon-testing stuff?
spstarr: or still in churn
agd5f: spstarr: it's merged
spstarr: ok i can drop that patch from my local trees
airlied: MrCooper: not planning on rebasing drm-radeon-next, but I don't think anyone should be downstream of it
airlied: i.e. using a git tree downstream and asking me to pull it
Kurko: where I can found interrupt patch?
jcristau: Kurko: on the dri-devel list
Jonimus: is there DynamicPM for the RV7xx chips yet?
Jonimus: ahh nvm
hagabaka: 2.6.32 kernel is nice
hagabaka: all the problems with frame buffer or compositing seem to be gone for me
eosie: please, could you possibly answer this question? it's not explicitly stated in the r5xx docs... is it true that fastfill must be enabled for the RB3D_COLOR_CLEAR_VALUE reg to be used by the hw?
MostAwesomeDude: That's a good question.
slide: I have an ATI Radeon Express 200M on my laptop. I want to have 1920x1080 on the VGA output to my TV but its giving me a max resolution of 1024x768, can anyone help me get it higher? I know its possible because I've done it before in Ubuntu
slide: It was on an Karmic beta that had been upgraded from Jaunty
BioTube: slide: have you fed xrandr the desired mode?
slide: hrm didnt know I could
BioTube: use the modeline cvt generates and feed to xrandr --new-mode
BioTube: a terminal program
slide: xrandr --new-mode VGA-0 Modeline "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync
slide: or remove the VGA-0 beforehand?
BioTube: I think you also need to take off 'Modeline'
slide: oh I use addmode
slide: ah ok sweet that got it to work :)
slide: now to document that so if this goes away i can get it back later hehe
slide: also though, whenever i try to run XBMC it says there is no hardware gl support
ivanx: hi all
ivanx: I'm experiencing a hard system lockup with a black screen when I try to run glxgears; this is with kernel 2.6.32 (kms enabled), mesa 7.6 and xf86-video-ati 6.12.99
airlied: eosie: when else would it be used?
ivanx: the gpu is an onboard HD 3200
eosie: airlied: I read it as "yes"
ivanx: the kernel modesetting seems to work just fine, but whenever I try to run a 3D program, the system just locks up and the screen goes black; anyone have any ideas?
eosie: airlied: it states that COLOR_CLEAR_VALUE is used if only COLOR_CHANNEL_MASK is 0, fastfill is not mentioned
airlied: oh wierd if the chan mask was 0 I expected nothing to render
eosie: me too
eosie: and because this statement doesn't make sense on its own, I am guessing fastfill is involved somehow
agd5f: airlied: so I have hpd implemented, but I'm having trouble find a good spot to put the init/fini() code since it relies on having the connector/encoder info available
airlied: agd5f: can you do it in the irq init?
agd5f: airlied: I need the connector info to know which hpds to enable
agd5f: and we don;t get the connector info until after device init
airlied: radeon_irq_kms_init should be well after that
airlied: oh it doesn't
airlied: it'll have to be after modeset init then
Zajec: guys, I rarely get answers from you on dri-devel@
Zajec: could you check it for my engine patch, please?
amarks: dintel ssd firmware AHCI
Telek: Hey something I've been wondering: Is the new HD4200(?) integrated graphics core-complete enough to handle OpenCL/AMD Stream?
glisse: Zajec: i replied to your patch
Zajec: glisse: ...
Zajec: glisse: yeah
Zajec: glisse: i'm slowly getting tired
Zajec: glisse: too many details about that whole PM
airlied: Zajec: we said it wasn't simple problem when you started
Luzipher: agd5f: don't know if you remember my question from yesterday - but FYI: it is possible to add the new firmware directly to the kernel, there is an Option in "Device Drivers -> General Options"
Zajec: airlied: yes, you did :)
agd5f: Luzipher: it's the license
airlied: Luzipher: you can do it yourself alright
airlied: there is a kernel option to add out of tree firmware to the kernel build
Luzipher: agd5f: yes, but that's not important for manually creating a kernel :)
glisse: Zajec: you already have the hardest piece
Zajec: glisse: :)
glisse: you can do a simple patch which doesn't care about the mutex/lock
Luzipher: yup, I just did that after messing around with an initramfs and more or less failing miserably ... (is it possible to build radeon into the kernel (no module) and have the firmware in the initramfs ?)
airlied: Luzipher: you don't need to do that
airlied: it won't work though
Luzipher: airlied: hmm, if it won't work ... what good is it then ? :)
airlied: there is another option to build the firmware into the kernel
airlied: External firmware blobs to build into the kernel binary
Luzipher: yes, I just did that ... actually I'm running on that ... I basically just wanted to report that cause I thought there wasn't such an option from the answer yesterday
Luzipher: but that building in of the firmware is absolutely needed if building radeon into the kernel and not as module, right ?
Luzipher: ok, thanks :)
kdeman: Telek: RV770-based best bet.
Telek: kdeman: Well is the chip 770 based or not? I've seen it reported to support DX 10.1 but the core config is the same as a Radeon 2400?
Telek: Nevermind :)
agd5f: airlied: just sent an rs600 fix to dri-devel. should probably go to 2.6.32.x
naki35366: good evening all
naki35366: pse can anyone help me ? i've a problem with my radeon x300 with ubuntu karmic settings...
kdeman: TeleK: anything RV7xx/R700 is what you'll want to use.
naki35366: it doesn't use high resolution anymore
naki35366: just only low-graphic mode
naki35366: it seems to be a trouble with the kernel mode setting in the boot phase, i think....
naki35366: pse help me!
naki35366: pse can anyone help me ? i've a problem with my radeon x300 with ubuntu karmic settings..
jcristau: agd5f, airlied: how likely is an abi break of libdrm_radeon at this point? trying to decide whether to enable it in 2.4.16
agd5f: jcristau: not likely
agd5f: at this point we are mostly just waiting for radeon to come out of staging
jcristau: right. thanks for the confirmation :)
Ralesk: hmmm... I have 2.6.32~rc8 at the moment, and can't get the native resolution console to work. Or compositing (KDE claims I don't have XDamage or Xcomposite, but I do, and according to Xorg.log, dri2 did load)
Travis1: having so many problems with my Radeon card...
scarabeus: okey something is wrongie
scarabeus: OpenGL renderer string: Software Rasterizer
Travis1: is there anyone out there that could help?
scarabeus: anyone has idea how i can force it to use R600 code
scarabeus: mesa from head, same for libdrm, xorg is 1.7.3 and kernel is .32
scarabeus: nothing in log indicating that it should not work
Zajec: scarabeus: R600 is used by default if available
scarabeus: it is built in mesa
Zajec: scarabeus: pastebin output of
Zajec: LIBGL_DEBUG=verbose glxinfo
[Enrico]: scarabeus: xf86-video-ati from git ?
scarabeus: [Enrico]: i wrote those ebuild so yes its from git ;]
[Enrico]: just to be sure :D
kdeman: Travis1: see if your glxinfo reports "2.1 Mesa 7.x ..direct rendering"
Zajec: scarabeus: what is your kernelkl
kdeman: Your mileage may vary.
scarabeus: Zajec: .32
Telek: scarabeus: Sure you've got dri2proto installed, as well as a 2.6.32 or higher drm module?
scarabeus: i think i has suspect
Zajec: permission denied?
Zajec: didn't see that ever
scarabeus: 106 Section "DRI"
scarabeus: 107 Mode 0666
scarabeus: 108 EndSection
scarabeus: me neither
scarabeus: it should work
Zajec: it's definitely a reason, but I can not help you with that
scarabeus: Zajec: i will try to debug it
scarabeus: also i wonder why it was not shown in previous pass when i ran the exact command
scarabeus: Zajec: thanks anyway
scarabeus: there it is
scarabeus: sys-util/glibc compiled with patch-2.6
scarabeus: thus no patches were applied
scarabeus: vanila glib is useless
scarabeus: tumdudum here goes recompiling whole system :/
Travis1: ok so I followed https://help.ubuntu.com/community/RadeonHD and ended up with a blank screen... :(
Zajec: sleeping mode :)
spstarr: what exactly is the issue
Travis1: http://pastebin.com/m67db43f8 that is my current xorg.conf file... something's very not right with 2 drivers right?
chithead: you don't need any xorg.conf at all
chithead: and this xorg.conf seems to be generated by the proprietary driver's application
Travis1: I've already tried booting without the xorg.conf and I got a blank screen on OS load.
Travis1: so I had to reboot in recovery mode and restore the xorg.conf
ikus060: Hello, I'm using the defalut available driver present in Karmic. Is there any better driver that deliver more performance ?
ikus060: I my case, the laptop is almost unusable if something tiny is moving in the screen
Ralesk: hmmmmm... airlied -- I tried your modesetting testing thing you wrote on LJ, I don't see anything bad in the dmesg, yet I don't get a shiny console with tiny letters...
airlied: Ralesk: wierd someone wrote a follow up patch in the comments maybe that'll help
airlied: also make sure fbcon is loaded
Ralesk: (I also just noticed that post is from a year ago, i didn't know the technology is that old :))
Ralesk: ahhhhhhhhh, fbcon was missing :D
Ralesk: there we go, one problem solved :)
Ralesk: nothing like a 210x65 console
Ralesk: now to figure out why kde doesn't like me
Ralesk: hmmm. well, compositing refuses to work on the radeon, works decently with what I believe to be the same files on the intel machine; both are capable of KMS and sexy host hi-res consoles :) what could be wrong?
airlied: Ralesk: refuses how?
Ralesk: KDE complains about compositing not being available when I turn the feature on.
BioTube: Ralesk: using XRender or OpenGL?
Ralesk: while the setting was on (just temporarily disabled) it was telling me something about XComposite and XDamage missing -- but they're very well present.
Ralesk: GL. but neither work actually.
airlied: glxinfo show direct rendeirng?
Ralesk: after the ramdac phase, xorg.log tells me: (II) RADEON(0): GPU accel not working, using shadowfb for KMS
airlied: Ralesk: pastebin the full dmesg and Xorg.0.log
Ralesk: one sec
Ralesk: my dmesg seems to be full of junk, but that might help, actually: http://xorg.pastebin.com/d28c60818
BioTube: is that everything?
airlied: you seem to have drm.debug=1 enabled
airlied: which sorta makes log crappy
BioTube: especially if the ring buffer gets filled
Ralesk: ah, yes, forgot that.
Ralesk: will do a reboot and get a clean file
Ralesk: http://xorg.pastebin.com/d362553cf is my xorglog
BioTube: (WW) RADEON(0): Direct rendering disabled
Ralesk: yeah, little above it is the line I wrote about shadowfb... wonder what's wrong.
BioTube: which distro do you use?
airlied: either too old -ati or accel fail in the kernel
Ralesk: hmm, I have one that I built from git da1fcddaa
Ralesk: since 6.12.4 is way too old for this, I'll see if I can build something newer from git. master as it stands now, is usable?
airlied: should be
Ralesk: when do you think the next release will be? :)
airlied: when we think KMS is stabilised
Ralesk: hmm, current master is best at crashing everything, actually :)
Ralesk: I have a non-blinking text cursor in the top-left corner, and empty screen, and SysRq-REIKSUB is the only thing that seems to work
airlied: post xorg log from it
airlied: agd5f: that polygon stipple patch seems wrong
airlied: Ralesk: try booting with radeon.agpmode=-1
Ralesk: any way to see if it took the setting? (I'm loading the module later on from a script for now, trying to make sure if the option was accepted)
airlied: oh add it to the module load line then
Ralesk: yeah, that's what I did
Ralesk: but... according to modinfo, -1 is PCI, and I *do* have an AGP card
airlied: yeah its a test
BioTube: AGP cards can be run like PCI ones
airlied: though the dmesg might still be most useful
BioTube: gets around some of the quirks
Ralesk: locks up just the same -- I can ssh in though, so let's fetch those files...
Ralesk: http://xorg.pastebin.com/d525e954a my dmesg now
Ralesk: the Xorg log looks the same, stops at exa
airlied: Ralesk: wierd dmesg looks okay
Ralesk: should I try with XAA?
airlied: XAA under KMS doesn't do anything
airlied: booting same stuff without modeseting work okay?
airlied: you can try adding Option "AccelDFS" "FALSE" to xorg.conf
Ralesk: same effect as saying nomodeset?
airlied: two tests, one nomodeset, second AccelDFS
airlied: try dfs first maybe
Ralesk: okay, gotcha, doing DFS
Ralesk: not accelerating DFS doesn't help
airlied: does the log report it not accelerating? (me hope we check the value ;-)
Ralesk: it just noted that it read that value from the config, pretty much
Ralesk: (**) RADEON(0): Option "AccelDFS" "False"
Ralesk: nomodeset makes things work
Ralesk: except turning on compositing makes things crash :D
Ralesk: this is the only thing I see that feels relevant, it's in kdm.log:
Ralesk: File radeon_dma.c function radeonReleaseDmaRegions line 348
Ralesk: Leaking dma buffer object!
Ralesk: X: radeon_bo_legacy.c:207: legacy_is_pending: Assertion `bo_legacy->is_pending <= bo->cref' failed.
Ralesk: and then, new session started
Ralesk: huh.... it started up just fine with compositing on now... nothing changed :P
Ralesk: there's just garbage in the last row and the last column of the screen
Ralesk: ha! opening a window creashed it :D
lmurray: What revision was the R300 version string changed?
lmurray: It completely broke the KWin blacklist detection. :< Just trying to find the first R300 version that actually works with compositing
tavl: anyone can help here? "syntax error near unexpected token `XINERAMA," (while trying to build xf86-video-ati, from GIT)
Ralesk: tavl: hmm, I just built the freshest commit from the master branch and had no such problems o.o
tavl: I think i forgot a dependency... i'll take a look
dli: 2.6.32 kernel, (II) RADEON(0): GPU accel not working, using shadowfb for KMS
Ralesk: dli: I just had that with a driver that wasn't fresh enough.
Ralesk: but for me, the master branch's latest commit makes things crash a lot when I turn on compositing
Ralesk: airlied: thanks for the help, I'll try to see if other stuff can/should be upgraded to make it work tomorrow.
airlied: ralesk: what mesa you running?
Ghworg: Ooh, new libdrm release on its way into debian. Yay!
kyrogenic: anyone got a Thinkpad W500 ??
airlied: kyrogenic: I know someone with one
kyrogenic: airlied: really??
airlied: yeah I tested some stuff on it a week or two ago
kyrogenic: airlied: are they running gentoo linux?
kyrogenic: airlied: I remember coming across 1-3 people i here running gentoo REAAALY smoothly on the w500 and I wanted to compare kernel configuration + general configuration because my machine is probably running at 65% efficiency/potential
airlied: no it was Fedora
kyrogenic: ah man
kyrogenic: that sucks
hagabaka: does anyone have experience with running adobe flash or air on radeon 9800?
airlied: Travis1: okay as root apt-get install git
Travis1: I've aleady installed git I believe
Travis1: I can do it again
airlied: okay git clone git://git.freedesktop.org/git/xorg/driver/xf86-video-ati
airlied: cd xf86-video-ati; sh autogen.sh --prefix=/usr
airlied: then make
Travis1: travis@travis-laptop:~/xf86-video-ati$ make
Travis1: make: *** No targets specified and no makefile found. Stop.
airlied: did the autogen.sh work?
Travis1: umm maybe not...
Travis1: checking for XORG... configure: error: Package requirements (xorg-server >= 1.2 xproto fontsproto xineramaproto randrproto renderproto videoproto xextproto) were not met:
Travis1: No package 'xineramaproto' found
Travis1: Consider adjusting the PKG_CONFIG_PATH environment variable if you
Travis1: installed software in a non-standard prefix.
Travis1: Alternatively, you may set the environment variables XORG_CFLAGS
Travis1: and XORG_LIBS to avoid the need to call pkg-config.
Travis1: See the pkg-config man page for more details.
airlied: apt-get build-dep xserver-xorg-video-ati
Travis1: ok I'll try that code
Travis1: yeah seems like that one worked..
airlied: okay I just need to write a quick patch now
Travis1: ok sure. so that autogen.sh didn't seem to work, will I need to do that again, or is that what you're writing the patch for?
airlied: no it should have wroked after the apt-get
airlied: so try it again now
Travis1: oh ok cool I'll try now
Travis1: yeah done
Travis1: there were some warnings about pointers that came up.. nothing to worry about?
airlied: okay apt-get install patch wget
airlied: wget http://people.freedesktop.org/~airlied/scratch/test-patch | patch -p1 -
Travis1: wget is already the newest version.
Travis1: The following packages were automatically installed and are no longer required:
Travis1: Use 'apt-get autoremove' to remove them.
Travis1: 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
airlied: oops not that ;-) line
airlied: wget http://people.freedesktop.org/~airlied/scratch/test-patch
airlied: patch -p1 < test-patch
airlied: from the xf86-video-ati dir
Travis1: so just enter:
Travis1: wget http://people.freedesktop.org/~airlied/scratch/test-patch
airlied: make ; make instal
airlied: install even
Travis1: did I still need to be in the /xf86-vide etc folder?
tavl: airlied: i'm trying to build the latest xserver, but it seems to need libgl... any idea where i get it? error msg: "checking for GL... configure: error: Package requirements (glproto >= 1.4.9 gl >= 7.1.0) were not met"
airlied: tavl: mesa
tavl: airlied, just install mesa first?
Travis1: travis@travis-laptop:~/xf86-video-ati$ sudo make ; make install
Travis1: Making all in src
Travis1: Making all in man
Travis1: Making install in src
Travis1: /bin/bash /home/travis/xf86-video-ati/./shave-libtool '/bin/bash ../libtool' --mode=install /usr/bin/install -c ati_drv.la '/usr/lib/xorg/modules/drivers'
Travis1: /usr/bin/install: cannot remove `/usr/lib/xorg/modules/drivers/ati_drv.so': Permission denied
airlied: tavl: yup I think so
Travis1: make: *** [install-ati_drv_laLTLIBRARIES] Error 1
Travis1: make: *** [install-am] Error 2
Travis1: make: *** [install-recursive] Error 1
airlied: Travis1: sudo make install
airlied: okay now try and start X with no xorg.conf
airlied: and get me the log if it works or doesn't
Travis1: ok sure thing. should I try without the attached screen?
Travis1: or doesn't it matter?
airlied: doesn't matter
Travis1: ok. Back in a sec
Travis1: Xorg.0.log = http://pastebin.com/m74f7ba2b
Travis1: Xorg.0.log.old = http://pastebin.com/m48891ff7
airlied: wierd it didn't seem to use the driver we just installed
airlied: or the patch didn't apply or somerthing
airlied: run git diff in the xf86-video-ati dir and make sure the output contains the patch
Travis1: next steps?
Travis1: where is the output?
airlied: when you run git diff it should show something
airlied: if it didn't then you need to apply the patch
airlied: patch -p1 < test-patch
Travis1: nothing happened
Travis1: so I type "patch -p1 < test-patch"
airlied: if the file test-patch is in that dir yees
Travis1: travis@travis-laptop:~/xf86-video-ati$ patch -p1 < test-patch
Travis1: patching file src/radeon_driver.c
Travis1: Hunk #1 succeeded at 1396 (offset 1 line).
airlied: okay now run sudo make, sudo make install
Travis1: ok done
airlied: now try to start X and get the logs
Travis1: ok I'm gonna have to do that in a couple of hours. I'm still at work and I can't keep justifying resetting my comp.. haha
airlied: Travis1: leave the logs linkns in here I might not be connected later
Travis1: ok sure. Hopefully there will be another with the knowhow and patience to give me a hand.