**** BEGIN LOGGING AT Wed Dec 19 02:59:59 2012
Dec 19 08:44:26 <ant_work> Jay7: hello, seems zeldin is using some (un)common framebuffer so stride is not width*cpp
Dec 19 09:17:18 <Jay7> ant_work: I see
Dec 19 09:17:46 <Jay7> well, good idea to merge then
Dec 19 09:17:53 <Jay7> but with testing
Dec 19 09:18:00 <ant_work> I'm still thinking about endianness...check at compile time or runtime? Seems gcc has some optimizations
Dec 19 09:18:21 <Jay7> at compile time
Dec 19 09:18:23 <ant_work> do you prefer macros?
Dec 19 09:19:00 <Jay7> but I like your idea about RGB <-> BGR swap according to endianess
Dec 19 09:19:23 <ant_work> in fact you have 4 cases but just 2 results
Dec 19 09:19:36 <Jay7> yeah
Dec 19 09:19:48 <Jay7> RGB-BGR/LE-BE
Dec 19 09:20:23 <ant_work> I've googled and there is people preferring to check on compile time and others saying runtime is also ok and will be ptimized
Dec 19 09:20:31 <ant_work> i.e. this   http://stackoverflow.com/questions/1001307/detecting-endianness-programmatically-in-a-c-program
Dec 19 09:20:59 <ant_work> I hope we can now do less checks
Dec 19 09:21:05 <Jay7> I see no point in runtime detection
Dec 19 09:21:49 <ant_work> I was hoping we can just convert to BE
Dec 19 09:21:50 <ant_work> color = (uint32_t)c1 << 16 | (uint32_t)c2 << 8 | (uint32_t)c3;
Dec 19 09:21:56 <ant_work> if necessary
Dec 19 09:22:07 <ant_work> but then we have the bitshifting in the code :/
Dec 19 09:22:26 <ant_work> in each fb_plot*
Dec 19 09:22:41 <Jay7> I'll look over that code with endianess in mind
Dec 19 09:24:32 <ant_work> here some snippets like reverseInt
Dec 19 09:24:34 <ant_work> http://www.ibm.com/developerworks/aix/library/au-endianc/index.html?ca=drs-
Dec 19 09:32:01 <ant_work> hm...in fstype.c we did
Dec 19 09:32:03 <ant_work> #define cpu_to_be32(x) __cpu_to_be32(x)	/* Needed by romfs_fs.h */
Dec 19 09:32:15 <ant_work> *and*
Dec 19 09:32:16 <ant_work> #if __BYTE_ORDER == __BIG_ENDIAN
Dec 19 09:32:44 <ant_work> iirc the second one was added by Thesing but people upstream criticized :/
Dec 19 09:33:14 <ant_work> they use   *bytes = __be32_to_cpu(sb->size);
Dec 19 09:53:35 <ant_work> ok, usually the filesystem are stored big endian
Dec 19 09:55:00 <ant_work> but jffs2 can be both...
Dec 19 15:36:32 <dromede_> i have pushed two new branches to my github kexecboot repo
Dec 19 15:36:42 <dromede_> one is the source tree cleanup i was talking about
Dec 19 15:37:15 <dromede_> the other is the immediate_boot, now renamed to autoboot, branch
Dec 19 22:19:13 <ant_home> bluelightning: hey
Dec 19 22:19:40 <ant_home> any plan to save the older linux kernels in meta-hh from bitrotting?
Dec 19 22:20:32 <ant_home> otherwise pls think about an /obsolete parking
Dec 19 22:43:17 <bluelightning> ant_home: hi
Dec 19 22:43:54 <bluelightning> I'd like to update them... apparently there are some patches that need to be applied
Dec 19 22:55:06 <ant_home> great
Dec 19 22:55:09 <ant_home> Jay7: http://paste.debian.net/217356
Dec 19 22:55:48 <ant_home> I'll test now
Dec 19 23:04:49 <ant_home> bluelightning: can you imagine to get some big endian device in your hands? Possibly with display...
Dec 19 23:16:04 <bluelightning> ant_home: isn't ARM bi-endian?
Dec 19 23:16:23 <ant_home> I thought os
Dec 19 23:16:26 <ant_home> *so
Dec 19 23:16:54 <ant_home> http://cateee.net/lkddb/web-lkddb/CPU_BIG_ENDIAN.html
Dec 19 23:17:30 <ant_home> http://cateee.net/lkddb/web-lkddb/ARCH_SUPPORTS_BIG_ENDIAN.html
Dec 19 23:43:10 <ant_home> Jay7: all works as before on qvga/vga-resized after patch
Dec 19 23:43:23 <ant_home> I'll add a bit of comment
Dec 19 23:44:30 <ant_home> bluelightning: btw, how should we 'track' the patches to be conform?
Dec 19 23:44:48 <ant_home> I mean in meta-handheld and meta-initramfs
Dec 19 23:45:17 <ant_home> I've never looked attentively, iirc there are a couple of fields to add
Dec 20 00:15:39 <ant_home> Jay7: 2 patches pushed a new fork on github
Dec 20 00:29:18 <ant_home> gn
**** ENDING LOGGING AT Thu Dec 20 02:59:59 2012