#ubuntu-mir 2013-05-06
<mlankhorst> RAOF: ok I think I have fixed the rendering glitches to plymouth now, I'll test shortly, after that i'll try to get keyboard working
<mlankhorst> hm still glitching on this:
<mlankhorst> Mesa 9.2.0 implementation error: unhandled format!
<mlankhorst> Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
<hk> where is the lightdm code  hosted? I mean the code to build the lightdm package in Mir ppa staging.
<kdub> hello folks, status, working on  internal client/'inprocess' egl for android today
<kgunn> mornin kdub
<gustav> What devices is it running on?
<kdub> gustav, the nexus 4 and galaxy nexus are the most-tested devices, although others should work as well
<gustav> Is it virtuous?
<gustav> Is it stable or usable?
<kdub> stable, yes, usable, depends what you're using it for! ;)
<gustav> Does it support X protocol?
<gustav> I'm not asking for any particular application. I'm not interested in Android per se.
<kdub> gustav, we have the freestack platform working with X as a client (eg, mir as system compositor)
<gustav> Cool.
<kdub> gustav, are you going to give it a try? our docs capture how to do so http://unity.ubuntu.com/mir/
<gustav> Well, I'm a bit wary. I'm running a laptop/desktop Ubuntu system. I've tried mucking about with X before with bad luck. I don't really get this no-configuration thing. Any way, this system also has Optimus/nVidia. I'm going into bad odds.
<gustav> I really want to keep X11, just checking this out. X11 seems to cover so many areas that other softwares do not. Mainly Wayland.
<gustav> The thing with X11/Xorg is the harmony with / between systems.
<gustav> Although some now break the protocol. I.e. Mac OS X.
<gustav> Can't run X/Linux app/client on Mac OS X host/server.
<gustav> Talking about a fairly recent version of Mac OS X.
 * kdub likes our new fancy cursor
<gustav> Is it good for picking lint from the navel?
<Darxus> gustav: I really expect X will be entirely usable on linux for a very long time.
<Darxus> gustav: I'd say the biggest concern would be driver support, and I expect that to be handled quite nicely by glamor:  http://www.freedesktop.org/wiki/Software/Glamor  (hardware independent hardware acceleration for X).
<Darxus> gustav: And I'm pretty sure you can run X.org rootless on Mac OS X, so you shouldn't have any problem with linux clients.  Don't know why you've had a problem with it.
#ubuntu-mir 2013-05-07
<mlankhorst> RAOF: oh btw, http://people.canonical.com/~mlankhorst/plymouth-mir.patch
<RAOF> mlankhorst: Oh, cool. Did you work out how input works?
<mlankhorst> not yet
<RAOF> You get a callback for your input events (you need to pass that callback to the server)
<mlankhorst> RAOF: in what thread does the callback run?
<RAOF> In surface creation.
<RAOF> It runs in a random thread.
<RAOF> I hope you're threadsafe! :)
<mlankhorst> RAOF: but what if I want a fd + poll + call a function to run in the main thread
<RAOF> Â¹: Not actually random, but not under your control.
<mlankhorst> that WILL be a common way of doing things..
<RAOF> mlankhorst: Then you get to do something like hw/xfree86/xmir/xmir-thread-proxy.c at the moment
<mlankhorst> if xserver does it, plymouth does it, gtk supports it
<tvoss> RAOF, the callback will always only run on one thread, the client side is not using a threadpool
<mlankhorst> tvoss: missing the point, it's not under the client's control :-)
<RAOF> tvoss: Right, but the thread is not under the caller's control.
<tvoss> mlankhorst, RAOF fair enough
<mlankhorst> I think for now I'll wait then until there's proper threadless support
<mlankhorst> even pulseaudio allows you to override it :P
<RAOF> *Internally* input is on a fd, which the client library polls, so there's no particular reason why we can't expose a pollable fd, and I expect we shall.
 * RAOF goes to settle ZoÃ«
<mlankhorst> RAOF: yeah this is why I won't mind waiting a bit longer, I can do it sooner but it relies on nasty hacks :)
<kdub> morning folks, status, working on internal client/inprocess-egl for android
<kdub> specifically, expanding the platform abstraction to accomodate android
<kdub> also mp-ed a unification of our types around native buffer handles
<kdub> are we having mir sessions at v-uds next week?
<tvoss> kgunn, ping
<kgunn> tvoss: pong
<tvoss> kgunn, do you have any mir sessions planned next week?
<kgunn> tvoss: kdub its on my todo....was thinking about breaking out the thrash testing stuff we added recently
<kgunn> its a decent size topic
<kgunn> and fairly unplanned
<kgunn> but with semi-firm ideas
<kgunn> about what we need
<kgunn> so the todo part is just the bp wrangling
<kgunn> getting on the agenda etc
<tvoss> kgunn, cool, let me know if I can help
<kgunn> tvoss: kdub racarr_ open to suggestions too....lemme know if you have a topic you;d like to add
<tvoss> kgunn, input stack might be interesting, but other than knowledge transfer, I cannot think of topics
<kgunn> tvoss: that might be good....just couch it as an info sharing session rather than work planning
<kgunn> racarr_: would you be cool with that? (since you'd likely get stuck driving :)
<kdub> i kinda wish the c++ steering committee had just used 'sp' for 'shared_ptr'
<kdub> racarr_, ping
<racarr_> kdub: Hi :) What's up
<racarr_> kgunn: Ok sounds fun :)
<racarr_> <--Can't stay away from IRC
<kdub> racarr_, seems the mesa inprocess egl platform always returns the same EGLNativeDisplayType, it wouldn't break anything if it returns a new one each time mg::Platform::shell_egl_display() is called, would it?
<racarr_> No I don't think so
<racarr_> maybe it breaks share lists between contexts? (not that we use it or have plans to)
<kdub> yay, got in-process/internal-client on android to work
<kdub> now i just have to unbreak what i did to mesa ;-)
<racarr_> kdub: yay
<RAOF> racarr_: Please don't be breaking the EGL spec :)
<kdub> hello RAOF
<kdub> i'm trying to sort out the ownership story for mesa internal clients (as part of getting our platform abstraction to work for android clients)
<kdub> why do we check for valid_displays in mir_egl_mesa_display_is_valid() ?
<RAOF> Because mesa's EGL implementation checks what gets passed in to eglCreateDisplay to determine what platform is being used.
<RAOF> So we need to be able to check if a random pointer is a valid Mir EGL display, so we can correctly initialise.
<kdub> but, really, we just need one EGLDisplay for all internal clients
<kdub> right?
<RAOF> Probably?
<RAOF> I mean, there's nothing stopping Mir servers from using more than one EGLDisplay, but I don't see any particular value to them to do that.
<RAOF> It's unlikely to be a big deal if we say âshells get exactly one EGLDisplayâ
<kdub> yeah... we'll see how the abstraction looks once I iterate on the gbm platform code a bit more
<kdub> seems though that an internal client can only establish one EGLDisplay connection though, that is
<kdub> the connection to the process in which it exists
<RAOF> That would seem to be reasonable.
<RAOF> I'm not totally familiar with our in-process code. There doesn't seem to be any reason for an in-process shell to make more than one connection, though.
#ubuntu-mir 2013-05-08
<robert_ancell> thomi, is quantal still enabled for lightdm CI?
<thomi> robert_ancell: should be quantal & raring
<thomi> if I'm reading this config file correctly
<robert_ancell> thomi, the quantal builds are failing (qt5), I think we decided to drop them right?
<thomi> robert_ancell: ahh, OK. I'll propose a merge now.
<robert_ancell> thomi, ta
<thomi> robert_ancell: https://code.launchpad.net/~autopilot/cupstream2distro-config/enable-mir-docs-upload/+merge/162907
<kdub_> good morning, got internal client/inprocess working yesterday on android, today, getting both android and gbm to sit under the same platform abstraction for inprocess
<tvoss> kdub_, \o/
<kgunn> kdub_: sweet...
<kgunn> its so quiet in here w/o alan & alf
<kdub_> yep
<kdub_> we probably need a namespaced "mir_egl_mesa_display_is_valid()" for both server and client
<leowt> hi there, what is the status of the android drivers usage in mir?
<kdub_> leowt, great!
<leowt> kdub_: is there any arm platform used in development currently?
<kdub_> the nexus line of devices
<leowt> kdub_: what does need to be done to use a arm development board like pandaboard and so?
<leowt> "loading drivers" is enough or theres much to do?
<kdub_> leowt, with the pandaboard
<kdub_> which, if i remember has an imagination gpu
<kdub_> probably pretty close to the galaxy nexus, which works fine
<kdub_> but you'd have to put an android image on the pandaboard, then an ubuntu touch install to get an ubuntu chroot
<kdub_> and then just load the blobs, load mir on the device, and give it a go
<leowt> kdub_: i have a couple of boards with Mali-400 available, same situation?
<kdub_> leowt, havent tried with mir with mali cores yet, but i got my first mali device (nexus10) in the mail this week
<leowt> im very interested in mir for desktop purposes
<kdub_> so maybe 50% chance mir will work out the box, 50% chance i'll have to bang on it for a bit to get it to work
<leowt> i will be glad to help
<leowt> i have a couple of dev boards
<kdub_> well, the easiest route is to find an xda-ported ubuntu touch image for one of your boards
<leowt> kdub_: currently i see that you develop on top of android images, am i right?
<kdub_> leowt, right, but that's really so we can use the android drivers unmodified
<leowt> kdub_: what are the plans to get away from that "workaround"?
<leowt> i mean, a pure ubuntu system
<kdub_> well, its a much bigger effort than just the gpu... #ubuntu-touch might give a fuller picture
<leowt> i see
<leowt> kdub_: tnks
<kdub_> no problem
<jdstrand> hi! will MIR support XSETTINGS (I hope not, since it makes application isolation more difficult)?
<kgunn> jdstrand: had to go look at XSettings spec....i come from android land
<kgunn> but its a good question
<kgunn> this only might come up
<kgunn> in the future convergence story
<kgunn> where we want to also support old x-apps (via rootless x on mir)
<kgunn> for the near term we've only to worry with qt, wonder if there's something analogous
<jdstrand> that rootless X on mir, that is a situation where all the applications running in X are in the same session, correct? ie, there is no isolation for keyboard events, etc
<kgunn> & just as concerning in qt world
<jdstrand> (for those in X, but an app in X couldn't mess with native mir app or vice-versa
<kgunn> jdstrand: i'll have to punt and say "don't know" wrt no isolation on keyboard events
<jdstrand> )
<kgunn> yeah...that does sound correct
<jdstrand> ok, well, mir is of course designed to thwart keyboard and mouse sniffing and screen grabs
<kgunn> yes
<jdstrand> right, so within that X there might be some questions on keyboard events
<jdstrand> (that's fine)
<jdstrand> it's also fine if xsettings is in X in mir
<kgunn> cool
<jdstrand> what I'm curious about is xsettings or its equivalent in native mir
<jdstrand> (well, by some definition of 'fine'-- it is not great that applications can sniff each other in their, but those won't be coming from the app store, so it isn't an immediate concern)
<kgunn> jdstrand: yeah, that's just it....mir tends to push out true window management/policy stuff....up to the shell's responsibility
<jdstrand> s/their/there/
<kgunn> jdstrand: but it is designed such that the shell will have access to privileged interfaces
<jdstrand> if I understand that statement and what xsettings does, it sounds like the shell would be what would handle these kind of preferences, as opposed to the individual apps trying to honor them
<jdstrand> (via a lib or something)
<kgunn> right...and actually the mir guys sat with your guys last week
 * jdstrand nods
<kgunn> cause we did discuss apps sharing data (like drag and drop)
<jdstrand> I don't know if xsettings came up in particular, so I wanted to ask
<kgunn> i don't think it did...
<jdstrand> (xsettings actually allows for module loading, so apps not being able to manipulate them or their equivalent is important)
<kgunn> i will bring up with robertA gets on later
<jdstrand> kgunn: thanks, I appreciate it. it sounds like we are ok, but I wanted to have a definitive answer
<kgunn> for sure....i know raof & roberta will know for certain
<kgunn> robert_ancell: i'm about to have to jet...kid has a dr appt....
<robert_ancell> kgunn, ok
<kgunn> but jdstrand was asking if xsettings would be used in the future
<kgunn> like with rootless x for legacy x apps
<kgunn> bottom line....will x apps be able to screw with each others settings ? or input streams ?
<kgunn> i told him, x apps would be seperate process from shell/qt apps wrt settings like these
 * kgunn wonders if he was right :)
<kdub_> sounds about right
<jdstrand> robert_ancell: right, so my question was mostly about native mir apps and mir supporting something like xsettings (I hope it does not). xsettings in the old X model would allow an app load modules and things by abusing xsettings
<jdstrand> robert_ancell: it sounds like the shell would handle all that and apps would have direct access to any of it. can you confirm?
<jdstrand> robert_ancell: as for rootless X server, it sounds like there will be a shared X session for all the non-Mir stuff to get lumped into. as such, anything in that session could in theory snoop/poke at everything in that session (but not outside)
<kdub_> thomi, jenkins builds armhf package and then puts it in ppa:mir-team/staging on every commit, right?
<jdstrand> robert_ancell: can you confirm that as well? if so, it could be neat to have a different rootless x server for each non-Mir app (at least optionally), which would isolate them much like Xephyr/Xnest/etc do now (though that might break some things that they expect to have)
<jdstrand> robert_ancell: err, s/apps would have direct access/apps would *not* have direct access/
<robert_ancell> jdstrand, otp, be back in 30mins
<jdstrand> robert_ancell: ok, I'll probably be eod then, but I read backscroll. feel free to answer at your convenience
<kdub_> if anyone has some review cycles for today... https://code.launchpad.net/~kdub/mir/native-buffer-type/+merge/162635
<thomi> kdub_: correct
<thomi> kdub_: sorry for the delay
<kdub_> thomi, no problem :)
<robert_ancell> jdstrand, correct apps will contact the shell for shell behaviour. Where appropriate, we will put things into the Mir protocol to avoid unnecessary side protocols, but we haven't really found anything for that yet
<robert_ancell> jdstrand, confirm with RAOF, but for rootless X I think the default assumption is the X apps all share the same server. We'd treat using separate X servers per app as a security optimization. My gut feel is it wont be required (there wont be so many legacy apps to matter)
<RAOF> I don't think there's any particular reason we couldn't have one-rootless-server-per-X-app.
<robotfuel> when I run mir_demo_server on saucy, I get the following error message:  mir_demo_server: error while loading shared libraries: libmirserver.so.0: cannot open shared object file: No such file or directory
<robotfuel> what should I be running to run the mir server?
<kdub_> robotfuel, sounds like something's not installed right
<robotfuel> http://pastebin.ubuntu.com/5646158/ is what I have installed from mir
<robotfuel> apt-get install -y mir-demos is what I used to do the install of mir
<kdub_> maybe mir-demos should depend on libmirserver0
<robotfuel> kdub_: thats it thanks :D
<RAOF> thomi: Could we please turn on Saucy builds in the PPA?
<thomi> RAOF: yeah, I'm surpised they're not on already. will check now
<RAOF> Ahem. Or maybe I could actually add the PPA back after blowing away my install.
<thomi> robert_ancell: while I'm in here, do you want saucy for the lightdm daily builds?
<robert_ancell> thomi, yes please
<thomi> RAOF: no, you were correct - no saucy builds AFAICS
<RAOF> Hm. The dependencies for mir-demos are a filthy lie.
<thomi> FYI: https://code.launchpad.net/~thomir/cupstream2distro-config/add-saucy-for-mir/+merge/163071 - will get francis to take a look when get gets online
<RAOF> At the moment you're publishing raring builds into the saucy repo, which isn't terrible.
<RAOF> Boo. What broke the build under gcc 4.8?
<kdub_> RAOF, have you noticed that mir_demo_inprocess_egl  doesn't terminate with ctrl-c?
#ubuntu-mir 2013-05-09
<RAOF> kdub_: I've not run that recently, but isn't that expected behaviour now that input is turned on?
<kdub_> oh, is it? i don't have a problem with --enable-input=true with mir_demo_server on 673
<RAOF> Wasn't ctrl-alt-backspace meant to kill the server?
<kdub_> well, we should always clean up and exit on sigterm :)
<kdub_> oh, i see what's going on... just a problem with the demo
<kdub_> not sure about 4.8 though
<RAOF> Well, yeah, but we're not going to get SIGTERM if we eat the input (like we should!)
<kdub_> in this case, i think the problem is that we have a sigterm handler registered (in the server) but the threadloop for mir_demo_inprocess_egl doesn't respond to sigterm
<tehcloud> how often do y'all sync from the debian sid repos?
<RAOF> We, as in ubuntu-mir, don't.
<RAOF> tehcloud: But it's about daily for Ubuntu as a whole, last I checked.
<thomi> robert_ancell: RAOF: saucy packages will be built on next landing
<robert_ancell> thomi, thanks
<thomi> nw
<bregma> hey guys, dependencies withing ppa:~mir-team/staging are all fouled up:  unity-system-compositor requires libmirserver0 (= 0.0.2bzr664raring0) but only 0.0.2bzr673raring0 is available
<RAOF> thomi ^^^: I thought we had unity-system-compositor autobuilt whenever mir got built?
<thomi> RAOF: Francis is working on that this week - he promises a hacky solution by the end of the week, sorry
<thomi> but... bregma's problem sounds different
<bregma> do the dependencies really need to be that strict?
<RAOF> libmirserver0 is C++, and we don't do anything to ensure ABI.
<RAOF> It does indeed need to be that strict.
<thomi> I can manually re-land u-s-c if you like?
<RAOF> It's probably not worth it? It'll break the next time mir lands.
<thomi> this is true, but if bregma needs it...
<RAOF> Eh, if it's easy.
<bregma> well, it's bedy-bies time for me anyway, so I'll check again in 8 hours or so
<thomi> RAOF: or anyone else: do you know what's required to get mir running on the phone? I can run it, but don't see anything on the screen. Is this a case of the phone shell rendering over the mir server, or do I need to do something else?
<thomi> the mir_demo_server, that is
<RAOF> thomi: Last time I followed the instructions (stop surface flinger, chroot in, run mir) they worked?
<thomi> RAOF: oh... there are instructions?
<thomi> I guess I shoulda read the README
<RAOF> thomi: http://unity.ubuntu.com/mir/ ?
<RAOF> http://unity.ubuntu.com/mir/using_mir_on_android.html is what I followed last.
<RAOF> Of course, you *could* just read the documentation in-tree :)
<RAOF> Ooops! Documentation skew!
<thomi> hmmm?
<thomi> RAOF: can you many any sense of this? http://pastebin.ubuntu.com/5646605/
<RAOF> thomi: The documentation talks of libmirclient-demos, and a âmirâ binary. âº
<thomi> I mean, I can see what went wrong "cannot create fb display", just not why
<thomi> oh, yeah
<RAOF> Paging kdub_!
<RAOF> What hardware are you trying it on_?
<thomi> the maguro
<thomi> surely kdub_ is asleep by now
<RAOF> Probably.
<RAOF> The maguro being... Galaxy Nexus?
<thomi> yeah
<robert_ancell> thomi, what is the autolanding failure in https://code.launchpad.net/~raof/mir/separate-graphics-buffer-and-display/+merge/161939?
<robert_ancell> " Approved revid is not set in launchpad (maybe a permission problem?)."
 * thomi looks
<thomi> robert_ancell: I believe it's that the MP is either set to WIP, rather than needs review, or that the approved revision is different to the latest revision in that branch
<thomi> robert_ancell: if it fails when the MP is set to approved, please let me know
<robert_ancell> thomi, ok, will do (it wasn't WIP before RAOF just changed it)
<thomi> ahh ok
<thomi> my guess is it was approved, and then an additional revision was pushed to the branch
<robert_ancell> RAOF, "The EGLStream conceptually operates as a mailbox.  When the
<robert_ancell>     producer has a new image frame it empties the mailbox (discards
<robert_ancell>     the old contents) and inserts the new image frame into the
<robert_ancell>     mailbox.  The consumer retrieves the image frame from the mailbox
<robert_ancell>     and examines it.  When the consumer is finished examining the
<robert_ancell>     image frame it is either placed back in the mailbox (if the
<robert_ancell>     mailbox is empty) or discarded (if the mailbox is not empty)."
<robert_ancell> does any of that sound like how you would use a mailbox?
<RAOF> No :)
<RAOF> But the behaviour *we* want is in EGL_stream_fifo
<robert_ancell> RAOF, and in this case an app is a EGL stream producer and the display server is an EGL stream consumer?
<RAOF> Indeed.
<RAOF> Although that's not necessarily exposed to the client.
<robert_ancell> "3.10.2.1 No way to connect consumer to EGLStream" ok, so this is a half-spec :)
<RAOF> Right.
<RAOF> All the producers and consumers are their own specs.
<RAOF> You're after http://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_stream_consumer_gltexture.txt for the consumer side, and http://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_stream_producer_eglsurface.txt for the producer side.
<RAOF> Oh, and http://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_stream_cross_process_fd.txt
<robert_ancell> RAOF, and if you have this stuff you don't need the DRM/android buffer IDs that we currently pass?
<RAOF> Right. They become the buffer passing mechanism.
<robert_ancell> that would simplify things down a lot
<RAOF> Yeah, it'd be pretty neat.
<robert_ancell> And currently we require Mesa because of the current buffer passing - with EGL you can use any standard EGL implementation (as long as it has the extensions)
<RAOF> Yup. Although you also need the ability to do a little bit of extra hooking into the EGL implementation to get a Mir EGL platform.
<robert_ancell> RAOF, what sort of stuff?
<RAOF> AFAIK that's a bit like what Android does.
<RAOF> Well, at base you need to be able to pass a MirSurface into eglCreateWindowSurface.
<robert_ancell> ok
<robert_ancell> RAOF, GLX works currently on Mir right?
<robert_ancell> (is that both GLX using DRI and traditional GLX?)
<RAOF> On the mesa drivers, yes.
<RAOF> I'm not sure what you mean by âtraditional GLXâ. If you mean indirect rendering, then yes.
<robert_ancell> yes
<robert_ancell> so this is what is required for GLX on android drivers?
<RAOF> This is a part of what's required, yes.
<alan_g> thomi: The docs on http://unity.ubuntu.com/mir/ seem behind the times. How often are they pushed?
<kgunn> alan_g|lunch: hey...you "surfaced" :)
<kgunn> quiet day w/o alf
<alan_g> kgunn: yes. Things seem to have been quiet all week.
<kdub_> good morning
<kdub_> thomi, ping me when you get up, we'll get your maguro running
<kdub_> alan_g, do you remember why we had to disable death tests on android? i'd guess we don't have to do that anymore
<alan_g> kdub_: There was a problem with the way that gtest forked. I'd guess the same
<alan_g> kdub_: shall I try enabling them?
<kdub_> i tried them on the device yesterday, seem to be ok
<alan_g> cool. (I imagine they've been fine since we junked the NDK)
<alan_g> kdub_: I'm not sure where to start with the "Composition bypass - Android" task I accepted. As the team Android specialist can you get me started? (If you're busy or need to think about it we can aim for a hangout tomorrow.)
<kdub_> alan_g, http://bazaar.launchpad.net/~mir-team/mir/trunk/view/head:/src/server/graphics/android/fb_swapper.h#L34
<kdub_> basically, we need a BufferSwapper that implements the swapping algorithm, and a path for a client to request composition bypass
<kdub_> i can hop on a hangout though
<kgunn> kdub_: alan_g thanks for jumpstarting on comp bypass...
<kgunn> its so key for mobile
<alan_g> kdub_: I've updated https://code.launchpad.net/~alan-griffiths/mir/support-multiple-inheritance-in-config/+merge/163156
<kdub_> alan_g, still looks good, i'm unsure why changing {} to () helped too though...
<alan_g> kdub_: I *think* it is a compiler bug (as clang agrees with us) but not completely sure there isn't a corner case that requires a copy constructor.
<alan_g> kdub_: did you ever ask thomi about the updates docs on http://unity.ubuntu.com/mir/ (they seem to miss a bunch of last week's changes.)
<kdub_> alan_g|life, yes, i think they're update regularly, but there's some sort of caching somewher
<racarr_> Hi all kind of in and out today still due to moving
<racarr_> But tomorrow back to normal
<racarr_> and by normal I mean I have a new house and office without lots of crazy (all love intended) housemates so hopefully better than normal :)
<kdub_> racarr_, cool
<alan_g|life> kdub_: thanks, I'll be patient (for now)
<thomi> hey guys - will look into the mir docs not being uploaded today.
<thomi> kdub_: I'd love to get my maguro up and running, btu I'm snowed under with distractions right now - how much longer before your EOD?
<kdub_> thomi, a bit of time :) i flashed my maguro today with 119, mir-staging ppa. mir works, but make sure surfaceflinger has never started
<kdub_> just to be safe :)
<thomi> kdub_: ok, I'll start flashing mine now, and maybe when I'm done I can ping you agaibn
<thomi> *again
<kdub_> like, 'adb shell stop'  will stop the surfaceflinger process, but i don't trust it to clean up fb resources
<thomi> so what's the better way?
<kdub_> well, you can muck around with the android startup files, i usually just mv /system/bin/surfaceflinger somewhere that the android init scripts can't find it :)
<thomi> hey guys - I wonder if I could get someone to review this trivial MP please? https://code.launchpad.net/~thomir/mir/fix-documentation/+merge/163231
<thomi> it's need to fix the documentation upload issues
<thomi> kdub_: I'm still getting the same error,and I don't seem to be able to move the surfaceFlinger binary since it's on a read-only filesystem
<thomi> am I missing something?
<kdub> adb remount
<kdub> Its probably ok if sf and all sf clients are dead
<thomi> that worked better - rebooting...
<thomi> kdub_: ummmm... something bad happened. now it doesn't boot?
<thomi> hmmmm
 * thomi tries pulling the battery
<kdub>  Well the shell wont boot up
<kdub> But the adb connection should work
<thomi> sure, it wasn't doing anything though. Pulling the battery seems to have fixed it
<thomi> for a second there I thought I'd bricked it somehow
<kdub> Nah, they're tough to brick :)
<thomi> well, mir_demo_server seems to run, so I'm one step closer :)
<thomi> wooo! glmark running on the phone
<kdub> Yay!
<thomi> kdub_: seems like it's limited to 60FPS, just like the desktop though :(
<thomi> I get 59 or 60 FPS for everything :(
<kdub> Right, it is swapinterval 1
<thomi> I'll pretend I understand... can you fix it easily?
<kdub> My next task is a bit of performance analysis...
<kdub> Probably will have to add swapinterval 0 support as part of that
<thomi> ok
<thomi> robert_ancell: got a second?
<robert_ancell> thomi, sure
<thomi> robert_ancell: I wonder if you'd mind reviewing my MP above ^^ ?
<robert_ancell> thomi, sure
<thomi> I want to see what's causing the mir docs to get out of date on the server - I suspect it's the caching proxy IS uses rather than anything our side
<thomi> thanks
<robert_ancell> thomi, what do we need to do to retrigger CI on https://code.launchpad.net/~mterry/lightdm/autologin-in-background/+merge/162670? I tried the "click here to trigger a rebuild" but it didn't do it
 * thomi checks
<thomi> robert_ancell: the link worked for me. It's a bit awkward though - if you're not logged in to the jenkins server it'll ignore you
<robert_ancell> how rude!
<thomi> robert_ancell: it's running now though: http://s-jenkins:8080/job/lightdm-ci/31/console
<thomi> yeah
<thomi> guess what? jenkins is the worst CI server. evar
<thomi> (IM not so HO)
<robert_ancell> kdub, woah, massive patch :)
<kdub> Medium size :)
#ubuntu-mir 2013-05-10
<thomi> mir docs upload is fixed
<kgunn> alan_g: mornin', just saying hello
<alan_g> kgunn: afternoon ;)
 * olli_ waves too
<alan_g> hi olli
<kdub> racarr_, are you back today?
<racarr_> kdub: -.- I was supposed to be but I couldn't get a zipvan last night so I need one more day :)
<racarr_> for the next 2 hours or so was going to try and catch up though while I wait on my large item moving helper
<kdub> racarr_, just wanted to give you a chance to look over the inprocess-egl stuff for gbm in https://code.launchpad.net/~kdub/mir/android-internal-client/+merge/163211
<racarr_> kdub: Peeking
<racarr_> I feel the InternalClient class is kind of strange but need to think about it...
<racarr_> How is it different than a "Client"
<kdub> racarr_, its not really different than a client
<kdub> other than the fact that its not the normal ipc-based client
<kgunn> racarr_: so are you in your new place tonight?
<racarr_> kgunn: Yep!
<kgunn> racarr_: awesome!
<racarr_> goal for today is move all my stuff, establish bedroom, establish bathroom/kitchen and acquire computer desk :)
<kgunn> racarr_: "establish" :D
<kgunn> like a military action
<racarr_> A little terrified of going to Ikea. Bed bath and beyond was almost totally overwhelming
<racarr_> haha
<racarr_> my family was military and we moved every year so it's like
<racarr_> a routine
<kgunn> :)
<kgunn> my wife hates when i go  to bed bath beyond...i want to buy everything
<racarr_> haha that's how I felt but I also was worried I was going to fill up my entire shopping cart so I walked around telling myself I couldnt buy everything I wanted
<racarr_> then walked out with like 1/3rd of what I needed and decided to try again today...
<kgunn> racarr_: that's good self control
<arsenm> racarr_: Bed bath and beyond enthusiast
#ubuntu-mir 2014-05-05
<RAOF> You know what would be nice? If gdb didn't die when trying to dereference this shared_ptr<>.
<duflu> RAOF: gdb gdb program ?
<RAOF> Now you have two problems :)
<anpok> is the input reception mode something that should be stored as a MirSurfaceAttrib?
<racarr__> MORNING
<racarr__> anpok: Probably not because its not exposed to clients
 * ogra_ shades his ears)
<racarr__> ahaha
<ogra_> :)
<racarr__> I accidentally woke up 2 hours early (...I seem to have this habit of resetting my alarm clock while I sleep)
<ogra_> just use an ubuntu phone ... it will let you sleep ;)
<racarr__> hahaha
#ubuntu-mir 2014-05-06
<bschaefer> duflu, hey, figure out that software rendering issue in SDL. Turns out if you set mir_buffer_hardware instead of mir_buffer_software you get a failed to mmap a buffer
<bschaefer> i think it started to happen when shm was introduced
<duflu> bschaefer: Ah yes, sounds like the right error then :)
<bschaefer> duflu, :)
<bschaefer> you can get the same error if you change multiwin as well
<duflu> I keep thinking we should augment some exception messages like that to describe the most likely cause/mistake
<bschaefer> could be helpful, but the area it fails at, im not sure if it knows much about the buffer type
<bschaefer> as it happens in: client/mesa/client_buffer.cpp:60:
<RAOF> We should make mir_surface_get_graphics_region return an error when called with a hardware buffer.
<bschaefer> but there could be a better way to detect, if the surface is set to hardware
<bschaefer> and you ask for the region, it should possibly have an error there
<bschaefer> yeah
<duflu> bschaefer: Yes, that too. "hardware" and "software" are kind of vague words
<bschaefer> duflu, just a little :)
<duflu> bschaefer: More confusingly "hardware" does not always imply GL. For example, our X drivers render (accelerated) using "hardware" buffers but not GL
<duflu> But that's the only exception
<bschaefer> duflu, thats interesting, I didn't know that... im not sure how SDL would handle that?
<bschaefer> as SDL either uses OpenGL/ES1/ES2/Software
<duflu> bschaefer: Yeah that's normal. Only X is weird.
<bschaefer> duflu, haha
<RAOF> As far as almost all clients are concerned, âhardwareâ == âCan use OpenGL*â
<RAOF> Theoretically you could have something like the cairo-drm backend, though, and that would use hardware buffers without going through GL.
<duflu> RAOF: Can we ever use OpenGL on shm buffers? surely...
<bschaefer> cool, yeah i hand't taken that into consideration, and defaulted to "hardware buffer"
<RAOF> duflu: Yes, we can, if we want to.
<RAOF> duflu: Although that'll need some libEGL support.
<duflu> RAOF: Your sound's still broken. I give up on the hangout
<RAOF> Eh.
<RAOF> I didn't think anyone was saying anything?
<duflu> RAOF: I think we need that for software rendering anyway
<RAOF> Oh, yes.
<RAOF> Well, if we want to allow software-rendered GL clients.
<duflu> It would also be generally cool to have a fallback buffer sharing mode that works on *everything*
<RAOF> Buffer sharing the easy part; the hard part is getting anything on the display :)
 * duflu thinks the opposite
<RAOF> Howso?
<duflu> We should work together
<duflu> RAOF: I just know more framebuffer stuff than buffer sharing
<RAOF> We've already got a buffer sharing mechanism that works everywhere - shm.
<duflu> When it's fixed to work everywhere?
<RAOF> It works everywhere now (although doesn't get you GL)
<RAOF> (And will never get you hardware-accelerated GL)
<duflu> I think we're missing a flag in our buffer messages to tell the client explicitly which to use?
<RAOF> Yes; I we assume that the client remembers what it asked for.
<duflu> Fortunately we have a flags field in those messages :)
<duflu> Although an enum to support N buffer sharing mechanisms might be better
<RAOF> Hm, maybe?
<RAOF> I don't think that would be particularly helpful; everything but âsoftwareâ is platform-specific.
<duflu> RAOF: Yeah that's enough so long as the type of "hardware" is clarified by the currently loaded client driver-thing
<RAOF> And that's what mir_surface_get_platform_type tells you.
<memeka> hi all
<memeka> I have libhybris installed on an ARM device, test_hwcomposer works ... what else is needed to get mir running?
<racarr__> oh sorry forgot
<racarr__> the meeting
<duflu> racarr__: Yeah twas just RAOF and myself. Nothing happened
<racarr__> :)
<racarr__> "It was just me and RAOF! NOthing happened I Swear"
<racarr__> like a sitcom plot
<racarr__> lol
<duflu> Nobody in here but us chickens
<RAOF> memeka: Have you tried it? That sounds like the major prerequisites :)
<memeka> RAOF: not yet... planning to
<memeka> just wanted to know what to expect
<memeka> XMir probably will not work?
<RAOF> XMir will definitely not work.
<duflu> memeka: No XMir, but you should be able to compile/run the native Mir demos
<memeka> except the demos, is there anything that would run?
<RAOF> SDL2 stuff should.
<duflu> memeka: You need toolkits to answer that question. So yes, SDL2 and Qt-based apps
<duflu> But you have to have the right packages and voodoo
<RAOF> memeka: Well, XMir won't work unless your ARM device happens to already have a kms driver, X support, mesa support, and you want to add a little patch to its DDX. :)
<memeka> RAOF: so that's a no :)
<RAOF> Correct :)
<memeka> demos require libgles2-mesa .... can I bypass mesa and use the egl from hybris?
<RAOF> They will use the egl from hybris.
<memeka> k, so setting the env variables should do it then
<RAOF> I think if you've got hybris installed it will already be providing your libGLES2.so.2; we use the alternatives system to delegate stuff like that.
<memeka> kwin_gles and konsole should work, right?
<duflu> memeka: Native EGL/GLES stuff needs explicit porting to Mir. Just the initialization stuff
<duflu> Because you need to create a Mir connection and surface for EGL to run in, and GLES runs in that.
<memeka> duflu: i see
<duflu> Unfortunately EGL is not sufficiently featured to be a "platform" in itself
<memeka> duflu: so that's why the egl tests fail :)
<duflu> RAOF: So it seems 1hz needs much porting
<memeka> only hwcomposer test actually runs
<RAOF> duflu: Yes indeed.
<duflu> Plus all the other proposals :P
<RAOF> duflu: I'll be doing that shortly, once the FrameDroppingPolicy
<memeka> duflu: and where is the init stuff done? :D
<duflu> mememka: A good example is in the Mir source. This sets up enough of Mir for an EGL app to use it: http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/examples/eglapp.c
<memeka> right, so this is when you want to start an EGL app
<memeka> this does not mean that kwin_gles needs to be patched as well, does it?
<memeka> duflu: thx for the link
<memeka> duflu: hmm.. the exmaples there have a demo shell and window manager ... so I guess kwin_gles will not work...
<duflu> memeka: It's not a real shell or window manager. They're just class names. You can still run anything on top of that.
<RAOF> memeka: Correct. kwin is fundamentally an X11 window manager. Making it work with Mir will require you to turn it into a Mir compositor.
<memeka> my impression was that you need android /system + libybris + mir and it should work out-of-the-box with e.g. unity 8
<memeka> RAOF: yes I forgot kwin is not mir compositor :P
<memeka> so for unity8 + apps like konsole, there shouldn't be anything to code
<memeka> while for EGL apps you just need to make them Mir clients
<RAOF> As long as konsole doesn't use any X11-only calls.
<RAOF> Apparently lots of KDE apps _do_ use X11-only calls (and are now adding Wayland detection, so they'll make X11-only or Wayland-only calls depending on environment variables. Woot!)
<RAOF> This seems to me to be a sub-optimal solution over, say, adding support in Qt to abstract these interfaces, but who am I to judge? :)
<memeka> I see...
<memeka> thanks for the answers...
<RAOF> But there shouldn't be _significant_ work required to get, say Konsole to run under a Mir compositor.
<duflu> Is there a nice software-blitting console app we should aim to port first?
<RAOF> There's kmscon - http://www.freedesktop.org/wiki/Software/kmscon/
<RAOF> That actually gets us both software and GLES2-accelerated rendering.
<duflu> RAOF: Sounds a little too tied to KMS/DRM
<RAOF> Also supports wayland.
<RAOF> Though a fork, perhaps.
<RAOF> See also, http://www.freedesktop.org/wiki/Software/kmscon/wlterm/
<RAOF> And with that Qt Creator lock up, it's EOD for me!
<duflu> Wow, throwing and catching exceptions is exceptionally slow. I can actually see the difference on screen :(
<asac> racarr__: hey, do you know if stgraber ended up being able to get something going with the lxc container thingy last week?
<racarr__> asac: I never heard back
<asac> kk
<asac> thanks racarr__
<AlbertA> kgunn: so I have a branch for compatibility changes to 0.2.0 for unity-mir , do I push this devel now I suppose? what is the workflow now?
<AlbertA> kgunn: compat to next revision of mir
<kgunn> AlbertA: yes...that would make sense, and _should_ end up giving you a binary in staging
<AlbertA> kgunn: how does that work? Just pushing the branch gives you a binary? or after it's merged?
<kgunn> the recipes used for unity-mir & papi now use their respecitive devel branches for daily builds
<kgunn> https://launchpad.net/~mir-team/+archive/staging
<kgunn> you can see here now, papi is failing too...
<kgunn> https://launchpad.net/~mir-team/+archive/staging/+build/5971411
<kgunn> i assume for the same change ?
<AlbertA> ah I see, so basically a compat branch with the debian ver bump should be enough and the next daily build will just pick it up
<AlbertA> so it builds against mir devel ?
<AlbertA> kgunn: it looks like papi devel is behind trunk
<AlbertA> kgunn: or am I reading that wrong
<kgunn> AlbertA: well...it shouldn't be, but lemme check
<kgunn> yeah...
<kgunn> you're right
<kgunn> but i guess its just because we've not really tried to commuicate the change in way of working
<kgunn> (ci just got going on thurs last week...)
<kgunn> AlbertA: also...we need to do this on u-s-c too
<kgunn> e.g. there is no u-s-c dev branch
<kgunn> atm
<AlbertA> kgunn: ok
<AlbertA> kgunn: so until that's in place, you can't really build agains mir devel then I suppose
<kgunn> right... AlbertA, i'll put one up and see if i can get francis to enable ci on it
<kgunn> AlbertA: so for papi-devel, i just merged trunk...but was that really the right way to do it ?
<kgunn> i feel its wrong somehow...
<AlbertA> kgunn: for this one time yes, to sync them up
<kgunn> yeah...
<kgunn> i suppose in the future
<AlbertA> kgunn: then after this devel should be merged to main
<kgunn> the right way would be indy MP's per change just retargeted
<AlbertA> kgunn: for the rest of the MP's coming in
<AlbertA> kgunn: I see to keep a visible history?
<kgunn> exactly
<kgunn> AlbertA: ...but not sure how to achieve it ?
<AlbertA> you can merge individual revisions from the other branch
<kgunn> hmmm AlbertA how to undo what i did?...local bzr revert, then push ?
<AlbertA> kgunn: but hold on...I think bazaar does keep history just ...doesn't display it
<AlbertA> kgunn: so maybe you don't really want that? it may complain about criss-cross merging
<AlbertA> kgunn: in the future when merging from devel to main
<kgunn> this would be simpler is trunk were....ah never mind
<AlbertA> kgunn: maybe just copy the commit messages to the merge commit?
<kgunn> AlbertA: actually...its ok, from the perspective that trunk (release) reflects the right history
<kgunn> its only devel which will have a "merged from trunk" item
<kgunn> which is totally sensible i think
<AlbertA> kgunn: yeah
<kgunn> ok..feels slightly less wrong
<kgunn> fginther: hey, hope you're well, could you help us out by setting up ci to run ~mir-team/unity-system-compositor/development-branch
<kgunn> just like it does for u-s-c's trunk ?
<fginther> kgunn, I can actually get to that right now
<kgunn> fginther: once that's done, we'll be totally switched onto dev branches
<kgunn> cool
<racarr__> kgunn: EVerything has dev branches now?
<racarr__> that are intended to always build against mir devel
<racarr__> ?
<kgunn> yes...in the process of writing a mail :)
<racarr__> yay
<fginther> kgunn, the ci job is ready now
<kgunn> fginther: thanks!
#ubuntu-mir 2014-05-07
<RAOF> Oh, that's right. I didn't actually hook up the framedropping bit yet.
<RAOF> That would be why the tests are failing.
<alan_g> alf_: I don't have glmark2-es2-mir on my box - so I'm guessing you know if it takes a "mir server" command-line parameter?
<alf_> alan_g: it doesn't, but why not just call "MIR_SERVER=... glmark2-es2-mir"?
<alan_g> alf_: thanks. That's what I've been suggesting
<alf_> alan_g: do we know if the connection fd produced by our connector is close-on-exec? That is, will the shell and glmark2 get the fd through popen so that the can use it if MIR_SERVER=fd://... ?
<alf_> alan_g: ahh, never mind, I see Josh is unsetting "MIR_SERVER_NO_FILE"
<alan_g> alf_: it didn't used to be. (That's how --launch-client worked). I'm testing things to have a prescriptive fix.
<alf_> alan_g: but yeah, ideally it should work with fd://..., so no need for MIR_SERVER_NO_FILE
<alf_> alan_g: ...for unsetting MIR_SERVER_NO_FILE
<alan_g> alf_: that's what I expect. But something isn't working (yet) - forgive me being slow to respond - been in VT land.
<alf_> alan_g: no worries
<alan_g> alf_: it does all work as expected (when I fixed a typo).
<alf_> alan_g: great
<alan_g> alf_: I don't want to reject unilaterally - so, if you get a minute, could you review lp:~josharenson/mir/unset_server_nofile â lp:mir/devel (it is small)
<alf_> alan_g: sure
<alf_> alan_g: disapproved and rejected
<alan_g> alf_: thanks
<robjh> Hi, i was wondering if there are any examples of how to use opengl with mir?
<robjh> looks like it's just egl?
<kgunn> robjh: you should look at the examples/demos....the names "eglxxxx" just imply its an egl context...
<kgunn> those are opengles, but opengl should work
<robjh> okay, thanks
<anpok> alf_: if you still have time before eod, https://code.launchpad.net/~andreas-pokorny/mir/extended-input-dispatcher-interface/+merge/218253
<alf_> anpok: sure
<racarr__> a collection of giant trucks is refactoring the pavement on my road
<racarr__> and its pretty distracting lol
<alan_g> Take the day off and be distracted?
<ogra_> or help them :)
<racarr__> hahaha
<racarr__> "So do you guys have a failing test expressing the requirements on the new road? If so I can just dive right in"
 * ogra_ recommends fireproof underwear though ... hot tar is nasty
<ogra_> (for divin at least)
<josharenson> Any ideas why I'm suddenly receiving libboost errors when  running any mir binary? I don't think I changed anything, and I'm exporting LD_LIBRARY_PATH correctly...
<racarr__> Can someone review this today perhaps? https://code.launchpad.net/~mir-team/mir/cursor-spike-phase-2-resubmit/+merge/217685
<racarr__> Ive got more to propose ;)
<dandrader> anpok, merging lp:~andreas-pokorny/mir/input-sender-split into lp:mir/devel currently gives out conflicts
<anpok> dandrader: aye - thought I would get an updated version sooner..
<AlbertA> racarr__: reviewing now
<anpok> dandrader|afk: done
<dandrader> anpok, great. thanks!
<AlbertA> racarr__: just some small nits but looks good
<racarr__> AlbertA: Thanks, just running off to lunch but will iterate after and
<racarr__> we can land ! and propose
<racarr__> CURSOR SPIKE PHASE 3
<anpok> in full hd?
<AlbertA> 4K I believe :)
<kgunn> anpok: so to enable the shell guys...do we need https://code.launchpad.net/~andreas-pokorny/mir/first-cleanup-for-input-configuration/+merge/218583 & https://code.launchpad.net/~andreas-pokorny/mir/extended-input-dispatcher-interface/+merge/218253
<kgunn> to land
<anpok> kgunn: and more
<anpok> i take what is currently locally in the input-sender-split branch and rip out pieces that can be reviewed
<anpok> and make separate mps from that
<kgunn> anpok: ok, i see....
<kgunn> anpok: i just made it a wip branch to look at the diff
<RAOF> robjh: Note that whether or not OpenGL works is EGL-implementation-dependent; it won't work on almost all ARM devices, for example.
#ubuntu-mir 2014-05-08
<kgunn> RAOF: good point...
<RAOF> Mah, memcheck tests. Why take so long, do you?
<duflu> <memcheck> Because I have to virtualize every memory access as well as instructions :)
<RAOF> And there we go. When you don't branch on uninitialised values, the memcheck tests pass. Astounding!
<racarr__> Sure but if you dont branch on unitialized values then what fun is left in coding.
 * duflu writes that down
<racarr__> lol
<duflu> I thought that if non-determinism works for the wider universe it must be the right way to code
<alf_> duflu: it does if you can the select the resulting reality that you prefer ;)
<duflu> alf_: Ah. So I'm running it on the wrong platform. Requires multiverse
<alf_> lol
<racarr__> Morning alf :)
<alf_> racarr__: Good night :)
<racarr__> aha any minute now...
<racarr__> debugging a chromium crash while I wait for the daily show to appear...on...my legal video streaming site *nods*
<racarr__> actually right now im just waiting for GDB to load symbols...
<racarr__> THEN sleep
 * RAOF should really file a bug about gdb SIGSEGVing everytime I try to dereference a shared_ptr<>
<racarr__> I think our button events
<racarr__> could be improved
<racarr__> the thing is you get "current button state"
<racarr__> plus is this an up or down event
<racarr__> so everyone has to keep track of
<racarr__> button states
<racarr__> well in particular, what X and chromium want is "this button up/down" not "new button state"
<racarr__> so the adapter layer has to keep track of button state
<racarr__> and
<racarr__> we only have a few buttons and
<racarr__> its a disaster of a button event.
<racarr__> lol that was un fair...but it does have room for improvement ;)
<RAOF> racarr__: I think that all our events need to have some pretty drastic surgery done on them.
<anpok> yes
<RAOF> They manage to be simultaneously verbose and not expressive enough.
<anpok> and not capturing everything needed
<RAOF> Right (not expressive enough)
<anpok> oh
<anpok> meant expressive in terms of making clear what is going on -> hint: MirEvent.motion.action & FunkyMask
<RAOF> Oh, that too.
<RAOF> Hm. What happened to lp:mir/devel r1544.52.1?
<RAOF> Specifically, why can't I list its history?
<alf_> duflu: alan_g: @1317370, is this under valgrind?
<alan_g> alf_: no
<duflu> alan_g: Might be a better idea to leave more specific bugs open and fix them individually. The older one would take more effort to resolve entirely. Also 1317370 is only new in v0.2.0
<alf_> duflu: on what hardward does it take 10 seconds?
<alan_g> duflu: I wouldn't object to that provided there are adequate cross-references
<duflu> alf_: Haswell i7 quad core desktop :)
<duflu> up to 20 seconds
<alf_> duflu: hmm, on my i5 laptop it takes 3-4 max
<duflu> Weird. Lemme check if it's a side-effect of previous ones
<alan_g> I've seen a lot of variation in the time for that one
<duflu> That's a bit curious that variation
 * alan_g is suspicious of "unit" tests that take more than milliseconds
<duflu> alf_: Yes it happens in isolation too. Up to 25.5 sec
<duflu> Only that test BufferQueueTest.compositor_never_owns_client_buffers
<alf_> duflu: alan_g: actually, for me, the whole BufferQueue test suite takes 3-4 secs, BufferQueueTest.compositor_never_owns_client_buffers takes about 150ms...
<duflu> alf_: Maybe you need more speed to make it race or something?
<alf_> alan_g: can you reproduce the slow test runtime?
<alf_> anpok: ^^ ?
<anpok> 10 secs to 15 secs
<duflu> alf_: It's not a big deal. If it's just me I'll look into it later
<alf_> anpok: what hardware?
<alf_> duflu: I am just curious about the difference...
<duflu> Sounds like a race. But I'm exercising discipline and not looking into it myself
<alf_> duflu: hmm, my test builds are not optimized I see, let me try with "Release"
<anpok> i7 quad core .. 4750
<duflu> i7-4770 does it too
<anpok> the BufferQueueTest.stress test usually takes about 2.6 seconds
<alf_> anpok: is 10-15 seconds the time for the whole BufferQueueTest.* run or just for BufferQueueTest.compositor_never_owns_client_buffers ?
<alan_g> Running repeatedly I got:
<alan_g> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::logic_error> >'
<alan_g>   what():  unexpected release: buffer was not given to compositor
<anpok> just for the never_owns_client_buffers
<anpok> but 15 secs is like the rare max .. and 10 is the avarage
<alan_g> Suggests there's racy code
<duflu> alan_g: Yeah, never look too hard. You'll always find more bugs
<alan_g> Yep
<duflu> and helgrind says?... surely something helpful
<duflu> But I must look away for now
<anpok> hm there were some intersting talks about haswells performance and compiler optimizations in going native 2013
<anpok> release binary is wors
<anpok> e
<anpok> 30 seconds
<anpok> and 38s ..
<anpok> enough testing bbiab
 * alan_g puts on list to look at later // gives other people the chance to look first and save me from it
<duflu> alan_g: I'm working roughly in the same area. Notice this reference looks racy (potentially used unlocked):
<duflu>     auto const& acquired_buffer = buffer_for(current_compositor_buffer, buffers);
<duflu>     if (buffer_to_release)
<duflu>         release(buffer_to_release, std::move(lock));
<duflu>     return acquired_buffer;
<duflu> That would result in the exception you saw, I think
<alan_g> duflu: that is plausible (needs testing of course)
<duflu> Hah. One of those days when the algorithm was right first time and it took me hours to understand the problem thereafter
<anpok> alan_g|lunch: yup it worked.
<alan_g> anpok: I like it when we can fix overcomplicated code. \o/
<anpok> me too
<anpok> hm if no test needs a stub header..
<anpok> should it exist then
<anpok> or is it a warning sign that we are lacking a test
<alan_g> anpok: or both?
<alan_g> anpok: re-reviewed. Just nits to fix AFAICS
<kgunn> alf__: ok, i feel goofy...i'm doing something wrong, i flashed a fresh image, installed glmark2 debs (manually) from staging ppa, did 'stop unity8', made mir socket 777 and ran glmark2-es2-mir...but got "Couldn't connect to the Mir display server"
<kgunn> just tried with sudo and got "Failed to create Mir surface!"
<alf__> kgunn: let me try
<alf__> kgunn: so devel-proposed?
<kgunn> alf__: yep
<alan_g> kgunn: Tried setting $MIR_SERVER to the endpoint? (No need for sudo for it to be the same then)
<alan_g> Oh, and starting the Mir server. ;)
 * alan_g is being nagged to reboot. BRB
<kgunn> alf__: ah-ha...i think the screen was blanked
<kgunn> working now
<alf__> kgunn: :)
<AlbertA> mterry: ping
<mterry> AlbertA, hello
<AlbertA> mterry: got a question for the split greeter
<AlbertA> mterry: does it only require global alpha support? not per-pixel?
<AlbertA> mterry: I would assume global only (i.e. surface->alpha())
<mterry> AlbertA, I'm not sure I follow the question, but it has it's background be full alpha, then it has a sliding screen on top of that
<AlbertA> mterry: ok so the other session shows through as the screen slides?
<mterry> AlbertA, exactly
<AlbertA> mterry: ok thanks!
<AlbertA> mterry: so right now the surface it uses is fullscreen with transparent background?
<mterry> AlbertA, yeah
<AlbertA> mterry: ok... just trying to figure out how to fix the mir GLRenderer
<alf__> alan_g: any more thoughts on main-loop-post-actions?
<alan_g> alf__: not yet.
<alf__> alan_g: ok
<alan_g> I'll take another look before standup
<alf__> alan_g: thanks
<alan_g> dednick: does this have everything you need from it? https://code.launchpad.net/~alan-griffiths/mir/spike-passing-out-client-fds/+merge/218629
<alan_g> alf__: done. Are you happy with passing-out-client-fds now?
<anpok> alan_g: all addressed - apart from compositor::Scene
<alf__> alan_g: yes, approved
<dednick> alan_g: seems to. i'm just trying it out now with my branch; but i'm having some linking issues
<dednick> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
<dednick>   what():  /usr/lib/arm-linux-gnueabihf/mir/platformgraphics/android/libmirplatformgraphics.so: undefined symbol: _ZN3mir8graphics9GLProgramD1Ev
<alan_g> dednick: that *sounds* like a problem AlbertA fixed on devel yesterday.
<alan_g> You ought to be able to "cherry pick"
<alan_g> It's -r 1609 on devel
<dednick> alan_g: ah. ok, i'll take a look
<alan_g> dednick: if it helps I've just sync'd the branch with devel.
<dednick> alan_g: got it working thanks
<dednick> alan_g: could probably do with a rpc report for new_fds_for_trusted_clients
<dednick> alan_g: as the one i asked for in the client is returning fd=0 which sounds a bit dubious.
<alan_g> dednick: hmm
<dednick> alan_g: it's probably my code
<alan_g> dednick: sorry (got distracted)
<alan_g> $ MIR_CLIENT_RPC_REPORT=log bin/mir_acceptance_tests --gtest_filter=TrustSessionHelper.gets_fds_for_trusted_clients
<alan_g> ...
<alan_g> [1399565480.978169] (DD) rpc: File descriptors received: 24 25 26
<alan_g> ...
<alan_g> Looks sane to me
<dednick> alan_g: hm. ok. is it normal that they're always the same when i run an app?
<dednick> no idea how it works
<alan_g> well, typically fds are allocated in numerical order
<alan_g> Within the process that is
<alan_g> So if you your clients always have the same number of files open when you run you'll see the same number
<dednick> alan_g: but if they're the same accoss clients, then how does another client connect to the fd?
<alan_g> dednick: child processes inherit their environment from the parent. Including (with various provisos) FDs
<dednick> alan_g: ah. ok
<dednick> alan_g: when i call new_fds_for_trusted_clients, i get a SessionAuthorizer::connection_is_allowed for the mir server process.
<alan_g> dednick: that's decribed in bug 1314574
<ubot5> bug 1314574 in Mir "The client process is identified when the socket connects, not when the client connects to Mir" [Undecided,New] https://launchpad.net/bugs/1314574
<dednick> ah. i thought it would be the process that created the socket.
<alan_g> Which reminds me to update the status (as I've started on it)
<alan_g> dednick: it is the process that created the socket
<alan_g> The socket is created on the server and then migrated to the trust helper and inherited by the client
<alan_g> Really simple if you don't think about it. ;^)
<dednick> presumably i have to authorise the session though :)
<dednick> s/session/connection
<alan_g> yes. And (until I fix the bug) that pid will get propagated to the session too.
<alan_g> dednick: I'm getting to EOD - is there anything more you need?
<dednick> alan_g: think i'm good for now thanks
<anpok> alf__: hm wrt WaitObject WatchDog ..
<anpok> when I remove the WaitObject parts from WatchDog.. can I still call it WatchDog?
<anpok> or is WatchDog IS A WaitObject the solution hmm
<AlbertA> anpok: there are some cases where you can just use auto_unblock_thread instead of watchdog
<AlbertA> anpok: RAOF said they were equivalent: https://code.launchpad.net/~albaguirre/mir/cleanup-switching-bundle-unit-tests/+merge/217534/comments/517495
<AlbertA> anpok: so perhaps just change it to AutoUnblockThread and/or AutoJoinThread instead?
<anpok> ack
<dandrader> are there environment variables to enable debug logging on a mir client?
<RAOF> anpok: I'm removing WatchDog from the 1Hz-rendering branch.
#ubuntu-mir 2014-05-09
<RAOF> Ok, that's a bit annoying. gdb now segfaults trying to read debugging symbols from mir_unit_tests
 * RAOF heads due luncheon
<kgunn> ok, realized i've never done this...if i run mir_demo_server_basic on vt1 and i want to kill it, how would i do that?
<kgunn> duflu: RAOF ^ ?
<duflu> kgunn: Firstly, server_shell is much cooler :) Secondly remember to sudo or else Mir doesn't have input (quit) support - https://bugs.launchpad.net/mir/+bug/1286252
<ubot5> Ubuntu bug 1286252 in Mir "mir_demo_server* successfully start as non-root (without input support), meaning it can't be quit/switched away from" [Medium,Confirmed]
<duflu> kgunn: Once you have input support it's Ctrl+Alt+Backspace
<kgunn> duflu: ah, i did sudo....
<duflu> That reminds me, I wanted to move some common logic like that into the server library and let shells override it. It's annoying every demo shell should have to re-implement something as basic as quitting
<duflu> (because mir_demo_server_minimal is unquitable, I think)
<duflu> Oops. Quit the wrong shell?
<RAOF> anpok_: Are you planning to try and land https://code.launchpad.net/~andreas-pokorny/mir/add-timer-to-main-loop/+merge/216881 anytime soon, or should I un-depend-upon it in 1Hz-rendering?
<RAOF> Oooh! Oooh! Oooh! There's a new button on Launchpad reviews, âShow inline commentsâ!
<duflu> Wha?!
<RAOF> There's no ability to comment inline yet, but the first parts of that series are landing.
<RAOF> Yay!
<duflu> RAOF: Heh, yeah I was trying to figure out how to make one
<duflu> What would also be really nice is side-by-side diffs
<duflu> In my experience they're much better for code review
<RAOF> Hm. Dumping the diff into meld would be pretty cool, yeah.
<RAOF> That would probably be pretty easy to do, actually.
<anpok> RAOF: i thought about doing so now, but havent started workin on that
<RAOF> anpok: Well, sometime would be nice, as 1Hz-rendering depends on it.
<duflu> RAOF: (1) Happy weekend. else (2) Please check again: https://code.launchpad.net/~vanvugt/mir/simplify-BufferQueue/+merge/218794
<RAOF> duflu: Doing so :)
<RAOF> duflu: It seems that the uniqueness constraint could be satisfied in a less invasive way.
<duflu> RAOF: You mean more exhaustive? I'd rather simplify and shrink the code before reconsidering unnecessary micro-optimizations
<RAOF> I don't suppose you've got a test for this?
<duflu> RAOF: It can't really be tested. The symptom is memory bloat of a private member... that is never leaked
<duflu> You can observe and test it externally, obviously
<duflu> I'll do another alt fix proposal
<duflu> I've come to not expect anything to land, so I work on many different things at once :)
<RAOF> You could measure memory use over thousands of compositor_acquire/compositor_release cycles, if nothing else :)
<duflu> RAOF: fprintf tells me the vector is huge... I don't really need any more info
<duflu> Hmm, a "smaller" fix actually isn't working
<RAOF> But you can't run an fprintf test on every commit :)
<duflu> RAOF: I don't intend to. Very few performance bugs get regression tests in general. Although I did manage with a bunch of SwitchingBundle issues before...
<duflu> Also memory bloat is an issue most programmers never consider. They think not leaking is enough... but really you need to do real external system testing
<RAOF> I'm still not sure why this isn't a proper target for an automated test?
<duflu> RAOF: Hmm, could just set a time limit on the existing test and fail I guess
<duflu> That would do it, but only on a small subset of system
<duflu> Heh. I never intended to fix any bugs with this proposal
<duflu> It just happened
<RAOF> Parse /proc/self/status, check RSS isn't increasing over thousands of compositor cycles? :)
<alan_g> Put a "reasonable" limit on the size and assert? Or add a query to report the queue sizes that can be checked in unit test?
<duflu> alan_g: I think that's a case of testing the known cause, when a fix would eliminate the test. I'm trying for a different test that would remain valid regardless of the implementation
<alan_g> duflu: I know but lacking a generic option it is better than no test.
<duflu> alan_g: I might have a generic options. On the other hand, I don't think any or all memory bloat problems have internal testing. It's really an external thing usually
<RAOF> Parsing /proc/self/smaps would get you a pretty good âam I using more memory by doing this thing over and overâ test.
<RAOF> This sounds like something that might be good for mir_test{,_framework}, actually.
<alan_g> RAOF: that sort of thing is probably more appropriate in the acceptance/stress/performance tests
<alan_g> yes
<RAOF> Anyway, EOW for me!
<alan_g> dednick: do you approve https://code.launchpad.net/~alan-griffiths/mir/spike-passing-out-client-fds/+merge/218629?
<alan_g> Or are there still problems using it?
<dednick> alan_g: got it working with trust sessions after you left last night. just approved
<alan_g> Great!
<duflu> alan_g: I'm seeing it too now. If you want to take over this, please do: https://bugs.launchpad.net/mir/+bug/1317801
<ubot5> Ubuntu bug 1317801 in Mir "[regression] [BufferQueue] BufferQueueTest.compositor_never_owns_client_buffers occasionally crashes with: what(): unexpected release: buffer was not given to compositor" [High,In progress]
<alan_g> duflu: ack - not sure I'll get to it this week though
<duflu> alan_g: Sure. Just mentioning in case you do. Otherwise my Monday comes sooner
<alf__> duflu: I may be able to take it over today, I will reassign is so
<alf__> s/is/if/
<duflu> alf__: That would be good too
<duflu> I got way too ambitious in the number of fixes I could get landed
<duflu> Need to share the love a bit more
<duflu> On the upside, not making progress gives me a clean slate for the weekend. Till next time...
<anpok> AlbertA: any reason why you wrote for-loops instead of auto pos = find(begin(..),end(..),item).. in the buffer queue?
<anpok> I mean was that based on the profilings?
<AlbertA> anpok: yeah they did better in profiling and std::find and iterators
<anpok> ok, i assumed those would be identical for somehing like vector
<AlbertA> anpok: there's a small overhead when constructing iterators at least on gcc/glibc
<AlbertA> anpok: so since the number of elements is small - the overhead in comparison is significant
<seb128> hey Mir team
<seb128> I've a dell inspiron 11 laptop, which has a touch screen, testing unity8/Mir on trusty ... things run fine but the touch screen doesn't work
<seb128> is that a known issue/limitation?
<racarr__> Morning
<seb128> hey racarr__, how are you?
<alan_g> seb128: racarr__ probably knows that part of the stack best.
<racarr__> seb128: Oh pretty good! You?
<seb128> I'm good thanks!
<racarr__> re: the touch screen...hmm...no one has one
<racarr__> so its hard to say
<racarr__> its not exactly expected to ork in that anyone has tried it
<racarr__> but I dont know why it wouldn't work...
<racarr__> someone has used a laptop touchscreen with success
<racarr__> maybe olli
<racarr__> so there must just be some sort of quirk or something
<racarr__> seb128: If you want to dig deeper MIR_SERVER_LEGACY_INPUT_REPORT=log MIR_SERVER_INPUT_REPORT=log could have something
<seb128> k
<racarr__> (export them as env variables in the environment unity system compositor is in)
<seb128> <bregma>	seb128, your hardware may need to be defined as an Android touch device for Mir to recognize it properly
<seb128> <bregma>	all of mine work out of the box now, but initially I had to create a file somewhere with hexadecimal device IDs in the title, can;t recall the details....
<seb128> <bregma>	I'll need to dig that up
<seb128>  
<seb128> is that what I've been told yesterday
<seb128> so I figured that you guys might know more about that ;-)
<racarr__> seb128: yes there are these ".idc" files
<racarr__> I  have never touched the code or one though so im not sure...
<racarr__> thats a good idea though
<bregma> yeah, .idc files, that's it
<racarr__> some community guy porting a device...that was his f
<racarr__> ix
<racarr__> when his touchscreen didnt work
<racarr__> um I can look in to it after standup. or you can probably find one on your phone
<seb128> I'm fine hacking it locally
<bregma> some touchscreens are not recognized as such because, well, hardware is flaky, so they need an IDC file to force the issue
<seb128> but that would be nice if those stuff were working out of the box
<seb128> normal users are not going to go figure that out
<seb128> well, the touchscreen is working fine under Xorg/unity7
<seb128> so somehow it's recognized correctly
<seb128> just not by Mir
<tedg> Do we get a compose key for free in Mir, or is that something we'll have to do ourselves?
<racarr__> I dunno, we might get it for free from XKB
<AlbertA> anpok: so assuming we change to pre-multiplied alpha
<anpok> AlbertA: where are we using the suspicious masking - or rather
<anpok> why does the issue not occur on the framebuffer?
<anpok> is the blending function for a normal display buffer different than for screen casing?
<anpok> *casting
<AlbertA> anpok: no it's the same
<AlbertA> anpok: but assuming we change the blending function -
<anpok> ah the scanout fixes it..
<AlbertA> anpok: there's still the issue that nested servers
<anpok> hm but over-blending with premultiplied should be associative
<AlbertA> anpok: would like to specify the final alpha value in the framebuffer
<anpok> well the initial one has to be zero
<AlbertA> anpok: for per-pixel alpha transitions between sessions
<anpok> hm you mean the nested session want to do direct alpha writes?
<anpok> *wants
<AlbertA> anpok: well somehow...the main thing is supporting per-pixel alpha transition effects
<anpok> i thought for our use cases we start with zero and just combine blend one over the other..
<anpok> could you explain more
<AlbertA> anpok: what do you mean start with zero
<AlbertA> anpok: alpha zero as background you mean?
<anpok> clear the frame buffer on usc, and every nested session that has an alpha channel to rgba=0,0,0,0
<anpok> yes
<AlbertA> anpok: ok, yeah that's what we kinda do
<anpok> so if the the normal blend mode (1,1-alpha) is not enough, we might have to extend the api
<anpok> so I think (alpha,1-alpha) is just wrong
<anpok> i mean we could extend the api to override the normal blending with other modes
<anpok> ah something like nv_blend_equation_advanced
<AlbertA> anpok: I suppose that in the nested case the resulting surface will have pre-multiplied rgb components
<anpok> yes
<AlbertA> anpok: and I suppose the QT renderer will produce the same as well
<AlbertA> anpok: so yeah I can see we need to assume pre-multiplied alpha
<anpok> hm we have to places, the demo_renderer and the gl_renderer
<AlbertA> anpok: right
<anpok> looking forward to the review :)
<anpok> we even have a test case that requires current behavior
<AlbertA> anpok: what do you mean?
<anpok> the test case of gl_renderer is kind of .. odd
<anpok> whenever you change something there you have to update the test case
<anpok> i mean, you cannot change it without breaking the unit test
<anpok> ah with review - i meant that I expect further comments with regard to alpha usage in gernal
<anpok> hm the round corners of the window decoration look strange now
<AlbertA> anpok: ummm, actually now that I think about it...you can change the surface global alpha
<AlbertA> anpok: which means we can't assume pre-multiplied either
<racarr__> gonna top approve https://code.launchpad.net/~mir-team/mir/cursor-spike-phase-2-resubmit/+merge/217685
<racarr__> soon
<AlbertA> anpok: I suppose we could change the shader to make it so...but doesn't seem right
<racarr__> unless anyone else wants to weigh in on MirCursor v. MirCursorConfiguration
<anpok> racarr__: text conflicts?
<racarr__> damn
<racarr__> so close
<anpok> AlbertA: hm i think we have to
<racarr__> ok fixing
<racarr__> I honestly cant believe how dumb merge algorithms are
<racarr__> I mean
<racarr__> I can because they are very easy to understand
<racarr__> its just annoying
<anpok> there is a project that tries to provide a more semantic merge
<racarr__> I have seen some lately (Though only proprietary)
<racarr__> im really excited
<anpok> does the merge on a whole program representation
<racarr__> yeah
<anpok> i.e. the one i read about was limited to c# for now
<AlbertA> anpok: yeah I see if we need to support correct alpha values in the framebuffer (for nested) I don't see a way
<AlbertA> anpok: around pre-multiplied assumption
<anpok> yes
<anpok> AlbertA: if we dont do that we will be haunte by porte&duff
<anpok> *porter
<anpok> *haunted
<AlbertA> right
<AlbertA> :)
<racarr__> it would be a really fun problem to hack on (semantic merge)
<anpok> hm we have clang now
<anpok> and there is a python libclang wrapper
<anpok> and you could make it learn from existing merges in the history of the project..
<racarr__> haha. thats an even more fun problem
<anpok> i.e. if dev a integrates code of dev b and there is conflict
<racarr__> I was thinking you could jut come up with
<anpok> always take dev a.. or something..
<racarr__> lots of hardcoded scenarios
<racarr__> that would solve most dumb problems
<anpok> ok
<racarr__> i.e. a class definition gains
<racarr__> two method declarations
<racarr__> at the same line
<racarr__> isnt a conflict :p
<racarr__> its just two people adding a method to a class
<anpok> but in different order
<racarr__> well right, somethings the order does matter, whereas if two developers put a method definition in a class
<racarr__> at the same time
<racarr__> its probably just fine to put the one that was added latter (in terms of timestamp) on the line after
<racarr__> sometimes*
<anpok> AlbertA: ah that would just be frag*alpha in the shader
<anpok> it looks like someone did that on purpose the way it is done now
<anpok> and thats good
<AlbertA> anpok: right the issue is how do you know which sources are pre-mutiplied already
<AlbertA> anpok: and which ones aren't
<AlbertA> anpok: what's in the shader currently is only to handle global alpha
<anpok> hm right now all our client surface are.. but most of them have alpha=1 so we do not notice the difference
<AlbertA> anpok: :) he yeah I guess if we look at it that way...
<anpok> if fingerpait would bitblt an rpba png image wihout telling lpng to premultiply
<anpok> i guess then we would have that case
<anpok> (can libpng do that?)
<AlbertA> anpok: not sure...
<AlbertA> anpok: but yeah I guess we don't change the shader
<AlbertA> anpok: or rather
<anpok> why not?
<AlbertA> anpok: I mean yeah change the shader but correctly compute the global alpha and just assume
<anpok> ah o
<anpok> k
<AlbertA> anpok: the source is already pre-multiplied
<rsalveti> kgunn: glmark2 just got approved
<rsalveti> should be migrated soon
<kgunn> \o/ thanks much rsalveti ... josharenson ^
<anpok> AlbertA: do you understand how the top decorations are drawn in the demo renderer
<AlbertA> anpok: the title bar?
<anpok> yeah, hm the part that should be cut off just started to get shine in the colors of the rainbow
<anpok> -to get
<anpok> there is something wrong
<AlbertA> anpok: oh really? I'm not seeing that...you mean with the tip of mir devel?
<anpok> if you swith to porter&duff over blending, then the top  corners of the window are not properly cut off
<AlbertA> ahhh...
<anpok> but thats an error in the code that draws the decoration
<AlbertA> saturation?
<AlbertA> or maybe overflow
<AlbertA> wrapping around
<anpok> it does if(at corner) { if(in above cricle) { cancel } }  if(cy<y) { shade )
<anpok> but it should be
<anpok> it does if(at corner && (in above cricle) { cancel } else  if(cy<y) { shade )
<anpok> demo_renderer.cpp:98
<anpok> hm still strange
<anpok> ah yes it is a wonderful case of non premultiplied
<anpok> as it only sets the alpha value but does not multiply it to the rgb
<anpok> AlbertA: will you create an MP?
<josharenson> yes thanks rsalveti... So I can look for it in universe in a few days?
<rsalveti> josharenson: yeah, probably later today
<rsalveti> https://launchpad.net/ubuntu/+source/glmark2
<rsalveti> once it migrates from proposed to release
<anpok> racarr__: you mean you need someone to top approve?
<racarr__> anpok: Ah well I was going to do so
<racarr__> I just wanted to
<racarr__> submit the suggestion to the academy before doing so
<racarr__> :p
<anpok> heh
<anpok> discussion there seems to be at a dead end
<anpok> agreement about an overall disagreement..
<anpok> in any case you might want to look at https://code.launchpad.net/~andreas-pokorny/mir/drop-dynamic-ptr-cast-in-input-configuration/+merge/218806
<anpok> since you are browsing right now..
<anpok> maybe i should wait for monday
<racarr__> anpok: Ill try and look in just a few min
<tedg> Is there an API for the trusted sessions somewhere?
<AlbertA> anpok: yeah I will create it...right now I'm mostly concerned about getting unity8 just to work right
<AlbertA> anpok: I could propose later to fix the support for transparent frame buffers
<AlbertA> anpok: because switching to porter/duff is practically only applicable to nested usecase
<AlbertA> anpok: where corrrect alpha is needed
<AlbertA> anpok: in all other cases including screencasting there's no need
<anpok> AlbertA: hmm... right now we do apply the alpha channel twice
<AlbertA> anpok: but as you said, right now unity8 is rendering with alpha 1.0 so it doesn't matter
<anpok> yes
<AlbertA> anpok: it only matters in the demo shell I suppose
<anpok> and potential transparency effects in the greeter some day
<AlbertA> anpok: right
<AlbertA> anpok: so maybe for now my initial fix of rendering an opaque background is enough (so that unity8 renders correctly)
<AlbertA> anpok: then we can open the alpha can-of-worms
<AlbertA> anpok: :)
<anpok> first or second one?
<anpok> confused
<AlbertA> anpok: I think https://code.launchpad.net/~albaguirre/mir/render-opaque-background/+merge/218712
<AlbertA> anpok: is the simples solution for now for both the transparent screencast issue and the unity8 rendering issue
<AlbertA> anpok: and then we need a discussion on supporting transparent framebuffers properly
<AlbertA> anpok: I think probably an attribute of the DisplayBuffer so we can change
<AlbertA> anpok: blening modes in the renderer could be the solution
<AlbertA> anpok: maybe an opaqueness attribute
<AlbertA> anpok: that the compositor can pass to the GLRenderer
<anpok> ack
<AlbertA> anpok: yeah an opaqueness attribute makes sense to me...that way we say non-opaque on the nested display buffer
<AlbertA> anpok: and everything else opaque
<AlbertA> anpok: i.e. the platform's display buffer and the screencast display buffer
<anpok> well we have the pixel format
<AlbertA> anpok: true but for some reason
<AlbertA> anpok: the platforms are returning one with alpha support
<anpok> ah yes
<AlbertA> anpok: dunno why...and the nested display buffer just replicates that
<anpok> and independent of that if the clients of the nested session make use of transparency we still have to blend properly
<AlbertA> anpok: right which we haven't seen since nobody is rendering with per-pixel alpha at the mir level
<AlbertA> anpok: it's all done by Qt...I wonder how they blend
 * AlbertA goes to check
<AlbertA> anpok: glBlendFunc(GL_SRC_ALPHA, GL_ONE);
<AlbertA> anpok: which I suppose makes sense, always make the destination opaque
<AlbertA> anpok: well I'm not sure that's what they use---just found some hints here and there
<anpok> thats odd
<AlbertA> anpok: no nevermind one of the comments alludes to
<AlbertA> glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA)
<AlbertA> in qsgrendernode.cpp
<AlbertA> all makes sense now
<AlbertA> :)
<anpok> http://home.comcast.net/~tom_forsyth/blog.wiki.html#[[Premultiplied%20alpha]] -- So anyway, yeah, premultiplied alpha. Use it, love it, pass it on. Then maybe we'll only take another 20 years til everyone's doing this stuff correctly.
<anpok> good
<josharenson> kgunn, it appears as though you cannot run glmark2 offscreen on android
#ubuntu-mir 2014-05-10
<frecel_> Is it possible to not allow screenshots to be taken of an application with mir on ubuntu touch?
#ubuntu-mir 2015-05-04
<duflu> RAOF: 'make test' is now very terse. Is that what the fans want?
<RAOF> âmake testâ has been very terse where it matters for *ages*
<RAOF> The fans want make ptest, anyway.
<duflu> RAOF: Like 20 lines terse?
<RAOF> duflu: Indeed, like 20 lines terse.
<RAOF> You only get interesting output on CI because we pass ARGS=-V to make test.
<duflu> Meh, it was never a useful level of zoom anyway
 * RAOF would prefer to have parallel tests *always* run, because that means parallel failures will largely be caught in CI, but that's apparently difficult.
<RAOF> duflu: Anyway, would MirReference rather than MirSurfaceId satisfy your nomenclature concerns?
<duflu> RAOF: Sure, but don't ask mako to. It might asplode
<RAOF> Libtypo??
<duflu> RAOF: "MirReference" was a worse name. "Signature" or "Fingerprint" would be OK. I prefer "Signature"
<duflu> RAOF: libtypo was called "gltext" during its development. Then at the last minute I found such a thing already existed and would be quite confusing so renamed
<RAOF> And characters are a precious resource, so âtypographyâ was rejected? :P
<duflu> RAOF: Yes, we are programmers, humans and Australians. All three prefer shorter names
<RAOF> I dislike both Signature and Fingerprint. Neither of those tell me that I can use it to refer to a specific object.
<RAOF> Both Signature and Fingerprint sound like verification mechanisms rather than reference mechanisms.
<duflu> RAOF: "Reference" is too overloaded in programming circles. Best to not re-overload that word
<RAOF> I... disagree.
<RAOF> I think that the common use of Reference exactly describes what a MirReference is.
<duflu> RAOF: In the English sense yes. But in the programming sense existing meanings of "Reference" take precedence
<duflu> And there are already too many
<RAOF> I think that this *is* the programming meaning of Reference.
<RAOF> <shrug>
<duflu> RAOF: Well I don't want this to become yet another case of "please rename" resulting in a worse outcome than where we started so stay on MirSurfaceId till a better word is conceived I guess
<duflu> To this list of nouns
<duflu> Hmm it's becoming a little too easy to crash the drm kernel module in vivid
<duflu> But since it's 6pm that tells me to give up for now
<anpok> oh yes
<anpok> 4.1 is not much better
<duflu> alf_: Fun fact: I just noticed buffers_sent_to_compositor can contain a buffer multiple times even in a single compositor environment. So if the client misses a frame deadline, that amplifies and makes it even less likely we'll return to the client in time
<duflu> This might be an entirely new bug
<anpok> just had an interesting i915 kernel message and after that just one core left .. or 1/8 of the processing power
<alf_> anpok: Are you using a custom kernel with vivid (4.x)?
<alf_> anpok: I see vivid has 3.19.x by default
<anpok> yes
<anpok> hm cannot remember what made me switch to 4.0
<anpok> but with 4.0 i915 crashes as soon as we do the vt switch
<anpok> 4.1 fixes that
<anpok> maybe i have to go backwards to solve those troubles
<anpok> alf_: i am using the kernel from the mainline kernel ppa
<alf_> anpok: ok
<alf_> anpok: After calling input_manager->start() and input_dispatcher->start() is there a guarantee that the input subsystem is 100% up and running?
<alf_> anpok: or are there asynchronous operations taking place
<anpok> alf_: nope
<anpok> start does not wait unti the thread is started
<anpok> so the first thing that happens after start() completes is a device scan..
<alf_> anpok: is it feasible to change the code to provide that guarantee?
<anpok> hm yes you basically could have a promise.set_value right after the legacy_dispatchable->dispatch..
<anpok> within ::starT()
<anpok> which is the first device scan
<anpok> alf_: but I am not sure how long that take.. is there a problem?
<alf_> anpok: The problem is that there is no way to tell when the server has *really* started. It's mostly a problem for tests (e.g. the end-to-end input tests I am looking into) at the moment, but even for production it would be nice to guarantee that when the socket appears the server is 100% up and running.
<anpok> hm but instead of blocking we could do something different..
<anpok> send some .. trigger back to main_loop..
<anpok> so that the compositors and input may start in parallel..
<alf_> anpok: At the moment, the compositor starts first and blocks until its threads are up and running. We could return an std::future<> from both compositor->start() and input*->start() and allow them to start up in parallel if needed.
<anpok> right
<anpok> alf_: hmm will you make an mp for that?
<anpok> i just realized that I will run into that in the next fixture I wanted to update
<alf_> anpok: I was planning to start working on these tasks... do you have any concerns?
<anpok> no I am kind of cleanin up the test fixtures .. cleaning out fake_event_hub..
<anpok> alf_: no concerns, just wasnt sure if you would do it.. or expect someone to do it :)
<alf_> kdub: "the document" refers to a proposal about the power-management architecture (powerd etc)
<kdub> ah, yes thanks
#ubuntu-mir 2015-05-05
<robert_ancell> Was any Mir API reverted from vivid? I'm trying to work out how XMir compiled using mir_buffer_stream_release_sync but libmirclient-dev doesn't contain this (trunk does)
<RAOF> I don't think mir_buffer_stream made it into vivid?
<RAOF> robert_ancell: Yeah, Maarten was developing against trunk, not vivid.
<robert_ancell> RAOF, but the PPA built somehow and it doesn't contain a newer version of Mir. So I guess he had a newer version of Mir at some point in there?!
<RAOF> robert_ancell: Maybe? That PPA doesn't have a dependency on one of the Mir landing PPAs, does it?
<robert_ancell> RAOF, oh, where would show that?
<RAOF> What's the PPA address?
<robert_ancell> https://launchpad.net/~mlankhorst/+archive/ubuntu/ppa
<robert_ancell> I can't see any dependency there
<RAOF> robert_ancell: Looks like the mir_buffer_stream calls are conditionally built.
<RAOF> robert_ancell: So the PPA would have built without cursor change support.
<robert_ancell> RAOF, but the condition only checks the existence of mir_toolkit/mir_buffer_stream.h, it doesn't know it doesn't have the API
<robert_ancell> I'm rebuilding it here (with debugging symbols) and it's failing to build
<RAOF> robert_ancell: I see it #ifdef based on MIR_TOOLKIT_MIR_BUFFER_STREAM_H_?
<robert_ancell> RAOF, yes. And that is defined in the vivid header
<RAOF> Really?
<robert_ancell>  grep MIR_TOOLKIT_MIR_BUFFER_STREAM_H_  /usr/include/mirclient/mir_toolkit/mir_buffer_stream.h
<robert_ancell> #ifndef MIR_TOOLKIT_MIR_BUFFER_STREAM_H_
<robert_ancell> #define MIR_TOOLKIT_MIR_BUFFER_STREAM_H_
<robert_ancell> #endif // MIR_TOOLKIT_MIR_BUFFER_STREAM_H_
<RAOF> You have a locally installed mir_buffer_stream.h
<robert_ancell> ?
<RAOF> /usr/include/mirclient/mir_toolkit/mir_buffer_stream.h is *not* in the vivid libmirclient-dev
<robert_ancell> Oh. I have silo0 installed. It must have come in with that.
<robert_ancell> That explains things...
<duflu> Wow, bypass can hold buffers almost two frames. That should not be surprising as it is
<anpok_> alf_: why do you use a weak_ptr to the promise in ::start?
<alf_> anpok_: I want to ensure that after we leave start() (i.e. the promise value has been set by the enqueued action), any exceptions will not try to set_exception() on it
<alf_> anpok_: it's invalid to try to set the value/exception of a promise twice and there is no direct way to check if the promise is set
<anpok_> ah now i see that
<alf_> anpok_: so I resorted to this
 * racarr yawns 
<racarr> Good morning
<mibofra> oh hi racarr :D
<alan_g> anpok_: racarr - guys, can you think of anything changed in input for 0.13 that might explain AndroidInputReceiverSetup.slow_raw_input_doesnt_cause_frameskipping failing in the silo build? https://launchpadlibrarian.net/205655685/buildlog_ubuntu-vivid-armhf.mir_0.13.0%2B15.04.20150505.1-0ubuntu1_BUILDING.txt.gz
<racarr> alan_g: No. that test is actually relatively isolated iirc
<racarr> e.g. really depends just on a few classes
<racarr> my guess is its really just a race/slowness
<alan_g> racarr: The odd thing is that the failing line is EXPECT_GT(duration, 1ms); - which I wouldn't expect slowness to trigger
<alan_g> Or am I reading it wrong?
<racarr> alan_g: It looks like what it depends on
<racarr> alan_g: Is that the motion event, wont be reported when things are made dispatchable at
<racarr> l265
<racarr> because its too new so it stays batched
<racarr> so the difference between start and is > 1 ms
<racarr> because we
<racarr> slept for some amount of tiome
<racarr> waiting for an event to become ready
<racarr> however if "auto start = high_resolution_clock::now()"
<racarr> well if we get there too late
<racarr> then the motion obviously wont be too new right
<racarr> and it has to do with the
<racarr> static time stuff in the input receiver
<alan_g> Yeah, the whole premise is dubious
<racarr> and is like 15-16ms or something
<racarr> I
<racarr> am a long standing proponent that this test doesn't make sense :p
<racarr> um
<racarr> woops standup
<alan_g> I'll join you on that
<alf_> racarr: BTW, we should be using steady_clock not high_resolution_clock
<alan_g> that's the least of the problems
<racarr> camako: If you cant use non x input on non x graphics then maybe just them being in the same library is a good solution
<alf_> alan_g: Well, a few years ago this led to a week of frustrating debugging because the device used in CI changed the clock during start-up. Not saying it's the same here, but there is no reason to risk going through this again :)
<racarr> I made you guys some mps
#ubuntu-mir 2015-05-06
<robert_ancell> Any idea why glGetStringi(GL_EXTENSIONS, i) is returning NULL but glGetString (GL_EXTENSIONS) is not?
<robert_ancell> This is in silo0 and seems to be why XMir is no longer working.
<robert_ancell> Have we changed GL version at any point? (on Nexus 4)
<RAOF> robert_ancell: I don't think so?
<duflu> robert_ancell: glGetStringi is regular OpenGL, not OpenGLES. You will find it does not exist in ES (https://www.khronos.org/opengles/sdk/docs/man/). But Mesa is lazy and mixes both the APIs, so unsupported functions in ES may still be linkable, even if not functional.
<robert_ancell> Interesting
<duflu> Is you're using full OpenGL instead of ES then I don't know. But it's meant to not be present in ES
<duflu> *If
<robert_ancell> Looks like XMir is using a full OpenGL context
<robert_ancell> ah, no, that was XWayland. XMir does do both...
<duflu> robert_ancell: OK, but even on desktop it will only work with very new GPUs (OpenGL 3.0 and later): https://www.khronos.org/opengles/sdk/docs/man3/html/glGetString.xhtml
<duflu> So probably don't use that
<duflu> Ideally
<robert_ancell> duflu, it's being used in libexpoxy if it detects OpenGL 3.0
<robert_ancell> I guess this used to work fine, so not sure what changed
<duflu> Oops, that's ES 3.0
<RAOF> When you say âvery new GPUsâ, what you probably mean is âeverything from at least the last 5 yearsâ. (Mesa support is somewhat newer, obviously âº)
<duflu> RAOF: Perhaps, but Ubuntu needs to work on a lot more systems than that
<duflu> Or else we lose a very large chunk of the user base
<RAOF> I agree that there's no reason to require 3.0 support for this.
<duflu> Although I would like to build a shell in future, I don't want Unity to have such high requirements that my shell becomes a necessary fallback for lots of people
<duflu> We already see that in Unity7 where Compiz supports more GPUs than Unity does :/
<robert_ancell> gedit on the phone sure looks weird: http://imgur.com/RdxOB85
<RAOF> That looks surprisingly reasonable to me?
<robert_ancell> Just odd to see it there :)
<RAOF> With the possible exception of using a crazy-arse default theme in the absence of the usual X atoms, I guess.
<robert_ancell> Anyone remember who you have to ask to get a PPA to build ARM binaries?
<RAOF> I believe the vanguard on #launchpad can hook you up.
<robert_ancell> RAOF, on the freenode channel?
<RAOF> Yah.
<RAOF> You could probably also prod on Canonical IRC, but I don't think it's necessary.
<duflu> robert_ancell: Yeah if you could ask the GTK guys what we have to set to get the default Ubuntu theme then GTK apps on Mir would look nicer
<duflu> I suspect the packages are not installed on phone for starters :)
<duflu> light-themes
<robert_ancell> duflu, We should be able to hard-code that in to GTK+ mir
<robert_ancell> not on this phone anyway
<duflu> OTOH we could just declare we're copying the mistakes of iOS7 design, because the rest of the world did already
<duflu> (thinner fonts in GTK without the Ubuntu theme)
<duflu> robert_ancell: Also let me know if you can confirm any of these? https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bugs?field.tag=snappyrdp
 * duflu goes to get sunshine for a bit
<robert_ancell> duflu, I'm not working on GTK+ Mir at the moment, you probably want to poke attente
 * robert_ancell EOD
<duflu> I have a hunch that some simple sleep calls might make the phone smoother
<duflu> Depending on how long Unity8 holds buffers for compositing
<duflu> greyback__: It occurs to me Mir should have a report or something for how long compositor buffers are held. Do you have any idea for Unity8's performance there?
<duflu> (should have a report but doesn't)
<greyback__> duflu: such a report would be of use for me (and other mir-based compositors)
<duflu> greyback__: Yeah in the past I've just used temporary logging to get an idea
 * duflu just discovered today that bypass/overlays actually hold each buffer for almost 32ms (which is surprisingly correct)
<greyback__> I don't think unity8's code manages buffers in the most optimal way currently. I've prototyped better solutions, but numbers always help
<greyback__> numbers which I can compare with Mir would be ideal
<racarr> Morning
<camako> o/
<seb128> hey racarr
<seb128> racarr, what's the status of being able to change the physical keyboard layout under Mir/unity8 (setxkbmap style)? In Brussels you said it should be easy and you could do it in the next weeks
<racarr> seb128: There is server side API in Mir now so
<racarr> unity8 could implement per surface keymap changes
<seb128> oh, nice
<seb128> or as a first step per session one
<seb128> so it's one for the unity8 team?
<alan_g> greyback: I'm trying to build qtmir on a tablet and getting some undefined references I don't see when cross compiling. Like "/home/phablet/spike-using-WindowManager/src/modules/Unity/Application/mirbuffersgtexture.cpp:56: undefined reference to `glDeleteTextures'. Is that something you recognise?
<racarr> seb128: afaik
<racarr> alan_g: QTMIR_USE_GLES or
<racarr> alan_g: just a sec
<seb128> mzanetti, greyback, ^ do you know?
<racarr> alan_g: cmake -DUSE_OPENGLES=1
<greyback> alan_g: yeah, see the switch used in the debian/rules file
<racarr> alf_: alan_g: https://code.launchpad.net/~mir-team/mir/pluck-low-hanging-event-fruit/+merge/258213 maybe you guys can update review comments? thinking I could start landing the pipe...
<racarr> not sure if we want to get the client ABI branch up first...
<alf_> racarr: sure
 * alan_g thinks RAOF and duflu will have opinions about breaking ABI
<racarr> thanks :)
<racarr> I really like listening to the UOS summits in the background while I code...
<racarr> the smooth sounds of willcooke listing default applications
<racarr> RAOF: http://bbcamerica.tumblr.com/post/118281271151/announcing-jonathan-strange-mr-norrell I still havent gotten to reading it yet :(
<racarr> stuck in this weird book 2666 atm lol
<racarr> poor jenkins seems pretty busy...
<RAOF> racarr: Shall I bring my copy to Dallas for you? :)
#ubuntu-mir 2015-05-07
 * RAOF unplugs his external monitor, causing all Qt apps to crash (as usual).
<greyback> I really hate that
<greyback> fixed in qt5.5!
<RAOF> YAY!
<RAOF> We should go back and close those Qt bugs, then :)
<racarr> RAOF: s'ok im hooked on kindle now
<RAOF> Fair enough.
<RAOF> The physical copy is pretty nice, though ;)
<RAOF> Also, you should read it :)
<racarr> well ok if you remember :D
<racarr> yeah I will...I've been stuck on this one book for like
<racarr> almost 2 months now I guess whoops
<racarr> I think I may just give up trying to extract meaning from this long rambling middle section and
<racarr> power through lol
<racarr> "2666"
<racarr> ouch jenkins had a murder run on me
<racarr> conflicts I bet
<RAOF> :)
<RAOF> Hm. It's trying quite hard to sleet here.
<racarr> eww
<RAOF> It's failing, and just dropping very cold rain, but it's trying.
<racarr> ah phones were having network issues
<racarr> and I had a memory error
<RAOF> Always the best!
<racarr> there have been a few funny test failures
<racarr> in this event cleaning pipeline where its
<racarr> basically tests were relying on behavior that converted an invalid android event
<racarr> to an invalid mir event
<racarr> so
<racarr> so
<racarr> many
<racarr> invalid states
<duflu> racarr: Isn't that better than an invalid Android event yielding a valid Mir event? :)
<RAOF> Oops. Filesystem corruption after hard power-off.
<RAOF> You know, this code that I'm writing right now could really do with Rust's borrow checker.
<RAOF> None of these shared_ptrs are *actually* shared. I'm using guarantees about their lifetimes that are manually maintained.
<duflu> Funny thing happens when you achieve low render latency - the LCD persistence (motion blur) becomes more noticeable
<alan_g> alf_: you agree I can TA this? https://code.launchpad.net/~unity-system-compositor-team/unity-system-compositor/trunk/+merge/258047
<alf_> alan_g: approval still stands
<alan_g> Is there an easy way to find the "image number" of a phone install?
<duflu> alan_g: system-image-cli -i    ?
<alan_g> duflu: thanks
<racarr> alf_: With the pointer buttons I do mean running out of bits ... do you have another idea?
<racarr> It may be ok to say 64 bits and call it done...
<racarr> I guess what im worried about is some devices will have buttons that I guess dont correspond
<racarr> to MirPointerButton and can only be interpreted through the device introspection API (perhaps this is true? Maybe it's not really...)
<racarr> and that could get weird if things were flags
<racarr> Does anyone have a good writeup of what is going on in situations where bzr merge --weave will fix conflicts that merge wont
<racarr> ive never bothered to understand it and it always leaves me with this
<racarr> sinking uneasy feeling
<racarr> man there could be a way better interface for managing
<racarr> pipelined branches...
<racarr> e.g. if launchpad
<racarr> understood it
<racarr> also I have to put a dollar in the gender specific noun when addressing a general audience jar :(
#ubuntu-mir 2015-05-08
<racarr> mt::TouchEventMatches(*key_event) spot the error
<racarr> :p
<racarr> it somehow seems more obvious out of ocntext
<tmpRAOF> That's how these things work.
<robert_ancell> Are there any special requirements for a client to connect to the Unity 8 Mir socket?
<robert_ancell> I'm trying to run a test client and getting a broken pipe
<robert_ancell> (error)
<duflu> robert_ancell: Not entirely sure. Unity8 has always been a bit different to plain Mir
<duflu> robert_ancell: A broken pipe might suggest there's a protocol compatibility break and you're mixing two different Mir versions..?
<robert_ancell> ok, very weird. Xmir has an argument --desktop_file_hint which seems to make the connection allowed. But Xmir doesn't actually use this argument at all. If I run my test program with --desktop_file_hint it works.
<robert_ancell> Some AppArmor thing must be checking the argument list...
<duflu> robert_ancell: I remember now -- Unity8 does very odd things like checking the client's argv (!)
<robert_ancell> That must be a "to be fixed" :)
<duflu> robert_ancell: It's definitely strange, but someone wrote that on purpose. Not sure if it's a permanent thing
<duflu> robert_ancell: The client(s) don't even need to support the --desktop_file_hint argument, just to be given it so the server Unity8 can see it in /proc/<pid>/cmdline (IIRC)
<robert_ancell> Yeah, my test program doesn't parse argv at all
<duflu> robert_ancell: At least one reason would be that Unity8 still uses the window title (app name) from desktop files. But it can and should use the surface name() instead
 * duflu finally kills all latency and makes the hardware cursor stick to things
<anpok_> alan_g: hm i just started to merge placement applying shell into DeclarativePlacementStrategy... moved the test suite back to throwback and now plan to reuse DefaultWindowManager.. stop me now!
<alan_g> anpok: stop it. We need to get stuff out of throwback, not add it
<anpok> ok
<alan_g> anpok: did you forget "bzr mv tests/acceptance-tests/throwback/test_client_input.cpp tests/acceptance-tests/test_client_input.cpp"? They look rather alike
<anpok> alan_g: hm I slowly started to with test_client_input.cpp and added stuff to it stepwise in previous mps
<anpok> -to
<anpok> and removed stuff from throwback .. then 'moved' the rest with the last mp
<alan_g> OK, just wondering
<kdub> racarr, i'm thinking about mf::BufferStream... was that split from mc::BufferStream or was it new when it was added?
 * kdub ponders if its wise to just merge mf and mc BufferStream
<kdub> and I guess what I'm really pondering is if its wise to make the interfaces in mc::BufferStream public
<racarr> kdub: I guess it was new when added? The only idea with it was to avoid
<racarr> exposing all the stuff on mc::BufferStream where not necessary
<racarr> as some of it is a little scary
<kdub> right, its still scary
<kdub> I think I've thought of another way to keep it internal, doesn't seem wise to make mc::BufferStream public without some intensive cleanup
<racarr> Yeah
<kdub> but, mf::BufferStream is handy
 * kdub has even had the thought that its a semi-internal-client (to bring that concept back :P)
<racarr> Hmm thats interesting
<racarr> and capture the request management stuff in
<racarr> some sort of client abstraction?
<kdub> which 'request management stuff'?
<racarr> drop_old_buffers, drop_client_requests, force_requests_to_complete
<kdub> ah, well those are the server's levers
<kdub> that the client shouldn't push
<racarr> what do you mean by mf::BufferStream as an internal client then?
<kdub> just in the sense that a server can write to a surface via the public api in the same sort of way that the removed 'internal client' could
<kdub> not that i'm bringing that back anytime soon :)
<racarr> Ah
#ubuntu-mir 2016-05-09
<duflu> tsdgeos: Got a Pineview system and soon found it's just a Unity8/qtubuntu bug. Mir is fine on it :)
<tsdgeos> yeah i saw your comments
<duflu> I'd guess Ubuntu Toolkit... something
<duflu> with shaders
<anpok> qtuick
<anpok> qtquick..
<duflu> I like the name qtuick
<anpok> yeah it has something..
<duflu> dyslexia
<anpok> maybe you can improve the situation with simpler shaders..
<zzarr> hello! can I run a custom application using mir in a snap package on dragonboard 410c?
<zzarr> I have a HDMI/USB connected touch display connected to it
<dandrader> kdub, do you know how do I fix/work-around this "android_dlopen called but not implemented!" error when running unity8+mir on a desktop?
<kdub> dandrader, i think it may have been fixed in silo-31
<dandrader> kdub, ok, thanks
<Saviq> pushing this one your way, guys bug #1574777 - a refresh rate of 0,60Hz doesn't seem right ;)
<ubot5> bug 1574777 in mir (Ubuntu) "tablet connected to monitor shows black screen - Idek Iiyama PL2409HD" [Undecided,New] https://launchpad.net/bugs/1574777
<bregma> that explains the FPS I'm getting.....
<bregma> sounds like a broken EDID -- as if there's any other kind
<bschaefer> haha... 0.60hz? that... would be interesting to see
<bschaefer> 166ms per frame? Or somewhere close...
<anpok> hm but i thought we do not care about that refresh rate with hwc
<anpok> but
<anpok> hwc itself might..
#ubuntu-mir 2016-05-10
<duflu> anpok: Hangout?
<anpok> omw .. strange connection problems..
 * duflu follows the shiny things
<greyback> alf__: hey, I recall that you did the refactoring to separate the rendering api from the renderer - was there ever a plan to implement an OpenGL rendering backend?
<alf__> greyback: you mean OpenGL and not OpenGL ES 2.0?
<alf__> greyback: If so, no plans at this point, but if/when the separation is finished it should be relatively easy to do. However, the separation effort is not in progress at the moment.
<greyback> alf__: yeah
<greyback> alf__: separation did not complete?
<alf__> greyback: no, other higher priority tasks got in the way
<greyback> alf__: ok
<alf__> greyback: and I have no idea when we will get back to it
<greyback> alf__: fair enough
<alf__> greyback: is this just about linking with libGL vs libGLESv2 or do you need different behavior based on Desktop vs ES2?
<greyback> alf__: I suspect the fact that Mir asks for GLES context, but Qt does GL with that context, is bad for older chips: (see https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1549455 and note the comments about bad unity8 performance and mesa complaints in comment 63)
<ubot5> Ubuntu bug 1549455 in qtubuntu (Ubuntu) "Unity8-dash on Intel Pineview graphics crashes and restarts continuously [qtubuntu: ASSERT: "eglDestroyContext(mEglDisplay, mEglContext) == EGL_TRUE"]" [Critical,Triaged]
<greyback> alf__: the client problem is a separate issue, that I know.
<mariogrip> any news on proprietary nvidia drivers working with mir?
<anpok> mariogrip: hm i believe nothing new to share yet..
#ubuntu-mir 2016-05-12
<kg_> bregma, hey, so hexchat working nice, but won't save settings...always warns "you don't have write access to /home/kg/.config/hexcat"
<kg_> i presume that's due to it being in the container ?
 * kg_ is now one-of-those-people
<kg_> bregma, so is there anyway to let the container access that?
<bregma> kg_, I believe you should have write access to a container-unique .config directory, ChrisTownsend can confirm
<bregma> I mean, there should be a container-unqiue home directory in which you can create a writable .config
<bregma> there were some problems with file ownership in containers that has cropped up from time time to time
<anpok> greyback: qtmir..
<anpok> qtmir does not replace the focus controller, right?
<anpok> so qtmir and unity8 keep mirserver informed about the focused surface/session?
<greyback> anpok: correct
<anpok> great.. so no problem there..
<ChrisTownsend> bregma: kg_: Yeah, for reasons I have yet to determine, some directories in the mappep home have user 100000/100000 as the owner, even when inside the container.
<ChrisTownsend> So the easiest thing to do is change .config to be your user and it should work.
<kg_> ChrisTownsend, how does one "change .config to be your user"
<ChrisTownsend> kg_: Oh, right, go to .local/share/libertine-container/user-data/xenial and change it there (assuming the id of your container is xenial).
<ChrisTownsend> kg_: Then sudo chown it.
<kg_> ChrisTownsend, interesting, there's no .config under /xenial/
<kg_> there's actually nothing
<kg_> oh wait...maybe that's old
<ChrisTownsend> kg_: Is that the id of your container?
<kg_> ChrisTownsend, l-c-m says yes, that's my only container...
<kg_> ChrisTownsend, and actually, there's nothing under /xenial/
<ChrisTownsend> kg_: Hmm, what are the permissions of the xenial directory itself?
<ChrisTownsend> kg_: There should be stuff in that directory.  I don't understand why there isn't.
<kg_> ChrisTownsend, drwxrwxr-x
<ChrisTownsend> kg_: Who owns it?
<kg_> ChrisTownsend, me..kg
<kg_> kg kg
<ChrisTownsend> kg_: Strange
<ChrisTownsend> kg_: Well, try creating a .config directory in there and see what happens.
<kg_> ChrisTownsend, sorry got distracted ;) will try
#ubuntu-mir 2016-05-13
<tjaalton> anpok_: hi, what's the status of the libinput patch going upstream?
<anpok_> tjaalton: not sure peter recently indicated he might add the lacking calibration part.. and I was to occupied with other things
<tjaalton> anpok_: ok, good to know
#ubuntu-mir 2017-05-08
<xnox> alan_g, is miral going to be maintained with mir? and do we need it in Ubuntu artful?
<xnox> (e.g. kiosk?)
<alan_g> xnox: yes.
<xnox> alan_g, ok, does it need to be in main? and then it probably may need subscriber, and be reseeded back in. Let me check.
<xnox> i think it should be in main.
<alan_g> Me too
 * alan_g would like it in Xenial too, but that's probably too much.
<xnox> not sure where to put it, but sticking it into "supported" for now.
<alan_g> ack. In principle miral is a part of Mir that just happens (for historical reasons) to be in a different source tree.
<xnox> we also have two boost source packages, per boost release.....
<xnox> well, imho MIR stack is like 4 packages: mir, miral, qtmir, qtmir-gles =)
<xnox> and i think we agreed to remove qtmir[-gles] in artful
 * xnox hopes i got that right
<alan_g> +1
<alan_g> I'm not sure what we plan with unity-system-compositor though
<xnox> currently i have the mandate to remove from the archive unity8 + touch stacks
<xnox> once ubuntu-desktop switches to gnome proper; remove unity7 too
<xnox> this includes ui toolkit, terminal-app, and everything in between.
<alan_g> That sounds fair
<alan_g> greyback_: got time for a quick review? https://code.launchpad.net/~alan-griffiths/miral/modernize-cmake/+merge/323376
<greyback_> alan_g: ok
#ubuntu-mir 2017-05-09
<alan_g> duflu: what's with all these ancient bugs linking to mir?
<duflu> alan_g: Not related to Mir. I just need to temporarily assign them to a project I am a member of in order to be able to delete legacy project tasks :P
<duflu> Such is Launchpad
<duflu> And ancient bugs won't expire till you delete their open project tasks
<duflu> *won't even begin to expire
<alan_g> duflu: I see, you're doing a cleanup of stuff that should have been forgotten. np.
<duflu> alan_g: Yes, still on the year 2010
<alan_g> There should be a better way. At least there are no launchpad haters to tell us how we did it all wrong.
<duflu> alan_g: *shrug* You can't remove a project task for foreign projects but you can correct the project name to one you are a member of, then delete it
<xnox> i thought there was a special project to move bugs to
<xnox> and items
<alan_g> Maybe so. But that doesn't mean everyone knows what it is. (I don't)
<Laney> is it https://launchpad.net/null-and-void that one?
<Laney> Some ancient cavity inside my brain was echoing with those words
<Laney> (in Ted's voice)
 * alan_g wonders if that implies everyone is a member of team null-and-void. 8^)
#ubuntu-mir 2017-05-10
<duflu> alan_g: OK, I figured out I can use Ubuntu (despite that being a distro and not a project), and won't use Mir for deletions now :)
<alan_g> duflu: nice.
#ubuntu-mir 2017-05-11
<tjaalton> alan_g: hi, perhaps best to discuss mesa/vulkan here
<tjaalton> the build issue
<alan_g> tjaalton: sure
<tjaalton> ../../../src/intel/vulkan/anv_wsi_mir.c:28:10: error: no previous prototype for âanv_GetPhysicalDeviceMirPresentationSupportKHRâ [-Werror=missing-prototypes]
<tjaalton>  VkBool32 anv_GetPhysicalDeviceMirPresentationSupportKHR(
<tjaalton> and then another for anv_CreateMirSurfaceKHR
<tjaalton> this is weird, since the includes should be fine
<tjaalton> i've just pushed ubuntu+1 branch to alioth git
<tjaalton> https://anonscm.debian.org/git/pkg-xorg/lib/mesa.git that is
<alan_g> tjaalton: this isn't code I've ever touched. Can I see the error on Zesty, or do do I need Artful?
<tjaalton> you need mesa 17.1
<tjaalton> so, this branch
<tjaalton> builds on zesty too, though you'd need newer libdrm
<tjaalton> which you can get from https://launchpad.net/~ubuntu-x-swat/+archive/ubuntu/updates
<alan_g> tjaalton: ack. (I'll start by browsing the source then)
<tjaalton> well the mir patches aren't applied to the source
<tjaalton> if you mean browsing cgit
<alan_g> ah
<alan_g> where do I find the patch?
<tjaalton> debian/patches
<alan_g> I'm misunderstanding - not debian/patches/07_gallium-fix-build-failure-on-powerpcspe.diff I'm sure
<tjaalton> vulkan-mir.patch
<tjaalton> but you need to apply the rest fist
<tjaalton> first
<tjaalton> series tells the order
<alan_g> $ find debian/patches
<alan_g> debian/patches
<alan_g> debian/patches/series
<alan_g> debian/patches/07_gallium-fix-build-failure-on-powerpcspe.diff
<tjaalton> did you clone it?
<alan_g> yes
<tjaalton> git checkout ubuntu+01
<tjaalton> er
<tjaalton> ubuntu+1
<tjaalton> you're on debian-unstable :)
<tjaalton> add -b
<tjaalton> no
<tjaalton> sorry
<tjaalton> just 'git checkout ubuntu+1' should do I think
<alan_g> tjaalton: that's it.
<tjaalton> then use quilt push -a
<tjaalton> to patch the source
<tjaalton> pop -a to unpatch
<alan_g> Sorry, not familiar with quilt. It says: "No series file found" - how do I tell it where the patches are?
<bschaefer> in my ~/.quiltrc
<bschaefer> QUILT_PATCHES=debian/patches
<alan_g> "$ QUILT_PATCHES=debian/patches quilt push -a" seems to work
<bschaefer> yeah it should, just like to not have to manually set that path each time haha
<bschaefer> i also have this in my quiltrc :) QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index"
<alan_g> tjaalton: (Sorry, got sidetracked) The compiler is right that there's no prototype for the functions. But I need to do a bit of digging to determine if that's actually an issue.
<alan_g> Hmm there's vkGetPhysicalDeviceMirPresentationSupportKHR declared in a header (and some xml) but no implementation.
<tjaalton> alan_g: i checked how it's done for wayland, and couldn't see where it differs :/
#ubuntu-mir 2017-05-12
<alan_g> tjaalton: yes, it looks the same. A guy we both know has offered to help (but he's not up yet). That may be quicker than trying to learn it ourselves.
<alan_g> tjaalton: I've just spotted your name on the SRU Wiki. I'm trying to update Mir in Xenial so that IoT can dispense with the overlay PPA (bug 1685186). Is this something you can help me with?
<ubot5> bug 1685186 in mir (Ubuntu) "[SRU] Mir needs to be updated to 0.26 in 16.04LTS" [High,In progress] https://launchpad.net/bugs/1685186
<tjaalton> alan_g: I can ack stuff on the queue, yes
<alan_g> tjaalton: that sounds like a step forward. Thanks.
 * alan_g is suffering from xml (in the mesa code)
<alan_g> tjaalton: I think src/intel/vulkan/anv_entrypoints_gen.py should be generating the function declaration, but I need to figure out how it is supposed to work.
<alan_g> tjaalton: I'm still not set up to try a full build, but you need 'VK_KHR_mir_surface' in SUPPORTED_EXTENSIONS in src/intel/vulkan/anv_entrypoints_gen.py
<tjaalton> alan_g: oh, I'll try that out
<tjaalton> thanks
<alan_g> np, someone needs to grok this stuff. I have to start somewhere.
 * alan_g is wondering which (if any) laptop deserves Artful at this time
<tjaalton> alan_g: new errors this time :)
<alan_g> Nice!
<tjaalton> vulkan/anv_entrypoints.c:712:5: error: unknown field âCreateMirSurfaceKHRâ specified in initializer
<tjaalton> etc
<alan_g> Well, that's protected by #ifdef VK_USE_PLATFORM_MIR_KHR - so let me see where that should come from...
<alan_g> Actually, no. it's a void* otherwise
<tjaalton> -> afk, will check back in a bit
<alan_g> tjaalton: does struct anv_dispatch_table in your anv_entrypoints.h not have a CreateMirSurfaceKHR member? Running that python script here generates it OK, maybe you just need to clean it?
<tjaalton> perhaps I shouldn't be running sbuild but a chroot
 * alan_g doesn't need to cross build often enough to learn the tools.
<tjaalton> uh, chroot build passes fine
<tjaalton> anv_entrypoints.h looks fine
<tjaalton> which is hardly surprising at this point
<tjaalton> anyway, guess it's on me to figure out why the package build fails
<tjaalton> using the upstream tarball & autoreconf
<tjaalton> yeah, the tarball comes with anv_entrypoints.c/h so they're not regenerated
<alan_g> tjaalton: I'll leave you to deal with that then
<tjaalton> removing just those two didn't help :(
<tjaalton> oh well
<tjaalton> ha, typoed the removal, works after all
<alan_g> \o/
<alan_g> tjaalton: abut the SRU bug above. Who (that's left) can get it targeted to xenial?
<tjaalton> alan_g: anyone on ubuntu-bugsquad or what was it called.. if you mean the technical bit of modifying the bug to show that
<tjaalton> as for allowing the update to enter proposed, maybe get some buy-in from #ubuntu-release first
<tjaalton> then anyone on the sru team can be more confident in letting it in
<xnox> alan_g, what's the bug number?
<alan_g> xnox: bug 1685186
<ubot5> bug 1685186 in mir (Ubuntu) "[SRU] Mir needs to be updated to 0.26 in 16.04LTS" [High,In progress] https://launchpad.net/bugs/1685186
<xnox> alan_g, the package should land into unapproved queue.
<xnox> alan_g, meaning somebody needs to publish the silo.
<xnox> then ubuntu-sru team will review the unapproved queue
<sil2100> I can potentially take a look at if if needed
<sil2100> *it
<sil2100> This will need an archive admin for final approval anyway
<ogra_> how do you make sure the mir-kiosk based snaps keep working ? (snapcraft will have used what was in the archive at the time of the snap build to link against libmirclient)
<ogra_> i.e. is 0.26 fully backwards compatible so it doesnt break existing deployments out there ?
<sil2100> Seeing the number of ABI bumps, that would be 'no'
<alan_g> ogra_: 0.26 is what is in the stable phone overlay
<alan_g> and the "mir snaps" are built with that
<sil2100> Anyway, this needs to first go through an archive-admin anyway, I guess it's best if the review is done by someone with the proper powers
<ogra_> alan_g, even the client apps ?
<alan_g> Getting 0.26 into xenial means we can stop using the overlay
<alan_g> ogra_: client apps should be using mir-libs
<alan_g> And that uses overlay
<ogra_> alan_g, ok
<alan_g> xnox: @"somebody needs to publish the silo." - how do I make that happen?
<xnox> alan_g, get an Archive Admin to review it on e.g. #ubuntu-ci-eng due to ABI bumps. For example, I would recommend pinging slangasek but I'm not sure if he is available today.
