| === hikiko_ is now known as hikiko | ||
| 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:58 |
|---|---|---|
| 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. | 06:59 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| RAOF | (Plus an API for binding RenderSurfaces to output, so they can render their content twice and we display it appropriately) | 07:08 |
| 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:09 |
| 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?! | 07:10 |
| 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:08 |
| greyback | alan_g: sure. It has what we need in there | 09:11 |
| 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:43 |
| greyback | ah it was not a question, you did it | 09:45 |
| alan_g | thanks | 09:45 |
| === hikiko is now known as hikiko|ln | ||
| === dandrader is now known as dandrader|afk | ||
| alan_g | greyback: does this look right to you? https://code.launchpad.net/~alan-griffiths/miral/changelog-for-0.2.0/+merge/307295 | 11:34 |
| greyback | alan_g: those are the main enhancements anyway. I'll trust you collated all the bugs | 11:38 |
| === hikiko|ln is now known as hikiko | ||
| om26er | Hi! is there a way I can run mirout without proving the MIR_SOCKET var ? | 12:01 |
| 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:22 |
| 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:34 |
| bregma | vogons, is there a command-line too that connects to the Mir server ^^? | 12:35 |
| === dandrader|afk is now known as dandrader | ||
| 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:36 |
| bregma | om26er, there's a good answer for you: the mirping tool from the mir-utils package | 12:41 |
| bregma | after all, it;s not enough to check check that an environment variable is set | 12:42 |
| === marcusto_ is now known as marcustomlinson_ | ||
| om26er | bregma, will test mirping as my phone boots. | 12:42 |
| 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:43 |
| kdub | I'm not sure how that gets set up, I thought something in upstart set the env variable | 12:44 |
| 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:51 |
| 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:55 |
| om26er | and seems on unity8 desktop that path is different, something under the banner of lightdm | 12:56 |
| 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:03 |
| om26er | (that's result of mirping) | 13:04 |
| bregma | that doesn't sound useful | 13:05 |
| kdub | success! we didn't crash | 13:06 |
| 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:07 |
| 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:08 |
| bregma | I would suggest trying to second-guess the mir server configuration is not going to bring a satisfactory level of success | 13:09 |
| bregma | om26er, exactly what is your goal? | 13:12 |
| 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:13 |
| om26er | this is needed for autopilot. I want a concrete solution not something on guesswork. | 13:14 |
| 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:16 |
| om26er | bregma, the goal is to make autopilot input code ready for convergence. | 13:17 |
| bregma | OK, but that's a little vague... what problem are you trying to solve that involves the Mir server? | 13:18 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| * 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:24 | |
| 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:25 |
| 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:26 |
| 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:27 |
| om26er | echo $MIR_SOCKET | 13:29 |
| om26er | also `env` does not list it | 13:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| om26er | bregma, is that the same for adb shell ? | 13:33 |
| bregma | om26er, yes, that's the nature of Unix logins | 13:34 |
| 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:36 |
| bregma | there is a system-level Mir compositor also, but you're not allowed to connect to that, for obvious security reasons | 13:37 |
| 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:38 |
| bregma | but Unity 8 only accepts authorized connections, it's not promiscuous like X11 | 13:41 |
| 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:47 |
| 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:48 |
| 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:51 |
| 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:53 |
| bregma | well, it sounds like we have another topic for discussion at the upcoming sprint | 13:54 |
| TheKit | why there is no arm64 in Mir PPAs? | 14:03 |
| anpok_ | there should be | 14:04 |
| TheKit | https://launchpad.net/~mir-team/+archive/ubuntu/staging - only amd64, armhf and i386 | 14:05 |
| TheKit | is it somewhere else? | 14:05 |
| 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:06 |
| anpok_ | not sure why the staging ppa does not include arm64 | 14:07 |
| anpok_ | oh reminds me that I have to fix usc | 14:07 |
| 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:11 |
| bregma | the staging PPA isn't really a part of the Mir development workflow so it did not go amiss | 14:12 |
| TheKit | thanks | 14:27 |
| bregma | TheKit, thank you for bringing it to our attention | 14:30 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === michael is now known as Guest71043 | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!