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