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