=== robert-ancell is now known as robert_ancell === chihchun_afk is now known as chihchun === irsol_ is now known as irsol [06:49] duflu: the thought was... we are passing a triplet of cursor_usage,w,h and it decided to ignore two parts of it to fullfill the first.. what if behaves the other way around or just fails.. [06:50] anpok_: I don't follow. But if you really do need the drmGetCap then ignore my comment [06:50] It's just a matter of the fix is too big, not faulty [06:50] duflu: hmm my point is.. i am not sure.. [06:51] the fix for radeon does not need it.. [06:51] anpok_: Well ignore Tegra. That's historically so slow (every revision) that we want to avoid caring about it [06:52] Why has Tegra been so consistently bad?? [06:52] Or the devices that contain them [06:53] RAOF: OK I'm now detecting the safety of frame dropping. If unsafe should we not drop (render with vsync) or throw a fatal exception [06:53] ? [06:54] I can't decide. So many evil choices [06:55] duflu: When is framedropping unsafe? [06:55] RAOF: When there aren't enough :) [06:55] buffers [06:55] I thought you were dynamically allocating said buffers? [06:56] RAOF: Not now. Choosing a different evil. I think overallocating creates an imbalance in the protocol request/reply for buffers and starvation/deadloack can happen [06:56] Throwing a fatal exception is certainly the wrong answer, though. Clients should not be able to crash the server. [06:57] ... that deadlock is the GLMark2Test hang [06:57] Hm. That seems like odd behaviour. Why do you think it causes a deadlock? [06:57] You can reallocate, but only at limited safe points in the lifecycle, which are not the same points we want to drop at [06:58] RAOF: Because glmark2 freezes and both client and server are left idle waiting for each other [06:58] Same theme as other bugs I'm fixing [06:59] Huh, I'm surprised. [06:59] Me too, but happy to not have an unbounded buffer queue too [07:02] Eh. [07:02] As a practical matter we kinda need one. [07:03] Or, rather, we need at least one per monitor plus one for the client [07:08] RAOF: Actually it's not entirely linear. Not simple, but if all monitors have the same frame rate then max two compositor buffers. [07:08] Or max three with bypass multimonitors [07:08] Or more with very slow refreshing monitors [07:08] But fortunately not linear with number of monitors [07:09] I'm really trying to avoid being asked to rewrite BufferQueue at the same time as the bug fxies [07:09] fixes [07:19] RAOF: To answer your earlier question; dropping frames in the wrong place results in us trying to send more exchange_buffer replies than we got requests, so that's an issue [08:19] Oh very weird. I'm seeing two compositor buffers held simultaneously on Android [08:19] is that overlays? [08:22] alf: Why is the jellyfish (glmark2) so much smoother on a phone than desktop? [08:22] alf__, ^ [08:40] duflu: it's smooth on my desktop :) [08:40] alf__: I mean the vertices [08:40] I've never found a desktop where it was smooth [08:40] But on mako I can see what it's meant to look like [08:42] duflu: Not sure what you mean... are you referring to e.g. the tentacles parts appearing to form corners? [08:42] alf__: Yeah but the body particularly [08:43] Like there's much higher mesh detail on the phone than desktop [08:46] duflu: I don't know... [09:12] "drop-dead-internals" has landed \o/ [09:22] Woo [09:22] Now to fix those freezes [09:22] To add to the mix, it seems our Android code becomes very unstable with frame dropping. [09:22] That's part of the problem [09:23] Fortunate that Unity does not use it yet [09:23] or much [09:44] alf__: main loop again.. i need it in two places of the input plaform interfaces.. [09:45] but I dont need start/stop only its base interfaces [09:45] waking on fd, action queue and timer [09:45] anpok_: do you mean the_main_loop() or do you need two new instances of e.g. GLibMainLoop? [09:45] all three.. [09:45] no the interface MainLoop [09:46] the various input platforms that we will need will either trigger events through the action queue, based on fd activity.. [09:46] but the decision which of those two is used in that case, depends on the platform [09:47] but I doubt they will ever need run/stop [09:47] or even worse, wouldnt even like them to use it.. [09:48] usage of Timer is an implementation detail i would simplify by reusing it.. [09:48] anpok_: So you want to give them an interface through which to add events or register fd actions. Who is going to own the main loop? [09:49] the input device hub in mirserver will own the input thread which drives that main loop instance (i try to avoid the term "the main loop") [09:51] anpok_: one option is to create a new interface in the input namespace that offers exactly what you need, and just implemented with a GLibMainLoop [09:51] I am close to not moving MainLoop over to platform and instead provide a separate interface [09:51] oh yes what you said [09:53] the other option is to reiterate the interface discussion with the idea that what the aggregation 'MainLoop' currently provides is a set of general purpose interfaces that need fixing [09:54] i kind of feel the urge to take the first door,, [09:54] It is better to adapt the interface hierarchy to current need than to speculate on future needs [09:55] anpok_: the MainLoop *is* an aggregation of general purporse interfaces (graphics::EventHandlerRegister, time::Timer, ServerActionQueue) [09:55] anpok_: but I think input owning the interface is best [09:55] graphigs::EventHandlerRegister is a too specific name and namespace imo [09:55] s/g/c [09:56] alan_g: you mean the speculation which parts of MainLoop will be required [09:56] It sounds like the new requirement is EventHandlerRegister+ServerActionQueue - but that the names are too specific [09:57] alan_g: That glmark2 freeze is more subtle than expected. Looks like our Android-specific code is at fault. But my new proposal today at least does not trigger it [09:57] alan_g: yes thats the next immediate requirement.. === chihchun is now known as chihchun_afk [10:01] duflu: as in "workaround" or as in "no worse than current"? [10:01] alan_g: No worse. The bug remains but I'm not working around it. Just not making it worse [10:01] Have two separate branches that will trigger it for future testing [10:02] Also, according to the date on the bug, you logged it before my branches existed :) [10:02] thanks for the update. You happy to continue with it or need me to take a look? [10:03] alan_g: I'll provide instructions in the bugs but will decide if I'm still concerned about them myself tomorrow [10:03] *bug [10:03] duflu: I recall that you didn't like the name mir_connection_platform_operation(...). Any suggestions? mir_connection_call_platform(), mir_connection_perform_platform_operation() ... ? [10:04] alf__: Yeah doesn't look nice but I can't think of a solution right now [10:04] OK. (I have my own "how does my code break that in CI?" issue to look into.) [10:04] I *expect* CI to pass. My phone certainly likes the new branch [10:05] alan_g: anpok: ^^ four lines up [10:07] * alan_g tries to imagine the context calling it... === chihchun_afk is now known as chihchun [10:39] alf__: where is that needed again? [10:42] anpok_: to replace platform specific calls e.g. mir_connection_drm_auth_magic(). Such functions are currently used by the EGL layer (e.g. in mesa) and also in the nested platform. [10:42] ahh yes [10:43] and really ...? [10:59] mir_connection_magic() [11:37] hm.. :p [11:37] 23782 frames in 5.0 seconds = 4756.278 FPS [11:37] should be better if I implement flip completion === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g === dandrader is now known as dandrader|afk [12:21] oh there we go [12:29] uploaded xorg-server_1.16.1.901-1ubuntu2+sa2 to my ppa, enjoy breaking things :P [12:34] mlankhorst: whats inside xorg? on mir? === dandrader|afk is now known as dandrader [12:44] standalone XMir, eg not using the xorg binary === pete-woods is now known as pete-woods|away [13:10] lack of cursor support is annoying === chihchun is now known as chihchun_afk [13:17] alan_g: What's the UMR fix? [13:19] alan_g: ahh, Uninitialized Memory... [13:37] alan_g: hm ogra today said that the alternative selection thing want upgraded after the last mir release [13:38] *wasnt [13:38] yeah, and mir still pulls in mesa [13:39] this would explain [13:39] which makes it use mesa libs by default [13:39] libmirplatform4driver-android is already the newest version. [13:39] oops [13:39] https://bugs.launchpad.net/mir/+bug/1396978 [13:39] Launchpad bug 1396978 in Mir "[testsfail] GLMark2Test fails to run in CI" [Undecided,New] [13:53] ogra_: you know what's going on then? ^^ [13:54] * alan_g hopes it is someone else's problem [14:03] alan_g, as i said, mir install libmirplatform4driver-mesa [14:06] But why has that started happening today and how do we fix it? [14:07] because today the new mir landed in the vivid image [14:08] we have a hack in the build scripts that forces the driver alternative to -adnroid even if -mesa is installed ... i just made sure that always gets applied, image #35 should behave better again [14:08] (indeed that wont solve the issue that we install mesa where we shouldnt) [14:08] so the mako image is broken because mesa is installed? [14:09] right, it has both, -mesa and -adnroid installed [14:09] the driver alternative defaults to mesa in such a case [14:13] I'm still not sure what the right way to fix is. (Hacking around the problem in the CI build isn't it though.) [14:14] just wait for the next image, it will have the forced alternative [14:14] (i assume CI devices just use the latest image) [14:15] long term it would be nice if we wouldnt end up with libmirplatform4driver-mesa on phones though :) [14:16] CI image updates are unpredictable (we've evidently got a mix currently) [14:17] I agree about not having libmirplatform4driver-mesa on phone - but the packaging stuff is magic where I don't understand how it should work well enough to fix it [14:18] * alan_g just knows it is broken === Rookie is now known as Guest98177 === dandrader is now known as dandrader|lunch === chihchun_afk is now known as chihchun === pete-woods|away is now known as pete-woods [15:01] ogra_: so the new meta packages didn't help? [15:02] AlbertA, well, not sure what pulls in -mesa ... it might not be mir but some other package with a dep that -mesa fulfills for it [15:02] this needs deeper research (whcih i currently cant do) [15:19] bah, when looking for failures to fix on things related to dri2, make sure they pass on normal x first :/ === dandrader|lunch is now known as dandrader === chihchun is now known as chihchun_afk === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [19:00] do I need to use opensource driver in order to test unity8 on utopic? [19:11] I'm on amd btw [19:45] RAOF: hi, is there a way to specify the position of a transient window/surface in the mir client api? or set the position of a surface in general? [20:13] attente_: the plan is to be able to specify the position of a child window relative to its parent window [20:14] is being worked on currently [20:15] greyback: thanks, is there a timeline for the feature? [20:16] attente_: January most likely [20:16] it's something I want too [20:16] greyback: can you tell attente_ a bit about the difference between the in-mir-process qt support and the normal-client qt support? [20:17] i know there are two things here but i forgot which is which [20:17] desrt: sure [20:18] Qt has a platform abstraction layer, to allow it be cross platform. Each platform has a plugin (QPA plugin). [20:18] so on linux we mainly use the xcb QPA [20:19] for Mir clients, we've an "ubuntumirclient" QPA plugin [20:19] for a mir server, we also made a QPA plugin "mirserver" which is what unity8 uses. [20:20] this plugin instantiates a Mir server, pretends that a Mir "Display" is a Qt QWindow, and connects up Mir's input handling with Qt's [20:21] so your Qt app, using this mirserver plugin, is in fact a mir server [20:21] if you use QML, anything you draw is drawn directly to the display's framebuffer [20:21] any mouse/key input goes straight to Qt [20:22] the final part to make Qt a useful mir server, is to allow it to integrate client surfaces into the QML scene, and send input events to those clients. For that we've a QML module [20:22] this is all implemented in lp:qtmir === benonsoftware is now known as \b === \b is now known as benonsoftware [20:28] sorry if i misunderstood, but the Qt app is a mir server? not a mir client? [20:37] attente_: unity8 is a special qt app which is a mir server. [20:38] all other apps on ubuntu touch are Qt apps which are mir clients [20:40] greyback: oh, ok