| * robert_ancell -> lunch | 00:06 | |
| sarnold | does anyone know the reasoning behind the piles of these compile warnings? http://paste.ubuntu.com/6177885/ | 01:20 |
|---|---|---|
| sarnold | I would have thought that "const typet" and "typet const" would have been interchangable, but g++ is complaining that const std::shared_ptr< msh::DisplayLayout > is different than std::shared_ptr< shell::DisplayLayout > | 01:22 |
| sarnold | sigh, moment... const std::shared_ptr< msh::DisplayLayout > and std::shared_ptr< shell::DisplayLayout > const | 01:22 |
| duflu | sarnold: I agree they look the same :/ Make sure you're using gcc 4.8 or later...? | 01:38 |
| sarnold | duflu: this appears to be gcc-4.8_4.8.1-10ubuntu4 | 01:40 |
| duflu | sarnold: Oh, I see. You probably have not aliased "msh". Replace it with "mir::shell" | 01:41 |
| sarnold | duflu: this is in the standard fullscreen_placement_strategy.cpp file, "namespace msh = mir::shell; | 01:43 |
| duflu | Don't know then | 01:44 |
| sarnold | drat :) | 01:44 |
| sarnold | src/client/gbm/* is full of similar looking warnings.. | 01:44 |
| bschaefer | duflu, hey, i've a question, what does fullscreen mean to mir atm? | 01:46 |
| bschaefer | ie. if we want to take a window and make it full screen (say its 1080x768 surface on a 1600x900 screen) | 01:47 |
| bschaefer | s/window/surface | 01:47 |
| duflu | bschaefer: The fullscreen state is "set" but not used. Our demos "fullscreen" just by setting the window size manually. The two are not wired up yet | 01:48 |
| bschaefer | duflu, will there be an API for this? To turn the active surface fullscreen? | 01:48 |
| duflu | bschaefer: Yes it exists, but does not affect surface size at all yet ... mir_wait_for(mir_surface_set_state(surface, mir_surface_state_fullscreen)); | 01:49 |
| bschaefer | duflu, awesome, I didn't see that when I was digging through the API :) | 01:50 |
| bschaefer | I saw I could make the server fullscreen, by an option, but that caused some problems (crashes) | 01:51 |
| duflu | bschaefer: Yes I agree it's confusing but you can see the function in include/client/mir_toolkit/mir_client_library.h and the args in include/shared/mir_toolkit/common.h | 01:51 |
| bschaefer | duflu, yeah I missed this: shared/mir_toolkit/common.h:65: mir_surface_state_fullscreen, along with the set state | 01:52 |
| bschaefer | that'll fix up my problem where im not sure what to do when asked to make the window fullscreen :) | 01:52 |
| duflu | bschaefer: It will still do nothing for now. :) | 01:53 |
| bschaefer | duflu, but when it does, I should be safe :) | 01:53 |
| bschaefer | duflu, O yeah, about that scroll V/H bug you made | 01:54 |
| * bschaefer digs it up | 01:54 | |
| duflu | That comes under the heading of "surface resizing not implemented yet" | 01:54 |
| bschaefer | https://bugs.launchpad.net/mir/+bug/1233089 | 01:54 |
| ubot5 | Ubuntu bug 1233089 in Mir "MirMotionEvent can't tell which direction the mouse wheel is scrolling" [Undecided,New] | 01:54 |
| bschaefer | duflu, Cool, hopefully when its implemented that API will stay somewhat the same | 01:54 |
| duflu | bschaefer: You have a solution for scrolling? | 01:55 |
| bschaefer | duflu, So I had that scroll direction implemented, but we talked that this should be handled differently, as one big problem was the event queue was being overflowed | 01:55 |
| bschaefer | duflu, Yeah I did, then we talked about it in Denmark, and we reverted it | 01:55 |
| bschaefer | https://code.launchpad.net/~brandontschaefer/mir/mir-vscroll-hscroll-event-data | 01:56 |
| duflu | bschaefer: Cool, please link relevant stuff and comment | 01:56 |
| bschaefer | duflu, i've done, but its reverted, let me make a new branch and get that back in :) | 01:56 |
| bschaefer | It was another problem I needed to address in my own project | 01:56 |
| duflu | bschaefer: I didn't start working on Mir until many months after Denmark... ?! | 01:56 |
| bschaefer | duflu, hmm I swear that was Denmark ... but now that I think about it it was Okalnd | 01:57 |
| bschaefer | Oakland* | 01:57 |
| duflu | Yeah about then. I started immediately after | 01:57 |
| duflu | Oh | 01:57 |
| duflu | Oops | 01:57 |
| duflu | No | 01:57 |
| bschaefer | to many places with small rooms with out windows | 01:57 |
| duflu | I had started by then | 01:57 |
| sarnold | hehe | 01:58 |
| duflu | It was San Mateo. Yeah :) | 01:58 |
| bschaefer | Cool :), yeah it was more about the responsibility of what mir should be doing | 01:58 |
| bschaefer | duflu, It was a bit ago, soo Im now forgetting the complete reason... | 01:59 |
| duflu | Where am I now? :S | 02:01 |
| bschaefer | duflu, O yeah, you mentioned it should be the toolkit that is responsible for it | 02:01 |
| bschaefer | https://code.launchpad.net/~brandontschaefer/mir/remove-vscroll-hscroll-events/+merge/162284 | 02:01 |
| duflu | bschaefer: I have no opinion on the solution until I get to reviewing it :) | 02:01 |
| bschaefer | duflu, well let me propose the old solution I had, then when a correct one comes around we can drop it :) | 02:02 |
| bschaefer | duflu, https://code.launchpad.net/~brandontschaefer/mir/lp.1233089-fix-v-h-scroll/+merge/188498 | 02:09 |
| bschaefer | so a MirMotionEvent motion; can get the v/h scroll info by: motion.pointer_coordinates[0].hscroll/motion.pointer_coordinates[0].vscroll | 02:10 |
| bschaefer | duflu, though...this will break the ABI :( | 02:12 |
| duflu | bschaefer: Possibly... That's actually less important for the server right now. But changing the structure size for clients could be a problem. | 02:15 |
| duflu | bschaefer: Fortunately we have a few unused fields in MirMotionEvent to steal bytes from ;) | 02:15 |
| thomi | robert_ancell: know anything about the ubuntu_platform_api_mirclient library implementation? | 02:15 |
| bschaefer | duflu, well if I can steal 2 then this will work :), I could also use a union and only need to steal 1 | 02:16 |
| thomi | or, alternatively, know anyone who's awake right now who does? | 02:16 |
| robert_ancell | thomi, not really | 02:16 |
| robert_ancell | racarr, ^ ? | 02:16 |
| bschaefer | as it can only be a vscroll xor hscroll | 02:16 |
| === jhodapp is now known as jhodapp|afk | ||
| bschaefer | though a union would not look very pretty :( | 02:18 |
| duflu | bschaefer: It's generalized for any device (including those which don't exist yet) so perhaps don't assume XOR | 02:19 |
| bschaefer | duflu, very true! | 02:19 |
| bschaefer | duflu, We could also hold off on this bug until something else that needs to break any structures anywhere to merge this in with that? | 02:24 |
| bschaefer | duflu, as Im assuming the ABI will have to be broken again at some point... | 02:24 |
| duflu | bschaefer: I hope that time comes... it's a matter of project planning | 02:24 |
| bschaefer | duflu, Right, and letting those who use Mir know when its coming I would think | 02:25 |
| bschaefer | duflu, think again, I don't know what: touch_major; touch_minor are for in the motion struct | 02:25 |
| bschaefer | s/think/then* | 02:25 |
| duflu | bschaefer: Yes there's a lot of copy/paste from Android. Hence bug 1175362 | 02:26 |
| ubot5 | bug 1175362 in Mir "MirMotionEvent fields lack documentation" [Medium,Triaged] https://launchpad.net/bugs/1175362 | 02:26 |
| bschaefer | Thats a good bug :), the v/hscroll bits where in there at that point haha | 02:27 |
| sarnold | duflu: thanks for the help :) | 02:36 |
| duflu | robert_ancell, kgunn: Should we add bug 1227739 to the phone priorities? | 02:36 |
| ubot5 | bug 1227739 in Mir "Mir continues to render application surface even when the indicator surface is on top" [High,Triaged] https://launchpad.net/bugs/1227739 | 02:36 |
| duflu | (cos I know how to solve that one :) | 02:36 |
| robert_ancell | duflu, looking | 02:36 |
| thomi | racarr: ping? | 02:36 |
| duflu | sarnold: No problem | 02:36 |
| kgunn | thomi: maybe ricmm | 02:37 |
| thomi | ricmm: awake? | 02:37 |
| thomi | kgunn: so I've gotten it to the point where I think it should work, but I get a segfault instead :-/ | 02:37 |
| robert_ancell | duflu, I agree with kgunn here - it's just an optimization so it doesn't need solving until we have all the other phone v1 features done | 02:38 |
| kgunn | duflu: of course...if its done prior...its gravy | 02:38 |
| robert_ancell | mmm gravy | 02:39 |
| duflu | Gravy's full of wheat :/ | 02:39 |
| thomi | heh, will you look at that. segfault comes from libmirclient3 :-( | 02:40 |
| kgunn | duflu: gluten free icing ? | 02:43 |
| kgunn | thomi: do you need some help | 02:44 |
| kgunn | from mir team | 02:44 |
| duflu | kgunn: Surprisingly icing sugar is also often flour :/ | 02:44 |
| thomi | kgunn: my plan at the moment is to clean this up and push it, then send you an email | 02:44 |
| thomi | kgunn: it doesn't look like anyone who understands the platform API is awake, so... | 02:44 |
| robert_ancell | thomi, do you have a WIP MP? | 03:04 |
| thomi | robert_ancell: really soon... | 03:04 |
| thomi | robert_ancell: just doing packaging changes now. Branch is at lp:~thomir/python-ubuntu-platform-api/add-mir-pkg | 03:04 |
| thomi | robert_ancell: will make a MP once the packaging stuff works | 03:04 |
| === chihchun_afk is now known as chihchun | ||
| thomi | robert_ancell: Mp created: https://code.launchpad.net/~thomir/python-ubuntu-platform-api/add-mir-pkg/+merge/188503 | 03:20 |
| kgunn | duflu: gotta ur nexus4 back yet ? | 03:20 |
| duflu | kgunn: I expect it would have only just arrived there. Expect about another week :P | 03:20 |
| robert_ancell | thomi, the segfault is in libmirclient or libmirserver? | 03:21 |
| kgunn | thomi: is there a "here's how you run AP tests on the phone" wiki | 03:21 |
| thomi | libmirclient3 | 03:21 |
| kgunn | duflu: bummer | 03:21 |
| duflu | kgunn: So I reverted to Nexus7. Not quite usable for Mir but much better than expected | 03:21 |
| kgunn | duflu: shocking really | 03:21 |
| duflu | ... as in there's only one bug AFAIK | 03:21 |
| thomi | kgunn: I don't think there's a wiki page. I believe most people still use the 'phablet-test-run' script | 03:22 |
| thomi | kgunn: just doing some research for you. I believe you can run 'phablet-click-test-setup' to download all the test cases | 03:23 |
| thomi | and then 'phablet-test-run unity8' for example to run that test suite | 03:23 |
| duflu | kgunn: Tracking says it arrived Sydney on Friday | 03:26 |
| duflu | Although the Australian Play Store still shows (discounted) Nexus 4 in stock | 03:28 |
| duflu | Can we assume all touch surfaces are full screen right now? Or do they exclude the notification bar? | 03:42 |
| duflu | -touch +phone | 03:42 |
| bschaefer | duflu, hey, one more question :). If I set mir_surface_state_fullscreen, then when its toggle off of fullscreen should the state be set to: mir_surface_state_restored? | 04:12 |
| bschaefer | or possibly unknown? | 04:12 |
| duflu | bschaefer: A floating window will usually be "restored" I think | 04:12 |
| bschaefer | duflu, hmm so thats more or less the default state of a surface? | 04:13 |
| * bschaefer should have just checked the source for the default state :) | 04:13 | |
| bschaefer | duflu, Looks like: mir_surface_state_unknown; is getting set on the creation of a MirSurface | 04:14 |
| * bschaefer finds that to be a strange state name...unknown... | 04:14 | |
| duflu | bschaefer: Tis correct. The state is stored in the server and the client considers the state unknown till it receives the first notification of what the state is | 04:15 |
| duflu | bschaefer: The server won't send such a notification unless you change it I think... ? | 04:16 |
| bschaefer | duflu, so when we want to set the state back to default, unknow it is! Sounds good, just wasn't the first thing I thought it was doing... | 04:16 |
| duflu | bschaefer: That will probably fail. I think restored is a more sane default | 04:16 |
| bschaefer | duflu, O, that makes sense as well :) | 04:17 |
| duflu | bschaefer: Oh. I vaguely recall that setting unknown is know you force the server to tell you the real value. Just wait_for the set and then get the value | 04:19 |
| duflu | -know +how | 04:19 |
| duflu | !? | 04:19 |
| bschaefer | duflu, well my goal is to set fullscreen when asked, thats simple | 04:19 |
| bschaefer | the thing is once fullscreen gets toggled off, the state will still be fullscreen, so i was just wanting to go back to default in a sense | 04:20 |
| bschaefer | duflu, Should I be setting the state on creation? | 04:20 |
| bschaefer | duflu, Im also not sure if these things are even hammered out yet :) | 04:21 |
| bschaefer | duflu, You're correct, if the state is unknown, then the surface gets configured when asked what the state is: | 04:24 |
| bschaefer | http://paste.ubuntu.com/6178269/ | 04:24 |
| duflu | bschaefer: Restored is a safe bet. "Restore" means "please put the surface back how it was before fullscreen/maximize. | 04:29 |
| duflu | " | 04:29 |
| bschaefer | duflu, yeah, that sounds good, I just got curious on how unknown was handled :). Thanks! I should head off for the night | 04:29 |
| bschaefer | duflu, have a good rest of your day! | 04:30 |
| duflu | bschaefer: I don't think I intended "unknown" to be used by clients | 04:30 |
| duflu | ... | 04:30 |
| duflu | Good night | 04:30 |
| bschaefer | :), well at lease it doesn't look like it should be used haha | 04:30 |
| budgee | holla mirs | 08:05 |
| budgee | Is Mir perhaps the reason I cannot get synergyc to connect to another synergys? | 08:06 |
| budgee | synergyc is running on a 13.10 machine with Mir | 08:06 |
| budgee | and synergys is running on 13.04 | 08:07 |
| mlankhorst | version difference I guess? | 08:21 |
| mlankhorst | synergy has a debug mode that might help | 08:21 |
| alf_ | alan_g: The question is whether we should treat send failures as critical errors and close the connection, or rely on getting an error next time we try to read from the socket (as is done now). The latest version of socket-messenger-race keeps the current behavior and doesn't propagate the send errors further. | 08:37 |
| alan_g | alf_: until recently ProtobufMessageProcessor::dispatch() handled write errors by dropping the connection. I think we should reinstate that. | 08:39 |
| alan_g | It changed as a side-effect of suppressing a lack of error handling when sending unsolicited events to the client. | 08:40 |
| alf_ | alan_g: I agree, and also make sendmsg() (for FDs) failures throw too. Does the client handle such events properly now? | 08:41 |
| alan_g | alf_: I've a rework of the client -side code sitting on a branch that does handle stuff correctly. Not sure about trunk | 08:42 |
| duflu | alan_g: Not immediately required, but if you come across any documentation for asio that's actually readable (unlike the official docs) then please let us all know?... It seems very black magic | 08:42 |
| alan_g | duflu: I was moaning about the same thing in Boston | 08:43 |
| duflu | alan_g: My concern is that it seems like only one of us (you?) has ever figured out how it works. And that's detrimental to our maintenance efforts | 08:44 |
| alan_g | duflu: I share your concern (and I don't have it figured out yet) | 08:48 |
| * alan_g thinks that if he ever does figure it out an article would be a good idea. | 08:49 | |
| * duflu gets out the pen an paper; finds 12 server-side "surface" classes and counting :P | 10:00 | |
| duflu | greyback: Unity8 on Mir ... forgive my ignorance but is that finally multi-surface? And are app surfaces usually fullscreen on the phone? | 10:04 |
| greyback | duflu: shell is single surface at the moment, work in underway to change that though. Yes app surfaces are usually fullscreen | 10:05 |
| duflu | greyback: So the shell gets lowered or always-on-top-but-hidden? | 10:05 |
| greyback | duflu: always on top, marks itself transparent to hide | 10:06 |
| greyback | s/marks/makes/ | 10:06 |
| duflu | greyback: Argh. OK... so that's using Mir's hidden attribute? | 10:06 |
| greyback | duflu: sorry no, it just makes its surface transparent, so surface underneath is visible | 10:07 |
| duflu | greyback: Oh. That will pose a problem to my occlusion testing I guess.... unless... the whole surface has alpha==0 ? | 10:07 |
| greyback | It does not tough the visible/hidden attribute | 10:07 |
| greyback | duflu: no, say if launcher out, the launcher bit is fully opaque, but the rest of the shell surface is transparent | 10:09 |
| duflu | greyback: Eeek. So I can't do occlusion testing on that. I guess I need to wait for Unity changes | 10:10 |
| duflu | greyback: Unless there's a definitive way to identify when the top (shell) surface and launcher is hidden? | 10:10 |
| greyback | duflu: sorry for my ignorance how, but what is occlusion testing? | 10:11 |
| duflu | greyback: Finding out what's hidden to optimize rendering | 10:11 |
| duflu | greyback: Final question before I go: Can I tell from Mir that the launcher is hidden by the shell surface state somehow? | 10:12 |
| greyback | duflu: I see. Shell is doing complex things, so there's no easy way for outsider to determine what parts of the surface is opaque and not | 10:13 |
| duflu | greyback: Well, I'm looking from inside the server, not outside. But still, will need something more efficient than testing every pixel of the surface for opacity | 10:13 |
| duflu | That's OK, I've found more things that need cleaning up and moving around before any of that | 10:14 |
| greyback | duflu: you could watch the input areas that the shell surface defines. Generally if it has an input area, that area is not-transparent | 10:14 |
| duflu | greyback: Interesting heuristic but not reliable. At least not on non-touch platforms | 10:15 |
| greyback | but that's the only way I can think mir is even aware of what shell is doing | 10:15 |
| greyback | yep, I've nothing better to suggest, sorry | 10:15 |
| duflu | greyback: OK, keep me posted on changes to the shell surface implementation? | 10:15 |
| duflu | Time to make dinner! | 10:15 |
| greyback | duflu: sure, but I expect it to be after the 1.0 release | 10:15 |
| duflu | greyback: Yep | 10:15 |
| greyback | bon appetit | 10:16 |
| === alan_g is now known as alan_g|afk | ||
| === hikiko is now known as hikiko|lunch | ||
| === alan_g|afk is now known as alan_g | ||
| davmor2 | kgunn: well that is my plan of using mir all day out of the window, no sound on received calls or sms, I'm just going to compare that with SF but I can't understand why mir would stop that | 10:49 |
| * ricmm was making calls on Mir yesterday | 10:51 | |
| ricmm | theres is no reason for Mir to block any kind of sound, something else in your setup is probably triggering it | 10:51 |
| ricmm | perhaps something triggered by the Mir selector, but certainly not the shell itself | 10:51 |
| davmor2 | ricmm: it's okay it dead on sf too apparently there was an issue that is/has been resolved and I might just need a new image and then I can start again | 10:53 |
| ricmm | perfecto | 11:02 |
| davmor2 | ricmm: apparently it is an issue with the infographics stuff so it effects anything it touches, so no camera sms or phone by the look of it :( | 11:06 |
| ricmm | wow | 11:19 |
| === chihchun is now known as chihchun_afk | ||
| davmor2 | ricmm: ah usermetrics sorry, the bit that infographics gets it's info from :) | 11:24 |
| === hikiko|lunch is now known as hikiko | ||
| === jhodapp|afk is now known as jhodapp | ||
| kgunn | mornin greyback, need any help ? | 12:31 |
| greyback | kgunn: not yet, am not out of ideas just yet | 12:32 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| Saviq | racarr, ping | 13:28 |
| kgunn | tjaalton: mlankhorst hey do you guys know anything about potential open source driver roadmaps, primarily when/if opengl4 would be supported? | 13:29 |
| mlankhorst | when we get around to it, if someone gets around to it :P | 13:30 |
| tjaalton | kgunn: http://www.x.org/videos/XDC2013/ian_romanick_mesa_update.avi that should tell, iirc | 13:30 |
| tjaalton | maybe next year | 13:31 |
| mlankhorst | sarnold: might know better than me, tbh | 13:31 |
| mlankhorst | sarvatt* | 13:31 |
| tjaalton | http://www.youtube.com/watch?v=Lk20sLDI1eE&feature=youtu.be | 13:33 |
| tjaalton | better link | 13:33 |
| greyback | alan_g: what does this error imply: what(): bind: Address already in use | 13:43 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| ricmm | kgunn: ping | 14:07 |
| kgunn | ricmm: pong | 14:08 |
| ricmm | kgunn: hey kevin, about the autopilot stuff... Mir blows up internally when the hwc is in a blanked state upon starting | 14:08 |
| ricmm | thats not really the shell's fault, the Mir code needs to account for this case | 14:08 |
| ricmm | bring the hwc to a clean slate etc | 14:08 |
| kgunn | greyback: oh crap... alan_g is out this afternoon dealing with a speeding ticket i think | 14:08 |
| ricmm | it is possible that unity8 will crash unexpectedly at some point while the screen is blanked | 14:08 |
| kgunn | alf_: ^ can you help greyback | 14:08 |
| ricmm | in which case Mir needs to make sure it can account for a startup with a hwc in any state | 14:09 |
| ricmm | the only case unity8 can protect is the oen where it has been explicity asked to quit itself | 14:09 |
| ricmm | one* | 14:09 |
| alf_ | greyback: perhaps some left-over mir socket file? | 14:10 |
| ricmm | its usually the left over /tmp/mir_socket yea | 14:10 |
| kgunn | ricmm: hmmm....wonder if that's because of some discussion i saw yesterday about AP stuff, creating some objects out of order... | 14:10 |
| ricmm | greyback: you sure its not there? | 14:10 |
| ricmm | kgunn: its not APs fault, nor the shell | 14:10 |
| kgunn | ricmm: i'm not saying it is | 14:10 |
| greyback | ricmm: I get this when running shell through AP, so need to figure out why | 14:11 |
| ricmm | greyback: only through AP? | 14:11 |
| kgunn | ricmm: i'm saying that you're right in that we may need to put in some safety code for a new order of things | 14:11 |
| greyback | ricmm: yep, I can run manually | 14:11 |
| alf_ | greyback: can you run in gdb and get a backtrace? | 14:11 |
| ricmm | greyback: just strace it, you'll see the failing syscall() | 14:11 |
| ricmm | kgunn: indeed, we need some protection when initializing the hwc to make sure it is reset to an unblanked state | 14:12 |
| ricmm | kgunn: technically spurious ->blank() or ->unblank() calls shouldnt fail, according to API | 14:12 |
| ricmm | but robert's code is catching it somewhere | 14:12 |
| ricmm | im sure he can sort it in miutes | 14:12 |
| kgunn | ricmm: well...that is semiCo code :) | 14:13 |
| kgunn | ricmm: yeah...we have mir stand up in 45 minutes | 14:13 |
| kgunn | kdub always makes it... racarr is a sometimes... | 14:13 |
| ricmm | kgunn: I could join and explain if you want | 14:16 |
| kgunn | ricmm: sounds great | 14:16 |
| kgunn | will invite | 14:16 |
| ricmm | perfect | 14:16 |
| didrocks | kgunn: oh, just a note, when you merge from the dev branch to trunk, please use a better and more detailed commit message "merge from latests dev branch" isn't very informative :) | 14:18 |
| kgunn | didrocks: ack....i can populate with aggregate commit | 14:19 |
| didrocks | kgunn: yeah, seems to be the right strategy ;) | 14:19 |
| * kgunn still claims victory for not breaking build :) | 14:19 | |
| om26er | The performance of Mir on Nexus 4 was on par with SF a few weeks ago, what changed? Is there a bug report somewhere ? | 14:41 |
| om26er | davmor2, maybe you know ? ^ | 14:42 |
| davmor2 | om26er: I don't have mako I have maguro which is slower anyway. | 14:46 |
| davmor2 | om26er: I took some basic videos yesterday and posted them here showing that mir was slower. I was going to run with mir all day today but then I get no notifications about calls and messages so need to get image 75 first. | 14:48 |
| om26er | davmor2, is 75 coming soon ? | 14:49 |
| davmor2 | om26er: as soon as all the bits required have built which isn't happening currently | 14:49 |
| kgunn | kdub: alf_ racarr hikiko ricmm standup | 15:02 |
| === dandrader is now known as dandrader|lunch | ||
| hikiko | joining kgunn | 15:05 |
| hikiko | goodbye! | 15:29 |
| ricmm | kdub: ping | 15:38 |
| kdub | pong | 15:38 |
| ricmm | kdub: http://paste.ubuntu.com/6180049/ | 15:38 |
| ricmm | you can see the last working blocking pread() on the vsync fd in line 1 | 15:38 |
| ricmm | returns in line 7 with valid data | 15:38 |
| ricmm | line 8's returns immediately with empty data | 15:39 |
| kdub | off the top of my head | 15:39 |
| ricmm | and then its spuriously happening like that consuming the full CPU where that thread schedules | 15:39 |
| kdub | that looks like the vsync signal that is polled for, which surfaceflinger uses to trigger its own composition, and sends that signal on to the clients | 15:40 |
| kdub | we should probably disable/enable that signal on a blank | 15:40 |
| ricmm | you dont use that signal at all? | 15:40 |
| kdub | and i'll think about disabling it, we're getting vsync from the commit fences right now | 15:40 |
| kdub | right | 15:40 |
| ricmm | oh then by all means disable it | 15:40 |
| ricmm | as it wakes the thread on vsync | 15:41 |
| kdub | yeah, disabling it makes more sense | 15:41 |
| ricmm | not costly, but then it causes this crap | 15:41 |
| kdub | i might re-enable it for performance logging or something at some point though | 15:41 |
| ricmm | is it easy to disable? | 15:41 |
| kdub | yeah, easy | 15:41 |
| * ricmm likes these answers | 15:41 | |
| ricmm | tell me how I can test :) | 15:41 |
| ricmm | kdub: why are we polling for the signal anyways? or is that the hwc polling it | 15:43 |
| ricmm | if its unused for anything in Mir I mean | 15:43 |
| kdub | we used to use it to get vsync | 15:43 |
| ricmm | ah ok | 15:43 |
| kdub | and hwc10 still does | 15:43 |
| ricmm | maguro is 1.0 ? | 15:43 |
| kdub | right | 15:43 |
| ricmm | hmm | 15:43 |
| ricmm | I havent tested this breakage in maguro, although in maguro we dont blank | 15:44 |
| ricmm | we just suspend | 15:44 |
| ricmm | which in turn turns the hwc off and gpu, etc | 15:44 |
| kdub | ricmm, http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/server/graphics/android/hwc_common_device.cpp#L68 | 15:44 |
| ricmm | I guess it will blow up maguro if you remove it, which we dont wanr | 15:44 |
| kdub | turn that last argument from a 1 to a 0 | 15:45 |
| kdub | or just delete lines 68-76 | 15:45 |
| ricmm | ok | 15:45 |
| kgunn | alf_: i'd ask duflu...since he's not on, do you know if raof/duflu actually fixed the radeon corrupt render issue ? | 16:00 |
| kgunn | alf_: having a hard time deciphering bug correspondence | 16:01 |
| kdub | android display creation needs some cleanup | 16:07 |
| alf_ | kgunn: the radeon issue we were seeing during the sprint (vertical black lines) has been fixed: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1218815 | 16:08 |
| ubot5 | Ubuntu bug 1218815 in xserver-xorg-video-ati (Ubuntu) "[radeon] Graphic glitches and screen corruption (vertical lines) on XMir surfaces only" [Critical,Fix released] | 16:08 |
| alf_ | kgunn: however, there seems to be a new radeon glitch: https://bugs.launchpad.net/mir/+bug/1233545 | 16:08 |
| ubot5 | Ubuntu bug 1233545 in mir (Ubuntu) "Screen corruption on radeon chipset" [Critical,New] | 16:08 |
| kgunn | alf_: thanks...arg, marked invalid for xmir...that's why | 16:08 |
| kgunn | alf_: yeah...saw that :) | 16:08 |
| alan_g | greyback: @"bind: Address already in use" - the socket filename is already being used | 16:14 |
| mterry | Hello! I'm looking at a bug with unity8-on-Mir where a frame or two of the dash can be seen before the greeter appears on screen-turn-on. I'm told that the Mir compositor stops accepting frames when the screen is blanked. But it seems that Mir is shutting down frames sooner than unity8 can respond to the screen-blank event and thus can't prepare the screen. :( Any hints? | 16:14 |
| mterry | racarr, alan_g: ^ ? | 16:15 |
| alan_g | mterry: not anything I'm familiar with. Sorry | 16:16 |
| ricmm | kdub: seems to be doing the same | 16:17 |
| ricmm | I still get the VSYNC pollers | 16:17 |
| ricmm | perhaps they are enabled by default, what I did was remove the code | 16:18 |
| * ricmm readds | 16:18 | |
| ricmm | kdub: http://androidxref.com/4.2.2_r1/xref/hardware/libhardware/include/hardware/hwcomposer.h#337 | 16:23 |
| kdub | yeah, we're doing that wrong | 16:24 |
| * mterry has to run for lunch, but will be back | 16:24 | |
| kdub | ricmm, try setting to zero | 16:28 |
| kdub | really, that thread looks like its started in registerProcs | 16:28 |
| ricmm | kdub: so should I first disable in the eventControl before registering the thread with registerProcs? | 16:30 |
| ricmm | perhaps it doesnt disable on the fly | 16:30 |
| ricmm | kdub: neg this is how SF does it so should be fine | 16:31 |
| kdub | just reading through the code for that thread | 16:31 |
| kdub | it should be able to be disabled on the fly | 16:32 |
| kdub | and it should start off | 16:32 |
| ricmm | well I still see the pread()s | 16:33 |
| ricmm | is it possible that what is disabled is the event delivery through vsync() ? | 16:33 |
| ricmm | yet it still polls internally | 16:33 |
| kdub | it should be waiting on a condition variable here https://github.com/CyanogenMod/android_hardware_qcom_display/blob/cm-10.1/libhwcomposer/hwc_vsync.cpp#L96 | 16:37 |
| === dandrader|lunch is now known as dandrader | ||
| kdub | alf_, do gbm buffers have fences? | 16:59 |
| kdub | just wondering if mg::BufferBasic should have fence-related functions, or if that's just an android think | 17:00 |
| kdub | thing | 17:00 |
| === alan_g is now known as alan_g|EOD | ||
| mterry | Back. Still curious if anyone knows much about Mir compositing as the screen blanks | 17:10 |
| ricmm | kdub: im at a loss here, im clearly disabling it | 17:30 |
| ricmm | condition is zero'd in the qcom hwcomposer | 17:31 |
| ricmm | so that thread should block on it | 17:31 |
| kdub | but its still not blocking? strange | 17:31 |
| ricmm | yea | 17:31 |
| ricmm | we shouldn't be reaching the pread at all | 17:31 |
| bschaefer | racarr, ping | 17:32 |
| mterry | kdub, I see you in bzr log for some HWC stuff. Do you know much about how Mir handles blanking/unblanking the screen? Specifically, is there an opportunity for the shell to change the screen before Mir stops accepting new frames upon a blank event? | 17:32 |
| ricmm | mterry: the blanking is requested by the shell, so yes the shell knows when its going to unblank | 17:33 |
| ricmm | exactly what are you trying to do? | 17:33 |
| mterry | ricmm, requested by shell? Not powerd? | 17:33 |
| mterry | ricmm, I'm looking at a bug with unity8-on-Mir where a frame or two of the dash can be seen before the greeter appears on screen-turn-on. It seems that Mir is shutting down frames sooner than unity8 can respond to the screen-blank event and thus can't prepare the screen | 17:33 |
| kdub | well, i think powerd talks dbus to the shell, and the shell commands mir what to do | 17:34 |
| kdub | if i understand | 17:34 |
| ricmm | mterry: powerd -> DBus to shell -> shell out to Mir to blank | 17:35 |
| ricmm | yup | 17:35 |
| mterry | kdub, interesting... ideally what I'd really like to happen is "blank screen; display something on that screen; have Mir stop accepting new frames" | 17:35 |
| mterry | ricmm, kdub: OK, will look in shell code for where we do that. May help me figure a workaround | 17:35 |
| ricmm | AFAIK hwcomposer blanking means the composer stops accepting frames, as well | 17:35 |
| ricmm | so whatever you want in place needs to be there before the blanking happens | 17:36 |
| ricmm | because also when we return to powerd, it will try to suspend (stop some pipelines, more weird behaviour( | 17:36 |
| kdub | well, we stop the composition pass, which in effect, stalls the clients | 17:36 |
| mterry | ricmm, seems like a jarring experience for user. Ideally they see dash -> black -> greeter | 17:36 |
| kdub | so seems we could display a fade (or whatever design wants) to black | 17:37 |
| kdub | then blank | 17:37 |
| kdub | then turn on, and start rendering a fade from black (or whatever) | 17:37 |
| ricmm | I would believe that would be communication between shell and greeter | 17:38 |
| ricmm | shell can hide, draw greeter and blank | 17:38 |
| ricmm | it all happens rather quickly anyways | 17:38 |
| racarr | bschaefer: Pong | 17:41 |
| bschaefer | racarr, hey, sooo it looks like we want v/hscroll back into mir again :( | 17:41 |
| bschaefer | racarr, problem, is we break the size of the event structure mp: | 17:41 |
| bschaefer | https://code.launchpad.net/~brandontschaefer/mir/lp.1233089-fix-v-h-scroll/+merge/188666 | 17:41 |
| bschaefer | racarr, and was wondering if you have any preference to which event info we could remove to make room for v/h scroll info :) | 17:42 |
| mterry | OK, yup. I see chain now. powerd calls com.canonical.Unity.Screen.setScreenPowerMode (defined in unity-mir) which calls Mir's configure_output | 17:42 |
| bschaefer | racarr, i also need to fix that branch up...some extra stuff got into it? | 17:43 |
| racarr | bschaefer: I don't think...at least first thought | 17:43 |
| racarr | that we should remove another event | 17:43 |
| racarr | to make room for v/h scroll | 17:43 |
| racarr | sounds like eventually you have to break ABI twice | 17:43 |
| racarr | i.e. will we want it back later | 17:43 |
| bschaefer | racarr, true, thats another option :) | 17:43 |
| racarr | just a big confusion | 17:43 |
| racarr | etc | 17:43 |
| bschaefer | yeah | 17:43 |
| racarr | so I would rather just bump mir client ABI but maybe | 17:44 |
| bschaefer | i can fix up the branch and wait for the next ABI break to go in | 17:44 |
| racarr | its really not opssible anymore | 17:44 |
| racarr | yeah I think that would be good unless its a rush | 17:44 |
| bschaefer | missing that event info causes some things to not work, but not a rush | 17:44 |
| mterry | greyback, so I'm looking at sequence on screen-blanking. unity-mir receives a request from powerd to blank, then it asks Mir. Is it reasonable to add a unity-mir signal to shell that it is about to blank, "better get any frames that you want in now"? | 17:47 |
| === jhodapp is now known as jhodapp|lunch | ||
| mterry | greyback, maybe in Unity.Application...? | 17:49 |
| greyback | mterry: maybe? So you want shell to be able to delay the screen blank? | 17:49 |
| mterry | greyback, I don't know about delay, but I'd like to prepare the screen for wake-up, so that user doesn't see a frame of the dash upon wakeup before the greeter can appear | 17:50 |
| racarr | kgunn: When can we break mirclient ABI again? | 17:50 |
| mterry | racarr, :) | 17:51 |
| racarr | I have an idea | 17:52 |
| racarr | re: mterry and greyback | 17:52 |
| greyback | mterry: sure, I understand the problem. But how to make sure we've the right frame ready isn't obvious to me. I thought the easiest solution is for Mir's compositor to allow shell to push a few more frames after the screen has blanked... | 17:52 |
| racarr | The problem is, the client tries to swap buffers after | 17:52 |
| racarr | the screen blanks | 17:52 |
| racarr | which blocks, because it cant get a new buffer, because the compositor can't display its buffer | 17:53 |
| racarr | its old buffer | 17:53 |
| mterry | greyback, well, we could also squeeze in a frame before blanking, same diff? I don't know if we do it right before blanking if user would see it before screen goes dark or not | 17:53 |
| racarr | so basically the problem is that there are these 1 or 2 | 17:53 |
| racarr | buffers in flight, 1 held by the client | 17:53 |
| racarr | which it wants to swap | 17:53 |
| racarr | and potentially the last one held by the compositor which it may have not gotten a chance to render yet | 17:54 |
| greyback | racarr: could we just empty the Buffer ring for shell? | 17:54 |
| racarr | yes, that's what I am getting at | 17:54 |
| racarr | just cancel all the buffers, so after screen unblank | 17:54 |
| greyback | yep, sounds ok to me | 17:54 |
| racarr | the first swap buffers wont display anything/perhaps its some sort of error | 17:54 |
| racarr | and then you get a buffer back, and get a chance to draw a frame | 17:55 |
| racarr | yeah :D | 17:55 |
| racarr | Ok | 17:57 |
| racarr | I can't immediately work on that... | 17:57 |
| greyback | so we'd need to somehow get to the SwitchingBundle for the shell, and call compositor_buffer on it a few times? | 17:57 |
| ricmm | if you have no time to work on it right away, why dont we just block unity-mir blanking until the shell says "cool" | 17:59 |
| ricmm | I can see it being just a few lines of code | 17:59 |
| racarr | greyback: I think maybe we can use "drop_frames" | 17:59 |
| racarr | it should be internal to the graphics backend though | 17:59 |
| greyback | racarr: sure | 18:00 |
| greyback | mterry: yeah, that's probably the quickest option: to unity-mir add a signal this is emittedwhen powerd asks for blanking. In unity8, connect to that signal, have the greeter slide in | 18:00 |
| greyback | mterry: then also to unity-mir add an invokable method which actually does the blanking. Then call that function from QML after greeter slide-in animation complete | 18:01 |
| greyback | so at least the pre-blank and post-blank visuals will be identical | 18:01 |
| mterry | greyback: I plan to drop the slide-in animation when blanking | 18:01 |
| mterry | greyback, so should be immediate | 18:02 |
| racarr | but then there is just | 18:02 |
| racarr | one frame before you blank | 18:02 |
| racarr | that is wrong | 18:02 |
| greyback | mterry: but then we've the problem again. There'll be some old pre-blank frames in the shell's buffer of frames, which will only be rendered after screen unblanked | 18:02 |
| greyback | Mir does triple buffering for apps, so every app has up to 3 frames ready at any one time | 18:03 |
| mterry | greyback, heh, you mean by making the greeter show faster, I'm making it worse? :) | 18:03 |
| greyback | s/apps/clients/ | 18:03 |
| mterry | greyback, guh, seems like the empty-queue method is the right way | 18:04 |
| mterry | greyback, but that's not going to happen soon you don't think? | 18:04 |
| racarr | I mean I can probably get to it by thursday | 18:04 |
| racarr | I just mean I cant do it right now | 18:04 |
| mterry | racarr, I don't think this is AAA priority | 18:04 |
| ricmm | its not AAA priority | 18:05 |
| mterry | racarr, it is marked for v1freeze, but doesn't need to be fixed today | 18:05 |
| racarr | ok | 18:05 |
| ricmm | wait a sec | 18:05 |
| mterry | racarr, for tracking purposes, bug is 1233564 | 18:05 |
| racarr | ill mention it at the weekly meeting to confirm the approach | 18:05 |
| greyback | racarr: yeah, good idea | 18:05 |
| ricmm | if it will be the Mir way, then it needs to happen ASAP, because Mir has a long turnaround and it usually breaks other things | 18:05 |
| racarr | and hopefully do it on thursday | 18:05 |
| ricmm | if its shell it can wait as its higher level and simpler | 18:06 |
| racarr | mir ;) | 18:06 |
| greyback | racarr: let us know if the other Mir guys approve of it or not | 18:06 |
| racarr | ok | 18:06 |
| racarr | it made it in to the .org file :) | 18:07 |
| mterry | racarr, to ricmm's point, do you know if there will be enough time afterward to land well? When are you guys planning last drop? | 18:07 |
| racarr | "last drop" -> *chills up spine* | 18:07 |
| racarr | I...honestly don't know | 18:07 |
| racarr | kgunn: ^? | 18:07 |
| mterry | racarr, thanks btw for offering to do the work. I've got the unity8 side of this, but would not be able to do Mir side in any reasonable timeframe | 18:09 |
| ricmm | kdub: my bad in the end | 18:16 |
| ricmm | disabling it does work fine | 18:16 |
| ricmm | sorry | 18:16 |
| racarr | mterry: No worries | 18:17 |
| racarr | my current delegation is to be a unity<->mir bug fairy and work on the mirserver API inbetween :) | 18:17 |
| kdub | ricmm, no problem, i'll mp a fix that disables that signal | 18:18 |
| ricmm | kdub: thank you, make sure it doesnt break maguro | 18:24 |
| === jhodapp|lunch is now known as jhodapp | ||
| racarr | [ RUN ] TestClientInput.clients_receive_injected_input_per_norm | 18:59 |
| racarr | [ OK ] TestClientInput.clients_receive_injected_input_per_norm (17 ms) | 18:59 |
| racarr | and they like it too. | 18:59 |
| racarr | lots of mechanical event conversion code to write + tests before motion events make it through | 18:59 |
| racarr | but got the inject to handle mechanism established | 19:00 |
| davmor2 | kgunn: image 75 is finally with us, So I'll give mir a hammering tonight and tomorrow am and let you know what I find :) | 19:00 |
| kgunn | mterry: racarr as to last code drop - well Oct 10 is supposed to be the cut off | 19:01 |
| racarr | not that anyone is counting right?!?! | 19:02 |
| racarr | >< ok thanks | 19:02 |
| thomi | kgunn: ping? | 19:05 |
| thomi | actualkly, nvm. read my email | 19:07 |
| kgunn | thomi: :) | 19:07 |
| thomi | this is such a mess. to make matters worse, I'm pretty sure I'm getting sick :-/ | 19:07 |
| kgunn | racarr: mterry it seems we almost need a compositor flush command ? | 19:11 |
| kgunn | if i understand the scrollback correctly | 19:11 |
| racarr | yeah | 19:19 |
| === dandrader is now known as dandrader|afk | ||
| === popey_ is now known as popey | ||
| === dandrader|afk is now known as dandrader | ||
| === kdub is now known as kdublunch | ||
| === kdublunch is now known as kdub | ||
| davmor2_ | kgunn: I had to stop running mir after an hour animation ground to a standstill. Are there any logs or info that would be useful to diagnosing why and I'll try again | 20:48 |
| kgunn | davmor2_: anything in var/crash ? | 20:49 |
| davmor2_ | kgunn: hud service crash maliit crash and a couple of others. | 20:53 |
| davmor2_ | kgunn: I'll clear it down though then run some more tests, also hud didn't work under mir but is under sf. I'll run top and look at crash reports and grab some logs tomorrow it's getting late now :-) | 20:57 |
| kgunn | davmor2_: yep...knew about the hud... | 20:57 |
| kgunn | davmor2_: do you know how to unwind a crash file ?....have to download symbols | 20:58 |
| kgunn | run apport backtrace or some such....i'll try to find the wiki... | 20:58 |
| kgunn | but getting slammed in another channel atm | 20:58 |
| davmor2_ | kgunn no rush dude I'm calling it a night just ping me or mail me on dave.morley@canonical.com I'll be testing in the morning now any way :-) | 21:00 |
| kgunn | racarr: ping | 21:01 |
| === davmor2_ is now known as davmor2 | ||
| racarr | kgunn: pong | 21:02 |
| kgunn | racarr: in unity...we think we might be screwwed on AP test enabling | 21:03 |
| kgunn | thomi was just pointing out | 21:03 |
| kgunn | that AP is built to just launch apps w/o shell | 21:04 |
| kgunn | but i don't think that's possible (atm) | 21:04 |
| kgunn | racarr: ^ ? | 21:04 |
| racarr | part of the plan with | 21:04 |
| racarr | this idea that only the shell would launch apps/it would verify the PIDs | 21:04 |
| racarr | were that 1. The shell would grow a dbus interface for launching apps | 21:04 |
| racarr | 2. upstart could be used directly by things that want to launch apps | 21:05 |
| racarr | and unity recognizes the PID from upstart and matches them | 21:05 |
| racarr | I don't believe 2 is implemented | 21:05 |
| thomi | racarr: is 1. implemented? | 21:05 |
| racarr | No, but it seems like it could be quickly | 21:05 |
| racarr | I mean, to unblock things | 21:05 |
| thomi | ok. We need it in like.... 30 minutes... doable? | 21:05 |
| racarr | unity-mir could have an environment variable | 21:06 |
| racarr | UNITY_MIR_DISABLE_SESSION_AUTHORIZER | 21:06 |
| racarr | for test runs | 21:06 |
| racarr | that's doable in 30 minutes :p | 21:06 |
| racarr | god you guys scared me | 21:06 |
| kgunn | racarr: thanks...if you could.... | 21:06 |
| racarr | I thought it was just like "none of the tests work" | 21:06 |
| kgunn | racarr: you have no idea | 21:07 |
| racarr | yeah will do it right now! | 21:07 |
| thomi | racarr: so.. we'd need to export that before unity8 started? | 21:07 |
| thomi | cos that runs inside upstart, so we'd need some upstart hacks as well | 21:07 |
| thomi | racarr: ? | 21:10 |
| thomi | I guess this also means that we can no longer run apps without the shell running? | 21:11 |
| racarr | thomi: https://code.launchpad.net/~robertcarr/unity-mir/disable-authorizer-env/+merge/188717 | 21:11 |
| racarr | yes | 21:11 |
| thomi | dandrader: veebers - you guys should probably read this conversation: ^^ | 21:11 |
| thomi | racarr: yes to which question? | 21:12 |
| racarr | yes we need to export it before unity 8 starts | 21:13 |
| racarr | I don't know how upstart environments work | 21:14 |
| racarr | presumably, as this is a required in 30 minutes solution, upstart can echo UNITY_MIR_DISABLE_SESSION_AUTHORIZER=1 to /etc/some/file/that/i/dont/know/the/name/of | 21:14 |
| racarr | and restart unity :p | 21:15 |
| racarr | err | 21:15 |
| racarr | upstart can echo, I mean | 21:15 |
| racarr | autopilot can echo | 21:15 |
| kgunn | veebers: ^ AP can echo ? | 21:17 |
| veebers | kgunn: yep, it can shell out or write a file etc. | 21:18 |
| veebers | I'm just reading the backlog to get context | 21:19 |
| kgunn | racarr: https://plus.google.com/hangouts/_/16ed3d4ac7bbdd50e109aaabbce63c149b8fb526?authuser=1&hl=en | 21:23 |
| racarr | brt | 21:25 |
| racarr | ill brb whole system performance | 21:26 |
| racarr | is awful | 21:26 |
| racarr | need to restart X | 21:26 |
| kgunn | thomi: so racarr is free ? | 21:42 |
| kgunn | ...or we still need the UNITY_MIR_DISABLE_SESSION_AUTHORIZER=1 to /etc/some/file/that/i/dont/know/the/name/of | 21:42 |
| racarr | seems unnnecessary because | 21:43 |
| thomi | kgunn: We probabyl won't need that | 21:43 |
| racarr | they have this desktop file hint workaround thing | 21:43 |
| thomi | but lets keep it around, just inc ase | 21:43 |
| thomi | thanks for that though racarr :) | 21:43 |
| racarr | ok, leaving for space burning man, see you guys in a month. | 21:43 |
| kgunn | :)) | 21:43 |
| racarr | ...:p | 21:43 |
| racarr | back to input injection | 21:45 |
| racarr | 80% done | 21:45 |
| racarr | reversing the lexicon and the assosciated tests is turning out to be really tedious | 21:46 |
| Saviq | racarr, btw, bug #1233245 - known issue? | 22:01 |
| ubot5` | bug 1233245 in unity8 (Ubuntu) "Volume up/down keys not working with Mir" [High,Incomplete] https://launchpad.net/bugs/1233245 | 22:01 |
| racarr | Saviq: new to me | 22:01 |
| Saviq | racarr, we're not getting any VolumeUp / VolumeDown keys - neither when there's an app in focus or not | 22:02 |
| Saviq | racarr, also, the fact that if you try starting unity8 when screen is blank results in "cannot unblank screen" and then you need to reboot, otherwise "address already in use" happens? | 22:02 |
| racarr | second one sounds like a stale unity 8 process is lingering | 22:03 |
| racarr | not sure what is supposed to happen when multiple procsses try and useHWC | 22:03 |
| racarr | first one...I think ugh | 22:03 |
| racarr | there may be an issue with unity8 actually getting key events because of the way its input areas work | 22:03 |
| racarr | its pretty unlikely that it would have key focus... | 22:03 |
| racarr | I guess, the first step would be to ensure mir_demo_server_input_filter produces key events on volume up/down but im almost certain it does (it certainly used to) | 22:04 |
| racarr | then to ensure a normal Qt client can receive them | 22:04 |
| racarr | and if so then the shell just isn't getting focus | 22:04 |
| racarr | but maybe they are getting lost in the Qt keymapping (As an example) which isn't tested much because OSK shortcircuits it | 22:05 |
| racarr | Saviq: probably the absolute first thing to try is run unity8 with MIR_SERVER_INPUT_REPORT=log and MIR_SERVER_LEGACY_INPUT_REPORT=log | 22:05 |
| racarr | and see how far the events get | 22:05 |
| racarr | ill start updating my phone ;) | 22:05 |
| racarr | but I can't spend a bunch of time on it right now, I need to power through this input injection thing | 22:06 |
| racarr | so we can get the HUD going | 22:06 |
| Saviq | racarr, yeah, k | 22:06 |
| racarr | mzanetti: Needs another hour or two of work before it can land but this should work: https://bugs.launchpad.net/mir/+bug/1233378 | 22:24 |
| ubot5` | Ubuntu bug 1233378 in Mir "Unity requires input injection API from Mir " [Undecided,In progress] | 22:24 |
| racarr | rtt | 22:24 |
| racarr | err | 22:24 |
| racarr | https://code.launchpad.net/~robertcarr/mir/input-injecter-api/+merge/188743 | 22:24 |
| sarnold | hrm, what does the #ifdef ANDROID _really_ mean here, and why does ANDROID platform not have std::make_shared? http://paste.ubuntu.com/6181654/ | 22:56 |
| racarr | sarnold: IT means is mir built with MIR_PLATFORM=android, i.e. are we using the android graphics drivers | 23:03 |
| racarr | android does have make_shared, the code is a little tricky to parse, on android it is returning a new instance | 23:03 |
| racarr | of the MirNativeBuffer object | 23:03 |
| racarr | on not android (GBM or nested) it is returning an empty shared pointer (null) of type MirNativeBuffer | 23:03 |
| racarr | "returning a new..." -> "returning a pointer to a newly allocated instance" | 23:04 |
| sarnold | racarr: thanks :) | 23:07 |
| thomi | racarr: still awake? | 23:45 |
| thomi | kgunn: the next issue seems to be input related - the autopilot input emulators don't have any effect on the launched applications. | 23:46 |
| thomi | as in, we try and tap on a button, and nothing happens | 23:46 |
| thomi | python | 23:47 |
| thomi | dammit, wrong window again | 23:47 |
| thomi | robert_ancell: who else can I ping about this? | 23:49 |
| racarr | thomi: oi | 23:52 |
| thomi | oh, you are awake :) | 23:52 |
| thomi | racarr: so.. any time I try and use the UInput touch driver that autopilot has, a big fat nothing happens on the screen | 23:52 |
| racarr | ok that is supposed to be synthetic udev devices right? | 23:53 |
| thomi | yes, essentially it's a user-space udev driver | 23:53 |
| racarr | It should work, so the first step is really to get MIR_SERVER_INPUT_REPORT=log and MIR_SERVER_LEGACY_INPUT_REPORT=log | 23:54 |
| racarr | then we should be able to see if the devices are loaded/recognized | 23:54 |
| racarr | and what happens | 23:54 |
| thomi | so, I should set those before starting unity8, and then paste you the unity8 log file? | 23:54 |
| thomi | I suspect the problem is that the udev device node only gets created when autopilot creates the touch device, which is long after the shell has started | 23:55 |
| thomi | does that sound plausible? | 23:55 |
| racarr | about pasting the log file and startying unity8: Yes :D lets get stderr and stdout | 23:55 |
| racarr | about the theory: It's plausible but device adding/removing should work | 23:55 |
| thomi | OK, I'll do that now | 23:56 |
| racarr | cool | 23:57 |
| racarr | we should have a MIR_DUMP_EVERYTHING_THAT_MAYHAPS_BE_USEFUL_FOR_DEBUGGING | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!