=== Baybal_ is now known as Baybal === hrw|gone is now known as hrw [08:43] morgen [08:58] * cwillu pokes [08:59] you're not rcn-ee :/ [10:50] if I want to change something in ubuntu kernel config for panda how to get .config in other way then cp /boot/config-*? [10:51] hrw, that's the only way, unless /proc/config has been enabled in the kernel (which it hasn't in ubuntu afaik() [10:52] cwillu_at_work: "apt-get source linux-ti-omap4" gave me ubuntu source package but it uses split config [12:39] hrw: to get the running defconfig, just run zcat /proc/config.gz [12:40] let me rephrase question: how to get kernel config from inside of linux-ti-omap4 source package? [12:42] hrw: ok, sorry. the config shall be in a folder debian.ti-omap4/config/config.common.ubuntu. Do you have this file in the source package? [12:45] yep - but tahts all? [12:46] hrw: yes, what did you expect? [12:46] preferred to be sure - split configs exists for a reason [12:47] hrw: right, it is not used in this case, not sure why actually... [12:48] sebjan_: one flavour only [12:49] yes, it makes sense... [14:28] hrw, so looking at your genesi f-k patch, it seems to expect that /boot is a vfat [14:28] that wont work [14:49] ogra: flash-kernel is set of hacks already [14:49] hrw, that doesnt solve the probelm that /boot cant be vfat :) [14:49] on smarttop it is ext2 by default [14:50] smartbook I mean [14:50] oh, that seems fine then, is it the same on smartbook ? [14:50] ah [14:50] markos_: does smarttop has /boot/ also on pata drive like it is in smartbook? [14:51] and does it use ext2 too ? [14:51] :) [14:51] ogra: initially it used vfat but now with new uboot it's able to use ext2 as wel [14:51] but yes [14:52] hrw, well, if its all ext2 then your patch seems fine to me [14:53] it needs a uboot upgrade though [14:53] ogra: I would prefer rewrite of whole script but no devices to check does it works properly on all [14:53] old smarttops will have to be upgraded first [14:54] hrw, i would prefer we split flash-kernel in functions and device spcific parts ... but i guess that needs wider discussion with debian-arm [14:54] yep [14:54] i.e. have a flash-kernel-common package that provides script snippets we can source [14:55] ogra: even flash-kernel can get rewrite properly [14:56] well, heh [14:56] f-k is somewhat constantly being rewritten [14:56] compare omap_flash_kernel and efikamx_flash_kernel functions [14:57] both have update_uImage_symlink() update_initrd_symlink() [15:00] hrw, well, theye functions come from NCommander for his generic update [15:00] which is very broken anyway [15:01] they neerd fixing all over [15:01] *need [15:04] I am a bit tired of rewriting update scripts again and again [15:04] few years ago I merged 5-6 zaurus update scripts into one [15:04] right [15:04] took year to get it tested on all supported devices and 2-3 developers more [15:04] what i want is device specific functions separate from HW specific ones [15:05] i.e. update NAND ... update u-boot_vfat separated from the omap or dove or whatever functions [15:06] it looks like omap and dove support was added by ubuntu [15:06] yes [15:06] omap was initially aded by me, dove comes from NCommander [15:07] both were completely redone when NCommander added the "improved subarch detection" stuff [15:07] style is completely different [15:07] yes [15:07] it was initally identical [15:07] but the spec was implemented in a way to use uname instead of /proc/cpuinfo [15:08] which breaks the style === JaMa is now known as JaMa|Off [15:10] hrw, for that part you should discuss with NCommander [15:11] this change also introduces bugs for unsupported boards ... i.e. it makes it try to flash to NAND on blaze (where no nand exists) [16:18] how to get default set of kernel options for arm device in ubuntu? [16:22] hrw, /boot/config-$(uname -r) [16:22] for source config, ask the kernel team [16:22] don't know exactly how the kernel selects the default options for arm in general [16:22] k [16:22] but at the git repository you can already check what is common [16:22] http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=blob;f=debian.master/config/armel/config.common.armel;h=0f0e053b1780d9d67b9c0ac7d1051fabf3d176b8;hb=HEAD [16:22] for example [16:22] as the master repo has both omap and versatile [16:22] well, the actual config is merged from nippets during package build iirc [16:22] yup [16:22] *snippets [16:23] ok [16:23] thx [16:23] hrw: but the "default" options is something that maybe someone from the kernel team can help you [16:23] easiest is really to just wget the binary and dpkg -x it i bet [16:23] ok [16:23] trying to make efikasb kernel to be more ubuntu like [16:24] build a package ;) [16:24] already did [16:25] ah, cool [16:25] there are also some extra ubuntu sauce generally applied at ubuntu's kernel [16:25] don't know if you wan to check those too [16:25] hrw: and which version are you building? the stock 2.6.31 kernel? [16:25] you should add them if possible, often distro userspace features correspond to them [16:26] rsalveti: yes 2.6.31.14.6 [16:26] and do not plan to add ubuntu patches on top of it [16:26] * hrw is not kernel hacker [16:27] oh, are you guys talking about linaro kernel or ubuntu kernel? [16:27] what i did for the ac100 kernel was to ssh into my panda that had a source tree, copy the config to .config and then run make menuconfig on both [16:27] none of those cooloney [16:27] rsalveti: how's going, had a nice vacation? [16:28] hrw: got this, man [16:28] its very time consuming to do it that way but you will end up with modtly identical configs [16:28] *mostly [16:28] cooloney: yup, very nice :-) [16:28] rsalveti: great. man [16:29] * cooloney just read a news, Marvell release a qual-core ARM chip [16:29] CONFIG_SCSI_MULTI_LUN is not set in TI-omap4... bad [16:29] cooloney: how was plumbers? [16:30] hrw: ti-omap4 unfortunately doesn't contain all arm common defines at the master repo [16:30] http://www.marvell.com/company/news/press_detail.html?releaseID=1447 [16:30] rsalveti: very good [16:31] met several linux-omap folks and other ARM guys [16:31] rsalveti: extra fun is that efikas have usb-wifi which rt2800usb does not want to load firmware for (and same firmware works with staging driver) [16:31] cooloney: cool :-) [16:32] hrw: what's CONFIG_SCSI_MULTI_LUN for? [16:32] hrw: haha :-) [16:32] hrw: i guess it is for some multi volume USB disk? [16:32] cooloney: Prompt: Probe all LUNs on each SCSI device [16:32] cooloney: think: real multislot card readers for example [16:33] does the efika have that ? [16:33] cooloney: and I have one of those [16:33] ogra_ac: I have such on usb [16:33] * GrueMaster drools over the marvel XP specs. [16:33] oh, that doesnt show as usb disks ? [16:33] intresting [16:35] ogra_ac: without multi_lun only CF works. with: cf, sd, ms, xd [16:35] well, then we should enable it asap [16:35] file a bug ;) [16:35] ogra_ac: popular cheap multislot readers have one controler so one card at time. this one handle 4 cards at same time [16:37] hrw: good point. could you please file a bug, then we can SRU a patch [16:37] bug 672635 [16:37] Launchpad bug 672635 in linux-ti-omap4 (Ubuntu) "enable CONFIG_SCSI_MULTI_LUN (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/672635 [16:39] * ogra_ac triages it properly [16:40] hrw: thx, man, you are so quick [16:41] sbambrough, hey [16:41] hey ogra_ac [16:41] sbambrough, are you subscribed to ubuntu-devel ? [16:42] (the mailing list) [16:42] i sent some questions regarding the possibility about using linaor kernels to it today, might intrest you too [16:42] *linaro [16:43] ogra_ac, I don't believe I am [16:43] https://lists.ubuntu.com/archives/ubuntu-devel/2010-November/031952.html [16:43] cooloney, ^^^ something to bring up at the kernel team meeting i belive [16:46] ogra_ac, your right they do interest me, though I don't have any answers right now [16:46] ogra_ac: ok, got it. [16:46] sbambrough, yeah, i dont expect answers right now, but we need to find some ;) === hrw is now known as hrw|gone [17:51] ogra_ac: were you able to test the new qt packages? [17:51] rsalveti, yes [17:51] and? [17:51] Illegal instruction [17:51] :( [17:51] see the bug [17:51] tiago also commented [17:52] oh, cool, too much emails at my inbox [17:53] sadly it doesnt seem to work as expected [17:53] tiagos test of just running the lib seems to show no misdetectin though [17:55] Might be another failure point. [17:55] i.e. i dont get the processor features line he mentions [17:55] GrueMaster, well, its definitely NEON related given just building it with NEON disabled makes it all work fine [17:56] What I mean is it may be code that is ouside the run-time detection. [17:57] ogra_ac: remember he's using qt 4.7.1 while posting at the bug [17:57] rsalveti, yeah [17:57] maybe this processor features is not there for the version we're using [17:57] I don't get it even on panda [17:57] yup [17:58] * ogra_ac hasnt set up his panda yet for cross checking [17:58] What's the bug number again? I can test the code on my dove to verify. [17:58] i have barely unpacked my suitcase [17:58] bug 664431 [17:58] Launchpad bug 664431 in qt4-x11 (Ubuntu Natty) (and 2 other projects) "QT on armel is built with NEON by default (affects: 2) (dups: 1) (heat: 30)" [Undecided,New] https://launchpad.net/bugs/664431 [18:01] ogra_ac: does it also crashes while running QT_NO_NEON=1 mumble? [18:01] yep [18:02] could be the case that the features thing is not working the way expected [18:02] yes, i would expect so [18:02] I don't believe it was ever tested on a no-neon hardware [18:02] to sad that slangasek already dropped the working packages [18:03] "working"? those packages were sitting verification-failed for some time before I removed them [18:03] would be good to trace the error [18:03] slangasek, huh ? who did set that ? [18:03] * ogra_ac checks the bug [18:04] hi all - if anyone has a second to help me get rcn-ee's scripts working for a beagleboard, I'd love a hand [18:04] slangasek, now thats weird, while i see that pitti set it to failed i dont get why [18:04] ogra_ac: because it was reported to regress on non-NEON systems [18:05] Jefro, best is to wait for rcn-ee for that [18:05] slangasek, err, no, exactly the opposite [18:05] slangasek, it fixed it for non-NEON systems [18:05] oh right; it was reported to regress on NEON systems [18:05] ogra_ac - thanks [18:05] which is nonsense [18:05] [18:06] given we announce that no library in maverick will do NEON [18:06] so it breaks a commitment [18:06] no library in maverick will *require* NEON [18:06] right [18:07] given that QT in maverick can currently only be build with statically having NEON on or off my upload was a proper fix [18:07] that upstream tried to add dynamic detection doesnt make the fix less valid [18:09] until we have a dynamic fix in place at least [18:10] ogra_ac: I also believe it is a post release regression to just disable it at qt [18:10] I know we're saying we're building without neon by default [18:10] but would be strange for users to have qt running slower because of an update [18:10] well [18:10] doesn't make sense to me [18:10] talk to davidm [18:11] that's why I thought it would be better to just fix the run time detection [18:11] i had a pretty strict request to switch it off immediately [18:11] ogra_ac: why? it's a ubuntu discussion in general, I understand the problems [18:11] yes, i agree that runtime detection is a better fix, but if it doesnt work we have to fix it another way [18:12] sure, in case it doesn't work we just disable it [18:12] and apparently the only way is static atm [18:12] but first let's try to get the proper fix in [18:12] right [18:12] but the "proper" fix seems ot require far more currently [18:12] since just backporting from upstream doesnt seem to work [18:13] it seems, let's at least get the correct trace [18:13] and identify what's happening [18:13] don't think that will take a lot of time [18:13] no [18:14] what i'm concerned about it that i already drown in mail from people running QT apps on the ac100, that the working packages were removed from proposed is a bit disturbing [18:14] I know, but let's give at least one or two days to try to get the proper fix [18:14] yes [18:15] now that you have the hardware and can try to trace the problem [18:15] if we're unable to fix, push the new packages without neon at all and we're fine [18:15] right, though i wont do that tonight anymore ... i'm jetlagged and did get off a plane less than 24h ago [18:16] ogra_ac: sure, take your time [18:16] ogra_ac: go to sleep then :-) [18:16] i would have tested during plumbers, but they dont have an elmo (read: the network there was so bad that most of us couldnt even get their mails) [18:17] yeah, elmo rocks [18:17] uds was perfect [18:17] to early for bed yet ... need to stay up to get my schedule correct [18:17] just thinking is a bit hard atm :) [18:17] :-) [18:18] plumbers was depressing overall [18:19] ogra_ac: why? no interesting stuff to discuss this year? [18:19] now that they are over upstart vs systemd they start bashing us for copyright assignment [18:20] haha, they will always find something to complain :-) [18:20] well, there was intresting stuff but i didnt like the mood [18:20] also seeing how lennart pulled strings to make all upstreams use systemd and Keybuk not being there at all to be able to stop that was annoying [18:20] seems that many userspace things will defauolt to systemd in the near future [18:21] i.e. gnome-session will go away [18:21] got it [18:21] all in all it felt like a redhat/intel conference [18:21] i felt very misplaced [18:21] but it was, somehow [18:21] yes [18:22] its just sad to see that so many important decisions are made there and that they are made with an anti ubuntu attitude in mind === zyga is now known as zyga-afk === robclark_ is now known as robclark [18:53] ogra_ac: rsalveti: Ok, after many interruptions, I finally downloaded the QT library from https://launchpad.net/~rsalveti/+archive/armel/+files/libqtcore4_4.7.0-0ubuntu5_armel.deb and it seems to be ok on my dove. [18:53] GrueMaster, you can run mumble ? [18:53] thats my testcase on the ac10 [18:53] 0 [18:53] Haven't tried mumble. [18:54] This is on my dove buildd (rack in basement). [18:54] should fail while loading mumble [18:54] right [18:54] Other system has been offline since Dallas. [18:54] you should get a SIGILL [18:55] I ran it according to the instructions in the bug, comment #30. Will find some test apps. [18:55] comment 30 is useless with our version [18:55] 8as you can see from the above discussion) [18:57] could -mfpu=neon optimize general fp code at the qt build? [18:58] then it'll fail for sure [18:58] I may give my son some spare hw next time I see him. He knows a lot about QT. [18:58] GrueMaster, just run mumble ;) [18:58] thats a safe test [18:58] no need to install a desktop for that, just use ssh -X user@dove mumble [18:58] I can't. The system has a minimal install for building. No X. [18:59] Still need to install for dependencies. [18:59] use a chroot [18:59] its not that it will take much time with a local mirror [18:59] I'll unpack my A0 and get it running in a bit. [19:00] It looks like it will take 64 minutes just to pull the PPA packages. [19:00] They're not mirrored. [19:00] ah [19:02] Not sure if it is my end or lp, but I am only getting 3.8K/s pulling the packages from rsalveti's ppa. [19:09] Jefro, ping [19:11] rcn-ee hey! thanks - I am having difficulty with the beagleboard script [19:11] hey Jefro,which of the scripts are you haing issues with? is it doing something odd? [19:11] ./setup_sdcard.sh gives me a syntax error [19:12] ./setup_sdcard.sh: line 333: syntax error near unexpected token `>' [19:12] that might be a bashism.. ;) [19:12] it must be. the line has a " &>> " in it. [19:13] is that the 'sd.log' part of the script? you can just comment that out, it's just to make it less noisy.. [19:13] I succeeded in getting it to work by putting a space between & and >> but now I think I probably should have just taken out the & and put a 2&>1 at the end [19:13] ah, ok - looking [19:13] yes, that is the sd.log line [19:14] the resulting image, however, fails to boot on my xM A2 [19:14] well, it boots up to a certain point but then fails with 'no init' and leaves me at an (initrd) prompt [19:14] yeah, just nuke the "&>> ${DIR}/sd.log" i'll come up with something else to work better with dash.. [19:15] That's weird, what was your full "./setup..." line? [19:15] (i have an A2 i test it on..) [19:15] ./setup_sdcard.sh --mmc /dev/sdf --uboot beagle --use-default-user [19:15] I'll try it again, just a sec (currently running rsalveti's preinstalled image) [19:16] weird, that's perfect.... [19:18] by chance is it 16/8g card? i've had some users report problems with that, but haven't been able to replicate it.. [19:19] 4G Kingston card [19:19] oops, no, that's the other one - this is a 4G no-name card [19:20] I'll try it on the Kingston card [19:21] another thing, if the script dies on error, it actually doesn't finish building the image.. [19:23] it looked like it completed - running now on different card [19:24] looks like it completed. the last line is "Formatting Boot Partition." [19:24] that's not even close.. ;) [19:24] hoo boy. is there a -v I can turn on? [19:24] I'm running this on Ubuntu 8.10 BTW [19:24] if that makes a dif [19:25] not really, it's a pretty simple/stupid script.. ;) the last thing it really says "Populating rootfs Partition" [19:26] ha... well, that may be why it only got as far as initrd! [19:26] i'm suprised it got that far... if it died after building the first fatfs, there shouldn't have even been an uImage... [19:27] it looks like it populated the boot partition [19:27] this is for a "getting started" article, so I may go with rsalveti's premade script for now and point readers at the rootstock instructions if they want to go further. Does that sound reasonable? [19:27] so maybe 8.04 just didn't like the "&>>"... format fatfs, copy bootloader, format ext, copy rootfs... [19:28] very possibly. I'll try it on my laptop, which has 9.10 installed. [19:30] Jefro: pre-installed image is easier for the first moment [19:30] then you can point for advanced customizations [19:30] and also rcn-ee's kernel [19:30] in case people want to hack the normal ubuntu image [19:31] rsalveti, you guys ready for another sru the next "xm"? ;) (u-boot).. [19:31] rcn-ee: haha :-) [19:32] i saw them on the u-boot list, and went oh my..... ;) [19:35] rcn-ee: that's why for natty we'll be upgrading the x-loader/u-boot when needed [19:35] or at least warn the user that he needs to update it, and create a tool for it [19:36] but yeah, sru all around :-) [19:36] GrueMaster: later on if you want to help and have enough time, please help getting the qt trace [19:37] Will do. [19:37] so we can find where and which instruction is breaking qt [19:37] I'd like to get some kind of qt benchmark, to compare the performance with and without neon [19:38] will try to dig one at the qt examples/tests/demos files at the git tree [19:38] rsalveti rcn-ee thanks for the help [19:39] Thats why I want to get my son involved. He can create one. [19:50] ogra_ac: are you running on the AC100? [19:52] GrueMaster: do you remember where you got the cpuburn package while stressing panda at dallas? [19:53] don't remember if vstehle gave us or we just got it somewhere [19:53] rlameiro, yes, i do [19:54] rsalveti, GrueMaster, you need to grab the latest cpuburn at http://pages.sbcglobal.net/redelm/ and compile the arm binaries [19:54] vstehle: cool, thanks [19:54] ogra_ac: How is it working? does everything works now? I am lining to buy one... on amazon [19:54] need to push that to our archive [19:54] orbarron: ^ [19:54] rcn-ee - new data point, when I used 9.10 to write the card it did get all the way to "populating rootfs" but still doesn't boot: "No init found." and an (initramfs) prompt. [19:55] rlameiro, nope, things are slowly getting better i think, but i havent tried any of the new hacks from phh yet [19:55] (I requested packaging in Bug #651576) [19:55] Launchpad bug 651576 in cpuburn (Ubuntu) "cpuburn now has Cortex-A8 and Cortex-A9 versions, please build for armv7a (affects: 1) (heat: 95)" [Undecided,New] https://launchpad.net/bugs/651576 [19:55] ok [19:55] i go to the ac100 to see if I can extract more info ;) [19:55] they are just trying to get backlight on/off on lid close to work [19:56] rcn-ee, poke poke [19:56] i personally was traveling fo ra few weeks, just got back yesterday [19:56] hey cwillu_at_work that zippy still failing? [19:56] hey; only when I start up the network [19:56] haven't been able to get any kernel messages out of it though [19:57] cwillu_at_work: zippy giving you trouble? [19:57] so every boot... how do you like the ck patchset? [19:57] prpplague, ooo, both of you at the same time :) [19:57] cwillu_at_work: zippy or zippy2 ? [19:57] 2 [19:57] prpplague, ks8851 troubles, specifically [19:58] rcn-ee, nothing conclusive yet; I'm using it on this desktop, and it seems to be an improvement, although I'm waiting another week until I say that for sure [19:58] (the problem with long uptimes is that you're never sure if things are faster because you rebooted, or because of the thing you changed that caused you to reboot) [19:58] okay, cool... i have a patchset saved on my work machine for the ck stuff that i'm about to push.. ;) [19:59] true true.. [19:59] prpplague, want to know about my ks8851 troubles? :p [19:59] cwillu_at_work: yea [20:00] prpplague, cable plug events don't seem to make it to network manager et al [20:00] prpplague, I hacked something up with mii-tool (which polls the mii status directly once per second) to simulate the behaviour [20:00] cwillu_at_work: do the events show up on the CL level? [20:00] nope [20:00] interesting [20:01] you using it with a panda or beagle? [20:01] beagle [20:01] c3 and c4 [20:01] vstehle: pulling it now. [20:01] prpplague, no, the _interesting_ part is that if I restart network manager _while_ copying data to a local machine _while_ mii-tool is running, everything dies [20:01] right now i only have panda's at my desk, i'll have to pick up a beagle from the office to do some testing [20:02] interestin [20:02] I think I have a stack trace around still [20:02] it dies in a weird fashion too :) [20:02] processes go into uninteruptable state; I _think_ it's when they try to access the network, but I'm not certain (x will hardlock, for instance) [20:02] sysrq-w shows them in that state though [20:03] the end of the dmesg is a preempt count oops or something [20:03] * cwillu_at_work looks for it [20:11] sorry, my hairy electrician called [20:11] * cwillu_at_work starts looking again [20:11] prpplague, http://pastebin.com/ZPXdqwfw [20:11] * prpplague looks [20:11] I've got another trace with some magic sysrq info as well [20:12] cwillu_at_work: interesting [20:16] sysrq log coming === zyga-afk is now known as khr [20:20] prpplague, http://pastebin.com/vdrrr8iL [20:20] * prpplague looks === khr is now known as zyga [20:21] prpplague, I don't know that it's related, but:: I had rcn-ee compile me a 2.6.36 with ck2 (con kolivas's patchset with scheduler and vm changes) for kicks; it works fine under fairly heavy load for days, until I connect the zippy's ethernet and configure the interface; moments later, the system hardlocks [20:22] I haven't been able to capture any messages from such a failure though [20:22] just a rough guess would be that the communication with the KS8851 is getting part of the packet trashed and it is trying to read beyond the allocated packet [20:22] i'd have to check but there were some similar problems reported with blaze [20:23] (blaze uses the KS8851 in the exact same way as the zippy2) [20:24] prpplague, I _don't_ get the problem unless I have both mii-tool running _and_ I restart network-manager _and_ there's network activity at the wrong time [20:25] I've noticed this sporadically when poking a beagle remotely (i.e., the far end of a 128kb link), but I can trigger it every time if I scp a couple hundred megs locally, with "mii-tool -w" running, and then restarting network-manager with the transfer still running [20:26] my guess is that mii-tool is holding something open that network-manager causes to be reset or whatever, at the same time as a packet comes in and does what you said before [20:26] sporadically == once or twice a day [20:27] interesting [20:27] since I disabled my mii-tool hack, (restarting network-manager when an ssh connection dies rather than when mii-tool -w spits out a line), I haven't seen a single crash yet in two weeks [20:29] I'm also suspicious that my ck2 crashes are related, given the scheduling changes + the "note: omap2_mcspi[14] exited with preempt_count 1" I get from a non ck2 kernel [20:29] just can't prove it :p [20:29] I've got several beagles and zippies and sd cards that I can duplicate this on, too :p [20:32] (note, those two traces are on different kernels; the earlier was 2.6.35rc5, longer one was 2.6.35.7 [21:06] * cwillu_at_work pokes at prpplague [21:07] fixed it yet? :D [21:08] cwillu_at_work: i'll have to see if i can replicate it on a beagle, all i have right now are pandas [21:08] can a panda use a zippy2? [21:08] Hello all +~ [21:09] * cwillu_at_work shorts RXShorty to ~neutral [21:09] Does anyone here has a Sharp Netwalker? [21:10] The reason I ask that Ubuntu 9.04 is getting old with packages, maybe someone already made a 10.04 version? [21:12] * rsalveti brb === zyga is now known as zyga-afk [22:01] rsalveti: hi [22:02] rsalveti: i was looking at pixman build log on LP, and it seems that it got compiled with NEON enabled. is that expected? [22:02] ogra: hi. see ^^^ in case you are here too [22:04] ndec: pixman has runtime neon detection [22:04] armin76: really? that's cool. i didn't know [22:05] armin76: is that documented? [22:05] ndec: i'm not sure, you'd have to ask ssvb since he did the work [22:13] armin76: looking at src, i think it's implemented in pixman-cpu.c, function _pixman_choose_implementation(). thanks for the tip [22:21] ndec: could you please help to take a look at this bug 666267 [22:21]