| RAOF | mlankhorst: Oh, I think I know why Mir clients are failing on new mesa; I ran into it before. | 00:00 |
|---|---|---|
| === zoktar_ is now known as zoktar | ||
| === cjohnston_ is now known as cjohnston | ||
| === xnox_ is now known as xnox | ||
| === duflu__ is now known as duflu | ||
| mlankhorst | RAOF: go on | 08:15 |
| mlankhorst | is this thep oint where the killer makes another move and you die before you can tell what the important information is? ;-) | 08:16 |
| alan_g | alf: I'm looking at some of the valgrind errors we see in my SwitchingBundle proposal and have found some very misleading reporting. What do you make of this: http://pastebin.ubuntu.com/6924718/ | 10:05 |
| anpok | lacking support for c++11 | 10:11 |
| alan_g | Rats. valgrind can't detect std::atomic wrappers on types that don't need a lock. (Because the wrapper gets optimised away.) | 10:17 |
| alan_g | That's a load of noise. | 10:17 |
| alf | alan_g: :/ | 10:30 |
| anpok | there is also no _GLIBCXX_SYNCHRONISATION_WHATEVER .. in atomic | 10:31 |
| alan_g | Yeah. tvoss suggested threadsanitizer - which isn't quite as wrong with the example | 10:31 |
| * alan_g wanders off to talk to folks that know this stuff in detail | 10:33 | |
| alf | alan_g: anpok: I wonder if helgrind can understand hardware instructions with acquire/release semantics (e.g. probably used by atomic<> implementations)... probably not | 10:41 |
| alan_g | alf: no. It is discussed on the valgrind lists - the opcodes are identical (for basic types anyway) | 10:42 |
| mlankhorst | RAOF: yeah the refresh fixed things.. I'm curious though since it seems to remove a bunch of free-s. Why were those removed? | 11:21 |
| mlankhorst | -+ free(dri2_surf->dri_buffers[__DRI_BUFFER_FRONT_LEFT]); | 11:21 |
| mlankhorst | -+ free(dri2_surf->dri_buffers[__DRI_BUFFER_BACK_LEFT]); | 11:21 |
| greyback | folks, I've a little C++ issue I need advice on: http://pastebin.ubuntu.com/6925097/ | 11:51 |
| greyback | I think I'm not fully understanding a reference to a pointer of an object and how to properly create one | 11:52 |
| alan_g | greyback: C++ won't let you bind a non-const reference to a temporary | 11:55 |
| alan_g | s/QScopedPointer<MockBuffer> buffer(new MockBuffer);/mir::graphics::Buffer* buffer{nullptr};/ | 11:58 |
| greyback | alan_g: interesting. Do I not need that MockBffer at all? | 11:58 |
| alan_g | greyback: I doubt it: swap_buffers() is used to get a pointer to a buffer provided by the compositor and optionally return one | 12:00 |
| alan_g | BTW swap_buffers got some drastic changes last week and that code is using the old version | 12:02 |
| greyback | alan_g: ah really? Ok, well this is more an experiment than anything else. | 12:02 |
| greyback | alan_g: thanks for the help, you've pointed me in the right direction | 12:03 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| alf | fginther: Hi! Do we need to do something to deploy the change for the pbuildjenkins scripts? | 13:54 |
| alf | rsalveti: ogra_: How do you want to handle the package dependency of e.g. libmirclient to its platforms? libmirclient Depends: libmirclientplatform-mesa | libmirclientplatform-android ? | 13:59 |
| ogra_ | alf, right, and then se seed libmirclientplatform-android in touch and libmirclientplatform-mesa everywhere else | 14:00 |
| fginther | alf, It's all deployed now, you should be good to go | 14:12 |
| alf | fginther: excellent, thanks | 14:13 |
| alf | ogra_: rsalveti: Also, do you want mesa and android to have the same priority (in terms of dpkg alternatives), or different priorites, possibly depending on platform? | 14:24 |
| ogra_ | alf, i assume they will never be installed together anyway | 14:25 |
| ogra_ | so they can have the same | 14:25 |
| alf | ogra_: if a package with the same priority as an already existing one gets installed, does the alternative change to the new one or stick to the current one? | 14:26 |
| ogra_ | i thinkit gets changed | 14:27 |
| alf | ogra_: hmm, let's see if I can find out for sure (to the sources!). The problem I am trying to avoid is someone using mir on the desktop, playing with packages, and installing the -android backend => broken system | 14:28 |
| ogra_ | use Conflicts/Breaks in the control file | 14:29 |
| ogra_ | then he needs to approve the removal ... (apt will ask Y/N ) | 14:29 |
| ogra_ | thats at least one stop gap | 14:29 |
| alf | ogra_: Then what is the point of having alternatives in the first place? We could just Conflict/Break from the start... I thought the (future) goal was to be able to install in parallel and have runtime selection? | 14:31 |
| ogra_ | but that would happen inside one package anyway, or not ? | 14:31 |
| rsalveti | alf: ogra_: I'd put the android with a lower priority | 14:37 |
| rsalveti | as our touch image is ro anyway | 14:37 |
| ogra_ | indeed | 14:37 |
| rsalveti | then we're still good for the desktop | 14:38 |
| ogra_ | though my statement still stands, for the runtime selection we want both in one package | 14:38 |
| alf | rsalveti: ogra_: would it make sense to have mesa < android on armhf, mesa > android otherwise? | 14:40 |
| alf | rsalveti: ogra_: from the update-alternatives manpage: "If the group is in automatic mode, and the newly added alternatives' priority is higher than any other installed alterna‐ tives for this group, the symlinks will be updated to point to the newly added alternatives | 14:45 |
| ogra_ | alf, right, well, do it like you described above | 14:46 |
| rsalveti | alf: we don't want to assume anything for armhf | 14:46 |
| rsalveti | as we now have the x86 emulator as well | 14:46 |
| alf | rsalveti: ogra_: ok, I will make them equal, hopefully what the manpage says is accurate, so just installing the package won't mess up a system with an existing equal alternative | 14:47 |
| rsalveti | right :-) | 14:48 |
| * alf didn't know what he was missing by not using ccache when developing/rebuilding packages | 14:55 | |
| kgunn | mterry: didn't mean to abandon you.... | 14:56 |
| kgunn | mterry: so what you wanted to know was where in the mir code does a client know his buffer is about to be "used" for composition consumption | 14:57 |
| kgunn | that right ? | 14:57 |
| mterry | kgunn, yeah... I want to know when a buffer with non-zero content is about to be used. (i.e. not just transparent; I don't know if Mir optimizes such frames out anyway) | 15:00 |
| mterry | kgunn, oh and this is from compositor side | 15:00 |
| mterry | kgunn, I tried inspecting buffers but didn't know how to get actual pixel data | 15:01 |
| kgunn | alf: or anpok ^ can you help out mterry... | 15:02 |
| mterry | anpok and alan_g, you two were helping me yesterday with buffer stuff. I have instrumented USC to insert itself into the surface/session creation process. Now I have these buffers that the surface wants to swap | 15:03 |
| mterry | But how do I inspect actual pixel data? (I want to see if there's actual pixels to draw, it's not just all transparent -- does Mir optimize that away?) | 15:03 |
| anpok | mir would not optimize that away | 15:04 |
| anpok | also if you look at current system behavior you regularly see white or black buffers show up.. so we seem to display things before actual content shows up - I dont know exactly where that happens though | 15:05 |
| mterry | anpok, hm. But I have a mg::Buffer object. I can't seem to do anything sensible with the native_buffer_handle, but how might I get the pixel data? | 15:06 |
| alan_g | mterry: I don't think that's an intended use. Maybe alf can suggest a way? | 15:08 |
| greyback | mterry: do you want to inspect the actual pixel data, or just be notified that a client has drawn its first frame? | 15:10 |
| mterry | greyback, well you showed me you had something in the works for frame notification | 15:11 |
| mterry | greyback, I suspect Qt is sending a dummy background before the Qml is fully loaded and drawn | 15:11 |
| mterry | greyback, so I wanted to be able to inspect data to see if that is true and to detect the first non-empty frame | 15:11 |
| greyback | mterry: when mir creates a Surface, it may be some time until the buffer is actually drawn to by the client. So I wanted to be notified after the client has drawn to the buffer, as then it is non-empty | 15:16 |
| greyback | so I wasn't going to actually inspect the pixel data. I just wanted to know that the client swapped a buffer, which means it drew to it | 15:17 |
| greyback | mterry: are you using the SurfaceManager in unity-mir by any chance? | 15:18 |
| mterry | greyback, no, I'm currently looking to do this in USC | 15:18 |
| greyback | mterry: ok | 15:18 |
| mterry | greyback, so who does have access to the pixel data? Seems hard to find in mir source :) | 15:18 |
| greyback | mterry: so what I think Mir needs to export is some kind of event which says "Session has a Buffer ready" to be composited/drawn on screen (i.e. one which the client has actually drawn to) | 15:19 |
| mterry | That would help, yeah | 15:20 |
| alan_g | mterry: the pixel data is platform dependent typically in a GL texture | 15:21 |
| mterry | alan_g, hmmm OK | 15:23 |
| alan_g | As far as Mir is concerned if a client has sent a buffer via swap_buffers() there is data. So I'm not sure what else this event you're discussing would be. | 15:25 |
| === alan_g is now known as alan_g|tea | ||
| mterry | alan_g|tea, what about the idea of a client Mir session being able to indicate to the server that it is "ready" to be composited? It seems not unreasonable that a compositor would want to keep some animation going or draw something to the screen while a client loads up | 15:46 |
| === alan_g|tea is now known as alan_g | ||
| alan_g | mterry: why doesn't it do that by posting a buffer? | 15:48 |
| mterry | alan_g, yeah but when does it stop the buffer? | 15:49 |
| alan_g | I don't understand | 15:50 |
| mterry | alan_g, so here's the problem I'm working with | 15:51 |
| mterry | alan_g, USC starts, and lightdm kicks off a greeter session and a user session around the same time. There's a race there, but USC knows to keep the greeter on top when it does show up | 15:51 |
| mterry | alan_g, but user session sometimes wins the race and appears for a second before the greeter | 15:52 |
| alan_g | ack that's what we discussed yesterday | 15:52 |
| mterry | alan_g, I'd like to be able to hide the user session when it appears (easy with Session::hide()) | 15:52 |
| alan_g | sure | 15:52 |
| mterry | alan_g, but I need to know when to unhide it (i.e. when the greeter is "done") | 15:52 |
| mterry | alan_g, and the greeter is posting frames before it is ready (presumably empty transparent frames) | 15:52 |
| mterry | Qt is doing that I think for me | 15:53 |
| mterry | alan_g, the situation would be very similar once USC gets boot animation support. We need to know when to transition from the animation to the greeter when it is ready to be shown | 15:54 |
| alan_g | So the answer to "why doesn't it do that by posting a buffer?" is that Qt posts buffers before it is ready? | 15:54 |
| mterry | alan_g, well. I mean, I could imagine a client like the unity8 shell not wanting to be "ready" before its scopes are loaded or whatever | 15:54 |
| mterry | alan_g, "readyness" doesn't necessarily translate into frames being posted | 15:55 |
| mterry | alan_g, but in this case, for the greeter, sure. It's because Qt is posting before there is actual content to load | 15:55 |
| === dandrader is now known as dandrader|afk | ||
| mterry | alan_g, I think the Qt window is drawn and its waiting for the Qml stuff to load and draw etc | 15:55 |
| mterry | at a guess, I haven't dived into it | 15:55 |
| === jono is now known as Guest53088 | ||
| alan_g | I don't like the sound of inspecting buffers to guess when they have "real" content. Too much can go wrong | 15:57 |
| mterry | alan_g, I get that. What about some Mir signal that a client could post to its server? | 15:57 |
| alan_g | It sounds like a weird client that posts buffers before it is ready. | 15:58 |
| alan_g | Is this really a general problem or something restricted to greeter <-> USC? | 15:59 |
| mterry | alan_g, I get that from a theoretical perspective. But there are a lot of layers between a Qml file that knows "Component.onCompleted: isReady()" and Mir | 15:59 |
| mterry | alan_g, those abstractions tend to mean that Qt/Qml throws data at Mir willy nilly | 16:00 |
| mterry | alan_g, well, when an app launches... We throw up a white screen right? What if the shell wanted to show an animation while it loaded | 16:01 |
| mterry | alan_g, it would need to know when to stop the animation. When the app is "ready" | 16:01 |
| anpok | for those cases the first frame is good sign of readyness | 16:02 |
| alan_g | mterry: I've got a hangout - back in ~10min | 16:02 |
| mterry | anpok, that's fair. I suppose click apps are tiny enough | 16:02 |
| anpok | i wonder whether other configuration changes will come up later | 16:03 |
| anpok | configuration changes the shell might request from a client.. | 16:03 |
| mterry | anpok, alan_g: I'd be happy if Qt/Qml wouldn't post any frames until everything was loaded. Is that a feasible change to make? Ideally we could start "frozen" and unfreeze... maybe Qt has internal support for doing that | 16:04 |
| anpok | seems like worthwhile to look into qt for that | 16:05 |
| * mterry isn't super familiar with Mir and Qt integration, but digs into it | 16:05 | |
| mterry | Maybe it's as easy as not doing show() until we're ready | 16:12 |
| alan_g | mterry: I don't know much Qt but that sounds like a logical approach | 16:21 |
| greyback | mterry: I'm not aware of any easy way to prevent Qt drawing until things are "ready" | 16:58 |
| mterry | greyback, yeah I haven't been able to stop it yet. Looks like QMirServerApplication even does it somewhere deep down? | 16:59 |
| greyback | mterry: nope, it doesn't touch render loop. Render loop will spin once the QML scene is ready. But it won't render if the "window" is marked hidden. So maybe http://qt-project.org/doc/qt-5.0/qtgui/qwindow.html#hide might do it | 17:01 |
| mterry | greyback, I tried removing all the QQuickView code from unity8, but it still is seemingly posting non-null buffers to swap_buffers | 17:01 |
| greyback | mterry: thing is, Mir is doing the compositing. Is user session appears first, Mir shows it first. It just means Qt hasn't drawn its surface faster than the user session has | 17:02 |
| mterry | greyback, maybe I don't understand how swap_buffers works, but it seems to be receiving valid buffers from the qml-less shell | 17:02 |
| mterry | greyback, yeah that makes sense to me. I can have the compositor hide the user session until the greeter is ready | 17:03 |
| greyback | mterry: as soon as a client asks Mir for a surface to render on, Mir will be aware of that surface and start compositing it - even though nothing has been drawn to that surface yet. So you see black | 17:03 |
| mterry | greyback, I just need a way to know when the greeter is ready so I can unhide it | 17:03 |
| mterry | greyback, or in the greeter's alpha case, transparency | 17:03 |
| greyback | mterry: I don't know how to get Mir to create a Surface invisible by default. But maybe position it off-screen initially, or mark it fully transparent? | 17:04 |
| mterry | greyback, well I've been using swap_buffers. Did your approach you mentioned the other day to detect frames use a different mechanism? | 17:04 |
| greyback | mterry: well that's step 2, no? That once the user session buffer has been drawn to you can then show it? | 17:04 |
| mterry | greyback, there is a way to get it to allow transparency: https://code.launchpad.net/~mterry/unity-mir/alpha-greeter/+merge/204069 | 17:04 |
| greyback | mterry: indeed. I need to review that... | 17:05 |
| mterry | greyback, I actually don't care so much about when the user session is ready. I just want to know when the greeter is ready so I can show the user session (ready or not) behind it | 17:06 |
| mterry | Eventually I'll probably be interested in that information too, to add a little "waiting for session" animation | 17:06 |
| greyback | mterry: oh ok, I misread.In Qt, you can connect to this signal https://qt-project.org/doc/qt-5.1/qtquick/qquickwindow.html#frameSwapped | 17:07 |
| greyback | mterry: else you need to get that info out of Mir somehow | 17:07 |
| mterry | greyback, I'm saying that even without the shell creating any windows, Mir compositor is seeing swap_buffer calls with non-null buffers. So I'm having a hard time determining when a frame is posted if that's not the right way. You said you had something similar. Does it rely on swap_buffers or something else in Mir? | 17:08 |
| greyback | mterry: yep, I added something to ms::BasicSurface::swap_buffers so that I was notified when an actual buffer was swapped | 17:11 |
| mterry | greyback, yeah I noticed you added a flag_for_render thing? | 17:12 |
| mterry | Haven't dived into your branch yet, but looks like that's my next step | 17:12 |
| mterry | But first, lunch | 17:12 |
| greyback | mterry: yes that's it. That event was emitted when an actual client puffer was swapped | 17:12 |
| greyback | worked nicely for my purposes | 17:12 |
| mterry | greyback, that's something you added, right? I don't see it in trunk | 17:13 |
| greyback | mterry: yep | 17:14 |
| === FunnyLookinHat_ is now known as FunnyLookinHat | ||
| === alan_g is now known as alan_g|EOD | ||
| mterry | greyback, oh, I see why flag_for_render isn't in trunk, it got removed... | 18:28 |
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| mterry | So I'm seeing swapped buffers from just mir::run_mir's use of DisplayServer... | 19:57 |
| * mterry is wondering what could be posting buffers internally | 19:58 | |
| * anpok mumbles something unintelligible | 20:09 | |
| anpok | mterry: when the display is on the compositor threads will start drawing the first frame | 20:20 |
| anpok | if you look in mir::compoistor::MultiThreadedCompositor::start I believe | 20:21 |
| anpok | schedules a composition for each active output | 20:21 |
| anpok | so with no surfaces you should get an initial glClear ... and swap buffers for | 20:22 |
| mterry | anpok, huh without data from the client? | 20:22 |
| anpok | I think this mainly about getting the display in the right state after turning it on again (or maybe the cause why we see old buffer contents - because we get the trigger before clients can send proper surface contents) | 20:24 |
| anpok | havent played with that code yet.. so.. add a grain of guessing from my side | 20:24 |
| mterry | anpok, huh. OK, I'll need to find a way to tell these apart from client-driven swap_buffer calls. Maybe only start listening for them after client is set up | 20:24 |
| anpok | mterry: I wonder if that is proper behavior | 20:25 |
| anpok | make waiting for the first round of new client buffers is better.. or just informing the shell and letting it decide what to do .. | 20:26 |
| anpok | you could try without scheduling the first draw - just to be sure | 20:26 |
| anpok | btw do you happen to know where the "Accept" decision is handled after an incoming call in unity8 | 20:27 |
| anpok | s/make waiting/maybe waiting/ o_O | 20:27 |
| mterry | anpok, the accept notification is from telephony-service | 20:40 |
| anpok | mterry: so they then launch the dialer app to take the call | 21:06 |
| anpok | they==that service | 21:06 |
| anpok | or searches for a running dialer app | 21:07 |
| mterry | anpok, yeah | 21:07 |
| mterry | anpok, launches it via upstart yeah, which either opens or focuses it | 21:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!