robert_ancell | duflu, did you convert all the propietary bugs to public? | 02:14 |
---|---|---|
duflu | robert_ancell: Yes, after briefly reviewing them | 02:14 |
robert_ancell | duflu, thanks | 02:14 |
robert_ancell | Can anyone explain to me what the application name is used for in the connect message? | 04:11 |
robert_ancell | thomi, is the Mir documentation online? | 04:15 |
RAOF | robert_ancell: I *think* that's just a placeholder that'll be replaced by the application's UUID? | 04:23 |
robert_ancell | RAOF, That was my guess. I'm trying to work out why we don't just use that for the system compositor instead of this lightdm_id | 04:24 |
RAOF | robert_ancell: That's how I *set* the lightdm_id. | 04:25 |
robert_ancell | RAOF, no, there's a separate parameter in the connect call right? | 04:25 |
RAOF | No? | 04:26 |
RAOF | mir_connect(socket, id, callback, ctx); | 04:26 |
RAOF | Is what xmir calls; that's the same as what a normal client would call. | 04:27 |
robert_ancell | RAOF, don't you use mir_connect_with_lightdm_id? | 04:28 |
RAOF | No? | 04:28 |
robert_ancell | (/usr/include/mir/client/mir_client_library_lightdm.h) | 04:29 |
RAOF | I don't include that file :) | 04:29 |
robert_ancell | RAOF, I guess it probably doesn't work then! | 04:29 |
RAOF | mir_connect_with_lightdm_id, or XMir? Or, I guess, Mir? :) | 04:29 |
robert_ancell | RAOF, XMir | 04:30 |
RAOF | It works as far as I can tell? | 04:30 |
RAOF | As in: I can log in and it works. | 04:30 |
RAOF | I may not have tested user switching, I guess. | 04:30 |
robert_ancell | RAOF, yeah, it's only going to matter when switching | 04:31 |
RAOF | It switches from the greeter to my login session fine :) | 04:31 |
RAOF | I guess it doesn't switch between users; I haven't tested that :) | 04:32 |
robert_ancell | RAOF, that one is implicit, because the greeter gets destroyed and since mir is just stacking then the session must become visible (and visa versa) | 04:32 |
robert_ancell | RAOF, ok, cool. I think I'll just propose we remove the ID | 04:32 |
RAOF | Sounds sensible. | 04:33 |
=== mmrazik is now known as mmrazik|afk | ||
=== jono is now known as Guest42688 | ||
=== mmrazik|afk is now known as mmrazik | ||
RAOF | I AM THE FACE OF MIR! | 07:38 |
RAOF | Real, honest to goodness emails. Oldschool. | 07:39 |
RAOF | Earnestly warning me that we're destroying linux. | 07:41 |
duflu | RAOF: So, you basically designed all of Mir, right ? :) | 07:44 |
RAOF | That's right. | 07:44 |
* duflu runs | 07:44 | |
RAOF | From the GROUND UP! | 07:44 |
bryce | RAOF, ground up... beef? to feed trolls? ;-) | 08:25 |
RAOF | From the ground up dreams of wayland developers! | 08:25 |
RAOF | Emulsified with the tears of linux enthusiasts. | 08:26 |
bryce | aaa! choices bad! we want some choice other than X, but please not more than 1! | 08:29 |
duflu | LOL. Beautiful summaries. | 09:05 |
duflu | Nice to see that Mir has /supposedly/ revived progress on Wayland for Redhat... | 09:19 |
duflu | I'd like to see Wayland succeed as much as Mir... | 09:20 |
alan_g | +1 | 09:22 |
Ranomier_ | +1 | 10:52 |
=== zAo^_ is now known as zAo^ | ||
=== mmrazik is now known as mmrazik|lunch | ||
=== alan_g is now known as alan_g|afk | ||
=== mmrazik|lunch is now known as mmrazik | ||
=== alan_g|afk is now known as alan_g | ||
alan_g | alf_: did you see my post to mir-devel? (Just checking) | 13:26 |
alf_ | alan_g: hmm, no, I guess we need to subscribe manually | 13:27 |
=== mhall119_ is now known as mhall119 | ||
alan_g | alf_: we do | 13:27 |
mmrazik | alan_g: I received it (in case you asking if the mails as such are getting delivered) | 13:27 |
alan_g | mmrazik: cool - I was really checking to see who has subscribed. ;) | 13:28 |
mmrazik | :) | 13:28 |
=== kgunnAFK is now known as kgunn | ||
=== Darxus_ is now known as Darxus | ||
=== alan_g is now known as alan_g|afk | ||
kdub | good morning, status, working on the nex4 display/hwc support today | 15:01 |
=== alan_g|afk is now known as alan_g | ||
alan_g | kdub: are you subscribed to mir-devel? | 15:10 |
kdub | yes, just checking mail now | 15:10 |
alan_g | alf_: do I need to forward the mir-devel email? (Would like to get some feedback) | 15:43 |
alf_ | alan_g: No need, I can read it from the archives (but I am deep in multi-threaded android code now...) | 15:45 |
alf_ | kdub: I get some failing integration tests on nexus 4. Is this normal? | 15:46 |
* alan_g is jealous: he's trying to work out where to submit a patch to google-glog - code is much more tractable. | 15:47 | |
kdub | alf_, i know of one.. haven't debugged it yet | 15:47 |
kdub | alf_, TestClientIPCRender | 15:48 |
alf_ | kdub: right, and I also get a segfault in AndroidBufferIntegration.buffer_ok_with_egl_context | 15:49 |
kdub | alf_, yes i see that too | 15:50 |
alf_ | kdub: In AndroidBufferIntegration.display_cleanup_ok I see some very suspicious memory errors with valgrind | 15:50 |
kdub | alf_, i haven't debugged that yet, but valgrind on android doesn't work that well | 15:53 |
kdub | unhandled syscalls | 15:53 |
alf_ | kdub: btw, multi-threaded compositing seems to mostly work on the nexus 4 with your branches. I am puzzled, though, because AndroidBufferIntegration.display_cleanup_ok aborts with a double-free when I make current a pbuffer surface instead of a window surface in AndroidDisplay.cpp (no threads involved) | 15:55 |
kdub | well, its good it seems to mostly work :) | 15:56 |
kdub | that is strange, maybe my plan today will be, branch work, investigate the integration tests for a while, and then hwc work | 15:57 |
alan_g | thomi: what progress on http://unity.ubuntu.com/mir? | 16:03 |
racarr | Morning | 16:05 |
alan_g | racarr: are you subscribed to mir-devel? | 16:06 |
kdub | mmrazik, that shell script split for crosscompile you requested is in btw | 16:06 |
mmrazik | kdub: I noticed. thanks | 16:06 |
mmrazik | was preparing some environment for it | 16:06 |
racarr | alan_g: Hmm maybe not | 16:06 |
alf_ | racarr: good morning | 16:07 |
alan_g | racarr: if you didn't see my email to it... | 16:07 |
racarr | alf_: Morning :) | 16:08 |
racarr | alan_g: I see the email...I will write back soon I need | 16:08 |
racarr | to think about that | 16:08 |
alan_g | racarr: then you're subscribed. ;) | 16:08 |
racarr | status today is still working on setting input focus and receiving input I kind of got stuck in circles yesterday | 16:14 |
racarr | I don't think there are any problems though, I was just scatterbrained yesterday afternoon. have a failing integration test :) | 16:14 |
racarr | alan_g: Hmm re:prepare-session-manager-for-input-focus. I think that makes sense but I am not sure what the object is yet. | 16:21 |
racarr | perhaps the object is the surface controller and it lives in shell | 16:21 |
racarr | if create_surface_for is called from ApplicationMediator though | 16:22 |
racarr | how does the session come to own the surface? | 16:22 |
alan_g | racarr: because the session is passed as the first parameter to the call | 16:26 |
alan_g | obviously create_surface_for() can call session->create_surface() | 16:27 |
racarr | ohhhh | 16:27 |
racarr | I understand | 16:27 |
racarr | I think it's | 16:28 |
racarr | SessionStore | 16:28 |
racarr | it makes even more sense if it's called | 16:28 |
racarr | Shell | 16:28 |
racarr | Shell::create_surface_for seems like an appropriate method | 16:28 |
alan_g | \o/ | 16:29 |
alan_g | racarr: now reply to that email | 16:33 |
racarr | ok | 16:35 |
racarr | I will "reply" I didnt actually get the email | 16:35 |
racarr | even though I have a verification email for subscribing to the list from before | 16:35 |
alan_g | racarr: there are *still* merge conflicts. | 16:38 |
alan_g | did you forget to "push"? | 16:40 |
racarr | alan_g: ok emailed | 16:40 |
racarr | really? | 16:40 |
racarr | just a second maybe my push hung | 16:41 |
racarr | oh hold habit and I accidentally pushed to ~rocket-scientists instead of ~robertcarr | 16:41 |
racarr | err... no. | 16:41 |
racarr | the opposite | 16:42 |
alan_g | racarr: ~rocket-scientists is correct this time | 16:42 |
racarr | :) | 16:42 |
racarr | ok pushed for real (r502) | 16:42 |
alf_ | kdub: I have the impression that we aren't supposed to deallocate the EGLNativeWindowType created by android_createDisplaySurface(); it's deallocated for us when we call eglDestroySurface() for the associated EGL window surface. | 16:43 |
alan_g | racarr: looks better | 16:43 |
alan_g | racarr: where did you email reply? I don't see it, and it isn't in the mir-devel archive. | 16:48 |
alan_g | kgunn: what's happening with mir-devel ^ | 16:48 |
kgunn | alan_g: let me check | 16:49 |
kgunn | alan_g: racarr stange....i see alan_g's original mail in the archive | 16:50 |
kgunn | and i just got a mail of racarr's...with the ability to approve/disapprove | 16:50 |
alan_g | kgunn: can you see if racarr is subscribed? | 16:50 |
alan_g | (Sounds like he's a non-member) | 16:51 |
kgunn | alan_g: ok...looks like he was a member....but the admin interface lets you filter | 16:52 |
kgunn | i marked racarr as someone who should be accepted always | 16:52 |
alan_g | kgunn: I see it now - thanks | 16:53 |
kgunn | racarr: i take it back | 16:56 |
kgunn | you are not a member | 16:56 |
kgunn | weird | 16:56 |
kgunn | racarr: i just added you | 16:58 |
racarr | Thanks :) | 17:14 |
alan_g | racarr: re prepare-for-inprocess-egl-clients - please make better use of the new directory structure. | 17:15 |
Cheery | how is it going around here? | 18:48 |
=== mmrazik is now known as mmrazik|eod | ||
kdub | Cheery, well :) | 20:02 |
=== mmrazik|eod is now known as mmrazik | ||
Cheery | well? | 20:10 |
mmrazik | kdub: is the install-on-android script supposed to work? I'm getting these: http://pastebin.ubuntu.com/5611775/ | 20:12 |
mmrazik | I'm talking about "bash: libboost-system1.49.0: command not found | 20:12 |
mmrazik | " | 20:12 |
kdub | mmrazik, its not handling the failure in installing protobuf well | 20:13 |
mmrazik | kdub: isn't there some '\' missing? | 20:13 |
mmrazik | kdub: this looks a bit suspsicious to me: https://pastebin.canonical.com/86760/ | 20:14 |
kdub | mmrazik, yes, there are | 20:15 |
sturmflut | How can I test Mir? I got it to build on my Ubuntu 13.04 install and the server binary runs okay, but all clients segfault after the connection to the server is established and the surface is created | 22:16 |
kdub | sturmflut, maybe you have a wrong version of mesa... | 22:49 |
sturmflut | The libgl1-mesa-dri and libgl1-mesa-glx are at version 9.0.2-0ubuntu1 | 22:52 |
sturmflut | packages | 22:52 |
sturmflut | kdub: Which versions do I need? I just used the ones from the raring repository | 22:54 |
kdub | racarr, RAOF ^^ | 22:55 |
RAOF | sturmflut: You need the packages from ppa:mir-team/staging | 22:56 |
RAOF | sturmflut: You're currently after mesa version 9.1~rc2-0ubuntu0+mir2-jenkins17 | 22:57 |
sturmflut | RAOF: ah, that would explain it | 22:58 |
RAOF | The reason why you get segfaults is that your mesa doesn't have a Mir EGL platform, which is how the accelerated clients draw. | 22:58 |
RAOF | So the client tries to initialise and EGLDisplay, mesa doesn't find a match, then tries the default (of X11), which segfaults when you don't have a working X11 on the other end of $DISPLAY. | 22:58 |
RAOF | (This would be a mesa bug ☺) | 22:59 |
sturmflut | RAOF: Okay, with the mesa packages from the PPA it works. Thanks! | 23:05 |
RAOF | There'll be a transition coming sometime soon where I'll break mesa in the process of switching the buffer-passing mechanism from flink to dma-buf; I'll only do that once everything's in place, though. | 23:07 |
sturmflut | So when do you think the most basic pieces of Mir and the toolkits (Qt, GTK+ etc.) will be in place? Is the project state on https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-converged still correct? | 23:26 |
kdub | sturmflut, there is a qpa for qt | 23:39 |
sturmflut | kdub: sounds good | 23:43 |
sturmflut | kdub: The target release for the switch to Mir on the desktop is still 14.04? | 23:43 |
kdub | sturmflut, the blueprints are up to date :) | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!