[00:36] <racarr> RAOF: How goes stub clientAPI stuff?
=== no_m7u is now known as Nothing_Much
=== chihchun is now known as chihchun_afk
[03:34] <robert_ancell> duflu, is mir_demo_server_shell and mir_demo_client_fingerpaint supposed to work in utopic? When I run them you don't seem to be able to draw with the mouse
[03:35] <duflu> robert_ancell: Yes, it does work. Did you remember sudo (required for input device access)?
[03:35] <robert_ancell> duflu, the server is run through sudo, yes
[03:35] <robert_ancell> I'm getting motion events. And if I click on the fingerpaint window it drags it rather than drawing
[03:39] <robert_ancell> duflu, are you running utopic? Can you confirm it working there?
[03:39] <duflu> otp
[03:42] <robert_ancell> ah, it seems that on first click it's in drag mode. If I hold down alt then drag the window it seems to work after releasing alt and then clicking.
[03:48] <duflu> robert_ancell: Ah, could be a minor demo-shell issue stealing the events then
[03:49] <duflu> Or not an issue at all
[03:49] <duflu> Will test
[03:49] <robert_ancell> It seems like the surface doesn't have focus. When I test GTK+ mir we're not getting any mouse up/down events even when clicking inside the surface until that first drag with alt.
[03:56] <duflu> robert_ancell: Works fine immediately on startup for me (now using vivid but always worked in utopic too)
[03:56] <robert_ancell> weird
[03:56] <duflu> robert_ancell: I fully expect we have input bugs though. I can't reproduce this one is all
[04:00] <duflu> robert_ancell: Oh, do you have multiple surfaces/clients when fingerpainting?
[04:01] <duflu> I think I have observed that fingerpainting on an unfocused window only works sometimes
[04:01] <duflu> Although I'm not sure it should work at all in our current design
[04:02] <robert_ancell> Who knows the correct way to interpret a current Mir motion event? GTK+ Mir was looking at the button_state field to determine which button event to generate. But touch events seem to have button_state empty. You can't tell it's a touch event without looking at the pointer_coordinates field. If we get a down event with button_state empty just assume it's the primary mouse button?
[04:03] <duflu> robert_ancell: There's a "tool" field to tell you if it's a finger or mouse (with buttons)
[04:04] <duflu> In theory
[04:04] <robert_ancell> duflu, only in the pointer_coordinates list - which could be a different tool for each event
[04:04] <robert_ancell> for each coordinate I mean
[04:04] <robert_ancell> We have the magic numbers for the device but no way to interpret them :)
[04:04] <duflu> robert_ancell: Yeah you could be using multiple tools at once
[04:05] <robert_ancell> I'm just going to generate a primary mouse button event if the field is empty
[04:05] <duflu> robert_ancell: Technically you should look at all the pointer_coordinates because any one of them could be a mouse
[04:05] <robert_ancell> But which one generated the up event?
[04:06] <duflu> robert_ancell: Hmm sounds like a good question. I'm reaching the limits of my mental memory of the event struct
[04:06] <robert_ancell> Based on previous discussions I think the answer would be "we're going to replace that struct"
[04:06] <RAOF> robert_ancell: This discussion is going to be obsolete reasonably soon.
[04:06] <RAOF> Hah, yes!
[04:06] <robert_ancell> there we go :)
[04:07] <duflu> robert_ancell: Kind of. It will hang around for a fair time because breaking the client API will be painful
[04:07] <duflu> ... for distro
[04:07] <RAOF> Do what you want for the moment, we'll provide you with an actual pointer in MirInputEvent 2.0
[04:07] <RAOF> (As in - there'll be a core-pointer like device that is what you care about)
[04:07] <duflu> robert_ancell: A reasonable kludge is only test pointer[0]
[04:08] <robert_ancell> I'm just going to do if (button_state == 0) generate_event (PRIMARY)
[04:11] <duflu> robert_ancell: Actually it's probably a good idea to separate button state from the pointer list. Assuming you don't care about multi-mouse support, you might want to use buttons in concert with some other device. So the device that has the buttons is irrelevant
[04:12] <robert_ancell> What is with X generating out of order keyboard events when it gets laggy? Very annoying...
[06:59]  * RAOF is confused and alarmed as to what the hell is happening on https://jenkins.qa.ubuntu.com/job/mir-utopic-amd64-ci/342/consoleFull
[07:09] <duflu> RAOF: The leak?
[07:10] <RAOF> That, and the 25 failing tests are failing with valgrind errors in totally unrelated code.
[07:10] <RAOF> If you look at it, ClientLibraryErrors.create_surface_returns_error_object_on_failure completes fine.
[07:10] <duflu> RAOF: Yeah I think that's "normal" with valgrind errors... some tests will fail delayed
[07:10] <RAOF> And then 25 *unrelated* tests fail with by 0x5EA268: ClientLibraryErrors_create_surface_returns_error_object_on_failure_Test::TestBody() (test_client_library_errors.cpp:206)
[07:16] <RAOF> Oh, it's probably something to do with forking.
[07:26] <duflu> That's fun. Compiz is mentioned in a kernel header... #define KEY_SCALE               120     /* AL Compiz Scale (Expose) */
=== Saviq is now known as Saviq-codedive
=== chihchun_afk is now known as chihchun
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
[15:00] <alan_g> alf_: anpok_ any opinions pending on this? https://code.launchpad.net/~alan-griffiths/mir/mir_Server-apply_settings/+merge/240612
[15:03] <alf_> alan_g: commented
[15:03] <alf_> alan_g: (approved)
[15:05] <alan_g> alf_: thanks. (I'll now base my next MP on it.)
=== chihchun_afk is now known as chihchun
=== dandrader is now known as dandrader|lunch
=== chihchun is now known as chihchun_afk
=== dandrader|lunch is now known as dandrader
=== alan_g is now known as alan_g|EOD
[18:55] <racarr> AWS outage causedirssi to die
[18:56] <racarr> private message bankruptcy :)
=== Saviq-codedive is now known as Saviq