[07:26] <duflu> Wow. Good anti-aliasing = almost readable text at 3px high
[07:30] <zzarr> duflu, what? 3px awesome
[07:31] <duflu> zzarr: Just admiring Google docs previews. And trying to read the docs in tiny print
[07:31] <zzarr> duflu, nice, what device?
[07:31] <duflu> zzarr: Desktop
[07:31] <zzarr> duflu, mir?
[07:32] <duflu> zzarr: No just Chrome...
[07:32] <zzarr> duflu, okey
[07:32] <duflu> But I shall try to make Mir as good in future
[07:33] <zzarr> duflu, you're a programmer @ Canonical?
[07:33] <duflu> zzarr: Yes :)
[07:33] <zzarr> duflu, awesome
[07:35] <zzarr> duflu, I have obtained the kernel config from my ASUS Chromebook Flip (ARM, RK3288)
[07:35] <duflu> zzarr: Want to try to use Mir?
[07:36] <zzarr> I know I some how need to extract the hardware parts in order to merge with the Ubuntu kernel and use Mir
[07:36] <zzarr> duflu, you're right on the money
[07:37] <zzarr> duflu, I can't think of a better OS for the computer then Ubuntu since it have a touch screen and can flip in to a tablet
[07:37] <zzarr> I can boot it from a SD card
[07:37] <duflu> zzarr: If the kernel supports DRI for your graphics chip then you can stick with the ChromeOS kernel (which helps a lot and often is more likely to work for some ARM devices than stock Ubuntu)
[07:38] <duflu> zzarr: What's in /dev/dri?  or /sys/class/drm?
[07:39] <zzarr> duflu, I'll have a look
[07:40] <duflu> I am a ChromeOS fan too. Although Google has a habit of using very old kernels in ChromeOS and Android
[07:40] <zzarr> in /dev/dri card0 card1 controlD64 renderD128 renderD129
[07:40] <zzarr> duflu, yes, I know
[07:41] <zzarr> duflu, other whys the Chromebook is awesome
[07:41] <duflu> Yeah ChromeOS is pretty. But once you run Ubuntu on a Chromebook it's profoundly faster (for Intel anyway). Which means Google's got a lot of improving to do
[07:43] <duflu> I recall they are building a new display system to solve that (and replace X11 that it still uses I hear)
[07:43] <zzarr> in /sys/class/drm I find card0 card1 card1-eDP-1 card1-HDMI-A-1 controlD64 renderD128 renderD129 version
[07:43] <duflu> Although there might be other reasons why their windowing system is slow
[07:44] <zzarr> my Chromebook uses a windowing system called freon
[07:44] <duflu> zzarr: OK, good news: Your ChromeOS kernel has a chance of just working with Mir (Ubuntu in a chroot installed via https://github.com/dnschneid/crouton). It's definitely worth a try. You sure that's ARM and not Intel?
[07:45] <zzarr> duflu, I have a crouton chroot installed
[07:46] <duflu> zzarr: You'll need to have it set up for fullscreen Ubuntu (not Ubuntu in the browser)
[07:46] <zzarr> duflu, it's an ARM I'm sure about that
[07:46] <duflu> Wow that Chromebook Flip looks like a great device
[07:46] <zzarr> duflu, it is :-D
[07:47]  * duflu adds it to the wishlist
[07:47] <zzarr> quad core, 4GB RAM :-)
[07:48] <duflu> zzarr: OK then. The next hurdle you might find (I remember hitting this now) is that Chromebooks often lack VT support in their kernels. Which is not a big deal but just Mir can't deal with that yet -- https://bugs.launchpad.net/mir/+bug/1169020
[07:49] <duflu> So that will stop you unless you have the Mir code I suspect
[07:51] <zzarr> I have the kernel config for the chromebook, can I add a console to it that way?
[07:52] <duflu> Not sure. Not very likely how nailed down ChromeOS is. You can only change what Google lets you change
[07:53] <zzarr> but if I have the source code (which I have) and the config, can't I just configure and build a new kernel?
[07:56] <zzarr> I thought I might be able to build a kernel with this tutorial https://github.com/dnschneid/crouton/wiki/Build-chrome-os-kernel-and-kernel-modules
[08:04] <duflu> zzarr: If you're in a chroot then you need a kernel that doesn't break ChromeOS. So I would recommend keeping the existing one and we should fix Mir to suit
[08:05] <zzarr> duflu, yea, but I thougt I should build a new kernel and run a stand alone environment from a SD card
[08:05] <duflu> zzarr: Sounds like the Ubuntu kernel lacks support for the chipset then?
[08:05] <duflu> Usually does for newish ARM devices
[08:06] <zzarr> yes, but I can configure a Chromebook kernel and build it
[08:07] <zzarr> so I install a custom Chromebook kernel on the SD card along with Ubuntu
[08:07] <zzarr> that way I should get the best of both worlds
[08:07] <duflu> True
[08:08] <duflu> zzarr: I would personally recommend sticking with the chroot though. Fixing Mir theoretically is easier than building your own OS with custom kernel :)
[08:09] <zzarr> duflu, I have that as a second way out then :-)
[08:09] <zzarr> it's more fun to try it from scratch
[08:09] <duflu> It's good you think that
[08:10] <duflu> Because someone has to be adventurous and try
[08:10] <zzarr> I have built linux kernels before (for UltraSparc)
[08:11] <zzarr> duflu, exactly, that's the way we move forward
[08:12] <zzarr> duflu, I'm a programmer too you see, so I know about the fact that some things are hard to do
[08:21] <zzarr> duflu, what line or lines define the console in the kernel config?
[08:22] <duflu> zzarr: Sorry, don't know
[08:22] <zzarr> okey, I'll stfg it
[09:09] <duflu> zzarr: Thanks for reminding me about the VT bug though. If I remember and get time I'll try to fix it before the bug reaches 1 year old
[09:09] <zzarr> duflu, no problem :-)
[09:09] <duflu> Actually the bug was from 2013, but I only associated it with chromebooks mid last year
[09:15] <zzarr> duflu, okey
[09:15] <duflu> If Xorg in an Ubuntu chroot can start, Mir has no excuse for failing to start...
[09:16] <duflu> We just have unnecessary error checking. And some errors are not really errors.
[09:18] <zzarr> duflu, that explains it
[09:19] <zzarr> duflu, but I don't get any 3D/OpelGLES support in the chroot (since ChromeOS uses freon)
[09:21] <zzarr> duflu, I though of making a freon to mir wrapper (I don't know if it's a good idea or not a time a go)
[09:22] <zzarr> duflu, I guess it would be a huge project even though both mir and freon is based of some parts of wayland
[09:22] <zzarr> not knowing if they are the same parts or not
[09:24] <duflu> zzarr: I'm not sure about Freon, but Mir and Wayland are entirely unrelated other than both (only just recently) use the same input library libinput.
[09:24] <duflu> I thought Freon was also completely separate
[09:25] <zzarr> duflu, okey, so mir has nothing to do with wayland.... I see, I think that freon has thought
[09:27] <duflu> zzarr: You remind me now that Mir (when using the mesa-kms driver) also requires a device-specific driver in the Ubuntu chroot under /usr/lib/x86_64-linux-gnu/dri/. As Ubuntu doesn't have that for your ARM chip, it will be software-rendered even when working properly
[09:27] <duflu> Which is not good. It won't run well at all
[09:29] <zzarr> duflu, that's not nice
[09:30] <duflu> zzarr: I know. It's because we use the Mesa implementation of OpenGL, which is portable but requires a DRI module specific to Mesa and the chipset to be accelerated
[09:31] <duflu> So hardware-accelerated Mir is limited to those covered by /usr/lib/x86_64-linux-gnu/dri/*
[09:31] <duflu> Minus *sw* :)
[09:35] <zzarr> duflu, so I will not be able to get an accelerated mir without that driver what ever kernel config I manage to create?
[09:35] <duflu> zzarr: I suspect that's right
[09:36] <zzarr> duflu, could I use an android-lxc for mir?
[09:36] <duflu> Unless you can find a custom libGLESv2 that works for your chipset
[09:37] <duflu> zzarr: For ARM hardware you might find usable drivers from Android, yes. But that's a maybe.
[09:38] <duflu> But Mir (via libhybris) only knows how to do that within an Android filesystem.... I think?
[09:38] <zzarr> duflu, I know for a fact that there are Android devices based off of RK3288
[09:38] <zzarr> duflu, I suspect that you're right
[09:46] <duflu> I should clarify that using any custom libGLESv2 (e.g. future Nvidia support!) also requires a custom Mir driver to be written to bootstrap it for mode setting and buffer management
[09:48] <duflu> Hmm actually that's not quite right. We might be able to mix and match. But no matter because such a /usable/ libGLESv2 for RK3288 may not exist.
[09:49] <duflu> Or likely we're missing other glue
[09:50] <zzarr> duflu, okey, is it possible somehow to compile a libGLESv2 for RK3288 myself?
[09:53] <zzarr> duflu, or do I need deep knowledge about how the RK3288 chip (Mali764) is built?
[09:54] <duflu> zzarr: You might need source code, but actually the ABI for libGLESv2 is well known. So you might be able to find and just copy a binary too. Although that assumes it's no linking to something awkward (like Android's bionic)
[09:55] <zzarr> duflu, okey
[12:02] <faenil> hello people
[12:03] <core_t> hi
[12:03] <faenil> After 1 day of debugging we found out the vivid+overlayppa LAPTOP setup I have here didn't boot to unity8
[12:03] <faenil> because it was missing
[12:03] <faenil> EGL_PLATFORM=mir
[12:04] <faenil> but it seems that env var should not even be needed
[12:04] <faenil> I'm here to report the issue and ask for advice :)
[12:05] <core_t> doesn't sound like a mir problem, try with unity people #ubuntu-unity
[12:05] <core_t> j/k :P
[12:05] <faenil> LOL
[12:06] <faenil> I was about to throw a digital fist over :D
[12:06] <core_t> :D
[12:08] <alan_g> faenil: I've never used EGL_PLATFORM=mir - I wonder what detects it.
[12:08] <faenil> alan_g: you mean who needs it?
[12:08] <alan_g> ack
[12:08] <faenil> without that, libEGL turns to libX11-xcb, and calls GetXcbConnection -> segfault
[12:10] <alan_g> alf: any ideas? ^^
[12:14] <alan_g> faenil: is $DISPLAY set? Unsetting that might discourage attempting an X connection
[12:14] <faenil> alan_g: we tried with DISPLAY= cmd
[12:14] <faenil> no diff
[12:14]  * alan_g suspected as much
[12:17] <alan_g> faenil: I imagine you must have more than a vanilla vivid+overlay setup to get unity8 desktop. What else did you install?
[12:17] <faenil> just unity8-desktop-session-mir
[12:17] <faenil> then discovered that didn't pull in mir platform and client packages
[12:17] <faenil> so I installed 2-3 packages
[12:18] <faenil> mesa-kms, mesa-x, evdev4...
[12:18] <faenil> and that's it
[12:18] <alan_g> mir-graphics-drivers-desktop?
[12:19] <alan_g> That *ought* to pull in all the needed stuff in one go
[12:19]  * alan_g grabs v+o laptop
[12:21] <faenil> alan_g: yep, already reported a bug where that was suggested
[12:22] <faenil> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1538659
[12:22] <faenil> oh, it was you :P
[12:23] <alan_g> :^)
[12:23] <faenil> so, yeah, I don't know what else could be missing
[12:24] <alan_g> Just updating & installing - I'll see what happens here and if I can diagnose
[12:25] <faenil> my laptop is running overlayppa as well, and I can boot unity8 without hacks
[12:25] <faenil> so I'm more inclined to think we're missing a pkg
[12:26] <alan_g> Sorry, what's the difference between "my laptop is running overlayppa" and "vivid+overlayppa LAPTOP setup"?
[12:31] <alan_g> I've probably other packages installed, but with apt-get install unity8-desktop-session-mir  mir-graphics-drivers-desktop I can start a guest session with unity8. (But all I get is a black screen with a cursor)
[12:35] <faenil> alan_g: the buggy one is not my laptop
[12:35] <faenil> it's a laptop I setup from scratch :)
[12:35] <alan_g> Ah, that's because USC is running, but nothing is connected to it.
[12:35] <faenil> alan_g: yes that's the issue, unity8 dies
[12:35] <faenil> good, you can reproduce it ;)
[12:35] <alan_g> \o/
[12:35] <faenil> that's the issue :)
[12:36] <faenil> if you add EGL_PLATFORM=mir somewhere so that unity8 picks it up
[12:36] <faenil> it will boot to unity8 :)
[12:37] <alf> alan_g: I wonder if changes to the way we export symbols have made it impossible for mesa to detect that mir is running
[12:38]  * alan_g wonders where USC publishes the endpoint. There's no /tmp/mir_socket
[12:40] <alf> alan_g: Perhaps USC doesn't publish an endpoint, the connection fd is just passed to sessions?
[12:41]  * alf has only faint memories of such facts, but can't be sure
[12:44] <alan_g> My memory is that robert_a couldn't make that work at first, and so publishing the endpoint got "embedded"
[12:46] <anpok> thought it was moved to /run/mir_socket .. or something like that
[12:47] <alan_g> You're thinking of $XDG_RUNTIME_DIR/mir_socket - but root tends not to have $XDG_RUNTIME_DIR set
[12:48] <kdub> isnt it /var/run/mir_socket?
[12:50] <anpok> http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk/view/head:/src/unity-system-compositor.c#L467
[12:50] <anpok> use the source lukes
[12:50] <alan_g> it's /run/lightdm-mir-0
[12:51] <anpok> on desktop?
[12:52] <alan_g> OK, I can crash a mir client. I'll dig into it after lunch
[12:59] <faenil> alan_g|lunch: yeah it crashes on GetXcbConnection
[12:59] <faenil> (most likely, or at least that was what we found out yesterday)
[12:59] <faenil> libEGL -> libX11-xcb -> GetXcbConnection -> segfault
[13:00] <alf> Saviq: Hi! I am trying to setup sbuild for Mir, duplicating what you have done for unity8. For the prepare-1-sbuild job how do I get the key files to pass as parameters? Can I just do 'sbuild-update --keygen' locally and upload, or do I need to do something different?
[13:01] <Saviq> alf, yeah, that's what I did
[13:02] <Saviq> should have documented that
[13:02] <alf> Saviq: btw, you have done a great job with all the prepare and build scripts. I am have I can just copy them with small changes and they work :)
[13:03] <alf> Saviq: s/I am have/I am happy/
[13:03] <Saviq> alf, changes!? :P
[13:03] <Saviq> alf, would be interested to know what you needed :)
[13:04] <alf> Saviq: not additions, just skipping some parts because I don't yet have some plugins currently installed (e.g. conditional build step, set build name)
[13:04] <Saviq> alf, ah those
[13:05] <Saviq> alf, I'm not totally sure about the conditional build steps, the plan was to skip heavy steps if they've been done on a machine already
[13:05] <Saviq> so you can just run the prepare job and let it figure stuff out
[13:05] <Saviq> seems to be working fine
[14:05] <alan_g> faenil: can you confirm whether apt-get remove mir-client-platform-mesa2 fixes the problem for you? (It works for me)
[14:06]  * alan_g thinks that there's a packaging "incantation" missing somewhere
[14:20] <faenil> alan_g: I hope it's not that, because that's what I did for my own laptop as well a week ago, but I think I checked that and mesa pkg was not installed in the setup I made from scratch
[14:21] <faenil> let's see...
[14:21] <faenil> alan_g: and I agree about the pkg incantation, that's my opinion as well
[14:21] <faenil> alan_g: crap, it's installed...
[14:22] <faenil> I spent two days debugging an issue I fixed on my own laptop by myself a week ago.
[14:22]  * faenil headdesks
[14:32] <faenil> greyback: ^
[14:32] <faenil> (ok, it was 2 weeks ago)
[14:34] <greyback> faenil: you're joking?!
[14:36] <faenil> greyback: I wish I were
[14:36] <greyback> aiii
[14:37] <greyback> still,  that identifies a mir packaging/so lib issue
[14:37] <faenil> yeah, let's see if I reported a bug first time got my own laptop booting
[14:38]  * faenil reads backlog from good old times
[14:46] <faenil> [13.01.16][17:59]<      faenil> | anpok: I've got mesa.so.2 and mesa.so.3
[14:46] <faenil> [13.01.16][18:01]<       anpok> | try to get rid of mesa.so.2
[14:47] <faenil> greyback: ^ he saved me last time :D
[14:49] <faenil> [13.01.16][17:58]<       anpok> | crash in XGetXcbConnection sound like mesa loads an older mir client driver and tries to verify the EGL Display it got from the mir server
[14:50] <faenil> boom, that was the winning hint
[14:50] <faenil> dednick: ^ if you're interested :)
[14:54] <dednick> heh
[14:56] <dednick> proable need a Replaces: mesa2 in the package control for mesa3
[14:57] <faenil> alan_g: http://bazaar.launchpad.net/~unity8-desktop-session-team/unity8-desktop-session/trunk/view/head:/debian/control#L18
[14:57] <dednick> i have about 10 different versions of mir on my laptop. sound probably sort that out!
[14:58] <faenil> so, desktop session is depending mir-graphics-drivers-desktop already
[14:58] <alan_g> dednick: I think "Breaks" is probably right, but I disavow all knowledge of those rules
[14:59] <dednick> yeah. i have no idea which one it is :)
[15:01] <alan_g> faenil: did you raise a bug? I can poke RAOF about adding the right incantation. (I trust his advice on these.)
[15:01] <faenil> alan_g: ok, the problem with session-mir is that overlay PPA has a version from March 2015
[15:01] <faenil> which didn't pull in drivers
[15:02] <alan_g> That needs an update then.
[15:03] <faenil> sil2100: ^
[15:03] <faenil> now, who pulled in mesa2 and mesa3 at the same time is another mistery that needs solving
[15:03] <faenil> s/who/what
[15:04] <sil2100> faenil: hmmm, could you guys get a bug filled for that?
[15:04] <faenil> sil2100: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1538659
[15:04] <faenil> I will rename the title now
[15:05] <sil2100> faenil: thanks, let me look at it shortly
[15:05] <faenil> sil2100: the PPA doesn't have that pkg, so it's coming from vivid archive
[15:08] <faenil> sil2100: title updated
[15:22] <faenil> alan_g: I'm not sure what I should report a bug about
[15:22] <faenil> that somehow I end up with mesa2 and mesa3 together after installing vivid and session-mir? :D
[15:24] <alan_g> Well, that would be fine except that recent libmirclients die if mesa2 is installed.
[15:25] <alan_g> There ought to be some way to tell dpkg to sort that out.
[15:26] <alan_g> But if you've not logged a bug already I can create on
[15:26] <alan_g> *one
[15:31] <kdub> what's that trick for using bzr and meld? is it just "bzr diff -r lp:mir --using meld" ?
[15:32] <faenil> alan_g: yeah I just don't know who pulls both mesa2 and mesa3 in
[15:33] <faenil> (haven't filed a bug yet)
[15:34] <alan_g> faenil: mesa2 is probably from a seed. mir-graphics-drivers-desktop?
[15:34] <alan_g> Or maybe its mesa?
[15:54] <faenil> alan_g: don't know
[16:59] <faenil> alan_g: https://bugs.launchpad.net/mir/+bug/1539184
[17:00] <faenil> I left it vague
[17:00] <faenil> at least we won't forget about it now ;)
[17:11] <alan_g> faenil: thanks, I'll update
[17:15] <faenil> cheers