Merge lp://staging/~thomir-deactivatedaccount/python-ubuntu-platform-api/add-mir-pkg into lp://staging/python-ubuntu-platform-api
| Status: | Merged |
|---|---|
| Merged at revision: | 14 |
| Proposed branch: | lp://staging/~thomir-deactivatedaccount/python-ubuntu-platform-api/add-mir-pkg |
| Merge into: | lp://staging/python-ubuntu-platform-api |
| Diff against target: |
749 lines (+402/-302) 5 files modified
setup.py (+28/-13) upa/__init__.py (+42/-0) upa/_mir.cpp (+45/-0) upa/_sf.cpp (+287/-0) upa/upamodule.cpp (+0/-289) |
| To merge this branch: | bzr merge lp://staging/~thomir-deactivatedaccount/python-ubuntu-platform-api/add-mir-pkg |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| python-upa-team | Pending | ||
|
Review via email:
|
|||
Commit message
Merge in changes to make upa module work under mir as well as under SF.
Description of the change
Merge in changes to make upa module work under mir as well as under SF.
Notes:
1) This currently segfaults if you try and get the resolution while running mir. Someone from the mir team needs to look into this. To reproduce in a single command:
python -c "import upa; upa.get_
If you're running surface flinger, that works perfectly. Under mir, we get this back trace:
#0 0x40518830 in mir_connection_
from /usr/lib/
#1 0x404aa344 in ua_ui_display_
from /usr/lib/
#2 0x40020970 in py_get_resolution (dummy=<optimized out>,
args=<optimized out>) at upa/upamodule.
#3 0x000dfe7e in PyEval_EvalFrameEx ()
#4 0x0011221e in PyEval_EvalCode ()
#5 0x0011778e in ?? ()
#6 0x0011778e in ?? ()
2) This merge does not expose the session lifecycle calls at all, but they're not used in autopilot, since we're still waiting for the proper shell application manager calls.
3) We need a more stable way of detecting whether we're running mir or surface flinger than looking for a file on disk... probably.
| Robert Ancell (robert-ancell) wrote | # |
This is likely to break in the future:
102 +def _get_correct_
103 + if exists(
104 + import _mir
Each shell will use a different socket in the $XDG_RUNTIME_DIR. A safer check is to see if $MIR_SOCKET is defined (though the shell might currently not define that either).
I'd recommend at least a big comment on why this is a temporary solution or check for the environment variable and optionally the socket.