#ubuntu-mir 2013-11-01 <duflu> Back in 30ish <alan_g> alf_: I've got a workman turning up in the next few minutes - I might be a little late for greyback's meeting <alf_> alan_g: ok <alan_g> greyback: : I've got a workman turning up in the next few minutes - I might be a little late for your meeting <greyback> alan_g: no worries <xnox> alan_g: alf_: so emulator is mostly working now. There is functional adb and networking. So far it attempts to boot into "mir" mode. <xnox> I've made sure to compile all android container unstripped (so debug symbols are intact) <alf_> xnox: I am missing some context here :) <xnox> attempting to start unity8 results in a segmentation fault, trying to run it under gdb only says that stack is corrupt =/ <xnox> alf_: so I want to ask for help bringing up mir / any graphical output on the emulator =) <alf_> xnox: which emulator is that? <xnox> alf_: sometime back kgunn recommended you or alan_g as UK time people, who can help out with it. <alan_g> xnox: what emulator? <xnox> alf_: it's android-emulator packaged to run Ubuntu Touch. So it boots unflipped/read-only system image, with an android container. <xnox> alan_g: alf_: https://wiki.ubuntu.com/Touch/Emulator <xnox> also i've been posting about on ubuntu-touch. <xnox> it's a QEMU based ARM virtualised machine, running linux-goldfish kernel with android container and everything mostly the same as normal android device. <xnox> (apart from well, not displaying mir) <alan_g> xnox: so, what happens if you try running e.g. mir_demo_server_basic? <alf_> xnox: you can try running Mir on its own to see what's going on <alf_> alan_g: You beat me to it! :) <alan_g> alf_: is it a race? <alf_> alan_g: No, but we had a photo-finish nonetheless ;) <xnox> root@ubuntu-phablet:/# mir_demo_server_basic <xnox> bash: mir_demo_server_basic: command not found <xnox> (this is running Ubuntu Touch rootfs, should be similar to mako/maguro tarballs et.al.) <ogra_> its in a separate package <alan_g> xnox: can you install mir-demos? Or do you need to build it? <xnox> alan_g: i can, but it's very slow. I might repack a tarball and relaunch it. * alan_g thinks Mir won't work unless it is installed <xnox> same as before: <xnox> root@ubuntu-phablet:/# mir_demo_server_basic <xnox> __pthread_gettid -2 <xnox> Segmentation fault <xnox> which is similar to running unity8 et. al. <xnox> http://paste.ubuntu.com/6340712/ <xnox> alan_g: alf_: if you could figure out what's broke, i'd be happy to fix it both in android, ubuntu and emulator. But at the moment i'm not sure what's wrong, as pretty much everything else is working. <greyback> a BT like that always makes me suspect hybris <xnox> and i don't usually work on amy08@example.org. <alan_g> debug symbols might help with the BT <alan_g> what happens if you try run "mir_demo_server_basic --display-report log" <alan_g> That might give a clue as to how quickly it segfaults <alf_> xnox: +1 debug symbols might help with the BT <xnox> alan_g: same output. <xnox> alan_g: so it's something fundamental =/ <alan_g> xnox: ack <xnox> alan_g: alf_: on android side in logcat i see that it's loading up EGL emulation, there is also GLES_android, GLESv1_CM and GLESv2 available. <alf_> xnox: I wonder if running under valgrind could give you more clues <rsalveti> kdub: ping <kdub> hello rsalveti <rsalveti> kdub: hey, so we were debugging the nexus 7 (tegra 3) issue yesterday, and we basically believe our code path might not be doing what the driver expects us to do <rsalveti> the crash happens in pthread_mutex_lock <kdub> rsalveti, 'our code path', meaning in hybris or mir? <rsalveti> and the lock is basically a pointer, unitialized <rsalveti> kdub: mir, by the way we're using the hwcomposer/gralloc <rsalveti> the first time it uses that pointer is already when trying the lock <rsalveti> so we believe we might be skipping a call or step that initializes that value internally <kdub> rsalveti, i don't know of something that surfaceflinger does that we're skipping <kdub> which function call into hybris has the problem? <rsalveti> kdub: the pthread_mutex_lock <rsalveti> kdub: the mutex pointer is not initialized, so just garbage <rsalveti> that's why when we try to access it, it crashes <rsalveti> I'm not sure yet that this is hybris specific at this point <kdub> right, but do we know the last function call mir makes? <rsalveti> do we have any sort of test cases/tools for hwcomposer/gralloc? <kdub> just the mir tests <kdub> mir_demo_standalone_render_to_fb should just drive the display <rsalveti> kdub: right, let me see, the crash happens with mir_demo_server <kdub> but it will have the same problem as the server <rsalveti> kdub: right <rsalveti> kdub: let me try to get a better backtrace <rsalveti> kdub: but the issue, iirc, was that it was coming from gralloc <rsalveti> which is just a blob, making it harder to get the full trace <kdub> right <kdub> i mean, it could be some dumb thing like... <kdub> on nvidia you have to open {gralloc, fb, hwc} in some specific order <rsalveti> kdub: yeah <brainwash> how do I switch to hardware cursor when running xmir? <kdub> i always like how the interface you couldn't quite get right at 6pm makes a lot more sense at 10am the next day <alan_g> kdub: that's after you've realised how to write the test. Right? <kdub> alan_g, yeah, you still have to decide what sort of things you want the test to test <alan_g> kdub: well if you don't know what "works" looks like it is hard to get the interface right <rsalveti> kdub: yeah, mir_demo_standalone_render_to_fb crashes the same way <rsalveti> kdub: do you have a n7 around? <rsalveti> kdub: I'm checking render_to_fb.cpp, but it seems the the buffer itself is null <rsalveti> which could be the reason for the mutex garbage content <kdub> yes, but when you say buffer, you mean, mir's buffer class? <rsalveti> kdub: crashing in src/server/graphics/android/hwc10_device.cpp -> hwc_device->set(hwc_device.get(), 1, &contents); <kdub> rsalveti, hmm <kdub> i have to tinker with that then <kdub> i'm actually working on improving that part of the code at the moment, maybe i'll find somehting <rsalveti> kdub: any ideas which we could try? <kdub> rsalveti, perhaps the list that's submitted there 'contents' isn't formed the way the driver expects it <kdub> hard to so how its malformed without tinkering with it though <rsalveti> kdub: so, when we set HWC_SKIP_LAYER at the hwcompositor layer, it doesn't crash <rsalveti> kdub: nothing in the screen, as expected, but the gl path and such is working as expected at least <kdub> rsalveti, thats good new news <rsalveti> kdub: so it might be something related with the hw layers <kdub> rsalveti, yes, it looks like it is #ubuntu-mir 2013-11-02 <brainwash> so (x)mir cannot handle hybrid graphics if both gpus are turned on? #ubuntu-mir 2013-11-03 <mardy> hi! Does Mir use EGL drivers, or does it require some modifications to them? <RAOF> mardy: The question is sort of malformed; EGL is a cross-platform(ish) way of mapping from a windowing system to GL/GLES/OpenVG/etc. <RAOF> mardy: So, accelerated Mir clients use an EGL driver - with Mir platform support - to draw to the surfaces they've created through Mir. <racarr> Mir uses EGL, but requires additional driver support basically <RAOF> mardy: And on the server-side, Mir uses various EGL platforms, yes. On the free stack Mir uses the drm platform to do the KMSâGLES mapping; on Android it loads the magical android stuff to do the same job. <RAOF> racarr: Also, a fine Sunday evening to you! <racarr> RAOF: Howdy :) <racarr> Happy monday morning #ubuntu-mir 2013-11-04 <RAOF> Oh, man. st33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abtie! <mlankhorst> is that an outcome of st33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abvote? :P * duflu resizes a surface, and kernel panics trusty <duflu> And again :P <ogra_> stop resizing surfaces then ... <alan_g> http://search.dilbert.com/comic/Definition%20Of%20Insanity <mardy> RAOF: thanks! Then let me refrase the question, in a more direct way <mardy> RAOF: the Nokia N900 and N9 phones come with EGL drivers (binary only, not open source); is there some chance to get Mir (and Ubuntu Touch) working on these phones? <mardy> they are real Linux phones, not Android <tvoss> mardy, what is the graphics buffer management, modesetting api used by those drivers? <Stskeeps> mardy: you can possibly do it with nitdroid drivers but you'd have to suffer from terrible tearing <Stskeeps> plus the problem is that n900 doesn't grok thumb2 due to a HW bug <mardy> tvoss: no idea <mardy> Stskeeps: Nemo is using the original EGL binaries, right? <mardy> Stskeeps: I'm not sure what the problem is; are these binary blobs tied in some way to X11? <tvoss> mardy, would be good to find out to answer your question <Stskeeps> mardy: yeah and x11.. we've tried with wayland on there but you need to spend immense time to get proper vsync going on that rather custom stuff <tvoss> Stskeeps, +1, reusing x11 interfaces is close to impossible <Stskeeps> so i've practically given up on those devices for any purpose <mardy> Stskeeps: I see... is nitdroid reusing the original drivers, or is it using android drivers taken from some other device (with compatible HW)? <Stskeeps> uses android drivers of dubious origin and licensing <mardy> cool :-) <mardy> Stskeeps: TBH, I don't care about licensing, I would just distribute instructions, not images <Stskeeps> :nod: <Stskeeps> but even then, the problem would be that tearing would be quite bad and direct rendering/hw composition is not that sane on those devices <mardy> again because of the drivers? Or is there some HW limitation (let's forget the N900 for a moment) <Stskeeps> drivers plus custom vsync handling in display/kernel <tvoss> mardy, if we do not have the hwc available, results are pretty bad. The same happens for the N7 <mardy> mmm... I guess I won't spend much time on this then :-) <tvoss> greyback, ping <greyback> tvoss: pong <greyback> I saw you've added comments to the doc, I'll have a look shortly <tvoss> greyback, hey, looking at the scenegraph document right now. I was thinking if we should add an introductory paragraph on different functionalities touched/covered by the scenegraph <tvoss> obviously rendering, but also, input, application handling, focus handling etc <tvoss> which would then allow us to augment the proposals with details on how things would be solved for those areas, too <greyback> tvoss: makes sense <tvoss> greyback, cool <greyback> tvoss: after that's done, how best you think to proceed? I've had a meeting with some of the Mir team on the rendering side, I think they were cautiously open to the idea. Input side, I need to get racarr and dandrader and myself in a meeting too. <tvoss> greyback, we should decide on a rough plan and have an iteration 0 asap to flesh out remainding details and identify blockers early on <tvoss> greyback, separate branch, full steam ahead. Once complete, we refactor into trunk <tvoss> greyback, makes sense? <greyback> tvoss: yes. <greyback> tvoss: ok, so I'll meet with racarr and dandrader on input matters this evening. If no major blockers are evident from that, I'll send round a mail with a proposed plan, set up a meeting to discuss it, and if I get go-ahead, execute <greyback> tvoss: how that sound? <tvoss> greyback, +1. I'm specifically interested in details on how you plan on updating focus, and thus app/surface/input details, atomically <greyback> tvoss: ok, I'd better get those details sorted <racarr> Morning <alan_g> Afternoon <alf_> Evening <greyback> racarr: heya, have you time soon to talk about Mir and Qt? <racarr> greyback: Ok we have our standup in 4 minutes but besides that <racarr> when is good for you? <greyback> racarr: well it's getting late here, so I'd prefer reasonably soon. dandrader|lunch should be there, he's been looking more at the input side than I have <racarr> greyback: Ok how about in 30 minutes? or tomorrow before the standup <greyback> dandrader|lunch: will you be back in 30 mins? <greyback> racarr: I'll be here anyway, so we can chat <racarr> ok <racarr> Is there no standup now or is my google hangout not working? <ricmm> kdub: ping <ricmm> kdub: lemme know when you are around! <kgunn> greyback: can i just lurk/listen in ? <greyback> kgunn: sure <racarr> greyback: ok hangout? <greyback> racarr: yeah, let's do it. alf_ wanna join? <greyback> dandrader: ah, good timing :) <racarr> https://plus.google.com/hangouts/_/7ecpju9thmntft9e183v78t8bc?authuser=1&hl=en <dandrader> greyback, I'm back <greyback> dandrader: short notice, but racarr & I are having a meeting now <alf_> greyback: I am in another meeting, will join as soon as I can, don't wait <greyback> kgunn: we're in meeting, can you join? <kgunn> yep <kgunn> greyback: where you at? <greyback> kgunn: https://plus.google.com/hangouts/_/7ecpju9thmntft9e183v78t8bc?authuser=1&hl=en <greyback> alf_: can you join now? <kdub> ricmm, pong <alf_> greyback: yes, joining <alf_> alan_g: ^^ hangout for the scenegraph:input side of things <alan_g> alf_: ack <gema> hi, how do I enable mir on trusty? <gema> is there a wiki explaining this? (for desktop) <tvoss> gema, this should help: https://wiki.ubuntu.com/Mir/Installing <gema> tvoss: thanks :D <davmor2> kgunn, tvoss: so it looks like unity and java based apps hate xmir on intel <tvoss> davmor2, on trusty? <davmor2> tvoss: no I haven't done the migration to trust that won't happen to beta time when things settle a bit <davmor2> tvoss: this was on Saucy for all the commercial apps <tvoss> davmor2, so unity and java apps together fail? <davmor2> tvoss: unity3d sorry the games engine and java based apps. Java says things like no GLX and unity3d Flashes like a strobe light <tvoss> davmor2, now that is interesting. And it works flawlessly without xmir? <davmor2> tvoss: indeed <tvoss> davmor2, okay, did you file bugs yet? <davmor2> tvoss: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Ai33BkOcORLLdGI2dE5hWHN1cXRaOXVRZHdrY2E5eWc&usp=drive_web#gid=0 no bugs filed yet completing the app migration was the primary task which got completed Friday evening <tvoss> davmor2, ack and thx, will take a look after dinner <davmor2> tvoss: if you look for the orange apps from the key those are all the ones that just wouldn't work due to xmir but were released as they worked flawlessly without xmir (which was then nolonger the default) the unity3d apps were let through as they were fine other than the strobe light effect <davmor2> tvoss|dinner: http://ubuntuone.com/4EniBLWsk5yxjJYyDjfTGy for the strobe effect <kgunn> davmor2: ack will look at after i go for a run <davmor2> kgunn: no rush just had time to go back and see if it was xmir or not :) <brainwash> it that the DPMS flicker? <davmor2> brainwash: no idea only happens on the unity3d games I can dig about and find you some that don't cost anything if you want to confirm it and figure it out for yourself :) <brainwash> bug 1232343 <ubot5> bug 1232343 in XMir "XMir Screen flickering when running steam or SDL games" [High,New] https://launchpad.net/bugs/1232343 <robotfuel> davmor2: brainwash: this could also be related. https://bugs.launchpad.net/xmir/+bug/1231632 <ubot5> Ubuntu bug 1231632 in XMir "Setting DPMS mode for output to 0 causes screen to blink/flicker once" [Medium,Triaged] <brainwash> yeah, annoying stuff <tvoss|dinner> kgunn, ping <davmor2> brainwash: I think a lot of the apps that have the problem are window/mac conversions so I'm not sure if it is just the way it calls glx that is causes xmir to reveal a bug that is normally hidden in X or an issue in xmir itself which is also really hard to tell <kdub> ricmm, where is the hwcomposer library that we're trying to get working? <kdub> i think it was removed from the nex7 build <bschaefer> has anyone ran the mir server natively on a 32 bit desktop in while? As im getting a failure to create a GBM buffer (for the cursor) similar to this: <bschaefer> https://bugs.launchpad.net/mir/+bug/1203070 <ubot5> Ubuntu bug 1203070 in Unity System Compositor "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Fix released] <bschaefer> on an intel chip <tvoss|dinner> bschaefer, can you please file a bug? <bschaefer> tvoss|dinner, yes i can <tvoss|dinner> bschaefer, thx <bschaefer> np! <bschaefer> https://bugs.launchpad.net/mir/+bug/1247943 <ubot5> Ubuntu bug 1247943 in Mir "Mir server failing to start when compiled for 32bit" [Undecided,New] <bschaefer> hopefully RAOF or duflu could take a look <ricmm> kdub: I think it uses the default hwcomposer lib <kgunn> tvoss|dinner: pong <kgunn> need to reboot...got some desktop weirdness happening #ubuntu-mir 2013-11-05 <robotfuel> duflu: ping <duflu> robotfuel: pong <robotfuel> duflu: armhf is failing on a new warning, I've opened https://bugs.launchpad.net/mir/+bug/1248014 <ubot5> Ubuntu bug 1248014 in Mir "/tmp/buildd/mir-0.1.1/tests/unit-tests/android_input/input_reader.cpp:758:36: note: 'args.androi33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abNotifyConfigurationChangedArgs33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abventTime' was declared here NotifyConfigurationChangedArgs args;" [Undecided,New] <duflu> robotfuel: Thanks. I noticed just a few seconds ago <tvoss> RAOF, ping <Mirv> do you need a bug about unity-system-compositor failing to build against the new Mir? <Mirv> fatal error: mir/shell/focus_setter.h: No such file or directory <duflu> Mirv: Yes please. The change looks intentional... https://code.launchpad.net/~alan-griffiths/mir/tidy-shell-component-pass-2/+merge/193418 <Mirv> bug #1248055 <ubot5> bug 1248055 in Unity System Compositor " unity-system-compositor FTBFS on trusty against new Mir (libmirserver10)" [Critical,New] https://launchpad.net/bugs/1248055 <Mirv> bug #1248080 too <ubot5> bug 1248080 in unity-mir "unity-mir FTBFS libmirserver10" [Critical,New] https://launchpad.net/bugs/1248080 <didrocks> duflu: kgunn: Mir was pulled to trunk without warning us? <didrocks> and ensuring that the deps are building? <duflu> didrocks: I was asked by kgunn last week to do it on Monday (so everyone was ready). <didrocks> duflu: we still need: <didrocks> 1. to get an email from you knowing you are doing so <didrocks> 2. you need to ensure we can build unity-mir and u-s-c from it <didrocks> which isn't the case, right? <duflu> didrocks: It's impossible to guarantee those simultaneously. And I wasn't aware of any failures. In fact I argued we shouldn't do a pull at all <didrocks> duflu: so please revert this pull <duflu> didrocks: Sure <didrocks> as long as you aren't sure you aren't ready <didrocks> thanks <didrocks> reverting to the previous version we released please <didrocks> Mirv: sil2100: FYI ^ <didrocks> Mirv: sil2100: remove them from the ppa please <Mirv> didrocks: ok, so so you also want a push --overwrite of the trusty branch to previous released version, or would it be enough to disable mir building + remove all relevant PPA packages? <didrocks> Mirv: let's get duflu put his trunk in shape again <didrocks> so just remove the components from the ppa <didrocks> and rekick a build for them <duflu> Mirv: An overwrite will be required. As we've lost the history of the post-0.1.0 Ubuntu changes. There's a weakness in the new system <duflu> I'm not sure who/where still holds a copy of that <didrocks> (mir, platform-api, unity-mir, u-s-c) <Mirv> didrocks: ok, duflu should be better suited to do that, as also the mir/trusty history is gone and there is no release commit anymore of the previous release <duflu> didrocks: I can take it back to 0.1.0 vanilla, but we don't have the history to restore 0.1.0+14.04.20131030-0ubuntu1 accurately <didrocks> Mirv: really? <didrocks> duflu: urgh? what have you done? <Mirv> didrocks: yep https://code.launchpad.net/~mir-team/mir/trusty <sil2100> ;/ <didrocks> duflu: what happened so that you reverted our commit? <didrocks> can you please restore it? <Mirv> didrocks: I think it's the development branch push --overwrite:d to the stable branch <didrocks> that was explicitely forbidden <duflu> didrocks: The pull clobbered it (as bzr noticed the same code in development-branch). So you lose the Ubuntu-specific history <didrocks> duflu: yeah, please restore it, manually <duflu> ... happens even without --overwrite <didrocks> and pull that to the dev branch <didrocks> I think we'll go again with merging if the mir team doesn't know what they do <duflu> didrocks: Dev is sacred and not overwritable. This is definitely a weakness in the system. If it stops arguments, I don't care if we revert to merging <didrocks> duflu: so let's merge dev to trunk then <didrocks> trunk is sacred <didrocks> and should not be overwritable <didrocks> you are messing with the whole system * didrocks isn't happy <duflu> didrocks: Yes, I never considered this possibility. I can rebuild the branch by hand, but not with the same history as it had <didrocks> duflu: so yeah, rebuild with what we had <didrocks> with 0 change from distro <didrocks> and the changelog in <duflu> didrocks: OK... rebuilding back to zero diff to distro <didrocks> thanks <duflu> didrocks: Although merging to trunk means it's no longer "sacred" because merge makes the history rubbish :( <duflu> Hmm <didrocks> duflu: well, at least, we ensure each commit from trunk can be buildable <didrocks> with the right soname and so on <didrocks> which isn't the case when you pull dev to trunk <didrocks> but I think we already show that pulling dev to trunk is an issue <duflu> didrocks: Yeah I don't care to argue about it any more. Rebuilding... <didrocks> thanks duflu <didrocks> duflu: can you give a sign to Mirv and sil2100 once done? <duflu> didrocks: Yep. When done I'll reinstate append_only too <duflu> didrocks,Mirv,sil2100: lp:mir restored to 0.1.0+14.04.20131030-0ubuntu1 <didrocks> thanks <Mirv> duflu: thanks <tvoss> greyback, good morning <sil2100> Thanks <duflu> ... and now append-only. All pull/push attempts will fail <greyback> tvoss: hi :) <duflu> ... I mean pull/push attempts that clobber history will fail <duflu> didrocks: Does this mean the Ubuntu branch isn't used for anything? (lp:ubuntu/mir) <didrocks> duflu: this is for automated import from debian, it doesn't work with dailies <duflu> Ah <duflu> didrocks: I still can't help but think... what you want from lp:mir is all about Ubuntu requirements, so it should live in lp:ubuntu/something <didrocks> duflu: you are merging your branch based on ubuntu rules <didrocks> it's the case for the 250 components we ship and develop upstream <didrocks> I don't think Mir should have a special treatment <didrocks> in addition, all teams following the ubuntu/canonical requirements are quite successful in the way they are handling their projects <didrocks> I think the Mir team should start listening as well to go the same path <duflu> didrocks: I completely agree with your frustration, which I think is rooted in Mir's lack of stable server ABI. I was arguing against exposing what we have now, and what has led to this situation long before it happened :( <didrocks> duflu: I'm afraid the only way to mitigate this right now is this dev branch + merging back trunk <duflu> didrocks: Yep. *everything* is append_only again. <didrocks> yeah, sounds good :) <tvoss> duflu, didrocks I would like to point out again that the server api is meant to evolve <didrocks> tvoss: I don't care as long as transitions are coordinated and everything is known to build against the new API <tvoss> didrocks, sure, that's the problem we need to tackle, fully agreed <didrocks> just as told during the sprint, be aware that we have to block everything for 5 hours at each ABI breakage <tvoss> didrocks, sure, but I still think that an ABI break shouldn't be an unusal case, but considered the normal situation :) Anyway, I know why we need to block right now, so point taken <duflu> didrocks: Is there a solution in place to locking/unlocking atomic changes between projects? Or is it just convention that consumer projects get updated before providers? <didrocks> tvoss: you can break your interfaces, but the way it's dealt with would mean everything should be in the same project (source) <didrocks> duflu: it's a convention for now. I proposed a new CI vision that the infra CI team will start building soon where we can put in place "transactions" <didrocks> (over multiple projects) <duflu> didrocks: Yep, "transactions" is the word I meant <didrocks> your team will be one of the piloting team on that I guess :) <duflu> didrocks: Isn't that backwards to how non-Canonical updates work? I mean we can't control changes to all non-Canonical "provider" projects like that (?) <didrocks> duflu: right, but on those projects, people are backward compatible most of the time <didrocks> we are still at glib2 <didrocks> or gtk3 <didrocks> after years <duflu> didrocks: Yeah I've never seen an ABI change as much as Mir :) <didrocks> so yeah, the system will be a way to help for them as well <didrocks> but not be a requirement <didrocks> (at least, for now) <mlankhorst> hey <mlankhorst> RAOF: ping? <mlankhorst> it looks the easiest way to support glamor-egl with xxv-ati might be to simply use the same codepath as used by nested mir <mlankhorst> or I guess make glamor-egl use mir natively without gbm <duflu> mlankhorst: It's 21:30 for him <mlankhorst> yeah, I'll look into it a little myself <mlankhorst> I guess the easiest way is to bypass most of xmir :P <mlankhorst> hm and I guess it *could* be done in a generic way, removing all the crap from the ddx, only requiring glamor-egl and xorg-server <Prf_Jakob> mlankhorst: just a quick question, is the plan to use glamour-egl on all drivers as a for of generic driver for Xmir? <mlankhorst> no idea yet :P I guess some egl magic will be used, and some mir magic for input/screens <Prf_Jakob> Ok <Prf_Jakob> If you read my response on mir-devel we have found that xa (and probably glamour) would be slower then software (at least for not insane window sizes). <mlankhorst> hm don't know if I'm subscribed there *checks* <tvoss> Prf_Jakob, hey there :) just spotted your nick :) <mlankhorst> oh indeed <Prf_Jakob> tvoss: hey hey! <mlankhorst> sigh vmware being different again <Prf_Jakob> virgil will be in the same position. <Prf_Jakob> So its not just us. <mlankhorst> virgil doesn't have egl though? <Prf_Jakob> its a gallium driver, so I guess it does. <mterry> Hello! I see a problem in nested Mir mode with autopilot input (both host and nested Mir see input, but don't act on it). I've got some time to investigate on my own now and I was wondering if anyone had any pointers to likely culprits? <kgunn> alf_: racarr ^ see post from mterry <alf_> kdub: http://paste.ubuntu.com/6365435/ <alf_> mterry: I don't if it's relevant in your scenario: if there isn't a focused window, input gets dropped <alf_> +know <mterry> alf_, this seems to be a difference between running nested and not. Like I'm running the same autopilot test in each case, so it's probably not a focus issue <alf_> mterry: is there a manual way to reproduce this, or does it happen with autopilot only? <alf_> kdub: also as a second test: http://paste.ubuntu.com/6365552/ i.e. check that the device can display buffers that are also marked as texture-capable <kdub> alf_, i'm not as worried about the 'second test' <alf_> kdub: fair enough :) <mterry> alf_, looks like I got disconnected. <mterry> mterry> alf_, I've only seen it with autopilot <alf_> mterry: can you track where the input event messages stop? <alf_> mterry: I mean in which component in mir or unity8 <mterry> alf_, that's my next step, yeah. But it's affecting both unity8 and apps, so it's probably not unity8-specific <mhall119> so I've been running Mir on my x220 laptop for about a week now, and so far so good, but has anybody had an issue where the screen flickers sometimes when Chromium is reloading a page? I've only seen it do this on G+, and not all the time <mhall119> w 80 <mhall119> ah, still flickering in r10 on the Nexus 7 :( <davmor2> mhall119: you don't know what flickering is till you install a unity3d app :) <mhall119> also, on both my phone and my laptop, if the screen turns off and I turn it back on (power button on the phone, mouse movemenet on the laptop) I see what was displayed before it shut off for a split second before it goes to the lock/welcome screen <mhall119> is that a known bug or should I file it? <mhall119> kgunn: ^^ ? <racarr> mhall119: I think its 'known' but im not aware of a bug filed <kgunn> time flies...eating a very late lunch <kgunn> and back <ogra_> lunch flies too then :) <kgunn> racarr: you still working on the mir on mir (or is it side by side) mir bugs ? <racarr> kgunn: Yes I'm tryingto findwhy input is failing under autopilot now <kgunn> racarr: that's cool....was just wondering <kgunn> thinking....i'd like to satisfy thomi 's request for fb grabbing and input coordinates (probed) from AP <kgunn> racarr: but that change would likely be a shell change maybe ?...e.g. i don't think AP would talk direct to mir <kgunn> thomi: ^ or do you even care what you talk to ? <kgunn> you = AP in this case :) <kgunn> btw, i watched Pi... <kgunn> i want those minutes of my life back :) <thomi> kgunn: haha <thomi> kgunn: AP doesn't really care who we talk to. I guess the important thing is that it's relatively easy to communicate from python, and that there's not a huge delay involved <thomi> but dbus would be fine I think <racarr> kgunn: Seems kind of like dbus to the shellyeah <kgunn> thomi: i also watched scanner darkly way better <thomi> yeah, that's a good movie <kgunn> racarr: kdub ....any volunteers to review and approve ? https://code.launchpad.net/~mir-team/mir/development-branch/+merge/194018 <kgunn> our branch is getting stale <kdub> i can review <kgunn> kdub: ta <kdub> kgunn, why do we go from so.9 to so.10? <kdub> sorry, to so.11 <kgunn> kdub: yeah i noticed that as well....i think alan subsequently broke again...so he bumped again <kgunn> kdub: related to my statement about didrocks wanting per comit survivability <kgunn> kdub: it doesn't hurt anything...but its odd <kdub> kgunn, well, i approved <RAOF> tvoss_: Somewhat belated bong. <RAOF> Or even pong. <kgunn> RAOF: just fyi....i have every intention of showing up at the 1am <kgunn> bailing for dinner now... #ubuntu-mir 2013-11-06 <RAOF> racarr: ^^^ Looks like kgunn would like the meeting to be on this week :) <racarr> Oi <RAOF> racarr: Oh, by the way - do we have an input driver model? <RAOF> My vague understanding of our current input stack is that it expects to open an evdev device and go to town. <RAOF> I ask this for the reasonably transparent reason that I'll soon be wanting to fold a touchpad driver into the mix. <racarr> RAOF: Yes basically open an evdev device and go to town <racarr> actually though all that is constrained to EventHub which emits droidinput33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abRawEvents <racarr> and you could call that the driver <RAOF> So I get to implement an input driver API. Huzzah! <racarr> but its hardly a driver model <racarr> RAOF: Living the dream ;) <duflu_> Ping kgunn <RAOF> duflu: Maybe you can talk with him at the meeting this afternoon? :) <duflu> RAOF: That one that no one has come to for a month and I think we informally canceled? <RAOF> Yeah, that one. <RAOF> kgunn was on earlier mentioning that he was going to show up this time. <duflu> Awesome. If only anyone replied to my email about canceling it... or turned up <duflu> RAOF: Am I in the right hangout? I uninstalled my calendar plugin today so am guessing <RAOF> Gah. Why hasn't the email with the hangout link come in yet? <duflu> RAOF: No. I suspect kgunn canceled it after my email :) <RAOF> Still only static? <kgunn> RAOF: duflu i'm here...but meeting is in 1 hr i think <kgunn> we had daylight savings last weekend...bet that's the prob <duflu> kgunn: Oh. It's on your timezone? <duflu> kgunn: RAOF and I are in, and we don't expect anyone else <kgunn> hmmm....lemme check <kgunn> yeah...i'm showing 1 hr from now <kgunn> and alexandros is good about showing right ? <duflu> kgunn: We kind of agreed to cancel it after alf and I were the only attendees for several weeks :) <kgunn> yeah... <kgunn> we need to come up with a decent time <kgunn> i sort of feel like we should maybe have like 3 rotating spots or something <RAOF> Maybe. <duflu> kgunn: If you want to chat at all today, we're "all" in the hangout now :) <kgunn> ok <racarr> wait are wedoing it now? <tvoss_> good morning <mlankhorst> g'day <duflu> mlankhorst: hallo <mlankhorst> alf_: hey, did you ever end up merging the mesa / mir changes back? :P <alf_> mlankhorst: are you referring to the EGLImage changes? <mlankhorst> yeah <alf_> mlankhorst: yes, they are in RAOF's github repo <mlankhorst> ok what about the mir changes? <alf_> mlankhorst: I don't remember exactly what additional changes were needed on the Mir side, but nested mir works now with lp:mir (or at least it worked last I checked) <mlankhorst> ah k * alan_g smells a missing test case <mlankhorst> hehehe, 'git merge ubuntu' on raof's branch then commenting out the mir patch in debian/patches/series works :P <mlankhorst> alf_: but what about my fixes ? I disabled vt switching in the nested case <alf_> mlankhorst: hmm, I am not sure... do you have a link to your changes/branch? <mlankhorst> http://paste.debian.net/64293/ <alf_> mlankhorst: instead of passing a nullptr it would preferable to pass a NullObject, in this case a NullVirtualTerminal. There is an implementation of that in include/test/mir_test_doubles/null_virtual_terminal.h, so we just move that to src/server/graphics/gbm and use it (and also change the tests to use that too) <mlankhorst> :/ <mlankhorst> hm lets see.. <mlankhorst> alf_: http://paste.debian.net/64300/ -- enjoy? <alf_> mlankhorst: Looks good, thanks (only some nits). I will shepherd it into trunk if you want. <mlankhorst> please :) <alf_> mlankhorst: ok <mlankhorst> seems acceptance-tests.ServerShutdown/OnSignal and ServerShutdown.server_removes_endpoint_on_abort hang? <alf_> mlankhorst: Is it a consistently reproducible? I remember there was a bug about something similar, but I think it was resolved. <mlankhorst> sort of, it happens in my chroot <alf_> mlankhorst: hmm, I get a consistent failure (not a hang) in ServerShutdown/OnSignal.removes_endpoint_on_signal/2 <alf_> mlankhorst: ...but only if I run the tests manually. If I use ctest everthing works. <mlankhorst> oh seems to be random here <mlankhorst> some other tests can fail too <mlankhorst> heh maybe my system is too fast :P <mlankhorst> C++ exception with description "Failed to find server" thrown in the test body. <mlankhorst> /home/mlankhorst/nfs/xorg/mir/tests/mir_test_framework/testing_process_manager.cpp:240: Failure <mlankhorst> Value of: server_process_was_started <mlankhorst> Actual: false <mlankhorst> Expected: true <alf_> mlankhorst: btw, are you using the latest development-branch? <mlankhorst> not sure, last commit i have is from nov 3 :P <mlankhorst> Restore: mir (0.1.0+14.04.20131030-0ubuntu1) trusty; urgency=low <mlankhorst> hm nov5 <alf_> mlankhorst: ok <alf_> mlankhorst: actually, the patch may not be needed after all... we create a different kind of platform when nested ("native platform") which doesn't use the VT at all <alf_> mlankhorst: did you actually have a problem with the current state of the code? <dandrader> greyback, ping <greyback> dandrader: pong <dandrader> greyback, working on the mir-with-qtscenegraph prototype? <greyback> dandrader: yep <dandrader> greyback, let me know when you're something I could use to start experimenting with the input part of it <dandrader> greyback, or if you need help with it <dandrader> s/you're/you've <mlankhorst> alf_: oh is that different? :P <mlankhorst> i think it used to be needed <mlankhorst> my bad then <greyback> dandrader: thanks, I'll remember that :) I've a good day or 2 of hacking to get the basics going, but then I'll ping you <Prf_Jakob> alf_: hey <alf_> alf_: hi! <alf_> Prf_Jakob: hi! <Prf_Jakob> I'm thinking a bit longer term here, but would you guys be okay with using egl to accessing buffers? <Prf_Jakob> I'm thinking of trowing together a extension for shadowfb type blitting to images. <Prf_Jakob> (disclaimer: I'm on the EGL WG at Khronos). <alf_> Prf_Jakob: Do you mean for the client to access buffers, or for the server to access buffers? <Prf_Jakob> It can be done in multiple ways, but one way would be that the server creates hardware image, you prime/dma-buf it over to the client (can be hidden in the toolkit) and then create a shadow on the client side which it uses for fast access. <Prf_Jakob> Alternativly you could prime over the shadow image. <Prf_Jakob> Both would require you to still load the hardware driver (in our case our mesa dri driver) in the client. <alf_> Prf_Jakob: I think it would be a useful extension that will cover some of the direct pixel access use cases, although there would still be apps/toolkits that for whatever reason don't want to do amy08@example.org. <alf_> tvoss_: ^^ Was there a specific driving case for "software" buffers? <Prf_Jakob> alf_: yet they are okay with gbm :/ <tvoss_> alf_, plymouth was the original one, yeah <alf_> Prf_Jakob: that's a good point <Prf_Jakob> I mean at that point you have already pulled in the dri driver and all the gl bits into the process VM anyways. <alf_> Prf_Jakob: Actually, a pure "software" client, doesn't load gbm. It currently only uses DRM to map dumb buffers. <Prf_Jakob> Ah <Prf_Jakob> Not to comfirtable putting that much of acceleration API in the kernel. <alf_> Prf_Jakob: :) <Prf_Jakob> Trying to eat the gpu cake and keeping the not using gpu API cake. <kgunn> goin' to work out <racarr> finally making some good progress on my persistent goal of <racarr> improving theinput acceptance testing framework... <racarr> hopefully should be able to make an MP with a net line of codeloss :) <RAOF> Huzzah! #ubuntu-mir 2013-11-07 <mterry> Heyo! Does anyone know what drives the creation of the autopilot-finger device in Mir when running under autopilot? It's not being created correctly in the nested case <thomi> mterry: I probably do <thomi> mterry: but I'm not sure I understand the questino :) * mterry jumps on thomi and doesn't let go <thomi> *question, even <mterry> thomi, I'm looking at running unity8 in 'nested mode' which is where there is a system Mir and a user Mir <mterry> thomi, input works fine normally <mterry> thomi, but when under autopilot, the Mir autopilot-finger device gets created as an external pointer, instead of an internal touchscreen, as it should <thomi> so, when you say "external pointer, instead of an internal touchscreen", is the problem that it shows up as a mouse device, and not a touch device? <thomi> or the "external" vs "internal" bit? <mterry> thomi, I believe the problem is that it's a pointer, not a touchscreen. Because the symptom I'm seeing is that drags don't happen. And movement with a pointer probably isn't translated into a drag without a button down <thomi> hmm, so autopilot only supports multi-touch under mir. In order for it to create a mouse device it needs xlib bindings <mterry> thomi, well, I suppose those are installed. But I'm not sure why it would decide to do that? <thomi> it wouldn't, unless the test case asked it to <thomi> I suspect the problem is elsewhere <mterry> thomi, I'm running the same test case just with different Mir config <thomi> do you have a test log from the failure? <mterry> thomi, yeah :-/ <mterry> thomi, yeah I've got a log, but with quite a bit of me-specific Mir debugging printfs in it <mterry> thomi, I'm guessing this is a Mir bug, not an autopilot one <thomi> so in the AP log, if you see '_uinput' lines, you're using uinput, which means multitouch <mterry> thomi, well, it makes two devices, one is "py-evdev-uinput" and one is "autopilot-finger", which I'm guessing means it's using uinput <thomi> mterry: right - the first is the keyboard device <thomi> the second is the multi-touch device <mterry> thomi, ah, ok <alan_g> alf_: any thoughts on https://code.launchpad.net/~robertcarr/mir/client-input-report/+merge/194028 (if not I'll just top-approve) <alf__> alan_g: sorry, network problems, I am ok with the MP <alan_g> alf__: nw <alan_g> alf__: I was just referring to the C++ standard and could not help noticing that the declaration style there is the one Daniel thinks is used by a few eccentrics. <alf__> alan_g: Some people argue that all C++ users are eccentrics, and we should just go back to C ;) <alan_g> Some people are welcome to put that into practice (so long as they stop bothering me) <kgunn> Mirv: just a heads up...we're wanting to update our mir trunk & we have an abi break that needs coordinating, i'll ping you on monday as i understand you guys are struggling to get back to green <racarr> Morning <alan_g> kdub: any guess what bug 1249019 might be? <ubot5> bug 1249019 in Mir "Test failure: AndroidGPUDisplay.hwc_display_ok_with_gles" [Undecided,New] https://launchpad.net/bugs/1249019 <kdub> alan_g, perhaps unity8 is running? <kdub> let me try <racarr> alan_g: Try running <alan_g> kdub: Nope - it fails the first iteration then <racarr> powerd-cli active <racarr> and backgroundingit <kdub> yes, could be that too <racarr> powerd can put the screen in to a suspsned state that mir cant remove attimes <alan_g> This is a pass once fail second time scenario <alan_g> racarr: "powerd-cli active" says "Press ctrl-c to exit." <racarr> alan_g: Yes you background it <racarr> the functionisas long as it is alive <racarr> it keeps powerd in the active state <racarr> weird interface <alan_g> racarr: still get a SIGABRT on the second test cycle <racarr> alan_g: :* <racarr> :(* <racarr> not aware of it then <alan_g> racarr: I'm guessing it is a teardown problem - If I repeatedly run the test executable it doesn't show a problem <racarr> ah <racarr> I love writing the literal for a null function "[](){}" lol <kdub> racarr, hah, yeah <kdub> ({[](){},[](){}}) <kdub> initializer list of null functions <racarr> kdub: Code is poetry ;) <racarr> poetry is just getting reallymodern <racarr> lol <sarnold> lol <RAOF> Whee! Alarm clock malfunction - ZoÃ« didn't wake up until almost 9 this morning. <RAOF> In her defence, she woke up quite a lot during the night :/ <olli_> RAOF, and what exactly are you giving her? can i get this in the US or can you send some over? <kgunn> kdub: hey...so the 4 integration tests we were chatting about earlier...if i do apt-get install mir-test-tools will that pull those in ? or do i have to build them ?....i guess i should just ask...how to build and run the 4 tests :) ? <kgunn> kdub: just a matter of curiosity...i noticed the cmakelist.txt for test_client_render has a if( MIR_PLATFORM STREQUAL "android") <kgunn> but the others (buffer, display, internal_client) don't.... <kgunn> even tho they're under graphics/android... <kdub> kgunn, that directory is disabled <kgunn> kdub: disabled in a sense, those don't become part of mir-test-tools ? <kgunn> brb...picking up man-child <kdub> kgunn, http://bazaar.launchpad.net/~mir-team/mir/trusty/view/head:/tests/integration-tests/CMakeLists.txt#L21 <kdub> all of them are compiled on android, but not gbm <kgunn> ah <kdub> not really sure what goes in that package, have to check <kgunn> ok...wife going now... <kgunn> so what package do those tests go into is the better question kdub <kgunn> ? <kdub> kgunn, i'll send an email <kgunn> kdub: thanks dude! <racarr> Oh yeah deleting <racarr> morecode :D <kdub> racarr, i'm having that experience too over in the android code world <kdub> 'whoohoo, less code!' <kgunn> that's good to hear <racarr> kgunn: It should all be gone by january at the latest #ubuntu-mir 2013-11-08 <kgunn> racarr: lol...like all the code...? <Mirv> kgunn: ok, and yes still trying to get all apps green <RAOF> Really? EventHub uses inotify to watch /dev/input to do hotplug? :( <tvoss> RAOF, we have a bug open to adjust that admittedly wrong behavior :) <RAOF> The EventHub is a big ball of spaghetti, isn't it. <tvoss> RAOF, it is, we need to split it up a little :) we haven't done so far to avoid too big of an investment <tvoss> RAOF, however, as we prepare for the scenegraph changes, we will tackle the EventHub/InputReader, too <tvoss> RAOF, if you want to see convoluted, special-cased code, look at InputDispatcher ;) <tvoss> that's real fun <RAOF> I'm less interested in that, because dispatching happens after libtouchpad :) <RAOF> Wheras EventHub is all up in libtouchpad's business. <tvoss> libtouchpad? <RAOF> https://github.com/whot/libtouchpad <RAOF> AKA: make touchpads not horrible. <tvoss> RAOF, hmmm, interesting, will have a look <RAOF> Not much there yet, but I plan to help Peter migrate the various bits of functionality from xf86-input-synaptics. <RAOF> But 8:30 says âtime to stop workâ :) <duflu> RAOF: Yes there's a problem if I reach my EOD before you :) <alan_g> greyback: would you check another tweak to unity-mir for me? https://code.launchpad.net/~alan-griffiths/unity-mir/make-portable-across-Mir-versions/+merge/194479 <alan_g> greyback: (repeat in case you missed it) would you check another tweak to unity-mir for me? https://code.launchpad.net/~alan-griffiths/unity-mir/make-portable-across-Mir-versions/+merge/194479 <greyback> alan_g: I missed the first ping. Yes I'll look now <alan_g> greyback: thanks <greyback> alan_g: approved, thanks <alan_g> greyback: ta <greyback> alf__: question for you: when a display is connected or removed, how is a new CompositingFunctor created/destroyed? Is it that the MultiThreadedCompositor is stopped and then started? <greyback> And then a second more general question: how is vsync respected? I don't see what blocks after a frame is ready, until vsync is done <alf__> greyback: 1. Yes, the MultiThreadedCompositor is currently torn down and set up from scratch <greyback> ok <alf__> greyback: 2. the blocking happens in DisplayBuffer33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abpost_update(), which is currently called internally by the DisplayBufferCompositor since it needs to call the right overload (with or without bypass) <greyback> alf__: got it. Thanks! <alf__> greyback: yw <kgunn> robotfuel: hey...i'm probably gonna miss the standup (have an external call)...did you happen to file a ci feature bug for adding our demo clients ? <kgunn> i know we spoke a few days ago...just following up <robotfuel> kgunn: yes, I already have a test runner for it as well that will pass or fail a demo after running x number of seconds depending on return code or stderr <kgunn> robotfuel: cool...is it strictly binary for running or not ? or does it look at the performance as its pass/fail ? <kgunn> robotfuel: just thinking if we could look at the fps # it would help prevent things like this...https://bugs.launchpad.net/mir/+bug/1249210 <ubot5> Ubuntu bug 1249210 in Mir "Mir client frame rate regression in r1196" [Critical,Triaged] <robotfuel> kgunn: we will add performance eventually as it's printed on tests in standard out, but we need to get data, before we can pass fail based on it. <kgunn> robotfuel: cool....glad to know you're on it <kgunn> appreciate it <kgunn> kdub: so i thot i'd be clever and try to build mir on the device to test the integration tests <kgunn> sounds like a yo dawg meme <kgunn> kdub: so all was going ok until i got to cmake .. <kgunn> kdub: then it complains about the boost libs <kgunn> kdub: i was now going to try to install them...but just wondering why that's not taken care of through all the install steps (devscripts, build-essential etc) <kdub> kgunn, i think there is a tool in devscripts for that... i usually use pbuilder-satisfydepends though <kdub> dpkg-genbuilddeps <kgunn> kdub: hmmm...i'm doing apt-get install libboost-dev-all <kdub> that should work too <kgunn> yeah...more than 1 way to skin a cat <kgunn> kdub: just to make sure (while i wait on the world to download)...if i simply say "YES" in the rules file for integration test, they should run as part of the build correct? <kdub> i believe so, but its not something i've tried recently <greyback> Hey, am I reading this wrong: http://bazaar.launchpad.net/~mir-team/mir/trusty/view/head:/include/platform/mir/graphics/display.h <- does create_gl_context() create a GL context which spans all physical displays? <kdub> greyback, i think thats how it works <greyback> kdub: hmm , I was expecting a gl context per framebuffer <kdub> alf__, would object if i'm wrong though :) <kgunn> greyback: fwiw, i've actually seen both...context per & 1 for many <greyback> kgunn: ok. I know both do-able, but I thought i heard someone mention Mir did context per fb. Was just checking <greyback> think 1 context per many makes my life easier <kgunn> still a good question...maybe alf__ will enlighten us <kgunn> i really really heart verizon and their damn wifi route today :-| <alf__> greyback: Each DisplayBuffer gets its own GL context. However, all contexts, including the ones returned by create_gl_context(), are created sharing a common base share context, so they can all access shared resources (like textures). <greyback> alf__: ah cool <greyback> I didn't know that could be done <alf__> greyback: for a caveat about multithreading with shared contexts see the comment in src/server/compositor/gl_renderer_factory.cpp <greyback> alf__: understood * greyback eod <racarr> Had a full system hang from mir_demo_server_shell :( <doneill_> sam113101: we should've been talking Mir over here, hah! <sam113101> doneill_: yeah <sam113101> doneill_: do you work on mir? <doneill_> Anyway, I suspect you'll bump into Unity-isms in Mir when you start implementing. I'd suggest poking around the Unity8 code and borrow gfx/input initialization from there. <doneill_> No, I work on Ubuntu Touch apps, but at this stage it requires being at least moderately familiar with Mir and how it works. <sam113101> ok <doneill_> I'm not in a very different position than you, except instead of weighing the options I'm using both Mir and Wayland. <robotfuel> racarr: ping <racarr> robotfuel: pong <robotfuel> racarr: I asked the question in #mir <robotfuel> racarr: :D <racarr> I see <racarr> I dontknow about the bug but I have seen it before(just haven't investigate yet) <racarr> I will check it out once I finish 1249210 <racarr> I basically understand what is happeningwith 1249210 and have the fix butI dont quite understand <racarr> why it results in halfFPS when bypassed <racarr> robotfuel: Investigating now as soon as I get a clean build dir:) <kgunn> updatin' to trusty.... #ubuntu-mir 2013-11-11 <duflu> RAOF: What's the preferred place for Mir-Mesa changes? SRU-style patches to archive? Or are we still using git somewhere? <duflu> alf_ ^ ? <alf_> duflu: I usually create pull requests for https://github.com/RAOF/mesa (egl-platform-mir branch, which is the default) <alan_g> duflu: re recent regression. I was wondering if changing advance_client_buffer() to swap_buffer(BufferHandle&) so that the handle could be released in the implementation before calling flag_for_render() would make the code clearer. (BufferHandle& would be a single-owner, move-only type, not the shared_ptr we have now - that too is an accident waiting to happen). What do you think? <alan_g> alf_: have you headspace to review https://code.launchpad.net/~alan-griffiths/mir/fix-Surface-hierarchy-break-render_surfaces-dependency-on-BasicSurface/+merge/194551 <alf_> alan_g: sure <alan_g> greyback: I'd like to get rid
{'channel': 'ubuntu-mir', 'month': 11}