[04:55] <tepper3> ls
[05:00] <duflu> ls: No file or directory
[05:00] <RAOF> Oooh, hosed system.
[05:00] <RAOF> No ls?
[05:01] <duflu> ls: Deprecated. Use a Mir shell instead.
[05:02] <duflu> RAOF: Apparently Mesa 12 adds 'support' for GBM_FORMAT_XBGR8888. But using it results in backward colours still. I suspect nobody actually tested the new feature yet...?
[05:02] <RAOF> Plausible?
[05:03] <RAOF> I'd expect it to be associated with a piglit test, though.
[05:03] <RAOF> (They're pretty easy to write, if you care ☺)
[05:04] <duflu> Never saw a test committed with the upstream change. But they say they added GBM_FORMAT_XBGR8888 for Android (where it is OpenGL's type RGBA in big endian). I'd be surprised if nobody else tested/fixed it yet
[05:04] <duflu> I mean Android's RGBX type, which is big endian
[05:05] <duflu> I used to have a manual test for it with mir-demos. I should dig that up
[05:08] <tepper3> oh sorry :> i'm using irssi and mistaked the term tab
[05:14] <RAOF> duflu: Piglit is in an entirely different repository; you wouldn't see any tests unless you were following it.
[05:14] <duflu> Oh. I thought it was odd previously tests were committed separately
[05:16] <RAOF> https://cgit.freedesktop.org/piglit/ is probably where tests would go.
[05:25] <duflu> I need to check it's not our fault still
[08:11] <duflu> alan_g: We don't have any report that simply logs what pixel format a surface is created as do we?
[08:11] <duflu> I keep needing such a thing
[08:12] <duflu> Hmm, or client report would do
[08:13] <alan_g> duflu: I can't claim to know it all, but I doubt it is currently reported. We probably just report the surface name.
[08:13] <duflu> I can't remember which report that is either
[08:14] <duflu> But I think if I want the format of a specific client it should be a client report
[08:18] <alan_g> I'd guess --scene-report has the surface create event and could add such detail, but we've never got around to adding much (optional) detail to any of the reports
[08:24] <RAOF> We should write a logging Mir proxy.
[08:25] <RAOF> Thanks to Protobuf being self-describing it'd actually be pretty easy, and would trivially log *everything*.
[08:25] <RAOF> Lovely for debugging.
[08:25] <duflu> #define if ...
[08:25] <duflu> #define while ...
[08:25] <RAOF> (Except, of course, for input events and anything else that comes over that socket, because yay)
[08:26] <RAOF> Bah.
[08:27] <RAOF> I really, really, wish things stuck in a std::function<> didn't need to be CopyConstructible.
[09:00] <anpok> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4543.pdf
[09:06] <RAOF> anpok: Of *course* there's an N document resolving that :P
[09:06] <RAOF> anpok: Although, to be honest, std::packaged_task would work fine for me were it not for the tiny problem of I'm doing this because std::future's use of TLS makes hybris have a sad.
[09:07] <anpok> ah yes
[09:26] <alan_g> duflu: I know there are other options to play with, but is this a plausible starting point for using Xmir? https://code.launchpad.net/~alan-griffiths/miral/script-testrun-with-xmir/+merge/300866
[09:28] <duflu> alan_g: That's the correct minimal syntax, yes, with two caveats:   (1) The default renderer on desktop is dri2 which is less reliable so sometimes try -sw.  (2) The -rootless option is not yet used by Unity8 but we hope to in future
[09:30] <duflu> alan_g: Oh two more caveats...
[09:31]  * alan_g wonders...
[09:31] <duflu> alan_g: (3) Our dbus settings are broken and will hang GTK apps. Use export DBUS_SESSION_BUS_ADDRESS=none or such to stop it hanging. (4) gnome-terminal is broken (and only gnome-terminal). So try something else like gedit
[09:33] <duflu> But maybe those problems are only in yakkety
[09:33] <duflu> At least only (1) of four caveats is an Xmir bug
[09:35] <alan_g> duflu: I've already got gnome-terminal "working" with the gtk-mir backend, just aiming to provide some support for other X apps.
[09:36] <duflu> alan_g: Well it used to work perfectly. Something in yakkety broke it.
[09:36] <duflu> yakkety is in flux
[09:37] <alan_g> Luckily for me I can still work on xenial & vivid+overlay
[09:37] <duflu> alan_g: You might actually want to run pure native X apps to avoid all the GTK/dbus problems.... like 'xterm', 'bitmap'
[09:40] <alan_g> ack. For the moment I'm mostly wanting to document a test context for "where in the stack does it go wrong" questions.
[09:42] <alan_g> It's hardly good support as (for example) Alt+F4 kills Xmir not the client
[09:42] <duflu> alan_g: Actually that sends the close signal to the current window, just the current window
[09:42] <duflu> in mir_proving_server anyway
[09:44] <alan_g> This is miral-shell which currently does that for Ctrl+F4 and does SIGTERM with Alt+F4.
[09:48] <duflu> alan_g: I think it's meant to be close current window everywhere else in the world :)
[09:49] <duflu> alf_ What do I win?....
[09:49] <duflu> [09:49] <duflu>                                   glmark2 Score: 4
[09:49] <duflu> [09:51] <duflu> alan_g: Really common combos like that which exist in other operating systems too I think are best kept
[09:52] <alan_g> I agree: that;s why "the shortcut key combination for closing the active Window is Ctrl + F4."
[09:52] <duflu> alan_g: Isn't it Alt+F4 elsewhere?
[09:53] <duflu> Ctrl+F4 doesn't exist in Unity7. Maybe in Windows?
[09:54] <alan_g> I'm sure I use it in Unity7, but it can easily be app specific.
[09:55] <duflu> Doesn't seem to do anything here
[09:55] <alan_g> Mostly it came from demo_server with demo_clients
[09:56] <alan_g> Trouble is there's a lot of "standards" in this area. I'll dig a bit.
[09:56] <alan_g> You may well be right.
[09:56] <duflu> alan_g: Well, check what the common defaults are in various window managers (not apps), and Windows, and OSX
[09:59] <alan_g> duflu: https://en.wikipedia.org/wiki/Alt_key#Alt_key_combinations supports your case
[10:00] <duflu> Maybe that's the only truly common window manager combo. The app equivalent is Ctrl+W
[10:00] <duflu> which may or may not be implemented in an app
[10:00] <duflu> Anyway, time to cook dinner since my callgrind graph is so uninteresting
[10:18] <alf_> tvoss: Hi! Could you please take a look at https://bugs.launchpad.net/platform-api/+bug/1602604
[13:35] <alan_g> greyback: how's qt compositing on MirAL going?
[13:35] <greyback> alan_g: am assembling some MPs for you now
[13:36] <alan_g> Nice!
[16:27] <alan_g> greyback: all your MPs belong to trunk
[16:29] <greyback> alan_g: thanks. I've bigger chunks to come, probably tomorrow
[16:30] <alan_g> ack. Are you looking to review any of mine?
[16:31] <greyback> I will now