| === chihchun_afk is now known as chihchun | ||
| === ara is now known as Guest67693 | ||
| === chihchun is now known as chihchun_afk | ||
| greyback_ | hey folks, does unity8 as a nested server have the ability to change the display configuration of the system server? I know the client API allows that, but has a nested server access to that somehow? | 12:16 |
|---|---|---|
| kdub | greyback_, it looks like mg::Display::configure() is plumbed up | 12:19 |
| greyback_ | kdub: ok cool, just wanted to make sure | 12:20 |
| greyback_ | thanks | 12:20 |
| kdub | greyback_, np | 12:20 |
| === marcusto_ is now known as marcustomlinson | ||
| === chihchun_afk is now known as chihchun | ||
| greyback_ | @vogons were there ever discussions on privileged mir clients? How to allow a system settings app or a screenshot tool, without giving those abilities to the world | 13:11 |
| kdub | sure, for the systems settings, we have some interfaces that apply policy to when the display gets configured | 13:15 |
| kdub | that we hazily? thought a security-concerned shell would mediate | 13:15 |
| greyback_ | sure, it's more the how to mediate. Who knows what client can do what | 13:17 |
| kdub | and with screenshotting, there's src/server/frontend/unauthorized_screencast.cpp | 13:17 |
| kdub | well, I guess mir wouldn't know which particular client is authorized | 13:18 |
| anpok_ | greyback_: I always thought those scenarios are handled by asking the shell whether a given session is allowed to do things..? | 13:26 |
| greyback_ | anpok_: sure, but how does the shell know to give permission or not | 13:26 |
| greyback_ | I know mir gives a shell the ability to reject such things. I'm asking if you ever thought how a shell would know to make those decisions | 13:27 |
| kdub | greyback_, doesnt this have to be an ubuntu policy? | 13:27 |
| kdub | like, some sort of permissions system involving other system components | 13:28 |
| anpok_ | hum by asking trust store? | 13:28 |
| greyback_ | kdub: yes | 13:29 |
| anpok_ | or is that for different use cases? | 13:29 |
| greyback_ | dbus has appArmor to impose permissions | 13:30 |
| greyback_ | if appArmor had an API for shell to see what permissions a client has, then that might be enough | 13:30 |
| kdub | greyback_, right, iirc, we give the pid of the client that is connecting from the kernel as the secure way the shell can know that the client that it has launched is actually the one that connects over the mir protocol | 13:32 |
| kdub | and that pid+dbus/apparmor/etc+ the overrides for mf::DisplayChanger and mf::Screencast are the levers involved | 13:34 |
| Chipaca | i get http://pastebin.ubuntu.com/11877784/ on the demo server when trying to connect, what am i doing wrong? | 13:50 |
| * tedg listens | 13:51 | |
| greyback_ | Chipaca: I just ran demo server & a demo mir client, all ok. What are the commands you're running? | 13:59 |
| tedg | greyback_, We're trying to get a QML snap working | 14:00 |
| tedg | greyback_, So we have a bit more convoluted setup | 14:00 |
| tedg | greyback_, I guess our question is more about "how do we figure out what is happening" more than "you have an issue" | 14:00 |
| tedg | We're probably broken here :-) | 14:00 |
| greyback_ | tedg: from the log, you trying to run a mir server and it is failing | 14:01 |
| greyback_ | looking at hte code, it is trying to read a message from the socket, but that is failing. Is it able to create the socket at all? | 14:03 |
| greyback_ | default socket /tmp/mir_socket | 14:03 |
| tedg | Here is the client side: http://pastebin.ubuntu.com/11877751/ | 14:04 |
| tedg | It's saying that the connection to the server failed. | 14:04 |
| greyback_ | can define MIR_SERVER_HOST_SOCKET=/something to tell mir a custom socket | 14:04 |
| greyback_ | tedg: is the server running tho? | 14:05 |
| tedg | I think the default snap is using /run/mir_socket | 14:05 |
| greyback_ | why would an application snap bring up a mir server? | 14:05 |
| tedg | No, the mir snap | 14:05 |
| greyback_ | shouldn't a snap framework be providing that? | 14:05 |
| greyback_ | ah ok | 14:05 |
| tedg | So Chipaca shut that down so he could easily start/restart it | 14:06 |
| tedg | But trying to keep things the same. | 14:06 |
| greyback_ | tedg: default mir socket is /tmp/mir_socket here | 14:06 |
| tedg | Huh, looking at the strace it looks like we might be closing the socket earlier? | 14:08 |
| tedg | I think that it's FD 4, and we're closing it at line 27 | 14:09 |
| tedg | greyback_, What is /usr/lib/x86_64-linux-gnu/mir/client-platform ? | 14:10 |
| tedg | It looks like we're reading that directory, but then not opening anything in it. | 14:11 |
| greyback_ | tedg: used by mir clients, I don't think a mir server needs that | 14:12 |
| tedg | greyback_, Yeah, I think the client might be failing in this case. | 14:12 |
| greyback_ | tedg: so the server is working? | 14:14 |
| greyback_ | your original paste suggests it isn't | 14:14 |
| tedg | greyback_, It works in the sense that it runs without error :-) | 14:14 |
| tedg | Oh, that may have been a mistake then. | 14:15 |
| greyback_ | tedg: you on desktop? Can you see a mouse pointer and move it? | 14:15 |
| tedg | greyback_, I don't have this setup, I've been working with Chipaca to debug his setup. We might have to wait for him to get back for that question. | 14:17 |
| Chipaca | greyback_: tedg: am back | 14:57 |
| tedg | Chipaca, Cool, so I want to get setup with what you have. | 14:59 |
| Chipaca | greyback_: the server works in the sense that i get a cursor and can move it around | 14:59 |
| Chipaca | tedg: ok, let me push the files. meanwhile you get snapcraft :) | 14:59 |
| Chipaca | or, hey, i'll make it a branch | 14:59 |
| Chipaca | 1 sec :) | 14:59 |
| Chipaca | tedg: lp:~chipaca/snapcraft/simpleqml | 15:00 |
| Chipaca | tedg: and i'll pastebin the other bits | 15:01 |
| Chipaca | tedg: http://pastebin.ubuntu.com/11878101/ | 15:03 |
| Chipaca | tedg: and http://pastebin.ubuntu.com/11878104/ on the device | 15:03 |
| === chihchun is now known as chihchun_afk | ||
| greyback_ | Chipaca: ok, but that socket error the server reports still worries me. If the mir socket not correct, then clients will be unable to connect | 15:03 |
| conyoo | :'( | 15:07 |
| conyoo | when/after using mirscreencast the keyboard stops working unity shell (wily) | 15:08 |
| conyoo | ~faild to mmap buffer | 15:08 |
| greyback_ | conyoo: could you try it with "-m /run/lightdm-mir-0" | 15:10 |
| greyback_ | may need to run as root too | 15:10 |
| conyoo | that's what i'm doing :P i get the same error with or without root | 15:13 |
| conyoo | let me copy the full error text (from tty to irssi in terminal app) | 15:14 |
| conyoo | MirBufferStreamAPI: Cought exception at client library boundary (in mir_buffer_stream_get_graphics_region): etc | 15:17 |
| conyoo | this is silly :D where can i find the log | 15:17 |
| conyoo | where is this error logged? it has a time stamp [14312312.123123 <ERROR>MirBufferStreamAPI ... etc | 15:19 |
| greyback_ | conyoo: you're talking to unity-system-compositor, so if anything printed will be in /var/log/lightdm/unity-system-compositor.log | 15:20 |
| === dandrader is now known as dandrader|afk | ||
| === conyoo_ is now known as conyoo | ||
| seb128 | when is the new mir supposed to land in wily? | 15:39 |
| seb128 | the one in silo 004 | 15:39 |
| seb128 | kgunn, ^ do you know? | 15:40 |
| kgunn | seb128: soon, it's being tested today | 15:40 |
| kgunn | seb128: what's up? blocking you? | 15:41 |
| seb128 | kgunn, it's blocking the gtk-mir backend update which includes quite some good fixes and improvements from attente | 15:44 |
| kgunn | seb128: ok, i was just telling the guys we do need to test this thoroughly, but we will land as soon as we feel good about it | 15:45 |
| seb128 | good, thanks | 15:45 |
| camako | seb128, kgunn, testing looks good so far. Just a couple of USC features yet to be tested, then we'll greenlight it. | 15:53 |
| camako | anpok ^ | 15:53 |
| seb128 | camako, thanks | 15:55 |
| Chipaca | greyback_: ok, i got the demo client to connect (not sure it's doing anything, but it connected) | 15:55 |
| Chipaca | greyback_: mir_demo_client_cursors just draws a weird (glitchy?) static box | 15:56 |
| Chipaca | and my actual cursor is gone | 15:56 |
| greyback_ | Chipaca: sounds about right, that demo tests custom cursors. egltriangle a little less confusing | 15:56 |
| Chipaca | ah, eglcounter shows a counter | 15:56 |
| Chipaca | works | 15:56 |
| Chipaca | tedg: ^ | 15:56 |
| Chipaca | mvo: and your patched xkbcommon is what allows that to work :) | 15:57 |
| Chipaca | next step, see why qt isn't working :) | 15:57 |
| Chipaca | tedg: have you been able to reproduce this? | 15:58 |
| tedg | Chipaca, Getting there. | 15:58 |
| tedg | Not yet | 15:58 |
| * Chipaca bbiab | 16:00 | |
| === dandrader|afk is now known as dandrader | ||
| mvo | Chipaca: yaaaaay! | 16:04 |
| tedg | Is there a key combination that'll cause the Mir demo server to shutdown? | 16:12 |
| tedg | Ctrl+Alt+Backspace, yes! | 16:12 |
| racarr | Morning! | 16:21 |
| Chipaca | mvo: not there yet though :) | 16:39 |
| Chipaca | oh, that's interesting | 17:14 |
| Chipaca | tedg: if I manually start a demo client from the mir snap, e.g., | 17:15 |
| Chipaca | MIR_SOCKET=/run/mir_socket LC_ALL=C XKB_CONFIG_ROOT=./xkbcommon/data/ LD_LIBRARY_PATH=$PWD/xkbcommon:/apps/mir/snap1/debs/usr/lib/x86_64-linux-gnu/:/apps/mir/snap1/debs/usr/lib/x86_64-linux-gnu/mesa-egl/ /apps/mir/snap1/debs/usr/bin/mir_demo_client_eglcounter | 17:15 |
| Chipaca | tedg: it works | 17:15 |
| Chipaca | tedg: but if instead i point to the qml apps' libs, with everything else staying the same, it fails to connect: | 17:16 |
| Chipaca | $ MIR_SOCKET=/run/mir_socket LC_ALL=C XKB_CONFIG_ROOT=./xkbcommon/data/ LD_LIBRARY_PATH=$PWD/xkbcommon:/apps/qmlapp.sideload/0/usr/lib/x86_64-linux-gnu/:/apps/qmlapp.sideload/0/usr/lib/x86_64-linux-gnu/mesa-egl/ /apps/mir/snap1/debs/usr/bin/mir_demo_client_eglcounter | 17:16 |
| Chipaca | Can't get connection | 17:16 |
| Chipaca | tedg: so my current working hypothesis is that I should go and make dinner | 17:17 |
| dandrader | a client get a mir resize event of, say (100,100). but as it keeps swapping buffers it never ever reaches a buffer of that size. is it possible? | 17:51 |
| dandrader | I mean, is a mir client ensured to eventually find a buffer matching the size of the last surface resize event it received? | 17:52 |
| anpok_ | yes | 17:53 |
| anpok_ | or yes I see that behavior on wily | 17:53 |
| anpok_ | and was debugging it | 17:53 |
| anpok_ | wait .. here is a trace.. http://paste.ubuntu.com/11877355/ | 17:57 |
| dandrader | anpok_, you also debugging https://bugs.launchpad.net/qtubuntu/+bug/1473720 ? | 18:00 |
| ubot5 | Ubuntu bug 1473720 in qtubuntu "keyboard stops working, maliit and unity8 consuming cpu" [High,In progress] | 18:00 |
| anpok_ | dandrader: the first resize and the buffer matches.. but since there is a new size it needs to redraw to the destination size 399,524.. meanwhile the user keeps resizing and again the exchanged buffer has a new size.. | 18:00 |
| anpok_ | the redraw seems to block the event loop.. so thread 1 seems be always waiting for something in qtcore or qtquick... | 18:01 |
| anpok_ | when I manage to get back to the original expected destination size 399,524 (in the trace above) .. it stops requesting a redraw and mirevents are processed again | 18:01 |
| dandrader | anpok_, so you mean that unity8 did sent all the mir-surface-resize events but the client just didn't process them all for some reason? | 18:02 |
| anpok_ | i believe so.. but not sure.. I manage to bypass the problem by blocking the render thread in the right places.. | 18:02 |
| anpok_ | noticed that while testing 0.14.0 on desktop | 18:03 |
| anpok_ | oh keyboard going away is a resize.. | 18:10 |
| anpok_ | so this on the phone too | 18:10 |
| dandrader | anpok_, the only way it could happen is if QWindowSystemInterfacePrivate::handleWindowSystemEvent is synchonous | 18:10 |
| dandrader | anpok_, no the keyboard going away animation is not done by resize | 18:11 |
| dandrader | anpok_, the resize happens then unity8 hides or shows the indicators bar at the top | 18:11 |
| anpok_ | yes.. the default impl says async.. but hmm thats the next thing to look into.. | 18:11 |
| anpok_ | ah | 18:11 |
| dandrader | anpok_, as unity8 makes the input method surface match the screen size - the top bar size | 18:11 |
| anpok_ | maybe the render thread is just faster in releasing the lock and looking for new stuff | 18:12 |
| anpok_ | and locks again | 18:12 |
| dandrader | anpok_, has a higher priority or something... | 18:12 |
| dandrader | anpok_, that's interesting. I'll play around with some algorithms after lunch | 18:14 |
| dandrader | anpok_, to solve that impasse | 18:14 |
| === dandrader is now known as dandrader|lunch | ||
| kgunn | pcoca: are you trying on an amd64 arch ? | 18:49 |
| pcoca | yes | 18:49 |
| pcoca | amd64 VM | 18:49 |
| pcoca | building the snaps on 15.04 | 18:49 |
| pcoca | and when I install (--allow-unauthenticated) I don't get the display | 18:50 |
| kgunn | pcoca: ah...you know what, i had a problem to working with the phablet-tools on vivid....I think they have diverged to the point | 18:50 |
| kgunn | where the wily phablet-tools are no longer kosher on vivid | 18:50 |
| kgunn | i updated my machine here to wily and everything magically worked | 18:51 |
| pcoca | OK, I will rebuild the snaps on 15.10 then and give it a try :) | 18:51 |
| pcoca | thanks kgunn | 18:51 |
| kgunn | pcoca: can you afford to work on wily? it would be a good second data point to prove that theory (e.g. phablet-tools for wily need to run on wily) | 18:51 |
| pcoca | i'm building the snaps on another VM | 18:52 |
| pcoca | so I will delete 15.04 VM and build everything from scratch on 15.10 | 18:53 |
| greyback__ | dandrader|lunch: with shell rotation landed, I see no reason why the OSK surface needs to resize at all. It could be fullscreen all the time. | 18:59 |
| === dandrader_ is now known as dandrader | ||
| dandrader | greyback__, yeah, I was about to investigate why we were resizing it in the first place. but I think you got the reason | 19:16 |
| greyback__ | yep. Still this resize bug is nasty | 19:16 |
| dandrader | greyback__, yes, will fix it first | 19:17 |
| greyback__ | thanks | 19:17 |
| kgunn | pcoca: ok, let me know your results, very interested | 19:26 |
| racarr | https://twitter.com/xlibfunctions | 20:05 |
| racarr | XkbGetMods(3): returns the moderators of the X11 mailing list, but ensures they are real and not virtual (unlike XkbGetVirtualMods(3)). | 20:05 |
| racarr | lol | 20:05 |
| kgunn | racarr: those are pretty funny | 20:13 |
| dandrader_ | anpok_, think I got a fix for this bug | 20:14 |
| dandrader_ | anpok_, and it's great as it essentially just deletes code :) | 20:14 |
| anpok_ | yay | 20:15 |
| anpok_ | is it the weird orientation change guess? | 20:15 |
| dandrader_ | anpok_, since there's no synchronicity whatsoever between the processing of mir-resize-events and the consumption of buffers (buffer swapping) as they happen in different threads and and sent through different IPC channels, I just have to loose things up | 20:16 |
| dandrader_ | s/and and sent/and are sent | 20:16 |
| dandrader_ | anpok_, ie, when I get a resize event I just trigger a "please redraw" event to qt and that's it] | 20:17 |
| dandrader_ | anpok_, instead of redrawing until the buffer size match the size advertised by the last mir-resize-event that got consumed. | 20:17 |
| dandrader_ | just have to do some more testing to be sure | 20:19 |
| === dandrader_ is now known as dandrader | ||
| anpok_ | ok .. so the important thing for mir would be that it never skips a resize event | 20:20 |
| dandrader | anpok_, and I think it doesn't | 20:20 |
| dandrader | anpok_, but it can easily happen in a resize animation that by the time the main thread reads a resize event that info is already outdated (ie, the render thread is already past that size) | 20:21 |
| dandrader | anpok_, so the actual size information in a resize event is kinda useless | 20:22 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| greyback__ | dandrader: fix looks reasonable, but haven't tested it yet. Will do so tomorrow morning | 21:29 |
| dandrader | greyback__, tested on my laptop and on mako. works nicely | 21:29 |
| greyback__ | dandrader: there a big rush? Should I try now? | 21:30 |
| dandrader | greyback__, you should be offline doing whatever you do after work :) | 21:30 |
| dandrader | it sure can wait till tomorrow | 21:31 |
| greyback__ | dandrader: someone has to cover the hole that Saviq left us with ;) | 21:31 |
| * Saviq not here | 21:32 | |
| dandrader | jesus.... | 21:32 |
| dandrader | you guys are nuts :) | 21:32 |
| racarr | I hit the point yesterday where I was really starting to question continuing to hack up the android stack and write complex tests for what I was doing | 21:58 |
| racarr | in hopes of deleting it in a few weeks for the | 21:58 |
| racarr | libinput platform... | 21:58 |
| racarr | soooo | 21:58 |
| racarr | I decided to see how long it would take to just add relative pointer axis and put off raw events until | 21:59 |
| racarr | after libinput | 21:59 |
| racarr | the answer is not long at all I think its done | 21:59 |
| racarr | testing ;) | 21:59 |
| kgunn | racarr: can you parse your last blurb a little more? | 22:26 |
| kgunn | are we now making libinput a pre-req for raw events? | 22:27 |
| racarr | kgunn: Well maybe, but providing a way to unblock unity8 | 22:32 |
| racarr | immediately as well | 22:32 |
| kgunn | racarr: you know what i like :) | 22:33 |
| kgunn | thanks | 22:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!