[09:01] <anpok> alan_g: one final question on the dnd MP - so a client identifies a drop event by makeing a != nulptr test on the dnd handle of a pointer button up event?
[09:03] <anpok> nm - there is a test for just that
[09:03] <alan_g> anpok: yes
[11:09] <alan_g> kdub: is mcl::ErrorChain obsolete - I don't see it being used.
[11:11] <kdub> eh, guess we have check that mir_presentation_chain_get_error_msg is working
[11:12] <kdub> could have been overlooked when MirRenderSurface error handling was introduced I suppose
[11:16] <alan_g> Thanks. (I can delete it without screwing up WIP.)
[11:49] <dandrader> anpok, around?
[11:49] <anpok> yes
[11:50] <dandrader> anpok, http://pastebin.ubuntu.com/24214922/
[11:50] <dandrader> anpok, can this input validator alter keyboard modifiers?
[11:50] <dandrader> anpok, eg: add a Ctrl keyboard modifier to a event that originally had none?
[11:55] <anpok> well it did not..
[11:56] <anpok> we changed that bit in lp:mir
[11:56] <anpok> iirc it would only copy the input event modifiers..
[11:59] <greyback> alan_g: hey, qtmir ftbfs against miral 1.3.1: miral/set_command_line_hander.h: No such file or directory
[12:01] <alan_g> greyback: Sorry, a spelling correction: miral/set_command_line_handler.h
[12:01] <greyback> alan_g: yep I know. Just thought you should know, in case you'd consider it an api break
[12:04] <alan_g> greyback: thanks. But as the ABI is unbroken (which I care about more), I'm not too worried.
[12:04] <greyback> ok
[12:04] <dandrader> anpok, I don't get it. can the input validator in the currently released mir add keyboard modifiers to the kdb input event passed to Surface::consume()?
[12:06] <anpok> dandrader: in 0.26 it only affected touch events
[12:06] <anpok> and usually I hope it never did anything at all
[12:08] <dandrader> anpok, I'm puzzled. I'm investigating a bug and currently it seems like qtmir is sending a keyboard event in surface->consume() without modifiers but it's arriving with a modifer on the client side (qtubuntu)
[12:08] <anpok> hm
[12:08] <dandrader> anpok, would that be possible?
[12:08] <anpok> with unity8 every client gets a keymap ..
[12:09] <anpok> that enables client side keystate tracking
[12:10] <dandrader> anpok, hmm, so you mean mir client lib could be adding that?
[12:11] <anpok> so if the client has seen a ctrl key down..
[12:11] <anpok> and never seen a ctrl key up..  xkb common will assume that it is stil down
[12:16] <greyback> alan_g: you missed fixing the typo in set_window_managment_policy.h
[12:18] <alan_g> greyback: are you sure?
[12:18] <alan_g> Rats! you're right
[13:03] <anpok> dandrader: that key state is reset on focus change .. and if you need to filter out events... we could try to add a machinery to trigger the input device state events which would sync clients and the server again
[13:05] <dandrader> anpok, I don't need to filter out events. I need to fix a bug where a client is creating and focusing a new child surface in response to a ctrl+O. once that child surface closes, the top-level surface is stuck with a ctrl modifier until ctrl is pressed+released again
[13:05] <anpok> this is odd
[13:06] <anpok> is there no focus change involved?
[13:06] <anpok> oh hold on the new child is focused and gets focused again?
[13:06] <dandrader> anpok, there are many bugs involved in that use case. in miral (just fixed), in qtmir and unity8.
[13:07] <dandrader> anpok, and now I'm thinking there must be some issue in mir as well. miral just released its fix. will try with that
[13:08] <dandrader> anpok, the new child surface does get focused
[13:08] <dandrader> anpok, once that child window is closed and focuse is assigned back to the top-level surface. it gets a sticky ctrl modifier
[13:09] <dandrader> anpok, even though, afaict, qtmir is sending key events without any modifiers.
[13:09] <dandrader> anpok, will proceed my investigations further and if I can't pinpoint another bug elsewhere will add mir to the bug report
[13:10] <anpok> ok..
[13:11] <anpok> dandrader: MIR_CLIENT_INPUT_RECEIVER_REPORT=log would be helpful