| robert_ancell | RAOF, are there things worth asking that we can't get apport to do? | 00:05 |
|---|---|---|
| RAOF | Yes; run a Mir server and client, and check if *that* works. | 00:05 |
| RAOF | Other than that, we should be able to collect all the relevant logs. | 00:06 |
| robert_ancell | ta, I'll ask them for that | 00:06 |
| RAOF | robert_ancell: Hey, if someone starts a Mir client and attaches it to unity-system-compositor's socket, what happens? | 00:07 |
| robert_ancell | RAOF, they can connect, but they'll never get focussed. (Actually can't remember if Mir's default behaviour will give them focus) | 00:08 |
| robert_ancell | Either way, it does need to be fixed (Haven't filed a bug yet) | 00:08 |
| * robert_ancell -> lunch | 00:24 | |
| duflu | RAOF: It appears someone has started on making VBE KMS-friendly. But it never hit any kernel tree yet. Do you know anything?... http://lists.freedesktop.org/archives/dri-devel/2013-January/034058.html | 03:15 |
| === chihchun_afk is now known as chihchun | ||
| robert_ancell | duflu, is bug 1192429 fixed now we have those VT changes in? | 03:38 |
| ubot5 | bug 1192429 in Unity System Compositor "unity-system-compositor is on multiple simultaneous (and random) VTs" [High,Triaged] https://launchpad.net/bugs/1192429 | 03:38 |
| duflu | robert_ancell: I will have to update and enable it to retest... | 03:39 |
| robert_ancell | duflu, are you still on the PPA? | 03:39 |
| duflu | robert_ancell: Saucy, yes. I had planned on moving to no-PPAs soon anyway | 03:39 |
| duflu | robert_ancell: Is the fix in distro yet? | 03:40 |
| robert_ancell | duflu, yes | 03:40 |
| robert_ancell | not a specific fix for that problem, but VTs seem to be working well now (aside from the input always going to XMir) | 03:41 |
| duflu | robert_ancell: Is there a bug for that one? | 03:43 |
| robert_ancell | duflu, yes, I'll just find it | 03:43 |
| duflu | robert_ancell: OK, please tag it: vt | 03:43 |
| robert_ancell | duflu, bug 1192843 | 03:43 |
| ubot5 | bug 1192843 in XMir "XMir does not relinquish input on session switch" [Critical,In progress] https://launchpad.net/bugs/1192843 | 03:43 |
| robert_ancell | tagged | 03:43 |
| duflu | That's cool. ppa-purge results in me getting mir package upgrades | 03:44 |
| robert_ancell | duflu, oh, why did you bump the soname for libmirserver? | 03:46 |
| duflu | robert_ancell: Because the switch branch seems to have changed enough ABI things that it became necessary | 03:46 |
| duflu | Loading the old version by mistake was causing serious bugs | 03:47 |
| robert_ancell | duflu, we always rebuild dependencies so it should be impossible to have an old version | 03:47 |
| duflu | robert_ancell: Not so on my Nexus4, which has not been updated :) | 03:47 |
| robert_ancell | duflu, but after that change it did break exactly like that because debian/rules wasn't updated to fix the version | 03:47 |
| duflu | robert_ancell: I thought any ABI break should result in an ABI bump? | 03:48 |
| duflu | That's surely why we separated ABI from version? | 03:48 |
| robert_ancell | duflu, only for libmirclient. libmirserver is still considered ABI unstable | 03:48 |
| robert_ancell | I'll send out an email clarifying | 03:48 |
| duflu | robert_ancell: Alright, that would be helpful | 03:48 |
| Mirv | I keep on getting bug #1210798 (private bug) on saucy from unity-saucy-compositor, ie. not starting up. sandy bridge intel graphics. will monitor the situation as/when updates come :) | 04:03 |
| ubot5 | Error: Launchpad bug 1210798 could not be found | 04:03 |
| Mirv | I'll make it public, not much private there unless something ubersecret in the coredump | 04:03 |
| Mirv | bug #1210798 - there | 04:04 |
| Mirv | damn you ubot | 04:04 |
| duflu | robert_ancell: Yes, VT switching works for me in USC. Bug updated. | 04:06 |
| robert_ancell | duflu, thanks | 04:06 |
| robert_ancell | RAOF, when we bump a package name (e.g. libmirserver0 -> libmirserver1) is there a manual approval for that to land in the archive? | 04:07 |
| Mirv | robert_ancell: yes, I already looked at it but the deal is that I need to ack it with someone with upload rights before publishing | 04:07 |
| robert_ancell | bug 1210798 | 04:08 |
| ubot5 | bug 1210798 in unity-system-compositor (Ubuntu) "unity-system-compositor crashed with SIGSEGV in eglGetDisplay()" [Undecided,New] https://launchpad.net/bugs/1210798 | 04:08 |
| Mirv | ah, hmm, I wonder if it's about me having libhybris installed on x86 | 04:11 |
| robert_ancell | Mirv, that reminds me, we need to make u-s-c attach unity-system-compositor.log automatically | 04:13 |
| * Mirv runs unity-system-compositor | 04:13 | |
| Mirv | ok, so the bug is just crashing without explanation if libhybris/etc installed on x86 | 04:14 |
| robert_ancell | Mirv, you uninstalled libhybris and that fixed it? | 04:15 |
| Mirv | robert_ancell: yes. it uninstalled libhardware etc as well. | 04:16 |
| tvoss_ | good morning :) | 04:16 |
| Mirv | morning tvoss_ | 04:17 |
| robert_ancell | tvoss_, I thought you were on holiday? | 04:17 |
| tvoss_ | robert_ancell, nope, only Friday | 04:17 |
| tvoss_ | robert_ancell, lool is on holiday, my alter ego :) | 04:18 |
| robert_ancell | ah, tag team | 04:18 |
| * tvoss_ is happily running a non-slow XMir right now :) | 04:18 | |
| tvoss_ | duflu, ping | 04:18 |
| tvoss_ | RAOF, ping | 04:21 |
| robert_ancell | tvoss_, ping | 04:23 |
| robert_ancell | tvoss_, you know you can just ask questions out loud :) | 04:23 |
| Mirv | I think I can work with XMir, this mirror-by-default is good enough for what I need until true multi-monitor support | 04:23 |
| robert_ancell | Mirv, nice! | 04:23 |
| tvoss_ | Mirv, woot | 04:25 |
| duflu | tvoss_, pong | 04:25 |
| tvoss_ | duflu, hey there :) tried the bypass branch with xmir, seeing some occasional rendering hiccups | 04:25 |
| Mirv | "nice!" to you, that is :) | 04:25 |
| tvoss_ | robert_ancell, yup :) | 04:27 |
| duflu | tvoss_, interesting. Not sure how to gauge if it is bypass to blame, or just hiccups that were hidden by extra buffering before | 04:27 |
| RAOF | tvoss_: Pong | 04:27 |
| duflu | tvoss_: What is a hiccup? | 04:28 |
| tvoss_ | duflu, seems like a buffer arrives out-of-order | 04:29 |
| duflu | tvoss_: Weird. I can't reproduce any such issue with plain Mir. | 04:29 |
| duflu | Maybe something unusual about XMir vs normal clients | 04:30 |
| tvoss_ | duflu, ack, RAOF ^ | 04:30 |
| RAOF | tvoss_: On intel, I presume? | 04:30 |
| robert_ancell | RAOF, bug 1211063 - does XMir load color profiles on startup and just not handle changes which would be via XRANDR yet? | 04:31 |
| ubot5 | bug 1211063 in Unity System Compositor "Color profile change is not instant when unity-system-compositor is running" [Undecided,New] https://launchpad.net/bugs/1211063 | 04:31 |
| RAOF | robert_ancell: We don't handle colour profiles *at all* at the moment. | 04:31 |
| robert_ancell | RAOF, I thought so too - Is Jussi confused | 04:32 |
| robert_ancell | ? | 04:32 |
| RAOF | I think so? | 04:34 |
| tvoss_ | RAOF, ack | 04:34 |
| tvoss_ | RAOF, is that a known issue? | 04:35 |
| RAOF | tvoss_: No, but it changes the plausible causes. | 04:35 |
| tvoss_ | RAOF, true :) anything else I can help to track down/triage the bug? | 04:35 |
| RAOF | eg: We have in the past failed to flush correctly on radeon, so the buffer we submit to Mir didn't necessarily have fresh content. | 04:35 |
| RAOF | tvoss_: What would be really good is a vsync'd app, displaying an increasing counter, counting up one per vblank, and a 60+Hz film of said client ;) | 04:36 |
| tvoss_ | RAOF, hah, nexuiz has got such a display, let me see if I can trick it into vblank ;) | 04:37 |
| RAOF | XMir *is* the client we have that's most likely to show out-of-order artefacts, as it's the only client we have that doesn't submit a new frame each vblank. | 04:37 |
| tvoss_ | RAOF, true :) | 04:41 |
| * tvoss_ needs more coffee | 04:42 | |
| RAOF | Actually, the requirement for vsync is spurious; all we need is something that displays a monotone counter that increases at least once per vsync. | 04:42 |
| duflu | tvoss_: I will modify some demo client(s) to increase my visual test coverage... after lunch | 04:42 |
| tvoss_ | duflu, yeah, I will move over to the new place, back in 30 | 04:43 |
| * RAOF heads off to the doctors with Zoë. Taking my laptop, so I should be around. | 04:51 | |
| robert_ancell | thomi, do you remember what the trigger was to make Jenkins do a test on a MP? I would like Jenkins reviews of https://code.launchpad.net/~a7x/lightdm/multiseat/+merge/178511 ideally before I approve the branches | 05:19 |
| thomi | robert_ancell: I take it a7x is not a member of ~canonical? | 05:20 |
| robert_ancell | nope | 05:20 |
| thomi | robert_ancell: I believe in that case you need to vote to approve the MP (you don't need to top-approve it thought) | 05:20 |
| robert_ancell | thomi, actually, he is a member of ~contributor-agreement-canonical - perhaps we should allow that group to trigger Jenkins | 05:21 |
| thomi | robert_ancell: you can ask, but I doubt it'll go through. Signing the contributor agreement doesn't mean Canonical has any kind of leverage over them, in case something bad happens | 05:21 |
| thomi | but I agree, it's a real PITA | 05:22 |
| robert_ancell | thomi, well, you could kick them out | 05:22 |
| robert_ancell | but yeah, I know what you mean | 05:22 |
| thomi | if we had more time we should set something up on prodstack as a firewalled builder | 05:22 |
| thomi | shouldn't be too hard to achieve | 05:22 |
| robert_ancell | thomi, is there a way to manually trigger a build, e.g. like the form we use for rebuilding? | 05:24 |
| thomi | yeah, you don't want to add an approve vote? | 05:24 |
| smartboyhw | robert_ancell, why does unity-system-compositor only work in lightdm | 05:25 |
| robert_ancell | smartboyhw, because no-one has used it in anything else. There's no particular reason why it couldn't be used elsewhere | 05:26 |
| smartboyhw | robert_ancell, oh | 05:26 |
| thomi | robert_ancell: I think I found the right job, just trying it now | 05:27 |
| thomi | hmmm, nope! | 05:28 |
| thomi | robert_ancell: I'm not sure how to do that, sorry. I can email fginther, and get back to you tomorrow, if you like | 05:29 |
| robert_ancell | thomi, np | 05:29 |
| robert_ancell | it's not that important | 05:29 |
| thomi | ok | 05:29 |
| duflu | tvoss_: I still can't reproduce any "hiccups" using bypass on mir_demo_server_shell with the example clients | 06:37 |
| tvoss_ | duflu, hmmm, might be XMir specific then | 06:37 |
| duflu | I'm using Intel BTW | 06:37 |
| duflu | RAOF: Is XMir now a well-behaved normal client? (no GBM-specifics) | 06:38 |
| RAOF | duflu: No. | 06:38 |
| duflu | RAOF: How so? Please forgive my forgetfulness... | 06:39 |
| RAOF | Because it doesn't use GL to render; it uses the DDX's methods to render. | 06:39 |
| RAOF | And it's not going to use GL to render for the forseeable future. | 06:40 |
| dholbach | good morning | 06:42 |
| duflu | RAOF: Hmm, OK. I don't really need to know what that means, other than to ensure that XMir only uses the buffer given to it by the client library, and for never longer than till the next swap. That's still true right? | 06:43 |
| duflu | dholbach: Morning | 06:43 |
| RAOF | duflu: That is true. | 06:43 |
| RAOF | OOooh. | 06:43 |
| RAOF | I have a plausible hypothesis. | 06:43 |
| dholbach | hi duflu | 06:43 |
| RAOF | How many times to you allocate buffers? | 06:43 |
| RAOF | Or: how many times will you send a buffer that the client hasn't seen before? | 06:44 |
| duflu | RAOF: Max 3 unique ones. Allocated lazily (when they're first required) | 06:44 |
| RAOF | I think the current code fails to handle the case where buffer->age == 0, but that should only happen once per buffer allocation. | 06:48 |
| RAOF | tvoss_: How many times do the hiccups occur? | 06:49 |
| tvoss_ | RAOF, hmmm ... difficult to tell, but regularly | 06:49 |
| RAOF | So, unlikely to be that you're hitting the age==0 case. | 06:49 |
| duflu | I can also see some damage/age-related bugs when toggling CCSM>OpenGL options | 06:50 |
| duflu | But that's not really related | 06:50 |
| duflu | tvoss_: What are you running to see hiccups in XMir? I suspect this might also be an issue - https://bugs.launchpad.net/xmir/+bug/1211186 | 07:31 |
| ubot5 | Launchpad bug 1211186 in mir (Ubuntu) "[regression] GL(X) apps don't have vsync when running under XMir" [Undecided,New] | 07:31 |
| tvoss_ | duflu, gnome terminal | 07:32 |
| duflu | tvoss_: Hmm, which branch or Mir/bypass and what revision? Keep in mind the input lag fix only just landed | 07:32 |
| duflu | -or +of | 07:32 |
| tvoss_ | duflu, only landed now? | 07:32 |
| tvoss_ | duflu, as of Friday iirc | 07:33 |
| duflu | tvoss_: Only landed in r955 | 07:33 |
| duflu | So looks like Friday night/Saturday your time | 07:34 |
| tvoss_ | duflu, let me recheck | 07:34 |
| duflu | tvoss_: Would have only landed in lp:mir midnight Friday night your time | 07:36 |
| * didrocks again sees issues with ATI | 07:37 | |
| didrocks | sil2100: doesn't seem around, let me try to match with a commit :/ | 07:37 |
| sil2100 | ? | 07:37 |
| sil2100 | I'm here, what's up? | 07:37 |
| didrocks | sil2100: didn't you see my ping? | 07:37 |
| sil2100 | Did I miss a ping? | 07:37 |
| didrocks | 09:19:30 didrocks | sil2100: the -ati machine seems wracky again, it was ok on Friday/Saturday | 07:37 |
| didrocks | 09:19:38 didrocks | sil2100: I think it's mir being the issue with that | 07:37 |
| didrocks | 09:19:48 didrocks | (the tests are ran in mirslave) | 07:37 |
| didrocks | 09:20:10 didrocks | can you see if anything was committed between latest good mirslave run and the new bad one in mir itself? | 07:37 |
| didrocks | 09:20:24 didrocks | (so look at when exactly mirslave check started to fail) | 07:37 |
| didrocks | 09:20:37 didrocks | and potentially match that with a mir rebuild which happened just before? | 07:38 |
| didrocks | 09:21:20 * | didrocks reboot ati to save it first | 07:38 |
| didrocks | multiple ones even ^ | 07:38 |
| sil2100 | Ah! Ok, just saw the ping ones, didn't manage to read the rest of the context ;) Looking at mirslave | 07:38 |
| sil2100 | Runs | 07:38 |
| sil2100 | 11th was fine it seems | 07:39 |
| RAOF | Grargh ATI | 07:40 |
| mlankhorst | isn't memory corruption fun? :P | 07:41 |
| didrocks | sil2100: no, look closer, sometimes the autopilot job is green, but just have one test running | 07:42 |
| didrocks | (on ati) | 07:42 |
| didrocks | and the job went stuck | 07:42 |
| sil2100 | I know, since job 72 failed since it only ran 1 job | 07:42 |
| sil2100 | But 71 seems ok, so checking changes in mir etc | 07:43 |
| * didrocks hopes they were some | 07:43 | |
| didrocks | sil2100: also package list (both post-setup) maybe? | 07:43 |
| RAOF | mlankhorst: I personally prefer texture corruption across suspend/resume cycles. That's more fun. | 07:45 |
| mlankhorst | pfft :p | 07:46 |
| mlankhorst | but I guess I'll try to isolate the issue at least | 07:48 |
| mlankhorst | and figure out why ati is kernel corrupting on me | 07:48 |
| sil2100 | didrocks: still looking, but hm, doesn't seem like there were any intrusive changes - the build started failing when running Mir version from 12.1, but the only changes made since the time it was ok are the packaging change (shlib in rules) and one CMake change ;/ And unity-system-compositor had no new changes since 10th | 07:49 |
| sil2100 | Looking at the postsetup list for anything else | 07:50 |
| didrocks | yeah, let's hope we can find something | 07:51 |
| sil2100 | But why is it always ati affected ;/?! | 07:51 |
| sil2100 | didrocks: how exactly did the ati machine hang up? | 07:52 |
| didrocks | sil2100: so, what we saw last week, is that (it was 100% of the time at first): | 07:53 |
| didrocks | u-s-c couldn't start or starts and hangs | 07:53 |
| didrocks | unity couldn't start (stuck on opengl plugin, when duflu is running unity_system_compositor) | 07:53 |
| didrocks | so the first opengl app hangs | 07:53 |
| didrocks | then, the machine times out of 2h | 07:54 |
| didrocks | if you then restart with regular xorg | 07:54 |
| didrocks | nothing happens | 07:54 |
| duflu | didrocks: duflu? | 07:54 |
| didrocks | the machines hangs | 07:54 |
| didrocks | duflu: sorry, I meant you run unity_support_test from compiz | 07:55 |
| sil2100 | uh | 07:55 |
| didrocks | sil2100: so, it's really annoying, everytime, that's what screwing up the ati machine | 07:55 |
| * duflu barely remembers what that means | 07:55 | |
| didrocks | duflu: you do run it if the unity plugin is setup to know if unity can be ran in that session | 07:56 |
| didrocks | or should fallback on llvmpipe mode | 07:56 |
| didrocks | IIRC | 07:56 |
| sil2100 | didrocks: since diffing the postsetup pkg lists show that only mir packages, unity-system-compositor and unity-autopilot are different between runs | 07:57 |
| didrocks | sil2100: ok, no kernel, no driver? | 07:57 |
| didrocks | weird, we had the issue 100% of the time | 07:57 |
| didrocks | and then, not anymore | 07:57 |
| didrocks | at all, in mutiple runs | 07:57 |
| didrocks | sil2100: when did you see that starting again? | 07:57 |
| duflu | didrocks: We've seen that problem before... https://code.launchpad.net/~vanvugt/ubuntu/quantal/nux/fix-1039155/+merge/128422/comments/281152 | 07:58 |
| sil2100 | didrocks: I compared the last ok run (which ran more than 1 test), which was from yesterday | 07:58 |
| sil2100 | With the one today, which started failing | 07:58 |
| didrocks | duflu: right, here the issue is that with Mir/u-s-c on ATI, the program hangs | 07:59 |
| didrocks | (unity_support_test) | 07:59 |
| sil2100 | geh | 07:59 |
| duflu | didrocks: Yes there have been problems on various machines where unity_support_test causes bugs if executed from within Compiz. I think I was advocating not running it from within Compiz (which solved the issues at the time) | 08:00 |
| didrocks | duflu: but this only happen when u-s-c is running | 08:01 |
| didrocks | with regular Xorg, no issue | 08:01 |
| didrocks | and not everytime :p | 08:01 |
| duflu | didrocks: The issue is much older than that and has been happening for an unlucky few for a year | 08:01 |
| sil2100 | didrocks: can I try re-running the mirslave stack? Since I missed last week and want to make sure the failure now is reproducible | 08:01 |
| didrocks | duflu: I mean, we run compiz hundreds of times everyday | 08:01 |
| sil2100 | (or does it crash ati for good?( | 08:01 |
| didrocks | if not thousands | 08:01 |
| didrocks | from the past 8 month on this particular machine | 08:02 |
| didrocks | duflu: only running xmir shows that issue | 08:02 |
| didrocks | sil2100: it's running every 4h automatically now | 08:02 |
| didrocks | sil2100: so let's wait for next run | 08:02 |
| sil2100 | Ok | 08:02 |
| duflu | didrocks: I know and I could never reproduce it either. However those who did have the problem before, found the solution was to unity_support_test externally, as in https://code.launchpad.net/~vanvugt/ubuntu/quantal/nux/fix-1039155/+merge/128422 | 08:04 |
| didrocks | duflu: but it would be good to know why Xmir is showing the issue more | 08:05 |
| didrocks | that doesn't explain the reason | 08:05 |
| duflu | didrocks: True :( | 08:05 |
| duflu | RAOF: Fun fact: DRM will successfully scan out non-scanout GBM buffers (!?) | 08:08 |
| didrocks | duflu: do you think we should try it now? | 08:08 |
| didrocks | duflu: and that will be compatible with u-s-c? | 08:08 |
| duflu | didrocks: I can't remember all the details and how things fit together, but I do think it would be good to avoid any fork/exec from compiz | 08:09 |
| didrocks | duflu: mind proposing an updated branch? | 08:09 |
| duflu | didrocks: I'm on the critical path to deliver bypass support, so want to finish that first | 08:09 |
| didrocks | duflu: sure, do you have any idea when you can tackle that one? (roughly?) | 08:10 |
| duflu | didrocks: 1 week ? :/ | 08:10 |
| didrocks | hum… | 08:10 |
| didrocks | ok | 08:10 |
| didrocks | we have to find something/someone to do it beforehand | 08:10 |
| didrocks | as otherwise it will mean no more Mir delivering in a week | 08:11 |
| sil2100 | Unacceptable ;/ | 08:11 |
| sil2100 | didrocks: so hm, the workaround/solution would be to remove running unity_support_test from within compiz and just running it like in the branch duflu mentioned, i.e. separately (maybe upstart?) | 08:14 |
| sil2100 | I wonder if this would indeed help | 08:15 |
| didrocks | sil2100: yeah, we need someone to try that with xmir though | 08:15 |
| didrocks | sil2100: /etc/X11/Xsession.d/ is fine for now | 08:15 |
| didrocks | (see #ubuntu-desktop) | 08:15 |
| duflu | sil2100: You need to do it in a parent process of the X session, because if unity_support_test fails then export LIBGL_ALWAYS_SOFTWARE=1 has to be inherited by the compiz process | 08:19 |
| sil2100 | duflu: right, thanks! | 08:19 |
| RAOF | duflu: How did you discover that? | 08:19 |
| duflu | RAOF: I was just curious. Not sure why. It's weord | 08:20 |
| duflu | weird | 08:20 |
| sil2100 | didrocks: I understand that you're hacking on it right now? Or should I try? But I won't be able to test it on xmir though, so will have to find someone running it | 08:20 |
| didrocks | sil2100: please do, I'm in a ETOOMUCH already :/ | 08:20 |
| didrocks | sil2100: why can't you try on xmir? | 08:20 |
| RAOF | duflu: We might accidentally allocate scanout-capable gbm buffers anywoy | 08:20 |
| duflu | RAOF: Makes me think GBM's idea of scanout is different to DRM's, which would be important to know | 08:20 |
| sil2100 | didrocks: I am afraid it will make my system boom ;) Is it safe? | 08:20 |
| didrocks | sil2100: it's easy to revert anyway | 08:21 |
| didrocks | install unity-system-compositor | 08:21 |
| didrocks | and uninstall it | 08:21 |
| didrocks | for removing it | 08:21 |
| didrocks | sil2100: what driver are you using? | 08:21 |
| duflu | RAOF: All I have to decide right now is (width >= 800 && height >= 600) ... :/ | 08:21 |
| sil2100 | Ok, sounds easy | 08:21 |
| sil2100 | didrocks: the open radeon driver | 08:21 |
| RAOF | duflu: It's also possible that there's *no* buffer which is incapable of scanout, depending on how funky intel's scanout hardware is. | 08:22 |
| didrocks | sil2100: excellent, that's what we need :) | 08:22 |
| duflu | RAOF: Yeah I figured drivers would be different on this. I will probably have to play with video cards | 08:22 |
| didrocks | sil2100: I would advise you to first try with regular Xorg | 08:22 |
| didrocks | sil2100: and ensuring that the script is ran | 08:22 |
| sil2100 | \o/ will do | 08:22 |
| didrocks | thx! | 08:22 |
| duflu | RAOF: Tho if you try to DRM flip a buffer with wrong dimensions that's pretty fatal | 08:29 |
| duflu | At least, Mir makes it fatal | 08:30 |
| mlankhorst | superrr deadly | 08:30 |
| sil2100 | didrocks: I'm quickly rebuilding compiz to remove that patch for running it from compiz, once this is done I test the scripts | 08:32 |
| didrocks | thanks sil2100! | 08:34 |
| duflu | Back in 30ish | 08:37 |
| duflu | RAOF: XMir is buffer usage hardware, right? :) | 09:12 |
| tsdgeos | guys, using mir_demo_server + mir_demo_client_accelerated on the Nexus 4 i get a black screen | 09:15 |
| tsdgeos | any clue of what may be wrong? | 09:15 |
| sil2100 | brb, reboot | 09:15 |
| duflu | tsdgeos: Probably surfaceflinger is still running? | 09:15 |
| tsdgeos | duflu: nope | 09:16 |
| tsdgeos | phablet@ubuntu-phablet:~$ ps -A | grep surf | 09:16 |
| tsdgeos | phablet@ubuntu-phablet:~$ | 09:16 |
| duflu | tsdgeos: I have seen similar issues... Mir lacks explicit support for turning the screen on if it is off. But that's not usually an issue if you have fully disabled surfaceflinger (and reboot): https://wiki.ubuntu.com/Touch/Testing/Mir#Switch_from_SurfaceFlinger_to_Mir | 09:17 |
| duflu | tsdgeos: Also, that issue I have seen is obvious because Mir will throw exceptions | 09:17 |
| duflu | mir_demo_server* will throw exceptions | 09:18 |
| tsdgeos | not here | 09:18 |
| tsdgeos | stuff is here | 09:18 |
| tsdgeos | on the shell | 09:18 |
| tsdgeos | without complaining | 09:18 |
| duflu | tsdgeos: Any hint that the backlight is *on* ? | 09:18 |
| tsdgeos | how could i know? | 09:18 |
| tsdgeos | it seems to be | 09:18 |
| ogra_ | use powerd-cli to force it on | 09:18 |
| duflu | It's usually obvious (not properly black) | 09:18 |
| tsdgeos | i.e. if i reboot i get the "google" logo | 09:18 |
| tsdgeos | until i start mir_server_demo | 09:19 |
| duflu | tsdgeos: Yeah | 09:19 |
| tsdgeos | that turns gray | 09:19 |
| tsdgeos | looks "ok" to me | 09:19 |
| duflu | tsdgeos: OK, so your server is running but not showing clients then | 09:19 |
| duflu | tsdgeos: Because it sounds like the glClear from mir_demo_server* is working | 09:19 |
| tsdgeos | should it show some FPS readings? | 09:20 |
| tsdgeos | because the unaccelerated one does | 09:20 |
| tsdgeos | but i still can't see anything on screen | 09:20 |
| duflu | tsdgeos: Yes it will always be 60 FPS on Nexus4 | 09:20 |
| tsdgeos | see no output here | 09:20 |
| duflu | tsdgeos: Does the client start/hang? | 09:20 |
| tsdgeos | i do see 60fps with the unaccerelated | 09:20 |
| tsdgeos | but the accelerated only gives | 09:21 |
| tsdgeos | phablet@ubuntu-phablet:~$ mir_demo_client_accelerated | 09:21 |
| tsdgeos | Starting | 09:21 |
| tsdgeos | Connected | 09:21 |
| tsdgeos | __pthread_gettid -2 | 09:21 |
| tsdgeos | Surface created | 09:21 |
| tsdgeos | and that's it | 09:21 |
| duflu | tsdgeos: OK then you have a GL-specific issue. Probably related to hybris | 09:21 |
| tsdgeos | :/ | 09:21 |
| tsdgeos | who do i nag ? | 09:22 |
| duflu | tsdgeos: https://bugs.launchpad.net/mir/+filebug ;) | 09:22 |
| tsdgeos | so it's going to be another day without any work done | 09:22 |
| tsdgeos | awesome :D | 09:22 |
| duflu | tsdgeos: Did you get all your binaries from the phablet image or hand built? | 09:23 |
| tsdgeos | all image + apt-get upgrade | 09:23 |
| ogra_ | ugh | 09:24 |
| ogra_ | did you check that there are no bits in the apt-get upgrade that reach into the android side ? | 09:24 |
| duflu | tsdgeos: Same result for mir_demo_client_egl* ? | 09:24 |
| ogra_ | (are yoou sure surfaceflinger works at all after you upgraded) | 09:25 |
| tsdgeos | duflu: the egl ones print stuff to the shell | 09:25 |
| ogra_ | (if not, Mir wont either ... apt-get has to be used with *lots* of care) | 09:25 |
| tsdgeos | but can't see stuff on screen either | 09:25 |
| duflu | tsdgeos: How about mir_demo_client_fingerpaint? | 09:25 |
| duflu | That should work (software rendering) | 09:25 |
| tsdgeos | nothing | 09:26 |
| tsdgeos | and it ended (returned to shell) after a while | 09:26 |
| tsdgeos | seems the demo server quite | 09:26 |
| tsdgeos | -e | 09:26 |
| RAOF | duflu: yes indeed it is buffer_usage_hardware :P | 09:26 |
| duflu | tsdgeos: It sounds a lot like your client and server are mismatched. :/ | 09:27 |
| tsdgeos | may be | 09:27 |
| tsdgeos | sadly s-jenkins:8080/job/ubuntu-touch-phablet-image-saucy-mir/ hasn't had a correct build for a long time | 09:27 |
| duflu | RAOF: Good. Because bypass cripples software buffer performance slightly. I have disabled bypass of those | 09:28 |
| RAOF | Huh | 09:28 |
| duflu | Not surprising. I would expect pushing pixels across the bus to GPU-land to be a bit slower | 09:29 |
| RAOF | But you need to do that bypass or not bypass? | 09:29 |
| tsdgeos | ogra_: what's your suggestion then to get something "up to date" given the last successful image is from 6 days ago? | 09:30 |
| mlankhorst | duflu: well just do staging transfers from GART to VRAM :-) | 09:30 |
| ogra_ | tsdgeos, poke rickmm ... once he is up ... and beyond that use the latest normal image, diable SF there and install the Mir stuff you need (i dont think the Mir image does much different) | 09:31 |
| duflu | mlankhorst: I don't know what you mean | 09:31 |
| tsdgeos | ogra_: then why is it red :'( | 09:32 |
| mlankhorst | perform a gpu assisted copy from system memory to VRAM | 09:32 |
| * tsdgeos tries to do something else until ricmm or grayback are online | 09:32 | |
| duflu | RAOF: In buffer_usage_hardware we're just sending (smaller) instructions across the bus and the filling/blitting originates from the GPU. It's quite different | 09:32 |
| ogra_ | tsdgeos, no idea, i'm not affiliated with that image | 09:32 |
| duflu | mlankhorst: Sounds interesting. Mir doesn't seem to with Intel at least. | 09:33 |
| tsdgeos | ogra_: sure, not blaming you, just crying out loud | 09:33 |
| mlankhorst | duflu: intel has no dedicated VRAM :P | 09:34 |
| ogra_ | tsdgeos, well, grab the latest normal image, disable SF and install Mir ... shouldnt be different :) | 09:34 |
| duflu | mlankhorst: I know. Which makes me surprised there's any performance difference. But I would expect it with real cards | 09:34 |
| tsdgeos | can try that i guess | 09:35 |
| tsdgeos | ogra_: tx | 09:35 |
| sil2100 | How can I see if xmir is currently used? | 09:48 |
| didrocks | sil2100: unity-system-compositor should be running | 09:49 |
| sil2100 | Ok, don't see it running here - is there anything else I need to do besides installing unity-system-compositor ? Any configuration switch? | 09:51 |
| didrocks | shouldnt' | 09:52 |
| didrocks | duflu: RAOF: ^ | 09:52 |
| didrocks | sil2100: cat /var/log/lightdm/unit* | 09:52 |
| * duflu checks | 09:52 | |
| sil2100 | http://paste.ubuntu.com/5976702/ | 09:53 |
| duflu | sil2100: You should have unity-system-compositor running, and also "ps auxw | grep mir" reporting mir options to X | 09:53 |
| sil2100 | This is from /var/log/lightdm/unity-system-compositor.log | 09:53 |
| RAOF | That's *very* informative :) | 09:53 |
| duflu | Heh | 09:54 |
| duflu | sil2100: Wrong URL? | 09:54 |
| sil2100 | hm, good url but it seems the log has some non-ascii characters in it | 09:54 |
| sil2100 | Let me paste just the relevant parts | 09:54 |
| sil2100 | inkerlinker.c:1095| ERROR: Library '/system/lib/libGLESv2.so' not found | 09:55 |
| sil2100 | Segmentation fault (core dumped) | 09:55 |
| didrocks | sil2100: hybris installed on your machine? | 09:55 |
| seb128 | libhybris | 09:55 |
| RAOF | You win the "I've got hybris installed" award. | 09:55 |
| sil2100 | I wonder what's hybris doing on my system | 09:55 |
| seb128 | we need to stop diverting libgles from there... | 09:55 |
| seb128 | really | 09:55 |
| tvoss | seb128, in the works as I understand it | 09:58 |
| seb128 | tvoss, great ;-) | 09:58 |
| tvoss | seb128, I have had that issue multiple times in the recent past :) | 09:59 |
| seb128 | tvoss, you are not the only one ;-) | 09:59 |
| sil2100 | Ok, xmir works now with all things hybris uninstalled | 10:04 |
| sil2100 | Thanks guys! | 10:04 |
| sil2100 | didrocks: the Xsession.d detection seems to work fine | 10:04 |
| didrocks | sil2100: you do have the file in /tmp/? | 10:05 |
| didrocks | /tmp/unity_support_test.0 | 10:05 |
| sil2100 | Yes | 10:05 |
| sil2100 | I also did the test that duflu recommended in that merge | 10:05 |
| duflu | Why do we even have libhybris on desktop? https://launchpad.net/ubuntu/+source/libhybris | 10:06 |
| sil2100 | i.e. made unity_support_test -> /bin/false and had a fallback to llvmpipe | 10:06 |
| sil2100 | Works both for xmir and standard x | 10:06 |
| sil2100 | didrocks: now the steps to proceed... I will fill in a merge to lp:nux with the xsession.d file, but what about compiz? Since we don't daily release that yet | 10:07 |
| sil2100 | didrocks: (we should start daily-releasing this week btw.) | 10:07 |
| sil2100 | didrocks: should I modify the packaging and queue it up for sponsoring? | 10:07 |
| didrocks | sil2100: juste prepare for a manual upload | 10:09 |
| sil2100 | Ok, doing one more check and then preparing everything | 10:09 |
| didrocks | thx sil2100 | 10:10 |
| duflu | sil2100: Can you link it to bug 1066764 too? | 10:10 |
| didrocks | mirslave just passed FYI this time | 10:10 |
| ubot5 | bug 1066764 in Nux "Unity fails to load on old hardware (compiz enabling LLVMpipe has no effect and Mesa tries to use hardware still)" [High,In progress] https://launchpad.net/bugs/1066764 | 10:10 |
| sil2100 | didrocks: ;/ Still, if this is the root cause, I guess it's better to have it resolved | 10:11 |
| sil2100 | duflu: ok! | 10:11 |
| sil2100 | didrocks: btw. is DESKTOP_SESSION and GDMSESSION ubuntu-2d still used? Since my desktop didn't want to start when I was setting those when doing a fallback to llvmpipe | 10:13 |
| didrocks | sil2100: I don't think they do work | 10:14 |
| sil2100 | didrocks: is setting those still required for the fallback mode or can I remove those and just use LIBGL_ALWAYS_SOFTWARE | 10:14 |
| sil2100 | didrocks: ok | 10:14 |
| didrocks | sil2100: yeah LIBGL_ALWAYS_SOFTWARE | 10:14 |
| sil2100 | So they're leftovers then ;) | 10:14 |
| didrocks | probably :) | 10:14 |
| RAOF | Bah. One-surface-per-output is annoying. | 10:16 |
| duflu | RAOF: How? | 10:19 |
| RAOF | Because it means sharding the single X root window. | 10:22 |
| RAOF | Which is awkward. | 10:25 |
| sil2100 | duflu: btw. in the old nux quantal branch I see you also removed the 01_blacklist_llvmpipe.patch patch as well, is that necessary? | 10:28 |
| RAOF | So much so that it's time to investigate the CrtcSetScanoutPixmap route. | 10:28 |
| duflu | sil2100: I have no idea. It was a long time ago | 10:28 |
| sil2100 | It wasn't mentioned in the change and it works here without removing it, so I guess I'll skip that | 10:29 |
| davmor2 | didrocks: I did a fresh install of saucy from fridays image over the weekend and am using mir from main that seems to of fixed the issues I was having thanks for the advice to drop the ppa :) | 10:35 |
| didrocks | davmor2: great! :) | 10:36 |
| sil2100 | didrocks: btw. since I see we already had a conffile /etc/X11/Xsession.d/50_check_unity_support which we rm_conffile'd - you think I should add it with the same name or maybe choose a different one? | 10:55 |
| didrocks | sil2100: same name is fine | 10:55 |
| didrocks | sil2100: of course, remove the rm_conffile :) | 10:58 |
| sil2100 | Yep ;) | 11:00 |
| sil2100 | didrocks: for the compiz manual upload... should I create a bug for that version, or just poke you with the source package etc? | 11:17 |
| didrocks | sil2100: no need for a bug | 11:18 |
| sil2100 | didrocks, duflu: https://code.launchpad.net/~sil2100/nux/unity_support_test/+merge/179666 <- it's the same change as duflu did in the past, just without removing the whitelist patch | 11:29 |
| sil2100 | didrocks: I sent the compiz source pkg to you by e-mail | 11:29 |
| didrocks | sil2100: approved and sponsored compiz, thanks! | 11:38 |
| duflu | sil2100: Thanks. But I must run away. | 11:42 |
| === tvoss is now known as tvoss|quick_lunc | ||
| === chihchun is now known as chihchun_afk | ||
| === alan_g is now known as alan_g|lunch | ||
| mlankhorst | i think my radeon hd 6570 is just busted, if I disable UVD the memory corruption appears to be gone | 12:20 |
| mlankhorst | but it still goes into lockup recovery every 10 seconds, until after 5 minutes of that it gives up and shuts itself down | 12:20 |
| === alan_g|lunch is now known as alan_g | ||
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| ricmm | hey guys | 14:44 |
| ricmm | msh::SessionListener::stopping() gets called when the socket's client end disappears? | 14:44 |
| ricmm | or when the client exits _explicitly_ | 14:44 |
| ricmm | greyback_: ping | 15:05 |
| greyback_ | ricmm: pong | 15:05 |
| ricmm | :) | 15:05 |
| greyback_ | sorry, dropped out there | 15:06 |
| ricmm | I asked this when you dropped | 15:06 |
| ricmm | msh::SessionListener::stopping() gets called when the socket's client end disappears? | 15:06 |
| ricmm | or when the client exits _explicitly_ | 15:06 |
| ricmm | as-in, would we get that when the process is SIGKILL'd | 15:06 |
| ricmm | or only SIGTERM / exit() | 15:06 |
| greyback_ | yes, I just tested it now (you missed my reply) I "kill -9" an app, SessionListener::stopping() was called my Mir | 15:07 |
| greyback_ | s/my/by/ | 15:07 |
| ricmm | greyback_: awesome \o/ | 15:10 |
| xjunior | hey guys | 15:25 |
| xjunior | I know, I know... I only get here with problems | 15:25 |
| xjunior | Now what I'm seeing here, using a intel graphics card is "intel(0): [drm] failed to set drm interface version." | 15:26 |
| xjunior | using the sleep trick doesn't work for me | 15:26 |
| xjunior | another workaround I've seen was to use GDM instead of LightDM, but I'm trying to avoid that | 15:30 |
| tsdgeos | ogra_: this morning you suggested using powerd-cli to make sure the screen was "on" | 15:42 |
| ogra_ | yeah | 15:42 |
| tsdgeos | ogra_: http://paste.ubuntu.com/5977723/ | 15:42 |
| tsdgeos | the output feels not totally right | 15:42 |
| ogra_ | sudo -u pahblet -i | 15:43 |
| ogra_ | *phablet | 15:43 |
| ogra_ | make sure you are in the users session ... phablet owns the session dbus | 15:43 |
| tsdgeos | ogra_: but then it says i need to be root | 15:44 |
| tsdgeos | phablet@ubuntu-phablet:~$ powerd-cli display on | 15:44 |
| tsdgeos | You must be root to run powerd-cli | 15:44 |
| tsdgeos | do i sudo? | 15:44 |
| tsdgeos | same warning if i sudo | 15:44 |
| ogra_ | tsdgeos, hmm, ask sfoshee ... it should work :( | 15:50 |
| SamuRay | saludos | 15:56 |
| SamuRay | alguien habla español? | 15:57 |
| xjunior | SamuRay: portugues | 15:58 |
| SamuRay | xjunior, al menos entiendes lo que digo? | 15:58 |
| xjunior | si | 15:58 |
| SamuRay | xjunior, puedes ayudarme con un problema que tengo con mir? | 15:58 |
| xjunior | SamuRay: depende... qual o problema? | 16:00 |
| SamuRay | yo he venido usando mir desde hace algunos meses, el dia viernes hubo una actualizacion y me da un error | 16:01 |
| racarr | Morning | 16:01 |
| SamuRay | E: /var/cache/apt/archives/libmirserver1_0.0.8+13.10.20130808.2bzr948saucy0_amd64.deb: intentando sobreescribir `/usr/lib/x86_64-linux-gnu/libmirplatformgraphics.so', que está también en el paquete libmirserver0:amd64 0.0.8+13.10.20130808.1bzr945saucy0 | 16:01 |
| SamuRay | morning racarr | 16:01 |
| xjunior | SamuRay: tente | 16:01 |
| xjunior | SamuRay: sudo dpkg --install --force-overwrite /var/cache/apt/archives/libmirserver1*.deb | 16:02 |
| xjunior | racarr: morning! | 16:02 |
| xjunior | racarr: would you try to help me with one intel issue? it seem to be failing to becomr DRM master or something | 16:02 |
| SamuRay | xjunior, esto ha ocasionado que el ligthdm no inicie automaticamente | 16:03 |
| xjunior | SamuRay: con usted? | 16:03 |
| SamuRay | xjunior, no entiendo | 16:04 |
| xjunior | SamuRay: o que esta ocasionando que el lightdm não inicie automaticamnte? | 16:04 |
| racarr | xjunior: I can try a little but I don't have an intel card or any ideass | 16:05 |
| racarr | so nothing so far :p | 16:05 |
| xjunior | have you seen people complaining about it? | 16:06 |
| ricmm | kdub: hey kevin | 16:19 |
| ricmm | tsdgeos is unable to bring up Mir on his nexus4 since a while back | 16:19 |
| ricmm | seems to only be working on maguro | 16:19 |
| racarr | xjunior: Not yet. | 16:21 |
| racarr | ricmm: I think kdub is on vacation? (t/f?) | 16:21 |
| racarr | it hasnt been that long since I tried on nexus 4 but I can try again today | 16:21 |
| ricmm | ah right, you have one too | 16:21 |
| ricmm | if you could that'd be great | 16:21 |
| ricmm | theres no obvious error, just nothing on screen | 16:22 |
| racarr | ok will do soon | 16:23 |
| tsdgeos | racarr: yeah it'd be great if you can try, just to make sure i'm not doing something really stupid (which tbh i don't see what can be) | 16:24 |
| tsdgeos | ricmm: racarr: ok, i'm eod'ing now, will be back in a few hours in non-working-mode in case you need me | 16:27 |
| greyback_ | racarr: hey, I'm looking into dandrader's work on the OSK. He was trying to add an extra surface type to Mir, but got resistance to that idea. | 16:34 |
| greyback_ | https://code.launchpad.net/~dandrader/mir/inputmethod_surface_type/+merge/173696 | 16:34 |
| greyback_ | racarr: I'm considering alternative ideas, would you have a few mins to discuss it some time today? | 16:35 |
| ricmm | tvoss: ping | 16:37 |
| tvoss | ricmm, pong | 16:37 |
| ricmm | according to the MR above, which seems to be stalled for a month now | 16:38 |
| ricmm | would it make more sense for OSKs to use the overlay type? | 16:38 |
| ricmm | how do we stack overlays and make sure the OSK has priority | 16:38 |
| ricmm | we need to unblock that work today | 16:38 |
| xjunior | filled this bug, racarr: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1211403 | 16:40 |
| ubot5 | Launchpad bug 1211403 in xserver-xorg-video-intel (Ubuntu) "intel failed to become DRM master" [Undecided,New] | 16:40 |
| tvoss | ricmm, looking | 16:41 |
| racarr | ricmm: greyback_: I thought we decided to use | 16:41 |
| racarr | the overlay surface type | 16:41 |
| racarr | Am updating my phone now to test 4 | 16:41 |
| ricmm | racarr: well I think the problem here is how would the shell know which of the overlay surfaces is the OSK? | 16:42 |
| tvoss | racarr, that contradicts what we have been discussing with design | 16:42 |
| greyback_ | racarr: I don't recall the decision being made anyway. I worry about needing the OSK surface to always be on top of everything else, so I need a unique way to identify it. I could identify the surface by its session | 16:42 |
| racarr | Ok. | 16:43 |
| racarr | greyback_: You still sort of need to identify it by session because | 16:43 |
| racarr | it should be the only surface allowed to take the | 16:43 |
| racarr | type we are using | 16:43 |
| greyback_ | racarr: indeed. But instead of just authorising it to take that session type, I can mark that surface in shell as special somehow, instead of relying on the surface type. | 16:44 |
| racarr | Hmm | 16:44 |
| greyback_ | I don't particularly like that solution though | 16:44 |
| racarr | yes, it feels like the surface type is a nice way to make that mark sort of though | 16:44 |
| racarr | I would be happy to land that branch now :) | 16:44 |
| ricmm | not so much the sort but the original identification is the issue I think | 16:44 |
| ricmm | isnt it? | 16:44 |
| racarr | tvoss: ricmm:? | 16:44 |
| racarr | ricmm: No, because, its the same as clients | 16:45 |
| racarr | with the PID based authorization | 16:45 |
| racarr | then if the client is called OSK, you can trust it really is the OSK | 16:45 |
| ricmm | right, but maliit-server isnt launched by the shell right now | 16:45 |
| ricmm | greyback_: the plan is to launch it from the shell? | 16:45 |
| ricmm | currently its a separate service, it needs to be up by the time the shell comes up | 16:45 |
| racarr | at least the shell needs the PID right | 16:45 |
| racarr | because the default policy is to dissaprove connections | 16:45 |
| greyback_ | ricmm: I figured shell would launch it. | 16:45 |
| ricmm | iirc if you launch maliit-server after a shell is up, Qt fails to find it as an input method | 16:46 |
| ricmm | not entirely sure how that works, but im sure it can be sorted | 16:46 |
| racarr | right I mean the worst case is the shell is passed | 16:46 |
| ricmm | and you are right, we need to authorize all sessions | 16:46 |
| ricmm | so it has to happen after anyways | 16:46 |
| racarr | --with-maliit-pid=7 | 16:46 |
| greyback_ | oh that's good to know, I wasn't aware of that concern | 16:46 |
| ricmm | ew | 16:46 |
| ricmm | racarr: now thats ugly | 16:46 |
| ricmm | the shell could launch the upstart job, thats fine | 16:47 |
| racarr | Of course XD, that's the literal worst case I can think of | 16:47 |
| racarr | ok | 16:47 |
| ricmm | its a session job anyways | 16:47 |
| racarr | Ok | 16:47 |
| ricmm | we just need to make sure that maliit-server wont block in that respect | 16:47 |
| racarr | and if there are issues with Qt detection or something | 16:47 |
| ricmm | I'll take that up with tmoenicke | 16:47 |
| racarr | that can either be resolved or it can do it before initializing Qt | 16:47 |
| ricmm | we can figure it out | 16:48 |
| ricmm | lets agree on the surface type thing | 16:48 |
| ricmm | who were the ones against it? daniel and alan? | 16:48 |
| racarr | Alan had no strong opinion I think daniel thinks we should use the overlay type | 16:49 |
| racarr | It's | 16:50 |
| racarr | tvoss is right the design documents call for | 16:50 |
| racarr | an input method surface type | 16:50 |
| racarr | because input methods are still stacked under hints (i.e. tooltips), and the final overlay layer, which so far is only for things like | 16:50 |
| racarr | magnifier or screenshot area selection | 16:51 |
| tvoss | yup | 16:51 |
| tvoss | racarr, ricmm I set the MP back to needs review | 16:51 |
| racarr | I am happy to approve it there is one thing though | 16:51 |
| racarr | does this really have to bump | 16:51 |
| racarr | mirclient so version? | 16:51 |
| racarr | I am | 16:52 |
| racarr | super super sure no one is using mir_surface_type_arraysize_ | 16:52 |
| alan_g | racarr: if they are then they are the sort of idiot that cannot be protected from themselves. | 16:53 |
| racarr | alan_g: Later this afternoon we find that someone was using it and it was me :p | 16:54 |
| ricmm | we can live with that | 16:54 |
| ricmm | alan_g: are you ok with approving this branch? | 16:54 |
| alan_g | ricmm: sorry? I don't see the context | 16:55 |
| ricmm | the input method surface type branch discussed above | 16:56 |
| racarr | Top approved | 17:05 |
| === alan_g is now known as alan_g|EOD | ||
| racarr | Bye alan :) | 17:07 |
| racarr | ripping the cloggable event sink out of client-focus :D | 17:07 |
| ricmm | racarr: \o/ | 17:12 |
| racarr | merging ~kdub/mir/connect-display-request | 17:29 |
| racarr | if anyone wants to jump in and stop it before jenkins has its way :p | 17:29 |
| racarr | connect-display-info has some of the worst merge conflicts I have ever seen :( | 18:13 |
| racarr | even with weave merge, its basically still total file ocnflict on all the tests | 18:13 |
| racarr | unit-tests got really slow | 18:20 |
| racarr | over the last week | 18:20 |
| racarr | probably takes 10x as long to run | 18:20 |
| racarr | When did we get all these tests with | 18:22 |
| racarr | sleeps, etc | 18:22 |
| racarr | I think it's a bad idea. sometimes things that take <100ms locally, I have seen take > 10,000 ms on valgrind in qemu | 18:22 |
| racarr | so you can never choose a reasonable sleep value | 18:22 |
| tsdgeos | +1 | 18:25 |
| tsdgeos | sleeps in tests are not cool | 18:25 |
| racarr | and now already the unit tests take 20 seconds, but if we have to bump the values because of failures | 18:25 |
| racarr | bler :p ill look in to it after lunch | 18:26 |
| racarr | Lunch! | 19:03 |
| tvoss | racarr, ping | 19:46 |
| racarr | tvoss: Pong | 19:48 |
| tvoss | racarr, hey there | 19:49 |
| tvoss | racarr, quick one: Do we hand over the appid to unity when a surface is requested? | 19:49 |
| racarr | the app id | 19:49 |
| racarr | like the session identifier | 19:49 |
| racarr | or do you mean like the PID or something | 19:49 |
| racarr | we do hand over the session identifier | 19:49 |
| racarr | it merged not so long ago | 19:50 |
| tvoss | racarr, ack. So whenever an app requests a surface, the session information is handed to unity? | 19:57 |
| racarr | tvoss: Ok well not entirel when worded that way | 19:58 |
| racarr | the surface now contains the session, so in all the | 19:59 |
| racarr | surface created hooks etc the session is passed through | 19:59 |
| racarr | however there are some componenets | 19:59 |
| racarr | mainly the_shell_placement_strategy | 19:59 |
| racarr | which deal in terms of msh::SurfaceCreationParameters | 19:59 |
| racarr | here, we don't pass the session | 19:59 |
| racarr | it seems like a good thing to pass | 19:59 |
| tvoss | why not? | 19:59 |
| tvoss | yeah, I think so, too | 19:59 |
| tvoss | otherwise the implementation always needs to query the state from some tracking entity | 19:59 |
| racarr | tvoss: I guess just omission :) | 20:10 |
| racarr | because the only placement we have design for, can be decided entirely based on | 20:11 |
| tvoss | racarr, can you fix that please? | 20:11 |
| racarr | surface parameters | 20:11 |
| racarr | Sure, what is it for? | 20:11 |
| racarr | hmm I guess you would probably want it for OSK | 20:12 |
| tvoss | racarr, well, session and surface are two things that belong together from my pov | 20:13 |
| tvoss | racarr, that should be reflected whenever requesting a policy decision | 20:14 |
| racarr | tvoss: mm | 20:16 |
| racarr | tvoss: Ok ill propose it in an hour or so just finishing up some stuff from pre lunch now | 20:17 |
| tvoss | racarr, thx | 20:18 |
| === tvoss is now known as tvoss|eod | ||
| tsdgeos | racarr: any luck with my nexus4+mir problem? | 22:07 |
| racarr | tsdgeos: Not yet. my nexus 4 seems to be having battery issues, I upgraded, then it died in abttery halfway through and wouldn't come back on for 20 minutes, finished upgrade, started getting mir | 22:08 |
| racarr | deps | 22:08 |
| racarr | rinse repeat | 22:08 |
| racarr | started building mir | 22:08 |
| racarr | rinse repeat... | 22:08 |
| tsdgeos | ouch | 22:08 |
| racarr | I will get to it before EOD definitely though | 22:09 |
| tsdgeos | awesome | 22:10 |
| racarr | Man I have never had so much fun on a monday | 22:39 |
| racarr | In particular considering I've spent almost the entire day with strange merge conflicts and the like | 22:39 |
| racarr | lol | 22:39 |
| RAOF | :) | 22:44 |
| RAOF | racarr: Re: focus notification: we should move away from having the enum guard value be named foo_arraysize_, possibly to foo_enum_max_? | 22:47 |
| racarr | RAOF: That seems more reasonable | 22:48 |
| racarr | I'm not really sure what it's purpose is in some cases but I didn't want to argue it in thisMP XD | 22:48 |
| RAOF | Actually, now that I think of it - I don't suppose the MirSurfaceFocusState enum could go away entirely? | 22:49 |
| RAOF | Enumerating boolean values is odd :) | 22:50 |
| RAOF | And you've already chosen to have it implicitly convertible to bool (deliberately, I presume?) | 22:51 |
| racarr | RAOF: Hmm | 22:53 |
| racarr | I dunno it's a little unclear because the state API still deals in integer values so | 22:53 |
| racarr | you don't necessarily know as a client library consumer that mir_surface_state_focus can only take on two values | 22:54 |
| racarr | I mean, that would be a really good guess :p but | 22:54 |
| RAOF | We could document that mir_surface_get_state(mir_surface_attrib_focus); returns bool ☺ | 22:54 |
| RAOF | Leaving the internal implementation as-is. | 22:55 |
| racarr | Mm, I wonder if an enum is the preferred way to do that | 22:55 |
| racarr | over using a comment though | 22:55 |
| robert_ancell | RAOF, have you seen http://pad.ubuntu.com/xubuntu-mir? | 22:55 |
| RAOF | robert_ancell: I suspect I've seen all the bugs on there, but I hadn't seen the pad itself; checking. | 22:56 |
| racarr | RAOF: Also strange requirements from 3d headtracking displays may force us to add mir_surface_quasifocused in 2018 | 22:56 |
| racarr | :p | 22:56 |
| robert_ancell | RAOF, yeah, can you just double check we have bugs against everything. It would be good to add bug links so we catch them all | 22:56 |
| RAOF | racarr: Actually, that's a reasonable point; it's entirely possible that we'll want to do gaze-tracking focusish in the not-too-distant future (I, for one, would love it); an enum it is. | 22:57 |
| RAOF | racarr: Or, probably, a bitfield, but we can transparently upgrade the unfocused/focused enum to a bitfield without changing API. | 22:58 |
| racarr | RAOF: Mm ok sounds good | 23:01 |
| RAOF | racarr: For explicitlness' sake, can you add an “= 0” to mir_surface_unfocused's definition? | 23:02 |
| racarr | RAOF: Ok yeah | 23:03 |
| racarr | I think I need to remove IPC semaphore too | 23:03 |
| robert_ancell | RAOF, can you triage bug 1210316 | 23:14 |
| ubot5 | bug 1210316 in xserver-xorg-video-ati (Ubuntu) "x crashes with radeon hd7850 video card with error /usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol: exaGetPixmapDriverPrivate" [Critical,Triaged] https://launchpad.net/bugs/1210316 | 23:14 |
| RAOF | Oooh, that's probably why. | 23:22 |
| RAOF | robert_ancell: Do you think anyone would be interested in read-only XRANDR support? If so, I can push it to staging. | 23:23 |
| robert_ancell | RAOF, in XMir? | 23:23 |
| RAOF | Yeah | 23:23 |
| robert_ancell | RAOF, yeah, staging should be safe for testing since no-one should be running it. I suspect XRANDR clients might get confused if they can't apply changes? | 23:24 |
| RAOF | Dunno. | 23:24 |
| RAOF | XRandR calls are allowed to fail for pretty much no reason at all. | 23:25 |
| robert_ancell | RAOF, so clients just listen for events and attempt to apply changes and don't really care if they fail? | 23:26 |
| robert_ancell | RAOF, also, currently clients just get a fixed config back, right? | 23:26 |
| RAOF | Well, clients care if they fail, but they need to handle the case that they fail. | 23:28 |
| RAOF | Yeah. Clients get whatever Mir set up. | 23:28 |
| racarr | RAOF: pushed the changes you suggested (plus removed ipc_semaphore.h) | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!