[00:42] <bjsnider> i've got tearing with the blob on mutter in oneiric
[00:44] <bryceh> mutter?
[00:45] <bjsnider> gnome-shell/mutter
[00:56] <RAOF> bryceh: Looks like they've got an 915G motherboard; I'm not sure why that's not showing as a VGA device, though.
[00:56] <bryceh> yeah
[01:00] <bryceh> RAOF, got word that OpenGL 3.0 is now being targeted to mesa 8.0 in feb '12
[01:01] <bryceh> checked with alex, and gl3 should benefit radeon as well, although there's some bits they have to tend to that may delay it a bit
[01:01] <bryceh> so we'll have an interesting decision to make at UDS...  stable mesa 7.12 or unstable but featureful mesa 8.0
[01:03] <bryceh> so jay's glsl shader stuff will wait until then; I chatted with him a bit about all this, he'll get back to us on how important this is for htem in the lts
[01:03] <bryceh> RAOF, intel responded well to your suggestion of better debugging stuff, and they'll look into what they might do to improve things for 7.12
[01:05] <RAOF> Sweet.
[01:06] <bryceh> I also mentioned the boot performance stuff we're working on now; they seemed interested
[01:07] <RAOF> I guess the other thing that we'd like is hybrid graphics support, but that's too huge to really be a wishlist :)
[01:08] <bryceh> yeah we'll want to be more specific
[01:08] <bryceh> next call is going to focus on feature stuff for their 2012 work; might be worth raising then. 
[01:09] <bryceh> RAOF, would you mind putting some thought into a plan of attack for what we could do for hybrid graphics support?  maybe start braindumping into a wiki page under wiki.ubuntu.com/X/
[02:07] <bryceh> (google docs to the rescue, heh)
[03:48] <RAOF> What?  Why would you install mesa 7.11 from a random PPA?  Why would you do that?!
[04:06] <tjaalton> bryceh: are they going to do both 7.12 and 8.0? I've understood that it's going to be called 8.0 if gl3 makes it, as it seems to be the case
[04:07] <tjaalton> bryceh: oh you got the doc already? :)
[04:07] <tjaalton> Sarvatt: meh
[06:38] <bryceh> tjaalton, from today's call, sort of sounded like they were of the mind it wasn't making it, and so I'm gathering there would be a .12 and an 8.0.
[06:39] <bryceh> however, the usual folks weren't on the call (worn out from XDC?) so suspect I was getting info 2nd hand
[06:40] <tjaalton> ok
[06:41] <tjaalton> I trust phoronix more! :)
[06:41] <bryceh> heh
[06:41] <tjaalton> http://www.phoronix.com/scan.php?page=news_item&px=OTkxMg
[06:42] <bryceh> then mesa 7.12 will include Steam support and be Wayland based
[06:42] <tjaalton> awesome
[06:44] <bryceh> yeah I was there for Ian's talk.  I got the impression that they were setting as a goal that they'd have gl 3 by the end of the year, but that it was a very optimistic goal
[06:44] <bryceh> whereas on the call it today they sounded like a more pragmatic conservative guess
[06:44] <tjaalton> so lets be very optimistic about it :)
[06:45] <bryceh> today?  yes guess it's still today for 15 minutes
[06:50] <RAOF> It's today for at least another 9 hours!
[06:51] <bryceh> we're running short on today here in the US
[06:52] <RAOF> Man, your economic problems never end, do they? :)
[06:54] <tjaalton> :)
[06:54] <bryceh> not until the rapture anyway
[07:27] <tjaalton> looks like airlied has been quietly doing x redesign work on his xserver repo
[07:28] <RAOF> Cool.
[07:29] <tjaalton> http://cgit.freedesktop.org/~airlied/xserver/log/?h=drvmodelv2-wip
[07:30] <tjaalton> -2/+39964 :) (the first commit)
[07:30] <RAOF> Sounds about right.
[07:33] <tjaalton> though looks like it's mostly copying stuff under drv/
[07:33] <RAOF> That looks like it's further along than I thought, actually.
[07:34] <tjaalton> was he at xdc?
[07:35] <RAOF> No.
[07:35] <bryceh> nope
[07:36] <bryceh> was surprising how few intel and redhat guys there were
[07:36] <RAOF> It would have been interesting to hear what he had to say, if he was :)
[07:36] <tjaalton> ok, so the redesign work was just briefly mentioned (judging from the phoronix notes)?
[07:37] <RAOF> Not even that, really?
[07:37] <RAOF> Oh, it might have been during the merge-the-drivers discussion.
[07:38] <tjaalton> jameys 'codebase of the future' according to phoronix
[07:39] <bryceh> mm, think that was the first talk
[07:39] <bryceh> things felt a bit chaotic that first morning
[07:39] <tjaalton> why was that? :)
[07:41] <bryceh> couple of the speakers hadn't arrived yet
[07:41] <bryceh> was kinda crazy how many people there had projector troubles
[07:41] <bryceh> I mean, at the _X_ conference
[07:41] <bryceh> lotta people didn't bother with slides anyway
[07:41] <RAOF> More troubles than at plumbers!
[07:41] <tjaalton> RAOF: btw, push xorg-server :)
[07:42] <RAOF> #$!@#
[07:43] <RAOF> poolie can't get build-from-branch working fast enough for me.
[07:43] <tjaalton> what's that?
[07:43] <RAOF> Making the process of pushing the branch to alioth and the process of submitting a source package to the archive the same thing.
[07:44] <RAOF> ie: tag the push, and Launchpad builds your package.
[07:44] <tjaalton> oh, found the proposal
[07:44] <RAOF> The finest way of ensuring I don't upload without pushing is to make pushes the way to upload :)
[07:45] <tjaalton> sounds good
[07:47] <bryceh> of course, we could just stop using git ;-) ;-)
[07:48] <tjaalton> meh :)
[07:48] <RAOF> I could still fail to push with bzr :P
[07:48] <tjaalton> and i'd fail using it outright
[07:50] <bryceh> I have to admit, I got rather confused yesterday working on -wacom to find there isn't a ubuntu branch anywhere (at least that I could find)
[07:50] <tjaalton> there isn't?
[07:50] <bryceh> tjaalton, ^ aha that's one of the things I wanted to ask you yesterday
[07:50] <tjaalton> should be
[07:50] <tjaalton> oh oh
[07:50] <bryceh> didn't find it
[07:50] <tjaalton> ther is, but it's on my personal repo
[07:50] <tjaalton> but writable by pkg-xorg
[07:51] <tjaalton> since there is no pkg-xorg repo for it
[07:51] <RAOF> Yay!  The compiz staged in the Desktop PPA has a working alt-tab switcher!
[07:51] <tjaalton> changed in which way?
[07:53] <tjaalton> bryceh: git+ssh://git.debian.org/git/users/tjaalton-guest/xf86-input-wacom.git
[07:53] <tjaalton> add bryceh-guest@ to be able to push too
[07:55] <RAOF> tjaalton: Changed in that when alt-tabbing to a group of terminals (a) he focus is returned to the last-focused window, and (b) the focused window is raised on top.
[07:55] <bryceh> tjaalton, https://bugs.launchpad.net/ubuntu/oneiric/+source/xf86-input-wacom/+bug/787781 has the patch; feel free to add if you want...  I'm waiting for someone to validate the ppa.
[07:55] <ubot4> Launchpad bug 787781 in xf86-input-wacom (Ubuntu Oneiric) (and 3 other projects) "Touch screen does not work with single finger touch, Lenovo x220 tablet (affects: 4) (heat: 28)" [High,In progress]
[07:56] <tjaalton> bryceh: ok
[07:56] <bryceh> but I'm like 99% sure it's the right fix
[07:56] <bryceh> and you know a bryce 99% certainty is like 50% likely to be correct
[07:57] <tjaalton> RAOF: ah, I switched to terminator due to bug 787465
[07:57] <ubot4> Launchpad bug 787465 in gnome-terminal (Ubuntu) "View->Show MenuBar isn't working in 11.04 (affects: 13) (dups: 4) (heat: 59)" [Low,Triaged] https://launchpad.net/bugs/787465
[07:57] <bryceh> terminator rocks
[07:58] <tjaalton> session saving could be better, though the devel version seems to have fixed some issues
[07:58] <tjaalton> current release is over a year old
[07:59] <bryceh> what more is there to add?
[07:59] <tjaalton> the issues with alt-tabbing etc forced me to use fullscreen windows, so terminator was a natural choice :)
[07:59] <tjaalton> bryceh: it doesn't save the terminal size, though it's quick to fix
[08:00] <tjaalton> i mean the sizes of the split terminals
[08:01] <tjaalton> and it could remember the fullscreen state too :)
[08:03] <bryceh> oh yes, that's certainly true
[08:09] <bryceh> tjaalton, you should plan on going to XDC next year.  it'll be in europe (Ireland or Germany) so should be an easy trip for you.
[08:11] <tjaalton> bryceh: yeah, I'll keep that in mind
[08:12] <tjaalton> only real problem is getting someone to take the kids to school/daycare :)
[08:12] <tjaalton> luckily my in-laws live quite close
[08:14] <bryceh> yeah, was a bit of a challenge for me and my wife last week, but we got it sorted (also thanks to in-laws)
[08:15] <bryceh> if it's 3 days like this time, you might be able to find a suitable flight on on Weds so it only occupies about half a week
[08:18] <tjaalton> yeah, quite doable
[10:47] <DeathWolf> hi all
[10:47] <DeathWolf> is there any hope that anyone could backport 1.10 to lucid?
[10:50] <tjaalton> DeathWolf: why?
[10:51] <DeathWolf> 1.10 brings the massive composite & xinerama improvement... and not everyone(corp envs) can afford to move to natty
[10:53] <tjaalton> don't know of any plans backporting it
[19:29] <Sarvatt> guess its too late for multiarch libpciaccess?
[19:30] <Sarvatt> tempted to shove it in x-updates at least so people can use i386 mesa on amd64 for wine and flash
[19:31] <Sarvatt> (without using all of edgers craziness)
[19:32] <bryceh> Sarvatt, yeah probably too late for oneiric
[19:32] <bryceh> Sarvatt, putting it in x-updates might not be a bad idea; how well tested is it so far?
[19:33] <Sarvatt> been using it for ~2 months now and it works fine
[19:34] <Sarvatt> its just making it multiarch so the i386 version that libgl1-mesa-dri needs is installable
[19:35] <Sarvatt> well libdrm-intel1:i386 is what really needs it
[19:35] <bryceh> Sarvatt, ok yeah sounds fine for x-updates / oneiric
[19:35] <bryceh> wouldn't put it in for x-updates / natty though
[19:36] <Sarvatt> oh yeah of course
[19:36] <Sarvatt> multiarch mesa on natty isnt *really* working even in edgers due to an apt bug that didnt get fixed in natty
[19:39] <bryceh> bbiab (food time)
[20:01] <jcristau> Sarvatt: pushed a m-a libpciaccess to debian now..
[20:05] <Sarvatt> jcristau: awesome, thanks for that! is multiarch dpkg in debian yet?
[20:06] <jcristau> no :(
[20:10] <Sarvatt> argh, i was stupid and just updated debian on my NAS to wheezy, eglibc needs 2.6.26 so it's going to be fun fixing it :( can't update the kernel on this arm box and its at 2.6.24
[20:20] <bladernr> Hi, can someone point me to where I can file bugs against mesa-utils that will be looked at and acted on?
[20:20] <bladernr> specifically, glxgears and glxheads never exit with a 0 status, they always seem to dump fatal error messages to terminal on exit...
[20:21] <jcristau> they only do that if you kill them afaict, not if you ask them nicely
[20:22] <bladernr> how do you ask them nicely?  
[20:22] <bladernr> closing them using window controls also causes this
[20:22] <bladernr> as did every signal I tried :/
[20:22] <jcristau> escape
[20:22] <bladernr> hrmmm... head -> desk
[20:24] <bladernr> so the problem is, we use this as a quick verification of 3d rendering during Ubuntu testing... and so checkbox (system testing) fires off glxgears automagically.  Typically, the user shuts the program down by closing the window (which makes perfect sense to me, hitting esc didn't occur to me)
[20:25] <bladernr> any way to shut it down without hitting escape (was hoping to make the process a little more automated and a little more user friendly)
[20:26] <bryceh> yeah
[20:27] <bryceh> wmctrl -c glxgears
[20:28] <bryceh> bladernr, see do_glx_loop in  xdiagnose/data/workloads/
[20:29] <bladernr> bryceh:  that causes a fatal IP error message
[20:31] <jcristau> you'd have to patch glxgears to listen to the event from the wm and shut down gracefully
[20:31] <jcristau> not hard, just not something anyone's bothered with so far afaik
[20:31] <bladernr> jcristau:  ugh... easier to just wrap it in some shell and ignore the exit status... at least for my purposes.  I was just looking for a cleaner way to do it
[20:33] <bladernr> bryceh:  do_glx_loop also results in a fatal IO error for every loop that completes when glxgears closes
[20:33] <bladernr> also, for the record, this is on Oneiric...
[20:34] <bryceh> bladernr, right, thought you said you wanted a way to shut it down without hitting esc
[20:34] <bladernr> ahhh... got it.  
[20:35] <bryceh> like jcristau  says, glxgears is fairly primitive
[20:36] <bladernr> out of curiosity, since mesa-utils got moved to universe, is there anything in main that you all would suggest as a basic 3d test?
[20:36] <bladernr> using glxgears isn't set in stone or anything, it's just what's been used for a while.
[20:37] <jcristau> i was going to say openarena, but that's not in main either :)
[20:38] <bryceh> unity ;-)
[20:39] <bryceh> no I don't know of any gl test code in main
[20:40] <bryceh> bladernr, really I would suggest looking at piglit (which isn't packaged yet, have to pull from git), or phoronix (which is packaged, but kinda weirdly; it downloads the workloads via the internet)
[20:40] <bryceh> I've also asked the Dx folks to produce a Unity/Compiz stress test we could use, but haven't heard status on that in some time
[20:41] <bladernr> bryceh:  yeah... I actually wouldn't be against running Phoronix, except that it's not in main either (this is for Ubuntu Friendly, primarily) and the goal is that users won't have to install extra things to do basic testing...
[20:41] <bladernr> bryceh:  that and it seems that I can't run Phoronix without having to download an additional 500MB of stuff ;-)
[20:41] <bryceh> phoronix includes a test script that will run openarena in automated mode for instance
[20:42] <bryceh> yeah :-/
[20:42] <bladernr> heh... I non-graphics related, but I installed Phoronix's "CPU" suite, and it pulled down nearly 2GB of extra stuff on a fresh Oneiric + Phoronix 3.4.0 install
[20:43] <bryceh> bladernr, problem is I think goal of main is to stick with just must-have bits such as would go onto the CD, and anything test-ish typically would be superfluous for anyone but us ;-)
[20:43] <bladernr> yeah, and that's the balance :)
[20:43] <bladernr> checkbox is in main, but everything we'd like to have is elsewhere :/
[20:44] <bladernr> oh well, that's part of the fun, I guess... ok, thanks everyone, gonna work on this some more
[20:45] <bryceh> bladernr, can you give me a bit more info about what you're trying to put together?
[20:45] <bryceh> bladernr, the xdiagnose/data/workloads stuff I'm putting together might fit your needs
[20:46] <bladernr> bryceh:  historically, we've had a VERY basic test in checkbox that just validates that 3d rendering is there and works... 
[20:46] <bladernr> bryceh:  so until this point, that has simply been running glxgears and asking the user if they saw the pretty moving gears.
[20:46] <bryceh> bladernr, mm, did it turn up many useful bugs?
[20:46] <bladernr> it's not stress or benchmark testing by any stretch...
[20:47] <bladernr> bryceh:  honestly, not that I'm aware of... but it's more a validation test than a bug search... 
[20:47] <bladernr> heh... it's also been there far longer than I have been, but yes, it's actual value is questionable
[20:47] <bryceh> well it certainly can't hurt; it at least verifies the gl libs are loaded properly and such
[20:48] <bryceh> I mean, aside from it being in universe
[20:48] <Sarvatt> glxgears probably isnt the best of tests anyway considering it'll run happily if there's no accelerated 3D
[20:49] <bryceh> bladernr, have you looked at /usr/lib/nux/unity_support_test ?  You definitely should be running that, whatever you do
[20:49] <bryceh> it doesn't display any graphics but it's an important test for validating that the machine will be able to run unity
[20:50] <Sarvatt> how about /usr/lib/nux/unity_support_test -p
[20:50] <bryceh> so more important than glxgears
[20:50] <bryceh> right, with -p
[20:50] <Sarvatt> err bryce beat me to it while i was looking up where it was stored
[20:50] <Sarvatt> hah
[20:53] <bladernr> bryceh:  actually, not at the moment, but I'll add it on the list of things to include for next cycle.  We do have a basic test that came from Natty that checks dbus to verify Unity is running and then ran /usr/lib/unity/autopilot
[20:53] <bladernr> that was when you could assume that if Unity was running, you were 3d capable 
[20:55] <Sarvatt> well unity-support-test would work if someone could run unity but decided not to
[20:55] <bryceh> and would give clues as to why unity wasn't running, if it wasn't
[20:56] <bryceh> plus it's in main already ;-)
[20:57] <bladernr> indeed... I just filed a bug to include that in testing...
[20:57] <bladernr> one of the things we're going to be discussing at UDS is beefing up the graphics testing in Checkbox (at least for now, the plan is to discuss this at UDS)
[20:58] <bladernr> so if you're at UDS and have free time, feel free to come make suggestions.  Actual graphics testing right now is admittedly pretty weak, and we want to change that
[20:58] <bryceh> bladernr, heh
[20:59] <Sarvatt> bladernr: 10 bucks says its schedule the same time as one of the few X talks, thats how it always works out..
[20:59] <bryceh> bladernr, I think there hasn't been a UDS yet that we didn't have this talk.  It's a tradition!
[20:59] <bladernr> bryceh:  yeah, but this time under new management ;-) (and I think I've sat in on this talk at the last three UDSs)
[21:00] <bryceh> bladernr, what my plans are is to build up xdiagnose into an X testing tool that we maintain here on the X side, and fill with yummy bits; it's in main and I'll try to make it reasonably easy to repurpose for automated or interactive testing
[21:01] <bladernr> bryceh:  that would be awesome