| RAOF | Clang once again to the rescue, with error messages that are (a) readable on a 1366x768 screen and (b) actually tell you what the error is. | 01:02 |
|---|---|---|
| duflu | RAOF: Any idea why we have all-the-X-things in staging now? Looks crowded... https://launchpad.net/~mir-team/+archive/staging | 02:03 |
| RAOF | duflu: Because we're about to go through the Xserver 1.14 transition, so I pushed that through staging first. | 02:06 |
| duflu | OIC | 02:06 |
| RAOF | And you can't just upload the server + any drivers with XMir changes, because the server ABI changed; you need the full enchilada. | 02:06 |
| RAOF | Hm. | 02:07 |
| RAOF | Dear filesystem: why is that file 0 bytes? | 02:08 |
| duflu | RAOF: New laptop yet? | 02:14 |
| RAOF | Nope. Should be shipping soon. | 02:14 |
| === duflu_ is now known as duflu | ||
| duflu | robert_ancell: Can you add this to 0.0.6? https://bugs.launchpad.net/mir/+bug/1130553 | 03:24 |
| ubot5 | Ubuntu bug 1130553 in Mir "Mir does not support eglSwapInterval(0)" [Medium,Fix released] | 03:24 |
| robert_ancell | duflu, done | 03:25 |
| duflu | Ta | 03:28 |
| === jono is now known as Guest27980 | ||
| tvoss | good morning :) | 05:06 |
| duflu | Morning tvoss | 05:33 |
| tvoss | duflu, hey :) how goes? | 05:34 |
| duflu | tvoss: Monday afternoon and still waking up. You? | 05:34 |
| tvoss | duflu, Monday morning, mostly awake :) | 05:34 |
| tvoss | although my caffeine level could be higher | 05:35 |
| duflu | It could always be higher... | 05:37 |
| duflu | To about 100 cups a day, which I believe is the lethal dose | 05:37 |
| didrocks | tvoss: hey | 06:25 |
| didrocks | how are you? | 06:26 |
| tvoss | didrocks, hey :) quite good, summer here in Germany. How about you? | 06:26 |
| didrocks | tvoss: same here, and seems the week will stay on that note ;) | 06:26 |
| tvoss | didrocks, hopefully :) So for Unity and Nux: I will push out those branches shortly | 06:27 |
| didrocks | summer finally \o/ (before apparently not so splending end of July and bad August) | 06:27 |
| didrocks | tvoss: excellent, you answered before even I asked! :p | 06:27 |
| tvoss | didrocks, sure :) | 06:27 |
| didrocks | tvoss: do you still have my branch somewhere? | 06:27 |
| tvoss | didrocks, let me find it :) | 06:27 |
| didrocks | should be https://code.launchpad.net/~didrocks/unity/new-gmock | 06:28 |
| tvoss | https://code.launchpad.net/~didrocks/unity/new-gmock | 06:28 |
| didrocks | :) | 06:29 |
| tvoss | didrocks, mind pinging me the gmock package location again? would like to check in a chroot | 06:32 |
| * duflu wonders who "Ken" is | 06:32 | |
| didrocks | duflu: kenvandine? | 06:35 |
| didrocks | or kevin duboi? | 06:35 |
| didrocks | duboit*? | 06:35 |
| duflu | didrocks: Kidding. I think your meant Kevin... https://code.launchpad.net/~didrocks/mir/use-system-googlemock/+merge/173008 | 06:35 |
| didrocks | ah Kevin ;) | 06:36 |
| duflu | I think I meant "you", not "your" | 06:36 |
| didrocks | duflu: more than possible, it's coffee-1 here (speaking of which…) ;) | 06:36 |
| didrocks | tvoss: https://code.launchpad.net/~didrocks/location-service/devsuggestsdoc/+merge/173136 | 06:37 |
| didrocks | tvoss: btw, you did approve it, but not globally approve? | 06:37 |
| tvoss | didrocks, done | 06:37 |
| didrocks | tvoss: thanks | 06:37 |
| didrocks | let me look for the location service gmock branch | 06:38 |
| didrocks | tvoss: https://code.launchpad.net/~didrocks/location-service/build-with-system-gmock | 06:38 |
| tvoss | didrocks, did you see my question for the new gmock package? | 06:38 |
| tvoss | didrocks, wanna propose that location-service branch? | 06:39 |
| didrocks | tvoss: we need to upload the gmock package first to distro, but sure, can propose | 06:40 |
| didrocks | tvoss: ppa:didrocks/ppa for the gmock package | 06:40 |
| didrocks | https://code.launchpad.net/~didrocks/location-service/build-with-system-gmock/+merge/173407 | 06:41 |
| tvoss | didrocks, approved but no top-approve yet | 06:48 |
| didrocks | tvoss: perfect, thanks! | 06:49 |
| duflu | alf___, hello... ? | 07:05 |
| alf___ | duflu: hi! | 07:06 |
| duflu | alf___: compositor_buffer(), is that actually latest_complete_buffer() ? | 07:07 |
| dholbach | good morning | 07:09 |
| duflu | Morning dholbach | 07:11 |
| dholbach | hi duflu | 07:11 |
| alf___ | duflu: it's the next buffer to be consumed by the compositor, it may be the latest submitted clien buffer or not (e.g. if the client has submitted two unprocessed buffers it's not the latest) | 07:11 |
| duflu | alf___, cool. But it is "complete" either way | 07:11 |
| alf___ | duflu: what does complete mean? | 07:12 |
| duflu | alf___, I mean the client has finished rendering to it | 07:12 |
| alf___ | duflu: yes | 07:12 |
| alf___ | duflu: @different-mesa-display-validation-functions, how about mir_server_mesa_egl_display_is_valid(), mir_toolkit_mesa_egl_display_is_valid()? | 07:15 |
| duflu | alf___, Argh. I think I prefer "server". We have outstanding tasks/arguments against "toolkit" | 07:15 |
| alf___ | duflu: mir_server_mesa_egl_display_is_valid(), mir_client_mesa_egl_display_is_valid() ? | 07:16 |
| duflu | alf___, I don't think my review was blocking really | 07:16 |
| duflu | alf___, Yup sounds better. I wonder if we're still inconsistent omitting "native". Bu that makes it longer | 07:17 |
| duflu | That reminds me. I meant to add a typedef for mir_bool to improve the client API readability | 07:18 |
| alf__ | duflu: mir_server_mesa_egl_native_display_is_valid(), mir_client_mesa_egl_native_display_is_valid(): perphaps they are not too bad considering only mesa (through dlsym) and a couple of tests will use them. | 07:33 |
| duflu | alf__: Yeah I'm undecided about "native". It's more consistent but makes it marginally too long. Abstain. | 07:34 |
| alf___ | duflu: (flaky connection may have lost messages) mir_server_mesa_egl_native_display_is_valid(), mir_client_mesa_egl_native_display_is_valid(): perphaps they are not too bad considering only mesa (through dlsym) and a couple of tests will use them. | 07:48 |
| duflu | alf___: Yeah I'm undecided about "native". It's more consistent but makes it marginally too long. Abstain. | 07:49 |
| duflu | alf___: I will use MPs/email for you from now on :) | 07:49 |
| === JoseAntonioR is now known as JoseeAntonioR | ||
| greyback | alf___: duflu: hi guys, either of you have good understanding of the input stack? | 08:04 |
| duflu | greyback: I have some experience from the client POV | 08:04 |
| greyback | duflu: it's more the server POV I'm asking from. But maybe you'll have an idea | 08:04 |
| greyback | Shell is a surface that will always be "on top". I also need shell to receive all input events, even with another surface has focus | 08:06 |
| greyback | so in my shell mir configuration, I can add a EventFilter to the chain of eventFilters - which is the solution I believe | 08:07 |
| duflu | greyback: Yeah InputFilters are meant to do that. But I'm not saying the design is perfect yet. Perhaps we need to marry InputFilters with a particular surface, sometimes | 08:07 |
| greyback | but what I need to be able to do is pass those Events to the shell input handler itself | 08:07 |
| duflu | greyback: The one from mir_surface_set_event_handler ? | 08:08 |
| greyback | duflu: yep | 08:08 |
| duflu | greyback: We could do that. We already merge multiple event sources into that behind the scenes in libmirclient | 08:09 |
| duflu | greyback: Not sure about specifics. Can you log an enhancement for racarr to look at too? | 08:09 |
| greyback | duflu: will do | 08:09 |
| greyback | thanks | 08:09 |
| duflu | No problems | 08:09 |
| duflu | -s | 08:09 |
| duflu | greyback: So that means you're linking libmirclient and libmirserver? | 08:10 |
| greyback | duflu: no I'm not | 08:10 |
| greyback | it's something I need to do from the server side | 08:11 |
| greyback | duflu: quick terminology check: EventFilter handles events, returns true if accepted, false if not. EventSink similar but always returns true? | 08:11 |
| greyback | i.e. doesn't allow events to propagate | 08:12 |
| duflu | greyback: Argh. I wrote EventSink and don't remember | 08:12 |
| * duflu checks | 08:12 | |
| duflu | greyback: EventSink is unconditional (returns void) | 08:13 |
| duflu | So that's kind of like true (handled) and false (continue to next sink) | 08:14 |
| greyback | duflu: ok, that's how I expected it. | 08:14 |
| duflu | Although AFAIK, we don't yet have chains of EventSinks. It's only ever 1:1 | 08:14 |
| greyback | that's ok | 08:15 |
| greyback | really my issue is, how to get the EventFilter associated with a Surface | 08:16 |
| duflu | greyback: Yeah it's a good question. But there might be architectural considerations racarr can think of before we dive in | 08:18 |
| tvoss | greyback, what are you trying to solve? | 08:18 |
| greyback | duflu: indeed. I'll get his advice | 08:19 |
| duflu | greyback: Actually I had thought of it already, and started. Some events already contain surface IDs. We need more of them to (input events too) | 08:19 |
| greyback | tvoss: the shell surface will always be on top of the application surfaces. I need also that the shell surface receives all events, even if application surfaces have focus. | 08:20 |
| duflu | So we need a mir_surface_post_event(event_caught_by_my_filter) | 08:20 |
| tvoss | greyback, hmmm, I would propose an event filter implementation that "knows" about the shell surface | 08:20 |
| greyback | tvoss: sounds right, yes | 08:21 |
| greyback | but the part I'm unable to solve is how to know get the event filter of the shell surface | 08:21 |
| duflu | greyback: How about just letting the filter "requeue" it conditionally and the event trickles down to the surface per usual? | 08:21 |
| greyback | duflu: that could work... | 08:22 |
| duflu | greyback: We should have it already. If filter returns false I would have thought it should go on to the surface... ? | 08:22 |
| duflu | Otherwise, what's the point in returning that bool? | 08:23 |
| greyback | duflu: true. I can't see why it wouldn't. I'll give it a go | 08:23 |
| duflu | greyback: Sounds vaguely like some input bugs I've encountered. So maybe it's just a little broken. But I think it is meant to work like that in theory | 08:24 |
| duflu | Of course, a filter can handle an event and still return false to send it on to the surface too. | 08:25 |
| greyback | duflu: ah there will be times when shell should accept the event, so application doesn't get it | 08:25 |
| duflu | greyback: Yes just return true in that case | 08:25 |
| duflu | Oh, I forgot. You need the surface handle still | 08:26 |
| duflu | OK | 08:26 |
| greyback | yep | 08:26 |
| duflu | greyback: So all you want to know is what was the surface that "would have" received the event, had it not been caught in the filter? | 08:28 |
| duflu | Of course, this is why XEvent has the window field :) | 08:29 |
| greyback | duflu: with my current understanding: I want a pointer to the event filter for surface x | 08:29 |
| greyback | because I think it makes most sense for me to grab the event filter of the shell, and push it to the start of the EventFilterChain. As is done in demo-shell | 08:30 |
| tvoss | greyback, +1 | 08:31 |
| tvoss | duflu, I think we can save the hassle of hit testing if greyback's filter implementation knows the shell surface and just passes on the event | 08:32 |
| duflu | tvoss: Yeah there might be a use case for redirection in future anyway. In which case we just want a send_event(event, surface) | 08:32 |
| duflu | Although it would be nice if input events told you the target surface ID too | 08:33 |
| tvoss | duflu, later down in the filter chain: yes, definitely. | 08:33 |
| tvoss | didrocks, down to one issue with mismatch between header files and library linked in for unity | 08:43 |
| didrocks | tvoss: phew, nice work! It seems they changed the API quite extensively (but not surprising in 2 years) | 08:44 |
| tvoss | didrocks, oh, it's more or less subtle: testing::internal::String is now std::string and the linker gets confused | 08:44 |
| didrocks | tvoss: am I the only one to think there are too many internal replications of std types in unity btw? | 08:45 |
| tvoss | didrocks, not sure what you are referring to | 08:46 |
| didrocks | tvoss: the glib::string types and all those kinds of mapper | 08:47 |
| tvoss | didrocks, oh yeah, that's ugly, but still: I don't think we should touch that code until absolutely necessary | 08:47 |
| didrocks | tvoss: agreed, that's why I wasn't sure the mismatch with latest gmock was due to something like that, I didn't take time to look at it closely TBH | 08:47 |
| tvoss | didrocks, different question: assume that I would like to install test executables. Where would be the most appropriate place to put them? | 08:56 |
| didrocks | tvoss: I think we would create a binary -tests package | 08:57 |
| didrocks | tvoss: not sure what's the point for non integration tests though | 08:57 |
| tvoss | didrocks, basic smoke testing could benefit from being able to run the tests against an existing image | 08:58 |
| tvoss | didrocks, mir is not the best example for that approach, but platform-api is | 08:58 |
| didrocks | tvoss: ok, so tests for the integration with the rest of the platform (libs, perfs and so on) | 08:58 |
| didrocks | yeah, I think a -tests package is reasonable | 08:58 |
| tvoss | didrocks, yup | 08:58 |
| tvoss | didrocks, what about the path? /usr/bin? | 08:59 |
| didrocks | tvoss: I would prefer libexec to not polluate the $PATH | 08:59 |
| tvoss | didrocks, ack. btw: for nux, we need bregma's help, my autoconf foo is not sufficient | 08:59 |
| didrocks | tvoss: sounds good :) | 08:59 |
| duflu | alan_g: Why does mir_demo_server* lose/hide/mangle stdout and stderr? | 09:10 |
| duflu | Sometimes I can see part of one line, but that's all | 09:10 |
| alan_g | duflu: I didn't know it did | 09:10 |
| alan_g | it shouldn't | 09:10 |
| duflu | Hmm maybe it's only when I run it from the VT. Maybe the VT output is blocked | 09:10 |
| alan_g | alf___: ^ | 09:11 |
| alf___ | duflu: If you mean that you lose the output that should be output to the VT, that's normal since we put the VT in graphics mode. If you mean that you lose output after having redirected it, then that's a problem. | 09:13 |
| duflu | alf___, OK normal is good | 09:14 |
| duflu | I'll use ssh for debugging | 09:14 |
| alf___ | duflu: (or redirect to a file for non-live debugging) | 09:14 |
| duflu | alf___, Yep thanks | 09:14 |
| * duflu stresses his GPU so much that it makes a /new sound/ | 09:16 | |
| RAOF | Wow. They're not lying when they say clang's static analyser makes compilation slow. | 09:25 |
| duflu | RAOF: BTW confirmed clang on saucy works well. So well I can actually run clang-built mir with it | 09:34 |
| duflu | Tho, clang's binaries are slightly slower | 09:35 |
| RAOF | Feel like trying -O4? :) | 09:38 |
| * alan_g thinks the point of supporting clang is that the binaries work | 09:38 | |
| duflu | Clang was just to improve code scanning... and to further prove the correctness of the code. Yes. | 09:39 |
| RAOF | Also error messages. | 09:40 |
| duflu | Yes, how could I forget clang's lovely colours | 09:45 |
| duflu | ? | 09:45 |
| tvoss | didrocks, https://code.launchpad.net/~thomas-voss/unity/new-gmock/+merge/173450 | 10:01 |
| didrocks | tvoss: building and testing :) | 10:02 |
| didrocks | tvoss: argh, failing to build, but it's because I don't have the right xorg version yet | 10:16 |
| didrocks | tvoss: I'll wait for the current proposed migration to finish | 10:16 |
| tvoss | didrocks, okay | 10:16 |
| tvoss | didrocks, ack | 10:17 |
| RAOF | Wow. clang-analyse finds only 22 bugs in Mir, of which only 5 are actually in our code, most of which are in the demos. | 10:22 |
| alan_g | RAOF: *Only*? That's 22 too many! (How many are legit bugs?) | 10:30 |
| RAOF | Of the 5 I've looked at, it's not clear that 3 of them are bugs, one is an obvious bug, and one is a not-checking-for-errors. | 10:32 |
| alan_g | That's pretty good. IME static analysis tools can create a LOT of false positives. | 10:34 |
| * alan_g decides to look himself later | 10:35 | |
| RAOF | Enjoy: https://code.launchpad.net/~raof/mir/fix-two-clang-analyse-results/+merge/173462 | 10:36 |
| RAOF | Hm, first result in android-input also looks legit. | 10:42 |
| RAOF | Ah, and the protobuf ones would be because clang doesn't understand GOOGLE_CHECK(), which I presume will evaluate to either an exception or an assertion. | 10:44 |
| alan_g | alf__: RAOF - do you guys recognise "/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libEGL.so: undefined reference to `mir_egl_mesa_display_is_valid'" - I'm getting that on trunk this morning | 10:56 |
| RAOF | alan_g: We *have* been poking around that area of the code, but I thought we'd removed all the direct linkages. | 10:57 |
| * RAOF checks his checkout. | 10:57 | |
| alf__ | alan_g: RAOF: Yes, I don't see any direct linkage that could cause this error, what does 'ldd /usr/lib/gcc/x86_64-linux-gnu/libEGL.so' say? | 10:59 |
| alan_g | alf__: "ldd: /usr/lib/gcc/x86_64-linux-gnu/libEGL.so: No such file or directory" ;) | 11:00 |
| alf__ | alan_g: oops, ldd /usr/lib/x86_64-linux-gnu/libEGL.so | 11:01 |
| alan_g | alf__: ;) http://paste.ubuntu.com/5855073/ | 11:02 |
| alf__ | alan_g: objdump -p /usr/lib/x86_64-linux-gnu/libEGL.so ? | 11:04 |
| alan_g | alf__: http://paste.ubuntu.com/5855080/ | 11:05 |
| alf__ | alan_g: that's not right: "NEEDED libmirclient.so.1", so you need to update your mesa version, and I also need to push some naming changes to trunk, just a moment | 11:07 |
| alan_g | alf__: looks like I should read upgrade info more carefully - http://paste.ubuntu.com/5855087/ | 11:10 |
| alf__ | alan_g: :) | 11:11 |
| alf__ | RAOF: Is the Mesa in staging uploaded automatically when your repo changes? | 11:19 |
| RAOF | alf__: Yes. | 11:19 |
| RAOF | After an hour or so. | 11:20 |
| RAOF | There *is* a manual step of propagating the changes from the egl-platform-mir branch to the mir-ppa branch. | 11:20 |
| RAOF | Hm. Again with the everything-deadlocking-in-the-kernel. | 11:33 |
| * RAOF goes to sleep, like his kernel. | 11:34 | |
| === hikiko is now known as hikiko|lunch | ||
| === alan_g is now known as alan_g|lunch | ||
| === hikiko|lunch is now known as hikiko | ||
| === alan_g|lunch is now known as alan_g | ||
| alan_g | alf__: are you happy with https://code.launchpad.net/~alan-griffiths/mir/SessionMediator-session-race/+merge/173247? | 13:26 |
| alf__ | alan_g: looks good, although I was under the impression that each SessionMediator would need to handle only one request at a time | 13:50 |
| alan_g | alf__: I don't think there's anything stopping asio starting a new request while an existing one is running. And then there are shutdown cases... | 13:52 |
| alf__ | alan_g: yeah, I guess my impression came from the client side, where we have a single thread servicing client requests... | 13:52 |
| netlar | does Mir use the Gallium open source driver? | 14:56 |
| alan_g | netlar: I don't think that's been tried. alf__ ^? | 15:00 |
| alf__ | netlar: Mir uses the Mesa drivers on the desktop. The radeon and nouveau drivers are implemented using Gallium3D internally. | 15:02 |
| netlar | alf__: So it should be very similar to X.org | 15:07 |
| alf__ | netlar: the plan is not to be :D | 15:07 |
| netlar | alf__: I do wonder if my graphics card will be supported | 15:08 |
| netlar | I have a Radeon 7750, has the Cape Verde chipset | 15:08 |
| alf__ | netlar: (but in terms of hardware support it would be similar) | 15:08 |
| netlar | Is that because it is going to use the Mesa and Gallium drivers? | 15:09 |
| alf__ | netlar: yes | 15:11 |
| netlar | alf__: Is there a list of radeon cards that have full support, becuase I think my card is still in testing stage | 15:12 |
| alf__ | netlar: http://xorg.freedesktop.org/wiki/RadeonFeature/ | 15:12 |
| netlar | thanks | 15:13 |
| netlar | One more question please | 15:14 |
| netlar | Is it going to be recommended to use the open source driver over the binary driver? | 15:15 |
| kdub | netlar, whichever one works and is best suited to your preferences, I suppose | 15:23 |
| netlar | kdub: I have always had trouble with the binary driver. Just I do not get any 3d performance with the open source driver | 15:24 |
| racarr | Morning! | 15:26 |
| kgunn | didrocks: just a quick check...how are we for xmir into universe? | 15:28 |
| kdub | hello racarr | 15:28 |
| didrocks | kgunn: I think xmir will just be a patch on top of xorg? That's how RAOF wants to deal with it AFAIK | 15:29 |
| racarr | Hi kevin :) | 15:29 |
| kgunn | yep | 15:29 |
| kgunn | racarr: hey | 15:29 |
| didrocks | kgunn: personnaly, every daily release but Mir because of the bug lists I tagged 1.5 weeks ago :) | 15:29 |
| didrocks | everything* | 15:29 |
| racarr | and hello also kevin :D | 15:29 |
| racarr | kgunn: I see you cancelled mir/unity sync...that must mean its done right? | 15:29 |
| kgunn | racarr: you wish :) | 15:30 |
| kgunn | racarr: greyback was looking fwd to chatting today | 15:30 |
| greyback | racarr: hey! | 15:30 |
| kgunn | i just cancelled the regular meeting....cause we weren't being very regular | 15:30 |
| kgunn | figured we'd just go ad-hoc | 15:30 |
| racarr | greyback: Hey! | 15:30 |
| racarr | want to sync up in say...15 min? | 15:30 |
| greyback | racarr: sounds good | 15:31 |
| racarr | I am still waiting for brian to come online | 15:31 |
| racarr | ok great | 15:31 |
| racarr | brb | 15:31 |
| kdub | racarr, can I book a sync on remove-surface-target with you after that? :) | 15:31 |
| racarr | kdub: Ok | 15:31 |
| kgunn | didrocks: so we are good for daily release but not in universe | 15:31 |
| kgunn | ? | 15:31 |
| didrocks | kgunn: no, mir doesn't build on armhf/powerpc AFAIK | 15:32 |
| didrocks | kgunn: so this is still blocking daily | 15:32 |
| didrocks | (we can skip tests for both for daily, but we need the tests running on armhf for universe) | 15:32 |
| kgunn | didrocks: this is what i was wanting to confirm with you....e.g. can we skip armhf/powerpc tests for daily | 15:33 |
| kgunn | didrocks: my bad....didn't realize the intree gmock issue was still open | 15:34 |
| didrocks | kgunn: yeah, but not for distro (at least, armhf) | 15:34 |
| didrocks | kgunn: this is blocking for universe, I've done most of the patching | 15:34 |
| didrocks | (7 components involved) | 15:34 |
| didrocks | tvoss finished unity | 15:34 |
| didrocks | the remaining one is nux | 15:34 |
| didrocks | I tvoss asked bregma to do it? | 15:34 |
| didrocks | think* | 15:34 |
| tvoss | didrocks, not yet | 15:35 |
| alf__ | netlar: proper support for you chipset recently landed upstream (kernel+mesa) and it should be soon landing in distributions, so expect the situation to improve | 15:36 |
| kdub | kgunn, i think we need a task to have the tests run 'driverless' on armhf | 15:36 |
| kdub | or at least skip the tests without proper driver support | 15:36 |
| bregma | I think we need to disable all integration tests within the package build, because they make no sense and give no useful results | 15:36 |
| didrocks | bregma: can we have them as autopilot tests then? if they are integration tests? (I'm still wondering what they are testing then on i386 and amd64 ;)) | 15:38 |
| bregma | the tests that fail on armhf do not run on other platforms because they require the andoid drivers | 15:38 |
| didrocks | bregma: so yeah, autopilot tests that can be triggered dynamically if a file is present maybe? | 15:39 |
| didrocks | (like a file from qtubuntu-android) | 15:39 |
| netlar | alf__: that is great news. and that would include 3d support? | 15:39 |
| alf__ | netlar: yes | 15:42 |
| netlar | woohoo, love it | 15:42 |
| racarr | greyback: Ok inviting you to a hangout whenever it's good | 15:51 |
| greyback | racarr: go for it | 15:51 |
| racarr | from my phone so I dont have a url | 15:51 |
| racarr | but you hould get it in G+ | 15:51 |
| racarr | greyback: Not working? | 15:52 |
| greyback | racarr: just managed to get into G+ now | 15:52 |
| greyback | racarr: lp:~gerboland/+junk/qml-demo-shell/ | 15:59 |
| racarr | kdub: Want to talk about remove-surace-target now? | 16:01 |
| kdub | racarr, sure | 16:01 |
| racarr | kdub: Ok trying to invite you on G+ | 16:02 |
| === tvoss is now known as tvoss|dinner | ||
| racarr | greyback: Working some on the demo shell | 18:42 |
| racarr | just installed a SurfaceBuilder to assign DepthIds | 18:42 |
| racarr | so now clients open under the shell and transparency works, etc | 18:43 |
| greyback | racarr: nice | 18:43 |
| racarr | I still need to figure out why focus is broken | 18:43 |
| greyback | racarr: though for me, clients were opening under shell and transparency was working | 18:44 |
| greyback | but all's good :) | 18:44 |
| greyback | I'm using a build of mir that's over a week or two old I think | 18:44 |
| racarr | oh | 18:44 |
| racarr | tht would explin it | 18:44 |
| racarr | the stacking order was backwards actually | 18:44 |
| greyback | aha | 18:44 |
| racarr | but it wasn't noticeable because we | 18:44 |
| racarr | used the hiding every other surface | 18:45 |
| greyback | that explains a lot then, yes | 18:45 |
| racarr | rather than restack approach | 18:45 |
| racarr | but the shell surface isn't | 18:45 |
| racarr | um | 18:45 |
| racarr | subject to that | 18:45 |
| greyback | tho still, the second app opened under shell, on top of first one... | 18:45 |
| greyback | anyway, am building latest mir to check things out | 18:45 |
| racarr | because | 18:45 |
| racarr | the irst one was hidden | 18:45 |
| racarr | it was actually "under" the first one still | 18:46 |
| greyback | racarr: yep, makes sense | 18:46 |
| racarr | greyback: "Makes sense" | 18:47 |
| racarr | XD | 18:47 |
| greyback | well, it explains why what I was seeing was happening | 18:49 |
| greyback | you know what I mean | 18:49 |
| bschaefer | hey, so im hitting a fun problem: | 18:57 |
| bschaefer | (EE) Failed to load /usr/lib/xorg/modules/drivers/intel_drv.so: /usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: xorgMir | 18:57 |
| bschaefer | seems theres a new intel driver the mir ppa hasn't been built with? | 18:57 |
| tvoss|dinner | bschaefer, did you pin the ppa? | 18:59 |
| racarr | greyback: Of course :) | 18:59 |
| bschaefer | tvoss|dinner, pin the ppa? | 18:59 |
| tvoss|dinner | bschaefer, making sure that updates from the archive that are newer than the ppa don't override the ppa packages | 19:01 |
| bschaefer | tvoss|dinner, o, well thats a nice features... and no I have not pined it, which I should have :) | 19:01 |
| kdub | racarr, i'm teasing out the state from ms::Surface, and looking at the transformation | 19:06 |
| kdub | seems that its just used by the graphics side, but will the input side need the transform eventually? | 19:07 |
| === tvoss|dinner is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| racarr | kdub: Yes. | 19:12 |
| kdub | racarr, thought so, i'll just put that info in the generic info about the surface | 19:13 |
| kdub | for anticipated future use :) | 19:13 |
| racarr | Excellent | 19:18 |
| tvoss | bschaefer, http://www.olli-ries.com/running-mir/ | 19:20 |
| tvoss | greyback, ping | 19:20 |
| greyback | tvoss: pong | 19:20 |
| bschaefer | tvoss, thanks | 19:21 |
| tvoss | bschaefer, yw | 19:21 |
| kgunn | racarr: just reading the scrollback...i guess client focus notif is broken huh?...so nvmd my last question about it | 19:37 |
| racarr | kgunn: It's 90% done. I just need to find time to come bck to the branch | 19:59 |
| kgunn | racarr: np | 19:59 |
| greyback | racarr: you fixed it? https://code.launchpad.net/~robertcarr/mir/fix-input-obscurance/+merge/173586 | 20:13 |
| racarr | greyback: Yes the other thing is | 20:14 |
| racarr | greyback: lp:~robertcarr/+junk/demo-shell-with-surface-controller | 20:14 |
| racarr | it's kind of a hack | 20:14 |
| racarr | in one place | 20:14 |
| racarr | the shell is using..Window 1 a the surface name apparently? (maybe somewhere in papi or qtubuntu) | 20:15 |
| racarr | and it just matches on tht to stack the shell surface higher | 20:15 |
| greyback | racarr: ok. No idea what's setting the surface name. Probably papi, need to check | 20:16 |
| greyback | is qtubuntu. WIll need to make that harder to guess | 20:31 |
| robert_ancell | kgunn, these are the blocker bugs for entering the archive https://bugs.launchpad.net/mir/+bugs?field.tag=entering-saucy | 20:55 |
| robert_ancell | (matches what we said) | 20:55 |
| kgunn | yep | 20:55 |
| olli | kgunn, https://blueprints.launchpad.net/ubuntu/+spec/mir-testing fyi | 20:58 |
| olli | I will add a BP for the cert test rollout | 20:58 |
| kgunn | olli: ack | 20:59 |
| === francisco is now known as Guest93946 | ||
| kdub | ms::Surface is shaping up :) | 21:55 |
| === JoseeAntonioR is now known as j | ||
| === j is now known as JoseeAntonioR | ||
| === JoseeAntonioR is now known as jose | ||
| kgunn | olli: let me know what you think https://blueprints.launchpad.net/ubuntu/+spec/mir-testing | 22:43 |
| kgunn | robert_ancell: bregma ^ | 22:43 |
| * bregma looks | 22:44 | |
| robert_ancell | kgunn, is this supposed to be mir or unity testing? | 22:44 |
| robert_ancell | kgunn, as I read it this is tests on Unity 7 on X, and then followed up later with the same tests on XMir? | 22:47 |
| kgunn | robert_ancell: yes thats the idea | 22:49 |
| kgunn | its a bit of regression testing combined wirh perf/ux | 22:50 |
| robert_ancell | kgunn, ok, the name of the bp is a bit confusing, but the tests / rationale seem good | 22:50 |
| robert_ancell | kgunn, I believe some of these tests should already exist right? | 22:50 |
| bregma | OK, might want to add Super-S (a known problem performer in the past) and some FPS numbers for something like glxgears as a general representation of games | 22:51 |
| racarr | greyback: For surface destruction I guess you could use the surface builder for notification but it's a little weird | 23:01 |
| racarr | the session listener could be extended | 23:01 |
| greyback | racarr: a bit yes, but it would work. | 23:05 |
| kgunn | bregma: ack.... | 23:12 |
| kgunn | will add | 23:12 |
| thomi | robert_ancell: Is the mir-team responsible for the ubuntu platform API? | 23:28 |
| robert_ancell | thomi, no, see ricmm_ and others | 23:28 |
| thomi | robert_ancell: OK, last time I asked I was told that the mir team would be taking over responsibility some time in the future. Is that still the case? | 23:28 |
| robert_ancell | thomi, not that I'm aware of | 23:29 |
| robert_ancell | kgunn, ^ ? | 23:29 |
| thomi | ok, good to know - want to make sure I don't drop the wrong person in it ;) | 23:29 |
| kgunn | thomi: mmm, where's that rumor coming from? | 23:31 |
| kgunn | thomi: altho we do contribute to it in a way sometimes | 23:32 |
| thomi | kgunn: I asked someone about it in Oakland... I think it was tvoss? | 23:32 |
| kgunn | but i think that api is quite broad....e.g. convenience api's for an os basically | 23:32 |
| kgunn | so even things like vcr functionality for music/video etc. | 23:32 |
| kgunn | note...i've been known to be wrong | 23:33 |
| kgunn | thomi: btw...since you're here....i see mir-stress on jenkins | 23:33 |
| kgunn | so is there an extra step to make it part of ci ? | 23:33 |
| thomi | kgunn: ugh... that thing is killing me slowly. | 23:33 |
| thomi | kgunn: The job needs to be re-worked. I'm having huge trouble provisioning a machine and running mir on it. First I tried using UTAH, but when that failed miserably, I'm now tryingn an lxc container and otto | 23:34 |
| thomi | it's been cauing me much stress - the bloody tests are there, but getting them to run is much harder than it ought to be | 23:35 |
| kgunn | thomi: thanks for continuing to chase...i think you've proven them to be good tests which caught quite a few bugs | 23:46 |
| thomi | kgunn: it certainly catches bugs, it's a pain that sooo much work is involved integrating it with our existing infrastructure | 23:47 |
| kgunn | thomi: hmmm....is there any help to be called in ? any other experts to lean on or bang ideas against ? | 23:49 |
| thomi | kgunn: I'm already leaning on people - my time zone gets in the way, as does the fact that at the moment my Internet connection is intermittent at best | 23:49 |
| kgunn | thomi: well, if there's anyway to do something clever with your problem and sharing it...let me know...its definitely something we want | 23:51 |
| thomi | yeah, will do | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!