[01:50] <Sarvatt> RAOF: ignore the patch names, how crazy does this look to you? http://paste.ubuntu.com/881301/
[01:51] <Sarvatt> going to need to condense these 50+ assigned private ivybridge bugs into something public for a SRU, ugh
[01:54] <RAOF> Sarvatt: What's getbuffer doing in there? 
[01:55] <RAOF> It doesn't look like an ivybridge fix; is that for something else?
[03:25] <RAOF> Oh, whoops.  That xfixes upload *may* have broken ABI.
[03:26] <RAOF> Or, rather broken ABI that we care about.  Stupid structure packing.
[03:53] <Sarvatt> RAOF: now I'm going to be disappointed when its not quetzalcoatl
[03:54] <Sarvatt> it will be fun misspelling that in debian/changelog 99% of the time
[03:55] <Sarvatt> oh wait thats not the adjective :)
[03:56]  * RAOF is hoping for ‘Questing Quetzacoatl’
[03:56] <RAOF> And also popping out for a moment.
[04:46] <tjaalton> Sarvatt: quetzal is the bird, quetzalcoatl is some "feathered mesoamerican deity" :)
[04:47] <tjaalton> RAOF, Sarvatt: yeah I'm not that worried that it wouldn't work with wleds, but a friend of mine kinda is
[04:48] <tjaalton> though he's also willing to just try it out since the colorhug is so affordable
[04:48] <RAOF> And just to be sure, by “wleds” you mean wide gamut led backlit displays, right?
[04:48] <RAOF> Such as, say, a Dell U2410?
[04:49] <tjaalton> is the marketing name "white leds"? then yes
[04:49] <RAOF> That makes it sound like just a simple led backlit display; if so, definitely yes.
[04:49] <tjaalton> he heard that some devices have a hard time getting the calibration right
[04:49] <tjaalton> ok thanks
[04:49] <RAOF> (Also definitely yes for wide-gamut led backlit display ☺)
[04:52] <tjaalton> right, I was pretty sure about that already, just wanted to confirm :)
[04:52] <tjaalton> not that you can actually get one anyway, the backlog is six weeks long..
[04:53] <RAOF> Also, it's easy to update the firmware, there's room for 60-odd calibration matricies, and Richard is adding more matrices as he gets access to more hardware (that's one of the things the first round of pre-order customers are doing; calibrating the colorhug using their existing photometers)
[05:19] <Sarvatt> wow 4 months lead time to get one
[05:30] <tjaalton> hmm weston, why not sync it?
[05:35] <RAOF> A fair question.  Sarvatt, any comments?
[12:57] <Sarvatt> RAOF, tjaalton: at this point its better than nothing, not sure if bryce cares about wstart and the background getting dropped :)
[12:58] <tjaalton> Sarvatt: thanks, syncing :)
[13:01] <Sarvatt> tjaalton: wait
[13:01] <Sarvatt> did you test build it?
[13:01] <Sarvatt> debian puts wayland egl in a different package
[13:01] <tjaalton> heh
[13:01] <tjaalton> well it's in NEW
[13:01] <tjaalton> I'll try
[13:02] <Sarvatt> yeah /usr/bin/ld.bfd.real: cannot find -lwayland-egl
[13:02] <tjaalton> hmm actually, wayland egl got moved
[13:02] <tjaalton> what, we should have it in the same package
[13:02] <Sarvatt> hmm
[13:03] <tjaalton> _should_, don't necessarily have it yet, I looked at the issue during one merge..
[13:03] <tjaalton> sigh
[13:11] <Sarvatt> tjaalton: libwayland-egl needs to be in /usr/lib/multiarch/mesa-egl/ with the rest of the egl libs, works that way
[13:11] <tjaalton> so we ship it in both libegl1-mesa and libegl1-mesa-drivers
[13:11] <tjaalton> cool
[13:11] <tjaalton> ..
[13:13] <tjaalton> I'll change that
[13:13] <Sarvatt> dri/usr/lib/${DEB_HOST_MULTIARCH}/egl/egl_gallium.so usr/lib/${DEB_HOST_MULTIARCH}/egl looks wrong too
[13:13] <Sarvatt> libegl1-mesa-drivers.install.linux.in
[13:15] <Sarvatt> should be in mesa-egl i imagine
[13:22] <Sarvatt> erg libxfixes is removing unity
[13:23] <tjaalton> update
[13:23] <tjaalton> ..again
[13:23] <Sarvatt> ah ok
[13:25] <Sarvatt> us.archive.ubuntu.com is lagging, still offering 5.6.0-0ubuntu1
[13:26] <tjaalton> it's libxfixes3 1:5.0-4ubuntu3 that you want
[13:26] <tjaalton> the previous one broke the abi
[13:27] <Sarvatt> its pulling down 1:5.0-4ubuntu4 which breaks the old unity offered
[13:28] <tjaalton> oh
[13:28] <tjaalton> hmm
[13:28] <tjaalton> ok not sure what's wrong then :)
[13:29] <tjaalton> I managed to upgrade before the new libxfixes got built
[13:30] <Sarvatt> they're going back to the ubuntu2 xfixes and rebuilding unity against it but unity got stuck in depwait and had to be rebuilt again, just finished 20 minutes ago
[13:30] <tjaalton> heh
[13:30] <Sarvatt> Binary: libwsbm-dev libwsbm1
[13:30] <Sarvatt> doh
[13:31] <Sarvatt> gotta fix cedarview packaging now
[13:31] <tjaalton> I noticed that moving windows across workspaces is broken in fabulous ways if the wall animation timeout is 0 (=disabled)
[13:31] <tjaalton> has been for some time though
[14:02] <tjaalton> what about the guy wanting to have gallium i915_dri back? should it build fine etc so it can be shipped in -dri-experimental?
[14:08] <Sarvatt> tjaalton: dri/usr/lib/${DEB_HOST_MULTIARCH}/libwayland-egl.so usr/lib/${DEB_HOST_MULTIARCH} in libegl1-mesa-dev, doesn't that need to be in mesa-egl too?
[14:10] <tjaalton> actually, why are we moving the wayland bits?
[14:11] <tjaalton> expecting the blobs to reiplement them?
[14:11] <Sarvatt> it needs to be in the same place as egl
[14:11] <Sarvatt> egl's getting moved to use with alternatives for blobs yeah
[14:12] <Sarvatt> tegra, cedarview, all the arm crap
[14:12] <tjaalton> ok if it needs to be there then fine
[14:12] <Sarvatt> well weston failed until i moved libwayland-egl* to /usr/lib/multiarch/mesa-egl/
[14:13] <tjaalton> man this is hard to get right
[14:13] <tjaalton> in my head at least :)
[14:13] <Sarvatt> tell me about it, mesa is crazy
[14:13] <Sarvatt> main reason i'd like to not bring back i915g
[14:14] <jcristau> can't the folks who want i915g just build it themselves?
[14:14] <tjaalton> ok so yes libwayland-egl.so needs to be there too, since we already create a link pointing there..
[14:15] <tjaalton> ..which is racy, dunno which one gets installed
[14:18] <tjaalton> Sarvatt: ok pushed, looks ok now?
[14:22] <Sarvatt> tjaalton: yeah minus libegl-gallium.so not being usable, but i've got to dig out a gallium using system to look at that one. at least weston will build against that. want me to test build and try building weston just to be sure?
[14:25] <tjaalton> Sarvatt: if it's not much trouble, sure
[18:26] <Darxus> I just realized there's a chance of compatible wayland and gtk packages in 12.04 Precise.  What are the chances of gtk 3.4 being included?  
[18:32] <seb128> Darxus, gtk 3.4 is already in precise for 3 months
[18:33] <Darxus> Oh.  Nice.  So some gtk apps can already run through wayland on precise with only packages in the precise repositories?
[18:33] <Sarvatt> i imagine gtk+ needs to enable wayland support, but not sure thats something thats wise :)
[18:35] <Sarvatt> its bad enough keeping wayland and mesa up to date together because the api changes so much, gtk+ would complicate things greatly
[18:36] <Sarvatt> many assumptions you're running git master of everything always to use it still
[18:36] <Darxus> Sarvatt: Yeah except wayland did a 0.85 release that gtk is maintaining compatability with until the 3.4 relese.
[18:36] <Darxus> And the wayland 0.85 release is what's packaged for precise.
[18:37] <Sarvatt> well ya might want to ask in #ubuntu-desktop or file a wishlist bug, its definitely not enabled at the moment
[18:37] <Darxus> seb128: seb128 Where is gtk 3.4?  This looks like 3.3 is in precise:  http://packages.ubuntu.com/search?suite=precise&keywords=libgtk
[18:37] <Darxus> Sarvatt: Okay, thanks.
[18:40] <Sarvatt> Darxus: from my perspective the problem is going to be when we do LTS backports, backporting X/mesa/kernel from 12.10 into 12.04 for newer hardware support, wayland will be included, thats guaranteed going to break 3.4 gtk+ wayland (gotta be crazy to think 0.85 will last that long without major breaks)
[18:42] <Sarvatt> it's kind of too late already too, we're well past feature freeze but ya have to talk to the desktop guys about it to be sure
[18:43] <Darxus> Thanks.
[18:45] <Darxus> I don't see how enabling wayland in gtk, so it works when precise is released but breaks when other packages get backported in the future is worse than never having it work in precise at all.
[18:46] <seb128> Darxus, 3.3 is the 3.4 serie, it just didn't turn stable yet
[18:47] <Darxus> seb128: Nice, thanks.
[18:52] <Sarvatt> Darxus: I bet ricotz would be interested in enabling it in the gnome ppa if you catch him on, possibly getting it ready to go for when 12.10 opens
[18:52] <Darxus> Sarvatt: Good to know, thanks.
[18:53] <Sarvatt> he keeps wayland up to date in xorg-edgers and is interested in it and also does lots of gnome stuff
[18:53] <Sarvatt> i'll ping him when i see him on
[18:53] <Darxus> Cool.
[20:09] <cnd> RAOF, I need help getting unity 3d on behemoth again :(
[20:09] <cnd> I don't understand why it's always broken...
[20:10] <cnd> when you have a minute, please ping me
[21:23] <cnd> RAOF, nm, unity --reset fixed it
[21:23] <cnd> RAOF, though I do need you to review the xorg-gtest patches :)
[21:54] <RAOF> cnd: Sure :)
[21:54] <cnd> RAOF, as for the xorg-gtest MIR, we have a lot of work to do
[21:54] <cnd> we have to push to get xorg-macros 1.17 released upstream
[21:54] <cnd> we have to get the latest xorg-gtest released
[21:55] <cnd> and then both packaged up and updated in precise
[21:55] <cnd> all after the feature freeze...
[21:55] <RAOF> Well, we can leave that.
[21:55] <cnd> really, we have to do it anyways
[21:55] <RAOF> The tests are now available for those who want to build locally.
[21:55] <cnd> because xorg-gtest is currently broken in precise
[21:55] <cnd> the gtest update that removed the static libs breaks xorg-gtest
[21:55] <RAOF> Oh, because it builds against the static library I removed.  Superb!
[21:56] <cnd> yeah
[22:53] <RAOF> cnd: Do you have any magical way of easily pulling patches out of git send-email's output (rather than saving each mail and applying)?
[22:53] <cnd> ask for where one can pull patches from?
[22:53] <cnd> do you need my patches?
[22:54] <cnd> if so, my personal xorg-gtest repo on fdo in the "source" branch has my commits
[22:54] <cnd> RAOF, ^^
[22:55] <RAOF> That's probably easier :)
[22:55] <cnd> RAOF, remember you'll need the latest xorg macros
[22:55] <cnd> and they need to be updated to appear as though they are 1.17
[22:56] <cnd> or manually reset the minimum version requirements to 1.16 when you test it out
[23:13] <Sarvatt> RAOF: btw barriers are screwed up on some input drivers
[23:13] <Sarvatt> mtrack is a mess but synaptics is fine
[23:13] <RAOF> Sarvatt: ???!
[23:14] <Sarvatt> how do i go about finding out why? :)
[23:14] <Sarvatt> it takes literally 10 attempts to make the launcher pop out with xf86-input-mtrack
[23:14] <Sarvatt> guess i should try evdev, thats the one that would suck to have broken
[23:15] <RAOF> Ok.  So the barrier blocking behaviour works fine, but the launcher reveal is brokenish?
[23:15] <RAOF> Kindly build http://paste.ubuntu.com/882498/ (you'll need ‘gcc -o barrier-test barrier-test.c -std=c99 $(pkg-config --libs xi xfixes)’)
[23:15] <Sarvatt> its like i cant press hard enough to make it pop out
[23:16] <Sarvatt> had to switch back to synaptics to use autohide
[23:16] <RAOF> If you run that it'll dump the velocity values you generate when you hit the thingy.
[23:16] <Sarvatt> incredibly frustrating :)
[23:18] <Sarvatt> what should i use for threshold?
[23:19] <RAOF> Anything; it doesn't really matter.
[23:20] <RAOF> Although don't set it higher than a couple of thousand, or you won't be able to get past it  :)
[23:27] <Sarvatt> http://paste.ubuntu.com/882516/
[23:27] <Sarvatt> first is synaptics which works great
[23:27] <Sarvatt> it could just be an mtrack specific problem, will try evdev out
[23:29] <Sarvatt> nevermind evdev doesn't work
[23:29] <RAOF> Sarvatt: Aaah.  Thanks for that.  mtrack is doing something crazy - notice how the ids for synaptics stay constant while you're hitting the barrier, and the mtrack ones don't?  That indicates that mtrack is sending motion events which *don't* hit the barrier in between.
[23:30] <RAOF> Could you try an xinput test, see what actual events are hitting the server when you try to run against the barrier?
[23:31] <bryceh> Sarvatt, is the mesa currently in xorg-edgers going to be pulled into precise, or are we on to doing individual cherrypicks at this point?
[23:31] <Sarvatt> bryceh: yeah 8.0.2 is releasing this week
[23:42] <Sarvatt> RAOF: this is so chatty, do you want a log of just me pressing against the edge and it not revealing?
[23:43] <Sarvatt> http://paste.ubuntu.com/882529/
[23:43] <RAOF> Yah, that'd be fin.
[23:44] <RAOF> Sarvatt: Is that constant motion right-to-left?
[23:44] <RAOF> Or, at least, constantish?
[23:45] <Sarvatt> http://paste.ubuntu.com/882531/ thats me pressing against it 3 times trying to reveal it from the middle of the screen
[23:45] <Sarvatt> well i guess i do speed up as i get closer to the edge
[23:45] <Sarvatt> i try to push it hard
[23:46] <RAOF> You'll probably have better luck pushing it more gently.
[23:47] <RAOF> It looks suspiciously like mtrack is sending some left→right motion events in the stream.  Which'll break the barrier stuff.
[23:48] <RAOF> Could you perhaps do the same with test-xi2?  That should give the raw relative events.
[23:48] <Sarvatt> http://paste.ubuntu.com/882537/ thats 7 or so times being constant with how hard i'm pressing against the edge
[23:48] <Sarvatt> ok i'm happy as long its the unsupported universe driver is at fault :)
[23:49] <Sarvatt> i had to switch while synaptics was causing me crashes with the lid closed to get things done, but synaptics seems to be working again after cnd's fixes
[23:49] <RAOF> I'd like to know the xi2 results too, as I think that's a better velocity measure.
[23:50] <Sarvatt> holy hell thats even chattier
[23:50] <cnd> woot! synaptics with clickpad support released upstream
[23:50] <RAOF> Yes.  Yes it is.
[23:50] <cnd> clickpad+clickactions even
[23:50] <Sarvatt> i wonder if that'll even fit on pastebin
[23:51] <Sarvatt> cnd: aweeesome!
[23:51] <cnd> now I just need to reopen the FFe
[23:51] <Sarvatt> http://paste.ubuntu.com/882543/
[23:52] <Sarvatt> first attempt brought out the launcher, took 5 attempts or so after that to bring it out the next time