**** BEGIN LOGGING AT Sat Dec 08 02:59:59 2012 Dec 08 16:29:45 bah...problems with collie-battery now :/ Dec 08 16:30:14 what's wrong? Dec 08 16:30:35 some headers changed Dec 08 16:31:14 linux/mfd/ucb1x00.h and include/linux/mfd/mcp.h Dec 08 16:32:23 http://paste.debian.net/215090/ Dec 08 16:32:29 that's after 3.3 Dec 08 16:33:27 6 patches to ucb1x00, probably collie_battery.c needs only minor adjusting Dec 08 16:37:16 Jay7: let see if some other dev joins Dec 08 16:53:37 * Jay7 looking over dromede's changes Dec 08 16:54:12 he made FB global variable and removed pointer to FB from all functions Dec 08 16:55:23 * Jay7 is trying to imagine when multiple FB structures may be needed Dec 08 17:20:49 well, maybe not in the initramfs Dec 08 17:21:14 "global and compile time allocated" Dec 08 17:43:02 hi channel Dec 08 17:47:03 dromede: hello Dec 08 17:47:24 dromede: I've looked over your fb refactoring Dec 08 17:48:30 trying to find situation when more than one FB is needed Dec 08 17:49:07 just to check that we are not on wrong way when removing fb pointer from functions call Dec 08 17:50:21 i read that you guys are planning a hackathon today Dec 08 17:50:30 unfortunately, im not home Dec 08 17:50:34 so i can only comment on my patches Dec 08 17:50:55 now, about the global fb struct Dec 08 17:51:43 i couldn't think of a possible scenario where you might need two structs Dec 08 17:52:17 so it made sense to me that a single global struct is a good way to go Dec 08 17:52:42 I'm not very happy with global structures.. but ok Dec 08 17:53:09 neither am i Dec 08 17:53:20 but there are valid cases when they can be used Dec 08 17:53:53 i think this is one of them Dec 08 17:54:03 and it only affects code in fb.c Dec 08 17:54:21 and only if you actually want to use the gui Dec 08 17:55:25 now, about my second fb patch Dec 08 17:55:27 Jay7: how is in psplash? Dec 08 17:55:41 our code was based on psplash Dec 08 17:55:52 did they use pointer to fb? Dec 08 17:56:00 yes iirc Dec 08 17:56:11 then I would keep it Dec 08 17:56:39 we are too far from original psplash code already Dec 08 17:56:53 yes but why did they do that? Dec 08 17:56:56 i think fb.c was based on psplash fb code Dec 08 17:57:04 http://git.yoctoproject.org/cgit/cgit.cgi/psplash/tree/psplash-fb.h Dec 08 17:57:10 dromede: yes, you are right Dec 08 17:57:11 they must have thought it's ok Dec 08 17:57:29 thesing was used that code to create fb.c Dec 08 17:57:39 imho having primitive drawing functions that take 6 or 7 arguments is not very optimal Dec 08 17:58:21 with my patches, drawing primitives only take 4 arguments Dec 08 18:01:53 dromede: have you seen the patches in zeldin branch? Dec 08 18:02:06 link please Dec 08 18:02:16 https://github.com/kexecboot/kexecboot/network Dec 08 18:03:58 Jay7 needs to find the right order to merge fb.c patches Dec 08 18:04:13 I have plan :) Dec 08 18:04:21 1) finish ubifs merge Dec 08 18:04:27 \°/ Dec 08 18:04:30 2) dromede's patches Dec 08 18:04:40 bgr/rgb mixup is fixed in my second fb patch Dec 08 18:04:44 3) zeldin's patches over dromedes Dec 08 18:05:23 endianess fixes would have to be rebased on top of mine _if_ my second patch is valid for 32 bit displays Dec 08 18:05:46 same probably goes for stride computation patch Dec 08 18:06:34 but let's deal with them one by one Dec 08 18:07:35 dromede, btw, OT, have you seen the thread in lakml about multiple machines? Dec 08 18:07:54 I'm not sure but I remember some problems with stride Dec 08 18:08:32 may be when viewport is not equal to real dimensions Dec 08 18:09:25 ant_work: you mean this one ? Dec 08 18:09:27 [ARM] head.S change broke platform device registration? Dec 08 18:09:31 dromede: "if multiple boards defined in. config, we can proceed to boot only the last" Dec 08 18:09:41 was: Multiple board support is broken Dec 08 18:10:22 no i didn't Dec 08 18:10:30 as is said, im not home Dec 08 18:10:35 i'll look at it tomorrow Dec 08 18:10:56 now, back to kexecboot Dec 08 18:10:56 sounds similar Dec 08 18:11:04 yea, sorry Dec 08 18:11:17 no problem Dec 08 18:11:37 do you guys have any more comments on making the fb struct global? Dec 08 18:12:04 no, I don't Dec 08 18:13:29 dromede: is https://github.com/mkatic/kexecboot/commit/2d892967f412f93cd05f6477004f1225ace8c242 ready to import? Dec 08 18:13:44 (ignore A_NONE) Dec 08 18:14:30 same question about immediate boot https://github.com/mkatic/kexecboot/commit/587754a7caafa8be1610d6e4ec6957fcb0c3adec Dec 08 18:14:30 this one only deals with the symptoms, not with the actual cause Dec 08 18:14:51 i still don't know why we get 5 events after every keypress Dec 08 18:15:14 ah Dec 08 18:15:21 ok, I'll try to investigate further Dec 08 18:15:22 but then again, code in main loop shouldn't be triggered on A_NONE events Dec 08 18:15:31 true Dec 08 18:15:33 so i would say yes, it's ready for import Dec 08 18:16:01 this one greatly reduces menu lag on Cxx0 machines Dec 08 18:16:06 look also at art2art patches. seems elegant Dec 08 18:16:30 no idea about impact of #include Dec 08 18:16:41 can't be too big Dec 08 18:16:43 ant_home: his repo is not up-to-date Dec 08 18:16:51 sys/queue.h is from FreeBSD Dec 08 18:16:55 immediate_boot is not yet ready, i need to include support for more keys Dec 08 18:16:56 BSD licensed Dec 08 18:16:59 and touchscreen support Dec 08 18:17:16 dromede: I see Dec 08 18:17:27 ok, let's postpone immediate boot then Dec 08 18:17:31 Jay7: ah, ok, I've just seen he's using high level lib Dec 08 18:18:19 dromede: the multiple keypress happen on Z since we switched to matrix driver iirc Dec 08 18:18:56 after 2.6.32 iirc Dec 08 18:19:24 note that poodle (locomo driver) spits as well Dec 08 18:19:31 I fear I've made error when refactoring previous code Dec 08 18:19:44 that part of code was changed when implementing TUI Dec 08 18:20:17 i can't comment on art2art patches, i never looked at menu.c code Dec 08 18:20:36 art2art can't upload his changes today Dec 08 18:20:47 so, postpone his patches as well Dec 08 18:22:25 what's missing on github are the other patches done to implement more options for kexec Dec 08 18:22:42 iirc was --hardreset Dec 08 18:23:12 but again, the devil is in fb.c now ;) Dec 08 18:24:17 i think fb.c changes should start with my "fb global struct" patch Dec 08 18:25:05 then we can comment on my second fb patch, this one is far more disruptive Dec 08 18:25:26 ant_home: can you collect all floating patches together tonight? :) Dec 08 18:25:35 and it should be tested on 32 bit displays, i can only confirm that it works on 16 bit displays Dec 08 18:25:51 dromede: I'll try in qemu Dec 08 18:25:52 openwrt has some, I have a first link Dec 08 18:25:54 http://code.google.com/p/wl-700ge/source/browse/trunk/package/kexecboot/?r=188#kexecboot%2Fpatches Dec 08 18:26:39 i already tried in qemu. iirc, qemu fb is also 16 bit Dec 08 18:27:54 well.. then let's wait for bugreports :) Dec 08 18:27:58 about openwrt patches; only 010-tty.patch might be interesting Dec 08 18:28:23 yes, 010-tty is interesting but we need replace it anyway Dec 08 18:28:39 we need way to get tty on top of which FB is residing Dec 08 18:29:03 I've tried to do some quick research but w/o success Dec 08 18:29:04 jay7: i'd rather we test it on a real 32 bit framebuffer first Dec 08 18:29:24 i tested it on my workstation framebuffer and it was broken Dec 08 18:29:29 32 bit support i mean Dec 08 18:29:36 hm.. Dec 08 18:29:39 but that could be due to the nvidia framebuffer being tiled Dec 08 18:30:48 i looked over my changes many times and i couldn't find a reason why it wouldn't work on 32 bit displays Dec 08 18:31:22 the patch itself makes a lot of sense to me Dec 08 18:31:37 basically, it changes the way we calculate color Dec 08 18:32:12 with my patch, color calculation is done only once, before calling drawing primitives Dec 08 18:32:39 there's no reason to calculate pixel values for every pixel and line we draw Dec 08 18:34:30 cool Dec 08 18:36:52 brb Dec 08 18:39:33 the main rationale of my fb patches was to go from this: Dec 08 18:39:38 typedef void (*plot_pixel_func)(FBPTR fb, int x, int y, kx_ccomp red, kx_ccomp green, kx_ccomp blue); Dec 08 18:40:37 and this: Dec 08 18:40:43 typedef void (*draw_hline_func)(FBPTR fb, int x, int y, int length, kx_ccomp red, kx_ccomp green, kx_ccomp blue); Dec 08 18:41:01 to this: Dec 08 18:41:03 typedef void (*plot_pixel_func)(int x, int y, kx_rgba color); Dec 08 18:41:12 typedef void (*draw_hline_func)(int x, int y, int length, kx_rgba color); Dec 08 18:41:33 and to reduce code in drawing primitives Dec 08 18:42:28 I got your point Dec 08 18:42:40 * Jay7 reading http://www.kernel.org/doc/Documentation/fb/fbcon.txt Dec 08 19:15:49 Jay7: look at the end Dec 08 19:15:50 http://tldp.org/HOWTO/Framebuffer-HOWTO/x134.html Dec 08 19:16:33 you can add many framebuffer vdevices Dec 08 19:18:24 /sys/class/graphics/* Dec 08 19:18:28 may be interesting Dec 08 19:26:32 http://www.armadeus.com/wiki/index.php?title=FrameBuffer Dec 08 19:26:44 here they suggest just use tty1 always Dec 08 19:26:57 may be it's good idea Dec 08 19:27:50 ant_home: do you have build env ready to do some tests? :) Dec 08 19:30:32 jay7: what's a good idea? Dec 08 19:30:57 do not try to guess on which console /dev/fb0 is residing Dec 08 19:31:08 just use tty1 Dec 08 19:31:17 may be via configure option Dec 08 19:32:32 Jay7: yes, I can quickly build Dec 08 19:43:20 i have to go, i'll be back tomorrow Dec 08 19:43:21 bye Dec 08 19:51:30 ant_home: I'm going to merge your last ubifs patch as is Dec 08 19:51:46 it's hart to make it better right now Dec 08 19:51:49 *hard Dec 08 20:33:44 there is common code, trying to get the mtd id Dec 08 20:34:05 for other reasons, I've found a routine Dec 08 20:34:09 mom Dec 08 20:34:53 but pls check memory allocation Dec 08 20:36:38 see get_mtd_number Dec 08 20:36:44 http://paste.debian.net/215124/ Dec 08 20:53:15 ant_home: last ubifs patch pushed :) Dec 08 20:54:23 well.. let's merge dromede's patches Dec 08 21:15:32 dromede's first patch is ok Dec 08 21:16:17 but second (fb.c: refactor line and pixel drawing routines) break display colors Dec 08 21:16:32 will push first one Dec 08 21:26:06 hm Dec 08 21:35:54 seems, colors are mixed somewhere Dec 08 21:36:05 tested on 24-bit Dec 08 21:36:11 bgr/rgb mixup is fixed in my second fb patch Dec 08 21:36:25 hm.. Dec 08 21:36:35 how is in zeldin patch? Dec 08 21:38:21 ah, is only for 32b Dec 08 21:38:55 it's ok for 16bit Dec 08 21:39:38 but broken on 24 Dec 08 21:39:50 and I can't switch qemu to 32bit Dec 08 21:40:21 wait, it skips 24b.. Dec 08 21:40:33 ah, I've using 24 bpp on host Dec 08 21:40:43 so no 32bit, sure Dec 08 21:41:06 + case 24: Dec 08 21:41:08 + case 32: Dec 08 21:41:28 yes, no break Dec 08 21:41:40 24 bpp is the same as 32 bpp w/o alpha channel Dec 08 21:41:51 as far as I understand Dec 08 21:44:01 right Dec 08 21:46:55 static char *offset; Dec 08 21:47:00 + *(offset) = color & 0x00FF0000; Dec 08 21:47:04 hm.. Dec 08 21:47:19 if color = 0x00FF0000 e.g. Dec 08 21:47:32 then we have color & mask = 0x00FF0000 Dec 08 21:47:56 which we are trying to place into char (one byte) Dec 08 21:48:40 now I know why all interface is red in 24-32bpp Dec 08 21:48:48 red is lowest byte Dec 08 21:49:32 well, now I know what is wrong.. let's drink tea and try fix it :) Dec 08 21:50:46 I see, offset+2 Dec 08 22:19:05 big endian case break dromede's optimisation AFAIU Dec 08 22:20:05 it would be nice to hear from zeldin Dec 08 22:20:52 (he's a videogames dev) Dec 08 22:23:10 yeah.. Dec 08 22:37:25 then is maybe better to pull the A_NONE patch for main and then the zeldin fixes Dec 08 22:37:44 finally we'll rediscuss with dromede and zeldin the endianness Dec 08 22:38:24 about removing support for 1,2,4 I never tested that Dec 08 22:39:44 let fb.c refactor pending if you have doubts Dec 08 22:39:49 I'll push semi-optimized version then Dec 08 22:40:13 or not.. Dec 08 22:41:05 I'm not sure dromede will have enough time to merge zeldin's bigendian changes Dec 08 22:42:15 yes but on the other side zeldin could help testing this refactoring if we start without endiannes bugs Dec 08 22:42:37 it would be one single patch for both ;) Dec 08 22:43:43 I've fixed dromede's version for 24bpp Dec 08 22:43:57 I think 32bpp version should work as is Dec 08 22:51:51 pushed Dec 08 22:59:50 Jay7: about autoboot.. Dec 08 23:00:21 maybe letting one use '0' instead? /* Seconds before default item autobooting (0 - disabled) */ Dec 08 23:00:49 default 60 or more Dec 08 23:00:52 I think we should merge autoboot and immediate boot Dec 08 23:01:05 not sure, how exactly Dec 08 23:01:06 0 = immediate Dec 08 23:01:34 fb is drawed but just for an instant Dec 08 23:01:44 I have to check Dec 08 23:03:15 I understend he wants one to start with zGRom Dec 08 23:03:27 so he can ship a boot.cfg Dec 08 23:03:54 but I think if there is 0 delay it can be ebough Dec 08 23:04:14 hm Dec 08 23:04:16 no way Dec 08 23:04:22 but what happens to other items? Dec 08 23:04:23 autoboot is configure option Dec 08 23:04:41 ah.. from other side.. Dec 08 23:04:54 yes Dec 08 23:05:36 you can parse images with delay Dec 08 23:05:47 delay == 0 Dec 08 23:05:58 but then how do you come back to menu? Dec 08 23:05:59 I've pushed A_NONE patch too Dec 08 23:06:23 hm..it is like an auto-start SD/CF Dec 08 23:06:33 autorun.inf :) Dec 08 23:06:54 maybe just check for the presence of a file, yes Dec 08 23:07:34 then again, conflicts are possible (in theory) Dec 08 23:07:51 SD and CF both with autorun... Dec 08 23:08:07 yeah Dec 08 23:09:05 we need boot list like BIOS then Dec 08 23:09:17 HDD->USB->CD->FD Dec 08 23:09:20 :) Dec 08 23:09:27 hehe Dec 08 23:09:31 and boot menu :) Dec 08 23:10:13 I remember someone complains about .gitignore inside git repo Dec 08 23:10:29 but can't remember any con's Dec 08 23:11:16 maybe about new files added if you build in that ddir Dec 08 23:11:26 like config.h Dec 08 23:11:36 what do you think if I'll remove it from repo? Dec 08 23:11:41 like config.h :) Dec 08 23:12:42 well, anybody should pull and build in master.,. Dec 08 23:12:59 with OE it's impossible Dec 08 23:15:26 ah, lumag added this Dec 08 23:15:47 maybe it's usual for kernel devs to build in the cloned master Dec 08 23:17:05 man gitignore give answer Dec 08 23:17:23 · Patterns which should be version-controlled and distributed to other repositories via clone (i.e., files that all Dec 08 23:17:25 developers will want to ignore) should go into a .gitignore file. Dec 08 23:18:40 so it should be in repo Dec 08 23:18:52 but may be should be cleaned up slightly Dec 08 23:19:26 this .gitignore should not hurt imho Dec 08 23:19:42 ok Dec 08 23:19:46 Jay7: ah, pls upgrade 0.5.9 version Dec 08 23:20:04 but I'll remove config.h from repo and will add it to .gitignore Dec 08 23:20:17 but hey, wait for 1.0 Dec 08 23:22:52 well, dromede's changes are upstreamed Dec 08 23:23:09 except immediate boot Dec 08 23:23:19 should I do a quick test at this point? Dec 08 23:23:49 yes please Dec 08 23:24:03 9732fa4ca9cbe9f220736494590bdbf653ac958a Dec 08 23:25:24 yes Dec 08 23:25:38 I've called it 0.5.9.1 Dec 08 23:25:48 for OE Dec 08 23:25:48 I've done compile&run tests in qemu x86 Dec 08 23:26:07 0.5.10 :) Dec 08 23:26:29 out of memory :p Dec 08 23:29:11 I'm rebuilding known 3.2 Dec 08 23:33:30 I think it's enough for today :) Dec 08 23:33:39 merge night is over Dec 08 23:34:14 tomorrow we need to discuss with dromede big endian changes by zeldin Dec 08 23:35:53 first two and last two patches seem ok Dec 08 23:36:08 the 4th is now superseded Dec 08 23:37:28 ok, it has built Dec 08 23:38:32 check ubifs and GUI speed Dec 08 23:43:36 menu is faster Dec 08 23:44:12 there is still some delay descending the menus Dec 08 23:44:31 then you trigger the repetition and it's too fast Dec 08 23:44:47 but it's ok, we can refine Dec 08 23:45:06 I'll see on spitz, was slow there Dec 08 23:45:38 but please change the version..is confusing Dec 08 23:47:18 may be release 6.0? Dec 08 23:47:33 yes, I've booted ubifs :) Dec 08 23:47:36 better with big endian changes though Dec 08 23:48:04 seems low hanging fruit Dec 08 23:48:18 yes, some bytes shuffling Dec 08 23:48:46 but we need one who can and will test it on big endian machine Dec 08 23:49:23 iirc pxa could run be Dec 08 23:49:42 anyway, there is too late Dec 08 23:49:54 I'm going to bed Dec 08 23:50:20 ok, thx for the work Dec 08 23:50:34 I'llwait for OE, I cannot reuse 0.5.9 :/ Dec 08 23:50:51 np, let's try to continue during tomorrow day Dec 08 23:51:10 ok Dec 08 23:51:11 gn Dec 08 23:51:11 good night **** ENDING LOGGING AT Sun Dec 09 02:59:58 2012