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