eboettcher: hm.. for the different programs in mesa/progs/tests, is there a place with images/descriptions of the correct results?
airlied: okay http://people.fedoraproject.org/~airlied/r500_gitdown_patches.patch
airlied: thats a load of separate patches you can use git-am to apply to r500-support
MostAwesomeDude: airlied: Do I want to know?
airlied: until git comes back.
MostAwesomeDude: Oh.
MostAwesomeDude: git died?
airlied: MostAwesomeDude: well I think only you and Alex should really care ;)
airlied: MostAwesomeDude: not openssh issue.. Debian..
airlied: fail..
MostAwesomeDude: airlied: Oh, that crap?
MostAwesomeDude: Glad I'm on Gentoo.
airlied: MostAwesomeDude: yup fd.o runs Debian..
MostAwesomeDude: Could be worse. Somebody let a CIA bot into #zen-sources, and it's been reading off the commit list from wireless-compat or such for the past few hours.
MostAwesomeDude:
MostAwesomeDude:
MostAwesomeDude:
MostAwesomeDude: Etc.
airlied: MostAwesomeDude: so I fixed the randomness I think
airlied: at least tri-add
MostAwesomeDude: airlied: Really? Lemme check this patch.
airlied: its like 8 patches in a mailbox
airlied: http://people.fedoraproject.org/~airlied/r500_gitdown.patch
airlied: is it compressed into one patch
MostAwesomeDude: Ah. Reading now.
airlied: MostAwesomeDude: the important one was the r300_shader.c bit
airlied: allocating the correct program size
MostAwesomeDude: Ah.
airlied: also the default clear fp was hiding some issues.. it was bad hack..
airlied: now it shuld be okay.
MostAwesomeDude: Was I off-by-one when outputting that OUT inst?
airlied: MostAwesomeDude: yes :)
MostAwesomeDude: Figures.
airlied: they didn't help much either :)
MostAwesomeDude: The first off-by-one in years, and I completely miss it.
airlied: well I got the RS texcoords backwards.
MostAwesomeDude: XD, wow.
MostAwesomeDude: Looks solid. Lemme apply and test.
MostAwesomeDude: Doesn't apply cleanly. Probably just small whitespace errors.
MostAwesomeDude: One second.
airlied: it should go on top of Alex's last patch
airlied: you may need to git pull his lceanups if you haven't
MostAwesomeDude: airlied: Which I do not have, unfortunately.
airlied: well anon git works.. just not ssh git
MostAwesomeDude: Well, I have from about 12 hours ago; is there newer stuff?
airlied: so you can pull them just not push back.
airlied: it should apply on clean up HA registers
airlied: GA registers even
MostAwesomeDude: Yeah, that's my current head. f86baae...
airlied: are you using git-am to apply?
MostAwesomeDude: No, was using patch.
airlied: the r500_gitdown_patches.patch is for use with git-am..
airlied: it contains 8 patches
MostAwesomeDude: I see.
airlied: so patch will only get confused
MostAwesomeDude: Ah. That's pretty snazzy.
MostAwesomeDude: I learn new git stuff every day.
MostAwesomeDude: Like I just learned about git stash.
airlied: we have some wierdass timing issues.
airlied: like I can get quad-tex-2d to work sometimes if I run it with lots of debugging on going to a file.
airlied: multitexture is still all loss..
airlied: it really kills the card dead
MostAwesomeDude: airlied: Like, hangs, or just very very slow?
airlied: MostAwesomeDude: card hangs, X goes to 100%, ssh goes slow
MostAwesomeDude: Wow.
MostAwesomeDude: So, that means that there's a lot of latency, right? We tell the card to 3D clear or 3D idle and it takes a while becuase we're doing something wrong?
airlied: no we just programmed it and it died.
airlied: X is just spinning on the wait for card to idle.
airlied: it never gets it.
MostAwesomeDude: Ah.
MostAwesomeDude: Poor X.
MostAwesomeDude: Sounds like my dates.
airlied: texturing is really busted.. its pot luck if it works.
airlied: oops texenv kills it .. tries lrp opcode.
airlied: in theory you should be able to do a lot of the other opcodes now.
MostAwesomeDude: Oh definitely.
airlied: its definitely a lot less random now.
airlied: I might see what I can do with texturing if I get anymore time.
airlied: or maybe Alex can see something really wrong
MostAwesomeDude: Wow, glxgears looks perfect.
airlied: I acutally haven't tried without renderaccel enabled.
MostAwesomeDude: Well, Composite still doesn't work right, although I gather that's not really our problem.
MostAwesomeDude: But tri-add finally looks right.
airlied: MostAwesomeDude: which bit of composite? xcompmgr + gears?
MostAwesomeDude: Well, 3D draws on top of everything else, and then Composite stuff draws on top of it.
airlied: the dirver needs major work to stop that..
MostAwesomeDude: Killing kompmgr makes everything nice again, so it's not EXA.
MostAwesomeDude: To be fair, fglrx still can't do Composite properly.
airlied: well only one open source driver can even kinda do it..
MostAwesomeDude: Somehow Alex got XV to be perfect w/Composite, although I think that's because it's in a different place.
MostAwesomeDude: airlied: Intel?
airlied: and its not shipping anywhere yet..
airlied: MostAwesomeDude: the Fedora Intel driver can do it.
airlied: MostAwesomeDude: Xv is in the DDX..
airlied: MostAwesomeDude: direct rendering is very different
MostAwesomeDude: airlied: Righty.
MostAwesomeDude: Is it even Mesa's problem?
airlied: MostAwesomeDude: its all of X's problem and the kernel.
MostAwesomeDude: Is it one of those things that needs Gallium/DRI2?
airlied: MostAwesomeDude: its not a fix it in one place..
airlied: MostAwesomeDude: its jsut DRI2.
airlied: not gallium
MostAwesomeDude: Ah.
MostAwesomeDude: I'm still not clear on Gallium yet. I know that it's both a superset of Mesa and a replacement, but I'm not clear on the details.
MostAwesomeDude: I just know that it needs to have hardware shaders.
airlied: MostAwesomeDude: its just an evolution of Mesa.
airlied: hmm I think its working with no render-accel ..
airlied: which might be good ... will play on laptop later.
airlied: time to go home me thinks.
MostAwesomeDude: Sounds like a plan.
MrCooper: as far as Mesa is concerned, Gallium is mostly just a new driver model
airlied: bbl maybe..
MostAwesomeDude: Unbroke MAX, MIN. They had bad copypasta.
MostAwesomeDude: 'k.
Zajec: airlied: do you know if someone was working on DRI2 for radeon?
MrCooper: Zajec: glisse
MostAwesomeDude: Zajec: I think glisse has some code.
Zajec: mm, nice :)
MostAwesomeDude: Wow, tri-add finally works. GW airlied.
Zajec: goes school
MostAwesomeDude: Whoo. Implemented all of the SOPs, and FRC, so pretty much all of the simple one-inst opcodes.
MostAwesomeDude: Now if only I could push.
airlied: MostAwesomeDude: churn em out :)
MostAwesomeDude: airlied: You got it.
MostAwesomeDude: When will we have git back up?
airlied: MostAwesomeDude: 2-3 hrs hopeefully, I think daniels might have it figured out by then.
MostAwesomeDude: airlied: Alright. Hopefully somebody will let me know if they need my key again.
MostAwesomeDude: I'm not revoking my old one since it was generated by an unpatched openssl.
airlied: I think the plan is to ban all the vunerable keys or some such.
MostAwesomeDude: Ah.
airlied: apparently only 32767 could have been generated with the code.
MostAwesomeDude: Huh. You think somebody would have noticed by now.
MostAwesomeDude: At some point, will we ever use STAT_WE?
airlied: MostAwesomeDude: maybe in the future when we are trying to beat fglrx ;-)
MostAwesomeDude: airlied: Okay. So I have every elementary (one-inst) opcode except SWZ.
MostAwesomeDude: (SWZ is special. I'm working on it.)
MostAwesomeDude: Is there any easier way to get a^b than e^(b*ln(a))?
airlied: MostAwesomeDude: not sure I suck at maths ;:-)
MostAwesomeDude: airlied: Fortunately, I took the maths in school.
airlied: MostAwesomeDude: I did as well and used to be quite good, but I've paged it out..
MostAwesomeDude: Hmm. So three insts. LN a, MUL b, tmp, EXP tmp.
MostAwesomeDude: Or LN2, MUL, EX2. Whichever base.
MrCooper: base 2 might be more efficient in hardware
MrCooper: or I might be on crack :)
MostAwesomeDude: MrCooper: Base doesn't matter, I'm just used to using ln and e from calculus.
MostAwesomeDude: In hardware, it's 2^x and ln2(x)
MrCooper: sounds like what I meant - 'base' may be the wrong term, I'm not very familiar with English math terms
MostAwesomeDude: MrCooper: Where did you learn maths?
MrCooper: .ch
MostAwesomeDude: Ah.
MostAwesomeDude: In a^b = c, or log_a(c) = b, "a" is the base.
MostAwesomeDude: I'm just glad we have hardware trig.
MrCooper: right, and my gut feeling is that either the base doesn't matter, or 2 will be more efficient
MostAwesomeDude: MrCooper: Correct on both counts.
MostAwesomeDude: Base doesn't matter, and base 2 is the only base in hardware.
MrCooper: that sounds like a contradiction in itself for 'matter' as in 'make a performance difference' :)
MostAwesomeDude: Oh.
MostAwesomeDude: Mathematically, base doesn't matter.
MrCooper: sure
agd5f: airlied: nice work!
_Krieger_: i`m using linux. i have slow 2d redraw in Xorg. Using xf86-video-radeonhd
_Krieger_: any solutions?
agd5f: eboettcher: the imge thing is firefox is an XAA bug in the server. You can disable offscreen pixmaps or use exa. ajax might have fixed it in xserver git
agd5f: eboettcher: for seeing the correct results you'll need to run the tests agains sw mesa
MrCooper: how would people feel about enabling EXA by default as of xserver 1.5.99?
agd5f: MrCooper: sounds good to me
david_brent: hi
partymol2: hello
partymol2: airlied, are you there?
partymol2: I have just noticed the issue with duplicated PCI IDs you mention in commit 1d0f1d31e2ed1d91ee87cb3e02ce48c8c07aa418
partymol2: I am the owner of the Vostro 1100 :)
partymol2: Have you made any change to the driver? I could try it out
MostAwesomeDude: airlied: Okay, so SCS has issues.
MostAwesomeDude: Heavy, heavy glitching, followed by card lockup.
MostAwesomeDude: X goes slow, ssh goes slow, laptop nearly melts itself overheating, I have to pull out the battery and apply ice.
MostAwesomeDude: Now, looking at the demo prog, the last two insts are SCS output, temp[0].x; END.
MostAwesomeDude: What's happening here is pretty evident. We're only writing to two of the output channels.
MostAwesomeDude: I watched it. It fills up enough pixels as it can run, and then all of the pixels stall waiting for the other two channels (B, A) to be written to.
MostAwesomeDude: Is the correct solution to make SCS fill all four channels? If so, what to fill them with?
dmb_: MostAwesomeDude: which demo is this?
MostAwesomeDude: dmb_: fp/tri-scs
dmb_: i want to see mine lock up :D
MostAwesomeDude: It's not in the master. Won't be.
dmb_: oh
MostAwesomeDude: SCS works by putting the cosine in R, and the sine in G.
dmb_: MostAwesomeDude: btw, i think there is a regression with my card
dmb_: a couple of weeks ago, glxgears was working
dmb_: now nothing\
MostAwesomeDude: But reading the docs, there's this: "The z and w components of the result vector are undefined."
dmb_: i run glxgears, its a blank black window, and after i move it, the gears start to show
MostAwesomeDude: So we have no idea what's supposed to go there.
MostAwesomeDude: dmb_: You know how to use git, right? Could you bisect?
MostAwesomeDude: I have a feeling I know where it broke, but I'm not sure.
dmb_: i'm using it right now
dmb_: yeh
dmb_: well, i know how to get around
dmb_: apply patchs etc
dmb_: bisect?
dmb_: hmm
dmb_: do i need to find the revision that worked?
MostAwesomeDude: Yeah. I'm actually gonna read off a rev to you, and I want to see if it works for you.
dmb_: ok
MostAwesomeDude: Try 1da094c
MostAwesomeDude: That's the last one that works for me.
MostAwesomeDude: Alternatively, load the mailbox patches from earlier; they make everything perfect for me.
dmb_: MostAwesomeDude: the ones airlied made?
dmb_: because i tried those
MostAwesomeDude:
MostAwesomeDude:
MostAwesomeDude:
MrCooper: MostAwesomeDude: write to a temp and then move that to the output reg?
MostAwesomeDude: Use git-am to apply it.
dmb_: yeh, i'v all ready used that patch
dmb_: no change
dmb_: i used git-apply to apply it
MostAwesomeDude: dmb_: No kidding? Now that's interesting.
MostAwesomeDude: Oh, you need to use git-am.
dmb_: whats the difference?
MostAwesomeDude: git-am will apply them correctly. git-apply chokes.
dmb_: hmm,i think i have to revert the other patch
MostAwesomeDude: Probably.
dmb_: maybe its just easier to revert to that revision
MostAwesomeDude: I'm not sure how you managed to get git-apply to apply them.
MostAwesomeDude: Eh, I would reset to the r500-support head, then re-apply the patches.
MostAwesomeDude: They clean up pretty much all of the TCL problems; you should have perfect TCL gears.
dmb_: yeh, agreed, won't let me revert either with those patches
MostAwesomeDude: Hmm.
MostAwesomeDude: I don't know what you did to your tree; apply git reset liberally until it works again.
MostAwesomeDude: You may have to re-pull.
MostAwesomeDude: The current r500-support head is f86baae.
dmb_: yeh
dmb_: just going to repull, messed something up big
dmb_: ok, applying now
dmb_: hmm
dmb_: Patch does not have a valid e-mail address.
MostAwesomeDude: Huh.
MostAwesomeDude: It doesn't?
dmb_: http://people.fedoraproject.org/~airlied/r500_gitdown.patch just looks like an ordinary patch doesn't it?
MostAwesomeDude: Yeah, but my git-patch choked on it.
MostAwesomeDude: Sorry, git-apply.
MostAwesomeDude: And then airlied said...
MostAwesomeDude:
MostAwesomeDude:
MostAwesomeDude:
MostAwesomeDude:
MostAwesomeDude:
MostAwesomeDude:
MostAwesomeDude:
MostAwesomeDude:
dmb_: interesting
dmb_: git-am worked for you?
MostAwesomeDude: Yep.
dmb_: hmm, maybe that was a warning
dmb_: because when i ran it again, it says previous dotest directory .dotest still exists but mbox given.
MostAwesomeDude: Huh.
MostAwesomeDude: Wiggy.
dmb_: i'll just check the files myself and see if they were changed :P
dmb_: nope, it didn't apply it
dmb_: maybe my git version is too old
MostAwesomeDude: Which version, distro?
dmb_: git version 1.5.2.5 ubuntu gutsy
MostAwesomeDude: 1.5.3.7 vanilla here.
MostAwesomeDude: Shouldn't be any big deal.
MostAwesomeDude: Done anything weird to your tree?
dmb_: yeh
dmb_: i completely recloned it
MostAwesomeDude: Hmm.
dmb_: then did git checkout origin/r500-support
MostAwesomeDude: So your head was the GA register cleanpu?
MostAwesomeDude: *cleanup
dmb_: yes
MostAwesomeDude: And then git-am
dmb_: dmb@alpha:~/Projects/mesa$ git-am r500_gitdown.patch
dmb_: previous dotest directory .dotest still exists but mbox given.
MrCooper: .dotest is usually a leftover from an aborted Git operation
otaylor: dmb_: see the discussion section at the end of the git-am man page
dmb_: the patch doesn't contain any of those
dmb_: its not in a mail format
dmb_: going to try git-apply again, and make sure all the diffs were applied
otaylor: dmb_; to quote "The command refuses to process new mailboxes while .dotest directory exists, so if you decide to start over
otaylor: from scratch, run rm -f -r .dotest before running the command with mailbox names."
dmb_: yeh, i removed it
dmb_: still get email error message
otaylor: ok, it wasn't clear what you were saying before
otaylor: dmb_: you are trying to git-am the whole eamil, and not just the body of the email, right?
dmb_: otaylor: isn't even an email, its right here: http://people.fedoraproject.org/~airlied/r500_gitdown.patch
MostAwesomeDude: otaylor: It's mailbox patches.
otaylor: dmb_: yeah, you can't apply that with git-am. Maybe airlied meant something else?
MostAwesomeDude: I dunno. He said git-am, and it worked for me. Unbroke my TCL and everything.
dmb_: i just looked over all the changes in the patch, and it seemed git-apply did it correctly
MostAwesomeDude: Huh. Go figure.
MostAwesomeDude: Well, as soon as git comes back, I have stuff to commit.
dmb_: after recompiling, only need to restart x right?
MostAwesomeDude: Not even.
MostAwesomeDude: After "make && make install", should be good to go.
dmb_: just rerun the gl app :D
MostAwesomeDude: Yep.
dmb_: ok
dmb_: oh, i always copied the stuff manually :D
dmb_: interesting, seems to work, when i thought i did the same last time
dmb_: lets try some zsnes ogl
dmb_: well, it shows
dmb_: just not very correctly
dmb_: http://img140.imageshack.us/img140/2549/screenshotzsnesak6.png that is zsnes
dmb_: its an improvement!
rx__: nice
MostAwesomeDude: XFD, that's about what I get.
MostAwesomeDude: At least snes9x is perfect.
MostAwesomeDude: Thanks, XV!
dmb_: i shall try
dmb_: oh yeh, xv
dmb_: cheater
simpson: SCS killed my card again.
simpson: Damn.
dmb_: lol
dmb_: watch out to not overheat your card too much
simpson: I'm going to go back to instructions which don't have these annoying "undefined" thingys.
dmb_: i had a bad experience
MostAwesomeDude: XD
MostAwesomeDude: "So why don't you like dogs?"
MostAwesomeDude: "I HAD. A BAD. EXPERIENCE."
dmb_: lol
MostAwesomeDude: Great movie.
dmb_: can't remember which movie thats from
MostAwesomeDude: The Italian Job.
dmb_: OH YEH
dmb_: great great movie
dmb_: Mark Wahlberg is a great actor
MostAwesomeDude: Surprisingly, yes.
dmb_: he was great in Departed also
MostAwesomeDude: Yeah. The Departed is an amazing movie.
MostAwesomeDude: XD, the r5xx US is soo powerful.
MostAwesomeDude: SWZ is like MOV.
MostAwesomeDude: Works fine.
MostAwesomeDude: I need to do negation at some point, but that's no biggie.
dmb_: MostAwesomeDude: is that some asm?
dmb_: hmm, never heard of the SWZ instruction
MostAwesomeDude: dmb_: It's basically a more powerful swizzle than normal select.
MostAwesomeDude: Lets you swizzle to one or zero.
MostAwesomeDude: Also lets you negate per-channel, but I haven't decided how I'm going to do that.
dmb_: i don't know much about graphics stuff
MostAwesomeDude: But I already wrote good code the first time around, so it's exactly like a MOV.
dmb_: so, a guess gpu's have there own instruction set?
MostAwesomeDude: Right.
MostAwesomeDude: But they typically implement similar instructions.
MostAwesomeDude: And technically you can do anything with MAD (multiply and add).
MostAwesomeDude: For example, the r3xx/r4xx shader doesn't have hardware trig (SIN, COS) so it's done using parabolic approx.
dmb_: oh
dmb_: guess you have to be good with math to work on this mesa stuff :D
MostAwesomeDude: Sorta.
MostAwesomeDude: Nothing past calculus.
dmb_: my main issues in calc were trig stuff anyway
gusta1: I've just ordered two new monitors, and one thing strikes me - how do I tell 'radeon' (or whatever part of X.org) to use a certain .icm file for color matching for a certain monitor?
glisse: gusta1: i think it's not supported yet
gusta1: by 'radeon' or X.org? color profiles has been implemented in Windows and Mac for one and a half decade at least...?
glisse: gusta1: well i am lacking knowledge on color profile but i think X doesn't have proper infrastructure for this but this should be in randr 1.3 at least if i properly heard discussion
gusta1: this surely must have had at least Any kind of priority in X before the compiz/aiglx mumbo jumbo got so much attention... damn it, i just bought two expensive monitors with excellent color...
glisse: i mean for several different monitor color profile
gusta1: ok, but for one profile for all monitors, there should be support?
glisse: gusta1: yup somethings like xcalib
glisse: iirc
glisse: but maybe otherthings
gusta1: k great thanks.. i'll just hope the multi-monitor support will be better one day. that's one of the reasons i'm swapping my current two (different) monitors, because it works so extremely bad in X..
dmb: xcalib works
dmb: i'v used that
glisse: gusta1: this guys is working on this color stuff i think http://www.behrmann.name/
dmb: i use icc profiles all the time with xcalib
gusta1: cool..
gusta1: dmb: is xcalib a program you have to run everytime you start x?
dmb: yes, i just set gnome-session to run it
gusta1: I think this should be part of the Monitor section in xorg.conf. that's the only thing that makes sense to me..
gusta1: christ
dmb: i agree
dmb: the only monitors that ever really told you to use icc profiles were the mac ones
gusta1: I want my new monitors to get the correct profiled colors, that's all... In soviet russia 50 years ago, I agree this might be overkill, but not to have decent color profiling support in X.org in 2008 is just embarrasing.
glisse: i am really insensitive to this i own a mac monitor and never bother to care about color calibration one day i should try see if it makes a differences
gusta1: i've read that the monitors i've bought really really need correct profiles, because they are badly calibrated by default...
dmb: glisse: it makes a HUGE difference on mac monitors
dmb: gusta1: i would search around any maybe file a bug if one isn't all ready filed
dmb: that would be great to see in the roadmap
dmb: i think the functionality is there, just not a user interface
gusta1: with today's MASSIVE corporate support (Redhat, Novell, Ubuntu to name a few) one would expect that there were at least _some_ decent implementation (per-monitor, simple interface, not some run-for-each-session crap solution), but no no.. i'll look at xcalib though, it's something... and thanks for the tip.
glisse: gusta1: ubuntu isn't that much supportive
glisse: go look at commit log and count number of ubuntu hacker...
agd5f: gusta1: you can adjust the gamma per head with xrandr 1.2
agd5f: not sure what apps support it
airlied: gusta1: everyone thinks their problem is important.
glisse: agd5f: waaoo i though that was randr 1.3 feature :)
airlied: gusta1: unless a customer shows up I ain't touching icc with a barge.
airlied: pole even.
gusta1: agd5f: gamma is important, sure, but icc profiles are more than just gamma, no?
agd5f: gusta1: no idea
dmb: take a look at the source for xcalib
dmb: its very simple
dmb: i think it is just gamma stuff
dmb: we would just need to implement a icc reader/parser
gusta1: glisse: yes, everyones own problem is "the most important", but seriously, no color profiles? but we have a huge crowd of kids cheering the compiz (mac osx look-alike junk)? that surely got attention.
gusta1: and having two monitors of different resolution with bad/no edid or different refresh rate (as I do now). congratulations ;)
dmb: gusta1: i think you should mention it in #xorg
gusta1: yeah
gusta1: i just wondered if it was per-driver, but it isn't i assume
airlied: gusta1: no hacker that cared enough to work on it..
airlied: gusta1: no customer paid RH enough to make any of our hackers work on it
dmb: gusta1: feel free to make a patch :P
gusta1: airlied: and not even Intel?
airlied: gusta1: as I said, there isn't a customer demand for it..
agd5f: gusta1: the color people complain every now and then that we don't support it, but, they never quite say what they want so we don't know what to implement
otaylor: gusta1: the only people who really care about color on linux are the animation studios, and they have their own high-end custom solutions
airlied: it sucks, but generally people don't care.. granted I'm now semi interested as I own a big Apple.
gusta1: yeah, i've fixed issues in gstreamer with a null-response from my patches, so my patching experience isn't the best :/
airlied: and if it makes it look nicer...
otaylor: gusta1: desktop publishing on linux is not a significant market for anybody
gusta1: and regular end-users who have some kind of interest in photo editing? ;)
otaylor: gusta1: they aren't customers, by and large
gusta1: but I get it, unless corporates do care, we won't see much.
otaylor: gusta1:I think the real problem is a little different
glisse: gusta1: last time i went out money was still king of the world ;p
otaylor: gusta1: the people who care at hobbyist level are "color geeks" ... and they see color as a really complex problem
gusta1: agd5f: what the color people probably want is what has been in Windows and Mac for decades. simple "use this .icm file for this monitor"-support ;)
agd5f: gusta1: but what does that mean?
otaylor: gusta1: they aren't all that interested in working in simple out of the box solutions, which is what is needed as a first step
gusta1: that's probably true otaylor
gusta1: a Windows-approach is not enough for the "color geeks", they would need some theoretically perfect solution. instead we end up with almost nothing ;)
agd5f: gusta1: hw people can say I have these knobs, and the color pepke say I have this icm profile, but we are missing how to connect the two
gusta1: yeah, perhaps this is something for randr 1.x (x>3)
gusta1: agd5f: the weird thing is, if xcalib has been there for years, and can "get the job done" more or less, why hasn't anyone moved it into X.org? you can't say you are missing "how to connect the two"..
agd5f: gusta1: I've never heard of xcalib until now
gusta1: heh ok...
otaylor: gusta1: Note that there has been traditionally uncertainty about patents in this area as well
gusta1: oh..
gusta1: but writing it outside the US could be a start then ;)
gusta1: as a non-american i really don't care or respect software patents much, and I don't really respect patents as reasons for not releasing open source code that might violate it.. but maybe i'm a bit naive..
otaylor: gusta1: well, often paying to much attention to what *could* be patented is a mistake (and I have no idea if there are relevant patents or not here, and am not qualified to investigate); but it's certainly something that has discouraged work in the past
gusta1: yeah, that's really too bad. and unless you have an implementation you can't know if it violates anything. but you don't want to spend a year of free time on something that might be shut down in the end... it's tough.
agd5f: gusta1: looks like xcalib should work if you update it to use the randr 1.2 per-head gamma hooks
otaylor: gusta1: anyways, basically I think what the area needs is someone to figure out what the simple big picture is (from the user interaction point of view as much as anything)and then what are the steps to get there
gusta1: otaylor: exactly.. and maybe someone==keithp :)
gusta1: agd5f: thanks, i'll look into it, doesn't sound too much of a hazzle
otaylor: gusta1: "someone" here would likely be someone new showing up interested in the problem with a motivation to see it fixed
otaylor: gusta1: (which probably means that their first stab at the simple big picture would be wrong, but that's what feedback and iteration is for)
gusta1: could be, but from what I can see, icm would be great for randr, and randr is like a big piece of un-documented stuff, so that "new guy" will need a mind of steele
airlied: gusta1: randr protocol is all documented
otaylor: gusta1: randr is the right place for the *small* pieces of the picture "how do I configure the gamma ramps for a particular crtc (output)"
otaylor: randr: and maybe also for the piece of the picture "how do I find out what this monitor reports for a icc profile"
gusta1: but the implementation? I tried to get a simple overview last summer iirc, and found nothing...
otaylor: gusta1: the X server really isn't that bad to dive into if you go in with the mindset that a) it's going to be confusing for a bit b) but it's not really that much code in the end
gusta1: but it's still very complex...
airlied: no its very large.
gusta1: and there's really no good overview (at least not that i've found) of the parts/modules, how they interact etc..
airlied: you just need to learn to ignore large parts of it.
airlied: and not care about how they interact..
otaylor: gusta1: but the bigger picture includes things like "in what colorspace is graphics computation done ... is it always in sRGB?" and "what does the configuration tool that the user uses look like"
airlied: ponders using a frag shader + rotate to do color profiles ;-)
otaylor: gusta1: gcc is complex. filesystems in the kernel are complex. most of the X server (leaving aside 5-10 source files) is not complex
gusta1: sure, and the first question is easy for current devs to answer, and the second is randr ;)
otaylor: gusta1: you mean the command line?
gusta1: ok, then i might try to fix the 'mouse' driver, if it's simple
gusta1: otaylor: i mean randr.. don't care if it's xrandr, grandr or any other [a-z]randr... but randr is one of the few things that works well in X (i.e. you don't need to hack that ugly xorg.conf)
gusta1: if someone adds a gnome-control-center icm profile thing which speaks randr, fine... but i'm not into the source tree, so i might be wrong here, but randr is dynamic, and icm should be too (no restart-X stuff). although you'll want the icm settings stored cross-session..
otaylor: gusta1: well, yes, configuration from userspace is one of the basic principles of how things are generally set up. But what do the dialogs look like in OS X? in vista? can we do better than that? until you have some idea of that, it's hard to go further and figure out the code details
gusta1: otaylor: "Select .icm-file for this monitor:"
gusta1: that's how it works in windows, and it works great. can't be simpler.
otaylor: gusta1: hmm, I don't remember ever getting a disk with an .icm file on it with a monitor. The again I tend to tos sthe stuff that comes with monitors without great examination
otaylor: gusta1: but sure, maybe that's the right approach :-)
gusta1: i've used it since '95 ;)
agd5f: gusta1: http://cgit.freedesktop.org/xorg/lib/libXrandr/ the xrandr lib
agd5f: http://cgit.freedesktop.org/xorg/proto/randrproto/ the xrandr protocol
otaylor: gusta1: I'd encourage you to see what's on the wiki for color management, and create a page describing basically what you see needs doing, then get some feedback from keithp
airlied: there was discussio on xorg list recently.
gusta1: otaylor: sounds fair
gusta1: airlied: sounds interesting
gusta1: after color profiling all I need is for my 5 button microsoft mouse (extremely common) to automatically enable the side-buttons... now I have to write some junk in xorg.conf (so much for zero config ;)...
gusta1: but i'll begin with trying to get xcalib to work per-monitor
agd5f: gusta1: I'm guessing you want XRRSetCrtcGamma() and friends
gusta1: i'll need to study color profiling much more... i think there's more than gamma to icm profiles, and if so... jee.
gusta1: but thanks for the function
agd5f: gusta1: it basically just manipulates the crtc LUTs
agd5f: we call it gamma, but it's really just LUT access
dmb:
eboettcher: agd5f: ty for the responses this morning :)
dmb: that could change, if/when adobe has a version of photoshop or illustrator for linux
agd5f: eboettcher: np :)
dmb: and there is a good chance that will happen, i won't say anymore
agd5f: they used to have framemaker on linux
agd5f: and photoshop for irix and solaris
dmb: agd5f: and in the future, photoshop for linux :D
eboettcher: dmb: if Adobe changes their license I may look into it :P
eboettcher: but I think that's highly unlikely
dmb: i don't think there is going to be any license changes, but there will be a port
dmb: the only question is when
eboettcher: if someone would make a more photoshop-looking default config for gimp...
dmb: eboettcher: there is gimpshop
dmb: i personally like the gimp ui though, but then again, i'm a big gtk fan
eboettcher: I'm aware but the people I've tried getting to convert only touch gimp
eboettcher: and since they use photoshop, they don't like it :/
eboettcher: I personally don't get attached to a UI -- I expect it to change
eboettcher: that said, those using default settings in gimp or photoshop are probably not doing professional work :)
dmb: yes
dmb: people think gimp is shit because of its ui
gusta1: gimp IS shit because of its ui. other than that, it's rather Ok
dmb: i like the ui, and i'm open to change
gusta1: still far far from photoshop
dmb: the ui is a reference implementation to the gtk gui standards :P
gusta1: people hate it enough to present their own thoughts: gimp-brainstorm.blogspot.com for instance.
gusta1: however, I lack some fundamental features in gimp, rather than a new UI...
agd5f: what I hate is MDI
dmb: agd5f: i have to agree
dmb: i can't stand mdi's
gusta1: i come from Windows, so MDI is great I think.. one program, one big window...
dmb: theres no point to it
gusta1: gimp to me, is as crazy as firefox having one toolbar(back+forward+url-bar) window. one window for each "tab" etc..
agd5f: and microsoft office is the worst offender. newer versions of word is not MDI, all the other apps are
gusta1: that's the point.
dmb: gusta1: firefox is not a mdi
gusta1: firefox is close to mdi compared to gimp
dmb: i like this: http://bp1.blogger.com/_wmx3OgdATU0/SBjnoW6yxRI/AAAAAAAAAhU/MT-qM-1GoRY/s1600-h/Gimpcapture2.jpeg
agd5f: but still each MDI window gets a separate space on the task bar
dmb: no mdi, but a way to have a certain configuration on the screen
gusta1: the thing is; there's a reason to join program functionality into a small set (ideally 1) of windows... having a gazillion of windows is just bad design.
dmb: well, you could also argue the concept of tabs is simular to MDI
gusta1: it is
agd5f: with one head maybe, but on multple monitors it's painful
gusta1: it's almost the same
dmb: agd5f: thats what makes me like gimp
gusta1: i've had two dual-head for many years ;)
dmb: those of us that have 2 or 3 monitors
dmb: keep the tools on one screen, the image on another, and some more tools on the other
dmb: and eventually X will support multiple pointers which will make that even better
gusta1: oh, so you want to run a formula 1 race with the mouse cursor across 3000 pixels to change tool? that's hardly great... i almost never split a program/functionalty over my two monitors...
eboettcher: two pointers :)
dmb: gusta1: thats what multiple pointers will fix
gusta1: two mice?
gusta1: omfg, i can't imagine using a mouse with my left hand..
dmb: not even that, provide some interface to switch which monitor the pointer is on
MAD|class: airlied: Morning.
gusta1: and before MPX, please someone fix so that a common multi-BUTTON mouse works out-of-the-box...
gusta1: multi-button mouse and color profiling should come far before MPX and compiz in my opinion ;)
MAD|class: gusta1: Done. Multi-button mice work, out-of-the-box.
dmb: i'v had multi-button mice work out of the box
MAD|class: Most apps don't care about buttons beyond 1, 2, 3, but it's there.
dmb: MAD|class: what class are you in right now :D?
MAD|class: Also Compiz has nothing to do with color profiling.
MAD|class: dmb: Between classes. They'll never drag me back, never!
gusta1: PS CS3 has a great interface where they use a really great toolbox/toolbar/movable thing, where you quickly can grab the functionality you want... using a dozen windows (in gimp) only shows you maybe 80% features you don't use... that's not efficient.
MAD|class: But I'm not changin' my nick when I have to leave in ~20.
dmb: i just got out of my univ for the summer
MAD|class: dmb: Semester schedule?
dmb: yeh
gusta1: MAD|class: i know that compiz has nothing to do with color profiling... i was trying to make a point.
dmb: well, the thing with open source software is there is a lot of people working on things, all scattered
dmb: the popular interest is compiz right now
gusta1: and firefox doesn't see my side-buttons unless I expicitly write an InputDevice section for my mouse...
dmb: and thats why companies are forced to worry about it
dmb: gusta1: what distro?
gusta1: forced?
gusta1: debian sid here
dmb: gusta1: companies do what the consumer want them to do
dmb: the consumer wants compiz
MostAwesomeDude: gusta1: 'k.
dmb: the businesses want stability
MostAwesomeDude: gusta1: I'm not paid here. I'm workin' on this driver because I wanted r5xx 3D support.
gusta1: I'd really like to know how to get firefox to use side-buttons without explicit InputDevice
dmb: one of the nice things about oss :D
MostAwesomeDude: So I've spent a few months reading source and learning how stuff goes.
dmb: gusta1: i have a touch pad and side scroll works
MostAwesomeDude: The (in)famous Con Kolivas is a grade-school teacher. He taught himself how to hack da kernel.
dmb: i very rarely ever use it though
gusta1: teacher? he's a medical doctor afaik
dmb: MostAwesomeDude: you have a summer break coming?
gusta1: anyway, i don't see where this is going
gusta1: please MostAwesomeDude, tell me more about multi-button mice working without an explicit section in xorg.conf
MostAwesomeDude: gusta1: Really? Perhaps I'm misinformed. The point, though, is that even though we're not feature-complete, only a small fraction of us are paid for our work. Most of us do this out of love, boredom, or desire to see a feature working.
syntropy: can someone help me with this driver?
MostAwesomeDude: syntropy: What's up?
syntropy: i've just switched from fglrx->radeon
syntropy: but it keeps forcing 800x600
dmb: gusta1: also, consider talking about this in #xorg if its not dead
syntropy: no Direct rendering either
dmb: this channel is full of mostly ati people :D
MostAwesomeDude: syntropy: Could you paste your Xorg log to a pastebin?
gusta1: dmb: yeah this is heavily OT ;)
gusta1: but MostAwesomeDude said multi-button mice works out-of-the-box.. I really want to know what i'm doing wrong. my mouse is extremely common too.
syntropy: MostAwesomeDude: Xorg.log -> http://rafb.net/p/bwoDTF13.html
MostAwesomeDude: gusta1: My synaptics touchpad and M$ mouse both work out-of-the-box here. I'm just saying that it's not impossible.
syntropy: MostAwesomeDude: xorg.conf -> http://rafb.net/p/0WavFR80.html
MostAwesomeDude: syntropy: One sec, readin' ze log.
eboettcher: gusta1: mine is
agd5f: syntropy: you need to specify the sync ranges for your monitor
syntropy: i don't have the manual, my monitor is second hand
syntropy: and it has no label
syntropy: All I know is the monitor is a Daytek that can do 1024x768 @ 60hz
MostAwesomeDude: syntropy: Okay, you've got a RS480.
agd5f: syntropy: try these: HorizSync 31.5-48.5
agd5f: VertRefresh 59-75
MostAwesomeDude: You'll get direct rendering, RENDER, and such if you upgrade your xf86-video-ati.
syntropy: ok
MostAwesomeDude: agd5f: Doesn't Mesa 7.x.x support RS480, or is it only the current git?
syntropy: those go in Subsection "Monitor" ?
agd5f: MostAwesomeDude: mesa 7.x does
agd5f: syntropy: yes
syntropy: alright, lemme check this out
syntropy: anything I should change or add before I do?
MostAwesomeDude: syntropy: Nope, the resolution and DRI stuff are two different problems. Tackle them one at a time.
syntropy: ok, brb then
agd5f: syntropy: you can bump the hsync up as well
agd5f: HorizSync 31.5-90 for example
syntropy: that worked
syntropy: thank you!
dmb: your welcome
agd5f: syntropy: np
dmb: :D
syntropy: now how can I fix direct rendering?
agd5f: syntropy: you need to upgrade your x stack
dmb: syntropy: whats glxinfo say?
syntropy: glxinfo says direct rendering off
MostAwesomeDude: syntropy: Your server's already new; I think you need to upgrade the driver.
syntropy: I upgraded Xorg and Mesa. mesa-7.03 is installed
syntropy: ok
agd5f: syntropy: you'll need latest xf86-video-ati
syntropy: the in kernel driver, or the xorg one?
agd5f: syntropy: xorg
MostAwesomeDude: syntropy: This is the userspace one for xorg.
syntropy: ok
agd5f: you may need a newer drm as well depending on what kernel you re using
MostAwesomeDude: Hey, does anybody know if git is working again? I've got stuffs to push.
agd5f: MostAwesomeDude: not yet
syntropy: 2.6.24-zen5
syntropy: i think it's new enough
agd5f: syntropy: probably
syntropy: YAY
syntropy: no more screen corruption w/ this driver!
syntropy: fonts appear properly!
MostAwesomeDude: Nice.
MostAwesomeDude: agd5f: Did you see my SCS rant earlier?
syntropy: any optimizations you would reccommend for my xorg.conf? http://rafb.net/p/0WavFR80.html
MostAwesomeDude: syntropy: I'm trying to remember whether or not you would have accelerated EXA.
MostAwesomeDude: I think so.
syntropy: I've got it set to XXA, should it be EXA instead?
MostAwesomeDude: Mm, try it and see how it feels.
agd5f: syntropy: don't need agpmode. doesn't do anythign on your chip
dmb: does hw acceleration really make that much of a difference?
syntropy: agd5f: okay, i'll nuke that line
agd5f: MostAwesomeDude: yeah. no idea off hand
MostAwesomeDude: dmb: In general, EXA is faster than XAA, and if you have Damage and/or Composite enabled, it's way faster.
otaylor: dmb: acceleration is a good thing, but if things go wrong (partial acceleration) it can make things a lot worse
dmb: what exactly does exa and xaa acceleration do to make it speed us as opposed to not using it?
otaylor: dmb: the real advantage of acceleration is when you are using a compositing manager and it allows you to just keep things in video memory
syntropy: ok, i'm restarting X now
otaylor: dmb: xaa you don't want accelerating anything ... the right xaa configuration is XAANoOffscreenPixmaps ... keep stuff in system memory, use software fallbacks
dmb: oh
otaylor: dmb: but when acceleratoin is working properly, you are using the gpu (mega-honking-fast) and working in video memory, rather than using the cpu (not so fast at graphics) and working in system memory
agd5f: xaa has a lot of other limitations
dmb: oh
otaylor: dmb: the most expensive thing is shipping stuff between system memory and video memory and much more so: shipping stuff from video memory to system memory
otaylor: dmb: which is why partial acceleration can be worse than no acceleration
dmb: yeh, i can see why
agd5f: like no method for pixmap migration, limited vram accessibility, fixed offsets, etc.
syntropy: bad news
syntropy: i upgraded xf86-video-ati, and now i get direct rendering, at 640x480
syntropy: :|
leio: so, it would be nice if EXA would actually not be a decelerator.
agd5f: syntropy: xorg log?
MostAwesomeDude: syntropy: ( ~~)
otaylor: leio: I think it's pretty good for ati these days
airlied: leio: its a lot faster now on ATI..
syntropy: http://rafb.net/p/RiyNVD18.html
leio: airlied: xorg-server-1.5?
leio: server-1.5-branch*
MostAwesomeDude: airlied: You're here!
agd5f: syntropy: xrandr --output VGA-0 --mode 1024x768
airlied: leio: no master.
leio: airlied: that means EXA will be fast in some 9 months for the general population
airlied: MostAwesomeDude: just sat down... bah I want my git..
syntropy: that worked...
MostAwesomeDude: airlied: Ditto. Have all kinds of FP goodies.
airlied: leio: yes you might have noticed we don't turn it on by default.
leio: (and it's not that fast here, but yes, much better than 1.5 branch)
airlied: leio: we neverf said it was fast yet..
airlied: leio: we said it had the potential to be fast, users who enable shit themselves, well nothing we can do.
MostAwesomeDude: I'm still pondering fast ways to do LIT, etc.
MostAwesomeDude: I'm ticked at SCS, though.
syntropy: agd5f, how can I get it to select this mode by default
syntropy: ?
airlied: MostAwesomeDude: wierd that SCS hangs stuff.. but since multi-texture does as well I suspect some bugs elsewhere.
MostAwesomeDude: airlied: Nevermind, just realized what I might be doing wrong.
leio: XAA performance and drawing correctness has degraded over time without anyone paying attention, and EXA isn't there yet. Or that's just the joke that is CFS, just everything is going worse here until that glorious day stuff gets ready :)
agd5f: syntropy: add Option "PreferredMode" "1024x768" to your monitor section. you can remove the sync ranges now too
syntropy: ok
airlied: XAA shouldn't have gone backwards, I think newer cards/cpus have shown its weakenesses.
airlied: XAA was fine ona 1024x768 monitor..
airlied: it however didn't scale up very well at accelerating anything.
leio: I can't measure XAA performance with linux process scheduler being so awful these days, but rendering correctness I can see
dmb: lol
agd5f: shadow is faster on newer cards since there's plenty of BW available now
leio: http://dev.gentoo.org/~leio/xorg/xf86-video-ati-XAA-rendering.png
airlied: leio: is there rendering bugs in a released X server?
leio: http://dev.gentoo.org/~leio/xorg/xf86-video-ati-XAA-font-rendering.png
dmb: can shadowfb work with dri?
syntropy: okay that seems to work now! this is great! now once ath5k gets up and working with my w/s card i'll be completely FOSS
airlied: leio: ajax fixes those.. not sure where though.
airlied: dmb: no.
leio: I don't know, would need to check; running git from 10th May to have some bearable EXA :)
leio: airlied: ok, cool, I'll check it out to be sure
syntropy: thank you agd5f
leio: (at some point in the weekend)
agd5f: syntropy: np
airlied: leio: they were fixed a week ago in 1.5 at least..
syntropy: keep workin on these drivers, if I have any sugegstions or such i'll be sure to visit later, thanks!
airlied: leio: and master I think as well.
dmb: he didn't say please
leio: probably didn't turn on and test XAA after last update on that date
leio: anyways, I know all this, but backlog was saying stuff like "In general EXA is faster than XAA"
airlied: leio: if you are running all the bits from master.
airlied: granted on r500 etc you sorta need EXA for Xv and rotate etc.
airlied: so it mgiht be slower but shit works..
leio: also some drivers only have EXA, no XAA
leio: but that's not one this channel concerns itself with
leio: I have a r200 btw, so I'm not affected by all these r300 fixes that have been going on. Now I'll stop speculating and see how things are in up to date git soon
MostAwesomeDude: Time to test out new SCS code. Be right back?
MostAwesomeDude: Huh.
MostAwesomeDude: Well, it doesn't die. Yay?
agd5f: airlied, MostAwesomeDude: we need to set R500_VAP_INDEX_OFFSET by default
agd5f: in the mesa code
agd5f: set it to zero for now
agd5f: default state is undefined
agd5f: that may be part of the issue with non-exa
MostAwesomeDude: agd5f: Hmm. Zat iz verry interestink.
airlied: agd5f: any ideas on the texturing btw?
airlied: agd5f: I patched my tree last night to default the rasteriser regs to the same asd fglrx does to no great effect.
airlied: agd5f: I'm wondering do we have an atom ordering issue.
agd5f: airlied: not sure, I haven't had a chance to play with texturing much. sounds feasible though
airlied: wierdly I can get some apps to draw when I run with all the debugging on ..
airlied: so it could also be a flush or wait missing.
eboettcher: O.O
eboettcher: irq 18 count not increasing
eboettcher: load average off the scales
eboettcher: and right now I wait for the debugger to load... this may be a while
syntropy: i've noticed a funny issue
syntropy: with the radeon driver as opposed to the fglrx, i need to set gamma much higher (1.8) in order to see things, and the colors on the screen have chaned tone slightly
syntropy: are these known issues?
airlied: syntropy: what card what type of monitor?
syntropy: Daytek DT-1536D
syntropy: but this isn't an issue under fglrx
airlied: syntropy: sorry DVI or VGA?
syntropy: VGA
airlied: syntropy: and what is the radeon card?
syntropy: ATI Radeon Xpress 200M IGP
airlied: hehe.. rs480...
airlied: we seem to have some problems with those cards and setting up the DAC.
airlied: I've heard other reports from IGP chips about darkness on the consolse
syntropy: oh...
syntropy: yeah
airlied: syntropy: maybe you could open a bug with the logs, I think I might need to find some more hw though :(
syntropy: well it's not /that/ big an issue
syntropy: i can work fine with it
syntropy: radeon means I can use radeonfb as my fb driver right? or should i stick with uvesafb?
airlied: hmm I normally stick with text mode ;)
airlied: but in theory uvesafb might be better. radeonfb messes with X sometimes.
syntropy: ah
eboettcher: debugger can't attach
eboettcher: I have a way-dead xorg, but I can't find out where or why it died...
eboettcher: grr and I'm failing to reproduce the crash
dmb: airlied: radeonfb doesn't work with r5xx and up i think
dmb: uvesafb doesn't work with the dri radeon driver
syntropy: does radeon support 3d if the program that needs it is in a 32bit chroot?
airlied: syntropy: should do if it can access the dri devi e
airlied: device
syntropy: see my issue is that I do game development in a 32 bit chroot
syntropy: glxgears in the chroot works perfectly
syntropy: but in game i get screen corruption and 7 fps
airlied: it might be getting indirect rendering.. does glxinfo say
airlied: direct rendering is on
syntropy: glxinfo says it is direct
airlied: there could be bugs in the conversion layer not sure how well tested it is on x86.
syntropy: :\
airlied: but ppc uses it a lot..
airlied: and really gears should probably screw up also..
syntropy: glxgears gets 205fps
dmb: thats slow
dmb: thats like software rendering speed
syntropy: ...
syntropy: glxgears is fullscreen
syntropy: i'm in fluxbox
syntropy: i'm trying it all in a 64bit env
syntropy: nope
syntropy: Q3 && radeon == fail
airlied: syntropy: yoo might try disable_lowimpact_fallbacks=true
airlied: though I'm not sure if q3 hits those
syntropy: err... that's a cvar in-game?
syntropy: i haven't seen it before
airlied: syntropy: nope env var for r300 driver
syntropy: export disable_lowimpact_fallback=true
syntropy: ?
syntropy: or capital letters?
airlied: nope like that
syntropy: no difference whatsoever
syntropy: :(
airlied: syntropy: bummer, maybe r300 + q3 sucks badly, I did notice openarena was a bit crap the other night
syntropy: well this is a problem
syntropy: the screen corruption is insane, but only for the 3d part, not the 2d
syntropy: I can pull down the console in game, and that is fine
syntropy: but the viewport rendering is garbled
eboettcher: airlied: I get over 140fps in q3 on r300
eboettcher: using ioquake3 that is :)
syntropy: well wtf
dmb: syntropy: sorry, you just fail at life :P:D:D:D
airlied: eboettcher: you using latest mesa? or 7.0.3?
eboettcher: 7.1
syntropy: err...
syntropy: i'm using 7.03
eboettcher: I was doing that with 7.03
dmb: syntropy: j/k if you were taking me seriously
syntropy: eboettcher. you had screen corruption with 7.03?
syntropy: is there an ebuild for 7.1 i wonder...
eboettcher: not that I can recall
eboettcher: syntropy: layman -a x11
eboettcher: emerge mesa-9999
eboettcher: it will brin more issues than you want :)
syntropy: 9999 will?
syntropy: :(
syntropy: I just want to play my ioQ3
syntropy: anyone?
syntropy: :(
syntropy: apparently git fixes this, so i'm taking the plunge
eboettcher: airlied: I never had screen coruption before either (way back)
eboettcher: just the reflections didn't work, no fog, and a bunch of other stuff back then
syntropy: what issues do I have if i upgrade?
eboettcher: you'll be using untested software
eboettcher: and have to pull in a bunch of other untested software to meet the deps
syntropy: yeah libdrm-9999 and dri2proto-9999
syntropy: anything else?
syntropy: any /major/ known issues
eboettcher: the xorg drivers and xserver
eboettcher: a few things like cario-9999 may get pulled in as well
syntropy: oh dear god
syntropy: maybe i'll just go back to fglrx
eboettcher: syntropy: what does quake3 say on the console?
syntropy: nothing at all, other than the regular stuff
syntropy: hold on....it was using libGL.so.1
syntropy: when i manually forced it to libGL.so
syntropy: it said:
syntropy: ATTENTION: default value of disable_lowimpact_fallback overridden by environment
syntropy: Warning, xpress200 detected
syntropy: it didn't do that before
eboettcher: OH
eboettcher: RS400
eboettcher: or 480
eboettcher: that changes things :P
syntropy: hm?
syntropy: still have screen corruption
syntropy: *cries*
syntropy: eboettcher, do you know what is wrong?
eboettcher: nope, I have yet to try out the rs400
airlied: if you have a real r300, you can do R300_NO_TCL=1 with latest mesa.
airlied: and it'll act like an rs480/690
syntropy: http://airlied.livejournal.com/59351.html
syntropy: mesa-7.04 should fix this....