[00:13] I just used [00:13] the cursor to click on things in a Qt app [00:13] oO [00:14] :D [00:16] kdub: Any ideas yet for cursor damage [00:20] racarr, got distracted :P [00:20] kdub: np [00:21] one possibility is the compositor sets the damage callback the same way it does now for the Renderables [00:21] on the Display [00:21] and Display exposes some method like [00:21] damage_region [00:24] moving the cursor is so great [00:24] *grin* [00:32] racarr: Cursor damage? You mean, for swcursor? [00:35] RAOF: Yeah! I wrote a sw cursor shell [00:35] it implements the compositing strategy to draw an overlay [00:45] Cool [00:46] RAOF: And I filled out enough of window handle to get pointer events working :) [00:46] clicked on some qt stuff [00:47] Woo! Input you can *see* :) [00:48] I think I will write an acceptance test for pointer events [00:48] then make it pass with the bits from this branch and propose those seperately [00:49] because the sw cursor is in the demo shell which isn't ready to land yet I guess [00:50] or work on damage [00:50] hmm [01:17] :3 [01:41] racarr, what is the point of CachedPtr? [01:49] robert_ancell: Prevent reference cycles (it keeps a weak_ptr) [01:59] The question remains: what is the point of CachedPtr? [02:00] Is it simply a weak_ptr convenience class? [02:18] Basically. [02:19] Hmm, I wonder how well that abstraction makes sense? Haven't used it. But I did encounter a reference cycle problem in surface-states which required weak_ptr [02:25] well it doesnt [02:25] prevent reference cycles in general but it [02:25] allows for each of the components [02:25] of the server configuration [02:25] to have singleton factory methods [02:25] without reference cycle [02:27] Umm, kay. === tvoss is now known as tvoss|exercise === jono is now known as Guest50668 [09:24] Mirrrrrrrrrrrrrrrrr [09:28] rocks? [09:42] rrrrors ? [09:54] OK... Friday nonsense. Must be weekend time... === tvoss|exercise is now known as tvoss [11:35] alf_: where do you think EventSink/Queue belong? [11:40] alan_g: EventSink is used all over the place (and both in server and client), so I think that the current placement is OK [11:40] alan_g: EventQueue is currently a detail in frontend, so I would be inclined to place it there (and don't expose it) [11:40] alan_g: to other modules yet [11:42] alf_: that sounds right to me too [11:44] although I think namespace mir should be uncluttered [11:44] alan_g: so create e.g. mir::event ? [11:45] alf_: perhaps. Not a blocker just now though. === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g === Saviq is now known as Saviq|mtg === olli__ is now known as olli === Saviq|mtg is now known as Saviq [15:03] hello all! status, a few branches in the air to remove the 3rd_party/android-fbtype directory, to upgrade to raring. working on hwc1.0 vsync support today [15:05] kdub: hello one! [15:05] status: reviewing and refactoring [15:15] status: iterating MPs, working on/proposed pause-communicator MP [16:18] Morning [16:19] morning racarr [16:19] hmm, no android classes on doxygen? [16:19] Afternoon all === alan_g is now known as alan_g|EOW === yofel_ is now known as yofel [18:51] racarr, ping [20:20] bschaefer: Pong [20:20] racarr, hello! [20:20] bschaefer: Hey! How goes? [20:20] Just got back from lunch :) [20:21] racarr, good! How about yourself :) [20:21] Excellent! [20:21] awesome, soo I've some questions about mir input :) [20:21] Ok! Shoot [20:22] im working on porting Mir to SDL atm, but looking at setting up : mir_surface_set_event_handler [20:22] ok [20:22] which isn't working atm, as it seems to be using the android platform? [20:22] no its just the android [20:22] input stack [20:22] its a little misleading [20:22] also the egl apps don't seem to be working with input either :( [20:22] as it stands input in trunk ... at least for key! You should be able to get some events [20:22] you need --enable-input=true [20:22] and permissions on /dev/input/* [20:23] Can you try with both of those? [20:23] right, I had to do that for umm the eglapp and got this problem [20:23] http://paste.ubuntu.com/5722394/ [20:23] there doesn't seem to be focus? [20:24] bschaefer: Ah! [20:24] input was briefly broken in trunk [20:24] https://code.launchpad.net/~robertcarr/mir/fix-1170524/+merge/159743 [20:24] do you have this revision? [20:24] racarr, oo nice, I havn't updated today! [20:24] * bschaefer checks [20:24] im at rev 606 :), let me try that out! [20:25] also, so the basic idea for input in Mir, is to set up an event callback, and let the app filter out the events? [20:33] bschaefer: Yes. I mean the app only gets events intended for it [20:33] racarr, awesome, sounds very easy :) [20:33] bschaefer: Yes. The thing to remember is event callback [20:33] will be invoked from a seperate thread [20:33] so you have to [20:34] well. synchronize somehow [20:34] oo, so pump/flush the fd? [20:34] for the surface [20:35] or wait until its received an event ... there was mir_wait but that was for something else :) [20:36] bschaefer: The input is on a seperate fd that is all managed internally [20:36] so once you create the surface [20:36] there is a thread which polls on that fd [20:36] and dispatches events to your callback once they arrive [20:36] I just mean [20:36] whatever object in SDL you are giving the events to [20:36] needs to be prepared to be used from another thread [20:36] or you have to lock it yourself [20:37] racarr, ooo, alright Ill have to keep that in mind [20:37] Excited to see SDL on Mir :) [20:37] cause, im just starting on the input side of things, as I already have opengles v 1/2 running fine :) [20:37] * bschaefer digs up a screenshot [20:37] In my ~1 week ahead of trunk branch we have a software cursor and [20:37] pointer events to apps [20:37] racarr, http://i.imgur.com/D591bOX.jpg [20:37] so will be fun to play with a fully functioning toolkit [20:37] awesome! [20:37] QtUbuntu stll has some quirks [20:38] whereas I imagine SDL [20:38] yeah, I saw you getting it working yesterday [20:38] well should just work [20:38] mwahaha smileys [20:38] :) [20:38] 1500 [20:40] racarr, right, all I think I should have to do, is receive an event from mir, figure out mouse/keyboard and tell SDL we have received a specific event [20:40] * bschaefer hopes its that easy [20:41] also sweet, receiving events in egl apps now :) [21:08] yay :) [21:09] bschaefer: The keycodes in [21:09] MirEvent are xkbcommon keysyms so you can probably even copy paste [21:09] a big event translation table from somewhere [21:09] if its needed [21:09] racarr, right, yeah thats how wayland was doing it [21:09] dont know thatmuch about SDL [21:09] mm [21:10] neither do i :) [21:10] well more now [21:10] :) [21:33] is it just me, or does g++ ICE all the time? [21:36] kdub: All the time [21:39] i.e. its not just you [21:39] its mostly around std::make_shared [21:40] racarr: only if you don't pass the right parameters ;) [21:47] haha [21:47] alan is funny at night [22:45] mer its difficult to acceptance test motion events due to the event batching behavior [23:12] whoohoo, hwc 1.0 was much easier to get going :) [23:12] now that all my android factories are set up