[06:58] <duflu> RAOF: Why doesn't MirSurfaceOutputEvent just give you an output to query with the output API? Are you reserving the right to virtualize the output (if it represents multiple physical outputs)?
[06:59] <RAOF> duflu: I was actually going to add the MirOutput to it, but it turned out to be unnecessary.
[06:59] <RAOF> (And kinda annoying to do)
[06:59] <RAOF> It already contains the display ID, and you can look up the MirOutput by the id.
[07:02] <duflu> RAOF: Maybe but I find myself adding new fields
[07:02] <duflu> And it seems I shouldn't have to
[07:02] <duflu> So I'm wondering if jumping to just MirOutput makes sense. Although the caller then has to annoyingly query current mode etc
[07:02] <duflu> Actually we've already had this conversation. I now remember arguing for the status quo... as heterogeneous attributes of multiple monitors a surface is on should be massaged into a summary (which is not a single physical output)
[07:02] <duflu> So maybe the current API is more future proof
[07:02] <duflu> Just has more functions
[07:03] <RAOF> duflu: If the fields are already exposed by MirOutput then they're unnecessary.
[07:03] <RAOF> The client can look up the MirOutput itself.
[07:04] <duflu> RAOF: That's true but similar to other parts of the client API, common use cases shouldn't be so complicated as requiring multiple function calls...
[07:05] <duflu> I think we can do better but won't rush into adding more functions either
[07:05] <duflu> There's no clear winner
[07:05] <RAOF> As I said, I was going to add a MirOutput* accessor.
[07:05] <RAOF> But (a) it doesn't make the API any more powerful, just more convenient, and (b) it was a bastard to try and plumb througgh.
[07:06] <duflu> Agreed. And you lose the power to summarise multiple heterogeneous physical outputs in a single result
[07:06] <RAOF> No, that's already gone.
[07:06] <duflu> Only if you query the ID :)
[07:07] <RAOF> Right, but if a client *does* query the ID we need to give them sensible results.
[07:07] <duflu> Yep
[07:07] <duflu> OK, current API stands
[07:07] <RAOF> If we want to provide them with enough information to handle “you're on two different outputs” then we should just give them both the outputs.
[07:08] <RAOF> (Plus an API for binding RenderSurfaces to output, so they can render their content twice and we display it appropriately)
[07:09] <duflu> I'm ignoring that last part. Discussed it multiple times before and each time concluded it hurts toolkit compatibility too much to ask each frame get rendered multiple times
[07:09] <RAOF> We'd only do it if a toolkit asked us for it.
[07:10] <RAOF> (Plus, we control the relevant toolkits, so we'd basically only do it if *we* wanted it done)
[07:10] <duflu> Target audience too small to worry right now
[07:10] <duflu> Although on that subject... intel where is my 10-bit support?!
[09:08] <alan_g> greyback: once we can land my current two MPs I think we should start thinking of a miral-0.2 release. What do you think?
[09:11] <greyback> alan_g: sure. It has what we need in there
[09:43] <alan_g> greyback: your comment suggests you're happy, your vote suggests you're not - which is it? https://code.launchpad.net/~alan-griffiths/miral/rework-handling-of-surface-state-changes/+merge/307163
[09:45] <greyback> ah it was not a question, you did it
[09:45] <alan_g> thanks
[11:34] <alan_g> greyback: does this look right to you? https://code.launchpad.net/~alan-griffiths/miral/changelog-for-0.2.0/+merge/307295
[11:38] <greyback> alan_g: those are the main enhancements anyway. I'll trust you collated all the bugs
[12:01] <om26er> Hi! is there a way I can run mirout without proving the MIR_SOCKET var ?
[12:22] <om26er> greyback, Hey! yesterday you were saying that if a client requires a display server under Mir session it has MIR_SOCKET env variable available. Does that mean python script wont be able to access that variable ?
[12:34] <bregma> om26er, if the environment variable is available there is no reason a Python script can't get at it
[12:34] <om26er> bregma, its not a global variable apparently
[12:34] <bregma> there is no such thingv
[12:35] <bregma> vogons, is there a command-line too that connects to the Mir server ^^?
[12:36] <kdub> argv[1] of mirout accepts socket file
[12:36] <alf_> bregma: how do you mean? We can mirping that connects,pings, and disconnect?
[12:41] <bregma> om26er, there's a good answer for you:  the mirping tool from the mir-utils package
[12:42] <bregma> after all, it;s not enough to check check that an environment variable is set
[12:42] <om26er> bregma, will test mirping as my phone boots.
[12:43] <om26er> kdub, alf_ I need to query screen resolutions sans xrandr with mirout, the problem is the location of the socket is not consistent in different environments. Is there a way to find the MIR_SOCKET ?
[12:44] <kdub> I'm not sure how that gets set up, I thought something in upstart set the env variable
[12:51] <alf_> om26er: I think that for unity8 the socket is always XDG_RUNTIME_DIR/mir_socket
[12:51] <alf_> om26er: What kind of inconsistencies have you found?
[12:55] <om26er> alf_, $XDG_RUNTIME_DIR/mir_socket does exit reliable but it does not work with mirout. on touch devices mirout works with /tmp/mir_socket
[12:56] <om26er> and seems on unity8 desktop that path is different, something under the banner of lightdm
[13:03] <om26er> also is it normal message: Could not connect to a display server: Failed to send message to server: Success
[13:03] <om26er> success as in ?
[13:04] <om26er> (that's result of mirping)
[13:05] <bregma> that doesn't sound useful
[13:06] <kdub> success! we didn't crash
[13:07] <bregma> generally speaking if mirout doesn't connect to the server and get the right information, using something else that isn;t a part of Mir is not going to work any better
[13:07] <bregma> mirout should know how to connect to the server i the absolute correct way
[13:07] <om26er> MIR_SOCKET=/run/mir_socket mirping <-- that command gives "Could not create a surface."
[13:07] <om26er> so that does sound like its working ?
[13:08] <om26er> but the thing is... How do I dynamically find that mir_socket path :)
[13:08] <kdub> that's probably a policy denial from u8
[13:08] <kdub> and bregma it should know how to connect to the server, but it still has to know which server to connect to
[13:08] <kdub> and... that error message is very confusing
[13:09] <bregma> I would suggest trying to second-guess the mir server configuration is not going to bring a satisfactory level of success
[13:12] <bregma> om26er, exactly what is your goal?
[13:13] <om26er> bregma, I need to check which display server is running (X or Mir), then talk to their relevant utilities (xrandr or mirout) to query screen resolutions.
[13:14] <om26er> this is needed for autopilot. I want a concrete solution not something on guesswork.
[13:16] <bregma> you're looking for ways to get your solution to work, but you're not describing what it's a solution to so we're not going to give you useful answers
[13:16] <bregma> that's why I'm asking what your goal is, not your solution
[13:17] <om26er> bregma, the goal is to make autopilot input code ready for convergence.
[13:18] <bregma> OK, but that's a little vague...  what problem are you trying to solve that involves the Mir server?
[13:20] <bregma> are you trying to run autopilot tests in a pristine environment without all the session setup that goes into a Touch or Ubuntu session?
[13:20] <bregma> under what circumstances will these tests be running, and how is the Mir server being run?
[13:21] <om26er> autopilot currently saves hard coded screen resolutions for many touch devices, its not scalable as we add more and more devices. We want dynamically determine the device resolution.
[13:21] <bregma> what device?  when is the test run and under what circumstances?
[13:22] <om26er> this is important because we have code that relies on display resolutions along with windows geometry to determine if that window is visible on a given screen.
[13:22] <om26er> bregma, Unity8 desktop for example, where different people have different screen resolutions on their laptops.
[13:22] <om26er> current autopilot assumes that if you are on a desktop you are running X11, we need to change that.
[13:23] <bregma> om26er, so this is for tests that will be run from a logged-in Unity 8 session?
[13:23] <bregma> or does it need to run elsewhere?
[13:23] <om26er> bregma, unity8 desktop and/or our current touch devices.
[13:23] <om26er> maybe in kvm as well
[13:24]  * alan_g muses: "the server" isn't always meaningful. Just now I happen to have two X servers and two Mir servers running onscreen. Which is "the server"?
[13:25] <bregma> if you are in a Unity 8 session, then MIR_SOCKET is the environment variable that contains the address of the Mir socket.  It doesn;t make any difference what device you're running Unity 8 on.
[13:26] <bregma> you can't just up and connect to the Unity 8 Mir server, however, because it accepts only authorized connections.
[13:26] <om26er> bregma, only that $MIR_SOCKET is not in the environment :/
[13:26] <bregma> Unity 8 in Mir is not X11
[13:26] <bregma> om26er, if MIR_SOCKET is not in the environment, then you have a borked installation
[13:27] <bregma> if you do not have MIR_SOCKET set, you;re not in a Unity 8 environment
[13:27] <bregma> well, not a valid oner
[13:27] <om26er> I tested on krillin and arale.
[13:27] <bregma> how did you test?
[13:29] <om26er> echo $MIR_SOCKET
[13:29] <om26er> also `env` does not list it
[13:30] <bregma> so, you opened a Terminal App instance and typed those commands?
[13:30] <om26er> what about just `pidof unity8` ? if its running we are in Mir, what you say.
[13:30] <om26er> bregma, ssh'd
[13:31] <bregma> om26er, you're not in a Unity 8 environment if you ssh in
[13:31] <bregma> try this: tr '\0' '\n' </proc/$(pidof unity8)/environ | grep MIR_SOCKET
[13:31] <bregma> alan_g, greyback, HO?
[13:32] <om26er> bregma, hmm, that does give UNITY_MIR_SOCKET that points to /run/mir_socket
[13:32] <bregma> om26er, you will notice if you ssh in to any machine you do not have an X11 environment either, unless you use -X to tunnel your local server over the ssh socket
[13:33] <om26er> bregma, is that the same for adb shell ?
[13:34] <bregma> om26er, yes, that's the nature of Unix logins
[13:36] <bregma> om26er, the Unity 8 mir server belongs to a particular login session, unlike X11 in which it runs as root and can be accessed by anyone
[13:37] <bregma> there is a system-level Mir compositor also, but you're not allowed to connect to that, for obvious security reasons
[13:38] <bregma> that said, I've successfully used the above tr command to bring up Mir-based applications through ssh on my Unity 8 desktop
[13:41] <bregma> but Unity 8 only accepts authorized connections, it's not promiscuous like X11
[13:47] <bregma> om26er, it looks like there have been some changes in the unity8.conf file (the upstart script that invokes Unity 8) and MIR_SOCKET does not show up in the unity8 process environment any more
[13:48] <bregma> it does get expoerted to Unity 8 clients, however
[13:48] <bregma> this still works reliably: tr '\0' '\n' </proc/$(pidof unity8-dash)/environ | grep MIR
[13:48] <bregma> sorry, that should be grep MIR_SOCKET
[13:51] <bregma> $ eval $(tr '\0' '\n' </proc/$(pidof unity8-dash)/environ | grep MIR_SOCKET) mirout
[13:51] <bregma> Could not connect to a display server: Failed to connect: not accepted by server
[13:51] <bregma> so, Unity8 still rejects the connection attempt because it's not authorized...  need to wrap that in a .desktop file.....
[13:53] <bregma> hey vogons, did we not provide a D-Bus interface that can be used to query the display config of a Mir server?
[13:53] <anpok_> there is only UnityScreen
[13:53] <kdub> mir doesnt do dbus
[13:53] <alan_g> bregma: Mir doesn't know about dbus
[13:53] <anpok_> provided by usc
[13:53] <bregma> I know we did discuss it last December
[13:54] <bregma> well, it sounds like we have another topic for discussion at the upcoming sprint
[14:03] <TheKit> why there is no arm64 in Mir PPAs?
[14:04] <anpok_> there should be
[14:05] <TheKit> https://launchpad.net/~mir-team/+archive/ubuntu/staging - only amd64, armhf and i386
[14:05] <TheKit> is it somewhere else?
[14:06] <anpok_> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay .. there you get the released mir versions
[14:06] <anpok_> with arm64..
[14:07] <anpok_> not sure why the staging ppa does not include arm64
[14:07] <anpok_> oh reminds me that I have to fix usc
[14:11] <bregma> just togled arm64 in that PPA
[14:11] <bregma> it's just that no one went in and manually did that after the functionality was made available in Launchpad
[14:12] <bregma> the staging PPA isn't really a part of the Mir development workflow so it did not go amiss
[14:27] <TheKit> thanks
[14:30] <bregma> TheKit, thank you for bringing it to our attention