| 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:14 |
| racarr_ | (its difficult because im using the BufferWriter strategy...now BufferAccessor...) this seems to be an argument for buffer::read :) | 00:15 |
| RAOF | I don't think that you can, in general, read from a Buffer. | 00:16 |
| RAOF | Heh. You live and learn. | 00:18 |
| RAOF | Also, whoops. 10⁶ ns in 1 ms. | 00:23 |
| racarr_ | NO EXPONENTS IN IRC | 00:25 |
| racarr_ | *smacks with ruler* | 00:25 |
| racarr_ | wheee | 00:26 |
| racarr_ | animted cursor :) | 00:27 |
| RAOF | Whoot! | 00:38 |
| racarr_ | *sends application to guiness book of world records* | 00:47 |
| racarr_ | Most banjos restringed during full mir compile: 1.5 | 00:47 |
| racarr_ | I await my challenger | 00:57 |
| RAOF | I wonder how much people would care if we added a glib dependency in Mir users. | 01:00 |
| RAOF | It'd be kinda nice to be returning GSource-s rather than needing to re-roll the same thing over again. | 01:01 |
| racarr_ | RAOF: I'd +1 that | 01:04 |
| 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. | 01:05 |
| duflu | RAOF: What's glib being used for now? | 02:00 |
| RAOF | duflu: GLibMainLoop | 02:01 |
| duflu | RAOF: That's old news(?) | 02:01 |
| RAOF | Oh, as in - what do *I* want to use it for? | 02:02 |
| RAOF | GSource | 02:02 |
| duflu | I'd forgotten how quickly things land without CI :) | 03:19 |
| duflu | The good old days of living dangerously | 03:19 |
| === chihchun_afk is now known as chihchun | ||
| RAOF | Man. | 06:51 |
| RAOF | *Again* I confuse nsec with msec. | 06:51 |
| racarr_ | y u no std::chrono | 06:56 |
| racarr_ | (C API presumably :() | 06:56 |
| RAOF | Oh, well. That's EOW for me. | 07:06 |
| RAOF | mircva::InputReceiver is *very nearly* a functioning GSource. | 07:06 |
| racarr_ | nifty | 07:07 |
| RAOF | GSource is pretty cool. | 07:07 |
| RAOF | For the eventloop integration thing I think I'll just export GSources directly via libmirclient-glib. | 07:08 |
| RAOF | But anyway, EOW. | 07:08 |
| racarr_ | bye :) happy weekend | 07:16 |
| mlankhorst | RAOF: can i use it in xmir too? | 07:21 |
| === dandrader is now known as dandrader|afk | ||
| tsdgeos | anpok_: racarr_: ping? | 12:12 |
| 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:13 |
| === dandrader|afk is now known as dandrader | ||
| 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:15 |
| 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:16 |
| tsdgeos | but i need unity8 to run so i can run autopilot so probably mir_demo_standalone_input_filter is not seful | 12:17 |
| * alan_g doesn't know (but thinks you asked the right people) | 12:18 | |
| 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:30 |
| 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:31 |
| tsdgeos | anpok_: do i just kill and start it? or is it driven by upstart too? | 12:32 |
| anpok_ | hm restart lightdm should do it | 12:33 |
| tsdgeos | oki | 12:33 |
| anpok_ | oh InputReport might not be helpful enough | 12:34 |
| tsdgeos | oh :/ | 12:36 |
| 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:37 |
| 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:38 |
| 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:45 |
| 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! | 12:46 |
| === 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 | ||
| 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? | 14:55 |
| === chihchun is now known as chihchun_afk | ||
| 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:03 |
| alan_g | Indeed. But I'm not sure GraphicBufferAllocator is the interface that should be exposed to support this? | 15:06 |
| alf__ | alan_g: just the_supported_pixel_formats() ? | 15:07 |
| alan_g | Well, that's all we need for render_surfaces and I can't currently see an interface it belongs on. | 15:08 |
| alan_g | I'm just not sure mir::Server::supported_pixel_formats() is right | 15:10 |
| === dandrader|lunch is now known as dandrader | ||
| * alan_g wonders if we should "republish" mir/raii.h | 16:31 | |
| === alan_g is now known as alan_g|EOW | ||
| attente_ | hello, does mir support pointer/keyboard grabbing? | 20:23 |
| anpok | hm a shell could do that on its own already, but no there is no such thing yet in the client api | 20:27 |
| attente_ | anpok: is there any plan to add it to the client api? | 20:46 |
| anpok | attente_: no idea when... or how urgent that is.. best is to make a bug report to rise attention | 21:07 |
| attente_ | anpok: ok, thanks | 21:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!