#ubuntu-mir 2013-06-10
<tvoss> alf_, ping
<alf_> tvoss: pong
<hikiko> hi :)
<sil2100> Morning
<hikiko> question: although there's a libmirclient in the repos from what I see mir trunk is one cmake project (client and server are not separate) is this true? (I am not so familiar to cmake and maybe I'm wrong) actually, I am trying to configure cmake to use a mir backend so I wonder if I have to link to mirclient library or add the client source files in the CMakeLists... :)
<didrocks> hey sil2100, how was your week-end?
<tvoss> hikiko, you should link to the client library
<duflu> hikiko: Depend on dev package libmirclient-dev, binary package libmirclient0, and just link to libmirclient
<duflu> hikiko: Though I'm not sure if the Mir source is set up to export CMake packages yet...
<duflu> Hmm
<hikiko> i think it isn't duflu but I am not sure
 * duflu checks
<hikiko> tvoss, you mean the system library?
<tvoss> hikiko, system library?
<duflu> hikiko: No we don't have/install a native CMake package. We do however install pkgconfig files. You can import the "mirclient" pkgconfig module into CMake via http://www.cmake.org/cmake/help/v2.8.8/cmake.html#module:FindPkgConfig
<hikiko> tvoss, i mean the libmirclient that is installed in the system
<tvoss> hikiko, exactly, if you are working outside the mir source tree
<duflu> hikiko: pkg_search_module(MIRCLIENT REQUIRED mirclient)
<hikiko> tvoss, I am woking on the mir server so, I have to use the libmirclient of the same branch I guess
<duflu> and then refer to the magic variables MIRCLIENT_* (http://www.cmake.org/cmake/help/v2.8.8/cmake.html#module:FindPkgConfig)
<sil2100> didrocks: hi! Too short ;) How about yours?
<hikiko> thank you duflu :D but this will use the installed libmirclient?
<didrocks> sil2100: same, too short :) still a little bit exhausted by last week
<didrocks> but otherwise good :)
<hikiko> mmm if I run make install in the client that wont be a problem
<tvoss> hikiko, yup, then you shouldn't link against the installed one
<sil2100> didrocks: at least we were able to release everything \o/
<duflu> hikiko: Or just depend on debian package (libmirclient-dev)
<didrocks> sil2100: exactly! so I feel more relaxed now :)
<didrocks> sil2100: I wanted to ask you if you don't mind taking the apps stack still today for the time robru will need to catch up on his emails? :)
<sil2100> didrocks: no problem ;)
<hikiko> hmmm thanks duflu but this is to link with the installed client library, in my case I am trying to do something on the server using the client library
<sil2100> didrocks: I'm poking people right now already
<didrocks> sil2100: that, + the new components we will put under dailies today? (You reviewed them with Mirv, right?)
<didrocks> sil2100: excellent, thanks!
<hikiko> is there any way to link with the client of the same branch?
<hikiko> (except of including the files)
<duflu> hikiko: "same branch" as what?
<sil2100> didrocks: all branches have been reviewed and merged in, so we should be able to redeploy stacks to get them daily released - but should I prepare needs-packaging bugs for the new packages?
<didrocks> sil2100: no need for needs-packaging bug. This is more to ask for someone to package it :)
<didrocks> sil2100: so yeah, just a MP with those, I'll prereview for NEWing before acking it
<didrocks> (MP for putting them under daily release)
<Mirv> yep, all reviewed
<sil2100> didrocks: ACK, although I saw that someone already added at least 2 of the new packages to the stacks last week, without re-deploying of course
<didrocks> Mirv: sweetness! be prepared, I think we'll have more soon :)
<duflu> hikiko: To use the client of your own local build you can export PKG_CONFIG_PATH=<mir_install_dir>/lib and then  pkg_search_module(MIRCLIENT REQUIRED mirclient)
<sil2100> didrocks: like dbus-cpp and location-service to platform stack
<didrocks> sil2100: ah, mind preparing me a list? Will be easier for my little brain :) (or a comment in the MP)
<sil2100> didrocks, Mirv: (but let's move that to -desktop) ;)
<duflu> where you previously cmake -DCMAKE_INSTALL_PREFIX=<mir_install_dir> .. ; make ; make doc ; make install
<didrocks> sil2100: nice idea :)
<hikiko> oh, i see duflu, thanks a lot!( duflu and tvoss :D)
<hikiko> duflu, ping
<duflu> hikiko, pong
<hikiko> I have another cmake question, if you could help.. :)
<hikiko> in the client CMakeLists.txt:
<hikiko> we have the tests if MIR_PLATFORM STREQUAL gbm or android
<hikiko> I am trying to create a mir platform in the server
<hikiko> but
<hikiko> I want to use the client as it is
<hikiko> but if I have the mir platform the $MIR_PLATFORM is equal to 'mir' not gbm or android
<hikiko> do you have any idea on how I could solve this?
<hikiko> if client and server were separate projects I wouldn
<hikiko> t have to worry about that
<hikiko> but now to build the server
<hikiko> I need to compile the client as well
<duflu> hikiko, I think you will find it's common for client+server to share a source package. And then be separate in the binary+dev packages produced
<duflu> But I don't quite understand the question
<hikiko> well: I added a new platform in the root CMakeLists
<hikiko> called "mir"
<hikiko> if I try to build from the root dir
<alan_g> hikiko: if you need distinct options for the server and client then don't use a single MIR_PLATFORM variable
<hikiko> alan_g, what could I do instead?
<alan_g> MIR_CLIENT_PLATFORM and MIR_SERVER_PLATFORM
<hikiko> :D
<duflu> I don't understand the need. Mir requires client platform == server platform
<hikiko> mmm but this way I have to modify both the client and the server isn't it?
<hikiko> duflu, I am trying to write a nested mir
<hikiko> which means I have to implement a server
<hikiko> using the client lib methods
<hikiko> so, I need the client to be gbm or android
<hikiko> depending on the machine
<hikiko> and the server to be mir
<duflu> Umm, there's no such thing as "client platform" is there? It just uses whatever "platform" the local server is
<hikiko> yes
<duflu> so MIR_PLATFORM means MIR_SERVER_PLATFORM
<hikiko> in my case yes
<duflu> which is "x11" now or something? :)
<hikiko> no no
<duflu> or SDL
<hikiko> it's not that task anymore duflu :)
<hikiko> it's not the mir on X
<duflu> Oh, properly nested.
<hikiko> yes :)
<duflu> Yes, MIR_PLATFORM=mir
<duflu> Hmm
<alan_g> hikiko: AIUI you actually don't want to use the client libs in the server, you want to use the host client libs
<hikiko> I think what alan_g said is the best solution
<hikiko> oh
<hikiko> so alan_g
<hikiko> I don't have to link with the client
<duflu> I still don't think MIR_CLIENT_PLATFORM makes sense
<hikiko> but with libmirclient installed in the system?
<alan_g> duflu: +1
<duflu> Mir clients will "just work". They're not compiled for a "platform"
<alan_g> hikiko: yes
<hikiko> so in the client I can just add an empty mir platform
<alan_g> hikiko: only if you're not supporting any clients. ;)
<hikiko> haha
<hikiko> braindamage
<hikiko> let me think it again :)
<duflu> I'm confused. But it would be nice to not have this confusion later at MP time
<hikiko> if I link with the system mirclient and I have a server-side platform the nested server will be the client that will use the system libmir
<hikiko> and then I have to do a client library for that server using mir functions again
<hikiko> so that the clients of the nested server
<hikiko> can use the nested mir?
<alan_g> yes
<hikiko> cool :D
<hikiko> so MIR_PLATFORM is fine :) I don't need client and server!
<alan_g> because, as duflu says, the client matches the server
<hikiko> so I "just" have to write 2 clients: one that does what mir server does + a connection and one that does what mir client does
<duflu> The client just talks a protocol. The server could be remote if only it wasn't for efficient buffer management meaning it's local, for now
<duflu> Hmm
 * duflu imagines an RDP buffer implementation
<duflu> Oh, and the socket is filesystem based
 * alan_g imagines duflu inventing X11
<hikiko> LOL
 * duflu regrets imagining
<duflu> I did say RDP though. That's not X11
 * alan_g doesn't let facts get in the way of a good story
<hikiko> sorry :s but I don't understand everything, I can't do what I said without implement a new type of buffers or rdp for the moment? (i mean can i do a very minimal nested display for example without doing all that?)
<hikiko> :S/rdp/any protocol
<hikiko> I mean can I use the protobuf and the buffers as they are?
<hikiko> I am refering to that: <duflu> The client just talks a protocol. The server could be remote if only it wasn't for efficient buffer management meaning it's local, for now
<duflu> hikiko: Yes you're right. I was just imagining extending Mir's power in future
<hikiko> yes :) I just got comfused with this ^ before you start imagining :) cool then!!
<hikiko> thank you very much both alan_g and duflu :D
<alan_g> alf_: I've discovered that, as of this morning, if I start mir on vt1 and a couple of clients on vt2 that after I switch to vt1 and back to vt2 the clients crash. Have you seen this?
<alf_> alan_g: no
<alf_> alan_g: but I haven't tried this recently
<alan_g> alf_: np (I was hoping for "yes, that is...")
 * alan_g decided to go back in time...
<alan_g> ...it happens with last week's code too. Fires up a box which didn't update since last week...
<alan_g> ...and on that I don't see a problem with last week's code. But when I pull head it goes boom...
 * alan_g checks versions carefully: 727 works, 728 fails
<alf_> tvoss: @not implementing snapshot ubuntu api, hmm, interesting... well the shell has access to each surface's texture but only in the (EGL) context of the compositor, i.e., in the CompositingStrategy the shell will provide to mir
<tvoss> alf_, hmmm ... that's a good point. the shell is only taking a screenshot as it couldn't move around surfaces on screen
<tvoss> alf_, thinking about it
<alf_> tvoss: (we can't give texture ids to the shell to use with its own EGL context, since that context comes from a different EGL display and backend (mir vs gbm))
<alf_> tvoss: (mir vs gbm/android)
<tvoss> alf_, okay, thanks for the hint
<alf_> tvoss: so we either keep the snapshot api, or the shell needs to get the snapshots as part of its compositing process
<tvoss> yup, I was thinking about the latter one ...
<tvoss> but let me check with Saviq, too
<tvoss> alf_, in a few, though, need to finish a mail
<alf_> tvoss: no problem... if we drop the API I need to start thinking about what to work on next :)
<tvoss> alf_, I think we need to keep it intact for the time being, just need to think it threw completely
<alf_> tvoss: "or the shell needs to get the snapshots as part of its compositing process" => "get *and draw* the snapshots...", since even in this case the shell still can't use the surface textures with its own inprocess client context
<hikiko> another question: the MirNativeBuffer in the client library is the same thing as android and gbm buffers? or this is the MirSurface in the client?
<alan_g> hikiko: yes
<racarr> Good morning!
<roman2861> Who knows abous Mir on Nexus 10?
<racarr> roman2861: kdub is your best bet
<racarr> My memory is that support on nexus 10 isn't that explored
<kdub> roman2861, right, there's a plan to support the nexus 10, but at the moment, there are bugs that make it unusable
<roman2861> I understood it when i tried to install Mir on tablet) But when you expect to fix bugs?
<kdub> roman2861, hopefully soon, but you can track this blueprint for updates https://blueprints.launchpad.net/ubuntu/+spec/client-1307-mir-nexus10
<roman2861> Thanks
<kdub> status today, trying to figure out composition bypass, cleaning up some mc:: interfaces, and opening up an ipc path for clients to request swapinterval 0/1
<alf_> alan_g: kdub: @lp 1189443, problem is that, due to the way we handle force_client_completion through exceptions, the clients can occasionally get an error response when asking from a buffer, but they are not in a good position to handle this situation right now. Also, what does getting an error response mean? Is it a fatal error, or should the client try again? It's not clear from a client's perspective.
<ubot5> Launchpad bug 1189443 in Mir "Mir clients crash when switching VTs" [Critical,New] https://launchpad.net/bugs/1189443
<alan_g> alf_: I don't think exceptions are right when switching VT
<alf_> alan_g: kdub: Yeah, perhaps we should rethink using an exception as a reaction to force_client_completion().
<kdub> why do we force_client_completion when switching vt?
<alan_g> From a client perspective failing to swap_buffer is probably severe
<alf_> kdub: to be able to stop the communicator's threads
<alf_> kdub: same situation as when shutting down, but then we start again when we resume :)
<alan_g> alf_: I don't think they are the same situation
<racarr> they are in the code now ;)
<kdub> we could also have a different method than just 'force_client_completion' i guess
<racarr> This reminds me of the
<kdub> that wil retry the request instead of bouncing an error out to the clients
<alf_> alan_g: right now they are, since we stop the communicator when switching VTs
<alan_g> racarr: we're discussing what should be
<racarr> exception handling in swap_client_buffer in
<racarr> err
<racarr> acquire client buffer
<racarr> in SwapperSwitcher
<racarr> except in this case there is no meaningful way to propagate a "try again" flag
<alan_g> alf_: kdub racarr - I knew it was better to call it "shutdown()" ;)
<alan_g> "pause" shouldn't need to abort requests in progress
<alan_g> (Aren't those threads blocked anyway)
<alan_g> hangout?
<alf_> alan_g: in the old version it didn't, it just ensured that any requests in progress would finish in some finite time
<alf_> alan_g: sure
<racarr> I am actually jumping on
<racarr> unity8-mir sync now
<alf_> alan_g: (and it was called force_requests_to_complete())
<racarr> I can join you guys after, or if you want to delay a little
<Saviq> racarr, alf_, hey, Gerry had to split, do you have anything I should know about or need to know something from me? or can we skip todays sync meeting?
<alan_g> https://plus.google.com/hangouts/_/848de4bb9222c984f54e33476685aee9165bbfcc?hl=en-GB
<alf_> Saviq: have you talked to tvoss about the snapshot API ?
<Saviq> alf_, not yet,
<tvoss> alf_, not yet
 * alan_g is prepared to wait to get right decision
<tvoss> Saviq, otp right now, will ping you after that
<racarr> Saviq: Yes, Gerry pinged me. Um...ricmm is coming today I believe
<Saviq> ok then, comign
<racarr> to talk about landing the dependencies (should hopefully happen, today, tomorrow)
<alf_> Saviq: tvoss: ok, thanks
<racarr> alf_: I was thinking about snapshots
<racarr> we can't share the texture ID directly, but we can share the buffer
<racarr> right?
<racarr> The same way we would to the compositor
<racarr> but it becomes kind of strange...
<alf_> racarr: buffer == gbm/android native buffer?
<racarr> yes
<racarr> I'm having trouble wrapping my head around exaclty what the synchronization problems are though
<racarr> Done with shell sync, if anyone wants to hang out still. There are a few new things for us that we could go over too
<racarr> or we can wait until tomorrow (and I will try and clarify thoughts on them today)
<alf_> racarr: also, in this case the mir egl platform would need to be able to handle those types and create egl images from them
<tvoss> Saviq, ping
<Saviq> tvoss, pong
<racarr> alf_: Yes. That's what I was thinking
<racarr> it seems like we could implement that
<racarr> can we on android?!?!
<alf_> kdub: ^^ Any idea?
<alf_> kdub: Can we implement eglCreateImageKHR for the Mir EGL platform on Android?
<racarr> Why can't we use the existing one on android?
<racarr> XD, not trying to be contrary, just having trouble wrapping my head around it
<kdub> right, i don't know that there's anything to implement
<racarr> there is both the problem of hooking together the bits
<racarr> but then there is the problem o
<racarr> is there a synchronization
<racarr> problem
<racarr> I mean this is basically like a client acquiring
<racarr> another clients buffer
<racarr> granted an internal client
<racarr> hey that's the name of an interface!
<racarr> but still.
<alf_> racarr: yes, our buffer swapping scheme assumes 1 producer 1 consumer (for proper functioning) and this breaks the assumption
<alf_> racarr: we still need some kind of "peeking" functionality, but if we hand out native buffer objects it complicates things
<alf_> racarr: kdub: perhaps "EGLImage InternalClient::egl_create_image(EGLDisplay disp, EGLClientBuffer buf)" and "EGLClientBuffer Buffer::egl_client_buffer()"... it's all too hazy right now :)
 * kdub doesnt really know the context we're talking about
<racarr> alf_: That is what I am thinking.
<racarr> but it's too hazy for me to be 100% convinced it works
<racarr> kdub: Snapshots
<racarr> well not snaphots
<racarr> preview
<racarr> s
<kdub> with android you can eglCreateImageKHR with the android native buffer type
<racarr> kdub: Mm. I think the confusing bit is
<racarr> if one client (i.e. the shell InternalClient)
<racarr> say the dash
<racarr> needs to preview an application
<racarr> It has to dos omething akin to like
<racarr> compositor_acquire
<racarr> (I think?)
<racarr> the implications of this are hazy
<racarr> to me XD
<racarr> maybe not to you
<alf_> racarr: probably compositor_peek(), which at least is somewhat clear to me :)
<kdub> right :)
<racarr> it is somehow an acquire though right because how can you know when the client is done with it
<racarr> espescially if we don't glflush on buffer swap
<racarr> which we can only get away with for so long :p
<alf_> racarr: right, it's more of a lock, you will need to peek/release
<racarr> I have a feeling there will be something called a fence involved
<racarr> XD
<alf_> racarr: kdub: What confuses me (probably because I am not familiar with Android EGL impl., is how you would create an EGLImage for the *Mir* EGLDisplay? Could you just write: eglCreateImageKHR(mir_egl_display, android_native_buffer)?
<racarr> In android it's all the same EGLDisplay
<kdub> right
<racarr> So. I think so!
<kdub> http://bazaar.launchpad.net/~mir-team/mir/trunk/view/head:/src/server/graphics/android/buffer.cpp
<alf_> racarr: kdub: ok, so only for Mesa we would need to actually implement eglCreateImageKHR for the "mir" egl platform
<alf_> racarr: kdub: ok, it's becoming a bit clearer... this could work if the access to the buffers is synced by using a peek/lock mechanism.
<kdub> alf_, right, i think so
<alf_> racarr: kdub: we could even enforce this at the API level, Surface::with_latest_buffer_egl_image_do(EGLDisplay, InternalClient, std::function<void(EGLImage)>) ... we would safely create/release the image, and just guarantee that it's valid for the duration of the callback function.
<racarr> that API might be difficult to use
<racarr> oh
<racarr> I'm not sure why I thought that
<racarr> XD
<alf_> all: Have a great rest of day!
<racarr> alf_: Yes. I think it makes sense.
<racarr> You too!
<racarr> Lets talk about this tomorrow
<racarr> once its had a little time to clarify
<alf_> racarr: sure
<racarr> See ya!
<racarr> When does kgunn come back?
<racarr|lunch> Happy lunch!
<racarr> Anyone around with some qmake knowledge?
<racarr> Now I know some qmake!
<bregma> *tsk* *tsk* it seems the mir codebase is liberally sprinkled with assert() macros executing code with side effects
<bregma> turns out that's always been a bad idea
<racarr> It's not the best idea XD
<racarr> I think most of the asserts
<racarr> are more of a "TODO"
<racarr> than anything else
<kdub> they can be removed, i'd say
<bregma> the test suite depends on them actually asserting
<bregma> I have an MP forthcoming
<bregma> slowly
<bregma> the root of the problem is that CMake sets NDEBUG by default in the current version
<racarr> Ah
<racarr> thanks :)
<bregma> does mir have an automerger?
<racarr> yes
<racarr> âFollow the Road of White Nettles for three days into the mountains, and you will come to a hermitage perched on a cliff. A learned brother dwells there who keeps copies of our clientâs documentation. He will advise you on the design of the system.â
<racarr> ...hahahaha
<racarr> Pretty much done for today :) Will be around for a while at least at computer if I can be helpful
#ubuntu-mir 2013-06-11
<olli> hey RAOF, not sure if you saw my mail earlier... will I be able to give xmir a spin tomorrow my time?
<RAOF> olli: Yeah, just processing email.
<RAOF> You should be able to, yes.
<olli> RAOF, great
<olli> no hurry, I will be afk for a while
<RAOF> You definitely will be able to with an xorg.conf change, maybe without (on Intel)
<olli> as long as it gets to me before you leave for the day
<olli> sounds good
<olli> as long as it's documented
<olli> cya RAOF and everybody else
<duflu> olli: bye ... ?
<duflu> Ah, my ISP decided they would start trying to diagnose connection problems at 9am. I'm out of whack now
<duflu> RAOF: SwapbuffersWait=true gets ignored in the PPA's intel driver. It still stays off :(
<duflu> Although if it was doing proper flipping then I would not be seeing tearing. Looks like it's blitting for buffer swapping... ?!
<duflu> Maybe that assumption is wrong...
<RAOF> duflu: And, just to check, this is happening with a regular X session, not running under the system compositor?
<duflu> AFK :P
<duflu> Some days the whole world tries to contact you simultaneously...
<duflu> RAOF: Yes regular X with no mir running
<RAOF> duflu: There'll be a new build of xf86-video-intel shortly; try that.
<duflu> RAOF: Kay, thanks
<RAOF> Gargh.
<RAOF> Faster, laptop.
<RAOF> Aha.
<RAOF> Mesa!
<duflu> ?
<RAOF> duflu: Mesa is why everything is broken for me.
<RAOF> Woot!
<RAOF> And now we're back to where we started.
<RAOF> With a ridiculous orange hardware cursor on top of the XMir session :)
<mlankhorst> fatally orange
<duflu> Umm, that's out of date. We switched to a black and white one some days ago
<duflu> Which reminds me, I meant to propose a smaller one
<tvoss> RAOF, ping
<RAOF> tvoss: Pong
<tvoss> RAOF, good morning :) you happy with being the primary technical contact for Khronos?
<duflu> Is that news I see?
<RAOF> tvoss: Yeah. I've sent that email off.
<duflu> In this public forum?
<tvoss> duflu, yup, not a secret I guess :)
<tvoss> RAOF, cool
<RAOF> Khronos membership is public anyway, right?
<tvoss> RAOF, yup
<duflu> Woo, we shall paint Khronos a "ridiculous orange"
<tvoss> duflu, :)
<tvoss> alf_, ping
<alf_> tvoss: pong
<tvoss> alf_, good morning :) for the snapshot question: how difficult is it to do a texture to texture copy from a surface/buffer to a texture handle supplied by Unity/shell?
<alf_> tvoss: texture handle created in the EGL context of the shell (inprocess client)?
<tvoss> alf_, yup
<alf_> tvoss: We don't have access to textures from different (non-shared) contexts. An option we were considering yesterday was to add eglCreateImageKHR support for the mir EGL platform, so we could create egl images for the native buffer handles (from our surface buffers) in the inprocess client context.
<alf_> tvoss: so we don't actually share EGL resources (because we can't) but share the underlying native buffer
<tvoss> alf_, can you give me a ballpark estimate of the work?
<tvoss> alf_, remind me why we can't share the eglcontext?
<alf_> tvoss: however, there are complications here, since we can't just give native buffers to the shell without synchronization with our internal swapping
<tvoss> alf_, fair enough
<alf_> tvoss: @sharing eglcontext, because egl objects are namespaced under the egldisplay they are created with
<tvoss> alf_, ack
<tvoss> Saviq, ping
<alf_> tvoss: @estimation, testing etc 1.5 weeks, + couple of days for spike first to ensure what we are trying to do will actually work
<alf_> tvoss: (e.g. a feasibility check)
<tvoss> alf_, okay, please keep looking at it for the time being. There are two use-cases here: (1.) The shell needs to be able to transform an app's surfaces (moving, scaling, shearing), (2.) the shell needs to be able to acquire a snapshot of a surface right before an app is stopped/killed
<duflu> Hmm, isn't a "snapshot" a much simpler case? We're going to need a non-GL interface for that to eventually support screenshotting too
<alf_> tvoss: use case (1) should be done inside a compositing strategy (using the display server's EGL context), so no problem there in terms of sharing buffers.
<RAOF> Yeah. Is there any particular reason why the snapshots shouldn't be exposed as a blob of bytes?
<alf_> tvoss: (2) What does it want to get back? Pixels, like now or a texture?
<tvoss> alf_, right now, we are using pixels that are uploaded to a texture (saviq, please correct me if I'm wrong)
<duflu> Eventually we'll need pixels. But some shell features require more efficient textures... like a switcher
<tvoss> duflu, exactly, and turning a texture to pixels is always possible
<duflu> Although it's interesting to point out that Compiz does the live-previews thing without any "snapshotting"
<tvoss> duflu, that's use-case (1.) though, where the app is running and the surface exists
<tvoss> duflu, we still need "previews"/"snapshots" of the last state for killed/stopped apps (implication of the lifecycle model)
<RAOF> The other option of course is that the surface still exists with the most-recent content.
<duflu> Well, not just transform, but hook drawing functions and redraw a surface in multiple locations (like a workspace switcher)
<tvoss> duflu, agreed, that's what I call "transformation" *handwaving*
<alf_> tvoss: for killed apps pixels are the only way forward, because otherwise we would need to keep buffers alive...
<tvoss> :)
<RAOF> alf_: Why can't we keep buffers alive?
<duflu> Yeah you need "pixels" for killed/suspended apps. And also screenshot utils
<tvoss> duflu, alf_ okay, pixels sounds like a good idea then ...
<duflu> Because it's unreasonable (I think) to say a screen shot util needs to be a GL app
<RAOF> duflu: Oh, certainly. But that's orthogonal.
<RAOF> Is there any particular reason to scrape the pixels out of the buffer, then keep a copy of those pixels, rather than just keeping the buffer around?
<duflu> Yeah. Just wondering if we need both approaches or only one
<tvoss> alf_, for the snapshotting/synchronization: I would think that the shell interacts with a surface object for the snapshotting, too ...
<duflu> RAOF: We do it already ;) ... https://bugs.launchpad.net/mir/+bug/1188451
<ubot5> Launchpad bug 1188451 in Mir "Mir server leaks surfaces from dead clients" [High,Confirmed]
<RAOF> I don't think we'll be saving any appreciable amount of scarce resources by destroying the buffer but keeping the contents.
<RAOF> duflu: Heh.
<tvoss> duflu, mark it a feature then :)
<duflu> Hmm, it's a feature when we /want/ to leak
<alf_> RAOF: I was thinking that it may be too complicated, but I guess in the case we are destroying the surface on the compositor side, it's easy to reason about.
<alf_> RAOF: However, giving out the buffer while the DS still owns it, is a world of sync hell.
<RAOF> Not destroying the surface for an app that's tombstoned would fix that, though.
<RAOF> Bonus marks if we can get the resurrected app to use the same surface, so it starts with valid content.
<duflu> It's only in sync after it's tombstoned :)
<duflu> Hence not useful for other screenshotting apps
<RAOF> duflu: No, I mean that if the surface still exists then the shell can just composite it as normal; it doesn't need a separate snapshotting process.
<duflu> Hmm, Nexus4 is giving me stuttering. But only when I wasn't looking. Now I'm looking for the bug it's fine
<tvoss> RAOF, yeah, like removing all buffers except for the most current one from the surface
<duflu> Ah there it is
<RAOF> *Having* a separate snapshotting process is useful for screenshot apps (however we want to do that), but that might not be the best way to give the shell what they need.
<alf_> tvoss: RAOF: duflu: Saviq: Have time for a hangout?
<RAOF> I'll be bathing ZoÃ« soon.
<tvoss> RAOF, will you be back after the bath?
<duflu> alf_, in a couple of minutes, or later...
<RAOF> Just delegated bathing to Sam.
<RAOF> I may pop in and out once or twice, but I'm good to go.
 * tvoss searches for the headset
<tvoss> good to go
<RAOF> Oh, and we don't have a thomi this week, do we?
<tvoss> RAOF, nope
<alf_> tvoss: RAOF: duflu: https://plus.google.com/hangouts/_/d306e4af1fc3351c7a344cb62ef288f737707419?hl=en
<duflu> alf_: Having output device problems again. It refuses to use the headset and goes thru the PC speaker only :P
<RAOF> duflu: In a couple of minutes. Or, in fact, now. :)
<duflu> Argh and the mic doesn't work either
<duflu> I need to log a bug
<duflu> This happens too often
 * duflu searches for another mic
<duflu> Sorry, I'm out. Need to get a plain old-style mic, and/or a bug fix :(
<Saviq> tvoss, alf_, I believe at the moment the snapshot _includes_ the strut (the top panel), that's why we need the sourceX and sourceY - to _ignore_ the part that's uninteresting
<tvoss> Saviq, ack
<Saviq> tvoss, alf_, so if that changes (we get only the surface), we'll need to adapt qtubuntu accordingly
<alf_> Saviq: tvoss: Yes, in mir we will just get the surface contents
<alf_> alan_g: in light of clang handling "=default" differently from g++ in terms of exceptions, does the recommendation to use =default still stand, or should we prefer "noexcept {}" for destructors?
<alan_g> alf_: do we see an important difference?
<alan_g> AFAIK "= default" works fine on interfaces, and we typically have an explicit destructor for implementations. (The exception being google mocks where we have to add "~T() noexcept {}")
<alf_> alan_g: I don't think in my case... just wondering for the sake of general correctness
<alan_g> alf_: correct me if I'm wrong, but isn't the difference in behaviour only evident if you explicitly say "=default" in an implementation? Which is pointless.
<xrc> hello
<xrc> I need help with some package problems
<alf_> alan_g: yes, you are right, I had misinterpreted the problem as applying to all "=default"s, thanks!
<xrc> regarding this bug: https://bugs.launchpad.net/unity-system-compositor/+bug/1177722
<ubot5> Launchpad bug 1177722 in Unity System Compositor "mir ppa : unity-system-compositor should be built against latest mir libraries" [High,Fix released]
<xrc> I have managed to somehow install the lightdm with unity-system-compositor today
<xrc> but after I clicked upgrade in my ubuntu window with proposed updates - it uninstalled it to go for the latest build of libmirserver
<alan_g> xrc: I hear your pain. But I'm not sure what state packaging is in just now. (I know there were changes recently - if RAOF is still about he might know.)
<xrc> alan_g, should I try asking him directly?
<alan_g> xrc: It's his evening - if he didn't see the mention he's not about.
<xrc> alan_g, oh, I see. The problem is that I kind of got it installed for a second
<xrc> alan_g, only to find it slip through my fingers a moment later... Oh well, waiting I should be then.
<alan_g> xrc: we are trying to get things sorted (and they mostly work with a bit of patience) but it is still a work in progress
<xrc> alan_g, keep up the good work ) sorry if I'm a little bit aggressive on this, just that I'm very excited about MIR )
<alan_g> alf_: thanks for catching my flawed logic.
<alf_> alan_g: yw, do you think that providing the mentioned guarantee to comm->pause() is feasible with reasonable effort/complexity?
 * kdub can't think of something other than SwapperDirector
<alan_g> alf_: we can't allow requests to block and guarantee that they've completed
<racarr> Morning! halfway
<racarr> greyback: Can we delay sync 20 minutes?
<alf_> alan_g: that's true :(
<alan_g> Afternoon!!
<alan_g> alf_: we have to allow requests that can't be serviced now to block
 * alan_g thinks that's a possible TODO in display
<alf_> alan_g: I think this is much more complicated than we had previously... I am not convinced that the complexity is worth it (meaning that we should explore other ways, too)
<alan_g> alf_: Perhaps, but I do think that "paused" is actually a meaningful state.
<alan_g> making frontend  keep track of retries is just pushing all the complexity there.
 * alan_g thinks that if we decide to put "pause" logic in another place it grows into a utility class.
<alf_> alan_g: I guess I am arguing it's simpler not to support internal retries. That is, do what have been doing until now: when we pause: 1. we ensure that all pending requests are handled 2. we block new requests. It's simple and leaves the server in a clean state.
<alan_g> alf_: If it isn't simplistic that works for me. Why did we decide that we'd allow blocking in the swapper yesterday?
<greyback> racarr: meeting?
<alf_> alan_g: because we hadn't thought through all the issues of doing so... and to avoid sending an error response to the client
<kdub> we'd have to wait for some free buffers before the pause takes effect then
<kdub> which is probably ok, but the response to pause might take some time then
<alf_> kdub: that's what has been happening until recently
<alan_g> It is simple enough to wait for all current requests to finish in communicator::pause()
<kdub> yeah
<alan_g> The problem was that communicator::stop() actually aborts blocked requests
<kdub> right, as long as we're not breaking the order that the buffers are going out to the clients, or returning an error code to the clients its ok
<kdub> i too forget how that precondition led to the conclusion of yesterday's meeting :)
<alf_> alan_g: no, the problem is that, after the swapper-swapper changes, we are throwing an exception from the swapper which leads to an error response
<alan_g> alf_: No, that was just a quieter failure
<alf_> alan_g: the exception is a result of unblocking the client thread (but that didn't used to be the case, unblocking the client thread had no ill effects)
<kdub> but we do that because we force_client_completion()
<kdub> if we're just waiting for the request to be serviced, then we won't have the exception/error msg
<alan_g> kdub: but that used to return a (random) buffer
<alan_g> s/random/handy/
<alan_g> alf kdub - hangout?
<alan_g> alf_: ^
<alf_> alan_g: sure
<racarr> greyback: 10 minutes?
<alf_> kdub: ?
<kdub> sure!
<alan_g> https://plus.google.com/hangouts/_/afc1479538f15eda73de20aca26fc67be70699b5?hl=en-GB
<alan_g> https://code.launchpad.net/~alan-griffiths/mir/fix-1189443/+merge/168639
<racarr> ricmm: Can we do our sync whenever greyback comes back?
<racarr> i.e. hopefully soon. sorry perfect storm of minor inconveniences on my part lol
<ricmm> racarr: hey
<ricmm> we are in a hangout
<racarr> Oh. Sorry
<racarr> link?
<alf_> kdub: SwapperVicePresidentOfInternalOperations :D
<racarr_> Ok now im really awake
<racarr_> alan_g: Want to hear about an interesting requirement on frontend/shell (well depending on how you interpret it)?
<alan_g> racarr_: Want to tell?
<racarr_> Yes! aha
<racarr_> So there is the application lifecycle stuff, where the shell can suspend an application that isn't focused
<racarr_> and then it may just be paused, it may be killed and reloaded later
<racarr_> (and restore its state from an archive it created)
<racarr_> etc
<alan_g> I believe you, go on.
<racarr_> but the whole time it is a "running application", appears in the running application sources, etc
<racarr_> which implies that, a Session should stay around after
<alan_g> WTF?!
<racarr_> it's socket connection closes
<racarr_> (well, it could be at other levels too)
<racarr_> the metaphor isn't that the application is killed it's that
<racarr_> it is paused, and may come back with a different
<racarr_> PID
<racarr_> haha
<alan_g> metaphors are well and good, but "running" is "running"
<racarr_> mm.
<racarr_> I'm unsure if we should punt it entirely to the shell (i.e. they keep track of applications they suspend and mix this in with the mir data source)
<racarr_> or we have some API where like, the shell can
<racarr_> steal the session from a session mediator
<racarr_> and give it back to a new one later
<alan_g> "mir data source"?
<racarr_> well, I mean, say from a session listener, they are building a list of session objects, that they somehow map to
<racarr_> entries in the running app lens, the launcher, etc.
<racarr_> we can say for applications, in paused lifecycle, you just have to keep track of yourself, and mix them in with the list we give you where you want them, etc (and presumably at this point they are no longer mir::*::Session, but just some data the shell is keeping around)
<alan_g> racarr_: you're talking implementation when I'd question the sanity of what the feature
<alan_g> s/what//
<racarr_> alan_g: It's not so much crazier than
<racarr_> swap partitions
<alan_g> racarr_: it is so
<racarr_> alan_g: To be clear, when I say the application serializes it's state
<racarr_> I don't mean it dumps it's memory
<alan_g> racarr_: I didn't read it that way
<racarr_> ok aha
<racarr_> anyway, Id unno, I think it makes sense on a phone, if I have a list of "running applications"
<racarr_> I don't really mind and probably prefer that some are occasionally killed
<racarr_> but its hidden from me by magic
<racarr_> when I have low memory
<alan_g> but to use your analogy - it is like a "swap partition" that loads at a random memory location and leaves the application code to do address fixup
<alan_g> What should be happening is that the connection remains open and that the resurrected application talks on it.
<alan_g> mir doesn't need to care.
<alan_g> s/does/should/
<racarr_> Is it possible?
<alan_g> Well, if no-one tells mir the client has gone it won't know.
<alan_g> The problem is saving and restoring the client state.
<alan_g> (Including sockets, file handles, ...)
<alan_g> racarr_: actually, that doesn't work - the client will have resources (like buffers) that we'd want to release.
<racarr_> alan_g: I think it's fine to consider
<racarr_> the surfaces closed.
<alan_g> racarr_: I think this needs taking through - what resources are needed while the client is suspended? what resources can be reclaimed? What information is persisted in Mir?
<racarr_> well, no, the surfaces close
<alan_g> if the surfaces close, then the shell can't preview etc
<racarr_> well, I think for paused applications it's a snapshot
<racarr_> made at pause time
<alan_g> racarr_: so Mir doesn't need to know it is the same application because it doesn't retain any resources?
<tvoss> alan_g, exactly ...
<tvoss> alan_g, at least not for step one
<racarr_> alan_g: No. I mean this was part of my question
<racarr_> should mir keep track, or do we punt it entirely to the shell
<racarr_> I think, conceptually somehow, even if there are no resources left (besides, the application metadata)
<tvoss> racarr_, I think we should collapse the state of non-running sessions
<racarr_> it seems like Mir (in it's role as the ApplicationManager)
<racarr_> should still know...
<racarr_> so there is one source of information "what are the application which are 'running'" (in the user sense)
<racarr_> tvoss: ?
<racarr_> one level less abstract ;)
<tvoss> racarr_, collapsing the state as in open fd's / buffers etc. We can keep track of non-running, recent apps, but we should start over with collapsing active state
<alan_g> racarr_: the shell takes a snapshot and tells the application to suspend. The application closes the connection and exits. Later the shell tells the application to resume and a new process makes a connection to Mir
<racarr_> alan_g: Yes, the question is in the mean time, the shell
<racarr_> wants to display the list of 'running' sessions. somehow
<racarr_> is it still just a mapping from the SessionManager (i.e. through some hypothetical for_each method or the SessionListener)
<racarr_> or does it need to track the "suspended" applications itself
<racarr_> tvoss: Yes. I think closing the buffers is clear (I hadn't really thought about the fds, but just assumed we would close them)
<racarr_> I am mostly thinking about the API we provide to the shell
<racarr_> over what actually happens to the resources
<tvoss> racarr_, fair point, I have an email drafted and will call in a meeting tomorrow my late afternoon
<racarr_> ok
<alan_g> Mir handles real applications with real sessions. If the shell wants to report something else...
<racarr_> the thing that got me thinking about this, is with the
<racarr_> HUD being out of process and relying on Session IDs
<racarr_> you gain an extra step there
<racarr_> unless somehow the session "stays alive" to mir
<alan_g> How does that make a difference?
<racarr_> I mean, the HUD has all this precomputed data assosciated with one session ID, then when the session comes back with a new ID
<racarr_> even though from the perspective of HUD it's supposed to be the same application
<racarr_> it needs to like, reset or assosciate them somehow
<racarr_> which, seems incorrect :)
<racarr_> but I dunno
<alan_g> racarr_: how does Mir being told about the association help HUD?
<racarr_> Sesion ID's can stay the asame (just as one example)
<racarr_> alan_g: Well, the architecture for the HUD is
<alan_g> HUD is using Mir's internal IDs?!
<racarr_> Uh. Basically. but maybe that is a little flexible
<racarr_> the architecture is the applications push their session ID and their menus to the HUD server on startup
<racarr_> and then receives messages from Mir (well the shell really, over a private API)
<tvoss> racarr_, I don't think that we have settled on a final solution there :)
<racarr_> like, "session 4 focused"
<racarr_> no, iteration 1
<racarr_> :)
<racarr_> anyway that message could just as easily be in terms of
<alan_g> racarr_: so it gets a message from shell saying "here's a new id for old id"
<racarr_> alan_g: Yes.
<alan_g> easier than trying to reuse an id
<racarr_> That is the extra step that made me think
<racarr_> that the concepts were wrong
<alan_g> Either Mir needs to be able to understand suspended sessions and be told by the shell that a new session is a suspended one resuming. Or the HUD needs to understand ID changes.
<racarr_> Mm.
<racarr_> I'm sure understanding ID changes is fine
<racarr_> it's just not the ideal code path
<alan_g> "not the ideal code path" == "it is harder to make a small change to HUD than a large change to Mir"?
<racarr_> I wonder if it is such a hard/large change
<racarr_> I mean what happens if you just close things down, and the shell keeps a reference to the session...
<racarr_> I dunno
<racarr_> at this point I don't think there is a strong enough reason for it anymore aha
<racarr_> just trying to think through the ideas :)
<alan_g> Associating a new ID with existing data ought to be simpler than managing lifetime.
<racarr_> alan_g|life: Cya!
<racarr_> thanks for feedback
<alan_g|life> Hope it helps. ;)
<racarr_> oi, we will keep it simple.
<kdub> alan_g|life, something briefly on screen :)
<kdub> wow, lots of /sb
<racarr_> kdub: Nothing much, I had an awful idea and Alan hates me now
<racarr_> you know, tuesday
<racarr_> :p
<alan_g|life> racarr_: stop projecting
<racarr_> alan_g|life: I'm just teasing :)
<alan_g|life> So am I
<racarr_> alan_g|life: It's hard to tell, Americans are subconciously programmed to conider all british people very serious
 * alan_g|life [evil laugh]
<racarr_> Um. So.
<racarr_> Need to check my brain quickly...
<racarr_> kdub: SurfaceStack iterates, from rbegin to rend to emit the surfaces to the compositor
<racarr_> but houldn't it be the other way around and we just don't notice because
<racarr_> of isngle visibility?
<kdub> 'single visibility'?
<racarr_> kdub: i.e. when we focus surfaces we hide all the others
<racarr_> so it's unclear that rendering is going backwards ;)
<kdub> i guess that depends on how we define the Z ordering
<racarr_> mm
<racarr_> I guess create_surface can insert at the bottom and that's
<kdub> if we insert the top surface at the end, then its ok
<kdub> right
<racarr_> mm.
<racarr_> I feel like it's kind of counterintuitive
<racarr_> with the name stack
<kdub> we should just have a macro to generate unique include guards on all the headers
<kdub>  /end c++ boilerplate grumble
<racarr_> kdub: (fset 'create-mir-class (lambda (&optional arg) "Keyboard macro." (interactive "p") (kmacro-exec-ring-item (quote ([
<racarr_> <<SNIP OF HUNDREDS OF INTEGERS>>
<racarr_> ;)
<kdub>  heh
<racarr> qmake
<racarr> is not the easiest make :(
<kdub> racarr better than Android.mk :P
<olli> RAOF, ping
<racarr> Does someone have time to give a pass on depthify stack (hasn't really changed since merging trunk)
<racarr> hoping to use it asap (tomorrow?)
<olli> robert_ancell, can you pls make sure I get my ppa q answered?
<robert_ancell> olli, yep, have pinged RAOF about it
<kdub_> racarr, i'll take another look
<racarr> kdub_: Thanks :)
#ubuntu-mir 2013-06-12
<RAOF> olli: You should have an email now.
<RAOF> Hm. How do I go about getting another mir-team PPA? I'm not an administrator on the team, and launchpad doesn't seem to list any administrators either.
<duflu> RAOF: Maybe robert_ancell has access (via https://launchpad.net/~pspmteam/+members#active)
<robert_ancell> RAOF, sure, what name do you want?
<RAOF> robert_ancell: Hows about âsystem
<RAOF> robert_ancell: Hows about âsystem-compositor-testingâ
<robert_ancell> RAOF, https://launchpad.net/~mir-team/+archive/system-compositor-testing
<RAOF> robert_ancell: Something to do the weeklyish releasesish into.
<RAOF> robert_ancell: Rock on. Thanks.
<RAOF> robert_ancell: Hm. What is âlightdm-set-defaults --removeâ supposed to do?
<robert_ancell> RAOF, not sure, I think didrocks did that. I tried it and it seems to set the value to "" which is useless
<RAOF> robert_ancell: Because âlightdm-set-defaults --remove --type=unityâ sets âtype=unityâ if it was not already there, and sets âtype=â otherwise.
<robert_ancell> I would change it but I'm not sure if anyone is relying in it in the current form
<RAOF> They can't be, because âfoo=â is a syntax error.
<RAOF> If using it breaks your lightdm.conf, then no one can be using it in anger :)
<robert_ancell> Yeah, I figure so
<robert_ancell> 'foo=' is foo="" right? It's syntatically valid, though I can't think off hand of any useful lightdm keys that are useful with empty strings
<RAOF> Hm. At least if you set âtype=â then lightdm fails to start.
<robert_ancell> RAOF, yeah, because it looks for the "" type and there is none. It would probably make sense for the daemon to ignore the "" value
<robert_ancell> It's the same behaviour as type=lksdhflkajsf
<RAOF> I guess I could do the "" is treated as default thing.
<RAOF> Oh, also, are you currently in the process of removing the hardware cursor from unity-system-compositor?
<RAOF> Or have any current plans to?
<robert_ancell> RAOF, no, but that sounds like something you'd like to do :)
<RAOF> Yes indeed :)
<duflu> RAOF: What would be a nicer alternative? mir_set_cursor_image() ?
<duflu> Obviously we should use a hardware cursor if we can
<didrocks> RAOF: robert_ancell: it was supposed to remove the default if the corresponding type was set
<robert_ancell> didrocks, right, so it should delete the key right? Not set it to black?
<robert_ancell> blank
<didrocks> robert_ancell: indeed, it was doing that at the time :)
<RAOF> duflu: I could go a mir_set_cursor_image.
<duflu> RAOF: I was thinking about it yesterday but told myself to stop daydreaming about features we don't yet need
<duflu> Now we need it?... :)
<RAOF> Well, "need" is obviously a movable feast :)
<RAOF> I *could* just turn it off and use the X software cursor.
<RAOF> But I would use it right now, if it happened to exist.
<alf_> RAOF: can't hear half of what you are saying
<RAOF> hikiko: https://code.launchpad.net/~raof/mir/separate-graphics-buffer-and-display is the branch.
<alan_g> hikiko: Is the dead? It's a week since you changed it: https://code.launchpad.net/~hikiko/mir/mir.fix-virt-destructorS/+merge/167705
<hikiko> oh you are right alan_g
<hikiko> I was looking at the other task
<hikiko> sorry
<hikiko> I will clean it up now
<alan_g> hikiko: That wasn't an order. (I just don't want dead MPs sitting in the list forever.)
<hikiko> no it's a good idea to do it now since I have many questions on the other task
<hikiko> and I emailed the list
<alan_g> I saw the email - but don't know most of the answers
<hikiko> yes, it's not an easy task, so better to finish this branch today :)
<alan_g> (But alf_ does)
<hikiko> thanks for the reminder!
<hikiko> yes, alf_ suggested to start the discussion in the mailing list where anyone can make suggestions
<hikiko> because we discussed some things already in the meeting but still there are some parts that are not very clear
<hikiko> anyway :) I ll fix the destructors first that is quite simpler :)
<alf_> alan_g: I don't have all the answers either... I do have a lot of suggestions, though ;)
<alan_g> will it help if I read the questions and suggestions and then we jump on hangout?
<hikiko> sure alan_g thanks a lot, I will do the destr in the meantime
 * alan_g first needs to wade through swapper-factory-interfaces and see what gardener is doing.
<hikiko> hahaha yes and I'll have a quick lunch in a while :) we can do it later
<hikiko> take your time :)
<alan_g> hikiko: I'll be leaving for lunch in 20min - hangout when I get back? Or do it now?
<hikiko> alan_g, enjoy your lunch
<hikiko> and we do it afterwards
<hikiko> :)
<hikiko> is there any bazaar command that can give you the differences between 2 different branches? (like an extended bzr diff)
<alf_> hikiko: bzr diff --old/--new
<hikiko> alf_, does this work for too completely different branches as well? eg mir.foo mir.bar ?
<hikiko> two*
<alf_> hikiko: I haven't tried (but possibly). In the worst case just cd into one of the branches.
<hikiko> hmm it seems that old-new works with one file :s
<hikiko> I'd like to have a diff like what we get when we propose for merge
<hikiko> with the differences between the 2 branches
<hikiko> is this possible?
<alf_> hikiko: bzr diff --old/--new works fine for me on the whole tree
<hikiko> i did bzr diff --old mir.foo --new mir.bar
<hikiko> and see no differences
<hikiko> :S
<hikiko> lol let me try on trunk just in case that foo and bar have 0 differences :p
<hikiko> cool... it works for the trunk alf_ :p
<hikiko> <--- feels stupid
<hikiko> it was that there were no differences :p
<hikiko> alan_g, I fixed the destructors
<hikiko> when you aren't busy do you want to do the hangout?
 * alan_g wishes there were not so many MPs to review
<hikiko> sorry :( do you want me to remove you from the reviewers?
<hikiko> I have mir-team anyway
<hikiko> (I tried to keep it much much simpler this time alan_g very few fixes outside src)
<alan_g> hikiko: this looks like somewhere you could have used "default":
<alan_g> 139	- ~Display() = default;
<alan_g> 140	+ virtual ~Display() {}
<alan_g> did you try that?
<hikiko> I removed the default from there
<hikiko> because of the nothrow issue
<hikiko> if I add default I'll have to create an empty destructor in every child
<hikiko> like that: virtual ~ChildDisplay() noexcept {}
<hikiko> it's http://stackoverflow.com/questions/11497252/default-destructor-nothrow this problem :/
<alan_g> Wouldn't the existing code hit the same snag if that
<alan_g> Wouldn't the existing code hit the same snag?
<hikiko> it didn't hit it because the destructors weren't virtual
<hikiko> looser throw specifier for 'virtual Y::~Y()'
<hikiko> error: overriding 'virtual X::~X() noexcept(true)'
<hikiko> that's the error I was getting
<hikiko> I can retry though to get 100% sure
<hikiko> but that was the reason I removed the default
<alan_g> ok - I'm still not entirely sure I understand when the problem exists.
<hikiko> alan_g, see comment 15 in the link above
<hikiko> it's a compiler specific issue
<hikiko> I was using clang when I first changed that branch and I was not getting any errors
<hikiko> then I saw that jenkins fails with that looser throw specifier error
<hikiko> and switched to gcc and got it as well
<hikiko> alan_g, also another question (sorry!) I saw your email, why do you suggest that we have a graphics static library and we load it at runtime? I understand what you suggest but I didn't understand very well which problem it solves :S
<alan_g> s/static/shared/ and it makes more sense.
<alan_g> hangout time? hikiko? alf_ ?
<alf_> alan_g: sure
<hikiko> sorry shared
<hikiko> alan_g, I am in
<alan_g> https://plus.google.com/hangouts/_/b984b9ad51b94388fdf039db9aa6e0aa01d46d90?hl=en-GB
<kdub> hello all
<alf_> kdub: Hi!
<alan_g> hello one
<greyback> racarr: awake yet?
<tvoss> alf_, ping
<alf_> tvoss: pong
<tvoss> alf_, can you give me the link for the instructions for installing the mir staging ppa, please?
<alf_> tvoss: http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html
<alf_> tvoss: http://unity.ubuntu.com/mir/installing_prebuilt_on_android.html
<kdub> alf_, are you ok with swapper-factory-interfaces after updating the members/functions to match the classes, and renaming shutdown to force_client_completion?
<alf_> kdub: alan_g: Is https://code.launchpad.net/~alan-griffiths/mir/fix-1189443/+merge/168639 still relevant if are going to revert to the old way of unblocking the client (for non-swapper-switching cases)?
<alan_g> alf_: no - sorry should have WPI'd it
<alf_> alan_g: ok
<olli_> guys... if I want to look at performance on native x vs xmir... what would you advice I use to measure
<olli_> tvoss, kdub alan_g ^
<olli_> RAOF, racarr ^
<alan_g> olli_: what performance matters to you?
<olli_> that is a good question
<olli_> I think atm something like glxgears/fps would keep me happy
<olli_> but then I know there is more to look at
<olli_> so you tell me
<kdub> glmark is probably the best choice, works on mir, surfaceflinger, x
<olli_> I want to get a quick feel for whether xmir has any impact
<kdub> plus alf's an in-team expert on the suite :)
<olli_> do we have benchmark results for the 3 DS?
<olli_> yeah, just missed him by 8min
<racarr> Hi all sorry...here now.
<racarr> Hit my head hard pretty hard yesterday and took extra rest
<alan_g> racarr: time for me to leave
<alan_g> Ouch!
<racarr> alan_g: I'm sure it will stimulate the regrowth of neural connections
<racarr> ...:)
 * alan_g resists temptation
<racarr> See you :)
<racarr> kdub: Yesterday at EOD ricmm was running in to some issues with mir on flipped container android
<racarr> did you hear about these?
<kdub> racarr, yeah
<kdub> well, at least with the issue that we don't use eglGetProcAddress() for eglCreateImageKHR and the like
<racarr> Oh there is a new one
<racarr> /home/phablet/mir/build/src/server/graphics/android/default_framebuffer_factory.cpp(80): Throw in function virtual  std::shared_ptr<mir::graphics::android::DisplaySupportProvider>  mir::graphics::android::DefaultFramebufferFactory::create_fb_device() const
<racarr> 23:06 <ricmm> Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
<racarr> 23:06 <ricmm> std::exception::what: display factory cannot create fb display
<racarr> unless it's solveable by immediate magic I will figure out how to get flipped container on my phone
<ogra_> wait for the currently running build to finish (max 1h) ... it has a bunch of udev fixed
<ogra_> *fixes
<racarr> kdub: Is udev involved? I don't actually know where the graphics devices live in android world...
<ogra_> well, if you use devices on the ubuntu side it surely is involved (since it sets all permissions there)
<kdub> seems a different error
<ogra_> k
<kdub> the udev structure should be 'normal'... what i'd suspect is the filesystem positioning of the graphics libraries
<racarr> Mm, that was my first guess but I dont know what is supposed to be where
<ogra_> well. up to today ueventd (androids "udev") and udev were fighting for the device ownership
<ogra_> android GL libs usually live somewhere in /vendor/lib
<racarr> libgralloc_* or whatever is what we must not be ablet o get here
<ogra_> (/vendor being a link or bindmount to /system/vendor)
<racarr> I guess first it would be best to check if hw_get_module fails or framebuffer_open
<racarr> kdub: It is framebuffer_open not hw_get_module
<racarr> and we are pretty sure surface flinger is dead :(
<ogra_> how did you kill it ... there is a certain process on the flipped images to change android service startup
<kdub> android graphics libraries live in /system/lib/hw, /system/lib/egl, /system/lib
<kdub> or /vendor/lib/hw /vendor/lib /vendor/lib/egl
<kdub> depending on device
<racarr> ogra_: Moved the binary and killed it
<kdub> racarr, nexus 4?
<racarr> kdub: ricmm is testing on galaxy actually, I am setting it up on my 4 now.
<racarr> flipped container jubilee
<racarr> ...sorry lingering effects of the head bang.
<ogra_> racarr, cp /var/lib/lxc/android/rootfs/init.rc /var/lib/lxc/android/overrides/
<ogra_> then edit init.rc to not contain any surfaceflinger blocks
<ogra_> (in the overrides dir)
<racarr> ogra_: Ok. We ust have a new theory though and maybe udev is it XD
<ogra_> that way it will not be started on boot
<racarr> on raring, where its working I have /dev/graphics/fb*
<racarr> flipped container has broken symlinks there atm?
<racarr> I dunno
<racarr> ricardo is testing something it seems
<ogra_> it shouldnt if your container started properly
<ogra_> see the lxc-android-config upstart job ... it creates the links
<racarr> XD. ok apparently the symlinks are fine
<racarr> HMMMMMMMMMMM
<ogra_> ah, good
<racarr> ok guys, well we had a good run
<racarr> but i guess it's time to give up now
<racarr> pack up head home
<ogra_> but there are other files in /dev you might need
<racarr> :p
<ogra_> and not all of them have udev rules yet
<racarr> the failing code path is pretty small, hw_get_module works (i.e. it loads gralloc), framebuffer_open fails
<ogra_> http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/current/ has the most recent flipped image btw ... with a lot less races
<kdub> racarr, fire up the integration tests on the device
<kdub> they will drive some tests that will test gralloc-only operations
<kdub> with some gralloc+openGL tests too
<racarr> Ohh good idea
<racarr> ogra_: Flashing the latest ones now :)
<ogra_> good, tell me how it goes ... they should boot you into the shell and apps should run properly now
<ogra_> if i know they are usable i will announce them to the ubuntu-phone list as experimental developer images :)
 * ogra_ is still downloading here ... slow DSL
<racarr> :)
<racarr> flasssshin
 * kdub is curious too, will give it a try
<racarr> ogra_: Boot to black screen :(
<ogra_> what device ?
<racarr> nexus 4
<racarr> adb shell works, but still drops me in android and there is ubuntu_chroot
<racarr> which I wasn't expecting
<racarr> is that right?
<ogra_> maguro is the only one thats actually known to work
<ogra_> no, that isnt right
<racarr> :) That didn't sound very right
<ogra_> how did you flash it ?
<racarr> http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/current/
<ogra_> right, and then ?
<racarr> downloaded armel+mako.zip
<racarr> and touch-armhf.zip
<racarr> puhed to sdcard
<ogra_> ok
<racarr> intalled from recovery
<racarr> do I need the bootimg file?
<ogra_> no
<ogra_> but the order is essential
<ogra_> armel+$subarch needs to go first
<racarr> ah I did the opposite and I was doing that I was like
<racarr> ...hmm I wonder
<racarr> ...ok
<ogra_> as soon as i'm done testing here i'll mail out instructions
<racarr> flashing...2.0!
<ogra_> (if that rsync ever finishes that is)
<ricmm> kdub: E/IMGSRV  ( 7010): :0: PVRSRVCreateDCSwapChain: Error - 10 returned
<ricmm> E/IMGSRV  ( 7010): :0: framebuffer_device_open: Failed to create flip chain; retrying
<ogra_> did it boot to the shell before you killed SF ?
<racarr> ogra_: Ok I sitll get boot to black but adb-shell
<ricmm> yes
<racarr> is container flipped now :)
<racarr> oh
<racarr> hey heres the shell
<racarr> nice
<ogra_> yay
<racarr> fuck only 69 minutes
<ogra_> thanks
<racarr> of talk time left
<ricmm> ogra_: yea, it booted to shell before I killed SF
<racarr> nice folding launcher :)
<racarr> unortunately at first glance the network indicator doesn't seem to be working
<ogra_> hmm, it should
<ogra_> its the same as on unflipped saucy now ...
<ogra_> try phablet-network-setup if you cant get it to work
<racarr> ogra_: Worked on reboot
<ogra_> ah, good
<ricmm> ogra_: any idea on my weird GL error?
<ogra_> ricmm, not really, no
<racarr> its before GL
<ogra_> looks like a permission thing though
<ogra_> but i'm only wildly guessing
<racarr> a permission that root wouldnt have?
<kdub> it could be any misuse or mis-setup of the driver
<ogra_> yeah
<kdub> it still is the android kernel, right? o.O
<ogra_> yes
<ogra_> same kernerl as in raring
<racarr> ok installing all sorts of boost headers and such on my phone, back in 10
<racarr> fascinating, someone else has produced
<racarr> the same error http://forum.imgtec.com/discussion/2611/pvrsrvcreatedcswapchain-error-on-android
<racarr> (im still installing build dependencies at 41.9 kbs)
<kdub> an my n4, i see a firmware problem
<gotwig> hey there
<racarr> kdub: Firmware problem?
<racarr> Hello :)
<gotwig> Is Mir going to be hold as an independend software project, independend from Unity/ubuntu?
<gotwig> so other software projects could reuse it
<kdub> gotwig, our primary target is to support unity, but if other projects take an interest i don't think anyone would object :)
<tvoss> gotwig, rephrasing it a bit: mir does not assume Unity to be there, but it caters towards its goals
<kdub> racarr, i see that the driver is complaining about not finding the gpu firmware
<racarr> kdub: Oh interesting...where should it bet?
<tvoss> gotwig, does that help?
<racarr> system/vendor/firmware?
<racarr> ogra_: till trying to understand this flipped container...
<racarr> is there a notion of chrooting in to android now?
<gotwig> thanks
<racarr> Apparently rebooting the device after killing sf fixed it on galaxy nexus :)
<gotwig> right now I only see baby basic stuff in Mir
<gotwig> is this normal :D?
<kdub> no one believes me that surfaceflinger is evil
<gotwig> nothing usable :/
<ogra_> racarr, i ahip a script for that, yeah ...
<ogra_> racarr, android-chroot
<gotwig> what can you do with mir right now
<gotwig> I just tested the client demos
<kdub> gotwig, there are qt/sdl branches and stuff floating around
<kdub> but you have to be motivated to track them down if you're interested :)
<racarr> Mm.
<gotwig> how can I get this? https://www.youtube.com/watch?v=E9AzRxsnfTE
<racarr> I mean you can run xmir, qt, sdl, etc.
<gotwig> so, qt is the future for ubuntu? no GTK at all?
<gotwig> because I am/was a GTK developer (haha -..-)
<tvoss> gotwig, gtk will still be around, but unity8 is qt/qml and so is the ubuntu sdk
<racarr> Well, we are focused on Qt (in particular QML yeah)
<gotwig> tvoss, only?
<racarr> but no one is planning to rewrite libreoffice in QML either, so there will be some GTK around for a while ;)
<tvoss> gotwig, only as in ubuntu sdk or unity8?
<gotwig> this new Mir thing
<gotwig> Unity Next (?)
<gotwig> can you tell me how to get a setup like in the video I posted plase
<gotwig> *please
<gotwig> he says he is using mir, but I dont believe it
<tvoss> gotwig, well, I'm pretty sure that it's unity8 on mir :)
<tvoss> gotwig, you should talk to greyback_ if he is around
<racarr> gotwig: Sorry XD, it's not an easy question to answer because a lot is currently in flux for those
<racarr> gotwig: If you were really intent on it, you could build mir, then build ~robertcarr/platform-api/mir2 with
<tvoss> gotwig, or mzanetti
<racarr> ENABLE_MIRSERVER_IMPLEMENTATION=true ENABLE_HYBRIS_IMPLEMENTATION=false
 * gotwig feels ashamed for being a Ubuntu Member and stopping Ubuntu software development
<tvoss> gotwig, why stopping ubuntu software development?
<gotwig> tvoss, well... I found elementary
<gotwig> maybe Unity Next brings me back
<gotwig> Once I did some Unity Scopes/Lenses, it was fun...
<greyback_> gotwig: I hope within a day or two to have a PPA with packages ready so you can easily run unity+mir on your machine.
<racarr> then build ~robertcarr/qtubuntu/mir2 from src/platforms with
<gotwig> greyback_, :3
<racarr> qmake "CONFIG += mirserver"
<gotwig> racarr, so I have to recompile mir, to get unity 8 running?
<racarr> Then! you can build ~robertcarr/unity/phablet-wednesday
<racarr> with ./build -s
<racarr> and ./run -i -m
<racarr> and it should work XD
<racarr> or you can wait on the PPA
<racarr> gotwig: No Mir from the ppa should work
<gotwig> racarr, can I do this all from TTY or a X session
<racarr> you can do it all from an X session
<gotwig> racarr, oh, these steps are for unity  8 ?
<racarr> Yes for something like the video you linked to
<gotwig> racarr, thank you very much
<racarr> :)
<gotwig> fast and clean support :O
<racarr> gotwig: No worries :)
<racarr> you should probably actually
<greyback_> lp:~robertcarr/unity/phablet-tuesday
<racarr> when building platform, api and qtubuntu
<gotwig> greyback_, ?
<racarr> gotwig: Err, greyback is correct on the branch
<greyback_> phablet-wednesday doesn't exist (yet)
<racarr> haha
<gotwig> why do you create branches for every day lol
<racarr> gotwig: Also probably or platform api also do ENABLE_MIRCLIENT_IMPLEMENTATION=true and
<gotwig> or do you do commits every week for every day xD
<greyback_> gotwig: to match his underwear :D
<racarr> CONFIG += mirserver mirclient for
<racarr> qtubuntu
<racarr> and you can test qt client apps too
<racarr> gotwig: Just because like I said things are ina  lot of flux this week haha
<gotwig> When I want to develop something for unity next
<gotwig> do I have to mess with QT?
<gotwig> I liked all this abstraction stuff from Unity, with the dbus interface...
<gotwig> do I need to add the PPA's for build dependencies?
<tvoss> gotwig, the primary languages are qml/qt/c++, for scopes and friends, things are a little different
<tvoss> gotwig, most likely python support and such
<gotwig> what I hate about ubuntu stuff is this extensive use of python -..- its so slow
<tvoss> gotwig, that's going away mostly
 * greyback_ on his bike home
<tvoss> gotwig, we are actively working towards getting python out of the picture for the ubuntu touch
<tvoss> greyback_, don't bike and irc :)
<gotwig> damn that is sexy https://www.youtube.com/watch?v=oaT5JsZQQyU
<gotwig> so guys...
<gotwig> I got the branch, what now?
<kdub> racarr, my container flip is stuck in a reboot-loop, but does yours have /system/etc/firmware/a300_pm4.fw ?
<gotwig> (I already did run ./build -s
<racarr> kdub: Yeah
<racarr> gotwig: Err, did you already do the first
<racarr> two bits i.e. build and install platform API and build and install
<racarr> qtubuntu?
<gotwig> racarr, I dont know :O I just did build -s
<gotwig> racarr, for the mir definition stuff, variables are enough?
<gotwig> qmake: could not find a Qt installation of ''
<gotwig> please help, this is so awesome xD
<racarr> gotwig: I just tried writing up everything
<racarr> here :)
<racarr> http://studio.sketchpad.cc/gmY0M6iqeh?
<gotwig> do I need all this?
<gotwig> Platform-api?
<racarr> Yep
<racarr> platform-api is the new low level library that sits on top of mir and other stuff, that toolkits, or applications which do not want to use a toolkit
<racarr> should use
<racarr> qtubuntu has the qtbackends you need for unity (in the same process as mir) and running apps (out of process)
<gotwig> racarr, do you work for canonical :X?
<racarr> gotwig: They keep paying me so I guess.
<gotwig> racarr, cool, do you live in the UK?
<racarr> Nope. San Francisco CA
<gotwig> Greetings from Germany ;D
<racarr> *waves*
<racarr> Also. yay finaly finished fetching build dependencies on nexus aha
<gotwig> --   package 'mircommon' not found
<gotwig> I know, I sound stupid for a dev xD but I never did qt stuff
<racarr> no worries
<racarr> I guess if you installed mir from ppa you need the mir dev packages
<racarr> gotwig: Which are called libmirserver-dev and libmirclient-dev :)
<gotwig> looking forward to packages ;D
<gotwig> ubuntu devs can do that very good :X
<gotwig> CMake Error: your CXX compiler: "CMAKE_CXX_COMPILER-NOTFOUND" was not found.   Please set CMAKE_CXX_COMPILER to a valid compiler path or name.
<racarr> Do you have g++ ?
<gotwig> tvoss, I found a video about you on youtube ;D
<tvoss> gotwig, about me?
<tvoss> gotwig, or posted _by_ me?
<gotwig> tvoss, yeah, dat Ubuntu OnAir ;D
<racarr> tvoss: Yeah, "A secret look at the private life of Ubuntu Touch's Architect"
<tvoss> gotwig, yup
<racarr> I watch it every day
<tvoss> what?
<racarr> :p
<gotwig> racarr, I am retarded >_> thx
<kdub> haha
<racarr> im just silly
<gotwig> One Night in Ubuntistan ;D
<gotwig> /usr/include/mirserver/mir/options/program_option.h:25:51: fatal error: boost/program_options/variables_map.hpp: not found :X
<gotwig> I installed libboost-dev
<racarr> oh, thi was a recent fix that probably didnt land in the PPA yet
<gotwig> worx
<racarr> ah
<racarr> yeah you need libboost-programoptions-dev in particular
<racarr> program-options?
<racarr> something
<gotwig> racarr, only libboost-dev
<racarr> probably pulls in everything
<gotwig> racarr, qmake: could not find a Qt installation of ''
<gotwig>  
<gotwig> racarr, do I have to download the second branch into the first one?
<racarr> no, it can go anywhere
<gotwig> getting qmake dependencies :X
<gotwig> I need the package for qplatformintegration.h
<racarr> gotwig: Let me try and remember um
<racarr> gotwig: qtbase5-private-dev
<racarr> :)
<gotwig> >_>
<gotwig> thx
<gotwig> did not fix it :O
<racarr> maybe you only had qt4 before and it was trying to build against
<racarr> qt4
<gotwig> :(
<racarr> maybe recreate the makefile (qmake command again)
<gotwig> I already tried some things
<racarr> there should be something in the output between that and build that makes it clear if it is doing
<racarr> qt5 or qt4
<gotwig> qmake runs fine
<racarr> do you have
<racarr> qt5-qmake
<racarr> ?
<racarr> If not, I think you want qt5-qmake and (perhaps?) qt5-default
<gotwig> Project MESSAGE: Warning: unknown QT: core-private
<gotwig> Project MESSAGE: Warning: unknown QT: gui-private
<gotwig> Project MESSAGE: Warning: unknown QT: platformsupport-private
<gotwig> oups, 3 lines ;D
<gotwig> do I have to build with qt5?
<racarr> Hmm.
<racarr> Yeah pretty much
<racarr> I'm not ure that qt4 wouldn't work if you changed a little API
<racarr> but qt5 is the target
<gotwig> I guess I miss a dependency
<racarr> gotwig: So ait, you have qt5-qmake, and qt5-default and qtbase5-private-dev
<racarr> and ran the qmake
<racarr> and...what happens?
<gotwig> *magic pills*
<gotwig> nope :X
<gotwig> I wonder why there is no qt4-qtconfig for qt5
<racarr> I have had weird things with qmake in the past with qt4/qt5
<racarr> could try making sure qmake -v
<gotwig> oh
<racarr> points at qt5
<racarr> and deleting the makefiles
<racarr> I really don't understand qmake, it drives me insane :)
<gotwig> whats wrong with make
<gotwig> lol
<gotwig> and cmake
<gotwig> Project ERROR: Unknown module(s) in QT: sensors
<racarr> gotwig: Are you building from
<racarr>  src/platforms?
<gotwig> YES
<racarr> gotwig: maybe it just means you need qtsensors5-dev?
<gotwig> yeah D
<gotwig> do you maybe got a dependency list for me lol
<racarr> I guess debian/control in the qtubuntu dir
<racarr> should have them
<gotwig> right
<racarr> kdub: Everything is working fine for me nexus 4 flipped
<kdub> yay
<gotwig> racarr, :O
<bregma> hmm, running xmir on the desktop I get both an X cursor and the big pink dogprick mir cursor following it around (only the mir cursor is in the wrong place)
<bregma> any way to staunch that thing?
<gotwig> UnityCore/Lens.h is missing
<gotwig> where can I get that
<racarr> gotwig: It should come from ./build -s successfully completing
<gotwig> I use 13.10
<gotwig> is this supported?
<racarr> gotwig: Could try libunity-core-6.0-dev
<racarr> bregma: Uh...I guess --enable-input=false to mir
<racarr> ould do it
<racarr> since currently xmir doesnt use mir input
<gotwig> racarr, no chance
<bregma> racarr, at least that's a clue, thanks
<racarr> gotwig: I dunno. I don't know much about the unity phablet build system
<racarr> only thing I can suggest, is the build scripts are a little finnicky so clean the tree and build -s again (I think it drops some stuff int he directory one above too that you will want to clean)
<racarr> bregma: MIR_SERVER_ENABLE_INPUT=false in environment will also work...
<racarr> We can add a cursor option too
<racarr> you don't like the big pink orange arrow? ;(
<racarr> we put our best visual designers on the job for over 15 seconds.
<gotwig> racarr, build -s as root?
<racarr> I dont think so the scripts normally ask for sudo when they need them to install dependencies etc
<gotwig> the problem was with the update
<gotwig> build -s did not work for me
<gotwig> because some update sources did not work
<gotwig> I replaced apt-get update with echo "blub" and it seems to work :X
<gotwig> (not because of you guys, but because the bumblebee PPA does not work with 13.10, and I did not knew that :/)
<racarr> Ah, great
<gotwig> Unity is so awesome
<gotwig> I really have to say it
<gotwig> smart scopes are the perfect addition
<racarr> :)
<gotwig> too bad the music is stopped when I leave the dash :/
<gotwig> now I should do some learning for my test.. see you later guys. And thank you very much
<gotwig> I think you convinced me to come back to unity development :X (third party app stuff, huh)
<racarr> gotwig: Good luck! nice meeting you
<racarr> Playing with the component showcase on nexus 4!
<gotwig> something that I did notice
<gotwig> build.sh wants to install libboost-regex-dev
<gotwig> it shouldnt do that
<gotwig> when It does that, it installs version 1.49 I guess, but it needs the newest version 1.53-dev I guess
<gotwig> first it installs one version, than removes packages to get the other, and its a mess
<racarr> oh! thanks, will check
<gotwig> I am on 13.10
<racarr> ...have you guys ever typed
<racarr> "adb hell"
<racarr> you get ADB but the text background is red
<racarr> and the text is yellow
<racarr> im not loosing it right?
<kdub> racarr, haha! i see it too
<kdub> easter eggs
<racarr> XD yeah
<racarr> I only use adb hell now
<kdub> i guess if we have a request for swapinterval 0 in our client api
<kdub> we need both a sync and non-blocking function call
<kdub> we should 'stop the bleeding' and inject pure virtual interfaces around ms::Surface and msh::Surface
<racarr> kdub: ?
<racarr> kdub: p.s. Happy to report unity8 running well on nexus 4 :)
<kdub> oh really!
<kdub> yay
<kdub>  racarr with like... the ability to launch applications?
#ubuntu-mir 2013-06-13
<racarr> kdub: Oh no XD
<racarr> well you can launch them but not from unity
<RAOF> How about switching?
<RAOF> âº
<racarr> RAOF: God you guys are so demanding
<racarr> how much does a shell really have to do!?!?!?!
<racarr> its coming together though :)
<kdub> still cool :)
<kdub> hey RAOF, i built my own mesa driver
<kdub> but get this error:
<kdub> [172730.125463] mir_demo_server[23263]: segfault at 0 ip b6b6b53a sp bf834e1c error 4 in libX11-xcb.so.1.0.0[b6b6b000+1000]
<RAOF> kdub: Your EGL platform detection isn't working; it's falling back to X11 and failing.
<RAOF> What's your mesa driver for?
<kdub> an i965 card
<kdub> does "EGL_PLATFORM=mir" work?
<racarr> I really want to watch a live stream of a concert and try as I might I cant get flash sound working XD
<racarr> so I'm rebooting to OSX
<racarr> Bye!
<racarr> :p
<RAOF> kdub: That should work, I think.
<RAOF> kdub: As long as you actually built the mir platform; you need to explicitly enable it.
<RAOF> kdub: PKG_CONFIG_PATH=$HOME/.local/lib/pkgconfig ./autogen.sh --prefix=$HOME/.local/ --enable-gles1 --enable-gles2 --with-dri-drivers=i965 --with-gallium-drivers=i915,nouveau,r300,r600,freedreno,svga,swrast --enable-shared-glapi --enable-glx-tls --with-egl-platforms=mir,drm,x11 --enable-texture-float --enable-gbm --enable-openvg --enable-gallium-egl --enable-gallium-gbm
<RAOF> Is what I use; you probably want to replace the --with-gallium-drivers bit to --with-gallium-drivers=
<RAOF> It's remarkable how quickly you learn to ignore the huge stomping orange arrow on your screen.
<duflu> Luckily it is moveable :)
<RAOF> duflu: Not once XMir starts :)
<duflu> robert_ancell: Umm saucy just builds mir without modification. There are lots of notes/warnings to fix but no errors.
<robert_ancell> duflu, all the tests pass?
<duflu> Yep
<robert_ancell> Did it build with -DNDEBUG?
<duflu> Doesn't appear so
<robert_ancell> duflu, did you run cmake from scratch?
<duflu> I ran it per usual. What's "from scratch"?
<robert_ancell> duflu, i.e. cleared out existing build
<duflu> robert_ancell: Yes it's a fresh machine
<duflu> from scratch
<robert_ancell> and definitely gcc 4.8?
<duflu> Yep
<robert_ancell> weird
<duflu> gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1)
<duflu> Perhaps gcc got updated to fix spurious errors recently
<RAOF> Clearly not, because mir just failed to build in the PPA again.
<RAOF> Huh.
<RAOF> I wonder how that builds on raring?
<RAOF> std::cerr should not be defined in <fstream>
<tvoss> RAOF, ping
<RAOF> tvoss: Pong.
<tvoss> RAOF, good morning :) how is it going?
<RAOF> Fine!
<RAOF> It looks like my trivial patch makes Mir build on saucy again, so I can start getting rid of the ugly orange pointer in unity-system-compositor âº
<tvoss> \o/
<tvoss> RAOF, did you see the mail I forwarded you? :)
<tvoss> olli, good morning :)
<olli> good morning gentlemen
<RAOF> tvoss: The sabdfl experiences with unity-system-compositor + XMir?
<tvoss> RAOF, yup
<olli> RAOF, that was good :)
<tvoss> RAOF, I think he ran without hw accel: <sabdfl> saucy!
<tvoss> <sabdfl> OpenGL vendor string: VMware, Inc.
<tvoss> <sabdfl> OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.2, 256 bits)
<tvoss> <sabdfl> OpenGL version string: 2.1 Mesa 9.2.0-devel
<tvoss> <sabdfl> OpenGL shading language version string: 1.30
<tvoss> <sabdfl> OpenGL extensions:
<RAOF> Hm.
<olli> gm morphis
<RAOF> In my experience that happens when lightdm fails to set up the drm permissions properly.
<tvoss> RAOF, yup
<RAOF> The output of âLIBGL_DEBUG=verbose glxinfoâ is the a diagnostic in that case; it'll generally say "i965: failed to open drm device: EPERMâ or words to that effect.
<tvoss> RAOF, sabdfl sent me his Xorg.log, just forwarded it to you
<RAOF> Hm. That doesn't seem to be an xmir session.
<tvoss> RAOF, yup, that's what I was thinking, too :)
<duflu> RAOF: So you really think a mir_set_cursor_image() is the right solution to use hardware cursors with xmir?
<duflu> I can't think of a better one. And general cursor management/theming should be kept out of the server
<RAOF> duflu: Well, xmir certainly needs *some* way of setting the cursor image. It doesn't necessarily have to be âhand a blob of pixels to Mirâ, but that's a reasonably simple first go.
<duflu> Yeah. I noticed GBM will fail unless you give it precisely 64x64 but that's a detail that can be hidden behind the API
<duflu> RAOF: Or should the cursor be a surface to take advantage of IPC?... :)
<duflu> Hmm, actually I'm not sure that's useful. Certainly more complex
<tvoss> RAOF, duflu why don't we enumerate different cursor types for a first cut, and make it more configurable in the future?
<duflu> tvoss: Not even types. Just leave it up to the toolkit to upload an image when it wants a different one
<duflu> I thought
<duflu> Hmm, though that makes resizing cursor management different when building a shell
<duflu> -different + difficult
<tvoss> duflu, right, it exposes a lot of internals to the client
<RAOF> The other option would be to treat the hw cursor as an overlay.
<tvoss> duflu, I think it makes more sense for the shell to decide the actual pixels of the cursor, and the client is able to choose from a pre-defined set
<RAOF> tvoss: I don't believe that works for XMir; I'm pretty sure some part of the X stack expects to be able to do arbitrary cursors.
<duflu> Although if the shell is an internal client then the mir_set_cursor_image() works still
<tvoss> RAOF, ack, fully understood
<tvoss> duflu, exactly
<duflu> I'm trying to avoid (1) having an enum of cursor types and (2) managing them in the server
<tvoss> duflu, I guess I would like to understand why you want to avoid an enum. Got a use-case/example for me?
<duflu> Not that I'm working on cursors at all right now
<duflu> tvoss: It's about limiting the functionality and responsibility of the server
<duflu> A shell will need "types" but the core server library not
<duflu> A touch shell for example won't need anything. Depends on the shell.
<tvoss> duflu, fair point, but what is exposed to the client?
<RAOF> If we knew how we were handling overlays, this *could* be done with overlay surfaces.
<duflu> tvoss: There will be a set_cursor_image() type function regardless but I'm trying to avoid the need for a set_cursor_type() in the core client API. It can go elsewhere.
<tvoss> duflu, but how do you prevent a client from setting an arbitrary cursor image?
<tvoss> duflu, that will break consistency, wouldn't it?
<duflu> tvoss: You don't. Clients are always allowed to, and some really need it
<duflu> Some apps will break otherwise
<RAOF> You don't, but it can only control its cursor image while said cursor image is over one of its surfaces.
<RAOF> (Or is otherwise owned by said surface, such as in a drag and drop operation)
<duflu> RAOF: Yeah then you end up with the ugly situation that X has where the arrow is different depending on the window :(
<tvoss> duflu, RAOF exactly, that's what I'm afraid of
<RAOF> I'm not sure that's avoidable.
<duflu> OK. I guess the client API is already gathering very specific enums (e.g. surface type/state) already. Why now cursors too
<duflu> -now +not
<tvoss> RAOF, duflu why don't we say enum first, mapping to the generic function, and we will see how far we can get with only an enum exposed to clients?
<RAOF> Some clients *are* going to want a pixel-perfect representation of their specific cursor (image manipulation programs are particularly fine candidates for this)
<RAOF> Also, games.
<tvoss> RAOF, fair point
<duflu> Games tend to use their own texturing for cursors. Not hardware or display server cursors
<tvoss> RAOF, is there value in only allowing set_cursor_image for fullscreen surfaces?
<RAOF> duflu: You've not noticed the âUse hardware cursorâ option that many games have?
<duflu> No
<RAOF> In my experience it's quite common.
<RAOF> I'm pretty sure Mass Effect had it, I seem to recall XCom having it, Civ 5 having it, â¦
<duflu> Oh I totally agree you need to be able to set an arbitrary custom cursor for some apps anyway
<RAOF> tvoss: re: fullscreen surfaces only - I don't know.
<RAOF> tvoss: I'm not sure that the situation we're trying to avoid - randomly different cursor themes for different windows - is best solved by not allowing different cursor themes.
<RAOF> I don't think it's a significant problem in X anymore. I think the solution is to make it easier to do right thing than the wrong thing, which I think is basiacally equivalent to saying âmake sure the toolkits do the right thing by defaultâ
<RAOF> Grr.
<RAOF> Why do we build with -NDEBUG?
<duflu> RAOF: I have a fix
<duflu> Just proposing now
<RAOF> duflu: For the whole shebang, or jsut teh NDEBUG bit?
<duflu> RAOF: For everything.
<RAOF> Hurray.
<RAOF> Allow me to approve that post-haste.
<duflu> Though now I notice that the debuilt tests are failing. Don't fail otherwise on saucy :/
<duflu> RAOF: Not just proposing yet :/
<RAOF> Well, that'll give me time to handle the mesa sru for mlankhorst then :)
<duflu> RAOF: Sorry. Something so simple should not have taken so long... https://code.launchpad.net/~vanvugt/mir/saucy-build/+merge/169108
<racarr> Just to make sure everyone not on mir list knows
<racarr> will be out in the morning at the dentist :)
<racarr> :( really
<alf_> racarr: enjoy :P
<didrocks> alf_: you will eat some candies, thinking about him?
<alf_> didrocks: :)
<RAOF> Chocolate!
<RAOF> racarr: Oh, iff you're still here - what bit of Mir infrastructure do I need to inject to get unity-system-compositor to eat input?
<racarr> I guess I'm kind of surprised that it's not eating input
<racarr> we still have to disable control sequences
<racarr> maybe the unity-system-compositor configuration
<racarr> removes input?
<racarr> it doesn't
<racarr> look like it ;) um
<racarr> not sure on the top of my head
<RAOF> racarr: Ta :)
<RAOF> racarr: The other possibility is that it's fixed in a later Mir than has built for saucy :)
 * RAOF goes baby-feeding.
<tvoss> alf_, ping
<alf_> tvoss: pong
<tvoss> robert_ancell, ping
<robert_ancell> tvoss, hello
<robert_ancell> yay, I can do a full dist-upgrade now without it trying to remove everything :)
<tvoss> robert_ancell, \o/
<robert_ancell> RAOF, damn, when did mesa become such a massive package?
<robert_ancell> 49.4M!
<RAOF> robert_ancell: There's a âdon't statically link 10MB worth of stuff into every DRI driverâ patch that I haven't applied to the PPA packages. That makes it somewhat smaller ;)
<alan_g> robert_ancell: Sorry, I just realized that we have a meeting just when I've a physio booked.
<robert_ancell> alan_g, can you do it now?
<alan_g> robert_ancell: yes
<robert_ancell> tvoss, I can confirm you do get a big ugly orange cursor :)
<robert_ancell> tvoss, did it work for you?
<tvoss> robert_ancell, now: yes, but it hang on boot an hour ago
<tvoss> robert_ancell, argh
<robert_ancell> tvoss, part of the problem there might be we don't have the more aggressive plymouth changes that went into Ubuntu after we forked the packaging
<robert_ancell> (upstart changes)
<robert_ancell> and Mir+Plymouth don't play so well together as X+Plymouth (which already isn't very well)
<tvoss> robert_ancell, so we should pull them over then
<robert_ancell> tvoss, the changes are 1.6.0-0ubuntu2.1 if you want to test
<robert_ancell> I'm making a lightdm release tomorrow, was planning on syncing all the packaging then
<tvoss> robert_ancell, great, thank you. Can you drop a mail to mir-devel once done?
<robert_ancell> tvoss, about what?
<tvoss> robert_ancell, when you synced the packages
<robert_ancell> that doesn't sound like a particularly interesting post...
<robert_ancell> bye all
<alan_g> alf_: fix-1189443 had merge conflicts when you approved. (I've just pushed resolution)
<alf_> alan_g: ok
<alf_> alan_g: @saucy-build, what I take from your comment, is that it would be even better for us to remove this test (since it is testing a precondition)
<alan_g> alf_: I'd be happy with that too. (And also, separately, with you suggestion of a MIR_ASSERT)
<alan_g> "It is your problem if you pass me nullptr - don't rely on ME to check it!"
 * alan_g remembers days of getting bug reports "this one's yours - it is asserting in your code..."
<alan_g> alf_: care to recheck fix-1189443?
<alf_> alan_g: sure
<alan_g> alf_: do you think the team needs a discussion on precondition checking on mir-devel?
<alan_g> hikiko: it looks like it should be quick to fix and land https://code.launchpad.net/~hikiko/mir/mir.dest-tmp/+merge/168934
<alf_> alan_g: Would it be worth to put these guidelines in our hacking guide? If so, we can use that as our starting point for a discussion. Otherwise, mailing list works fine, too.
<alan_g> alf_: I was wondering how close to agreement we (as a team) are. I know tvoss wasn't in agreement with me when he added the tests.
<tvoss> alan_g, enlighten me please :)
 * alan_g wonders "hacking" or "coding guidelines"
<alan_g> tvoss: about writing tests for the reporting of precondition violations
<alf_> alan_g: ok, if you suspect there may be disagreement, the ML sounds like a good place to start
<alan_g> tvoss: see discussion on https://code.launchpad.net/~vanvugt/mir/saucy-build/+merge/169108
<hikiko> alan_g, that's what I am doing now
<hikiko> cross compiling and fixing
<alan_g> hikiko: I hope you don't feel I'm nagging. ;)
<alf_> alan_g: "coding guidelines" is a better match, if we create it we should also move "Error handling strategy" from HACKING
 * alan_g decides to try saucy again
<hikiko> haha no alan_g :) better to finish with that before I go to something new.. I don't like to see it there either
<tvoss> alan_g, ENOCONTEXT :)
<tvoss> alan_g, gimme a few
<alan_g> tvoss: it is not an important use of your time
<tvoss> alan_g, okay, cool :) from a quick glance: I'm as convinced as alf :)
<alan_g> (just satisfying your curiosity)
<gotwig> :(
<gotwig> When are packages coming for unity next + mir
<tvoss> greyback, can you give gotwig some eta for unity next + mir packages?
<greyback> tvoss, gotwig: give me 2 hours to build them and verify them
<tvoss> greyback, \o/
 * tvoss wants to buy beers for greyback
<gotwig> alcohol free beers ;D
<gotwig> I am just too stupid to compile all dat unity greatness *.*
<gotwig> I finished it, but when I start it via ./run (in X session) I cant use any apps. What am I missing?
<greyback> gotwig: ah, so you got shell working?
<gotwig> greyback, when you are going to release it as a package (and if it works) I am sure OMG! Ubuntu is going to do an article ;)
<gotwig> greyback, yeah, but no apps?
<gotwig> greyback, and also it didnt work with mir, for me
<gotwig> It said it cant load "ubuntu"
<greyback> gotwig: we've not got the apps working with shell yet
<greyback> there's a bit more to do there
<gotwig> than I manually changed it to "ubuntumir" in the run file, but it didnt work either
<greyback> lemme see, things changed on Tuesday and I'm not up to speed
<gotwig> greyback, what do you mean? I cant use Unity Next apps in Mir?
<gotwig> I got segmentation fault
<gotwig> as the error
<greyback> gotwig: not yet. Unity shell and Mir need more development to support applications and window management of those apps
<greyback> gotwig: we've got work yet to do.
<gotwig> greyback, so the dude on youtube is a liar ;X?
<greyback> gotwig: what was the link again? Let me check it
<gotwig> https://www.youtube.com/watch?v=E9AzRxsnfTE
<gotwig> oh, there are no apps ;D just screenshots I  guess?
<greyback> gotwig: ah, I see it. In that video, it was running Unity with the fake built-in apps, a feature we only use for testing.
<greyback> gotwig: exactly
<greyback> gotwig: proper app support is coming, but will be a few weeks before all the bits & pieces connect
<gotwig> ok ;X
<gotwig> which advantages has using Mir right now for me as a developer...
<greyback> gotwig: sorry for the confusion, I totally see where you're coming from
<gotwig> how native are X applications going to feel?
<gotwig> They cant fit in the new UI :X
<greyback> gotwig: for an app developer point of view, you should not need to care about Mir at all. If you write in Qt, everything will work exactly as they do under X
<gotwig> "without X bindings"
<tvoss> gotwig, to pick up from yesterday: if you are doing a gtk app, and someone wires up gtk to Mir, you don't need to worry
<tvoss> gotwig, even if not, we will have a rootless xserver that is fired up on demand for apps that talk X. But that's not there, yet
<gotwig> but GTK is so primitive, when you compare it to QT :/
<tvoss> gotwig, then why not learn qt?
<gotwig> C++ .. ouch
<gotwig> its so different
<tvoss> gotwig, why not do qml then?
<tvoss> gotwig, easy to get started with
<tvoss> gotwig, and learning c++ is always a good idea :)
<tvoss> alf_, can you point me to the adjusted x driver branches?
<alan_g> learning c++ is a lifetime journey
<alf_> tvoss: https://code.launchpad.net/~mir-team/*
<tvoss> alan_g, agreed, but every journey has a start
<racarr> Good morning! (for 10 minutes before I go to the dentist)
<alan_g> Keep smiling
<smspillaz> ahah, dentists
<ogra_> yeah, racarr gets all the fun ... mean ...
<smspillaz> I was in for a bit of a shock the last time I went - everyone at that clinic had quit and all the staff were replaced by people who ... looked like they might also pass as part time models
<smspillaz> it was a bit surreal
<gotwig> I broke my 13.10 :/
<kdub> with ms::Surface or msh::Surface, would anyone object to putting a pure virtual interface around those classes? they're kinda ballooning as a concrete class
<alan_g> kdub: ms::Surface really ought to be a private implementation class - not an interface
 * alan_g thinks msh::Surface is a mess and doesn't know what to make of it
<kdub> yeah, i guess in carving out a signal path for the swapinterval0 ipc message, i had to cross the "ms/msh::surface swamp"
<kdub> as I've begun to think of it :)
<alan_g> \o/ (someone else thinks there's a problem there.)
<alan_g> kdub: we should hatch a strategy for draining the swamp. Not sure "putting an interface around" is the right answer though.
<kdub> yeah, i'm just trying to find a way to drive the interfaces in the tests
<kdub> and they're not very mockable without interfaces
<alan_g> I share your pain
<alan_g> kdub: isn't the comment at the top of ms::Surface still true? Because if it is I can't see an interface helping you.
<kdub> well, i think that the inheritance from both Renderable and SurfaceTarget might need re-evaluation
<alan_g> Oh?
<kdub> from what I see, we're just doing it because we don't have a 'surface state' object that is useful to both the input and graphics world
<kdub> like, the compositor needs a 'surface state' (where is this in the scene graph) as well as some access to the graphics buffer
<kdub> and the input needs access to that same state, as well as some input objects
<kdub> but we use multiple inheritance to jam all that together into ms::Surface
<alan_g> Do you have something against multiple inheritance?!
<kdub> not generally :)
<alan_g> We have an object that is useful to the graphics (implements Renderable) and input (implements SurfaceTarget). Why is that not reasonable?
<alan_g> Where does "jamming" come into it?
<alan_g> (Not saying you're wrong - just want to understand)
<kdub> i was just thinking that if the SurfaceStack held an object that held 3 things (graphics, input, state) and handed out (graphics, state) to the compositor and (input, state) to the input manager
<kdub> then that object would be analogous to  msh::Surface in our current code
<alan_g> "state" being?
<kdub> "this surface's place in the world", position, size, transformation, etc
<alan_g> So, ms::Surface is that object, that Renderable is (graphics, state) and SurfaceTarget is (input, state)?
<kdub> right
<kdub> and then we could present just the state to the shell interfaces
<kdub> (which don't exist, but the shell probably needs a MVC-like view of the surfaces)
<kdub> racarr^^
<kdub> oh, he's at the dentist
<alan_g> kdub: OK, that would be a new SurfaceMark2 interface in ms
 * alan_g hopes that name isn't taken seriously
<kdub> alan_g, right. that concern about a view of the 'state' for the shell's purposes just comes from
<kdub> i don't see how a shell object would access that info currently
 * kdub is really opening up a can of worms today :P
<alan_g> I'm happy with that idea.
<alan_g> That was the extent of your changes to ms::Surface? What about the mess^b msh::Surface?
<racarr> Back!
<kdub> alan_g, sorry, got distracted
<alan_g> kdub: np - I'm about to leave anyway. racarr can take over discussion of msh::Surface
<racarr> *blank*
<alan_g> racarr: kdub has decided to start draining the "msh::Surface" swamp
<alan_g> racarr: kdub has decided to start draining the "msh::Surface swamp"
<kdub> just start thinking about it :)
<kdub> yay, my mesa improvements work... now to figure out how to show raof on github
<racarr> kdub: Sorry I dropped out of our conversation earlier...I got distracted by the stuff I am doing with input acceptance tests
<racarr> think I just finally got a test fixture I am happy with, at least the first part...trying to make it trivial to write input tests with multiple clients and synthetic input
<kdub> np, i got distracted cleaning up mesa's mir platform :)
<racarr> its a party all around XD
<kdub> RAOF, ping
<RAOF> kdub: Yo.
<RAOF> Mesa? Woot!
<kdub> RAOF, i made the egl dri2 driver upstreamable while adding swapinterval0 hooks
<kdub> well, hopefully more upstreamable
<kdub> i submitted a pull-request on github with the cleanup
<RAOF> Less /* do stuff */? âº
<RAOF> Hurray!
<kdub> basically, we now have a native type for egl displays and surfaces
<kdub> and i removed 'mir_client_library.h" from the platform_mir.c
<kdub> it pairs with lp:~kdub/mir/gbm-cleanup
<kdub> so hopefully we can get those both reviewed and land them at the same time
<kdub> maybe monday :)
<nall> could this be why I'm getting an error "Can't create a surface"
<nall> "Can't initialize EGL" ?
<nall> It's thrown when calling mir_surface_is_valid which checks the protocol buffer for an error and I'm having trouble figuring out what actually sets this error.
<RAOF> nall: That's what happens when the call to create a surface fails.
<RAOF> nall: In the past there was a bug with colour formats that caused that sort of problem. The other option is that you've got a mismatched mesa version, since Mir requires some patches to work.
<nall> The method I used for installation was to install the pre-compiled packages first to ensure I had the right mesa libraries.  The I built from source installing with prefix=/usr to overwrite the precompiled mir packages.
<nall> I'm trying to get it to work on VMWare.  I'm building from source because I had to add vmwgfx (VMWare's drm driver) to a drivers list to fix a bug when calling drmOpen.  On doing that it loads the driver but fails to create the surface.
<RAOF> nall: Oh, cool.
#ubuntu-mir 2013-06-14
<RAOF> nall: So, the chances are that this is a problem somewhere in the EGL stack. It might be time for two-machine debugging - start up mir_demo_server under gdb, and break on...
<RAOF> Something or other. What would that be...
<RAOF> Probably mf::SessionMediator::create_surface
<nall> Yeah there are I think 6 definitions for create_surface in various classes.  That's the first one called so I'll start there.  I've never used gdb before, didn't even know it existed.  I've just been grepping the source and putting puts() in various places.  Thanks for the tip.
<RAOF> Yeah.
<RAOF> Single-stepping is pretty awesome.
<racarr> might be interesting to test render_to_fb and render_surfaces first
<racarr> s/interesting/easier/
<nall> I'll try that too.  Thanks
<robert_ancell> racarr, still here?
<tvoss> RAOF, ping
<RAOF> tvoss: Pong.
<RAOF> Up early?
<tvoss> RAOF, yup :) how is it going?
<RAOF> Well.
<tvoss> alf_, ping
<alf_> tvoss: pong
<alf_> Saviq: tvoss: At what point in the lifecycle of a session does the shell need to take a snapshot of a session/surface? Just before it switches away from it?
<Saviq> alf_, or to it
<alf_> Saviq: why when to it?
<Saviq> alf_, two cases: session is born, the app slides from the side
<Saviq> alf_, or we switch between apps
<Saviq> alf_, in both cases there are transitions for both the currently and the next focused app
<Saviq> alf_, at the moment basically whenever an app appears not in its final position (fully on screen, bar the panel)
<Saviq> alf_, is when a snapshot is used
<alan_g> I'm in the process of updating to new images and find that I can't run mir on my updated N4
<alan_g> # ldd /bin/mir_demo_standalone_render_surfaces | grep not\ f
<alan_g> 	libhardware.so.1 => not found
<alan_g> Am I doing something stupid?
<duflu_> alan_g: It's all part of the various branches/bugs I'm working on
<duflu_> And shall have to stop soon
<alan_g> duflu_: ack
<duflu_> I give up...
<greyback> Hi folks, anyone using the mir staging ppa on saucy at the moment?
 * alan_g thinks that is an ominous question
<greyback> I added the PPA yesterday, but on reboot lightdm failed to start. Seemed Mir did start to launch ok, as I got the cursor, but then that died.
<greyback> :)
<alan_g> I updated a machine to saucy yesterday - but not tried using Mr as system compositor
<greyback> alan_g: that's a no then? :)
<greyback> no worries, just a head's up
<alan_g> well, I used the ppa - but only for building mir
 * alan_g isn't likely to use system compositor until mir can be nested
<kdub> good morning
<alan_g> kdub: good afternoon
<kdub> status, mp'd a cleanup for mesa/gbm, probably will tackle the egl symbols bug 1189938 in mir this morning
<ubot5> bug 1189938 in Mir "android links to EGL extension functions directly" [High,In progress] https://launchpad.net/bugs/1189938
<racarr> Morning
<alan_g> afternoon
<racarr> Just spilled my morning coffee halfway through....my "habit brain" is revolting
<racarr> :)
<tvoss> racarr, rofl :)
<racarr> tvoss: What happened with that app-centric world meeting
<racarr> yesterday when I woke up I saw that it had been rescheduled
<racarr> in to the past?
<ogra_> and everyone but you attended !
<racarr> oh did it actually happen yesterday?
<ogra_> :)
<racarr> I was at the dentist anyway
<ogra_> nah, kidding
<tvoss> racarr, it happend, it is a weekly one now
<racarr> oh ok
<racarr> ill come next week
<tvoss> racarr, yup
<alf_> kdub: Is there a fast way to get the pixels of an android buffer? glReadPixels() from an FBO backed by our buffer as a texture takes >50ms on Nexus4 :/
<alf_> kdub: (for a 512x512 surface)
<kdub> alf_, yeah, glReadPixels on adrenos is reallly slow
<kdub> you can access the buffer's pixels via gralloc
<racarr> we have some tests that do it right?
<kdub> example code at tests/draw/android_graphics.cpp
<kdub> adreno is tile-based gpu, so glReadPixels is tricky to do quickly
<alf_> kdub: thanks, I think that we will need to have a Buffer::pixels() method, and use that to get the pixels, fall back to glReadPixels()/FBO if ::pixels() fails (e.g. on GBM we can't really get the pixels of a hardware buffer, they may be tiled).
<racarr> alf_: If we can peek at the buffers, I don't understand why we need software
<kdub> well :) another alternative is to have anothe class that we can plug the native handles into, and it can provide us with the pixels
<racarr> copy
<alf_> kdub: sure
<alf_> racarr: That's the ubuntu API for now, but there are also some synchronization issues with making buffers available to the shell outside of the compositor.
<alf_> racarr: One idea discussed is for mir to give out a buffer to the shell when an app closes
<racarr> oh when it closes, of course, sorry
<racarr> alf_: ^
<alan_g|EOW> Bye all!
<racarr> Bye!
<tvoss> alan_g|EOW, bye
 * racarr enters the "Q"
<racarr> this half a cup of coffee thing just isnt working out for me
<racarr> brb
<kdub> hey racarr, updated the doc in https://code.launchpad.net/~mir-team/mir/saucy-android/+merge/169365 if you could take another look?
<kdub> i have a egl-extensions branch that can land right after that one
<kdub> hmm, actually... its probably just easier to land all the fixes at onec
<racarr> kdub: Should we merge it/
<kdub> yeah, i think so
<kdub> i'll mp the extensions branch within an hour
<racarr> Ok
<racarr> kdub: "
<racarr> apparently if you bzr commit, change, save commit message, it needs a second commit
<racarr> " :)
<racarr> haha the more you know
<kdub> yeah :P
<bschaefer> hello everyone, i've uploaded my current mir support for sdl1.2 on the mir ppa if anyone wants to try it out :)
<bschaefer> (games are work :)
<bschaefer> working*
<racarr> bschaefer: Excellent
<racarr> ill try it out the next time im looking for something to play with
<bschaefer> racarr, thanks :), and cool! Still need to fix some odd thing with SW rendering...but I've a work around for now
<bschaefer> (copying the entire screen over to mir...)
<racarr> hmm
<racarr> ill try and look at that
<bschaefer> racarr, im making a different ppa to show you what I mean, its strange, I copy the changes for that frame over to mir, and swap buffers
<racarr> one day we should port it to the platform-api which should mostly be find and replaceish stuff
<racarr> it doesn't really matter now, but might as more application description stuff, etc comes in
<bschaefer> yeah, that would be nice
<bschaefer> racarr, its as almost mir doesn't paint the alpha? Or assumes its double buffered...im not very sure :)
#ubuntu-mir 2013-06-15
<kdub> saucy broke my computer -_-
<racarr> :(
<kdub> oh well. racarr do the jenkins errors about the android/saucy fixes make any sense?
<kdub> seems like maybe a spurious bug in ProtobufCommunicator test case
<kdub> filed a bug about it lp:1191191
<redtape|renegade> OT | Slightly unusual story but good nouns if you wann- a name for your project , I guess .. :::: http://cnet.co/11DbkPS  ::::
<redtape|renegade> leaves
#ubuntu-mir 2013-06-16
<arsson> so i got saucy, one of the dayly builds. need some instructions to get this mir rock?
<ogra_> its probably more likely to find someone here during the week
<arsson> i use mir ppa but there is no actual mir package
<arsson> o
#ubuntu-mir 2014-06-09
<mterry> Hey folks!  I'm trying to figure out lifecycle event management for mirserver instances.  If USC gives the mirserver a life cycle event, which piece of code might end up calling SIGSTOP on the shell?
<mterry> kdub_, racarr__ ^ ?
<racarr__> mterry: "Calling SIGSTOP on the shell"A
<racarr__> ?
<mterry> racarr__, well
<mterry> racarr__, what seems to happen is that the unity8-greeter *sometimes* will be SIGSTOPPED when inactive
<mterry> racarr__, seemingly due to Mir lifecycle management
<mterry> racarr__, the unity8 shell doesn't seem to have this problem
<racarr__> interesting, and they are both usc clients?
<mterry> racarr__, and the greeter doesn't always.  I'm trying to trace down the origin of the SIGSTOP
<mterry> racarr__, yeah
<mterry> racarr__, platform-api has some code to SIGSTOP, but I didn't think USC ran the platform-api code.  Does Mir do any default interpretation of those events, or does it simply pass them on to clients?
<racarr__> prettysure it just passes it on...maybe platform API does some interpretation
<racarr__> I dont think things are wired to sigstop themselves though?!
<racarr__> so lets see whats going on
<racarr__> mterry: So the normal process lifecycle management sigstop stuff
<racarr__> is processcontroller.cpp in unity-mir...
<racarr__> there is also this weird
<racarr__> serverstatuslistener.cpp
<racarr__> which raises SIGSTOP as part of some dance with upstart...
<racarr__> maybe that is your offender
<mterry> racarr__, right
<mterry> racarr__, I don't *think* so
<mterry> racarr__, not the upstart bit though.  greeter doesn't set that variable and there is no corresponding SIGCONT for that one
<racarr__> (the second part of that could be the problem though right?)
<racarr__> second argument to signal handler, siginfo_t
<racarr__> has pid of sender
<racarr__> so maybe best to start there
<mterry> racarr__, well the greeter CONTs fine
<mterry> racarr__, and will STOP/CONT as it becomes active/inactive
<mterry> racarr__, and processcontroller looks like it's used for shell apps, not shells themselves.  :-/
<mterry> racarr__, good point about pid of sender
 * mterry goes afk for a bit
<racarr__> mterry: Yes...I don't think processcontroller could be involved...
<racarr__> I was just trying to locate all the sigstops lol
<mterry> fair!
<racarr__> the one in platform API is for the old surface flinger compatibility
<mterry> racarr__, oh really?  You don't think that's still used?
<racarr__> errr let me look more carefully lol but I dont think so
<mterry> racarr__, the stuff in default_application_manager.cpp is what I was looking at.  Not sure when it's used though
<racarr__> yeah 98% sure thats its the old
<racarr__> surface flinger out of process window manager
<racarr__> thing
<mterry> racarr__, I would love it if we just deleted all non-Mir ways of doing things
<racarr__> I kind of thought I heard we had done that lol
<racarr__> but apparently now
<racarr__> not
 * mterry goes afk for realz
<racarr__> cya
<kdub_> mterry, i've seen bad drivers use signals (maybe even sigstop)
<kdub_> AlbertA, with usc and alpha, is it that the nested display doesn't fill the alpha channel?
<kdub_> i'm finding I have to disable the alpha blending to get pixels with the overlay work
#ubuntu-mir 2014-06-10
<RAOF> Bah!
<RAOF> QT CREATOR!!!!!!!!!
<anpok> alf_: do you have any thoughts regarding a new separate namespace for main loop, timer service..
<RAOF> I don't think it's a terrible idea, but I'm not sure what it would be.
<anpok> scheduler is a hot candidate.. like event_loop
<RAOF> That's a pretty decent name.
<alf_> anpok: mir::services? scheduler is not bad
<anpok> RAOF: btw, regarding mesa - all issues so far were solved through pulling in further autotools related patches from master
<RAOF> You autotools!
<anpok> RAOF: what is currently in the archive is a non-functional gallium backend
<RAOF> Ah.
<RAOF> Heh.
<anpok> RAOF: now it stumbles getting a good EGLConfig - i.e. surface attribute bit is wrong iirc
<anpok> alf_: sounds good but, but what is not a service? (maybe I misnamed timer service?)
<anpok> -but
<alf_> anpok: fair point
<anpok> RAOF: ah right, this one is really odd.. all config entities it checks have EGL_PBUFFER_BIT = 0x1 and one that is not listed in egl.h 0x10... so it is 0x11 while we want EGL_WINDOW_BIT = 0x4 to be set
<RAOF> Hm. Incorrect shift?
<anpok> I have not yet found the place where those config objects get assembled..
<anpok> oh no it isi 0x8 + 0x1 actually
<anpok> but that one is also not listed in egl.h
<anpok> not as a surface type at least
<anpok> alf_: i would like to introduce an interface like main loop that does not say "i am a single instance" - maybe something like EventLoop or Scheduler .. dunno .. which provides the FD/Timer/ActionQeueu (services :))..
<alf_> anpok: Whether this is going to be useful depends on what needs our consumers have. For example at the moment we have a need for synchronized FD + Signal + ActionQueue (current MainLoop) and a Timer which doesn't need to be sync with them.
<alf_> s/synchronized/serialized/
<anpok> hm input sender needs fd + timer, none of them need to be serialized.. or in the main loop or ..
<alf_> anpok: I guess if two services don't need to be serialized between them, we might as well pass them as separate interfaces?
<anpok> yes
<anpok> oh .. sorry that was what I wanted to express
<anpok> s/an interface/a class/
<RAOF> The way AsioMainLoop provided both mir::MainLoop and mir::Timer? :)
<anpok> yes..
<anpok> so that we can decide within server configuration which thread handles which type of events for which part of the mir functionality
<alf_> anpok: RAOF: Didn't we split them apart to make things simpler? :)
<anpok> yeah lets revert
<alf_> anpok: hmm, if we really need this can we somehow use composition to provide the functionality and keep the eveng logic in separate classes?
<alf_> anpok: instead of going back to the the loop super file?
<anpok> yes.. that should be a driving goal
<anpok> also getting rid of the unpredictable parts of asio
<anpok> I wont be working on that this week or so..
<anpok> Just thought about it again, as I am updateing the MPs again
<RAOF> Man I wish gdb worked.
<alan_g> RAOF: ? It has been working for me for at least a decade
<RAOF> alan_g: Tried it on mir_unit_tests recently? It segfaults while trying to load the debugging symbols.
<alan_g> RAOF: yes, I've been using it to track down weird behaviour in trust-session APIs
<alan_g> alf_: thanks for the clue - that's fixed now and I don't have to worry about a mystery CI failure. [@https://code.launchpad.net/~alan-griffiths/mir/rework-test_client_library_old.cpp/+merge/222018/comments/533359]
<alf_> alan_g: great, glad I could help
<anpok> alan_g: i just realized that you suggested scheduling, while I propose scheduler instead..
<alan_g> anpok: scheduler is likely better.
<anpok> ... ok then I will rebase the input sender on that..
<anpok> hm I should move TimerService too
<anpok> alf_: I am inclined to rename mir::graphics::EventHandlerRegistrar to scheduler::FDHandlerRegistrar
<anpok> because in input::InputSender I only use that part of the main loop interface
<anpok> alan_g: alf_: kdub_: is the order in which parts of the DisplayServer are started and stopped relevant?
<anpok> I see we do have test cases that ensure a specific order..
<alan_g> anpok: yes (but I can't remember details)
<alf_> anpok: yes
<anpok> I think about your complaint about the name TimerService..
<alf_> anpok: TimerServiceManagerer :P
<anpok> hehe
<anpok> that part of the interface is only there to start&stop it.. so maybe we could inverse it.. and make it an observer of the server state, and react by starting and stopping the thread
<anpok> or provide a StartStoppable (suggestions welcome) interface
<anpok> that could be driven by DisplayServer
<anpok> but that means the we strictly follow insertion order on start and backwards on stop..
<anpok> s/the we/that we have to/
<anpok> or on third thought..:
<alf_> anpok: there is also the pause/resume case which has some special needs
<anpok> class AlarmLoop : public AlarmService
<AlbertA> kdub_: for your alpha question yesterday...
<AlbertA> kdub_: the issue with the alpha originally was yes, the alpha channel in nested was not initialized
<AlbertA> kdub_: so then we initialized it to opaque
<AlbertA> kdub_: that doesn't work for the split greeter work as it relies on being able to show through multiple nested sessions
<AlbertA> kdub_: so then I modified it so that a nested transparent display buffer would get its alpha channel written
<AlbertA> kdub_: and the last change was to make it actually write correct alpha
<AlbertA> kdub_: to avoid alpha^2'ish effects
<kdub_> sigh, why did we lose the rich pixel format type
<anpok> kdub_: from the conversations I heard it was just side effect of unification of two types..
<kdub_> heh, i'd say the type was just c-ified :)
<anpok> code is patient
<anpok> or version control systems at least
<anpok> kdub_: maybe a good time to get that mp through :)
<kdub_> yeah, seems like a big chunk to improve given how pervasive the type is though
<kdub_> other fish to fry
<anpok> hm are there affordable displays to test depp color pixel formats
<anpok> i only know that mine sucks even at displaying 8 bit per channel
<anpok> hi racarr_
<racarr_> anpok: hi. What's up?
<racarr_> seems like there was netsplit or something.
<racarr_> did I miss something?!?!
<anpok> nope
<racarr_> haha
<racarr_> I was just converting cursor test stuff to inprocess server test
<racarr_> to find this intermittent failure
<racarr_> and found that but still have the other half of the tests to convert now.
<racarr_> then...I have to do the same thing for this enable usb touchscreen branch lol
<racarr_> I feel good about getting more fake devices in fake event hub though
<racarr_> I was thinking after that branch lands I will add a fake joystick.
<racarr_> fake wacom style tablet, etc.
<racarr_> hmm
<racarr_> I have a weird throw in std::mutex::lock I dont understand
<racarr_> Throws std::system_error when errors occur, including errors from the underlying operating system that would prevent lock from meeting its specifications. The mutex is not locked in the case of any exception being thrown
<racarr_> like what!
<racarr_> oh I understand
<racarr_> lol
<racarr_> good talk
<kdub_> why do we have a Width /and/ a DeltaX
<RAOF> anpok: The Dell UltraSharp line does (reasonably) affordable 10bpp panels; even the crappier ones are full 8bit. :)
#ubuntu-mir 2014-06-11
<kdub_> color me annoyed
 * kdub_ has to go bump the android headers package
 * RAOF resists the urge to write std::zip and std::infinite_seq
<anpok_> hi vila
<anpok_> RAOF: do we actually want to use egl/gles2 in cases which we would have to fall back to swrast?
<vila> anpok_: hey !
<RAOF> anpok_: Yes, ish.
<anpok_> ok, ish
<RAOF> anpok_: We certainly want to let _clients_ render with egl/gles2
<RAOF> You're correct that we don't particularly want EGL on the final composition pass, though.
<RAOF> Except that Unity8 uses it for that :)
<anpok_> yeah, but there is still usc..
<RAOF> Right. usc shouldn't use EGL in the swrast case.
<RAOF> It should instead be using something designed for it, like pixman.
<anpok_> but that cpu based composition pass is not really a new graphics platfrom, but rather a fall back option for all our platforms
<anpok_> hm or we make it a separate platform, but share a lot of code with the mesa platform ..
<anpok_> and if we want to provide the same for android .. come up with something similar
<anpok_> hm but that could be a per-output decision
<RAOF> I don't think it's a per-output decision?
<RAOF> Although you're right; it both is and isn't a new platform.
<RAOF> It shares the âhow do we get this buffer to the physical displayâ part of an existing platform, while adding a shared âhow do I composite these thingsâ bit.
<RAOF> boost::asio is maddeningly documented.
<anpok_> RAOF: hm in case of an usb display
<RAOF> ...you want to render on the gpu, and shuttle buffers to the usb display.
<anpok_> ack
<alan_g> dednick: welcome back. Got time to discuss "trust[ed] [prompt] session" terminology?
<dednick> alan_g: hi. sure
<alan_g> You seem to disagree with the terminology in https://wiki.ubuntu.com/Security/TrustStoreAndSessions - or do I misunderstand?
<alan_g> Which do you think is the right document to base the terminology on?
<alan_g> dednick: ^
<dednick> alan_g: ... well i think the whole "prompt" thing may be a bit specific, which is why I dropped it. I thought that was more directed to the use case of a dialog popping up asking the user if it wants to allow access to a resource (UAC)
<dednick> and tvoss started to use the terminology of "trusted particiapant" a while later.
<alan_g> dednick: OTOH a discussion of "trust sessions" and "trusted sessions" is confusing for everyone. It would make sense as "trusted prompt sessions" and "trusted prompt providers"
<dednick> the participant(s) is the "trust promp provider" in the wiki as far as i understand
<alan_g> BRB
<dednick> alan_g: well if it's helping to make sense of it, I can't really complain.
<alan_g> dednick: the problem is that when the code doesn't match the documentation people don't trust either
<alan_g> And the Wiki and "Application Embedding & Trusted Helpers" documents are what people look at to make sense of the MP
<dednick> alan_g: sure.
<alan_g> Also, you seem to have both the app and the TPP as "trusted session" without distinguishing them. Can that be right?
<alan_g> I've seen "trusted participant" in the code (but not noticed it in the docs) - is it just a TPP or can it be the App too?
<dednick> alan_g: i didn't see any reason for distinguishing the participants of the trust session.
<dednick> both app and tpp are participants of a trust session.
<dednick> "According to the description given before, three participants of a trust prompt session can be identified"
<alan_g> dednick: but they have different roles - the tpp is overlaid on the app
<dednick> alan_g: right, but when we're talking about layering, it's just an order. app first, then tpp.
<alan_g> ack. But I take that as descriptive not introducing it as a term
<alan_g> So there's significance to the order things are processed in for_each_participant_in_trust_session()?
<dednick> in the shell there is.
<alan_g> OK, then we need an acceptance test that spells out that requirement.
<alan_g> But wouldn't it be simpler to just query the App and the TPP? Like we do the trust helper?
<dednick> alan_g: hm. i guess putting that kind of assumption in is not really a great idea, but it's a bit of a necessity when dealing with multiple layers of tpp's. Perhaps we should add another "type" of participant (as we did for trust_helper).
<dednick> when inserting/querying in the container/manager i mean
 * alan_g doesn't grok "multiple layers of tpp's" - are they all part of one TPS, or are they nested TPS's?
<dednick> alan_g: as far as I understood, all part of one TPS. see page 4/5 of the google doc.
<dednick> the gallery, content hub and FB will all have surfaces.
<alan_g> I see it. But don't really follow how to make it work.
<dednick> fyi, at the moment, i believe the "select dest" is done by the gallery, so there aren't any surfaces on the content hub.
<alan_g> I can see race conditions adding the different TPPs (they need not be added in the order the TPH adds them if they've not connected to Mir.)
<alan_g> Although that probably doesn't matter - I imagine each would be added in response to a user action and that will serialise them.
<dednick> 1) gallery initiates content hub though dbus/whatever
<dednick> 2) content hub creates trust session with gallery app id.
<dednick> 3) content hub calls new fd for trust session (2 fds)
<dednick> 4) content hub creates session for dest picker (with fd from 3)
<dednick> 5)   user see's dest picker overlayed on top of gallery (due to trust session)
<dednick> 6)   user picks face book as destination
<dednick> 7) content hub intiates facebook app with second fd from 3
<dednick> 8) FB starts and is overlayed on top of content hub session.
<dednick> alan_g: yeah, race will exist if you add 2 participants for apps which we start. but the use cases for app starts are in response to user action.
<dednick> alan_g: i'm not really sure how this fits into the trust store model though...
<alan_g> LOL
<dednick> theres a bit of a disconnect between the security side of this, and the user side of it.
<alan_g> Yes. I'm starting to think we have "prompt client", "prompt session", "prompt helper" and "prompt provider" - and trust is implicit. ;)
<dednick> indeed.
<dednick> i've been implementing application embedding using security terminology.
<alan_g> The terminology used is a big hurdle to understanding what the code supports.
<dednick> right. but this was supposed to be an initial phase of something that is "trust" related.
<alan_g> But really, the "trust" part isn't implemented in Mir. And "trust"/"trusted" in the names is confusing every reviewer.
<dednick> yeah. i have no idea how the security bit is supposed to hook into this. perhaps we should drop the "trust" for "prompt". Trust(ed)Session/Helper/Participant -> PromptSession/Helper/Participant
<alan_g> I assume it "hooks in" by controlling which connections can create a prompt session.
<dednick> alan_g: i meant where it's going to live if not mir.
<dednick> perhaps the shell.
<alan_g> dednick: I assume the same place that decides who can connect, configure_display, or screencast
<dednick> alan_g: right. but at that point, it does become "trusted"
<alan_g> Yes, the shell provides a custom SessionAuthorizer to control session permissions. (Or Mir defaults to being trusting.)
<dednick> but since we dont call them "trusted_screencast"...
<alan_g> ...we should call it "prompt_session_is_allowed()"
<dednick> but now we don't match the documentation anymore :)
<dednick> so lets change the documentation!
<alan_g> Well, maybe.
<alan_g> But it would be easier to explain
<alan_g>  "application" => "application"
<alan_g>  "trusted prompt session" => "prompt session"
<alan_g>  "trusted helper" => "prompt helper"
<alan_g>  "trusted prompt provider" => "prompt provider"
<alan_g> than what we have now
<dednick> +1
<alan_g> alf_: anpok_  Opinions? ^^
<alf_> alan_g: dednick: what about "interactive session"? Does it make sense to differentiate between the two in mir?
<alf_> s/interactive session/interaction session/
<alan_g> which two?
<alf_> alan_g: dednick: in the docs there is also an "trusted interaction session"
<alf_> alan_g: dednick: so "trusted interaction session" vs "trusted prompt session"
 * alan_g thinks there are two many docs to remember 
<dednick> alan_g: hm: i would have said embedded before "interaction"
<anpok_> is prompting the user for decisions the only relavant use case?
<dednick> alf_: ^
<dednick> anpok_: at the moment, yes; can't say about the furture though.
<alan_g> I like "embedding session" - but worry where to find it in the docs (without rewriting them all)
<alan_g> It is always good to stick with the use cases we know about.
<anpok_> funny - then the overall purpose - the reason why focus management/surface order needs to be aware of it - suddenly becomes obvious
<anpok_> so I would really prefer that naming, if it is not a simplification or only a small aspect of the problems to solve.
<alan_g> I've got to go make lunch (it is my turn) please reach a consensus.
<alan_g> I'll catch up when I get back
<dednick> i think we should check with tvoss before making the decision though. Since he has the grander plan in mind.
<alan_g|lunch> If Saviq agrees then we can convince tvoss
<alf_> dednick: I wasn't proposing "interaction session". I was referring to "trusted interaction session" use case presented in the docs, and whether it would be make sense to have a "prompt session" in mir instead of something that would cover all use cases.
<alf_> dednick: assuming that what is expected from mir doesn't change for each use case
<alf_> anpok_: alan_g|lunch: ^^
<alf_> dednick: (repeating since you probably missed this) I wasn't proposing "interaction session". I was referring to "trusted interaction session" use case presented in the docs, and whether it would be make sense to have a "prompt session" in mir instead of something that would cover all use cases.
<alf_> dednick: assuming that what is expected from mir doesn't change for each use case
<anpok_> alf_: hm looking at the docs it is hard to see whether a (trust*) session for prompts behaves different than a (trust*) session for 'interaction'
<anpok_> i think they might differ in the used surface properties/window types?
<alf_> anpok_: yeah that was my point, they seem similar enough not to warrant a special distinction (sorry I think I expressed this the other way around than I meant)
<alf_> anpok_: i.e., we shouldn't have a "prompt session" in mir, but rather something more general
<anpok_> so introducing prompt as a term for both is maybe not the right solution
<anpok_> yes
<anpok_> but I am all for not using trust - as it seems to be a distraction of what this functionality is about..
<anpok_> which is providing and dealing with some sort of grouped session based on
<anpok_> existing sessions..
<alf_> anpok_: it is an unfortunate and confusing coincidence that we are using the term 'session' in Mir to represent mir clients.
<anpok_> why is it unfortunate? I think we should try to treat (trust*) session like a session.
<anpok_> ah ok .. that would not reflect the nesting
<alan_g> Anyone that thinks "it is a  an unfortunate and confusing coincidence that we are using the term 'session' in Mir to represent mir clients" should join the "scene::Session => scene::Application" discussion.
<alan_g> I'm afraid that "interaction session" might be premature generalization. If when we come to "interaction session" use cases we find that we can implement a "prompt session" using it then we can provide a new API and deprecate the old one. If we use "interaction session" now and when we come to the non-prompt use cases we we cannot generalise then we have "painted ourselves into a corner".
<camako> alan_g, it seems we are finally getting somewhere with the terminology
<alan_g> camako: I hope so. I don't think it is quite settled yet.
<DonkeyHotei> can the reliance on libegl be eliminated?
<camako> alan_g, but I don't remember reading abt "interaction session"... Could you provide a link to the doc?
<alan_g> camako: https://wiki.ubuntu.com/Security/TrustStoreAndSessions
<alan_g> "Trusted Interaction Session"
<camako> Oo this doc..
<alan_g> Too many documents not enough acceptance tests
<camako> alan_g, ok now I remember reading about it...
<camako> alan_g, I don't know what this phrase means, "Potentially system chrome"?
<alan_g> Dammit! "Reading symbols from bin/mir_unit_tests...Segmentation fault (core dumped)"
<alan_g> "chrome" is shiny stuff
<alan_g> My feeling is we should go with the use case we understand (prompt session)
<camako> At least we all agree to drop "trust(ed)"..
<alan_g> alf_: ^^
<camako> "prompt" is somewhat limiting though...
<alan_g> dednick: anpok ^^
<camako> could get obsolete/nonsensical as soon as another use-case emerges
<alf_> DonkeyHotei: @libegl, no, at least not at the moment... we depend on EGL throughout Mir
<alf_> DonkeyHotei: what do you want to do?
<camako> ... which interaction session is another use-case but a bit nebulous
<DonkeyHotei> alf_: bug 1304959
<ubot5> bug 1304959 in mir (Ubuntu) "No support for older intel hardware, or no clear message about not being supported." [Medium,Confirmed] https://launchpad.net/bugs/1304959
<camako> "Prompt" also sort of means "on top of everything"
<alf_> DonkeyHotei: We are working on using software GL rendering through Mesa/llvmpipe if no HW accel is available
<alf_> anpok: ^^
<DonkeyHotei> alf_: how soon?
<dednick> "embedding/ed session" ?
 * anpok waves 
<alan_g> I'm afraid that "embedding/ed session" might be premature generalization. If when we come to "embedding/ed session" use cases we find that we can implement a "prompt session" using it then we can provide a new API and deprecate the old one. If we use "embedding/ed session" now and when we come to the non-prompt use cases we we cannot generalise then we have "painted ourselves into a corner".
<alan_g> But if we feel we know enough for confidence about the future I'll wait and see.
<camako> yeah embedded/ing also has the connotation that things are inside other stuff.. In a general sense, it may not always be the case
<anpok> alan_g: camako: dednick: I can vote for using prompt now and having a rename while we add new stuff to it... the only thing I am still missing is that the functionality is about some sort of <session> created by multiple processes.. and prompt does not say that
<alan_g> True - it implies the implementation, not the requirement
<camako> How about "cooperative session"?
<camako> I think it 'd cover both the interaction and prompt
<alan_g> That's so general it says very little
<dednick> hm. bit too general
<anpok> the other thing ..are we going to see further changes that will make sessions and sessions look the same from the server side api?
<dednick> a session looks pretty much like a session to me :)_
<dednick> you mean a trust session and a session?
<anpok> i erased the word trust already :)
<alan_g> A [trusted] prompt session
<dednick> possibly could be deriving from a common focusable object in the future. but it hasn't really been discussed.
 * alan_g has tried to persuade tvoss that "session" was a bad name for it. And persuade mir developers that "session" is a bad name...
<anpok> DonkeyHotei: there is no mesa dri driver for n450?
<DonkeyHotei> should be
<camako> "trust session" and "interaction session" have little in common, so whatever term we choose, it will have to be pretty general - and won't explain either...
<alan_g> I vote for "prompt session" now
<dednick> "prompt session" for me too . mainly because I want the pain to end. :)
<alan_g> dednick: who said the pain would end?
<alan_g> ;^)
<dednick> well. actually it will just begin since, that's when the renaming game starts.
<alan_g> Renaming is easy. I do it all the time.
<dednick> i hadn't noticed! :)
<alan_g> find -name \*.cpp -or \*.h | xargs sed --in-place ...
<camako> prompt session sounds good, then
<dednick> there's a lot of trust around. trust session, trusted session, [trusted] participants, trust session manager, trust helper, trust listener, trust session container. trust session events, blah blah
<alan_g> I don't mind doing the renames - if we are agreed on the naming scheme
<kgunn> is tvoss hiding ? :P
<kgunn> wonder if tvoss cares about the naming...
<alan_g> kgunn: we spoke to tvoss yesterday. And he's been absent from here ever since
<kgunn> camako: alan_g dednick ...so basically, we're scrubbing trust, replacing with prompt...in all instances of trust<something>
<dednick> alan_g: it's ok. it'll ease me back into working after a bit too long in the sun :)
<camako> kgunn, my understanding is that
<camako> we are using this name in our code
<dednick> kgunn: for mir yes
<camako> not changing tvoss' doc
<alan_g> kgunn: not quite that simple. But that's a big chunk of it
<kgunn> ack...i figure some paradigms won't match quite that easy
<kgunn> gotta get a coffee, i'll be on standup in minutes
<dednick> alan_g: are we going for "prompt session participants", or "application + prompt provider"?
<alan_g> dednick: I'd suggest application()  helper() and for_each_provider()
<alan_g> but that's a slightly independent change
<dednick> alan_g: sure.
<anpok> DonkeyHotei: ok - I think I have an even older netbook than that, which uses a similar gpu
<anpok> but havent tried mir on it yet.
<DonkeyHotei> anpok: i believe mine is n450 with i945 graphics
<anpok> intel has some intersting naming schemes ther gma950 i945 .. 945G .. but yes.. i will try this evening
<DonkeyHotei> i already tried, black screen
<DonkeyHotei> it tries to use libegl which fails
<anpok> DonkeyHotei: so egl/glesv2 usage would always fail on 945?
<AlbertA> heh, a fix committed before the an external bug: https://bugs.launchpad.net/mir/+bug/1328952 yippeee
<ubot5> Ubuntu bug 1328952 in Mir "Compositing with invisible surfaces" [High,Fix committed]
<DonkeyHotei> anpok: bug 1304959
<ubot5> bug 1304959 in mir (Ubuntu) "No support for older intel hardware, or no clear message about not being supported." [Medium,Confirmed] https://launchpad.net/bugs/1304959
<kdub_> rsalveti, any plans to get the android 4.3 headers from libhardware into the android-headers package? hit a snag with the api between 4.2 and 4.4 when trying to enable hwc alpha blending
<kdub_> specifically, I need to use the hwc_layer_1_t::planeAlpha field introduced in android-4.3
<kdub_> https://android.googlesource.com/platform/hardware/libhardware/+/android-4.3.1_r1/include/hardware/hwcomposer.h
<rsalveti> kdub_: goal is to update it to be based on 4.4, just never spent cycles on it as we didn't have any request for the update til now :-)
<kdub_> rsalveti, great, anything I can do to help?
<rsalveti> kdub_: mind creating a bug and assigning that to me
<rsalveti> ?
<rsalveti> can take care of that later today
<kdub_> rsalveti, will do
<kdub_> thanks
<ogra_> kgunn, will reverting split greeter also revert the boot animation ability ? (that came in alongside)
<kdub_> rsalveti, here's the bug: https://bugs.launchpad.net/ubuntu/+source/libhybris/+bug/1328971, can't assign/set priority on it though
<ubot5> Ubuntu bug 1328971 in libhybris (Ubuntu) "android 4.4 headers needed for hwc_layer_1_t::planeAlpha field" [Undecided,New]
<kgunn> ogra_: initially, we'd have to ask mterry about adding that animation into inproc greeter
<kgunn> suppose it might actually be easier
<ogra_> kgunn, i think u-s-c ships it atm, we could just not rip it out
<mterry> kgunn, ogra_, no doesn't affect our ability there
<kgunn> (in terms of transitions)
<ogra_> mterry, great !
<mterry> ogra_, kgunn: we don't need to rip out any part of it, and animation doesn't care if it stops at split greeter or user session
<ogra_> yeah
<ogra_> thats what i thought
<ogra_> would be a shame to do RTM with a black screen through the whole boot
<kdub_> mterry, is boot animation that a usc client? or does it override the compositor for a bit
<mterry> kdub_, it's written as a USC client
<kdub_> cool, just curious
<mterry> That the USC knows about especially
<rsalveti> kdub_: thanks
<kdub_> AlbertA, we don't have a way to discern whether abgr_8888 has premultiplied alpha or not, do we?
<racarr_> Another new GCC CI failure https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-amd64-ci/385/console
<racarr_> syncfence.cpp:68
<anpok> kdub_: but if it is a buffer from a client
<anpok> we are safe to assume that
<kdub_> we probably assume that, but aren't safe to do so
<anpok> well safer than assuming the opposite
<AlbertA> kdub_: no
<AlbertA> kdub_: you need to?
<kdub_> AlbertA, eh, probably will go on the 'todo' pile
<AlbertA> kdub_: in any case, we now assume pre-multiplied instead of straight alpha
<AlbertA> kdub_: which makes more sense
<kdub_> right
#ubuntu-mir 2014-06-12
<RAOF> Huh. Do we really not have a server report that includes the message IDs?
<alf_> alan_g: anpok_: Do you prefer manually merging branches until the clang issue is fixed, or do you want to force g++-4.8? I prefer (1) if we can get a reasonable ETA on the fix (a couple of days max).
<alan_g> alf_: I (mildly) prefer disabling the clang build
<alf_> alan_g: even better, too bad we can't just do it ourselves :/
<alf_> alan_g: anpok_: From what I understand from ubuntu-ci-eng discussions, the gcc-4.9 update has been reverted
<alan_g> alf_: shall I kick off an affected build to see what happens?
 * alan_g has a link handy
<alf_> alan_g: sure
<alan_g> done - should know in 20min
<alf_> alan_g: anpok_: to be exact, the update making gcc-4.9 the default has been reverted, gcc-4.9 packages are still there
<alan_g> (Unless it fails faster)
<alf_> alan_g: which MP did you trigger?
<alan_g> alf_: Just http://s-jenkins.ubuntu-ci:8080/job/mir-clang-utopic-amd64-build/531/console
<alf_> alan_g: the CI environment is still broken...
<alan_g> /o\
 * alan_g starts to think fondly of a former "life" where he "owned" the CI environment
<alan_g> alf_: I (mildly) prefer disabling the clang build - I wonder if fginther is about yet
<alf_> fginther: ^^
<anpok_> hm isnt there a way to override the clangs header picking behavior
<anpok_> -the
<anpok_> maybe we can force clang to pick the 4.8 folder
<alan_g> anpok_: maybe - but how much time should go on that?
<anpok_>  we would have to add -I /usr/include/c++/4.8 --gcc-toolchain=/usr/lib/gcc/`uname -m`/4.8 to the clang command line - provided that 4.8 is still available on the ci builder
<anpok_> +-linux-gnu
<anpok_> hm the clang packages from llvm.org dont have that issue anymore
<alf_> anpok_: This has been fixed in the debian packages, but they haven't been pulled in the ubuntu archive yet
<fginther> alan_g|lunch, alf_, morning
<alf_> fginther: Hi! Due to recent clang breakage, all our CI jobs are failing. I think that things have been fixed in the archive (by making g++-4.8 the default again, instead of 4.9), but the CI environment is still broken.
<alf_> fginther: We would like to either fix/update the CI environment (preferred), or if this is not feasible for the near future then temporarily disable the clang jobs for mir-ci and autolanding
<fginther> alf_, I'll have to see what's required to fix it. After a skim of the latest logs, I have no idea what's broken to know what to fix.
<alf_> fginther: How is the build environment for CI updated? We need to ensure we have the latest package versions from archive (in particular for the package gcc-defaults)
<alf_> fginther: (source package 'gcc-defaults')
<fginther> alf_, they are pbuilder chroots updated with 'pbuilder update'
<alf_> fginther: ok, I think that just updating the chroots should be enough to fix this
<fginther> alf_, ack, I'll kick of an update now
<alf_> fginther: thanks
<alf_> fginther: please let us know when it is done, so we can trigger a couple of builds to see if the clang ci jobs are fixed
<fginther> alf_, the update is complete and there appears to be a build in progress
<alan_g> fginther: which failed: CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:54 (message):
<alan_g>   The C++ compiler "/usr/bin/clang++" is not able to compile a simple test
<alf_> fginther: alan_g: I have triggered a new one, now that we are sure that the update is done
<alan_g> alf_: fginther that failed too
<fginther> :-(
<fginther> alan_g, alf_, I manually check to see what gcc packages are in that chroot, maybe that got dropped somehow when the archive changed the default
<fginther> alan_g, alf_, the chroot has both gcc-4.8 and gcc-4.9, the gcc package version is 4:4.9.0-3ubuntu5. gcc -v reports "gcc version 4.8.3 (Ubuntu 4.8.3-3ubuntu1)"
<kgunn> seb128: hey there, so AlbertA has some changes coming wrt screen blanking...which will also likely be a proxy for screen brightness as well...would you be the person to
<kgunn> talk to about having settings properly pick up
<kgunn> any brightness settings ?
<seb128> kgunn, hey, setting got transferred to bfiller's team, jgdx would probably be the right person to talk to
<kgunn> seb128: thanks!
<seb128> kgunn, but iirc we only use the powerd dbus interface there, so there might be nothing to change on the settings side
<seb128> kgunn, yw
<kgunn> AlbertA: jgdx is in #ubuntu-touch
<AlbertA> thanks
<seb128> #ubuntu-touch is the right channel to use anyway
<seb128> Laney, I and some other probably still know that code better, the project just got moved
<seb128> so we can also reply/comment on the channel
<alf_> fginther: alan_g: trying a chroot locally to try to figure out wth is going on
<kdub_> AlbertA, are those screen-blanking changes mir-level or powerd?
<AlbertA> kdub_: USC and powerd
<AlbertA> USC will now handle inactivity tracking, which makes it have to handle brightness (dim, bright, off)
<kdub_> AlbertA, cool, makes sense
<AlbertA> this is to avoid having powerd also instantiate an android input parser thread
<AlbertA> and because USC handles display power state changes it just makes more sense for it to be there
<alf_> fginther: alan_g: Can't reproduce problem locally with utopic chroot.
<alf_> fginther: alan_g: Is it possible to recreate the chroot from scratch instead of updating it?
<fginther> alf_, can you do a "dpkg --list|grep gcc"?
<fginther> alf_, this is what I have: http://paste.ubuntu.com/7634385/
<fginther> alf_, it should be possible to recreate
<alf_> fginther: http://paste.ubuntu.com/7634390/ (see also stdc++ libs)
<alf_> fginther: can you also paste your stdc++ libs?
<fginther> alf_, http://paste.ubuntu.com/7634395/
<alf_> fginther: kinnara has a fuller gcc 4.9 installation than my chroot. Perhaps the updates don't work so well if you already have 4.9...
<alf_> fginther: I would propose either a clean chroot, or perhaps trying to remove the 4.9 packages manually
<alf_> fginther: (clean chroot seems safer)
<fginther> alf_, I'll work on recreating the chroot toady
<alf_> fginther: thanks
 * kdub_ renames surfaceflinger spaghettiflinger
<DonkeyHotei> [Wed 2014-06-11 07:35:19 AM PDT] <alf_> DonkeyHotei: We are working on using software GL rendering through Mesa/llvmpipe if no HW accel is available
<DonkeyHotei> [Wed 2014-06-11 07:36:47 AM PDT] <DonkeyHotei> alf_: how soon?
<alf_> DonkeyHotei: 'anpok_' is working on it, so he is better suited to answer the question
<alf_> anpok_: ^^
 * kdub_ is interested in how that will look in the code too
<kdub_> and also if android can make use of it
<anpok_> DonkeyHotei: next task
<anpok_> i think we cannot do much about unity8 using glesv2
<anpok_> DonkeyHotei: resurrected old hardware today.. will see why egl fails to come up there
<kdub_> anpok_, with that llvm stuff, are you intending it to be a different platform? a feature of the mesa platform?
<AlbertA> gaah...deadlock when using surface observer...
<AlbertA> since my observer tries to change focus
<anpok_> kdub_: llvm on dri would be mesa platform..
<anpok_> i mean we could/should also have gbm + pixman
<anpok_> that would be a new platform
<anpok_> AlbertA: it happened sooner than I thought
<AlbertA> anpok_: yeah this is for USC where it likes to raise the session only after receiving the first frame
<AlbertA> anpok_: also I would like do deregister the observer at that time too...but not possible either :)
 * AlbertA notes its time to remove unlock the guard before executing observer callbacks
 * AlbertA time to unlock the guard rather
<fginther> alf_, looks like the rebuild chroot is working: http://s-jenkins.ubuntu-ci:8080/job/mir-clang-utopic-amd64-build/541/console
<racarr_> Spinning my head in circles on cursor in renderable list lol
<racarr_> There are at least 3 main approaches I could think of
<racarr_> 1. Cursor specially built in to surface stack. Requires some renderable generalization and renaming surface stack/perhaps changing some API
<racarr_> kind of unsatisfying but maybe a good first step
<racarr_> 2. Expand scene type functionality of surface stack slightly, i.e. add_renderable instead of add_surface. so surface stack is renamed to um
<racarr_> Scene or Renderables or something
<racarr_> and the API has to be futzed around all over
<racarr_> 3. Use view-adapter style pattern
<racarr_> where something inbetween the surface stack and the compositor
<racarr_> presents a modified renderable list.
<racarr_> adding the cursor on top
<racarr_> I tried thinking through tests too...but I mean the main sort of acceptance tests for what I am trying to do is that there is some sort of small buffer at the top of the renderlist that moves with the pointer.
<racarr_> so its satisfied by all 3 approaches fine.
<racarr_> 1 is...
<racarr_> at best a first step, but might be the best choice because it accomplishes the goal, improves things (grows renderable interface)
<racarr_> but then, you need different casing in surface stack for touch spot visualization if you take that approach....and that obviously seems pretty bad
<racarr_> so probably no 1.
<racarr_> 2. Seems good, but im a little literally unclear on exactly how the interfaces should shape up because it has to touch all the factories a little, etc...and there are no clear tests to guide it...but maybe I can think through it more
<racarr_> 3. Has a certain charm lol...in that it solves the
<racarr_> cursor/touch visualization/overlay problem perfectly and also grows
<racarr_> the renderable interface
<racarr_> but also clearly...
<racarr_> taking an approach of continuing to append view adapters
<racarr_> between surface stack and compositor
<kdub_> my 2 cents are that the cursor should come along with the generate_renderable_list() function
<racarr_> wouldn't work/would become very messy (interdependent)
<racarr_> kdub_: :D Yes I agree lol...im just not sure how.
<kdub_> and, on the basic level, it is a renderable of sorts, that is, the concrete cursor class would inherit from renderable
<racarr_> Yes
<kdub_> and the display buffers sort out the hardware cursor abilities
<anpok> i would prefer 2.
<racarr_> so my main divide is is this cursor renderable. 1. Something built in to the scene. 2. Something added to the scene by some sort of controller or 3. Something appended to the scene by some sort of compositor
<racarr_> anpok: Yeah...my intuition is that is also best...im just not exactly sure what the new surface stack should look like
<kdub_> I don't mind the concrete SurfaceStack impl gaining specific cursor knowledge
<racarr_>  / how exactly renderable/surface/input target interact
<racarr_> kdub_: I was thinking too its not so awful for cursor right, because its just one thing on the top
<kdub_> what's not so awful?
<racarr_> but then, touch spot visualization is kind of seperate in that there are any number and they
<racarr_> vanish or dissapear
<racarr_> kdub_: SurfaceStack impl gaining cursor knowledge
<racarr_> but if SurfaceStack impl has to know about cursors, and touch spots...
<racarr_> it kind of seems
<racarr_> like too much
<kdub_> eh, you can have a cursor object as a member that takes care of the hairy details
<racarr_> hmm maybe.
<kdub_> as for the touchspot visualization, you just insert the cursor renderable multiple times with different coordinates for each
<kdub_> and like, that way, you have the cursor image be part of the stack
<kdub_> and future fancy stuff like MSwindows trailing cursor effect be a matter of the compositor's view state
<racarr_> haha fancy stuff
<kdub_> heh, well more realistically, like say the cursor is a waiting cursor and has to rotate
<racarr_> we already support trailing cursor in glamor
<racarr_> haha yes. sure. there are definitely things
<kdub_> and iirc, the current client-backed renderable inherits from a touch-targetable interface
<kdub_> and the cursor-backed renderable would not
<kdub_> so, solves that other problem
<racarr_> the thing is if all renderables dont
<racarr_> inherit from input target
<racarr_> but surface stack stores
<racarr_> renderables
<racarr_> then you at least need a cast to implement InputTargets::for_each
<racarr_> so it doesnt seem quite right
<kdub_> if we have internally a list of cursors and a list of clients
<kdub_> the for_each can iterate over the clients, which inherit from the right interface for that
<racarr_> oh yes, if we keep cursors really entirely seperate
<anpok> as soon as you add more than just images that refer to surfaces to your scene you need some sort of runtime type information
<kdub_> and the stack grows in smartness to interleave the cursors with the clients
<kdub_> with the 1st step being 'cursors always on top' (pretty simple)
<kdub_> anpok, no, why
<kdub_> or maybe
<kdub_> who needs that information
<anpok> when you traferse the scene you might ignore certain elements - i.e. for touch dispatch you would ignore the cursor objects
<racarr_> anpok: Well thats the thing in approach 1 though right
<racarr_> cursor is just totally seperate
<kdub_> sure, thats why you have cursors in one list and clients in the other internally
<kdub_> and generate_renderables_list can weave the two together, as both types implement mg::Renderable
<racarr_> but, I mean it seems like eventually...
<racarr_> we want to support inserting other kinds of renderables in
<racarr_> the scene right?
<anpok> *traverse
<racarr_> I mean...I would be happy for example if decorations were in the scene
<anpok> kdub_: in that case ok ..
<racarr_> and all sorts of various effects from various shells
<racarr_> could be in the scene
<racarr_> shadows could be in the scene perhaps
<racarr_> etc
<anpok> camera configuration
<racarr_> camera configuration
<racarr_> yes
<kdub_> racarr_, decorations, sure
<racarr_> so I wonder if taking this approach is actively making things
<racarr_> worse
<racarr_> so I should just bite the bullet and make surface stack
<kdub_> animations are compositor-driven more than scene driven though
<racarr_> RenderablesTree (new name)
<racarr_> (err by new name, I mean thats not a final name lol)
<racarr_> and work in terms of add/remove renderable, etc
<kdub_> it was originally just std::list<mg::Renderables>
<racarr_> kdub_: Yes lots of animations maybe... I mean effects like
<kdub_> sorry, std::list<std::shared_ptr<mg::Renderables>>
<racarr_> say unity glass layers (like unity 7 alt tab switcher)
<kdub_> RenderableList is just a typedef
<kdub_> but sure, the compositor just wants something  that can be traversed for rendering
<kdub_> tree or list, /me doesn't mind
<racarr_> mm
<racarr_> in this case, I'm worried about
<racarr_> the other side of the API
<anpok> the actual renderer that draws to one output only needs that list
<racarr_> i.e. for adding/removing to it/arranging it, etc.
<racarr_> i.e. if cursor controller is going to be adding and arranging cursor renderables in RenderTree, it probably needs something
<anpok> and information about how to set up the projection matrix.. resolution..
<racarr_> better than depth id ;)
<racarr_> among other things
<kdub_> no no
<kdub_> projection matrix is a view
<anpok> it should not care about the rest of the scene..
<kdub_> like, the compositor can have its own state
<anpok> ah ok maybe that part could also benefit from being able to interpret a tree
<anpok> maybe it depends on what a renderable could be
<anpok> kdub_: I dont think so..
<kdub_> the tree is just a z-ordering
<kdub_> and, i'm talking in the short-medium term here
<kdub_> the compositor has to feed back to the stack for certain bits of information, like alf_'s visibility stuff
<racarr_> well. I think for cursor I am going to try and get something going with some cursor knowledge built in to surface stack, because this allows me to grow the renderable interface some without worrying too much about other stuff
<kdub_> cool
<kdub_> although I just got renderable cleaned up! :)
<racarr_> and then after, make an attempt to pull the specifics out of the stack to do touch spots
<racarr_> but give up if ends up being too confusing, because cursor specialization in the stack impl isnt so bad
<racarr_> kdub_: Haha.
<racarr_> THE WHEEL IS TURNING
<anpok> kdub_: that was just the preparation work to make it dirty again
<kdub_> haha, hope not!
<racarr_> haha
<anpok> hm intersting intel needs a reboot with the hdmi cable pluggin to be able to send audio through hdmi
<racarr_> Luckily we dont yet have a "dirty renderable"
<racarr_> concept
<anpok> *plugged in
<anpok> racarr_: hehe
<racarr_> and that sounds...non surprising lol
<racarr_> intel audio...connection stuff is totally messedup, i.e. switching between line in and mic when line in is plugged in, switching dual-function jacks between input/output
<anpok> sounds like intel wifi
<racarr_> lol
<anpok> only works when power management is turned off
<racarr_> intel graphics though does a great job satisfying my need of drawing 20 quads in 16ms
<anpok> amazing what open source drivers can do to a buy decision..
<anpok> ..with all that quirks I would have never bought that laptop
<racarr_> my nexus 4 battery life
<racarr_> seems to have dropped to roughly...um
<racarr_> like if I leave it unplugged for an hour it goes dead
<racarr_> kind of situation
<racarr_> maybe thats exaggerating
<racarr_> I can't really tell
<racarr_> but its gotten really bad
<anpok> i switched from webos to ubuntu phone last week
<anpok> for that reason actually .. battery becoming really awkward
<racarr_> hahahaha
<racarr_> anpok: Congratulations on being the first person
<racarr_> to use that sentence
<anpok> now I wonder what it would take (apart from ordering a replacement batery) to get ubuntu phone running on the pre3
<anpok> i miss the keyboard
<racarr_> kind of a small screen for unity
<anpok> yeah means less overdraw
<racarr_> :)
<racarr_> I suspect we may all have shiny new phones before too long anyway
<kgunn> AlbertA: didn't you or someone fix the "last frame doesn't render" bug?
<AlbertA> kgunn: yes
<kgunn> thot so...
<AlbertA> kgunn: reappeared?
<kgunn> nope...just need to go kill some fud
<kgunn> did it make the 020 cut off ?
<AlbertA> let me see
<kgunn> racarr_: o/ feels like forever since i said hi
<AlbertA> kgunn: yes it did
<kgunn> so hi!
<kgunn> AlbertA: thanks
<racarr_> kgunn: Hi!
<racarr_> How was your trip? I remember you went to colorado but cant remember exactly why
<kgunn> racarr_: yeah thanks for asking
<kgunn> racarr_: it was nice
<kgunn> racarr_: pot tourism
<racarr_> hahaha of course.
<kgunn> racarr_: j/k :) my bro in law lives ther
<camako> nice cover :-)
<racarr_> Right mine too ;)
<kgunn> did some hiking...which was needed for all the food/beer calories consumed
<racarr_> aha sounds pleasant
<racarr_> ive been craving some nature lately
<racarr_> have to find a way to escape the city this weekend
<kgunn> racarr_: did a 6mi/3000 ft elevation incr hike...and it rained on us the entire 2nd half down the mountain...that was fun
<kgunn> little chilly
<racarr_> haha...cest la vie.
<kgunn> ....aaaaandddd reboot
<racarr_> https://jenkins.qa.ubuntu.com/job/mir-clang-utopic-amd64-build/540/console
<racarr_> :/
<racarr_>   The C++ compiler "/usr/bin/clang++" is not able to compile a simple test  The C++ compiler "/usr/bin/clang++" is not able to compile a simple test
<racarr_> thats a shame
<kgunn> racarr_: hey, have you played with performanceOverlay ? wondering if there's a way to dump to a file
<kgunn> http://developer.ubuntu.com/api/qml/sdk-14.10/Ubuntu.PerformanceMetrics.PerformanceOverlay/
<kgunn> for the curious, only works on apps (not shell) set the PERFORMANCE_OVERLAY variable, reboot, tap 4 times on the app screen
<racarr_> kgunn: I dunno sorry.
<racarr_> quick scan of the code makes it look unlikely (dumping to file)
<kgunn> racarr_: yeah no biggie
#ubuntu-mir 2014-06-13
<racarr_> https://jenkins.qa.ubuntu.com/job/mir-android-utopic-i386-build/536/console
<racarr_> omg...
<racarr_> :(
<racarr_> is CI completely destroyed or am I just having the worst luck ever on this branch
<RAOF> racarr_: Heh.
<RAOF> Erm, what?
<RAOF> We seem to call MirSurface::create_wait_handle.result_received(), but we never call MirSurface::create_wait_handle.expect_result()?
<RAOF> How does that not make mir_wait_for() a no-op?
<RAOF> Ah, ok. So the answer is: it *is* a no-op.
<alan_g> alf_: today it's "mir-android-utopic-i386" - https://jenkins.qa.ubuntu.com/job/mir-android-utopic-i386-build/
 * alf_ sighs
<alf_> alan_g: I will ask in the CI channel, perhaps the can recreate the chroot tarball
<alan_g> alf_: fginther is already on it
<alf_> alan_g: great then
<alf_> alan_g: anpok: Thoughts on the name for "Scene::inform_about_rendering_for(CompositorID, RenderableList const& rendered, RenderableList const& not_rendered);"
<alan_g> alf_: I don't know what it means => it is bad
<alf_> alan_g: I wan't to let the scene know which renderables a compositor rendered and which it didn't
<anpok> then use rendered instead
<anpok> renderered_renderables :)
<anpok> or rendered_elements -typos
<alan_g> alf_: what's the sequence these days?...
<alan_g> 1, The scene gives the compositor a list?
<alan_g> 1.1. The compositor gives the scene two lists?
<alan_g> Can't the compositor just tag the list items "rendered"?
<alan_g> Or partition the list?
<alan_g> Does the scene even need to know what *wasn't* rendered?
<anpok> it only needs to know what wasnt rendered at all in any compositor
<anpok> so one list could be enough
<anpok> so the scene now gets an explicit - i am done with rendering, and that is what I did call from each compositor (hopefully)
<alan_g> Isn't it simpler for each element in the scene to know when it was last rendered
<alf_> alan_g: anpok: It needs to know somehow (compositor tells it, or it tries to figure out by itself Rendered = All - NotRendered) what was rendered too, since we need to send both occlusion and exposure events.
<anpok> oh so also the difference between this and last round of drawing
<anpok> hm what if we have compositors that drive outputs that are side by side.. and that compositor has half the framerate of the other
<anpok> *two
<anpok> ahh nm, you can figure that out through the compositor id
<alf_> anpok: the idea is that the scene knows about all the compositor ids. If all compositors say that we haven't rendered this surface then it is marked as occluded
<anpok> but you have to wait untill you receive results from all
<anpok> and take the most recent maybe..
<anpok> then you also need to know that a compositor is turned off
<alf_> anpok: but in any case, I am not concerned with the multi-monitor case right now, I am focusing on the single screen case
<anpok> .. ok I just thought the interface is too complex..
<anpok> but it needs to be that way .. or the scene does more
<alf_> anpok: you mean passing both rendered and not_rendered?
<alan_g> We don't want to change everything as soon as there's multiple renderers
<alf_> alan_g: we won't
<anpok> alf_: well there is a reason for each parameter..
<alan_g> then we have to understand cases like multiple renders with overlapping contents
<anpok> alf_: it feels like a start rendering / done rendering call required by the compositors
<anpok> is rendereable_list_for only called once per frame per compositor
<alan_g> AFAICS "occlusion" == we have to drop a frame because none of the renderers have drawn recently
<anpok> *calls
<alf_> alan_g: We (at least I) think we understand them. I am focusing on the simple case in the implementation side not the API side.
<alan_g> alf_: so for each buffer the scene tracks if each compositor was offered it and if it was then rendered?
<alf_> alan_g: I tried the FrameDroppingPolicy approach, but it has problems.
<alf_> alan_g: I am not sure what you mean with the last comment
<alan_g> Hmm. maybe I'm overcomplicating
<alan_g> Each "thing in the scene that can be rendered"  needs to know whether all compositors offered the opportunity to render it on their last opportunity declined to do so?
<alf_> alan_g: anpok: The current idea is: 1. Each compositor somehow informs the scene (or some other object) which renderables it rendered and which not 2. When a renderable hasn't been marked as not rendered by all compositors, it is considered "occluded" and the client is notified 3. When a renderable is marked as rendered by any compositor it is considered "exposed"
<anpok> alan_g: not sure if it needs to know that it was offered - because if it wasnt offered for other reasons (and thus not rendered) it has to treated like occluded. so not rendered should be enough.
<anpok> but scene needs to track all compositions that happen in parallel and with a different rate..
<alf_> alan_g: anpok: We also need to know when it's being re-rendered after being occluded, to send an "exposed" event.
<alf_> alan_g: anpok: that's step (3) above
<anpok> why do we use something like a renderablelist at all?
<alan_g> alf_: understood. I'm trying to understand how the updates are generated from the information provided.
<alf_> alan_g: oops (2) should be, "When a renderable hasn't been marked as not rendered by all compositors, it is considered "occluded" and the client is notified"
<alf_> alan_g: double oops, should be, "(2) When a renderable *has* been marked as not rendered by all compositors, it is considered "occluded" and ...
<alan_g> when a When a renderable has been marked as "occluded" by *all* compositors then it is considered "occluded". "All" being the compositors to which it was offered.
<alf_> alan_g: right
<anpok> do we have to differ between occluded not offered to any compositor?
<anpok> do we have to differ between occluded *and* not offered to any compositor?
<alan_g> Not offered to any makes "all" trivially satisfied
<anpok> sure, just since you mentioned it, i wondered if in that case a different event is expected to be sent to the client - but I do not see a reason to do so.
<alan_g> We can represent "occluded in compositor X" by an attribute on the thing or as inclusion in a collection.
<anpok> the thing is the buffer inside the renderable list or the surface inside the scene
<anpok> +?
<alan_g> Yes, the "thing in the scene that can be rendered"
<anpok> alf_: wrt naming, some proposals: compositon_result_for(id, rendered, not_rendered), submit_rendering_result_for(id..) )
<alan_g> thing->occluded_in(this);
<anpok> and the opposite
<anpok> and you need to find a point in time when you evaluate the information per thing
<alan_g> the point is time is when thing gets any messages adding/removing compositors or adding/removing occlusions.
<alan_g> Or, using lists: Scene::rendering_result_for(this, RenderableList const& rendered, RenderableList const& occluded);
<anpok> ah so removal of compositors is like occluded_in(stopp_compositor)
<anpok> *stopped
<anpok> alan_g: hm it only needs to store the "rendered by compositor x" information, which is removed on compositor removal, and occlusion, and added on rendering..
<alf_> alan_g: anpok: right, so we can either make "thing" smarter (with the caveat that it needs to have more context), or we manage the logic centrally...
<anpok> otherwise you would never loose occulded informations for removed compositors
<anpok> *lose
<alan_g> OK, I'm getting caught by another discussion. But to answer the original question...
<alan_g> Scene::rendering_result_for(this, rendered, occluded);
<alf_> alan_g|tea: anpok: Thanks! I will think through the details of both approaches (centralized vs distributed logic) and decide.
<alf_> fginther: Hi! Any update on the corrupted chroot tarball?
<anpok> AlbertA: with the current image the keyboard popups seem to be opaque
<anpok> hm no we did not cause that
<AlbertA> anpok: right
<AlbertA> anpok: they are working around it: https://bugs.launchpad.net/mir/+bug/1328952
<ubot5> Ubuntu bug 1328952 in Mir "Compositing with invisible surfaces" [High,Fix committed]
<AlbertA> anpok: until the alpha fix lands officially in archive
<alan_g> alf_: fginther we have some CI successes at last!!!
<anpok> ah ok
#ubuntu-mir 2015-06-08
<alan_g> alf_: anpok got time today for a little USC MP? https://code.launchpad.net/~alan-griffiths/unity-system-compositor/incorporate-logo-into-spinner-binary/+merge/261181
<anpok> ok
<duflu> alan_g: Let me know if you ever find a vectorized version? (just a list of vertices is enough) I like the idea of infinite scalability and 3D effects using the logo in future projects :)
<duflu> Although it has rotational symmetry so should not be too hard...
<alan_g> duflu: sure. Maybe someone in design has something more tractable than a png?
<duflu> alan_g: Dunno. Although I suspect the basic list of coordinates required and then repeated 3/6 times would be hilariously simple
<alan_g> alf_: do you know a way to get a premultiplied image out of any tool? I really don't want to write a script to edit the header.
<duflu> alan_g: Frankly that's the best option to edit in situ. Because the requirement for pre-multiplication is in the code using it and not the image. If someone were to extract the image header and want to edit it, they would not want it pre-multiplied
<alf_> alan_g: I would say don't care about this for now, the sizes are small. I am more concerned about having both .h and .png
<duflu> Even better if we generate the header from png at build time, which I'd recommend
<alf_> duflu: alan_g: Ideally we would produce the .h from .png and change to pre-multiplied alpha there
<alan_g> Creating the header during the build would introduce a dependency on a tool that does that.
<duflu> alf_: Maybe, probably not. If you're using a generic bin2c tool then it should not interpret the bytes it's converting
<alan_g> (And I don't know one that does pre-multiplication
<duflu> alan_g: I've done it many times. Write a bin2c.c tool and generate it at build time too :)
<alf_> duflu: we need to use a tool that dumps the pixel data, so it does know about the pixel format
<alf_> alan_g: I am fine on USC build depending on such a tool
<duflu> alf_: "need" is over-used there :)
<duflu> Just generate your tools at build time. It's a simple matter of *make*
<alf_> alan_g: (and I am fine not doing premultiplication for now)
<duflu> It's not a performance issue. Running through the image once even on a slow device is quite fast enough
<alan_g> How about I delete the .png and if anyone wants to generate the headers they can MP that?
<duflu> alan_g: Reproducability says probably keep it
<alf_> alan_g: In that case don't delete it, I will try to propose an MP with the build time generation later today or tomorrow
<alan_g> alf_: works for me.
<alan_g> Guys, any preferences for which client API? Two options here: http://paste.ubuntu.com/11645578/
<duflu> alan_g: The second one will eventually be required (for type morphing) so probably better
<alan_g> duflu: we can do type morphing with either
<duflu> Well the second one makes more sense to me. You shouldn't need the connection object to morph
<alan_g> The fist one is one call fewer and makes the existing mir_connection_create_spec_for_changes() more reasonable.
<alan_g> *first
<alan_g> But I too lean towards the second
<duflu> alan_g: On that note, why is connection here? mir_connection_create_spec_for_changes(MirConnection* connection);
<alan_g> I've a vague recollection it was for consistency with code we've now deleted.
<alan_g> But I guess we don't need it for the new API
<alan_g> Hmm. mir_surface_create() used the connection supplied to mir_connection_create_spec_for_XXX. Shouldn't the connection just be supplied to directly?
<SturmFlut> tvoss: Ping
<tvoss> SturmFlut, pong
<robert_ancell> RAOF, ping
<kgunn> robert_ancell: is it a holiday over there...wonder if he's off
<robert_ancell> kgunn, ah, is that it
<RAOF> robert_ancell: Pong
<RAOF> kgunn: No, that was yesterday :)
<kgunn> Queen's birthday :)
<robert_ancell> RAOF, had a question about X drivers and Mir - why do the drivers need to know they're running inside Xmir?
<RAOF> robert_ancell: For new glamor-based XMir they don't, because there are no X drivers.
<robert_ancell> RAOF, ah, so we can drop all those patches?
<RAOF> Correct.
<RAOF> Although this is a bit of a bone of contention.
<robert_ancell> RAOF, oh, why?
<RAOF> My understanding is that nvidia would very much like to have the same sort of DDX interface that the Xorg binary provides.
<RAOF> So that they can provide their own GLX, and expose all the funky features that their hardware supports.
<robert_ancell> RAOF, right, but there's always the option of other driver interfaces to Mir like Android
<robert_ancell> RAOF, and I should be pushing these all into Debian git?
<RAOF> If you've got access, please.
<robert_ancell> RAOF, I'm not sure - I guess I should just try and push
<RAOF> Oh, that reminds me...
#ubuntu-mir 2015-06-09
<RAOF> Dear glmark2-es2-mir. Why are you hanging in a syscall on mako?
<RAOF> ARGH! What fool enables -Werror in the release build!
<RAOF> Ok, that's officially weird.
<RAOF> kdub: You don't happen to be here, do you?
<RAOF> Hm. Why isn't libmirclient9 installed?
<RAOF> s/installed/loaded/g
<robert_ancell> RAOF, it appears I don't have Debian git commit access - can you sync over xserver-xorg-video-* changes?
<robert_ancell> I can send you git patches if that helps
<RAOF> I certainly can.
<RAOF> I'm heading out to the physio now, but I'll get to it when I get back.
<robert_ancell> RAOF, no rush
<robert_ancell> RAOF, glamor runs in software right?
<c74d> <https://unity.ubuntu.com/mir/using_mir_on_pc.html> seems to assume that I'm using X11. Can I use Mir without X11?
<robert_ancell> c74d, yes, you can use Mir without X11 (for example running the Unity 8 desktop)
<c74d> thanks
<RAOF> Well, *that's* entirely non-obvious.
<DalekSec> RAOF: Oh hey then, does that mean you work on xorg in Debian too?  Happen to know if #787144 has a chance of being fixed soon/before the next upstream release? :D
<RAOF> DalekSec: I don't know, sorry.
<DalekSec> Hey sure no problem, was a shot in the dark.  I'm sorry to have taken it here.
<RAOF> No need to be sorry :)
<RAOF> Gah. PROTOBUF!
<RAOF> To the âhm, will this workâ CI-a-tron!
<RAOF> You know, if protobuf wasn't so adamant about being never being dynamically loaded we could actually embed the protocol stuff in libmirclient and libmirserver...
 * duflu shrugs
<duflu> OK, progress of the unexpected sort: Turns out this is another case of the test methodology being buggy and not the product
<RAOF> :)
<RAOF> duflu: Do you happen to know where the buffer-semantics-rework doc is?
<duflu> RAOF: Nope. I was mostly uninvolved
<alan_g> alf_: is the new comment enough for you? https://code.launchpad.net/~alan-griffiths/mir/NestedServer.posts_when_scene_has_visible_changes/+merge/261103
<alf_> alan_g: yes, thanks
<screwsss> what is mir
<alan_g> screwsss: see the channel topic
<racarr> Good morning! found bug testing touch stream rewriter yesterday....working on that now
#ubuntu-mir 2015-06-10
<duflu> Why is it every time I look, Ubuntu is using a kernel that upstream has end-of-life'd ? :)
<duflu> https://www.kernel.org/
<duflu> We never seem to be using the long term supported ones
<greyback_> alan_g: network dropped, have you a link to the HO?
<alan_g> https://plus.google.com/hangouts/_/canonical.com/mir-qtmir?authuser=0
<alan_g> tvoss: ^
<tvoss> alan_g, ack
<kdub> its gotten tricky to be sure whats the source of a CI failure
<kdub> hmm, anyone know anything about glmark breaking with abi changes? I've found https://bugs.launchpad.net/mir/+bug/1341490, but what I see seems slightly different
<ubot5> Launchpad bug 1341490 in Mir "Bumping the client ABI causes CI failures" [Medium,Triaged]
<kdub> because i shouldnt be bumping or breaking anything in https://code.launchpad.net/~kdub/mir/multiple-bufferstream-api/+merge/261123
<alan_g> kdub: the most recent problem with glmark was that the version of libmirclient8 from 0.12 loaded libmircommon3 but the 0.14 drivers that were loaded also loaded libmircommon4
<alan_g> Once 0.13 hit archive that "went away"
<kdub> hmm, dunno if thats what i'm hitting in this problem
<alan_g> I doubt it.
<AlbertA> kdub: another MP is also hitting the same glMark issue... https://code.launchpad.net/~raof/mir/input-methods-can-specify-foreign-parents/+merge/258001
<kdub> AlbertA, right, and that one adds another function to the mir_surface api too....
<kdub> so the glmark definitely is a loading mirclient8 when mirclient9 should be loaded
<kdub> issue
<AlbertA> kdub: oh is it loading libmirclient8 then using the built libmirprotobuf.so.0 from the cI build?
<kdub> possibly, have been able to get a backtrace
<kdub> http://pastebin.ubuntu.com/11690920/
<AlbertA> kdub: but in any case, do we even want a libmirclient8 talking to a server released with libmirclient9?
<kdub> probably not
<kdub> maybe we need to bump the protobuf number?
<AlbertA> kdub: seems like we need to disable glmark for now since we bumped client ABI until release...
<kdub> AlbertA, because we don't build glmark against the code that's being landed?
<AlbertA> kdub: right. it's just a package dep
<AlbertA> kdub: or rather I guess it's just a package installed by the mir mako runner scripts
<kdub> hmmm
<AlbertA> kdub: so looking at RAOF's branch - protobuf seems like the only suspect to cause the glmark crash...
<AlbertA> probably stack protobuf objects that are now a different size in the new libmirprotobuf.so.0....
<AlbertA> do we have libmirprotobuf as an .so to share between client and server?
<AlbertA> it does seem like we need to bump the protobuf ABI then....
<AlbertA> or at least when we bump libmirclient ABI
<AlbertA> and there's been a protobuf change
<kdub> AlbertA, right, that seems sensible to me too
<racarr> whee...all my tests passing now and working on device for touch stream rewriter...just code cleanup now.
<alan_g> You enjoy cleaning up code?
<racarr> alan_g: I feel like you are kind of pointlessly mean to me sometimes
<racarr> (e.g. above)
<racarr> sorry I'm sure you consider it as having intent
<racarr> and are trying to communicate something to me
<alan_g> racarr: actually I'm glad you are not tempted to skip the "clean up" bit.
<racarr> but I don't really appreciate it when it's phrased like that
<alan_g> I was just amused by your phrasing
<alan_g> Sorry that it read differently
<racarr> lol I understand sorry.....
<racarr> no, my fault lol
<conyoo> o_O
<alan_g> no, no, my fault. I was careless in my phrasing.
<racarr> such is our internet life.
<bschaefer> mterry, would deb2snap work on armhf?
 * bschaefer only saw x86/x64 libs on it
 * bschaefer tests it out
<mterry> bschaefer, heyo -- it would work, but you may have to do it inside an armhf machine
<mterry> s/may//
<bschaefer> mterry, right, its what i was thinking i would have to do
<mterry> bschaefer, it *should* work
<bschaefer> mterry, as it looks like it does some fun ldd work :)
<bschaefer> haha yeah :)
<bschaefer> *should* work is usually worth a try
<bschaefer> mterry, thanks!
<kgunn> mterry: hey before i let the day get away from me....again...i'm going through review comments on my attempt to upload mir snap to store
<mterry> kgunn, oooh OK
<kgunn> and one question was about the global socket vs user
<kgunn> i mean on one hand i guess you could argue it doesn't matter for the type of device
<kgunn> e.g. it's probably not gonna have multiple apps
<kgunn> but just wondering, was there something troubling about using the var/run/user/*/mir_socket
<kgunn> ?
<kgunn> mterry: ^
<kgunn> or is that just what mir_demos* use...
<mterry> kgunn, didn't try it, but I thought compositors were expected to be per-device, not per-user
<kgunn> mterry: i guess that is true for a "system compositor"
<kgunn> altho in ubuntu touch i think u-s-c is actually per user....?
<mterry> kgunn, no even there it's run as root for the whole system
<mterry> kgunn, (otherwise it'd be hard to do the split greeter, which runs as a separate user)
<mterry> kgunn, unity8 is its own compositor of course (for the user).  But u-s-c is system wide
<kgunn> holy crap...just grabbed krillin, it's been on for 3 days idling hardly any battery gone...impressive
<mterry> kgunn, I'm .. pleasantly shocked?   :)
<kgunn> me too
<kgunn> mterry: ok, thanks...i think i've got the ammo to argue that one away now
<kgunn> mterry: one last one...i got dinged on confinement, so doing a lot of reading....is it just "work" ? or is there some mystery there....
<kgunn> guessing you know from being a snappy dude now :)
<mterry> kgunn, can you explain that a bit?
<racarr> Lunch!
<mterry> kgunn, I can explain the current Mir confinement a bit?  Or are you talking about something else?
<kgunn> mterry:  security_template_valid (meta/system-compositor.apparmor)
<kgunn> 	(MANUAL REVIEW) 'unconfined' not allowed
<kgunn> Why is this running unconfined? Framework services and binaries should also all run under confinement.
<mterry> kgunn, ah yes
<mterry> kgunn, that was laziness on my part
<mterry> kgunn, so just "work"
<kgunn> you lazy so and so
<mterry> kgunn, there needs to be some investigation on what exactly u-s-c needs
 * kgunn keeps reading hoping for a payoff...
<mterry> kgunn, so basically that's likely just running it confined and seeing what DENIED comments you get in syslog
<mterry> kgunn, and then crafting an apparmor file with exceptions
<mterry> kgunn, similar to the apparmor file for clients
<kgunn> ok
<mterry> kgunn, in meta/framework-policy/
<kgunn> mterry: yep...i'm familiar :)
<kgunn> i've already made some mods
<mterry> kgunn, that one I did put some thought into and worked with jdstrand a bit to tighten it as possible
<mterry> kgunn, oh good
<mterry> kgunn, I figured it was more important to get that right than worry about the server side of things, which is something we wrote
<mterry> kgunn, but I guess the store reviewers/admins didn't see it that way  ;)
<kgunn> which btw, are you ok for me to just push changes to snappy-packaging ?....or, should i keep a seperate branch
<mterry> kgunn, naw that's fine.  I put it under mir-team so that it could be edited as needed
 * kgunn has been known to tear up steele balls with rubber hammers
#ubuntu-mir 2015-06-11
<RAOF> AlbertA, kdub: The problem with libmirprotobuf ABI bumps is that they're not parallel-loadable.
<RAOF> AlbertA, kdub: That said, given the alternative is stack smashing anything using libmirclient8, it seems the lesser of two weevils.
<AlbertA> RAOF: ? why not?
<RAOF> AlbertA: Two reasons: (1) Protobuf throws an abort() fit if you try and load it twice, and (2) none of the symbols are versioned, so they'll stomp on each other.
<RAOF> I mean, it might accidentally work, but you also might get libmirclient.so.8 calling into a mixture of libmirprotobuf.so.0 and libmirprotobuf.so.1.
<RAOF> (Or libmirclient.so.9, for that matter)
<RAOF> If (1) wasn't true we'd be statically linking mirprotobuf into mirserver and mirclient as nature intended.
<AlbertA> RAOF: oh you mean in the same process? but how would that happen? wouldn't the linker see libmirclient9 is linked to libmirprotobuf2?
<RAOF> Yeah, in the same process.
<AlbertA> or libmirprotobuf1 rather....
<RAOF> The linker doesn't check that; the linker sees that libmirclient.so.8 needs libmirprotobuf.so.0 and libmirclient.so.9 needs libmirprotobuf.so.1.
<RAOF> It doesn't do any symbol resolution at that point, though.
<RAOF> When it *does* try to resolve the symbols it'll do the wrong thing, though - any call from libmirclient.so.8 will hit the same code as the same call from libmirclient.so.9.
<AlbertA> RAOF: right.... but how did we get to the point of loading both libmirclient.so.9 and libmirclient.so.8 in the same process?
<RAOF> I don't think any code that *we* produce will do that.
<AlbertA> RAOF: ahh ok...like it's possible...like something loading plugins for example....yeah....
<RAOF> But it's by no means impossible - something using SDL + Qt, maybe?
<RAOF> Right.
<RAOF> And should someone *do* that it will fail in an *entirely* inscrutable fashion.
<AlbertA> right....
<RAOF> FWIW I've bumped the ABI on my branch.
<RAOF> Because *definitely* inscrutably killing everything that uses libmirclient.so.8 is worse than possibly killing someone linking to both libmirclient.so.8 and libmirclient.so.9 :)
<RAOF> But, basically, protobuf is terrible and should feel bad :)
<AlbertA> RAOF: one more reason to move away from it...yeah
<AlbertA> :)
<duflu> OK my usual technique for replacing USC with Mir for testing is not working on krillin. What's the other way to stop USC from starting?
<duflu> (Not working means USC steals the touchscreen and a second server can't get input)
<alf_> duflu: isn't 'stop lightdm' working for you?
<alf_> (sudo)
<duflu> alf_: Forgot to try that. Now it's semi-bricked. This will take time to get back
<duflu> Funny thing about ubuntu-device-flash is that if you don't really know what you're doing and repeat enough times it will eventually work
<RAOF> Unless you're flashing a N10, at which point you should probably load android on it and *then* try flashing it.
<duflu> RAOF: Yes that has worked in the past too
<duflu> Heh. Or I could just Google the problem and get a solution from AskUbuntu fairly quickly (which is the same solution I stumbled on for another phone recently)
<RAOF> Is there a good way to test threadsafety?
<duflu> RAOF: helgrind and/or threadsanitizer of course
<RAOF> Right, but is there a good way to ensure that they actually pick up races / lock ordering problems / etc?
<RAOF> Or is it just âdo a whole bunch of things on a whole bunch of threads and hope that you hit a bad codepathâ?
<duflu> RAOF: They do assume your test coverage is reasonable
<RAOF> But more than that, right?
<RAOF> I mean, they assume not only that you hit every line of code, but that you hit a lot of temporal combinations.
<duflu> RAOF: Well in both cases they report theoretical errors before they happen. But still to get that far you need some reasonable test coverage to touch the code paths. They do not however rely on bad luck; they're better than that.
<RAOF> True; they don't need you to *actually* hit a data race.
<RAOF> You do still need to have multiple threads hitting the appropriate bits, though.
<duflu> Does anyone know why Mir-demos (trunk) can't get any touch events on krillin? I'm almost out of ideas, and now bisecting to see if older code works
<duflu> Ugh, it's a Mir bug. Logging it now
<alan_g> alf_: incorporated your USC code improvements. Thanks
<alf_> alan_g: you are welcome
<alan_g> anpok: How's this? https://code.launchpad.net/~alan-griffiths/unity-system-compositor/incorporate-logo-into-spinner-binary/+merge/261181
<anpok> looking
<anpok> ah and now const
<anpok> hm i am marked as community
<alan_g> Wear it with pride
<alan_g> AlbertA: as you've not contributed code to it, care to review this? https://code.launchpad.net/~alan-griffiths/unity-system-compositor/incorporate-logo-into-spinner-binary/+merge/261181
<AlbertA> alan_g: yeah taking a look
<alan_g> thanks
<AlbertA> gah...I guess mirclientplatformmesa does need to link against libmirclient....
<AlbertA> mir_platform_message_xxx apis...
<anpok> AlbertA: and also other platforms because of the event builders
<kgunn> mterry: hey, starting to look into snap stuff again...so, pidof...doesn't that seem a bit hardcore to not have access to a tool like that ? i mean
<kgunn> to have to explicitly say you want some basic tool, that seems weird to me
<mterry> kgunn, it's leaking info about what else is running on the system
<mterry> kgunn, default app isolation is quite intense
<kgunn> no kidding
<kgunn> so things like top couldn't either
<kgunn> just seems weir
<kgunn> d
<mterry> kgunn, might be able to run it, but only see some pids?  not sure
<mterry> kgunn, so it's a tricky problem for mir
<kgunn> i was just looking at that script...
<mterry> kgunn, the original reason was that the tty races with mir
<mterry> kgunn, mir might show first, then gettty takes over the screen
<mterry> kgunn, but duflu was actually saying there was a mir bug there
<mterry> kgunn, that it should notice it got stolen
<kgunn> ah
<mterry> kgunn, so that might be another solution
<kgunn> vongons ^ anyone aware of that one ?
<kgunn> mir getting screen taken by getty
<kgunn> (....and is it getty or agetty?)
<kgunn> mterry: ok, as i am reading...i just realized that not declaring security-template default is not the same as declared security-template but empty default
<kgunn> so i think i need to rebuild...as i just commented that out
<mterry> kgunn, it might be agetty
<mterry> kgunn, huh...  it should be the same?  if you just don't have that line at all, it should use the default
<kgunn> mterry: how do you read https://developer.ubuntu.com/en/snappy/guides/security-policy/
<kgunn> "Defining snap policy"
<kgunn> When caps and security-template are not specified, caps defaults to client networking.
<kgunn> vs
<kgunn> security-template: (optional) alternate security template to use instead of default. When specified without caps, caps defaults to being empty. Not compatible with security-override or security-policy
<kgunn> Additional access beyond what is allowed by the declared security-template is declared via this option
<mterry> huh
<mterry> well, if you leave out both, you'll be fine right?
<mterry> you don't care if caps includes networking
<mterry> kgunn, ^
<mterry> gotta run, bbl
<mterry> kgunn, heyo -- any progress on apparmor security stuff?
<mterry> grr, missed
<anpok> hum
<anpok> nexus10 provides pressure, touch major AND orientation.. but no minor .. or tool width..
<racarr> ...*bangs head on desk*
<racarr> I've been testing this scenario for like a day and wondering where events dissapear too
<racarr> and I forgot about the input filters in mir_demo_server
<racarr> ....lol
<racarr> got some good tests out of it at least
<ahayzen> Hi, I tried to run unity8 via LXC as per https://wiki.ubuntu.com/Unity8inLXC on Intel ivy bridge hardware, but when i start the session the mouse appears, the welcome wizard appears for a split second then disappears and reloads itself going into a loop. Meanwhile the CPU/disk start increasing in load as I assume apport or something is going mental in the background. Is there anything I can do to see what is causing the welcome wizard to crash?
<ChrisTownsend> ahayzen: Hi!  Try looking in ~/.cache/upstart/unity8.log and see what it may be spewing out.  Also use top and see what process is running at the high load.
<ahayzen> ChrisTownsend, hmm nothing obvious in the log, how am i supposed to run $ top if i can't switch tty ?
<ChrisTownsend> ahayzen: Do you have ssh set up on the machine?
<ahayzen> not yet ;-)
<ChrisTownsend> Hmm, yeah, then no top.
<ahayzen> heh i'm gonna have to SSH in via my ubuntu phone to debug my desktop aren't I? lol
<ChrisTownsend> It sounds like Unity 8 is having some issue, but it's hard to tell what though.  I haven't seen that behavior.
<ChrisTownsend> lol, the irony!
<ChrisTownsend> ahayzen: Is your user's home in the standard place, ie, /home/$user
<ahayzen> i would assume, all i did was follow the instructions
<popey> he
<ChrisTownsend> ahayzen: The Unity8 LXC bind mounts your normal user's home directory.  If it's the standard, then yeah.
<ahayzen> (the ones that popey gave me) #blamepopey
<popey> I get the same black screen here
<popey> yup yup
<ahayzen> i was at Oxfordgeeknights last night and another person on intel hardware said he had the same
<ChrisTownsend> Hmm, to me, welcome wizard reload over and over is a bit different than the black screen.
<ChrisTownsend> ahayzen: What version of Ubuntu is your host?
<ahayzen> it like flashes up for a split second then goes blank then comes up again in a loop, but the mouse stays visible and useable throughout
<ahayzen> vivid
<popey> I'm on wily
<ChrisTownsend> ahayzen: Ok.  Anything abnormal in /var/log/lightdm/unity-system-compositor.log?
<ChrisTownsend> popey: Black screen sounds like a u-s-c issue.  Have you looked in the file I just noted?
<ahayzen> WARNING: QApplication was not created in the main() thread. ... then lots of Opening session session-0
<ahayzen> Closing session session-0
<popey> no, will try now
<ChrisTownsend> ahayzen: Sounds pretty normal.  I'm kind of stumped.:-(
<ahayzen> hmm let me update it, rerun and get some fresh unity8 logs
<ChrisTownsend> ahayzen: Ok.  I need to go in a few minutes.  I'll be around tomorrow.  You can also file a bug against unity8-lxc and I'll take a look.
<ahayzen> ChrisTownsend, ok thanks for your help
<ChrisTownsend> ahayzen: Are you using the PPA or the version from the archive?
<ahayzen> PPA IIRC
<ChrisTownsend> ahayzen: Ok, that's good.
<ahayzen> yeah ppa:unity8-desktop-session-team/unity8-preview-lxc
<popey> i ave no unity8.log
<ChrisTownsend> ahayzen: Yeah, that's best.  I'll try it on my Vivid machine and see what happens.
<ChrisTownsend> popey: Yeah, look at /var/log/lightdm/unity-system-compositor.log.
<popey> http://paste.ubuntu.com/11698588/
<ChrisTownsend> popey: Your not even getting Unity 8 started.  It's seems like Mir is not happy.
<ahayzen> interesting mine isn't too dissimilar http://pastebin.ubuntu.com/11698589/
<ChrisTownsend> ahayzen: popey: Alright, I think they are different issues.  I gotta go though.  I'll either ping you or find me tomorrow.
<popey> okay
<popey> thanks
<ahayzen> thanks
<popey> ahayzen: lets gang up on him tomorrow :)
<ahayzen> popey, hehe :-)
<ahayzen> popey, what happens if you run top? I see unity8 using ~90% and ms2 using ~90%
<popey>  4653 alan      20   0 2790820 218392  84428 S 102.7  2.7   5:29.18 unity8
<popey> ya
<popey> i dont have any media on this
<popey> unrelated, have you installed tweakgeek?
 * ahayzen notes to look into ms2 being terrible on desktop
<ahayzen> ...no?
<popey> install mzanetti's open store, grab tweakgeek from it, run that and you can make terminal live beyond app lifecycle :)
<popey> so they run in the background. handy when you want to ssh into something from the device
<ahayzen> ooo cool, can we not keep the screen on yet ;-)
<popey> not yet
<ahayzen> ok that sortof stuff in the unity8 log looks bad.... [1434057338.091424] <ERROR> Mesa/NativeSurface: Caught exception at Mir/EGL driver boundary (in advance_buffer): /build/buildd/mir-0.12.1+15.04.20150324/src/client/rpc/stream_socket_transport.cpp(154): Throw in function virtual void mir::client::rpc::StreamSocketTransport::send_message(const std::vector<unsigned char>&, const std::vector<mir::Fd>&)
<ahayzen> Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorIN3mir25socket_disconnected_errorEEEEE
<ahayzen> std::exception::what: Failed to send message to server: Broken pipe
<ahayzen> 32, "Broken pipe"
<ahayzen> my full unity8 http://pastebin.ubuntu.com/11698632/
<ahayzen> popey, shall i report a bug with ^^ ?
<mzanetti> ahayzen, well... you can install bigmovingtext from openstore ;)
<mzanetti> that can keep the display lit
<ahayzen> i have the normal bigmovingtext...
<mzanetti> ahayzen, that boost exception happens when something tries to grab an invalid screen buffer
<mzanetti> I think
<mzanetti> where did you get it?
<ahayzen> there is alot of them :-)
<ahayzen> from .cache/upstart/unity8.log
<ahayzen> when running on a vivid ivy-bridge laptop with unity8 in LXC
<mzanetti> oh, I see
<mzanetti> hmm. not sure then what it is
<mzanetti> ahayzen, you might want to stop by in #ubuntu-unity tomorrow and talk to greyback about it
<ahayzen> ok :-)
<popey> pass ahayzen
<ahayzen> we'll be really nice to everyone and bug them late friday then :-)
<popey> \o/
<AlbertA> ahayzen: that exception just means the server died or got shut down while the client was still alive
<AlbertA> so if it's in unity8 log, then I guess because USC died...
<ahayzen> AlbertA, interesting
#ubuntu-mir 2015-06-12
<tmpRAOF> Hm. So, the libmirprotobuf rabbit-hole.
<RAOF> I have a number of possible hacks, each more awkward than the last.
 * duflu wonders if a swear jar is required for lib*protobuf
<RAOF> I think I'm going to plump for âassert that we'll be able to fix this before we need more than 2^31 surface IDs and abuse the highest bit of output_id to indicate that there's a follow up message comingâ.
<RAOF> if (id & 1<<31)
<RAOF> Aww, yeah.
<RAOF> Huh.
<RAOF> Why do we have both SurfaceCreationParameters and SurfaceModifications, I wonder.
<RAOF> s/SurfaceModification/SurfaceSpecification/
<greyback> "SurfaceParameters" to be consistent?
<RAOF> Yeah.
<RAOF> I'm not sure why we have two different structs for âhere are the properties of this new surfaceâ and âhere are the new properties of this surfaceâ
<RAOF> Hm.
<RAOF> Now that I say that... apart from the only-these-properties changed thing.
<RAOF> So, yeah, that's actually totally fine.
 * RAOF decides not to write a test that Mir correctly returns an error when a client tries to create 2^31 surfaces.
<alf_> RAOF: Hi! Did you have a chance to take a look at the glmark2 package?
<RAOF> alf_: Oh, sorry. Not yet.
<RAOF> I'll just get to that before EOD.
<alf_> RAOF: no worries, thanks
<RAOF> alf_: Any reason for it to be arch restricted anymore? Mir builds everywhere now.
<alf_> RAOF: Even the archive version?
<alf_> RAOF: (no reason on the glmark2 side)
<RAOF> I'm pretty sure wily has an everywhere-built mir, but rmadison is being *super* slow to verify that for me :)
<RAOF> Yup.
<alf_> RAOF: ok, I will update the package then
<RAOF> I can do it if you like.
<RAOF> It otherwise looks fine, so I'll upload.
<alf_> RAOF: Sure, go ahead then. Thanks!
<RAOF> alf_: glmark2 uploaded. Enjoy.
<alf_> RAOF: thanks
<alan_g> greyback: I'm working on the "system compositor" logic and just wanted to check something you probably know. Mir's nested server logic creates a fullscreen surface in the host for each display it uses. I don't see that U8 would want anything else, but could it?
<greyback> alan_g: I can think of no reason why it would want a non-fullscreen surface
<alan_g> Thanks.
<duflu> alan_g: Fullscreen also means we get bypass/overlays, which is a very good thing
<alan_g> duflu: yes, my thinking was that for a system compositor we disallow anything else
<duflu> alan_g: "Disallow" is probably too strong a word. Examples of non-fullscreen surfaces could be transitions between sessions, or on-screen keyboards for login
<alan_g> Hmm. Would an OSK be a client of the system compositor?
<duflu> alan_g: Perhaps. But one of the main reasons for nesting is transitions. And that can involve sliding (hence surfaces not fullscreen briefly)
<duflu> Oh, actually they are fullscreen. Just animated to not look fullscreen
<alan_g> duflu: I was referring to surfaces a client can create, not what the host can do internally
<dednick> tvoss: https://docs.google.com/spreadsheets/d/1g1u3RjukeEdTAk0WPHsVuf42apVm3iepMdC82oJ1TcA/edit#gid=1176402920
<dednick> ah, actually, the server is a mix of two. let me separate
<tvoss> dednick, mind increasing the sample size such that distribution characteristics become a bit more apparent?
<dednick> tvoss: ok
<tvoss> greyback_, ^
<greyback_> +1
<tvoss> dednick, any chance you automate creation of those histograms? R is pretty helpful in doing that stuff
<tvoss> dednick, also: validateAndDeliverTouch - dispatchTouch is interesting
<tvoss> dednick, probably more interesting than the per event timings, although we could leave those in, too
<dednick> tvoss: probably could do. if you think it's worth putting the effort in. never used R though, so may take some time.
<tvoss> dednick, okay, let's do this in gdocs for now, but we should look into automatically generating reports like this
<tvoss> dednick, not necessarily you, though :)
<dednick> tvoss: :) ok
<greyback_> we were discussing this at our sprint in dallas, so it's a work item somewhere on the mir team's plate
<tvoss> greyback_, I think want similar reports for u8, too
<tvoss> greyback_, it's probably as easy as emitting an lttng event
<greyback_> tvoss: ofc, I wanted them to have a reporting interface u8 could link into
<alan_g> alf_: I've been playing with system compositing/guest compositor on my desktop and have seen some intermittent problems with vt switching, closing the nested session and fatal errors in RealKMSOutput::clear_crtc(). Is there any chance that the "platform" in the nested session if fighting with the host over the hardware? Do you know where I should start looking?
<dednick> tvoss, greyback_ : updated with increased sample size
<tvoss> dednick, does that have the difference, yet?
<dednick> tvoss: difference?
<alf_> alan_g: The nested platform doesn't (shouldn't) have access to the display hardware at all, so it's unlikely that there is a conflict there. At some point Intel had some problems with VT switching, and perhaps it still does.
<tvoss> dednick, the difference between validateAndDeliverTouch and dispatchTouch for server
<dednick> tvoss: ah. no
<alan_g> alf_: that's how I thought it should be. I'll see if I can nail down a repeatable scenario (ideally without a VT switch).
<anpok_> dednick: Diff is the time the event spends within the event loop?
<anpok_> or the qtquick scene dispatch..
<dednick> i'm adding now
<anpok_> kernel version?
<anpok_> @vt switching problem?
<anpok_> oh ok scrolling back .. i only experienced system freezes and kernel panics.
<dednick> tvoss, greyback_ , anpok_ : diff is on now.
<tvoss> dednick, greyback_ so seems like the majority lies around 15ms
<anpok_> diff is difference between two events?
<dednick> ya. problem is that it's not the majority we're worried about. most of scrolling is smooth, but it's the outliers that's causing the problems.
<tvoss> dednick, I think you are not calculating the diff between timestamps, but the diff between event timestamp deltas
<dednick> hm. actually not sure if diff is showing anything in this case. we need to do timestamps
<dednick> ya
<tvoss> dednick, yup
<anpok_> oh so diff is between receive and send?
<dednick> greyback_: what do we get first? the qtmir event feeder event? or the MirSurfaceItem event? it's the feeder right? just need to make sure things are actually in sync
<greyback_> dednick: feeder
<greyback_> that pushes the events onto qt's event loop, which trickle through the scene, until they hit a MirSurfaceItem, where they dispatched to client
<dednick> right. that's from u8 surface as client in usc
<greyback_> yep
<dednick> excellent...
<dednick> tvoss, greyback_ , anpok_ : diff is on a new sheet
<tvoss> dednick, awesome
<greyback_> interesting long tail
<greyback_> dednick: I'd be curious if turning off Qt's input event resampling has any impact on that graph
<dednick> greyback_: the compression?
<greyback_> dednick: yea
<greyback_> h
<dednick> greyback_: this is without compression
<greyback_> dednick: ah ok
<dednick> might be interesting to see it with.
<dednick> although i wonder if the events won't line up anymore
<dednick> not 1 to 1?
<greyback_> that is what we're using right now
<greyback_> would be nice to know what the main loop is doing on those slow dispatch times
<dednick> so the diff here is between the QtEventFeeder and the MirSurfaceItem, both on server. need to check between QtEventFeeder and client as well probably.
<dednick> although that's just measuring latency
<dednick> majority is around 25ms latency between server->client. But plenty outliers. Particularily worring are a few in the order of 100's of ms.
<dednick> between 500ms and 1300ms.
<anpok_> O_O
<dednick> assuming all my data is correct. but should be able to see if it wasn't (should slowly go totally out of sync if it wasn't aligned).
<tvoss> anpok_, could you provide your packages for the non-resampling version to dednick?
<anpok_> tvoss: i used the MIR_CLIENT_INPUT_RATE=0 setting
<anpok_> which passes -1 to the consumer..
<tvoss> anpok_, okay
<dednick> are the stamps at start of a mir log timestamps?
<dednick> [1434111685.022267] input: Received event finished ....
<anpok_> yes
<anpok_> seconds.microseconds
<dednick> graphed the android input channel as well.
<tvoss> anpok_, you sure that those are milliseconds?
<tvoss> dednick, is that server or client?
<anpok_> micro
<anpok_> code does "tv_sec and tv_usec/1000
<anpok_> what are you looking at?
<tvoss> andyrock, https://docs.google.com/spreadsheets/d/1g1u3RjukeEdTAk0WPHsVuf42apVm3iepMdC82oJ1TcA/edit#gid=2092414509
<tvoss> anpok_, https://docs.google.com/spreadsheets/d/1g1u3RjukeEdTAk0WPHsVuf42apVm3iepMdC82oJ1TcA/edit#gid=2092414509
<anpok_> thats the time difference between two event..
<ChrisTownsend> ahayzen: Hey, are you around?  Following up on your unity8-lxc issue from yesterday.
<tvoss> anpok_, sure, asking for the unit :)
<ahayzen> ChrisTownsend, i'm at work at the moment so will be about later, but i managed to get a full unity8 log http://pastebin.ubuntu.com/11698632/ which shows some errors, and it was unity8 and ms2 using ~90% cpu each
<ChrisTownsend> ahayzen: Ok, I'll look over your log.   Just ping me later when you have some time.
<ahayzen> thanks
<ChrisTownsend> ahayzen: Sure.  Just looking at that error, it seems the Mir version in the container is out of date.  When you begin to look at this, let' start from a fresh baseline.  Do 'sudo unity8-lxc-setup --rebuild-all --redownload' and then try it again.  If it still fails, then we'll dig deeper.
<ahayzen> ChrisTownsend, cool thanks
<anpok_> average time diff between events is 13ms in my sample set .. but like 93% are in  the range of 8ms to 10ms
<dednick> tvoss: the andoid channel? it's u8 process. MIR_SERVER_INPUT_REPORT
<tvoss> dednick, ack
<alan_g> alf_: the Ctrl+Alt+Fn event to request VT switch ought to be handled in the host server right? I've discovered a way to hang input in a *nested* server and that prevents the request being serviced. (I can 'chvt n' perfectly well from ssh)
<attente> hi, is the mir demo server working for anyone? i'm getting an error: <ERROR> mircommon: Failed to load libraries from path: /home/william/Code/jhbuild/install/lib/mir/server-platform (error was:No such file or directory)
<anpok> attente: you might not have the mir-graphics-drivers-desktop installed?
<anpok> oh
<anpok> thats from a build dir..
<attente> anpok: i just built it from trunk
<attente> for some reason it didn't install into that directory but i'm not sure why
<anpok> ok .. you can either change CMakeCache.txt by switching the platforms built to :
<anpok> MIR_PLATFORM:=STRING=mesa-kms;android
<anpok> (it was renamed)
<anpok> or redo the build directory
<attente> anpok: oh ok, thanks. should i file a bug for that?
<anpok> hm
<attente> oh. it's already like that in CMakeLists.txt though
<anpok> it is not really a bug.. in theory MIR_PLATFORM is a developer setting..
<anpok> so since that value already exists
<anpok> when the change came
<anpok> cmake did not overwrite it..
<attente> anpok: ok, i see what happened thanks. i was in an older source directory
<ahayzen> ChrisTownsend, if your about, i totally forgot I got this when i installed http://pastebin.ubuntu.com/11703788/ not sure if it affects the welcome wizard not working?
<ChrisTownsend> ahayzen: That looks normal.  I have to install upstart and remove systemd in order for it to work.  LXC and systemd do not mix in this instance, at least the last time I tried.
<ahayzen> ChrisTownsend, ok just wanted to check :-)
<ChrisTownsend> ahayzen: Yeah, kind of looks scary if you don't now what's going on.
<ahayzen> right time to switch sessions and see if it does its normal thing...
<ahayzen> ChrisTownsend, OMG it works \o/
<ChrisTownsend> ahayzen: Awesome!
<ahayzen> now onto the next issue... why when i hold my finger in a static position on the touchpad does my mouse move? lol
<ChrisTownsend> ahayzen: popey is also all taken care of, so my work is done:)
<ahayzen> \o/
<ChrisTownsend> ahayzen: That touchpad issue is probably something in Mir.
<ahayzen> ChrisTownsend, thanks for your help getting me running anyway :-)
<ChrisTownsend> ahayzen: Sure, you're welcome!
<anpok> tvoss: i think i really had corrupted data sets..
<anpok> but only a few measurements are affected
<anpok> two of the timestamps i care about are in the distant future
#ubuntu-mir 2015-06-14
<rsalveti> racarr_: any news on https://code.launchpad.net/~mir-team/platform-api/delete-deprecations/+merge/254170 ?
<rsalveti> gst-plugins-bad1.0 is currently broken on proposed because it uses window.h as well
<rsalveti> but I guess we first need to land this and then rework the gst patch
<racarr_> swartzcr:
<racarr_> woah
<racarr_> whoops
<racarr_> cross channel typo :p
#ubuntu-mir 2016-06-15
<robert_ancell> anyone know of a libmirserver-glib project?
#ubuntu-mir 2016-06-17
<alan_g> alf_: Just checking my thinking... there's no way for a server based on Mir to detect that the server is about to shutdown? (Beyond hooking signals, and policing its own use of stop())
<alf_> alan_g: I don't think so, but I guess it depends on what "about to shutdown" means. What's the use case?
<alan_g> In miral I want to exit an "in process client" before the server closes the connection
<alan_g> So SIGINT, or Ctrl+Alt+BkSp, or ...
<alf_> alan_g: Would adding a ServerStatusListener::about_to_stop and calling it just after the mainloop exits in DisplayServer work for you?
<alan_g> alf_: I think it would be better if it happened before the mainloop exit. But I was really checking I wasn't missing an existing method.
<alf_> alan_g: there isn't an existing method I am aware of
<alf_> alan_g: I am thinking of making a few changes to the tiling window manager in miral, but wanted to check with you first. The core of the changes is that every surface always takes up exactly the space provided by the tile (as long as the app itself allows that, not sure we support max/min sizes?). With multiple tiles, resizing a tile/surface will just give more space to the others.
<alf_> alan_g: A concern I have is that this will start to increase the complexity of the tiling WM and perhaps we want to keep it more simple as an example, rather than a full blown tiling WM?
<alan_g> alf_: Please go ahead - I want the WMs in Miral to be serious efforts that test the API, not proof-of-concept examples.
#ubuntu-mir 2016-06-18
<tom___> F
#ubuntu-mir 2017-06-17
<TronFourtyTwo> Hello! Anyone around?
