#ubuntu-mir 2013-10-28
<duflu> RAOF: I'm still downloading trusty, so it will be some time before I can look for test failures there. Have you tried (Mir)?
<RAOF> duflu: I have; test suite passes, both in-tree and on-build.
<duflu> RAOF: Hmm. Though we are aware of some sporadic failures still - https://bugs.launchpad.net/mir/+bugs?field.tag=testsfail
<duflu> Or on Android, "reliable" failures
<RAOF> Hey, didn't https://bugs.launchpad.net/mir/+bug/1201959 get resolved at the sprint?
<ubot5> Ubuntu bug 1201959 in Mir "[xmir] autopilot tests failling (dash.PreviewNavigateTests & switcher.SwitherWindowsManagementTests)" [High,Triaged]
<duflu> RAOF: It looks like the right age, but you should double check with QA I guess
<duflu> RAOF: It appears acceptance-tests is failing on a test we fixed recently... Only on trusty and only under debuild
<duflu> I'll investigate after lunch
 * duflu lunches
<RAOF> Win!
<RAOF> An amd64 Xserver build completes in the PPA!
 * duflu suggests a Drinking Bird to manage the build button
<doneill> Hi all. I'm having a difficult time running my Qt application on my Nexus 4 running the last Touch release: "<program> ./path/to/main.qml -platform ubuntu --desktop_file_hint=/path/to/program.desktop" just seems to hang and "ubuntumirclient" doesn't do more than crash with "QUbuntu: Could not create application instance". What am I doing wrong?
<RAOF> doneill: Have we switched on the âyou must start things from upstartâ integration yet? That might be your problem, if so.
<doneill> How would I deal with that? Is there a writeup on it somewhere?
<duflu> Surely we have a shortcut for streamlining development (avoiding upstart)?
<RAOF> duflu: I'd presume so, but I'm not really familiar with that particular bit, just that it was going to happen.
<duflu> RAOF: Can you still reproduce the big radeon XMir problem?
<duflu> (post-stripes corruption and flickering)
<RAOF> The post-stripes corruption got fixed at the sprint.
<RAOF> I'll upgrade the radeon box and see if the flickering's gone.
<duflu> RAOF: No... the POST-stripes-bug :)
<duflu> The bug after the stripes fix..
<duflu> RAOF: https://bugs.launchpad.net/xmir/+bug/1233545
<ubot5> Ubuntu bug 1233545 in xserver-xorg-video-ati (Ubuntu) "XMir screen corruption on radeon chipset" [Critical,Confirmed]
<RAOF> Yeah, that's the flickering annoyance.
<duflu> RAOF: The latest duplicate had a video showing damage rectangles offset by some amount, in some frames
 * RAOF wonders if the thinkpad reproduces that, because that's much nicer to test on.
<mlankhorst> Morning!
<doneill> Hi mlankhorst.
<mlankhorst> heya
<doneill> RAOF: It launches from console using the system-settings.desktop hint, so that's something.
<sil2100> Hello guys!
<davmor2> hello sil2100
<alan_g> hello sil2100
<sil2100> Do you know if everything is ready for the mir transition? i.e. all dependencies in projects such as platform-api and u-s-c fixed?
<alan_g> sil2100: is this the same question that didrocks was discussing with kgunn on Friday? AFAIK the only question was whether anyone had actually run the XMir build. (I don't know what happened over the weekend.)
<sil2100> alan_g: that's probably the same thing - I only got an e-mail from Kevin that there were some unit-test failures, which I guess don't happen now or something, but I didn't get a green light to start our machinery
<sil2100> alan_g: and I see the u-s-c mir dependency bump wasn't merged in yet, the MR was waiting
<sil2100> So I started wondering if all was ready
<alan_g> sil2100: yeah - I saw the emails, but they didn't tell me anything useful
<sil2100> Same here, I'll maybe wait for Kevin to pop up then
<racarr|sick> Happy monday
<markss> It sounds like I shouldn't expect to be able to use Mir in a virtual machine at all presently,  based on what I can find on the Internet. Unless anyone here has seen it working in a virtual guest?
<alan_g> markss: correct. Currently you shouldn't expect to be able to use Mir in a virtual machine.
<racarr|well> markss: https://bugs.launchpad.net/mir/+bug/1157196
<ubot5> Ubuntu bug 1157196 in Mir "Mir does not work in vmware virtual machine due to drm open failure" [Medium,Triaged]
<racarr|well> has some info
<racarr> I heard something along time ago about someone running xmir in virtualbox :p but I decided to believe
<racarr> they were mistaken
<racarr> VirtualBox and VMware do work with DRM though, sooooooo
<racarr> perhaps a dedicated individual could solve it at this point
<markss> alan_g, racarr:  Thank you.
<Saviq> hey guys, what is:
<Saviq> The following packages have unmet dependencies:
<Saviq>  libmirserver7 : Depends: libmirplatform (= 0.0.15+13.10.20131014-0ubuntu2) but 0.1.0+14.04.20131028-0ubuntu1 is to be installed.
<Saviq> about
<Saviq> ?
<Saviq> that happens in https://code.launchpad.net/~kgunn72/unity-mir/bump-mir-dep16/+merge/191551
<racarr> Saviq: libmirserver depends:          libmirplatform (= ${binary:Version}),
<racarr> so it I guess something didnt get bumped?
<Saviq> racarr, yeah, but why does that fail? something's not released yet?
<racarr> Yeah I guess either libmirplatform isn't published
<racarr> or the it is but the packages are uninstallable because something got out of sync
<racarr> I Don't think so
<racarr> maybe just libmirplatform isnt published?
<racarr> Nice got my first ubuntu 14.04 has experienced an internal error
<kdub> racarr, hah :)
<Saviq> greyback, q: have you tried running unity8 under mir on desktop recently? I'm getting "cannot open current VT"
<greyback> Saviq: I have not.
<Saviq> greyback, should it work? I've gone:
<Saviq> QT_QPA_PLATFORM=ubuntumirclient unity8 --vt 7
<greyback> Saviq: try as root
<Saviq> ah
<Saviq> brb
<greyback> Saviq: honestly, haven't tried that in a while
<greyback> but in theory, it should work
<Saviq> ok *something* happened, but nothing really interesting
<racarr> I haven't tried in ages :)
<racarr> back in 10-15. sun finally up over the buildings :p going to go for a walk
<Saviq> greyback, and where do I get the QPA plugins for desktop from?
<Saviq> qtubuntu-android still?
<greyback> Saviq: qtubuntu-android
<Saviq> ah, I had an :armhf version
<Saviq> <facepalm>
<Saviq> ohkay... /system/lib/libGLESv2.so not found
<ogra_> Saviq, ugh, that shouldnt be hardcoded
<Saviq> seems like there's stuff to fix in qtubuntu...
<ogra_> armhf != touch ...
<ogra_> (or s/touch/android/)
<Saviq> ogra_, I know it shouldn't
<ogra_> :)
<Saviq> ogra_, didn't find yet what linked to it
<ogra_> hybris usually ...
<ogra_> but that shouldnt be installed on a non touch armhf install
<ogra_> if something in mir hard depends on it thats wrong
<Saviq> yeah, qtubuntu-android depends on it
<ogra_> right
<ogra_> remove that :)
<Saviq> ogra_, libqubuntumirclient.so links to libhybris
<Saviq> racarr, ideas why that â happens?
<racarr> because of platform api perhaps?
<kdub> it uses egl?
<racarr> this is on desktop
<Saviq> racarr, yes
<racarr> maybe application_api isnt properly split from the rest of platform-api anymore
<racarr> Nice, olli at the cloud sprint :p
<Saviq> racarr, who would we ask to look into fixing qtubuntu on desktop?
<racarr> Saviq: I dont know so want me to do it? :p
<racarr> I did it once before so it can't be that hard to do it again.
<racarr> I can get to it in like 1 hour
<mterry> If I have (1) USC running, (2) multiple sessions active, and (3) the right half of the front session is transparent, will Mir correctly show the back session on the right half of the screen?
<mterry> racarr, kdub ^
<kdub> it should do alpha blending
<mterry> kdub, "should" or "I believe it does"?  :)
<kdub> i havent checked recently
<kdub> so, i think it does and havent heard otherwise
<kdub> mterry, is it something you don't see behaving correctly?
<mterry> kdub, well, no... But I don't have a tiny test case.  I'm working with two unity8 instances.  And maybe one of them is having a black background somewhere.  I'm looking into it
<mterry> kdub, I'm guessing there's not a nice test for this in mir code somewhere?  :)
<kdub> mterry, cool. the mir_demo_server_shell should be able to run 2 clients and you should see them on the screen together
<kdub> although, that's a slightly different use case than seeing alpha blending...
<mterry> kdub, I didn't know if there was maybe some clever Mir logic that disabled rendering a session that wasn't in focus
<RAOF> mterry: I believe the current state of the code is that it USC will only service swapbuffers requests form focussed sessions.
<mterry> RAOF, that's low level talk to me.  I'm guessing it won't update the bitmap, but will it render old bitmap to screen?
<kdub> RAOF, but didn't duflu put in support for occlusion because that wasn't the case?
<RAOF> kdub: Maybe?
<RAOF> I know there was one point where USC was only doing anything interesting with the currently focussed session, and hadn't noticed anything change.
#ubuntu-mir 2013-10-29
<alan_g> kgunn: what's the state of lp:mir? Can we safely MP the development branch today?
<kgunn> didrocks: ^ sorry i was unable to follow up...were you guys able to pull into archive ?
<alan_g> kdub: alf_ anyone for an easy review? https://code.launchpad.net/~alan-griffiths/mir/enable-unity-mir-to-avoid-SessionManager/+merge/193046
<alf_> alan_g: looking
<kdub> looks okay to me
<alan_g> kdub: We do reviews on lp not on irc 8^)
<kdub> what, we don't have an irc bot that helps with that yet? :P
<alan_g> Would you trust a irc bot with your credentials?
<kdub> eh, i guess not
<kgunn> sil2100: do you happen to know if mir got updated in trusty yesterday
<kgunn> greyback: btw, yes, my comment was your option4....but racarr 's comment confused me :) wrt whether or not the shell was "creating" surfaces
<greyback> kgunn: ok
<sil2100> kgunn: yes ;)
<kgunn> sil2100: thanks....any notes or caveats ?
<sil2100> kgunn: I saw it in trusty release today, even upgraded my device to it and did some testing
<racarr> Morning
<kgunn> racarr: mornin'
<racarr> kgunn: Howdy! How goes Oakland?
<kgunn> racarr: hey...if you want to come to the marriott at some point, i was pestering mterry (who's here) to try and get unityonmir running on the desktop
<kgunn> he was struggling a little...and likely just needs a little mir help
<kgunn> racarr: then i could buy you a beer :)
<racarr> kgunn:  When? Later today? Tomorrow?
<kgunn> racarr: today would be great...he was kind of fresh on it (he was looking last night)
<racarr> Ok. I need to finish breakfast and stuff but should be able to head over around 10
<racarr> kgunn: Same hotel right?
<racarr> Oakland marriot city center
<kgunn> right racarr
<racarr> ok
<racarr> its literally 25 minutes away so ill leave in 20 and be there soon :)
<racarr> kgunn: So my in person consulting services are $300 for the first hour
<racarr> and $200 for each following hour
<racarr> am I billing you, or michael
<racarr> :p
<racarr> jk I am excited to leave the house
<kgunn> racarr: :)
<kgunn> racarr: i may go m.i.a. this afternoon
<kgunn> racarr: but would love you to come tomorrow as well
<racarr> kgunn: I heard :p I google calendar stalk you so I know what's up
<racarr> you have a whole collection of fun meetings looking forward to hearing about them
<racarr> ok brt
<Mirv> robert_ancell_: hi just in case, not sure if you were pinged on bug #1245958 but now you are :) kdub is at least looking at it but had some device problems.
<ubot5> bug 1245958 in unity-mir "Apps crash with image 8" [Critical,New] https://launchpad.net/bugs/1245958
<Mirv> (you're listed as the contact for mir stack at https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dHFtUmlPOUtCRk8zR2dtaEpIbUVhMmc#gid=3)
<robert_ancell_> Mirv, I'll update that
<Mirv> thanks
<robert_ancell_> Mirv, I can't edit that but I've shifted teams, so escalate to kgunn
<Mirv> robert_ancell_: oh of course you have, sorry :) but can you think of someone else to put in there besides kevin who is already in the other column?
<Mirv> the idea is that first there's the contact person and then if needed an escalator
<Mirv> maybe a list of people
<robert_ancell_> Mirv, I don't know who Kevin has in mind, but just asking on #ubuntu-mir is probably the best step at the moment
<Mirv> robert_ancell_: ok changed that, it's at least better than having you there
<racarr> kdub: Happen to know anything about...
<racarr> ok well the set up is, one host mir_demo_server_basic
<racarr> then run a nested mir_demo_server_shell with an eglclient
<racarr> then run a second nested mir demo server shell with a second egl client
<racarr> and the first server dies with something about bad file descriptor
<racarr> err
<racarr> the first nested
<racarr> server
<racarr> the second server and the host server continue to function
<kdub> it does?
<kdub> seems something should die somewhere in that scenario
<kdub> Mirv, what's the magic incantation for phablet-flash to get trusty image #8? whatever i just did gave me image #5
<Mirv> kdub: --channel trusty-proposed
<kdub> groan
<kdub> all these channels :)
<Mirv> yeah took a while for me too, since there's no list command. but I peeked it from here then https://system-image.ubuntu.com/
<kdub> Mirv, thanks then
<Mirv> np
<kdub> racarr, is that causing problems? the second nested server continuing
<racarr> kdub: ? Why should something die
<racarr> I mean the first nested does die
<racarr> but that's the bug
<kdub> racarr, i thought you meant the bug was that the 2nd one continues
<racarr> oh no I mean
<racarr> the secnod one continues which is correct right
<racarr> but why dont they both
<kdub> and the cause of the 1st server dying is which client connecting? (1st server egl client, the 2nd server, or the 2nd server's egl client)
<racarr> I should figure that out
<racarr> it's either
<racarr> the 2nd server or the 2nd server egl client
<racarr> you can observe the first server and client working
<racarr> until you run the second one and then they die
<racarr> and you can observe the second one working
<racarr> checking...
<kdub> racarr, also, any logs/messages?
<racarr> kdub: It appears to be when the second nested client connects
<racarr> though it seems like there may be a few things that can happen,i.e. sometimes the second nested client works and the first dies, sometimes both die
<racarr> just a bad file descriptor exception with no location from
<racarr> the one that dies
<racarr> if it doesnt ring any bells off the top of your head dont worry too much, still lots of basic debugging to do
<kdub> racarr, yeah, none ring immediately
<racarr> kdub: oh it may actually be when the second client exits the first client dies lol
<racarr> I thought it was happening all at once because you immediately can't see the second client
<racarr> but also
<racarr> mir server doesnt end up with
<racarr> a transparent background
<racarr> so opacity doesnt work
#ubuntu-mir 2013-10-30
<mlankhorst> RAOF: I don't get the corruption on ati, is it only on the login screen?
<RAOF> mlankhorst: Hrumph. No, it's all the time.
<RAOF> mlankhorst: Although for me it's only really noticable on dual-head setups.
<mlankhorst> hmmmm
<duflu> mlankhorst: There are videos in the duplicates: https://bugs.launchpad.net/xmir/+bug/1233545
<ubot5> Ubuntu bug 1233545 in xserver-xorg-video-ati (Ubuntu) "XMir screen corruption on radeon chipset" [Critical,Confirmed]
<RAOF> As I say, throwing in a radeon_bo_wait(src) before the EXA copy seems to fix it for me - but might not, as maybe it still glitches if I load the machine heavily enough.
<mlankhorst> probably will
<mlankhorst> RAOF: hm what kernel?
<mlankhorst> and what resolution? Just in case it matters
<mlankhorst> RAOF: hm if screen automatically turns off, xset dpms force on doesn't redraw the entire screen again
<RAOF> mlankhorst: Latest saucy kernel; 1366x768 + 1920x1200
<alf_> RAOF: duflu: Any idea if it is reasonable to upgrade to trusty now?
<RAOF> alf_: Works for me.
<duflu> alf_: It's working find on the laptop. But as always, don't risk a production machine till release
<duflu> "working fine"
<alf_> RAOF: duflu: thanks, it's for my devel box
<mlankhorst> [  3420.199] (EE) Received unknown Mir lifetime event
<mlankhorst> hmz
<mlankhorst> bleh
<mlankhorst> not fatal though
<mlankhorst> those 2 are funny resolutions though
<popey> RAOF: who would be best to look at bug 1245958 ?
<ubot5> bug 1245958 in unity-mir "Apps crash with image 8" [Critical,New] https://launchpad.net/bugs/1245958
<mlankhorst> RAOF: unable to reproduce the corruption though :/
<mlankhorst> ok I broke trusty xmir, first time by hotplugging a display, second time by switching resolutions
<alf|upgrade> mlankhorst: perhaps https://github.com/afrantzis/xserver/tree/multimonitor-stabilize will improve things for you
<mlankhorst> alf|upgrade: that's not in trusty yet?
<alf|upgrade> RAOF: Have you tested https://github.com/afrantzis/xserver/tree/multimonitor-stabilize ? Should we get it in? (although perhaps it's not as relevant now, since we are going rootless only)
<alf|upgrade> mlankhorst: (no)
<mlankhorst> bah
<mlankhorst> RAOF: hm even if I overload the gpu I don't get glitches with ati
<mlankhorst> running 5 glxspheres or so ;)
<mlankhorst> so on my amd 5570 I'm unable to reproduce, macbook seems unaffected too
<alan_g> alf_: are you set up to verify a phone fix? https://code.launchpad.net/~alan-griffiths/mir/fix-1245958/+merge/193225
<alf_> alan_g: I can be ready within the next hour (need to flash latest image)
<davmor2> alf_: it's not progress further than 8
<davmor2> alan_g: if I knew how to install it I could have a go here on maguro
<alan_g> davmor2: not sure what the best approach is - I built and installed on the phone. (nb the default install path isn't the one that gets used)
<alf_> davmor2: the way I usually do it for quick tests is cross build on the desktop and just copy the .so files to the phone
<alan_g> so do I - but got caught by saucy/trusty switch
<davmor2> Yeah my knowledge on building packages is very limited, I just break them on the whole.  Note to self must learn packaging when I get some more time to myself :D
<alf_> greyback_: @dont-use-OrganisingSurfaceFactory MP, are you OK with me top-approving it? I saw that you reverted your top-approval...
<greyback_> alf_: just written the comment as to why I un-approved it
<alf_> greyback_: ok
<racarr> Morning
<kdub> hello racarr
<racarr> Hey kevin
<greyback_> alf_: alan_g: I'd like to set up a meeting tomorrow to talk about my Mir+QtScenegraph proposal. What time is suitable for you guys? Who else should attend from your side?
<alf_> greyback_: duflu and dandrader
<alan_g> greyback_: duflu, racarr, dandrader
<greyback_> alan_g: alf_: what's a good time when you talk with duflu?
<greyback_> early morning (UTC)?
<alan_g> greyback_: @"Please place under the method definitions in a private section" it is in a private section under the member functions. What do you mean?
<alf_> greyback_: http://www.timeanddate.com/worldclock/meetingtime.html?day=31&month=10&year=2013&p1=26&p2=136&p3=37&p4=196&iv=0
<alf_> greyback_: so probably 09:00 UTC
<greyback_> alan_g: I mean adding an explicit "private:" under the member functions, and putting it in there
<greyback_> as in http://pastebin.ubuntu.com/6330752/
<alan_g> greyback_: paraphrasing: move the private section before the protected one?
<alan_g> greyback_: Ah - was looking at wrong class
<greyback_> alan_g: oh, sorry
<greyback_> alf_: handy link, thans
<greyback_> +k
<greyback_> alan_g: alf_: tomorrow morning a bit early, in case not everyone has digested the doc. Friday ok?
<alan_g> greyback_: ok
<greyback_> will arrange separate meeting to suit racarr & dandrader
<alf_> greyback_: ok
<greyback_> ok, I'll arrange that, thanks!
 * alf_ is unhappy with the super-slow speeds from system-image.ubuntu.com for phone images (30Kb/s)
<alf_> actually 30 KB/s
<ogra_> alf_, weird ... its on the same line as cdimage.u.c
<alf_> ogra_: cdimage.u.c gives me much better speed (>500KB/s)
<ogra_> strange
<alf_> ogra_: e.g. try http://system-image.ubuntu.com/pool/ubuntu-2b15f23887a568f00df8bd9cf8e5ceab9a837bd66f0075a0cb04773c66442e0f.tar.xz vs http://cdimage.ubuntu.com/releases/13.10/release/ubuntu-13.10-server-armhf+omap.img
<ogra_> both get me ~280KB/s
<ogra_> (which is about as much as i get over this 2Mbit line)
<alan_g> greyback_: I've updated the unity-mir MPs - hope I've grokked the project style this time. ;)
<greyback_> alan_g: magic, thank you. Looking now
<greyback_> racarr: hey, is this week a bad week to have a meeting on the Mir&QtScenegraph doc?
<alan_g> kdub: assuming we've now unblocked the image 8 build it would be good to drop the dev-branch changes onto trunk. Maybe you could confirm the status is OK your afternoon? (Or nudge kgunn)
<kdub> alan_g, confirm the status is ok?
<kdub> like, test the dev branch out for problems, you mean?
<alan_g> kdub: no, make sure we're the image has gone and we don't have to fix it
<alan_g> s/ we're//
<kdub> ah, make sure it hits the builds
<kdub> rather, make sure it lands in the image
<alan_g> and that the image gets promoted
<greyback_> alan_g: I'm getting merge conflict with dont-use-OrganisingSurfaceFactory, can you double-check with unity-mir trunk please?
<alan_g> greyback_: sure
<kdub> alan_g, can do
<alan_g> kdub: thanks
<alan_g> greyback_: it's just bzr not liking changes on adjacent lines. updating...
<greyback_> alan_g: thank you
<alan_g> greyback_: you're welcome. Thanks for reviewing
#ubuntu-mir 2013-10-31
<kgunn> kdub: ping
<kdub> kgunn, pong
<kgunn> kdub: hey, thanks for the hoop jumping on that crasher and working with alan_g
<kdub> oh, sure, was just some shepherding a patch along :)
<kdub> got me all updated to trusty too
<omega9_> hello, I am interested in contributing to Mir and was wondering if there were mentored tasks that I could do to get started?
<duflu_> omega9_: Welcome. I would suggest learning to build the code (from bzr lp:~mir-team/mir/development-branch) and looking at the docs in there (which are also on the web: http://unity.ubuntu.com/mir/)
<duflu_> Once you can build, the immediate tasks are the bugs logged against the Mir project in Launcpad
<omega9_> duflu_, are there tasks that are specifically flagged as beginner?
<duflu_> omega9_: Not yet, sorry. It's more a matter of let contributors do whatever excites them, because that gets the ball rolling
<omega9_> OK, thank you.
<alf_> duflu: I retriggered fix-1246590
<duflu> alf_, Thanks but probably not necessary
<Xobs> I'd like to get an accelerated windowing system on my i.MX6-based board.  The vendor has Android support.  Is there a guide for extracting Android drivers from a BSP and using them in Linux?
<Xobs> Basically: Given an Ubuntu armhf install, what do I need to add to get accelerated Mir?
<duflu> Xobs: Mir will try to use the Android driver directly via libhybris. Though the Mir code often needs modification before new platforms work. So I suggest starting with doing an armhf build, running mir_demo_server_* and seeing what works/fails. Instructions are: http://unity.ubuntu.com/mir/
<duflu> Xobs: Although that assumes you've got an Ubuntu image booting at all. So maybe start with: https://wiki.ubuntu.com/Touch/Porting
<Xobs> duflu: What do I need to pull out of the Android BSP?  Or do I just need to copy the Android RFS somewhere on the Ubuntu RFS?
<Xobs> duflu: I've gotten it booting in the past by using debootstrap.  At least, stock Ubuntu.
<duflu> Xobs: Cool. Then follow the Mir build instructions and see if you can start one of the demo servers... or see where they fail
<duflu> Xobs: I'm not sure what you need to pull out and where. It's likely in the porting guide (https://wiki.ubuntu.com/Touch/Porting)
<Xobs> duflu: Thanks, I'll start working on that.
<Xobs> duflu: One followup question: How do GL-accelerated apps work?  Do all Mir-accelerated programs require GLES, or do they use Mesa for libGL?
<Xobs> duflu: The vendor only provides GLES binaries, not GL.  So what happens if e.g. I run something like Quake, that is written for full GL?
<duflu> Xobs: It's always GLES right now. On desktop that's Mesa. On Android that's the native GL library via libhybris
<Xobs> duflu: Fascinating.  So if (when?) Chrome or Firefox are ported, they'll automatically use Mir's GLES for WebGL?
<duflu> Xobs: Mir is GLES only right now. So no problem. The only exception is on desktop you can run GLX apps over XMir. But the server is still GLES
<Xobs> duflu: That is the best news.
<duflu> Xobs: Something always goes wrong in porting, so it's always feasible, but never guaranteed to work
<duflu> Xobs: XMir only supports desktop hardware though (intel/nouveau/radeon)
<duflu> ... so far
<Xobs> duflu: Right now, I'd just like to get compositing working first.  Dragging windows around on a 2560x1700 screen is a bit slow on this platform right now.
<duflu> Xobs: On most ARM systems, it will still be slow even when ported at that resolution. You're likely to hit fill rate limitations even if done perfectly
<Xobs> duflu: I had Wayland working (kinda), but not well at all.  I think Mir might be a better way to go.
<Xobs> duflu: Wayland was running at 10fps or so.  glesmark2 was running at 40-50fps.
<duflu> Xobs: It's hard to get a real answer of the physical frame rate though. Other than using your eyes. If you have desktop Ubuntu you can install the Benchmark compiz plugin from package "compiz-plugins" to find out the physical frame rate
<Xobs> duflu: The vendor's Xorg drivers don't support AIGLX, meaning compositing is done with Mesa.  But given stability problems I've seen with Debian and the possibilities of Mir, I'm thinking more and more of getting Ubuntu running instead.
<duflu> Xobs: Any idea what the fill rate specs are for that GPU?
<Xobs> duflu: Still looking in the manual, but one site says the GC2000 does 1.066 Gpix/s
<duflu> Xobs: So that's roughly 244FPS theoretical maximum at 2560x1700
<Xobs> duflu: Yes, finally found the page in the manual.  1.066Gpix/s, 88M tri/s.  I think that Mir is the way to go to get good windowing performance.
<duflu> Xobs: Sure. Only thing is Mir doesn't yet have a usable native desktop. We're working on that.
<Xobs> duflu: I thought Ubuntu Phone used Mir?  Or is that Unity running under XMir?
<duflu> Xobs: Yeah that's native, but I meant desktop. That's a touch OS
<Xobs> duflu: Alright.  I'll give the porting guides a read, and fix errors as they crop up.
<duflu> greyback: Somehow I've run out of time to review your doc today. I trust it's no disaster if it's not this week? (though it might be)
<greyback> duflu: it's not a disaster, but I'd definitely like your input. Monday better?
<duflu> greyback: I will be aiming for tomorrow anyway
<greyback> duflu: ok
<alan_g> kdub: I'm at EOD, but found an interesting problem - https://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/73/console  runs the tools/setup-partial-armhf-chroot.sh. And liblttng-ust0 doesn't exist ... looks like liblttng-ust2 is right. (From chant on #ubuntu-ci-eng)
<alan_g> It's causing merges to fail
<kdub> alan_g, ah, could MP a bump easily enough
<cyphermox> kdub: could you give me a few minutes to look at the script and come up with a better solution?
<alan_g> cyphermox: talk to kdub about the script ^
<cyphermox> ahha ;)
<cyphermox> kdub: can that script be deleted or is that used for something critical?
<kdub> cyphermox, its mainly used in a development workcycle at the moment
<kdub> cyphermox, so it can be deleted from the mir tree, we'll probably want to keep it around as a tool for mir devs though
<kdub> cyphermox, if there's a better solution though, that would be great
<cyphermox> well, if it's used manually it should still be updated to use the right libraries
<cyphermox> but I guess the CI magic shouldn't be using it
<cyphermox> kdub: has that script actually worked in the recent past?
<cyphermox> seems to me like libboost is maybe broken and not so downloadable in this fashion
<kdub> cyphermox, should work now
<cyphermox> ok
<cyphermox> then maybe it's my changes...
<cyphermox> would you be able to test them? I put stuff over there: lp:~mathieu-tl/+junk/test-cross-compile
<kdub> looking..
<cyphermox> in the meantime I'll just do a MP for the quick bump to liblttng-ust2, but the changes I'm testing should help avoid having to change the script every time there is a library transition
<kdub> cyphermox, sounds great
<cyphermox> kdub: https://code.launchpad.net/~mathieu-tl/mir/armhf-chroot-script-fixes/+merge/193480
<kdub>  +1ed, thanks
<kgunn> kdub: or racarr ... can either of you  review...easy one https://code.launchpad.net/~mir-team/mir/bump-mirserver-to-10/+merge/193515
<kgunn> quick note on it, i saw duflu had already bumped the debian version (for the abi)
<kgunn> but alan_g told me earlier we have a true api break with unity-mir as well
<kgunn> hence this mp
#ubuntu-mir 2013-11-01
<duflu> Back in 30ish
<alan_g> alf_: I've got a workman turning up in the next few minutes - I might be a little late for greyback's meeting
<alf_> alan_g: ok
<alan_g> greyback: : I've got a workman turning up in the next few minutes - I might be a little late for your meeting
<greyback> alan_g: no worries
<xnox> alan_g: alf_: so emulator is mostly working now. There is functional adb and networking. So far it attempts to boot into "mir" mode.
<xnox> I've made sure to compile all android container unstripped (so debug symbols are intact)
<alf_> xnox: I am missing some context here :)
<xnox> attempting to start unity8 results in a segmentation fault, trying to run it under gdb only says that stack is corrupt =/
<xnox> alf_: so I want to ask for help bringing up mir / any graphical output on the emulator =)
<alf_> xnox: which emulator is that?
<xnox> alf_: sometime back kgunn recommended you or alan_g as UK time people, who can help out with it.
<alan_g> xnox: what emulator?
<xnox> alf_: it's android-emulator packaged to run Ubuntu Touch. So it boots unflipped/read-only system image, with an android container.
<xnox> alan_g: alf_: https://wiki.ubuntu.com/Touch/Emulator
<xnox> also i've been posting about on ubuntu-touch.
<xnox> it's a QEMU based ARM virtualised machine, running linux-goldfish kernel with android container and everything mostly the same as normal android device.
<xnox> (apart from well, not displaying mir)
<alan_g> xnox: so, what happens if you try running e.g. mir_demo_server_basic?
<alf_> xnox: you can try running Mir on its own to see what's going on
<alf_> alan_g: You beat me to it! :)
<alan_g> alf_: is it a race?
<alf_> alan_g: No, but we had a photo-finish nonetheless ;)
<xnox> root@ubuntu-phablet:/# mir_demo_server_basic
<xnox> bash: mir_demo_server_basic: command not found
<xnox> (this is running Ubuntu Touch rootfs, should be similar to mako/maguro tarballs et.al.)
<ogra_> its in a separate package
<alan_g> xnox: can you install mir-demos? Or do you need to build it?
<xnox> alan_g: i can, but it's very slow. I might repack a tarball and relaunch it.
 * alan_g thinks Mir won't work unless it is installed
<xnox> same as before:
<xnox> root@ubuntu-phablet:/# mir_demo_server_basic
<xnox> __pthread_gettid -2
<xnox> Segmentation fault
<xnox> which is similar to running unity8 et. al.
<xnox> http://paste.ubuntu.com/6340712/
<xnox> alan_g: alf_: if you could figure out what's broke, i'd be happy to fix it both in android, ubuntu and emulator. But at the moment i'm not sure what's wrong, as pretty much everything else is working.
<greyback> a BT like that always makes me suspect hybris
<xnox> and i don't usually work on graphics at all.
<alan_g> debug symbols might help with the BT
<alan_g> what happens if you try run "mir_demo_server_basic --display-report log"
<alan_g> That might give a clue as to how quickly it segfaults
<alf_> xnox: +1 debug symbols might help with the BT
<xnox> alan_g: same output.
<xnox> alan_g: so it's something fundamental =/
<alan_g> xnox: ack
<xnox> alan_g: alf_: on android side in logcat i see that it's loading up EGL emulation, there is also GLES_android, GLESv1_CM and GLESv2 available.
<alf_> xnox: I wonder if running under valgrind could give you more clues
<rsalveti> kdub: ping
<kdub> hello rsalveti
<rsalveti> kdub: hey, so we were debugging the nexus 7 (tegra 3) issue yesterday, and we basically believe our code path might not be doing what the driver expects us to do
<rsalveti> the crash happens in pthread_mutex_lock
<kdub> rsalveti, 'our code path', meaning in hybris or mir?
<rsalveti> and the lock is basically a pointer, unitialized
<rsalveti> kdub: mir, by the way we're using the hwcomposer/gralloc
<rsalveti> the first time it uses that pointer is already when trying the lock
<rsalveti> so we believe we might be skipping a call or step that initializes that value internally
<kdub> rsalveti, i don't know of something that surfaceflinger does that we're skipping
<kdub> which function call into hybris has the problem?
<rsalveti> kdub: the pthread_mutex_lock
<rsalveti> kdub: the mutex pointer is not initialized, so just garbage
<rsalveti> that's why when we try to access it, it crashes
<rsalveti> I'm not sure yet that this is hybris specific at this point
<kdub> right, but do we know the last function call mir makes?
<rsalveti> do we have any sort of test cases/tools for hwcomposer/gralloc?
<kdub> just the mir tests
<kdub> mir_demo_standalone_render_to_fb should just drive the display
<rsalveti> kdub: right, let me see, the crash happens with mir_demo_server
<kdub> but it will have the same problem as the server
<rsalveti> kdub: right
<rsalveti> kdub: let me try to get a better backtrace
<rsalveti> kdub: but the issue, iirc, was that it was coming from gralloc
<rsalveti> which is just a blob, making it harder to get the full trace
<kdub> right
<kdub> i mean, it could be some dumb thing like...
<kdub> on nvidia you have to open {gralloc, fb, hwc} in some specific order
<rsalveti> kdub: yeah
<brainwash> how do I switch to hardware cursor when running xmir?
<kdub> i always like how the interface you couldn't quite get right at 6pm makes a lot more sense at 10am the next day
<alan_g> kdub: that's after you've realised how to write the test. Right?
<kdub> alan_g, yeah, you still have to decide what sort of things you want the test to test
<alan_g> kdub: well if you don't know what "works" looks like it is hard to get the interface right
<rsalveti> kdub: yeah, mir_demo_standalone_render_to_fb crashes the same way
<rsalveti> kdub: do you have a n7 around?
<rsalveti> kdub: I'm checking render_to_fb.cpp, but it seems the the buffer itself is null
<rsalveti> which could be the reason for the mutex garbage content
<kdub> yes, but when you say buffer, you mean, mir's buffer class?
<rsalveti> kdub: crashing in src/server/graphics/android/hwc10_device.cpp -> hwc_device->set(hwc_device.get(), 1, &contents);
<kdub> rsalveti, hmm
<kdub> i have to tinker with that then
<kdub> i'm actually working on improving that part of the code at the moment, maybe i'll find somehting
<rsalveti> kdub: any ideas which we could try?
<kdub> rsalveti, perhaps the list that's submitted there 'contents' isn't formed the way the driver expects it
<kdub> hard to so how its malformed without tinkering with it though
<rsalveti> kdub: so, when we set HWC_SKIP_LAYER at the hwcompositor layer, it doesn't crash
<rsalveti> kdub: nothing in the screen, as expected, but the gl path and such is working as expected at least
<kdub> rsalveti, thats good new news
<rsalveti> kdub: so it might be something related with the hw layers
<kdub> rsalveti, yes, it looks like it is
#ubuntu-mir 2013-11-02
<brainwash> so (x)mir cannot handle hybrid graphics if both gpus are turned on?
#ubuntu-mir 2013-11-03
<mardy> hi! Does Mir use EGL drivers, or does it require some modifications to them?
<RAOF> mardy: The question is sort of malformed; EGL is a cross-platform(ish) way of mapping from a windowing system to GL/GLES/OpenVG/etc.
<RAOF> mardy: So, accelerated Mir clients use an EGL driver - with Mir platform support - to draw to the surfaces they've created through Mir.
<racarr> Mir uses EGL, but requires additional driver support basically
<RAOF> mardy: And on the server-side, Mir uses various EGL platforms, yes. On the free stack Mir uses the drm platform to do the KMSâGLES mapping; on Android it loads the magical android stuff to do the same job.
<RAOF> racarr: Also, a fine Sunday evening to you!
<racarr> RAOF: Howdy :)
<racarr> Happy monday morning
#ubuntu-mir 2014-10-27
<alan_g> alf_: happy with the updates? https://code.launchpad.net/~alan-griffiths/mir/some-acceptance-tests-use-mir-Server-API/+merge/239406
<snadge> is it possible to log in with unity 8 at the moment?
<anpok> snadge: it should be.. but havent tried for a while
<snadge> i suspect some kind of systemd issue
<anpok> .. just upgrading my test vm
<anpok> snadge: hm works for me..
<snadge> vivid?
<anpok> oh just last utopic..
<snadge> vivid is super breakage land.. this is the rebase with jessie.. systemd etc
<kdub> morning
<alan_g> kdub: afternoon
<alan_g> Anyone about to review this? https://code.launchpad.net/~alan-griffiths/mir/some-acceptance-tests-use-mir-Server-API/+merge/239406
<racarr> Good morning!
<racarr> standup: Wrote some tests for vsync timings from server over the weekend implementation monkey todya
 * alan_g wishes launchpad allowed multiple prerequisites (as he's got yet another branch that depends on two branches still being reviewed).
 * AlbertA wishes you could list external branch dependencies too
<alan_g> true
<alan_g> racarr: want to express a preference before I go offline? https://code.launchpad.net/~alan-griffiths/mir/fix-1386185/+merge/239743/comments/589089/+reply
<racarr> alan_g: Is this a case for an atomic?
<alan_g> It seems confusing introducing an atomic variable when there's already a mutex around covering "everything".
<racarr> hmm
<racarr> alan_g: Ok I guess leave it as is :)
 * alan_g resists temptation to replace LL59..62 with "(std::lock_guard<decltype(mutex)> lock(mutex), ++disconnecting);"
<alan_g> racarr: I don't have strong feelings for any of the options.
<racarr> alan_g: me either I guess...
 * alan_g hopes one of his MPs gets approved before his tomorrow.
#ubuntu-mir 2014-10-29
<duflu> RAOF: Can you remove the "devel" series now? I think we're used to "lp:mir" now.
<RAOF> duflu: Maybe? Let me check.
<duflu> I can't... You own it :)
<RAOF> Turns out that I can :)
<RAOF> Oh, wow.
<RAOF> Yeah, that renderer frig is a really terrible cludge.
<RAOF> Ok CI. Review that branch before I wake up tomorrow morning. I dare you!
<alan_g> alf_: PidFakingSessionCoordinator?
<alf_> alan_g: ok
<alan_g> alf_: in Washington we talked about adding "emergency cleanup" handling to mir::Server. Have you thought about that yet?
<alf_> alan_g: no
<alan_g> OK. Unless you're keen to do it I might look at that. (Once I've figured out what is happening to ClientCredsTestFixture.session_authorizer_receives_pid_of_connecting_clients)
<alf_> alan_g: It's not in my short-term plans, so feel free to pick it up if you have the cycles.
<alf_> alan_g: currently focusing on main loop and a couple of assigned bugs
<anpok> kdub: which part is too heavy, in real_hwc_wrapper?
<anpok> would you prefer having the same interface has hwc, without a structure and conversions taking pace?
<anpok> +l
<kdub> anpok, somewhat, although maybe we could just log what's going on in terms of the api
<anpok> hmm oh!
<anpok> i missed adding the logs
<kdub> like the point of that class is to be light and easy to pop logging in and out at the hwc api level
<kdub> and if we do type conversions in there, it becomes thicker and thicker. Like, I could be sending a std::list<Renderables> in the prepare and set functions and converting the types in the 'RealHwcWrapper', but
<kdub> thats the job of other classes to do the tricky work of converting the mir types to the raw hwc stuff
<kdub> like, originally, I just mocked out the hwc type, but that proved zany in the test code (list checking in particular)
<kdub> and the wrapper provided cleanups in terms of the code that executes the logic, as well as in the test code for HwcDevice
<kdub> anpok, I guess my main suggestion is
<kdub> since we have the need to requery this information from the hwc device, we should have a class that does the some sort of things that the factory does
<kdub> and the DisplayDevice implementers can use that to get subsequent display configurations
<kdub> which cuts down on duplication, and isolates the tricky business of gathering that information
<anpok> the resource factory?
<kdub> because the hwc api designers didn't really think it through and make it easy for us
<anpok> hm i thought the duplication would go away as soon buffer creation would rely on the display configuration outputs provided by the display device..
<anpok> i thought display device would be the indirection to use for that purpose ..
<anpok> .. differing between fb, hwc-1.0/fb and hwc-1.1
<kdub> well, there's more distinctions to be made
<kdub> like hwc 1.3 supports opaque pixel formats and such
<kdub> so hwc 1.1-1.3 have the same fundamental stuff going on in the business of posting displays, but the initial arrangements vary
<anpok> kdub: so you mean I should be moving assembling of mir display structures to resource factory?
<anpok> ok misread what you said above
<kdub> right, like the code in framebuffers (in the anonymous namespace) may as well be its own helper class that the Framebuffers can use to make the fb-buffers
<kdub> and some other part of the system (even, mga::Display) can use to generate the configuration
<kdub> the DisplayDevice implementations have enough to juggle in the business of simply posting the layer list
<dandrader> I just built qtmir on my desktop. a test binary refuses to run because it's looks for libmirserver.so.25 whereas libmirserver.so.26 is the one installed
<dandrader> I wonder what's out of sync
<dandrader> oh, it's the installed /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqpa-mirserver.so
#ubuntu-mir 2014-10-30
<RAOF> You can get the best linker errors with symbol versioning :)
<didrocks> hey guys
<didrocks> so, I'm trying the desktop next image with unity8 + Mir
<didrocks> however, I have a dell XT2
<didrocks> which is creating a lot of wrong inputs from the touchscreen
<didrocks> (like random click and cursor movement)
<didrocks> with Xorg, I was able to disable it with: xinput set-prop 'N-Trig MultiTouch' 'Device Enabled' 0
<didrocks> anything similar with Mir?
<alan_g> didrocks: probably not (yet). Of the folks that have dived into input anpok's not around today and racarr isn't up yet.
<didrocks> alan_g: ok, I'll try to poke racarr later today, thanks!
#ubuntu-mir 2014-10-31
<alan_g> greyback: here's the MP for the features we discussed yesterday. Do the tests capture your requirements correctly? https://code.launchpad.net/~alan-griffiths/mir/terminate-and-abort-in-mir-Server-API/+merge/240236
<greyback> alan_g: it addresses my main issue with run_mir, yes, thank you
<alan_g> greyback: My plan is to retire run_mir and get qtmir using Server::run()
<greyback> alan_g: suits me nicely
<alan_g> greyback: I'll do the migration work with qtmir once I've got this landed, but may need some guidance on branches and testing.
<greyback> alan_g: ok. qtmir's testing story quite weak, so I'll probably asking your guidance there :)
<alan_g> Yeah, I guessed it was "build the whole stack and see if smoke comes out of phone"
<greyback> mostly yeah
<alan_g> is it lp:~mir-team/qtmir/devel-mir-next I should be looking at? (Or lp:qtmir?)
<greyback> alan_g: lp:qtmir
#ubuntu-mir 2014-11-02
<misteryJOE> it seems i have mir server running , does anyone know how to start Xorg ontop of mirserver?
#ubuntu-mir 2015-10-26
 * Guest42341 What a fine day for science! 
<RAOF> *Man* we don't care about object ownership at all.
<RAOF> Want to receive events when a new surface is created? Congratulation! You're now a part-owner in all surfaces.
<RAOF> Oh, for the love of god. Of *course* the_session_listener is a a singleton usable only by a consumer *outside* Mir.
<RAOF> Raaaargh. Hulk SMASH!
<Guest42341> :))
<duflu> anpok_: It appears in my bucket-of-cheap-spare-mice that I have a choice between too-fast or smooth-but-sometimes-missing-kernel-events. Any hints for making mice smoother or more reliable?
<duflu> Hmm, maybe "don't use cheap spare mice"
<alf> vogons: Please take a look at the Display configuration API proposals in https://docs.google.com/document/d/1wpoHVYdPZGthN2WS8oDvhRlpyuUqrizK1C4quE4XwMk/edit# so we can have more meaningful discussions during upcoming meetings (standup, eu/aus/us syncs)
<sturmflut2> I finally rebuilt glmark2 against the stable phone overlay PPA so it works on OTA-7 again, but it looks like at least on krillin sometimes the OpenGL ES context freezes until I trigger an event in Unity8, e.g. swipe in the launcher or the app switcher.
<sturmflut2> I can post a link to the new click package for testing purposes
<sturmflut2> Also happens on mako
<alan_g> sturmflut2: thanks for trying the rebuild. I'm not sure who's best placed to investigate, but the link will help.
<sturmflut2> http://hogsmeade.lieberbiber.de/~sturmflut/glmark2.sturmflut_0.5.0_armhf.click
<sturmflut2> alan_g: At least the binary continues to write to stdout and switches between the benchmark scenes, so it's not completely frozen I think, it keeps trying to output something that maybe then isn't handed to the display in the end?
<sturmflut2> I'll build it against X11 on the desktop too to make sure it's not a problem with the glmark2 code itself
<Guest42341> sturmflut2, glmark2
<Guest42341> Segmentation fault (core dumped)
<Guest42341>  (on wily)
<sturmflut2> Works fine on a 15.10 desktop with an Intel Ivybridge CPU/GPU (i915 driver)
<alan_g> alf: any thoughts on the above?
<duflu> sturmflut2: Not your fault. We know about it... https://bugs.launchpad.net/qtmir/+bug/1497828
<ubot5> Launchpad bug 1497828 in qtmir (Ubuntu) "Apps appear to freeze in Unity8, although they are really still rendering (swap interval zero). Need to interact with the shell to unfreeze it." [High,Triaged]
<duflu> alan_g: That freeze is a known issue ^
<duflu> And then it was EOD
<alan_g> duflu: ack, have a good evening
<alan_g> anpok_: what's the state of https://code.launchpad.net/~andreas-pokorny/mir/load-all-supported-input-platforms/+merge/274421? Your last comment links it to https://code.launchpad.net/~andreas-pokorny/mir/move-cookie-test-to-acceptance-tests/+merge/275502 which got rejected.
<anpok_> alan_g: bschaefer made a better version of the same
<anpok_> so I removed my mp
<anpok_> and that one landed this morning
<alan_g> So load-all-supported-input-platforms is good to go?
<anpok_> yes..
<anpok_> evertything is currently waiting on the input abi bump
<anpok_> which I reworked after a discussin with raof hmm on friday
<alan_g> Great.
<alan_g>  alf: could you look over https://code.launchpad.net/~alan-griffiths/mir/nested-server-applies-display-config-policy/+merge/275542 - I think it is orthogonal to your proposal (modulo stuff that still needs fixing) but I'd like your thoughts.
<alf> alan_g: doing that right now (I also linked a bug report about this I had file some time ago)
<alan_g> :)
<alf> anpok_: When you get the time could you please take a look at https://code.launchpad.net/~alan-griffiths/mir/nested-server-applies-display-config-policy/+merge/275542 (see my last comment)
<alan_g> anpok_: Looks like the merged pre-req confuses LP - https://code.launchpad.net/~andreas-pokorny/mir/input-configuration-api/+merge/273975
<tjaalton> I'm about to push mesa 11.0.4 with ftbfs fix (1509005) to xenial, FYI
<anpok_> alan_g: aye
<anpok_> alf: I believe that is close to the reverse of the bandaid we had
<anpok_> alf, alan_g: I believe the problem back then with the split-out greeter was that the screen is turned off usc switched to a newly craeated greeter session that turned the displays back on again.. because the nested server applied the display configuration on startup..
<anpok_> *when the screen..
<anpok_> but a lot changed since then... maybe usc would catch that..
<anpok_> adding that to the review
<anpok_> (i really didnt like the 'solution' back then)
<alan_g> anpok_: that sounds like it would be caught by the check I added for "!= current config"?
<anpok_> alan_g: hm what if the nested session sees the screen turned off on startup?
<alan_g> anpok_: rather than speculate, there ought to  be a test case (even if we decide to land these changes first).
<anpok_> i mean then the configs would/might be != .. and it would apply them - still this is the wrong place to make that decision
<anpok_> yes.. imo the nested server should do that..
<alan_g> Hmm. The greeter doesn't go through the nested server, so these changes shouldn't affect it.
 * alan_g wonders if he understood the scenario correctly
<anpok_> alan_g: hm oh i dont know how the greeter is done currently. That split greeter back then never landed..
<anpok_> so for that scenario you need to have a nested session, turn the screen off, start a second nested session, focus the second nested session..
 * alan_g was thinking of the spinner
<anpok_> hm spinner is not submitting a config, is it?
<alan_g> no
<alan_g> Sounds like this isn't a scenario that currently matters. (And with the other bugs in this area I suspect it has problems anyway.)
<alan_g> And at least a part of it is about USC policy.
<anpok_> hm i think I wrote something similar to the review
<kdub> should we be sending an initial visibility event? (I think we should be)
<alan_g> kdub: what do you mean by "an initial visibility event"?
<kdub> https://code.launchpad.net/~kdub/mir/initial-visibility-event/+merge/275704
<kdub> :)
<alan_g> alf: NI answered? https://code.launchpad.net/~alan-griffiths/mir/nested-server-applies-display-config-policy/+merge/275542
<alf> alan_g: yes
#ubuntu-mir 2015-10-27
<shuduo> hi, anyone has idea how to make mir working as snap on RPi2 or BBB?
<greyback> alan_g: good morning. Small conflict (1 file) when merging trunk into https://code.launchpad.net/~alan-griffiths/qtmir/test-harness-for-MirWindowManager/+merge/274221 - can you please address
<greyback> about time we land that
<alan_g> greyback: sure - otp now, after that
<greyback> thank oyu
<alan_g> shuduo: I don't know about issues specific to RPi2 or BBB, but it ought to be possible to bundle the mir libraries along with your chosen server and client(s) in a snap.
 * alan_g speaks with the confidence that comes from never having created a snap package
<shuduo> alan_g: good to know. there is a lp:~mir-team/mir/snappy-packaging for building mir snap. i have verified on X86 pc and qemu. it works good. then i can run a simple QT app snap on top of mir snap. I want to reproduce the procedure on arm platform. do you think it's possible?
<alan_g> well, we do run Mir on arm devices. ;) But the graphics drivers tend to be a lot less standardized and need device specific "bring-up".
<shuduo> alan_g: i guess you are mentioning ubuntu touch. right? I'm sure if we can bring up graphic without android running in container there are traditional Linux XWindow environment working on RPi2 and BBB. how far to bring mir up on them?
<shuduo> s/I'm sure/I'm not sure/
<shuduo> runningin container. There are traditional Linux XWindow...
<shuduo> sorry my IRC running on a remote server so bad latency key response.
<alan_g> shuduo: if you've got something like mesa & kms in the stack that could work.
<shuduo> alan_g: let me check. thanks.
<tjaalton> mesa fails to build on xenial because of this: http://pastebin.com/G7pLiWRT
<tjaalton> probably same on wily too
<dandrader> anpok_, have you ever tried logging into a unity8-mir  session inside a virtual box VM? here it just freezes :/
<anpok_> dandrader: yes.. did that frequently to test mir releases
<anpok_> but there was also a recent problem in kvm on wily
<anpok_> or rather wily on kvm.. for some reason the mouse driver change its behavior
<dandrader> anpok_, hmm... so you're seeing the same issue as well?
<anpok_> i believe there is a bug fot that..
<anpok_> https://bugs.launchpad.net/mir/+bug/1489522
<ubot5> Launchpad bug 1489522 in Mir "mir fails to open the right mouse device in kvm/qemu" [Undecided,New]
<dandrader> anpok_, which is two months old today :(
<anpok_> yeah include it into your prayers..
<anpok_> bbl
<dandrader> anpok_, not sure if it's the same thing though as in my vm it doesn't even get to start unity-system-compositor. never gets to leave the lightdm greeter UI
<dandrader> :)
<alan_g> greyback_: I did fix the conflict in https://code.launchpad.net/~alan-griffiths/qtmir/test-harness-for-MirWindowManager/+merge/274221 (but CI seems to be slow validating it).
<greyback_> alan_g: ok, thanks
<SturmFlut> Dear Mir team, I just connected my Nexus 4 to a projector, coupled keyboard and mouse via Bluetooth and the phone turned into a desktop. You guys are my personal heroes and this message is good for a beer if we ever meet in person ;)
<bschaefer> SturmFlut, that would be for bregma (and others) :)
<SturmFlut> Just come to Ubucon Europe 2016 and ask me for the beers :)
#ubuntu-mir 2015-10-28
<robert_ancell> duflu, hey, is there anything in particular that needs working on in xmir while you are away?
<duflu> robert_ancell: Yeah I've tried to keep the bug lists accurate. I'll email the URLs to you
<robert_ancell> duflu, ta
<bschaefer> duflu, when does your vacation start?
<duflu> bschaefer: One week
<bschaefer> duflu, cool, enjoy!
<tjaalton> duflu: hey, so will mir revert back to the old pkg-config filename for mir-client-platform-mesa-dev, or provide both?
<duflu> tjaalton: The plan is 0.17.1 provides both. But 0.18.0 only the new one
<tjaalton> ah, good
<duflu> If and when 0.17.1 goes out
<tjaalton> so I can upload this new mesa to xenial then
<duflu> tjaalton: So long as it doesn't contain -dev and assuming we don't release 0.17.1 in xenial :P
<tjaalton> right
<duflu> Simple :)
<RAOF> Even *if* we release 0.17.1 in xenial; 0.17.1 provides both names.
<duflu> RAOF: Good point but we don't want xenial packages getting into the habit of the old name
<RAOF> Indeed.
<duflu> Which reminds me, Xmir will probably need to support both
<duflu> That's a bit ugly
<duflu> Oh, no it won't
<RAOF> It can always just use the new name.
<duflu> yes
<RAOF> Right.
<duflu> It does already
<alan_g> greyback: @https://code.launchpad.net/~alan-griffiths/qtmir/test-harness-for-MirWindowManager/+merge/274221 - are there known problems on wily? (The latest failure doesn't look related to the MP)
<greyback> alan_g: I think CI on wily is busted. As long as vivid+o is ok, I'd be happy
<alan_g> greyback: I won't look any deeper then. Thanks
<zzarr> alan_g, I think I'll skip porting mir to freon, it's too easy to install ubuntu on a sd-card
<zzarr> if I download an image for a device with the same SoC as I have in my device, can I use the binary blob with libhybris?
<alan_g> zzarr: ok
<zzarr> am I correct in my assumption that I can use GPU drivers from any Android device with the same GPU type (same SoC, RK3288)?
<alan_g> zzarr: I'm not familiar with the issues involved, but I suspect you'd at least need compatible firmware drivers. kdub may have a clearer idea (but it is still early on his part of the planet.)
<kdub> zzarr, in theory it should work
<zzarr> kdub, okey, what firmware will I need?
<kdub> whatever firmware works with the android drivers
<zzarr> kdub, do I need to modify the kernel? (I have an kernel for Arch Linux right now)
<kdub> android will have its own kernel drivers that have to be around in whichever kernel you're using
<zzarr> kdub, is there a step by step explanation how to do it?
<kdub> not really, we use the android kernels in ubuntu touch, i would just go with those
<zzarr> but it's not a Android based device I have, it's a ChromeBook (ASUS ChromeBook Flip)
<zzarr> so there's no Android kernel for it (if I can't use a Android kernel for another device)
<kdub> well, to use the android drivers and hybris, you'll need the same environment that those drivers run in under android
<zzarr> yes, but I thought that meant I needed just an lxc
<zzarr> this it what I thought, I could install Ubuntu, have and install the necessary Android drivers in a lxc and install the firmware for the drivers
<kdub> the userspace drivers have to talk to the kernel drivers properly
<kdub> and if there are no kernel drivers for the device, they wont work
<zzarr> ohh, right, I forgot about that
<zzarr> alan_g and kdub, thanks for your help
<kdub> yep, no problem
<anpok_> dandrader: which version of mir did you try to run in kvm?
<alan_g> \\o/ Got a failure on krillin
<alan_g> /o\ not the one I was trying to reproduce
<anpok_> i think I have to revert the change to the mesa hack
<alan_g> anpok_: just thinking... could we change mesa to do something like lp:~vanvugt/mir/fix-1510218 and lose the hack completely?
<bschaefer> alan_g, nice
<bschaefer> o
<bschaefer> alan_g, sooo another error that could come up later?
<anpok_> the odd thing is .. we do access the native egl display (which does the dlopen for mir symboles) within the mgn::Display .. which already has the guestplatform
<anpok_> which means we already reloaded that library
<anpok_> because that happens just before the platform creation..
<anpok_> alan_g: hm I dont understand
<anpok_> ah change mesa!
<anpok_> yeah we could do sane things in mesa instead of what we currently do
<alan_g> bschaefer: I don't believe in coincidences. This one proves there's racy code about and we all know races.
<dandrader> anpok_, the one in wily. 0.17 I think
<anpok_> dandrader: with the one in wily I do get something on screen .. but for some reason use input does not work
<bschaefer> alan_g, very true, hopefully caused by the same issue
<dandrader> anpok_, I downloaded the wily iso from ubuntu.com. installed it in a vm. installed the unity8 session package in it and tryied logging into it
<anpok_> which one?
<anpok_> i mean which session package
<dandrader> anpok_, unity8-desktop-session-mir I think
<dandrader> anpok_, so you can select a unity8 mir session from the lightdm greeter
<anpok_> dandrader: hm ok .. this works... then screen turns black for a few seconds.. then I see the u8 greeter.. and run into the input problem
<dandrader> anpok_, oh, so you get way further than I. for me the greeter UI gets stuck
<dandrader> anpok_, and running "ps -rf"  I see that usc is not even running yet
<anpok_> greeter ui gets stuck .. that means usc is not starting up
<anpok_> could you paste the unity-system-compositor.log from var/log/lightdm?
<dandrader> -ef I mean
<anpok_> bbl
<bschaefer> dang Failed to enter Recovery
<bschaefer> so the version on CI is 311?
 * bschaefer wonders why 312 is the current image im pulling
<alan_g> bschaefer: fginther said CI is 312, where do you see 311?
<bschaefer> alan_g, o i though someone in google hangout mentioned 311...
<bschaefer> that could have been their run or a prev run
<alan_g> bschaefer: that might have been in the context "it started working with 311 and stopped with 312"
<alan_g> We should record all hangouts for reference
<bschaefer> ooo i see
<bschaefer> yeah
<bschaefer> alan_g, i wish there were logs...
<bschaefer> just simple text logs
<bschaefer> but a recording would be nice
<bschaefer> huh, my krillin does not want to be flashed
 * bschaefer tries again
<bschaefer> alan_g, you just used: ubuntu-device-flash touch --channel=ubuntu-touch/rc-proposed/ubuntu --bootstrap
 * bschaefer hasnt flashed this krillin in some time
<greyback_> quick C++ question, how can one forward declare the MirFormFactor enum?
<alan_g> I didn't "--bootstrap", but otherwise yes
<greyback_> I'm unable to specify a working storage type
<alan_g> enums are a PITA because of C legacy. The underlying type needs to be known
<greyback_> that's what I'm suspecting. oh well
<bschaefer> enum class?
<bschaefer> i suppose that wont work for that though :(
<camako> bschaefer, http://askubuntu.com/questions/602035/how-do-i-use-ubuntu-device-flash-with-the-bq-aquaris-e4-5-and-aquaris-e5/602037#602037
<camako> bschaefer, you need to use a recovery image
<camako> wget http://people.canonical.com/~jhm/barajas/recovery-krillin.img
<camako> ubuntu-device-flash touch --channel ubuntu-touch/rc-proposed/bq-aquaris.en --recovery-image /home/camako/Downloads/recovery-krillin.img --developer-mode --password=0000 --bootstrap
<bschaefer> camako, oo ok, thanks!
<camako> (channel will be different for you)
<bschaefer> i thought i'v done this before with that but things could have changed
<camako> bschaefer, yeah they have
<bschaefer> camako, cool thanks
<camako> bschaefer, also you need to put the device in "bootloader" mode as explained in that link by pressing certain buttons
 * camako wonders if alan_g 's way of flashing didn't update everything, which might explain the difference
 * alan_g wonders too. Will try again tomorrow if there's been no progress.
<bschaefer> camako, oo ok, just got down downloading the recovery
<bschaefer> huh... set developer mode it lights up green, go back it goes back to off
 * bschaefer reflashes with --developer-mode
<bschaefer> kind of strange you cant do that anymore...
<bschaefer> from the UI
<alan_g> bschaefer: works for me
<bschaefer> strange, when ever i press the check, it doesnt ask for a password
<bschaefer> and when i leave the menu it goes back to being off
<alan_g> bschaefer: I have a passcode set
<bschaefer> same
<bschaefer> i even went and set a new passcode to check
<alan_g> Odd
<alan_g> tried rebooting
<alan_g> ?
<bschaefer> yeah i just re-flash in dev mode...
<bschaefer> alan_g, o i should have
<bschaefer> i had once rebooted, but it was still doing it maybe i needed reset password and reboot
<bschaefer> well its in dev mode now
<anpok_> 311 was yesteday i believe..
<bschaefer> soo,ill have to check that again
<anpok_> dunno
<alan_g> what's the command to get the image data? we could add it to the test script
<bschaefer> what like adb pull?
 * bschaefer didnt know you could grab that
<alan_g> I mean the phablet version of uname -a
<alan_g> returns the channel, version etc
<bschaefer> o... /me looks for that
<bschaefer> alan_g, adb shell system-image-cli -i
<alan_g> that's the one. At least we can get that info into the test logs.
<bschaefer> yeah that would be nice
 * alan_g goes hacking
<alan_g> bschaefer: done
<bschaefer> alan_g, haha that was quick :)
<alan_g> write access to the repository the script is pulled from is useful
<bschaefer> yeah that would be nice for debugging
<anpok_> dandrader: maybe the mesa-kms driver package is missing?
<dandrader> anpok_, hmm... let me check
<dandrader> anpok_, you mean mir-platform-graphics-mesa-kms6?
<dandrader> anpok, you there?
<anpok> yes switched network
<dandrader> anpok, http://pastebin.ubuntu.com/12992020/
<dandrader> anpok, this is what I get when I try to log in
<dandrader> anpok, just sent you an e-mail with the same content as I though you were gone for good from IRC :)
<dandrader> thought
<anpok> sooo you need to turn the machine off and configure spice + qxl
<anpok> and it should work
<anpok> should be somewhere in display settings in
<anpok> virt-manager
<dandrader> anpok,  never heard of this stuff... ok, let me search for it... do you use VirtualBox as well?
<anpok> oh you are using virtual box
<anpok> >
<dandrader> anpok, is VirtualBox bad? should I use something else like VMWare?
<anpok> the drm driver of virtual box is still a separate kernel module.. I havent come around to update it
<anpok> hm vmware and kvm would both work
<dandrader> anpok, is it worth filing a bug about virtual box?
<anpok> hm sure
<robert_ancell> kgunn, ack on the email about xmir
<kgunn> hey thanks robert_ancell
<kgunn> robert_ancell: i wonder, does it just need a wm ?
<kgunn> but i figure ChrisTownsend would have suggested that....if thats what it was
<robert_ancell> kgunn, duflu did create a built in wm, but I suspect it doesn't set a lot of things.
<robert_ancell> Most modern X apps do behave a bit weird without one. It might also be settings that are set by u-s-d / g-s-d (since u-g runs without a WM but needs u-s-d for things to work).
<robert_ancell> i.e. no-one really tests toolkits / apps without running inside a full shell so the defaults are often wrong.
<ChrisTownsend> kgunn: robert_ancell: Compiz is running, so there is a WM under Xmir.
<ChrisTownsend> And it works fine on a desktop, so I'm thinking it may be specific to arm support.
<robert_ancell> ok
<ChrisTownsend> robert_ancell: The awful artifacting has been there for some time now.  The huge scaling inside the Xmir window is pretty new- it doesn't occur with the version of Xmir in the libertine PPA.
<robert_ancell> ChrisTownsend, where is the libertine PPA?
<robert_ancell> Is that an old version of Xmir, i.e. a regression?
<ChrisTownsend> robert_ancell: https://launchpad.net/~libertine-team/+archive/ubuntu/devel/+packages
<ChrisTownsend> robert_ancell: Yes, I believe it's a regression.
<ChrisTownsend> robert_ancell: You uploaded that Xmir on Oct. 13, so something between then and now.
<kgunn> robert_ancell: fwiw, i also was able to just now connect external monitor and it survived/displayed as expected (granted the FF is still huge)
<kgunn> ChrisTownsend: ^
<kgunn> have you been able to do multimonitor on arm ?
<kgunn> thot you had trouble...so i've at least seen it once :)
<kgunn> w/ xapps specifically
<ChrisTownsend> kgunn: I was kind of able to get it to work one time, but it went to the, uh, screen with the dots first for a bit before actually displaying.  I haven't been able to get it to work since.
<ChrisTownsend> kgunn: But I think any Xapps stuff is a separate issue from external monitor stuff.
<kgunn> me too actually
<kgunn> wasn't sure if you were claiming xmir was directly impacting it, so good to confirm
<ChrisTownsend> kgunn: Nope, I just think external monitor support is fragile period.
#ubuntu-mir 2015-10-29
<RAOF> Why, hello there ThreadSanitizer. I rather expected less extensive complaints.
<alan_g> alf_: you want any more reviews of lp:~afrantzis/mir/server-side-set-base-display-configuration or shall I TA?
<alf_> alan_g: feel free to TA
 * alan_g hopes krillin feels free to "pass"
<alan_g> Sorry for confusing kdub about the future
<alf_> alan_g: no worries
<kdub> isn't being confused about the future part of the human condition? :D
<anpok> oh and that is related to full screen focus changes
<anpok> now I am confused
<alan_g> welcome to the human race ;)
<Saviq> hey all, we noticed u-s-c is hogging CPU when an external screen is connected, is this known? bug #1511357
<ubot5> bug 1511357 in unity-system-compositor (Ubuntu) "CPU hogging when external screen connected" [Undecided,New] https://launchpad.net/bugs/1511357
<kgunn> vogons ^
<alan_g> I didn't know about it
<greyback_> just trying it now on my N4, USC using 40-50% cpu - nothing interacting with it, or causing rendering to happen
<alf_> kgunn: Saviq: Not known
<alf_> Saviq: greyback: Could you check which thread is using the CPU? (press 'V' in top to get a forest view with threads)
<Saviq> fancy
<Saviq> doing
<Saviq> alf_, hmm, only see a process tree, not threads with V
<greyback_> H maybe?
<Saviq> H
<Saviq> yes
<Saviq> alf_, Mir/Comp
<alf_> Saviq: greyback_: Right V + H to also get threads
<greyback_> yep, same here
<alf_> Saviq: greyback_: Could you pastebin an snapshot of the top output
<greyback_> alf_: http://pastebin.ubuntu.com/12998801/
<Saviq> alf_, http://pastebin.ubuntu.com/12998806/
<alf_> greyback_: Saviq: thanks
<alf_> greyback_: Saviq: let me try on desktop to see if it's android specific or not (unless you have already tried it there?)
<Saviq> alf_, didn't try yet, can do in 30s
<alf_> greyback_: Saviq: Which mir/usc are you using? What's in archive at the moment?
<Saviq> alf_, rc-proposed, so vivid overlay
<greyback_> mir 0.17
<alf_> Saviq: please try it if you can for more data points, I will do that also
<Saviq> ack
<Saviq> alf_, looks android-specific indeed, couldn't reproduce here (xenial, fwiw)
<alf_> Saviq: hmm, I can't even start a session with ubuntu-desktop-mir on wily (no overlay)
<Saviq> alf_, not really tested, we targeted overlay for a while now...
<alf_> Saviq: yeah, let me install that
<Saviq> alf_, do you just get a mouse cursor?
<alf_> Saviq: I get nothing
<Saviq> alf_, try overlay, if that no worky, we'll see what's going on
<alf_> Saviq: something is not right, USC log gives me Opening session x-183
<Saviq> alf_, try a guest/different user?
<alf_> Savig: Closing session x-183 ... and so on until it gives up
<alf_> Saviq: ah, wait, you are talking about unity8 session, I am trying ubuntu-desktop-mir?
<Saviq> alf_, what's that? ;)
<alf_> Saviq: yeah, unity8-desktop-session-mir works
<Saviq> alf_, ack :)
<alf_> Saviq: well, kind of... if I login as normal user I get the greeter but when I login from greeter I get to the greeter again
<alf_> Saviq: if I login as guest I just get a blank screen with mouse cursor
<Saviq> alf_, yeah, double greeter expected
<Saviq> alf_, guest isn't tested well, need to look into ot
<Saviq> it
<alf_> Saviq: right, but when I login from second greeter, I don't get into unity8, I just see the (second) greeter again
<Saviq> alf_, oh, too many greeters...
<Saviq> alf_, any chance you typed your pwd wrong?
<alf_> Saviq: no, when I type it wrong, I stay in the greeter. When I type it right, I get a blank screen for a bit, then the second/unity8 greeter reloads
<Saviq> alf_, ah, sounds like a crash
<Saviq> alf_, that's with overlay?
<alf_> Saviq: yes
<Saviq> alf_, would be interested in /var/crash/ and .cache/upstart/unity8.log after you clear them and try again
<alf_> Saviq: http://people.canonical.com/~afrantzis/unity8-crash.tar.xz, but it seems to be an exception thrown from Mir, I am using gdb to track it
<Saviq> alf_, ack
<Saviq> indeed   what():  Failed to wait for event: Interrupted system call
<dandrader> anpok, ping
<anpok> pong
#ubuntu-mir 2015-10-30
<greyback_> alan_g: did you have any fixes for the system-compositor WM to deal with https://bugs.launchpad.net/canonical-pocket-desktop/+bug/1511538
<ubot5> Launchpad bug 1511538 in qtmir (Ubuntu) "1/2 screen on external monitor" [High,Confirmed]
<greyback_> if so, would be nice to include with mir 0.17.1 release
<alan_g> greyback_: not yet. But looks similar to other nested display config problems I'm chasing down
<greyback_> alan_g: ok
<alan_g> greyback_: have you seen anything similar on phone? https://bugs.launchpad.net/mir/+bug/1511723
<ubot5> Launchpad bug 1511723 in Mir "unplugging external monitor causes nested server to throttle client" [Undecided,New]
<greyback_> alan_g: I haven't actually.
<greyback_> alan_g: that's desktop only?
<alan_g> greyback_: that's what I've been testing - as most of the display management problems are platform independent
<anpok> alf: was that convincing enough? https://code.launchpad.net/~andreas-pokorny/mir/input-configuration-api/+merge/273975/comments/697135
<alf_> anpok: is a device configured either as touchpad or pointer?
<alf_> anpok: or => xor
<anpok> alf_: no.. touchpads are both touchpads and pointers
<anpok> mice are just pointers..
<alf_> anpok: I don't know... I still think that apply_touchpad_configuration() is a different operation to apply_pointer_configuration(), not just variations of the same operation.
<alf_> anpok: Anyway, I won't block on that.
<alan_g> alf_: I agree - they have different effects
<anpok> hmm
<anpok> isnt just a matter of abstraction when describing the effect
<anpok> +that
<anpok> there is no problem in changing the interface.. I just want to understand that point.. or rather..
<anpok> when do you think overloading is ok-ish.. and when is it considered harmful .. not appropriate..
<alan_g> draw_a_gun()  and draw_a_card() vs draw()
<anpok> ^ a good case of draw(gnu) draw(card)?
<alf_> anpok: a bad case
<anpok> oh really?
<anpok> draw : gnu -> void      draw : card -> void ..
<anpok> they wont have the same effect but both draw <something> .. somewhere..
<anpok> .. compare to operator<<(stream, T)
<alf_> anpok: well, it really depends on the context, but drawing a gun is drawing a card is not related in general. For example in a class Cowboy I would expect two different methods.
<anpok> oh .. gun ... i read gnu
<anpok> what do you mean be different methods? I would expect neither inside a 'Cowboy'
<anpok> s/be/by
<alf_> anpok: Well, now we are starting to discuss class design completely theoretically... :)
<anpok> meta design
<anpok> we need space glasses for that..
<anpok> http://blog.spaceglasses.com/
<anpok> guess we just have to expense that..
<alan_g> draw_a_picture_of_a(gnu) is different again
<anpok> ok need to go offline again..
<alf_> anpok: I guess for me the ultimate counter example we have is mev::make_event(). At one abstraction level you could say that all these create "events", and that's correct, but I argue that we should have "make_touch_event", "make_pointer_event" etc instead
 * alan_g wonders about angels and points of pins
<alf_> anpok: going with the first approach (all these create events) has led to a very hard to read API
<anpok> alf_: there I agree it should not be the same name,
<anpok> bbl
 * alan_g is tired of segfaults deep inside /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#ubuntu-mir 2016-10-31
<duflu> RAOF: I'm half tempted to land two of my mirvanity proposals without any reviews. No one else has an interest/stake in it really. Would you mind sanity checking occluded-vanity and interval-0-is-not-an-error?
<RAOF> duflu: sure
<RAOF> duflu: Seems like a more correct fix for interval-0-is-not-an-error would be to disallow interval 0?
<RAOF> duflu: Since there's never any reason to use it, and your new code assumes that the display runs at a fixed rate?
<duflu> RAOF: There are two reasons you might want it; (a) To report Mir's absolute best case lowest latency; and (b) to measure improvements to framedropping (e.g. predictive bypass presently only helps with interval 0)
<duflu> It's not default, sure.
<duflu> RAOF: Also fixed frame rate displays are a good assumption, but also variable ones don't break mirvanity. My FreeSync display gets much better numbers than my fixed one
<duflu> RAOF: The display Hz is only used to calculated the estimated range, which gives an estimate of when the test is finished (has covered the full superposition range)
<duflu> It's not used to produce any measurements
<RAOF> The latency variable is never used to calculate latency?
<duflu> RAOF: The monitor's refresh rate does not contribute to the measurements reported. Just contributes to "estimated range" which tells the user what to expect from the measured range
<duflu> I mean the display_hz does not contribute. The physical performance of the monitor does contribute of course
<duflu> RAOF: Oh, sorry, I see the bit you mean. Yes latency -= state->last_change_time_error is a necessary evil, to avoid having to make every frame completely unique and having to write a vision algorithm that could distinguish tens of thousands of different images
<duflu> Our "refresh rate" is always the maximum refresh rate of a monitor, so that tweak is minimal for a variable framerate display
<RAOF> As long as we always report the maximum refresh that doesn't seem to be broken, yes.
<duflu> RAOF: Indeed from the kernel up I believe we're always, only, told the maximum rate.
<RAOF> For now :)
<duflu> I don't mind. If we get more data later we can adjust
<duflu> I read that Nvidia were drilling Google on the same kind of issue -- why optimize for fixed frame rate displays? The answer is because that's what most people have, and because variable frame rate displays don't really suffer if you're careful.
<RAOF> If you use them as fixed framerate displays variable rate displays are simply a frame-times->16ms-optimisation.
<duflu> RAOF: I intentionally drive mirvanity at the max frame rate the hardware will accept. So the max refresh rate is indeed the refresh rate it runs at
<RAOF> Unless there's contention, but that's not very helpful for benchmarking anyway.
<RAOF> ...at least for the moment.
<duflu> I'm content that the benchmark is occasionally finding bugs we would never have found otherwise. So despite the theoretical limitations, it is immensely useful
<duflu> RAOF: In case you were curious my reasoning for wanting EDIDs was just to get at some sane identifying string for each monitor.
<duflu> I don't think DRM provides that abstraction...?
<RAOF> duflu: Yeah, we should totally expose something like that.
<RAOF> Correct; you want to parse the edid.
<duflu> Which is unfortunate if DRM is doing parsing already
<RAOF> Yeah.
<RAOF> Hm.
<RAOF> I don't *think* there's a DRM API for extracting the vendor strings, but it might make sense.
<RAOF> On the other hand, importing an edid parser into Mir might also make sense.
<duflu> RAOF: What else are we missing from the EDID?
<duflu> What is is *DRM* missing from the EDID?
<RAOF> Nothing it cares about, AFAIK :)
<RAOF> The monitor manufacturer and year/week of production are two things that aren't exposed by DRM.
<duflu> I'm just thinking about things a user might want to see in a config GUI. The vendor/product strings are helpful
<RAOF> Serial number, manufacturer product number.
<RAOF> Yeah, these are useful things to expose.
<duflu> And firmware uploads! Let's port Mir to the panel itself
<RAOF> I'm about +0 for parsing the EDID in Mir, -0 for just throwing the EDID to a client. âº
<duflu> RAOF: Sounds sufficient. And probably is the status quo (only the GUI app has to link to an EDID decoding library)
<RAOF> I actually don't know; X parses the EDID itself, but I'm uncertain whether those properties are exported over XRANDR.
<RAOF> Or, rather, I've forgotten whether those properties are exported :)
<RAOF> Aaah, merge conflicts!
<RAOF> A perfect time to EOD!
<duflu> Ok, later.
<alan_g> sil2100: is it you I need to ask to get miral into X+O? https://bileto.ubuntu.com/#/ticket/21105
<sil2100> alan_g: hey! Let me take a look
<sil2100> alan_g: ah, ok, so the destination probably confused people
<sil2100> alan_g: so this silo is only for xenial-overlay?
<alan_g> sil2100: I got confused by belito UI and couldn't figure out how to target XO only. (I do know now.) But it's harmless landing in zesty too. Just wanted to know "the right way" before fiddling further as its new to xenial
<sil2100> alan_g: ok, publishing
<alan_g> sil2100: thanks
<alan_g> sil2100: does "xenial/miral: Failed to update local..." mean that didn't work?
<sil2100> Interesting error
<sil2100> Ah, I know what happened
<sil2100> Ok, publishing manually
<sil2100> Bileto got confused if I wanted to publish it as a xenial-overlay-only landing, as the cached primary branches were meant for zesty
<alan_g> sil2100: I guess I got bileto back for confusing me. ;)
<alan_g> dandrader: I don't know how to go about checking this (as no-one knew it was missing). Can you take a look? https://code.launchpad.net/~alan-griffiths/miral/rewire-SurfaceObserver-notifySurfaceModifications/+merge/309668
<dandrader> alan_g, sure
<dandrader> alan_g, btw, are you able to build miral-qt without issues?
<dandrader> alan_g, gerry and I were getting some "missing tracepoints.h" errors
<alan_g> dandrader: yes, I think that got fixed Friday
<dandrader> didn't stop to investigate it. so far I I've been just commenting out all trace calls and #includes...
<dandrader> alan_g, ah, great
<alan_g> FWIW it actually worked on a second attempt - which is how it got missed
<kdub> did any of the euro-vogons hear if raof had started poking at the platform extension mechanisms for the client api?
<alf> kdub: I didn't hear anything
<anpok_> hm not yet .. his last complaint were branch conflicts..
<anpok_> I assume he still was working on something else..
<anpok_> as in .. not on something new..
<anpok_> +about..
<anpok_> before he left this morning
<kdub> thanks alf and anpok_  (reaching the point in the hybris work where it would come in handy to stack on the intended final api instead of deprecations)
<alan_g> dandrader: I assume won't be stepping on anyone's if I rework MirSurface so that the property values get updated correctly?
<dandrader> alan_g, right, you shouldn't be conflicting with anyone else's work
<dandrader> alan_g, FYI: we plan to have a ppa with miral-qt as a big fat patch for qtmir this week. so your latest changes will come in handy.
<dandrader> alan_g, I think gerry has been preparing it in https://code.launchpad.net/~unity-team/qtmir/miral-qt-integration
<dandrader> I suppose you already know about all that. anyway, just in case :)
<alan_g> dandrader: I knew he planned it
#ubuntu-mir 2016-11-01
<RAOF> GAH! CachedPtr strikes again!
<RAOF> ...and EOD>
<alan_g> greyback: I've been poking around miral-qt again. Fixed (subject to review) some stuff that needed fixing.
<greyback> alan_g: ack. I've just opened the queue
<greyback> alan_g: looking at https://code.launchpad.net/~alan-griffiths/miral/remove-some-modules-Unity-Application-dependence-on-libmirserver-dev/+merge/309593 - you move the mirserver dependency into a small helper utility - is that all you will do with that, or have you further plans?
<alan_g> greyback: it's a process, I first want to isolate the precise features that are being used, and then review how (or if) they should look in libmiral. I suspect some are not yet stable enough and am wondering about an "experimental" library to move them to for now.
<greyback> alan_g: ok. Wanted to be clear on the direction
<alan_g> Sure. In this case it makes it clear how little of the mir/scene/session.h interface is used.
<alan_g> greyback_: just wondering... why does Mir "Need api for client to inhibit screen dim/off" when AFAICS it is no more involved than in "cut&paste" or "drag&drop"?
<greyback_> alan_g: you could look at it that way, yes. But I believe copy&paste/dnd were designed with as little mir involvement due to the content-exchange aspect.
<greyback_> whereas this strikes me as very close to mir's existing functionality - display configuration
<alan_g> But repowerd manages screen dim/off. The only thing needed is "what's the current app?"
<alan_g> Which is almost the same as C&P
<greyback_> I'd say current focusedwindow more than current app, but you point remains
<alan_g> thanks
#ubuntu-mir 2016-11-03
<dandrader> greyback, alan_g, may I merge https://code.launchpad.net/~dandrader/miral/moveStuffToUnityApi/+merge/309785 and https://code.launchpad.net/~dandrader/unity-api/miral/+merge/309787 ?
<dandrader> greyback, alan_g addressed the only comment you guys made
<alan_g> dandrader: fine by me - I don't understand it well enough to object.
<greyback> dandrader: go for it
<greyback> I've just TAd
<alan_g> greyback: https://code.launchpad.net/~alan-griffiths/miral/check-libmiral-symbols/+merge/309931/comments/803339
<greyback> alan_g: with that MP, what am I supposed to see? I added a method to miral::Window and rebuilt, but saw no warning or complaint that the ABI changed
<alan_g> greyback: did you update the symbols.map script?
<greyback> alan_g: no
<alan_g> You new symbol won't be exported without that
<alan_g> "make symbols"
<alan_g> You'd see that missing when you tried to use it
<tsdgeos> guys, any idea why it mir would want to load graphics-mesa-kms.so.8 instead of graphics-mesa-kms.so.10 that is the one that exists?
<tsdgeos> http://paste.ubuntu.com/23421281/
<alan_g> Because it's there?
<greyback> alan_g: it's not there according to his paste
<tsdgeos> no, it's not there
<alan_g> Because someone set an environment variable specifying it
<tsdgeos> alan_g: which env var would it be?
 * alan_g dives into the code
<tsdgeos> i'm going to say that something is scaping from the snap though
<tsdgeos> since i do actually have /usr/lib/x86_64-linux-gnu/mir/server-platform/graphics-mesa-kms.so.8
<greyback> it could be the plugin autodetection stuff...
<alan_g> MIR_SERVER_PLATFORM_GRAPHICS_LIB
<tsdgeos> tx
 * alan_g muses about writing a simple launcher for miral-kiosk that starts games and creating an "Mbox" snap
<bschaefer> alan_g, you could look at scummvm or umm other ones like mupen64plus
<bschaefer> which emulate roms ... which would be pretty cool to have setup with a miral kisok (joysticks works with sdl2 + mir as well)
<alan_g> bschaefer: that's actually cleverer than I was thinking. I was just going to grab gnome-chess gnome-mahjongg et alia and put them in the snap
<bschaefer> alan_g, that would be good to have as well + a launcher
<bschaefer> though those emulators have launchers built in for the most part
<bschaefer> (which gives you a nice single client snap + lots of older games) An arcade machine kind of
 * bschaefer needs to look at retropie
<alan_g> With a simple "launch, hide and wait for exit" launcher
<bschaefer> yeah that would be awesome to have as well
<bschaefer> alan_g, that goes a little above a kiosk into like a minimalistic shell?
<alan_g> being able to add games requires additional knowledge of the snapd content interface
<anpok> hm
<alan_g> bschaefer: why? I was thinking one active app at a time
<anpok> I think kodi should actually be a mir server
<anpok> a kiosk .. that runs games or videos inside and allows you to switch between them..
<anpok> i.e. there is libretro / retroarch which provies a ps3 like interface
<bschaefer> true, but ... yeah then its still a kisok
 * bschaefer was thinking if you could switch apps but you mean starting a new app *closes* your app
<alan_g> I was just going to hide the window until the new app exits
<bschaefer> that works :) and would be nice ... since those games are fun to have around on a simple kiosk
#ubuntu-mir 2016-11-04
<om26er> RAOF: hello
<duflu> om26er: He seems to be away today
<om26er> duflu: oh, ok. I was told to contact RAOF regarding libmirclient-debug as I needed the mouse pointer co-ordinates from it. Do you know if there are any docs on that somewhere ?
<duflu> om26er: The debug extension provides only two headers and we keep the docs in the headers.... dpkg -L libmirclient-debug-extension-dev
<duflu> So that would be the place if any
<duflu> Oh, one header. Duplicated :)
<duflu> Seems the feature isn't there
<om26er> yeah seems the co-ordinates of a surface are available only
<om26er> even more, does this extension require mir to be running in debug mode ?
<duflu> om26er: Not sure. I'm not aware of such a feature but that doesn't mean it doesn't exist
<om26er> duflu: I did send an email to Chris last night so, will probably get a reply next week
<duflu> om26er: Yeah sorry. He just seems to be absent today
<duflu> anpok_: Progress. I now have in-server clients (render_surfaces) working in VirtualBox. 100FPS at 1320x910 in a VM :)
<dandrader> alan_g, greyback, regarding immediate miral-qt work: I think we should now propose branches for lp:~unity-team/qtmir/miral-qt-integration instead of lp:miral. Then, once lp:~unity-team/qtmir/miral-qt-integration lands, propose directly for lp:qtmir
<dandrader> alan_g, greyback, sounds like a plan?
<greyback> dandrader: can we get a silo together with a working miral-ised unity8, just to assess where we are right now
<dandrader> greyback, need miral 0.4, as I told on the e-mail
<greyback> dandrader: which doesn't stop us making a test silo, including miral
<alan_g> dandrader: greyback there are pros and cons to each approach, it depends where we think most of the remaining work lies.
<alan_g> I have a somewhat biassed view because I'm just looking at the interaction with Mir and MirAL.
 * greyback changing office, bbiab
 * alan_g thinks miral will need work for packaging to work on vivid (because of the g++ ABI)
<alan_g> greyback: in my review of miral-qt I'm looking at orientation. So far, MirAL doesn't expose orientation of displays or surfaces and I'm not sure that matters to /window management/. That is, I think it's a /compositing/ concern. And for compositing I think we need a different abstraction than miral::Window (with a way to map between of course). Other stuff that belongs to that abstraction are buffers_ready_for_composit
<alan_g> or(), occlusion, generate_renderables(). Does that make sense to you?
<greyback> alan_g: are you including preferred_orientation in that assessment>
<greyback> display rotation causes a geometry change, the window manager may want to do work to reposition/resie surfaces to suit
<greyback> but the WM might also want to notify the app of the orientation it wants it to display at
 * greyback ponder
<greyback> s
<alan_g> I'm not entirely sure about orientation (or preferences) it isn't yet clear to me
<greyback> ok, quick summary: windows can have a list of preferred orientations (orientations the UI supports)
<alan_g> yep
<greyback> then the shell should limit the system orientation to match those preferences
<greyback> within reason
<alan_g> that's the wibble word
<greyback> so if surfaceA specifies it prefers portrait orientation, and it is focused, shell should be in portrait
<greyback> right, because it's not straightforward - if you are on desktop, shell isn't going to change from natural landscape to portrait, just because the surface prefers it
<alan_g> Ack. that convinces me that there's a WM component.
<greyback> for a traditional desktop, everything will be landscape. But on a tablet or phone, preferred orientations may cause the shell to decide to change orientation
<greyback> yeah, I believe the WM needs to care
 * alan_g has seen portrait desktop setups
<greyback> oh sure, they exist. But you can't easily switch orientation just because the app prefers it. Alt-Tabbing between portrant & landscape surfaces shouldn't force you to rotate your monitor on its stand
<alan_g> greyback: thanks, I need to think some more
<greyback> but changing display orientation on a phone/tablet is trivial
<alan_g> Unless "locked" by the user
<greyback> indeed
<alan_g> So MirAL's next big feature should be an orientation model that supports choices
 * alan_g thinks hard
<greyback> take note that unity8 orientation support is all done in unity8 - Mir is not doing any rotation of the shell
<alan_g> ack
<greyback> which isn't ideal, we're not updating the display config with the "correct" orientation - it something I need to look at again. It was mainly blocked due to bug 1556142
<ubot5`> bug 1556142 in Mir "Changing scale, formFactor or DPI in display configuration causes renderer teardown/recreate unnecessarily" [High,In progress] https://launchpad.net/bugs/1556142
<alan_g> greyback: I know RAOF has been chipping away at that, could be worth re-examining post Mir-0.25
<greyback> alan_g: ack
<dandrader> alan_g, miral no longer builds in V+O http://pastebin.ubuntu.com/23425346/
<alan_g> dandrader: "interesting"
<dandrader> greyback, while I wait for miral 0.4 I gonna start experimenting with exposing child miral windows to unity8 (popups, menus). with a separate branch on top of lp:~unity-team/qtmir/miral-qt-integration
<greyback> dandrader: perfect!
<greyback> dandrader: I believe we both agree that any new work on qtmir is done on top of that branch
<alan_g> dandrader: greyback quick review? https://code.launchpad.net/~alan-griffiths/miral/update-changelog/+merge/310077
<greyback> looks good, acked
#ubuntu-mir 2017-10-30
<Saviq> xnox: hey, any idea where does -DCMAKE_C_COMPILER value come from in dh_auto_configure when cross-compiling? seems on 16.04 arm64 it points to aarch64-â¦-cc instead of -gcc, resulting in broken configure
<xnox> Saviq, both should be valid, are you telling me that ....-cc doesn't exist? or that it does exist, but behaves not like gcc, and/or ...gcc is expected?
<xnox> Saviq, there is debhelper itself, but also there is cross-build patch in cmake source. either one, or both might be doing this.
<Saviq> xnox: doesn't exist
<xnox> Saviq, also i'm assuming you are using normal cross-compilaton, not the archaic dpkg-cross stuff
<Saviq> # aarch64-linux-gnu-cc
<Saviq> No command 'aarch64-linux-gnu-cc' found, did you mean:
<Saviq>  Command 'aarch64-linux-gnu-gcc' from package 'gcc-aarch64-linux-gnu' (main)
<Saviq> aarch64-linux-gnu-cc: command not found
<xnox> Saviq, and you do have cross build-depends insteadd for the arm64 right?
<Saviq> xnox: normal as in `debuild -aarm64`?
<Saviq> # aarch64-linux-gnu-gcc
<Saviq> aarch64-linux-gnu-gcc: fatal error: no input files
<Saviq> compilation terminated.
<xnox> yes that is normal
<xnox> crossbuild-essential-arm64 is installed right?
<Saviq> yup
<Saviq> yeah using mk-build-deps --host-arch arm64
<Saviq> the same works on 17.10
<xnox> fun
<xnox> might be a cross-toolchain bug, rather than anything in debhelper/cmake.
<xnox> let me check things and/or possibly ping doko
<Saviq> xnox: FWIW the same applies to -c++ vs. -g++
<xnox> yeah, checked that too
<xnox> Saviq, please use ubuntu-bug and open a bug against debhelper, saying that when crosscompilig, using dh, using dh's buildsystem cmake, it sets incorrect default compiler variables. and request that this commit is SRUed into xenial - https://anonscm.debian.org/git/debhelper/debhelper.git/patch/lib/Debian/Debhelper/Buildsystem/cmake.pm?id=61d575451f028e2bba666d40ee1dedc8c6308f40
<xnox> please let me know the bug number, i can prep the sru, but could you please open the bug report such that you get all the notifications about it
<Saviq> xnox: ack
<Saviq> how did we not see this before... <shake_head />
<Saviq> prolly overlay hid it away
<Saviq> xnox: bug #1728673
<ubot5> bug 1728673 in debhelper (Ubuntu) "cmake's default compiler names incorrect when crosscompiling" [Undecided,New] https://launchpad.net/bugs/1728673
<xnox> Saviq, there is a cheat =) install and use debhelper from xenial-backports, as that one is fixed =)
<Saviq> xnox: aha, might do that
<xnox> Saviq, can you return me a favor?
<xnox> what is the best current practice for cmake gmock/gtest?
<xnox> -- Found Threads: TRUE
<xnox> CMake Error at /usr/src/googletest/googletest/cmake/internal_utils.cmake:149 (add_library):
<xnox>   add_library cannot create target "gmock" because another target with the
<xnox>   same name already exists.  The existing target is a static library created
<xnox>   in source directory "/usr/src/googletest/googlemock".  See documentation
<xnox>   for policy CMP0002 for more details.
<xnox> Call Stack (most recent call first):
<xnox>   /usr/src/googletest/googletest/cmake/internal_utils.cmake:172 (cxx_library_with_type)
<xnox>   /usr/src/gmock/CMakeLists.txt:84 (cxx_library)
<xnox> ..
<xnox> i hate when above happens =/
<Saviq> aha :)
<Saviq> xnox: have a look at https://github.com/MirServer/mir/compare/1e543d3b885fca34f494a9be4d6f60ec541c4203...277b0a0b13087e190a641f06cd5a745e6d14c181
<Saviq> actually that might not be all, but Alan did just redo the gtest/gmock detection in mir https://github.com/MirServer/mir/commits/master
<Saviq> so https://github.com/MirServer/mir/blob/master/cmake/FindGtestGmock.cmake should help
<Saviq> as it works on Ubuntu and Fedora, too
<xnox> hm, why is /usr/src/googletest/googletest/ second given that is the preferred path on both ubuntu and debian in new world order?
#ubuntu-mir 2017-10-31
<Saviq> legacy, I suppose
<Son_Goku> xnox: because no one else does that
<Son_Goku> the rest of us ship the libraries
<Son_Goku> xnox: who says that Debian/Ubuntu are the center of the Linux universe
 * Son_Goku finds this offensive given how much crap it's taken to make Mir work on Fedora
<Son_Goku> things still don't quite work... :/
<RAOF> There is no best practice for GMock ð 
<xnox> Son_Goku, as far as I can see googletest is the new source name, after gmock and gtest have merged; unless it's only debian that followed upstream rename.
<xnox> Son_Goku, independent gtest & gmock no more.
<xnox> Son_Goku, are you saying others stuck shipping the split out libraries only, and did not move onto the googletest?
<Son_Goku> CMake itself distinguishes between the two
<Son_Goku> the source package for us is gtest, but it produces gmock and gtest libraries
<Son_Goku> not everyone uses both
<xnox> Son_Goku, but I see projects trying to import both and that doesn't work, as gmock builds gtest too. Importing both results in a duplicate library/target in cmake.
<Son_Goku> if they import both as SOURCE, yes
<xnox> (gmock building gtest, is new to googletest based sources)
<Son_Goku> yes, I know
<Son_Goku> but if the library is already built and you're linking to it, it won't
<xnox> but that stopped being supported....
<xnox> in debian/ubuntu we ship the gmock/gtest sources, but not pre-building the libs =/ as per upstream recommends.....
<Son_Goku> they changed their recommendation
<Son_Goku> which is why CMake supports locating the library
<xnox> ok, then i am out of date again =/
<Son_Goku> yeah, it sucks
<Son_Goku> Google is fluid like that
<Son_Goku> in Fedora, we currently have gtest as a lib, and gmock as source
<Son_Goku> which was Google's previous recommendation
<Son_Goku> but now it's okay to have the whole thing as libs
<Son_Goku> it's nuts
<RAOF> Ah! I was wondering why I couldn't find gmock as a library in Fedora!
#ubuntu-mir 2017-11-02
<Son_Goku> RAOF, hey, it seems like your Git repository is incomplete
<Son_Goku> it's missing all the newer tags from Launchpad
<RAOF> As in 0.28? Yeah, probably.
<Son_Goku> yeah
<Son_Goku> RAOF, also, now that it's on GitHub officially-ish, I could submit my spec to be merged into the repository
<Son_Goku> you might want to talk to mvo about how he manages to update the spec and debian stuff for the snapd repo and implement the same thing for mir
<Son_Goku> and wire up CI building for Mir on Fedora
<RAOF> Pull requests welcome!
<RAOF> (CLA permitting, I think?)
<RAOF> Yeah, building on Fedora in CI should be a simple as adding a Fedora lxd image.
 * RAOF loves that Riot has a âyou seem to be shaking the phone in frustration, would you like to file a bug report?â dialogue.
<RAOF> Now (?) that we've disabled merge proposals on LP we'll need to do a final sync from there.
<Son_Goku> I signed the CLA last year for snapd stuff
<Son_Goku> I believe that still applies for Mir
 * Son_Goku grumbles slightly about the continued existence of the CLA...
<Son_Goku> hmm, looks like there's something wrong with building the package with unit tests enabled
<Son_Goku> extracting debug info from /builddir/build/BUILDROOT/mir-0.28.1-1.fc26.x86_64/usr/bin/mir_unit_tests_mesa-kms
<Son_Goku>  /usr/lib/rpm/debugedit: canonicalization unexpectedly shrank by one character
<Son_Goku> RAOF ^
<Son_Goku> something weird is going on with how mir_unit_tests_* binaries are being compiled
<RAOF> ??!
<Son_Goku> this usually happens when something has something like a double slash is encoded in some path
<Son_Goku> because canonicalization of file paths would reduce it by a character
<Son_Goku> so like somewhere in CMake, these things are getting compiled with paths that have double slashes in it
<RAOF> mir_unit_tests_mesa-kms shouldn't *have* any debug info; it's a symlink!
<RAOF> But that's entirely possible
<Son_Goku> no it isn't
<Son_Goku> it's legit binary
<Son_Goku> -rwxr-xr-x. 1 root root 118M Nov  1 23:52 mir_unit_tests_mesa-kms
<Son_Goku> it's also HUGE
<duflu> Son_Goku, https://bugs.launchpad.net/mir/+bug/1473330  :)
<ubot5> Ubuntu bug 1473330 in Mir "mir_*_tests binaries are suspiciously large. Up to 248MB before stripping." [Medium,Triaged]
<Son_Goku> RAOF: https://paste.fedoraproject.org/paste/jY4AHO9htZkJdk2nEapVlw
<Son_Goku> this is what the built tree looks like
<Son_Goku> debug symbols not finished splitting, though
<RAOF> Hm. Have we changed the way we wrap this executables?
<Son_Goku> well, this is the first time I was able to build the unit tests
<Son_Goku> they've been broken before
<RAOF> Hm, no.
 * Son_Goku is sending a build of mir 0.28.1 without unit tests to build in copr
<Son_Goku> once we can get the unit tests, then we'll be in a state where putting this in Fedora proper could be a thing
<RAOF> In my build tree, mir_* is a symlink to mir_*.bin.
<RAOF> Oh, sorry, wrong.
<RAOF> mir_* is a symlink to wrapper
<Son_Goku> that seems like debian foo
<Son_Goku> because it's not here
<RAOF> (Which sets some environment variables and then calls argv[0].bin)
<RAOF> That's not debian foo; I'm running a raw cmake build.
<RAOF> I don't build packages during development ;)
<RAOF> All those are being bulit from CMakeLists.txt with mir_add_wrapped_executable(), which is defined in cmake/MirCommon.cmake
<RAOF> Oooooh1
<RAOF> !
<Son_Goku> https://paste.fedoraproject.org/paste/yg7YM9HFJSPR9a93cGIpmQ
<RAOF> No, that's right.
<RAOF> You've run make install.
<Son_Goku> this is my cmake command
<RAOF> As is right and proper.
<RAOF> And we don't use the wrapper on installed binaries, because we can assume the libraries are also installed.
<RAOF> Be about your business ;)
<Son_Goku> okay then
<Son_Goku> :)
<Son_Goku> you had me panicking for a bit there
<Son_Goku> https://copr.fedorainfracloud.org/coprs/ngompa/Mir/build/656918/
<Son_Goku> no unit tests yet
<Son_Goku> since, well, debugedit says there's something wrong with them
<RAOF> Hrm.
<RAOF> âstrings bin/mir_unit_tests_mesa-kms.bin| rg //â does not show up any // paths for me.
<Son_Goku> hmm
<Son_Goku> the person who would know more about this is mjw (Mark Wielaard) in #rpm.org
<Son_Goku> he is the one who hacks on debugedit and knows more than anyone else I know about debug symbol stuff
<Son_Goku> but he's not online yet
<RAOF> There are a bunch of PATH/../../foo.h in there.
<Son_Goku> that could do it too
<Son_Goku> but I'll probably be passing out soon, since it is past midnight here
<RAOF> But I'd expect that to result in canonicalisation dropping more than one character :)
<RAOF> Heh.
<RAOF> Good news, everyone!
<Son_Goku> it's easy enough for someone to reproduce though
<RAOF> I've been accidentally testing that GNOME Shell passes my wayland conformance suite.
<RAOF> And it does!
<Son_Goku> RAOF: ?
<Son_Goku> :)
<RAOF> (Not that there's much of a conformance suite yet, mostly the infrastructure for one)
<Son_Goku> anyway, anyone can reproduce the problem I have by downloading https://copr-be.cloud.fedoraproject.org/results/ngompa/Mir/fedora-26-x86_64/00656918-mir/mir-0.28.1-0.fc26.2.src.rpm and using `rpmbuild -ra --with check mir-0.28.1-0.fc26.2.src.rpm`
<Son_Goku> I suppose on a debian system with rpm installed, if you have the debian builddeps installed, you could do it with `rpmbuild -ra --nodeps --with check mir-0.28.1-0.fc26.2.src.rpm`
 * RAOF fires up positive-seasnail
<RAOF> Son_Goku: What's the way to install all the build-deps of an rpm?
<Son_Goku> $ rpm -ivh https://copr-be.cloud.fedoraproject.org/results/ngompa/Mir/fedora-26-x86_64/00656918-mir/mir-0.28.1-0.fc26.2.src.rpm
<Son_Goku> $ sudo dnf builddep -D "_with_check 1" --spec ~/rpmbuild/SPECS/mir.spec
<Son_Goku> (ordinarily, we'd use the SRPM directly, but we want more builddeps than the default)
<Son_Goku> and once you have the builddeps installed
<Son_Goku> you can just do the following:
<Son_Goku> $ rpmbuild -ba --with check ~/rpmbuild/SPECS/mir.spec
<RAOF> Ta
<RAOF> Ah.
<RAOF> I think it's more likely to be a trailing /
<RAOF> Son_Goku: Fixed in Fedora 27, apparently :)
<RAOF> https://bugzilla.redhat.com/show_bug.cgi?id=304121
<ubot5> bugzilla.redhat.com bug 304121 in rpm "debugedit prints: canonicalization unexpectedly shrank by one character" [Medium,Closed: rawhide]
<RAOF> Yes! And now that it's hooked up, Mir also passes this particular test!
<RAOF> So I guess I get this applied to a git tree, break up some megafiles, and propose.
<Son_Goku> [09:03:58 AM]  <mjw>	pmatilai, O, right, yes, it might also be the some source file is encoded as some/dir//source.c with a double slash which some code might or might not remove and then the lengths don't add up.
<Son_Goku> RAOF ^
<Pharaoh_Atem> RAOF: so I ran ctest and got the following error:
<Pharaoh_Atem> 17: [ FAILED ] 1 test, listed below:
<Pharaoh_Atem> 17: [ FAILED ] MesaGraphicsPlatform.connection_ipc_package
<Pharaoh_Atem> 17: [ RUN ] MesaGraphicsPlatform.connection_ipc_package
<Pharaoh_Atem> 17: [2017-11-02 14:54:39.357042] mesa-kms: Using DRM device /dev/dri/card1
<Pharaoh_Atem> 17: [2017-11-02 14:54:39.357132] mesa-kms: Using DRM device /dev/dri/card0
<Pharaoh_Atem> 17: unknown file: Failure
<Pharaoh_Atem> 17:
<Pharaoh_Atem> 17: Unexpected mock function call - returning default value.
<Pharaoh_Atem> 17: Function call: drmAuthMagic(8, 32659)
<Pharaoh_Atem> 17: Returns: 0
<Pharaoh_Atem> 17: Google Mock tried the following 1 expectation, but it didn't match:
<Pharaoh_Atem> 17:
<Pharaoh_Atem> 17: /builddir/build/BUILD/mir-0.28.1/tests/unit-tests/platforms/mesa/kms/test_platform.cpp:108: EXPECT_CALL(mock_drm, drmAuthMagic(mtd::IsFdOfDevice("/dev/dri/card0"),_))...
<Pharaoh_Atem> 17: Expected arg #0: Is an fd of DRM device /dev/dri/card0 (one of: { 10 })
<Pharaoh_Atem> 17: Actual: 8
<Pharaoh_Atem> 17: Expected: to be called once
<Pharaoh_Atem> 17: Actual: never called - unsatisfied and active
<Pharaoh_Atem> 17: /builddir/build/BUILD/mir-0.28.1/tests/unit-tests/platforms/mesa/kms/test_platform.cpp:108: Failure
<Pharaoh_Atem> 17: Actual function call count doesn't match EXPECT_CALL(mock_drm, drmAuthMagic(mtd::IsFdOfDevice("/dev/dri/card0"),_))...
<Pharaoh_Atem> 17: Expected: to be called once
<Pharaoh_Atem> 17: Actual: never called - unsatisfied and active
<Pharaoh_Atem> 17: [ FAILED ] MesaGraphicsPlatform.connection_ipc_package (7 ms)
<RAOF> Pharaoh_Atem: Harrumph. Please file a bug, that's the test having an implicit dependency on the order udev enumerates devices in, I think.
<Pharaoh_Atem> okay
<Pharaoh_Atem> where do I file bugs now?
<Pharaoh_Atem> is it still LP?
<Pharaoh_Atem> ah, it moved to GitHub too
<Pharaoh_Atem> that makes things easier
<Pharaoh_Atem> RAOF: https://github.com/MirServer/mir/issues/8
<RAOF> Ta
#ubuntu-mir 2017-11-03
<Pharaoh_Atem> RAOF: my first pull! https://github.com/MirServer/mir/pull/11
