**** BEGIN LOGGING AT Fri Sep 28 02:59:56 2012
Sep 28 08:24:15 <ant_work> dromede: have you found the bug making menu redraw 6 times (iirc)?
Sep 28 08:25:08 <ant_work> strangely the menu is only slow on spitz (maybe on akita too). On c7x0(vga) and on poodle(qvga) is ok
Sep 28 08:26:15 <ant_work> fwiw I've also seen that pressing a key triggers multiple events (matrix driver ?)
Sep 28 08:29:54 <Jay7> dromede: thanks, I'll review when have time
Sep 28 08:30:15 <Jay7> ant_work: he found and sent me quick fix for this
Sep 28 08:38:50 <ant_work> ah, ok, great
Sep 28 09:20:28 <dromede> do c7x0 and spitz use the same keyboard driver?
Sep 28 10:01:21 <ant_work> yes, https://patchwork.kernel.org/patch/77252/
Sep 28 10:01:43 <ant_work> tosa too
Sep 28 10:58:04 <dromede> can you confirm that a key triggers multiple events on the corgi as it does on spitz?
Sep 28 11:20:49 <ant_work> yes
Sep 28 11:21:22 <dromede> hm
Sep 28 11:21:48 <ant_work> for poodle too, I discovered that when it was missing kernel keymap
Sep 28 11:22:00 <dromede> it's no wonder why it works well on the poodle, much less pixels to deal with (qvga)
Sep 28 11:22:11 <dromede> but i can't explain why it's faster on corgi
Sep 28 11:22:21 <ant_work> it's a different fb driver
Sep 28 11:22:26 <dromede> really?
Sep 28 11:22:35 <dromede> corgi doesn't use pxafb?
Sep 28 11:23:27 <dromede> ah
Sep 28 11:23:29 <dromede> w100fb
Sep 28 11:23:40 <ant_work> yes
Sep 28 11:24:21 <dromede> well then it's faster on corgi devices because the framebuffer is in video memory
Sep 28 11:24:48 <dromede> as opposed to system memory on spitz devices
Sep 28 11:25:22 <dromede> and i guess w100fb handles rotation aswell
Sep 28 11:26:10 <dromede> my guess rotation is the main difference in menu performance
Sep 28 11:26:21 <dromede> i did try using kexecboot in portrait mode on akita
Sep 28 11:26:35 <dromede> the difference in performance was _very_ noticeable
Sep 28 11:27:19 <dromede> i made it draw in portrait mode and directly on the fb
Sep 28 11:27:24 <dromede> lot's of flicker
Sep 28 11:27:26 <dromede> but very fast too
Sep 28 11:32:31 <ant_work> c7x0 does not need rotation
Sep 28 11:32:41 <dromede> right
Sep 28 11:32:46 <dromede> well, then that's probably it
Sep 28 11:32:48 <ant_work> probably is in hw, right
Sep 28 11:33:26 <dromede> if only they left the w100 chip in newer zaurii models...
Sep 28 11:34:07 <ant_work> heh, remember that we lost the accelerated X driver ...
Sep 28 11:34:19 <ant_work> bitrot
Sep 28 11:34:29 <dromede> you still have kdrive
Sep 28 11:34:54 <ant_work> in OE I'd say it's finally deprecated, so tslib
Sep 28 11:35:12 <dromede> kdrive was removed from OE-Core
Sep 28 11:35:42 <ant_work> anyway, I'd like to remove the #ifdef zaurus from kexecboot...with a partition parser
Sep 28 11:36:25 <ant_work> I'm very near to repartition on the fly with BLKPG iocl but it's much more clean if the kernel does read the partitioning at boot...
Sep 28 11:37:59 <ant_work> if the Zaurus is the only device needing 'fake' partitioning at runtime, there is lttle sense to adapt kexecboot
Sep 28 11:38:41 <dromede> well, the suspend/resume bug is finally fixed, that was my main focus&concern
Sep 28 11:38:50 <dromede> now i can focus on other kernel issues
Sep 28 11:38:52 <ant_work> thats great wrt kernel
Sep 28 11:39:12 <dromede> i'll spend some time with the mtd subsystem
Sep 28 11:39:18 <dromede> i don't know when but i will
Sep 28 11:39:19 <ant_work> unfortunately I'm pretty sure poodle and c7x0 have some issues
Sep 28 11:39:30 <ant_work> with recharging
Sep 28 11:40:14 <ant_work> i.e. all is fine after cold-coot (remove and reinsert battery)
Sep 28 11:40:34 <ant_work> how shoul I properly verify the device is really charging?
Sep 28 11:40:56 <dromede> a multimeter will know for sure
Sep 28 11:41:05 <ant_work> well, yes
Sep 28 11:41:24 <dromede> so corgi and poodle have trouble with online charging ?
Sep 28 11:41:45 <ant_work> it's long I don't debug but yes, smthg strange
Sep 28 11:42:01 <ant_work> i.e. after kexecboot kernel boots, charging led goes off
Sep 28 11:42:22 <dromede> reinsert the cable again, it should turn on
Sep 28 11:42:24 <ant_work> and I suspect it isn't recharging while in kexecboot
Sep 28 11:42:59 <ant_work> the old 2.6 kernels did not have this problem
Sep 28 11:43:31 <dromede> i am aware of this bug, i know where it happens
Sep 28 11:43:47 <dromede> as i said, when the led goes off, simply reinsert the cable
Sep 28 11:44:20 <dromede> the led will stay on and the device will charge
Sep 28 11:44:22 <ant_work> not ethat at least poodle, sometimes need the same treatment even after battery is removed
Sep 28 11:44:29 <ant_work> ..sometimes...
Sep 28 11:47:07 <ant_work> (note that the same poodle doesn't 'power-off' but restarts, unless battery switch is open :)
Sep 28 11:47:22 <ant_work> kernel is not 100
Sep 28 11:47:26 <ant_work> %
Sep 28 11:47:32 <ant_work> :/
Sep 28 11:48:14 <ant_work> anyway, I'm testing the new kernels built with minimal provided fragments
Sep 28 11:48:21 <ant_work> they boot
Sep 28 11:48:39 <dromede> 3.4?
Sep 28 11:48:59 <ant_work> yes, but my point is about the features
Sep 28 11:49:12 <ant_work> we'll use the standard KTYPE
Sep 28 11:49:33 <ant_work> so we'll get a pre-fixed skeleton where we can add our config fragments
Sep 28 11:50:00 <dromede> i'm not familiar with the linux-yocto kernel build system
Sep 28 11:50:01 <dromede> but
Sep 28 11:50:02 <ant_work> I'm pretty sure Yocto crow has exensivelytested the feature-set with oe-core images
Sep 28 11:50:25 <dromede> strange that vanilla 3.4 will boot
Sep 28 11:50:30 <dromede> can i see your kernel config?
Sep 28 11:50:34 <ant_work> th point is: the usb modules, the filesystems, the debug level...all is defined in small .cfg files
Sep 28 11:50:40 <dromede> for 3.4?
Sep 28 11:50:59 <ant_work> iirc I did boot 3.4 months ago
Sep 28 11:51:10 <ant_work> I have the recipe only locally
Sep 28 11:51:26 <dromede> i just want to see the defconfig
Sep 28 11:51:35 <ant_work> I don't know if it is worth to update the 3.2 or commit directly the 3.4
Sep 28 11:51:52 <ant_work> heh, the point is that you will not able to 'check' by seeing the defconfigs
Sep 28 11:52:19 <ant_work> fragments are sparse, you'll need a  bitbake -c menuconfig and inspect your build dir
Sep 28 11:52:48 <dromede> yes, i want the one from the kernel build dir
Sep 28 11:52:48 <ant_work> frragments are in /meta of the kernel recipe you have in your WORKDIR
Sep 28 11:53:10 <dromede> 3.4 shouldn't boot, that's my point
Sep 28 11:53:12 <ant_work> hm... maybe I can send you some older pre-work with full defconfig...
Sep 28 11:53:16 <dromede> but i hope i'm wrong
Sep 28 11:53:21 <dromede> please do
Sep 28 11:53:26 <ant_work> I'll test in a few hours
Sep 28 11:53:30 <ant_work> spitz?
Sep 28 11:53:33 <dromede> if i'm wrong, that's one less patch to worry about
Sep 28 11:53:36 <dromede> yes please
Sep 28 11:53:54 <ant_work> iirc I booted poodle and corgi
Sep 28 11:54:08 <ant_work> spitz was under dust until your ZGRom
Sep 28 11:54:10 <ant_work> :)
Sep 28 11:54:41 <ant_work> seriously, there are much more devs on spitz so I take care of the others
Sep 28 11:57:32 <ant_work> for those models, one idea could be having a ZGRom and another rescue image on nand, the game/ROMS on CF/SD
Sep 28 11:57:45 <ant_work> we'll need toresize the nand, though
Sep 28 12:00:45 <dromede> ZGrom will go public later this week
Sep 28 12:00:47 <ant_work> ...but atm we would not be able to boot the ZGRom from jffs2/ubi :/
Sep 28 12:01:07 <ant_work> how big was it, uncompressed?
Sep 28 12:01:34 <dromede> around ~150mb
Sep 28 12:01:47 <dromede> and that's just the apps/emu/engines
Sep 28 12:01:59 <dromede> engines expect game data in the same directory
Sep 28 12:02:01 <ant_work> hm, do you have any jffs2 image to check the size?
Sep 28 12:02:08 <dromede> no
Sep 28 12:02:25 <dromede> nand in not suitable for current ZGrom rootfs design
Sep 28 12:02:43 <ant_work> can't you make a link?
Sep 28 12:02:53 <ant_work> or even unionfs?
Sep 28 12:03:07 <dromede> it wasn't a priority
Sep 28 12:03:12 <ant_work> ah, ok
Sep 28 12:03:18 <dromede> sd/cf cards are dirt cheap these days
Sep 28 12:03:26 <ant_work> heh, true
Sep 28 12:03:27 <dromede> so i didn't bother much with nand
Sep 28 12:03:40 <ant_work> on Z it's still faster
Sep 28 12:03:51 <dromede> true, but not by much
Sep 28 12:04:01 <dromede> nand might make an impact on boot time
Sep 28 12:04:25 <ant_work> yes, boot from ubifs *is fast*
Sep 28 12:04:36 <dromede> but that's about it, no game engine/emulator would benefit from nand
Sep 28 12:05:25 <dromede> pixman is giving me grief, i cant build it
Sep 28 12:05:38 <dromede> looking at the logs, it's trying to apply the same patch twice
Sep 28 12:06:18 <ant_work> heh, I remember to have read on spitz the CF contrroller can hog the bus and thus the LCD can be disturbed
Sep 28 12:06:45 <dromede> that was true for wifi cards, yes
Sep 28 12:06:56 <dromede> this never happened to me with cf flash cards
Sep 28 12:07:14 <dromede> and the wifi card issue can be fixed with proper bus arbiter configuration
Sep 28 12:07:44 <ant_work> this is one example of the code where linux-yocto should do the right thing
Sep 28 12:08:18 <ant_work> i.e. we don't define any of those kernel parameters and rely on yosto configuration
Sep 28 12:08:23 <ant_work> *yocto
Sep 28 12:09:02 <ant_work> I'm still a bit dubios, they tested deeply on x86 and on beagleboard
Sep 28 12:09:22 <dromede> currently, there is no way to configure the bus arbiter at runtime
Sep 28 12:09:31 <dromede> i wrote a very nice sysfs interface for it
Sep 28 12:09:38 <ant_work> ah, ok
Sep 28 12:09:38 <dromede> and i lost the patch :/
Sep 28 12:09:41 <ant_work> :/
Sep 28 12:11:24 <ant_work> I hope to be able to reduce the defconfig to a few kb. Now I'm at 11-12Kb but there is much more to clean
Sep 28 12:12:03 <dromede> and what's the size of the 3.4 linux-yocto zImage?
Sep 28 12:13:30 <dromede> hm, this is interesting
Sep 28 12:13:48 <dromede> both OE-Core meta and meta-openembedded have pixman recipe
Sep 28 12:13:53 <dromede> *recipes
Sep 28 12:14:23 <dromede> actually no
Sep 28 12:14:40 <dromede> there's a bbappend in meta-oe
Sep 28 12:15:05 <dromede> that includes two identical patches
Sep 28 12:16:25 <dromede> hm, that can't be right
Sep 28 12:16:32 <ant_work> http://cgit.openembedded.org/meta-openembedded/log/?qt=grep&q=pixman
Sep 28 12:16:39 <ant_work> 2012-09-10	pixman: drop patches, merged to oe-core
Sep 28 12:17:30 <ant_work> mayb you are not up-to date
Sep 28 12:17:51 <dromede> hmm, i'm using combo-layer to update all of my layers
Sep 28 12:18:47 <dromede> yep, misconfigured combo-layer
Sep 28 12:18:47 <dromede> good
Sep 28 12:22:05 <dromede> maybe we should add a bbappend for pixman in meta-handhelds
Sep 28 12:22:17 <dromede> current recipe completely disables iwmmxt detection
Sep 28 12:22:35 <dromede> and pixman received a lot of iwmmxt optimisations in the last two years
Sep 28 12:22:47 <dromede> most of the mmx code was converted to iwmmxt code
Sep 28 12:31:45 <ant_work> good idea
Sep 28 12:33:26 <ant_work> now, we don't want meta-handheld to depend on meta-oe
Sep 28 12:33:36 <ant_work> just take care of oe-core's recipe
Sep 28 12:33:43 <dromede> of course
Sep 28 12:33:51 <ant_work> (why is th e.bbappend in meta-oe now?)
Sep 28 12:34:08 <dromede> PRINC := "${@int(PRINC) + 1}"
Sep 28 12:34:14 <dromede> that's all it contains
Sep 28 12:34:52 <ant_work> seems to me absolutely cruft
Sep 28 12:35:08 <ant_work> maybe JaMa forgot to drop the recipe too
Sep 28 12:35:16 <dromede> maybe
Sep 28 12:35:35 <dromede> the bbappend in meta-handheld would only contain a single variable
Sep 28 12:35:42 <ant_work> or meybe he has some .bbapend in shr layer...
Sep 28 12:36:02 <dromede> but before that i have to test whether the current gcc can actually compile pixman with iwmmxt code
Sep 28 12:38:34 <ant_work> don't know why/when it has been disabled.
Sep 28 12:39:09 <dromede> i think it had something to do with cpu detection routines messing with qemu
Sep 28 12:51:46 <ant_work> iirc only a few packages have been built for iwmmxt. Toolchain does support it, though
Sep 28 15:15:06 <dromede> i've uploaded ZGrom kernel changes to my github
Sep 28 15:15:14 <dromede> https://github.com/mkatic/linux/commits/3.2-stable
Sep 28 17:08:36 <ant_work> dromede: pls see if you have time to refactor my last pending patch for kexecboot / ubi. Jay7 is short of time :)
Sep 28 17:09:56 <ant_work> I could do a little better, creating a function for the common code reading the last two digit of e.g. /dev/mtd12
Sep 28 17:10:08 <ant_work> that's all :)
Sep 28 17:10:24 <ant_work> th ememory allocation in that part of code is rather ugly :/
Sep 28 17:12:52 <ant_work> wow, lot of patches for spitz :/
Sep 28 17:13:25 <ant_work> no problem for adding patches in our meta-handheld layer :)
Sep 28 17:14:27 <ant_work> to move forward we/I had to discard most of the patches. Dmitry agreed about collie and tosa. corgi and spitz were vanilla
Sep 28 17:14:47 <ant_work> we only kept some keymaps
Sep 28 17:15:24 <ant_work> do you see value in keeping 3.2?
Sep 28 17:16:03 <ant_work> it's a bit sad most of linux-yocto rework/polishing has been done with 3.4...
Sep 28 17:16:19 <ant_work> I'd jump on 3.4 this weekend if possible
Sep 28 17:17:57 <ant_work> heading home now, bbl
Sep 28 17:37:54 <dromede> bluelightning: is there any good way of crosscompiling packages that need to run just compiled binaries ?
Sep 28 17:38:05 <dromede> with OE ofcourse
Sep 28 17:41:58 <bluelightning> dromede: I'm not sure I understand the question... ?
Sep 28 17:42:18 <dromede> take exult for instance
Sep 28 17:42:30 <dromede> it compiles a tool that generates headers at compile time
Sep 28 17:42:38 <bluelightning> ah ok
Sep 28 17:42:47 <dromede> right
Sep 28 17:43:32 <bluelightning> so, if the tool can actually be built for the host and generate valid output for cross-compilation, then usually we just build a native version (possibly cut-down to only build the tools) and then build the target version with the latter depending on the former
Sep 28 17:44:23 <dromede> are there any examples of this in oe-core?
Sep 28 17:44:27 <bluelightning> if the tool actually must be run in the target environment in order to generate valid output (e.g. gobject-introspection), there's no out-of-the-box solution, but it would have to involve running it in qemu
Sep 28 17:44:37 <bluelightning> dromede: well, Qt; that's a somewhat large example
Sep 28 17:45:09 <dromede> ok, thanks
Sep 28 17:46:00 <bluelightning> there are probably others though
**** ENDING LOGGING AT Sat Sep 29 02:59:57 2012