[00:06] <thomi> kgunn: OK, it's landed in trunk, I updated the SS
[06:04] <RAOF> Mmm.\
[06:08] <RAOF> A piglit run is an excellent way to trigger those radeon multihead glitches!
[06:13] <alf_> RAOF: glad you can reproduce them, is this with pure xmir, or with the multimonitor-stabilize branch?
[06:13] <RAOF> alf_: Pure xmir.
[06:14] <RAOF> The multimonitor-stabilise code looks fine (but not tested on this glitchy radeon yet)
[06:17] <RAOF> Actually, I had some thoughts about how to remove the rest of the mir_wait_for()s, which we should do to prevent those EQ overflows.
[06:27] <alf_> RAOF: +1, if it can be done reasonably
[06:30] <RAOF> alf_: Oh, has nested gbm got itself magically fixed while I was otherwise engaged, or is that still up for grabs?
[06:34] <alf_> RAOF: not fixed, mlankhorst tool a look at the code, and cleaned up the paths we should be taking (ping him for the cleanup). He said the code could work in theory, but for some unknown reason it doesn't...
[06:35] <RAOF> alf_: Heh. That was what I concluded when I looked at it in Lexington :)
[06:35] <RAOF> alf_: I think *something*'s closing a handle when it shouldn't, but I didn't start to track it down.
[08:19] <alf_> Saviq: How do I start unity8 manually on the phone? E.g. after a crash, or if I want to run with gdb or valgrind?
[08:21] <mlankhorst> RAOF: meh just hack the kernel to not re-use gem handles
[08:22] <alf_> jibel: Hi! How do I start unity8 manually on the phone? E.g. after a crash, or if I want to run with gdb or valgrind? So far I have 'export QT_QPA_PLATFORM=ubuntumirclient' and the 'unity8' but that crashes with http://paste.ubuntu.com/6191320/
[08:23] <alf_> Saviq: ^^
[08:33] <jibel> alf_, Hi, I use upstart with 'start unity8', the job is in /usr/share/upstart/sessions/unity8.conf
[08:33] <jibel> but it apparently only does an exec unity8
[08:34] <alf_> jibel: is that with the phablet user?
[08:34] <jibel> alf_, yes sorry, as phablet
[08:35] <jibel> sudo -i -u phablet
[08:35] <jibel> then start unity8
[08:35] <alf_> jibel: thanks! also, I don't seem able to ssh into the phone, although I can ssh locally in the phone, and network is working. Have you come across that?
[08:39] <pete-woods> hey guys, random question, I have a library (libusermetrics) that unity8 is using, it listens to dbus signals from a system dbus service
[08:39] <pete-woods> under mir, it doesn't seem to react to the signals any more
[08:39] <pete-woods> can anyone think of anything stupid I could have done that would tie it into x/surface flinger?
[08:40] <pete-woods> it's using the qt dbus libraries
[08:41] <jibel> alf_, no, I generaly use adb
[09:34] <Saviq> alf_, alan_g, hey guys, can you please have a look at bug #1235159 and bug #1235000
[09:34] <alf_> Saviq: sure
[09:37] <alan_g> Saviq: 1235159 is a consequence of fixing https://bugs.launchpad.net/bugs/1216237
[09:37] <Saviq> alan_g, yeah, I mentioned that in the description
[09:38] <Saviq> alan_g, but couldn't we find out that the socket is stale? or would that be unity8's / unity-mir's responsibility?
[09:41] <alan_g> Saviq: Of course it is *possible* to find out. But it does complicate things - what is the use case that requires it?
[09:41] <Saviq> alan_g, it happens in connection with the "can't unblank" issue
[09:42] <Saviq> alan_g, starting unity8 with mir when screen is off results in that ↑
[09:42] <Saviq> alan_g, then, when you kill it and want to try again, the socket's preventing it from starting
[09:44] <alan_g> Saviq: so, a possibly simpler solution would be an atexit handler that deletes the socket?
[09:44] <Saviq> alan_g, sure, if that's not in place yet?
[09:45] <alan_g> Saviq: I believe not - although it would depend on how violently the process is killed
[09:46] <Saviq> alan_g, yeah, so not reliable enough at times
[09:46] <Saviq> alan_g, one other idea would be for the upstart job to delete it on startup
[09:46] <Saviq> alan_g, arguably when the unity8 job starts, there should not be a mir socket lying around
[09:48] <alan_g> Saviq: arguably the mir socket shouldn't outlive the process - there must be more Mir can do to clean up. I'll look into it this afternoon.
[09:49] <Saviq> alan_g, thank you
[09:49] <alan_g> alf_: is the blanked screen one something you've got a handle on?
[09:52] <alf_> alan_g: I am not very familiar with that part of the android code, but I will give it a try, when I am done with https://bugs.launchpad.net/mir/+bug/1234609
[09:52] <alan_g> alf_: me neither. Thanks
[10:29] <alf_> Saviq: what part of unity8 exactly depends on libmirserver? That is, if I change libmirserver (breaking ABI), what other libraries do I need to rebuild to try it out?
[10:34] <alf_> Saviq: the rdepends I see are libunity-mir1 and libubuntu-application-api-mirserver1
[10:34] <Saviq> alf_, yeah, sounds right
[10:34] <Saviq> greyback, anything else ↑ ?
[10:34] <gema> hi, any mir dev around at this time?
[10:35] <gema> or anyone using mir on their phone daily
[10:35] <greyback> alf_: that's it
[10:36] <alf_> Saviq: greyback: thanks
[10:36] <Saviq> gema, alf_ and alan_g are devs
[10:37] <gema> Saviq: ack
[10:37] <alan_g> gema: what's up?
[10:37] <gema> alf_, alan_g I have observed a big degradation in performance overnight to the point that hhis morning my phone was almost non responsive
[10:37] <gema> alan_g: is this something you guys are aware of?
[10:38] <gema> alan_g: and my batery was almost completely drained, as well
[10:38] <ogra_> gema, did you log in and check with top whats eating your device ?
[10:39] <ogra_> (very unlikely thats Mir)
[10:39] <gema> ogra_: no, I didn't I was on the move this morning when this happened
[10:39] <gema> ogra_: mir is the only thing I have enabled yesterday that is super new
[10:39] <gema> ogra_: I have been leaving my phone overnight since day one and doing same test cases as yesterday night in the morning
[10:40] <gema> ogra_: ok, so your theory is that there is some other process at 100%
[10:40] <gema> ogra_: the only reason I am blaming mir is because the transitions were super slow , the gallery would come up white screened, etc
[10:41] <gema> ogra_: by the time it was a brick and I checked at home, top looked ok
[10:41] <ogra_> gema, there are knoen issues with unity8 and suspend under Mir
[10:41] <gema> ogra_: what does suspend mean in this context?
[10:41] <ogra_> ?
[10:42] <gema> I haven't suspended the phone, does it go into suspend mode after a while or.. ?
[10:42] <ogra_> your device is always suspended unless the screen is on
[10:42] <gema> ogra_: but it can take calls
[10:42] <ogra_> yes, that bit isnt suspended
[10:42] <gema> ogra_: so it is not totally suspended
[10:42] <gema> ogra_: can I adb into it if it is suspended?
[10:42] <ogra_> arm allows to keep single devices unsuspended
[10:43] <ogra_> it is suspended
[10:43] <gema> ogra_: ok
[10:43] <ogra_> if you connect a cable USB (and adbd) are unsuspended
[10:43] <alf_> gema: there was a bug about unity8 + mir taking 100% cpu, it seems to be fixed in the latest devel-proposed image (80)
[10:43] <gema> alf_: ack, will move to that one then
[10:43] <ogra_> (and everything you need to use adbd ... which means the whole system wakes up in this case
[10:43] <ogra_> )
[10:43] <gema> ogra_: ack
[10:45] <gema> alf_: thanks, will try system settings on that one and keep it running for a day or so to see if it degrades
[10:45] <gema> alf_: in fact today is friday, I am going to run it over the weekend :D
[10:46] <alf_> gema: even better :)
[10:46] <gema> alf_: thanks!
[10:47] <gema> ogra_: whilst I have your attention, do you know if this change is on image 80: http://bazaar.launchpad.net/~indicator-applet-developers/indicator-messages/trunk.13.10/revision/383
[10:47] <gema> ogra_: or where do I check for it
[10:50] <ogra_> if you click on "back to branch summary"  you should see if it was merged some time
[10:50] <om26er> gema, I talked about the slowness with Saviq yesterday as well. He was not seeing it but I see it, very clearly
[10:50] <Saviq> om26er, I'm seeing it now, too
[10:51] <Saviq> om26er, gema, top shows nothing hogging the CPU, but there's definitely something wrong with unity8@mir there
[10:51] <ogra_> gema, and at the top of this branch you see that the package was released only 31min ago ... so will likely be in the next build
[10:51] <ogra_> (last commit that is)
[10:51] <om26er> Saviq, I can even note the slowness in a progress indicator If I look closely
[10:53] <gema> Saviq: good that you are seeing it, it's a bit sneaky to put a finger on it
[10:53] <gema> Saviq: I have been trying :/
[10:54] <gema> ogra_: ack, thanks
[10:54] <Saviq> ogra_, have you seen the device not waking up properly under Mir? I can ping it, but adb is not working nor does the shell come up?
[10:54] <ogra_> Saviq, nope, havent had that yet
[10:55] <Saviq> ogra_, it's what tsdgeos says in -touch
[10:55] <ogra_> Saviq, tsdgeos cant reboot
[10:55] <Saviq> ogra_, I think mine might be the same, really, only I misattributed it
[10:55] <gema> ogra_: I couldn't reboot in the end either
[11:00] <om26er> yeah, reboot does not work for me as well. have to press the power button for 10secs to bring it back to life
[11:03] <Saviq> alf_, for me it's very easy to reproduce gema's and om26er's slowdown - just run calculator app autopilot test suite - after it's finished everything just crawls :/
[11:03] <Saviq> alf_, top is silent, so is iotop
[11:03] <Saviq> swap isn't touched
[11:05] <gema> om26er: do you have a bug number?
[11:06] <om26er> gema, no, didn't report it (yet)
[11:06] <gema> om26er: ack, I am reflashing by now, please let me know number whenever you have it
[11:07] <om26er> gema, same here, reflashing. I'll report a bug now
[11:07] <gema> om26er: ack
[11:07] <om26er> Saviq, Should I report for unity8 or Mir ?
[11:07] <Saviq> om26er, both, please
[11:08] <Saviq> alf_, restarting just unity8 helps - so there's something going on between unity8 and mir for sure
[11:17] <om26er> gema, bug 1235190
[11:19] <gema> om26er: thanks
[11:19] <om26er> np
[11:19] <gema> om26er: confirmed :D
[11:20] <gema> Saviq, alf_: bug 123519
[11:20] <gema> oh, not that one
[11:20] <Saviq> nope ;)
[11:20] <gema> bug 1235190
[11:20] <gema> :D
[11:21] <alf_> gema: thanks
[11:22] <om26er> gema, can you try this: go to system settings there try to change the wallpaper, when the picker appear tap 'cancel' CRASH!!
[11:23] <om26er> it seems if an app tries to exit itself system hangs because the same problem happens in the video player when I tap it close button (the one on the extreme left)
[11:23] <gema> om26er: what happens is that if you have an extra app open, the flow goes to that app instead of going back to system settings
[11:23] <gema> om26er: can you try having only system settings open?
[11:24] <om26er> gema, I only had system settings opened. no other apps were opened.
[11:24] <gema> om26er: ok, let me try that
[11:25] <gema> om26er: doesn't crash for me but it takes two clicks to get rid of the gallery for some reason
[11:25] <gema> om26er: I am on image 80, btw
[11:26] <om26er> I am on 80 as well(just flashed) and the crash is pretty consistent.
[11:29] <Saviq> om26er, I think lool mentioned settings crashing around wallpaper selection
[11:29] <Saviq> om26er, please apport-bug it and affect mir
[11:34] <lool> goal is trying to identify the top issues (Mir or other things needing porting to Mir) that prevent most tests from failing; I'm sure there's commonality in the AP regressions we're seeing across the board
[11:37] <om26er> Saviq, that's bug 1235195
[11:37] <Saviq> om26er, can you apport-bug it so that we get the traceback?
[11:38] <Saviq> om26er, I mean apport-bug /var/crash/blah.crash
[11:38] <Saviq> om26er, or maybe apport-collect now? is it possible to send the .crash post-factum?
[11:48] <om26er> Saviq, I attached the .crash file. having hard time reporting a bug using apport-bug file.crash since I have to pull the file first to my laptop.. and apport does not seem to like that
[11:50] <Saviq> om26er, why do you have to pull that file over?
[11:50] <Saviq> om26er, apport-bug is there just fine on the device?
[11:50] <om26er> Saviq, apport bug is supposed to open a browser link, isn't it ?
[11:51] <Saviq> om26er, it will print it out for you
[11:51] <Saviq> om26er, just copy-paste to your desktop
[11:53] <om26er> Saviq, yeah. it worked with apport-cli :)
[11:55] <jibel> om26er, ubuntu-bug falls back to apport-cli if there is no display, if it doesn't it is a bug in apport
[11:58] <om26er> ok. reported a new bug https://bugs.launchpad.net/mir/+bug/1235209
[11:59] <om26er> its private while the retracer runs
[12:04] <alan_g> alf_: when you've got the headspace, would you take a look at https://code.launchpad.net/~alan-griffiths/mir/mir_lifecycle_connection_lost/+merge/189021
[12:04] <alf_> alan_g: sure
[12:30] <dandrader> ping kgunn
[12:30] <kgunn> dandrader: pong
[12:30] <dandrader> kgunn, so, did the guys try the autopilot tests on galaxy nexus?
[12:30] <dandrader> kgunn,  did they work?
[12:31] <kgunn> dandrader: yes...found out someone was picking up wrong
[12:31] <kgunn> dandrader: product variable...was using tuna instead of maguro
[12:31] <kgunn> dandrader: thomi fixed it in the ap plugin
[12:32] <dandrader> ah, great. so I wasn't crazy afterall :)
[12:33] <kgunn> dandrader: nope...you no crazy :P
[12:33] <kgunn> ok...brb
[13:09] <olli> alan_g, dandrader, do we have somebody looking at https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1233245
[13:09] <olli> Saviq, just mentioned it as an issue for AP tests that "type"
[13:10] <dandrader> olli, can start on it right away, if it's a priority
[13:10] <olli> dandrader, got other high priorities?
[13:10]  * dandrader as just getting started on https://bugs.launchpad.net/unity-mir/+bug/1234570
[13:10] <dandrader> s/as/was
[13:11] <olli> Saviq, is 1234570 less important?
[13:11] <Saviq> dandrader, that'd be what you call an interrupt ;)
[13:11] <Saviq> olli, ↑
[13:11] <dandrader> not really, still flashing my device with the latest stuff
[13:12] <olli> Saviq, iow: ok for dandrader to look at 1233245?
[13:12] <Saviq> dandrader, if you could look at the keyboard input, that would be nice - either with autopilot or the volume up/down keys - should effectively be the same issue
[13:12] <Saviq> olli, yes
[13:12] <olli> k
[13:12]  * olli is tired
[13:12] <olli> dandrader, thx!
[13:12] <olli> can you have it fixed in say... -1h ;)
[13:12] <dandrader> Saviq, olli np, will switch to the keys bug then
[13:13] <olli> thx man
[13:13] <dandrader> hehehe. unfortunately my time machine is broken at the moment :)
[13:14] <olli> so fixing that might be an even higher prio
[13:33] <alf_> alan_g: what's the purpose of the time limit in test_server_disconnect.cpp ?
[13:33] <alf_> alan_g: (in MyTestingClientConfiguration)
[13:34] <alan_g> alf_: To stop the test running forever (but maybe it isn't needed...)
[13:35] <alf_> alan_g: the problem I see is that if the timeout occurs we don't have a condition to check success/failure
[13:36] <olli> dandrader, kgunn just mentioned that racarr might be looking into that as well, pls coordinate when he is online
[13:36] <alan_g> alf_: then we won't have had a callback and we fail
[13:36] <alan_g> 243	+ EXPECT_CALL(mock_event_handler, handle(mir_lifecycle_connection_lost)).Times(1).
[13:37] <alf_> alan_g: ahh, missed that, thanks
[13:37] <alan_g> alf_: np
[13:39] <greyback> dandrader: please test unity-mir trunk for bug 1234570, I should have fixed that
[13:41] <dandrader> greyback, ah, good to know
[13:41] <dandrader> will leave a note on the bug itself
[13:46] <kgunn> greyback: do i need to get that on the "ask sheet" :)
[13:47] <greyback> kgunn: yep
[13:47] <kgunn> greyback: shall i say pull all trunk or cherry ?
[13:51] <kgunn> i said trunk...
[13:54] <alan_g> greyback: Can I get your opinion? Re getting apps to save state when the server goes away. rcimm suggested sending "mir_lifecycle_state_will_suspend", but I've proposed a new event "mir_lifecycle_connection_lost" in https://code.launchpad.net/~alan-griffiths/mir/mir_lifecycle_connection_lost/+merge/189021
[13:56] <greyback> kgunn: there's only 1 commit, so trunk
[13:57] <greyback> alan_g: why would an app need to distinguish the two events? In both cases, it should save it's state and prepare to be killed
[13:59] <alan_g> greyback: Well, I did it that way because I wanted to call "raise(SIGTERM)" for the latter
[14:00] <alan_g> greyback: And I am doing that in a default event handler
[14:02] <greyback> alan_g: the only distinction I see from the app's perspective is that, with "mir_lifecycle_state_will_suspend" it has 3 seconds to save its state, whereas with "mir_lifecycle_connection_lost" does it have any such time guaranteed?
[14:02] <greyback> because a suspended app may be killed at any time. We don't guarantee it will be resumed
[14:04] <alan_g> greyback: From my perspective "mir_lifecycle_connection_lost" allows the app to decide to save and then exit, or to drop the existing connection and try to connect again
[14:04] <alan_g> but maybe that is too flexible
[14:07] <greyback> alan_g: if it is possible to drop existing connection and try reconnecting, then I support having a different signal. I wouldn't use 'lifecycle' in the name though for that case
[14:07] <dandrader> olli, Saviq please ignore me. I was running under SF :/
[14:07] <olli> dandrader, ignored
[14:07] <Saviq> dandrader, thing is, it started working for me suddenly...
[14:08] <dandrader> Saviq, did you restart unity8?
[14:08] <Saviq> dandrader, yeah, like a few times
[14:08] <Saviq> dandrader, am restarting all the time due to bug #1235190
[14:10] <alan_g> greyback: There's nothing in Mir that require the process exits - it is "just" the connection that has gone bad. (Of course, the server may well be gone for a while.)
[14:11] <alan_g> greyback: Although defaulting to "raise(SIGTERM)" makes the Mir examples behave better when the server dies.
[14:11] <greyback> alan_g: sure, I just got the impression that reconnecting to new Mir server instance wasn't possible, that Mir held some client state it couldn't do without. If reconnect possible, I say it's better solution than kill/respawn
[14:13] <alan_g> greyback: Mir holds client state against the connection, clear down the connection and you can start again
[14:13] <dandrader> Saviq, are you sure you're not running under SF? :)
[14:14] <Saviq> dandrader, just checked, yes :)
[14:15] <alan_g> We have tests with multiple, independent connections from one client
[14:15] <greyback> alan_g: ok, well I approve the added signal. For my info, what client state does Mir hold? Surface geometry?
[14:17] <alan_g> greyback: The connection has info about the display and a collection of surfaces, the surfaces have geometry and buffer info
[14:17] <greyback> alan_g: ok, what I expected. Thanks
[14:19] <alan_g> greyback: do you want to suggest another name for the event?
[14:20] <greyback> alan_g: it isn't really related to lifecycle, so maybe just "mir_connection_lost" ?
[14:21] <alan_g> greyback: Well, it is part of the MirLifecycleState enum passed to the MirLifecycleEventCallback
[14:22] <greyback> alan_g: ok, "mir_lifecycle_connection_lost" will do
[14:26] <dandrader> Saviq, do you know what turns the screen on and off when you press the power button?
[14:27] <Saviq> dandrader, powerd
[14:27] <dandrader> Saviq, so powerd listens directly to the /dev/input/event files, right?
[14:28] <Saviq> dandrader, more or less, yes
[15:15] <davmor2> kgunn: quick test, Under mir, open the terminal popup the keyboard.  No rotate the phone, now open the keyboard again do both sides of the keyboard work
[15:20] <kgunn> davmor2: definitely skim osk bugs for rotation (and restest with SF...there were lots of issues previously)
[16:00] <davmor2> kgunn: very quickly if I do /home/phablet/.display-mir (reboot) and then do ps aux |  grep unity-system-compositor I should see it there right?
[16:00] <kgunn> davmor2: nope
[16:01] <kgunn> davmor2: your only means to see if mir is running on touch
[16:01] <kgunn> davmor2: is to ps aux | grep surfaceflinger
[16:01] <kgunn> davmor2: if you do not see it...then you're running mir
[16:01] <davmor2> kgunn: ah that showed nothing
[16:02] <davmor2> kgunn: thanks I had this horrible feeling that maybe part of it wasn't installed when I didn't see unity-system-compositor
[16:02] <kgunn> davmor2: yeah, bit of a negative test...cause on touch, mir is in the unity8 process
[16:03] <davmor2> kgunn: ah right okay that makes sense :)
[16:08] <davmor2> kgunn: also is there a way to get screenshot yet?  I'm assuming not but thought I would double check
[16:09] <kgunn> davmor2: not yet...its kinda anti-security in a way....we're talking about how to add for "special" apps to use for debug and such
[16:11] <kdub> can't you cat the fb? i thought that trick still worked
[16:14] <dandrader> racarr, ping
[16:45] <racarr> Morning
[16:49] <alan_g> Evening
[16:50]  * davmor2 resorts to using cheese as a screenshoter for mir.  Thinking outside the box :D
[16:55] <dandrader_> racarr, have you started working on that yesterday? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1233245
[17:00] <alan_g> kdub: I was targetting the wrong branch. Please re-review https://code.launchpad.net/~alan-griffiths/mir/mir_lifecycle_connection_lost/+merge/189375
[17:00] <kdub> done
[17:01] <alan_g> quick! ;)
[17:01] <alan_g> Have a good weekend!
[17:26] <racarr> dandrader: I think I will start working on it ASAP
[17:26] <dandrader> racarr, because I'm on it
[17:26] <racarr> the problem is unity8 can't really get focus the way things are set now
[17:26] <racarr> so I was planning to add a new component in unity-mir "KeybindingEventFilter"
[17:26] <racarr> which lets you like
[17:26] <dandrader> racarr, I'm thinking along the lines of adding an input filter for such key events in unity-mir
[17:26] <racarr> bind_key(keycode, surface)
[17:26] <dandrader> s/input/event
[17:27] <racarr> and uses the input-injecter
[17:27] <racarr> not yet quite landed
[17:27] <racarr> to inject them to the shell surface
[17:27] <racarr> yes. I think using an input filter is the way to go
[17:27] <racarr> but I think we should inject them to the shell surface so the rest of the shell
[17:27] <racarr> can handle as normal
[17:28] <racarr> bind_events_to_surface(std::function<bool(MirEvent const&)> consumes_event, std::shared_ptr<msh::Surface> const& target)
[17:30] <racarr> dandrader: Does that make sense?
[17:30] <racarr> the input injecter api which you can merge from ~robertcarr/mir/input-injecter-api
[17:30] <racarr> is very simple just, surface->inject_input(shared_ptr<InputInjecter>, MirEvent)
[17:31] <racarr> InputInjecter comes from the_input_injecter()
[17:31] <dandrader> by "inject them to the shell surface" you mean letting those volume key events reach shell's qt event loop in the same way as any other event
[17:31] <dandrader> then yes
[17:31] <dandrader> racarr, ^
[17:40] <racarr> dandrader: Yes
[17:40] <racarr> if that can be done just directly through Qt I guess that is fine
[17:40] <racarr> but there isnodirect
[17:41] <racarr> MirEvent->Qt translation code
[17:41] <racarr> because it goes through the ubuntu-platform-api
[17:41] <racarr> and the Event struct there
[17:41] <racarr> so I think using the InputInjecter, and injecting it on to the channel and the client reads it just like normal
[17:41] <racarr> will be the best way
[17:42] <dandrader> racarr, sure
[17:43] <racarr> ok sounds good to me
[17:43] <racarr> one thing to watch out for
[17:43] <racarr> is scan codes are not mapped to key codes
[17:43] <racarr> on the server side
[17:43] <racarr> but I think there is some AINPUT_KEY_VOLUME_DOWN scancode or such
[17:43] <racarr> that you can safely use
[17:45] <racarr> ok I am going to start reproducing crashes here https://docs.google.com/a/canonical.com/document/d/1b-X9tN2Q9c_5r39XzA-Ppebbjuin5zVf9SkAGMcdp9Q/edit#
[17:45] <racarr> and hopefully pick one off
[18:29] <racarr> yay think I found the problem in hold-surface-alive
[18:52] <mlankhorst> ]
[18:59] <racarr> Lunch!
[18:59] <racarr> will be verifying the fix to hold-surface-alive when I get back then using that environment
[19:00] <racarr> to reproduce some more bugs
[19:45] <racarr> Back
[19:59] <racarr> ricmm: taskcontroller.h:57:5: error: ‘upstart_app_launch_app_failed_observer_t’ does not name a type upstart_app_launch_app_failed_observer_t failureCallback;
[19:59] <racarr> do you know what I need?
[20:01] <dandrader> racarr, build from trunk
[20:02] <dandrader> racarr, lp:upstart-app-launch
[20:05] <racarr> dandrader: Thanks :D
[20:25] <dandrader> racarr, MirEvent takes the key code from android::InputEvent as it is, unmodified
[20:26] <dandrader> racarr, so AKEYCODE_* are used/valid there
[20:26] <dandrader> racarr, but those keycodes are not exported by mir headers
[20:27] <racarr> dandrader: you should be able to use KEY_VOLUMEDOWN and KEY_VOLUMEUP on the scancode
[20:27] <racarr> from linux/input.h
[20:28] <dandrader> racarr, ok, but I wonder what's the use of those mir key codes
[20:28] <dandrader> at the moment, it seems they're unusable
[20:28] <racarr> yes
[20:28] <racarr> xkb_mapper should be used
[20:28] <racarr> on the server side
[20:28] <racarr> to put xkb keysyms in the keycode
[20:28] <racarr> before the event filter
[20:42] <dandrader> racarr, and why we wanna use xkbcommon instead of whatever comes with android-input
[20:43] <dandrader> racarr, it's more powerful or better suited for desktop use cases?
[20:43]  * dandrader just skimmed through the subject
[21:20] <racarr> kdub: I am getting lots of could not unblank display on startup
[21:20] <racarr> and it seems like maybe some other people are too
[21:20] <racarr> any idea?
[21:21] <kdub> logcat & dmesg?
[21:22] <racarr> kdub: what is logcat?
[21:22] <kdub> android-chroot; logcat
[21:23] <racarr> ah
[21:23] <racarr> D/hwcomposer( 2561): hwc_blank: Doing Dpy=0, blank=0
[21:23] <racarr> E/hwcomposer( 2561): hwc_blank: failed. Dpy=0, blank=0 : Operation not permitted
[21:23] <racarr> I/ServiceManager(  695): service 'display.qservice' died
[21:23] <racarr> I/ServiceManager(  702): Waiting for service SurfaceFlinger...
[21:23] <racarr> I/ServiceManager(  702): Waiting for service SurfaceFlinger...
[21:23] <racarr> I/ServiceManager(  702): Waiting for service SurfaceFlinger...
[21:23] <racarr> I/ServiceManager(  702): Waiting for service SurfaceFlinger...
[21:23] <racarr> I/ServiceManager(  702): Waiting for service SurfaceFlinger...
[21:24] <racarr> I/ServiceManager(  702): Waiting for service SurfaceFlinger...
[21:24] <racarr> I/ServiceManager(  702): Waiting for service SurfaceFlinger...
[21:24] <racarr> aren't you suspiscious
[21:27] <kdub> yep, something has wrong permissions
[21:27] <kdub> perhaps...
[21:28] <racarr> something
[21:28] <racarr> is unblanking the display
[21:28] <kdub> racarr, if you run the mir demos as root vs phablet, see if that has the same problem
[21:28] <racarr> mm
[21:28] <racarr> I think it will, the thing is the display really is unblanked
[21:28] <racarr> even when unity8 isnt running
[21:29] <racarr> nor sf
[21:30] <racarr> but the backlight is on...
[21:31] <racarr> kdub: Err, running the mir demos as root
[21:31] <racarr> also gives can not unblank display
[21:31] <racarr> operation not permitted
[21:31] <kdub> how did it get in that state?
[21:32] <racarr> I dunno.
[21:32] <racarr> seems like probably unity8 crashes on boot
[21:32] <racarr> because it never comes up
[21:34] <kdub> i just flashed pending, didn't see the problem
[21:34] <kdub> well, this
[21:34] <kdub> phablet-flash ubuntu-system --channel devel-proposed --no-backup
[21:35] <racarr> mm, that's what I did but then I rebuilt the world
[21:35] <racarr> I am sure something went wrong
[21:35] <racarr> too many variables right now...ill dig
[21:36] <kdub> i'm trying to rebuild the world too
[21:37] <racarr> kdub: Best of luck on your voyage :p
[21:37] <racarr> I think I may have just not installed platform api to the right path
[21:37] <racarr> but I think maybe if mir crashes leaving the screen unblanked
[21:38] <racarr> then it can fail to unblank the screen on startup and wont come back?
[21:38] <racarr> yay ok it works
[21:38] <racarr> swas just papi misinstall
[21:38]  * kdub feels like i'm a poorly-drawn seafarers in a 15th century sea chart
[21:38] <kdub> i'm now navigating through the straits of platform-api too
[21:39] <racarr> yay and hold surface alive fix works
[21:39] <racarr> so...the surface isn't inevitably alive
[21:41] <racarr> wow I didnt use the screen so it turned off
[21:41] <racarr> then I pressed the power button and it came back on
[21:41] <racarr> is this really mir
[21:41] <racarr> wow
[21:41] <racarr> it is :D
[21:41] <racarr> :p
[21:43] <racarr> kdub: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1235000
[21:44] <racarr> cant make sense of it yet though
[22:15] <racarr> how do I run touch apps from the command line
[22:15] <racarr> I thought it was something about desktop file hint
[22:15] <racarr> but not working
[22:16] <racarr> I need to not use upstart because I am trying to run it in GDB with electric fence
[22:16] <racarr> I guess I could run it with electric fence in upstart then attach in GDB