| robotfuel | kgunn: it doesn't save that information in the logs | 00:03 |
|---|---|---|
| robotfuel | kgunn: I will rerun the tests to get that info, it goes to stdout | 00:03 |
| robotfuel | kgunn: I don't notice any tearing, but open arena is always moving it would be hard to see | 00:06 |
| robotfuel | kgunn: I'll watch again and get back to you. brb | 00:07 |
| robotfuel | kgunn: openarena runs too fast to tell if it's tearing | 00:27 |
| Sarvatt | run non xmir openarena with vblank_mode=0 openarena? | 00:31 |
| robotfuel | xorg had a segfault on intel with xmir http://10.97.2.10:8080/job/utah-xmir-troubleshooting/ws/results/Xorg.0.log | 00:31 |
| tvoss_ | RAOF, ping | 05:08 |
| sgx1 | hi. now there're two mir PPAs, which one to use? installing_prebuilt_mir_on_pc.md suggests using system-compositor-testing ppa. but i find packages in Mir staging ppa are newer. | 05:27 |
| tvoss_ | sgx1, yup, but staging revs too fast and system-compositor-testing is the save alternative so far :) | 05:28 |
| tvoss_ | sgx1, we cherry-pick over to system-compositor-testing on a regular basis | 05:28 |
| RAOF | tvoss_: Pong. | 05:28 |
| robert_ancell | RAOF, duflu, alf__, hikiko, racarr, kdub, kgunn, meeting time! | 05:58 |
| robert_ancell | thomi too! | 05:58 |
| hikiko | hi | 05:58 |
| hikiko | joining in a sec robert_ancell | 05:59 |
| kgunn | kdub: you around? | 06:06 |
| tvoss_ | didrocks, ping | 06:25 |
| didrocks | tvoss_: pong | 06:29 |
| tvoss_ | didrocks, got a branch for you to test on the ati machine :) | 06:29 |
| didrocks | tvoss_: yeah! there are two ways: building it locally (but I don't have any i386 machines ready) | 06:30 |
| didrocks | tvoss_: or pushing that to the ppa manually | 06:30 |
| didrocks | I'm in favor of #2 | 06:30 |
| tvoss_ | didrocks, so what do you need from me? just the branch? | 06:31 |
| didrocks | tvoss_: yep, the branch is fine | 06:31 |
| tvoss_ | didrocks, lp: ~thomas-voss/mir/default-to-null-input-by-default | 06:32 |
| didrocks | tvoss_: branching, pushing, building | 06:32 |
| didrocks | then will rerun | 06:32 |
| tvoss_ | didrocks, ack | 06:32 |
| tvoss_ | didrocks, status? | 07:05 |
| tvoss_ | didrocks, I need to step out at 10 my time (in ~55 minute) to run some errands | 07:06 |
| didrocks | tvoss_: well, it's building in the ppa right now | 07:06 |
| didrocks | tvoss_: and as there is an ABI break, regarding to latest version, I have to rebuild u-s-c as well | 07:06 |
| didrocks | so waiting for mir to publish first | 07:07 |
| tvoss_ | didrocks, ack ... which ppa are you using? | 07:07 |
| didrocks | tvoss_: daily-build-next | 07:09 |
| tvoss_ | didrocks, ack and thx | 07:09 |
| didrocks | yw ;) | 07:09 |
| didrocks | will keep you posted | 07:09 |
| tvoss_ | didrocks, stepping out now, back in ~1 hour | 07:38 |
| didrocks | tvoss_: ok, u-s-c is building now | 07:38 |
| tvoss_ | didrocks, ack | 07:38 |
| dholbach | good morning | 07:46 |
| mlankhorst | didrocks: ping | 08:03 |
| didrocks | mlankhorst: pong | 08:05 |
| mlankhorst | didrocks: on that non-working machine, could you post the full logs from /var/log/lightdm and full dmesg? | 08:05 |
| didrocks | mlankhorst: I are running a rerun from tvoss first | 08:06 |
| didrocks | mlankhorst: so wait for it I would say ;) | 08:06 |
| didrocks | currently running, so shold have results soon | 08:06 |
| mlankhorst | yeah my own test machine fails with std::exception::what: Failed to set the current VT mode | 08:07 |
| * mlankhorst doesn't have plymouth or splash enabled, might be why | 08:07 | |
| mlankhorst | hm seems to be https://bugs.launchpad.net/mir/+bug/1195509 | 08:13 |
| ubot5 | Launchpad bug 1195509 in Unity System Compositor "System compositor fails to start - Failed to set the current VT mode: Input/output error (5)" [Critical,Triaged] | 08:13 |
| === dholbach_ is now known as dholbach | ||
| didrocks | mlankhorst: do you start it from lightdm? | 08:31 |
| mlankhorst | yeah | 08:31 |
| didrocks | weird | 08:31 |
| === seb128_ is now known as seb128 | ||
| mlankhorst | does lightdm switch to the console before letting unity-system-compositor configure it? | 08:33 |
| mlankhorst | and can I use strace on ust somehow, to figure this one out | 08:37 |
| didrocks | mlankhorst: I can answer on the second one | 08:37 |
| didrocks | mlankhorst: /etc/lightdm/lightdm.conf.d/ | 08:38 |
| didrocks | you have a file shipped by usc | 08:38 |
| didrocks | you can put a command | 08:38 |
| didrocks | like: system-compositor=strace unity-system-compositor | 08:38 |
| mlankhorst | yeah | 08:40 |
| mlankhorst | hm of course that works.. | 08:40 |
| mlankhorst | didrocks: who spawns the xserver, unity-system-compositor or lightdm? | 08:49 |
| didrocks | mlankhorst: ligthdm AFAIK | 08:51 |
| didrocks | but I can be wrong | 08:52 |
| mlankhorst | hm seems to be a plymouth race :P | 08:54 |
| tvoss | didrocks, ping | 09:38 |
| didrocks | tvoss: wb! | 09:38 |
| didrocks | tvoss: so passed \o/ | 09:38 |
| didrocks | tvoss: please file a MP ;) | 09:39 |
| didrocks | (I'm still rerunning to ensure we don't get any race, but should be good) | 09:39 |
| tvoss | didrocks, \o/ | 09:40 |
| tvoss | RAOF, any more insight? any handover tasks I should look into? | 09:40 |
| mlankhorst | looks like it's still failing locally, I'll try to figure out why :p | 09:40 |
| RAOF | tvoss: I'm still hooking up exposing the buffer id to the client. Once that's done, I'll instrument everything and give it a run. | 09:41 |
| tvoss | RAOF, awesome, thank you :) | 09:41 |
| tvoss | greyback, ping | 09:43 |
| tvoss | alf__, didrocks https://code.launchpad.net/~thomas-voss/mir/default-to-null-input-by-default/+merge/176638 | 09:45 |
| greyback | tvoss: pong | 09:48 |
| alf__ | tvoss: what's the driving force behind default-to-null-input-by-default ? | 10:00 |
| tvoss | alf__, first: it saves us a bunch of wakeups per second in the system compositor scenario. Second: it solves issues with booting up on certain ATI HW where creating a bo for the hw cursor results in an exception | 10:01 |
| alf__ | tvoss: can't the system compositor turn this off, instead of making it the default? | 10:02 |
| tvoss | alf__, possible, too | 10:02 |
| didrocks | tvoss: should I rebuild Mir without your patch and be ready to take the new system-compositor in? | 10:20 |
| didrocks | tvoss: ran 4 times, with full test suit and pass | 10:20 |
| mlankhorst | I think I understand the bug, but not the fix yet :P | 10:23 |
| tvoss | mlankhorst, which one exactly? the ati one? | 10:23 |
| mlankhorst | https://bugs.launchpad.net/mir/+bug/1195509 | 10:23 |
| ubot5 | Launchpad bug 1195509 in Unity System Compositor "System compositor fails to start - Failed to set the current VT mode: Input/output error (5)" [Critical,Triaged] | 10:23 |
| tvoss | mlankhorst, \o/ I have been looking at that, too | 10:23 |
| tvoss | didrocks, yup, but might take me some time, an hour or so | 10:23 |
| didrocks | tvoss: ok, I can rebuild Mir meanwhile | 10:24 |
| didrocks | to not loose time | 10:24 |
| didrocks | tvoss: or will you have Mir changes? | 10:24 |
| didrocks | (to expose an API or so on…) | 10:24 |
| mlankhorst | tvoss: well it's a dumb bug | 10:24 |
| tvoss | didrocks, most likely no mir changes, at least I hope so | 10:25 |
| didrocks | tvoss: ok, let me do a preventive build then :) | 10:25 |
| RAOF | mlankhorst: Something involving plymouth is a dumb bug? Say it ain't so! | 10:27 |
| mlankhorst | I don't get why plymouth is killed by lightdm *after* xserver started.. | 10:28 |
| mlankhorst | or mir | 10:28 |
| didrocks | mlankhorst: I think for smooth transitioning? (just a guess) | 10:31 |
| mlankhorst | anyway the io comes from the TTY having hung up | 10:35 |
| RAOF | No, that shouldn't be it. | 10:35 |
| mlankhorst | I'm guessing it is being opened too early, while plymouth still has control over it | 10:35 |
| RAOF | mlankhorst: How's that mir-plymouth branch goin? :) | 10:36 |
| mlankhorst | RAOF: blocking on the same thing as I want to block Xmir for, the separate thread is ugly | 10:36 |
| RAOF | mlankhorst: Indeed it is; bug tvoss about that :) | 10:37 |
| mlankhorst | but I did a control WARN_ON(1), and I did get that unity-system-compositor had a WARN_ONn hung_up_tty_ioctl+0x27/0x50 | 10:37 |
| mlankhorst | so it looks like this is the issue here | 10:38 |
| tvoss | mlankhorst, RAOF happy to adjust the separate thread, but can we fix the bug without me on the critical path? | 10:38 |
| mlankhorst | tvoss: erm sure, just postpone opening the fd or patch lightdm some more | 10:39 |
| tvoss | mlankhorst, cool | 10:39 |
| mlankhorst | I can do the latter | 10:39 |
| RAOF | tvoss: Yeah, it's fixable. It's just that there wouldn't be an opportunity for this bug to exist if we weren't doing the stupidly fragile plymouth dance. | 10:39 |
| tvoss | RAOF, help me understand, what is the fragile plymouth dance? :) | 10:40 |
| mlankhorst | tty handover from plymouth | 10:40 |
| RAOF | Plymouth starts, grabs the display. We then ask plymouth to die but hide its dying, and then X starts up, grabs the display, and takes the contents of the framebuffer. | 10:41 |
| mlankhorst | well it looks like a workaround here might be to use VT_SETACTIVE instead of VT_ACTIVATE | 10:42 |
| mlankhorst | erm VT_SETACTIVATE * | 10:42 |
| * duflu goes to find food | 10:43 | |
| * tvoss loves those subtle differences for VT_* ;) | 10:43 | |
| tvoss | duflu, good luck | 10:43 |
| * duflu rolls eyes at those identifiers | 10:43 | |
| mlankhorst | we'd snatch the terminal away from plymouth, if it's still active :P | 10:43 |
| tvoss | RAOF, so in an ideal world, plymouth would just be a mir client, right? | 10:43 |
| RAOF | Correct! | 10:43 |
| mlankhorst | meh lets see if it works.. | 10:44 |
| RAOF | mlankhorst: Can we just nuke the whole VT subsystem? | 10:44 |
| tvoss | RAOF, would disconnecting from the controlling tty for Mir help here? | 10:48 |
| mlankhorst | lets see if this works... | 10:49 |
| mlankhorst | tvoss: when touching the modes of the controlling tty, you want to not be attached to the tty? | 10:49 |
| tvoss | mlankhorst, random idea :) | 10:49 |
| mlankhorst | I guess not touching the tty at all could work though :p | 10:52 |
| * tvoss mutters something about process group leaders and setsid | 10:53 | |
| tvoss | alf__, I set the status of https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367 | 11:05 |
| tvoss | back to needs review | 11:05 |
| tvoss | I'm quite sure I can fix the heisenbug :) | 11:05 |
| mlankhorst | tvoss: actually it might need setsid for this to work correctly.. | 11:09 |
| mlankhorst | is unity-system-compositor run as root? | 11:11 |
| tvoss | mlankhorst, I think so | 11:11 |
| alf__ | tvoss: as you like, I figured that since this MP was not related to the problem that cause the failure, we might as well merge it | 11:12 |
| RAOF | mlankhorst: Yes, u-s-c is run as root. | 11:13 |
| mlankhorst | blergh, looks like we need to do setpgid, setsid, before opening console | 11:13 |
| mlankhorst | after that when /dev/tty is opened it automatically becomes ours, or in the worst case we need to claim it for ourselves | 11:14 |
| tvoss | alf__, fair point, I will repropose under a different name | 11:15 |
| mlankhorst | I now know more about job control than I cared for :p | 11:25 |
| RAOF | tvoss: I'm off to bed; I've not yet managed to run a fully instrumented stack, so I'm not sure what I'll find. | 11:41 |
| tvoss | RAOF, ack, thanks | 11:44 |
| mlankhorst | meh got a fix, I think | 11:45 |
| mlankhorst | http://paste.debian.net/18230/ | 11:46 |
| mlankhorst | the TIOCSCTTY needs to be uncommented if the setsid is not enough.. | 11:47 |
| mlankhorst | but it's kind of rude since it means snatching the tty away from someone else :p | 11:50 |
| tvoss | mlankhorst, well, that's the consequence of our plymouth dance, right? :) | 11:54 |
| mlankhorst | I guess so, what is the sleep for btw | 11:54 |
| mlankhorst | it seems to work fine without | 11:54 |
| tvoss | mlankhorst, didrocks was seeing some races iirc :) didrocks ^? | 11:55 |
| mlankhorst | apart from some gpu stall everything works fine I guess | 11:58 |
| mlankhorst | and the stall might be related to changes in my own tree | 11:58 |
| mlankhorst | meh the remainder seems to be related to my card being flaky | 12:02 |
| tvoss | mlankhorst, \o/ | 12:05 |
| tvoss | mlankhorst, wanna come up with an mp? | 12:05 |
| mlankhorst | what branch is base? | 12:07 |
| tvoss | mlankhorst, trunk, bzr branch lp:mir | 12:08 |
| mlankhorst | ok | 12:08 |
| mlankhorst | lets see if this works | 12:12 |
| tvoss | alf__, didrocks https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367 | 12:17 |
| mlankhorst | hm, I need a better git-bzr | 12:17 |
| === JoseeAntonioR is now known as jose | ||
| tvoss | mzanetti, could you retrigger CI for https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367 | 12:30 |
| tvoss | ? | 12:30 |
| tvoss | didrocks, you around? | 12:30 |
| mzanetti | tvoss: sure. If you want I can give you permissions to retrigger jobs | 12:30 |
| tvoss | mzanetti, I have, still need to setup my vpn :) | 12:31 |
| tvoss | again :) | 12:31 |
| mzanetti | tvoss: actually, in this case its enough to re-set the MR to "Approved" and Jenkins will pick it up again | 12:31 |
| tvoss | mzanetti, top-state? | 12:32 |
| mzanetti | tvoss: yeah | 12:32 |
| didrocks | tvoss: back now | 12:32 |
| tvoss | didrocks, https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367 | 12:32 |
| tvoss | didrocks, that's not the usc adjustment | 12:33 |
| didrocks | ok, looking for the additional commit | 12:33 |
| didrocks | tvoss: ok, a little bit complex. What I would suggest is that we get the ATI fix first, then, having that running (with the workaround) a couple of day, and then, removing the sleep workaround, thoughts? | 12:35 |
| tvoss | didrocks, not sure I do get you :) the mr I pasted is not connected to the ati issue ;) | 12:36 |
| didrocks | tvoss: right, what I meant is: | 12:36 |
| didrocks | let's not try to remove the race workaround for now | 12:36 |
| didrocks | your fix is to avoid this issue, right? ^ | 12:37 |
| tvoss | didrocks, where do you see that I remove it? | 12:37 |
| tvoss | nope :) | 12:37 |
| mlankhorst | look I don't think that this is ready for universe if it requires a sleep workaround.. | 12:37 |
| tvoss | didrocks, mlankhorst might have a fix for the sleep workaround | 12:37 |
| didrocks | tvoss: ah, I thought the waitpid would help that case as well, but maybe not enough context in the diff and it would be better than I download the whole file :) | 12:37 |
| didrocks | ah good ;) | 12:38 |
| tvoss | didrocks, yeah, this should fix the armhf races | 12:38 |
| didrocks | but I would suggest that we keep the sleep for a couple of days (even if we have the fix) | 12:38 |
| didrocks | to get things flowing | 12:38 |
| didrocks | and then, trying to removing it and testing several rounds | 12:38 |
| tvoss | didrocks, for disabling the input: can we pass additional command-line arguments to usc via lightdm? | 12:39 |
| didrocks | tvoss: it seems to be possible, you just can't use shell expansion or && for instance | 12:40 |
| didrocks | but command --option seems to work | 12:40 |
| didrocks | (as "strace unity-system-compositor" worked) | 12:40 |
| tvoss | didrocks, okay, then you can just pass --enable-input=false to usc :) | 12:41 |
| didrocks | tvoss: this is already implemented? | 12:42 |
| tvoss | didrocks, yup | 12:42 |
| didrocks | hum, grep isn't my friend | 12:42 |
| tvoss | didrocks, usc uses mir's DefaultServerConfiguration, which in turn respects that command-line option | 12:42 |
| didrocks | ah ok ;) | 12:42 |
| tvoss | didrocks, you need to fgrep in mir | 12:43 |
| didrocks | yeah, makes sense | 12:43 |
| tvoss | src/server/default_server_configuration.cpp | 12:43 |
| didrocks | indeed, saw it :) | 12:43 |
| didrocks | tvoss: https://code.launchpad.net/~didrocks/unity-system-compositor/fix-for-ati/+merge/176674 | 12:45 |
| didrocks | I'll then rebuild once in trunk and ensure with multiple test runs it's reliable | 12:45 |
| mlankhorst | and again that needs fixing too :P | 12:46 |
| mlankhorst | https://code.launchpad.net/~mlankhorst/mir/setsid/+merge/176676 | 12:48 |
| tvoss | didrocks, mind filing a bug against usc to make sure that we reenable hw pointer functioanlity shortly? | 12:50 |
| didrocks | tvoss: sure | 12:50 |
| tvoss | didrocks, thx | 12:50 |
| mlankhorst | I don't think papering around it is a good thing though, that bug should be fixed first | 12:51 |
| didrocks | mlankhorst: we have deadlines as well, we can't be idealistic when working on time constraints | 12:51 |
| didrocks | as long as bugs are logged in, I don't think we should hold off | 12:51 |
| didrocks | if we know that the workaround is reliably working | 12:52 |
| mlankhorst | yeah but you want to land a random git snapshot of mesa, some xorg patches and some other stuff and then put mir in universe? | 12:52 |
| didrocks | mlankhorst: mir will be in main I guess | 12:52 |
| didrocks | to be able to build xorg | 12:52 |
| didrocks | as it's a build-dep, right? | 12:52 |
| mlankhorst | yes | 12:52 |
| didrocks | so Mir in main, but not enabled by default | 12:52 |
| didrocks | just a technology snapshot to get people trying it | 12:53 |
| mlankhorst | and if it's in main it means I have to support it, including the mir bits. So open bugs that are not understood become a lot more important to me then.. | 12:53 |
| robotfuel | Does anyone know how I change the resolution in xmir? xrandr doesn't work | 12:54 |
| didrocks | mlankhorst: you're welcome to give a hand to properly resolving them promptly consequently | 12:54 |
| didrocks | tvoss: https://bugs.launchpad.net/mir/+bug/1204505 | 12:54 |
| ubot5 | Launchpad bug 1204505 in Mir "unity-system-compositor needs to have hw pointer functionality enabled back" [Undecided,New] | 12:54 |
| tvoss | didrocks, thx | 12:55 |
| didrocks | tvoss: not sure how you want to prioritize it | 12:55 |
| tvoss | didrocks, not sure yet, put it high, please | 12:55 |
| didrocks | doing so | 12:55 |
| robotfuel | Sarvatt: I tried openarena with vblank_mode=0 in xmir, it still was a lot faster than x | 13:11 |
| tvoss | bregma, ping | 13:12 |
| bregma | tvoss, hi | 13:12 |
| kgunn | tvoss: thank for all your help overnight! | 13:14 |
| tvoss | bregma, I looked into the acceptance tests, input-related ones specifically, and came up with an MP | 13:15 |
| tvoss | https://code.launchpad.net/~thomas-voss/mir/fix_process_waitpid_approach_to_correctly_setup_tracing/+merge/176367 | 13:15 |
| kgunn | robotfuel: if that weird "better on xmir than x" only happening on ati gpu ? or e.g. on my intel i did not see this...i saw a 10% drop | 13:15 |
| tvoss | bregma, it contains a pipe-based cross-process sync appraoch and adds a timeout to wait_for_termination | 13:15 |
| robotfuel | kgunn: yes this is only ati | 13:15 |
| kgunn | robotfuel: wondering if its related to ati video driver | 13:15 |
| bregma | tvoss, will it handle the case where a server child process is waiting for a client child process and the client child process exits without sending a synch message? | 13:16 |
| * kgunn wonders if intel is vsync'ing properly...and ati is unhinge from vsync | 13:16 | |
| robotfuel | kgunn: we also can't to xmir benchmarks at 800x600 until this bug is fixed https://bugs.launchpad.net/mir/+bug/1196239 | 13:16 |
| ubot5 | Launchpad bug 1196239 in Mir "Cannot change display resolution" [Critical,Triaged] | 13:16 |
| robotfuel | kgunn: we can get the default resolution for the monitor though | 13:17 |
| tvoss | robotfuel, that's fine for now | 13:18 |
| kgunn | robotfuel: hmmm & that bug is only on ati as well correct ?...again, i get different #s on my intel when i run 600x800 vs native res, meaning...my intel numbers all look sane | 13:19 |
| robotfuel | kgunn: it might be, intel isn't working for me right now, it has the driver bug | 13:20 |
| robotfuel | kgunn: can you delete xserver-xorg-video-intel package version 2:2.21.9+xmir5870-1~saucy1 from the mir-team/system-compositor-testing ppa? | 13:21 |
| robotfuel | kgunn: the 0~saucy1 driver is suppose to work | 13:22 |
| kgunn | robotfuel: lemme see | 13:23 |
| kgunn | tvoss: so, robotfuel asked for me to roll back intel driver to 0~saucy1....but before i venture off, do you know why raof manually updated it ? do you have some context ? (is this for sna ?) | 13:28 |
| tvoss | kgunn, I actually copied it over, it's the driver with sna enabled | 13:29 |
| tvoss | robotfuel, are you sure that you have the ppa pinned? the driver is working perfectly fine here | 13:29 |
| kgunn | robotfuel: confirmed...its working on mine for past few days as well | 13:31 |
| kgunn | i was tvoss guinea pig & just left it installed | 13:31 |
| robotfuel | tvoss: kgunn https://bugs.launchpad.net/xmir/+bug/1203776 a lot of people have a problem with the 1~saucy driver | 13:42 |
| ubot5 | Launchpad bug 1203776 in XMir "X crashes w/ latest xserver intel driver from System Compositor Testing PPA" [Undecided,New] | 13:42 |
| tvoss | robotfuel, are we sure that those people did pin the ppa correctly? | 13:43 |
| tvoss | robotfuel, can you try the intel driver from staging real quick on the machine? | 13:43 |
| robotfuel | tvoss: I'll try the one from the staging ppa, RAOF's looked at the bug and verified it. | 13:44 |
| tvoss | robotfuel, ack and thx | 13:45 |
| didrocks | tvoss: ok, unity-system-compositor starts and hang (remember that it's with Mir trunk rebuilt from the last couple of hours) | 13:45 |
| didrocks | tvoss: dm_connection_start | 13:45 |
| didrocks | Failed to read header | 13:45 |
| tvoss | didrocks, dm_connection talks to lightdm | 13:46 |
| tvoss | robotfuel, if your issue is fixed with the intel driver, I will copy it over to the testing-ppa | 13:46 |
| tvoss | kgunn, ^ | 13:46 |
| didrocks | tvoss: new xorg-server in distro… | 13:47 |
| didrocks | I bet that's it | 13:47 |
| * didrocks looks at the version | 13:47 | |
| tvoss | argh | 13:47 |
| robotfuel | tvoss: didrocks http://10.97.2.10:8080/job/utah-xmir-troubleshooting/3/artifact/results/dpkg-list.log has the versions of everything installed when the xorg crash happens | 13:49 |
| didrocks | tvoss: yeah, I bet it's the xorg issue | 13:49 |
| didrocks | tvoss: I'll just apt-get source the old one | 13:49 |
| tvoss | didrocks, for the dm_connection thingy? | 13:49 |
| didrocks | and update with it | 13:49 |
| didrocks | tvoss: yeah, it's a consequence | 13:49 |
| didrocks | xorg doesn't have -mir option | 13:50 |
| tvoss | didrocks, ack | 13:50 |
| tvoss | didrocks, ah ... | 13:50 |
| didrocks | so, /me apt-get source, fake a bump changelog and reupload to daily-buid-next ppa | 13:50 |
| didrocks | mlankhorst: would be nice to coordinate with us and not make the whole thing more painful :p | 13:51 |
| kgunn | didrocks: so we're not dead yet, once you update daily-build-next ppa we get another shot at tvoss "disable input" for the ati bug? | 13:53 |
| didrocks | kgunn: right | 13:54 |
| didrocks | kgunn: I have faith, his fix in mir directly worked with multiple runs | 13:54 |
| didrocks | kgunn: I think if the option in unity-system-compositor is correctly wired up, it shouldn't make a difference and should pass as well | 13:54 |
| kgunn | didrocks: that's good news... | 13:54 |
| kgunn | thanks | 13:54 |
| xjunior | Morning edge people | 13:55 |
| didrocks | mlankhorst: actually, it was doko on that one… | 13:57 |
| tvoss | robotfuel, did you install the driver, yet? | 14:00 |
| robotfuel | tvoss: no not yet, I'll do it now. | 14:01 |
| tvoss | robotfuel, ack | 14:02 |
| greyback | alf__: ping | 14:07 |
| robotfuel | tvoss: FYI the drivers in the latest drivers staging ppa failed to build https://launchpad.net/~mir-team/+archive/staging/+packages | 14:10 |
| alf__ | greyback: pong | 14:12 |
| greyback | alf__: hey, the snapshot API is working great, thank you | 14:12 |
| alf__ | greyback: Great news! Thanks for letting me know. | 14:14 |
| greyback | alf__: I've one question however. I grab a snapshot just after the application surface is created, which is a touch too early as I guess the application hasn't drawn to it yet (i.e. I get black snapshot). Would there be a way to detect if an app has actually drawn to it's surface | 14:14 |
| greyback | alf__: this is nothing at all major (for now I just delay snapshot with a timer), but would be nice for later | 14:14 |
| tvoss | greyback, I think we should postpone that discussion until we have cleaned the scenegraph-conglomerat within mir | 14:15 |
| robotfuel | tvoss: the lastest successful build from the staging ppa is already installed on the system. It doesn't work | 14:16 |
| alf__ | greyback: We have such a mechanism internally, but I don't think it is exposed in any way to the shell. | 14:16 |
| greyback | alf__: I see. I'll keep it in mind. I might log a bug for it. Thanks! | 14:22 |
| alf__ | greyback: np | 14:23 |
| robotfuel | tvoss: I have some other intel systems that didn't have an xorg crash | 14:38 |
| robotfuel | tvoss: I am retrying to see if it's a race condition. | 14:38 |
| tvoss | robotfuel, ack | 14:38 |
| robotfuel | kgunn: resolution changes do work on intel, not on radeon. :) | 14:45 |
| kgunn | robotfuel: i am so frustrated with the ati... | 14:46 |
| kgunn | :-/ | 14:46 |
| tvoss | didrocks, status? | 14:59 |
| didrocks | tvoss: 3 runs until now, it's all green | 14:59 |
| robotfuel | tvoss: the xmir crash on intel is race condition | 14:59 |
| didrocks | tvoss: I'm waiting for the 4th to finish | 14:59 |
| tvoss | robotfuel, where? | 14:59 |
| didrocks | to send an email :) | 14:59 |
| tvoss | didrocks, ack and thx | 14:59 |
| didrocks | tvoss: yw! thanks to you! | 14:59 |
| robotfuel | tvoss: https://bugs.launchpad.net/xmir/+bug/1203776 | 15:01 |
| ubot5 | Launchpad bug 1203776 in XMir "X crashes w/ latest xserver intel driver from System Compositor Testing PPA" [Undecided,New] | 15:01 |
| tvoss | robotfuel, no, I meant where in the code ;) | 15:03 |
| robotfuel | tvoss: I haven't looked in to it. | 15:03 |
| tvoss | robotfuel, okay, thx | 15:05 |
| qengho | Hi all. I maintain Chromium browser, and I received a pointer from upstream to a doc about their efforts to abstract some of the display interface. We may find it interesting. https://sites.google.com/a/chromium.org/dev/developers/design-documents/ozone | 15:05 |
| tvoss | qengho, hey there :) | 15:08 |
| qengho | tvoss: yo. | 15:08 |
| tvoss | qengho, I recently read it, quite interesting :) | 15:11 |
| hikiko_ | alf__, revno 881 works better: I see the mouse pointer but I can't move it | 15:12 |
| qengho | tvoss: Thanks. | 15:15 |
| tvoss | qengho, thanks for keeping us posted | 15:16 |
| tvoss | bregma, ping | 16:15 |
| bregma | tvoss, pong | 16:26 |
| tvoss | bregma, so my local testing reveals some issues under valgrind, still trying to digest all of the information | 16:26 |
| bregma | .... | 16:28 |
| tvoss | bregma, thought I would handover, as your mail suggested to me that you are looking into the issue, too | 16:28 |
| bregma | sure | 16:29 |
| === om26er is now known as om26er_afk | ||
| === om26er_afk is now known as om26er | ||
| kdub | kgunn, ping | 17:46 |
| kgunn | kdub: pong | 17:48 |
| racarr | lol...whoops | 18:53 |
| racarr | I just found a unit-test file which is missing from cMakeLists.txt | 18:53 |
| racarr | after spending 5 minutes like oh god how does this compile | 18:53 |
| racarr | do I even understand C++ | 18:53 |
| racarr | what is happening | 18:53 |
| racarr | etc | 18:53 |
| kdub | haha | 18:53 |
| racarr | (missing from CMakeLists in trunk) | 18:54 |
| racarr | for who knows how long | 18:54 |
| racarr | because the API it uses is quite old | 18:54 |
| racarr | thats ok though its a lame test | 18:54 |
| racarr | *makes new branch* | 18:54 |
| racarr | I wonder if I should write a failing test that all our test files are built :p | 18:55 |
| racarr | omg | 19:04 |
| racarr | more dead files | 19:04 |
| racarr | this is embarassing -.- | 19:04 |
| kdub | which tests? | 19:05 |
| racarr | kdub: test_android_input_registrar | 19:08 |
| racarr | and mock_input_configuration.h which it includes | 19:08 |
| kdub | what | 19:08 |
| racarr | its been this way for at least | 19:08 |
| racarr | 3 months | 19:08 |
| racarr | because Ir emember I rebuilt the input configuration | 19:08 |
| racarr | when I still lived at my old place | 19:08 |
| racarr | we could use bzr blame but it's almost certainly my fault so | 19:08 |
| racarr | :p | 19:08 |
| kdub | ah, i thought you said another registrar test that I was sure was working lately :) | 19:09 |
| racarr | I hate using droidinput::Vector | 19:59 |
| racarr | s/hate/have a strong distaste | 19:59 |
| racarr | https://code.launchpad.net/~robertcarr/mir/support-monitor-input-channels/+merge/176775 whee | 20:11 |
| racarr | good news, unity is done | 20:12 |
| racarr | *closes eyes and begins to sleep* | 20:12 |
| racarr | :p | 20:12 |
| kdub | racarr, droidinput::Vector can't be as bad as writing new classes that support android::sp :) | 20:16 |
| racarr | kdub: Ah, android::sp | 20:17 |
| racarr | you know the input stack still isnt the most beautiful code | 20:18 |
| racarr | but we have come a long way since | 20:18 |
| racarr | android::sp in DefaultServerConfiguration | 20:18 |
| racarr | XD | 20:18 |
| kdub | oh yeah, much better now :) | 20:36 |
| kdub | mir on the whole is much better | 20:36 |
| kdub | remember back in the day, when we wrapped std::thread/mutex/chrono with boost? :) | 20:36 |
| racarr | kdub: Oh god | 20:56 |
| racarr | that led to the most fucked up compiler errors. | 20:56 |
| racarr | I just remember, coming on to the Mir team, in the past I had been a perpetual C++ skeptic but I was like | 20:57 |
| racarr | ok well I guess if they are doing C++ carefully and the right way it seems pretty good and well lets try it | 20:57 |
| racarr | then I ran in to some stuff from the std::thread stuff and mir::std and I was just like | 20:57 |
| racarr | oh god.... | 20:57 |
| racarr | Back soon | 21:00 |
| === racarr is now known as racarrlunch | ||
| olli | robert_ancell, ping | 21:24 |
| robert_ancell | olli, hello | 21:27 |
| olli | hey robert_ancell | 21:27 |
| olli | quick q, I am trying to understand the new dashboard gema announced recently | 21:27 |
| olli | from there it looks like we are building u-s-c without running any tests | 21:28 |
| olli | http://91.189.93.67/staging/merger/unity-system-compositor/ | 21:28 |
| olli | kgunn, ^ | 21:29 |
| robert_ancell | olli, u-s-c doesn't have any tests currently | 21:30 |
| olli | robert_ancell, how come, I thought anything mir has tons of tests | 21:30 |
| olli | that's what I keep getting told at least | 21:31 |
| olli | :) | 21:31 |
| robert_ancell | olli, not u-s-c. :( | 21:31 |
| olli | how do we intend to land that in distro if it doesn't have tests | 21:32 |
| === racarrlunch is now known as racarr | ||
| olli | robert_ancell, ^ | 21:35 |
| olli | brb | 21:35 |
| robert_ancell | olli, it doesn't have much code over top of existing Mir so it is quite well tested. We will have integration tests that ensure that the whole stack works together. But yes, it should have some local tests too | 21:37 |
| racarr | because of the structure we use kind of like... | 21:43 |
| racarr | 1. Mir component. 2. default implementation in tree for demo-server and system-compositor | 21:43 |
| racarr | 3. another implementation for unity | 21:43 |
| racarr | I agree USC is really pretty well tested | 21:43 |
| racarr | even if it has no in tree tests | 21:43 |
| olli | robert_ancell, what's the plan to get tests in place | 21:51 |
| robert_ancell | olli, file bugs and prioritize them | 21:54 |
| olli | that's a reaction to my ping but apparently not a long standing plan | 21:55 |
| robert_ancell | kernel panic, please repeat anything directed at me since " robert_ancell, what's the plan to get tests in place" | 21:57 |
| olli | <robert_ancell> olli, file bugs and prioritize them | 21:59 |
| olli | <olli> that's a reaction to my ping but apparently not a long standing plan | 21:59 |
| robert_ancell | olli, the long plan is the same as Mir - new functionality needs new tests. At the moment we have very little functionalty | 22:00 |
| robert_ancell | racarr, regarding https://code.launchpad.net/~robertcarr/mir/session-transactions/+merge/175669 alan is away | 22:17 |
| robert_ancell | this week | 22:17 |
| robert_ancell | So, get a second opinion or you have to wait if you need his response | 22:17 |
| racarr | robert_ancell: Hoping for a second opinion :) | 22:22 |
| racarr | not in the, need someone to approve it sense, but in the actually trying to figure out if its a good idea sense | 22:22 |
| kgunn | thomi: question about http://10.97.2.10:8080/job/mir-saucy-amd64-ci/ | 22:46 |
| kgunn | am i reading that right...are the number of tests dramatically dropping? | 22:47 |
| kgunn | or did they migrate...http://10.97.2.10:8080/job/mir-vm-ci-build/ | 22:48 |
| kgunn | ? | 22:48 |
| * thomi looks | 22:53 | |
| thomi | kgunn: that graph seems odd - I'm sure we don't have 50000 tests :-/ | 22:56 |
| thomi | kgunn: looks like the results are being repeated a bunch of times: http://10.97.2.10:8080/job/mir-saucy-amd64-ci/216/testReport/%28root%29/SurfaceCreation/ | 22:57 |
| robert_ancell | 23 outstanding MPs! We need to land some code here | 23:28 |
| robert_ancell | kdub, can you check if you're happy with https://code.launchpad.net/~afrantzis/mir/rectangle-closed-open/+merge/176348 | 23:29 |
| kdub | robert_ancell, sure | 23:29 |
| kdub | i think i am, just wanted to get the input take on the matter | 23:29 |
| robert_ancell | kdub, also, if you've fixed the issues duflu pointed out https://code.launchpad.net/~kdub/mir/add-pf-query/+merge/176451 can land | 23:31 |
| racarr | greyback: https://code.launchpad.net/~robertcarr/mir/support-monitor-input-channels/+merge/176775 | 23:35 |
| racarr | a present for you | 23:35 |
| greyback | racarr: aww geee, you shouldn't have! | 23:35 |
| racarr | greyback: Don't worry, I left a bag of coal in the Qt scene graph thread so it's balanced | 23:36 |
| greyback | racarr: :) | 23:36 |
| racarr | the impl is a little different than how it was on SF but I think as long as | 23:36 |
| racarr | you are using the surface InputRegioni | 23:36 |
| racarr | int he same way the trap windows were used before | 23:37 |
| racarr | it should work | 23:37 |
| racarr | I even read some QML code | 23:37 |
| greyback | racarr: goodness, you have been busy | 23:39 |
| === qengho_ is now known as qengho | ||
| racarr | greyback: Nah. it's just a carefully crafted illusion | 23:43 |
| racarr | *kicks up feet* | 23:43 |
| racarr | Happy to see your video last night before I went to sleep :) | 23:43 |
| racarr | did you guys get my email to scene graph thread because I didnt get my own email | 23:44 |
| racarr | but normally do... | 23:45 |
| greyback | racarr: it looks like it does all I need. I'll try integrating it tomorrow. Note I'm on holiday Friday, so tomorrow is gonna be busy for me | 23:45 |
| racarr | if it's simple, i.e. surface needs to become a monitor surface and X needs to be hooked up to Y and bla and bla | 23:46 |
| racarr | I have some time | 23:46 |
| racarr | well not tonight probably anyway | 23:47 |
| racarr | but if you cant finish it tomorrow, maybe send me a brain dump if it makes sense andI can try and run with it | 23:47 |
| greyback | racarr: yep, got it. I didn't read it as rough-edged | 23:47 |
| greyback | sure | 23:47 |
| greyback | it's what I'll attempt first thing. As right now, cannot actually interact with apps! | 23:48 |
| racarr | pft | 23:48 |
| racarr | greyback: So we just got it working and now already first thing feature bloat | 23:48 |
| greyback | racarr: XD | 23:48 |
| kdub | ooo android 4.3 | 23:51 |
| racarr | kdub: Oooo | 23:53 |
| kdub | yay, looks like the HAL layer is the same | 23:53 |
| kdub | for graphics | 23:53 |
| kdub | racarr, time to start merging their new input stack! | 23:53 |
| kdub | :P | 23:53 |
| racarr | kdub: I was about 3 second ahead of you there | 23:53 |
| racarr | kdub: "Improved window buffer allocation results in a faster image buffer allocation for your apps, reducing the time taken to start rendering when you create a window." | 23:53 |
| racarr | that ones for you ;) | 23:53 |
| kdub | where did you see that? | 23:54 |
| racarr | kdub: http://developer.android.com/about/versions/jelly-bean.html?43 | 23:54 |
| racarr | Video encoding from a surface | 23:55 |
| racarr | Starting in Android 4.3 you can use a surface as the input to a video encoder. For example, you can now direct a stream from an OpenGL ES surface to the encoder, rather than having to copy between buffers. | 23:55 |
| racarr | "On-screen GPU profiling | 23:55 |
| racarr | " | 23:55 |
| racarr | only new SF stuff | 23:55 |
| kdub | yeah, seems like all new SF stuff | 23:55 |
| racarr | well | 23:55 |
| racarr | and drivers are | 23:55 |
| racarr | open gles 3 now?! | 23:55 |
| kdub | probably just an option though? | 23:56 |
| kdub | lots of new bluetooth hals though | 23:56 |
| RAOF | Why does xmir suddenly infinite loop in xf86DeleteDriver now that I'm trying to debug?! | 23:57 |
| kdub | thank goodness we're not a bluetooth server | 23:57 |
| racarr | kdub: yeah they just say the nexus devices have | 23:58 |
| racarr | opengles3 | 23:58 |
| racarr | I cant even think of one clever thing you could do with mir and opengles3 XD | 23:58 |
| racarr | Im sure its good for clients | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!