[01:45] bschaefer: Your SDL 2.0 work, that's not in archive is it? [01:46] duflu, the one in archive will work for the desktop [01:46] you'll need the one in mir staging for the phone [01:47] bschaefer: Oh, trusty or just utopic? [01:47] there was an issue with arm i need to get patch in archive :( [01:47] duflu, utopic [01:47] i dont think the trusty one built [01:47] bschaefer: Ah. No wonder it wasn't linked to Mir :) [01:47] o looks like it did [01:47] duflu, it has a nice dynamic linking, so no hard depends :) [01:48] but i suppose you need so to compile [01:48] bschaefer: That's the right answer. Although it's so rare these days I always don't expect it :) [01:48] * bschaefer wrote the debain file and has forgotten [01:48] duflu, :) [01:48] *almost [01:48] duflu, i didn't know about until Rayn, one of the devs mentioned it [01:48] and did that work [01:48] it was pretty cool [01:52] bschaefer: How's the input support? [01:52] Pretty much complete (as much as Mir allows you to)? [01:59] * RAOF hides [02:13] duflu, yeah [02:13] duflu, and yeah i need to re-confirm that bug [02:14] duflu, o thanks for re-opening it :) [02:17] also turns out mir does shaped windows server side, but allows for rect region windows [02:17] sooo i need to implement that as well [02:18] bschaefer: I've just started modifying that stuff. But if you mean windows with an alpha channel, yet that works now: mir_demo_client_egltriangle -b 0 [02:18] -yet +yeah [02:24] sweet! I don't know much about shape windows them selfs [02:24] just saw it in SDL and know i've to support it [02:24] i think its using alpha channels [02:25] as it takes a bitmap [02:25] (for its example) [02:25] bschaefer: It *just works* (tm) [02:25] :) [02:25] it looks cool on x11, so it would be nice to support it haha [02:25] Although demo-shell is naive and will put a rectangular shadow around your shaped app :P [02:26] thats good to know [02:26] vs freaking out [07:00] RAOF: Oh, no more inline comments check box in reviews [07:51] To the EOW! [07:56] Hello, I have an issue with MIR + a touch-screen [07:56] I run the app both on x86 (Desktop) and ARM (tablet) [07:57] In some condition I dont get the TouchEvent "UP" from my 2nd finger [07:58] The test-case is : Put Finger-1 Down, F2-Down, F2-Up, F1-Up => it looks like Mir sends only one Up [07:59] I have already talk about this with some mir-developer .. (I think they are sleeping now) [07:59] Has anyone an idea to debug this ? [07:59] (I know how to compile lp:mir, I have already put some debug trace on, and inside code ...) [08:04] slvn_: that might be speculation, maybe you get the up events in a single event? [08:06] slvn_: what is the result of mir_event.motion.action & 0xff00 when you only get a single up event? [08:06] anpok, how could I check that ? here's some part of the *application* code -> https://hg.libsdl.org/SDL/file/3e2b3019a879/src/video/mir/SDL_mirevents.c === Stskeepz is now known as Stskeeps [08:06] alan_g: seems like my mp failed because of timing issues in the asio alarm test fixture \o/ [08:07] anpok, I will check [08:07] slvn_: we borrowed some ugliness from the android input stack [08:08] and that is up and down events for pointers/finger may be encoded in a single event, and the state change is stored in the action value [08:08] anpok, yep I understand, I check that :) [08:08] seems like line 167 in the file need to handle that [08:08] k [08:12] asio does not allow replacing the timer scheduler during runtime or as an io_service configuration.. so one way to eliminate real timing could be to not use asios deadline_timer but write a timer service that behaves exactly like it, but uses an abstract scheduler interface. [08:13] hmm [08:14] somehow.. === yofel_ is now known as yofel [08:14] anpok, ... before starting the whole compilation stuff. A question : mir_event.motion.action is defined in : /usr/include/mircommon/mir_toolkit/event.h, and it goes from 0 to 10. so the mir_event.motion.action & 0xff00 does not make sense ? [08:15] well i would like agree to that.. [08:16] if ( mir_event.motion.action & 0xff00 ) == 0, that would be a mir_motion_action_down << 8 [08:16] but il will check [08:17] slvn_: hm ok I was wrong you have to get two up events [08:20] slvn_: the android input stack stores the index of the pointer that goes up /down in that part of the action variable [08:20] I believe to stay somewhat compatible that part was kept.. [08:20] slvn_: so i guess you run in the default case when you get the second up event [08:20] for the first up event you will get (pointer index 0 << 0xff) | mir_motion_action_up as action [08:21] and for the second up event you will get (1 <<0xff)| mir_motion_action_up [08:21] but it depends on the order of finger releasing [08:21] so yeah what you observe makes sense given the mir event handling code [08:22] I enter the default case with action = 0x105 and 0x106 [08:22] anpok, yep, the order of finger releasing has also a very strange impact ! [08:23] because the value stored is not the finger id but the index in the attached pointer_coordinates array [08:23] 105 / 106 is mir_motion_action_up = 1, mir_motion_action_pointer_down = 5, mir_motion_action_pointer_up = 6, [08:25] anpok, so basically : I should do switch ( action & 0xff) to strip the finger id ? [08:25] not the finger id but the pointer_coordinates index.. [08:26] and you have to read the pointer coordinate index to pass the right id to the HandleTouchPress function.. [08:26] i believe the other not mentioned index can be treated as a touch motion [08:28] alan_g: we would need something similar to that - written against a mockable interface: http://www.boost.org/doc/libs/1_55_0/boost/asio/deadline_timer.hpp [08:28] :) [08:28] wrong file [08:29] that one http://www.boost.org/doc/libs/1_55_0/boost/asio/detail/deadline_timer_service.hpp [08:31] anpok: I've not yet had time to look at your MP or why it failed. So I'm lacking context to make meaningful comment. [08:33] ok the AsioMainLoopAlarmTest.main_loop_runs_unti_stop_called does wait for 10 ms for the ml thread to start and to execute a 0 ms timeout [08:34] tests that rely on sleep/wait are broken [08:37] anpok, line 228 and 231 : I could replace the "cord_index" by : (motion.action >> 8) [08:42] yes - but you only get meaning full values if you are handling action&0ff = mir_motion_action_pointer_{up,down} [08:44] alf_: hey, question on the MultiThreadedCompositor: how does it manage to switch between using the DisplayBufferCompositingFunctor and the BufferConsumingFunctor during runtime? [08:44] I don't see where the decision to use one over the other occurs [08:45] greyback: They both run in parallel, but you shouldn't concern yourself with that, it will soon be removed and the task of consuming frames will be done at a lower level [08:49] anpok : yes, I also changed switch (motion.action & 0xff) line 169, and 193 [08:49] anpok: now it's much better for Up/Down event [08:51] alf_: okay. Different hypothetical question: say I wrote a naughty server using Mir, which uses its own compositing loop instead of Mir's. While running as a nested server, when the display is blanked, and it tries to render, a exception is thrown inside Mir: "error during hwc prepare(). rc = ffffffff" [08:51] sounds very hypothetical [08:52] :) [08:52] alf_: aside from telling to not be naughty (am working on it), what avenue would you suspect? [08:56] greyback: hmm, strange, the nested server shouldn't touch the screen at all... Plus, for the host server, when the screen is blanked we normally don't even a expose a display buffer for that screen. [08:57] greyback: is the exception thrown from the host mir or from your qt-compositor nested mir? [09:01] anpok, something is still weird, I still need a little help. This is only 1 "motion.action" but a table of pointer_coordinates[pointer_count] [09:03] Why I'm surprised is that it's running as nested server, so I expected it to be free to render as much as it wantede while the display was blanked, as the system server would consume those buffers [09:04] alf_: good question, lemme see [09:05] slvn_: i believe the other pointers do not change up/down state but are just provided because they might contain moves moves - but not really sure [09:05] -moves [09:06] I have to dig more into InputDispatcher to see when that happens [09:09] anpok. I think (not checked) there are different "motion.pointer_coordinates[cord_index].id". So If I choose cord_index==action>>8. I fix the .id [09:09] and then, I get only motion event from 1 finger [09:10] if I only do : "switch (motion.action & 0xff) {" and discard the 0xff00, all work fine [09:11] basically, If it would have been "motion.action & 0xff" from scratch in SDL code, I would have not noticed the bug [09:11] duflu: Are you working on the cleanup on sigabort etc? If not, I can pick it up. [09:12] duflu: alan_g: I am thinking of adding a mg::Platform::emergency_cleanup() method to do a best effort cleanup in fatal signal situations [09:14] alf_: reasonable. The alternative design is a registration facility (like atexit()). [09:19] alan_g: Like, e.g., EmergencyCleanupRegistrar::register_cleanup(...) mg::create_platform(...,std::shared_ptr const& r) ? [09:19] anpok: if (action & 0xff == cord_index) then real_action=action&0xff else real_action = motion [09:20] Or EmergencyCleanupRegistrar const& r [09:21] alan_g: it depends on whether a platform needs to do clean-up for created display though... unless we also add this to Platform::create_display() [09:21] Hmm. It is also possible to install signal handlers in the "platform" [09:22] anpok : this patch is working perfectly ! http://pastebin.com/PB7FTvkk [09:22] anpok this is what you said first I think! [09:24] alf_: I don't see why it depends. The are equivalent with: r.register([this]{ emegency_cleanup(); }); [09:25] slvn_: ah that function is called for every pointer? [09:25] then yes looks good! [09:26] anpok with the pointer_cound, but only one action for all ! [09:27] I cannot use the same action for all, because otherwise I have weird up/down event that appears [09:27] F1 Down F2 Down F1 Up F2 Up -> down down up up Up Down [09:28] alan_g: I meant the comment for using a shared_ptr vs a reference to pass the registrar [09:28] ok ... I send this patch to bschaefer and also racarr__ because there were implicated [09:28] thanks anpok for the help ! [09:30] alf_: I got that. Your original mg::Platform::emergency_cleanup() code didn't need it. And neither does r.register([this]{ emegency_cleanup(); }); [09:36] anpok, anyway, is there a way to see why the cord_index is encoded into the "action" and also, when there are several pointer count, why by default this should be a motion action [09:36] alan_g: Sure, but neither handle the case where the individual displays need cleanup, *without* the platform having a mediating role in that. Anyway, at least for mesa there isn't such a need anyway. [09:38] bbiab [09:40] alf_: OK. I don't (currently) see a strong reason for preferring any of the three approaches. [09:40] Well four if you consider rev vs sp different [09:40] *ref [09:40] anpok : curiously : fingerpaint.c has : MirMotionAction masked_action = event->motion.action & ~0xff00; // FIXME: https://bugs.launchpad.net/mir/+bug/1197108 [09:40] Ubuntu bug 1197108 in Mir "Input action fields no longer maintain compatibility with surfaceflinger" [Medium,Fix released] [09:43] slvn_: the encoding happens in InputReader of the android input code (TouchMapper is the class) [09:54] alf_: Oops, sorry. No not working on it at all (https://bugs.launchpad.net/bugs/1320114) [09:54] Ubuntu bug 1320114 in Mir "[DRM/GBM] Crashing Mir (via fatal signal) often leaves the screen blank and difficult to recover" [Medium,Triaged] [10:03] anpok, the patch is not working. It works better, but sometime I miss a UP event (miss== I dont detect?) [10:21] slvn_: oh sorry did not look at the patch properly [10:28] slvn_: http://pastebin.com/fy97wgEJ [10:32] anpok, okay.... I found some stuff ! MIR is sending me : action=0x101 but only pointer_counter=1 !!!! [10:32] so I never do something with this event ! [10:36] anpok, action=0x101 means the UP event should be applied to the cord_index=1, but the pointer_count==1 mean there is only 1 element in the table, only 1 cord_index (of value=0) [10:39] anpok, ... that's fully fix my issue now ! and it appears several time [10:39] if (motion.pointer_count == 1 && (motion.action >> 8) != 0) [10:39] motion.action &= 0xff; [10:48] oh i assumed it only happens for pointer_up,down and not for all kinds of up and down events.. === seb128_ is now known as seb128 [11:50] Everybody, does the MirMotionEvent struct makes sense to anyone ?? MIR sends me sometimes with "motion.action=0x101" (cord_index=1 + action_up) and "pointer_counter=1" => so the only cord_index available 0 ! Is this a Bug ? === alan_g is now known as alan_g|lunch [12:17] the code in [12:18] wrong terminal [12:18] slvn_: looks like a bug [12:26] anpok, ok, maybe I should double-check with latest version of MIR ? (I am using lp:mir Tree is up to date at revision 1186) === alan_g|lunch is now known as alan_g === ted is now known as tedg === alan_g is now known as alan_g|tea === jono is now known as Guest91026 === ValicekB_ is now known as ValicekB === tedg is now known as ted [16:18] hey there [16:19] is Mir supposed to work on any intel hardware? [16:19] it doesn't seem to run on the Dell mini 10v (that's an old atom based machine with an intel 950 video card) [16:21] seb128, I use a i965 for mir work [16:22] I had EGL errors/assertions in the unity8-mir log [16:22] need to boot again and share them [16:22] I guess my current description lacks details [16:43] seb128: Ive heard rumors about i915 issues I think [16:43] the ollld ones [16:43] oh 950 [16:43] who knows ;) === alan_g|tea is now known as alan_g === dandrader is now known as dandrader|lunch === alan_g is now known as alan_g|EOW [17:05] racarr__, it might be i915 or 945, the 950 came from some googling, but didrocks pointed out that it was probably not right [17:09] yeah, it's i195 [17:15] the error it gives is "ASSERT: "(eglContext_ = eglCreateContext( eglDisplay_, screen->eglConfig(), share ? share->eglContext() : EGL_NO_CONTEXT, attribus.constData())) != EGL_NO_CONTEXT" in file ../../../../src/platforms/base.context.cc, line 63 [17:16] (I hope I didn't do typos, I don't have an easy way to copy the log from the machine) [17:16] that's in unity8-mir.log [17:42] seb128: Ok I think there is something [17:43] with i915, i.e. the mesa driver doesnt support the DRI2 apis or [17:43] *not entirely sure* [17:43] all I know for sure is that duflu knows [17:43] ok [17:43] "known issue" then ;-) [17:43] let me know if I should report it [17:44] what's the difference between libmir*-mesa & libmir*-android packages? [17:44] kgunn: ^ Do you remember? i915 intel mesa...doesn't work? === dandrader|lunch is now known as dandrader [17:45] xnox: libmir-mesa uses MEsa EGL, GBM, kernel drm (direct rendering manager) modesetting, etc [17:45] racarr__: why would i want that installed on ubuntu-touch? [17:45] libmir-android uses android graphics drivers, android EGL, gralloc, hardware composer [17:45] Id ont think you would lol [17:45] yeah, you wouldn't [17:45] racarr__: lolz, we do at the moment =) [17:45] no wonder ubuntu-touch image is 1.4 GB big with LLVM et al [17:46] unless you're ambitious and want the freedreno stuff? (uncharted waters) [17:46] xnox: Yeah...last I checked [17:46] I believe we end up pulling [17:46] significant parts of X + [17:46] both libegls, etc. [17:46] I think there are some eird dependencies in mesa [17:46] but ive never dug down [18:07] racarr__: right, as i recall from duflu, dri2 never added support for i915 [18:40] kgunn: Ok. No bug needed from seb then :) === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader