[05:22] <LLStarks> sarvatt, is sna enabled on edgers? i want to get some benchmarks.
[05:23] <hyperair> LLStarks: there's ppa:sarvatt/intel-sna
[05:23] <hyperair> LLStarks: however, the patch required in X itself is missing.
[05:23] <hyperair> so it segfaults nicely
[05:24] <LLStarks> ah
[05:24] <Sarvatt> it doesn't segfault because the x patch is missing, that just fixes rendering corruption.. :)
[05:24] <hyperair> Sarvatt: i got a segfault!
[05:25] <LLStarks> will sna ship with oneiric and is it comparable to exa, uxa, etc?
[05:25] <Sarvatt> no it wont
[05:25] <hyperair> =(
[05:25] <Sarvatt> it's dependent on the xserver 1.12 video abi
[05:26] <LLStarks> that's alright, we're setting up for PP during the oneiric cycle
[05:27] <LLStarks> will there be any hiccups similar to the gem/uxa transition? that was harsh.
[05:27] <Sarvatt> pretty much 100% guaranteed there will be :)
[05:28] <LLStarks> ouch
[05:28] <Sarvatt> sorry I didn't update it today, will update it to the latest in the morning
[05:29] <LLStarks> so, is the sna ppa (now or tomorrow) ready for vm or live testing in the sense that the desktop is usable?
[05:29] <LLStarks> *live as in actual install runing on actual hardware
[05:29] <Sarvatt> sure if you want to test it, just avoid chrome/chromium because they dont work
[05:30] <LLStarks> any benchmarks you'd recommend for showing maximum benefits?
[05:30] <Sarvatt> that ppa hyperair linked needs to be activated at the same time as xorg-edgers
[05:32] <LLStarks> if at all possible, i'd like to get a hardware table up and running on the wiki. vga string, commit id, benchmark date, results.
[05:33] <Sarvatt> i dont think it's anywhere near ready for something like that, it's going to be very volatile for some time yet..
[05:33] <hyperair> LLStarks: 8086:2a32 -> segfault.
[05:34] <LLStarks> can you boot to recovery terminal?
[05:34] <hyperair> LLStarks: ?
[05:35] <hyperair> recovery terminal? 
[05:36] <LLStarks> tty
[05:36] <hyperair> well i can switch to ttys yeah
[05:36] <LLStarks> then that's not so bad.
[05:36] <hyperair> in fact, that's how i repaired my X.
[05:36] <hyperair> mm yeah it's just a normal X segfault
[05:36] <hyperair> it's not a wedge
[05:36] <LLStarks> ah ok
[05:36] <hyperair> i should probably get a proper stack trace 
[05:36] <Sarvatt> hyperair: http://dpaste.com/551239/ look like that?
[05:36] <hyperair> Sarvatt: not quite
[05:36] <hyperair> Sarvatt: it had a few intel_drv.so lines in the middle
[05:36] <hyperair> and i lost the log. blargh.
[05:37] <LLStarks> praying that 8086:27a2 works
[05:45] <LLStarks> taking the sna plunge. i hope my body can take it.
[05:47] <LLStarks> the laptop loves it. whenever i test something new it's like "awww, you're still thinking of me. sure, i'll give you some more performance. windows stopped driver updates for me years ago."
[05:48]  * LLStarks crosses fingers
[05:52] <LLStarks> holy hell
[05:52] <LLStarks> http://ie.microsoft.com/testdrive/performance/fishietank/
[05:52] <LLStarks> 2 fps to 40 fps
[05:53] <LLStarks> can i send a cake to intel?
[05:53] <LLStarks> let's see if it handles 720p gl output
[05:55] <LLStarks> ...it didn't choke
[05:55] <LLStarks> this is amazing.
[05:57] <LLStarks> smooth 1080p. yup.
[05:57] <LLStarks> it's almost as if the i945gm no longer needs vaapi
[06:06] <LLStarks> hyperair, no segfaults yet. just the occasional artifact.
[06:06] <LLStarks> very rare.
[06:07] <LLStarks> i'm going to be brave and try chromium
[06:07] <LLStarks> all seems fine
[06:09] <tjaalton> bryceh: forgot to push xkeyboard-config changes?
[06:15] <LLStarks> sarvatt, i've noticed that gl subtitle rendering (is broken on edgers. what component should i file against upstream?
[06:16] <LLStarks> and has been for a while
[06:33] <tjaalton> RAOF: moo, you haven't pushed the earlier xkeyboard-config merge to git?-)
[06:34] <RAOF> Wait, what?
[06:34] <RAOF> Let me just get that!
[06:34] <tjaalton> 2.2.1-1u1
[06:34] <tjaalton> maybe we should get 2.3.1 for oneiric?
[06:35] <tjaalton> debian didn't put it in unstable yet because they still have gnome2 there and there's some conflict
[06:35] <RAOF> I don't know of any reason no to grab that.
[06:35] <tjaalton> but we already have gnome3 for the most part
[06:35] <tjaalton> in oneiric
[06:36] <RAOF> Was the conflict just the naming scheme bits, or something more fundamental?
[06:36] <tjaalton> don't remember the details
[06:37] <RAOF> Pushed like a jimmyhack.
[06:37] <tjaalton> 2.1 is "the best for gnome2", nothing more than that
[06:37] <tjaalton> and we already have 2.2.1 :)
[06:37] <tjaalton> so yes, should be no blockers for 2.3.x
[06:38] <tjaalton> s/yes/no/
[06:38] <RAOF> Right.  I'm pretty sure that refers to the naming stuff.
[06:39] <tjaalton> the dvorak-stuff?
[06:40] <RAOF> No - renaming all the profiles $COUNTRY ($MAP) to $LANGUAGE ($MAP).
[06:40] <tjaalton> as
[06:40] <tjaalton> ah
[06:40] <RAOF> So the keyboard indicator here says “English (Dvorak)” rather than “USA (Dvorak)”.  Etc.
[06:40] <tjaalton> heh, makes sense
[06:42] <RAOF> While that was done for GNOME 3, I'm not sure why it's not regarded as appropriate for GNOME 2.
[06:47] <RAOF> Mmm. Looks like this system's borken enough to no longer boot.
[06:47] <tjaalton> i should work through installing the sandybrigde system.. finally switching to ssd et al
[06:48] <RAOF> Maybe I should stop holding out for ivybridge and build a decent desktop system.
[06:53] <LLStarks> wait for ivy bridge
[06:53] <LLStarks> :3
[06:54] <LLStarks> tr-gate. better than sandy bridge.
[06:54] <LLStarks> sole purpose is to embarrass amd for the next year or so
[06:54] <tjaalton> and ~8 months away
[06:54] <RAOF> Right.  There's *always* something cool ~8 months away.
[06:54] <LLStarks> sandy bridge + x58 is surefine
[06:55] <tjaalton> x58? that's old
[06:55] <LLStarks> wait. did i mess up the chipset?
[06:56] <LLStarks> z68
[06:57] <RAOF> “After this operation, 258 MB disk space will be freed.”  Hm.  That seems rather a lot.  Oh, wait, it's removing xserver-xorg-core and ubuntu-desktop.
[06:57] <tjaalton> RAOF: heh, which update?
[06:58] <RAOF> Multiarch'd mesa.
[06:58] <tjaalton> ah, because there's no xserver update to go with it?
[06:58] <RAOF> Right.
[06:59] <RAOF> Also because llvm's not multiarched, so all the i386 drivers are baroque.
[07:26] <LLStarks> if it ain't baroque, don't fix it
[07:27] <RAOF> Actually, that's not quite true.  All the i386 gallium drivers are broke.  i965_dri is perfectly happy to run i386 glxinfo and glxgears.  Score.
[08:01] <LLStarks> can sna be done with stable mesa?
[08:03] <RAOF> AFAIK sna is largely independent of mesa.  You're very much not allowed to make backward-incompatible DRI2 changes :)
[08:06] <LLStarks> well, i was wondering if i could test it without a full edgers payload
[08:07] <RAOF> Probably, but you get to keep all the pieces.
[08:07] <LLStarks> eh?
[08:07] <RAOF> “If it breaks, you get to keep the pieces”
[08:08] <hyperair> LLStarks: no fair!
[08:08] <hyperair> LLStarks: 32-bit or 64-bit?
[08:08] <LLStarks> 32-bit
[08:08] <hyperair> maybe it hates 64-bit.
[08:08] <LLStarks> not that i have a choice
[08:08] <hyperair> heh
[08:09] <RAOF> Oh, atom?
[08:09] <RAOF> That was frequently paired with an i945.
[08:09] <LLStarks> core duo.
[08:09] <hyperair> core duo? those support 64-bit, no?
[08:09] <RAOF> No, the core duo *2* supports 64-bit :)
[08:09] <hyperair> model name      : Intel(R) Core(TM)2 Duo CPU     T5750  @ 2.00GHz
[08:10] <hyperair> core 2 duo.
[08:10] <LLStarks> t2050
[08:10] <LLStarks> still more powerful than an atom
[08:10] <LLStarks> despite being 5 years old
[08:10]  * hyperair wants a sandy bridge.
[08:10]  * RAOF is fairly sure anything 686-derived is faster than an atom.
[08:10] <hyperair> lol
[08:10] <LLStarks> atom is 686
[08:11] <LLStarks> p3 architechture
[08:11] <RAOF> No, it's not.  It's an in-order processor.  Which is why performance sucks.
[08:11] <LLStarks> really?
[08:11]  * RAOF is pretty sure.
[08:11] <LLStarks> you're right
[08:12] <LLStarks> not p6
[09:47] <RAOF> Why must the mesa build system be constructed entirely of hate?
[09:59] <tjaalton> heh
[10:06] <RAOF> Hm, (a) has this worked, and (b) how small are the gallium drivers now?
[10:31] <RAOF> Win! 3.6M 2011-06-07 15:12 r300_dri.so → 1.3M 2011-06-07 19:29 r300_dri.so, 3.5M 2011-06-07 15:12 r600_dri.so → 843K 2011-06-07 19:29 r600_dri.so
[10:31] <tjaalton> woohoo
[10:32] <tjaalton> so a shared gallium core?
[10:32] <RAOF> Yeah.
[10:32] <tjaalton> nice
[10:33] <RAOF> With only the *tiny* problem of 19M 2011-05-27 19:49 /usr/lib/libLLVM-2.9.so.1
[10:36] <tjaalton> hehe
[11:57] <Prf_Jakob> Has anybody tried Unity on a git master gallium driver?
[12:03] <RAOF> Probably some of our intrepid xorg-edgers cadets have?
[12:04] <tjaalton> probably yeah
[12:04] <tjaalton> i've only tried swrastg but with 7.10, which lacks tfp support
[12:04] <RAOF> I happen to have a nice hot ccache here; want me to try?
[12:04] <tjaalton> you've pulled a snapshot too?
[12:04] <RAOF> (And a radeon 5450ish)
[12:05] <RAOF> tjaalton: Mesa build hacking always gets done on master :)
[12:05] <RAOF> It's not sufficiently fun to do twice :)
[12:05] <tjaalton> RAOF: naturally, but is it ending up in oneiric soon?-)
[12:06] <Prf_Jakob> RAOF: no real need I jast wanted to know if there was a known problem with Unity on gallium, I'm guessing the problem is in our driver.
[12:06] <Prf_Jakob> Unity works pretty well with vmwgfx except a rendering bug.
[12:06] <RAOF> Cool.
[12:07] <RAOF> tjaalton: It'll end up in oneiric soon; I just need to finish off the llvm 2.9 mir, which is blocked on actually being able to build openjdk-6b18 on an arm system to check the testsuite.
[12:09] <ScottK> What mesa is planned for oneiric?
[12:09] <RAOF> 7.11
[12:09] <ScottK> Sigh.
[12:09] <RAOF> Problem for KDE?
[12:10] <ScottK> Mgraesslin just mentioned on one of the KDE lists he'd done 4.7 to work with 7.10.
[12:10] <ScottK> Then mentioned if someone was going to use 7.11 with KDE 4.7 they better test it.
[12:11] <ScottK> So not necessarily a problem, but a combination with undefined results at this point.
[12:11] <RAOF> Ah, right.  Well, xorg-edgers contains 7.11 snapshots, but we won't be switching until 7.11 gets branched.
[12:13] <RAOF> Oh!  At what point did libGL start to fallback on swrastg_dri?
[12:20] <tjaalton> aiui Sarvatt right, it would be 7.11?
[12:20] <tjaalton> uh
[12:20] <tjaalton> "iirc what Sarvatt said,..."
[12:22] <ScottK> RAOF: We didn't get 4.7 beta 1 packaged yet either.
[12:23] <RAOF> Fun multiarch fact: dpkg --remove mesa-utils won't remove the i386 mesa-utils package; you need dpkg --remove mesa-utils:i386
[12:25] <RAOF> Wow.  glxgears is curiously messed up.
[13:24] <jussi> Hrm, Im having an issue where I have the laptop setup with the external screen, and only the external screen in use. However, when powermanagement turns the screen off after a period of inactivity, it doesnt come up again when you become active. the machine seems fine and reponsive, but no screen. 
[13:35] <tjaalton> jussi: best bet is to try the mainline .39 kernel
[13:36] <jussi> tjaalton: how would I go about getting that ? is it relatively stable? 
[13:37] <tjaalton> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.39.1-oneiric/
[13:37] <tjaalton> certainly stable enough to test that
[13:40] <jussi> tjaalton: right, however, this machine is on natty
[13:41] <tjaalton> sure
[13:41] <tjaalton> just install the deb :)
[13:41] <jussi> ok :) 
[13:41] <tjaalton> it doesn't matter if it's built on oneiric tools
[13:41] <tjaalton> *with
[13:42] <tjaalton> at least, it shouldn't matter much, and hasn't for the usecases I've had
[13:42] <jussi> ok, was just unsure. Ill let you know how it goes :)
[13:42] <tjaalton> good
[13:42] <tjaalton> which system did you have?
[13:43] <jussi> is there a chance it will fix my bug also? (bug 793487)
[13:43] <ubot4> Launchpad bug 793487 in xserver-xorg-video-intel (Ubuntu) "Kubuntu does not shut down when external monitor attached through displayport (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/793487
[13:43] <jussi> Its a HP probook 5320m
[13:44] <jussi> also, do I need to install the headers? 
[13:44] <tjaalton> no need for the headers, unless you have dkms packages
[13:45] <tjaalton> ah so it's arrandale, yeah .39 might fix that bug
[13:45] <jussi> dkms packages? 
[13:45] <tjaalton> .39-rc2 has been tested to fix some bugs concerning external monitors
[13:46] <tjaalton> dynamic kernel module source, probably don't have them if it's something you don't know :)
[13:46] <tjaalton> used for binary blobs
[14:04] <jussi> tjaalton: Unfortunately the kernel did not boot. I installed hte headers also, but still no boot. I pressed esc to see the progress, and it seems to stop after apparmor 
[14:05] <tjaalton> jussi: dang
[14:06] <jussi> tjaalton: Im more than happy to try anything else you ahve to offer though. :) (or try troubleshoot the kernel)
[14:06] <tjaalton> you could try this one, in case the point release broke something http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.39-oneiric/
[14:07] <tjaalton> at least one person booted that succesfully on natty
[14:09]  * jussi tries
[14:22] <jussi> tjaalton: unfortunately no go on that either. it gets a little further, but then dies
[14:22] <tjaalton> meh
[14:23] <tjaalton> you could try rc4 from the parent dir next, it's also built on natty if it makes a difference after all..
[14:28] <tseliot> tjaalton: the blobs won't work with the new kernel as we prevent the module from building against unsupported kernels
[14:29] <tjaalton> tseliot: right, but is it already in natty too?
[14:29] <tseliot> tjaalton: yep
[14:29] <tjaalton> nice
[14:29] <tseliot> :)
[14:29] <jussi> hrm, theres also this in the install proceedure:  W: Possible missing firmware /lib/firmware/rtl_nic/rtl8105e-1.fw for module r8169
[14:29] <tjaalton> well, i was just pointing out when the headers would be useful
[14:29] <tjaalton> jussi: that shouldn't matter
[14:30] <jussi> ok, just thought to mention it
[14:30] <tjaalton> some new nic module i guess
[14:32] <jussi> right, reboot time. hope this works.
[14:34] <jussi> right then. (it boots :D ) now let me shut down and see if it fixes that bug, Ill try the initial bug I mentioned in a min. 
[14:35] <tjaalton> phew, great
[14:40] <jussi> right, so that bug I mentioned before (793487) is fixed with this kernel. 
[14:40] <tjaalton> niice
[14:41] <jussi> kde seems a little slow, not sure whats going on.
[14:41] <jussi> just seems. 
[14:42] <jussi> anywya, Ill go away for a bit, and see if the other bug still persists
[14:42] <tjaalton> ok
[14:42] <jussi> (and if someone wants to build the newer .1 kernel for natty, I would be happy to try that.)
[14:44] <tjaalton> the hwe team has a set of patches that'll hopefully get added to the natty kernel, even though there will be no upstream point-releases anymore for .38
[14:44] <jussi> Im also getting a few artifacts left on the screen. 
[14:44] <tjaalton> looks like it would fix a bunch of issues
[14:44] <tjaalton> ah
[14:45] <tjaalton> well, it has around 90 commits, of which maybe 8 are needed
[14:45] <tjaalton> rc4 that is, to the drm/i915 code
[14:45] <jussi> not artefacts per se, but parts of highlighting etc
[15:12] <tjaalton> RAOF: pushed xserver merge with the fedora pointer-barrier patch added
[15:13] <tjaalton> now xorg merge finalized so we can start pushing these to oneiric..
[17:35] <apw> anyone seen X server dumping ?  on intel ?
[17:35] <apw> [ 25658.288] Segmentation fault at address 0x7f039ec32010
[17:35] <apw> [ 25658.288] 
[17:35] <apw> Caught signal 11 (Segmentation fault). Server aborting
[17:36] <apw> this is natty updated as of this morning
[18:16] <hyperair> apw: full stack trace?
[18:17] <apw> hyperair, at the bottom of: http://paste.ubuntu.com/621075/
[18:17] <Sarvatt> apw: one sec, let me get you the bug number
[18:18] <Sarvatt> i attached a fix to it, its x-x-i-synaptics
[18:18] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/774978 comment #25
[18:18] <ubot4> Launchpad bug 774978 in xserver-xorg-input-synaptics (Ubuntu) "xserver crashes in RecordAReply when XRecord is enabled in syndaemon (affects: 91) (dups: 22) (heat: 444)" [High,Triaged]
[18:19] <Sarvatt> it just started now though? it happened at random before but amazing you went from release till now and just started hitting it
[18:20] <apw> yeah first time i've ever seen it
[18:20] <apw> i right clicked somewhere and boom
[18:20] <apw> oh ... of course i don't use my touchpad most of the time on this machine as i have external keybaord an mouse
[18:21] <apw> and i was using the touchpad unusually ... so
[18:35] <hyperair> weird, i've been using my touchpad though
[18:35] <hyperair> why would a touchpad cause intel_drv.so to segfault?
[18:35] <hyperair> i see that in the stack trace somewhere
[18:57] <LLStarks> hyperair, i've seen it happen in israel due to voltage differences
[18:57] <hyperair> Sarvatt: IT WORKS.
[18:57] <LLStarks> my xserver choked whenever i used the touchpad
[18:58] <hyperair> LLStarks: ah, right voltage differences.
[18:58] <hyperair> well my xserver never choked due to the touchpad
[18:58] <hyperair> but the touchpad itself choked.
[18:59] <LLStarks> btw, all of my observed improvements that i attributed to SNA yesterday were all from the new ddx/mesa/drm WITHOUT SNA
[18:59] <LLStarks> i don't get it
[19:00] <LLStarks> what's crippling the stable stack so much?
[19:00] <tjaalton> Sarvatt: time to sru -synaptics?
[19:01] <LLStarks> synaptics needs tapbutton2=2
[19:01] <LLStarks> for two-finger middle click
[19:01] <LLStarks> right now, it's tapbutton2=3
[19:02] <LLStarks> that and out-of-the box two-finger scrolling
[19:17]  * hyperair doesn't observe any improvements to SNA though..
[19:22] <LLStarks> intel ddx is overrated
[19:23] <LLStarks> i have no idea what's going on between oneiric's 2.15 and the non-SNA git, but something is slowing me down
[19:24] <LLStarks> it can't be mesa. this is 2d stuff.
[19:26] <LLStarks> i wish i could source this slowdown, but xorg log is clean
[19:37] <LLStarks> can i run -intel master on a stable oneiric stack?
[19:40] <hyperair> hmm i wonder why 3d activity causes my entire computer to freeze for short periods of time
[19:40] <hyperair> enough to miss a number of interrupts for psmouse
[19:40] <hyperair> and enuogh to screw over eth0 transmission
[19:41] <hyperair> and enough to make iwl4965 trigger a hardware reset
[19:41] <LLStarks> x is just weird
[19:42] <hyperair> heh
[19:42] <hyperair> i think it's more like i915 is doing too much processing in the irq
[19:45] <LLStarks> i945gm slowdown with the 2.15 ddx confirmed.
[19:45] <LLStarks> 2.15git is fine.
[19:46] <LLStarks> there's like zero acceleration in the former
[19:47] <LLStarks> and this is without SNA
[19:47] <LLStarks> time for some bisecting
[19:47] <LLStarks> should be fun
[19:51] <LLStarks> wait wtf... 2.15-release git is fine. did somebody screw up packaging?
[20:03] <LLStarks> nvm. i might be wrong.
[21:07] <Sarvatt> tjaalton: i dont suppose there's any chance you already did any of the mesa lucid backport? :P
[21:07] <tjaalton> Sarvatt: not sure, probably not
[21:07] <tjaalton> silly sentence
[21:08] <Sarvatt> yeah it was a long shot, gonna start throwing it together now since thats the last part
[21:23] <bjsnider> ricotz, is it possible to change the sound theme in gnome 3? it's not an option with the tweak tool
[21:44] <ricotz> bjsnider, this can be done with dconf-editor
[21:45] <ricotz> bjsnider, org/gnome/desktop/sound
[22:06] <Sarvatt> got it close, http://sarvatt.com/downloads/mesa/
[22:11] <bryceh> Sarvatt, should I go ahead and upload/sru the fix you posted on #774978?  Or is there more we need to do first?
[22:14] <Sarvatt> that'd be much appreciated
[22:38] <tjaalton> Sarvatt: would adding -lrt to LDFLAGS help there?