[01:45] <duflu> bschaefer: Your SDL 2.0 work, that's not in archive is it?
[01:46] <bschaefer> duflu, the one in archive will work for the desktop
[01:46] <bschaefer> you'll need the one in mir staging for the phone
[01:47] <duflu> bschaefer: Oh, trusty or just utopic?
[01:47] <bschaefer> there was an issue with arm i need to get patch in archive :(
[01:47] <bschaefer> duflu, utopic
[01:47] <bschaefer> i dont think the trusty one built
[01:47] <duflu> bschaefer: Ah. No wonder it wasn't linked to Mir :)
[01:47] <bschaefer> o looks like it did
[01:47] <bschaefer> duflu, it has a nice dynamic linking, so no hard depends :)
[01:48] <bschaefer> but i suppose you need so to compile
[01:48] <duflu> 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] <bschaefer> duflu, :)
[01:48] <duflu> *almost
[01:48] <bschaefer> duflu, i didn't know about until Rayn, one of the devs mentioned it
[01:48] <bschaefer> and did that work
[01:48] <bschaefer> it was pretty cool
[01:52] <duflu> bschaefer: How's the input support?
[01:52] <duflu> Pretty much complete (as much as Mir allows you to)?
[01:59]  * RAOF hides
[02:13] <bschaefer> duflu, yeah
[02:13] <bschaefer> duflu, and yeah i need to re-confirm that bug
[02:14] <bschaefer> duflu, o thanks for re-opening it :)
[02:17] <bschaefer> also turns out mir does shaped windows server side, but allows for rect region windows
[02:17] <bschaefer> sooo i need to implement that as well
[02:18] <duflu> 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] <duflu> -yet +yeah
[02:24] <bschaefer> sweet! I don't know much about shape windows them selfs
[02:24] <bschaefer> just saw it in SDL and know i've to support it
[02:24] <bschaefer> i think its using alpha channels
[02:25] <bschaefer> as it takes a bitmap
[02:25] <bschaefer> (for its example)
[02:25] <duflu> bschaefer: It *just works* (tm)
[02:25] <bschaefer> :)
[02:25] <bschaefer> it looks cool on x11, so it would be nice to support it haha
[02:25] <duflu> Although demo-shell is naive and will put a rectangular shadow around your shaped app :P
[02:26] <bschaefer> thats good to know
[02:26] <bschaefer> vs freaking out
[07:00] <duflu> RAOF: Oh, no more inline comments check box in reviews
[07:51] <RAOF> To the EOW!
[07:56] <slvn_> Hello, I have an issue with MIR + a touch-screen
[07:56] <slvn_> I run the app both on x86 (Desktop) and ARM (tablet)
[07:57] <slvn_> In some condition I dont get the TouchEvent "UP" from my 2nd finger
[07:58] <slvn_> The test-case is :  Put Finger-1 Down, F2-Down,  F2-Up, F1-Up   => it looks like Mir sends only one Up
[07:59] <slvn_> I have already talk about this with some mir-developer .. (I think they are sleeping now)
[07:59] <slvn_> Has anyone  an idea to debug this ?
[07:59] <slvn_> (I know how to compile lp:mir, I have already put some debug trace on, and inside code ...)
[08:04] <anpok> slvn_: that might be speculation, maybe you get the up events in a single event?
[08:06] <anpok> slvn_: what is the result of  mir_event.motion.action & 0xff00 when you only get a single up event?
[08:06] <slvn_> 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
[08:06] <anpok> alan_g: seems like my mp failed because of timing issues in the asio alarm test fixture \o/
[08:07] <slvn_> anpok, I will check
[08:07] <anpok> slvn_: we borrowed some ugliness from the android input stack
[08:08] <anpok> 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] <slvn_> anpok, yep I understand, I check that :)
[08:08] <anpok> seems like line 167 in the file need to handle that
[08:08] <anpok> k
[08:12] <anpok> 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] <alan_g> hmm
[08:14] <anpok> somehow..
[08:14] <slvn_> 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] <anpok> well i would like agree to that..
[08:16] <slvn_> if ( mir_event.motion.action & 0xff00 ) == 0, that would be a mir_motion_action_down << 8
[08:16] <slvn_> but il will check
[08:17] <anpok> slvn_: hm ok I was wrong you have to get two up events
[08:20] <anpok> slvn_: the android input stack stores the index of the pointer that goes up /down in that part of the action variable
[08:20] <anpok> I believe to stay somewhat compatible that part was kept..
[08:20] <anpok> slvn_: so i guess you run in the default case when you get the second up event
[08:20] <anpok> for the first up event you will get (pointer index 0 << 0xff) | mir_motion_action_up as action
[08:21] <anpok> and for the second up event you will get (1 <<0xff)| mir_motion_action_up
[08:21] <anpok> but it depends on the order of finger releasing
[08:21] <anpok> so yeah what you observe makes sense given the mir event handling code
[08:22] <slvn_>  I enter the default case with action =  0x105 and 0x106
[08:22] <slvn_> anpok, yep, the order of finger releasing has also a very strange impact !
[08:23] <anpok> because the value stored is not the finger id but the index in the attached pointer_coordinates array
[08:23] <slvn_> 105 / 106 is   mir_motion_action_up           = 1,     mir_motion_action_pointer_down = 5,   mir_motion_action_pointer_up   = 6,
[08:25] <slvn_> anpok, so basically : I should do switch ( action & 0xff)          to strip the finger id ?
[08:25] <anpok> not the finger id but the pointer_coordinates index..
[08:26] <anpok> and you have to read the pointer coordinate index to pass the right id to the HandleTouchPress function..
[08:26] <anpok> i believe the other not mentioned index can be treated as a touch motion
[08:28] <anpok> 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] <anpok> :)
[08:28] <anpok> wrong file
[08:29] <anpok> that one http://www.boost.org/doc/libs/1_55_0/boost/asio/detail/deadline_timer_service.hpp
[08:31] <alan_g> 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] <anpok> 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] <alan_g> tests that rely on sleep/wait are broken
[08:37] <slvn_> anpok, line 228 and 231 : I could replace the "cord_index" by :   (motion.action >> 8)
[08:42] <anpok> yes - but you only get meaning full values if you are handling action&0ff = mir_motion_action_pointer_{up,down}
[08:44] <greyback> alf_: hey, question on the MultiThreadedCompositor: how does it manage to switch between using the DisplayBufferCompositingFunctor and the BufferConsumingFunctor during runtime?
[08:44] <greyback> I don't see where the decision to use one over the other occurs
[08:45] <alf_> 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] <slvn_> anpok : yes, I also changed switch (motion.action & 0xff) line  169, and 193
[08:49] <slvn_> anpok:  now it's much better for Up/Down event
[08:51] <greyback> 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] <anpok> sounds very hypothetical
[08:52] <greyback> :)
[08:52] <greyback> alf_: aside from telling to not be naughty (am working on it), what avenue would you suspect?
[08:56] <alf_> 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] <alf_> greyback: is the exception thrown from the host mir or from your qt-compositor nested mir?
[09:01] <slvn_> 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] <greyback> 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] <greyback> alf_: good question, lemme see
[09:05] <anpok> 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] <anpok> -moves
[09:06] <anpok> I have to dig more into InputDispatcher to see when that happens
[09:09] <slvn_> 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] <slvn_> and then, I get only motion event from 1 finger
[09:10] <slvn_> if I only do : "switch (motion.action & 0xff) {" and discard the 0xff00, all work fine
[09:11] <slvn_> basically, If it would have been "motion.action & 0xff" from scratch in SDL code, I would have not noticed the bug
[09:11] <alf_> duflu: Are you working on the cleanup on sigabort etc? If not, I can pick it up.
[09:12] <alf_> 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] <alan_g> alf_: reasonable. The alternative design is a registration facility (like atexit()).
[09:19] <alf_> alan_g: Like, e.g., EmergencyCleanupRegistrar::register_cleanup(...) mg::create_platform(...,std::shared_ptr<EmergencyCleanupRegistrar> const& r) ?
[09:19] <slvn_> anpok:  if (action & 0xff == cord_index) then real_action=action&0xff else real_action = motion
[09:20] <alan_g> Or EmergencyCleanupRegistrar const& r
[09:21] <alf_> 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] <alan_g> Hmm. It is also possible to install signal handlers in the "platform"
[09:22] <slvn_> anpok : this patch is working perfectly ! http://pastebin.com/PB7FTvkk
[09:22] <slvn_> anpok this is what you said first I think!
[09:24] <alan_g> alf_: I don't see why it depends. The are equivalent with: r.register([this]{ emegency_cleanup(); });
[09:25] <anpok> slvn_: ah that function is called for every pointer?
[09:25] <anpok> then yes looks good!
[09:26] <slvn_> anpok with the pointer_cound, but only one action for all !
[09:27] <slvn_> I cannot use the same action for all, because otherwise I have weird up/down event that appears
[09:27] <slvn_> F1 Down F2 Down F1 Up F2 Up ->  down down up up Up Down
[09:28] <alf_> alan_g: I meant the comment for using a shared_ptr vs a reference to pass the registrar
[09:28] <slvn_> ok ... I send this patch to bschaefer and also racarr__ because there were implicated
[09:28] <slvn_> thanks anpok for the help !
[09:30] <alan_g> 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] <slvn_> 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] <alf_> 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] <alf_> bbiab
[09:40] <alan_g> alf_: OK. I don't (currently) see a strong reason for preferring any of the three approaches.
[09:40] <alan_g> Well four if you consider rev vs sp different
[09:40] <alan_g> *ref
[09:40] <slvn_> anpok : curiously : fingerpaint.c has :  MirMotionAction masked_action = event->motion.action & ~0xff00;     // FIXME: https://bugs.launchpad.net/mir/+bug/1197108
[09:43] <anpok> slvn_: the encoding happens in InputReader of the android input code (TouchMapper is the class)
[09:54] <duflu> alf_: Oops, sorry. No not working on it at all (https://bugs.launchpad.net/bugs/1320114)
[10:03] <slvn_> anpok, the patch is not working. It works better, but sometime I miss a UP event  (miss== I dont detect?)
[10:21] <anpok> slvn_: oh sorry did not look at the patch properly
[10:28] <anpok> slvn_: http://pastebin.com/fy97wgEJ
[10:32] <slvn_> anpok,  okay.... I found some stuff !  MIR is sending me : action=0x101  but only pointer_counter=1 !!!!
[10:32] <slvn_> so I never do something with this event !
[10:36] <slvn_> 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] <slvn_> anpok, ... that's fully fix my issue now ! and it appears several time
[10:39] <slvn_> if (motion.pointer_count == 1 && (motion.action >> 8) != 0)
[10:39] <slvn_> motion.action &= 0xff;
[10:48] <anpok> oh i assumed it only happens for pointer_up,down and not for all kinds of up and down events..
[11:50] <slvn_> 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 ?
[12:17] <anpok> the code in
[12:18] <anpok> wrong terminal
[12:18] <anpok> slvn_: looks like a bug
[12:26] <slvn_> 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)
[16:18] <seb128> hey there
[16:19] <seb128> is Mir supposed to work on any intel hardware?
[16:19] <seb128> 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] <kdub_> seb128, I use a i965 for mir work
[16:22] <seb128> I had EGL errors/assertions in the unity8-mir log
[16:22] <seb128> need to boot again and share them
[16:22] <seb128> I guess my current description lacks details
[16:43] <racarr__> seb128: Ive heard rumors about i915 issues I think
[16:43] <racarr__> the ollld ones
[16:43] <racarr__> oh 950
[16:43] <racarr__> who knows ;)
[17:05] <seb128> 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] <seb128> yeah, it's i195
[17:15] <seb128> 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] <seb128> (I hope I didn't do typos, I don't have an easy way to copy the log from the machine)
[17:16] <seb128> that's in unity8-mir.log
[17:42] <racarr__> seb128: Ok I think there is something
[17:43] <racarr__> with i915, i.e. the mesa driver doesnt support the DRI2 apis or
[17:43] <racarr__> *not entirely sure*
[17:43] <racarr__> all I know for sure is that duflu knows
[17:43] <seb128> ok
[17:43] <seb128> "known issue" then ;-)
[17:43] <seb128> let me know if I should report it
[17:44] <xnox> what's the difference between libmir*-mesa & libmir*-android packages?
[17:44] <racarr__> kgunn: ^ Do you remember? i915 intel mesa...doesn't work?
[17:45] <racarr__> xnox: libmir-mesa uses MEsa EGL, GBM, kernel drm (direct rendering manager) modesetting, etc
[17:45] <xnox> racarr__: why would i want that installed on ubuntu-touch?
[17:45] <racarr__> libmir-android uses android graphics drivers, android EGL, gralloc, hardware composer
[17:45] <racarr__> Id ont think you would lol
[17:45] <kdub_> yeah, you wouldn't
[17:45] <xnox> racarr__: lolz, we do at the moment =)
[17:45] <xnox> no wonder ubuntu-touch image is 1.4 GB big with LLVM et al
[17:46] <kdub_> unless you're ambitious and want the freedreno stuff? (uncharted waters)
[17:46] <racarr__> xnox: Yeah...last I checked
[17:46] <racarr__> I believe we end up pulling
[17:46] <racarr__> significant parts of X +
[17:46] <racarr__> both libegls, etc.
[17:46] <racarr__> I think there are some eird dependencies in mesa
[17:46] <racarr__> but ive never dug down
[18:07] <kgunn> racarr__: right, as i recall from duflu, dri2  never added support for i915
[18:40] <racarr__> kgunn: Ok. No bug needed from seb then :)