#ubuntu-mir 2014-01-06
<duflu> RAOF: Surely if Mesa is that sensitive to compiler flags, we should try them out? :)
<RAOF> We should certainly see if it *is* that sensitive to compiler flags, yes :)
<duflu> Yes, if.
<mlankhorst> morning
<mlankhorst> RAOF: well --enable-debug causes -O0 to be added by default, it's stupid. :/
<mlankhorst> apart from that I think it doesn't matter much
<alan_g> Happy New Year
<duflu> alan_g: Welcome back
<anpok> hi
<duflu> Morning anpok
<anpok> duflu: with opening namespace scope i meant haveing namespace foo\n{\nnamepace bar\n{\n at the beginning of a block of method implementations..
<duflu> anpok: Yes, that's good too. I forgot about that
<alan_g> anpok: here's the project guideline: http://unity.ubuntu.com/mir/cppguide/index.html?showone=Namespaces#Namespaces - there are a lot of valid options (although we don't seem to use many of them)
 * duflu runs away
<anpok> alan_g: there are a few cases in which there is a general rule description
<anpok> then a few examples
<anpok> and then detail rules below
<anpok> and some of the examples are not covered by the detailed rules..
<alan_g> anpok: true. Maybe someone (hint hint) should MP a fix
<anpok> alan_g: yeah for ever issue there are at least two possible solutions
<anpok> *every
<anpok> alan_g: we started the namespace discussion because I used mg::foo in a new source file..
<alan_g> That's common Mir usage. What's to discuss?
<anpok> that we should abondon it in favor of an acronym free style
 * alan_g has a mild preference for what we have and a strong preference for not changing something that's all over the codebase.
<anpok> i suspect uk has no holy three kings national holiday?
<alan_g> Correct. It isn't a national holiday.
<alan_g> CofE has epiphany on 12th night and it is traditional to take down decorations.
<racarr> Morning
<alan_g> Happy New Year
<racarr> Happy new years as well!
<kdub> the dreaded 'no space left on device'
<kgunn> on n7 ?
<kdub> yeah, just from installing too much stuff on device
<racarr> happy new years btw kgunn :)
<kgunn> racarr: thanks
<kgunn> you too
<kgunn> rebooting n4 takes much longer than i would ever guess
<kdub> maybe something's amiss, mine doesn't take an unreasonable amount of time
<kgunn> might be cause i'm doing unity8 "run_on_device" which copies stuff...and then seems to take a bit before actually restarting unity8
#ubuntu-mir 2014-01-07
<anpok> duflu: i put the prereq back on wip indicating that I will rework it now.
<anpok> hi btw
<duflu> Hello
<duflu> anpok: If nothing else, Jenkins will refuse to land an approved branch if it depends on something else not yet landed. So you'll save yourself time, trying to keep them in order
<alan_g> alf_: Happy new year
<alf_> alan_g: Happy new year to you too!
 * duflu -> dinner
<RAOF> didrocks: How much trouble would a Breaks: libmirclientN (<< $SOMEVER) and Breaks: libmirserver (<< $SOMEVER) to ensure a lockstep upgrade be for you, and at what point in the cycle would it become too much trouble?
<didrocks> RAOF: you have something without SONAME which is going to break libmirclient and server?
<RAOF> didrocks: Indeed
<RAOF> I intend to break the protocol (by introducing a way to break protocol without requiring lockstep upgrades, so this should happen exactly once)
<didrocks> RAOF: what other source package is going to break libmir* ?
<RAOF> No other source package, but clients linked against old libmirclientN won't be able to talk to servers linked against new libmirserver and visa versa.
<RAOF> (Of course, the Breaks: itself isn't entirely sufficient, as it'll break a session if you upgrade the libs mid-session. Fortunately, the phone doesn't do that)
<RAOF> didrocks: libmirclientN will break libmirserver, and libmirserver will break libmirclient
<didrocks> RAOF: so, basically, you will place the breaks on source package producing xserver-xorg-xmir, libubuntu-application-api-mirclient1, libunity-mir1 and unity-system-compositor
<RAOF> didrocks:
<didrocks> RAOF: ah, only between those 2
<didrocks> ok, so, feel free to do it at any time, this doesn't really impact us
<didrocks> or told differentlyâ¦
<didrocks> it impacts us way less than ABI breaks :p
<didrocks> at the same time, in a release, there is a high chance to have an ABI break as well, so even the Breaks will probably be redundant :)
<RAOF> :)
<RAOF> Yeah, this affects the touch images not very much. But would be evil on a desktop, where you can upgrade without restarting. So I'd like to do it before we have any real desktop users. :)
<alf_> greyback: Hi! I am trying to build lp:~gerboland/+junk/qml-demo-shell/ on Nexus 10 but I am getting "qmake: could not find a Qt installation of ''". I have installed the packages you mention in the bug report. Any idea what I could be missing?
<greyback> alf_: qt5-qmake might me the culprit
<alf_> greyback: I have it... anyway, calling /usr/lib/arm-linux-gnueabihf/qt5/bin/qmake directly works, something must be messed up with qtchooser
<greyback> alf_: qt5-default then :)
<alf_> greyback: great, thanks :)
<alf_> greyback: ok, managed to build and run, but when I tap on e.g. 'Dialer' it complains: "** (process:13065): WARNING **: Unable to emit signal 'application-start'
<alf_> Asking Upstart to start application 'dialer-app' failed"
<alf_> greyback: I am running as "phablet" after having stopped "unity8" in a clean touch installation
<greyback> alf_: interesting, wonder how that broke (upstart-app-launch the source of that message)
<alf_> greyback: tapping a second time prints: "(null):dbus_error.c:69: Unhandled error from nih_dbus_error_raise: Name "com.ubuntu.Upstart" does not exist" and crashes shortly after
<greyback> alf_: yeah, it's like upstart isn't there. It didn't get removed by any chance. Does "initctl list" list some processes?
<alf_> greyback: yes
<greyback> alf_: sounds stupid, but maybe reboot the device, and check if unity can launch apps first
<alf_> greyback: ok
<alf_> greyback: apps start ok in unity8, although unity8 seems to hang after I open 3-4 of them
<greyback> alf_: did you just do a clean flash of latest devel image? I'll have to investigate this
<alf_> greyback: yes, ubuntu-system channel devel, but just a moment... if I reboot and immediately stop unity8 (without first causing it to hang), qml-demo-shell works
<alf_> greyback: so unity8 must be causing something (upstart?) to crash
<greyback> alf_: which is bizarre, but could he happening. I'll see if I can reproduce.
<greyback> alf_: will make working on this bug that little more frustrating too :(
<alf_> greyback: btw, with qml-demo-shell I mostly get blank (black) snapshots on the left
<greyback> alf_: tap it. That'll refresh the snapshot
<greyback> first snapshot taken too early, hence black
<alf_> greyback: hmm, it seems that I always get a black rectangle "over" the snapshots. I see a couple of line from the snapshot and then a black rectangle
<greyback> alf_: let me update my device and try it. For me, I get the whole snapshot (smaller though)
<alf_> greyback: ok, I got what happens... when I start a second up a new black rectangle appears
<alf_> greyback: I will stick to one app for now
<greyback> alf_: have you enough info to proceed? Can I help/simplify the demo?
<alf_> greyback: It should be OK for now, I can reproduce the upside-down problem. I will let you know if I need something more, thanks!
<greyback> alf_: very well, best of luck!
<kgunn> alf_: welcome back...and thanks for hopping on the weird one
<alf_> kgunn: thanks, and happy new year :)
<anpok> kdub: I am following you suggesting to make these utilities as transparent wrapper class
<anpok> why did you suggested mir::geometry? I would think mir::graphics would be a better fit.
<alf_> kdub: it turns out what you are seeing on Nexus 7 is related to https://bugs.launchpad.net/mir/+bug/1263741 . When we snapshot we occasionally get an OUT_OF_MEMORY error and give back stale data.
<ubot5> Ubuntu bug 1263741 in Mir "Some snapshots on Nexus10 upside-down" [Critical,Triaged]
<kdub> interesting
<kdub> the plot is thickening then
<kdub> i think there's some interference between the compositor thread and the snapshot thread somehow
<alf_> kdub: according to GL docs after an OUT_OF_MEMORY error all bets are off (the state of the GL becomes undefined)
<alf_> kdub: do we have a bug for the n7 issues?
<kdub> alf, yeah, one min
<kdub> alf_,  i think a robust solution here would just be to
<kdub> let the mg::Buffer provide the pixel data in a native way (on android, this would be to map the ashmem buffer)
<kdub> then we avoid all the GL headaches
<kdub> alf_, https://bugs.launchpad.net/mir/+bugs?field.tag=nexus7
<kdub> oops https://bugs.launchpad.net/mir/+bug/1238695
<ubot5> Ubuntu bug 1238695 in Mir "unity8 display flickers and stops responding on Nexus 7 (grouper)" [High,In progress]
<alf_> kdub: do we have access to any debugging information from the driver?
<kdub> eh, not too much.. it just seems that the n7 will give a GL_OUT_OF_MEMORY from glEGLTargetTexture2D when trying to use the EGLImage as a texture (when the texture is tied to the fbo)
<kdub> i think that mapping the ashmem buffers is more robust for android
<kdub> let me see if i can do a survey of how sf does this
<alf_> kdub: yeah... unfortunately the desktop still needs this (we can't map the hardware buffers)
<kdub> well, thats okay though
<alf_> kdub: (can't map and read linear pixel information)
<kdub> that would just be how the mesa platform does the pixel read operation
<kdub> and the android platform would map
<alf_> kdub: the original intention of pixelbuffer was for each platform to provide its own implementation, but the GL one seemed to work well until now, so there was no need for it
<kdub> seems there's a need now, if just to improve robustness/memory considerations
<kdub> alf_, do you have any insight on the nexus 10 upside down thing?
<kdub> maybe it just fails with OUT_OF_MEMORY and then just keeps flipping the pixel buffer
<alf_> kdub: yes, on error it gives out the previous data
<alf_> kdub: which get flipped again
<kdub> right
<alf_> kdub: we either need to provide 1. platform specific pixelbuffer implementations, or 2. go the fix-1238695 way, changing mg::Buffer to know how to provied the data itself
<kdub> alf_, i prefer the first one, still poking around to see how others get at the pixel data
<alf_> kdub: +1 for (1). Let me know how you get on with it. Perhaps we could save time if I take care of the infrastructural part so you only need to take care of the Android implementation?
<kdub> okay, cool. my initial instinct is that i'd have a mga::PixelBuffer::PixelBuffer(mg::Buffer) and leave the interfaces for Buffer/PixelBuffer alone
<alf_> kdub: Why is the buffer needed in the constructor (vs the current PixelBuffer::fill_from(mg::Buffer))?
<kdub> I guess that could work too, so PixelBuffer would take the platform in its constructor, and then use a platform-specific way to fill the pixels
<alf_> kdub: I was thinking something along the lines of PixelBuffer Platform::create_pixel_buffer(), so that the implementation is completely internal to each platform
<kdub> i'm okay with that too
<alf_> kdub: ok, I will work on that tomorrow then, and we can discuss more when we have something concrete
<kdub> sounds good
<anpok> what files do I have to touch for an ABI break - I found src/client/CMakeLists.txt
<anpok> do I need to change something in debian/?
<kgunn> anpok: one moment...
<kgunn> anpok: digging out a mail that outlines it...
<Saviq> kgunn, hey, we'd need someone Mir to look at https://code.launchpad.net/~allanlesage/unity8/indicator-stubs/+merge/192059/comments/464049
<thomi> Saviq: so I agree that there's a bug somewhere in autopilot or (more likely) python-evdev - it seems that perhaps the device resources aren't being deleted. HOWEVER, we're only seeing that because we need this nasty workaround due to the bug in mir
<Saviq> kgunn, we've worked around bug #1238417 some time before, but that workaround seems to be limited to a certain number of tests
<ubot5> bug 1238417 in Mir "Unity does not process events from evdev device created before unity is restarted (autopilot tests)" [Critical,Incomplete] https://launchpad.net/bugs/1238417
<Saviq> thomi, yup
<thomi> Saviq: kgunn: IIRC, pitti looked at this, and said soemthing along the lines of "mir uses inotify to detect new device nodes, which is the wrong way to do it" - I believe he said the correct way was to use the evdev library instead?
<Saviq> thomi, I've tried del'ing the device before creating a new one, but with GC it probably never really kicked in
<Saviq> thomi, yeah, but if the device node is already there... how would that explain what we're seeing?
<thomi> Saviq: I suspect that python-evdev doesn't close the device when you delete the python object. I could spend time looking into that, but we'd still have the problem in mir
<Saviq> thomi, +1
<thomi> and we'd still need the ugly workaround in the test suite
<Saviq> thomi, if it wouldn't pick up existing devices, it wouldn't pick up the real ones (touch) in the first place?
<thomi> Saviq: it picks up existing devices just fine
<Saviq> thomi, yeah exactly, and the *first* test in a unity8 autopilot run completes, so it detects a new one as well
<Saviq> thomi, so that doesn't seem to explain why it wouldn't pick up an existing one after it's restarted once
<thomi> the problem is that when the inode is created, mir gets notified, but at that stage the evdev rules haven't been applied yet, so we don't have write permissions
<thomi> so mir fails to open the device, and never tries again
<thomi> if we switched to using the correct library to detect new device nodes, we'd get notified at the correct timne
<thomi> *time
<Saviq> thomi, the inode is only created once per autopilot, though, isn't it?
<thomi> Saviq: no, it's created once every time you create the input device
<thomi> so without the workaround, it's once per AP process run. With the workaround, it's once per test
<thomi> the latter case is causing the second, related issue
<Saviq> thomi, yeah exactly, so if it would be permission problems, no tests would work (or actually we should see the first test failing, and subsequent ones passing)
<thomi> Saviq: no, because usually the device is created before the SUT starts, which gives it enough time to get set up properly
<thomi> so under normal situations, this works fine
<Saviq> thomi, ok, so why does the second test fail? permissions are stable then?
<Saviq> thomi, sorry if I'm being daft, I just want as many details as possible
<thomi> (I'm guessing here) because with the workaround creates a new device per test
<Saviq> thomi, so you think inotify is triggered
<Saviq> thomi, so basically the first device created somehow gets stale
<thomi> Saviq: so at this point I'm guessing... we need someone from the mir team to look at this. The fact that pitti looked at it and came back pretty quickly with both a problem description & potential solution indicates to me that we know what the issue is, we just need to fix it
<Saviq> thomi, sure, just wanted to understand some more
<kgunn> phew...ok anpok sorry...decided to just send you a clean set of instructions...
<kgunn> let me know if that doesn't clear it up
<thomi> Saviq: so if you don't get nay joy from the mir team, you can explicitly close the uinput device before creating a new one
<thomi> Saviq: it seems that python-evdev doesn't do that for you
<Saviq> thomi, I *think* I tried that
<thomi> Saviq: but that still doesn't fix the underlying issue, but it *should* make your tests pass again :)
<Saviq> thomi, but yeah, will push for a fix anyway
<thomi> Saviq: calling 'my_device.close()' ?
<kgunn> racarr: can i come at you from left field to ask if you can potentially help fix this ^
<Saviq> thomi, it was before Christmas, so...
<kgunn> thomi: i assume this is what you were going to ping me about ?
<thomi> kgunn: yup :)
<anpok> https://bugs.launchpad.net/mir/+bug/1237784
<ubot5> Ubuntu bug 1237784 in Mir "[enhancement] Please move input detection to libudev" [Low,Triaged]
<anpok> ^ that change?
<anpok> kgunn: thank you
<kgunn> racarr: seems we have "disappearing input" https://bugs.launchpad.net/mir/+bug/1238417
<ubot5> Ubuntu bug 1238417 in Mir "Unity does not process events from evdev device created before unity is restarted (autopilot tests)" [Critical,Incomplete]
<kgunn> and yes...it could be related to the bug you just posted anpok
<Saviq> whoa that's a nice bunch of bugs that could get squashed with this
<thomi> kgunn: that sounds like *exactly* what pitti suggested as well
<Saviq> thomi, it's pitti's bug ;)
<thomi> Saviq: oh, well...
<kgunn> i would hope he sounds like himsel
<thomi> no wonder then :)
<kgunn> f
<kgunn> :)
 * thomi needs more coffee, brb
<kgunn> racarr: actually...after reading thru pitti's bug again...is this something RAOF  may want to be doing as he was tearing up subfloor on the input stuff
<kgunn> i'm not familiar enough...but this looks like it might be a chunk of work
<kgunn> (not a matter of tracking down a simple bug ...)
#ubuntu-mir 2014-01-08
<RAOF> You know, I wish I could have Mir on one monitor and X on another...
<kdub> kgunn, that palatable workaround for the n7 works on all my devices, so I posted it for review
<kgunn> kdub thanks!
<RAOF> Come for the feature addition, stay for the âhmm, that could really use a refactorâ :/
<duflu> RAOF: You're not selling it
<Sarvatt> RAOF: do you work for intel now?
<RAOF> Sarvatt: No, but I'm making sure my work-habits will be compatible if I do :)
<Sarvatt> who needs to backport anything to a stable release? :P
<Sarvatt> lol
<RAOF> Oh, right. Our cross build support is broken in the presence of pkg-config. Huzzah.
<RAOF> Ah.
<RAOF> Which is why we reimplement it for all the libralies.
<duflu> Speaking of Intel, keithp is in town and apparently giving a talk on zero-copy compositing this week. Pity I'm not registered, come to think of it
 * duflu -> lunch
<RAOF> It'll be on the intarwebs.
<Sarvatt> havent heard about recordings, only livestreams :(
<Sarvatt> otherwise why am i up at 12:30 watching anholts lca talk on http://timvideos.us/
<RAOF> Sarvatt: Oh, is anholt on now?
<Sarvatt> RAOF: http://timvideos.us/gentilli
 * duflu wonders with so mean livestreams how much work will get done today
<duflu> (by himself)
<duflu> -mean +many
 * duflu also wonders why "mean" is in muscle memory
<duflu> Ugh, 7ms round-trip on N7 :(
<duflu> And seemingly even longer latency between compositor schedule and composition starting
<duflu> I blame the kernel 3.1 we have on the N7
<RAOF> Where does the 7ms round trip come from?
<duflu> RAOF: mirping
<duflu> Doing the smallest, lightest, operation I know of
<RAOF> Also, damn annoying stupid partial-armhf-mostly-working-stupid-annoynig-annoyance.
<RAOF> 7msec seems huge.
<duflu> RAOF: It's not terrible. Certainly better than the kernel of only a few years ago. And if we're smart about pipelining then it won't be a big issue
<duflu> Although I suspect we can do significantly better than we do now
<duflu> Because it takes at least 2 context switches for an input event to reach the client, and then at least 2 more for the resulting change to reach the screen
<RAOF> Ok. What would it take to requrie an *actual* armhf chroot to cross-build Mir?
<anpok> duflu: /o\
<duflu> anpok: ???
<anpok> a nothing .. just reading through and older geometry::PixelFormat-removal MP
<anpok> s/and/an
<duflu> anpok: Well, one type is better than N>1
<duflu> Even if that one type is suboptimal in some use cases
<duflu> Although I don't think that's true right now
<anpok> ah back then those types were two separate enum..
<didrocks> kgunn: Mir releasing as we speak FYI :)
<kgunn> didrocks: thanks much! a nice coordinated effort once more :)
<didrocks> kgunn: yeah! ;)
 * ogra_ hugs didrocks 
<ogra_> (and hopes it wont take 5 weeks anymore in the future with the new CI infra to get a commit show up in the image)
 * didrocks hugs ogra_ back
<didrocks> ogra_: well, as soon as we finished the pilot programm, I'm sure the Mir components will be in it
<didrocks> (and so platform-api as well)
<ogra_> yay
<ogra_> bug 1258056 had its actual commit into devel on dec. 6th ... its just hilarious the process takes so long
<ubot5> bug 1258056 in Mir "nested mir on android fails on galaxy nexus" [High,Fix released] https://launchpad.net/bugs/1258056
<ogra_> such a fix shouldnt take more than a week or two
<mterry_> ricmm, so image 119 will have new Mir!  That means the libhybris patch should be the last thing blocking nested mode
<ogra_> mterry_, didnt the hybris fixes land long ago ?
<ogra_> i thought the Mir stuff was the last bit
 * ogra_ is actually waiting with your branch in hands since monday to finally land it :)
<ogra_> (tapping my feet)
<mterry_> ogra_, tell me about it
<ogra_> heh
<mterry_> ogra_, to my knowledge, the hybris fix is still waiting to land in trusty.  Not sure why exactly
<ogra_> hmpf
<mterry_> ricmm, what's the blocker to landing the hybris fix?
<ogra_> do you know who handles that ?
<mterry_> ogra_, ricmm
<mterry_> ogra_, he had a fix at the sprint in London
<ogra_> ah
<ricmm> mterry_: manpower
<ricmm> mterry_: today by EOD
<ricmm> I dodnt have a fix i had the idea of what was wrong, ultimately the fix is a bit different
<ricmm> just havent had time to sit down with it, ill do that today
<ricmm> so ogra can land it all tomorrow
 * ogra_ hugs ricmm 
<ricmm> can you tell him that when he returns?
<ricmm> i need to grab some foods
<ogra_> sure
<ricmm> (:
<ricmm> thanks
<ogra_> mterry_, in case you missed it, ric said he will have the code ready for me so i can land it tomorrow
<ogra_> (he asked me to forward that to you)
<mterry_> ogra_, thanks!
<mterry_> ogra_, I did miss it
<ogra_> yeah, you seem on and off
<mterry_> ogra_, yah  :(
<ogra_> freezing bits in the pipe ? :)
<mterry_> ogra_, I am trying to install a modified final image zip manually onto my mako, but my changes don't seem to be getting through once I flash.  Do you know any trick to it?  Like, is there an md5sum somewhere I need to update?
<ogra_> hmm, no, flashing the zip should be enough
<ogra_> how did you modify it ?
<mterry_> ogra_, I added some debugging output to a qml file
<mterry_> ogra_, inside the zip, there was a tar.gz, and I modified the files in that
<ogra_> byond that its the normal rootfs ?
<mterry_> ogra_, yeah
<ogra_> hmm, i think that should work, though not sure, sisnce we use gpg signatures nowadays ... but i'm not sure we do on that level, stgraber should know
<ogra_> (i would just modify the file on disk though)
<mterry_> ogra_, problem is I'm trying to debug first boot
<mterry_> ogra_, and I don't know a better way to get in there.  Do you?
<ogra_> not really
<mterry_> Well, I'll put this down for now and test my nested branch with newest Mir stack
<ogra_> ask stgraber how to better modify the zip
<ogra_> he surely knows
<mterry_> ogra_, OK
<kgunn> kdub: you gonna address alan_g's comment on arbitrary casting of ints to pointers comment on your fix for the snapshot flickers ?
<kgunn> or should i just top approve?
<kdub> should have been addressed
<kdub> r1317 in that branch
<kgunn> kdub: ack....my bad (my bad eyes missed it)
<anpok> do we have a new ci problem? the last two mp failed for the same unit test
<RAOF> robotfuel: What would I need to do to get an armhf schroot on the CI hardware?
<kgunn> anpok: can you repro at all locally ? (e.g. repeat run an insane # of times)
<robotfuel> RAOF: The builder?
<RAOF> robotfuel: That'd do, I think.
<robotfuel> RAOF: can you link to the failed job?
<RAOF> robotfuel: The basic problem is that setup-partial-armhf-chroot has fundamental limitations that I'm running into.
<anpok> kgunn: not today.. the n10 refused to charge, I put it on a different wall charger.. currently shows only the battery icon
<robotfuel> RAOF: we are building arm natively
<RAOF> robotfuel: Oh, I don't want access to the builder. I want the android tests to be run in a *real* armhf chroot, rather that the bailing wire and twine that we currently use.
<robotfuel> RAOF: the android tests are being run on the phones
<RAOF> robotfuel: So if I removed cross-compile-chroot.sh from the tree that *wouldn't* break CI?
<kgunn> anpok: so, there was one bad mako when alf_ was looking into ci troubles before break...when that was taken out of cycle
 * RAOF doesn't intend to remove cross-compile-chroot.sh, but boy would it be nice to thorourghly break it.
<kgunn> it self corrected....it'd be interesting to see if its the same unit running
<kgunn> those ci tests
<kdub> RAOF, i wouldnt object to removing it
<robotfuel> RAOF: we are building on Calxeda and then running the tests on the phones
<RAOF> robotfuel: https://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/565/console suggests otherwise?
<kgunn> anpok: are you talking about failure on this jenkins run https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/226/console
<anpok> yes
<robotfuel> RAOF: that seems to be new, that is a pbuilder
<anpok> one was kdubs screenshot fix, the other one was the removal of a android lib in the mir source..
<RAOF> kdub: I wouldn't actually remove it, but I would replace it with something that uses a real armhf chroot, so we don't have to do all the munging. (And adding a udev dependency dramatically increases the amount of munging required)
<anpok> so both on the .. android gpu test.. let me look again
<anpok> ndroidGPUDisplay.gpu_display_ok_with_gles
<anpok> C++ exception with description "error posting with fb device" thrown in the test body.
<anpok> if I can trust the battery indicator... it is now fully charged..
<anpok> and starts
<anpok> will try
<kgunn> anpok: just fyi...you can find the specific device name in the console output
<kgunn> in this case it was device
<kgunn> mako-04cb53b598546534
<robotfuel> https://jenkins.qa.ubuntu.com/job/mir-mediumtests-trusty-touch/206/console shows that an arm(calxeda) server built the packages
<robotfuel> RAOF: ^
<kgunn> alf_:  curious if this is out special friend mako-04cb53b598546534
<kdub> it just looks flaky to me
<kdub> tested on my device here, seems it doesnt get to gtest_repeat=10
<robotfuel> kdub:  it failed on mako-0090f741e3d141bc
<robotfuel> oops kgunn^
<RAOF> robotfuel: So, I'm trying to fix all the failures of https://code.launchpad.net/~raof/mir/mockable-udev/+merge/196824/comments/466002 . There is an actual problem there, which I can fix, but I can't fix the first failure in a sane way without requiring a real armhf chroot for that test.
<kgunn> anpok: on your comment about "pick just one"...i'm confused...what do you mean ?
<kgunn> anpok: ah...nvmd
<kgunn> one currently
<kgunn> got it
<robotfuel> RAOF: Ah I was looking at the latest failure my bad
<robotfuel> RAOF: I am not sure about the pbuilder, fginther can get you access
<kdub> so it looks like something is failing, i can reproduce about 1/10 times on my device with that test case
<RAOF> robotfuel: I don't need access (unless it's to persistently change the machine's configuration); I need a change in the build environment.
<RAOF> robotfuel: Or, I guess, for us to drop that test run? Is it covering anything not covered by the other tests?
<kdub> well, with gtest_repeat it fails, but thats almost expected... let me see how its running on the device...
<robotfuel> RAOF: that has to be changed by the CI team, I don't know if they are using that pbuilder for other builds.
<robotfuel> fginther: ping ^
<fginther> robotfuel, RAOF, I was trying to follow, but I don't know exactly what the issue is
<RAOF> Actually, if we've got a bunch of Caldexa nodes, why are we even doing that armhf build on i386?
<fginther> RAOF, which build?
<fginther> do you have a link to a job?
<RAOF> http://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/565/console
<RAOF> (From https://code.launchpad.net/~raof/mir/mockable-udev/+merge/196824/comments/466002)
<robotfuel> fginther: the mir-android-trusty-i386-build
<fginther> RAOF, that's an intentional cross compile job (setup ages ago by mmrazik). If you go to the parent job, you'll see that there is a separate job to run on a calxeda node: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-armhf-ci/344/
<robotfuel> RAOF: it looks like vera++ needs to be added to the debian control as a build requirement for it to pass on mir-android-trusty-i386-build
<RAOF> robotfuel: And libudev; but setup-partial-armhf-chroot.sh can't work properly with libudev.
<robotfuel> RAOF: unless we can ignore the error "vera++ not available - disabling make target style_check"
<RAOF> We do ignore that warning, yes. :)
<RAOF> (Because libudev the first library we use that lives in /lib rather than /usr/lib)
<RAOF> So, if we're already building and running the tests on android-armhf, is there any value in an explicit cross-compile test run?
<robotfuel> RAOF: if we are telling people they can use an armhf pbuilder to build armhf builds in the documentation it is worth having. Other than that no.
<fginther> RAOF, that would be up to the mir team. If the job is no longer needed, we can remove it.
<anpok> kdub: how do you run the test cases on the device? mir/partial-armhf-chroot/usr/src/gmock/gtest/include/gtest/internal/gtest-port.h:1340:: pthread_mutex_lock(&mutex_)failed with error 22
<RAOF> robotfuel: I'll fix up the cross-compile-chroot.sh to setup and use an armhf schroot, so that'll still work.
<anpok> thats what I got with current devel.. a few weeks older binaries dont behave like that
<kdub> anpok, i'm not seeing that with what I just built
<anpok> thats a failure in gtest
<anpok> i am obviously doing something horribly wrong
<RAOF> fginther: Ok. I'll poke mir-devel@ to see if anyone is attached to that particular build.
<kdub> anpok, if you're cross compiling, try compiling with the script
<kdub> and if it is with the script, try regenerating the partial chroot the script makes
<kdub> if your cross compile toolchain and the stl on the device get of sync, i've seen that cause problems before
<anpok> ah, thank you.
#ubuntu-mir 2014-01-09
<RAOF> Ah, of course. *That's* why you don't do a compile in an actual armhf chroot.
 * RAOF apparently has an xorgRootess
<duflu> RAOF: +l ?
<RAOF> No; typo :)
<duflu> +Mir ?
<RAOF> But it seemed like a funny typo.
<RAOF> This *should* work, and be rootless...
<penk> hello, I'm installing unity-system-compositor & xmir on amd64 trusty, everything seems running fine under /var/log/lightdm, but the screen is blank.. any idea?
<penk> # tarball of log https://mega.co.nz/#!hMxD1ArC!e7AevxbOyidBBaZZAlXP7SoZdkMlT8b7Qzi3dDel2OI
<duflu> penk: I can't see any reason in those logs. Could you please "ubuntu-bug unity-system-compositor" ?
<penk> duflu: sure I'll get to that
<duflu> penk: Everything works without unity-system-compositor?
<penk> duflu: yes, with radeon driver
<duflu> Hmm, I should revive my radeon machine and update it
<penk> duflu: I can hear the lightdm sound, but the screen is black
<duflu> penk: Is the monitor LED showing it's asleep (like orange instead of green)?
<penk> duflu: I'm pretty sure the screen & system is awake
<duflu> penk: So you can see the backlight is on, but pixels are black?
<penk> duflu: exactly
<duflu> penk: When you can, please try "Ctrl+Alt+F1". Can you reach the VT that way? Also please try installing mir-demos and running "mir_demo_client_egltriangle". Does it appear on top of the blackness?
<penk> duflu: vt switching is working
<penk> duflu: sometimes the compositor gives me VT I/O error though
<penk> duflu: I'll try mir-demos later
<duflu> That's probably not cool
<penk> duflu: I see mir_demo_client_egltriangle running on the screen
<duflu> penk: Cool. Then the bug is just XMir. Please log it against that project
<penk> duflu: got it, thx
<duflu> Now showing in a browser near you: http://timvideos.us/wool
<anpok> duflu: what is shown next?
<duflu> anpok: Too late I think ... http://linux.conf.au/programme/schedule
<anpok> oh zero copy composition
<anpok> kdub: I could not reproduce the error, but hey got a different one instead - mir_integration_tests fails to create a fb
<duflu> That's OK. Keith being Keith only talked about X. And when asked about something other than X (Wayland) he said he wasn't interested. And had nothing to say
<anpok> hehe
<alan_g> duflu: @bug 1239955 on CI - have we asked #ubuntu-ci-eng if they can poke the hardware?
<ubot5> bug 1239955 in Mir "integration-tests hang/fail in AndroidGPUDisplay.gpu_display_ok_with_gles when the display is asleep: what(): error posting with fb device" [Medium,Triaged] https://launchpad.net/bugs/1239955
<duflu> alan_g: Assuming it's the same cause. There might be other triggers...
<anpok> on n10 that test always fails for me
<anpok> but with a different exception
<anpok> here gralloc is queried for a framebuffer_device_t, a pixel format is taken from that structure
<anpok> the pixel format is RGBA_8888
<anpok> but the no EGLConfig that is querried matches that visual id
<anpok> the most similar one is BGRA_8888
<anpok> the other thing I noticed was that whenver i run the tests in order the display is turned off around that test..
<anpok> seems like the tests before that one cause that in some way?
<anpok> forget the last two statements - just some buffers are flipped where two of the three are black. display is not turned off..
<alan_g> duflu: it isn't just the one device. The difference seems to be they moved to trusty-proposed 119 today. Gonna try that here.
<duflu> Fair enough. We don't have much device-specific code
<alan_g> alf__: I'm not sure what to try next with bug 1239955 (which is blocking CI) - any suggestions before I MP disabling the test?
<ubot5> bug 1239955 in Mir "integration-tests hang/fail in AndroidGPUDisplay.gpu_display_ok_with_gles when the display is asleep: what(): error posting with fb device" [Critical,Triaged] https://launchpad.net/bugs/1239955
<alf__> alan_g: @"Initially I saw intermittent failures if unity8 wasn't stopped", is unity8 not being stopped while running our tests in CI?
<alan_g> alf__: it is stopped - I've checked
<alf__> alan_g: does "sudo powerd-cli display on bright &" make any difference locally?
<alan_g> alf__: yes. Seems to work as well as the power button
<alan_g> alf__: revise that - still failing intermittently
<alf__> alan_g: no more ideas off the top of my head
<alan_g> alf__: OK I'll MP disabling the test as a workaround.
<anpok> alf__: do you have a nexus10?
<alf__> anpok: yes
<alf__> anpok: ?
<anpok> do the integration tests run for you on the device?
<alf__> anpok: haven't tried recently... do you want me to?
<anpok> it would be nices
<anpok> -s
<anpok> because I dont think that my issues are hardware related
<alf__> anpok: ok
<anpok> I believe that the egl config selection needs a different logic
<alf__> anpok: ok, so should I just run the integration tests from development-branch or do you need some special branch/config?
<anpok> just that
<anpok> or even just limit to the AndroidGPUDisplay.* tests
<alf__> anpok: I get "could not select EGL config for use with framebuffer"
<alf__> anpok: for gpu_display_ok_with_gles
<anpok> me too
<anpok> it happens because we try to select an egl config with the same "visual id" as the one mentioned in the framebuffer_device_t
<alf__> anpok: I am not familiar with what visual id means for Android, but on the desktop it's not directly related to a pixel format
<anpok> hm it seems like on android it matches the pixel format integer found in system/graphics.h
<anpok>     HAL_PIXEL_FORMAT_RGBA_8888          = 1,
<anpok>     HAL_PIXEL_FORMAT_RGBX_8888          = 2,
<alf__> anpok: it seems because our code checks for it or because you found some reference of that fact elsewhere? :)
<anpok> our code checks for it :)
<anpok> .. and the values seem to make sense
<anpok> so docs would be awesome :)
<alf__> anpok: if a print out the id values I get: http://paste.ubuntu.com/6720922/ (which supports this)
<anpok> yes
<alf__> anpok: so we are looking for RGBA8888 but nexus 10 provides BGRA8888
<anpok> or RGBX for the frame buffer
<anpok> I wonder if is necessary to have an exact match here
<anpok> I guess that code path is only used in the unit tests..
<anpok> s/unit/integration
<anpok> hm the android gl_context could also make use of the surfaceless context class
<alf__> anpok: the framebuffer_device_t reports that it uses RGBA8888 but Nexus 10 doesn't seem able to render to it. As you said this is the fallback (non-HWC) path, which Nexus 10 probably won't ever need to use.
<anpok> ok if a different one is picked posting silently just fails
<kgunn> racarr: anyway...the more i thot about the autopilot input prob thomi & Saviq were talking about....
<kgunn> i got confused..
<kgunn> is it really the at the events go missing ?
<racarr> it soundslike the device
<kgunn> or is it just that the restart causes mir to get confused b/c the "rules" aren't realy changed...even thos inotify says ok?
<racarr> doesntget probed properly
<kgunn> ...or are there really 2 problems both there
<kgunn> racarr: ok...so more that latter
<racarr> mm I think so
<kgunn> someone (i think thomi) was scaring me that we had a 2nd prob of events going missing (even after proper probing)
<alf__> racarr: is something "eating" your spaces and apostrophes or it it just quick typing?
<alf__> is it
<kgunn> i'm quessing an old tea spill on the space bar
<racarr> alf__: Space key eaten mostly
<racarr> via tea yes lol
<kdub> robotfuel, where can i find the script that sets up the phone on CI?
<robotfuel> kdub: pulling it up now...
<kdub> thanks
<robotfuel> kdub: lp:~chris.gagnon/+junk/mir-medium-test-runner-for-jenkins
<robotfuel> kdub: http://s-jenkins.ubuntu-ci:8080/view/Mir/job/mir-mediumtests-runner-mako/configure if you need more info
<kgunn> kdub: fyi...i was gonna try the fab-4 integration tests...since its now in archive, will likely ressurect the kill surfflinger topic as soon as i have confidence
<kdub> not sure what that means :)
<kdub> like, remove sf from the image?
<kgunn> kdub: well...at least stop having it available for unity8....only as a tool for bringup
<kgunn> meaning, we won't be putting effort in maintaining unity8 code
<kgunn> which enables surf flinger
<kgunn> to be reliably used
<ogra_> kdub, mainly drop the ability to run it
<ogra_> as i understood (as a plumber)
<kdub> right, sounds okay to me
<brainwash_> is it possible to enable hardware cursor manually when using XMir? why is it still not supported, any reasons?
<kgunn> alf__: ^ if you're on
<brainwash_> I really would love to use XMir, but a slow/laggy mouse cursor is a no-go
<kgunn> brainwash_: right, thanks for trying xmir and using...just a matter of effort really, we've shifted our focus towards
<kgunn> building out features around tablet/unity8 shell
<kgunn> since xmir didn't make it in by default...the way
<kgunn> scheduling lines up wrt releases etc
<brainwash_> so XMir gets abandoned slowly?
<kgunn> it makes more sense for us to pour it on for unity8-mir & "rootless" x on unity8-mir
<brainwash_> rootless like xwayland, right?
<kgunn> brainwash_: not abandoned per se, but feature stagnant
<kgunn> brainwash_: rootless will leverage a lot of what was done in mir
<kgunn> oops/mir/xmir
<brainwash_> alright, but I'm still interested if hardware cursor support is possible :)
<kgunn> brainwash_: was trying to hail someone smarter than me :)
<kgunn> brainwash_: depending on your timezone...if you pop in say in about 8 hours or so...you'd get a better answer
<kgunn> when the australs come onlien
<kgunn> online even
<brainwash_> alight, I'll setup my server then and rejoin with my irc bouncer, so I'll don't miss the answer, thanks :)
<kgunn> brainwash_: sorry i wasn't better help...
<kgunn> again thanks for trying out xmir
<mterry_> ricmm_, poke about libhybris
<ricmm_> mterry_: wip
 * kgunn hugs ricmm_ 
<kdub> rsalveti, are you okay with https://code.launchpad.net/~kdub/mir/less-3rd-party/+merge/199851
<kdub> basically making mir a dependency of android-headers
<rsalveti> hm, lemmecheck
<rsalveti> kdub: looks good
<kdub> cool, thanks!
<kdub> *making mir depend-on android-headers, rather
<RAOF> brainwash_: Yeah, HW cursor support is possible & needed.
<RAOF> brainwash_: It'll get done before we're done, but with phone/tablet being the current focus for Mir development it's understandably lower importance :)
<RAOF> brainwash_: On the other hand, it could get done sooner if you wanted to do it :)
<brainwash_> RAOF: so it's not a trivial thing :/
<RAOF> Oh, it's reasonably simple.
<brainwash_> on top of that, I lack the knowledge to implement this
<RAOF> For those not watching #wayland, http://www.anandtech.com/show/7641/amd-demonstrates-freesync-free-gsync-alternative-at-ces-2014, is super-cool.
<kgunn> yeah.. RAOF that is pretty cool
<kgunn> and giving it away...hmmm
<RAOF> Apparently available on all recent AMD GPUs, too.
#ubuntu-mir 2014-01-10
<Sarvatt> RAOF: also laptop only
<RAOF> Sarvatt: Doesn't appear to be explicitly laptop-only?
<RAOF> Or, rather, there doesn't seem to be any reason external displays couldn't implement the same thing.
<Sarvatt> http://techreport.com/news/25878/nvidia-responds-to-amd-free-sync-demo
<Sarvatt> it'd need a new scaler in the monitor which is what gsync is
 * RAOF is not entirely sure why external displays have scalers in them anyway.
<RAOF> So that could be pretty simply solved :P
<RAOF> New question: why does Intel allocate the root window differently, in a way that fails, when I pass -rootless? To the gdbatron!
<RAOF> Oh, right.
<RAOF> Because it turns out that Intel doesn't allocate 0x0 pixmaps in VRAM.
<RAOF> Who knew?!
<RAOF> Dear X damage: WTF?
<duflu> RAOF: Inaccurate damage reports?
<duflu> Racey?
<RAOF> Curiously offset.
<duflu> Oh, fun
<RAOF> Apparrently by screen_x, screen_y.
<RAOF> So the damage region comes out as (-230, ...) â (214, ...)
<duflu> RAOF: Cos Mir has your screens at different locations to where X thinks? :)
<RAOF> No; apparently because COMPOSITE interacts strangely with damage.
<duflu> I do recall thinking I had Compiz damage handling theoretically water tight, and then seeing bugs on random occasions
<RAOF> Well, that would have been asynchronous.
<RAOF> Making everything significantly more difficult.
<duflu> Yes, being outside the server did pose the biggest hurdles
<duflu> But my Ubuntu desktop doesn't look /too/ broken right now :)
<RAOF> Hm. Am I using a version of Mir that's unable to service requests from two windows at the same time?
<RAOF> Grr. Is it just me, or is the msg-processor-report roughly useless?
 * duflu hasn't used it
<RAOF> Bah! It *is* Mir failing to send me buffers again.
<RAOF> I mean, I'm also doing things wrong, but Mir is definitely doing them wrong as well. Bah.
<didrocks> RAOF: shared guilt? :)
<didrocks> hey RAOF ;)
<RAOF> didrocks: Yo!
<RAOF> Well, I'm merely crashing the X server when I try and start xterm. Mir is failing to let me draw anything!
<didrocks> ah, annoying right :)
<duflu> Dear gcc, You still suck at C++ error messages
<janimo> is this spec uptodate? https://wiki.ubuntu.com/Mir/Spec
<janimo> I see it links to QMir in LP which is marked as deprecated  https://launchpad.net/qmir
<alan_g> janimo: I'm not sure what's happening with qmir - sorry. I know kgunn was checking our docs were current recently he may know more. (But is on Texas time)
<janimo> alan_g, thanks. I am trying to learn more about mir/xmir/unity8 and try as much of it as possible out on a regular x86 desktop
<janimo> the unity compositor/xmir part seems to be ok so far (as others have found) on integrated intel GPUs
<alan_g> janimo: AFAIK unity8 uses unity-mir for Qt bindings
<janimo> alan_g, seeing whether I can run unity8  was the next step :)
<anpok> and qt itself uses platform api
<anpok> qt-ubuntu that is
<janimo> I just saw an old (May 2013) video with Unity8 running on a laptop, and was wondering whether that is still possible or it was mostly amockup that has been abandoned
<alan_g> Right. I guess that platform api is preferred over qmir. I'll ask kgunn to confirm before changing the Wiki.
<alan_g> janimo: you're probably better asking on #ubuntu-unity. But my understanding is that it should be possible to get it to work (but it won't, for example, adapt properly to the screen size.)
<janimo> alan_g, just basic working UI without sensor support or other niceties would be enough for now, I'll ask there thanks
<alf__> janimo: The high level picture is unity8 -> qt -> qt-ubuntu -> platform-api -> mir, and also unity8 -> unity-mir -> mir
<alf__> greyback: ^^ please correct me if I am wrong
<greyback> alf__: correct
<janimo> alf__, the former for Android the latter for desktop?
<alf__> janimo: no, both for both
<janimo> alf__, which package provides qt_ubuntu ?
<janimo> the latter sequence is not using qt at all? I am not sure what the two separate path are then (apps vs shell?)
<greyback> janimo: qtubuntu-android I think
<janimo> greyback, does it need some more work for desktop or is it misnamed (android)
<greyback> janimo: the second path exists because unity8 is a mir server. That code path starts up Mir, and exports mir info to unity8 (via unity-mir) allowing unity8 to read window lists and change window placement/management
<greyback> janimo: but unity8 also wants to draw a shell, the dash, launcher, etc. So for that, unity8 also acts just like any other mir client - that's the 1st code path
<greyback> janimo: largely misnamed. It works on desktop - only annoyance is it depends on libhybris which does misconfigure your desktop. I think a patch just landed to qtubuntu to fix that, so there will be a "qtubuntu-desktop" package soon
<janimo> greyback, by mir at the end of both code paths do we mean the unity-system-compositor ?
<janimo> unclear at first site which of those are libraires/daemons or even protocols :)
<greyback> janimo: no, unity8 is an instance of a mir server. It is meant to run with user permissions, only when user logs into their account. U-S-C is another Mir instance, which runs asap at startup, as root user, and is resposible for the login greeter, startup animations and user switching
<janimo> since I understood mir is two libraries (server and client) to build higher level components from, it confuses me when I see a role attributed to Mir
<alf__> janimo: for these paths s/mir/libmirserver/
<janimo> ack
<greyback> mir supports nested servers, so unity8 mir server will be a client of the USC mir server
<janimo> and xmir is only a transitional step, but otherwise it won't be needed on unity8 desktop?
<greyback> yes  - though will be needed for compatibility for exotic toolkits which do not have native support for mir, only X
<alf__> janimo: also note that xmir is moving towards rootless support (being able to run x apps as windows in unity8) instead of the current state which is running a whole X session under mir.
<janimo> alf__, I noticed that. I first ran xmir today, and mostly read docs so far
<janimo> I am more interested in running unity8/mir without the android bits and using mesa, rather than desktop use cases/convergence
<janimo> so tablet like use case but on the free stack
<janimo> this is a subset of the full converge work AFAIK
<ogra_> note that the nested U-S.C and Mir stuff will land on the phone next week (or so... still waiting for a hybris patch to land it)
<alf__> alan_g: anpok: Do you have any (links to) notes from our discussion about hardware layer and related APIs? I was looking at lp:~kdub/mir/db-optimize but I get the feeling that we discussed something slightly different in terms of API (execute-around-method?), but perhaps that was at a higher level?
<alan_g> alf__: someone took photos but I've not got a link
<alf__> alan_g: I think it was kdub :)
<anpok> alf__: we discussed various variants
<anpok> to which one did we settle?
<alf__> anpok: that's what I don't remember :)
<anpok> alf__: there was the topic of locking planes between the start of drawing and the final post
<anpok> i.e. to cover things like, somebody plugs in a monitor and the scan out engine has not enough overlays/planes left ..
<anpok> (provided thats possible at all)
<anpok> i wonder if the interface shouldnt be just: draw(list<buffers_with_transformation>) .
<alan_g> alf__: anpok we settled on Mir being told "draw these" - no holding locks across interactions
<anpok> so it would fallback on its own when necessary
<alan_g> "fallback" being gl compositing? Yes
<alf__> alan_g: anpok: What triggered my concerns was that lp:~kdub/mir/db-optimize introduces the optimize() call which means that we may need to keep state between optimize() and post(). I think I remember some related discussion, but it could be that the discussions were for a higher level, or that my memory is failing me.
<anpok> is display_buffer the interface level
<anpok> yes
<anpok> is that the interface level were that would happen or is there a more higher level interface the shell would ues..
<anpok> it is now in display_buffer::optimize
<alan_g> I don't believe we have a migration path thought out - this is still a couple of items down the backlog. But surely "optimize" and "post" are both part of the "draw these" processing.
<anpok> looking at the interfaces there again, i think display_info should be the place to add draw_these
<anpok> alf__: will make another MP - I would then also eradicate the k-constants. if there is no futher objection
<alf__> anpok: sure
<anpok> I was reluctant because I found two forms of constants.. with the normal variable nameing style, and ALL_CAPS
<davmor2> just had my first lockup on maguro since the new mir landed so I don't know what it changed but it isn't dying anywhere near as often on maguro now well done team :)
<dandrader> alf__, hey, got some spare time to help a mostly clueless guy with "OpenGL in Qt vs EGL in Mir" issues (on the "qml as mir compositor" task)?
<dandrader> my qml compositor is notified about the creation of a client surface. so I create the corresponding qt scene graph and qml item for it, to that is gets displayed on the qml scene
<alf__> dandrader: sure
<alan_g> anpok: ALL_CAPS should be reserved for preprocessing macros
<dandrader> but when I call bind_to_texture
<anpok> alan_g: i agree
<anpok> will include that way then ..
<dandrader> the texture displaying the client surface is there being shown and updating nicely on the qml scene
<dandrader> but all other gl textures used by Qt get borked
<dandrader> the one used to hold fonts is blanked
<dandrader> and the other used to hold an image starts showing the contents of that client mir surface as well
<anpok> is that GL vs GLESv2?
<dandrader> alf__, I could make a video if that would help understanding the situation
<alf__> dandrader: no need, do you have some code I can read/try out?
<dandrader> alf__, I do, but is not so convenient as you need to build and install a couple of repos (a qpa, a specific mir version, install qt 5.2..)
<dandrader> ah, and a specific platform-api as well
<dandrader> alf__, want to try it still? :)
<alf__> dandrader: I would at least like to just quickly check what it is doing :)
<alf__> dandrader: so perhaps not run it yet
<dandrader> alf__, 1- so, install qt 5.2 from that "canonical edgers" qpa, 2- that mir lp:~unity-team/mir/mir-for-qpamirserver, 3- that platform-api lp:~dandrader/platform-api/set_window_dimensions and 4- that qpa lp:~unity-team/mir/mir-for-qpamirserver
<dandrader> alf__, sorry, the qpa is this one: lp:~unity-team/+junk/qpa-mirserver
<dandrader> alf__, then follow the instructions in the README in this qpa-mirserver on how to run the demo shell and client
<alf__> dandrader: ok, I will start by just reading the code and see if I actually built this :)
<dandrader> alf__, ah, and that's on a nexus 10
<alf__> dandrader: btw, how does your work overlap with what greyback is doing?
<dandrader> alf__, its the same code base
<dandrader> alf__, I'm just trying to help him out while he's busy with other work (e.g. side stage, etc)
<alf__> dandrader: ok, mir::graphics::Buffer::bind_to_texture() needs an existing texture to bind the contents of the buffer to, i.e. it doesn't create a texture itself.
<alf__> dandrader: my guess is that in MirBufferSGTexture you need to create a texture (whose id you can then return in textureId()) and bind to that
<alf__> dandrader: so, more or less: glGenTexture() once, and glBindTexture(), Buffer::bind_to_texture()] in MirBufferSGTexture::bind()
<alf__> dandrader: (unless qt provides a better way to deal with raw gl objects)
<alf__> dandrader: see src/server/compositor/gl_renderer.cpp:199
<dandrader> alf__, excelent. makes sense. thanks, I will try it! For me the interaction between EGL and the current OpenGL context in Qt is a really gray area
<dandrader> alf__, so glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, image) acts on the GL_TEXTURE_2D of the currently active texture unit in the current Openg GL context. is that it?
<greyback> alf__: aaahhh, dammit that makes sense
 * greyback kicks himself hard
<alf__> dandrader: yes, on the target the currently active texture unit (i.e. what was last bound with glBindTexture() on that unit)
<alf__> dandrader: don't forget to set attributes of the texture as in gl_renderer.cpp
<dandrader> alf__, ok, thanks!
<alf__> dandrader: hmm, although I see some qt calls in MirBufferSGTexture::MirBufferSGTexture that indicate that perhaps qt can do that for you, provided it somehow gets the texture id from you?
<dandrader> alf__, from my current understanding I think qt expects a QSGTexture (which MirBufferSGTexture extends) to do the texture creation itself. although it might have some kind convenience wrapper, which use should be optional
<alf__> dandrader: I am wondering whether the setFiltering(...) ... updateBindOptions() etc calls in the constructor will have any effect, since the texture is not bound yet at that point...
<dandrader> alf__, AFAIU, they just fill up the internal variables of QSGTexture
<dandrader> like in a simple POD struct
<dandrader> alf__, so that the scene graph might query them later one
<dandrader> s/one/on
<alf__> dandrader: right, but I guess that updateBindOptions() actually applies these values, which will need a bound texture?
 * dandrader checks
<dandrader> alf__, you're right
<dandrader> alf__, thanks for pointing that out!
<alf__> dandrader: np
<ogra_> mterry, FYI, maguro tested and running fine with nested mode, now we just need to get ricmm_ to commit that hybris fix for grouper
<mterry> ogra_, awesome.  I was able to revive my grouper device from what I thought was certain death, so I can test that when it's available
 * mterry gets excited for nested mode to land
<ogra_> good, i can test too ... we just need to clone ricmm_ somehow ... he is swamped i think
<ogra_> or get asac to announce that we drop grouper :P
<ogra_> mterry, bah, spoke to soon, seems i cant wake it up from suspend
<mterry> ogra_, oh no
 * ogra_ reboots 
<ogra_> hmm, now it wakes up but takes nearly 10sec to do so after pressing the button
<dandrader> alf__, problem solved! thanks a lot!!!
<dandrader> greyback, \o/
<ogra_> ... and works immediately on all subsequent presses
<ogra_> this is weird
<greyback> dandrader: woo! thanks alf__ !!
<alf__> dandrader: greyback: great!
<alan_g> alf__: got time to comment on https://code.launchpad.net/~alan-griffiths/mir/expose-rpc-infrastructure/+merge/200879?
<alf__> alan_g: sure, will look in 5'
<ogra_> mterry, hmm, looking with dbus-monitor it seems like the display stays off until there is dbus feedback from NM o_O ...
<ogra_> i reliably see it turning on if the NM response to the resume shows up
<mterry> ogra_, well this branch does move the dbus service that powerd talks to from unity8 to unity-system-compositor...
 * ogra_ wonders how that can be connected 
<ogra_> mterry, well, it looks like the screen only turns on when indicator-network activation happens
<ogra_> which is pretty strange
<mterry> let me see if I see anything similar on manta
<ogra_> might be a coincidence, but it is pretty reproducable
<ogra_> (running dbus-monitor as the phablet user indeed)
<mterry> ogra_, I don't see similar behavior on mako or manta
<ogra_> this is good ...
<ogra_> but on maguro it will bite us in the tests
<mterry> yup
<mterry> :(
<ogra_> (since they fail if unlocking doesnt happen in time)
<ogra_> we had such a thing before (i guess davmor2 remembers) ... but it was fixed inbetween
 * ogra_ tries to find the old bug
<mterry> kdub, are you still well versed in nesting mode concerns?  We're seeing a weird behavior on maguro where the screen doesn't wake up in a timely fashion  ^
<ogra_> bug 1255045
<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
<davmor2> ogra_: if you drop grouper and maguro what the hell do I test on
<ogra_> davmor2, the new flo and mako your manager has sent you before we dropped them ;)
<davmor2> ogra_: but these are both mine that I bought to play with Ubuntu on :'(
<ogra_> mterry, so it seems this patch from duflu fixed it http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/revision/154 ... i wonder if u-s-c needs a similar patch if the screen is now handled through it
<ogra_> davmor2, so you can still do community testing with them
<davmor2> ogra_: When! :D
<mterry> ogra_, yup.  That patch didn't make it to u-s-c
 * mterry whips up a branch
<ogra_> awesome !
<ogra_> that was quick :)
<davmor2> ogra_: what is usc to you? It is Ubuntu Software Center to me :)
<ogra_> not in this channel ;)
<ogra_> unity-system-compositor
<davmor2> ah
<ogra_> everywhere else it is ubuntu-software-center ;)
<davmor2> you can understand my confusion now though right we really need to start thinking more about initials and if the already exist :D
<mterry> ogra_, do you mind giving lp:~mterry/unity-system-compositor/dbus-screen-fix a test?  I'll test on my other devices to confirm no regressions
<janimo> kgunn, hi, which are the new mir integration tests in trusty-proposed? What package?
<ogra_> mterry, will do will take a bit (meeting run for the next 2h now and i have no active arm build env atm)
<mterry> ogra_, OK, will mark it for merge review so jenkins makes a deb
<ogra_> ++
<kgunn> janimo: hey!...yeah...yesterday they were in the devel-proposed image
<janimo> kgunn, I have 121 installe don the n4
<kgunn> janimo: to double check apt-cache policy libmirserver* if you have libmirserver12 installed tests should be there
<kgunn> janimo: well...actually
<kgunn> janimo: you'll need to apt-get install mir-test-tools
<janimo> mir-test-tools itself is not, indeed
<janimo> kgunn, any chance of adding it by default in the image? The use case is network not being available while doing graphics bringup and testing is
<mterry> ogra_, hopefully when you're ready, https://code.launchpad.net/~mterry/unity-system-compositor/dbus-screen-fix/+merge/201211 will have debs
<ogra_> perfect !
<janimo> kgunn, not sure whose call is adding packages to the build. ogra?
<ogra_> janimo, i just add them on request to the seeds (if they actually need seeding, ususally deps just pull things in)
<janimo> ogra_, well I can request adding mir-test-tools but someone else needs to approve such requests I guess
<janimo> and ask for a reasone (which I provided above for this particular request)
<ogra_> kgunn, do they install any upstart job or anything that would make a binary start etc ?
<ogra_> or would thesy just add some extra binaries that arent used by anything
<janimo> ogra_, well they have 5 deps (lttng, libumockdev, liburcu1) so may not be very straighforward from seedin PoV
<janimo> ogra_, but other than that they are a couple of binaries to test Mir client and server
<janimo> ogra_, but it is those deps that make it desirable by default in the image, to avoid installing many debs by hand
<ogra_> janimo, hmm, not sure what the mock pieces might do
<janimo> especially when the image being tested is no longer the very latest and there are newer versions of libmirserver and libmirclient
<ogra_> was long as system behavior doesnt change due to a seed change i'm all fine
<ogra_> read: someone needs to a) run the whole testsuite with them installed and make sure nothing fails
<janimo> ogra_, I'll do that and let you know
<ogra_> b) give me an MP against the ubuntu-touch seed branch
<ogra_> (and c) some manual smoketesting would be nice but not mandatory)
<janimo> ogra_, well the mir tests set up fake DRM devices or various other udev driven environment bits
<janimo> hence umockdev -
<ogra_> right
 * janimo has just grepped the sources
<ogra_> as long as they only do that when invoked by a test and not in the general system thats fine
<ogra_> if they modify (install udev rules) the system in a permanent way we cant just ship it
<ogra_> janimo, given pitti is the umockdev upstream, he can probably shed some light on if it makes sense to ship that stuff by default
<ogra_> he should know the impact
<janimo> ogra_, it's only libumockdev that is depended upon , not the umockdev binary
 * janimo wonders whether a custom build channel devel-devel would make sense
<janimo> devel version of ubuntu with development/testing  related packages added in the image
<janimo> targetting bringup and porting work mostly
<janimo> or even automated hw test setups
<ogra_> janimo, well, i would expect a bringup to be done on a rw image in any case
<ogra_> so the channels wouldnt really help here
<mterry> ogra_, hrm.  With my patch, u-s-c crashes with the "could not activate surface with eglMakeCurrent" error
<ogra_> mterry, i guess we need duflu ... he wrote the original
<mterry> kdub, you around?
<kdub> mterry, otp
<mterry> kdub, ok, no worries.  when you're done, I'd like some talk-through help
<kgunn> janimo: sorry...i am otp to...lost context...you ok? or got other questions ?
<kdub> mterry, ok, done with the call, whats up?
<kgunn> mterry: that looks like the annoying "unity8 took long to shut down..and powerd switched blank on..now mir can't get screen"
<kgunn> mterry: if you do "powerd-cli display on bright" from root on device
<mterry> kdub, so.  For nested mode, I've moved the dbus interface that powerd talks to from unity-mir to unity-system-compositor
<kgunn> it should hold the display on for testing...
<kgunn> obviously....if its not just testing....then yeah, we have a problem
<mterry> kgunn, yeah not just for testing  :(
<mterry> kdub, but a fix went in in the meantime to fix a screen blanking issue on maguro.  I've ported that patch over to u-s-c too, but now I get an error "could not activate surface with eglMakeCurrent".  Here's my branch: https://code.launchpad.net/~mterry/unity-system-compositor/dbus-screen-fix/+merge/201211
<janimo> kgunn, I am ok, just wanted to know what your team thinks of adding mir-test-tools to the default images
<mterry> kdub, now...  can starting a compositor twice be bad?  Should I be guarding those calls to start/stop?
<kgunn> janimo: i'm fine with that idea...kdub ? you ok if mir-test-tools shows up in images ?
<kdub> kgunn, sure, works for me
<kgunn> mterry: kdub ( ricmm_ & greyback to a degree)....i think we need to have a sequence diagram of screen blanking...
<kdub> mterry, with the way mir code is now, start() shouldn't be called twice, i can patch that though
<kdub> kgunn, i agree
<kgunn> we keep suffering either bugs in the product...or annoyances in testing...
<kgunn> kdub: i know you're busy on hwc stuff....
<mterry> kdub, I'm not certain I'm calling it twice right now...  But it just seemed possible
<mterry> kdub, there doesn't seem to be a call to see 'isStarted' or something to even guard the call
<mterry> kdub, if I did call it twice, would that explain the crash I'm seeing?
<kdub> i think it could, but i have to poke around to be sure
<mterry> kdub, OK.  I will also test on my end with my own guard variable
<kdub> i'll fix it in mir, shouldn't take too long
<kdub> the call to blank/unblank though is guarded against double on's
<mterry> Guh!  Now I can't reproduce
<kdub> now that you added the guard?
<mterry> ogra_, ^ can't reproduce anymore, so I'd still like to see your testing results when you can get to them.  No rush
<mterry> kdub, no, just at all
<mterry> I reproduced it several times in a row...  Now nothing
<ogra_> it seems unreliable ... even on my maguro i have it sometimes react immediately (most of the time it takes >10sec to wake up though)
<mterry> I meant the u-s-c crash, but yeah, these powerd interactions seem less than predictable
<ogra_> oh, ok
<mterry> I haven't been able to reproduce the screen wake up problem at all.  Might just be a maguro issue
<ogra_> yeah, like the old one was
<alan_g> kdub: do you still dislike "namespace google { namespace protobuf { class RpcChannel; } }"?
<mterry> debs are in the merge for ya, btw
<alan_g> alf__: anpok opinions on "namespace google { namespace protobuf { class RpcChannel; } }" as a single line?
<kdub> i don't mind it in general, but the rest of the code puts something like that on 7 lines
<alf__> alan_g: I am ok with one level of "namespace X { class Yy }", but with more I think the class name is somewhat lost in the text
<alf__> alan_g: e.g., I would be more OK with http://paste.ubuntu.com/6727615/ if we want to keep it short
<janimo> ogra_, better than I thought, all the deps of mir-test-tools are already in the image (they were not on my desktop only)
<ogra_> janimo, ah, perfect ...
<janimo> ogra_, where is the bzr branch you need a MR agains for adding mir-test-tools ?
<alan_g> alf__: sorry, got distracted. I don't think we have a consensus format.
<janimo> ogra_, https://code.launchpad.net/~jani/ubuntu-seeds/ubuntu-touch.trusty-mir-test-tools/+merge/201236
<ogra_> janimo, perfect
<kgunn> janimo: i saw your mail...about the failing tests....did you stop unity8 before running ?
<kgunn> kdub: janimo should stop unity8 correct ?? ^
<kdub> yes
<kgunn> at least i did stop unity8....and integration, acceptance tests pass 100%
<kdub> although segfaults shouldnt be happening
<kgunn> unit-test fails...only 1 after many...its the
<janimo> kgunn, I did not stop it :)
<janimo> kgunn, well then the tests are great, since the majority passed even with unity8 running
<kgunn> janimo: ok...hopefully you'll get even better results when you try with untiy8 stoped
<janimo> kgunn, how is that doen again? kill the process or some upstart command?
<janimo> I keep forgetting even though I had stopped unity8 in the past IIRC
<alan_g> janimo: sudo -u phablet -i stop unity8
<kdub> janimo, sent a mail, but last I remember, mir_stress should be run against a demo server
<kgunn> janimo: right...running as "phablet" just "stop unity8"
<kgunn> janimo: also...as kdub says....really for the case of this testing...it should be unit, integration & acceptance
<janimo> I used su - phablet and that did not find stop. I need to remember to stick to sudo -i -H -u phablet
<kgunn> janimo: i'm gonna update https://docs.google.com/a/canonical.com/document/d/1oxXDxehRQ35rYRwkuBCy1ZNmB_IBpg5UhE3jvNHEk_0/edit#
<kgunn> with the unity8 stop
<janimo> kgunn, ok. I just sent a new email
<kgunn> janimo: thanks..
<ogra_> janimo, never use su :)
<ogra_> (gets you a totally different env than sudo)
<janimo> ogra_, yes  I remember the thread on the mailing list a few months ago, but it seemed to end inconclusively
<janimo> I had used su - so far because it is shorter :)
<ogra_> we use sudo -u phablet -i everywhere
<janimo> ogra_, I will too from now on :)
<ogra_> yeah :)
<ogra_> janimo, meta uploaded btw
<janimo> ogra_, thanks
<mterry> Does mirserver initialize the display to on or off on startup?  (by itself, not worrying about powerd right now)
 * mterry is trying to wade through the code to determine, but perhaps someone knows off the top of their head
<anpok> mterry: i dont think so, it only interferes with hwc and framebuffer device
<mterry> anpok, so it leaves it uninitialized until powerd asks the compositor to turn it on/off?
<mterry> anpok, mirserver deals with screen when that happens via Display::configure()
<mterry> I'd assumed it would do something on startup too
<kdub> mterry, it does set the screen to unblanked on start
<mterry> kdub, OK, cool.  Where?
<anpok> HWCCommondevice::turn_screen_on ..
<kdub> http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/platform/graphics/android/hwc_common_device.cpp#L58
<anpok> but I thought that would not turn the display on/off
<kdub> anpok, those hal functions should blank or unblank the fb device
<kdub> mterry, is that what you meant, or did you mean something else?
<mterry> kdub, I believe that's what I wanted, yeah
<kdub> cool... that constructor should get hit when the_display() is called the first time (not for nested / offscreen of course)
<mterry> kdub, hmm
<mterry> kdub, testing restarting unity8 with the screen off doesn't turn screen on
<kdub> restarting how
<kdub> and in what powerd state?
<mterry> kdub, um
<mterry> kdub, I had pressed power button so screen was off
<mterry> kdub, then I did a "sudo -u phablet -i restart unity8"
<kdub> right, so the power button allows the system to enter 'powerd inactive'
<kdub> my understanding is that everyone could assume that things were on to start with... although hopefully the discussion about those power interactions clarifies the situation
<mterry> kdub, sure.  I'm just trying to document the current situation.  And if mirserver is turning display on on startup, I'd expect a unity8 restart to turn display on
<kdub> right, it should
<mterry> hmm
#ubuntu-mir 2014-01-11
<Prf_Jakob> win 25
<mlankhorst>  /alias 25 window 25
#ubuntu-mir 2015-01-05
<RAOF> Hm.
<RAOF> It occurs to me that what I really want is mir::observing_ptr.
<racarr_> ALL ABOARD THE MIR TRAIN
<racarr_> DEPARTURE SOON
<racarr_> *whistle blowing*
<racarr_> Happy new years everyone :) See you all tomorrow.
<mlankhorst> Morning and happy newyear
<mlankhorst> RAOF: don't we all want that? :D
<kdub> good morning
<greyback_> alan_g: hello! Happy New Year to you
<greyback_> quick question, the new mir Server api doesn't have a getter for the_placement_strategy - omission or intentional?
<alan_g> greyback_: Healthy New Year!
<kgunn> mornin' & happy new year to all
<greyback_> o/
<alan_g> We've exposed the stuff that is in use
<alan_g> kdub: kgunn : Healthy New Year!
<kdub> alan_g, thanks
<greyback_> alan_g: https://bugs.launchpad.net/mir/+bug/1407687 - I'd like it re-instated as I've a qtmir patch to use it. Far from urgent tho
<ubot5> Launchpad bug 1407687 in Mir "request: mir::Server provide the_placement_strategy getter" [Undecided,New]
<kgunn> camako: seems like we should probably cherry pick this into stable
<kgunn> https://code.launchpad.net/~vanvugt/mir/fix-1401488/+merge/245443
 * camako looks
<kgunn> ...lemme know what ya think
<kgunn> showing up here also
<kgunn> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1405687
<ubot5> Launchpad bug 1405687 in unity8 (Ubuntu) "unity8 crashes while using webbrowser-app" [Undecided,Incomplete]
<kgunn> ...with people confirming
<camako> kgunn, yeah I think so
 * kdub wonders why we're wrapping the binaries
<camako> kgunn, we'll be making a release though.. will start it today..
<kgunn> cool
<alan_g> kdub: wrapping is an [in]elegant way to locate the platforms directory
<kdub> yeah... guess its too late to object
<alan_g> If I (or duflu) had had a better idea then we would have objected
<kdub> yeah, something to improve on later
<racarr_> Good morning
<kdub> morning racarr_
<camako> morning
<racarr_> hey :) Happy new years guys
<camako> happy new year to you too :-)
<attente_> hello, is mir supposed to generate hover-exit motion events when the mouse cursor leaves a surface?
<racarr_> sort of yes
<racarr_> as it stands cursor stuff doesnt work very well espescially under unity8
<racarr_> qtmir will drop the hover exit event afairc (it would be hard for it to know what to do with it currently atm)
<greyback_> qtmir is missing many useful mouse events yet
<greyback_> so yeah, is on the list
<kgunn> racarr_: happy new year
<alan_g> camako: racarr_ Healthy New Year!
<racarr_> MirPointerEvent coming soon :)
<racarr_> PointerInputEvent rather
<racarr_> maybe this is a good time to inbox 0
<racarr_> BOOM
<kgunn> good luck
<kgunn> ....you'll likely get stuck on the riveting cla email
<alan_g> greyback_: I'm curious: how is the_placement_strategy() useful outside of Mir? Is it a workaround for a better API?
<greyback_> alan_g: I want to push the placement decision into qml. I do this by making the place() call emit a synchroneous signal, that qml can catch and make the decision
<greyback_> alan_g: https://code.launchpad.net/~gerboland/qtmir/initialSurfaceGeometry/+merge/231725 is how I'm using it
<alan_g> greyback_: OK but that just needs override (which is supported).
<alan_g> I'll take a look
<greyback_> alan_g: yeah, my workaround is just to save a copy of the shared pointer to the PlacementStrategy
<greyback_> ...in the override
<alan_g> I think it is similar to my saving the WindowManager in https://code.launchpad.net/~alan-griffiths/mir/tiling-window-mamagement/+merge/245228 (but I want the WindowManager, not the PlacementStrategy interface
<greyback_> alan_g: yes indeed. I've always let Mir create the objects and then relied on getters for them (not doing this was buggy with the old api). Perhaps I should relax that now
<alan_g> greyback_: it seems you actually want a MirPlacementStrategy* (not a ms::MirPlacementStrategy). So, rather than an accessor in Mir and a downcast (BTW wouldn't dynamic_cast be safer?), why not keep a weak_ptr<MirPlacementStrategy>? That would automatically give you your nullptr too.
<greyback_> alan_g: fair point, and yes fair point
<alan_g> Can I mark lp:1407687 invalid?
<greyback_> alan_g: just an FYI on why I'm implementing ms::MirPlacementStrategy - I received complaints from some clients where the surface size returned by the PlacementStrategy would be changed later when the surface is added to the scene. I.e. the surface would get a resize event shortly after creation. Some clients don't like that
<alan_g> that seems sensible
<alan_g> And what ms::PlacementStrategy is for
<greyback_> alan_g: you can. But it does open up a slight API inconsistency in mir::Server - as many overrides do have accessor methods, and only a few do not
 * greyback_ not sure "accessor" is the correct term
<alan_g> "accessor" or "factory method" or ...
<greyback_> ack
<alan_g> I'd rather only expose things that are actually useful
<greyback_> that fair. I'm not that opinionated on this, just wanted to raise the question as to how you expect the api to be used
<alan_g> Sure. I'm not opinionated either. The interface is already public so there's little cost to exposing it - except that folks might use it (and write bad code).
<greyback_> I'll let you have the final call so.
<alan_g> Do you have an opinion on my example above? After writing my WindowManager example code think there's too much "wiring" in the example and not enough in the library. (I could push the "Tracker" and "Factory" wiring into Mir and give it a msh::WindowManger interface)
<greyback_> I do like the basic design of WindowManager, and think TilingWindowManager is a nicely written bit of example code. It is a bit surprising for me that different methods of WindowManager will be called in different threads tho, but as long as that's clearly documented it is fine
<greyback_> yeah the tracker is pretty typical, I had expected it to be in Mir
<greyback_> if you intend to push WindowManager into Mir, then yeah think it logical the Trackers will have to go in too
<attente_> will mir support the same kind of pointer hover enter/exit behaviour as in X? per http://tronche.com/gui/x/xlib/events/window-entry-exit/normal.html
<racarr_> attente_: Yes
<alan_g> I'm not sure the design is yet mature enough to put in the API (e.g. no focus switching) but it does seem to be that stuff is missing that would make Mir usable.
<racarr_> attente_: Currently support is spotty, I guess it wont work under unity8 and should work otherwise
<racarr_> soon it will work fine :)
<attente_> racarr_: thanks!
<greyback_> racarr_: qtmir/unity8 will generate the hover enter/exit events for the client, if mir supports such an event
<racarr_> greyback_: DO you think so? I think it will drop it in QtEventFeeder
<racarr_> the bit that
<racarr_> switches based on the touch action
<racarr_> just drops hover enter/exit afairc
<racarr_> QtEventFeeder::dispatchMotion...are you saying they are then
<racarr_> generated again later?
<greyback_> racarr_: we'll generate them in the MirSurfaceItem - which lives in our scene and knows when mouse in/out occurs
<racarr_> oh
<racarr_> future perfect
<racarr_> will
<racarr_> not
<racarr_> present perfect
<racarr_> will
<racarr_> haha
<greyback_> yes sorry
<racarr_> No its ok :p yea
<racarr_> h
<racarr_> that is where to do it. nothing atm I think though
<greyback_> Hayy New Year btw!
<racarr_> Happy new year!
<racarr_> There are some pointer event changes upcoming that should make this possible to implement correctly
<racarr_> currently you cant really differentiate between
<racarr_> touch points hovering
<racarr_> and the pointer
<greyback_> yeah, mouse support need work still, will be dandrader's first mission when back
<racarr_> ah cool
<racarr_> im cleaning up the mir end :)
<racarr_> SYNERGY
<greyback_> nice
<greyback_> it could do with it
<greyback_> any idea how's the libinput integration going too?
<racarr_> new model is touch/pointer event are seperate event types
<racarr_> hmm
<racarr_> not really
<racarr_> definitely some progress on the
<racarr_> infrastructure to
<greyback_> +1 for the different event types anyway
<racarr_> well like support libinput based devices and
<racarr_> also use the android stack
<racarr_> etc
<greyback_> gotcha
<racarr_> I wouldnt be expecting 2 finger scroll this month though :(
<racarr_> maybe thats pessimistic or anpok was working over holidays or something lol
<racarr_> greyback_: Did you have nice holidays?
<greyback_> racarr_: yeah, was the perfect length to forget everything work related
<greyback_> you?
<greyback_> see the family?
<racarr_> Yeah excellent :D Also forgot everything. Went to see family
<racarr_> they gave me a violin
<racarr_> A+!
<greyback_> nice!
<greyback_> I wouldn't like to be your neighbor right now...
<greyback_> we have an old family violin which my mother used to play when she was young. We got it restored and gave it to my sister's daughter
<greyback_> ofc no such thing as a free gift - she's now eternally obliged to play it at family gatherings :)
<racarr_> hehe of course
<alan_g> racarr_: kdub I could do with another vote on https://code.launchpad.net/~alan-griffiths/mir/tiling-window-mamagement/+merge/245228
<kdub> alan_g, okay
<kdub> alan_g, will review probably after your EOD, my brain is spooled up with how to improve android display construction
<alan_g|EOD> kdub: np
<racarr_> wow this vacation stuff
<racarr_> really works
<racarr_> I actually had fun reviewing the managed surface branch
 * alan_g|EOD thinks he needs a vacation then
<racarr_> I think its ok to land this yeah? https://code.launchpad.net/~mir-team/mir/port-examples-off-mir-event-access/+merge/245240
<racarr_> hmm I guess anpok is still gone
<racarr_> evdev-input-platform isnt easy
<racarr_> Finished reviews gonna take a niec long lunch
<racarr_> back in ~1 hour
<kgunn> camako: are we fully swtiched over from asio to glib mainloop?
<kgunn> ...guessing not on rtm
<camako> kgunn, yes
<camako> kgunn, correct .. not on rtm
<kgunn> kdub: for "Make nested & offscreen an actual platform" it's marked ready for release...so we really have a sw FB for offscreen on devel ?
<RAOF> That would be pretty rad.
<racarr_> Hi RAOF!
<racarr_> Happy new years :D
<RAOF> racarr_: Happy new year!
#ubuntu-mir 2015-01-06
<racarr_> camako: Oh...re: downstream branches
<racarr_> I forgot about some of them
<racarr_> https://code.launchpad.net/~mir-team/platform-api/expose-mir-connection
<racarr_> and the corresponding qtubuntu branch should land I hope...
<racarr_> platform-api first I guess
<racarr_> tvoss approved plan but still needs review
<racarr_> I tried remove-sha1sums but have already hit my interest threshold for it :)
<RAOF> :)
<racarr_> I really can't articulate how frustrating it is without seeming childish though :/
<RAOF> What prevents us from using abi-compliance-checker instead of sha1sums?
<racarr_> I think I spend probably
<racarr_> 10-15 minutes every night
<racarr_> updating all my current branches
<racarr_> one by one
<racarr_> merging trunk
<racarr_> updating sha1sums
<racarr_> push
<racarr_> next branch
<racarr_> maybe its 5 minutes
<racarr_> but every
<racarr_> single
<racarr_> day
<racarr_> lol
<racarr_> RAOF: I dunno.
<racarr_> Oh well im over it
<RAOF> I might look at hooking up compliance-checker instead.
<RAOF> That would be acceptable, I think.
<RAOF> And also solve the problem.
<racarr_> RAOF: You should check with...I believe AlbertA at least started
<RAOF> There's already a compliance-checker target.
<racarr_> mm
<racarr_> I dunno whats wrong with it
<racarr_> lol
<RAOF> The trick would just be to add that to make check.
<racarr_> or rather what it does
<racarr_> good news is pointer event is coming together nicely
<RAOF> Sweet!
<racarr_> oh are we gonna do
<racarr_> monday meeting otnight?
 * RAOF is available.
<racarr_> :) I will plan on being there
<racarr_> :) It's good to be back
 * RAOF notices he's reading the CLA thread on ubuntu-devel, and goes back to writing another smart pointer.
<duflu> tvoss: Happy 2015... you around?
<tvoss> duflu, a happy 2015 to you, too. Around but about to jump on a meeting. Can I ping you later?
<duflu> tvoss: Maybe. I have meetings just about all day. I might email you instead
<tvoss> duflu, yup, that would work
<tvoss> duflu, we can probably sync up tomorrow my morning if needed
<duflu> tvoss: It's a minor issue you can comment on offline
<tvoss> duflu, ack
<duflu> alan_g: Oh I think everyone else is still on vacation. Do we need a meeting today?
<alan_g> nothing specific I need to address
<kgunn> camako: so i know you're trying to make a release of code, is that to vivid and rtm ?
<tedg> Never thought about latency of input. Makes sense for 3d goggles. https://twitter.com/ID_AA_Carmack/status/552485206691946496
<camako> kgunn, just vivid
<kgunn> camako: tooth ok ?
<greyback> tedg: with 3d goggles, it seems latency is the big issue. As Carmack says, the motion to photon is critical
<greyback> +time
<tedg> Yeah, and it seems to be an issue with the samsung joypad he's playing with :-)
<tedg> I'm actually surprised how good the bluetooth controller have gotten.
<tedg> Worked in a group that did wireless controllers back in 2002, it's tricky.
<alan_g> camako: I had a brief look at lp:1407863 - and concluded that something happen to the CI environment (because a null change fails the same way). Not looked into what it could be though.
<camako> kgunn, yeah routine visit
<camako> alan_g, curious
<alan_g> camako: yw
<racarr_> Great to see the rapid pace on MPs
<racarr_> even if a bunch of them were pretty old
<racarr_> ROAR
<racarr_> * Copyright Â© 2015 Canonical Ltd.
<racarr_> Oh yeaaaah
 * alan_g thinks that's taking "Merry New Year" a bit far
<racarr_> hehe
<kdub> anymore takers? (and thanks to racarr_ ) https://code.launchpad.net/~kdub/mir/power-control-to-display/+merge/245006
<racarr_> :)
<racarr_> I wonder how long I can keep doing every review every day for
<racarr_> lol
<racarr_> I mean I guess already today I refrained from further comment on 2
#ubuntu-mir 2015-01-07
<duflu> RAOF: What's this new pointer type you've mentioned?
<RAOF> Overly complicated and abandoned.
<RAOF> :)
 * RAOF -> lunch.
<duflu> RAOF: Oh. I think Google made a good choice actually in abbreviating their template to "sp"
<duflu> We could have a "ref" or "ptr" similarly. It would improve the readability of many lines of code
<duflu> Although C++ should have done this for us :(
<racarr_> I would probably vote for an SP alias...
<racarr_> its not so bad by itself but when its like
<racarr_> std::vector<std::shared_ptr<graphics::....
<racarr_> I start to struggle sometimes ;)
<duflu> Bleh. Why does even the simplest task end up not being simple?
<duflu> alan_g: Hey I think I probably failed to document some enhancements by other people that I didn't understand. Feel free to add more entries to the changelog
<alan_g> duflu: ack
<duflu> Oh did vivid just get kernel 3.18 today?
<duflu> Apparently it did
<Saviq> hey guys, does this trace ring any bells https://errors.ubuntu.com/problem/fc69b4f16d4d4571c83038bf9dc47b84135d9ced ?
<Saviq> the exception msg I managed to find is:
<Saviq> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
<Saviq>   what():  Nested Mir Display Error: Failed to update EGL surface.
<alan_g> Saviq: no bells. All it really says is "eglMakeCurrent() failed" (It doesn't fix the failure but we should at least record the error code!)
<Saviq> alan_g, right, could be useful indeed
<alan_g> I guess you've no context about when this happens?
<Saviq> alan_g, during an AP test run
 * Saviq tries to reproduce locall
<mlankhorst> is rotation implemented on the server or do clients have to do their own rotation?
<racarr_> Good morning!
<racarr_> Ive been trying to figure out
<racarr_> how to make the doxygen more useful...
<racarr_> in particular the comments in tree
<racarr_> I dont care that much abotu the generated output (perhaps thats a mistake)
<racarr_> one idea is moving all the trivial comments
<racarr_> e.g.
<racarr_> mir_foo_get_baz
<racarr_> retreives bazz from foo
<racarr_> precondition foo is valid
<racarr_> etc
<racarr_> in to like
<racarr_> trivial-comments.h
<racarr_> so then in the header file there is only stuff you actually wanna read
<racarr_> Landing https://code.launchpad.net/~mir-team/mir/fix-1407883/+merge/245703 to avoid CI failures
#ubuntu-mir 2015-01-08
<mlankhorst> The size of mir surface doesn't change on rotate right? rotating is just a hint to client
<alan_g> mlankhorst: right
<mlankhorst> hey how can I test egl debugging on the phone?
<mlankhorst> on android it seems to be calling setprop debug.egl.trace
<mlankhorst> ah found it, i need to use /system/bin/logcat too
<mlankhorst> symlink in /usr/local/bin to it makes adb logcat work
<Saviq> hmm guys, is it normal that a dist-upgrade installs mir-client-platform-android on my desktop?
<Saviq> had to manually install -mesa instead
<kgunn> mmm
<kgunn> i think we got packaging issues again somehow...
<kgunn> RAOF: kdub ^
<RAOF> Bah.
<kgunn> RAOF: also...citrain upgrade-device tool....seems busted, in that the silo gets add to the device, but doesn't install packages
<kgunn> likely due to packaging
<kgunn> camako: ^
<kgunn> stepping away for a bit
<RAOF> Saviq, kgunn: Hm. So, ubuntu-touch depends on mir-graphics-drivers-android; ubuntu-desktop-next depends on mir-graphics-drivers-desktop.
<RAOF> This seems reasonable.
<Saviq> RAOF, might be unity-desktop-session-mir should, too
<RAOF> Saviq: So, I think the answer is: install ubuntu-desktop-next if you want unity8 on a desktop. :)
<Saviq> right, that works probably
<RAOF> Alternatively, this whole problem will almost entirely go away (next â¹) release.
<camako> kgunn, opened a bug for it https://bugs.launchpad.net/mir/+bug/1408827
<ubot5> Launchpad bug 1408827 in Mir "citrain tool cannot install Mir" [High,New]
<Saviq> camako, is there a chance there was a new dependency somewhere?
<Saviq> ah I see there's quote a bit of explanation
<camako> Saviq, possibly.. our packaging changed quite a bit so...
<RAOF> Urgh.
<RAOF> camako: What's the expected use of citrain device-upgrade here?
<RAOF> camako: Unless the expectation is that you then *build* something on the phone, that analysis is wrong.
<camako> RAOF, upgrade the packages infrom a silo
<camako> RAOF, upgrade the packages from* a silo
<RAOF> Then I don't see how that analysis follows.
#ubuntu-mir 2015-01-09
<RAOF> Because there *has* to be something in the silo that depends on libmirserver28
<RAOF> Or, rather, *unless* there's something in the silo that depends on libmirserver28 you're not testing the new Mir.
<camako> RAOF, correct, usc, qtmir are/were on the silo
<RAOF> And they were built against the correct version, presumably, and so had a dep on libmirserver28?
<camako> RAOF, yep they were changed to dep on libmirserver 0.10
<camako> RAOF, but we don't necessarily bump their dep, we only do it unless downstreams must be changed as a result of changes in mir
<RAOF> Yeah, absolutely.
<camako> RAOF, but this time we did, because there were code changes
<camako> in downstreams
 * greyback_ surprised qtmir built against mir0.1.0, as it failed for me until I changed post_update() to "gl_swap_buffers(); flip();"
<camako> greyback, I changed it in qtmir
<greyback_> camako: ah really? Ok, I didn't find that branch
<RAOF> camako: So, the interesting question is: âwhy were mir-utils, qtdeclarative5-qtmir-plugin, and qtmir-android held backâ.
<camako> greyback : this was in the silo ---> https://code.launchpad.net/~mir-team/qtmir/devel-mir-next/+merge/245592
<greyback_> camako: saw that, but has empty diff for me?!
<greyback_> as in, what LP shows me
<greyback_> ah, I see it now
<camako> greyback, ah yeah I noticed that too. it's lying
<greyback_> camako: ok well mystery solved
<camako> greyback, look at the commit # 269 here ---> https://code.launchpad.net/~mir-team/qtmir/devel-mir-next
<greyback_> thanks!
<camako> 269 == approved rev of the MP (but the diff shows empty :-) )
<attente_> hello, is there some known issue with heavy screen flickering in mir_demo_server? running mir-demos 0.10.0+15.04.20150107.2-0ubuntu1, kernel is 3.19.0-031900rc3-generic
<attente_> hi, has anyone experienced that problem recently? mir_demo_server is flickering heavily (it seems to happen after switching vt the second time)
<racarr_> attente_: new to me
<racarr_> can you file a bug?
<attente_> racarr_: sure
<racarr_> this late on a friday its not going to get a lot of attention ;) but next week
<attente_> racarr_: right ;)
<racarr_> :) Thanks
<racarr_> probably gonna be some sort of driver specific thing ;(
<racarr_> attente_: Saw  the bug. Thanks :)
<attente_> racarr_: np :) forgot to mention about the kernel update at first, hope that's not the cause
#ubuntu-mir 2016-01-11
<duflu> And to make everyone feel good about their code we have mir-ci-bot. Which seems to approve everything :)
<kgunn> robert_ancell: ping
#ubuntu-mir 2016-01-12
<robert_ancell> kgunn, hii
<alan_g> Any reviewer for https://code.launchpad.net/~alan-griffiths/mir/nested-server-uses-host-graphics-platform/+merge/281886?
<greyback> http://pastebin.ubuntu.com/14477402/ <- think my libraries are mismatched?
<greyback> yeah, I've mix of 17 & 18 somehow
<greyback> I must've been naughty again
<alan_g> kdub: https://bugs.launchpad.net/mir/+bug/1532202/comments/12 - before I dive into the android platform do you any pointers or thoughts?
<ubot5> Launchpad bug 1532202 in canonical-pocket-desktop "[android] External monitor slows rendering" [High,In progress]
<kdub> alan_g, maybe check if the code is waiting the hwc_fallback_gl_renderer aronud the texture loading
<kdub> or in the ipc platform before the buffer is sent back over ipc
 * alan_g ducks as words whoosh over his head
<kdub> http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/platforms/android/server/hwc_fallback_gl_renderer.cpp#L134
<hroo772> quick question about mir. Has it been made the default graphics server in 16.04?
<alan_g> no
<hroo772> thanks. Were there any major graphics changes between 15.10 and 16.04? I've had some odd issues with an older nvidia chip crashing after the login screen. Haven't gotten logs just yet
<hroo772> it seemed like xorg fallback didn't seem to work properly and after the crash, it just gets sent back to the login screen
<josharenson> So I was complaining that I couldn't get the greeter to run as a mir server... the real issue is with mir-platform-input-evdev4... Just by installing that package (and not attempting to run the greeter as a mir server), my system won't even boot.
<josharenson> The only error I see is re: bluetooth (making a pastebin)
<josharenson> the bt part looks possibly unrelated, but still wondering why the package is breaking my system
<anpok_> josharenson: but that package should just be available..
<anpok_> i mean it is required by usc
<anpok_> indirectly due to the driver packages..
<josharenson> anpok_: can you clarify? it _shouldn't_ be installed?
<anpok_> it should be installed..assuming you are on rc-proposed..
<anpok_> but why would you install it in isolation?
<josharenson> anpok_: this is on xenial desktop and it doesnt look like anything else installed it
<josharenson> anpok_: and w/o it mir complains that there is no input devices
<anpok_> hmm odd .. mir-graphivs-drivers-desktop should require it
<anpok_> *graphics
<anpok_> it just means it starts up further and then halts for other reasons..
<josharenson> anpok_: havent done a dist upgrade in a few days, let me see what the result of that is too
#ubuntu-mir 2016-01-13
<alan_g> alf: happy with this update? https://code.launchpad.net/~alan-griffiths/mir/nested-server-uses-host-graphics-platform/+merge/281886
<alf> alan_g: not pushed yet?
<alan_g> Hmm...
<alan_g> ...push failed (yesterday) because I'd not synced local working copy between desktop and laptop
<alan_g> alf: pushd
<alf> alan_g: approved
<alan_g> thanks^2
#ubuntu-mir 2016-01-14
<anpok> alf: is that better now? Then I would also merge that to the 0.18 version of the fix: https://code.launchpad.net/~andreas-pokorny/mir/fix-1531517/+merge/282439
<alan_g> kdub: does this work for you? Or do you still find it unclear?
<alan_g> https://code.launchpad.net/~alan-griffiths/mir/nested-server-uses-host-graphics-platform/+merge/281886/comments/717223
<kdub> alan_g, sure
<alan_g> thanks
#ubuntu-mir 2017-01-09
<mhall119> tsdgeos: how are you not an Ubuntu member yet?
<tsdgeos> mhall119: because it means you need to do nice things :D
<tsdgeos> tbh i've done *nothing* for ubuntu
<tsdgeos> outside by dayjob
<tsdgeos> doesn't feel appropiate
<tsdgeos> to be an ubuntu member
<tsdgeos> basically i read https://wiki.ubuntu.com/Membership a few times and i didn't think i qualified
<mhall119> tsdgeos: are you a part of BCNFS in Barcelona?
<tsdgeos> i am
<tsdgeos> https://github.com/bcnfs <- me me
<mhall119> I'm looking for an Ubuntu Member who might request community donations money to help sponsor it
<tsdgeos> i see
<tsdgeos> i'll re-read those memebrship pages again
<mhall119> tsdgeos: involvement in your loco team and upstream projects are considered as well
#ubuntu-mir 2017-01-10
<Pharaoh_Atem> tvoss: I saw this today: https://lists.freedesktop.org/archives/wayland-devel/2017-January/032580.html
<Pharaoh_Atem> but I didn't see any mention of the APIs that Mir needs being added :(
<Pharaoh_Atem> what's going on in re upstreaming?
<anpok_> Pharaoh_Atem: https://anonscm.debian.org/cgit/pkg-xorg/lib/libinput.git/tree/debian/patches?h=ubuntu
<Pharaoh_Atem> anpok_: are these rebased against 1.6?
<anpok_> they look like the newest version because the functions in evdev.c are prefixed with fallback_
<Pharaoh_Atem> anpok_: so what's holding up upstreaming from your side (you're the patch author right)?
<anpok_> we added reading contact sizes from touchscreens
<anpok_> but the touchscreen drives do have no consistent way of reporting it..
<anpok_> so this patch still needs a way to scale/calibrate the reported value to some physical unit .. pixels.. mm..
<Pharaoh_Atem> so then how is this even working with Mir?
<Pharaoh_Atem> it seems like it's a horrible idea altogether
<anpok_> the value is provided as is
<Pharaoh_Atem> so the value exists, but is not any good
#ubuntu-mir 2017-01-11
<duflu> RAOF: Do you recall why outputs have pixel formats?
<duflu> Is that for nesting?
<RAOF> Because CRTCs have pixel formats?
<RAOF> How else would you scan out of rgb565, or rgbx1010102?
<duflu> RAOF: Hmm, OK. Just noticed we've hardcoded xrgb in a couple of places for KMS (which might aggravate the vmware bug)
<RAOF> Really? Odd.
<RAOF> If you want to update the kms platform to use the available output formats that'd be fine :)
<duflu> In other news, I found a second use for blank DVDs
<duflu> To burn ThinkPad BIOS updates (which otherwise require Windows)
<duflu> The first use is as a coaster
<RAOF> Huh. I always used USB sticks for that.
<duflu> RAOF: Not an option with ThinkPad ISOs
<duflu> I have tried many times
<duflu> The first 32K of the ISO is zero... so there's no boot sector there
<RAOF> HUh.
<duflu> Is CI down? I've been waiting 5 hours on my current branch...
<duflu> Oh I see others have been waiting 7 hours
<anpok> hm device-runtests-mir seem to wait for krllin executors
<anpok> hm but it is still running
<anpok> at least one job..
<duflu> anpok: Finished after 6 hours
<duflu> Just one revision on one branch
<alan_g> kdub: have I understood your review comment? https://code.launchpad.net/~alan-griffiths/mir/rework-throwback-and-staging/+merge/314351
<kdub> alan_g, didn't see the other file, will remove needs fixing
<alan_g> thanks
 * alan_g only needs the prerequisite to pass review now
<kdub> camako, been thinking... if we're deprecating mir_buffer_stream_get_egl_native_window in favor of Mir(Render)Surface, there's really no reason to have a 'hardware' buffer stream
<kdub> so maybe we just drop the MirBufferUsage parameter from mir_render_surface_get_buffer_stream(), and that makes software buffers
<kdub> android drivers don't need streams, mesa doesnt need streams, and the users will port to using MirRenderSurface as the native window (instead of the hop through mir_bs_get_egl_native_window())
<camako> kdub, umm yeah sounds reasonable... Future (non-egl) middleware can use PCs, I guess
<kdub> right, and if we encounter any usage of it (which I think most the usage is the egl case)
<kdub> we should add extensions for android and mesa to do the right thing
<kdub> that is, 'add extensions for android/mesa to alloc a hardware bufferstream'
<kdub> I'll pull that param out of there, and RAOF is probably interested in reviewing as well
<kdub> 0.26 is going to be a big silo
<bschaefer> kdub, it is
<bschaefer> going to be
<alan_g> kdub: your commit comment seems to be a C&P error - https://code.launchpad.net/~kdub/mir/usage-deprecation-nested/+merge/314518
<kdub> alan_g, thanks, correcetd
<kdub> camako, darn, we have name collisions when trying to change MirRenderSurface to MirSurface :/
<camako> kdub, yeah we are not ready... We need to make a release
<camako> then delete MirSurface
<camako> then rename
<kdub> yeah, so it looks like releasing the new platform won't make it into 0.26
<alan_g> kdub: unless you call it Mir5urface for the time being and then deprecate
<alan_g> ;)
<kdub> yeah :D
<kdub> mir_5urface_release
<kdub> not too late to change all the functions to l33t5p34k before the 1.0!
<alan_g> LOL
<camako> kdub, @new platform... correct
<alan_g> If we don't have enough to release now, we /could/ release MirRenderSurface in 0.26, then deprecate it for MirSurface in 1.0.
<alan_g> ...and delete it in 2.0
<bschaefer> kdub, i like that naming scheme, it expresses a lot about the functions
<bschaefer> %s/*/l33t5p34k/g
<alan_g> keywords too?
<bschaefer> %s/./l33t5p34k/g
<bschaefer> every char
 * bschaefer assumes this would no longer compile though
<kdub> well, thats where macros come in
<bschaefer> haha
<bschaefer> good luck figuring out how many k's you need to disambiguate that grammar
<kdub> alan_g, yeah, I think the plan was to not release the MirRenderSurface, because if its named 'MirSurface', then it falls into the vulkan standard
<alan_g> kdub: ack, I thought that too
<kdub> yay, we're in a cheatsheet for khronos https://www.khronos.org/registry/vulkan/specs/1.0/refguide/Vulkan-1.0-web.pdf
<alan_g> But at that time I also thought 1.0 would make it into 17.04
 * bschaefer has hope but it fades by the hour
<kdub> r:74
<tjaalton> bregma: ping
#ubuntu-mir 2017-01-12
<duflu> RAOF: I noticed in my IRC log an issue with Xmir changing display configs. Looks like that's just to support DPMS settings. Would it hurt to drop that?
<RAOF> duflu: Not at all.
<duflu> Or hide it behind "Xmir is in legacy full system compositor mode"
<RAOF> Plausibly.
#ubuntu-mir 2017-01-13
<duflu> RAOF: CI is hung but I did fix your concerns: https://code.launchpad.net/~vanvugt/mir/remove-input-resampling-standalone/+merge/314305
<RAOF> I enjoy the fact that our input consumer is now woke :)
<duflu> Or "awoke" might avoid dyslexic readings...
<duflu> RAOF: Also managed to remove the extra wake now...
<duflu> Pushing...
<ogra_> bschaefer, https://plus.google.com/+OliverGrawert/posts/6S6U4MKG32y?sfc=true
<ogra_> <3
<bschaefer> ogra_, just saw :) thats awesome!
<bschaefer> ogra_, did you get pulseaudio to work with videos?
<ogra_> thats still the first build that i did over a month ago ! it just works now that the os works
<bschaefer> nice!
<ogra_> i didnt try playing anything yet (i didnt even expect it to start !!!)
<bschaefer> haha
<ogra_> it just did ...
<bschaefer> ogra_, yeah last i heard puleaudio was an issue, though things should render
<bschaefer> theres an issue with hardware accel (only on core ive yet to dig into)
<ogra_> my monitor has no speakers so that requires some different setup
<bschaefer> at lease for me!
<ogra_> pulse *'should* work though
<ogra_> it is installed and connected
<bschaefer> hmm last i heard things were being called but no sound
<ogra_> but indeed i cant test it with that HW
<bschaefer> yeah, something i need to test out again :)
<bschaefer> ogra_, awesome though! I might need to pick up a raspi3 now!
<ogra_> and i might need to pull your latest branch ... (or you could just enable armhf builds for your snap ;) )
<bschaefer> ogra_, the source has landed upstream :)
<ogra_> this was so totally unexpected
<ogra_> oh
<bschaefer> yeah, you mentioned opengles was working then bam
<ogra_> sadly mir 0.25 has issues on the pi atm
<bschaefer> ogra_, thats my fault as well it seems :)
<bschaefer> gamma when getting it from the hardware defaults the ramp to 0?
<ogra_> well, snappy is generous ... it is easy to install with --revision=
<bschaefer> ogra_, AlbertA found that out...
<bschaefer> soo hopefully we can get a fix out ... but unfortunate
<ogra_> well ...
<ogra_> once we have all the ducks in a row i'll roll a kodi image
<bschaefer> sweet!
<ogra_> no hurry though :)
<bschaefer> i can most likely get a mir built with turning off gamma for now
<bschaefer> yeah :) but things like this are just fun to do!
