| mhall119 | RAOF: hey, I was just going to ask if you had any indication from ickle about that patch rejection, other than what was in the git log and NEWS file | 00:00 |
|---|---|---|
| RAOF | mhall119: No, I've not. | 00:00 |
| mhall119 | I really feel sorry for him, sounds like he's in an unpleasant spot | 00:00 |
| RAOF | I don't know; I don't have a feel for Intel-internal politics. | 00:01 |
| RAOF | robert_ancell: https://code.launchpad.net/~raof/mir/prebump-abi-for-lifecycle-cookie/+merge/184703 ? | 00:52 |
| robert_ancell | RAOF, cool. I have the u-s-c change in lp:~robert-ancell/unity-system-compositor/app-lifecycle - still feels a bit clunky though | 00:57 |
| jrr | I tried out mir last night (installed unity-system-compositor , open source radeon driver), and the whole display had small black stripes (say, 5px normal, 5x black, 5px normal... across the whole thing) | 00:57 |
| jrr | is this known, or should I re-repro and file a bug? | 00:57 |
| robert_ancell | RAOF, so the logic for XMir needs to be, don't grab input devices on startup until you get lifecycle state set to "mir_lifecycle_state_resumed". Drop them on "mir_lifecycle_state_will_suspend" | 00:58 |
| robert_ancell | jrr, just file a bug and we'll mark it duplicate if there is already one | 00:58 |
| jrr | alright, will do | 00:59 |
| RAOF | robert_ancell: And then tell Mir that it's done, right? | 00:59 |
| robert_ancell | RAOF, yes, once we can do that | 00:59 |
| robert_ancell | RAOF, and if I don't hear from you in a reasonable amount of time I just drop your connection :) | 01:00 |
| RAOF | :) | 01:00 |
| robert_ancell | RAOF, how can I build a local XMir to test this? | 01:01 |
| RAOF | ./autogen.sh --prefix=$HOME/.local --enable-xmir && make -j9 && make install | 01:01 |
| robert_ancell | RAOF, have you made the switch from surface focus to app lifecycle on master? | 01:02 |
| RAOF | No, I haven't yet. | 01:02 |
| * robert_ancell -> lunch | 01:02 | |
| * RAOF → coffee | 01:04 | |
| ricmm | RAOF: no, thats not how the application model is defined | 01:08 |
| ricmm | applications are given a long timeframe to save their state | 01:09 |
| ricmm | theres no calling back into the server to signal state saving completion | 01:09 |
| ricmm | its a hard policy scenario, the client has no say in the time/resource constraints associated with its lifecycle | 01:09 |
| RAOF | My reading of the application lifecycle doc was that the on_application_about_to_stop callback would “3. Wait for timeout or completion then SIGSTOP the process.” | 01:11 |
| RAOF | Which implies to me that the unity API needs some way to signal completion? | 01:12 |
| RAOF | Not that *client code* would be calling it; we don't expect clients to use libmirclient directly anyway. | 01:12 |
| RAOF | ricmm: ^^^ | 01:14 |
| tvoss__ | RAOF, nope, the client just receives the signal, and is granted a grace period for serialization | 01:18 |
| tvoss__ | a.k.a. state preservation | 01:18 |
| ricmm | RAOF: if the document says that then it is wrong, will need to update it | 01:19 |
| tvoss__ | ricmm, taking an AI to update | 01:19 |
| ricmm | thanks | 01:19 |
| tvoss__ | ricmm, might be later my day, though | 01:20 |
| tvoss__ | google docs are a bit difficult in this place | 01:20 |
| ricmm | no worries, about time to sleep over here | 01:21 |
| ricmm | RAOF: consider that 3. item broken, tvoss will update document, applications only get signaled of an about_to_suspend() transition | 01:21 |
| ricmm | or a resumed() transition if they are previously-stopped applications | 01:21 |
| ricmm | otherwise they start from 0, its up to applications to restore their state from their serialization targets | 01:22 |
| ricmm | thnks for taking an interest in clarifying the design guidelines | 01:23 |
| * ricmm -> beer/sleep | 01:23 | |
| RAOF | Hm. | 01:44 |
| RAOF | I'd prefer if 3. *wasn't* broken, and I'm not sure why we're adamant that it is. | 01:44 |
| robert_ancell | RAOF, what's the document link? | 02:03 |
| RAOF | robert_ancell: https://docs.google.com/a/canonical.com/document/d/186nT03Jyu_d-GMyJ--8Qp83o1Ey-O1EsWZtwrPGE2TQ/edit | 02:03 |
| robert_ancell | RAOF, hmm, I'm not seeing how this can be completed without the shell being signalled when a client has completed | 02:09 |
| RAOF | robert_ancell: I think they're just going to not bother with the "until completed" | 02:13 |
| RAOF | robert_ancell: So instead it's ‘SIGSTOP after $TIMEOUT’ | 02:13 |
| RAOF | Rather than SIGSTOP after $TIMEOUT or completion, whichever happens first. | 02:14 |
| RAOF | Which I think is the trivially better behaviour, so I'm not sure why they're adamant that it should not be that way. | 02:14 |
| robert_ancell | RAOF, right, but the component that does the killing is the shell right? Which means it has to know when completion occurs to do the killing. Unless the platform API has a separate thread that does the killing if the function call doesn't return in a sufficient time | 02:15 |
| robert_ancell | I'm not sure how this is all implemented | 02:15 |
| RAOF | robert_ancell: No, it can just assume that completion has occurred by $TIMEOUT. | 02:15 |
| RAOF | ie: the shell sends the "about_to_suspend" signal, and then in 10 seconds SIGSTOPs the client. | 02:16 |
| robert_ancell | RAOF, oh, I guess the process will quit before 10s if it is successful, so the "complete" signal is the process termination | 02:17 |
| robert_ancell | RAOF, in our case where we don't actually want the process to quit, it doesn't work so well | 02:17 |
| RAOF | Oh, no. | 02:17 |
| RAOF | The process doesn't quit. | 02:17 |
| robert_ancell | or in the case of the shell, it might not be the process termination but the Mir client connection quitting | 02:17 |
| RAOF | It just has no completion signal. | 02:17 |
| robert_ancell | RAOF, so the shell has 0 idea if the process is actually suspended? | 02:18 |
| RAOF | Correct | 02:18 |
| robert_ancell | ah | 02:18 |
| RAOF | Well, the shell knows, because it's sent SIGSTOP | 02:18 |
| RAOF | It has no idea if the process has *saved its state* | 02:18 |
| RAOF | Which I think is silly. | 02:19 |
| robert_ancell | yes | 02:19 |
| RAOF | So I'm going to continue hacking on the cookie branch and then land it when they come to their senses. | 02:19 |
| robert_ancell | :) | 02:19 |
| robert_ancell | I don't see any reason not to send the signal back to the shell | 02:19 |
| RAOF | Right. | 02:19 |
| robert_ancell | The apps won't ever know | 02:20 |
| RAOF | The shell doesn't have to *wait* for the signal | 02:20 |
| robert_ancell | and it will be make debugging a lot easier | 02:20 |
| RAOF | Yes. | 02:20 |
| robert_ancell | rather than just guessing if an app actually suspended | 02:20 |
| RAOF | And, hell, we'll be able to send SIGSTOP *sooner* | 02:20 |
| robert_ancell | RAOF, does SIGSTOP free up any resources except for CPU? | 02:21 |
| RAOF | And give interesting metrics, like ‘your app took 5s to suspend, which is getting close to the 10s timeout…’ | 02:21 |
| RAOF | robert_ancell: No | 02:21 |
| robert_ancell | I suppose it allows the kernel to page out all the memory for that app | 02:21 |
| RAOF | Yeah. | 02:21 |
| RAOF | But the kernel could page out all but one page of the app anyway. | 02:21 |
| RAOF | (Assuming a reasonable app that's blocked when mir_swap_buffers is blocked) | 02:22 |
| robert_ancell | and all apps will be like that :) | 02:22 |
| === chihchun_afk is now known as chihchun | ||
| ricmm | RAOF: consider it a no-op to the display server itself | 03:41 |
| ricmm | if you want I can rewrite in a way that the Mir protocol itself needs not understand what the passed message means | 03:42 |
| RAOF | I think it makes perfect sense for the Mir protocol to understand? | 03:43 |
| RAOF | I'm not sure why having a ‘Yo! I've finished this thing you asked me to do’ callback is a bad idea. | 03:43 |
| ricmm | well I believe saying "until they come to our senses" is out of place | 03:43 |
| ricmm | its irrelevant, this was planned ages ago | 03:43 |
| RAOF | It doesn't prevent us from having a hard timeout. | 03:43 |
| ricmm | for functionality scheduled to land for 13.10 | 03:44 |
| ricmm | and which has been in place since a long time ago | 03:44 |
| ricmm | Mir being the new player in the game | 03:44 |
| RAOF | For a little context: Robert and I would like for this callback to exist, because it's really useful for unity-system-compositor to know when XMir's done handling the "please suspend" message. | 03:45 |
| ricmm | I dont think you need to care about the timeout or not, the lifecycle policy itself is up to the shell to implement | 03:45 |
| ricmm | not the display server | 03:45 |
| ricmm | *policy* | 03:45 |
| RAOF | But the shell is a part of the display server. Not the display server policy, certainly, but the callback gives the shell a mechanism for better policy. | 03:46 |
| ricmm | hmmm | 03:47 |
| ricmm | I'm sorry but the display server is a library that the shell implements | 03:47 |
| ricmm | the display server imposing non-display-server policy on the shell is wrong | 03:47 |
| RAOF | But this isn't imposing policy? | 03:47 |
| ricmm | yes, the shell and therefore the system can decide what policy to implement regarding application management | 03:47 |
| ricmm | the display server != application manager | 03:47 |
| RAOF | If the shell wants to ignore the completion event that's well within its rights? | 03:48 |
| ricmm | the shell *defines* the existance of an event at all | 03:48 |
| ricmm | maybe the mistake was exposing it Mir in terms of defined semantics | 03:48 |
| ricmm | it should've just been an opaque message passing over a bus | 03:49 |
| RAOF | An extensible Mir protocol. Yeah, that would have been a good idea :) | 03:49 |
| ricmm | sure, but this is what we have due to lack of assigned man power | 03:50 |
| ricmm | if it doesnt fit the XMir world, extend it | 03:50 |
| ricmm | and make it fit, without breaking the touch world | 03:50 |
| RAOF | Sure, that's what I intend to do. | 03:50 |
| ricmm | great, but dont extend the lifecycle states, feel free to add extra stuff to the protobuf message itself | 03:51 |
| ricmm | because the first interferes with the defined model | 03:51 |
| RAOF | But the cleanest way to do that is to add a completion event to the lifecycle callback added the client passes to libmirclient. | 03:52 |
| RAOF | That doesn't extend the lifecycle states, nor does it interfere with the model at all. | 03:52 |
| ricmm | that is not going to happen before post-October planning | 03:52 |
| ricmm | it demands extending a model that has been in place for many months now | 03:52 |
| RAOF | What? | 03:52 |
| RAOF | No it doesn't! | 03:52 |
| ricmm | and it is not something that will be considered for development 4 weeks before delivery date | 03:52 |
| RAOF | I don't see how it extends the lifecycle model? | 03:53 |
| ricmm | well first of all I dont see why the *display* *server* needs to care about an application having saved its state | 03:53 |
| ricmm | that souns like session/application management | 03:54 |
| ricmm | am I wrong to think that? | 03:54 |
| RAOF | Not particularly, but session/application management is also handled through Mir. | 03:55 |
| ricmm | *if* you are doing some sort of session management in Mir to support XMir itself then thats XMir's problem (which only runs legacy applications, afaik) | 03:55 |
| === chihchun is now known as chihchun_afk | ||
| RAOF | This is true. | 03:55 |
| === chihchun_afk is now known as chihchun | ||
| RAOF | ricmm: So, http://bazaar.launchpad.net/~raof/platform-api/update-for-lifecycle-cookie/revision/149 is what this would look like, platform-api side. | 04:28 |
| === duflu is now known as duflu|away | ||
| robert_ancell | ricmm, the session management is u-s-c managing its children (i.e. XMir), not the applications running underneath those (i.e. the X clients). It's the same logic as in the shell - when an application is no longer visible, then it should be triggered to suspend. In this case, when you switch sessions the old session is asked to "suspend" and it stops reading input (and potentially could do more if it wanted) | 05:39 |
| robert_ancell | gtg, bye all | 05:40 |
| alf_ | RAOF: Hi! Any thoughts on https://lists.ubuntu.com/archives/mir-devel/2013-September/000376.html ? | 05:41 |
| RAOF | alf_: Not really, no. | 05:44 |
| RAOF | Although... hm. | 05:44 |
| RAOF | It's possible that you're running afoul of the name caching that i965 does? | 05:44 |
| alf_ | RAOF: ? | 05:49 |
| RAOF | In intel_context.c, intel_process_dri2_buffer | 05:50 |
| === duflu|away is now known as duflu | ||
| alf_ | RAOF: ah, yes, we were trying various things in there with Marteen yesterday but unfortunately didn't fix the problem | 06:04 |
| RAOF | Ah, ok. | 06:04 |
| alf_ | RAOF: (not to say that the problem isn't there, perhaps we didn't try the right fix :)) | 06:05 |
| RAOF | ☺ | 06:05 |
| alf_ | RAOF: I am just saying that we haven't exhausted the investigation of what could be going wrong in intel_process_dri2_buffer with PRIME fds | 06:06 |
| smspillaz | RAOF: does xmir copy the entire root window (as it lives in gpu memory) to a mir surface (which also lives on the gpu)? | 06:09 |
| smspillaz | or does it copy and blit each subwindow directly | 06:09 |
| RAOF | Entire root window | 06:09 |
| duflu | smspillaz: Damage rects only | 06:09 |
| smspillaz | ah, that makes sense | 06:09 |
| smspillaz | yep +1 | 06:10 |
| RAOF | I'd like to subwindow it, actually. | 06:10 |
| RAOF | But that's a discussion for next week. | 06:10 |
| smspillaz | RAOF: that would probably make sense for the noncomposited case | 06:10 |
| duflu | smspillaz: At least the intel DDX seems to loop through the rectangles and take as little as possible each frame | 06:10 |
| RAOF | duflu: The other DDXen are similar, but they copy the bounding-box of the damage | 06:11 |
| RAOF | smspillaz: Indeed. | 06:11 |
| duflu | Close (and efficient) enough | 06:11 |
| duflu | RAOF: In fact, possibly _better_ for cache performance | 06:11 |
| RAOF | Indeed | 06:11 |
| smspillaz | RAOF: I guess that's why some parts of xmir had to live in the ddx | 06:12 |
| RAOF | Doesn't Intel gate on the number of rectangles, though, and do the bounding box given sufficiently many rectangles? | 06:12 |
| smspillaz | because the 2d accel parts are all different wherever you look | 06:12 |
| RAOF | smspillaz: Right | 06:12 |
| duflu | RAOF: Not AFAIK... it copies the rects as they're given | 06:12 |
| smspillaz | cool | 06:12 |
| smspillaz | I was just explaining to someone why xmir stuff had to live in the drivers and wanted to make sure I understood the code correctly | 06:13 |
| duflu | Speaking of which, I must set up a saucy nouveau today. To figure out which bugs are truly common | 06:13 |
| RAOF | There's a long-term intent to do a generic xf86-video-mir using Mir's EGL platform and Glamor, but that's a lot more effort and likely to be less performant. | 06:13 |
| alf_ | duflu: @https://lists.ubuntu.com/archives/mir-devel/2013-September/000379.html, I think the OP is using fglrx? | 06:15 |
| smspillaz | RAOF: as I thought | 06:16 |
| smspillaz | RAOF: just to confirm, xwayland works by forcing all windows ot live on the cpu right? | 06:16 |
| smspillaz | or at least the root window | 06:16 |
| smspillaz | erm | 06:17 |
| smspillaz | normal windwos actually | 06:17 |
| smspillaz | its rootless | 06:17 |
| smspillaz | (so that they can be used as a wl_buffer via shm) | 06:17 |
| RAOF | No, XWayland also has DDX patches | 06:17 |
| duflu | alf_: Possibly a good point, but not true for the existing reporters of that bug | 06:17 |
| alf_ | duflu: sure, just for this particular instance | 06:18 |
| smspillaz | RAOF: ah okay | 06:18 |
| smspillaz | RAOF: I wonder what's to us from having ddx patches which all they do is "copy damaged bit from PixmapPtr to fd however you like" | 06:19 |
| RAOF | smspillaz: It's just that there's exactly one maintained xwayland DDX patch - intel. I wrote the ati and nouveau patches a year ago, and they're somewhat out of date. | 06:19 |
| duflu | alf_: Unless it _is_ possible to start Mir with radeon while fglrx kmod is loaded? | 06:19 |
| RAOF | smspillaz: Well, xwayland *doesn't* copy from the PixmapPtr; it shares the backing BO with weston, and submits damage rects. | 06:20 |
| alf_ | duflu: no idea if it's possible... | 06:21 |
| smspillaz | RAOF: oh weird | 06:21 |
| RAOF | smspillaz: Nah, it's perfectly sensible for a client-allocated model. | 06:21 |
| smspillaz | I guess that makes sense actually | 06:22 |
| smspillaz | because xserver was allocating anyways | 06:22 |
| smspillaz | I wonder how hard it would be to beat the xserver into accepting some foreign buffer | 06:22 |
| smspillaz | probably quite hard | 06:22 |
| RAOF | No, pretty easy actually. | 06:26 |
| RAOF | If we single-buffered in Mir I could totally do that for XMir. | 06:26 |
| smspillaz | RAOF: ah, right | 06:26 |
| duflu | RAOF: BTW, single buffering in SwitchingBundle recently became impossible in order to simplify the logic. But I could add it back in easily enough | 06:29 |
| RAOF | I don't think we particularly want to use single-buffering. | 06:29 |
| duflu | True | 06:30 |
| duflu | That's a new one. Unity panel takes up a quarter of the screen height | 06:36 |
| duflu | RAOF: How do I disable i915 and let nvidia/optimus rule? | 06:47 |
| RAOF | duflu: In your bios? | 06:52 |
| duflu | RAOF: No such option. Either intel only, or both intel+nv with intel given control of all outputs except VGA :( | 06:52 |
| RAOF | duflu: You *may* have luck with /sys/kernel/debug/vgaswitcheroo | 06:53 |
| RAOF | But it's also possible that the nvidia card is *only* hooked up to VGA | 06:53 |
| duflu | RAOF: It certainly looks like nvidia only talks to the VGA port. That's quite annoying and unexpected | 07:01 |
| RAOF | Not entirely unexpected. Hardware muxes cost money. | 07:02 |
| RAOF | And suck a bit anyway | 07:02 |
| duflu | No wonder it cost me so little :/ | 07:02 |
| RAOF | (Unless you do fancy things, like Apple do/did) | 07:02 |
| duflu | Great. Then I still have only intel hardware for saucy/xmir testing. | 07:02 |
| RAOF | Except for the vga port? :) | 07:03 |
| duflu | RAOF: I particularly needed dual monitor testing | 07:04 |
| RAOF | Hm. Less useful. | 07:04 |
| duflu | Oookay. Perhaps I need a second desktop and prerequisite electrical upgrades to the house :/ | 07:13 |
| mlankhorst | alf_: oh btw are you sure it didn't help things? if so can you please do a strace of the failing process? | 07:15 |
| mlankhorst | with patches applied | 07:15 |
| mlankhorst | I only care about the failing instance, maybe it will show a clue of what's wrong | 07:16 |
| alf_ | mlankhorst: ok, just be sure (because I am applying the patches to a local tree), I only care about the intel changes from the diff, right? | 07:16 |
| mlankhorst | what other changes are there in that diff? | 07:17 |
| alf_ | various other bits here and there e.g. in the gallium state tracker | 07:22 |
| mlankhorst | oh just some whitespace fixups | 07:22 |
| alf_ | mlankhorst: @populating region.name, if we are dealing with prime fd buffers, won't all incoming buffer only have the .fd field populated? Setting the region flink name, won't help us avoid recreating the region. Am I missing something? | 07:24 |
| mlankhorst | why wouldn't it? | 07:26 |
| mlankhorst | if 2 buffers ar equal the flink name would be the same | 07:27 |
| mlankhorst | but.. mayb3e stracea will help find the issue | 07:28 |
| duflu | RAOF: Did you (or someone) hack xserver-xorg-video-intel to fix initial mode selection? | 07:29 |
| duflu | It's *different* now | 07:29 |
| alf_ | mlankhorst: sure, but the incoming buffers don't have the .name field set, just the .fd field, so they will always compare unequal to the region. Unless, that is, the buffer information is also updated somehow? | 07:31 |
| mlankhorst | alf_: oh like that.. | 07:31 |
| mlankhorst | alf_: ugh how could that be the case for dri buffers? o.O | 07:33 |
| mlankhorst | oh right, mir backend is mapped to dri2 | 07:34 |
| mlankhorst | bah, I'll need to think about it some more.. grr:P | 07:35 |
| RAOF | duflu: Hm, not deliberately? :) | 07:37 |
| duflu | RAOF: Oh, one definite change seems to be that the intel DDX no longer accepts NullRegion (now crashes) | 07:39 |
| RAOF | Yeah. We should never be passing in NullRegion, though. | 07:39 |
| RAOF | Are we? | 07:39 |
| mlankhorst | dun dun duuuun | 07:42 |
| alf_ | mlankhorst: that sounds ominous :) | 07:42 |
| duflu | RAOF: No, but I may need to as a workaround. Unless I can figure out how to fix the intel code :P | 07:44 |
| duflu | RAOF: Did you investigate https://bugs.freedesktop.org/show_bug.cgi?id=68969 ? | 07:46 |
| ubot5 | Freedesktop bug 68969 in Driver/intel "xf86-video-intel 2.99.901 + XMir + multimonitors = all displays black" [Normal,Resolved: notourbug] | 07:46 |
| RAOF | duflu: I did have a look, but didn't get as far as reproducing. | 07:47 |
| RAOF | duflu: I pulled the latest xmir patch from ickle's branch into the latest Ubuntu package, though, so it's some other change in the tree breaking it. | 07:50 |
| alf_ | RAOF: https://github.com/RAOF/mesa/pull/4 | 07:56 |
| RAOF | alf_: Hm. What frees dri2_surf in that case? | 07:58 |
| alf_ | RAOF: dri2_surf is just a cast of surf to dri2_egl_surface, they are the same thing | 08:00 |
| RAOF | ...urgh. Quite true! | 08:00 |
| mlankhorst | alf_: hm i have a fix for i965, i think | 08:01 |
| * alf_ is excited... | 08:01 | |
| mlankhorst | http://paste.debian.net/37818/ | 08:03 |
| mlankhorst | no idea if it works though or if the fd is correct ;;p | 08:05 |
| alf_ | mlankhorst: thanks, will check | 08:06 |
| duflu | RAOF: It *looks* like the intel DDX is tracking its own damage per-pixmap, and XMir's multi-monitor optimization of only submitting outputs/pixmaps when dirty is confusing it. Any ideas? I'm going round in circles | 08:26 |
| alf_ | mlankhorst: no luck, bug still occurs? Do you want me to get an strace? | 08:33 |
| mlankhorst | definitely | 08:33 |
| alf_ | mlankhorst: btw, I tried another experiment: I also pass the GEM name with the incoming buffer (name provided by Mir), but use the fd to create the buffer, and setting the name in the region manually with flink (like the previous patches). I still get the bug, which indicates that the core problem may not be (only) in intel_process_dri2_buffer() | 08:38 |
| mlankhorst | alf_: fun :p | 08:39 |
| mlankhorst | alf_: oops, can you set singlesample_mt->region->handle = region->handle in intel_miptree_create_for_dri2_buffer ? | 08:52 |
| alf_ | mlankhorst: sure | 08:52 |
| mlankhorst | it would appear I missed that part on importing bo's, so it was still 0 ;) | 09:00 |
| alf_ | mlankhorst: https://github.com/afrantzis/mesa/tree/egl-platform-mir-egl-image-i965-experiment | 09:24 |
| alf_ | mlankhorst: (https://github.com/afrantzis/mesa.git branch egl-platform-mir-egl-image-i965-experiment) | 09:24 |
| mlankhorst | alf_: do you close the original gbm bo afterwards? | 09:27 |
| mlankhorst | or at any point | 09:27 |
| alf_ | mlankhorst: the BOs are closed only when the Mir surface is destroyed | 09:28 |
| mlankhorst | what about the pixmap created with dri2_create_image_khr_pixmap | 09:29 |
| mlankhorst | do you ever close that one? | 09:29 |
| alf_ | mlankhorst: also when the surfaces are destroyed (the bo and respective EGL images are created lazily when the compositor/clients needs them the first time). | 09:30 |
| mlankhorst | ok but this definitely looks wrong here.. | 09:30 |
| mlankhorst | + dri2_img->dri_image = | 09:31 |
| mlankhorst | + dri2_dpy->image->createImageFromName(dri2_dpy->dri_screen, | 09:31 |
| mlankhorst | + width, | 09:31 |
| mlankhorst | + height, | 09:31 |
| mlankhorst | + format, | 09:31 |
| mlankhorst | + flink_arg.name, | 09:31 |
| mlankhorst | + stride / 4, | 09:31 |
| mlankhorst | + NULL); | 09:31 |
| alf_ | mlankhorst: ok, what is wrong with it? | 09:31 |
| mlankhorst | you can't use FLINK internally | 09:32 |
| mlankhorst | you'd need to use the dupimage call, assuming it works | 09:34 |
| alf_ | mlankhorst: it doesn't... | 09:34 |
| mlankhorst | what happens when you try? | 09:35 |
| alf_ | mlankhorst: the call succeeds but I still get errors further down when rendering, even when using GEM names | 09:35 |
| alf_ | mlankhorst: let me paste... | 09:36 |
| mlankhorst | alf_: yes probably, but it's more correct than flinking | 09:36 |
| alf_ | mlankhorst: here is the strace output with USE_DUP 1 , http://paste.ubuntu.com/6087181/ | 09:39 |
| mlankhorst | still more correct | 09:40 |
| alf_ | mlankhorst: btw, why can't I FLINK? Note that this is still happening at the EGL platform level, outside any driver specific context. | 09:40 |
| mlankhorst | alf_: because there is no refcounting in drm | 09:40 |
| mlankhorst | if you close 1 handle, everything is invalid. userspace has to explicitly keep track themselves | 09:40 |
| alf_ | mlankhorst: I am only getting the global name, I am not opening/closing anything | 09:42 |
| mlankhorst | alf_: you are creating a new representation of the bo through createImage. | 09:42 |
| mlankhorst | alf_: but regardless in this case the problem didn't change.. can you add extra traces to libdrm/intel to the GEM_CLOSE calls? | 09:45 |
| alf_ | mlankhorst: I guess that is drm_intel_gem_bo_free(), sure | 09:48 |
| mlankhorst | with indication of which handle closed, I'm not good enough to understand that part from the ioctl numbers yet :P | 09:50 |
| alf_ | mlankhorst: http://paste.ubuntu.com/6087259/, with USE_DUP = 1 | 10:01 |
| duflu | I give up | 10:09 |
| === dandrader is now known as dandrader|afk | ||
| mlankhorst | alf_: what do close messages look like? | 10:11 |
| alf_ | mlankhorst: "drm_intel_gem_bo_free: ..." | 10:12 |
| mlankhorst | alf_: because I see some handles that are being re-created after close | 10:13 |
| mlankhorst | however due to flushing they may not be killed right away after destroying | 10:13 |
| mlankhorst | alf_: I think mir needs to be smarter, and cache the fd's. check if it's seen them before or not and if so re-use them.. | 10:17 |
| mlankhorst | or better yet | 10:17 |
| mlankhorst | allocate them on the client side and give them to mir for use | 10:17 |
| alf_ | mlankhorst: so instead of sending the Prime FD every time, send it once and then send an another id back and forth? | 10:20 |
| mlankhorst | alf_: no, keep the fd cached on the client side, don't close it | 10:20 |
| === dandrader|afk is now known as dandrader | ||
| alf_ | mlankhorst: hmm, I think we are already doing this in the client | 10:30 |
| alan_g | alf_: I may have missed the context, but we have two client processes in the chain - nested-mir and the application. Both get passed the fd | 10:36 |
| RAOF | Yeah, we cache fds. | 10:39 |
| alf_ | alan_g: This is about buffer fds used by the final application. (As you know) nested-mir creates the surface/buffers itself. | 10:43 |
| alan_g | alf_: Ok then. Sorry for the noise | 10:44 |
| === chihchun is now known as chihchun_afk | ||
| === hikiko is now known as hikiko|lunch | ||
| === alan_g is now known as alan_g|lunch | ||
| === hikiko|lunch is now known as hikiko | ||
| === dandrader is now known as dandrader|lunch | ||
| kgunn | RAOF: you and ricmm all ok ? | 12:17 |
| kgunn | :) | 12:17 |
| === dandrader|lunch is now known as dandrader | ||
| === alan_g|lunch is now known as alan_g | ||
| alan_g | alf_: Are you OK with the updated https://code.launchpad.net/~alan-griffiths/mir/spike-nested-input/+merge/184351? | 13:15 |
| alf_ | alan_g: approved | 13:20 |
| alan_g | alf_: thanks | 13:20 |
| mlankhorst | alf_: anyway the final application is messing up here, nothing the nested mir could do would cause -ENOENT here unless they share the drm fd.. :P | 13:48 |
| === jono is now known as Guest88427 | ||
| === mzanetti is now known as mzanetti|meeting | ||
| alf_ | mlankhorst: the final application gets the drm fd so it can use it with mesa | 14:07 |
| alf_ | mlankhorst: and handles everything through it (and libmirclient) | 14:07 |
| alf_ | mlankhorst: through it == mesa | 14:08 |
| mlankhorst | alf_: yes, but is the same fd shared between mesa and nested mir? | 14:15 |
| === alan_g is now known as alan_g|tea | ||
| alf_ | mlankhorst: yes (of course not with the same fd number, but the same underlying file) | 14:21 |
| alf_ | mlankhorst: host mir, nested mir and clients/mesa use dup()-ed fds that point to the same drm file instance | 14:24 |
| === mzanetti|meeting is now known as mzanetti | ||
| kgunn | didrocks: ping | 14:30 |
| didrocks | kgunn: pong | 14:31 |
| kgunn | didrocks: hey...been a while, hope time off was good | 14:31 |
| kgunn | didrocks: just wanting to know...are you ok with resolution here | 14:31 |
| kgunn | https://bugs.launchpad.net/xmir/+bug/1221209 | 14:31 |
| ubot5 | Launchpad bug 1221209 in unity-system-compositor (Ubuntu) "need to establish upgrade action when xmir becomes default" [Undecided,New] | 14:31 |
| didrocks | kgunn: was excellent, thanks! In a sprint in Boston this week (so investigating some part of holidays to travel ;)) | 14:31 |
| * didrocks looks | 14:31 | |
| kgunn | didrocks: basically...robert recommending reboot on xmir distro roll out | 14:32 |
| didrocks | kgunn: yeah, it sounds good (and the right way to implement it) | 14:33 |
| kgunn | didrocks: cool...just wanted to make sure we're ok (before the 11th hour gets here :) | 14:33 |
| didrocks | kgunn: but I think people won't reboot every 4 hours for now (as we release every 4 hours) | 14:33 |
| didrocks | kgunn: so, it comes back to the discussion about ABI stability, is it coming so that we can remove the "hack" for forcing rebuilds in both u-s-c and unity-mir? | 14:33 |
| didrocks | seems I was disconnected… | 14:34 |
| didrocks | 10:33:11 didrocks | kgunn: yeah, it sounds good (and the right way to implement it) | 14:34 |
| didrocks | 10:33:29 didrocks | kgunn: but I think people won't reboot every 4 hours for now (as we release every 4 hours) | 14:34 |
| didrocks | 10:33:54 didrocks | kgunn: so, it comes back to the discussion about ABI stability, is it coming so that we can remove the "hack" for forcing | 14:34 |
| didrocks | | rebuilds in both u-s-c and unity-mir? | 14:34 |
| didrocks | kgunn: ^ | 14:34 |
| kgunn | didrocks: do you recall if there is a bug for that hack ? if not...i'll log one...and tag it for "make-xmir-default" | 14:35 |
| kgunn | https://bugs.launchpad.net/xmir/+bugs?field.tag=make-xmir-default | 14:35 |
| didrocks | kgunn: indeed, let me log it as a bug, one sec | 14:35 |
| === alan_g|tea is now known as alan_g | ||
| kgunn | didrocks: oh..thanks...yeah, i think its a seperate issue from the reboot discussion | 14:35 |
| didrocks | kgunn: it's linked as because of this, it means that potentially, we force every 4 hours people to reboot | 14:37 |
| didrocks | as we rebuild u-s-c as soon as there is a commit in Mir | 14:38 |
| kgunn | didrocks: true...i see the link...just saying, it deserves its own bug | 14:38 |
| didrocks | kgunn: https://bugs.launchpad.net/xmir/+bug/1223393 | 14:39 |
| ubot5 | Launchpad bug 1223393 in XMir "ABI stability of libmirserver" [Undecided,New] | 14:39 |
| didrocks | let me add the tag | 14:39 |
| didrocks | kgunn: TBH, I think ABI stability needs to happen in the incoming 2 weeks | 14:40 |
| didrocks | seeing how far we are, we need to try to stabilize now | 14:40 |
| kgunn | didrocks: no doubt | 14:40 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === tkamppeter__ is now known as tkamppeter | ||
| hikiko | bye | 15:12 |
| mlankhorst | alf_: ARRRRRRRGHHHHHH | 15:19 |
| mlankhorst | ARGHH | 15:19 |
| mlankhorst | bad alf_ | 15:19 |
| mlankhorst | bad! | 15:19 |
| alf_ | mlankhorst: ? | 15:19 |
| mlankhorst | alf_: if any client closes the bo, they will be closed for all clients.. | 15:20 |
| mlankhorst | you can't dup the drm fd for that reason | 15:20 |
| alf_ | mlankhorst: but open()-ing a new drm_fd works? | 15:23 |
| mlankhorst | yes | 15:23 |
| alf_ | mlankhorst: and possibly sending it over a unix socket? | 15:23 |
| mlankhorst | it will, but the dup is why it fails | 15:24 |
| mlankhorst | if the nested mir closes their bo it was closed on the other one too :P | 15:24 |
| mlankhorst | causing the -ENOENT out of nowhere | 15:24 |
| alf_ | mlankhorst: ok, I will try to de-dup() and see if that helps. Note, though, that I don't think we are explicitly closing anything during rendering... | 15:26 |
| mlankhorst | maybe, but it will at least nail the issue down to the process causing it | 15:26 |
| alf_ | mlankhorst: ah, sorry for the false alarm, we actually fixed that long ago... we drmOpen() a new fd and send it to clients :/ | 15:29 |
| alf_ | mlankhorst: but hmm... | 15:33 |
| alf_ | mlankhorst: I actually see a dup() in NestedMir... I will get rid of this and check what is going on | 15:35 |
| alf_ | mlankhorst: removed stray dup() in nested mir, no change :/ | 16:31 |
| alan_g | kgunn: nested input works on android drivers. (still needs more test coverage, but sort of there) - https://code.launchpad.net/~alan-griffiths/mir/missing-links-to-wire-up-input/+merge/184824 | 16:48 |
| kdub | alan_g, yay | 16:49 |
| alan_g | kdub: let's forget about this mesa stack. ;) | 16:50 |
| kgunn | alan_g: wow!...i guess input was easier than render | 16:51 |
| kgunn | awesome! | 16:51 |
| alan_g | kgunn: all the input problems were in code we "own" | 16:52 |
| kdub | alan_g, we could table it! http://translate.google.com/#es/en/mesa | 16:52 |
| alan_g | kdub: sadly, in the UK "table it" means something different. | 16:53 |
| kdub | need to find an idiom translator now... | 16:53 |
| alan_g | http://en.wikipedia.org/wiki/Table_(parliamentary_procedure) | 16:54 |
| alan_g | Anyway, a good point for... | 16:55 |
| === alan_g is now known as alan_g|EOD | ||
| kgunn | kdub: so technically mterry could take your android updates+ alan_g|EOD 's input and try to integrate greeter against it | 16:59 |
| kdub | kgunn, sure, it would be easier if its the ubuntu touch shell/greeter (qml apps?) as opposed to lightdm and xmir though | 17:00 |
| racarr | I think I've come up with a way to rebuild message processor + socket session + session mediator | 17:38 |
| racarr | that will fix this DPMS IPC issue but it's kind of invasive | 17:38 |
| racarr | wondering if I should run with it, or refocus on perhaps doing DPMS for XMir via some out of channel API for the time being | 17:39 |
| kdub | racarr, whats the plan? | 17:40 |
| racarr | kdub: So the essentialy difficulty is now, that the message reading loop runs like | 17:41 |
| racarr | Step -1: Begin read in constructor | 17:42 |
| racarr | Step 0: Respond to asynbc read | 17:42 |
| racarr | Step 1: Allow the message processor and session mediator to fully handle the message (i.e. then say block on Surface::advance_buffer | 17:42 |
| tvoss_ | racarr, why is that? I thought we tried to avoid blocking event loops and be as parallel as possible? | 17:43 |
| racarr | STep 2: Schedule the next asynchronous read. | 17:43 |
| racarr | tvoss_: No, the way it's architected now we can't read a second message from a client until a first is fully processed | 17:43 |
| tvoss_ | racarr, ? | 17:43 |
| racarr | tvoss_: Because things are written as in Steps 0-2 there, we don't | 17:44 |
| racarr | read a second message until we have finished processing the first one completely | 17:44 |
| racarr | which we use to keep messages in order | 17:44 |
| racarr | the problem is not all messages are in the same "channel" | 17:44 |
| kdub | racarr, can't we have a special case on the client side though... "if you are the client that turned off the screen, you'll get an error if you try to swapbuffers before you turn the screen on" | 17:44 |
| kdub | (or did we already consider that?) | 17:44 |
| racarr | and the particular problem is, say you use DPMS to turn off the screen, then call advance buffer | 17:44 |
| tvoss_ | racarr, which would be fine, too, if the message handling just handles stuff like dpms asynchronously | 17:45 |
| racarr | and you are | 17:45 |
| racarr | perpetually blocked on advance buffer | 17:45 |
| racarr | so you can never turn | 17:45 |
| racarr | the screen back on | 17:45 |
| racarr | kdub: It could always be racy I think (because other people can turn on/off the screen...but it's a possibility) | 17:45 |
| kdub | racarr, even the server could turn on the screen, but then it would just be an event sent to clients | 17:46 |
| tvoss_ | kdub, I would rather want to avoid such a hacky appraoch | 17:46 |
| racarr | kdub: The plan I was developing, was instead to read messages as fast as possible, then the SessionMediator uses a thread pool | 17:46 |
| racarr | to perform the actual operations and returns futures or whatever to the message processor | 17:46 |
| racarr | the SessionMediator can use, multiple locks | 17:46 |
| racarr | to enforce the different channels | 17:46 |
| racarr | i.e. there is a | 17:46 |
| racarr | SessionMediator::display_configuration_lock | 17:46 |
| racarr | and SessionMediator::surface_channel_lock | 17:46 |
| racarr | so, you can't execute resize_surface while swap is still executing | 17:47 |
| racarr | but you can reconfigure the display, or say receive a display reconfiguration event | 17:47 |
| racarr | you know messages within a "sequence" i.e. alll protected by the surface channel lock | 17:48 |
| racarr | will all be in order, because you don't read the next message | 17:48 |
| racarr | until you have actually received the std::future from the SessionMediator | 17:48 |
| racarr | at which point you know the lock from that channel is held | 17:48 |
| racarr | I am pretty sure it works, but am nervous about doing it because it changes the entire server side threading model basically | 17:49 |
| racarr | and who knows what that does | 17:49 |
| racarr | I mean I guess hypothetically I should | 17:49 |
| kdub | racarr, yeah, thats why i keep thinking | 17:49 |
| racarr | but I don't seem to be confident about that :p | 17:49 |
| kdub | 'there's got to be some smarts we could put into the client side' | 17:49 |
| racarr | I think it's always a race on the client. | 17:50 |
| racarr | also this may show up other places | 17:51 |
| racarr | i.e. two surface clients | 17:51 |
| racarr | if you have to wait until the server responds that you have swapped one buffer before you can begin swapping the next | 17:51 |
| kdub | its a big change, because client requests go from in-order to out of order | 17:51 |
| kdub | or rather two (or more channels) and we have to do the sync logic in the server at some point | 17:51 |
| racarr | kdub: No, that's the thing with still not reading the next message until the SessionMediator takes some lock for you | 17:52 |
| racarr | it's just there become seperate channels, i.e. display-configuration, and surface | 17:52 |
| kdub | racarr, well, thats the sync i was talking about :) taking the lock | 17:52 |
| racarr | but messages in the surface channel will still be processed in the order they are sent | 17:53 |
| racarr | ah yeah | 17:53 |
| racarr | yeah | 17:53 |
| racarr | and it's not super trivial with all the thread pools and such | 17:53 |
| kdub | with swapbuffers, we currently say 'this might block!' | 17:54 |
| kdub | we could just say like, 'after calling 'block server/turn screen off' the only thing you can do is some subset of the server functionality' | 17:55 |
| racarr | I think we understand that to mean though, that mir_client_swap_buffers_sync might not return immediately | 17:55 |
| racarr | not that you can't call any mir_client_ functions | 17:55 |
| racarr | Mm. I guess we could say that, espescially perhaps to XMir | 17:56 |
| racarr | but it seems really difficult if you are writing a multithreaded client | 17:56 |
| kdub | well, the renderthread just knows the swap could wait an arbitrarily long time | 17:56 |
| kdub | it doesn't have to know why | 17:57 |
| racarr | and I worry we will end up with bugs that literally mean the screen turns off and can't come back on :p | 17:57 |
| racarr | ? | 17:57 |
| racarr | if xmir accidentally swaps after turning off DPMS | 17:57 |
| racarr | the swap thread will wait infinitely | 17:57 |
| kdub | racarr, if it has two threads | 17:57 |
| kdub | a render thread, and display management thread, its not a problem | 17:57 |
| racarr | You mean, it's not a problem as long as the client | 17:58 |
| racarr | never calls swap_buffers after turning off the display? | 17:58 |
| racarr | I am just not sure it's a good idea to put that requirement on the client when the failure case is | 17:58 |
| racarr | restart the entire session | 17:58 |
| kdub | right, as long as the client remembers the well-known "swapbuffers can wait a really long time sometimes" | 17:59 |
| racarr | ? How does that help you? | 17:59 |
| racarr | It will wait forever | 17:59 |
| racarr | there's no way for the system to recover | 17:59 |
| racarr | even if the client uses | 17:59 |
| racarr | async swap buffers | 17:59 |
| racarr | and the client itself isn't blocking | 18:00 |
| racarr | it can still never turn the display back on. | 18:00 |
| kdub | ah, the 'server thread is blocked' problem | 18:00 |
| racarr | Yes :( | 18:00 |
| kdub | still coming back into the problem :) | 18:00 |
| racarr | haha no worries, it's confusing, I didn't realized this is what was happening on GBM | 18:01 |
| racarr | ...for a long time haha | 18:01 |
| kdub | well, if the client sends 'display off', then 'swapbuffers' | 18:02 |
| kdub | we know when we receive the swapbuffers command | 18:02 |
| kdub | that we cannot guarantee that we will ever be able to service the command | 18:02 |
| kdub | so perhaps an error? | 18:02 |
| racarr | kdub: I've been thinking about an error yeah | 18:04 |
| racarr | the thing is how does the client know when to call swap buffers again | 18:04 |
| racarr | the client then has to like | 18:04 |
| racarr | call swap buffers, if error, see if the error was because the display was off | 18:04 |
| kdub | when it turns the screen back on, or sees that the screen has been turned back on | 18:04 |
| racarr | if so, update some flag so we watch the display configuration for the display to come back on to start our render loop | 18:04 |
| racarr | the thing is there will be apps and stuff too who will try and swap buffers while the screen is off, not just the client who has to turn the screen back on | 18:05 |
| racarr | so it has to be a reasonable behavior for them too | 18:05 |
| kdub | well, those can block | 18:05 |
| kdub | normally | 18:05 |
| racarr | unless we throw an error :p | 18:05 |
| racarr | in which case they have to decide what to do with it, which can't just be call swap_buffers again because they need to be sleeping while | 18:06 |
| racarr | the screen is off | 18:06 |
| kdub | just the client that is turning the screen on and off is the problem one that we have to give an error to | 18:06 |
| kdub | so i think that approach would work, but there's also the reworking of the session mediator | 18:06 |
| racarr | hmm yeah maybe just errors to the one client... | 18:07 |
| kdub | because, although i sorta like it the way it is :) if we have a new scenario we might have to improve it to fit the new scenario | 18:07 |
| racarr | I think it could be improved in general some | 18:07 |
| kdub | like... on new message, make a std::async to service the request | 18:08 |
| racarr | I think you should be able to process messages from the same client | 18:08 |
| racarr | about different surfaces | 18:08 |
| racarr | concurrently | 18:08 |
| racarr | (as an example of a general improvement which has kind of similar requirements to this) | 18:08 |
| kdub | racarr, right | 18:09 |
| kdub | there's a few other ones i'm sure where that would be beneficial | 18:09 |
| kdub | racarr, i'm starting to lean more towards improving the server so that a new message is handled in a future | 18:12 |
| racarr | kdub: Yes I think it should work...I'm worried it might be too big to finish this week though | 18:14 |
| racarr | lots of test redoing, etc. | 18:14 |
| racarr | I just had an interesting idea for a "solution" | 18:14 |
| racarr | if you swap buffers while you turned off the display | 18:15 |
| racarr | you turn it back on XD | 18:15 |
| kdub | racarr, it is a fair amount of test reworking and restructuring | 18:15 |
| racarr | and then xmir tries to do the right thing | 18:15 |
| racarr | but if it ever fails its not catastrophic | 18:15 |
| racarr | i.e. the session mediator implicitly turns it on for you | 18:15 |
| kdub | racarr, not a bad solution :) | 18:15 |
| racarr | kdub: Mm. | 18:19 |
| racarr | Ok thanks for talking through it with me :D I'm going to work on other stuff for a few hours | 18:19 |
| racarr | and then revisit and choose an approach | 18:19 |
| racarr | maybe wait to sync with Alan in the morning, I bet he has an opinion :D | 18:20 |
| kdub | racarr, no problem... if you want, we could call a hangout on it for tomorrow morning | 18:21 |
| racarr | kdub: Mm good idea, ill make sure to be up early enough and we can just do it after the standup | 18:23 |
| mlankhorst | alf_: meh new strace then :P | 18:59 |
| mlankhorst | with the dup removed still | 18:59 |
| === seb128_ is now known as seb128 | ||
| kgunn | mornin robert_ancell | 21:03 |
| robert_ancell | kgunn, hello | 21:03 |
| kgunn | robert_ancell: curious, any joy on fixin the sec bug/vt input shotgun style | 21:14 |
| robert_ancell | kgunn, we had a disagreement with ricmm/tvoss over using the app lifecycle api, so we need to do some more convincing there | 21:15 |
| kgunn | robert_ancell: we're supposed to be default on the 19th....i fear we're running out of runway | 21:15 |
| robert_ancell | kgunn, very much so | 21:15 |
| robert_ancell | kgunn, I think we're just going to have to make the API change - it shouldn't affect the shell team | 21:16 |
| robert_ancell | didrocks, still around? | 21:19 |
| didrocks | robert_ancell: yeah, I'm in Boston right now in a sprint | 21:19 |
| robert_ancell | didrocks, oh, cool. All the autolanding is off for mir right? How do we push through releases now? | 21:20 |
| didrocks | robert_ancell: we just workarounded a dns issue that we are having for the last 3 days | 21:20 |
| didrocks | (an infra issue) | 21:20 |
| didrocks | when I say just, it's really *just* | 21:20 |
| robert_ancell | didrocks, oh, they weren't intentionally blocked? | 21:21 |
| didrocks | so at least, we'll have build for dailies | 21:21 |
| didrocks | 2 issues :) | 21:21 |
| didrocks | 1. intentionally block | 21:21 |
| didrocks | 2. dns issues making things even not building for the past 3 days | 21:21 |
| didrocks | count 2 as fixed | 21:21 |
| didrocks | for 1, we need to ensure the current image is fine | 21:21 |
| didrocks | and then doing the unity8+mir transition | 21:21 |
| didrocks | is what is in mir trunk for that goal? | 21:22 |
| didrocks | (the thing you do want to release?) | 21:22 |
| didrocks | sorry, but on holidays and then, just back on this sprint, so quite lost on all the things that happened :) | 21:22 |
| didrocks | robert_ancell: still around? | 21:25 |
| robert_ancell | didrocks, yep | 21:26 |
| didrocks | does my question make sense? | 21:26 |
| robert_ancell | didrocks, mir trunk should still be going into saucy, otherwise we wont get any critical fixes or features for the phone | 21:27 |
| robert_ancell | brb, need to restart modem | 21:29 |
| robert_ancell_ | blew our 100G cap, just upgraded to 200G. The 64k throttled speed is so unusable... | 21:32 |
| didrocks | robert_ancell_: ok, let's try to get mir, u-s-c, unity-mir and qtubuntu rebuilt for making the transition | 21:33 |
| robert_ancell_ | didrocks, the mirclient3 transition? | 21:33 |
| === robert_ancell_ is now known as robert_ancell | ||
| robotfuel | robert_ancell_: https://bugs.launchpad.net/bugs/1218381 is happening on saucy, with additional black vertical lines (there is a bug for the black lines) | 21:34 |
| ubot5 | Launchpad bug 1218381 in XMir "saucy has horizontal distortion on ati" [High,Incomplete] | 21:34 |
| robert_ancell | robotfuel, ta | 21:35 |
| didrocks | robert_ancell: urgh, transition? | 21:45 |
| didrocks | robert_ancell: no transition right now please | 21:45 |
| didrocks | asac tries to get unity-mir on | 21:46 |
| asac | :) | 21:47 |
| asac | yay!! | 21:47 |
| asac | we all try to get it in | 21:47 |
| asac | not me :) | 21:47 |
| RAOF | Transition all the things! | 23:25 |
| kgunn | ok | 23:29 |
| RAOF | robert_ancell: Incidentally, http://bazaar.launchpad.net/~raof/platform-api/update-for-lifecycle-cookie/revision/149 is the platform-api update for our proposed change. | 23:32 |
| robert_ancell | RAOF, yes, saw that | 23:33 |
| robert_ancell | RAOF, any luck convincing ricmm? | 23:33 |
| RAOF | Not really. | 23:33 |
| robert_ancell | RAOF, ricmm, I was also thinking, if the correct behaviour when switching sessions is that the hidden session should suspend its apps the only way this can occur is if the system compositor can notify the shell. So it makes sense in the Unity 8 case as well as the XMir case | 23:34 |
| robert_ancell | RAOF, we should code it up without the cookie for now. That's at least an improvement on the current case. It will have the input overlap issue potentially | 23:34 |
| RAOF | Yeah. I'll just push the branch so you can test. | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!