[01:19] <robert_ancell> RAOF, did you flash your nexus 4? Any gotchas?
[01:19] <RAOF> robert_ancell: Yeah, I've flashed my nexus 4. No gotchas that I can remember.e
[01:20] <RAOF> Except that you can't keep the screen off but the device on, so it's less interesting as a build box than I hoped :)
[01:20] <robert_ancell> RAOF, because it emits too much light?
[01:21] <RAOF> robert_ancell: No, not really. It's aesthetically displeasing.
[01:21] <RAOF> I could totally use it as a buildbox.
[01:21]  * robert_ancell hears the worlds smallest violin
[01:21] <ogra_> just turn the brightness to 0
[01:21] <ogra_> there is a sysfs handle for it
[01:22] <RAOF> Oh, nifty.
[01:22] <ogra_> (its just linux ;) )
[01:23] <ogra_> though i wouldnt recommend to build on an eMMC/SD card
[01:24] <duflu> I wonder how that compares to using the Nexus 7 as a build box (which I found quite successful)
[01:24] <ogra_> the SoC is definitely a lot more powerful
[01:24] <duflu> Though if you can cross compile from a PC, that wins
[01:25] <ogra_> but you dont have USB host mode ...
[01:25] <ogra_> well, for packages that are designed for cross building, thats true
[01:25] <RAOF> Sounds like a job for sshfs!
[01:25] <duflu> Why do you need USB host mode when you have scp/rsync? :)
[01:26] <ogra_> well, sshfs/rscny over wlan ...
[01:26] <ogra_> could use plain nfs as well, i guess that would be faster ...
[01:26] <duflu> Yeah wifi's not much worse than USB 2.0
[01:26] <ogra_> but if these are the chouces i'd actually take the MMC
[01:26] <ogra_> *choices
[01:27] <ogra_> though stilll, a chromebook is $250 ... and comes with  USB 3.0
[01:27] <duflu> Ugg. New keyboard. I'm very slow now. Please be patient.
[01:27] <RAOF> Ah, *there* we go - /sys/class/backlight/lm3530/device/lm3630_backlight_on_off
[01:27] <ogra_> if you want a serious device to do native arm builds thats the way to go
[01:29] <RAOF> Is building on the MMC likely to kill the flash quickly?
[01:30] <ogra_> nah, i doubt you will manage that in the time you own the phone
[01:30] <ogra_> but its slow I/O
[01:30]  * duflu wonders what's wrong with the existing Mir cross-compile script
[01:31] <ogra_> if your build requires at least some disk I/O it will have quite some impact
[01:32] <ogra_> duflu, in the end it will be packaged and have a bunch of dependencies ... and that means native builds
[01:32] <ogra_> while you build raw upstream code and are sure you have a cross bits in place thats different
[01:32] <ogra_> s/a/all/
[01:33] <ogra_> cross building packages with a dependency chain is trickier :)
[02:12] <TheMuso> RAOF: Do you not have a pandaboard at your disposal? Would that not be a suitable build board?
[02:15] <duflu> TheMuso: Pandas are hopelessly slow. Nexus 7 blows it out of the water and supposedly Nexus 4 is similar
[02:16] <duflu> ogra_: Thanks you made me realise I can finally buy Chromebooks in Australia. But $349 :P
[02:26] <TheMuso> duflu: Rotery disk is better than flash for building no?
[02:26] <TheMuso> At least there is that option with panda.
[02:26] <TheMuso> But I guess you could use rotery with the Nexus7.
[02:27] <TheMuso> duflu: And out re Chromebooks in Australia.
[02:28] <TheMuso> s/out/ouch/
[02:28] <duflu> TheMuso: It's true the bottleneck on Nexus 7 is slow flash. But I recall that the panda having only two cores (and slower) was a bigger issue compared to the 4-core Tegra3
[02:28] <TheMuso> Fair enough.
[02:32] <TheMuso> I guess we need better dev boards then. :p
[02:34] <duflu> Well if ARM servers with far-too-many-cores are now real products then that would be a good build solution, surely... ?
[02:34] <duflu> I think it was HP talking about such products in Copenhagen.
[02:36] <duflu> www.hp.com/go/moonshot
[02:46] <duflu> Of course, that's for Ubuntu builds. Not your desk ;)
[02:52] <robert_ancell> RAOF, does installing the PPA mesa hose the phablet UI?
[02:52] <RAOF> robert_ancell: I don't see why it would.
[02:52] <RAOF> robert_ancell: Does it? :)
[02:52] <robert_ancell> RAOF, we'll find out soon...
[02:53] <duflu> Surely surface-flinger does not depend on Mesa library paths....
[02:53] <duflu> Or anything "Mesa"
[02:54] <RAOF> Also, the PPA mesa shouldn't break anything that depends on Mesa *anyway*
[02:55] <duflu> True. My laptop still works with Ubuntu goodness
[07:31] <duflu> What's the _eventual_ preference for stride? Should it always represent #bytes or will it become #pixels?
[07:32] <duflu> (with respect to MirGraphicsRegion)
[07:35] <alf_> duflu: bytes
[07:36] <RAOF> Bytes is probably more useful, yeah.
[07:36] <duflu> alf_: Ta. And good morning
[07:39]  * alf_ notices that we now have an Android CI job (the buildng part of it, at least)
[08:39] <tvoss> alan_g, ping
[08:39] <alan_g> tvoss: ?
[11:16] <alf_> alan_g: fyi, I am working on changing render-surfaces to use DisplayServer(Configuration)
[12:53] <alan_g> alf_: Excellent!
[15:27] <racarr> Mew
[15:27] <racarr> Morning :)
[15:28] <alf_> racarr: Hello
[15:50] <alan_g> racarr: Hello
[15:50] <racarr> alan_g: Hi
[15:54] <racarr> alan_g: Btw wanted to ask you...seen any weird segfaults with
[15:54] <racarr> droidinput::sp, droidinput::Vector and finally the android atomics?
[15:55] <racarr> I thought I was going to make my big integration test for input branch pass last night and now segfaults in android atomics
[15:55] <racarr> tried with and without android types
[15:55] <alan_g> racarr: I haven't
[15:56] <alan_g> Is this a hybris/android target?
[15:57] <racarr> alan_g: No native x86
[15:59] <alan_g> Not seen it. Want me to look? (Yet.)
[15:59] <racarr> alan_g: I will try and make a reduced test case later. I haven't spent so much time on it yet
[15:59] <racarr> I was just hoping it sounded familiar
[16:00] <alan_g> Sorry to disappoint you
[16:01] <racarr> deciding what to do with prepare-for-inprocess-egl-clients now
[16:01] <racarr> :) no worries
[16:12] <racarr> it is weird because the android doesn't really need
[16:12] <racarr> a NativeDisplayContainer
[16:12] <racarr> so it would be possible to write the
[16:13] <racarr> mir_egl_native_display_is_valid using
[16:13] <racarr> an ifdef (just mir_connection_is_valid) on android
[16:13] <racarr> seperate versions of mir_egl_native_display_is_valid
[16:14] <racarr> or an android implementation (which is rather trivial)
[16:14] <racarr> but seems kind of like a verbose way to do nothing
[16:15] <alf_> status: investigating a graphical glitch in the WIP code to change render-surfaces to use DisplayServer(Configuration)
[16:17] <racarr> alf_: Any opinions on what to do with android for NativeDisplayContainer?
[16:17] <racarr> I am inclined to just move the definition of mir_toolkit::mesa_native_display_is_valid
[16:17] <racarr> to android/gbm
[16:17] <alf_> racarr: let me refresh my memory
[16:18] <racarr> alf_: :) Don't feel like you have to process it immediately
[16:18] <alf_> racarr: it would be refreshing change from trying to debug a graphical glitch :)
[16:20] <racarr> Aha...I know the feeling
[16:20] <racarr> the basic issue is pretty simple, mir_egl_native_display_is_valid uses mcl::EGLNativeDisplayContainer::instance which is defined in the gbm bits
[16:21] <racarr> along with the implementation of EGLNativeDisplayContainer
[16:21] <racarr> trying to decide if android should also implement EGLNativeDisplayContainer (seems unnecessary)
[16:21] <racarr> or one of these other approaches should be used
[16:23] <hikiko> hi
[16:24] <alf_> racarr: It would be a dummy implementation, so I don't see the harm in doing it this way. It would move the complication to the build system instead of the code.
[16:24] <alf_> racarr: (almost dummy implementation)
[16:27] <racarr> hmm
[16:28] <racarr> Im not sure which way to do it though (using the build system) so now I am kind of leaning
[16:28] <racarr> to just implementing the display container haha
[16:32] <alf_> racarr: IIRC, The only symbol that the rest of the code needs mcl::EGLNativeDisplayContainer::instance(), so defining it in src/client/android/android_native_display_container.cpp should do the trick
[16:32] <racarr> alf_: But it wants an instance of EGLNativeDisplayContainer returned
[16:33] <racarr> so have to write a little android stub
[16:33] <racarr> thats what I just did though :)
[16:33] <alf_> racarr: right, and great :)
[16:34] <alf_> racarr: perhaps Kevin will find the abstraction useful and use it more extensively in the android backend
[16:34] <racarr> thats what I am thinking
[16:34] <racarr> alan_g: prepare-for-inprocess-egl-clients is updated
[16:34] <racarr> android build works :)
[16:35] <alan_g> racarr: I'll look soon
[16:35] <racarr> Going to change https://code.launchpad.net/~robertcarr/mir/happy-monday-dedupe-more-stubs/+merge/153713 to approved if no one objects soon :)
[16:41] <alan_g> racarr: It will conflict with something I'm working on - but that's life
[16:43] <racarr> What are you working on?
[16:44] <racarr> hmm actually I need
[16:44] <racarr> another approve, I think no review since I merged trunk
[16:44] <racarr> I dunno if someone wawnts to review...
[16:44] <racarr> changes at 190-211 came in during trunk merge
[16:45] <alan_g> racarr: https://code.launchpad.net/~alan-griffiths/mir/refactor-frontend-Surface-cleanup/+merge/154138
[16:46] <alan_g> racarr: looking at prepare-for-inprocess-egl-clients
[16:51] <racarr> :) thanks
[16:51] <racarr> frntend-Surface-cleanup looks fine so far (quick read)
[16:51] <alan_g> racarr: that's what you MP would conflict with.
[16:51] <johnjohn101> any ideas on what video system will be best supported by mir (short term)?
[16:52] <alan_g> racarr: "+Cflags: -I@INCLUDEDIR@/mir" - can that be right?
[16:52] <racarr> err. let me look
[16:53] <racarr> alan_g: No its not
[16:53] <racarr> its left over from when we had like
[16:54] <racarr>  err.../usr/include/mir/mir_toolkit/api.h
[16:54] <racarr> r512 :)
[16:55] <racarr> hrm
[16:55] <racarr> my test doesn't seem
[16:56] <racarr> to fail or pass or crash or anything
[16:56] <alan_g> racarr: we need to nail down this naming issue.
[16:56] <racarr> it appears to exit unit tests normally
[16:56] <racarr> alan_g: Which, sorry
[16:56] <racarr> for headers?
[16:56] <alan_g> racarr: and their directories and packages
[16:57] <alan_g> racarr: there's a reason the first TDD step is to write a failing test.
[16:58] <racarr> alan_g: It did fail until I implemented it
[16:58] <racarr> and then it failed in more surprising ways (the atomic stuff, which is now fixed)
[16:59] <racarr> but now it just runs, seems to go through the test
[16:59] <racarr> and exit google mock normally
[16:59] <alan_g> what was that (atomic stuff)?
[16:59] <racarr> but there is nothing about passing or failure or exceptions or errors or
[16:59] <racarr> anything
[16:59] <racarr> just wasn't keeping a droidinput::sp when I needed to
[16:59] <alan_g> Tried putting #error in the test body?
[17:00] <racarr> ?
[17:00] <alan_g> To prove you're compiling the test and haven't lost it in a merge
[17:00] <racarr> oh well I just tried that but yes
[17:01] <racarr> it is the test...
[17:01] <racarr> I can remove expectations
[17:02] <racarr> and get errors about unexpected calls etc
[17:02] <alan_g> racarr: could you be leaking the mock objects?
[17:02] <alan_g> Then their expectations are not validated
[17:03] <racarr> mm thought about that so then I tried verifying them
[17:03] <racarr> and also checking for leaks
[17:04] <racarr> the thing is it doesn't even print OK/FAIL or whatever
[17:04] <racarr> it just exits
[17:04] <racarr> tried breaking in exit
[17:04] <racarr> but its not informative
[17:04] <alan_g> racarr: puts("GOT HERE")?
[17:04] <racarr> it finishes the entire test
[17:04] <racarr> body
[17:04] <racarr> and invokes the tear down
[17:05] <alan_g> racarr: that's too weird.
[17:06] <alan_g> What's the branch, which test?
[17:07] <racarr> alan_g: lp:~robertcarr/mir/send-inputs-to-client
[17:08] <racarr> unit_tests/inut/android/test_android_input_manager.cpp
[17:08] <racarr> set_input_focus
[17:08] <alan_g> alf_: do we have a useful answer for johnjohn101 @"any ideas on what video system will be best supported by mir (short term)?"
[17:09] <alan_g> racarr: I'll see what happens here
[17:10] <racarr> alan_g: thanks
[17:10] <racarr> the thing is if you comment out
[17:10] <racarr> line 239
[17:10] <racarr> the expectations fail
[17:10] <racarr> but it pritns things and becomes useful again and properly faild
[17:10] <alan_g> racarr: bzr denies that branch exists
[17:11] <racarr> properly fails*.
[17:11] <racarr> err..
[17:11] <racarr> alan_g: Oh send-input-to-clients
[17:11] <racarr> not send-inputs-to-client
[17:11] <racarr> XD
[17:11] <alan_g> Wandering "s" ;)
[17:13] <alf_> johnjohn101: Do you mean what kind of GPU? Also, do you care about mobile devices or desktop?
[17:16] <alan_g> racarr: missing file?  fatal error: mir_test_doubles/mock_input_focus_selector.h: No such file or directory
[17:17] <racarr> whoops...sorry haven't done my pre push pass on this branch yet
[17:18] <alan_g> racarr: no worries - but I need that file to test what you have
[17:19] <racarr> alan_g: Pushed another rev
[17:19] <alan_g> racarr: ack
[17:20] <alf_> johnjohn101: in any case, on the desktop it's anything with a working DRM/KMS and GL (Mesa) driver (mostly tested with intel and radeon). For mobile is the nexus and galaxy nexus phones.
[17:21] <alf_> alan_g: racarr: Is anyone looking into stabilizing the VM CI build? If not, I will try to take a look tomorrow.
[17:22] <alan_g> alf_: what's the problem?
[17:23] <alan_g> racarr: I see the problem
[17:23] <racarr> Oh?
[17:23] <racarr> *prepares for facepalm*
[17:23] <alan_g> (But it does leak)
[17:23] <racarr> oh really
[17:23] <alan_g> racarr: I don't see the solution yet
[17:23] <alan_g> ;)
[17:25] <alf_> alan_g: racarr: BespokeDisplayServerTestFixture.focus_management is consistently failing in VM builds (both for CI and autolanding)
[17:25] <racarr> alan_g: Oh hmm wait something related to the MockInputDispatcher leaks?
[17:25] <racarr> alan_g: I have not looked yet no...didn't know it was
[17:26] <alan_g> alf_: I didn't know => haven't looked into it. All yours.
[17:27] <alf_> alan_g: racarr: ok
[17:27] <alf_> all: Have a great rest of day
[17:27] <alan_g> alf_: Have a great evening!
[17:30] <racarr> See you alf_
[17:31] <racarr> alan_g: Hmm wait even if I remove all the expectations I am still getting the same weird non-failure
[17:31] <racarr> but it was definitely failing earlier...what have I done!
[17:38] <alan_g> racarr: The process is exiting (with status 1)  after doing the TearDown() step. I have a vague recollection of seeing that with an attempt to access an already dead object during destruction.
[17:40] <racarr> hmm
[17:50] <racarr> status: Stuck and hungry so breaking to cook bacon and a bagel :)
[17:51] <racarr> during the day I sometimes think of myself as an object for transforming bacon, bread, and tea and C++ in to
[17:51] <racarr> different C++
[17:54] <ogra_> poor jono
[17:55] <ogra_> but at least he has a bagel as company
[17:56] <jono> lol
[17:58] <racarr> Took me a second!
[17:58] <alan_g> racarr: I don't see what is happening. No C++ exception, no signal and _exit() is called with an uninformative stack. Going to play chess instead.
[17:59] <ogra_> funnily you wrote that while on the ubuntu phone list the mail with "[Ubuntu-phone] No bacon?" rolled in
[17:59] <ogra_> we're really community driven these days :)
[18:00] <ogra_> bacon everywhere !
[18:01] <racarr> alan_g|chess: Enjoy :) I will figure it out
[18:01] <racarr> thanks
[18:15] <min2> hello
[18:17] <racarr> narrowed it down significantly...
[18:17] <racarr> something weird with droidinput::sp and gmock going on
[18:18] <racarr> surprising! ;)
[18:19] <racarr> oh or maybe not...it seems to really just be the construction of the window handle from the application handle...
[18:19] <racarr> maybe there is something I am missing about droidinput::RefBase
[18:25] <racarr> hmm
[18:25] <racarr> I fixed it but I don't understand how...and ran in tot he next problem! InputChannel constructor throws without real fds
[19:05] <racarr> hmm ok later maybe a factory and mocking for droidinput::InputChannel
[19:05] <racarr> for now the test can use a socketpair ;)
[20:08] <bcbc2> I'm running mir on 13.04 with the ppa. When I add 'type=mir' to lightdm.conf and restart lightdm it runs in low graphics mode. If I then reboot I just get a black screen. I'm following the instructions here: http://unity.ubuntu.com/mir/using_mir_on_pc.html Any hints on how to debug?
[20:18] <kgunn> bcbc2: did you "ensure you have the proper custom Mesa build installed"
[20:21] <bcbc2> kgunn: it says "If you installed Mir using the packages from mir-team staging PPA ..., you should be good to go.
[20:22] <kgunn> bcbc2: it sure does...and you should....hmmm
[20:26] <bcbc2> kgunn: I tested it with those instructions for "Running MIR natively". I used mir_egltriangle and it worked okay. Does that qualify as 'some-mir-client' in those instructions?
[20:27] <kgunn> bcbc2: yes
[20:27] <kgunn> its what you think....just a little gl triangle app rendering to a mir surface
[20:30] <bcbc2> kgunn: ok... good. So are there any log files I should be checking too troubleshoot the black screen? I've been rebooting into recovery mode and removing 'type=mir' before restarting to get around it.
[20:31] <johnjohn101> is mir shipping with the next version of ubuntu ( 13.10 maybe).
[20:31] <kgunn> bcbc2: sorry...i'm not the best at desktop x stuff...
[20:32] <kgunn> bcbc2: i'll be honest...i've been on quatal....wonder if its cause your on raring?
[20:32] <kgunn> bcbc2: no specific knowledge....just thinking aloud
[20:33] <bcbc2> kgunn: ok - cool. It's not a big deal. I'll maybe play around with quantal or take a break. Thanks.
[20:33] <kgunn> bcbc2: you prompted me to update a second hand machine i had to raring....maybe i'll try those instructions and see what gives
[20:34] <kgunn> also....i'll mention it to some of the other fellows who have more experience on x/compiz/mesa
[20:35] <kgunn> johnjohn101: shipping is kind of loaded
[20:36] <kgunn> johnjohn101: in general there is a goal/vision of convergence of what we achieved with the ubuntu touch/phablet
[20:36] <kgunn> if you read some of the spec
[20:36] <johnjohn101> next year is ok. i'm ready for ubuntu to be at the next level
[20:37] <kgunn> https://wiki.ubuntu.com/Mir
[20:37] <kgunn> johnjohn101: sorry...digging out links i'm slow :)
[20:37] <kgunn> one more
[20:38] <kgunn> https://wiki.ubuntu.com/UnityNextSpec
[20:38] <johnjohn101> tx kgunn
[20:39] <kgunn> not sure when you got disconnected
[20:39] <kgunn> but if you look at those 2 links
[20:39] <johnjohn101> last message from you was "one more"
[20:39] <kgunn> https://wiki.ubuntu.com/UnityNextSpec
[20:39] <johnjohn101> sorry working and connecting to clients and it resets
[20:39] <kgunn> np
[20:40] <kgunn> so those 2 links outline what/why and point to the how which is really in all the blueprints
[20:40] <kgunn> but you could think...focus is to get solid on "small screen" devices first
[20:40] <johnjohn101> kind of crazy for ubuntu to switch to QT on a dime
[20:40] <kgunn> then grow into "large screen" devices to achieve 1 code base to rule them all
[20:42] <kgunn> johnjohn101: it may seem a little crazy...but i think Qt evolved to the point where you can get gl goodness & great ease of use/fast development (as a toolkit)
[21:21] <racarr> [ RUN      ] AndroidInputManagerDispatcherInterceptSetup.server_input_fd_of_focused_surface_is_sent_unfiltered_key_events
[21:21] <racarr> Device added: id=0, name='', sources=0x00000101
[21:22] <racarr> [       OK ] AndroidInputManagerDispatcherInterceptSetup.server_input_fd_of_focused_surface_is_sent_unfiltered_key_events (4 ms)
[21:22] <racarr> Yay
[21:24] <kdub_> racarr, on device :) i saw our input library booting up the input devices
[21:25] <kdub_>  *?
[21:30] <racarr> kdub_: Probably!
[21:30] <racarr> the way it is in trunk is if you have permissions on the input device it should probe the appropriate ones and events will flow from kernel->event hub->input reader->input dispatcher->input dispatcher policy->event filters (there are none in trunk)
[21:30] <racarr> and then there will be no focused window so it will be dropped
[21:31] <racarr> this last branch is to hook up focus and
[21:31] <racarr> THEY GOOOOO
[22:25] <RAOF> Who wants to review client-side-buffer-age! It'll be fun!
[22:26] <racarr> RAOF: I will do it in just 10 minutes. it will be good to switch state back and forth before I do self review
[22:26] <RAOF> Oh, god. Self review. BAH
[22:30] <racarr> hehe
[22:30] <racarr> RAOF: https://code.launchpad.net/~robertcarr/mir/send-input-to-clients/+merge/154221 exists and is close to its final state if you want something t look at :) will propose properly after self review round after reviewing client-side-buffer-age!
[22:31] <racarr> But first, tea + food