#ubuntu-mir 2013-04-29
<mlankhorst> RAOF: I was hitting a failure mode on a hybrid system, I don't know yet what exactly it was but it had something to do with being hybrid
<mlankhorst> also seems like mir lacks support for backlight and dpms off :P
<robert_ancell> thomi, can you disable all the quantal CI/autolanding for packages in the Mir staging PPA? We only support raring now
<robert_ancell> thomi, also, any update on the lightdm autolanding?
<thomi> robert_ancell: re: quantal, sure thing.
<thomi> robert_ancell: re lightdm... you don't mean lightdm, do you?
<robert_ancell> thomi, I mean autolanding from lp:~mir-team/lightdm/unity into the staging PPA
<robert_ancell> (or is that just a side-effect of CI?)
<thomi> robert_ancell: ahh, gotchya, let me check where that is at
<JoseeAntonioR> hey guys, anyone around who can help me with a Mir problem?
<robert_ancell> thomi, I'll do a manual upload if it's going to take time - but point me to the packaging branch
<thomi> sure, one sec
<robert_ancell> JoseeAntonioR, depends on what the problem is!
<JoseeAntonioR> :)
<JoseeAntonioR> so, basically, I manually start mir and its dependencies (by adding the package to the ppa and apt-get), I create the file, and then  go to the VT1
<JoseeAntonioR> execute the command to run Mir natively, and I get a black screen, even after a minute or so
<robert_ancell> JoseeAntonioR, yeah, it doesn't display anything by default. So black screen is correct
<JoseeAntonioR> oh
<robert_ancell> RAOF_, ^ see, we do need mir --retro!
<thomi> robert_ancell: just to confirm, the source branch should be lp:~mir-team/lightdm/unity, and not lp:~mir-team/lightdm/mir  (which is what is currently configured)
<robert_ancell> thomi, yes, I renamed it
<thomi> robert_ancell: ok, will be one very soon, just gotta re-deploy
<robert_ancell> thomi, ta
<JoseeAntonioR> well, but there's something else, it uninstalled the ubuntu-desktop package when doing apt-get dist-upgrade
<robert_ancell> JoseeAntonioR, you can run demo_client to see something
<JoseeAntonioR> robert_ancell: how should I?
<robert_ancell> JoseeAntonioR, try reinstalling ubuntu-desktop and see what new packages it needs to pull in
<robert_ancell> JoseeAntonioR, just run it from another VT
<robert_ancell> and then switch back
<JoseeAntonioR> already reinstalled ubuntu-desktop as it didn't want to boot, and had to go into restore mode to reinstall
<JoseeAntonioR> want the package list?
<robert_ancell> JoseeAntonioR, nah, sounds like something else went wrong - be sure to check what packages are being removed when running dist-upgrade!
<JoseeAntonioR> yeah, will do next time, just give me a sec to test mir again
<thomi> robert_ancell: FYI: https://code.launchpad.net/~thomir/cupstream2distro-config/lightdm-tweaks/+merge/161519
<thomi> we're reviewing & deploying now
<thomi> robert_ancell: lightdm daily-builds go into a separate PPA (lightdm-team/daily) - do you still want precise & quantal support for that?
<robert_ancell> thomi, yes
<robert_ancell> thomi, still being reviewed?
<thomi> robert_ancell: sorry - got distracted - just doing it now :-/
<thomi> robert_ancell: being deployed as we speak
<robert_ancell> thomi, huh, the MP still says needs review
<thomi> robert_ancell: hit F5
<robert_ancell> bing!
<thomi> ok, so we gotta wait for it to merge
<thomi> Francis says "5 minutes"
<robert_ancell> thomi, will lightdm build or do I need to make a commit to prompt it?
<thomi> robert_ancell: ok, the lightdm-mir config update has been deployed - the other changes will get deployed later (we need to wait for some existing jenkins jobs to complete)
<thomi> robert_ancell: and it should pick up the MPs automatically
<thomi> robert_ancell: if you have a specific MP that you care about, link me and I can monitor it
<robert_ancell> thomi, no specific MP, I just want it to put a package into the PPA
#ubuntu-mir 2013-04-30
<robert_ancell> thomi, still no sign of a package in the PPA...
<thomi> robert_ancell: ok, I think we need a MP with a whitespace change.
<thomi> it needs something to process. Shall I make something?
<robert_ancell> thomi, I just pushed a change
<thomi> robert_ancell: where to?
<robert_ancell> thomi, oh, did that need to be a MP?
<robert_ancell> I just pushed directly
<thomi> ok
<robert_ancell> thomi, https://code.launchpad.net/~robert-ancell/lightdm/unity-whitespace/+merge/161536
<thomi> hmmmmm
<thomi> robert_ancell: something really odd is happening with the jenkins infrastructure at the moment. TBH, if you want a package in the PPA soon you may be better off dput'ing it manually, since Francis is in a meeting now
<robert_ancell> thomi, ok will do
<thomi> I'll try and see what the issue is, though
<thomi> sorry aboyut that :(
<robert_ancell> np
<robert_ancell> thomi, no change on the lightdm PPA build? I'm going to upload it now
<thomi> robert_ancell: do you have the link to that MP handy?
<thomi> robert_ancell: seems to be working: https://code.launchpad.net/~robert-ancell/lightdm/unity-whitespace/+merge/161536
<thomi> robert_ancell: approve that and it should merge
<thomi> oh wait
<thomi> it merged already
<robert_ancell> thomi, yeah, it merged but it hasn't uploaded a new package to the PPA
<thomi> hmmm
<robert_ancell> thomi, also a mir quantal package got built, but I think you said those changes were delayed right?
<thomi> robert_ancell: I just reminded Francis to deploy the rest of the config, he's doing it now
<thomi> just looking in to why the package didn't get uploaded to the PPA
<thomi> robert_ancell: remind me: which PPA should that branch have landed in?
<robert_ancell> thomi, https://launchpad.net/~mir-team/+archive/staging
<thomi> hmm, well I got that right, at least
<thomi> robert_ancell: we're getting some errors from bzr bd
<thomi> which is preventing the package from being dput'd
<robert_ancell> thomi, what is the packaging branch?
<thomi> robert_ancell: lp:~lightdm-team/lightdm/mir-packaging
<thomi> robert_ancell: we're trying a few things now
<robert_ancell> thomi, I'll pull the packaging into lp:~mir-team/lightdm/unity
<thomi> robert_ancell: ok, let me know when the MP to do that is up, because we'll need to change the config
<thomi> otherwise you'll get merge conflicts
<thomi> not that that's a problem though
<robert_ancell> thomi, ok, I added the packaging to  lp:~mir-team/lightdm/unity
<thomi> robert_ancell: ok, in a meeting at the moment, but I'll update the autolanding after lunch
<robert_ancell> hmm, merge conflict
<robert_ancell> will be there *soon*
<robert_ancell> thomi, packaging in lp:~mir-team/lightdm/unity, but still no lightdm 1.7.0bzrXXXX in the PPA - anything to do?
<thomi> robert_ancell: we updated the config, let me ping francis and see where he's at.
<thomi> robert_ancell: it might be easier if you join #ps-qa on the canonical IRC server so you're part of the conversation
<redtape> Hello peoples of mir-land ..
<redtape> QUESTION: Will the ubuntu mir project code have an MIT license or GPL v3.0 ?
<redtape> I understand that this will take some time to get a response as there is only 50 ppl in the room , but I will go to bed and dream of your answers .. & have a look in the morning.
#ubuntu-mir 2013-05-01
<alan_g> redtape: Mir is a mix of GPL and LGPL (the latter for the client side).
<redtape> ok thank-you.  I take it that is GPL 3.0 ?
<alan_g> redtape: correct
<thomi> anyone seen alf this morning?
<bcbc2> mir has unmet dependencies: depends on libmirserver0 (=0.0.2bzr643raring0) but the version of libmirserver0 is 0.0.2bzr644raring in the ppa
<thomi> I just found the same thing :-/
<bcbc2> I mean:  0.0.2bzr644raring0
<thomi> alf__: ping?
<alf__> thomi: pong
<thomi> alf__: I wonder if you could take a look at this? https://code.launchpad.net/~thomir/glmark2/fix-for-new-mir-client-api/+merge/161875
<thomi> it fixes glmark2 to use the new surface creation function in the mir client API
<thomi> then we can have pretty graphs again :)
<thomi> hmm, empty diff - WTF?
<thomi> alf__: did you already fix that?
<alf__> thomi: I pushed a fix to lp:~mir-team/glmark2/mir some time ago (this morning)
<thomi> alf__: haha, ok
<thomi> alf__: thanks - any idea what the packaging issue is in the ppa?
<alf__> thomi: for glmark2 or for mir?
<thomi> alf__: for mir
<thomi>  mir : Depends: libmirserver0 (= 0.0.2bzr643raring0) but it is not going to be installed
<alf__> thomi: no, I will try to find Robert, but he is not around right now
<thomi> ok, thansk
<robert_ancell> thomi, hmm, odd quantal build failures for lightdm?! https://jenkins.qa.ubuntu.com/job/lightdm-quantal-amd64-ci/8/console
<robert_ancell> Might just be easiest to drop quantal support
 * thomi looks
<bschaefer> duflu, heres the bug if you want to change it to a better description: https://bugs.launchpad.net/mir/+bug/1175267
<ubot5> Launchpad bug 1175267 in Mir "Mir EGL Apps fail to shutdown." [Undecided,New]
<duflu> bschaefer: Thanks. so long as it's assigned to the Mir project I'd see it anyway
<bschaefer> duflu, o well cool :)
<bschaefer> duflu, it seems to hang while shutting down, soo it might be different then the egl failing to init problem I was seeing...
<bschaefer> but I can try to come up with a different test
<duflu> bschaefer: Maybe mention "init" somewhere. So people don't confuse it for existing "shutdown" bugs
<thomi> robert_ancell: ugh - I've seen this before - it's some odd autotools thing
<thomi> there's a variable that's being set to ''
<bschaefer> duflu, alright! And not hang, but after shutdown it stops running completely (which I don't see where in the code it should quit out)
<robert_ancell> thomi, unity-system-compositor not set up for CI yet? https://code.launchpad.net/~robert-ancell/unity-system-compositor/std-endl/+merge/161906
<thomi> robert_ancell: I'll check - the lightdm issue seems to be a missing build-depends
<thomi> we're just trying to figure out what it is
<thomi> robert_ancell: for lightdm, we're missing a build-depends on qtchooser in quantal. Probelm is, that would require us to add the qt PPA for quantal, but not precise. If you're OK, I suggest we disable quantal support for lightdm daily builds
<robert_ancell> thomi, yeah, ditch quantal
<robert_ancell> thomi, any eta for CI for unity-system-compositor?
<robert_ancell> RAOF, can you merge https://code.launchpad.net/~raof/mir/document-reality/+merge/161895 with trunk so I can merge my branch with it?
<RAOF> robert_ancell: Done.
<bschaefer> https://code.launchpad.net/~brandontschaefer/+junk/sdl-mir-support
<bschaefer> cmake .. -DVIDEO_OPENGL=OFF
#ubuntu-mir 2013-05-02
<hk> where's the XMir code hosted?
<mlankhorst> mirning
<mlankhorst> support mir as a backend for plymouth is INPROGRESS, is there anyone actively working on it? sounds like a fun little item for me to get started in mir
<mlankhorst> racarr_:         AC_DEFINE(XMIR, 1, [Support wayland mode])
<mlankhorst> er RAOF_*
<mlankhorst> ohey plymouth sort of works
<mlankhorst> Mesa 9.2.0 implementation error: unhandled format!
<mlankhorst> Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
<mlankhorst> http://testbot.winehq.org/~mlankhorst/plymouth-mir-wip-1.patch -- not complete yet, just a WIP
<robert_ancell> thomi, is there a way to recompile unity-system-compositor every time mir changes?
<robert_ancell> i.e. recompile the package in the PPA
<thomi> robert_ancell: hmmmmm - you want to rebuild because of API/ABI changes?
<robert_ancell> thomi, yes
<robert_ancell> thomi, we just set the mirserver API to always require recompiling as it doesn't have any API/ABI stability at the moment
<thomi> robert_ancell: I'll ask Francis, I don't think there's any easy way (although we could hack something up pretty easily).
<robert_ancell> thomi, ta
<thomi> robert_ancell: so the full story is that this is what the MBS is designed to solve (we use it for unity). It needs to be integrated with the new autolanding stuff
<thomi> robert_ancell: but we can hack a jenkins job to do that. However, there are a few edge cases to think about, like what to do when the dependant package fails to build
<thomi> so right now we'll just do the best we can - if anything fails to build it just won't get dput'd
<bschaefer> robert_ancell, https://launchpad.net/~brandontschaefer/+archive/sdl-mir-support
<RAOF> Dear GLX: I hate you.
<robert_ancell> RAOF: From GLX. I apologize if I have offended you but I'm old and I just don't understand what you crazy kids are doing
<mlankhorst> RAOF: oh btw could you peek at my plymouth mir wip patch?
<robert_ancell> bschaefer, you should probably use version 2.0.0-0ubuntu1~mir1 so it's less than the official 2.0.0 release
<robert_ancell> bschaefer, I mean 2.0.0-0ubuntu1+mir1
<mlankhorst> I only tested on the mir demo server with input explicitly disabled, I still use raw console handling for input for now
<robert_ancell> bschaefer, actually, disregard that. Now I understand
<RAOF> mlankhorst: Sure. Where is it?
<bschaefer> robert_ancell, alright, :)
<mlankhorst> above^
<mlankhorst> http://testbot.winehq.org/~mlankhorst/plymouth-mir-wip-1.patch
<mlankhorst> it doesn't work correctly yet since it assumes that last buffer == current buffer
<mlankhorst> so it doesn't do a full redraw, and mir_demo_server was complaining "Mesa 9.2.0 implementation error: unhandled format!"
<robert_ancell> thomi, can we get u-s-c to rebuild now? Or shall I just do a trivial merge?
<thomi> robert_ancell: sure, I'll trigger it manually
<RAOF> mlankhorst: Got a patch that isn't full of automake droppingsz/
<RAOF> ?
<mlankhorst> RAOF: no sorry :(, plugins/renders/mir and configure.ac is the meat
<robert_ancell> bschaefer, what branch are you working on libsdl?
<thomi> robert_ancell: running now - http://10.97.2.10:8080/view/Generic%20jobs/job/generic-dput/1189/console
<bschaefer> robert_ancell, I don't have the actual source pushed up but i moved over to using this version: http://hg.libsdl.org/SDL/
<robert_ancell> bschaefer, just a local checkout?
<bschaefer> yeah, I grabbed it changed it, made a patch, patched the libsdl2 from saucy then uploaded the ppa
<bschaefer> soo I suppose Im using the libsdl in the ppa from saucy
<bschaefer> robert_ancell, https://launchpad.net/ubuntu/saucy/+source/libsdl2
<RAOF> mlankhorst: Is plymouth wedded to VTs? Because that would ideally go away.
<mlankhorst> RAOF: no, I just didn't get around to fixing the input stack yet
<RAOF> mlankhorst: Also, I think you're calling mir_surface_next_buffer_sync in the wrong place - you should call it *after* doing your drawing.
<alan_g> robert_ancell: kdub is still testing android on https://code.launchpad.net/~afrantzis/mir/remove-in-tree-glm/+merge/162174
<RAOF> mlankhorst: We're thinking of renaming it as mir_surface_swap_buffers to make it more obvious âº
<mlankhorst> RAOF: Yeah I thought so, but the unaccelerated demo did it like that
<RAOF> mlankhorst: Hm, so it does. I'll fix that :)
<mlankhorst> this is just the work of me poking half a day at the mir demos and plymouth
<mlankhorst> how many buffers are there in the sw case?
<RAOF> 2
<RAOF> Well, or more.
<RAOF> But 2 by default.
<RAOF> And we don't currently expose any way to get anything but 2.
<mlankhorst> is there any guarantee? I was thinking of just keeping track of the damage to last buffer and merge it with damage to current buffer
<RAOF> You get buffer age :)
<mlankhorst> ok
<mlankhorst> I'll look at it monday then :)
<RAOF> I'm not sure if we'll guarantee that the number of buffers will never exceed n, for a client-sent value of n.
<mlankhorst> shrug buffer age is probably good enough
<mlankhorst> if it's > 1 I'll just redraw the entire screen
<RAOF> It'll always be > 1 (it'll almost always be 2).
<mlankhorst> ok ok, I'll poke it a bit more before I shout random stuff again ;P
<RAOF> Because the buffer you've just drawn to will have age = 1 right after you've called next_buffer (see the EGL_EXT_buffer_age spec for further details âº)
<thomi> robert_ancell: maybe you noticed already, but the u-s-c package is in the staging PPA now
#ubuntu-mir 2013-05-03
<Saviq> kdub, http://pastebin.ubuntu.com/5627701/
<Saviq> kdub_, http://pastebin.ubuntu.com/5627701/
<Saviq> kdub_, or http://pastebin.ubuntu.com/5627712/ for TouchArea instead of MouseArea
<kdub_> will try that one too
<kdub_> Saviq, the qpa plugin isn't working right just yet
<Saviq> kdub_, ok thanks
<robert_ancell> alf__, bug 1176083
<ubot5> bug 1176083 in glm (Ubuntu) "[MIR] glm" [Undecided,New] https://launchpad.net/bugs/1176083
<alf__> robert_ancell: thanks
<kdub_> ping thomi
<thomi> kdub_: hey
<thomi> what can I do for you
#ubuntu-mir 2014-04-28
<duflu> RAOF: I tried to make a little progress on Mir's support for i915 but the issue appears to be lower level any idea?  https://bugs.launchpad.net/mir/+bug/1275398
<ubot5> Launchpad bug 1275398 in Mir "i945: Mir GL clients are rendered as black or transparent windows when using i945 graphics" [High,Triaged]
<duflu> (i915 driver, i945 chip)
<RAOF> duflu: Do you know if it's black buffers, or transparent buffers?
<duflu> RAOF: Varies between clients :)
<duflu> Possibly varies between clients on RGBX/RGBA
<RAOF> Ah, so the buffers would just be uninitialised, then.
<RAOF> Almost.
<RAOF> I guess our buffer initialiser gets to them, but they never get _new_ content.
<RAOF> duflu: Does in-process rendering work?
<RAOF> In-process client, I mean.
<duflu> RAOF: I need to test more I guess but render_surfaces is perfect
<RAOF> duflu: mir_demo_standalone_inprocess_egl ?
<duflu> RAOF: I'll have to boot up the noise machine again
<duflu> afk
<xnox> * libmirclient7 [amd64 armhf i386]  (for libboost-system1.54.0)
<xnox> * libmirplatformgraphics-mesa [amd64 armhf i386]  (for libboost-program-options1.54.0)
<xnox> * libmirserver18 [amd64 armhf i386]  (for libboost-program-options1.54.0)
<xnox> * libmirserver18 [amd64 armhf i386]  (for libboost-system1.54.0)
<xnox> Above packages are the last few that are in main and use boost1.54 in utopic, is a daily release (even if no-change one) planned soon into the utopic archive?
<duflu> RAOF: inprocess_egl fails too -- black screen just the cursor
<xnox> or should i upload no change rebuild into utopic?
<RAOF> xnox: Feel free to no-change rebuild.
<xnox> RAOF: thanks.
<RAOF> xnox: We don't daily-release into utopic, thanks to our current embarrassing lack of ABI.
<duflu> New competition: Who can make Mir work on something older than this '06 Pentium D? :)
<duflu> Although I think we're most limited by DRI2/Mesa support :(
<xnox> RAOF: and are boost-templates known to leak to ABIs of things that build against lib*mir*-dev ? i don't think there are any abi/api changes to system&program-options, but still would be interesting to know.
<RAOF> xnox: It would not surprise me if boost templates leaked into the ABI (such as it is), but I'm not sure.
<xnox> RAOF: ok, thanks.
<RAOF> Hm. Actually, I'm pretty sure that boost::asio is a part of our current ABI.
<duflu> Really?
<xnox> RAOF: i wish boost had stable abi =(
<RAOF> duflu: Well, it's hard to say, isn't it. There's certainly a bunch of boost::asio in include/server/*.h, which is ostensibly public.
 * RAOF wonders what contortions boost would need to go through in order to ensure a stable ABI.
<xnox> RAOF: well, stdlib and stl manage it =) the piles of diff in asio alone from boost1.54 -> boost1.55 do not make me happy...
<xnox> RAOF: i think i'll wait until we have some images of utopic before rebuilding those and/or wait for a release to utopic.
<RAOF> xnox: That seems sensible; we've got a process that'll rebuild all our reverse-depends when that happens, anyway.
<xnox> RAOF: excellent!
<duflu> RAOF: If your hacking journeys have you retained any system that uses the i915 driver?
<duflu> -If +In
<RAOF> duflu: I've got an Atom netbook; I forget whether or not that uses i915_dri.so
<duflu> RAOF: Yeah it should
<duflu> Mine does
<duflu> As long as it predates PowerVR
<RAOF> It does :)
<duflu> RAOF: It's fun to try even if you just install trusty plus mir-demos. Suddenly the old system has super-smooth graphics and some new potential :)
<duflu> Although unity7 is also less of a hog in trusty than previous releases too. Somewhere in the last 12 months it's gone from 60 seconds opening the dash to almost instant. \o/
<duflu> RAOF: What is DRM_API_HANDLE_TYPE_SHARED?
<duflu> I can see some logic in Mesa's i915 changed for that type in the Mir patch
<RAOF> That would be for flink, IIRC.
<duflu> Oops, actually the change affects != DRM_API_HANDLE_TYPE_SHARED
<RAOF> Hm. It's entirely possible that I just haven't done the necessary hookup bit for i915?
<RAOF> At one point it was sharing files with i965, then that got split and they got copies of identical files that then diverged...
<duflu> +   if (whandle->type != DRM_API_HANDLE_TYPE_SHARED)
<duflu> +      return NULL;
<duflu> That's new. Did it ever work?
<RAOF> Oh!
<RAOF> You're looking at the wrong i915
<RAOF> :)
<duflu> RAOF: Looking at my Ubuntu Mesa source :)
<RAOF> That's the Gallium driver, which we don't use.
<RAOF> You want src/mesa/drivers/dri/i915.
<RAOF> Confusingly, there are two separate i915 drivers in the mesa source.
<duflu> I'm confused by most of the Mesa source so that's OK
<RAOF> Hm. Is there some way to add a target to each compiled target in cmake?
<duflu> RAOF: Umm, rephrase that?
<duflu> Add a dependency?
<duflu> RAOF: http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command:add_dependencies
<RAOF> duflu: Specifically, I want to grab a total list of sources (to run them through clang-check -analyze)
<anpok> RAOF: last time I did that by replacing the add_executable and add_library alls with homegrown macros that behave same
<RAOF> anpok: Yay? Ok, I'll stop trying to make a branch that'll automatically run the static analyser :/
<duflu> RAOF: cmake usually has an existing answer if you can wade through the docs
<anpok> back then I also wanted to acchieve something like virtual library target, since the project could be build all static libs or as shared libraries or static exectuables.. and avoid fpic where possible..
<duflu> anpok, RAOF: I hear GNU Make is still awesome
<duflu> Just that CMake dumbs it down too much, sometimes
<duflu> Whee, all the (review) things.
<duflu> alf_: I spent a while looking at the screencasting stuff on the weekend. What was the motivation for recompositing to screencast? is ReadPixels truly infeasible?
<duflu> I mean the whole thing relies on the assumption that it's faster to GL render twice than to render one and then glReadPixels... ?
<alan_g> alf_, anpok: are you OK with this? https://code.launchpad.net/~alan-griffiths/mir/purge-some-sessions/+merge/217252
<alf_> alan_g: looking
<alan_g> thanks
<kgunn> AlbertA: is this bug a dup really of the stale socket cleanup ?
<kgunn> https://bugs.launchpad.net/mir/+bug/1189770
<ubot5> Launchpad bug 1189770 in Mir "[DRM/GBM] Killing (or crashing) Mir often leaves the screen blank and difficult to recover" [Medium,Triaged]
<kgunn> kinda feels like it is
<alan_g> kgunn: no - that's about locking up the VT (e.g. input doesn't work)
<alf_> kgunn: alan_g: Have you seen that recently?
<alan_g> no
<AlbertA> kgunn: no that's different it still happens actually
<AlbertA> kgunn: alf: alan_g: I see that all the time when I kill (not sigkill) mir on my intel laptop
<AlbertA> well maybe not all the time
<AlbertA> actually I think when mir dies
<AlbertA> with an exception
<AlbertA> I usually get a blank screen that I can only switch out of with sudo chvt 7
<alan_g> AlbertA: is that a consequence of bug 1285084?
<ubot5> bug 1285084 in Mir "Exceptions are raised in a compositing thread and not handled" [Undecided,New] https://launchpad.net/bugs/1285084
<alan_g> Because exceptions in most threads are handled sanely
<AlbertA> alan_g: could be, I haven't investigated it
<alf_> AlbertA: kill => inadverently kill by doing something wrong that leads to exception?
<AlbertA> alan_g: the last time I saw it was when i investigated the power off display bug which was throwing an exception
<AlbertA> alf_: Sorry not by killing that works fine. I mis-remembered
<alf_> AlbertA: interesting, do you remember from which thread it was thrown from? We can force an exception there to reproduce consistently...
<alf_> AlbertA: s/from//
<AlbertA> alf_: Yeah it was the bug daniel fixed, so the DisplayConfiguration valid check
<alf_> AlbertA: thanks
<AlbertA> alf_: which was I suppose the demo shell responding to a power key event
<AlbertA> alf_ : whatever that thread is
<sil2100> kgunn: hi!
<sil2100> kgunn: so, we would need to re-assign your Mir silo for utopic, as it's currently still building stuff for trusty
<sil2100> kgunn: are you guys using the silo right now? Since my re-assignment will require a rebuild of all packages
<mterry> greyback, welcome back!  I'm sure you have a backlog of stuff, but when you have a few minutes, I wanted to pick your brain on lifecycle events & nested servers
<greyback> mterry: am happy to talk whenever you'd like
<mterry> greyback, OK.  So I have USC sending lifecycle events like will_suspend and resumed to the greeter (which is a glorified unity8 session -- nested mirserver etc).  It never seems to see them...  I went down the stack to platform-api on the greeter side, and it never seems to get the event
<sil2100> kgunn: tell me when you think I could do that
<mterry> greyback, does the nested server hide such events or not listen for them in the first place?
<kgunn> sil2100: hmmm....letme just grab the packages real quick and then you can have it, i'll ping you....
<sil2100> kgunn: ok, thanks!
<greyback> mterry: I don't know. I'm not aware of any reason why a nested server would hide those events or ignore them. Have you any sample code I could test with?
<kgunn> sil2100: ok, go for it
<sil2100> kgunn: thanks, doing o/
<kgunn> sil2100: yeah...we'll want to target utopic
<mterry> greyback, sorry, got distracted.  Sample code...   no just some local edits to my various split branches.  I could try to reproduce using mir demo code
<greyback> mterry: ok. well on idea is that platform-api only has lifecycle listenening code in its client library, not its server lib (lp:platform-api:src/ubuntu/mirclient)
<mterry> greyback, nested servers don't run both code?
<mterry> I figured they would be clients on one side and servers on the other
<greyback> mterry: I don't see how one process can use platform-api client & server simultaneously tho
<greyback> maybe they can, but I expected symbol collisions
<mterry> Yeah, I don't know how the code fits together.  I just assumed that a nested mirserver was re-using the client code somehow.  But if it isn't, that would explain some of what I'm seeing
<greyback> mterry: the nested server is a Mir server itself, it is run with QT_QPA_PLATFORM=ubuntumirserver right?
<mterry> greyback, right, which would pick up the side of platform-api without the listening it seems
<greyback> if so, then the platform-api server plugin is being used, and that doesn't have lifecycle event listening code build in
<greyback> indeed
<greyback> that's my best theory at the moment
<mterry> greyback, alright.   I'll test that out, thanks
<greyback> mterry: let me know if I can help more
<alf_> AlbertA: How do you support a buffer queue of one in the new implementation? Won't that lead to the compositor blocking?
<AlbertA> alf_: I add the only buffer to the free queue
<AlbertA> alf_: so then the compositor and clients end up sharing the same buffer
<AlbertA> alf_: all the time
<AlbertA> alf_: then after I added to the free queue at the very beginning the
<AlbertA> operations are all the same as in the other cases
<AlbertA> alf_: i.e. a client's next request (after release) will block until compositor composites that buffer
<alf_> AlbertA: but what if a buffer is held by the client when the compositor acquires it? It will just get it?
<AlbertA> alf_: yes because it wil fall under the "use current buffer" condition
<alf_> AlbertA: ok, I am not sure how well SwitchingBundle handles this scenario...
<AlbertA> alf_: hence why I wrote the unit test :)
<alf_> AlbertA: it's conceivable that it doesn't handle it well (since we don't have users of this use case)
<AlbertA> alf_: some of the unit tests in SwitchingBundle do exercise constructing a SwitchingBundle of 1 buffer
<AlbertA> alf_: but there wasn't any specifically testing the behavior of 1 buffer scenario.
<greyback> mterry: question for you: what launches unity-system-compositor? I can't see a system upstart job for it
<mterry> greyback, lightdm manages it
<greyback> mterry: ah ok
<alf_> AlbertA: I wonder if the logic around buffer_to_release in compositor_acquire() could be problematic for the single buffer scenario. For example, we pop() the buffer from the ready_to_composite_queue and set the current_compositor_buffer with it. Then we release() it and in give_buffer_to_client() we need to resize, so the buffer pointer in current_compositor_buffer is now invalid.
<AlbertA> alf_: yes you are right
<AlbertA> alf_: I need to add that to the unit test
<alf_> AlbertA: ahhh, the beautiful land of the component formerly known as SwitchingBundle :)
<alf_> AlbertA: at least in the new version we can *read* the code and *find* the problems
<AlbertA> alf_: :)
<AlbertA> alf_: it kinda mirrors government
<AlbertA> alf_: because it shows the danger of centralizing many things in one
<AlbertA> alf_: :)
<kdub> lol
<mterry> Mir folks -- why is there no version of mir_connection_set_lifecycle_event_callback for mirservers that are nested?  Surely nested servers want to hear about such events too.  I'll file a feature request bug unless ya'll tell me it doesn't make sense
<mterry> Hmm, the mirserver library links to mirclient.  Maybe I can use that API after all
<josharenson> Question: I have a thread that calls "run_mir" (which blocks). Is there a graceful way to stop mir?
<kdub> that function is more of a helper
<kdub> mir::DisplayServer has run() and stop()
<kdub> josharenson, ^^
<josharenson> kdub, ack
<kdub> mterry, don't know the specific problem, but if something in the mir client api is useful to the things the custom nested server is doing, then no reason not to use the client api
<kdub> and, if its a thing that should be universally done, then we should pull it into the nested code
<mterry> kdub, yeah...  but MirConnection isn't exposed to mirserver users.  You can get the HostConnection, but that class isn't defined externally
<mterry> kdub, I ended up filing bug 1313832
<ubot5> bug 1313832 in mir (Ubuntu) "[enhancement] Allow nested mirservers to listen for lifecycle events" [Undecided,New] https://launchpad.net/bugs/1313832
<josharenson> kdub, when I start the display server via display_server.run() and join the thread, the client application says it cannot connect to the display server... After looking at the example basic server, I can't figure out what I'm missing (client app runs under example server just fine)
<kdub> how do you join the thread if the display server is still running? o.O
<josharenson> I'm kicking off a thread that calls a function that calls run... joining my thread back to the main thread.... is the server supposed to block after calling run?
<kdub> iirc, it is running until stop()
<josharenson> so is the best way to call run_mir with the command to start the client as the lambda arg?
<josharenson> punctuation would have made that more clear... is the best way, to run a client without manually starting a server beforehand, ^^
<kdub> josharenson, it depends on what you're trying to do really
<josharenson> kdub, start mir server -> run glmark2 -> stop server
<kdub> run_mir is helpful code if you're starting an executable that you'd expect to respond to ctrl-c
<kdub> so with that, I'd come up with an executable that fires off the mir server, forks out the client, waits for the child to end
<kdub> then DisplayServer::stop()
<kdub> something like that
<kdub> i think the acceptance tests do something similar
<josharenson> kdub, ok thanks.. I just got something that _kind of_ works.. ill reference the acceptance tests
<kdub> josharenson, yw
<kdub> camako, have some time to chat about https://code.launchpad.net/~kdub/mir/overlay-gl-program/+merge/217153/comments/517227 ?
<camako> kdub, can I ping you in a bit?
<kdub> camako, sure, no rush
<camako> kdub, sorry that took a while
<kgunn> AlbertA: might give a look over this
<kgunn> https://blueprints.launchpad.net/ubuntu/+spec/client-1410-unity-ui-power
<kgunn> i just added a potential policy idea...
<AlbertA> kgunn: yes it's being discussed over e-mail, I have to change the mir tasks
<AlbertA> kgunn: as that changed a while back during previous IRC discussions
<kgunn> AlbertA: we need to land things faster i can tell :) before they change on irc
<AlbertA> kgunn: :)
<AlbertA> kgunn: well what I implemented is in sync with the IRC discussions
<kgunn> thats god news
<kgunn> or good news even
<AlbertA> kgunn: the missing parts so far
<AlbertA> kgunn: is long-press power button (new to me)
<kgunn> ah
<AlbertA> kgunn: and who will communicate the per session timer settings/backlight value preferences
<AlbertA> kgunn: to USC
<kgunn> AlbertA: so kinda feels like either usc reads them direct ?...or...relies on shell & we make in interface to keep it all agnostic...
<kgunn> but...u of u-s-c is unity...
<kgunn> so...
<kgunn> what are your thoughts
<AlbertA> kgunn: right...currently it's built in defaults, overridable through the command line
<AlbertA> kgunn: but we do need an interface, just don't know if DBus, or resuing the mir socket
<AlbertA> kgunn: depends on who will communicate the info
<AlbertA> kgunn: could be the lightdm socket as well...
<kgunn> mmm...right, it is per user session
<AlbertA> Saviq: ^
<AlbertA> probably too late
<kdub> camako, pong, np
<kgunn> AlbertA: actually...he doesn't sleep...i'm convince
<kgunn> d
<camako> kdub, I see your points and am updating my comments...
<kdub> camako, cool, thanks
 * kgunn loves that camako is going to help on sticky subjects
<camako> kdub, I 'm good... Just the naming bothers me a bit...
<kdub> yeah, I have to address some of daniel's naming comments too
<kdub> i think that overlay vs optimized-surface is a good distinction to make in the naming
<kdub> with overlay being the android concept
<camako> kdub, I like :-)
<kgunn> AlbertA: and would u-s-c really be involved for brightness/ALS ?
<AlbertA> kgunn: only as a proxy to powerd
<kgunn> ah
<kgunn> pass thrug
<AlbertA> kgunn: yeah
<kgunn> damn i can't type today
<camako> kdub, on second thought, they'd be "optimized" if hwc wouldn't reject them..
<camako> kdub, perhaps "fallback" or smth like that
<camako> kdub, but if nothing works, "optimized" is better than "overlay"
<camako> kdub, also this means that by falling back to gl, we are requiring gl capable gpu on the SoC.. should we worry about that?
<kdub> camako, i don't think so, we won't hit an opengles-less android device soon
<kdub> camako, 'optimized' was from the perspective of the DisplayBufferCompositor
<kdub> within the android platform, 'overlay' vs 'fallback' is a good distinction
<kdub> the pot o gold at the end of the rainbow for me is like... wobbly windows, and then when the animation stops, the hwc overlay stuff seamlessly kicks in
<camako> kdub, I'm not worried abt Android-capable devices.... But there are devices coming out with only a 2D gpu e.g... Those devices could replace GLRenderer... but now we *require* GL for the "overlays"
<kdub> well, we don't though, they can just give a stub gl program factory
<kdub> and then that would be another platform without gl
<kdub>  s/stub/null
<camako> kdub, how will they render overlays?
<kdub> well, thats for that platform to figure out, like say its the omap dss
<kdub> and there is made an explicit opengl-less platform for that... they can just reject the optimization function, or under the hood, they can do what they want
<kdub> like, I sent out this line on the ML
<kdub> http://bazaar.launchpad.net/~kdub/mir/future-default-display-buffer-compositor/view/head:/src/server/compositor/default_display_buffer_compositor.cpp#L49
<kdub> and at that line, if the platform returns true for line 64, then the platform gets the RenderableList to the screen however it wants
<kdub> or,  for mesa, mesa can accept a renderlist that has a 64x64 image + a fullscreen image
<kdub> and under the hood, it figures out 'hey, this is a hardware cursor, and this is a bypass'
<kdub> and that same line would work for android, where under the hood, it does the whole HWC dance
<camako> kdub, the term "overlay" is already confusing us....   I mean how will they render overlay-rejects? The only method we provide for layers rejected by hwc, which is not replaceable, is gl... Or am I misunderstanding...
<kdub> camako, like, a hwc extension would have to come out, I think
<kdub> that is like OpenGL-less HWC
<camako> kdub, I'm not worried what happens under the hwc hood (it's SoC specific... 2D, DSS are all fair game)... But the fallback path is the common denominator and minimum requirement assumption
<kdub> camako, taking a step back... what are you anticipating happening?
<camako> kdub, when we have taken much pain to make things replaceable, are we okay with having this assumption which ties us to opengl
<AlbertA> camako: but that's a requirement of opengl hinted strongly by the hwc headers
<kdub> well, it ties us to opengl only for a platform which has a hard opengl requirement anyways
<camako> kdub, yes as long as we are in the Android world we are good
<camako> kdub just wanted to make clear that just because GLRenderer can be replaced doesn't mean we can do without GL
<AlbertA> camako: isn't that the point of having a separate GL program as fallback for android?
<camako> kdub, I'm ok with this assumption... Just want to make sure it's explicit
<kdub> right
<camako> AlbertA: yes
<kdub> the other thing though is post_update() on mg::DisplayBuffer assumes OpenGL too
<camako> Ok so we basically require opengl... which is ok...
<AlbertA> camako: oh I think I see your point...why put an extra program if we require GL implicitly anyway
<AlbertA> camako: is that it?
<camako> AlbertA: Yes part of it...
<camako> AlbertA: But that means factoring the heck out of GLREnderer and making things difficult
<kdub> but, my big point is that the HWC program has strict requirements, GLRenderer will grow and flex
<kdub> and I don't want the HWC to break as GLRenderer grows and flexes to support like... window decorations or animations
<camako> Sure, I basically don't have a problem with what we are doing...
<camako> But was under the impression that, with GLRenderer being replaceable
<camako> we could do away with GL and support GL-less platforms eventually (of course not possible now with hwc etc)
<AlbertA> camako: yeah, I would think it would be another folder under platform :)
<camako> but I understand now that GLRenderer being replaceable is not necesarily to get rid of gl-capable gpu
<kdub> perhaps, although there is other plumbing that would have to be done
<kdub> and a lot of that plumbing would be rooting the GL concepts out of the platform interfaces
<kdub> but, overall, yes :)
<camako> Before that we'd have to break the Android dependency... Android require gles2 capable gpu now
<AlbertA> camako: yeah no doubt more changes would be needed to support it
<AlbertA> camako: but your gpu-less platform would basically provide a rendererfactory that creates
<AlbertA> camako: the gl less renderer
<kdub> right
<kdub> and really, the GLRenderer and DefaultDisplayBufferCompositor are just split between "this one doesn't have GL and this one does lines"
<kdub> I think the more important interface is DisplayBufferCompositor
<kdub> esp because  GLRenderer's interface is kinda weird
<kdub> like, 'begin()'  just does a glClear, and end() does a texture cache flush, and if you don't call it, you leak and explode
<kdub> and, if you call end() before the eglSwapBuffers, you get tears
<kdub> things like that :)
<AlbertA> kdub: yeah it's tricky to wrap state machines
<camako> Won't be long before compositors run on ucontrollers... Some gpu companies working on it... Mostly 2D at first...
<camako> Anyways... would be a good problem to have for ubuntu
<kdub> right, like maybe raspberry pi or something.. maybe some of our intrepid lurkers could look at that :)
<kdub> 'there's only 2 things hard in computer science, cache invalidation and naming things'
 * kdub thinks of that quote often when trying to come up with class names
<Saviq> kgunn, AlbertA, :P
<RAOF> kdub: That quote's incorrect; the correct one is âThere are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errorsâ âº
<kdub> RAOF, haha, clever
#ubuntu-mir 2014-04-29
<duflu> RAOF: https://launchpad.net/ubuntu/+source/libinput ?
<duflu> Sounds official
<RAOF> Indeed.
 * RAOF upgrades to utopic
<RAOF> But first: coffee!
<josharenson> kdub, re: way earlier, I am following the same method as the acceptance tests to launch server/client combo... but it isn't working, likely due to the fact that popen forks
<bschaefer> anyone know why mesa-common-dev is installing GL headers on arm?
<duflu> RAOF: I just noticed this happening on my system:
<duflu> [    1.345960] fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing generic driver
<duflu> which sounds logical
<duflu> but doesn't that mean we can never have a seamless boot screen?
<duflu> Because any modern system will start with efifb (or other) and then switch to the GPU-specific driver
<RAOF> bschaefer: Because you can totally build GL applications against mesa on arm?
<RAOF> duflu: No; intel, for example, has code to seamlessly take over from the EFI bootsplash.
<duflu> RAOF: I suspected as much. Cool
<duflu> RAOF: By default?
<RAOF> I'm not sure if they've enabled it yet.
<duflu> Trusty's boot screens seem quite broken for many possible reasons. Grub is often one
<duflu> As usual, most of the boot experience is a black screen. Sometimes a purple border. And then the login screen
<duflu> Plymouth doesn't really play a part any more
<RAOF> It's because we boot too fast.
<duflu> Yeah. I wonder what purpose the black screen with purple border is intended for though
<duflu> It just looks confusing
<RAOF> That would probably be grubish.
<bschaefer> RAOF, with glx?
<RAOF> bschaefer: Sure, why not!
<bschaefer> RAOF, hmm then either SDL2 is confused or i am :)
<RAOF> There would be some adrino GPUs where you could do GLX :)
<bschaefer> as SDL2 assumes if GL/gl.h and GL/glx.h then opengl is supported, and attempts to render in opengl on arm
<bschaefer> which fails
<RAOF> And this is at compile-time, obviously.
<RAOF> There's no way of explicitly asking for EGL?
<bschaefer> there is, and it compiles fine, its at run time when a renderer is picked
<bschaefer> which usually if opengl is around, opengl is picked first
<bschaefer> RAOF, i can get around this by --disable-video-opengl in the deb for arm builds
<bschaefer> RAOF, i just thought that opengl stayed away from arm, and it was just es 1/2
<RAOF> It's technically possible to do on arm hardware (although I haven't followed up if Rob has actually implemented it for any of the reverse-engineered drivers), and (for example) the new nvidia arm stuff supports OpenGL 4.4.
<RAOF> bschaefer: How does it pick a renderer? It can't pick a GLX one for Mir, because it can't get an X connection :)
<bschaefer> RAOF, thats awesome! I didn't even know that was close to being supported on arm
<bschaefer> RAOF, well, SDL2 just does 2 checks
<bschaefer> if GL/gl.h and GL/glx.h exists, then flip the define VIDEO_OPENGL = 1
<bschaefer> if VIDEO_OPENGL = 1, then we assume opengl is supported, and we attempt to return an opengl context for the renderer in the mir backend
<RAOF> Ah.
<bschaefer> actually its changed a bit in mir since then, but we get flags that'll hand that to us (in the mir back end)
<RAOF> Well, it should be checking whether the EGL implementation supports OpenGL.
<bschaefer> The check is just for OpenGLX11(), which flips that flag  :(
<bschaefer> i should add a check if x11 is even around at that point though?
<bschaefer> Ill have to dig more into its criteria for picking opengl, as i think its a bit to loose
<bschaefer> RAOF, thanks!
<RAOF> NP :)
<duflu> RAOF: Here you go. It works at near light speed :)   https://code.launchpad.net/~vanvugt/mir/single-buffer/+merge/217555
<RAOF> duflu: I notice you assume that reading and writing to that buffer simultaneously won't crash :)
<duflu> RAOF: Correct for all memory types I know of...?
<RAOF> I'm pretty sure doing so on some graphics hardware invokes undefined behaviour.
<RAOF> But that's ok, because you can't hardware-accelerate single-buffered clients anyway!
<duflu> RAOF:  I doubt it. Traditionally most GL implementation support single buffering
<RAOF> Not to window surfaces?
<RAOF> And only GL; that's one of the things removed in GLES
<duflu> RAOF: Yeah "traditionally" in the good old GL days
<anpok_> RAOF: duflu: you could have the other buffer in the display control unit that does the scan out.. and only block gl during scanout.. so the gles driver would really see only one buffer
<anpok_> greyback: duflu is out for short, but comes back soon
<duflu> greyback: Not sure there was any WM news this week... ?
<greyback> duflu: not from me, I was out last week
<greyback> duflu: have you anything?
<duflu> I have grand plans for making a start on defining "Window" (maybe) and the multi-surface support stuff
<duflu> greyback: But nothing official yet. I got delayed last week trying to fix some regressions.
<duflu> And it happened to be a 3-day week in Australia :)
<greyback> duflu: fair enough. This week I hope to sort out the QtCompositor multi-monitor story
<duflu> anpok_: Yeah I was thinking you could block single buffered clients "only during scanout". But not a pressing issue
<duflu> greyback: Fun. Let us know if anything needs fixing/improving
<greyback> duflu: once anpok's custom-input-dispatcher branch lands, I'll be a happy bunny
 * duflu doesn't even know what that means
<greyback> anpok_: note https://code.launchpad.net/~andreas-pokorny/mir/custom_input_dispatcher/+merge/215174 has conflicts with trunk, could you update please
<anpok_> greyback: ok
<anpok_> hm i seem to be using a different compiler than our ci - the new 4.8 or 4.9 does not include string.h..
<anpok_> hmm or that caused by a change in boost exception
<greyback> fginther: ping
<greyback> anpok_: hey, do you think lp:~andreas-pokorny/mir/input-sender-split is close to MR?
<greyback> (fyi it has conflicts with mir-devel right now)
<anpok_> i know
<anpok_> i am untangling things that I added during custom_input_dispatcher
<greyback> anpok_: ok
<anpok_> it is closeish .. but not done
<greyback> I'll be working off it for now anyway
<anpok_> thanks
<kdub> yay, figured out my resizing problem, lets see if there's any other way to break this overlay stuff
<josharenson> So I still cannot figure out how to launch a mir client (via popen) and have it attach to a mir server that was started from a different thread (at least that isn't some kind of hack)... Has anyone done this? I think the issues is popen forks
<kdub> josharenson, what sort of problem?
<josharenson> kdub its either not working at all (client cannot connect to mir), or the performance is terrible (.5 frames / sec)
<kdub> generally, I'd fork first, then have the processes do their things
<josharenson> kdub I've tried using the test framework (launch_client_process) which does exactly that... no dice
<kdub> josharenson, what is like the overarching goal?
<kdub> like, launch glmark or something automatically?
<josharenson> kdub, start server, run benchmark, stop server
<kdub> right, just making sure
<josharenson> if i call run_mir in a separate thread, sleep the main thread while server inits, and then call popen, it works
<josharenson> kdub, but that uses a sleep call, and there is no way to gracefully stop the server
<kdub> use a condition_variable to wake it up when the client has stopped
<josharenson> kdub, it blocks at the run_mir call though
<kdub> well, run_mir will just stop on the signals iirc
<josharenson> kdub, so just raise(sigint)?
<kdub> well, I dunno if that's the preferable way
<kdub> if you're using the test framework directly (eg, like writing a new acceptance test)
<kdub> then the drivers might not be being hit I think the default with those is to stub out the drivers
<kdub> like, this new executable that does this should be more of 'in the spirit of the acceptance tests' than an acceptance test itself I guess
<kdub> just my two cents though :)
<josharenson> kdub, nod... however when I tried everything acceptance test related, up to and including dropping the popen into an existing acceptance test, the benchmark still couldn't connect to mir... I'll keep trying things...
<alan_g|EOD> josharenson: kdub how about using InProcessServer with the default configuration? You can launch glmark in the test body.
 * alan_g|EOD hasn't tried it but it should be possible
<kdub> josharenson, yeah, thats another idea
<kdub> like, check out the demo_inprocess_egl example
<kdub> alan_g|EOD, but if the purpose is benchmarking, I'd rather not cut out the IPC stuff
 * josharenson looking at that function
<josharenson> kdub, alan_g|EOD certainly looks like what I'm trying to do.. I'll give it a try. Thanks
<alan_g|EOD> kdub: If you launch a child process you'll be doing IPC
<kdub> alan_g|EOD, yeah, good point
<kdub> no process context switches though
<alan_g|EOD> kdub: If you launch glmark as a child process it will be a different process
<kdub> well, I thought we were talking about inprocess egl clients
<alan_g|EOD> InProcessServer creates a server in the test process. But the client can be another process - provided you ship the connection FD across.
 * alan_g|EOD wanders away again
<kdub> have a nice wander :D
 * kdub has to reacquaint myself with InProcessServer
<stgraber> hey there
<stgraber> so asac asked me to get a Unity8 + Mir desktop session running inside a LXC container (as a way to run 14.10's unity8+mir on 14.04)
<stgraber> so far I'm trying to run unity8 with mir on vt8 from within a container. I've got access to /dev/tty8 and to /dev/dri but things are still failing a bit
<stgraber> http://paste.ubuntu.com/7361449/ any idea?
<stgraber> that's basically a clean container with just unity8-desktop-session-mir installed in there
<stgraber> asac: http://paste.ubuntu.com/7361648/
<asac> greyback: ^^
<asac> greyback: who could help?
<asac> kdub: ^ ?
<asac> racarr__: ^ :) (that was last ping i'll try)
<racarr__> Hola!
<asac> yay!
<racarr__> asac: stgraber: It's not familiar off the top of my head...lemme think/try something
<asac> nice one... thanks!
<racarr__> hmm experiment uninformative lol, lsof on a running mir_demo_server_shell
<racarr__> is all libraries, /dev/tty /dev/dri and /dev/input (which wouldnt give this error...I think opening input still just fails with a log message)
<kdub> stgraber, lxc container on the desktop?
<stgraber> kdub: yep
<racarr__> stgraber: Ok looking at gbm source its definitely the DRM fd
<racarr__> *thinks*
<racarr__> stgraber: Hmm if you aren't running USC
<racarr__> then EGL_PLATFORM="mir" shouldnt be set
<racarr__> because mir clients (incl nested mir server )use the mir egl platform
<racarr__> but a host mir server uses the
<racarr__> drm egl platform
<racarr__> it shouldnt be necessary to set EGL_PLATFORM="mir"
<racarr__> that could be it.
<racarr__> if not, backtrace would be next step to see if its the server context or unity8 failing to initialize
<racarr__> seems like the server...but *shrug*
<asac> racarr__: stgraber: no luck?
<stgraber> asac: sorry, had a meeting, back now
<asac> heh
<asac> dont worry
<asac> i just wanted to check before i drop off :)
<stgraber> racarr__: ok, so things should work if I only set QT_QPA_PLATFORM=ubuntumirserver in the environment and call unity8?
<asac> allright, i am off, cu around tomorrow
<racarr__> stgraber: Should!
<AlbertA> kdub: ping
<kdub> AlbertA, pong
<AlbertA> kdub: so on the fallback path
<kdub> sure
<AlbertA> kdub: let's say you are using demo shell
<AlbertA> kdub: and lets' say evertying is hooked up to hwc as envisioned
<kdub> right
<AlbertA> kdub: how does the extended
<AlbertA> renderer get to render the shadows?
<AlbertA> I'm not clear how the fallback and the compositor render interplay
<kdub> well, in that case, the user of mg::DisplayBuffer (eg, the demo shell writer) would know they're doing something advanced, so they wouldn't try the optimization function
<kdub> like, if the compositor writer can fit what they want to appear on the screen into a RenderableList, then they have the shot at optimization
<kdub> otherwise, they have OpenGL to do what they want
<AlbertA> ah I see
<kdub> now, a clever compositor writer with this scenario could make a Renderable that is black, and insert it into the list
<kdub> but not all ideas behind effects can be captured in the RenderableList
<kdub> like from a compositor writer's perspective, they don't know about the android fallback GL code
<kdub> and this is a cool abstraction (i'm biased :) ) because it works for like
<kdub> hardware cursor + bypass buffer too
<kdub> on mesa
<AlbertA> I see you could render the shadows just once (until window size changes) and keep inserting into the list
<kdub> right, but take like the 'magic lamp' animation (like a macos minimize)
<kdub> during the animation, the compositor writer wants to do GL, so they have the flexibility
<kdub> but once the window has become steady, then the compositor writer knows its simple, and can try submitting to the optimized function to get the optimized render the platform provides
<racarr__> living on the edge and having a second coffee today :D
#ubuntu-mir 2014-04-30
<RAOF> WOOO! Party at racarr__'s place!
<racarr__> RAOF: WOOOO. CHROMIUM ALL NIGHT
<racarr__> haha not really im almost done
<racarr__> then sometime tonight ill remove all the like // TODO: Lol comments from xmir-input.c and send it yo you on github
<racarr__> RAOF: I am not sure exactly what we should do with it...
<racarr__> for the case of a single keyboard and mouse I mean it seems
<racarr__> really good
<racarr__> but I guess it breaks everything else
<RAOF> I'll block some time out to merge it and clean up the rest of xmir.
<RAOF> It shouldn't be too hard to do in such a way that it doesn't break everything else :)
<duflu> Ah so many code reviews, so few years in human life
<duflu> Where's skynet when you need it?
<duflu> That's odd. How does an 84 line test program that's dynamically linked produce an executable of 2269640 bytes?
<RAOF> Template expansion, debugging symbols? :)
<duflu> RAOF: Yeah I excluded debugging symbols and it's still big. Templates are the prime suspect(s)
<duflu> Heh. Pick the C++ program from the C programs:
<duflu> -rwxrwxr-x 1 dan dan     19135 Apr 30 15:02 mirout
<duflu> -rwxrwxr-x 1 dan dan     18080 Apr 30 15:02 mirping
<duflu> -rwxrwxr-x 1 dan dan   1630369 Apr 30 15:02 mirscreencast
<RAOF> :)
<RAOF> Hey, mpt! Up early?
<mpt> RAOF, I usually start at 8am. I was a little late today because the subway workers are striking.
<RAOF> Ah. BST is in effect.
<mpt> Indeed
<RAOF> I wonder how much https://wiki.ubuntu.com/AccountPrivileges should change, if at all, given that we restrict screenshots and can do funky things with fullscreen windows.
<RAOF> Although I don't particularly want to add anything to what I'm sure is a huge backlog of things requiring thought.
<anpok> are there other reasons than lack of existance, why the mi::EventFilter interface is used by the nested platform?
<anpok> - i mean we could now remove that indirection and just pass the events to the mi::InputDispatcher which has more or less the same interface
<duflu> anpok: The filter is an important interface the server/shells will override. So although it looks unused it probably is used very much in real servers
<anpok> sure
<anpok> thats not what I wanted to change
<anpok> the event filter interface is just also used in the nested output - while the composite event filter is used by the dispatcher
<RAOF> I don't think there's any particular reason not to send nested events through the InputDispatcher; I think I'd prefer to send them through the _full_ input stack, with a Nested input driver (if that ends up being reasonable)
<anpok> so we have nestedoutput -> input_relay : public EventFilter -> InputDispatcher -> ... which calls another EventFilter while dispatching..
<anpok> i believe we just recycled the interface there because there was no mir style InputDispatcher till now..
<anpok> duflu: i get different results when I make normal build..
<anpok> *a
<anpok> nm - will make a separate MP later..
<anpok> already enough gore
<duflu> anpok: Consider demo-shell. None of the input handling would work at all unless EventFilter is called:
<duflu> class WindowManager : public input::EventFilter
<anpok> .. and again thats not wht I wanted to change
<mpt> RAOF, good question. Iâd rather avoid using a full-screen window or a system-modal window for other reasons, even if it isnât as futile as I thought. :)
<duflu> OK
<duflu> Cool
<anpok> just wanted to get rid of input_relay
<RAOF> mpt: Fair enough. We'll probably need to treat those windows specially in some ways, right? In particular, focus probably needs to be treated strictly.
 * RAOF is sad that we can't make it system-modal. Then we could display it entirely outside the user's desktop; it's a marvellous technical solution! :)
 * mpt has flashbacks to Windows NT asking you to type Ctrl Alt Del to ensure your security
<RAOF> It's something we could totally do :)
<RAOF> But a SAK is mostly overkill.
<duflu> ^ irony anyone?
<mpt> RAOF, sure, maybe we could dial down the probability of focus stealing when that window is up. But to keep perspective, we donât do that for browser windows on HTTPS pages containing probably-more-important password fields.
<RAOF> ...which will mostly be prefilled by the browser, anyway? :)
<RAOF> Anyway, EOD for me now. Thanks, chaps!
 * duflu waves to RAOF
<duflu> alan_g: Still got plans to unduplicate BasicSurface/Surface ? Or can I assume those classes are more settled now?
<alan_g> duflu: I was pretty much done with the surface hierarchy and about to look at other aspects of scene & shell when asked to stop moving stuff. I won't be back to that for a few days anyway as I'm dealing with trust session related changes at the moment.
<duflu> alan_g: Well I won't have any related changes ready any time soon either. Just thinking
<duflu> alan_g: Good luck with the trust stuff. Last I heard I think we mostly agreed it had no need to be in Mir at all. Although maybe you've found reasons to the contrary. Actually I don't want to know
 * alan_g wishes it were that simple
<sil2100> kgunn: hello!
<sil2100> kgunn: the Mir silo was prepared in the morning, we pressed the build button as well, but it seems there are FTBFS ;/
<sil2100> https://launchpad.net/~ci-train-ppa-service/+archive/landing-007/+packages
<sil2100> kgunn: could you have someone looking at those?
<sil2100> kgunn: the Mir FTBFS seems to be rather trivial
<alf_> sil2100: looking
<sil2100> alf_: thanks :)
<alf_> sil2100: do we need to do something to trigger a rebuild or will a push to the used mir branch be enough?
<sil2100> alf_: push to the used branch and I can fire a rebuild :)
<kgunn> alf_: sil2100 ...i'm on now...thanks
<sil2100> alf_: just give me a sign once it's updated
<sil2100> kgunn: o/
<alf_> kgunn: do you want me to push to the branch directly or prepare an MP?
<alf_> kgunn: (I assume the right branch is ~mir-team/mir/trunk-0.1.9)
<kgunn> alf_: its easiest if you just update to the branch directly
<kgunn> alf_: i assume you're making a change ? not pulling from a dev-branch rev beyond the tagged rev ?
<alf_> kgunn: right a change which I am going to forward-port to devel too (with an MP)
<kgunn> alf_: cool, that will work
<sil2100> kgunn: will you pick it up from now on? Making sure it builds? :)
<kgunn> yes sir! sil2100 thanks
<sil2100> kgunn: thanks! I hope to see it ready for releasing later today :D
<kgunn> me too!
<dandrader> anpok, hey. how is it going with the input changes?
<dandrader> I saw the first patch landed
<anpok> i am kind of through with cleanups and making the android input dispatcher use the input sender
<anpok> but it seems like I broke something in input dispatcher..
<anpok> I had to add two futher methods to the mir input dispatcher interface - those are triggers needed by the android input dispatcher - an empty stub should do there
<alf_> kgunn: sil2100: pushed change ~mir-team/mir/trunk-0.1.9
<sil2100> o/ Thanks
<kgunn> alf_: ta...
<greyback> fginther: ping
<fginther> greyback, pong
<greyback> fginther: hey, could you set up CI and autolanding on a few dev branches for me please? lp:unity-mir/devel lp:platform-api/devel
<fginther> greyback, sure, lp:unity-mir/devel is already setup
<greyback> fginther: oh cool, I'd not noticed
<fginther> greyback, let me know if it doesn't appear to be working
<greyback> fginther: will do
<greyback> fginther: could you also do lp:qtubuntu/devel  please?
<fginther> greyback, yes
<greyback> fginther: thanks very much!
<greyback> fginther: I'd like your opinion on something actually. How possible would it be to create a PPA with the devel branches of mir, platform-api, qtubuntu & unity-mir (hmm, might need USC too) which would rebuild everything any time the devel branch changes?
<greyback> it would be good so that if Mir breaks API/ABI, the dependent projects would notice quickly and fix it
<fginther> greyback, it's possible to dput changes to a PPA as part of the autolanding jobs...
<fginther> but are you asking to rebuild every package in the PPA whenever any MP is merged?
<greyback> fginther: kinda yeah :) Well at least if mir changes, the dependents are rebuilt.
<fginther> greyback, so we have a way to do that, but it might be a little clunky for what you're trying to do. We can try to set it up this way and see how well it works
<fginther> greyback, the idea is that a mir autolanding job would kick off a rebuild job of every dependent project in a specific list of jobs
<greyback> fginther: that would do just fine
<fginther> and at the end of each job, the PPA would be update
<greyback> how do the dependent projects learn if the new mir revision breaks their compilation?
<fginther> that's part of the clunky part :-). The notification mechanism is an email that the job failed
<greyback> that would do. It's what mail filters are for :)
<fginther> it sorta works because these rebuild jobs should never fail. so if it does, it's a strong indication of an abi breakage
<greyback> tat's exactly the info we want. This sounds perfect
<fginther> ok. I'll first work on add the branches you mentioned and setup the build chain as a second step. Do you already have a PPA for this?
<greyback> fginther: great, thank you. No I've no PPA set up, there is https://launchpad.net/~mir-team/+archive/staging but I can't say if being used (doesn't look like it)
<greyback> kgunn: can you say^^ ?
<slvn_> hello,
<slvn_> I develop a native C application, to run on arm UbuntuPhone os
<slvn_> I should connect to MIR
<slvn_> (through SDL backend)
<slvn_> but it can get access to /tmp/mir_socket
<slvn_> in other terms,  I try to run "mir_demo_client_eglplasma" from command line (adb shell)
<slvn_> and it works
<slvn_> but, If I package this "mir_demo_client_eglplasma" into a click package,
<slvn_> I get an error : "Can't get connection"
<slvn_> Any Idea ?
<greyback> slvn_: are you running it with unity8?
<slvn_> yes, this is with unity
<slvn_> 8
<greyback> slvn_: does ~/.local/upstart/unity8.log contain any "REJECTED" messages?
<kgunn> greyback: whats the question ? ....staging ppa is something that can be used for just that "staging"
<kgunn> so you're welcome to  modify any of the recipes...just put a note in if you do
<greyback> kgunn: I just saw other bits & pieces in there and was worried it was for staging other things.
<kgunn> we were thinking we might use that for keeping the dev branches building and sane (before ci airline)
<kgunn> yeah...but everything is on-demand i believe
<kgunn> you should be ok
<greyback> kgunn: yes exactly, I'm asking fginther to set up mir/devel, platform-api/devel and others to all build into that staging ppa
<kgunn> perfect!!!
<kgunn> that's where i wanted it to get to
<greyback> great
<greyback> fginther:  https://launchpad.net/~mir-team/+archive/staging is a good PPA to use
<greyback> thank you!
<slvn_> greyback, no "REJECTED" messages in unity8.log but some in  /var/log/syslog :  apparmor="DENIED" operation="connect" parent=11049 profile="com.ubuntu.developer.blabla.myapp2_myapp2_0.912" name="/tmp/mir_socket" pid=11056 comm="mir_demo_client" requested_mask="rw" denied_mask="rw" fsuid=32011 ouid=0
<fginther> greyback, ack
<greyback> slvn_: oh interesting, appArmor is blocking
<slvn_> could I be facing this issue : https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1236912 ?
<greyback> slvn_: are you specifying the mir socket?
<slvn_> yes,  export MIR_SOCKET=/tmp/mir_socket
<greyback> slvn_: I didn't think that was necessary
<greyback> but in your click package, that isn't being done, is it?
<greyback> I expect "$XDG_RUNTIME_DIR/mir_socket" to be the correct socket your application should connect to
<slvn_> greyback,  It is done in my click package. I call a  "sh" script that set the MIR_SOCKET then run "mir_client_eglplasma".
<slvn_> i will try
<ogra_> that wont work i guess
<greyback> slvn_: yes please remove that MIR_SOCKET definition
<ogra_> talk to jdstrand on #ubuntu-touch ... i doubt you will be able to access anything in /tmp
<greyback> it will be set correctly for apps for you
<ogra_> app confinement wont let you
<slvn_> wont work
<greyback> slvn_: to explain the architecture to you. There is actually 2 mir servers running on your phone. One is unity-system-compositor, which is the system compositor (runs as root, manages user sessions, uses /tml/mir_socket). The other is unity8 itself, which is a user session/nested server (runs as the logged in user, uses socket $XDG_RUNTIME_DIR/mir_socket)
<greyback> the unity8 mir server connects to /tmp/mir_socket. It then offers $XDG_RUNTIME_DIR/mir_socket for the user's apps to connect to
<greyback> slvn_: please check the output of unity8.log again. I suspect a REJECTED message is there now
<slvn_> greyback, ApplicationManager REJECTED connection from app with pid 11371 as no desktop_file_hint specified
<greyback> slvn_: yep
<greyback> slvn_: you need to get rid of your shell script, and have the "mir_demo_client_eglplasma" run directly
<ogra_> that wont still allow access to the socket ... talk to the security team (specifically jdstrand) a confined click app will not be able to access anything on the rootfs by design
<greyback> ogra_: he doesn't want to. He was accidentally specifying the wrong mir server socket
<greyback> appArmor was doing its job well
<ogra_> they only have access to /opt/click.ubuntu..com/$appname and the appdir under ~/.cache
<ogra_> ah, k
<slvn_> ogra_, greyback,  but maybe I can run the app with the XDG_rUNTIME_DIR/mir_socket ?
<kgunn> anpok: is the multiple creation of input dispatcher config also blocking this ....(i mean i would guess so, but just in case ) https://code.launchpad.net/~andreas-pokorny/mir/input-sender-split
<greyback> slvn_: that is not necessary, that value is already set by the click script that launches the binary
<greyback> slvn_: that unity8.log message tells me the app is connecting to unity8, but unity8 is rejecting it because a shell script is launching the binary
<greyback> you need to get rid of that shell script
<josharenson> kdub, have a minute to discuss inprocessserver?
<kdub> josharenson, I haven't gone and refreshed my memory on that class, but I can see what I remember
<josharenson> kdub, I have this http://pastebin.ubuntu.com/7368197/
<josharenson> kdub, but same issue as all other menthods I've tried... as soon as the display server stops blocking, glmark2 claims it cannot connect to mir
<josharenson> kdub I should mention the class that the code is in extends InProcessServer
<kdub> why do mir_connect_sync there?
<kdub> glmark-es2-mir should be going and connecting at some point
<slvn_> greyback, Ok. I understand now. I need to remove the a.sh, so that the executable is called with the --desktop_hint_file,  But in the otherside I need to specify the mir_socket to XDG. which is then problem !
<josharenson> kdub, ah I guess the mir_connect_sync is not needed because run_mir is called from InProcessServer's setup method... but I don't understand when glmark2 is supposed to connect
<kdub> well, popen goes and runs the glmark-es2-mir binary, so that's where glmark would connect
<greyback> slvn_: but you don't need to specify the mir socket, it is done for you by the click scripts
<josharenson> kdub... thought so, and I've looked at the glmark2-es2-mir code and it seems pretty straightforward.... still can't figure out why my hack solution works, and this doesn't
<kdub> it might have something to do with that socket negotiation like greyback suggested?
<greyback> slvn_: and you don't need the desktop_file_hint parameter either actually. Just the binary name should be enough
<slvn_> greyback, yes, that's true :/
<josharenson> kdub, ok ill keep looking i guess...
<slvn_> greyback, I mean it works. I though I did the test previously
<kdub> oh sorry greyback josharenson got my independent convo threads intertwined :)
<greyback> np, the joy of IRC :)
<kdub> josharenson, we're sure that the socket file is designated correctly on both sides?
<greyback> josharenson: if a mir client claims it cannot connect, always check ~/.local/upstart/unity8.log for a "REJECTED" message
<josharenson> kdub, I think so.. I've tried piping directly to the socket and no luck
<greyback> josharenson: unity8 is very strict on what clients it allows to connect.
<josharenson> noted
<kdub> josharenson, how would you pipe with glmark2-es2-mir's command line options though
<slvn_> greyback, so this works now I see the eglplasma launch from my click package
<greyback> slvn_: yay!
<slvn_> greyback,  but not my problem with my real app :)
<josharenson> I got the name of the socet file and did popen(glmark2 > /tmp/socket)
<slvn_> greyback, is that I cannot load the shared libraries !
<greyback> slvn_: ah, that's weird. Are they shared libraries part of your click package? Do you get appArmour messages relating to it?
<josharenson> brb food
<ogra_> you will have to build static ...
<greyback> ogra_: really?
<ogra_> yes
<greyback> eww
<ogra_> as i said, no rootfs access unless you use QML/Qt bindings
<greyback> slvn_: there's your answer
<ogra_> jdstrand probably knows a way around
<ogra_> not sure there is one though
<slvn_> ogra_, greyback,  but, if I were using the "sh" script I could have defined the LD_LIBRARY_PATH, and that was working ! (but not the mir_socket)
<greyback> surely read-only access to the click package directory wouldn't kill anyone
<kdub> josharenson, and is "glmark2-es2-mir > /tmp/socket" a way to designate the connection socket?
<ogra_> slvn_, right, but your script wants running under confinement i guess ...
<ogra_> *wasnt
<slvn_> orga_, but it was rejected by mir (not the "sh" script but the executable, i understand correctly)
<greyback> slvn_: that surprises me
<ogra_> well, i dont know all of the mechanics (which is why i keep referring to jdstrand ;) )
<greyback> slvn_: as an experiment, if you could restore your script, where you call your binary, append "--desktop_file_hint=/path/to/your/desktopfile.desktop" and try it
<greyback> slvn_: it's a workaround (warning: likely to go away) for unity8 rejecting apps with PIDs it does not expect
<slvn_> greyback, I tried :) and I got the "syntax help" of mir_client_eglplasma
<greyback> slvn_: ah, try "-- --desktop_file_hint....."
<greyback> that's two dashes, and a space, before the rest of it
<slvn_> greyback,  I am confused, --desktop_file_hint is not even working on the Exec line.
<ogra_> that only works with QML
<slvn_> greyback, Exec=mir_demo_client_eglplasma -- --desktop_file_hint=./myapp2.desktop   >>  it displays the help of the problem
<ogra_> it is an option qmlscene uses
<slvn_> ok, it makes sense
<greyback> slvn_: it's not an option for any binary really, it's actually read by unity8. I just need the binary to ignore it :)
<greyback> hence the --
<slvn_> greyback, ok, anyway ...
<slvn_> greyback, ogra_,  so my next trouble is this LD_LIBRARY_PATH that I cannot set, even to current directory. Who could help me about this ?
<ogra_> jdstrand ;)
<greyback> slvn_: jdstrand :)
<ogra_> but i guess his answer will just be "build statically"
<ogra_> that you could even run a shellscript is most likely a bug
<greyback> static building is kinda lame, but the more people who complain, the more likely we add support for shared libs
<ogra_> oyu can indeed ship your own libs inside the click
<ogra_> and *then* you can use LD_LIBRARY_PATH pointing to it
<slvn_> orgra_, I can build statically this is true ... I have no real anwser to that,  it's a working solution :)
<greyback> rpath maybe?
<slvn_> ogra_, hmmm say it again. I will ship my own libs !
<ogra_> i pinged jamie in #ubuntu-touch ... see if he drops by here
<jdstrand> hi
<slvn_> hi
<slvn_> I have a little problem :)
<slvn_> I have build a click package for my ARM (Nexus10) with ubuntu touch
<slvn_> I want to run a native C++ application using MIR and using shared library
<bschaefer> slvn_, you can always use mir-staging ppa that includes an SDL2 that has mir enabled
<slvn_> (Actually the shared library is SDL)
<bschaefer> err
<bschaefer> but theres that opengl problem atm...
<slvn_> yes, that's also true ...
<jdstrand> slvn_: have you stated all of the problem?
<slvn_> jdstrand, yes. basically the only problem is that I would like to use a shared library in my app
<bschaefer> slvn_, or you can just compile/install sdl2 to the default location...
<bschaefer> so you don't have to update the LD_LIB path
<slvn_> and that I can provide the shared library
<jdstrand> slvn_: ok. the library should be usable by your app if it is included in the ubuntu framework you specify
<jdstrand> slvn_: (ie, if it is in the framework and not usable, that is a bug)
<leitao> what is the plan for Mir on Ubuntu?
<jdstrand> slvn_: if it is not part of the framework, you need to ship it in your click package
<leitao> I mean, what is the target release to have Mir.
<slvn_> jdstrand,  the .so lib in my package.
<slvn_> but not accessible
<slvn_> unless un do LD_LIBRARY_PATH=.
<bschaefer> jdstrand, you should be able to use one of the hard coded *.desktop file though?
<bschaefer> so you're not using a click package...
<bschaefer> as SDL2 is not in the framework atm
<jdstrand> slvn_: yes. LD_LIBRARY_PATH is set for you automatically by upstart-app-launch/aa-exec-click to include $pkgdir/lib/$gnutriplet
<jdstrand> where pkgdir is the install directory for that click
<jdstrand> bschaefer: I don't understand your question wrt *.desktop. I thought we were talking about click
<bschaefer> jdstrand, well, i was trying to help him out using non-click package. Just editing a simple gallery*.deskop yesterday
<slvn_> bschaefer :
<slvn_> I have build a click package with .desktop .json and manifest
<jdstrand> if it is non-click, then just install the sdl libraries via apt and use them
<bschaefer> slvn_, unless you want a click app, which is the new in way to package things :)
<slvn_> and it works when I specify Exec=mir_demo_client_eglplasma
<slvn_> but when I put Exec=a.out it asks for the SDL2.so libs
<slvn_> I am in :)
<bschaefer> slvn_, right, try installing SDL in the default locations
<bschaefer> vs your staging dir
<bschaefer> so you don't have to do the LD_LIB
<jdstrand> I'm not sure why that would be unless mir_demo_client_eglplasma was staically linked (yet another option for you)
<bschaefer> jdstrand, once SDL2 gets added to the framework... things will be easier....
<slvn_> what do you mean by "staging dir" ?
<jdstrand> yes
<bschaefer> slvn_, hmm where do you normally install SDL2?
<bschaefer> jdstrand, i've to talk to Saviq about how hard that is, or what that means :)
<slvn_> hmm... I compiled the SDL2 with a chroot armhf
<slvn_> so no real location..
<bschaefer> slvn_, and install the *.deb?
<bschaefer> slvn_, as, where do you point LD_LIB?
<bschaefer> as you should be attempting to put SDL2 in the default locations of LD_LIB
<jdstrand> so, if you are distributing as a click, that implies you want others to use it. you will have to statically link or ship the libs in the click for the app to be usable on other systems (since those won't have sdl2)
<bschaefer> so you don't have to specify it
<jdstrand> once sdl2 is part of the framework, you won't have to do that
<bschaefer> jdstrand, that sounds a loot easier
<bschaefer> slvn_, as right now the only way to get your SDL app to run is by specify the LD_LIB path right?
<slvn_> mm, I dont really understand. Maybe I dont understand what is click
<jdstrand> click has the concept of fat packages-- ie those that can ship binaries/libraries for multiple architectures
<slvn_> I want to distribute apps like .apk
<jdstrand> right, that is click
<slvn_> ok good :)
<jdstrand> you upload click apps to the app store and they are available for ubuntu touch users
<jdstrand> the ubuntu-sdk is setup to help you with that
<bschaefer> i see, yeah im talking about non-click app atm
<slvn_> bschaefer, currently there was to solution : use Exec=a.sh  and Exec=a.out
 * bschaefer has a very limited understand of unity8
<jdstrand> the problem is that you have ventured outside of the framework, so you have some extra things to do
<bschaefer> slvn_, i normally stop unity8 and run my own mir server to test SDL apps on arm :)
<slvn_> bschaefer, yep, but user wont kill unity8 to run my app :)
<bschaefer> slvn_, haha
<bschaefer> slvn_, no
<slvn_> bschaefer,  Exec=a.sh allows me to set th LD_LIBRARY_PATH, but I get reject by MIR (mir_socket pb)
<jdstrand> slvn_: so, you'll need to decide how to deal with sdl2 for your app while sdl2 isn't in the framework
<slvn_> Exec=a.out is ok for MIR (as proven by mir_client_Demo_eglplasma) , but I cannot set the LD_LIBRARY_PATH
<jdstrand> slvn_: warning, using Exec=a.sh isn't going to work under confinement
<bschaefer> slvn_, right, that makes sense
<bschaefer> slvn_, so you'll have to figure out
<bschaefer> where LD_LIB normally looks
<bschaefer> and ensure SDL2 is there
 * bschaefer doesn't know if theres a default LD_LIB path...
<jdstrand> *or* copy those files in $pkgdir/lib/$gnutriplet in the click package
<bschaefer> i assume /usr/lib is one of them?
<bschaefer> that would be a good way to test
<slvn_> I dont understand that
<jdstrand> then put your binary in $pkgdir/lib/$gnutriplet/bin in the click package
<slvn_> you mean I should creat a "usr/lib/ directory in my click package ?
<jdstrand> slvn_: lets say your click is unpacked in /opt/click.ubuntu.com/foo/0.1
<jdstrand> then LD_LIBRARY_PATH is set to:
<jdstrand> /opt/click.ubuntu.com/foo/0.1/lib/arm-linux-gnueabihf
<jdstrand> and PATH is set to:
<jdstrand> PATH="/opt/click.ubuntu.com/foo/0.1/lib/arm-linux-gnueabihf/bin:$PATH"
<jdstrand> so, you just put whatever libraries you want in lib/arm-linux-gnueabihf in your click
<jdstrand> and whatever binaries in lib/arm-linux-gnueabihf/bin
<jdstrand> eg: you have Exec=fooexec
<jdstrand> then you have lib/arm-linux-gnueabihf/bin/fooexec
<jdstrand> and lib/arm-linux-gnueabihf/somesldlib.so
<jdstrand> then when upstart-app-launch goes to launch the app, it finds lib/arm-linux-gnueabihf/bin/fooexec which uses lib/arm-linux-gnueabihf/somesldlib.so
<jdstrand> you can see all the different paths that are set by examing aa-exec-click (note, aa-exec-click is not used on unity8, but does everything upstart-app-launch does)
<bschaefer> slvn_, so the overall idea, is to get the SDL lib placed in the default location that upstart-app-launch is looking in
<bschaefer> so you dont have to set the LD_LIB path
<jdstrand> if you wanted to have this also usable on amd64, you would also ship lib/x86_64-linux-gnu/somesdllib.so and lib/x86_64-linux-gnu/bin/fooexec compiled for amd64
<jdstrand> bschaefer: yes
<bschaefer> yup
<slvn_> ok, it makes sense !
<jdstrand> your can cheat in the short term by installing the sdl libraries via apt, then just copying them in. note, this probably won't be robust across the release
<bschaefer> right, but it'll be  a nice way to check you're heading the right direction :)
<jdstrand> yes
<slvn_> I try
<bschaefer> jdstrand, thanks for the explanation!
<jdstrand> np
 * jdstrand also notes that QML2_IMPORT_PATH is also set to $pkgdir/lib/$gnutriplet, in case you need it
<bschaefer> thats good to know
<slvn_> bschaefer, jdstrand, the PATH is correctly set, but the LD_LIBRARY_PATH is empty
<bschaefer> slvn_, im assuming it doesn't get set globally (only when its being clicked)
<slvn_> the app "b.out" is found, but same problem of missing lib .so
<jdstrand> (and as mentioned, you can see all the env vars that are set by looking at /usr/bin/aa-exec-click, which while not used by unity8, sets all the same variables upstart-app-launch does)
<bschaefer> slvn_, did you do an echo $QML2_IMPORT_PATH
<bschaefer> and attempt to put the sdl2 lib there?
<bschaefer> in the click package it self?
 * bschaefer doesn't have a N<n> laying around atm
<slvn_> QML2_IMPORT_PATH=/usr/lib/arm-linux-gnueabihf/qt5/imports:/opt/click.ubuntu.com/.click/users/@all/com.ubuntu.developer.blabla.myapp2/lib/arm-linux-gnueabihf
<bschaefer> slvn_, looks like: /opt/click.ubuntu.com/.click/users/@all/com.ubuntu.developer.blabla.myapp2/lib/arm-linux-gnueabihf
<bschaefer> is where you'll want to take a look at
<slvn_> ./lib/arm-linux-gnueabihf/bin/b.out
<slvn_> ./lib/arm-linux-gnueabihf/libSDL2-2.0.so.0
<slvn_> b.out: error while loading shared libraries: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory
<bschaefer> slvn_, well, i would have to assume its looking in a different location :)
<bschaefer> slvn_, hmm , did you look in :/opt/click.ubuntu.com/.click/users
<bschaefer> for your app?
<jdstrand> slvn_: is lib/arm-linux-gnueabihf/libSDL2-2.0.so.0 a symlink or an actual file?
<slvn_> look strange, because PATH and QML2_IMPORT_PATH are correct
<slvn_> but LD_LIBRARY_PATH is empty
<slvn_> (when I do an echo with the sh script)
<jdstrand> slvn_: how are you launching the shell script?
<slvn_> could this be a protection of root shell... or something
<slvn_> Exec=a.sh
<jdstrand> right, but how are you executing that?
<jdstrand> via the app scope? via 'start application APP_ID=...', something else?
<slvn_> in the click package, I do some "echo" that I get back with the log file
<slvn_> I build the click package, download it, install it.  click manually on the tablet, and look at the log
<bschaefer> slvn_, try with out the *.sh?
<bschaefer> and the bin directly
<jdstrand> slvn_: what did you set as your template in your security manifest?
<jdstrand> (ie, if it is running confined, then you can't use a shell script in this manner)
<slvn_>     "policy_version": 1.1 ?!
<jdstrand> slvn_: please paste your security manifest
<slvn_> {     "name": "com.ubuntu.developer.blabla.myapp2",     "description": "this is my app",     "framework": "ubuntu-sdk-14.04-dev1",     "hooks": {         "myapp2": {             "apparmor": "myapp2.json",             "desktop": "myapp2.desktop"         }     },       "maintainer": "",      "title": "My App Slvn",     "version": "0.912" }
 * ogra_ returns from dinner 
<ogra_> jdstrand, heh, yeah i was worndering if he found a bug when i heard the script works
<jdstrand> slvn_: that is your click manifest. what is the contents of the security manifest?
<slvn_> Unable to exec 'a' in '/opt/click.ubuntu.com/.click/users/@all/com.ubuntu.developer.blabla.myapp2': No such file or directory
<slvn_> I have no security manifest :)
<ogra_> ah
<jdstrand> slvn_: myapp2.json
<jdstrand> "apparmor": "myapp2.json"
<jdstrand> myapp2.json is the security manifest
<slvn_> {     "policy_groups": [         "networking"     ],       "policy_version": 1.1  } ~
<jdstrand> slvn_: right, so the app is running under confinement. what is the output of 'grep DEN /var/log/syslog' (please use http://paste.ubuntu.com)
<slvn_> I get : b.out: error while loading shared libraries: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory
<slvn_> in the app log file
<slvn_> but nothing new in the syslog
<jdstrand> slvn_: this is not a gui app atm?
<jdstrand> like, you are just trying to test to see if it loads the library?
<slvn_> well, it should be GUI app, but it dont load the lib yet
<slvn_> in the .desktop
<slvn_> Terminal=false
<slvn_> Type=Application
<slvn_> X-Ubuntu-Touch=true
<slvn_> X-Ubuntu-Single-Instance=true
<slvn_> StartupNotify=true
<jdstrand> slvn_: and there was no output with 'grep DEN /var/log/syslog' on the device?
<slvn_> no ...  BUT. If I use a "sh" script to start the "b.out" (with LD_LIBRARY_PATH=.) thenr the access to the mir_socket is reject
<slvn_> nothing appear on syslog when I click on the app
<jdstrand> slvn_: I'm not sure why LD_LIBRARY_PATH would not be set. you can see that it is here: http://ci.ubuntu.com/smokeng/utopic/touch/mako/5:20140430.1:20140411.3/7821/security/1059670/
<slvn_> Yes, this is strange :/ I have tried to update to the same security manifest, and swith the framework to 13.10. but same problem.
<slvn_> no sure if this is relevant, but I installed the Nexus10 image, one week ago
<slvn_> this is revision (?) #303
<slvn_> dont know if it make sens
<slvn_> e
<slvn_> Sometimes LD_LIBRARY_PATH get removed : http://superuser.com/questions/27376/why-does-my-ld-library-path-get-unset-launching-terminal
<slvn_> I have already seen this, dont know if it is possible in that case :/
<slvn_> maybe I dont install the click package correctly ?
<slvn_> I do :  click install  com....
<slvn_> but there is also "register",  and --all-user,
<jdstrand> slvn_: if you are installing on the device, you should use: pkcon install-local /path/to/click
<jdstrand> slvn_: I am preparing a click package for you to test. give me a minute
<slvn_> even with pkcon install-local .. same problem
<fginther> greyback, kgunn, is it ok to move the mir/devel branch builds to utopic?
<greyback> fginther: I think so yes
<jdstrand> slvn_: I think there is a bug in upstart-app-launch
<slvn_> ok:)
<slvn_> no problem, now this identified !
<slvn_> *is
<jdstrand> well, maybe my manifest is not correct
<jdstrand> tedg: hey, do I need to do anything special to my click manifest to make ual set LD_LIBRARY_PATH?
<fginther> greyback, thx
<jdstrand> https://code.launchpad.net/~jdstrand/+junk/test-click-env
<jdstrand> there is com.ubuntu.developer.jdstrand.click-env_0.1_all.click in http://bazaar.launchpad.net/~jdstrand/+junk/test-click-env/files
<jdstrand> install that with: pkcon install-local com.ubuntu.developer.jdstrand.click-env_0.1_all.click
<kgunn> fginther: yes
<jdstrand> then run start application APP_ID=com.ubuntu.developer.jdstrand.click-env_click-env_0.1 && sleep 5 && grep LD_LIBRARY_PATH ~/.cache/upstart/application-click-com.ubuntu.developer.jdstrand.click-env_click-env_0.1.log
<jdstrand> there is no LD_LIBRARY_PATH set
<tedg> jdstrand, We're not setting the LD_LIBRARY_PATH
<jdstrand> oh? why not?
<jdstrand> I thought we decided to do that? I updated aa-exec-click to do that some time ago
<tedg> jdstrand, No one asked me to :-)
<jdstrand> tedg: can you do it?
<jdstrand> :)
<tedg> jdstrand, Sure, to package dir /lib
<jdstrand> tedg: you can look at aa-exec-click for what it is doing, but basically:
<jdstrand> libdir="$pkgdir/lib/$gnutriplet"
<jdstrand> if [ -n "$LD_LIBRARY_PATH" ]; then
<jdstrand>   export LD_LIBRARY_PATH="$libdir:$LD_LIBRARY_PATH"
<jdstrand> else
<jdstrand> export LD_LIBRARY_PATH="$libdir"
<jdstrand> fi
<jdstrand> slvn_: so, there you go
<jdstrand> tedg: do you need a bug?
<slvn_> jdstrand, yep, thanks, so i dont need to try your click package
<tedg> jdstrand, Uhm, no I'll do it right now.
<jdstrand> tedg: thanks
<jdstrand> tedg: note that aa-exec-click does this:
<jdstrand> libdir="$pkgdir/lib/$gnutriplet"
<jdstrand> export PATH="$libdir/bin:$PATH"
<jdstrand> ...
<jdstrand> export LD_LIBRARY_PATH="$libdir:$LD_LIBRARY_PATH"
<jdstrand> tedg: so you have things like lib/arm-linux-gnueabihf/foo.so and lib/arm-linux-gnueabihf/bin/fooexec
<jdstrand> tedg: I thought that looked slightly odd, but pretty sure that was what was decided on the list
<tedg> jdstrand, Yeah, I think we're already doing that with the path
<jdstrand> tedg: yes, we are. I think you missed what I was saying
<tedg> Not sure why it's not "bin/triplet"
<jdstrand> tedg: ie, the .so file and the bin/ are at the same livel
<jdstrand> level
<jdstrand> yeah
<jdstrand> yeah, me either
<jdstrand> I don't particularly care what it is, but if we change it, it might break things. nothing uses aa-exec-click that I know of other than test scripts, so if you would prefer to change things, just let me know
<tedg> I don't care that much.
<tedg> Are you going to the SDK sprint?
<jdstrand> week 1?
<tedg> As long as we align with the Qt Creator folks I don't think it matters too much.
<tedg> Yeah
<jdstrand> I'll be there thu and fri
<tedg> See how loudly they're complaining :-)
<jdstrand> tedg: you are already setting QML2_IMPORT_PATH correctly by appending. LD_LIBRARY_PATH would be the same except prepending
<jdstrand> ok, I've gotta go
<jdstrand> tedg: thanks for taking care of that! :)
<slvn_> thanks jdstrand for you help !
<jdstrand> sure thing
<slvn_> thanks also ogra_, greyback, and bshaefer
<ogra_> :)
<slvn_> tedg, hi, just wondering how it works for this kind of modification ?
<greyback> welcome, hope it gets sorted out
<slvn_> tedg, when does it get released ?
<slvn_> greyback, yep, hope, then I will have to see with bschaefer why the sdl dont print anything on mir :)
<greyback> :)
<tedg> slvn_, Uhm, not sure. I can put it up for review but I don't have much control after that.
<tedg> Probably not this week considering May day.
<slvn_> tedg, no problem, I just ask because I am not familiar with the process. like, is there a ticket/report, and any *weekly* releaes or so
<slvn_> I installed Ubuntutouch on my Nexus10 using : ubuntu-device-flash --channel=devel --bootstrap
<ogra_> slvn_, it needs to go through several steps ... first it needs to get merged into the trunk branch, then the landing team assigns a build area for it where a deb gets produced, that deb goes to QA testing, once it passed that it goesd to the ubuntu archive and will then be picked up by the next phone image build
<slvn_> ogra_, but how long to see it in "channel=devel" ? 1week, 1month, 1year?
<ogra_> usually there is a bugreport accompaying it or a merge proposal at least that you can watch ... since tedg said above already he wont need a bug for it he might be able to give you the link to the MP so you can watch that
<ogra_> really depends... such small changes usually only take a day (we only build two new images in max per day)
<ogra_> but the landing and QA teams are mostly employees ... and there is may day in many parts of the world
<ogra_> which means many people wont work tomorrow
<ogra_> (or on the weekend)
<slvn_> ok great, so very fast, cool
<ogra_> lol
<ogra_> before we had that setup it would have been in the archive in 20min
<tedg> slvn_, MR is here: https://code.launchpad.net/~ted/upstart-app-launch/ld-library-path/+merge/217832
<slvn_> but without review and smoke test
<ogra_> yeah
<tedg> I'd be surprised if it took less that 2 weeks.
<tedg> than
<ogra_> tedg, heh
<ogra_> pessimist
<slvn_> 2weeks, would be fine anyway :)
<tedg> There are UAL MRs that are over a month old already.
<ogra_> approved ones ?
<tedg> Yes
<ogra_> wow
<tedg> ogra_, https://code.launchpad.net/ubuntu-menu-bar/+activereviews
<ogra_> then whoever is the lander for your team should do his job better
<ogra_> or you should have more landers in your team
<slvn_> thanks again ! and see you. I go to sleep
<racarr__> lol forgot that I deleted x-input-evdev last week
<racarr__> treated to quite a surprise
<racarr__> on rebooting
 * RAOF giggles at racarr__ 
<anpok> kgunn: yes..
<kgunn> good grief...do you sleep :)
 * kdub has wondered about that too :P
<anpok> i had a few friends visiting
<anpok> they just left..
<anpok> so it is not my fault!
#ubuntu-mir 2014-05-01
<duflu> bschaefer: SDL demos working better now?
<bschaefer> duflu, been digging into other issues with it atm :(
<bschaefer> duflu, hopefully soon!
<duflu> RAOF: Did the packaging branch change in utopic?... https://code.launchpad.net/~mir-team/mir/trunk-0.1.9/+merge/217290/comments/518614
<RAOF> Not as far as I'm aware?
<RAOF> duflu: https://code.launchpad.net/~ps-jenkins/mir/utopic-proposed
<RAOF> Looks like jenkins isn't landing such things to lp:mir?
<duflu> Bah, I'll land it anyway
<duflu> Since landing nothing or anything else would make us inconsistent
<duflu> I already verified the only diff to development-branch was the changelog
<duflu> So low risk
<Saviq> duflu, stuff's in trunks now
<Saviq> duflu, that step (pushing to trunk) needs to be explicitly triggered after packages migrated to release
<duflu> Saviq: Oh wow. Something that happened 17 hours ago just showed up
<duflu> OK
<Saviq> duflu, well, it only migrated 2h ago
<Saviq> and there was no one to push the button, is all
<duflu> Saviq: Cool. Everything is *clean* again
<Saviq> duflu, kk
<alan_g> greyback: do you have an opinion on https://code.launchpad.net/~alan-griffiths/mir/spike-shell-namespace/+merge/216332?
<greyback> alan_g: I've kept my silence mainly as I don't have a strong opinion. It would indeed be an improvement on today's situation.
<alan_g> alf_: FYI we've a CI issue to bug ChrisGagnon about when he surfaces: https://launchpad.net/~chris.gagnon/+archive/mir-demo-tester/+packages says 'mir-demo-tester' is only available for trusty under chrisgagnon's ppas
<duflu> Ah good. I was about to mention...
<duflu> Anyone got bright ideas not already mentioned in: https://bugs.launchpad.net/mir/+bug/1293944  ?
<ubot5> Ubuntu bug 1293944 in Mir "Mir deb packages with versioned names cannot be installed simultaneously any more" [Medium,Triaged]
<duflu> That's really a bug that's not solved until multiple releases are out...
<racarr__> Morning
<mterry> kgunn, is there not an open bug about Mir and deleting its stale sockets before using them?
<kgunn> mterry: there is
<mterry> couldn't find one searching for 'socket'
<kgunn> mterry: actually...there was a fix for cleaning up sockets on a nice shut down....
<kgunn> which landed
<kgunn> there is another bug
<kgunn> for aborted mirs leaving stale socket
<kgunn> lemme dig
<kgunn> alf_: ^ we should address this with the core log upload/exception right ?
<alan_g> kgunn: isn't alf_ on a public holiday?
<kgunn> :) dang it...yes
<kgunn> i forgot...almost everyone is off today and tomorrow
<kgunn> in europe
 * alan_g feels left out
<kgunn> :)
<alan_g> mterry: there's a closed one
<mterry> alan_g, huh.  I would think stale sockets from crashes still are of interest.  Can't we just do whatever fuser does to tell if it's stale or not and delete if so?
<alan_g> mterry: we do
<mterry> alan_g, ah nice...  I was testing yesterday and kill -9 left a socket that USC couldn't handle
<mterry> alan_g, did that land in latest Mir or is that a bug?
 * alan_g has to go look
<alan_g> mterry: it was fixed at -r 1560 on development-branch. Which is in 0.1.9 (according to lp:1285215)
<mterry> alan_g, ah.  Well I will reflash and retry then.  I love when things are fixed right before I ask about them!  :)
<alan_g> You're lucky - I'm of the opinion that if you "kill -9" you're responsible for cleaning up the mess.
<kgunn> mterry: robru's email indicated that the latest mir landing 0.1.9 will appear in image#7 which should be later today
<mterry> kgunn, it's available from devel-proposed now
<kgunn> mterry: ok, i could not find a bug covering the abort stale socket...so if you still hit that, definitely file a bug
<mterry> kgunn, alan_g is claiming it's fixed?  I'm testing now
<alan_g> kgunn: mterry the bug is 1285215
<mterry> alan_g, well, kill -9 isn't that different from a crash eh?
<alan_g> mterry: it is - we can (and do) process SIGABRT, SIGSEGV etc
<mterry> alan_g, ah cool
<alan_g> SIGKILL is special - we can't intercept it in a handler
<mterry> alan_g, yup.  But you're saying that the fix handles even that case?
<mterry> (by cleaning up on startup?)
<kgunn> ah...it was fix-released...
<alan_g> Yes. in 0,1,9 which will appear in image#7
<kgunn> alan_g: yeah...for some reason i thot we hadn't addressed the abort case, i just got lost :)
<alan_g> kgunn: you're thinking of bug 1235159 (fixed in 0.0.15)
<ubot5> bug 1235159 in mir (Ubuntu) "Mir fails to start if there's a stale socket" [Medium,Fix released] https://launchpad.net/bugs/1235159
<alan_g> dednick: in case you think I've forgotten about you... I've a branch that allocates an FD server-side and passes it out to the client here: lp:~alan-griffiths/mir/spike-passing-out-client-fds/ - the code's still a bit manky and probably not immediately useful to you. But it is progress.
 * kgunn goes to look up "manky"
<dednick> alan_g: ah. i was meaning to ask you about it :)
<dednick> alan_g: thanks, i'll take a look
<alan_g> kgunn: "dirty and unpleasant"
<mterry> alan_g, kgunn: yay, socket reusing seems perfect
<kgunn> mterry: thanks for that validation!
<camako> mterry, I'm the lucky owner of the enhancement request you've made abt lifecycle event callbacks in a nested config. Can you help me understand the scenario in a bit more detail?
<mterry> camako, sure
<mterry> camako, and hi!  Not sure I've met you before?
<camako> mterry, hi.. No I don't think we've met.. I'm new to the mir team
<mterry> camako, so the use case is this: I have a greeter for the phone.  Design wants the greeter to show a little animation when the greeter shows up (both on boot and on screen-on).  The unity-system-compositor (USC) already tries to send its child sessions (greeter & unity8) lifecycle events on screen on/off.  So I thought "OK, I'll listen to that"
<mterry> camako, but turns out that nested mirservers don't get those events
<mterry> camako, because while mirclient has an API for registering callbacks (in the MirConnection class)
<mterry> camako, mirserver can't get access to a MirConnection pointer.  I believe the intention is that it could get one via HostConnection
<mterry> camako, but HostConnection is never actually defined in the public headers
<camako> mterry, so unity8 is running a nested server right?
<mterry> camako, (the reason it needs to be public is because those callbacks are registered in platform-api, so if platform-api can't see them, it can't register the callbacks)
 * alan_g has to have a closer look at the "in process" client support. I really should be the same API as "out of process" clients have.
<alan_g> *It
<mterry> camako, unity8 is yeah.  As is the greeter (I'm working on the set of branches that deals with splitting the greeter out of the unity8 executable and into its own process)
<mterry> alan_g, agreed
<mterry> camako, also welcome!  :)
<camako> mterry, so as things currently stand you have both unity8 and greeter in the same process.. Is greeter a (mir) client of unity8 (mir nested server)?
<camako> mterry, sure..
<mterry> camako, today on image #7, greeter and unity8 are part of the same process, part of the same code base.  In my branches, to land at a nebulous future date, greeter and unity8 are two processes, but basically both running the same code, just different qml.  So they'll still both be nested server clients of USC
<camako> mterry, got it.. So in a bare bones scenario a nested server needs to get lifecycle events from the system server
<camako> is my understanding right?
<mterry> camako, that would be nice yeah.  The API exists in Mir to send them out, but nested clients of the USC can't register their own callbacks to hear the signals
<alan_g> mterry: I don't know if it helps in the architecture you have but...
<camako> mterry, ok thanks that helps... Let me read some code, and I'll ping you if I have more questions...
<alan_g> You can use the normal "out of process" client API in the same process as a server (we have a bunch of tests that do this) simply by getting a socket from the server and connecting over it.
<mterry> alan_g, would that be a second connection to the server or would I then be acting as a "standalone" mir server and a separate mir client?
<mterry> camako, sure, sounds good!  :)
<alan_g> mterry: You're already spinning up a server right? But you're connecting my some "internal" mechanism I've not looked into.
<alan_g> If instead you connect over a socket then you have the "client" API
<alan_g> You just call mir_connect("fd:/$fd_number")
<mterry> alan_g, well I think we are connecting via an existing socket.  But mirserver doesn't really expose that fact when in nested mode, yeah.  So you're thinking that I could simultaneously do a mir_connect?
<mterry> right
<mterry> alan_g, OK...  That might unblock me at least.  I can try.  But the bug still stands that I'd have to do such a workaround
<alan_g> mterry: this is an "instead" of, not "as well as" idea
<mterry> alan_g, whaddya mean?
<mterry> alan_g, if this is sufficient, you don't care about the mirserver connection exposing?
<alan_g> mterry: I don't know (never dug into) the "internal client" code. But if you don't mind being an "external client" in the same process instead you can use the above approach.
<mterry> alan_g, right. I may do that as a short term fix to unblock me.  But I was just saying above that ideally mirserver would just work for this case
<fginther> greyback, apologies for the delay in getting those devel branches added.
<racarr__> Do you guysn want to opaquify client library structs
<racarr__> I started thinking about child surfaces which would require changing surface parameters
<alan_g> racarr__: it is on the "TODO" list
<racarr__> and I made the cursor configuration an opaque struct (seems likely to break otherwise with addition of rgba data etc)
<racarr__> and u m
<racarr__> it just seems like a good time to do it
 * alan_g waits for kgunn to point to the right blueprint
<racarr__> We can first: Add getters/setters, second: port downstreams three: opaquify structs
<racarr__> so not much churn for other people
<alan_g> Agreed. (that's the "stable intermediate forms" pattern.)
<racarr__> Ok I will just submit an MP when I have time unless someone else gets to it first.
<racarr__> I thought it had come up in the past but couldnt quite remember
<alan_g> LOL
<alan_g> It has - we discussed it in December/London
<racarr__> Mm
<alan_g> We just haven't got to it yet
<greyback> fginther: no worries
<kgunn> racarr__: you now own "opaquify clients"
<kgunn> https://blueprints.launchpad.net/ubuntu/+spec/client-1410-mir-converged
<kgunn> alan_g: btw, had a note to myself to ask...are we done with "better and proper update notifications for surfaces" after all the surface rework ?
<racarr__> kgunn: :D
<alan_g> kgunn: I guess we are. At least it's done on the surface side. (But we're not making use of it on the compositor side - yet.)
<kgunn> that was my understanding as well...there, but yet to be harnessed
<alan_g> I think greyback may have started using it
<fginther> greyback, while testing I found that the platform-api/devel build fails http://s-jenkins.ubuntu-ci:8080/job/platform-api-devel-utopic-amd64-ci/2/console
<fginther> greyback, I'm ready to enable the jobs, but just wanted you to know there might be some failures initially
<greyback> fginther: that's ok, that failure is expected
<fginther> greyback, ok, I'll proceed with deploying the jobs. Please ping the ci channel if you find strange failures after the switch
<greyback> fginther: excellent, thank you for doing it!
<racarr__> kgunn: I just realized opaquify clients
<racarr__> may be something else lol
<racarr__> i.e. make clients opaque
<racarr__> nvm
<racarr__> read on launchpad
<racarr__> Lunch!
<racarr__> Back
#ubuntu-mir 2014-05-02
<duflu> Wow... I've got a client to keep running after a server dies
<duflu> And keep reporting a (higher) framerate :)
<RAOF> That's awkward.
<RAOF> Heh. Turns out that rather than making a general interface that's hard to implement making an interface that does just what we need is much easier. :)
<duflu> Absolutely. Hack from top-to-bottom and then modularize when it becomes necessary. Then you'll end up with the simplest code
<duflu> That's also fun. DRM reports my refresh rates are 59.95-60Hz. Yet when I measure the actual frame interval it's just below 59.90Hz
<duflu> I guess it's just a guide...
<duflu> On the plus side, that's good for my Canon camera, which annoyingly records video at 59.94Hz
<RAOF> And with that, EOW.
<greyback> alan_g: ping
<alan_g> greyback: wotcha!
<greyback> alan_g: heya :) I've question about run_mir. I see of code in that file dealing with signal handling, am I right that Mir intercepts the signal first, then propagates it to the inprocess client? (fatal_signal_cleanup)
<alan_g> greyback: it has been a while since I looked at that code. IIRC it does some cleanup and then propagates the signal to the previous handler.
<alan_g> But the cleanup is pretty limited - tell the server to stop and zap the filesystem endpoint (if any)
<alan_g> alf_: ^^ you're working on changes around this stuff. Do you know?
<alan_g> greyback: I'm just off to lunch. I can take a look when I get back.
<greyback> alan_g|lunch: it's not major, am trying to fix crash bug on unity8 stop, and need to understand exactly what run_mir is doing
<alf_> greyback: unless the inprocess client has set new signal handlers, fatal_signal_cleanup gets it first and then propagates to any previous handlers
<alf_> greyback: unless the inprocess client has set new signal handlers, *after* run_mir is called, ...
<greyback> alf_: if I set a signal handler before run_mir is called, does it get run before the one set by run_mir?
<alf_> greyback: no, it runs after
<alf_> greyback: I assume we are still talking about the auto const intercepted = { SIGQUIT, SIGABRT, SIGFPE, SIGSEGV, SIGBUS }; signals
<alf_> greyback: i.e. the fatal signals
<greyback> alf_: I have 2 issues: (1) when Ctrl+C hit, mir server shuts down, but Qt doesn't realise it. I've worked around it, but it's not great. (2) if Qt (the in process client) quits, I want to stop Mir safely.
<greyback> http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/view/head:/src/unity-mir/qmirserver.cpp is what we're doing
<greyback> issue (2) is the one concerning me right now
<greyback> the bug is if I hit Ctrl+C, the server.stop() on line 63 causes a crash
<greyback> I suspect it is due to calling stop() on a deleted server, but am not really sure. But this code is getting messier & messier, so want a better approach
<alf_> greyback: ok, so ctrl+c (SIGINT) is another matter, it doesn't go through fatal_signal_cleanup
<alf_> greyback: To stop the server you can call server_config.the_main_loop()->stop()
<greyback> alf_: what is DisplayServer::stop for then?
<alf_> greyback: or DisplayServer::stop()
<alf_> greyback: it's the same
<greyback> yep
<greyback> can you see any problem with calling DisplayServer::stop after the client returns?
<greyback> it works fine if client returns, and mir still running as usual
<greyback> but it crashes there with SIGINT, presumably Mir is shutting down having received that signal
<alf_> greyback: right, so by then the DisplayServer may have been destroyed, so 1. you can call server_config.the_main_loop()->stop() which in the worst case will recreate a main loop and have no effect 2. track server lifecycle with the ServerStatusListener
<greyback> alf_: ok, will try those, thanks
<alan_g> greyback: do you still need an answer? (I dropped off over lunch)
<greyback> alan_g: I'm ok for now, alf helped me, thanks
<alan_g> :)
<alan_g> alf_: I don't plan to land it in this form (hence it is WIP) but could you review this for me please? https://code.launchpad.net/~alan-griffiths/mir/spike-passing-out-client-fds/+merge/218074
<alf_> alan_g: sure
<alan_g> dednick: I've cleaned up the client-fd spike a bit since yesterday. Have you had a chance to look at it? Should we look at combining it with the stuff you've been doing?
<greyback> alf_: hey, using server_config.the_main_loop()->stop()  does appear to improve things, but might be exposing a Mir bug, as I now get a crash in hwcVsyncThread
<greyback> alf_: random crash I should say, sometimes it is fine
<greyback> also, after a few server crash & restarts, input appears to break completely
<greyback> on the phone that is
<dednick> alan_g: thanks haven't had a chance to have much of a look yet. i'll do it this afternoon.
<alf_> greyback: can you please try if storing the_main_loop() before run_mir and using the stored variable makes a difference?
<alan_g> dednick: fine. I'll leave it "parked" until you get back to me. No rush.
<greyback> alf_: no change
<alf_> greyback: ok, we will need to talk to kdub or AlbertA because hwcVsyncThread seems to be in the Android system or drivers
<alf_> greyback: It would be helpful if we could figure out the circumstances (esp. timing) under which this happens, e.g., if it happens when the client finishes first and then the server or vice versa etc
<greyback> alf_: ok. I'm failing to get even a useful stracktrace
<greyback> alf_: why are we allowing the server to shut down before the client has?
<alf_> greyback: who needs stacktraces when there is printf/std::cout ;)
<greyback> alf_: also being devil for a minute: what do I loose by not using run_mir, but creating, starting & stopping the DisplayServer myself?
<alf_> greyback: I am not sure about the details of our interaction with the internal clients will have to look
<greyback> (that is what I'm doing in the QtCompositor code)
<alan_g> greyback: you lose convenience
<greyback> alan_g: I gain the full control over Mir
<alf_> greyback: you also lose proper mir shutdown under most circumstances (which is related to convenience, since you can reimplement this yourself of course)
<alan_g> And with that power comes responsibility. ;)
<greyback> Mir intercepting and acting upon signals, before anything higher up has a chance to, is hard for the higher up to deal with
<greyback> I would prefer that Qt is always fully shut down, before Mir shuts down
<alan_g> greyback: there are serious limits to what can be done in a signal hander. But we can seek a "better way" together...
<alf_> greyback: alan_g: perhaps we should extend the ServerStatusListener with a stopping() method, to allow users to act before Mir components actually shut down, but it depends on the particular situation whether this would be helpful or not
<greyback> alan_g: sure. I need the help :) But this is a problem point for me and Mir, I've always struggled with it to be reliable
<alf_> greyback: please join stand-up today if possible and we can discuss a bit there
<greyback> alf_: ok
<alan_g> greyback: I missed part of the conversation. But it seems to me that you really want to know Mir intends to shut down - not that a signal has been received.
<greyback> alan_g: it is the fact that Mir decides to shut down, without the client having any say in the matter, that bothers me
<greyback> client = the in-process client, the user of libmirserver
<greyback> it bothers me that a library instigates shutdown on the applicaiton that uses it
<alan_g> that sounds reasonable.
<alf_> greyback: with mir the customer is never right ;)
<greyback> :D
<greyback> but the customer is demanding :)
<alan_g> alf_: in this industry we have "users" not "customers"
<alan_g> greyback: so, if there were a layer of indirection between run_mir() installing signal handlers and what those handlers do, and you could change and/or wrap the defaults would you be a happy user?
<alf_> greyback: alan_g: ... I was about the propose something like that ^^^
<greyback> alan_g: alf_: I think that would be good yes.
<alan_g> All problems in computer science can be solved by another level of indirection
<alan_g> "All problems in computer science can be solved by another level of indirection"
<alan_g> ...
<alan_g> David Wheeler
<alan_g> alf_: do you want to write & propose something? Or shall I?
<alf_> alan_g: greyback: I can do it, unless it's urgently needed today, in which case you have more time until EOD
<greyback> alf_: my bug is bug 1315251. I wouldn't classify it as a Critical as it's not effecting users, but it's getting in the way of tests.
<ubot5> bug 1315251 in unity-mir "unity8 7.86+14.10.20140429.2-0ubuntu1 crashes on recent utopic images" [High,In progress] https://launchpad.net/bugs/1315251
<greyback> I'll continue trying to work around it for now
<alf_> greyback: ok, we will have an MP by Monday if not today
<greyback> alf_: thank you
<alf_> greyback: still, please join the stand up to ensure we have all the details right
<greyback> will do
<alf_> alan_g: trying to understand spike-passing-out-client-fds. So, is the point to allow a client (I guess trusted server?) to request a new connection endpoint and get back an fd for that connection that it will then pass to another client?
<alan_g> alf_: yes - so the main point is the server -side wiring. The IPC call I introduced will probably morph into a trust related API.
<anpok> the StubbedServerConfiguration adds two options 'tests-user-real-input' and 'tests-use-real-graphics' .. so that when real-input is not set stubs are used..
<anpok> but those parameters are never set.
<anpok> which is probably because there is yet no method to set parameter in mo::Option
<alan_g> anpok: you can set them on the command line
<alan_g> (Or in the environment)
<anpok> hm the latter seems to be simpler in that cae
<anpok> *case
<alan_g> It is the same as any of the other options - the user gets to chose how to set it
<anpok> alan_g: i mean, thats part of the tests .. mir_test_frameworks
<alan_g> anpok: I know
<alan_g> You can put options on the command line or in the environment when using the test framework
<alan_g> Including the two you mention
<anpok> i just wonder where the best place for setting those options would be
<anpok> the StubbedServerConfiguration is a base class for InputTestingServerConfiguration.. that one is used in tests that will only work when real input components are used
<alan_g> That sounds like a bad idea
<anpok> yip
<alan_g> I mean why use a configuration that stubs something you want to use
<alan_g> ?
<anpok> it only worked up to know because the InputTestingServerConfiguration overrides methods..
<anpok> s/know/now
<anpok> alan_g: StubbedServerConfiguration, kind of stubs everything with regard to input and graphics.. as far as i can see
<alan_g> That's the point of it
<alan_g> The clue is in the name
<anpok> InputTestingServer "un"-stubs the input part to some degree..
<anpok> :)
<anpok> by overriding again..
 * alan_g thinks "bzr blame" might be useful
 * alan_g resists the temptation
<anpok> :)
<alan_g> So, don't use the Stubbed config if you don't need it
<anpok> hm have to check which test also relies on that derived configuration
<alan_g> anpok: when something doesn't make sense it should be fixed. (Preferably in an MP that just fixes the error.)
<kgunn_> anpok: sorry to pester, but you said you couldn't mp b/c of prereq branch had "needs fixing"...racarr's scene observer stuff....
<kgunn_> which branch ? i poked around but couldn't find
<alan_g> kgunn_: scene observe has landed
<alan_g> *observer
<kgunn_> ack
<josharenson> I'm trying to use InProcessServer, but it crashes. I think the problem is how I'm setting up the serverConfigration. Is this a valid way to create a server configuration? http://pastebin.ubuntu.com/7381079/
#ubuntu-mir 2015-04-27
<alan_g> alf_: any opinion? https://code.launchpad.net/~alan-griffiths/mir/more-surface-resize/+merge/256912/comments/641407
<alan_g> anpok_: any opinion? https://code.launchpad.net/~alan-griffiths/mir/more-surface-resize/+merge/256912/comments/641407
<anpok_> yes
<anpok_> posting
<alan_g> kdub AlbertA: any opinion? https://code.launchpad.net/~alan-griffiths/mir/more-surface-resize/+merge/256912/comments/641407
 * kdub looks
<alan_g> camako: I just came across some TODO comments in src/server/frontend/buffer_stream_tracker.h - are they a legacy of your (now abandoned) effort to change the buffer ownership logic?
<kdub> alan_g, I think that comment was mine at some point
<kdub> alan_g, and I think it was about how if the frontend code held a shared_ptr somewhere in there, we could re-bury the acquire/release (wrapped by swap_buffers() nowadays)
<kdub> but its kinda dusty, as we've gotten rid of TemporaryClientBuffer
<alan_g> kdub: I was wondering if the comments should go
<anpok_> kdub: do you want to have another look on the resubmitted MP here: https://code.launchpad.net/~andreas-pokorny/mir/dispatchable-event-hub/+merge/256445
<kdub> alan_g, yeah, it probably can
<kdub> anpok_, okay
<kdub> anpok_, with that, what was the lockup that was happening in the test?
<alan_g> kdub: for avoidance of doubt you're referring to both the first two TODOs in that file. (The third one looks wrong too, but is different)
<kdub> alan_g, ah, yeah, i was referring to the third one
<kdub> what? a mir file with more than one todo in it? :)
<kdub> well, the part about the shared ptr is part about it
<kdub> doh, mispoke, reorienting...
<kdub> alan_g, so the 1st and 2nd todo are about how originally, i thought a unique_ptr should get deposited there, and released when the client message came back, so its pretty old, as the BufferQueue hasn't quite evolved that way
<anpok_> lockup? the problem the first time since landed was that no initial scan happened and then that after the scan there would be blocking call to epoll_wait, instead of just testing for pending events
 * alan_g thinks he should leave it to kdub to revise these comments.
<anpok_> *the first time this MP landed..
<kdub> alan_g, mk, easy to do today
<alan_g> ;)
<anpok_> hum I guess the new input dispatcher will need another round.. so I guess I have to fit the old one meanwhile
 * kdub is prodding around the {mf,mc}::BufferStream interface today anyways
<kdub> anpok_, re lockup https://bugs.launchpad.net/mir/+bug/1444061 said a freeze, but that sounds like what you described up there
<ubot5> Ubuntu bug 1444061 in mir (Ubuntu) "[regression] Mir servers freeze on startup (mouse and keyboard not responsive)" [Undecided,New]
<anpok_> yes redid it by splitting the changes up into hm two iirc
<kdub> anpok_, right, but how does splitting it up into two fix it?
<anpok_> well .. i changed it along the lines of splitting it up :)
<anpok_> the one that already landed siwtches the timeout handling to a timer fd (which is a new addition) and this change now ensure that there is an initial call to do the device scan
<kdub> anpok_, ah, well, lgtm I suppose, maybe a comment in the bug about what the root cause was would be helpful though
<kdub> anpok_, ah, yes, thats what I was asking about
<kdub> anpok_,  +1 then from me
<alan_g> kdub: still need info? https://code.launchpad.net/~alan-griffiths/mir/more-surface-resize/+merge/256912
<kdub> alan_g, switched to abstain, probably enough for top-approval now
<kdub> but if not, i'll re-review later today
<alan_g> kdub: I'm happy to leave it for later
<kdub> alright, just in the thick of reorganizing some tests, will check later
#ubuntu-mir 2015-04-28
<duflu> camako, tmpRAOF: Forgot to mention - vGEM (2.0?) in kernel 4.1 sounds interesting. Seems to solve the performance problems (and PRIME support) for generalized software rendering support
<duflu> camako, RAOF: I suspect it doesn't solve the KMS bit though. But other projects do
<RAOF> Yeah, you still need some way of modesetting.
<duflu> Although I don't like saying "you need kernel 4.1", I do like that vGEM aims to solve performance issues that I had hoped to (and never expected to realistically) ever fix myself
<alan_g> kdub: does this resolve the confusion? https://code.launchpad.net/~alan-griffiths/mir/more-surface-resize/+merge/256912/comments/642572
<kdub> alan_g, I guess a bit closer, maybe i'm just pointing out that if width_inc is not set, then its the same thing as setting it to 1
<alan_g> kdub: yes, that's a possible server implementation.
<kdub> alan_g, and in the comment, it says "(if set, otherwise 0)"
<alan_g> in the comment it says "*min_width* (if set, otherwise 0)"
<kdub> alan_g, ah, there's the source of the confusion
<kdub> alan_g, okay then lgtm
<alan_g> alf_: is this clearer? https://code.launchpad.net/~alan-griffiths/mir/more-surface-resize/+merge/256912
<robert_ancell> willcooke sent me a command for running Xmir on convergence devices "MIR_SOCKET=$XDG_RUNTIME_DIR/mir_socket Xmir --desktop_file_hint=/usr/share/applications/los.desktop". What provides /usr/bin/Xmir?
<anpok> it used to be in here: https://launchpad.net/~mlankhorst/+archive/ubuntu/ppa
<robert_ancell> anpok, interesting - that package provides /usr/bin/Xmir but the standard package in the archives does not
#ubuntu-mir 2015-04-29
<duflu> Once again out-smarted by my own test case
<duflu> And that's a good thing
 * duflu wanders off
#ubuntu-mir 2015-04-30
<alan_g> greyback: quick Q - does Unity8 pass command line options to Mir?
<greyback> alan_g: yes it does
<alan_g> Thanks. (Confirms what I thought)
<alan_g> alf_: is this something we want off our TODO list? https://code.launchpad.net/~kdub/mir/update-bufferstream-tracker-todos/+merge/257577
#ubuntu-mir 2015-05-01
<alan_g> duflu: do we mention bugs that were not evident in 0.12 or ones that correspond to listed features?
<duflu> alan_g: Usually everything. But I get what you mean
<duflu> alan_g: Those bugs that weren't evident have "Invalid" Ubuntu tasks. But yeah document everything in the changelog
<alan_g> OK, thanks
<alan_g> duflu: pushed
<duflu> alan_g: Kay
<alan_g> duflu: AFAIK we're ready to branch as soon as lp:~alan-griffiths/mir/update-changelog lands. Can you think of anything we should wait on?
<duflu> alan_g: No, never need to wait really. Just branch ASAP and backport anything that's missing. It's better to have a quiet branch and massage that
<alan_g> I know we can sync afterwards, but it is nice to tag and branch as one event. It isn't as though trunk should be in a broken state
<duflu> alan_g: The v0.13.0 tag lives in the 0.13 branch, so not a major issue
<alan_g> FFS today switching VTs from and back to mir servers seems to be broken. Even with the binaries that worked yesterday.
<duflu> alan_g: Try switching to an intermediate VT before Mir (https://bugs.launchpad.net/mir/+bug/1409133)
<ubot5> Ubuntu bug 1409133 in linux (Ubuntu) "Heavy black flickering with Intel graphics after VT switching from X" [High,Triaged]
 * duflu -> weekend
 * alan_g thinks duflu didn't read what I said. It is VT switching that is broken. (But only on my desktop)
<greyback_> ERROR: unrecognised exception. (This is weird!)
<greyback_> FATAL: exception not rethrown
<greyback_> nicely put ;)
<alan_g> camako: for a USC release do I need to create a changelog entry? It looks like the existing ones were created by a bot.
<AlbertA> alan_g: no only if the version is changed (i.e. 0.0.7)
<alan_g> Cool thanks
<camako> alan_g, yep the bot will put what's in the MP's commit msg into the changelog
<camako> automatically
 * alan_g thinks duflu would argue with it
#ubuntu-mir 2016-05-02
<slvn> hello ! I have built a snap package app (amd64, 16.04), based on SDL2, with mir back-end compiled. I am wondering if someone using mir could give a try. It should take less than 1 min.
<slvn> basically:  sudo snap install tic-tac-toe
<slvn> (In I fact, I pretty sure it won't work, because I have forced the software rendering ... )
<Tak> ok, so I got a unity8 session going inside kvm
<Tak> is the ubuntu-mobile-ish ui expected? or do I need to configure something to run with xmir?
<anpok> Tak: the ui depends on the input devices attached.. you should get a mobilish ui with unity8 dash.. and very few apps..
<Tak> ok, that's expected then
<anpok> so by default you should get the unity8 ui in desktop mode ..you might be able to toggle to tablet mode too
<Tak> how do I tell what mode it thinks it's in?
<anpok> tablet mode means stuff is in fullscreen.. and you also have a side stage .. but to see that you need to have some apps running
<anpok> the desktop mode has window decorations..
<Tak> ok, I have desktop mode then
<Tak> I guess it's also expected that I can't install packages from the store in desktop mode? (ala https://bugs.launchpad.net/ubuntu/+source/unity8-desktop-session/+bug/1371820 )
<ubot5> Ubuntu bug 1371820 in unity8-desktop-session (Ubuntu) "Ubuntu Store Download Error, install failed." [High,Triaged]
<anpok> .. unfortunate.. but still true.. I am not sure what is missing - different construction site..
#ubuntu-mir 2016-05-03
<duflu> anpok: Did you check if the integer/float precision fix was required for touchpad scrolling?
<duflu> It would be awesome if that's all we're missing
<duflu> I didn't  :)
<anpok> nope... we cannot just switch.. or we decided not to switch
<anpok> so we need a separate axis.. for whell ticks and scroll motion
<anpok> then we wont run into the problem of needing to rescale values in downstream code
<anpok> but I found some errors in batching/resampling of relative mouse motion
<anpok> it should have caused awkward additional acceleration in unity8-like setups
<duflu> anpok: I thought floats could let us use one scroll value to rule them all? Given that a mouse wheel tick in Mir is 0.1f, we are free to then represent high-res touchpad scrolling as smaller values than 0.1f
<duflu> Like 0.005f
<duflu> Only Mir clients would need to be updated to support accumulation...
<duflu> which is fine
<om26er> Hi! the cursor on my thinkpad moves the pointer on screen very slowly in unity8 session, while the touchpad is quite responsive. How can I increase the pointer sensitivity for thinkpad's cursor ?
<slvn> om26er, I have the same issue ... In "Mouse & Touchmad", the "Mouse Pointer Speed" setting controls both the mouse speed and the (red) TrackPoint
<bschaefer> sounds like a libinput thing... anpok any ideas ^
<slvn> though, it would be nice to  have something to set the TrackPoint speed ...
<anpok> slvn: we are working on something to allow a per device setting
<anpok> so that should be only a temporary limitation
<slvn> anpok, ok, thanks for the info!
<anpok> as in .. the client api that does that configuration will have all the bells and whistles..
<anpok> but i currently do some other bugfixing work that seems to be more important..
<anpok> patches welcome..
#ubuntu-mir 2016-05-04
<duflu> RAOF: When would you estimate the majority of transitions to yakkety would finish?
<RAOF> What do you mean?
<duflu> RAOF: I mean when do you reckon the floor and mountains would stop moving
<RAOF> Oh, roughly now.
<duflu> Hmm, OK. Might switch soon
<RAOF> Oh, I don't think gcc-6 is default yet. That's the last piece of outstanding foundation change I know of.
<duflu> Sounds like a big one
<duflu> Usually is
<RAOF> Well, mir already builds with it :)
<duflu> Cool, but we also depend on a whole archive that needs to work too
<RAOF> Well, my laptop is fine with it (at the moment).
<RAOF> The everything-stages-in-proposed switch has shaved *a lot* of the sharp edges off the development release.
<duflu> Yeah I can put it on a laptop any time. But if my main work dev machine stops working, that's a problem
<duflu> RAOF: What's that? We just use proposed more now?
<duflu> Or use it properly
<RAOF> Every upload gets diverted to proposed, and only migrates when (a) the migration does not break installability, and (b) all autopkgtests pass.
<duflu> Awesome
<RAOF> This is why having a autopkgtests for Mir would be valuable; every mesa upload would sit in proposed until the Mir autopkgtests completed successfully.
<duflu> Except I'm sitting on an installability regression that's a major pain
<duflu> Which we don't test for
<RAOF> By âinstallabilityâ I mean âevery package in the archive can be installedâ, not âcan be installed on a PC with a new nvidia card âºâ.
<duflu> Ooh
<duflu> RAOF: I meant https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1546641
<ubot5> Ubuntu bug 1546641 in unity-settings-daemon (Ubuntu Yakkety) "unity-settings-daemon crashed with SIGSEGV in up_exported_daemon_get_lid_is_closed()" [Critical,Triaged]
<duflu> Which admittedly is not installability as much as acceptability
<RAOF> Indeed.
<RAOF> Also, isn't a bug in the development branch, but in the release :).
<duflu> It was in development, before it got released :)
<duflu> Two months before
<RAOF> Right, but this is less a question about yakkety.
 * duflu continues searching for unofficial EGL extensions
<kdub> alf__, are you back today?
<alf__> kdub: yes
<kdub> alf__, welcome back
<alf__> kdub: thanks!
<kdub> alf__, just wanted to point out https://bugs.launchpad.net/mir/+bug/1577357, wondering if you remember anything about that bug/workaround where we try to force mir_demo_server to link to pthread
<ubot5> Ubuntu bug 1577357 in Mir 0.23 "package-built mir_demo_server does not start on device" [High,New]
 * kdub will keep chipping at it after i've got 1578159 squared away
<kdub> probably would be nice to have in 0.23 if its simple (my experiments with it monday werent sucessful though)
<kdub> so if its not, we'll just tag to 0.24
<alf__> kdub: The original issue was seen only when cross-compiling with clang+ld.gold (IIRC). The packaged binaries are built with gcc+ld.bfd, right?
<kdub> yes, they should be
<alf__> kdub: In any case, it's very strange that the executable doesn't link with pthread even though we have the work around (i.e. explicitly use pthread symbols)
<kdub> right, and I've traced through enough to see that -pthread is there in the options
#ubuntu-mir 2016-05-05
<duflu> RAOF: Oh, you can't apt remove automatically installed packages?
<duflu> It's like they're not installed
<RAOF> duflu: ??
<RAOF> I'm not sure what you mean. âsudo apt autoremoveâ just removed a bunch of automatically installed packages here.
<duflu> RAOF: Yeah that works. But before then they don't show up in dpkg -l or apt remove <name>
<duflu> So you can't see that you've got stale packages installed other than searching for their files
<RAOF> I still don't see that behaviour :)
<duflu> PPAs are evil
<duflu> I have removed them now
<RAOF> apt upgrade, for example, lists all the automatic-but-no-longer-necessary packages I had installed.
<duflu> RAOF: Yes indeed. But dpkg -l or an explicit apt remove <name> doesn't show them
<duflu> Never mind. All gone
<RAOF> Extremely odd. I don't know how you've managed to mess your dpkg database up to such an extent :)
<duflu> Add one PPA
<duflu> that's it
 * RAOF feels tempted to write mir::aggregate_error
<RAOF> Urgh. How has this git tree got messed up?
<duflu> RAOF: Cosmic rays. Must be affecting both sides of the country
<duflu> Sun spots
<duflu> Bad luck
<duflu> <insert some poorly informed comment about quantum mechanics>
#ubuntu-mir 2016-05-06
<alan_g> greyback: FYI with a bit of hacking around I can run the qtmir demo on mesa-drm, but sadly it dies on mesa-x11.
<ogra_> is there an easy way to get the current DPI from Mir via shell ?
<anpok> ogra_: the mir tool mirout tells pixels and mm for each output
<ogra_> ah, looks like xrandr
<ogra_> thanks !
#ubuntu-mir 2017-05-01
<alan_g> anpok: https://hangouts.google.com/call/5ofvxljtdjhjjp6w4xt2onjqq4y
#ubuntu-mir 2017-05-04
<AdamH_> Good afternoon, daft question but how do I rotate the screen to portrait under mir? specifically I am looking to set the screen to portrait in mir-kiosk on Ubuntu Core
<alan_g> AdamH_: you'd need to set the display configuration programmatically. Are "you" a program? Or what access do you have?
<AdamH_> alan_g: Thanks I am building a snap on top of mir-kiosk, I couldn't see anything like xrandr on Ubuntu core to set orientation
<alan_g> AdamH_: if you're using the Mir API see: https://unity.ubuntu.com/mir/0.26/group__mir__toolkit.html#ga0d7b3425e1efccaf550ec1ae2a3e7e83
<alan_g> If you're using a toolkit then I don't know how that functionality is exposed
<AdamH_> Thanks, gives me something to work with. Just not sure how mir-kiosk uses the API yet
<alan_g> AdamH_: the client uses the API to talk to the kiosk server
<AdamH_> Thanks
<xnox> tvoss, does future mir work going to need oxide-qt package in Ubuntu?
#ubuntu-mir 2017-05-05
<alan_g> RAOF: https://hangouts.google.com/hangouts/_/canonical.com/mir-sync
<RAOF> alan_g: I'll just put down this sleeping baby. Be with you soon.
<alan_g> RAOF: np
<RAOF> Alternatively, maybe this ex-sleeping baby wants some more food...
<RAOF> alan_g: can I ping you when I'm free? ð
<RAOF> Shouldn't be too long.
<alan_g> RAOF: the joys of parenthood. ;)
<alan_g> I may not be at keyboard, will check back regularly
<RAOF> alan_g: OK, free.
<RAOF> Babies are poorly designed in many ways :)
#ubuntu-mir 2017-05-06
<anpok> yay ... the external android plaform builds and tests run
