| === robert-ancell is now known as robert_ancell | ||
| === chihchun_afk is now known as chihchun | ||
| === irsol_ is now known as irsol | ||
| 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:49 |
|---|---|---|
| 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:50 |
| 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:51 |
| duflu | Why has Tegra been so consistently bad?? | 06:52 |
| duflu | Or the devices that contain them | 06:52 |
| 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:53 |
| duflu | I can't decide. So many evil choices | 06:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| RAOF | Huh, I'm surprised. | 06:59 |
| duflu | Me too, but happy to not have an unbounded buffer queue too | 06:59 |
| RAOF | Eh. | 07:02 |
| RAOF | As a practical matter we kinda need one. | 07:02 |
| RAOF | Or, rather, we need at least one per monitor plus one for the client | 07:03 |
| 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:08 |
| 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:09 |
| 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 | 07:19 |
| duflu | Oh very weird. I'm seeing two compositor buffers held simultaneously on Android | 08:19 |
| duflu | is that overlays? | 08:19 |
| duflu | alf: Why is the jellyfish (glmark2) so much smoother on a phone than desktop? | 08:22 |
| duflu | alf__, ^ | 08:22 |
| 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:40 |
| 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:42 |
| duflu | Like there's much higher mesh detail on the phone than desktop | 08:43 |
| alf__ | duflu: I don't know... | 08:46 |
| alan_g | "drop-dead-internals" has landed \o/ | 09:12 |
| 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:22 |
| duflu | Fortunate that Unity does not use it yet | 09:23 |
| duflu | or much | 09:23 |
| anpok_ | alf__: main loop again.. i need it in two places of the input plaform interfaces.. | 09:44 |
| 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:45 |
| 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:46 |
| anpok_ | but I doubt they will ever need run/stop | 09:47 |
| anpok_ | or even worse, wouldnt even like them to use it.. | 09:47 |
| 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:48 |
| 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:49 |
| 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:51 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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.. | 09:57 |
| === chihchun is now known as chihchun_afk | ||
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| alf__ | alan_g: anpok: ^^ four lines up | 10:05 |
| * alan_g tries to imagine the context calling it... | 10:07 | |
| === chihchun_afk is now known as chihchun | ||
| anpok_ | alf__: where is that needed again? | 10:39 |
| 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:42 |
| anpok_ | and really ...? | 10:43 |
| alan_g | mir_connection_magic() | 10:59 |
| 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 | 11:37 |
| === 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 | ||
| mlankhorst | oh there we go | 12:21 |
| mlankhorst | uploaded xorg-server_1.16.1.901-1ubuntu2+sa2 to my ppa, enjoy breaking things :P | 12:29 |
| anpok_ | mlankhorst: whats inside xorg? on mir? | 12:34 |
| === dandrader|afk is now known as dandrader | ||
| mlankhorst | standalone XMir, eg not using the xorg binary | 12:44 |
| === pete-woods is now known as pete-woods|away | ||
| mlankhorst | lack of cursor support is annoying | 13:10 |
| === chihchun is now known as chihchun_afk | ||
| alf__ | alan_g: What's the UMR fix? | 13:17 |
| alf__ | alan_g: ahh, Uninitialized Memory... | 13:19 |
| anpok_ | alan_g: hm ogra today said that the alternative selection thing want upgraded after the last mir release | 13:37 |
| anpok_ | *wasnt | 13:38 |
| ogra_ | yeah, and mir still pulls in mesa | 13:38 |
| 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:39 |
| ubot5 | Launchpad bug 1396978 in Mir "[testsfail] GLMark2Test fails to run in CI" [Undecided,New] | 13:39 |
| alan_g | ogra_: you know what's going on then? ^^ | 13:53 |
| * alan_g hopes it is someone else's problem | 13:54 | |
| ogra_ | alan_g, as i said, mir install libmirplatform4driver-mesa | 14:03 |
| alan_g | But why has that started happening today and how do we fix it? | 14:06 |
| ogra_ | because today the new mir landed in the vivid image | 14:07 |
| 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:08 |
| ogra_ | right, it has both, -mesa and -adnroid installed | 14:09 |
| ogra_ | the driver alternative defaults to mesa in such a case | 14:09 |
| 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:13 |
| 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:14 |
| ogra_ | long term it would be nice if we wouldnt end up with libmirplatform4driver-mesa on phones though :) | 14:15 |
| alan_g | CI image updates are unpredictable (we've evidently got a mix currently) | 14:16 |
| 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:17 |
| * alan_g just knows it is broken | 14:18 | |
| === 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 | ||
| AlbertA | ogra_: so the new meta packages didn't help? | 15:01 |
| 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:02 |
| mlankhorst | bah, when looking for failures to fix on things related to dri2, make sure they pass on normal x first :/ | 15:19 |
| === 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 | ||
| gcollura | do I need to use opensource driver in order to test unity8 on utopic? | 19:00 |
| gcollura | I'm on amd btw | 19:11 |
| 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? | 19:45 |
| greyback | attente_: the plan is to be able to specify the position of a child window relative to its parent window | 20:13 |
| greyback | is being worked on currently | 20:14 |
| attente_ | greyback: thanks, is there a timeline for the feature? | 20:15 |
| 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:16 |
| desrt | i know there are two things here but i forgot which is which | 20:17 |
| greyback | desrt: sure | 20:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| === benonsoftware is now known as \b | ||
| === \b is now known as benonsoftware | ||
| attente_ | sorry if i misunderstood, but the Qt app is a mir server? not a mir client? | 20:28 |
| greyback | attente_: unity8 is a special qt app which is a mir server. | 20:37 |
| greyback | all other apps on ubuntu touch are Qt apps which are mir clients | 20:38 |
| attente_ | greyback: oh, ok | 20:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!