| racarr | kgunn: image fails | 00:24 |
|---|---|---|
| racarr | are there older images | 00:25 |
| kgunn | racarr: thanks... rsalveti how far back can we go ? ^ | 00:25 |
| racarr | I have a copy of | 00:25 |
| racarr | july 26th | 00:25 |
| racarr | on my desktop it seems | 00:25 |
| racarr | thats kind of far though XD | 00:26 |
| kgunn | so 12th would be 1 week...and the bug describes it popping up ~2 weeks ago | 00:26 |
| kgunn | racarr: question...is the hwcomposer.h etc matching from the 12th to current ? | 00:27 |
| racarr | no hwcomposer.h on the image | 00:27 |
| racarr | lets check hardare.h though | 00:28 |
| kgunn | racarr: yeah...that's what i meant | 00:28 |
| kgunn | gralloc and fb as well | 00:28 |
| racarr | yep | 00:29 |
| racarr | the same | 00:29 |
| racarr | ok im going to september 26th because | 00:29 |
| racarr | err | 00:29 |
| racarr | uly 26th | 00:29 |
| racarr | because I dont have anything else to do :p | 00:29 |
| racarr | kgunn: maybe check your ~/Downloads/phablet-flash | 00:31 |
| racarr | for images? | 00:31 |
| racarr | though | 00:31 |
| racarr | i e dont have the images elsewhere | 00:31 |
| kgunn | racarr: will do | 00:31 |
| racarr | then bisecting probably ont help much | 00:31 |
| kgunn | also...as you're building, check the ubuntu/hybris/hybris/include/android/hardware/ and see how those headers compare | 00:32 |
| kgunn | 26th vs current | 00:32 |
| racarr | ubuntu/hybrys/hybris/hat | 00:34 |
| racarr | /what? | 00:34 |
| kgunn | racarr: i have a jul 25th :) | 00:34 |
| racarr | I have been looking in /usr/include/android | 00:34 |
| kgunn | oops...nvmd...i was looking in source i downloaded | 00:35 |
| kgunn | that's where they are before image creation | 00:35 |
| racarr | XD | 00:35 |
| kgunn | ./ubuntu/hybris/hybris/include/android/hardware/fb.h | 00:35 |
| kgunn | etc | 00:35 |
| racarr | thats a hell of a path | 00:35 |
| racarr | I realized | 00:35 |
| racarr | e can rule in our out the headers | 00:35 |
| racarr | in an easy ay | 00:35 |
| racarr | well that whole theory | 00:36 |
| racarr | did surface flinger change? | 00:36 |
| racarr | I guess that doesnt necessarily rule it out | 00:36 |
| kgunn | whathcya mean? | 00:36 |
| racarr | I mean we have this theory that libhardware changed | 00:37 |
| racarr | and it broke mir because mir has the static in tree headers | 00:37 |
| racarr | but if surface flinger didn't change | 00:37 |
| racarr | that seems unlikely | 00:37 |
| kgunn | racarr: right...but isn't it truly in tree for surface flinger (e.g. he's not gonna get headers outta sync) | 00:42 |
| kgunn | since its all just part of android | 00:42 |
| racarr | kgunn: Right I am just saying if e literally haven't updated | 00:46 |
| racarr | the surfaceflinger binary | 00:46 |
| racarr | havent tested this image yet but want to go get pizza before the bakery closes | 00:52 |
| racarr | back soon | 00:52 |
| kgunn | racarr: actually....i think i just found a jul 29 & aug 9 images | 00:53 |
| racarr | I am trying to build mir on this image...but | 00:54 |
| racarr | build deps are pulling in a hybris upgrade | 00:54 |
| racarr | so it would be not so surprising if it didn't work? | 00:54 |
| racarr | ghsdflKSDfljLKsdgjldkfjglkdjglkejrg;lakerjgl;kejrgt | 00:55 |
| racarr | just a little keyboard mashing :p | 00:55 |
| racarr | brb pizza | 00:55 |
| RAOF | Ah, yes. | 01:09 |
| RAOF | It's important not to leak fds. | 01:09 |
| RAOF | Huh. Something's broken in our resource cache it seems. | 01:14 |
| racarr | back | 01:32 |
| kgunn | racarr: dont we rebuild surfaceflinger from source everytime ? (i thot we built the whole android file system...for what we have source for) | 01:35 |
| kgunn | stepping out...biab | 01:35 |
| racarr | kgunn: yeah I guess its probably never the same | 01:37 |
| kgunn | racarr: just comparing bins of libsurfflinger they are diff between jul 25 & latest | 01:37 |
| kgunn | but not surprising | 01:37 |
| kgunn | ok...really stepping out | 01:37 |
| duflu | racarr: is surface flinger relevant to the Nexus4 bug? We intentionally disable it to run Mir (usually) | 01:41 |
| racarr | kgunn: july 26th works! | 01:45 |
| racarr | duflu: No but one of the theories is that there is a libhardware mismatch | 01:45 |
| racarr | but I didn't relize we rebuilt surface flinger everytime | 01:45 |
| duflu | I see | 01:45 |
| racarr | duflu: Want to check your ~/Downloads/phablet-flash and see if you have any images beteen | 01:46 |
| racarr | july 26th and august 18th | 01:46 |
| racarr | and can verify mir orks/doesn't work on them | 01:46 |
| racarr | bisecting ;) | 01:46 |
| racarr | but I am out of images | 01:46 |
| racarr | err august 12th sorry | 01:46 |
| racarr | ricmm: rsalveti: Any way we can get images from before august 12th | 01:47 |
| duflu | racarr: Only July 26th (works for me I think) and August 8th (broken) | 01:48 |
| racarr | August 8th broken. Awesome | 01:49 |
| racarr | kgunn: ^ | 01:49 |
| duflu | racarr: At least that appears to be the latest one I have. And the latest broke my N4 | 01:50 |
| duflu | Though surely we can get image dates/versions from the devices? | 01:50 |
| racarr | duflu: The problem right now is cdimages.ubuntu.com | 01:51 |
| racarr | only has back to august 12th :p | 01:51 |
| racarr | so I am trying to bisect | 01:51 |
| duflu | racarr: Yeah Albert logged the bug on 13th a few days after he first mentioned it. Because it took me a few days to upgrade and confirm | 01:51 |
| racarr | but the range is uly 26th to august 8th now | 01:51 |
| racarr | but there are no images | 01:52 |
| racarr | inbeteen | 01:52 |
| racarr | ween | 01:52 |
| racarr | Spill on keyboard:( | 01:52 |
| duflu | Pork and beans? | 01:52 |
| duflu | Argh | 01:52 |
| duflu | That would be weezer | 01:52 |
| duflu | I suck | 01:52 |
| racarr | I guess I will start | 01:58 |
| racarr | reading changeloads | 01:58 |
| duflu | racarr: Actually 20130808 may not be accurate. The download date for that was 20130813 and I remember I did an update immediately after | 01:58 |
| duflu | Will have to reflash it without updates to confirm | 01:59 |
| racarr | Ah! thanks. | 01:59 |
| racarr | lxc-android-config (0.67) saucy; urgency=low | 01:59 |
| racarr | * allow devices that use EFS as label for the factory partition to mount it | 01:59 |
| racarr | under /efs instead of /factory | 01:59 |
| racarr | that means anything | 01:59 |
| racarr | -- Oliver Grawert <ogra@ubuntu.com> Sun, 04 Aug 2013 12:24:23 +0200 | 02:00 |
| racarr | I wonder if | 02:00 |
| racarr | I have nothing in /factory on the working image so probably not | 02:00 |
| racarr | I dont know what a /factory is though | 02:00 |
| racarr | im going to bisect | 02:00 |
| racarr | lxc-android-config | 02:00 |
| racarr | because permissions are suspect | 02:01 |
| racarr | oh I can't really do that as easily as I want to | 02:01 |
| racarr | ok I upgraded lxc-android-config | 02:03 |
| racarr | and it still works | 02:03 |
| racarr | im going to upgrade packages one at a time lol | 02:03 |
| racarr | that was kind of silly :p not even sure what to try next | 02:05 |
| racarr | no hybris updates | 02:06 |
| duflu | N4 sez: Not enough charge to turn on yet. This seems to happen a lot | 02:06 |
| racarr | lets upgrade lxc | 02:07 |
| racarr | duflu: Happens to me a lot too :( and you can | 02:07 |
| racarr | use more poer than you get off low power USB compiling | 02:08 |
| racarr | mir | 02:08 |
| duflu | racarr: Yeah I put it on mains for a while | 02:08 |
| * duflu wonders if the USB 3 port would have more power than USB 2 | 02:09 | |
| racarr | Maybe | 02:09 |
| racarr | not lxc! let's upgrade apparmor | 02:11 |
| racarr | im staring at a list of like 200 packages trying to pick ones that could be relevant lol | 02:11 |
| duflu | racarr: Maybe consider those that Mir depends on | 02:13 |
| racarr | duflu: Mm. should just start with that | 02:16 |
| racarr | all the build deps | 02:21 |
| racarr | are newest version | 02:21 |
| racarr | as are the dependencies | 02:22 |
| racarr | except or | 02:22 |
| racarr | multiarch support | 02:22 |
| racarr | *tests* | 02:22 |
| duflu | racarr: phablet-flash has no options to specify an image file(s) any more. Any clue? | 02:24 |
| racarr | duflu: You have to use clockwork mod | 02:24 |
| racarr | duflu: You flash the armel+dev first then the armhf | 02:24 |
| duflu | Great. Later then | 02:24 |
| racarr | you have to use adb push file /sdcard/ | 02:24 |
| racarr | instead of | 02:24 |
| racarr | /sdcard | 02:24 |
| racarr | or it ust silently fails ater taking | 02:24 |
| racarr | forever | 02:24 |
| racarr | lol | 02:24 |
| racarr | aw not multiarch support either | 02:25 |
| RAOF | Grr overlapping outputs. | 02:28 |
| racarr | ok I think I narrowed it don to a set of 20 packages | 02:34 |
| racarr | is there an easy way to reverse my last | 02:35 |
| racarr | apt transaction | 02:35 |
| racarr | http://pastebin.ubuntu.com/6004993/ | 02:36 |
| racarr | something in here killed it' | 02:36 |
| racarr | http://pastebin.ubuntu.com/6004994/ | 02:37 |
| racarr | this is suspiscious | 02:37 |
| racarr | reverting back to working image to narrow the list | 02:44 |
| racarr | Setting up initramfs-tools-ubuntu-touch (0.34) ... | 02:45 |
| racarr | seems sort of sketchy | 02:45 |
| racarr | compared to everything else at least | 02:45 |
| smspillaz | racarr: arrrround? | 03:21 |
| racarr | smspillaz: Enthusiastically! | 03:27 |
| === chihchun_afk is now known as chihchun | ||
| kgunn | racarr: you're awsome...so down to 20 packages, somewhere between jul 26 & aug 8 | 03:33 |
| racarr | kgunn: Actually just got a working system again and clicking, so more like 19 packages lol | 03:35 |
| racarr | really only like 4 or 5 that seem reasonable we should know super soon | 03:35 |
| kgunn | racarr: cool | 03:36 |
| smspillaz | duflu: so I don't know if something I'm seeing is a bug in the mir buffer swapper or a bug in my code | 03:37 |
| kgunn | duflu: ping | 03:37 |
| smspillaz | duflu: basically if I do draw1 -> swap1 -> draw2 -> swap2 -> draw3 -> swap3 | 03:38 |
| smspillaz | I seem to see something like | 03:38 |
| smspillaz | after swap1 : nothing after swap2 : draw1 after swap3: draw2 | 03:38 |
| smspillaz | (using mir_surface_swap_buffers directly) | 03:38 |
| duflu | smspillaz: Do you have a very recent server? That was probably fixed in lp:mir r955 | 03:39 |
| smspillaz | duflu: bzr pulled as of yesterday | 03:39 |
| duflu | kgunn: Hi | 03:39 |
| duflu | smspillaz: Yeah that's new enough | 03:40 |
| smspillaz | hmm ok I'll try again | 03:40 |
| smspillaz | maybe I was just an idiot and forgot to set my path right or something last night | 03:40 |
| duflu | smspillaz: For manual testing that kind of thing I use fingerpaint (in which single clicks generate single swaps and should generate immediate output) | 03:41 |
| duflu | Though we have automated tests for it of course | 03:41 |
| smspillaz | ah you know what | 03:41 |
| smspillaz | it could be that stupid thing with sudo not working with LD_LIBRARY_PATH | 03:41 |
| duflu | kgunn: pong? | 03:41 |
| smspillaz | well not stupid, but a gotcha nonetheless | 03:41 |
| smspillaz | so I was probably still running the one in /usr/bin | 03:42 |
| duflu | smspillaz: Yeah you have to set it after sudo | 03:42 |
| smspillaz | you guys really need something like weston-launch | 03:42 |
| duflu | smspillaz: You mean a dumb and simple shell? | 03:42 |
| smspillaz | duflu: not really. Its a setuid thing that talks to pam to get the invoking env, handles all of the vt switching and drmSetMaster/drmDropMaster stuff and then runs weston as user | 03:44 |
| duflu | smspillaz: Oh right. I have thought about similar | 03:44 |
| duflu | Someone just has to do it | 03:44 |
| smspillaz | lol | 03:44 |
| smspillaz | it makes life a lot easier :) | 03:45 |
| racarr | smspillaz: Ill take care of it on Yotday, the imaginary day I just invented inbetween | 03:45 |
| racarr | now and featufre freeze | 03:45 |
| racarr | :p | 03:45 |
| smspillaz | though admittedly not as useful anymore because logind no longer allows arbitrary processes other than init to spawn new sessions | 03:45 |
| smspillaz | so it has to start on the same vt you launched it on as opposed to starting on a new one | 03:46 |
| RAOF | As long as you don't want VT switching you should be able to run mir_demo_server_shell as your user directly. | 03:46 |
| smspillaz | RAOF: don't you need root for input? | 03:47 |
| smspillaz | I seem to recall that's what half of what weston-launch was about | 03:47 |
| RAOF | sudo chown smspillaz /dev/input/**/* | 03:47 |
| smspillaz | or maybe that was to do with vt-switching and input | 03:47 |
| smspillaz | RAOF: :/ | 03:48 |
| RAOF | smspillaz: Hey, it's harmless¹ | 03:48 |
| RAOF | ¹: As long as you trust everything on your box | 03:48 |
| smspillaz | I guess my alternative solution of doing source /home/smspillaz/.bashrc was probably not better | 03:49 |
| smspillaz | (so that I didn't have to re-type every bloody path again) | 03:49 |
| racarr | Nooooooooooooooooooooooooooooooooo | 03:50 |
| racarr | bisection failed | 03:50 |
| racarr | life | 03:50 |
| racarr | no | 03:50 |
| racarr | just bisection | 03:50 |
| smspillaz | duflu: :/ I'm still getting the one-frame lag | 03:57 |
| smspillaz | (correct paths and all) | 03:57 |
| racarr | err | 03:59 |
| racarr | ...I retract my err | 04:00 |
| smspillaz | though oddly its not happening on the demo clients which use mir_surface_swap_buffers_sync!?! | 04:01 |
| RAOF | Hrm | 04:02 |
| smspillaz | attack of the threads! | 04:03 |
| duflu | smspillaz: Not sure then. We have automated and easily manual testing of this issue. If you can figure out the scenario exactly that would be helpful | 04:06 |
| smspillaz | duflu: I'm just doing a dump of the image surface to a png to figure out what's going on for now | 04:07 |
| smspillaz | reeeeecompiling | 04:07 |
| kgunn | racarr: bisection failed as in ...you added everything back one by one to a failing image that no longer fails but actually boots with unity-mir ? | 04:12 |
| racarr | kgunn: I think I made a istake in thinking I hd found a broken set of packges | 04:12 |
| racarr | in that it just didnt ork once | 04:12 |
| racarr | maybe I didnt use sudo and forgot because adb history was fucked up or something | 04:12 |
| racarr | I dunno | 04:12 |
| racarr | no I am still on a orking images | 04:12 |
| racarr | and adding more and more packages | 04:12 |
| racarr | about 20 at a time then rebooting and testing | 04:12 |
| racarr | lol | 04:13 |
| racarr | this last one pulls in a bunch of stuff so I have a feeling this will break it but then to bisect this smaller list I need to go all the way back | 04:13 |
| racarr | and reflash | 04:13 |
| racarr | ubuntu-touch-generic-initrd ubuntu-touch-session | 04:14 |
| racarr | these are the most suspsicious packages that I havent ruled out yet | 04:14 |
| racarr | all the mir dependencies and build dependencies | 04:14 |
| racarr | are ruled out | 04:14 |
| kgunn | racarr: can you pastebin the remaining packages ? | 04:23 |
| kgunn | just updating the bug | 04:24 |
| robert_ancell | thomi, is jenkins screwed up again? (https://jenkins.qa.ubuntu.com/job/lightdm-saucy-amd64-ci/85/console) | 04:24 |
| robert_ancell | and http://s-jenkins:8080/job/lightdm-ci/168/ | 04:24 |
| kgunn | just in case you don't find the offender | 04:24 |
| thomi | it wouldn't surprise me, let me see | 04:24 |
| racarr | kgunn: http://pastebin.ubuntu.com/6005189/ | 04:24 |
| racarr | almost through a bunch though | 04:24 |
| thomi | robert_ancell: the public jenkins has been up and down all day today | 04:25 |
| thomi | robert_ancell: private jenkins should be working though | 04:25 |
| robert_ancell | thomi, also, do you happen to know who I can poke to make a PPA have a high priority? | 04:25 |
| thomi | robert_ancell: #launchpad-ops | 04:26 |
| olli_ | robert_ancell, rcimm & rsalveti | 04:26 |
| racarr | kgunn: http://pastebin.ubuntu.com/6005191/ | 04:26 |
| racarr | I ust ran mir succesfully | 04:26 |
| racarr | after a reboot | 04:26 |
| racarr | and those are the only remaining packages | 04:26 |
| racarr | in upgrade | 04:26 |
| racarr | going to eat some ice cream then come back to it | 04:26 |
| robert_ancell | ricmm, rsalveti, you can bump PPA priorities? Can you set ppa:mir-team/qa-testing to the same priority as ppa:mir-team/staging? | 04:27 |
| thomi | robert_ancell: you mean build priority in the lp build queue, right? | 04:27 |
| racarr | going to eat icecream and revisit | 04:27 |
| racarr | oh | 04:28 |
| racarr | wow | 04:28 |
| robert_ancell | thomi, yeah | 04:28 |
| racarr | im going around in workspace switching loops | 04:28 |
| thomi | robert_ancell: I thought so, I've always had to ask launchpad people to tweak that for me, but maybe others have more permissons than I do | 04:28 |
| kgunn | racarr: icecream can only help | 04:29 |
| smspillaz | kgunn: so I'm working at the australian election and our counting how-to guide give the example of replacing the candidates name with "ice cream" | 04:40 |
| smspillaz | as an example of an informal vote | 04:40 |
| smspillaz | I really don't know who or why somebody would want to vote for ice cream | 04:41 |
| racarr | so close | 04:42 |
| racarr | ps daily show had coverage of australlian elections it as hilarious | 04:42 |
| smspillaz | racarr: I saw that! | 04:42 |
| smspillaz | ahh good ol' cameron diaz | 04:42 |
| racarr | does anyone have time to revie client-focus-notifications while I am still awake? | 04:44 |
| racarr | libopenobex1 libpam-systemd libpixman-1-0 libplymouth2 libpolkit-agent-1-0 libpolkit-backend-1-0 libpolkit-gobject-1-0 libsystemd-daemon0 libsystemd-login0 libupower-glib1 libusb-1.0-0 libwaudio1 login multiarch-support packagekit-plugin-click plymouth policykit-1 powerd systemd-services telepathy-gabble telepathy-ofono tzdata | 04:47 |
| racarr | one is evil | 04:48 |
| RAOF | racarr: Sure. I want that branch landed :) | 04:49 |
| racarr | RAOF: It feels like today is the day | 04:49 |
| RAOF | https://code.launchpad.net/~robertcarr/mir/client-focus-notifications/+merge/179801 is the current one, right? | 04:50 |
| racarr | I'm looking for the words to say...I don't think I can hide...what I'm feeling inside... | 04:50 |
| racarr | RAOF: https://code.launchpad.net/~robertcarr/mir/client-focus-notifications/+merge/180903 | 04:50 |
| racarr | didn't you check the moon charts? | 04:50 |
| racarr | libpam-systemd libplymouth2 libpolkit-agent-1-0 libpolkit-backend-1-0 | 04:51 |
| racarr | libpolkit-gobject-1-0 libsystemd-daemon0 libusb-1.0-0 libwaudio1 | 04:51 |
| racarr | multiarch-support packagekit-plugin-click plymouth policykit-1 powerd | 04:51 |
| racarr | systemd-services | 04:51 |
| racarr | hmmm | 04:51 |
| racarr | im trying to eliminate ones which seem really unlikely to break mir | 04:52 |
| racarr | first so when I finally break it (and have to start the whole thing over again) | 04:52 |
| racarr | the pool is super small and I can just guess | 04:52 |
| racarr | libpam-systemd libplymouth2 libsystemd-daemon0 plymouth policykit-1 powerd systemd-services | 04:54 |
| racarr | any bets? :p | 04:55 |
| racarr | systemd plymouth policykit or powerd one of them broke mir on the nexus 4 | 04:55 |
| * RAOF lays a bet on "systemd" | 04:58 | |
| racarr | seems likely | 04:58 |
| racarr | it wasn't powerd | 04:58 |
| racarr | seeing if plymouth is the surprise offender now | 04:58 |
| racarr | damnit, ran demo ithout root, 30 second penalty as phone hangs. | 04:59 |
| racarr | :p | 04:59 |
| * RAOF should really get around to submitting a branch that fixes the build with clang 3.4 | 05:00 | |
| racarr | plymouth, hitelisted | 05:01 |
| racarr | what | 05:04 |
| racarr | I am fully upgraded | 05:04 |
| racarr | and just ran mir | 05:04 |
| racarr | ufahsufashfasha | 05:04 |
| RAOF | Huzzah! | 05:04 |
| RAOF | You've fixed it! | 05:04 |
| racarr | what if it fixed itself in the archive | 05:05 |
| racarr | while ive been doing this all day | 05:05 |
| racarr | ive been using | 05:08 |
| racarr | the same mir | 05:08 |
| racarr | binary | 05:08 |
| racarr | ...maybe a header changed | 05:08 |
| racarr | ugh | 05:08 |
| racarr | ok literally no headers changed | 05:08 |
| racarr | im flashing a latest image and upgrading to see if it really did just | 05:10 |
| racarr | ...fix itself | 05:10 |
| tvoss | good morning | 05:15 |
| tvoss | RAOF, we have exclusive access to the ati machine :) | 05:15 |
| RAOF | Excellent. | 05:20 |
| * RAOF is making coffee for a moment. | 05:20 | |
| tvoss | RAOF, I'm back in ~1 hour | 05:23 |
| racarr | tvoss: So I've been bisecting images, until I got to august 12th broken july 26th orks then I ran out of images so I started | 05:26 |
| racarr | installing packages to upgrade, about 10 at a time | 05:26 |
| racarr | and rebooting and testing | 05:26 |
| racarr | at one point it seemed to break, so I bisected those packages from the working image | 05:26 |
| racarr | but then it always orked so I started over | 05:27 |
| racarr | over about 30 reboots I saw maybe 2 failures here I had to reboot, but then it alays worked until I was | 05:27 |
| racarr | fully ugpraded, and it still worked! | 05:27 |
| tvoss | racarr, wtf | 05:27 |
| racarr | and then I verified I asn't crazy, and the fully upgraded binary was working | 05:27 |
| racarr | and cmake, didn't detect any thing as touched, i.e. mir needing rebuild, in fact none of the mir | 05:27 |
| tvoss | racarr, could you reboot like 20 times to rule out a race? | 05:27 |
| racarr | build depdencies were ever upgraded | 05:28 |
| racarr | tvoss: I have, it seems either it always fails, or | 05:28 |
| racarr | just occasionally it fails in this one way that a reboot fix | 05:28 |
| racarr | but always works otherwise | 05:28 |
| racarr | what I am doing now is a clean image to see i it was | 05:28 |
| racarr | magically fixed in the archive | 05:28 |
| tvoss | okay | 05:28 |
| tvoss | racarr, can you compile that into an email? | 05:29 |
| racarr | tvoss: Yeah I am about 5 minutes away from the result on the | 05:30 |
| racarr | clean image then I will write things up | 05:30 |
| racarr | it doesn't really make any sense as far as I can see, but I was pretty careful | 05:31 |
| racarr | but I dunno, I haven't really zoomed back out yet | 05:31 |
| racarr | ive just been...in robot mode | 05:31 |
| racarr | ugh | 05:34 |
| racarr | it didn't work | 05:34 |
| didrocks | hey robert_ancell! Just a quick note on lightdm packaging, you took my cleanup branch, right? (https://code.launchpad.net/~didrocks/lightdm/packaging-cleanup) | 05:35 |
| didrocks | it was merged in the /unity one, not sure you took it for trunk | 05:35 |
| robert_ancell | didrocks, yeah, it's a mix of a few different packaging branches :) | 05:36 |
| robert_ancell | i.e. what was in the archive + the changes you made + the test changes made for CI | 05:36 |
| robert_ancell | will be nice to be down to one branch :) | 05:36 |
| didrocks | robert_ancell: indeed ;) thanks! | 05:37 |
| * didrocks can close a tab then \o/ | 05:37 | |
| racarr | tvoss: OK I commented on the bug | 05:39 |
| racarr | brain basically off now | 05:44 |
| RAOF | didrocks: Yo! | 05:45 |
| didrocks | RAOF hey! | 05:45 |
| RAOF | Bah. Why aren't all the rdeps of xmir magically rebuilt when I break the ABI? :) | 05:46 |
| RAOF | didrocks: By the way, this patch http://paste.ubuntu.com/5983202/ worked fine; it was when we turned on logging for the msg-processor and frontend that the race disappeared. | 05:48 |
| RAOF | And by ‘worked fine’ I obviously mean “hung like a bastard” | 05:48 |
| didrocks | RAOF: was the rdepends a question for me? | 05:49 |
| didrocks | RAOF: ah, so you got all the info you needed? | 05:50 |
| RAOF | No :) | 05:50 |
| RAOF | didrocks: Well, we got all the information that patch provided. :) | 05:50 |
| didrocks | heh | 05:50 |
| RAOF | Which was "yes, XMir really is writing the request to the socket and is not receiving a reply" | 05:50 |
| didrocks | RAOF: the ATI machine is completely deprovisionned btw | 05:52 |
| RAOF | So I hear. | 05:52 |
| didrocks | (just done) | 05:52 |
| didrocks | if you need help to setup the environment, do not hesitate | 05:53 |
| RAOF | I think others are taking the lead on this bug for a while, while I get multihead for XMir done. | 05:53 |
| didrocks | ok | 05:53 |
| alf__ | racarr: dpms ping | 06:14 |
| RAOF | I seem to be leaking ALL THE FDs | 06:22 |
| RAOF | But I don't think that's my fault. | 06:23 |
| smspillaz | the awkward moment when you have been writing C++ for so long that you forgot how to write GObjects | 06:24 |
| RAOF | I hear the correct way to do that is to write a DSL. | 06:24 |
| smspillaz | RAOF: DSL? | 06:25 |
| RAOF | Domain Specific Language; ie: Vala | 06:26 |
| smspillaz | lol | 06:26 |
| smspillaz | actually | 06:26 |
| smspillaz | I think this marks the first time this year | 06:26 |
| smspillaz | I will have written a GObject | 06:26 |
| duflu | \o/ | 06:26 |
| smspillaz | not a cause for celebration | 06:26 |
| duflu | or /o\ depending on how you look at it | 06:27 |
| smspillaz | /o\ most certainly | 06:27 |
| duflu | gcc. How I hate you and your insane C++ error messages | 06:43 |
| RAOF | Yes | 06:46 |
| dholbach | good morning | 06:53 |
| RAOF | Hrm. | 07:41 |
| tvoss | RAOF, ? | 07:42 |
| RAOF | I think we might leak fds for clients with more than one window | 07:42 |
| RAOF | Or, at least, we leak ALL THE FDs when XMir has two surfaces, one for each of my displays, and we don't leak fds when XMir is only driving one display. | 07:43 |
| RAOF | The problem could be in the XMir code, but I thought that mirclient should handle the fds sent over the wire. | 07:49 |
| duflu | RAOF: Is this related?... 1194534 | 07:51 |
| duflu | bug 1194534 | 07:51 |
| ubot5 | bug 1194534 in Mir "mir_connection_release does not free associated surfaces" [Medium,Triaged] https://launchpad.net/bugs/1194534 | 07:51 |
| RAOF | duflu: I don't think so; I don't call mir_connection_release | 07:51 |
| duflu | Ever? | 07:52 |
| RAOF | Ever | 07:52 |
| RAOF | At the moment. I guess I should at some point, but it's not hugely important. | 07:53 |
| duflu | RAOF: So you *should* get leaks of some sort anyway :) | 07:53 |
| RAOF | What *is* important is that Mir doesn't leave in excess of 1024 file descriptors open, causing X to fail to accept any new clients. | 07:53 |
| RAOF | duflu: Oh, sure. It just shouldn't be “there are more than 1024 file descriptors leaked by the RPC code” | 07:54 |
| duflu | That is indeed a lot | 07:54 |
| tvoss | alf__, ping | 08:25 |
| alf__ | tvoss: pong | 08:26 |
| alan_g | hikiko: how is it going? | 08:38 |
| hikiko | hi alan_g | 08:39 |
| hikiko | I started a new branch here: https://code.launchpad.net/~hikiko/mir/mir.native-platform-functions and I am now replacing the functions in native platform | 08:40 |
| alan_g | hikiko: by "native platform" you mean *nested* platform? | 08:45 |
| hikiko | no | 08:45 |
| hikiko | I started filling the: | 08:45 |
| hikiko | get_ipc_package, create_internal_client, create_buffer_allocator | 08:46 |
| alan_g | for android and gbm? | 08:48 |
| alan_g | Let's first rewrite the nested functions that can be written "return native_platform->xxxxxxx();" and get that onto trunk. | 08:48 |
| hikiko | without implementing the xxxx() you mean? | 08:51 |
| alan_g | https://code.launchpad.net/~hikiko/mir/mir.native-platform-functions already has implementations (stubs) | 08:52 |
| hikiko | yes | 08:52 |
| hikiko | so I ll just call the stub functions | 08:52 |
| hikiko | you don't want me to implement the stubs as well | 08:52 |
| alan_g | If we get the nested code landed (with stubs) then we can separate work on the GBM and Android support | 08:53 |
| hikiko | cool | 08:54 |
| * alan_g likes to keep as much code on trunk as possible. (I.e. small incremental merges) | 08:54 | |
| alan_g | hikiko: like: https://code.launchpad.net/~alan-griffiths/mir/display-is-not-output/+merge/180914 (which you could review once you've MP'd the above) | 08:57 |
| RAOF | Oh, that's right. Callbacks are non-optional. | 09:25 |
| duflu | That sucks. My thinkpad has pinned itself to 800MHz even though I'm building on both cores | 09:29 |
| duflu | Usually that only happens on low battery or high temperature... | 09:29 |
| RAOF | Is there some philosophical reason why all our async functions *require* valid callbacks to be passed in? | 09:40 |
| duflu | RAOF: I was wondering that at the start of the year. I think I proposed making them optional and it was rejected. Can't remember | 09:45 |
| hikiko | alan_g, https://code.launchpad.net/~hikiko/mir/mir.nested-platform-functions/+merge/181001 | 09:45 |
| hikiko | I'll review the display-is-not-output now | 09:46 |
| RAOF | duflu: I guess we could have a no-op callback in mirclient? | 09:46 |
| alan_g | hikiko: OK (I'll review yours after I finish on session_lifecycle) | 09:46 |
| RAOF | Because I really *don't care* when this surface gets released | 09:47 |
| duflu | RAOF: It's a bit ugly and definitely suboptimal | 09:47 |
| duflu | RAOF: I'd prefer support for NULL | 09:47 |
| duflu | NULL is definitely a valid callback in some cases | 09:47 |
| RAOF | An explicit no-op callback is probably more self-documenting, but NULL is more idiomatic. | 09:48 |
| duflu | RAOF: Then to solve both: const CallbackType *noop = NULL; | 09:48 |
| hikiko | sure alan_g take your time | 09:48 |
| duflu | RAOF: Or just #define NO_CALLBACK NULL | 09:49 |
| RAOF | But now you need to explicitly handle NULL in mirclient! | 09:49 |
| duflu | RAOF: So...? | 09:49 |
| * RAOF is not really arguing against NULL | 09:50 | |
| mpt | tvoss, katie: When we say surfaces aren't aware of their absolute position, what's the one-sentence reason why? | 10:04 |
| hikiko | alan_g, what does the POC mean here? // TODO as a POC just use the first active display | 10:08 |
| alan_g | "Proof Of Concept" (note to self: don't abbreviate) | 10:09 |
| tvoss | mpt, as seen in the past, it leads to assumptions regarding the phyiscal layout of screens for example. | 10:09 |
| hikiko | so, alan_g this branch just modifies the display to match the new Display interface with the multimonitor support or I am missing something? | 10:15 |
| hikiko | no, there's the displayoutput as well | 10:16 |
| alan_g | hikiko: yep | 10:16 |
| mpt | tvoss, when there are multiple displays, do apps know even what display each surface is on? | 10:19 |
| tvoss | mpt, the plan is to only communicate dpi changes | 10:20 |
| === chihchun is now known as chihchun_afk | ||
| mpt | tvoss, thanks. Next question: If an app has three windows open, A, B, and C, and A is focused, does the app have knowledge that B is above C or vice versa? | 10:21 |
| tvoss | mpt, the app knows which surface is focused | 10:22 |
| mpt | Yes, but that's A. :-) | 10:22 |
| tvoss | mpt, sure :) but under the constraint that stacking only changes when focus changes, an app knows if B is over C or vice versa | 10:23 |
| mpt | ah, right | 10:23 |
| mpt | So it couldn't interrogate, but it could remember | 10:23 |
| hikiko | alan_g, output == context? | 10:23 |
| alan_g | hikiko: ? | 10:23 |
| tvoss | mpt, exactly. our focus policy makes sure that stacking per app only ever changes if focus changes (at least for regular surfaces) | 10:24 |
| mpt | tvoss, unless a window manager decides to go Amiga Intuition 1.x style and add a "Send to Back" button to every title bar. :-) | 10:25 |
| hikiko | I mean, a display's output (eg the nested display's output) is the sum of variables that describe the context we render in the display (the state)? | 10:25 |
| tvoss | mpt, hmmm, good point ;) | 10:25 |
| hikiko | and we ll have a different context for every display and a different display for every monitor? | 10:26 |
| alan_g | hikiko: there's one Display and an output for each active monitor. (At least that's what's in the native GBM code) | 10:27 |
| alan_g | But that's not what I've implemented for nested (yet) | 10:28 |
| hikiko | so each monitor is a different "buffer"/window? | 10:28 |
| alan_g | ack | 10:28 |
| hikiko | yes, I understand what you did and it looks good to me, I am just trying to get sure I understand the whole concept | 10:28 |
| hikiko | +can I top approve? it has 4 positive reviews | 10:30 |
| alan_g | hikiko: I think it should be a customization point - and am still thinking. (E.g. I may want a nested mir with a single window that doesn't match a monitor) | 10:30 |
| alan_g | hikiko: you can top approve | 10:31 |
| alan_g | (And you don't need to ask permission) | 10:31 |
| katie | tvoss, another question for you.. is it Mir or the application that should remember whether a surface is fullscreen/maximised etc? | 10:31 |
| tvoss | katie, for the surface state, it should be the application | 10:32 |
| hikiko | alan_g, if this 1 window can be splitted to as many buffers as the monitors and can have the size of the virt. screen size there shouldn't be a problem (I am not 100% sure though) | 10:34 |
| mpt | tvoss, katie: If Mir can remember its absolute position, why can't Mir remember its state too? | 10:34 |
| tvoss | mpt, fair question: we could add a function: restore previous state | 10:35 |
| mpt | tvoss, katie: I think we're missing a description of how an app tells Mir the identity of a surface it's reopening. That would be the place to describe that Mir restores not just the previous position and size but the previous state too. | 10:36 |
| alan_g | hikiko: it isn't a problem for now - but I was thinking more of a window smaller than a monitor. (So I could run up a server as a "normal" application) | 10:36 |
| tvoss | mpt, ah, that's a good point. so the app is responsible for "tagging" a surface | 10:37 |
| mpt | tvoss, when an app opens a surface, does it have to provide a preferred size? | 10:53 |
| tvoss | mpt, yup, an initial one at least | 10:53 |
| mpt | tvoss, but what if I develop a word processor, and the preferred size for new document windows depends on the physical size of the current display, up to a reasonable limit? Should all apps contain that kind of logic? | 10:55 |
| tvoss | mpt, why would it depend on the physical size? you mean in terms of percentage? | 10:56 |
| mpt | tvoss, katie suggests that in that case, an app could just ask for a preferred size of, say, 8" by 12". On any screen smaller than that (e.g. phone, tablet), it would take up full screen. On any screen larger (e.g. Cinema Display), I'd get that actual size. | 10:57 |
| tvoss | mpt, yup, that sounds like a good idea. How do you want to handle aspect ratios? | 10:58 |
| mpt | tvoss, if you reopened a surface on a display that was still wide enough but not tall enough, katie and I think it would only get shorter, not narrower. | 11:01 |
| tvoss | mpt, so we do not preserve aspect ratio? | 11:03 |
| mpt | tvoss, right | 11:03 |
| tvoss | mpt, okay. What if an app needs that functionality? | 11:03 |
| mpt | tvoss, unless you want to back that into window management (it seems a bit niche), the app would need to notice its new height and narrow itself proportionately. | 11:05 |
| mpt | *back -> bake | 11:05 |
| tvoss | mpt, the one thing that concerns me is the feedback cycle required ... | 11:06 |
| tvoss | mpt, user resizes window, app receives resize notification, resizes its frame | 11:06 |
| mpt | tvoss, well there are other cases where a window wants to set strict limits on how it can be resized ... The most complicated example I've seen is floating toolbars, where the exact combination of width and height depends on what buttons and other controls are present. | 11:08 |
| mpt | Palettes is an even better example. | 11:08 |
| tvoss | mpt, ack, so why don't we say an app can request the following flow: about-to-be-resized(old_size, newly_requested_size) -> new_size_as_calculated_by_app | 11:10 |
| tvoss | and only then we resize | 11:10 |
| mpt | Hmm, I thought the Gimp toolbox would be an example, but it isn't, because of that dire "You can drop dockable dialogues [sic] here" | 11:12 |
| mpt | tvoss, what use is old_size there? | 11:15 |
| tvoss | mpt, hmmm, to express the user requested change ... although the application should know that anyways | 11:18 |
| mpt | tvoss, ideally the app would animate internal reshuffling of a window's contents, but that isn't helped by knowing the old size of the entire window. | 11:20 |
| mpt | For that it needs to know the old position of individual elements inside. | 11:21 |
| tvoss | mpt, which it does anyway | 11:23 |
| === tvoss is now known as tvoss|lunch | ||
| Saviq | greyback, any idea how do we stand on screen blanking in unity8@Mir? | 11:42 |
| === hikiko is now known as hikiko|lunch | ||
| greyback | Saviq: I've not attempted it. Right now it doesn't blank. | 11:44 |
| Saviq | greyback, right, another one to the list of regressions | 11:45 |
| Saviq | greyback, did you write it in the end or shall I? | 11:47 |
| greyback | Saviq: http://sketchpad.cc/zYRXs1hnWu | 11:49 |
| Saviq | greyback, added some more and their blueprint-like status, how's it look? | 11:52 |
| greyback | Saviq: looks ok | 11:53 |
| === tvoss|lunch is now known as tvoss | ||
| tvoss | alan_g, got a nexus 4 handy? | 12:08 |
| alan_g | yes (but lunch is calling) | 12:08 |
| tvoss | alan_g, can you ping me after lunch then? | 12:09 |
| alan_g | tvoss: Sure. Should I leave it installing anything? | 12:10 |
| tvoss | alan_g, would be cool if you could phablet flash the latest image | 12:10 |
| alan_g | tvoss: ack | 12:11 |
| alan_g | Rats!! (It is in "I don't have enough charge to charge mode" again.) | 12:14 |
| === alan_g is now known as alan_g|lunch | ||
| tvoss | olli_, ping | 12:15 |
| olli_ | tvoss, pong | 12:16 |
| === hikiko|lunch is now known as hikiko | ||
| === alan_g|lunch is now known as alan_g | ||
| alan_g | tvoss: back (but flashing failed) "ERROR:phablet-flash:Command 'adb shell mount /sdcard/' returned non-zero exit status 255" | 13:38 |
| tvoss | alan_g, please ask in #ubuntu-touch for help | 13:41 |
| alan_g | tvoss: I'll ping you when I've got it working again | 13:42 |
| tvoss | alan_g, ack | 13:42 |
| alan_g | hikiko: how are you doing? | 13:54 |
| tvoss | sil2100, didrocks lxc-start on the ati machine fails, I can briefly see the login prompt, then the container shuts down | 13:55 |
| tvoss | sil2100, didrocks lxc-attach fails with lxc-attach: failed to get the init pid | 13:56 |
| didrocks | tvoss: do you restart the Mir environment? | 13:56 |
| didrocks | the right run? | 13:56 |
| alan_g | tvoss: OK I've got a newly flashed N4 | 13:57 |
| ricmm | thomi: did you guys get the prio sorted? | 13:57 |
| ricmm | I obv cant push it, I just ask whoever is on vanguard in webops | 13:57 |
| tvoss | ricmm, thomi is unlikely to be online | 13:57 |
| ricmm | right | 13:59 |
| tvoss | didrocks, how do I do that? | 13:59 |
| didrocks | tvoss: that's what I told, we need to reset the Mir environment | 14:00 |
| tvoss | didrocks, mind telling me how? :) | 14:00 |
| didrocks | but I don't have time for that (taking 15 minutes and hoping on meetings) | 14:00 |
| didrocks | tvoss: I can recreate quickly a blank one rather | 14:00 |
| tvoss | didrocks, ack | 14:00 |
| didrocks | where you have a persistency daily image | 14:00 |
| didrocks | then you add the ppa | 14:00 |
| didrocks | and the packages | 14:00 |
| didrocks | sounds ok? | 14:00 |
| hikiko | alan_g, in this case the window could be resized to be fullscreen when necessary | 14:01 |
| hikiko | so, why not | 14:01 |
| didrocks | let's take that as a yes :) | 14:01 |
| alan_g | hikiko: Don't worry about that use case yet | 14:02 |
| === chihchun_afk is now known as chihchun | ||
| alan_g | hikiko: what are you doing currently? | 14:04 |
| hikiko | I am looking at the display | 14:05 |
| didrocks | tvoss: ok done | 14:05 |
| didrocks | let me pm the instructions | 14:05 |
| hikiko | there are at about 8 functions with todo | 14:05 |
| hikiko | I think that maybe I should start from there | 14:06 |
| === jono is now known as Guest90491 | ||
| hikiko | if you agree | 14:06 |
| hikiko | (alan_g) | 14:06 |
| === greyback is now known as greyback|needsfo | ||
| === greyback|needsfo is now known as greyback|food | ||
| alan_g | hikiko: Don't try to do too much at once. I'm looking at the mulit-monitor interactions for NestedDisplay (I think alf__ is busy writing the stuff I need for it) | 14:09 |
| hikiko | alan_g, what do you suggest I do as a next step then? | 14:09 |
| alan_g | so maybe the best place to for you to start is in the NativeGBMPlatform | 14:09 |
| alan_g | BTW Don't worry about duplicating code with GBMPlatform - we can refactor that after we have things working. | 14:10 |
| alan_g | hikiko: ^^ | 14:10 |
| hikiko | ok then :) I ll start adding the functions there! | 14:11 |
| alan_g | hikiko: don't go too fast - just get the test to get through one more function call | 14:12 |
| alan_g | (Before an exception gets thrown) | 14:13 |
| hikiko | alan_g, what do you mean get the test? | 14:15 |
| rsalveti | tvoss: racarr: can start mir_demo_server successfully with aug 5th | 14:15 |
| rsalveti | tvoss: which other test can I run? | 14:15 |
| rsalveti | hm, seems it crashed now | 14:16 |
| rsalveti | E/Adreno200-GSL( 1724): <ioctl_kgsl_driver_entry:269>: open(/dev/kgsl-3d0) failed: errno 2. No such file or directory | 14:16 |
| alan_g | hikiko: there's only one TestNestedMir test currently - I mean that one | 14:16 |
| hikiko | you mean to run this test each time I add a new function? | 14:17 |
| alan_g | hikiko: I mean change the system so that the exception caught comes from the next not-implemented function that gets called, update the test for the new exception and MP those changes. | 14:18 |
| hikiko | alan_g, ok :) I might bother you when I have to modify the test because it will be my first one... but ok, I'll do the change first :) | 14:23 |
| === greyback|food is now known as greyback | ||
| alan_g | alf__: @place-surface-in-output - how does a client select an output? I don't see any client-side API for it - what have I missed. | 14:41 |
| alf__ | alan_g: it's a new field in surface creation parameters .output_id | 14:43 |
| alan_g | alf__: thanks | 14:44 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| tvoss | racarr, ping | 15:10 |
| hikiko | bye! | 15:15 |
| tsdgeos | olli_: is it ok if instead of 19.2 I test image 20? | 15:17 |
| tsdgeos | phablet-flash cdimage-touch --pending is giving me 20 instead of 19.2 | 15:17 |
| tvoss | tsdgeos, please do 19.2 | 15:17 |
| tsdgeos | tvoss: then i'm going to need help on how to get it | 15:17 |
| tvoss | ogra_, how to get 19.2 with phablet-flash? | 15:18 |
| ogra_ | tvoss, dunno, i never use phablet-flash ... i think you need to give it a --url parameter | 15:21 |
| ogra_ | tvoss, reading teeh help i would guess: phablet-flash cdimage-touch -d mako --ubuntu-path=http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20130819.2/ | 15:23 |
| tvoss | tsdgeos, ^ | 15:23 |
| tsdgeos | ogra_: the help confuses me | 15:24 |
| ogra_ | phablet-flash cdimage-touch -h | 15:24 |
| tsdgeos | what's the difference between --device-path and --ubuntu-path | 15:24 |
| tsdgeos | ogra_: that is what is confusing me, yes i can get there ;-) | 15:24 |
| ogra_ | dunno, ask sergiuiens :) | 15:24 |
| ogra_ | he invents those options all the time :) | 15:25 |
| rsalveti | device-path is the android zip file | 15:32 |
| rsalveti | ubuntu-path is the ubuntu zip file | 15:32 |
| rsalveti | you need both | 15:32 |
| ogra_ | oh ? | 15:32 |
| tsdgeos | can't i just say "i want 20130819.2" easily? | 15:33 |
| ogra_ | i thought there was a patch that you only need one with the latest phablet-flash | 15:33 |
| ogra_ | tsdgeos, depends how well your voice input works | 15:33 |
| ogra_ | :P | 15:33 |
| bschaefer | tvoss, ping | 15:49 |
| tvoss | bschaefer, otp | 15:49 |
| bschaefer | tvoss, alright | 15:49 |
| === tvoss is now known as tvoss|afk | ||
| === chihchun is now known as chihchun_afk | ||
| alan_g | Have a good day everybody! | 16:58 |
| === alan_g is now known as alan_g|EOD | ||
| kgunn | racarr: you on? | 17:16 |
| racarr | kgunn: Yeah just recently | 17:17 |
| kgunn | np...feel free to coffee up | 17:17 |
| kgunn | basically....the current request is to retest using 19.2 with -b (to make it completely fresh) | 17:18 |
| kgunn | rsalveti was able to get it working | 17:18 |
| kgunn | in case the image moved....use this command line | 17:18 |
| rsalveti | I didn't get the crash, but just noticed I'm also getting a black screen | 17:18 |
| rsalveti | the issue when allocating memory is due a race in udev/ueventd, which I'm working on atm | 17:18 |
| kgunn | phablet-flash cdimage-touch --ubuntu-path http://cdimages.ubuntu.com/ubuntu-touch/daily-preinstalled/20130819.2/saucy-preinstalled-touch-armhf.zip --device-path http://cdimages.ubuntu.com/ubuntu-touch/daily-preinstalled/20130819.2/saucy-preinstalled-touch-armel+[device].zip -b | 17:18 |
| racarr | 19.2? | 17:18 |
| rsalveti | racarr: which was the latest issue that you were having? a crash or just a black screen? | 17:19 |
| racarr | rsalveti: Ah yeah black screen is all I get | 17:19 |
| racarr | crash is rare | 17:19 |
| racarr | any time I have ever seen the crash | 17:19 |
| racarr | a reboot has made it go aay and it | 17:19 |
| racarr | reverted to black screen | 17:19 |
| rsalveti | right, then let me flash the older image again, which was working without black screen | 17:19 |
| racarr | err so wait should I try this | 17:20 |
| racarr | phblet-flash kgunn gave me? | 17:20 |
| rsalveti | please try | 17:20 |
| rsalveti | seems it worked fine for ev | 17:20 |
| kgunn | rsalveti: "worked fine" means unity8 came up on mir ? & no black screen ? | 17:20 |
| racarr | Err | 17:21 |
| rsalveti | unity coming afaik | 17:21 |
| racarr | flashing | 17:22 |
| racarr | ok installing mir ppa on image | 17:39 |
| bschaefer | kgunn, hey, sooo Im suppose to help work on an ATI bug? Would you happen to know something about that? | 17:40 |
| kgunn | bschaefer: ok....so, it seems to be corrected by the latest kernel (updated to 3.11 y'day ~2pm my time) | 17:40 |
| bschaefer | through didrocks machine, and I missed tvoss a bit ago...soo I figured you might know something! | 17:40 |
| bschaefer | kgunn, o really? | 17:40 |
| bschaefer | kgunn, soo do we need to confirm this, or is it already? | 17:40 |
| kgunn | tvoss|afk: & didrocks rebuilt and tried reboot ad-nauseum | 17:41 |
| kgunn | it never failed | 17:41 |
| kgunn | there were some kernel changes (e.g. mutex related) that certainly could've effected | 17:41 |
| kgunn | so anyway...result was to place didrocks machine back "on the line" | 17:42 |
| bschaefer | sweet, well lets hope it stays fixed :) | 17:42 |
| kgunn | he will start pushing updates tomorrow morning his tmie | 17:42 |
| kgunn | time | 17:42 |
| kgunn | yep | 17:42 |
| bschaefer | cool! Well that was fun to work on :) | 17:42 |
| kgunn | we are going to pull his machine again in a couple of weeks during bug squash week to root cause | 17:42 |
| kgunn | seriously the pressure is off....but if you wanted to attempt some root cause effort that would be great | 17:43 |
| bschaefer | that would be a good idea, don't want this coming up later on | 17:43 |
| kgunn | altho you'd need to coordinate with him....as its back in service | 17:43 |
| kgunn | painful part will be trying to stay on 3.10 kernel to test | 17:43 |
| bschaefer | kgunn, I can try, I think i remember trying to reproduce this last week on my ati machine | 17:43 |
| kgunn | bschaefer: were you ever successful ? | 17:44 |
| bschaefer | right, yeah if he comes back and wants some more testing i my time zone Ill go with it! | 17:44 |
| bschaefer | kgunn, nope :( | 17:44 |
| bschaefer | kgunn, it was only didrocks machine | 17:44 |
| kgunn | bschaefer: yeah...that's the thing....his machine was kinda golden | 17:44 |
| kgunn | even raof's debug add ons changed timing and bug disappeared.... | 17:44 |
| bschaefer | yeeah, didrocks should get a new machine :) | 17:44 |
| kgunn | like i say mutex changes coming in 3.11 kernel make me wonder | 17:44 |
| bschaefer | but it is nice it did catch something like that, would have been hard to figure out later on... | 17:45 |
| bschaefer | kgunn, in a bad way? | 17:45 |
| bschaefer | or rather the mutex fixes are the fix? | 17:45 |
| kgunn | b/c xmir would always start ok...it only ever stalled when compiz was trying to init gl for unity | 17:45 |
| kgunn | in a good way | 17:45 |
| kgunn | yes...mutex fixes | 17:45 |
| bschaefer | right, I ran into that on my intel machine | 17:45 |
| bschaefer | but then i purged all of my libegl* stuff and it never came back... | 17:46 |
| kgunn | <mlankhorst> mir fixes, ww_mutex changes, dpm support | 17:46 |
| bschaefer | kgunn, then my laptop died :(... | 17:46 |
| kgunn | <mlankhorst> maybe uvd fixes | 17:46 |
| bschaefer | awesome | 17:46 |
| kgunn | that was the response i got for kernel changes that might've effected this | 17:47 |
| bschaefer | well IIRC it was thought to be a deadlock right? | 17:47 |
| bschaefer | or a race for this ATI problem? | 17:47 |
| racarr | back on DPMS mode :) | 17:49 |
| racarr | phone almost upgraded | 17:49 |
| kgunn | racarr: so did 19.2 work for you ? | 17:49 |
| kgunn | bschaefer: well...deadlock only occured when they tried subsequent start of x after the compiz stall on gl load | 17:50 |
| kgunn | bschaefer: so the 1st symptom was always failure to load gl from compiz (even tho mir was fine) | 17:50 |
| bschaefer | kgunn, oo interesting, well when tvoss|afk gets back I can play around on the machine again to try and get the issue or dig some more into it | 17:51 |
| racarr | kgunn: It's installing mir ppa | 17:51 |
| racarr | it takes me 5-6 minutes to run apt-get update alone :( | 17:51 |
| racarr | phablet is so slo on my wireless | 17:51 |
| rsalveti | racarr: 19.2 always gives black screen here, but aug 5th works fine, will test some other images | 17:51 |
| rsalveti | doesn't crash, but gets a black screen | 17:51 |
| kgunn | racarr: rsalveti ....ok, i tried earlier, got black screen....just reflashed and _only_ installed the mir ppa (e.g. didn;t do a dist-upgrade rather install 1by1) | 17:51 |
| kgunn | and still got a black screen | 17:51 |
| racarr | Wait then why am I trying | 17:52 |
| racarr | because isnt this hat I did | 17:52 |
| racarr | yesterday | 17:52 |
| rsalveti | right, I first thought the issue was related with the crash that happens sometimes | 17:52 |
| racarr | no | 17:52 |
| racarr | the crash just happens XD | 17:52 |
| rsalveti | hahah, right | 17:52 |
| racarr | I think it's different | 17:52 |
| racarr | rsalveti: Ok so yesterday | 17:52 |
| rsalveti | let me try to isolate the black screen then | 17:52 |
| racarr | I started from a working image | 17:52 |
| racarr | july 26th | 17:52 |
| racarr | and started upgrading packages in groups of 10 | 17:52 |
| kgunn | rsalveti: also...for racarr's sanity....didn't you see unity boot (no black screen) when apparmor=0 ? | 17:52 |
| racarr | a few times I saw the crash, but reboot always fixed it and it orks multiple times over | 17:52 |
| racarr | eventually I ully ugpraded | 17:52 |
| kgunn | or was that just a red herring | 17:52 |
| racarr | and it worked too! | 17:53 |
| rsalveti | apparmor=0 doesn't have any effect here | 17:53 |
| racarr | Never had any effect here either:( | 17:53 |
| kgunn | rsalveti: thanks...i'll stop saying that then :) | 17:53 |
| racarr | rsalveti: Anyay what this means (i.e. if someone can confirm that upgrading uly 26th works while installing the latest image fails) | 17:53 |
| rsalveti | racarr: right, will try with some other images here, if it's android related I should be able to see what changed easily | 17:53 |
| racarr | then we can narrow it down to things in the image process | 17:53 |
| racarr | great | 17:53 |
| racarr | I was wondering if it could have to do | 17:53 |
| racarr | didn't the images change | 17:53 |
| rsalveti | racarr: just tested from aug 5th, and worked fine | 17:53 |
| racarr | to multiuser | 17:53 |
| rsalveti | but didn't dist-upgrade | 17:53 |
| rsalveti | let me do that now | 17:53 |
| rsalveti | will download 100mb =\ | 17:53 |
| racarr | tested what? | 17:54 |
| racarr | i.e. mir/unity, etc all run fine (from which source) | 17:54 |
| rsalveti | image from aug5th | 17:54 |
| racarr | on august 5th image? | 17:54 |
| rsalveti | yup | 17:54 |
| racarr | the mir image? or | 17:54 |
| racarr | image + mir ppa or whatever | 17:54 |
| racarr | what* | 17:54 |
| rsalveti | default image, and default mir from ppa (just testing the egltriangle client example)_ | 17:54 |
| rsalveti | for now | 17:54 |
| rsalveti | which is already enough to reproduce the black screen issue | 17:54 |
| rsalveti | sorry, default mir from archive | 17:54 |
| rsalveti | let me dist-upgrade now to check | 17:55 |
| kgunn | rsalveti: you sure about that?...i thot racarr was getting black screen , but then could subsequently run mir demo client fine | 17:55 |
| kgunn | racarr: ^ ? | 17:55 |
| rsalveti | lol, so many issues at the same time it seems :-) | 17:55 |
| rsalveti | but I'm getting black screen with mir_demo_client_egltriangle | 17:56 |
| kgunn | :)~ | 17:56 |
| racarr | Yes I can run the client | 17:57 |
| racarr | fine | 17:57 |
| racarr | and it reports getting FPS, etc | 17:57 |
| racarr | (frequently it gets stuck at half FPS though not always) | 17:57 |
| racarr | but there is never anything on the screen | 17:57 |
| rsalveti | then why the hell even the client is getting a black screen here | 17:57 |
| racarr | rsalveti: No, black screen | 17:57 |
| rsalveti | showing fps and such, but black screen | 17:57 |
| racarr | it ust reports working | 17:57 |
| racarr | yes | 17:57 |
| rsalveti | right | 17:57 |
| rsalveti | then it's the same behavior here | 17:57 |
| racarr | On any image where I have ever seen that | 17:57 |
| racarr | I have never seen | 17:58 |
| racarr | anything on screen from mir :) | 17:58 |
| racarr | but occasionally have seen the crash | 17:58 |
| racarr | on any image where I have seen things on screen from mir | 17:58 |
| racarr | I have also occasionally seen the crash | 17:58 |
| racarr | but never seen | 17:58 |
| racarr | just black screen | 17:58 |
| racarr | so I think it's really just two issues | 17:58 |
| rsalveti | right | 17:58 |
| rsalveti | the crash is something that should be fixed once I fix the udev/ueventd races | 17:58 |
| rsalveti | now we need to isolate this black screen one, got quite a few images to test here | 17:59 |
| rsalveti | after doing dist-upgrade | 17:59 |
| racarr | ok makes sense that the crash is a race | 17:59 |
| racarr | im glad you hve the images :) | 18:00 |
| racarr | 19.2 is still broken for me | 18:00 |
| racarr | ust for the record | 18:00 |
| rsalveti | ok, should have enough to keep me busy for the next hour | 18:01 |
| racarr | Ok. Let me know if I can help | 18:01 |
| kgunn | rsalveti: let me know if i can be of help as well.... | 18:01 |
| rsalveti | sure | 18:01 |
| racarr | kgunn: I am considering that maybe I should try and land dpms with the ineffeciency that I was talking about yesterday | 18:02 |
| racarr | because it will be easy to fix after FF | 18:02 |
| kgunn | i'm not the fastest....but i follow instructions well | 18:02 |
| kgunn | racarr: yes | 18:02 |
| kgunn | agreed... | 18:02 |
| rsalveti | racarr: worked fine after dist-upgrade | 18:08 |
| rsalveti | now to try some other images | 18:08 |
| racarr | So sstrange | 18:10 |
| racarr | its going to be something awfully small in the end haha | 18:10 |
| rsalveti | could be on the android side | 18:12 |
| rsalveti | like the migration to 4.2.2 | 18:12 |
| racarr | oh didnt realize that happened | 18:14 |
| rsalveti | but the interesting thing is that the binaries we were using were already from 4.2.2 | 18:16 |
| racarr | so strange :/ | 18:19 |
| rsalveti | yeah, image from 07 already gives me a black screen | 18:21 |
| rsalveti | now let me revert the android side | 18:21 |
| rsalveti | yeah, just flashing the android zip from 05 made 07 to work again | 18:23 |
| rsalveti | so the different is on the android side, will investigate that a bit more | 18:24 |
| racarr | Aha! close | 18:25 |
| * rsalveti takes a break, late lunch | 18:26 | |
| racarr | :) enoy | 18:26 |
| racarr | Lunch for me | 18:52 |
| === racarr is now known as racarr|lunch | ||
| tvoss_ | racarr, ping | 19:01 |
| kgunn | rsalveti: so 07 vs 05...that's android config as of August 7 and August 5 respectively ? | 19:19 |
| rsalveti | kgunn: yes | 19:19 |
| rsalveti | august 5 was still based on 4.2.1, >= august 6 is based on 4.2.2 | 19:20 |
| kgunn | rsalveti: got it... | 19:20 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === racarr|lunch is now known as racarr | ||
| racarr | hoops back | 19:46 |
| racarr | whoops* | 19:46 |
| racarr | tvoss_: pong | 19:52 |
| thomi | morning | 20:12 |
| racarr | dpms is almost done :) | 20:17 |
| racarr | all done except the GBM impl hich looks really simple | 20:18 |
| racarr | im a little concerned about backlight control | 20:18 |
| racarr | if (drmIoctl(sna->kgem.fd, DRM_IOCTL_MODE_GETPROPERTY, &prop)) | 20:24 |
| racarr | drm API is a pain to mock | 20:24 |
| racarr | not sure how to mock the | 20:25 |
| racarr | DPMS property index id integer:p | 20:25 |
| rsalveti | racarr: ok, so the change is part of the updated display stack for qcom (for 4.2.2) | 20:34 |
| rsalveti | reverted it and was able to get that to work with the latest image, now to find out the right commit :-) | 20:34 |
| kgunn | rsalveti: can you share the android git tree & relative history (if easily at hand) | 20:43 |
| kgunn | rsalveti: just curious...i mean, we're likely going to have to update to "new android stack model" | 20:43 |
| kgunn | would be my guess | 20:43 |
| kgunn | rsalveti: p.s. thanks for the bisecting help | 20:43 |
| racarr | rsalveti: Great to hear :) | 20:46 |
| rsalveti | kgunn: http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_hardware_qcom_display.git;a=summary | 20:48 |
| rsalveti | this is what I reverted, basically | 20:48 |
| rsalveti | from the phablet-saucy branch to phablet-10.1 | 20:48 |
| rsalveti | now will try to bisect in more details | 20:49 |
| racarr | Implemented durning off the display but turning it back on | 20:53 |
| racarr | is having some issues | 20:53 |
| racarr | revno: 982 [merge] | 21:32 |
| racarr | what does this do | 21:32 |
| racarr | or is it just refactoring | 21:32 |
| racarr | it breaks unity 8 | 21:32 |
| racarr | and the easy answer is revert it :p | 21:33 |
| racarr | ...lol at xf86-video-modesetting | 21:42 |
| racarr | /* bonghits in the randr 1.2 - uses dpms to disable crtc - bad buzz */ | 21:43 |
| racarr | if (mode == DPMSModeOff) { | 21:43 |
| racarr | } | 21:43 |
| racarr | ...bad buzz indeed. | 21:43 |
| bschaefer | anyone else getting this error with only this mir demo: http://paste.ubuntu.com/6008072/ | 21:44 |
| bschaefer | the multiwin, it seems when ever I try to do any kind of "get mir region" it fails :( | 21:44 |
| racarr | bschaefer: THERE ARE NO MORE B UGS LALALALALALALALA | 21:45 |
| racarr | No I have not seen that | 21:45 |
| bschaefer | racarr, :) | 21:45 |
| bschaefer | haha | 21:45 |
| racarr | and actually just built and tested trunk like 30 seconds ago | 21:45 |
| racarr | on radeon | 21:45 |
| racarr | my distribution | 21:45 |
| racarr | is not entirely up to date | 21:45 |
| bschaefer | racarr, yeah im on ati...maybe I should update mir | 21:45 |
| * bschaefer goes to rebuild trunk | 21:45 | |
| bschaefer | all other demos work though :) | 21:46 |
| robert_ancell | robotfuel, ack on the bypass testing - that seems to be the same behaviour others are getting. duflu has made some more changes so I'll update the PPA now | 21:50 |
| * bschaefer notices the nice grey background of the mir server now | 21:58 | |
| bschaefer | racarr, stack trace if you're interested: http://paste.ubuntu.com/6008119/ | 22:00 |
| bschaefer | full trace: http://paste.ubuntu.com/6008126/ | 22:02 |
| bschaefer | racarr, i also just realized was getting that cursor problem as well that I commented out... | 22:02 |
| bschaefer | as im not even able to load the server without it complaining about the gbm not able to open ... | 22:03 |
| * bschaefer goes to try that out again | 22:03 | |
| racarr | ill check it out soon | 22:08 |
| racarr | second lunch :p | 22:08 |
| bschaefer | yuup getting that gbm cursor error just when trying to start the mir server on normal X... http://paste.ubuntu.com/6008137/ | 22:08 |
| bschaefer | racarr, :), well I really should ping RAOF about it | 22:08 |
| bschaefer | as IIRC the fix the u-s-c was to disable input but this was only for u-s-c, not the mir server... | 22:08 |
| racarr | No I get RAOF | 22:09 |
| racarr | :p ok maybe I can figure out my dpms thing myself | 22:09 |
| racarr | and you can hve RAOF | 22:10 |
| bschaefer | racarr, haha, well yours is a bit more important :) | 22:10 |
| bschaefer | i think my issue is only on a few ATI cards... | 22:10 |
| bschaefer | racarr, i can also bug him tomorrow about it | 22:11 |
| racarr | ok ill give you RAOF for | 22:11 |
| racarr | 1 bitcoin | 22:11 |
| racarr | insted | 22:11 |
| bschaefer | haha | 22:11 |
| racarr | :p haha sorry im just teasing | 22:11 |
| racarr | dont orry about it | 22:11 |
| * bschaefer doesn't have any bitcoins | 22:11 | |
| racarr | I probably cant look hard at this right aay though, need to poke at | 22:11 |
| racarr | DPMS a little | 22:11 |
| racarr | should be super close | 22:11 |
| racarr | haha me either | 22:11 |
| bschaefer | cool, i don't actually know what DPMS is | 22:12 |
| bschaefer | sounds like a long word though | 22:12 |
| kgunn | rsalveti: so what's the current thot....should you simply revert that one commit to unblock ? or what's your recommendation ? | 22:13 |
| bschaefer | Display Power Management Signaling? Eww... | 22:13 |
| rsalveti | kgunn: there's not single commit to revert yet, still looking | 22:13 |
| kgunn | rsalveti: got it...i'll try to be patient | 22:13 |
| rsalveti | haha :-) | 22:13 |
| kgunn | rsalveti: i get a lot of questions about it....as you can imagine :) | 22:15 |
| rsalveti | yup, no worries | 22:15 |
| racarr | bschaefer: Its pretty ew | 22:26 |
| racarr | so ar I can turn the display off | 22:26 |
| racarr | but then never back on :p | 22:26 |
| bschaefer | haha, well who needs a working display anyway! | 22:26 |
| racarr | then I tried looking in xf86-video-modesetting for examples | 22:27 |
| racarr | hich is where | 22:27 |
| racarr | 21:44 < racarr> /* bonghits in the randr 1.2 - uses dpms to disable crtc - bad buzz */ | 22:27 |
| racarr | comes from | 22:27 |
| racarr | lol | 22:27 |
| bschaefer | hahaha | 22:27 |
| racarr | RAOF: Around? | 22:59 |
| RAOF | racarr: Yo! | 23:08 |
| racarr | RAOF: Was hoping you might have some insight on my DPMS difficulties | 23:10 |
| racarr | essentially, I am setting the DPMS property on the connector | 23:10 |
| RAOF | Sure. Let's see if I've drunk from that particular fountain of madness. | 23:10 |
| racarr | with the DPMS mode, and DPMSModeOff works kind of as you ould expect | 23:11 |
| racarr | the display turns off | 23:11 |
| racarr | unforunately I can't verify hat happens next because | 23:11 |
| racarr | I can never turn the display back on | 23:11 |
| RAOF | Heh. | 23:11 |
| racarr | and if I write mir_demo_server to | 23:11 |
| racarr | some output the file ends up empty | 23:11 |
| racarr | I guess I can use a second machine to | 23:11 |
| racarr | get that but | 23:12 |
| racarr | lol I guess I am just wondering if there is anything off the top of your head | 23:12 |
| racarr | that should obviously have to be done as well, etc | 23:12 |
| racarr | maybe I can use xset dpms force on | 23:12 |
| racarr | to recover | 23:12 |
| RAOF | I think possibly the answer might be "don't bother trying to use the dpms properties; just modeset a null fb"? | 23:13 |
| RAOF | racarr: That's what the intel driver does, at least. | 23:14 |
| RAOF | DPMSOff == SET_CRTC to 0; DPMSOn == set_mode_major (ie: full modeset) | 23:15 |
| RAOF | racarr: This is different to just removing the display from the DisplayConfig because the display is still logically connected (and so you can put windows on it, we probably still have its DisplayBuffers allocated, etc). But as far as KMS is concerned, just remove it from the config. | 23:18 |
| racarr | he intel driver also sets the property | 23:18 |
| racarr | the modesetting driver ignores the crt and just messes ith the property | 23:18 |
| racarr | complaining of "bonghits in the randr" | 23:18 |
| racarr | Ill try ith the crtc...and make sure I redo things properly on ModeON | 23:20 |
| RAOF | Ah, right. You might want to set the DPMS property in addition to doing the modeset to turn off/on the backlight. | 23:22 |
| RAOF | (Which we might have to do manually anyway) | 23:22 |
| racarr | sounds promising | 23:22 |
| racarr | yes backlight | 23:22 |
| racarr | is a mild concern | 23:22 |
| racarr | intel driver seems to do special things | 23:23 |
| RAOF | Yeah, backlight is a swamp of madness. | 23:23 |
| racarr | attempts test again...*crosses fingers* | 23:24 |
| RAOF | Because it's all ‘as an OEM I can add value by having a different backlight interface!’ | 23:24 |
| RAOF | (Spoiler: no, you can't) | 23:24 |
| RAOF | Hm. So XMir XRandR appears to work, except for the bit where Mir actually changes any modes. | 23:27 |
| racarr | Doo doo :( | 23:32 |
| racarr | also that doesnt sound great | 23:32 |
| bschaefer | RAOF, hey, guess what happens when I try to start the mir server on my ATI machine? http://paste.ubuntu.com/6008137/ | 23:36 |
| RAOF | bschaefer: What ATI card do you have, again? | 23:36 |
| bschaefer | VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Redwood XT [Radeon HD 5670/5690/5730] | 23:37 |
| bschaefer | 5670 | 23:37 |
| bschaefer | is the one I have | 23:37 |
| bschaefer | and if i comment out the creation of the cursor it works fine until I try to do software renderering (multiwin example) | 23:38 |
| bschaefer | everything else works if I comment that out... | 23:38 |
| bschaefer | (comment out the creation of the cursor) | 23:38 |
| RAOF | Right. This suggests that we're failing to allocate software-renderable gbm buffers. | 23:40 |
| bschaefer | right, which this is what I get when I run the mutli win when I turn the cursor off: http://paste.ubuntu.com/6008119/ | 23:40 |
| RAOF | Does the server also die? | 23:41 |
| RAOF | Or spew any error messages? | 23:41 |
| bschaefer | well right from my perspective of it not working :) | 23:41 |
| bschaefer | RAOF, nope, it just fails to run the application and it dies | 23:41 |
| bschaefer | it spews out: | 23:41 |
| bschaefer | terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >' | 23:41 |
| bschaefer | what(): Failed to import PRIME fd for DRM buffer | 23:41 |
| bschaefer | also this is me running mir natively on normal X | 23:43 |
| RAOF | By "on normal X" you mean "With an X server running on another VT", right? | 23:45 |
| bschaefer | RAOF, hmm normal X meaning i've turned off xmir | 23:46 |
| kgunn | hey...anyone got phoronix installed running standalone x (not xmir)....updated like today...want to give it a shot | 23:46 |
| bschaefer | but yes | 23:46 |
| kgunn | specifically openarena | 23:47 |
| bschaefer | kgunn, i don't have phronoix installed but I can install it | 23:47 |
| bschaefer | and im on standalone x | 23:47 |
| kgunn | its pretty dead easy | 23:47 |
| bschaefer | yeah, it just take a while to download the games :( | 23:48 |
| kgunn | i just ran it on a recent update and it was ~10fps | 23:48 |
| bschaefer | RAOF, i can try to take a better look into it since I can reproduce it well | 23:48 |
| bschaefer | well at lease figure out what function is failing... | 23:49 |
| bschaefer | kgunn, im also on ati | 23:49 |
| RAOF | bschaefer: To debug you'd want to stick a breakpoint in gbm_dri_bo_create, matching width == 64 and height == 64. | 23:50 |
| bschaefer | RAOF, to match the size of the cursor? | 23:51 |
| bschaefer | RAOF, and ill give that a try after running this phoronix test | 23:51 |
| RAOF | bschaefer: Correct. That way you won't catch the other allocations | 23:51 |
| bschaefer | o cool, but it seems to be the the only one, as commenting out the creation of the cursor and the server works | 23:51 |
| bschaefer | all egl apps work fine on it | 23:52 |
| kgunn | bschaefer: that's cool...its a good data point | 23:55 |
| bschaefer | kgunn, cool, just downloading openarea...then it should run! | 23:55 |
| RAOF | bschaefer: Yeah; all those other allocations will succeed, so they're uninteresting. That's why you should ‘break gbm_dri_bo_create if ((width == 64) && (height == 64))” ☺ | 23:56 |
| bschaefer | ooo i see, I was thinking all gbm buffer calls were failing, because running the example mulitwin was having problems getting a mir region | 23:57 |
| bschaefer | which seemed related... | 23:57 |
| bschaefer | thanks! | 23:57 |
| RAOF | I'd suspect it's just calls with GBM_BO_USE_WRITE set | 23:58 |
| RAOF | Which the cursor will have, but also any buffer we allocate for software rendering. | 23:59 |
| RAOF | And it's easier to catch the cursor :) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!