[00:41] RAOF, lightdm.log - http://paste.ubuntu.com/5953288/, X log - http://paste.ubuntu.com/5953289/. Tried with a rebuilt Xorg, but no change [00:41] RAOF, any ideas? [00:41] also, any thoughts on bug 1206744? [00:41] bug 1206744 in XMir "black screen on nvidia gt640 with system-compositor-testing ppa" [Critical,New] https://launchpad.net/bugs/1206744 [00:42] Hm. My guess is that X is spinning in a loop somewhere; attaching gdb might be fruitful. [00:43] robert_ancell: Ah, I should respond on that bug, even though my current response is going to be "huh?" [00:53] robert_ancell: Oh - does XMir start against mir_demo_server_shell? That's easier to test while keeping an active session. [00:53] RAOF, I'll try that in a few mins === csslayer_ is now known as csslayer [01:23] Hm. I'm not sure this powerpc build of xf86-video-ati is actually going to start. [01:28] I assume it ignores the package name for starters ;) [01:40] What do you mean? There's plenty of PPC hardware with radeon chips. [01:51] RAOF: "86" [01:53] Ah. [01:57] Yeah, that's been wrong since forever. [04:04] RAOF, yeah, so I can't run X in mir_demo_server - any debugging ideas? Can you reproduce? [04:05] robert_ancell: I couldn't on radeon; I'll try again on intel. [04:05] robert_ancell: There's a new set of drivers in ppa:mir-team/staging which you might want to try, too. [04:09] RAOF, I have the drivers from main, which seem to be the latest [04:11] Ah, yeah. For intel that's true. [04:15] Ah, yes. I really, truly, can't reproduce with current stuff on radeon. [04:25] * RAOF reboots to turn on his intel card [04:37] Huh. I can't reproduce the hang, but I *can* reproduce a segfault [04:43] RAOF, in XMir? [04:43] In the intel driver. [04:43] Which you might not be hitting, because it's in the gen7 accel pathways. [04:47] Hm. Although that's clearly a bug in xmir's damage code *somewhere* [05:00] Huh. Yes, that might also be the cause of the unity blankness. [05:06] RAOF, so it's only in the new driver? Should I try the old one? [05:06] It looks like it might be an interaction of the new driver with the new xmir. [05:07] I'm just testing an xserver patch [05:10] Yup, that works for intel. [05:10] RAOF, the xserver patch? I downgraded the -intel driver and no change here [05:11] Yeah, xserver patch. [05:11] RAOF, so new xserver release needed? [05:11] Looks like it. Checking that it doesn't break !intel [05:12] RAOF, ok, I'll open a bug and file it to you. Should we file bugs against ubuntu/xorg-server or xmir? [05:12] (given we're now in main) [05:12] ubuntu/xorg-server [05:12] Feel free to tag with xmir. [05:13] good morning [05:14] Yo! [05:15] robert_ancell, RAOF I noticed yesterday that mir from the archive (usc rebuilt on top of it) fails to start with ^Flinker^@linker.c:1095| ERROR: Library '/system/lib/libGLESv2.so' not found [05:16] This would be on the phone, right? [05:17] bbl [05:17] RAOF, nope, on the desktop :) a bit surprising, isn't it? [05:17] doko_, ping [05:17] Yes indeed. [05:22] Ah, yes. That does indeed break radeon. [05:25] RAOF, for me it happens on Intel [05:25] tvoss: Blank screen? [05:26] RAOF, no, fallback to X [05:26] Oh, the failure to start. [05:26] That's a super odd one; is your /etc/ld.conf correct? [05:27] RAOF, what am I looking for? [05:29] Should only contain a pointer to ld.so.conf.d/*; that should just contain obvious bits. [05:29] RAOF, /etc/ld.so.conf includes files from /etc/ld.so.conf.d [05:29] Particularly, should not contain /system/lib/* anywhere :) [05:29] RAOF, i386-linux-gnu_EGL.conf i386-linux-gnu_GL.conf i686-linux-gnu.conf libc.conf x86_64-linux-gnu.conf x86_64-linux-gnu_EGL.conf x86_64-linux-gnu_GL.conf [05:29] that's the ld.so.conf.d contents [05:29] All looks sane. [05:30] I need to help with Zoë for five minutes; I'll think more. [05:33] RAOF, tried the mir_demo_server_shell, hangs my system [05:34] tvoss: I don't think we support multiple simultaneous servers yet, so demo_server* won't work if you're running USC... [05:35] duflu, I'm _not_ running USC :) [05:35] Ah [05:38] RAOF, how do we release new xserver and drivers? Is that somehow guarded/gated or do we just push to the archive? [05:43] tvoss_: We just push to the archive. [05:45] RAOF, I wonder if we should gate that, too. Especially as multiple people could push to the archive [05:45] Well, it's gated in -proposed. [05:45] Like everything else. [05:46] RAOF, what tests are run in proposed? [05:47] On the Xserver? None at the moment. [05:47] But I think we run a full pass of every other component before promoting out of proposed. [05:47] Speak of the devil! [05:47] 'tis didrocks! [05:47] didrocks, good morning :) [05:48] hey RAOF, tvoss_! [05:48] * didrocks overslept, not sure if it's because of the UK delay [05:49] RAOF: thanks for -ati, -nouveau! [05:51] ok, the mirslave failed the same way apparently [05:51] now, we need to wait for all dailies to finish to be able to relaunch it [05:51] argh, ati machine down again [05:51] Aha! *That's* what was going wrong! [05:51] RAOF: what? [05:51] thomi: around? [05:52] Oh, just tracking down some damage stupidity in the xmir/xmir-ddxen. [05:53] RAOF: tvoss_: did you reproduce the issue I was mentionned with latest mir+xorg from distro and u-s-c from daily-build ppa? [05:53] didrocks, yup, usc fails with ^Flinker^@linker.c:1095| ERROR: Library '/system/lib/libGLESv2.so' not found [05:53] didrocks, on my laptop :) [05:54] interesting, should we blame RAOF and the mesa upload then? :) [05:55] or something else in the linking is looking for it somewhere else? [05:55] like a RPATH [05:55] That's a tremendously odd lib path. [06:02] RAOF, which one? [06:02] /system/lib/ [06:05] RAOF, indeed [06:05] RAOF, seems like mir is compiled for armhf [06:05] Yeah, that's what it looks like. [06:11] didrocks, ^ [06:12] tvoss_: debian/rules still makes sense though [06:13] didrocks, right. there is http://bazaar.launchpad.net/~mir-team/mir/trunk/revision/922 though, not sure, how that might interfere [06:13] it doesn't have the -D<…> specific to android [06:13] tvoss_: no, shouldn't [06:13] didrocks, the one thing that is interesting: if I do an apt-get source on libmirserver0 and try to build locally, the build fails [06:14] $ ldd /usr/lib/x86_64-linux-gnu/libmirserver.so.0 | grep libGL [06:14] libGLESv2.so.2 => /usr/lib/x86_64-linux-gnu/libhybris-egl/libGLESv2.so.2 (0x00007f8e46144000) [06:14] here [06:15] after removing libhybris: [06:15] libGLESv2.so.2 => /usr/lib/x86_64-linux-gnu/mesa-egl/libGLESv2.so.2 (0x00007f080cd74000) [06:16] not sure you are seeing the same issue then [06:21] robert_ancell: There's a shiny new xserver in mir-team/staging. [06:32] RAOF, how can we solve that ld issue? [06:33] RAOF, can we dictate an order for resolving to the linker? seems to me it is alphabetical [06:33] Um. Why is libhybris installed at all? [06:36] RAOF, it is installed by the platform api, checking why that is the case for non armhf targets [06:37] Right.\ [06:37] So, the problem is that libhybris has claimed the EGL alternative. [06:38] Which is correct, actually; you *want* it to. [06:38] Except it makes no sense when not running on an android system. [06:39] RAOF, right, and that's the case in the archive, too [06:40] So - is there any particular reason why libhybris should be built on any architecture other than armhf? [06:41] Because “apt-cache rdepends libhybris” shows there to be a large number of ways for me to accidentally break my system. [06:42] RAOF, nope, looking at the same output [06:43] RAOF, either we fix all of the rdepends, or we find a creative way to trick the alternatives mechanism in taking into account the platform it is running on [06:44] We fix all the rdepends, and not build libhybris on i386 and amd64 [06:44] RAOF, working on the platform api right now [06:44] Unless we're targetting some crazy i386 android hardware it is never correct to have libhybris installed on i386 or amd64. [06:45] RAOF, right [06:51] * RAOF heads to the shops to get dinnerables. === doko_ is now known as doko [06:52] tvoss_, hi [06:52] doko, hey there :) cancel that ping [07:06] didrocks, can I filter rdepends by architecture? [07:07] tvoss_: not easily, it's better to apt-cache policy [07:07] didrocks, ack ... [07:10] good morning [07:13] robert_ancell: Been able to test with that X server? [07:29] RAOF, I'll test nw [07:30] TA [07:32] RAOF, no, still spins at 100% CPU [07:32] Grr. [07:33] I'll check again locally. [07:38] RAOF, Does XMir show a background? Or is a black background what I'd expect to see on success? [07:38] If you pass -retro you'll get to party like it's 1989 to the eye-bending X root weave. [07:39] Otherwise, yeah. Black background with no cursor is your success criterion. === alan_g|EOD is now known as alan_g [07:39] RAOF, ah, I still have the cursor so it must not work [07:39] Which cursor? [07:40] RAOF, the Mir cursor [07:40] Ah. [07:40] Tried with -retro, definitely no background [07:41] Grr. It all works just fine here. Could you run X from gdb and see where it's spinning? [07:43] RAOF, yep [07:48] RAOF, hmm, I seem to have stopped the X mouse working - any way to reset it? [07:49] i.e. my existing X session, so can't copy the output I want to show you :) [07:51] RAOF, Weirdly, when I run X from inside Unity it works, and not when I run it from a VT [07:52] That *is* weird. [07:52] robert_ancell: ‘sudo modprobe -r psmouse; sudo modprobe psmouse’ might work. [07:52] To get your mouse back :) [07:53] RAOF, nice! [07:53] When all else fails, remove the device and retrigger hotplug :) [07:53] (worked!) [07:53] RAOF, when running it inside Unity under gdb I got a segfault, but not sure if that [07:53] 's related [07:54] RAOF, http://paste.ubuntu.com/5954185/ is the backtrace [07:55] bug 1208715 [07:55] bug 1208715 in xorg-server (Ubuntu) "XMir fails to start on intel" [Undecided,New] https://launchpad.net/bugs/1208715 [07:56] RAOF, were you running X from a VT? [07:56] Yes [07:57] RAOF, so, when I run from a VT stopping X with ctrl+Z stops in a variety of places [07:57] I've never seen that crash before :) [07:58] RAOF, first one is main -> InitOutput -> xf86DeleteDriver [07:58] Urgh. Spinning in DeleteDriver again? But why doesn't that occur here? [07:58] RAOF, actually, always in InitOuput [07:58] Guessing that should have completed.. [08:00] Correct, that should have completed. [08:00] Could you pastebin your xorg log? [08:01] RAOF, http://paste.ubuntu.com/5954194/ [08:03] Urgh. It's going to be your crazy hybrid laptop again, isn't it. [08:03] RAOF, yep, haven't changed hardware here [08:03] At least I seem to hit these problems before other people ;) [08:04] didrocks, hey, the Mir daily landing automatically goes to main now right? I checked the job and it seemed to have gone through without a manual step [08:05] RAOF, anything else I can do from this end? [08:06] robert_ancell: Not unless you particularly feel like getting your elbows into xf86DeleteDriver [08:06] RAOF, not particularly, at least not at the end of a night :) [08:07] robert_ancell: there was a manual publication because of a packaging change today [08:07] robert_ancell: but yeah, otherwise, it goes straight to main [08:07] didrocks, ta [08:07] no u-s-c running successfully yet though :/ [08:07] (see my emails) [08:08] didrocks, yeah, I checked the job there :( [08:09] didrocks, in a *.install file, can I restrict installation of a file to an architecture? [08:10] tvoss_, sounds unlikely! [08:10] tvoss_: no, you need to play a silly dance like .install.in -> .install [08:10] didrocks, do you have an example for that handy? [08:10] didrocks: Actually, you can have an install.$arch [08:10] ooh [08:10] RAOF: right, but you duplicate everything [08:10] tvoss_: depends on how long your list is ^ [08:10] That is true [08:11] ok, gtg. Later all! [08:11] RAOF, didrocks so I would have *.install for everything and a special *.install.armhf for armhf installs? [08:11] robert_ancell, g'night [08:11] see you robert_ancell [08:11] RAOF, please update the bug if you find anything [08:11] tvoss_: no, .install will be used if it doesn't find a .install.armhf [08:12] didrocks, okay, that's why the list length is important :) [08:12] so you need to cp .install .install.armhf [08:12] right ;) [08:12] think to symlink a .install.arm64 to .install.armhf as well [08:12] (as it's incoming) [08:13] didrocks, alternatively: can I restrict a binary package in debian/control to an architecture? [08:13] Easily. [08:13] tvoss_: yeah, just change "any" in Architectures: [08:13] to "armhf amd64" [08:13] tvoss_: for hybris though, check with ricardo, IIRC, they wanted to build on i386/amd64 for some reason [08:13] didrocks, arm64 it is, right? [08:14] didrocks, sure, I'm taking care of that right now [08:15] * RAOF hits Zoë evening time [08:16] tvoss_: right, arm64 [08:16] RAOF, can you give me a quick handover when you are back? [08:22] duflu, ping [08:22] tvoss_, pong [08:23] duflu, hey there. I was wondering if boost::circular_buffer might be of use to you [08:23] tvoss_: Not sure. I would have to have a good reason to rewrite things and add more dependencies on boost tho [08:23] Don't have any such reasons [08:24] duflu, well, the best reason is that it is tested and in production for some years from my pov [08:24] tvoss_: My current implementation without boost is much better tested than with boost. :) [08:26] hi [08:26] Good morning hikiko [08:26] duflu, I don't want to discuss this to death, but my pov is that we shouldn't reimplement circular buffers on our own :) [08:27] when I build mir trunk I get this error: [ 29%] Building CXX object src/shared/input/CMakeFiles/mirsharedinput.dir/android/android_input_receiver.cpp.o [08:27] /usr/lib/i386-linux-gnu/libc_nonshared.a(stack_chk_fail_local.oS): In function `__stack_chk_fail_local': [08:27] (.text+0x10): undefined reference to `__stack_chk_fail' collect2: error: ld returned 1 exit status [08:27] any idea what I am missing? (sorry the paste was longer than I expected) [08:28] hikiko: You've probably got out-of-date binaries that make fails to rebuild [08:28] tvoss_: The case used in my new code is quite different. It is a sequence of three queues in a single ring. Generic circular queues don't handle that === mpt_ is now known as mpt [08:28] duflu, that just depends on the template parameter then, right? [08:29] hikiko: first try: make clean&&!make [08:29] tvoss_: No, regardless of parameter it's insuffucient. Boost assumes one head and tail. I need three [08:29] alan_g, it was in a fresh build, I am dist-upgrading to see if I still get it [08:30] duflu, fair, just saying :) [08:36] alan_g, sorry I hadnt see the ! what does !make do? [08:36] it didn't fix it but it's the first time I see it :) [08:36] It runs your most recent command starting with "make" [08:37] interesting! [08:39] hikiko: second try: rm -rf * && cmake .. && make [08:41] alan_g, I tried but it didn't fix it... I am waiting dist-upgrade to finish because I might have outdated libraries used by mir :s [08:41] but it was compiling until yesterday [08:43] hikiko: in the same directory? [08:45] you mean to try cmake in the root dir? [08:46] alan_g, I did the same things I do everytime to compile mir [08:46] I mean was yesterday in the same directory as today? [08:47] no [08:47] Is today a fresh checkout> [08:47] yesterday it was on staging/mir today in staging/trunk [08:47] and the trunk is a fresh checkout [08:48] If you update to yesterday's revision does it still fail? [08:49] let me check === alan_g is now known as alan_g|tea [08:54] in 928 I get the same error trying 927 now [08:56] didrocks, related question to *.install: can I have architecture specific symbol files? [08:56] tvoss_: yeah, same rule, *.symbol.armhf [08:56] didrocks, thanks [08:56] yw ;) [08:57] it's a pain to update though, people needs to update both before merging === alan_g|tea is now known as alan_g [09:03] didrocks, fair, but at least we force people to be conscious [09:06] alan_g, I don't get it in 925 [09:07] but I get it in r 926-929 [09:08] hikiko: so there's something about -c 926 that disagrees with your system? [09:09] Mine is happy, as are the CI platforms. [09:09] What does "uname -a" give? [09:09] Linux qubby 3.10.0-5-generic #15-Ubuntu SMP Wed Jul 24 19:44:23 UTC 2013 i686 i686 i686 GNU/Linux [09:10] you're 32bit? [09:11] yes [09:11] * alan_g doesn't know why that would be a problem, but it is an obvious difference [09:12] :s [09:12] let's see what's the change in 926 [09:14] any funny mir bugs for me to look at? :P [09:15] alan_g, do you think I have to fill a bug report? [09:17] hikiko: if you feel like it. [09:19] well if I don't find a way to fix it +send a patch I will submit one :) [09:22] hikiko: OK. (I think I've got a 32bit VM set up - but it probably needs updating as I only use it for tax purposes) [09:28] alf__: can you have quick look over -c 926? hikiko finds it FTBS on her *32bit* system. [09:30] alan_g: sure [09:38] Hmm, http[s] traffic is timing out. Is chat working? [09:39] alan_g: I can read your message [09:39] * alan_g decides to restart router before calling ISP [09:39] BRB [09:44] alan_g https://bugs.launchpad.net/mir/+bug/1208774 [09:44] Ubuntu bug 1208774 in Mir "`__stack_chk_fail' error in 926 and later revisions (i386)" [Undecided,New] [09:47] greyback, ping [09:47] tvoss_: pong [09:48] greyback, hey there :) quick question: which symbols from the platform api do you/unity-mir consume? [09:48] hikiko: what does 'objdump -T /lib/i386-linux-gnu/libc.so.6 | grep __stack' say? [09:49] $ objdump -T /lib/i386-linux-gnu/libc.so.6 | grep __stack [09:49] 00106b70 g DF .text 0000001a GLIBC_2.4 __stack_chk_fail [09:49] outdated? [09:50] I ve seen the http://stackoverflow.com/questions/5090881/libgcc-s-so-undefined-reference-to-stack-chk-failglibc-2-4 as well [09:50] tvoss_: from platform api, only ua_ui_mirserver_init & ua_ui_mirserver_finish [09:51] greyback, ack [09:51] that's all that unity-mir & unity8 needs. qtubuntu naturally uses more [09:53] hikiko: can you pastebin flags.make and link.txt from build/src/shared/input/CMakeFiles/mirsharedinput.dir/ [09:54] hikiko: btw, are you building with make -jX ? [09:54] np [09:54] no [09:54] hikiko: ok [09:54] just make or make all [09:56] http://pastebin.ubuntu.com/5954501/ [09:57] http://pastebin.ubuntu.com/5954503/ [09:57] alf__, ^ [09:57] hikiko: thanks [09:58] someone in stack overflow says that: add -fno-stack-protector when linking for a similar problem [09:58] but if that was the problem shouldn't we get the error in amd-64 as well? [09:58] * alan_g is back via a mobile connection [10:00] hikiko: the pastes look normal [10:01] :S [10:01] hikiko: has dist-upgrade finished? [10:01] yes [10:02] before I build 925 and 926 [10:02] let me reboot just in case [10:12] alf__, BTW I saw a cmake message [10:12] You have called ADD_LIBRARY for library 3rd_party without any source files. This typically indicates a problem with your CMakeLists.txt file [10:14] i rebooted and got the error again [10:14] smartboyhw: it's ok, just ignore this [10:48] hikiko: any progress? [10:53] alan_g: hikiko: I have managed to reproduce this in a i686 chroot. I have found that explicitly linking against libc (-lc) fixes the build issue, but I haven't figured out why we need this. [10:56] alf__: thanks, I guess that's enough for hikiko to work around it? [10:56] alf__, thanks cool :D [10:57] could you pls submit the fix? [10:58] hikiko: it's a workaround, feel free to use it until we figure why this happens, I don't think it should end up in trunk just yet [10:58] +1 [10:58] ok so I just add a -lc in linker flags? [10:59] hikiko: yes, in src/platform/graphics/CMakeLists.txt [10:59] thank you! :) [10:59] hikiko: yw [11:02] alf__: My broadband is intermittent at best, so I'm working on laptop/mobile (so I don't want to download 32bit saucy just now). But if you want to assign me the bug I'll pursue it once service is resumed. [11:04] alan_g: Sure, feel free to assign the bug to yourself when the networking issues are fixed. In the meantime I will continue investigation. [11:09] alf__: How badly do we need to block on the lazy allocation optimization? Reimplementing it has taken 10 hours of my time so far and still not quite done [11:14] I mean, it's almost done, and I thought fully covered by tests, but I just discovered a strange bug where a client might get stuck at 40Hz. What is 40Hz?... :) [11:17] Oh. 40Hz would be a problem with every third frame, of course [11:19] duflu, which might hint to triple buffering ;) [11:19] tvoss_: It is. I know === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g [11:39] pushed a bugfix for the xf86DeleteDriver infinite loop [11:47] duflu: I am OK with not blocking the current MP for it, as long as it's going to be done soon enough. [11:48] alf__: That's good. I'm past thinking straight for today anyway [11:51] duflu: although, if we don't have this, we can't really test how the new swapper/bundle behaves with double-buffering. [11:52] alf__: What do you mean? The tests cover double buffering. [11:52] duflu: I mean from a visual fluidity perspective, not so much from a correctness one [11:53] alf__: Yes I know. I have some additional timing tests in mind to add [11:55] duflu: e.g. will multi-monitor use cases continue to work as well with strict double-buffering? [11:55] alf__: Should do... [11:55] alf__: But again, I'm past thinking straight [11:55] Later... [12:00] alf__: I spotted a mistake in -c 926 - can't see it causing the link problem, but mentioning it: lp:~alan-griffiths/mir/remove-spurious-link-options [12:00] alan_g: ok, trying in the chroot === alan_g is now known as alan_g|lunch [12:01] alan_g|lunch: no difference === dholbach_ is now known as dholbach === tvoss_ is now known as tvoss|lunch === hikiko is now known as hikiko|lunch === dholbach_ is now known as dholbach === hikiko|lunch is now known as hikiko [13:02] just wondering do we have a contributor agreement before submit? [13:04] how do I find matching versions of mir/usc/xorg-server ? [13:05] i seem to repeatedly get mismatched versions when trying === alan_g|lunch is now known as alan_g [13:36] question: [13:37] I am writing the nested display and at some point I need to create a mir surface [13:38] In the examples we call: MirSurfaceParameters const request_params = [13:38] {__PRETTY_FUNCTION__, 640, 480, pixel_format, mir_buffer_usage_hardware}; [13:39] so, I wonder what size we need instead of 640, 480: the full virtual screen size, something else I have to get from the nested mir? 640, 480 for the moment? [13:39] from native mir* [13:39] alan_g, alf__ any ideas? [13:41] hikiko: Ideally you would need one surface per output I think [13:41] which means? [13:42] hikiko: that you should read the display configuration and create the surfaces accordingly [13:43] is it similar to what you do in the gbm display? === alan_g_ is now known as alan_g [13:45] hikiko: In its final form it should be something like that. Perhaps as a first step just support one surface covering the full virtual screen size as you mention. [13:46] chihchun, the contributor agreement is linked from here. http://www.canonical.com/contributors [13:46] didrocks: just sanity check my thinking.....i should have everything i need in main except u-s-c [13:46] didrocks: so if i am up to date [13:47] i should just be able to rebuild local u-s-c- & install.... [13:47] to test right ? [13:47] hikiko: you only need to create a surface when your client asks for one - doesn't that request supply everything? [13:48] alan_g, I am not talking about an egl surface but for the MirSurface I ve seen that we use in mir_demo_client_accelerated [13:49] I guess I have to create such a MirSurface at the nested_display initialization [13:49] isn't it? [13:49] and then initialize egl create the egl surface et c [13:50] hikiko: surely all you need to do is forward the requests coming from a client? [13:51] Doesn't the client do the rest? === alan_g is now known as alan_g|afk === tvoss|lunch is now known as tvoss|hungry === tvoss|hungry is now known as tvoss_ [13:53] yes sounds reasonable.. but I am a bit comfused I have to think it a bit more to clarify what is done in the client and what in the server === chihchun is now known as chihchun_afk === alan_g|afk is now known as alan_g [13:58] hikiko: Just fill in the unimplemented functions in NestedPlatform? [13:59] alan_g, that's what I started doing: I started from create_display and then added all the display functions to be able to call the constructor [13:59] but maybe it's better to just add an exception there [13:59] and move to the rest of the functions [14:00] An exception where? [14:01] in the NestedDisplay constructor [14:01] mm no [14:01] I have to finish with the display before filling the rest of the NestedPlatform functions [14:02] hikiko: Doesn't the NestedDisplay constructor just need to initialize a pointer to the NativeDisplay? [14:02] Why should it throw? [14:02] and do nothing more? [14:02] :s [14:02] What else does it need to do? [14:03] the nested display will just forward every request to the native display? [14:03] I don't know - I don't remember your spike well enough [14:04] But mostly, yes [14:07] didrocks: ping [14:09] alan_g, what does spike mean? [14:10] The version you wrote by changing the code at compile time [14:11] oh, there I used to initialize egl in the display constructor [14:11] because that's what every display was doing (and the clients were doing the same) and then yes I was using the native code for the rest [14:12] I was creating a full screen mirsurface [14:14] hikiko: I don't see a need to do anything (e.g. create a surface) that the client doesn't ask for. [14:15] * alan_g doesn't know everything [14:15] :) [14:15] it sounds reasonable [14:15]