| RAOF | Stupid bastard of an acceptance test! Last time I ran you, you worked! | 01:29 |
|---|---|---|
| RAOF | Oh, oops. | 01:38 |
| === duflu_ is now known as duflu | ||
| RAOF | Hey, cool. My touchpad really does support two-finger multitouch. | 02:48 |
| * tvoss watches Linux Action Show | 07:53 | |
| duflu | tvoss: Good idea, till I realized how long it was :) | 08:09 |
| tvoss | duflu, last third :) | 08:09 |
| anpok | is there a way to batch surface changes together... i.e. move show hide.. | 08:40 |
| anpok | and have only one notification | 08:41 |
| 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:14 |
| anpok | hm I believe the shell would need an API to batch those changes together. | 09:27 |
| 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:32 |
| anpok | duflu: ah, no.. thats not what I meant.. | 09:35 |
| duflu | anpok: You mean atomic? | 09:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| anpok | hum | 09:41 |
| 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:43 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| tvoss | Saviq, so the music player app issue should be fixed with the media-hub iiuc | 09:50 |
| 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:51 |
| 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:52 |
| Saviq | tvoss, well, no, the issue is that we're disagreeing with Qt on what we do | 09:53 |
| 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:54 |
| 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:56 |
| anpok | ok - a failing eglSwapBuffers then? | 09:57 |
| Saviq | or an ignored one... | 09:57 |
| 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:58 |
| 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 | 09:59 |
| 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:01 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| tvoss | Saviq, hmmm, I think both approaches are valid, i.e., block and not block, where block could be a safe default | 10:14 |
| Saviq | tvoss, sure, we need to come up with a solution, though ;) | 10:28 |
| Saviq | tvoss, as this is the last known 5.2 issue that we need to fix | 10:29 |
| Saviq | tvoss, or well, we at least need guidance on whether we want to argue with Qt folk or not | 10:33 |
| tvoss | Saviq, how about proposing making the blocking optional to the qt folks | 10:39 |
| Saviq | tvoss, TBH I'm not convinced, so I wouldn't like to argue that point :) | 10:40 |
| 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:41 |
| Saviq | tvoss, btw, definition of the expose event http://qt-project.org/doc/qt-5/qwindow.html#exposeEvent | 10:42 |
| 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:43 |
| Saviq | or qt wouldn't | 10:44 |
| Saviq | or maybe we don't, nothing in qtubuntu apparently | 10:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| Saviq | tvoss, _throttle_ | 10:48 |
| Saviq | tvoss, we don't need to throttle if we don't want them to render at all | 10:48 |
| 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:49 |
| Saviq | tvoss, and that's what you need to argue with them on :) | 10:50 |
| tvoss | Saviq, I guess you are putting the focus on *you* here ;) | 10:51 |
| 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:52 |
| 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:53 |
| Saviq | tvoss, sounds so, yeah | 10:54 |
| tvoss | Saviq, replied | 11:22 |
| Saviq | tvoss, thanks | 11:24 |
| Saviq | tvoss, btw, I think I found the commit https://qt.gitorious.org/qt/qtdeclarative/commit/a7f61f7 | 12:02 |
| * Saviq tries to see if reverting that helps for the time being | 12:03 | |
| Saviq | tvoss, FYI: Gunnar replied | 12:24 |
| tvoss | Saviq, thanks | 12:31 |
| 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:51 |
| Saviq | tvoss, maybe the latter, as this seems to be a qml-specific thing | 12:52 |
| === 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 | ||
| 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... | 14:25 |
| === 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 | ||
| tvoss | Saviq, that's indeed looking too complicated to just revert it | 15:19 |
| === 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 | ||
| 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) | 15:59 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| kgunn | tvoss: sure...and it doesn't solve the potential race you highlighted to them | 16:14 |
| 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:19 |
| greyback | alf__: so I do a fresh boot, "sudo stop lightdm" and try mir_demo_server_shell | 16:20 |
| greyback | alf__: I'm not missing anything obvious, am I? | 16:21 |
| 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:22 |
| 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:23 |
| alf__ | greyback: ok, thanks | 16:24 |
| greyback | alf__: "address already in use" - aha USC is running as mir server.... | 16:27 |
| * greyback digs into help file to find right switch to use nesting | 16:28 | |
| 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:31 |
| greyback | alf__: if I stop lightdm, USC still running. Killing bad | 16:36 |
| 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:37 |
| alf__ | greyback: if you leave it running can you run the demo server normally? | 16:38 |
| 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:40 |
| 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:42 |
| 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:43 |
| alf__ | greyback: but that (host) mir surface is the framebuffer for all apps connecting to the nested server | 16:44 |
| greyback | alf__: gotcha | 16:44 |
| 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:45 |
| greyback | alf__: it is working as nested anyway | 16:47 |
| greyback | alf__: so seems killing lightdm screws up the DRM state | 16:47 |
| greyback | I want to find a clean way to stop USC | 16:48 |
| === dandrader is now known as dandrader|lunch | ||
| greyback | mterry where are you... | 16:57 |
| kgunn | greyback: i think mterry has the worst wifi ever | 16:58 |
| greyback | will resort to mail | 16:59 |
| 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:09 |
| alf__ | greyback: ok, ensure it's getting stopped normally (not -9) | 17:11 |
| greyback | alf__: right, it's not. I gets a SIGTERM, but just sits there. So teardown isn't happening for some reason | 17:12 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!