[01:32] duflu, how does mir_pixel_format_xrgb_8888 and mir_pixel_format_bgr_888 have the red channel in the same location? [01:32] Where are the pixel formats defined? [01:34] robert_ancell: common.h ... the 32-bit formats are designed to be expressed as uint32 whereas the 24-bit formats are three bytes. So for little endian they are the reverse [01:35] That said, I'm not sure X can deal with the latter at all [01:36] very confusing [01:36] We use endianess like that so software apps using 32-bit formats don't need to ever do byte swapping to work on any machine. [01:37] robert_ancell: Yes, but it makes sense and is the best option if you think about it. The alternative is that every app would need #ifdef for different endianness [01:37] Unfortunately endian does not apply to 3 byte pixels. It makes no sense there [01:39] BTW, I did not design it that way. It was like that before I/we joined Mir [01:40] And it seems like the right solution too. Just confusing when dealing with some APIs like OpenGL that do the opposite [01:42] duflu, so your branch corrects the wrong masks right? The rest of it is just code moved around. [01:43] robert_ancell: Yes, and it ensures everything (screen and windows) agrees on the format of TrueColor pixels [01:43] Although it's still not ideal for EGL. More work is required there [01:45] duflu, btw we do know that software mode works - the goal is to get EGL to work [01:45] More importantly, I've now done an MP in git-for-launchpad :) [01:45] duflu, yeah, well done! [01:47] duflu, you can just push into the xmir branch [01:48] robert_ancell: Yes, software has always worked. Although the upload/copy operations in software are slowish, rendering the same in OpenGL arguably uses even more resources. And OpenGL needs the buffer held for longer. The only problem is some droids (and I noticed it on mako) sometimes corrupt software buffers on screen. That's usually a flags bug in the Mir android code [01:48] duflu, what do you mean by "uses even more resources"? [01:49] Software mode seems poor when resizing windows, I'd expect that to be faster in OpenGL right? [01:49] robert_ancell: Both rendering approaches require an "upload" or copy of the whole surface. However there's no OpenGL state and texture to worry about in software [01:50] robert_ancell: Yeah some things will be faster in GL on some devices. But there's not a huge difference if your apps are software rendering in the first place [01:50] duflu, so, do you think getting EGL to work is a waste of time? [01:50] robert_ancell: No, I think EGL will be faster for some things and we should do it [01:52] Even the upload itself may be faster in some GL implementations === chihchun_afk is now known as chihchun [01:57] robert_ancell: It's satisfying being able to play /usr/games/sol on the phone :) [01:58] heh === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [02:22] robert_ancell: Theoretically rootless should let us skip a copy completely. Because the X server no longer has to composite its apps in software into the screen surface. But I don't know the reality of the implementation. That's just theory. [02:23] duflu, yeah, I guess === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [04:04] robert_ancell: BTW found a simpler solution to the xkb problems. Just configure with --prefix=/usr [04:04] So it finds everything in the right place [04:04] duflu, and you can then run without installing? [04:04] robert_ancell: Yep, no installation [04:04] sweet [04:05] Sweet unless there's an ABI break [04:05] But I don't think Xorg does ABI breaks much === chihchun is now known as chihchun_afk [04:19] Xorg breaks ABI every release. [04:19] Not quite, but very nearly. [04:21] Hm. That's got to be a gcc bug. [04:21] auto foo = [this]() { return display_config; }; foo().active_configuration(); blows up. [04:22] auto foo = [this]() -> mg::DisplayConfiguration const& { return display_config; }; foo().active_configuration(); works as expected. [04:33] RAOF, how is 'this' actually defined? Just a pointer to the class right? (raw c pointer?) [04:34] nm what i was thinking makes no sense (was thinking something with a std::unique_ptr) [04:37] Yeah, “this” is a keyword meaning “pointer to the implicit first parameter of the function call” :) [04:41] RAOF, yeah was trying to find the actual definition in the standard but 'this' is an over used word :) [05:27] Ok, wtf? [06:00] How is DefaultServerConfiguration::configuration_options being set to a non-null value in the constructor, but then the_options() SEGVing because configuration_options contains null? [06:01] Cosmic rays [06:02] Hm, or slicing? === Hawk is now known as Guest44551 [06:02] $1 (this) = (mir::DefaultServerConfiguration * const) 0x1c44e10 [06:02] (Contains correct value) [06:02] $4 (also this) = (const mir::DefaultServerConfiguration * const) 0x1c44e10 [06:03] Oh, no. That's the same value. [06:03] It looks different in gdb :) [06:03] Watchpoint it is. [06:04] duflu, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1493185 [06:04] Ubuntu bug 1493185 in unity8 (Ubuntu) "missing icons in dash/app scope for ubuntu touch vivid image" [Undecided,New] === Guest44551 is now known as change [06:05] Guest44551: Thanks. Sounds like the ubuntu UI toolkit (that is shader heavy and sometimes the least portable part) === change is now known as Hock [06:05] anyone looking into it? [06:06] Hock: I will reassign it. Can you attach a screenshot? That URL does not work..!? [06:08] Hock: The relevant people log on in a couple of hours [06:08] They should notice it [06:11] i attached it [06:12] i submitted this bug two days ago. :( [06:12] Hock: Thanks. I just checked the source code. Looks like ubuntu-ui-toolkit. It's possible you'll get a better response now it's assigned to the right project today [06:13] duflu, great! thanks [06:13] Hock: We had a similar issue recently. ubuntu-ui-toolkit is ambitious, sometimes to the point of non-portable [06:13] this will not be related to gralloc hal crashing using CM kernel, right? [06:14] Hock: No, your kernel unity8 and Mir seem to be working fine [06:14] this is fine as its on aosp kernel [06:14] when i tried using CM kernel, the gralloc refused to start. [06:14] just died [06:14] Hock: Nice working getting that far [06:14] *Nice work [06:15] nice. but still long way to go [06:15] I'm not so sure it's a long way [06:15] wifi doesnt work as the stock kernel does come with source [06:15] its binary wlan.ko [06:16] have been trying a few prima sources but insmod hung [06:16] and wlan0 does not get created [06:16] CM kernel cant be used as their gralloc dont play nice with ubuntu touch [06:17] anyway hint on how to get cm gralloc to work? [06:18] Hock: Don't know. If you don't get a response within a day then the person is: https://launchpad.net/~loic.molinari [06:18] For the bug that is [06:18] ok. [06:18] how can I tell the verion of mir that I am running on? [06:19] version [06:21] Hock: dpkg -l | grep libmir [06:22] But Mir is working (or else many things would have failed before the screen got painted that much even) [06:24] 0.13.3+15.04.20150617-0ubuntu1 [06:24] libmirclient9:armhf 0.14.1+15.04.20150821-0ubuntu1 [06:24] mixed of 0.13 and 0.14 [06:24] Hock: Sounds like vivid (which is presently a mix of 0.14.1 and 0.13.3, the latter is for some clients that haven't been updated) [06:24] yes, mir is working. just the icons [06:25] yes, i switched back to vivid [06:25] going to wily does not solve the icons issue [06:47] Ok, that's weird. [06:48] If you call the_frontend_display_changer() from the_session_coordinator(), Mir crashes. [06:49] OH! [06:49] Because there's a cycle there. [06:50] Nice of ABSOLUTELY NOTHING AT ALL to notice a stack overflow. === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g [13:20] RAOF: Is there a reason that those are needed over the binary blog that the RaspPi folks are using? [13:35] * ogra_ shkes fist towards provider ... [13:35] tedg, kms support perhaps ? [13:35] the binary blob is used in any case, you cant boot the board without it [13:35] (the bootloader is contained in the blob) [13:36] Yeah, not sure. I just want Mir on my RPi2 :-) [13:40] i dont think we have all needed userspace for the closed driver either yet (libEGL, libGLES etc) [13:48] So perhaps that is the Mesa work that was mentioned. [13:48] yeah === dandrader_ is now known as dandrader === dandrader is now known as dandrader|afk === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g === dandrader|afk is now known as dandrader [17:00] AlbertA: hi, i'm just wondering if you had a chance to think about how we can implement GtkComboBox behaviour using Mir menu surfaces === alan_g is now known as alan_g|EOD [17:15] attente: not quite just got back from vacation [17:16] AlbertA: oh, sorry. welcome back! === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [18:05] is mir-platform-graphics-mesa-x4 meant for use in xmir? or is it something else? [18:14] dandrader: that might be mir on x [18:14] camako: ^ [18:18] my test laptop (vivid+overlay) is strange after I dist-upgraded and thus got mir 0.15. Some things are not working anymore. Not sure what I messed up. I tried to clean up all traces of mir 0.14 pakages. now at least I can get "sudo mir_proving_server" working [18:19] but when I try to run a client, it fails to connect. eg running mir_demo_client_egltriangle gives a "Can't get connection" failure [18:19] I made sure I had MIR_SOCKET=/tmp/mir_socket set [18:19] dandrader: thats for running mir within x [18:19] so, how do I start debugging that? [18:19] anpok, ok, so I can safely ignore this [18:21] hm that should be MIR_CLIENT_SOCKET= [18:21] so my mir_demo_client_egltriangle is giving a "Can't get connection" error message when I try to run it in my mir_proving_server. how do I start debugging this? [18:21] and --arw-file to ensure that the permission . [18:22] is open enough for other users [18:22] anpok, yeah, did "sudo chmod a+rw /tmp/mir_socket" as well [18:22] anpok, what client-side env vars should I set to get some logging explaining what's going on? [18:23] anpok, or is it really a very basic error where logging wouldn't help anyway... [18:55] hmm dandrader, tried to reproduce but I my vivid vm now has problems with egl.. [18:55] dandrader: MIR_SERVER_SESSION_MEDIATOR_REPORT and _CONNETION_REPORT = log are the most basic logs for server interactions [18:56] sorry CONNECTOR_REPORT [18:59] anpok, but that's on the server side. any env var I could set on the client side? [19:02] there is MIR_CLIENT_RPC_REPORT.. [19:02] but not sure what do read out of it [19:02] the issue seems to be on the client side. like it's not really finding the socket file. so I would like to know what exactly is the filename + path it's trying to use [19:02] strace hmm [19:11] anpok, thanks for the strace tip. good one [19:12] anpok, so the problem seem indeed server side: http://paste.ubuntu.com/12330409/ [19:12] anpok, what do you make of this exception? [19:13] hm try fingerpaint? [19:13] it's like client process ended suddenly or something [19:13] * dandrader tries [19:14] anpok, ah, interesting. it gives more output [19:15] anpok, http://paste.ubuntu.com/12330431/ [19:15] anpok, seems I'm missing some package :) [19:16] I do have a /usr/lib/x86_64-linux-gnu/mir/client-platform/mesa.so.2 [19:17] which seems to come from a local build of mir 0.14... [19:17] * dandrader installs mir-client-platform-mesa3 [19:19] great! now it finally works! [19:19] anpok, thanks for the help! === dandrader is now known as dandrader|afk === ahayzen_ is now known as ahayzen === dandrader|afk is now known as dandrader === ahayzen_ is now known as ahayzen [23:04] tedg: Right. The bits that are needed are kms (modesetting), EGL-on-KMS (Mir rendering), and EGL hooks (client rendering).