#ubuntu-mir 2013-07-15
<RAOF> Hm. I wonder how hard it would be to get a mir_surface_swap_buffers with a MSC/SBC tag.
<tvoss_> good morning :)
<duflu> tvoss_: Morning
<tvoss_> duflu, hey, happy Monday :)
<duflu> tvoss_: Let's hope so
<dholbach> good morning
<RAOF> thomi: Can we fix unity-system-compositor in the mir-team PPA to not always be a revision behind Mir?
<RAOF> thomi: It looks like the unity-system-compositor source upload happens at about the same time as the Mir upload, which means it's always building against a Mir that's about to become obsolete.
<tvoss_> dholbach, good morning :)
<dholbach> hi tvoss_
<RAOF> Hm. I wonder if I can get hacky composite-bypass in XMir today...
<duflu> RAOF: Today? Isn't it the evening for you?
 * duflu edges closer to insanity
<mlankhorst> morning
<alan_g> greyback: are you still unhappy with lp:~robertcarr/mir/implement-client-credentials? (It has changed a lot.)
<greyback> alan_g: ah we're waiting for my approval too. racarr said he cannot do what I wanted immediately, so for now it will do. I'll approve
<greyback> alan_g: you can top-level approve now. Thanks
<alan_g> greyback: I don't need your approval, but it is polite to ask in case there's an issue
<greyback> alan_g: it is indeed. Thank you :)
<alan_g> greyback: yw
<RAOF> duflu: It is, but it's almost done.
<tvoss_> RAOF, just did an upgrade, all good so far. This is intel switched to the sna accel arch, right?
<duflu> tvoss_:  SNA was turned on since raring. We turned it off in Mir driver builds tho
<mlankhorst> but I fixed sna for intel, dno if raof enabled it yet or not
<mlankhorst> s/intel/mir/
<tvoss_> mlankhorst, I *think* so :)
<tvoss_> mlankhorst, the updated radeon driver should fix two of the critical bugs on mir, right?
<mlankhorst> probably
<mlankhorst> theoretically it should create the surface parameters in the same way as mesa
<mlankhorst> which should satisfy tiling constraints etc
<tvoss_> ack
<duflu> alf_: Turning off MultiAcquisitionBackBufferStrategy in the synchronous case seems to solve all my problems. Now tell me why that's a bad idea... :)
<alf_> duflu: because it's needed to support multiple buffer consumers while minimizing buffer "loss" (a window placed between multiple screens, taking snapshots etc)
<alf_> duflu: however, that's for normal windows, fullscreen bypassed windows probably don't need this
<alf_> duflu: hmm, perhaps they need the snapshot part, but I don't believe it's critical for XMir
<duflu> alf_: I'm tempted to push the logic of MultiAcquisitionBackBufferStrategy into the spin swapper. Just wondering why that's a bad idea...
<duflu> Oh. It's a bad idea because the reference to the buffer I have right now only exists when bypass is turned on
<duflu> :P
<alf_> duflu: how would that help you?
<duflu> alf_: I mean I have to hold the buffer explicitly for DRM from before page flip n till after page flip n+1
<duflu> ... else tearing
<alf_> duflu: can't you do that in the bypass compositing strategy?
<duflu> alf_: Yes, it could be held in the compositor or display buffer. Which one is a minor detail
<alf_> duflu: we are already enforcing a related policy in the existing compositing strategy: we are holding the buffer until after the swapbuffers
<alf_> duflu: (I mean the window buffers)
<duflu> alf_: That's not sufficient for bypass. You have to hold the buffer for _two_ page flips
<alf_> duflu: sure, I just mean that enforcing this in the bypass compositing strategy is a reasonable option, since we are already doing something related in the existing strategy.
<duflu> alf_: There are many such things I need to clean up and find a nicer home for. I will review them all before proposing anything
<alf_> duflu: ok
<duflu> alf_: But before then, I need to solve this deadlock
<duflu> 4 days with no progress is depressing
<duflu> alf_: BTW you would be my best friend if you merged the swapper classes into a single one. It's very overcomplicated spreading a well-known buffer rotation algorithm between 3+ classes
<alf_> duflu: Which classes are you referring to?
<duflu> alf_: SwitchingBundle, BufferSwapper{Multi,Spin}, MultiAcquisitionBackBufferStrategy
<duflu> That's four classes for a relatively simple switchable rotation algorithm
<duflu> I strongly suspect if it was simplified to one then I could get over this issue. But I'm not sure yet so won't jump the gun
<alf_> duflu: The problem with merging into one class is that we will create an overcomplicated class. Each layer is simple/testable enough on its own and builds off the layer below: the BufferSwapperMulti/Spin classes are the core swapping algorithms, the SwitchingBundle allows switching between the swapping algorithms at runtime, the MultiAcquisitionBackBufferStratey allows multiple consumers while minimizing buffer loss. Putting everything in one
<duflu> alf_: I would almost do it myself to prove you wrong. :)
<duflu> It's a simple well-known algorithm used in the industry. There's no need to spread it over so many classes
<duflu> Using a single class would in fact simplify things a lot
<alf_> duflu: it's not spreaded, the core is in BufferSwapperMulti/Spin classes, everything else is extra
<duflu> OK, I'll drop the idea. I can't really prove my point unless I do it, and that would take too much effort right now
<alf_> duflu: in any case, I would be happy to be proven wrong if the result is actually better :)
<duflu> alf_: My first preference is to propose small diffs. So I won't be rewriting it if I can help it
<duflu> alf_: I need to cook dinner. In the mean time, could you please look at MultiAcquisitionBackBufferStrategy and tell me if you think you can imagine a more elegant approach than the "partly_released" flag?
<duflu> I think that might help
<alf_> duflu: what's the problem with that (so it can guide my thoughts)?
<duflu> alf_: The flag is never set... because I always have at least one shared_ptr owning the TemporaryCompositorBuffer
<duflu> ... and because the flag is never set, compositor_release never happens.
<duflu> ... and because compositor_release never happens, the client runs out of buffers (hangs)
<alan_g> tvoss: ping
<kgunn> bregma: just checking in, do you need any help  ?
<bregma> kgunn, armhf build MP is up and ready for review
<kgunn> bregma: \o/ hell yeah!
<bregma> if didrocks could take a look that would be especially useful, I suppose
<didrocks> bregma: I'm more than busy right now, but I'll try having a look today
<hikiko> oups :p i forgot the lunch a few hours... :p
<alan_g> bregma: do you know if the input tests are still hanging on the armhf build? (I tried a fix at -c847 - but as I can't reproduced the failure locally...)
<hikiko> alf_, I saw your branch for android where you separate the display and the display buffer, do you think it's necessary to do the same in the nested mir?
<bregma> alan_g, I have never had the input tests hang on my N7, but I can kick off a test run to check (it'll take 2 hours or so)
<hikiko> because atm I use 1 class that inherits from both the display and the displaybuffer classes
<alan_g> bregma: I have the impression it only happens on the build farm
<alan_g> s/happens/happened/
<alf_> hikiko: yes, you need to do it because the Display and DisplayBuffer interfaces will soon become incompatible
<hikiko> :s
<hikiko> ok
<bregma> alan_g, sounds likely, expecially if it depdends on underlying OS support
<alan_g> hikiko: if you get your code landed first, then it won't be your problem. ;)
<hikiko> I ll get your android changes as a reference then, thanx alf_
<hikiko> what do you mean?
<alan_g> hikiko: if your code is on trunk when alf_  tries to change the interfaces, then he'll have to adapt your code, not you.
<hikiko> hehe :) I am not done yet I need a few more days, so I guess better to separate it now... alf_ has an mp already from what I've seen :)
<kgunn> alan_g: thanks so much for looking at bregma's mp!
<alan_g> kgunn: np
<kgunn> hikiko: alf_ i'll leave it to you guys to coordinate interface changes & landings...but multumonitor takes prioirty, e.g. try not to slow it down
<hikiko> sure kgunn :)
<didrocks> bregma: do you have a handy link?
<bregma> didrocks, https://code.launchpad.net/~bregma/mir/lp-1195265/+merge/174478
<racarr> Morning
<didrocks> bregma: if you: +ifeq ($(DEB_HOST_ARCH),powerpc)
<didrocks> bregma: please reenable arch: any in debian/control
<greyback> racarr: hey, when you've spun up, can we have a quick chat?
<racarr> greyback: Morning! Yeah
<greyback> racarr: cool, let me know when's good for you
<racarr> greyback: Now is good want to start a hangout while I find my phone?
<greyback> racarr: ok, am on it
<kgunn> didrocks: what needs to happen next? shouldn't we be able to enter universe (once bregma's mp is merged)
<didrocks> kgunn: I think we told with olli_ that we're going to use the ppa for some days
<didrocks> and then decide of Thursday
<didrocks> I would hope bregma is just going to fix the small query I have and then approve so that I can try a first daily to the next ppa tomorrow
<kgunn> didrocks: thanks, sounds like a plan....good to be one step closer :)
<didrocks> kgunn: same here :)
<greyback> racarr: oh another thing I need: a good way to know that a surface was destroyed. I tried subclassing SurfaceBuilder - but that gives me a mir::frontend::Surface, which is private member of mir::shell::Surface - so I cannot seek for it in a list of surfaces
<racarr> greyback: ok. it can probably just go on the_session_listener
<greyback> racarr: sounds ok to me
<mterry> kdub, poke about ~mterry/mir/session-for-surface branch, if you wanted to chat about where the need is coming from
<kdub> mterry, sure
<mterry> kdub, so my goal is to allow u-s-c to have the greeter stay on top of other sessions (and be transparent at will to expose the next session)
<mterry> kdub, the plan was for lightdm to name the greeter session in a way that u-s-c can know
<mterry> kdub, then u-s-c would override the surface builder, and any surface that belongs to the greeter session could be marked with a different depth
<mterry> kdub, I'm open to other ways, this was just the way robert ancell recommended
<kdub> mterry, i guess I just see that our surface stack has a weak ability to control what's in it
<kdub> and would guess that expanding that SurfaceStack functionality would be more scalable in the long term
<racarr> mterry: I am working on a solution for that for unity which is better too
<racarr> well
<racarr> maybe it's slightly different
<racarr> I hope to have a good answer for matching the things up soon though  without the session
<racarr> unity 8 also needs surface->session eventually though
<racarr> i.e. you click to raise a surface which application becomes active
<racarr> err
<racarr> surface->session
<kdub> racarr, right... a restructuring of msh:: is needed
<racarr> kdub: Maybe. I was just thinking simple. The surface needs a reference to it's session ;) the msh::Surface at least
<kdub> where does the shell want to access a surface, and then get a session? shouldn't it be accessing the surfaces through the session?
<kdub> rather, what's the case that the shell has a surface without knowing the session?
<racarr> had a mild trip over
<racarr> modem power cord
<racarr> XD
<racarr> um, so like click to focus right
<racarr> youve clicked somewhere, the shell got an event
<mterry> kdub, I seem to have lost connection  :-/
<mterry> not sure what you saw from me, but I last sent " or at least, one way he thought it would be doable"
<racarr> it wants to focus the surface underneath
<racarr> but it needs to know which application is now focused to update the launcher
<kdub> racarr, the shell gets an event from where in the system?
<racarr> say mi::EventFilter::handle_event
<racarr> I mean any number of cases
<racarr> lets go with that one XD
<racarr> or maybe it's not exactly there,
<racarr> maybe there is some new cllback lter like
<racarr> mi::EventFilter::handle_event_before_dispatching_to(Event, Surface)
<racarr> which would be ideal for this kind of thing (now you ust say, raise_surface ,focus surface, whatever)
<racarr> but it doesn't make sense to iterate through all the sessions here
<racarr> but you still need to focus the application someho
<kdub> why wouldn't we have mi::EventFilter::handle_event_before_dispatching_to(Event, Session)
<didrocks> bregma: do you mind sending me a "ack" by email once your branch is merged please? that would win me some time :)
<racarr> kdub: How would you know
<racarr> what session
<bregma> didrocks, sure
<racarr> is targeted
<racarr> sessions don't have
<racarr> geometry
<didrocks> thanks! :)
<racarr> or anything
<racarr> or necessarily a strict depth ordering
<racarr> right I can stack a indow inbetween two other windows
<racarr> of the gimp
<racarr> so to pick the event
<racarr> you hve to iterate by surfaces
<racarr> and then find the session
<racarr> it seems clumsy to find the surface and then search
<racarr> for the session
<kdub> racarr, i don't have the problem-context quite so strongly, but my first vague sense of what's going on is we're trying to work around ms::SurfaceStack's limitations
<racarr> there are a bunch of cases
<racarr> I think
<racarr> that is more what mterry's problem is
<racarr> but I am saying the surface->session assosciation
<racarr> is required anyway
<kdub> a bit tricky to talk about, but
<kdub> if whatever needs that association would talk in terms of sessions, then it wouldn't
<kdub> racarr, i guess I'm just a bit unsure what our data structure surrounding our 'group of surfaces' reflects
<kdub> or rather, what its evolved into
<alan_g> racarr: kdub: I'm about to disappear (EOD), but there is a difference between being able to find the "owning" session for a surface and the surface knowing its owner. Is that where you differ?
<racarr> it could be by assosciation
<racarr> but I don't see why there is a problem with the surace having a reference to the session really
<racarr> it's only a 'circular dependency' in the same way
<racarr> a circularly linked list is
<racarr> XD
<kdub> racarr, i might not have an objection either, its just kinda dawning on me that some of our data structures could be better
<kdub> racarr, like, take msh::ApplicationSession
<kdub> msh::ApplicationSession : public msh::Session
<racarr> Mm
<racarr> that doesn't mean much besides
<racarr> msh::Session : public msh::SessionInterface
<kdub> well, the full chain is msh::ApplicationSession : public msh::Session : public mf::Session
<kdub> so we kinda tie msh::ApplicationSession to frontend concepts
<kdub> when maybe what we want is a session that is more independent of ipc concepts?
<racarr> maybe
<racarr> im actually struggling to figure out
<racarr> why msh::ApplicationSession exists
<kdub> like, a grouping of surfaces by input association, as well as a grouping of surfaces by ipc association
<racarr> hmm
<racarr> surfaces aren't grouped by input necessarily though
<racarr> I mean I think that's what 'Session' is
<racarr> it's the IPC grouping
<racarr> not in particular the IPC grouping, that's just a detail
<racarr> but it's the 'client' grouping
<kdub> well, i think that's where the problem might be though?
<kdub> like, for graphics, obviously, we associate them so the compositor can make sense of them
<kdub> in ms::SurfaceStack
<kdub> and we group the surfaces by IPC connection in msh::Session
<kdub> i'm kinda picking up on another association we want them to have
<kdub> and that we're splicing that association into the already existing associations?
<racarr> I'm not sure.
<kdub> yeah, i guess i'm not sure either
<racarr> there is definitely
<racarr> something different than IPC connection
<racarr> more akin, to client, or owner that is useful
<racarr> for example, how does the shell recognize it's own surfaces to manipulate them
<racarr> how do you tell any two surfaces apart :p
<kdub> right
<kdub> like, msh::Session should keep its IPC based roots, but perhaps the shell wants to keep its own groupings of surfaces
<kdub> and the default grouping is simply the ipc grouping
<racarr> what kind of other groupings?
<kdub> like for instance :) when we were talking about sending events to surfaces and needing to know the ipc session associated with that
<racarr> Isnt that the IPC grouping?
<kdub> i guess i'm unsure
<racarr> I think it is...there probably are other groupings though
<racarr> like it's not clear where we would model workspaces atm
<racarr> stages as well
<kdub> right
<kdub> i mean, i think that once we decouple a surface from the IPC portions, making the shell will be much more pleasant experience :)
<kdub> at least more pleasant than overriding our factories so surface associations can be injected i guess
<racarr> Mm
<racarr> I guess for this particular case, probably the DepthId should be in msh::SurfaceCreationParameters
<racarr> so you don't have to overrie the factory
<racarr> then it's super reasonable to extend the interface
<racarr> msh::PlacementStrategy::Place(Session, SurfaceParameters)
<kdub> ah, ok
<racarr> i.e. the shell places a surfce for a session
<racarr> but I think it will come up again later aha
<kdub> it will, its our central data structure, really
<tvoss> racarr, why would the depthid need to be in the surfacecreationparameters?
<racarr> tvoss: Wellllllllllll
<racarr> it's about where
<racarr> it's assigned and how
<racarr> the shell can match up which surface gets what
<racarr> potentially through associating with the session
<tvoss> racarr, I would expect that it is not exposed to anyone creating a surface, as a lot of information is needed to determine the depth
<racarr> well it would just be part of the surface creation parameters on the server, so its not expoed over IPC
<racarr> but the_shell_placement_strategy
<racarr> has the opportunity to add DepthId
<tvoss> racarr, what is a depthid?
<racarr> tvoss: Actually there isn't a lot of information, DepthId needs a better name ;)
<racarr> haha
<racarr> same line of thought
<racarr> All it means is if there are two u rfaces with DepthID X and Y
<racarr> and X>Y then X is always on top of Y
<racarr> when X=Y they stack in the order they are put in and can be reordered
<tvoss> racarr, why isn't that the absolute depth in z?
<racarr> tvoss: Because it's easier this way
<racarr> the surface gets
<racarr> DepthId{1}
<tvoss> racarr, not sure why? z establishes a total order
<racarr> the shell surface*
<racarr> the application surfaces all get DepthId{0}
<racarr> then you can talk about raising an application to the top
<racarr> or reordering them or whatever
<racarr> without
<racarr> having to worry about the fact that the shell is on top
<tvoss> hmmm, sounds like a slice to me
<racarr> It's more of a primitive form of
<racarr> nested surface stacks or something
<racarr> essentially each DepthId is it's own 'stack'
<tvoss> it's not really nested, it's more like banded
<tvoss> a part of a depth-spectrum
<racarr> "primtiive form" :p
<tvoss> or how about a bucket? we are essentially using it as a rough indicator to discretize the continuous z axis, right?
<racarr> I don't entirely follow ;)
<racarr> I don't know. I don't like thinking in terms of 'Z axis'
<racarr> because it doesn't behave like the 'X and Y axis'
<racarr> but, yes, it's to break that up
<tvoss> well, what you basically say is: you have a bucket of surfaces that belong to the shell
<racarr> but also to provide the shell an API to control such.
<tvoss> sure @control
 * kdub just likes normal z ordering, with the shell having fine grained control over how all the surfaces mix in the SurfaceStack
<tvoss> kdub, +1, what use case does the banding solve racarr?
<racarr> what use case does Z ordering solve?
<racarr> I would say it's the more general API that leaves a lot more room for 'user error'
<racarr> so it needs a motivation
<racarr> rather than the other way around
<tvoss> racarr, but depth is the natural representation and the natural order that we are after here, isn't it?
<racarr> Maybe.
<racarr> I don't know.
<racarr> but then what do we do, the shell assigns each surface a depth ID, or
<tvoss> racarr, do you have any case in mind that is difficult to solve without the notion of buckets?
<racarr> just inr esponse to everything that happens
<kdub> i think once we start evolving SurfaceStack
<racarr> reorders all the surfaces relative
<kdub> we'll see that the depthid goes away
<racarr> I think that's
<racarr> difficult...
<racarr> tvoss: Without the notion of buckets? What do you mean?
<racarr> *shrug* DepthID should probably go away, but I would hope in favor of real hierarchal layers
<tvoss> what use-case would break with depth-ordering only?
<racarr> err, well I think both can support the use cases we need.
<racarr> but I think the code that results in the shell
<racarr> from having the shell mnually specify/manage Z order is painful
<racarr> I mean what does it do? everytime a surface is created or destroyed walks the surface stack and reorders things relatively according to some state and rules (i.e. shell surface goes on top of all the application surfaces, which go on top of the desktop layer, oh but the shell surface goes under the OSK layer...)
<racarr> I think it's more declarative with the DepthId's, or some sort of layer concept
<racarr> even on the desktop, with weird WM stuff like always on top, always on bottom, etc
<racarr> you can represent those as sort of 'statically stacked' layers
<racarr> that applications move between
<racarr> *shrug*
<tvoss> racarr, need to think about it
<racarr> Haha I feel like I am arguing against a proposal but I am not sure what the proposal is or why I am arguing
<racarr> tvoss: Would appreciate thought on it, yes
<racarr> robert_ancell's thought is that the shell should provide like a sort function to the SurfaceStack implementation
<racarr> and just control Z order that way
<racarr> but I guess my intutition is that the implementation of this function becomes messy.
<racarr> Hand wavy, sorry :)
<racarr> I mean, I guess I think
<olli_> :)
<racarr> render(SurfaceStack) should really be a function of State(SurfaceStack)
 * kdub smells tightly coupled notions
<racarr> whereas if you have some surface sorting object
<racarr> its going to need state from all over the system
<tvoss> racarr, well, if you compose the function implementation in a sane way, it should be a good primary interface to provide aa sorting interface
<racarr> I think that sane implementation
<racarr> ends up being a stack
<racarr> of stacks
<tvoss> in that I do agree, you gradually refine your sorting criterion until you end with "pure" depth
<racarr> and the shell creates this object
<racarr> and sends messages to it like filter_object->set_depth_for_shell_surface(above_application_surfaces)
<racarr> so it seems like
<racarr> nice unctionality for the surface stack to provide
<racarr> directly
<racarr> err s/filter/sort
<tvoss> but it would in turn require the surface stack to know a lot about the notion of shell vs. app surfaces
<racarr> well
<racarr> I dunno ;) I don't think it's a lot to know
<racarr> in the phone case, it's enough for some object the shell implements higher up
<tvoss> @phone case: but that's a special case of the general problem, isn't it?
<racarr> to assign DepthId{0} to app surfaces and DepthId{1} to shell surfaces
<racarr> yeah but I think its the same on the desktop it's just
<racarr> more difficult to enumerate, but I mean its like
<racarr> there is a Desktop Layer, an Always on Bottom Application La yer, and Application Layer, etc.
<tvoss> I don't think we should engrave that notion into the SurfaceStack
<racarr> so instead you think there should be some shell component
<racarr> that listens like "new surface created"
<racarr> and searches the surface stack
<racarr> for the right spot to put it in?
<racarr> Or this sort function approach
<racarr> or something else?
<tvoss> racarr, I would think that it might make sense to collect the operations that the stack needs to support fast
<tvoss> racarr, an interesting thought: a surface role could be interpreted as a depth id, too
<racarr> that
<racarr> is kind of a hope :)
<racarr> but I don't think we ever found an exact set of roles that matches up
<racarr> to stacking
<racarr> MPT was trying
<racarr> remember the big picture witht he layer and the drawing of the eye
<tvoss> hmmm, I think our recent addition of an input method role could help there
<tvoss> yup
<racarr> I think one of the counterexamples was or example some input methods are system model and some input method are window/application/entry field modal or whatever
<racarr> I think
<racarr> you can define the stacking like
<racarr> a sorting of roles first
<racarr> i.e. application role is a layer under shell role is a layer under input method etc
<tvoss> well, I would start over with sorting by app instances, where I consider the shell an app instance, too
<racarr> if you also allow each err
<racarr> "band" or whatever
<racarr> to have
<racarr> a modality layer
<racarr> on top of it
<tvoss> hmmm, let's reverse the question: given a surface stack layer, how can we test if the stacking is correct?
<racarr> what do you mean layer here?
<tvoss> remov ethe layer :)
<tvoss> just surface stack
<racarr> ok
<racarr> well. I dunno, I mean,
<racarr> each form factor shell
<racarr> has some set of invariants
<racarr> i.e. dash is above all applications
<racarr> mostly recently used application is above the one before it
<racarr> etc
<tvoss> hmmm, that means that the first order is always "most interesting" in decreasing order, right?
<tvoss> under the assumption that the shell is always most interesting to the user as the primary system interface, and most recently used is equivalent to most interesting application
<racarr> yeah
<racarr> I mean it's a statement about
<racarr> who gets visibility
<racarr> when screen space is contested
<racarr> more than a "Z order"
<tvoss> okay, so assume that we would reorder the list of apps (again, shell included) as opposed to the surfaces, then every surface would receive a base "layer" according to the apps's index in the list, right?
<tvoss> per stack it's a per role ordering then
<tvoss> but again a most interesting order, too
<tvoss> so yeah, I do agree that the absolute z order that is finally calculated is only a result of all of these steps
<racarr> I'm not sure it's ok to
<racarr> assume apps, stck together
<tvoss> with the constraint of minimally intrusive z position changes
<racarr> i.e. I would expect to be able to stack a window from another app
<racarr> between my 3 gimp windows
<tvoss> s/stack/bucket/band
<tvoss> for that,we need the constraint of minimal z order changes
<tvoss> or better z coordinate changes
<tvoss> you only really change z in the end if you detect a conflict between the semantics and the actual position
<racarr> right
<tvoss> that's why I think that defining the verification algorithm should solve most of the problem already
<racarr> I dunno
<racarr> that doesn't clarify it for me
<racarr> I mean, one option from that perspective
<racarr> is to provide an API the shell implements
<racarr> bool obscures(Surface1, Surface2)
<racarr> which is just the verification algorithm
<racarr> and you call it
<racarr> N^2 times
<racarr> but it's pretty clear that's not correct
<tvoss> it might be correct but inefficient
<racarr> sure
<racarr> by correct I mean, the correct code to put in a header file that gives us the best probability of a bug free performant shipping shell
<tvoss> hah, I think we want a stable sort
<tvoss> as the stack is always partially sorted
<racarr> I think the thing with the sort plugin approach
<tvoss> by definition
<racarr> is...well..
<racarr> the first part is my opinion
<racarr> that I don't think you want to recompute the sort each time you query the order
<racarr> and then given that, you go on to cache is in this object, etc
<racarr> but now to keep your cache valid
<racarr> this object has to listen to signals from the rest of the system
<racarr> i.e. surface destroyed, surface created, etc
<tvoss> you only want to resort if something changes ...
<racarr> so it's an object that gets messages like
<racarr> surface destroyed, surface created
<racarr> and maintains the orders the surfaces stack in
<tvoss> yup
<racarr> so why isn't it ust the
<racarr> surface stack
<racarr> because it has the same interface
<tvoss> okay, bed time :)
<tvoss> I'll keep it spinning
<racarr> haha no fair
<racarr> ok sleep well!
<racarr> see you
<racarr> lunch for me
<thomi> morning
<racarr> Morning!
<olli_> kgunn, are Chris' bug part of that list
<kgunn> olli_: yes
<kgunn> olli_: well...may i clarify what you mean ?
<kgunn> olli_: e.g. radeon pixelated rendering...yes
<kgunn> it is part of the list
<olli_> the ones he is tagging
<olli_> iow are there bugs yet from him?
<olli_> robert_ancell, RAOF, kgunn if someone wanted to get a better understanding of the xmir-x-drivers, who should be on the call?
<olli_> RAOF?
<olli_> anybody else?
<robert_ancell> olli_, RAOF is the expert, he might know if the other X devs in Canonical might know too
<kgunn> olli_: i think RAOF primarily...shared the same with hlh
<olli_> robert_ancell, thx
<kgunn> olli_: robert_ancell maybe mlankhorst ?
<olli_> kgunn, like it when you are ahead of me ;)
<robert_ancell> kgunn, yes, I was thinking so too, but I don't know how much he knows
<kgunn> olli_: wrt ChrisG's "bugs"...so far, there has been a bug present, i haven't heard of any complaints from him that didn't already have a bug...but i will circle back for an inquisition
<olli_> kgunn, are the existing ones tagged
 * olli_ wants to look at a list and see it turn "fix released" 
<olli_> robert_ancell, I suggested a meeting to include RAOF
<olli_> in a compatible tz
<olli_> well, at a NZ tz compatible time
<olli_> robert_ancell, kgunn, jfyi... our window in the cert lab closes on ~Thu this week
<kgunn> olli_: wrt bugs that are actually being fixed....yes, there might be some cleanup to be done
<robert_ancell> olli_, ack
<olli_> and /me is very eager to get results and I think you should be too :)
<olli_> kgunn, I think any bug that hits Chris should be tagged
<olli_> not sure how to parse your last statement
<olli_> :)
<kgunn> olli_: i am sure its me :)...when you say "tagged" how ? what specifically do you mean ?
<olli_> kgunn, in LP you can add an arbitrary string to a bug
<olli_> i.e. what didrocks did for distro release
<olli_> I think we should have a similar tag for bugs that bother chris
<olli_> so we can make sure (via a simple query on that tag) that he is not blocked
<olli_> otherwise I see a team sprint in LEX for everybody on the horizon - as we all want these numbers ;)
<olli_> don't we?
 * robotfuel waves at olli_
<olli_> ah
<kgunn> olli_: got it
<olli_>  /nick robotfuel reboot_robot
<olli_> scnr
<robotfuel> olli_: kgunn here is the first bug, https://bugs.launchpad.net/xmir/+bug/1201565 I used needed-for-lab because launchpad didn't accept it with underscores.
<ubot5> Ubuntu bug 1201565 in XMir "unity doesn't run in xmir session " [Undecided,New]
<kgunn> robotfuel: would it be possible to run the same machine / config in bug#1201565 just with the modification of commented out #type=unity in the /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf file
<robotfuel> kgunn: yes
<kgunn> robotfuel: thanks....assuming this might be the kind of thing the team would do when they get access
<robert_ancell> RAOF, Can you look at the comment I made on the X log in https://bugs.launchpad.net/xmir/+bug/1201565 and see if that indicates a problem?
<ubot5> Ubuntu bug 1201565 in XMir "unity doesn't run in xmir session " [Undecided,Incomplete]
<robert_ancell> actually, I'll just assign it to you - it's got to be either X or Unity failing
<robert_ancell> racarr, did you see the build failure in https://code.launchpad.net/~robertcarr/mir/notify-surface-destruction/+merge/174834? Missing a file?
<racarr> robert_ancell: ;) man I even remember hte exact details of creating that file and not doing M-x vc-register...
<racarr> thanks haha
<racarr> pushed a rev
<robert_ancell> racarr, also, https://code.launchpad.net/~robertcarr/mir/simplify-depth-assignment/+merge/174872 has a merge conflict
<racarr> robert_ancell: Just pushed the merge :)
<kdub> RAOF, if we update the mir_client_library.h, that breaks xmir, right?
<kdub> racarr, would you object to moving the client side event handler thread to the connection?
<kdub> racarr, nevermind :)
<olli_> hey guys
<olli_> have you heard of Chromiums project Ozone?
<olli_> https://plus.google.com/100132233764003563318/posts
<olli_> puts Mir right next to Wayland as "alternative window system"
<olli_> good job everybody :)
<olli_> kgunn, ^
<kdub> olli_, yay
<RAOF> kdub: If you touch things in mir_client_library.h that xmir uses, yes.
<kdub> RAOF, so it would probably be better if all the  client-api-facing changes for multimonitor configuration land at once...
<kdub> just to minimize the amount of disruption
<RAOF> kdub: As long as you're only *adding* ABI it's fine.
<kdub> right... ~kdub/mir/display-grouping is a change, but after that, it should be just adding ABI
<kdub> specifically, a change to the display info direct-query function
<kdub> robert_ancell, that MP changes the protobuf protocol too, I guess that verison number should be bumped too
<robert_ancell> kdub, just commenting on that
<kdub> i guess i'll bump the soversion
<robert_ancell> kdub, those protobuf changes mean an old libmirclient would break against the new libmirserver
<kdub> yes
<RAOF> Do we have any way of checking that?
<RAOF> I mean, at the moment it's still (just!) reasonable to abort with an error message.
<RAOF> On a similar note, do we have any infrastructure for extensions?
<robert_ancell> RAOF, checking protobuf changes?
<robert_ancell> RAOF, no to extensions
<robert_ancell> (in that we have no infrastructure)
<RAOF> robert_ancell: Either checking protobuf changes or checking the protocol version the client expects.
<RAOF> Hrmph. Unity-system-compositor will want a (temporary) API for setting the position of the hw cursor.
<robert_ancell> RAOF, if we use protocol buffers correctly we shouldn't need that, though it would be nice so we can log it. We don't check backwards compatibility because we only have the latest version of the lib on trunk
<robert_ancell> RAOF, racarr just landed a patch for cursor support in u-s-c
#ubuntu-mir 2013-07-16
<robert_ancell> RAOF, are you adding that .symbols file to libmirclient? If too busy, I can do it
<RAOF> robert_ancell: Yeah, I am in the background.
<RAOF> Turns out that it's a little bit more complicated, because we accidentally export about 100KB worth of C++ symbols too.
<robert_ancell> RAOF, time for symbol filter..
<RAOF> Time for -fvisibility=hidden.
<RAOF> It should also significantly reduce our startup time.
<robert_ancell> nice
<robert_ancell> RAOF, in the background?
<RAOF> It builds while I do other things :)
<robert_ancell> k
<duflu> RAOF: That's the fun part about C++ symbols. Often their name lengths far exceed their code size :)
<duflu> Is 60 degrees at idle good? :P
<robert_ancell> RAOF, those SNA changes you made - are they on https://github.com/RAOF/xserver?
<RAOF> robert_ancell: No, they're on lp:~raof/mir/xf86-video-intel-vladmir
<robert_ancell> RAOF, aha
<RAOF> Because Intel is too cool to use an acceleration architecture that lives in the xserver tree :)
<robert_ancell> RAOF, that branch doesn't seem to exist
<robert_ancell> is it private?
<RAOF> Shouldn't be?
<RAOF> Ah, sorry.
<robert_ancell> oh ~mir-team?
<RAOF> lp:~mir-team/mir/xf86-video-intel-vladmir
<robert_ancell> I just read our own documentation :)
<RAOF> :P
<robert_ancell> RAOF, btw, is there a reason why it isn't lp:~mir-team/xserver-xorg-video-intel/vladmir?
<RAOF> Not really. Does that project exist, though?+
<robert_ancell> RAOF, yes
<robert_ancell> and lp:~mir-team/nouveau/vladmir
<RAOF> Then the answer is probably âbecause at one point that branch was privateâ
<robert_ancell> I thought so
<robert_ancell> and lp:~mir-team/xserver-xorg-driver-ati/vladmir
<robert_ancell> for bonus inconsistency in source package naming
<robert_ancell> upstream naming rather
<RAOF> Well, none of those projects have the actual upstream name :)
<RAOF> Upstream they're xf86-video-{ati,intel,nouveau}
<robert_ancell> RAOF, yeah, sad eh?
<RAOF> Would you prefer it if the canonical repositories were under the various projects?
<robert_ancell> RAOF, well, look. You registered nouveau :)
<RAOF> I can't remember why :)
<robert_ancell> RAOF, it confuses me slightly, but it doesn't really matter
<duflu> Am I imagining things, but did saucy's power usage drop significantly when it moved to 3.10?
<duflu> -but +or
<duflu> Oh, that actually wasn't recent
<tvoss> RAOF, ping
<RAOF> tvoss: Pong
 * duflu does the no-more-deadlocks dance
 * RAOF goes to get milk
<hikiko> hi :)
<hikiko> question: I wonder how could I check in which platform mir runs (to see for example which type of buffers I will need) without using ifdef
<duflu> hikiko: Not sure. But I have been wondering much the same. I would say it should be a function of the platform to produce (factory) its own buffers. This would eventually be owned by a "graphics driver" which would take over platform roles
<dholbach> good morning
<duflu> Morning dholbach
<hikiko> duflu, you mean a factory in each native platform isn't it? and the nested one will just use it?
<hikiko> I mean: buffer interface that is implemented by android and gbm separately
<duflu> hikiko: I think I mean the "platform" should be a portable interface to operate on the interfaces to platform-specific objects, like buffers
<duflu> Yes
<duflu> But that's just what I think. Not necessarily how it works now
<hikiko> :) it doesn't sound a bad idea :)
<hikiko> I'll try it!
<RAOF> hikiko: There's also mir_surface_get_platform_type
<hikiko> yes
<hikiko> but to use this
<hikiko> I need to have a client platform isn't it?
<alf_> hikiko: I guess the first question is why do you need to explicitly know on which platform you on.
<dholbach> hi duflu
<hikiko> +i saw at tests/unit-tests/client/test_client_platform.cpp that we use ifdef to call it
<hikiko> alf_, yes I do because I will use native buffers
<duflu> alf_: That's my point. There should be a (portable) interface always available to give you what you want. If not already at lower-level classes then at least implemented per platform
<alf_> hikiko: where/how are you going to use native buffers?
<alf_> hikiko: (I am trying to understand your scenario better)
<hikiko> hmm... I needed gbm in my last branch because nested mir was a different platform
<hikiko> but I see what you mean
<hikiko> maybe this time (runtime) I won't need to do anything
<hikiko> since I will create both a native platform (- initializes gbm, drm creates devices etc) and the nested one
<hikiko> ok, I ll check if I need it first :>
<hikiko> (thanks all)
<RAOF> New laptop should be shipping soon... shipping sooooooon!
<tvoss> RAOF, \o/
<mlankhorst> or will it?! dun dun duun
<tvoss> RAOF, disabling semaphores seems to work
<RAOF> Yay for year-old i915 bugs!
<tvoss> RAOF, but it means a degradation in terms of throughput and morre cpu load
<RAOF> Man, why don't we just default to clang everywhere?
<mlankhorst> because clang doesn't compile a linux kernel
<alf_> alan_g: The scenegraph is probably the proper way to handle a lot surface properties. However, unless we make it a priority, we will just continue to scatter more surface bits and pieces around the code base... Not sure how it ties with our current xmir and mobile priorities.
<alan_g> alf_: I was just discussing that with tvoss
<tvoss> alf_, alan_g seems like we should have a discussion about that topic with the team
<alan_g> alf_: tvoss: quick hangout to discuss how we schedule this discussion?
<tvoss> alan_g, on another call right now
<alan_g> np later today?
<tvoss> alan_g, sure
<duflu> I would have imagined only the shell would have a scene graph. I don't understand why you would have one accessible inside libmirserver... ?
<RAOF> We need something approximating a scenegraph to actually draw, though.
<duflu> Yes, but what gets drawn in what order is all up to the shell. I guess the server code hasn't quite reached that level of clarity yet
<duflu> ... so some of it is scattered around the server
<tvoss> duflu, largely due to us not having a scenegraph in place
<duflu> tvoss: Yes, I guess. Just saying it should eventually live in the shell only. Not Mir
<tvoss> duflu, but Mir at least needs to know how to talk to it, with the shell being able to inject the actual implementation
<duflu> tvoss: Most of it... no. If we aspire to the shell "being" the compositor, then any properties that affect composition would be stored in the shell's scene graph
<alan_g> Mir needs to be able to query the scenegraph without trips into javascript
<duflu> What? Javascript? Where?
<tvoss> duflu, the shell
<tvoss> duflu, is written in QML
<duflu> Oh. Right. That's sillyness on behalf of the shell
<duflu> Hmm
<tvoss> duflu, at a future point we want the shell to do the actual compositing
<tvoss> duflu, however, right now, that's not the case and we need to make that we do not scatter functionality across the system that would better fit into a consistent scenegraph model
<tvoss> if that moves to the shell over time, awesome
<tvoss> duflu, not entirely sure why you think that doing the shell is in qml, though
<duflu> tvoss: At least part of the Unity8 shell is C++ already though. We don't have to wait for the distant future to put shell things in the shell
<tvoss> duflu, fair, but I'm not confident that we have the resources available right now to implement the actual compositing in the unity-mir glue layer
<tvoss> duflu, from my pov, having a concept of a scenegraph hammered down helps us in the short and in the long term
<duflu> tvoss: Is it just like shell-specific surface properties we need storage for?
<tvoss> duflu, nope, it's really a bigger problem we need to solve as the current (very naive) surface stack is not capable of holding the information and providing the operations we really want
<duflu> tvoss: That's my concern. The assumption that the scene graph is a stack is a very bad assumption. That's an implementation detail that is shell-specific
<duflu> I fear hard-coding more inflexible assumptions into the server
<tvoss> duflu, a stack is only the final view assembled from the scenegraph, in that I do agree
<alan_g> duflu: that's the problem we're trying to solve
<duflu> tvoss, alan_g: Alright. I guess part of the generalization will involve rejigging the "stack" as used in input too
<tvoss> duflu, yup
<duflu> Since it's not always a stack
<alan_g> ack
<duflu> Unfortunately a few of us did point this out before that code landed
<duflu> But at least we have something working I guess
<tvoss> duflu, and I think there were compelling reasons to land it nevertheless, iirc for bootstrapping purposes
<duflu> Yep
<duflu> I think I just talked myself into having a general scene graph interface in the server
<duflu> Good idea
<alan_g> We already discussed that we'd be here, doing this, in Oakland - it isn't a surprise
<RAOF> Ok. Let's see if swapbuffers+bypass works...
<duflu> RAOF: I hope you're not talking about my branch. Still working on it
<duflu> Though I did get over the deadlock today... and now find a theoretical reason why it should not work as well as it is...
<RAOF> No, I'm talking about the XMir side - having SwapBuffers actually wait to swap the buffers, and handing out the Mir buffer to fullscreen GLX clients.
<duflu> RAOF: Oh, so XMir is now a regular client?
<RAOF> No?
<RAOF> Well, yes, but it doesn't use EGL.
<duflu> RAOF: Nevermind. Resolving the confusion I have right now is not required. Happy hacking
<RAOF> Eh, it's building.
<RAOF> I've got time to resolve confusion if you like :)
<didrocks> RAOF: still around? do you mind listing me the binary packages I should install from xmir and mesa?
<RAOF> didrocks: Sure, after I have collected pizza!
<didrocks> :)
<didrocks> thanks!
 * tvoss does not like gmail telling me that I have 666 unread mails
<alf_> tvoss: it would be even more interesting/disturbing if it automatically redirected you to https://www.youtube.com/watch?v=jsmcDLDw9iw :)
<duflu> alf_: And even more so for https://www.youtube.com/watch?v=2EdWwEMSyuY
<alf_> duflu: :)
<RAOF> didrocks:
<didrocks> RAOF: wrong copy/paste? :p
<RAOF> didrocks: Yo! Do you need all the binaries, or can I assume the apt resolver is in effect?
<didrocks> RAOF: no, it's whitelisting, so we need all the binary packages we need to install
<didrocks> RAOF: to prevent uncontrolled transitions :)
<RAOF> Ok.
<RAOF> So what we want is the list of all the binary packages built by the relevant source packages, right?
<RAOF> didrocks: That's a *big* list.
<didrocks> RAOF: all the binary packages from xmir and mesa that we need to install by default, yep :)
<RAOF> Ah, just the ones that need to be installed by default?
<didrocks> RAOF: right, the one we need and are tested :)
<didrocks> as we are running the unity tests, I think all xmir/mesa is involved at some point (with the patches for xmir/mir)
<didrocks> RAOF: my list right now is: unity-system-compositor libmirprotobuf0 libmirserver0 libmirclient1 lightdm liblightdm-gobject-1-0 unity-greeter
<RAOF> libegl1-mesa
<didrocks> this is quite short for a long list :p
<RAOF> libegl1-mesa-drivers libgbm1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libgles2-mesa xserver-common xserver-xorg-core
<RAOF> xserver-xorg-video-ati xserver-xorg-video-radeon xserver-xorg-video-intel xserver-xorg-video-nouveau
<didrocks> RAOF: sounds like reasonable, adding them!
<didrocks> RAOF: thanks! will try that soon :)
 * RAOF is confused. How does xf86-video-intel load, when it *should* be trying to resolve symbols that don't exist in xmir?
<alan_g> RAOF: they're marked "load on use?"
<RAOF> They *should* be used.
 * alan_g gives up - ask the link loader where it resolves them
<RAOF> LD_DEBUG= to the rescue!
 * alan_g finds his brain can't focus on any more MP reviews
<didrocks> RAOF: seems you forgot libegl1-mesa :) I'm adding it
<alf_> alan_g|lunch: what do you think about ViewableArea::view_area() -> DisplayGeometry::geometry() or DisplayLayout::layout()
<alf_> alan_g|lunch: that is "geom::Rectangles DisplayGeometry::geometry()"
<alan_g> alf_: I don't think "geometry()" tells anyone what it does
<alf_> alan_g: get() ?
<alf_> alan_g: get_current_geometry()?
<alan_g> visible_region()
<alf_> alan_g: or are you referring to the term geometry itself?
<alan_g> I think the word is too generic
<alan_g> layout() is a bit better, but to me would imply that it includes information about which outputs are where
<kgunn> alan_g: alf_ ...just my 2 cents +1 on visible_region vs geom....or you could even say region_to_be_displayed
<alf_> alan_g: kgunn: I think we need to take a step back with this + "tell don't ask"... I am looking at the code that uses ViewableArea and I think the interface we need is actually something like DisplayRegionBoundaries::place_point(p) and ::place_rect(r), i.e. find the closest position of point or rect so that they are within Display boundaries
<alan_g> alf_: I was wondering about that approach
<alf_> alan_g: SessionMediator is one exception to this, but it needs DisplayConfiguration (not just a collection of rectangles) anyway
<alf_> alan_g: so it doesn't really count, the other is the ability to make something fullscreen, like msh::ConsumingPlacementStrategy does, but we can "tell" our object to do that too
<alf_> alan_g: however, I don't know if there are future needs that will make the whole approach too restrictive and we would be better off just giving out all the information anyway...
<alan_g> alf_: IME giving out all the information introduces unnecessary coupling
<alan_g> Can we make something line void DisplayGeometry::change_to_fullscreen(blah&) work now?
<alf_> alan_g: (assuming blah==Rectangle) yes
<alan_g> alf_: I didn't know it would be SomeSurfaceInfoHolder ;)
<alan_g> *if it
<alf_> alan_g: I will go with this approach, i.e., DisplayBoundaries::bound_point() ::bound_rect() ::make_fullscreen() (and perhaps also ::fit_rect() which resizes the rectangle to fit instead of moving it to be within bounds, but I will check what the current consumers need)
<alf_> alan_g: (names are tentative, I am open to suggestions)
<alan_g> alf_: is "bound" a term of art here? "To bound" can be "to bounce"
<alan_g> restrict_point(Point&) et alia?
<alf_> alan_g: I used it as: verb (used with object)
<alf_> 5.
<alf_> to limit by or as if by bounds; keep within limits or confines.
<alan_g> confine_point() sounds good
<alf_> alan_g: agreed
<alan_g> fit_rect() => clip(Rectangle&)?
<alf_> alan_g: Yes, much better!
<alf_> alan_g: The other point is that it seems fitting to have a mi::InputBoundaries and a msh::SurfaceBoundaries interface, implemented by an mg::DisplayBoundaries concrete class
<alan_g> alf_: is there an OutputBoundaries lurking sonewhere?
<alf_> alan_g: (assuming OutputBoundaries is for a single screen/output), conceptually it could be there, but I don't see a consumer for it at this point. It's the same as the DisplayBuffer/ViewableArea case we discussed last week.
<alan_g> alf_: ack - it just seemed symmetric
<olli_> tvoss, robotfuel has some results to look at, have a min to spare
 * alf_ really needs to create a vim snippet/template for an abstract base class
<tvoss> olli_, sure
 * alf_ decides that there is no better time than right now to do it...
<mhall119> kgunn: can you clear something up for me?  Does XMir require xorg drivers for the hardware it'll run on, or does it only need Mir drivers for the hardware it will run on?
<kgunn> mhall119: yes :)
<kgunn> remember xmir is still the x stack....with x apps rendering into backbuffers....then the sys-compositor takes those as inputs rendered out into the frontbuffer
<mhall119> kgunn: "yes" doesn't work for an "A or B?" question :P
<mhall119> kgunn: right, but if I'm running XMir on, say, a Tegra shipset, does it need Tegra XOrg drivers, or just a Tegra Mir system-compositor driver?
<tvoss> mhall119, right now it still needs Xorg drivers
<mhall119> ok
<kgunn> mhall119: tegra ?
<mhall119> nVidia's mobile SoC
<kgunn> right
<kgunn> just questioning whether or not there are xorg drivers for that
<kgunn> might be android drivers
<kgunn> :)
<mhall119> there are android drivers, yes
<mhall119> so if there are Android drivers, but not Xorg drivers, then we can't run XMir on it?
<kgunn> mhall119: right...
<mhall119> why is that?  I thought XMir would abstract the specific hardware from Xorg
<kgunn> that was what i was getting at questioning your mix of tegra w x
<racarr> Morning
<mhall119> kgunn: I'm discussing XMir with someone on G+, just want to have my facts straight
<racarr> greyback: Was reading your email at the coffee shop ,didn't entirely process yet
<racarr> but maybe this is the case for the
<racarr> EventFilter
<racarr> ?
<kgunn> mhall119: well...think of it this way....xmir/u-s-c is sort of rerouting what the x stack thinks is going into a fb....into a input buffer of the compositor
<kgunn> the x stack itself is still using gl drivers for the app renderings
<greyback> racarr: could be. I'd like some guidance please
<kgunn> mhall119: ....to answer your question tho, xmir & android are mutually exclusive topics
<racarr> greyback: Thats my theory let me catch up on email and give it a solid read
<racarr> if you install an event_filter via server configuration
<racarr> it gets all events, and ut returns true/false from a callback
<racarr> to handle
<mhall119> kgunn: hmmm, so apps get a buffer from XMir, but then use the hardware-specific Xorg driver to draw into that buffer?
<kgunn> mhall119: yes
<mhall119> ok, I think I understand now
<greyback> racarr: okay. And I can direct all those events to a surface of my choice?
<mhall119> kgunn: so XMir doesn't provide the GL drawing methods in a hardware-abstracted way?
<kgunn> mhall119: well...i guess that is where i get nit-picky
<kgunn> the drawing methods are provided by opengles
<racarr> greyback: No hmm, this is just like you can consume them
<kgunn> drivers are specific against the soc (cpu & gpu)
<racarr> or let them go to first surface
<racarr> they would have otherwise gotten to
<racarr> I can add some sort of targetting filter
<racarr> there are some hooks in android
<greyback> racarr: you see what I need though? Do let me know what I need to do.
<kgunn> mhall119: make sense ?
<racarr> greyback: I don't yet but I'm sure I will by 830 XD
<greyback> racarr: no prob. Thanks!
<mhall119> kgunn: not entirely, but that's probably my fault :)
<kgunn> mhall119: no, keep poking until we get there
<mhall119> kgunn: so is XMir a non-hardware-specific-hardware-driver like vesa, or is it just a frame-buffer-provider that still need an accompanying hardware-specific-harware-driver?
<mhall119> pardon the gratuitous use of hyphens
<kgunn> mhall119: :)
<racarr> mhall119: As I understand it it' a new 'DIX' i.e. Device Independent X, plu changes to the hardware specific drivers (very small basically just replacing one buffer allocation function)
<kgunn> mhall119: right ^
<kgunn> mhall119: one thing i might have left out...compiz is still there
<kgunn> so you are still fully composing all the windows in x....so when it hits the u-s-c, its just 1 frame
<racarr> duflu: smspillaz: compiz4ever
<racarr> greyback: I'm awake now XD
<mhall119> so my current stack is Intel GPU -> intel Xorg driver -> Xorg Xserver
<kgunn> ...when i say 1 frame, i mean 1 composed view...
<mhall119> if I start using XMir, where will it fit into that stack?
<racarr> greyback: I think, conceptually the EventFilter is what we want
<racarr> greyback: The only difficulty with the EventFilter is getting the events in to Qt...
<tvoss> mhall119, xorg == xmir -> usc
<kgunn> mhall119: i think maybe the bit that escapes a lot of people....even tho you say "gpu/xorg driver"....
<kgunn> there are multiple clients here
<kgunn> the app (maybe), compiz & usc/mir
<racarr> greyback: Basically I see two approaches but don't understand how to fit them both with Qt, so you should help :) um
<mhall119> tvoss: not sure what you meant by that
<racarr> ok so possibility 1 is you install an mi::EventFilter.
<racarr> it always gets all events, so you recognize the gestures there, and just chop out the events you want
<kgunn> mhall119: xmir is xorg with a patch on top
<racarr> this can be extended over time, to support reinjecting/targeting events etc
<kgunn> that racarr described in scrollback
<racarr> though I'm not sure anything is needed for the simpel gestures (only foro ptimization later like the cancellation stuff)
<mhall119> kgunn: ok, so it's not just a driver for Xorg, it's a whole modified server?
<racarr> can also be easily extended with like:
<tvoss> mhall119, for the 13.10 stack it is the following flow of rendering: x app -> xorg(which is xmir) -> usc (which is a minimal shell on top of Mir) -> screen
<racarr> filter_event_beore_dispatching_to(target, event)
<kgunn> mhall119: sort of....(you make it sound ominous, when its not :)
<kgunn> mhall119: so yeah...
<racarr> greyback: The problem here, is Event is a MirEvent passed
<tvoss> mhall119, it's a minimally patched Xserver exposing hooks to the x drivers to be able to render to Mir buffers
<racarr> to this callback
<racarr> on the C++ side
<racarr> and I am not sure what you can do with that
<racarr> maybe you can use some QPA functions
<racarr> to inject it somewhere
<kgunn> mhall119: what tvoss said....which is what i meant by "rerouting" x compiz output to mir input buffers instead of the fb
<kgunn> plubming
<mhall119> ok, so we modify each of the Xorg drivers too, I didn't realize that
<tvoss> mhall119, the links to the modified drivers are here: http://unity.ubuntu.com/mir/building_source_for_pc.html
<mhall119> thanks, I think that was the part I was missing
<racarr> greyback: The other bit is we cn add support for creating windows with 'monitor' channels
<racarr> so you can create an invisible window that always gets all events
<racarr> and get things in to Qt that way
<racarr> kind o ugly but works I uppose
<racarr> and how the input setup works on SF afaict
<tvoss> racarr, I would vote against having this input trap setup
<racarr> tvoss: Me too XD
<racarr> the event filter way, or some variant down that lines is the only scalable way
<racarr> as opposed to using the
<racarr> client input delivery mechanism
<racarr> because eventually to do better/fater gesture recognition
<racarr> the shell might want to replay events, or do that event cancellation stuff we talked about, etc.
<kdub> alan_g, updated surface-owns-render-info to separate size_and_position()
 * alan_g finds his brain can't focus on any more MP reviews
<kdub> ok :)
<kdub> i guess technically its able to be top-approved, anyone else want to take a look?
<racarr> alan_g: alf_: Want to avoid another day of iteration, but having a little trouble with client-focus-notifications
<racarr> What is reasonable behavior for ~Clog?
<racarr> unclog shouldn't throw? or ~Clog should...catch it and abort?
<alan_g> assert on failure
<racarr> should ust clog/unclog assert
<racarr> directly?
<racarr> first thought was just have the dtors assert
<alan_g> racarr: It is a precondition failure to unclog when not clogged so asserting seems right to me
<racarr> ok
<racarr> I am never really sure when to assert ;)
<racarr> my style used to be to assert everything I thought was assertable
<racarr> but that tends to lead to trouble so now I never use it
<alf_> alan_g: racarr: We had some dicussion before, but I don't remember if we reached a conclusion about using C assert() (=assert_if_not_ndebug()) vs a new assert (=always assert) function. Does anyone remember?
<alan_g> <cassert> style assert is fine for a precondition failure - as detecting the problem isn't a post-condition
<racarr> Speaking of assert...
<racarr> has anyone ever looked in to the problem of
<racarr> restarting mir without killing clients?
<alan_g> Not to my knowledge
<racarr> Lets do that and then assert everything ;)
<racarr> hmm. I wonder how large of a chunk of work that would be/if its interesting now
<racarr> alf_: Hey. I am thinking of tackling
<racarr> ...omg copy paste doesn't work anymore
<racarr> https://bugs.launchpad.net/mir/+bug/1193222
<ubot5> Launchpad bug 1193222 in XMir "Screen never sleeps; missing power management" [Critical,Triaged]
<racarr> and just wanted to make sure you hadn't started on the assosciated GBM platform changes or
<racarr> well see if you had any thoughts :)
<kdub> racarr, wasn't there some plan for power management external to mir or something?
<racarr> kdub: Well, yes this is interesting :p on converged/the phone
<racarr> the pln is just mir needs to expose methods out of the graphics platform
<racarr> and unity provides
<racarr> some DBus API
<racarr> or some such
<racarr> but...xmir needs to be able to request display on/off
<kdub> but i'd imagine it would make that request to different places
<racarr> and well...I dunno if we want to hook xmir up to USC via DBus...so it seems to make more sense to have it in the client API
<racarr> what do you mean?
<kdub> specifically, pause mir
<kdub> turn screen brightness off somewhere else
<kdub> or at least I thought that was the plan :)
<racarr> there is more
<racarr> than screen brightness
<racarr> there is backlight control
<kdub> sure
<racarr> but then also setting the zero mode
<racarr> on the CRTC
<racarr> 'turns it off'
<racarr> that is the pause mir step I guess
<kdub> right, i was being vague :)
<racarr> because if there is no CRTC everything grinds to a halt until pages start flipping again
<racarr> mm
<racarr> I do nt think everything actually grinds to a halt now
<kdub> racarr, swapinterval 0 clients would keep going
<racarr> but it will ;)
<racarr> yeah
<kdub> i get confused when new feature requests are made via bugs :-/
<racarr> "Screen fails to sleep"
<racarr> is a bug version XD
<racarr> I wonder if xmir clients are
<racarr> prepared for the aggressive kind of
<racarr> power management we want to do
<kdub> "mir won't fit on a 3.5 floppy"
<racarr> i.e. I am using my X11 music player, the screensaver comes on, display goes off, we pause mir
<racarr> is my
<racarr> silly ingle threaded X11 music player going to
<racarr> start blocking?
<racarr> on some X calls
<racarr> and will it still keep playing music if so
<kdub> racarr, i'd guess that that's parallelized in X clients too
<racarr> my...
<racarr> thought is that it isnt :p
<racarr> but I am not sure if pausing mir actually makes anything block for X clients
<kdub> yeah, thikning back to past experiences...
 * kdub doesn't know
<racarr> I'm almost certain most GTK apps wouldn't respond well
<racarr> to some X/GL calls just blocking forever
<racarr> *shrugs*
<racarr> *adds to list of things to harass RAOF about*
<racarr> Lunch
<racrr> RAOF: Ping?
<tvoss|dinner> racrr, you are missing an a
<racarr> tvoss|dinner: I tried to fit that statement to about 10 scenarios
<racarr> before realizing what you meant XD
<tvoss|dinner> ;)
<Wellark> hi guys! will XMir work on VirtualBox?
<Wellark> as accelerated, not sw rendering.
<racarr> Wellark: This isn't a support channel. Go away!
<racarr> :p jk hi antti
<racarr> Wellark: I don't understand the entire virtual box stack
<racarr> but I think not yet
<Wellark> racarr: well the thing is
<racarr> They expose DRM (i.e. KMS)
<racarr> I'm not sure if they expose GBM though, and at the least some small modifications will be needed to the X driver
<Wellark> that virtualbox is *the* solution people use to run ubuntu on windows and on older releases of ubuntu (let's say 12.04 host)
<Wellark> naturally there are others too
<Wellark> but virtualbox seems to be very popular
<Wellark> I would even say most, but I don't have the data
<Wellark> and then there are people like me who run multiple VM's in virtualbox to be able to easily test stuff and fear of breakage
<racarr> mm, I don't know the data either but that sounds true
<racarr> I think it's on everyones radar, there is a work item for it somewhere but
<Wellark> so, 13.10 will have the fallback X so that most probably works with the available virtualbox 3d drivers
<racarr> I think in 13.10 fallback for virtualized
<racarr> yeah
<racarr> is acceptable
<Wellark> then of course this is no good for me (now I'm being selfish) when I have to develop unity8 code that requires Mir
<Wellark> and at the moment I don't have any HW that can actually run Mir
<Wellark> so I'm a bit concerned
<Wellark> and I'm probably not the only one
<racarr> ati or nvidia with no free driver support?
<racarr> :(
<Wellark> well, I have an exotic AMD card
<Wellark> last time I checked it didn't work that well with open drivers
<Wellark> and also my primary desktop machine is running 12.04 and I've been doing all my development up until now with VMs
<Wellark> but in essense not being able to run Mir inside any VM is quite troubleling
<Wellark> but we will see
<racarr> I see your point.
<olli_> kgunn, are you on didrocks' 5 items?
<racarr> I'll mention it to people and maybe try taking a look out of curiosity. There's a possibility maybe it actually can be made to work pretty quickly
<kgunn> olli_: literally
<kgunn> i'm actually wrestling with his #5
<racarr> but if it's substantial there probably isn't time for it right now
<kgunn> cause i didn't think libmirserver i/f wa an issue
<kgunn> (i mean its still moving....due to shell)
<kgunn> its libmirclient, which is controlled
<Wellark> racarr: that would be nice. I know we all have a full plate right now so generating additional work items is not something to be taken lightly
<Wellark> racarr: but as I said, not supporting any VM might handicap the development flow for people that need to develop on top of Mir, but not Mir it self
<Wellark> and by 14.04 also the users need/want to run Ubuntu on VM's for whatever reason
<racarr> Of course
<Wellark> like currently, we have Mac users running ubuntu in a VM, we have windows user running ubuntu in VM and then we have ubuntu users running ubuntu in a VM :)
<Wellark> racarr: anyway, thanks! :)
<Wellark> and good night
<olli_> kgunn, thx
<racarr> Night! Hope all is well.
<racarr> See you in the bar around 13.10 ;)
<olli_> bregma, any progress on the privacy notice in the installer?
<Wellark> racarr: or in your dreams at night ;)
<racarr> STop reading my diary
<bregma> olli_, I'm working on an MP for Ubiquity as suggested by cjwatson
<olli_> bregma, cool, thx
<olli_> bregma, will take it off my todo
<xnox> bregma: to work on top of Mir? =)
<xnox> bregma: nice.
<xnox> bregma: if you need any help join #ubuntu-installer and just ask. A small bunch of us idle there and respond rather quickly to all crazy things about ubiquity.
<bregma> xnox, I'll be there if there are problems, but mean time I'm happy just hacking
<xnox> bregma: good luck =)
<kgunn> bregma: thomi thinks you can may already have access to build...but you can get direction from #launchpad-ops
<thomi> bregma: what specifically are you looking for access to? The PPA builders, or the CI/autoland infrastructure?
<bregma> thomi, the fails didrocks sees look like they are in a PPA https://launchpadlibrarian.net/145088439/buildlog_ubuntu-saucy-armhf.mir_0.0.7%2B13.10.20130716ubuntu.unity.next-0ubuntu1_FAILEDTOBUILD.txt.gz
<thomi> bregma: yeah, you need to ask in #launchpad-ops
<thomi> bregma: I don't fancy your chances though
<bregma> indeed
<olli_> bregma, bschaefer do you guys know how to best disable accessibility in Saucy
<bregma> um, install it?
<olli_> robotfuel is having issues
<olli_> bregma, disabling it
<olli_> did you mean deinstall?
<bschaefer> thats what I would think as well, as unity *shouldn't* depend on it...
<bregma>  it was humour -- accessibility in Unity has always been a to-do
<bregma> is this a problem with Super-Spacebar?
<robotfuel> this is what I think should work  sudo -u ubuntu gconftool-2 --set --type bool /desktop/gnome/interface/accessibility false
<olli_> robotfuel, I like the idea of uninstalling it
<olli_> seems very safe
<robotfuel> I tried that, but everything depends on it
<bschaefer> :'(
<bschaefer> does setting that to false help?
<olli_> bregma, it's messing with mir benchmarks
<robotfuel> I have tests running now with that set to false, but I won't know for a bit
<bregma> which aspect of a11y is interfering with mir?
<olli_> robotfuel, dpkg -L at-spi2-core | xargs rm :)
<olli_> *cough*
<robotfuel> bregma: it's not mir, it's the gui-toolkits benchmark is crashing because of accessibility
<robotfuel> olli_: if setting to false doesn't help I'll do that. a distupgrade might pull in a new version of at-spi2-core, so I'd have to run that after every time I install packages to be safe
<olli_> robotfuel, do we need the at deamon to shut down?
<olli_> discussing with slangasek in ubuntu-devel
<olli_> robotfuel, can we disable the test for now and file this as a bug?
<olli_> but move on with the over benchmarks?
<robotfuel> olli_: yes, if it fails I'll just continue with other tests manually so we get results today
<olli_> robotfuel, infinity just suggested to remove /etc/xdg/autostart/at-spi-dbus-bus.desktop
<olli_> kgunn, ^ fyi
<robotfuel> olli_: ack, I am adding that to the preseed and distupgrade scripts now.
<robotfuel> olli_: thanks :)
<olli_> robert_ancell, are we using upstart user sessions in S
<robert_ancell> olli_, based on top, yes
<robert_ancell> olli_, upstart keeps using 100% CPU in my session :(
<robert_ancell> that's how I noticed the change had gone through
<olli_> robert_ancell, maybe I have a wrong understanding of upstart user sessions
<olli_> mind explaingin user session real quick
<olli_> I was just trying to judge from my ps afx output
<racarr> til: 1. Don't try and run mir with electric fence under GDB your entire system will hang
<racarr> 2. Don't try and run mir with electric ence under GDB a second consecutive time
<racarr> your entire system will hang again :(
<bschaefer> racarr, have you tried a third time?
 * bschaefer heres 3 is some sort of lucky number
<bschaefer> hears*
<racarr> bschaefer: I'm thinking about it ;)
<bschaefer> :)
<racarr> I mean right now all I have is a speculaative theory that electric fence causes my system to hang
<racarr> psuedoscience
<bschaefer> are you talking about a literal electric fence you are working under?
<bschaefer> cause that sounds unsafe
<racarr> no haha
<racarr> its a library you LD_PRELOAD
<racarr> that wraps malloc and free to catch many
<racarr> memory errors
<racarr> with an early segfault (rather than due to corruption lately)
<bschaefer> o nice, somewhat like valgrind?
<racarr> Yes. Catches a subset of valgrind errors
<racarr> but with much smaller performance penalty
<racarr> its great :)
<bschaefer> awesome, yeah valgrind gets hard to run at times....as it take forever to run the problem
<bschaefer> program*
 * olli_ pictures racarr sitting on a powerpole, in a yoga pose, hacking mir
<bschaefer> haha
<racarr> olli_: San Francisco is full of powerpole coworking spaces.
<racarr> robert_ancell: The good news is mir_stress now runs indefinitely
<robert_ancell> racarr, just updating to trunk?
<racarr> the bad news is I cant work out how the 'race' I fixed could present itsel except in memory corruption
<racarr> robert_ancell: No, the way it presented to me was
<racarr> an exception from SessionContainer::remove_session, "Invalid Session" meaning that the session had already been removed
<racarr> this was from ~SessionMediator, so when I investigated the logs I found that
<racarr> I was getting         report->session_error(session->name(), __PRETTY_FUNCTION__, "connection dropped without disconnect");
<racarr> but also a call to disconnect earlier (which completes, right prior to this exception throwing)
<racarr> anyway, I initially thought that maybe ~SessionMediator was
<racarr> being called from another thread, while the thread in ::disconnect was waiting, inbetween executing shell->close_session(session) and session.reset()
<racarr> so I guarded that and
<racarr> everything fixed itself
<racarr> except, actually ~SessionMediator is being called from the same thread as far as I can tell in the logs
<racarr> so that lock shouldn't matter, but fixes things which seems to imply
<racarr> frontend may be misdirecting messages
<racarr> due to some sort of corruption
<robert_ancell> racarr, does the guard make sense without knowing the problem?
<racarr> robert_ancell: Not really
<robert_ancell> racarr, :(
<racarr> I think it's likely that as soon as a few bits change, the problem will present itself again
<racarr> so im going to dig a little deeper, and if I dont find anything
<racarr> put up what I have so far
#ubuntu-mir 2013-07-17
<racarr> killall mir_stress;
<racarr> fun to write ;)
<racarr> feel very close to this stress bug
<racarr> but need to go help build a dome
<racarr> back later :)
<RAOF> racarr: Yo
<racarr> RAOF: Hi! Sorry. I am about to leave (I literally have to go help build a dome)
<RAOF> That's ok.
<racarr> but, I will be around...was hoping we could have a hangout later
<RAOF> Sure.
<racarr> I am jumping more on the xmir train (WHISTLE WHISTLE SCREEEEEECH)
<RAOF> Wooo wooo!
<racarr> and have a few items I want to sync with you on and just in general
<racarr> clarify
<RAOF> Cool.
<racarr> Ok play time!
<racarr> aww truncated
<racarr> *runs in shame*
<RAOF> What the whatting what? My perfectly valid DrawablePtr gets mangled in the process of calling xmir_dri2_drawable_can_bypass. Are there two different definitions of struct _Drawable or something?
<RAOF> There must be! What the whatting what?
<RAOF> Well, that's moderately terrible. Always #include <xorg-config.h>, lest your structures magically change layout!
 * duflu includes <xorg-config.h> in all files from now on
<duflu> Oh kdub, you put conflicts in all my code today :)
<duflu> Worse than conflicts... classes don't exist any more . Hmm...
<kgunn> so does gdb have known issues with xmir ?
<duflu> kgunn: X in general is not GDB friendly. You always have to GDB from an ssh login
<duflu> or remote shell of choice...
<RAOF> I'm happily gdbing XMir right now.
<RAOF> FSVO âhappilyâ
<kgunn> got it
<RAOF> Bah.
<RAOF> I should have remembered the unofficial X motto.
<RAOF> âX: More difficult than you thinkâ
<duflu> X: Solve everything for...
<RAOF> Alright. That's enough GLX bypass for now. Upstreaming!
<duflu> Woo!
<duflu> thomi: Sorry to bug you late in the day but any idea about... https://jenkins.qa.ubuntu.com/job/mir-clang-saucy-amd64-build/1222/console
<didrocks> hey kgunn!
<kgunn> hey didrocks !
<didrocks> waow, you are using French punctuation (space before ! : and ; )
<didrocks> kgunn: I confirm that u-s-c depends on libmirserver FYI
<didrocks> unity-system-compositor:
<didrocks>  Depends: libboost-program-options1.53.0, libboost-system1.53.0, libc6 (>= 2.9), libgcc1 (>= 1:4.1.1), libmirserver0 (= 0.0.7+13.10.20130716ubuntu.unity.next-0ubuntu1), libstdc++6 (>= 4.6)
<didrocks> (this dep is automatically resolved by the linker)
<kgunn> didrocks: hmmm,  i know  it uses a "shared" header...but it must actually end up being in libmirserver
<didrocks> src/system_compositor.h:#include <mir/default_server_configuration.h>
<didrocks> yeah, should be that ^
<kgunn> that be the one
<didrocks> kgunn: so, +1 on the virtual package, created by a soname (in cmake) which creates a config.h file (#define)?
<kgunn> didrocks: wanna join our team meeting ?....we can get all our stuff out of the way & ping you to join
<racarr> didrocks: It's really fun. you know you want to
<didrocks> racarr: ahah :p
<didrocks> kgunn: oh sure, when is it? (I thought your meetings were on Thursday)
<kgunn> nope tonight
<kgunn> or this morning sorry
<didrocks> I was able to translate :-)
<didrocks> how long from now?
<kgunn> we start in 1/2 hour
<didrocks> ok, just time to get the coffee ready then!
<kgunn> oh sure
 * racarr jealous
<racarr> If I had coffee there would be no going back
<didrocks> racarr: caffein-free tea? :)
<racarr> didrocks: One step ahead XD
<didrocks> heh
<racarr> it's the caffeine I want. it's just the caffeine I dont want in 1 hour
<RAOF> didrocks: Incidentally, how do we work out when the ABI has changed for that?
<RAOF> Empirically?
<didrocks> RAOF: you mean, how do you see the ABI changed? Yeah, you have to notice that your change did that
<didrocks> RAOF: the integration tests will tell you that quickly I think :p
<RAOF> Ah, ok.
<thomi> duflu: hey, I missed your message before
<thomi> duflu: it looks like possibly a bzr bug? Did you retry the build?
<duflu> thomi: No, I don't think I have the VPN set up any more
<thomi> duflu: OK
<thomi> duflu: I've just kicked it off again, we'll see if it works this time.
<duflu> thomi: Ta
<thomi> duflu: and I'll file a bug against bzr builder and see what the devs say
 * duflu wonders if the VPN setup instructions are any simpler tnow
<thomi> I'm not sure they're any simpler... but I set it up once, and have never had to touch it again
<duflu> ... because I tend to wipe my machines between releases
<thomi> I recommend using the network-manager-applet instructions
<thomi> ahhh
<thomi> I haven't done that for a few years now
<thomi> duflu: perhaps you have a router that's VPN capable? Although that's not very secure, depending on who has access to your personal network
<robert_ancell> thomi, hikiko, alf_ kgunn kdub meeting
<RAOF> racarr: Are you still hankering for a hangout?
<didrocks> kgunn: RAOF: let me enlight your day/night and please approve https://code.launchpad.net/~didrocks/mir/remove-powerpc/+merge/175201 :)
<thomi> duflu: looks like the re-run of that jenkins job worked. I've filed a bug against bzr-builder anyway
<duflu> thomi: Yep thanks
<dholbach> good morning! :)
<thomi> RAOF: Is a string like "Intel Corporation: 2nd Generation Core Processor Family Integrated Graphics Controller" useful enough to identify the graphics chipset for the xmir devices?
<thomi> I as because that's all we get for the cert lab machines at the moment
<thomi> But I guess ideally we'd get the specific model number
<RAOF> thomi: It's pretty good, but could be better.
<thomi> ok.. as long as it's not totally useless, I'll run with it for now
<RAOF> Ideally we'd get a tuple of (gen, GT #).
<RAOF> Xorg.0.log should actually have the (gen, GT #) tuple in in.
<RAOF> But I can't tell at the moment, because btrfs has done it's "I'll just wedge for a couple of minutes, k" thing, and anything that hits the disc subsystem is going to hang in D state.
<RAOF> Ah, there we go! Hissy fit ended!
<RAOF> [  6184.799] (--) intel(0): Integrated Graphics Chipset: Intel(R) Sandybridge Mobile (GT2)
<RAOF> That one's nice :)
<tvoss_> didrocks, just let me know when I can have fun on the arm builders, happy to take a look
<didrocks> tvoss_: yeah, I pinged infinity, but no luck :/
<tvoss_> didrocks, no pong or "no, you can't have fun on the builders"?
<didrocks> no pong
<duflu> I hate it when I wait a month for something to arrive, and then the wrong thing arrives
<duflu> Day spoiled
<alf_> duflu: :/
<duflu> alf_: You mentioned it's a problem when the ground moves under your feet and MPs become conflicted... Yes I experienced this today as I have many times already. I don't think it's a problem we can avoid completely while so many people are working on Mir simultaneously
<didrocks> alf_: look at https://code.launchpad.net/~didrocks/mir/remove-powerpc/+merge/175201 for the first part I guess :)
<alf_> didrocks: thanks
<didrocks> yw!
<alf_> didrocks: Agreed. My point was that if we have too many such "disruptions", it will unavoidably slow down critical work, and it is a risk we should have in mind.
<alf_> duflu: ^^
<alf_> didrocks: sorry, wrong nick :)
<didrocks> alf_: I started to think I hadn't enough coffee :p
<duflu> alf_: Yes. I guess then large changes must be justified and have high value for helping future work... which usually large changes do
<duflu> For example; a driver interface. It's a large change, but has high value
<alan_g> duflu: why do you think the graphics namespace might "go away"?
<duflu> alan_g: Because it makes no sense to designate part of Mir as "graphics" and other parts not graphics. It's all intended for graphics, so we should avoid the word
<duflu> alan_g: "platform" ?...
<alan_g> duflu: I concede that it is possible you can persuade the team to rename "graphics" to <something else>, but the namespace will still exist.
<duflu> How?
<duflu> alan_g: How would it still exist if it was renamed?
<alan_g> As, for example, "platform"
<RAOF> But Mir is not all intended for graphics; there's input, too.
<alan_g> It will still have the same contents and role
<duflu> RAOF: Almost all. The statement still holds :)
<RAOF> In put is *at least* as big as graphics.
<duflu> alan_g: Yes, true. Is your current proposal significantly different to just the namespace changes though?
<duflu> I haven't looked at it all in detail
<alan_g> yes, it moves stuff into that namespace
<tvoss_> duflu, if we remove graphics, we should have a namespace platform
<alan_g> Which is part of having a delineated garphics/platform API we can take to vendors
<tvoss_> duflu, we almost certainly end up with prefixes like Graphics* and that's what namespaces are for
<duflu> tvoss_, alan_g: Looking in more detail, I see we are moving things out of "compositor" that are platform independent. I don't think such things make sense in "platform" actually
<duflu> Maybe "graphics" is just a stepping stone
<alan_g> "graphics" is intentionally platform independent. That's why we have android and gbm implementations.
<alf_> alan_g: ... which contradicts our moving platform independent code into it :/
<alan_g> alf_: how does ""graphics" is intentionally platform independent" contradict " moving platform independent code into it :/"
<alan_g> ?
<alf_> alan_g: sorry, I read graphics (thinking gbm/android) is platform *dependent*, my comment is invalid
<didrocks> alf_: still no review on my branch?
<alf_> didrocks: done
<didrocks> thanks ;)
 * duflu goes stealth mode to avoid bugging Europe for the day (and vice versa)
<hikiko> alf_, ping!
<alf_> hikiko: pong
<hikiko> hi
<hikiko> do you have some time to ask you about the miron mir?
<alf_> hikiko: sure
<hikiko> https://lists.ubuntu.com/archives/mir-devel/2013-June/000166.html
<hikiko> I have this as a reference but I am not sure about my design:
<hikiko> mg::create_native_platform will be similar to current create_platform and leave in gbm/android
<hikiko> mg::create_nested_platform will be similar to create_platform and in nested_platform.cpp
<hikiko> and the create_native_platform_nested will call both?
<hikiko> if the native platform doesn't know anything about the nested platform
<alf_> hikiko: @mg::create_nested_platform, as things have evolved, you can probably skip this function and instantiate NestedPlatform directly (because it will live in libmirserver)
<hikiko> yes but where?
<hikiko> if it's required that
<alf_> hikiko: @mg::create_native_platform_nested, this will create a native platform configured for nested functioning (e.g. no drm, no vt)
<hikiko> sure but
<hikiko> my question is:
<alf_> hikiko: you can select which platform to create in DefaultServerConfiguration::the_graphics_platform()
<hikiko> so I choose there to create the native_platform_nested and this does the rest
<hikiko> I mean I just have to load the right callback
<alf_> hikiko: at that point you should create either 1. the native platform: with mg::create_native_platform or 2. the nested platform: use the NestedPlatform class. We can start with NestedPlatform calling mg::create_native_platform_nested() internally to create the native platform in "nested" mode.
<hikiko> got it :)
<hikiko> thanks alan_g
<hikiko> alf_*
<hikiko> :)
<alan_g> hikiko: yw
<hikiko> hahaha
<tvoss_> greyback, ping
<greyback> tvoss_: pong
<tvoss_> something is flakey in our armhf tests
<tvoss_> dear armhf machine, faster please
<bregma> tvoss_, can you be more specific about the flakiness?
 * bregma is not disagreeing
<tvoss_> bregma, I'm not entirely sure, but the file-based sync mechanism should be totally reliable albeit a bit unelegant :)
<tvoss_> however, I do see the clients starting in strace and immediately exiting with 0
 * bregma goes off to play with the synch mech
<tvoss_> bregma, a pipe should help :)
 * tvoss_ thinks that he could help the armhf build machine a little in translating to assembler
<tvoss_> bregma, I have something like http://pastebin.ubuntu.com/5884664/ in mind
<bregma> might want to epoll/signal in the wait to avoid a deadlock (does pipe() close if the writer exits without a shutdown()?)
<tvoss_> bregma, should, feel free to adjust ... if you can take care of that sync mechanism in the acceptance tests, I willl look into the flakiness
<tvoss_> I think it comes down to an unholy combination of buildd, kernel version, epoll and reactors
<tvoss_> just triggered a rebuild
<bregma> sure, but your rebuilds are still faster than mine
<tvoss_> bregma, not sure :)
<smspillaz> 1
<smspillaz> :(
<alan_g> smspillaz: ?
<smspillaz> alan_g: older versions of byobu required you to select a screen session whenever you launched byobu
<smspillaz> newer versions automatically resume your first
<smspillaz> So I have a muscle-memory of byobu-1 which ends up in me saying "1"  a lot
<alan_g> Yes I guessed that
<alan_g> All change is bad
<bregma> d'oh, fork() and RAII do not mix well
<racarr> Hours of stress testing -> lunch
<tvoss_> bregma, any more insight on your side?
<racarr> Ah! I had one more idea and failed to leave for lunch...and then now I think I finally found it
<racarr> (stress test)
<racarr> well it finally makes sense why it crashes at least
<racarr> NOW real lunch
<kdub> rvalue fun
<bregma> tvoss_, I'm fairly certain there's a race condition when the socket is destroyed by multiple child processes in the tests, but I'm still looking for concrete proof .. good news is I can repro locally now (after a 6 hour build)
<bschaefer> bregma, are you getting a pure virtual function called? Causing it to crash? (I've ran into that when attempting to close the mir server before...)
<bschaefer> or close a connection to the server
<bregma> bschaefer, there is a deadlock where the test case is waiting for a signal but the child (signaller) has exited beforre the wait begins (qhich itself is a sequencing problem)
<bschaefer> bregma, oo different problem then :)
<bschaefer> bregma, children should learn to wait!
<bregma> indeed
<tvoss_> bregma, \o/
<tvoss_> bregma, I will EOD now
<thomi> morning
<racarr> Morning
<racarr> this stress-test race is a little deeper than just adding a mutex or something struggling a bit to find a solution even now that it's found
<racarr> kdub: I feel like the general theme may interest you
<racarr> msh::Surface is almost impossible to use safely outside of the scope of the Session that owns it
<racarr> because, say, when a surface is closed, so we have to find a new surface to focus, so we find it and get a shared_ptr<msh::Surface>
<racarr> and then call surface.anything()
<racarr> and then another thread closes the surface
<racarr> so your msh::Surface pointer is stlil valid but surface.anything()
<racarr> throws...
<racarr> because the ms::Surface is gone
<racarr> I guess, you need session to act as a synchronization point so rather than like
<racarr> bla = session.default_surface()
<racarr> bla.take_input_focus(targeter)
<racarr> you can do like session.take_input_focus_on_default_surface(targeter)
<racarr> and the session will hold it's internal lock preventing a close_surface from being processed
<racarr> but this feels unsatisfying and unscalable
<racarr> The other immediate direction that comes to mind is exposing locks out of the session as API, i.e. msh::Session::Freeze f(session);, but this seems really error prone.
<racarr> So maybe what you really want, is some way to promote a surface pointer, i.e. surface.no_really_block_any_thread_that_is_trying_to_destroy_this_surface_until_the_return_value_of_this_function_is_destroyed
<racarr> so now I start to think that these are transactions
<racarr> and wonder what Alan's thoughts so far are on the new scenegraph model ;)
<racarr> because these sort of inconsistencies, are what the hypothetical group-mind scenegraph model is supposed to be able to solve
<racarr> Another random API idea: session.transcation(std::function<void>())
<racarr> which freees the session (with a recursive mutex)
<racarr> and then invokes the callback
<racarr> so this way you can write like
<racarr> session.transaction([&](Session& s) { auto surface = s.default_surface(); surface.take_input_focus(); }
<racarr> and anything calling i.e. Session::destroy_surface
<racarr> will block until your transaction is complete
<racarr> It's not really a transaction
<racarr> because it's not reapplicable, what is it...
<racarr> it's like an atomic operation. but it's not clear what session.atomically_do means (atomic with respect to what?)
<robert_ancell> racarr, can you merge lp:~robertcarr/mir/simplify-depth-assignment with trunk?
<racarr> robert_ancell: Yeah doing so now
<robert_ancell> cool
<racarr> robert_ancell: I finally found the stress race :)
<racarr> in a way that explained the weirdness from yesterday and everything
<racarr> so uite happy
<robert_ancell> \o/ awesome!
<robert_ancell> me too :)
<racarr> but the solution is a little tricky
<robert_ancell> and thomi too I expect
<racarr>  /unclear
<thomi> hmmm?
<kgunn> robert_ancell: hope it clears some other stuff
<kgunn> too
<thomi> racarr: cool!
<thomi> racarr: when you have a branch with the fix, let me know and I'll review your MP and test it here
<thomi> I seem to be able to trigger these things more easily than most people
<racarr> XD I get it like
<racarr> ALWAYS
<kgunn> hey, does anyone know any special fiddling required to run a system with both nvidia & intel gfx ?
<racarr> within a second
<thomi> apparently my CPU isn't just hyper-threaded, it's hyper-mega-awesome-threaded
<kgunn> i know RAOF said his ran
<thomi> racarr: awesome :)
<kgunn> do you just load nouveau for nvidia and everything else should he "happy happy happy" ?
<kgunn> oops/he/be
<racarr> kgunn: When I had hybrid graphics the special fiddling was always disable one in the BIOS ;) not sure if you are hoping to do more than that
<kgunn> nope....dandrader was trying xmir and having issues...i'll share tht
<racarr> oh god. what an awful merge conflict
<kgunn> racarr: thx for it
<racarr> :)
<kgunn> racarr: dandrader was looking for something fun...i told him he'd get a couple of beers from me if he solves the input lag
<racarr> you mean the output lag!
<racarr> or was that a dream
<racarr> sometimes the team meeting is hard to remember
<kgunn> racarr: right
<kgunn> all depends....:)
<kgunn> and i think most correctly...yet to be determined lag
<kgunn> racarr: btw...i capture 2 other "please add api" tasks in the unity prep bp
<kgunn> 1 for osk surfacetype
<kgunn> and 1 for greeter
<kgunn> i figure you know what they are....but if not....ping dandrader for osk & mterry for greeter
<racarr> I think I do
<racarr> simplify-depth-assignment is the first part of the greeter fix
<racarr> buttttttttttttttttttttttttttttttttttttttttttttt the second part isn't clear to me yet
<racarr> ill make sure I don't lose track of them :)
<racarr> robert_ancell: Merging simplify-depth-assignemtn will take a while
<racarr> something...strange landed
<racarr> and I can't even understand how the tests pass in trunk
<robert_ancell> racarr, np, was just checking you'd seen it
<racarr> all the tests which are supposed to test depth ID
<racarr> got replaced with default_depth
<racarr> oh and then they pass because the expectations got reordered
<racarr> to make them pass
<racarr> -.-
<racarr> -.-
<racarr> all the surface stack ordering tests are broken
<racarr> because they verify by comparing the reference to the rendering criteria and the buffer stream
<racarr> but they all use stub buffers that share the same
<racarr> rendering criteria and buffer stream
<racarr> so by broken I mean they always pass
<racarr> I think I have decided on (at least for a first proposal) this msh::Session::perform_transaction(std::function)
<racarr> API.
<racarr> The test is difficult to design though.
<racarr> the, test should verify that during the body of the function argument to perform_transaction
<racarr> calls to create/destroy surface block
<racarr> it should also not be a racy test ;)
<racarr> one interesting possibility, requiring some serious pthread nastiness
<racarr> is first you have to pin your test thread to one core, and set pthread sched param to
<racarr> SCHED_FIFO
<racarr> then you create a session, and a surface and call perform_transaction
<racarr> in your body, you start a new thread, which calls session.destroy_surface
<racarr> oh and the new thread also needs to be pinned to the same core
<racarr> so then after you strt the new thread, the test yields guaranteeing your surface destroying thread will run now
<racarr> since they are both pinned to the same core, and scheduling mode is SCHED_FIFO
<racarr> the thread is guaranteed to continue to run until it blocks or yields
<racarr> so, in the test thread, right after you yield, you can check if the surface has been destroyed
<racarr> if it has, then create_surface blocked (otherwise that thread would still be executing and will have finished destroying the surface)
<racarr> err, if it hasn't*
<racarr> if it has, then clearly create_surface succeeded
<racarr> and you have deterministic test results, i.e. create_and_destroy_surface_block_during_body_of_transaction
<thomi> robert_ancell: I notice that u-s-c has no license file!?
<robert_ancell> thomi, I guess. It has license headers
<robert_ancell> feel free to add one
<racarr> I have the sick feeling that that test
<racarr> would never land
<thomi> robert_ancell: will do
<thomi> robert_ancell: https://code.launchpad.net/~thomir/unity-system-compositor/add-license-file/+merge/175422
<racarr> I dont think it's even possible to use SCHED_FIFO without root XD
<racarr> I'm not sure this test is even possible as a normal user
<racarr> because threads and processes are the same to the linux scheduler
<racarr> so any program that can guarantee a thread executes
<racarr> until it blocks
<racarr> can bring down a single core system :p
<racarr> but really I just want to guarantee, that another particular thread wont execute until that thread blocks
<racarr> It's not actually a realtime requirement, I don't care if the kernel lets other processes run
<thomi> robert_ancell: for this autopilot test, what's the best way of figuring out what hardware is running?
<racarr> what I need is PTHREAD_SCOPE_PROCESS
<racarr> but it's no tsupported on linux...
<racarr> lol
<RAOF> Really? That's odd.
<racarr> RAOF: Actually linux pthread implementation seems to be roughly
<racarr> the least expressive pthread implementation allowed by the specification
<racarr> because of the lack of distinction between
<racarr> threads and processes.
<racarr> ahaha
<racarr> I am not happy about pthreads atm if you can tell
<RAOF> You could probably rube-golberg up the behaviour you want with an extra thread, right?
<racarr> RAOF: I can't figure out a way...
<RAOF> ie: a watchdog thread that monitors the thread you're interested in, and sets a flag when it's blocked.
<racarr> can't
<racarr> do that either in linux
<racarr> i.e. tell if a thread is blocked
<RAOF> What do we mean by âblockedâ in this case?
<racarr> RAOF: voluntarily yielded
<racarr> RAOF: So the idea is, I am developing this API like session.do_transaction(std::function)
<racarr> for solving...a series of other races, the stress test stuff
<racarr> so, the semantics it needs to provide are
<racarr> create_and_destroy_surface_block_during_body_of_transaction_function
<racarr> so as far as I can see, the only way to deterministically test that is to
<racarr> start a second thread from within your transaction callback, which tries to destroy a surface
<racarr> and then guarantee that that thread runs until it blocks
<racarr> i.e. isn't preempted by your original thread
<racarr> because otherwise, all you can say is "that thread hasn't gotten to destroy surface yet..." (or rather, whatever instruction in the implementation of destroy surface the lock is actually held on)
<RAOF> You should be able to parse /proc to assert that the thread isn't running?
<racarr> but whatever code does that
<racarr> might preempt the thread
<racarr> and then it wont be running
<racarr> i.e. the thread might exhaust it's timeslice and be stopped from running beore it actually blocks
<racarr> so, an easy fix is to use
<racarr> SCHED_FIFO
<racarr> and pin both threads to the same core
<racarr> but, because there is no PTHREAD_SCOPE_PROCESS
<racarr> SCHED_FIFO requires root, and can bring down your entire system
<racarr> lol
<RAOF> Eh, it's a testsuite.
<RAOF> They're pretty much allowed to bring down your system âº
<RAOF> piglit does all the time!
<racarr> yeah but can they run as root?
<racarr>  / with some weird RT capability flag
<RAOF> Why can't they?
<racarr> I dunno
<racarr> I guess I just kind of assume someone would object and stop that from landing
<racarr> I don't mean anyone in prticular, I just mean it sounds really
<racarr> objectional
<racarr> lol
<racarr> BUG: Can't run tests as non root user!
<racarr> haha, I guess it can just be a disabled test.
<RAOF> We build the packages as root already, so setting the RT capability on the tests shouldn't be _too_ bad.
<racarr> mm.
<racarr> ok, those are all very good points.
<racarr> XD, Thank you
<racarr> I was kind of spinning from "Can't use SCHED_FIFO"
<racarr> and just going deeper down that line
<racarr> and reading very strange websites about freebsd
<RAOF> Damn it takes *forever* to build an Ubuntu kernel.
<RAOF> You try and add one piece of functionality to dma-buf, you're waiting hours for it to build!
#ubuntu-mir 2013-07-18
<racarr> RAOF: You just need to switch the scheduling policy on your brain.
<racarr> Of course, that could bring down the whole system so it's not allowed under the controlled substances act...
<thomi> RAOF: got a second?
<RAOF> thomi: Sure.
<thomi> RAOF: just writing this autopilot test for u-s-c, what's the best way of determining the graphics chipset in use?
<thomi> RAOF: also, Didier's email seemed to say that we should only be running u-s-c on intel chipsets?
<RAOF> How specific are we about "in use"?
<RAOF> ie: hybrid graphics, what should we report?
<thomi> RAOF: I don't know... I guess you'd know better than me
<thomi> the test is to determine whether we're actually running u-s-c on supported hardware
<RAOF> glxinfo | grep renderer (in XMir) is not-terrible
<thomi> RAOF: I guess IO could do something like run "lshw -class display" and parse the output
<thomi> RAOF: OK, so under what situations should we be running u-s-c?
<RAOF> Everywhere that isn't proprietary driver.
<RAOF> Oh, and not on virtual hw, or crazy old stuff like SiS.
<thomi> RAOF: so, how do I determine "not on proprietary driver"?
<thomi> or "not on virtual hardware"?
<thomi> I'm wondering if it's better to whitelist suppoorted hardware, or to blacklist unsupported hardware
<RAOF> If i915.ko, radeon.ko, or nouveau.ko are loaded.
<thomi> ahh, ok, that's much easier
<thomi> thanks!
<RAOF> Acutally, that'll miss some hybrid systems.
<RAOF> You actually want to make sure that each VGA device in lspci | grep VGA has its associated driver loaded.
<RAOF> So, if there's an nvidia device in lspci | grep VGA, then nouveau.ko is loaded, itc.
<RAOF> etc.
<thomi> hmmmm, that sounds harder to do exhaustively
<RAOF> lspci -vvv, parse it out, check that "Kernel driver in use: " is the right thing.
<thomi> RAOF: OK, but presumably there's edge cases when matching device -> driver? or do we really only care about those three cases: intel, nvidia & ati?
<RAOF> Only those three cases.
<thomi> ok, sweet
<RAOF> If there's an intel VGA device (identifiable by 8088 pci id), then it must have i915 loaded; if there's an nvidia device, it must have nouveau loaded, likewise ati.
<thomi> awesome, thanks for your help.
<thomi> Going to lunch now, will get this finished when I get back.
<RAOF> Arse. This kernel is built with debug symbols, making it 700 MB, or significantly larger than my boot partition. Poot.
<xnox> ... chain-load?!
<xnox> boot of usb?! =)
<racarr> RAOF: Sounds like the second reason today to switch to FreeBSD
<RAOF> Surely GNU/Hurd!
<thomi> I don't suppose anyone here has a machine with a radeon graphics chipset?
<thomi> RAOF: perhaps you have one?
<RAOF> thomi: I do.
<RAOF> What can I do for yoU?
<thomi> RAOF: any chance you could send me the output of 'lspci -vvv' on that machine please?
<thomi> or maybe just the section for the VGA device
<RAOF> http://paste.ubuntu.com/5886137/ (and with -n, which you should probably use so you can match on PCIID )
<RAOF> http://paste.ubuntu.com/5886140/
<RAOF> thomi: ^^^
<thomi> RAOF: thanks
<RAOF> You'll notice this is a hybrid system, so a good test :)
<thomi> RAOF: what's the best way to determine if xmir is running? simply "pgrep unity-system-compositor" ?
<thomi> or is there some better way that you can think of?
<RAOF> Two options; pgrep unity-system-compositor or grep xmir /var/log/Xorg.$(echo $DISPLAY | sed s/://g).log
<thomi> RAOF: I don't like the log file apprach, it seems a bit fragile to me... but I'm having trouble getting pgrep to do what I want :(
<thomi> ahh yes, I remember
<thomi> pgrep cuts process names
<thomi> so "pgrep unity-system" works, "pgrep unity-system-compositor" will never return anything :(
<RAOF> You could also check the args used to spawn /usr/bin/X; if they contain â-mir â, then it's XMir.
<duflu> robert_ancell: What's you're preferred medium? :)
<duflu> Oh
<thomi> robert_ancell: got a second?
<robert_ancell> thomi, otp
<robert_ancell> thomi, sure
<robert_ancell> thomi, are you checking from inside X or outside it?
<thomi> robert_ancell: https://code.launchpad.net/~thomir/unity-system-compositor/add-autopilot-test/+merge/175444
<thomi> robert_ancell: I'm hoping we can get didier to do the packaging for us?
<robert_ancell> thomi, what packaging is required?
<thomi> robert_ancell: autopilot tests are usually packaged into <appname>-autopilot
<thomi> package
<thomi> so in this case, unity-system-compositor-autopilot
<robert_ancell> thomi, and that's part of the u-s-c source package? I can do that
<thomi> yes
<thomi> awesome - I can package python modules, but packages where it's half Cmake, half python build systems confuse me
<robert_ancell> thomi, what is an existing package I can look at?
<thomi> robert_ancell: lp:unity8 has one
<thomi> as does lp:unity, and any of the phone apps
<thomi> usually I'd point dh at the setup.py file in tests/autopilot, but I'm not sure how you do that in a mixed package?
<robert_ancell> thomi, because it's all python we just make a debian/unity-system-compositor-autopilot.install file and update debian/control. I'm doing a merge now
<thomi> awesome, thanks
<thomi> I thought it was more complicateed than that, but OK :)
<robert_ancell> thomi, was there a reason for unity_system_compositor over unity-system-compositor?
<thomi> robert_ancell: yes, you can't have '-' in module names
<robert_ancell> thomi, https://code.launchpad.net/~robert-ancell/unity-system-compositor/add-autopilot-test-packaging/+merge/175446
<thomi> will merge now
<thomi> robert_ancell: OK, those changes are now in my branch. Will email the list so didrocks reviews it
<robert_ancell> kdub, still here?
<robert_ancell> thomi, did you want didrocks to specifically review https://code.launchpad.net/~thomir/unity-system-compositor/add-autopilot-test/+merge/175444?
<thomi> robert_ancell: yes
<thomi> robert_ancell: Standard procedure is that his team review any packaging changes for stuff that's being daily-released
<robert_ancell> thomi, oh, I forgot to say, you probably want to add something to the Depends line in debian/control for the test
<thomi> robert_ancell: otherwise it's too easy to release broken packages into distro
<robert_ancell> I'm not sure which packages it needs
<thomi> robert_ancell: oh, good point, thanks :)
<robert_ancell> thomi, can you add a specific review request for him? Otherwise when I review it it will not be pending on him
<thomi> sure
<robert_ancell> (and then I'll forget and just approve it)
<thomi> done and done
<RAOF> I hope this doesn't hit the thermal trip point...
<tvoss_> good morning :)
<RAOF> Good morning
 * RAOF wonders if packaging thermald would be a useful way of attempting to make this laptop less likely to emergency-shutdown due to hitting the thermal trip point.
<duflu> RAOF: What? Ubuntu doesn't already come with sane sensors monitoring?
<didrocks> thomi: hey, still around?
<thomi> didrocks: yo yo
<didrocks> thomi: just looking at MP ;) So I think we need another tests: if we are not on a open source driver, ensuring unity-system-compositor doesn't run
<didrocks> thomi: of installing autopilot tests, I prefer having a setup.py and some hack in debian/rules, do you want me to propose a branch with that?
<thomi> didrocks: sure, that's trivial, one second
<didrocks> thomi: something similar than unity8 if you want to do it (setup.py in the autopilot directory) and in debian/rules, see my call to setup.py
<didrocks> then dh --with python2 and build-dep on python
<thomi> didrocks: ugh, I had that initially, and robert_ancell removed it
<thomi> didrocks: can I ask you to do the packaging for me? Pretty please?
<didrocks> thomi: sure sure, incoming!
<thomi> I'll buy you a beer next time we meet :)
<didrocks> heh, \o/
<tvoss_> didrocks, for the armhf test hangs ...
<tvoss_> did you see Stephen's mail?
<didrocks> tvoss_: hey, yeah, read it
<tvoss_> didrocks, so one way would be for us to come up with a custom TEST macro (TEST_WITH_REQUIREMENTS) that checks if android runtime is present and disables the test if not automatically
<tvoss_> didrocks, what do you think?
<didrocks> tvoss_: sounds the right way to me, do you have any way to tests that we are running with android? like detecting a file is present?
<tvoss_> didrocks, we could try to resolve symbols from the platform api
<thomi> didrocks: actually, I'll make this test case test both scenarios
<didrocks> thomi: that's fine as well, just change the name then :)
<tvoss_> didrocks, essentially taking the cause of the error as check
<didrocks> thomi: platform-api will tell "not on android"?
<didrocks> tvoss_: because platform-api will be installed, right, so platform-api symbols will be there
<tvoss_> didrocks, fair point ... hmmm, we need a way to force the backend instantiation and report an error if something is missing ...
<didrocks> tvoss_: couldn't platform-api have this check?
<didrocks> like a platform-run call to know where we are running on?
<didrocks> (just a silly proposal :p)
<tvoss_> didrocks, hmmm ... let me think about it for a bit
<didrocks> thomi: ok, the longer was to readd the ppa to install libmirserver-dev ;) here we are, do you want a MP against your branch? (it's just one commit): lp:~didrocks/unity-system-compositor/autopilot-packaging-fixes
<thomi> didrocks: nah, I'll just merge it in, thanks!
<didrocks> thomi: yw ;)
<thomi> didrocks: just finished the test as well
<didrocks> great :)
<didrocks> RAOF: hey, did you see that xorg-server is lower than distro? are you planning on updating it?
<didrocks> RAOF: I thin I can't run the autopilot tests because of that, right?
<mlankhorst> sec
<didrocks> https://launchpad.net/~mir-team/+archive/staging/+copy-packages still times out :/
<thomi> didrocks: your changes have been merged in, and the new test is pushed.
<didrocks> thomi: excellent! looking at the testing part, you want a second review from robert_ancell I guess as well?
<thomi> didrocks: if he's still here
<thomi> didrocks: otherwise I think we're good to merge
<thomi> what could possibly go wrong!? :P
<didrocks> thomi: heh, indeed! ;)
<mlankhorst> RAOF: pushed
<didrocks> thomi: sounds perfect to me with those changes, +1 ;)
<didrocks> I'm now adding it to the tests to run
<didrocks> done
<tvoss_> didrocks, https://github.com/ros-infrastructure/buildfarm/issues/87
<didrocks> tvoss_: but, the buildds (not the virtualized builders) are now running with qmenu? Not sure of the latest, but from last news I got, they were still running on bare metal
<tvoss_> didrocks, hmmm, good question ... checking with #is
<RAOF> didrocks: Yes, I was planning to update xorg-server. Just after mlankhorst pushes 1.14.2-0ubuntu1 to git :)
<RAOF> duflu: Ubuntu *does* have sane sensors monitoring, but thermald does intel-specific tricks.
<mlankhorst> it's all you now, stop hiding behind me :P
<duflu> RAOF: Cool. In fact cooler the better
<RAOF> mlankhorst: Ta
<didrocks> RAOF: I can't copy package to the daily-build-next and next ppas :/
<RAOF> didrocks: I'm updating now.
<didrocks> RAOF: I can't add the staging ppa, because different version of Mir and unity-system-compositor (with versions higher than daily-build-next/next)
<didrocks> RAOF: do you think I should just reupload to daily-build-next them?
<didrocks> mesa + xorg*
<RAOF> I'm not sure what you're asking.
<didrocks> RAOF: basically, I need mesa + xorg* copied in daily-build-next ppa
<didrocks> (I can't add staging because of mir/unity-system-compositor version mistmatch)
<RAOF> Right. And for that we need an xserver that's newer than the archive.
<didrocks> RAOF: I wanted to binary copy your packages, but https://launchpad.net/~mir-team/+archive/staging/+copy-packages times out constantly for me
<RAOF> Really? I've been happily copying packages from staging for a while.
<didrocks> RAOF: is it timeouting for you?
<RAOF> How many packages are you trying to copy?
<didrocks> RAOF: well, I can't even display https://launchpad.net/~mir-team/+archive/staging/+copy-packages
<RAOF> didrocks: Yes.
<RAOF> I can happily load that page .
<didrocks> urgh, not me, not yesterday, no today :/
<didrocks> RAOF: hum, do you mind copying that yourself to daily-build-next?
<RAOF> Odd.
<didrocks> RAOF: I can add you to the team
<RAOF> Yeah, sure.
<didrocks> thanks a bunch :)
<RAOF> Just mesa + the X packages that you need, right?
<didrocks> RAOF: exactly! to https://launchpad.net/~ubuntu-unity/+archive/daily-build-next
<RAOF> And once Mir has landed in Universe I can just add the xmir patch to our regular xserver git, and all will be well.
<didrocks> RAOF: you need Mir to be landed in Universe? xmir depends on Mir?
<didrocks> not the other way around?
<mlankhorst> RAOF: no
<mlankhorst> RAOF: mir needs to be in main for that depends
<RAOF> mlankhorst: Oh, yeah, quite true.
<RAOF> didrocks: Yes, indeed. XMir depends on libmirclient.
<didrocks> ok, which is the stable API part :)
<RAOF> Correct.
<didrocks> RAOF: I think Mir entering main isn't an issue, I know an archive admin who as well reviewed and fixed the packaging for Main :p
<RAOF> Faster, laptop, faster!
<alf_> RAOF: Are you sure you want to push your thermally challenged laptop so hard? ;)
<RAOF> I've chocked it up, and the kernel build has finished. It's only 65â now :)
<tvoss_> ffs, why does swithcing to a guest session fix the input lag issue?
<tvoss_> s/input lag/output lag
<RAOF> Hm. Does that suggest a Mir platform?
<tvoss_> RAOF, ?
<RAOF> Because that's switching surface focus.
<tvoss_> RAOF, it does ... let me check something
<RAOF> Notably, it *doesn't* stop X from rendering, unless Mir blocks it.
<tvoss_> RAOF, yup
<RAOF> Does u-s-c block mir_surface_swap_buffers block when a surface isn't focused?
<tvoss_> RAOF, checking exactly that
<tvoss_> robert_ancell, ping
<duflu> RAOF: It shouldn't block for obvious compositing reasons, but it does due to https://bugs.launchpad.net/mir/+bug/1188486
<ubot5> Launchpad bug 1188486 in Mir "Unfocused apps are never visible on screen" [Medium,Triaged]
<tvoss_> RAOF, might that be the reason that a switch to the guest session "aligns" things again?
<RAOF> Plausibly.
 * RAOF wanders through the code while Mesa builds.
<duflu> ... it's a general problem Mir has with unfocused clients getting paused. They shouldn't get paused, obviously
<duflu> At least not by default
<tvoss_> duflu, agreed, it should be a policy
<dholbach> good morning
<tvoss_> woot, no more second cursor :)
<duflu> tvoss_: So now just try to VT switch to tell if you're in Mir ;)
<tvoss_> duflu, fair :) but htop tells me I'm in mir
<tvoss_> wow, only one cursor ... this is so mainstream
<duflu> It's so 20th century
<tvoss_> duflu, exactly
<tvoss_> duflu, my mind feels bored now ...
<pete-woods> morning guys!
<pete-woods> I just tried running mir in a VM
<pete-woods> and it doesn't seem to start
<pete-woods> is this expected for the moment?
<tvoss_> pete-woods, yup
<tvoss_> pete-woods, what vm are you trying?
<pete-woods> tvoss_: it's parallels - it has a fantastic pass-through GLX driver
<pete-woods> obviously I've uninstalled that for trying out Mir
<pete-woods> so I was expecting it to run with fbdev/llvmpipe like X11 does
<tvoss_> pete-woods, we need a driver capable of gbm/drm/kms
<duflu> pete-woods: It is planned, but not implemented yet
<pete-woods> tvoss_, duflu: no worries guys, is this something we'd be trying to have ready for 13.10?
<duflu> pete-woods: We will be trying yes, but I don't believe it's on the critical list
<tvoss_> pete-woods, exactly what duflu said. The easiest way for us would be if the vm offers the required driver functionality and an XMir integration
<pete-woods> duflu: that's fair enough - I'm really just a very interested party here
<duflu> pete-woods: https://bugs.launchpad.net/mir/+bug/1118903
<ubot5> Launchpad bug 1118903 in Mir "Mir lacks a software rendering backend" [High,Triaged]
<RAOF> Oooooh.
<RAOF> Hm.
<tvoss_> RAOF, ?
<RAOF> So, because threading and X is a world of pain, we push events through a pipe.
 * tvoss_ listens excitedly to RAOF
<RAOF> Which obviously happens asynchronously.
<RAOF> But that's ok, because we register the pipe as a general socket, and have a wakeup handler.
<RAOF> So, what happens is we receive the buffer on a thread. We push this through the pipe, which wakes up the server if it's not already busy...
<RAOF> So what I should check is whether we should *also* be registering a BlockHandler to check the pipe before the server goes into select.
<RAOF> Although my understanding is that it should just immediately wake up.
<RAOF> But first, ZoÃ« bath.\
<robert_ancell> didrocks, ah, I was looking at an out-of-date version of unity8 which didn't have setup.py
<robert_ancell> tvoss_, hellp
<robert_ancell> hello
<didrocks> robert_ancell: be on the edge! (yeah, it's something I fixed) :-)
<tvoss_> robert_ancell, you running in XMir?
<robert_ancell> tvoss_, not this very second
<tvoss_> robert_ancell, I've got a patched libmirserver package that disables input for the usc and the second cursor
<tvoss_> robert_ancell, need some mileage to make sure that the lag does not show up anymore
<robert_ancell> tvoss_, I never remember noticing the lag
<tvoss_> robert_ancell, weird
<tvoss_> robert_ancell, still, some mileage would be great :)
<robert_ancell> tvoss_, email me the link
<tvoss_> robert_ancell, the package :)
<robert_ancell> tvoss_, just send the branch, it will be easier to compile here
<tvoss_> robert_ancell, not a branch yet, patched the src package from the system compositor testing ppa
<robert_ancell> tvoss_, don't you build from the branch?
<tvoss_> robert_ancell, nope, I did an apt-get source libmirserver0 and patched the package, it's really a hack right now, would need to be handled in usc and shouldn't go into mir at all
<robert_ancell> tvoss_, so can't you just do a bzr branch, make the change, commit and push somewhere?
<tvoss_> robert_ancell, https://code.launchpad.net/~thomas-voss/mir/disable-input-by-default
 * tvoss_ notes that this is hacky and should be cleanly done in the unity-system-compositor server configuration
<robert_ancell> brb
<didrocks> RAOF: do you mind telling me once everything is copied so that I can run the tests?
<RAOF> didrocks: Sure
<didrocks> thanks!
<RAOF> Hm. Where did my xorg-server upload disappear to?
<didrocks> RAOF: never heard about the launchpad black hole? ;)
<RAOF> Ah. sacuy â  saucy :(
<tvoss_> RAOF, :)
<didrocks> RAOF: so close, should have worked! :-)
<alan_g> tvoss_: ping
<tvoss_> alan_g, grabbing coffee :) mind opening a hangout and inviting me, would like to use the ipad
<alan_g> tvoss_: ack
<tvoss_> alan_g, can you call again please?
<robert_ancell> tvoss_, I'm still seeing a similar delay
<tvoss_> robert_ancell, hmmm, is that a new issue for you? you said you haven't seen it before, right?
<robert_ancell> tvoss_, now I try it I do remember it
<robert_ancell> but I tried both, and I'm not seeing any major difference
<RAOF> didrocks: Everything's in the PPA now; enjoy.
<didrocks> RAOF: \o/ I'll for sure, thanks!
<alan_g> \o/ networking and cursor now working again on my laptop
<katie> tvoss_, ping
<tvoss_> katie, pong
<katie> tvoss_, hi. are we having our meeting in 5 mins?
<tvoss_> katie, if you want to, yes. I still owe you a review, though. Anything urgent to discuss?
<katie> tvoss_, i do have a couple of general questions, so yes, would still like a quick chat
<tvoss_> sure
<tvoss_> can you invite me to the hangout then?
<katie> sure, thanks
<alan_g> alf_: are you happy to top approve move-graphicsplatform-dependencies-to-graphics-less-contentious?
<alf_> alan_g: sure,
<alf_> alan_g: do you want me to do it?
<alan_g> alf_: that would make me happy too
<alan_g> Oh! /o\ only *wireless* and g3 networking is working. Laptop still doesn't do wired networking.
<alf_> alan_g: (done)
 * duflu wanders off dazed
<alan_g> duflu was still up?! No wonder he's dazed
<alan_g> alf_: just looking at gl_pixel_buffer.cpp and see a runtime test "is_big_endian()" - shouldn't that be detected at compile time?
<alf_> alan_g: We could, although ARM CPUs are bi-endian, but I am not sure if this is a scenario we have to care about.
<didrocks> kgunn: hey, around?
<kgunn> didrocks: yeah
<didrocks> kgunn: so, I have a good news and a bad news :)
<didrocks> kgunn: good news is that the tests failing were finally flacky tests it seems
<didrocks> the bad news is that with thomi's script, we have the confirmation that mir isn't running
<didrocks> https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/501/
<didrocks> can be a config issue, but would be better to debug with someone knowing how lightdm runs unity-system-compositor
<mterry> kgunn, hi
<mterry> ahem
<kgunn> mterry: hey...your here :)
 * kgunn suffering irc ping-tsunami
<kgunn> mterry: so didrocks having  u-s-c/mir failing to start on his autopilot daily release testing
<kgunn> wondered if you've tinkered enough to have a look
<kgunn> https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/501/
<mterry> couldn't hurt...
<kgunn> didrocks: how to get the log files off that machined?
<kgunn> didrocks: we'd need the usual suspects in /var/log/lightdm
<didrocks> kgunn: we have them
<didrocks> mterry: hey hey! :)
<didrocks> mterry: one sec, just grabbing my coffee ;)
<kgunn> didrocks: please don't scare mterry :))
 * mterry runs into the brush
<didrocks> kgunn: I've scared hum for many years now you know :p
<didrocks> first on the OEM side, he was taking unity from my packaging
<didrocks> I think he was scared from that date :p
<didrocks> s/hum/him/
<kgunn> didrocks: actually i should ask...have you simply done a subsequent reboot on that machine ?
<kgunn> bschaefer & robotfuel were seeing yesterday that
<kgunn> on a few machines xmir wouldn't come up after initial dist-upgrade
<kgunn> but then after second reboot it would
<kgunn> and then it was fine thereafter
<mterry> didrocks, so I see two failures,  test_running_hardware_check and a 'unity_system_compositor' test
<mterry> Oh, maybe those are the same
<didrocks> mterry: they are, on the 2 configs :)
<didrocks> kgunn: in fact, we install the packages before lightdm starts
<mterry> didrocks, but I don't see the /var/log/lightdm stuff in the archive.zip file
<didrocks> mterry: ok, so in the log, you can see http://10.97.4.139/otto/saucy-i386-20130718-1122
<didrocks> mterry: I: Archive of the container to run this test available for download from:
<mterry> oh man, ok
<didrocks> mterry: we can collect lightdm logs in the next run if needed
<didrocks> mterry: this is simple config file
<didrocks> kgunn: can you tell, I'll be 5 minutes late?
<didrocks> mterry: here, you have in archive/ all the delta from the base image
<didrocks> (it's an overlayfs)
<didrocks> as in the logs:
<didrocks> I: Run archived as ubuntu_13.10_saucy_salamander_alpha_i386_20130718.1374153658.otto
<didrocks> mterry: so you want http://10.97.4.139/otto/saucy-i386-20130718-1122/archive/ubuntu_13.10_saucy_salamander_alpha_i386_20130718.1374153658.otto I guess
<didrocks> mterry: this is just a tar, untar it (for some reason, file-roller doesn't like that it's ending up with .otto)
<mterry> didrocks, .otto is weird, yah  :)
<didrocks> and you should have all the delta from the base image
<kgunn> didrocks: ack
<didrocks> mterry: because the archive can be use to rerun the same tests on your machine
<didrocks> :)
<didrocks> it has some metatada ;)
<didrocks> we are using lightdm from distro FYI
<didrocks> which is enough from what robert told
<kgunn> didrocks: lightdm from distro...yeah
<kgunn> it better be :) that's what his instructions say
<mterry> didrocks, well, I downloaded/unpacked the logs and the error we get from u-s-c is:
<mterry> ERROR: /build/buildd/mir-0.0.7+13.10.20130718ubuntu.unity.next/src/server/graphics/gbm/gbm_display_helpers.cpp(284): Throw in function int mir::graphics::gbm::helpers::DRMHelper::open_drm_device(const mir::graphics::gbm::helpers::UdevHelper&)
<mterry> Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
<mterry> std::exception::what: Error opening DRM device
<mterry> [boost::errinfo_errno_*] = -13, "Unknown error -13"
<mterry> So...  didrocks, looks like you have an unknown error.
 * mterry goes home
<didrocks> mterry: thanks! that's helpful :)
<mterry> didrocks, more seriously, I haven't run into an error opening DRM device before
<didrocks> jibel: do you think it's linked to lxc? ^
<mterry> racarr, ^ is that error familiar to you?
<didrocks> mterry: we are running in a lxc container with otto, it's working fine with acceleration for compiz & others
<didrocks> mterry: but maybe this has influence
<mterry> didrocks, maybe a permission error on some udev device in the container?
<jibel> didrocks, it is possible, it is what I reported to thomi last week
<didrocks> mterry: yeah, if you use more than what is used
<didrocks> mterry: any idea what's under used?
<didrocks> use*
<mterry> didrocks, I didn't parse that
<didrocks> mterry: do you know exactly which udev device you need?
<mterry> didrocks, not exactly...  something inside /dev/drm/card[0-9] or some such, looking at code
<didrocks> jibel: do you think we should get stgraber as well to help?
<jibel> mterry, which job did you get this message from?
<didrocks> jibel: 501
<didrocks> /var/log/lightdm
<didrocks> (from the archive)
<mterry> kdub, do you know more about the above error message? ^
<didrocks> mterry: is is that hidden in the code?
<didrocks> :)
 * didrocks tries to branch mir to look as well
<mterry> didrocks, well, it just enumerates some devices and errors out if problems
<mterry> didrocks, so hard to see what's the exact issue by looking at code
<didrocks> mterry: yeah, I wonder how we can debug that, I'm sure it's lxc/udev in lxc which doesn't authorize the right dev/
<mterry> didrocks, build a version with better debugging?  strace it?
<didrocks> mterry: do you want debug symbols? :)
<didrocks> I can have that for you!
<mterry> didrocks, not symbols but just printfs saying what it is doing
<mterry> but stracing would likely be easier
<mterry> just insert that into the jenkins job
<didrocks> mterry: you can get access to the machine if needed
<didrocks> by ssh
<didrocks> and running inside the container
<didrocks> if that's easier than hacking the jenkins job
<mterry> or wherever it launches u-s-c
<mterry> didrocks, maybe, ok
<jibel> mterry, I need to know which device it is trying to access to to see if there are missing privileges, or apparmor blocking access, or a module mismatch, ...
<didrocks> jibel: strace will indeed help, as mterry mentionned
<didrocks> mterry: to run unity-system-compositor, we can do that without any X, just starting from a login prompt, right?
<mterry> didrocks, I think so...?
<mterry> didrocks, I already have ssh access?
<mterry> which machine?
<didrocks> mterry: from magners, it's ssh ubuntu@dx-autopilot-intel
<didrocks> mterry: but we're going to restart the container with this install for you :)
<didrocks> mterry: just need to hack to not have the tests running and the machine staying up
<sil2100> racarr: hi!
<didrocks> mterry: so
<mterry> didrocks, OK, so trying in container, we get mir running
<didrocks> we tried to shutdown the machine
<mterry> unlike on jenkins
<didrocks> and just restart it
<didrocks> mterry: well, unlike on the first attempt as well
<didrocks> mterry: like, when you joined
<didrocks> we restarted it
<didrocks> and there was the error
<didrocks> and so, the fallback was running
<didrocks> it's just since you get it working once that now it's ok
<mterry> My work here is done!
<didrocks> :p
<didrocks> I didn't follow with the pings on IRC, butâ¦
<didrocks> did you change anything in /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf ?
<mterry> didrocks, I commented my change back out
<didrocks> yeah, that's why we see
<didrocks> can it be a race?
<mterry> didrocks, but if you want to run with strace, uncomment the line in there
<didrocks> mterry: see!
<didrocks> mterry: just restarted
<didrocks> it's on your plate \o/\o/\o/
<mterry> didrocks, OK.  Now if we restart lightdm, do we expect to see this error again?
<didrocks> so, more seriously, seems there is a race
<didrocks> I bet we won't
<didrocks> mterry: want to try?
<mterry> Hmm
<mterry> didrocks, OK.  And if it fails, let's add strace, then restart.  Or will that wipe out the config change?
<didrocks> mterry: no, that will keep the config change
<didrocks> so yeah, let's do that :)
<mterry> ok, restart worked-ish
<mterry> didrocks, OK, how to restart?
<didrocks> (I just rechecked)
<didrocks> mterry: just shutdown (like that)
<didrocks> then it archives :p
<didrocks> (my fault)
<didrocks> see the lxc-start command
<sil2100> racarr: (here as well) ping
<didrocks> mterry: it's running, jibel restarts
<mterry> didrocks, sorry, wasn't watching byobu when that all happened :)
<didrocks> mterry: ok, restarted
<didrocks> so it's running again
<didrocks> strace should slows the start enough :/
<mterry> ok, let's see that log
<mterry> didrocks, it looks like it worke
<mterry> didrocks, so yeah, race condition?
<didrocks> mterry: right, I'm sure strace slows it down enough :/
<mterry> didrocks, well...  file a bug and add a sleep 1 in meantime?  :-/
<didrocks> mterry: like sleep && unity-system-compositor in the conffile?
<didrocks> sleep 1*
<racarr> sil2100: Pong
<racarr> Dentist soon sorry but im around for next 30 minutes
<mterry> didrocks, yeah, that could work
<sil2100> racarr: priv then!
<mterry> didrocks, I looked away, did the sleep work?
<didrocks> mterry: we are trying first to see how many times it fails
<didrocks> it's really random
<mterry> didrocks, hmm..  also, for testing sleep, probably better to test higher value than 1 in case that's not enough time
<mterry> didrocks, I'm going to grab lunch
<didrocks> mterry: well, we need to have that merged in unity-system-compositor package as long as we don't fix the race :/
<didrocks> so I'm afraid about the value we would put here
<didrocks> we tried with cold cache, without any difference
<didrocks> (it worked the first time)
<didrocks> ok, without sleep, it started 7 times on 10 trials
<didrocks> kgunn: FYI ^
 * kgunn read most of the scrollback
 * didrocks feels sorry for kgunn
<kgunn> didrocks: so sleep seems to fix it, otherwise 70% working..."randomly"
<didrocks> kgunn: no, we are trying sleep for now
<kdub> mterry, that error (from way up in the /sb) didn't mean anything obvious to me either
<didrocks> and the syntax doesn't support it
<didrocks> we are trying to have a shell calling unity-system-compositor with a sleep
<kgunn> didrocks: so at this very moment you are testing for the reliability of sleep (e.g. u-s-c sleep 1)
<kgunn> ?
<didrocks> kgunn: yeah, with no interesting value right now (we have 100% failures)
<kgunn> didrocks: sorry still confused by your last statement "no interesting value"...what is value ? and didn't you say even w/o sleep you get 70% working ? what config is failing 100% ? (sorry if i am slow minded :)
<didrocks> kgunn: 70% working -> call with no config
<didrocks> 0% working with the sleep, but still trying
<kgunn> didrocks: bummer
<kgunn> didrocks: and by failure we mean...xmir doesn't launch, but rather fallsback to standalone x
<didrocks> kgunn: right
<kgunn> (just confirming that is _still_ the failure mode)
<didrocks> no unity-system-compositor (so no xmir) running
<didrocks> kgunn: yeah, we tested well the fallback work
<didrocks> it's working :)
<didrocks> (that's the bright side :p)
<kgunn> bregma: bschaefer ^ just fyi...mterry helping, but good to know...have you seen this recently on any of your reboots ?
<didrocks> kgunn: FYI, 50% working without any sleep on another test run
<kgunn> e.g. xmir not starting but falling back to x
<bschaefer> kgunn, with a recent update? Or the same problem as yesterday?
<didrocks> kgunn: sleep 1 seems to be a "better" value: 90% passed (on 10 runs)
<kgunn> bschaefer: oh yeah...duh...this is identicle to robotfuel's isn't it....
<bregma> I have never had u-s-c fail to start on reboot on my test machine
<didrocks> kgunn: sorry, no, not the sleep 1, just no sleep but embedding it in a shell
<didrocks> trying with sleep 1 on 10 runs now
<didrocks> it's clearly a race anywayâ¦
<bschaefer> interesting either way ...
 * kgunn wonders....no one ever sees this locally....wondering about kvm monitors
<didrocks> kgunn: do people notice you think?
<kgunn> didrocks: hard to miss the giant-ass mouse missing
<kgunn> :)
<didrocks> kgunn: indeed ;) but you knowâ¦ at least, having a case we can reproduce the race is good
<kgunn> didrocks: sure....its just we've had suspicions about the kvm monitors about other things
<didrocks> kgunn: hum? this is running on bare metal
<didrocks> we are connected directly to ssh on it
<kgunn> didrocks: oh...really, so this is a machined hooked to a normal monitor ? (or embedded lcd)
<didrocks> kgunn: we can remove the kvm daemon, but it's not in the hook at all
<didrocks> we are in a ssh connexion directly connected to it, not using kvm
<kgunn> didrocks: who is "We" & "it"....i guess, i'm trying to get at, is there a display phyically connected to the processor running u-s-c (or attempting to)
<kgunn> ?
<didrocks> kgunn: we == jibel and I right now
<didrocks> we are connected by ssh to the machine
<didrocks> and start/stop lightdm
<didrocks> there is a display physically connected to it
<didrocks> but in lexington
<kgunn> didrocks: got it...
<didrocks> so a little bit far for us to look at it :)
<kgunn> theory busted
<didrocks> right
<didrocks> ok, another run with sleep .1
<didrocks> -> 100% pass on 10 trials
<kdub> would people be ok if we had mir_init_display_info(DisplayStruct*); mir_get_display_info(DisplayStruct*); mir_destroy_display_info(DisplayStruct*); in the client api?
<didrocks> kgunn: so, to be able to move on thisâ¦ what do you think we should do?
<kgunn> didrocks: \o/ ....for sleep 1 or .1 (typo or not)
<kgunn> ?
<didrocks> kgunn: sleep .1 (no typo)
<kgunn> you add to the u-s-c conf file right ?
<didrocks> no, u-s-c config doesn't support && apparently :/
<didrocks> so we call unity-system-compositor.sleep, which is a shell script, with sleep .1; unity-system-compositor
<didrocks> and call unity-system-compositor.sleep from u-s-c conf file
<didrocks> kgunn: I just want to be able to give you one set of test results with xmir enabled
<didrocks> not sure if you want to go that ugly way then ^
<kgunn> didrocks: seems there's enough proof there we know what that issue is....and it should permit more testing
<kgunn> so that would be fine (as it shouldn't alter anything but the startup)
<didrocks> kgunn: so, you want me to MP it?
<kgunn> didrocks: yes...i think so, we know its a dirty hack....we'll have an assoc bug to fix it
<kgunn> not that we have a nice repro capability
<kgunn> bschaefer: what was the pass/fail experience you had yesterday with robotfuel ?
<kgunn> was it on the order of 70% ?
<bschaefer> kgunn, you mean ChrisGagnon?
<kgunn> yes
<bschaefer> right, umm sorry was a bit confused :)
<kgunn> bschaefer: ^
<bschaefer> he was hitting it pretty commonly
<bschaefer> i never asked percentage, and I couldn't reproduce it on my machine
<bschaefer> kgunn, I would say greater than 50% though
<bschaefer> err greater than 50% passing
<kgunn> bschaefer: even better
<kgunn> bschaefer: oh...then about the same
<bschaefer> kgunn, but he'll have a better grabs on the numbers :)
<bschaefer> I only asked about 3-4 machines, but it seemed like he could get a failing one pretty fast
<kgunn> bschaefer: this little work around will at least unblock him
<bschaefer> awesome, adding that .1 sleep in?
<kgunn> bschaefer: yep
<bschaefer> interesting, i remember lightdm having a racing problem before...
<bschaefer> when the machine was super fast, but it could be a different issue :)
<kgunn> didrocks: to make sure i understand....sleep 0 = 70% pass, sleep 1 = 0% pass, sleep .1 = 100% (10 runs each)
<didrocks> kgunn: between 50-70% for no sleep
<didrocks> kgunn: now, shell with sleep .1: 100% pass
<bschaefer> sounds about right (with sleep 0 that is)
<bschaefer> didrocks, awesome :)
<didrocks> kgunn: sleep 1: 100% as well (it was a test issue)
<didrocks> but let's keep .1, it's working
<kgunn> didrocks: cool....better....that was gonna freak me out
<didrocks> bschaefer: well, not that awesome TBH :p
<bschaefer> didrocks, well its an odd workaround, but still a workaround for now
<bschaefer> and you found a way to 100% reproduce :)
<didrocks> bschaefer: no, 30% reproduce the failure (without any sleep) :p
<bschaefer> oo I see it was a test issue
<didrocks> kgunn: https://code.launchpad.net/~didrocks/unity-system-compositor/add-dirty-sleep/+merge/175633
<didrocks> kgunn: I'm opening the bug
<kgunn> didrocks: there's one already open
<didrocks> ah, url?
<kgunn> https://bugs.launchpad.net/xmir/+bug/1201565
<bschaefer> was it htis one: https://bugs.launchpad.net/xmir/+bug/1201565
<ubot5> Launchpad bug 1201565 in XMir "unity doesn't run in xmir session " [Critical,Triaged]
<bschaefer> opps :)
<didrocks> kgunn: hum, doesn't seem to be that one
<didrocks> we don't have unity-system-compositor running, not unity
<kgunn> bschaefer: hmmmm, did we morph this bug on accident...are there really 2 bugs ? or did the unity problem actually go away...
<bschaefer> kgunn, hmm IIRC, that but above was about u-s-c not running, or really just a symptom...
<bschaefer> didrocks, which problem were you looking at?
<didrocks> bschaefer: unity-system-compositor doesn't run
<didrocks> and so, we fallback to legacy X
<didrocks> the bug title you have is unity crashing under xmir
<bschaefer> didrocks, right, thats what that bug is about, as u-s-c doesn't run which was causing unity to now run...
<didrocks> bschaefer: but xmir doesn't start even
<didrocks> bschaefer: which is what the bug seems to be about
<didrocks> and here, we fallback to traditional xorg
<bschaefer> didrocks, right, xmir wans't starting either...but you can't have xmir with u-s-c right?
<didrocks> and unity is running
<bschaefer> didrocks, well I never actually saw the problem happening...it was on a VM somehwere
<bschaefer> or a machine somewhere
<didrocks> bschaefer: your bug is mentionning a crash in unity, which isn't the case here
<didrocks> kgunn: I would suggest keeping the bug separated and see where we can get for more clarity, thoughts?
<bschaefer> didrocks, right... ChrisGagnon is on lunch atm sooo he would be the one I would poke ...
<robotfuel> didrocks: rebooting seems to help starting xmir
<didrocks> robotfuel: we did reboot by a set of 10 times multiple times
<kgunn> i gotta run
<bschaefer> didrocks, though the overall problem with that bug was u-s-c was not starting, and on a second reboot it would start...
<kgunn> iterviewing
<didrocks> bschaefer: why is is associated with xmir then?
<didrocks> bschaefer: xmir even doesn't start at this level
<bschaefer> didrocks, well what we can do, is you can open a bug up, and if we can confirm its the same we can mark it as a dup as the one you open
<didrocks> then, we fallback to xorg
<bschaefer> didrocks, right
<didrocks> and unity start
<didrocks> doesn't crash
<bschaefer> it was black screening on that bug
<bschaefer> err
<didrocks> bschaefer: yeah, sounds a good plan :)
<bschaefer> well actually im not sure if it was, no one actually saw a visual
<bschaefer> didrocks, yeah, Ill poke Chris when gets back, or Ill just take a look at it :)
<robotfuel> didrocks: no I can try that right now though, I have a bunch of machines with it loaded.  the reboot 10 times is a good idea
<didrocks> robotfuel: we did that a lot and have data FYI, one sec, summarizing this
<didrocks> mterry: bschaefer: robotfuel: kgunn: bug #1202752
<ubot5> bug 1202752 in Unity System Compositor "race when starting unity-system-compositor from lightdm" [Undecided,New] https://launchpad.net/bugs/1202752
<kgunn> didrocks: cool
<bschaefer> didrocks, thanks
<didrocks> yw :)
<didrocks> thanks to jibel as well
<bschaefer> jibel, thanks :)
<bschaefer> didrocks, also, it does look a but different
<bschaefer> didrocks, as that error you get, wasn't showing up in the othe rbug
<didrocks> bschaefer: isn't it? :)
<didrocks> ok, better to keep that separated
<bschaefer> didrocks, yup, until we can confirm that its the same, it could be somewhat related, but yeeah
<robotfuel_> kdub: I've found the version of checkbox we are using for ihv's, so I can run it on xmir -> http://certification-static.canonical.com/checkbox-ihv/
<robotfuel_> oops
<robotfuel_> wrong k
<robotfuel_> kgunn: ^
<racarr>  back
<kgunn> robotfuel_: cool....kdub might like to know too :)
<TheDrums> Howdy, just curious, when might 0.0.7 hit the "System Compositor Testing" PPA?
<racarr> Yay ust implemented my session transaction stuff I was fantasizing about yesterday
<racarr> and it does in fact fix the stress test
<kgunn> TheDrums: honestly not sure, we've been laser locked on bugs for entering distro....i meet with the team in a bit, i'll see if we can bump it
<kgunn> racarr: i thot robert_ancell fixed it ?....or were we multi-bugged
<TheDrums> Cool, thanks.
<kgunn> TheDrums: what exactly were you after in the latest? or what is the testing ppa lacking ?
<kgunn> just curious
<kgunn> ...pardon me while i reboot, brb
<TheDrums> kgunn: Latest?  See if any crashing is fixed, or anything like that mainly.  Going to spin up a new ISO for it when it hits and trying to follow the official testing "rules" by not using staging. ;)  (The System Compositor Testing I'd hope is more likely to work, and as I can't actually test it on my hardware all I can do is see if the deps are right while generating.)
<racarr> kgunn: Err, I think we were multibugged
<racarr> well, we have definitely been multibugged
<kgunn> TheDrums: mos def....-testing PPA should totally work....its just a copy of "confirmed" synch'd packages from staging
<TheDrums> That's my idea, only had it once so far where it had unmet depends.  Anywho, was just asking about it, not trying to get into anything. :)
<kgunn> TheDrums: sure...and yeah....we screwed up about a week ago on that one :)
<kgunn> no hiccups since
<kgunn> another reason for getting in distro soon....to escape the ppa madness
<kgunn> ...and rebooting again
<racarr> Late lunch...back soon!
<racarr> mm tacos
<robert_ancell> bregma, so, the armhf builds are supposed to be working now?
<bregma> robert_ancell, as far as I know, tvoss disabled the tests so the packages build
<robert_ancell> bregma, ok, it looks like jenkins is just behind then
<bregma> I'm working with an older branch so I can try to make the tests fail sanely, so I haven't verified the builds myself
<kdub> robert_ancell, so with the changes for ~kdub/mir/display-grouping, the client api has not changed (other than new functions) because we'll support the now-deprecated display query function
<kdub> but the protobuf protocol has changed
<kdub> so the soname for the client should be the same (because there is no abi breakage), right?
<robert_ancell> kdub, correct - I'll re-review
<robert_ancell> src/client/CMakeLists.txt still has the soname bump - is that what you were just about to remove?
<kdub> right, just pushed seconds ago
<robert_ancell> kdub, you can't change DisplayMode in mir_protobuf.proto like that - it will break old clients
<robert_ancell> you either need to extend it and keep the old width, height and supported_pixel_format fields, or make a new message
<robert_ancell> You can rename the fields though if they have the same content as the new fields. Though it looks like width, height and supported_pixel_format no longer exist
<robert_ancell> kdub, http://paste.ubuntu.com/5888893/ shows how you could extend DisplayInfo
<robert_ancell> there's a wire cost of sending the obsolete fields because they were marked 'required'
<robert_ancell> Note the field numbers can never be reused - they form part of what goes on the wire
<kdub> hmm
<kdub> what about Connection going from 'optional' to 'repeated'
<robert_ancell> kdub, that's allowed if it makes sense - an old client will take the first or last (I can't remember which) of the fields and just use that.
<kdub> ah, ok
<kdub> won't we break old clients eventually though and remove those fields?
<robert_ancell> kdub, yes probably. This is a little bit artificial because in practise if probably wont matter. But we've made an API/ABI guarantee so we should get in the habit of doing it right
<kgunn> thomi: mind a review on https://code.launchpad.net/~didrocks/unity-system-compositor/add-dirty-sleep/+merge/175633
<robert_ancell> At least we should have the fallback code and delete it once we know all clients in the wild are updated
<robert_ancell> kdub, it will be easier to make a new message, then drop the old one in the future
<robert_ancell> (than extend the current message)
<robert_ancell> we should really add the version into the connect message and reject old clients once we make that break
<kdub> robert_ancell, but... if a new server is running and an old client connects, the client won't work
<kdub> even if we preserve the right fields
<robert_ancell> no?
<kdub> because the code in the frontend is just talking in terms of the new messages
<robert_ancell> kdub, yes, we have to populate the old fields to be backwards compatible
<kdub> that really complicates everything though :/
<robert_ancell> kdub, is the old supported_pixel_format == the new pixel_format?
<kdub> yes
<robert_ancell> kdub, rather supported_pixel_format = pixel_format[0]
<kdub> sure, that shouldnt have changed
<robert_ancell> and width == mode[0].horizontal_resolution?
<kdub> right, I see what you're saying :) maybe i'm just resistant to deprecated code that has to be supported
<robert_ancell> kdub, it's the cost of having a protocol
<racarr> robert_ancell: kdub: Just being nosy ;) this sounds like it may be a recurring problem over the next month
<racarr> I wonder if we can do something like add a version to connect
<robert_ancell> kdub, this is where it might make sense to make a new connect message
<racarr> and then it can just fail sanely and people need to update their clients
<robert_ancell> and we just reject the old connect message for old clients.
<racarr> I mean obviously we can't break things all the time, but for the time being it's mostly a matter of keeping things sane
<racarr> rather than actually having "clients int he wild"
<robert_ancell> The problem with the changes as you've made them is an old client will interpret the new data incorrectly
<robert_ancell> basically what racarr is saying :)
<thomi> kgunn: sure
<robert_ancell> thomi, I just approved it
<thomi> I see :)
<thomi> looks nice a nasty hack, but *shrug* if it gets the job done :)
<thomi> I ahve so many IRC channels I don't always see when people ping me :-/
<racarr> thomi: Oh btw this is supposed to be
<racarr> the stress test fix )
<racarr> :)*
<racarr> https://code.launchpad.net/~robertcarr/mir/session-transactions/+merge/175669
<thomi> racarr: awesome, will test locally
<thomi> dumb question: can I still run mir natively if I'm running xmir?
<racarr> I...think so?
<kgunn> thomi: i have run democlients while running xmir
<kgunn> it uses the same window thos
<kgunn> though
<racarr> you should be able to run another server
<kgunn> so i had to ctl-c to get my unity back
<thomi> awesome, thanks
<racarr> but you will need to pass -f or something
<racarr> so they dont use the same socket file
<thomi> hmm, ok
<kgunn> thomi: right...what racarr said...otherwise it gloms onto your active mir window
<racarr> then your client has to support that :p
<racarr> we should have an environment variable
<racarr> maybe we do and I forgot
<thomi> kgunn: "gloms" - technical term? :P
<kgunn> thomi: don't think so...
<kgunn> gotta be some slang i picked up from my 15 yr old...
<racarr> yeah we dont' have an environment variable
<thomi> racarr: so I run "mir_demo_server -f /path/to/some/nonexistent/socket" ?
<robert_ancell> racarr, there's MIR_SERVER_FILE
<kgunn> glom = a parasitic type use of
<racarr> robert_ancell: I mean one for the client library
<racarr> thomi: Yes, or mirserver file
<robert_ancell> racarr, ah, ok
<racarr> it would be nice if like
<kdub> robert_ancell, so I guess for now, i'll just support the old messages at the same time
<racarr> MIR_CLIENT_SOCKET
<racarr> if it was set, was the socket used for
<racarr> mir_connect(NULL,
 * robert_ancell hates it's called --file. How vague is that?
<racarr> clients can still specify a socket of course
<robert_ancell> racarr, +1
<kdub> but i think adding versioning to connect in the near future is a good plan
<thomi> robert_ancell: --file-descriptor :)
<robert_ancell> thomi, but it's a path!
<racarr> robert_ancell: mir --the-thing-that-used-to-be-export-display-equals-0=/tmp/bla
<thomi> robert_ancell: a path to a file descriptor, right?
<robert_ancell> mir --socket?
<robert_ancell> thomi, no the name of a socket that will be opened by the server
<racarr> mir --address
<thomi> oh ok
<robert_ancell> mir --client-socket?
<racarr> I like --socket-path
<robert_ancell> racarr, it probably needs to be --client-socket-path because for nested Mir we'll need --parent-socket-path or similar
<thomi> ugh. Can we make ./native_compile.sh run "sudo mk-build-deps -i" at the top?
<thomi> hmm. . pity it needs sudo, and isn't installed by default I guess
<racarr> robert_ancell: Well, for nested mir it should have the same name as this
<racarr> MIR_CLIENT_SOCKET_...
<racarr> variable
<robert_ancell> I guess
<racarr> (the parent-socket-path)
<robert_ancell> so we can use two env variables MIR_SERVER_SOCKET_PATH and MIR_CLIENT_SOCKET_PATH
<thomi> why do you need two variables? Surely they should always be the same?
<racarr> mir on mir
<racarr> It's mir all the way down.
<thomi> ... and we want to do that why?
<racarr> Unity 8?
<racarr> the future.
<thomi> so.. maybe I'm being obtuse, but why is that "mir on mir", and not just "mir" ?
<racarr> same idea as xmir where there is a system compositor
<racarr> and each user session runs in a
<racarr> session compositor
<thomi> ahh, I see
<racarr> and you can spin between user sessions on a burning cube
<thomi> well... that seems very practical
<kdub> robert_ancell, how's this diff for the protobuf file?
<kdub> http://pastebin.ubuntu.com/5888989/
<racarr> thomi: Practically the biggest gain is that the system compositor comes up very very early in the boot process
<racarr> and after tht its flicker free :)
<robert_ancell> kdub, that looks good. I think the DEPRECATED should be on the display_info field, not the display_state right?
<robert_ancell> not the Connection message I mean
<robert_ancell> kdub, and we just omit setting display_info in the new code? Since it's optional we can do that
<kdub> deprecated is on the right field, there's a diff break
<thomi> racarr: so with your banch, the server no longer deadlocks, but it does seem to crash
<kdub> hmm... not sure
<thomi> racarr: and I have to restart lightdm if I want my console back :-/
<kdub> robert_ancell, old clients won't break (eg crash) if we don't set that field, but they won't be able to get any display information
<robert_ancell> kdub, oh duh :)
<kdub> :)
<robert_ancell> kdub, right, so we don't break API or ABI, but we do change behaviour. That's probably acceptable given the state of the project
<kdub> ok
<racarr> thomi: Oh thats a shame
<racarr> I never had a deadlock
<racarr> I just had a crhs
<racarr> crash*
<racarr> Ok well I will try out with my laptop and longer times and
<racarr> stuff
<racarr> this definitely fixes a race though! so
<racarr> ...something!
<thomi> racarr: I just built packages, will install them now and make sure I can replicate
<thomi> I just built locally before
<racarr> It feels like
<racarr> race conditions are more prevalent in the southern hemisphere
<racarr> :p
<thomi> racarr: yup, confirmed it crashes, but it seems to crash when mir_stress is about to exit, not half way through the run
<thomi> racarr: let me know if there's anythign I can do to help you debug this, but I feel like your MP should be 'Needs Fixing' until I can run mir_stress without crashes - do you agree?
<racarr> hmm
<racarr> I guess my thought was merge it, because by inspection it fixes a bug
<racarr> and it's just we have multiple bugs
<racarr> s
<racarr> I have an idea about a crash that could only occur when the client is actually exiting.
<racarr> thomi: in src/server/frontend/session_mediator.cpp ~SessionMediator l66
<racarr> right before if (session)
<racarr> could you add
<racarr> std::unique_lock<std::mutex> lock(session_mutex)
<racarr> outside the scope of the if.
<racarr> That may fix it! If not the most useful info would come from runnign the server with
<racarr> MIR_SERVER_MSG_PROCESSOR_REPORT=log MIR_SERVER_SESSION_MEDIATOR_REPORT=log
<thomi> racarr: that line already exists at that location
<racarr> huh
<thomi> racarr: what about the SessionMediator dtor?
<thomi> does that need a lock as well?
<racarr> thomi: That's what I meant
<thomi> oh
<racarr> shouldn't the if (session) in ~SessionMediator be
<thomi> sorry
<racarr> at l66?
<thomi> I saw l66 as 166
<racarr> ah!
<thomi> :)
<racarr> haha, I was like
<racarr> oh god, I don't even know what branch is what anymore
<thomi> ok, building...
<racarr> Ah :) always feels good to get to the end of my own branch list
<racarr> this
<racarr> eh nvm the thought vanished
<thomi> racarr: nope, that doesn't work either
<racarr> the races around msh::Surface in the  session-transactions branch
<thomi> racarr: when I do that, mir_server hangs, and mir_stress never exits
<racarr> I feel like they have given me a lot more clarity about what the scenegraph needs to do, and whats wrong with the existing interfaces
<racarr> but apparently not that clear because I just completely brain dumped
<racarr> thomi: Ok. Can you pastebin with the two env variables I sent up above
<thomi> racarr: where does the output go?
<thomi> racarr: got it.. trying to pastebin a 5.3MB log file :-/
<thomi> maybe that's a bad idea :)
<racarr> haha oh right
<thomi> hmmm... I now have a 280KB .gz fie.. I'll email it to you
<racarr> I..had some good times with those log files
<racarr> I ended up adding roughly ~15 random printfs with line and thread-id
<racarr> and added thread-id in the logs
<racarr> and used emacs macros
<racarr> to reorder them
<racarr> and did that roughlly
<racarr> 100 times in a row
<racarr> and that was tuesday
<racarr> lol
<thomi> racarr: OK, email sent. let me know if you get it
<racarr> thomi: got it
<thomi> awesome
<racarr> thomi: Does the file really cut off int he middle of
<racarr> disconn...
<racarr> it seems to contain no information :(
<racarr> is that stderr and stdout?
<thomi> racarr: that's stdout, and yeah, it really does cut off there
<racarr> thomi: :( ok I will see if I can reproduce it on some of my other devices
<thomi> racarr: ok, let me know if I can get you anything else
<robert_ancell> racarr, what's the advantage of a transaction over a lock?
<robert_ancell> racarr, ps, are you using emacs?
#ubuntu-mir 2013-07-19
<racarr> robert_ancell: I think it just exposes less implementation detail
<racarr> I mean it's just a lock in implementation right, but the interface to the clients
<racarr> is "perform these operations atomically"
<racarr> and yes, what did my emacs do?
<robert_ancell> racarr, + // from a second thread before input focus is set.xs
<robert_ancell> think you missed hitting ctrl there
<racarr> True!
<racarr> thanks :) fixed in r858
<duflu> Woo... another morning of just fixing conflicts
<duflu> robert_ancell: ping
<robert_ancell> duflu, yep
<duflu> robert_ancell: You mentioned that shortened versions was a possibility: major.minor only
<duflu> I think I agree with that...
<duflu> So long as no one complains that we change major a lot
<robert_ancell> duflu, for the project?
<duflu> Yes
<robert_ancell> duflu, yeah, I like it too. The second number is only incremented if we branch, so for most purposes we only have one number
<duflu> robert_ancell: Or rather the second number represents fixes that don't affect ABI
<duflu> ... ?
<robert_ancell> duflu, then you can't do branches. i.e. if we release Mir 94 in saucy, then we need to fix it, we need version 94.1 because in t-series we'll be on (say) 113
<robert_ancell> So the version become <version>.<branch-version>
<duflu> robert_ancell: I don't understand the problem. Once saucy is released as N.M, it will get updates N.(M+1). T-series is the only distro that will get (N+1)
<duflu> Just like we do for Unity releases...
<robert_ancell> duflu, so what do we do if we release 1.2 in saucy and 1.3 in t-series then need to make a patch to saucy?
<robert_ancell> we can't go 1.3 because that would collide with a newer version. Then we'd have to do 1.2.1
<duflu> robert_ancell: There's no problem if each new distro gets a major rev
<duflu> Numbers are cheap
<robert_ancell> yes they are
<robert_ancell> but there's no need to unnecessarily break ABI every single release which is what this scheme would do
<duflu> ... so it would be 1.2 in saucy (up to 1.X in updates), and 2.Y in T
<duflu> And _eventually_ when the ABI stabilizes, we could stay on the same major and branch to 3 components
<duflu> All the while ABI == major == a single integer
<robert_ancell> there's no need to combine the project version and the three (for the moment) ABIs together into one number
<robert_ancell> it just creates unnecessary work
<duflu> robert_ancell: That's kind of true. But it does create clarity.... Alternatively, see my latest MP comments
<robert_ancell> duflu, I have to go but I updated both MPs
<tvoss_> good morning :)
<tvoss_> RAOF, ping
<duflu> Morning tvoss_
<tvoss_> mlankhorst, RAOF  in case you are around: I noticed that SNA is not enabled by default in the XMir drivers. Is that by accident or on purpose?
<didrocks> tvoss_: hey, ar you going to push today the disable armhf android tests?
<didrocks> are*
<tvoss_> didrocks, sure, I assumed you had done it already, happy to do it, though
<tvoss_> alf_, mind if I set https://bugs.launchpad.net/mir/+bug/1102760 to in-progress?
<ubot5> Launchpad bug 1102760 in Mir "Multi-monitor support incomplete - can't show different images on each screen" [Critical,Triaged]
<didrocks> tvoss_: ah, sorry, I'm more trying to decipher the race right now
<alf_> tvoss_: sure
<didrocks> tvoss_: .1 doesn't seem enough though, just had a case where it's not enough
<tvoss_> alf_, the correct answer is nope :)
 * didrocks will try .5 and give several try to it
<didrocks> tvoss: if you want, I can disable all tests, but I thought you wanted to be more fine grain and I don't know ctest
<tvoss> didrocks, let me see what I can do :)
<RAOF> tvoss: Um, that would be by accident.
 * RAOF checks the packaging branches.
<tvoss> RAOF, I have a custom /etc/X11/xorg.conf to enable sna
<tvoss> didrocks, https://code.launchpad.net/~thomas-voss/mir/disable_acceptance_integration_tests_on_armhf/+merge/175746
<tvoss> RAOF, alan_g|EOD you might want to have a look, too: https://code.launchpad.net/~thomas-voss/mir/disable_acceptance_integration_tests_on_armhf/+merge/175746
<didrocks> tvoss: approved
<didrocks> thanks!
<didrocks> tvoss: I may need to extend the sleep to .5s FYI
<didrocks> just ensuring that all the runs pass
<tvoss> didrocks, not sure if that is enough, we might need to disable unit tests too
<didrocks> (by priority to dailies to finish tests)
<tvoss> so let's see what the builders say
<didrocks> tvoss: ok, I'll rerun a mir build once merged, ok?
<tvoss> didrocks, ack
<RAOF> Hm. Why is it defaulting to UXA? The packaging branch clearly defaults to sna.
<tvoss> RAOF, can you reproduce defaulting to UXA locally?
<didrocks> RAOF: on ati, we have another issue in fact making unity-system-compositor segfaulting
<didrocks> RAOF: libEGL warning: Could not open driver /usr/lib/i386-linux-gnu/egl/egl_gallium.so (libOpenVG.so.1: cannot open shared object
<didrocks> file: No such file or directory)
<RAOF> didrocks: Oooh, really?
<RAOF> That's odd.
<RAOF> I clearly had libOpenVG installed.
<didrocks> RAOF: so, we should install libopenvg1-mesa I think
<RAOF> Yeah.
<didrocks> RAOF: but maybe the deps don't take it
<didrocks> let me see
<RAOF> Actually, that shouldn't be fatal; I think it should go on and load egl_dri2.so
<didrocks> RAOF: so libegl1-mesa:i386                         9.2~git20130628.g6b676e6-0ubuntu0+mir4-jenkins86saucy0
<didrocks> but libopenvg1-mesa:i386                      9.1.4-0ubuntu3
<didrocks> RAOF: weird that shlibdeps doesn't force the latest version
<didrocks> RAOF: we need libopenvg1-mesa from the ppa, right?
<RAOF> We shouldn't, no.
<RAOF> libopenvg1-mesa is installed, then?
<didrocks> RAOF: right, but not the version from the ppa
<didrocks> (you didn't list it in the things to upgrade)
<didrocks> can the ABI has changed?
<RAOF> Yeah, I didn't expect it to be necessary; libopenvg should have a fixed ABI.
<didrocks> RAOF: as soon as the slot is free, I'll retry forcing the upgrade to latest
<didrocks> I was thinking it was the race again, but longer timeout needed on ati
<didrocks> but not the case :)
<RAOF> didrocks: Yeah, thanks. I'm surprised. Looks like this might be a libegl1-mesa-drivers bug (lack of appropriate depends: on libopenvg1-mesa)
<didrocks> RAOF: sounds likely the cause, will keep you posted (I think the slot will be free in 10 minutes
<didrocks> )
<RAOF> Test-building patch series to ensure they build at each commit is annoying.
<didrocks> RAOF: ok, now we get:
<didrocks> ERROR: /build/buildd/mir-0.0.7+13.10.20130719ubuntu.unity.next/src/server/graphics/gbm/gbm_cursor.cpp(46): Throw in function mir::graphics::gbm::GBMCursor::GBMBOWrapper::GBMBOWrapper(mir::graphics::gbm::GBMPlatform&)
<didrocks> Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
<didrocks> std::exception::what: failed to create gbm buffer
<RAOF> didrocks: Hm. What platform is that?
<RAOF> didrocks: Obviously it's ATI, but what chipset?
<didrocks> RAOF: 05:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series]
<didrocks> RAOF: do you want a ssh access to the machine?
<RAOF> didrocks: Sure, why not.
<didrocks> RAOF: prefered ssh public key? ;)
<RAOF> From launchpad?
<didrocks> oui have 2!
<didrocks> seems you are someone who can't decide! ;-)
<RAOF> chris@Ed
<didrocks> ok, grabbing that one :)
<alf_> duflu: alan_g: @remove-graphics-viewable-area, my concern about using *Region is that "Region" has a particular meaning in graphics (an arbitrary collection of pixels) and we are not providing any related operations
<duflu> alf_: Maybe so, but I feel it's closer. So another word... ?
 * duflu reserves the right to not think with so little time left in the week
<alan_g> alf_: duflu: with members "clip_to_screen" and "make_fullscreen" I have a feeling that "screens" might be part of the role/name
<alf_> alan_g: perhaps we should not have *Boundaries/Regions, but completely different names for the too interfaces
<alf_> s/too/two/g
<alan_g> ScreenLayout?
<duflu> alf_: I think Region is most accurate. Qualify it as FooRegion if you like. The word "Boundaries" makes me imagine a set of lines in space, where the line equations are most important, rather than their contents
<alf_> duflu: that was the intention, the boundaries are important, not the contents for these interfaces
<duflu> Desktop?
<duflu> A "Desktop" is the set of all displays rectangles...
<alan_g> My "desktop" is the thing that holds up tea, monitors, paper and pens...
<duflu> desktop->clean(later)
<alan_g> ;)
<duflu> People generally understand "is it on the desktop", and the concept extends to multiple monitors per desktop
<duflu> If you want to steal X/Compiz terminology then it's a "Screen", but that's confusing terminology when "Screen" encompasses multiple monitors
<duflu> Although, arguably, the desktop could be transformed to take up less than the monitor :P
<alan_g> Should we avoid using "screen" then and use, say, "output"
<alf_> alan_g: duflu: I think that the Input(Coordinate?)Boundaries interface makes sense from the input subsystem's (the consumer's) perspective.
<alf_> alan_g: duflu: I am not completely happy with SurfaceBoundaries, give the actual operations that it has, as Alan pointed out.
<duflu> I would still hope for a name that describes the area/region, rather than just its edges
<duflu> Area?
<alan_g> DisplayMap ... clip_to_display()
<duflu> Map has become an overloaded word, methinks
<tvoss_> woot, not a single gpu hang with sna after bios upgrade on x220 while running a complete phoronix test suite
<duflu> tvoss_: There's a new BIOS? Or you were out of date?
<tvoss_> duflu, bios is from May 2013
<duflu> tvoss_: All other possible variables eliminated? :)
<tvoss_> duflu, yes, I'm staring at this for quite some time now ;)
<duflu> tvoss_: Oh, I seem to have installed that BIOS already. No wonder mine has worked... (?)
<tvoss_> duflu, I was actually down to inspecting individual registers of the gpu
<duflu> Eek
<tvoss_> duflu, but: intel_gpu_top is really an awesome tool
<alf_> alan_g: duflu: OK, so how about, InputRegion::bounding_rectangle(), InputRegion::confine(Point) and DisplayOutputLayout::clip_to_output() DisplayOutputLayout::make_fullscreen()/resize_to_output()
<duflu> alf_: Sounds reasonable
<duflu> Though I'm not sure what a "Layout" is. Didn't get that far
<duflu> If you make the change soon, I will abstain on it
<alan_g> "size_to_output()"?
<alan_g> DisplayOutputLayout seems a bit wordy
<alf_> alan_g: DisplayLayout?
<alan_g> DisplayArea?
<duflu> Oh. Yes it was so wordy I didn't understand "DisplayOutputLayout". I did understand "DisplayLayout" (or would "OutputLayout")
<alan_g> DisplayLayout would be OK
<alan_g> OutputRegion?
<alan_g> If it works for input, then why not for output?
<alf_> alan_g: I don't think that DisplayArea/OutputRegion communicate that there are multiple outputs. InputRegion doesn't care about that (yet). Which brings up another point, that these interfaces may need to change names as the needs of shell/input change. This is just a first cut.
<alan_g> DisplayLayout would be OK
<alf_> alan_g: duflu: ok, so it's InputRegion and DisplayLayout (although I still think *Boundaries makes sense, since all these operations are about clipping/checking against/sizing to some boundary)
<duflu> alf_: OK. Please resubmit so I don't have to do any more reviews today :)
<duflu> ... so that it's at least not blocked on me
<alan_g> alf_: Something can have boundaries without being named for them
<alf_> duflu: Feel free to pre-abstain :)
<alf_> alan_g: Sure, but as I mentioned above, in this case the boundaries are more important than that something in terms of what the consumer needs. Anyway, I think both approaches are reasonable, so I am not fussed :)
<didrocks> tvoss|benchmark_: that wasn't enough: https://launchpadlibrarian.net/145330493/buildlog_ubuntu-saucy-armhf.mir_0.0.7%2B13.10.20130719.1ubuntu.unity.next-0ubuntu1_FAILEDTOBUILD.txt.gz
<didrocks> tvoss|benchmark_: at least, it doesn't hang, but unit-tests are segfaulting
<didrocks> tvoss|benchmark_: duflu: alf_: any of you wanting to ack https://code.launchpad.net/~didrocks/mir/disable-unit-armh-tests/+merge/175786?
<didrocks> as per discussion, we disable the tests right now, then before a week pass by, tvoss|benchmark_ promised to work on them again (with some platform-api trick)
<duflu> didrocks: Nothing to see yet :)
<didrocks> duflu: click on the commit :p
<duflu> Also.. don't we usually fix failing tests?
<didrocks> duflu: well, it's been 3 weeks they are failing and preventing us for pushing mir
<tvoss|benchmark_> didrocks, +1
<didrocks> duflu: so no, you don't usually fix failing tests ;)
<didrocks> thanks tvoss|benchmark_! I'll rerun a build again once merged
<didrocks> duflu: so the new deal is "no mir by default until this is fixed"
<didrocks> btw, let me add that on the spreadsheet
<didrocks> tvoss_: mind approving? (not tvoss|benchmark*ed* now? ;))
<duflu> didrocks: I will let the western hemisphere decide. I need to start winding up...
<didrocks> duflu: enjoy your week-end!
<tvoss_> didrocks, want a happrovie?
<didrocks> tvoss_: I would love one! :)
<tvoss_> didrocks, there you are
<didrocks> thanks!
 * duflu also means Greece and Germany even though they're not in the western hemisphere
<duflu> Bah, details
<tvoss_> didrocks, https://bugs.launchpad.net/platform-api/+bug/1203003
<ubot5> Launchpad bug 1203003 in platform-api "The platform api should offer an init method that resolves all required symbols and indicates whether the platform is available or not" [Critical,New]
<didrocks> tvoss_: sounds like the right strategy, thanks!
<tvoss_> didrocks, https://bugs.launchpad.net/mir/+bug/1203004
<ubot5> Launchpad bug 1203004 in Mir "Tests disabled on armhf" [Critical,New]
<didrocks> tvoss_: mir built on armhf
<tvoss_> didrocks, \o/
<didrocks> time for unity-system-compositor ;)
<tvoss_> didrocks, \o/
<didrocks> heh ;)
<robotfuel> kgunn: we have a saucy version of the ihv tests now http://certification-static.canonical.com/checkbox-ihv/
<kgunn> robotfuel: hey thanks
<robotfuel> kgunn: I'll run that on some of the systems today in the lexington lab
<kgunn> robotfuel: good stuff & checkbox is single sign on right? so anyone could run their machine?
<robotfuel> kgunn: I think the machine has to be added to hexr first to show up on c3, but anyone can run checkbox and view the results locally. it also produces an xls spreadsheet of the results.
<robotfuel> kgunn: with the ihv tests there is no need for a network connection
<robotfuel> kgunn: to run it you unpack the tarball cd in to the checkbox-ihv directory then run start_testing
<robotfuel> kgunn: it installs all the required packages and runs checkbox's graphics tests
 * kdub is tempted to just keep overriding MirEvent for sending messages to client
<kdub> but thats probably already overridden too much
<racarr> kdub: I think so! I wish we didn't use it at all
<racarr> for sending messages to the client
<racarr> kdub: The thing is, most messages to the client
<racarr> will eventually need some sort of subscription mask
<racarr> well maybe not :p
<racarr> but I think a lot do, like, the client can "subscribe" to display changes
<racarr> and this way, I think rather than use the mechanism we do now of the MirEvent, which is sort of half out of band
<racarr> to our protobuf IRC, even though it is
<racarr> on the same socket
<racarr> we can model it as a call
<racarr> with multiple responses
<racarr> and then on the client side, I think using
<racarr> more fine grained delegates, i.e. handle_input(MirEvent), handle_display_changed(information), handle_focus_lost
<racarr> etc. is just good loose coupling
<racarr> even though we don't have many events to the client so far
<racarr> it already causes noise in some of the tests
<racarr> where for example, a test which wants to match client input events
<racarr> i.e. "this client gets an A key"
<racarr> has to either mute, or expect, irrelevant events like
<racarr> got Focus, lost focus (because it's a 3 client test)
<racarr> or maybe later like, display changed!
<racarr> and then, what is qtubuntu going to do?
<racarr> qtubuntu_handle_input(Event) switch(event->type) case mouse_event: qtubuntu_handle_mouse_event, case key_event: bla bla. case surface_configuration_event: switch event->surface->attrib...
<racarr> blablabla
<racarr> so I think we should just have
<racarr> seperate delegates
<kgunn> kdub: i think i know why someone did it...but isn't there another way we could flip buffers on our mir gl rendering ?
<kgunn> other than glreadpixels
<kgunn> glreadpixels not good for deferred arch's....it makes you wait for the entire pipe to finish rendering
<kgunn> when, you could run away and do more stuff
<kgunn> also...there is some overlap in processing on the gpu that can be gained (not just the exploiting the cpu side of things)
<kgunn> on a deferred mode arch....you can processing geometry & stuff...of the next frame, while your rendering out the previous frame
<kgunn> thots ?
<kgunn> tvoss_ was seeing some perf hits on galaxynexus with unity8....and i was poking around and noticed that we're doing glreadpixels
<Stskeeps> [21:33] <kgunn> kdub: i think i know why someone did it...but isn't there another way we could flip buffers on our mir gl rendering ?
<Stskeeps> err..
<Stskeeps> sorry, slippage of the mouse
<Stskeeps> (kid on my arm, ..)
<kgunn> kdub: tvoss_ http://forum.imgtec.com/discussion/comment/7821#Comment_7821
<racarr> Where are we doing
<racarr> glReadPixels!
<racarr> besides the snapshot functionality.
<kgunn> racarr: hmmm...now you're making me wonder if i know what i'm talking about :)
<kgunn> maybe that's where it is
<kgunn> gl_pixel_buffer.cpp
<racarr> kgunn: I think it's only for snapshots
<racarr> 90% confidence index ;)
<kgunn> racarr: thanks...i'll poke a bit more to ensure
<racarr> I heard about some galaxy nexus performance problems though
<racarr> so I guess something is going on
<kgunn> racarr: it does make sense tho now that you say it....there's a bunch of copying etc going on
<kgunn> racarr: yeah...i don't think anyone has tried demo shell on nexus4 (if you were feeling  jumpy :)
<racarr> I did last week when it didn't really do anything
<racarr> and it was fine
<kgunn> racarr: and yeah...i know way too many little bastard issues on omap4460
<racarr> I will try again soon ;)
<kgunn> to really worry too much
<racarr> kind of fell out of sync with gerry this week because I missed thursday morning and was distracted by the stress-test wednesday morning
<kgunn> racarr: did you launch an app ? and if so, any perf delta appearant ?
<kgunn> racarr: he mainly bug fixed and put quality goodness into app management
<kgunn> so the ui perf prob wouldn't have changed much
<racarr> It wasn't apparent on nexus 4 or desktop
<racarr> but I also didn't really push it XD
<racarr> at the time it was like "ok lets figure out why nothing shows up on screen..."
<racarr> *hours of furious recompiling*
<kgunn> greyback: ^
<racarr> "Yay it shows up on screen! *flicks aimlessly for a minute*
<racarr> :p
<kgunn> wrt nexus 4
<kgunn> greyback: in case you read scrollback...would be interesting to know...how often you're doing snapshot for apps
<kgunn> that could be a very bad thing (glreadpixels + a copy)
<kdub> kgunn, there is another way
<kdub> (sorry for the delay, was eating lunch)
<MichaelP> when Mir is shiped with the next release. How is it going to be with ati proprietary drivers ?
<kdub> kgunn, nexus4 has similar problems with long glReadPixels performance
<racarr> "There are only two hard things in Computer Science: cache invalidation and naming things."
<racarr> haha, I feel like this speaks to our
<racarr> scenegraph/synchronization data store topic *waves hands*
<kdub> hah
<kgunn> kdub: so that glreadpixels is your trigger for flipping ? or rather is it just for snapshot support (in which case this is ok)....and i tend to agree with racarr that's what this is
<kgunn> enlighten if i'm wrong
<kdub> kgunn, i'm unsure what the question means
<kgunn> kdub: sorry...i am refering to the use of glreadpixels in the code
<kgunn> i am thinking its only relevant to when a shell client wants a snaphot
<kgunn> (e.g. it shouldn;t be called every frame)
<kdub> right, of course
<kdub> the normal render pass does not hit that function
<kgunn> MichaelP: in 13.10 we would be delighted to see proprietary driver support appear from the various vendors
<kgunn> but that's not ours to promise
<MichaelP> kgunn: yeah i know.. distro's like arch you either have to downgrade xorg or use ati beta drivers...
<MichaelP> now whats mir supose to do that xorg don't ?
<kgunn> MichaelP: be younger :)
<kgunn> seriously though....that's one part
<kgunn> being a bit more focused w/o legacy of decades of special interest add-ons will help maintainability
<MichaelP> Sometimes younger is dummer !!lol
<kgunn> and this is all a journey
<kgunn> if you ask what xmir will do...nothing
<kgunn> its about a conservative step of introducing mir into distro, yet with real road miles on it
<kgunn> its easy to keep designing, tweaking, etc...but maturity cannot be delivered like a feature
<racarr> One thing that mir is supposed to do that X doesn't is make sense from the ground up :p
<kgunn> like Orsen Wells said of Paul Masson wine (and if you don't know what that is...then you're the younger of us ;)
<racarr> and shine some sense up the whole stack, as opposed to
<racarr> pushing nonsense and hacks up the whole stack :p
<MichaelP> from what i was reading on google about mir.. was sound like with in the next few releases of other distro's everyone eles wants to switch to wayland
<kgunn> MichaelP: can't learn everything from reading
<MichaelP> Im downloading 13.10 right now to check it out
<kgunn> MichaelP: awesome!
<MichaelP> kubuntu said kwin doesn't support mir
<kgunn> MichaelP: i heard that too...
<kgunn> the beauty of open source...
<kgunn> MichaelP: another thing i think mir is bringing beyond xorg
<MichaelP> But yet i watched a video on google.. with unity.. gnome shell.. kde xcfe useing mir
<kgunn> is that its been built around having an answer on mobile & desktop...
<racarr> xmir :)
<kgunn> using android drivers and then of course mesa
<kgunn> another big decision is server side alloc'd buffers
<MichaelP> I have trouble with the free ati drivers... i use HP laptop... then to watch music video's i plug into my hdmi tv.. So if im in like say gnome.. i have trouble sizing the screen.. on the hdmi
<kdub> racarr, why do input and events come back to the clients with the same callback?
<kdub> is it driven by convenience or necessity? :)
<racarr> kdub: That's what I was talking about earlier
<racarr> I think it
<racarr> 's wrong
<racarr> kdub: If you look 2.5 hours up in scrollback
<racarr> I wrote a bunch on it
<kdub> racarr, ah
 * racarr sets clock ahead 5 minutes
 * racarr beer top flies with a *clang*
#ubuntu-mir 2013-07-20
<MichaelP> I thought 13.10 came with Mir
<bregma> well, 13.10 will be released in 3 months, who can tell the future so well?
<d-snp_> hi :)
<d-snp_> I just upgraded to ubuntu 13.10 and it seems to be working
<d-snp_> but there's a weird bug with the resolution setting is there a commandline tool for repopulating the possible resolutions list?
<d-snp_> when I booted into 13.10, it had VESA resolution, and mirrored displays but everything was 3d accelerated, so the drivers were working perfectly
<d-snp_> I then managed to turn off mirroring, and for my 2nd display I could change resolutions
<d-snp_> so now I have 1 monitor at good resolution, and the other at 640x480
<d-snp_> so I'm pretty sure it's just a gui config bug ;)
<d-snp_> also, out of interest is this mir now running directly on top of the hardware? no x in between?
<d-snp_> root      6516  7.5  0.9 217896 57536 tty7     Ss+  18:12   1:42 /usr/bin/X -core :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
<d-snp_> so X is still running? :(
<d-snp_> am I running mir at all? how will I notice? :P
<TheDrums> You aren't using Mir, no.  You should seek support in #ubuntu+1
<d-snp_> alright thanks
<d-snp_> alright, turns out I did things in the wrong order
<d-snp_> upgrading to saucy for some reason removed the system compositor ppa
<d-snp_> now I think of it, that's pretty obvious, as it probably picks the ppa for your distro
<d-snp_> ok :P
<d-snp_> alright! now I'm in business
<d-snp_> it boots to a screen that says I'm in low graphis mode
<d-snp_> but I can't use my mouse to press ok
<d-snp_> I can use my keyboard to go to another terminal, and chat with you
<d-snp_> the low graphics mode is in alt-f1
<d-snp_> alt-f7 seems to have some left over output from the boot process
<d-snp_> nothing on the other terminals
<d-snp_> plugged my mouse out and in, that worked! :)
<d-snp_> couldn't get out of the configuration window though
<d-snp_> killed it, but don't know how to restart it, instead I ran mir_demo_server, and then mir_demo_client_eglflash etc and those work fine
<d-snp_> it would be awesome if I could get it to do some basic compositing using a simple wm
<d-snp_> is there anything like that?
<racarr> d-snp_: There is something like that coming together as part of unity 8 (wm functionality) :) there is no straightforward way to run it with all the dependencies now.
<racarr> p.s. channel not very active on weekend :)
<d-snp_> I guess that's sort of a good sign, means everyone's fulltime on it right?
<d-snp_> though a pity that there's no basic wm available yet
<d-snp_> I'm reading the source of the render_surfaces example now
<d-snp_> but the c++ is .. awkward :P
<d-snp_> this syntax [&](..) { ... } .. what does that do? :D
<d-snp_> is it like c#'s with( .. ) { ... } ?
<pepper_chico> d-snp_, look out for c++ lambdas
<pepper_chico> that's a capture by reference lambda/closure
<d-snp_> ahhh
#ubuntu-mir 2013-07-21
<jakubo> hi, is there any news? i have been waiting for 0.0.7 to emerge but nothing happened for almost a week now...
<jakubo> i just wonder if my repos are working correctly, beacuase there are hardly ANY updates WHATSOEVER ..?!
<Walther> What's the status of Mir now; is it pushed to saucy yet?
<d-snp> Walther: no, you have to enable a ppa
<d-snp> and it doesn't have a desktop WM yet, so you can only run some demos
<Walther> Hm, i thought you could already replace the default one with mir, and it just fallbacks to x when necessary
<d-snp> you can apparently run XMir, which then runs regular DE's, but I haven't found a tutorial for that yet
<Walther> hmm.
<d-snp> that's their plan for saucy, to have that working transparently
<Walther> Hmm hmm hmm. I'd really be interested in testing real-life scenarios and use with it, pretty sure just demos aren't useful in terms of testing
<Walther> Yeah, I know the plan, i thought they were at it though to some extent. How's the driver support - at least some time ago only option was open drivers
<d-snp> afaik that's still the case
<Walther> I'm personally not a huge fan of the open drivers, the binary ones "just work" way better
<Walther> nod. welp, let's see how and when things progress then
<d-snp> yeah, they claim to have nvidia and amd in on this, hopefully they're going to show what that means soon
<Walther> Mmh.
<d-snp> the api doesn't seem to bad though, I think some people will be making window managers for it in no time
<robert_ancell> thomi, is this your tests failing? http://10.97.0.1:8080/view/cu2d/view/Head/view/MIRSlave/job/cu2d-mirslave-head-2.2check/13/console
 * thomi looks
<thomi> robert_ancell: no, i don't think so
<thomi> brb
<thomi> robert_ancell: I don't see any of the output I'd expect if it were running the autopilot tests
<robert_ancell> ok
<thomi> robert_ancell: ahh, I figured it out
<thomi> robert_ancell: the tests are run in a downstream job: http://10.97.0.1:8080/job/autopilot-saucy-daily_release/543/label=autopilot-ati/testReport/?
<thomi> so yeah, the test failed.
<thomi> robert_ancell: looks like u-s-c wasn't running
<thomi> when it should ahve been
<thomi> *have
<robert_ancell> thomi, are you familiar with the daily release into universe process?
<thomi> robert_ancell: otp, brb
<robert_ancell> k
<thomi> robert_ancell: hey, I'm somewhat familiar, depending on what you'd like to know
<robert_ancell> thomi, ok, I followed didrocks instructions and ran cu2d-run to manually publish.
<robert_ancell> The bot made a MP with the debian/changelog changes and they got merged
<thomi> ok
<robert_ancell> But I'm not seeing anything show up in https://launchpad.net/ubuntu/+source/mir, or the queues
<robert_ancell> So I'm not sure if there's anything more to do, or it's failed or what
<thomi> robert_ancell: hmmm, I'm not sure - that part is outside my domain I'm afraid
#ubuntu-mir 2014-07-14
<RAOF> WTF Linux?
<RAOF> If I get interrupted in the middle of recvmsg while receiving file descriptors do you _really_ dup() all those descriptors and give them to me twice?
<duflu> RAOF: dup would mean different fd values... ?
<RAOF> duflu: Precisely.
<duflu> Umm kay
<RAOF> YES
<RAOF> This is, obviously, somewhat awkward.
<duflu> RAOF: Could you take a glance at this? https://code.launchpad.net/~mir-team/mir/fix-1339700-take2/+merge/226534
<RAOF> duflu: Sure.
<RAOF> duflu: Why do you think that âwhile(count > 0) cv.wait(lock);â would be more efficient than âcv.wait(lock, [](){ count > 0 });â?
<duflu> RAOF: Because there's no lambda required. No callback into one, no inlining, and no extra work for the compiler. So even if it could be made as efficient as the "while" syntax it would still require a lot more work by the compiler to do so
<duflu> Not to mention it's easier to read. There's always a loop to wait on a condition, so it's nicer to get people to read it as "while (something)" instead of "do_stuff(until not cond)"
<RAOF> I don't know; wait(for_thing) pretty easy to understand.
<duflu> After optimizations it should generate the same code. But the while syntax is even easier to read, and requires no compiler optimization effort to generate optimal code
<RAOF> Roughly the inverse code, but pretty much, yeah.
<RAOF> However, I think the lambda code is easier to read.
<RAOF> So, personal taste :)
<duflu> I did notice at some point in the past (Mir) developers preferred reading all logic lef-to-right in long lines. Prior to that most developers read top-to-bottom
<RAOF> At a guess, that'd be the influence of functional programming..
<RAOF> The lambda asserts state, the loop describes how to get that state..
<duflu> RAOF: I think "while()" is a more reliable assertion in C-anything. But that's just me I guess
<duflu> It's also clearer that the condition is tested while locked (and must be)
<RAOF> It's not really an assertion, though; it's a proceedure.
<duflu> RAOF: Knowing bare minimum about the C language it is a logical assertion :)
<duflu> while (A) B; means A is no longer true after
<duflu> And then, lunch
<RAOF> Of *course* I can't reproduce that bug now that I've got some debugging in place. How stupid of me to presume I might be able to..
<greyback> alf_: hey, nested servers GL contexts - they are not getting alpha buffers are they?
<greyback> alf_: no they can, it just seems I'm not configuring things correctly to get a gl context with alpha
<greyback> a nested server has the RGBA of the nested gl context decided based on the current format of the display output.
<greyback> it seems the format QtComp is getting does not have alpha enabled
<greyback> Qt also reports that the GL context it is getting has no depth of stencil buffers either - which is odd, as I would expect rendering errors as a result, but visually it looks ok
<greyback> depth _or_ stencil
<alf_> greyback: Are you referring to a context you get with mg::Display::create_gl_context() or the one that is current when you make_current()
<greyback> alf_: an excellent question
<greyback> alf_: yeah I'm referring to mg::Display::create_gl_context()
<alf_> greyback: Ok, I see that's broken, it always returns zero alpha
<alf_> greyback: (broken for nested)
<greyback> alf_: ok, that was confusing me. Thanks!
<alf_> greyback: what behavior do you need?
<greyback> alf_: I just want to read the RGBA/depth/stencil buffer sizes into Qt. But I was doing that for a temporary context I created with mg::Display::create_gl_context - so Qt thought it had no alpha/depth/stencil buffer
<greyback> but instead I can just read that from the current context when I call make_current()
<alf_> greyback: do you get alpha for the context you get from make_current()?
<greyback> alf_: I need to check, but I think so yes
<alf_> greyback: as you mentioned, by default the surface/context RGBA a nested server uses matches the format of the real output framebuffer (in the system compositor), which is probably RGB. You can override this with the_display_configuration_policy(). Not sure if unity8 already does this. For depth/stencil you need to override the_gl_config()
<greyback> alf_: we override the_gl_config() anyway
<alf_> greyback: that's only for depth/stencil though
<greyback> alf_: indeed. So you recommend we override the_display_configuration_policy too? In unity8?
<alf_> greyback: question is, why do you need alpha for unity8's surface?
<greyback> alf_: we don't actually. Qt does complain if depth & stencil missing though
<alf_> greyback: ok, but you set that with the_gl_config(), so I am confused about the actual problem...
<greyback> alf_: there may not be an actual problem, aside from what is returned by mg::Display::create_gl_context not being what I expected
<kgunn> mterry: hey, are you available for some help/thots on debian control file changes?
<mterry> kgunn, sure
<alf_> mterry: Hi! I noticed that in USC trunk we are waiting for two frames to be posted before marking a session as ready. Is this a workaround for some unity8 issue?
<mterry> kgunn, is this more ABI breakage stuff?  :)
<mterry> alf_, it was a workaround for *something* -- without that we'd get black frames first.  Either Qt or Mir or some driver code was posting black frames
<kgunn> mterry: nope, more like shuffling some libraries around to make them shared libraries
<kgunn> https://code.launchpad.net/~mir-team/mir/libmirshared/+merge/226670
<alf_> mterry: ok, I guess I should keep it in the refactoring then :)
<kgunn> mterry: ...oh, and alan_g brot up this bug...so maybe it is
<kgunn> https://bugs.launchpad.net/mir/+bug/1293944
<ubot5> Ubuntu bug 1293944 in Mir "Mir deb packages with versioned names cannot be installed simultaneously any more" [Medium,Triaged]
<kgunn> but the discussion started with the mp :)
<kgunn> and adding packages to the control
<mterry> kgunn, so you need to add a new libmirshared1 package?
<kgunn> mterry: yeah, effectively....and instead of just reading
<kgunn> https://www.debian.org/doc/debian-policy/ch-controlfields.html
<kgunn> and hoping to get it right, alan_g was wanting someone with some experience to possibly guide
<mterry> kgunn, k
<alan_g> mterry: there's more problems there than just adding a new library. We've existing libraries that ought (AFAICS) to be versioned.
<mterry> alan_g, hello!
<alan_g> mterry: hi
<mterry> alan_g, like libmirplatform
<alan_g> yes
<alan_g> and mesa/libmirclientplatform.so
<alan_g> and android/libmirplatformgraphics.so
<mterry> alan_g, so many ABIs!
<alan_g> I can (mostly) sort out the cmake side of things but the packaging files are "magic"
<mterry> alan_g, well, since you'll be changing the name of the files it installs (they'll have ABI version numbers now), you at least get to avoid the pain of breaks/replaces
<mterry> alan_g, do you have a branch that does the cmake side of things?
<alan_g> mterry: I started with the new library. Not touched the existing ones yet. (Was trying to understand things first.)
<mterry> alan_g, ok, let me look at existing packaging and recommend a thing
<kgunn> mterry: yeah, thanks...i was thinking a brief review of where we are would be helpful
<alan_g> And, maybe mesa|android/libmirplatformgraphics.so doesn't matter as it implements an API defined in libmirplatform.
<mterry> alan_g, so libmirshared would be in practice an internal library, right?  no -dev?
<mterry> alan_g, none of these libraries have .symbols files  :(
<alan_g> mterry: I think it needs a -dev - as there are headers
<mterry> alan_g, are they public headers though?  Like, will third-party packages build against it?  Doesn't hurt to have them be public, but just asking
<alan_g> there are public headers (I'm looking to see how these get published now)
<alan_g> Ah! they are installed by mircommon-dev.install
<mterry> alan_g, ah... hm.  So you'll have to add a breaks/replace on libmirshared-dev
<alan_g> Or rename to libmircommon ;)
<alan_g> Which would work
<mterry> alan_g, fair
<mterry> alan_g, you'd probably want to rename mircommon-dev to libmircommon-dev then
<alan_g> So that would need a replace anyway?
<mterry> alan_g, yeah for its old name.  You might want to do all of Provides/Conflicts/Replaces for the old name, so the old package is removed on upgrade
<alan_g> mterry: and I can just add "libmircommon1 (= ${binary:Version}), " to that and the libraries that use it?
<mterry> alan_g, well not to the libraries that use it, they'll have automatic dependencies created by shlibs:Depends
<mterry> alan_g, but for libmircommon-dev, yes
<alan_g> OK. I'll try that for now. Is there an easy way for me to test/validate my changes?
<mterry> alan_g, try an upgrade from a PPA and make sure it installs new packages fine and removes the old package...
<mterry> alan_g, or you could use dpkg -i locally and make sure it complains correctly, but it won't automatically remove package, it will just error out
<alan_g> mterry: I'm not at all familiar with packaging - how do I get it on a PPA?
<mterry> alan_g, do you have a PPA associated with your LP user?
<alan_g> Not if I had to do something to get one
<alan_g> I see "Create a new PPA"
<mterry> alan_g, yup, do that
<mterry> alan_g, just make some random testing PPA for yourself
<alan_g> done
<mterry> alan_g, OK, now when you're ready, you can build a source package locally with debuild -S
<alan_g> from the checkout root?
<mterry> alan_g, yeah
<mterry> alan_g, and then do...  dput ppa:alan-griffiths/NAMEOFYOURPPA ../mir_VERSION.changes
<mterry> ah, junk-ppa I see
<mterry> :)
<alan_g> mterry: Sorry to keep bugging you. "debuild -S" gets as far as debsign: gpg error occurred!  Aborting...
<mterry> alan_g, oh right...  do you have a gpg key that LP knows about?
<alan_g> mterry: yes
<mterry> alan_g, OK
<mterry> alan_g, so do "dch -i" and put some dumb comment in there, make sure to change UNRELEASED to utopic
<mterry> alan_g, then try debuild -S again
 * alan_g looks guilty - he's still on trusty
<mterry> alan_g, trusty!  tsk tsk  :)
<mterry> alan_g, you can still push to the PPA from trusty, but you won't be able to test the upgrade path on your local machine that way
<dandrader> dednick, is a MirPromptSessionEvent event tied to a surface? ie. does it happen in relation to a specific surface?
 * dandrader clueless about prompt sessions
<dandrader> alan_g, you there?
<alan_g|EOD> dandrader: not really
<dandrader> racarr__ ping
<dednick> dandrader: not tied to the surface
<dednick> dandrader: go directly to the client prompt session.
<dandrader> dednick, oh....
<racarr__> dandrader: Hi :) welcome back
<dandrader> racarr__, hi
<dandrader> and thanks :)
<dandrader> racarr__, so in mir, MirEvents are always tied to a surface, right?
<alan_g|EOD> mterry: something still went wrong - but I'll deal with it tomorrow
<dandrader> racarr__, or at least that's what it seems to be from reading the client api
<mterry> alan_g|EOD, k, poke me when I'm online
<dandrader> racarr__, ie, MirEvents are always and will always be directed to some MirSurface of some client. i.e., the client never gets a MirEvent directly from the MirConnection or something. always through the handler set by mir_surface_set_event_handler
<racarr__> dandrader: That sounds right to me
<dandrader> racarr__, ok. but then we have MirPromptSessionEvent in MirEvent...
<dandrader> racarr__, which, as dednick said, is not tied to a surface
<racarr__> hmm I missed that
<racarr__> *looks*
<racarr__> dandrader: I wonder if those are just consumed in the client library? i.e. the lambda in MirPromptSession::MirPromptSession in the client library.
<dandrader> racarr__, which then generates a mir_prompt_session_state_change_callback call to the api user?
<racarr__> dandrader: SEems right
<dandrader> racarr__, I guess so, but then it seems wrong to me to have that in a MirEvent which is supposed to contain events that reach the api user through mir_event_delegate_callback
<dandrader> racarr__, would be like it's exposing an implementation detail to the API user
<dandrader> racarr__, right?
<racarr__> dandrader: I would agree yes
<racarr__> I am not a MirPromptSession expert so to speak lol
<dandrader> racarr__,  me neither. will talk to dednick tomorrow
<racarr__> but yeah...I think MirEvent is a strange chocie
<racarr__> ive always felt it was strange to put
<racarr__> anything besides
<racarr__> Input events in "MirEvent"
<dandrader> racarr__, even surface resizes?
<racarr__> I kind of think its better if you just have
<racarr__> resize events or surface events or whatever
<racarr__> but there is no need to group them all in the "all in one event"
<racarr__> struct
<dandrader> racarr__, you do if they are going all to be sent to the same callback
<racarr__> maybe they shouldnt be though because
<racarr__> the callback kind of has funny semantics right, i.e. called from different threads
<racarr__> depending on the event type.
<dandrader> racarr__, hmm, I think it's more like a design choice: "have 1 callback  and put a type field in the event" or "have one callback per event type and remove the type field"
<dandrader> historically the first option is more popular
<racarr__> I think its kind of a misguided attempt to save typing
<racarr__> at the expense of a small amount of coupling (e.g. in ABI breaks) between
<racarr__> what could be unrelated structs
<racarr__> lol
<racarr__> but in this situation it probably doesnt matter much
<racarr__> </lunch>
<racarr__> yay
<racarr__> finished one pass through the whole QPA
<greyback> racarr__: thanks!
<greyback> racarr__: do you have review comments?
<racarr__> greyback: Just mailed them
<racarr__> greyback: The most concerning thing for me is some of the signal usage
<racarr__> and things that look like Q_EMIT address-of-value-reference-passed-by-mir
<greyback> racarr__: what line numbers are you using?
<racarr__> oh sorry I think all line numbers are in
<racarr__> the respective implementation file
<racarr__> for
<racarr__> the class in latest rev
<greyback> racarr__: ah those are the class name
<greyback> ok
<racarr__> yes sorry my review strategy
<racarr__> was I wrote down all the classes
<racarr__> shuffled them in to a random order
<racarr__> and then started reading
<racarr__> lol
<racarr__> oh also paste
<racarr__> is a little alarming
<greyback> Q_EMIT of pointers to mir objects done with care, the objects those pointers point to, qtmir has a shared_ptr to, so the pointer should always be valid
<greyback> racarr__: I /think/ paste is what we've had in unity-mir for some time :)
<racarr__> yes ive just never reviewed it before lol
<racarr__> it seems like it hsould at least have the focus check
<greyback> focus check?
<racarr__> You shouldn't be able to paste unless you are focused at least right
<racarr__> otherwise why not just paste all the time and see what you get
<racarr__> lol
<racarr__> I saw  some of the Q_EMITs had comments like in SessionAuthorizer...but for example SurfaceConfigurator::attribute_set
<racarr__> if someone connects to that with a queued signal it could crash right?
<greyback> true. sadly there's no way to enforce a direct connection
<greyback> but I think that class will go away, since now there's the SurfaceObserver
<racarr__> oh yeah that should go away
<greyback> requestAuthorizationForSession "but it seems like this non blocking behavior requires code connecting to the signal to make the right choice."  - it does indeed
<greyback> one needs to use a direct connection to that signal to properly authorize sessions
#ubuntu-mir 2014-07-15
<duflu> RAOF: When I sleep the phone clients correctly scale down to 10Hz. Do we have sleep/resume messages yet?
<duflu> ... because obviously clients should be told to sleep properly
<RAOF> I believe so?
<duflu> RAOF: I don't see any Mir*Event
<duflu> Oh hang on
<duflu> No, can't see it
<duflu> RAOF: Were we planning on utilizing any GL error codes?
<RAOF> No
<duflu> Or does that require Khronos changes/blessing?
<RAOF> We could absolutely do it, but I think we ended up deciding that it's not an EGL thing.
<duflu> OK. What I do remember is that argument being complex enough I don't want to remember it right now
<RAOF> Man, this is going to provoke conflicts with _everything_
<RAOF> Oh, _arse_
<RAOF> We can't hide anything.
<RAOF> Because we expect (server) clients to subclass DefaultConfiguration, which means they need to be able to resolve everything that DefaultConfiguration includes.
<RAOF> Hm.
<RAOF> Doesn't that make much of the headers in src/ implicitly ABI?
<RAOF> (The _best form_ of ABI)
<duflu> RAOF: Hey it looks like Android-input drops/deduplicates events when we're not keeping up
<duflu> That's good... we don't have to do anything
<RAOF> Huzzah!
<RAOF> Sweet. So, I very nearly have a libmirclient with an ABI equal to the ABI we expect to expose..
<alf_> RAOF: @break-out-rpc-transport, so ancillary socket data are queued separately from normal socket data?
<RAOF> alf_: Correct.
<RAOF> It's all very complicated.
<RAOF> If you sendmsg(300 bytes, 1 fd), send(300 bytes) and recvmsg(600 bytes, <some fds>, MSG_WAITALL) your recvmsg will read 300 bytes and 1 fd.
<RAOF> If you sendmsg(300 bytes, 1 fd), send(300 bytes) and then recv(301 bytes), you'll (a) receive 301 bytes, and (b) never be able to get at that fd.
<RAOF> For added annoyance, if you recvmsg(300 bytes, <some fds>, MSG_WAITALL) *and get interrupted* you'll receive some data < 300 bytes and an fd, and your next recvmsg will receive the fd again.
<RAOF> That seems likely to be a bug, though.
<alf_> RAOF: What about MSG_TRUNC ? Is this when we sendmsg(300,2) and recvmsg(300,1) ?
<RAOF> MSG_CTRUNC, yeah.
<RAOF> Well, as long as you haven't run into CMSG_SPACE aliasing :)
<alf_> RAOF: (trying to understand how queuing ancillary data works), if we sendmsg(300,1) and recv(299) is the fd lost?
<RAOF> I don't think so, no.
<alf_> RAOF: or do we need to move on reading to a subsequent message for the fds to be discarded
<RAOF> We need to move on to reading a subsequent message.
<RAOF> I don't think there's a test for that behaviour in the unit tests, though.
<alf_> RAOF: I wonder how the fd-data association is maintained since we are using a stream socket, so no strict message boundaries
<RAOF> alf_: There are message boundaries in the kernel.
<alf_> RAOF: true
<RAOF> Internally it's got a bunch of skbs, and SOCK_STREAM just reads on to the next one when the current one's done.
<alan_g> RAOF: I don't need to keep you late, but if you have time to help with packaging...
<RAOF> alan_g: Just commenting now :)
<RAOF> alan_g: Oh, and other than the CI failure bit, the packaging seems fine.
<alan_g> RAOF: thanks for looking.
<RAOF> alan_g: By the way, I've stripped all those symbols out of libmirclient locally by way of symbol visibility; we could probably do the same for libmirplatform..
<alan_g> RAOF: but what about client code that needs the symbols?
<alf_> RAOF: how does that work with testing (where we may need access to some of the internal symbols)?
<RAOF> alf_: I build a couple of things twice.
<RAOF> alan_g: What client code would need those symbols?
<alan_g> RAOF: Hmm. I was assuming that as the headers were published they were already needed in our public API
<RAOF> Right, but not from libmirclient.so
<alan_g> And we do use them in examples of "how to use Mir"
<RAOF> But, again, not from libmirclient.so
<RAOF> These symbols aren't being hidden from libmirserver.so, but we were *also* exporting them from libmirclient.so.
<alan_g> Hmm. So we could put them all into libmirplatform (and export then) and also put the ones used into libmirclient that it uses (internally). That could avoid the new lib
<alan_g> Could we also remove mircommon-dev from libmirclient-dev?
<RAOF> Possibly?
<RAOF> EOD for me today though, sorry.
<RAOF> I'll push the branch
<RAOF> You're looking for lp:~raof/mir/symbols-file. It's still a little WIP.
<alan_g> RAOF: ak
<alf_> RAOF: scenario sendmsg(300, 1) sendmsg(300,1) recvmsg(300, 0) recvmsg(0, $Y) Y == ?
<alf_> RAOF: i.e. if we ask for Y=1 fd will we get MSG_CTRUNC, or do we need to read at least one more byte to get into the next msg in order to get access to the second message's fd?
<alf_> RAOF: I guess we need to experiment
<alan_g> mterry: After emailing you I removed the "Conficts:" to see if CI would then work.
<mterry> alan_g, ah ok
<alan_g> AFACS the build script is using dpkg directly. BUt I don't know much about it
<alf_> anpok: You mentioned something about showing the previous frame instead of current?
<alan_g> mterry: I need advice. Removing "Conficts:" seems to satisfy CI (but is probably lying), and some documentation suggests "Break:" as a possible alternative.
<mterry> alan_g, yeah...  Breaks is I think generally recommended over Conflicts except in some cases I can't remember. But the documentation I was looking at used Conflicts so I recommended that on to you
<mterry> I'm honestly not super clear on the difference
<alan_g> mterry: how bad is it to have neither?
<mterry> alan_g, if they share files, it is bad but I don't quite know in which circumstances it will break
<mterry> alan_g, one of those things I've never gone against recommendations for :)
<alan_g> I'll try "Breaks" and see if CI breaks. If it works I know what to do. If it fails... I'll consult another expert (RAOF)
<anpok> alf_: yes
<anpok> it was best to notice inside the pin entry dialog
<anpok> I had a devel-proposed image + qt comp silo, removed the silo then upgraded
<anpok> i mean I upgraded the image..
<anpok> and it was easy to reproduce in the pin entry
<anpok> after another round of flashing devel-proposed the issue is gone
<camako> mterry, once upon a time you asked for nested lifecycle event support :
<camako> https://code.launchpad.net/~cemil-azizoglu/mir/nested_lifecycle_events/+merge/224426
<kgunn> in a galaxy far far away
<tedg> dednick, So I thought when we were talking with mdeslaur that we wanted the second socket AND a list of people to connect.
<tedg> The second socket takes care of the connection restriction aspect.
<tedg> But we still want to know who is connecting and if they're someone we expect.
<tedg> That being said, that was my understanding, if mdeslaur is willing to sign off on not having the list, I'm happy not having to make it. :-)
<mdeslaur> there's not way of validating the list
<mdeslaur> we assume whatever is connecting there is trusted
<dednick> tedg: ^ yeah. no point if you can get around it...
<mdeslaur> tyhicks could confirm
<tedg> K
<tedg> It seems a bit odd to me.
<tedg> I guess in the future we'll restrict that socket to only being able to make trusted prompt sessions.
<racarr__> Morning
#ubuntu-mir 2014-07-16
<RAOF> Really, gcc? If you use C++, even if you intend to expose a purely C ABI, you are compelled to expose random std:: detritus too?
<RAOF> Why, hello there!
<RAOF> Quite clearly nobody actually suse the mir_debug_* symbols, because they're mangled.
<duflu> RAOF: Umm, worthy of a bug report maybe
<RAOF> Or I'll just fix it.
<duflu> Or both at once...
<duflu> If it never worked then it's not a regression. If no one ever used it then maybe not important enough to be a bug :)
<duflu> Hey gdb understands STL containers now and makes them readable
<duflu> that's new
<RAOF> Oh, the python support got fixed?
<anpok_> @duflu: https://bugs.launchpad.net/mir/+bug/1275398 afaik this is the issue with i915 using a slightly different init code in mesa than the newer intel. so it needs some mir love
<ubot5> Ubuntu bug 1275398 in Mir "i915 driver/i945 hardware: Mir GL clients are rendered as black or transparent windows when using i945 graphics" [High,Triaged]
<duflu> anpok_: Please apply love where appropriate
<duflu> Umm.
<duflu> You know what I mean
<anpok_> :)
<anpok_> i am strugling still with qxl
<anpok_> it does page flip
<anpok_> it seems to drop the page flip event to the event queue
<anpok_> user space seems to get woken up but there is no page flip event
<alan_g> RAOF: @"we don't want to install these into the global library search path" - if not then how does client code access the symbols in e.g. libmirplatform?
<RAOF> Via libmirserver?
<RAOF> We currently dlopen them from libmirserver, right?
<RAOF> Then the (server) client code never needs to directly link against libmirplatform?
<alan_g> Nope. The point of libmirplatform being LGPL is that it doesn't require client code to link against the GPL libmirserver
<alan_g> BTW I like the idea of introducing .symbols
<RAOF> Ooooh!
<alan_g> we do dlopen [mesa|android]/libmirplatformgraphics.so - so it could work for those
<RAOF> By âclient codeâ in this case you mean âplatform driversâ?
<alan_g> For this example, yes
<RAOF> What else is going to require symbols from libmirplatform, and not also link with libmirserver?
<alan_g> true. But by "client code" I mean drivers, servers, client, etc
<RAOF> There's a separate libmircilentplatform, right?
<alan_g> There is
<RAOF> Anyway, the answer to the question âwhere would they get their symbols fromâ is âfrom the thing that's dlopening() themâ
 * alan_g is still confused why some things are .so and some are not.
<RAOF> I think the state we _want_ to be in is having exactly two SOs - libmirserver.so and libmirclient.so
<alan_g> For servers & clients maybe. But drivers introduce a third case
<alan_g> And I would prefer to share common code than link it into all three.
<alan_g> Or four if there's really a good reason for libmirclientplatform.so being different from libmirplatform.so
<RAOF> Drivers don't need to link against anything Mirish; they get dlopen()ed, so they always have the symbols available.
<RAOF> Drivers are never useful outside the context of a mirserver instance
 * RAOF is somewhat foggy, so may in future disown current statements :/
 * alan_g is not going to argue now but doesn't feel quite convinced
<RAOF> I'm a bit annoyed that libstdc++ means that libmirclient exports >1000 symbols, rather than the ~10 or so we *actually* want to export.
<duflu> RAOF: Yeah I was wondering how you were going to solve the template problem. Particularly since libmirserver needs many of the template instance symbols exported
<alan_g> I think it's a lot more than 10 (but a lot more less than 1000)
<duflu> I think you will find it will be higher than 1000, I expect
<duflu> Templates are evil things
<duflu> A tip for counting unique templates: Search for "::~" to identify unique destructors
<RAOF> alan_g: Yeah, more like 50, true.
<RAOF> duflu: I gave up touching libmirserver. Practically every cpp file is a part of the ABI there.
 * RAOF started trying to hide what look like purely internal classes, but it turns out that they're not purely internal.
<duflu> RAOF: I think a better place to start on mirserver is search the headers. You can quickly find a bunch of classes/headers that are unreachable by the public interfaces
<duflu> "unreachable" meaning we don't provide any APIs for people to access instances of said classes
<alan_g> RAOF: my feeling is that libmir[client]platform is already stable (if not pretty) and a better measure for driver compatibility than the volatile server ABI
<RAOF> duflu: That's what I did; it's not true that they're unreachable by public interfaces.
<duflu> RAOF: Well, some, not all, obviously
<RAOF> I don't think any of them are unreachable by public interfaces, actually.
<duflu> RAOF: There used to be plenty. But I haven't made a stab at it for a long time
<RAOF> At least by my criterion of âif I apply visibility=hidden to this class, does everything link?â
<duflu> Given the number of headers has increased, I doubt they're all actually needed in public now
<alan_g> RAOF: meaning tests that access "internal" classes?
<duflu> RAOF: Obviously Mir needs those headers. I'm talking about headers no external project wants/can utilize
<RAOF> alan_g: No, meaning mir_demo_server.
<anpok_> well we can safely hide those not in include
<anpok_> oh
<RAOF> anpok_: Ba baw! Incorrect!
<anpok_> our examples do that?
<duflu> Because we rejected the idea of separating "shared" headers from "public"
<alan_g> We should be able to hide those not in include
<RAOF> anpok_: Because we expect people to derive from DefaultServerConfiguration, so everything that DefaultServerConfiguration touches needs to be public.
<RAOF> And by âpublicâ I mean âlinkable toâ.
<duflu> Ah the ServerConfiguration beast
<alan_g> Why?
<anpok_> RAOF: sure? but for those forward decls should sufficient
<RAOF> Not at link time.
<anpok_> +be
<duflu> Although public projects only need access to classes used in public methods of *ServerConfiguration
<duflu> I mean used in public declarations
<alan_g> RAOF: yes, at link time
<RAOF> You can't have an object with fields that have visibility less than the object.
<alan_g> But the fields only need the forward decls
<duflu> Sounds like we may have exposed too much info in *server_configuration.h"
<alan_g> Certainly more than I think we do
<RAOF> So, empirically, if you stick a bunch of visibility=hidden attributes on classes with headers in src/server, mir_demo_server_* cannot link.
<alan_g> We *should* be able to do that. I don't think the root cause is DefaultServerConfiguration - but will need to investigate.
<RAOF> Because the class derived from DefaultServerConfiguration needed a bunch of symbols.
<duflu> camako: The merge will be instantly redundant if we shuffle the development focus back to 0.5. We can now that 0.5 actually has a branch
<RAOF> Yeah, I'll push this branch at some point.
<duflu> camako: And then there's no waiting for Jenkins ;)
<RAOF> Here we go...
<RAOF> CMakeFiles/mir_demo_server_shell.dir/__/server_configuration.cpp.o:(.data.rel.ro._ZTCN3mir8examples19ServerConfigurationE0_NS_26DefaultServerConfigurationE[_ZTVN3mir8examples19ServerConfigurationE]+0x2d0): undefined reference to `mir::DefaultServerConfiguration::the_input_registrar()'
<RAOF> And a thousand others.
<RAOF> But EOD for me here.
<alan_g> RAOF: goodbye. (But that is a function in DefaultServerConfiguration, not something the function "touches".
<alan_g> )
<camako> duflu, I see your point. However, we have already suffered and are in the final stretch (packages built).
<camako> There is an ongoing discussion on configuring jenkins for the rtm.
<camako> Meaning two distros..
 * camako feels our problems will be addressed soon 
 * alan_g admires the optimism of youth
<duflu> camako: Well the preferable solution would be for distro to actually use the distro configuration and build from the correct upstream branch  :)  https://launchpad.net/ubuntu/+source/mir
 * camako hasn't considered himself as "youth" in a very long time.. But thanks..
<duflu> That was previously "nice to have" but with two distros, probably now required
<camako> duflu, yes... That's why I'm "optimistic"
<camako> dednick, I'm assuming you've seen kgunn's email?
<camako> Can we push for landing silo 18, or do you need to fix smth?
<dednick> camako: just read now
<dednick> camako: give me a sec
<camako> sure
<sil2100> o/
<camako> duflu, thanks for updating the changelog...
<dednick> camako: give me a about 15 minutes to give the silo a quick test
<camako> dednick, sounds good... Take your time... I've yet to finish testing myself..
<greyback> alf_: I'm beginning to suspect that the reason for the slowdown is the fact, while before the job of actual rendering & buffer management was split between a mir compositor and the Qt renderer, now Qt's renderer thread is rendering but also is managing buffers
<alf_> greyback: I took some new traces this morning, and one thing I noticed is that at the start rendering the dash takes ~1000 calls, but after visiting "copes" and going back
<alf_> greyback: ... "Scopes" scope and going back it increases to over 1500, trying to figure out what the diff is
<greyback> alf_: I think that's because the contents of an off-screen scope are still being rendered
<greyback> alf_: I've pushed a patch to improve things, it should have landed by now
<alf_> greyback: which package?
<greyback> alf_: unity8, from the silo6
<duflu> That's fun. Callgrind says we make a quarter of a million fread calls to load X cursors
<greyback> alf_: Qt's scenegraph renderer does not do off-screen culling
<alf_> greyback: :/
<anpok> greyback: if we make those buffers opaque?
<anpok> then still  no culling?
<greyback> well it's a big cost for a large scenegraph, and a good developer can more easily manually manage the visibility of components
<greyback> alf_: a nice way to visually see these off-screen things is to run unity8 with QSG_VISUALIZE=overdraw
<greyback> anpok: sorry, I didn't follow that. Which buffers opaque? Other apps I guess you mean?
<alf_> greyback: also I noticed that even in the best case when things are "smooth", the dash is consistenly above 16ms (20-30ms), and in the worst case (judder) it's about (40-50), so there is some serious work to be done there regardless of this particular issue
<greyback> anpok: yeah making them opaque would help
<greyback> alf_: yep
<greyback> alf_: dash is doing lots of work, and lots of bad things
<greyback> and as a result qt isn't able to optimise much
<alf_> greyback: "actual rendering & buffer management" how do you mean that?
<alf_> greyback: in theory QtCompositor should be more efficient, since it's rendering directly to the mir provided framebuffer instead of on a surface which is then composited by the default mir renderer (which I think was happening before QtComp?)
<greyback> alf_: correct. I just had the idea last night that we've taken the jobs of 2 threads and combined them into 1 (removing GLRenderer though)
<alf_> greyback: hmmmmm
<anpok> the full screen blend blocked the caller for around 2 ms on nexus4
<greyback> anpok: the thing is, we see performance drop with zero apps open. So that is Qt rendering directly to the mir provided framebuffer
<alf_> greyback: you may be right, in the sense that because we are rendering in the thread that blocks for the page flip, the effect of missing a frame boundary are more pronounced
<anpok> wasnt there an option to move eglSwapBuffers to another therad in Qt?
<greyback> anpok: that is enabled (the renderer runs in a separate thread per window - per display *I think* - separate to the GUI thread)
<alf_> greyback: anpok: it's not that they are in the same thread, it's also that previously because we rendered to a surface first, we had a buffer to ease frame boundary misses
<anpok> i thought there was another one that also moves eglswap to a third
<alf_> greyback: anpok: but this is just on the top of my head, no hard facts to back it up
<alf_> greyback: anpok: off the top ...
<alf_> greyback: your new unity8 build is much better in terms of gl calls per frame
<greyback> alf_: yeah, but you can still experience jank when switching between apps & scopes scope
<greyback> so not perfect
<alf_> greyback: you mean while switching between the two, or after switching to scopes and back to apps again
<alf_> ?
<greyback> alf_: if I just go back & forth between the 2, it seems to slow a bit
<greyback> expecially with a certain flick
<duflu> Good news. I shall leave you today with nothing new to propose
<greyback> \\o/
<greyback> duflu: oh to continue our custom to belatedly admit we've not done anything wrt window management: I've not done anything wrt window management recently
<duflu> greyback: Awesome-tastic
<duflu> greyback: Me too but only because RTM trumps WM
<alf_> greyback: hmm, that's to be expected I guess... during the transition we are rendering both scopes. Each scope separately fails to meet the deadline, both scopes together make a complete mess
 * duflu has another idea and fails to log off...
<greyback> alf_: yep
<greyback> alf_: but at least a probably solution is in the pipeline: split Dash out of shell so it is a separate process
<greyback> s/probably/probable/
<greyback> well "solution"
<greyback> it'll still render slowly
<alf_> greyback: Has something changed in this area in QtComp? Is nonQtComp somehow convincing QtSG to render only parts of the SG?
<greyback> but the frame boundary missing would be more forgiving - if that theory is right (I'm convinced)
<duflu> Ah. Input latency reduced ten-fold. If only we could do that on the phone.
<alf_> greyback: is split-dash scheduled for rtm?
<alf_> duflu: how and what's blocking this on the phone?
<duflu> alf_: Framedropping. And the fact that Qt apparently lacks throttling to be able to use it safely
<greyback> alf_: yes
<greyback> duflu: call me ignoramus: input throttling? Is that compressing a large number of events into a single event, to reduce the amount of events a client has to process? Or something else?
<duflu> greyback: Could refer to different things. Where's it written?
<greyback> duflu: I dunno, I saw you write it, I wanted to know what you were referring to
<duflu> greyback: Oh. I did notice with strong suspicion though that Android-input seems to group and discard input events depending on how fast you consume them. Really fast renders get more events. Slow renderers get less, but at least don't get progressively more behind
<greyback> duflu: ok, that's interesting
<duflu> greyback: So fingerpaint for example always keeps up with the current pointer location, but a fast renderer (frame dropping) sees many more samples... smoother curves
<duflu> I know for a fact my mouse generates around 1000 events per sec. Mir is certainly not getting most of them
<camako> dednick, the silo is testing well for me. How is it on your side?
 * camako saw some msgs between alan_g and tvoss
<camako> and dednick
<dednick> camako: silo working for me. tvoss having some issues, but don't think it's directly related.
<greyback> alf_: I'm getting more & more convinced by your frame boundary explanation
<alf_> greyback: convinced by experiments or by thinking about it? :)
<greyback> alf_: I've no proper data, more just thinking about it
<alf_> greyback: btw, QSG_VISUALIZE and its various options are very neat... and the dash sucks at batching (33 alpha-enabled batches, 2 opaque) :/
<greyback> alf_: I know, it's horrible
<greyback> alf_: totally defeating the batching optimisation
<greyback> explains why scrolling so severe on CPU and GPU
<alf_> greyback: Do you think there is an easy way with the QtComp codebase to test the frame boundary theory?
<greyback> alf_: possibly by comparing frame render & frame delta times between QtComp & non-QtComp
<greyback> QSG_RENDER_TIMING *might* give enough info, else QSG_RENDERER_DEBUG=render
<greyback> would also need to compare the same complex scene for both cases
<Saviq> hey guys, got a gift for you - client crash on exit bug #1342694
<ubot5> bug 1342694 in mir (Ubuntu) "qmlscene crashed with SIGSEGV in _M_release() on quit" [Undecided,New] https://launchpad.net/bugs/1342694
<Saviq> it *could* potentially be qtubuntu, too
<AlbertA> Saviq: it's being discussed... I think alan_g just root caused it
<Saviq> coolz
<racarr__> Would appreciate thoughts on https://code.launchpad.net/~mir-team/mir/cursor-spike-phase-7-name-some-cursors/+merge/225242
<racarr__> once it or something similar lands can go around and add cursor support to qt, chromium, gtk, etc...
<racarr__> + any problem with landing https://code.launchpad.net/~mir-team/mir/improve-attribute-protocol-and-normalize-getters/+merge/225912
<racarr__> opinions on https://code.launchpad.net/~mir-team/mir/touchspot-visualizer/+merge/224731 probably more important than cursor
<racarr__> opinions on https://code.launchpad.net/~mir-team/mir/touchspot-visualizer/+merge/224731 probably more important than cursor
<racarr__> whoops
<racarr__> how to share acceptance tests with unity-mir/qtmir/mirqt/gerry
<racarr__> beyond copy pasting code
<racarr__> ive been thinking though there are a lot of tests
<greyback> racarr__: I'm open to ideas
<racarr__> that should be run against
<racarr__> the shell server configuration
<greyback> racarr__: also note I've not had the time to make any of the changes you suggested yet. So don't be offended if it appears I just ignored you:)
<racarr__> no worries I havent done a second pass through yet. um.
<racarr__> I dont think any of them are in particular important to prevent landing.
<racarr__> i.e. I expect a read through of unity-mir
<racarr__> would turn up about just as much
<greyback> could you make a gdoc and put your review comments in there please? Easier to deal with than an email thread IMO
<racarr__> I kind of tried to identify things that we may want to fix asap though.
<greyback> oh sure, most of the same mistakes are probably there :)
<racarr__> like...I had kind of forgotten that screencast authorization was never implemented
<racarr__> lol
<racarr__> ok will
<racarr__> google doc it up
<greyback> with QtComp, I need to disable it, as it won't work
<greyback> until I combine Qt's renderer with Mir's interface properly
<racarr__> haha right...
<racarr__> we need proper permissions for display config at least
<racarr__> or
<racarr__> maybe both are just always disabled on the phone
<racarr__> and there is
<greyback> I've no idea how shell mediates that. We've not had that discussion
<racarr__> developer mode :p
<racarr__> always disabled + developer mode to always enable
<racarr__> is better than
<racarr__> always allowed though
<greyback> oh apparently I was wrong, we do send clients focus/unfocus events
<racarr__> :)
<racarr__> https://code.launchpad.net/~mir-team/mir/improve-attribute-protocol-and-normalize-getters/+merge/225912
<racarr__> last chance to object pre landing
<greyback> racarr__: why does a setter return the type that is set?
<greyback> + MirSurfaceType set_type(MirSurfaceType t);
<racarr__> greyback: hmm no real reason atm...the exception throw
<racarr__> used to be in configure instead of set_*
<racarr__> I guess there is some thought that the logic is like
<greyback> racarr__: it's a weird api IMO, as when I set something, I've to check if the value returned is actually the one I set. Else I cannot trust it
<racarr__> well
<racarr__> they are private
<racarr__> the public api is
<racarr__> int configure(int, int) lol
<greyback> that's a crappy API and you know it
<racarr__> lol which part
<greyback> why not just export these private methods?
<greyback> ABI stability?
<racarr__> well as it stands the only user is frontend which is
<greyback> me
<racarr__> happy with the ints.
<racarr__> ?
<greyback> eh. I'm trying to be a vocal API consumer
<racarr__> haha.
<greyback> configure(int,int) is an unpleasant way to set properties on something
<greyback> aside from that, I like your changes
<racarr__> I think, as needed/requested, setters and getters can be added for specific properties....some of them have public getters
<racarr__> I guess configure/query is really the API to frontend
<racarr__> and the API to shell
<racarr__> has been ignored lol
<greyback> nice :P
<racarr__> I hope I make sense...I may literally be the most tired I have ever been right now
<racarr__> the good news. No niccotine in 5 days!
<racarr__> and i...enjoyed the whole process this time
<racarr__> and am pretty confident that I am over it
<racarr__> the bad news. no proper sleep in 5 days!
<greyback> keep it up man, you can do it
<racarr__> I think tonight is finally my night just due to sheer and total exhaustion.
<racarr__> :D Thanks
<greyback> I'm not in any hurry for you to do anything (think I'm the bottleneck right now)
<greyback> so if you need to snooze, go for it
<racarr__> I...none of it makes me want to smoke lol im just so tired atm hard to tell things make sense
<racarr__> haha, nah, gotta power through until the sun goes down at least lol
<racarr__> Think I am going to distract myself with low brain power acceptance testing.
<greyback> :)
#ubuntu-mir 2014-07-17
<duflu> alf___: ping
<alf___> duflu: hey
<alf_> my tail grew while I was away
<duflu> alf_: Hey can you refresh my memory about where to find the Qt compositor code that determines how long compositor buffers are held?
<duflu> Or if you can't remember, I shall dig it up later
<alf_> duflu: I am not sure I get your question, but related code is in lp:qtmir (i.e. the glue between qt an mir used by QtCompositor)
<duflu> alf_: Thanks. It's been quite a while since I jumped between projects
<alf_> duflu: by "Qt compositor" you mean the new version, right (THE "QtCompositor")?
<duflu> alf_: I was away for the changeover. Only vaguely familiar with the fact that things are changing there
<alan_g> RAOF: provides was in the incantation mterry gave me. And my reading of the documentation didn't make it clear that it was wrong.
<alan_g> Thanks for the fix
<duflu> Oh render_surfaces isn't green any more?
<duflu> Horrible green isn't fashionable?
<alan_g> ...a shame it didn't work
<alf_> duflu: lp:qtmir , src/modules/Unity/Application/mirsurfaceitem.cpp should be a good start for what you are looking for. Note, again, that this is the code for the upcoming "QtCompositor" Gerry is working on, *not* what's in the images right now.
<alf_> duflu: I think the relevant code for the current version is in lp:unity-mir
<duflu> alf_: Thanks, good to know the difference
<alf_> duflu: I have managed to reproduce 1335481 locally. Are you investigating or should I look into it?
<alf_> duflu: bug 1335481
<ubot5> bug 1335481 in mir (Ubuntu) "unity-system-compositor crashed with SIGABRT - assertion failed at buffer_queue.cpp:136 - "!pending_client_notifications.empty()"" [Critical,Triaged] https://launchpad.net/bugs/1335481
<duflu> alf_: Go nuts, I'm not working on it
<alf_> duflu: ack
<mlankhorst> is mir broken on nouveau? getting thread 1 stuck on pthread_mutex_lock in #7  mir::scene::Observers::add_observer (this=this@entry=0xc54ee8, observer=std::shared_ptr (count 1, weak 0) 0xc55978) at /build/buildd/mir-0.4.1+14.10.20140714/src/server/scene/surface_stack.cpp:285
<duflu> mlankhorst: I was considering retesting more hardwares this week. Will do so by the weekend
<duflu> rsalveti: Got some fun for you
<alan_g> mlankhorst: that looks like it could be a problem we fixed in -r 1764 (can't find the bug reference just now).
<alan_g> I don't think the fix has quite made it to archive.
<duflu> rsalveti: https://bugs.launchpad.net/ubuntu/+source/libhybris/+bug/1343198
<ubot5> Ubuntu bug 1343198 in Mir "[android] Mir spends 12%+ CPU time in get_hooked_symbol (libhybris-common)" [Medium,In progress]
<mlankhorst> alan_g: is there a ppa for testing?
<alan_g> camako: ^
<camako> mlankhorst, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-018
<mlankhorst> I thought the train was crashed by a aiplane?
<tedg> dednick, So the silo18 has everything in it now?
 * tedg notices a new branch added there
<dednick> tedg: new branch? didnt realise
<dednick> tedg: it's still missing a bit from unity8
<tedg> dednick, I think so, but I'm loosing track of which ones I need :-)
<tedg> dednick, Oh, is that in a silo somewhere?
<dednick> tedg: i'm not really sure. things are a bit fluid at the moment. Saviq?
<Saviq> dednick, it could be added now
<tedg> dednick, So I got silo 18 installed but I'm not seeing a socket in the runtime dir.
<Saviq> dednick, previous landing *just* happened
<tedg> Is that expected?
<tedg> Saviq, While you're here, when does dash get it's own PID?
<dednick> tedg: that's the bit that's missing.
<Saviq> tedg, soon after qtcomp
<Saviq> tedg, meaning a week, max two away
<dednick> tedg: if you add a MIR_SERVER_PROMPT_FILE=1 to your unity8.conf upstart file it will work.
<tedg> Oh, my. I was hoping that was going to be an hour, max two away...
<tedg> dednick, So can I ask the trusted prompt session to overlay on the Unity8 PID?
<tedg> Or is that crossing the streams?
<dednick> tedg: no, it wont work on the unity8 pid. only an application
<tedg> dednick, Uhg, okay.
<tedg> Saviq, Can we split the dash out before the qtcompositor landing?
<tedg> I realize it won't be as beautifulâ¦
<Saviq> tedg, no we can't
<tedg> Saviq, If I ask really nicely. PLEASE! :-)
 * tedg gets some kitten pictures off the Internet
<Saviq> tedg, really, no, it's already done based on qtcomp, and qtcomp is landing within days
<Saviq> and is more important
<tedg> Hmm, okay.
#ubuntu-mir 2014-07-18
<duflu> kdub_: Around?
<alan_g> RAOF: you say "Breaks/Replaces" should work, sil2100 and mterry both say Conficts/Replaces/Provides should work. Any reason for the difference?
<duflu> alf_: Sanity check: After eglSwapBuffers, you can trash your texture data right?
<duflu> I always thought so
<alf_> duflu: yes for normal textures, for EGLImage backed textures the situation is not clear in the specs, but we have always assumed the same
<duflu> alf_: Yeah I think more things would blow up if the data was still required after swapbuffers
<duflu> Ah Friday afternoon... the best time to tackle complex problems
<duflu> providing you don't need to have a Friday evening
<sil2100> alf_: hello! Are you familiar with qtubuntu codebase?
<alf_> sil2100: I've browsed it, but I wouldn't say I am familiar with it.
<alf_> sil2100: what's up?
<sil2100> alf_: we're trying to identify the source of a recent crash in qmlscene that's most likely caused by qtubuntu and since ricmm doesn't seem to be around right now we're looking for someone that could help in the identification here
<alf_> sil2100: I can take a look in ~1h, where do I get information?
<sil2100> alf_: thanks! The bug is here https://bugs.launchpad.net/ubuntu-app-launch/+bug/1329141
<ubot5> Ubuntu bug 1329141 in Ubuntu Application Launcher "qmlscene crashed while running test_can_launch_multiple_applications" [Critical,Confirmed]
<sil2100> It might be hard to pin-pointing, but maybe at least you could have a look and check if it's not anything obvious
<alf_> sil2100: The crash as retraced in https://bugs.launchpad.net/ubuntu/+bug/1340571 , is caused by qtubuntu for some reason not being able to create a server connection. It's not a real crash caused by some programming error (at least not at the crash site).
<ubot5> Ubuntu bug 1329141 in Ubuntu Application Launcher "duplicate for #1340571 qmlscene crashed while running test_can_launch_multiple_applications" [Critical,Confirmed]
<kdub_> racarr__, (when you're up) or dandrader, what do you think about this branch? lp:~vanvugt/mir/fastlog
<kdub_> (changing the input logging for mir)
 * kdub_ approved, but then again I don't use that log very often :)
 * dandrader looks
<alan_g> AlbertA: alf_ kdub_ Anyone think we need more discussion of this: https://code.launchpad.net/~vanvugt/mir/server-ABI-24/+merge/227137
<kdub_> alan_g, I approved, didnt see a problem
<alan_g> kdub_: thanks (I didn't either)
<AlbertA> alan_g: seems like the usual course of action so +1
<racarr__> Morning :)
<greyback> racarr__: hey, have you any more comments on qtmir QPA plugin?
<racarr__> greyback: Don't think so!
<greyback> racarr__: ok great, thank you for looking into it
<racarr__> np :)
<alf_> racarr__: standup?
<racarr__> alf_: Sorry was breakfasting...
<alf_> racarr__: no worries, I have a question for you
<racarr__> nothing exciting from me...been doing some reviews and a little side work and working on cursor renderable
<racarr__> small hang up in cursor renderable...the
<racarr__> well it would be nice to be able to creat ean EGL image from the cursor buffer
<racarr__> to unify the software path
<racarr__> but you caont because there is no "DRIImage" for the dumb bos
<racarr__> alf_: Yeah?
<alf_> racarr__: I was looking into https://bugs.launchpad.net/mir/+bug/1344024 and traced the problem in our ConsumingPlacementStrategy
<ubot5> Ubuntu bug 1344024 in Mir "Clients cannot create surfaces when the screen is off" [High,In progress]
<racarr__> oh sounds right
<alf_> racarr__: when a screen (or the only screen) is off, the strategy will return size=(0,0)
<alf_> racarr__: I was wondering if we should have a more reasonable strategy as default. Is someone relying on current ConsumingPlacementStrategy behavior?
<racarr__> alf_: I don't think so no...it's kind of a hangover
<racarr__> I mean the strategy is reasonable right? size to outputs
<racarr__> presumably the problem is something like
<racarr__> using output.current_mode_index
<alf_> racarr__: Currently, if the client has asked for a particular size, we clip that the size of the output it's in. The problem is that if there are not outputs the new size will be (0,0) which is consistent, but fails
<alf_> racarr__: But taking a step back, I don't think we should be resizing the surface (by default) if the client has explicitly asked for a particular size.
<alf_> racarr__: Orthogonally to the above, we are currently using available display buffers to find the available outputs (and we don't create a display buffer for a screen that's off), so perhaps we should switch to DisplayConfiguration and take into account all "used" outputs (regardless of their power state)
<racarr__> alf_: Note about display configuration v. display buffers definitely seems right
<racarr__> resizing the surface...I dunno
<racarr__> I guess maybe we shouldnt by default
<racarr__> its
<racarr__> the unity behavior
<racarr__> but there is no reason to have it
<racarr__> in the mir tree
<alf_> racarr__: well, the client can get all the information about the display configuration, so if it asks for a particular size the we should respect that (in the default impl., a proper shell is another story)
<alf_> racarr__: although, I guess since the client can't place the surfaces exactly this is less useful
<racarr__> mm
<racarr__> I think it makes sense to remove from mir...no sense in the model now for having it as
<racarr__> a random bit of behavior
<alf_> racarr__: currently ConsumingPlacementStrategy has three subpolicies: 1. if the client has asked to be placed in a particular output (output_id is valid) => place it there
<alf_> racarr__: 2. if the client has asked for a particular size => clip the surface to the size of the output it is in
<alf_> racarr__: 3. if the client has asked for 0 size => make it fullscreen in the output it is in
<racarr__> yes
<racarr__> carefully designed to justify an elaborate series of cucumber tests
<racarr__> lol
<racarr__> um
<racarr__> I don't think any of the behaviors make sense for us to have
<racarr__> I mean maybe in demo-shell or something
<racarr__> but they are all shell-mediated right
<racarr__> even asking to be placed in a particular output
<racarr__> its the kind of thing where the shell says, eh, no thanks.
<racarr__> so I am not sure there is a point in having the default strategy impl if each shell is going to write its own
<alf_> racarr__: we should at least have a null implementation to allow the source to build :)
<alf_> racarr__: (and run the tests)
<alf_> racarr__: But I think something that includes only (1) would make sense as a default
<racarr__> Yeah I was wondering if it should have 1 but
<alan_g> racarr__: does it make sense to move the other behaviours to the examples?
<racarr__> it should probably be in demo shell
<alf_> racarr__: plus just placing all surfaces at 0,0 with the size they have requested, a size of 0,0 being an error
<racarr__> why have (1) in tree if every shell
<racarr__> is expected to override
<racarr__> the placement strategy
<alf_> racarr__: well USC doesn't (currently) need to override it
<racarr__> presumably it will at some point though
<alf_> racarr__: yes, probably when we want to make it smarter about multiple monitors
<alf_> racarr__: I am inclined to include (1) in the default just because it's explicitly provided in the client API
<alan_g> It is good to have a default that is sensible enough for a hypothetical developer to use until they need to change it. (Like what we have with USC now)
<racarr__> I was thinking about that
<racarr__> but then
<racarr__> surface states are provided in the client API too
<racarr__> right? so what is
<racarr__> the conceptual difference between the output-id placement behavior
<racarr__> and mir_surface_state_fullscreen leading to your surface becoming fullscreen
<alf_> racarr__: one difference is that the client can fake fullscreen size (it can get the display config), whereas it has not control of placement outside the output_id API.
<alf_> racarr__: Another point is: let's say that we don't support output_id, a client gives us an output_id, what do we do?
<alf_> racarr__: do we place that where we want and lie to the client, or do with error out?
<alf_> racarr__: s/do with/do we/
<racarr__> alf_: But the null impl never runs
<racarr__> so place it whever you want :p
<racarr__> demo shell should certainly
<racarr__> support 1.
<alf_> racarr__: the problem is that output_id is supposed to provide a kind of guarantee (in my mind at least) that the output will be placed where the client told it to.
<alf_> racarr__: and a null default impl. breaks that guarantee
<racarr__> only a kind of guarantee because
<racarr__> the shell can always say
<racarr__> no thats ridiculous im not placing you on that monitor
<alf_> racarr__: then I think the output_id param is not useful if it's only a hint
<alf_> racarr__: Imagine XMir running and wanting to place the screen surface in a particular screen
<racarr__> Presumably the shell policy would be yes that something like XMir could always
<racarr__> specify output_id
<racarr__> whereas...maybe apps cant?
<alf_> racarr__: The API should give it that guarantee (with conforming implementations, of course), XMir shouldn't care about what's running beneath it. So I think that the mir server either supports output_id and places the surface properly, or it doesn't and errors.
<alf_> racarr__: and sure that could be a policy in the shell depending on the client
<racarr__> it's not really much of a guarantee
<racarr__> I man the shell
<racarr__> mean*
<racarr__> could respect output_id
<racarr__> and then
<racarr__> resize you and put you on another monitor
<alf_> racarr__: but treating it either as a guarantee or as a hint depending on the client is inconsistent
<alf_> racarr__: but the client asked for that particular id, not "fullscreen on any monitor you like"
<racarr__> maybe it should be an error if its not permitted and people who
<racarr__> don't really care about the actual physical setup of the displays (i.e. xmir because of monitor configuration I guess)
<racarr__> shouldn't use output_id
<racarr__> maybe this is imaginary but I have the thought that the answer isnt to always
<racarr__> support it from the client
<racarr__> i.e. should my phone app be able to open fullscreen on the external monitor
<racarr__> may be a permission or something
<alf_> racarr__: I guess I don't mind an almost-null implementation, as long as it errors out if an output id is provided ("I cannot provide that guarantee").
<racarr__> I still think its a weird guarantee
<racarr__> what if you request an output-id and the user
<racarr__> moves you
<racarr__> is that an error?
<racarr__> probably not so is there some additional constraint like its only for certain surface types which are not movable by the user
<racarr__> but even then what happens when the monitor dissapears or something
<racarr__> so what the guarantee just becomes
<racarr__> if you provide an output-id you will be fullscreen on that output for some non zero amount of time
<racarr__> but then how can the client
<racarr__> use the guarantee?
<racarr__> because the time could be arbitrarily small
<alf_> racarr__: user move: fair point, monitor disappears: if the client cares about a particular id, it probably means it selected that based on the current display config, and it should monitor display config changes and adapts
<racarr__> hmm thats an interesting problem how do
<racarr__> ok so it could be for only non user movable windows
<racarr__> like say XMir, perhaps some presentation windows, etc
<racarr__> and then, when the outputs dissapear
<racarr__> you could add something that like
<racarr__> until a new output_id is assigned or
<racarr__> the output is cleared
<racarr__> the surface just dissapears
<racarr__> i.e. isn't on screen
<racarr__> and that makes the guarantee a little stronger
<alf_> racarr__: I think that's reasonable, the client should react quickly anyway
<racarr__> I am thinking about like
<racarr__> to prevent flicker
<racarr__> i.e. monitors 1 2 3
<racarr__> client with output id 3
<racarr__> monitor 3 unplugs
<racarr__> shell places
<racarr__> on 1
<racarr__> client receives display configuration
<racarr__> change
<racarr__> places on 2
<racarr__> but then you can make the guarantee if setting the output-id is successful
<racarr__> then if a surface appears
<racarr__> it will appear on that output
<racarr__> and then, still perhaps sometimes its dissalowed
<racarr__> im not sure
<racarr__> i.e. things like can phone apps open on the external display
<alf_> racarr__: another point is that if output_id is a guarantee you can cater for both 1. clients that really need to be placed in that id otherwise they don't work properly (XMir) 2. clients that would like to be placed in that output id, but it's not critical (they can try with output_id, fallback to without output_id)
<alf_> racarr__: anyway, food for thought :)
<alf_> racarr__: enjoy your day an weekend!
<alf_> all: ^^
<mzanetti> thanks alf_ :) you too
<racarr__> alf_: :) Cheers. Happy friday
<bschaefer> racarr__, hey, was just getting to the doing the SDL2 cursor stuff. 2 have come up that I don't see in mir (not sure if they are really needed anyway):
<bschaefer> SDL_SYSTEM_CURSOR_NO and SDL_SYSTEM_CURSOR_CROSSHAIR
 * bschaefer gets the x11 equivalent
<bschaefer> XC_pirate and XC_tcross
<racarr__> XC_pirate oO
<racarr__> ill hvet o look in to that one
<racarr__> will add crosshair to the branch though
<racarr__> thanks :D
<bschaefer> racarr__, nice :), thank you!
<racarr__> brb though
<bschaefer> racarr__, yeah the pirate, is just a cross, like on a treasure map
<bschaefer> err...weird, pirate does not show up like that in xlib manual...weird...
<bschaefer> strange...:     case SDL_SYSTEM_CURSOR_NO:        shape = XC_pirate; break;
#ubuntu-mir 2014-07-19
<Aki-Thinkpad> I am developing a pair programming plugin for the ubuntu SDK. A lot of X based apps are being suggested for sharing outputs and what have you
<Aki-Thinkpad> I am kind of curious whether Mir (I am an ignoramous) has any desktop sharing functionality being worked on
#ubuntu-mir 2015-07-13
<anpok_> hi
<anpok_> I am playing with xmir in silo-004.. and tried various options
<anpok_> when using -egl or -egl_sync the buffer contents seem to be corrupted. -sw and no option work fine when -damage is used. Without -damage a mix of old and new buffer is sometime visible..
<duflu> anpok_: Did it ever work better than that? The new xmir is still relatively "new"
<duflu> Weird. Every IRC message and email I've sent today has been met with silence.
<duflu> Is there anybody out there?
<sturmflut2> Well, it's only 10 AM here in europe, on a monday. People are probably either asleep or in meetings.
<ogra_> or both ;)
<sturmflut2> ogra_: Didn't want it to phrase like that, but yes.
<duflu> Actually I was sending messages mostly to people in this timezone (West Aust / Hong Kong / Tokyo)
<anpok_> duflu: :)
<anpok_> not sure .. at least there is one configuration inside the set that works fine
<duflu> anpok_: I would not worry about it. In my testing XMir 2.0 has been only mildly mature. I would not expect it to have perfect visual correctness and damage handling yet
<duflu> alf_, anpok_: If I need to propose a fix to egl-platform-mir.patch, where is the best place?
<alf_> duflu: mesa package
<alf_> duflu: I have found that all other repositories are out of sync with the package
<anpok_> hm tjaalton recently had to make changes to the patch
<duflu> It's been a while. I need to remember how to :)
<alf_> greyback: Which component in unity8(?) knows when the screen is (un)locked? I need it to emit a dbus event on (un)locking.
<alf_> greyback: (Hi!)
<greyback> alf_: Hey!
 * ogra_ thought there is already one ... mtp should use it 
<greyback> alf_: it's a qml component: either Greeter/Greeter.qml or Components/Lockscreen.qml
<greyback> what is it you want to do?
<alf_> greyback: I want USC to somehow know if the screen is locked or not, so we can deal with inactitivity timeouts correctly. Basically, when the phone is locked touches shouldn't extend the inactivity timeout.
<greyback> understood
<greyback> Greeter is probably the place to be
<greyback> qml doesn't have built-in support for dbus. We usually write a small C++ class with a method which fires the dbus signal. Then call that method from qml.
<alf_> ogra_: if there is an existing dbus signal I can watch for, even better... but I haven't been able to find one
<alf_> greyback: ack
<greyback> alf_: something like DashCommunicator would be the simplest example I can point you to
<ogra_> alf_, bzr branch lp:mtp ... if there is a dbus signal server.cpp should use it
<greyback> that's in lp:unity8:/plugins/Unity/DashCommunicator
<ogra_> (i dont think mtp implements its own thing here)
<alf_> ogra_: thanks, I will take a look
<alf_> greyback: ogra_: So, I see a 'com.canonical.Unity.Greeter' interface used by MTP, but I don't see unity8/greeter implementing this interface
<ogra_> fun
<ogra_> well, it works with mtp ... somehow ..
<Chipaca> alf_: o/
<Chipaca> alf_: does mir always load xkb?
<alf_> Chipaca: Hi. It uses xkb libraries on the client side
<Chipaca> alf_: yes. always?
<alf_> Chipaca: yes (AFAIK)
<Chipaca> ok
<attente> hi, shouldn't mir be re-focusing a parent surface when one of its focused child surfaces is released?
<renatu> hey guys I am using ubuntu 15.04 (r58) on arale, and I noticed that the screen never turns off while idle
<renatu> how I can debug it?
<anpok> this is known issue of unity-system-compositor
<tsdgeos> me?
<anpok> hm alf_ made a fix
<tsdgeos> er
<tsdgeos> ignore me
<tsdgeos> i added an highlight on unity and get confused thinking people are pinging me
 * tsdgeos hides in his cave
<anpok> :)
<renatu> anpok, nice thanks, will this fix land on OTA5?
<anpok> renatu: iirc applications seem to try to remove display on requests that they never issued.. and that caused usc to restart the display off timeout
<anpok> iirc ota5 is already closed?
<renatu> seb128, ^^^
<seb128> anpok, renatu, check on #ubuntu-ci-eng, there are still discussing very selected landing, but it's likely going to be for ota-6 now
<seb128> anpok, is there any way to tell what application does that?
<kgunn> camako: anpok what's the plan on mir0.14 wrt wily vs vivid+ being frozen ? e.g. are you gonna land in wily regardless? or dual land only ?
<kgunn> i got no opinions, just asking
<camako> kgunn, land on both. vivid+ will soon thaw.
<kgunn> ack
<anpok> kgunn: i was told I cannot dual land because of the attached source packages
<anpok> so I picked wily since vivid+overlay was freezing already
<kgunn> camako: ^
<kgunn> anpok: ok, up to you and camako how you wanna do it...
<kgunn> anpok: but you might wanna add
<kgunn> https://code.launchpad.net/~afrantzis/unity-system-compositor/fix-1461476-display-off/+merge/264127
<kgunn> to that silo
<kgunn> camako: racarr also, just checking on the raw event stuff, i thot we needed some device introspect as a precondition?
<kgunn> just seeing the introspect card is on backlog
<kgunn> was there maybe a smaller task gonna be spun out of that ?
<camako> anpok, kgunn, ack about it not being a dual landing, but we will land on both. vivid+ is thawing by EoD today.
<camako> land on both == two silos
<kgunn> :) camako i'm kind of wanting to bet you on the thaw
<kgunn> but you might win...
<kgunn> you never know
<camako> kgunn, yeah I know it may not but the point is it's close (one or two days don't make much of a difference at this point)
<camako> kgunn, I made a comment on the introspection card, but haven't been able to sync with racarr. Hopefully today
<kgunn> camako: thanks... it'll be my favorite topic for a while :)
<greyback_> racarr: What is meant by "device introspection" exactly?
<racarr> greyback_: Yeah input device introspection
<racarr> enumerate devices, query their properties, etc...
<greyback_> racarr: ok, that makes sense. Just the name was vague, and introspection I consider to inspect inside something, not just read fundamental properties of it
<racarr> yeah I see that
<racarr> I think of it as introspection wrt to the fields
<racarr> in the event
<racarr> an in particular the raw event which will need more interpretation
<racarr> but even as it stands like
<racarr> some of our axes e.g. everything except
<racarr> x/y can't be used because
<racarr> they are device specific min max
<racarr> so its like, hey what is this axes, what is this button
<racarr> *shrug*
<greyback_> racarr: devils advocate - who needs that?
<anpok> shells
<kgunn> racarr: so should it be better names as event-introspection ?
<kgunn> if it's even named yet :)
<greyback_> for unity8 drawing pointer, would not relative mouse move events be enough?
<greyback_> i.e. mouse moved 1 unit to the left
<greyback_> anpok: I'll need more than "shells" ;) Can you give me examples
<racarr> greyback_: Yes thats what the raw events are
<greyback_> shells can get device info via other libraries like udev
<racarr> and the intersection with
<greyback_> racarr: cool
<racarr> introspection
<racarr> is you get a bunch of
<racarr> {Id: 7: axis 9: value 14}
<anpok> greyback_: true..
<racarr> which ones come from a mouse :)
<racarr> um so yeah shells
<racarr> can't strictly speaking use udev without
<racarr> breaking our encapsulation of input
<anpok> greyback_: I wanted to write that.. and then realized.. that with libudev you do not need to have permission to query the device
<racarr> so then
<racarr> input platforms don't work
<racarr> e.g. someone writes a platform for a custom device or
<racarr> a platform for networked input ala synergy
<racarr> you can't assume that you can just query the device via other apis
<racarr> and then there are also client consumers
<greyback_> sure, but similarly we can't assume mir runs on linux, but we have
<racarr> I think for example drawing apps
<greyback_> I just don't want to see reinvention of the wheel
<racarr> wan't to find a device thats a tablet and map it to a window...and maybe list the tools
<greyback_> ok, fair example
<racarr> it's
<racarr> an unfortunately complex solution to relative pointer events
<racarr> but I dont think much is required for that
<racarr> if I can't find a good pat
<racarr> moistly the difficulty is in carving through the InputReader
<racarr> soon though...there's kind of
<racarr> a fallback strategy of just throwing some relative info in the pointer event
<racarr> MORE CAFE
<racarr> mmm
<racarr> AlbertA: In https://code.launchpad.net/~albaguirre/mir/tweak-failing-tests-ci-tsan/+merge/264463
<racarr> + ASSERT_THAT(client_frames, Gt(compose_frames * 0.78f));
<racarr> what does this mea
<racarr> n
<racarr> well or rather why 0.78 now instead of 0.8
<kdub> racarr, iirc from the summary in the standup, changing that value didn't quite work either, and since its a timing-based test, might just be disabled
<kdub> and... in the new buffer scheduling stuff, should be translated to a not-timing-based test
<racarr> kdub: Ah. Sounds good to me :)
<racarr> thanks
<kdub> 'tis the time in the afternoon to switch to reviewing
<attente> hi, i don't seem to be receiving a focus-in event for a surface when one of its focused child surfaces is released. is this unexpected or by-design?
<racarr> just spent a while working on mir on x review....made progress now breaking for lunch...
<greyback__> attente: bug. That's window management which requires much work still
<attente> greyback__: ok, thanks
<attente> greyback__: is there already a bug number for it? should i file one?
<greyback__> attente: not that I know of. Please file
<attente> greyback__: is there any other information i can get out of a MirSurfaceEvent other than the attribute and the value (through the client api)? ideally like a surface handle or identifier?
<greyback__> attente: I'll let a Mir expert answer that. racarr?
<attente> greyback__, racarr: actually, i spoke too soon, i guess i don't need it because i'm getting that info directly from the event handler callback for the surface
<conyoo> gsettings get com.canonical.qtmir lifecycle-exempt-appids
<conyoo> ['com.ubuntu.music']
 * ahayzen ducks
<conyoo> does this mean music app is not suspended?
<ahayzen> while audio is playing yes.. for now ;-)
<conyoo> nice :D
<conyoo> so i can add terminal app?
<ahayzen> hopefully it'll go soon
<ahayzen> i don't know if settings that would allow other apps to not be suspended, try it!
<conyoo> i have no idea how :>
<conyoo> gsettings set com.canonical.qtmir lifecycle-exempt-appids what?
<greyback__> conyoo: yes
<greyback__> what -> "['com.ubuntu.music','com.ubuntu.terminal']"
<greyback__> qith quotes
<greyback__> with
<conyoo> uuu thanks, greyback__  :D
<conyoo> gsettings get com.canonical.qtmir lifecycle-exempt-appids
<conyoo> ['com.ubuntu.music', 'com.ubuntu.terminal']
<ahayzen> :-) greyback__ you'll be happy to hear that we are finally working on bg-playlists support with the media-hub guys at the moment, its slow progress but we'll get there soon hopefully :-)
<conyoo> so is the key some vector, enum/
<greyback__> ahayzen: wooo!
<greyback__> conyoo: array of strings
<conyoo> right
<conyoo> yay! now i can use unity8 on the desktop :D
<conyoo> Xmir sort of works :D i'm good
#ubuntu-mir 2015-07-14
<greyback_> hey folks, does unity8 as a nested server have the ability to change the display configuration of the system server? I know the client API allows that, but has a nested server access to that somehow?
<kdub> greyback_, it looks like mg::Display::configure() is plumbed up
<greyback_> kdub: ok cool, just wanted to make sure
<greyback_> thanks
<kdub> greyback_, np
<greyback_> @vogons were there ever discussions on privileged mir clients? How to allow a system settings app or a screenshot tool, without giving those abilities to the world
<kdub> sure, for the systems settings, we have some interfaces that apply policy to when the display gets configured
<kdub> that we hazily? thought a security-concerned shell would mediate
<greyback_> sure, it's more the how to mediate. Who knows what client can do what
<kdub> and with screenshotting, there's src/server/frontend/unauthorized_screencast.cpp
<kdub> well, I guess mir wouldn't know which particular client is authorized
<anpok_> greyback_: I always thought those scenarios are handled by asking the shell whether a given session is allowed to do things..?
<greyback_> anpok_: sure, but how does the shell know to give permission or not
<greyback_> I know mir gives a shell the ability to reject such things. I'm asking if you ever thought how a shell would know to make those decisions
<kdub> greyback_, doesnt this have to be an ubuntu policy?
<kdub> like, some sort of permissions system involving other system components
<anpok_> hum by asking trust store?
<greyback_> kdub: yes
<anpok_> or is that for different use cases?
<greyback_> dbus has appArmor to impose permissions
<greyback_> if appArmor had an API for shell to see what permissions a client has, then that might be enough
<kdub> greyback_, right, iirc, we give the pid of the client that is connecting from the kernel as the secure way the shell can know that the client that it has launched is actually the one that connects over the mir protocol
<kdub> and that pid+dbus/apparmor/etc+ the overrides for mf::DisplayChanger and mf::Screencast are the levers involved
<Chipaca> i get http://pastebin.ubuntu.com/11877784/ on the demo server when trying to connect, what am i doing wrong?
 * tedg listens
<greyback_> Chipaca: I just ran demo server & a demo mir client, all ok. What are the commands you're running?
<tedg> greyback_, We're trying to get a QML snap working
<tedg> greyback_, So we have a bit more convoluted setup
<tedg> greyback_, I guess our question is more about "how do we figure out what is happening" more than "you have an issue"
<tedg> We're probably broken here :-)
<greyback_> tedg: from the log, you trying to run a mir server and it is failing
<greyback_> looking at hte code, it is trying to read a message from the socket, but that is failing. Is it able to create the socket at all?
<greyback_> default socket /tmp/mir_socket
<tedg> Here is the client side: http://pastebin.ubuntu.com/11877751/
<tedg> It's saying that the connection to the server failed.
<greyback_> can define MIR_SERVER_HOST_SOCKET=/something to tell mir a custom socket
<greyback_> tedg: is the server running tho?
<tedg> I think the default snap is using /run/mir_socket
<greyback_> why would an application snap bring up a mir server?
<tedg> No, the mir snap
<greyback_> shouldn't a snap framework be providing that?
<greyback_> ah ok
<tedg> So Chipaca shut that down so he could easily start/restart it
<tedg> But trying to keep things the same.
<greyback_> tedg: default mir socket is /tmp/mir_socket here
<tedg> Huh, looking at the strace it looks like we might be closing the socket earlier?
<tedg> I think that it's FD 4, and we're closing it at line 27
<tedg> greyback_, What is /usr/lib/x86_64-linux-gnu/mir/client-platform ?
<tedg> It looks like we're reading that directory, but then not opening anything in it.
<greyback_> tedg: used by mir clients, I don't think a mir server needs that
<tedg> greyback_, Yeah, I think the client might be failing in this case.
<greyback_> tedg: so the server is working?
<greyback_> your original paste suggests it isn't
<tedg> greyback_, It works in the sense that it runs without error :-)
<tedg> Oh, that may have been a mistake then.
<greyback_> tedg: you on desktop? Can you see a mouse pointer and move it?
<tedg> greyback_, I don't have this setup, I've been working with Chipaca to debug his setup. We might have to wait for him to get back for that question.
<Chipaca> greyback_: tedg: am back
<tedg> Chipaca, Cool, so I want to get setup with what you have.
<Chipaca> greyback_: the server works in the sense that i get a cursor and can move it around
<Chipaca> tedg: ok, let me push the files. meanwhile you get snapcraft :)
<Chipaca> or, hey, i'll make it a branch
<Chipaca> 1 sec :)
<Chipaca> tedg: lp:~chipaca/snapcraft/simpleqml
<Chipaca> tedg: and i'll pastebin the other bits
<Chipaca> tedg: http://pastebin.ubuntu.com/11878101/
<Chipaca> tedg: and http://pastebin.ubuntu.com/11878104/ on the device
<greyback_> Chipaca: ok, but that socket error the server reports still worries me. If the mir socket not correct, then clients will be unable to connect
<conyoo> :'(
<conyoo> when/after using mirscreencast the keyboard stops working unity shell (wily)
<conyoo> ~faild to mmap buffer
<greyback_> conyoo: could you try it with "-m /run/lightdm-mir-0"
<greyback_> may need to run as root too
<conyoo> that's what i'm doing :P i get the same error with or without root
<conyoo> let me copy the full error text (from tty to irssi in terminal app)
<conyoo> MirBufferStreamAPI: Cought exception at client library boundary (in mir_buffer_stream_get_graphics_region): etc
<conyoo> this is silly :D where can i find the log
<conyoo> where is this error logged? it has a time stamp [14312312.123123 <ERROR>MirBufferStreamAPI ... etc
<greyback_> conyoo: you're talking to unity-system-compositor, so if anything printed will be in /var/log/lightdm/unity-system-compositor.log
<seb128> when is the new mir supposed to land in wily?
<seb128> the one in silo 004
<seb128> kgunn, ^ do you know?
<kgunn> seb128: soon, it's being tested today
<kgunn> seb128: what's up? blocking you?
<seb128> kgunn, it's blocking the gtk-mir backend update which includes quite some good fixes and improvements from attente
<kgunn> seb128: ok, i was just telling the guys we do need to test this thoroughly, but we will land as soon as we feel good about it
<seb128> good, thanks
<camako> seb128, kgunn, testing looks good so far. Just a couple of USC features yet to be tested, then we'll greenlight it.
<camako> anpok ^
<seb128> camako, thanks
<Chipaca> greyback_: ok, i got the demo client to connect (not sure it's doing anything, but it connected)
<Chipaca> greyback_: mir_demo_client_cursors just draws a weird (glitchy?) static box
<Chipaca> and my actual cursor is gone
<greyback_> Chipaca: sounds about right, that demo tests custom cursors. egltriangle a little less confusing
<Chipaca> ah, eglcounter shows a counter
<Chipaca> works
<Chipaca> tedg: ^
<Chipaca> mvo: and your patched xkbcommon is what allows that to work :)
<Chipaca> next step, see why qt isn't working :)
<Chipaca> tedg: have you been able to reproduce this?
<tedg> Chipaca, Getting there.
<tedg> Not yet
 * Chipaca bbiab
<mvo> Chipaca: yaaaaay!
<tedg> Is there a key combination that'll cause the Mir demo server to shutdown?
<tedg> Ctrl+Alt+Backspace, yes!
<racarr> Morning!
<Chipaca> mvo: not there yet though :)
<Chipaca> oh, that's interesting
<Chipaca> tedg: if I manually start a demo client from the mir snap, e.g.,
<Chipaca> MIR_SOCKET=/run/mir_socket LC_ALL=C  XKB_CONFIG_ROOT=./xkbcommon/data/ LD_LIBRARY_PATH=$PWD/xkbcommon:/apps/mir/snap1/debs/usr/lib/x86_64-linux-gnu/:/apps/mir/snap1/debs/usr/lib/x86_64-linux-gnu/mesa-egl/ /apps/mir/snap1/debs/usr/bin/mir_demo_client_eglcounter
<Chipaca> tedg: it works
<Chipaca> tedg: but if instead i point to the qml apps' libs, with everything else staying the same, it fails to connect:
<Chipaca> $ MIR_SOCKET=/run/mir_socket LC_ALL=C  XKB_CONFIG_ROOT=./xkbcommon/data/ LD_LIBRARY_PATH=$PWD/xkbcommon:/apps/qmlapp.sideload/0/usr/lib/x86_64-linux-gnu/:/apps/qmlapp.sideload/0/usr/lib/x86_64-linux-gnu/mesa-egl/ /apps/mir/snap1/debs/usr/bin/mir_demo_client_eglcounter
<Chipaca> Can't get connection
<Chipaca> tedg: so my current working hypothesis is that I should go and make dinner
<dandrader> a client get a mir resize event of, say (100,100). but as it keeps swapping buffers it never ever reaches a buffer of that size. is it possible?
<dandrader> I mean, is a mir client ensured to eventually find a buffer matching the size of the last surface resize event it received?
<anpok_> yes
<anpok_> or yes I see that behavior on wily
<anpok_> and was debugging it
<anpok_> wait .. here is a trace.. http://paste.ubuntu.com/11877355/
<dandrader> anpok_, you also debugging https://bugs.launchpad.net/qtubuntu/+bug/1473720 ?
<ubot5> Ubuntu bug 1473720 in qtubuntu "keyboard stops working, maliit and unity8 consuming cpu" [High,In progress]
<anpok_> dandrader: the first resize and the buffer matches.. but since there is a new size it needs to redraw to the destination size 399,524.. meanwhile the user keeps resizing and again the exchanged buffer has a new size..
<anpok_> the redraw seems to block the event loop.. so thread 1 seems be always waiting for something in qtcore or qtquick...
<anpok_> when I manage to get back to the original expected destination size 399,524 (in the trace above) .. it stops requesting a redraw and mirevents are processed again
<dandrader> anpok_, so you mean that unity8 did sent all the mir-surface-resize events but the client just didn't process them all for some reason?
<anpok_> i believe so.. but not sure.. I manage to bypass the problem by blocking the render thread in the right places..
<anpok_> noticed that while testing 0.14.0 on desktop
<anpok_> oh keyboard going away is a resize..
<anpok_> so this on the phone too
<dandrader> anpok_, the only way it could happen is if QWindowSystemInterfacePrivate::handleWindowSystemEvent is synchonous
<dandrader> anpok_, no the keyboard going away animation is not done by resize
<dandrader> anpok_, the resize happens then unity8 hides or shows the indicators bar at the top
<anpok_> yes.. the default impl says async.. but hmm thats the next thing to look into..
<anpok_> ah
<dandrader> anpok_, as unity8 makes the input method surface match the screen size - the top bar size
<anpok_> maybe the render thread is just faster in releasing the lock and looking for new stuff
<anpok_> and locks again
<dandrader> anpok_, has a higher priority or something...
<dandrader> anpok_, that's interesting. I'll play around with some algorithms after lunch
<dandrader> anpok_, to solve that impasse
<kgunn> pcoca: are you trying on an amd64 arch ?
<pcoca> yes
<pcoca> amd64 VM
<pcoca> building the snaps on 15.04
<pcoca> and when I install (--allow-unauthenticated) I don't get the display
<kgunn> pcoca: ah...you know what, i had a problem to working with the phablet-tools on vivid....I think they have diverged to the point
<kgunn> where the wily phablet-tools are no longer kosher on vivid
<kgunn> i updated my machine here to wily and everything magically worked
<pcoca> OK, I will rebuild the snaps on 15.10 then and give it a try :)
<pcoca> thanks kgunn
<kgunn> pcoca: can you afford to work on wily? it would be a good second data point to prove that theory (e.g. phablet-tools for wily need to run on wily)
<pcoca> i'm building the snaps on another VM
<pcoca> so I will delete 15.04 VM and build everything from scratch on 15.10
<greyback__> dandrader|lunch: with shell rotation landed, I see no reason why the OSK surface needs to resize at all. It could be fullscreen all the time.
<dandrader> greyback__, yeah, I was about to investigate why we were resizing it in the first place. but I think you got the reason
<greyback__> yep. Still this resize bug is nasty
<dandrader> greyback__, yes, will fix it first
<greyback__> thanks
<kgunn> pcoca: ok, let me know your results, very interested
<racarr> https://twitter.com/xlibfunctions
<racarr> XkbGetMods(3): returns the moderators of the X11 mailing list, but ensures they are real and not virtual (unlike XkbGetVirtualMods(3)).
<racarr> lol
<kgunn> racarr: those are pretty funny
<dandrader_> anpok_, think I got a fix for this bug
<dandrader_> anpok_, and it's great as it essentially just deletes code :)
<anpok_> yay
<anpok_> is it the weird orientation change guess?
<dandrader_> anpok_, since there's no synchronicity whatsoever between the processing of mir-resize-events and the consumption of buffers (buffer swapping) as they happen in different threads and and sent through different IPC channels, I just have to loose things up
<dandrader_> s/and and sent/and are sent
<dandrader_> anpok_, ie, when I get a resize event I just trigger a "please redraw" event to qt and that's it]
<dandrader_> anpok_, instead of redrawing until the buffer size match the size advertised by the last mir-resize-event that got consumed.
<dandrader_> just have to do some more testing to be sure
<anpok_> ok .. so the important thing for mir would be that it never skips a resize event
<dandrader> anpok_, and I think it doesn't
<dandrader> anpok_, but it can easily happen in a resize animation that by the time the main thread reads a resize event that info is already outdated (ie, the render thread is already past that size)
<dandrader> anpok_, so the actual size information in a resize event is kinda useless
<greyback__> dandrader: fix looks reasonable, but haven't tested it yet. Will do so tomorrow morning
<dandrader> greyback__, tested on my laptop and on mako. works nicely
<greyback__> dandrader: there a big rush? Should I try now?
<dandrader> greyback__, you should be offline doing whatever you do after work :)
<dandrader> it sure can wait till tomorrow
<greyback__> dandrader: someone has to cover the hole that Saviq left us with ;)
 * Saviq not here
<dandrader> jesus....
<dandrader> you guys are nuts :)
<racarr> I hit the point yesterday where I was really starting to question continuing to hack up the android stack and write complex tests for what I was doing
<racarr> in hopes of deleting it in a few weeks for the
<racarr> libinput platform...
<racarr> soooo
<racarr> I decided to see how long it would take to just add relative pointer axis and put off raw events until
<racarr> after libinput
<racarr> the answer is not long at all I think its done
<racarr> testing ;)
<kgunn> racarr: can you parse your last blurb a little more?
<kgunn> are we now making libinput a pre-req for raw events?
<racarr> kgunn: Well maybe, but providing a way to unblock unity8
<racarr> immediately as well
<kgunn> racarr: you know what i like :)
<kgunn> thanks
#ubuntu-mir 2015-07-15
<duflu> greyback__: I might be imagining things but my phones feel more laggy. Did we disable input resampling or something?
<greyback__> duflu: nope
<duflu> Hmm, probably imagined
<greyback__> dednick working on getting numbers for that, using mir's new perf work
<duflu> greyback__: Now is a very good time. We have incremental improvements that reduce latency in both 0.14 and 0.15
<duflu> And have more after that too. So it won't be sudden, but it is good solid progress
<duflu> When the improvements actually make it into distro, then they will be announced. In the past we've announced things and then had to revert them before they entered distro
<alf_> duflu: greyback__: FWIW, after installing silo 4 (mir 0.14) on mako, scrolling the apps scope feels more laggy than before the update
<greyback__> :(
<duflu> alf_: Is only Mir upgraded or other things too?
<duflu> Because I've spent months verifying Mir is actually faster in 0.14 than 0.13
<duflu> s/is/was/
<alf_> duflu: Here is the list of upgraded/installed packages: http://paste.ubuntu.com/11881589/
<duflu> alf_: OK then. Way too early to pin the blame on Mir 0.14 :)
<duflu> alf_: Also, it's advisable to never use the dash for latency testing. Because the dash has never been fast enough to keep up with 60FPS it will skip frames, which is visually misleading.
<duflu> ... you can't see subtle changes if your granularity is 33ms between frames to start with
<anpok> .. one possible purely speculative conclusion could be that we should look for things that cause problems and optimize those..
<alf_> duflu: I don't use it for latency testing. In the end it's the final visual impression that counts, however, and for some reason we have regressed on this in silo 4.
<duflu> alf_: Sure, it's always possible to do worse. Just that if you're looking for very small improvements in future, don't use the dash for visual testing because its performance is too erratic and unreliable
<anpok> i am really looking forward to see the perf test with the rest of the stack of the phone included
<anpok> just making tests with mir demos isnt really interesting
<duflu> Not fun and interesting, but really important. Because if you upgrade the whole stack (ie. that silo) then you have no chance of finding out which package made it slower
<duflu> At least not easily
<anpok> well the silo does not contain substantial changes in any of the other packages
<duflu> If true, then that's intriguing
<anpok> i mean .. take server changes.. qtmir plugs in new parts and has its own threading behavior and additional mutual exclusion (event vs render thread) .. so any measurements without that involved cannot be used to make statements about the new phone image
 * duflu is only going on what he knows. That is the latency improvement in Mir 0.14 works in isolation (if that's the _only_ thin you change on the phone). That was also months ago. Many things could have changed to affect the performance of the phone or Mir specifically.
<anpok> we replaced input dispatcher which.. should have no effect on qtmir because it has its own .. so it may effect usc..
<anpok> *affect
<kdub> streams having size and pixel formats makes little sense to me... buffers and surfaces have sizes, but streams are just a collection of buffers
<anpok> could it be that because of the double buffering branch the swap took longer..
<anpok> hmm but still  it happened even without.. so nm.
<anpok> kdub: what would be the size of a surface?
<anpok> or how is it defined..
<kdub> the size of the surface is the size that the surface is :)
<kdub> surface size is the intended composition size
<kdub> and buffer size is the actual size of the buffer
<anpok> kdub: so the primary size used to compose the buffers..
<kdub> anpok, right, the surface size is the size that the compositor will have the surface appear on screen
<kdub> and the buffer size is the same; its the size of the buffer
<kdub> and if the two differ, thats what scaling is for
<kdub> but differing should only be a transient scenario for resize
<kdub> and an intentional one if there's a stubborn video decoder, perhaps
<anpok> so if we report user input to the client... hmm
<anpok> which buffer size do we use
<kdub> surface size
<anpok> or surface size
<anpok> the size the client received as his last resize event..
<kdub> yes
<anpok> or .. instead .. the last resize event sent out to the clien
<anpok> t
<anpok> that could be different from the surface size
<kdub> well, no?
<anpok> and also  different from the buffer size
<kdub> surface size is the important one... when that changes, we send out the resize event
<anpok> right we do that instantly
<kdub> right, and the input changes at that point too
<kdub> and in the NewBufferSemantics, the client will arrange the transition of buffersize to match the surfacesize
<Guest16852> Hi All, I am a newbie, building the mir on ubuntu x86, 64 bit.
<Guest16852> But I am facing a problem, thanks in advance.
<Guest16852> Building CXX object src/platforms/mesa/server/common/CMakeFiles/mirsharedmesaservercommon-static.dir/buffer_allocator.cpp.o
<Guest16852> /home/rakesh/ubuntu_development/mir/src/platforms/mesa/server/common/buffer_allocator.cpp: In member function âstd::unique_ptr<mir::graphics::Buffer> mir::graphics::mesa::BufferAllocator::reconstruct_from(MirBufferPackage*, MirPixelFormat)â:
<Guest16852> /home/rakesh/ubuntu_development/mir/src/platforms/mesa/server/common/buffer_allocator.cpp:240:5: error: âgbm_import_fd_dataâ was not declared in this scope
<Guest16852>      gbm_import_fd_data data;
<Guest16852>      ^
<Guest16852> /home/rakesh/ubuntu_development/mir/src/platforms/mesa/server/common/buffer_allocator.cpp:241:5: error: âdataâ was not declared in this scope
<Guest16852>      data.fd = package->fd[0];
<Guest16852>      ^
<Guest16852> /home/rakesh/ubuntu_development/mir/src/platforms/mesa/server/common/buffer_allocator.cpp:248:31: error: âGBM_BO_IMPORT_FDâ was not declared in this scope
<Guest16852>          gbm_bo_import(device, GBM_BO_IMPORT_FD, &data, package->flags),
<Guest16852> Can any one please help me, where to find out the definition for function gbm_import_fd_data and GBM_BO_IMPORT_FD
<Guest16852> Even I have successfuly installed the mesa library on my machine
<anpok> Guest16852: do you have gbm.h?
<anpok> installed..
<Guest16852> let me check
<anpok> oh you are on ubuntu..
<Guest16852> [00:24 rakesh@param build]  :  locate gbm.h
<Guest16852> /home/rakesh/ubuntu_development/mir/tests/include/mir/test/doubles/mock_gbm.h
<Guest16852> /usr/include/gbm.h
<Guest16852> yeh it seems
<anpok> go to your mir source dir and type 'dpkg-checkbuilddeps'
<Guest16852> [00:27 rakesh@param mir]  :  'dpkg-checkbuilddeps'
<Guest16852> dpkg-checkbuilddeps: Unmet build dependencies: android-headers (>= 4.4.2) umockdev (>= 0.8.7)
<anpok> could you check the mesa version or actually the libgbm-dev version installed
<anpok> maybe we need to ensure that the gbm headers are new enough
<anpok> as in the version shown in 'apt show libgbm-dev'
<greyback_> anyone give me some hints on debugging this: [1436970458.912329] <ERROR> mircommon: Caught exception at Mir/EGL driver boundary (in queueBuffer): /build/mir-UAyS26/mir-0.13.4+15.04.20150709.2/src/client/rpc/stream_socket_transport.cpp(168): Throw in function virtual void mir::client::rpc::StreamSocketTransport::send_message(const std::vector<unsigned char>&, const std::vector<mir::Fd>&)
<greyback_> Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorIN3mir25socket_disconnected_errorEEEEE
<greyback_> std::exception::what: Failed to send message to server: Broken pipe
<greyback_> 32, "Broken pipe"
<greyback_> happens sometimes when I have multimonitor setup and I unplug the second screen
<Guest16852> @anpok, this is my gbmlib version installed
<Guest16852> Version: 10.1.3-0ubuntu0.4
<anpok> so thats trusty..
<anpok> but it should have those structs defined
<Guest16852> Yup, I am using 14.04
<anpok> oh that was added in 10.2
<Guest16852> @anpok, so do I need to upgrade the libgbm-dev ????
<anpok> yes.. mir can only build with mesa newer than 10.2
<Guest16852> Thanks mate.
<Guest16852> let me try
<Guest16852> is there any apt-get install package?
<Guest16852> or do I need to build the source code again?
<anpok> oh you could try picking a newer mesa release, but that might require you to also install a newer libdrm .. and might run into further troubles..
<anpok> install as in .. trying to build it locally..
<anpok> it might be simpler to just go to utopic or even vivid
<Guest16852> Thanks mate, I will install the 15.04 then
<Guest16852> that is the easiest way I reckon.
<rakesh__> Thanks anpok
<anpok> welcome - happy hacking.
<rakesh__> Yoo too
<greyback_> unping - it's a symptom of the server dying
<anpok> oh which server? .. i mean nested or host?
<greyback_> anpok: host
<greyback_> http://pastebin.ubuntu.com/11882995/
<anpok> oh
<kdub> greyback_, did the server die?
<greyback_> kdub: yeah
<greyback_> https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1474891
<ubot5> Ubuntu bug 1474891 in mir (Ubuntu) "USC crash on multimonitor unplug" [Undecided,New]
<kdub> seems like a mir bug, can probably look this afternoon
<kdub> or a hwc bug maybe :)
<greyback_> kdub: any info I can supply that might help?
<greyback_> while I've things set up
<kdub> greyback_, maybe how often it occurs
<greyback_> kdub: it's not guaranteed, maybe 30% of the time
<kdub> greyback_, alright, will let you know what I see
<greyback_> kdub: cool, thanks
<greyback_> kdub: I think it's easier to repro on the N4
<greyback_> C++ advice please: http://pastebin.ubuntu.com/11883287/
<greyback_> that fails to compile, as DisplayConfigurationOutputType is an enum, not a class
<greyback_> anyone know any trick to avoid having to put :: qualifiers in from of the enum names in that switch?
<greyback_> i.e. I can do "typedef mg::DisplayConfigurationOutputType out" and then use out::lvds
<greyback_> but if I can avoid that, it would be nice
<anpok> using out = DisplayConfigurationOutputType;
<anpok> oops
<anpok> using out = mg::DisplayConfigurationOutputType;
<greyback_> anpok: I'll still need to do out::lvds then yeah?
<anpok> yes
<greyback_> ok, I guess that'll do
<greyback_> thanks!
<kgunn> Chipaca: just checking in, i believe you got mir launching ok....and were just having issues with the qml part...is that right ?
<kgunn> just in case you still needed some help
<kgunn> Chipaca: also, did you end up having to have some sort of patched drm or mesa driver ? curious what that was, if any
<Chipaca> kgunn: no, we patched libxkbcommon, but that's all for now
<Chipaca> kgunn: however
<Chipaca> HOWever
<Chipaca> kgunn: anything other than the demo clients that ship with mir can't connect
<Chipaca> kgunn: so rather puzzled by that
<kgunn> weird... Chipaca so you couldn't build the qtclock snap like i did in the doc ?
<kgunn> ...or well, build, instlal and run
<Chipaca> kgunn: i don't know the doc you mean :-/
<kgunn> Chipaca: this one...
<kgunn> https://docs.google.com/document/d/14msTXe_cFulk9z4jFptEjFJzZx58b1mWU_r4VivLkfA/edit
<kgunn> qt clock reference app (towards the bottom)
<Chipaca> ah!
<Chipaca> no, i haven't tried that, i will do so now
<Chipaca> kgunn: are you around for a bit more?
<kgunn> yes Chipaca, will be interesting
<kgunn> Chipaca: the patch to  libxkbcommon, is in wily itself already ? or something separate ?
<Chipaca> kgunn: not in wily, no; it's http://pastebin.ubuntu.com/11882626/
#ubuntu-mir 2015-07-16
<attente> hi, is there a way for me to change the attachment rectangle of a menu/tooltip surface without destroying and re-creating it?
<anpok_> attente: mir_surface_apply_spec(the_surface, updated_spec) should work.
<attente> anpok_: thanks!
#ubuntu-mir 2015-07-17
<robert_ancell> RAOF, back?
 * conyoo good morning o_O
<seb128> seems like the new mir landing in wily is busted, it triggered  bootest regression errors and I installed it on a device and unity8-dash abrt on start
<seb128> just letting the channel know
<seb128> unsure who is looking after that landing/update
<seb128> kgunn, ^
<anpok> i am looking at that right now
<anpok> I tried mako this morning.. worked as expected
<seb128> can you reproduce or do you need info?
<anpok> now trying on krillin
<seb128> k
<seb128> seems also whoever did that landing forgot to rebuild some libmirclient8->libmirclient9 rdepends
<seb128> ciborium ubuntu-push-client url-dispatcher
<greyback> kdub: hey, so I cross-built your branch locally, copied the mirserver lib to the device, rebooted. All looks ok. But when I plugged in a monitor, hang. Here's a backtrace: http://pastebin.ubuntu.com/11892528/
<greyback> kdub: would you prefer I do a proper build & install? Just in case?
<anpok> seb128: how did you discover that ciborium depends on libmirclient8?
<kdub> greyback, the fix is contained in the graphics-android.so.2
<greyback> kdub: gah, ok
<seb128> anpok, that's the ones that fail to update with wily-proposed enabled
<seb128> anpok, but seems like it's a depends chain and that url-dispatcher is the one that need a rebuild
<anpok> seb128: yeah I had an mp for url-dispatcher prepared, just forgot to add it.
<greyback> kdub: god news, that seems to have fixed it
<greyback> good even
<kdub> yay
<greyback> nice one
<kgunn> seb128: anpok just trying to understand, how did seb128 see bootest regression and we didn't ? i'm kinda hinting, what could we do to avoid in future
<seb128> kgunn, I didn't do that in front, I'm just looking at why mir is blocked in proposed (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt)
<seb128> sorry, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<kgunn> seb128: ah...i mean not good, but good it got caught in proposed
<kgunn> so machinery worked ;)
<anpok> hm it would have turned up when somebody tries to remove the old client libraries
<dandrader> what's the name of the env var I should use to tell the filepath of the socket file my mir server should use?
<dandrader> ok, it's MIR_SERVER_FILE
<tedg> Seems like Mir isn't linking to protobuf? https://bugs.launchpad.net/ubuntu/+source/url-dispatcher/+bug/1475619
<ubot5> Ubuntu bug 1475619 in url-dispatcher (Ubuntu) "url-dispatcher ftbfs with GCC 5" [Critical,Confirmed]
<tedg> (in wily)
<tedg> Added a Mir task
#ubuntu-mir 2015-07-18
<racarr> Happy weekend \o/
#ubuntu-mir 2016-07-18
<tjaalton> RAOF: hi, still around?
<duflu> tjaalton: I think he's on vacation for a while. Maybe back at some point this week briefly
<tjaalton> duflu: ok, there was just a thing with the mir egl patch for mesa, missing 'break;'s since an update to it 3y ago, wondering if it was a mistake
<tjaalton> uploaded 12.0.1 btw
<duflu> tjaalton: I have a collection of bugs in the mir egl patch :)  https://bugs.launchpad.net/ubuntu/+source/mesa/+bugs?field.tag=egl-platform-mir
<duflu> Woo Mesa 12
<tjaalton> needed just a slight rebase, and noticed these
<tjaalton> duflu: oh, well I can fix 1473091 on the distro
<duflu> tjaalton: You mean 1473901? You're my hero
<tjaalton> ah right
<tjaalton> but doesn't dropping those affect other users of gm_dri_is_format_supported?
<tjaalton> gbm_*
<duflu> tjaalton: It's just a mistake we introduced in the patch. I think it's safe for us to remove it
<duflu> Certainly it would be nice for it to finally work
<tjaalton> oh right
<tjaalton> actually, upstream added XBGR8888 there, so our patch no longer carries that
<tjaalton> that's new with 12
<duflu> tjaalton: Added it in Mesa 12.x?
<duflu> As in it should work properly now?
<duflu> I know a certain Xmir bug that might benefit from that
<tjaalton> yes
<duflu> Oooh, I thought it would never happen
<duflu> tjaalton: Great news assuming it's not a mistake. XBGR8888 is the same thing as RGBX for Android. But why would Mesa support XBGR but not ABGR?
<tjaalton> well, ABGR was already added but not to that function so not really useable
<tjaalton> aiui
<duflu> tjaalton: Still one of those switch cases is wrong
<duflu> Which is better than two
<tjaalton> ok I'll drop the other one
<duflu> tjaalton: Yeah at least till upstream adds it intentionally.
<duflu> It might work now, but that would only be by accident
<tjaalton> and then we'll get it for free
<duflu> tjaalton: Looks like a possible upstream bug in the April 2016 change though. They should have added GBM_FORMAT_ABGR8888 at the same time
<duflu> Because Android requires it
<tjaalton> ah
<duflu> But simply having a case statement for it may not be enough. Safer to omit it till it's fully implemented upstream
<duflu> Could be enough for Mir. Not enough for other projects
<tjaalton> right
<alan_g> anpok: did you have a chance to try https://code.launchpad.net/~alan-griffiths/miral/fix-1603086/+merge/300220?
<robert_ancell> duflu, what did you have in mind with rethinking how LightDM launches USC?
<duflu> robert_ancell: No idea :) It's a requirement rather than a design
<robert_ancell> duflu, what's the requirement?
<duflu> robert_ancell: Just easier control/restarting of unity-system-control independently of lightdm
<robert_ancell> duflu, that
<robert_ancell> that's a pretty severe operation - do you expect the sessions to survive?
<duflu> robert_ancell: OK, nevermind. I found unity-compositor-command=/usr/bin/env ... works
<robert_ancell> nice
<duflu> robert_ancell: Hmm, though could you simply stop lightdm from deleting the environment of unity-system-compositor?
<robert_ancell> duflu, you mean inherit the lightdm environment?
<duflu> robert_ancell: Yeah I guess
<robert_ancell> it's worth considering
<alan_g> duflu: you should also be able to create unity-system-compositor.conf to put options in.
<duflu> alan_g: I was wondering that but found no default file existed
<alan_g> I guess no-one has found a need for it yet
<duflu> I'd still rather not publicise file formats at all till there's a strong need to standardize them
<duflu> Oh. I could also have given --options to unity-compositor-command
<anpok> alan_g: oh it seems I have been using it all day now
<alan_g> So the latest version (from Friday) works for your use case?
<anpok> yes
<duflu> alan_g, anyone, remember the workaround for "GtkSettings Cursor Theme: Unsupported GDK backend
<duflu> " ?
<alan_g> how are you getting that?
<duflu> alan_g: nautilus via gtk on Mir (Unity8)
<duflu> Oh that's not the crash. Just a message that precedes the crash
<duflu> Nevermind
<alan_g> Mmm... may not be the thing you've hit. But there are issues running gkt apps as root (that I've yet to dig into). I use -arw-file and run as a normal user.
<duflu> Not running as root.
<duflu> anpok: Hey can you add 'nautilus' to your list of GTK apps to test? :)
<duflu> I just realized I test Xmir with it lots, but never Mir native
<duflu> Found it. Turns out that's a bug I fixed elsewhere.
<duflu> anpok: If you're interested, I've possibly fixed the same bug elsewhere already: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1603923
<ubot5> Launchpad bug 1603923 in nautilus (Ubuntu) "nautilus crashes when run under Mir" [Undecided,New]
<anpok> oh yes .. cursor settings is on my list of things to be resolved soonish
#ubuntu-mir 2016-07-19
<sil2100> Hello!
<sil2100> We would need to have mir building all required binaries for arm64
<sil2100> For xenial+ (so xenial and yakkety essentially)
<sil2100> I tried a test build in my xenial-enablement silo but it fails to build due to some files missing during install
<sil2100> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-004/+build/10483762
<duflu> sil2100: Please join in then: https://bugs.launchpad.net/mir/+bug/1579866
<ubot5> Launchpad bug 1579866 in Mir "Android graphics platform doesn't get packaged for arm64" [Medium,Triaged]
<duflu> Europe wakes up, and Launchpad buckles, times out instead of working.
<duflu> Time to change focus
<sil2100> duflu: thanks! Could someone bump the priority up? Since this is a critical bug from our xenial POV
<sil2100> duflu: without this fixed we cannot get xenial arm64 images building for testing
<duflu> sil2100: Well I've run out of time to do what I was doing. Will attempt a proposal for you now
<duflu> May or may not work
<sil2100> duflu: thanks! Just modifying the debian/control parts didn't do the job
<duflu> Oh
<sil2100> duflu: the link I attached has a build log from that attempt ;)
<sil2100> It's missing some files during install
<sil2100> So maybe the build system doesn't build something for arm64 that it should?
<sil2100> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-004/+build/10483762 <- I used a test MP with the debian/control changes to see where we're at
<sil2100> dh_install: missing files, aborting
<sil2100> Looks like pretty critical files seem to be missing
<duflu> sil2100: Did you also change 'rules'?
<duflu> Search armhf
<duflu> I'll try...
<sil2100> No, I didn't go that 'deep' ;)
<duflu> sil2100: Because 'rules' tells it to not build the android platform (drivers)
<duflu> I've proposed a branch
<sil2100> \o/
<duflu> Might not work
<duflu> But meeting now
<duflu> then EOD probably
<sil2100> Yeah, let me forward that to my test branch and rebuild, seeing if it fails on my silo
<sil2100> duflu: thanks for looking into that
<duflu> No problem
<duflu> sil2100: On that note we also have an Nvidia driver and 'rules' tells packaging to not build that either (!?)
<duflu> It's also not totally finished
 * duflu wonders if Larabel is listening
<tedg> bregma: Can one run U8 yakkety in qemu?
<bregma> tedg, I don't think so , for lack of Mir-capable drivers (just like on a RasPi)
<tedg> bregma: Ah, okay. I thought that I had done it once, but not sure how.
<tedg> bregma: Is there a way to do SW rendering?
<bregma> I keep asking the Mir guys that and I never get a completely straight answer, but I don't think so
<kdub> tedg, I think goldfish, the android emulator, might work (in the sdk?) but haven't used that in a long time
<kdub> and iirc, that's qemu-based
<tedg> kdub: Cool, we'll look.
#ubuntu-mir 2016-07-20
<Mirv> duflu: do you have a chromebook with the gfxboot issue or just polishing bugs?
<Mirv> I was meaning to try to figure out how to rip off gfxboot from image (like unetbootin does, but unetbootin does not work for 16.04 images anymore), but then again my main problem with my chromebook is that the seabios cannot boot from internal SSD which makes installing Ubuntu there a bit useless.. (even though it works, I used 14.04.4). so I'm using chroot for now.
<duflu> Mirv: Yes I have one, but have other priorities than hacking it right now. My previous experiences told me not to install Ubuntu onto the Chromebook itself. Because unless you can access the hardware write-protect switch it will default to giving you a warning on boot up... and then hitting the wrong key will clobber the Ubuntu setup
<duflu> Better to install Ubuntu to USB or SD or something
<Mirv> duflu: that's true too, you can't disable the easy-to-push-destroy without disabling the write protect. then again, it seems quite well documented what screw to unscrew to disable write protection. but your idea of using Ubuntu from USB/SD would actually be the solution for my SeaBIOS problem too, so maybe I should actually try to find time to modify 16.04 image to be bootable.. or I could use the unetboo
<Mirv> tin for 14.04.4/.5 and upgrade that to xenial
<Mirv> I'd like to run Unity 8 / Mir / everything over there since it's a touch enabled chromebook too
<duflu> Yeah Chromebooks are handy hardware. It would be good for Ubuntu if we supported them a bit better
<Mirv> the SUSE's gfxboot developer did his best. then again if we would get _UEFI_ boot working (whatever it needs) instead of legacy we wouldn't be using gfxboot in the first place
<duflu> Mirv: Chromebooks have EFI??
<Mirv> but it seems it's still TODO and not WIP for eg GalliumOS too
<Mirv> duflu: AFAIK that's what it tries to boot when pressing "Ctrl+U" instead of "Ctrl+L", but I really do not have slightest idea what kind of Coreboot payloads or such it'd need
<duflu> Mirv: I thought Ctrl+U was for ChromeOS USB sticks only?
<duflu> U for USB, not UEFI
<duflu> L for legacy (Ubuntu)
<Mirv> duflu: well hmm at least some have certainly hacked TianoCore (UEFI) on top of Coreboot and have Xubuntu running https://github.com/GalliumOS/galliumos-distro/issues/112
<duflu> Mirv: BTW don't expect Mir to start just yet: https://bugs.launchpad.net/mir/+bug/1169020
<ubot5> Launchpad bug 1169020 in Mir "[regression] Mir gives up too easily - std::exception::what: Failed to find the current VT" [Medium,Triaged]
<duflu> Mir doesn't support VT-less kernels (ChromeOS)
<duflu> I hope that's the only hurdle
<Mirv> oh, ok. well Unity 8 on X.org for starters then would be my goal..
<duflu> Also Mir has at least two other minor kernel requirements that ChromeOS may not meet
<duflu> They would all need workarounds
<Mirv> ...a goal for some rainy day I get that chromebook out of the drawer
<Mirv> duflu: well if we're booting Ubuntu we're not running ChromeOS?
<Mirv> only coreboot + seabios and then normal kernels and everything
<duflu> Mirv: I mean the Crouton option... which is better for armhf chromebooks
<Mirv> ah well crouton is totally else yes, that's what I have at the moment
<Mirv> my chromebook is x86, similar to https://www.amazon.com/Acer-Chromebook-CB5-132T-C1LK-Certified-Refurbished/dp/B01GK8URL2/ - 4GB, 32GB, quad-core 14nm Atom with Broadwell era graphics
<Mirv> with crouton I only got KDE Plasma 5 working with xenial, and even that needed some hacking. the script is badly out of date but Unity(7) wouldn't start even after removing the unity-2d referrals
<duflu> Mirv: I recall last time I tried the only workable option was either 12.04 or 14.04 and then partially successful upgrade
<Mirv> duflu: it's still the same unless you do some fixing in /tmp where crouton unpacks its scripts, and run then from there
<Mirv> but with a couple of fixes xenial installation is possible
<Mirv> for KDE I was simple fixing the plasma-desktop package name to point to the current KDE5  name
<duflu> I feel Ubuntu should be keeping up with consumer devices like Chromebooks and Windows tablets better than it is...
<Mirv> Plasma is useful for me since I can test Qt 5 with that at least
<alan_g> namecheck for anpok - https://who-t.blogspot.co.uk/2016/07/libinput-is-done.html - congrats
<anpok> oh wow
<alan_g> camako: this has changed again since you approved, still happy? https://code.launchpad.net/~alan-griffiths/mir/add-mir_surface_spec_attach/+merge/300202
 * camako looks
<camako> alan_g, LGTM
<alan_g> camako: thanks
<greyback> alan_g: "placement" is a funny word instead of position. How come?
#ubuntu-mir 2016-07-21
<duflu> robert_ancell: Could just about do another Xmir release now. The most important bugs of the moment are fixed. I'm just trying to figure out how to fix up launchpad git so that 1.18 is the default branch...?
<robert_ancell> duflu, I've changed the default
<duflu> robert_ancell: Thanks. I assume I couldn't see it without admin
<robert_ancell> It was https://code.launchpad.net/~xmir-team/xorg-server/+git/xmir/+edit
<robert_ancell> probably admin required
<duflu> Nope, I just lacked the URL
<duflu> robert_ancell: I do want to try for more Xmir fixes but no need to wait... I might achieve zero more in the short term
<robert_ancell> ok, I'll upload to Yakkety
<duflu> Ta
<duflu> robert_ancell: Ha. I just landed another one, but not important
<robert_ancell> duflu, I just noticed... :P
<duflu> Well nobody else ever noticed that one but me. So you don't need to include it this time
<alan_g> greyback: https://code.launchpad.net/~alan-griffiths/mir/add-mir_surface_spec_attach/+merge/300202/comments/774172
<greyback> alan_g: replied. MirPlacement wfm
<alan_g> greyback: ta
<alan_g> greyback: I'm looking into exposing output changes in miral and was wondering about miral-qt/src/platforms/mirserver/screen.h - are any of the second block of methods actually used anywhere? Or are they just there because its easy?
<greyback> alan_g: scale, formfactor, etc?
<alan_g> I'm mostly thinking of pixelFormats(), modes() which I don't see used in the project and are not overrides
<greyback> alan_g: mostly because they were easy
<greyback> possibly cruft left over
<greyback> I don't see any reason to keep them
<alan_g> There's no "magic" access to them then from downstream?
<alan_g> greyback: thanks, if I don't need to support them (yet) I won't.
<greyback> alan_g: not that I'm aware of
<greyback> alan_g: hey, from miral::WindowInfo, how can I distinguish a window having a parent or not? WindowInfo::parent() returns a Window, but it could be null
<greyback> i.e. default instantialized
<alan_g> I use "if (auto parent = info.parent())" a lot
 * greyback never likes that syntax. I read the operation as assignment, which I never think of as being able to fail
<greyback> alan_g: ok, that'll work
<greyback> ta
<alan_g> 1. it isn't assignment, 2. the result of assignment isn't success/fail
<alan_g> greyback: how close are we to having something we can demo rendering using Qt?
<greyback> alan_g: I have rendering, I'm working on the surface positioning now
<alan_g> Isn't that just implementing the "advise_xxx" hooks?
<greyback> alan_g: yep, but child window positions not correct, digging into why
<alan_g> if you need help I'm interested
<greyback> alan_g: ack
 * alan_g has been fixing "window positions not correct" reported from toolkits for a couple of weeks
<greyback> I think it's my issue, as miral-shell is working correctly
<alan_g> It *could* be missing "advise" calls - I found a few
 * alan_g remembers he wanted to provide an optional logging wrapper around the WMP
 * camako sees that 0.23.4 has landed
#ubuntu-mir 2016-07-22
<Mirv> duflu: btw the discussion with you did inspire me to a working solution. I installed Ubuntu from USB stick to another USB stick on my another computer, and then booted that up on the Chromebook, therefore bypassing gfxboot
<Mirv> since gfxboot is only used on live usb for the legacy boot
<duflu> Mirv: Oh good trick
<duflu> I might try that
<duflu> anpok_: vscroll events are now magnitude 1.0 for mouse wheels. Is that new?
<duflu> Weren't they 1/15 before?
<duflu> greyback_: Figured out why touchpads in Unity8 don't feel very accurate. We convert the floating point input to integers :P
<greyback_> duflu: we do? Where?
<duflu> greyback_: handleWheel* ... QPoint
<duflu> rather than QPointF
<duflu> Touchpad two-finger scrolling is normalized... a float usually less than 1.0
<duflu> 1.0 just means "the same amount as a mouse wheel tick"
<greyback_> duflu: ok, nice find. Patch on the way?
<duflu> greyback_: Sorry, I need to get more Xmir done before EOW
<greyback_> duflu: bug logged?
<duflu> (just added smooth scrolling there too)
<duflu> greyback_: Yep, top of the Qtmir list
<duflu>  anpok_: vscroll events are now magnitude 1.0 for mouse wheels. Is that new?
<duflu> I'm not complaining, but I thought it was 1/15th before
<zone42314> hi
<zone42314> how do you run gedit on mir from cli?
<alan_g> zone42314: GDK_BACKEND=mir gedit
<zone42314> Failed to connect to Mir: Failed to send message to server: Success
<zone42314> (gedit:11651): Gtk-WARNING **: cannot open display:
<zone42314> doesn't work
<alan_g> Which Mir server are you running? What arguments?
<zone42314> i'm using the terminal app on unity8
<zone42314> not on server
<zone42314> i need to launch gedit from terminal app
<zone42314> but using mir gdk mir or whatever is called
<alan_g> U8 needs something like GDK_BACKEND=mir gedit -- --desktop-file <some desktop file>
<alan_g> In this case Unity8 is your Mir server
<zone42314> alan_g: some programs just throw and error if you use -- args
<zone42314> how do you launch them?
<zone42314> if you can't use --
<alan_g> zone42314: that's not my doing
<zone42314> where to ask?
<zone42314> unity channel?
<alan_g> you may need MIR_SOCKET=/tmp/mir_socket too
<kdub> #ubuntu-touch or #ubuntu-unity might be good places
<zone42314> ok thanks
<kdub> although most the people there hang out here and vice versa
<alan_g> But that ought to be set if the terminal's running under U8
<zone42314> SDL_VIDEODRIVER=mir supertux2 -- --desktop_file_hint=unity8.deskop
<zone42314> Error: Unknown option '--''. Use --help to see a list of options
<zone42314> :(
<zone42314> is there a way to workarround this error?
<alan_g> zone42314: no point (yet) SDL_VIDEODRIVER=mir supertux2 doesn't work on any mir servers
<zone42314> what does ubuntu-app-launch do?
<zone42314> looks like you can launch supertux2 with 'ubuntu-app-launch supertux2'
<zone42314> and i don't see using Xmir
<alan_g> That probably starts an Xmir server
<zone42314> but then i should see the Xmir in top
<zone42314> right?
<alan_g> True
<zone42314> but i don't
<alan_g> What system you running? Xenial?
<zone42314> 16.10
<alan_g> Ah. That may have a more recent SDL than I've got
<zone42314> ibsdl2-2.0-0/yakkety,now 2.0.4+dfsg2-1ubuntu1 amd64 [installed,automatic]
<zone42314> probably not
<alan_g> Is ubuntu-app-launch a script?
<zone42314> hey, i'm here for help :D
<zone42314> don't now :(
<zone42314> i can't c/p from Xmir pff
<zone42314> it's on lp
<alan_g> Sorry, wife calling "lunch"
<zone42314> bon apetite
<zone42314> appetit
<bregma> zone42314, supertux2 does not run natively on Mir, it definitely requires XMir
<zone42314> bregma: but if it runs with Xmir, you should see the Xmir process in top, right?
<bregma> XMir does not use a lot of CPU
<bregma> do a ps-ef | grep -i xmir
<bregma> because supertux2 uses libSDL2, it should theoretically run OK natively on MIr, but it turns out is uses some X11 calls outside of libSDL, so it will fail
<zone42314> bregma: i don't have ps-ef, do i need to install ps-watch?
<bregma> the root of that problem is that it uses the "glew" OpenGL extension wrangler library, which has a hardcoded assumption that Linux == X11
<bregma> zone42314, there should be a space between the 'ps' and the '-ef'
<bregma> I am running supertux2 on a test machine right now....
<bregma> $ ps -ef | grep -i xmir
<bregma> stephenw 13490 13486  4 08:54 ?        00:00:00 Xmir -rootless -title @ -displayfd 3 -mir yakkety_supertux2_0.0
<zone42314> 12385 11641  0 15:56 pts/19   00:00:00 grep --color=auto -i xmir
<zone42314> i only see this
<zone42314> bregma: how did you launched sueprtux2?
<bregma> zone42314, I have it in a libertine container, I just click on the icon in Unity 8
<zone42314> bregma: but libertine uses Xmir
<zone42314> no?
<bregma> yes
<zone42314> no
<bregma> like I said, it won't run natively on Mir
<bregma> it == supertux2
<zone42314> but it runs on my pc
<zone42314> sudo apt install supertux2
<zone42314> ubuntu-app-launch supertux2
<bregma> zone42314, is that from Unity 8?  Are you running on a Mir server at all?
<zone42314> it's from unity8
<zone42314> i'm running the game from the terminal app with ubuntu-app-launch
<bregma> and it runs?
<zone42314> because -- --deskop_file_hint=unity8 gives an error
 * bregma has been wrong before
<zone42314> because suerptux2 doesn't like the -- arg
<bregma> why do you have a -- in there at all?
<zone42314> bregma: how do you launch apps in unity8-desktop from terminal app
<zone42314> you need to use -- --desktop_file_hint (i think?, right?)
<bregma> you need to pass the appropriate .desktop file to ubuntu-app-launch
<zone42314> how do you run gedit or nautilus for ex?
<bregma> zone42314, I use libertine for X11-based programs
<alan_g> greyback: have updated. Happy now? https://code.launchpad.net/~alan-griffiths/miral/monitor-outputs/+merge/300740
<bregma> zone42314, if you have a native Mir application, and its .desktop file is set up properly, you should just have to pass the .desktop file name to ubuntu-app-launch (no --desktop-file-hint or -- or anything)
 * bregma install supertux outside of a container to play with it
<zone42314> bregma: thanks :D
<zone42314> i think that's how i launch supertux :P
<greyback> alan_g: approved
<zone42314> bregma: does it work? :D
<alan_g> I doubt supertux2 works without Xmir, it fails for both me and duflu (https://bugs.launchpad.net/mir/+bug/1605074/comments/13)
<ubot5> Launchpad bug 1605074 in xorg-server (Ubuntu) "supertux2 has two mouse pointers (one should be hidden)" [Undecided,Confirmed]
<bregma> zone42314, I have a slow internet connection, so it takes a while.....
<bregma> zone42314, I modified the .desktop file by adding the magic X-Ubuntu-Touch=true stanza, and launched using 'ubunti-app-launch supertux2' but the app crahes on startup
<bregma> haven't figured out why yet (need a backtrace) but my guess is the libglew problem I mentioned earlier
<bregma> same thing if launched from the Unity 8 Dash
<alan_g> bregma: duflu agrees (see above comment)
<alan_g> It doesn't work natively with the miral shell either
<zone42314> bregma: oh. i'm super confused right now because it works fine for me
<bregma> zone42314, well, until I've analyzed my crash I won't commit to why it doesn;t work for me
<alan_g> bregma: An SDL game that works (well starts up) natively is 7kaa
<bregma> alan_g, 7kaa is known to start on the demo Mir server, not necessarily on Unity 8
<alan_g> Exactly. But supertux doesn't work at all with the Mir backend
<alan_g> U8 is whole additional set of opportunities
<bregma> indeed
 * bregma takes the dog for a walk while he waits for stack traces to run with his pokey network connection
<alan_g> Lucky dog
<alan_g> zone42314: "it works fine" with X-Ubuntu-Touch=true in the desktop file?
<zone42314> alan_g: i don't see x-ubuntu-touch in any of the 2 supertux2 desktop files
<zone42314> /usr/share/app-install/desktop/supertux:supertux2.desktop
<zone42314> /usr/share/applications/supertux2.desktop
<alan_g> Then I would guess that ubuntu-app-launch defaults to using an Xmir server. And we know that works (for a suitable value of "works").
<zone42314> alan_g: i am playing supertux2
<zone42314> and killing the Xmir at the same time
<zone42314> nothing happens
<zone42314> there is no Xmir running
<greyback> thanks XMir for stealing all my input. And thanks kernel for not giving me a usable VT!
<alan_g> greyback: Bad luck! But why would XMir steal all your input?
<greyback> alan_g: am genuinely unsure. I Alt+dragged the XMir window, and from then on compiz refused to let focus switch away from xmir. As if mouse clicks disappeared somewhere
<alan_g> Xmir or mir-on-x?
<greyback> oh
<greyback> mir on x
<greyback> yes, my bad
<greyback> mirX
<alan_g> That sounds like camako's grabs going wrong. It's been working for me though.
<greyback> it was a once-off, usually it's ok
 * camako reads the backlog
 * alan_g remembers "once-off" that waited until after release before becoming "always"
<camako> hmmm, greyback have you filed a bug?
<greyback> camako: if I can reliably reproduce it again, I will
<greyback> am not managing it now that I try
<camako> greyback, did you alt+drag an app running inside mir-on-x or mir-on-x window itself?
<camako> You shouldn't be able to alt+drag mir-on-x
<zone42314> alan_g: Xmir
<zone42314> bash: /usr/bin/Xmir: No such file or directory
<zone42314> alan_g: and i can still play supertux2
<greyback> camako: alt+drag working for my qtmir-based mir-on-x! It moves the window around my X desktop
<zone42314> bregma: i've removed Xmir and supertux still starts
<camako> greyback, beats me
<greyback> *shrug*
<alan_g> zone42314: ack
<zone42314> alan_g: i have to take a brake, see ya guys and thanks for help
<alan_g> greyback: great news! Can we ship it? ;)
<greyback> :)
 * alan_g has CLion "run"ning on Xmir on MirAL shell
<alan_g> does it have to be so laggy?
<bregma> yep, traceback showsupertux crashing in XQueryExtension, which is completely consistent with the glew issue
<bregma> zone42314 must be running an X server somewhere else if he's able to launch it and run it successfully
<alan_g> Agreed
<alan_g> greyback: I've just thought that CanonicalWindowManagerPolicy has two roles that ought to be separated. 1. the default WM wiring (which you want) and 2. interpreting events (which you don't). Do you agree? Can you suggest good names?
<greyback> alan_g: I do agree
<greyback> names... lemme think
<greyback> wow, was it something I said? :)
<alan_g> I'm inclined to leave CanonicalWindowManagerPolicy with 1 and move the event handling into miral-shell
<alan_g> Were they all in germany?
<greyback> mpt isn't
<anpok_> hm
<greyback> err actually, he might be
<greyback> alan_g: +1 on your suggestion
#ubuntu-mir 2017-07-21
<ChrisTownsend> greyback: Hey, are you able to connect to Canonical irc?
<ChrisTownsend> greyback: nm, it just started working:)
