#ubuntu-mir 2014-01-13
<RAOF> AAaargh.
<RAOF> Stupid partial-armhf-chroot stupid bastard of a thing.
<RAOF> Um, why doesn't find_path actually stat the file it's looking for?
<duflu_> RAOF: maybe because stat will give you the real answer, whereas it may be useful to retain a relative path like that passed in?
<RAOF> duflu_: But then how does it find the file?
<duflu> Magic!
<RAOF> Specifically - I can see that find_library stats for the library it's looking for, and indeed, find_library(GLIB_LIBRARY ...) is finding the glib library.
<RAOF> However, find_path(GLIB_INCLUDE_DIR glibconfig.h ...) isn't statting glibconfig.h, and isn't finding GLIB_INCLUDE_DIR.
<RAOF> Ok, that's super annoying.
<duflu> RAOF: I missed that, and hope it's not my lack of IRC stability that's annoying
<duflu> It's annoying me though
<RAOF> duflu: Ah, no. I was just getting annoyed at cmake and our convoluted build system.
 * RAOF wins the buildsystem wranger award!
<duflu> gcc wins the award for compiler most confused and lost by a missing parenthesis
<duflu> I shouldn't have to switch to clang just to figure out what's wrong.
<RAOF> duflu: Correct! Have export CC=clang; export CXX=clang++ in your .profile! :)
<RAOF> Ooh, we've gained a .clang-format directive.
<RAOF> Arse.
<RAOF> Where is the configuration of the mako testrunner?
<RAOF> Also, how do we change it?
<RAOF> (cf: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/259/console , which is a failure because of a shiny new libumockdev0 dependency that's not getting resolved)
<sgx1> hi, i haven't followed mir  for several months. did your developement focus change from lp:mir to lp:mir/devel ?
<duflu> sgx1: Yes
<duflu> :)
<sgx1> I've a local lp:mir repository. is it possible to  create a a local lp:mir/devel from this and pull updates instead of 'bzr branch lp:mir/devel" ? i'm not familiar bazaar.
<duflu> sgx1: You should "bzr branch lp:~mir-team/mir/development-branch mydevbranch" so you can pull regular updates. But if you're not happy doing that then just download the source tarball: https://launchpad.net/mir/+milestone/0.1.4
<sgx1> what's the difference between  lp:~mir-team/mir/development-branch and lp:mir/devel?
<sgx1> thanks anyway.
<alan_g> alf__: just checking - you're happy with updates to expose-rpc-infrastructure?
<alf__> alan_g: yes
<alan_g> thanks
<duflu> alan_g: I think we should usually try to wait for a minimum of 2 (human) reviews. Sorry I didn't get to it...
<duflu> Oh, perhaps it did almost get 2
<alan_g> duflu: Yeah. And it is low risk of breaking things
<duflu> alan_g: Well, start of a new mini-cycle too. So lower risk
<alan_g> ;)
<alan_g> alf__: can you land build-options-for-tests? (or abandon it)
<alf__> alan_g: I will try to sync with CI today, to change the jenkins scripts. If I don't manage to do it today I will mark it as WIP, so it doesn't clutter the MP list.
<greyback> hey folks, what does the error message: what():  error during hwc set()
<alan_g> greyback: I don't recognise it, but sounds like something kdub might know. Do you have any more details?
<greyback> alan_g: not really no, it pops up during random autopilot tests.
<greyback> https://bugs.launchpad.net/mir/+bug/1262982 is best I could log about it
<ubot5> Ubuntu bug 1262982 in unity-mir "Random mir failures running unity8 shell during AP tests" [High,Confirmed]
<alan_g> greyback: Hmm. The reporting code should be better - one of the points of boost exceptions is that they give file & line number.
<greyback> alan_g: here's one instance: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4625/artifact/results/log/unity8.log
<alan_g> greyback: there's nothing there that points me to the right place. Can you wait for kdub to wake up?
<alan_g> alf__: ^^ any idea?
<anpok> since when did this start to pop up?
<alf__> alan_g: greyback: it's from mga::HWC11Device::post() (or less likely mga::HWC10Device::post(), depending on the device). I am guessing it has to do with screen blanking, but not certain.
<greyback> anpok: not really sure, possible it's been around for a while
<anpok> but not started to happen, like mid of last week?
<greyback> alf__: that would be a possibility anyway
<greyback> anpok: think longer
<anpok> hm i have issues building for android
<anpok> the hwcomposer_defs.h defines a set of HWC_DEVICE_API_VERSION_X_X macors that map to HARDWRE_DEVICE_API_VERSION_2 .. which should be defined hardware.h
<anpok> but hardware.h only has HARDWARE_DEVICE_API_VERSION
<anpok> ah ok cleaning up the var/apt/cache/ helps
<kdub> anpok, old versions of android-headers needed a patch for that, which went in mid-december
<anpok> kdub: I had two versions of them downloaded, and both of them installed - for some reason the older one won
<kdub> alf__, alan_g so with the db-optimize branch, the proposed design is set to keep the gl rendering in the compositor class
<kdub> with the sequence being DisplayBuffer::optimize(), Renderer::render(), DisplayBuffer::post()
<kdub> we could also just have DisplayBuffer::post(gl_rendering_functor), which I didn't go with because I wanted to keep the responsibility to GL-render out of DisplayBufferr
<rsalveti> kdub: hey, got one issue with mir when porting to 4.4
<kdub> rsalveti, i'd be surprised if there wasn't one or two issues :)
<kdub> what is seen?
<rsalveti> kdub: seems the qcom devices dropped the rendering support on fb devices
<rsalveti> kdub: so fb->post doesn't work anymore
<rsalveti> seems that this is not an issue with sf as it uses the hwcomposer for post
<kdub> well, we should be able to use hwcomposer for that one too...
<rsalveti> kdub: yeah, seems that's the only issue
<rsalveti> kdub: we should probably use hwcomposer by default for that unless it's not available
<rsalveti> which might be what sf is doing already
<kdub> rsalveti, we use hwcomposer as default, and fall-back to the fb module
<rsalveti> oh, cool then
<kdub> so something isn't loading in hwcomposer, then we try fb, and that doesn't work either
<kdub> i'd guess that...
<kdub> hwcomposer is now like version 1.2 or something
<rsalveti> yeah
<kdub> not a lot of code change for us, but we currently fail if we detect version 1.2
<rsalveti> kdub: oh, ok
<kdub> rsalveti, i could try the image and see if i can bump it to work
<rsalveti> let me check, but I think mako is using 1.2
<rsalveti> kdub: yup, will publish one image in a few
<kdub> rsalveti, cool, thanks
<alf__> kdub: it could be DisplayBuffer::post(unoptimized_rendering_functor) with unoptimized_rendering_functor(list of surfaces). DisplayBuffer doesn't need to know anything about GL in particular
<rsalveti> I/SurfaceFlinger(  652): Using composer version 1.2
<rsalveti> kdub: ^
<rsalveti> in theory android 4.4 already supports even 1.3
<kdub> yeah, so my hope is that i can just bump the versioning checks in mir, and it should work
<kdub> the api is not much different between 1.1, 1.2, and 1.3
<kdub> (there were bigger jumps in api between fb module, 1.0, and 1.1)
<rsalveti> right, cool
<anpok> kdub: is it possible that the hwc cherry picks a few buffers in the middle of the array?
<anpok> bbl
<kdub> anpok, sure, if its possible
<kdub> like, if you had 4 tiled windows, it could pick the lower-left one, although in the array its between two gl composited ones
<anpok> kdub: who is using setScreenPowerMode?
<kdub> anpok, where do you see that symbol?
<anpok> dbusscreen.cpp
<anpok> so somebody wires it with powerd?
<anpok> or is it maybe used from a qml script?
<kdub> yes, that signal comes from dbus
<kdub> right now, that's powerd, but it could come from anywhere i suppose
<RAOF> robotfuel: How are the mako test images set up? Specifically, can I get another package installed on it (or, better, get the test script to run âapt-get -f installâ after its dpkg run so that added dependencies get resolved automatically)?
<robotfuel> RAOF: It's been a while let me look
<RAOF> robotfuel: cf: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/259/console
#ubuntu-mir 2014-01-14
<robotfuel> RAOF: I'll add a apt-get install -f, this is what it's doing https://bazaar.launchpad.net/~chris.gagnon/+junk/mir-medium-test-runner-for-jenkins/view/head:/mir_install_packages.sh
<RAOF> Aah.
<RAOF> I think you'll be able to remove the âfor DEB in ...â loop.
<RAOF> That appears to be there to resolve package dependencies, yes?
<robotfuel> RAOF: yes
<RAOF> Yeah. Just running âapt-get -f installâ after the dpkg run should do it, and will pick up newly-added dependencies to boot.
<robotfuel> RAOF: testing an update now.
<robotfuel> it looks like I need to use  || true on the dpkg -i part, it doesn't continue to the apt-get -f install.
<RAOF> Ah, yeah. That's right.
<kdub> rsalveti, probably too late to get a jump on the hwc 1.2 task today, but did that 4.4 image ever become available?
<RAOF> Woot.
<RAOF> Rootless working, finally.
<duflu_> Woo
<RAOF> Although for values of *working* that don't include non-origin window positioning or resizing.
<RAOF> Or, really, any window management.
<RAOF> Obivously.
<RAOF> To the Shellinator!
<duflu> RAOF: Yeah I already knew what it can't yet do. But still, cool!
<RAOF> Oh, this is why Mir has to spawn the X server...
<robotfuel> RAOF: the depends has been fixed on mako
<duflu> RAOF: The non-origin input issues are filed under: https://bugs.launchpad.net/mir/+bugs?field.tag=input
<RAOF> robotfuel: Thanks muchly!
<rsalveti> kdub: sorry, was having dinner while the image was being uploaded
<rsalveti> got a quite slow upload channel, but got the images at http://people.canonical.com/~rsalveti/aosp/
<rsalveti> you need to flash root, system, boot into recovery, and flash http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/pending/trusty-preinstalled-touch-armhf.zip
<DalekSec> duflu: For bug 1212753, it may be "related" to bug 1173649.  Had that problem myself, but didn't change xorg.conf on the live system to test it (causes other issues as well, so did on installed system.)
<ubot5> bug 1212753 in mir (Ubuntu) "[i865] unity-system-compositor fails to start: Failed to choose ARGB EGL config" [High,Triaged] https://launchpad.net/bugs/1212753
<ubot5> bug 1173649 in xserver-xorg-video-intel (Ubuntu) "incorrect color depth - intel graphics card" [Undecided,Opinion] https://launchpad.net/bugs/1173649
<duflu> DalekSec: When I tested an i810 (Pentium 3) system I noticed the same, Very interesting that you say being limited to 16-bit colour is a bug
<duflu> It might be coming from the kernel in that case
<DalekSec> While I didn't say it was a bug, it's not a good default as it causes other programs to have issues.  It's not being set to 15 from the kernel, it's in the intel driver.  (As stated by the dev in the report.)
<DalekSec> (I have a P4 with integrated.)
<duflu> DalekSec: My point was that we see common behavior between Mir and X, and their closest common factor is the kernel
<duflu> (intel driver)
<DalekSec> Ah, right.
<duflu> Heh. ickly is being profoundly helpful as usual... https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1173649/comments/44
<ubot5> Ubuntu bug 1173649 in xserver-xorg-video-intel (Ubuntu) "incorrect color depth - intel graphics card" [Undecided,Opinion]
<duflu> *ickle
<duflu> Welcome to summer :)
<kgunn> duflu: so, to promote 0.1.4 dev to trusty, just need to tag the latest rev & then mp dev branch to trusty...
<kgunn> noticed we slightly changed...right? now we rely on the tag
<kgunn> oh...already tagged i see
<duflu> kgunn: Correct. The tag is right
<duflu> I thought greyback et al might be keen to get the flicker/snapshot fix
<greyback> duflu: yep, we were
<duflu> were? are? :)
<greyback> nah, not any more :P
<duflu> Oh well. 0.1.4 was plenty big enough to justify a release anyway. And we were 3.5 weeks past v0.1.3
 * greyback saw the client RPC mechanism land, was happy
 * duflu recalls willfully staying out of that discussion, so glad he ignored the MP come to think of it
<anpok> duflu: whats your opinion on having background color a part of the scene and giving it to begin vs GLRenderer having a color in the constructor
<duflu> anpok: I'm not sure it fits in the mir concept of Scene. Your current design I think is cleaner
<duflu> It's a good stepping stone toward "how do we do custom GL in a bespoke shell?"
<anpok> when i first started the change there was no begin/end in renderer but a clear instead..
<anpok> so set_clear_color made some sense
<duflu> anpok: Good point. I did intend for custom shells (like demo shell) to modify begin() in that case
<duflu> Perhaps to inherit from GLRenderer and change it
<anpok> so it looks a bit wierder now - and I wonder if moving to the GLRenderer constructor, and hence doing it udner the hood would be better
<anpok> or that
<anpok> duflu: I will change it to a struct .. but
<anpok> just made a test .. the tuple emits less binary size than the struct
<duflu> anpok: That's unusual, but still worth a struct
<anpok> the difference is hard to notice, but the code looks of course better.
<anpok> I nearly did it in the first place but felt bad about it since I had the feeling to provide more to it, to have a reason for adding a distinct structure...
<duflu> typedefs can serve as documentation :)
<anpok> is the opengl spec defining a default clear color?
<duflu> anpok: Yes, but that includes alpha==0 (http://www.khronos.org/opengles/sdk/docs/man/)
<duflu> I mean... http://www.khronos.org/opengles/sdk/docs/man/xhtml/glClearColor.xml
<duflu> Whee, rotated displays minus distortion
<duflu> Plus too many dependent branches
<anpok> hm hardest problem is always coming up with a name
<duflu> Fred
<duflu> Bob
<duflu> Gertrude
<anpok> speeking of that, my wife came up with names for our kids
 * anpok is just listening to http://channel9.msdn.com/Events/GoingNative/2013/Inheritance-Is-The-Base-Class-of-Evil 
 * duflu downloads it for later
<anpok> that person gave a longer talk on the first day, much longer
<anpok> and that one contains the motivation for that one..
<anpok> .. next to other nice examples: http://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning
<kgunn> duflu: i feel stupid (no mgr jokes please :)...but shouldn't there be a way to propose this
<kgunn> https://code.launchpad.net/~mir-team/mir/version-0.1.4/+merge/201134
<kgunn> via launchpad button to trusty
<duflu> kgunn: https://code.launchpad.net/~mir-team/mir/version-0.1.4/+register-merge
<duflu> kgunn: Not sure if it will work though. Usually we merge dev into a child of lp:mir and then propose that
<kgunn> duflu: thanks...dammit...just one level down
<kgunn> duflu: ah...
<kgunn> ok will do
<duflu> Well merge dev (-rv0.1.4)
<kgunn> duflu: exactly...
<kgunn> has to the ver you tagged
<alan_g> \o/ - talk accepted! http://accu.org/index.php/conferences/accu_conference_2014/accu2014_sessions#c_best_practice_-_designing_header_files
<anpok> congratulations
<kgunn> duflu: fyi...https://code.launchpad.net/~mir-team/mir/promote-ver-0.1.4/+merge/201560
<duflu> kgunn: OK, but instead of reviewing I'm running off to dinner :)
<kgunn> duflu: enjoy....is happy birthday in order ?
<duflu> kgunn: Thanks but I'd rather avoid the thought
<kgunn> heh
<alf_> alan_g: Congratulations! Is this talk related to an article of a similar name you have written (I think it was in overload?)?
<alan_g> alf_: yes, that is the core
<anpok> alan_g: hey, saw the TODO you had in your 2013 slides yesterday in code - when doing the other review - and thought about it..
<anpok> with the compile time trie..
<alan_g> anpok: I've been resisting that temptation a long time now. It isn't a worthwhile optimisation.
<anpok> yeah it is more of an intersting riddle to solve with new c++ features than anything you notice as an improvement afterwards
<anpok> apart from one TODO less.
<alan_g> If you want something worthwhile, figure out why duflu added code to stop & start the compositor to unity-mir/DBusScreen::setScreenPowerMode() and do something less brutal. (c.f. https://code.launchpad.net/~kdub/mir/compositor-double-start-stop/+merge/201242)
<didrocks> kgunn: hey!
<didrocks> kgunn: we are about to start our "self service" release piloting by end of week, I wonder if the new Mir release will be a nice opportunity for that
<anpok> alan_g: where did you see the change in unity-mir?
<sil2100> That could be a good test of the process, as there are ABI breaks to handle
<alan_g> anpok: bzr blame src/unity-mir/dbusscreen.cpp
<anpok> ah not a new change
<anpok> thought you were referring to new branch for unity-mir
<alan_g> anpok: sorry no, a bit of lp archaeology called for
<didrocks> sil2100: +1
<didrocks> sil2100: and there is a client ABI break, so needs new xorg
<mlankhorst> can it be hooked up to xorg 1.15? :P
<didrocks> kgunn: I guess you forgot the xmir changes ^
<didrocks> mlankhorst: it can if we go with the silo approach
<didrocks> and if timelines matches
<mlankhorst> well expecting it in 2 weeks
<didrocks> ah, I think they will want it first though
<didrocks> mlankhorst: I guess it's just a rebuild anyway, but let's see with them
<mlankhorst> oh in that case just rebuild
<mlankhorst> RAOF: ping
<anpok> alan_g: hm yes duflu considered letting the display trigger the compositor to stop and start again
<mlankhorst> RAOF: are you going to release xserver-xorg-video-ati ubuntu11 at some point? :P
<anpok> but according to the bug ticket comments there was no decision and the fix was to add compositor stop / start on power mode changes
<anpok> https://bugs.launchpad.net/ubuntu/+source/unity-mir/+bug/1255045/comments/18
<ubot5> Ubuntu bug 1255045 in unity-mir (Ubuntu) "screen does not turn on on maguro when pressing the power button" [High,Fix released]
<alan_g> anpok: I suspect our current problem is manifested if the power mode is set but isn't changing.
<anpok> yes
<anpok> powerd probably sending multiple ons
<anpok> or whatever also chats about power modes
<anpok> but doing more state tracking on unity-mir does not feel right
<anpok> hm but for display configurations it already tracks wheter it would change the configuration
<alan_g> unity-mir is stateful already, so that doesn't bother me
<alan_g> but It seems extreme to be stopping the compositor
<alan_g> Especially as, in principle, there could be outputs powered independently
<anpok> is there a compositor instance per output?
<alan_g> alf_: can you think of a more elegant approach to bug 1255045 than stop/start of the compositor? ^^
<ubot5> bug 1255045 in unity-mir (Ubuntu) "screen does not turn on on maguro when pressing the power button" [High,Fix released] https://launchpad.net/bugs/1255045
<anpok> or is there one compositor for all?
<anpok> ok
<alan_g> one compositor to rule all the compositing threads
<alan_g> (Which are currently serialized because of a broken model)
<ogra_> note that there is also https://code.launchpad.net/~mterry/unity-system-compositor/dbus-screen-fix/+merge/201211
<ogra_> (for nested mode, i just tested it on maguro)
<alan_g> ogra_: thanks for the warning
<alf_> alan_g: At the moment configure() recreates the DisplayBuffers, so the compositor needs to be stopped and restarted to read the new ones
<ogra_> i actually think the hack from the session mir should be dropped for this, i doubt we will use it without u-s-c in the future
<ogra_> (feels like duplication to leave it in place)
<alf_> alan_g: so when changing just the power state we could retain the current displaybuffers => not start stop needed
<anpok> alf_: do we need to inject some sort of screen-changed-please-redraw?
<alan_g> alf_: so displayConfig->configure_output(..) => displayConfig->power_mode(newPowerMode)
<alan_g> anpok: we shouldn't need it if we don't discard the buffer
<anpok> which we do now because the buffers are recreated because the config change.. ok
<anpok> alan_g: or more logic in configure_output to detect changes that just boil down to power changes?
<alf_> alan_g: anpok: right, the work happens in Display::configure(), the DisplayConfiguration is just a container of information
<alan_g> Ah yes.
<alan_g> So display->power_mode(newPowerMode)
<kgunn> didrocks: thanks for the catch...
<anpok> alan_g: alf_: but on android it does not seem to do more right now - it actually just checks for power mode changes
<alf_> anpok: on Mesa it doesn't though...
<alf_> alan_g: anpok: Alternatively we could continue with start/stop, but hiding it from unity-mir. For example unity-mir could use the DisplayChanger class (or similar)
<alan_g> alf_: +1 for hiding it from unity-mir and USC
<anpok> alan_g: you refered to as broken because it create a thread for each display that then just sits and waits of a trigger, instead of using the pool we already have from asio..
<anpok> alf_: you display conf change AND DisplayChanger? or something new?
<anpok> +mean
<alan_g> anpok: actually I was referring to the "lock the world, paint an output, unlock the world" bottleneck
<alf_> alan_g: anpok: so unity-mir could use an interface like PowerManager (yes, we can probably find a better name) which is implemented by injecting code to {stop() configure() start()} into our main loop
<anpok> alf_: why arent we doing that also for display configuration changes?
<anpok|lunch> i mean the existing DisplayConfiguration::configure_output somethig
<alf_> kgunn: On Nexus 10, glCopyTexSubImage2D is for some reason too slow when copying to a texture backed by an EGLImage. Interestingly it's fast when the texture is not backed by an EGLImage. I am looking into/measuring alternatives, like rendering to a texture (backed by the buffer we want to send to the client) first and rendering that to the screen, when we need to take a screenshot
<alf_> anpok|lunch: I don't understand what you mean
<alf_> kgunn: ideally we would want to use multiple render targets (drawing to multiple buffers at once), but that's not supported in ES 2.0
<kgunn> alf_: right
<kgunn> alf_: wonder if just a dma memcpy would be faster than farting around with glteximage calls
<alf_> kgunn: Which API allows us to do that with GPU buffer data?
<alf_> kgunn: does Android have something for this?
<kgunn> alf_: if its system memory it shouldn't matter that it also happens to be mapped into for gpu use
<kgunn> should it ?
<alf_> kgunn: no, but that's true only for unified memory systems
<kgunn> alf_: right...i am making assumptions
<kgunn> i thot everything after old n7 was unified
<alf_> kgunn: you are forgetting the desktop case ;)
<alf_> kgunn: however it's not a bad assumption to make and that's the other alternative I was considering: doing it differently on android vs mesa (i.e. not depending necessarily on GL)
<kgunn> alf_:yeah...on desktop cpu is fast enough
<kgunn> alf_: and i think in general glteximage khronos spec iirc has some
<alf_> kgunn: (but I need to wait for kdub to discuss what android offers us in terms of buffer copying)
<kgunn> aspects to it, where it has to do some weird backstore preservation stuff
<kgunn> that you're simply not interested in
<kgunn> but...its part of the spec...and just slows it down
<alf_> kgunn: @preservation, that gave me an idea...
<rsalveti> kdub: were you able to flash 4.4?
<kdub> rsalveti, i flashed it, didnt get the wifi to work though.
<kdub> is that expected?
<rsalveti> kdub: did you also flash the radio?
<kdub> i flashed CM11, and then flashed system, recovery, ubuntu touch, boot
<kdub> i got a could-not-access on the .img's in the link you sent
<rsalveti> kdub: weird, maybe an image was being uploaded when you tried
<rsalveti> kdub: I don't think CM11 would flash the radio
<rsalveti> kdub: flash the bootloader & radio as I said on my email, and try again
<kdub> okay
<rsalveti> let me check the permission again
<kdub> ah, its working now
<rsalveti> kdub: indeed, you should be able to access them now
<kdub> okay, ill let you know how it goes shortly
<rsalveti> kdub: great
<kdub> rsalveti, still having radio/wifi problems, will reflash
<rsalveti> kdub: weird, ok
<kdub> rsalveti, i got (from clockworkmod) 'root access missing', with a yes/no to obtain root, but other than that, nothing out of the ordinary
<kdub> rsalveti, worked this time flashing though
<kdub> i fastboot formatted a few partitions
<rsalveti> kdub: yeah, you can ignore that, need to get that fixed
<rsalveti> got it
<rsalveti> yeah, I flashed the 4.4.2 factory image before flashing our image
<rsalveti> that also erases everything
<kdub> rsalveti, at any rate, have the image working, so starting to get mir to run, thanks
<rsalveti> kdub: great
<RAOF> mlankhorst: That would be a reasonable plan, wouldn't it :)
<RAOF> mlankhorst: Got a bug reference for it?
<mlankhorst> RAOF: no, was just curious
<RAOF> But you're right, I should release it now :)
#ubuntu-mir 2014-01-15
<bregma> so, I'm hacking up a Unity8 session for the desktop, and now I'm stuck with Mir throwing an exception  what():  Failed to create GBM buffer object ... any ideas what to persue with this?
<RAOF> bregma: I always end up gdbing that, and catching the exception to see what's broken.
<bregma> problem is there's other exceptions thrown in the stack as a means of regular control flow (shame!) so it's a pain to trace during the login session startup
<RAOF> What? Where are our exceptions-as-control-flow?
<RAOF> Oh.
<RAOF> Yeah. In UdevWrapper?
<RAOF> AKA: my code
<RAOF> </shame>
<bregma> no, it's somewhere in one of the Unity8 libraries
<bregma> processing config files, throws an exception at end of file just like Java does
<bregma> </scorn>
<bregma> anyway, my problem comes from a gbm_bo_create() failed call, which sounds like perms mayve?
<RAOF> Quite possibly.
<RAOF> Although I thought that would break earlier.
<bregma> well, this is nested mir-on-mir, everything is baby steps
<robert_ancell> bregma, is there anything else you need from me for Unity 8 session work?
<bregma> robert_ancell, I'm not sure, but I'm using your lightdm branch and at least that works OK
<robert_ancell> cool
<bregma> I seem to be stuck on this gbm_bo_create() fail without a clue, though
<RAOF> What's the callstack?
<bregma> http://paste.ubuntu.com/6753595/
<bregma> no debug symbols because it's installed from a PPA hashtag sadface
<RAOF> Ah, ok.
<RAOF> At least it isn't trying and failing to allocate a hardware cursor buffer or something.
<RAOF> Hm. Has anyone tied Alan's in_process_server?
<RAOF> Or even tried it; I'm easy :)
<RAOF> EOD
<duflu> RAOF: Should I know about that? Was it announced anywhere?
<didrocks> kgunn: hey, reverted your approval (see the commits)
<didrocks> comments*
<kgunn> didrocks: sorry...comments where ?
<didrocks> kgunn: Mir MP you just approved
<kgunn> didrocks: ah..i see
<didrocks> kgunn: I saw IS told the firewall is opened, I need to test those, but I can get someone from your team piloting the new process as soon as tomorrow I guess (my tomorrow)
<didrocks> do you know who should be this "lander" ?
<kgunn> didrocks: ok...so new process i get that...but
<kgunn> i'm confused about changelog...i thot we _did_ want to list all the changes
<kgunn> ?
<didrocks> kgunn: yeah, for the current release
<didrocks> not for an older one
<didrocks> see, there are two stenzas that was added in debian/changelog
<kgunn> didrocks: ah...ok...so remove the second stanza in changelog and we are all good ?
<didrocks> one for current release
<didrocks> +mir (0.1.4-0ubuntu1) UNRELEASED; urgency=medium
<didrocks> and one for  mir (0.1.3+14.04.20140108-0ubuntu1) trusty; urgency=low
<didrocks> yeah, just remove the modification for 0.1.3+14.04.20140108-0ubuntu1
<kgunn> didrocks: as for "lander"...what capabilities does that person need ?
<kgunn> didrocks: i would recommend duflu if you do it in the morning hours...and then alan_g or alf_ in euro time...
<didrocks> kgunn: rigourness, tracking of failures. Of course, being in a compatible timezone will help
<didrocks> but I agree duflu sounds the best to me
<didrocks> I just need to ensure that we can catch up in the morning so that we can discuss the process and I can show him how this works :)
<kgunn> duflu: you still on ?....can would you mind quickly just removing the 0.1.3 ref from the debian changelog as mentioned by didrocks above ?
<kgunn> (i gotta pay attention to the room)
<duflu> kgunn: Sorry, had a birthday visitor, and plumber digging up the pavement. Simultaneously
<kgunn> duflu: sounds awesome :)
<kgunn> duflu: and now my confidence is shattered after i read the rejection based on missing 2kloc from my MP :)
<kgunn> which...i still can't figure why that happened...
<duflu> kgunn: Seems to have come from some pre-0.1.4 revision.
<kgunn> i know...i was really careful...
<kgunn> but then again, those were bzr repos, which i thot i pulled correctly to, but who knows...
<kgunn> old local bzr repos that is
<duflu> didrocks: The old changelog for 0.1.3 is wrong. Are you sure we want to keep it?
<kgunn> ^ i agree with duflu ...the one in there is more descriptive
<didrocks> duflu: yeah, you don't rewrite history, it's like if you uncommit, change content commit and push --overwrite
<duflu> Or do we just need to restore "Automatic snapshot..." ?
<duflu> didrocks: Even if it's wrong? What use the changelog if it's not accurate? :)
<duflu> ^os
<duflu> ^is
<didrocks> duflu: it's published all over the place, and you are changing it
<didrocks> you need to be careful before publishing it, not after :)
<didrocks> and don't change history
<duflu> didrocks: OK...
<didrocks> duflu: do you think that tomorrow morning, we can try doing that piloting for the new release process? probably a hangout or anything like that will be easier
<duflu> didrocks: It was the robot/script that got it wrong I think
<didrocks> (my morning)
<didrocks> duflu: well, it's because your process didn't follow with your second trunk, what we support
<duflu> didrocks: Sure
<didrocks> but that's going to be fixed ;)
<didrocks> ok, let's do that, I'll ping that
<didrocks> you*
 * duflu still likes "bzr pull :push"
<duflu> didrocks: changelog fixed
<didrocks> duflu: thanks, will get it merged as per tomorrow training
<kgunn> thanks guys
<fginther> greyback, ping
<greyback> fginther: pong
<fginther> greyback, do you have some time to discuss the mir testing you asked about last week?
<greyback> fginther: sure
<fginther> greyback, this is for a physical desktop hardware test right?
<greyback> fginther: these tests need to run on devices where mir runs
<fginther> greyback, ok, so touch devices and desktop
<greyback> fginther: yep
<greyback> fginther: so this is for the unity-mir project
<greyback> tsdgeos: can you show fginther what test we want to run - I'm about to eod
<tsdgeos> sure
<tsdgeos> fginther: there's a package called libunity-mir-tests or something
<tsdgeos> fginther: inside it there's a binary called unity-mir-test-app
<tsdgeos> just run that one
<fginther> tsdgeos, ok, are there any specifics about how the test system should be provisioned, or is installing the test package sufficient
<greyback> fginther: we're just getting started off with unity-mir tests, so please advise us on how to structure/change things
<tsdgeos> fginther: i would hope that installing it should be enough
<fginther> Most of our test runners are setup to install packages on top of a fully provisioned system, run the test command, then collect the junitxml result files
<tsdgeos> that should work
<tsdgeos> unity-mir-test-app should accept the -oxml thing
<tsdgeos> to give you junitxml output
<tsdgeos> -o filepath,xunitxml
<tsdgeos> to be more precise
<fginther> tsdgeos, if you have those execution details, can I ask that you create a bug under https://bugs.launchpad.net/ubuntu-ci-services-itself/+bugs to track this?
<tsdgeos> sure
<fginther> tsdgeos, also, in may be a lot easier to get a touch test working for this, would it be helpful to you if that were ready before the desktop test, or do both need to be ready at the same time?
<tsdgeos> fginther: i actually was thinking device only :D
<tsdgeos> so yeah, no need to have them at the same time
<tsdgeos> just trying to boostrap the thing
<fginther> tsdgeos, I can't make any promises on when this will be ready, but I'll try to get started on it this week
<tsdgeos> cool
<greyback> fginther: tsdgeos: thanks!
<fginther> greyback, you're welcome
<tsdgeos> fginther: https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1269485 is enough?
<ubot5> Ubuntu bug 1269485 in Ubuntu CI Services "Create CI step for unity-mir tests" [Undecided,New]
<fginther> tsdgeos, thanks
<bregma> racarr, got a minute to help with a Mir input issue?
<racarr> bregma: Hey. Let me try! What's up?
<racarr> I am making tea but will be back in like...2 min
<bregma> I have Unity8 running on Mir on my desktop, but no input seems to work ... is there a good way to approach debugging this (like maybe an environment variable to dump debug info to stderr)?
<bregma> oh, umm, I'm using a laptop with a touchscreen, so at least that should work I would think
<racarr> lets start with MIR_SERVER_INPUT_REPORT=log and MIR_SERVER_LEGACY_INPUT_REPORT=log
<racarr> bregma: ^
<racarr> first thing to check is of course permissions
<racarr> user can't read from /dev/input
<bregma> racarr, OK, sounds like a good start ... gotta reconfigure and reboot
<bregma> /dev/input/* is all root:root
<racarr> areyourunning u8 as user? You definitely wontget input then
<bregma> wait, Unity8 doesn't support being used?
<bregma> that doesn;t sound too sleable
<bregma> how does Unity8 work on the phone then?
<racarr> I think...we put user in some group that can read /dev/input
<racarr> I think
<racarr> the proper solution involves lightdm
<racarr> no one ever explained it to me but it must be like
<racarr> lightdm and upstart and fd passing
<racarr> I guess we need that for the desktop preview
<bregma> mmm, I can ping RobertAncell later
<racarr> yes lets ask him.
<racarr> I think that's the short story though
<bregma> racarr, I manually set the permissions on /dev/input/*(a+rw, for the lulz) and set those env vars, I see motion events being logged now, but no response from Unity8 .. any suggestions?
<bregma> [1389815848.590785] (II) input: Published motion event seq_id=147 time=1389815848590506000 (0.264998 ms ago) dest_fd=54
<racarr> bregma: Hmm...
<racarr> nowits hard tosay, I tried unity8 on desktop not so long ago and input was working when I ran it as root (basically what you did)
<racarr> anything even a little interesting in the logs?
<racarr> Could it be related to this laptop touchscreen?(Does anything elsework)
<bregma> Unity7 works just dandy
<bregma> like I say, I see the motion events in the Unity8 log, but there seems to be a piece missing
<bregma> I see 'UbuntuKeyboardInfo - socket error: "QLocalSocket::connectToServer: Invalid name"' as well
<bregma> in case that's any help
<bregma> latest log: http://paste.ubuntu.com/6758171/
<dandrader> bregma, about the "UbuntuKeyboardInfo" error. that's unity8 trying to talk to ubuntu-keyboard (the virtual keyboard daemon on phablet)
<dandrader> but, naturally, this daemon is not available on desktop
<bregma> naturally
<bregma> yet
<dandrader> bregma, as for input debugging, you can check what's happening at the next layer,  the qpa (qtubuntu), where mir events are transformed into qt ones
<bregma> dandrader, that's the information i was missing
<bregma> I'm using the ubuntumirserver QPA
<dandrader> qtubuntu is a bit of a maze as classes there have deep inheritance trees
<dandrader> (could be easily flattened, btw)
<dandrader> bregma, the file you want to look at there is src/platforms/base/input.cc
<bregma> aptly names
<dandrader> bregma, you can set #define LOG_EVENTS to 1 there and build it with CONFIG+=debug to get a lot of output
<dandrader> bregma, the place where that translation (mir -> qt) of input events happens is QUbuntuBaseInput::dispatchMotionEvent
<kdub> racarr, i'm tinkering with the 4.4-based ubuntu touch... not getting input though, any quick checks/fixes I can do?
<dandrader> EOD
<bregma> gah, evidently Mir does not work with the latest libgl1-mesa-dri because of missing symbols ... the fun never stops
<racarr> kdub: MIR_SERVER_LEGACY_INPUT_REPORT=log might help
<racarr> um maybeit relates
<racarr> to the device configuration file stuff
<bregma> failed to open /usr/lib/x86_64-linux-gnu/dri/i965_dri.so: /usr/lib/x86_64-linux-gnu/dri/i965_dri.so: undefined symbol: _glapi_tls_Dispatch (unity-system-compositor.log)
<racarr> woah its a party now
<racarr> kdub: they end in like .idc and were in android_root/system/devices
<racarr> InputDevice.cpp l89
<racarr> just a guess though
<racarr> will think more am expectingmylandlord and bug inspector at any moment
<racarr> bug exterminator
#ubuntu-mir 2014-01-16
<RAOF> duflu_: I only use the mu:: shorthand in the implementation file of mir::udev::, everywhere else I use the full mir::udev:: namespace specifier. You'd prefer it if I used the full mir::udev:: specifier in the implementation file, too?
<duflu_> RAOF: No, there are two possible ways to avoid mentioning the namespace in the implementation. I'd prefer either of them :)
<duflu> *to avoid repeating the namespace
<didrocks> duflu: hey! tell me when you have some time for a chat on the new process (hangout I guess)
<duflu> didrocks: Sorry, it seems I'm possibly tied up for the rest of the day (sabdfl) in other meetings
<didrocks> duflu: ok, do you think you will have time tomorrow or let's wait for Monday?
<duflu> didrocks: Tomorrow is OK AFAIK
<didrocks> duflu: sounds ok. there are consequences btw, we need to have a lander for unity-mir (I think you won't land every release for it) and another one for qtubuntu/platform-api
<didrocks> as they are linked to those landing, we need to clear that out
<didrocks> kgunn: I was thinking about greyback for unity-mir, thoughts?
<greyback> didrocks: count me in
<didrocks> sweet!
<didrocks> so, we need to find a victim for qtubuntu/platform-api ;)
<kgunn> didrocks: thats ricmm_
<kgunn> who is in a mtng w me right now
<didrocks> kgunn: ok, I'll send an email to sum that up
<didrocks> thanks!
<anpok_> are there any rules of thumb in using lttng - should one avoid string outputs.. keep them short .. just do not core, and make the trace points as descriptive as possible..
<tvoss> anpok_, I think there are no strong rules, but the longer the name, the more data to store
<tvoss> anpok_, I would think that limiting the scope with something mir::comp::event might make sense
<tvoss> anpok_, thoughts?
<anpok_> re
<anpok_> tvoss: thought about parameters .. i.e there is now a report that is meant to produce the selected egl configuration.. and does so by dumping each configuration attribute line by line
<anpok_> " [ name_of_the_attribute ] : <EGLInt value>"
<tvoss> anpok_, okay, can you produce a single line out of that? we can selectively _not_ record that
<anpok_> sure
<alan_g> anpok_: there's no reason that every reporting interface should be implemented for lttng (or glog, or log, or...)
<anpok_> hm why not?
<alan_g> lack of need
<anpok_> so you mean no further lttng report implementations are needed?
<alan_g> When we need them we write them - or even a (hypothetical) http status monitor
<tvoss> alan_g, I disagree. duflu's reporters are evaluated manually by parsing text output
<tvoss> alan_g, I think those are perfect candidates for lttng report implementations
<alan_g> tvoss: I don't know what "duflu's reporters" means, so I can't disagree that some more lttng reports are needed
<tvoss> alan_g, duflu did quite some work on reporters recently for input latency and such
<alan_g> But there's no reason to say "here's a reporting interface, therefore do an lttng implementation"
<alan_g> But what you're saying is we have a timing report requirement on *some* report interfaces - therefore do an lttng implementation. Which is fine.
<tvoss> alan_g, fair
<alan_g> But there are too many sentences starting "But"
<anpok_> But you can continue like that
<alan_g> But "a report that is meant to produce the selected egl configuration" doesn't beg for an lttng version
<anpok_> so you would be fine with leaving out certain report method calls?
<alan_g> Sure, just implement the simplest thing that satisfies a need we have now.
<kdub> alan_g, i like the second suggestion in ~kdub/mir/db-optimize
<alan_g> kdub: yw
<fginther> tsdgeos, going back to 1269485. You don't want a VM do you, you want to run this on a touch device, right?
<fginther> https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1269485
<ubot5> Ubuntu bug 1269485 in Ubuntu CI Services "Create CI step for unity-mir tests" [Undecided,New]
<tsdgeos> fginther: yes, device is cool
#ubuntu-mir 2014-01-17
<duflu> RAOF: Your rootless work... is that a whole new DDX?
<RAOF> duflu: No; it's the same set of DDXen.
<RAOF> duflu: It's basically âhook into all non-root-window setupâ rather than âhook into only the root-window setupâ
<duflu> RAOF: Oh. So same number of copies as XMir? (one too many)
<RAOF> duflu: Correct.
<RAOF> Our design ensures we cannot do better (barring optimisations for GLX apps, which are easier for rootless)
<duflu> RAOF: Wouldn't glamor do better?
<RAOF> No? Why would it do better?
<duflu> RAOF: I thought it might be more efficient but now realize you'd just have an extra texture upload, in a different place
<duflu> Hey, I just realized the texture cache should really help XMir multimonitor
<duflu> maybe
<duflu> Hmm, scrap that. XMir will typically always use bypass. So no textures anyway
<RAOF> Yeah, I'd hope so.
<RAOF> To the EOWatron!
 * duflu waves to RAOF
<duflu> perhaps too late
<anpok> hi
<alf_> anpok: hi
<timp> hello
<timp> we are having some crashes in autolanding that seem mir-related, can someone have a look at the crash logs? I cannot make sense from them - https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/4710/
<timp> we saw the same here in this MR https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-swipe-delete-001/+merge/199906
<timp> three times autolanding failed for that MR, and then suddenly it passed. So the failures seem not consistent
<alf_> timp: looking
<timp> alf_: thanks
<dandrader> when a bug fix goes into lp:mir/devel, what's the process to have it cherry-picked into lp:mir (trunk)?
<alf_> dandrader: ideally we merge lp:mir/devel into trunk, but depending on what else has landed this may not be possible at that point, so you can propose a separate MP for the fix targeting lp:mir
<alf_> timp: how can I get a stack trace from the .crash file? apport-retrace doesn't work for me (but perhaps I am doing it wrong)
<dandrader> alf_, sure. Because I noticed (correct me if I'm wrong) that trunk and devel are ABI-incompatible at the moment
<alf_> dandrader: right, so in this case, either wait or propose a separate MP if it's urgent
<dandrader> alf_, I'll make a separate proposal targeting trunk. thanks
<dandrader> (it's a critical bug)
<timp> alf_: I don't know. I was hoping to get help here
 * timp in a meeting now
<anpok> kdub: didnt you recently fix an issue in which frames where jittering on nexus 10?
<dandrader> gl newbie needing help: what would make mir_demo_client_egltriangle block indefinitely on the glDrawArrays(...) of its render loop? I suppose it's waiting for the mir server to do something it was supposed to do?  like giving him a new buffer to draw on?
<dandrader> for context: I'm updating gerry's "qml mir compositor" prototype to use the latest mir version
<alan_g> dandrader: you may get some clue which call is blocking from  MIR_CLIENT_RPC_REPORT=log
<dandrader> alan_g, thanks, will try it now
<dandrader> alan_g, my bad. I wans't fflushing after the printf. it's actually hanging in mir_eglapp_swap_buffers(), which makes more sense
<dandrader> alan_g, the last line from the RPC report is "(DD) rpc: Invocation succeeded: id: 4 method_name: next_buffer"
<dandrader> more precisely, eglSwapBuffers(egldisplay, eglsurface);
<kdub> alan_g, alf_ updated https://code.launchpad.net/~kdub/mir/workaround-qcom-display-request/+merge/201859
<kdub> should now check the array length in a less-objectionable way
<kdub> thanks alan_g
<rsalveti> kdub: hey, any branch for me to try?
<kdub> rsalveti, oh yeah https://code.launchpad.net/~kdub/mir/hwc12-support/+merge/202015
<kdub> something wish screen blanking is still funny, but one step at a time
<kdub> that at least gets unity8 to the screen
<rsalveti> kdub: great
<rsalveti> kdub: did it worked fine with hwcomposer 1.1 when using 4.2 on mako as well?
<kdub> rsalveti, still have to test that
<rsalveti> right, because I expect us to merge this first before doing the 4.4 switch
<rsalveti> but will give it a try in a few
<kdub> starting to like the 'post_update(renderlist, render_fn)' better than 'filter_out_optimized_renderables'
#ubuntu-mir 2015-01-12
<duflu> RAOF: Just installed a new vivid touch image and there's a little bit on 0.9 with the new 0.10
<duflu> Looks like another dependencies fix?
<duflu> little bit *of* 0.9
<Saviq> duflu, FYI, I bumped changelog in the 0.8 backport, too (to be able to depend on it)
<duflu> Saviq: Thanks. I think there are one or two other fixes in 0.8.1, did you notice?
<Saviq> duflu, did not
<duflu> Saviq: Yeah one landed already and others we should consider: https://launchpad.net/mir/+milestone/0.8.1
<Saviq> duflu, that might be a problem for the rtm release, we only want very targeted fixes in there (unless all of those are supposed to go into rtm?)
<duflu> Saviq: Yeah, ask the higher powers that be
<duflu> They look important
<Saviq> duflu, they should have a https://launchpad.net/canonical-devices-system-image/ then
<Saviq> task
<duflu> Saviq: Sure, but camako/kgunn would prefer to be the deciders
<duflu> So long as someone tells them... or else they're likely to not notice the other bugs
<Saviq> yeah, ok, I'll continue as if the one bug landed and the new one are accepted, will talk to them when their timezone gets up
<alan_g> alf_: happy & healthy new year
<alf_> alan_g: thanks, you too!
<mlankhorst> do we have the es2 manual somewhere?
<alf_> mlankhorst: (In case you haven't found it yet) https://www.khronos.org/registry/gles/
<mlankhorst> yeah i think i found something like that, and found what i was looking for, thanks ;)
<mlankhorst> was curious why glamor with the ES2 backend was disabling GL_ALPHA for alpha pictures. I re-enabled it again and things now owrk..
<mlankhorst> oh
<mlankhorst>     Disable A8 texture format for GLES2.
<mlankhorst>     
<mlankhorst>     As PVR's GLES2 implementation doesn't support A8 texture as
<mlankhorst>     rendering target, we disable it for now.
<mlankhorst> figures
<Saviq> folks, we're getting a build failure of the prompt session backports, any idea what's wrong http://paste.ubuntu.com/9718106/ ?
<Saviq> the silo is http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=landing-018
<alan_g> Saviq: looks like a Mir API update to PromptSessionListener needs corresponding changes to PromptSessionListener
<alan_g> in qtmir I presume
<Saviq> alan_g, well, yeah, that's what https://code.launchpad.net/~mir-team/qtmir/rtm-14.09-staging/+merge/244580 does - and that's what fails the build...
<Saviq> ah hmm
<Saviq> alan_g, I see now
<Saviq> alan_g, the relevant changes were split between two MPs on our side, sorry for the noise
<alan_g> np
<alan_g> I know it illustrates we're not where we want to be but does anyone have a reason why landing this first and then improving the API would be a bad idea? https://code.launchpad.net/~mir-team/mir/improved-tiling-window-mamagement/+merge/245994
<kdub> alf_, anpok  welcome back!
<kdub> alf_, in mgm::Display we register_fd_handler(), but I don't see the unregistration... is that something to be added?
 * kdub is trying to figure out if android is okay not to unregister the display change handler as well
<alf_> kdub: Hi! Yes, we could/should add this. It's not there because it was not needed under normal usage (both display and ML are torn down).
<kgunn> alf \o/ welcome back!
<kgunn> anpok:  \o/ welcome back!
<alf_> kgunn: \o Hi!
<alf_> kgunn: HNY + 12!
<kgunn> ;)
<racarr_> Good morning
<alan_g> Good evening
<kdub> can we just rm proving_server?
<racarr_> :) I still support that....
<racarr_> I kind of want to guess the outcome of the MP
<racarr_> and put it in a sealed envelope
<racarr_> :p
<racarr_> kdub: I think there is a pretty strong argument that its a negtive because it pulls on the interfaces but not realistically
<racarr_> but then we have to take on the burden of not breaking it
<racarr_> updating it
<racarr_> reviewing changes to it
<racarr_> manually testing it
<kdub> right, exactly... maybe in a bit
<racarr_> yeah its easier once example-window-management is a little more complete I guess
<kgunn> camako: is citrain device-upgrade still busted? (packaging)
<kgunn> just checkin' before i try...(flashing atm)
<camako> kgunn, I haven't tried but it probably is
<camako> kgunn, dist-upgrade works
<kgunn> camako: i didn't bother...just dist-upgraded
<camako> kgunn, RAOF didn't agree with Robru's analysis
<camako> that anything is broken
<camako> on mir side
<camako> kgunn, let's talk about it tonight
<camako> with the aussies
<kgunn> ack
<kgunn> camako: would you be utterly disappointed if i missed tonight?
<camako> kgunn, I'd be devastated
<camako> :-)
<mhall119> I've found that after a day of heavy use, especially loading a lot of images in my app (uReadIt) that screen movement gets choppy, predominately in the lower half of the screen
<mhall119> is there a known bug for graphical glitches/tearing on the Nexus 4?
<mhall119> kgunn: ^^
<kgunn> kdub: you ever see this? ^
<mhall119> I haven't tried screen-recording it yet, since it may not show up in a recording if it's a driver issue
<kgunn> mhall119: actually just recording with another camera might give clues...
<kdub> kgunn, I haven't seen that issue
<kgunn> mhall119: some people say "tearing" which may or may not fit a typical graphics dude's definition
<mhall119> ok, I just rebooted (new revision!) so I'll have to wait until it starts acting up again, usually does it at least once a day
<kgunn> mhall119: do you ever see it with anything else ? i mean if it tears via the app....if you switch to another app
<kgunn> does the tearing continue ?
<greyback_> there was a report of such visual glitching during the sprint in Washington
<mhall119> kgunn: yeah, I don't know the proper terms, it looks like random rectangles of screen are being re-painted a fraction of a second behind others
<greyback_> yep, exactly that. I've seen that
<mhall119> kgunn: once it starts it does it on everything, apps, shell, etc
<mhall119> I can't recall if it does it on the lock/welcome screen
<mhall119> lock screen doesn't really move enough to notice if it did
<greyback_> https://bugs.launchpad.net/mir/+bug/1383745 <- this bug was reported
<ubot5> Launchpad bug 1383745 in Mir "[mako] screen corruption/tearing after using the device for medium durations" [Medium,New]
<greyback_> Andrew (community guy who reported it) showed it to me on his N4.
<greyback_> I've never noticed it with my N4 however
<kgunn> mhall119: does that uReadIt seem to help make it happen ?
<mhall119> greyback_: that's exactly it!
<mhall119> kgunn: I don't know, but it's one of my most heavily used apps
<mhall119> it's also loading/unloading/moving a lot of images, which is part of the reason I suspect it triggersis
<mhall119> triggers it
<kgunn> mhall119: does anything make it "recover" ? or once it starts tearing continues thru reboot ?
<kgunn> or rather reboot i assume fixes it, but it will continue until you reboot ?
<kgunn> ..geeze my grammar is awful
<greyback_> I recall the Mir team suspecting it was a GPU driver bug, or Mir not using fences quite correctly. You see the tiles that the GPU memory is broken up into
<greyback_> as if buffer swap is only half done
<kgunn> right...i do recall the fellow showing us
<mhall119> kgunn: only a reboot seems to help
<kgunn> of course kdub was on baby-watch 2014 :)
<mhall119> kgunn: I've tried closing all apps, locking, unlocking, etc, nothing helps
<kdub> restarting lightdm?
<mhall119> haven't tried that yet, just sudo restart lightdm?
<kdub> should work
<kgunn> kdub: but won't that reset the gl context anyway ?
<kgunn> or what would lightdm restart tell you? or separate out ?
<kdub> sure, but if its a kernel driver leak, then it'll come back
<kgunn> ah
<kdub> if its a userspace driver leak or a mir leak, it won't have glitches on restart
<kdub> sounds like a resource problem at the moment
<kgunn> userspace== all the proprietary gpu mapping stuff...
<kgunn> yeah
<mhall119> kdub: I'll try that if it happens again
<ahayzen> mhall119, i used to have that screen tearing alot around the DC sprint...but i haven't seen it recently on my device, it was usually triggered/noticed when i entered the spread for me
<ahayzen> mhall119, but i could just be restarting my device too often to see it
<mhall119> ahayzen: what channel do you use?
<ahayzen> mhall119, rtm proposed
<ahayzen> mhall119, so i'm a bit infront of you
#ubuntu-mir 2015-01-13
<duflu_> Hang on a sec, be in hangout in a minute
<duflu_> Saviq: That heap corruption bug I don't think I'll try to push for 0.8.1. It's unclear if it's really resolved or if we're getting false duplicates from another bug with the same Stacktrace signature confusing errors.ubuntu.com
<Saviq> duflu, ack
<duflu> Once we've proven the problem is gone in devices running 0.10 it will be clear
<duflu> Saviq: Hmm, although if we pushed the fix for the first one to 0.8.1 that might be enough. Cos the second similar crash only got introduced in 0.9
 * duflu proposes for someone else to decide
<Saviq> duflu, 0.8.1 is already up for QA validation
<duflu> Saviq: Easy decision then. Which rev?
<Saviq> ok this is going to be mayhem
<Saviq> I knew we should not have released lp:mir/0.8 into rtm :|
<Saviq> duflu, 1965 + lp:~mir-team/mir/backport-1355173.trust-prompt-suspend
<duflu> Saviq: Kay. That's landed at r1966 BTW
<Saviq> yeah, that's why I don't know what will happen
<Saviq> because the train merged it as a different rev
<Saviq> most probably conflicts will happen
<duflu> Saviq: I doubt it's a problem. Nothing else has landed on that branch in months
<Saviq> duflu, probably not a *problem*, but the train will complain anyway, as it will try to push 1965 + backport that it merged itself to lp:mir/0.8
<Saviq> and I expect it will fail to do so due to the new commit on top
<Saviq> although maybe it will reconcile first, we'll see
<Saviq> but that's exactly why I wanted to have a separate branch for releases, one that no one pushes to manually
<duflu> Saviq: RTM packaging is a different branch: lp:~mir-team/mir/14.09
<duflu> Although I fully expect the train madness to ignore that fact :)
<duflu> Merging will happen cleanly either way. Bzr knows when the same source branch already landed.
<Saviq> duflu, well, camako seems to not have known about the 14.09 branch, so the MP that is in the train is the above backport
<duflu> Saviq: Never mind. They both end up in sync later. We can clarify configs another day
<Saviq> duflu, it's not what the train ignores, really, it's rather that the MP was against lp:mir/0.8 and not the rtm branch
<Saviq> duflu, yup
 * duflu wishes more people remembered the difference between upstream and distro branches
<duflu> More robots I mean?
<alan_g> alf: have you asked CI eng to look at the repeated failures on https://jenkins.qa.ubuntu.com/job/mir-vivid-amd64-autolanding/?
<alf> alan_g: no
<alan_g> I've just asked
<alf> alan_g: thanks, just joined channel
 * kdub wishes android had thought out their multimonitor stuff better
 * alan_g wishes Mir had thought out their multimonitor stuff better
 * davmor2 wishes anyone had thought about multimonitor stuff full stop
<kdub> :)
 * anpok_ wishes we infinite display space and no need for multiple monitors
<davmor2> anpok_: that's easy buy one of these http://www.samsung.com/uk/consumer/tv-audio-video/televisions/curved-tvs/UE78HU8500TXXU and use it as a monitor
#ubuntu-mir 2015-01-14
<duflu> That's confusing. Linking a bug to a branch changes the branch's last modified date
<alan_g> duflu: how do you envisage getting a scale factor from "Alt+middle_button"?
<duflu> alan_g: Pythagoreoan distance from the point of clicking to current cursor pos
<duflu> alan_g: Kind of like the way we scale on touch in the demo shell
 * duflu -> dinner
<alan_g> I'm still missing something: isn't the point of clicking the current cursor position?
 * alan_g sees duflu has gone
<alan_g> Ah! middle click & drag
<greyback_> stupid question, but I don't see it anywhere in the code: is the DPI of a monitor calculated anywhere?
<greyback_> alf: ^
<alf> greyback_: not at the moment (but all the info is there)
<greyback_> alf: ok, was just checking
<greyback_> thanks
<greyback_> alf: Ive another stupid question, does DPI depend on the resolution you've chosen for your monitor? Or it depends on the actual number of pixels it has?
<alf> greyback_: resolution, since even though the monitor may have a finer grain than the current resolution it's not really available to us
<greyback_> alf: ok, is what I guessed, thanks! Is it worth doing that sum though, if you get weird fractional values? Should there be a small set (72, 96..) we choose from?
<greyback_> not sure how toolkits deal with weird values for DPI
<alf> greyback_: Not sure either, but if toolkits want to support real sizes properly they need to handle all possible values.
<greyback_> alf: indeed. Think will be truthful for now, and then see which toolkits give trouble. Thanks
<anpok_> hm shoold key modifiers work globally for all attached input devices
<anpok_> *should
<anpok_> X behaves that way.. the android input stack does that too
<racarr> anpok_: Seems like ok behavior...I guess we will eventually have to support both and let shell decide
<anpok_> racarr: somethig odd i noticed becayse modifier state is currently unified by eventhub.. as it queries all devices it knows.. but it has no clue about devices added with libinput
<anpok_> which is probably no problem since i would use the android code for everything not a touchpad
<racarr> BufferStream 2.0 aka "gently introduce buffer stream" seemingly done...requires a round of review from myself though.
<racarr> This just factors our the common MirScreencast and MirSurface code
<racarr> and tests, etc...in toa  client internal
<racarr> MirBufferStream
<racarr> then I should be able to rebase intro-buffer-stream on it and
<racarr> well, the lack of code duplication should make it a lot more compelling :)
<mhall119> kdub: FYI,had the graphics issue again and restarting lightdm fixed it
<mhall119> http://paste.ubuntu.com/9752519/ shows RAM usage before and after
<mhall119> not sure if that helps or not
<greyback__> mhall119: please update https://bugs.launchpad.net/mir/+bug/1383745 with your finding, it implies either the userland driver or Mir has an issue
<ubot5> Launchpad bug 1383745 in Mir "[mako] screen corruption/tearing after using the device for medium durations" [Medium,New]
#ubuntu-mir 2015-01-15
<alan_g> anpok: your concerns are addressed now? https://code.launchpad.net/~mir-team/mir/introduce-pointer-event/+merge/245679
<anpok> yes
<kdub> alf_, would the asio->glib mainloop stuff affect this part of USC?
<kdub> http://bazaar.launchpad.net/~mir-team/unity-system-compositor/devel-mir-next/view/head:/src/asio_dm_connection.cpp
<alf_> kdub: no, that's an independent asio service instantiation
<kdub> alf_, thanks
<alf_> kdub: np
<kgunn> alf_: so should we also migrate usc onto glib mainloop ?  curious the thot
<alf_> kgunn: @USC glib, I would say no. The needs of the USC DM connection are very simple and a good match for what ASIO offers. The GLib event loop would be overkill for this.
<kgunn> ack
<tedg> There's no Mir connection mock, right?
<tedg> I'm not going to write one, but I'd love to have one for my test :-)
#ubuntu-mir 2015-01-16
<duflu> alf_: Did you try to reproduce the heap corruption by reverting my fix yet?
<alf_> duflu: no
<duflu> I'm hesitant to revisit it. There's likely days of work in that still and I have one hour left in the week really
<alf_> duflu: probably not a good time to start :)
<alf_> kdub: Hi! @more-helpful-hwclist, so are "//HWC 1.1 to 1.2 have int sourceCrop and *no* fbtarget" and "//HWC 1.1 to 1.2 have int sourceCrop and fbtarget" both true?
<kdub> alf_, no, 1.1 and 1.2 have a fbtarget layer
<alf_> kdub: so the first comment is wrong?
<kdub> yes, but the code is right... wil go change
<alf_> kdub: ack
<kdub> oh, reading in context, I just copied the comment without changing it
<kdub> updated
<attente_> AlbertA: hi, is your menu api also implemented in the mir_demo_server?
<AlbertA> attente_: the server currently does not have default semantics for menu surfaces yet
<tedg> Is there any progress on getting Mir to build on PPC?
<tedg> Kinda annoying that my packages lose architectures when adding Mir dependencies :-/
 * alan_g still hasn't fixed all the tests he broke this morning
<racarr> tedg: As you may have guessed by now I think the answer is no :p
<tedg> racarr, Yeah :-/
<tedg> Need to find some PPC phones
<tedg> :-)
<mlankhorst> they exist? o.O
#ubuntu-mir 2016-01-18
<tjaalton> I need a newer xmir patch so it works with 1.18 which I'm going to start pushing to a staging ppa
<flux__> tjaalton, 0.18?
<tjaalton> build failures http://pastebin.com/TpHjxNCh
<tjaalton> xserver 1.18
<flux__> ah
<tjaalton> some would be easy even for me to fix but not all
<tjaalton> hm, I'll give it a try and then someone can fix what went wrong :)
<tjaalton> actually it should be good now, I'll push it to the ppa and post something on the ml
<LocutusOfBorg> hi guys
<LocutusOfBorg> [14:02:38] <LocutusOfBorg> I did upload libsdl2_2.0.4 on debian experimental, and I would like to know your opinion about a sync
<LocutusOfBorg> [14:03:08] <LocutusOfBorg> it changed API/ABI, but upstream convinced us that the changes are still ABI safe (and if something segfaults, it's because they are using the library in a wrong way)
<LocutusOfBorg> [14:03:15] <LocutusOfBorg> so I didn't bump soname
<LocutusOfBorg> [14:03:22] <LocutusOfBorg> https://lists.alioth.debian.org/pipermail/pkg-sdl-maintainers/2016-January/thread.html
<LocutusOfBorg> [14:03:26] <LocutusOfBorg> the rationale is there ^^^
<LocutusOfBorg> [14:03:56] <LocutusOfBorg> how do you feel about a sync from experimental or unstable (I plan to test reverse dependencies a week or two and then go for unstable)
<LocutusOfBorg> [14:04:13] <LocutusOfBorg> s/sync/merge
<LocutusOfBorg> from #-devel
<ogra_> :)
<LocutusOfBorg> BTW the patch (ubuntu delta) seems that can even be dropped
<LocutusOfBorg> the mir support should be in the new release
<ogra_> yeah, most likely
<LocutusOfBorg> so, can I sync from experimental?
<ogra_> well, if nobody from the Mir guys objects i guess so
<LocutusOfBorg> I uploaded on unstable on delayed/7
<LocutusOfBorg> if nothing breaks I'll sync in a week+1 day
<tsdgeos> guys have you seen this crash backtrace before? https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1535297/comments/5
<ubot5> Launchpad bug 1535297 in unity8 (Ubuntu) "Unity8 crashes on session logout on desktop" [Undecided,New]
#ubuntu-mir 2016-01-19
<kenvandine> kgunn, any status update on mouse settings?  bill said that's something we need for 9.5 and we're still blocked on the shell work
<kgunn> kenvandine: for mouse settings there is nothing blocking...
<kgunn> one sec
<kenvandine> kgunn, i meant it's blocking the mouse panel in system-settings
<kgunn> kenvandine: right, there is nothing blocking...fwd'ing you an email that andreas wrote sometime back (but you're not on :)
<kenvandine> kgunn, we need the shell work to land which includes the gsettings schema
<kgunn> kenvandine: i thot with input the link was with u-s-c over dbus and no shell interaction ?
<kenvandine> greyback said we needed a shell piece
<kenvandine> and the gsettings schema will live in the shell
<kenvandine> kgunn, check with greyback, i'm sure he can explain it better
<kenvandine> kgunn, basically u-s-c provides a dbus api, but the shell needs to configure u-s-c on startup based on per-user settings
<kenvandine> i think the u-s-c api is done, we just need the shell to configure u-s-c based on gsettings
<kgunn> kenvandine: ack...btw, we're at a sprint together...so slow on pings
#ubuntu-mir 2016-01-20
<mariogrip>  is this normal behavior in mir? http://paste.ubuntu.com/14576082/
<mariogrip> that alloc is 0x0  after hw_module->methods->open
<mariogrip> android platform
<flux__> yay 0.18.1
<flux__> - Bug fixed:
<flux__>       . [regression] pinch to zoom not working reliably (LP: #1531517)
<ubot5> Launchpad bug 1531517 in Mir 0.18 "[regression] pinch to zoom not working reliably" [Critical,Fix committed] https://launchpad.net/bugs/1531517
<mariogrip> is it normal that alloc_dev->() is set android_buffer_allocator.cpp on L63 which at this point it get's set to 0x0 in qcom/libgralloc/gpu.cpp (in android src)?
<mariogrip> alloc_dev->alloc()**
<mterry> RAOF, MIR_LOGGING=1 eh?
<RAOF> mterry: That is a thing that you could set, yes :)
<mterry> RAOF, this is a nested server, does that change anything?  (in terms of defaults or whatever)
<RAOF> mterry: It shouldn't.
<Saviq> camako, we'll need pressure on bug #1530946, too
<ubot5> bug 1530946 in Mir "Setting a surface keymap crashes in xkbcommon: xkb_keymap_new_from_names()" [High,Confirmed] https://launchpad.net/bugs/1530946
<camako> Saviq, ack
<camako> Saviq, https://code.launchpad.net/~mir-team/mir/0.19/+merge/283303/comments/719534
<Saviq> camako, thanks
<anpok> Saviq: aye already doing some background research on bernoulli equation
<Saviq> anpok, :D
#ubuntu-mir 2016-01-21
<flux__> can't wait for mir 0.19 to land
<flux__> can i haz mir 0.19?
<flux__> <3
<flux__> uh. there's also 0.18.2
<duflu> kdub: I just noticed my next big major task ("frame notififcation") was mentioned as a requirement of NBS. Can I assume it's not in there yet?
<duflu> (https://docs.google.com/spreadsheets/d/1qf3IssN_sujygMPK2sTX2AUhGiDUBF3TMYYcSRSaSy0/edit?usp=sharing)
<alan_g> Saviq: RAOF does this make sense? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1535397/comments/5
<ubot5> Launchpad bug 1535397 in unity8 (Ubuntu) "[enhancement] Implement support for QWindow::visibility set to Automatic" [High,Triaged]
<RAOF> alan_g: That makes sense...
<RAOF> I can't say that I *like* it...
 * alan_g fears the madness of the context will force something RAOF won't like
<alan_g> anpok: I've just updated and with -c 3256 "add an option to select pointer acceleration profile" I see compile errors like: "error: âlibinput_device_config_accel_get_profileâ was not declared in this scope" - does that mean anything to you?
<mterry> RAOF, is there a way to regenerate http://unity.ubuntu.com/mir/using_mir_on_pc.html from trunk?
<RAOF> mterry: Sigh.
<RAOF> mterry: You can grab the doc from the mir source tree, but this is one of the âIS is going to get onto it reeeeeeel soon nowâ things that's been outstanding since August last year or something.
<mterry> RAOF, sure got it  :(  We just got bit by outdated advice is all.  We're fixed now, I was just trying to save future souls
#ubuntu-mir 2016-01-22
<zzarr> hello!
<zzarr> can I check if mir is running on a remote display?
<zzarr> I tested with "ps afx | grep unity-system-compositor" it's not...
#ubuntu-mir 2017-01-16
<alan_g> duflu: I saw camako's comment about mir_window_type_popover. The design doc says "The popup type was previously called Menu" which doesn't match the comments in our header. Do you have an opinion on the correct name?
<duflu> alan_g: It appears I missed that. So no opinion
<duflu> yet
<alan_g> The description of https://code.launchpad.net/~mir-team/mir/no-window-type-overlay/+merge/314749
<duflu> alan_g: Traditionally in toolkits there have always been multiple separate menu types (which helps with behaviour and animations)... popup != dropdown
<duflu> alan_g: Sounds like it belongs in a different MP anyway
<duflu> Or three different menu classes: https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472629520
<alan_g> Sure, I was tempted to just do away with mir_window_type_popover (which is trivial) but then wondered if that was a good direction.
<duflu> alan_g: I'm pretty sure we need to separate them because decoration and animation may be different
<alan_g> "Examples of popups include menus, combo boxes, walkthrough hints, and popovers" (Mir and Unity: Surfaces, input, and displays (v0.3)_
<duflu> Oh dear
<duflu> Yes a combo box may be a popover and may be similar to a menu
<alan_g> But at the moment mir_window_type_popover and menu are synonyms
<duflu> alan_g: I think it's an interesting question but not a blocker for that particular MP
<duflu> which just landed
<alan_g> That MP landed. I was wondering how best to sort out mir_window_type_popover/menu which is also wrong.
<duflu> alan_g: This is why display servers generally don't get involved in toolkit design :)
<alan_g> I guess a toolkit designer/user would be the best to ask. ;)
<alan_g> duflu: thanks for the chat. At least I know there isn't an easy right solution.
<duflu> alan_g: I know we need to distinguish the different menu types. That's all
<duflu> I think I know anyway. Maybe we need a subtype
<alan_g> I'll see what attente thinks when he wakes up
<duflu> cimi: zesty Unity8 now has the new input rate logic. Feels a bit nicer but we're not finished yet
<duflu> Although I would like to get a kernel fix for the usbhid regression....
<hikiko> hey Trevinho
<hikiko> ping :)
<hikiko> here?
<hikiko> I think there's a problem with the design you suggest in the gcc review: if I use the tool, unity won't switch profile in real-time but in next reboot
<hikiko> :s/gcc/ucc
<hikiko> also, if the user modifies the lowgfx profile, he wont have the default settings anymore
<hikiko> next restart*
<hikiko> also that profile is generated by the .ini isn't it?
<hikiko> the tool runs once at startup as far as I understand it
<hikiko> I probably should change unity to use that tool as well, but we still need to switch to lowgfx instantly
<hikiko> and overwriting the settings seems to be the easiest way
 * alan_g wonders how that's relevant to #ubuntu-mir
<hikiko> oh noes
<hikiko> LOL
<hikiko> sorry....
<hikiko> I thought I am in #ubuntu-desktop
<hikiko> thanks alan_g :p
<alan_g> hikiko: how's it going in U7 land?
<hikiko> alan_g, fine :) I am trying to finish all the remaining priority tasks to focus on porting chromium on mir
<alan_g> A great way to start the new year. (I hope)
<attente> alan_g: hey. gtk does differentiate between the different popup types when creating those widgets, so if it helps you to differentiate between them, we could pass them to you: https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#GdkWindowTypeHint
<alan_g> attente: I'm not sure how much it would help us (it is really unclear if Mir needs different behaviour). But if a shell is doing server-side decorations it would likely matter.
#ubuntu-mir 2017-01-17
<alan_g> Saviq: is greyback about this week? (I just saw bug 1656727 which sounds related to the client window stuff)
<ubot5> bug 1656727 in unity8 (Ubuntu) "Unity8 crashes and restarts when clicking on a menu [terminate called after throwing an instance of 'std::out_of_range' what(): map::at]" [Critical,Confirmed] https://launchpad.net/bugs/1656727
<Saviq> alan_g, was sick over the weekend, should be back today, assuming he got better
<alan_g> Thanks
<Saviq> alan_g, I believe that's a dupe of bug #1643976 though
<ubot5> bug 1643976 in Oxide "webbrowser-app crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [Medium,Confirmed] https://launchpad.net/bugs/1643976
<Saviq> difficult to know without more of a trace
<alan_g> I don't think so - that's the client crashing, not the server
<Saviq> the server is the client ;)
<Saviq> alan_g, whenever unity8 tries to instantiate a WebView (wizard), it crashes like that - could very well be a coincidence
<alan_g> Oh, I read it as the app crashes
<alan_g> nm
<alan_g> Our "EOY review": https://insights.ubuntu.com/2017/01/17/mir-2016-end-of-year-review/
#ubuntu-mir 2017-01-18
<alan_g> greyback: (and mup) I wondered if your work on client windows would bear on bug 1656727?
<ubot5> bug 1656727 in unity8 (Ubuntu) "Unity8 crashes and restarts when clicking on a menu [terminate called after throwing an instance of 'std::out_of_range' what(): map::at]" [Critical,Confirmed] https://launchpad.net/bugs/1656727
<greyback> alan_g: thanks :) I would expect that to be solved by dandrader's child window work
<dandrader> alan_g: when are you planning to release a new miral
<dandrader> alan_g: looking forward to have the fix for https://bugs.launchpad.net/miral/+bug/1652109
<ubot5> Ubuntu bug 1652109 in MirAL "tooltip windows never get ready" [Medium,Fix committed]
<alan_g> dandrader: I'm trying to get stuff reviewed for a release alongside Mir 0.26
<alan_g> dandrader|afk: if that's not fast enough I can release against 0.25 separately
<dandrader> alan_g: ok. I would expect releasing miral fixed to be a simple matter
<dandrader> s/fixed/fixes
<alan_g> dandrader: it is. Just requires chasing through belito & ci-eng. But I've let the fix accumulate until needed.
<alan_g> so it is a matter of how urgently you need it
#ubuntu-mir 2017-01-19
<blmvxer> Hello, I have a couple questions about mir and unity8 on x86
<duflu> blmvxer: Hi, yes?
<blmvxer> I've been trying to force rotation on My baytrail tablet as it's stuck in portrait until I get the gyro drivers up.
<blmvxer> is there a command line or config way of doing that?
<duflu> blmvxer: Yes, but the command line for it isn't introduced till Mir 0.26.0 :)
<duflu> blmvxer: If you have Mir 0.26 or later then run 'mirout -h' to see the commands
<blmvxer> Ugh dang it, well one last question. Maliit keyboard doesn't display either, is there a way to manually invoke that?
<duflu> blmvxer: Not sure about that one. Maybe try #ubuntu-unity
<blmvxer> Installing mir-utils aws and I'll check with them. I just recently got Ubuntu "hacked" on my baytrail and was hoping to mess around with Unity8 since there's an x compatibility layer and such
<blmvxer> It's apparently mir 0.24
<duflu> blmvxer: Yeah I maintain Xmir also. If you're running Mir 0.24 then it sounds like you're not up to date. I suggest Ubuntu 17.04 for the latest Unity8+Mir
<duflu> (which is Mir 0.25)
<blmvxer> That probably won't allow me to force landscape mode though, right? That's the only issue other than maliit I'm facing
<duflu> blmvxer: Yes and no. Mir 0.26.0 will be released to Ubuntu 17.04 in the coming weeks, which will solve it. However earlier Ubuntu versions won't ever get the newer Mir
<blmvxer> Dang, I'm just not looking forward to building the kernel since I require so many patches and drivers to even boot on this tablet lol
<blmvxer> Thanks though for your help, I'll check with the other channel for help on Maliit
<duflu> Ok, no problem
<alan_g> greyback: this is potentially useful to you - https://code.launchpad.net/~alan-griffiths/miral/trace-exceptions/+merge/315112
<greyback> yep looks like it could come in handy
<dandrader> alan_g: what's the silo with miral's upcoming release?
<dandrader> alan_g: think I found it https://bileto.ubuntu.com/#/ticket/2382
<alan_g> dandrader: 2382 - it's in QA ATM
<alan_g> yeah, that's it. :)
<tjaalton> is mir in xenial older so that newer xmir can't be used there, and will stay like that?
<tjaalton> wondering what to do with lts-hwe
<tjaalton> drop xmir entirely from it and rely on the original one, or forward-port the old xmir patch to lts-hwe version..
<tjaalton> looks like xenial is just missing mir_event_type_input_device_state
<alan_g> tjaalton: AFAIK there's no current intent to update xenial with a new Mir
<tjaalton> alan_g: ok, that's fine
<tjaalton> looks like I've fixed this build fail in the past too :)
<alan_g> It is remotely possible that the whole stack will be SRU'd at some point. (But not before 17.04 ships.)
#ubuntu-mir 2017-01-20
<duflu> camako: Woo, 0.26.0 now contains 40 fixes. Big enough for you? :)
<alan_g> dandrader: miral 1.0.2 has landed in archive
 * dandrader checks
<dandrader> alan_g, indeed, thanks
<dandrader> alan_g, see this scenario. got top-level window A (focused and on top of the stack) followed by top-level window B and child window B1. B->activate() is called. miral raises only B1. Is that correct?
<dandrader> (B1 was front of B, to be clear)
<dandrader> alan_g, yes, reproduced it with miral-shell. indeed a bug
<dandrader> alan_g, https://bugs.launchpad.net/miral/+bug/1658085
<ubot5> Ubuntu bug 1658085 in MirAL "top-level window is not raised along with its child" [Undecided,New]
<alan_g> dandrader: ack
<dandrader> alan_g, is there a key to quit miral-shell?
<alan_g> Ctrl-Alt-BkSp
<dandrader> thanks
<alan_g> bregma: miral-examples contains a useful scripts: miral-desktop (starts a "desktop") and miral-xrun (runs argument under Xmir)
<alan_g> dandrader: https://code.launchpad.net/~alan-griffiths/miral/fix-1658085/+merge/315232
<dandrader> alan_g, ack
<alan_g> dandrader: am I right in assuming your child window stuff will sweep up bug 1656727?
<ubot5> bug 1656727 in unity8 (Ubuntu) "Unity8 crashes and restarts when clicking on a menu [terminate called after throwing an instance of 'std::out_of_range' what(): map::at]" [Critical,Confirmed] https://launchpad.net/bugs/1656727
<dandrader> alan_g, yes. I get no crash here. just proper menus
<dandrader> alan_g, will link the bug to the mp
<alan_g> dandrader: great
