| racarr | only 68 more files to remove mir event access from | 01:02 |
|---|---|---|
| racarr | will be here for meeting but going to break for a while | 01:29 |
| DalekSec | Hello! Sorry to come with so little detail, but is there a known issue with xmir, nouveau, tty switching, or such that would cause a screen lockup? What I did, booted into the xmir session, looked at a couple things, ran a few commands, switched to a tty and ran a couple more, switched back to TTY7 and after a little typing nothing seemed to take anymore, keyboard or mouse. I was also unable to | 02:43 |
| DalekSec | switch TTYs. | 02:43 |
| DalekSec | Congrats otherwise, was more responsive than before! :) | 02:46 |
| duflu | DalekSec: Not surprising such bugs might still exist, but I'm not aware of anyone else still experiencing that kind of thing. Not sure | 02:53 |
| DalekSec | Oh sorry, Mir 0.10.0, forgot to say. >_< | 02:54 |
| DalekSec | duflu: OK, thanks. It was a live session anyway, so no harm. | 02:54 |
| duflu | DalekSec: Yeah I could tell if it's "more responsive" :) | 02:54 |
| DalekSec | Ahaha. :D | 02:54 |
| duflu | DalekSec: BTW Mir 0.11 will be noticeably better for XMir | 02:55 |
| DalekSec | duflu: Oh? And is that going to be released into vivid soon? | 02:56 |
| duflu | DalekSec: Probably more like a month away. It will take that long to reach critical mass | 02:56 |
| DalekSec | Ah, alright. Thanks. I suppose I should check the tabloids to see what might be coming. :P | 02:57 |
| duflu | DalekSec: Maybe, but this channel is more accurate :) | 02:58 |
| duflu | because the Mir team is actually here | 02:58 |
| DalekSec | Oh indeed, I don't follow it too closely though, too many things to keep track of. | 02:58 |
| duflu | Ha. I keep starting the wrong version of our demo servers by accident. But you notice the difference immediately as 0.10 is noticeably more laggy than 0.11 | 03:41 |
| duflu | racarr: You could make a permanently opaque structure for clients like: | 04:37 |
| duflu | struct MirEvent | 04:37 |
| duflu | { | 04:37 |
| duflu | long long serial_num; // A unique ID for this event. Only Mir can use it. | 04:37 |
| duflu | }; | 04:37 |
| duflu | And let the server decide how long is right to remember each one internally | 04:37 |
| duflu | if not "char opaque[1024];" ;) | 04:38 |
| DalekSec | (Oh woah, 1212753 was fixed?! Also, I don't suppose that'll fix the software renderer?) | 04:39 |
| duflu | I mean let the client library decide how long to keep the internal representation of each | 04:39 |
| duflu | DalekSec: Kinda. That error should now be impossible but none of mir-team has hardware to reproduce and verify it | 04:40 |
| DalekSec | So I suppose if I get a chance, I should check it. OK, coolio. I'll stop bugging now. :) | 04:41 |
| === chihchun_afk is now known as chihchun | ||
| duflu | Ugg, I top approve things and then am surprised when they land | 06:24 |
| duflu | Clever | 06:24 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| anpok | hm is there any reason why RAOF used mir/{client,server}-platform as install paths for platforms but just {client,server}-modules inside the build? | 09:01 |
| === sil2100_ is now known as sil2100 | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| greyback | alf_: hey, I've multimonitor working with Qt. Did you ever observe, with mesa, that one display's swap buffers would cause swap buffers of the other display to block? | 10:34 |
| anpok | wow, one thread per monitor? | 10:35 |
| greyback | yeah | 10:35 |
| anpok | and a single qml scene? | 10:35 |
| greyback | yeah | 10:35 |
| alf_ | greyback: \o/, I haven't noticed this. Could it be locking at the qml/qt level? | 10:35 |
| anpok | hm then one event loop .. hmm are renderers allowed to draw one scene multiple times? | 10:35 |
| alf_ | greyback: Also is this using MultiThreadedCompositor now or just Qt as before? | 10:36 |
| greyback | anpok: one per "frame" the QML scene is synchronized with the scenegraph. The scenegraph can then be passed over multiple times if need be | 10:37 |
| anpok | oh | 10:37 |
| anpok | i mean .. cool | 10:37 |
| greyback | alf_: just Qt. It's another project to combine mir and qt's renderers | 10:37 |
| alf_ | greyback: ok | 10:38 |
| greyback | anpok: note it's not a single scene as you'd define it. We've 1 QML scene, but it is split into 2 subtrees, one subtree for each monitor | 10:38 |
| greyback | anpok: so I can't easily have something 1/2 way on each monitor | 10:38 |
| greyback | alf_: so yeah it could be many things, I just heard rumour mesa might be an issue | 10:40 |
| anpok | hm something like that might happen with qxl | 10:41 |
| alf_ | greyback: I haven't noticed something like this locally, but I haven't tried MM recently. Does the blocking have a visible effect? | 10:41 |
| greyback | alf_: with relatively complex scenes yes. I see one monitor's eglSwapBuffer block for 7-10ms every frame | 10:42 |
| greyback | I'm sure you would have noticed that however. So probably something I'm doing wrong | 10:42 |
| greyback | but yay for almost working , and not crashing | 10:43 |
| alf_ | greyback: Is that the low-level eglSwapBuffer call in mesa::DisplayBuffer ? | 10:43 |
| greyback | alf_: not quite, it's the DisplayBuffer::gl_swap_buffers and flip calls | 10:44 |
| alf_ | greyback: If this includes flip then a delay is normal, since need to synchronize with vsync to do the flip. | 10:47 |
| * greyback goes to disable on non-primary monitor... | 10:55 | |
| alf_ | greyback: having said that, you should also be seeing such a "delay" even with one monitor. If you are seeing very different delay behavior with multiple screens we should look into it. Of course, with multiple screens we are stressing the GPU more... | 11:04 |
| greyback | alf_: I only see such a delay with one monitor. I want to see how a stock mir server behaves | 11:05 |
| duflu | greyback_: Multi-monitor could theoretically suffer from indefinite freezes on secondary monitors (part of bug 1395581) | 11:21 |
| ubot5 | bug 1395581 in Mir "Double-buffered surfaces may lag or freeze if event driven and not constantly redrawing" [High,In progress] https://launchpad.net/bugs/1395581 | 11:21 |
| duflu | ... in theory | 11:21 |
| duflu | Although your render time should be <1ms on desktop | 11:22 |
| greyback_ | duflu: ok, will keep that in mind. I've an animation on both screens, so both should be constantly redrawing | 11:23 |
| greyback_ | how do I make proving shell change to side-by-side config? | 11:23 |
| duflu | greyback_: --help ;) | 11:23 |
| greyback_ | you mean I have to read, ugh | 11:23 |
| duflu | greyback_: Also you'll get significantly higher performance releasing all your renderables before the flip() | 11:24 |
| duflu | If not already | 11:24 |
| greyback_ | duflu: not so easy for qtmir to do that just yet, but yeah I understand why | 11:25 |
| duflu | greyback_: Sounds a lot like buffers_ready_for_compositor() is underestimated for the second monitor... which is bug 1395581 | 11:26 |
| ubot5 | bug 1395581 in Mir "Double-buffered surfaces may lag or freeze if event driven and not constantly redrawing" [High,In progress] https://launchpad.net/bugs/1395581 | 11:26 |
| greyback_ | duflu: I'm not even rendering client surfaces yet. This is compositor only | 11:27 |
| duflu | greyback_: Not nested I take it | 11:27 |
| greyback_ | well mir-proving-shell works nicely | 11:27 |
| greyback_ | duflu: correct | 11:27 |
| duflu | greyback_: OK, good luck. It's getting late here | 11:28 |
| greyback_ | so qtmir has a problem somewhere | 11:28 |
| greyback_ | duflu: absolutely, go away :) | 11:28 |
| duflu | Kay | 11:28 |
| alan_g | greyback_: would you also check "mir_demo_shell --display-config sidebyside --window-manager tiling"? (There are some - probably irrelevant - compositing tweaks in proving shell) | 11:36 |
| greyback_ | alan_g: ok | 11:37 |
| greyback_ | alan_g: ah I don't have the latest mir for that | 11:37 |
| greyback_ | mir_proving_server --display-config sidebyside --window-manager tiling | 11:38 |
| greyback_ | [1421840251.676989] (II) SharedLibrary: Loading libmirplatform5driver.so | 11:38 |
| greyback_ | Unknown command line options: --window-manager tiling | 11:38 |
| alan_g | greyback_: nevermind then | 11:38 |
| greyback_ | next time | 11:38 |
| alan_g | Like I said the tweaks are probably irrelevant. Just peace of mind to eliminate them | 11:39 |
| greyback_ | just figured out it's a qt problem, so I wouldn't worry :) | 11:40 |
| alan_g | :) | 11:43 |
| anpok | for various definitions of 'I'? | 11:43 |
| greyback_ | :D | 11:43 |
| alan_g | anpok: it's a common abbreviation for "if I were you then I wouldn't worry"/"I wouldn't worry if I were you" | 11:46 |
| anpok | ... lost in translation | 11:50 |
| === alan_g is now known as alan_g|lunch | ||
| === dandrader is now known as dandrader|afk | ||
| === alan_g|lunch is now known as alan_g | ||
| === dandrader|afk is now known as dandrader | ||
| === marcusto_ is now known as marcustomlinson | ||
| === chihchun is now known as chihchun_afk | ||
| tsdgeos | guys, do you use zeitgeist for something? | 15:05 |
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| === alan_g is now known as alan_g|EOD | ||
| === SturmFlut|AFK is now known as SturmFlut | ||
| === greyback__ is now known as greyback | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!