[00:03] <RAOF> Huh.
[00:03] <RAOF> That's not what I expected.
[00:04] <RAOF> I may need to revise my hypothesis.
[00:10] <bryceh> Sarvatt, this look at all familiar?  https://launchpadlibrarian.net/93758841/white_window-all_screens2.png
[00:11] <bryceh> occurs with chromium intermittently apparently
[00:11] <Sarvatt> bryceh: nope only seen one white screen when everything in the background was fine
[00:11] <Sarvatt> bryceh: intel?
[00:12] <bryceh> of course ;-)
[00:12] <bryceh> it's lp #935630
[00:13] <bryceh> actually wait, this has a radeon card in it too
[00:13] <bryceh> but yeah, -intel
[00:15] <bryceh> someone else seeing it, is on -radeon
[00:19] <bryceh> bet it's a compiz bug
[00:21] <Sarvatt> bryceh: the mesa bug i'm thinking that ended up with all white windows like that crashed in mesa every time not long after, you upstreamed it, i dont see anything standing out in that bug
[00:22] <Sarvatt> looks like i closed the bug, the guy gave really good debug info on it so i was keeping track of it :(
[00:23] <cnd> it's raining releases :)
[00:24] <cnd> RAOF, there's a new xorg-macros
[00:24] <Sarvatt> i already updated macros in debian twice and it hasn't been released, a third!?
[00:24] <bryceh> katamari coming
[00:25] <cnd> Sarvatt, it's my fault :)
[00:25] <cnd> I added some testing and c++ related stuff to macros
[00:25] <cnd> it's now 1.17
[00:25] <Sarvatt> i saw the leadup but havent seen the release, its late here :)
[00:25] <cnd> I just got the email
[00:25] <Sarvatt> pushing it to git
[00:27] <Sarvatt> after a build test
[00:28] <Sarvatt> might as well 0ubuntu1 xutils-macros unless you plan on pushing more :P
[00:28] <Sarvatt> err xutils-dev
[00:28] <Sarvatt> pushed
[00:31] <eruditehermit> hey
[00:32] <eruditehermit> when using synaptics, my mouse doesn't highlight menu items
[00:32] <eruditehermit> is this something you guys have seen?
[00:35] <RAOF> I believe that's either a compiz bug or a gtk bug.
[00:35] <eruditehermit> it works with psmouse proto=exps
[00:36] <eruditehermit> RAOF, so it is a known problem?
[00:36] <RAOF> eruditehermit: Yeah, I'm pretty sure it is.
[00:36] <eruditehermit> cool
[00:40] <eruditehermit> thanks RAOF
[00:48] <RAOF> cnd: Huh.  I presume you actually built your xorg-gtest patches; why am I having so much trouble?
[00:57] <RAOF> cnd: BAH!  It's because you lied.  Your source branch does not contain all the commits on the list (specifically, it doesn't have 3/9 - hide evemu under #ifdef)!
[04:59] <Sarvatt> tjaalton: so wayland-demos needs to be removed now right?
[05:00] <Sarvatt> bryceh: do you have any desire to have wstart and your background in wayland-demos anymore? weston was synced, aka the wayland-demos rename and lost all customizations
[05:03] <tjaalton> Sarvatt: I guess so
[05:05] <Sarvatt> tjaalton: ok filing the bug
[05:06] <cnd> RAOF, it doesn't?
[05:06] <cnd> I pushed exactly what sent to the list
[05:07] <RAOF> Huh.  My pulls don't see that commit, and it causes build failures.
[05:07] <cnd> RAOF, you have commit f12dbf8526643c2a0c88b5c52ed9f82a7cb232cf?
[05:08] <RAOF> Yes.
[05:09] <RAOF> And f12dbf8~1 is f46d862b2 - Install xorg-gtest source code in $(prefix)/src/xorg-gtest in my pull.
[05:09] <RAOF> cnd: http://cgit.freedesktop.org/~cndougla/xorg-gtest/log/?h=source doesn't seem to list it, either.
[05:09] <Sarvatt> tjaalton: hmm should weston provide wayland-demos maybe? https://bugs.launchpad.net/ubuntu/+source/wayland-demos/+bug/954722
[05:10] <cnd> RAOF, http://cgit.freedesktop.org/~cndougla/xorg-gtest/commit/?h=source&id=f12dbf8526643c2a0c88b5c52ed9f82a7cb232cf
[05:11] <cnd> it's the 6th commit from top
[05:11] <cnd> "Add a meta-header xorg-gtest.h"
[05:12] <RAOF> Oh, right.
[05:12] <RAOF> I'm looking at a different thing - src/xorg-gtest-all.cpp
[05:12] <RAOF> Which unconditionally includes device.cpp
[05:12] <cnd> ahh, yes
[05:12] <cnd> sorry
[05:14] <cnd> I forgot to check when evemu isn't installed
[05:14] <cnd> I'm testing that right now
[05:14] <RAOF> How do you get around the double build of device.cpp?
[05:14] <cnd> double build?
[05:16] <cnd> RAOF, I just pushed a fix to xorg-gtest-all.cpp
[05:16] <cnd> pull again from the source branch
[05:16] <cnd> it should build without evemu
[05:16] <RAOF> I get http://paste2.org/p/1939451 when I build *with* evemu.
[05:18] <tjaalton> Sarvatt: maybe so, if if ships same binaries
[05:18] <cnd> argh, let me double check
[05:18] <RAOF> Incidentally, it'd be a good idea to build the xorg-gtest library during build, but not install it.
[05:19] <Sarvatt> tjaalton: well we'll see if the archive admins complain :)
[05:19] <cnd> RAOF, that's what make check is for
[05:19] <RAOF> Ah, so it is.
[05:19] <cnd> RAOF, I can build it with and without evemu
[05:19] <cnd> with the very latest in my source branch
[05:20] <RAOF> So can I.
[05:20] <cnd> it looks like you are trying to build device.cpp separately from xorg-gtest-all.cpp in the output you pastebined
[05:20] <RAOF> That's not tip; that's with all patches up to 8/9 installed.
[05:20] <cnd> hmm...
[05:20] <cnd> are you sure?
[05:21] <cnd> I have 9/9 here
[05:21]  * RAOF tends to test-build with each patch when reviewing.  People like it if all intermediate steps build, for some reason.
[05:21] <cnd> oh, you mean you've built up to 8/9
[05:21] <Sarvatt> for good reason, it is git after all :)
[05:22] <cnd> if every git commit builds in my series I'll be pleasantly surprised
[05:22] <RAOF> Sarvatt: Indeed.  And since git has a stupid merge model… :{
[05:22] <cnd> I tried to do things in a sane way
[05:22] <Sarvatt> stupid, ha! :)
[05:22] <cnd> but overhauling the build system is not an easy task over multiple commits
[05:22] <Sarvatt> i like seeing history instead of merged foo branch with 40 commits as one commit thanks :)
[05:23] <cnd> Sarvatt, I tend to think git merge --no-ff is helpful
[05:23] <cnd> having had to backport all of the input stack from 1.12 into 1.11 :)
[05:23] <RAOF> Sarvatt: It's a matter of opinion; I find treating the merge as a single unit is most often the most useful way to think about it.
[05:24] <cnd> I agree
[05:24] <cnd> but I don't bother with --no-ff for git branches
[05:24] <cnd> because no one else does
[05:24] <RAOF> Since your merge is generally *conceptually* one unit of work, broken up into a bunch of smaller parts - the individual commits.
[05:31] <Sarvatt> i just hate going through something like http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/unity-greeter/precise/changes
[05:32]  * Sarvatt picked the first bzr branch that popped up in his browser
[05:32] <Sarvatt> yes i know rXXX broke it, but it did 30 things at once
[05:34] <RAOF> That's not a terribly good example, because it's a packaging branch :)
[05:35] <RAOF> So the unit of measure there is the "release" :)
[05:36] <RAOF> Huh.  I'm a bit surprised that it doesn't have the upstream history, though.
[05:45] <Prf_Jakob> https://bugs.freedesktop.org/show_bug.cgi?id=44697 <-- is this something you guys have seen?
[05:53] <Sarvatt> Prf_Jakob: thanks, replied
[05:53] <Sarvatt> most likely wont still be a problem, price you pay for following git master :P
[05:54] <bryceh> Sarvatt, no I don't really care anymore
[06:40] <cnd> RAOF, I just updated my source branch a bit more
[06:40] <cnd> I'm done for the day though
[06:40] <cnd> please let me know if there are any issues
[06:41] <cnd> I'll work on them tomorrow
[06:41] <cnd> thanks!
[06:49] <RAOF> I'll check.
[07:36] <tjaalton> oh geez, the weston sync made it in phoronix..
[12:25] <dupondje> Could somebody give https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/931397 a look?
[15:35] <bryceh> dupondje, yeah I looked at it, and can reproduce it myself.  Next step is probably some intimate git-bisection work to find the failure, just haven't had time yet.
[15:59] <dupondje> It seems fixed already in a newer version
[15:59] <dupondje> i'll see if I can do some bisect
[16:12] <bryceh> that'd be great
[17:41] <LLStarks> is multitouch for touchpads or touchscreens?
[17:46] <bryceh> LLStarks, both
[20:10] <LLStarks> bryceh, how do i make use of it? all that new xinput code seems to have done is eliminate skipping when multiple points of contact are made on the touchpad.
[20:11] <bryceh> LLStarks, cnd has posted some emails and stuff to ubuntu-devel@ and ubuntu-x@, with some of the commands that turn things on and customize them.
[20:11] <bryceh> some of it depends a lot on your hardware.
[20:12] <cnd> LLStarks, are you asking how to develop applications with multitouch support?
[20:13] <cnd> sorry to message and run, I need to get some lunch
[20:13] <cnd> biab
[20:14] <FernandoMiguel> evening
[20:35] <FernandoMiguel> what's that white bar over HUD?
[20:40] <FernandoMiguel> http://i.imgur.com/m21U1.png
[21:41] <bryceh> FernandoMiguel, it's even shadowed!
[21:42] <FernandoMiguel> I know
[21:42] <bryceh> FernandoMiguel, compiz bug probably; there've been other such white box bugs reported, dig through the compiz bug pile
[21:42] <FernandoMiguel> k
[21:42] <bryceh> I bumped one over there the other day
[22:27] <LLStarks> cnd, just use multitouch for cool things like gestures or multi pointer
[22:27] <cnd> LLStarks, what is your definition of "use"?
[22:27] <cnd> do you want to use multitouch to develop applications using gestures?
[22:27] <LLStarks> no
[22:27] <cnd> or do you want to play with multitouch applications?
[22:27] <LLStarks> play
[22:28] <LLStarks> synaptic gesture is fedora-only
[22:28] <LLStarks> afaik
[22:28] <cnd> we have the same synaptics for trackpads
[22:28] <cnd> but those aren't really multitouch
[22:29] <cnd> LLStarks, unity has gestures
[22:29] <cnd> but we don't have many applications with gestures yet
[22:29] <cnd> we're still developing easy-to-use gesture APIs
[22:30] <LLStarks> only unity? what about gnome-shell?
[22:30] <cnd> if you have a touchscreen, you can test out some gesture support in eog and evince
[22:31] <jcristau> LLStarks: canonical works on unity not gnome shell..
[22:32] <cnd> LLStarks, nothing is preventing gnome-shell from using utouch for gestures like unity does, but no one has attempted to yet
[23:52] <cnd> RAOF, I hope xorg-gtest is all ready for your usage today :)
[23:52] <RAOF> cnd: I'm just sending a mail to xorg-devel saying that the source branch now builds fine for me, and throwing a reviewed-by at it.
[23:52] <cnd> RAOF, what about the interface for other projects?
[23:53] <cnd> i.e. the xorg-gtest.m4 script and Makefile-xorg-gtest.am
[23:53] <RAOF> That looks like a reasonable solution to me.
[23:53] <cnd> ok
[23:54] <RAOF> I guess you could write a custom Makefile, rather than use an autotools generated one, and that might be nicer.  I'm not entirely sure how that would look, though.
[23:54] <cnd> I'm worried about trying to support such an approach long term
[23:55] <RAOF> The "include a makefile" approach?
[23:55] <cnd> yeah
[23:55] <cnd> and making it work properly with all the permutations of configurations
[23:55] <cnd> like silent build options
[23:55] <RAOF> Oh, right.
[23:56] <RAOF> Silent build isn't *terribly* hard to implement manually, but it's more annoying, yeah.
[23:56] <RAOF> I don't think the build permutations would be terribly hard to support, though?
[23:57] <cnd> I don't really know
[23:57] <cnd> and I don't have time to try to think about it :)
[23:58] <RAOF> :)
[23:59] <cnd> I've already devoted too much time to autotools this past week...