[00:06] tvoss_: https://code.launchpad.net/~rsalveti/mir/fixing-libhybris-dependencies/+merge/178863 [00:12] RAOF, do you know about mlankhorst's changed in -staging? [00:12] robert_ancell: I do not. [00:12] * RAOF checks [00:12] RAOF, so he overwrote -0ubuntu9 for some reason. But others have said his changes fix a crash [00:13] I did tell him about your bug, and he seemed to have an idea of what was happening. [00:13] So not sure why they don't just go directly to main? [00:13] rsalveti, speaking of our libhybris dependency :) [00:14] RAOF, I was looking at the Mir patch by the way. I notice it unloads drivers if they don't work with Mir, but doesn't check if the driver count is 0 afterwards. My logs do show three drivers being unloaded [00:14] we keep hwcomposer.h in-tree... if libhybris maintained hwcomposer.h (like it does with gralloc.h), it would help mir's dependency situation [00:14] just a 'wishlist' though [00:15] kdub: sure, mind opening a bug against the libhybris package? [00:15] sure [00:15] also, if someone can help me understand such failures: https://code.launchpad.net/~rsalveti/mir/fixing-libhybris-dependencies/+merge/178863 [00:15] any idea why we don't have an armhf jenkins build job as well? [00:15] just building for i386 and amd64 [00:16] or is it trying to cross build for armhf? [00:17] rsalveti, yep [00:17] right, then we might need some other changes as well... [00:17] -- Could NOT find LIBHARDWARE (missing: LIBHARDWARE_LIBRARY) [00:17] when cross building [00:18] package wasn't even installed [00:18] there's a script in the top level directory (+ ./cross-compile-chroot.sh) that the builder is executing [00:18] you can change the script if need be, but really its probably an issue of getting cmake to sort things out correctly [00:19] right, it's only installing libhybris and libhybris-dev [00:19] not necessarily all the dependencies [00:19] let me check the script [00:19] https://jenkins.qa.ubuntu.com/job/mir-saucy-amd64-ci/462/console also failed [00:20] but seems related with the test results [00:20] not related with my change [00:20] kdub, does https://code.launchpad.net/~rsalveti/mir/fixing-libhybris-dependencies/+merge/178863 make sense? [00:20] you shouldn't build-dep on libhybris-egl [00:20] that's provided by mesa [00:21] and you just need to install libhybris during runtime, as that will replace mesa's egl [00:21] right, we shouldnt care at buildtime whether its the hybris or mesa [00:22] rsalveti, did you want a specific review from tvoss_ instead of just the mir team? [00:22] no, just added him there because he asked me to === michi__ is now known as michi [00:23] ok, kdubs review should be sufficient to land === michi is now known as Guest35414 [00:25] kdub: ok, changed the cross build script, will wait to see if that helps [00:26] rsalveti, i reviewed with a +1, conditional on getting it past the builder [00:27] kdub: any idea why it failed for amd64 though? [00:28] rsalveti, no, that is a strange failure :/ [00:31] robert_ancell: not that you needed another data point....but using staging xorg worked for me (+mir from main, +usc from daily-build) [00:32] RAOF, any update on that patch from mlankhorst? [00:32] robert_ancell: I'm hunting it down; it doesn't seem like he pushed that to git. [00:38] Ah, there it is. [00:40] RAOF: quick one...what did "mesa dependent on some radeon kernel patches" mean ? or how does it relate ? [00:44] kgunn: To be proper, the radeon mesa module needs to know the size of the buffer its importing; for dma-buf there's currently no way to get that, so I made a kernel patch. [00:45] kdub, rsalveti, so it looks like those memcheck failures are happening elsewhere https://jenkins.qa.ubuntu.com/job/mir-saucy-amd64-ci/463/console [00:45] kgunn: We're doing sufficiently simple things that this shouldn't be a problem, but for upstream acceptance the general case is important :) [00:49] robert_ancell: yeah, they are not related with packaging changes for arm :-) [00:50] hmm [01:15] Ah. *There* we go. This laptop *does* have fans. [01:32] robert_ancell: New Xserver tested, fixes your bug, and uploaded. [01:32] RAOF, nice! [01:33] And with that, I think I'm no longer firefighing? [01:33] Maybe I can get some actual feature work done! [01:33] duflu: Good morning! [01:33] RAOF: Morning! [01:33] * duflu reserves judgement over good, for a while [01:34] Heh. How's Perth travelling? [01:34] RAOF: It's basically spring. Been very warm lately [01:35] RAOF: Laptop in action yet? [01:35] It is indeed. [01:37] duflu, can I get you to re-review https://code.launchpad.net/~robert-ancell/mir/alt-ctrl-backspace/+merge/178036? [01:37] robert_ancell: Yes, can it wait for me to plough through email etc first? [01:37] duflu, sure [01:41] duflu: I'd still like to line up a bypass discussion at some point, too :) [01:42] RAOF: I know. But I have significant "switch" issues to address first. It won't go away :/ [01:42] duflu: ok. [01:42] There's plenty of xrandr to do :) [01:42] RAOF: So don't expect today [02:07] RAOF: did you like your new laptop? thinking about getting a similar one in a month [02:08] rsalveti: It's pretty nice. [02:09] It's particularly nice to have the system76 guys in the community - I'm half-way through setting up secure boot on this machine thanks to an out-of-band firmware update I got because I mentioned that I wanted to securebootify it. [02:09] OK, I have now broken my VTs. Can't switch to any [02:09] RAOF: yeah, that's nice, cool [02:10] most reviews are saying good things about it as well, looking forward to move from my thinkpad t400 :-) [02:10] 4 years old already [02:10] It's pleasantly light, and reasonably constructed. [02:10] nice [02:11] RAOF: running xmir on it already? [02:11] It's not quite at the build quality of my old x200s, but it's a cut above the old asus I had. [02:11] rsalveti: Not right at the moment; I like my VTs :) [02:11] RAOF: haha, right :-) [02:12] It's easier to test in mir_demo_server_shell, anyway. [02:12] You don't have to blow away your existing session to test there :) [02:12] right, indeed [02:13] The laptop is also nice and quiet. Idle I don't think the fans are on at all, and under moderate load they pick up to fairly quiet. [02:15] awesome [02:15] can't wait to get one as well [02:18] Has anyone else noticed Mir servers crash when new clients start? Seems to be a new regression on trunk landing last night [02:18] * duflu is trying to trace the problem without breaking his machines [02:21] Rolling back to yesterday's branches work at least [02:54] Dear lord. Why doesn't bzr ship with bzr-pager? [02:55] RAOF: hmm, never heard of it. What does it do? [02:55] smspillaz: Pipes everything bzr outputs through a pager. [02:55] oh, I guess it automatically pipes to less [02:55] ie: git's default mode. [02:55] heh [02:55] This is one of the rare cases where git's default is substantially saner than bzr's. [02:56] RAOF: I dunno, I think the git branching model is saner than having to muck around with lightweight checkouts :) [02:56] though I was very happy when I found out about lightweight checkouts [02:56] unfortunately it was only after I had run out of disk space N times already [02:57] I don't bother with lightweight checkouts. A repository works fine. [02:57] RAOF: repository? [02:57] Now, *this* is something bzr does terribly. [02:57] bzr init-repo .; will turn the current directory into a repository. [02:58] RAOF: I don't see how that's different from bzr branch' default behaviour [02:58] Anything you branch into that directory will share the repository. [02:58] So you've got one copy of history + n-checkouts. [02:58] If your checkouts are what's pushing you over the space size, you've got problems :) [02:59] RAOF: I used to always do bzr branch lp:foo foo.whatever and then have a million foo.* drs [03:00] *dirs [03:00] each with their own build/ [03:00] Yeah, jml wrote a plugin to identify and remove those branches which had been merged. [03:00] when you consider that a unity build got to about 3GB, it got big quick [03:00] RAOF: yeah, I never was able to find that, but I have heard that such a thing existed [03:01] in any case, git's behaviour in that area is much *much* nicer :) [03:02] lp:bzr-removable [03:02] * duflu has wacky graphics corruption and can't see what he's typing. brb [03:02] Woot! [03:04] duflu: you do a much better job at spelling correctly when you can't see what you're typing than me :) [03:04] * smspillaz could never see what he was typing whenever using irssiconnectbot or whatever on android, hence all the spelling mistakes generally [03:10] smspillaz: Well, that time I was looking at the keyboard [03:10] heh [03:10] RAOF, I still have the X lockup, investigating more here [03:10] It seems a Mir (heap corruption?) bug hit me in the middle of libgbm, which then corrupted X too [03:10] Huh. It fixed it here, damnit! [03:10] RAOF, I didn't think you'd reproduced it had you? [03:10] robert_ancell: You've got 0ubuntu9, from the archive? [03:10] RAOF, yes [03:11] robert_ancell: I managed to reproduce it on my hybrid system. [03:16] RAOF, what was the cause for you? [03:16] Spinning in deletedriver, because radeon was marked for deletion but wasn't getting deleted [03:17] Back for the night shift [03:21] robert_ancell: Not sure if you want to wait for someone to do a proper fix, but this is rather critical... https://code.launchpad.net/~vanvugt/mir/revert-r931/+merge/178877 [03:22] duflu, I'm looking at it now. We should revert if it's causing problems. [03:22] duflu, can you note in the bug what you're doing to confirm it? [03:22] I assume this is mir_demo_server and mir_demo_client_*? [03:23] Huh. I tested that commit with mir_demo_server_shell and xmir. [03:23] Presumably I should also have done so with a native Mir client :) [03:24] robert_ancell: Yes, I added a comment [03:24] It would be nice to figure out how that got past all automated testing... [03:28] Ok, I can reproduce the crash with mir_demo_client_eglplasma. [03:28] duflu, did the whole video system lock up when testing the client? [03:29] robert_ancell: It killed the Mir server, which does turn off the display. You need to switch to X to restore the state correctly (Ctrl+Alt+F7) [03:30] robert_ancell: There's a separate bug for that :) [03:30] * RAOF +1s the revert, then heads to lunch. [03:31] duflu, I'll just confirm your branch fixes it, then +1 from me too [03:36] argh. Stupid cmake [03:36] duflu, don't block on me [03:37] robert_ancell: I will. I already blocked the morning for this :S [03:39] Damn. I'm involved in too many reviews again [03:48] RAOF - https://code.launchpad.net/~mir-team/mir/expose-debug-buffer-id-to-client/+merge/176843 would break ABI/API [03:52] robert_ancell: I will defer testing ctrl+alt+backspace till the regression is fixed. So I can test properly === chihchun_afk is now known as chihchun [04:01] rsalveti, have some associated packaging changes broken android builds? https://jenkins.qa.ubuntu.com/job/mir-android-saucy-i386-build/1622/console [04:07] duflu, hoping that android build failure is going to disappear? [04:18] RAOF, is there a reason you compact the driver list on deletion? [04:21] robert_ancell: Yes hoping one way or the other [04:26] good morning :) [04:27] RAOF, ah, so turned out I had the -0ubuntu9 from yesterday. The new -0ubuntu9 from main does fix the problem for me [04:30] bbl [04:41] HELLO [04:41] I want to know what's the equivalent of a window manager (in the X world) with mir? is it the compositor? [04:42] the thing that draws the window borders, offers special effects, etc. [04:45] sam113101: It's the "shell". And as yet there is no shell that does any window management really. But we're slowly building a demo in examples/demo-shell/. And later it will be done in the Unity8 project's shell. [04:45] All you can do with demo-shell is Alt-Tab and move windows around (Alt+drag or three fingers) [04:45] * duflu goes to lunch [04:56] I don't know what's a shell, it's kind of confusing (at least to me) [05:13] sam113101: Yes. The compositor is the equivalent of a window manager; same as wayland. [05:14] RAOF: what's a shell, then? [05:14] sam113101: Think "desktop environment". [05:14] sam113101: It's the bit of the compositor that is the desktop environment. [05:16] good morning again :) [05:17] Heeelo. [05:18] the shell is part of the compositor? [05:18] Yes [05:18] duflu, I think we have to land https://code.launchpad.net/~rsalveti/mir/fixing-libhybris-dependencies/+merge/178863 first to fix the android build errors [05:18] you're sure it's not the opposite? [05:19] sam113101, the shell *is* a compositor [05:19] Is a display server. [05:19] there's no special component called a compositor. There can be a number of compositors [05:20] Everything is rolled into one - display server, compositor, shell, window manager. [05:24] RAOF: Does X/XRandR handle rotation internally? That is, for XMir does Mir need to provide some kind of rotation option when configuring the display? [05:25] It would be better if it did; let me check. [05:25] robert_ancell: there can be multiple compositors? [05:26] sam113101, yes, in the Ubuntu case we have Unity Shell as one compositor and Unity System Compositor switching between shells [05:27] alf__: I'd be better to handle it in Mir, but it's currently handled in the drivers. [05:28] alf__: So if it's hard for Mir to expose that, XMir can do that work. [05:29] is there a mir server a compositor talks to or is the compositor the server itself? [05:30] sam113101: like wayland compositors, the clients connect to it directly [05:30] sam113101: The compositor is the server itself. Everything is in the one place; display server, compositor, shell, window manager. [05:30] Just like wayland. [05:32] sam113101: I think you're used to the X/Compiz/WM way of doing (and naming) things. Mir is more like Gnome Shell, Windows or OSX in that the whole UI (shell) is one thing. And that thing does composition, window management, etc. [05:32] yeah I'm used to the old scenario [05:32] RAOF: For now (due to time constraints), I'd rather if XMir handled it, if it is something that is ready. [05:33] RAOF: What would X require from Mir in terms of rotation? === jono is now known as Guest5052 [05:34] so there are only two things, a compositor (which uses the mir library) and clients (which also use the mir library to talk to the compositor), is that right? [05:35] alf__: Ideally it would take the buffer from XMir and rotate it during the composition phase based on what XMir asked. [05:35] alf__: I was thinking about that. Rotation requires (1) Screen transformation, (2) Cursor transformation, (3) surface resize support as width becomes height etc [05:35] alf__: So XMir could set RotateClockwise90 on it's 1920x1080 window, and Mir would take the 1920x1080 buffer and rotate it through 90 degrees when compositing to the framebuffer [05:36] ... in other words, Mir is not ready for that. Let XMir do it :) [05:38] I suspect (3) resize support is the major blocker. That's probably quite non-trivial [05:38] duflu: RAOF: right, at the same time the contents need to be transformed accordingly, e.g., X needs to know that this is now a 1080x1920 surface and draw accordingly, so XMir should be involved at some point? [05:38] I think I'm going to write my own compositor some day, if I ever get knowledgeable enough [05:38] sam113101: We aim to provide examples that help people to do that. Just need time to make the examples more interesting [05:39] alright [05:39] sam113101: You could start now by copying examples/demo-shell/ but the API is likely to change somewhat still [05:40] RAOF, ping [05:40] tvoss_: Pong [05:41] alf__: No, X wants it to be a 1920x1080 surface always. [05:42] RAOF: But in terms of content drawing it will treat it as a 1080x1920 surface, right? [05:45] I think the answer to that is "no" [05:45] But I need to trace further [05:46] RAOF: in any case... we need to find out what more, if anything, XMir needs from Mir to support screen rotation [05:47] Yes [05:48] RAOF: I would imagine that since XRandR uses KMS normally, that it can handle everything internally, and that Mir (for now) can just replace the functionality that KMS provides [05:48] RAOF: so no rotations/transformations [05:48] Yeah. [06:01] Ugg. My audio settings are broken again. Need to reboot to hangout [06:03] thomi: psychedelic ! [06:03] kgunn: I know, but watch this! [06:05] robert_ancell: weekly ? [06:06] kgunn, yes... === tvoss_ is now known as tvoss|flaky_wire === tvoss|flaky_wire is now known as tvoss|test [06:34] ugh, hangout is broken all of a sudden [06:35] hmm, can't log back in [06:37] hmmm, unity-system-compositor does not compile for me, failing with /usr/include/mirserver/mir/default_server_configuration.h:23:40: fatal error: mir/options/program_option.h: No such file or directory [06:37] #include "mir/options/program_option.h" [06:39] looking into my include files, that include file is indeed missing [06:41] thomi, :( [06:42] thomi, it's coming up to your turn [06:48] tvoss|test: I confirm: https://launchpadlibrarian.net/146957401/buildlog_ubuntu-saucy-amd64.unity-system-compositor_0.0.1%2B13.10.20130807-0ubuntu1_FAILEDTOBUILD.txt.gz [06:49] robert_ancell, ^ [06:49] I am too tired to talk constructively about surface-configuration-interface/client-focus I think [06:49] tvoss|test, hrm. Looks like someone changed the API [06:50] racarr, :( Get some sleep! [06:50] but would appreciate if people could try and think about them, and say...not tomorrow, but the next morning [06:50] I will make it an extra early morning day and can sync up with everyone [06:50] robert_ancell: Looking at your branch... I think I have a less intrusive way to do this (e.g. not needing to set the server explicitly) [06:50] :) [06:50] robert_ancell: i'll let you decide ultimately....but if you're sway-able...i'd say update ppa asap since we;re still struggling ^ [06:50] robert_ancell, it's not even that, the include file mentioned in default_server_configuration does not exist anymore [06:50] alf__, ok, please propose an alternative. We just need to get something landed [06:50] robert_ancell: ok [06:51] robert_ancell: My pleasure :D [06:51] kgunn, Do you think being unable to VT switch is a blocker? [06:51] I'm otherwise happy to update [06:51] robert_ancell: not a blocker imho [06:51] ok, will do [06:51] just a bug :) [06:51] and I'll point the complaints to you :) [06:52] certainly [06:52] * kgunn goes to bed [06:53] tvoss|test: another day without u-s-c to distro I think :/ [06:53] alf__, I'm about to EOD - lp:~robert-ancell/mir/vt-switch-keys is the VT switching branch (not working). If you want to fix/change that feel free [06:55] robert_ancell: Do we want both quit and vt to live only in examples? Will u-s-c do its own thing separately? [06:55] RAOF, can you upload the recent X to the staging PPA so I can copy it to the s-c-t PPA? [06:55] robert_ancell: Is there any particular... oh, yeah. Pinning. [06:55] alf__, the VT switching is in DefaultServerConfiguration, the alt+ctrl+backspace just in DemoServerConfiguration [06:55] RAOF, yep [06:56] robert_ancell: ok [06:56] Oh, I think it'll be rejected because it's not newer than the archive? [06:56] Let's find out! [06:56] alf__, I think that makes sense. It was kind of yuck to have the VT switching code separate from the GBM code, but I couldn't think of a way around it [06:56] RAOF, because of the obsolete -0ubuntu9? [06:57] robert_ancell: Yeah. [06:57] Other option is to delete the X server in s-c-t? [06:57] Then it'll drop out of pinning and they'll get the archive version. [06:57] RAOF, yeah, that might work [06:59] RAOF, we can drop xserver-xorg-video-* as well right? [06:59] robert_ancell: Yes [06:59] and libdrm and mesa? [06:59] robert_ancell, RAOF announcing that by mail might be a good idea. How can we test before removing it? [06:59] Yes. [07:02] alf__: Oh, another thing that Mir doesn't provide on the monitor-configuration front? Names for the outputs. [07:02] alf__: There's no way to distinguish between HDMI-1 and VGA-1 and… [07:09] alf__: It doesn't need to be a string; you could also send an enum. But we do need some way to tell. [07:16] RAOF: ok [07:21] RAOF/alf__: I too vote for names/numbers/anything. [07:22] Hmm, no wonder X is always confused. Xrandr says VGA is active even when the monitor is physically turned off [07:22] duflu: RAOF: sure, probably both an enum with the type VGA/HDMI etc, and a unique name [07:23] alf__: Also, in the absence of GUI's it would be awesome to be able to say "VGA1 rightof DVI1 align top" or similar [07:24] alf__: I'd be happy to do such a text interface providing arbitrary placement is functional [07:24] But obviously we have higher priorities right now... [07:28] kgunn: tvoss|test: FYI, I disable u-s-c tests and run for now [07:29] kgunn: tvoss|test: apparently, nobody is working on debugging it, and that's what which is screwing the -ati machine everyday [07:29] Another option which doesn't even need names is to have special key combos which move the current monitor (with the cursor) relative to others [07:29] kgunn: tvoss|test: like nothing else is running after that when starting the session, I think the ati driver state isn't right then and we have to reboot it [07:30] jibel: FYI ^ let's do that [07:31] Mirv: so don't bother with mirslaves for now, as per ^ [07:32] good to have a least a start of explanation why we got the -ati machine screwed everyday [07:34] didrocks: yeah I didn't already because you told me so on Monday [07:37] duflu: The DDC pins provide power for the EDID firmware; it's not possible to distinguish between an unpowered monitor connected to a VGA port and a fully armed and operation monitor plugged in to a VGA port. [07:38] RAOF: OK, makes sense if your OS handles multi-monitor more reliably than this one :/ [07:39] But it will be super-psychic-always-right in Mir :) [07:39] Not really. It never really makes sense. [07:39] Fortunately, you *can* tell if a DisplayPort monitor is turned off, and it's also possible to detect some HDMI (but I'm not sure whether we do at the moment) [07:40] So once everyone's thrown away their current hardware this problem will go away! [07:40] RAOF: Hmm, I will need a system with multiple digital outs and at least one new monitor first [07:41] Wait, no. Just the former. [07:55] good morning === tvoss|test is now known as tvoss|flaky === seb128_ is now known as seb128 [08:03] alan_g, ping [08:03] tvoss|flaky: ? [08:04] alan_g, good morning. your recent refactoring to the platform stuff breaks compiling unity-system-compositor as the options-headers are not installed [08:05] tvoss|flaky: https://code.launchpad.net/~robert-ancell/mir/mirplatform/+merge/178895 [08:07] alan_g, does not pass CI due to the install directory directive not being correct [08:07] alan_g, do you have cycles available to take care of landing it? [08:08] tvoss|flaky: will do [08:08] alan_g, thx [08:32] tvoss_: https://code.launchpad.net/~alan-griffiths/mir/mirplatform-install-headers/+merge/178909 [08:41] alf__: any chance of a quick top-approve for https://code.launchpad.net/~alan-griffiths/mir/mirplatform-install-headers/+merge/178909 [08:43] alan_g: looking [08:51] alan_g: are the headers included in some package? [08:53] alf__: Good point [09:31] tvoss_: https://code.launchpad.net/~alan-griffiths/mir/mirplatform-install-headers/+merge/178909 [09:37] alf__: Oh, and could we also grab the EDID? [09:39] RAOF: I guess so, why do you need it? [09:39] Clients sometimes care about it. [09:40] You can grab useful information from it, like the name of the display etc. [09:43] Oh, and subpixel layout; likewise, clients can use it. [09:43] RAOF: how does xrandr get edid now? Does KMS provide it, or does it grab it from /sys? [09:43] kms provides it. [09:43] RAOF: can you point me to the function? [09:44] alan_g, looking [09:45] RAOF: is it a "property blob"? [09:45] alf__: extern drmModePropertyBlobPtr drmModeGetPropertyBlob(int fd, uint32_t blob_id); with blob_id ==... yeah [09:45] You need to grab the properties, iterate over them finding which one has name == "EDID", and then that's the blob to get. [09:45] RAOF: thanks [09:46] RAOF: ok, so to sum up: subpixel, edid, unique name [09:47] These are the things I've hit so far, yes :) [09:47] I think they cover the main bases. [09:50] alan_g, building mir now, and usc subsequently [09:50] katie, ping [09:50] tvoss_, ping pong [09:50] tvoss_: thanks [10:05] alf__: Whoops! subpixel, edid, type/name, *and* the number of independent outputs that can be driven. [10:06] RAOF: ok [10:06] RAOF: How blocking are these? Any preference about order of implementation? [10:07] I don't think any are totally blocking. count_crtcs would be my first preference, then EDID, then type/name, then subpixel. [10:09] Of those, if we shipped without subpixel it wouldn't be terrible. We *could* ship without EDID, it just makes my life easier. The type & count_crtcs are absolutely mandatory. [10:12] RAOF: we will ship with all, mostly caring if any of these is blocking you in the short term [10:12] duflu: FYI, https://code.launchpad.net/~afrantzis/mir/gbm-alloc-validate-buffer-format/+merge/178928 [10:12] alf__: Yeah saw it [10:45] Hah! alf__ - is the modes array sorted at all? If not, is there a way of getting the output's preferred mode? [11:00] tvoss_: does it work for you? [11:00] alan_g, still compiling. had some hiccups as I have libhybris installed [11:11] alan_g, compilation works fine here [11:11] alan_g, approved :) alf__ would you mind taking a second look and top-approving? [11:11] tvoss_: great. [11:11] alan_g, I haven't tried usc, though [11:13] tvoss_: but it builds? [11:13] alan_g, ack [11:13] good enough for me [11:27] RAOF: The modes are as KMS gives them back, so sorted from higher to lower resolutions. I haven't come across a situation where the preferred mode is not the first (but of course I haven't had the chance to try with a lot of outputs) [11:28] tvoss_: which MP is that? [11:28] alf__, https://code.launchpad.net/~alan-griffiths/mir/mirplatform-install-headers/+merge/178909 [11:29] tvoss_: alan_g: top approved [11:34] alf__, \o/ [11:36] alf__: Probably time to add preferred-mode to that to the list, then ☺ (or, at least, ensure preferred mode is the first in the array). I'm pretty sure CRTs will have a highest-resolution mode that's non-preferred. [11:37] RAOF: ok [11:38] RAOF: the list grows :) but thankfully all are simple additions [11:38] And now, sleep. === alan_g is now known as alan_g|lunch [12:28] alf__: hey, could I maybe add this bug to your list of things to do: https://bugs.launchpad.net/mir/+bug/1209216 - or please comment if I'm not using the API correctly [12:28] Launchpad bug 1209216 in Mir "Snapshot of non-fullscreen surface returns a fullscreen pixmap with white padding" [Undecided,New] [12:29] greyback: will take a look [12:30] didrocks, ping [12:30] tvoss_: pong [12:30] alf__: if you'd like more info in that bug, do say. It is very textual :) [12:30] greyback: could you point me to the code where the code is used [12:30] ? [12:31] didrocks, staging has got a new version of mir that has got all the headers installed [12:31] didrocks, tested locally, can build usc against it [12:32] alf__: http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/view/head:/src/modules/Unity/ApplicationManager/applicationscreenshotprovider.cpp#L46 [12:32] tvoss_: ok, let me retry manually then, hoping that it won't screw up the ati machine again [12:32] first, building mir [12:32] didrocks, ack [12:35] greyback: I can't think a way for Mir to be getting this wrong (not that it's not possible0. Could the non-fullscreen surface be really implemented as a fullscreen surface with transparency on the top? [12:35] alf__: hmm, that's a possibility. Let me look [12:43] tvoss_: cmake isn't available on all archs yet, it will take a little bit more time for armhf [12:43] didrocks, cmake as in? sorry, ENOCONTEXT :) [12:44] tvoss_: cmake made Mir FTBFS (a new upload, arch mismatchs) [12:44] I'll retry Mir once cmake is published on armhf [12:44] didrocks, okay [12:45] greyback: btw, in the code I see that you are mirroring the image. Note, that I am mirroring too internally when transforming from texture (bottom-up) to byte data (top-down). Perhaps we can avoid both mirrorings. [12:46] alf__: yes that would make sense === alan_g|lunch is now known as alan_g [12:52] alf__: you are correct, it appears every qtubuntu surface is actually fullscreen. It is using platform-api to move & resize the surface, but those a stubs. Qt itself I believe is drawing the white padding === greyback is now known as greyback|lunch [13:23] didrocks, shouldn't happen anymore with the loosened dependency [13:24] doko: yeah, I hope so :) just retried armhf === greyback|lunch is now known as greyback [13:49] didrocks, ping [13:49] alf__, alan_g what is the review status on duflu's switch branch? [13:50] tvoss: I started looking at it a couple of days ago. Then it went to WIP. I see it is now back again. [13:50] tvoss: pong [13:51] tvoss: It is a LOT of change to get one's head around and validate. [13:59] alan_g, I know, it still fixes the lag issue, though [14:00] tvoss: alan_g: I haven't validated every line (nor I plan to), but it seems to work reasonably well last I checked. It effectively triple-buffers all the time, though, and what concerns me is that attempts to enforce double-buffering haven't been successful yet, which may indicate a more fundamental algorithmic issue. I am OK with getting this in without the enforced double-buffering, but we need to fix it soon, if only to prove that it is doa [14:02] alf__, ack [14:14] didrocks: ping [14:14] kgunn: pong [14:14] didrocks: hey read the scrollback...checked mails, so it seems the ati machine is the last hurdle ? [14:15] kgunn: hum, ati and intel [14:15] kgunn: the other issues isn't confirmed to be fixed AFAIK [14:15] (like no GL) [14:15] the additional input is that we have confirmation that it's that failing state which makes the ati machine irresponsive then [14:15] and we have to electrically reboot it [14:17] didrocks: i apologize for my questioning...just trying to help :)...but "other issues isn't comfirmed to be fixed" you are referring to intel xorg seq fault ? [14:18] kgunn: right, it was intel/ati (the symptoms looked the same), was that worked on? I didn't see any change on the bug I referred [14:19] didrocks: for sure intel "has a fix"....me, tvoss, bschafer all verified a fix [14:20]