[00:14] ah hmm...it's difficult to write to a buffer you get on the server side via compositor_acquire because you get [00:14] the temporary compositor buffer and can't [00:14] cast to the platform implementation type... [00:15] (its difficult because im using the BufferWriter strategy...now BufferAccessor...) this seems to be an argument for buffer::read :) [00:16] I don't think that you can, in general, read from a Buffer. [00:18] Heh. You live and learn. [00:23] Also, whoops. 10⁶ ns in 1 ms. [00:25] NO EXPONENTS IN IRC [00:25] *smacks with ruler* [00:26] wheee [00:27] animted cursor :) [00:38] Whoot! [00:47] *sends application to guiness book of world records* [00:47] Most banjos restringed during full mir compile: 1.5 [00:57] I await my challenger [01:00] I wonder how much people would care if we added a glib dependency in Mir users. [01:01] It'd be kinda nice to be returning GSource-s rather than needing to re-roll the same thing over again. [01:04] RAOF: I'd +1 that [01:05] but in my mind GLib is effectively libc ;) [01:05] Well, we already have a runtime dependency on glib... [01:05] Hm. [01:05] I think I will do that. [02:00] RAOF: What's glib being used for now? [02:01] duflu: GLibMainLoop [02:01] RAOF: That's old news(?) [02:02] Oh, as in - what do *I* want to use it for? [02:02] GSource [03:19] I'd forgotten how quickly things land without CI :) [03:19] The good old days of living dangerously === chihchun_afk is now known as chihchun [06:51] Man. [06:51] *Again* I confuse nsec with msec. [06:56] y u no std::chrono [06:56] (C API presumably :() [07:06] Oh, well. That's EOW for me. [07:06] mircva::InputReceiver is *very nearly* a functioning GSource. [07:07] nifty [07:07] GSource is pretty cool. [07:08] For the eventloop integration thing I think I'll just export GSources directly via libmirclient-glib. [07:08] But anyway, EOW. [07:16] bye :) happy weekend [07:21] RAOF: can i use it in xmir too? === dandrader is now known as dandrader|afk [12:12] anpok_: racarr_: ping? [12:13] or anyone else, is there a way to get the log of the raw x,y of the touch presses mir gets? [12:13] i tried exporting MIR_SERVER_INPUT_REPORT=log [12:13] but the only thing i get is [12:13] [1417781333.496738] (II) input: Received event finished seq_id=102 src_fd=89 [12:13] which isn't much interesting === dandrader|afk is now known as dandrader [12:15] tsdgeos: is mir_demo_standalone_input_filter of any use (despite its name it is a demo *server* that dumps input events) [12:16] alan_g: probably not, i have a situation with autopilot+unity8 in which i think some touch events are being delivered wrong somewhere [12:17] but i need unity8 to run so i can run autopilot so probably mir_demo_standalone_input_filter is not seful [12:18] * alan_g doesn't know (but thinks you asked the right people) [12:30] tsdgeos: hm did you export that for usc? [12:30] because unity8 is nested [12:30] anpok_: ok, let me see if i restart usc then [12:30] and the input gets fed directly from the nested surface to the qt input dispatcher and I think it wont be logging its contents.. [12:31] anpok_: where do usc logs end up? [12:31] it ought to end up in /var/log/lightdm/unity-system-compositor.log [12:32] anpok_: do i just kill and start it? or is it driven by upstart too? [12:33] hm restart lightdm should do it [12:33] oki [12:34] oh InputReport might not be helpful enough [12:36] oh :/ [12:37] anpok_: @"not helpful" the interface or the default implementation? (I'm looking for motivating examples for allowing customizing the reports and we should try to get the interfaces right) [12:37] alan_g: hm i think the interface here.. it does not get the position [12:37] i believe we log it somewhere else [12:38] through the legacy input report [12:38] anpok_: do you know the lower place i could put a printf of the x,y positions? [12:38] to see if it's mir or wathever is below? [12:38] is that android already? [12:38] we have that.. hmm but where [12:45] tsdgeos: MIR_CLIENT_INPUT_RECEIVER_REPORT=log for unity8 [12:45] ok, let's see [12:45] this would be what unity8 receives from usc [12:46] and you can basically do the same for a client of unity8 to see how that event got dispatched to it.. [12:46] food first! === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g === dandrader is now known as dandrader|lunch [14:55] alf__: I've been looking at migrating render_surfaces (mostly out of curiosity to see what stops it being a valid example). There's just one nasty: "surface_pf = the_buffer_allocator()->supported_pixel_formats()[0];" as we don't expose the buffer allocator. Can you think of a better way to get a valid pixel format? === chihchun is now known as chihchun_afk [15:03] alan_g: No. Perhaps this indicates a gap in the new API, since without a pixel format the shell can't create its own surfaces. [15:06] Indeed. But I'm not sure GraphicBufferAllocator is the interface that should be exposed to support this? [15:07] alan_g: just the_supported_pixel_formats() ? [15:08] Well, that's all we need for render_surfaces and I can't currently see an interface it belongs on. [15:10] I'm just not sure mir::Server::supported_pixel_formats() is right === dandrader|lunch is now known as dandrader [16:31] * alan_g wonders if we should "republish" mir/raii.h === alan_g is now known as alan_g|EOW [20:23] hello, does mir support pointer/keyboard grabbing? [20:27] hm a shell could do that on its own already, but no there is no such thing yet in the client api [20:46] anpok: is there any plan to add it to the client api? [21:07] attente_: no idea when... or how urgent that is.. best is to make a bug report to rise attention [21:08] anpok: ok, thanks