Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-9-28

Search This Log:


nanonyme: hifi: I dunno, Gentoo was my first Linux distro too. ;) It had an *interesting* learning curve.
Nightwulf|work: hi all
dileX: hi Nightwulf|work
Nightwulf|work: hi dileX
rvalles: trying kms on r700 with .32-rc1
rvalles: seems it works
rvalles: 2d works, xv "works", glxgears works, mplayer -vo gl works
rvalles: no "xcomposite" nor "aiglx" extensions
rvalles: and both nexuiz and sauerbraten crash X.
rvalles: did anybody make any of those work with the new r700 kms?
rvalles: *with linux 2.6.32-rc1
nanonyme: rvalles: What's with Xv, tearing?
taiu: rvalles: nexuiz worked here a while ago, will try with latest bits...
taiu: rvalles: nexuiz works, although there's still issue with index buffer space check so by default it asserts there
taiu: are you running indirect or smth so X crashes?
rvalles: nanonyme: that and the color bar thingies...
rvalles: taiu: indirect?
rvalles: direct rendering -> yes (glxinfo) and xcomposite/aiglx "extensions not found"
rvalles: rvalles@reimu ~ $ xcompmgr -s
rvalles: No composite extension
rvalles: hm, I'm using plain git
rvalles: maybe I should build some specific branch?
rvalles: (for mesa)
taiu: mesa latest is ok, buy you need latest bits from drm-next kernel branch, not sure they have reached linus yet
rvalles: warsow -> doesn't start
rvalles: openarena -> works! I played... for a few seconds, then it crashed to desktop
rvalles: drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info.
rvalles: [ 2516.129115] [drm:r600_cs_packet_parse] *ERROR* Can not parse packet at 548 after CS end 548 !
rvalles: [ 2516.129118] [drm:r600_packet3_check] *ERROR* bad DRAW_INDEX
rvalles: [ 2516.129119] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
rvalles: those are the relevant lines @ dmesg
rvalles: taiu: not sure... I just built .31-rc1
rvalles: hotplugging a second screen hasn't worked either
rvalles: gonna reboot and see if it works on next boot
rvalles: nothing
rvalles: doesn't see it at all
rvalles: (perhaps related to the screen not having DDC support)
rvalles: (it's an old sony trinitron crt, 17", manages 1280x1200@60)
rvalles: still
rvalles: this is better than the usual
rvalles: last time I tried (without kms)
rvalles: it crashed and burned
rvalles: ej: no display on either monitor
rvalles: which forced me to keep it unplugged till now.
Pallokala: taiu: http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.32-rc1 has:
Pallokala: Merge branch 'drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
Pallokala: so it seams that drm-next has reached Linus
rvalles: seesh
rvalles: must hate _my_ hd4850 then.
Pallokala: that merge was on Sep 23
rvalles: rc1 was after that
rvalles: so...
rvalles: (a few hours ago, actually.
rvalles: )
rvalles: it also might work if I disabled kms
rvalles: are you using kms, taiu?
taiu: Pallokala: there's updates since then: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-next
taiu: yes
rvalles: ok
rvalles: guess it's in the updates since then, then
rvalles: maybe by rc2 it'll be better
rvalles: anyways, enough testing
rvalles: seems at least what used to be working is still working (2d accel) so I can do work.
dileX: haha
dileX: noone relaized it
dileX: while debianizing my kernel (drm-next on top of linus-tree)
dileX: its rc*1* not rc*2* as the Makefile says
dileX: oh linus
octoploid: To quote him: "Oh nnooooooooooooo-(takes breath)-ooooooo...
octoploid: Damn. I hadn't realized. I'm a moron.
octoploid: "
dileX: I realized to late, changed my debian-version to rc2
dileX: while doing breakfast I said to me
dileX: where was rc1?
octoploid: rc2=rc1 in this case.
dileX: nevertheless I enjoyed it :-)
dileX: yeah
dileX: BTW, for my understanding of version-numbering 2.6.31-git{1..18} is wrong. after .31 tarball the git-versions shoulb ebe bumped to 32 (stable 31-post fixes go to 2.6.31.x). as a side-note.
dileX: s/for/from
dileX: (git-versions in the merge-window)
MrCooper: airlied: maybe keeping pixmaps in GTT could work for RN50?
glisse: don't we disable accel on rn50 ?
airlied: MrCooper: PCI GTT isn't exactly fast
MrCooper: nor is RN50 VRAM?
airlied: MrCooper: true.
airlied: MrCooper: hence why I'md oing everything I can in system memory ;-)
airlied: glisse: we have CP + 2d engine
MrCooper: the PixmapIsOffscreen hook works for that, doesn't it?
airlied: not really since it'll still migrate
glisse: don't understand the usefullness of a gpu on a server
airlied: glisse: for kvms.
airlied: glisse: and paying our wages
glisse: :)
airlied: also IGPs are bad because scanout steals from memory bandwidth
airlied: so crappy PCI GPUs are all the rage
airlied: you get race to the bottom between mga g200se, rn50 and xgi z9
MostAwesomeDude: $ display freakin-fast-3d-card.jpg
airlied: MrCooper: with that EXA patch I think I was getting gtkperf and x11perf close to old XAA numbers, as opposed to a magnitude less
MrCooper: watching RV870 pr0n, are we? ;)
soreau: heh
MostAwesomeDude: It's that ad with the Virge, r128, Trident, and 3dfx all on the same board.
MrCooper: airlied: sure, but I don't see any reason for such a niche solution in EXA itself when the PixmapIsOffscreen hook should fit the bill
airlied: MrCooper: I don't see how it does, since it doesn't work at the moment
airlied: how do I stop it migrating any pixmaps that aren't windows with PixmapIsOffscreen?
airlied: its sort of after the fact
MrCooper: obviously you'd have to change it to return FALSE for pixmaps you don't want in VRAM :)
MrCooper: I thought you only wanted the screen pixmap in?
airlied: screen pixmap + window pixmaps like XAANoOffscreenPixmaps
MrCooper: I'd be surprised if XAANoOffscreenPixmaps moved in window pixmaps, sure about that?
airlied: they start off in, since xaa doesn't migrate in ever
taiu: I like 1-liners :) http://dpaste.org/w5Ow/raw/
taiu: if anybody would like to test, makes nexuiz explosions better, and doom3 title screen
taiu: also seems to pass glean blendFunc
MrCooper: airlied: well, your patch doesn't actually catch window pixmaps anyway
MrCooper: exaDoMigration never gets windows, only pixmaps
airlied: ah I'll track that down then
airlied: yup XAA did windows separate to pixmaps alright
MrCooper: so you can definitely achieve the same effect in the PixmapIsOffscreen hook
MrCooper: airlied: note that windows != window pixmaps
airlied: its mainly from ajax's advice that copying XAA was probably the best answer
airlied: since we knew that worked
airlied: I'll play with PixmapIsOffscreen tomorrow
MrCooper: again, I'm pretty sure it doesn't special-case window pixmaps
airlied: (pSrc->type == DRAWABLE_WINDOW) || IS_OFFSCREEN_PIXMAP(pSrc)
MrCooper: or XAANoOffscreenPixmaps wouldn't have helped for compiz
airlied: is all over the place
MrCooper: that checks for a window, not its pixmap
airlied: yup thats what I'm checking for as well
MrCooper: except that a PixmapPtr never points to a window
airlied: ah thats the problem then,
airlied: I'll have a dig around then to see
Jill: hi
Jill: my open ati driver is too slow, can i increase it?
AStorm: ?
AStorm: you mean speed up.
AStorm: 1) pastebin /var/log/xorg.0.log
soreau: Jill: Which model card do you have?
Jill: i mean i want clear window resizing
AStorm: 2) wait for someone to check your configuration, e.g. soreau
AStorm: Jill: uhhh... you want composite.
Jill: no
soreau: Or he already has composite and he's using a slow method of resising
AStorm: yes redraws are slower with radeon due to reasons unknown
AStorm: probably still too many buffer flushes
soreau: resizing*
AStorm: but they aren't *that* slow.
Jill: hmm
AStorm: KMS is slower than non-KMS still.
soreau: Jill: Can you explain what you want to do a bit more in detail?
Jill: http://paste.org.ru/?lfqdya
Jill: yes i can
Jill: when i resize my windows... they are... has some effects like slow drawing of borders or something
soreau: Are you using a compositing window manager?
Jill: and sometimes X freezes happens
AStorm: you mean it doesn't update inside the window
Jill: no i dont
soreau: More specifically, are you using compiz?
Jill: AStorm: and outside lags
AStorm: Jill: we asked about the whole log
Jill: soreau: no i dont
AStorm: not some grep of it.
AStorm: :/
soreau: Jill: What is the output of 'glxinfo|grep renderer'?
Jill: wait
Jill: youre so fadt
Jill: fast*
soreau: ;)
AStorm: soreau: as if that has anything to do with 2D rendering ;p
Jill: whole logs are http://paste.org.ru/?6p9w22
Jill: and soreau: bash: glxinfo: command not found
soreau: Yech, debian
AStorm: ugh
soreau: Debian uses ye olde packages
AStorm: old X server and old driver
AStorm: that's the driver that doesn't do EXA yet
Jill: but they are good i think
Jill: olds
Jill: =)
Jill: maybe i need to install new linux image?
soreau: and xserver that doesn't like exa either
AStorm: Jill: not really
AStorm: but you need radeon drm module for fast 2D
AStorm: the kernel module
soreau: Well, everything there is old. It's debian :/
AStorm: right now your drm doesn't work, either because it's missing
AStorm: or because you don't have the permissions to access the device node
AStorm: open says it's missing.
Jill: can you try give instructions step-by-step about installation?
AStorm: so, build and load radeon kernel module
AStorm: ?
AStorm: nah, that's debian-specific, esp. if you're using their kernel :>
Jill: omg... build and load... i am simple user
AStorm: otherwise we might mess up your museum of free software
AStorm: I recommend #debian
Jill: i just from #debian
AStorm: ask them about drm radeon kernel module
tormod: Jill, there is debian-unstable and debian-experimental
AStorm: how to get it
AStorm: yes, there are
soreau: AStorm: Actually, the drm is found but it's the wrong version..
Jill: okay
AStorm: soreau: it's not.
soreau: I must be reading it wrong then
tormod: there should be at least linux 2.6.30 packages for Debian
AStorm: (II) RADEON(0): XAA Render acceleration unsupported on Radeon 9500/9700 and newer. Please use EXA instead.
AStorm: ok, here you have it
AStorm: you need EXA.
AStorm: ;p
Jill: i have installed libdrm2 2.3.1-2
soreau: And when we goes to use exa, it will fail I bet
AStorm: that is not the thing
Jill: and i already use Xorg -configure xserver confing
soreau: on X 1.4.2
AStorm: soreau: probably
AStorm: Jill: well, it's a very old x server
soreau: takes an excerpt from the compiz bot
AStorm: it's a whole release back
soreau: Jill: EXA will give a noticeable speed boost when using X server 1.5.0 (or recent versions from git) and the open source intel/ati drivers. Otherwise, you should stick with XAA. In order to use EXA add the following line to the Device section of your /etc/X11/xorg.conf file: Option "AccelMethod" "EXA"
Jill: i afraid about use unstable...
AStorm: or rather, two releases
AStorm: Jill: ...
AStorm: you fell into the debian trap
soreau: indeed
AStorm: their "stable" means old
soreau: nods
AStorm: unstable means tested
AStorm: teeting means untested
Jill: fucked
soreau: No..
AStorm: even unstable is not that fresh ;>
soreau: You're just mislead
AStorm: that's debian misrepresentation of what "stable" means
AStorm: in their language, it means "unchanging"
soreau: Debian uses old packages. And even with the new stuff, they hold out on key components, anything that might be misconstrued as nonfree
tormod: it's stable in the sense the distribution does not change, does not say anything about the software
AStorm: it should be called Debian frozen or whatever
AStorm: but not stable
AStorm: they have an iceweasel already ;p
AStorm: so "frozen" fits.
Jill: too fast again guys
soreau: Jill: In other words, all the good work that has been done on the open radeon driver components you're missing out on because of the oldness
AStorm: Jill: the point is: upgrade your system to debian unstable... at the very least
soreau: Which is probably the #1 reason why you're experiencing subpar performance
Jill: english isnt native, sorry but i understand... unstable repos on, and fully update..
AStorm: next step after Debian "frozen" would be debian "dead cold"
AStorm: ;)
AStorm: Jill: no, that might explode
AStorm: you need a system reinstall I think
AStorm: or at least a good upgrade guide
soreau: recommends recent versions of ubuntu for a deb based system
AStorm: ask #debian for one
Jill: in ubuntu open-steam doesnt works properly
AStorm: huh?
AStorm: it should work.
Jill: it doesnt i test it two times
AStorm: prod #ubuntu about it, maybe check launchpad for open bugs
Jill: two nights =)
AStorm: hmmh
AStorm: anyway, open-steam is out of scope of this channel ;p
Jill: two sweet nights and nothing.. maybe because i am not developer yet
Jill: okay
AStorm: or you just hit a bug.
Jill: open-steam for its devs
Jill: radeon
AStorm: yeah, ask them about it
soreau: Jill: Which version of ubuntu did you use.. did you notice an increase in performance? Does open-steam 'work' in debian?
Jill: last lts
soreau: Hardy's pretty old too :p
Jill: i want arch
Jill: archlinux
soreau: So? Go get it, I heard it's free
Jill: i was on it about mounth...
Jill: cool stuff but impossible hold it in slablility =)
soreau: If you want 'stable' or 'LTS' stuff, I guess you'll be waiting for awhile
soreau: Alternatively, get a recent version of ubuntu (at least 9.04) and be happier
tormod: Jill, I guess you will find Ubuntu 9.04 "stable" enough, otherwise there is 9.10 Beta around the corner
Jill: i dont need it, ubuntu
tormod: Jill, we see that :)
Jill: very bad ru support channel
Jill: and they too fast update it
Jill: i have poor internet speed now
tormod: are the ru support channels better for archlinux and debian?
josmala: Well you could skip everyother update and still get securit patches.
Jill: in arch they are right, in debian they are quiet
Jill: in ubuntu they are idiots
tormod: Jill, for your poor internet speed, Ubuntu can mail out a free CD to you, https://shipit.ubuntu.com/
Jill: they talking about "how to install XP on usb-stick" or "how to fix something in registry of XP"
Jill: i know
tormod: Jill, bring that up with the local Ubuntu team, to get rid of the "idiots" (but now we are really off-topic for this channel)
Jill: but if i need something else of debian - arch, asp i like
Jill: tormod: ubuntu developers are not ubuntu operators of ru support channel, and i doesnt mean eng channel
Jill: okay lose offtop
Jill: can i do something with this piece of "pie"?
Jill: i dont know why but it feels debian is good
soreau: Jill: You should probably tell the debian folks you need an updated system with at least X 1.5.x to get better driver performance and let them help you
Jill: soreau: thanks, i will do that now
Jill: they must be know how to help =)
Jill: bye
fpoibaf: MrCooper: do you plan to commit the patch at http://marc.info/?l=mesa3d-dev&m=125370276029279&w=2 ?
fpoibaf: it fixes a corruption problem I was having with sauerbraten
MrCooper: yeah, just need to find the time
diverse_izzue: hi all. i observe a three-fold reduction in 2d performance (measured with gtkperf) when using kms/dri2 as opposed to dri1. the performance reduction is also well perceivable when using the system, especially in apps using lots of widgets such as evolution.
chainsawbike: diverse_izzue, as far as i know dri2 is still rather unoptimised
chainsawbike: ... kms/dri2
diverse_izzue: chainsawbike, i know that, but somehow assumed that was only related to 3D, apparently i'm wrong...
hifi: RV690 doesn't work with vsync, XV and GL are both drawing black or nothing
hifi: disabling vsync from DDX fixes both
hifi: RS690 I meant
Lutz_Ifer: so far for "with new videocard everything will be better"
Lutz_Ifer: computer doesn't boot if connect more than one monitor. crap.
soreau: Lutz_Ifer: At what point in the boot process does it fail?
Lutz_Ifer: absolute beginning
Lutz_Ifer: monitors don't turn up, no bios beep
Lutz_Ifer: and yes, extern power is supplied for that videocard
soreau: Well, that doesnt have anything to do with the radeon drivers then..
soreau: Rather one or more of your hardware components are likely faulty
Lutz_Ifer: i know, i just had to let of steem...
Lutz_Ifer: "don't buy hardware at ebay" was right another time
Lutz_Ifer: ironically, the card works fine if i just connect one monitor instead of both
adamk_: Morning all.. What would cause an "undefined symbol: radeon_cs_space_reset_bos" error?
roysjosh: adamk, old libdrm, I think. see http://cgit.freedesktop.org/mesa/drm/commit/?id=39970c67b77014caac9a4c3a33765ac7a312b54e
roysjosh: adamk_, ^
adamk_: Hmmm..
adamk_: Thanks.. I'm not sure I updated that on this machine.
adamk_: roysjosh, That did it. Thanks again.
roysjosh: adamk_, you're welcome
Terman: what's the address to clone the drm-next git?
octoploid: Terman: git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
Terman: octoploid: thanks!
octoploid: Terman: But if you use git already (linus tree) a git pull would be easier...
Terman: octoploid: no, I use a "standard" distro source tree
Terman: octoploid: an drm-next tends to contain newer patches, or am I wrong?
octoploid: Terman: yes.
Terman: octoploid: who wants to run semi-tested code ;->
Neo_The_User: airlied: go ahead and kick and ban me or whatever I don't care I'm switching to Windows soon so I can play racing games with my new force feedback steering wheel but I can't get 3d working with r600 KMS. drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info. I am on my archlinux machine. Here is my dmesg: http://pastebin.ca/1582724 Thank you in advance, if you decide to be a helpful
Neo_The_User: human being. :)
nanonyme: Neo_The_User: Is that dmesg fater the error?
Neo_The_User: yes
nanonyme: Immediately after it? o.O
Neo_The_User: what?
Neo_The_User: i did glxgears, then i typed dmesg
nanonyme: That is, after you got drmRadeonCmdBuffer -22.
nanonyme: Right.
nanonyme: That's odd then.
Neo_The_User: so 3d is supposed to be working>
nanonyme: Last lines in dmesg should be related to the -22 error.
nanonyme: You have none such there. :)
biotube: what about "[drm] Initialized radeon 1.31.0 20080528 for 0000:01:00.0 on minor 0"?
Neo_The_User: http://pastebin.ca/1582727 and http://pastebin.ca/1582729
nanonyme: biotube: That's normal.
nanonyme: It means /dev/dri/card0 got created by radeon module.
biotube: i was wondering about the version numbers
nanonyme: Afaik.
nanonyme: The version sounds fine for non-KMS.
Neo_The_User: but i have kms in my kernel
nanonyme: Hrm...
Neo_The_User: should i recompile radeon?
nanonyme: Lemme recheck...
nanonyme: Yeah, with KMS you should have 2.0.0 there, I thi nk.
Neo_The_User: ok
kdekorte: Neo_The_User, if you have kms in your kernel you need to compile libdrm with --enable-experimental-radeon-api and then recompile the ddx and make sure you run autogen.sh as part of the ddx compile
Neo_The_User: oh totally forgot about that!
yangman: (II) [KMS] drm report modesetting isn't supported.
yangman: >.>
nanonyme: kdekorte: Yeah, the thing here is his DRM modules seem to not have KMS (at least enabled).
Neo_The_User: kdekorte: --enable-radeon-experimental-api you mean :P
kdekorte: nanonyme, he should make sure that he don't have any old radeon.ko files around. including in his initrd (I had the -22 problem and that was my issue).. there was an old radeon.ko in /lib/modules/[kernel ver]/extra that needed to be deleted
kdekorte: Neo_The_User, yeah, just doing it from memory...I have it all in scripts to rebuilt
Neo_The_User: heh
nanonyme: kdekorte: Yeah but I think dmesg should at least say *something* with -22...
kdekorte: also you have to rebuilt mesa (after doing make distclean) after you build and install libdrm
Neo_The_User: right im rebuilding everything
biotube: if the module doesn't enable KMS, the ioctl's invalid(or so it seems), so dmesg wouldn't register it(unless I missed my guess)
kdekorte: are you doing distcleans first and would recommend autogen.sh for at least the DDX
Neo_The_User: yep
kdekorte: nanonyme, when I had the -22 issue it did not report to dmesg at all, just on the command line I believe
kdekorte: Neo_The_User, also do "modinfo radeon | grep filename" and make sure it is in the drivers/gpu/drm directory
Neo_The_User: /lib/modules/2.6.31-ARCH/kernel/drivers/gpu/drm/radeon/radeon.ko
kdekorte: ok, looks good
Neo_The_User: :)
nanonyme: kdekorte: For me it has always reported in dmesg, that's how you get to debug...
Neo_The_User: i need to restart brb
Neo_The_User: ok i have everything as far as logs and stuff goes. no 3d yet. http://pastebin.ca/1582756
Neo_The_User: it still says i have old radeon but i updated that >:O
dmb: looks like 3d is working?
Neo_The_User: [neo1993@archie ~]$ glxgears drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info.
dmb: oh, no idea then :/
Neo_The_User: oh well... back to fglrx. later fellerz!
biotube: anybody else test non-KMS r600 3d?
adamk_: biotube, I've used it.
biotube: well, only thing I could think of was that it was borked, but that's out the window
kdekorte: Still looks like Neo_The_User has an old radeon.ko... but oh well he is gone now...
twnqx: hi guys
twnqx: after i got my displayport working for video
twnqx: is it possible that there's something that needs to be set up to get the audio there as well?
Luzipher: hi ... just a short question: do I need xserver 1.7 with kernel 2.6.32-rc1 and git master mesa/radeon-ddx/libdrm ?
AStorm: 1) no 2) not really 3) yes
AStorm: as in 2) you can use drm-next on top of 2.6.31
Luzipher: AStorm: ehm ... ok :) actually I just wanted 2d to run on 2.6.32-rc1, without fancy drm-next stuff, but something stopped working (it wasn't 2.6.32's fault): my screen just stayed black when starting X ... 1.7 solved that
AStorm: 2.6.32-rc1 should be ok
AStorm: nah, 1.7 is not necessary
AStorm: just the new libs and ddx
Luzipher: AStorm: as i said - everything stayed black with 1.6.4 and git-master mesa/libdrm/radeon-ddx
AStorm: ?
AStorm: shouldn't
Luzipher: I should have left the kernel out in my original question actually: do git-master libdrm/mesa/radeon-ddx need xserver 1.7 :)
glisse: airlied: r520 patch should be good i shouldn't respawn 3 times before having it right ;)
glisse: both were tested with 3d + suspend/resume
AStorm: Luzipher: they don't
AStorm: you probably haven't rebuilt ddx after updating libdrm
glisse: hopefully i should be done this week with the remaining asic
Luzipher: hm, ok, I'll try what vgaarbitration does now ... and then have a look at the logs when it didn't work
Luzipher: AStorm: I think i have, but thanks for the info
Luzipher: AStorm: will test that as well and try to go back to 1.6.4 ... thanks again
wiwar: Hello, my gnome halts the computer if I try to logout, what I chould to check ?
rehabdoll: uh, gnome?
wiwar: here is my xorg.conf - http://pastebin.com/f9f3f8d3
wiwar: And this is /var/log/Xorg.0.log - http://pastebin.com/f618e4bde
wiwar: rehabdoll: I believe it is radeon driver who have a wrong configuration
Neo_The_User: before i switched to fglrx i gave it one more shot and 3d works but im getting /msg NickServ identify <
Neo_The_User: sorry. do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Neo_The_User: Try adjusting the vblank_mode configuration parameter.
nanonyme: That's normal.
Neo_The_User: oh ok
g-zu: same thing as Luzipher happened to me earlier today after upgrading to 1.6.4, I had to switch to radeonhd, the driver works well with 1.6.3.901
g-zu: and staying black --- well, I logged in remotely - X crashed in some dga access call and didn't return to console mode after
g-zu: it's something with xorg-server 1.6.4
twnqx: gentoo blacklisted 1.6.4 - prolly for a reason
g-zu: twnqx: I must have synced just before they blacklisted it
twnqx: hrhr
twnqx: you're not the only one
nanonyme: g-zu: Which ddx do you have, btw?
g-zu: nanonyme: what's ddx again? the driver or drm?
twnqx: my last remaining problem is currently no audio on the displayport
twnqx: :((
nanonyme: g-zu: X driver.
twnqx: git <3
g-zu: x11-drivers/xf86-video-ati-6.12.4
twnqx: heh
twnqx: xf86-video-ati: git, mesa: git, libdrm: git
twnqx: the only driver so far that at least got me video on the display port
twnqx: fglrx didn't even get me a picture on the internal display >_>
g-zu: twnqx: I don't have a displayport monitor :D
twnqx: neither have i. but i have a displayport -> hdmi adapter.
g-zu: otherwise I probably would use the latest too, I used to do regular updates from git a while back, but now I don't anymore
twnqx: and sadly this laptop doesn't have an HDMI port :X
g-zu: nanonyme: should I have used the git ddx with 1.6.4?
nanonyme: g-zu: I don't know but there's been going back and forth with DGA-related stuff in ddx git.
g-zu: oh
g-zu: nanonyme: I think it crashed in initialization, I wonder why radeonhd survived it though
nanonyme: I think DGA initialization is disabled in current radeon git. ;)
g-zu: is there any software left that uses dga?
g-zu: I think it could be removed completely
nanonyme: Iirc the idea is to stop it from initializing and only use the parts that are useful.
nanonyme: Iirc some games use the mouse stuff in DGA still.
g-zu: sad, IMHO dga should have been obsoleted for quite some time now
g-zu: and removed
twnqx: like xinerama
g-zu: if it were up to me once something has a replacement component it should be marked obsolete with very next release and in less than a year removed completely, let antiquated stuff die
g-zu: it just increases complexity in maintaining compatibility
twnqx: can someone link me to the docs for the hd3650?
rehabdoll: i think everything is in x.org/docs/amd or something
Luzipher: AStorm: if you remember my problem from earlier: it's caused by xserver 1.6.4. Both, 1.6.3 and 1.7 work though.
EruditeHermit: hey tormod
tormod: hi
Luzipher: so ... xserver 1.6.4 and current libdrm/radeon-ddx doesn't work for me ... it seems X fails and then fails to restore console or something. As I said, xserver 1.6.3 and current git do work with the same libdrm/radeon-ddx
AStorm: luzipher: interesting
AStorm: I recommend reporting a bug on fd.o
Luzipher: if someone wants to take a look: here is Xorg.0.log: http://pastebin.com/m4ad906d9
Luzipher: and dmesg: http://pastebin.com/m78f536d4
Luzipher: Astorm: which category ?
AStorm: Luzipher: hmmmm
AStorm: not sure
AStorm: try vs xserver
nanonyme: g-zu: DGA is hardly deprecated yet for the input parts. Maybe it will become such with XInput2 but hardly yet.
Luzipher: AStorm: ok, will do, thanks
twnqx: Luzipher: it seems to be broken
Luzipher: twnqx: what exactly ? :)
twnqx: i read today reports from at least 4 people having issues and saw it masked as do-not-use inside gentoo
twnqx: xorg 1.6.4
Luzipher: twnqx: saw a mask too, but only because of intel
AStorm: how can you mess up a stable release? ;p
Luzipher: twnqx: and that seemed to be patched already
twnqx: same thing as Luzipher happened to me earlier today after upgrading to 1.6.4, I had to switch to radeonhd, the driver works well with 1.6.3.901
twnqx: :P
Luzipher: well, radeon works well with 1.6.3.901 as well :)
g-zu: nanonyme: well, didn't know that, I retract my statement in that case
nanonyme: g-zu: True, the display parts of DGA haven't been used for a long time due to them being an obscene security risk. ^^
nanonyme: I recall reading it could be safely implemented on top of KMS if anyone has way way too much time though.
nanonyme: Probably not worth it though.
DanaG: What is DGA, anyway?
DanaG: oh, google.. right.
g-zu: Direct Graphics Access, I didn't know it was used for input too
g-zu: name suggests only graphics
Zajec: what is difference between XvMC state tracker and g3dvl?
yokto: I have a question about gallium. wasn't the whole point of gallium that developpers wouldn't have to implement all the different rendering apis but could just write a gallium driver and be done with it - if so why are there so many different gallium entries in the radeonFeature matrix http://www.x.org/wiki/RadeonFeature ?
airlied: yokto: you have to implement interface code
Luzipher: AStorm: bug is already reported: https://bugs.freedesktop.org/show_bug.cgi?id=24200
nanonyme: airlied: And partial support implies parts of interface code are only partially or incorrectly implemented, aight?
yokto: interface code? is there any detailed information on the whole gallium thing available some where all I could find so far were a few vague sketches and on the tungston website the just say the interface is in the header files which sounds kind of scarry.
kainz: yokto: welcome to driver development ^_^
adamk_: GLX_EXT_framebuffer_object requires KMS?
nanonyme: Sounds like it.
AStorm: yokto: you expect docs from devel code?
AStorm: laughed
airlied: nanonyme: or the state tracker is only partially implemented
airlied: yokto: generally you have some gpu specific code you need to write
airlied: this is less than writing the whole state tracker , but no 0
kainz: airlied: are there any testing and/or data collection tasks an old RV380 would be useful for?
kainz: (PCIE radeon x600)
airlied: kainz: testing kms on it is always worthwhile
adamk_: Any thoughts about compiz crashing with "blur window" enabled: http://pastebin.com/ma1b3ecb
adamk: Well that's cool. With KMS disabled, trying to start compiz with blur enabled crashes the X server.
MostAwesomeDude: yokto: You wanted to know about Gallium? :3
MostAwesomeDude: The reason I put all the different Gallium status squares on that page is because I won't fill them in if they don't work.
MostAwesomeDude: GalliumStatus is much the same thing.
MostAwesomeDude: http://www.x.org/wiki/GalliumStatus
airlied: adamk: indirect rendering
soreau: adamk: Which type of blur is crash there?
soreau: motion, alpha or focus (it shouldn't be the latter)
adamk: soreau: alpha
adamk: Heh.
adamk: Alright, KMS enabled. Without LIBGL_ALWAYS_INDIRECT, compiz crashes. With LIBGL_ALWAYS_INDIRECT=1, X crashes
adamk: Alright, enough fighting with this.
adamk: I have to get some work done now.
soreau: airlied: I did some testing with tv-out and it seems in 'clone' mode where VGA-0 is 1280x1024 and the tv just shows the upper left 800x600 of the screen, using compiz ezoom (enhanced desktop zoom) the upper 800x600 of VGA-0 does not zoom but remains static while the rest of the VGA screen does (tv also remains static) However when I set S-video --right-of both work independently/correctly
soreau: This happens regardless if it's direct or indirect rendering
soreau: This screenshot demonstrates the oddity http://omploader.org/vMmZ4YQ
airlied: soreau: bug in compiz most likely
nanonyme: rnoland: Btw, wonder if it'd be altogether impossible to write a non-glibc-dependent solution for that random thing, maybe something that would only depend on pthreads or so. ^^ (if a system doesn't have pthreads, I might just start crying ;P)
nanonyme: (glxhash hash random macros, that is)
lavaburn: hey guys, i'm having some trouble building the xf86-video-ati DDX - anyone care to have a look at my build log?
lavaburn: http://lavaburn.untergrund.net/files/build.log
rnoland: nanonyme: my patch should deal with saving restoring state on POSIX boxes... it doesn't explicitly deal with thread safety though...
nanonyme: Yeah, I was wondering about the how to do it in a thread-safe manner without relying on glibc.
nanonyme: And whether it would be insanely hard to do.
airlied: glibc fixed the problem, other libcs probably need to do the same
kainz: nanonyme: obsd doesn't have a very functional pthreads
rnoland: nanonyme: might could just add a lock/unlock to INIT /DESTROOY
soreau: airlied: Well that took longer than expected, but here on UMS with 2.6.31 it works as expected (so it's not a compiz bug ;)
rnoland: but since i've not seen the bad behavior either before or after, my compulsion to fix it is weak...
airlied: soreau: even with cloned tv?
soreau: Correct
lavaburn: any remote ideas on my build issue? :(
soreau: I would bisect but to my knowledge, I don't know that there was ever a good commit where this worked
soreau: (running kms)
soreau: lavaburn: What does you VIDEO_CARDS="" look like in make.conf?
lavaburn: i have radeon and radeonhd in there under VIDEO_CARDS
lavaburn: i get the same exact error whether i try the -9999 ebuild or try and compile a git pull
soreau: lavaburn: Looks like you're missing some prerequisites/dependencies AFAICT
lavaburn: Hmm, I made sure I had the mesa master and libdrm up to date as well as the newest xorg git and all of its dependencies, this one's really puzzling me
soreau: lavaburn: Which kernel are you running?
lavaburn: 2.6.32-rc1, i have KMS working successfully, I'm, just X-less now :)
soreau: lavaburn: I'm updating my system to see if I might be able to reproduce your issue but I have a feeling I wont be able to. You might need to ask someone more knowledgeable like chithead
lavaburn: I appreciate your effort mate, thankyou :)
lavaburn: I wonder how i can ensure every single last thing that video-ati depends on is up to date...
soreau: is wondering if 2.6.32_rc1 has any drm-next in it at all
lavaburn: Should I scrap the kernel compiles drm and build drm-next?
lavaburn: *compiled
biotube: 2.6.32 was supposed to have it, but it came out so quick
EruditeHermit: soreau, what is UMS?
stikonas: UMS == Userspace Modesetting
mixstirssi: Just looking for confirmation - running Gentoo minimal install CD and to see what I should list for VIDEO_CARDS in make.conf, friend asked for lspci output and then said they thought "r128" would be appropriate (output from lscpi regarding video card: 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X (rev 5c) )
rhodan: Fragmented memory, mplayer crash. Goddammit.
MostAwesomeDude: mixstirssi: r128, yes.
mixstirssi: MostAwesomeDude: thanks
rhodan: http://dpaste.com/99594/
g-zu: mixstirssi: wow, those are still around?
mixstirssi: g-zu: Well, it's an old box that's been around for a long time
wiwar: Hello, can anybody help me with http://bugs.gentoo.org/show_bug.cgi?id=286833
g-zu: wiwar: do you use a session manager?
rhodan: wiwar: Yep, it's "lost" instead of "lose". Glad I could help you.
wiwar: g-zu: I start x-session with
wiwar: startx command
rhodan: Btw: Why is gl suddenly so much better than xv? I alway thought it should be the other way around?
wiwar: rhodan: thanks
g-zu: wiwar: well, I don't know what to say, are you sure the computer hangs? have you tried to ssh in from another machine?
soreau: EruditeHermit: stikonas is correct WRT UMS
_moep_: hey
wiwar: g-zu: Yes, I did. It doesn't respond
wiwar: g-zu: even to ping too
soreau: Does 2.6.32_rc1 have any drm-next bits? or.. what are the correlation (if any) between the two? (wrt drm-next)
g-zu: wiwar: I guess until this is fixed you have to sync and poweroff instead of logging out... I don't know what's happening, the information is not good enough to draw any conclusions
wiwar: what kind of information should I add ?
g-zu: some debugging information just before the crash, you should be able to get that with a remote console somehow
wiwar: g-zu: it is too complex for me...
g-zu: wiwar: there are tutorials on the web on how to get that information
g-zu: but if you're too lazy to follow them just run sync from a console and power off, this way you won't lose data
wiwar: ok, I understood that
g-zu: alternatively you might add sync to your sensitive filesystems in fstab
g-zu: if they have that option, and also set syncronous write-back for your hdd via hdparm
g-zu: but this will slow down disk accesses significantly in most cases
g-zu: wiwar: just out of curiosity, what fs do you use?
_moep_: hey I've some problems with my radeon card and the driver heres the log: http://mypaste.ja-s.de/1952
g-zu: _moep_: you have to recompile xf86-video-ati
_moep_: ack
_moep_: 10mins ago
g-zu: you upgraded your xorg-server but did not update the driver
g-zu: _moep_: you have to do it again after the server upgrade
g-zu: (EE) module ABI major version (2) doesn't match the server's version (5)
wiwar: g-zu, etx3
wiwar: ext3
g-zu: _moep_: this says that the module is older than xorg server
_moep_: g-zu: but in squeeze the xorg update was weeks
_moep_: +ago
biotube: could the -dev files be out of date?
g-zu: _moep_: X.Org X Server 1.6.3.901 (1.6.4 RC 1) --- and radeon_drv compiled for 1.4.2, module version = 6.12.99
_moep_: hm lets check
g-zu: _moep_: it's pretty obvious the video driver is for 1.4.2 while the server is 1.6.3.901
_moep_: ohh
_moep_: ls -l /usr/lib/xorg/modules/drivers/ | grep radeon
_moep_: -rwxr-xr-x 1 root root 956 29. Aug 05:23 radeon_drv.la
_moep_: but
g-zu: _moep_: you installed it in /usr/local
_moep_: ./configure --prefix=/usr/lib/
_moep_: thats was my prefix
g-zu: ./configure --prefix=/usr is the correct syntax
_moep_: ah :D
g-zu: _moep_: true
_moep_: root root 956 29. Aug 05:23 radeon_drv.la
_moep_: :)
_moep_: lets test again
g-zu: _moep_: did you forget a make install?
g-zu: if not try with a clean tree
_moep_: it did but same problem
_moep_: ok lets try make clean
g-zu: _moep_: make distclean
g-zu: this will also nuke the makefile
g-zu: and other nasty leftovers
_moep_: ./configure --prefix=/usr should be ok?
g-zu: that's what I've been using for years
biotube: if you don't want KMS
g-zu: never failed me
_moep_: dito
_moep_: root root 968 29. Sep 01:12 radeon_drv.la <- better
g-zu: congrats
g-zu: _moep_: does startx work now?
_moep_: nope but I here the system beep :D
_moep_: that what discripe in my bugreport
_moep_: http://bugs.freedesktop.org/show_bug.cgi?id=22562
g-zu: lol
_moep_: i post the hole xorg.conf
g-zu: _moep_: actually, can you temporarily renaming xorg.conf to something else and see if it works without it?
g-zu: ^^rename
_moep_: http://mypaste.ja-s.de/1953
_moep_: sure
_moep_: you mean no xorg.conf?
biotube: yep
_moep_: i tested with a livecd but same problem
g-zu: _moep_: yeah
_moep_: so a) its a radeon bug b) a configproblem
g-zu: _moep_: does it work without a xorg.conf file?
_moep_: wait
_moep_: nope. systembeep and nothing
_moep_: blackscreen
_moep_: some ideas?
soreau: _moep_: What problem are you having?
_moep_: soreau: i've good a blackscreen and no xorg error
_moep_: http://bugs.freedesktop.org/show_bug.cgi?id=22562
soreau: _moep_: Which live cd did you test with?
_moep_: ubuntu 9.04
soreau: _moep_: Well it probably wont work on debian using X 1.4.2 for that HD 4350 but I imagine 2D should at least work on Jaunty
soreau: _moep_: Have you tested with a different monitor to see if it's an 'out-of-range' issue?
_moep_: nope sorry no 2th monitor available
_moep_: but its squezze not stable :P
soreau: In both of those logs you have X 1.4.2 though
_moep_: xserver-xorg-core 2:1.6.3.901-1
soreau: Not saying that's necessarily the problem (though it is quite ancient), since you tried on a Jaunty live cd and have the same problem, I suspect hardware issue. Which is why I suggest testing with a different monitor
soreau: _moep_: What does 'X -version' say?
_moep_: X.Org X Server 1.6.3.901 (1.6.4 RC 1)
_moep_: Release Date: 2009-8-25
soreau: Well in the logs you posted in the bug report, they show you were loading X 1.4.2
_moep_: yeah look at the date ;) this was in july
soreau: Can you try plugging your monitor into the other port?
_moep_: nope the other is VGA :/
soreau: Then I'm out of ideas, sorry
_moep_: hm :/
_moep_: ok I post my full xorg into the bugreport
_moep_: hopes for agd5f
g-zu: _moep_: did you try the radeonhd driver?
soreau: Is there a place that tells you how to configure a kernel for kms?
g-zu: soreau: not that I know of
g-zu: but I can walk you through it, I did it already twice, it's not that hard
_moep_: g-zu: nope not with these card
soreau: g-zu: I already have kms working but wondering why it wasnt in the topic link
g-zu: _moep_: try it, you can try with and without the use of atombios, you might get lucky
soreau: _moep_: I have black screen when starting X a certain way. So try starting X with X -retro
g-zu: soreau: maybe they don't want people who can't figure it out to start shouting they're having problems with it :D
g-zu: it really involves a lot of updates to get it done properly
soreau: g-zu: I think it's because the kernel config is changing/evolving
g-zu: soreau: and finding the information and understanding what to do really filters out some of the less experienced users
soreau: _moep_: Well that was my fault because I forgot to put & after my X startup line ;)
g-zu: soreau: that might be true as well
soreau: _moep_: But still try it out
g-zu: but I think they'll keep it in staging for 2.6.32 as well
_moep_: soreau: ah little bit blink blink and then also black :D
soreau: g-zu: I think it's a bit of both. This whole bit really isn't designed for end users
_moep_: now again blinking and i see the gdm
soreau: _moep_: Try starting something.. X -retro & xterm
soreau: Or it might be X -retro & sleep 1 & DISPLAY=:0 xterm
g-zu: soreau: I think you mean && after sleep1
soreau: oh yea xD
g-zu: or at least ;
soreau: g-zu: Disclaimer: Not designed for inexperienced users
soreau: ;)
soreau: g-zu: You're completely right
soreau: But mostly you'd only need to sleep if you were starting something like compiz
_moep_: soreau: doesnt look better i can login but i see black, then much colourful pixelpoints
soreau: g-zu: But it's beer:30 here and I started early
soreau: _moep_: Can you switch to tty and back?
g-zu: soreau: grats
soreau: _moep_: I recall seeing something similar as the behavior you're describing when I was messing with mesa.. which kernel is this btw?
g-zu: _moep_: try radeonhd, really, it might work, it does initialization differently
soreau: is starting to think _moep_ needs to disable dri
soreau: If nothing else, just to test
_moep_: soreau: I had this problems also with disabled DRI
soreau: _moep_: What kernel are you running
_moep_: (but tested some months ago)
_moep_: 2.6.31.1
soreau: Is that to say _rc1?
_moep_: nope stable
soreau: Bah
g-zu: _moep_: is kms enabled in your kernel?
soreau: enough with this stable rambling
soreau: is not liking these debian-washed souls
_moep_: g-zu: uhhm dont now
soreau: ugh
_moep_: wait
_moep_: Symbol: DRM_RADEON_KMS [=n]
g-zu: great
g-zu: _moep_: try Option "AccelMethod" "ShadowFB"
soreau: No telling what else he has misconfigured in there too :P
_moep_: g-zu: i did
g-zu: _moep_: and?
_moep_: Option"AccelMethod" "exa" # default shadowfb
_moep_: is in my config
g-zu: does it work?
_moep_: nope :)
_moep_: is my default
g-zu: _moep_: comment the AccelMethod, DRI and BusId lines and try again
_moep_: ok
_moep_: nope
_moep_: same problem
g-zu: and if it still fails I strongly suggest: git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-radeonhd; cd xf86-video-radeonhd; ./autogen.sh --prefix=/usr && make && make install && sed s/radeon/radeonhd/ -i /etc/X11/xorg.conf ; startx
_moep_: i did
_moep_: ;)
g-zu: radeonhd fails too?
_moep_: 02:01 < _moep_> soreau: ah little bit blink blink and then also black :D
_moep_: it shows me more details like radeon but in the end... yes
g-zu: _moep_: I'm afraid you're going to have to use vesa or something else, until this is fixed
_moep_: I know but hmm vesa suxx :)
_moep_: g-zu: soreau: thx for help... its late go to bed thx!
g-zu: _moep_: apparently do does your monitor or some of the other libs you have installed
g-zu: s/do/so/
soreau: g-zu: Until what's fixed? The PEBKAC issue?
_moep_: g-zu: ok i try to check a other TFT
_moep_: gn
_moep_: cya
g-zu: bye _moep_
g-zu: soreau: lol
g-zu: soreau: that might well be the problem here :D
yangman: was there an explicit fix for composite+GLX causing hangs or did that just get resolved as other things were being changed?
g-zu: night soreau I'm tired
g-zu: night yangman
soreau: yangman: When did this start happening?
yangman: soreau: really old bug. it's resolved now
soreau: mmk
DanaG: Mmm, build fail: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32-rc1/BUILD.LOG
soreau: DanaG: I'm having trouble seeing how that's related to radeon stuff
soreau: Looks like karmic fail to me
DanaG: heh, it's really not. =รพ
DanaG: Aside from the fact that I need that kernel if I wanna' try the new goodness in 2.6.32.
DanaG: without building it myself.
DanaG: Then again, maybe I should just.... build it myself.
soreau: I just finished the same process sans the karmic fun and worked fine first time
soreau: DanaG: If you run drm-next, you probably have later code than whatever's in 2.6.31_r2
DanaG: I currently don't, but if I'm going to build anything at all, I might as well go with drm-next.
DanaG: slaps himself with a fish, to perhaps motivate himself to stop being lazy.
DanaG: hmm, but how do I git branch? I always have trouble with that... it likes to give me the "you haven't told me which branch to pull from" thing.
soreau: /topic
DanaG: hmm, that tells how to run it on top of 2.6.31.
DanaG: agh
DanaG: ah
DanaG: "alternatively use drm-next as is"
DanaG: oh yeah, one handy thing somebody could add to the wiki:
DanaG: a way to force the radeon driver to not load, would be to pass an invalid parameter.
DanaG: radeon.goaway=1, or something like that.
soreau: What's wrong with patching .31?
DanaG: I'm feeling daring; I might as well use drm-next as-is.
soreau: Why go from one extreme to the other? Just stick to the guided plan
DanaG: hmm, does changing cpu-type from "generic x86_64" to "Core 2" make much difference in anything?
biotube: optimizations
dbbolton: i need some help figuring out why an X update broke my system. x was working fine with the radeon driver, and now it won't start. here are the errors i get: http://pastebin.com/d306b438e
dbbolton: i already had firmware-linux installed, and i tried re-installing it. i also tried installing a new kernel, booting it into single user mode, then building the radeon driver from deb src
soreau: dbbolton: Please post your full log when asking for support
dbbolton: full log: http://pastebin.com/d1300744f
funnyman3595: Hey, folks. I have a problem and I think I know the cause, but I'd like to confirm that.
funnyman3595: The problem is that DRI isn't working. Xorg log says: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed (libdri.a too old) // [dri] Disabling DRI.
funnyman3595: From what I see, I think the problem is that this file is missing: /usr/lib/xorg/modules/extensions/libdri.so
soreau: dbbolton: Well you should use exa to get acceleration working but that's not the problem. I's segfaulting around the time it's doing stuff with xrandr so make sure if you've built your X server, your xrandr related packages are in sync / up to date
soreau: funnyman3595: Please post the full X log
funnyman3595: Package manager reports it as installed by xorg-server, but the file isn't there, despite reinstalls.
dbbolton: soreau i didn't build xserver, just installed from debian sid repository
soreau: dbbolton: Perhaps you should ask them why it's failing then. AFAICT, this isn't an issue with the radeon driver
biotube: it could be you didn't upgrade everything
funnyman3595: soreau: http://pastebin.ca/1583589
dbbolton: biotube it isn't a mixed system
soreau: funnyman3595: Both libdri.so and libdri2.so weren't installed to the right place if at all. Have you tried rebuilding your X server?
funnyman3595: soreau: Trying again now.
soreau: dbbolton: Did you make sure you have relevant package versions for ddx, libdrm and mesa?
dbbolton: soreau libdrm2, libdrm-intel1, libgl1-mesa-dev, libgl1-mesa-dri, libgl1-mesa-glx, libglu1-mesa, mesa-common-dev are installed. i dont know about ddx. search for it in aptitude didn't show any results.
biotube: xserver-xorg-video-radeon
soreau: dbbolton: I wasn't asking about the names your distro gives it's packages but rather the versions you have installed. ddx = xf86-video-ati (for your distro, what biotube said)
dbbolton: soreau http://pastebin.com/d379efed2
funnyman3595: soreau: Aha, I think I may have found the problem. Hadn't been general enough in enabling the version of xorg-server I needed, so it decided to downgrade when that one was deprecated.
funnyman3595: And the old version it used apparently has DRI2 forced off for some reason.
soreau: dbbolton: Try with Option "AccelMethod" "EXA"
dbbolton: soreau is it clear from my log why i can't hit crlt_alt_f1 to get to a terminal after starting X, but I can still ssh into that computer?
soreau: not from what I can tell
funnyman3595: dbbolton: For what it's worth, I run into that system when I haven't reinstalled the input drivers after upgrading xorg.
funnyman3595: *symptom
funnyman3595: X steals the keyboard from the rest of the system, but then can't read it.
funnyman3595: Alt+SysRq+R will make the kernel reclaim it, and might make Ctrl+Alt+F1 work again.
funnyman3595: It does for me.
dbbolton: funnyman3595 i have evdev, kbd, and mouse installed, as well as hal
funnyman3595: dbbolton: So do I, but unless I force them to reinstall after upgrading xorg, they don't get configured right or some such.
dbbolton: ok
funnyman3595: Might just be a Gentoo idiosyncracy.
funnyman3595: But it can't hurt.
dbbolton: i've had my share of X problems on gentoo and debian with this machine
funnyman3595: Matter of fact, I just hit it again. Heh. Was triggering it at the same time I explained it.
soreau: funnyman3595: Did you get your issue resolved then or are you waiting for xserver to build?
funnyman3595: soreau: Looks like, but I can't confirm quite yet.
soreau: funnyman3595: What do you mean?
funnyman3595: soreau: The files appear to be there now, but until I can, you know, log in, it's hard to see if it's working.
soreau: Why can't you login?
dbbolton: soreau here is my log after trying that option http://pastebin.com/d450c40ec
funnyman3595: Because X forgot how to use the keyboard when I upgraded, so I have to reinstall the input drivers to remind it.
soreau: funnyman3595: Perhaps you just needed to toggle AllowEmptyInput
funnyman3595: There we go. Reinstall finished, now I kick the X server...
funnyman3595: And presto, they work again.
soreau: dbbolton: idk why it's crashing like that but maybe you could try with only vga connected
funnyman3595: Aha. glxgears FPS just jumped an order of magnitude. Sounds like it's working again.
soreau: cool
funnyman3595: soreau: Yup, Compiz is once again happy with me.
dbbolton: soreau do you mean unplug absolutely everything except the vga
soreau: dbbolton: Well it's init'lzg VGA-1 instead of -0 for some reason
soreau: Then it crashes around the time xrandr stuff happens
dbbolton: soreau i have 2 vga out puts
soreau: So I'm just making a guess
funnyman3595: soreau: As I understand it, the issue is that Gentoo sees that you have a compatible version of the input drivers installed and doesn't realize that they won't work if compiled against the wrong xorg-sever version.
soreau: funnyman3595: Are you using S-video there?
funnyman3595: So once you upgrade xorg-server, you need to force it to recompile the input drivers before they'll work again.
funnyman3595: soreau: Probably not, it's a laptop screen.
soreau: ok
funnyman3595: But, yeah, if X won't take keyboard input and Ctrl+Alt+F1 doesn't work, Alt+SysRq+R might make the Ctrl+Alt+FX keys work again.
funnyman3595: does a "my computer is happy again!" jig and wanders off.
DanaG: hmm, I wonder if you can use fbcondecor with KMS.
DanaG: eh, the patches stop at 29, anyway. no 30 or 31.
tavl: my xorg is freezing, when starting with radeon as driver... no log messages at all... anyway to find out what is going on? (any other way to get error output than dmesg or /var/log/X11 ?)
mekius: tavl: can you ssh in from another machine?
tavl: mekius: no... i'm using it (with vesa as driver)
soreau: tavl: Can you paste the X log from the failed session?
tavl: soreau: there's none
soreau: How are you starting X?
tavl: soreau: the last entries in my xorg log are from my last SUCCESSFUL session, with vesa
tavl: soreau: startx
soreau: After running startx there is no log whatsoever in /var/log/?
tavl: tail /var/log/Xorg.0.log
tavl: (II) Open ACPI successful (/var/run/acpid.socket)
tavl: (II) VESA(0): Setting up VESA Mode 0x122 (800x600)... and so on... nothing about my execution using radeon...
soreau: Sometimes it will append .old to past logs
tavl: soreau: and, if i erase this file, change my xorg.conf to use radeon, startx... it freeze... only rebooting... and no Xorg.0.log in /var/log...
soreau: That's pretty bad if what you say is accurate
soreau: Can you try with X -retro instead of startx?
tavl: soreau: i have a dmesg.old, but nothing like Xorg.*.old
soreau: append as in appended to Xorg.*.log
tavl: $ X -retro ?? only this?
soreau: Well you could have a terminal I guess: X -retro & xterm
tavl: soreau: there's nothing like Xorg but my current Xorg.0.log...
DanaG: retro? I've never heard of that option.
soreau: Makes x start with a disco ball and orange couches
DanaG: Default to -br. Add -retro option for the nostalgic.
v1ttu: Hi
v1ttu: Is ANYONE here? :(
v1ttu: >_<
tavl: soreau: i used this command "X -retro -keeptty -novtswitch -ignoreABI -verbose -logverbose -logfile mylog.xorg vt0"... still frozen... but this time the log was saved... any clue? http://pastebin.ca/1583749
nanonyme: ignoreABI sounds like a very stupid switch.
soreau: So do many of the rest of them
soreau: tavl: Why are you using all those switches? The idea was supposed to be to keep things as simple as possible to a bare minimum
tavl: soreau: i tried only the -retro, but i got no log or else... still freezing..
tavl: soreau: this combination of flags gave me some log output, at least..
soreau: I could see where you'd try -lofile blah but why the rest? *shrug*
nanonyme: ignoreABI means pretty much "ignore that my X.org stack is broken"
soreau: And yes, your stack is severely broken