roysjosh: mael_, hmm I think the 'quiet' on the kernel command line may have eaten the important logs... maybe boot with 'debug drm.debug=15 3' ... runlevel 3 should keep the ioctls from appearing
mael_: yeah I thought the logs were pretty light
agd5f: roysjosh: the radeontool light command just tiggles the LVDS_ON bit of LVDS_GEN_CNTL which the drm alreadys sets/clears appropriately
agd5f: *toggles
roysjosh: agd5f, maybe it doesn't do it early enough? without that first `radeontool light off` I have a 0% resume rate, and with I have 100%... :\
ossman: agd5f, it looks like 125994ab30d4f0f126c62fa741ec62a52d69d7a8 should probably have increased the so-ver on libdrm_radeon
agd5f: roysjosh: does the latest drm work any better?
mael_: roysjosh, not much more verbose I fear http://pastebin.com/m2b7cf530
agd5f: roysjosh: does dpms work?
agd5f: ossman: libdrm_radeon isn't officially released yet so there are no versions
ossman: agd5f, I see
agd5f: won't be released until radeon kms comes out of staging
ossman: agd5f, airlied might need to add a constraint to the fedora packages then
agd5f: ossman: yeah
mael_: roysjosh, ok found my mistake. I have a debian, all the stuff is in /var/log/syslog. not messages
mael_: will repost
Luzipher: grrr, this was the third time I ran into this bug: https://bugs.freedesktop.org/show_bug.cgi?id=25311 ... did anyone ever look at it or can I provide some more information somehow ?
ossman: agd5f, I guess that explains the crash. but I'm not sure its related to my vsync issues unfortunately
roysjosh: agd5f, yes, dpms works fine- when I'm idle for a sufficient time, the screen goes black (screensaver) and then a little later off (dpms off). not sure on newer drm- it's running a 2.6.31 f12 kernel. I can try updating later.
agd5f: roysjosh: the radeontool light command does basically the same thing as dpms from the hw's perspective
agd5f: roysjosh: does resume work if you dpms off your panel then suspend?
rehabdoll: is it just me, or is the latest mesa master build broken?
agd5f: sleep 5; xset dpms force off; suspend
mael_: roysjosh, http://pastebin.com/m6e9295f1 I removed the "drm:radeon_crtc_cursor_move" messages and the ioctl messages
ossman: agd5f, do you remember if things are supposed to work via a buffer copy or a buffer swap?
roysjosh: agd5f, I'll have to get back to you on it in a few hours- the laptop is at home. is there any way it could be a timing issue? or would kms skip a path of code during suspend if the panel was already off via radeontool?
laumonier: opengl works with radeon driver????
Wizzup: sure, to a certain extend
laumonier: because i try to play to wow and it crash at the launch of it
agd5f: ossman: no kms pageflipping support yet for radeon
ossman: agd5f, so that's "buffer copy" then?
agd5f: roysjosh: kms won't skip a path due to radeontool
agd5f: ossman: yep
ossman: agd5f, at which point mesa will do a DRI2 CopyRegion call to the X server, which in turn calls the DDX radeon_dri2_copy_region() which calls CopyArea() to do the work
ossman: agd5f, and CopyArea() is the EXA function that doesn't have any vsync support?
agd5f: correct
ossman: so it was just my imagination that vsync used to work? :)
agd5f: could be
roysjosh: agd5f, but e.g. could that panel be considered as disabled (or something) and a loop through all active panels in kms then not call some code? e.g. if (panel->foo & RADEON_LVDS_ON) { code_that_kills_my_resume(); }
agd5f: roysjosh: nope
roysjosh: agd5f, hm. well, I'll have more info when I'm home. thanks!
ossman: is getting a bit frustrated here
ossman: agd5f, does the r600 chips just ignore the vline waits or how come vsync isn't working there? I cannot see any explicit checks for r600 chips in the code
agd5f: ossman: r600 doesn't have a blitter, it accumulates verts in a vertex buffer
ossman: agd5f, so it has its own set of EXA functions?
agd5f: it has it's own set of hooks like the other drivers
agd5f: but for the older chips, we could insert vline waits per rectangle
ossman: ok
ossman: if only there was a "yum downgrade to three weeks ago" command...
agd5f: ossman: it could still be done, you'd just have to try and do the vline what before the draw command
roysjosh: mael_, what modes are supposed to be set?
mael_: roysjosh, I have 2 screens, one CRT, one LCD
agd5f: but since you don't know what rectangles have accumulated, you'd have to wait for the blanking period
ossman: agd5f, I'm trying to find the path of least resistance here. find the component that changed between now and three weeks ago and revert that component
mael_: when the LCD is connected alone I got a correct modeline for 1680x1050
mael_: when the 2 screens are plugged, I only have one modline for 1680x1050 that doesn't work
mael_: the edid are the same in every case though
mael_: i-e Modeline "1680x1050"x60.0 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync (65.3 kHz) doesn't work and is the only one I get when the 2 screens are plugged
agd5f: mael_: can you pastebin xrandr --verbose?
mael_: agd5f, http://pastebin.com/m714c5e50
mael_: the modeline that works (and is detected when the LCD is the only screen, whether in DVI or HDMI) is Modeline "1680x1050" 147.00 1680 1787 1966 2252 1050 1053 1059 1089 -hsync +vsync
agd5f: mael_: what card is this
agd5f: ?
agd5f: mael_: is this a laptop?
mathbr: I recently rebuilt my kernel and built it with CONFIG_AGP=y; booting up until the point where X is supposed to start works fine but after that I only get a black screen and have to force my way out.
mathbr: dmesg for this: http://pastebin.com/m4e98443a
mael_: agd5f, no it's not a laptop it's a small factor acer with an IGP
agd5f: mael_: what chip?
mael_: x1250 or x1200
mael_: rs690
agd5f: mael_: can you pastebin your xorg log and dmesg?
mael_: agd5f, I suppose you don't want the drm.debug=15 dmesg but a less verbose one?
agd5f: mael_: I just want to see the connector stuff that gets printed when the module loads
mael_: http://pastebin.com/m18769552 < Xorg.log
mael_: agd5f, any chance you get those messages in http://pastebin.com/m6e9295f1 ?
agd5f: mael_: yup, got em
mael_: I can repost an other dmesg excerpt otherwise, you tell me what stuff you want grep'd
mael_: ah fine
mathbr: Should I also try "debug" and "drm.debug"?
agd5f: mael_: do you have the log with the 147 mhz mode that works?
mael_: agd5f, I can produce those yes
edgecase: i forgot where in history the ATI bios stopped using x86 code and went to tables... how about ATI Technologies Inc Rage XL [1002:4752] (rev 27) ?
agd5f: mael_: you might try a newer drm with the new pll option, depending on what version you are currently using
agd5f: edgecase: nope
edgecase: so Rage XL is x86 code?
mael_: agd5f, the 2.4.17 tarball
agd5f: edgecase: all of our roms are a mix of code and tables
agd5f: mael_: what kernel?
mael_: 2.6.33-rc4
edgecase: agd5f, where would the code to POST that card in linux-xorg live?
Ronis_BR: man, 3D performance without KMS is almos 5x better than with KMS... is there anyway to improve that?
ossman: gah!
ossman: agd5f, I got vsync back! seems to be mesa that's the culprit
ossman: agd5f, investigating...
agd5f: ossman: wow, how?
ossman: agd5f, I went back to some time before christmas
ossman: agd5f, I was fiddling with the DDX at the same time, so give me a sec and I'll confirm that it is indeed mesa that's the key
mael_: agd5f, ah funky, I had to reboot since restarting gdm failed to produce a non-flickering screen
mael_: and I don't have the correct modeline after reboot and only one screen connected but the screen is not dark
mael_: although it flickers a bit
laumonier: someone knows a website where i can configure my xorg.conf file?
ossman: agd5f, yeah, it's mesa. I'm back to running the latest DDX in F12
Zaba: with KMS, will it be possible to run X without setuid root?
agd5f: mael_: the 146.2 modeline is what's in your edid
agd5f: mael_: does loading the radeon drm with new_pll=0 help?
ossman: agd5f, that glsync program in mesa/progs/xdemos doesn't seem to be a good test for vsync
ossman: it never works for me, even though xbmc vsyncs very nicely now
agd5f: ossman: maybe they use different methods?
ossman: agd5f, probably
ossman: agd5f, the glsync program uses glXSwapBuffer
ossman: agd5f, but you can also make it sync on glFinish(), right?
agd5f: ossman: I don't think GL provides a sync mechanism natively, only via glx
ossman: agd5f, yeah it's all extensions
mael_: agd5f, sorry xchat was stuck. I just briefly saw a mention of new_pll=0 but that's all I had
agd5f: mael_: the 146.2 modeline is what's in your edid
agd5f: mael_: does loading the radeon drm with new_pll=0 help?
mael_: so the 147 modeline is not in the edid?
agd5f: mael_: I'm not sure where the other modeline came from
mael_: strange I had it before
mael_: ok sorry for the redherring
mael_: I'm trying with new_pll=0
Ronis_BR: man, without KMS radeon performance is better than fglrx :)
mathbr: Got a more verbose dmesg now: http://pastebin.com/mbb57c1c
ossman: agd5f, xbmc seems to be using the GLX_OML_sync_control extension. anything you're familiar with?
agd5f: ossman: sorry
ossman: further digging then
agd5f: ossman: http://dri.freedesktop.org/wiki/CompositeSwap
ossman: agd5f, this is all your fault btw. if it weren't for you finishing that blit code then I wouldn't have done an upgrade ;)
agd5f: ossman: so what changed in mesa that broke it?
ossman: agd5f, ooh, thanks. that will be helpful
ossman: agd5f, no idea yet. I guess I'll have to bisect it
mathbr: airlied: Do you have a minute?
ossman: agd5f, b5a408b works at least
hnsr: xming, is there a live ebuild of mesa in the multilib overlay?
Luzipher: hnsr: I'm giving up on the multilib-overlay for gentoo, I can't resolve all blocks / missing dependencies here - did you manage to get it working ?
hnsr: Luzipher, haven't really tried yet
ossman: agd5f, git reflog ftw, btw :)
Luzipher: hnsr: it's awful for me, but maybe that's my system, I also have the x11 and mozilla overlays active
agd5f: looks up git-reflog
ossman: agd5f, perfect for us unstructured slobs who cannot remember what we were doing last week :)
Eythan: Hello
mael_: agd5f, with new_pll=0 I have a blank screen
agd5f: mael_: ok
Hackus: Mmmmm.....
Hackus: This is ODD.
Hackus: "(--) RADEON(0): Chipset: "ATI Mobility Radeon HD 3870 X2" (ChipID = 0x9509)"
Hackus: I don't technically have a ATI 3870x2....I have two 3870's in crossfire config.
Hackus: Is there a difference if you have one card with 2 RV670's vs two cards with each thier own RV670?
Hackus: Anyone have a 3870? What is your chip ID?
Hackus: I bet everyone went to lunch. :-)
Hackus: <-Talking to himself.
MostAwesomeDude: You're sure you don't have an x2?
MostAwesomeDude: Because the PCI ID is what indicates that, and the ID doesn't magically change in Crossfire.
MostAwesomeDude: (Not to mention that Crossfire isn't supported.)
Eythan: Hello, i have a Sapphire RadeonHD 5850, can i use radeon driver ?
MostAwesomeDude: Eythan: Sadly, no. We don't support HD 5xxx quite yet.
Eythan: thx
Eythan: an ETA ?
Eythan: at least for 2D ?
Hackus: No, it is not a 3870x2. It is two MXM Type 3 cards in a latop connected via Crossfire.
ossman: agd5f, breakage is somewhere between 99637ba..0857f38
ossman: I'll see if I can narrow in on it
MostAwesomeDude: Hackus: O RLY?
Hackus: Quite specifically, a ATI 3870 is a single card with TWO GPU's on it. Here is a picture of my two cards:
Hackus: http://www.killernotebooks.com/info/ati_3870.html
Hackus: Woops! I meant ATI 3870x2 is a single card with TWO GPU's on it.
MostAwesomeDude: Hackus: Well, take one card out and see if it changes. :3
Hackus: Yes, I did, and it works.
Hackus: :-)
Hackus: (i.e. DRI functions correctly.)
Hackus: Its a HUGE pain to take the card out though just to run my favorite OS>
Hackus: I need the DRI to work, for my GPU project I am working on.
MostAwesomeDude: DRI doesn't work with two cards?
Hackus: Nope.
Hackus: Says something about VGA arb and then explodes.
Hackus: :-)
MostAwesomeDude: Considered not Crossfiring them?
MostAwesomeDude: Also DRI1/UMS or DRI2/KMS?
Hackus: Yes, I turned off the BIT on both cards but it doesn't help.
mentor: Is it not possible to soft-disable one card?
Hackus: No, because my BIOS sucks.
Hackus: :-)
MostAwesomeDude: KMS totally can boot an arbitrary number of Radeons and get them out of vgaarb.
MostAwesomeDude: So, are you using KMS?
Hackus: Yep.
Hackus: WOuld you like a pastebin of what happens?
Hackus: Huge explosion happens.
Hackus: X Universe explosion->http://pastebin.com/d776ffbf8
Hackus: The thing tanks pretty hard, but I haven't been able to figure out why yet.
Hackus: Is there a way in Xorg.conf I can turn one of the PCI devices off or make it ignore it?
Hackus: The cards are listed at these two PCI addresses:
Hackus: 03:00.0 VGA compatible controller: ATI Technologies Inc Device 9509
Hackus: 06:00.0 VGA compatible controller: ATI Technologies Inc Device 9509
chithead: Hackus: if you don't use vga arbiter, you can start X with -isolatedevice parameter
Hackus: Really?
Hackus: Let me look that up...
chithead: in the old days, I used that for multiseat setups
MostAwesomeDude: Hackus: Your DDX, when did you last update it?
Hackus: Oh...DDX..lemme see...about two weeks ago I rebuilt a full ddx and mesa, plus dri modules.
Hackus: It didn't help, so I reinstalled the Fedora 12 packages.
MostAwesomeDude: Because it looks like most of the mess in your Xorg log is you playing a video with an old DDX.
Hackus: I think I spentPlaying a Video?
Hackus: I mean, Playing a Video?
Hackus: What do you mean?
Hackus: That log was from a manually loaded radeon kernel module and a manual startx from the command line.
philipp64: my Samsung T240HD has broken EDID info. it says its DisplaySize is 160x90 ...
Hackus: (Just to make sure stuff was loaded in the right sequence.
chithead: at least they got the aspect ratio right
agd5f: Hackus: R500DisplayTexturedVideoCP shouldn't be in your log, 3870 is an r6xx chip
Hackus: !!!!
Hackus: Quite right.
taiu: Hackus: you reposted another guy's pastebin
Hackus: Gazooks, I got my pastebins screwed up!
Hackus: <-Stupid
phercek: agd5f: regarding bug: https://bugs.freedesktop.org/show_bug.cgi?id=26199
philipp64: chithead: not even. it's 1920x1200 (so 16x10, not 16x9)
Hackus: Lemme repaste.
chithead: philipp64: file a bug on bugs.freedesktop.org so they add an edid quirk to the X server
phercek: agd5f: looks like the bug is not completely repeatable: when I tried today the machine did not even boot when I disabled agp fast write; when I enable it it did boot without error
phercek: agd5f: so I
agd5f: phercek: AGP is pain. you can try Option "BusType" "PCIE" in the device section of your config
agd5f: or if you are using kms, radeon.agpmode=-1
phercek: agd5f: so I'm not sure I can create a set of dmesg, xorg.log and xorg.conf at one time which shows the bug as I saw it / reported it
Hackus: Sorry your most Awesomeness....here is my new pastebin: http://pastebin.com/m21ac8791
Hackus: :-)
agd5f: Hackus: try forcing the busid in your xorg.conf
Hackus: Alright, I will try that.
philipp64: chithead: I've not filed such a bug before... can you point me at one so I know what to provide?
Hackus: Right now I am running without a xorg.conf. I will whip one up and try it out though.
Hackus: Thank you.
mancha: what does radeon.agpmode do?
Hackus: Can I ask a question?
phercek: agd5f: just tell me what you want me to try; as for as me I'll can work even with sw renderer; do you want me to try to boot with radeon.agpmode=-1 ? ... the problem is I cannot reproduce the bug as I reported it :-(
philipp64: Oh, also, I entered the correct DisplaySize, but I still get the message: (II) Quirked EDID physical size to 0x0 cm \n (II) RADEON(0): Indeterminate output size
agd5f: mancha: sets the agpmode or -1 using the internal gart
Hackus: Where do all you guys reside? Are you at one location or multiple locations? (Airlied, MostAwesomeDude....etc.)?
mancha: ah ok, and since i don't use that what is the default? when do you need to set it manually?
chithead: philipp64: provide the edid and point out which are the correct values
mathbr: Any other ideas what I could do? I'd really like to get AGP/DRM/DRI working here.
chithead: philipp64: ah it seems an edid quirk already exists
mancha: is it something you try when you have issues on an agp card?
MostAwesomeDude: Hackus: airlied is .au, agd5f is .va.us, I'm .or.us
philipp64: chithead: so why does it say "Indeterminate output size" when you've already configured the size?
mathbr: mancha: Did you mean me?
mancha: no, i meant agd5f :)
agd5f: philipp64: make sure you have the displaysize option associated with the correct monitor section for the monitor in question
chithead: philipp64: not sure, you could include that part of the log in the bug report
mathbr: OK ;-)
agd5f: mancha: yeah
mancha: agd5f many thanks.
mael_: agd5f, any idea some other stuff I could try?
agd5f: mael_: you could try specifying a custom modeline
mael_: using xrandr you mean?
agd5f: mael_: generate one with cvt and add it with xrandr
agd5f: if it works, you can hardcode it in your xorg.conf
philipp64: agd5f: I have it in the section named "HDMI" (and not "HDMI-0").
mael_: last time I tried that with the 147 modeline it took it for the CRT connected on DVI-0 and not the LCD on HDMI-0
mael_: and I failed to get xrandr --addmode to work
agd5f: mael_: you have to add it to the output you want
mael_: but I will retry noneless and report
philipp64: I don't have a monitor section named for the output.
agd5f: mael_: if the mode doesn't exist you need to add it with --newmode
agd5f: philipp64: the monitor must have the same name as the output
mael_: agd5f, sorry I did that of course
mael_: it's just that using the mode later on did not work (i-e the monitor was still blank)
agd5f: mael_: try a different modeline
agd5f: Modeline "1680x1050_60.00" 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync
agd5f: or
agd5f: Modeline "1680x1050R" 119.00 1680 1728 1760 1840 1050 1053 1059 1080 +hsync -vsync
mael_: agd5f, ok
agd5f: mael_: also note the mode names
philipp64: agd5f: so it goes in the "HDMI-0" monitor section. ok. will retry.
mael_: yeah 1680x1050 conflicted with the existing one
mael_: I used my_mode
mael_: (but it doesn't display in the gnome applet which is annoying)
Hackus: Ok, tried with a set PC Bus ID: http://pastebin.com/m475365d3
Hackus: Here is the new Xorg.0.log: http://pastebin.com/m123adaa6
Hackus: Anything else you could suggest in the xorg.conf?
philipp64: chithead and agd5f: seems to not make a difference which Monitor section I put the displaysize in.
philipp64: I've put it in both "HDMI" and "HDMI-0".
mael_: agd5f, none of the 2 modelines you gave me are working. the _60 doesn't display anything, the R one displays, is stable for a few secs then flickers and turn black
ossman: agd5f, I'm narrowing in and I suspect Jesse Barnes' new DRI2 syncing thing is the culprit
ossman: unfortunately he constructed a large swatch of commits that don't work on DRI2 1.1
philipp64: agd5f: should I file a bug? xdpyinfo seems to report the correct size regardless...
mathbr: Just switched back to my Radeon 9600 and everything's fine. :-/
ossman: agd5f, "daf7fe69f7bd0caa955d30b43fc35b7ce0069b6b is the first bad commit"
mathbr: AGP, DRM, DRI work just fine. So I'm just gonna ask: is r7xx (rv730 in my case) supposed to work yet? The x.org wiki says it should, at least for 2D accel and XVideo which is all I need ATM.
mael_: agd5f, so the modeline solution doesn't work. I've moved the 1680x1050 LCD to DVI where it works and is almost flicker free in its native resolution
soreau: mathbr: Yes, it works. What problem are you having with it?
mael_: I've added a 1920x1200 LCD screen on HDMI-0 and it is blank/doesn't seem to work (although it flickered briefly)
ossman: agd5f, that commit makes sense. It seems he ripped out the old (working) code and replaced it with something that requires DRI2 1.2
mael_: could it be that the issue is with HDMI when there is more than one screen connected?
mathbr: soreau: AGP fails to initialize no matter what I try, thus no DRI any seemingly no Xvideo because of this. DRI renderer is always software rasterer, even though I'm using libdrm 2.4.17.
mathbr: I don't really know what to do anymore.
mathbr: If I try a kernel with CONFIG_AGP=y, I only get a blank screen where X is supposed to start. Dmesg for this: http://pastebin.com/mbb57c1c
mathbr: I'm right now using the one and same kernel perfectly fine with my Radeon 9600.
soreau: mathbr: Did you install the firmware for it?
mathbr: Both /lib/firmware/radeon/RV730_me.bin and /lib/firmware/radeon/RV730_pfp.bin are here, yeah.
soreau: maybe vesafb is messing it up
mathbr: In what way and what could I do about it?
soreau: what about firmware options in your kernel config?
soreau: Do you have CONFIG_FIRMWARE_IN_KERNEL and CONFIG_EXTRA_FIRMWARE with your firmware
soreau: Seems like it goes south when [drm] writeback test failed happens right after it requests the firmware
soreau: not sure if these are related or what it means
spstarr: back
soreau: front
spstarr: glisse: no, only with KMS + IRQ
spstarr: glisse: my intel GMA GPU has irqs with KMS and no stalls
spstarr: 32: 1444611 199496 PCI-MSI-edge i915@pci:0000:00:02.0
mathbr: soreau: # CONFIG_FIRMWARE_IN_KERNEL is not set
jcristau: you don't need that if you build radeon as a module
mathbr: I'd go with any solution ATM as long as it works™.
agd5f: ossman: file a bug
agd5f: cc jesse
soreau: mathbr: Also did you try booting with radeon.modeset=1 to enable kms?
ossman: agd5f, okay
agd5f: mathbr: r7xx works as well as r6xx
agd5f: so 2D, Xv, 3D
GNU\colossus: what do you think, is a 4350-class card enough to push Quake 3 at 1920x1200x24 at playable (>=60) fps using free drivers?
MostAwesomeDude: Should, yes.
mathbr: agd5f: Yeah, read your blog entries. More reason for me to despair. :-/
mathbr: soreau: Any other things I could try out when I put back my new card?
mathbr: agd5f: Did you see my recent pastebin's?
agd5f: mathbr: what are you trying to do?
spstarr: glisse: im at a standstill basically, for testing radeon w/o KMS isn't going to give all the benefits and additional functionality only in KMS
GNU\colossus: MostAwesomeDude: cool. thanks for letting me know :)
soreau: fwiw, xbmc looking awesome with milkdrop on rv350 with kms+classic mesa
mathbr: agd5f: Just using my new card with 2D accel and XVideo. If I can get 3D accel, too I'm happy.
soreau: MostAwesomeDude: I downgraded mesa and drm-radeon-testing to somewhere around jan1st, but gallium is still slow slow slow. What else could have happened?
agd5f: philipp64: if xdpyinfo reports correctly, then I think you can ignore the message
mathbr: If I put it in right now and boot with exactly the same xorg.conf and exactly the same kernel all I'll get is a X freeze again.
agd5f: mathbr: r7xx agp card I take it? using kms?
MostAwesomeDude: soreau: Not sure. I just pushed some stuff earlier that hopefully brings everything back up to prior speeds.
mathbr: RV730 yeah, tried with radeon.modeset=0 and without it. Not with radeon.modeset=1 yet. Is this supposed to work better? Should it affect the things happening in the dmesg I posted recently?
glisse: spstarr: did you tested with old kms kernel which didn't have irq support for r6xx ?
agd5f: mathbr: apg may work better with modeset=1, however if you enable kms, make sure you have a ddx and mesa with kms support
mathbr: How can I ensure that? Or check it? Mesa is currently at 7.7 here.
spstarr: glisse: can i turn off IRQ with KMS?
mathbr: And I don't really know anything about DDX…
spstarr: glisse: i can test -rc5 if i can... just rename the firmware file?
spstarr: this should fail to enable IRQ?
agd5f: spstarr: that will disable accel
spstarr: no module option to turn off irq?
agd5f: spstarr: nope
spstarr: agd5f: is it easy to implement myself?
spstarr: if I can see the stalls w/o IRQs then we can draw a better picture of what is going on
spstarr: i know I dont see them with UMS which uses no IRQ
agd5f: spstarr: it's probably easier to just revert the a commit before the irq stuff got merged
spstarr: can try sure.. one moment
agd5f: spstarr: try kms with 2.6.31 for example
spstarr: lemme get .31 and compile it, that would be easier
agd5f: er 2.6.32 rather
mathbr: Got 2.6.32 here BTW
spstarr: .32
agd5f: spstarr: 2.6.32, not .31
spstarr: yeah getting .32
spstarr: vanilla .32
spstarr: 2.6.32.6
mathbr: 2,4G /var/log O_o
spstarr: nice he
spstarr: eh
mathbr: Debug after all…
mathbr: 51M /var/log Better…
spstarr: is very curious if .32.x shows stalls with KMS w/o IRQ
spstarr: if it DOES.... then we have not an irq issue but something else.
spstarr: if it doesn't then we'll go from there
spstarr: i think it's interesting knowing how dynticks works now
spstarr: So we look at a quad core desktop machine which probably has no deeper
spstarr: power states and therefor does not use the broadcast timer and compare
spstarr: it to a laptop which has deeper power states and needs to use the
spstarr: broadcast timer, which of course increases the number of IRQ0
spstarr: events. What a surprise.
spstarr: 'broadcast timer'
spstarr: yes, the quad core has no P states
spstarr: my original thought was dynamic ticks was on-demand vs a broadcast timer
spstarr: ew
spstarr: The broadcast mechanism is necessary because the local APIC timer
spstarr: stops in deeper power states. That's a hardware problem .... It is a single timer which is used by all cores in a system to work around this hardware stupidity
spstarr: gross
spstarr: so what im being told is that LAPIC is broken and that laptop motherboard designers still are not making computers with proper timers?
spstarr: hurls a lung at Lenovo
DanaG: hmm, how would I check if I'm affected by a similar issue?
DanaG: Dual-core, though, not quad.
spstarr: DanaG: compile 2.6.32.6
spstarr: run glxgears full window... move mouse over window manager title/buttons, see if you have the gears stall on drawing with KMS and NO irq
spstarr: thats what im going to try right now
spstarr: if you do, then I will adjust bug report.
DanaG: computer I'm on right now has Intel... would have to do the other thing when I get home.
spstarr: kernel built
DanaG: oh, and lucid is 2.6.32.3.
glisse: spreeuw: yeah also update hte bug report once you tested 2.6.32 :)
spreeuw: I'm using 2.6.33 rc5
spreeuw: and it works excellent ;p
soreau: man, I'm really confused now
soreau: any game I try to play is using Video: Using OpenGL: Brian Paul - Mesa X11 : 2.1 Mesa 7.8-devel
soreau: this is very very slow...
Wizzup: has 2.0, how'd you get 2.1?
soreau: the crazy thing is, I have no idea where this is coming from since glxinfo does not report this at all
agd5f: soreau: trying to run a 32bit app on a 64 bit distro?
soreau: Wizzup: Well, even if you use (r300) gallium it will say OpenGL renderer string: Gallium 0.3 on RV350
soreau: OpenGL version string: 2.1 Mesa 7.8-devel
stikonas: isn't 2.1 a version shown by software renderer
soreau: agd5f: No, I'm all 32bit here
soreau: stikonas: Hmm.. that's something to check..
agd5f: soreau: what does ldd show your app is linked to?
soreau: stikonas: well even with LIBGL_ALWAYS_SOFTWARE, it doesn't show Brian Paul - Mesa X11
soreau: agd5f: Let me check
spstarr: agd5f / glisse: it's NOT irq
spstarr: is happening with KMS and no IRQ
spstarr: 2.6.32.6-custom-radeon-noirq
soreau: agd5f: http://pastebin.com/m3881b417
spstarr: updates bug
agd5f: soreau: is it using the proper libGL?
soreau: hmmm... /usr/local..
soreau: agd5f: I do not think so
soreau: I can't really tell what the heck is going on
soreau: I want to know where this Brian Paul - Mesa X11 : 2.1 Mesa 7.8-devel is coming from
soreau: This never happened before..
spreeuw: soreau: what exact variable has that value?
agd5f: soreau: is /usr/local/lib/libGL.so.1 the correct libGL for your system? You can also try LIBGL_DEBUG=verbose app and see if you are getting an error of some sort
spstarr: Stalls with RV635 with KMS - period
spreeuw: OpenGL version string: 2.0 Mesa 7.8-devel
GNU\colossus: is there some sort of idle powersaving coming for HD 4xxx cards?
spreeuw: is git mesa
spstarr: glisse: with IRQs out of the picture, it might be features missing in driver or optimizations?
agd5f: GNU\colossus: there's a driver option for UMS, and some testing patches for kms
glisse: spstarr: unlikely my rv635 behave properly
soreau: spreeuw: It's only when I run a game, but does not show with glxinfo
glisse: spstarr: did you stated your screen resolution in the bug ?
soreau: agd5f: good idea, sec
agd5f: spstarr: I can't reproduce it either
spstarr: glisse: so you do not see the gears stall when mouseovering the titlebar of glxgears?
spstarr: glisse: let me mention that.. 1920 x 1200
glisse: no, not even when moving the mouse like crazy over
agd5f: spstarr: same size screen here
glisse: i will retest with a bigger screen tomorrow, well once i am done with r6xx checker
spstarr: added to bug
spstarr: agd5f: you made glxgears window maximized?
GNU\colossus: agd5f: thanks, nice to know!
agd5f: spstarr: yes
glisse: it might be that the resolution is big enough to hit our driver limit
spstarr: am I able to record this somehow to show the stalls?
agd5f: spstarr: got a digital camera that takes video?
spstarr: yes
spstarr: I do
spstarr: let me do that now
soreau: agd5f: spreeuw: Notice the GL vender/render strings http://pastebin.com/m4ca581b7 I don't see anything indicating failure otherwise
soreau: but I think it is linked wrong..
agd5f: soreau: what if you remove /usr/local/lib/libGL*?
soreau: agd5f: Let's see..
spstarr: recorded
soreau: agd5f: Awesome, that seems to have fixed it!
soreau: wtf happened there...
agd5f: soreau: looks like you had a old mesa installed in /usr/local
agd5f: soreau: mesa installs in /usr/local by default unless you specify a different prefix when you configure it
soreau: agd5f: Well that must have happened recently because it wasn't broken a couple days ago.. first it was only affecting when trying to set LIBGL_DRIVERS_DIR to gallium
soreau: but then all the sudden it started affecting apps that were supposed to be running with classic mesa too
soreau: which is installed is /usr
spstarr: agd5f: ok made video, watch the video in default resolution to notice the gears, i will explain if you have questions
spstarr: it is 23MB
soreau: agd5f: No telling how it happened but thanks
spstarr: maybe covert to ogv
spstarr: convert
agd5f: soreau: did you change LD_LIBRARY_PATH or LD_RUN_PATH?
jroys: agd5f, (rs200 suspend/resume): xset dpms force off ; suspend -> hang. from X, the display first went off, but then came back in a vt with a blinking cursor, then suspended. when resumed, it hung.
soreau: agd5f: I think I might have..
agd5f: jroys: does switching to another vt before suspend help? also how are you suspending? is your distro using vbetool?
agd5f: jroys: does sleep 5; xset dpms force off; suspend help? sometimes you get late input events
soreau: agd5f: I might have changed it inadvertently through a startup strat I have
soreau: s/strat/script
jroys: agd5f, I suspended last time via: echo mem > /sys/power/state. I also use pm-suspend, which basically does the same thing, no vbetool. that's actually what I did last time, with the sleep 5; on front
agd5f: soreau: that's probably the cause of your problems then
agd5f: jroys: weird
jroys: agd5f, yep.
agd5f: jroys: do you need the "radeontool light on" part to resume correctly?
jroys: agd5f, not sure - want me to try?
jroys: agd5f, I'm assuming not
agd5f: jroys: sure
soreau: MostAwesomeDude: So I think the whole time, games weren't even using gallium though glxinfo reported it in the same environment. building latest to test now
jroys: agd5f, the 'radeontool light on' is not needed
soreau: agd5f: So when an app links to (in thsi case) an old libGL, then that libGL gets removed, does it just look for other libGL files in the path order?
agd5f: soreau: yes
spreeuw: still having this weird gamma issue in openarena
soreau: ok, that makes sense then
spreeuw: windowed panes (alt enter) have correct brightness (gamma) but fullscreen is dull and grayish
spreeuw: been like this since a couple of months
agd5f: jroys: can you try the latest radeon drm bits?
spstarr: glisse: http://www.sh0n.net/spstarr/radeon/glxgears-stall.avi
soreau: agd5f: So since I was explicitly setting LIBGL_DRIVERS_DIR to where the dri.so files were.. where does libGL.so come in?
agd5f: soreau: libGL loads the proper hw driver
spstarr: glisse: you will see what i mean by the gears losing FPS when they spin
soreau: agd5f: so it doesn't really matter too much which libGL.so it is as long as it picks r300_dri.so (in this case?)
glisse: spstarr: yup i saw the issue
glisse: hopefully tomorrow i will solve my checker issue and have time to look into that
glisse: zzzZZZzz
spstarr: ok
spstarr: agd5f: i forgot about just using a digital camera to record the video directly :)
spstarr: makes things much easier to explain visually
spstarr: back to -rc5
soreau: oh garbage
soreau: Alright, so now I'm trying to compile mesa with './autogen.sh --prefix=/opt/xorg --with-demos="" --with-dri-drivers="" --enable-gallium-radeon --disable-gallium-intel --with-state-trackers=dri,glx,xorg --disable-egl && make distclean && make clean && make linux-x86-32' but the prefix is getting set to /usr/local..
soreau: Should I do make distclean && make clean before the configure then?
soreau: and, now mesa is installed to /usr/local and there's no uninstall target
soreau: so how do I manually remove it from /usr/local?
soreau: This is pretty frustrating
soreau: half of mesa gets installed to /usr/local while other parts get installed to the prefix I need all of it to be installed to
spstarr: ugh
soreau: gmake is screwing me over
soreau: and I'm trying to not use it
soreau: Can someone help me out here? http://pastebin.com/m61bc017f
soreau: Note the --prefix passed to autgen.sh, then the configure output (says prefix=$PREFIX) but at the bottom, see gmake come out of nowhere and start installing to the default prefix
soreau: grrr
soreau: how do I tell gmake which prefix?
soreau: this is something new in mesa or what?
mathbr: Booting with radeon.modeset=1 did not work at all, neither with CONFIG_AGP=y nor CONFIG_AGP=m, I had to remove that one.
mathbr: The latter even gave me an oops
chithead: you can try with radeon.agpmode=...
mathbr: RV730+Kernel 2.6.32+CONFIG_AGP=y: http://pastebin.com/m5fa96608
Shuren: soreau, have you complete to built mesa? that output seems to be ok, or i don't understand the problem
mathbr: RV730+Kernel 2.6.32+CONFIG_AGP=m: http://pastebin.com/m289edb8b
mathbr: chithead: Is this different from doing this in xorg.conf?
jcristau: mathbr: what if you don't load vesafb?
mathbr: I don't do anything in particular, X does.
jcristau: no, you get vesafb loaded at boot for some reason
soreau: Shuren: Yea, I fixed it now but it's still dumping libGL stuff into /usr/local for some unkown reason
mathbr: jcristau: Does this come with the vesa driver? I can only see vesa_drv.so in there
soreau: So when trying to play some games with gallium, I get a ton of hex output in the console and in dmesg a lot of [drm:r100_cs_track_check] *ERROR* [drm] No buffer for z buffer !
soreau: Is there anything to do about this?
jcristau: mathbr: no, it's unrelated to X
soreau: mathbr: vesafb is a kernel module when CONFIG_FB_VESA is set
soreau: you don't want it to get loaded
chithead: no, vesafb cannot be built as module
Shuren: dunno, i don't play with gallium for now
chithead: uvesafb might
soreau: oh well you don't want it set at all then
mathbr: Currently this and Debian default it seems:
mathbr: CONFIG_FB_BOOT_VESA_SUPPORT=y
mathbr: CONFIG_FB_UVESA=m
mathbr: CONFIG_FB_VESA=y
soreau: make them all =n
mathbr: Another kernel rebuild. :-/ I'll try that tomorrow, thanks for today.
soreau: After you've built it once already, it's much quicker unless you do make clean
mathbr: I purged the src directory before I found out that /var/log is filled up with debug stuff.
soreau: You built a kernel and got rid of the evidence? -dirty ;)
mathbr: Didn't expect /var/log to take that much space and I was wondering why I couldn't even do one single write access anymore…
soreau: MostAwesomeDude: fwiw, I am not liking gmake. It seems to do whatever it wants to do
soreau: MostAwesomeDude: But I got gallium installed again and it's back to normal speeds
airlied: soreau: gmake == make
soreau: airlied: Well it's making me mad because it's installing stuff wherever it wants to
airlied: soreau: but its the same as make
airlied: soreau: exactly the same
soreau: airlied: ok
soreau: Now what about [drm:r100_cs_track_check] *ERROR* [drm] No buffer for z buffer ! ?
airlied: ls -la /usr/bin/gmake
airlied: lrwxrwxrwx. 1 root root 4 2009-10-20 00:15 /usr/bin/gmake -> make
soreau: airlied: Well I guess it's the meas build system being retarded then
soreau: it caused me a lot of grief for nothing
airlied: wonders whats it installing wierd
airlied: is seems to work for packages fine
airlied: glisse: btw I think that gpu lockup statement is wrong
airlied: glisse: genearlly when we've actually tracked down a gpu lockup it has a mostly logical explaination
soreau: airlied: Well I don't know what I did wrong but whatever it is, it's the same thing that's been working for months now :P
airlied: soreau: you configure --prefix=/somewhere and it installs files outside that?
soreau: airlied: That's what I made of it
airlied: glisse: and we should treat them as regressions
airlied: if they happen more than they did before a change definitely
airlied: soreau: what files?
soreau: airlied: Well afaict, libGL.so files.. because I deleted them and they reappeared
soreau: but I'm sure it was a fluke
soreau: because I can't reproduce it
airlied: sounds like you ran autogen.sh or something and forgot the --prefix
soreau: airlied: Do you know what this means or how to fix it? [drm:r100_cs_track_check] *ERROR* [drm] No buffer for z buffer !
eosie: soreau: r300g?
soreau: eosie: Yes
eosie: soreau: do you have a test app?
airlied: soreau: you running drm-radeon-testing?
soreau: airlied: yes
soreau: eosie: Yes, the dolphin emulator for one..
soreau: and mupen64plus with certain video plugins
soreau: a bit heavier on the GL 3D I believe, but I am curious why it's complaining about Z buffer
eosie: soreau: well you may send the command stream it dumps, maybe I will spot something
soreau: eosie: Well I think dolphin gives a different error
soreau: eosie: Ok how do I find the command stream?
eosie: in stderr :)
soreau: you mean the plethora o hex it outputs?
eosie: yes
soreau: hmm ok
soreau: And in dmesg I see a bunch of [drm:r100_cs_track_check] *ERROR* [drm] No buffer for z buffer !
soreau: [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
soreau: eosie: It's uploading to pastebin now
soreau: meh, it's too big
soreau: let me try file upload
agd5f: mathbr: you have radeon compiled in and agp stuff as modules?
soreau: eosie: http://omploader.org/vM2N0YQ
agd5f: mathbr: probably easier to just do modules for everything
eosie: hm, somebody must have changed the textual format of dumped CS :(
soreau: orly?
soreau: eosie: For dolphin, it dumps a ton of hex but in dmesg, it's totally different
soreau: radeon 0000:01:00.0: (PW 1) Vertex array 0 need 100663290 dwords have 81920 dwords
soreau: [drm:r100_cs_track_check] *ERROR* Max indices 16777215
soreau: [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
soreau: eosie: which iirc, you said the app was requesting an unreasonable amount of resources or something
mathbr: agd5f: Right now agp modules are built in, radeon is not.
eosie: soreau: or more likely, we might be getting wrong (random?) data
soreau: mhmm
soreau: eosie: So what does this mean if someone changed the textual format of dumped CS?
agd5f: eosie: sounds like a CS parser bug
mathbr: agd5f: Currently like this:
mathbr: CONFIG_DRM_RADEON=m
mathbr: CONFIG_FB_RADEON=m
mathbr: CONFIG_FB_RADEON_I2C=y
mathbr: CONFIG_FB_RADEON_BACKLIGHT=y
mathbr: # CONFIG_FB_RADEON_DEBUG is not set
mathbr: # CONFIG_DRM_RADEON_KMS is not set
agd5f: eosie: I ran into a similar issue on r1xx: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=cf57fc7aa2ac61d02a29550b99db6a01ccd7917c
eosie: agd5f: interesting
agd5f: eosie: I suspect you command stream is missing whatever packet writes the max indices
soreau: eosie: The test case I am using is m64+ with z64 rsp/gfx plugins
eosie: soreau: a really simple test case would be better
eosie: soreau: please recompile mesa with --enable-debug, lets see if you get any assertion failing
soreau: eosie: Of course
soreau: ok
Vi0L0: hmm... i want to use [testing] with [kde-unstable] but after pacman -Syu it says that kde-libs requires phonon (so it want continue) and after pacman -S phonon it says that phonon conficts with qt, so it ask to remove it... what the?
Vi0L0: oh sry, misstypo...
soreau: eosie: I have compiled with --enable-debug, now what?
soreau: eosie: Does 'unknown opcode: 39' mean anything?
soreau: I'm not seeing any additional output in the usual places (syslog and stderr) with --enable-debug
eosie: soreau: yes, the fragment shader might get undefined results in this case (not sure), it shouldn't cause any other failures
eosie: *might return
soreau: eosie: Well I built with --enable-debug but not seeing any different output
soreau: is there somewhere I should be looking or something else I need to do?
eosie: soreau: no
soreau: eosie: Also, ISTR you said enemy territory works fine there.
eosie: soreau: yes, it does
soreau: eosie: the menu does work fine. but if you start a game, it is immediately apparent the graphic errors
soreau: and, they've gotten better but it looks like a dark rainbow wonderland :)
soreau: eosie: Looks like this http://omploader.org/vM2N0cQ
soreau: with classic, it is perfectly flawless afaict
soreau: It used to be completely slow with gallium, but now it is mostly up to speed but these graphical errors
edt: stellarium does not work well here with git mesa and friends
edt: it gets massive font corruption and its impossible to select from its menus. Have to alt+tab and cntrl+C to stop it...
edt: googleearth works but is a bit choppy
soreau: eosie: Now I get this after it dumps some hex http://pastebin.com/m21423413
soreau: edt: Which card do you have?
edt: hd3300 from 790gx: Mesa DRI R600 (RS780 9614) 20090101 TCL DRI2
edt: on gentoo with ~amd64
edt: soreau looks like stellarium is noise. Checked gentoo bugs and its a problem with qt 4.6
edt: sorry
eosie: soreau: it's nice you have better performance than before, unfortunately here it's the other way around
eosie: soreau: wait... are you testing et or etqw?
soreau: eosie: No, just et
eosie: me too
soreau: I did try etqw when I managed to install it once about 6 months ago and it didn't work at all of course
soreau: since then I haven't had it installed
eosie: now the etqw main menu works! :)
soreau: The menu worked for men when I tried it back then iirc,,
soreau: I got as far as trying to actually start a game then it would just die
eosie: when trying to start a new game, it segfaults so it can be tracked down
soreau: eosie: Now I built with debug.. and I am trying to build without debug again but it's still showing it's built with debug enabled :P
cxo: Is there a chance we can get vdpau support with radeon? if thats possible at all?
soreau: I did make clean, reconfigured, nuked the dri.so files, nothing seems to work
soreau: eosie: I don't know why I'm having so many problems configuring mesa today
cxo: autoreconf -i -v, distclean, configure?
soreau: I'm going to try deleting the entire prefix dir to see if it helps
soreau: could ccache be throwing it off?
soreau: I nuked the prefix, reinstalled and it's still a debug build
eosie: "*ERROR* [drm] No buffer for z buffer !" can be fixed by disabling immediate mode... I don't really get it, it's a completely unrelated feature
soreau: eosie: How do you enable immediate mode anyway?
eosie: it's enabled by default in master
soreau: eosie: btw, with mesa debug, the app crashes with http://pastebin.com/m21423413 when debug is enabled but without debug, it continues to run slowly, dumping hex in the terminal
eosie: be glad it crashes
eosie: it means a fragment shader compilation failed and pretty much anything can go into CS
eosie: we used to get hardlocks this way
soreau: yea, I got a hardlock before with dolphin.. but now it just crashes
Jonimus: woo after a rebuild of the newest packages I no longer have as poor of performance with dynpm enabled
Jonimus: so now I can saver battery life when need be and get performance when I need it :)
soreau: That's another thing I don't mind testing all the latest code. Surprisingly, it does not crash too badly resulting in an annoying hard lock
eosie: I thought I had added abort there
linuxrocks123: airlied: is there any way I can use the X1300 with radeonfb? like an experimental branch somewhere or something?
BioTube: isn't radeonfb deprecated?
linuxrocks123: I don't know. Is it?
linuxrocks123: My problem is I'm trying to use this PC graphics card on a SPARC.
linuxrocks123: and it's not working
BioTube: all I know is that it kills KMS
cxo: radeonfb is deprecated
linuxrocks123: so no one's adding support for new cards?
cxo: well unless you have a really old card like a 128
linuxrocks123: It already works up through 9800 or so.
linuxrocks123: oh you mean they're adding support for old cards right now ... okay
linuxrocks123: I actually have a Rage XL I was trying to get to work in this same machine.
cxo: no. i meant radeonfb is not going to be updated
linuxrocks123: oh, okay
linuxrocks123: lol, darn
cxo: are you running linux on sparc?
linuxrocks123: yeah
cxo: and kms doesnt work?
linuxrocks123: I'm not even sure what KMS is.
cxo: radeon modesetting etc..?
linuxrocks123: X doesn't work.
linuxrocks123: The card won't work at all.
linuxrocks123: X fails with "Cannot map MMIO aperture. No such file or directory (2)"
cxo: did you try build the latest bits from git?
linuxrocks123: no
linuxrocks123: airlied told me to upgrade my kernel and with the updated kernel it just crashes the machine when I try to start X
cxo: linux,drm,mesa,xf86-video-ati
linuxrocks123: I'm on X 7.4 / kernel 2.6.31-gentoo-r7
cxo: i'd say you need >2.6.32
linuxrocks123: Isn't the latest 2.6.32.5?
cxo: 33-rc5
linuxrocks123: oh
linuxrocks123: umm, what do I need that for?
linuxrocks123: I don't care about KMS unless that's necessary to get pictures on the screen.
linuxrocks123: do you know what the error with the MMIO aperture means?
BioTube: I believe KMS support was added for your card in either 2.6.30 or 2.6.31
BioTube: MMIO = memory-ampped I/O
cxo: dont know what it means. But i'd build everything out of git before i start looking for an answer
BioTube: s/ampped/mapped/
linuxrocks123: okay, so it would be failing because of incomplete KMS support?
BioTube: if you're using userland modesetting, KMS code shouldn't impact you
linuxrocks123: I didn't do anything special to enable KMS at least.
BioTube: I'd try the latest xf86-video-ati and the latest stable kernel
cxo: does sun still sell sparc boxes?
linuxrocks123: yeah but this is an old one
linuxrocks123: Sunblade 2500
linuxrocks123: I already tried whatever the latest xf86-video-ati version Gentoo had (and I enabled testing), and I compiled 2.6.32.5 from source.
linuxrocks123: I also tried radeonhd.
linuxrocks123: same thing :(
adamk: oga: DO you know what the most recent radeon supported by radeondrm in OpenBSD is? And if it's changed between 4.6 and 4.7.
BioTube: linuxrocks123: have you tried the vesa driver?
cxo: why dont you just build everything like i said, its going to take less than an hour, nothing to lose
linuxrocks123: VESA doesn't work on SPARC.
BioTube: hmm...
linuxrocks123: It's because there's x86 assembly code embedded on the video card.
linuxrocks123: Theoretically uvesafb would work except that no one's ported v86d to anything other than x86.
linuxrocks123: cxo: I've never built X out of git before, but my previous experiences compiling X by hand suggest it's a major hassle.
cxo: not x
cxo: linux,drm,mesa and xf86-video-ati
linuxrocks123: Well, I already did linux, and I enabled "~sparc" for all of X11.
Luzipher: is there already a fedora package for the new interrupt firmware for R600/R700 ?
linuxrocks123: Nothing changed for the newer X versions, and the new kernel just made it crash instead of error out.
linuxrocks123: and actually it looks like that's a bug or something because X now crashes no matter what's in the config file or what card it's trying to use.
linuxrocks123: unless I use the older kernel
Luzipher: ah yes, seems to be "xorg-x11-drv-ati-firmware"
cxo: you shouldnt have an xorg.conf for the most part
linuxrocks123: I have two video cards in my machine, so yeah I need one.
linuxrocks123: One is a Sun-branded 3D Wilcat thing that doesn't work at all except with the e3d framebuffer.
linuxrocks123: and the e3d framebuffer will work with X, but not really because parts of the screen are missing
linuxrocks123: like, blotches of pixels all around the screen don't render
linuxrocks123: really weird
linuxrocks123: That's why I got the PC graphics card in the first place.
linuxrocks123: Oh the Sun-branded 3D Wildcat thing is "XVR600" btw.
cxo: well join the line then, we're all waiting for help :)
linuxrocks123: lol
linuxrocks123: I've almost given up hope ... I'm probably just going to get a Radeon 9250 or something and just use radeonfb.
cxo: is the sunblade worth it?
linuxrocks123: yeah, these cards are only like $20 each on eBay.
linuxrocks123: and I think I can return the X1300
linuxrocks123: It's got 2 1.2GHz UltraSPARC IIIs in it.
linuxrocks123: and 2GB RAM
linuxrocks123: so it's not that bad
linuxrocks123: I just want to be able to run X on it is all.
cxo: you really personify the stereotypical ati dev's argument - "the few users that..."
cxo: sunblade, sparc, ati card, X? not even if god came down to earth and wrote a driver, is that likely going to be a good combo
linuxrocks123: lol
linuxrocks123: Well what brand card would you suggest I buy.
linuxrocks123: I'm open to suggestiosn.
linuxrocks123: I was thinking ATI was a good bet because the OSS drivers are relatively good, especially with the new documentation.
linuxrocks123: I can't use proprietary anything, of course.
cxo: yeah
cxo: actually, have you tried solaris?
linuxrocks123: I will use Solaris if, after about 10 of these cards or so, I still can't find one that works.
linuxrocks123: but yeah Solaris would work with the XVR600.
linuxrocks123: with a binary driver
linuxrocks123: and I think it has to be Solaris 9 or older.
cxo: what about a new solaris? like that one with the debian glibc userspace?
linuxrocks123: uh, I don't think that one works on SPARC.
linuxrocks123: let me check.
cxo: honestly dude, just go build the bits i said, you have nothing to lose
linuxrocks123: yeah Nexenta doesn't support SPARC :(
linuxrocks123: and Solaris userland sucks
linuxrocks123: so it's going to be after I spend the $30 they're asking on eBay for an ATI Rage XL with Sun ROMs.
linuxrocks123: I'd build the bits if I had any reason to believe it would work.
linuxrocks123: but randomly downgrading probably has about as much chance of working as randomly upgrading
linuxrocks123: it's not that new a card
cxo: its not about upgrading vs downgrading. its about making sure all the items of the graphics stack are in sync with each other. Having the latest driver, but all of userspace out of date wont help
cxo: but thats just how i see it
linuxrocks123: *shrug*, I'm pretty much using Gentoo ~sparc now.
linuxrocks123: I was using Gentoo sparc stable before
cxo: plus the time we killed talking about it, you might have already finished the build :)
linuxrocks123: so I think I'm in sync
linuxrocks123: heh, doubtful
cxo: i build it daily, i know how long it takes :)
linuxrocks123: Things often don't compile as easily on sparc as x86.
linuxrocks123: There's the 32-bit userspace versus 64-bit kernel.
linuxrocks123: and just people don't test that it compiles as much'
linuxrocks123: You have to pass "CROSS_COMPILE=sparc64-linux-unknown-gnu-" to make just to build the kernel.
Luzipher: hnsr: maybe this saves you some time if you try the multilib overlay: I had to disable the fam, acl and ldap use-flags to resolve circular dependencies
Jonimus: wtf why is my mesa build failing
Jonimus: oh wait I know
Digital_Pioneer: Hey, I've got recent git builds of libdrm, ddx, mesa and a RV770. Gradients look pretty nasty, so I think it's not using a decent bittage of color. How can I change this?
Digital_Pioneer: I have no xorg.conf, and I'd rather not make one, but I can if necessary.
Digital_Pioneer: WTH? Hitting Alt-F# takes me to a console from X!
Digital_Pioneer: That's not OK.
Digital_Pioneer: Oh curse it.
Digital_Pioneer: restarts X
Jonimus: hmm I'm getting some corruption on the window decorations of windows containing 3d effects like glxears
Jonimus: normal windows are fine its only the glxgears window as well as other 3d apps
Jonimus: but ut2004 was fine
chant: if I see artifacts on my screen in only certain modes in openarena, is taht more likely mesa or the X driver?
chant: artifacts are constant and at top of screen in one of the widescreen modes.
chant: Brb.
chant: It was mesa :)
chant: ah, no it wasn't.
chant: necessarily.