| duflu | bschaefer: Your SDL 2.0 work, that's not in archive is it? | 01:45 |
|---|---|---|
| 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:46 |
| 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:47 |
| 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:48 |
| duflu | bschaefer: How's the input support? | 01:52 |
| duflu | Pretty much complete (as much as Mir allows you to)? | 01:52 |
| * RAOF hides | 01:59 | |
| bschaefer | duflu, yeah | 02:13 |
| bschaefer | duflu, and yeah i need to re-confirm that bug | 02:13 |
| bschaefer | duflu, o thanks for re-opening it :) | 02:14 |
| 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:17 |
| 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:18 |
| 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:24 |
| 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:25 |
| bschaefer | thats good to know | 02:26 |
| bschaefer | vs freaking out | 02:26 |
| duflu | RAOF: Oh, no more inline comments check box in reviews | 07:00 |
| RAOF | To the EOW! | 07:51 |
| 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:56 |
| slvn_ | In some condition I dont get the TouchEvent "UP" from my 2nd finger | 07:57 |
| slvn_ | The test-case is : Put Finger-1 Down, F2-Down, F2-Up, F1-Up => it looks like Mir sends only one Up | 07:58 |
| 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 ...) | 07:59 |
| anpok | slvn_: that might be speculation, maybe you get the up events in a single event? | 08:04 |
| 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 |
| === Stskeepz is now known as Stskeeps | ||
| anpok | alan_g: seems like my mp failed because of timing issues in the asio alarm test fixture \o/ | 08:06 |
| slvn_ | anpok, I will check | 08:07 |
| anpok | slvn_: we borrowed some ugliness from the android input stack | 08:07 |
| 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:08 |
| 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:12 |
| alan_g | hmm | 08:13 |
| anpok | somehow.. | 08:14 |
| === yofel_ is now known as yofel | ||
| 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:14 |
| anpok | well i would like agree to that.. | 08:15 |
| 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:16 |
| anpok | slvn_: hm ok I was wrong you have to get two up events | 08:17 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:25 |
| 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:26 |
| 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:28 |
| anpok | that one http://www.boost.org/doc/libs/1_55_0/boost/asio/detail/deadline_timer_service.hpp | 08:29 |
| 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:31 |
| 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:33 |
| alan_g | tests that rely on sleep/wait are broken | 08:34 |
| slvn_ | anpok, line 228 and 231 : I could replace the "cord_index" by : (motion.action >> 8) | 08:37 |
| anpok | yes - but you only get meaning full values if you are handling action&0ff = mir_motion_action_pointer_{up,down} | 08:42 |
| 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:44 |
| 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:45 |
| 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:49 |
| 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:51 |
| greyback | :) | 08:52 |
| greyback | alf_: aside from telling to not be naughty (am working on it), what avenue would you suspect? | 08:52 |
| 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:56 |
| alf_ | greyback: is the exception thrown from the host mir or from your qt-compositor nested mir? | 08:57 |
| 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:01 |
| 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:03 |
| greyback | alf_: good question, lemme see | 09:04 |
| 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:05 |
| anpok | I have to dig more into InputDispatcher to see when that happens | 09:06 |
| 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:09 |
| slvn_ | if I only do : "switch (motion.action & 0xff) {" and discard the 0xff00, all work fine | 09:10 |
| 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:11 |
| 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:12 |
| alan_g | alf_: reasonable. The alternative design is a registration facility (like atexit()). | 09:14 |
| 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:19 |
| alan_g | Or EmergencyCleanupRegistrar const& r | 09:20 |
| 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:21 |
| slvn_ | anpok : this patch is working perfectly ! http://pastebin.com/PB7FTvkk | 09:22 |
| slvn_ | anpok this is what you said first I think! | 09:22 |
| alan_g | alf_: I don't see why it depends. The are equivalent with: r.register([this]{ emegency_cleanup(); }); | 09:24 |
| anpok | slvn_: ah that function is called for every pointer? | 09:25 |
| anpok | then yes looks good! | 09:25 |
| slvn_ | anpok with the pointer_cound, but only one action for all ! | 09:26 |
| 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:27 |
| 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:28 |
| 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:30 |
| 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:36 |
| alf_ | bbiab | 09:38 |
| 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:40 |
| ubot5 | Ubuntu bug 1197108 in Mir "Input action fields no longer maintain compatibility with surfaceflinger" [Medium,Fix released] | 09:40 |
| anpok | slvn_: the encoding happens in InputReader of the android input code (TouchMapper is the class) | 09:43 |
| duflu | alf_: Oops, sorry. No not working on it at all (https://bugs.launchpad.net/bugs/1320114) | 09:54 |
| ubot5 | Ubuntu bug 1320114 in Mir "[DRM/GBM] Crashing Mir (via fatal signal) often leaves the screen blank and difficult to recover" [Medium,Triaged] | 09:54 |
| slvn_ | anpok, the patch is not working. It works better, but sometime I miss a UP event (miss== I dont detect?) | 10:03 |
| anpok | slvn_: oh sorry did not look at the patch properly | 10:21 |
| anpok | slvn_: http://pastebin.com/fy97wgEJ | 10:28 |
| 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:32 |
| 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:36 |
| 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:39 |
| anpok | oh i assumed it only happens for pointer_up,down and not for all kinds of up and down events.. | 10:48 |
| === seb128_ is now known as seb128 | ||
| 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 ? | 11:50 |
| === alan_g is now known as alan_g|lunch | ||
| anpok | the code in | 12:17 |
| anpok | wrong terminal | 12:18 |
| anpok | slvn_: looks like a bug | 12:18 |
| 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) | 12:26 |
| === 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 | ||
| seb128 | hey there | 16:18 |
| 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:19 |
| kdub_ | seb128, I use a i965 for mir work | 16:21 |
| 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:22 |
| 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 ;) | 16:43 |
| === 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 | ||
| 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:05 |
| seb128 | yeah, it's i195 | 17:09 |
| 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:15 |
| 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:16 |
| racarr__ | seb128: Ok I think there is something | 17:42 |
| 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:43 |
| 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:44 |
| === dandrader|lunch is now known as dandrader | ||
| 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:45 |
| 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 | 17:46 |
| kgunn | racarr__: right, as i recall from duflu, dri2 never added support for i915 | 18:07 |
| racarr__ | kgunn: Ok. No bug needed from seb then :) | 18:40 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!