[02:02] <RAOF> Hurray for having next week off. This week is not my most productive ever :/
[08:03] <hikiko> hello
[08:03] <hikiko> alf__, ping!
[08:08] <tvoss> alf__, ping
[08:08] <hikiko> lol I think he has a meeting
[08:10] <alf__> hikiko: pong
[08:10] <alf__> tvoss: pong
[08:10] <robert_ancell> tvoss, ping
[08:10] <robert_ancell> (everyone else was doing it)
[08:11] <alf__> ping-pong madness :)
[08:11] <hikiko> lol
[08:11] <tvoss> man ...
[08:11] <tvoss> robert_ancell, pong
[08:11] <hikiko> ok tvoss ask first if you want :D
[08:11] <robert_ancell> tvoss, do you know who is maintaining LTT-ng in Ubuntu? If we take a dependency on it I'll do a MIR, but if it's another team I can leave it for them
[08:12] <tvoss> robert_ancell, it should be stephane graber for Ubuntu, the kernel team makes sure that our kernels are enabled
[08:12] <tvoss> robert_ancell, does that help?
[08:12] <robert_ancell> tvoss, thanks, I'll ask him
[08:13] <tvoss> robert_ancell, cool, let me know if I can help
[08:21] <alf__> hikiko: your turn :)
[08:26] <hikiko> alf__, i just merged after a longtime and I wonder what some new things are:
[08:26] <hikiko> eg. the internal native display
[08:26] <hikiko> and the internal client
[08:34] <alf__> hikiko: The internal client is the object in-process "clients" (like e.g. the shell) use to get the EGL handles they need to render
[08:36] <alf__> hikiko: The InternalNativeDisplay, is the implementation of MirMesaEGLNativeDisplay (which is what Mesa expects from us) for the in-process clients
[08:36] <alf__> hikiko: (this is of course only for the GBM case, Android uses other abstractions internally)
[08:37] <alf__> hikiko: (Android uses other abstractions internally = meaning not InternalNativeDisplay)
[08:39] <alf__> hikiko: btw, you don't any of this for render_to_fb to work
[08:53] <hikiko> cool :) so I can leave them for later
[08:54] <hikiko> I just need to understand what's going on :)
[15:04] <kdub> hello all, status, working on swapinterval 0 for android, was unsucessful in getting unity next to run
[15:09] <hikiko> kdub, ping
[15:09] <kdub> hello
[15:09] <hikiko> hello :)
[15:10] <hikiko> kdub, in my sdl branch I get a compile error in a header file: android_input_manager.h:26 because it is included in the src/server/default_server_configuration.cpp
[15:11] <hikiko> should this file be there or I can just delete the include line?
[15:11] <hikiko> I don't do an android build
[15:11] <kdub> hikiko, sure ,but the input stack is called 'android' too, its probably needed somewhere in the code
[15:13] <hikiko> so the input for the pc-build uses the android_input_manager.h?
[15:15] <kdub> yep
[15:17] <hikiko> kdub, we have an important bug in this header file
[15:18] <hikiko> we use the enum Status
[15:18] <hikiko> but
[15:18] <hikiko> Status is defined in the Xlib headers
[15:18] <hikiko> i mean #define
[15:19] <hikiko> in the android build you don't use Xlib
[15:19] <hikiko> so you don't get any error
[15:19] <hikiko> but in the gbm/sdl
[15:19] <hikiko> we have to either remove that header file from the build or use another name for Status
[15:20] <hikiko> can I fill a bug report?
[15:20] <alf__> hikiko: where does Status come from?
[15:20] <hikiko> X11/Xlib.h
[15:20] <alf__> hikiko: no I meant from our side
[15:21] <hikiko> src/server/input/android/android_input_manager.h
[15:21] <alf__> hikiko: found it in 3rd_party/android-input/android/frameworks/base/services/input/InputDispatcher.h
[15:22] <alf__> hikiko: But why do these too conflict? Why do X headers end up in src/server/default_server_configuration.cpp?
[15:23] <hikiko> because sdl includes the X headers
[15:23] <hikiko> and in any case I should include them :)
[15:24] <hikiko> even if I used pure Xlib
[15:25] <alf__> hikiko: right, but why do the headers end up included by src/server/default_server_configuration.cpp ? DefaultServerConfiguration shouldn't know anything about the implementation of Platform, Display etc which includes X/SDL headers
[15:27] <alf__> status: Continuing lttng experiments/integration, cleaning up unused code
[15:27] <hikiko> no idea
[15:29] <alf__> hikiko: well, that's something to look into then :)
[15:29] <hikiko> but I didn't write that file :s I have no idea of its internals why wouldn't we just rename status?
[15:33] <kgunn> hikiko: can you not use namespace here to solve your problem?
[15:33] <hikiko> no kgunn namespaces cannot override the preprocessor definitions
[15:34] <hikiko> the preprocessor substitutions happen before the compiler even sees the file
[15:34] <hikiko> so Status will be an integer
[15:34] <kgunn> hikiko: oh...see that now in scrollback...#define
[15:35] <hikiko> I think that maybe I should fill a bug report and send an email to the mailing list, maybe someone can suggest a solution :)
[15:36] <kgunn> hikiko: not really the way it works
[15:36] <kgunn> hikiko: i think you need to solve the problem & _then_ propose a solution
[15:36] <hikiko> I can solve the problem 2 ways but I don't know what I might break in the android build
[15:36] <kgunn> hikiko: if you end up with requiring a change to the name of something in mir, create a merge proposal & let it get reviewed
[15:37] <hikiko> ah ok :)
[15:37] <kgunn> hikiko: ah...but that's where testing comes in :)
[15:37] <kgunn> hikiko: prove it to yourself
[15:39] <hikiko> should I setup an android environment to test this? I have a nexus galaxy, does mir work there?
[15:43] <alf__> hikiko: yes, although I guess as a first step it would be enough to check that everything builds (which you can do without a phone)
[15:44] <alf__> hikiko: I am still curious how the X11 headers end up in default_server_configuration.cpp . Where are you including SDL, X11 headers in the code?
[15:44] <hikiko> alf__, you mean if that if I choose the android platform in ccmake I can build it in the pc
[15:44] <hikiko> only in sdl/display.cpp, sdl/display.h
[15:45] <kdub> hikiko, you can cross compile from the pc
[15:45] <hikiko> kdub, are there any instructions on how to do it?
[15:45] <alf__> hikiko: for building on Android check http://unity.ubuntu.com/mir/building_source_for_android.html
[15:46] <hikiko> ah cool :D
[15:47] <alf__> hikiko: set up the repos/get all the dependencies mentioned there, and at the last step run the ./cross-compile-chroot.sh script
[15:48] <alf__> hikiko: are you including sdl/display.h somewhere?
[15:48] <hikiko> where can I get this script from?
[15:48] <alf__> hikiko: its in the root directory of the tree
[15:49] <alf__> hikiko: (note: check the "cross compile" part of the guide)
[15:49] <greyback> kdub: hey, did you succeed in running qml-phone-shell on the phone yesterday?
[15:50] <hikiko> oh I see alf__ thank you!
[15:50] <kdub> greyback, no, hit a corrupt stack
[15:51] <greyback> kdub: strange, want me to investigate anything?
[15:51] <hikiko> ok, I will try to remove the .h first and if I get a break in android I will rename the enum and propose a merge
[15:51] <kdub> greyback, i still haven't ruled out that I set it up wrong somehow, so probably nothing to investigate yet
[15:52] <greyback> kdub: ok, well ping me if I can help.
[15:52] <kdub> sure, thanks
[16:06] <kgunn> greyback: should we get one of Pat's guys to try your instructions ?
[16:07] <greyback> kgunn: they're very preliminary, things will get a whole lot easier once platform-api stuff settles down. But I have no objection
[16:15] <kgunn> racarr: might join #ubuntu-touch
[16:16] <kgunn> rsalveti is going to give mir/unity8 build a whirl
[16:16] <rsalveti> cool, will give it a try later today (after uds)
[16:29] <alf__> hikiko: my suggestion is to find out if you can avoid the naming clash, by finding out why X11 headers end up in default_server_configuration.cpp (and fixing that)
[16:36] <hikiko> alf__, that's a solution only if we are 100% sure that we don't want to include X11 headers and android headers together
[16:37] <hikiko> the problem is not the default_server_configuration.cpp but
[16:37] <hikiko> that we include that android_something.h
[16:37] <hikiko> if we include it elsewhere at somepoint
[16:37] <hikiko> we ll end up to have the same problem
[16:37] <hikiko> what I think is a better solution
[16:38] <hikiko> is to not include android header files at all in a pc build
[16:38] <hikiko> :s/pc/non-android
[16:41] <greyback> kdub: racarr: We plan to have Mir to run as non-root user, right? Can you quickly say why right now we must run it as root?
[16:42] <kdub> greyback, because sf does it, at least on android :)
[16:42] <kdub> tbh, haven't tried it non-root on android much
[16:43] <greyback> kdub: oh ok then /me gives up :)
[16:44] <greyback> kdub: there's so much about this layer I yet don't understand, so I'm full of questions like these.
[16:44] <alf__> hikiko: but that's the android input stack which now is mir's input stack for all platforms, we can't disable it
[16:44] <alf__> hikiko: for any platform
[16:45] <hikiko> that's why I think that I a rename is the best solution
[16:45] <hikiko> I'll just rename the enum :)
[16:46] <hikiko> and then you can include the file everywhere
[16:48] <alf__> hikiko: that will just hide the underlying problem, i.e., that somehow X11 headers get included where they are not supposed to be included
[16:51] <alf__> hikiko: I would be all for renaming if we actually needed to include both the input and X11 headers, but that doesn't seem to be the case... we get a spurious X11 header inclusion somehow
[16:56] <hikiko> I understand what you mean and it's interesting to find why it happens, my point is that the rename is necessary if we are going to use the android input stack and the X at the same time, we ll end up to have similar conflicts anyway
[17:03] <alf__> hikiko: when/if we get that problem, we can fix it then :)
[17:07] <hikiko> we have it now
[17:30] <racarr> Unlikely but possible cause of shell crash
[17:30] <racarr> perhaps qtubuntu/platform API were built against mesa EGL headers (seems like hybris is built this way in packaging for example)
[17:31] <racarr> o we ran in to the same old eglplatform.h nonsense
[17:31] <racarr> which doesn't matter on 32 bit machines?
[17:31] <racarr> nvm
[17:49] <racarr> ok speculating about this bug is getting me nowhere so im flashing my nexus 4
[17:49] <racarr> google claims it backs up all my app data anyway ;)
[17:49] <kdub> racarr, use clockworkmod backup
[17:50] <racarr> kdub: Even better
[17:51] <racarr> You can multiboot nexus 7 but no one wrote it for nexus 4
[17:53] <racarr> kdub: Oh wait, but this is literally a stock device so I have to oem unlock and clear it to install clockwork right?
[17:53] <racarr> that will be good the second time though
[17:53] <kdub> racarr, right
[17:54] <tvoss> kdub, ping
[17:55] <kdub> hey tvoss
[17:55] <tvoss> kdub, hey, did you have a chance to debug greyback's issue?
[17:56] <kdub> no, working on other performance things though
[17:56] <tvoss> kdub, okay
[17:57] <racarr> tvoss: I am working on it
[17:57] <tvoss> racarr, okay
[17:57] <racarr> but got stuck in a 6 hour diversion of trying to get mir working on nexus 7 again
[17:57] <racarr> but um...
[17:57] <racarr> it didn't work :p
[17:57] <racarr> so now im in the minor diversion of flashing my nexus 4
[17:58] <racarr> the stacktrace is just nonsense so I will need to reproduce it
[17:59] <kgunn> racarr: wow...that frightens me off
[17:59] <kgunn> re: 6 hr diversion of n7
[18:01] <racarr> kgunn: Well tbh I didn't get that deep but it was really time consuming
[18:02] <kgunn> racarr: did you try to use the upstream or kdubs libhybris
[18:02] <racarr> wait I didn't know where kdubs was anymore
[18:02] <racarr> but I tried to use the upstream and tried to backport it myself
[18:03] <racarr> then tried to backport it myself again better
[18:03] <racarr> haha
[18:03] <racarr> same segfault in  um
[18:03] <racarr> pthread_mutex_lock all around
[18:03] <racarr> well thats not true, the first time I tried to backport it, it segfaulted very easly in a corrupt stack
[18:03] <racarr> then the upstream version, and my second backport
[18:04] <racarr> print much more debug info about loading android libraries and finding the tegra 3
[18:04] <racarr> and then segfault in pthread_mutex_lock
[18:04] <tvoss> racarr, that's a known issue with hybris
[18:05] <tvoss> racarr, at least for the nvidia driver, it comes down to the fact that nvidia's driver uses a mutex shared across processes
[18:05] <racarr> tvoss: https://github.com/libhybris/libhybris/pull/49
[18:05] <racarr> this is what we mean by upstream in this conversation
[18:05] <racarr> but it doesn't work
[18:06] <racarr> libhybris trunk is very different looking from what we are using, so I am guessing
[18:06] <racarr> it needs to be backported by something more intelligent than diff and dumbly resolving conflicts
[18:11] <racarr> building clang too
[18:25] <racarr> currently on a phone call from ubuntu, wild
[18:40] <racarr> nexus 4 seem to overheat in calls
[18:40] <racarr> haha
[18:46] <racarr> kdub: Any advice with wireless on nexus 4? It claims to assosciate to my network but no connection (nexus 7 worked with no intervention)
[18:47] <kdub> mine worked fine from the ubuntu wireless interface
[18:47] <kdub> phablet-network-setup might help too
[18:47] <kdub> (just copies your laptop's wireless conf on over to the device)
[18:47] <racarr> annnd it magically fixes it
[18:47] <racarr> self
[18:47] <racarr> :)
[19:32] <racarr> I thought mir was running but really surface flinger was just bugging out :(
[19:34] <racarr> kdub: ...um...have you ever seen
[19:34] <racarr> ...inverted? colors
[19:34] <racarr> I think this is inverted
[19:34] <racarr> its not inverted
[19:34] <racarr> white is white but orange is purplke
[19:34] <racarr> red is blue
[19:34] <racarr> ok
[19:34] <kgunn> usually pink/green
[19:34] <racarr> format mix up
[19:35] <kgunn> is when rgb formats get screwed
[19:35] <racarr> I think
[19:35] <racarr> this is unity in mir
[19:35] <racarr> XD
[19:35] <kgunn> meaning like ubuntu purple/orange ?
[19:36] <racarr> well like
[19:36] <racarr> the youtube icon is blue instead of read
[19:36] <racarr> the background is a deep purple
[19:36] <racarr> the camera icon is perfect almost
[19:36] <racarr> facebook i orange
[19:36] <kgunn> oh cool....
[19:36] <kdub> sounds like an rb flip
[19:36] <kgunn> yep
[19:36] <racarr> mm
[19:36] <kgunn> bgr rgb
[19:36] <racarr> wait so
[19:36] <racarr> why didnt it crash
[19:37] <racarr> I was expecting it to segfault XD
[19:37] <racarr> like greybacks
[19:37] <kgunn> if its 888 then the bit sizes are the same
[19:37] <kgunn> no worries...just interpretted wrong
[19:37] <kgunn> http://graphics.github.io/bltsville/
[19:37] <kgunn> this is really common
[19:38] <kgunn> tried solving with this open project
[19:38] <kgunn> actually this one related to it http://graphics.github.io/ocd/
[19:39] <racarr> kdub: So if there are things on the screen and ps aux | grep surface gives me nothing
[19:39] <kgunn> lots of people get bgr/rgb swapped due to differing spec's/interpretations
[19:39] <racarr> I should be pretty confident it's mir XD? I'm trying to confirm
[19:39] <racarr> the right QML phone shell is running, etc.
[19:39] <kgunn> can you run dumpsys SurfaceFlinger from the android shell
[19:39] <kgunn> that would tell you if surface flinger is rendering
[19:39] <kdub> yeah
[19:39] <racarr> dumpsys command not found?
[19:40] <kgunn> gotta be in the android shell
[19:40] <racarr> as in
[19:40] <kgunn> not an adb command
[19:40] <racarr> adb shell
[19:40] <kgunn> yep
[19:40] <racarr> I don't have it
[19:41] <kgunn> hmmm, weird....i don't either
[19:41] <kgunn> on my ubuntu device
[19:41] <racarr> oh
[19:41] <racarr> I know how to figure out XD
[19:42] <racarr> ill run a mir client :p
[19:42] <racarr> I do have a tmp/mir_socket so seems pretty promising
[19:42] <racarr> also the screen is blue which seems unlikely to be something that surface flinger would do
[19:43] <racarr> oh cool
[19:43] <racarr> it is mir
[19:43] <racarr> ...um
[19:43] <kgunn> so does that mean we've been looking at surfaceflinger this whole time :-/
[19:43] <racarr> ?
[19:43] <racarr> No.
[19:44] <racarr> the ...um is because
[19:44] <racarr> my whole point here was to figure out why the inproces-shell doesn't run inprocess on the nexus 4
[19:44] <racarr> but then it does
[19:44] <kgunn> :D
[19:44] <racarr> so now I have to find out why it crashes for other people XD
[19:44] <kgunn> you cured it!
[19:44] <racarr> and
[19:44] <racarr> figure out how to make
[19:44] <racarr> blue
[19:44] <racarr> orange
[19:44] <racarr> red
[19:44] <racarr> something
[19:45] <racarr> im going to do that first XD
[19:45] <kgunn> wondering if that's the Qtubuntu plugin pixel cfg format
[19:45] <kdub> i'd look there first
[19:45] <racarr> Yeah
[19:45] <racarr> 95% sure that's what it i
[19:46] <kgunn> other could be our setting on the hw for color fmt is wrong :)
[19:46] <racarr> trying to find the debian source for the packages gerry poted on chintrap
[19:46] <racarr> kgunn: No I would be willing to bet somewhere in
[19:46] <racarr> actually somewhere in ubuntu_application_api_mirserver
[19:46] <racarr> there is like
[19:46] <racarr> pixel_format = argb // TODO: ~racarr lol
[19:46] <kgunn> :D
[19:47] <kgunn> doh!
[19:47] <racarr> ah yep there it is
[19:47] <racarr> *grin*
[19:49]  * kgunn kinda disturbed "we" took out dumpsys....awfullly useful
[19:50] <racarr> hmm
[19:50] <racarr> I cant get at the pixel formats from libmirserver easily right now...
[19:50] <racarr> need to pass the buffer allocator through
[19:51] <racarr> computers sure are fun
[19:54] <racarr> why is it magically fixed...ugh
[19:54] <racarr> maybe it really was the eglplatform.h nonsense and I don't understand
[19:54] <racarr> integer promotion rules
[19:58] <kdub> racarr, might be, i don't think i tinkered with that eglplatform.h fiel
[19:58] <racarr> kdub: It's fixed in the PPA now
[19:58] <racarr> my thought is that if the qtubuntu backage was built in pbuilder
[19:58] <racarr> it used the mesa headers
[19:59] <kdub> i don't know that the android build draws from that ppa
[19:59] <kdub> at least the scripts
[19:59] <racarr> mm
[19:59] <racarr> well im ust going to try and fix the colors for now and sync up with greyback tomorrow
[20:08] <racarr> cross your fingers :)
[20:09] <kgunn> toes as well
[20:10] <racarr> hey cool the colors are right
[20:11] <racarr> feels really smooth
[20:11] <racarr> gesture are all easy to use :)
[20:12] <racarr> it's always so anticlimatic
[20:17] <kdub> great :)
[20:17] <kdub> racarr, yeah
[20:19] <tvoss> racarr, which device?
[20:20] <kgunn> racarr: oh don't worry....crazy will arrive
[20:21] <racarr> tvoss: Nexus 4
[20:21] <racarr> with inprocess mir shell :)
[20:25] <tvoss> racarr, epic :) video?
[20:26] <racarr> tvoss: After lunch. It's not much of a video though because it will look just like the out of process stuff except applications wont work :p
[20:26] <kgunn> tvoss: like mirco said...strange milestones....we want nothing to change :)
[20:26] <kgunn> even tho we are changing
[20:27] <racarr> tvoss: A cooler video would have been when r and b were swapped
[20:27] <racarr> "Ubuntu Phone: Midnight-ice theme"
[20:28] <kdub> midnight ice blur
[20:28] <kdub> the next big thing i hear ;-)
[20:28] <kgunn> oh man....i want that.....mightnight ice blur phone!
[20:29] <racarr> maybe ill get a transfer to marketing
[20:29] <tvoss> racarr, ack :)
[20:30] <kgunn> :D
[20:34] <racarr> Ok lunch!
[20:39] <kdub> thats a good idea
[21:50] <kgunn> robert_ancell: aren't you on baby duty?
[21:51] <robert_ancell> kgunn, Not until Tuesday
[21:51] <kgunn> robert_ancell: ok, your mail was just a pre-emptive strike
[21:51] <robert_ancell> kgunn, yep
[21:52] <kgunn> racarr: kdub & greyback makin' all kinds of progress
[21:53] <kgunn> robert_ancell: they have the inprocess shell working on n4
[21:53] <robert_ancell> kgunn, nice
[22:00] <racarr> gosh the mission is charming :)
[22:00] <racarr> Walking around for lunch now includes trees which is a big plus