[01:00] <wolfslord> racarr, How can I help you with the work item "In process EGL"?
=== rsalveti_ is now known as rsalveti
[01:51] <racarr> wolfslord: Hi!
[01:51] <racarr> Hmm it's hard to explain right now. it's close to done actually but blocked on figuring out some weird issues in jenkins environment for prepare-for-inprocess-egl-branch
[01:52] <racarr> the idea is about, allowing to create an EGLContext from a seperate thread bound to a mir surface in process
[01:52] <racarr> and render like a client, but in process
[01:52] <racarr> this of course, for the shell
[01:53] <racarr> I don't know how to split it up in to seperate tasks right now. The idea is the prepare-for-inproces-egl branch changes the (Mir)EGLNativeDisplay type from MirConnection to this "NativeDisplay" structure which has several callbacks (surface_advance_buffer, surface_get_parameters), etc.
[01:54] <racarr> then in prepare-for-inprocess-egl the client library, is modified to create this native display structure with functions pointing to client library based impementations
[01:54] <racarr> so the next step (once the issue with landing prepare-for-inproces-egl is unblocked, so this can proceed somewhat without it)
[01:56] <racarr> is to implement a server side version of MirMesaEGLNativeDisplay, with callbacks that work in terms of the in process server interfaces
[01:56] <racarr> There is already one around in the branch mentioned here though https://bugs.launchpad.net/mir/+bug/1122388 (demo-shell-with-egl-abstraction)
[01:56] <ubot5> Error: launchpad bug 1122388 not found
[01:56] <racarr> err. bug setting failure :/
[01:57] <racarr> anyway, it's absically done just a matter of landing the code in the right order and figuring out this
[01:57] <racarr> jenkins failure
[01:57] <racarr> so I can't think of a sub task or anything to give you :(
[04:23] <wolfslord> So which ubuntu version exactly is recommended to dev MiR?
[04:24] <RAOF> wolfslord: Raring
[04:26] <wolfslord> RAOF, Thank you. I had a problem with my system and I'm going to reinstall so that's why I asked :)
=== mmrazik|eod is now known as mmrazik
[07:46] <bochecha_> hi, I'm developing a new IBus input method engine for Hong Kong people, and with the recent Mir announcement I'm wondering if I should bother spending time to make it work well on Ubuntu
[07:46] <bochecha_> what particularly confuses me is this statement in the MirSpec page:
[07:46] <bochecha_> We have looked at multiple candidate input stacks and have chosen the one included in Android for its efficiency, clear design and flexibility.
[07:46] <bochecha_> "input stack" is a bit vague, so just do be clear: does it mean that Ubuntu is moving away from IBus?
[07:47] <bochecha_> (not that there is anything inherently wrong with it, but I'd just like to know how to prioritize the platforms I will be working on)
[07:54] <tvoss> bochecha_, we are looking into the different input method (protocols) and IBus is on our list. But we would be happy to work together with you and identify your requirements. In general though: making your new engine work on Ubuntu would be great
[07:59] <bochecha_> tvoss: well, my requirements are simple: a running IBus daemon :)
[08:00] <bochecha_> if Ubuntu moves away from IBus, then my engine just won't run, and I will have one less platform to care about (yay, less work! :P)
[08:03] <tvoss> bochecha_, @ibus daemon: that's easy enough :) for your question on the input stack: we are not moving away from iBus, the input stack refers to the low-level event process from evdev
[08:03] <bochecha_> oh, I see
[16:57] <Leyland> Hello, I have some questions. Is anyone working on a 'mir client over X' library for development of mir clients with out leaving the comfort of an X desktop? Are there things that would make such a library impossible? Are there any major changes expected for the mir client interface, is it a good time for toolkit integration? If I am not here please respond anyway, I will look at the logs later, thanks!
[17:16] <Pajn> One thing I wonder about Mir is if it's going to recreate all work done by Wayland or if it only will support a subset of Waylands features?
[17:16] <Pajn> This is because of the wery narrow time frame that have been set
[17:17] <Pajn> Wayland have been developed for far longer and whit Canonicals daily QA it should take even longer
[17:18] <Pajn> Is there any margins in the time frame for unexpected happenings?
[17:29] <Leyland> I would love to see a more comprehensive comparison of wayland and mir, rather then the knee jerk reactions I've been reading lately, but oh well. May the X server replacement that garners the most hardware support win!
[17:55] <alan_g> Leyland, I don't know of anyone working on a 'mir client over X' - it would be interesting, but probably just achieve the "worst of both worlds".
[17:56] <alan_g> Wayland and mir are very different things - A Wayland (the protocol) implementation using mir (the library) could happen.
=== alan_g is now known as alan_g|afk