[09:42] <anpok_> alan_g: https://code.launchpad.net/~andreas-pokorny/mir/load-all-supported-input-platforms/+merge/274421/comments/702108 you mean the mouse cursor itself is not moving?
[09:42] <alan_g> anpok_: right
[09:43] <anpok_> with a touchpad or mose?.. do you have logs from the hosting server?
[09:44] <alan_g> It's a lenovo - there's both a touchpad and a button in the keyboard. The latter is what works with the current input stack, but not with the MP
[09:45] <alan_g> (It does move without the button presses)
[10:09] <anpok_> alan_g: hm oh libinput might have defaulted to disable while typing
[10:09] <anpok_> but that would be odd for modifier keys
[10:10] <anpok_> i remember a change for that ..
[10:10] <anpok_> whats your libinput version?
[10:11] <alan_g> hold on, I have to grab the laptop...
[10:12] <alan_g> libinput10
[10:16] <anpok_> 0.10  was the last abi breaking release.. the source version should be higher
[10:17] <anpok_> hm maybe I should finally make an MP that adds input configuration examplse and also one that makes disable while typing configureable
[10:17] <alan_g> sorry, 0.21.0
[10:17] <anpok_> thx will dig through logs
[10:34] <alan_g> alf_: did you get a response from CI re mir-mediumtests-builder-vivid-armhf?
[10:39] <alf_> alan_g: Yes, they fixed the infrastructure problem. The mir-mediumtests-runner-touch are now failing because of https://bugs.launchpad.net/mir/+bug/1515660 .
[10:42] <alf_> alan_g: I'll take a look. I need a break from the Android stuff.
[10:45] <alan_g> alf_: I thought it the same as I get 404 from https://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/4834/console and https://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/ ends on the 12th
[10:51] <alf_> alan_g: That's yet another problem (something goes wrong when publishing the result to the public server), but it doesn't affect the job result. Logs are available in s-jenkins.
[10:52] <alan_g> alf_: I can't access that since I have trouble with the VPN I've not been motivated to resolved.
[10:55] <anpok_> hm this is also a vivid-clang problem .. "Failed to trigger thread shutdown"
[10:55] <anpok_> *there
[10:56] <anpok_> in several MPs during NestedServer acceptance tests
[10:57] <anpok_>  NestedServer.display_configuration_reset_when_application_exits
[11:00] <anpok_> the mako test runner failure is beause 0.17.1 landed
[11:00] <anpok_> alf: we need to incorporate the changelog to lp:mir.. or even add an entry for 0.18.0
[11:01] <alf_> anpok_: ack, will take a look
[11:01] <anpok_> as a result of the newer version archive it only install some of the ci built packages..
[11:03] <anpok_> odd
[11:04] <anpok_> despite the complaints initially it does install the ci build
[14:25] <alan_g> alf_: kdub - at the root of some of the display config problems is the way that nested::Display manages overlapping (in my case cloned) outputs. It makes a surface supposedly the size of the bounding rectangle but also fullscreen on the first output in the overlap group: the server resizes the surface and things get "inconsistent". Is it better to have fullscreen surfaces for all active outputs? Or not have it fullscre
[14:25] <alan_g> en?
[14:25] <greyback_> alan_g: I see no reason why a nested server would want a non-fullscreen surface
[14:27] <alan_g> greyback_: in this case it wants one that covers all the overlapping outputs. Suppose your outputs are {{0, 0}, {100, 700}} and  {{0, 0}, {700, 100}} then the current logic wants  {{0, 0}, {700, 700}}
[14:28] <greyback_> alan_g: ah, cloned mode
[14:29] <anpok_> that may cause weird behavior for input too..
[14:29] <greyback_> if you're cloning the nested server's surface on each display, why would arrange things so it is partly occluded? i.e. is too big for each display
[14:30] <greyback_> either we choose size which is intersection of the display geometries, else we start scaling to fit
[14:31] <alan_g> greyback_: ...or we pick "the biggest" monitor and window the others.
[14:31] <alan_g> there are lots of options. But the current choice is broken.
[14:33] <greyback_> desktop currently chooses the intersection of the display geometries, which is most reliable choice I guess
[14:35] <alan_g> that also makes sense.
[14:35] <alf_> alan_g: greyback_: The single surface for overlapping is an optimization that's, in theory at least, worth having, but it's not necessary. Are there any downsides to option 2, not making the surface fullscreen?
[14:36] <alf_> greyback_: so for 0,0,100x700 0,0,700x100 it would show a 0,0,100x100 surface on both screens?
[14:36] <alan_g> Currently, the system-compositor WM rejects non-fullscreen surfaces
[14:36] <kdub> kgunn, I didn't see the mir packages installed from the silo...
[14:37] <alan_g> So that affects USC
[14:37] <kgunn> kdub: you have to pin the ppa
[14:37] <kdub> ah, right
[14:37] <kgunn> /etc/apt/preferences.d/extra-ppa.pref
[14:37] <kgunn> just copy that entry
[14:37] <kgunn> and modify one to be "landing-020"
[14:38] <kdub> ack
[14:38] <kgunn> kdub: so how did you get that thing to build without gles there ?
[14:38] <kdub> I don't know how silos work :) :/
[14:38] <kgunn> i was reading up on that....twins...and i guess it's always suppose to fail
[14:38] <kgunn> :)
[14:38] <alf_> alan_g: on the other hand, the single surface may interfere with overlay optimizations on the host server...
[14:39] <kgunn> kdub: i'm trying to get qtmir force merged around the xenial mess
[14:39] <kgunn> so we can add that back and rebuild more easily
[14:40] <alan_g> alf_: yes, I'm not sure how to evaluate the trade-offs
[14:45] <alf_> alan_g: We would need to measure unity8 FPS with the two approaches. For now I would say if (1) (one fullscreen surface per output) is simpler overall, go for that and we can revisit.
[14:45] <alf_> alan_g: greyback_: What are our main clone mode scenarios (for phone)?
[14:46] <anpok_> alf_, alan_g: would those two surface be overlapping on usc too?
[14:46] <greyback_> alf_: none in my opinion
[14:47] <greyback_> clone mode only makes sense for very limited situations - usually mirroring desktop onto projector for presentation
[14:47] <anpok_> alf_, alan_g: or would usc always be neutral and.. assume them to be side by side?
[14:47] <alf_> greyback_: then I guess the optimization isn't important anyway, so let's go for the simpler solution
[14:47] <alf_> alan_g: ^^
[14:48] <alan_g> anpok_: they are also overlapped in USC
[14:48] <alf_> anpok_: hmm, actually that's a good point
[14:49] <alan_g> alf_: ack. I just need to test that compositing isn't confused by overlapping display buffers.
[14:49] <anpok_> alan_g, alf_: thinking about the cursor..
[14:49] <anpok_> and enter exit events that we can probably filter out..
[14:52] <kdub> kgunn, alright, so i'm seeing what you're seeing, so I guess we had 2 corruption issues
[14:52] <kdub> because the demo_client_flicker one sure was a problem
[14:52] <kdub> where's our xmir source?
[14:52] <kgunn> kdub: one sec...lemme dig
[14:52] <kgunn> kdub: https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir
[14:53] <kdub> kgunn, thanks, let me see if there's anything in there that stands out
[16:16] <tsdgeos> hi guys, i'm getting the "Failed to wait for event" exception of dispatch_loop in threaded_dispatcher.cpp
[16:17] <tsdgeos> when starting unity8 in my laptop
[16:17] <tsdgeos> any idea of what may be the culprit?
[16:25] <alan_g> anpok_: did you need me to do anything on laptop? (yet?)
[16:31] <anpok_> you would have to run evemu-describe and evemu-record as root
[16:32] <anpok_> but but for all involved devices
[16:32] <anpok_> so touchpad and touchpad button ... if those are exposed as separate
[17:28] <dandrader> anpok_, are we tracking the lacking of mouse acceleration on the relative mouse axes in some bug already?
[17:31] <dandrader> anpok_, if so this bug could be make a duplicate: https://bugs.launchpad.net/mir/+bug/1517133
[17:31] <dandrader> s/make/made