Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-11-04

Search This Log:

bryce_: agd5f, would you mind taking a look at bug 24889? We're getting a number of bug reports similar to this, but it's the most complete I've seen so far.
bryce_: it seems not to be the usual "monitor has broken edid" issue
Nightwulf|work: hi all
hagabaka: hi, I'm using ubuntu karmic, and I used its "x-edgers" ppa to enable KMS for radeon. it worked after I rebooted the first time, although there were some X server crashes. but after the second reboot, I got flashing horizontal lines on the screen, more visible to the right side
hagabaka: the lines start appearing as early as the start up messages, and continue in the console or X, but don't appear in BIOS settings or grub menu. I was able to change the refresh rate in X once, and that fixed the flashing, but after restarting it appeared again, and now when I try to change display settings, X server just restarts
hagabaka: I can switch to 800x600, and the flashing disappears, but if I switch back to the native resolution 1024x768, x server restarts...
airlied: happycube: generally if you get a state emit with no vertex data queued you should do nothing
airlied: unless gallium works different
happycube: yeah... r300g doesn't have any other routine that's triggering emitting the vertex coordinates atm ;)
happycube: MostAwesomeDude: can you look over the new changes in http://pastebin.com/m3c5d4da1 ?
mfwitten: I need to know: Is the crappy graphics performance I get due to crappy hardware (Radeon Mobility X600) or due to (currently) incomplete/crappy open source drivers?
mfwitten: Glest and glob2 destroy my system, which seems unreasonable
mfwitten: There is, of course, some texture bug that keeps warsow and sauerbraten from running smoothly, but it seems like it could be really smooth
muep__: glob2 has never worked fine for me
mfwitten: oh?
muep__: usually I have found it a least a bit sluggish
muep__: but haven't tried it in a long while
mfwitten: indeed
glisse: mfwitten: the driver is far from using the hw fully
UninfrmdLuddite: i ahve a 4850 512mb and i cannot get it to run with mandrake cooker at all
UninfrmdLuddite: im practically going to go out and buy an nvidia
mfwitten: glisse: OK. That's all I needed to know
soreau: UninfrmdLuddite: See the wiki link in the topic
soreau: You will need the latest kernel, probably drm-next, libdrm, mesa and ddx from git
honk: UninfrmdLuddite: great for you ;)
UninfrmdLuddite: you know honk theres usually people on freenode that are helpful. I guess your niclk expressed your intelligence
UninfrmdLuddite: the sound of a goose
UninfrmdLuddite: soreau: i have tried all that it just white screens
honk: UninfrmdLuddite: you might wanna ask a question instead of simply stating that it's broken ;)
UninfrmdLuddite: am currently updating my cooker to the official release and shall try again
twnqx: if i could choose
twnqx: i'd go the nvidia path
twnqx: but somehow the manufacturers of decent laptops put ati in -_-
soreau: UninfrmdLuddite: Can you pastebin the X log from the failed session?
soreau: honk: There is no reason to be cynical
UninfrmdLuddite: i can but there are 568 p[ackages upgrading at the moment through my wireless connection so will be in a while
soreau: twnqx: and you are not helping
twnqx: i asked several times if theres a way to debug a full kernel hang
soreau: UninfrmdLuddite: I will probably be gone by then, but if you can paste a log maybe someone will get to you
twnqx: or what is taking up 100% cpu if i just run X & xdpyinfo
twnqx: with absolutely nothing in a logverbose 7 X log or in dmesg
UninfrmdLuddite: theres 180 packages to go so it will be a while. then i have to cook dinner
soreau: twnqx: You probably have some component causing the trouble you need to update. Are you using drm-next?
twnqx: no, i have a policy against RC kernels
twnqx: i'm using 2.6.31.y + patch as per topic
soreau: That is drm-next
twnqx: good. X 1.7.1, git ddx, git mesa, git libdrm
twnqx: (al of them 3 days old now)
UninfrmdLuddite: is it possible to run both n nvidia card and a radeon in a xfire motherboard? or is that just asking for trouble?
twnqx: and slowed down dramatically from stable
twnqx: like, xv is getting me ~2fps now
soreau: Try updating and rebuilding all of those components starting with libdrm
twnqx: UninfrmdLuddite: you can run it, but you'll have to separate graphics cards, no SLI/crossfire
twnqx: two*
soreau: UninfrmdLuddite: Not possible with current implementations
twnqx: yeah well, GL will suffer i guess
twnqx: so, DRM->X->mesa -> DDX?
soreau: that should work
UninfrmdLuddite: i suppose i have put so many hours into it now if i bought an nvidia it would be like surrendering and that's just not right
twnqx: pfff
twnqx: it took me two days two rule out bugs in pam_mount, udev and entrance so i could just log in to my laptop
twnqx: giving up after a few hours is losing
UninfrmdLuddite: its more than a few
twnqx: soreau: did i mention it only happens with KMS enabled?
twnqx: on an RV635?
soreau: twnqx: No, but you should update and recompile nonetheless
twnqx: just doing that
soreau: If the problem persists, file a bug
twnqx: i hope 2.6.32 comes soon
twnqx: if i had a single working version i'd do a git bisect
twnqx: right....
twnqx: turns daring
twnqx: yeah... no.
twnqx: KMS enabled, X stalls at 100% load after like 2s, can only be killed with SIGKILL, radeon module is still locked after it, console can't be used
twnqx: X also can't be restarted, only random artefacts on the screen
taiu: twnqx: there's some patches in dri list which will probably help
glisse: UninfrmdLuddite: consider testing this livecd http://adamwill.fedorapeople.org/radeon-20091102-x86_64.iso
glisse: if it works with it than ubuntu is just missing the lastest software/fixes
glisse: twnqx: likely same iso worth testing for you too
twnqx: glisse: gonna give it a try, even though i'm now on minutes old git (except kernel)
twnqx: also seems to be related to e17 fading out the menu bar
twnqx: which might go all the way to negative coordinates, dunno how it's implemented
hoo-hah: hi guys, is gallium too experimental to test out? I've got a hd4850
MrCooper: no Gallium driver for that card yet
hoo-hah: oh
eosie: MostAwesomeDude, zhasha: http://storm.unas.cz/eosie-11-04.tar.gz - please review/push, especially the patch 0004 needs review
Kano: airlied: what is needed for autogen for fedora x64 with /usr/lib64?
glisse: Kano: --libdir=/usr/lib64
Kano: just found it, but thx
Kano: stop prefdm;start prefdm
Kano: is the correct way to restart X?
glisse: Kano: it's mostly distro specifique
glisse: init 3
glisse: should shut it down properly
twnqx: hm
twnqx: that new local privilege escalation exploit for kernes < 2.6.32 makes it more likely that i'll upgrade soon...
Kano: glisse: is there are generic option to enable modesetting drivers
Kano: for intel+radeon?
glisse: Kano: what you mean ?
glisse: at compile time ?
Kano: glisse: yes
glisse: no generic option
Kano: i dont find in the wiki how to build/install drm modules only from a kernel tree
glisse: can't do that easily
glisse: Kano: best is to build full kernel
Kano: not possible, live image
jdizzle_: agd5f: fwiw I tried enabling acceldfs (both with and without migrationhueristic greedy), and performance was much worse
uzi18: have problem with firmware loading for radeon in initrd
uzi18: from dmesg: firmware radeon_cp.0: firmware_loading_store: vmap() failed
uzi18: firmware radeon/RV770_me.bin
uzi18: any help ?
uzi18: kernel 2.6.32 rc6
ferr: :P
ferr: make kpkg is running for me:)
ferr: but have also radeon
roysjosh: hagabaka, a few people are having similar issues - see my bug at https://bugs.freedesktop.org/show_bug.cgi?id=19960 (especially the video I took of my screen) and see if the problem looks similar to yours
agd5f: hagabaka: you need a newer drm. drm-next or 2.6.32
Kano: agd5f: is 2.6.32 available als live image
agd5f: Kano: depends on the distro
Kano: tell me one
agd5f: Kano: I don't know off hand which ones provide it
Kano: so fedora does not
agd5f: Kano: might
Kano: i worte some debug scripts to compile altest ddx for intel/ati but the drm is not working. so best i need a live image with latest kernel
glisse: Fedora is 2.6.31 but when it comes to drm i think we got all the lastest bit and even more bits than 2.6.32
kdekorte: Kano, fedora has nightly builds that have VERY recent drm code
Kano: kdekorte: it just did not work
Kano: i need not only newer radeon but also intel drm
kdekorte: can you explain what you mean by "did not work"
glisse: Kano: what i said apply to nouveau,intel,radeon
Kano: did the kernel change in the last 2 days?
Kano: kdekorte: agpgart error in dmesg
kdekorte: Can you be more specific, like actually posting the message
uzi18: agd5f: have problem with insmod radeon ;/
uzi18: agd5f: dmesg complaining me about problem with firmware loading - any sollution?
agd5f: uzi18: make sure you have the firmware available
adamk_: Is the firmware installed?
cxo: Hey I just built 2.6.32-rc6 for my laptop, andi built drm and radeon into the kernel, but it only switches to a native resolution long ways into init unlike my other box that switches resolution immediately after grub
uzi18: agd5f:
uzi18: /var/log/dmesg.4:platform radeon_cp.0: firmware: requesting radeon/RV770_pfp.bin
uzi18: /var/log/dmesg.4:platform radeon_cp.0: firmware: requesting radeon/RV770_me.bin
uzi18: /var/log/dmesg.4:firmware radeon_cp.0: firmware_loading_store: vmap() failed
uzi18: /var/log/dmesg.4:r600_cp: Failed to load firmware "radeon/RV770_me.bin"
uzi18: /var/log/dmesg.4:[drm:radeon_driver_load_kms] *ERROR* Fatal error while trying to initialize radeon.
agd5f: cxo: depends on when the module gets loaded
cxo: agd5f, but its built into the kernel
cxo: uzi18, are you on ubuntu?
agd5f: uzi18: did you build the ucode into your kernel?
cxo: there is a bit of wonky behaviour in mkinitramfs on ubuntu
uzi18: [root@uzi tmp]# ls -l initrd.TXSajY/lib/firmware/radeon/RV77*
uzi18: -rw-r--r-- 1 root root 5440 Nov 4 15:54 initrd.TXSajY/lib/firmware/radeon/RV770_me.bin
uzi18: -rw-r--r-- 1 root root 3392 Nov 4 15:54 initrd.TXSajY/lib/firmware/radeon/RV770_pfp.bin
agd5f: uzi18: sounds like a local issue
uzi18: agdf: this problem is with loading from inittrd but from chroot loads fine
cxo: Can fbcon also be built into the kernel
uzi18: on rc5 it works grat but on rc6 have this problems
uzi18: agd5f: grat=grat
uzi18: great ;)
cxo: did you get any weird virtio cross reference errors when building rc6?
agd5f: uzi18: is this a self-built kernel/initrd or distro provided?
uzi18: agd5f: self-build but changed only rc5 to rc6
uzi18: initrd generator does not changed
agd5f: uzi18: maybe something broke in the kernel fw stuff in rc6
uzi18: agd5f: have all radeon fw in initrd image
taiu: uzi18: when you build in I guess you need CONFIG_FIRMWARE_IN_KERNEL
uzi18: i have radeon compiled as module
uzi18: agd5f: maybe i will add delay for insmod radeon ?
uzi18: because it is insmoded just after loading:
uzi18: echo -n /lib/firmware/firmware.sh > /proc/sys/kernel/hotplug
uzi18: echo -n /lib/firmware/firmware.sh > /proc/sys/kernel/hotplug
uzi18: echo -n /lib/firmware/firmware.sh > /proc/sys/kernel/hotplug
uzi18: echo -n /lib/firmware/firmware.sh > /proc/sys/kernel/hotplug
uzi18: echo -n /lib/firmware/firmware.sh > /proc/sys/kernel/hotplug
uzi18: insmod /lib/modules/2.6.32-desktop-0.rc6.1/kernel/drivers/gpu/drm/radeon/radeon.ko modeset=1
uzi18: agd5f: what do You think?
agd5f: uzi18: I don't know. I'm not familiar with what your init script is doing
agd5f: uzi18: if it worked in rc5, it's probably something else
uzi18: agd5f: funny thing that same as on rc5 ;/
cxo: Were there any drm/kms/radeon changes from rc5 to rc6?
uzi18: cxo yes there were :)
agd5f: nothing related to fw. I suspect it's an issue with the kernel fw loader, which is not part of the drm
cxo: OK. I'll also upgrade to rc6 sometime today
cxo: is that ok -> drivers/gpu/drm/radeon/radeon_atombios.c:609: warning: the frame size of 1464 bytes is larger than 1024 bytes
cxo: I'm just going to use my rc5 kconfig for rc6
uzi18: agd5f: ok i have moved insmod radeon to the end of all insmods maybe will help
cxo: I keep getting section mismatch warnings during modpost
cxo: when building 2.6.32rc6
glisse: agd5f: cursor on non avivo is of fixed size ?
agd5f: glisse: I think so... don't remember off hand. let me check
agd5f: glisse: yeah, looks like it
glisse: 64*64 ?
agd5f: yup
glisse: and it's always 24bpp
agd5f: glisse: no, depends on what mode it's set for
agd5f: see CRTC_CUR_MODE in CRTC(2)_GEN_CNTL
glisse: agd5f: i think i will need a ttm addition :(
agd5f: glisse: either mono or some variant of 24 bpp
glisse: i am trying to fix issue where cursor buffer endup way beyond of way before the display_base
agd5f: glisse: ah yeah
glisse: agd5f: make sure to push of the roof any hw engineer which thinks that was a good idea ;)
glisse: i guess for the scanout hw logic it helps
agd5f: glisse: I don't think we planned to be using that display block with 256 MB of memory at the time
agd5f: it comes from r128 IIRC
glisse: well i think i can solve most of my bug by changing display_base but this means flicker i think
agd5f: glisse: still have to make sure fb and cursor are within 128 MB of eachother
glisse: yeah i will go the ttm way
glisse: i am trying to think to the best way to change ttm to do that
glisse: i think i will propose to add extra bo storage at end or begining of bo
glisse: might be usefull for others things than cursor
glisse: and for cursor we would ask for extra space at end of each fb
agd5f: glisse: also for gpu-only vram maybe we add a flag like visible/invisible and you can pick depending on if sw will need to access the buffer or not. something similar could be done for cursor
glisse: agd5f: yeah i had somethings similar in mind for unmappable vram
glisse: basicly it would effict buffer in non visible vram if user space wants to map it
agd5f: or just don't let them map it if that flag is set
glisse: i started hacking on that got distracted by bug
glisse: don't think forbidding mapping is good
agd5f: although I guess that would limit migration of buffers in general
glisse: anyway i think most urgent is to fix the stupidity of moving buffer so often
hagabaka: roysjosh: I looked at the video; your screen seems to turn black every few seconds; mine doesn't. also, the flashing lines on my screen are formed with a shifted "shadow" of the image, and the shift is longer to the right. when I move my mouse to the right edge of the screen, I would see a shadow of the cursor.
glisse: agd5f: do you remember if we have any reported issue with bad rendering on radeon 7200 (R100), people seeing black window for instance
agd5f: glisse: not sure about 7200, but IIRC, there have been several issues with RV200/M7
agd5f: which is pretty similar
glisse: i got an M7 and it seems to work fine
glisse: beside some issue with agp
glisse: debugging without the affected hw is painfull
MrCooper: glisse: black window for (certain) 3D apps only?
glisse: MrCooper: only popup message from gnome are black
glisse: also hint are black
glisse: for instance when you move the cursor over the close button of a window a hint should appear under gnome
adamk_: With or without a compositing manager running?
glisse: adamk_: without as far as i can tell
glisse: basic gnome desktop
MostAwesomeDude: eosie: Just got up, reviewing.
MostAwesomeDude: Blend mask looks great. :3
MostAwesomeDude: Colorbuf/zsbuf offsets looks good; might help with mipmap gen.
kdekorte: agd5f, on the black window issue, could it be an alpha color issue?
MostAwesomeDude: I'll have to check rendering with poly mode, but that looks good too.
MostAwesomeDude: Solid patchset, good work.
agd5f: kdekorte: black window issue as in the old visual/gamma thing, or what glisse is talking about?
glisse: i think kde people see similar issue as the problem i am describing
kdekorte: what glisse is talking about
glisse: but yet i am unsuccessfull at reproducing it with kde
glisse: and any of my hw
agd5f: glisse: radeon might need something like this in the GL compositer case: http://cgit.freedesktop.org/mesa/mesa/commit/?id=2073006c9566b08888b4338748a843c645bd0db1
kdekorte: I think the notifications may try to do a "pseudo alpha" if and read the screen under the popup. So if the read is returning bogus valus, that could be why is it black
agd5f: kdekorte: does it only happen with composite?
kdekorte: I don;t have one
kdekorte: just guessing here
agd5f: glisse: I had a patch to rework radeon similarly, but I wasn't able to reproduce the problem
kdekorte: lowest machine I have is RV280
agd5f: and the tfp tests in piglit seems to fail no matter what on radeon hw
glisse: agd5f: i thought i saw a similar patch commited to radeon
scottles: Has anyone tried the radeon driver on an iMac? I run Debian (currently squeeze) on my iMac and usually use RadeonHD (which generally works fine) and decided to try the radeon driver.. it seems to garble the display on my LVDS screen (output on 2nd DVI screen is fine). My imac has a radeon 2600 pro.. anyone experience this?
agd5f: scottles: make sure you are using a recent driver. also might need a quirk since mac's tend to have broken connector tables
scottles: dpkg -l shows 6.12.3-1
scottles: which is one release behind latest
scottles: agd5f: how do you enable quirks?
agd5f: scottles: you have to figure out if it needs one or not and what quirks it needs
agd5f: radeonhd may have a quirk for it already
scottles: agd5f: how would I go about doing that? :)
agd5f: scottles: check the radeonhd source and see if they have a quirk for your card
scottles: agd5f: ok.. will do.. :)
agd5f: scottles: might also try 6.12.4 or git master, see if they work any better
scottles: agd5f: I have no experience in building drivers in x.org... but I am just having a look through the radeonhd source now..
agd5f: scottles: what are the pci ids and subsystem ids for your card? lspci -vn
scottles: agd5f: hmm.. my radeon doesn't appear to show up in an lspci -vn..
agd5f: scottles: it should
scottles: agd5f: I am currently running radeonhd, would that make a difference? I have done a grep of the output and there is no reference to "radeon" anywhere..
agd5f: scottles: -vn shows numbers, so you won't see any names
agd5f: just pastebin the output
jcristau: -vnn shows both
scottles: agd5f: http://pastebin.com/m56d95eb4
agd5f: scottles: doesn't appear to have a quirk
scottles: agd5f: well I can wait until debian maintainers update to 6.12.4 in Debian sid.. not sure how long that will take though..
scottles: agd5f: what will be the next step to try if it doesn't work in the latest driver release?
agd5f: scottles: figuring out why. file a bug and attach xorg, log, config, vbios.
scottles: agd5f: ok, thank you for your help! I will do that once I have tried the newer drivers :)
spreeuw: CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_sdvo.c
spreeuw: if the rest merged fine can I compile for drm/radeon then?
eosie: MostAwesomeDude: thank you
MostAwesomeDude: eosie: No, thank you! :3
eosie: MostAwesomeDude: ;)
Zajec: how does g3dvl work?
Zajec: does it use shareds?
eosie: MostAwesomeDude: I just don't know what's wrong with polymode. Some combinations of states produce incorrect results.
Zajec: *shaders
eosie: MostAwesomeDude: I double-checked everything, was stepping in the driver with a debugger, watching the values, it's all correct
MostAwesomeDude: Zajec: Yes.
eosie: MostAwesomeDude: Sometimes, the hardware seems to use the front-face polymode for back faces too, thus ignoring the state for back faces.
MostAwesomeDude: eosie: Might be a bug in the maths for winding, but those seemed pretty correct. How are you testing?
happycube: MostAwesomeDude: did you see my pastebin from last night? it turns out nothing was emitting the vertex info
eosie: MostAwesomeDude: rotating triangle in OpenGL, setting facing and polymode, debugging using kdbg
agd5f: eosie: compare with classic driver.
MostAwesomeDude: I'm not sure classic ever sets poly mode.
eosie: I think the classic drives does it right.
spreeuw: glxgears still broken on 31.5 with drm next merge
spreeuw: gives me white stripes
spreeuw: maybe the merge didnt go well
eosie: ... which is what makes me uncomfortable.. ;)
agd5f: spreeuw: try make realclean and rebuild mesa
happycube: it looks like r300_emit_vertex_buffer() might need to be taken out of r300_emit_dirty_state - now for each drawing there's no dirty state so the latter exits w/o doing anything...
spreeuw: k
MostAwesomeDude: happycube: Yeah, that's a definite possibility. One of osiris' bits might fix that.
agd5f: MostAwesomeDude: classic sets polymode
agd5f: r300UpdatePolygonMode() in r300_state.c
Zajec: what is softpipe? is this something that pretends to be hardware? calculating for example shaders on cpu?
MostAwesomeDude: Zajec: softpipe is a SW rasterizer.
Zajec: MostAwesomeDude: and SW raserizer is... ? :|
MostAwesomeDude: agd5f: Ah, I see. Subtly different from the Gallium setup, then.
Zajec: does it calculate 3D world on CPU?
Zajec: like starting glxgears without 3D driver?
MostAwesomeDude: Zajec: It's a software version of the 3D pipeline.
MostAwesomeDude: Just like swrast from classic Mesa.
Zajec: ok :)
Zajec: th
Zajec: x
spreeuw: agd5f: after a clean rebuild I get the old crash again
kdegel: agd5f:
|wilco|: how on earth can i have 3d accelerated wine on my amd64 system when i only have 64bit version of r600_dri
kdegel: adamk:
spreeuw: glxgears come up, but the sideplane of the cogs is gone
spreeuw: and it hangs the machine
kdegel: I don't know if you remember, but we were working a bug out
kdegel: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/463369
kdegel: last Friday
spreeuw: dri1 rv620
kdegel: I wanted to give you guys an update and throw something by you
kdegel: I did a bunch of updates the last 2 days and I coudln't get the server to flake out like it was, so today I completely re-installed the server and LTSP and they login still doesn't work
kdegel: but the graphics part isn't messed up anymore
kdegel: so I'm wondering if this is an issue with something else?
osiris_: happycube: the bug you're trying to fix in redbook/planet is fixed on my r300g-vbo branch already
eosie: osiris_: I tried your branch and r300_vbo.h is missing.
osiris_: eosie: oopsie
MostAwesomeDude: osiris_: You didn't add r300_vbo.h to your branch, BTW.
happycube: osiris - it's fixed in master, too
MostAwesomeDude: Heh.
happycube: the issue i tracked down the last couple of nights led to it only drawing the first bit of any sequence ;)
Zajec: so can I try g3dvl on r6xx without hw acceleration?
osiris_: Zajec: nope
Zajec: but... softpipe?
osiris_: hmm
osiris_: I'm not sure there's full softpipe renderer for gallium
happycube: there isn't a way to build a softpipe_dri.so IIRC
Zajec: so when softpipe is used actually?
eosie: Zajec: Using a software rasterizer for video acceleration is insane.
happycube: fallback cases
eosie: Zajec: fot testing
eosie: *for
Zajec: uhm, ok
MostAwesomeDude: softpipe *does* work on r600, but you must specify RADEON_SOFTPIPE.
dileX: RADEON_SOFTPIPE=1 glxinfo
MostAwesomeDude: I haven't officially added it to the winsys in a sane way, but it does work.
happycube: eosie - less so if it makes *very* good assembly code, but yeah ;)
Zajec: eosie: i don't want performance, just see how it works
MostAwesomeDude: More importantly, I don't think g3dvl works with radeon right now.
dileX: (for example)
cxo: Would building certain things into the kernel make it boot up faster?
dileX: "Work around aliasing bugs - developers should comment this out"???
dileX: $ grep fno-strict-aliasing build.log | wc -l
dileX: 999
eosie: Zajec: You may give it a try
franjva: Hi. Does anyone know what part of drm-next made it to 2.6.32-rc6? I'm getting the same corruption I got with -rc5, and that was definitely fixed long ago in drm-next.
franjva: I mean corruption in youtube, virtualbox and comix
spstarr: looks at git
soreau: looks at spstarr
franjva: I think the last commit that went into rc5 was d0c403e950d449c8c413a1fbf05dfec45ce03e55
franjva: that had the bug
dileX: franjva: See (worked-for-me with rc5 and rc6)
spstarr: looks at soreau looking at spreeuw
spstarr: looks at soreau looking at spstarr
stikonas: Linus Torvalds said that things were really quiet during those 2 weeks, so one more drm pull request probably wouldn't annoy him too much
franjva: dileX: so no new drm code made it to rc6?
franjva: from rc5, I mean
dileX: franjva: no, last were that 3 drm-fixes
dileX: franjva: if you want I send you a single patch incl. revert-drm-fixes and drm-next patches
franjva: weird. drm-linus was updated 7 days ago. I though it would get into rc6
franjva: dileX: yeah, please :)
dileX: franjva:
agd5f: spreeuw: seems to only affect the dri1 path, and only on some cards...
franjva: dileX: it applies without errors. rebooting, thanks
abacaba: Hi! On my system glxgears hangs with -fullscreen. My video is RV630, and I'm on 2.6.31+drm-next+recent mesa/video-ati taken from xorg-edgers repository. How this can be debugged? I see nothing in logs and system stop respoding even on CTRL+ALT-SysRq+B...
agd5f: abacaba: using kms?
abacaba: no
abacaba: Haven't tried with KMS...
agd5f: abacaba: does using mesa from the 7.6 branch work any better?
abacaba: Does it support 3D for R6xx/7xx chips?
agd5f: abacaba: yes
eosie: osiris_: I don't understand your proposal concerning get_tex_size_no_border, I think CLAMP_TO_BORDER means clamping to a constant border color (pipe_sampler_state::border_color), it has nothing to do with an edge of texture
osiris_: eosie: yeah, that's what DrJakob has suggested first, but turned out to be wrong
eosie: osiris_: I also looked at st/mesa and it seems to completely ignore the "border" parameter in glTexImage*
eosie: he might have meant that
abacaba: Ok, it works better with mesa-7.6 - it does not hang in fullscreen
spreeuw: abacaba: the last working commit for me is 409469f
spreeuw: the next one breaks glxgears
spreeuw: for mesa got
spreeuw: git
dileX: r300g (xorg/st) as softpipe: openarena runs (very slow)
spreeuw: dileX: do brightness changes work for you?
spreeuw: (gamma)
dileX: oops, how to check that (or see)?
spreeuw: dileX: in the menu under display
spreeuw: brightness
dileX: while running openarena? hmm, must check.
spreeuw: within open arena
spreeuw: change is immediate
dileX: spreeuw: somewhere -> setup -> options -> display -> brightness (changed to max.). seems to work. unfortunately, mouse-moving is a torture and yeah very slow.
spreeuw: like VERY slow?
spreeuw: then you may not have direct rendering
dileX: like un-play-able
spreeuw: they said it was akin swrast
spreeuw: so thats soft rendering
dileX: OpenGL renderer string: Gallium 0.3 on softpipe
dileX: $ RADEON_SOFTPIPE=0 glxinfo 2>/dev/null | grep "OpenGL renderer string"
dileX: OpenGL renderer string: Gallium 0.3 on RV515
dileX: $ RADEON_SOFTPIPE=1 glxinfo 2>/dev/null | grep "OpenGL renderer string"
dileX: OpenGL renderer string: Gallium 0.3 on softpipe
kdegel: tormod: kdegel, can you get a backtrace from the server crash?
kdegel: tormod: from http://wiki.x.org/wiki/Development/Documentation/ServerDebugging its expecting X to crash
kdegel: but X doesn't crash, it just kind of gets freaked out
kdegel: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/463369
tormod: kdegel, but you said it backs out to the login screen?
otaylor: airlied: so, with -105 and agp I have massive resume issues
tormod: kdegel, is X killed when running glxinfo?
kdegel: tormod: no
airlied: otaylor: yeah I think my r100 stopped resuming, will look today
kdegel: it doesn't back out to the login screen, it just also does it at the login screen, doesn't matter if I'm loged in as a use ror not
otaylor: probably related to
otaylor: Nov 4 15:52:18 localhost kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(7).
otaylor: Nov 4 15:52:18 localhost kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB !
kdegel: tormod: X doesn't get killed, it just gets all flaky where nothing is ledgable
kdegel: I can take a pic to show
airlied: otaylor: ring test fails earlier I think
tormod: kdegel, please also attach full logs to the report instead of pastebin links
kdegel: tormod: OK, which logs would you like?
otaylor: airlied: yeah
tormod: kdegel, Xorg.0.log in particular
kdegel: sure thing
otaylor: airlied: Nov 4 15:52:14 localhost kernel: [drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0xCAFE
otaylor: DEAD)
tormod: kdegel, basically those files that people have asked for in the report
tormod: kdegel, you have an ES1000 (RN50) card, so no DRI and do not think about using compiz
tormod: kdegel, did you see any difference between XAA and EXA?
tormod: kdegel, try 16 bit depth
kdegel: tormod: XAA and EXA for options in xorg.conf ?
kdegel: I think I only tried EXA and that fixed the issue, that and changing the compiz.conf file
tormod: what did you change in the compiz conf?
kdegel: from my understanding compiz should just not be involved at all and should fail over to metacity but since theres a bug in the video driver, its failing to act normally
tormod: kdegel, no, compiz will not even try to start since you have sw rendering
kdegel: 10:27 < Gadi> kdegel: http://pastebin.com/m2c44b744
kdegel: 10:27 < Gadi> that's an /usr/bin/compiz script (adapted from the interpid one) that should solve the problem
kdegel: from the bug report
kdegel: I don't know what was changed, I can post my default compiz.conf that comes installed by default if you would like
tormod: kdegel, please diff the two
wunki: is it possible to get 2D support in FreeBSD for a 5850? I'm desperate..
wunki: I just want to be able to use Vim normally..
agd5f: wunki: not yet
wunki: that's a pitty..
wunki: will it take long to have support?
kdegel: tormod: would you like it in the bug report? or just pastebin here?
happycube: wunki - try VESA if you're doing just 2d? waste of an uber-powerful card but eh
tormod: kdegel, the compiz diff just pastebin here
agd5f: wunki: working on it
wunki: happycube: I'm using Vesa now, but it's not workable... Every new line takes a second in vim
wunki: agd5f: really appreciate the effort
kdegel: tormod:
kdegel: http://pastebin.com/f513dc7cb
happycube: ouch - vesa should be faster than that
wunki: agd5f: do you have any prognoses when of a first release?
wunki: happycube: maybe my xorg.conf isn't good.. will also check that out
agd5f: wunki: I have analog working already. digital not quite yet. After that, just need approval to release
wunki: agd5f: that's good news, I will keep FreeBSD as my main OS than.
wunki: agd5f: was thinking of a switch to Linux for the fglrx
tormod: kdegel, there were just too many changes to find what matters in there
tormod: kdegel, I just guess the "working" one correctly gives up and falls back to metacity
kdegel: which is what the ltsp people said should happen ....?
kdegel: which I think is why they thought it was a compiz issue, but when the compiz people looked at the issue, they determined that compiz wasn't the cause, it was reacting the way it should but the driver was not working correctly
tormod: kdegel, did you try 16 bit depth?
kdegel: no I didn't
kdegel: you want me to change that on the server and for the person who logs in?
kdegel: or just one or the other?
adamk_: kdegel: Didn't we determine that your GPU doesn't support 3D acceleration?
soreau: yes, agd5f established that
adamk_: Not that an X server crashing is ever acceptable.
kdegel: adamk_: yes
tormod: kdegel you must _attach_ the logs not paste them into comments
kdegel: tormod: ok, I'm not sure how to do that but I will figure it out
tormod: kdegel, and please scp it instead of c&p from putty...
kdegel: ahh there it is
kdegel: adamk_:
kdegel: tormod:
kdegel: for what its worth
kdegel: http://pastebin.com/m622cd521
kdegel: from #ltsp
tormod: kdegel, so gadi is saying that the driver explodes on glxinfo calls. is this correct?
kdegel: tormod: well not literally of course, but yes, and I think the compiz people think the same
tormod: kdegel so if you don't try to start compiz, there is no problem?
kdegel: I have it turned off
kdegel: was off from the beginning
tormod: kdegel do you have "failsafe gnome" session on this ltsp thing? ok
kdegel: even uninstalled it
kdegel: I haven't, not even sure if it can do it.....
soreau: tormod: Last we checked, it was failing at the time glxinfo was called
tball: HEllo guys
adamk_: Right.
tball: Is there any status on powermanagement under kms?
tball: For r600+
adamk_: I don't remember if it was checking with LIBGL_ALWAYS_INDIRECT set, but glxinfo failed crashed the X server when checking for TFP
kdegel: tormod: give me a moment, have to restart
tormod: ok, but without compiz, there is no glxinfo run, and it's still broken, right?
adamk_: Well, it doesn't crash.
adamk_: Heck, even with EXA enabled, it didn't crash when glxinfo was run, as I recall.
kdegel: adamk_: I think that is correct, I am looking through the logs
tormod: I get pretty confused by all these contradictions...
adamk_: Alright.
adamk_: As I understand it, the only real bug here is that glxinfo crashes X on his GPU when XAA is enabled.
adamk_: I would wager that any GL application would do the same thing, though.
kdegel: remote, right?
adamk_: soreau: Is that your recollection, too?
tormod: so everything is fine with exa?
adamk_: If I remember correct, yes. I recall him changing to EXA, restarting X and logging in succesfully.
soreau: adamk_: I was trying to think back and best I recall, with EXA the problem was 'fixed'
tormod: ok now we're talking
tormod: there have been other reports of xaa failing miserably in 9.10
kdegel: awesome ! :(
adamk_: What is odd is that his GPU does not support direct rendering, and it's never enabled in the X server.
adamk_: Well, that isn't odd in and of itself. What's odd is that an X server without DRI enabled would crash when glxinfo is run.
rhodan: Hey, is ksnapshot laggy for you when trying to select a specific area?
tormod: well glxinfo would make vesa crash at one point
Zajec2: tball: i plan to implement engine downclocking
Zajec2: tball: waiting for airlied "getting his ass" to get my base patch :)
tball: Zajec2: Sounds good. Does anything work now?
Zajec2: tball: no
adamk_: tormod: So, anyway, that's my entire understanding of the situation.
tball: Zajec2: Ok :) What more than engine downclocking needs to be implementet
Zajec2: tball: implementing is easy, it's just hard to get in mainline, you now, agreements on architecture
tball: yeah ok
Zajec2: tball: engine downclocking is most important, little less important is memory downclocking
Zajec2: tball: that will give you most reduction of power consumption
tball: Well thats the last stone in my way of going oss fulltime :) My laptop don't like the heat without powermanagement
rhodan: How do I try out the xorg state tracker?
tball: ok
Zajec2: tball: hopefulyl we will get this somehow into .32 still :)
Zajec2: tball: kms is as staging, so AFAIU Linus should accept patches
tball: Zajec2: Wauu I didn't expect that. Though we had to wait for 0.33
tball: Well good news
Zajec2: tball: same reason for me for switching to KMS :)
Zajec2: tball: i hope not... but don't treat me as expert anyway
tball: Zajec2: Well you are developing some of the powermanagement, aren't you ;-) Thats make you the expert
Zajec2: i just know modesetting a little ;) not much knowledge about accelerated 2D, 3D or kernel rules ;)
kdegel: tormod: adamk_ should I do something with the ticket?
kdegel: add anymore info? maybe its not clear enough?
tball: Zajec2: Well I understand. But nice you are looking into it :-) We really need powermanagement
tormod: kdegel, there's so much back and forth in that report so it will never be clear :)
kdegel: :(
tormod: kdegel, so everything is fine when using EXA?
adamk_: Maybe close that bug and start a new one explaining that your X server crashes when you run glxinfo with XAA enabled? Include the appropriate log file from the crash.
kdegel: I haven't tried with just that option and not having an edited compiz.conf file, that was going to be my next test
kdegel: but ultimately we would like to have as close to a default distro as possible
tormod: if the above theory is right, the normal compiz script will not do any harm when using exa
kdegel: thats what I was thining when you guys were discussing
kdegel: but unfortunently I have put in a lot of hours today so I am going home and will do what adamk_ suggested in opening a new ticket
kdegel: I may steal some words from adamk_ if that is cool :)
tormod: kdegel, please do that test and summarize in the report. then we can try to reproduce the glxinfo on xaa problem and nail that down
adamk_: That's fine with me :-)
kdegel: tormod: ok, thanks for all of your help, will you be on tomorrow morning? I'm EST
tormod: kdegel, can not promise anything, but I am subscribed to the report
kdegel: which package should I put it under?
tormod: xserver-xorg-video-ati
kdegel: fantastic
kdegel: tormod:
kdegel: adamk_:
kdegel: again, thank you for your time and work
kdegel: hopefully I will talk to you guys tomorrow, bye
ootput: hi all. I recently started tracking dev versions of ati drivers for my hd card. I notice the following output when using glxinfo: http://dpaste.com/116366/ Is this a standard non-critical error?
rhodan: Help! Help! I'm being ignored!
adamk_: ootput: No, IRQs are not supported yet.
adamk_: Sorry, yes, that is a standard non-critical error :-)
adamk_: I initially read that as non-standard critical error.
wunki: what type Rxxx are the 5850? So I can watch the repo's for commits which enable the card :)
adamk_: R8xx
wunki: adamk: thanks, is there a feed for the commits?
ootput: adamk_: thanks for clearing that up
ootput: it didn't seem to affect 3d performance stability
adamk_: wunki: Not that I know of.
adamk_: ootput: IRQ support will probably improve performance, but I really don't know much about it.
wunki: I have zero knowledge of building drivers, how do you build drivers for new cards? Just trial and error?
tormod: rhodan, just nobody around who feels qualified to answer your questions I guess :)
tormod: wunki, I think it helps with some tech docs on the cards
wunki: ah, I though AMD wasn't cooperating.
adamk_: Exactly the opposite.
tormod: wunki, AMD is paying opensource developers
tormod: wunki, to track the commits, there is http://lists.freedesktop.org/mailman/listinfo/xorg-commit
octoploid: Are there any plans to send the revert of 49c458e544ae14514209ed80ea6829ca1b18ddf0 to Linus soon?
wunki: ah, my bad
wunki: tormod: thanks
tormod: sometimes these git commit ids are so telling for us humans
octoploid: tormod: Revert "drm/r600: avoid assigning vb twice in blit code"
tormod: thanks :)
tormod: google are pretty good at them though: http://lkml.org/lkml/2009/10/8/19
tormod: octoploid, its reverted in drm-next, maybe you can check linux-next
octoploid: Without the revert flash videos and qemu guests are garbled on my RS780. Would be good if it could make it into 2.6.33.
octoploid: tormod: Yes I know.
agd5f: octoploid: it's in drm-next. not sure when airlied is planning to ask linux to pull additional updates
agd5f: *linus
airlied: sometime soon I hope ;-)
octoploid: agd5f: That'
logari81: tormod: I have two possibly ubuntu related problems, so maybe you can give me a tip
logari81: 1) on a R600er with 2.6.32-rc6 and xorg-edgers ppa, I can't get KMS because of modules loading order issues (upstart??)
logari81: 2) on a R400er with 2.6.32-rc6 and xorg-edgers ppa, I have no X at all, only a corrupted pointer, but the resolution in VT seems KMS-like
octoploid: s why I'm asking. Not much time left.
tormod: logari81, https://wiki.ubuntu.com/X/RadeonKMS
airlied: kinda wanted to see if I could find the proper w500 fix
airlied: but I'll push the VRAM not at 0 one for now
logari81: tormod: restarting gdm as in wiki described makes KMS work on the R600
tormod: logari81, not sure about (2) but it can also be the fbcon loading issue.
tormod: sometimes the server makes radeon load and KMS is initalized but then the server probes for KMS and fails (race?) and starts modesetting on its own -> fail
Zajec2: could you guys review http://bugs.freedesktop.org/show_bug.cgi?id=24837 ? so airlied can know if this should be applied :)
Zajec2: airlied: could you collect all awaiting patches info drm-next few days before pull request, please?
Zajec2: airlied: so we could test that all together and eventually add more fixes
airlied: Zajec2: any patches athat aren't in drm-next yet I only wrote in the last day or two
airlied: I'm going to scrap drm-next for radeon dev quite soon
airlied: its really not working out correctly
Zajec2: airlied: er, it's 7 days old, isn't it?
airlied: Zajec2: I don't work weekend
Zajec2: airlied: i would love to have 7-day weekend ;)
Zajec: airlied: seriously, i wonder if http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-next repository is correct one
airlied: why?
airlied: 7 days is last Thu, - weekdn is patches from last two days
Zajec: ah, two days back means weekend, and more two means 5
Zajec: ok, ok :)
Zajec: 5->4
Zajec: anyway, it's ok
airlied: I'll push whats in my mtree now
airlied: but I've got a lot more important things to do
airlied: the problem with me pushing things too early is I can't revert them then
Zajec: er, can't you?
airlied: no drm-next can't rebase
Zajec: it seems i'm still newbie with repos/git :)
airlied: hence why I'm going to stop using it
Zajec: weird
airlied: no its the linux development model
airlied: other ppl base their trees of drm-next
airlied: so I can't rebase it
Zajec: ahh
Zajec: that way
Zajec: airlied: so we should probably have some drm-experimental that gets into drm-next at some point, that finally get into Linus's tree finally?
airlied: Zajec: I'll probably just do drm-radeon-testing
airlied: and keep it as something I can rebase often
Zajec: ї)
Zajec: :)
Zajec: sniffs drm-next activity ;)
airlied: it should have mirroed by now
Zajec: airlied: damn you ;) i was going to sleep soon... and now you took my patch :P have to work on more PM now ;)
Zajec: airlied: all nice patches in drm-next, nice :)
airlied: Zajec: I didn't push your patch yet did I? its in my other list ;-)
Zajec: oh
Zajec: it's i pulled your tree into my local
Zajec: :P
Zajec: git newbie ;)
dileX: airlied: whats with ?
airlied: no idea, not sure where we are getting called like that
rozzo: hello
rozzo: :D
rozzo: i have aproblem with my card ati radeon
rozzo: whan configure to use the radeon driver i get blank screen
rozzo: when*
biotube: which card?
rozzo: radeon xpress X1270
rozzo: X1200 series
chithead: and pastebin Xorg.0.log
rozzo: chipset R690
edt: gmake[5]: *** No rule to make target `compiler/libr300compiler.a', needed by `r300_dri.so'. Stop.
edt: gmake[5]: *** Waiting for unfinished jobs....
edt: when building mesa from git...
edt: anyone elase seen this?
chithead: did you run make clean
editka: hello folks. Do you recommend me radeon driver or fglrx driver for my Radeon X600 (RV380) 3E50 (PCIE) chip? I am getting screen corruption when using radeon driver (haven't tried fglrx yet) when compositing is on...
biotube: I don't think fglrx supports it anymore
editka: biotube: ok no problem for me radeon is giving me good performance, but i need to solve the corruption issue - this is my wife's pc and she loves the effects xD
editka: http://pastebin.com/m3513f1c6 this is my xorg.log
biotube: editka: it looks like you didn't entirely clean out fglrx; this can cause problems
kdekorte: editka, might need to upgrade the xserver as well
editka: X Server: 1.6.5, radeon version: module version = 6.12.4
editka: biotube: this is clean install and fglrx have never been installed here :-(
biotube: editka: your xorg.log lists attempts to load it
biotube: did you reuse an old xorg.conf
editka: biotube: yes it is xorg autoconfiguration - i have no xorg.conf
adamk_: It says that is part of the built-in configuration.
adamk_: Probably something stupid that opensuse does.
editka: and unfortunatelly opensuse doesn't provide xorg 7.5. newest is 7.4 :-(
editka: adamk_: it is xorg autoconfiguration, not opensuse autoconfiguration...
adamk_: Xorg, by default, will not try load fglrx.
adamk_: If it's doing that, it's because opensuse did something stupid and changed the built-in configuration.
adamk_: At least that's my guess.
editka: adamk_: oh...
adamk_: Both based on your log file and my too-long experience with opensuse.
editka: adamk_: i was thinking of building clean xorg for opensuse without all that patches... but not sure if it would be accepted mainstream...
biotube: the easiest thing to do would be to have a xorg.conf specifically call for radeon
biotube: Section "Device"
biotube: Driver "radeon"
biotube: EndSection
biotube: learned that when X wanted to load radeonhd by default
editka: biotube: but question is - would it solve my issue? it tries to load fglrx without success, then ati, then radeonhd, then radeon....
biotube: I don't know, but it's a start
editka: radeon is loaded ok and it is used
editka: i think i have better chance with a 6.5 xorg custom build :-( suse's xorg packages has ton of diffs and tarballs
agd5f: editka: try Option "EXANoDownloadFromScreen"
editka: agd5f: do exist some tool to autogenerate xorg.conf? because i dont have any xorg.conf on my system
biotube: editka: any missing parts are filled in automatically
biotube: err, detected automatically
Luzipher: wow ... kms works now with two cards plugged in :) ... but it does have more graphical glitches than without kms ... is that a known problem ?
EruditeHermit: hi
editka: biotube: cannot get xorg up with this xorg: http://pastebin.com/m2015305e
editka: apparently not all missing part are detected automatically :-(
editka: or do i need to specify driver in each Device section?
biotube: I'm not sure, but you might need to give the device a name
biotube: Identifier "Configured Video Device"
biotube: or somesuch
editka: biotube: you were right...
editka__: (WW) RADEON(0): Option "EXANoDownloadFromScreen" is not used wtf :-(((
editka__: ok, so no composite on RV380??? Can't believe it :-(
editka__: (==) RADEON(0): Using XAA acceleration architecture --- shouldn't xorg use EXA automatically in case of RV380 ???
biotube: that's a recent default IIRC
editka__: bieoutdated xorg... again.. i feel i will have to package 7.5 by myself :-(
editka__: biotube:
editka: trying with EXA now
editka: ok, so screen is corrupted when using EXANoDownloadFromScreen, without it, with EXA and even with XAA... any suggestion?
editka: only when composite desktop is on
editka: :-(
cxo: Are any of you guys interested in a laptop with a Radeon 9700pro ? I want to sell it, i'll give it away cheap! Maybe it could be useful for driver development
spstarr: cxo, thats an r3xx AGP :)
spstarr: has an RV350 (Radeon 9600 Mobile) on his old T42
happycube: the mobility 9700 is actually a rv350 variant... i think an upclocked 9600. not 8 pipes ;)
happycube: and yeah, laptops with tgt video chips are useful... /me has a t60 w/x1400
MostAwesomeDude: eosie: Pushed your patches. Will get to the other problems later; I need to see if I can get osiris' code cleaned up and merged.
happycube: cool
editka: any hint on how can i resolve screen coruption when composit on with my X600 (RV380) PCIE (X Server 1.6.5, radeon 6.12.4, DRI 1.31.0)
editka: tried wit EXA, XAA, EXANoDownloadFromScreen, nothing helps :-(
happycube: what kind of corruption? if running 3d apps you should move to dri2
Tanktalus: just wants to run opengl apps :-P
editka: happycube: if i turn composite on i have track of windows when moving them for example...
happycube: also, mesa/src/state_tracer/st_atom_viewport.c 's computation of translate[1] is suspect... simply using "st->state.viewport.translate[1] = half_height + y;" makes glxgears move with resizing correctly
editka: happycube: and after a few minutes the whole xorg freezes so i have to restart my system.
happycube: ^ tested on both softpipe and r300g.
happycube: ouch...
happycube: without composite how do other 3d uses run on it?
editka: happycube: http://pastebin.com/m4b4fecc3 my xorg.log
editka: happycube: without composite everything is OK
editka: happycube: as far as i can tell... i have tried only glxgears
editka: glxgears gives me 1600-1700fps
happycube: i don't see anything wrong in here
Tanktalus: editka: I wish I could get that. I get about 280fps with glxgears :-(
editka: Tanktalus: yes but i cannot get composite working... which is major for me it is my wife's computer
editka: and i pray to get world of warcraft working... with radeon driver
Tanktalus: I'm using (some) compositing on kde4 with Xrender, not OpenGL (OpenGL hangs, at least last time I tried).
Tanktalus: My wife's computer has an older nvidia card in it, and compositing is turned off ;-)
cxo: I have a little screen corruption too, but usually at the bottom of every window
editka: Tanktalus: for me it doesnt't hang imediately but causes minor screen artifacts and then freezes..
happycube: how hot is the card getting?
editka: nvidia is no problem because you can use prioprietary driver... ati has dropped support for my card :-(
cxo: (R700, 2.6.32rc5, and whatever radeon from git)
editka: happycube: the card is not everheating imo
editka: happycube: how can i check?
happycube: *nod* that sounded vaguely like a memory corruption
happycube: touch the hsf, if you can keep your finger on it it's ok ;)
agd5f: editka: might try git master or kms
happycube: i think i'd try a game (etracer? dunno) with compositing off and seeing if that's ok
editka: happycube: seems ok
editka: happycube: ok i will try tuxracer
happycube: yeah - kms/dri2 might help, esp if you actually want to run 3d apps *while* compositing ;)
editka: happycube: i am using dri2 imho
editka: check the xorg.log
happycube: you're not
happycube: it's got dri2 support, but it's not running
happycube: if this is ubuntu 9.10 you need "radeon.modeset=1" in your kernel/grub config
editka: happycube: should i try? even with xorg 7.4?:
editka: this is opensuse 11.2
editka: agd5f: i would rather not compile xorg/radeon/whatever since this is not my pc and would like to let it update through package manager.... but unfortunately suse's xorg packages has over 200 of tarbbals and ton of patches and it will be hell to update that rpm :-(
happycube: humm... if you have updated mesa and xserver, those are the important bits
happycube: you probably want a new kernel tho
happycube: nm, you do have one - ok, put in radeon.modeset=1 in the kernel options
editka: i have kernel Mesa-7.6....
happycube: also might wanna ask the opensuse channel? maybe someone who works on 3d packages is out there
editka: happycube: i have tried... but no response... i am affraid that i will need to upgrade to xorg 7.5 :-((
happycube: drm, radeon 2d driver, and mesa are the important bits
editka: libdrm-2.4.14
editka: mesa is 7.6
editka: and radeon driver is 6.12.4
editka: drm is the most outdated here yes?
editka: i think i could repackage it and upgrade it..
happycube: it comes with the kernel, but you might want to get it from git
happycube: it should be new enough to do modesetting, so edit your kernel config
happycube: also search for any "radeon.modeset=0" in /etc somewhere