#ubuntu-mir 2013-11-25
<alf_> alan_g: perhaps we should go with different executables in the existing (acceptance/integration/unit) directories, e.g., acceptance-tests(-main), acceptance-tests-c89, acceptance-tests-symbol-resolution ...
<alf_> alan_g: unit-tests, unit-tests-umockdev etc
<alan_g> alf_: maybe (although needing umockdev seems more integration/acceptance-test to me)
<alf_> alan_g: yeah, link-time seams blur the test category lines
<alan_g> alf_: maybe that's the key idea: "MIR_ENABLE_SPECIAL_LINKAGE_TESTS"?
<alf_> alan_g: that would leave out the c89 tests, MIR_ENABLE_SPECIAL_BUILD_TESTS?
<alan_g> alf_: do we need to include the c89 test in this category?
 * alan_g doesn't think we even need to link c89 test - it should be compile time
<alf_> alan_g: No, we don't need to include it really, but we need to enable it by default somehow. I guess we can start with SPECIAL_LINKAGE + separate c89 and reconsider if new "special" tests arrive.
<alf_> alan_g: hmm, or is c89 already built?
<alan_g> alf_: I thought it was on by default (but haven't looked recently)
<alf_> alan_g: ok, it is still there, so yes, SPECIAL_LINKAGE is good enough for now if we want to go the separate category path
<alan_g> And using link seams does interfere with other tests, so they do make a coherent category of sorts.
<FunnyLookinHat> Anyone here privy to the details on why Software Center is going away after 14.04? https://docs.google.com/spreadsheet/ccc?key=0AiT4gOXSkmapdGdFejk0MjFydUlNMDVoMXNRdGdkbFE#gid=1
<FunnyLookinHat> Not sure where to ask - but trying to track down the story on this one - I presume click packages will be a replacement or something?
<davmor2> FunnyLookinHat: the applications lens is replacing it.  On desktop that will mean support for debian and click backends aiui, best place is possibly #ubuntuone though as it controls development of software-center now
<FunnyLookinHat> davmor2, Cool thanks!
<olli> kgunn, Saviq http://paste.ubuntu.com/6474449/
<olli> I followed the instructions in the unity8 wiki and am stuck at this stage
<olli> I feel like I am missing like 1 package but can't see it straight
<olli> kgunn, Saviq stderr is misisng, working on it
<kgunn> olli: watch out for ancient ppa's.....i had some really old qt edger ppas that hosed me
<olli> kgunn, this is a virign install on my new laptop
<olli> :)
<kgunn> olli: oh...nvmd
<Saviq> olli, it's possible, we're in transition between in-built shell-facing scopes api and a package outside
<Saviq> olli, not everything got released yet
<Saviq> kgunn, ââ
<alf_> kdub: are you happy with the shm-buffers-part1 MP? If you also prefer base_ptr() instead of map() it's an easy change...
<kdub> alf_, yeah, was just reviewing
<alf_> kdub: (I will probably need to resync with trunk anyway)
<alf_> kdub: s/trunk/development-branch/
 * kdub always calls development-branch trunk too
<truebattleaxe> is anyone having any issues with the display settings after installing mir?
<racarr> morning
<truebattleaxe> hey
<kdub> alan_g, with more-cleanup-of-ownership-of-client-buffers, the changes to buffer ownership will probably trickle into mc::SwitchingBundle, right?
<alan_g> kdub: yes.
<kdub> i'm finding some of the composition changes for overlay are tied to that class
<kdub> trying to anticipate how we'll change
<alan_g> kdub: I don't have anything in flight right now - so you can sneak in ahead of me
<kdub> i don't really want to wade into it if i can help it, but it might be necessary
 * kdub keeps looking
<alan_g> kdub: I don't anticipate changing the logic - just the way buffers are handed out for clients. (Still playing with raw pointer vs unique handle). So I don't anticipate any conflicts with overlays
<kdub> alan_g, okay. at the moment, i'm considering burying the 'frameno' logic back inside of mc::SwitchingBundle
<alan_g> kdub: is that feasible? Surely there needs to be some logic associated with the (possibly concurrent) compositors?
 * alan_g decides it is too late in the day to worry
<kdub> the logic is needed, it just seems to me that the buffer tracker is the best place to keep it
<kdub> instead of splitting responsibility out to the compositor and the buffer tracker
<kdub> i'll see if its cleaner or not :)
<Saviq> hey folks, since the recent mir release, unity8 is crashing on shutdown
<Saviq> could you please have a look https://bugs.launchpad.net/mir/+bug/1253685
<ubot5> Ubuntu bug 1253685 in unity8 (Ubuntu) "unity8 crashed with SIGSEGV in QMetaObject::activate()" [Medium,New]
<Saviq> from what I can see surface is deleted (surface=0x0) in inputarea.cpp
<Saviq> greyback, fyi â
<Saviq> racarr, could you have a look at this over our night â?
<greyback> Saviq: hmm, ok will have a look in a bit
<Saviq> greyback, well, it's EOD for you
<greyback> kinda
<greyback> did start late tho
<Saviq> greyback, your call
<Saviq> racarr, greyback it's very easy to reproduce - just Ctrl+C after running unity8 on the console
<greyback> so I've another 30 mins
<Saviq> (stop unity8 before that)
 * Saviq puts steps to repro
<Saviq> greyback, please try and find someone to continue past your EOD, though
<Saviq> unless you fix it, obviously
<greyback> Saviq: ok
<didrocks> also, if you see it's fixed in latest Mir release, maybe we can just go ahead
<didrocks> (with latest mir + unity-mir + platform-api)
<didrocks> and we release that
 * didrocks would appreciate an email about it in the morning, even if there is no progress
<racarr> Saviq: Ok
<greyback> racarr: if you're looking, I suspect this is the line causing the crash: line 90 of inputarea.cpp in unity-mir
<greyback> racarr: probably that the InputArea has been destroyed before the MirSurface is
<greyback> racarr: I've to run unfortunately, will be back in 4 hours
<kdub> how extensively is DepthID used anymore?
<kdub> also, recursive mutex, sad
<racarr> greyback: Oi thanks
<racarr> kdub: Still used to keep theshell surface on top
<kdub> racarr, ah, okay... i can look past it for now :)
<kdub> was just bemoaning our locking situation in surfacestack
<kdub> the new mc::DefaultDisplayBufferCompositor::composite is beautiful
#ubuntu-mir 2013-11-26
<kdub> hey duflu, I wanted to sync with you on adding overlay support to the compositor
<kdub> pretty much, my plan is to have the platform provide a 'filter' for the scene that will skip GL composition on a surface if the hardware can handle composing that surface
<kdub> so, if the platform can bypass or overlay-composite any given buffer, it simply tells the compositor to skip rendering that surface with GL
<duflu> kdub: Sounds about right. Although all the "filter" code will be replaced by Q*
<kdub> right, i pinged greyback about it, he seemed optimistic that it can be worked into the qt scenegraph
<duflu> kdub: Could be a generalization of BypassFilter, in a way. We just have to remember that if/when Q* take over the scene graph to ensure there's a working Qt replacement
<kdub> right, just like a 'hardware optimization filter'
<kdub> greyback said it wouldn't be too hard to integrate a 'skip rendering these layers' into his work, so hopefully the bypass filter and this overlay work will mesh nicely with that
<duflu> kdub: Before we add yet more filters, I had planned on tidying up and getting back to only having a single surface class passed around filters/renderers.
<kdub> duflu, yeah, part of the work that will need to be done is cleaning up the filter/operators on the SurfaceStack
<kdub> i don't know that the model we have makes sense anymore, with the way we're using it these days
<duflu> kdub: I'm not committing to a particular class or name. Just that it became obvious to me there's so much coupling on the filter/operators that it would make more sense to refer to just something::Surfacelike instead. A single interface
<kdub> perhaps, i haven't really felt out what I like best yet... just that it is pretty coupled
<duflu> kdub: I think it could be dangerous to be specific about the interface. It needs to be a general Surface-like interface to encompass CompositingCriteria, Renderable (buffer acquisition), flagging for overlay/bypass/etc
<duflu> That all fits into some kind of Surface interface I think. If we're lucky, an existing one
<duflu> Hmm, maybe it would be the reintroduction of a "Renderable"
<kdub> got a bit lost
<kdub> we'll probably hash all that out next week though :)
<duflu> Yes. Oh look; final confirmation.
<kdub> yeah, should be a fun long flight
<duflu> Actually, significantly shorter than Boston :)
<truebattleaxe> i've lost my volume control and ability to vol + and - with the keyboard. is there a fix for this
<truebattleaxe> this happened when i installed mir
<duflu_> truebattleaxe: Not sure. That's odd because XMir does not affect input or sound. Those are unchanged to regular X
<duflu_> truebattleaxe: Try uninstalling Mir and make sure the problem goes away. Otherwise it's somewhere else :)
<truebattleaxe> hmm maybe its just how i installed kde
<truebattleaxe> is there any way to update mir? or see if there are updates
<duflu_> truebattleaxe: it's just in normal Ubuntu updates
<truebattleaxe> gotcha. i did uninstall ubuntu software manager and center. i have noticed its probably just muon but for some reason it doesn't get root access
<duflu> truebattleaxe: sudo apt-get update ; sudo apt-get upgrade
<duflu> Will do a regular update (including Mir)
<truebattleaxe> doing that now. just wondering if thats normal with muon. to get the error of no root access
<truebattleaxe> how often is mir getting updated right now?
<duflu> truebattleaxe: On 14.04 every couple of weeks. On 13.10, not at all. (https://launchpad.net/ubuntu/+source/mir)
<truebattleaxe> gotcha. im on 14.04 so that is definitely good to hear
<duflu> truebattleaxe: But XMir does not use Mir input. And Mir has nothing to do with sound. So you should probably search for other causes/solutions
<truebattleaxe> i think i may have uninstalled the sound manager some how.
<truebattleaxe> thanks duflu
<truebattleaxe> so far i've had no problems with mir. It actually seems like my system is faster
<duflu> truebattleaxe: Probably not faster, but very likely smoother. There's extra buffering and page flipping is enforced. So it could really make a visual difference if the existing X driver is below-par
<duflu> Umm, "above" par??
<truebattleaxe> yes i would say above par :P
<truebattleaxe> way smoother
<truebattleaxe> thanks duflu for the info. definitely makes me a bit easier knowing there are updates every few weeks
<duflu> truebattleaxe: No problem. In fact we're trying to get 0.1.2 into trusty this week
<truebattleaxe> a stable release?
<duflu> truebattleaxe: They're all *stable* but it's a snapshot of the latest development
<truebattleaxe> gotcha
<truebattleaxe> once that update comes out i'll compile my desktop setup so i can pass it to my dad. He wants to use linux but he's iffy switching from windows because of ease to use.  So i made something that has all the apps he would use and ease and taking out that "edgyness" of linux to give him the experience he needs
<didrocks> hey duflu, how are you?
<duflu> didrocks: Hello. Good. You?
<didrocks> duflu: I'm fine, even if latest image we promoted isn't that nice, so we'll have to race again today :)
<duflu> didrocks: Well, I didn't land it this time :)
<didrocks> duflu: I was coming to news, I think you heard about Mir making unity8 crashing?
<duflu> But happy to help
<didrocks> duflu: it's the previous Mir release
<duflu> didrocks: I haven't seen any evidence of Mir making Unity8 crash... ?
<didrocks> urgh, the info wasn't sent?
<didrocks> I guess it was https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1253685
<ubot5> Ubuntu bug 1253685 in unity8 (Ubuntu) "unity8 crashed with SIGSEGV in QMetaObject::activate()" [Critical,Confirmed]
<duflu> didrocks: Ah, right. See comment #11
<didrocks> so it's unity-mir (still associated with Mir in my head)
<didrocks> yeah, just reading :)
<duflu> It's very confusing that unity-mir has classes that sound like they're in Mir
<didrocks> yep
<didrocks> so, I guess I have to wait for greyback
<duflu> RAOF: How evil is it to limit width/height of a surface to 65535?
<RAOF> Not very evil?
<RAOF> I guess it depends on what the units are.
<duflu> RAOF: Pixels... so that's 4-gigapixels
<RAOF> Well, not necessarily. It could be a thin strip of a window.
<RAOF> But that's not at all evil.
<duflu> RAOF: Yeah I know. But is it foreseeable for Mir to support multi-gigabyte surfaces?
<RAOF> It's forseeable for GPUs to act on multi-gigabyte *buffers*, but I don't think they're likely to be displayed.
<duflu> I'm conflicted because the most elegant solution to resizing seems to be to make size a MirSurfaceAttribute. Therefore int value = (width << 16) | height;
<duflu> Although if it was beyond 65535 you could just use zero and ask the client to query the buffer properties, as they already do
<RAOF> That (width << 16) | height would be entirely hidden in mir_client_library, right?
<Mirv> filed bug #1254986 and bug #1254987 against unity-mir and unity-system-compositor respectively
<ubot5> bug 1254986 in unity-mir "unity-mir FTBFS against libmirserver11" [Critical,New] https://launchpad.net/bugs/1254986
<ubot5> bug 1254987 in Unity System Compositor "unity-system-compositor FTBFS against libmirserver11" [Critical,New] https://launchpad.net/bugs/1254987
<duflu> RAOF: Yes, behind mir_surface_get_size
<duflu> Although a client could observe events and see the odd value if it wants
<RAOF> It shouldn't be able to do that.
<RAOF> If it's monitoring for size events it should receive a synthesised event, not the raw protocol value.
 * duflu discovers yet another redundant Surface class and is now much more sad
 * alan_g enjoyed their Java and Python IDEs: http://www.jetbrains.com/objc/features/cpp.html
<alf_> alan_g: looks interesting, but mac os x only :/
<alan_g> alf_: that's just the current xcode plugin. They're working on a cross platform C++ IDE
 * alf_ is pretty happy with vim + YouCompleteMe + Syntastic
 * duflu thinks IDE == heresy. Pure code should be pure, accessible, readable and buildable with a text editor and shell :)
<duflu> Although I do now accept syntax highlighting. And feel slightly dirty.
 * alan_g thinks e.g. selecting a block of text and saying "make that a member function" is less disruptive to thinking about the code than doing the steps by hand.
<duflu> alan_g: Pick the odd one out:
<duflu>     std::shared_ptr<graphics::Buffer> snapshot_buffer() const;
<duflu>     void swap_buffers(std::shared_ptr<graphics::Buffer>& buffer);
<duflu> I think we need some kind of consistency, somehow
<alan_g> duflu: they are different use-cases (note the const) but I do agree
<alan_g> We'll get there
<mlankhorst> ok, mesa 10 test build in ppa:canonical-x/x-staging soon
<mlankhorst> might need some mir testing :P
<ogra_> did anything with the input layer change recently ? i cant wake up my maguro anymore without tapping the screen
<didrocks> ogra_: seems you are not popular here :)
<didrocks> kgunn: so, we confirmed that ogra's bug started in the previous Mir release: https://bugs.launchpad.net/mir/+bug/1255045
<ubot5> Ubuntu bug 1255045 in mir (Ubuntu) "screen does not turn on on maguro when pressing the power button" [High,Confirmed]
<ogra_> heh
<didrocks> kgunn: so, putting the current Mir release on hold until this one is fixed
<didrocks> mind having some people from your team looking at it? (and answering on IRC in the future ;))
<ogra_> well, i didnt ping anyone specifically and didnt expect an answer :)
<didrocks> ogra_: still, would be nice if upstream in working hours was reading IRC :)
<alan_g> didrocks: I only answer when I have something to say
<didrocks> alan_g: would be still nice if downstream doesn't have to play catching up to proove/search for which component regressed (this happens a lot) and that can be done with a little bit more communication
<alan_g> I don't have a Galaxy Nexus and don't see the problem
<didrocks> still, I guess you have an idea on what enters Mir trunk
<didrocks> more than us anyway
<alan_g> didrocks: I rarely touch the input stuff. I think dandrader was making changes there a few weeks ago.
<alan_g> Those changes might be (finally) on trunk
<didrocks> alan_g: yeah, so at least, sharing this information would have been a start :)
<alan_g> ogra_: which version of Mir are you looking at?
<ogra_> alan_g, well, the changeset with which it started is http://people.canonical.com/~ogra/touch-image-stats/20131120.2.changes
<ogra_> so somewhere between misetver 9 and 10
<ogra_> *mirserver
<alan_g> ogra_: Ok, that would be from "a few weeks ago". :(
<ogra_> well, it entered th distro on the 20th
<alan_g> ogra_: there's a long and painful story about how stuff gets to Mir trunk. I don't like to think about it.
<didrocks> this is due to a long a painful story to be able to release Mir as well, but we already discussed it
<alan_g> I can't see anything immediately suspicious. The stuff dandrader did in -c 1150 lp:~mir-team/mir/development-branch/ is only test code.
<dandrader> alan_g, there's 1160.1.33 "android-input - Assign more unique touch ids"
<dandrader> alan_g, that needs a recent qtubuntu which finally got a release only yesterday. but it's easy to tell if there's a mismatch there as there would be a crash after you tap on the screen 16 times :)
<dandrader> but that's all about touch events. nothing to do with buttons/keys.
 * alan_g has to go. (If someone can lend him a Galaxy...)
<Kaleo> shouldn't https://bugs.launchpad.net/mir/+bug/1255045 be marked as Critical?
<ubot5> Ubuntu bug 1255045 in mir (Ubuntu) "screen does not turn on on maguro when pressing the power button" [High,Confirmed]
<greyback> didrocks: there's no kgunn for the rest of this week I believe
<kgunn> greyback: whats up ? (on a hangout....)
<greyback> kgunn: oh, I thought you were on hols. Sorry!
<didrocks> greyback: ok, ah no :)
<didrocks> kgunn: you probably missed my pings
<kgunn> very soon ....like minutes...not hours
 * greyback goes back under his rock
<kgunn> didrocks: something wrong ?
<didrocks> kgunn: yeah, basically we have https://bugs.launchpad.net/mir/+bug/1255045
<ubot5> Ubuntu bug 1255045 in mir (Ubuntu) "screen does not turn on on maguro when pressing the power button" [Critical,Confirmed]
<didrocks> kgunn: this is on previous mir release
<didrocks> (and it's promoted in the current image now)
<didrocks> kgunn: I think I'll have to hold any Mir release on it
<didrocks> kgunn: not, it can be on qtubuntu (which had to be upgraded due to the ABI breakage), you have the package version on the description
<didrocks> would be nice if you can assign someone to it
<kgunn> racarr: ricmm ^ can you guys please take a look into this bug ?
<didrocks> thanks
<kgunn> didrocks: so, if flashing dev-proposed will it be in that image ?
<didrocks> kgunn: just flash trusty
<kgunn> ack...thanks
<didrocks> no need for -proposed
<didrocks> kgunn: maguro
<kgunn> didrocks: ah...maguro
<didrocks> yeah maguro (*sigh*)
<kgunn> didrocks: maguro only good for sushi these days...right ?
<alf_> kdub: so in KMS A plane respresents an image source that can be blended with or overlayed on top of a CRTC during the scanout process
<kdub> so similar to android overlays
<kdub> alf_, for what its worth, I think (to the compositor) we can model the hardware cursor as an overlay as well
<kdub> so for gbm, it would be a kms plane or a hardware cursor, and for android, it would be a hwc surfcae
<alf_> kdub: In KMS since this happens during scanout, the result is not really saved anywhere (not in user accessible buffer at least)
<kdub> in android, i think its composited to a buffer, but we don't know exactly when that buffer is ready to see
<ogra_> kgunn, well, maguro uses a PVR chipset ... we will soon have to support intel/android HW too ... that mostly comes with PVR (often enough even the same driver) ... so it makes sens to take care for it
<alan_g> kgunn: the only team member that I think might have a maguro/Galaxy Nexus is kdub
<kgunn> alan_g: ...i thot racarr had one, but surely any help welcome
<alan_g> kgunn: you may be right
<alf_> kdub: @hardware cursor as overlay, probably as long as there is some kind of attribute that tells us that this is the cursor, since, at least with kms, there is a dedicated API for it so we need a special overlay implementation
<kdub> alf_, right, but thats something the gbm platform can sort out so the compositor doesn't have to think about it
<kdub> ricmm, does maguro count on mir to turn the screen on and off? or is handled somehow with sysfs and powerd?
<greyback> kdub: any way I could help you determine that? I've a gnexus here
<greyback> kdub: powerd sets display state by talking to (unity-)mir over dbus.
<greyback> which is setting the MirPowerMode on the display
<kdub> greyback, ok, i have an idea then
<ricmm> kdub: it relies on mir, but afaik robert never plugged that path
<ricmm> something might have changed that prevemts the hwc from restartong unledd there is a toich
<ricmm> powerd does hpwever brong the system.down
<ricmm> which results in the screen going off
<ricmm> having lunch, can help in a bit
<kdub> ricmm, sure, should have something to try by then
<ricmm> ok
<ricmm> typing on phone is hard
 * kdub sees the power button working intermittently on maguro
<kdub> was that the bug? that it doesn't work sometimes?
#ubuntu-mir 2013-11-27
<RAOF> Oh, my.
<RAOF> âmake test ARGS=-j9â
<duflu> Why is freenode timing out so much this week?
<RAOF> Is your internet being terrible again? :)
<duflu> Apparently I'm still connected at full speed. It's only IRC that's weird
<robotfuel> duflu: ping
<duflu> robotfuel: pong
<robotfuel> duflu: I thought I needed the project(<name>) in the cmake file to name and publish an executable, will everything work the same without it?
<duflu> robotfuel: Yeah should work without it, from memory
<robotfuel> duflu: I was just following this http://www.cmake.org/cmake/help/cmake_tutorial.html when I modified the cmake file for this MP https://code.launchpad.net/~chris.gagnon/mir/development-branch-no-valgrind-on-arm-unit-tests/+merge/196406
<duflu> robotfuel: Because it already falls under the mir project
<robotfuel> ah ok, I'll remove it then.
<RAOF> Alright. That's me for the day. See you all in London.
<duflu> RAOF: Happy travels
<tvoss> RAOF, see you in London :)
<alf_> tvoss_: can you remind me why we have the test discovery logic in mir, instead of adding the test directly?
<tvoss_> alf_, iirc, people wanted one executable per test class (unit/integration/acceptance) but more fine-grained output in the output of "make test"
<alf_> tvoss_: ok, and I guess the usual gtest output (which is fine grained) is supressed when running with make test / ctest
<tvoss_> alf_, exactly
<alf_> tvoss_: thanks, I am trying to streamline our testing infrastructure and remove hardcoded assumptions (e.g. ANDROID==armhf==cross-compilation)
<tvoss_> alf_, yup :) I'm not opposed to getting rid of the test discovery in general
<alf_> tvoss_: ... and also remove hardcoded CI specific logic from our build system, instead exposing it as options. As a first step I am trying to figure out what the requirements are from all sides.
<alf_> tvoss_: anyway, to be continued after lunch :)
<tvoss_> alf_, yup :)
<alan_g> alf_: IIRC it was a workaround for a lack of any test output from CI. But we now see output from failed tests, so I think it unnecessary.
<alan_g> alf_: got a moment to talk design?
<alf_> alan_g: sure, hangout or IRC?
<alan_g> shall we start here?
<alf_> alan_g: sounds good
<alan_g> This is about buffer handles
<alan_g> I've been working through the consequences of a single owner handle passed out by BufferBundle
<alan_g> And come across the fact that these would be needed for the in-process clients
<alan_g> Which means that the handles would need to be in shared - to be available for platformgraphics
<alan_g> And I think putting part of (what is logically) compositor there seems distinctly odd
<alan_g> thoughts?
<alf_> alan_g: I don't understand why they need to be in 'shared'. Did you mean libmirplatform?
<alan_g> I did
<alan_g> I meant mirplatformgraphics
<alan_g> The "gbm" or "android" libraries
<alf_> alan_g: ok, let me process this for a moment (and check the code)
<alan_g> alf_: e.g. include/platform/mir/graphics/internal_surface.h
<alan_g> alf_: the alternative design is to use a raw pointer - and at this point it seems like a more elegant approach.
<alf_> alan_g: ok, so the problem is solved this way by InternalSurface not needing the implementation of the buffer handle, and just calling swap/release on the underlying surface
<alf_> alan_g: and unique_ptr is cumbersome because of the need for an explicit deleter signature...
<alan_g> alf_: well I was writing my own handle type, but there's still a need for type information
<alf_> alan_g: right, I meant that if we wanted to use unique_ptr instead it would be cumbersome. What I think would work is a shared header only implementation of a generic unique pointer handle that is more like a shared_ptr in terms of deleter encapsulation.
<alan_g> Possible. But brutal
<alf_> alan_g: I am not necessarily saying that this would be preferable to the raw pointer (and swap/release) approach :)
<alan_g> ack. ;)
<alan_g> We don't actually need release() for the current functionality
<alan_g> Just because of the way some tests are designed
<alan_g> (We don't leak resources or anything)
<alf_> alan_g: What about the buffer bundle returning a normal unique_ptr to an mg::Buffer that knows how to destroy itself?
<alf_> alan_g: (i.e. a decorated mg::Buffer)
<alan_g> As in with the default destructor. Yes, it could be done but like the current design we're creating an unnecessary object every time we pass out a buffer
<alan_g> The thing is we're not really passing out ownership - so smart pointers are at best misleading
<alf_> alan_g: OK then. I think we can start with the raw pointer approach, and if we see that it leads to issues we can reconsider. My original concern was related to your last statement; when using smart pointers there is an expectation that they knows how to clean themselves up, not so with raw pointers.
<alan_g> alf_: agreed a raw pointer says "this one", not "you own this"
<alan_g> alf_: thanks
<alf_> alan_g: You are welcome. Going off on a tangent, I would like, in general, to have a smart ptr ala shared_ptr with unique semantics in the C++ arsenal :)
<alan_g> alf_: If you want it in the standard library you'll probably have to write a proposal for WG21
<alan_g> (It isn't hard to implement, but standardising it...)
<ricmm> greyback: ping
<greyback> ricmm: pong
<ricmm> greyback: I just replied to the screenshotting thread
<ricmm> I believe the scope is too broad for what the actual requirement is, which is to get QA back to where they were before
<greyback> ricmm: you're not wrong
<tvoss_> ricmm, the one thing we should avoid is investing too much work into the screenshotting solution
<ricmm> I said 30 minutes
<ricmm> with 30 minuts you can have a dbus interface that screenshots something and saves to /tmp/unity8/screenshots//formatted-name.png or whatever
<ricmm> greyback: +1/-1 ? I'll do the MR and just ping thomi to see if hes happy with it
<ricmm> thats already days of discussions without unblocking them
<ricmm> which was the real req
<ricmm> tvoss_: ^
<greyback> ricmm: I'm +1.
<ricmm> ok
 * ricmm branches
<tvoss_> ricmm, see Saviq's answer
<Saviq> ricmm, they can't do nothing with screenshots, it's screencasting that they need
<tvoss_> Saviq, did they have screencasting with surfaceflinger?
<Saviq> tvoss_, no
<ricmm> so it has nothing to do with going back to where we were before
<ricmm> nvm then
<tvoss_> Saviq, ricmm +1, it seems to be a mid-term requirement then
<popey> Saviq: tvoss_ when you guys are considering screenshot / screencast, can you also please consider remote desktop? â»
<tvoss_> popey, one step after the other :)
<popey> indeed
<popey> they're all related though
<Saviq> popey, I think nothing we've talked about until now precludes
<tvoss_> popey, agreed
<Saviq> popey, https://lists.ubuntu.com/archives/mir-devel/2013-November/000511.html
<truebattleaxe> GOOOOOOOOOOOOD morning
<alan_g> kdub: over on #ubuntu-ci-eng Saviq is volunteering to test your GNexus fix
<Saviq> alan_g, kdub yeah, gonna take some build time, but I will
<ogra_> just a little hint for the future ... ask the bug submitter to test it ;)
<kdub> Saviq, thanks
<kdub> what i was seeing yesterday on the stock image was it  was working intermittently
#ubuntu-mir 2013-11-28
<Saviq> duflu, re: bug #1255045 - it's very difficult to see on maguro the difference between black and turned off
<ubot5> bug 1255045 in mir (Ubuntu) "screen does not turn on on maguro when pressing the power button" [Critical,Confirmed] https://launchpad.net/bugs/1255045
<Saviq> duflu, but I can see completely no reaction on the screen when pressing the power button
<Saviq> duflu, and indeed the patch didn't help
<duflu> Saviq: Can you look from a wide angle? A backlight usually bleeds through even a black screen from a sufficient angle
<Saviq> duflu, yeah, problem is maguro is AMOLED - no backlight...
<duflu> I suspect I've seen a similar bug on either Nexus 4 or Nexus 7. Can't remember which
<duflu> Saviq: Oh, AMOLED FTW :/
<Saviq> duflu, https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1255045/comments/13 for some syslog activity
<ubot5> Ubuntu bug 1255045 in mir (Ubuntu) "screen does not turn on on maguro when pressing the power button" [Critical,Confirmed]
<Saviq> duflu, so yeah, the lack of activity between power button and touch does not... prove anything... but also does not rule out your "it's black, not blank" suspicion
 * Saviq tries surfaceflinger
<duflu> Saviq: We might have to start with one of the Nexus's where it's more obvious on the traditional LCD
<Saviq> duflu, yeah, except that bug is only happening on maguro isn't it?
<duflu> Saviq: Maybe... I don't have maguro but am sure I saw a similar wake-on-touch problem on Nexus 4/7 some time recently
<duflu> Hmm... and then there's the question; if the screen is truly asleep why power the touch sensor?
<Saviq> duflu, ok, under surfaceflinger I managed to see the difference between blank and black... shite it's subtle, trying again under mir
<Saviq> doesn't help it's past 3am here..
<Saviq> so yeah, one step closer... I'm gonna go now... o/
<Saviq> didrocks, https://code.launchpad.net/~vanvugt/unity-mir/fix-1255045/+merge/197016 seems to work!
<didrocks> oh
<didrocks> really?
<Saviq> didrocks, just doing some more tests, but yeah
<Saviq> as in... waiting 1 minute ;)
<didrocks> Mirv: ^
<didrocks> Mirv: so, if all planet aligns, can you publish Mir?
<Saviq> didrocks, Mirv, I've unity-mir packages, but building unity8, too, as they need to be released together this time
<tvoss_> Saviq, happy to test, too
<Saviq> didrocks, Mirv, tvoss_ http://people.canonical.com/~msawicz/mir-maguro-blank/
<Saviq> echo "expect stop" > ~phablet/.config/upstart/unity8.conf
<Saviq> didrocks, Mirv, tvoss_, oh and yeah, that with ppa:ubuntu-unity/daily-build
<Mirv> didrocks: Saviq: so the Mir landing actually becomes Mir + unity-mir + platform-api + u-s-c + unity8 landing?
<Mirv> but yeah, preparing at least for such a beast
<Saviq> Mirv, ultimately yes, but we still have a commit missing in unity8 before that can happen
<Mirv> Saviq: ok
<Saviq> ah crap
<tvoss_> Saviq, ?
<Saviq> didrocks, Mirv, tvoss_ the above ââ not to .conf, but to .override
<Mirv> Saviq: and that unity-mir fix too
<Saviq> Mirv, right, that too
<Mirv> ok, just updated the landing plan to reflect
<Saviq> Mirv, could we publish Mir first, then land stuff in unity and unity-mir (as we're blocked on unity8 due to bug #1255578)
<ubot5> bug 1255578 in Ubuntu CI Services "dependency issues on libunity-mir1 in testrunner-otto" [Undecided,Confirmed] https://launchpad.net/bugs/1255578
<Saviq> Mirv, and then land unity8, unity-mir, unity-scopes-shell?
<Mirv> Saviq: land mir, platform-api, unity-mir, unity-system-compositor, unity8 is the current list
<Mirv> Saviq: only what is absolutely required, is unity-scopes-shell part of it too?
<Saviq> Mirv, no, not absolutely required
<Saviq> Mirv, https://code.launchpad.net/~saviq/unity8/raise-sigstop/+merge/191212 is though
<Mirv> ok, a separate landing item for that then please
<Mirv> right, marking that to the sheet too
<Saviq> Mirv, was already there
<Mirv> Saviq: so is that MP "a commit missing"?
<Saviq> Mirv, but "waiting for code"
<Saviq> Mirv, not sure what you mean?
<Mirv> Saviq: you said that unity8 is missing a commit, so is thar raise-sigstop the only commit needed still for unity8, similar to maguro fix being the only commit needed for unity-mir?
<Saviq> Mirv, yes
<Mirv> ok :)
<Mirv> and yes the scopes is there in the landing asks
<Saviq> Mirv, but we can't merge into unity8 until Mir is published, due to the above bug
<Saviq> Mirv, or well, we can force it in
<Mirv> Saviq: aha, ok, then a manual merge would be needed
<Saviq> Mirv, ok, will do once there's more people +1'd
<Mirv> yep, that's useful. bzr branch lp:unity8, bzr merge, bzr commit --author , bzr push. but yeah, only in very special cases, after enough +1:s and with landing team's approval I'd say :)
<Saviq> or well, we can add daily build to it temporarily
<Saviq> will run -ci with daily build on them, then
<Mirv> oh right that technique too
<Saviq> Mirv, hrm, any idea why that'd have failed http://s-jenkins.ubuntu-ci:8080/job/unity-mir-trusty-armhf-ci/29/console ?
<Saviq> libmirclient-dev (>= 0.1.2) but 0.1.1+14.04.20131120-0ubuntu1 is to be installed. :/
<Saviq> Mirv, ah, Mir building in daily-build?
<Saviq> seems we'll have to wait for that
<Saviq> alan_g, re: https://code.launchpad.net/~vanvugt/unity-mir/fix-1255045/+merge/197016/comments/456116
<Saviq> alan_g, http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/view/head:/src/unity-mir/dbusscreen.cpp#L45
<Saviq> wouldn't configure_output take care of pause/resume?
<Saviq> or well, display->configure(), for that matter?
<alan_g> Saviq: it just seems strange to pick out compositing
<Saviq> alan_g, sure, I agree (bear in mind, I dunno Mir enough), but since we're already configuring the display, couldn't it do pause/resume internally, if there's no screens enabled?
<alan_g> Saviq: I know the infrastructure isn't in place, but there should be a change notification for the display area covered by the screen
<alan_g> At present it is a pretty brutal "there are changes somewhere"
<Mirv> Saviq: seems not using daily-build PPA the 0.1.2 was already there
<Saviq> Mirv, yeah, it's weird, but I think it got superseded by the new build already
<Saviq> Mirv, and it's only libmirclient-dev that complained about the version, although that, by apt dep error standards, might not mean anything...
<Saviq> Mirv, will restart once the new build gets published
<Saviq> alan_g, ok understood
 * alan_g disgs through the code...
<alan_g> Saviq: OK, I suspect this is a hack around the absences of a schedule_compositing() call in compositor - and not really intended as a pause()/resume() cycle
<Saviq> alan_g, sounds right, compositor should know when display comes on and schedule then, right?
<alan_g> Saviq: well, I think it should be notified (and, in theory, told what area needs display) - unless the idea really is to pause the server
<Saviq> Mirv, grrr, dep fail again :/
<Saviq> Mirv, the hook name is definitely added http://s-jenkins.ubuntu-ci:8080/job/unity-mir-trusty-armhf-ci/30/console
<Saviq> Mirv, but indeed it doesn't seem to be executed??
 * Saviq goes to -ci-eng
<Mirv> Saviq: yeah, probably a job for CI team to check
<Saviq> alan_g, FWIW, we would actually need a frame composited before turning the display back on, as now you can see the previous frame for a split second when turning the device on
<alan_g> Saviq: ack
<alan_g> Saviq: is the code we're looking at executing after the device is turned on or before?
<Saviq> alan_g, I'd say after
<Saviq> alan_g, i.e. we get notified that the screen was turned on, not that it's going to be turned on
<Saviq> alan_g, that's something that will be better when we move the responsibility on that from powerd to unity-mir/unity8
<alan_g> Saviq: that makes it hard to composite a frame beforehand
<Saviq> alan_g, i.e. it will be told "you need to turn on now", and it will decide what to do and when to actually turn on
<Saviq> alan_g, yeah of course
<tvoss_> Saviq, do we have updated packages, yet?
<alan_g> Although, I gather there wasn't a flash and then black
<Saviq> tvoss_, still the same http://people.canonical.com/~msawicz/mir-maguro-blank/
<Saviq> tvoss_, + daily-build ppa + unity8.override
<alan_g> alf_: thoughts? https://code.launchpad.net/~vanvugt/unity-mir/fix-1255045/+merge/197016 (and ^^)
<Saviq> tvoss_, although I have a unity8 package now
<tvoss_> Saviq, okay, those work for me
 * Saviq adds
<tvoss_> Saviq, will give that package a spin, too
<Saviq> tvoss_, pushed
<Saviq> tvoss_, drop the .override for good measure
<tvoss_> Saviq, ack
<Saviq> /food
<alf_> Saviq: alan_g: the DisplayChanger class holds the logic for properly reconfiguring the display (pausing/resuming), so that's what we should expose (or a similar interface), i.e., I don't think display->configure() should pause resume internally
<alf_> Saviq: alan_g: about whether we should pause/resume or schedule_compositing() instead, it depends on how well our display classes deal with posting buffers if the display is off (right now not very well it seems)
<alf_> Saviq: alan_g: and whether it actually makes sense to disable communications and input
<alan_g> alf_: I also wonder if we should be processing input when the display is off
<alf_> alan_g: don't we need to handle some kind of input event to wake up (e.g. power button press)?
<alan_g> Hmm. but touch events going to apps?
<alf_> alan_g: Turning off communications would solve that.
<alan_g> alf_: maybe not - there was a time input bypassed the thread pool. I don't remember that changing.
<alf_> alan_g: yes, so turning off communications _properly_ would solve that :)
<alf_> alan_g: and then there is also the issue of showing previous state when we wake up (because the buffer contents are obsolete)...
<alan_g> Anyway, it does look like code around patch is a cut down version of MediatingDisplayChanger
<alan_g> Which, like you say is what we should expose
<dandrader> any reason why all shell::Surface methods are virtual whereas surfaces:Surface are not. Both are concrete classes.
<alan_g> dandrader: insanity
<dandrader> lol
<alan_g> dandrader: you're also looking at an old version
<dandrader> alan_g, hmm, true!
<dandrader> I'm playing with gerry's "qt scene graph" mir branch
<alan_g> The newer version doesn't fix all the insanity, but is a step in a right direction.
 * alan_g remembers he wants to look at that before next week
<Saviq> Mirv, tvoss_, didrocks, ok so bug #1255948 will not let us through upstream merger, OK to force land those two commits before release?
<ubot5> bug 1255948 in Ubuntu CI Services "upstream merger hooks do not propagate to downstream jobs' builder_hooks" [Undecided,New] https://launchpad.net/bugs/1255948
<didrocks> let me look, one sec
<Saviq> greyback, can we have your ACK on https://code.launchpad.net/~vanvugt/unity-mir/fix-1255045/+merge/197016 ?
<Saviq> didrocks, it's:
<Saviq> https://code.launchpad.net/~saviq/unity8/raise-sigstop/+merge/191212
<Saviq> and https://code.launchpad.net/~vanvugt/unity-mir/fix-1255045/+merge/197016
<didrocks> Saviq: if it's tested and really ready to land (with the whole Mir stuff), +1
<greyback> Saviq: looking
 * greyback confused why he doesn't get mail when a unity-mir MR is made
<Saviq> greyback, there's a lot of confusion about LP mails if you ask me...
 * Saviq installs the packages on mako and maguro, too
<Saviq> s/maguro/manta/
<Saviq> didrocks, pushed a fix to debian/control in https://code.launchpad.net/~saviq/unity8/raise-sigstop/+merge/191212
<alf_> Reading the meaningless (to most people) Android codenames, I think we should use mythical monsters for Ubuntu Touch codenames: Ubuntu Touch 2.0 Kraken, 3.0 Hydra etc :P
<Saviq> tvoss_, Mirv, I can has more +1s?
<Saviq> alf_, who would you get the billions of $$ from then?
<didrocks> Saviq: looks good for packaging change
<Saviq> alf_, like android did with KitKat? ;)
<tvoss_> Saviq, installing too
<tvoss_> hmmmm, what did I do to my nexus? Saviq, have you seen INFO:phablet-flash:Device detected as
<tvoss_> ERROR:phablet-flash:Unsupported device, autodetect fails device
<tvoss_> before?
<Saviq> tvoss_, that happens when your device isn't booted
<Saviq> tvoss_, -d <codename>
<Saviq> tvoss_, to skip autodetection
<tvoss_> Saviq, thx, works
<Saviq> tvoss_, any updates?
 * Saviq is tempted to just push the button
<tvoss_> Saviq, works here
<Saviq> ok, /me pokes the buttons
<Saviq> Mirv, ready
<Saviq> Mirv, hope it's not too late for you :/
<Saviq> Mirv, both MPs are in trunks
<Saviq> didrocks, ââ
<didrocks> \o/
<didrocks> I guess Mirv left
<didrocks> Mirv: ?
<didrocks> ok, no more Mirv I guess :)
<didrocks> Saviq: so, mir, platform-api, unity-mir, unity-system-compositor + unity8, right?
<didrocks> Saviq: do you know if the u-s-c FTBFS fix was merged?
<Saviq> didrocks, no
<Saviq> don't know
<didrocks> seems, is was
<didrocks> it*
<Saviq> didrocks, looks like it, yeah
<Saviq> https://code.launchpad.net/~unity-system-compositor-team/unity-system-compositor/trunk
<didrocks> Saviq: so, I'm adding that to robru's list
<Saviq> didrocks, thanks
<didrocks> Saviq: any particular thing to look at in unity8 trunk?
<Saviq> didrocks, that it starts ;)
<didrocks> well, that's a given :p
<Saviq> didrocks, other than that there's a lot happened... 3 weeks no release almost
<didrocks> ok
<alan_g> alf_: are you fixing the the merge conflicts? https://code.launchpad.net/~afrantzis/mir/mir-client-ensure-global-symbol-resolution/+merge/196110
<alf_> alan_g: I think I will wait for lp:~afrantzis/mir/build-options-for-tests to be merged, so I can follow the same scheme for special linkage tests build options
<alf_> alan_g: do you want me to mark as WIP?
<alan_g> alf_: fair enough
<alan_g> alf_: No. Nobody's around anyway
<alf_> alan_g: ok
#ubuntu-mir 2013-11-29
<alf_> alan_g: Have you been able to reproduce a GBMDisplayTest.drm_device_change_event_triggers_handler failure locally?
<alan_g> alf_: not tried very hard (yet)
<alf_> alan_g: ok, I am looking into it, and the best I could to is cause it to "mir_unit_tests: src/uevent_sender.c:213: uevent_sender_send: Assertion `subsystem != ((void *)0)' failed"
<alf_> alan_g: actually, with gtest_repeat I get that assertion failure fairly consistently
<alan_g> alf_: I assume my changes have no effect on that?
<alf_> alan_g: No, I don't think so, it also happens in the CI for ~afrantzis/mir/lgpl-gbm-android.
<alan_g> OK. Do you want help? Or can I leave you to investigate for now?
<alf_> alan_g: I am OK for now, I will let you know if I hit a dead-end, thanks
<alf_> alan_g: ok, found the issue with the test and I am experimenting with a solution
<alf_> (well tentative solution)
<alan_g> alf_: well done
<alan_g> Guesses it was a race condition
<alf_> alan_g: well done to you too :)
<alf_> alan_g: https://code.launchpad.net/~afrantzis/mir/fix-gbm-udev-events-test/+merge/197182
<alan_g> alf_: ta
<pete-woods1> tvoss_: good afternoon / ping !
<tvoss_> pete-woods, hello :)
<alan_g> alf_: looking at greyback's hacks for qt composition reminds me that the lack of information about what changed when calling the notify_change is something we need to address. (In this case he's created a second callback so that he knows which surface has posted a buffer)
<greyback> alan_g: yep, I did that :)
 * alan_g thinks that a surface pointer in the notification would be useful for other use cases too
<alf_> alan_g: greyback: sure
<greyback> alan_g: alf_ these are misc notes I took in my work: https://docs.google.com/a/canonical.com/document/d/12aVPbX5qzr2GqF8yBcc17ZWsD9Z1kQfoSaYi2yMm1rE/edit
<greyback> They're rough, but I'd say they're of interest
<alf_> greyback: very useful, thanks
<alan_g> I'd also like to factor in the display on notification we were discussing re the GNexus problems
<alan_g> greyback: useful notes. I think there are some alternative solutions but knowing the problems is good.
<alf_> greyback: @generic way to call eglGetProcAddress(), can you please elaborate, it's not clear what's blocking us from using  eglGetProcAddress()
<greyback> alan_g: oh of course, I just hacked in what I needed
<greyback> alf_: I suppose nothing stops me calling eglGetProcAddress. Just didn't know if Mir should wrap it or not. Probably not..
<alan_g> sure, experimenting is how we learn the right approach
<dandrader> should libmirserver and libmirclient be mutually exclusive (ie. a binary shouldn't link to both) or they're complementary?
<alan_g> dandrader: the nested server uses both
<dandrader> alan_g, ok
<dandrader> alan_g, because I was looking at the android-input symbols exported by then. mirserver needs "android::InputChannel::openInputFdPair(int&, int&)" but mirclient is the one providing it
<alan_g> alf_: I can think of several changes to notify: buffer_posted_on_surface, surface_created/translated/resized/raised, output_off/on/resize/translated
<dandrader> not saying it's right or wrong. just noticed it
<alan_g> Does this suggest a listener interface interface?
<alan_g> dandrader: It could be wrong, but the server does use the client library
<dandrader> alan_g, theoretically I suppose mir libs shouldn't let any android symbol out. but in practice it's very useful for the qt-scene-graph-as-compositor prototype work :)
<alan_g> dandrader: I think we need to police our exports. But there's too much in movement ATM
<dandrader> alan_g, agreed
<alan_g> dandrader: I've also been saying that we should rename the "android" namespace in  the input stack fork
<dandrader> I suppose RAOFs refactoring work of android-input will effectively pull that code out of 3rd_party and reshape them to fit mir's style and naming. ie. make mir absorb android-input
<alf_> alan_g: The listener would make sense to have in our new model
<alf_> alan_g: I am not sure about whether output_off/on/resize/translated belongs in the same listener. Depends on what the model contains etc
<alf_> alan_g: or whether we provide some kind of facade
<alan_g> alf_: I think that outputs *should* be part of the model
<alan_g> But they're not yet. (Nor is some of the input model - which I've yet to get my head around)
<alan_g> alf_: I was thinking of changing out existing functor to an interface and then adding events over time.
<alf_> alan_g: sounds good
<alf_> alan_g: and +1 for a comprehensive model
#ubuntu-mir 2013-11-30
<nongio> hi there, i'm trying to run mir on a vmware virtual machine with ubuntu 13.10, is this guide ok? http://unity.ubuntu.com/mir/building_source_for_pc.html
<truebattleaxe> yes nongio
<truebattleaxe> follow that guide
<nongio> currently i'm getting an error when running: sudo mir_demo_server_basic
<nongio> ... Error opening DRM device
<truebattleaxe> via terminal?
<nongio> yes
<truebattleaxe> one second
<nongio> thianks
<truebattleaxe> ill be right back
#ubuntu-mir 2013-12-01
<nongio> hi, I want to try mir on a vmware virtual machine with ubuntu 13.10 is it supported? i'm using this guide http://unity.ubuntu.com/mir/building_source_for_pc.html
<nongio> hey, no one using a virtual machine for development?
<anpok> hm is anybody of you hanging around in london this day?
<nongio> hi, truebattleaxe
#ubuntu-mir 2014-11-24
<duflu> Hmm, lots of internal compilers errors these past few days on vivid
<duflu> And no sign of disk errors
<duflu> -s
<desrt> duflu: good morning
<duflu> desrt: Hello
<duflu> desrt: Happy Sunday night?
<desrt> yup!
<duflu> Made great Mir progress on Sunday myself. Prototyped an exciting approach to reducing our buffer lag dynamically
 * desrt has been playing around with bluetooth and gvariant<->kdbus serialisation this weekend
<desrt> turns out NetworkManager currently lacks a good mechanism for marking a PAN-capable paired bluetooth device in such a way as to say "i never want to connect to the internet with this"
<RAOF> Yeah, that's moderately annoying.
<desrt> it does have -a- mechanism
<desrt> you can find the Device object corresponding to the mac address in question, enumerate its connection objects and call 'Delete' on them
<desrt> and then the device will go away
<desrt> but it'll be back again once you restart networkmanager
<RAOF> That doesn't sound like a solution to âI never want that phone I paired with to appear to be an internet connection, everâ
<RAOF> :)
<duflu> RAOF: I'm still staying out of two-stage surface creation, but have a requirement request: Make surface width/height optional attributes (if not now then in future). Because in some cases they're unknown by the client who is (for example) requesting an initial state of "full screen"
<duflu> Maybe we need to allow an initial size of 0x0
<RAOF> No, I don't think we need to do that :)
<RAOF> But, indeed, clients requesting fullscreen will get full screen (shell policy allowing).
<duflu> RAOF: I've tried not having it and it's ugly and misleading to require a width and height that is never used
<RAOF> We can't guarantee that it's never used.
<RAOF> Or, rather, we *can*
<duflu> RAOF: It must never be used if you want full screen
<duflu> Or else it's just wasted buffer creation and deletion
<RAOF> Our choices are: require width/height, if the shell disallows fullscreen then terminate the app.
<RAOF> duflu: two-stage-surface-create (follow-on-branch) sends fullscreen attribute at surface creation time.
<RAOF> There's no wasted buffer creation.
<duflu> RAOF: Yeah deferring all buffer creation is easy
<duflu> RAOF: I think it's fine if you can get the dimensions from the initial state or fail creation if the shell refuses full screen
<duflu> And this is why I'm not participating in that discussion. If something is broken after it lands, I'll let you know :)
<RAOF> duflu: So far the only attribute mismatches I say will fail creation are buffer_usage and pixel_format.
<duflu> RAOF: Do we need pixel format for hardware or let GL choose?
<RAOF> Given that we can't let GL choose, yes.
<RAOF> There is literally no way of letting GL choose for us.
<RAOF> (And where people have been proposing such ways, they've been along the lines of âtell GL to use the format that we've already specified for the native windowâ)
<duflu> RAOF: Yes, I mean you can partially infer one from the other, but I guess that only gets you a subset and not a specific singular choice
<RAOF> Right.
<RAOF> And also - your surface creation completes before you do any GL calls.
<duflu> RAOF: Hmm, actually if your buffer creation is deferred then pixel format and buffer usage are also not immediately required -- just needed before the surface ever gets realized
<duflu> Oh, but you have GL wanting things
<duflu> Great
<alf> greyback: Hi! We were discussing implementing the item 'Add a polite "client close your window" request', which I think was requested by you. Could you elaborate what the use case / requirements are for it?
<greyback> alf: it's a desktop feature primarily - to implement the red X in the window decoration
<greyback> which I presume (never checked) is a message to the client to say, please close that window
<greyback> I doubt X just deletes that window on the client
<alf> greyback: ok, so this is per surface (window) not the whole app
<greyback> alf: right
<alf> greyback: (unless they coincide of course)
<greyback> alf: well that's not for Mir to enforce IMO
<greyback> if client has only 1 surface, and user closes it, it's up to the app to decide to close itself or not, no?
<greyback> "close itself" = quit the whole process
<alf> greyback: I wonder... there may be a security risk here I think... imagine a user closing an app, the (only) window disappears, but the process is still there doing its thing in the background
<greyback> alf: isn't it alsp possible to start an app which creates a mir connection, but doesn't create a surface?
<alf> greyback: then again, I am not sure how IM indicators work, do they spawn a different process when showing the contacts window when clicking on the indicator (e.g. skype)?
<greyback> unlikely
<alf> greyback: fair point
<alf> greyback: perhaps I am being overly paranoid :)
<greyback> alf: I expect shell would still have the application marked as running in the launcher, so user will be able to see it
<alf> greyback: ok, so we basically want the same semantics as an X11 close event (a request that the client is free to ignore/handle as they wish).
<greyback> alf: I think that's reasonable. You?
<alf> greyback: I think so too (in general), but since I am not closely involved with window management work, I can't say how it fits with the WM grand plan.
 * alan_g wishes for the mir-nested-on-X "platform" once more
<alan_g> alf: how are you testing MirSurfaceVisibilityEvent? I've not yet been able to reproduce your faulure
<alan_g> *failure
 * alan_g reproduces failure
<alan_g> :)
<alf> alan_g: I just found that we have an fd leak that affects most repeated runs of acceptance test. It may be involved in these failures too, so I suggest we fix this first (looking into it now).
<alan_g> alf: I won't look at this any further until I hear from you. But let me know if I can help.
<alf> alan_g: thanks
<alf> alan_g: the failure in migrate-MirSurfaceVisibilityEvent doesn't seem to be related to the fd leak
<alan_g> alf: yeah. It was related to the NullFocusSetter
<alan_g> Any progress with the fd?
<alf> alan_g: Yes, our stub implementations of ClientBuffer(Factory) didn't release the fds passed to it through the MirBufferPackage, will have a fix soon
<alan_g> nice
#ubuntu-mir 2014-11-25
<mlankhorst> heh
<mlankhorst> $ glxgears
<mlankhorst> Running synchronized to the vertical refresh.  The framerate should be
<mlankhorst> approximately the same as the monitor refresh rate.
<mlankhorst> 305 frames in 5.0 seconds = 60.848 FPS
<mlankhorst> fear!
<mlankhorst> (with Xmir -rootless only else it crashes and an additional copy, but meh)
<mlankhorst> ok at this point I could really use proper timestamps for vblanks from mir.. :/
<greyback_> any progress on landing silo9? It's been there a long time now...
<ogra_> once the packaging is fixed i suppose
<ogra_> (it blocks itself)
<greyback_> ic
<AlbertA2> greyback: yeah sorry
<AlbertA2> greyback: hit another packaging issue
<greyback_> AlbertA2: np, these things happen
<AlbertA2> greyback: just waiting on CI to merge the fix and then I'll have to rebuild in silo so it should make it today
<greyback_> cool
<ogra_> AlbertA2, can you pin me once it is done (for the seed change, i cant do the change if the packages do not exist in the archive)
<ogra_> *ping
<AlbertA2> ogra_: yeah I'll ping you
<AlbertA2> ogra_: so packaging fixes are done...we are stuck with migrating to release pocket
<AlbertA2> ogra_: because of ubuntu-touch meta package? which from what I see uses the published seeds to generate the ubuntu-touch deps...so how do we proceed from here?
#ubuntu-mir 2014-11-26
<duflu> alf__: Is glmark2 designed to finish in a fixed time or vary according to GPU power?
<alf__> duflu: fixed time (test parameter 'duration' default is 10 seconds)
<duflu> alf__: Right, so a slow machine won't take it over an hour then
<alf__> duflu: right
<duflu> Remind me not to try and fix bugs so much. Fixing the fixes takes so much time that the feature development halts :)
<alan_g> Just don't put the bugs in to start with
<duflu> alan_g: None are mine (?). I'm trying not to victimize their creators
<duflu> Mostly not mine
<alan_g> Indeed, we all review the MPs
<duflu> Oh and then some devious test reboots my phone
<duflu> alan_g: I remember you suggested making people responsible, back at the sprint. I had thought the same before. The real issue is the person desiring a fix the most is not usually the person who broke it
<alan_g> I think people should be aware of how they broke something so that they can learn. But one can't be made responsible one has to be it.
<duflu> OTOH, if someone is a repeat offender, we would be wise to throttle them with bugfix tasks instead of feature development
<duflu> But that would be mean too
<duflu> More phone testing...
<duflu> alan_g: OK I can reproduce the GLMark2Test hang. It's a visible freeze. Will need to continue tomorrow
<duflu> Visible on mako
<alan_g> duflu: that's great - I couldn't reproduce (admittedly I didn't spend very long on it)
<duflu> alan_g: I suspect we're not matching up number of buffer replies with number of requests. Both server and client are starved and idling
<alan_g> Then you've got processes to poke around in? Even better.
<alan_g> I'll be glad to see that one gone
<duflu> alan_g: Yeah. Annoyingly seems related to what I'm fixing, but more needs fixing obviously
<alan_g> duflu: hopefully that means there will be a unified fix that will be obviously correct. (Once you've thought of it.)
<duflu> alan_g: Or many
 * alan_g hopes not
<duflu> Oh it's going to be a bug fix week
<duflu> alan_g: Can you track down any more MPs that made it worse?
<duflu> Although I've got two that do it reliably
<alan_g> I've not noticed any others. But I'll keep track.
<duflu> Hmm, framedropping policy has moved into GlibMainLoop recently
<AlbertA> ogra_: the mir release is stuck in proposed: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<AlbertA> http://pastebin.ubuntu.com/9250453/
<AlbertA> ogra_: it looks like ubuntu-touch package has a dep on  libmirplatform3driver-android
<AlbertA> ogra_: and looking at the README it seems it is based on the seeds: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/ubuntu-touch-meta/vivid/view/head:/README
<AlbertA> ogra_: any ideas on how to move forward?
<ogra_> by dropping it ;)
<ogra_> its a bit awkward that we have to update the seeds for such a change ... that means new -meta packages for every ABI bump you guys do
<ogra_> would be nicer to have a higher level libmir meta package that the seed could depend on
<AlbertA> ogra_: right that's why this new mir release introduces mir-graphics-drivers-android
<ogra_> (similar to linux vs linux-image vs linux-image-$(uname -r)
<ogra_> ah, right, so lets land this then :)
<AlbertA> so do we manually modify the dep lists for ubuntu-touch and land it together with the mir release?
<AlbertA> ogra_:^
<ogra_> no
<ogra_> ubuntu-touch-meta gets generated from the seeds ;)
<AlbertA> ogra_: ok
<ogra_> i just merged your seed change ... takes a bit to generate the package
<ogra_> i'll upload asap
<AlbertA> ogra_: ok thanks!
<alan_g> alf__: I'm looking at MirScreencastTest and thinking that the tests that depend on the mock_screencast are really integration tests. (And that the remaining tests don't really prove the feature.) Do you concur?
<alf__> alan_g: looking
<alf__> alan_g: I mostly agree. This (like other tests) would like to be true end-to-end tests, but unfortunately that's not possible with our current CI infrastructure.
<alan_g> yes
<alf__> alan_g: Also what is an acceptance vs integration tests in our current architectur is somewhat fuzzy. The "hexagonal architecture" definition of acceptance vs integration is the clearest I have encountered.
 * alan_g goes to google
<alf__> (hexagonal == ports and adapters)
<alan_g> From a quick skim this looks like what I intended to describe at the initiation sprint
<alf__> alan_g: Makes sense. It's also what the example in the GOOS book finally organically ends up with. Here are some nice diagrams from one of the authors: http://www.natpryce.com/articles/000772.html
<alan_g> yep
<alf__> alan_g: I like that acceptance tests (tests again the domain model) are different from end-to-end (system) tests.
<alan_g> Sure. And it does fit with our classification. (What system tests we have are in benchmarks or examples and are not very good at reporting pass/fail)
<alan_g> Anyway, for the current instance, you're happy if I shuffle most of the tests over to integration tests?
<alf__> alan_g: Sure. If we can easily change some of them to remain in the acceptance tests (and it makes sense to do so), then I would prefer that of course.
<alan_g> I'm taking reliance on mock_screencast (as opposed to having it around by accident) as the discriminator.
<alf__> alan_g: Moving them will create some acceptance test gaps (e.g. for the mir_screencast api), but let's fix them properly.
<alan_g> It just makes the gap more visible
<alf__> alan_g: The MirScreencast test in particular could be probably made to work as acceptance test, if we use our MockGL/EGL infrastructure, which makes sense since EGL/GL is our integration point. We don't have an interface for GL/GLES but we can just use the link-time seam as usual.
<alf__> alan_g: ... or introduce an interface for it
<alan_g> Yes, but I don't want to take that on right now
<alf__> alan_g: Understood.
<AlbertA> greyback_: mir has released, so no lock on qtmir anymore :)
<greyback_> AlbertA: yay, thanks
 * DalekSec waves to olli_.
<olli_> camako, DalekSec is representing xubuntu and was helping to gather some xmir compatibility test results back in the day
<olli_> camako, he had a question if http://unit193.net/wiki/doku.php?id=wiki:mir is still of help
<camako> olli_, first time I'm seeing it... It could be useful if it were up to date.
#ubuntu-mir 2014-11-27
<anpok_> duflu: the thought was... we are passing a triplet of cursor_usage,w,h and it decided to ignore two parts of it to fullfill the first.. what if behaves the other way around or just fails..
<duflu> anpok_: I don't follow. But if you really do need the drmGetCap then ignore my comment
<duflu> It's just a matter of the fix is too big, not faulty
<anpok_> duflu: hmm my point is.. i am not sure..
<anpok_> the fix for radeon does not need it..
<duflu> anpok_: Well ignore Tegra. That's historically so slow (every revision) that we want to avoid caring about it
<duflu> Why has Tegra been so consistently bad??
<duflu> Or the devices that contain them
<duflu> RAOF: OK I'm now detecting the safety of frame dropping. If unsafe should we not drop (render with vsync) or throw a fatal exception
<duflu> ?
<duflu> I can't decide. So many evil choices
<RAOF> duflu: When is framedropping unsafe?
<duflu> RAOF: When there aren't enough :)
<duflu> buffers
<RAOF> I thought you were dynamically allocating said buffers?
<duflu> RAOF: Not now. Choosing a different evil. I think overallocating creates an imbalance in the protocol request/reply for buffers and starvation/deadloack can happen
<RAOF> Throwing a fatal exception is certainly the wrong answer, though. Clients should not be able to crash the server.
<duflu> ... that deadlock is the GLMark2Test hang
<RAOF> Hm. That seems like odd behaviour. Why do you think it causes a deadlock?
<duflu> You can reallocate, but only at limited safe points in the lifecycle, which are not the same points we want to drop at
<duflu> RAOF: Because glmark2 freezes and both client and server are left idle waiting for each other
<duflu> Same theme as other bugs I'm fixing
<RAOF> Huh, I'm surprised.
<duflu> Me too, but happy to not have an unbounded buffer queue too
<RAOF> Eh.
<RAOF> As a practical matter we kinda need one.
<RAOF> Or, rather, we need at least one per monitor plus one for the client
<duflu> RAOF: Actually it's not entirely linear. Not simple, but if all monitors have the same frame rate then max two compositor buffers.
<duflu> Or max three with bypass multimonitors
<duflu> Or more with very slow refreshing monitors
<duflu> But fortunately not linear with number of monitors
<duflu> I'm really trying to avoid being asked to rewrite BufferQueue at the same time as the bug fxies
<duflu> fixes
<duflu> RAOF: To answer your earlier question; dropping frames in the wrong place results in us trying to send more exchange_buffer replies than we got requests, so that's an issue
<duflu> Oh very weird. I'm seeing two compositor buffers held simultaneously on Android
<duflu> is that overlays?
<duflu> alf: Why is the jellyfish (glmark2) so much smoother on a phone than desktop?
<duflu> alf__, ^
<alf__> duflu: it's smooth on my desktop :)
<duflu> alf__: I mean the vertices
<duflu> I've never found a desktop where it was smooth
<duflu> But on mako I can see what it's meant to look like
<alf__> duflu: Not sure what you mean... are you referring to e.g. the tentacles parts appearing to form corners?
<duflu> alf__: Yeah but the body particularly
<duflu> Like there's much higher mesh detail on the phone than desktop
<alf__> duflu: I don't know...
<alan_g> "drop-dead-internals" has landed \o/
<duflu> Woo
<duflu> Now to fix those freezes
<duflu> To add to the mix, it seems our Android code becomes very unstable with frame dropping.
<duflu> That's part of the problem
<duflu> Fortunate that Unity does not use it yet
<duflu> or much
<anpok_> alf__: main loop again.. i need it in two places of the input plaform interfaces..
<anpok_> but  I dont need start/stop only its base interfaces
<anpok_> waking on fd, action queue and timer
<alf__> anpok_: do you mean the_main_loop() or do you need two new instances of e.g. GLibMainLoop?
<anpok_> all three..
<anpok_> no the interface MainLoop
<anpok_> the various input platforms that we will need will either trigger events through the action queue, based on fd activity..
<anpok_> but the decision which of those two is used in that case, depends on the platform
<anpok_> but I doubt they will ever need run/stop
<anpok_> or even worse, wouldnt even like them to use it..
<anpok_> usage of Timer is an implementation detail i would simplify by reusing it..
<alf__> anpok_: So you want to give them an interface through which to add events or register fd actions. Who is going to own the main loop?
<anpok_> the input device hub in mirserver will own the input thread which drives that main loop instance (i try to avoid the term "the main loop")
<alf__> anpok_: one option is to create a new interface in the input namespace that offers exactly what you need, and just implemented with a GLibMainLoop
<anpok_> I am close to not moving MainLoop over to platform and instead provide a separate interface
<anpok_> oh yes what you said
<anpok_> the other option is to reiterate the interface discussion with the idea that what the aggregation 'MainLoop' currently provides is a set of general purpose interfaces that need fixing
<anpok_> i kind of feel the urge to take the first door,,
<alan_g> It is better to adapt the interface hierarchy to current need than to speculate on future needs
<alf__> anpok_: the MainLoop *is* an aggregation of general purporse interfaces (graphics::EventHandlerRegister, time::Timer, ServerActionQueue)
<alf__> anpok_: but I think input owning the interface is best
<anpok_> graphigs::EventHandlerRegister is a too specific name and namespace imo
<anpok_> s/g/c
<anpok_> alan_g: you mean the speculation which parts of MainLoop will be required
<alan_g> It sounds like the new requirement is EventHandlerRegister+ServerActionQueue - but that the names are too specific
<duflu> alan_g: That glmark2 freeze is more subtle than expected. Looks like our Android-specific code is at fault. But my new proposal today at least does not trigger it
<anpok_> alan_g: yes thats the next immediate requirement..
<alan_g> duflu: as in "workaround" or as in "no worse than current"?
<duflu> alan_g: No worse. The bug remains but I'm not working around it. Just not making it worse
<duflu> Have two separate branches that will trigger it for future testing
<duflu> Also, according to the date on the bug, you logged it before my branches existed :)
<alan_g> thanks for the update. You happy to continue with it or need me to take a look?
<duflu> alan_g: I'll provide instructions in the bugs but will decide if I'm still concerned about them myself tomorrow
<duflu> *bug
<alf__> duflu: I recall that you didn't like the name mir_connection_platform_operation(...). Any suggestions? mir_connection_call_platform(), mir_connection_perform_platform_operation() ... ?
<duflu> alf__: Yeah doesn't look nice but I can't think of a solution right now
<alan_g> OK. (I have my own "how does my code break that in CI?" issue to look into.)
<duflu> I *expect* CI to pass. My phone certainly likes the new branch
<alf__> alan_g: anpok: ^^ four lines up
 * alan_g tries to imagine the context calling it...
<anpok_> alf__: where is that needed again?
<alf__> anpok_: to replace platform specific calls e.g. mir_connection_drm_auth_magic(). Such functions are currently used by the EGL layer (e.g. in mesa) and also in the nested platform.
<anpok_> ahh yes
<anpok_> and really  ...?
<alan_g> mir_connection_magic()
<mlankhorst> hm.. :p
<mlankhorst> 23782 frames in 5.0 seconds = 4756.278 FPS
<mlankhorst> should be better if I implement flip completion
<mlankhorst> oh there we go
<mlankhorst> uploaded xorg-server_1.16.1.901-1ubuntu2+sa2 to my ppa, enjoy breaking things :P
<anpok_> mlankhorst: whats inside xorg? on mir?
<mlankhorst> standalone XMir, eg not using the xorg binary
<mlankhorst> lack of cursor support is annoying
<alf__> alan_g: What's the UMR fix?
<alf__> alan_g: ahh, Uninitialized Memory...
<anpok_> alan_g: hm ogra today said that the alternative selection thing want upgraded after the last mir release
<anpok_> *wasnt
<ogra_> yeah, and mir still pulls in mesa
<anpok_> this would explain
<ogra_> which makes it use mesa libs by default
<anpok_> libmirplatform4driver-android is already the newest version.
<anpok_> oops
<anpok_> https://bugs.launchpad.net/mir/+bug/1396978
<ubot5> Launchpad bug 1396978 in Mir "[testsfail] GLMark2Test fails to run in CI" [Undecided,New]
<alan_g> ogra_: you know what's going on then? ^^
 * alan_g hopes it is someone else's problem
<ogra_> alan_g, as i said, mir install libmirplatform4driver-mesa
<alan_g> But why has that started happening today and how do we fix it?
<ogra_> because today the new mir landed in the vivid image
<ogra_> we have a hack in the build scripts that forces the driver alternative to -adnroid even if -mesa is installed ... i just made sure that always gets applied, image #35 should behave better again
<ogra_> (indeed that wont solve the issue that we install mesa where we shouldnt)
<alan_g> so the mako image is broken because mesa is installed?
<ogra_> right, it has both, -mesa and -adnroid installed
<ogra_> the driver alternative defaults to mesa in such a case
<alan_g> I'm still not sure what the right way to fix is. (Hacking around the problem in the CI build isn't it though.)
<ogra_> just wait for the next image, it will have the forced alternative
<ogra_> (i assume CI devices just use the latest image)
<ogra_> long term it would be nice if we wouldnt end up with libmirplatform4driver-mesa on phones though :)
<alan_g> CI image updates are unpredictable (we've evidently got a mix currently)
<alan_g> I agree about not having libmirplatform4driver-mesa on phone - but the packaging stuff is magic where I don't understand how it should work well enough to fix it
 * alan_g just knows it is broken
<AlbertA> ogra_: so the new meta packages didn't help?
<ogra_> AlbertA, well, not sure what pulls in -mesa ... it might not be mir but some other package with a dep that -mesa fulfills for it
<ogra_> this needs deeper research (whcih i currently cant do)
<mlankhorst> bah, when looking for failures to fix on things related to dri2, make sure they pass on normal x first :/
<gcollura> do I need to use opensource driver in order to test unity8 on utopic?
<gcollura> I'm on amd btw
<attente_> RAOF: hi, is there a way to specify the position of a transient window/surface in the mir client api? or set the position of a surface in general?
<greyback> attente_: the plan is to be able to specify the position of a child window relative to its parent window
<greyback> is being worked on currently
<attente_> greyback: thanks, is there a timeline for the feature?
<greyback> attente_: January most likely
<greyback> it's something I want too
<desrt> greyback: can you tell attente_ a bit about the difference between the in-mir-process qt support and the normal-client qt support?
<desrt> i know there are two things here but i forgot which is which
<greyback> desrt: sure
<greyback> Qt has a platform abstraction layer, to allow it be cross platform. Each platform has a plugin (QPA plugin).
<greyback> so on linux we mainly use the xcb QPA
<greyback> for Mir clients, we've an "ubuntumirclient" QPA plugin
<greyback> for a mir server, we also made a QPA plugin "mirserver" which is what unity8 uses.
<greyback> this plugin instantiates a Mir server, pretends that a Mir "Display" is a Qt QWindow, and connects up Mir's input handling with Qt's
<greyback> so your Qt app, using this mirserver plugin, is in fact a mir server
<greyback> if you use QML, anything you draw is drawn directly to the display's framebuffer
<greyback> any mouse/key input goes straight to Qt
<greyback> the final part to make Qt a useful mir server, is to allow it to integrate client surfaces into the QML scene, and send input events to those clients. For that we've a QML module
<greyback> this is all implemented in lp:qtmir
<attente_> sorry if i misunderstood, but the Qt app is a mir server? not a mir client?
<greyback> attente_: unity8 is a special qt app which is a mir server.
<greyback> all other apps on ubuntu touch are Qt apps which are mir clients
<attente_> greyback: oh, ok
#ubuntu-mir 2014-11-28
<mlankhorst> mir doesn't expose the concept of crtc right/
<alf__> mlankhorst: right, you tell it how you want to configure your displays in the virtual view space and it sets up things internally
<mlankhorst> yeah was looking at implementing dpms :P
<mlankhorst> after that I should be close in features to xorg-mir, except i only support what mir supports, which isn't much..
<mlankhorst> and it feels like input lags, but it looks more like acceleration is not implemented :p
<alf__> mlankhorst: what kind of acceleration?
<alf__> mlankhorst: you mean graphics acceleration in general?
<mlankhorst> pointer acceleration
<duflu> mlankhorst: Mir has hardware cursors, but disabled for X (until X uses Mir's input)
<duflu> mlankhorst: Also, the lag I'm working on. But only in spare time right now
<duflu> There's a lot of gain to be made yet
<duflu> We have three levels of triple buffers (= 3 * 2 frames lag)
<duflu> (in a nested server case)
<duflu> That will be fixed
<duflu> mlankhorst: https://bugs.launchpad.net/xmir/+bug/1216468, https://bugs.launchpad.net/unity-system-compositor/+bug/1204505
<ubot5> Launchpad bug 1216468 in XMir "Mouse pointer lags behind slightly (still using software cursor instead of hardware)" [High,Triaged]
<ubot5> Launchpad bug 1204505 in XMir "[enhancement] unity-system-compositor needs to have hw pointer functionality enabled back" [Medium,Triaged]
<mlankhorst> duflu: yeah :P
<duflu> mir_surface_set_state(duflu, cooking)
<mlankhorst> I was testing with mir_demo_server_basic though..
<duflu> mlankhorst: That will have the HW cursor
<duflu> mlankhorst: But yeah I know other things lag further behind the cursor.
<duflu> These are known issues I'm keep to fix
<duflu> *keen
<duflu> mlankhorst: Also, demo_server_shell is more useful
<duflu> I think we can kill basic now. Not sure
<duflu> OK, I'm going to run now
<mlankhorst> and dpms working :p
<alf__> mlankhorst: I think you (?) mentioned at one point that we shouldn't dup a drm fd. Do you know if it's OK to dup() it, close the old fd and only use the new one?
<mlankhorst> as long as you only use 1 copy it's fine
<alf__> mlankhorst: thanks
<DalekSec> camako: Right, we haven't really done much with it since 13.10, just some mild testing every so often.
#ubuntu-mir 2015-11-23
<alan_g> alf_: anpok_ with krillin CI problems again I'm strongly inclined to land some "easy stuff" by hand. Starting with lp:~afrantzis/mir/fix-1517990 - any objections?
<alf_> alan_g: no
<anpok_> sure!
<alan_g> In that case, I'm accepting suggestions
<ahayzen> Hey guys, I've just reported bug 1518935, but I'm not sure which part of the platform is causing it, I think it is possibly QtMir but wanted to ask you guys before I add the project as affected?
<ubot5> bug 1518935 in Canonical System Image "When an application is suspended or closed it causes a large UI stutter" [Undecided,New] https://launchpad.net/bugs/1518935
<greyback_> ahayzen: hard to know for sure, someone would need to investigate. I suggest unity8 at the very least
<ahayzen> greyback_, ok thanks :-)
<dandrader> alan_g, any reason why size hints (min and max size, size increment value) are not properties of mir::scene::surface?
<alan_g> dandrader: because they are specific to window management
<dandrader> alan_g, I'm doing a lot of gymnastics to get that info from mir::shell::WindowManager methods to our MirSurface object in Unity.Application
<alan_g> dandrader: that's because the window management work for qtmir hasn't been done yet
<alan_g> greyback_ and I are due to start it on Wednesday
<dandrader> alan_g, window management is done in unity8. qtmir just proviedes that info to it
<alan_g> OK, I'm using "window management" as shorthand for that work
<dandrader> alan_g, right now I'm working on making unity8 obey those size hints
<dandrader> alan_g, in QML
<dandrader> alan_g, and qtmir is the guy that exposes mir stuff into QML to untiy8 can use it
<dandrader> alan_g, because it's just so much better to write those kinds of things in QML than in C++
<alan_g> dandrader: agreed. And that piece of qtmir work has been postponed over months. So greyback_ and I are getting together to do it this week.
<greyback_> dandrader: ordinarily I'd agree, but we've a mandate to implement policy like this in mir
<greyback_> dandrader: I do want this info exposed to qml though
<dandrader> greyback_, alan_g I have the unity8 part ready here: https://code.launchpad.net/~dandrader/unity8/sizeHints
<alan_g> IMO mir::scene::Surface already has a bunch of info on it that doesn't belong there.
<greyback_> dandrader: the plan is to move the JS code you added in WindowResizeArea.qml to mir itself
#ubuntu-mir 2015-11-24
<alan_g> alf_: are you getting somewhere with CI failure?
<alf_> alan_g: I have a few things I want to try (experimental MPs), but got blocked by the Display.* failures
<alf_> alan_g: I am close to an MP for the new failures, so I should have some results soon.
<alan_g> alf_: cool, thanks.
<slvn_> hello !
<slvn_> I have some issue to debug maybe someone can help :
<slvn_> I have an app on ubuntu-phone that tries to go fullscreen, but the top status bar is always there.
<slvn_> if I use "mir_surface_spec_set_state( fullscreen )" before creating the surface, it works.
<slvn_> but I try to use it after creating the surface,  using "apply_spec" it does not work ...
<slvn_> there is no error message .. the request just seem to be discarded ... any idea ?
<alan_g> slvn_: I suspect that surface modification requests are not supported by unity8/qtmir yet.
<alan_g> I know that greyback_ and I are planning to do some work on the qtmir aspects starting tomorrow
<slvn_> well ... maybe this is the good reason ...
<greyback_> slvn_: unfortunately yes, that's not working yet on the unity8 side
<slvn_> I have also tried to call the function "mir_wait_for( mir_surface_set_state(fullscreen) )" after the surface_create, and this one was working.
<slvn_> does this make sense ?
<greyback_> slvn_: not really, but I think you've hit a code-path we've not tried yet. Would you log a bug please?
<greyback_> slvn_: please log against the project "qtmir"
<mcphail> slvn_: can you post the bug number here so I can follow it? Keen to see this improved
<slvn_> hmm ... I dont really know what to log, because to me, the mir_wait_for(..)  is expected to be working ! I saw this code in lp:qtubuntu when doing SetfullScreen
<alan_g> slvn_: it makes sense in that there are some (essentially legacy) functions that are supported, but the apply_spec is the (not working yet) future.
<alan_g> Unfortunately the qtmir/u8 support for "apply_spec" got delayed as there were more urgent priorities.
<slvn_> ok, I got it ! just get confused because there was no error, and wasn't working
<slvn_> you want me to fill a bug report for which part ?
<slvn_> since, I have an explanation I am fine :)
<alan_g> "apply_spec" not supported by qtmir/u8
<slvn_> ok !
<mzanetti> anpok, ping
<slvn_>  https://bugs.launchpad.net/qtmir/+bug/1519338
<ubot5> Ubuntu bug 1519338 in QtMir "API "mir_surface_apply_spec" is not supported in qtmir/u8 " [Undecided,New]
<mcphail> greyback_: aww - give it a "High" priority - medium bugs are never fixed :p
<greyback_> mcphail: it'll be fixed :) Especially as we'll definitely be moving to the newer way (apply_spec)
<mcphail> greyback_: cheers :)
<anpok> mzanetti: pong?
<mzanetti> hey anpok
<mzanetti> anpok, https://code.launchpad.net/~mzanetti/unity8/uinput/+merge/277572/comments/704818
#ubuntu-mir 2015-11-25
<slvn_> Hello !
<slvn_> a mir question ...
<slvn_> what is the first OTA-# version that has  ""libmirclient.so.9" ?
<anpok_> afaik libmirclient.9 was in mir 0.14.. but cannot remember which OTA number that would relate to
<slvn_> I explain ... I use SDL2 lib, which will pick this share library, and would like to make sure that it exists ...
<alan_g> anpok_: correct. But I don't remember either.
<alan_g> alf_: are you not merging lp:~afrantzis/mir/android-gralloc-can-be-safely-closed-quirk for a reason? As an added test?
<alf_> alan_g: Yes, I wanted it to use the normal process to merge (should be done any moment now)
<alan_g> alf_: OK, I was just about to push an MP and thought it would be nice if it had a chance to pass.
<alf_> alan_g: Hmm, it seems the wily jobs for autolanding are delaying the landing, should be doon in the next half-hour I suppose. If you can wait a bit more...
<alan_g> alf_: yeah, I'll wait. Most of my existing MPs are lacking reviewers anyway.
#ubuntu-mir 2015-11-27
<peter-bittner> I'm interested in the state of "restoring windows when attaching / detaching external monitors". Is the work on this topic progressing, or is there some (easy) help needed from the community, maybe?
<peter-bittner> I've asked a question about that on  the ubuntu-phone mailing list, https://lists.launchpad.net/ubuntu-phone/msg16985.html
<alan_g> alf__: which was the disp-conf bug we discussed yesterday?
<peter-bittner> Sorry to disturb you: I'm interested in the state of "restoring windows when attaching / detaching external monitors". Is the work on this topic progressing somehow?
<alf__> alan_g: https://bugs.launchpad.net/mir/+bug/1518317
<ubot5> Ubuntu bug 1518317 in Mir "Client display configuration is not unapplied when the client doesn't explicitly release its surfaces before disconnecting" [High,Confirmed]
<alan_g> peter-bittner: that sounds as though it cross-cuts Mir, Qtmir and Unity8. There's some work in Mir that will likely be landing in 0.18 and Gerry and I started on some Qtmir work that impacts it this week. Don't know about U8 though.
<alan_g> alf__: thanks
<alf__> alan_g: just in case you didn't see it, there is a comment in https://bugs.launchpad.net/mir/+bug/1518317 with some thoughts and a link to my WIP branch
<ubot5> Ubuntu bug 1518317 in Mir "Client display configuration is not unapplied when the client doesn't explicitly release its surfaces before disconnecting" [High,Confirmed]
<alan_g> alf__: thanks, was just about to look (was still in qtmir-land)
<peter-bittner> alan_g: What is "landing in 0.18" in terms of OTA or Ubuntu release date (for desktop computers)? Sorry for my ignorance.
<peter-bittner> And does fixing that issue translate into "application windows (positions, dimensions) will be restored when attaching / detaching external monitors automatically"?
<peter-bittner> This is the problem I intend to be solved: http://askubuntu.com/questions/561197/is-there-a-way-to-prevent-your-windows-from-moving-when-an-external-monitor-is-c/561824#comment1031840_561824
<peter-bittner> Are we on the same page?
<peter-bittner> I've also asked a question about that on  the ubuntu-phone mailing list, https://lists.launchpad.net/ubuntu-phone/msg16985.html
<ahayzen> greyback, thanks for commenting on that music-app power consumption bug :-)
<greyback> ahayzen: it just emphasizes that lifecycle exemption is not a good solution for background processes
<ahayzen> yup :-) greyback hopefully we can remove our exception in the short-medium term, as the bgplaylists is getting close now, we'll then just need one extra thing from media-hub :-)
<greyback> *nod*
<greyback> but more generally, we need something better
<ahayzen> i think trusted services are the best solution... we just need more services/expand them
<greyback> I think we need ability to occasionally wake up the app to ask it "the list is about to run out, do you want more stuff added to the list, or can I stop"
<alan_g> alf__: (if you're still around) I resubmitted ~alan-griffiths/mir/fix-1518317/ after rebasing on anpok's conflicting (and simplifying) MP. Maybe you can re-approve?
<alf__> alan_g: done
<alan_g> ta
#ubuntu-mir 2016-11-28
<attente> https://www.irccloud.com/pastebin/XrJE3Xpc/
<attente> alan_g: hey, are you getting those errors when building miral-shell? ^
<alan_g> attente: no. Compiler? Platform?
<attente> alan_g: gcc via ccache
<attente> on zesty
<attente> gcc 4:6.2.1-1ubuntu1, ccache 3.3.3-1
 * greyback also got that today
 * alan_g hasn't got zesty to hand
<attente> greyback, alan_g: adding an extra comma there fixes it
<greyback> attente: alan_g: ack I'll look after it
<attente> greyback: thanks
<alan_g> thanks
<alan_g> greyback: that's down to a gtest change?
<greyback> attente: where did you add a comma? To designate an extra macro argument?
<attente> greyback: yeah: )); -> ),);
<attente> greyback: in all three places the error occurred
<greyback> attente: bah, I thought I had tried that and compiler rejected it
<attente> https://www.irccloud.com/pastebin/LyZvkGRM/
<attente> oh. really?
 * attente shakes fist at googletest
<greyback> alan_g: well, this is the patch. I'm unclear what's really changed: http://bazaar.launchpad.net/~gerboland/miral/gtest-bug-workaround/revision/457
<ubot5`> Ubuntu bug 457 in k3b (Ubuntu) "k3b doesn't have any dependencies on cdrdao" [Medium,Invalid]
<greyback> ooh ubot got that wrong
<alan_g> greyback: for earlier versions of googletest (vivid, xenial, yakkety) that will break. "error: macro "INSTANTIATE_TEST_CASE_P" passed 4 arguments, but takes just 3),);
<greyback> alan_g: yeah I guessed that
<greyback> but I'm still unclear what really changed
<greyback> qtmir uses that macro in one test, and it compiles.
<alan_g> greyback: could you paste the definition of INSTANTIATE_TEST_CASE_P?
<alan_g> I see: # define INSTANTIATE_TEST_CASE_P(prefix, test_case_name, generator) \ etc
<greyback> alan_g: yep it has changed since: http://pastebin.ubuntu.com/23549170/
<alan_g> /sigh
<alan_g> Why do they do these things? AFAICS qtmir doesn't use "-pedantic" which would be the difference
<alan_g> greyback: you still working on fix? or shall I take over?
<greyback> alan_g: I'm still investigating
<greyback> just comparing qtmir testcase with miral: http://pastebin.ubuntu.com/23549194/
<greyback> difference is not obvious to me yet
<greyback> no obviously different compiler flag
<alan_g> I didn't see -pedantic in qtmir
<greyback> ah
<greyback> I didn't think pedantic was reported with -Werror
<greyback> ok, that must be it
<greyback> alan_g: wdyt? http://pastebin.ubuntu.com/23549271/
<greyback> I can't see any way to get the googletest version, to gate it on 1.8
<alan_g> I'd prefer not to rely on a gcc extension: https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Variadic-Macros.html
<alan_g> And I remember the  GTest .cmake doesn't set the standard properties
<alan_g> greyback: I'll sleep on it.
<greyback> alan_g: ack
<greyback> have a nice evening
 * greyback not sure what is least worst fix 
#ubuntu-mir 2016-11-29
<alan_g> greyback: does this work on zesty? https://code.launchpad.net/~alan-griffiths/miral/fix-for-zesty-gtest/+merge/312018
<greyback> let me try
<duflu> alan_g, greyback: You might want to link that to bug 1644062
<ubot5`> bug 1644062 in content-hub (Ubuntu) "googletest 1.8.0-2 (on zesty) breaks existing builds [add_library cannot create target "gmock" ...]" [Critical,In progress] https://launchpad.net/bugs/1644062
<alan_g> duflu: that looks like a different issue with the gtest changes
<duflu> alan_g: It's the same thing. RAOF made the same fix as yours in his branch
<duflu> Although the bug title would make you think not
<alan_g> and the bug description. (And yes, I stole his approach)
<greyback> alan_g: no luck: http://pastebin.ubuntu.com/23552386/
<duflu> And I spent most of a day fixing that one and others related to gtest 1.8 last week
<alan_g> greyback: can you check if HAS_W_GNU_ZERO_VARIADIC_MACRO_ARGUMENTS is getting set?
<greyback> alan_g: it's not getting set
<alan_g> greyback: ack. I wonder why
<greyback> I'll have a look
<duflu> Does anyone apart from Xmir use mir_buffer_stream_swap_buffers (i.e. asynchronous swap callbacks)?
<anpok_> duflu: i was tinkering with it in gtk
<anpok_> in conjunction with the gdk frame clock
<anpok_> but iirc that part has not landed yet
<duflu> Ha. mir::client::FrameClock is the name of the class I'm working on
<anpok_> .. yes it has not
<anpok_> first I or someone else has to clean up the resize handling
<duflu> Just wondering... if I introduce a new feature for swap_buffers_sync only initially will most users benefit?
<duflu> The async case requires threads and mess. I'd rather separate it
<duflu> Possibly an event loop instead
<duflu> Hurray, EGL uses a different code path, unnecessarily?
<alan_g> greyback: sorry, that seems to be a clang flag
<greyback> ok
<alan_g> greyback: pushed a version that works with g++
<alan_g> I hope
<greyback> ack
<greyback> alan_g: I believe you have a NOT missing in your logic. You check if "-Wno-something" is set, and if it is, append -Wno-something.
<alan_g> I think I check if  "-Wno-something" is supported by the compiler and, if it is, set it. I guess it doesn't work?
<alan_g> Got a meeting, back soon
<greyback> nope, sorry
<greyback> http://pastebin.ubuntu.com/23552532/ - the clang cmd line option is added
<alan_g> /sigh check_cxx_compiler_flag() isn't as magic as I thought.
<alan_g> greyback: I think I've got it
<greyback> alan_g: well that fixes gcc!
<greyback> zesty clang now found another error
<greyback> http://pastebin.ubuntu.com/23552717/
 * alan_g mutters about users
<greyback> http://pastebin.ubuntu.com/23552731/ fixes that issue (and a class/struct complaint) for clang
<alan_g> Feel free to propose that (you can drop "public" too)
<greyback> ok
#ubuntu-mir 2016-11-30
<RAOF> Bah.
<RAOF> mir_render_surface_get_buffer_stream is broken.
<duflu> RAOF: Is there such thing as a hardware default gamma ramp, or would you just need to save and use the current ramps at startup?
<RAOF> duflu: There's whatever's in the LUT after POST.
<duflu> Yeah
<RAOF> Which is going to be a sensible default.
<duflu> RAOF: Unfortunately only the system compositor (first invocation) can get that. And a client can never get it
<RAOF> Why won't a client get that?
<RAOF> We read out the existing gamma curve at startup.
<duflu> RAOF: I mean the client can't assume that someone else hasn't changed it already
<RAOF> That's true. Why would a client care?
<duflu> RAOF: To approximate 'xrandr --brightness' which is predictably just an ugly approximation
<duflu> To keep it accurate you need to know the default full brightness ramp
<RAOF> But we're going to provide a brightness knob anyway?
<duflu> RAOF: Backlight control doesn't work on desktops, projectors, OLED... :)
<RAOF> Incorrect!
<duflu> There is no backlight device
<duflu> That works
<duflu> Blame intel
<RAOF> Depends on the monitor.
<duflu> Most non-laptop systems actually don't have a user controllable backlight device
<duflu> And even some laptops don't (OLED)
<RAOF> Both my monitors support brightness control.
<duflu> RAOF: /sys/class/backlight works?
<RAOF> X doesn't, but that's fine.
<RAOF> duflu: No, but you can bang the I2C bus.
<duflu> Yeah, I'm thinking about a portable solution
<duflu> RAOF: Suggested tools for i2c controls?
<RAOF> Indeed. A portable solution is us providing a brightness knob.
<RAOF> ddccontrol is a reasonable start.
<RAOF> Oh, hello! ddcci-dkms provides /sys/class/backlight.
<RAOF> I wonder why that's not a part of drm?
<RAOF> Anyway - the portable solution is for us to provide a brightness knob, backed by an actual backlight device if possible or by gamma ramps if not.
 * RAOF likes that captureless lambdas desugar to C function pointers.
<duflu> OK, this works... sudo ddccontrol -r 0x10 -w 100 dev:/dev/i2c-7
<duflu> Not obvious or user friendly
<RAOF> Oh, totally.
<RAOF> Which, again, is why we provide a brightness knob on a MirOutput :)
<duflu> Nice to have a solution that doesn't sacrifice colour precision
<RAOF> Yes.
<duflu> Oh, we can do fancy things too. Like ask the monitor what its orientation is
<duflu> We should do that
<RAOF> Plausibly? I haven't really fiddled with too much of that :)
<duflu> My desktop monitor can do a few useful things...
<duflu> Controls (valid/current/max) [Description - Value name]:
<duflu> Control 0x02: +/1/65535 C [???]
<duflu> Control 0x04: +/0/1 C [Restore Factory Defaults]
<duflu> Control 0x05: +/0/1 C [Restore Brightness and Contrast]
<duflu> Control 0x06: +/0/1   [???]
<duflu> Control 0x08: +/0/1 C [Restore Factory Default Color]
<duflu> Control 0x10: +/50/100 C [Brightness]
<duflu> Control 0x12: +/50/100 C [Contrast]
<duflu> Control 0x14: +/0/65535 C [???]
<duflu> Control 0x16: +/100/100 C [Red maximum level]
<duflu> Control 0x18: +/100/100 C [Green maximum level]
<duflu> Control 0x1a: +/100/100 C [Blue maximum level]
<duflu> Control 0x1e: +/0/1   [???]
<duflu> Control 0x60: +/16/65535 C [Input Source Select]
<duflu> Control 0x68: +/1/2   [???]
<duflu> Control 0x6c: +/0/65535 C [Red minimum level]
<duflu> Control 0x6e: +/0/65535 C [Green minimum level]
<duflu> Control 0x70: +/0/65535 C [Blue minimum level]
<duflu> Control 0x8a: +/50/65535   [???]
<duflu> Control 0x8c: +/12/65535   [???]
<duflu> Control 0xaa: +/1/65535 C [OSD Orientation - Landscape]
<duflu> Control 0xac: +/8464/1 C [???]
<duflu> Control 0xae: +/6000/65535 C [???]
<duflu> Control 0xb0: +/0/1   [???]
<duflu> Control 0xb6: +/3/65535 C [???]
<duflu> Control 0xc0: +/0/65535   [???]
<duflu> Control 0xc6: +/17868/65535 C [???]
<duflu> Control 0xc8: +/269/147 C [???]
<duflu> Control 0xc9: +/513/65535 C [???]
<duflu> Control 0xca: +/0/2   [???]
<duflu> Control 0xcc: +/2/11   [???]
<duflu> Control 0xd6: +/1/65535 C [DPMS Control - On]
<duflu> Control 0xdc: +/0/65535 C [???]
<duflu> Control 0xdf: +/513/65535 C [???]
<duflu> Control 0xe0: +/0/65535 C [???]
<duflu> Control 0xe1: +/0/65535 C [Power control - Off]
<duflu> Control 0xe2: +/0/65535 C [???]
<duflu> Control 0xe3: +/0/65535 C [???]
<duflu> Control 0xe4: +/0/65535 C [???]
<duflu> Control 0xf0: +/0/65535 C [???]
<duflu> Control 0xf1: +/3/65535 C [???]
<duflu> Control 0xf2: +/0/65535 C [???]
<duflu> Control 0xfd: +/102/65535 C [???]
<alan_g> greyback: question answered? https://code.launchpad.net/~raof/mir/plumb-through-edid/+merge/312008
<greyback> alan_g: yep
<applemuncy_1> qtmir.surfaces: MirSurface[0x1f3b9e8,"unity8-dash"]::resize old (1920,1011), new (1080,1851)
<applemuncy_1> WxH or HxW ?
<alan_g> applemuncy_1: I've no special knowledge of qtmir, but WxH is normal
<applemuncy_1> Thanks : )
<greyback> yep, WxH
<bschaefer> fritsch, hey, soo saw kodi just bump to 18, was there anything else i need to do for the mir PR?
#ubuntu-mir 2016-12-01
<duflu> RAOF: mirout is only printing half my EDID (compared to xrandr --verbose). I wonder if it's useful to have a length value without having to interpret bytes?
<RAOF> duflu: I did think about that. The only time it's interesting is to a client that is unable to parse the EDID but, for some reason, wants to store it?
<duflu> RAOF: Yes indeed. Or a user who wants to copy and paste into a decoder
<RAOF> If they want to do that they can just read /sys/class/drm/$CONNECTOR/edid
<RAOF> In a much more friendly fashion.
<RAOF> parse-edid /sys/class/drm/$CONNECTOR/edid is going to be much easier to do than taking the output of mirout, stripping off the whitespace, converting back to binary, and dumping it into parse-edid.
<duflu> RAOF: Is there a whole length field or is it incremental?
<RAOF> The second-last byte is the number of extensions which follow. I'm not sure if all extensions are fixed-size, though.
<RAOF> So there is indeed no single length field.
<RAOF> And it's anywhere up to 32K
<duflu> Strange also DRM can't get subpixel order from my Dell
<RAOF> duflu: If you care, lp:~raof/mir/dump-edid-size
<duflu> Maybe. Working on that topic right now
<RAOF> Then maybe you'd like to review https://code.launchpad.net/~raof/mir/dump-edid-size/+merge/312223 :)
<duflu> RAOF: I'll let yours land. I have a branch that adds text (but will improve it after lunch)...
<duflu> Output 48: DisplayPort, connected, "DELL U2413", 1920x1200+0+0, enabled, on, 520mm x 320mm (24.0"), normal, 1.00x, unknown, monitor
<RAOF> Ah, parsing out the name? Sure.
<RAOF> This is the point at which I wish we had a comprehensive set of failure tests.
<RAOF> Also a proper RPC debugger.
<RAOF> Oh, right.
<RAOF> This fails because we don't have any eventloop in place.
<RAOF> And now, when you I both actually pump the eventloop *and* don't use freed data, things work better.
<RAOF> Oh, yay! I *wrote* a bunch of failure tests in the past.
<RAOF> Thanks, past, me!
 * alan_g has miral-shell running on Unity8/X+O
<romex_> oh cool, mir0.25 works fine
<alan_g> for what?
<romex_> for recording the screen, with 0.24.1 on 17.04 (mirscreencas | ffmpeg) although it did record, the video was showing only the first frame
<romex_> hm.. and unity8 works, does it already use miral?
<romex_> oh and i'm using hexchat snap on unity8 /17.04 now
<anpok> iirc there is a test sio right now that integrates the qtmir/miral integration for unity8
<anpok> that mp has it.. https://code.launchpad.net/~unity-team/qtmir/miral-qt-integration/+merge/310001
<romex_> http://i.imgur.com/mkEATx8.png
<romex_> i have #2180 installed https://bileto.ubuntu.com/#/ticket/2180
<romex_> interesting, unity8 is becoming usable :D so i took a screen shot, launched firefox dev from the container, uploaded to imgur, copy the link, alt tab to hexchat snap, and paste the link
<romex_> hm.. now to get the child windows working, this will make me cry
<alan_g> greyback: can you advise? ^^
<greyback> romex_: unity8 not quite yet using miral, we have a silo2160 with that implemented but child window support isn't in there yet
<romex_> https://code.launchpad.net/~dandrader/unity8/miral
<romex_> this, so.. i'll have to compile u8?
<romex_> do i need anything else?
<greyback> romex_: that is pre-built in silo 2160
<romex_> oh this https://code.launchpad.net/~dandrader/unity8/miral
<greyback> https://bileto.ubuntu.com/#/ticket/2160
<romex_> sorry wrong c/p
<romex_> Unity8 CI Bot: Needs Fixing (continuous-integration) 16 hours ago
<romex_> thanks greyback
<greyback> to be expected, as branch depends on a unity-api change
<greyback> romex_: don't expect child windows to work with that!
<greyback> it's a very work-in-progress silo still
<romex_> but but daniel had it working, bu then again he knows what he's doing
<romex_> ok then, i'll just wait to land it in a silo :D
<romex_> for me unity8 is almost ready :D
<romex_> i have child windows i think i'll try to move away from unity7
<romex_> and try to report more u8 bugs
<greyback> romex_: yep, daniel had it working, but it needs lots of polish yet before we it can be shared
<alan_g> greyback: after QA tried testing miral under Unity8 I started wondering about how that might work. The main blocker I see is that U8 will interpret a lot of user interactions and not pass them to the "application". Is that likely to changes, or is this just an unsupported scenario?
<greyback> alan_g: can you give me some examples of this blocker?
<alan_g> Dragging
<greyback> and when did QA test miral&unity8?
<alan_g> yesterday
<alan_g> Seems that if the test plan doesn't say "try this on a non-virtual machine running Unity7" they get inventive
<greyback> ah, now I follow you, running miral shell in a window inside unity8
<greyback> :D
<greyback> dragging should just work, all the mouse events should be delivered to the client
<greyback> but apparently not
<greyback> I'll give it a look
<alan_g> You'll need a MP I just put up
<alan_g> https://code.launchpad.net/~alan-griffiths/miral/basic-Unity8-compatibility/+merge/312246
<greyback> ok
<alan_g> I guess I need a polite way to say "if Mir doesn't work on a configuration don't bother testing MirAL on it"
<alan_g> /sigh
<greyback> alan_g: for some reason, the miral makes itself fullscreen when I try it on unity8 here. Any idea why?
<alan_g> greyback: that's Mir's "nested server" - it assumes that it takes over the outputs. Bug 1646449
<ubot5> bug 1646449 in Mir "Nested Mir does not support a windowed mode" [Medium,Triaged] https://launchpad.net/bugs/1646449
<alan_g> In the distant (and recent) past that made sense - the only nesting was inside USC
<greyback> alan_g: sorry for delay, too many distractions. I've booted to unity8, run "miral-desktop -socket ${XDG_RUNTIME_DIR}/not_mir_socket -launcher qterminal" and I get fullscreen miral with qterminal working inside it. I can drag the window around, and drag the scroll bar inside it
<alan_g> greyback: OK, cool. Is that the release version of the stack or development? (I was using X+O)
<greyback> alan_g: this is zenial
<greyback> updated just before trying
<alan_g> zesty?
<greyback> bleh, yes
<greyback> darn linguistic redundancy
<alan_g> greyback: I've got a machine on zesty, but can't log into the U8 session on it.
<alan_g> Mostly because the greeter doesn't display and I'm typing blind
<greyback> alan_g: maybe remove the unity8 greeter and install the old "unity-greeter" ?
<alan_g> it is the unity-greeter
<alan_g> Maybe I should try the unity8 one
<alan_g> greyback: while I'm distracting you. I can't reproduce locally, but any thoughts on this? https://bugs.launchpad.net/miral/+bug/1646532
<ubot5> Ubuntu bug 1646532 in MirAL "Cannot run kate or qterminal in miral-desktop" [Undecided,New]
<greyback> alan_g: worked for me on today's Zesty
<greyback> trying my xenial box
<greyback> yep, ok there too.
<alan_g> thanks, I'm wondering if there's a "missing" dependency I have installed
<greyback> alan_g: qtubuntu-desktop installed?
<greyback> I'd expect some error output from qt at least
<alan_g> according to the test case
<greyback> am unsure, it all looks legit
<greyback> he inside a VM?
<alan_g> greyback: I was checking you didn't recognise it. Don't waste time on it
<alan_g> Yes, in a VM
<greyback> ok
<greyback> if VM, qt using gl to draw stuff, might be gl issue
<alan_g> Any quick way to vaiidate that guess? (Like one of the Mir demos?)
#ubuntu-mir 2016-12-02
<alan_g> greyback: I told you not to waste time on that bug. I have already marked it a dup.
<greyback> alan_g: I hadn't hit refresh, 'tis all.
<bschaefer> yay mir support landed upstream in kodi
<AlbertA> bschaefer: nice! does that mean the snap can build for upstream github branch now? or not quite yet?
<alan_g> Nice.
<bschaefer> AlbertA, yes it can, i upstreamed the fixes need for cmake, the only issue is the tarballs
<anpok> oh wow!
 * alan_g is looking forward to running "miral-desktop -kiosk -launcher kodi"
<bschaefer> ill have to look into doing it correctly
<AlbertA> bschaefer: you could potentially just make a custom plugin that pulls in the tar balls
<bschaefer> AlbertA, hmm but internet access was blocked?
<bschaefer> which was the issue, or do plugins get more rights?
<AlbertA> bschaefer: ahh.. nvmd then. forgot the builder is launchpad
<bschaefer> AlbertA, yeah how i have to do it now is manually point the cmake -DRELATIVE_PATH_TO_TAR_BALL
<bschaefer> soo it'll be like
<bschaefer> -DPATH=../../../../../tarballs/<name>.tar
 * bschaefer will have to check it out though
<anpok> miralshell at least is working fine (still with 0.24.1)
<anpok> on vmware
<anpok> I thought there was a problem
#ubuntu-mir 2017-11-27
<alan_g> Saviq: are you looking into the PPA build failures?
<Saviq> alan_g: already fixed
<Saviq> or are there new ones?
 * Saviq checks
<Saviq> gah
<Saviq> HUH
<alan_g> Saviq: I see you pushed a change, but I don't see any difference
<Saviq> alan_g: because it failed to upload
<Saviq> "dpkg-buildpackage: unknown option or argument --tar-ignore=.git"
<Saviq> because freakin' travis has Ubuntu from 4 years ago :P and dpkg only got many long options very recently
<alan_g> Saviq: ack. You're on it?
<Saviq> alan_g: https://github.com/MirServer/mir/pull/57
<Saviq> it's even worse that dpkg-source does have them long, and that's what I checked the man for...
<Saviq> but dpkg-buildpackage only passes on short ones <facepalm />
<Saviq> this is where us waiting for the packages to build would be nice when merging ;)
<alan_g> Yup.
<Saviq> popey: hey, do you know if there's anyone managing the #ubuntu* channels here? we'd like to redirect from here to #mirserver, not sure who to ask :)
<popey> Sure thing
<popey> You could ask in #ubuntu-irc I think.
#ubuntu-mir 2017-11-29
<RAOF> New question: how does any input not currently fail Valgrind?
<RAOF> Answer: It doesn't as soon as you turn the seat report on. Top hole!
