[04:03] <RAOF> REVIEW ALL THE THINGS!
[08:22] <anpok_> RAOF: still around?
[10:03] <alan_g> greyback: I know this isn't the exact context you're interested in, but it may be related to some of the problems you've seen. So FYI: https://bugs.launchpad.net/mir/+bug/1507518
[10:59] <zzarr> hello! how does mir and freon compare?
[11:11] <alan_g> Very much as weston and freon do.
[11:13] <zzarr> hmm... never heard of weston
[11:14] <alan_g> weston is the best know implementation of wayland
[11:19] <zzarr> ohh, it's wayland
[11:20] <zzarr> is there a possibility to use libhybris with freon drivers?
[11:21] <zzarr> to make it speak the graphics language of mir ;)
[11:24] <ogra_> zzarr, you are mixin up things :)
[11:25] <zzarr> I just realized that :O
[11:25] <ogra_> hybris is to make libc (linux) binaries talk to bionic (android) binaries
[11:25] <ogra_> not related much to Mir or wayland
[11:25] <ogra_> freon will have some Mir compatibinity layer
[11:26] <zzarr> is it happening right now or is it planed for the future?
[11:26] <ogra_> (look for ozone-mir and ozone-wayland)
[11:27] <zzarr> ahh, thanks ogra_
[11:27] <ogra_> why are you so interested in it ? after all it will only help with chromium
[11:27] <ogra_> (freon that is)
[11:28] <ogra_> all that freon does is add support to chromium for talking directly to drm/kms drivers ...
[11:29] <zzarr> I know, I wanted the other way around ;)
[11:30] <zzarr> I have a Chromebook (RK3288 chipset) which I wish to run MIR on
[11:30] <ogra_> not sure thats possible
[11:31] <ogra_> (without running Mir natively i mean)
[11:31] <zzarr> but I want a native mir ;)
[11:32] <ogra_> well, then you have to port Mir ... i doubt freon can help much here
[11:32] <ogra_> (apart from using it for code examples perhaps)
[11:32] <tvoss> zzarr, Mir supports drm/kms drivers already, probably best ot give the demo clients/servers a spin
[11:33] <zzarr> I have an ASUS ChromeBook Flip and it's formfactor just screams "put MIR/Unity8 on me" ;)
[11:34] <zzarr> I'll just install mir and it works?
[11:36] <zzarr> I can't do it right now, I'm at work, I'll test it after work
[11:47] <zzarr> I know this is off topic, but can I have both MIR and Freon running at the same time?
[11:51] <zzarr> I hope I'm not making you tired of me, but Ubuntu/Canonical/MIR/Unity8/Snappy puts me in a good mood
[11:51] <zzarr> mode*
[12:02] <tvoss> zzarr, I personally haven't tried, but if it comes with kms/drm drivers, chances are good
[12:04] <zzarr> tvoss, are freon or mir occupying the driver or can I use both at once?
[12:04] <tvoss> zzarr, it's exclusive or, both will want exclusive access to the drm nodes
[12:05] <zzarr> okey, so I have to find a way to stop freon and start mir then
[12:06] <anpok_> zzarr: rockchip 3288 uses mali
[12:06] <anpok_> since the lima driver has not taken off yet.. your only chance are the android drivers afaict
[12:08] <zzarr> anpok_, okey, so the lima driver is the one that will handle Mali GPU's but it don't support the 764 yet... got you
[12:08] <anpok_> i mean drm kms might work.. but you will lack a user space egl/gles driver..
[12:08] <anpok_> ack
[12:10] <zzarr> so I'd better find a way to install Ubuntu in a dualboot rather then a chroot as I hav now and then install libhybris and an android driver I guess
[12:12] <zzarr> will I be able to use the drm kms drivers for other functions like wifi and bt?
[13:11] <kenvandine> greyback, hey, any update on the mouse/touchpad settings support?
[13:12] <greyback> kenvandine: not yet no. Mir still needs to switch to libinput before that can proceed
[13:12] <kenvandine> greyback, ok, is that happening soon?
[13:12] <greyback> kenvandine: anpok_ is managing it, seems like it's not far away
[13:13] <anpok_> there is a bunch of mps up for review.. most of them will land soon.. some already landed but got reverted because of a regression on modifiers..
[13:14] <anpok_> but real soo now..
[13:14] <anpok_> kenvandine: the part you might be interested in is already exposed in usc
[13:14] <anpok_> or by usc..
[13:14] <anpok_> the dbus api
[13:15] <anpok_> i am about to prepare a change for USC that wires stuff together, but the dbus API for configuring pointer and touchpads has already landed..
[13:16] <greyback> kenvandine: there were discussions about using GSettings for those settings, and having unity8 read those settings and configure USC accordingly (would solve the log-in issue)
[13:16] <greyback> does that ring a bell?
[13:16] <kenvandine> yeah
[13:16] <kenvandine> that was the plan
[13:17] <greyback> ok good, we're on same page so
[13:17] <kenvandine> so i don't really need the dbus api...  :)
[13:17] <greyback> yeah you don't
[13:17] <kenvandine> greyback, so i have a unity8 branch that adds the schema, but it's quite outdated
[13:18] <kenvandine> i should update that :)
[13:18] <greyback> kenvandine: please do, that would be excellent
[13:18] <greyback> since you know what you need
[13:19] <kenvandine> greyback, you've seen it before, but here's a reminder :)
[13:19] <kenvandine> lp:~ken-vandine/unity8/mouse_touchpad_schema
[13:19] <kenvandine> i just merged the latest trunk
[13:19] <greyback> cool, thanks
[13:29] <tvoss> greyback, anpok_ I'm confused, I thought we decided against the gsettings approach?
[13:30] <greyback> tvoss: true, we agreed the proper way is mir having api for this. I dunno how far long that is tho
[13:30] <tvoss> anpok_, ^?
[13:31] <tvoss> anpok_, greyback iirc, we decided that a private dbus api is the stop-gap measure to keep us moving
[13:31] <anpok_> tvoss: even with a client side configuration api there will be gsettings somewhere
[13:31] <tvoss> anpok_, disagreed
[13:31] <anpok_> and someone has to apply the settings found in gsettings on session start..
[13:31] <tvoss> anpok_, let unity8 handle that
[13:31] <anpok_> tvoss: and thats what we do..
[13:31] <tvoss> anpok_, certainly not system settings
[13:32] <tvoss> anpok_, sorry, but gsettings is not the way we agreed to do it
[13:33] <anpok_> tvoss: sure, but I am not touching gsettings stuff..
[13:33]  * tvoss reads backlog
[13:34] <tvoss> anpok_, so unity8 translates a private dbus api to a gsettings schema? now that sounds like a really bad idea
[13:37] <anpok_> I would phrase that the other way round..
[13:37] <anpok_> but then still .. you should start the sentence with "kenvandine, greyback:"
[13:38] <greyback> the private dbus api is needed for IPC between usc and u8, that we'll eventually replace with proper mir api
[13:38] <anpok_> somebody has to forward settings from somehwere..
[13:38] <tvoss> greyback, kenvandine let's jump on a hangout real quick
[13:39] <greyback> sure
[13:39] <tvoss> kenvandine, greyback https://plus.google.com/hangouts/_/x7iu5fnluwfqektfyirtrpyizua?hl=en&authuser=0
[13:40] <kenvandine> ok
[14:26]  * alan_g discovers that he can crash mir by stepping through the client "display reconfiguration" code.
[17:48] <greyback> AlbertA: hey, I see you've updated https://code.launchpad.net/~albaguirre/qtubuntu/use-mir-surface-apis/+merge/267228 - would there be any specific app I should use to test it with? One that uses those surface types?
[19:31] <kgunn> anpok_: actually i'll ask hear
[19:31] <kgunn> here even
[19:33] <kgunn> so i'm trying to get snapcraft for mir going, just sorting through the build deps
[19:33] <kgunn> and seems we need to have libinput installed, but it's not gettting installed automatically ?
[19:35] <kgunn> hmm, or maybe i'm not installing a dependency correctly for snapcraft itself...
[19:35] <kgunn> lemme dig a bit more
[19:41] <anpok_> kgunn: hm what do you mean by not getting installed automatically? .. hm libinput is pulled in as build dep and runtime dep of the evdev platform
[19:59] <kgunn> anpok_: well, so when i try to build with snapcraft, which effectively runs cmake
[19:59] <kgunn> i get
[19:59] <kgunn> -- CMAKE_C_COMPILER: /usr/bin/cc
[19:59] <kgunn> -- checking for module 'libinput'
[19:59] <kgunn> --   package 'libinput' not found
[20:15] <kgunn> anpok_: so when i do apt-cache policy libinput ...i get : N: Unable to locate package libinput
[20:17] <anpok_> libinput-dev and libinput10
[20:17] <kgunn> ah just found it meself just now...
[20:17] <anpok_> so snapcraft is not pulling dependencies on its own?
[20:18] <kgunn> anpok_: so how does one determine which libinput ver we use ?
[20:18] <kgunn> anpok_: nope, you've gotta list 'em
[20:18] <kgunn> :-/
[20:18] <kgunn> anpok_: but i can get it as a sub dependency...e.g. if libevdev-dev pulls it in, i could get it that way
[20:18] <anpok_> as of now 1.0.1 + our patches.. and I am waiting for x to get more patches added..
[20:18] <anpok_> before that 0.21 + our patches was fine too
[20:19] <kgunn> anpok_: so is there fwd/backward compat issues there ?
[20:20] <anpok_> hm no not in that sense.. it would build and run on both recent releases to vivid-overlay and wily
[20:23] <kgunn> anpok_: just sharing, so i
[20:23] <kgunn> am using the debian/control file in mir as a guide to determine
[20:23] <kgunn> what to add
[20:24] <kgunn> anpok_: https://pastebin.canonical.com/142095/
[20:25] <kgunn> so what am i missing to pull in libinput ?
[20:25] <kgunn> should i just add libinput10 directly ?
[20:25] <kgunn> ...suppose i can, just wondering if you had expected libevdev-dev to pull it in
[20:26] <anpok_> just libinput-dev (>= 0.21)
[20:27] <anpok_> not not really.. dependency between libinput depends on libevdev not the other way round
[20:28] <anpok_> i believe we added libevdev for some of the privileged tests
[20:28] <kgunn> anpok_: dang it...my list got truncated too...so probably me
[20:44] <kgunn> anpok_: hey, i think i really did stumble onto something
[20:44] <kgunn> seems to be tied to mir0.17
[20:44] <kgunn> so the instructions i follow to build mir are
[20:45] <kgunn> the classic http://unity.ubuntu.com/mir/building_source_for_pc.html
[20:45] <kgunn> i just mir 0.16 no prob
[20:45] <kgunn> when i do cmake i get that error
[20:46] <kgunn> hmm, altho i didn't explicity run sudo mk-build-deps --install --tool "apt-get -y" --build-dep debian/control
[20:46] <kgunn> on mir0.17
[20:49] <kgunn> ah...that did it, libinput-dev
[21:19] <AlbertA> greyback: qtcreator which has menus and dialogs. The menu bar is still wonky but most other things popup in the right place
[21:19] <greyback> AlbertA: ok, nice
[21:22] <kgunn> vogons working through dependency stuff, is python3 just used for supporting the build ? or is it something mir actually relies on at runtime
[21:23] <AlbertA> kgunn: it's used for the tool that parses
[21:23] <AlbertA> the perf latency numbers
[21:23] <AlbertA> so not mir run-time
[21:56] <RAOF> anpok_: Around now!