| === SAM113101 is now known as sam113101_afk | ||
| === sam113101_afk is now known as sam113101 | ||
| kgunn | duflu: do you know if FSM stand for "finite state machine" in the context of this bp ? https://blueprints.launchpad.net/ubuntu/+spec/client-1404-mir-rootlessx | 03:26 |
|---|---|---|
| duflu | kgunn: Sounds like a good guess :) | 03:26 |
| duflu | I don't know any other "FSM" | 03:27 |
| duflu | I think the "synaptics FSM" is something I've proposed fixes to in the past actually. The touch stuff is obviously a state machine | 03:31 |
| duflu | kgunn: I'd just note Synaptics is a brand and most devices using that code are not Synaptics. So maybe libsomethingelse is more appropriate. | 03:46 |
| duflu | It would be awesome if more devices used Synamtics, but seems more common are the cheaper Alps and Elan | 03:48 |
| tvoss | duflu, you ok with me top-approving https://code.launchpad.net/~vanvugt/mir/fix-r1049-regressions/+merge/191776 | 06:02 |
| tvoss | ? | 06:02 |
| duflu | tvoss: Yep | 06:02 |
| tvoss | duflu, done | 06:02 |
| * tvoss -> airport | 06:06 | |
| duflu | alf_: Froze? | 06:17 |
| alf_ | duflu: yes, back again | 06:19 |
| duflu | alf_: OK, meeting done I guess | 06:19 |
| duflu | alf_: I've never used a GL context in two threads simultaneously before like Mir does. How safe is it? | 06:38 |
| duflu | alf_: Oh. Apparently very safe as each DisplayBuffer gets a separate context :) | 06:40 |
| alf_ | duflu: Mir uses different shared contexts in different threads, which is safe. The only caveat is that you need to synchronize the creation of resource ids (e.g. textures) | 06:40 |
| duflu | alf_: Yes it was the texturing that worried me. But that's OK if it really is a separate context per display | 06:41 |
| duflu | alf_: Seen this? 1234563 | 06:48 |
| duflu | bug 1234563 | 06:48 |
| ubot5 | bug 1234563 in Mir "mir_demo_standalone_render_surfaces crashes in glDrawArrays" [Medium,Triaged] https://launchpad.net/bugs/1234563 | 06:48 |
| alf_ | duflu: let me try... is it consistently reproducible? | 06:50 |
| duflu | alf_: On saucy desktop it seems. Even after a full reinstall | 06:50 |
| alf_ | duflu: confirmed | 06:56 |
| duflu | Joy | 06:57 |
| duflu | Huh. That race condition I thought I saw... would only exist if display buffer compositors shared a renderer. But they don't | 06:58 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| duflu | Sigh. Maybe I can make better progress in the kitchen than I have in code today. | 10:09 |
| === dandrader is now known as dandrader|lunch | ||
| === alan_g is now known as alan_g|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| mterry | alf_, hello! You around? | 14:06 |
| === alan_g|lunch is now known as alan_g | ||
| alf_ | mterry: Hi! | 14:07 |
| mterry | alf_, OK, I have questions for you and/or alan_g about nested Mir... | 14:07 |
| alan_g | mterry: ask it then | 14:08 |
| mterry | alf_, so I tried to get a unity8 shell to talk to USC using the new-style MIR_SOCKET=fd://XX mode | 14:08 |
| mterry | And I ran into an error about Mir connection not being made. Upon investigation, it seems like qtubuntu and friends are designed for either being mirserver or mirclient, but not both. So I manually put in a mir_connect() call into unity8 for testing | 14:09 |
| mterry | Which presumably consumes the MIR_SOCKET fd. But then it looks like part of qtubuntu does later want to use MIR_SOCKET for its server parts later | 14:10 |
| mterry | And I get a Bad file descriptor error | 14:10 |
| alan_g | mterry: there's an example of using the fd mode in the mir_demo_server_basic example. | 14:11 |
| mterry | alf_, alan_g: I guess my question is, have you guys only tested on pure Mir, or have you actually got a qtubuntu-using app to do nested server mode? | 14:11 |
| alan_g | I'm not sure what you're doing with USC - I know robert_ansell was working on it at one point | 14:11 |
| alan_g | mterry: we've only done testing with the mir_demo_* | 14:12 |
| mterry | alan_g, yeah he was. USC is basically just the root Mir server. He's got some branches where it talks to lightdm and passes back fds for lightdm to hand to other sessions as MIR_SOCKET | 14:12 |
| alf_ | mterry: a qtubuntu app shouldn't care about whether it is talking to a nested or host server | 14:13 |
| mterry | I'm using those. It seems to work a little bit, but qtubuntu doesn't anticipate this use case, and I'm trying to see the easiest way to make it work | 14:13 |
| alf_ | mterry: or in this case app==unity8? | 14:13 |
| mterry | alf_, app==unity8 | 14:13 |
| mterry | alf_, there are ubuntumirclient and ubuntumirserver QPA plugins. And they each seem to assume it's only client or only server | 14:14 |
| mterry | I can propose a fix, I just am still uncertain what that fix is yet. I guess I'll look at the demo code. | 14:15 |
| === dandrader is now known as dandrader|afk | ||
| alf_ | mterry: why does unity8 need both ubuntumirclient and ubuntmirserver? It does all the rendering in-process so ubuntumirserver should be the only one it needs. Mir hides the details of being nested or not. | 14:17 |
| mterry | alf_, well, I guess that's my problem. It doesn't seem to | 14:17 |
| alan_g | mterry: does unity8 use both plugins in the non-nested case? | 14:18 |
| alan_g | Because it shouldn't know anything about being nested | 14:19 |
| mterry | alan_g, alf_: sorry, got disconnected. Not sure what you saw latest. But: should a nested Mir need to call mir_connect? | 14:23 |
| mterry | (on app/shell-side code) | 14:23 |
| alan_g | mterry: no | 14:23 |
| mterry | alan_g, OK. So my error I saw was probably unity-mir making assumptions and calling a piece of Mir code that required mir_connect... I'll dig into that side of things | 14:23 |
| mterry | Rather than go down the road of calling mir_connect myself | 14:24 |
| alan_g | mterry: it shouldn't do anything differently than in the standalone case | 14:24 |
| mterry | alan_g, OK, good to know | 14:24 |
| === dandrader_ is now known as dandrader | ||
| racarr | Good mirning! | 14:51 |
| alan_g | Good afternoon | 14:56 |
| mterry | alan_g, so during mir::run_mir (called by unity-mir), I'm getting that "connect not called" error. I think during DisplayServer construction. I wouldn't expect such an error during a mir-internal call, right? | 15:16 |
| mterry | alf_, ^ | 15:19 |
| alan_g | mterry: just looking for whre that comes from | 15:19 |
| mterry | sure | 15:20 |
| alf_ | mterry: it sounds like mir is using the nested path, but something isn't going as expected | 15:21 |
| alan_g | mterry: sounds like the connection doesn't get established. Does the fd actually exist in the nested process? | 15:22 |
| mterry | alan_g, theoretically. robert_ancell's branches do some clever fd passing around to make sure. What posix call tests fd existence? | 15:23 |
| alan_g | mterry: is it feasible to launch unity8 using mir_demo_server_basic --launch-client unity8 - and avoid USC? | 15:24 |
| alan_g | Or does it need some other setup? | 15:25 |
| mterry | alan_g, I could, as a test, sure. Let me get back to you | 15:26 |
| alan_g | mterry: obviously you need any switches to get it into nested mode | 15:27 |
| mterry | alan_g, well, mir_demo_server_basic sets MIR_SOCKET, right? That should auto-switch to nested-mode. | 15:27 |
| racarr | fcntl(fd, F_GETFD is the FD test | 15:27 |
| mterry | racarr, ah cool. I'll test that after this demo server test | 15:28 |
| alan_g | mterry: It does - I just didn't know if that was all you need | 15:28 |
| alan_g | racarr: Maybe we should use that to give a more helpful error message. | 15:29 |
| racarr | Seems useful. | 15:32 |
| racarr | The way the platform-api symbols are is a little weird for stuff like this | 15:34 |
| racarr | if you accidentally link libplatform-api-mirclient and libplatform-api-mirserver (nested unity8 shouldn't need platform API mirclient) | 15:34 |
| racarr | I guess you are going to get the wrong symbols? | 15:35 |
| racarr | maybe not, because we have the two different build QPAs with explicit linkage that are opened at runtime... | 15:35 |
| racarr | not sure how Qt loads them | 15:35 |
| racarr | *shrug* | 15:35 |
| mterry | alan_g, going through the demo, I get "Address already in use"... | 15:44 |
| mterry | alan_g, in about the same spot (DisplayServer constructor) | 15:45 |
| alan_g | mterry: try mir_demo_server_basic --standalone etc | 15:45 |
| mterry | alan_g, the server should fallback to standalone, since it doesn't have MIR_SOCKET, but ok | 15:46 |
| mterry | I'll also add --no-file | 15:47 |
| alan_g | mterry: Doh! that's the one I was thinking of | 15:48 |
| mterry | alan_g, aha! OK. That worked with --no-file. So the fd being bad somehow leads to the "mir not connected" message? | 15:50 |
| mterry | alan_g, so lightdm/usc must be fucking up the fd passing | 15:51 |
| alan_g | mterry: It seems that way - but Mir should be giving a better diagnostic | 15:51 |
| alan_g | I suspect it is hanging (or failing in some other bad way) in the connect call to a duff socket | 15:52 |
| * alan_g thinks he should log a bug | 15:54 | |
| racarr | perhaps old news to other people but I finally figured out how to get a a good terminal on the phone. lol. adb shell is always weird with some terminal programs (i.e. text editors tend to not work). ssh over nexus 4 wifi sucks | 16:10 |
| racarr | adb shell service ssh start | 16:11 |
| racarr | is where it's at | 16:11 |
| racarr | adb forward tcp:2222 tcp:22 | 16:11 |
| racarr | adb forward tcp:3768 tcp:3768 | 16:11 |
| racarr | ssh phablet@127.0.0.1 -p 2222 | 16:11 |
| racarr | err ignore the 3768 | 16:11 |
| racarr | thats some unity qml debug stuff lol | 16:11 |
| alf_ | kdub: @display-construction-overhaul2, do we need to access the native types outside of any of the other resources created with them? | 16:29 |
| kdub | the fb and the hwc? | 16:31 |
| alf_ | kdub: yes the native android types | 16:31 |
| kdub | i don't think so (if i understand the question properly :) ) | 16:33 |
| racarr | kdub: DisplayCommander, nice | 16:41 |
| kdub | hah :) i like that one too | 16:41 |
| alan_g | greyback: it's not immediately obvious to me which packages I need to compile unity-mir - so could you answer a quick question? Why does src/unity-mir/surfacecontroller.cpp need the line "#include <mir/surfaces/surface_stack_model.h>"? AFAICS it never uses the SurfaceStackModel definition. | 16:51 |
| greyback | alan_g: "sudo mk-build-deps -ir debian/control" should install what you need, no? | 16:52 |
| alan_g | greyback: ack was just remembering that | 16:52 |
| greyback | alan_g: it's needed for the constructor of the SurfaceController, so ms::SurfaceStackModel is defined | 16:53 |
| alan_g | But it only needs a declaration | 16:54 |
| kdub | greyback, haven't tried in a while, but have we sorted out how to cross compile those components? | 16:54 |
| kdub | apologies for asking again :) | 16:54 |
| alan_g | greyback: I still see "qmirserverapplication.h:20:27: fatal error: QGuiApplication: No such file or directory" | 16:55 |
| greyback | kdub: tbh I've not tried since you last asked. But I agree we need to solve this story. A properly working pbuilder arm chroot would be very nice | 16:55 |
| greyback | alan_g: have you "qtbase5-dev" installed? | 16:56 |
| alan_g | greyback: yes | 16:57 |
| greyback | alan_g: make clean, re-run 'qmake' and see if that works | 16:57 |
| greyback | and make ofc | 16:57 |
| alan_g | greyback: no change (and no target ofc) | 16:59 |
| alan_g | greyback: I'm hitting EOD anyway. Maybe it will work in the morning. (But I'm pretty sure that header isn't needed) | 17:00 |
| === alan_g is now known as alan_g|EOD | ||
| greyback | alan_g: ok, talk tomorrow | 17:01 |
| greyback | alan_g|EOD: if I remove that header, it fails to build. | 17:02 |
| alan_g|EOD | What's the error? | 17:02 |
| alan_g|EOD | greyback: What's the error? | 17:03 |
| greyback | alan_g|EOD: error: invalid use of incomplete type 'class mir::surfaces::SurfaceStackModel' | 17:04 |
| greyback | alan_g|EOD: EOD, we can deal with this tomorrow :) | 17:04 |
| greyback | sorry :D | 17:04 |
| alan_g|EOD | np | 17:04 |
| * alan_g|EOD wishes for the line number. But has to take wife out to eat. ;) | 17:05 | |
| kdub | racarr, (just bouncing naming suggestions around), how about "MonitorTraits" instead of "DisplayInfo" | 18:20 |
| racarr | kdub: I don't like monitor because monitors don | 18:27 |
| racarr | 't have a number_of_framebuffers_available | 18:27 |
| racarr | which is why I thought Output was nice. | 18:28 |
| kdub | yeah, but output is pretty overloaded | 18:28 |
| racarr | hmm | 18:28 |
| racarr | I think within the mga:: namespace it's relatively clear, Mir, graphics, android, output attributes | 18:29 |
| racarr | but not totally. | 18:29 |
| racarr | I didn't think DisplayInfo was that unclear | 18:30 |
| racarr | I think Attributes...to me carries a little more connotation that this is the configured information (i.e. the configured size, etc) | 18:31 |
| racarr | and not just the capabilities | 18:31 |
| racarr | which I think of as 'Info' but I'm not sure if the dictionary would back me up on that one aha | 18:31 |
| racarr | I think maybe it's just a struct instead of an interface | 18:32 |
| racarr | kdub: Hmm | 18:33 |
| racarr | is it just | 18:33 |
| racarr | the DisplayConfiguration? | 18:33 |
| kdub | eh, not quite | 18:33 |
| racarr | why? | 18:34 |
| kdub | i'd say a configuration would be the most expansive, so would include multimonitor configuration | 18:34 |
| racarr | an OutputConfiguration then perhaps | 18:34 |
| kdub | lets see what terms gbm has.. | 18:34 |
| racarr | I mean, it's the configuration of a single display/output/monitor and some properties which resutl from that configuration (i.e. number of framebuffers available) | 18:34 |
| racarr | but the thing is, presumably in multimonitor scenarios | 18:34 |
| racarr | this changes | 18:34 |
| racarr | which is why I thought the word "Configuration" might make sense | 18:35 |
| racarr | you don't expect the information for a display to change but of course the configuration does | 18:35 |
| kdub | in multimonitor, it doesn't change | 18:37 |
| kdub | its just the class for the attributes/traits of each monitor | 18:38 |
| racarr | kdub: Are you sure? I mean | 18:38 |
| racarr | if I have an external display hooked up | 18:38 |
| racarr | am I guaranteed the same number of framebuffers | 18:38 |
| racarr | at various resolutions etc | 18:38 |
| racarr | also...the size can change right? | 18:38 |
| kdub | size can't really change | 18:38 |
| racarr | oh yeah | 18:39 |
| racarr | I forgot android hal doesn't really do sophisticated monitor configuration | 18:39 |
| racarr | kdub: I will let it toss around in my head a little more...DisplayInfo isn't bad though | 18:43 |
| racarr | I do think that a struct with constant data members | 18:44 |
| racarr | is perhaps a little more clear | 18:44 |
| racarr | because it's more like just some immutable piece of info than an object right | 18:45 |
| kdub | eh, have to think about that | 18:45 |
| kdub | essentially, thats what it is already | 18:45 |
| racarr | ? from the consumer perspective the values can chance | 18:46 |
| racarr | change | 18:46 |
| racarr | they are just const member functions now right? or did I misread | 18:46 |
| kdub | they are const member functions | 18:48 |
| kdub | even at that though, i'd rather have the interface | 18:49 |
| racarr | I think it's better to enforce the immutability, and the struct is a little better for tests | 18:51 |
| racarr | because you don't have to write these, mock the interface, set the getter functions to return values | 18:51 |
| racarr | type tests...which I think | 18:51 |
| racarr | are more strong coupling than good tests | 18:52 |
| racarr | in many cases | 18:52 |
| kdub | it makes for more test structure, but doesn't increase coupling in the production code | 18:56 |
| kdub | if i want to rename a struct member vs rename a class function, same amount of churn | 18:56 |
| kdub | i guess i could make a struct with its copy/assign deleted | 18:57 |
| racarr | kdub: Except, you don't have to update the tests that are passing in literals like {size, format, number} | 19:01 |
| racarr | I mean if you were writing the test first, you wouldn't write some class like Stub or MockDisplayInfo and set it up to return the three const values right | 19:02 |
| racarr | you would pass them as a literal tuple to the consumer | 19:02 |
| racarr | and then verify the state | 19:02 |
| racarr | as opposed to the interaction (consumer calls get_size(), which really isn't actually very interesting) | 19:02 |
| kdub | i'm sure i did just that at one point, but i probably wrote the DisplayInfo tests before the other ones | 19:03 |
| racarr | :) I mean at this point with an existing code base, and refactoring v new stuff writing the tests first of course becomes blurry | 19:04 |
| racarr | but I just mean, in the ideal, if you were sitting down to write some new class | 19:04 |
| racarr | and you knew it needed to do some computation based on the display size, pixel format, and number of frame buffers | 19:05 |
| racarr | well I feel like I would probably use a struct and literals and not an interface | 19:05 |
| racarr | but *shrug* | 19:05 |
| kdub | i guess i have to program that struct in different ways | 19:08 |
| kdub | and don't know if i want to have two constructors for the struct | 19:09 |
| racarr | ? If the values don't change shouldn't you initialize it with | 19:12 |
| racarr | the values themselves | 19:12 |
| racarr | and not the objects which contain the state | 19:12 |
| kdub | these classes are wrappers around two different HAL's (which actually own the state) | 19:12 |
| kdub | HWCInfo does a bit more than FBInfo | 19:14 |
| racarr | kdub: That seems kind of strange to me and it feels more like two different objects using the HALs should pack the same kind of struct | 19:28 |
| racarr | but | 19:28 |
| racarr | I will do a deeper read of the code | 19:28 |
| racarr | and comment on launchpad | 19:28 |
| racarr | because im not sure exactly how it all links up | 19:28 |
| racarr | I think it's something about powerd with the android integration tests failing | 23:14 |
| racarr | kdub: The symtoms are pretty weird. If you 'stop unity8' while the screen is blanked...about 9/10 times | 23:14 |
| racarr | integration tests will then fail with the error to post to fb device | 23:14 |
| racarr | unity8 will not start back, etc | 23:14 |
| kdub | yeah, i'm not convinced we have that architecture worked out just yet | 23:15 |
| racarr | if you press power button, even though unity8 is dead | 23:15 |
| racarr | something happens | 23:15 |
| racarr | because now the integration tests will all pass | 23:15 |
| racarr | except the binary will hang while exiting | 23:15 |
| racarr | and that's as far as I've gotten | 23:15 |
| racarr | you cant kill it at that point lol | 23:15 |
| racarr | reading through powerd now | 23:16 |
| racarr | static void update_internal_state(void) | 23:19 |
| racarr | .... | 23:19 |
| racarr | .... | 23:19 |
| racarr | that is not the best function name ;) | 23:20 |
| kdub | racarr, you know how to use powerd-cli? | 23:30 |
| racarr | kdub: Oh. I sort of do now :p | 23:37 |
| racarr | kdub: Maybe I dont :p I was hoping to turn the display on with it | 23:40 |
| racarr | but it hangs | 23:40 |
| kdub | i just do 'powerd-cli display on', seems to work | 23:40 |
| racarr | kdub: After stopping unity8 while the display was off? | 23:41 |
| kdub | i just do that to keep the display on once its gotten to the on state | 23:42 |
| racarr | oh I see | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!