Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-12-25

Search This Log:

spstarr: i just echo to /sys :)
spstarr: echo "disk" > /sys/power/state as root ;)
spstarr: these days one doesn't need to use any funky tools to restore video for radeons i dont think
Ghworg: What I actually do when I'm not testing something is just close the laptop and let the acpi event take care of it
soreau: # echo "disk" > /sys/power/state\nbash: echo: write error: Function not implemented
soreau: I am looking for something like that command though
soreau: I don't use a DE, just plain ol' standalone X
soreau: pm-suspend seems to have done the trick!
soreau: Thanks Ghworg
soreau: Also, the procedure seems to have gone flawlessly
soreau: rv350 on drm-radeon-next with all latest user space components
mcgreg__: just compiled 2.6.33-rc2 and got everything working, everything was quite stable just very nice and I justr wanted to say this here... until mouse disappeared. it is still there , just I cant see it anymore. just played nexuiz to test
mcgreg__: and after restarting Xorg it is still "invisible" :/
_KAMI_: hi
mcgreg__: hi
mcgreg__: hmm when I start nexuiz I can see the mouse again ... just not the mouse on the desktop
eosie: nexuiz renders its own mouse cursor using the 3D engine
mcgreg__: I've trd change mouse themes and stuff, didnt work, had to reboot the machine
mcgreg__: that the only issue I have found yet
mcgreg__: *tried
mcgreg__: just started nexuiz again and started a game , the mouse pointer is still there
mcgreg__: no problems with warcraft3 as well
mcgreg__: generally with 2.6.33 kms and xorg seems to work very good
mcgreg__: hehe really, all kinds of problems I had are gone. I am very very pleased. I am very pleased about that :)
mcgreg__: oh lol I wrote it 2x ;)
mcgreg__: I really cant thank you enough for that gentlemen :O
mcgreg__: :)
wirry: :D
mjt: are there any plans for power management?
eosie: there are always plans for power management ;)
mjt: heh
mjt: never-ending plans, i see ;)
Ghworg: It's in progress, causes visual glitches currently so needs some more work
mjt: aha. So 2.6.33-rc2 does not boot with KMS for many people...
mjt: it has been mentioned here yesterday
dileX: mjt: here I have troubles w/o kms (nomodeset), seems to be acpi-related
airlied: mostly ppl missing the firmware I'm guessing
dileX: hehe, 3rd ppl reporting troubles w/ 2.6.33-rc2. OK, this guy has acpi/wmi problems with hp-wmi, too
mjt: airlied: does it really need firmware from other place? I mean, the one in kernel is not enough?
mjt: every time i run a 3d app it complains about interrupts
airlied: mjt: http://people.freedesktop.org/~agd5f/radeon_ucode/
jcristau: mjt: yes.
airlied: needs to patch the Kconfig now it has a home
airlied: not that anyone will erad it
mjt: airlied: yeah i'm reading your email to linux-kernel that's why i asked you here :)
mjt: "do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly."
mjt: (but that's 2.6.32 not .33-rc)
mjt: what it will do if it can't load firmware?
mjt: hang/stop?
mcgreg__: for me in case for kernel .32 kms simply wont work in case of .33 it crashed the kernel
mjt: i mean, in case the fw is not in kernel (as it's not in kernel right now), can it load some other "simpler" fw and continue?
airlied: -rc1 hangs, rc2 should do better I think
airlied: i.e. kms with no accel
mjt: that should work ;)
airlied: need to test that again at some point
mcgreg__: in my case I had RV730_cp.bin RV730_pfp.bin installed, just the 3rd part R700_lc.bin was missing and it crashed (.33-rc2)
_KAMI_: hello
JohnDoe_71Rus: merry cristmas
_KAMI_: Merry XMAS!
mjt: Dec 25 14:05:03 gandalf vmunix: [TTM] Erroneous page count. Leaking pages.
mjt: Dec 25 14:05:03 gandalf vmunix: general protection fault: 0000 [#1] SMP
mjt: "ttm" sounds familiar, and somehow i think it's related to radeon...
mjt: ..and it's gone (had to hard-reboot)
mjt: for fun, disk subsystem worked for a few minutes after this OOPS. But stopped.
mjt: yeah, ttm is used by radeon module
glisse: mjt: which kernel ?
mjt: 2.6.32
mjt: .2
mjt: theres' a stack trace follows but somehow i don't think it's interesting.. is it?
glisse: could be
mjt: oh, there are several OOPSes like that
mjt: http://www.corpit.ru/mjt/ttm-leaking-pages-gpf.log
mjt: several "Leaking pages" messages but only one OOPS
glisse: well hopefully it's fixed in 2.6.33
glisse: thought i am surprise that you hit this error
glisse: mjt: doing anythings special ?
mortal_: is there any radeon driver version which works with radeon 8500
glisse: mortal_: all version since few years
mjt: glisse: special as in?
mjt: glisse: at the time it happened i were typing something in this very IRC window (it's in an xterm)
glisse: firefox with hundred of tabs, playing on 2 quake at the same time ...
mjt: not even fancy transparency etc
mjt: firefox were running, with 2 or 3 tabs one with flash playing some music (trivial flash-based music player, not even pictures)
mjt: no quake :)
mjt: basically firefox, thunderbird and irc and a few xterms
mortal_: glisse: the latest bleeding edge does not work :/
glisse: which gpu ?
glisse: mortal_: it should, more than likely a configuration issue on your side
mjt: amd780g built-in
mortal_: glisse: r200 I think, there is some bug, it is already documented
mortal_: http://pastebin.com/m465e3af8
mortal_: it needs work to solve
mortal_: iirc even karmic's packages don't work
mortal_: but I should try
glisse: mortal_: looks like one of this is out of date: libdrm, kernel, mesa
mortal_: glisse: it is bleeding edge git xorg
glisse: if it's libdrm you need to rebuild everythings
mortal_: ubuntu packages
glisse: mortal_: i don't know what ubuntu does
mortal_: all current
glisse: but it looks like their are packaging out of date things
mortal_: glisse: I have
_KAMI_: hello again
anotheruser: hello, is anyone there?
leshka: hello, using the radeon driver starts my GNOME in 3 and a half minutes, but vesa does it in 2 seconds.
adamk_: Heh, I was wondering when/if you'd show up here :-)
gregorian: hi
gregorian: never used irc before, but googling led me here finally :)
gregorian: Thanks for your help. Gnome was setup perfectly. But this X is a real issue
gregorian: Any suggestions?
adamk_: Unfortunately, I really don't have any ideas myself.
adamk_: And, being Christmas day, I'm not sure who is actually on here at the moment that could figure out what's goingon.
gregorian: I guess I'll come back later then. Thank you once again!
adamk_: Well, you can always just idle here and see if anyone pops up with a suggestion or two.
adamk_: Or not.
penguin42: Is there any useful debug I can provide if X has sudddenly got very slow doing normal stuff - it's taking ~45% CPU with just displaying top -
penguin42: oddly the % is rising, it's upto 59% now
amarsh04: I had a very crazy situation that did that penguin42
penguin42: I'm just wondering if there is any useful debug I can gather
amarsh04: using a build of xmms 1.2 that I compiled myself, when I had the app running with "use fontsets" enabled, Xorg CPU usage more than doubled
amarsh04: so have a check of what graphical apps are running... if they do something that has to be done by X rather than hardware or the app, it can affect performance
penguin42: I'm wondering if it's kms related - it seemed OK when I was running yesterday without KMS, and it's mostly OK but I just noticed it eating CPU and flash stopped (a flash game not video or anything clever)
amarsh04: this was on a radeon 9200se in my case, not a radeonhd
penguin42: this is rv710
amarsh04: I haven't run kms yet, only running Debian unstable
amarsh04: I have a machine running radeonhd, but I can't see which modules it loads unless I switch the monitor from this pc to the radeonhd machine
amarsh04: on this machine, kernel modules radeon,ttm, drm,drm_kms_helper and some i2c modules seem to be involved with the graphics card
penguin42: nod
idletask: Merry Christmas #radeon
amarsh04: my dmesg has "radeon defaulting to userspace modesetting"
idletask: If I want to keep up to date on GLSL, what is the right component to follow? Mesa?
amarsh04: forgot that he was in #radeon rather than #radeonhd so he was on topic after all
amarsh04: brb
edgecase: hey does anyone know where i can get ImpacTV2 datasheet? Has it been declassified?
MostAwesomeDude: If Google doesn't turn it up, then you're probably out of luck.
edgecase: ;<
MostAwesomeDude: You could ask bridgman, although he won't be around for another day at least.
edgecase: i suspect Macrovision is to blame
edgecase: k
MostAwesomeDude: Well, no, the reason you'd be out of luck is because that chipset was before the AMD acquisition.
MostAwesomeDude: Docs from before that time are *very* rare.
MostAwesomeDude: We don't have r100/r200 docs either.
MostAwesomeDude: amarsh04: FYI only radeon and drm should be loaded if modeset is disabled, for your radeonhd setup.
MostAwesomeDude: When KMS is active, you'll get the i2c, ttm, etc. modules.
amarsh04: ok, thanks MostAwesomeDude... not sure on the Debian specifics but I'm using a 2.6.32 kernel
amarsh04: maybe Debian have the kernel stuff in place for when the userspace software is ready
MostAwesomeDude: amarsh04: Kind of. Intel KMS shares some of the structures of Radeon KMS, and it was merged a couple revisions ago.
amarsh04: ah, ok, thanks
penguin42: spent almost a week thinking there was some weirdo problem where blacks were less black on this new machine with radon+dvi than my old intel+vga to the same monitor and eventually concluded that for no apparent reason gnome-terminal's black pallete entry was much closer to grey
lordheavy: mesa master from git fail to build http://pastebin.fr/6357
MrCooper: penguin42: I was also fooled by that once :}
lordheavy: problem in r300_render.c
_KAMI_: how can i enable hdmi audio
_KAMI_: with radeonhd driver?
penguin42: I'm fairly sure that's a separate driver, mine is listed in /proc/asound/cards - but I don't have an HDMI sound system
_KAMI_: I can select it in pulseaudio's volume control
_KAMI_: listed in lspci
_KAMI_: and asound too
_KAMI_: but when I select it no
_KAMI_: sound from the hdmi device
_KAMI_: 01:00.1 Audio device: ATI Technologies Inc RV620 Audio device [Radeon HD 34xx Series]
_KAMI_: not muted in alsamixer
_KAMI_: Advanced Linux Sound Architecture Driver Version 1.0.21.
_KAMI_: HDA ATI HDMI at 0xfdeec000 irq 17
chithead: hdmi audio requires either radeonhd or a very recent kernel
adamk_: _KAMI_: That sounds like a question for the alsa people, I would think.
penguin42: this is interesting; this sucks with kms, but is great without it
bridgman: is searching Google to find out what an ImpacTV2 chip is
bridgman: wow, it's from before I joined ATI
edgecase: well it's the TV encoder, when it was an external chip
edgecase: i thought it would shed some light on the builtin tv-enc
mjt: glisse: just got another OOPS with the same message ([TTM] Erroneous page count. Leaking pages.). Now the system were locked hard and nothing left in logs...
bridgman: ahh, I was thinking the opposite, "maybe we can use what we know about the current tv encoder to figure out impactv2" ;)
bridgman: I found a block diagram :
bridgman: http://www.fzd.de/FKTI/MITARB/schmei/Linux/hardware/VGA/impactv2.html
edgecase: bridgman, the TV out on this T30 laptop has weak H-sync in dark scenes, and horiz tearing at the top, so i'm going to hook it up to my waveform monitor (oscilloscope for TV) and see what's up with the sync levels
Zajec: bridgman: can I request new year gift for radeon? ;)
Zajec: bridgman: please, try to make stuff release audio IRQ :)
Zajec: *staff
edgecase: of course knowing what stuff is tweakable would be good, the driver source is pretty spartan
bridgman: edgecase, we're talking archaeology here ;)
edgecase: well i have rv200, maybe later models are similar (and documented) ?
edgecase: in gpu/radeon there's different generations of encoders tho
bridgman: we haven't found a lot of documentation on any of them yet, but I guess the interesting point here is that the design doesn't seem to have changed much from rage all the way to fairly recent chips
edgecase: otoh, what encoders *do* have specs available?
bridgman: which probably explains the lack of docco on recent chips
bridgman: so far none, that's the problem
edgecase: ic
bridgman: "everyone knows how they work", ie the corporate knowledge is embodied in a bazillion lines of source code
bridgman: which nobody touches
edgecase: hmm i should try windows on this hardware and compare
edgecase: yeah, the video formats haven't changed, no need to go there
bridgman: generally if you can find something that does work well we can pick through the source code and see what it's doing
edgecase: right
bridgman: although in theory agd5f is already programming the same way as current drivers
edgecase: ok well it's too early to tell if i'm just doing something wrong, or if there's a real problem
bridgman: i'm not sure exactly where we are with tv-out these days unfortunately
edgecase: i should try with x300 card tv-out as well
bridgman: Zajec, I'll go back through the audio stuff agd5f sent; I don't actually remember seeing audio IRQs there, that's why you got a blank look last time you asked
edgecase: i seem to have a problem with rv200 kms, i have LVDS + S-video outputs enabled, and i tried setting the LVDS property "scaling mode" to Center
edgecase: the panel is 1024x768, and in 800x600 mode, it works, but the unused portions of the panel are not black, but rather the right shows the s-video portion of framebuffer, and below it is flickery garbage
edgecase: i wonder, *shoud* it be black?
bridgman: pretty sure it should be black; there have been a couple of kms issues mentioned that seemed like uninitialized memory but I don't remember any discussions getting closed, response was usually to try the latest code then never heard back
edgecase: ic
edgecase: bridgman, are there any docs available covering crtc registers, for *any* series of radeon?
penguin42: wonders if they all still look like something derived from yee oldee 6845
bridgman: penguin42; pretty much, yes
bridgman: edgecase; I thought the initial register spec docs we released covered crtc, but it's been a couple of years
bridgman: hold on...
edgecase: i have a theory on "extended blanking" heh
bridgman: bah, my pdf reader has decided it doesn't want to render the older docs we published
bridgman: edgecase, can you go to www.x.org/docs/AMD, pull down the M56 doc and check the CRTC registers section ?
bridgman: I'm just seeing blank pages, don't think that's what we published
edgecase: ok
Zajec: bridgman: i am sure airlied claimed he has IRQ working (audio one)
bridgman: ok, worst case I'll ask what he did ;)
Zajec: bridgman: for that we need two things: register that is used to enable audio irq and register to ack audio IRQ
ppman: hey, I want to help out getting r700 3d to work better. What's the best thing I can do to help?
edgecase: bridgman, i'm seeing CRTC register details
jcristau: ppman: find something that doesn't work, and fix it
ppman: hrm, that's a good idea :)
Zajec: bridgman: does releasing two registers need IP review?
Zajec: or is this code airlied wrote that need IP review?
Zajec: bridgman: maybe you can just post that 2 registers without IP review?
Zajec: i could probably use it to write rest
dmz001: Continuation of x1300 problem on Fedora
dmz001: I've been attempting to get the xorg.conf correct to force the DVI port to be used as the primary. I've succeeeded but only if I use a lower resolution than the monitor can actually handle
dmz001: But along the way I encountered this tidbit. I wanted to force the modeline so I turned on noDDC. And even with the VGA port disconnected it treated the VGA port as connected and the DVI port as disconnected. Is there a way to force which port the card will use?
eosie: IIRC some guy here reported that r300g locks up his machine, any idea who was it?
edgecase: does LVDS need proper blanking? i mean if you have disp_h < native size, does crtc put out black pixels automatically, or would it use h blanking to tell it?
edgecase: scaling mode set to None for example
mjt: " /;/l'
dmz001: Continuation of x1300 problem on Fedora
dmz001: I've been attempting to get the xorg.conf correct to force the DVI port to be used as the primary. I've succeeeded but only if I use a lower resolution than the monitor can actually handle
dmz001: But along the way I encountered this tidbit. I wanted to force the modeline so I turned on noDDC. And even with the VGA port disconnected it treated the VGA port as connected and the DVI port as disconnected. Is there a way to force which port the card will use?
bridgman: Zajec; releasing less than three registers does not require IP review
bridgman: of course nobody would think to split the information up into little bits and release it 2 registers at a time thereby getting around IP review
bridgman: OF COURSE releasing just two registers requires review !!
bridgman: ;)
Zajec: ...
bridgman: the issue here is just that I don't remember seeing that info in the audio stuff we have in IP review now
Zajec: bridgman: sorry, i'm poor about irony understanding ;)
bridgman: no problem ;)
Zajec: bridgman: err, so... can you release 2 registers? :)
Zajec: (without IP review)
bridgman: NO !!!
Zajec: ok :);
Zajec: rebooting to KMS
bridgman: to be precise, if the information really does seem trivial then I can release anything without IP review, but not much in the audio area is trivial because there is so much third party stuff there
Zajec: yeah, heard that
Zajec: thanks for explainationg
bridgman: or a better way to put it, I guess, is that it doesn't need as much IP review
bridgman: there's a reason we didn't do audio at first, it's a huge honkin' pain in the *** from an IP point of view
bridgman: so it would have held everything else up
penguin42: chunks of licensed IP?
bridgman: yep
bridgman: the problem is that the bits of programming info don't map cleanly onto "our IP" or "somebody else's IP", they're blended together
penguin42: nod
adwyn: hello and happy christmas everyone. Does anyone know what the "bios bootup message" in the /var/log/Xorg.0.log refer to? Cause the error that is shown there appears once in a while when i power on my computer.
bridgman: not the bios bootup message, the long beep ;)
adwyn: :))
edgecase: interesting D1CRTC_BLANK_DATA_COLOR - RW - 32 bits - DISPDEC:0x6090 Set the color for pixels in blank region
bridgman: my understanding from adwin was that two things happened together :
bridgman: the first was the appearance of a "bios bootup message" in xorg log showing what seemed to be the BIOS version string (which normally didn't appear)
bridgman: the second was a long beep which kept happening until reboot
adwyn: exactly
bridgman: the bios version string is longer than I remember seeing, eg 7192.
bridgman: adwyn's question was whether that meant something; the middle part looks like a standard BIOS version number but not sure about the rest
bridgman: brb
edgecase: what's the difference between blanking and overscan areas?
edgecase: is it horiz vs vert?
ppman: AFAIK, blanking is what should be blank, due to old crt concerns, and overscan area is the extra taken off of the mode's size
edgecase: taken off mode's size?
edgecase: is it black but not in the blanking period?
edgecase: that's the commodore-64 effect of the border around the screen colour heh :)
penguin42: do all of these throwbacks still exist in the DVI, HDMI and displayport world?
bridgman: yeah, IIRC "overscan" is normally set to a color, while "blanking" is actually black (or slightly darker than black, I haven't touched TV for a while)
idletask: Hello
bridgman: the idea was that analog TVs were normally set so that some of the overscan area was cut off but not all of it, since the active area was rectangular and the CRTs were kind of oval-ish
idletask: I have just looked at the subject line, I have rebuilt libdrm/ddx/mesa yesterday from Gentoo's X overlay, git show shows that the last change is more recent than Dec 20th...
idletask: But I have an IRQ problem
bridgman: can't find rlc firmware ?
idletask: Namely, this is the message I see: do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly
idletask: Well, dmesg says firmware is loaded
chithead: either you don't have firmware for the interrupt controller or the drm is too old to support irq
bridgman: can you confirm that the rlc firmware is being loaded ? there are three microcode images - me, pfp and rlc
idletask: Ah, no
bridgman: the first two have been around for a long time, rlc is new and is required for interrupts
idletask: I only have _pfp and _me
bridgman: is there a message saying rlc load is failing, or no rlc-related messages at all ?
bridgman: if no messages, then you need a newer drm
idletask: But the latest drm kernel just fails to boot altogether :(
chithead: irq message is only a warning, 3d will still work
idletask: bridgman: no rlc mention at all
penguin42: idletask: For me with kms until I put the rlc in it hung waiting for the rlc firmware
idletask: penguin42: what kernel do you run?
penguin42: idletask: 2.6.33-rc2
idletask: Hmm
idletask: I run ( fails to boot, meh)
idletask: BTW, the card is an RV790
idletask: Well, I'll try 2.6.33-rc2, I guess
penguin42: mine is RV710
penguin42: I ended up adding the firmware to the kernel built in set since I;m not using initrd, I guess it needs fixing to have it in the tree
chithead: drm in 2.6.32 does not support interrupts
idletask: penguin42: can you elaborate?
idletask: Do you mean the firmware is not bundled with 2.6.33-rc2?
idletask: chithead: well, that explains it
chithead: no new firmware is being added to the kernel, you need to install it separately
penguin42: idletask: I turned on kms by default (it tells you this might be a bad idea!), the rlc firmware isn't in the tree - you have to download it; but you have to get it to the booting kernel; if you are using initrd then I think it can load it from there, if not you have to tweak linux/firmware/Makefile to pull it in
idletask: penguin42: kms is on by default here also
idletask: penguin42: care to pastebin the process you followed to achieve this result?
penguin42: I haven't got it written down anywhere - hmm let me think
idletask: Argh
idletask: User error
penguin42: I haven't got it written down anywhere - hmm let me think; are you running with initrd's ?
idletask: No I'm not
penguin42: ok, so I think you'll need to do the same trick as me
idletask: This is pretty daft... If no new firmware will be submitted to the kernel _and_ you need to modify the kernel to load this firmware if you want KMS, this pretty much requires that you have an initrd - which I don't want, for load time reasons :/
bridgman: yeah, I think initrd will be the normal way going forward; manually building the image into your kernel is a stopgap
penguin42: idletask: http://paste.ubuntu.com/346552/
penguin42: bridgman: Is there a reason that firmware isn't in the kernel when the others are?
idletask: penguin42: thanks a lot!
penguin42: idletask: Having said that see my note - I find kms to be slower and touchy, I've dropped back to having it off
bridgman: penguin42; as I understand it old firmware/microcode is not being kicked out immediately but new stuff is being treated as binary files handled by the loader rather than ersatz source built into the kernel binary
bridgman: the "hex dump source" was always a sore point
penguin42: bridgman: I meant putting things explicitly in the firmware subdirectory rather than hex dump source
bridgman: but it made things simpler so was tolerated for a while
bridgman: I was under the impression that everything new would go in the firmware subdirectory, but not sure if that is actually happening
penguin42: bridgman: I think that's where the existing pair of binaries is, if the rlc goes there as well it should just work
bridgman: still needs to be in initrd though
bridgman: I thought the existing pair of images was being built into the kernel but maybe I'm out of date there
penguin42: bridgman: Ish, the kernel can build the firmware into the firmware binary by itself with one config option
penguin42: bridgman: There's some code that takes stuff in firmware/ and builds the things you configured into the kernel binary
bridgman: yep, but AFAIK everyone is trying to avoid that
idletask: What are the reasons why KMS is slower than no KMS? (and is it the case with Intel, too?)
bridgman: some distros were explicitly moving the images out of kernel into binary files
bridgman: re; KMS speed, I think the main thing is that all the code is new, particularly the memory manager, and doesn't have the years of tweaks that the old code did
penguin42: bridgman: It doesn't actually need the driver writer to do anything other than the same mechanism that you use for initrd, you just CONFIG_FIRMWARE_IN_KERNEL and whereever you use the standard firmware loader it will see to it
bridgman: probably the same for Intel but that code will have a few more months of tweaks
penguin42: bridgman: There's something else going on with KMS - it was eating cpu when idle
bridgman: the idea with KMS though is that some things get slower and other things get faster, at least once the code settles down
bridgman: glxgears will get slower, for example ;)
bridgman: don't think eating CPU was part of the design ;)
idletask: Well, at 4.5k frames/sec with KMS, I won't complain
penguin42: bridgman: I posted to the list; I was seeing 50%+ cpu when idle with KMS - not all the time, but once it started it needed a reboot to stop; and also seeing things like 50%+ cpu on simple flash games
lordheavy: penguin42: did you check if it's iowaits ?
penguin42: lordheavy: I'm trying to remember, but I think it was completely user time
bridgman: also was the system really idle or was something like compiz madly redrawing ?
penguin42: I don't run compiz
edgecase: bridgman, the m56 docs look pretty complete for CRTC stuff, what is a CRC used for in the DAC? some LVDS/TMDS stuff?
soreau: bridgman: heh, that's what you get for blaming compiz ;)
bridgman: just wondering where the CPU time is going -- *something* has to be happening...
bridgman: with a couple of exceptions, the drivers and X server need to be told to do things, they can't just sit around and suck up cpu time on their own
penguin42: bridgman: Yeh I wondered if there was a good way to figure it out, an strace showed it doing a lot of ioctl's on the dri fd
idletask: Another completely unrelated question - what programs can I use to test the compliance/completeness of the provided OpenGL API?
soreau: bridgman: Well FWIW, the compiz devs take care not to do things like 'madly redrawing'
idletask: uses kwin with compositing and it runs fine
bridgman: edgecase; not sure about crc, checking
edgecase: just wasn't sure if it was Cyclic Redundancy Check, or sometihng else, but it looks like it's a CRC signature
edgecase: i don't think it's relevant for what i'm looking at
bridgman: soreau; agreed, but something must be happening or the cpu wouldn't be active ;)
edgecase: here's some good stuff: DACA_WHITE_FINE_CONTROL 12:8 0x10 Full-scale Output Adjustment - DACADJ(4:0)
soreau: bridgman: Well, some compiz effects can be more cpu intensive than others like transparent cube for example but since he's not running compiz this is not likely the case ;)
idletask: I'm frustrated that I need to run the ati proprietary driver to run games with wine :( I wonder where the lack is (Mesa probably)
bridgman: exactly... so the question is what *is* running
soreau: bridgman: So the better question would be something something - top? :)
penguin42: bridgman: It was a good question, I'm not aware of anything like xrestop but to show you on which client the server is working
idletask: About my question about complete OpenGL support testing - is there another way than paying the $$$ to SGI?
edgecase: also good: DACA_ZSCALE_SHIFT 16 0x0 DACA zero scale shift enable. Causes DACA to add a small offset to
edgecase: the levels of all outputs. Drives DACA ZSCALE_SHIFT pin.
edgecase: hey it looks like load detection can generate an interrupt!
bridgman: idletask; for mesa there are a set of test programs that exercise specific functions, but they're not all wired together into any kind of validation suite
idletask: bridgman: can you give the name of such a program? I'd like to see if I have them built
bridgman: mesa/progs/*
bridgman: maybe half are demos designed to do something interesting, the other half are targetted at specific functions
bridgman: you can usually tell by the program name
idletask: Hmm OK, looks like Gentoo's ebuild doesn't build them
bridgman: wherever you put the mesa source code - the progs normally get built at the same time as the driver
idletask: Ah
idletask: Then they're not installed
bridgman: makes sense; I think distros just give you the mesa binary and whatever else is needed to make it work
idletask: Sure, but they could add a USE flag for this
idletask: I want to get rid of fglrx, and that means I need to be able to run Oblivion with the radeon driver
idletask: Right now, I can't :(
bridgman: which gpu ?
idletask: RV790
bridgman: ok, so latest "everything" plus kms enabled should get you the work-in-process code
idletask: Dungeon Siege runs, but with a frame rate three times less than fglrx (apart from the bug that affects it wrt glxDraw*() functions)
bridgman: what happens when you run oblivion now, and have you played with disabling any wine options ?
bridgman: fyi if you want to browse the mesa progs :
bridgman: http://cgit.freedesktop.org/mesa/mesa/tree/progs
edgecase: bridgman, i'm having trouble finding h_disp and v_disp registers
bridgman: if there are registers for everything else it's possible disp = total minus everything else
bridgman: will check
idletask: bridgman: well, it's unusable with KMS. Without, the videos run fine, but the game crashes immediately when a new game is started (some sort of null pointer dereference from what I can understand of the error message - which I haven't noted down). With fglrx, it runs
idletask: bridgman: when you say "everything", does that include the X server?
bridgman: what do you mean by unusable with kms ?
penguin42: idletask: Have you tried iwthout KMS but with the open source driver?
idletask: bridgman: choppy as hell, something like 10 frames a minute
bridgman: just drivers
idletask: penguin42: I have, see above
bridgman: ok, so something is falling back to sw rendering
idletask: bridgman: not even kernel-side drm?
bridgman: any log messages about fallbacks ?
penguin42: bridgman: Which log do those end up in? xsession, xorg or dmesg?
bridgman: just drivers, no need to rebuild x server afaik
idletask: bridgman: honestly, I haven't noted them down... I don't even know where the bug really is to start with: mesa, the ddx, libdrm...
idletask: bridgman: but I can do so if you're interested - that will be messages from wine though
bridgman: penguin42; not sure, seems to vary from one app to the next
bridgman: usually the app has some kind of console and I think the messages appear there, not sure
bridgman: the messages should give an idea of why things are slow
bridgman: idletask, I don't understand your question about kernel-side drm
penguin42: bridgman: I just ask because there's one bit in google-earth which goes very very slow for a while,and I'm guessing it's dropping back, but I can't see anything in any log
idletask: bridgman: more generally though there's an "interesting" bug: you can emulate a desktop with wine - if you do so, the program will not even load with the radeon ddx (whether with KMS or not)
idletask: It will with fglrx
penguin42: wine is a whole pot of pain
idletask: I'll probably write a full report on the wine users mailing list about these problems
penguin42: You have to be very picky about versions of frglx with wine as well, there was a bug a while ago in a frglx version that went really very very wrong in wine
idletask: penguin42: gentoo has the 9.11 version, and I use wine 1.1.32 (later versions just won't find the 3D support at all with radeon - doh)
idletask: That would be a good case for a bisect since I have the wine git tree
penguin42: plays with google earth - someone seems to like doing 3D building modelling around here
edgecase: D1GRPH_PITCH - RW - 32 bits - DISPDEC:0x6120
edgecase: Field Name Bits Default Description
edgecase: D1GRPH_PITCH 13:0 0x0 Primary graphic surface pitch in pixels.
edgecase: bridgman, i think that's it there
edgecase: pg 206
bridgman: edgecase, I think that's actually the number of pixels from the start of one scan line to the start of the next scan line
bridgman: doesn't have to be the same as the number of pixels displayed across a scan line
edgecase: no i saw h_total elsewhere
bridgman: there could be some skipped IIRC
edgecase: oh you mean offset and start for x/y
edgecase: for panning, right?
bridgman: something like that - agd5f knows the details better than I do
bridgman: I tried to get into the office systems to check but my phone line is being really unreliable; storm coming and the winds are blowing hard, so the phone line flaps around and drops the connection every so often
edgecase: no worries
bridgman: need to go chop some more firewood, bbl
bridgman: Merry Christmas everyone...
penguin42: Thanks bridgman
eliasp: hi
eliasp: i have trouble with xf86-video-ati and s2ram, so i'd like to follow the advise from /topic first, recompiling all these components but i'm note sure what 'ddx' is... i'm on gentoo and cant find anything related to it...
eliasp: i'm using a r500 (x1600 [M56]) and suspending makes my box being stuck completely... even SysRq doesn't work ....
wirry: hmm, mine comes to life after resume, when i press the power-off-button
eliasp: is ddx just a builtin component of X.org?
BioTube: eliasp: ddx refers to the X driver(xf86-video-ati in this case)
eliasp: wirry: mine doesn't even shut off correctly... the screen goes black, backlight stays on...
eliasp: BioTube: ah, ok.. fine..
wirry: well...it doesnt shut off then...the display turns on
eliasp: how could i trigger s2ram from CLI? i'm currently just testing it by using KDE's "suspend button"
wirry: but it was strange anyway...kms needed 30s to initialise
eliasp: if it was just that... i could live with it...
wirry: but i killed it now and installed windows over the holidays...want to play cod \o/
eliasp: but the current situation makes my notebook more or less unusable.. ;-(
eliasp: wirry: go to hell! ;-)
wirry: hey
eliasp: hi Poly-C
wirry: i still have two pcs with gentoo on it
eliasp: wirry: pheew, ok ;-)
wirry: both with kms working ;)
wirry: one intel and on amd
eliasp: hmm, i envy you... my Intel based one (Samsung NC10) lacks a working battery, my AMD based ony lacks a working s2ram ;-)
wirry: hmm..i dont use any kind of suspend for my desktop - its only for gaming or trying out radeon (the driver)
eliasp: wirry: i don't have a desktop system anymore since ~5 years but just planning to build one again... a pity there are no intel based PCI-E cards... but AMD is fine too...
wirry: and the laptop i installed windows on is 2 years old...it never really worked with linux, i would have sold it, but i would get to less money for it so i keep it
eliasp: wirry: i need laptops for doing my work... so i have the netbook + a more powerful 17" HP nx9420
wirry: im still a gamer, thats the only reason i would install windows
eliasp: ok, i haven't played any games since unreal tournament 1 ;-)
eliasp: that's now ~10 years ago ...
wirry: i dont like netbooks at all...they are all widescreen and there is no netbook with a trackpoint (i now, there's a sony but its way tooooo much)
eliasp: yes, Sony is really expensive (as long as you want a good one from Sony)
wirry: so i bought a lenovo x61t (the tablet was cheaper then the normal version...dunno why)
eliasp: i like the netbook as a portable device when i'm out without all my other stuff i usually need for work
eliasp: ah, great.. was thinking about getting a tabled based device too...
wirry: yeah, netbooks are small and portable...but with glossy screens? and only 600px in the high...that sucks
eliasp: well, probably next year
wirry: if there is a 5:4 netbook with a trackpoint and a outdoor-usable screen in it - i would wait no second to buy it
eliasp: doesn't the Lenovo Ideapad have a trackpoint? all other Lenovo devices i know of do have one...
eliasp: ok, probably it isn't 5:4 ;-)
wirry: my thinkpad runs 5h on battery AND has much more power then a netbook
wirry: no it isnt...
wirry: the lenovo would be really nice as vodafone sells them in germany
wirry: ohh
wirry: they sell the nc10 too - nice :)
eliasp: TBH, i don't like ISP/MSP provided hardware, as it tends to be more expensive in the end than just going to the next store and buying it ;-)
eliasp: just discovered there's mesa-7.7 on Gentoo... just keywording all needed dependencies...
eliasp: oh, it even needs a newer xorg-server... let's see how far this works fine ;-)
wirry: mhmm could be right...but as im "working" for vodafone its much cheaper for me ;)
eliasp: ah, ok....
wirry: ahh, apprentice is the word i was looking for
eliasp: Leo is your friend ;)
wirry: dammit, my "o" locks
wirry: yeah, but the site took too long
evil_core: [drm:r100_cs_track_texture_check] *ERROR* Texture of unit 0 needs 16512 bytes but is 16384
evil_core: [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
evil_core: s3tc bug?
evil_core: tc-elite crashesh with that error
spreeuw: tc elite works without too
evil_core: yeah, but I got some s3tc fixes for older drm-next, now using drm-radeon-testing
evil_core: will try again ,but those patches was not applyuing probably
evil_core: ../../../../src/gallium/auxiliary/draw/draw_context.h:154: note: expected ‘const void *’ but argument is of type ‘long unsigned int’
evil_core: r300_render.c:388: error: too few arguments to function ‘draw_set_mapped_constant_buffer’
evil_core: Zhack Rusing probably broke Mesa :/
evil_core: but I am not sure, anybody can confirm that gallium builds for him?
evil_core: spreeuw: but slower? or it uses only more memory?
evil_core: wirry: why 5:4, isnt 4:3 better?
wirry: hmm...
wirry: you could be right
wirry: as long as its not 16:9/10
evil_core: eliasp: definitely now. Ideapads are shit w/o trackpoint, drains, rollcage and are made by diffrenet peoples (even BIOS is different, without VT and some other things). The only ideapad that got trackpoint is Thinkpad SL(its ideapad with thinkpad-"like" casing, without drain, rollcage, and with glossy screen/caseing(it looks like HP Pavilion more)
evil_core: I love old games, the only consoles I got are SNES and NES
evil_core: and even dont like old-new CRT with progressive scanline because of lightguns ;)
evil_core: so 4:3 is must have for me
soreau: just discovered a new video plugin for N64 emulator that fails with classic mesa but works with gallium
evil_core: I got T60p with UXGA 15" IPS/FlexView. Damny nice screen, but its definitely too big for me. Previously was using also 1%", but CRT which had not so big real display surface) and keyboard was definitely more far from display. I got now eyestraining ;)
evil_core: soreau: dont make us angry, gallium doesnt build for now :/
soreau: For who?
evil_core: for me
soreau: Well you
soreau: Oops
soreau: You've broken your system in one way or another every day for the past two weeks so I'm not too surprised it's not working for you ;)
evil_core: soreau: so try building r300 gallium from master
evil_core: now, it was building yesterday
soreau: Can you show the configure sequence you're using and the build error?
wirry: I <3 my x61
evil_core: http://pld.pastebin.com/f4cbffb76
soreau: Alright, lemme try to build latest here
evil_core: PREFIX=/opt/xorg
evil_core: env CFLAGS=-m64 CXXFLAGS=-m64 ./autogen.sh --enable-64-bit --prefix=$PREFIX --libdir=$PREFIX/lib64 --with-dri-drivers=r300,swrast --enable-pic --enable-glx-tls --enable-gallium-radeon --disable-gallium-intel --with-state-trackers=dri,glx
evil_core: make
sgvadds: Does anybody know if doom III should work at normal fps or there are some known problems. I just want to know if I can get some more fps some way or it is impossible with the current state of the drivers. I have something about 20-30fps average with almost all settings to Ultra on HD4670 and I know that it could be better (and it is under some other OS)
evil_core: sgvadds: maybe on closed source driver it should work
sgvadds: maybe but I have too new X
evil_core: then be happy that it works at all ;)
sgvadds: and I really want it with open-source driver ^-)
sgvadds: It works and I'm happy
evil_core: I got 20-30fps i nquake on mine r500
evil_core: quake3*
sgvadds: I can't wait till I can get the full power of GPU under Linux :-) Anyway the developers made the great work
evil_core: sgvadds: forget abut it with free drivers
sgvadds: I just want to know if there are some known limitations or I can tweak my system some way
evil_core: sgvadds: you will get less fps when more features will be iplemented :)
moobie: Hello
evil_core: sgvadds: you can try enabling shaders
evil_core: GLSL*
moobie: and merry Christmas
evil_core: moobie: hi
moobie: Anybody know if the tormod repositories uses the pm patch?
sgvadds: evil_core, I think it's not right. It should be much faster. And about GLSL - as I can see they are enabled already by default?
evil_core: sgvadds: if you are so happy because of "ultra" settings and dont see difference in picture "quality", then you can run freedoom and be happy because of 10K FPS and quality set to max ;)
eliasp: ok, now i'm on kernel-2.6.32 (KMS enabled), x11-base/xorg-server-, mesa-7.7, libdrm (git), xf86-video-ati (git) but s2ram still makes my laptop being stuck ... even SysRq doesn't work... hardware is R500/x1600 [M56] ... any idea how to get more information to debug this?
evil_core: sgvadds: remember some old phoronix wine benchmarks which showed that 3d games works better under wine than windows? and that in wine they are quicker than native
evil_core: sgvadds: its not impressing that function stubs are quciker than function that does something
evil_core: sgvadds: if you are buying laptop, then got Intel - some performance with much more expensive radeon using less battery. They got way better free drivers, because theres no alternative
evil_core: sgvadds: anyway you got in topic radeonBuildHowTo, explaining how to enable shaders on r600
evil_core: soreau: and?
sgvadds: evil_core, I'm not a gamer (at least now) and I look at the all the modern games from the point of 3d programmer :-) So I can see the difference (if it is possible). All I want is to know if I could get some more from my card. I don't want to think that mesa driver are so slow and to understand a year later that something was wrong with my system which caused that slowness - that's why I asked. Sorry if my english is not very good
soreau: evil_core: It failed, but I am updating libdrm to make sure
soreau: and... it just failed
soreau: evil_core: So yea, latest mesa build is broken
evil_core: I got updated all
soreau: I guess I could run a quick bisect and see who broke it :)
evil_core: I guess that Zack, because git log show that only him made changes yesterday
evil_core: "yesterday" - dpends where you live
kdeman: The R600 driver just needs to be OpenGL 2.1 compliant... it is getting there.
soreau: evil_core: Yea I think so too but bisect will tell for sure
soreau: and I think the git log is on a fixed time somewhere
evil_core: kdeman: I hate r600 owners, because mine r500 is not OpenGL 1.5 compliant probably then :/
soreau: evil_core: Too late, he's gone
moobie: Anyone tried tormod's ppa?
sgvadds: evil_core, you wrote about radeonBuildHowTo - do you mean that I simply need the latest code or there are something special for r600 that I can't find? If first - my last update from git was 3-4 hours ago
soreau: sgvadds: Which kernel are you running and are you using kms or not?
sgvadds: 2.6.33-rc2 with drm-radeon-testing. with kms.
soreau: evil_core: Ah guess what?.. the build from the 19th fails in the same way which means, libdrm is the one that probably broke it
soreau: So mesa just needs to catch up now
soreau: sgvadds: Try booting with nomadeset. This will disable kms and give a speed boost
soreau: nomodeset might be more appropriate though ;)
brro: would it ever make sense for the radeon.ko driver to not even question (via dmesg) about a request for the firmware? When I insert the module I do see the bus id of 7:0:0 and another of 8:0:0 show up, so that's a good sign, but not much more. it's an HD 3450 which is the rv620 series with four dvi outputs
soreau: MostAwesomeDude: Can someone fix mesa to track latest changes? It fails to build against latest libdrm it would seem
evil_core: soreau: so what should I do. Use stable libdrm?
sgvadds: soreau, but I thought that some of new features should work with kms only? Is it wrong? Anyway I'll try now to turn off KMS.
penguin42: oops, it didn't like that - *ERROR* ib_get failed
brro: I didn't try modeset=0 yet so I'll do that. It's going to take me a lot longer to get the more recent git versions onto this particular machine.
evil_core: sgvadds: bot in r600 case
dmz001: Continuation of x1300 problem on Fedora
evil_core: sgvadds: not*, and you need to change code to get GLSL in r600, use google : r600 glsl
dmz001: I've been attempting to get the xorg.conf correct to force the DVI port to be used as the primary. I've succeeeded but only if I use a lower resolution than the monitor can actually handle
dmz001: But along the way I encountered this tidbit. I wanted to force the modeline so I turned on noDDC. And even with the VGA port disconnected it treated the VGA port as connected and the DVI port as disconnected. Is there a way to force which port the card will use?
soreau: evil_core: You can do whatever you want
evil_core: soreau: I want to build new Gallium, but dunno what
soreau: sgvadds: Yes kms has the potential to provide new features but it is currently slower than dri1(non-kms)
soreau: evil_core: Well i am going to attempt a libdrm bisect and see if I am right
evil_core: soreau: so I am waiting. but if I remember good, after last libdrm update I was able to build Mesa
BioTube: the radeon API was changed sunday
evil_core: hmm..its much more slower with UMS
evil_core: + KMS than with UMS w/o KMS?
sgvadds: soreau, thanks. I'll try. evil_core, does the string "OpenGL shading language version string: 1.10" in glxinfo output mean that GLSL is enabled? I thought it is.
soreau: evil_core: hmm.. looks like last commit to libdrm was the 21st..
soreau: I wonder what broke it
soreau: Oh BioTube said it was changed sunday
soreau: That makes sense, so my assumption was correct :)
soreau: sgvadds: In this unstable state, some might report a version but still lacking features it should have. Not sure about that shading string but I wouldn't rely on it hard and fast
evil_core: so what can I do now?
soreau: evil_core: Downgrade libdrm
soreau: I will figure out which commit you need, hang on
evil_core: to which?
evil_core: ok
evil_core: BioTube: so there will be big change in r300 driver?
evil_core: soon*
BioTube: evil_core: i don't know
dmz001: I am having problems setting the correct mode for a monitor on a DVI port. I've been attempting to force the driver to assign a modeline.
soreau: Still at it dmz001?
dmz001: soreau: Yup.
dmz001: But I've switched to trying to force the modeline. But the selection of the VGA port over the DVI is having me puzzled.
soreau: dmz001: Well if the modeline makes your monitor go black, idk why you'd want to set it
soreau: I think the last suggestion to you was to update your driver component
soreau: +s
soreau: Did you do that?
dmz001: No.
dmz001: I'm taking the opportunity to play with xorg.conf.
airlied: dmz001: http://wiki.debian.org/XStrikeForce/HowToRandR12
airlied: mainly section III
dmz001: I'm certain that the monitor can handle the settings. So I wanted to experiment with forcing the modeline.
soreau: evil_core: Well I'm pretty sure you want drm f1660c249198b5cc14ebbb75107da7bcb6972033
soreau: But even after installing that version mesa still fails to build for me
soreau: I probably did it wrong
dmz001: I wanted to isolate the interaction between what the monitor reports and what is being used. So I tried noDDC
dmz001: Well, it really confused the poor beast. Even when I thought I told it to use the DVI port, it selected the VGA port.
penguin42: the mailing list size limit is too small for a pair of Xorg.0.logs
dmz001: Can I disable the VGA port or makeit use the DVI port?
airlied: dmz001: did you read that link
evil_core: soreau: thanx, but how to get it? (all I know is git pull)
airlied: it answers all your questions
penguin42: airlied: Are you the moderator for the mail list?
dmz001: Yes. But I suspect that it is too late in the game. I want to force it to use my modeline before it even starts.
airlied: penguin42: I think I can be
dmz001: Where is the "off" setting in xorg.conf
airlied: dmz001: you didn't bother reading it
soreau: evil_core: Did you read the link in the topic?
penguin42: airlied: Its just a post of mine is apparently marked as for moderation because it's too large - a pair of xorg logs
airlied: dmz001: you probably want to forget everything you have learned and start by reading that page
dmz001: Thanks folks.... Reading it is.
Zajec: airlied: bridgman seems to don't know about you discovering audio IRQ :)
Zajec: airlied: and I'm afraid he didn't report this to IP guys
soreau: airlied: I installed the libdrm commit to /usr before you broke the api but latest mesa still fails to compile. What am I doing wrong?
soreau: hmm
soreau: Wonder where draw_set_mapped_constant_buffer is
soreau: defined
ppman: /root/radeon/drm/linux-core/drm_agpsupport.c:520: error: implicit declaration of function 'phys_to_gart'
airlied: Zajec: I didn't discover anything
airlied: it prints it out when you run audio
airlied: the unknown irq is quite obviouisly the audio one
airlied: MostAwesomeDude: whats the issue with exposing GS? if apps use it on old hw it'll be slow
airlied: but the thing is ppl running those apps on old hw won't ever get useful behaviour
airlied: so not exposing it doesn't help them
Zajec: airlied: err, i didn't see it!
Zajec: airlied: started audio and nothing appeared
airlied: wierd I get an irq printed when I just boot with audio patches
Zajec: airlied: if then it's not any secret, what is that line for you?
airlied: can't see it now
Zajec: do you have it noted?
Zajec: ok
Zajec: airlied: but still we don't know how to ack it, do we?
airlied: probably not
Zajec: airlied: is that possible only some chipsets need enabling this audio IRQ bit?
Zajec: (like my, and that's why I don't see anything when starting playing)
airlied: no idea I just saw it in my logs
Zajec: ok
ppman: where is the recommended source of drm?
airlied: ppman: in the kernel
ppman: not git somewhere?
airlied: in the kernel git
airlied: see the topic
ppman: okay
soreau: Where is draw_set_mapped_constant_buffer defined?
airlied: in gallium draw module
soreau: mesa is failing to build with: r300_render.c:340: warning: passing argument 2 of 'draw_set_mapped_constant_buffer' makes integer from pointer without a cast \n r300_render.c:340: warning: passing argument 3 of 'draw_set_mapped_constant_buffer' makes pointer from integer without a cast
soreau: same thing for functions r300_swtcl_draw_arrays and r300_swtcl_draw_range_elements in r300_render.c
sgvadds: soreau, thank you one more time, turning kms off really adds the performance for doom3 ( however same workarounds were needed). It was almost playable - fps was not lower than 20 vs 10 with kms on. But it crashed after few minutes (3-5). And with kms i haven't seen crashes at all during hours of testing. :-) Seems like I need to be more patient and just wait a bit
soreau: I'm trying to figure out what's broken.. at first i thought it was libdrm but downgrading it to f1660c249198b5cc14ebbb75107da7bcb6972033 and installing to /usr doesn't allow mesa to build
airlied: soreau: trivial fix
soreau: airlied: but where is the problem, ie. what broke it?
soreau: That's what i really want to know
airlied: fixed now
airlied: the GS commit changed a gallium API
airlied: it didn't fixup r300g
soreau: huh
soreau: airlied: I downgraded mesa to a commit from the 19th and seemed to still fail
soreau: oh well, will update and test now
eliasp: is s2ram on r500+KMS+kernel-2.6.32 supposed to work using current xf86-video-ati from git?
soreau: What is GS?
moobie: Hello
moobie: If my Xorg doesn't find the drm radeon module
moobie: Does that mean it isn't installed? :
moobie: (EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM
moobie: (EE) RADEON(0): Acceleration initialization failed
moobie: It happended when I enabled kms
_KAMI_: hello!
soreau: moobie: You need to rebuild mesa and ddx against libdrm that is compiled with --enable-radeon-experimental-api
soreau: evil_core: mesa is fixed now
moobie: soreau, well just used the tormod repo
moobie: Is there something I should take care?
moobie: about
soreau: moobie: I doubt that works on all distros
soreau: Not everyone uses ubuntu
soreau: Oh sorry, thought you meant something else
soreau: too many channels :)
moobie: soreau, But I use Ubuntu :)
moobie: Used to use archlinux, until fglrx didn't work anymore
soreau: moobie: Are you sure you updated everything offered by that repo?
moobie: Yes
soreau: Well go tell tormod his repo is broken or build libdrm, mesa and ddx yourself
moobie: Was much easier in Arch :)
moobie: Yeah, I'm used to do it like that. But liked to do it in a cleaner way this time
soreau: moobie: Also, make sure you are using the relevant kernel?
moobie: soreau, I'm just using the mainline 2.6.32 kernel for ubuntu
soreau: Doesn't tormod provide a kernel too?
moobie: I might need drm branch of the kernel?
moobie: yes but its only 2.6.32 as far as I know
moobie: 2.6.31*
edgecase: airlied, do you know expected behaviour of scaling mode: None on LVDS? Should the overscan be black? ie mode smaller than native panel resolution
soreau: moobie: I would use the kernel the repo provides
soreau: moobie: You might need to boot with radeon.modeset=1 too
mjt: and don't forget to load fbcon... ;)
soreau: Well afaict, he needs ddx built with kms
moobie: soreau, did that
soreau: did what?
moobie: radeon.modset=1
moobie: Thats where the problems happended
moobie: drm worked fine without kms
moobie: mjt, fbcon?
moobie: soreau, tomrod doesn't provide a kernel as far as I can see
mjt: speaking of all this.. when radeon module is loaded, my console switches to graphics mode with veru small font, clearing everything which was on the screen before. Later on boot, a larger font is loaded, again clearing everything on the screen. Is there a way to do both at one go and not clear the screen?
soreau: moobie: Does lsmod|grep fbcon show anything?
mjt: moobie: drm worked fine w/o kms because it was "old" drm
moobie: soreau, no it doesn't show anything
eliasp: hmm, s2ram doesn't work without KMS too... ok, it actually suspends, but doesn't wakeup correctly... ;-/
mjt: maybe fbcon's built-in?
mjt: eliasp: withOUT ?
eliasp: mjt: yes, radeon.modeset=0 ... and no s2ram ;-(
mjt: ahh
soreau: mjt: I want to think ubuntu builds everything they can as modules
soreau: but not sure
mjt: debian kernel includes alot of stuff into main kernel binary
moobie: What does fbcon do?
mjt: like ipv6 and most sata and a few filesystem drivers
moobie: Should I try rebuild radeon?
mjt: but debian's not ubuntu
mjt: moobie: what do you want to achieve?
edgecase: moobie, tried ubuntu xorg-edgers ppa ?
soreau: moobie: What do you mean 're'build? I thought you said you were using tormods repo?
moobie: mjt, radeon with kms and glsl experimental
moobie: I got ubuntu + r700
moobie: edgecase, Thats what I have installed right now
moobie: soreau, yeah but you said I should try rebuild radeon :P Nevermind then
edgecase: moobie, what's the issue?
soreau: moobie: What is the output of modinfo fbcon ?
mjt: and is the right kernel loaded? :)
moobie: mjt, yes ;)
mjt: poor moobie ... so many questions... ;)
moobie: edgecase, It won't load drm with kms enabled
edgecase: pastebin your xorg.log?
moobie: soreau, modinfo fbcon
moobie: filename: /lib/modules/2.6.32-02063202-generic/kernel/drivers/video/console/fbcon.ko
moobie: license: GPL
moobie: srcversion: 65B645FD36D989F537E4715
moobie: depends: font,bitblit,tileblit
moobie: vermagic: 2.6.32-02063202-generic SMP mod_unload modversions
soreau: Well if modinfo shows fbcon is indeed a module, he prolly just needs to load it before radeon gets loaded
soreau: And it is a module
mjt: yeah
soreau: moobie: So you should have fbcon load before radeon kernel module
moobie: Would that solve the drm thin?
mjt: but note that without fbcon, there will be nothing on console!
mjt: moobie: no
mjt: so i wonder if he has radeon loaded...
soreau: heh
soreau: moobie: We can ask you a lot less questions if you do as edgecase said and pastebin X log
moobie: Dudes I might sound as a newbie, but actually I have installed the git version of thiese many times :) I just haven't tried it with kms yet
moobie: I will
moobie: http://pastebin.com/ma4435b8
moobie: ohh btw. It doesn't recognize the radeon.modset option in the kernel commandline
soreau: The kernel doesn't but the radeon module should
moobie: But the initrt might know it?
moobie: initrd
moobie: soreau, ok
soreau: All's I can say is make absolutely sure you have latest mesa and ddx installed from tormods repo and it should work
soreau: [KMS] drm report modesetting isn't supported.
soreau: You need libdrm, mesa and ddx from tormods repo
moobie: soreau, hmm I think it sounds as a drm kernel problem
soreau: doesn't look like you do
soreau: moobie: Did you build this kernel?
moobie: soreau, no
moobie: from ubuntu mainline kernel
moobie: ubuntu's ppa
lordheavy: nice now mesa master is building fine, thanks airlied !
edgecase: moobie, karmic kernel didn't work for me, i'm using lucid
moobie: edgecase, Should I try the 2.6.33-rc2 or just 2.6.32
edgecase: what hardware?
edgecase: i mean what gpu
soreau: moobie: I think first you should try loading fbcon before radeon kernel module
soreau: it just might fix it
moobie: edgecase, r700
moobie: soreau, okay
edgecase: i'm using rv200 and .32, but try .33 why not
moobie: Do I get irq support with the 2.6.32 kernel?
moobie: soreau, could I just add the fbcon module in /etc/initramfs-tools/modules ?
soreau: moobie: On ubuntu, I have no idea tbh. if I were you, I'd get to a tty, stop gdm, unload radeon and drm, then modprobe fbcon and start gdm again
moobie: soreau, ok
moobie: but again. What is fbcon good for?
moobie: I mean it doesn't solve my drm problem
soreau: It's FRAMEBUFFER_CONSOLE in the kernel
moobie: and I can see consoles just fine
soreau: Theoretically, you should have no tty without it loaded
edgecase: moobie, everyone uses fbcon with kms,
edgecase: if you don't, how can anyone support what your are doing?
soreau: on kms kernel
moobie: My problem is, as edgecase stated, that my kms is not active in my curren t kernel
moobie: I will try a lucid kernel at first
edgecase: get newest you can
moobie: edgecase, where did you get your kernel?
edgecase: lucid
soreau: moobie: The other problem is you're using all binary packages for kernel, libdrm, mesa and ddx so you don't evn know how they were built or configured
edgecase: soreau, i just installed them, and kms and drm2 works for me, so he has at least a chance
moobie: soreau, exactly :)
soreau: edgecase: Well of course there's a chance, it works for a lot of people. I'm just saying..
soreau: I'd rather just build everything myself and know for sure exactly where I'm getting what and how I'm building it
moobie: soreau, I just don't want to make my system unclean
moobie: I.E. installing with make install
soreau: Bah
moobie: :P
moobie: soreau, with archlinux i even made my own packages before installing them
soreau: I guess I should migrate from gentoo to LFS instead then
soreau: package managers are a waste of time ;)
brro: which distribution does airlied or some of the other developers prefer to use?
edgecase: fc12
soreau: brro: Fedora
moobie: edgecase, where do you specify the load of fbcon?
jcristau: brro: airlied works for redhat, which kinda answers the question :)
brro: yes ;) so fedora core 12 then I see
edgecase: moobie, i didn't have to do anything, it just worked for me
soreau: edgecase: Do you know if fbcon is built-in?
soreau: edgecase: ie, does modinfo fbcon find the module?
edgecase: it's a module with 2.6.32-8-generic
soreau: and is it loaded there for you?
edgecase: yes
edgecase: i think it's after initrd is finished
edgecase: you could stop gdm and try loading it like posted above
mjt: hey, maybe moobie does not have radeon card after all? :)
soreau: mjt: Nah, x log said it's hd4xxx
edgecase: could be a knockoff like Rageon
mjt: oh ma.. ;)
soreau: heh
edgecase: you know, fake sounds-alike, like ButterThumb or malk...
mjt: here w/o fbcon (i don't use any auto-module-loaders like udev) i have no console after loading radeon with kms.
moobie: mjt, dude. Plz
mjt: be it 2.6.31 or .32
mjt: ok, i'm shutting up
moobie: mjt, Do I really sound that stupid ;)
mjt: i don't think that's stupid
moobie: don't answer that
moobie: :P
edgecase: moobie, well just modprobe fbcon already!
moobie: I think I will try getting drm to work first
moobie: I am downloading a lucid kernel right now
mjt: yesterday i tried to use alternative directories for drm/mesa/ddx stuff. But i wasn't able to fight against ldconfig which insisted on using libGL.so.1 from /usr/lib not from /opt/xorg/lib/. That's supposed to be something trivial, but I gave up.
edgecase: moobie, nobody does kms without fbcon, so you'd be developing that yourself
sgvadds: edgecase, I saw your questions about overscan etc - do you have some issues with console area less than display area and the outer area being white? if so then I have the same and probably could help you. At least with testing
mjt: (since you mention stupidity..)
moobie: edgecase, in your case it just worked with a lucid kernel ;)
moobie: Lets take 1 step at a time
moobie: mjt, :P
edgecase: sgvadds, sort of, i have 2 displays, LVDS with s-video right-of, so right overscan is part of svideo, and bottom and bottom-right overscan is whitish garbage
soreau: moobie: btw, is radeon and drm modules loaded per lsmod?
sgvadds: edgecase, I have primary DVI DFP and s-video (DIN) right-of, native resolution of DFP is 1280x1024, max resolution of tv is 1024x768, so I have 1024x768 console on primary and the area at the right and bottom is just white. I temporarily solved this using video=1024x768
moobie: soreau, drm, but not radeon :|
edgecase: sgvadds, you make console artificially small, to avoid white overscan, in X?
soreau: moobie: Well that's a definite problem, in fact.. that's probably the whole problem
moobie: soreau, I guess you are right
soreau: moobie: Get to tty, stop gdm, modprobe radeon, start gdm, profit
edgecase: modprobe fbcon before or after?
moobie: Something is not right. I do got splendid 2d acceleration
soreau: But modprobe fbcon before radeon ;)
moobie: ;)
moobie: brb then
sgvadds: edgecase, no, I made it small in console to avoid white areas (i'm booting runlevel 3 so it's useful for me), X uses full 1280x1024 on primary and 1024x768 on tv
mjt: but when x is loaded, isn't it supposed to auto-load radeon?
mjt: i think it done that for me
edgecase: sgvadds, so just fbcon is having white areas at native resolution?
soreau: X doesn't load the kernel module afaik
mjt: but maybe i'm confusing it with something else...
edgecase: sgvadds, it must be clipping the console output then?
soreau: X loads the ddx, or the user space radeon X driver
mjt: soreau: yeah that's for sure
mjt: oh, i think it was fglrx
mjt: who auto-loaded kernel module
BioTube: x loads the drm module, but it doesn't wait long enough for KMS to initialize
mjt: aha, so it actually loads the kernel part!..
sgvadds: I'm not sure if that is fbcon, all I can see that I had these white areas before and that now I have 1024x768 boot console scaled to my full primary 1280x1024 DFP
moobie: Well I kinda found the problem
mjt: yay
moobie: The kernel 2.6.32 upstream has a problem with its radeon drm module
mjt: really?
moobie: It has some symbols which isn't right :)
mjt: i wonder how it works for me... ;)
moobie: you know. Unknown symbol ..... etc etc etc
mjt: i don't
edgecase: you using insmod or modprobe to load ?
moobie: mjt, well where did you get it?
soreau: moobie: Sounds like you have a module for a different kernel
moobie: I got it from a ubuntu kernel site
mjt: i compile it by my own
mjt: from kernel.org
edgecase: moobie, you used modprobe to load them?
moobie: edgecase, yes
mjt: heh
edgecase: moobie, x86 or x64?
moobie: mjt, well thats what I don't want ;)
moobie: x64
edgecase: pastebin the missing symbol errors
mjt: moobie: i maintain my own kernel and boot tools for debian for more than 5 years already... ;)
edgecase: usually depmod and modprobe figure those things out
moobie: edgecase, I think its easier just to install the lucid kernel
mjt: kernel-2.4.19 (1) unstable; urgency=low * First revision -- Michael Tokarev Fri, 11 Oct 2002 22:25:56 +0400
mjt: oh well..
moobie: mjt, make me a kernel ;)
mjt: http://www.corpit.ru/debian/tls/kernel/
moobie: mjt, jff. I have made my own kernels.
mjt: but i doubt that will do you any good
mjt: 'cause it needs my initramfs and stuff
sgvadds: edgecase, also I can figure that this behavour (white areas) was introduced not so far ago, it was black earlier. I have no much free time to find the source of problem so I wish to help you if you want.
moobie: Doesn't work :)
moobie: [ 93.199018] radeon: Unknown parameter `modset'
sgvadds: missed 'e'
moobie: NOOO! :P
moobie: Thats probably the root of my problem
moobie: mjt, is going to laugh his ass off
evil_core: thax soreau, airlied
soreau: np
airlied: soreau: GS is geometry shading
soreau: airlied: Ah
moobie: sgvadds, it should say radeon.modeset=1
airlied: edgecase: yes scaling center should have black surrounds, none should be unscaled so no soverscan
soreau: moobie: Maybe you needed to modprobe radeon modeset=1
airlied: I'm not sure none make sense on LVDS with a mode smaller than the native
moobie: soreau, I will try reboot first, when I changed it to the right
soreau: moobie: It was wrong?
soreau: bah, I should have caught that..
soreau: but that doesnt explain the radeon symbol issue still
tball_: It works
soreau: We know :)
edgecase: airlied, what is the meaning of "none", i was expecting it to be unscaled, gravity top left
airlied: sgvadds: yeah it just a missing memset/black fill in the fb cose
sgvadds: moobie, probably so. I just tried to help. May be I missed sometihing else
tball_: sgvadds, it worked. Thx
tball_: Now I need to get the glsl experimental and the powermanage patch to work
tball_: I'll recompile mesa :)
edgecase: none turns off rmx?
mjt: powermanage patch?
tball_: powermanagement patch
mjt: what's that?
airlied: edgecase: none means none, I don't think there is an option for unscaled, gravity top left
airlied: because who the hell would want that
sgvadds: airlied, it's about white areas? sorry i'm not clearly understand - but even if it will be no white no more - why can't I use my DFP as primary console and disable it for TV? Is it possible?
airlied: tball_: glsl on r600 is on by deafult
airlied: sgvadds: its a missing memset
airlied: at the moment the console appears on everything connected
airlied: you can disable TV on the command line if you want
airlied: video=TV-1:d
airlied: I think that is right
edgecase: airlied, i don't care where one the screen the unscaled, small screen is, but Center gave me top left with non-black overscan
moobie: Should I recompile libgl1-mesa-glx or libgl1-mesa-dri to get glsl with radeon?
airlied: edgecase: thats a bug that is fixed in 2.6.33-rc2
mjt: moobie: can you recompile only one of them?
edgecase: airlied, ty
moobie: mjt, I could recompile them both. But maybe only one of them was needed
mjt: the thing is that's the same tarball or git tree
moobie: Is it normal to have missing fontswith kms?
mjt: you need extra work to recompile only part of the tarball...
moobie: fonts with*
soreau: moobie: Those are ubuntu packages.. they have parts of different packages from upstream
mjt: moobie: sure it's normal - you can't have ALL fonts, some will always be missing...
soreau: moobie: If you want glsl, you would just compile mesa from git
sgvadds: airlied, but I tried this with no result two days ago. Or even yesterday - I lost in dates. Should I try this again? I mean 'video=TV-1:d' in hope that something changes. Btw, what names are expected for outputs. dmesg shows me that my s-video tv is DIN
moobie: soreau, got it
moobie: mjt, dude
soreau: moobie: But you are already using tormods repo so it should already be the latest
moobie: soreau, yeah but it seems glsl is not enabled
moobie: though I have heard it should be enabled by default
airlied: sgvadds: look in /sys/class/drm
airlied: got the proper name
airlied: for the proper name
soreau: moobie: Of course not, you dont even have radeon loaded much less 3D working
soreau: moobie: After you get a working kernel, I suspect it will all start working
sgvadds: airlied, I see following there 'card0 card0-9-pin DIN-1 card0-DVI-I-1 card0-DVI-I-2 controlD64 ttm version'. Should I use DIN-1&
sgvadds: ?
moobie: soreau, it works now :)
moobie: and I got prober kms
airlied: sgvadds: then video=DIN-1:d
soreau: moobie: What does glxinfo|grep nGL say?
sgvadds: OK Thanks I'll try now
moobie: soreau, my dmesg | grep radeon
moobie: http://pastebin.com/m2691a3e0
moobie: soreau,
moobie: OpenGL vendor string: Advanced Micro Devices, Inc.
moobie: OpenGL renderer string: Mesa DRI R600 (RV730 9480) 20090101 TCL DRI2
moobie: OpenGL version string: 1.5 Mesa 7.7
moobie: Well it seems I got a too old mesa
soreau: moobie: Then you need newer mesa
moobie: I need mesa 7.8
moobie: Didn't see that before
moobie: :P
mjt: but i really wonder what moobie wants to achieve...
mjt: OpenGL version string: 1.5 Mesa 7.7-rc2
moobie: mjt, radeon + kms + glsl
mjt: what for?
mjt: curious
moobie: mjt, I am curious myself :)
mjt: i'm curious why you need that set
moobie: and want to test the latest achievements with the oss stack
mjt: because, well, after so much time spent on this - not only your but others who're helping you -- it's interesting to know why that time has been spent...
moobie: mjt, sure. Well isn't it normal people wants to test the latest and greatest?
mjt: maybe
moobie: no one is forced to help me mate
mjt: sure
sgvadds: airlied, I tried DIN-1. "video DIN-1:d". No success. I also tried DIN-0, DIN. Could you give me some hint where it is parsed in source - may be I'll found the reason.
moobie: mjt, ohh and ofcourse. Try the oss against Heroes of Newerth (a game) using opengl 2.0
moobie: I really want to ditch fglrx
sgvadds: *find
sgvadds: airlied, and of course "video=DIN-1:d" - typo was there, not in config
edgecase: airlied, is that scaling mode implemented with CRTC overscan (on LVDS) or just by filling the area outside the screen with black?
mjt: hm. What's the way to tell X to load dri from different location, not from /usr/lib/dri ?
mjt: things like r600_dri etc
airlied: sgvadds: drivers/gpu/drm/drm_fb_helper.c
edgecase: you referred to memset... so filled with black pixels?
airlied: edgecase: the scaler does it, so not sure who does the overscan
airlied: edgecase: thats is different
airlied: edgecase: that is for the dual-head case
airlied: where the monitors don't match
edgecase: i mean, if scale 1:1
edgecase: oic
airlied: for the LVDS case its all hw
edgecase: ok let me ask another way, does the framebuffer size change when i switch to a mode < native panel size?
sgvadds: mjt, may be LIBGL_DRIVERS_PATH but I'm not sure
airlied: edgecase: no
airlied: edgecase: sorry yes
mjt: LIBGL_DRIVERS_PATH has no effect as far as i can see. Even before startx.
evil_core: why s3tc now doesnt work?
airlied: in X it resizes the fb
edgecase: ok ty
airlied: mjt: you can't tell X I don't think
mjt: LIBGL_DRIVERS_PATH=/opt/xorg/lib/dri/ startx
edgecase: airlied, know of any docs on rmx/panel scaler? i didn't see in the m56 i was reading
mjt: airlied: so the whole radeonBuildHowTo is wrong??
airlied: mjt: no I doubt that
moobie: kms + radeon + glsl works quite nice :)
airlied: you can use LIBGL_DRIVERS_PATH for cleints just no X
moobie: anybody knows howto install zajec's powermanagement patch?
mjt: the thing is that my X crashes right when i run ANY 3d client
mjt: crashes in r600_dri.so from /usr/lib/dri
mjt: even glxgears
mjt: er glxinfo
airlied: the server has a hardcoded DRI_DRIVER_PATH at configure time
mjt: ok
mjt: lemme symlink it
mjt: heh. that's progress - glxinfo does not crash X anymore
mjt: but does not report anything either
mjt: (EE) AIGLX error: Calling driver entry point failed
mjt: (EE) AIGLX: reverting to software rendering
mjt: which entry point it wants?
airlied: sounds like built with different configure options or something, like tls
mjt: (II) Module radeon: vendor="X.Org Foundation" compiled for 1.6.4, module version = 6.12.99 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0
airlied: mesa not the ddx
mjt: tls?
mjt: different than what? :)
airlied: the X server
mjt: ok makes sense
sgvadds: mjt, it's not best solution, but it's simple - install it at your system's default path. but do it only if you are ready to get nonworking X at all. I'm booting my system at runlevel 3 so I always get the console and then I could start X - if you want to test experimental drivers may be its good solution. And you always able to restore original drivers from console if you want.
mjt: --enable-glx-tls
mjt: that's from debian build
mjt: sgvadds: i want to be able to switch easily
sgvadds: mjt, i think easy switching is really hard. do you know where the paths are hardcoded, where they are used from environment etc?
sgvadds: mjt, it's probably possible but not so easy
mjt: let's see
moobie: Hello again guys. Anyone experience artifacts when resuming from suspend with radeon?
moobie: like if the image pitch is wrong.
mjt: airlied: that helped. I rebuilt mesa with the same flags as debian uses and it loaded and run ok, finally. fps in glxgears increased from 850 to 980 :)
mjt: apparently alot of apps linked with libGL uses hardcoded path to the library
mjt: i guess i'll file a bugreport for tha
mjt: t
sgvadds: moobie, i would try suspend now. I didn't tried tried this cos my system is almost always online, I'm rebooting it only when I'm experimenting with something. But is swap required for that? Can I suspend without swap in linux?
moobie: sgvadds, I think so
moobie: I don't know tbh
moobie: btw, is irq support something implemented in mesa or drm?
moobie: sgvadds, plz tell me if it worked :)
moobie: sgvadds, did you try it?
sgvadds: To clear something, I'm just a system developer, I was working for windows development, but now i'm out of work, not sure I said it right. maybe workless. :-). I'm russian. So now I'm going to find my way in the open source community. And my English is perfectly enough to read all I need from MSDN, but I suspect it's not so good when I'm talking there.
sgvadds: moobie, what are you asking about - suspend?
moobie: yeah :)
sgvadds: moobie, so can I do it without swap?
sgvadds: if I can - I'll try
moobie: I think so, but I honestly don't know
moobie: sgvadds, but just try it :)
sgvadds: Does anybody else have the answer?
moobie: if it fails, you can just reboot
sgvadds: OK. Then tell me how can I try it ^-)
moobie: Do you use gnome or kde?
moobie: or something else
sgvadds: Now kde, but I think its not the main problem
moobie: What is?
sgvadds: I think there are some scripts, but I can't remember exactly. And I still haven't so much time to read their source
moobie: Well I gtg sgvadds
moobie: Its bed time
moobie: But thx anyway
sgvadds: moobie. what is preferred way to suspend in linux
moobie: I just push the suspend button :)
sgvadds: moobie, the last time I used linux suspend wasn't working on almost all systems I had - that was few years ago
moobie: sgvadds, what version of kde?
sgvadds: moobie, I mean not the suspend button, but suspend at all :-)
sgvadds: moobie, 4.3.85 (KDE 4.3.85 (KDE 4.4 Beta2))
moobie: There should be a sleep button
moobie: sgvadds, look besides your power off button
moobie: shutdown*
moobie: next to*
sgvadds: moobie, I can't see it. - Logout - Lock - Switch User - Restart - Shutdown. May be some script I could run?
moobie: sgvadds, do you got the right modules loaded?
sgvadds: Which modules do you mean
sgvadds: ?
sgvadds: I don't know which modules are needed for suspend to work
sgvadds: That's why I'm asking here :-)
sgvadds: Could you tell me if there is some standard way for linux to suspend - some script etc?
sgvadds: If no, I'll better look at some docs if I'll have time
moobie: sgvadds, you need some modules I think
moobie: don't remember them though
moobie: depends on distro
moobie: and your cpu
moobie: sgvadds, well good buy
moobie: good night
moobie: I need to go
sgvadds: OK good night
sgvadds: airlied, are you still here?
evil_core: I got better performance with KMS
evil_core: something wrong on mine side?
sgvadds: evil_core, how did you get that?
sgvadds: ^-)
evil_core: i got r500
mentor: Hmmm, xf86-video-ati is SEGVing when it tries to access a mapped bo
evil_core: I got all power saving features enabled both in xorg.conf and radeon module
evil_core: can it cause such huge impact?
sgvadds: how huge? can you give some numbers?
evil_core: difference between kms ans non-kms?
sgvadds: yes
evil_core: I got also huge framedrop with s3tc disabled
evil_core: it doesnt work anyway
evil_core: and disabling it in gallium doesnt work
sgvadds: framedrop in what app? and you use gallium?
evil_core: it means i get crappy textures in quake3 with gallium
evil_core: no,m because it hangs mine machine
evil_core: quake3 works with gallium nice
evil_core: openarena works for 10-30seconds and hang
sgvadds: is q3 the same as openarena. Or are they different? I thought the engine is the same. Wrong again?
evil_core: both are ioquake3, but openarena was modified trough years
sgvadds: OK. I think I understand it. Anyway, what a difference between kms and non-kms - its strange that you get better performance with kms
evil_core: must check, but with s3tc enabled in driconf I get 400% performance boost
evil_core: s3tc doest work, and many textures are missed(especially animatited) or looks like pixel-art
evil_core: with s3tc disabled q3 is unplayable
evil_core: performance drops from 20-60 to 2-18
sgvadds: evil_core, all I heard was about that kms is slighltly slower. BTW in driconf there are two settings about s3tc. And more - where you are getting 400% boost, in which app? q3?
evil_core: no, its more messed up
evil_core: will count from demo
evil_core: maybe mocing trackpoint uses cpu ;)
sgvadds: is q3 free? could I get it somewhere to test. I have openarena, but it works fine for me all the last time.
evil_core: lol, in demo mod I got 38-90 fps after disabling vsync
evil_core: I hate openarena look
evil_core: its not free, but its easy to get "for free" ;)
sgvadds: BTW when I tried doom3 vsync settings doesn't worked - is there some explanation?
evil_core: sqvadds: you tried switching it in driconf?
evil_core: I am switching it only there
sgvadds: ok I'll try to get it to test (q3 i mean)
sgvadds: yes in driconf and in the game
sgvadds: it never shows more than 60 though its apparentlry possible
evil_core: usually I am using vsync
evil_core: xmoto for example works best with gallium in UXGA mode
sgvadds: and even under W7 - i tried switching it in Catalyst setting and in the in-game-settings - no result
evil_core: and it really differs, try uxga, in 1400 and less I dont got performance problems in any game
sgvadds: it shows 62-63
evil_core: wtf, catalyst?
evil_core: ouch, w7
sgvadds: yes, I have to use different systems to work. so I can use them to compare
sgvadds: btw i think there is some issue in doom3 with vsync so I've never seen it working faster than vsync
evil_core: demos confirmed it, I got 4x more fps with s3tc enabled
sgvadds: on every OS
evil_core: its not designed to work faster, but to not waste non-displayed cpu cycles
evil_core: aand avoid possible tearing
sgvadds: I'm not sure what for it was designed but I prefer to see something like 150fps. And the tearing is there anyway. At least on my system
evil_core: lol, whats impressing in wastinpower/draining battery
evil_core: vsync doesnt render frames that would be not displayed
Hackus: Merry Xmas. Now, Santa, where is my working DRI for Xwindows!!! I was a good boy honest!
evil_core: that are rendered to /dev/null
evil_core: sgvadds: its also gets more hot, so its shortening gpu life
evil_core: and makes fan more noisy, so in every aspect its stupidity
sgvadds: so you are going to say that frames are rendered and dropped? or I understand you wrong. I'm not so close with OpenGL but I think we just not getting back from the frame showing call tiil the time for the next frame - so we have no time to render useless frames
evil_core: i get no tearing with KMS, and only with KMS
evil_core: yes
evil_core: vsync sync frame rendering to monitor refresh rate
evil_core: not exactly, theres option in q3 to sync every frame
sgvadds: OK probably I've seen the same - no tearing with kms and with kms they are teared - don't know what's the reason.
sgvadds: But I think it's known
evil_core: its more complicated thing, you can also get triple buffering
sgvadds: How?
evil_core: so you are rednering frames ahead also
evil_core: game predicts next frames
sgvadds: I know what it is and how to do it programmatically. :-) My question is how can I get this with current drivers?
evil_core: I am not dri developer, so maybe better ask somebody else
evil_core: but if you know how code it, you can probably try set that mode and check if will work ;)
sgvadds: OK. I thought there are some settings like in W catalyst. I know how it works but I don't know how it is realized in mesa drivers. If it realized
sgvadds: is realized
mentor: Interrupt support as per topic?
sgvadds: mentor, what do you mean?
sgvadds: evil_core, btw, what is the preferred time for all to talk here. I mean when all the developers are here - I don't know where from the the UTC they are living
BioTube: sgvadds: bridgman, airlied and agd5f are all in north armerica AFAIK
sgvadds: airlied, as I can see the source file you pointed at is just parsing the right part of mode string, after the colon. May be I'm wrong - but I need to sleep also. May be tomorrow it will be clearlier. I still need to find where the name of display connector is parsed
sgvadds: Good night to all going to sleep and merry christmas to others :-)
mentor: sgvadds: vsync requires notification of vsync which occurs via interrupt and has only just happened?
evil_core: sgvadds: I know that adamk and Zajec are from UTC+2 like me
sgvadds: mentor, don't understand you good enough to answer - could you ask your question some other way that I'll understand or may be somebody else
evil_core: sgvadds: anyway airlied is in similar time (I live in Poland, but definitely not in UTC+2), and MostAwesomeDude later which are GODs there
mentor: sgvadds: I believe you are asking about vertically synchronised rendering; I believe the information in the topic may be relevant.
mentor: ?
sgvadds: mentor, I was asking about vsync, yes, but I know much about what vsync is, I just wanted to know how to control it from mesa driver settings :-)
evil_core: dricpmf and only driconf
evil_core: and xorg.conf
evil_core: try kms, I dont get tearingg with kms
evil_core: w/o kms you dont get pageflip on r400+
sgvadds: evil_core, it's strange? 2 hours of diff (I'm +4) but as I can see most talks here are something like +8 or even more. But I could be wrong of course. I'm not even sure what time it is now if don't look at panel :-)
evil_core: not in holidays
evil_core: airlied. MostAwesomedude and Raveman are paid devs, so they have break now
sgvadds: evil_core, Now It's more clear, thanks. Now I want to be some paid dev. No, It's just a joke. My freedom costs much more. :-)
sgvadds: Damn. I sure I could help the development but I just have no time now. I just got to find some stupid work. And then may be I'll have some time. That is as always in our life. Anyway I'll track the development and try to help as it possible
MostAwesomeDude: evil_core: I don't get paid for my Xorg work.
MostAwesomeDude: My day job is totally different.
MostAwesomeDude: Also AFAIK nobody's implemented the KMS pageflip for radeon, maybe I missed it.
sgvadds: MostAwesomeDude, can I ask you probably inconvinient question :-)
evil_core: MostAwesomeDude: you could miss anything in radeon development?
MostAwesomeDude: sgvadds: Sure, but don't be surprised if I don't have an answer. :3
MostAwesomeDude: evil_core: Yeah, I don't keep close tabs on all the patches that go into the kernel. airlied's the DRM maintainer, so a lot of patches go straight to him, and if I don't pay attention, I might never see them.
sgvadds: I will not be surprised. We, russians, are too straight people sometimes. I'm looking for the job now so Is it possible that you tell me how much you are getting for your job. Monthly, yearly, it doesn't matter. Or you may not answer at all if it's commercial secret. I just want to reproduce it to my future chief. :-)
sgvadds: And look at his face...
BioTube: i believe his day job is 'student'
evil_core: lol, maybe ask Steve and go to chief the ;)
MostAwesomeDude: Yeah, I work for my university. I don't get paid much.
evil_core: hm//dunno what I can do in feature
evil_core: wanted to be admin in the past, becaus I hate math and object programming
sgvadds: MostAwesomeDude, Ok so you are just worked for university and not paid? If it is so it is probably what I had till I left my University. They wanted me to work on thermonuclear synthesis, not sure how its named in english. Anyway i left it as wanted to deal with something more real.
evil_core: akk I know is linux management, so I am currently simply PLD developer
sgvadds: And I didn't want to became 'nevyezdnoy', don't know how to tell it in english - it's the man who can't leave the country coz he know too much :-)
evil_core: ouch, I undertand
evil_core: looks funny because I undrrstand it a bit
sgvadds: evil_core, what do you mean - what I said? That's a reason that now I looking for my own way in that life :-) And that's why I want to help open-source drivers to evolve, especially after fglrx failure to work with newer kernel and then with newer xorg. I'll try during my free time to work on mesa etc. I'll sure that I can help If could get enough time for that.
sgvadds: I don't even know why I'm telling you that, I could ask you to forget all of this if there were no logging. :-) Just a christmas. Sorry.
sgvadds: OK will play doom3 some more, maybe I'll catch some usefull or relax :-)
edgecase: i wouldn't call that game relaxing O.o
sgvadds: edgecase, I find any game relaxing as it lets me to throw out some emotions. can't find the right word for it -:)
evil_core: relaxing is stoneage, fizwizzle or even tc-elite
evil_core: sqvadds: no, russina is a bit like polish, especially when you are not using cyrilica
sgvadds: BTW doom3 works as expected but sometimes asks me for the key again - is it known problem? I'll try to look at "stoneage, fizwizzle or even tc-elite"
evil_core: stoneage works under dosbox and uae
sgvadds: but what about that " sqvadds: no, russina is a bit like polish, especially when you are not using cyrilica" - i didn't understand that
evil_core: its pirated vrsion I guess
evil_core: russian*
sgvadds: DOOM3?
evil_core: yes
sgvadds: of course?
sgvadds: it's just a joke russian means pirated?
sgvadds: I have licensed vesrion of D3
sgvadds: So I just downloaded free runtimes of doom3 and added packs as specified at the instructions
evil_core: I dont have, but pirated soft is standard in east eaurope
DanaG: In Soviet Russia.... $NOUN $VERB you!
evil_core: DanaG: :)
sgvadds: DanaG, what should be replaced
evil_core: sgvadds: /.
DanaG: eh, I didn't want to bother filling in the blanks. =P
sgvadds: Yes Pirated soft is standard, but not pirated is not more rare
sgvadds: I really have licensed version
evil_core: DanaG: but dont joke from putin, because irc is not encrypted, and we dont know if sgvadds doesnt use telnet to connect to shell ;)
sgvadds: of DOOM 3
sgvadds: evil_core, do you think I'm some kind of 'provocator' from putin?
sgvadds: :-)
evil_core: I got legal Fizzwizzle Collector Pack, Ignition, Fallout pack and thousand SNES games
evil_core: and many NES
evil_core: I dont think that new games are worth much
BioTube: too many times they think "siny" ==
BioTube: "good"
BioTube: at least crappy graphics meant games had to be good to sell
evil_core: I love pixel-art
sgvadds: Don't you think that this radeon channel is something invisible from the point of view of our prezidents - will it be Putin or Medvedev or somebody else
evil_core: not in soviet/putin russia ;)
BioTube: evil_core: what's impressive is things like descent that managed pretty great graphics on crappy hardware while maintaining gameplay
Hackus: Maybe Putin has problems with his DRI. :-)
Hackus: I know I do. :-)
evil_core: hi is grepping internet for putin, russia and red all the time
sgvadds: Hopefully Putin doesn't have the problems. If he would that drivers he use will be declassified 20 years later. So about medvedev
evil_core: its maybe not like Great Firewall, but KGB is getting stronger again
sgvadds: Is It bad?
evil_core: definitely
evil_core: its back to sviet russia
sgvadds: It's not on the topic but I think it's forgiveable - is it the right word.
evil_core: unit means nothing and only one person in country got right
sgvadds: What rights do you mean
sgvadds: ?
evil_core: putin got right
evil_core: or maybe.. I dont speak english too good
evil_core: everybody else is wrong, and if he thinks another, then he will dissappear
sgvadds: What are you talking about. I'm sorry but I'm even was'nt tracking our own news last time
sgvadds: Every way it's not the channel to discuss politics so advise me some to go to :-)
evil_core: I wanted to tell that Putin is like Koing Djon Ill
sgvadds: Where are you from, evil_core
evil_core: Poland
sgvadds: And what do you think about Russia at all?
evil_core: it was going to bo normal democracy country until Putin replaced Jelcyn
sgvadds: Are we the people who freed you or are we the people who occupied you
mentor: democratic
sgvadds: Especially now, as the ost plan was published
mentor: Yes
jwm: anyone have problems with transparency working with compiz?
evil_core: defintely not You
jwm: OpenGL version string: 2.0 Mesa 7.8-devel
Hackus: Wow, you get compiz to work? :-0
jwm: heh
soreau: Hackus: Having trouble getting compiz working?
Hackus: Can't get jack here to work. Jill ran off with my transparency.
jwm: I had it working great with fglrx and xorg 1.6
evil_core: Hackus: its strange that compiuz works?
jwm: now if I set a window class XTerm transparency of 70 or anything less than 100
Hackus: Trust me, you can't fix my problem.
jwm: and I start up mrxvt
jwm: I get no text unless I alt+mouse wheel it up to 100
soreau: Hackus: Of course not, but we can help you to fix it ;)
jwm: and window decorations are completely transparent
Hackus: First I have to find the problem, and I think it is vga arbitration is screwed on a two card video system with DRI.
jwm: I'm compiling 2.6.33 right now
jwm: see if that helps
soreau: Hackus: Well you probably wont get help unless you ask for it
jwm: heh
Hackus: I am looking at the vga arb code and KMS and I think it is entirely the wrong approach. No wonder it has so many problems.
jwm: I might try to go back to mesa 7.7
evil_core: sqvadds: red army didnt freed any country, it was "taking control". On evil replaced by another.
Hackus: Quite frankly its a train wreck.
Hackus: I am surprised it works for anyone. :-)
evil_core: sgvadds: Russia == linux, hackers, kgb, vodka and tetris :D
edgecase: Hackus, VGA is evil, arb or not
edgecase: the change from ISA to PCI should have eliminiated it
sgvadds: evil_core, did evil red_army transported some of native citizens somewhere. as it was planned in ost plan.
evil_core: whats arb?
sgvadds: :-)
soreau: jwm: That might be an easy test for you.. I didnt know glsl for r6-7xx code has so broken
Hackus: Still, I think in about 10 YEARS, if the video card manufactures make OPEN cards, things will get better, eventually.
jwm: glsl?
soreau: jwm: GL Shader Language
Hackus: We need more examples like AMD
jwm: ohh
BioTube: evil_core: arbitration
jwm: heh
soreau: jwm: Its why you get version 2.0 reported
jwm: opengl 2.0
edgecase: Hackus, intel is good AFAIK also
jwm: yeah if transparency doesn't work
jwm: isn't that the easiest thing to do..
Hackus: Yeah, the intel GMA stuff works out of thebox pretty well.
edgecase: i suppose EFI cleans up the ISA legacy
jwm: should I enable efi in the kernel framebuffer code?
Hackus: But, I have a Radeon 3870x2 in my laptop, which is the machine I am doing development work on.
Hackus: X absolutely is a dog on my ATI 3870x2.
evil_core: sgvadds: http://en.wikipedia.org/wiki/Generalplan_Ost? It was german plan, not russian
jwm: great
jwm: broadcom-sta doesn't compile with 2.6.33
jwm: heh
Hackus: Did you try 2.6.33-rc2?
DanaG: hmm, my laptop has UEFI... but it's a bit screwed up. if I use UGA-supported grub, I get video framebuffer, but if I try a newer version that supports GraphicsOutputProtocol, it hard-locks upon trying to use framebuffer.
sgvadds: evil_core, that was I'm saying. Russians never wanted to do something bad to Poland. NEVER. And the plan is from NAZIS. Sorry from offtop, but this theme touches everobody from Russia.
jwm: Hackus: no
jwm: it's just missing linux/autoconf.h
evil_core: sgvadds: yeah, they werent racist, they wanted to make one big communist country from the whole world and it failed. Nobody never hated russian citizens, only their reign, because citizen mean nbothing, can do nothing and even dont know whats going on in authoritative countries, because of censorship and propaganda
evil_core: sgvadds: but about red army: http://en.wikipedia.org/wiki/Katyn_massacre, and they robbed everything they were able and raped many womans. Red army were awlkays chaotic and undisciplined
soreau: re-reads the topic
scgtrp: i'm using a radeon 4100 on 2.6.32 with mesa-git and i'm getting graphics corruption in some apps. glxgears and bzflag work fine, blender sometimes renders extra objects that aren't really there, kpovmodeler's display is completely corrupted. what could be wrong?
evil_core: scgtrp: upgrade drm maybe. Wanna patch for 2.6.32 with current drm-radeon-testing?
soreau: jwm: Please let me know if downgrading mesa helps your issue
evil_core: no!
scgtrp: i've got libdrm-git 20091216. is this what the "recompile libdrm/ddx/mesa if you have anything before Sun Dec 20th" in the topic is about, or is that for something else?
evil_core: it will nto help him
BioTube: scgtrp: the API got rewritten then
evil_core: but drm shouldnt be updated also?
scgtrp: ... wouldn't that break already installed mesa-using apps?
bridgman: AFAIK it was the API between libdrm_radeon and mesa/ddx, not between libdrm_radeon and drm that changed
BioTube: scgtrp: it was the radeon-specific drm API
evil_core: you can always revert it
bridgman: not 100% sure though
BioTube: scgtrp: an internal issue between ddx, mesa and libdrm
scgtrp: ahhh. think that could fix my problem?
BioTube: scgtrp: if you had an API issue, you wouldn't get acceleration to begin with
scgtrp: ok then
bridgman: might just be driver bugs... not sure how well blender is running on current drivers
bridgman: haven't heard anything good or bad about how kpovmodeler is running
bridgman: has anyone else here tried blender recently on 6xx-7xx ?
evil_core: anyway upgrading drm can always fix or break more, its like russian roulette ;)
scgtrp: http://img34.imageshack.us/img34/2086/kpovmodeler.png << that's what happens to kpovmodeler. i can't get a screenshot of blender because the corruption disappears when i try
evil_core: I hate when nothing changes
sgvadds: Sorry again, evil_core can we go somewhere else to talk about that? Anyway I grieve about all the people died, but don't read only the western propaganda. I think our nations both went through that and now we can find the truth. But do you read not just the links to the "ost" plan but the plan sources which were published few day ago? Are you sure that nazi's army was the better choice for your country?
jwm: soreau: I don't have that problem under xcompmgr nor enlightenment 17's bling composite plugin
jwm: it must be a compiz issue
mentor: scgtrp: Can you take a picture which you can print out and fax to us?
scgtrp: heh
scgtrp: it'll just be a large cube appearing from nowhere covering most of the screen, zooming in/out makes it go away
scgtrp: messes with the ksnapshot timing options
soreau: jwm: That is not likely the case at all. Compiz exposes a lot of graphics driver bugs
scgtrp: http://img709.imageshack.us/img709/8994/blender.png
soreau: Which makes it a useful test tool
scgtrp: also, while i'm here: i can't enable compositing in the kwin settings
soreau: jwm: I would be very interested to know if downgrading mesa fixes the problem with compiz (I can just about 100% guarantee you it's not a compiz problem)
jwm: k
bridgman: scgtrp; there have been a few rounds of discussion about enabling kwin compositing; problems are showing up with a number of drivers
evil_core: sgvadds: did you get priv messages from me?
bridgman: don't remember seeing any resolution re: what the problem was; on the fglrx side the problem was punted back to the kwin devs but don't think anything came of it
scgtrp: note to self: nvidia.
sgvadds: evil_core yes let's go there
jwm: it's sad ati/nvidia is at such a crummy state with linux
jwm: I almost want to go back to using windows only on desktop
bridgman: scgtrp; think the kwin issue was reported against nvidia as well
scgtrp: nvidia always worked fine for me
jwm: yeah nvidia was decent for me too
scgtrp: didn't take compiling git versions of everything
jwm: but closed source
scgtrp: doesn't really matter to me, as long as it works
bridgman: this seems to be a recent change in the kwin detection code, seems like some kind of performance testing as well as caps
jwm: I never liked ati
jwm: heh
bridgman: looks like it hit all the vendors
jwm: software wise
scgtrp: bridgman: in what version?
scgtrp: hm
scgtrp: installs compiz to see what it does
bridgman: the first google hits were for 4.2.0
bridgman: which was a while ago IIRC
scgtrp: i'm really more concerned about the corruption though, i can live without compositing
scgtrp: compiz (core) - Fatal: GLX_EXT_texture_from_pixmap is missing
bridgman: ok, that's something different
soreau: scgtrp: What does 'glxinfo|grep renderer' say?
scgtrp: IRQ's not enabled, falling back to busy waits: 2 0
scgtrp: OpenGL renderer string: Mesa DRI R600 (RS880 9712) 20090101 TCL
soreau: You need to start compiz with --indirect-rendering since you're using DRI1
jwm: soreau: different mesa didn't help
soreau: jwm: Ok, thanks for testing
soreau: I wonder why it's so messed up for you
jwm: hehe
jwm: because it's me
scgtrp: soreau: WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported! This is an application bug!
scgtrp: WARNING: Application calling GLX 1.3 function "glXDestroyPixmap" when GLX 1.3 is not supported! This is an application bug!
jwm: do I want dbe xfree86-dga glx dri
soreau: scgtrp: Harmless mesa warning
scgtrp: (also, i have no window titlebars)
soreau: Hmmm...
soreau: scgtrp: You need to make sure to start compiz with ccp and make sure Window Decoration is enabled in ccsm (and that a decorator is actually being started)
jwm: I don't use ccp
jwm: heh
soreau: jwm: You have an HD3xxx, right?
jwm: yeah
jwm: 3200
soreau: jwm: You do use ccp because compiz-manager does all that for you
jwm: ahh
soreau: jwm: And did you say you get the above mesa warnings?
jwm: yeah soreau
jwm: but the interesting thing is the irq thing
soreau: Well something is wrong
jwm: it would go back to the wait thing
jwm: with fglrx
jwm: with radeon though it doesn't
soreau: jwm: Those warnings should only appear for older ati cards
scgtrp: soreau: plenty of warnings, no titlebars (after installing emerald and compiz-manager)
scgtrp: also i don't have ccp
jwm: soreau: I actually don't get the 1.3 warnings with any compiz app
soreau: scgtrp: You need to install libcompizconfig, compizconfig-python and ccsm then
soreau: jwm: There's only one compiz..
jwm: well there is ccsm
soreau: ccsm != compiz
soreau: ccsm is a python app, nothing to do with graphics
jwm: ok I phrased it wrong
jwm: anyway I went from rainbow windows
jwm: to yellow
jwm: but it just flashes for a brief second before the window is drawn
soreau: Well you still get the 1.3 warnings when running compiz-manager from a terminal?
soreau: I want to see a screenshot of your window borders
soreau: jwm: Do you have a decorator running?
jwm: whoa
jwm: wait
jwm: I turned off blur windows
jwm: and it fixed it
jwm: sweet
jwm: it's fixed
soreau: -_-
jwm: heh
jwm: cairo-dock even runs too
jwm: lol
jwm: let me try opengl mode
jwm: hehe
soreau: Yea, the functionality that alpha blur requires is not yet been implemented
soreau: I hope it will be soon though
jwm: heh
jwm: cairo-dock with opengl died
jwm: :)
jwm: figures
jwm: doesn't like fglrx either
soreau: What do you mean it died?
jwm: it crashed
jwm: too much crap is listed why
jwm: heh
jwm: it's fine
jwm: I use cairo as a backend
jwm: great, now I am going to unmask mesa again
jwm: and rebuild stuff
scgtrp: soreau: compiz runs but is being extremely funky
soreau: scgtrp: Describe funky
scgtrp: quite possibly compiz bugs though rather than radeon bugs (input going to the wrong places)
soreau: You mean like keyboard typing in the wrong window?
scgtrp: soreau: and mouse clicks, yes
scgtrp: that join/part above was me starting up irssi in a terminal (which was currently getting all the input) then attempting to close xchat which wound up closing the terminal instead
jwm: are you sure you just aren't use to input follows mouse?
jwm: hehe
jwm: my favorite behavior in X btw
jwm: :)
soreau: yea, I never heard of anything like this before
scgtrp: hates it, but to each his own
soreau: scgtrp: How are you starting compiz?
scgtrp: ... the window with non-gray borders should get input though, not the window behind it
scgtrp: soreau: ccsm
soreau: ccsm cannot start compiz
soreau: ccsm is the Compiz Config Settings Manager
scgtrp: ... then how did ccsm start compiz? O_o
soreau: It didn't
scgtrp: odd
jwm: I read a howto once that said use ccsm to start compiz
jwm: hehe
soreau: scgtrp: Here, what is the output of 'ps ax|grep compiz|grep -v grep'?
jwm: needless to say it confused me
scgtrp: soreau: too late, already did kwin --replace to get sane input behavior back
scgtrp: tries again
jwm: who started these --replace parameters
jwm: it confuses me
jwm: I run compiz standalone
jwm: but I use compiz-manager
jwm: so it does the replace stuff behind the scenes
jwm: emerald --replace
scgtrp: ahhh! that must have been it
soreau: Yea, I use X standalone with compiz
soreau: No DE
jwm: same here
jwm: high five soreau
scgtrp: compiz-manager is in my .bash_history, so i suppose so
soreau: :)
jwm: do you use cairo-dock soreau
jwm: I'd like something like windows 7 really though
jwm: heh
soreau: jwm: No I just support it
soreau: I don't like docks personally
jwm: me neither
jwm: I use windows+r in windows
jwm: to run everything
jwm: is there a cool run blah app
scgtrp: write one, can't be too hard :)
soreau: It's Super+R now
soreau: no more windoze
scgtrp: anyway
jwm: hehe
soreau: ;)
jwm: maybe I will put a single line xterm sticky across all desktops
jwm: and have a window focus to it hotkey
scgtrp: soreau, jwm: any input on the graphics glitches in blender/kpovmodeler?
soreau: jwm: lol
soreau: scgtrp: I don't use either of those so wouldn't know
jwm: yeah sorry scgtrp
jwm: I haven't tried blender yet on nix
jwm: I've used linux/bsd on server end for 15 years now
jwm: heh
jwm: off and on (more off than on) on desktop though
scgtrp: well, that's interesting
scgtrp: after all that screwing with compiz i started up kwin again and got compositing without doing anything
gregorian: hello, starting GNOME with the radeon driver takes 3 and a half minutes, while the vesa driver takes 5 seconds. Please help me resolve this issue.
gregorian: is anyone there?
MostAwesomeDude: Nope, nobody here.
MostAwesomeDude: Are you actually testing from a cold boot?
MostAwesomeDude: Or did you just change xorg.conf and restart X?
MostAwesomeDude: GNOME takes forever to load, the first time after a cold boot.
MostAwesomeDude: But it's all still in memory if you only restart X.