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