[05:37] n === duflu_ is now known as duflu === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === fginther` is now known as fginther === chihchun is now known as chihchun_afk [15:59] ...and one more time [15:59] desrt: hey, curious, we've been talking about disallowing reparenting of surfaces/windows...someone pointed out that gtk permits this [15:59] desrt: just wondering, is this really used ? or do you know of examples ? [16:10] Qt's API could allow reparenting support, but I don't see it used much at all, probably can live without it [16:11] https://qt-project.org/doc/qt-5/qwindow.html#setTransientParent [16:15] kdub: examples/testdraw/android_graphics_region_factory.cpp uses mir/graphics/android/native_buffer.h (which got privatized with the secrecy drive). Do you think reasonable clients might want access to this header? [16:17] no, I don't think so [16:17] there might be a reason in the future, but for the moment, it can stay hidden [16:18] * alan_g decides that testdraw/android_graphics_region_factory.cpp needs fixing [16:20] yeah, needs some update, its a very old file === dandrader is now known as dandrader|lunch [16:23] Morning! [16:23] Good morning even [16:27] kdub: is reworking graphic_region_from_handle() a quick thing for you? (I'm not sure of the right approach - its all unfamiliar) [16:29] alan_g, rework how? (i'm guessing it depends on some header that's inconvenient) [16:29] It uses NatriveBuffer from mir/graphics/android/native_buffer.h [16:29] NativeBuffer even [16:32] hmm, I think I see a way to get rid of it [16:32] hopefully won't take long [16:33] kdub: it is not currently worth spending long on - but would help clean up. [16:35] alright [16:35] I'll let you know if I've given up :) [16:38] hi, i'm having trouble running mir from trunk [16:38] i keep getting a File already exists in database: mir_protobuf_wire.proto warning [16:40] attente_: could that be bug 1391976 [16:40] bug 1391976 in Mir "Loading libmircommon.so twice leads to a segfault in protobuf code" [High,New] https://launchpad.net/bugs/1391976 [16:40] ? [16:40] Which executable are you using? Which platform? [16:41] alan_g: yeah, it sounds like it. i'm just trying to run a unity8 session against mir trunk [16:43] attente_: you've built U8 against your build of Mir? There are ABI breaks [16:44] alan_g: i have as well as u-s-c, but i get a different exception [16:44] alan_g: Warning: ignoring unrecognised arguments: --vt 8 [16:45] Ignoring things isn't an exception [16:45] alan_g: http://paste.ubuntu.com/9058242/ [16:45] sorry, i didn't want to paste in the channel [16:46] "std::exception::what: Could not open hardware module" - not running as root? Already running a USC instance? [16:47] alan_g: just trying to run it from lightdm [16:47] as a desktop session [16:50] We're still talking USC? [16:53] the session is lightdm-unity8-session [16:58] You pasted an exception "std::exception::what: Could not open hardware module" - that was from USC? I'm guessing it wasn't run as a privileged user? [16:58] alan_g: i'm not sure, that paste is from the /var/log/u-s-c.log though [17:01] attente_: on x86 with mesa drivers? [17:02] anpok: amd64 with mesa drivers [17:03] then why does it load the android drivers [17:03] anpok: no idea [17:04] anpok: i don't have either of the android platform driver packages installed [17:06] anpok: argh. thanks, apparently i had the libmirplatform4driver installed [17:07] you need at least the -mesa one .. [17:19] does MirDisplayOutput provides the subpixel order of that output in some way? [17:22] Trevinho: Not yet! Looks like there is subpixel info in DRM since feb though. [17:22] feburary [17:22] racarr: cool, thanks [17:23] Thank you :) === dandrader|lunch is now known as dandrader| === dandrader| is now known as dandrader === alan_g is now known as alan_g|EOD === tedg` is now known as tedg [20:40] * kdub goes cross-eyed trying to think of the proper nested abstraction [21:02] i'm becoming convinced that nested and offscreen [21:02] are just different display modes [21:02] not really platforms of the same par as android/mesa/etc [21:18] kdub: Sounds like display mode/platform is onto something [21:19] maybe the offending noun is platform right [21:19] so broad.... [21:19] yeah, but its okay when used with mesa and android imho [21:19] because those can provide all thats needed [21:20] mm I guess I just mean contrasting against it is hard. [21:20] like its hard to say what is a display mode and what is a platform [21:20] because [21:20] platform is so vague [21:20] sure [21:21] I'm favoring just having the display server override the display creation for our two 'interesting' modes (offscreen and nested) [21:21] and also telling the platforms if they're the one server instance to rule them all when we create the platform [21:22] because there's also some confusion in our libplatform C functions about that [21:22] which, has a massive negative diff :) and makes it less confusing when some other driver comes along [21:22] such as llvm [21:23] I guess we'll see what it looks like once I get through tgetting things to compile [21:23] mm [21:23] seems like a promising path :) === greyback__ is now known as greyback [22:29] robert_ancell: hey, curious... i tried to ask ryan this earlier, not sure if he's out or something [22:30] but, we were talking about reparenting surfaces/windows [22:30] and i heard gtk supports it, but is it really employed ? [22:31] kgunn, when we discussed it with RAOF Ryan said he'd look at putting a warning into GTK+ to discourage apps from doing it. We couldn't think of a reason why they would need to [22:31] it's been something we didn't want to support, but if there's cases etc [22:31] ah...ok [22:31] I think it's mostly just a hangover from X [22:31] yeah, i was just curious if we were being draconian [22:33] robert_ancell: thanks...and good to know you guys expected it as well [22:38] kgunn, http://irclogs.ubuntu.com/2014/11/05/%23ubuntu-desktop.html#t23:55 [22:38] found it [22:38] ta [22:39] https://bugzilla.gnome.org/show_bug.cgi?id=739697 [22:39] Gnome bug 739697 in .General "GTK should warn when reparenting a shown window" [Normal,Unconfirmed]