[01:29] Stupid bastard of an acceptance test! Last time I ran you, you worked! [01:38] Oh, oops. === duflu_ is now known as duflu [02:48] Hey, cool. My touchpad really does support two-finger multitouch. [07:53] * tvoss watches Linux Action Show [08:09] tvoss: Good idea, till I realized how long it was :) [08:09] duflu, last third :) [08:40] is there a way to batch surface changes together... i.e. move show hide.. [08:41] and have only one notification [09:14] anpok: Not yet. But I did design in the expectation that mir events could arrive in batches. Don't think that's implemented yet [09:27] hm I believe the shell would need an API to batch those changes together. [09:32] anpok: It's probably a good idea for throughput. But (a) We don't yet have evidence that event throughput is a problem; and (b) It's hard to decide how long to batch events. You could easily cause all sorts of lag bugs [09:32] In theory, any delay could be detrimental to client performance [09:35] duflu: ah, no.. thats not what I meant.. [09:35] anpok: You mean atomic? [09:36] in the split greeter switch between greeter and session and on boot [09:36] for these swtiches there is now "spinner" showing a loading screen [09:37] and it seems like if u-s-c does spinner->hide() .. check states of surfaces .. greeter or session->show() there seems to be a wrong frame in between.. [09:38] guys, do you know the "Qt queues events when rendering blocked" bug from last week? [09:38] there's a reply from one of the Qt folks that we might need to argue against (or agree and implement...) [09:38] https://bugreports.qt-project.org/browse/QTBUG-37677?focusedCommentId=237009&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-237009 [09:41] hum [09:43] Saviq, I can see the need for synchronizing to swap buffers, but I'm a bit hesitant to provide all apps with information about the screen's state [09:43] tvoss, well, it's not about the screen's state, but about the app surface's state [09:45] tvoss, so there's two things... on one hand we're SIGSTOP'ing the apps soon after anyway [09:45] tvoss, so even if they don't care about that, we're fine [09:45] (that == the opaque/expose) [09:46] so we would need to send an event when the buffer is not going to be consumed, because it is occuled, and if the screen is turned off [09:46] on the other, shell is affected already, but that we can control and make sure that it does honor those events [09:47] Saviq, just to cross-check: the whole app is effectively blocked if swap-buffers does not return, correct? [09:47] tvoss, yes [09:47] only the gui/qml thread and the renderer I though? [09:48] +t [09:48] anpok, yes [09:48] anpok, but everything in QML happens on the GUI thread effectively [09:48] anpok, which is by default linked to everything else in the process iiuc [09:48] or would that also affect other QThreads created, as they do dispatch events through QApplication? [09:48] anpok, everything else, too, unless explicitly decoupled [09:48] tvoss: no. if you have a thread created yourself, with no synchronisation, that's not going to magically become blocked [09:49] the gui thread is blocked because it's waiting on the render thread to signal completion, which is actually blocked [09:49] w00t, sure, fair point. I'm referring to elements being implicitly tied to the gui thread [09:50] Saviq, so the music player app issue should be fixed with the media-hub iiuc [09:51] tvoss, sure, but that's just one issue [09:51] tvoss, shell is also affected by that - no volume buttons, no alarms working [09:51] and there's probably more we don't know about [09:51] will qt clients that run animations inside their frame bisbehave with 5.2/5.1 if we dont support them with these events? [09:51] Saviq, yup, but I think that it would be easier for us to solve in the shell than for *all* apps [09:51] i.e. qt games.. [09:52] anpok, they won't be running anyway [09:52] anpok, yeah, when screen off they're SIGSTOP'ed, so doesn't *really* matter [09:52] anpok, in this particular scenario, they are sigstop'd pretty soon [09:52] Saviq, so the only real issue is the shell, correct? [09:53] tvoss, well, no, the issue is that we're disagreeing with Qt on what we do [09:54] tvoss, we need to either convince them to not sync (which must not have been happening in 5.0) [09:54] Saviq, at least making it configurable would be handy [09:54] or we need to implement the supported behaviour and not block the rendering thread [09:56] Saviq, yeah, my point was that generating the exposure/obscure event for/in the shell is certainly doable [09:56] but the QtQuick renderer thread has to receive that occlusion event before he goes into the blocking eglSwapBuffers call.. [09:56] tvoss, not sure why we'd special case it, though... [09:56] anpok, there can't be no blocking eglSwapBuffers call, that's the thing [09:56] and that sounds like an easry race condition to run into [09:57] ok - a failing eglSwapBuffers then? [09:57] or an ignored one... [09:58] Remember anything that's not a client or a nested server is "bling". To sync that perfectly to compositing you have to render it in the compositor (i.e. don't use Surfaces) [09:58] See the demo-shell decorations :) [09:59] I'm not sure on what would be the right / correct thing to do here, but obviously what they're saying is that a blocking eglSwapBuffers call is not supported [09:59] at least while the surface is allowed to render, I'd say [09:59] but yeah ↑ that'd be racy [10:01] SwapBuffers is designed to (and must) work asynchronously behind the scenes. If you make it synchronous like a glFinish() then performance is unacceptable [10:06] Saviq, hmmm, agreed, it's difficult to say, but using exposure events to encode possible reasons why a call to swap buffers might block/return an error [10:06] does not seem to be right to me [10:06] tvoss, yeah, it seems they're working under the assumption that swap buffers will always work [10:07] tvoss, Saviq: eglSwapBuffers always blocks once you've filled the queue. That's how to throttle clients to the refresh rate :) [10:07] duflu, yeah, sure, but that's a "special case" [10:07] ... which happens "all the time" [10:07] duflu, in our case we're telling the app effectively that the queue is filled when screen is off [10:08] Saviq, which actually is quite sensible :) [10:08] * duflu goes away to try and finish his work for the evening [10:08] tvoss, not necessarily [10:08] tvoss, not if the assumption from Qt is that the app stops when that happens [10:09] unless we first "tell it" that there's not going to be more swaps possible (with expose/occlude) [10:09] but that's dangerous [10:09] Saviq, it is, and kind of goes against the defined of eglSwapBuffers [10:09] +behavior [10:09] indeed [10:10] Saviq, so Qt always assumes the "good" path when calling eglSwapBuffers unless otherwise told [10:10] Saviq, races and timings aside, this sounds fragile. [10:11] tvoss, well, not if what it does is just wait for stuff to settle again, and process everything when swapping is possible again [10:11] tvoss, especially when you consider the swapping to only not return when buffer is filled, and indeed you don't want to do unnecessary work until you can swap again [10:11] Saviq, what do you mean with "wait for stuff to settle again"? [10:12] Saviq, the definition of "unneccessary" becomes quite broad though, if you block the overall event processing on the rendering [10:12] tvoss, well, if you're a GUI app, and are expecting to be able to draw [10:13] tvoss, your GUI thread blocking on you not being able to draw... [10:13] makes sense to me [10:13] if you're told that you won't be able to draw (expose/occlude), that's another matter [10:14] Saviq, hmmm, I think both approaches are valid, i.e., block and not block, where block could be a safe default [10:28] tvoss, sure, we need to come up with a solution, though ;) [10:29] tvoss, as this is the last known 5.2 issue that we need to fix [10:33] tvoss, or well, we at least need guidance on whether we want to argue with Qt folk or not [10:39] Saviq, how about proposing making the blocking optional to the qt folks [10:40] tvoss, TBH I'm not convinced, so I wouldn't like to argue that point :) [10:41] Saviq, and I'm likewise not convinced that switching off the screen equates to an obscure event [10:41] tvoss, well, in our case it does, as we're unfocusing the app / putting the lock screen on [10:42] tvoss, btw, definition of the expose event http://qt-project.org/doc/qt-5/qwindow.html#exposeEvent [10:43] tvoss, I'd say that that makes sense, as exposed is a broader event than obscured [10:43] Saviq, okay, and we would be required to send a resize event? [10:43] tvoss, not sure, why? [10:43] Saviq, doc says so [10:43] tvoss, first time [10:43] Saviq, hmmm ... [10:43] tvoss, I'd say we're actually sending exposeEvent already [10:43] tvoss, otherwise we'd never draw [10:44] or qt wouldn't [10:44] or maybe we don't, nothing in qtubuntu apparently [10:45] Saviq, it's still racy to send the expose event [10:45] tvoss, not if we don't block swap buffers subsequently [10:46] tvoss, so that's the real, architectural, question - should we be ever blocking swap buffers [10:46] Qt seems to think we should not [10:47] not if we want the GUI thread to run [10:47] which we want, at least for the shell [10:47] Saviq, we should, and we have to ... it's absolutely normal behavior to throttle clients with that [10:48] tvoss, _throttle_ [10:48] tvoss, we don't need to throttle if we don't want them to render at all [10:49] and we're SIGSTOP'ing them anyway [10:49] tvoss, don't get me wrong, I'm the devil's advocate here [10:49] tvoss, and that's why I don't want to argue with Qt folk, 'cause it's not me that made (makes) that decision [10:49] Saviq, sure, that's fine. I still think that an assumption on eglSwapBuffers not blocking is fragile [10:50] tvoss, and that's what you need to argue with them on :) [10:51] Saviq, I guess you are putting the focus on *you* here ;) [10:52] tvoss, I just don't know enough about this [10:52] tvoss, and it's kind of an architectural question [10:52] Saviq, sure, no problem. Just created an account in Jira [10:52] and then... you're the architect! :D [10:52] Saviq, yup. According to http://www.khronos.org/registry/egl/sdk/docs/man/xhtml/eglSwapBuffers.html [10:53] Saviq, a way of returning early would be to return false and raise EGL_CONTEXT_LOST [10:53] Saviq, which is really expensive [10:54] tvoss, sounds so, yeah [11:22] Saviq, replied [11:24] tvoss, thanks [12:02] tvoss, btw, I think I found the commit https://qt.gitorious.org/qt/qtdeclarative/commit/a7f61f7 [12:03] * Saviq tries to see if reverting that helps for the time being [12:24] tvoss, FYI: Gunnar replied [12:31] Saviq, thanks [12:51] Saviq, is qt-project the qt channel I should go to? [12:51] tvoss, #qt-labs [12:51] Saviq, thanks [12:51] tvoss, or #qt-quick [12:52] tvoss, maybe the latter, as this seems to be a qml-specific thing === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g === greyback is now known as greyback|lunch [14:25] tvoss, FYI it's actually https://qt.gitorious.org/qt/qtdeclarative/commit/ebe8b9408cfcd953fae80514aa67e49221541bed that introduces the syncing, I doubt we can revert that with any certainty that it's gonna work [14:25] it does _almost_ apply -R, but I'd really rather not... === dandrader is now known as dandrader|afk === pete-woods is now known as pete-woods-lunch === dandrader|afk is now known as dandrader === greyback|lunch is now known as greyback [15:19] Saviq, that's indeed looking too complicated to just revert it === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g === pete-woods-lunch is now known as pete-woods [15:59] racarr, poke! I figure you might be starting your day soon. I was curious if that PPA helped with testing the "screen turns back on" bug. I tested myself with your runServerWithGreeterClient branches to see if they helped, but they didn't. Not sure why this problem cropped up again (I thought it was already solved) [16:08] tvoss: Saviq ...so what's preventing us from using the expose event? seems like that is the given answer ? [16:08] kgunn, we certainly can, but it's still racy [16:08] tvoss: agreed...i think its a _terrible_ idea [16:08] in general [16:09] but just living with the "make it happy" moment [16:09] :) [16:09] kgunn, specifically when dealing with applications, we would need to wait for the apps to acknowledge the event before we can stall the pipeline [16:09] yeah...long halting sequence [16:09] alf__: hey, Mir fails to start on me frequently with this error: std::exception::what: Error opening DRM device [16:09] -22, "Unknown error -22" [16:10] kgunn, I think we can leverage the expose event in the shell easier, though [16:10] alf__: it's a nouveau machine, if that's any help/hindrance [16:10] kgunn, and for apps: the music hub will solve the immediate issue of missing EOS [16:10] greyback: hmm, I think we have a bug for this, let me see [16:11] tvoss: and iiuc, at the base qwindowsysinterface class gives you some guarantees you handling...so no misbehaved apps [16:11] kgunn, got difficulties parsing that sentence [16:11] :) [16:12] tvoss: just meaning @dealing with applications/waiting for ack's [16:12] tvoss: i'm understanding from his response that there's a guarantee for handlling [16:12] kgunn, mir would have to deal with that [16:13] kgunn, you have to synchronize that across process boundaries [16:13] tvoss: right...but from the app side too [16:13] kgunn, well, on the app side it's simple [16:13] kgunn, what is really challenging is getting that straight over process boundaries [16:13] suddenly, we would need timeouts and stuff [16:14] tvoss: sure...and it doesn't solve the potential race you highlighted to them [16:19] greyback: Hmm, I can't find a bug for this exactly (error opening DRM device + error 22 (EINVAL)), but I do remember people were discussing some issues with nouveau [16:19] alf__: ok, I'll log a bug anyway [16:19] greyback: "fails to start frequently", which I guess means sometimes works? [16:19] alf__: yeah, seems to [16:20] alf__: so I do a fresh boot, "sudo stop lightdm" and try mir_demo_server_shell [16:21] alf__: I'm not missing anything obvious, am I? [16:22] greyback: ok, btw you don't need to stop lightdm, you can start mir in e.g. VT1 (although if you get a strange crash you may not be able to vt away in some cases), so keep an ssh connection ready [16:22] greyback: what happens if you don't stop lightdm, does it help? [16:23] greyback: ok, do you run sudo mir_demo_server_shell? [16:23] greyback: s/ok/oh/ [16:23] alf__: just rebooting to try without stopping lightdm, gimme a min. Yep always sudo [16:24] greyback: ok, thanks [16:27] alf__: "address already in use" - aha USC is running as mir server.... [16:28] * greyback digs into help file to find right switch to use nesting [16:31] greyback: hmm, so you are running USC... I guess in that case you should stop lightdm, but I wonder if doing so properly stops USC. [16:36] alf__: if I stop lightdm, USC still running. Killing bad [16:37] greyback: killing bad, for it or for your session? :) [16:37] alf__ if I kill, I get the DRM error [16:37] and general life rule [16:38] greyback: if you leave it running can you run the demo server normally? [16:40] alf__: nested mode should work with this, right: sudo mir_demo_server_shell --host-socket /tmp/mir_socket -f /tmp/another_mir_socket [16:42] greyback: right, although note that nested servers live inside the context of the host server, so only visible in the host server's VT [16:43] alf__: I didn't know that [16:43] makes sense tho [16:43] greyback: they work by using a surface the same way a normal application does [16:44] greyback: but that (host) mir surface is the framebuffer for all apps connecting to the nested server [16:44] alf__: gotcha [16:45] greyback: but in any case, stopping USC and starting a demo server should work. In which VT are you trying to start the demo server? [16:47] alf__: it is working as nested anyway [16:47] alf__: so seems killing lightdm screws up the DRM state [16:48] I want to find a clean way to stop USC === dandrader is now known as dandrader|lunch [16:57] mterry where are you... [16:58] greyback: i think mterry has the worst wifi ever [16:59] will resort to mail [17:09] alf__: I suspect that USC is hanging on shutdown, and so not cleaning up the DRM state. Have asked mterry about it, will see what he says [17:11] greyback: ok, ensure it's getting stopped normally (not -9) [17:12] alf__: right, it's not. I gets a SIGTERM, but just sits there. So teardown isn't happening for some reason === alan_g is now known as alan_g|afk === dandrader_ is now known as dandrader === alan_g|afk is now known as alan_g === dandrader is now known as dandrader|bbl === dandrader|bbl is now known as dandrader