#ubuntu-mir 2013-03-11
<robert_ancell> What is the review process for mir? If one person and jenkins have OK'd code does the reviewer set the MP to approved or do you leave that for the proposer?
<robert_ancell> RAOF, ^?
<RAOF> robert_ancell: I believe the reviewer can set that, but I don't know if it's documented
<robert_ancell> RAOF, what have people been doing?
<robert_ancell> also, is one human review sufficient (as long as they are confident in it)
<RAOF> Again, I think so.
<RAOF> As far as I'm aware, reviewers have been setting it to approved.
<robert_ancell> ok, I'll do that then
<Leyland> Are there example or demo clients that show the use of input?
<Leyland> I am able to build and run the demo_client_accelerated on X, using my wrapper libraries that map mir and EGL calls to X and glx, but I don't have anything to see how input works.
<alan_g> Leyland: not yet. input is a work-in-progress
<Leyland> Thanks! :)
<Ranomier_> Hey there i used ubuntu for a long time because i was new in linux now im using gentoo/archlinux, because i want go deeper. Anyway, is there a differenz between mir and wayland?
<Ranomier_> *difference xD
<FunnyLookinHat> Ranomier_, yes.  :)  https://wiki.ubuntu.com/MirSpec
<FunnyLookinHat> (It's in the topic)
<FunnyLookinHat> An even breakdown by RAOF of the design differences specific to Wayland: https://plus.google.com/u/0/113883146362955330174/posts/PXc93m8nKwk
<FunnyLookinHat> *even better breakdown
<Ranomier_> mmmh and why it where developed bihind closed doors?
<Ranomier_> why u guys said 5 or 6 months ago hey that thing in wayland is not good for us, we thinking about mir ...
<Leyland> Too many chefs spoil the broth?
<Ranomier_> No thats not the point, im not talking about that the source code was behind close doors, im talking about the idea and the problems u have with wayland ...
<Leyland> I'm just asking if that was the reason, I don't know myself
<FunnyLookinHat> Ranomier_, there's plenty of public discussion on that in the various social networks ( primarily in the comments of the post I linked ) - afaik this is a place for technical discussion, not philosophic arguments :)
<Ranomier_> im not at g+ and fb ... and now?
<Ranomier_> Sry but for this single point a want a answer, why u not just saying something?
<Ranomier_> why u develop 6 months and no one knows it ... everyone thought u using wayland. My company too.
<arti> so, G+ post say basicaly two things that wayland lacked 6 month ago: 1) no input stack (then write one,  less work then dooing everyhing from start) 2) server-side buffers (pach it and send upstream, less work then dooing everything from start)
<arti> gui toolkit's would be needed to rewrite anyway but just not qt and gtk have to support 3 backends(x11, wayland, mir) instead of two (x11, wayland) whitch means more work
<Ranomier_> yeah thats technical reasons and good reasons, but how about saying something 6 months ago?
<arti> yes, not talking with developers is the worst part
<Ranomier_> sry for my bad english, my pasive vocabulary is good, but active ...
<arti> mine isn't better either but everything sould be readable
<Ranomier_> ubuntu is for people ... i missunderstand this sentence ... it is not for all people - it is for the users majority. And u think they dump. U dont care about the developers that are users too
<Ranomier_> our company thinked and tested code with wayland and ubuntu, but now ...
<Ranomier_> next time just say something!
<Leyland> Ranomier, out of curiousity what project are you working on that uses Wayland?
<Ranomier_> iptvÂ´s for hospitals
<Ranomier_> they are touchsreen
<Ranomier_> just say something, NOW! Sry but im a little angry
<Leyland> I'm not sure Wayland is dead from Mir, especially if they both can leverage the same universal EGL backend.
<Ranomier_> http://xkcd.com/927/ !
<arti> i hope that it doesn't get that bad but i gues it already is that bad
<arti> x11, wayland, mir, directfb
<Leyland> Ha, I don't think it's that bad, I created a thin wrapper of some EGL functions over GLX and I was surprised by the symmetry. In fact the last project I worked own was in essense faking OpenGL on 2d blitting hardware
<Ranomier_> "this is a place for technical discussion, not philosophic arguments" it is not philosophic it is a company decision!!!
<Leyland> I think we got the wrong impression with what you initially said.
<Ranomier_> yeah and now please tell me why u not said something in the past, said that aspects of the wayland project is not what u need....
<vibhav> ...
<vibhav> This channel is for technical discussion regarding Mir
<FunnyLookinHat> vibhav, +1  :)
<Ranomier_> ok then i join #ubuntu-mir-company-decisions and then im alone ... why u cant tell me in short words here why not.
<vibhav> Sure
<FunnyLookinHat> vibhav, Are you https://plus.google.com/u/0/107393039276001104013/posts ?  If so I'm https://plus.google.com/u/0/107253373337628904473/posts - nice to meet you  in IRC  :)
 * vibhav hugs FunnyLookinHat 
<vibhav> \o/
<FunnyLookinHat> 0/
<Ranomier_> ok where i can post or write something, to get the imformation about ur silence 6 months ago.
<Ranomier_> ?
<Ranomier_> have i to register at g+ to get an answer?
<vibhav> Ran
<vibhav> Ranomier_: sorry, but can you rephrase what you said?
<Ranomier_> ok, i want to now why canonical said they are using wayland then develop mir behind closed doors wothout saying something? And other comanys think they can develop and test code for wayland with ubuntu.
<arti> he want's to know why didn't canonical contact wayland devolopers about their shortcoming before starting Mir
<Ranomier_> no not only the wayland developer
<arti> well everyone
<arti> why didn't they tell everyone about mir from the start
<Ranomier_> now i and we rephrase our answer ... and now?
<Ranomier_> Ihr seid beton kÃ¶pfe, genau wie siemens enterprise. U are concrete heads, just like siemens enterprise.
<Ranomier_> ok i have no time for that my girlfriend is waiting for me at home, i have to go bye for now but i coming again, day for day^^
<Ranomier_> im reading the news im waiting for ur answer. bye
<racarr> Hmm. Today does not seem to be the day where I have a mystical epiphany on the mysterious prepare-for-inprocess-egl jenkins failure
<racarr> :(
<thechef> Is Mir a fake-project designed to emulate competition to wayland developers so the finally implement binary driver support?
<R__> my understanding is that binary drivers that work for Mir will also work for Wayland
<R__> or at least that's what we're being fed right now ;p
#ubuntu-mir 2013-03-12
<racarr> RAOF: Im here!
<RAOF> racarr: Oh! Because you've got ops!
 * RAOF was scanning the user list, and you weren't where I expected :)
<racarr> :)
<racarr> https://code.launchpad.net/~robertcarr/mir/prepare-session-manager-for-input-focus/+merge/152806 for the bored reviewers :)
<RichardMIchaels> I am not really opposed to Mir, but I think canonical ought to do what it can to share the same application and driver base as Wayland, including by providing a MIr backend that can display a Mir session to an X server.
<RAOF> We do indeed plan to do that (an X backend for Mir)
<RichardMIchaels> Which would gaurantee that any application that could run on Mir could run on an X server, including waylands rootless x server
<RAOF> No, that's not what it would guarantee. For that, you'd need a rootless Mir compositor, which doesn't make sense.
<RichardMIchaels> thas good to hear
<RichardMIchaels> If you can display an entire rootless Mir session to an X server, it would indirectly allow Mir applications to to be displayed to a hardware X server or a wayland X server.
<RichardMIchaels> If you could also allow Mir applications one by one to be displayed rootless to an X server, that would be great
<RichardMIchaels> One of the issues is that there is a lot of old hardware out there, old video cards with no acceleration. the only driver for them is in the X server. Since qt and gtk support multiple backends, its not a big issue for those apps. The concern is that some people will make Mir only applications in the long run. So, its good to gaurantee that any Mir app can be displayed in someway to an X server.
<RichardMIchaels> You would probably need a software OpenGL render that would render the things coming from a Mir app into an X protocol stream
<RichardMIchaels> Mesa is capable of that
<RAOF> brb
<RichardMIchaels> another thing you could do is allow the user to create a rootless Mir session and then allow them to run a mirvncserver to allow it to be accessed by VNC. I would be happy with that
<RichardMIchaels> This would give you remote desktop capabilities and also allow Mir to be used on a computer with a hardware connected X server
<RichardMIchaels> that hits two birds with one stone
<RichardMIchaels> by rootless Mir session, I actually mean headless.
<RichardMIchaels> a headless Mir session
<racarr> My suspiscion is that for running Mir on old cards with no acceleration a framebuffer based graphics platform in mir would be most appropriate
<RichardMIchaels> So, the Mir session runs, but, it does not display to a video card. Instead, its output goes out to VNC clients via a VNC server
<racarr> And applications and mir can use whatever software GL implementation is available that can work on memory mapped buffers
<racarr> if you have an X driver you can do this.
<racarr> It might even be simpler than that if a good abstraction in GBM can be found.
<racarr> Haven't thought about it deeply though and am just about to take off for a while :)
<RichardMIchaels> Right. X drivers use framebuffers, and in some cases a 2D driver API called XAA, if i am correct.
<duflu> Awesome to see other people are making Mir to be clang compatible. I was going to eventually...
<RichardMIchaels> On the old hardware, you would either need to run an X server and then display a MIR session to it. or you would need to work the X drivers into Mir.
<RichardMIchaels> Or into KMS/DRI type Linux APis
<RichardMIchaels> clang is a cool compiler.
<RichardMIchaels> Clang claims to support all of C++ up to the 98 standard. Software needs to be ported to it must use a lot of GCC only features. But Clang even supports many GCC features.
<RAOF> We don't use any (afaik) GCC only features. We *extensively* use C++11, though :)
<RichardMIchaels> i see
<RichardMIchaels> clang is working on full C++11 support if am not mistaken
<Mirv> I do hope there won't be a mirvncserver or I'm going to have serious trouble on IRC
<Mirv> although I guess irssi can be taught to avoid highlighting particular phrases :)
<Cheery> sup?
<RAOF> Mirv: Surely irssi doesn't highlight on substring matches?
<Mirv> RAOF: for me it does, because in Finnish we conjugate all words in so many ways that I need to
<RAOF> Heh
<Cheery> I just looked into example code.
<Cheery> I think EGL should be abstracted away. but this looks somewhat okay otherwise.
<Cheery> one thing though. why do you want server side buffer allocation?
<Cheery> hmm.. in other hand, MIR should not abstract away EGL.
<Cheery> (EGL should be abstracted away, because we do not want such software that refuses to run because the platform is w rong)
<Cheery> (but then.. we already have this stupid separation between GL_ES2  and GL2, and GL_ES3 vs. GL3, and GL4
<Ranomier_> Lets try today again.
<Ranomier_> can somebody tell why canonical not just said someting about their plans 6 months ago? I dont talking about opening source code, im only talking about that their where able to just say: "hey we dont like that and that in wayland, we build our own display server".
<Ranomier_> companys testet code with wayland on ubuntu and that work is for nothing
<RAOF> Who tested code with Wayland on Ubuntu?
<duflu> Ranomier_: Yes, it's true there have been some public Ubuntu wiki pages floating around talking about how Ubuntu would support Wayland. However those alone were no contract committing Canonical to using Wayland. Canonical has the freedom to build what it likes. And I'm not sure what companies you're talking about testing with "Wayland on Ubuntu"... ?
<duflu> Furthermore, Wayland is a protocol. So even if Ubuntu "used" Wayland, we would still need to build a display server for the Wayland protocol; Mir.
<Ranomier_> @1: comm'on it is clear that there so no contract with the comunity. Ubuntu is for people and we are a family and we tell us so importand things. @2: Thats not display server u only have to replace weston.
<duflu> Cheery: I believe the main driver for server side allocation was the Android driver platform. Not sure. tvoss/alf can confirm.
<Ranomier_> weston is the reference compositor, its just there for testing wayland.
<duflu> Yes, that's my point. Even to "support Wayland", Canonical would still need to build a display server and it may as well be called Mir. So it's really just an argument over protocols.
<Ranomier_> ok wait, what is weston 1. a display server 2. a compositor ?
<tvoss> duflu, even more so, it's a question of a unified egl client platform, and that does not necessarily mean a protocol but a sane way of people to interface with an existing EGL client platform and the ability to define display server specific behavior
 * duflu can see tvoss's hands waiving in the air around a virtual architecture diragram
<duflu> diagram
<tvoss> duflu, :)
<tvoss> duflu, more like saying: The android client-side EGL platform proposes a very similar approach, and it is quite elegant and straight-forward
<tvoss> Cheery, for server-side buffer allocation: The decision used to be mostly driven by the android driver model, yes
<Cheery> tvoss: does it affect client side or compositor?
<tvoss> Cheery, how do you mean?
<duflu> Ranomier_: Outside of the X-world, the display server is typically the thing you build and it happens to do "composition". So platforms other than Xorg generally do not have "compositors", but display servers that do composition. This is supported by the statement here --> http://wayland.freedesktop.org/
<Cheery> tvoss: does it affect the protocol between client or compositor, or render buffer creation of the client, or compositor's access into the buffers or modesetting?
<tvoss> Cheery, it does to some degree, yes. If you do not have a client-side buffer allocation scheme, the client only needs to get hold of a surface, and start rendering and eglSwapBuffers advances the underlying buffers in a steady-state manner. Server-side, the surface could be backed by an arbitrary number of buffers
<Ranomier_> but i cant belive that if ur talked to the community u can together make wayland what u need 6 months ago ... and i cant belive thats more of work.
<Cheery> Ranomier_: I don't know who am I talking with yet, so I ignore the 6-month claim entirely.
<Cheery> Ranomier_: I suggest you do so too.
<tvoss> alf_, please correct me if I'm wrong but access into buffers or modesetting is not affected @Cheery's question
<Cheery> tvoss: so it'd be practically different on client-side?
<duflu> That's an interesting question. Surely the client/server-side buffer argument is an implementation detail. The client API will never make it obvious which is being used.
<duflu> (It's opaque and abstracted)
<Cheery> and the protocol would not shift direction in passing a handle?
<tvoss> Cheery, from a toolkit-perspective: no, it would be transparent to an app-developer. and as duflu points out, it is an implementation detail in the end
<Ranomier_> ok, a complete other thing martin said he wonÂ´t support mir in kwin, because it is only one distro.
<RAOF> He's welcome to that; if Mir becomes awesome he might find it useful to build a KWin compositor on top of Mir, but that's unlikely.
<alf_> tvoss: Cheery: that is correct (if I understood the question correctly)
<RAOF> Cheery: For reference, I'm in the process of changing the GBM buffer passing from flinked gem buffers to dma-buf fds. Clients don't see a change.
<tvoss> RAOF, you might want to clarify what is unlikely
<tvoss> :)
<RAOF> Ranomier_: There's already a KWin branch turning it into a Wayland compositor; it's unlikely that they'd want to throw away that work.
<duflu> KWin fans will still have the option of logging into KWin running on X, running on xmir. I'm sure that would work right now. Do we need to make a video?
<duflu> RAOF^
<RAOF> duflu: It'd totally work now; I'm not going to make a video right now, though :)
<duflu> RAOF: Yeah sorry. I wasn't asking you to
<Cheery> if compositor, client, and protocol between them doesn't change, I don't know why it matters to Mir or Wayland.
<duflu> RAOF: In fact it's the evening. Surely you have family stuff :)
<RAOF> Well, as long as I lined up all the bits; the dma-buf transition is incomplete, so trunk of everything doesn't quite work together.
<Cheery> since it means both of them could  use either client-side allocated or server-side allocated buffers.
<Cheery> depending of platform
<Cheery> it's something that is flushed under driver API anyway.
<RAOF> Just to be clear - clients *can* care, if they choose to. If they want (or need, like XMir) access at a lower level than EGL, they get to pay the price of dealing with that.
<Cheery> lower level than EGL.. doesn't that mean going under the binary blob driver that supplies the EGL?
<Cheery> also I'm letting you know one thing.
<Cheery> XMir becomes obsolete in 2 years
<Cheery> once things really work
<Cheery> I couldn't care less about dysfunctional X programs that belong to 1985 and are never used or ported to Mir/Wayland
<Cheery> so if something does bit inefficiently there, nobody cares
<Ranomier_> an associate asking is there source code of mir?
<Cheery> yes. I studied it just small while ago
<Ranomier_> where i can find it?
<Cheery> https://wiki.ubuntu.com/MirSpec
<Cheery> https://launchpad.net/mir
<Cheery> http://bazaar.launchpad.net/~mir-team/mir/trunk/files
<Cheery> they're having just egl example  program right now.
<Cheery> I hope they'd get some beta API for nvidia really soon
<Cheery> that's what everybody cares about anyway
<duflu> Cheery: Canonical knows very well that a desktop without Nvidia support is not a desktop. And nouveau's not really good enough right now.
<Cheery> things fall into place once that hapens
<Cheery> after that we'll get chrome ported to Mir pretty fast, as well as steam.
<Cheery> then everybody are using Mir.
<Cheery> the tension has been building since 1997
<Cheery> I think it'll also get the steamboxes and all that stuff by valve rolling up
<Cheery> linux becomes a practical desktop and we'll see things are going to change and fast
<Cheery> it's also time bomb for Mir.
<Cheery> once nvidia gets the API rolled out, Mir will work by the end of this year, or there will be something else that does the thing.
<Ranomier_> if canonical worked upstream in wayland, where would we be now?
<Ranomier_> i mean wayland is ready, mir not ...
<Ranomier_> if i see the version number of mir 0.0.2
<Ranomier_> ...
<alf_> Ranomier_: probably at the same (or worse) place, since the bulk of the work is in the display server implementation itself, not the protocol
<Ranomier_> ok the wayland protocol is well defined for ur usecases, but the core not?
<Ranomier_> i mean many companys say now, lets wait ... we build our products on x until they maked a decision wich where the standart. becouse a co existend of wayland and mir is horror^^
<Ranomier_> because*
<alf_> Ranomier_: I depends on the product. In most cases you don't really care whether it's X11 or Wayland or Mir, because you are using a toolkit that shields you from the details.
<Ranomier_> my company builds iptv with a telephone for hospitals.
<Ranomier_> we have our own toolkit^^
<Cheery> Ranomier_: I don't see it that way.
<Cheery> X is retarding system, not an option if there's something alternative.
<Ranomier_> im not a programmer in my company im only a admin^^
<Cheery> also you have web for things that really always need to work.
<Ranomier_> But x has many performance problems with vsync.
<Cheery> also it's again.. freedom of choice
<Cheery> there will be commercial apps for both Mir and wayland.. and systems ported for both
<duflu> Ranomier_: Vsync problems are mostly driver issues. Except when they're compositor bugs like with Compiz 12 months ago for example
<Cheery> there will be compositors made for both protocols.
<Ranomier_> and linux is again cluttering
<Cheery> I think next thing they freak after is the audio system
<Cheery> but it's not as bad thing as this was.
<Cheery> linux audio problems are mostly made by linux devs.
<Cheery> not by some company that decided to force everyone into Xorg flavour of linux.
<Ranomier_> i like systemd of poetering but pulse is fail. an audio system should an part of the kernel and it has to stand alone, no alsa->pulseadio-jack things.
<Cheery> that decision was as if someone had excreted into ice cream pool.
<Cheery> "now you only eat this kind of ice cream bwahahahaaha!!"
<Cheery> "take that! freedom!"
<Cheery> "you have freedom to eat ice cream, as long as there's crap in it."
<Cheery> Ranomier_: I think MIDI should be phased out from audio system
<Cheery> it's not audio
<Cheery> it's more like peripheral input/output
<ezakimak> qq: any possibility/plan to make use of the enlightenment evas/other libs?
<bryce> ezakimak, no plans that I'm aware of
<ezakimak> just heard that their software renderer is very fast, no idea if their code could be reused in mir though.
<robert_ancell> racarr, can you set me to be a channel op?
<mhall119> robert_ancell: you can probably request it in #ubuntu-irc
<racarr> robert_ancell: Done
<racarr> was lunching
* robert_ancell changed the topic of #ubuntu-mir to: Mir - http://launchpad.net/mir https://wiki.ubuntu.com/MirSpec
<robert_ancell> racarr, ta
<racarr> I introduced a rather difficult merge conflict for myself ;) one of these days I will learn how to use version control
<RAOF> kdub: Yo!
<RAOF> kdub: Did you see the rest of my ping yesterday, re: AndroidClientBufferDepository?
<kdub> RAOF, ah yes... i left it building somewhere in one of these terminals...
<kdub> RAOF, i'll give it a try, it looked like it would work
<RAOF> kdub: I hadn't yet done the refactoring; I wanted to ask if what the constraints were first.
<RAOF> Why are all blog comment systems terrible?
<kdub> RAOF, the constraints are that I found that mapping/munmapping buffers repeatedly on android doesn't work
<RAOF> kdub: Oh, so once you've seen a buffer you *have* to keep it around *forever*?
<kdub> RAOF, unfortunately thats what I've  found :/ we can munmap it  once we're done with it forever
<kdub> RAOF, let me find you the header....
<kdub> https://github.com/CyanogenMod/android_hardware_libhardware/blob/jellybean/include/hardware/gralloc.h
<kdub> function 'unregisterBuffer' (munmap) makes it an error to call 'registerBuffer' (mmap) on the buffer once you've let it go
<RAOF> Meep.
<RAOF> Ok, so if I refactor out ClientBufferDepository I need to ensure that Android keeps all its buffers forever.
<kdub> yeah, its weird
<RAOF> Actually... couldn't we handle this server-side, in cooperation with the client library?
<RAOF> kdub: If the server guaranteed that it wouldn't send a buffer more than 3 frames old (ie: if we're triple buffering), then the client library could forget buffers older than 3 frames.
<RAOF> kdub: The small flaw I can see is the framebuffer - if we only have 6 framebuffers to play with, maybe we can't do that.
<kdub> RAOF, i like that rule... but i think that 3 limit should be adjustable
<RAOF> kdub: By whom?
<kdub> we can do n-buffer swapping, and the android api's allow the drivers to acquire more than 1 at once
<kdub> so if the driver starts requesting 2 buffers at once, or if we're doing n-buffering
<RAOF> We currently only do double or triple bufferring, and throw an exception if we try and do anything else :)
<RAOF> I'm not averse to having the server tell the client how many buffers it needs to remember, though.
<kdub> RAOF, sure, as long as the number is adjustable, its ok by me :)
<RAOF> I'll initially do it as a construct-time property; if that needs to change at runtime, we can make the change when we need it ;)
<kdub> sure
<racarr> hmm
<racarr> I've changed my hmm to nvm
#ubuntu-mir 2013-03-13
<robert_ancell> duflu, did you convert all the propietary bugs to public?
<duflu> robert_ancell: Yes, after briefly reviewing them
<robert_ancell> duflu, thanks
<robert_ancell> Can anyone explain to me what the application name is used for in the connect message?
<robert_ancell> thomi, is the Mir documentation online?
<RAOF> robert_ancell: I *think* that's just a placeholder that'll be replaced by the application's UUID?
<robert_ancell> RAOF, That was my guess. I'm trying to work out why we don't just use that for the system compositor instead of this lightdm_id
<RAOF> robert_ancell: That's how I *set* the lightdm_id.
<robert_ancell> RAOF, no, there's a separate parameter in the connect call right?
<RAOF> No?
<RAOF> mir_connect(socket, id, callback, ctx);
<RAOF> Is what xmir calls; that's the same as what a normal client would call.
<robert_ancell> RAOF, don't you use mir_connect_with_lightdm_id?
<RAOF> No?
<robert_ancell> (/usr/include/mir/client/mir_client_library_lightdm.h)
<RAOF> I don't include that file :)
<robert_ancell> RAOF, I guess it probably doesn't work then!
<RAOF> mir_connect_with_lightdm_id, or XMir? Or, I guess, Mir? :)
<robert_ancell> RAOF, XMir
<RAOF> It works as far as I can tell?
<RAOF> As in: I can log in and it works.
<RAOF> I may not have tested user switching, I guess.
<robert_ancell> RAOF, yeah, it's only going to matter when switching
<RAOF> It switches from the greeter to my login session fine :)
<RAOF> I guess it doesn't switch between users; I haven't tested that :)
<robert_ancell> RAOF, that one is implicit, because the greeter gets destroyed and since mir is just stacking then the session must become visible (and visa versa)
<robert_ancell> RAOF, ok, cool. I think I'll just propose we remove the ID
<RAOF> Sounds sensible.
<RAOF> I AM THE FACE OF MIR!
<RAOF> Real, honest to goodness emails. Oldschool.
<RAOF> Earnestly warning me that we're destroying linux.
<duflu> RAOF: So, you basically designed all of Mir, right ? :)
<RAOF> That's right.
 * duflu runs
<RAOF> From the GROUND UP!
<bryce> RAOF, ground up... beef?  to feed trolls? ;-)
<RAOF> From the ground up dreams of wayland developers!
<RAOF> Emulsified with the tears of linux enthusiasts.
<bryce> aaa!  choices bad!  we want some choice other than X, but please not more than 1!
<duflu> LOL. Beautiful summaries.
<duflu> Nice to see that Mir has /supposedly/ revived progress on Wayland for Redhat...
<duflu> I'd like to see Wayland succeed as much as Mir...
<alan_g> +1
<Ranomier_> +1
<alan_g> alf_: did you see my post to mir-devel? (Just checking)
<alf_> alan_g: hmm, no, I guess we need to subscribe manually
<alan_g> alf_: we do
<mmrazik> alan_g: I received it (in case you asking if the mails as such are getting delivered)
<alan_g> mmrazik: cool - I was really checking to see who has subscribed. ;)
<mmrazik> :)
<kdub> good morning, status, working on the nex4 display/hwc support today
<alan_g> kdub: are you subscribed to mir-devel?
<kdub> yes, just checking mail now
<alan_g> alf_: do I need to forward the mir-devel email? (Would like to get some feedback)
<alf_> alan_g: No need, I can read it from the archives (but I am deep in multi-threaded android code now...)
<alf_> kdub: I get some failing integration tests on nexus 4. Is this normal?
 * alan_g is jealous: he's trying to work out where to submit a patch to google-glog - code is much more tractable.
<kdub> alf_, i know of one.. haven't debugged it yet
<kdub> alf_, TestClientIPCRender
<alf_> kdub: right, and I also get a segfault in AndroidBufferIntegration.buffer_ok_with_egl_context
<kdub> alf_, yes i see that too
<alf_> kdub: In AndroidBufferIntegration.display_cleanup_ok I see some very suspicious memory errors with valgrind
<kdub> alf_, i haven't debugged that yet, but valgrind on android doesn't work that well
<kdub> unhandled syscalls
<alf_> kdub: btw, multi-threaded compositing seems to mostly work on the nexus 4 with your branches. I am puzzled, though, because AndroidBufferIntegration.display_cleanup_ok aborts with a double-free when I make current a pbuffer surface instead of a window surface in AndroidDisplay.cpp (no threads involved)
<kdub> well, its good it seems to mostly work :)
<kdub> that is strange, maybe my plan today will be, branch work, investigate the integration tests for a while, and then hwc work
<alan_g> thomi: what progress on http://unity.ubuntu.com/mir?
<racarr> Morning
<alan_g> racarr: are you subscribed to mir-devel?
<kdub> mmrazik, that shell script split for crosscompile you requested is in btw
<mmrazik> kdub: I noticed. thanks
<mmrazik> was preparing some environment for it
<racarr> alan_g: Hmm maybe not
<alf_> racarr: good morning
<alan_g> racarr: if you didn't see my email to it...
<racarr> alf_: Morning :)
<racarr> alan_g: I see the email...I will write back soon I need
<racarr> to think about that
<alan_g> racarr: then you're subscribed. ;)
<racarr> status today is still working on setting input focus and receiving input I kind of got stuck in circles yesterday
<racarr> I don't think there are any problems though, I was just scatterbrained yesterday afternoon. have a failing integration test :)
<racarr> alan_g: Hmm re:prepare-session-manager-for-input-focus. I think that makes sense but I am not sure what the object is yet.
<racarr> perhaps the object is the surface controller and it lives in shell
<racarr> if create_surface_for is called from ApplicationMediator though
<racarr> how does the session come to own the surface?
<alan_g> racarr: because the session is passed as the first parameter to the call
<alan_g> obviously create_surface_for() can call session->create_surface()
<racarr> ohhhh
<racarr> I understand
<racarr> I think it's
<racarr> SessionStore
<racarr> it makes even more sense if it's called
<racarr> Shell
<racarr> Shell::create_surface_for seems like an appropriate method
<alan_g> \o/
<alan_g> racarr: now reply to that email
<racarr> ok
<racarr> I will "reply" I didnt actually get the email
<racarr> even though I have a verification email for subscribing to the list from before
<alan_g> racarr: there are *still* merge conflicts.
<alan_g> did you forget to "push"?
<racarr> alan_g: ok emailed
<racarr> really?
<racarr> just a second maybe my push hung
<racarr> oh hold habit and I accidentally pushed to ~rocket-scientists instead of ~robertcarr
<racarr> err... no.
<racarr> the opposite
<alan_g> racarr: ~rocket-scientists is correct this time
<racarr> :)
<racarr> ok pushed for real (r502)
<alf_> kdub: I have the impression that we aren't supposed to deallocate the EGLNativeWindowType created by android_createDisplaySurface(); it's deallocated for us when we call eglDestroySurface() for the associated EGL window surface.
<alan_g> racarr: looks better
<alan_g> racarr: where did you email reply? I don't see it, and it isn't in the mir-devel archive.
<alan_g> kgunn: what's happening with mir-devel ^
<kgunn> alan_g: let me check
<kgunn> alan_g: racarr stange....i see alan_g's original mail in the archive
<kgunn> and i just got a mail of racarr's...with the ability to approve/disapprove
<alan_g> kgunn: can you see if racarr is subscribed?
<alan_g> (Sounds like he's a non-member)
<kgunn> alan_g: ok...looks like he was a member....but the admin interface lets you filter
<kgunn> i marked racarr as someone who should be accepted always
<alan_g> kgunn: I see it now - thanks
<kgunn> racarr: i take it back
<kgunn> you are not a member
<kgunn> weird
<kgunn> racarr: i just added you
<racarr> Thanks :)
<alan_g> racarr: re prepare-for-inprocess-egl-clients - please make better use of the new directory structure.
<Cheery> how is it going around here?
<kdub> Cheery, well :)
<Cheery> well?
<mmrazik> kdub: is the install-on-android script supposed to work? I'm getting these: http://pastebin.ubuntu.com/5611775/
<mmrazik> I'm talking about "bash: libboost-system1.49.0: command not found
<mmrazik> "
<kdub> mmrazik, its not handling the failure in installing protobuf well
<mmrazik> kdub: isn't there some '\' missing?
<mmrazik> kdub: this looks a bit suspsicious to me: https://pastebin.canonical.com/86760/
<kdub> mmrazik, yes, there are
<sturmflut> How can I test Mir? I got it to build on my Ubuntu 13.04 install and the server binary runs okay, but all clients segfault after the connection to the server is established and the surface is created
<kdub> sturmflut, maybe you have a wrong version of mesa...
<sturmflut> The libgl1-mesa-dri and libgl1-mesa-glx are at version 9.0.2-0ubuntu1
<sturmflut> packages
<sturmflut> kdub: Which versions do I need? I just used the ones from the raring repository
<kdub> racarr, RAOF ^^
<RAOF> sturmflut: You need the packages from ppa:mir-team/staging
<RAOF> sturmflut: You're currently after mesa version 9.1~rc2-0ubuntu0+mir2-jenkins17
<sturmflut> RAOF: ah, that would explain it
<RAOF> The reason why you get segfaults is that your mesa doesn't have a Mir EGL platform, which is how the accelerated clients draw.
<RAOF> So the client tries to initialise and EGLDisplay, mesa doesn't find a match, then tries the default (of X11), which segfaults when you don't have a working X11 on the other end of $DISPLAY.
<RAOF> (This would be a mesa bug âº)
<sturmflut> RAOF: Okay, with the mesa packages from the PPA it works. Thanks!
<RAOF> There'll be a transition coming sometime soon where I'll break mesa in the process of switching the buffer-passing mechanism from flink to dma-buf; I'll only do that once everything's in place, though.
<sturmflut> So when do you think the most basic pieces of Mir and the toolkits (Qt, GTK+ etc.) will be in place? Is the project state on https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-converged still correct?
<kdub> sturmflut, there  is a qpa for qt
<sturmflut> kdub: sounds good
<sturmflut> kdub: The target release for the switch to Mir on the desktop is still 14.04?
<kdub> sturmflut, the blueprints are up to date :)
#ubuntu-mir 2013-03-14
<sturmflut> kdub: How will window decorations be handled in Mir? Server-side or client-side?
<kdub> sturmflut, current thinking is client-side, but its still up in the air... your thoughts welcome
<robert_ancell> kdub, good point. thomi, can you set up ci and automatic PPA building for lp:qmir into lp:mir-team/staging?
<sh4rm4> so mir uses C++ and boost, right ?
<RAOF> Indeed.
<sh4rm4> ah. i heard someone saying that boost apps are very slow to compile and templates will expand to a lot of code
<sh4rm4> in other words, bloat
<sh4rm4> is that correct ?
<sh4rm4> also, he said something about massive ram usage. he said that i possibly want be able to rebuild mir on a netbook with 512MB RAM
<sh4rm4> *won't
<RAOF> He probably wouldn't want te rebuild mir on a netbook with 512MB of ram, no.
<RAOF> But that's more because a netbook with 512MB of ram is terribly, horribly underpowered, and won't build *anything* well :)
<sh4rm4> because of the compilation times ?
<sh4rm4> well i built an entire linux distro in 3 days on an efika mx
<sh4rm4> 800 mhz, 512MB RAM
<sh4rm4> about 300 packages
<RAOF> You would no longer be able to do that :)
<sh4rm4> :(
<RAOF> You couldn't do that for Ubuntu *now*; firefox and libreoffice (at least) would trigger the OOM killer.
<sturmflut> kdub: Personally I think server-side decorations are better because they provide a unified look for all windows regardless of the toolkit and the controls (minimize/maximize/close) would still work if the client freezes. Also the decoration theme developers would have to rewrite their themes for every toolkit and all applications not relying on the latest version of one of the big toolkits would use different decorations,
<sturmflut>  resulting in chaos. Client-side decorations may offer more flexibility but I think the negative sides outweigh the positive ones.
<sturmflut> RAOF: I agree, I've seen single gcc instances using more than 1 GB of RAM
<sh4rm4> btw: why was CMAKE chosen as a build system ? in the eyes of a packager, it's horrible - doesnt even support DESTDIR
<RAOF> sh4rm4: Mir's build is much lighter than that; I can have 5 parallel g++ processes in 4GB of ram, so you'll be able to build in under a GB of ram easy.
<sh4rm4> RAOF, even with debug info ?
<RAOF> sh4rm4: Because all build systems suck, and the person who did the initial build system thought cmake sucked the least.
<RAOF> It's not terrible, and we've got plenty of cmake packages working fine.
<RAOF> sh4rm4: Indeed with debug info
<sh4rm4> well, autoconf *can* at least be used sanely, and it's at least freestanding and straightforward to use: ./configure --prefix=/ --enable-feature && make -j2
<RAOF> cmake can be used just as sanely.
<RAOF> *I'd* prefer autotools, but that's because I've got a huge amount of experience with their utter terribleness.
<sh4rm4> whereas invoking cmake requires a ton of options, cmake calls back into itself, and needs a C++ compiler to begin with
<sturmflut> sh4rm4: cmake does support DESTDIR
<sh4rm4> example of a build script for a cmake-using app (mysql) https://github.com/rofl0r/sabotage/blob/master/pkg/mysql#L19
<sh4rm4> in comparison, postgresql: https://github.com/rofl0r/sabotage/blob/master/pkg/postgresql
<sh4rm4> sturmflut, oh ? how is it being passed ?
<sturmflut> sh4rm4: You pass it to the "make install" command
<sh4rm4> hmm i wonder why that doesnt work with mysql
<sturmflut> I just tried it with mir and it worked
<RAOF> sh4rm4: Eh; fix your tools. http://bazaar.launchpad.net/~mir-team/mir/trunk/view/head:/debian/rules is a much nicer package build âº
<sh4rm4> btw, doesn't the usage of C++ objects, which are usually dynamically allocated, lead to much higher mem consumption and slow speed due to repeated malloc calls ?
<sh4rm4> according to the mir overview page, one of the design goals is speed
<sh4rm4> thinking along the lines of this paper:  http://domino.watson.ibm.com/comm/research_people.nsf/pages/nickmitchell.pubs.html/$FILE/oopsla2007-bloat.pdf
<RAOF> sh4rm4: Only if you repeatedly create objects? You can do that in C, too.
<sh4rm4> right, but that's not idiomatic C
<sh4rm4> whereas it's idiomatic OOP
<RAOF> It's *totally* idiomatic C!
<sh4rm4> this here is OOP style: if(string("xxx:xxx:xxx").split(":").elements(2) == "xxx") { ... }
<sh4rm4> you got 4 dynamic allocs in that line
<sh4rm4> in C you would deal with a buffer on stack
<RAOF> That's not particularly "OOP style"; that's just a bad interface.
<RAOF> Also, that paper appears to be all about the overhead of Java objects, which C++ doesn't have?
<sh4rm4> aren't java and C++ objects quite similar ?
<RAOF> No.
<sh4rm4> maybe C++ objects are even worse because they have a vtable
<RAOF> Java uses a VM; there's a certain amount of overhead involved in that.
<sh4rm4> that's at least one pointer overhead for each object
<RAOF> A C++ object only has a vtable if it's got a virtual member; and that's *exactly* what you'd do with a C struct.
<sh4rm4> you mean a C struct with function pointers ?
<RAOF> Indeed
<sh4rm4> you wouldnt do that
<RAOF> Perhaps you've not read much C? You do that _all the time_
<sh4rm4> that's a pretty bad style
<RAOF> I don't think you'll find any non-trivial C program that _doesn't_ use that style.
<sh4rm4> i've written about 50, and only one uses that style, because its a straight translation from actionscript code
<duflu> RAOF: It's "common", but not common to most non-trivial C, I think
<RAOF> duflu: It might just be the areas I deal with; X, mesa, the kernel, anything using glib, â¦
<duflu> RAOF: Yeah I know it's common in those areas. Those are the first things I thought of. But then... nothing else
<sh4rm4> well, glib is C that tries to be C++, so no surprise there
<RAOF> I'm can't think of any non-trivial C code which doesn't have at least one struct with function pointers in it, but I guess there could be areas of the C-verse I've not explored :)
<duflu> Welcome to the multiverse
<sturmflut> C structs with function pointers are pretty standard I would say
<sh4rm4> when you need to stick a function pointer into a struct, you should rethink your design, because bets are high you're about to do something stupid
<duflu> sh4rm4: I agree. It's high risk and should be avoided in C /if/ there is an alternative procedural approach
<duflu> Well, medium risk...
<duflu> You can shoot yourself in the foot many other ways
<sh4rm4> ;)
<duflu> You reduce the risk if you don't expose the object structure in any public APIs. Users just see "myapi_foo_init()" and it populates the vtable.
<sh4rm4> yeah, but as soon as you deal with callbacks, the code starts getting messy
<duflu> Yeah, no implicit "this" parameter is a constant headache
<duflu> Though there's a good argument that anything implicit is dangerous
<duflu> robert_ancell: https://bugs.launchpad.net/mir/+bug/1136938
<ubot5> Launchpad bug 1136938 in Mir "mirserver.pc is empty/incomplete" [High,New]
<robert_ancell> duflu, turned out to be the fricking CMake cache being stupid
<robert_ancell> delete the cache and it works
<duflu> robert_ancell: Yes "make clean" is never enough. You should regularly "rm -rf build"
<robert_ancell> what is the point of a cache if it doesn't work...
<RAOF> Indeed.\
<RAOF> MIR_GCC_VERSION is in the same boat; you can't change it once it's been set. And you can't change it in ccmake *until* it's been set!
<robert_ancell> well, there goes 3 hours of time wasting
<robert_ancell> as I side effect. I learnt a lot more about cmake. And lost a lot of respect for it
<RAOF> You clearly had more respect for it than I did ;)
<robert_ancell> people say it works well for them. I think they all must have Stockholm syndrome
<RAOF> *I* say autotools works well for me :)
<RAOF> Sure, it's horrible in basically every way, but it's explicably horrible. Except where it isn't  :)
<robert_ancell> RAOF, at least autotools has the excuse of being old
<tehcloud> nothing beats a hand-crafted makefile
<TheMuso> Even autotools beats a hand-crafted makefile. :)
<duflu> I love GNU Make. However it totally fails for complex projects with cross-directory dependencies
<duflu> CMake does that very well
<duflu> So I use CMake, but don't *like* it
<robert_ancell> duflu, do you know the rationale for this wait handle stuff? Can't we just do something like http://paste.ubuntu.com/5612673/?
<RAOF> We could do that (although I'd change mir_connect_sync to return a MirConnection rather than void)
<robert_ancell> RAOF, sure, in that case when there's only one thing to return
 * RAOF is still rooting for the foo_begin/foo_end/foo pattern.
<robert_ancell> The only case I can see for the wait handle is to be able to cancel the request
<robert_ancell> I really like the way GLib did it, though it uses a generic type for the callbacks which I'd avoid
<RAOF> The wait handle is there so you can wait until it's done, not so you can cancel it.
<robert_ancell> RAOF, yeah, though we need some sort of cancelling mechanism and that seems the right place to put it
<duflu> RAOF: I proposed such a solution already and it was disapproved on the basis of multiple functions doing the same thing
<robert_ancell> RAOF, who disapproved it?
<RAOF> duflu: I know :(
<robert_ancell> duflu, i mean
 * duflu looks
<RAOF> robert_ancell: Do we need a cancellation mechanism? With what porpoise?
<robert_ancell> RAOF, if you register a callback and then need to delete the object you have to cancel the callback
<duflu> robert_ancell: alan_g disapproved that too: https://code.launchpad.net/~vanvugt/mir/simple-connect/+merge/147305
<RAOF> robert_ancell: Ah, yeah. Fair call.
<robert_ancell> duflu, do you have the previous proposal you reference handy?
<duflu> robert_ancell: That was an earlier version of the current "optional-callbacks" branch
<duflu> Oh, no
<duflu> That was "remove callbacks"
<duflu> robert_ancell: https://code.launchpad.net/~vanvugt/mir/remove-callbacks-mir_connect/+merge/147056
<duflu> Now all 3 proposals to simplify the client API have been disapproved
<duflu> I'm becoming slightly dismayed for the future of Mir development
<RAOF> robert_ancell: And bug #1112195
<ubot5> Error: Launchpad bug 1112195 could not be found
 * duflu goes to the store and whip up lunch
<RAOF> duflu: Did you deliberately refrain from making that bug public?
<duflu> RAOF: I only forgot to make "closed" bugs public
<duflu> You can do so if you like
<RAOF> Publicified.
 * duflu goes to play in the rain and kitchen
<duflu> RAIN!
<RAOF> Dear lord. In Perth?!
<robert_ancell> bug #1112195
<ubot5> bug 1112195 in Mir "Mir client API lacks simple synchronous interface" [High,Opinion] https://launchpad.net/bugs/1112195
<robert_ancell> RAOF, yeah, we've stolen all Australia's good weather at the moment. But we'd quite like the rain back now
<robert_ancell> Reading that bug report. When anyone says "With templates" I get a shudder down my spine
<RAOF> robert_ancell: What's a harmless bit of template metaprogramming between friends? âº
<RAOF> The begin/end approach doesn't require metaprogramming, at the cost of needing to define an extra two-line function for each begin/end pair.
<robert_ancell> yes, I agree
<robert_ancell> I'm going to send this to the mailing list as I think most people are thinking along the same lines
<RAOF> You know what would be awesome? If we could build Mir with clang and get sensible goddamned compiler errors.
<duflu> RAOF: Yeah a few people have started trying and logged bugs about the problems
<RAOF> We'd also want to stop our brain-dead MIR_GCC_VERSION thingy.
<duflu> I was going to address one of them today but it may turn out that I continue having to work on the old surface-types
<RAOF> robert_ancell: Are you planning to take bug #1112195 to the list?
<ubot5> bug 1112195 in Mir "Mir client API lacks simple synchronous interface" [High,Opinion] https://launchpad.net/bugs/1112195
<robert_ancell> RAOF, I've written a draft, was thinking on it
<robert_ancell> I don't want us to fall into design by committe
<RAOF> Cool. I shall wait until you've posted it before commenting further.
<RAOF> Actually, we really need to get the toolkit-patching stakeholders in; they're the so-far somewhat mythical âcommon use caseâ we're currently optimised for.
<tvoss> RAOF, you should grab loicm in, he is the one with the deepest understanding of Qt's platform abstraction layer
<tvoss> alf_, the Jenkins VM build seems to be unstable for some time now. Are you aware of that?
<robert_ancell> duflu, still around?
<alf_> tvoss: Yes, but I haven't had time to deeply look into it. I'll try to take a look soon, but from what I saw its a timeout issue that's related to the test code, not something actually wrong with the main code.
<duflu> robert_ancell: I think so. Have not combusted yet
<duflu> More to the point... why are you still around?
<robert_ancell> duflu, I stay up late on Thursdays to talk to the Europeans
<duflu> robert_ancell: That's not a euphemism is it?
<robert_ancell> uh, I'm struggling to work out what it would be a euphemism for...
<tvoss> alf_, ack and thanks
<sturmflut> Can you already estimate when basic input handling and window management will be implemented in Mir? I am waiting for the moment when I can start the demo clients and move the windows around
<tvoss> sturmflut, racarr is busy working on the input bits, you might want to ping him when he comes online. He is on the US west coast
<sturmflut> tvoss: What about window management? I saw that window decorations are still a TODO, so how would one interact with Mir at the moment? Without window decorations there are no window borders and controls for maximizing/minimizing, moving, closing etc.
<tvoss> sturmflut, those are left to do right now, the window decorations will be provided by the shell/Unity
<kdub> good morning folks, status, working on the server constructing the android display differently depending on the environment the server is ran (start of hwc work)
<alan_g> Hello kdub
<alan_g> I've started on the refactoring of frontend we discussed earlier in the week and on mir-devel
<alan_g> alf_: kdub racarr - there seem to be varying thoughts about how the shell hooks into mir. Shall we plan a hangout this afternoon/morning?
 * alan_g thought it was all clear after the London sprint
<alf_> alan_g: I am in
<alan_g> alf_: kdub - let's give racarr an hour in which to appear. Hangout at 17:00 UTC
<kdub> alan_g, sounds good
<racarr> I am appeared
<racarr> hangout at 17:00 would be best though. still digesting
<alan_g> alf_: kdub racarr - https://plus.google.com/hangouts/_/73bee7c67b692d0a384d6cc18448029c47205a49?authuser=0&hl=en-GB#
<racarr> alan_g: alf_: kdub: Says no one is there
<racarr> maybe someone could send me an invite through teh interface?
<racarr> the*
<racarr> thanks for the updates to prepare-to-send-clients input btw :)
<alan_g> sometimes its easier just to write the code
<racarr> Following up on prepare-sessions-for-input-focus, using this SessionManager::create_surface_for approach, the test I want to write is TEST(SessionManager, create_surface_for_session_forwards_and_then_focuses_session)
<racarr> but I can't set an expectation on the session because it's the real SessionManager, which doesn't use a factory to construct Session implementations
<racarr> I am trying to decide if this is evidence that the SessionContainer is also a SessionFactory (or some such)
<racarr> or if it's just not a compelling change, if there is no other real motivation for it, here it's just easy to set the expectation on the surface factory instead
<racarr> but it kind of seems like it might be correct *shrug*
#ubuntu-mir 2013-03-15
<RAOF> Who wants to help me work out an exciting gmock weirdness? http://paste.ubuntu.com/5615354/ generates http://paste.ubuntu.com/5615358/
<duflu> RAOF: Maybe you're missing a .WillOnce(Return(x)); or similar on the end of your EXPECT_CALL(*mock_buffer_factory, create_buffer_rv(_,_,_))
<RAOF> Aha! DoOnce overrides the default behaviour, which means that I wasn't returning.
<RAOF> duflu: Correct!
<duflu> Whee
<duflu> Gmock is weird like that. "EXPECT_CALL" does more than expect something. It actually determines the behaviour :P
<RAOF> Even worse, while you can WillOnce(DoDefault()), you can't WillOnce(DoAll(Something(), DoDefault())
<RAOF> Man, I wonder what clang's error messages would look like.
<RAOF> Woot! It compiles!
<RAOF> Now, to make it additionally _link_.
<RAOF> And only one failing test. Time to heat luncheon pizza.
 * duflu is jealous of luncheon pizza
<duflu> or generally anyone who can eat regular pizza :/
<duflu> RAOF: See also https://bugs.launchpad.net/mir/+bug/1110115
<ubot5> Launchpad bug 1110115 in Mir "PixelFormat is in namespace "geometry"" [Medium,New]
<RAOF> Well, that has to be one of the stupider reasons for failing a test: asserting the expectations *after* the call that satisfies them.
<RAOF> BAH
<duflu> RAOF: Asynchronous expectations! <insert poorly informed quantum mechanics joke>
<tvoss> RAOF, happens to all of us :)
<tvoss> mmrazik, ping
<mmrazik> tvoss: pong
<tvoss> mmrazik, http://unity.ubuntu.com/mir/ is accessible now, can you adjust the jobs or do we need thomi for that?
<mmrazik> tvoss: I should be able to do it. Is there any info from the ticket (like what user to use to scp)?
<mmrazik> let me check the autopilot job to see what I need
<tvoss> mmrazik, don't know :)
<mmrazik> tvoss: mhm... I guess we will need to figure out. Autopilot is using autopilot-sync.. so let me first try to guess mir-sync
<mmrazik> tvoss: I guess I'm out of luck. In matter of fact it looks like autopilot-sync stopped to work too (permission denied)
<mmrazik> tvoss: do you have the ticket # at hand?
<tvoss> mmrazik, forwarded you the mail
<RAOF> Macros like EXPECT_THROW: measurably worse than Hitler. :(
<RAOF> It couldn't possibly say âyou've removed the header that was implicitly including <stdexcept>, so I now don't know what std::logic_error isâ. Oh, no.
<duflu> RAOF: I have clang building Mir now. It's messy and needs some cleaning up yet
<RAOF> Woot!
<duflu> But the errors are phenomenally better than gcc
<duflu> And numerous :P
<RAOF> And we'll always have the jenkins autotests to tell us when we've used something that doesn't work in gcc :)
<tvoss> mmrazik, any luck with the mir-sync stuff?
<mmrazik> tvoss: nope. I was on a call
<tvoss> mmrazik, ack
<mmrazik> tvoss: and I think there is something broken even for autopilot
<mmrazik> tvoss: it looks like few bytes are transfered and then the connection is lost
<mmrazik> tvoss: will need to follow up on #is
<tvoss> mmrazik, thx
<tvoss> mmrazik, can you cc me on the ticket please?
<mmrazik> tvoss: I'm just trying irc first
<tvoss> mmrazik, ack
<mmrazik> tvoss: btw. what should be actually copied? /usr/share/doc/mir-doc/html/* ?
<tvoss> mmrazik, yup
<alf_> duflu: alan_g: @surface-types, configure() at RPC level, I understand your concern about the pain of adding new RPC methods. My suggestion was based on having a limited and relatively stable number of surface attributes. Is this not the case?
<duflu> alf_: It's not the case right now. I will have a couple soon and keep thinking of more such attributes that clients will eventually need to be able to set
<alan_g> alf_: duflu even if we multiplex different data over an rpc call we can demultiplex at the server boundary
<alan_g> It doesn't have to propagate frontend => shell => surfacers
<duflu> alan_g: If you do it too close to the boundary (frontend) then same problem. Too many classes will be changing all the time
<duflu> alan_g: If you think you can safely move the boundary without cursing future development to extraneous effort then I suggest proposing a proof of concept branch
<alan_g> duflu: well, I was answering alf_ - you know I don't think these attributes should ever go beyond shell anyway
<duflu> alan_g: Most other attributes have to. For example "state" changes the server into an "unredirected" rendering mode for example.
<duflu> And "hidden" directly affects a surfaces::Surface
<duflu> It's only "type" that can stop at the shell layer
<alan_g> duflu: "hidden" maps to Surface::hide()/show()
<alan_g> And that can happen by shell decoding an attribute
<duflu> alan_g: Consider also width/height. Attributes or not, such messages from the client will end up reaching surfaces::Surface
<alan_g> duflu: but not as shell related attributes (I believe)
<mmrazik> tvoss: srry... one more question... do you want http://unity.ubuntu.com/mir or http://unity.ubuntu.com/mir/api asi thomi was suggesting (the later requires some mkdir-ing for me and moving things aournd; but not a big deal)
<alan_g> mmrazik: http://unity.ubuntu.com/mir
 * mmrazik is just uploading stuff to http://unity.ubuntu/mir/
<tvoss> alf_, ^ any thoughts?
<alf_> alan_g: duflu: I think I would prefer to do the demultiplexing in the Mediator, the attrib,value pair (or any other method we use) is a communications detail that may change, not need to propagate it further down
<duflu> I really wish people raised these concerns 2 weeks ago...
<alan_g> alf_: I'm not so sure - I think the shell is what interprets attributes
<duflu> Please put your comments in the merge proposal so I can review them next week
<alan_g> duflu: I wish we'd discussed the design before the MP appearede
<alf_> tvoss: mmrazik: Yes, http://unity.ubuntu.com/mir is good as we have a main page
<duflu> alan_g: Too much room for misunderstanding in English. C++ is clearer :)
<alan_g> duflu: more precise, not necessarily clearer
<alan_g> duflu: I have design discussions with everyone else on the team. It works for us.
<alan_g> duflu: alf_ does too
<duflu> alan_g: Yes we can and do discuss a lot. But some/most problems and disagreements are not foreseeable.
<alan_g> duflu: some are not. some are easily prevented.
<duflu> Please put your concerns in the merge proposal. I really don't want arguments ruining my weekend
<alan_g> duflu: let's try a either a hangout or pair-programming when you're back. MP/review isn't working - it is just frustrating.
<duflu> alan_g: Although I suggest waiting until there are multiple attributes and then decide if we're demuxing in the right location
<alan_g> duflu: I agree with that bit
<duflu> MP/review works very well. It's formal and clearly documented. Unlike IRC where you lost track of a conversation
<duflu> -lost +lose
<alan_g> duflu: your idea of working is "I've now been working on this branch for a month and it's been under review for two weeks. It has worked perfectly without bugs for the entire duration. Remember we're only arguing about style issues that can be fixed later."
<mmrazik> tvoss et al: Enjoy: http://unity.ubuntu.com/mir/ !
<tvoss> mmrazik, thanks :)
<alan_g> mmrazik: \o/
<duflu> alan_g: I am happy to address all your concerns in the formal environment of a merge proposal. My frustrations aside, let's use Launchpad as intended
 * alan_g shrugs
<duflu> Forgive me. But if any further code change is required along the lines of what's being discussed then it's much too large for me to do in the few minutes I have left
<alan_g> duflu: I don't expect a rewrite in a few minutes, just something different in the next two weeks
<alan_g> duflu: have a good weekend! "See" you next week.
<duflu> alan_g: If you have a solid suggestion and the time, please propose a branch to mine. Keep in mind we don't want per-attribute interfaces leaking into the reporting system, amongst other things
<alan_g> duflu: ack
<alf_> duflu: alan_g: @solid suggestion, I think too many conflicting solid suggestions are delaying us here, instead of a discussion through which we can find reasonable compromises
<alf_> duflu: alan_g: problem is that the communication latency for MPs and launchpad is very high, thus the need for more direct communication
<alan_g> alf_: I'm all for discussion - I'd rather have a half hour conversation than spend a day recoding
 * tvoss paints on the wall: Be reasonable, agile and "Done is better than perfect"
<alan_g> alf_: as you've more overlap time with duflu than I have, how about you try pair programming with him when he gets back?
<duflu> alan_g, alf_: We're all perfectly capable of communicating in writing. And I have addressed every concern raised so far. If you have more concerns, please put them in writing and I'll work to resolve them as always
<duflu> The greatest hurdle so far has been trying to understand the design rationale for much of the Mir code, but I believe I'm making good progress in understanding the intention of what's there...
<duflu> tvoss: Yes we do seem to iterate a lot in seek of perfection. Although that's often feasible, it is harder with differing views of "perfection" :)
<duflu> Umm, "in search of"
<tvoss> duflu, I'm just saying that perfection is the enemy of good enough, and alf_ was pointing out that compromises might be a better way to move forward and achieve clarity
<alf_> alan_g: duflu: sure, but I think I prefer a three-way discussion at this point (since all three of us have differing opinions at this point)
<alan_g> and I'm saying a "face-to-face" conversation is the best way to refine a resolution
<alan_g> alf_: I'm sure I could live with anything you and duflu are both happy with.
<duflu> alan_g: That may well be true. But it's not feasible on the weekend. We'll save some time if you write down ideas for what you think needs to change and I can have something ready before you wake up on Tue.
<alan_g> duflu: could you also see if you can get hangouts set up - for if we still need to talk.
<duflu> alan_g: That's feasible. It used to work fine with 2 people. Just died with more :P
<alf_> duflu: do you have the latest binaries from google?
<duflu> alf_: Probably not
<alf_> duflu: what happens for me is that every once in a while hangouts break in some way, and upgrading the binaries usually improves the situation
<alf_> alan_g: duflu:  @"Although I suggest waiting until there are multiple attributes and then decide if we're demuxing in the right location", so let's merge what we have and refactor later ?
<alan_g> alf_: I don't think that's the blocker. Let me review the latest version.
<duflu> alf_: I was thinking the same, but thought it would be rude of me as author to suggest it
<duflu> Especially as I am willing to make changes myself and am willing to do all the work still
<duflu> Here, have clang support.
<duflu> And happy (grand prix) weekend :)
<alf_> duflu: have fun!
<alan_g> alf_: had a chance to look at https://code.launchpad.net/~alan-griffiths/mir/refactor-frontend-cleanup/+merge/153386 yet?
<alf_> alan_g: not yet, will do shortly
<alf_> alan_g: commented
<alan_g> alf_: looking...
<tvoss> alan_g, alf_ can you give https://wiki.ubuntu.com/Mir/GetInvolved a spin? Feel free to edit in place
<alf_> tvoss: sure, so what's the plan with wiki + project-page coexistence?
<tvoss> alf_, we can have both, but I want to have a simple landing page where people are welcomed and introduced to the project
<tvoss> alf_, that page should be quite static and dispatch to the up-to-date documentation as generated from the source tree
<tvoss> makes sense?
<alf_> tvoss: Sounds good. Any luck finding a better theme for the doxygen docs?
<alf_> tvoss: or perhaps asking design for one...
<tvoss> alf_, not yet
<kdub> morning folks! status, ported over the android framebuffer type (lessening hybris dependency, solving some alloc issues), working on android display selection
<alan_g> kdub: morning. Don't forget to review a few MPs
<tvoss> morning kdub
<alan_g> status: unblocked glog, Proposed refactorings we've discussed.
<kdub> alan_g, i might have to ping someone to get libgoogle-glog0 into quantal
<alan_g> kdub: quantal?
<kdub> phablet builds are still quantal, last I downloaded :)
<kdub> i don't think we have to block the glog branch on it
<kdub> rsalveti, are the phablet builds still quantal? i heard rumblings about transitioning to raring
<tvoss> kdub, glog should be in universe in quantal iirc
<rsalveti> kdub: still quantal, raring transition kind of going in place
<kdub> thanks
<kdub> rsalveti, while i've bothered you... here's how i get the demo to run with mir underneath... lp:~kdub/aal+/ubuntu-platform-mir
<rsalveti> lemme see
<alan_g> kdub: re add-glog-logging - is there anything I need do, or are you handling it.
<kdub> alan_g, i'll handle it
<alan_g> kdub: cool
<alf_> alan_g: @add-glog-logging, do we need to make it explicit to the users that we are using glog? I would think this is an implementation detail.
<alf_> alan_g: (mostly referring to the command line options)
<alan_g> alf_: Probably not, but I'd prefer to address that when we've covered some other reporting scenarios
<alf_> alan_g: I am fine with that (i.e. that there is the prospect of hiding the details)
<alan_g> kdub: want to review refactor-frontend-cleanup before I decide to land it?
<kdub> alan_g, let me scan it for red flags... 5 minutes :)
<kdub> lots of branches lately! :)
<alan_g> kdub: I want them all to land before the weekend, so we can have a good start next week.
<racarr> alan_g: Removed the .orig here https://code.launchpad.net/~robertcarr/mir/prepare-shell-for-input-focus/+merge/153483
<racarr> if you have time to take a look another look
<alan_g> racarr: looking...
<kdub> alan_g, +1'd. lots of sed :)
<alan_g> kdub: you know my secret!
<racarr> alan_g: Thanks
<racarr> not sure what to do with prepare-to-send-clients-input will talk to daniel my afternoon
<racarr> oh no I wont its his saturday
<racarr> fixed header here https://code.launchpad.net/~rocket-scientists/mir/prepare-for-inprocess-egl-clients/+merge/150379 as well
<kgunn> kdub: thanks for unblocking alf
<kgunn> understand its still an open task
<alan_g> racarr: I think you get what votes you can and then take this as advice: https://code.launchpad.net/~robertcarr/mir/prepare-to-send-clients-input/+merge/152100/comments/333969
<alan_g> kgunn: are you able to give an opinion? (Read the comments) https://code.launchpad.net/~robertcarr/mir/prepare-to-send-clients-input/+merge/152100
<alan_g> racarr: approved
<kgunn> ^ reading
<alan_g> alf_: racarr any review comments for https://code.launchpad.net/~alan-griffiths/mir/refactor-surfaces-cleanup/+merge/153431 ?
<alf_> alan_g: why does surfaces need a deleter ctor parameter?
<alan_g> alf_: It inherits two use cases - one with a null deleter and one that deletes from the surface stack. I didn't feel it should be fixed by this MP but could be pursuaded
<racarr> thinking about refactor-surfaces-cleanup
<racarr> as for the multi channel stuff..I dunno I actually have the impression that some issues
<racarr> are easier to solve with split channels and timestamps
<racarr> and Ir emember I came to this conclusion when reading the why X is not our ideal windowing system paper in Lexington
<racarr> but I can't remember why
<racarr> so I will try and read it again and come back :)
<racarr> Hmm
<racarr> i think the deleter is fine
<racarr> except at 510-512 and 524-526 it seems kind of strange
<racarr> because the contents of the deleter are in the test
<racarr> so if the implementation is modified to not pass a surface_stack.destroy_surface deleter
<racarr> the test still passes right?
<racarr> alan_g: ^
<racarr> So maybe there should be like
<racarr> static msh::Surface::create_within(surface_stack, params)
<alan_g> racarr: I guess another option would be to provide a Deleter class. Or to rework the interaction between shell and surfaces.
<alan_g> mmrazik: jenkins problem? "/tmp/cckobwIf.s: Fatal error: can't close CMakeFiles/unit-tests.dir/graphics/test_gl_renderer.cpp.o: No space left on device"
<mmrazik> alan_g: just added a comment and reapproved
<mmrazik> alan_g: but to answer your question -- yes, jenkins problem
<alan_g> mmrazik: thanks
<kdub> kgunn, no problem. i forgot to mention, but in that blueprint, i almost see 'display integration' as 'vsync timings + display mode selection'
<kdub> i guess we can leave it there for now
<kgunn> kdub: feel free to reword
<kgunn> no prob
<racarr> alan_g: Hmm. I am not sure. A deleter class doesn't sound particularly compelling
<alan_g> racarr: In that case I prefer to untangle the shell/surfaces interaction. Either in this MP or a future one.
<racarr> I am not sure I see how to do it right now...
<alan_g> racarr: it isn't obvious to me now. But I'm sure after a bit of thought it will simple.
<racarr> another thought, which is kind of similar to a deleter class but slightly more appealing to me
<racarr> or maybe this is what you meant...
<racarr> is like SurfaceController implements...SurfaceOwner? or something, with destroy surface
<racarr> so the call .destroy_surfaces moves to shell::Surface dtor
<racarr> because the only case for a null deleter is in tests right?
<racarr> So they should just supply a stub
<racarr> maybe even just ignore the additional interface.
<alan_g> racarr: Part of fixing it is to work out what we really need from those tests.
<racarr> that is why I liked
<racarr> the static method, because then you can express what we want from both of those tests now with one idea..i.e.
<racarr> TEST(Surface, create_with_returns_surface_managed_through_controller)
<racarr> or something
<racarr> which I think sounds like what we want
<racarr> the @ makes me feel like I am yelling
<alan_g> racarr: It needs more cleanup in that area anyway - the shell shouldn't be updating the SurfaceStackModel directly. So I guess I'll rework on Monday
<racarr> Hmm ok.
<alan_g> Is my EOD so I'll try to forget it for the weekend.
<racarr> I am thinking though, the current branch
<racarr> I don't know if it's any worse and the naming is definitely better
<alan_g> Fine. Land it and I'll propose rework MP on Monday. (Unless you do it today)
<racarr> Ok. Sounds good
<racarr> I probably wont today unless I have any ideas
<Cheery> how are the Mir-nvidia -negotiations going on?
<racarr> I generated a big list of minor little refactorings yesterday
<racarr> that I want to get through once
<racarr> the risk of conflicts is a little lower
<alan_g> Is it ever?
<Cheery> http://hardware.slashdot.org/story/13/03/15/1254210/nvidia-walked-away-from-ps4-hardware-negotiations
<racarr> eh
<Cheery> that is particularly interesting
<racarr> friday afternoon I should be safe from
<racarr> too much
<racarr> alan_g: Ok well have a good weekend!
<alan_g> racarr: In that case, land as much as you can this morning.
<alan_g|life> Cheery: I don't know anything to tell you
<Cheery> alan_g|life: why is it important, should you know it?
<Cheery> I mean I'd have understood "I can't tell you"
<racarr> Cheery: re: nvidia.
<racarr> I think "well" is the best answer I can give right now ;)
<Cheery> I sort of see nvidia is probably getting to this. but I'd like to know when it happens.
<Cheery> it'd be nice to know if it goes public in 10 days or in 2 months, or by the end of this year.. or...
<racarr> :)
<racarr> It's all based on the phases of the moon and alignments of the planets
<Cheery> easy stuff then.
<racarr> hehe
<racarr> alf_: kdub: Can we wait to turn
<racarr> refactor-surfaces-cleanup to approved until after I land
<racarr> prepare-to-send-clients input
<racarr> p.s. do either of you want to review that
<racarr> I will sort out the conflicts either way but I think it will be less conflicts this way
<racarr> alf_: Oh and could you look
<kdub> racarr, thats fine by me
<racarr> at prepare-for-inprocess-egl-clients agian?
<racarr> your last comment is the dissaprove from before we decided to remove those tests
<racarr> kdub: Thanks :)
<racarr> XD next week all my branches get to be like send-clients-input inprocess-egl-clients, etc...I wonder if the week after that it will just be
<racarr> prepare-to-refactor-sending-clients-input
<racarr> and I get stuck in a loop
<kgunn> racarr: alan_g|life got waylayed by mgmt discusion
<kgunn> racarr: i read duflus comment
<kgunn> i tend to agree about the secondary channel
<kgunn> but i don't why you couldn't just use a surf id like he suggested
<racarr> Because the android code is nontrivially dependent on (through leaky abstraction Is uppose)
<racarr> and implements
<racarr> the secondary channel method
<racarr> so to do it now, sets back progress a week or so
<racarr> which in the face of not really seeing the concrete problem I am not so disposed to do
<racarr> and I am inclined to think that android had a pretty good reason for structuring it the way they do now
<kgunn> racarr: don't get me wrong
<racarr> for example a client with an input thread and a display thread, display thread will be at most at say 60hz but input thread is easily processing events at 120 hz
<kgunn> i think duflu was pointing out potential race conditions that are legit
<racarr> so the display thread.
<kgunn> but solvable with the id
<racarr> is hung up on synchronously on rendering which is fine because it can go a little slow
<racarr> but the input thread should still be able to handle events at a fast rate, because it's a two way negotiation with the server (i.e. the client has to explicitly handle-or-not-handle events)
<racarr> and if the client falls behind events start to become batched and then interpolated
<racarr> I dunno I have the idea that on the seperate channel with the idea of a dedicated input receiver thread
<racarr> we will have more predictable performance characteristics
<kgunn> ironically one of the unity guys was having this exact race condition problem with a test on autopilot
<kgunn> click was for a button(surface) that wasn't present
<kgunn> so click got lost
<racarr> In X though it's hard to do the synchronization
<racarr> based on just comparing timestamps or something because
<racarr> it's a three way race between the client the compositor/window manager and the server
<racarr> I am just thinking about daniel's example...
<racarr> I had convinced myself yesterday it would work fine but let me think again before I say something dumb :p
<tvoss> racarr, ping
<racarr> tvoss: Pong!
<racarr> I didn't do it
<racarr> I promise
<racarr> I mean, so an input event is in the dispatcher.
<racarr> the dispatcher looks at a snapshot or locked view of the surface stack and says
<racarr> ok B is on top so I send it to B
<racarr> then B closes inbetween that
<racarr> decision and B handling
<racarr> the event
<racarr> how is it that A gets the events that were targeted at B?
<racarr> I mean it doesn't
<tvoss> racarr, it cannot happen as changes to the surface stack is transactional
<racarr> That's what I think :)
<tvoss> the worst thing that can happen is that B receives an event for a surface that does not exist anymore
<racarr> in fact, it's even better than that. You can then go once you are notified that B did not respond
<tvoss> but that's fine from, the behavior is consistent from the server's perspective
<racarr> you can look at the timestamp
<racarr> err...
<racarr> ok nvm this isn't fully coherent yet
<racarr> I think there are some cases where you might want to redispatch to A
<racarr> would be like the "pixel perfect behavior"
<racarr> I'm not sure
<racarr> but the worst case is yeah, this B receives an event but the surface doesn't exist
<racarr> no one receives events they shouldn't
<racarr> well, from other surfaces*
<racarr> *shrug*
<kgunn> racarr: ....i'm tempted to say cool
<kgunn> racarr: lunatic fringe question....what about B has 2 surfaces...1 disappears?
<kgunn> could B be fooled into handling event for surface 2 when it was meant for surface 1 ?
<tvoss> kgunn, an event is always targeted towards a surface
<racarr> no because it's a seperate
<racarr> channel per surface not per client
<kgunn> ah
<kgunn> then "cool"
<kgunn> racarr: tvoss so duflu was on crack from the beginning :)
<tvoss> kgunn, duflu might have a valid point, but we will find out and then we iterate
<racarr> It's definitely a concern (even if I don't think this race scenario is)
 * tvoss paints "perfection is a journey, not a destination" on the channel wall
<racarr> but there are more complex cases like menus, etc.
<racarr> that I don't fully understand yet.
<kgunn> i guess the base question is...why would a surface go away
<kgunn> that'll determine what you'd do with the input
<racarr> I think while two channels sounds like a lot more potential for racing...
<racarr> my thought is that, if you have two seperate channels of control, one handling display messages all with valid timestamps, and one handling input messages all with valid timestamps, and all changes to the surface stack are transactional
<racarr> I unno
<racarr> I can't imagine a race right now
<tvoss> racarr, just go ahead and let's complete one iteration :)
<racarr> its because the removal of
<racarr> the surface and the change of focus
<racarr> is a transactional operation
<racarr> as opposed to in X where it has to go through the window manager
<racarr> and becomes another race point
<kgunn> racarr: i think tvoss is right
<kgunn> implement
<racarr> *shrug*
<racarr> ITERATION 1 GO!
<kgunn> and then tweak frequencies if you want
<racarr> *nods*
<kgunn> and see if you can generate one
<kgunn> a race that it
<kgunn> damn/it/is
<racarr> ok I am changing prepare-to-send-clients-input to approved then
<racarr> and https://code.launchpad.net/~robertcarr/mir/prepare-shell-for-input-focus/+merge/153483
<racarr> (thanks for review btw kdub :))
<kdub> racarr, sure!
<racarr> kgunn: Reading your weekly update
<racarr> wonder if we should send weekly updates to
<racarr> public list as well?
<kgunn> racarr: yeah, good idea
<kgunn> you mean mir-devel
<kgunn> ?
<poseidon> Anybody here set up mir on archlinux?
<racarr> kgunn: Yes
<racarr> More merge conflicts! Wheeeeeeeeeeeeee
#ubuntu-mir 2013-03-16
<sturmflut> I was thinking about porting some existing OpenGL examples to mir so they can be included in the examples/ directory. What about glxgears?
<RAOF> sturmflut: You can find es2gears_mir in my mesa-demos branch on Launchpad - https://code.launchpad.net/~raof/mir/mesa-demos-mir
<sturmflut> RAOF: Thanks
<sturmflut> I must say I hate OpenGL ES 2.0 for all the programmable pipeline stuff
<sturmflut> Everything that was easy is horribly complicated
<RAOF> sturmflut: You should be able to get a full OpenGL context out of EGL if you ask for it; at least on the desktop âº
<sturmflut> RAOF: mir_egltriangle works on my machine, but mir_eglgears dumps "libEGL warning: unsupported platform (null)" on the console and noting is displayed while the framerate ist output on the console
<sturmflut> nothing
<RAOF> Hm. Worked last time I tested it :)
<RAOF> I might give it another whirl on Monday.
<RAOF> It's non-trivial for me, because I'm half way through breaking it :)
<sturmflut> May be the fault of my local installation
<sturmflut> Two reboots ago my X.Org didn't even have GLX anymore
#ubuntu-mir 2013-03-17
<RAOF> Bah. âmake testâ doesn't depend on the output of the build, so you need to manually run the build before testing changes.
<RAOF> Thanks, cmake!
<RAOF> Huh. Trunk doesn't build?
<RAOF> Hah! Doesn't build with g++ 4.6, because override.
 * RAOF blows away his build tree again.
#ubuntu-mir 2014-03-10
<davmor2> anyone about yet that can help me diagnose a potential framebuffer issue on mako please
<alan_g> davmor2: I'm about. Don't know how much I can help though. Tell a bit more...
<davmor2> alan_g: so my screen has completely locked, when I had it on maguro it was down to an issue on the FB/hardware side of things.  I've had this once on Friday, once over the weekend and now today.  I've grabbed syslog, dmesg and logcat is there anything else that might be useful and I'll put all the info into a bug
<alan_g> davmor2: I can have a look. But this is likely an area where kdub or AlbertA can make better, faster progress.
<davmor2> alan_g: well I'm leaving the device in it's current state so it can wait for them
<alan_g> OK
<davmor2> AlbertA: Morning alan_g point me at you as a possibly solver of an issue I am having with mir on mako, Now and then the display just locks up when is random, I've grabbed dmesg, logcat and syslog is there anything else that might be useful for a bug?
<davmor2> AlbertA: I'm assuming it is an issue with the fb like I had on maguro but could be wrong
<davmor2> I've left the phone in the locked up state
<davmor2> kdub: Morning.  I have an issue on mako the phone's graphics has locked up.  I have the syslog, dmesg and logcat is there anything else I can get that would be useful for a bug report?
<davmor2> kdub: I have a feeling looking at it that it might be a fb issue like I saw before on maguro
<davmor2> kdub: I've left the phone in the broken state
<davmor2> kgunn: ^
<kgunn> davmor2: sorry, we were in standup...i'll let kdub give you some pointers
<kgunn> davmor2: are you sure its graphics that's locked up ?
<davmor2> kgunn: I can access the phone and everything looks normal it's just the image on the screen that seems frozen, but there are no crash reports not much in the way of errors anywhere similar to the issue I had on maguro which is what made me question if it was the fb, if I restart the phon eeverything is fine till the next time it happens
<kdub> davmor2, thos logs are the most useful
<AlbertA> davmor2, which version of mir and unity8, etc?
<davmor2> AlbertA, kdub: I'll add all that to the bug for you, give me 5 minutes or so and I'll throw you guys the bug number
<rsalveti> alf__: any news regarding glmark2?
<alf__> rsalveti: I am going to release a new upstream version soon (hopefully today, tomorrow morning latest)
<rsalveti> alf__: great, thanks
<davmor2> kdub, AlbertA: https://bugs.launchpad.net/mir/+bug/1290416  phone is still in the locked state I've added an image of what I see the phone still sleeps but when I wake it I get back to the frozen image.  let me know if there is any thing else I can grab you.  p.s. if I reboot the phone it works fine again till the next time.
<ubot5> Ubuntu bug 1290416 in Mir "Mako locks up roughly once a day since R226" [Undecided,New]
<AlbertA> davmor2: do you think you can attach gdb to the unity8 and unity-system-compositor processes?
<AlbertA> davmor2: A dump of the thread states
<AlbertA> davmor2: would probably be useful
<davmor2> AlbertA: sure, is it just gdb unity8 <pid_of_unity8> and the same again for unity-system-compositor?
<AlbertA> davmor2: should be
<davmor2> give me 5 then
<AlbertA> davmor2: I haven't tried attaching in a while
<AlbertA> davmor2: :)
<AlbertA> davmor2: and then thread apply all bt to dump the thread backtraces
<davmor2> AlbertA: In theory unity8 should now be attached
<davmor2> AlbertA: let me know if it isn't
<AlbertA> does thread apply all bt dump anything?
<AlbertA> "thread apply all bt"
<davmor2> ah sorry one second
<davmor2> AlbertA: comment 9 should be right now
<AlbertA> davmor2: wow 30 threads...
<AlbertA> davmor2: it probably be useful if you can dump all that to a file and attach it
<AlbertA> davmor2: otherwise it's going to be a loooooong comment
<AlbertA> davmor2: :)
<kdub> only 30? :P
<AlbertA> davmor2: well it may be only the thread ids, some older threads may have died already
<davmor2> AlbertA: comment 10 is a file :)  I'll grab usc now
<davmor2> AlbertA: comment 11 should be usc
<kdub> AlbertA, kinda looks like an IPC lockup to me?
<AlbertA> davmor2: ummm I suppose the interesting bit is all of them are blocked in swapbuffers but one thread was doing a sessionDestroyingSurface
<kdub> I don't see a thread waiting at a driver point... will re-read the backtrace though
<AlbertA> davmor2: I wonder if there's a deadlock there
<kdub> yeah, or in SwitchingBundle
<davmor2> AlbertA: No idea
<davmor2> AlbertA: the maguro would regularly lock up in a similar fashion so it just reminded me of that especially when there were no crash files.
<AlbertA> kdub: in usc, snapshooting seems blocked, maybe that caused the driver error
<kdub> which comment number has the usc/unity8 backtrace?
<AlbertA> kdub : #11
<davmor2> kdub: 10/11
<kdub> ah, needed to f5 the page
<AlbertA> davmor2: in any case, these are good leads to pursue
<davmor2> AlbertA, kdub: now is there anything else while it is in this state?  As it is my main phone so I can't receive any calls currently :)
<AlbertA> davmor2: I think this is enough for now
 * davmor2 waits on a +1 from kudb before rebooting the device
<davmor2> kdub: even
<kdub> yeah, it gives something to go on
<davmor2> cool thanks guys
<AlbertA> davmor2: R229 is in reference to what?
<kdub> system image number, probably
<AlbertA> kdub: ok
<davmor2> AlbertA: system image number
<davmor2> AlbertA: R226 was Fridays and is the current promoted image, R229 was released this morning
<AlbertA> davmor2: ok, so it's probably mir 0.1.5 then
<davmor2> AlbertA: yeap libmirclient version is listed in the top comment
<kdub> AlbertA, system-image-cli -i will give that number
<AlbertA> davmor2: oh, yeah I see it now
 * kdub might add libandroid-properties1 as a mir runtime dependency
<kdub> its already in the system image
<kdub> it would help us detect the device name, so we can blacklist, or fail better if the android library is ran on a mesa device
#ubuntu-mir 2014-03-11
<alan_g> alf__: I guess this is no linger needed? https://code.launchpad.net/~afrantzis/mir/always-consume-input-events-in-clients/+merge/209313
<alf__> alan_g: affirmative
<hikiko> hello
<hikiko> I am trying to run mir on nvidia, I have loaded and installed the nouveau driver (checked with lsmod that there is no other nvidia driver) and when I run the mir server basic demo, I get a message that gbm failed to load the nouveau driver... (nvidia GF188 [GeForce GT 440])
<hikiko> does anyone else have the problem?
<hikiko> is there anything I can do to fix it?
<RAOF> Hey!
<RAOF> I... think that card should be supported by nouveau?
<RAOF> Does X work properly?
<hikiko> yes RAOF
<hikiko> X is fine
<RAOF> And glxinfo under X shows that it's using nouveau?
<hikiko> let me check
<hikiko> well if I run: glxinfo | grep -i nouveau
<hikiko> I gett libGL error: failed to open drm device: Permission denied libGL error: failed to load driver nouveau
<hikiko> (i ran startx though so it might be just permissions let me check in unity7)
<hikiko> yep
<hikiko> when i start unity from lightdm
<hikiko> i get OpenGL vendor string: nouveau
<RAOF> Cool. Hm...
<duflu> Look over there!
 * duflu runs away
<hikiko> :P
<hikiko> in /usr/lib/x86_64-linux-gnu/dri I have a nouveau_dri.so (and a nouveau_vieux_dri.so) if that helps
<hikiko> so it should find it
<alan_g> alf__: @fix-1260612 - it is an improvement. Should I approve and log a bug for the not-working scenario? Or do you have a clue how to fix?
<alf__> alan_g: No clue, but I will keep investigating. Feel free to log a different bug if you like and assign it to me.
<alf__> alan_g: hmm, you are running shell as host basic as nested, I am running basic as host shell as nested.
<alan_g> alf__: I've tried your scenario with "_shell" and "_basic" as the nested server. The latter shows the problem I saw. Not sure why there's a difference though.
<alan_g> I'll approve the MP - it seems to be a "_basic" bug
<alf__> alan_g: well, basic doesn't support resizing or moving gestures, in the shell==host scenario we are moving/resizing the whole nested window, and I am not sure if resizing means scaling or cropping in this case
<alan_g> alf__: I think some /examples gardening is required - who can remember these differences. But explained to my satisfaction
<alf__> alan_g|tea: so, yes, we seem to be cropping in the shell==host scenario (if you "zoom in" hard enough you will see it)
<kgunn> AlbertA: btw, i landed the usc change to have fuzzy time on screen blank...but i still see the app on unblank
<kgunn> will our plan to move all the screen state in usc better address this ?
<kgunn> AlbertA: what's weird is i know i saw it work once (e.g. saw only the lock screen)
<AlbertA> kgunn: well you need to add the delay to a configuration file
<AlbertA> kgunn: by default its 0
<AlbertA> If you add /etc/xdg/unity-system-compositor.conf
<AlbertA> with a power-off-delay=500 maybe
<AlbertA> kgunn: but yes moving the screen state out of powerd will help here
<AlbertA> kgunn: also for the power-off-delay to be "seen"
<AlbertA> kgunn: you need this in powerd: https://code.launchpad.net/~albaguirre/powerd/let-display-turn-off-backlight/+merge/208667
<mterry> alan_g, btw, I finally got a chance to test your nested-sessions-dont-post-buffers-until-something-happens branch (had to wait for 0.1.6 to settle first, was getting weird crashes before).  It works like a charm, thanks!
<alan_g> mterry: \o/
<ogra_> hmm, so after using mirscreencast it seems that the screen stopped auto-suspending
<AlbertA> ogra_: hmm, interesting... I don't see why that would be the case from a mir perspective
<ogra_> the screen was initially suspended ... running miscreencast properly woke it up too ... it just doesnt turn off again until i press the power button twice
<AlbertA> ogra_: there must be some resource we are holding on the screencast compositor
<ogra_> well, is that solely screencast or do you perhaps invoke powerd somewhere to get the display up
<AlbertA> ogra_: there must be a display on - I think that was fixed recently - but not through powerd
<ogra_> hmm, i could imagine that both processes start wrangling over owning the screen then or that powerd simply isnt aware the screen is on if you force it on from Mir
<ogra_> (so it doesnt try to suspend it then)
<AlbertA> ogra_: Oh I see, you started mirscreencast while the screen was off, then yeah, powerd wouldn't know about that
<ogra_> AlbertA, yeah, not a biggie, but it would be good if they could communicate to each other about this
<AlbertA> ogra_: In any case, we are ripping the screen power state out of powerd and putting it in usc
<ogra_> ah, k
<ogra_> thats will be fine then
<AlbertA> ogra_: Also the forcing of display on will be removed if this lands:
<AlbertA> https://code.launchpad.net/~robertcarr/mir/remove-ensure-display-powered/+merge/209734
<ogra_> hmm, tests need this function
<ogra_> you should talk to the QA guys about that, autopilot needs a way to force the screen on before starting its tests
<AlbertA> racarr: ^
<racarr_> ogra_: AlbertA: I think my branch is unrelated
<racarr_> you guys need to be able to to force screen on externally
<racarr_> like powerd-ctl or hatever it was called
<racarr_> does
<racarr_> which should still work for now? but maybe they got changed out
<AlbertA> racarr_: well I think it's kinda related in that right now the screencast turns the screen on
<racarr_> my branch is just about, clients which have explicitly turned the screen off
<AlbertA> racarr_: I believe your MP will avoid that
<racarr_> there was a behavior that automatically turns it back on when they swap buffers
<racarr_> hmm
<racarr_> maybe!
<AlbertA> racarr_: which is good
<racarr_> mm
#ubuntu-mir 2014-03-12
<duflu_> Oh, I just noticed the new trusty decorations. Very nice.
<RAOF> Hey, is there any particular reason we don't run the valgrind tests on package build?
<mlankhorst> probably because nobody added it? :p
<anpok_> good morning mir
<alan_g> good morning anpok_
<anpok_> I would like to extend the way we store and change transformations of surfaces.
<anpok_> In the example I wanted to implement in demo shell I want to make incremental increases of rotation angles around the z axis.
<alan_g> anpok_: I think duflu has also been thinking along those lines
<anpok_> since I also need the inverse of the whole transformation, I would refrain from exposing a transformation matrix..
<duflu> Wha? All I'm thinking is doc review right now :)
<anpok_> so there are so many ways of storing transformations..
<duflu> anpok_: I have a plan, and it looks nothing like the existing classes. Can you wait for me to propose an approach?
<anpok_> and storage does not necessarily affect interface, but it does make certain interfaces simpler or harder to support..
<anpok_> duflu: can I help some way?
<duflu> anpok_: I'm in a mad rush to finish my work today, but I'm happy to talk about it another day...?
<duflu> Do you need something that works soon?
<anpok_> my relative coordinates and input events not being sent to the surface bug is right now in conflict with you recent changes..
<duflu> anpok_: Oh. OK, which branch?
<anpok_> https://code.launchpad.net/~andreas-pokorny/mir/fix-1261647/+merge/210246
<anpok_> I basically now require the input::surface to provide a transformation matrix to get from screen frame to local frame
<anpok_> I was curious about your branch.. curious in which direction it goes..
<duflu> anpok_: Assume there will be no surface-specific transformation matrix at all. Per-surface transformations are very short-lived transient things better controlled by an external animation object. So for input just assume it's always simple and orthogonal a rectangle
<anpok_> well I could imagine having objects in a scene that refer to the real surface to some degree, and those object contain the information about transformations
<anpok_> but I wouldnt call those object animations
<duflu> anpok_: The permanent surface transformation as far as input cares is just the size and position. That's a simple matrix you can generate if you need to.
<duflu> Rotations and slides however are more "view" things than "model" things so I'm trying to get those transformations out of the model (surface implementation classes)
<anpok_> touch input works on the visual .. or view part of our model. it should use as much information as possible from that model
<anpok_> I see that we have to split basicsurface
<anpok_> but the android input stack needs to have access on the view model.. and not directly the surfaces
<duflu> anpok_: If you generate a transformation matrix based on top_left() and size() then I guarantee that will be correct. Anything more complex like a rotation or a slide is too fast and too short-lived to be relevant to input
<anpok_> but thats a shell decision
<duflu> anpok_: Yeah it's a design decision that's actually Mir's responsibility as it relates to any-and-all shells. We should let shells do whatever they want too. I suggest if we do keep some transformation() methods then they will be for the exclusive use of input. However inputting to rotated or moving surfaces is not a useful feature to worry about right now.
<duflu> That's unrelated to screen rotation
<RAOF> Scaled surfaces - eg: pixel-doubled surfaces to handle HiDPI - need more input transformation than just top_left() and size().
<anpok_> hm I thought a complete solution would be straight forward to implement.
<anpok_> I mean.. by restricting two only three dimensions..
<anpok_> s/two/to
<anpok_> so the plan wasnt to have a surface model to communicate.. and a visual/scene model that refers to surfaces and contains the transformation and can be used to dispatch input and as base for rendering?
<duflu> anpok_: BasicSurface has an arbitrary transformation() still, and if there's a good reason then it can keep it. Just that I want to keep the size and position out of that. Add it back in for input calculations if you need to... but I think that's dangerous because you're missing the extra information like how the whole screen is transformed
<anpok_> hm but you still do make use of the transformation in the gl renderer?
<duflu> Remember window decorations have to use the same BasicSurface::transformation() but they have their own size and position, so the matrix cannot contain scaling and position just for the client area
<duflu> anpok_: Yes, the GLRenderer still uses Renderable::transformation() and will continue to for now
<duflu> anpok_: Although in reality I would be happy to say that transformation() will always be the identity matrix. Real animations will be added in during composition/rendering
<duflu> Hmm, maybe
<anpok_> sure that part I agree
<anpok_> also the assumption that the caller would draw surfaces at -0.5,0.5 with a 1x1 quad..
<duflu> anpok_: Actually if you go Compiz-style then the animation is returned from Renderable::transformation()
<anpok_> sorry no compiz backlog here.. but animated scenegraphs..
<duflu> anpok_: Yeah we can't use normalized coordinates. They make attaching correctly sized window decorations too hard. To make all decorations seamless they need to have identical coordinates to the surface itself, and use a scale that is in pixels (not in "surface widths")
<duflu> anpok_: I think transforming input beyond size and position is not useful right now. Not only Unity doesn't need it, but no shell I've ever seen will need it. Screen rotation is of course separate and already done
<anpok_> hm basically I thought that part is now better because the scene objects that we have now only provides the information without imposing a certain way of rendering
<anpok_> sure, i just find it hard to see in which direction we are going..
<duflu> anpok_: Also keep in mind the compositor/renderer may change the whole screen appearance like zooming out to a cube or sliding. In that case, to transform input properly you'd have to ask the renderer for the full matrix sequence and reverse-engineer it
<anpok_> mps only show incremental steps that may or may not approach in the direction
<anpok_> or just ask it to transform to local coordinates, which is simple if is encoded in a view model.. or if there are objects to talk about..
<duflu> anpok_: Yeah it's hard to see the grand plan sometimes, and we often trip over each other.
<duflu> anpok_: I would be reluctant to approve anything which requires matrix math in the CPU/BasicSurface. But I don't plan on removing Renderable::transformation() any time soon so you can still base the work on that
<duflu> Although that matrix will always be identity really
<duflu> Put another way, all information should flow from the scene to the compositor/renderer. We don't want it flowing the other way. It just means for input to "look right" the renderer has to keep the surface visually in line with the model (except during brief animations)
<anpok> 10:54 < duflu> Although that matrix will always be identity really
<anpok> 10:57 <anpok_> I think not much math is needed.. at least compared to for example a cache miss..
<anpok> the other topic I had in mind was changing MirMotionEvent .. it needs a client abi bump .. wasnt sure if that is worth the change.. I dropped unnecessary fields
<duflu> Sorry, busy finishing work for a while
<duflu> I'll be back
<duflu> anpok: Your comment from 10:57 never arrived here :)
<duflu> Looks like Xchat timed out and reconnected
<duflu> anpok: Extending *Event structures is unavoidable and I agree there's more information there than we use. But if it's an optional change we should defer the client ABI break for a later larger release. In the mean time you can safely rename the fields you think are unused to see if that causes an API break without breaking the ABI
<anpok> ok..
<anpok> regarding matrix math .. i think it will be easy to have short cuts for the 90% cases.
<anpok> that dont involve any
<duflu> anpok: If you do go down the road of translating input coords *completely* with the screen, then keep in mind you'll also have to reverse engineer the screen transformation and any temporary changes to it like cube mode or workspace sliding. I think it's a bad idea to do that. Better to stay with just size+position support
<duflu> Hah. I now realize why Compiz used relative motion for everything. So it didn't have to transform input
<duflu> That and the ability to rotate your cubes without hitting a screen edge
<duflu> anpok: Any significant complexity needs an expected use case. If not in Unity then in other shells. I don't think there is a use case for complete reverse mapping on input coordinates with arbitrary transformations right now.
<duflu> And you still don't have access to the renderer's display transformation (which you need)
 * duflu -> dinner
<kgunn> alf__: afternoon sir, let's say i wanted to run glmark2 on my nexus4...at the moment, what do i do ? :)
<alf__> kgunn: bzr lp:glmark2, fix a line in the code (ask me then), ./waf configure --data-path=$(pwd)/data --with-flavors=mir-glesv2 , ./waf , build/src/glmark2-es2-mir
<alf__> kgunn: of course you need to run it against usc or a demo server, as unity8 doesn't accept arbitrary connections
<kgunn> alf__: thanks...
 * kgunn remembers waf defeating him some time ago
<alf__> kgunn: http://paste.ubuntu.com/7079309/ is the change you need to make (before running waf)
<mterry> racarr_, with your greeter-configuration-for-mterry branch, what other changes do I need?  You had suggested there were other changes
<kgunn> alf__: thanks...stuck in a uds session, will try when i free
<alf__> kgunn: np
<greyback> alf__: unity8 would probably accept it if you append "--desktop_file_hint=/usr/share/applications/calculator.desktop" to the glmark command
<greyback> kgunn: ^^
<kgunn> thank for the hot tip
<alf__> greyback: glmark2 doesn't understand this command-line option
<greyback> alf__: darn, it doesn't ignore it
<greyback> alf__: this works: "/glmark2-es2-mir -- --desktop_file_hint=/usr/share/applications/calculator.desktop"
<greyback> kgunn: ^^
<alf__> greyback: interesting!
<kdub> alan_g, how's this sound? https://code.launchpad.net/~kdub/mir/platform-specific-options/+merge/210500/comments/496321
 * alan_g looks
<alan_g> kdub: I think there are more issues than I first realized
<kdub> issues that are existing, because of the review, or both?
<kdub> I suppose I wouldn't mind putting the logic in mir::DefaultServerConfiguration::DefaultServerConfiguration either
<alan_g> Well, there's an issue that to do that you need mo::Configuration to support adding options.
<alan_g> And that is at odds with users having a choice how to supply options
<alan_g> There's an existing issue that nothing says that mo::Configuration has to support the keys listed in its header
<kdub> so, not forcing reliance on boost::program_options
<alan_g> Yeah, why not allow a hard-coded lookup table?
<alan_g> It is a convenience that we do command-line, environment and config files, not a requirement.
<kdub> hardcoded lookup table of what?
<alan_g> Key -> vaule
<alan_g> *value
<kdub> oh, as an alternative implementation of option lookup
<alan_g> Yes. I can imagine most users of Mir don't want to allow all the options to be configured
<alan_g> Could all your logic go into mo::DefaultConfiguration?
<kdub> I think so
<kdub> well, hmm
 * alan_g thinks that would make the most sense
<kdub> yeah, I think we should still make mo::Configuration::add_options boost-free though
<kdub> that way platform library wouldn't need boost::program_options, and the server-implementers wouldn't need it either
<kdub> alan_g, the problem though is that we then need a comment in mo::Configuration that says
<kdub> 'make sure to load the platform stuff'
<kdub> or to be more precise, 'make sure to load and set the platform-specific keys too'
<alan_g> kdub: we shouldn't have mo::Configuration::add_options at all
<alan_g> That belongs in mo::DefaultConfiguration
<kdub> we need some interface for the platform to do add options, just because it dlsyms the function...
<kdub> maybe a std::function to do so or something
<alan_g> We need a comment that says "these keys are always required", "these keys are optional and needed by mesa/android", "other platforms need other keys"
<alan_g> The way your MP does it is fine (within DefaultConfiguration)
<alan_g> We don't need
<alan_g> If someone replaces Configuration then they have to reverse-engineer the options they need to support.
<alan_g> While if someone uses our implementation it is all a bit nicer for them.
<kdub> maybe we need two mo::Configurations, the user one and the platform one
<kdub> and the platform sets up its own mo::Configuration (no add_options) and supplies it to the server configuration
<kdub> yeah, I kinda like that
 * alan_g wonders which of us has gone mad
<alan_g> Where do you think that the platform configuration gets its option values from?
<kdub> it gets its keys and defaults from the platform, but the values are parsed from the environment/command-line/config-file
<alan_g> All the querying of command-line, environment and config is part of our default implementation of mo::Configuration
<alan_g> None of that is a requirement on an alternative implementation
<kdub> right
<alan_g> Actually, I've just realized that your approach has bugs
<alan_g> If you add an option "vt" (say) in platform...
<alan_g> and specify MIR_SERVER_VT=2 in the environment...
<alan_g> then the first time you parse the environment it won't be recognised...
<alan_g> and an exception will be thrown by boost.Options
<kdub> sure, but all the parsing is done before anything other than the options starts using it
<kdub> I think there are better ways though
<kdub> like, maybe I should pass argc/argv to the platform creation and let it decide what to from there
<kdub> the platforms each have their own options, parsed however they want to
<kdub> and the platforms can't see the server options, and the server can't see the platform ones
<kdub> with the downside being, we have to guard against option-name collisions
<alan_g> Or we could "special case" the --platform-graphics-lib option and load the library (and ask for its options) before doing any parsing.
<alan_g> So, remove platform-graphics-lib as an option and, instead supply it via MIR_PLATFORM=android
<kdub> I don't mind parsing the command line for it
<kdub> essentially, that's whats being done in the MP now
<kdub> the_options() triggers a parse, and we get the graphics library name out, then we go and add the platform options, and reparse
<alan_g> kdub: the problem comes with what I described above - you can't supply platform lib options in the environment
<kdub> I don't see the problem
<kdub> we would parse the (command line and the environment and the config file) once to get the library name, then add the options, then parse those 3 again to fill in the other options
<alan_g> If, during that parse an option that isn't recognised (--vt) in my example. boost objects
<alan_g> You can make it ignore unknown command line arguments, but not in the environment
<kdub> oh, so boost can't ignore MIR_SERVER_VT on the first parse?
<alan_g> Exactly
<alan_g> It throws an exception
<kdub> okay, I understand now
<alan_g> It is a PITA that we were forced to ignore unknown command-line options too
<kdub> okay, so we could special case using MIR_PLATFORM (which both the client and server would listen to), or we could pass argc/argv to the platform creation
<alan_g> I still think it best to handle all of it in mo::DefaultConfiguration - and just provide a way (like you do now) for the library to add options to the default
<kdub> yeah, seems like it would keep the code all in one place better
<alan_g> But, for that, we can't get the platform by using boost.Options to parse the environment
<alan_g> and get the platform
<rsalveti> kdub: did you ever look at what would be needed for mir to support an external monitor when using the android backend?
<rsalveti> was using the hdmi adapter yesterday with mako (android), worked nicely
<rsalveti> android basically just mirrors it
<kdub> really?
<kdub> thats excellent then
<kdub> I wouldn't have expected that, I think non-cloning would take some effort though
<rsalveti> yeah
<rsalveti> kdub: just get http://www.amazon.com/gp/product/B00DWGB6CU/ref=oh_details_o00_s00_i01?ie=UTF8&psc=1
<rsalveti> works with mako, flo and hammerhead afaik
<rsalveti> maybe not hammerhead, but I know it works with mako and flo
<rsalveti> nexus 10 also got a mini/micro hdmi port
<kdub> yeah
<kdub> well, thats good news
<mterry> racarr_, with your greeter-configuration-for-mterry branch, what other changes do I need?  You had suggested there were other changes
<racarr_> mterry: Hi!
<racarr_> um
<mterry> racarr_, something about needing something else in Mir land to work
<racarr_> mterry: https://code.launchpad.net/~robertcarr/mir/remove-ensure-display-powered/+merge/209734
<mterry> racarr_, hmm, I have that too
<racarr_> mterry: And what is the behavior now?
<mterry> racarr_, I didn't see a difference.  Screen still turned on when greeter came up.  Maybe I screwed up one of the merges
<mterry> Had both your branches and changed unity8 to use right unity-mir method.  (I thought)
<racarr_> hmm
<racarr_> I guess maybe something extra is going on
<racarr_> how can I reproduce?
<mterry> racarr_, lp:~mterry/unity8/split should be enough
<mterry> racarr_, though that doesn't have the edit necessary to use the right unity-mir call
<mterry> I can give you that diff in a pastebin in a sec
<mterry> racarr_, http://paste.ubuntu.com/7080641/
<racarr_> mterry: Do I need to make any system configuration changes?
<mterry> racarr_, naw
<racarr_> awesome. will look soon
<mterry> racarr_, you'll autologin into a unity8 shell.  Then try locking screen.  It will go black for a sec, then the backlight will come back on (I claim)
<racarr_> not sure whats going on at this point so
<racarr_> just going to have to poke around with GDB and logs and such
<mterry> racarr_, when I'm done with some other work, I'll re-test myself in case I'm drunk
<racarr_> mterry: It is almost 3 pm
<racarr_> :p
<mterry> racarr_, just an expression!  :)
<racarr_> yeah no hurry, I am not going to get to it for at least a few hours. in the zone on some cursor stuff then lunch
<racarr_> haha I know
<kdub> starting to see why we don't have platform specific options yet
<kdub> sometimes i load x86 mir on the phone, and then worry something has gone really wrong
<mterry> racarr_, still here?  Testing with just your  remove-ensure-display-powered works for me now
<mterry> racarr_, in my testing before, I had extracted your diff on top of 0.1.6
<mterry> racarr_, this time I used your branch as-is, and it worked
<racarr_> mterry: Yay!
<racarr_> Ok that should land soon
<mterry> racarr_, oh!  my testing included your unity-mir changes too.  Let me test without to see if those are strictly necessary
<racarr_> I think they are...
<mterry> I believe it.  Just want to triple-confirm for my list of greeter-split branches
#ubuntu-mir 2014-03-13
<racarr_> Yes sounds good
<mterry> racarr_, it still seems fine without the unity-mir change...  It may still be a good change to make.  But the screen doesn't seem to come on at least even without it
<racarr_> mterry: -.- ok well I will see if I can come up with a theory
<racarr_> on that
<racarr_> yay testing :D
<RAOF> duflu: Actually, I think sequence numbers would be a superior solution all 'round.
<RAOF> Also, how did operation: All The Documents go? :)
<duflu> RAOF: Yeah, possibly. You need to have a good story for wrapping though
<RAOF> My story for wrapping is uint64_t.
<duflu> RAOF: Heh, I have thought the same before
<duflu> RAOF: All the documents only turned out to be half the work I expected. And keeping a discussion in google doc comments helps to keep everyone on the same page (literally)
<RAOF> That means you need to care about wrap around in ~30,000 milenia, given a client that makes 1000 requests/sec.
<duflu> RAOF: I'm concerned that also assumes Mir won't be around when the next major jumps in computing power arrive
<RAOF> In what way?
<duflu> RAOF: The wrap around could still feasibly happen if someone runs the same code on a super machine 10 years from now
<duflu> 10 years isn't much
<RAOF> I don't think that's true.
<duflu> But it does defer the problem nicely
<duflu> Hah. We could just move to 128-bit numbers between now and then
<RAOF> If a client makes 1Ã10â¶ requests/sec, wraparound is still in 30,000 years.
<duflu> RAOF: You said 10^3 before
<duflu> oh
<duflu> years not millenia
<RAOF> Yeah.
<RAOF> And 1Ã10â¹ is wraparound in ~30 years.
<duflu> We will need to build a pyramid to store the code and the computer in. They last kind of well
<duflu> RAOF: There is a validation problem with 64-bit ints still. You need to know which values are valid handles. So to avoid the known set of valid handles growing unbounded you need to break the client API and introduce explicit handle destruction
<RAOF> Why do you need to know which values are valid handles?
<duflu> RAOF: Error checking so someone can't accidentally wait on an invalid one?
<duflu> Also, you never know how many waits there will be on the same handle.
<RAOF> It's not a handle now.
<RAOF> I'm not sure that we need to validate wait handles; it'd be nice, sure, but it'd be a pretty obvious code bug.
<duflu> RAOF: Each one still needs some state (signalled or not), even in the single-threaded waiter case. Otherwise you'd be racing waiter against signaller
<RAOF> Ah, sorry. Let me clarify:
<RAOF> mir_{connection,surface,whatever}_wait_sync_point(thing, sync);
<RAOF> Needs no state other than a single integer in the object.
<RAOF> It's signalled iff sync <= last_seen_seqnum.
<RAOF> And MirSurface/MirConnection/MirWhatever can maintain the last_seen_seqnum internally.
<RAOF> We don't even need to change protocol (although this does assume things about our protocol; namely that requests are processed in-order)
<duflu> RAOF: That appears to only work for objects that are signalled in order. In reality you don't know the order they will be signalled in so need to store state with each one
<duflu> Oh, the state is in MirSurface/MirConnection etc
<RAOF> What objects are not signalled in order?
<RAOF> Yeah. At the moment the state could be solely in MirConnection, but I think we'll want to have at least two request streams at some point, so they might as well be in the objects of interest.
<duflu> RAOF: I'm thinking about a generic wait handle system. I guess there's no good reason why mirclient could not become explicitly ordered
<duflu> RAOF: So actually each MirWaitHandle just gets its own counter
<duflu> Or not.
<duflu> Anyway, this is consuming my morning.
<RAOF> :)
<duflu> Jolly good luck improving all the things
<RAOF> Dear valgrind: If you're going to exit claiming an error, it's polite if you make some attempt to inform me what the goddamned error is!
<duflu> RAOF: I feel your pain from here
<RAOF> I _think_ I've finally got _all_ the errors ironed out.
<RAOF> Some by fixing honest leaks in our tests, some by adding more suppressions, and some by telling glib not to confuse valgrind with its memory management.
<duflu> RAOF: Ah glib. It would be nice if we didn't have hard dependencies on big pieces like that
<RAOF> Only the tests do.
<duflu> RAOF: Indirectly from *umockdev* right?
<duflu> That's a build-dep only
<RAOF> Right
<duflu> RAOF, mlankhorst: I notice some time in the past few months intel drm likes randomly losing vsync and tearing. Anyone else seen that?
<duflu> -likes +"has started"
<mlankhorst> nope :s
<mlankhorst> think there might be a bug ab out it though
<duflu> AFAIK, the page flip scheduling Mir uses should mean that Mir can't be responsible for causing it... (?)
<hikiko> hello
<RAOF> Hey!
<hikiko> hi RAOF :)
<RAOF> Has someone managed to figure out your nouveau problem yet?
<hikiko> no :/
<hikiko> but no prob, I had to remove nouveau anyway to debug something else with the proprietary driver
<hikiko> btw could you tell me where I could find the most recent instructions on how to build mir and unity8 on the phone?
<hikiko> (is nexus galaxy still supported?)
<RAOF> I think it still works.
<hikiko> cool :D
<hikiko> so, are there any instructions on how to build everything on android?
<RAOF> As for building for the phone, I always use cross-compile-chroot.sh in the Mir source tree to build Mir; I've not yet had to do a unity8 build, though.
<hikiko> I'd like to test brandon's branch (an sdl demo), maybe I don't really need unity8
<hikiko> but I'd probably need to do a fresh ubuntu installation
<anpok> hikiko: AlbertA recently added a cross-compile-chroot.sh to unity-mir - which fixes the Qt cmake configuration files. I believe with that script unity8 should also build, when you update the build dependencies..
<anpok> hmm .. maybe you also have to change some of the cmake library variables used from discovered build dependencies
<hikiko> anpok, if I just follow these steps: https://wiki.ubuntu.com/Touch/Install
<hikiko> I will only have unity8 and not mir?
<anpok> both
<hikiko> then since my phone is totally outdated I can "just" follow the instructions? I mean they are recent isn't it?
<anpok> hm dunno, I tend to have all kinds of fun due broken usb cables
<hikiko> haha :)
<hikiko> let's confirm it in #ubuntu-touch then
<duflu> hikiko, RAOF: Is that just Mir on nouveau? I can dig up a video card or two and test fairly easily
<hikiko> duflu, I have a GeForce GT 440 with nouveau
<duflu> hikiko: I should still have a couple of Nvidia cards around. But what am I testing?
<hikiko> duflu, when I run the mir server basic or shell
 * duflu also wants to see nouveau *still works*
<hikiko> everything gets stuck (cant switch tty) and I get a message that gbm cant load the nouveau driver
<hikiko> and this happens right after i start it so I dont have enough time to attach the process to gdb from ssh
<hikiko> I ve seen that the error comes from mesa
<hikiko> libgbm
<hikiko> when we create the device
<hikiko> but didn't search further
<duflu> hikiko: OK, I'll try to test some cards soon.
<hikiko> thanks duflu
<duflu> hikiko: Got a bug number yet?
<hikiko> no I will fill a bug report
<hikiko> https://bugs.launchpad.net/mir/+bug/1210646 <- this might be relevant
<ubot5> Ubuntu bug 1210646 in Mir "XMir doesn't work with Nouveau" [Medium,Incomplete]
<hikiko> although in his case mir detects the driver
<duflu> hikiko: I'm not sure that would be the same issue. Please log a new one: https://bugs.launchpad.net/mir/+filebug
<hikiko> https://bugs.launchpad.net/mir/+bug/1291851 duflu
<ubot5> Ubuntu bug 1291851 in Mir "Mir server can't load the nouveau driver when it's starts." [Undecided,New]
<duflu> hikiko: Cool, thanks
<RAOF> How much do we care that the memcheck test is garbage on the CI hardware?
<RAOF> (As in: the test always passes, because the command is malformed)
<alf__> RAOF: How do you mean? We know we don't catch leaks, but at least memory errors were reported.
<duflu> RAOF: Depends if we can actually make it pass. For armhf that may be nontrivial
<alf__> RAOF: (don't catch leak = don't fail on leaks)
<RAOF> alf__: I mean that â3/9 Test #3: memcheck-test .......................   Passed    0.01 secâ passes because the command is malformed.
<RAOF> The test of our memchecker :)
<alf__> RAOF: We care :) How is it malformed?
<RAOF> alf__: Build locally, enable memcheck and disable gtest detection. The test log will show that valgrind doesn't run, because the commandline is malformed. But, happily, we're checking for failure, so that passes.
<RAOF> duflu: Also, https://code.launchpad.net/~raof/mir/udevify-eventhub/+merge/210348 shows that we _can_ make it pass on armhf with fail-on-leak. :)
<RAOF> alf__: See http://paste2.org/6UP8wzIY
<alf__> RAOF: Hmm, where does all this come from? Changes by a CI script?
<alf__> RAOF: (probably judging by /home/chris/...)
<RAOF> alf__: It comes from cmake/MirCommon.cmake, mir_add_memcheck_test() being broken
<RAOF> Specifically, because CMake's variable handling is a legion of fail.
<RAOF> ${VALGRIND_ARGS} is a list, which expands to a semicolon-delimited list in some circumstances, such as when we're trying to pass them to sh -c.
<alf__> RAOF: We don't have many of the options from that output in our pristine codebase in VALGRIND_ARGS
<RAOF> It works in the other codepath because it's cmake interpreting the list, and it does it correctly.
<RAOF> Oh, that's true.
<RAOF> I think we have enough options to trigger the problem though. Let me check!
<alf__> RAOF: that's why I think it's probably some CI script changing something
<alf__> RAOF: but yeah, I think you are right, we do have that problem even with just our own options
<alf__> RAOF: how can cmake be so broken...
<RAOF> Buildsystems.
<RAOF> Mess with people's brains.
<alf__> RAOF: please file a bug then and I can take a look if you don't have a solution yet
<RAOF> alf__: Sure. I've bashed my head on this one enough I think :/
<anpok> hm in one case VALGRIND_ARGS is meant to be a list is, in the other case we want it to be have as a string
<RAOF> Yes.
<anpok> -is
<anpok> so string (REPLACE ";" " " VALGRIND_ARGS_AS_STRING "${VALGRIND_ARGS}")
<anpok> should work
<anpok> of course only when the args dont have ; inside :)
<RAOF> :)
<RAOF> alf__, anpok: Enjoy 1291876
<RAOF> Or even bug# 1291876
<RAOF> bug #1291876
<ubot5> bug 1291876 in Mir "memcheck-test doesn't test anything when DISABLED_GTEST_DISCOVERY is enabled" [Undecided,New] https://launchpad.net/bugs/1291876
<alf__> RAOF: anpok: cmake => "string types ought to be enough for everybody" (but let's hack lists in them too!)
<RAOF> Well, either string types or lists would be fine.
<anpok> hm internally I believe they treat them as separate types..
<RAOF> But they've managed to make it so that ADD_TEST(foo "String of stuff") doesn't work, because "String of stuff" is attempted to be run as an executable verbatim, and you can't trivially escape "s.
<RAOF> (For some absolutely bizzare reason, when I tried "\\\"" it ended up in the CTest file as "/""
<anpok> hehe
<alf__> anpok: I don't know: "In CMake all variables are of the type string. Nevertheless CMake can deal also with lists. If a string contains semicolons, these semicolons can be interpreted as separators of string values. "
<anpok> ah
<RAOF> Oh!
<RAOF> You know how we could fix this?
<RAOF> By not trying to use cmake here!
<anpok> the issue is only on armhf, because append items to the string?
<RAOF> No, the issue is everywhere.
<RAOF> Ok.
<RAOF> I think I know what to do.
<RAOF> I'll take Zoe out to the park for a bit, come back, and see if I really do.
<anpok> hm why dont I see leak-check=full
<anpok> have fun
 * anpok crawls back into his cave
<RAOF> YES! I (finally) win a CI run of udevify-eventhub that would fail on leaks but doesn't, because we don't leak. And passes on all our architectures. And doesn't have glib confuse valgrind seven ways to Sunday.
<mlankhorst> or are you certain of that?
<mlankhorst> you probably sneaked a 'void *malloc(size_t sz) { static char buf[8 * 1024 * 1024]; return buf; }' in somewhere
<mlankhorst> :P
<RAOF> I'm surprised how much glib confuses valgrind.
#ubuntu-mir 2014-03-14
<RAOF> duflu: I think you fundamentally misunderstand the purpose of memcheck-test :)
<duflu> RAOF: Yeah possibly
 * duflu goes to find lunch
<RAOF> duflu: Does my latest comment help?
<duflu> RAOF: Yep
<RAOF> Urgh.
<RAOF> Why does touch produce weird input events?
<anpok> RAOF: weird?
<RAOF> anpok: I get weird results when recording/replaying with umockdev.
<anpok> oh ok..
<RAOF> Which makes "operation refactor how touchscreens work" somewhat less safe... :)
<anpok> hm I am cleaning up relative coordinates in motion events
<anpok> I hope we dont run into conflicts
<RAOF> anpok: Unlikely, I think.
<RAOF> Good weekend, everyone!
<Saviq> hey folks, any idea about this abort? http://pastebin.ubuntu.com/7089395/ first time I saw it, it seems to happen (very rarely, like once every 40 runs or so) on unity8 exit under 5.2
<alan_g> Saviq: looks like it comes from mia::InputRegistrar::handle_for_channel() - but I don't know why that would be without digging.
 * alan_g wishes folks didn't throw exceptions that are not going to be handled. we have abort() for a reason.
<Saviq> alan_g, ok, I'll file a bug if/when I get it again
<duflu> Good weekend indeed
<Saviq> alan_g, FYI: bug #1292472
<ubot5> bug 1292472 in mir (Ubuntu) "unity8 crashed with what(): Requesting handle for an unregistered channel" [Medium,New] https://launchpad.net/bugs/1292472
<alan_g> Saviq: ack
 * alan_g wonders why his DE just restarted
<kdub> alan_g, I usually blame gamma rays
#ubuntu-mir 2014-03-15
<Guest92458> hi
#ubuntu-mir 2015-03-09
<robert_ancell> Has anyone been looking into Freon on ChromeOS?
<duflu> robert_ancell: Not as far as I know. Seems probably irrelevant. It's a very lean single "platform" implementation of what Mir's "Mesa" platform is.
<duflu> ... which I'm working on making even faster
<robert_ancell> duflu, I'm interested in what they did for input devices / access permission to the drm device etc
<duflu> robert_ancell: Are we not going to do it the way we did for X11? Or searching for a better option?
<robert_ancell> I'm just interested in their solution. I don't think it has any effect on us
<duflu> robert_ancell: Also remember ChromeOS/Android != Ubuntu
<robert_ancell> They have a very limited use case so they can drasticly simplify.
<duflu> Whatever they use we might not have, and vice-versa
<robert_ancell> I didn't make that connection at all...
<duflu> robert_ancell: In the same way that Android kernel != Ubuntu kernel
<robert_ancell> I'm pretty sure their kernel has nothing to do with the Android one
<duflu> robert_ancell: No, but you're assuming it's closer to Ubuntu than the Android one is. It might be equally distant in new ways (tm)
<robert_ancell> I haven't made that assumption either
<duflu> robert_ancell: Suffice to say Mir already has code that replaces what Freon does. And that DRM platform in Mir we call "Mesa" is excitingly more mature and capable than Mir's Android platform
<duflu> Although we're always working on improving performance
<alan_g> alf_: duflu anpok_ - anyone else going to look over this? https://code.launchpad.net/~albaguirre/mir/fix-1427976-take2/+merge/252031
<duflu> alan_g: If so then not today
<alf_> alan_g: I will, in a bit
<alan_g> greyback: thanks for confirming U8 does what I suspected.
<greyback> np
<greyback> giving input focus to somethign which isn't visible to the user is just wrong IMO
<alan_g> Me too. But someone put in the effort to do it and the rest of us let it land.
<duflu> greyback: I thought so too. But now come to think of it, that's useful. We can just get the Scene (SurfaceStack) to check if the focussed surface is visible() next time it does a frame. And if not visible by then, revert to previously focussed
<duflu> Give the surface a frame to become visible and if it's fast enough, it gets focus.
<duflu> Although there's also the cookie stuff ...
 * duflu -> dinner
<greyback> duflu: with unity8, the surface only appears in the SurfaceStack (equivalent) when it has drawn a frame
<greyback> is a surface a surface if nothing has been drawn?
<greyback> I think no
<duflu> greyback: Right, but you need to know "preferred focus" which might be a surface not yet visible
 * duflu -> dinner really
<greyback> duflu: sure, but that's a focus decision, which is more likely related to surface being user-visible than being created
<greyback> ah, he's gone
<alan_g> There are also scenarios (like activating menus) where it isn't essential for the surface to paint for it to affect the processing of input. (But there are other ways to handle that.)
<greyback> right
<alan_g> alf_: you've tracked down a couple of these in the past. I must be missing something - have you time to help? https://code.launchpad.net/~alan-griffiths/mir/is-NullWindowManager-better-than-GenericShell/+merge/252147/comments/626462
<racarr> InputDispatcher->InputSender port is mostly working...some race appearing where the finished signal isn't percolating properly and then delivery starts to slow down (timeouts eventually make it work)
#ubuntu-mir 2015-03-10
<racarr> Yay InputDispatcher on InputSender is working...
<racarr> though I have to understand this FD limit in glib_main_loop...
<racarr> and I guess this requires full stack testing (joy joy)
<racarr>     static int const max_write_fds{100};
<racarr> (though its 10 in trunk)
<racarr> in glib_main_loop_sources.cpp
<racarr> does anyone understand why this is done with a static array?
<racarr> alf_: ^ ?
<alf_> racarr: trying to remember...
<alf_> racarr: I think it's so that multiple main loops can handle the signals in a sane way
<racarr> alf_: Ah...I sorta see...I had just realized that must be the purpose of the
<racarr> "static std::once_flag"
<racarr> (which is unfortunately breaking test isolation...)
<racarr> or I speculate may be :)
<racarr> Now my problem is just after a few dozen acceptance tests the same one always fails
<racarr> but passes when run in isolation
<racarr> with the "Failed to add signal write FD"
<racarr> exception from glib_main_loop_sources
<racarr> so the static seems to blame
<alf_> racarr: isn't the array cleared when the sources are unregistered in each test?
<racarr> alf_: Seemingly not...(commenting out the call once and just clearing it on construction does fix the immediate issue)
<racarr> I dont really understand whats happening yet though
<racarr> its possible things are not being properly unregistered
<anpok> alf_: remember? I ran into something similar and fixed it..
<anpok> racarr: the idle source may not be executed.. then floats around .. and gets picked up by someone else or worse..
<anpok> idle source that cleans up on destruction of the main loop
<racarr> hmm :/
<anpok> https://code.launchpad.net/~mir-team/mir/fix-delayed-sigaction-restore/+merge/249862
<anpok> never completed because dispatchable was simpler for my task and because creating a valid test case for the issue was really hard
<anpok> the test attached caused all sort of issues inside glib
<alf_> anpok: so this is a side-effect of the workaround to unref in the idle thread?
<alf_> anpok: s/idle thread/idle callback/
<anpok> maybe
<anpok> maybe we have case where the cleanup never happens?
<anpok> hm or are the fds cleaned up directly, and not together with resetting the sigactions?
<anpok> hmm but with the fix I only evade the delayed manipulation of sigaction
<anpok> it does not solve the issue that there is something wrong with the cleanup callback
<anpok> (or with the library underneath)
<alf_> racarr: anpok: I don't have enough info to know if the issue you are seeing is the same anpok saw. In any case, if you have an easily reproducible use case, let me know, and I can take a deeper look.
<racarr> alf_: Thanks...im sure ill  be getting back to youtomorrow :)
<racarr> I have one more input isolated issue which I am going to
<racarr> clean up first for sanity
<anpok> racarr: hmm you could try adding some traces that dump the g_main_context, thread id on main loop construction/destruction/signal cleanup
<robert_ancell> Where is the XMir branch?
<mlankhorst> robert_ancell: on fd.org git
<robert_ancell> mlankhorst, oh hey, still online? :)
<mlankhorst> http://cgit.freedesktop.org/~mlankhorst/xserver/log/
<mlankhorst> you should come online sooner next time though, about to sleep
<mlankhorst> I'm maintaining it there as a bunch of quilt patches
<mlankhorst> should probably be moved to a separate branch on top of xorg-server instead
<robert_ancell> mlankhorst, I assumed you were already off. I was here two hours ago. Is that a good time to talk tomorrow?
<mlankhorst> are you ever on during mornings?
<robert_ancell> whose mornings?
<mlankhorst> <
<mlankhorst> erll yours
<robert_ancell> It's my morning now
<mlankhorst> oh australian time?
<robert_ancell> New Zealand
<mlankhorst> ahh
<robert_ancell> mlankhorst, what works best for you, either two hours earlier than now or in about 9.5 hours (not today though)
<mlankhorst> about 10 hors from now
<robert_ancell> OK, I'll try and catch you then in a few days
<mlankhorst> oke
<robert_ancell> thanks
#ubuntu-mir 2015-03-11
<duflu> tmpRAOF: I have no opinion but it looks like your big fd branch would be landable
<tmpRAOF> 3 approves is probably good enough :)
<duflu> tmpRAOF: That and 1.5 months
<duflu> That said, I had a branch that looked like it was going to land until it got to about week 6
#ubuntu-mir 2015-03-12
<robert_ancell> mlankhorst, hey
<duflu> alan_g: I find myself potentially having to route logic through the frontend shell code. Although I can skip it for now if any of libmirserver will change again...?
<duflu> I don't want to base it on classes that might change
<duflu> It's functional without touching shell already. But in future should use shell.
<alan_g> I expect some functions to get added to frontend::Shell to support sizing, morphing etc. But that's not my immediate agenda.
<duflu> alan_g: Yeah, just about done :)
<duflu> But the proof of concept is renaming, which doesn't need WM policy (yet)
<alan_g> Surely there should be a policy about names. ;)
<duflu> alan_g: Doubt it. Never seen a shell that modified what an app set...
<alan_g> *something* needs to decide what to do if the name is stupidly long and won't fit in the decoration. I don't see that being the compositor
<duflu> alan_g: Actually it is. That affects rendering and fade out etc. And even if it doesn't fit, the task switcher and panel etc still know the full name
<alan_g> OK, (at least for now) it isn't as though we can't refine the logic later.
<duflu> alan_g: Well all other spec morphs will need intervention of the shell. But I'm intentionally keeping that out of stage one
<anpok> in the old days figuring out where to place letters was a compositors job.. but compositor is no longer a synonym to typesetter
<anpok> at least in the world of display servers..
<duflu> anpok: Also we don't draw lines... "Shell" includes compositor, WM, whatever you want.
<duflu> Which makes sense... until you realize how mammoth a job it is to build all that. We need to make it a bit easier.
<duflu> With reusable bits
<anpok> yes it is easy to avoid conflicts or disagreement by just making general statements. I would conclude with the shell author should not have to replace or override the compositor to get a different title or decoration.. your example above just shows that the surfaces arent the right place to make layouting or display related changes to the text. The original problem seems that we havent established that o
<anpok> ther place yet..
<anpok> oh that message got long
<anpok> bleh ModuleDeleter is no silver bullet I still have to take care of well defined ownerhsip
 * alan_g resists quoting Brooks
<anpok> :)
<duflu> Each window has a "title" string. I haven't asserted anything beyond that other than suggesting it should be UTF-8
 * duflu is confused, but also doesn't care as it's just about EOD
 * duflu goes to cook weird-looking mushrooms
<mpt> Would Mirâs security mechanism require command-line utilities where you choose a window, like xprop, xwininfo, or xkill, to be given special privileges?
<alan_g> alf_: your tools/update_package_abis.sh just saved me from pushing a broken change. Thanks!
<alf_> alan_g: good to hear!
<anpok> alf_: alan_g: AlbertA: interested in reviewing https://code.launchpad.net/~andreas-pokorny/mir/dispatchable-action-queue-and-fixes/+merge/252451?
<alf_> anpok: sure, will take a look in a bit
<alan_g> anpok: ok
<greyback> alan_g: hey, I noticed in mir::Scene:Surface, the methods configure & query are marked to be removed. And instead to read/write an attribute on a Surface, you need to go through AbstractShell. Isn't that a bit roundabout?
<alan_g> greyback: it is more that the attribute implementation doesn't fit well with the MVC design that we were trying to stick to. The model (scene) should only contain stuff that is on interest across the system, the shell is the main consumer of attributes and they ought to be supported there.
<alan_g> Certainly only the shell should be updating the model, not "anything that can view objects in the model".
<greyback> alan_g: okay. It doesn't quite gel with me (cuz in my mind, the SurfaceStack is the model, Surfaces are entries in the model), but I'll acquiesce to your better judgment
<alan_g> Essentially the model shouldn't be responsible for holding all information about surfaces that any part of the system might want. Only the information that is shared across the system. (If you think about the canonical MVC view as a widget, the model doesn't need to know the typeface)
<greyback> fair, ok
<alan_g> anpok: I may be missing something: is there an advantage to using an Fd over a condition variable?
<anpok> well apart from the fact that you can use the fd in a more neutral way with regard to the threading model ...
<anpok> the Dispatchers that execute Dispatchables need fds
<nikwen> Hi!
<kdub> hello nikwen
<nikwen> I have a question regarding Mir and Slimport devices.
<nikwen> I've installed the latest version of Mir from trunk on my vivid Nexus 4 and connected my Slimport adapter.
<nikwen> When I connect the phone to a screen, I only see a black screen.
<nikwen> However, the syslog shows that the device detects my monitor (I've tried with multiple ones) and the devices recognize that there is some input.
<nikwen> The display that there's a 1920x1080 (60 Hz) source attached, but yet the screen is black.
<kdub> well, id make sure that everythings powered down and up with the slimport attached, mine's a bit flaky sometimes
<nikwen> Do I need any other piece of software? How can I verify it's not an issue with the hardware?
<nikwen> Btw, I've tried with two (sadly poor-quality) HDMI cables and three monitors.
<kdub> and, the mir demos should work, but unity8 needs some work to get going
<kdub> and maybe the display-report or compositor-report or hwc-report (from mir's --help option) can give some clues as to what mir is doing
<nikwen> Ah, that might be the issue. Do I need to install a special version of Unity8? If so, which branch should I install?
<kdub> nikwen, I'd just advise tinkering with the demos at the moment, and waiting for that stuff to trickle out, /me has lost track of which branches need to go together
<nikwen> kdub, ok, thanks. I'll check whether I can get the demos working. :)
<kdub> no problem
<nikwen> I'll definitely report back if it works. ;)
<anpok> oh terry pratchett died
<nikwen> Hi, it's me again.
<nikwen> kdub, Mir is working with my Slimport. :)
<nikwen> Now I'll just have to find and compile the proper branch of Unity8. :)
<kdub> nikwen, great!
<nikwen> kdub, big thanks for your help. I thought my Slimport might be broken but I'm glad it was software-related.
#ubuntu-mir 2015-03-13
<alan_g> alf_: answered? https://code.launchpad.net/~alan-griffiths/mir/update-libmirserver-symbols/+merge/252568
<alf_> alan_g: yes, thanks
<zzarr> hello!  I need guidance to get 3D acceleration to work with the mir display server with the help of libhybris with a mali 400 gpu
<zzarr> I have a pcduino3 board with a AllWinner A20 SoC
<zzarr> there's an Android image for the device
<alan_g> zzarr: you'll likely get the best help from kdub or AlbertA who are on USA time - they know most about bringing up android based devices.
<zzarr> okey, what dose USA-time mean in CET?
<alan_g> yes.
<anpok_> zzarr: hm expect them to arrive between 14:00 and 15:00
<zzarr> is it -6 or -7 hours?
<zzarr> thanks :)
<anpok_> dunno... thats when they start to show up usually
<alan_g> UTC-6
<zzarr> thanks :)
<zzarr> I love this community :)
<ogra_> zzarr, you will most likely want to read the ubuntu-touch porting guide
<ogra_> to get a shrunk down android container working that provides the necessary hybris setup
<zzarr> I'll look in to it
<zzarr> I'm about to port Ubuntu to a Android phone to... but that's next chapter
<ogra_> right, but i guess the setup you need will be the same in both cases
<ogra_> (or at least pretty close to each other)
<zzarr> I think so too :)
<alan_g> Why is mir_connection_create_spec_for_input_method() in mir_surface.h?
<kdub> zzarr, yes, you have to have that porting guide followed so that the android container is set up properly, but after that, the mali 400 should work with mir
<zzarr> thanks kdub :)
<greyback> kdub: hey, I was testing qtmir with duflu's favourite: a client which renders as fast as possible (mir_demo_client_egltriangle -n). I'm relying on mir's frame-dropping ability - so when qt renders, it just grabs a buffer with compositor_snapshot and releases it after swap & flip. However flip is taking >270ms in this case!!
<greyback> would you have any ideas on why that is/where to start looking?
<greyback> there is not such a high flip time with a client that respects vsync
<kdub> greyback, so I guess the defaulte frame dropping in mir kicks in after 100ms, so that could account for some of it
<kdub> hah, defaulte, that's the english spelling, right?
<greyback> ye olde spelling perhaps :)
<greyback> mir's framedropping timer causes it's own compositing to block?
<kdub> it shouldn't but maybe that compositor_snapshot that's in the loop is causing the blockage?
<greyback> I put a timer around mg::DisplayBuffer::flip()
<kdub> hmm, and android or mesa platform?
<greyback> mesa
<kdub> greyback, so duflu and I are looking into these bugs, https://bugs.launchpad.net/mir/+bug/1377872, and https://bugs.launchpad.net/mir/+bug/1429264
<ubot5> Ubuntu bug 1377872 in Mir "Double-buffered compositing performance is very poor (30 FPS) on intel" [Medium,Confirmed]
<ubot5> Ubuntu bug 1377872 in Mir "duplicate for #1429264 Double-buffered compositing performance is very poor (30 FPS) on intel" [Medium,Confirmed]
<kdub> I think there's something amiss with the switch to double buffering... if its easy to reproduce, probably best to file a bug and we can dig further
<greyback> it must be something I'm doing wrong, as mir_proving_server doesn't behave so badly
<greyback> you would have noticed 4fps as being broken :)
<alan_g> greyback: mir proving sever does weird shit - like compositing in an input event handler
<greyback> alan_g: eee okay
<kdub> we're just proving how robust we are? :)
<kdub> greyback, at any rate, I think either me or duflu would be interested in seeing if we can reproduce and figure out what's going on
<greyback> kdub: ok, I'll email with a branch & instructions
<kdub> greyback, thanks
<mpt> Defining default window position is doing my head in
<mpt> âCascaded relative to another window means positioned one title-bar height lower than the other window, and one title-bar height to the right in an LTR language, or one title-bar height to the left in an RTL language â unless this would result in any part of the window being off-screen or in shell space, in which case the window should be shrunk the minimum amount to avoid this if that would not make it smaller than its minimum width/height, or otherwise
<mpt> should be placed at the top left (LTR) or top right (RTL) of the displayâs biggest non-shell space.â
<mlankhorst> does mir handle pure KMS devices?
<mlankhorst> I'm running ubuntu on a tegra device that has a separate drm node for display and rendering
<kgunn> mlankhorst: what do you mean by pure KMS ?
<mlankhorst> I don't think there is a corresponding egl device for it
<mlankhorst> so it's a similar case to a displayport external usb
<kgunn> mmm, tegra w/o an egl
<kgunn> vogons ^
<mlankhorst> shrug I'm testing with nouveau
<mlankhorst> itt's a jetson tk1
<kdub> eh, we probably need gbm/egl at some point of the initialization
<mlankhorst> so if I plug in a displaylink it won't work?
<kdub> not sure
<mlankhorst> displaylink is a pure USB display that works with the modesetting driver in xorg
<mlankhorst> but there's no mesa driver for it since it has no acceleration
<racarr> I think it wont work
<mlankhorst> thought as much
<racarr> Because theres no GBM backend
<racarr> rather than thelack of GL so to speak
<racarr> the GL could be software
<racarr> I guess we'vebeen hoping
<racarr> that SimpleDRM/GBM (having a total blank...people from redhat are working on it...) or whatever its called
<racarr> will solve this for us as iirc it includes
<racarr> a software GBM backend
<mlankhorst> dumb GBM?
<racarr> I think it's not dumb gbm haha
<mlankhorst> I mean that would be what you need there
<mlankhorst> using the 'dumb' interface :p
<racarr> oh no but I mean I think
<racarr> that interface doesn't quite do enough
<racarr> thats what we use for software buffers on mesa (or I think...used to use?)
<racarr> I think that doesn't provide a fake/software GBM 'device' though?
<racarr> sorry it's been months and months since I've thought through this.
<racarr> tl;dr; things without mesa bits wont work as it stands
<mlankhorst> bleh
<racarr> we are kind of expecting someone else to provide themissing piece?
<racarr> but that was months ago
<mlankhorst> why isn't the dumb interface sufficient?
<racarr> mlankhorst: Hmm well the first problem is how would you even get gbm_device
<mlankhorst> same way? :p
<racarr> mlankhorst: iirc though the dumb buffers are a feature of the
<racarr> GBM DRI backend
<racarr> but the DRI backend will fail to open a device
<racarr> without
<racarr> mesa bits
<racarr> obv
<mlankhorst> you have a swrast gallium driver though? :P
<mlankhorst> why wouldn't that one work?
<racarr> I dunno lol, you'd have to try
<racarr> I guess the first point of failure would be mir only enumerating dri devices via udev (probably true?)
<mlankhorst> that's fine, it's a dri device..
<racarr> I guess I don't know whatI am talking about then :)
<racarr> I thought it would be a DRM device but not a DRI device?
<racarr> I now refer you to alf or raof :p
<mlankhorst> oke
<racarr> Maybe it will work lol
<racarr> there's some stuff about loading the swrast driver in
<racarr> the gbm dri backend now that I dont remember
<mlankhorst> I think that's kms-swrast
#ubuntu-mir 2016-03-14
<anpok_> wetab only had a i915 gpu?
<duflu> anpok_ ??
<anpok_> duflu: over the weekend someone asked for help with ubuntu touch on that device ..
<anpok_> what he described is just like the i915 experience
<duflu> anpok_: Cool. I've been wondering when that would happen. Have intel tablets gathering dust
<anpok_> which is .. qt applications trying to create gl 2.0 context fail to start
<duflu> Although for them it's probably just a matter of "what's the apt command to turn Ubuntu into Ubuntu Touch?" :)
<duflu> anpok_: Oh, yes that too. I have a very old desktop I have refused to throw out for testing that. Not sure it will ever be useful
<anpok_> because ubuntu mesa disables gl 2.0 support for those devices.. because it would run in llvmpipe only .. and paired with that cpu the performance is just horrible..
<anpok_> a fixed function gl solution or a good software backend for qt is the only way to fix that..
<duflu> anpok_: You mean a new shell :) Our UI toolkit is all shaders...
<anpok_> oh yeah...
<duflu> I've been expecting this to become a thing. Unity8's hardware requirements is already too high for lots of Ubuntu users with legacy hardware
<anpok_> hm i guess you could get very far by ignoring that there are shaders defined..
<duflu> anpok_: I think I've seen that bug happen. What you get is blank windows (no text or widgets)
 * duflu wonders why bzr is taking 10+ minutes for a push
 * duflu realizes it's cos when you push to the wrong project, the diff is large
<duflu> anpok_: The good news is Unity7 falls back automagically to LLVMpipe, and it's usually fast enough that most people don't notice. Just with some tearing and no dash blur
<duflu> Although Unity7 has the benefit of hardware acceleration support for i915 :P
<duflu> So I'm not sure just how bad LLVMpipe on i915 would be. Probably not great
<anpok_> well.. not useable on atoms at least
<anpok_> but ok on a i7 or xeon
<duflu> anpok_: Atoms are 64-bit and use i965 now :)
<duflu> But I would like it if we didn't retire old hardware just out of software limitations/ignorance
<duflu> I recall the first one actually occurred in Mesa (dropping old GPUs)
<anpok_> hm maybe there is a way to get the qtpainter bakend back into qtuick rendering...
<alan_g> alf_: should this failure worry us? https://mir-jenkins.ubuntu.com/job/build-2-binpkg-mir/arch=i386,compiler=gcc,platform=mesa,release=xenial/445/console
#ubuntu-mir 2016-03-15
<AlbertA> vogons: umm haven't been able to connect to hangouts
<AlbertA> or canonical irc
<alan_g> AlbertA: I think some of the internal network dropped out
#ubuntu-mir 2016-03-17
<mzanetti> kdub, ping
<kdub> hello mzanetti
<mzanetti> kdub, hi. I'm investigating in the crashers we have on turbo. seems all of them choke on the same boost exception.
<mzanetti> I'd like to test the branch you linked
<mzanetti> do you happen to have a package I could install?
<kdub> yes mentioned in tracking bug, https://bugs.launchpad.net/mir/+bug/1554635
<ubot5> Launchpad bug 1554635 in Canonical System Image "Importing contacts trigger unity restart - Mir crashed with exception 'failed to add sync point to command buffer'" [Critical,Confirmed]
<kdub> mzanetti, still searching for the dmesg and /system/bin/logcat log at the time of the problem, if you have that
<mzanetti> thanks!
<mzanetti> kdub, dmesg: http://paste.ubuntu.com/15408731/
<mzanetti> kdub, logcat doesn't seem to print anything when this happens
<mzanetti> kdub, well, here it is: http://paste.ubuntu.com/15408756/
<mzanetti> kdub, the first few lines are before the crash, and then it has stuff when restarting things up
<mzanetti> but immediately before/during the crash, no output happened
<kdub> mzanetti, thanks, yeah, doesnt look like anything suspicious
<mzanetti> trying your debs now
<kdub> mzanetti, thanks
<mzanetti> kdub, what packages are required? just libmirserver?
<kdub> mir-platform-graphics-android8_0.20.3-0ubuntu1_armhf.deb is where the fix is, but the mircommon ones might be needed too
<mzanetti> kdub, seems to still crash
<kdub> hmm, unfortunate
<kdub> it shouldn't crash in the same way though, the exception should be ignored and printed to the log? with an egl error code hopefully
<mzanetti> still seing an exception. let me get a cleaner log
<mzanetti> kdub, http://paste.ubuntu.com/15408876/
<kdub> failed with EGL_BAD_ALLOC
<mzanetti> ?
<kdub> mzanetti, well, I'm not sure what that might mean, but I do see how hte exception is still getting out
<kdub> mzanetti, let me rebuild quickly so it will be caught and maybe things will just continue
<kdub> mzanetti, thanks for the help
<mzanetti> kdub, no prob. please ping me when you have something more to test
<kdub> mzanetti, sure, rebuilding packages now
<kdub> mzanetti, package built in https://private-fileshare.canonical.com/~kdub/mir-debs-1554635-attempt2.tar.gz with second attempt at catching the exception
<mzanetti> kdub, crashing, with this message:
<mzanetti> error installing sync point failed to add sync point to command buffer 3003
<kdub> mzanetti, hmm, don't know how the exception is propogating then
<mzanetti> kdub, k, will attach a debugger, gimme a few, just need to flash another deivce
<kdub> mzanetti, thanks, and if that doesnt work i'll just log the error and not throw an exception at all
<kdub> mzanetti, take three: https://private-fileshare.canonical.com/~kdub/mir-debs-1554635-attempt3.tar.gz
<kdub> should just log without throwing... if it doesn't crash, great, otherwise, its maybe a resource leak
<mzanetti> kdub, logs, not crashing. confirming it "fixes" all the reported unity crashers in that turbo blockers list
<kdub> mzanetti, great, are you still seeing a logged error in the unity8 log? I'm interested in if its a loss-of-context problem
<mzanetti> I do see the EGL warning, yes
<kdub> is it the 3003 error code? or is it something about having no EGLDisplay
<mzanetti> kdub, hmm... I saw some EGL warning at first, but trying to repro now, I can't see it any more
<mzanetti> lemme restart and try fresh
<mzanetti> it's not crashing any more, neither by switching between between browser/messages, nor the content ub imports. both would trigger it reliable before
<mzanetti> kdub, I get this after a fresh restart and then reproducing: [2016-03-17 19:40:29.234223] <ERROR> egl sync fence: failed to add sync point to command buffer: 0x3003
<mzanetti> kdub, however, doing it a second time, it won't print this any more
<kdub> mzanetti, as long as its not spamming the log with that message, its probabyl an acceptable fix
<mzanetti> ak ok... got it printed a second time now
<kdub> although if/when I get a device, i'd be interested to dig further
<mzanetti> it's not spamming tho... it's once per reproducing steps
<mzanetti> kdub, I'll send a mail to victor etc letting him know about this fix, ok?
<mzanetti> will cc you
<kdub> right, and as long as its not spamming its probably acceptable to move through
<kdub> mzanetti, sure, and thanks for the remote help
<kdub> AlbertA, we probably want https://code.launchpad.net/~kdub/mir/fix-1554635/+merge/289419 to ride along in 0.20.3 to unblock that device
<AlbertA> kdub: ok
<kdub> thanks AlbertA
#ubuntu-mir 2017-03-13
<alan_g> anpok: another question about SurfaceInputDispatcher. In drag&drop was expecting a leave event when the cursor drags out of the source target. But AFAICS that only gets sent if no buttons are pressed. Is there a valid reason for that behaviour?
<alan_g> (I know you didn't write this code but racarr isn't about to ask.)
<anpok> alan_g: hm do we keep sending input events if there are buttons pressed?
<anpok> to the window
<alan_g> anpok: SurfaceInputDispatcher.gestures_persist_over_button_down says "yes"
<alan_g> But I don't get why.
<anpok> alan_g: so afaiu when you press a button the window owns the guesture until release.. hence the leave is only sent when all buttons are released
<anpok> so it keeps receiving the motion events even when you leave the window..
<anpok> when there is no owner because the button was not pressed it should sent the leave event the instant you leave the window..
<anpok> the why is probably about menues.. and existing x11 behavior..
<anpok> you dont want mouse interactions to directly end when you accidently leave the window .. the accidently here is identified through button state..
<alan_g> That makes sense. But so does "drag" leaving.
<alan_g> Hmm... I guess I need to introduce another case.
<anpok> hm so a different state from in-guesture to in-drag  with different rules for pointer dispatch
<alan_g> yeah. Feels messy but what choice is there.
<attente> alan_g: hi, i'm looking at https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1669524 (and https://bugs.launchpad.net/mir/+bug/1420334 by extension). sorry i didn't reply to your original question, but can we still get the necessary client api to help implement those functions (always on top, client-side move/resize)?
<ubot5> Ubuntu bug 1669524 in mir (Ubuntu) "GTK window functions `Always on Top, Move and Resize' don't work in Mir/Unity8" [High,Triaged]
<ubot5> Ubuntu bug 1420334 in xorg-server (Ubuntu) "[enhancement] Missing client API for relative surface movement (e.g. dragging client-decorated windows)" [Wishlist,Triaged]
<alan_g> attente: the move API is on the "wishlist" (i.e. not yet moved to "backlog"). You want an "always on top" and "init resize" too?
<attente> alan_g: yes please to "always/keep on top". by "init resize", do you mean initial resize event? i've worked around that so it's not as important now, just requested the size on window creation instead
<alan_g> I mean initiate a resize gesture
<attente> alan_g: oh. ok, yes please to that too :)
<anpok> just another drag state
<anpok> *states
#ubuntu-mir 2017-03-15
<duflu> anpok: I checked errors.ubuntu.com today and found a couple of new USC crashes that are happening in the Mir input code. Have a look (for Criticals or new bugs): https://launchpad.net/mir/+milestone/1.0.0
<duflu> I only picked the ones known to occur in 17.04
<duflu> alf_: Do you have an upstream link for your protobuf fix?
<duflu> "re-fix"
<anpok> duflu: I think they have the same root cause..
<duflu> Win
<duflu> Killing two bugs with one fix
<alan_g> anpok: greyback: questions answered? https://code.launchpad.net/~alan-griffiths/miral/raii-for-blob-and-cookie/+merge/319229
<anpok> alan_g: oh because of the operator MirBlob*..
<anpok> I didnt realize friend can do that..
<alan_g> That's the Barton & Nackman trick
<alan_g> Although the use with "deleted" wasn't possible in the '90s
<anpok> ah friend injects the function at global scope and delete does the opposite..
<anpok> so it avoids that the one with MirBlob* is even considered
<alan_g> s/global scope/namespace scope/
<alan_g> But yes
<alan_g> The one with MirBlob* is in the overload set, but not selected as it requires a user written conversion
<alan_g> camako: need any more answers? https://code.launchpad.net/~alan-griffiths/mir/drag-and-drop-II/+merge/319820
<camako> alan_g, probably ... I'll continue the review
 * bschaefer should review as well
<alan_g> more eyes fewer bugs
<alan_g> (maybe)
<bschaefer> ideally :)
<bschaefer> alan_g, a handle is just the raw data a drag and drop will be passing? (just an arbitrary amount of bytes i assume)
<bschaefer> we could alway typedef it but meh should be fine as a vector
<alan_g> bschaefer: it's a key (an ssid registered with content hub)
<alan_g> But Mir doesn't need to care
<bschaefer> o yeah i see  std::vector<uint8_t> const handle{std::begin(uuid), std::end(uuid)};
<bschaefer> thats fair, was just thinking it didnt give much info on what it was
 * bschaefer looks up what handle actually means and it fits perfectly here
#ubuntu-mir 2017-03-16
<alan_g> anpok: any preferences (or other ideas)? https://code.launchpad.net/~alan-griffiths/mir/drag-and-drop-II/+merge/319820
<anpok> alan_g: on the sequence diagram.
<alan_g> yes?
<anpok> is the dnd handle in the MP the "drag mir_cookie" from the sequences diagrams?
<anpok> hm something to identify data in content hub..
<alan_g> anpok: That was the original suggestion, but we changed our mind. I guess the diagram wasn't updated.
<anpok> so the actual data now?
<alan_g> No. Still a handle for content hub. Just doesn't have to bee the cookie that signed the initial event
<alan_g> greyback: anything you know of that I should look at before a (bugfix) MirAL 1.3.1 release?
<greyback> alan_g: nothing comes to mind
<alan_g> Thanks.
<mterry> Any best practices for debugging Mir?  I'm looking at bug 1673215 ("bind: Permission denied") but Mir aborts after the problem occurs and gdb stepping messes up the timing of Mir, it bails on my thread because I'm taking too long.
<ubot5> bug 1673215 in unity8 (Ubuntu) "Second unity8 user session hangs with a black screen" [High,Triaged] https://launchpad.net/bugs/1673215
#ubuntu-mir 2017-03-17
<dandrader> alan_g, what am I missing on the second approach? http://pastebin.ubuntu.com/24194904/
<alan_g> dandrader: required fields. ;)
<dandrader> alan_g, namely?
<alan_g> If you look in the libmirclientcpp header for surface spec you'll see comments about the fields
<dandrader> alan_g, reading the code, anyone would assume the two snippets mean the same
<alan_g> dandrader: I agree. I hit the same issue writing that header
<dandrader> alan_g, only difference I see is the missing buffer_usage specification
<dandrader> alan_g, compariing with your miral code
<dandrader> alan_g, I suppose those convenience calls all assume hardware buffer usage
 * alan_g finally goes look at the code
<alan_g> buffer usage & pixel format
<alan_g> I know it doesn't make sense. I just work here.
<dandrader> alan_g, right. reading up mir_create_window_spec documentation it does say you must specify buffer usage
<dandrader> alan_g, now my code works...
<alan_g> dandrader: Right, and in the new world order it there won't be a default bufferstream to apply it to...
 * dandrader doesn't know what a "bufferstream"  is
<alan_g> Lucky you!
<dandrader> :D
