| === kedars_ is now known as kedars | ||
| === asac_ is now known as asac | ||
| lool | ssvb: Oddly, switching with another pixman and the problem goes away | 07:21 |
|---|---|---|
| lool | cwillu_at_work told me that squeeze/sid/emdebian libpixman doesn't have the issue but lucid pixman (same source, different toolchain) does | 07:21 |
| lool | I'm pretty sure he used the same kernel in all tests since we dont provide kernels for beagleboard on ubuntu | 07:22 |
| lool | bizkut-offline: This is seriously annoying; you don't even answer when we ask you to stop your verbose away | 07:23 |
| armin76 | lool: :D | 07:59 |
| ssvb | lool: don't know, maybe recompiling pixman (and xserver?) with a different toolchain just hides the bug | 08:00 |
| ssvb | lool: but I know for sure that such problem existed with problematic kernels and it resulted in a similar looking artefacts on screen | 08:00 |
| lool | Ok | 08:01 |
| lool | Hmm right, I didn't think of rebuilding xserver, and it might be a bug in the kernel only triggered in specific conditions | 08:02 |
| ssvb | lool: what version of kernel are you using by the way? | 08:02 |
| lool | In Ubuntu we track 2.6.32 for the next release, but we don't provide beagleboard kernels; he was running a .32 IIRC | 08:03 |
| lool | 11:14 < cwillu_at_work> Linux overo 2.6.32.1-x1.0 #1 PREEMPT Thu Dec 17 02:23:37 UTC 2009 armv7l GNU/Linux | 08:03 |
| lool | I'm not sure from which branch | 08:03 |
| lool | I suppose -omap, but then it could be any tree derived from that | 08:03 |
| ssvb | I see, there is a small testcase which can be easily used to verify whether the kernel has this problem or not, I'll try to find it | 08:06 |
| lool | Great | 08:06 |
| === bizkut-offline is now known as bizkut | ||
| ssvb | lool: here is a testcase for kernel bug: http://siarhei.siamashka.name/files/20100104/test-sighandler-vfp-corruption-bug.c | 09:35 |
| ssvb | lool: looks like the fix did not get upstream yet (just tested it with the latest linux-omap kernel), makes sense to send some ping messages | 09:36 |
| lool | cwillu_at_work: ^ | 09:39 |
| lool | ssvb: thanks! | 09:39 |
| * armin76 kicks NCommander | 09:53 | |
| ssvb | lool: also just verified that these old patches still apply cleanly and fix the problem | 09:53 |
| * NCommander is beaten by armin76 | 09:54 | |
| * armin76 steals NCommander's dove boards | 09:54 | |
| NCommander | armin76, :-P | 09:55 |
| NCommander | armin76, http://www.engadget.com/2010/01/04/freescale-reveals-7-inch-smartbook-reference-design-hopes-to-se/ - just buy one of these | 09:55 |
| armin76 | NCommander: i prefer your boards *g* | 09:55 |
| armin76 | NCommander: gimme Z0! | 09:56 |
| NCommander | armin76, I never had a Z0 | 09:57 |
| armin76 | NCommander: get me one! | 09:57 |
| * NCommander thinks armin76 didn't get any ARM hardware for the holidays | 09:57 | |
| * cwillu_at_work is pinged | 09:57 | |
| * cwillu_at_work pokes lool | 09:57 | |
| armin76 | NCommander: there's an dove arm buildd that hasn't build something since october, gimme! | 09:58 |
| NCommander | armin76, ? | 09:58 |
| armin76 | NCommander: give it to me if it isn't doing anything :P | 09:59 |
| * cwillu_at_work has finished reading the scrollback | 10:00 | |
| * cwillu_at_work runs ssvb's test-sighandler-vfp-corruption-bug.c | 10:02 | |
| cwillu_at_work | cwillu@overo:~$ ./a.out | 10:02 |
| cwillu_at_work | error: x=1090022160 y=1090022161 d=9434.232100 | 10:02 |
| cwillu_at_work | Aborted | 10:02 |
| ssvb | cwillu_at_work: it's a bit messy, but demonstrates that the signal handler can corrupt floating point registers from the main thread, normally this test should run infinitely without any problems | 10:03 |
| cwillu_at_work | ya, that run lasted all of 20 seconds | 10:04 |
| ssvb | cwillu_at_work: for pixman it means that the signal handler responsible for input handling may corrupt NEON registers and as these are used for processing pixel data, it results in image artefacts which look as horizontal stripes | 10:05 |
| cwillu_at_work | hmm | 10:06 |
| cwillu_at_work | only horizontal stripes? | 10:06 |
| cwillu_at_work | I only get 45degree stripes | 10:06 |
| cwillu_at_work | this is upstreams 2.6.32.2 from git, with some patches applied | 10:07 |
| cwillu_at_work | although experienced this under 2.6.32.1, only started playing with libpixman after I switched to that series, so I don't know about earlier kernels | 10:08 |
| ssvb | cwillu_at_work: well, any kind of bad things may happen in general, also including xserver crashes on some occasions, so the bug is better to be fixed | 10:08 |
| cwillu_at_work | do I only need that one patch, or do I also need patch 1/2? | 10:09 |
| ssvb | they depend on each other, so both need to be applied | 10:09 |
| cwillu_at_work | okay | 10:09 |
| cwillu_at_work | re: input handling, that explains why it was so much worse when dragging a scroll bar than when using the mouse wheel | 10:12 |
| cwillu_at_work | ssvb, this is only mildly related, but would you know what is required to gain any benefit from the neon routines in pixman? Is a new cairo build also required? | 10:19 |
| cwillu_at_work | (compiling a new kernel, will ping when it completes and I've tested it) | 10:20 |
| ssvb | cwillu_at_work: just neon optimized pixman is enough, cairo upgrade is not required | 10:23 |
| ssvb | cwillu_at_work: also pixman version 0.17.2 has more neon optimized functions and they are faster, git master has even more stuff | 10:23 |
| cwillu_at_work | yep, I was compiling git master | 10:24 |
| cwillu_at_work | among others... :p | 10:24 |
| cwillu_at_work | should it be a dramatic improvement? | 10:24 |
| cwillu_at_work | I'm mainly concerned with scrolling a firefox window at 1280x1024, and I haven't noticed a whole lot of difference | 10:25 |
| ssvb | cwillu_at_work: what is the desktop color depth? | 10:25 |
| cwillu_at_work | Which makes me inclined to think that firefox is either ignoring my efforts, or that I'm optimizing something that's only 1% of the problem anyway | 10:25 |
| suihkulokki | ssvb: re: pixman and neon, is reading /proc/self/auxv really the best way to find out if the cpu supports neon? | 10:25 |
| ssvb | suihkulokki: not sure about this, but it seems to work | 10:26 |
| suihkulokki | yes, but it is a slight problem when run under qemu linux-user where that file is x86 auxv of qemu | 10:28 |
| cwillu_at_work | ssvb, I've tried 16 and 24 | 10:30 |
| lool | suihkulokki: You can override glibc's hwcaps perspective though | 10:30 |
| cwillu_at_work | sorry, missed the question while I was typing :p | 10:30 |
| ssvb | suihkulokki: I see, but ARM CPUs unfortunately do not support any way to identify cpu type from userspace for the 'security reasons' | 10:30 |
| lool | Wont help with pixman but can help with shared libs | 10:30 |
| lool | suihkulokki: Perhaps qemu should provide an emulated /proc in some way though | 10:31 |
| lool | Things like cpuinfo will be bogus as well | 10:31 |
| ssvb | cwillu_at_work: firefox browser does all the rendering in 32bpp and converts the results to the desktop color format as the last step | 10:32 |
| suihkulokki | lool: yeah, Qemu providing virtual /proc to apps running inside qemu would be the correct fix | 10:32 |
| ssvb | cwillu_at_work: 32bpp is slow because memory bandwidth is limiting performance for most operations | 10:33 |
| cwillu_at_work | ssvb, I was under the impression that 24 and 32bit were the same memory layout, and hence I didn't mention that I also tried 32 explicitly :p | 10:33 |
| cwillu_at_work | ssvb, but should I expect to not see any improvement with the neon routines? | 10:34 |
| cwillu_at_work | <cwillu_at_work> my kingdom for a firefox that uses 16bpp internally :( | 10:35 |
| cwillu_at_work | ^^ is that basically the answer? | 10:36 |
| cwillu_at_work | and if that's the case, would there ever be any chance of ubuntu's armel firefox getting patched? | 10:37 |
| ssvb | cwillu_at_work: profiling scrolling in firefox 3.6 beta 5 looks more or less like this for me: http://pastebin.com/m669d1f7f | 10:42 |
| ssvb | cwillu_at_work: looks like it is already 16bpp friendly | 10:43 |
| cwillu_at_work | ssvb, as of 3.6? | 10:43 |
| ssvb | cwillu_at_work: don't know, I just remember that this was not the case for firefox 3.0 and I had a simple patch for it | 10:44 |
| cwillu_at_work | I'm on 3.5 right now, I'll install 3.6 and see if that improves things | 10:44 |
| cwillu_at_work | ssvb, or do I just need to adjust my expectations? | 10:45 |
| cwillu_at_work | i.e., is it fluid for you? | 10:45 |
| ssvb | cwillu_at_work: but still arora browser is much faster than firefox for scrolling | 10:45 |
| cwillu_at_work | I'm fairly reliant on a streamable xmlhttprequest in the browser, which is something of a gecko only thing | 10:46 |
| ogra | suihkulokki, shouldnt that be possible through containers ? | 10:47 |
| ssvb | cwillu_at_work: disregard the previous oprofile report, appears that for scrolling distribution of cpu time between graphics output and browser engine overhead heavily depends on how fast you are scrolling the page | 11:00 |
| cwillu_at_work | rm /tmp/ssvb/hard_data | 11:01 |
| ssvb | cwillu_at_work: this is a comparison of firefox vs. arara for scrolling with arrow down key pressed, firefox: http://pastebin.com/m6f334785 arora: http://pastebin.com/m9f98ed2 | 11:02 |
| ssvb | cwillu_at_work: arora feels much faster and it also spends almost half of the time in pixman, which firefox has a lot of other overhead | 11:02 |
| ssvb | s/which/while | 11:03 |
| cwillu_at_work | kernel just finished building, installing and retesting | 11:04 |
| ssvb | cwillu_at_work: basically these profile reports show that arora benefits from pixman optimizations a lot more and the effect is much more easily visible | 11:04 |
| ssvb | cwillu_at_work: great, let me know about the results | 11:05 |
| cwillu_at_work | just rebooting now (wanted to update some other stuff at the same time, nothing like mixing experiments to save time :p) | 11:17 |
| cwillu_at_work | for no particularly good reason, I've still got it booting into a 32bit framebuffer; if I understand you correctly, there's still a benefit to using 16, correct? | 11:19 |
| cwillu_at_work | (running the test now) | 11:19 |
| cwillu_at_work | hasn't stopped yet | 11:21 |
| cwillu_at_work | unsurprisingly, scrolling is slow as hell while its running :p | 11:21 |
| ssvb | cwillu_at_work: 32bit framebuffer is slower because there is more data to process, also display refresh steals some of the memory bandwidth | 11:22 |
| ssvb | cwillu_at_work: what is your screen resolution? | 11:22 |
| cwillu_at_work | ssvb, 1280x1024 :p | 11:22 |
| ssvb | cwillu_at_work: ok, same here | 11:22 |
| cwillu_at_work | the sigalarm testcase looks good, hasn't crashed yet | 11:23 |
| cwillu_at_work | ssvb, with an otherwise idle cpu, is firefox smooth on your hardware? | 11:23 |
| cwillu_at_work | I get about 3 frames per second | 11:23 |
| cwillu_at_work | during full-screen scrolling | 11:23 |
| ssvb | cwillu_at_work: it is *much* better for me, probably at least 10 frames per second | 11:23 |
| ssvb | cwillu_at_work: but it is subjective impression, I did not run tests with camera | 11:24 |
| cwillu_at_work | ssvb, 10 frames is just short of fluid, but still acceptable | 11:24 |
| cwillu_at_work | ssvb, would be able to compare against ff-3.5 would you? | 11:25 |
| ssvb | cwillu_at_work: it would take time to build ff-3.5 | 11:26 |
| cwillu_at_work | no apt-get? :p | 11:26 |
| cwillu_at_work | rebooting under 16bpp | 11:26 |
| ssvb | brb | 11:28 |
| cwillu_at_work | <3 | 13:33 |
| ssvb | cwillu_at_work: any news? | 13:41 |
| cwillu_at_work | performance seems to be respectable for a smaller scrolling region, I think I need to do some a/b tests to prove that they're actually better though | 13:42 |
| cwillu_at_work | the glitching is definitely fixed by that patch, I've got it sent to my upstream, who grumbled about Russel being up to his usual self such that they were never applied | 13:43 |
| cwillu_at_work | oh, hi rcn-ee, you joined :) | 13:44 |
| rcn-ee | hey cwillu_at_work, so did the patches help with pixman? i haven't been able to test them myself.. | 13:46 |
| cwillu_at_work | rcn-ee, yes, I actually sent them after I had verified that they worked this time :) | 13:46 |
| === bjf-afk is now known as bjf | ||
| * bizkut is away (i am away now) | 16:33 | |
| === bizkut is now known as bizkut-offline | ||
| * armin76 rofls | 16:34 | |
| armin76 | ah, too bad lool is not here :D | 16:35 |
| === bizkut-offline is now known as bizkut | ||
| asac | ogra: you said you had a fix for apex? | 18:48 |
| asac | http://launchpadlibrarian.net/36670366/buildlog_ubuntu-lucid-armel.libgd2_2.0.36~rc1~dfsg-3.1ubuntu1_FAILEDTOBUILD.txt.gz | 18:49 |
| asac | http://launchpadlibrarian.net/36947837/buildlog_ubuntu-lucid-armel.libgphoto2_2.4.7-0ubuntu1_FAILEDTOBUILD.txt.gz | 18:49 |
| asac | NCommander: you have buildd powers? | 18:50 |
| asac | e.g. can you give back with good prio? | 18:50 |
| asac | last build failure might be just fixed? | 18:50 |
| asac | hmm libtool still ftbfs | 18:51 |
| * asac kicks off a build | 18:51 | |
| NCommander | asac, yeah, I can do that | 19:00 |
| NCommander | asac, which package needs a nudge | 19:00 |
| armin76 | NCommander: nageia is the buildd that doesn't do anything :) | 19:04 |
| asac | NCommander: nevermind. thought libtool wasnt retried | 19:09 |
| asac | NCommander: dove images broken/not booting? or just test builds? | 19:11 |
| NCommander | asac, the issue was that I didn't notice that we haven't had an alternate build in almost a month. cjwatson looking at antimony to see what went wrong | 19:11 |
| ogra | asac, http://paste.ubuntu.com/351393/ | 19:12 |
| ogra | (it doesnt respect CFLAGS) | 19:12 |
| ogra | but that only fixes the initial build failure, at the end it fails with a cast error in link.cc | 19:12 |
| ogra | well, "link.cc:236: error: invalid conversion from 'const char*' to 'char*'" | 19:14 |
| ogra | anyway, off again | 19:14 |
| asac | ogra: what context? | 19:15 |
| ogra | apex | 19:15 |
| ogra | you asked for my apex fix | 19:16 |
| asac | ogra: kk | 19:16 |
| asac | i can check | 19:16 |
| asac | ogra: if still there ... why -marm? is that a workaround or the right fix? | 19:17 |
| ogra | apex is a bootloader for armv5 | 19:18 |
| asac | oh ;) | 19:18 |
| ogra | and doesnt have any thumb support | 19:18 |
| asac | yeah | 19:18 |
| asac | makes sense | 19:18 |
| asac | ogra: why is it in main? | 19:18 |
| ogra | it is used for the nslu2 | 19:18 |
| ogra | that was our first supported armel arch before wer had any HW | 19:18 |
| asac | guess we dont support it anymore? | 19:19 |
| asac | e.g. we should unseed/demote it ;) | 19:19 |
| ogra | it can happily go to universe, but i feel bad if i demote it in that state | 19:19 |
| asac | sure | 19:19 |
| asac | should be fixed | 19:19 |
| ogra | yeah ... would feel like dumping trash on the MOTU | 19:19 |
| asac | ogra: do you know if its seeded or why it didnt get demoted in karmic? | 19:19 |
| asac | we want to fix all universe armel only failures too ;) | 19:19 |
| asac | just that we start in main as its on top of that webpage ;) | 19:20 |
| ogra | it didnt ftbfs and nobody had it on the radar | 19:20 |
| ogra | probably my fault since i cared for it in jaunty and didnt look after it later | 19:20 |
| asac | ogra: well. but afaik it shows up in component-mismatches unless its pulled in thorugh some mechanism | 19:21 |
| asac | just wnat to understand what is that ;) | 19:21 |
| asac | but no hurry | 19:21 |
| ogra | i think its just seeded in supported | 19:22 |
| ogra | that makes it not show up on the mistmatches page | 19:22 |
| asac | dyfet: checked chrome? | 19:28 |
| asac | kk | 19:28 |
| dyfet | asac: not extensivily but it works | 19:29 |
| dyfet | asac: and feels fast(er)... | 19:30 |
| dyfet | or did you mean chromeos rather than chromium browser? | 19:30 |
| asac | nope | 19:30 |
| asac | our packages | 19:30 |
| asac | good | 19:31 |
| armin76 | thanks to me *g* | 19:31 |
| dyfet | asac: since it imports, I dumped my mozilla directory onto the box and let it try to import my bookmarks and passwords, it did not seem to import my passwords entirely though... | 19:36 |
| asac | dyfet: entirely? but parts? | 19:38 |
| dyfet | yes | 19:38 |
| asac | dyfet: any pattern what got imported and what not? | 19:38 |
| asac | maybe compare what you see in show passwords in ffox and chromium | 19:39 |
| dyfet | I am not sure, but they were all form based, and it happened to be one site it only filled the email/login id, not the password field | 19:39 |
| dyfet | but again I did not go through very many sites with it yet | 19:39 |
| asac | ok. if in doubt i would start comparing the show passwords dialog in preferences of firefox/chrome | 19:41 |
| asac | maybe its a bug about detecting password/input fields | 19:41 |
| asac | or something | 19:41 |
| dyfet | asac: it feels like there is more in my firefox saved passwords...in fact, there is some I can already confirm are missing | 19:43 |
| asac | JamieBennett: there still? | 19:43 |
| JamieBennett | asac: yes | 19:43 |
| asac | JamieBennett: someone claimed that n.b.l-efl isnt localized ... e.g. like the applications and categories etc. | 19:43 |
| dyfet | asac: never mind, I found the ones I thought were missing :) | 19:43 |
| asac | good :) | 19:44 |
| asac | JamieBennett: can you confirm that thats the case in our lucid build? | 19:44 |
| JamieBennett | asac: ummm, not sure, not something I've looked into but I can check | 19:44 |
| asac | that would be great | 19:44 |
| asac | JamieBennett: how do one best try the launcher? does it just show up as a session variant in gdm? | 19:45 |
| JamieBennett | When I installed it I just ran it from the command line | 19:45 |
| JamieBennett | asac: It seems that it is localized, most strings come from the .desktop. lfelipe has tested and can confirm along with k-s | 19:48 |
| asac | JamieBennett: ok. is sound recorder localized? | 19:50 |
| asac | like in chinese? | 19:51 |
| JamieBennett | no idea ;) | 19:51 |
| JamieBennett | I use neither :D | 19:51 |
| asac | JamieBennett: so you say you confirmed it by starting in a different language? | 19:52 |
| asac | (on your own?) | 19:52 |
| JamieBennett | asac: I confirmed it by asking the developer, I can play around with the local install I have if you need that but lfelipe says he can provide up-to-date screenshots for anything we need | 19:53 |
| JamieBennett | k-s also confirmed | 19:53 |
| asac | confirmed by running or by thinking ? | 19:56 |
| asac | i am find if they say they run lucid packages and all is there | 19:56 |
| asac | its just that we got a report about this ;) | 19:56 |
| asac | s/find/fine/ | 19:56 |
| asac | so developers saying "it should work" ... might not be right approach ;) | 19:57 |
| cwillu_at_work | I find your lack of faith disturbing | 19:59 |
| asac | faith? | 20:00 |
| cwillu_at_work | "it should work" | 20:00 |
| cwillu_at_work | therefore: it should work. | 20:00 |
| cwillu_at_work | (I'm done now :p) | 20:01 |
| asac | yes. but if there is a complain about it not working, its ok to double check :) | 20:01 |
| JamieBennett | I don't have a lucid desktop install at the moment, I'll set one up (its on the todo list for today anyway) | 20:08 |
| asac | JamieBennett: no need to if you dont have the infrastructure to check. just thought you had all in place | 20:10 |
| JamieBennett | asac: not in a Lucid environment yet, something I will fix tonight | 20:10 |
| asac | hehe | 20:11 |
| asac | i should upgrade too | 20:11 |
| asac | e.g. ~end of jan | 20:34 |
| * bizkut is away (i am away now) | 20:41 | |
| === bizkut is now known as bizkut-offline | ||
| asac | bad away messages ;) | 20:41 |
| asac | dyfet: so did you check the moblin media player? | 20:41 |
| armin76 | haha | 20:41 |
| armin76 | where's lool! | 20:42 |
| armin76 | !seen lool | 20:42 |
| ubot4 | I have no seen command | 20:42 |
| asac | armin76: he left this channel | 20:42 |
| armin76 | bah, useless bot | 20:42 |
| armin76 | well, he just dissapeared in a net split :) | 20:42 |
| asac | yes.... so he left the channel | 20:42 |
| asac | because whereever i am is the main channel :-P | 20:42 |
| asac | armin76: so did you finally manage to get something usable wrt chromium? | 20:43 |
| armin76 | asac: nah, segfault when building v8 | 20:43 |
| armin76 | i'll try building on my armv7 board, but i'm busy building other stuff | 20:44 |
| armin76 | thats what happens when you only have one board :) | 20:44 |
| armin76 | could be that either something is broken or that doesn't build on armv5te | 20:45 |
| armin76 | asac: build it on jaunty :) | 20:45 |
| NCommander | asac, I thought we had a working chromium on ARM ... | 20:49 |
| asac | NCommander: we have ... armin76 doesnt | 20:51 |
| armin76 | :D | 20:51 |
| armin76 | NCommander: he's using an ugly patch though! | 20:53 |
| NCommander | armin76, ? | 20:53 |
| armin76 | NCommander: asac is using an ugly patch to make it work :) | 20:54 |
| armin76 | s/work/build | 20:54 |
| asac | hey. i have the right one ... just need to check | 20:55 |
| mturquette | could someone point me to the apt repositories for the dove and babbage boards? | 20:59 |
| * armin76 points to asac and NCommander | 21:00 | |
| armin76 | NCommander: btw meet mturquette, he wants ubuntu rocking on omap | 21:01 |
| NCommander | mturquette, its just the normal ports repo for bost | 21:01 |
| asac | mturquette: http://ports.ubuntu.com/ubuntu-ports/ | 21:02 |
| asac | deb http://ports.ubuntu.com/ubuntu-ports/ lucid main restricted | 21:02 |
| asac | deb-src http://archive.ubuntu.com/ubuntu lucid main restricted | 21:02 |
| asac | etc | 21:02 |
| mturquette | ah, makes sense. thanks NCommander / asac. | 21:03 |
| armin76 | mturquette: yw :) | 21:04 |
| === bizkut-miau is now known as bizkut-redhat | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!