[01:45] <RAOF> Sweet! Implicit serialisation FTW!
[12:41] <dandrader> anpok_, hi
[12:41] <dandrader> anpok_, any ETA on the input_sender branch?
[12:45] <anpok_> hm
[12:45] <anpok_> I am on holiday this week
[12:45] <anpok_> I am looking for shepard ..
[12:46] <anpok_> thought I had everythin cleaned up this morning, but there are still concerns regarding nameing
[13:04] <dandrader> anpok_, we *really* need this in.
[13:05] <dandrader> anpok_, so I was thinking about landing it now and fix any badly named bits later
[13:06] <dandrader> mir interfaces are constantly changing here and there anyway (which is natural). so that should not be a big deal
[13:52] <racarr_> Morning
[14:11] <kgunn> greyback: alf_ has been working on the "visibility" i/f for the client in order to help friendly-stop rendering (vs depedning on life cycle events)
[14:11] <kgunn> question is
[14:12] <kgunn> is that as important? or less so than the orientation i/f we just discussed
[14:12] <kgunn> (which is new to mir guys)
[14:38] <greyback> kgunn: sorry, was in other meeting. visibility is a nice to have, orientation is more useful however
[14:40] <kgunn> greyback: does this need to be a built in mir i/f ?...or use opaque shell-app channel ?
[14:40] <kgunn> just needs to be spec'd
[14:41] <greyback> kgunn: opaque shell-app channel only 1 way sadly - client can give shell information, or ask shell for information. But shell can't send client info with it
[14:42] <greyback> kgunn: so there are 2 parts. 1) shell tells a client - the current orientation has changed to <something>. 2) client tells shell, this is the list of orientations I support
[14:43] <greyback> 2) could use the side-channel, but 1) cannot
[14:43] <kgunn> camako: alf_ ^
[14:44] <tvoss> greyback, why does the shell need to know the supported orientations?
[14:45] <greyback> tvoss: if foreground app does not support portrait, shell should not try to change it to landscape
[14:50] <tvoss> greyback, now I'm confused :)
[14:51] <greyback> tvoss: quick hangout?
[14:52] <tvoss> greyback, you are number 4 in a list of 5 right now
[14:52] <tvoss> greyback, let me get back to you
[14:52] <greyback> tvoss: :)
[14:52] <greyback> please hold, your input is important to us
[15:20] <racarr_> we do have surface_attrib_focus
[15:20] <racarr_> set by the shell
[15:20] <racarr_> which wouldnt be so different than orientation
[15:21] <racarr_> kdub_: alan_g: P.s. iterated onc ursor spike phase 4
[15:22] <alan_g> racarr_: I agree that a surface attribute is a natural implementation approach. (But let's check the use cases.)
[15:22] <racarr_> alan_g: Mm.
[15:22] <racarr_> I think today is finally going to be the day that construction drives me insane
[15:22] <alan_g> racarr_: coffee shop?
[15:22] <racarr_> the people who have been working close by are now literally working on my street and they seem to have chosen right outside my window
[15:23] <racarr_> as the nexus of
[15:23] <racarr_> ....trucks
[15:23] <racarr_> yeah I think that might be what I do in 30 min or so...
[15:23] <alan_g> noise cancelling headset?
[15:23] <racarr_> Haha. Only works for low frequency noise
[15:23] <racarr_> which I dont think is the annoying part of jackhammering
[15:24] <alan_g> Mm. Mine copes with the whine of aircraft engines
[15:24] <alan_g> Not tried jackhammers
[15:28] <racarr_> ill just become a master of meditation and cast it from my mind...seems easiest.
[15:29] <racarr_> alan_g: re: enable-usb-touchscreens
[15:30] <racarr_> I put the display_bounds in stub server configuration because stubdisplay isnt
[15:30] <racarr_> a public class
[15:30] <racarr_> and it inherits from NullDisplay
[15:30] <racarr_> which shouldn't have a size.
[15:44] <racarr_> hmm I broke clientsurfaces::are_created_with_correct size when  I changed the default testing disp lay bounds
[15:44] <racarr_> but its not clear to me why this would have ever passed
[15:45] <racarr_> as the default server configuration has mostly ignored clients size requests in favor of fullscreening them
[15:45] <racarr_> for over a year
[15:46] <racarr_> no thats not true
[15:46] <racarr_> nvm it all
[15:46] <racarr_> I just made the screen smaller
[15:46] <racarr_> than this surface lol
[15:46] <racarr_> and I forgot we do listen to requests...just most apps dont make them
[15:46] <racarr_> lala
[15:47]  * alan_g goes to review "ursor spike phase 4" again
[15:48] <racarr_> :) Thanks
[16:53] <alan_g> kdub_: before I EOD - don't forget https://code.launchpad.net/~mir-team/mir/trusted_sessions/+merge/221191
[16:55] <kdub_> alan_g, i switched to abstain, my internet is having problems
[16:55] <kdub_> (hopefully that msg went through)
[16:57] <alan_g> kdub_: Still looks like "Needs Info to me". But I can top approve if you're not going to object.
[16:57] <alan_g> *"Needs Info" to me
[16:58] <kdub_> alan_g, sounds good
[16:59] <alan_g> kdub_: you still have many hours before it lands to find a reason to stop it. ;)
[17:23] <racarr_> Wow I just got some of those shoe gel pad things...
[17:23] <racarr_> game changers.
[17:24] <racarr_> even for sitting down.
[17:24] <racarr_> *back to things*
[18:11] <josharenson> do we use the exact same libegl as android?
[18:17] <racarr_> everything on ubuntu side links against libhybris-egl which "links" against an actual android libegl from cyanogen
[18:17] <josharenson> ack
[18:17] <racarr_> libhybris-common/core/something
[18:17] <racarr_> it has a name and its probably not libhybris-egl lol
[18:18] <racarr_> but
[18:18] <racarr_> thats basically the deal
[18:18] <josharenson> ok, thanks
[18:36] <racarr_> Lunch :)
[18:36] <racarr_> made good progress ona cceptance tests for cursor is a renderable
[18:36] <racarr_> not really clear
[18:36] <racarr_> they are acceptance tests
[18:36] <racarr_> but they are something
[18:38] <racarr_> its acceptance criteria I guess (i.e. there is something that shows up in the renderable list that acts like the cursor)
[18:38] <racarr_> but for driver writers and compositor authors and such
[18:38] <racarr_> not
[18:38] <racarr_> acceptance criteria for clients clearly
[18:39] <racarr_> so it doesnt really excercise the system from the outside totally in the way our acceptance tests would
[18:39] <racarr_> notably there is no client. just a thread that makes expectations and then moves the cursor around
[18:39] <racarr_> *shrug*
[18:39] <racarr_> Lunch