[01:23] Gah. Summer must be coming. Everything has a spider living in it already :P [01:26] :) [04:54] Dear lord, upstairs is hot. [04:55] Also, why must Qt have crappy font rendering? [04:55] (Alternately, where do I tell Qt to render fonts non-crappily?) [04:59] Hm. Hang on to shared_ptrs, or increment other people's reference counting? [05:34] filed bug #1252144 on a test failure on builders [05:34] bug 1252144 in Mir "A test failing on builders with mir 0.1.1" [Critical,New] https://launchpad.net/bugs/1252144 [05:41] Mirv: Also, is the "UNRELEASED" a problem? mir (0.1.1-0ubuntu1) UNRELEASED; urgency=low [05:46] duflu: no, it's fine and gets changed by cu2d as seen at https://launchpadlibrarian.net/156699885/mir_0.1.1%2B14.04.20131116-0ubuntu1.diff.gz [06:10] Mirv: If I propose a fix to lp:mir can we test it quickly? I can't reproduce the bug either... [06:14] Does it fail on the PPA builders, too? [06:15] Looks like a silly-short timeout which will fail on a busy server. Proposing now... [06:16] Oh. Wait, no. It fails after 1ms [06:32] duflu: yeah I can push to some PPA as well if needed [06:32] Mirv: We don't use PPAs in Mir any more. But proposing now... [06:33] ok, seeing the branch [06:41] building soon at https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-daily/+sourcepub/3666854/+listing-archive-extra [06:43] RAOF: When is an appropriate time to add resize support to Mesa? There are prerequisite changes in Mir 0.1.2 that it will need, but can we update git immediately? [06:43] We can update git any time you want. [06:45] RAOF: In that case, may I ask you to look at my two lines of logic and update the buffer acquire/release stuff to suit? [06:45] two-ish [06:46] :) [06:46] Certainly. Where are they? [06:46] RAOF: https://launchpadlibrarian.net/156390351/mesa-mir-resize-support.patch [06:47] It works now... but of course we don't have any demo clients using non-colour buffers yet [06:47] How do clients know to change their rendering, by the way? [06:47] RAOF: They presently query EGL. Events are coming soon [06:48] For example: https://code.launchpad.net/~vanvugt/mir/resize-examples/+merge/194833 [06:49] Added to git. [06:49] RAOF: Ta muchly [06:50] Oh, also; why is there a check for buffer.width and buffer.height? [06:51] RAOF: So it falls back to the existing (working) behaviour if you accidentally run it against an older Mir [06:51] Ah, ABI. [06:51] ... where they are zeroed fields [06:51] Yeah, fair call. [06:52] It's both sad and exciting that resizing surfaces is one of the most dramatic things you will see on demo_server* right now [08:01] RAOF: Were you referring to jaggies on touch earlier? I see them now :P [08:16] Mirv: Jenkins is reporting CI failures which are actually problems with the build machine and not the code :( [08:16] https://code.launchpad.net/~vanvugt/mir/fix-1252144.trunk/+merge/195547 [08:38] duflu: yep, retrying in case it helps [09:42] alf_: Do we ensure xbgr is listed before abgr so dumb clients like unity-mir will grab the first (fastest) pixel format? [09:44] duflu: no, on the contrary, we return pixel formats in descending "active" bits order (abgr = 32, xbgr = 24) [09:44] alf_: Is that a good idea [09:44] ? [09:47] duflu: It's a more predictable ordering (and helps a bit when searching for particular formats), sorting by "fastest" is not. In any case, if unity-mir, or any other app needs a particular surface type they should search for it, not rely on formats[0] being what they want. [09:47] alf_: Yeah I was trying to avoid fixing and rebuilding unity-mir [09:48] duflu: (because we may indeed decide to change the ordering in the future) [09:49] alf_: OK. I think we need to improve on format lookups in future. Perhaps like bug 1236254 [09:49] bug 1236254 in Mir "[enhancement] MirPixelFormat should encode details of the pixel format" [Medium,New] https://launchpad.net/bugs/1236254 [09:50] duflu: yeah, I was looking at the DRM fourcc format, but it's a bit arbitrary unfortunately [09:51] duflu: (/usr/include/drm/drm_fourcc.h) [09:51] alf_: Yeah I know it, but it does not solve the problem [09:55] duflu: alan_g: @offscreen-platform, are you happy with renaming to OffscreenDisplayContext or OffscreenNativeDisplay or ... [09:55] alf_: I think I prefer OffscreenPlatform more :S [09:56] alf_: reminding myself... [09:57] duflu: alan_g: Unless we go with one of the other methods (e.g. adding egl_native_display() to platform directly and having an independent OffscreenPlatform interface) [09:58] alf_: Or just make OffscreenPlatform a real platform and drop the pure virtual requirement :) [09:59] alf_: the name doesn't bother me much - but I would suggest BasicPlatform/MinimalPlatform would be a better base for Platform than OffscreenPlatform [10:00] Yeah that would be better [10:00] BarePlatform? [10:00] alan_g: duflu: EGLPlatform? [10:01] alf_: That's slightly better, but it's going to confuse people for that to be the base of "Platform" [10:02] I think any good solution is going to involve rethinking "Platform" which is a job for another day. [10:02] * duflu abstains [10:03] alan_g: duflu: OK, I will go with BasicPlatform [10:14] alf_: the last suggested revised name for "surfaces" I can find is "core" - how do you feel about that? [10:20] alan_g: thinking... [10:27] alan_g: I am not convinced that core is a better name than surfaces (or something else), it's surely is less descriptive [10:28] alan_g: after all mir::surfaces is all about the creation and management of surfaces [10:28] alan_g: mir::scene ? [10:40] alf_: maybe - although I've been trying to get away from "scenegraph" which tends to be taken too specifically [10:40] alf_: mir::model? === om26er_ is now known as om26er [10:47] alan_g: It depends on how literally we want to use "model" (in the MVC sense), since the component contains the controller too. [10:47] tvoss_: I think the time is ripe to change the name of mir::surfaces. Do you have any thoughts on a good name? (Also ^^) [10:48] alf_: yeah, but mir::model_controller is a bit long winded [10:49] mm or mmc is easy to type though... === chihchun is now known as chihchun_afk [11:08] g 63 === dandrader is now known as dandrader|afk === alan_g is now known as alan_g|lunch === dandrader|afk is now known as dandrader [13:58] weird, weird, the test duflu fixed still failing in the daily-build PPA, while when I build in another PPA (granted probably slightly different PPA) it succeeded: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+sourcepub/3667324/+listing-archive-extra [13:59] this is the bug #1252144 still [13:59] bug 1252144 in mir (Ubuntu) "A test failing on builders with mir 0.1.1: PublishedSocketConnector.drm_auth_magic_is_processed_by_the_server" [Critical,In progress] https://launchpad.net/bugs/1252144 === alan_g|lunch is now known as alan_g [14:51] didrocks: ok...what's up ? u-s-c FTBFS ? [14:51] kgunn: see what Mir posted an hour ago ^ [14:51] bug #1252144 [14:51] bug 1252144 in mir (Ubuntu) "A test failing on builders with mir 0.1.1: PublishedSocketConnector.drm_auth_magic_is_processed_by_the_server" [Critical,In progress] https://launchpad.net/bugs/1252144 [14:52] didrocks: sorry...got on later than that [14:52] kgunn: also, it seems platform-api doesn't have the bump build-dep merged [14:52] that's the 2 things now that we can slowly try to land things again :) [14:52] and doing Mir in priority [14:53] seems to work on virtualized ppa, but not on real hardware one [14:53] (the latter beeing used for distro) [14:53] (comments #4 and #5) [14:55] didrocks: do we know the fundamental differences between qt5-daily PPA vs. daily-build PPA ?? [14:56] kgunn: I have this virtualized vs non virtualized in mind, but that's it [14:57] kgunn: the other possibility is a timing issue, but it's weird we have consistent failures (we did several retries) [14:57] and virtualized would be "faster" [14:57] mlankhorst: alf_ ....any ideas, this is strange ^ almost wonder, did mesa change ?? [14:57] gah why always blame mesa [14:57] :P [14:58] didrocks: is the mir-patched xserver stuff in archive for trusty ? [14:58] kgunn: well, both are built on trusty, right? [14:58] so I guess that mlankhorst didn't remove the patch, right mlankhorst? [14:58] mlankhorst: only because no one's touched u-s-c/xmir in a good while :) [15:00] alf_: ping [15:00] kgunn: let me look for the content of the ppa [15:00] this is why /me doesn't like xserver/mesa sitting outside bzr [15:00] I was testing your --offscreen branch and get this error when I try to run offscreen http://pastebin.ubuntu.com/6437847/ [15:01] kgunn: mlankhorst: that particular test doesn't interact with any external components, its a unit test using mocks [15:01] it's [15:01] kgunn: +1 for not liking that ;) [15:02] didrocks: I'm tempted to do so, but no [15:03] mlankhorst: sorry...i'll keep it to myself :) [15:03] alf_: ok...so just a failing mock...sounds like you're familiar enough, could you take a look on the trunk ? [15:04] kgunn: ok [15:04] kgunn: we haven't touched mesa in trusty much, only uploaded 9.2.2 afaik [15:05] alf_: thank you...this is an item that's holding up our mir update to the archive (going on 3 weeks :) [15:05] mlankhorst: sorry dude...i'll try not to be so mesa-blame-happy :) [15:05] robotfuel: (will get back to you in a bit) [15:06] robotfuel: sorry...i swiped alf_ [15:06] alf_: ack I see you have your hands full :) [15:08] kgunn: no, all the same for both [15:08] apart from this virtualized vs non virtualizeds [15:12] didrocks: ack, we got someone looking [15:12] kgunn: thanks! [15:12] keep us posted [15:12] didrocks: at least hope it fails on their local machine....it should since its the non-virt failing [15:12] kgunn: cyphermox/robru/ken when I'm not around [15:13] thank you sir [15:13] kgunn: let's cross fingers (they should try building the package to have the same config: bzr bd) === dandrader is now known as dandrader|lunch [15:15] alf_: ^ see didrock's last statement [15:15] alf_: alan_g: would either of you be able to make sense of this: http://pastebin.ubuntu.com/6422376/ What I'm trying to do is use a qt application in Mir. So running mir_demo_server_shell, and then qmlscene (using the qtubuntu plugin so behaves as mir client) [15:15] didrocks: one thing on the platform-api bump... https://code.launchpad.net/~kgunn72/platform-api/bump-mir-dep-0.1.1/+merge/193519 [15:15] greyback: looking... [15:15] alf_: alan_g: it would appear that mesa imports x11. Do we have patch to stop that? [15:15] didrocks: it looks like it won't autoland due to mir build dep itself...(or do i not understand ?) [15:16] e.g. does mir have to land first before that will actually merge ? [15:17] greyback: that doesn't look familiar to me. Sorry [15:17] alan_g: np, thanks for looking [15:18] greyback: When you create an egl display from an egl native display (MirConnection etc), the patched mesa checks Mir first so it shouldn't be a problem. Is this desktop or phone? [15:18] alf_: desktop [15:18] kgunn: yeah, for those kind of trivial change, you can force it to trunk (merge manually) [15:18] kgunn: to not wait mir to land in the ppa [15:19] didrocks: ack, so pull, merge, push quickly ? [15:19] (well, mir is in the ppa, but failed tobuild, as we discussed) [15:19] kgunn: sounds good to me [15:19] ricmm: ^ just beware of what i'm about to do :) [15:20] greyback: can you please also install libegl1-mesa-dbg so we can get the missing functions in the trace [15:20] alf_: ack [15:21] greyback: are you able to run an example mir application? [15:21] alf_: yes, demo mir clients are fine [15:21] greyback: also use MESA_DEBUG=1 EGL_LOG_LEVEL=debug when running the qt app [15:22] ok === alan_g is now known as alan_g|tea [15:27] kgunn: sec [15:27] * ricmm reads back [15:28] go for it === om26er is now known as om26er1 === om26er1 is now known as om26er [15:34] ricmm didrocks: & done...platform-api trunk now dep on 0.1.1 mir [15:34] kgunn: thanks! [15:34] "just" the FTBFS now ;) [15:34] and then we can build/test/deliver Mir === alan_g|tea is now known as alan_g [15:36] alf_: http://pastebin.ubuntu.com/6437996/ <- egl seems to decide x11, not mir. [15:38] how does it decide? is there an env var maybe that could force it? [15:38] FYI I am running X11 on VT7. Am trying to run mir on VT1. [15:39] greyback: on the same machine? [15:39] alf_: yes [15:40] greyback: just curious...can you run a mir demo client per the instructions http://unity.ubuntu.com/mir/using_mir_on_pc.html [15:40] under "runing mir natively" [15:40] ...sorry if this is deja vu [15:40] kgunn: that's exactly what I'm doing. Demo mir clients work fine [15:41] greyback: just to be clear, you mean the mir server is running on VT1 but you want to start an app from VT7 under X11? [15:41] alf_: nope. I'm starting app from VT2 [15:41] for running under mir [15:42] greyback: ok, FWIW, running it from VT7/X11 should work too [15:42] alf_: yes that makes sense :) [15:42] * greyback stops using VT2 [15:43] greyback: are you using qtubuntu trunk or some other branch (I want to take a look at the code there) [15:43] alf_: please...can you do that after the drm_auth_magic test failure [15:44] kgunn: I am doing it in parallel, the package is building (which is slow) [15:44] :) thanks [15:45] alf_: heh, this is where things get annoying. I'm using Qt5.2, and made a branch of qtubuntu to support it, and also hack around depending on hybris: alf_: I made a branch so it wouldn't depend on hybris. lp:~gerboland/qtubuntu/qt5.2-on-desktop/ [15:46] alf_: but please you try using standard qtubuntu, just to test please [15:46] greyback: as a first step I want to take a look at the code [15:47] alf_: sure [15:48] alf_: src/platforms/base/context.cc will be of interest to you [15:51] Happy monday! [16:17] kgunn: I can't recreate the problem building the package locally :/ === dandrader|lunch is now known as dandrader [16:31] alf_: thanks...hmmm.... didrocks thots to proceed ? [16:33] kgunn: did you ask on #webops? [16:41] didrocks: so sorry...was otp...why webops ? [16:41] kgunn: they will be able to help to debug why the test segfault on devirtualized ppas (meaning, distro builders) [16:41] even getting you chroot access I guess [16:52] racarr: mornin' [16:53] Morning kgunn! [16:53] alan_g: My branch actually does conflict with yours a little...I want to just straight up remove the session container [16:53] maybe we can talk about it tomorrow? [16:54] racarr: I've no problem with it being removed [16:55] alan_g: The thing is we only use it internally for the system compositor focus tracking (i.e. finding hwich session to give focus to when another closes) [16:55] so rather than make it a customizable component, I am just going to fold it in to [16:55] msh::DefaultShell [16:55] which is the new SessionManager [16:56] / implementor of mf::Shell [16:57] Hmm. But the "Controller" part of SessionManager belongs in surfaces [16:57] As does the "Model" part [16:57] hmmmaybe, I mean it wont be the same manager, I am changing [16:58] the mf::Shell interface as well [16:58] So, I'm not convinced by "msh::DefaultShell" [16:58] to basically mirror the mf::SessionMediator interface [16:58] except in terms of Mir server types instead of IPC types [16:58] to the DefaultShell, takes the fully interpreted IPC requests, and decides which controller components to use [16:58] to update the model [16:59] s/to the DefaultShell/so the mf::Shell/ [17:00] I guess I should look at what you're doing. (But my head is full ATM) [17:00] I will propose it todayhopefully [17:03] OK will look in morning [17:17] robotfuel: since some services are back to working....have you had a chance to test out the demo clients as part of ci ? [17:19] kgunn: I am working on that now [17:27] robotfuel: please check latest lp:~afrantzis/mir/offscreen-display [17:27] alf_: will do thanks [17:32] android clients? :) === dandrader is now known as dandrader|afk [17:50] kgunn: I am still waiting for this a MP to land before we can add demos to CI, I've talk to the phablet team and it's on their list to review today, they have a bunch of reviews to do. https://code.launchpad.net/~chris.gagnon/phablet-tools/run-test-without-autopilot/+merge/194920 === dandrader|afk is now known as dandrader [18:07] racarr: https://code.launchpad.net/~robertcarr/mir/cbranch-can-not-be-named-fix-1247718/+merge/195629 has problems I got this failure: /tmp/buildd/mir-0.1.1/tests/unit-tests/input/android/test_android_input_manager.cpp:158:83: error: template argument 1 is invalid === alan_g is now known as alan_g|EOD [18:27] alf_: just FYI, I did a little digging, found if I set EGL_PLATFORM=mir, then I get further. Failure now with EGL_BAD_CONTEXT... [18:27] alf_: your new offscreen branch crashes my X session, but otherwise seems to work. [18:29] robotfuel: it's not ready to be run under X11 yet, you still need to be in a VT [18:30] alf_: I am running it in a vt with sudo mir_demo_server_basic --offscreen --vt 3, yet it still crashes my X session [18:32] robotfuel: ok [18:33] greyback: if you don't solve this today, please send me an email with quick instructions so that I can try tomorrow morning [18:34] alf_: ok [18:50] robotfuel: btw, you can't switch back to X while the offscreen server is running yet (I guess that's what you meant by killing the X session) [18:51] alf_: ah ok, maybe that is the issue? I've added the crash part of the X log to the MP [18:52] alf_: X restarts in fallback mode on tty8 after running --offscreen [18:52] robotfuel: only when switching to X while offscreen is running, though, right? [18:53] alf_: I did try to switch back to tty7 I'll retry [18:55] alf_: yeah If I don't switch back X does not crash. [18:56] robotfuel: ok, thanks [18:57] alf_: I also updated the comment in the MP. [19:03] racarr, ping [19:10] bschaefer: pongalong [19:11] racarr, hello! So, i was digging around in the motion event, and it doesnt seem to expose the type of device being used [19:11] ie: http://paste.ubuntu.com/6438929/ [19:11] with out exposing the ToolType, you don't know if it the event is a mouse/finger/etc.. [19:11] bschaefer: Seems correct [19:12] racarr, i can test it out some more, but was just wondering if you knew of any other way :) [19:12] without having to use an unused var [19:16] No. sorry. [19:17] racarr, alright, well i can make a bug, and get some tests then I can get an MP up [19:17] thanks! [19:17] Thankyou ! [21:36] * kdub forgot to restart xchat after x locked up [21:50] timefor awalk [21:50] at thatpoint in refactoring where its like [21:50] ahahgashgahsga [21:50] also its really time for a new space key [22:06] racarr, c++ doesn't need the space key :P [22:07] just tabs