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