[00:00] racarr: ok, log incoming [00:01] racarr: http://paste.ubuntu.com/6181800/ [00:01] racarr: I don't see any mention of the uinput device [00:02] racarr: which is called 'autopilot-finger' BTW [00:02] racarr: in that log, the input events are me unlocking unity8 with my finger [00:02] no autopilot [00:03] I wonder about these two lines: [00:03] [EE, android-input] [EventHub]could not open /dev/input/event6, Permission denied [00:03] [EE, android-input] [EventHub]could not open /dev/input/event7, Permission denied [00:05] yeah, so when we create the autopilot touch driver, even6 and event7 appear on the /dev/input folder [00:05] thomi: i would say thats almost certainly it [00:05] not sure why we get 'Permission denied' though, the permissions on those device nodes are identical to all the others [00:06] I guess unity8 isnt run with root, but something sets the permissions on the /dev/input nodes it needs to something it can use [00:06] group? [00:06] apparmor? [00:06] secret-security-framework-number-9 [00:06] group is all the same, android_input [00:06] who would I talk to about apparmor? [00:06] I dunno [00:06] Jamie maybe, if he's still awake [00:06] I bet ricmm would know more than me [00:06] ricmm_: ^ ? [00:07] maybe its a race with setting the permissions [00:07] and opening hte device [00:07] I dont know [00:07] where the permissions [00:07] comes from [00:12] thomi: good grief... [00:12] i mean how did that work prior to mir....shoulda been the same right [00:14] kgunn: racarr, OK, I've eliminated apparmor as a culprit [00:14] racarr: are you able to see what would cause that permission denied error in mir? [00:17] its the same error you get if you urn it on the desktop without [00:17] permissions to open the /dev/input devices [00:17] looking [00:17] I see it's in EventHub.cpp:961 [00:17] Mm [00:18] errno doesnt lie [00:18] permission is denied [00:18] (kind of catchy when you say it outloud) [00:18] but... [00:19] http://pastebin.ubuntu.com/6181858/ [00:20] what. thefuck. is. goingon!? [00:20] robert_ancell: does mir drop priviledges after starting up? [00:20] oops, I meant racarr ^ [00:21] like, maybe when it loads initially, it's running as root, but then it drops to being run as a user that isn't root or in the android_input group? [00:30] not that I know of [00:33] thomi, it does not [00:33] bums [00:34] is it possible the devices are being probed after mir opens , mir tries to open them fails, gives up, then they get given [00:34] the appropriate permissions? [00:34] I'll try creating the devices first, then starting mir [00:50] are there devices that refuse O_RDWR but work fine for O_RDONLY ? [01:17] thomi: any luck [01:18] kgunn: long answer: check out #ubuntu-touch scrollback. short answer, no luck at all. Have managed to stump several people much smarter than I am :-/ === jono is now known as Guest37503 [02:17] thomi: i see you are basically left to contemplate the infinite in #touch...can you summarize where you are, maybe duflu in his inifinite linux device wisdom might have some tricks [02:17] * duflu thinks you have the wrong name there === ubot5` is now known as ubot5 [02:20] kgunn: sure [02:21] actually, I should probably file a bug so my progress is not lost to the grey mist I'm happy to call my memory [02:33] thomi: so this same thing works in SF ? [02:33] yup [02:34] just writing up a bug report. Will be done in a few minutes [02:34] thomi: hmmm....by removing sf, could something not be setting wider permissions that should? [02:34] Thank you for not continuing the tradition of bugs that only exist in IRC [02:34] we looked pretty exhaustively at permissions [02:34] duflu: :) [02:34] this is a big one [02:35] ditto to the documenting it in a bug [02:42] robert_ancell: Please stop removing distro tasks. They are absolutely required where bugs are reported against distro, and fixed in distro [02:42] duflu, none of the other bugs have distro tasks and all mir bugs affect distro. There's no need to duplicate entries [02:43] robert_ancell: They're not duplicate. They clearly delineate where a fix is upstream or in distro [02:43] Launchpad is designed that way [02:43] duflu, in the case of mir upstream == distro [02:44] robert_ancell: Not true. Our upstream fixes are usually days (or weeks) ahead of distro. And after we branch properly, months [02:44] Hence you need separate tasks [02:44] duflu, when it's marked fixed released it's in distro [02:45] robert_ancell: No, that means fix released upstream (usually as a tarball). Hence Fix Released upstream often happens after distro in reality [02:45] duflu, in reality our releases are done automatically and straight into distro. There's no tarballs [02:46] robert_ancell: You can't make up your own rules different to the rest of Ubuntu. People need and expect ubuntu tasks to know what's going on [02:48] duflu, you can, we have, there's no point making ensuring ever bug has both an upstream and ubuntu task open on it. All Mir bugs are Ubuntu bugs, we've decided to track them all in the upstream tracker [02:49] duflu: kgunn, anyone else who cares: this is what I've been bashing my head against all day: https://bugs.launchpad.net/mir/+bug/1233944 [02:49] Ubuntu bug 1233944 in Mir "Unity8/Mir is unable to open autopilot uinput devices" [Critical,New] [02:50] robert_ancell: Anyone who uses Ubuntu and Launchpad knows that fixed in "Mir" does not mean fixed in "Ubuntu". We need to communicate more clearly and there's a simple protocol in place. Why not just make the bugs *accurate* ?! [02:50] robert_ancell: racarr (if you're on) kdub ^ [02:50] I will purchase many drinks for the person who solves this for me [02:51] robert_ancell: If you want, I will do it. I do so anyway. I just can't stand working in an environment where even the information describing what we're doing is wrong [02:51] duflu, I'd say most people who use Launchpad don't know or care about the distinction between upstream and downstream tasks. The bugs are accurate. [02:52] duflu, no, it's a huge amount of pointless paperwork [02:52] It's not huge, and it has a very clear purpose. Launchpad's bugs a multidimensional for good reason [02:53] duflu, they were done like that because there was a large number of components that have different upstreams and downstreams. In this case that has not occurred. The software center team used this practise because it made things much easier and it matches my experience too [02:54] I gotta go walk in the pouring rain to clear my head for a bit. When I get back, I expect to see a bugfix waiting for me ;) [02:54] brb [03:03] thomi, I'm looking at this bug but you probably know more about the input layer than me [03:05] thomi, I'm a little unsure of what you mean in the report - does Mir never get input from these devices or only if they are created before Mir starts? [03:05] robert_ancell: mir is only able to open the devices if they exist before mir starts [03:06] thomi, and you get the input events from them? [03:06] robert_ancell: well, I never got that far, but the open() call doesn't fail, which is what's happening in the error case [03:06] thomi, so the bug essentially seems to be "mir fails to hotplug input devices"? [03:07] I guess so [03:07] thomi: robert_ancell ...ok thinking aloud (and yes i'm a manager i'll try not to hurt myself) [03:08] robert_ancell: feel free to change the bug title :) [03:08] but...it bothers me this is "3rd party code"..so i dig around in cynagenmod [03:08] thomi, can you show me the code that creates the devices? [03:08] robert_ancell: sure... one second [03:08] it seems that eventhub.cpp is built into either libui or libinput [03:08] thomi, wondering if they're created with wrong permissions and then they're updated (just a guess) [03:08] depending on when the change happened [03:09] robert_ancell: well, we use uinput, and the uinput system creates the actual event* devices [03:09] so could one of these libs that is actually in the device be causing this? with some primordial android input setup code [03:10] robert_ancell: http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/input/_uinput.py#L192 [03:10] e.g. just like surfaceflinger would fight with mir over the display....maybe one of these is fighting mir for the input dev [03:10] basically, work out the device capabilities, and hand it all off to the kernel [03:14] thomi, can you reproduce on the desktop or just the phone? [03:15] robert_ancell: I haven't tried on the desktop. Should I just run mir_demo_server, or something more complicated? [03:15] thomi, that should be fine, you're just looking for the error message when they're created [03:16] ok, need to install some things first... [03:18] thomi: reading your instructions...cd ~/autopilot, is that on the device ? [03:18] kgunn: yes [03:18] ah i see it...forget to run setup after i reflashed [03:19] kgunn: that directory gets created when you run phablet-click-test-setup [03:19] yeah [03:22] robert_ancell: so I'm having problems testing mir on the desktop since I don't currently have a second machien to SSH into the first one, so I can't create the uinput devices after mir starts [03:22] thomi, ah - what do I need to install to test it here? [03:23] robert_ancell: python-autopilot [03:24] thomi, the archive one or a branch? [03:24] robert_ancell: archive is fine [03:24] make sure you export those mir env vars :) [03:25] thomi, I can just run the contents of create_touch_device() to test this right? [03:25] robert_ancell: probably, yes [03:25] (trying to break this down to the simplest repeatable case) [03:26] I usually just start the python interpreter, and write: [03:26] from autopilot.input import Touch; t = Touch.create() [03:26] simple enough for me :) [03:26] ta [03:26] brb === jhodapp is now known as jhodapp|afk [03:35] thomi, seems to run fine on desktop [03:35] thomi, but u-s-c is being run as root, the shell on the phone is being run as a user account right? [03:38] thomi: as part of the instructions in the bug...do you assume they've loaded your python-ubuntu-platform-api deb ? [03:40] kgunn: ahhhh yes! [03:40] kgunn: thanks for that [03:40] robert_ancell: yesh, that's correct [03:40] kgunn: will update the bug now :) [03:40] * kgunn wonders if yesh is a michael scott/office reference [03:42] kgunn: bug updated [03:42] heading out for 20 mins... [03:51] thomi: should that same example AP test (ubuntu ui tookit) run on SF even with the new deb installed ? [03:52] kgunn: yes [03:52] kgunn: are you saying that it doesn't? [03:52] thomi: verifying that now... === chihchun_afk is now known as chihchun [03:53] thomi: can you try with apparmor=0 passed to the kernel? [03:54] you can probably looking into our flash-kernel script to see how it constructs a blob with command line to flash [03:54] if that fails, make sure you put everything in the bug [03:54] and ill pick it up in the AM EST [03:54] ricmm_: we ruled out apparmor [03:55] I'm about to EOD, but the bug is pretty well documented [03:55] DENIED in syslog is not enough to rule it out [03:55] oh? [03:55] ruling it out is apparmor=0 in the kernel command line [03:55] some things are silent, or at least im told so :) [03:56] huh.. that's not what the apparmor guys said earlier. OK, so how do I chaneg the kernel parameter on the phone? [03:56] look into the flash-kernel script [03:56] but if you are about to EOD, go EOD [03:56] ill look into it tomorrow [03:56] midnight here [03:56] ricmm_: 'flash-touch-kernel'? [03:58] indeed === ricmm_ is now known as ricmm [03:58] anyways you've put enough in the bug, update with the apparmor result or just go and ill try it tomorrow [03:59] ok [03:59] I'll try and figure this script out, or eat dinner, whichever happens first :) [04:02] thomi: i get https://pastebin.canonical.com/98327 [04:04] kgunn: you need to be the phablet user: sudo -i -u phablet [04:04] kgunn: adding that bit of infomration to the bug as well :) [04:04] gah [04:06] thomi: op now i get the awesome testibilty arg prob [04:08] kgunn: the fact that you get a warning is not necessarily a sign that something broke. post your output somewhere? === chihchun is now known as chihchun_afk [04:12] https://pastebin.canonical.com/98328 thomi [04:13] again this is still just running with surface flinger [04:13] stepping away to get a drink to stay awake [04:14] kgunn: you need to download https://raw.github.com/akkana/scripts/master/termsize and run it - get your terminal back :) [04:14] I mean that as an aside, it won't fix your problem [04:14] but it will make you less suicidal while developing on the phone :) [04:15] kgunn: hte unknown option is a red herring. Your actual problem is this: MismatchError: After 10.0 seconds test on Standard.selected failed: True != dbus.Boolean(False, variant_level=1) [04:16] kgunn: I'm *sure* this worked for me earlier today... let me reboot & double check [04:26] kgunn: ahhh, you need to unlock the shell before you run the test [04:27] kgunn: yeah, that'll be it [04:28] OK, I gotta go help with dinner [04:28] * thomi -> BBL [05:06] thomi: so how to unlock the shell ? [05:09] thomi: nvmd i see you updated [05:10] thomi: ok...totally works [05:11] kgunn: :) [05:21] thomi: did you have any trouble with the mir logging...i'm running ok (expected failure on mir) but don't get the input log after the env setting [05:21] ...and yes i was sudo -u phablet -i when i set the env variables === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [05:51] kgunn: nope, it just worked for me [05:51] kgunn: note that if you're running unity8/mir under upstart you need to use initctl set-env, otherwise, if you're running it directly use export [05:56] thomi, duflu, RAOF, racarr, kdub, kgunn, alf_, hikiko, meeting in 4 mins.. [05:59] hikiko, meeting! [06:04] robert_ancell, i am having a problem connecting i ll be there in 2 minutes [06:04] hikiko, np [06:17] Was I the only one thinking of Brady Bunch music when the second alf appeared? [06:17] racarr, so you wanted to talk to kdub and I wanted to talk to RAOF or alan :) [06:19] In my case, I should have just talked to kdub during the day XD [06:19] I am so useless by the time we have these meetings >< [06:20] * alf_ upgraded hangouts, let's see if it's going to be better next time [06:21] It's a story of a man named Frantzis, who was bringing up some very lovely clones... [06:21] * duflu goes back to real work [06:21] bye all [06:21] Bye robert_ancell [06:22] bye [06:55] can we have a small hint about the gpu drivers? pleeeease === chihchun_afk is now known as chihchun [07:31] racarr: Still around? [07:33] morning [08:04] mlankhorst: Morning. Did any of that nouveau vsync timing work land, anywhere? [08:08] nah but maintainer is looking at it :/ === alf_ is now known as alf|xmir_devel === mzanetti is now known as mzanetti|otp === mpt_ is now known as mpt === mzanetti|otp is now known as mzanetti === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [10:58] alan_g, so, about that FakeEventHub MP review, ARBITRARY_TIME should be simply arbitrary_time (so one can't infer if it's const, local, global or member variable)? [10:58] hi, did anyone get the stop lightdm crash recently? [10:59] because I got it today and I couldnt switch VTs from ssh anymore [11:00] dandrader: Yes. But one can infer it isn't a macro. [11:00] ok [11:03] although one would handle a macro pretty much the same way it would a const variable. === hikiko is now known as hikiko|lunch === alan_g is now known as alan_g|lunch [12:17] ricmm, ping [12:23] guys you possibly know this already but there are crashers for maliit and hud when you start mir [12:35] bug 1233988 [12:35] bug 1233988 in maliit-framework (Ubuntu) "maliit-server crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [Medium,Confirmed] https://launchpad.net/bugs/1233988 [12:35] davmor2, is it the one you're seeing ^ [12:35] and I couldn't retrace hud [12:36] jibel: possibly, I had a few that I couldn't retrace so far [12:38] jibel: I'm trying a few things currentl'y when I get back from Lunch I'll add some debug symbols and see if I can get some info from it === dandrader is now known as dandrader|lunch === hikiko|lunch is now known as hikiko [12:53] folks, I've an issue with Mir and clients which are SIGSTOP-ed. It appears that sometimes Mir considers that client dead and disconnects it. [12:53] is there any way to prevent that? [12:57] davmor2: i don't have an issue with assigning the maliit crash to mir if its the cause...but please do some testing on SF to compare....at least, i've seen OSK be fairly unstable in the SF config as well [12:57] davmor2: hud for sure is a unity-mir/mir issue [12:58] https://bugs.launchpad.net/unity-mir/+bug/1231713 [12:58] Ubuntu bug 1231713 in unity-mir "HUD spyglass doesn't appear on bottom-upward swipe on unity-mir" [High,In progress] === alan_g|lunch is now known as alan_g [12:59] kgunn: I need some Mir team help with the above query, please push it to near the top of the stack. It's causing big app-management problems [13:08] kgunn: I cleared out /var/crash before starting mir so I think it is possibly just an issue with maliit but on a fresh sf boot I don't see any crashes but that isn't to say that the reboot didn't cause the maliit crash if that makes sense. [13:10] kgunn: my phone is completely locked up now. I'm about to dig into it and see what is what. [13:13] kgunn: ouch adb isn't connecting [13:13] greyback_: ack.... alan_g this sounds related to how the server handles crashing shell (altho more to the second phase of restoring apps) [13:14] * kgunn waits for alan_g to tell me there's code sitting on dev branch i should have merged to trunk (braces) [13:14] kgunn: if you know it, why should I tell you? [13:14] kgunn: the server handling crashing shell is probably unity-mir/my fault. I've idea on possible fix [13:15] greyback_: how quickly does this happen? After half an hour? Or in seconds? [13:15] kgunn, I don't get this maaliit crash with SF, but it is there on every boot with MIR enabled [13:16] jibel: ack...can you log a specific bug to that effect (maliit crash on every mir boot)...thank you [13:17] greyback_: https://code.launchpad.net/~alan-griffiths/mir/client-dies-without-server/+merge/187797 [13:17] which i s on our dev branch.... [13:17] alan_g: minutes [13:17] dev branch most definitely breaks api [13:18] so...gotta do all the paperwork first [13:18] kgunn: oh interesting [13:18] https://code.launchpad.net/~mir-team/mir/development-branch [13:18] ...which i'll just go ahead and start right now.... [13:19] kgunn: it would be good to land https://code.launchpad.net/~alan-griffiths/mir/fix-1201436/+merge/188535 too - that's got more RPC cleanup [13:19] kgunn, bug 1233988 [13:19] bug 1233988 in maliit-framework (Ubuntu) "With MIR enabled: maliit-server crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [Medium,Confirmed] https://launchpad.net/bugs/1233988 [13:20] alan_g: shall i top approve? (i take it "fix nits" addresses duflu's "needs fixing") [13:20] jibel: thank you1 [13:20] or thank you! even [13:22] is there a know issue for unity8 using 100% CPU when the phone is idle with screen blank? [13:22] kgunn: yes [13:24] jibel: yes...there are actually 2 disctint bugs for that [13:24] I found 1233870 but not the other, do you have it handy? [13:30] * kgunn wonders if i just lied to jibel...one moment [13:31] greyback_: can you get a server log from msg-processor-report? That ought tell why the server decides to disconnect [13:32] alan_g: ok [13:32] jibel: i knew it was a unity8 bug....but it seems there are a few more :) https://bugs.launchpad.net/unity8?field.searchtext=cpu&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&fiel [13:32] d.has_no_package= [13:32] I suspect that something happens on the socket - but... [13:33] kgunn, no worries, I'll continue searching [13:33] jibel: i think i was thinking of this one https://bugs.launchpad.net/unity8/+bug/1217099 [13:33] Ubuntu bug 1217099 in Unity 8 "Unity consumes 50% CPU when screen turns off" [Undecided,Incomplete] [13:33] kgunn: had to take the battery out of my phone, now digging into if there were any crash reports [13:35] kgunn: the only addition to the crash count seems to be _usr_lib_arm-linux-gnueabihf_upstart-app-launch_zg-report-app.32011.crash I'll try that script that does seem to work ish and get some info on it [13:36] davmor2: cool [13:47] kgunn: http://paste.ubuntu.com/6183885/ hope that is useful I think it stopped saying there were missing symbols [13:52] kgunn: would there be a dbg package for this from /usr/lib/arm-linux-gnueabihf/qt5/plugins/platforms/libqubuntumirclient.so [13:53] davmor2: there must be somewhere [13:54] kgunn: apt-cache search libqubuntumirclient returns nothing [13:54] greyback_: ^ best way to get debug pkg for libqubuntumirclient.so ? [13:55] davmor2: so...what was happening when you got this? http://paste.ubuntu.com/6183885/ [13:55] davmor2: looks like glib got upset somehow... [13:56] kgunn: pass that was the only additional crash I found after removing the battery so I could get the device back up after it completely locked up on me [13:56] tedg: mind looking at this real quick http://paste.ubuntu.com/6183885/ just thot you might have an idea [13:57] kgunn, You don't have zeitgeist installed [13:58] davmor2: ^ [13:58] packaging mistake ? [13:58] davmor2: the qtubuntu-android-dbgsym package, from ddebs.ubuntu.com repo [13:58] tedg: this is image 75 [13:58] davmor2, what's the package name for bugs against Mir ? [13:58] davmor2: see https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages for info [13:59] greyback_: thanks [14:02] greyback_: I think it was more my apt-cache search foo letting me down :) [14:03] davmor2: :) [14:03] wow unity8 takes 100% cpu probably that's the reason for slowness I see on mako [14:03] om26er: https://launchpad.net/mir [14:03] davmor2, I wanted the package name, but I'll find it from that link. Thanks [14:07] kgunn, jibel: that's about as good a stack as I can get for the maliit issue http://paste.ubuntu.com/6183984/ jibel does that match yours? [14:08] guys, you're hogging our testing vms again! ;P [14:09] Saviq: I'm on a my own hardware so I doubt that :P [14:09] davmor2, it was a general remark to the Mir guys ;) [14:09] davmor2, yes, it seems to match [14:10] davmor2, why don't you submit the crash with apport and let the retracer do the work [14:10] ? [14:10] pitti fixed them few days ago to produce usable stack traces [14:10] jibel: cause it's fun :) [14:10] davmor2, you have too much spare time ;) [14:11] jibel: I have no spare time I have a script and installing a few dbg packages :) [14:13] jibel: how are you doing that? apport-collect/cli/bug? [14:13] davmor2, apport-cli /path/to/crash on the device [14:14] jibel: really...that simple huh ? [14:14] kgunn, So it seems the answer to your question is: people just putting data into Zeitgeist doesn't make it important enough to have. [14:14] davmor2, then send and when it asks to open the browser, copy the link to the browser on your desktop [14:14] Stupid shortsightedness [14:14] tedg: :) [14:14] kgunn, do we have a bug for 100% cpu usage of unity8 on mako or should I report one ? [14:15] om26er, read backlog [14:15] om26er: we have it [14:15] *scroll [14:15] om26er: we have a handful actually :) [14:15] davmor2: that last one is interesting http://paste.ubuntu.com/6183984/ seems you need libmirclient dbg symbols [14:16] kdub: ping [14:16] ok [14:16] kgunn: apparently I don't have some up-to-date packages so I'm updating the image and trying again, shuggin fashin packages [14:18] davmor2: ack [14:18] dandrader: before i forget [14:19] dandrader: if you mp, please target this branch https://code.launchpad.net/~mir-team/mir/development-branch [14:19] kgunn, sure [14:19] dandrader: we're using that as a staging area to prevent un-shepherded server api breaks [14:24] ricmm: he's west coast [14:24] ricmm: can anyone else help ? [14:24] altho he's prompt at ...he'll be in in 30min === greyback_ is now known as greyback|shops [14:37] kgunn: just wanted to see where he was at with the branch to remove the vsync signal [14:37] for the cpu usage bug [14:37] ricmm: yep :) me too...feel free to join our standup [14:38] ill join it for the first few mins [14:38] thx === alan_g is now known as alan_g|tea [14:41] * ricmm tea aswell [14:49] kgunn, the sleep&retry hack works, but a lot of cycles seems to be needed (i.e. a big delay between the device file showing up and udev rules getting applied to it), which is a bit unnerving === alan_g|tea is now known as alan_g [14:49] didrocks: what's that incantation to bump the deb changelog ? [14:49] dandrader: have you tested a few times...is it consistent? [14:49] kgunn: dch -i [14:50] didrocks: dang it...thot so...sorry for the ignorant interupt [14:50] kgunn: seems obvious isn't it? ;) (j/k) [14:50] no worry, if you don't practice it regularly, yeah, it's normal that you don't remember ;) [14:50] dandrader: i know you were going to try-wait in a loop...guessing it tries multiple times ? [14:51] dandrader: wonder if your attempts slow it down ? [14:52] dandrader: curious, are you able to run through autpilot test ? e.g. ubuntuuitoolkit per the bug [14:52] kgunn, anyway, the quick hack is not so quick in the end. aiming at the proper fix now [14:52] dandrader: so, not MP worthy ? [14:53] kgunn, if I have to spend time debugging a quick hack it's because it's not quick anymore :) [14:53] dandrader: sure [14:53] kgunn, and a second problem is hit: [14:53] "[InputReader] Touch device 'autopilot-finger' did not report support for X or Y axis! The device will be inoperable." [14:54] kgunn, so that might be a second hurdle waiting after the current one [14:54] * kgunn goes for another cup of coffee...and considers running into the street to be hit by oncoming traffic [14:55] lol [14:56] /me wonders how he has lived this long [14:59] kgunn: give it two more weeks [14:59] then we can all just get on a bus and do the same [14:59] :) [15:00] kgunn: ill skip the standup, I just saw emails from kevin that I had missed [15:00] its up for review, the changes requested are trivial [15:01] im sure kevin will have it ready within 1-2 hours [15:01] im testing it locally now and will do my review [15:05] ricmm: cool...appreciate the testing [15:17] good evening! === greyback|shops is now known as greyback [15:19] kgunn: is it possible to run a Wayland session compositor on top of the Mir system compositor? [15:20] mhall119: i would assume you mean in theory ? [15:20] yeah [15:20] and if there's been any discussion and/or plans [15:21] mhall119: sure...you'd have to write a wayland-mir back end [15:21] mhall119: its been discussed...like over beer...but nothing more than that [15:21] ok [15:24] kgunn, mhall119: FWIW we've had similar discussions about implementing Wayland using the Mir library. (IT would be "fun", but isn't currently planned or worked on.) [15:28] alan_g: would that work to run an upstream Gnome-Shell-as-Wayland-compositor on top of a Mir system compositor? I thought implementing the Wayland protocol would only let us run Wayland clients [15:32] kgunn: right completely fresh install on the default SF all I have crash wise is for _sbin_ureadahead.0.crash so I will delete that now and then reboot into mir and see what appears then [15:33] mhall119: Maybe. In that case the "Weston" session compositor would need to talk the protocol that the Mir system compositor uses (and currently that's the internal Mir one). For that you'd need to implement a session compositor as a Mir client. [15:33] But if the system compositor talked Wayland... [15:34] * s/Weston/Wayland/ [15:36] right, you'd have to implement a fb backend based on mir in weston [16:11] hi all, according to (http://unity.ubuntu.com/mir/installing_prebuilt_on_android.html) I should be able to run mir on nexus 7 with a special libhybris [16:11] questions 1) is this true? 2) if so, where do I get it? [16:11] pete-woods, i think that support landed, so no special one needed anymore [16:11] haven't tried in a while [16:12] kdbub: I just tried running it, and basically ran into this bug (https://bugs.launchpad.net/mir/+bug/1231917) [16:12] Ubuntu bug 1231917 in libhybris (Ubuntu) "Mir servers crash with SIGSEGV in libhybris-common.so.1 on Nexus7" [Undecided,New] [16:12] and figured that it must be that libhybris thing mentioned in the wiki [16:13] might be that hwc isnt working for nexus 7 [16:14] I don't know what hwc is (hardware compositor?), but I'm guessing I can't fix it myself [16:15] pete-woods, posted a suggestion on the bug [16:19] kdub: thanks for the suggestion, /system seems to be mounted ro, is there a safe way to change this? [16:19] mount -o remount,rw /system [16:20] okay [16:20] kdub: I just wanted to check I wasn't going to explode stuff if I did that [16:20] :) [16:21] if it explodes, move it back [16:21] :) [16:25] alan_g, on that deactivate-notifications-when-display-off branch, changed the name to mode(MirPowerMode) [16:25] reads much cleaner, no new enums or confusing bools [16:25] * alan_g goes to look... [16:26] sadly that removing the hwcomposer shared lib doesn't seem to help, but thanks for the suggestion [16:27] pete-woods, thanks for giving it a try [16:28] np [16:28] I am obviously the one with most to gain from a fixed display server [16:28] i'm wandering around hwc code for the next bit, so there's hope i can get it working... no time promises though [16:29] kdub: approved [16:29] alan_g, thanks [16:29] kdub: well I have my fingers and toes crossed :) [16:47] alan_g: kdub alf|xmir_devel .....any takers https://code.launchpad.net/~kgunn72/mir/bump-libmirserver5/+merge/188877 [16:47] its an easy one [16:51]