#ubuntu-mir 2013-08-12
<robert_ancell> RAOF, are there things worth asking that we can't get apport to do?
<RAOF> Yes; run a Mir server and client, and check if *that* works.
<RAOF> Other than that, we should be able to collect all the relevant logs.
<robert_ancell> ta, I'll ask them for that
<RAOF> robert_ancell: Hey, if someone starts a Mir client and attaches it to unity-system-compositor's socket, what happens?
<robert_ancell> RAOF, they can connect, but they'll never get focussed. (Actually can't remember if Mir's default behaviour will give them focus)
<robert_ancell> Either way, it does need to be fixed (Haven't filed a bug yet)
 * robert_ancell -> lunch
<duflu> RAOF: It appears someone has started on making VBE KMS-friendly. But it never hit any kernel tree yet. Do you know anything?... http://lists.freedesktop.org/archives/dri-devel/2013-January/034058.html
<robert_ancell> duflu, is bug 1192429 fixed now we have those VT changes in?
<ubot5> bug 1192429 in Unity System Compositor "unity-system-compositor is on multiple simultaneous (and random) VTs" [High,Triaged] https://launchpad.net/bugs/1192429
<duflu> robert_ancell: I will have to update and enable it to retest...
<robert_ancell> duflu, are you still on the PPA?
<duflu> robert_ancell: Saucy, yes. I had planned on moving to no-PPAs soon anyway
<duflu> robert_ancell: Is the fix in distro yet?
<robert_ancell> duflu, yes
<robert_ancell> not a specific fix for that problem, but VTs seem to be working well now (aside from the input always going to XMir)
<duflu> robert_ancell: Is there a bug for that one?
<robert_ancell> duflu, yes, I'll just find it
<duflu> robert_ancell: OK, please tag it: vt
<robert_ancell> duflu, bug 1192843
<ubot5> bug 1192843 in XMir "XMir does not relinquish input on session switch" [Critical,In progress] https://launchpad.net/bugs/1192843
<robert_ancell> tagged
<duflu> That's cool. ppa-purge results in me getting mir package upgrades
<robert_ancell> duflu, oh, why did you bump the soname for libmirserver?
<duflu> robert_ancell: Because the switch branch seems to have changed enough ABI things that it became necessary
<duflu> Loading the old version by mistake was causing serious bugs
<robert_ancell> duflu, we always rebuild dependencies so it should be impossible to have an old version
<duflu> robert_ancell: Not so on my Nexus4, which has not been updated :)
<robert_ancell> duflu, but after that change it did break exactly like that because debian/rules wasn't updated to fix the version
<duflu> robert_ancell: I thought any ABI break should result in an ABI bump?
<duflu> That's surely why we separated ABI from version?
<robert_ancell> duflu, only for libmirclient. libmirserver is still considered ABI unstable
<robert_ancell> I'll send out an email clarifying
<duflu> robert_ancell: Alright, that would be helpful
<Mirv> I keep on getting bug #1210798 (private bug) on saucy from unity-saucy-compositor, ie. not starting up. sandy bridge intel graphics. will monitor the situation as/when updates come :)
<ubot5> Error: Launchpad bug 1210798 could not be found
<Mirv> I'll make it public, not much private there unless something ubersecret in the coredump
<Mirv> bug #1210798 - there
<Mirv> damn you ubot
<duflu> robert_ancell: Yes, VT switching works for me in USC. Bug updated.
<robert_ancell> duflu, thanks
<robert_ancell> RAOF, when we bump a package name (e.g. libmirserver0 -> libmirserver1) is there a manual approval for that to land in the archive?
<Mirv> robert_ancell: yes, I already looked at it but the deal is that I need to ack it with someone with upload rights before publishing
<robert_ancell> bug 1210798
<ubot5> bug 1210798 in unity-system-compositor (Ubuntu) "unity-system-compositor crashed with SIGSEGV in eglGetDisplay()" [Undecided,New] https://launchpad.net/bugs/1210798
<Mirv> ah, hmm, I wonder if it's about me having libhybris installed on x86
<robert_ancell> Mirv, that reminds me, we need to make u-s-c attach unity-system-compositor.log automatically
 * Mirv runs unity-system-compositor
<Mirv> ok, so the bug is just crashing without explanation if libhybris/etc installed on x86
<robert_ancell> Mirv, you uninstalled libhybris and that fixed it?
<Mirv> robert_ancell: yes. it uninstalled libhardware etc as well.
<tvoss_> good morning :)
<Mirv> morning tvoss_
<robert_ancell> tvoss_, I thought you were on holiday?
<tvoss_> robert_ancell, nope, only Friday
<tvoss_> robert_ancell, lool is on holiday, my alter ego :)
<robert_ancell> ah,  tag team
 * tvoss_ is happily running a non-slow XMir right now :)
<tvoss_> duflu, ping
<tvoss_> RAOF, ping
<robert_ancell> tvoss_, ping
<robert_ancell> tvoss_, you know you can just ask questions out loud :)
<Mirv> I think I can work with XMir, this mirror-by-default is good enough for what I need until true multi-monitor support
<robert_ancell> Mirv, nice!
<tvoss_> Mirv, woot
<duflu> tvoss_, pong
<tvoss_> duflu, hey there :) tried the bypass branch with xmir, seeing some occasional rendering hiccups
<Mirv> "nice!" to you, that is :)
<tvoss_> robert_ancell, yup :)
<duflu> tvoss_, interesting. Not sure how to gauge if it is bypass to blame, or just hiccups that were hidden by extra buffering before
<RAOF> tvoss_: Pong
<duflu> tvoss_: What is a hiccup?
<tvoss_> duflu, seems like a buffer arrives out-of-order
<duflu> tvoss_: Weird. I can't reproduce any such issue with plain Mir.
<duflu> Maybe something unusual about XMir vs normal clients
<tvoss_> duflu, ack, RAOF ^
<RAOF> tvoss_: On intel, I presume?
<robert_ancell> RAOF, bug 1211063 - does XMir load color profiles on startup and just not handle changes which would be via XRANDR yet?
<ubot5> bug 1211063 in Unity System Compositor "Color profile change is not instant when unity-system-compositor is running" [Undecided,New] https://launchpad.net/bugs/1211063
<RAOF> robert_ancell: We don't handle colour profiles *at all* at the moment.
<robert_ancell> RAOF, I thought so too - Is Jussi confused
<robert_ancell> ?
<RAOF> I think so?
<tvoss_> RAOF, ack
<tvoss_> RAOF, is that a known issue?
<RAOF> tvoss_: No, but it changes the plausible causes.
<tvoss_> RAOF, true :) anything else I can help to track down/triage the bug?
<RAOF> eg: We have in the past failed to flush correctly on radeon, so the buffer we submit to Mir didn't necessarily have fresh content.
<RAOF> tvoss_: What would be really good is a vsync'd app, displaying an increasing counter, counting up one per vblank, and a 60+Hz film of said client ;)
<tvoss_> RAOF, hah, nexuiz has got such a display, let me see if I can trick it into vblank ;)
<RAOF> XMir *is* the client we have that's most likely to show out-of-order artefacts, as it's the only client we have that doesn't submit a new frame each vblank.
<tvoss_> RAOF, true :)
 * tvoss_ needs more coffee
<RAOF> Actually, the requirement for vsync is spurious; all we need is something that displays a monotone counter that increases at least once per vsync.
<duflu> tvoss_: I will modify some demo client(s) to increase my visual test coverage... after lunch
<tvoss_> duflu, yeah, I will move over to the new place, back in 30
 * RAOF heads off to the doctors with ZoÃ«. Taking my laptop, so I should be around.
<robert_ancell> thomi, do you remember what the trigger was to make Jenkins do a test on a MP? I would like Jenkins reviews of https://code.launchpad.net/~a7x/lightdm/multiseat/+merge/178511 ideally before I approve the branches
<thomi> robert_ancell: I take it a7x is not a member of ~canonical?
<robert_ancell> nope
<thomi> robert_ancell: I believe in that case you need to vote to approve the MP (you don't need to top-approve it thought)
<robert_ancell> thomi, actually, he is a member of ~contributor-agreement-canonical - perhaps we should allow that group to trigger Jenkins
<thomi> robert_ancell: you can ask, but I doubt it'll go through. Signing the contributor agreement doesn't mean Canonical has any kind of leverage over them, in case something bad happens
<thomi> but I agree, it's a real PITA
<robert_ancell> thomi, well, you could kick them out
<robert_ancell> but yeah, I know what you mean
<thomi> if we had more time we should set something up on prodstack as a firewalled builder
<thomi> shouldn't be too hard to achieve
<robert_ancell> thomi, is there a way to manually trigger a build, e.g. like the form we use for rebuilding?
<thomi> yeah, you don't want to add an approve vote?
<smartboyhw> robert_ancell, why does unity-system-compositor only work in lightdm
<robert_ancell> smartboyhw, because no-one has used it in anything else. There's no particular reason why it couldn't be used elsewhere
<smartboyhw> robert_ancell, oh
<thomi> robert_ancell: I think I found the right job, just trying it now
<thomi> hmmm, nope!
<thomi> robert_ancell: I'm not sure how to do that, sorry. I can email fginther, and get back to you tomorrow, if you like
<robert_ancell> thomi, np
<robert_ancell> it's not that important
<thomi> ok
<duflu> tvoss_: I still can't reproduce any "hiccups" using bypass on mir_demo_server_shell with the example clients
<tvoss_> duflu, hmmm, might be XMir specific then
<duflu> I'm using Intel BTW
<duflu> RAOF: Is XMir now a well-behaved normal client? (no GBM-specifics)
<RAOF> duflu: No.
<duflu> RAOF: How so? Please forgive my forgetfulness...
<RAOF> Because it doesn't use GL to render; it uses the DDX's methods to render.
<RAOF> And it's not going to use GL to render for the forseeable future.
<dholbach> good morning
<duflu> RAOF: Hmm, OK. I don't really need to know what that means, other than to ensure that XMir only uses the buffer given to it by the client library, and for never longer than till the next swap. That's still true right?
<duflu> dholbach: Morning
<RAOF> duflu: That is true.
<RAOF> OOooh.
<RAOF> I have a plausible hypothesis.
<dholbach> hi duflu
<RAOF> How many times to you allocate buffers?
<RAOF> Or: how many times will you send a buffer that the client hasn't seen before?
<duflu> RAOF: Max 3 unique ones. Allocated lazily (when they're first required)
<RAOF> I think the current code fails to handle the case where buffer->age == 0, but that should only happen once per buffer allocation.
<RAOF> tvoss_: How many times do the hiccups occur?
<tvoss_> RAOF, hmmm ... difficult to tell, but regularly
<RAOF> So, unlikely to be that you're hitting the age==0 case.
<duflu> I can also see some damage/age-related bugs when toggling CCSM>OpenGL options
<duflu> But that's not really related
<duflu> tvoss_: What are you running to see hiccups in XMir? I suspect this might also be an issue - https://bugs.launchpad.net/xmir/+bug/1211186
<ubot5> Launchpad bug 1211186 in mir (Ubuntu) "[regression] GL(X) apps don't have vsync when running under XMir" [Undecided,New]
<tvoss_> duflu, gnome terminal
<duflu> tvoss_: Hmm, which branch or Mir/bypass and what revision? Keep in mind the input lag fix only just landed
<duflu> -or +of
<tvoss_> duflu, only landed now?
<tvoss_> duflu, as of Friday iirc
<duflu> tvoss_: Only landed in r955
<duflu> So looks like Friday night/Saturday your time
<tvoss_> duflu, let me recheck
<duflu> tvoss_: Would have only landed in lp:mir midnight Friday night your time
 * didrocks again sees issues with ATI
<didrocks> sil2100: doesn't seem around, let me try to match with a commit :/
<sil2100> ?
<sil2100> I'm here, what's up?
<didrocks> sil2100: didn't you see my ping?
<sil2100> Did I miss a ping?
<didrocks> 09:19:30 didrocks | sil2100: the -ati machine seems wracky again, it was ok on Friday/Saturday
<didrocks> 09:19:38 didrocks | sil2100: I think it's mir being the issue with that
<didrocks> 09:19:48 didrocks | (the tests are ran in mirslave)
<didrocks> 09:20:10 didrocks | can you see if anything was committed between latest good mirslave run and the new bad one in mir itself?
<didrocks> 09:20:24 didrocks | (so look at when exactly mirslave check started to fail)
<didrocks> 09:20:37 didrocks | and potentially match that with a mir rebuild which happened just before?
<didrocks> 09:21:20        * | didrocks reboot ati to save it first
<didrocks> multiple ones even ^
<sil2100> Ah! Ok, just saw the ping ones, didn't manage to read the rest of the context ;) Looking at mirslave
<sil2100> Runs
<sil2100> 11th was fine it seems
<RAOF> Grargh ATI
<mlankhorst> isn't memory corruption fun? :P
<didrocks> sil2100: no, look closer, sometimes the autopilot job is green, but just have one test running
<didrocks> (on ati)
<didrocks> and the job went stuck
<sil2100> I know, since job 72 failed since it only ran 1 job
<sil2100> But 71 seems ok, so checking changes in mir etc
 * didrocks hopes they were some
<didrocks> sil2100: also package list (both post-setup) maybe?
<RAOF> mlankhorst: I personally prefer texture corruption across suspend/resume cycles. That's more fun.
<mlankhorst> pfft :p
<mlankhorst> but I guess I'll try to isolate the issue at least
<mlankhorst> and figure out why ati is kernel corrupting on me
<sil2100> didrocks: still looking, but hm, doesn't seem like there were any intrusive changes - the build started failing when running Mir version from 12.1, but the only changes made since the time it was ok are the packaging change (shlib in rules) and one CMake change ;/ And unity-system-compositor had no new changes since 10th
<sil2100> Looking at the postsetup list for anything else
<didrocks> yeah, let's hope we can find something
<sil2100> But why is it always ati affected ;/?!
<sil2100> didrocks: how exactly did the ati machine hang up?
<didrocks> sil2100: so, what we saw last week, is that (it was 100% of the time at first):
<didrocks> u-s-c couldn't start or starts and hangs
<didrocks> unity couldn't start (stuck on opengl plugin, when duflu is running unity_system_compositor)
<didrocks> so the first opengl app hangs
<didrocks> then, the machine times out of 2h
<didrocks> if you then restart with regular xorg
<didrocks> nothing happens
<duflu> didrocks: duflu?
<didrocks> the machines hangs
<didrocks> duflu: sorry, I meant you run unity_support_test from compiz
<sil2100> uh
<didrocks> sil2100: so, it's really annoying, everytime, that's what screwing up the ati machine
 * duflu barely remembers what that means
<didrocks> duflu: you do run it if the unity plugin is setup to know if unity can be ran in that session
<didrocks> or should fallback on llvmpipe mode
<didrocks> IIRC
<sil2100> didrocks: since diffing the postsetup pkg lists show that only mir packages, unity-system-compositor and unity-autopilot are different between runs
<didrocks> sil2100: ok, no kernel, no driver?
<didrocks> weird, we had the issue 100% of the time
<didrocks> and then, not anymore
<didrocks> at all, in mutiple runs
<didrocks> sil2100: when did you see that starting again?
<duflu> didrocks: We've seen that problem before... https://code.launchpad.net/~vanvugt/ubuntu/quantal/nux/fix-1039155/+merge/128422/comments/281152
<sil2100> didrocks: I compared the last ok run (which ran more than 1 test), which was from yesterday
<sil2100> With the one today, which started failing
<didrocks> duflu: right, here the issue is that with Mir/u-s-c on ATI, the program hangs
<didrocks> (unity_support_test)
<sil2100> geh
<duflu> didrocks: Yes there have been problems on various machines where unity_support_test causes bugs if executed from within Compiz. I think I was advocating not running it from within Compiz (which solved the issues at the time)
<didrocks> duflu: but this only happen when u-s-c is running
<didrocks> with regular Xorg, no issue
<didrocks> and not everytime :p
<duflu> didrocks: The issue is much older than that and has been happening for an unlucky few for a year
<sil2100> didrocks: can I try re-running the mirslave stack? Since I missed last week and want to make sure the failure now is reproducible
<didrocks> duflu: I mean, we run compiz hundreds of times everyday
<sil2100> (or does it crash ati for good?(
<didrocks> if not thousands
<didrocks> from the past 8 month on this particular machine
<didrocks> duflu: only running xmir shows that issue
<didrocks> sil2100: it's running every 4h automatically now
<didrocks> sil2100: so let's wait for next run
<sil2100> Ok
<duflu> didrocks: I know and I could never reproduce it either. However those who did have the problem before, found the solution was to unity_support_test externally, as in https://code.launchpad.net/~vanvugt/ubuntu/quantal/nux/fix-1039155/+merge/128422
<didrocks> duflu: but it would be good to know why Xmir is showing the issue more
<didrocks> that doesn't explain the reason
<duflu> didrocks: True :(
<duflu> RAOF: Fun fact: DRM will successfully scan out non-scanout GBM buffers (!?)
<didrocks> duflu: do you think we should try it now?
<didrocks> duflu: and that will be compatible with u-s-c?
<duflu> didrocks: I can't remember all the details and how things fit together, but I do think it would be good to avoid any fork/exec from compiz
<didrocks> duflu: mind proposing an updated branch?
<duflu> didrocks: I'm on the critical path to deliver bypass support, so want to finish that first
<didrocks> duflu: sure, do you have any idea when you can tackle that one? (roughly?)
<duflu> didrocks: 1 week ? :/
<didrocks> humâ¦
<didrocks> ok
<didrocks> we have to find something/someone to do it beforehand
<didrocks> as otherwise it will mean no more Mir delivering in a week
<sil2100> Unacceptable ;/
<sil2100> didrocks: so hm, the workaround/solution would be to remove running unity_support_test from within compiz and just running it like in the branch duflu mentioned, i.e. separately (maybe upstart?)
<sil2100> I wonder if this would indeed help
<didrocks> sil2100: yeah, we need someone to try that with xmir though
<didrocks> sil2100: /etc/X11/Xsession.d/ is fine for now
<didrocks> (see #ubuntu-desktop)
<duflu> sil2100: You need to do it in a parent process of the X session, because if unity_support_test fails then export LIBGL_ALWAYS_SOFTWARE=1 has to be inherited by the compiz process
<sil2100> duflu: right, thanks!
<RAOF> duflu: How did you discover that?
<duflu> RAOF: I was just curious. Not sure why. It's weord
<duflu> weird
<sil2100> didrocks: I understand that you're hacking on it right now? Or should I try? But I won't be able to test it on xmir though, so will have to find someone running it
<didrocks> sil2100: please do, I'm in a ETOOMUCH already :/
<didrocks> sil2100: why can't you try on xmir?
<RAOF> duflu: We might accidentally allocate scanout-capable gbm buffers anywoy
<duflu> RAOF: Makes me think GBM's idea of scanout is different to DRM's, which would be important to know
<sil2100> didrocks: I am afraid it will make my system boom ;) Is it safe?
<didrocks> sil2100: it's easy to revert anyway
<didrocks> install unity-system-compositor
<didrocks> and uninstall it
<didrocks> for removing it
<didrocks> sil2100: what driver are you using?
<duflu> RAOF: All I have to decide right now is (width >= 800 && height >= 600)    ... :/
<sil2100> Ok, sounds easy
<sil2100> didrocks: the open radeon driver
<RAOF> duflu: It's also possible that there's *no* buffer which is incapable of scanout, depending on how funky intel's scanout hardware is.
<didrocks> sil2100: excellent, that's what we need :)
<duflu> RAOF: Yeah I figured drivers would be different on this. I will probably have to play with video cards
<didrocks> sil2100: I would advise you to first try with regular Xorg
<didrocks> sil2100: and ensuring that the script is ran
<sil2100> \o/ will do
<didrocks> thx!
<duflu> RAOF: Tho if you try to DRM flip a buffer with wrong dimensions that's pretty fatal
<duflu> At least, Mir makes it fatal
<mlankhorst> superrr deadly
<sil2100> didrocks: I'm quickly rebuilding compiz to remove that patch for running it from compiz, once this is done I test the scripts
<didrocks> thanks sil2100!
<duflu> Back in 30ish
<duflu> RAOF: XMir is buffer usage hardware, right? :)
<tsdgeos> guys, using mir_demo_server + mir_demo_client_accelerated on the Nexus 4 i get a black screen
<tsdgeos> any clue of what may be wrong?
<sil2100> brb, reboot
<duflu> tsdgeos: Probably surfaceflinger is still running?
<tsdgeos> duflu: nope
<tsdgeos> phablet@ubuntu-phablet:~$ ps -A | grep surf
<tsdgeos> phablet@ubuntu-phablet:~$
<duflu> tsdgeos: I have seen similar issues... Mir lacks explicit support for turning the screen on if it is off. But that's not usually an issue if you have fully disabled surfaceflinger (and reboot): https://wiki.ubuntu.com/Touch/Testing/Mir#Switch_from_SurfaceFlinger_to_Mir
<duflu> tsdgeos: Also, that issue I have seen is obvious because Mir will throw exceptions
<duflu> mir_demo_server* will throw exceptions
<tsdgeos> not here
<tsdgeos> stuff is here
<tsdgeos> on the shell
<tsdgeos> without complaining
<duflu> tsdgeos: Any hint that the backlight is *on* ?
<tsdgeos> how could i know?
<tsdgeos> it seems to be
<ogra_> use powerd-cli  to force it on
<duflu> It's usually obvious (not properly black)
<tsdgeos> i.e. if i reboot i get the "google" logo
<tsdgeos> until i start mir_server_demo
<duflu> tsdgeos: Yeah
<tsdgeos> that turns gray
<tsdgeos> looks "ok" to me
<duflu> tsdgeos: OK, so your server is running but not showing clients then
<duflu> tsdgeos: Because it sounds like the glClear from mir_demo_server* is working
<tsdgeos> should it show some FPS readings?
<tsdgeos> because the unaccelerated one does
<tsdgeos> but i still can't see anything on screen
<duflu> tsdgeos: Yes it will always be 60 FPS on Nexus4
<tsdgeos> see no output here
<duflu> tsdgeos: Does the client start/hang?
<tsdgeos> i do see 60fps with the unaccerelated
<tsdgeos> but the accelerated only gives
<tsdgeos> phablet@ubuntu-phablet:~$ mir_demo_client_accelerated
<tsdgeos> Starting
<tsdgeos> Connected
<tsdgeos> __pthread_gettid -2
<tsdgeos> Surface created
<tsdgeos> and that's it
<duflu> tsdgeos: OK then you have a GL-specific issue. Probably related to hybris
<tsdgeos> :/
<tsdgeos> who do i nag ?
<duflu> tsdgeos: https://bugs.launchpad.net/mir/+filebug   ;)
<tsdgeos> so it's going to be another day without any work done
<tsdgeos> awesome :D
<duflu> tsdgeos: Did you get all your binaries from the phablet image or hand built?
<tsdgeos> all image + apt-get upgrade
<ogra_> ugh
<ogra_> did you check that there are no bits in the apt-get upgrade that reach into the android side ?
<duflu> tsdgeos: Same result for mir_demo_client_egl* ?
<ogra_> (are yoou sure surfaceflinger works at all after you upgraded)
<tsdgeos> duflu: the egl ones print stuff to the shell
<ogra_> (if not, Mir wont either ... apt-get has to be used with *lots* of care)
<tsdgeos> but can't see stuff on screen either
<duflu> tsdgeos: How about mir_demo_client_fingerpaint?
<duflu> That should work (software rendering)
<tsdgeos> nothing
<tsdgeos> and it ended (returned to shell) after a while
<tsdgeos> seems the demo server quite
<tsdgeos> -e
<RAOF> duflu: yes indeed it is buffer_usage_hardware :P
<duflu> tsdgeos: It sounds a lot like your client and server are mismatched. :/
<tsdgeos> may be
<tsdgeos> sadly s-jenkins:8080/job/ubuntu-touch-phablet-image-saucy-mir/ hasn't had a correct build for a long time
<duflu> RAOF: Good. Because bypass cripples software buffer performance slightly. I have disabled bypass of those
<RAOF> Huh
<duflu> Not surprising. I would expect pushing pixels across the bus to GPU-land to be a bit slower
<RAOF> But you need to do that bypass or not bypass?
<tsdgeos> ogra_: what's your suggestion then to get something "up to date" given the last successful image is from 6 days ago?
<mlankhorst> duflu: well just do staging transfers from GART to VRAM :-)
<ogra_> tsdgeos, poke rickmm ... once he is up ... and beyond that use the latest normal image, diable SF there and install the Mir stuff you need (i dont think the Mir image does much different)
<duflu> mlankhorst: I don't know what you mean
<tsdgeos> ogra_: then why is it red :'(
<mlankhorst> perform a gpu assisted copy from system memory to VRAM
 * tsdgeos tries to do something else until ricmm or grayback are online
<duflu> RAOF: In buffer_usage_hardware we're just sending (smaller) instructions across the bus and the filling/blitting originates from the GPU. It's quite different
<ogra_> tsdgeos, no idea, i'm not affiliated with that image
<duflu> mlankhorst: Sounds interesting. Mir doesn't seem to with Intel at least.
<tsdgeos> ogra_: sure, not blaming you, just crying out loud
<mlankhorst> duflu: intel has no dedicated VRAM :P
<ogra_> tsdgeos, well, grab the latest normal image, disable SF and install Mir ... shouldnt be different :)
<duflu> mlankhorst: I know. Which makes me surprised there's any performance difference. But I would expect it with real cards
<tsdgeos> can try that i guess
<tsdgeos> ogra_: tx
<sil2100> How can I see if xmir is currently used?
<didrocks> sil2100: unity-system-compositor should be running
<sil2100> Ok, don't see it running here - is there anything else I need to do besides installing unity-system-compositor ? Any configuration switch?
<didrocks> shouldnt'
<didrocks> duflu: RAOF: ^
<didrocks> sil2100: cat /var/log/lightdm/unit*
 * duflu checks
<sil2100> http://paste.ubuntu.com/5976702/
<duflu> sil2100: You should have unity-system-compositor running, and also "ps auxw | grep mir" reporting mir options to X
<sil2100> This is from /var/log/lightdm/unity-system-compositor.log
<RAOF> That's *very* informative :)
<duflu> Heh
<duflu> sil2100: Wrong URL?
<sil2100> hm, good url but it seems the log has some non-ascii characters in it
<sil2100> Let me paste just the relevant parts
<sil2100> inkerlinker.c:1095| ERROR: Library '/system/lib/libGLESv2.so' not found
<sil2100> Segmentation fault (core dumped)
<didrocks> sil2100: hybris installed on your machine?
<seb128> libhybris
<RAOF> You win the "I've got hybris installed" award.
<sil2100> I wonder what's hybris doing on my system
<seb128> we need to stop diverting libgles from there...
<seb128> really
<tvoss> seb128, in the works as I understand it
<seb128> tvoss, great ;-)
<tvoss> seb128, I have had that issue multiple times in the recent past :)
<seb128> tvoss, you are not the only one ;-)
<sil2100> Ok, xmir works now with all things hybris uninstalled
<sil2100> Thanks guys!
<sil2100> didrocks: the Xsession.d detection seems to work fine
<didrocks> sil2100: you do have the file in /tmp/?
<didrocks> /tmp/unity_support_test.0
<sil2100> Yes
<sil2100> I also did the test that duflu recommended in that merge
<duflu> Why do we even have libhybris on desktop? https://launchpad.net/ubuntu/+source/libhybris
<sil2100> i.e. made unity_support_test -> /bin/false and had a fallback to llvmpipe
<sil2100> Works both for xmir and standard x
<sil2100> didrocks: now the steps to proceed... I will fill in a merge to lp:nux with the xsession.d file, but what about compiz? Since we don't daily release that yet
<sil2100> didrocks: (we should start daily-releasing this week btw.)
<sil2100> didrocks: should I modify the packaging and queue it up for sponsoring?
<didrocks> sil2100: juste prepare for a manual upload
<sil2100> Ok, doing one more check and then preparing everything
<didrocks> thx sil2100
<duflu> sil2100: Can you link it to bug 1066764 too?
<didrocks> mirslave just passed FYI this time
<ubot5> bug 1066764 in Nux "Unity fails to load on old hardware (compiz enabling LLVMpipe has no effect and Mesa tries to use hardware still)" [High,In progress] https://launchpad.net/bugs/1066764
<sil2100> didrocks: ;/ Still, if this is the root cause, I guess it's better to have it resolved
<sil2100> duflu: ok!
<sil2100> didrocks: btw. is DESKTOP_SESSION and GDMSESSION ubuntu-2d still used? Since my desktop didn't want to start when I was setting those when doing a fallback to llvmpipe
<didrocks> sil2100: I don't think they do work
<sil2100> didrocks: is setting those still required for the fallback mode or can I remove those and just use LIBGL_ALWAYS_SOFTWARE
<sil2100> didrocks: ok
<didrocks> sil2100: yeah LIBGL_ALWAYS_SOFTWARE
<sil2100> So they're leftovers then ;)
<didrocks> probably :)
<RAOF> Bah. One-surface-per-output is annoying.
<duflu> RAOF: How?
<RAOF> Because it means sharding the single X root window.
<RAOF> Which is awkward.
<sil2100> duflu: btw. in the old nux quantal branch I see you also removed the 01_blacklist_llvmpipe.patch patch as well, is that necessary?
<RAOF> So much so that it's time to investigate the CrtcSetScanoutPixmap route.
<duflu> sil2100: I have no idea. It was a long time ago
<sil2100> It wasn't mentioned in the change and it works here without removing it, so I guess I'll skip that
<davmor2> didrocks: I did a fresh install of saucy from fridays image over the weekend and am using mir from main that seems to of fixed the issues I was having thanks for the advice to drop the ppa :)
<didrocks> davmor2: great! :)
<sil2100> didrocks: btw. since I see we already had a conffile /etc/X11/Xsession.d/50_check_unity_support which we rm_conffile'd - you think I should add it with the same name or maybe choose a different one?
<didrocks> sil2100: same name is fine
<didrocks> sil2100: of course, remove the rm_conffile :)
<sil2100> Yep ;)
<sil2100> didrocks: for the compiz manual upload... should I create a bug for that version, or just poke you with the source package etc?
<didrocks> sil2100: no need for a bug
<sil2100> didrocks, duflu: https://code.launchpad.net/~sil2100/nux/unity_support_test/+merge/179666 <- it's the same change as duflu did in the past, just without removing the whitelist patch
<sil2100> didrocks: I sent the compiz source pkg to you by e-mail
<didrocks> sil2100: approved and sponsored compiz, thanks!
<duflu> sil2100: Thanks. But I must run away.
<mlankhorst> i think my radeon hd 6570 is just busted, if I disable UVD the memory corruption appears to be gone
<mlankhorst> but it still goes into lockup recovery every 10 seconds, until after 5 minutes of that it gives up and shuts itself down
<ricmm> hey guys
<ricmm> msh::SessionListener::stopping() gets called when the socket's client end disappears?
<ricmm> or when the client exits _explicitly_
<ricmm> greyback_: ping
<greyback_> ricmm: pong
<ricmm> :)
<greyback_> sorry, dropped out there
<ricmm> I asked this when you dropped
<ricmm> msh::SessionListener::stopping() gets called when the socket's client end disappears?
<ricmm> or when the client exits _explicitly_
<ricmm> as-in, would we get that when the process is SIGKILL'd
<ricmm> or only SIGTERM / exit()
<greyback_> yes, I just tested it now (you missed my reply) I "kill -9" an app, SessionListener::stopping() was called my Mir
<greyback_> s/my/by/
<ricmm> greyback_: awesome \o/
<xjunior> hey guys
<xjunior> I know, I know... I only get here with problems
<xjunior> Now what I'm seeing here, using a intel graphics card is "intel(0): [drm] failed to set drm interface version."
<xjunior> using the sleep trick doesn't work for me
<xjunior> another workaround I've seen was to use GDM instead of LightDM, but I'm trying to avoid that
<tsdgeos> ogra_: this morning you suggested using powerd-cli to make sure the screen was "on"
<ogra_> yeah
<tsdgeos> ogra_: http://paste.ubuntu.com/5977723/
<tsdgeos> the output feels not totally right
<ogra_> sudo -u pahblet -i
<ogra_> *phablet
<ogra_> make sure you are in the users session ... phablet owns the session dbus
<tsdgeos> ogra_: but then it says i need to be root
<tsdgeos> phablet@ubuntu-phablet:~$ powerd-cli display on
<tsdgeos> You must be root to run powerd-cli
<tsdgeos> do i sudo?
<tsdgeos> same warning if i sudo
<ogra_> tsdgeos, hmm, ask sfoshee ... it should work :(
<SamuRay> saludos
<SamuRay> alguien habla espaÃ±ol?
<xjunior> SamuRay: portugues
<SamuRay> xjunior, al menos entiendes lo que digo?
<xjunior> si
<SamuRay> xjunior, puedes ayudarme con un problema que tengo con mir?
<xjunior> SamuRay: depende... qual o problema?
<SamuRay> yo he venido usando mir desde hace algunos meses, el dia viernes hubo una actualizacion y me da un error
<racarr> Morning
<SamuRay> E: /var/cache/apt/archives/libmirserver1_0.0.8+13.10.20130808.2bzr948saucy0_amd64.deb: intentando sobreescribir `/usr/lib/x86_64-linux-gnu/libmirplatformgraphics.so', que estÃ¡ tambiÃ©n en el paquete libmirserver0:amd64 0.0.8+13.10.20130808.1bzr945saucy0
<SamuRay> morning racarr
<xjunior> SamuRay: tente
<xjunior> SamuRay: sudo dpkg --install --force-overwrite /var/cache/apt/archives/libmirserver1*.deb
<xjunior> racarr: morning!
<xjunior> racarr: would you try to help me with one intel issue? it seem to be failing to becomr DRM master or something
<SamuRay> xjunior, esto ha ocasionado que el ligthdm no inicie automaticamente
<xjunior> SamuRay: con usted?
<SamuRay> xjunior, no entiendo
<xjunior> SamuRay: o que esta ocasionando que el lightdm nÃ£o inicie automaticamnte?
<racarr> xjunior: I can try a little but I don't have an intel card or any ideass
<racarr> so nothing so far :p
<xjunior> have you seen people complaining about it?
<ricmm> kdub: hey kevin
<ricmm> tsdgeos is unable to bring up Mir on his nexus4 since a while back
<ricmm> seems to only be working on maguro
<racarr> xjunior: Not yet.
<racarr> ricmm: I think kdub is on vacation? (t/f?)
<racarr> it hasnt been that long since I tried on nexus 4 but I can try again today
<ricmm> ah right, you have one too
<ricmm> if you could that'd be great
<ricmm> theres no obvious error, just nothing on screen
<racarr> ok will do soon
<tsdgeos> racarr: yeah it'd be great if you can try, just to make sure i'm not doing something really stupid (which tbh i don't see what can be)
<tsdgeos> ricmm: racarr: ok, i'm eod'ing now, will be back in a few hours in non-working-mode in case you need me
<greyback_> racarr: hey, I'm looking into dandrader's work on the OSK. He was trying to add an extra surface type to Mir, but got resistance to that idea.
<greyback_> https://code.launchpad.net/~dandrader/mir/inputmethod_surface_type/+merge/173696
<greyback_> racarr: I'm considering alternative ideas, would you have a few mins to discuss it some time today?
<ricmm> tvoss: ping
<tvoss> ricmm, pong
<ricmm> according to the MR above, which seems to be stalled for a month now
<ricmm> would it make more sense for OSKs to use the overlay type?
<ricmm> how do we stack overlays and make sure the OSK has priority
<ricmm> we need to unblock that work today
<xjunior> filled this bug, racarr: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1211403
<ubot5> Launchpad bug 1211403 in xserver-xorg-video-intel (Ubuntu) "intel failed to become DRM master" [Undecided,New]
<tvoss> ricmm, looking
<racarr> ricmm: greyback_: I thought we decided to use
<racarr> the overlay surface type
<racarr> Am updating my phone now to test 4
<ricmm> racarr: well I think the problem here is how would the shell know which of the overlay surfaces is the OSK?
<tvoss> racarr, that contradicts what we have been discussing with design
<greyback_> racarr: I don't recall the decision being made anyway. I worry about needing the OSK surface to always be on top of everything else, so I need a unique way to identify it. I could identify the surface by its session
<racarr> Ok.
<racarr> greyback_: You still sort of need to identify it by session because
<racarr> it should be the only surface allowed to take the
<racarr> type we are using
<greyback_> racarr: indeed. But instead of just authorising it to take that session type, I can mark that surface in shell as special somehow, instead of relying on the surface type.
<racarr> Hmm
<greyback_> I don't particularly like that solution though
<racarr> yes, it feels like the surface type is a nice way to make that mark sort of though
<racarr> I would be happy to land that branch now :)
<ricmm> not so much the sort but the original identification is the issue I think
<ricmm> isnt it?
<racarr> tvoss: ricmm:?
<racarr> ricmm: No, because, its the same as clients
<racarr> with the PID based authorization
<racarr> then if the client is called OSK, you can trust it really is the OSK
<ricmm> right, but maliit-server isnt launched by the shell right now
<ricmm> greyback_: the plan is to launch it from the shell?
<ricmm> currently its a separate service, it needs to be up by the time the shell comes up
<racarr> at least the shell needs the PID right
<racarr> because the default policy is to dissaprove connections
<greyback_> ricmm: I figured shell would launch it.
<ricmm> iirc if you launch maliit-server after a shell is up, Qt fails to find it as an input method
<ricmm> not entirely sure how that works, but im sure it can be sorted
<racarr> right I mean the worst case is the shell is passed
<ricmm> and you are right, we need to authorize all sessions
<ricmm> so it has to happen after anyways
<racarr>  --with-maliit-pid=7
<greyback_> oh that's good to know, I wasn't aware of that concern
<ricmm> ew
<ricmm> racarr: now thats ugly
<ricmm> the shell could launch the upstart job, thats fine
<racarr> Of course XD, that's the literal worst case I can think of
<racarr> ok
<ricmm> its a session job anyways
<racarr> Ok
<ricmm> we just need to make sure that maliit-server wont block in that respect
<racarr> and if there are issues with Qt detection or something
<ricmm> I'll take that up with tmoenicke
<racarr> that can either be resolved or it can do it before initializing Qt
<ricmm> we can figure it out
<ricmm> lets agree on the surface type thing
<ricmm> who were the ones against it? daniel and alan?
<racarr> Alan had no strong opinion I think daniel thinks we should use the overlay type
<racarr> It's
<racarr> tvoss is right the design documents call for
<racarr> an input method surface type
<racarr> because input methods are still stacked under hints (i.e. tooltips), and the final overlay layer, which so far is only for things like
<racarr> magnifier or screenshot area selection
<tvoss> yup
<tvoss> racarr, ricmm I set the MP back to needs review
<racarr> I am happy to approve it there is one thing though
<racarr> does this really have to bump
<racarr> mirclient so version?
<racarr> I am
<racarr> super super sure no one is using mir_surface_type_arraysize_
<alan_g> racarr: if they are then they are the sort of idiot that cannot be protected from themselves.
<racarr> alan_g: Later this afternoon we find that someone was using it and it was me :p
<ricmm> we can live with that
<ricmm> alan_g: are you ok with approving this branch?
<alan_g> ricmm: sorry? I don't see the context
<ricmm> the input method surface type branch discussed above
<racarr> Top approved
<racarr> Bye alan :)
<racarr> ripping the cloggable event sink out of client-focus :D
<ricmm> racarr: \o/
<racarr> merging ~kdub/mir/connect-display-request
<racarr> if anyone wants to jump in and stop it before jenkins has its way :p
<racarr> connect-display-info has some of the worst merge conflicts I have ever seen :(
<racarr> even with weave merge, its basically still total file ocnflict on all the tests
<racarr> unit-tests got really slow
<racarr> over the last week
<racarr> probably takes 10x as long to run
<racarr> When did we get all these tests with
<racarr> sleeps, etc
<racarr> I think it's a bad idea. sometimes things that take <100ms locally, I have seen take > 10,000 ms on valgrind in qemu
<racarr> so you can never choose a reasonable sleep value
<tsdgeos> +1
<tsdgeos> sleeps in tests are not cool
<racarr> and now already the unit tests take 20 seconds, but if we have to bump the values because of failures
<racarr> bler :p ill look in to it after lunch
<racarr> Lunch!
<tvoss> racarr, ping
<racarr> tvoss: Pong
<tvoss> racarr, hey there
<tvoss> racarr, quick one: Do we hand over the appid to unity when a surface is requested?
<racarr> the app id
<racarr> like the session identifier
<racarr> or do you mean like the PID or something
<racarr> we do hand over the session identifier
<racarr> it merged not so long ago
<tvoss> racarr, ack. So whenever an app requests a surface, the session information is handed to unity?
<racarr> tvoss: Ok well not entirel when worded that way
<racarr> the surface now contains the session, so in all the
<racarr> surface created hooks etc the session is passed through
<racarr> however there are some componenets
<racarr> mainly the_shell_placement_strategy
<racarr> which deal in terms of msh::SurfaceCreationParameters
<racarr> here, we don't pass the session
<racarr> it seems like a good thing to pass
<tvoss> why not?
<tvoss> yeah, I think so, too
<tvoss> otherwise the implementation always needs to query the state from some tracking entity
<racarr> tvoss: I guess just omission :)
<racarr> because the only placement we have design for, can be decided entirely based on
<tvoss> racarr, can you fix that please?
<racarr> surface parameters
<racarr> Sure, what is it for?
<racarr> hmm I guess you would probably want it for OSK
<tvoss> racarr, well, session and surface are two things that belong together from my pov
<tvoss> racarr, that should be reflected whenever requesting a policy decision
<racarr> tvoss: mm
<racarr> tvoss: Ok ill propose it in an hour or so just finishing up some stuff from pre lunch now
<tvoss> racarr, thx
<tsdgeos> racarr: any luck with my nexus4+mir problem?
<racarr> tsdgeos: Not yet. my nexus 4 seems to be having battery issues, I upgraded, then it died in abttery halfway through and wouldn't come back on for 20 minutes, finished upgrade, started getting mir
<racarr> deps
<racarr> rinse repeat
<racarr> started building mir
<racarr> rinse repeat...
<tsdgeos> ouch
<racarr> I will get to it before EOD definitely though
<tsdgeos> awesome
<racarr> Man I have never had so much fun on a monday
<racarr> In particular considering I've spent almost the entire day with strange merge conflicts and the like
<racarr> lol
<RAOF> :)
<RAOF> racarr: Re: focus notification: we should move away from having the enum guard value be named foo_arraysize_, possibly to foo_enum_max_?
<racarr> RAOF: That seems more reasonable
<racarr> I'm not really sure what it's purpose is in some cases but I didn't want to argue it in thisMP XD
<RAOF> Actually, now that I think of it - I don't suppose the MirSurfaceFocusState enum could go away entirely?
<RAOF> Enumerating boolean values is odd :)
<RAOF> And you've already chosen to have it implicitly convertible to bool (deliberately, I presume?)
<racarr> RAOF: Hmm
<racarr> I dunno it's a little unclear because the state API still deals in integer values so
<racarr> you don't necessarily know as a client library consumer that mir_surface_state_focus can only take on two values
<racarr> I mean, that would be a really good guess :p but
<RAOF> We could document that mir_surface_get_state(mir_surface_attrib_focus); returns bool âº
<RAOF> Leaving the internal implementation as-is.
<racarr> Mm, I wonder if an enum is the preferred way to do that
<racarr> over using a comment though
<robert_ancell> RAOF, have you seen http://pad.ubuntu.com/xubuntu-mir?
<RAOF> robert_ancell: I suspect I've seen all the bugs on there, but I hadn't seen the pad itself; checking.
<racarr> RAOF: Also strange requirements from 3d headtracking displays may force us to add mir_surface_quasifocused in 2018
<racarr> :p
<robert_ancell> RAOF, yeah, can you just double check we have bugs against everything. It would be good to add bug links so we catch them all
<RAOF> racarr: Actually, that's a reasonable point; it's entirely possible that we'll want to do gaze-tracking focusish in the not-too-distant future (I, for one, would love it); an enum it is.
<RAOF> racarr: Or, probably, a bitfield, but we can transparently upgrade the unfocused/focused enum to a bitfield without changing API.
<racarr> RAOF: Mm ok sounds good
<RAOF> racarr: For explicitlness' sake, can you add an â= 0â to mir_surface_unfocused's definition?
<racarr> RAOF: Ok yeah
<racarr> I think I need to remove IPC semaphore too
<robert_ancell> RAOF, can you triage bug 1210316
<ubot5> bug 1210316 in xserver-xorg-video-ati (Ubuntu) "x crashes with radeon hd7850 video card with error /usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol: exaGetPixmapDriverPrivate" [Critical,Triaged] https://launchpad.net/bugs/1210316
<RAOF> Oooh, that's probably why.
<RAOF> robert_ancell: Do you think anyone would be interested in read-only XRANDR support? If so, I can push it to staging.
<robert_ancell> RAOF, in XMir?
<RAOF> Yeah
<robert_ancell> RAOF, yeah, staging should be safe for testing since no-one should be running it. I suspect XRANDR clients might get confused if they can't apply changes?
<RAOF> Dunno.
<RAOF> XRandR calls are allowed to fail for pretty much no reason at all.
<robert_ancell> RAOF, so clients just listen for events and attempt to apply changes and don't really care if they fail?
<robert_ancell> RAOF, also, currently clients just get a fixed config back, right?
<RAOF> Well, clients care if they fail, but they need to handle the case that they fail.
<RAOF> Yeah. Clients get whatever Mir set up.
<racarr> RAOF: pushed the changes you suggested (plus removed ipc_semaphore.h)
#ubuntu-mir 2013-08-13
<robert_ancell> RAOF, on that Xubuntu list there seem to be two chipsets that have bad failures, GeForce 6150SE nForce 430 and RV370/M22. Do we have known bugs for that?
<RAOF> robert_ancell: I haven't found any yet.
<racarr> Off for now!
<racarr> ill come back later and iterate on connect-display-request-merge and client-focus-notifications if people have time to review
<RAOF> Grr. I hate this code.
<duflu> ?
<RAOF> Oh, splitting up the root window.
<RAOF> I'll just get it to work now, and then refactor out all the ugly.
<RAOF> Or at least as most ugly as possible.
<duflu> Oh, right, multimonitor?
<RAOF> Yeah.
<RAOF> duflu: Oh, I seem to remember you having thoughts on a hw cursor api?
<duflu> RAOF: Only minor thoughts...
<duflu> Also someone started already...
<RAOF> Oh, yeah.
<RAOF> That's right.
<duflu> RAOF: Bug 1189775, bug 1206780
<ubot5> bug 1189775 in Mir "Mir cursor has no hotspot setting, assumes (0, 0)" [Medium,In progress] https://launchpad.net/bugs/1189775
<ubot5> bug 1206780 in Mir "Clients cannot change the hardware cursor" [Low,Triaged] https://launchpad.net/bugs/1206780
<RAOF> HW cursor is a prerequisite of useful GLX bypass, so I may need to pick that up.
<tvoss|eod> good morning
<RAOF> tvoss|eod: Good morning
<tvoss> RAOF, hey there :) how is it going?
<RAOF> This code is ugly, and I hate it.
<tvoss> RAOF, the multi-monitor stuff?
<RAOF> Yeah.
<RAOF> But I'll get it to work, and then unuglify it.
<RAOF> To the extent that's possible.
<alf__> RAOF: FYI, a branch adding some of the requested extra display configuration information has landed
<RAOF> Woot!
<RAOF> alf__: Thanks.
<alf__> RAOF: basically Output::type, Card::max_simultaneous_outputs, Output::preferred_mode
<RAOF> Nifty. That'll mostly complete the read-end of randr.
<didrocks> duflu: it seems you were right, since we remove this unity_support_test call from opengl, the ATI hang isn't showing (yet)
<didrocks> it's still a workaround and not a fix, but good enough for me :)
<duflu> didrocks: The guess is well-educated. Mixing multiple GL contexts with fork/exec is apparently a bad idea, sometimes
<duflu> ... which means don't run a GL app (unity_support_test) from within a GL app (compiz)
<didrocks> duflu: I still wonder how/why u-s-c exacerbate this behavior, but at this stage, this is good enough :)
<didrocks> duflu: but when compiz is starting another app
<didrocks> from the launcher
<didrocks> it fork/exec another potential GL app
<RAOF> Wasn't it hybris that exacerbated this behaviour?
<duflu> didrocks: I'm more curious why a few people hit the problem a year ago, but the rest of us did not
<didrocks> (but I guess you meant during opengl initializion)
<didrocks> RAOF: no :/
<didrocks> RAOF: we got more faulty ran this week-end, after we removed hybris
<didrocks> duflu: right, that's really weird
<duflu> didrocks: One explanation is that very few people actually attempt to use hardware that would fail unity_support_test
<duflu> Hardware that's not a VM...
<didrocks> possibly, but we see that ATI can fail in that case, but it never failed with plan xorg, just with xmir
<didrocks> so it's not only hardware-related
<didrocks> there is a chain of event
<didrocks> duflu: argh, I talked too quick
<didrocks> RAOF: duflu: ATI machine stuck now :/
<didrocks> Mirv: FYI ^
 * didrocks checks the compiz version
<RAOF> Grargh!
<didrocks> 1:0.9.9~daily13.04.18.1~13.04-0ubuntu4
<didrocks> ok, we have the one with the fixed version :/
<didrocks> RAOF: do you think anything you can do or I should reboot the machine?
<RAOF> It might be worth attaching gdb again and confirming that it's blocked in the same place?
<didrocks> RAOF: want access?
<RAOF> Yeah, why not.
<RAOF> I've realised that I can't actually get the setting part of multi-monitor to work until I can bind a surface to an output, so let's play SSH!
<didrocks> ;)
<dholbach> good morning
<tsdgeos> racarr: any luck with my nexus4 issue?
<tsdgeos> yay
<tsdgeos> at least now it's crashing :D
<duflu> tsdgeos: Sounds like your expectations have lowered :/
<tsdgeos> duflu: well it was doing nothing, it now crashes
<tsdgeos> tbh that is a small improvement :D
<sil2100> duflu: hi! It seems the compiz unity-support-test running outside of compiz did not help in the u-s-c crashes on ati, sadly
<duflu> sil2100: Then I am out of ideas
<smspillaz> sil2100: stacktrace ?
<sil2100> smspillaz: not sure if we have any, the machine is usually in really bad condition when that happens
<duflu> tsdgeos: Confirmed, after upgrading to the latest phablet images, N4 hangs instead of rendering. Black screen :/
<tsdgeos> \o/
<tsdgeos> it's not only me being stupid
<duflu> Not at all
<duflu> tsdgeos: Do you have a bug logged in mir yet?
<tsdgeos> i think not
<tsdgeos> let me check
<tsdgeos> duflu: nope, i was waiting for a second person to confirm
<tsdgeos> can do now if you want
<duflu> tsdgeos: Yes please. And don't be afraid to log bugs early and confirm later
 * duflu shuts down to swap video cards
<tsdgeos> duflu: https://bugs.launchpad.net/mir/+bug/1211694
<ubot5> Launchpad bug 1211694 in Mir "Black screen on Nexus4" [Undecided,New]
<duflu> tsdgeos: Thanks
<tsdgeos> duflu: sorry i did not remember your name
<tsdgeos> so i wrote your ircnick
<duflu> tsdgeos: /whois duflu
 * tsdgeos is not as good with nicks <-> names <-> faces has he'd like
<tsdgeos> duflu: i know but you were not here when i was filling the bug :D
<duflu> tsdgeos: Sorry, I am playing with video cards. I won't have much attention on IRC for the rest of the day
<tsdgeos> duflu: no worries :-)
<RAOF> smspillaz: Not (obviously) compiz's fault - X is hung in DRI2Authenticate, waiting on xmir_drm_auth_magic to complete.
<duflu> RAOF: Any chance we will/can accept the community-provided patch for https://bugs.launchpad.net/mir/+bug/1195425 ?
<ubot5> Launchpad bug 1195425 in xserver-xorg-video-ati (Ubuntu) "Corrupted screen using radeon drivers" [Critical,Triaged]
<duflu> (comment #12)
<RAOF> Yes, I can apply that.
<duflu> RAOF: For the record, I have nothing to do with it. Just noticed the bug and community activity therein
<RAOF> Yeah, I was aware of the problem and the patch (which was also a reply to the upstream patch submission bit); I just didn't think we hit it.
<RAOF> Thanks for pinging me with it.
<duflu> RAOF: I'm playing with a Cedar card and have serious corruption in render_surfaces. But haven't tried the patch
<RAOF> The patch is only for XMir; render_surfaces is going to be a different problem.
<duflu> RAOF: You mean https://launchpadlibrarian.net/144789844/mir_fix_tiling.diff ?
<RAOF> Yes
<duflu> Hmm
<RAOF> Possibly in the mesa patch ;)
<duflu> RAOF: Ok, just noticed the render_surfaces bug is a recent regression. Likely caused by the switch branch and the bug is limited only to render_surfaces with its wacky buffer initialization
 * duflu changes graphics cards again
<RAOF> didrocks: ppa:raof/aubergine contains an annotated mir/xmir stack that'll dump info about the drm auth process.
<duflu> Woo, 3 minutes. New record?
<RAOF> That's nice and fast.
<duflu> Can't do that with Windows
<didrocks> RAOF: excellent! I think next run, when the machine will be freed, you won't be around
 * RAOF uses his bios to switch graphics cards, so it's approximately 1 standard boot time to change.
<RAOF> didrocks: That is highly likely :)
<didrocks> RAOF: do you prefer to connect live when we try that? we can do that tomorrow in that case
<RAOF> didrocks: The interesting stuff will be in /var/log/Xorg.0.log, and /var/log/lightdm/*
<RAOF> I'm happy for this to just get run and have the logs dumped on me.
<didrocks> RAOF: ok, let's try that :)
<didrocks> RAOF: one run passed successfully meanwhile FYI
<didrocks> so it's not a 100% hit unfortunately :/
<RAOF> Yay. Race condition!
<didrocks> RAOF: oh, I'm afraid we'll get newer Mir though throughout the day
<didrocks> RAOF: can you try to push mir with a higher version?
<RAOF> Allow me to upload to my ppa again, this time with an epoch?
<didrocks> RAOF: sounds good :)
<mlankhorst> already? haha
<didrocks> I would never thought I would say epoch is good :p
<didrocks> think*
<didrocks> RAOF: I'm a little bit afraid you uploaded u-s-c to early without an artificial bump on debian/control
<didrocks> RAOF: so it's getting published before Mir
<didrocks> and so package dependency won't work
<RAOF> didrocks: Oh, arse. Allow me to fix that.
<mlankhorst> lol
<mlankhorst> one more epoch later!
<RAOF> Hm. The 3.11 kernel looks like it might have fixed the hsw texture corruption on suspend/resume.
<didrocks> sil2100: RAOF: I think I just press the "I'm feeling lucky" button and just get the ati card screwed starting at the first run!
 * didrocks now collect logs
<didrocks> RAOF: https://bugs.launchpad.net/mir/+bug/1204939/comments/11
<ubot5> Launchpad bug 1204939 in Mir "Unity doesn't start on ATI test machine (hang in mir_wait_for())" [Critical,Triaged]
<didrocks> sil2100: ok, now that those infos are extracted, I'm rebooting the ati machine FYI ^
<sil2100> ;)
 * sil2100 checks the logs
<sil2100> didrocks: I guess Daniel might take a look at those logs as well, maybe he would have some ideas as well - if he has enough time to look at them
<didrocks> yeah
<sil2100> didrocks: I think we need to make sure everyone knows what happened
<sil2100> didrocks: did you poke Pat and Kevin?
<didrocks> sil2100: oliver is doing the communication work :)
<sil2100> Awesome
<sil2100> didrocks: Apps finished, all green :O
<didrocks> sil2100: wooow \o/ green again
<sil2100> :O <- shocked face
<didrocks> sil2100: running more make it less a burden to fix issues
<sil2100> didrocks: so it seems, as less changes are in during releases, so even less possible stacks to fail at once ;p
<didrocks> right :)
<xjunior> is ickle around?
<xjunior> Chris Wilson
<olli_> RAOF, ping
<olli_> thomi, ping
<thomi> olli_: Hi
<olli_> thomi, hey
<olli_> thomi, mind having a look at http://bazaar.launchpad.net/~ubuntu-testcase/ubuntu-manual-tests/trunk/view/head:/testcases/packages/1572_xMir to see if this is in good shape for a round of call for testing as part of balloons cadence testing
<thomi> sure
<olli_> thomi, focus for this should be to test mir out of archive
<olli_> and to get some wider HW coverage from the community
<olli_> balloons mentioned he is accepting changes via branches ;)
<olli_> thomi, thx
<thomi> yeah OK, there are a few tweaks I'd make
<thomi> olli_: what's the timeline for this?
<olli_> the CFT will happen on Sat 8/17
<olli_> so before EOW, preferable earlier
<thomi> olli_: OK.
<thomi> I'll finish writing this looooong bug report, then get to it :)
<olli_> thomi, awesome
<olli_> thomi, we will provide them with additional information on
<olli_> how to install etc
<olli_> as well as release notes type of information (i.e. don't file MM not working...)
<olli_> so you don't have to worry about it
<olli_> but you can if you want ;)
<thomi> olli_: if MM doesn't work, we should remove it from that list
<olli_> I'll start putting something together and copy you on it for comments
<thomi> cool
<thomi> thanks
<olli_> coolio
<olli_> thx
<racarr> Client-focus-notifications v5!
<racarr> Is anyone besides tsedgos able to reproduce this mir not working on nexus 4 thing I have been hearing about
<racarr> I just tested fresh everything and it seems fine
<olli_> racarr, ev was having issues
<RAOF> Ok. What the hell is going on with the jenkins ATI machine?
<bschaefer> RAOF, hey, so I've been seeing these memory leaks, but they look like libEGL and not the clients fault: https://bugs.launchpad.net/mir/+bug/1211982
<ubot5> Launchpad bug 1211982 in Mir "Memory leaks in libEGL while running mir" [Undecided,New]
<bschaefer> unless i've missed cleaning something up, or the demos missed cleaning something up
<RAOF> That does look a lot like a leak in Mir's EGL, doesn't it.
<bschaefer> RAOF, yeah, i've seen the dri2_create_screen leak for sometime now...but figure to at lease poke you about it
<RAOF> Pity about those ??? frames :)
<bschaefer> yeaah
<RAOF> Got the -dbgsym packages installed?
 * bschaefer checks
<bschaefer> well im assuming I don't :)
<bschaefer> RAOF, http://paste.ubuntu.com/5983019/
<bschaefer> for the first one, still some ?? for the second, let me dig for those packages
<RAOF> Yup, there's the leak.
<bschaefer> RAOF, interesting, well let me collect better info and update the bug
<bschaefer> dang... just empty ??? that are left: http://paste.ubuntu.com/5983021/
 * bschaefer wondres which package that would be
<RAOF> libgl1-mesa-dri-dbg, I wager.
 * bschaefer installing
<jono> hey all
<jono> btw, I am collating Mir testing of gpus at https://wiki.ubuntu.com/Mir/GPUTesting
<RAOF> Hey jono!
<bschaefer> still question marks for that one...but it filled in a bunch of ??? for an uninted var:
<jono> hey RAOF :-)
<bschaefer> http://paste.ubuntu.com/5983027/
<jono> this should provide a better idea of overall gpu coverage
<bschaefer> RAOF, ill look for some dbg packges, and take a look at the source code to figure out which lib is being called
<bschaefer> thanks for the info!
<bschaefer> the full log atm: just 3 more ??? to go... http://paste.ubuntu.com/5983033/
<RAOF> Ah. That ioctl is going to be noise.
<bschaefer> cool, then just 2 leaks that I see in egl apps, and with sdl on the mir side of things :) which is not a lot
<RAOF> How annoying are these leaks for you? I(should)'ve plugged the create_window_surface one, and I can check out the other one.
<bschaefer> RAOF, not at all annoying, just saw them when I was checking my own memory leakage
<RAOF> Ok.
<RAOF> I'll fold them in next time I need to update mesa then.
<bschaefer> RAOF, everything is still running smooth, and its only during creation, and termination of the program so its not a huge deal
<RAOF> Yeah. You'll also leak once per surface you create, but you're unlikely to do that in a loop :)
<bschaefer> one would hope :), depending on the application...but yes
#ubuntu-mir 2013-08-14
<RAOF> Ok. I'm confused.
<RAOF> racarr: Around?
<racarr> RAOF: Yeah
<RAOF> racarr: Do you have any goddamned idea why https://bugs.launchpad.net/mir/+bug/1204939 might be happening?
<ubot5> Launchpad bug 1204939 in Mir "Unity doesn't start on ATI test machine (Mir fails to respond to drm_auth_magic request)" [Critical,Triaged]
<RAOF> Check out the patch in the description, plus the server & client output.
<racarr> System hang
<RAOF> Except you can ssh into the machine in this state, and attach gdb to whatever you want to, and prod it.
<racarr> oh no I meant I had a system hang
<RAOF> Hah.
<RAOF> :)
<RAOF> So you did not get my question?
<racarr> I do not have an immediate guess..
<racarr> I ust cancelled all my evening plans though because I am having weirdcramps (kind of overexerting lately)
<racarr> so I can look at it some tonight lol
<racarr> Um, if I had any god damned idea?
<RAOF> Boo cramps!
<racarr> sok. I think it's from building a massive metal dome hich was pretty satisfying
<racarr> ok. I will think about it and be back after dinner ~40 minutes?
<robotfuel> thomi: I have this new bug that prevents nexuiz from running on xmir for benchmarks https://bugs.launchpad.net/xmir/+bug/1212062
<ubot5> Launchpad bug 1212062 in XMir "xmir crashes to greeter when running nexuiz phoronix test" [Undecided,New]
<robotfuel> thomi: logs aren't that good at pin pointing the crash :/
<RAOF> Heh. Pulseaudio appears to think that my HDMI audio sink is at 48KHz whereas it's really 44.1KHz. Dummy sounds really weird sped up by 10% :)
<RAOF> robotfuel: Wait, apport didn't catch the actual segfault?
<robotfuel> RAOF: no the logs are pretty much not useful
<robotfuel> RAOF: the u-s-c log shows it's restarting, but that's it.
<RAOF> Bah.
<RAOF> Apport *should* catch that segfault and give us a lovely symbolic backtrace.
<RAOF> Whee. Nexuiz is pretty big.
<robotfuel> RAOF: I had it turned off, I've turned it back on and will upload the crash it collects
<RAOF> a
<RAOF> Ah, cool.
<robotfuel> I didn't want stray windows about a web apps crashes messing with my benchmark numbers.
<RAOF> Fair call.
<robotfuel> RAOF: thomi the new bug via apport  https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1212065
<ubot5> Error: launchpad bug 1212065 not found
<robotfuel> I'll make the other one a dupe
<RAOF> Ta muchly.
<thomi> seems like it's still private
<thomi> at least until the LP retracer thingie does it's work
<RAOF> I should be able to see it even while it's private, but I can't.
<robotfuel> I made it public
<robotfuel> strange that it was private
<thomi> bugs with stack traces that might contain private info are marked private by default
<thomi> lp then redacts that information and makes the bug public again
<robotfuel> I've moved the bug to xmir because it only happens when the u-s-c is installedhttps://bugs.launchpad.net/xmir/+bug/1212065
<ubot5> Launchpad bug 1212065 in XMir "Xorg crashed with SIGABRT in VidModeSetViewPort()" [Undecided,New]
<robotfuel> ugh No symbol table info available. maybe I need dbg packages?
<RAOF> robotfuel: Nah, the apport retracer should go back in and fill in everything.
<RAOF> *should* âº
<robotfuel> I have to run thanks for your help RAOF and thomi
<thomi> RAOF: any luck with that bug?
<RAOF> thomi: The nexuiz bug? The retracer hasn't touched it yet.
<thomi> boooo
<RAOF> Ah, there we go.
<thomi> oh?
<RAOF> The retracer has now touched it :)
<RAOF> Huh, yes. That's not going to work.
<RAOF> :)
<racarr> RAOF: I may have gotten distracted when I found the dongle to plug my guitar in to my computer
<RAOF> racarr: Woot!
<racarr> I am back to thinking though um
<racarr> so how does the failsafe X session
<thomi> RAOF: why not?
<racarr> come in to play?
<RAOF> racarr: The failsafe X session doesn't come into play. Or, rather, it comes into play after the test times out and decides that it's all gone pear-shaped.
<racarr> oh ok
<RAOF> thomi: Because it calls sna_crtc_set_mode_major; we need to disable that codepath under nested :)
<RAOF> racarr: I need to set up my keyboard somewhere that I can actually play it. Also, find all my music. âº
<thomi> RAOF: ok, so "That's not going to work" means "I know what the problem is, and how to fix it", not (as I thought) "the new stack trace does not help me fix the issue" :)
<RAOF> thomi: Right.
<thomi> RAOF: racarr: in Boston, we should get instruments and have a mir-team plus guests jam session :)
<racarr> Oh...yes we should!
<racarr> I'll bring my guitar
<RAOF> thomi: I'd be pretty rubbish at a jam session, I suspect :)
<thomi> no way I'm taking my guitar on an American airline flight though :)
<thomi> RAOF: me too, that's half the fun :)
<racarr> RAOF: Chords!
<racarr> then you add notes, and add fewer if they sound really bad
<racarr> it's easy
<RAOF> :)
<racarr> Ok so wait this lastlog
<racarr> seems to imply that
<RAOF> http://www.homestarrunner.com/sbemail36.html
<racarr> drmAuthMagic
<racarr> oh wait
<racarr> ok so is that actually failing? andit's a permissions sorta thing with the session stuff
<racarr> or could it still be
<racarr> some sort of mir failing to send the reply
<RAOF> Yeah, that's what I thought.
<RAOF> Because you can see the second request successfully written to the socket, but nothing server-side about it.
<thomi> RAOF: any idea when we can land the X fix? I need to give an estimate to olli
<RAOF> thomi: For nexuiz?
<RAOF> thomi: I'll fix it up now if it's urgent.
<RAOF> Clearly it is urgent, soâ¦
<racarr> RAOF: ButI mean around
<racarr> http://paste.ubuntu.com/5983202/
<racarr> l155, do we know if ret < 0?Or is it still unclear
<thomi> RAOF: yeah, I'd say it's pretty urgent, it's blocking xmir certainly
<RAOF> thomi: Along with this ati banana, yeah.
<thomi> :)
<RAOF> racarr: We don't know if ret < 0, but we do know that we never get there the second time. Also, we know that the first call succeeds.
<RAOF> (Because otherwise X would be all bailing)
<racarr> ohhh
<RAOF> Also, the exception would propagate out, kill unity-system-compositor, and get logged.
<racarr> ok thanks I misinterpreted
<racarr> Wait what do you mean we dont get there the second time,Doneauth appearstwice
<racarr> Oh I see
<racarr> its printed twice
<RAOF> Right.
<RAOF> I shouldn't have used the same string for both bits :)
<RAOF> But you get two entry prints, and the "Done auth" is done for each entry print.
<RAOF> Man, that's an unclear sentence :)
<racarr> Mm
<racarr> it would be useful to have
<RAOF> But for a successful auth you'll see âIn drm_auth_magic to auth magic:â¦ In DRMHelper::auth_magicâ¦ Done authâ¦ Done authâ
<racarr> MIR_SERVER_SESSION_MEDIATOR_REPORT and MIR_SERVER_MSG_PROCESSOR_REPORT=log
<racarr> I can't figure out, how far the second auth is getting beyond sent
<RAOF> Ah, right. I've not instrumented the server end of the RPC channel.
<RAOF> didrocks: Good morning!
<didrocks> hey RAOF! thanks for the bug report update
<RAOF> Thanks for running the tests.
<didrocks> just a little bit scared about the "I have no idea why" :)
<didrocks> yw! I got lucky, first time and strike! :)
<RAOF> :)
<didrocks> It's even annoying, I was preparing myself to a lot of try & retry pain :)
<didrocks> RAOF: the machines are free for the next 25 minutes, not sure if this can help though
<RAOF> Hm. We could try again with MIR_SERVER_SESSION_MEDIATOR_REPORT and MIR_SERVER_MSG_PROCESSOR_REPORT set to log.
<RAOF> That's what racarr suggested.
<didrocks> so, environment variable?
<didrocks> shold we just set them to something like 1?
<RAOF> Yeah. Or we could pass those options in.
<RAOF> Nah, both should be set to "log"
<didrocks> ah ok :)
<didrocks> let's try that
<RAOF> Want me to log in, or will you do the honours?
<didrocks> RAOF: please log in
<didrocks> I need to refind the run first
<didrocks> now the question isâ¦ what archive was it :p
<RAOF> :)
<RAOF> You have the unity launcher always visible? :P
<didrocks> RAOF: since the update, I can't reveal it anymore
<didrocks> so forced to have it always visible :/
<RAOF> Oh, which update?
<didrocks> like a month ago
<RAOF> Huh. Works here. Of course.
<didrocks> when changing with the latest X the barrier logic
<didrocks> RAOF: ah, better, it's fixed now \o/
<didrocks> a little bit hard, but good enough :)
<RAOF> Now we have a full 1920px worth of terminal!
<didrocks> heh, indeed :)
<didrocks> ok, let me find again the command I wrote to restore an archive :p
<didrocks> interesting
<didrocks> who wrote that buggy code? :p
<RAOF> :)
<didrocks> RAOF: looks good to you?
<RAOF> Yup
<didrocks> RAOF: let's poweroff to have new fresh logs
<RAOF> Yeah.
<RAOF> Also, I'm not sure if lightdm does the right thing wrt unity-system-compositor on restart.
<didrocks> RAOF: do you think we should reboot the machine?
<didrocks> can do quickly
<RAOF> I don't think so.
<didrocks> RAOF: just doing it, as the state was screwed the second time we start it
<RAOF> Fair 'nuff.
<didrocks> don't want to pollute the result :)
<duflu> ping mlankhorst
<didrocks> RAOF: please re-ssh and re-byobu :)
<didrocks> RAOF: it's all yours now
<RAOF> didrocks: Bah, that worked.
<didrocks> argh indeed
<didrocks> let's try to shut it down
<RAOF> Although I don't see the logs I'd expect.
<didrocks> and reboot again
<didrocks> ah?
<RAOF> So maybe the environment isn't set in the right place?
<didrocks> hum
<didrocks> didn't I write in that file? :/
<RAOF> We could also edit /etc/lightdm/lightdm.conf.d/10-unity-system-compositor
<didrocks> let's retry first
<RAOF> Yeah
<didrocks> RAOF: quick way to see it worked or not?
<didrocks> RAOF: if not, you can poweroff/restart
<RAOF> Didn't get the logs we wanted.
<RAOF> Also, worked.
<didrocks> ok, I let you edit :)
<didrocks> (annoying those apps changing term cap)
<RAOF> didrocks: Going to shut down and try again?
<didrocks> RAOF: please do :)
<RAOF> I've not paid attention as to how you actually start it ;)
<RAOF> Although I guess the <up> key could work :)
<didrocks> ah ok :)
<didrocks> yeah
<didrocks> RAOF: waow, how did you guess the default user password? :p
 * didrocks runsâ¦
<RAOF> :)
<didrocks> ok, restarted then
<didrocks> RAOF: no luck?
<RAOF> Wah, box keeps being restarted.
<didrocks> oh right
<didrocks> let me fix that
<didrocks> sorry
<didrocks> urgh
<didrocks> that's weird
<didrocks> it should have copied the "fixed versoin"
<didrocks> let me recheck
<didrocks> RAOF: in fact all the tests ran
<didrocks> that's why it's shutting down
<didrocks> grrr, this starts to be annoying, last time it was the way to go
<didrocks> oh
<didrocks> I'm sooooo stupid
<didrocks> saucy-i386-20130813-0917
<didrocks> saucy-i386-20130809-0917
<didrocks> in the path
<didrocks> I could have tried for a long timeâ¦
<RAOF> :)
<didrocks> ok, this time, my first attempt should be the right one
<didrocks> that explains as well why the /etc/environment wasn't exposed
<RAOF> Heh
<didrocks> ok good :)
<didrocks> shoudln't restart now
<didrocks> the stage is yours
<RAOF> Great. So, we've got the logs we're after.
<didrocks> \o/
<RAOF> Now we just need to actually trigger the bug.
<didrocks> right
 * RAOF is on Mir weekly call for a while
<didrocks> ok ;)
<RAOF> Feel free to keep restarting until you hit the bug :)
<didrocks> RAOF: doing :p
<didrocks> bahâ¦ 15 restarts without any issue, I wonder if the debugging log helped maybe to slow it down enough
<RAOF> Yay heisenbug?
<didrocks> exactly :/
<didrocks> RAOF: yeah, I have no idea :/
<didrocks> RAOF: I've archived it just in case
<RAOF> TA.
<didrocks> should I give back the machine to production?
<didrocks> (I guess still ~5 minutes for it being free)
<didrocks> yeah, the machine is needed, freeing it
<RAOF> Sorry, yeah.
<dholbach> good morning
<Mirv> racarr / ricmm: re: http://bazaar.launchpad.net/~phablet-team/qtubuntu/trunk/revision/165 (mir backends) - there's double dh_auto_configure, the latter one under override_dh_install. that's probably harmless, but also unintentional?
<racarr> Mirv: I think that was me, and it was unintentional
<Mirv> racarr: ok, filed bug #1212131
<ubot5> bug 1212131 in qtubuntu "Double dh_auto_configure in debian/rules" [Undecided,New] https://launchpad.net/bugs/1212131
<Mirv> I'm just finishing testing with the new packages, just to be sure
<Mirv> works fine on nexus 4
<Mirv> (which was to be expected, but I just wanted to see it in action..)
<mlankhorst> duflu: pong
<duflu> mlankhorst: Sorry in hangout now
<sil2100> duflu: hi! Once you're over with the hangout, I know you're busy but you might have some quick insights on https://bugs.launchpad.net/mir/+bug/1204939 with the new debugging data, as per Didiers comment:
<ubot5> Launchpad bug 1204939 in Mir "Unity doesn't start on ATI test machine (Mir fails to respond to drm_auth_magic request)" [Critical,Triaged]
<sil2100> https://bugs.launchpad.net/mir/+bug/1204939/comments/11
<sil2100> Since we had to block releases of the mir stacks because of that
<racarr> Mirv: I'm glad you expected it ;)
<duflu> sil2100: We were just discussing that in the hangout. People generally agree that we have not yet ruled out some socket needs better flushing, or similar. RAOF was working on it but just went to dinner I think
<duflu> It's just a theory. We're at least getting closer to where the cause might be
<duflu> mlankhorst: I'm getting: bo ffff880082c01000 pinned elsewhere: 0x00000002 vs 0x00000004
<duflu> ... which sounds like my bo is pinned to "TT" when I'm trying to pin it to VRAM. But I don't understand what it really means by "TT"
<mlankhorst> TT is translation table, eg gart :P
<mlankhorst> are you on a 3.11 kernel?
<duflu> mlankhorst: Oh. No this is 3.8 (raring)
<duflu> mlankhorst: RAOF said it sounded like something you fixed recently... ?
<duflu> Though I am definitely open to blaming my own code still
 * duflu grabs a newer kernel
<duflu> tvoss: I didn't actually mean it when I said I was going to sleep. That's many hours away :)
<mlankhorst> a framebuffer will be in VRAM, exporting a handle as dma-buf will pin it to GART
<duflu> tvoss_^
<mlankhorst> on older kernels, 3.11 fixed this
<duflu> mlankhorst: Cool thanks. I will give 3.11 a spin
<sil2100> duflu: thanks guys :)
<duflu> brb
<duflu> alan_g: How confident are you that none of our sockets will ever need more flushing than we do already? It sounds like sil2100's issues could be caused by a socket buffering a request or response, but never accumulating enough to flush...
<alan_g> duflu: it isn't something I've thought about.
<duflu> Fair enough. So it's not impossible I guess
<alf__> duflu: alan_g: It's unlikely that socket buffering would actually cause data not to be sent at all. In the worst case it would introduce a small delay while waiting for other data to come along.
<duflu> alf__: Worth thinking about for performance at least I guess
<duflu> ping greyback
<greyback> duflu: pong
<duflu> greyback: Can you confirm the fix for bug 1199450?
<ubot5> bug 1199450 in Mir "[xmir] Inputs slowing, last event of a stream of events greatly delayed" [Critical,Fix released] https://launchpad.net/bugs/1199450
<greyback> duflu: can do. Let me reboot
<duflu> Ta
 * duflu has managed to simulate the bug with demo_client_fingerpaint but never see it in the wild
<duflu> greyback: Any good news before I depart?
<greyback> duflu: so far, inputs are immediate, so I think bug is fixed. As it used to take several hours for bug to be noticeable, I'll work the day before marking bug as fixed
<duflu> greyback: OK, thanks for testing that
<greyback> duflu: thanks for fixing :)
<duflu> greyback: No problem. It was consequential to other work I was already doing. BTW using Intel GPUs?
<greyback> duflu: yep, sandybridge
<duflu> Cool
<duflu> mlankhorst: nouveau seems to be (successfully) doing multiple page flips per vblank...
<duflu> Or am I imagining things?
<mlankhorst> unfortunately not..
<mlankhorst> I have 2 patches that help with the vblanking some
<mlankhorst> sec
<mlankhorst> http://cgit.freedesktop.org/~mlankhorst/linux/commit/?id=4d2b97bdaebd7686075bce5ad1a498918d2ab17f^
<mlankhorst> http://cgit.freedesktop.org/~mlankhorst/linux/commit/?id=4d2b97bdaebd7686075bce5ad1a498918d2ab17f
<duflu> mlankhorst, OK awesome to see you're already onto it
<duflu> I may have to enter kernel land and test those tomorrow...
<mlankhorst> duflu: well the fix is really from the second commit in nouveau_display.c -- you should try that separately :P
<mlankhorst> but I'm still getting > 60 fps with compositing somehow, dno why
<mlankhorst> ah now I understand
<mlankhorst> nouveau ddx is messy :/
<alan_g> Hmm with the new fangled mir_connection_create_display_config() interface, how do we determine the size of the display? Is MirDisplayMode::vertical_resolution the height?
<olli_> didrocks, I checked with RAOF yday on the ATI bug
<olli_> discussing whether the stop is warranted or not
<didrocks> olli_: ah nice! we discussed a little bit/tried to debug together this morning
<didrocks> (no success though)
<olli_> he said we should block mostly to "help" you
<olli_> i.e. it is probably not an ATI spec. problem but a sporadic IPC one but if we don't get it fixed you will just reboot your system over and over again
<olli_> didrocks, just wanted to share that with you
<olli_> to show some sympathy ;)
<didrocks> olli_: yeah, or have to skip this tests on that machine and add an hack for this oneâ¦
<didrocks> olli_: thanks ;) let's see how it goes on a longer term
<tsdgeos> racarr: ping when you're online
<tvoss_> didrocks, what is wrong with this line in debian/control?
<tvoss_>  -- Thomas Voss (thomas.voss@canonical.com) Mon, 12 Aug 2013 15:51:35
<didrocks> tvoss_: you shouldn't have this line in debian/control
<didrocks> or you meant debian/changelog?
<tvoss_> didrocks, changelog, sorry :)
<tvoss_> ah, spotted it :)
<didrocks> tvoss_: you need a double space and <   > between your email address
<didrocks> so:
<didrocks>  -- Thomas Voss <thomas.voss@canonical.com>  Mon, 12 Aug 2013 15:51:35
<didrocks> not sure what you try to do to have () and only one space ;)
<tvoss_> didrocks, still no luck
<tvoss_>  -- Thomas Voss <thomas.voss@canonical.com>  Mon, 12 Aug 2013 15:51:35
<didrocks> tvoss_: you don't have the timezone
<didrocks>  -- Thomas Voss <thomas.voss@canonical.com>  Mon, 12 Aug 2013 15:51:35 +0200
<didrocks> not sure why you try by hand instead of dch -i, really ;)
<bschaefer> small branch, memory leak in multi win demo: https://code.launchpad.net/~brandontschaefer/mir/fix-memory-leak-mutli-win-example/+merge/180210
<bschaefer> and small memory leak, just 3 surfaces ~4k bytes
<racarr> These lateoclock meetings just do not ork ell for me
<racarr> I got so woken up I couldnt get to sleep until 4
<tsdgeos> racarr: there?
<racarr> tsdgeos: Yes :) sorry
<tsdgeos> racarr: did you get the nexus4 mir thing to work?
<racarr> I went to our lateoclock meeting last night...and wasn't able to get to sleep afterwards
<racarr> Yes! but then I realized I was testing unity8 with old packages still because path wasn't thought I was
<racarr> and the PPA isn't installable at the moment
<racarr> so now I am building qtubuntu, etc
<racarr> just mir trunk, all the demos, etc
<racarr> so I guess, I will hopefully see the problem soon at least
<tsdgeos> racarr: well, my problem is, i can't even get anything on screen with mir_demo_client_accelerated
<tsdgeos> racarr: is all the stuff you use from packages? or you use some code yet to be commited?
<racarr> tsdgeos: Ah see, I just did a clean build
<racarr> of mir trunk and the demo clients work fine
<racarr> I think I didn't try demo_client_accelerated in particular, but did try demo_render_surfaces, demo_render_to_fb, demo_fingerpaint, and demo_inprocess_egl
<tsdgeos> well i'm using the image
<racarr> hmm
<tsdgeos> any idea why i may not be getting anything?
<racarr> tsdgeos: We are sure surface flinger is dead?
<tsdgeos> racarr: well, it's not showing in ps, is that enough?
<racarr> I think actually it might not show up in normal PS anyway because it's on the other side of the LXC container
<racarr> but I'm not 100% sure
<racarr> with no surface flinger
<racarr> nexus 4 should get stuck on the
<racarr> "Google" screen
<racarr> probably
<racarr> tsdgeos: There may be something useful if you run the server with
<racarr> MIR_SERVER_DISPLAY_REPORT=log
<tsdgeos> yes, it gets stuck on the google screen
<racarr> did you try the standalone mir demos?
<racarr> render_surfaces, render_to_fb and inprocess_egl?
<tsdgeos> racarr: which binary is that?
<tsdgeos> is that in any deb pkg?
<tsdgeos> or do i have to compile mir?
<racarr> tsdgeos: sorry I keep on thinking you have a build directory XD
<racarr> um
<racarr> I think they were in the demos packagge at least
<racarr> mir_demo_standalone_*
<tsdgeos> racarr: shall i run as root, as phablet or don't care?
<racarr> inprocess_egl, render_surfaces, render_to_fb
<racarr> um, you know I had success running them as phablet but I didn't think that was supposed to work
<racarr> so lets go with root XD
<racarr> and MIR_SERVER_DISPLAY_REPORT=log if they don't work
<ricmm> racarr: you get the shell on your n4 ?
<tsdgeos> racarr: so this is the server output http://paste.ubuntu.com/5986351/
<tsdgeos> and this is the client
<tsdgeos> http://paste.ubuntu.com/5986353/
<tsdgeos> still nothing on screen
<racarr> tsdgeos: When you run the standalone ones
<racarr> run without a server
<racarr> ricmm: I was running old packages XD
<tsdgeos> racarr: the only standalone i can find is mir_demo_standalone_input_filter
<racarr> Really ok I guess we don't build them anymore
<tsdgeos> and well, that does output stuff to the shell
<tsdgeos> but i don't see anything
<tsdgeos> not sure if i should be seeing anything or not
<ricmm> racarr: so now it doesnt work?
<racarr> not with input_filter
<tsdgeos> racarr: i guess i can try building stuff if that helps
<racarr> ricmm: Well I am still building to verify, it seems not too though
<racarr> tsdgeos: Yes, I think that ould be the next step if you can
<racarr> just start with building mir
<racarr> and we can run the integration-tests binary
<racarr> which will verify a lot of
<racarr> driver stuff
<tsdgeos> but i'm confused as of why you see stuff when using the image and you don't
<racarr> and narrow things down
<racarr> tsdgeos: No I am using the normal image and built mir atm
<tsdgeos> oh
<racarr> I switched back to the normal image because I thought maybe I would dogfood it sometimes on days when I dont need google maps
<racarr> but it turns out I use google maps pretty much every day lol
<racarr> I guess probably I should try the image..
<racarr> ill download the image while you build mir XD
<racarr> tsdgeos: ricmm: Is this still the link http://s-jenkins:8080/job/ubuntu-touch-phablet-image-saucy-mir/lastSuccessfulBuild/artifact/saucy-preinstalled-phablet-armhf.zip
<tsdgeos> racarr: im just using the regular image
<tsdgeos> + the mir ppa
<racarr> its not working
<racarr> tsdgeos: oh ok
<racarr> so we should be in roughly the same spot
<racarr> so lets see what happens withhhh the integration-tests binary
<tsdgeos> racarr: which cmake switch do i need to compile mir?
<ricmm> racarr: yea thats the link
<ricmm> havent checked today's image, but it should be fine
<ricmm> lately if it builds it works
<ricmm> so yea
<racarr> tsdgeos: -DMIR_PLATFORM=android
<tsdgeos> racarr: ok, build, what now?
<racarr> tsdgeos: Try running the binaries in build/bin lets start with
<racarr> unit-tests, integration-tests and acceptance-tests
<tsdgeos> ./bin/mir_demo_standalone_render_sur
<tsdgeos> nothing on screen
<tsdgeos> running unit-tests now
<tsdgeos> everything passes
<tsdgeos> +
<tsdgeos>   YOU HAVE 2 DISABLED TESTS
<tsdgeos> everything passes
<tsdgeos> racarr: what now?
<bschaefer> racarr, hey, you were looking at a crash in: usr/lib/xorg/modules/extensions/libxmir.so (xmir_auth_drm_magic+0x3f) [0xb752560f]
 * bschaefer seems to be getting a black screen on start up, and attempting to load unity7 causes opengl to crash when attempting to load
<bschaefer> usr/lib/xorg/modules/extensions/libxmir.so (xmir_auth_drm_magic+0x3f) [0xb752560f]
<bschaefer> opps
<bschaefer> paste.ubuntu.com/5986691/
<racarr> tsdgeos: Mer. I guess try
<racarr> the standalone programs that I mentioned
<racarr> well also try running mir_demo_server_shell and a client with mir built this way
<racarr> bschaefer: I was, but I didn't get so far
<racarr> the last theory as of liek 2 am last night as that maybe the second auth magic request
<racarr> isnt being sent to the server in time because of socket buffering
<bschaefer> racarr, o well nevermind then :), I think i've an incorrect package somewhere...as everyone else seems to have a working intel machine on main
<bschaefer> racarr, as I thought it was an ATI problem
<racarr> we think that may ust be
<racarr> coincidence
<racarr>  / most likeley to aggrivate the race
<bschaefer> that could be as well, hmm yeah as right now I just get a black screen right after logging into lightdm, but Ill mess around some more
<racarr> but
<racarr> yeah see if it could be wrong packages
<racarr> and if not, I think I can help figure out if it's
<racarr> the same bug
<racarr> which would be useful
<bschaefer> and I can do a "startx" to get into an xsession, but when I attempt to start unity it hangs on loading the opengl driver
<bschaefer> alright will do!
<bschaefer> racarr, o also one more interesting thing, is as soon as I switch to a tty I get this message and my xsession dies (but no errors):
<bschaefer>  (II) AIGLX: Suspending AIGLX clients for VT switch
<tsdgeos> racarr: none of the standalone stuff does much, they just turn the screen "less black" and that's it :-/
<racarr> tsdgeos: Hmm, and anything novel with MIR_SERVER_DISPLAY_REPORT=log on the standalone stuff?
<racarr> They should be rendering things
<racarr> tsdgeos: Can we double check that surface flinger is disabled like it documents at the bottom of the page here: https://wiki.ubuntu.com/Touch/Testing/Mir
<tsdgeos> racarr: nothing :-/ http://paste.ubuntu.com/5986754/
 * tsdgeos checks the surface flinger
<tsdgeos> racarr: so basically
<tsdgeos> cp /var/lib/lxc/android/rootfs/init.rc /var/lib/lxc/android/overrides/
<tsdgeos> vi /var/lib/lxc/android/overrides/init.rc
<tsdgeos> # Comment out any line that deals with surfaceflinger (near the bottom there is a chunk of them)
<tsdgeos> ?
<tsdgeos> yeah
<tsdgeos> nothing
<racarr> bler
<racarr> ok maybe I should riemage my phone
<racarr> tsdgeos: I am kind of at a loss to try and determine what oculd be different
<tsdgeos> :(
<tsdgeos> racarr: i'd appreciate if you tried a reimage, but i agree that's a lot of time
<tsdgeos> anyway
<tsdgeos> it's almost 1am here
<tsdgeos> and tomorrow is a national holiday
<tsdgeos> i'm going to log off
<bschaefer> racarr, after purging libelg* and reinstalling xserver-xorg-video-intel and libmirserver1...things seem to be working again
<tsdgeos> maybe on friday things will be automagically better
 * tsdgeos hopes
 * tsdgeos waves
<bschaefer> libegl*
<racarr> bschaefer: Yay
<racarr> so probably
<racarr> unrelated
<bschaefer> yup, still strange though...if it comes back ill let someone know :)
<racarr> thanks.
<RAOF> racarr: :( Sorry for keeping you up.
<RAOF> bschaefer: Your OpenGL app hangs? On hardware that isn't in the QA lab? SCORE!
<bschaefer> RAOF, no anymore :(
<bschaefer> RAOF, just purged libegl* and reinstalled what was needed and things seem to be working again
<bschaefer> not anymore*
<RAOF> Eh, it's a race.
<RAOF> Of some kind.
<RAOF> You'll be back!
<bschaefer> RAOF, haha, well thats good news!
<bschaefer> my logs were clean until I tried to force start unity, and when compiz was loading the opengl plugin everything hung and I got that stack trace, but it didn't say
<bschaefer> the xserver went down with an error, or at all, the log just ends...
<thomi> RAOF: any news on the Xorg fix?
<RAOF> thomi: Which one?
<RAOF> The nexuiz one?
<thomi> the nexiuz one
<thomi> yeah
<thomi> I saw some activity on the bug
<thomi> but I'mnot sure how far away we are from having a new package in distro
<RAOF> Should be fixed in distro at the moment, I think, but I should also wrap up Chris' newer patch.
<thomi> oh sweet, thanks
#ubuntu-mir 2013-08-15
<duflu> Ug. nouveau killed my system
<RAOF> Dead as a doornail?
<duflu> Back now
<duflu> If only I could remember SysRq combos
<RAOF> REISUB
<RAOF> Although we've actually disabled all but SUB from that.
<RAOF> olli: Good morning/evening.
<olli> hey RAOF
<olli> evening
<RAOF> Various tarballs are sauntering up to U1.
<olli> RAOF, awesome!
<olli> thx
<RAOF> Taking a relaxed stroll through my ADSL pipe.
<olli> :)
<olli> do you need me to upload something?
<olli> it seems like there is enough time until the meeting
 * olli counts hours until 5am
<RAOF> About 12 :)
<olli> 12?
<olli> I count 9
<RAOF> Hm. 10?
<olli> 9h 12min
<olli> 7:48pm here
<olli> meeting in my cal from 5-6am
<RAOF> Meeting is 10pm my local time, and it's 11 minutes to 12 here.
 * RAOF checks calendar.
<olli> hm
<RAOF> Ah.
<olli> I never get these TZs right
<RAOF> No, it's 9pm my local time :)
<olli> :)
<RAOF> Anyway, the upload is about half done; it'll be done in plenty of time for 9pm :)
<olli> RAOF, when you send the mail, mind suggesting an IRC channel (ask if that works... it's china...)
<olli> and if it doesn't we can try something like gg doc
<RAOF> On freenode?
<olli> to just share stuff, links to files in the local fs, etc
<olli> RAOF, yeah
<olli> we could probably just use this one here actually
<olli> or a randomly picked, sort of private one
<duflu> RAOF: Have you ever observed anything like bug 1211700? It's almost as it nouveau+radeon have excessive locking which makes GL command floods from busy clients block page flipping also
<ubot5> bug 1211700 in Mir "Unthrottled EGL clients cause Mir to slow, sometimes to a halt" [Undecided,New] https://launchpad.net/bugs/1211700
<duflu> *as if
<RAOF> I've not seen that
<duflu> It feels familiar. I think I came up against similar in Compiz
<RAOF> Well, there's currently no scheduling at the GPU level, so clients are perfectly capable of flooding.
<duflu> Ah, bug 1007299 was similar but that was mitigated with more sane XDamage logic
<ubot5> bug 1007299 in Compiz "Compiz frame rate decreases if application frame rates are too high (unthrottled)" [High,Fix released] https://launchpad.net/bugs/1007299
<olli> RAOF, I have asked tvoss_ to reply to tim's mail, we do have some canned answer
<RAOF> olli: About IRC, or the general "what's happening 14.04+"?
<RAOF> Or, I guess, both? :)
<olli> the latter
<olli> RAOF, the Mesa U1 link doesn't work for me
<RAOF> Grr. Let me check.
<RAOF> Oh, man. The fact that the mesa link randomly ends in âXserverâ is confusing :)
<olli> heh
<RAOF> olli: Check the new link?
<olli> RAOF, wfm, thx
<duflu> RAOF: Does this look related to the auth_magic issues?...
<duflu> [ FAILED ] BespokeDisplayServerTestFixture.client_drm_auth_magic_calls_platform (1922 ms)
<duflu> See bug 1212516
<ubot5> bug 1212516 in Mir "integration-tests: BespokeDisplayServerTestFixture failing under valgrind" [Undecided,New] https://launchpad.net/bugs/1212516
<RAOF> duflu: Plausibly?
 * RAOF checks the bug.
<RAOF> It's not clear to me if it's related or not.
<duflu> It sounds very close to the symptoms being discussed yesterday
<duflu> Wow, building a kernel is much slower than it used to be.
<jono> RAOF, do you know what the status is on the ATI blocker that is blocking Mir from updating in the archive?
<RAOF> jono: It's being frustrating and awkward.
<jono> RAOF, I can imagine
<jono> still blocked I presume
<RAOF> But it's not actually an ATI blocker; it's an IPC problem that only appears on that machine for some reason.
<jono> ahhh
<jono> RAOF, do you think we should hold off the call for testing for the packages in the archive until this is fixed?
<RAOF> Maybe? It's a race condition that seems to be pretty hard to hit, though.
<jono> I see
<duflu> jono: https://bugs.launchpad.net/mir/+bug/1204939/comments/13
<ubot5> Launchpad bug 1204939 in Mir "Unity doesn't start on ATI test machine (Mir fails to respond to drm_auth_magic request)" [Critical,Triaged]
<jono> thanks duflu
<tvoss_> good morning :)
<duflu> tvoss_, hi
<tvoss_> duflu, hey there, how is it going? kernel build done?
<duflu> tvoss_: Yes done now. I shall have to reboot and break/fix things soon
<tvoss_> duflu, :)
<jono> hey tvoss_
<tvoss_> jono, hey there :)
<tvoss_> jono, you are supposed to be offline, aren't oyu?
<jono> tvoss_, technically
<jono> :-)
<jono> back tomorrow for a day and then off on Fri
<RAOF> tvoss_: Huh. That document you linked points to a private launchpad branch :)
<tvoss_> RAOF, oops :)
<tvoss_> RAOF, let's see if they try to open the link then ;)
<duflu>   /reboot
<tvoss_> duflu, welcome back :)
 * duflu is experimenting with mlankhorst's vblank proposals, so things are a bit jerky
<duflu> I take it back. Not jerky, but perfect 60Hz in Mir. Only X is broken :)
 * tvoss_ moves over to the new house
<duflu> Too many houses to choose from?...
<duflu>  /swap hardware
<mlankhorst> :p
<RAOF> mlankhorst: Probably time for me to chase up that dma-buf patch again. Have there still not been any replies, or am I just not subscribed to the right list and people aren't CCing me?
<RAOF> Man our tests take a long time to run under valgrind!
<duflu> Weird how nouveau renders the Mir hardware cursor visibly differently to intel/radeon
<duflu> RAOF: *-tests --gtest_filter="*the_test_you_want*"
<RAOF> duflu: Yeah, fair call.
 * duflu Ctrl+Alt+De
<mlankhorst> RAOF: poke sumits on irc, but yeah I haven't had any feedback on my fence patch either
<RAOF> sumits-away it is!
<duflu> mlankhorst: Your vblank patches work brilliantly for Mir. Strangely stuck at 30-45Hz in X though.
<duflu> Maybe Compiz is just trying to do *too much* every frame
<mlankhorst> duflu: I still get > 100 fps every time, I guess double vblank somewhere
<duflu> mlankhorst: Well, Mir had a nice healthy 60Hz with the patches
<duflu> And buttery smooth
<dholbach> good morning
<duflu> Morning dholbach
<dholbach> hi duflu
<mlankhorst> duflu: my gtx 480 can drive 2 panels at 2560x1440 without problem on bootspeed
<duflu> mlankhorst: Admittedly I have only tested a G210 so far
<mlankhorst> it's stuck on 135 mhz memory clock
<mlankhorst> your clock is more than that
<duflu> mlankhorst: How to force it higher?
<mlankhorst> so trust me if it's stuck on 30 fps
<mlankhorst> it's because of a double vblank path
<mlankhorst> the only times boot speeds have given me issues have been when I was running real 3d applications, not the compositing manager :P
<mlankhorst> oh and 1080p video decoding won't work on boot speeds ;P
<mlankhorst> duflu: sec if you want to recompile the ddx you can probably kill off a vblank
<duflu> mlankhorst: I think I've already spent enough time recompiling kernels. It's not my priority task right now...
<mlankhorst> http://paste.debian.net/25338/
<mlankhorst> ddx patch
<mlankhorst> no idea if it helps though
<mlankhorst> but it kills an extra wait
<alan_g> duflu: have you had time to investigate bug 1212518?
<ubot5> bug 1212518 in Mir "valgrind acceptance-tests: [ FAILED ] TestClientInput.hidden_clients_do_not_receive_pointer_events" [High,Confirmed] https://launchpad.net/bugs/1212518
<duflu> alan_g: No, I am still focusing on bypass. Just logging other bugs as I notice them
 * alan_g knows how that is
<duflu> Dear radeon: Give me an error, or display my buffer. Doing neither is not very friendly.
<alf__> duflu: is this with the dmabuf fix applied?
<duflu> alf__: I have no idea what you mean. But I have tested up to kernel 3.10.6 and get the same bug
<duflu> alf__: What is it? What does it do?
<alf__> duflu: dmabuf fix = fix for not pinning video buffers to system memory that mlankhorst was working on
<alf__> mlankhorst: does 3.10.6 contain the dmabuf pinning fixes?
<duflu> alf__: Yeah mean for nouveau? Yes tested that and it works. But no luck with radeon... though I can't test kernel 3.11 with radeon due to other errors
<mlankhorst> alf__: 3.11 does, which is in the archive
<mlankhorst> I don't think it qualifies for stable, but it can be backported if you care
<duflu> alf__: Yeah I ran into that on nouveau and confirmed 3.11 works. You mean a similar fix is required for radeon?
<alf__> duflu: yes, it's a dmabuf issue affecting both nouveau and radeon
<duflu> alf__: OK. I just gave up trying 3.11 on radeon due to strange errors. I'll have to go back to it
<alf__> duflu: what problems do you get with 3.11?
<duflu> alf__: I saw odd Mesa/kernel errors and then full system hang. But that was raring + 3.11 kernel. I will try saucy daily image now...
<duflu> It's difficult when I can't upgrade this machine to saucy yet, and it's the only one I can put video cards in
<alf__> duflu: why can't you upgrade?
<duflu> alf__: It's my "stable" server/desktop
<alf__> duflu: perhaps have an partition for unstable installations?
<duflu> alf__: Perhaps. But that's a last resort
<alf__> duflu: btw, I have a radeon, so if you want me to try something with saucy + 3.11 I would be happy to
<duflu> alf__: If I need help, I'll let you know thanks. I'll live-boot saucy for the rest of the day...
<alf__> duflu: ok
<duflu> Wow, kernel 3.10.6 is either impressive or a little broken for me...
<duflu> 909115392 bytes (909 MB) copied, 1.3706 s, 663 MB/s
<duflu> (that's to an old USB stick)
 * duflu goes offline testing hardware and kernels for a while
<mlankhorst> oh btw about radeon...
<mlankhorst> https://bugzilla.kernel.org/show_bug.cgi?id=60674
<ubot5> bugzilla.kernel.org bug 60674 in Video(DRI - non Intel) "linux 3.10.x RV740 (Radeon HD 4770) display problem" [Blocking,New]
 * smartboyhw doesn't understand why duflu is using a 3.10.6 kernel
<smartboyhw> 3.10.7 just released...
<mlankhorst> ugh
<duflu> alf__, the latest saucy live images seem to refuse to boot... something I noticed on another machine last night. And I can't go back to alpha-2 (only available for non-Unity flavors) because that's too old to have the right kernel. So if you could do some manual radeon testing, please do... lp:~vanvugt/mir/bypass
<alf__> duflu: ok, so anything in particular I should try out?
<duflu> alf__: Any fullscreen hardware surface (eglplasma or egltriangle -f)
<alf__> duflu: ok
<duflu> alf__, thanks. I will continue trying to find a newish saucy iso that works
<duflu> And with that, I should organize dinner
<RAOF> olli: Good morning
<katie> hi tvoss_
<tvoss_> katie, hey, I have been double booked :/ cannot miss the other meeting unfortunately
<katie> tvoss_, ok, can we re-schedule
<katie> ?
<tvoss_> katie, for sure, today?
<RAOF> jammy: Hello
<katie> tvoss_, i can do half an hour from now, or else tomorrow is better for me
<jammy> raof: hello
<tvoss_> jammy, hey
<tvoss_> katie, tomorrow then
<katie> ok, i'll put something in the calendar :)
<jammy> tvoss_: hi, nice to talk to your guys again :)
<tvoss_> apt-cache policy unity-system-compositor
<tvoss_> unity-system-compositor:
<tvoss_>   Installed: 0.0.1+13.10.20130813.1-0ubuntu1
<tvoss_>   Candidate: 0.0.1+13.10.20130813.1-0ubuntu1
<tvoss_>   Version table:
<tvoss_>  *** 0.0.1+13.10.20130813.1-0ubuntu1 0
<tvoss_>         500 http://de.archive.ubuntu.com/ubuntu/ saucy/universe amd64 Packages
<tvoss_>         100 /var/lib/dpkg/status
<tvoss_> tvoss@x220:~/.phoronix-test-suite/test-results$ apt-cache policy libmirserver1
<tvoss_> libmirserver1:
<tvoss_>   Installed: 0.0.9+13.10.20130813-0ubuntu1
<tvoss_>   Candidate: 0.0.9+13.10.20130813-0ubuntu1
<tvoss_>   Version table:
<tvoss_>      0.0.9+13.10.20130813-0ubuntu1 0
<tvoss_>         500 http://de.archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages
<tvoss_>  *** 0.0.9+13.10.20130813-0ubuntu1 0
<tvoss_>         100 /var/lib/dpkg/status
<mterry> racarr, heyo!  Got a sec to talk about mir sessions in u-s-c?  I'm testing on my nexus4 and the_shell_session_container() seems empty (yet mir/lightdm/u-s-c seem to be up and I see things on the screen).  What populates that list?  (seems to be sessionmediator in mir, but not sure what calls its connect() method)
<alan_g> BRB - I've broken VT switching, need to restart some stuff
<racarr> mterry: the protobuf_message_processor
<racarr> but if things are working the session container is almost certainly being filled
<racarr> you could check for open session, etc, well "connct" with
<racarr> MIR_SERVER_SESSION_MEDIATOR_REPORT=log
<racarr> perhaps, you are getting the_shell_session_container in a weird way
<racarr> i.e. if you just store the CAchedPtr return value
<racarr> err
<racarr> well, you need to hold
<racarr> a strong reference to it
<racarr> or you might end up with two
<mterry> I got disconnected, resending in case I was already timed out...
<mterry> <mterry> racarr, sorry, was away for lunch
<mterry> <mterry> racarr, it seems that it's filled from platform-api.  So apps themselves might fill it...  but I think the shell/greeter aren't.   Not sure if they should or even if I'm reading the situation right
<racarr> mterry: Ah ok
<racarr> it's filled from the RPC layer as basically
<racarr> the session is like connection or something
<racarr> there is no session for shell/greeter surfaces.
<racarr> i.e. inprocess
<mterry> racarr, but don't they act as a client for the u-s-c?  I'd think they'd call mir_connect to connect to the system mir
<racarr> no, so
<racarr> we don't have nested mir at the moment, but lets say we did and then
<racarr> there is USC, which iwll jjust hve one session
<racarr> "session mir"
<racarr> and the session mir has application sessions, and shell surfaces, etc.
<racarr> in the session mir
<racarr> the shell surfaces, are all inprocess clients
<racarr> so there is no mir_connect, and no session
<racarr> there could be a session of some sort invented I guess. haven't come up with a usecase/sensible way to do it so far
<mterry> racarr, shell surfaces are inprocess clients to what?  To their own mir servers?  But aren't they also clients to the u-s-c?  So they'd do a mir_connect to it, I would have thought.  I guess I'm missing how u-s-c views the shell surface, if it doesn't think of them as a client session...
<racarr> mterry: u-s-c never sees shell surfaces
<racarr> u-s-c just sees
<racarr> greeter, maybe bootsplash and stuff like that, and one surface
<racarr> for each user session
<mterry> racarr, ok, sorry.  I guess when I said 'shell surface' I meant user session surface
<racarr> oh ok like the whole
<racarr> session
<racarr> that
<mterry> racarr, so greeter/user should be registered as sessions in u-s-c, right?
<racarr> should be in the_session_container yeah
<racarr> but, we don't have nested mir at the moment so you couldn't actually do that right?
<mterry> OK, I'm not seeing that now.  So somewhere that's being messed up (and may be my own patches...)
<mterry> racarr, we don't have nested mir?
<mterry> racarr, how is u-s-c supposed to work then?
<mterry> just xmir?
<racarr> yep just xmir
<racarr> nested mir is still in progress
<racarr> some parts of it started to land
<mterry> racarr, ok.  So maybe I'm still getting ahead of myself.  :(   /me is eager to try to test whole system integration with a split greeter on phone
<racarr> :(
<racarr> you could use little Qt apps that display a picture as fake session clients of u-s-c
<racarr> to get things going
<racarr> it just wont be as satisfying lol
<mterry> racarr, well, I'm actually able to get the greeter and shell to be run by lightdm
<mterry> racarr, but they don't seem to talk to u-s-c at all, and I can't switch between them
<racarr> I don't know what exactly is going on byt my guess is its just
<racarr> two entirey seperate mir servers
<mterry> hrm
<thomi> morning
<bschaefer> hmm there seems to be a recent memory leak in: mir_connection_create_display_config
<bschaefer> http://paste.ubuntu.com/5990319/
<bschaefer> as the eglapp is calling the correct destroy function as well...so it appears to be mir hanging on to something?
<bschaefer> found the leak :)
<bschaefer> when anyone has time: https://code.launchpad.net/~brandontschaefer/mir/clean-up-config-cards/+merge/180413
<arsson> unity8
<jono> olli, which BP tracks the composite bypass work?
<jono> tvoss_, olli, http://www.jonobacon.org/2013/08/15/mir-update-and-testing-mir-in-ubuntu-13-10/
<tvoss_> jono, thx
<jono> https://wiki.ubuntu.com/Mir/GPUTesting is growing :-)
<racarr> oh wow!
<arsson> you could add geforce gt420 to failure for now
<arsson> but when using propreitary graphics driver it fell back to X
#ubuntu-mir 2013-08-16
<RAOF> Man, our session mediator is the cacheline killer.
<RAOF> It appears to service each request on a different CPU.
<racarr> RAOF: We are threading geniuses
<RAOF> We should probably cut back on that :)
<RAOF> But what are we threading geniuses *through*?
<RAOF> The eye of a needle?
<RAOF> The eye of a camel?
<RAOF> Inquiring minds want to know!
<racarr> haha
<RAOF> I'm pretty sure we could trim a fair bit of fat from our RPC code.
<RAOF> Wait. Are we sure we're reading from the socket in order? I seem to get multiple request messages interleaved.
<duflu> RAOF: Surely that's something protobuf deals with?
<RAOF> No, protobuf is purely encoding.
<RAOF> It doesn't have anything to do with actually shipping the encoded bytes anywhere; that's all us.
<duflu> RAOF: I do recall coming across documentation which said protobuf waits for all the bytes to reform a message. You can't just peak at headers etc
<RAOF> We *do* peek at the headers :)
<RAOF> Or, rather, we encode the size of the message as a header and then send that + the message.
<duflu> RAOF: That's odd, because when I wanted to "peek" I found protobuf disallowed it
<RAOF> Oh, I don't think you can peek at a bit of a protobuf message.
<RAOF> But we wrap the protobuf message in a tiny extra protocol (ie: two byte msg size, followed by protobuf msg)
<duflu> RAOF: Yes, both statements are true. Different layers
<RAOF> Incidentally, the drm auth message is surprisingly big; it's 19 bytes.
<RAOF> Sorry, 26 bytes.
<RAOF> Presumably we're actually sending the string "drm_auth_magic" over the wire.
<RAOF> Which seems totally unnecessary, but whatever.
<duflu> RAOF: Yeah I had two branches that removed that. One I think got proposed, and rejected. At least I could never measure any performance benefit in removing it
<RAOF> Yeah, it's not going to be a big performance problem.
<RAOF> It's just something we could trivially not do.
<duflu> RAOF: Actually, I think it was something like 1% CPU of something
<RAOF> We additionally copy all the messages at least once more than I think is necessary.
<duflu> RAOF: How performant are local sockets known to be?
<RAOF> (We copy from the message into a buffer, then write that buffer to the socket)
<RAOF> local sockets should be pretty good; to get better we'd need to do shared memory, I believe.
<RAOF> Urgh. Couldn't we just appropriate Wayland's IPC mechanism? That's really nice âº
<RAOF> Bah. For all that we use threads, mirclient is pretty terribly unthreadsafe.
<duflu> RAOF: Does wayland use sockets?
<RAOF> Yes
<RAOF> In fact, I *think* it's unsafe to call any function from mirclient in more than one thread.
<RAOF> (Because anything that writes to the mir socket does so in a thread unsafe way, so you can't call anything that could send a message from more than one thread at once)
<duflu> RAOF: I'm fairly confident the thread safety aspects of libmirclient are now solved (recently in r827). Except bug 1194384 remains
<ubot5> bug 1194384 in Mir "Mir client callbacks are not thread-safe" [Medium,Triaged] https://launchpad.net/bugs/1194384
<RAOF> Ah, yes. We've got a big-old mutex around every call in MirConnection.
<RAOF> Oh, no. Not around configure_display
<duflu> RAOF: Heh, well it was right at the time. I can't check everyone's changes since all the time
<duflu> RAOF: In other news, alf tells me that my bypass+radeon problems were just the old kernel I have here. It works in saucy, which means saucy can bypass intel+nouveau+radeon. I will do final testing before EOD
<RAOF> Woot!
<duflu> Might have to add a kernel version check :/
<duflu> Because slightly slower is better than corruption or crashes
<duflu> And spurious bug reports
<olli_> morning RAOF
<RAOF> olli_: Good morning
<olli_> thx for doing the call last night
<olli_> was well perceived :)
<olli_> do you have any good update on bug 1204939
<RAOF> Ah, good.
<ubot5> bug 1204939 in Mir "Unity doesn't start on ATI test machine (Mir fails to respond to drm_auth_magic request)" [Critical,Triaged] https://launchpad.net/bugs/1204939
<RAOF> No.
<RAOF> I have a variety of things that it's *not*, and *maybe* it's a threadsafety issue in our IPC code.
<RAOF> But I'll hopefully get another debug dump from a jenkins run later today when Didier's up, and then I'll hand off to alan_g
<duflu> olli_, I am putting bypass on pause for the day and looking into the possibly-related bug too
<olli_> RAOF, do we have any other way to reproduce?
<olli_> w/o didrocks
<olli_> duflu, thx, I saw the note in the bug
<olli_> I'd really like to get this unblocked prior to the weekend (which is in a few hours for you lucky guys ;)
<RAOF> olli_: As far as I can tell, the Jenkins ati box is the only one that reproduces.
<olli_> RAOF, sure, but you suggest you need didrocks to access it
 * duflu wonders if headlessness helps
<RAOF> olli_: Ah, I see what you mean.
<RAOF> Didier has done all the jenkins futzing for all of my previous debugging romps. I'm not sure what actually needs to be done to put the machine in the necessary state.
<olli_> RAOF, yeah, I don't think this is anything that would help today to speed things up but maybe somehting to consider for the next bug on his system (i.e. get access)
<olli_> RAOF, he might actually be out
<olli_> he was out for sure on Thu
<olli_> not sure if he is also taking Fri off
<olli_> RAOF, duflu, everybody, mind sending me & didrocks an update via mail before you EOW? we have a few interested parties that are curious if&when we can enable autolanding again
<RAOF> olli_: Sure.
<duflu> Yep
<olli_> thx guys
 * duflu is struggling to reproduce said bug now
<olli_> sounds like a tough nut to crack
<RAOF> duflu: You're trying the valgrind bug?
<RAOF> duflu: Because I think the drm_auth_magic failure in that requires you to run one of the previous, failing tests first.
<duflu> RAOF: I'm doing exactly the same as yesterday, on multiple machines which had the bug yesterday. I shall have to bisect....
<RAOF> Hah! Surprise!
<RAOF> Huh. The apple magic touchpad kernel panics my Galago after a couple of seconds' use.
 * duflu pretends he wasn't the last person to touch that kernel driver
<duflu> Actually, I probably wasn't
<RAOF> Dear OOM killer: where did my 16GB of RAM go? Did you really have to kill Xorg?
<duflu> There's a SysRq combo for that
 * duflu -> lunch
<tvoss_> good morning
<tvoss_> olli_, ping
<olli_> tvoss_, wassup
<RAOF> Mornang all.
<tvoss_> RAOF, hey there :)
<tvoss_> hmmm, I want a Mir logo and have it printed @http://www.unixstickers.com/
<RAOF> Hm. Why is whoopsie cycling between 1GB and 4GB resident size?
<duflu> tvoss_: I want a better Mir logo too. Right now we only have examples/mir_image.h
<tvoss_> duflu, yeah
<duflu> tvoss_, I was thinking about designs just yesterday :)
<tvoss_> duflu, I was thinking if we should name the different threads in Mir to make htop output more readable
<tvoss_> duflu, we could have something similar to the unity logo
<duflu> tvoss_, I hope better than the Unity logo
<duflu> Something the quality of the logo on https://launchpad.net/compiz, but obviously completely different
<RAOF> tvoss_: Oh, yes please! Sensible names for threads!
 * duflu would rather more careful design of threads. But has also suggested some names: https://bugs.launchpad.net/mir/+bug/1194384
<ubot5> Launchpad bug 1194384 in Mir "Mir client callbacks are not thread-safe" [Medium,Triaged]
<tvoss_> duflu, I was more thinking about a pthread_setname_np call
<duflu> tvoss_: Yes should work: pthread_setname_np(t.native_handle(), "foo");
<tvoss_> duflu, I'm a bit worried about _np (not posix)? :)
<duflu> tvoss_: Or more generally explicitly depending on pthread, which we don't thanks to C++11
<duflu> tvoss_: P.S. Lenovo released BIOS 1.39 for X220 with CPU microcode update. I'm not sure, but it feels like power and fan usage is lower
<tvoss_> duflu, woot :) time to get out my bios flash usb stick :)
<smartboyhw> tvoss_, I didn't realize that you guys have a logo:P
<duflu> smartboyhw: Not really. Just the image from mir_demo_{client_accelerated,standalone_render_surfaces}
 * smartboyhw thought you guys can just ask from Canonical Design Team, weird
<tvoss_> smartboyhw, well, yes, but they are quite busy these days :)
<smartboyhw> tvoss_, oh:(
<smartboyhw> BTW, any easy Mir bugs to fix? :P
<tvoss_> smartboyhw, let me have a look
<tvoss_> RAOF, duflu what's the status of https://bugs.launchpad.net/mir/+bug/1102757
<tvoss_> ?
<ubot5> Launchpad bug 1102757 in Mir "System compositor children receive all input events" [High,In progress]
<duflu> tvoss_: No idea. I don't have a dev env for USC. Never needed to yet
<duflu> Maybe I could reproduce it with regular Mir and test Robert's branch...
<RAOF> tvoss_: Blocked on https://code.launchpad.net/~robertcarr/mir/client-focus-notifications
<RAOF> tvoss_: Plus I need to hook up the XMir bit to relinquish input once that's done.
<tvoss_> RAOF, ack
<tvoss_> RAOF, is that the same issues that prints passwords in clear text onto the terminal
<tvoss_> ?
<RAOF> No; *that* issue should be fixed, I think.
<RAOF> This is the issue that mirrors passwords across all the logged-in sessions :)
 * duflu tests
<duflu> tvoss_: I can't reproduce any stray text going to other VTs. At least not any more now I'm updated
<tvoss_> RAOF, ack and thx
<duflu> RAOF, alf__: Anyone know the exact commit of the famous "DMA-buf" fix?
<alf__> duflu: sorry, no
<RAOF> Not me, either.
<alf__> RAOF: Hi! Yesterday I was spiking per-session modesetting, and I found that trying to apply the display config from within the display config change handler in the client caused the client to hang. Is this going to be an issue for the XMir use case?
<RAOF> alf__: No; I have to proxy everything from the handler to the X main loop anyway.
<alf__> RAOF: ok, then we can leave the thread issue for later
<RAOF> Oh, that reminds me.
 * RAOF pushes mutex fix for display config setting
<dholbach> good morning
<RAOF> alf__: The way to actually set a mode is to set the current_mode member of the config struct, right?
<alf__> RAOF: yes
<alf__> RAOF: to the index of the wanted mode in the modes array
<RAOF> Cool, ta.
<RAOF> alf__: Oh, and setting âused = 0â should turn the display off?
<alf__> RAOF: well, not use it, which right now means just leaving there whatever was on screen before, but yes it should ideally turn it off
<RAOF> I ask this merely because the kms way of dealing with this appears to be âset the mode, connecting it to 0 outputsâ.
 * duflu reboots to try for some more hardware testing
<RAOF> Also, I'll want to make DPMS work, too.
<RAOF> Hm. That actually needs a different API though, doesn't it? We don't actually want to unset the mode, we want to turn off the monitor.
<alf__> RAOF: different api from our side?
<RAOF> Yeah, maybe.
<alf__> RAOF: why isn't !used enough?
<RAOF> For XMir I can actually just fake it by not adjusting the root window etc but unsetting the monitor.
<RAOF> alf__: Because we need to be able to distinguish between âturning off a monitor, but keeping it logically presentâ and âturning off a monitor and rearranging the desktop to support the new geometryâ
<RAOF> As I say, I can fake that at the XMir level; maybe we can do the same at the Unity8 level.
<alf__> RAOF: I am not sure I see the problem... Can yous set an output to !used and arrange the others as if the output existed at some point in the virtual space?
<alf__> RAOF: (for the first case you describe)
<RAOF> alf__: Yes, ish - the responses to a client querying the display state should be different, though. In the DPMS case the display is logically enabled (so, for example, it's fine to put windows on it). In the actually-off case the display is gone, and you need to do things like move all the windows that were on it somewhere else, etc.
<RAOF> It basically means I'll be keeping some shadow display configuration in XMir that isn't quite the same as the display configuration that unity-system-compositor has; we'd likewise need to do the same for Unity8
<alf__> RAOF: got it
<RAOF> Bah. Why do we return "" for no error?
<RAOF> Rather than, say, returning NULL. Which is more idiomatic to check for.
<duflu> alf__, It appears I will not be able to test radeon on saucy --> bug 1212977
<ubot5> bug 1212977 in Ubuntu "saucy daily-live images are unbootable on Dell Optiplex 990; stuck in BusyBox shell" [Undecided,New] https://launchpad.net/bugs/1212977
<alf__> duflu: ok, just ping me if you need any radeon tests
<duflu> mlankhorst: Can you think of a nicer way to detect the DMA-buf fix from userland, than comparing kernel versions?
<duflu> RAOF: Can I get driver name from a drm fd?
<duflu> Ah, drmGetVersion perhaps
<RAOF> duflu: Yup. Are you after the kernel driver name or the mesa driver name?
<duflu> RAOF: Either will do I guess
<duflu> Just trying to figure out how/when the DRM version changed
<RAOF> drmVersion will get the kernel name, which is fine.
<RAOF> Won't get you a useful version number, though :)
<duflu> RAOF: Has it changed at all recently?
<RAOF> The version number? I don't think so.
<duflu> I have to run. Sorry to leave you without much progress on the bugs...
<alan_g> alf__: Do you want any more eyes on https://code.launchpad.net/~afrantzis/mir/session-events/+merge/180312? Or shall I top-approve?
<alf__> alan_g: I am OK, feel free to top-approve
<mzanetti> hey, should mir_demo_server and mir_demo_client work on the Nexus 4?
<mzanetti> The screen just stays black here
<alan_g> mzanetti: they were working last time I looked (admittedly not this week). You are starting a mir_demo_client too?
<mzanetti> alan_g: yes
<greyback> alan_g: mzanetti is the second person with this problem. tsdgeos has it too
<alan_g> greyback: mzanetti has a bug been logged?
<tsdgeos> https://bugs.launchpad.net/mir/+bug/1211694
<ubot5> Launchpad bug 1211694 in Mir "Black screen on Nexus4" [Undecided,Confirmed]
 * alan_g hooks up N4 to try it out
<mzanetti> alan_g: thanks :)
<mzanetti> alan_g: I tried the exact same steps on a galaxy nexus. works fine there. so its really something on the Nexus 4.
<mzanetti> alan_g: does it work for you?
<alan_g> mzanetti: had to recharge N4 to use it. Still checking things with the image that's on it before reflashig
<mzanetti> ok
<alan_g> Old and current mir versions works fine on the old image, reflashing...
<alan_g> alf__: Any ideas what might cause this? https://bugs.launchpad.net/mir/+bug/1211694/comments/4
<ubot5> Launchpad bug 1211694 in Mir "Black screen on Nexus4" [Critical,Confirmed]
<alf__> alan_g: no, but I can pick up the investigation in an hour or so
<alan_g> alf__: OK, I'll be off to lunch shortly - if I hit inspiration before then I'll let you know.
<greyback> Hi folks, I reported this bug: https://bugs.launchpad.net/mir/+bug/1213047, but trying to use "apport-collect 1213047" returns no useful data, just the message "Package mir not installed and no hook available, ignoring"
<ubot5> Launchpad bug 1213047 in mir (Ubuntu) "[xmir] gnome-screenshot only gets black image" [Undecided,New]
<smartboyhw> greyback, because you should pick a binary package to report I think
<greyback> smartboyhw: yep, specifying a binary package helped, but a hook would be much more convenient for other users
<ricmm> alan_g: ping
<alan_g> ricmm: Hello
<ricmm> morning o/, tvoss/racarr sent me to you for something
<smartboyhw> tvoss_, hey, I asked if there's anything easy-peasy to fix and you didn't answer:P
<ricmm> I need to pass from server to clients a Lifecycle event to trigger a higher level callback in the platform-api (clients)
<ricmm> robert suggested using an interface like the under used for handle_display_config_change()
<ricmm> s/under/one
<tvoss_> smartboyhw, sorry, got lost on the pile of things I'm doing right now
<tvoss_> smartboyhw, but I don't remember something off the top of my head
<ricmm> but then there is also the general MirEvent with MirEventDelegate which I could extend with a new type of MirEvent
<ricmm> what would you consider the best approach? my event right now just needs to pass a uint32 to identify the callback to issue
<ricmm> later, it might have a couple more members
<ricmm> one of those members might be a data stream, so protobuf bytes
<ricmm> MirEvent might be a bit weak if I need to pass a stream to the client at some point
<alan_g> ricmm: I have to look at how that stuff works to give a decent answer
<ricmm> ah, who would be better to ask then? kevin?
<ricmm> it was tvoss who suggested to ping you, robert actually asked me to try with the handle_() interface first
<alan_g> There have been several versions (so I'm not sure what happens ATM) - I think duflu, racarr and kdub have worked on it.
<ricmm> ok, ill follow roberts advise
<Saviq> racarr, ping
<ricmm> it just felt a bit overkill as the DisplayConfiguration class is rather large and complex, creates a quite nice protobuf message
<ricmm> mine is just a single-member struct at the moment, with 2 more possible
<ricmm> ill give it a shot and pass it for review
<ricmm> Saviq: too early for him
<Saviq> ricmm, I know, just hoping for him to pong as soon as he's back ;)
<alan_g> ricmm: OK, if you're happy with that. (tvoss is remembering earlier in the project when I could track all the code changes.)
<ricmm> alan_g: k, thanks for the help
<racarr> Morning
<racarr> ricmm: Saviq: pre pong. I will be back and awwake for real in 10 min though
<Saviq> racarr, will be there!
<Saviq> or here, actually
<racarr> Saviq: ok back
<Saviq> racarr, so, about https://bugs.launchpad.net/mir/+bug/1211694
<ubot5> Launchpad bug 1211694 in Mir "Black screen on Nexus4" [Critical,Confirmed]
<Saviq> racarr, can we help debug in any way?
<Saviq> racarr, like give you ssh access to a device?
<Saviq> racarr, did you try just flashing the latest cdimage-touch image and then the mir image?
<Saviq> or just upgrading from the mir PPA if applicable?
<racarr> Saviq: Oh sure. Uh no I did not try the mir image I just tried the PPA yesterday which was uninstallable
<racarr> I tried building it
<racarr> all
<racarr> in it worked though
<racarr> so I haven't been able to make any progress
<racarr> maybe SSH access to a device would be good
<Saviq> tsdgeos, would you be able to get racarr a broken device with ssh access?
<Saviq> tsdgeos, broken as in "black screen on nexus4"
<tsdgeos> i guess yes
<tsdgeos> let me try
<Saviq> racarr, sure, maybe something just requires rebuilding
<racarr> Well
<racarr> Maybe if it'scdimage + mir image
<Saviq> racarr, but we don't know what that might be
<racarr> then I should try again (I only tried PPA)
<racarr> and I will be able to reproduce it
<Saviq> racarr, that would be best, yeah, you know how to get that?
<racarr> Saviq: tsdgeos Ok so one thing to check
<racarr> is if the PPA is uninstallable
<racarr> does that mean the image has the wrong packages too?
<Saviq> racarr, it wouldn't build
<racarr> by the PPA is uninstallable I mean dependency issues
<Saviq> racarr, if you mean like unresolvable dependencies
<racarr> force uninstall of unity8
<Saviq> racarr, and that seems to be the case indeed http://s-jenkins:8080/job/ubuntu-touch-phablet-image-saucy-mir/?
<racarr> well
<racarr> it has a version fight
<racarr> but not unresolved
<Saviq> racarr, so the last image built is from yesterday morning
<Saviq> racarr, which built fine
<Saviq> (last mir image, that is)
<racarr> grr qalab vpn is broken
<racarr> Saviq: I don't understand how it could build succesfully becuse
<racarr> fresh install, then add phablet ppa
<racarr> doesn't work as of yesterday
<Saviq> racarr, yesterday morning
<Saviq> racarr, as in 6am UTC
<Saviq> racarr, vpn works for me
<racarr> *starts flashing phone*
<olli_> racarr, needless to say, but this issue is starting to block more and more ppl and us in landing u8/mir... so pls work your magic :)
 * olli_ hand racarr a triple espresso 
<tsdgeos> racarr: did the ssh work now?
<racarr> olli_: It seems to have become the fun of the day!
<racarr> I just need to get to reproduce it
<racarr> tsdgeos: Still no route eto host
<tsdgeos> weird, was working for Saviq 5 min ago :-/
<tsdgeos> Saviq: does it work for you now?
<racarr> tsdgeos: I am flashing a new image now with --wipe, then will try mir image instead of ppa
<racarr> and it seems like that must reproduce it because
<tsdgeos> oka
<Saviq> racarr, tsdgeos +1, works
<racarr> all nexus 4 are the same
<racarr> Really? Why can't I ssh :(
<tsdgeos> racarr: try again
<tsdgeos> ?
<racarr> oh there we go yeah
<racarr> tsdgeos: sshed in and poking around..not totally obvious yet
<racarr> by not totally obvious I mean totally unobvious lol
<racarr> tsdgeos: I am installing the mir-demos package
<racarr> just as a friendly I am installing packages on your phone warning XD
<tsdgeos> racarr: sure, all yours
<tsdgeos> just try not to hack on the rest of the network if possible :D
<racarr> ok I am getting a strange error but I wonder
<racarr> if it might be because I'm on ssh
<racarr> tsdgeos: Wait was that do or don't
<racarr> hack the rest of the network
<racarr> :p
<racarr> tsdgeos: http://pastebin.ubuntu.com/5993217/
<tsdgeos> errr wait
<tsdgeos> is that the Nexus10 or the Nexus4
<racarr> ok surface flinger
<racarr> is running right now
<racarr> as well
<racarr> is it the wrong device lol?
<tsdgeos> no it's the nexus4
<tsdgeos> racarr: no it's the correct device
<tsdgeos> i just was not trying to do any mir anymore
<tsdgeos> so i went back to a working non mir image
<tsdgeos> so yes, surface flinger is there
<racarr> tsdgeos: Oh ok
<racarr> in that case I just broke surface flinger
<racarr> um I cant run mir_demo_server_shell still is the thing
<racarr> I guess some sort of weird device node permissions
<racarr> even as root
<racarr> same no permission exception
<racarr> ca you try running it locally? do you get that exception?
<tsdgeos> let me see
<tsdgeos> yeah, can't
<tsdgeos> never got that
<tsdgeos> reboot maybe?
<racarr> Yeah lets try it
<racarr> lemme know when its back
<tsdgeos> racarr: back
<racarr> tsdgeos: Is there anything onscreen?
<tsdgeos> nope
<tsdgeos> blackness
<tsdgeos> well greyness
<racarr> really thats too bad because its totally rendering at 60 fps lol
<tsdgeos> :/
<racarr> tsdgeos: Still nothing?
<tsdgeos> nope
<tsdgeos> now it got blacker
<racarr> mm killed the mir server
<racarr> ugh I wish we had the render_to_fb demo
<racarr> it seems though like
<racarr> bringing up the display is working
<racarr> client is connecting fine, perhaps even
<racarr> bufferallocation, etc is working fine
<racarr> well it is
<racarr> but then
<racarr> opengl just isnt producing
<racarr> any results
<racarr> I forget which
<racarr> partition is the mir image? i.e. ho do I flash it
<racarr> system, data...seems like system :p
<racarr> ricmm: ^?
<racarr> ok I think it is lashing now via bootloader thing
<racarr> I am going to go walk around the block
<racarr> HYPPPPPPPPEr
<racarr> I dont have a black screen
<racarr> so it cant have flashed very well :(
<tsdgeos> :/
<racarr> ok no its just autodeploy.zip
<racarr> doesnt work anymore
<racarr> adb sideload it is!
<tsdgeos> racarr: if yuo want i can tell you what i do
<racarr> err...it doesn't work
<racarr> tsdgeos: Yes! perfect
<racarr> its just adb flash system/data *.zip right
<racarr> but Ic an't remember if it's system or data
<tsdgeos> racarr: http://paste.ubuntu.com/5993332/
<tsdgeos> this is not even using the unity-mir image anymore
<tsdgeos> since that image i just the regular image + the ppas
<tsdgeos> or so i've been told
<tsdgeos> a reboot may be in order somewhere in the middle
<racarr> :( I feel like that's just what I did
<racarr> yesterday
<racarr> maybe it's something silly like we have a color format bug
<racarr> and nexus 4s made in october of 2012 return BGRA instead of RGBA as the first format
<racarr> lol
<racarr> I don't even know!
<racarr> ok, back in 10
<ricmm> racarr: data partition
<ricmm> tsdgeos: can you get someone else to try?
<ricmm> chicken has a nexus 4
<tsdgeos> ricmm: mzanetti tried doing extractly the same on the nexus4 and on the gnexus
<tsdgeos> can confirm the gnexus works and the nexus4 not
 * mzanetti confirms
<tsdgeos> as written in the bug
<ricmm> so what the hell is going on with robert's n4
<ricmm> what is the *exact same thing*
<ricmm> updating from the ppa? or installing the image
<tsdgeos> ricmm: the exact thing is doing the same on both devices
<tsdgeos> ricmm: you'll have to ask him what he did
<ricmm> oh I meant the exact same thing from your device to his
<ricmm> I know what exact same thing means :)
<mzanetti> ricmm: http://paste.ubuntu.com/5993351/
<mzanetti> ricmm: did exactly the same steps on a GNexus and a Nexus4
<ricmm> ok
<ricmm> what version of mir do you have on the n4
 * mzanetti boots the Nexus 4
<olli_> alan_g, is usc in lp:mir?
<alan_g> olli_: no
<mzanetti> ricmm: Installed: 0.0.9+13.10.20130813-0ubuntu1
<mzanetti> this is mir-demos. need any other packages?
<alan_g> olli_: lp:unity-system-compositor
<olli_> alan_g, thx!
<Saviq> tsdgeos, racarr, gtg, will be back later this evening if you have any updates
<racarr> ah stretching my legs felt good
<racarr> wasnt olli saying something about how instead of fixing the nexus 4 I should walk to the ocean...
<racarr> :p
<racarr> ok
<racarr> mir image produces a black screen of death...
<tsdgeos> racarr: i need to do some real life stuff, my phone's still connected, if you reboot it, it ought to come back with the same ip...
<tsdgeos> be back in two hours if nothing happens
<racarr> tsdgeos: Cheers. Thanks :)
<racarr> hopefully ill figre it out
<ricmm> racarr: maybe something changed permissions-wise
<ricmm> at the udev level, in the container
<ricmm> can you strace the server? it might be failing to acquire something
<ricmm> silently
<racarr> ricmm: Seems like it must be...
<racarr> oh good idea!
<racarr> but still this doesn't make any sense
<racarr> because the matrix looks like
<racarr> tsdgeos: Building mir on latest image (fails), adding ppa on latest image (fails), using mir image (fails)
<racarr> where for me it's building mir on latest image (suceeds), adding PPA (suceeds), using mir image (fails)
<racarr> lol so many errors
<racarr> the linking setup on phablet seems to be werid
<racarr> its looking for every library in like
<racarr> ten directories with weird numbers
<racarr> before finding them
<racarr> in /usr/ilb
<racarr> ioctl(13, 0xc0f86d87, 0xbef5fef0)       = -1 ENOMEM (Cannot allocate memory)
<racarr> writev(8, [{"\6", 1}, {"hwcomposer\0", 11}, {"Failed to call ioctl MSMFB_OVERL"..., 66}], 3) = 78
<racarr> writev(8, [{"\6", 1}, {"hwcomposer\0", 11}, {"init: Failed to setup primary ba"..., 40}], 3) = 52
<racarr> writev(8, [{"\4", 1}, {"hwcomposer\0", 11}, {"Initializing Qualcomm Hardware C"..., 40}], 3) = 52
<racarr> writev(8, [{"\4", 1}, {"hwcomposer\0", 11}, {"MDP version: 440\0", 17}], 3) = 29
<racarr> that doesn't look great
<ricmm> racarr: indeed, compare with your working scenario
<ricmm> cleaning lady about to mop the whole house, so will be away for a bit
<ricmm> lunch
<racarr> Ok, see you soon
<racarr> have to figure out a way to get my working scenario without iping back and forth all day lol
<racarr> wiping
<olli_> alf__, ping
<tvoss_> ricmm, racarr ping
<ricmm> tvoss_: sup
<tvoss_> ricmm, just wanted to check if I can help with the nexus4 issue?
<ricmm> tvoss_: oh, well not sure how far rob got
<ricmm> I dont have a nexus4 and im knee-deep into the mir work
<tvoss_> ricmm, ack
<ricmm> so no idea where we stand
<tvoss_> ricmm, ack
<tvoss_> will wait for racarr to come back then
<ricmm> ok
<racarr> tvoss_: Oh Ive been here sorry
<racarr> it didn't sho up as a ping
<racarr> tvoss_: so I'm actively 'making progress' at discovering facts
<racarr> but I can't make anything consistent out of what I have igured out so far
<tvoss_> racarr, mind walking me through what you are uncovering?
<racarr> tvoss_: Ok. So, yesterday, just building mir and the stack on a clean nexus 4 I flashed worked
<racarr> likewise this morningm it worked, but once you install the mir image, it breaks
<racarr> everything seems to run
<racarr> but things are just black
<racarr> err, ok so I mentioned all those details about the stack because
<racarr> tsdgeos built it on a normal image and it seemed to not ork
<racarr> anyway, so things are all black, no errors or anything
<racarr> but there is this suspiscious result from strace on mir_demo_server
<racarr> 16:46 < racarr> ioctl(13, 0xc0f86d87, 0xbef5fef0)       = -1 ENOMEM (Cannot allocate  memory)
<racarr> 16:46 < racarr> writev(8, [{"\6", 1}, {"hwcomposer\0", 11}, {"Failed to call ioctl  MSMFB_OVERL"..., 66}], 3) = 78
<racarr> 16:46 < racarr> writev(8, [{"\6", 1}, {"hwcomposer\0", 11}, {"init: Failed to setup  primary ba"..., 40}], 3) = 52
<racarr> 16:46 < racarr> writev(8, [{"\4", 1}, {"hwcomposer\0", 11}, {"Initializing Qualcomm  Hardware C"..., 40}], 3) = 52
<racarr> 16:46 < racarr> writev(8, [{"\4", 1}, {"hwcomposer\0", 11}, {"MDP version: 440\0",  17}], 3) = 29
<racarr> tvoss_: So then I built mir
<racarr> same results, but different strace errors interestingly enough
<racarr> http://pastebin.ubuntu.com/5994179/
<racarr> there is this error on ioctl to fd 8
<racarr> which, as ar as I can tell from the strace logs is
<racarr>  /dev/socket/property_service
<racarr> so, something has gone wrong with udev (except it doesn't seem to be udev) or apparmor (Except I unloaded apparmor) or permissions (except as root)
<racarr> so I am guessing it is some sort of LXC environemtn thing I don't understand yet
<racarr> what im currently doing is
<racarr> 55% through building mir on hat I expect to be a working nexus 4 image
<racarr> so I can
<racarr> compare the strace logs
<racarr> anyway though my leading theories are weird permissions on video devices, or this /dev/socket/property_service
<racarr> but, again, it's not a "permission" so there is some other system coming in to play
<racarr> or, I as wondering if the ENOMEM could have been meaningful
<racarr> i.e. there was some restriction on the size of processes mapped address space through some system limit
<racarr> and mapping the framebuffer isn't working
<racarr> that seems
<racarr> absurd
<racarr> so im basically just waiting on the build right now
<tvoss_> racarr, ack
<racarr> tvoss_: Oh I guess the other thing
<racarr> is buffer swapping definitely works, the hwole IPC layer, input, everyone thinks they are happy
<racarr> and the integration-tests pass, so OpenGL really renders
<racarr> so either 1. The Framebuffer is broken or 2. GL is broken on the server side
<racarr> but everything else is pretty much ruled out
<racarr> there was some weirdness
<racarr> about clients sometimes
<racarr> getting reduced FPC
<racarr> i.e. when I as testing clients it as either
<racarr> 60 fps
<racarr> 30 fps
<racarr> or 1-2 fps
<racarr> we use the HWC for vblank symbols
<racarr> so it seems tied in
<racarr> but very strange
<tvoss_> hmmm ...
<racarr> tvoss_: One way or another the spinning triangle will come back ;)
<tvoss_> racarr, yeah, we need it ...
<tvoss_> it all started with it :)
<racarr> tvoss_: It's so anticlimatic sometimes because it was so gradual XD
<racarr> if you had asked me back in copenhagen what things would have been like, when it was finally time to land mir on the phone
<tvoss_> racarr, indeed :)
<racarr> I feel like I was imagining like fireworks, peace on earth
<racarr> goodill to all men, etc
<racarr> but, it just sort of happens eventually
<racarr> XD
<racarr> and everything else is still the same
<racarr> I got pretty stressed about all of it for a while ;)
<tvoss_> racarr, that's the beauty of it :) it just happens
<racarr> tvoss_: XD ok my build finished
<racarr> the one that was supposed to ork like it did this morning, i.e. flashing the latest image and building trunk
<racarr> ERROR: /home/phablet/src/trunk/src/server/graphics/android/android_framebuffer_window.cpp(75): Throw in function virtual void* mir::graphics::android::AndroidFramebufferWindow::android_display_egl_config(EGLDisplay) const
<racarr> Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
<racarr> std::exception::what: could not select EGL config for use with framebuffer
<tvoss_> racarr, that's just weird ...
<racarr> ok and integration-tests fail all over
<tvoss_> did libhardware change?
<racarr> well test_accelerated_render hangs
<racarr> seems like
<racarr> it must have somewhere
<racarr> or
<racarr> some permissions are causing things to fail
<racarr> inside libhardare
<racarr> straceee
<racarr> except network doesn't work anymore and I can't install strace....XD
<racarr> reboot fixed it
<racarr> *rambles*
<racarr> ok also
<racarr> after reboot
<racarr> I don't get that EGL confic
<racarr> g
<racarr> exception anymore
<racarr> but nothing on screen
<racarr> it's this
<racarr> ioctl(8, 0xc0f86d87, 0xbee5c110)        = -1 ENOMEM (Cannot allocate memory)
<racarr> again
<racarr> oh the ENOMEM isn't on the properties_service it's
<racarr> open("/dev/graphics/fb0", O_RDWR|O_LARGEFILE) = 8
<racarr> ok so
<racarr> writev(3, [{"\6", 1}, {"hwcomposer\0", 11}, {"Failed to call ioctl MSMFB_OVERL"..., 66}], 3) = 78
<racarr> is the error for this ENOMEM and it matches up in dmesg to this thing [  102.204578] msmfb_overlay_set: ioctl failed, rc=-12
<tvoss_> racarr, right, seems like a memory limitation is hit
<racarr> tvoss_: https://jira.cyanogenmod.org/browse/CYAN-1260
<racarr> how obscure
<racarr> not exactly
<racarr> but close
<racarr> well the errors are exactly but why does using disk encryption trigger it in cyanogen mod
<racarr> and it being friday trigger it on ubuntu touch :p
<racarr> tvoss_: Is there an easy way to build Android.mk stuff from isnide the chroot or something
<racarr> I want to try this liboverlay
<racarr> ok its a worthwile test to see i things worked unsynced without
<racarr> HWC to
<racarr> narrow EGL out of the possibilities
<ricmm> tvoss_: this problem isnt hit on surface flinger
<ricmm> mir only
<ricmm> so it has to be some sort of permissions thing
<ricmm> check lxc-android-config for the udev rules
<ricmm> maybe something changed recently
<racarr> lxc-android-config that is
<racarr> exactly hat I was looking for earlier but didnt know what it was :)
<ricmm> https://code.launchpad.net/~ubuntu-branches/ubuntu/saucy/lxc-android-config/saucy-proposed
<ricmm> shit
<ricmm> where did my client library code go
<ricmm> :(
<racarr> non HWC mode doesn't get anything
<racarr> on the screen either
<racarr> except no apparent errors in strace and FPS is unbound
<racarr> can't find any lxc-android-config things yet but exploring
<tvoss_> ricmm, did we upgrade anything in the android side of things? I do see adjusted permissions for certain devices
<ricmm> im not aware of any updates
<ricmm> ogra is the best one to ask about those
<racarr> ogra_: Ping if you happen to come by :)
<racarr> the only perhaps relevant ulimit is max locked memory       (kbytes, -l) 64
<racarr> what sort of access control things are there besides
<racarr> posix permissions, apparmor, limits, and LXC
<racarr> android magic?
<racarr> this time the whole phone crashed :(
#ubuntu-mir 2013-08-17
<racarr> Pretty much done for today
<racarr> will be around on the weekend
<racarr> Hey I ust found my yubi key I lost months ago!
<racarr> :p
#ubuntu-mir 2013-08-18
<robert_ancell> thomi, for https://code.launchpad.net/~ubuntu-multiseat/lightdm/multiseat-logging/+merge/180238 Jenkins seems to have not noticed the reset to approved - can you kick Jenkins / tell me how to do that
<robert_ancell> ?
<thomi> robert_ancell: let me look - sorry, was AFK before
<robert_ancell> RAOF, online yet? Want to help me out with some trivial MPs?
<RAOF> robert_ancell: Yeah, sure.
<robert_ancell> https://code.launchpad.net/~robert-ancell/unity-system-compositor/install-apport-hook/+merge/180751
<robert_ancell> https://code.launchpad.net/~robert-ancell/unity-system-compositor/apport-logs/+merge/179627
<robert_ancell> RAOF, also olli suggested apport wasn't attaching sufficient information for GPUs - is that the case? I thought we had lspci and that should be sufficient? Anything else we can attach>
<thomi> robert_ancell: you should probably set a commit message on that MP
<thomi> otherwise it'll fail autolanding again
<robert_ancell> thomi, ack
<RAOF> robert_ancell: For which apport hook did olli think we didn't have enough information?
<robert_ancell> RAOF, just u-s-c I think
<robert_ancell> Note, it didn't have a hook installed
<RAOF> robert_ancell: Also, does the unity-system-compositor hook get run as root?
<robert_ancell> RAOF, I believe so
<RAOF> Oh, yeah. Because u-s-c is run as root.
<thomi> robert_ancell: I think the prerequisite branch may be confusing it. Since it's already merged, I'm going to resubmit the MP without the pre-req and approve it myself - that OK with you?
<robert_ancell> thomi, sure
<thomi> ugh. why is compiz using 80% of my CPU!?
<thomi> robert_ancell: hmm, something is very broken in the autolanding infrastructure
<thomi> robert_ancell: I'm going to try grabbing that branch and pushing it as myself, will that cause problems?
<robert_ancell> thomi, ok, so it's not me then :)
<thomi> it'll make it look like I did the work, at first glance... not sure if people care about that or not
<robert_ancell> thomi, it's not my branch, so we can't push to it
<thomi> robert_ancell: no, but I can grab it and re-push to ~thomir
<thomi> robert_ancell: or you could do that :)
<robert_ancell> thomi, I can ask them to resubmit if that will help?
<thomi> I don't think that will help, since they can't push to anywhere that we need. hmmmmm
<thomi> this is really odd
<thomi> let me see if naytone has tweaked the config files recently
<thomi> *anyone
<thomi> robert_ancell: do you think this is the first thing to land since 2013-08-17 ?
<thomi> Francis landed what looks like a pretty big change to the mir config on the 17th, I wonder if that's causing the problem
<robert_ancell> thomi, trunk has the last thing as Fri 2013-08-16 03:25:22 +0000
<robert_ancell> this is lightdm, not mir
<thomi> yeah but it's all in the same stack
<thomi> the change francis landed would affect everything in the mir stack
<thomi> which would include mir, u-s-c, lightdm
<robert_ancell> ah
#ubuntu-mir 2014-08-11
<duflu> RAOF: Shouldn't "nm" show us exporting versioned symbols?
<RAOF> duflu: Not in the default output, apparently.
<RAOF> See objdump -T
<RAOF> duflu: Re bug #1355005 - presumably you tested the --vt parameter on desktop?
<ubot5> bug 1355005 in Mir 0.6 "[regression] unity-system-compositor can't start (Unknown command line options: --vt 1)" [Critical,Incomplete] https://launchpad.net/bugs/1355005
<duflu> RAOF: Yeah checking android right now
<RAOF> duflu: Because that's a mesa-specific option.
<RAOF> Passing --vt 1 will fail on android, but we don't pass --vt 1 on android as far as I can tell, soâ¦
<duflu> RAOF: Yep. Handballed to lightdm (if at all)
<RAOF> I don't know how Cemil was getting his device to fail :)
 * duflu checks the lightdm source
<RAOF> What?!
<RAOF> As soon as I get fed up with parallel valgrind runs reliably hitting what would seem to be a race in InProcessServer setup, it's suddenly all âwhat do you mean? It works just fineâ
<duflu> RAOF: Temp files!
<RAOF> duflu: Generated by valgrind?
<duflu> RAOF: Our tests do
<RAOF> Oh, no. All of those are fine.
<RAOF> As demonstrated by âmake test ARGS=-j200â being reliable.
<RAOF> Well, except for very rare failures in InProcessServer, which *doesn't* make a temp file.
<duflu> RAOF: Wow, that's the run on a quantum computer option?
<duflu> Cos of course it finds a solution then
<RAOF> That's the âalmost all of the memory is shared, and a major component of the test time is where we (necessarily) sleep for 3 seconds or whatever>
<RAOF> There's no real reason not to run *all* the tests at once :)
<RAOF> I just don't know the CMakery to make it happen by default
<RAOF> Oh!
<duflu> RAOF: More curious is how Cemil got it working at all. If you have the latest tip of either Mir branch then USC won't build at all (bug 1355021)
<ubot5> bug 1355021 in Mir "[regression] unity-system-compositor FTBFS against Mir 0.6/0.7: undefined reference to `...@MIR_CLIENT_8'" [Critical,In progress] https://launchpad.net/bugs/1355021
<duflu> I guess it just wasn't the latest code
<anpok> RAOF: it fails for me too image 183..
<anpok> (vt param issue)
<RAOF> anpok: What's adding the vt parameter?
<anpok> it is not part of usc-wrapper
<anpok> oh also the logs say that lightdm does it
<RAOF> Yeah, /var/log/lightdm/lightdm.log is your winner.
<RAOF> But why is LightDM setting the --vt parameter for you but not for me?
<RAOF> What device are you running on?
 * RAOF suspects lightdm's vt_can_multiseat() check is faulty.
<anpok> n4
<anpok> hm vt is only omiited if it stays unconfigured and negative
<RAOF> anpok: Does your n4 have a /dev/tty0 and /sys/class/tty/tty0/active?
<RAOF> Because that's what LightDM uses to determine whether or not to set the VT.
<anpok> yes
<anpok> both
<RAOF> Ok, so that's why.
<RAOF> The N4's kernel would appear to have CONFIG_VT set for some reason.
<anpok> seat_unity_start?
<RAOF> So: options are - add a VT option to the android backend, as it would clearly work (for some devices), change the LightDM check to not detect VT on android, or revert the change that makes unrecognised options fatal.
<RAOF> anpok: Indeed. Calls vt_can_multi_seat()
<anpok> but if it gets no vt it fails..
<anpok> is there a fallback somwhere else that would then start usc?
<RAOF> But it *does* get a VT
<anpok> sure
<RAOF> Oh, it only fails if it doesn't get a VT *and* vt_can_multi_seat returns true. Otherwise it sets 0.
<anpok> given a device without a config_vt kernel...
<RAOF> Which is âoh, I don't do VTsâ
<anpok> ah ok
<RAOF> So, if you test on the N10 you'll never hit this, because it's apparently built without CONFIG_VT
<anpok> and 0 means ommit
<RAOF> Correct
<alan_g> RAOF: we can add a handler for --vt to USC
<alan_g> It's a few LOC as a workaround
<alan_g> If Mir handles it then USC never hears about it, otherwise it can ignore it
<RAOF> alan_g: That's a fine workaround, but we should also get lightdm to stop passing it.
<alan_g> Yes.
<RAOF> Because lightdm might behave incorrectly. If, say, it expects us to be on a particular VT and we totally ignore that :)
<anpok> hm .. configuring lightm with minimum-vt=0 is not accepted by lightdm it expects >0
<anpok> would be the wrong setting anyhow
<alan_g> So, shall I put a workaround into USC/devel-mir-next? (With dirty great FIXME comments about lightdm)
<RAOF> alan_g: Sounds like the quickest unblock.
<anpok> hm lightdm is supposed to provide the platform parameters
<anpok> so it should figure out which platform is going to be used
<anpok> and only then consider vt options
<anpok> or are we going to have start up time configured platform options?
<RAOF> We should probably invest in an actual configuration file at some point.
<anpok> i mean select the platform on startup inside mir..
<RAOF> Oh, that.
<RAOF> See https://code.launchpad.net/~raof/mir/privatise-all-the-things/+merge/228796
<RAOF> Where we select the platform on startup inside mir :)
<anpok> hm so in theory lightdm then needs to provide relevant options for all possible loadable platforms
<RAOF> Not really; the only reason why lightdm provides the VT is that it needs to do VT handling.
<RAOF> We *should* have a config file so that nonvolatile options can be specified there, though.
<alan_g> RAOF: Done
<alan_g> duflu: have you a fix for lp:1355021 or shall I MP mine?
<duflu> alan_g: Yes, it's been up for review some time now :)
 * alan_g hits refresh
<alan_g> duflu: I think "Requires.private: mirclient" is all we need, but if you know better?
<duflu> alan_g: Tried that first. Apparently it doesn't work like we thought it does
<duflu> And the pkg-config docs are vague
<alan_g> Hmm, I built USC that way - but I'll take your word for it
<duflu> alan_g: Maybe I made a mistake. But that was my first idea.. private
<alan_g> I'll retest
<duflu> alan_g: I mean doesn't work in mirserver.pc.in ... and that's where you want the fix obviously. Users of mirserver should never have any knowledge that libmirserver links to libmirclient privately
<alan_g> duflu: Yes. That's what I mean
<duflu> alan_g: I also noticed we're missing Requires gles and egl too. But propose them separately
<alan_g> duflu: that makes sense. "Requires.private: mirclient"  in mirserver.pc.in fixes builds of USC, qtmir, unity-mir and platform-api (the devel-mir-next branches) I think it is the way to go.
<duflu> alan_g: I can only assume I made a mistake. It failed for me... didn't add -lmirclient to the link line of usc
<alan_g> duflu: care to re-check?
<duflu> alan_g: Actually I think rpath-link is nicer
<duflu> alan_g: Not really. I'm trying to finish other things today. Land whatever works
<alan_g> duflu: it was RAOF that suggested removing rpath
<duflu> alan_g: Yeah it's a big hammer I guess. That's one disadvantage
<groot_> Hello guys.
<groot_> kdub: good news :). At last I booted UT with the latest ubuntu image (8 august). But logcat shows the same errors as it did in previous image.
<alan_g> camako: There's a workarond for the --vt problem on USC/devel-mir-next already. And for the FTBFS at https://code.launchpad.net/~alan-griffiths/mir/fix-1355021/+merge/230272
<groot_> Screen flickers a lot whenever I touch, probably due to EGL_BAD_MATCH error. I've the logs, can you take a look ?
<camako> alan_g, yep incorporating them into the branches right now.
<groot_> here's the logcat http://paste.ubuntu.com/8017115/. If you need any other logs, let me know.
<kdub> groot_, good progress, flickers how?
<groot_> kdub, all icons bounces up and down. Sometimes screen becomes white. When I press any app, it doesn't open until I touch the screen again.
<kdub> hmm, might not have a quick fix :/
<groot_> there's a error in logcat "call to OpenGL ES API with no current context". Maybe it's because of this or EGL_BAD_MATCH.
<groot_> kdub: I'm patient :). Any log you need to identify the problem ?
<racarr> Guten morgen!
<alan_g> 192325
<racarr> qengho: Hi...can't find this chromium-mir-apply-patch
<racarr> you mentioned
<racarr> did you take it down? Or maybe I am forming the URL wrong...
<qengho> Oh. Hrm.
<racarr> or is it not in your public_html? I dont seem to be able
<qengho> Oh, not a url. I can move it into the web space.
<racarr> to ssh to chinstrap anymore
<racarr> ah
<qengho> racarr: Okay, now in web space.
<racarr> qengho: Ok well I will giveit a try and see what happens :)
<qengho> racarr: I don't mean to dump a big problem on you. I'm debugging too. I think it's initializing too many times, and I'm testing that guess now.
<racarr> Well I will at least get a build going so I have a working tree
<racarr> qengho: + grep 'X-rev: untethered, sync dev patch back to release. Wanted 22454{revision:-a revision but none was specified.}' debian/patches/mir-support
<racarr> ?
<racarr> ./apply-patch-distro.sh: line 52: f: unbound variable
<qengho> racarr: Hrm. I'm missing a blackslash.  Download again?
<qengho> Just fixed in place.
<racarr> qengho: :) s'goin now thanks
<qengho> racarr: shell script within a shell script within a shell script.  Fancy, but error-prone.
<dandrader> alf_, is the take_snapshot() method guaranteed to call the callback from a thread different from the caller?
<dandrader> alf_, in other words: is it guaranteed to be asynchronous or could it be synchronous?
<qengho> Hi, what can my client use to determine whether it's in a Mir session?  Env var "MIR_SERVER_NAME"?
<alan_g> qengho: I'm not sure I understand the question. A Mir session doesn't exist until a client connects to a Mir server - at which point it ought to know about having connected.
<racarr> qengho: I guess you mean like, how could you autodetect mir v. x11
<racarr> MIR_SOCKET will not necessarily be set so I don't really know...
<racarr> You can see if mir_connect fails :)
<racarr> certainly if you can connect to X11 and Mir you probably want to connect to Mir
<alan_g> qengho: By default a client connects to $XDG_RUNTIME_DIR/mir_socket - so that file existing would be an indication of a mir server. But the server could have supplied $MIR_SOCKET to override this location. (It is also possible for servers to do something else that the Mir code doesn't support directly but the client should know about that.)
<qengho> Thanks.
<alan_g> As racarr says, if mir_connect fails then there's probably no Mir server
<racarr> Can we rm -rf platform-api-mirserver? did someone already
<racarr> looks like its still there
<racarr> qengho: It is telling me patches/mir-support already exists and bailing out of the script
<qengho> racarr: Ah, right. You can "quilt delete mir-support" or edit debian/patches/series to disable the one I added.
<greyback> racarr: +1 on  rm -rf platform-api-mirserver
<racarr> qengho: :) thanks. I figured. I just wanted to make sure I was "following the instructions"
<racarr> for reproducability
<racarr> greyback: Ok I will submit an MP soon...I dont know if now is the time to do it but
<racarr> I mean otherwise we will just forget lol
<racarr> I would at least :)
<greyback> racarr: it's far from important right now
<greyback> but nobody will forget it - any time you've to do anything with papi, you can't avoid seeing it :)
<racarr> mm
<mhall119> is mircast working to record videos from a device yet?
<ogra_> that always worked ... but youo wont have enough space on the device for the raw data
<ogra_> mhall119, http://paste.ubuntu.com/8021284/ ... still in very early stages (and i havent touched it in  months) ... my plan was to actually get from there to having netcat stream it on a port into avconv on a PC
<RAOF> ogra_: Did you look at hooking the stream up to the hardware video encoding bits?
<RAOF> ogra_: I think that our screencasting interface should be expressive enough for you to do zero-copy screencast â hardware encoder, which would give you much more space on the device :)
<ogra_> oh, thats actually a nice idea, no, the above is just a bit of sunday afternoon scriptery from when mirscreencase was new ... i'll pick up that work after RTM again
<ogra_> *cast
<camako> Mir 0.6.0 release is ready for testing.... Here are the instructions to use Mir 0.6.0 : http://pastebin.ubuntu.com/7993688/
<camako> AlbertA, racarr, kdub ^^ ... You guys might be EoD by now, but in case you're not...
<camako> Mir test plan --- > https://wiki.ubuntu.com/Process/Merges/TestPlans/Mir
#ubuntu-mir 2014-08-12
<mhall119> thanks ogra_, I may just rig up my old phone to record
<racarr> Back for more.
<racarr> (I just cant get enough)
<mhall119> hey racarr
<RAOF> Stupid valgrind. Be faster. On the N10
<duflu> Hmm, launchpad and Canonical servers seem to be down... ?
<chunsang> duflu: I think so, couldn't connect to Canonical servers.
<seb128> it's being looked at
<duflu> I have the whole rest of the internet and still feel cut off :/
<alan_g> Launchpad seems to be working here - but canonical irc isn't
<duflu> greyback: Can you explain what it is exactly that makes the summary screen appear when waking from sleep? Is it Unity8 getting a wakeup event of some sort?
<greyback> duflu: u8 gets a dbus message from powerd when the display has been blanked - for which it draws the greeter (summary screen as you called it)
<duflu> greyback: OK, cool. So my solution should work then. Unfortunately I can't x-compile for android now I deleted my cache and launchpad is gone
<greyback> duflu: not sure what you're fixing but uhhh.. good job! :)
<duflu> greyback: Wrong frame seen (sometimes) on wakeup
<greyback> duflu: does it fix this too? https://bugs.launchpad.net/unity8/+bug/1353374 by any chance?
<ubot5> Ubuntu bug 1353374 in qtmir (Ubuntu) "Last dash frame not posted to display" [Undecided,In progress]
<duflu> greyback: Don
<greyback> woo!
<duflu> greyback: Don't think so
<greyback> aww
<duflu> greyback: I'm only working on restarts right now
<greyback> ok
<duflu> greyback: Although I suspect Mir shouldn't need fixing. Why wouldn't you get U8 to have some greeter frame ready when it goes to sleep?
<duflu> Mir is getting *fixed* regardless
<duflu> I mean, switch to greeter mode and then it redraws at the sleep rate of 10Hz
<greyback> duflu: u8 isn't blocked from drawing when the display goes to sleep. So it does eventually draw the greeter
<alan_g> alf_: do you have any insight? https://code.launchpad.net/~alan-griffiths/mir/deduplicate-platform-plugin-symbols-maps/+merge/229939
<greyback> duflu: there's some reason it takes >1 second for u8 to actually show the greeter though. That I don't understand
<duflu> greyback: That's a worry. It means my solution of waiting 500ms for a fresh frame before forcing one isn't enough
<duflu> greyback: Although I have added a *flush* for the whole scene. Need to get launchpad back to test on the phone
<alf_> alan_g: I am OK with exporting the mesa symbol for now, I can't think of a sane way to do it otherwise (but admittedly I haven't thought too hard).
<alan_g> alf_: I don't feel I've any real understaind
<alan_g> understanding of the problem it solves - just how the current solution works
<duflu> alan_g: (I still can access LP but) I reproduced the link failure of USC again today. Seems I was the only one testing in a pure clean environment so still had the bug after yesterday's fix. Found the bug is actually in USC so proposed a final fix there
 * alan_g wonders why backspace is so close to enter
<alan_g> duflu: I think you were testing USC trunk not .../devel-mir-next which has a similar fix (I think yours is probably more correct though)
<duflu> alan_g: Tested both today :)
<duflu> The bug is consistent
<duflu> I do wonder how the silo(s) built USC at all. It means they're not building it correctly if they succeeded last night
<alan_g> duflu: camako and I were wondering the same about Friday's "successful" build
<alf_> alan_g: problem is: because Mesa supports multiple platforms, when we call eglGetDisplay(handle), Mesa needs to decide which platform to load based on handle. For mir it tries to load the ...is_valid function and uses that to check if that is a Mir handle so it can use the mir platform.
<alan_g> Either the environment or the build settings must be significantly different in a debuild
<alf_> alan_g: an idea is to expose that function through a helper library instead of mirclientplatform
<alan_g> alf_: I think there should probably be a better way, but without a second platform requiring analogous capability it is hard to know what the right abstraction is. So I'm OK with exporting the mesa symbol for now (or trying to).
<duflu> alan_g: Where can I find the nested-server input event logic?
<duflu> Is there a pass-through somewhere?
<alan_g> duflu: not sure exactly there's an event handler around somewhere ... NestedOutput::mir_event(?) ... that takes input events and injects them in the input stack
<duflu> alan_g: Aha, you're right. I didn't think to look under graphics/ for input code :)
<duflu> Whee, launchpad returns
<alf_> Saviq: https://bugs.launchpad.net/mir/+bug/1353374 , have we concluded that it's qtmir or unity8 at fault here, I see that they are marked in progress for those components ?
<ubot5> Ubuntu bug 1353374 in qtmir (Ubuntu) "Last dash frame not posted to display" [Undecided,In progress]
<Saviq> alf_, Daniel was working on those, dunno how far he got though
<Saviq> alf_, so I can't comment on whose fault it is yet
<alf_> Saviq: ok, I will wait for Daniel... I just want to know if I should be looking into it from the Mir side of things
<alf_> dandrader: Hi! About take_snapshot(): it is synchronous when returning an empty snapshot (e.g. when there is no session/surface), but ideally you should assume nothing about it, only that the callback will be called at some point.
<alf_> dandrader: is this causing a problem for you?
<dandrader> alf_, no really. just wanted to know
<alf_> dandrader: ok
<alf_> dandrader: for https://bugs.launchpad.net/mir/+bug/1353374, does "in progress" mean that you have traced the problem in unity8/qtmir?
<ubot5> Ubuntu bug 1353374 in qtmir (Ubuntu) "Last dash frame not posted to display" [Undecided,In progress]
<mardy> after calling mir_connect_sync(), mir_connection_is_valid() returns false, and the error is: "connect not called"
<mardy> any ideas?
<alf_> mardy: do you have some code you can share?
<mardy> alf_: http://bazaar.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/trust-sessions/view/head:/online-accounts-service/mir-helper.cpp
<mardy> alf_: lines 118-121
<alf_> mardy: hmm, that's strange, is there an easy way to reproduce this?
<mardy> alf_: not without building the branch... but I could try to write a simpler test case
<mardy> alf_: or maybe the MirConnection is simply NULL?
<alf_> mardy: not null, it would crash in that case
<alf_> mardy: can you run under gdb and "catch throw" to see if any exceptions are thrown inside mir?
<mardy> alf_: yep: http://paste.ubuntu.com/8026826/
<mardy> alf_: let me see if I can install debug symbols...
<alf_> mardy: so there are two aspects to this 1. that mir_connect_sync fails 2. that it returns an error message that is not expected
<alf_> mardy: Let's focus on (1) since that's what's blocking you I presume
<alf_> mardy: Which server are you trying to connect to?
<mardy> alf_: the default one (I just run the app from the phone's terminal)
<alf_> mardy: ok, what's your "MIR_SOCKET" env value?
<mardy> alf_: the variable is unset
<alf_> mardy: ok, then it should connect to $XDG_RUNTIME_DIR/mir_socket
<alf_> mardy: probably /run/user/32011/mir_socket
<mardy> alf_: do you mean that I should pass that instead of NULL, or you are just saying that it will connect there by default?
<alf_> mardy: it should connect there by default, so need to do anything
<mardy> alf_: OK, the file exists
<alf_> mardy: ok, just to be sure can you confirm that XDG_RUNTIME_DIR is set properly?
<mardy> alf_: yes, it's correct
<alf_> mardy: so, unity8 has been known to reject connections that do not have an associated desktop file, can you try running with --desktop_file_hint=/usr/share/applications/online-accounts-ui.desktop (or some other valid .desktop file)
<alf_> mardy: alternatively export  APP_DESKTOP_FILE_PATH=<desktop-file>
<mardy> alf_: ah, right, there was an e-mail discussion about authenticating trusted helpers, that might be the issue
<mardy> dednick: hi! Does the above ring a bell to you? ^
<dednick> mardy: looking
<greyback> mardy: oh, should you not be using the trusted socket: $XDG_RUNTIME_DIR/mir_socket_trusted
<dednick> mardy: is this a trust helper? or an app?
<mardy> greyback: ah-ah! makes sense :-)
<mardy> dednick: a trusted helper
<dednick> mardy: yeah. trust helpers need the trusted socket to connect otherwise qtmir will reject the connection
<mardy> dednick: OK, I will try that, thanks
<mardy> looks like it's working! :-)
<mardy> greyback: the helper is supposed to slide up from the bottom, right?
<greyback> mardy: yep (dednick's work)
<mardy> then it's working fine :-D
<greyback> woo!
<groot_> kdub: Hello :). Did you find any solution to my problem? Earlier, I was running some mir_demo test in the phone. Most of them works fine, some failed with exception.
<kdub> groot_, no, flickering is usually caused by some timing problems that are tricky to pin down
<groot_> kdub: Any particular log you need to identify the problem? Here's the tests log anyway, if it helps http://pastebin.com/aHqTs0qH.
<qengho> I upgraded to uptopic on my machine.  My xmir buffer n-1 problem is gone, yay.
<qengho> mir test clients don't run, though.  mir_demo_client_basic    #->   Assertion `mir_connection_is_valid(mcd.connection)' failed.
<racarr> Good morning
<racarr> delayed standup is mostlyu studying inpout resampling
<alan_g> qengho: what are you using as the Mir server? Is it publishing an endpoint at $XDG_RUNTIME_DIR/mir_socket?
<qengho> alan_g: There is no socket. What am I using? Er, xmir, I think.
<alan_g> XMir is an X11 server, not a Mir server - so I wouldn't expect it to support Mir clients.
<qengho> Oh. I'm using regular desktop on Utopic. I have a client I wish to test. What's the best way?
<alan_g> switch to (say) VT1 & run a mir server (as root) e.g. "sudo mir_demo_server_basic"
<alan_g>  switch back to VT7 and sudo chmod a+rw /tmp/mir_socket
<alan_g> then run your app using /tmp/mir_socket as the socket (on command line or via $MIR_SOCKET)
<alan_g> Switch back to VT1 to see the results
<alan_g> qengho: http://unity.ubuntu.com/mir/using_mir_on_pc.html
<qengho> alan_g: thanks.
<groot_> kdub: I tested eglMakeCurrent() with some ALOG commands like this http://paste.ubuntu.com/8027461/
<groot_> found that sometimes it reports "No context", "Not drawn", "No surface". But function returns EGL_TRUE.
<racarr> Is anyone familiar wiht test failures in the phablet-test-run mir-demo-suites fixture on mako CI
<racarr> touchspot-renderable has failed CI twice because of that...it looks like the tests(I can't figure out how to run them yet) are just runnin
<racarr> g
<racarr> a demo server and a client
<racarr> which  I just did with the branch on a clean mako...
<racarr> or does anyone know how I can reproduce this suite locally? I don't seem to have it as an autopilot test suite which apparently it is
<racarr> + phablet-test-run -x -s 04ccca120acd4dea -v mir-demo-tester --mir-demo mir_demo_client_fingerpaint /tmp/mir_demo_client_fingerpaint-log
<racarr> this sort of stuff
<racarr> https://launchpad.net/~chris.gagnon/+archive/ubuntu/mir-demo-tester perhaps
<robotfuel> racarr: that doesn't use autopilot, I think that needs the mir-demos or mir-test-tools package to be installed
<racarr> robotfuel: Ah the -x arg to phablet-test...thanks :)
<racarr> the -s was so confusing I filtered out the -x too and had been trying to run it as autopilot I guess
<robotfuel> racarr: the phablet-test-run -x just executes a command on the phone, the -s is the phone's serial number :D
<racarr> robotfuel: It looks like I need mir-demo-tester from the PPA? Or was I supposed to get it from some package in archive.
<racarr> ah
<robotfuel> racarr: mir-demo-tester is in my ppa. it's not in the archive.
<racarr> kdub: Should I consider touchspot renderable rejected until demo shell is fixed?
<racarr> as long as demo shell is decorating based on renderable
<racarr> there is obviously no way to
<racarr> have it not decorate certain renderables
<racarr> without adding information to renderable that
<racarr> post_renderables_if_optimized
<racarr> can't interpret
<racarr>  demo shell is fixed, renderable is fixed, the tesselate method is changed, whatever
<racarr> I mean one "solution"
<racarr> is to have renderer accept scene elements
<racarr> while display buffer would only accept renderable
<kdub> racarr, yeah, thats somewhat what i'm thinking
<kdub> i mean, Renderer needs to be picked apart, but thats a bit of a tough task
<kdub> and after lp:~kdub/mir/fix-1348330 lands
<kdub> the demo shell's compositor can operate on renderables
<kdub> so then the scene elements can carry the info
<kdub> sorry, rephrase
<kdub> the demo shell's compositor can operate on _scene elements_
<racarr> aha ok
<kdub> actually, that one is moderately clear to land
<kdub> oh, yeah, have to track down that valgrind thing
 * kdub can shift to doing that
<racarr> :) No real hurry on my end besides
<racarr> generic trying to iterate on open branches in the morning
<racarr> style situation
<kdub> yeah, its about time to get that one through though
<racarr> :) ok yeah it looks like after that it would be pretty straightforward to extend
<racarr> well
<racarr> change would_embellish to work in terms of scene elements
<kdub> sure
 * kdub grumbles about GLRenderer
<kdub> i think there should be SceneElements::with_shell_data(std::function<void(std::shared_ptr<void>)> const&)
<kdub> or a get/set that shells can program in data thats affixed to the specific SceneElement
<kdub> but, doesn't clutter up core mir with a bunch of specific interfaces for decarotions/animations
<kdub> that all the shells want to rewrite anyway
<racarr> maybe...
<kdub> yeah, doesnt really apply to the cursor stuff though, as that's something that comes out of 'core mir'
<racarr> It makes sense in that it solves problems so far we
<racarr> see between qtmir and demo-shell
<racarr> I guess im still attached to this idea
<racarr> of functional purity of the renderer with respect to
<racarr> scene elements/renderables
<racarr> which shell data, definitely kind of flies at
<racarr> on the other hand um
<racarr> that idea has never really panned out
<racarr> nor has any reasoning why it
<kdub> I guess I just don't see that the renderer is functionally pure right now :)
<racarr> should pan out really been proven
<racarr> no! It's not
<racarr> well
<racarr> I mean with respect to the renderables it almost is right there is a certain serializable input stream
<racarr> i.e. {buffer: 3, geometry: some rectangle}
<racarr> I mean I don't know you can view it as outputting some hardware command stream
<racarr> which obviously is stateful
<racarr> depending on overlay state and bla blabla.
<racarr> but you can also view, the renderer, and the renderer...backend (i.e. opengl, hwc...) as
<racarr> a function from Renderlist -> pixels
<racarr> but maybe that's not really particularly meaningful :)
<Nothing_Much> Are there problems with running XMir with the Oibaf PPA on Radeon APUs?
<racarr> [ 68%] Building CXX object tests/unit-tests/CMakeFiles/mir_unit_tests.dir/graphics/mesa/test_buffer_allocator.cpp.o
<racarr> [ 69%] [ 69%] Building CXX object tests/unit-tests/CMakeFiles/mir_unit_tests.dir/graphics/mesa/test_display.cpp.o
<racarr> ...whoops
<racarr> selection buffer strikes again
<racarr> hmm
<racarr> ugh
<racarr> tried moving is_a_surface/needs_decoration/whatever to SceneElement
<racarr> but now...the problem is how does the DemoRenderer know about it
<racarr> in particular DemoRenderer::tesselate which is called from the bowels of DemoRenderer::render
<racarr> the thing is if you make
<racarr> render take
<racarr> SceneElementSequence
<racarr> then the API to compositor becomes very clumsy...i.e.
<racarr> Query scene elements, see if you want to offer to hardware compositor, if you do copy each elements renderable to a renderable list
<racarr> pass it to post_renderables_if_optimizable
<racarr> if not you pass the scene element sequence to the renderer
<racarr> the list copying is pretty ugly :p even if you can make it efficient i.e. make Renderable
<racarr> List(SceneElementSequence const&) zero copy
<racarr> its a weird assymetry between
<racarr> Renderer::render(SceneElementSequence) and DisplayBuffer::post_renderables_if_optimizable(RenderList)
<racarr> of course, if you make post_renderables_if_optimizable take SceneElementSequence then
<racarr> the entire point of moving is_a_surface toSceneElement
<racarr> is invalidated
<racarr> the thing is I think the inheritance of implementation
<racarr> from GLRenderer->DemoRenderer is weird
<racarr> I mean, DemoRenderer could have a totally different interface than GLRenderer because its only used from DemoCompositor
<racarr> except that it wants to duplicate the code to draw a rectangle
<racarr> which while convenient for saving the original author a half an hour
<racarr> isnt a realistic design imo
<racarr> err
<racarr> it wants to share the code to draw a rectangle*
<kdub> right
<racarr> I think I am going to hack around it in demo renderer
<racarr> rather than make any mir interfaces weirder
<racarr> i.e. DemoRenderer::begin(std::set<mg::Renderable::ID> const& renderable_ids_not_to_decorate)
<racarr> lol...
<racarr> unordered_set even
<kdub> yeah, I kinda feel like DemoRenderer/GLRenderer have to be a different objects that share some objects
<kdub> like a tessellation object
<kdub> like, even if it it didn't share anything, writing a gl program to draw squares isn't that tough
<kdub> even if it is a few scores of lines of code, just gl's nature
<kdub>  /end my 2cents
<racarr> kdub: I agree....maybe it shouldn't share anything.
<racarr> we will see...I think this strangeness of what I am doing here will attract some comments lol
<racarr> so ium sure discussion will continue
<kdub> hah, yeah
<racarr> I think one of the test makos may be failing or something
<racarr> https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/2376/console
<RAOF> racarr: Hm. That looks more like a setup error.
<RAOF> âunable to make backup link of `./lib/udev/rules.d/70-android.rules' before installing new version: Invalid cross-device linkâ
<racarr> I think thats
<racarr> just  a thing that happens
<RAOF> That doesn't look like hardware failure to me?
<racarr> you always get that in the emulator too
<RAOF> That should fail the tests, though?
<racarr> oh
<racarr> yeah
<racarr> hmm
<racarr> what does it mean
<RAOF> I think that the /lib mount point has gone weird?
<RAOF> Man, valgrind is not the greased lightning on an N10.
<RAOF> Stupid bloody code bloody bloody grumble mumble grumble...
<RAOF> Why do you leak, damnit?!
#ubuntu-mir 2014-08-13
<RAOF> To the espresso machine repairer!
<duflu> Oh, looky. utopic gets 0.6! https://launchpad.net/ubuntu/+source/mir
<duflu> alf_: Around?
<alf_> duflu: yes
<duflu> alf_: Since 0.6.0 got released today we're getting bug reports of https://bugs.launchpad.net/mir/+bug/1348515
<ubot5> Ubuntu bug 1348515 in Mir "libmircommon-dev 0.6.0+14.10.20140811-0ubuntu1 fails to install/upgrade, does not replace mircommon-dev 0.5.1+14.10.20140728-0ubuntu1" [High,In progress]
<duflu> Do you want to revive the fix?
<RAOF> Urgh :(
<duflu> Should only affect developers. Unfortunately due to other bugs even non-developers will be -dev packages already
<duflu> will *have*
<alf_> duflu: RAOF: So, I am not sure what the right fix is. Probably change < 0.5.1+14.10.20140722-0ubuntu1 to << 0.6~ ?
<duflu> alf_: Surely "<< 0.6" ?
<RAOF> 0.6~ would be right(erish)
<duflu> Righterish then
<alf_> duflu: RAOF: ok, let me propose that then
<alf_> duflu: @cross-compile with 4.9, I have to change the cross compilation cmake file to explictly use 4.9. Does the current plain '...-g++' work for you?
<duflu> alf_: It does now. Today's updates insisted on replacing the 4.8 one with 4.9
<alf_> duflu: ok, thanks
<duflu> Come to think of it I had experimented with 4.9 x-compiles a while back and forgot about it
<duflu> alf_: I didn't mean to ask you to fix the bug. Only that you already had a fix in progress :)
<duflu> And in 24 hours we may well have a lot more duplicates coming in from utopic users
<duflu> (un)fortunately not a large proportion of users are set with with LP accounts to report bugs
<alf_> duflu: no worries, it's a trivial fix (assuming it works). Come to think of it again, perhaps you are right, the tilde in (<< 0.6~) doesn't make much sense (doesn't hurt either)
<alf_> RAOF: ^^ ?
<RAOF> alf_: Doesn't matter much either way :)
<alf_> well, unless someone releases 0.6~ver, but then again someone may release 0.6~~ :)
<duflu> Debian version sorting looks complicated :P
<RAOF> Bah, ok, then. I'll write a double-buttocked stub platform.
<alf_> RAOF: duflu: https://code.launchpad.net/~afrantzis/mir/fix-mircommon-debian-replaces/+merge/230583
<duflu> alf_: Ta
<seb128> is https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1354564 an issue somebody is looking at?
<ubot5> Ubuntu bug 1354564 in unity8 (Ubuntu) "Keyboard no longer works in Unity8 desktop session" [Undecided,Incomplete]
<seb128> real keyboard not working on unity8-mir-desktop sessions
<duflu> seb128: Sorry, I didn't notice that one. I'll make sure we don't lose track of it
<seb128> duflu, thanks
<ogra_> hmm, there seems to be a new hard dependency on freedreno in Mir ... the 0.6.0 release pulled that inot the touch images which makes the tarball grow by 4MB ... is this hard dep actually nercessary ?
<ogra_> (we are very short on space in touch and will never use freedreno there)
<duflu> ogra_: That's probably not from Mir directly, but something else Mir uses. See Mir doesn't mention it: http://bazaar.launchpad.net/~mir-team/mir/0.6/view/head:/debian/control
<duflu> ogra_: Try removing "freedreno" and see what packages complain?
<ogra_> http://paste.ubuntu.com/8034516/
<ogra_> seems libdrm ... via mesa :/
<ogra_> s/via/and/
<alf_> ogra_: the question is: why are we pulling in mesa and libdrm on the phone in the first place?
<ogra_> alf_, some deps i think ...
<anpok> shlib deps?
<anpok> on mirserver ..
<anpok> nm, looked at the x86 build..
<alf_> ogra_: some mir packages depend on libegl1-mesa (>= 7.8.1) | libegl1-x11 and libgles2-mesa (>= 7.8.1) | libgles2 , perhaps we could change these so they are satisfied by what touch provides with the android drivers?
<ogra_> alf_, yeah that would be good i guess ... if we can drop mesa we definitely should
<alf_> ogra_: hmm, the libhybris packages doesn't provide libgles2 nor libegl1(-android) or similar, not sure what the policy for libegl packages is
<ogra_> lets wait for rsalveti i guess :)
<racarr> Morning
<Saviq> incomiiiing!
<mterry> :)
<mterry> Hey folks!
<mterry> I need help with a promotion-blocking bug
<mterry> I'm seeing behavior where /run/user/32011/mir_socket_trusted is created, but the normal mir_socket file in that directory is *not*
<mterry> Any guesses on what code path would cause that?
<dednick> alan_g: ^
<kdub> mterry, is the MIR_SERVER_FILE set? or did it go to /tmp/ somehow?
<kdub> also, the default is based on XDG_RUNTIME_DIR
<mterry> kdub, let me double confirm env
<dednick> mterry: check for tmp/mir_socket
<mterry> MIR_SERVER_FILE=/run/user/32011/mir_socket and XDG_RUNTIME_DIR=/run/user/32011 for unity8, which should be creating these
<mterry> dednick, no such file
<dednick> although i don't know why the trusted one would be at a different location
<mterry>  /run/mir_socket exists, but that's for USC
<mterry> kdub, ^ see above about the environ
<dednick> mterry: what about MIR_SOCKET ?
<kdub> the trusted file can be changed via MIR_SERVER_PROMPT_FILE
<kdub> mterry, its somewhat strange that MIR_SERVER_FILE is set in the environment
<mterry> MIR_SOCKET=/run/user/32011/mir_socket but MIR_SERVER_HOST_SOCKET=/run/mir_socket
<mterry> kdub, ^
<mterry> kdub, the unity8 upstart job sets that
<kdub> mir won't parse MIR_SOCKET, iirc
<dednick> mterry: is MIR_SOCKET set outside of the unity8 env?
<kdub> oh, I take that back
<mterry> dednick, I think lightdm does
<dednick> kdub: it's something in u8 upstart
<kdub> it does parse MIR_SOCKET
<mterry> dednick, does set it rather
<mterry> kdub, MIR_SOCKET is set to the same as SERVER_FILE.  But when unity8 started, it was set to /run/mir_socket
<mterry> kdub, which is normal Mir operation, as I recall (to re-set the var for the sake of any subprocesses)
<kdub> and no failures? sounds like something's not set or not parsed as expected
<kdub> like, forgive me if you know all this but
<mterry> kdub, I don't see a message in unity8 log
<kdub> MIR_SERVER_FILE will set the server's socket file for clients to that server
<kdub> MIR_SERVER_HOST_SOCKET will set the socket for a nested mir to connect to
<mterry> Yes.  And those values are seemingly set correctly for unity8
<mterry> I'm just not seeing the mir_socket file existing
<mterry> Though I *am* seeing the mir_socket_trusted file
<dednick> hm. wonder if someting closed the file.
<mterry> dednick, uh oh
<mterry> dednick, I think I see a scenario where that might happen in fact
<mterry> but this would all explain unity8-dash, but not the weird unity8 behavior...
<mterry> kdub, I may see the problem.  I think it's not Mir.  It's a job deleting the mir socket after unity8 makes it
<kdub> mterry, ah, okay
<mterry> kdub, thank you for looking!
<kdub> yep, no problem
<kdub> mterry, MIR_SERVER_CONNECTOR_REPORT=log also has a helpful line about where mir creates the socket too
<rsalveti> alf_: ogra_: libhybris is not providing that because we decided (a bunch of months ago) that going with updates-alternatives was actually better
<rsalveti> and removing mesa is not that trivial actually, I think we might have deps issues with some other packages
<rsalveti> but we can try I guess
<rsalveti> something we can try before rtm I'd guess
<rsalveti> but it might be tricky
<rsalveti> maybe we can ask help from foundations
<ogra_> yeah
<ogra_> rsalveti, i asked pat to actually organize a cross team event to review the seeds/manifests before RTM
<rsalveti> great
<ogra_> i guess we should just do it then
<ogra_> or at least inspect it
<rsalveti> but mesa is so core that it might not be that trivial
<ogra_> yeah, i have no high hopes
<rsalveti> just sucks that mesa brings a bunch of extras
<ogra_> definitely ... that drm crap is annoying
<ogra_> (and so bloated)
<rsalveti> yeah
 * ogra_ remebers we are fighting drm deps since the arm team startd 
<ogra_> thats like 4 years already .... still no solution
<racarr> is everything failing CI due to this lxc-android-config stuff now?
<racarr>  / are the appropriate people notified
<kdub> hmm, I saw that this morning for the 1st time on a RAOF branch
<kdub> is it happening everywhere?
<kdub> racarr, ^^
<racarr> kdub: It happened to your branch now
<racarr> and my branch yesterday 2 times
<racarr> in a row
<racarr> seems all over :(
<racarr> fix-1348330 I mean
<racarr> has there been a change in the partitioning setup that one of the makos hasn't received (shot in the dark lol...)
<racarr> not really sure what could be goiung on
<kdub> racarr, yeah, seems dpkg is trying copy cross-partition, and the device won't let it
<kdub> for lxc-android-config
<racarr> mm
<racarr> robotfuel: Are you still master of the mediumtests-runner-mako ?
<racarr> I think we need to remove the dist-upgrade from the CI job
<racarr> e.g. lxc-android-config isnt supposed to be runtime upgraded
<robotfuel> racarr: josharenson took that over I think. I can take a look though
<josharenson> robotfuel, it can probably be removed.. It was there when glmark2 required adding a ppa
<josharenson> oh wait
<josharenson> no I'm not sure why it was there...
<racarr> I think it just seems like a good idea right
<racarr> dist upgrade why not
<racarr> and someone forgot it wasnt safe on the phones (I mean I have seen this CI output dozens of times and never remembered lol)
<racarr> if we don't want to mess with it upgrading the makos may be enough to fix things for now...not sure of the timing
<josharenson> yeah it was in the script to begin with... what could it hurt to remove it?
<racarr> of last promotion/the lxc-android update
<josharenson> I'll remove it now, and watch the builds
<racarr> uhhh
<racarr> I don't think it could hurt anything
<racarr> just have to make sure the makos are kept up to date
<racarr> with images
<racarr> not sure how that is handled
<josharenson> racarr, uh I don't see a dist upgrade happening... grep agrees, let me look closer
<josharenson> at least in the mir-medium-test-runner-for-jenkins job
<racarr> josharenson: https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/2386/console
<racarr> + apt-get dist-upgrade -y --force-yes
<racarr> btw ive always wondered what is a medium test
<racarr> lol
<josharenson> racarr, I see it there, but its not in the lp project that I have commit access to
<racarr> ah
<josharenson> and I also have no idea what a mediumtest is
<josharenson> we should be running hardtests
<racarr> lol
<josharenson> anyways, robotfuel, you know where the dist-upgrade comes from?
<robotfuel> it might be in the jenkins job
<robotfuel> it was from a long time ago :P
<racarr> looks like its part of some "preinstall" step
<robotfuel> racarr: josharenson http://bazaar.launchpad.net/~mir-team/+junk/mir-medium-test-runner-for-jenkins/view/head:/mir_install_packages.sh is where it's at
<robotfuel> line 18...
<racarr> :)
<josharenson> robotfuel, so I'm very confused now... Is the jenkins job pointing to the project in ~josharenson/+junk/ or ~mirteam/+junk
<josharenson> because my version of the file doesn't have that
<robotfuel> josharenson:  lp:~mir-team/+junk/mir-medium-test-runner-for-jenkins is in the job config
<josharenson> robotfuel, I thought we changed that in Malta?
<kdub> josharenson, robotfuel, racarr kinda trailed off... but is that problem setting up the lxc-android-config still ongoing? https://jenkins.qa.ubuntu.com/job/mir-mediumtests-utopic-touch/
<kdub> trying to figure out when its worthwhile to retrigger landings
<josharenson> kdub, I didn't make any changes, so its probably still happening.. Since the issue isn't part of the single lp repo I have access to, there isn't anything I can do I don't think :-/
<kdub> josharenson, ack, I'll go agitate over in #ubuntu-ci-eng
<josharenson> gl
<racarr> Is anyone using sbuild to cross compile mir?
<racarr> I am having difficulties... g++-4.9:armhf : Depends: gcc-4.9:armhf (= 4.9.1-5ubuntu1) but it is not going to be installed
<kdub> i've tried with sbuild, but havent had much luck
<racarr> cross-compile-chroot isnt working for me anymore either :(
<racarr>   The C compiler "/usr/bin/arm-linux-gnueabihf-gcc" is not able to compile a
<racarr> simple test program bla bla bla
<racarr> but blank output
<kdub> racarr, did you do the transition to 4.9?
<kdub> i had to like configure the alternatives to get it going a bit ago
<racarr> kdub: Hmm? On the host or in the chroot. This is a new chroot.
<racarr> host is 4.9
<kdub> host, right
<kdub> lemme try to regenerate the chroot from devel, a few mins
<racarr> kdub: Thanks :)
<fginther> kdub, moving here now... Right now, the disabled test will likely cause all MPs to fail. Is it better to remove the test and allow MPs to pass?
<kdub> fginther, I guess camako or kgunn_ should make that call
<kdub> although I'm becoming a bit backlogged, I'd prefer to wait
<fginther> camako, kgunn_, to catch you up. the mir-mediumtests-runner-mako test is causing a new version of adbd to be installed. This will wedge the phone and require a human to restart it. I've had to disable the test so that all of the phones don't die
<fginther> a new image is likely to resolve this, allowing for a proper fix to be implemented to deal with this problem the next time
<kgunn_> camako, i defer to you, but kinda feels like we should catch the next image
 * camako is looking at the script
<camako> kgunn_, everyone on the team runs the tests that this script runs (and more) on a regular basis.. so it's ok for a while..
<kgunn_> camako, you bet, that argument makes sense
<camako> kgunn_ this is the script I was looking at before the release... It has other problems as well, e.g. demos don't work
<kgunn_> ack
<fginther> camako, kgunn_, so the request is to continue testing MPs, but remove this test until the next image?
<camako> fginther, I think it's fine.. what 's the ETA on the image?
<fginther> camako, about 6 hours
<camako> fginther, not a problem
<camako> fginther would you mind giving me a heads up when you've reenabled it?
<kgunn_> ok, still having fun-with-computers TM...rebooting
<camako> fginther, also , the 0.4, and 0.5 specific scripts can now be removed.. We'll soon need 0.7 :-) (will let you know when)
<fginther> camako, sure. If for some reason the next image doesn't contain the expected version of adbd, I'll need to keep it disabled. Will give you a notice either way
<fginther> assuming the image arrives before I go to bed tonight (which it should0
<camako> fginther, np, I'll change the title on IRC/mir to let people know that they need to run the tests manually until further notice
<racarr> fginther: There were other issues before the new version of adb being installed, i.e. upgrading lxc-android-config
<racarr> which apparently should never be done
<fginther> ugh
<racarr> so I think the problem is dist-upgrade being run on
<racarr> the phones
<racarr> as part of CI
<racarr> right? It's just not safe
<racarr> and I don't think there is any particular need to do it
<fginther> racarr, In that context I agree, although I've heard it argued the other way that without a dist-upgrade it's missing potential bug fixes, etc.
<racarr> hmm
<fginther> racarr, I'm not even sure if this was pulled in due to a dist-upgrade (I assume you are right, but haven't checked yet)
<racarr> yes perhaps not
<racarr> the lxc-android-config was
<racarr> maybe we need
<racarr> a blacklist of packages
<racarr> not to upgrade
<racarr> i.e. the script can, apt-get update, apt-get dist-upgrade --simulate or whatever it is
<racarr> remove lxc-android-config, adb, etc
<racarr> upgrade all remaining packages
<fginther> racarr, right, that would be an option. Sure we can figure out some way to avoid insalling those
#ubuntu-mir 2014-08-14
 * duflu falls into the obsession of finding new ways to reduce latency again
<anpok> this time using an organic lvds interface?
<duflu> anpok: Sounds difficult to patch into a stable release
<greyback_> It seems necessary that MIR_SERVER_NAME must be set to something in order for a nested client to work. That expected?
<greyback_> aha no, USC depends on it
 * alan_g hates it when compiler optimizations affect behaviour (especially the result of tests)
<AlbertA2> Any review volunteers for these USC fixes?
<AlbertA2> https://code.launchpad.net/~albaguirre/unity-system-compositor/fix-1353647/+merge/230370
<AlbertA2> https://code.launchpad.net/~albaguirre/unity-system-compositor/fix-1230345/+merge/230844
<AlbertA2> mterry: ^
<mterry> AlbertA2, OK
<mterry> AlbertA2, in the second one, the timeout-over-dbus one, values <=0 are ignored.  We don't want them to disable a timeout?
<AlbertA2> mterry: yeah I guess it should be possible, but needs a bit of refactoring so we can disable each individually
<mterry> AlbertA2, in the other merge, why split acquired_sys_state into two fields?  With (!requested_suspend_blocker || pending_suspend_blocker), you are allowing for calling requestSysState twice and overriding your existing cookie, aren't you?
<AlbertA2> in case powerd is not available and there's a pending request to block suspend basically
<AlbertA2> for example if powerd crashes...and we turned on the screen
<AlbertA2> and the interface is not available but will in the future
<AlbertA2> or when booting when powerd may not yet be available, we issue the suspend block call when it does become available
<mterry> AlbertA2, but if you see that powerd comes back up, you just clear the requested_suspend_blocker and sys_state_cookie fields and request it again, right?
<mterry> I'm not seeing why you would need the pending field
<AlbertA2> mterry: oh so it's because I'm not getting the serviceUnregister call if powerd restarts or crashes...I dunno why...
<AlbertA2> so
<AlbertA2> The pending flag is kinda used to force to issue the call again, since the internal state in powermediator is out of sync
<mterry> AlbertA2, well...  you don't necessarily *need* the unregister call.  We can just pay attention to the register calls
<mterry> AlbertA2, but any time you would set pending=true, why not just instead set requested=false?
<mterry> AlbertA2, two fields complicates the logic and means that the code can (if requested=true and pending=true) request a second cookie and forget it requested the first
<AlbertA2> mterry: yeah I thought I had a reason..but I don't see why it needs to be two fields...
<AlbertA2> let me simplify that then
<AlbertA2> mterry: oh, I think I remember...
<AlbertA2> mterry: in the case that powerd is not yet available...I wanted something to tell me
<AlbertA2> in case the suspend block call was issued
<AlbertA2> that we needed to request a suspend block...
<mterry> AlbertA2, but wouldn't requested remain false then?
<AlbertA2> since powerdMediator
<AlbertA2> does not track the screen power state
<AlbertA2> right...but if it has not been requested...
<AlbertA2> then there's no need to actually make the call
<AlbertA2> basically if powerd restarts while the screen is off
<AlbertA2> there's no need to issue the call...
<AlbertA2> but I'll try and make that more clear...
<mterry>  AlbertA2, OK I think I get it.....  But
<mterry> AlbertA2, seems like we should save the desired state in one field.  And whether or not we have a cookie in another (maybe just examine if cookie string is empty).  That way we can always know what to do
<mterry> If we notice that powerd restarted, we can clear the cookie and look at desired state to see if we should make the request
<AlbertA2> mterry: yeah that makes sense...let me see
<smallfoot-> It is impossible to uninstall Mir in Utopic
<smallfoot-> when I try to remove some Mir package, it tries to remove like all packages on the system
<AlbertA2> mterry: updated https://code.launchpad.net/~albaguirre/unity-system-compositor/fix-1353647/+merge/230370
#ubuntu-mir 2014-08-15
<camako> 0.6.1 ppa ready in silo 4... This is a mir only landing (no ABI breaks)... Here are the instructions for testing... http://pastebin.ubuntu.com/8049567/
<racarr> camako: A landing without ABI breaks?!?!
<racarr> *choirs of angels sing*
<camako> I'm sure we have broken something... Just not the ABIs :-)
<racarr> "Didn'
<racarr> t break the ABI. Diodn't break the ABI. There may be a few bad commits. But I didn't break the ABI" to the tune of https://www.youtube.com/watch?v=3TY8vLI4buo
<racarr> ...that's all...
<racarr> :p
<camako> :-) "There ain't no bugs in Mir" would work too...
<duflu> Anyone else notice how stable the "8" in libmirclient8 is? :)
<duflu> libmirclient has the luxury of C to keep in stable. But C++ can be just as stable... we're just not there yet. I suspect we could still move a bunch of headers out of include/ and into src/ so they don't contribute to any ABIs any more
<duflu> camako: In exciting news, I think I've got the "butter" branch where I want it. Seems to improve the usability of the phone quite nicely
<camako> duflu, sounds good.. Folks can start reviewing, then
<duflu> I had to sacrifice a little bit of lag to get scrolling up from 48Hz to 60Hz, but it feels nicer now
<duflu> Still, much less laggy than the phone is right now
<camako> duflu, nice! I think you can empirically tell the difference, right? Any caveats?
<duflu> camako: Yes, it's all based on human eyes now. No caveats any more, just improvement :)
<camako> ok good... let's hope for a smooth review :-)... If you can generate some before and after numbers, it'd help the review process
<duflu> You may also find MIR_CLIENT_INPUT_RECEIVER_REPORT now mentions negative lag for some input events. This is correct, because they're predicted a few milliseconds into the future
<camako> hah interesting
<camako> hey I saw you marked some 0.7.0 targeted bugs as "Fix released"... I had done some too.... thanks for that...
<racarr> duflu: I think...there are a few problems
<racarr> with the branch, but im not 100% finished studying yet
<racarr> but I think, if you look at
<racarr> droidinput::MotionEvent and
<racarr> the way historical pointer coordinates are added
<racarr> where 1 event will include
<racarr> multiple pointer coordinate samples over time
<racarr> I think the likely effect of the branch is to
<camako> Hmmm this failed twice now if anybody wants to take a look : https://code.launchpad.net/~mir-team/mir/0.6/+merge/230879/comments/561324
<racarr> drop half of pointer samples
<racarr> hence why you see
<racarr> something close to 50 fps (half the 100hz input rate of most touch screens)
<racarr> and then I have no clue where the 60hz is coming from. but may be close to coincidental from the 48hz because of the frame time tweaking
<racarr> the idea with the resampling is
<racarr> because of the mixed refresh rate of the monitor and the input device
<racarr> sometimes you will get
<racarr> frames where you have two touch samples
<racarr> which, say in the case of a scroll, means a greater scroll
<duflu> racarr: That was true for the old branch. The new one has consumeBatches=true and a sample window that moves every 16ms. Hence 60Hz
<racarr> per frame
<duflu> racarr: So essentially you have all the raw events from during the frame contributing to a single prediction, single cooked event
<duflu> Devices seem to vary a lot. Nexus4 produces events at 96Hz whereas my mouse is 125Hz
<racarr> no
<racarr> its multiple interpolated pointer samples
<racarr> in one event
<racarr> and we are ignoring all
<racarr> except the last
<duflu> racarr: OK, if you've got a practical suggestion for improvement that works please put it in the review
<racarr> duflu: I am still studying like I said...just wanted to fill you in one what I had learned
<racarr> duflu: The thing is...ok so if you imagine a scroll
<racarr> then you can think of say, the displacement, which on a given frame, i.e. how far it drags behind
<racarr> the finger
<racarr> so the way your branch is configuring things, is lowering
<racarr> the minimum value of the displacement (i.e. the latency)
<racarr> on the other hand, butter on android, intentionally suffers
<racarr> 1 frame latency in order to be able to
<racarr> resample the 100hz display smoothly to frame time, such to
<racarr> minimize the CHANGE in the displacement
<racarr> which is like jerk, or some such.
<duflu> racarr: Yes, I realized I had to suffer one extra frame of latency to make the batch size sufficiently big for a nice experience.
<duflu> That's the big change in yesterday's version
<duflu> The new version does indeed minimize the change in displacement (slightly higher latency but smoother scrolling)
<racarr> I think it's dropping most touch samples though -.-
<duflu> racarr: The raw samples are all used in InputConsumer to affect the resampled curve. Where is the "drop"?
<racarr> duflu: http://developer.android.com/reference/android/view/MotionEvent.html
<racarr> For efficiency, motion events with ACTION_MOVE may batch together multiple movement samples within a single object. The most current pointer coordinates are available using getX(int) and getY(int). Earlier coordinates within the batch are accessed using getHistoricalX(int, int) and getHistoricalY(int, int). The coordinates are "historical" only insofar as they are older than the current coordinates in the batch; however, they ar
<racarr> its
<racarr> interpolate
<racarr> not extrapolate :)
<racarr> the drop is
<racarr> clients want 100hz or so of touch samples for computing
<racarr> acceleration, like the device has
<duflu> racarr: I can see some clients might want a configurable option to get the raw event stream. But are you saying that the cooked event stream should be faster than the frame interval?
<duflu> That's a nice ideal, but I'm not sure InputConsumer works that way..?
<racarr> I'm pretty sure it does ;)
<racarr> I mean thats how we are using it the only problem is
<racarr> we are literally ignoring the historical pointer coords.
<racarr> which would give us
<racarr> the 100hz rate
<racarr> I think we would find if we enabled the 100hz rate without
<racarr> proper frame timing
<racarr> the jerk would come back
<racarr> because we would have the problem where
<racarr> you get multiple events per frame
<duflu> racarr: I'm still a bit confused. I would really like to get a higher cooked event rate. If you know how to do it without the experience degrading (for me it mostly means no resampling benefit) then please point out the required code changes
<racarr> I think the answer is use the historical coordinates + real frame timing :) but
<duflu> It's easy to deliver events to clients faster. But so far that always means a worse looking experience
<racarr> im still trying to figure it out completely
<duflu> racarr: I would love to get a merge proposal for any improvements to try out
<duflu> Although I might ignore that branch for the week now. Not enough time left to dive back in. It usually sucks me in for days at a time of obsessive testing
<racarr> :) ill have something next week
<racarr> im going to try and work up a test that lets you pick a
<racarr> refresh rate and an input streaming rate
<racarr> and then simulates a smooth scroll
<racarr> and measures
<racarr> the displacement from "ideal scroll"
<racarr> and then we can automatically test various
<racarr> parameters, etc.
<racarr> I mean obviously still some manual testing will be required but
<racarr> it should give us a nice method to be sure we are making things better
<duflu> Yeah, some trustworthy automation would be good. I've developed a distrust of the input latency metrics we have right now
<duflu> Kind of like the bogus "render time" argument :)
<duflu> We need to work on building more reliable metrics
<racarr> Yeah...its hard :( lol
<racarr> android and ios arent exactly jumping to publish their
<racarr> tips and tricks on accelerating
<racarr> your input stack
<racarr> hahaha
<racarr> *pictures cosmo magazine at grocery store checkout: 10 tips and tricks for accelerating your input stack*
<RAOF> Bah. Our CI fails in the most inscrutable way. The thing passes the tests _locally_, damnit.
 * duflu needs to fix up and get his client perf report branch for review. That makes a good start
<RAOF> Why is cmake such unmitigated garbage?!
<duflu> RAOF: Because it's an evil conspiracy to annoy you
<duflu> DMake is better
<duflu> And EMake will solve everything
 * duflu misses pure GNU make. Unfortunately it's too sharp an instrument that people constantly cut themselves on it
<duflu> Or just mess it up
<kdub> alan_g, I'm thinking about: https://code.launchpad.net/~kdub/mir/testable-surface-tracking/+merge/230814/comments/561452
<alan_g> kdub: not clear? Sorry
<kdub> well, no, clear enough
<kdub> I guess i'm just thinking about testing now
<kdub> and how SessionMediator test is really somewhat of an integration test
<kdub> or rather, if we did hoist the SessionSurfaceTracker, it would be more of an integration test
<kdub> of two objects composed together
<kdub> and am wondering if you thought that was wrong-headed thinking
<alan_g> Not so - it would simply not test their interaction
<alan_g> And I don't think we need to require that interaction
<alan_g> Analogy: "vector" gets tested. Vector gets used in cache. We don't test that cache uses vector a specific way. Just that it works.
<kdub> alan_g, hmm, okay
<kdub> I'll keep thinking about it, but it seems reasonable
<kdub> and a good, small way to shift my own thinking about tests
<kdub> thanks
<alan_g> yw
<alan_g> And the comment doesn't say the MP is wrong, just suggests that it could be an interface too far.
<kdub> sure, I'm beginning to think that too
<mibofra> hi guys, can anyone help me to start mir/lightdm on ubuntu touch? (http://paste.ubuntu.com/8054602/ the log)
<greyback_> mibofra: that's not a very useful log, what has  /var/log/lightdm/unity-system-compositor.log ?
<alan_g> Hmm "[+1.16s] DEBUG: Process 25466 terminated with signal 11" - a segfault doesn't look promising
<greyback_> mibofra: what device are you testing it on?
<mibofra> greyback_, http://paste.ubuntu.com/8054953/
<mibofra> on a samsung galaxy s3 (i9300)
<mibofra> but anyway maybe I've to explain my setup xD
<greyback_> mibofra: I suggest for initial debugging, you install the "mir-demos" package and try out mir_demo_server_basic and see if it crashes or not. If it does crash, we'd appreciate a backtrace
<mibofra> ok anyway
<mibofra> greyback_, I've a strage setup. I've used to have a debian bootstrapped and chrooted on android (cyanogenomd). With debian I could start the X server (after stopped surfaceflinger), and I could use X and it worked fine, so I've decide to try with ubuntu touch
<mibofra> in the same way
<greyback_> mibofra: interesting!
<mibofra> I can start pulseaudio, ping, traceroute, use apt, start dbus and more, but I can't start lightdm
<mibofra> greyback_, my goal is to use chroot to use android as layer to support the hw
<racarr> Good morning
<mibofra> more or less if it will work in this way any arm7 device with android is supported by ubuntu touch
<mibofra> and because android and the bootstrapped system share /dev /sys /proc ecc as I can see a device from chroot, if for example I use xboxdrv on ubuntu chrooted I can use the device on android for example
<mibofra> but the only obstacle is lightdm that won't start xD
<mibofra> (because debian with X is great, but unity fits better the smartphone that's why I wanted to try this possibility)
<greyback_> sure. unity-system-compositor is crashing for you, which most likely means mir is crashing for some reason
<mibofra> greyback_, anyway let's try the dem
<mibofra> *demo
<kgunn> you could try running the mir integration tests to just validate the android-driver working
<mibofra> I've launched mir_demo_server_basic without options, but I can't see anything, but I don't receive errors and the applications continue to run
<mibofra> *continues
<mibofra> greyback_, kgunn lightdm launches also [+0.81s] DEBUG: Session pid=26012: Running command /usr/sbin/ubuntu-touch-lightdm-session ubuntu-touch-session . If I launch it I receive this: http://paste.ubuntu.com/8055058/
<mibofra> but I can't see anything
<mibofra> (note the upstart bridge, I'm into chroot so I can't use upstart or init or similar)
<greyback_> mibofra: mir_demo_server_basic runs a basic mir server - it has nothing to draw yet. With it running, execute mir_demo_client_flicker or something else
<mibofra> ok
<greyback_> kgunn: how does one run the integration tests?
<greyback_> I don't even know where they live
<kgunn> greyback_: i've only ever run them in a build dir from a local native build
<kgunn> uh...
 * kgunn goes digging
<mibofra> greyback_, I receive something like this and continuing http://paste.ubuntu.com/8055089/
<mibofra> but I can't still see anything
<kgunn> apt-get install mir-test-tools
<kgunn> ./mir_unit_tests
<kgunn> ./mir_integration_tests
<kgunn> ./mir_acceptance_tests
<mibofra> *I hope it uses the framebuffer (/dev/fb0 or /dev/grapichs/fb0) as X
<kgunn> AndroidBufferIntegration.*
<kgunn> Tests basic gralloc (gpu buffer allocation HAL) usage
<kgunn> AndroidInternalClient.*
<kgunn> tests that the unity8 surface can establish an EGL context
<kgunn> AndroidGPUDisplay.*
<kgunn> Tests that the primary and fallback display HAL works, and can render with OpenGLES.
<kgunn> TestClientIPCRender.*
<kgunn> tests that the client can receive buffers over IPC and draw to them with software and OpenGLES.
<kgunn> mibofra: the integration & acceptance tests are the interesting ones ^
<mibofra> ok
<kgunn> can probably skip the unit tests
<kgunn> kdub: ^ still accurate ?
<camako> mibofra, you wanna stop unity8 and lightdm
<kdub> kgunn, yes
<camako> before starting basic server
<mibofra> camako, they are not started
<greyback_> camako: it wasn't even running for him
<kgunn> camako: i think he's on a weird setup...like he's in android, chroot'd into starting ubuntu
<kgunn> but he's got SF stopped
 * kgunn wonders if stopping sf is enough to release the hw ?
<alan_g> kgunn: if server_basic doesn't exit with an error it probably is
<kgunn> yeah...and he got x to work in his chroot
<kdub> it should be
<mibofra> http://paste.ubuntu.com/8055122/ mir_unit_tests , http://paste.ubuntu.com/8055134/ mir_integration_tests , http://paste.ubuntu.com/8055170/ mir_acceptance_tests  but I'm not really sure if the tests were finished.
<mibofra> (or it was only my impression as there were not other output)
<mibofra> kgunn greyback_
<mibofra> (there isn't a way to start unity8 on Xorg, right? just to know)
<alan_g> A working draft of a symbol map for libmirserver is a good place to end the week. lp:~alan-griffiths/mir/initial-symbol-map-for-libmirserver
<mibofra> kgunn, there is a config file for mir like xorg.conf for x ?
<racarr> No, there are a few options
<racarr> you can see mir_demo_server_basic --help for example
<mibofra> ok
<racarr> probably  nothing that makes it work on a device where it doesnt
<mibofra> racarr, just to know how much it is configurable
<mibofra> racarr, anyway a demo works
<mibofra> mir_demo_standalone_render_to_fb
<mibofra> kgunn
<mibofra> I can see something on the phone
<anpok> those are the builtin opions for default components.. you can override pretty much everything through the mirserver api
<mibofra> ok
<mibofra> mir_demo_standalone_render_to_fb writes on the framebuffer, right?
<kgunn> cool you see something, and yeah
<mibofra> kgunn, so can I force mir (with lightdm) to write on the framebuffer?
<mibofra> uhm with mir_demo_standalone_input_filter I can have inputs form the touchscreen and more
<kgunn> mibofra: what do you mean force ?
<mibofra> so it works more or less
<anpok> mibofra: hm that example uses egl/glesv2 and draws some stuff..
<mibofra> kgunn, use the framebuffer unaccelerated
<anpok> it is similar to a mirserver drawing with egl/glesv2
<anpok> it is accelerated
<mibofra> anpok, I think it's using the software rendering
<kgunn> mibofra: no, i thot that test just writes to frame buffer directly rather than going via hwc
<kgunn> with mir on android there's really no sw rendering afaik
<kgunn> kdub ^ sw rendering on mir on android ?
<mibofra> kgunn, the matter is that the drivers are loaded, android use the hw rendering, but I think X or other wants another drivers to work (for mali400 gpu there are the drivers for x)
<racarr> mibofra: Mir has no support for software rendering via writing to /dev/fb like your X drivers are working
<racarr> almost certainly you are using the android drivers
<racarr> if the demo works
<mibofra> ok
<mibofra> racarr, the demo works
<racarr> what about running demo_server_basic and one of the clients? e.g. mir_demo_client_fingerpaint
<kdub> yeah, writing to the fb directly wont work
<kdub> well, lets just say its not the path thats supported :)
<mibofra> with mir_demo_client_fingerpaint I don't receive any output on the screen, but the executable doesn't give to me errors and it doesn't quit
<mibofra> *if I don't stop it
<kdub> have you tried mir_demo_standalone_render_to_fb?
<mibofra> kdub, it works
<kdub> oh great
<kdub> thats the tricky part
<mibofra> ok I'm going to have dinner
<mibofra> see you later guys
<racarr> :)
<mibofra> re-hi xD
<racarr> Lunch!
<mibofra> kdub, racarr kgunn just for curiosity I've installed also xorg and lxde, in a glxgears test, debian used to do 60fps more or less, ubuntu touch 91 :D
<mibofra> anyway
<mibofra> 1|root@m0:/root # glxinfo -display :0 | grep OpenGL
<mibofra> OpenGL vendor string: Mesa Project
<mibofra> OpenGL renderer string: Software Rasterizer
<mibofra> OpenGL version string: 2.1 Mesa 10.2.5
<mibofra> OpenGL shading language version string: 1.20
<anpok> \o/
<anpok> what device are you using?
<mibofra> a samsung galaxy s3
<mibofra> the gpu is a mali 400
<kgunn> yep good to hear
<mibofra> uhm kgunn I get something useful (I think)
<mibofra> kgunn, racarr, kdub http://paste.ubuntu.com/8056495/
<kdub> mibofra, you have to use upstart
<kdub> "service lightdm restart"
<kdub> as the phablet user
<mibofra> kdub, I've tried but it doesn't work
<mibofra> kdub, it's set to autologin with phablet user
<kdub> just running like that won't work, as it has to be started with certain arguments
<mibofra> ok but that's lightdm : http://paste.ubuntu.com/8056507/
<mibofra> kdub
<kdub> well, the X server shouldn't be starting at all
<kdub> don't know what might be going wrong there though
<anpok> mibofra: is there no unity-system-compositor.log in /var/log/lightdm/ ?
<mibofra> kdub, the x server start on the framebuffer
<mibofra> anpok, yep but it isn't very useful
<mibofra> anpok, it's this http://paste.ubuntu.com/8056543/
<mibofra> (anyway, if you have anything more important to I can leave :) , just I won't to disturb)
<mibofra> *I don't want disturb
<mibofra> (xchat autocorrect xD fantastic)
<anpok> you could pretend being lightdm .. by calling unity-system-compositor with --from-dm-fd 0 --to-dm-fd 1 if you want to debug that
<mibofra> anpok, in fact I don't pretend the problem it's light xD
<mibofra> but I've to use light to launch it, that's the poin
<mibofra> *point
<anpok> why is that a problem?
<mibofra> anpok, it isn't a problem, I like also the startx approach, so I don't have to use a display manager to run the display server. But mir is really all the package display manager + libraries + greeter
<anpok> mir provides the libraries for that.
<mibofra> anyway some demos works anpok kdub like the framebuffer one
<mibofra> some like mir_demo_client_eglflash go in segfault
<anpok> mibofra: try launching mir_demo_server_shell --file /tmp/somwhere  ... then mir_demo_client_eglfingerpaint -m /tmp/somewhere
<kdub> mibofra, the framebuffer one drives the display via HWC
<kdub> not the /dev/fb0
<mibofra> kdub, I've understood
<mibofra> anpok, I can find the mir_demo_client_fingerpaint not the egl one
<anpok> oops
<anpok> typo
<mibofra> ah ok
<mibofra> anpok, anyway I launch a test like this one and I don't receive errors or similar, only the binary that keeps running without output on the screen
<anpok> oh
<mibofra> eh anpok , the only demo that works with an output on the screen is mir_demo_standalone_render_to_fb at the moment
<anpok> mibofra: to solve that you need a few hours out of kdub or AlbertA
<mibofra> fantastic xD
<mibofra> anpok, and if they want
<kdub> mibofra, try
<kdub> ./mir_demo_server_basic --launch-client "./mir_demo_client_egltriangle"
<mibofra> ok
<mibofra> kdub, sh: 1: ./mir_demo_client_egltriangle: not found
<kdub> probably in /usr/bin
<mibofra> ah lol ok don't worry
<mibofra> yes I didn't see the point kdub sorry
<mibofra> kdub, Current active output is 720x1280 +0+0
<mibofra> Server supports 3 of 6 surface pixel formats. Using format: 2
<mibofra> Surface 0 DPI
<mibofra> but I don't see anything
<kdub> okay, so something is locking up probably
<kdub> try adding --msg-processor-report log to the end and pastebinning the out
<mibofra> kdub, --msg-processor-report on/1 or similar?
<mibofra> only adding the option I get the help.
<mibofra> with --msg-processor-report 1 or on I get segfault
<kdub> has to be "log"
<mibofra> kdub, yep I've noticed now that on the help
<mibofra> kdub, http://paste.ubuntu.com/8057321/
<kdub> hmm, so the client's blocking
<kdub> could you pastebin /system/bin/logcat?
<mibofra> kdub, I can do a better thing, if you have netstat I can send you the logcat output in realtime
<mibofra> if you want
<mibofra> netstat lol, kdub I wanted to mean netcat
<kdub> mibofra, lets just stick with pastebin, dont know that one
<mibofra> kdub, ok
<mibofra> kdub, I've passed logcat output to pastebinit
<mibofra> let's wait until it finishes
<mibofra> (I hope it will finish)
<mibofra> kdub, anyway I've stopped any service can lock hw, like the media manager, zygote, surfaceflinger, audioflinger and drm
<kdub> it wont finish
<mibofra> *of the android system
<mibofra> kdub, I'm pasting
<mibofra> kdub, http://paste.ubuntu.com/8057442/
<kdub> cool, no errors
<kdub> does
<kdub> ./mir_integration_tests --gtest_filter="TestClientIPCRender.*"
<mibofra> kdub, a thing, I've the executables in /usr/bin and /usr/bin is in the path
<mibofra> so you can omit the ./
<mibofra> kdub, http://paste.ubuntu.com/8057461/
<kdub> interesting, the client rendering is working too
<kdub> not sure what's blocking then
<mibofra> kdub, <mibofra> http://paste.ubuntu.com/8055122/ mir_unit_tests , http://paste.ubuntu.com/8055134/ mir_integration_tests , http://paste.ubuntu.com/8055170/ mir_acceptance_tests  but I'm not really sure if the tests were finished.
<mibofra> tests I've done some hours ago
<kdub> no, the integration tests don't finish for some reason
<kdub> and the MultiThreadedCompositor test is hanging
<mibofra> kdub, I've send a ctrl+c after a while because I thought they were frozen
<mibofra> but I can repeat the test and I can wait them finish
<mibofra> *tests
<mibofra> ah kdub yep the integration tests were aborted but I've not aborted them
<mibofra> good night kdub and thanks
<mibofra> see you
<mibofra> good night everyone and thanks too
<Nothing_Much> I forgot whether my question was answered or not, so... Does Mesa need patches for XMir to work from the Oibaf PPA?
<racarr> Nothing_Much: First time hearing about the oibaf ppa so can't be sure
<racarr> if Mir works but XMir does not Mesa will not need additional patching
<racarr> The DDX drivers, i.e. xserver-xorg-video-intel
<racarr> do require a patch and if xmir isnt working but mir is
<racarr> thats a good guess
#ubuntu-mir 2014-08-16
<mibofra> hello guys
<mibofra> guys, a thing, I'm trying to build from source mir. The mesa libs/binaries in the packages provided in the repo with ubuntu touch are already patched?
<mibofra> or have I to recompile the mesa too?
<mibofra> *the mesa exes/libs
<mibofra> RAOF, http://unity.ubuntu.com/mir/building_source_for_pc.html (I see your name on the git repo so), Do I need to compile also mesa after compiling mir, or the packages provided on ubuntu touch are patched?
#ubuntu-mir 2014-08-17
<RAOF> mibofra: Yeah, the mesa packages in the archives (so, Ubuntu desktop and Ubuntu touch) have Mir support. There's no need to rebuild them
<memeka> hi; is it possible to run mir on top of android hwcompositor in linux?
<memeka> i have libhybris working (test_hwcompositor works) ... and wondering if I can put Mir on top of it
<memeka> anyone?
<mibofra> guys anyone remembered me?
<mibofra> xD
<mibofra> *remember
<mibofra> I've done some tests
<mibofra> anpok, :)
<mibofra> (happy to see you)
<mibofra> (someone who maybe remember me)
<mibofra> (*remembers)
<mibofra> racarr, hi
<anpok> mibofra: hm?
<anpok> australias watch starts soon
<mibofra> anpok: go watch it xD
#ubuntu-mir 2015-08-10
<duflu> Wow 0.15.0 is getting quite big now it's rebased on the latest Mir 0.16 code... https://launchpad.net/mir/+milestone/0.15.0
<zzarr> hello!
<zzarr> is there a fix for the missing mouse cursor on Ubuntu Touch (I have a Meizu MX4 Ubuntu Edition)
<greyback> zzarr: it's in progress, we need to finish reviewing it and integrating it
<zzarr> so I take it there's no simple solution (like running some magical lines in a terminal)
<zzarr> greyback: do you have a clue when it's done?
<greyback_> zzarr: within a couple of weeks hopefully
<zzarr> that quick, that's impressive :)
<alan_g> kdub: is the "MIR_USE_BIONIC" test in 3rd_party/android-input/android/CMakeLists.txt actually useful these days?
<kdub> alan_g, no
<greyback_> kdub: hey, did you manage to find time to look into the problem I found with multimonitor in silo0?
<kdub> yeah, spent the morning on it, no breakhtrough
<greyback_> ok, if I can help in any way, let me know
<kdub> greyback_, okay, thakns
<ted> Really interesting demo of Vulkan: http://blog.imgtec.com/powervr/gnomes-per-second-in-vulkan-and-opengl-es
<ogra_> lol, is gnomes per second the bogomips of graphics engines now ?
<ted> I hope so
<RAOF> bschaefer: Any reason why we're not talking here, by the way?
<RAOF> Probably, yes.
<bschaefer> RAOF, o no reason at all
<bschaefer> are there any other tests that do this sort of thing? I looked around and this i was the first i saw of a udev record
<bschaefer> being used
<bschaefer> or rather the load_device_evemu
<bschaefer> RAOF, also I cant really test the cookie factory with a demo since the demo uses the android lexer which is in the client code :( for events
<RAOF> Yeah, this is the first test that uses it.
<RAOF> You might notice that the branch adds the load_device_evemu method :)
<bschaefer> o i missed that part :)
<bschaefer> RAOF, how can i check 100% that the buffer has been posted and is getting input?
<bschaefer> i know i get at lease a surface event right away
<bschaefer> and one when the dev is loaded
 * bschaefer tries to print those events
<RAOF> Check for a mir_surface_focused event.
<bschaefer> i do get a surface event let me check what kind
#ubuntu-mir 2015-08-11
<bschaefer> RAOF, hmm the only thing i can do with a surface event is: MirSurfaceAttrib mir_surface_event_get_attribute(MirSurfaceEvent const* ev);
 * bschaefer thought a new function to check if surface was visible was around
<bschaefer> though: mir_surface_attrib_focus should be set
<RAOF> Right.
<RAOF> You get mir_surface_event_get_attribute, check that it's mir_surface_attrib_focus, and can then mir_surface_event_get_attribute_value, which should be mir_surface_focused.
<RAOF> bschaefer: Hah!
<bschaefer> RAOF, ?
<RAOF> Fun fact: load_device_evemu doesn't wait for the device replay to finish before returning.
<RAOF> Which is sensible.
<bschaefer> RAOF, so the test is finishing before the events get through?
<RAOF> So what's happening is that the test is quitting before the device replay starts.
<RAOF> Yup.
<bschaefer> dang, i like... thought about that
<bschaefer> last week and ended up looking at the udev source code
<RAOF> If you put a sleep after load_device_evemu you get events.
<bschaefer> but stopped
<bschaefer> haha
 * bschaefer was getting focused events
<RAOF> Yup.
<RAOF> So the right thing to do will be to block the test until an input event is received.
<bschaefer> RAOF, is there a reasonable way to get when the replay starts?
<bschaefer> o right thats better
<RAOF> :R(
<RAOF> :)
<bschaefer> sad face its failing
 * bschaefer wonders what he did wrong
<bschaefer> HERE WE ARE: 1439251644004809000 - 14631743400016030123
<bschaefer> its close ...
 * bschaefer doesnt remember where that print statement even is
<bschaefer> whats weird is that print statement isnt even there any more ... hmm why didnt that get recompiled out of there
 * bschaefer most likley forgot to install the changes
<RAOF> :)
<RAOF> Install?
<RAOF> You can run out of the build tree easily.
<bschaefer> yeah
<bschaefer> o really?
<bschaefer> i just usually run off staging
<bschaefer> RAOF, just do a LD_LIBRARY_PATH to where they are built?
<RAOF> Everything's built with a wrapper that sets the right variables.
<bschaefer> RAOF, o so just use that wrapping in bin?
<RAOF> You should be able to do build/bin/mir_unit_tests and have it all run correctly.
<RAOF> Yeah.
<bschaefer> well that makes things easier
<bschaefer> RAOF, i think whats happening is your tests runs off the android lexicon
<bschaefer> which is set to 0
<bschaefer> for the timestamp
<bschaefer> no
<bschaefer> wait...
<bschaefer> T: (18954176 + 12574245) 7571075335272719900 which is
<bschaefer> cookie.timestamp, cookie.mac == calculated mac
<bschaefer> hmm somethings is off somewhere
<bschaefer> as your verify uses the cookie timestamp to get a mac
<RAOF> That would be right?
<bschaefer> yeah it is .. im just wondering whats going on with my mac
<bschaefer> ie. why is my mac not the correct value, as it should either be 0 or a correct value (from what i've done so far)
<bschaefer> so it seems i've either missed a spot, or am doing something wrong :)
<RAOF> Is it just random stack garbage?
<RAOF> If you haven't explicitly set it to something it's quite possible that it's just whatever happened to be on the stack.
<bschaefer> RAOF, right which means i've missed a location
<bschaefer> (in where an event is created)
<bschaefer> which could be in the test code it self :)
<bschaefer>     at /home/bschaefer/src/attestable-timestamps-client/tests/mir_test_framework/fake_input_device_impl.cpp:246
<bschaefer> RAOF, the thing is i already came through here and gave all the mac values a 0
<bschaefer> as it wouldnt have compiled otherwise
<RAOF> Ah, this isn't a fake input device.
<RAOF> This is a fully armed and operational input device.
<bschaefer> RAOF, hmm this is where the code path is coming from for a make event
<bschaefer> on a mir key event
<bschaefer> but still, i set the mac to 0 :)
<bschaefer> unless i just miss placed the mac ...
<bschaefer> with a random uint64
<RAOF> :)
<bschaefer> but i did it after the timestamp, and thats what i did in the fake inptu device
<bschaefer> RAOF, are you saying that we shouldnt be getting the events through the fake input stack?
<RAOF> Right.
<RAOF> I would expect you to get the events through the normal input stack, because that's what load_device_evemu does.
<bschaefer> hmm now i wonder why thats happening...
<bschaefer> right it should be a real input device
<RAOF> It creates a real* evdev device and makes it produce real* events.
<RAOF> *For values of ârealâ which are provided by a LD_PRELOAD shim, but whatever ;)
<bschaefer> did a break on:
<bschaefer> mir::events::make_event(long, std::chrono::duration<long, std::ratio<1l, 1000000000l> >, unsigned long, unsigned int, MirPointerAction, unsigned int, float, float, float, float, float, float)
<bschaefer> best part is i can see:
<bschaefer> mir::events::make_event (device_id=0, timestamp=..., mac=0, modifiers=0, action=mir_pointer_action_motion, buttons_pressed=0, x_axis_value=99, y_axis_value=99,
<bschaefer>     hscroll_value=0, vscroll_value=0, relative_x_value=99, relative_y_value=99)
<bschaefer> soo mac = 0
<RAOF> Why would that get hit at all? We're sending key events, not pointer events.
 * bschaefer finds these functions to have a lot of arguments
<bschaefer> o
<RAOF> Yeah, not my favourite interfacae :)
<bschaefer> i used the wrong one
<bschaefer> RAOF, yeah i find that strange to be honest... as you did a keyboard recording...
<bschaefer> where is the mouse event coming through?
<bschaefer> events::make_event(long, std::chrono::duration<long, std::ratio<1l, 1000000000l> >, unsigned long, MirKeyboardAction, unsigned int, int, unsigned int)
<bschaefer> the right one :)
<bschaefer> RAOF, still coming through the fake input dev
<bschaefer> RAOF, urrg
<bschaefer> RAOF, ignore all of this
 * bschaefer forgot to filter
<bschaefer> and was hitting it on a random other test
<RAOF> :)
<bschaefer> now it makes sense why we hit the pointer break :)
<RAOF> :)
<bschaefer> RAOF, we never actually hit a make event
<bschaefer> for a keyboard action
 * bschaefer goes back to swapping 3 buffers and sleeping 1 second
<RAOF> Run with MIR_CLIENT_INPUT_RECEIVER_REPORT=log and you'll see that you're really getting keyboard events.
<bschaefer> RAOF, thanks gdb is not as friendly it would seem
<bschaefer> strange but good news i think
<bschaefer> SETTING MAC VALUE: 14215524572544855579
<bschaefer> SETTING MAC VALUE: 0
<bschaefer> both those come in at the same time
<bschaefer> (for one DOWN event)
<bschaefer> which; 14215524572544855579
<bschaefer> is the expected value
<bschaefer> soo now to figure out hwy...
<RAOF> :)
 * bschaefer fears its the android lexicon
<bschaefer> RAOF, yes: SETTING MAC VALUE: 17 -- 1
<bschaefer> RAOF, soo whats strange... why do we get a different make_event?
<bschaefer> before the android lexicon?
 * bschaefer needs to figure out the stack a bit better...
 * bschaefer hard coded 17 to be set for the mac only in the android lexicon part
 * RAOF admits that's a bit of the input stack he's not super familiar with.
<bschaefer> RAOF, well sounds like a good part for me to get familiar with :)
<RAOF> :)
<bschaefer> RAOF, im starting to think ... the server generates an event and sends it to the android layer
<bschaefer> which is ripped apart and sent to the client or something
<RAOF> Correct.
<bschaefer> the issue we cant preserve the mac with that...
<bschaefer> since the android layer doesnt have any of that :(
<bschaefer> RAOF, is this to avoid sending events over the wire?
 * bschaefer also doenst really understand the 'wire' very well
<RAOF> We actually have two entirely parallel wires.
<bschaefer> wire being the rpc?
<RAOF> Yeah.
<RAOF> âThe thing which ferries bits from the server to the clientâ
<bschaefer> soo yeah that wont preserve a struct
<bschaefer> that is opaque :(
<RAOF> Yeah, you'll need to poke into the android layer.
<bschaefer> yeah
<bschaefer> RAOF, we cant change the android layer, but maybe theres some unused uint64 somewhere
<RAOF> We've got the protobuf-speaking socket, and one Android socket per surface with input.
<bschaefer> RAOF, we cant can we?
<RAOF> Why can't we change the android layer?
<bschaefer> i've no clue :)
<bschaefer> since its 3rd party
<RAOF> We can (and have) changed the android layer.
<bschaefer> but im not sure how much its sync*
<bschaefer> o cool, well then that makes thinks 100x easier
<bschaefer> things*
<RAOF> It's utterly out of sync; we're never going to try and merge any upstream changes into it.
<bschaefer> RAOF, didnt know that :), cool yeah ill just fix up the android layer and get the client android lexicon accepting the new mac bits :)
 * bschaefer guesses a day or so
<bschaefer> RAOF, thanks for all the info!
<RAOF> Mad c++ request: is it possible to template<class Obj, void (Obj::*mem_fn)(Args...)> ?
<RAOF> THis seems like something that should be possible, but as far as I can tell isn't.
<camako> Hmm calendar won't open... Can someone paste the link for 2/3rd?
<RAOF> https://plus.google.com/hangouts/_/canonical.com/2-3-mir-meeting?authuser=1
<RAOF> Maybe strip the authuser off.
<anpok> RAOF: http://paste.ubuntu.com/12054177/ .. not very convenient..
<RAOF> anpok: Yeah, that's roughly what I thought.
<RAOF> Which is stupid, because this would actually be *really easy* for a compiler to infer.
<RAOF> Anyway, EOD for me.
<anpok> hm .. well rules.. and such..
<anpok> the method ptr needs to be constant.. and the type parameters of it need to be known before .. it is trivial  if you use that as a function parameter though, but then you dont have compiletime method ptr address..
<anpok> anyhow .. decltype constexpr and nested templates are a source of nice clang stack traces
<RAOF> :)
<alan_g> AlbertA: did I do something different than you meant? https://code.launchpad.net/~alan-griffiths/mir/make-mir_demo_server-dlopen-mir/+merge/267498
<AlbertA> alan_g: umm yes. But now I did a clean build locally here...and it didn't help...ummm I wonder if I confused my binary names....
<alan_g> AlbertA: OK. A pity though. Thanks
<AlbertA> alan_g: ah I see... I changed the RTLD options... loading with just RTLD_LAZY made is actually what made it work....
 * alan_g feels confused
<AlbertA> alan_g: sorry :)
<AlbertA> alan_g: it's just that when I see a GL crash I automatically suspect TLS issues...
<alan_g> AlbertA: No, I'm wondering how that fixes anything.
<alan_g> But I'll try it
<AlbertA> alan_g:  I'll speculate and say maybe libhybris doesn't support libGLESv2.so being loaded with RTLD_NOW
<alan_g> AlbertA: I'm not even going to think about what that imples.
#ubuntu-mir 2015-08-12
<zzarr> hello! is there a jre which can run under mir?
<RAOF> Yes; any JRE will do.
<RAOF> However, there's no Swing or AWT support; you'd need to use a native toolkit binding.
<zzarr> I mean with 3D/OpenGL
<RAOF> Yeah, GL works fine as long as your bootstrap windowing system implements Mir support.
<RAOF> So if you've got Java bindings for SDL or GTK (which exist) or Qt (dunno), then you can GL to your heart's content.
<RAOF> In Java.
<zzarr> nice :)
<zzarr> I have a phone, Meizu MX4 Ubuntu Edition which I would like to run java apps on (note I'm not speaking of Android apps)
<zzarr> how do I install the bindings?
<RAOF> Looks like you might be after http://qtjambi.org/
<RAOF> And if you want something in the store, you bundle the dependencies in your .snap
<RAOF> If you don't mind hacky, break-your-upgrade-path development you can enable a writable filesystem on your phone and just use apt.
<zzarr> I'm running proposed so I think my changes would be undone when I install an upgrade
<zzarr> qtjambi looks really interesting
<zzarr> I'm a programmer using Qt Creator as my primary IDE
<zzarr> it's right down my path :)
<RAOF> Hm, actually, looks like qtjambi might only be for Qt4; only Qt5 has Mir support.
<zzarr> okey
<zzarr> but I should be able to load a qt4 lib in qt5 right?
<zzarr> or are the bindings changed?
<RAOF> They'd be changed.
<zzarr> hmm, okey
<zzarr> maybe I could write a wrapper for the lib
<duflu> Oh look, something shiny
<zzarr> something shiny? is it Mir :D
<zzarr> I have debootstrapped a vivid in a folder /home/vivid (I'll call it guest) my idea is to make a script that installes xmir (on the host) and link it to the guest
<kenvandine> greyback, another question about InputInfo, do you know if the apple magic trackpad should show up as a touchpad?
<kenvandine> greyback, i need to get something to test it, but wanted to confirm before ordering it
<greyback> kenvandine: no idea, recommend you ask the Mir team (RAOF probably knows best)
<kenvandine> anybody ^^ RAOF ^^
<greyback> he's not awake for about 6 hours
<kenvandine> oh right
<greyback> kenvandine: I do recall him complaining how the apple trackpad is a bizarre piece of hardware
<greyback> so it might be a special case
<kenvandine> i have an old one, which i used to test the old gesture stuff in unity
<kenvandine> years ago :)
<kenvandine> the batteries leaked and no longer work
<greyback> kenvandine: you more curious if it works at all?
<kenvandine> aluminum isn't a great material to house batteries in
<kenvandine> i need to test the touchpad settings, and what's reported as a touchpad
<kenvandine> there aren't many choices for bluetooth touchpads
<kenvandine> most use a usb dongle
<kenvandine> not going to work on the phone :)
<greyback> kenvandine: something like "udevadm info -q all -n /dev/input/mouse1" might help report at least what udev thinks it is
<greyback> edit mouse1 to suit
<kenvandine> yeah, i need a device to plugin :)
<kenvandine> not plugin
<kenvandine> pair :)
<greyback> that company credit card won't use itself!
<kenvandine> :)
<bregma> kenvandine, the Apple magic trackpad reports as a regular trackpad
<bregma> it's the Magic mouse that was an unusual beast
<kenvandine> bregma, great
<kenvandine> i'll grab that one then
<RAOF> greyback, kenvandine: The apple magic touchpad does indeed show up as a touchpad.
<RAOF> kenvandine: It's an excellent piece of hardware to buy, because it's an excellent piece of touchpad hardware.
<RAOF> (Like, apparently, all Apple touchpads and unlike every other touchpad ever for no obvious reason)
 * RAOF should totally get a magic mouse.
<bschaefer> RAOF, sooo i got all the device set up for an event5/6 for the mouse/touchpad buuuut it wasnt getting to mir
<RAOF> Hm.
<bschaefer> the evemu-play was working soo i slightly gave up and just pushed the branch :)
<RAOF> Heh.
<bschaefer> RAOF, there was another issue with adding two standard devices
<RAOF> I'm heading out to the shops quickly, but I'll have a look when I get back.
<bschaefer> as well (could have just created a struct for each type of device)
<bschaefer> RAOF, yup, just waiting for jenkins to say its green
<RAOF> I did, at one point, have a test for touchpad motion + clicks, so it's *possible* to replay those things. :)
<bschaefer> strange, i wonder why mir/android isnt picking it up
<bschaefer> i wonder if im just using the wrong event* (event though it says mouse0/mouse1)
<bschaefer> for event5/event6
<bschaefer> my event4 says its the video driver, not a keyboard (not sure how you got event4 to be a keyboard device)
#ubuntu-mir 2015-08-13
<kenvandine> RAOF, thanks
 * bschaefer goes to eat dinner
 * RAOF would quite like to be able to build mir :/
<bschaefer> RAOF, it would help :(
<bschaefer> RAOF, looks like the branch if failing on some protobuf stuff
<RAOF> Yeah, things built wrong.
<bschaefer> RAOF, hmm my error?
 * bschaefer compiles fine on his machine
<RAOF> Is your machine running wily? :)
<RAOF> Slash wily-proposed?
<bschaefer> RAOF, yes :)
 * bschaefer wishes he wasnt
<duflu> bschaefer: Workaround on mir-devel
<bschaefer> duflu, for the proto issue?
<duflu> Yep
<bschaefer> duflu, do i just need to wait for it to merge into lp:mir?
<duflu> bschaefer: I think we're waiting for protobuf to get rebuilt and re-released against the new C++ ABI of GCC5
<bschaefer> duflu, cool i can just wait a little
<bschaefer> people can still look at the code :)
<duflu> bschaefer: You can still build it too. Just cmake .. -DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_C_COMPILER=gcc-4.9
<bschaefer> duflu, im building fine locally
 * bschaefer is on proposed
<bschaefer> duflu, just want to make jenkins happy :)
<RAOF> Yeah, that needs to wait for the archive to work :)
<duflu> Jenkins will be grumpy for some time yet. That's why I landed as much as possible by hand yesterday
<bschaefer> haha, well that attestable cookie branch isnt a MUST LAND ASAP
<bschaefer> soo i think it can wait
<bschaefer> plus its ~3.9k in changes
<duflu> bschaefer: Seems the list of unfinished ongoing transitions is now shorter, but still includes protobuf: http://people.canonical.com/~ubuntu-archive/transitions/
 * bschaefer has never seen that site
<duflu> New to me too
<bschaefer> duflu, hopefully that means soon :)
<duflu> RAOF: What's your regular deb build command (that conveniently avoided the test failure I was getting for so long)?
<RAOF> duflu: Probably DEB_BUILD_OPTIONS="notest nocheck" sbuild -d wily --arch=armhf -j9
<duflu> RAOF: notest nocheck sounds like a reasonable explanation. So I wasn't the only one seeing the failure, just the only one looking :)
<RAOF> If it's what I'm thinking, the test fails because of a qemu deficiency, so it's not very useful to run.
<RAOF> That's what the mako/arale is for.
<duflu> RAOF: No, different (desktop) issue
<RAOF> Oh, I think just debuild works for me, theer.
<duflu> RAOF: Yes, it works, now. Didn't for quite a while; https://bugs.launchpad.net/mir/+bug/1483097
<ubot5> Ubuntu bug 1483097 in Mir "Acceptance test fails under debuild: ClientCredsTestFixture.session_authorizer_receives_pid_of_connecting_clients" [Medium,Fix committed]
<RAOF> Ah, it's possible that I've only ever built it with real root (in a sbuild chroot)
<duflu> alf: Hello
<alf> duflu: Hi!
<duflu> alf: No exciting news to report other than wily doesn't build Mir right now :)
<alf> duflu: Thanks. Has 0.14 landed for vivid+overlay? :P
<duflu> alf: Not sure actually
<duflu> I think it did. It was on arale. But mine might have been hacked
<duflu> alf: Umm, yes seems to be on arale (which is running vivid)
<alan_g> alf: welcome back. Hope you had a good break.
<alf> alan_g: Thanks. I didn't manage to forget keyboard shortcuts, but it was good nonetheless :)
<alan_g> You have to try harder (or longer) next time. ;)
<alf> alan_g: @hack-mir_input-Thread-run-implementation, doesn't the proposed code only enable run() for benchmarks and unit-tests? Is that what we want?
<alan_g> alf: Mmm. I guess that's everywhere we use it. (Which suggests there may be a more elegant solution.)
<alan_g> Can you accept this version this while I look into that as a follow-up (to the series)?
<alf> alan_g: Sure. It actually seems CommonInputThread is not used any more.
<alan_g> alf: thanks for that observation - it lead me to a much better solution.
<alf> alan_g: yw
<greyback_> alf: hey, welcome back. When you get a chance, could you have a look over this doc and see if you agree with the premise: https://docs.google.com/document/d/10_Y04_TrmA_UV9BrObVGLm71jPlFKifBCt6v7YyMU7Q/edit
<alf> greyback_: will do
<alan_g> alf: @hack-mir_input-Thread-run-implementation - I've pushed the "better solution"
<kdub> welcome back alf
<alf> kdub: Thanks!
<alf> greyback_: Is "scale" something that can be calculated from resolution and real display dimensions (which are already present in what Mir publishes), or something different?
<greyback_> alf: different. It's user-configurable UI scaling
<alf> greyback_: how does it affect Mir?
<greyback_> alf: not at all
<greyback_> well, it's probably a per-display setting
<greyback_> so would be /nice/ if it was set & stored with the other per-display configurations
<greyback_> but far from required
<greyback_> it can be saved in gsettings too
<alf> greyback_: so the idea is that whoever sets the display resolution will set it and then clients can access it from there
<greyback_> right
<alf> greyback_: do you see this as a unity8 specific setting or something more generally useful?
<greyback_> alf: I think it's unity8 that would be the main consumer
<greyback_> while most shells have to deal with HiDPI screen issues
<greyback_> I think most have their own way
<greyback_> but one thing I that might go hand-in-hand with this is: unity8 needs to know what scale each client is drawing at.
<greyback_> as example, say I've a retina screen, and so gave set scale to "x2"
<greyback_> I launch 2 apps, one is clever and reads the scale setting and scales its UI. Other app is old, unaware of scale, so draws at x1
<greyback_> then it is the compositor's job to do (ugly) scale up of the old unscaled app
<greyback_> so it's consistently sized
<kdub> and input stack's job to map the input?
<greyback_> kdub: yeah (Qt will manage it easily enough)
<greyback_> with multimonitor, things get more complex
<kdub> things always get more complex with multimonitor :)
<greyback_> if I need mir clients to tell the server the scale they're drawing at, then it makes sense to add mir api for clients to read scale of the display
<greyback_> that's my motivation, but I'm unity8 :)
 * alan_g wonders if he can delete 10KLOC this week
<greyback_> alf: do client API's need to be extended, or does unity8/qtmir need to extra code so that if the display configuration is changed by SystemSettings, that unity8 sets it's own base config to be the same?
<greyback_> -'
<alf> greyback_: both could work, since unity8/qtmir have the pid from Mir's auth mechanism, but changing the API is the cleanest approach. Otherwise, you have a Mir client API call that acts differently depending on Unity8 internals.
<greyback_> alf: well my concern is for non-system-settings apps using that api
<greyback_> but you have a point
<alf> greyback_: Well, the auth mechanism can deny all "change base config" requests that are not coming from system-settings
<greyback_> yep
<alf> alan_g|lunch: @deleting 10KLOC, a worthy goal :)
<kgunn> greyback_: silo 0 still hanging, expected ?
<greyback_> kgunn: it just finished building, I've not checked yet
<kgunn> greyback_: hmmm....apt cache policy showing older libmir*s
<kgunn> will tinker a little
<kgunn> oh wait, wrong term
<kgunn> but yes...still unexpected libmircommon's installed
<kgunn> and wrong u-s-c
<kgunn> i used citrain
<greyback_> did it actually do anything? Because it didn't for me, ubuntu-touch-session in the way
<kgunn> greyback_: well, it downloaded them....
<kgunn> is that what this means "E: There are problems and -y was used without --force-yes"
<kgunn> it did say u-t-s would be downgraded
<kgunn> at any rate, gonna use a hammer
<greyback_> http://pastebin.ubuntu.com/12071338/ is my output, which results in no updates actualy installing
<kgunn> same
<greyback_> sigh
<greyback_> damn thing crashing still
<alan_g> alf: @10KLOC - I have MPs the deletes, now they just have to land.
<greyback_> kdub: hey, I'm still having no luck with the external display being rotated on my N7 in silo0. Can you help?
<greyback_> USC is resizing the surfaces to suit
<greyback_> nothing is locking up (but unity8 is crashing for some reason)
<kdub> wasn't n7's rotation strange somehow?
<kgunn> greyback_: and do we need to rebuild u-t-s ?
<greyback_> kgunn: probably
<greyback_> kdub: nope
<greyback_> same code used to work in n4 & n7 - unity8 did the rest just fine
<kdub> i have a hazy memory that we had to rotate the n7 by 90deg or something
<greyback_> kdub: yep, unity8 is looking after that
<greyback_> kdub: if you can test silo0, I recommend you stop unity8, and see how USC looks on other display
<greyback_> dumbass, no wonder qtmir was crashing, I forgot to merge the multimonitor handling code
<kdub> greyback_, so wait for that to merge in then?
<greyback_> kdub: if you stop unity8, you can still repro the issue just by looking at the spinner graphic
<kdub> okay
<greyback_> thanks. Sorry to have to pester you, but I've dug a bit and was unable to see why it's not happening
<kdub> greyback_, sure, will look this afternoon
<popey> kgunn: is it possible to use a nexus 7 with a slimport and latest mir/unity etc, like the nexus 4?
<kgunn> popey: in theory, if silo 0 wasn't still busted :)
<popey> oh, its busted?
<popey> that'll be why I have a black screen on my nexus 7 then
<popey> is it fixable? I mean, downgrade something?
<kgunn> popey: "fixable" ? like don't install it in the first place
<kgunn> popey: black screen only when you plug it into slimport right ?
<popey> heh
<popey> no, it's black on internal display
<popey> i had a devel image on it from ages ago (because we don't have newer ones on flo), added silo 0 and the overlay ppa
<popey> dist-upgrade, reboot, black screen
<kgunn> popey: huh....no hadn't seen  that
<kgunn> popey: but i hand't tried n7 and i think kdub was gonna poke around on n7 today
<popey> okay
<popey> no worries, just wanted to play before the n4 arrived.
<kdub> afaik, u8 needs to pull in a branch to stop that crash, and I sent a mir-fix to greyback__ that hopefully fixes the rotation issue
<kgunn> kdub: what's the branch, just in case i can merge with lp:~mir-team/mir/silo0
<kgunn> gerry might be off for the evening
<greyback__> kgunn: I am, I can push current state which prevents the crash, but apps aren't drawing currently
<greyback__> so it's not really worth rebuilding until I fugure that out tomorrow
<kgunn> k
#ubuntu-mir 2015-08-14
<bschaefer> RAOF, hey, so a few questions on the review for attestable cookie (also my test is failing now). Cant read the keyboard udev file any more or rather no events
<bschaefer> RAOF, also, when it comes to a platform such as libinput/x11 how does that tie into mir server it self?
<bschaefer> does it replace the android backend?
<RAOF> Yes, ish.
<RAOF> But not the bits you touched.
<bschaefer> RAOF, so either way we still use the low level android stuff that talks to the kernel?
<RAOF> No, we replace the low level stuff.
<RAOF> But not the IPC stuff.
<bschaefer> RAOF, trying to read anpok branch on libinput and how to add a configuration, but his branch only has platform changes
<bschaefer> RAOF, hmm IPC?
<bschaefer> inter process com?
<bschaefer> add an API so U-S-C can set things needed for a barrier (similar to how unity7 works with xinput2)
<bschaefer> RAOF, also i dont think main is fixed yet for protobuf :(
<RAOF> So, we absolutely should not add an API to U-S-C providing barrier-like behaviour.
<bschaefer> RAOF, i think its to add an API to umm set settings like
<bschaefer> speed of cursor
<bschaefer> or some things that is needed to be set in libinput
<RAOF> Yeah, I think that's also incorrect to use USC for.
<bschaefer> hmm
<RAOF> We *should* have Unity8 in charge of drawing the pointer.
<bschaefer> :(
<RAOF> (Whether or not we need to, as a short-term hack, introduce such an API is left as an exercise for the reader)
<bschaefer> RAOF, right hmm, was just under the impression that letting U-S-C render the cursor since greyback didnt want unity8 to draw the cursor
<RAOF> greyback is wrong. At least long-term.
 * bschaefer cant see long term very well atm
<bschaefer> mainly because im missing a lot of context
<bschaefer> RAOF, so in the short team, this shouldnt be to hard ... my main issue is not even knowing how an API should be set up like this since the only thing
<bschaefer> the branch touches is things in src/platforms, meaning i would have to write a C API to touch the platform bits?
<bschaefer> ie. set the cursor device configurations?
<bschaefer> unless U-S-C gets access to a separate C++ API im not aware of
<bschaefer> but either way, im not super familiar with exposing things from the platform --> client
<bschaefer> RAOF, is it platform --> server --> client?
<bschaefer> and back down? platform <--- server <--- client?
<RAOF> Yeah, platform â server â client.
<bschaefer> alright, so mainly i just need to figure out how to send simple data down the RPC
<bschaefer> RCP?
 * bschaefer can never remeber the right letter order
<bschaefer> rpc
<bschaefer> RAOF, that'll at lease be a good start, the only thing im worried about is short term tends to be long term :(
<bschaefer> RAOF, whats the ideal solution for this?
<RAOF> There are a number of plausible options.
<RAOF> One would be to pass the evdev fds down to the nested compositor and manage switching via EVIOCREVOKE.
<bschaefer> that way they can change the device settings them selfs?
<RAOF> Right; then the nested compositor has a full input platform and can go to town.
<bschaefer> that would be a small impact in mir...and would require some work in U-S-C
<bschaefer> but i cant imagine it being crazy
<bschaefer> RAOF, well small impact in the sense that i have no clue what it would require besides 1 function :)
<RAOF> It'd be mostly easy. It'd be easier if we didn't have to pretend that USC was a normal Mir server and U8 was a normal Mir client :)
<bschaefer> haha ... i suppose that complicates things...
<RAOF> Eh, it just makes things a little messy.
<bschaefer> RAOF, i was mainly just going off what was talking about and the card
<bschaefer> err what was talked*
<RAOF> Yeah.
 * bschaefer would rather do it the right way vs a hack that will be shoved into mir
<bschaefer> then it'll happen again and again and you're left with x11v2 :)
<RAOF> :)
<bschaefer> RAOF, ill try to talk about it tomorrow at the stand up to see any other ideas
<RAOF> We could also potentially expose various bits of currently-internal libinput handling.
<bschaefer> RAOF, such as the device it self? So settings can be manually changed in U-S-C?
 * bschaefer has been reading through the libinput code
<bschaefer> and it just seems to turn everything from a device into a mir event
<bschaefer> now ... i dont even know what *settings/configuration* needs to changed/set yet :)
<RAOF> So the nested compositor (ie: unity8) can twiddle the behavioural tweaks itself.
<bschaefer> but from what i understand its mainly the cursor/pointer
<bschaefer> right, that might be better then adding a full blown API like mir_platform_set_cursor_speed(int speed);
<bschaefer> RAOF, that would make U-S-C explicit on the platform though right?
<RAOF> That's not a full-blown API :)
 * bschaefer haha... well thats kind of what i imagined i would attempt to add in the api (from what that card says)
<bschaefer> then figure out how to change libinput
<RAOF> A full-blown API is something like mir_input_get_device_properties() mir_input_set_device_properties() :)
<bschaefer> to what they want
<bschaefer> o
<bschaefer> hmm
<bschaefer> RAOF, well... what if for now i just went through and figured out every function that would be needed
<RAOF> From which you receive arbitrary blobs of data, and to which you push arbitrary blobs of data :)
<bschaefer> then just add function support for that?
<bschaefer> would make it easier to remove i suppose
 * RAOF is not serious about that; that's pretty much the worst possible API.
<bschaefer> haha
<RAOF> I'll make some coffee while thinking.
<bschaefer> alright i've asked far to many questions this early for you haha
<bschaefer> RAOF, o also this if for the pocket PC so i can imagine it having some priority
<RAOF> It's not all *that* early :)
<bschaefer> all the settings: https://wiki.ubuntu.com/MouseAndTouchpad#prompting
 * bschaefer has no clue if those are even *real* settings
<bschaefer> in libinput
<bschaefer> mainly i see this: http://paste.ubuntu.com/12076130/
<bschaefer> looking at http://wayland.freedesktop.org/libinput/doc/0.21.0/libinput_8h_source.html
<RAOF> http://wayland.freedesktop.org/libinput/doc/latest/group__config.html
<RAOF> Is the relevant bit for HEAD.
<bschaefer> RAOF, oo sweet thanks
<bschaefer> right i see we are more after device configuration
<RAOF> So, our relevant design constraints are:
<RAOF> a) We ideally don't want to have to expose every input device property (for every input device type) in an API.
<RAOF> b) We ideally preserve the opportunity for the system-compositor to act on input without worrying about a nested compositor also handling that input.
<bschaefer> RAOF, input porperty mouse/keyboard?
<RAOF> Mouse, keyboard, joystick, $RANDOM_NON_EVDEV_THING_THAT_WE_MIGHT_NEED_TO_SUPPORT.
<bschaefer> o i see yeah
<RAOF> c) The users' shell needs access to various device input properties.
<bschaefer> o right ... yeah they'll need to get_* them as well so they can display the value
<RAOF> Correct.
<bschaefer> that doubles what i thought needed to be done :)
<bschaefer> RAOF, now B)...
<bschaefer> we need to let U-S-C connect with these devices to listen to events out side of mir?
<bschaefer> or provide a way for U-S-C to get events
<bschaefer> but not eat them
<RAOF> u-s-c already has a way to do that (as does U8)
<bschaefer> RAOF, o i see, hmm and wouldnt we ideally want to make sure all the libinput stuff is hidden?
<bschaefer> ie. have an API with generic get/set for these types of properties*
<bschaefer> RAOF, thats if done how the card is proposed atm
<RAOF> Right; that runs into desire (a) :)
<bschaefer> right hmm
<bschaefer> RAOF, hmm soo it just sounds like the only way to do this well is to expose libinput stuff
<bschaefer> and have U-S-C handle whats missing
<RAOF> So, I think probably the *nicest* solution is to have u-s-c hand off input fds to the U8.
<RAOF> So the nested compositor has a full input platform, and U8 can poke it directly without needing a client API.
<bschaefer> then that would make u8 have to poke the API here right? http://wayland.freedesktop.org/libinput/doc/latest/group__config.html
<bschaefer> based on the FD
<RAOF> Correct.
<bschaefer> RAOF, you did mention that would be ideal if U-S-C and U8 were setup correctly (in the fact that U8 is a mir client etc)
<RAOF> But that would be an internal, mirserver API, and that's far more malleable than a client API (which then needs RPC support and such).
<bschaefer> RAOF, what problems would that cause us in how things are set up now?
<RAOF> This also has the added benefit of reducing input latency somewhat, as U8 doesn't need to wait for usc to wake up, process the input event, write it to U8's socket, and then U8 wakes up.
<bschaefer> RPC support sounds annoying, but there was a mention of dbus to libinput?
<RAOF> That's the sideband option, yes :)
<bschaefer> so we could just skip from a client api --dbus> platform (libinput)
<RAOF> That option is: U-S-C exposes a DBus API for prodding these things.
<bschaefer> but that still means we would need an API in mir which would need a list of device properties
<RAOF> That basically just replaces the mirclient RPC component with a DBus RPC component.
<bschaefer> and libinput it self hooks up to?
<bschaefer> by passing a client api?
<bschaefer> right
<bschaefer> RAOF, i suppose that would make things more ... platform independent
<RAOF> Well, not really.
 * bschaefer has no context on the idea of having multiple platforms
<bschaefer> for mir at lease
<RAOF> It has exactly the same problems as a mir client API :)
<bschaefer> since i see an X11 platform (which just uses libinput)
<RAOF> Except that dbus is a nicer RPC mechanism than ours ;)
<bschaefer> yeah as each platform could have its own quirks
<bschaefer> that 1 api couldnt rule over
<RAOF> Right.
<bschaefer> RAOF, o ... and U-S-C IS the MIR SERVER
<bschaefer> right?
<bschaefer> ie.
<bschaefer> platform --> USC --> client?
<bschaefer> rather
<bschaefer> platform --> USC --> U8?
<RAOF> usc is *a* mir server, yes.
<bschaefer> i see, i just now understood that part...
<RAOF> Platform is entirely hidden from USC by libmirserver.
<bschaefer> so platform --> libserver --> USC?
<bschaefer> in how things would have to talk?
<bschaefer> or does libmirserver even have a public API?
<RAOF> Oh, absolutely.
<RAOF> It's the API that USC uses.
<bschaefer> i see ok
<RAOF> Mostly it's mir::Server
<bschaefer> so the client API would sit between USC and U*
<bschaefer> U8
<RAOF> Right.
<RAOF> U8 is *also* a Mir server.
<bschaefer> so then the client API would expose a FD
<bregma> what's wrong with having a D-Bus API for enumerating devices and their settinsg (and maybe changing some as appropriate)?
<bschaefer> o...geez right
<bschaefer> since its a *nested* server
<RAOF> bregma: Mainly that you now need to abstract over your input platforms, and leak that abstraction through to a client.
<bschaefer> bregma, like a DBUS API for mouse settings (get/set) and keyboard (get/set)?
<RAOF> bregma: You also need to be able to identify *which* client, as a multi-user system is going to have different configuration for different users.
<bregma> RAOD, it's going to need that abstraction somewhere
<RAOF> bregma: Absolutely; but the less that abstraction is exposed the easier it is to change.
<bregma> also, there is an arbitrary number of input devices and types and attrubites and settings and most of them are hot-pluggable, and D-Bus is ideal for that
<bregma> D-Bus decouples everything so nicely
 * bschaefer needs to learn dbus better
<RAOF> Yeah, but âarbitrary number and types of attributesâ is just pushing complexity on to the client.
<RAOF> I mean, it makes it easier to have code that *builds*, but more difficult to have code that *works*.
<bregma> well, it's complex and only the client really understand what it wants to do with the input
<RAOF> Correct! Which is why it should be doing the input processing :)
<bschaefer> RAOF, why cant we give the client already in use devices? ie. a list of all connected devices in which they can get/set info to? (im missing a lot of context here) :(
<RAOF> See-also: pointer barriers ;)
<bschaefer> in such a way where we enum over the connected devices rather then potential devices
<bregma> we're going to need something like pointer barriers sooner rather than later, because of the whole press-the-left-edge-to-reveal-the-Launcher thing going on
<RAOF> Yes. That should be implemented by the shell, *not* by USC.
<RAOF> Having it implementable by the shell is one of the major architectural motivations for Mir-like things!
<bregma> probably...  I lack the architectural view of some of this stuff
<bregma> RAOF, you're thinking the best thing to do would be to pass an evdev fd through a C api to the client and let it worry about doing settings things itself?
<RAOF> Yes.
<bregma> hmmm
<bschaefer> RAOF, which i think we all agree on, the only thing we are trying to figure out is how to get configuration changes to libinput;...
<bschaefer> which right ... theres all these different ways to do this :)
 * bschaefer talking about having the shell implement barriers
<bregma> that sort of implies sticking to libinput exclusively in the future, no?  Or is it an evdev-level fd that bypasses libput?
<RAOF> It's an evdev-level fd that bypasses libinput.
<RAOF> I guess it's not even necessarily an evdev fd; it's just *an* fd.
<bschaefer> wouldnt they still need their own input platform which connects directly to libinput?
<RAOF> Yes.
<bregma> I though some of the settings being passed were libinput settings, not evdev settings
<bschaefer> right, at lease that can be abstracted
<RAOF> It just so happens that we don't currently have any input devices that *don't* use evdev, but I'm not sure that's something we can reliably bake in.
<bschaefer> bregma, well i think you get an FD device then use it to change libinput
<bschaefer> settings
<RAOF> You give the fd to libinput.
<bschaefer> so sometime in the future when libinput isnt around, you would just pass the fd to w/e handles input at that point?
<bregma> I'm just thinking things like pointer acceleration is a libinput thing, not an evdev thing
 * bschaefer just thought you would pass the fd to libinput then change the acceleration your self in the shell
<bschaefer> from the evdev FD
<RAOF> Right. This does need libinput to be extended with the ability to create a device from an evdev fd rather than a path.
<RAOF> bschaefer: Exactly. The nested compositor has an input platform, which will be libinput, and adds devices based on the fds it receives.
<bschaefer> RAOF, it sounds nice, i just dont 100% know all the details in this :)
<bregma> maybe anpok can add that with his other upstream changes
<bschaefer> that would be nice...
 * bschaefer kind of assume you could get a evdev FD from a libinput device
<bschaefer> already
<RAOF> You can't, no.
<bschaefer> o :(
<RAOF> But we create libinput devices from evdev fds (or, rather, from /dev/input/* paths), so that's fine.
<bschaefer> i can at lease start making the API for that is suppose ... should just really be a function to mir_platform_get_fd?
<bregma> is that a sadface with a little hat?
<bschaefer> bregma, haha maybe
<bschaefer> o:(
<bschaefer> <:(
<bschaefer> RAOF, right now i think i understand the supppppper broad picture, i think ill generate more questions in the details
<bschaefer> the only thing that seems to block this is actually getting a evdev fd
<bschaefer> from the device to send to the Shell
<bregma> just so you know, anpok is off until the 20th (and I'm off until next Tuesday)
<bschaefer> yeah ...my goal was to try to do as much as i could until he got back :)
<bschaefer> bregma, enjoy your time off! Is it still summer there?
<RAOF> I think the API would actually be something like mir_surface_set_raw_input_handler(), which would set up the callback to handle the fds sent.
<bschaefer> then the function pointer would just be
<RAOF> bregma: But you're not on holiday today?
<bschaefer> (int fd)
<RAOF> :)
<bschaefer> void* ctx
<bregma> bschaefer, I've got tickets to a Broadway show in NYC, I understand it's 32 and sticky there
<bschaefer> bregma, o geez! But awesome! I think you told me you had those
<bschaefer> or are you going again?
<bschaefer> its 28C here now :(
 * bschaefer does not do well in hot weather
<RAOF> bschaefer: You'd need a bit more than just int fd; although possibly just int[] fd, int num_fds.
<bregma> no, this is it, my wife's 50th birthday presemt
<bschaefer> bregma, awesome, well that sounds like a fun trip
<bschaefer> RAOF, a list of FDs? I was thinking each FD would get sent individually but idk why :)
<bschaefer> which is fine
<RAOF> Either is probably fine; a list probably makes it a bit easier.
<bschaefer> RAOF, that function would get called....when an input came down on the fd?
<RAOF> That function would get called each time:
<RAOF> a) A new input device was added
<bschaefer> or one removed
<RAOF> b) The surface received focus (and so a set of input device fds need to be sent)
<bschaefer> oo that makes sense, was thinking that would be independent of surfaces
<bschaefer> but i guess surfaces can filter what devices work on it?
<RAOF> Yeah, it can't really be.
<bschaefer> or something?
<RAOF> This is the bit where having an explicitly different system-compositorânested compositor would make a whole lot of sense.
<bschaefer> which is what we have now?
<bschaefer> with USC->U8?
<RAOF> Which is not what we have now.
 * bschaefer needs to learn how to draw that arrow
<RAOF> Any API that U8 needs is also available to an arbitrary other cilent.
<bschaefer> o i see
<bschaefer> since its the server/client
<RAOF> (Modulo permission bits enforced by USC)
<bschaefer> at the same time
<RAOF> Right.
<bschaefer> eww
<RAOF> U8 *is* a Mir client :){
<bschaefer> hmm yeah
<bschaefer> RAOF, so far this is making sense but i know as soon as i start to write any code my mind will go blank :)
<bschaefer> but so far that makes sense
<RAOF> The reason we need to send device fds on surface focus is that we will *revoke* those fds on surface unfocus.
<bschaefer> RAOF, fds are specific to each surface?
<RAOF> Yeah.
<bschaefer> i see, didnt know that i thought it was more server specific
<bschaefer> and a surface on the server it self would have the same FD/devices
<bschaefer> soo thats a part that will have to be touched in the server, when a surface is released to send that off
<RAOF> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c7dc65737c9a607d3e6f8478659876074ad129b8 is the relevant bit.
<bschaefer> RAOF, duh, that makes a lot more sense from the first sentence haha
<bschaefer> RAOF, cool thanks for all the info! Ill be sure to have more questions come next week
<RAOF> :)
 * bschaefer tries to write everything down so far coverd
<bschaefer> RAOF, o also there was some questions on the attestable cookie MP when ever you get a chance to read though
<RAOF> Yeah, I'm looking through it.
<bschaefer> (one being about providing a way to produce cookies public wise)
<bschaefer> RAOF, cool thanks!
<alan_g> alf: @mir-on-x-grab-keyboard - am I missing some incantation to activate the grab? "$bin/mir_demo_server --launch-client bin/mir_demo_client_multiwin" and try various key combinations.
<alf> alan_g: what works for me is explicitly setting the input platform --platform-input-lib=lib/server-modules/server-mesa-x11.so.4
<alan_g> alf: that helps. Thanks
<alan_g> WTF?! "static inline std::chrono::nanoseconds seconds_to_nanoseconds(std::chrono::nanoseconds secs)"
<attente> hi. unity-system-compositor is crashing for me with: "/usr/sbin/unity-system-compositor: relocation error: /usr/sbin/unity-system-compositor: symbol _ZN3mir6Server24add_configuration_optionERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_NS_10OptionTypeE, version MIR_SERVER_32 not defined in file libmirserver.so.32 with link time reference"
<alan_g> attente: that's a g++5/g++4 mismatch. (Part of the "gcc5 transition")
<attente> alan_g: oh... is there any temporary workaround for it?
<alan_g> Well, I've just avoided updating anything from archive.
<alan_g> What stack are you seeing this on?
<attente> alan_g: just did an update on wily
<alan_g> Your using unity-system-compositor on a desktop?
<alan_g> *you're
<attente> alan_g: yes, was trying to run u8
<alan_g> You've likely downloaded a bizarre mix of g++4.9/g++5 packages. So...
<alan_g> You could try finding an 4.9 build of USC and reinstalling, but you're likely to run into other (similar) problems depending what's in archive.
<alan_g> FWIW The "__cxx1112basic_string" is g++5's new string implementation. So USC is built with g++5 and libmirserver isn't.
<attente> alan_g: ok, thanks. do you think rebuilding the mir packages with g++5 would work?
<alan_g> attente: maybe. It depends what 4.8/5 mix of libs you now have. (e.g. boost and protobuf)
<attente> alan_g: ok, i'll try it anyways
<popey> kgunn: what's the state of silo 0, is it still broken? Any ETA for it not being?
<ted> popey, patches welcome! ;-)
<popey> ted: you don't want my patches :)
<ted> popey, Perhaps, but we're talking about kgunn here â he knows how to translate from "Old English" to American. ;-)
#ubuntu-mir 2015-08-16
<RAOF> Dear CLion: We're building a pseudo-cryptographically-secure timestamp system into Mir for the express purpose of preventing your obnoxious focus stealing.
<RAOF> No love, Chris.
<bschaefer> RAOF, o fyi something in trunk has messed up umockdev reading of the recordings :(... or i messed something up
<bschaefer> ill have to take a better look tomorrow
 * bschaefer trying to avoid looking at emails today
<RAOF> bschaefer: What are you doing in here on Sunday? :)
<bschaefer> RAOF, NOTHING!
<bschaefer> :)
 * RAOF shoes bschaefer off to the weekend
 * bschaefer goes away from irc
<RAOF> Or even shoos.
<bschaefer> haha
#ubuntu-mir 2016-08-15
<duflu> RAOF: I take it an Android backend (or stub) for subpixel is coming?
<duflu> Or not required?
<duflu> Maybe x11 too
<duflu> Awesome. Kernel 4.7 fixes my black screen by turning it into an equally plain orange screen
<RAOF> duflu: Nested is up next. Android already sets it to _unknown, which might be as good as we can do?
<duflu> RAOF: I would hope Android can do better. Will grep later. Also x11 should be able with xrandr info..?
<RAOF> Yup. X11 should be reasonably easy.
<duflu> RAOF: I can't find any such option for Android/HAL... Probably just as well while unity8 does client-side screen rotation, which would need work in that case
<RAOF> unity8 could certainly make the appropriate changes.
<RAOF> Of course, that requires the nested platform to do the right thing, which it doesn't at the moment :)
<duflu> RAOF: I think it's mostly desktop monitors that U8 just isn't ready for
<duflu> "low" DPI
<RAOF> Indeed.
<RAOF> Sub-400DPI :)
 * duflu is reminded to investigate FRC
<duflu> again
<RAOF> FRC?
<duflu> RAOF: I think it's also known as DRM_MODE_DITHERING_*  (https://en.wikipedia.org/wiki/Frame_rate_control)
<RAOF> Oh, temporal dithering?
<duflu> Yes
<duflu> RAOF: I noticed recently Macbook Airs still need it
<duflu> In 2016 just as they did in 2010 :P
<RAOF> Seriously? I thought Apple tended to ship non-terrible hardware.
<duflu> Yep, seriously.
<duflu> It looks extra bad in Ubuntu like spatial dithering. I think we need to flip a switch
<RAOF> Yay! Trade colour terribleness for 30Hz flicker!
<duflu> Yep... and I only just convinced John Lea to stop shipping pre-dithered wallpaper
<duflu> RAOF: What was it you said about relating surfaces to output info before? I have a plan, but don't want to conflict if you have one
<RAOF> duflu: Pass a MirOutput* as a part of the surface-output event.
<duflu> RAOF: That's won't work if you need to abstract it to a non-real MirOutput
<duflu> ie. clone mode or overlapping multiple outputs
<RAOF> ??
<duflu> So you should probably wait for my general solution
<duflu> Or go have dinner...
<RAOF> True, but overlapping outputs don't make sense, and clone mode you can happily pick whichever you choose.
<duflu> RAOF: In clone mode, two physically different arrangements should surely be generalized to disabling sub-pixel?
<duflu> Similarly I need to proxy frame timing info
<duflu> So it's not that we should say a surface is on output X, but the common traits of the outputs it is on are A,B and C
<duflu> RAOF: I meant a surface "overlapping" multiple outputs. In such a case what is its subpixel arrangement, and frame interval, and physical resolution etc
<duflu> The answer may not match any 'real' output
<RAOF> In such a case, you pick one output.
<RAOF> (Specifically, you pick the output with the highest scale factor âº)
<duflu> RAOF: Yeah I get that we can survive with that compromise. And in the single monitor case the answer is absolutely correct. I'm just trying to future-proof
<RAOF> Surfaces should generally span multiple outputs only transiently, and you can't render them correctly anyway.
<duflu> RAOF: I used to believe that. Till we were asked to do a monitor "wall" project
<duflu> One surface, many monitors
<duflu> Although in that case everything except the phase of display would match
 * duflu now remembers what he was looking at
<RAOF> For a video wall wouldn't you just do multiple surfaces?
<RAOF> Or, alternatively, multiple buffer streams in a single surface.
 * ogra_ would just make vlc work :P
#ubuntu-mir 2016-08-16
<duflu> Hey Saviq, anyone, can you please give these milestones?   https://bugs.launchpad.net/canonical-devices-system-image/+bugs?field.status%3Alist=FIXCOMMITTED&assignee_option=choose&field.assignee=vanvugt
<Saviq> duflu, done
<duflu> Saviq: Thanks
<duflu> Saviq: I didn't check if anyone else had fixes committed without a milestone...
<Saviq> duflu, it's not like it's mandatory to have a milestone
<duflu> Saviq: No, but bugs are more likely to get fully closed if they do
<duflu> And thus no longer part of the apparent backlog
<Saviq> that true
<duflu> Also you should be able to look at the milestone and see accurately what's in it
<duflu> Saviq: On that note, one of the four (the least important) branch didn't land. That just means the default scroll speed is now correct, but you can't yet set it above 1.0x speed
<Saviq> duflu, yeah I know, I didn't wanna step on the settings folks toes with this, will make sure they have it on their radar
<Saviq> and I thought that one was the least important so wanted to let them land whenever they have a chance to
<alan_g> greyback_: what reasoning determines if something goes into namespace qtmir or global namespace?
<greyback_> alan_g: I used to struggle with namespaces and Qt, so initially I just avoided them. As time has been going on, I've figured out the mysteries, so now i put everything into qtmir namespace
<alan_g> greyback_: OK, I can do that too
<greyback_> please do
#ubuntu-mir 2016-08-18
<alan_g> greyback: have you looked at this? (I'm tempted to update, but won't if a review is already in progress) https://code.launchpad.net/~alan-griffiths/miral/spike-miral-qt-integration/+merge/303165
<greyback> alan_g: I had a brief look this morning over coffee, was going to review proper after lunch.
<greyback> welcome to update it
<greyback> I mostly was thinking of plan for action to test it out
<alan_g> greyback: updated, now you plan can test the combined changes
<greyback> ack
<alan_g> greyback: did you ever look into the crash I see when apps close?
<greyback> alan_g: not yet, but the current work I'm doing touches that code so I hope to fix it that way
<alan_g> OK, I was thinking of poking around, but it clearly isn't the right time just now.
<greyback> alan_g: could you do me a favour and check if this compiles ok for you (with MIRAL_ENABLE_TESTS=1): lp:~gerboland/miral/use-cmake-extras
<alan_g> GRE
<alan_g> greyback: sure. 2 min
<greyback> ta
<greyback> I'm getting http://pastebin.ubuntu.com/23067425/ which I'm presuming is due to my custom mir build (with test LTO disabled)
<alan_g> greyback: that's bug 1603080
<ubot5> bug 1603080 in mir (Ubuntu) "mirtest-dev provides an incorrect .pc file" [Undecided,New] https://launchpad.net/bugs/1603080
<greyback> aha
<alan_g> It's your own fault for not reporting mirtest-dev bugs when you got it.
<greyback> I only got that now!
<greyback> instead I was getting fail on gtest.a not existing
<alan_g> Hm cmake not happy: "cannot create target "gtest" because another target of the same name exists"
 * alan_g suspects a conflict with miral/test
<alan_g> greyback: it works on its own, but conflicts with miral/test's gtest stuff.
<greyback> alan_g: you're on yakkety, right?
<alan_g> yes
<alan_g> At least for that trial
<greyback> it works well for me on xenial+overlay, no conflict. I'll  try yakkety
<alan_g> Oops I mean you can't have both -DMIRAL_ENABLE_TESTS=on and -DMIRAL_ENABLE_QT=ON
<greyback> alan_g: ah, I see what you mean
<greyback> yeah, that's step 2
<greyback> for me, I just hit the fact that Ninja doesn't like the GMock/test script shipped in miral
<alan_g> Anyway, you just need to hack your mirtest.pc file to build for yourself
 * alan_g switches back to xenial (without overlay)
<alan_g> greyback: are you planning to fix the conflict with miral-qt?
<greyback> alan_g: I'm working on it now
#ubuntu-mir 2016-08-19
<memeka> hello, will mir work with gbm drivers?
<duflu> memeka: Yes, despite the misleading name the mesa-kms driver should work for any GBM implementation with KMS support
<duflu> ... without requiring Mesa :)
<memeka> duflu: for wayland i need an EGL driver with gbm_platform support (e.g. to start weston) and with wayland_platform support (to start EGL apps in weston) .... would i be able to use this driver (gbm_platform) with mir? and would i be able to run EGL apps?
<duflu> memeka: apps require special work. There's something in Mesa called egl-platform-mir.patch that needs to be ported to other EGL implementations to make it understand Mir clients. Without that you just get a server but no apps visible
<memeka> duflu: unfortunately I am not using Mesa drivers - using Mali binary drivers (with gbm support) - is there a way to get apps running?
<duflu> memeka: Only if you have the source code to the Mali "libEGL.so.1" and expertise in writing drivers
<memeka> :( thanks
<duflu> memeka: Maybe 6 months from now ;) Mali is common enough that other people want it too
<memeka> Haha maybe
<memeka> Tho I think it's easier to use the android drivers
<duflu> It might be... that might be possible without writing code.
#ubuntu-mir 2017-08-14
<xnox> RAOF, the PR looks good, I'll cherry-pick and will upload shortly.
<xnox> sorry for the delay, was at debconf
<xnox> RAOF, this does indicate that you are running tests on trusty kernel, rather than xenial kernel.
<xnox> RAOF, and snaps on trusty require hwe (xenial) kernel and subordinate systemd.
<xnox> RAOF, why are tests are not executed on xenial kernel? can you at least install hwe kernel on the test nodes?
<Guest73093> xnox: We'd need to take it up with IS; those tests are run on the jenkaas environment. We don't have access to the underlying system :)
#ubuntu-mir 2017-08-15
<xnox> Guest90219, right makes sense =))))) make do with what you have.
#ubuntu-mir 2017-08-16
<oSoMoN> hey all
<oSoMoN> Iâm looking at this weird chromium/libreoffice interaction issue, where symbol mir_display_config_release somehow comes into play
<oSoMoN> I could use some help in understanding it
<oSoMoN> https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1710789
<ubot5> Launchpad bug 1710789 in chromium-browser (Ubuntu) "chromium does not open downloaded files" [High,In progress]
<greyback> alan_g: ^
<alan_g> looking...
<oSoMoN> from my tests in VMs, the issue happens only on amd64, not i386
<oSoMoN> and zesty and artful are affected
<oSoMoN> trusty and xenial are fine
<alan_g> mir_display_config_release was introduced in Mir 0.21 - xenial originally had Mir 0.17 - so I suspect there's an old libmirclient on the system
<alan_g> oSoMoN: could you $ apt show -a libmirclient9 on an affected system?
<oSoMoN> alan_g, http://paste.ubuntu.com/25326372/
<alan_g> Oh! Look what I find:
<alan_g> /usr/lib/chromium-browser/libmirclient.so.9
<alan_g> /usr/lib/x86_64-linux-gnu/libmirclient.so.9
<alan_g> Is chromium-browser shipping its own libmirclient?!
<oSoMoN> alan_g, yes, see https://cs.chromium.org/chromium/src/third_party/protobuf/README.chromium?q=libmirclie&sq=package:chromium&l=50
<alan_g> I guess the stub needs syncing with more the recent symbols.
 * alan_g thinks there must be a better way
<alan_g> oSoMoN: it's a guess, but I suspect that soffice.bin (or its dependencies) needs the real libmirclient, but gets the stub
<oSoMoN> alan_g, ack, Iâll dig further into this direction
<Saviq> https://developer.ubuntu.com/core/examples/snaps-on-mir is finally back up
<alan_g> \o/
<alan_g> bschaefer: AlbertA anyone for a design discussion? https://code.launchpad.net/~alan-griffiths/miral/pre_init-CommandLineOption/+merge/329098
