**** BEGIN LOGGING AT Wed Jul 07 02:59:56 2010
Jul 07 03:53:20 <GNUtoo|laptop> hi
Jul 07 03:53:26 <GNUtoo|laptop> ahhh
Jul 07 03:53:34 <GNUtoo|laptop> The "ext2load" command is broken on u-boot binary earlier than "20080723"
Jul 07 04:13:06 <GNUtoo|laptop> ok done
Jul 07 05:33:32 <mrmoku> shazkhan: oeventsd is one of the components that does not yet have a FSO2 replacement
Jul 07 06:04:05 <PaulFertser> mrmoku|away: moreover it will never have, according to Mickey's plans.
Jul 07 06:05:31 <gena2x> morning, guys.
Jul 07 06:06:07 <gena2x> i want someone to test glamo video playback to check if it working only here.
Jul 07 06:06:36 <gena2x> this is not easy to setup, but i hope might be interesting.
Jul 07 06:07:59 <gena2x> yesterday dos1 failed to setup kernel... and in fact didn't tested anything.
Jul 07 06:08:22 <gena2x> so, may be anyone?
Jul 07 06:09:41 <gena2x> the goal is setup is to watch 640x480x15fps mpeg2 video. common! :)
Jul 07 06:09:56 <lindi-> gena2x: yes but what does it involve?
Jul 07 06:11:23 <gena2x> lindi-: need to install supplied .34 kernel, backup your sd (mine 8gb backup took 4 minutes with dd), better to install 533/88 kernel.
Jul 07 06:11:29 <gena2x> lindi-: need to install supplied .34 kernel, backup your sd (mine 8gb backup took 4 minutes with dd), better to install 533/88 u-boot.
Jul 07 06:12:08 <gena2x> lindi-: turn off X.
Jul 07 06:12:23 <gena2x> lindi-: get video and play :)
Jul 07 06:12:44 <lindi-> gena2x: ok but with .34 sounds don't work?
Jul 07 06:12:45 <gena2x> lindi-: it should work in debian. dos1 had shr and got 'hang udev'
Jul 07 06:13:07 <gena2x> lindi-: yes, video will be without sound. but we testing video, right?
Jul 07 06:13:47 <gena2x> lindi-: all works here.
Jul 07 06:15:16 <lindi-> I've forgotten how to build .34 hmm
Jul 07 06:15:25 <lindi-> I'm sure you told me some time ago the branch and config
Jul 07 06:15:29 <gena2x> lindi-: i proved built kernel.
Jul 07 06:15:39 <lindi-> yes but I don't fancy running binaries from net :)
Jul 07 06:15:40 <gena2x> i will proved kernel and modules.
Jul 07 06:16:24 <gena2x> hm... you want to see changes first?
Jul 07 06:17:00 <lindi-> no I want to always be in the position where I can easily modify stuff I use :)
Jul 07 06:19:52 <lindi-> gena2x: which git branch should I build and with what configuration?
Jul 07 06:21:09 <gena2x> i and using slighly outdated git. 4-7 days ago or so...
Jul 07 06:21:18 <gena2x> i want builds to be same.
Jul 07 06:21:50 <gena2x> and if we'll start sinconizing them.
Jul 07 06:24:58 <gena2x> i do not really want recompiling or any other kind of headaches. dos1 yesterday already tested something unknown for 3 hours.
Jul 07 06:27:46 <gena2x> ok, anyone who do not mind running precompiled kernel?
Jul 07 06:28:42 <gena2x> lindi-: i can provide you patch without any testing of course.
Jul 07 06:31:25 <gena2x> strange. nobody interested?
Jul 07 06:32:59 <gena2x> i spend more than 3 days on this issue nobody can spend 1 hour to do relatively small test?
Jul 07 06:35:47 <sicu> i think it's more a question of it being early morning and people are busy at work
Jul 07 06:36:09 <sicu> i'd be happy to help test, but won't be able to do so before i get home from work this evening
Jul 07 06:36:21 <sicu> gena2x: but your work is much appreciated =)
Jul 07 06:37:11 <gena2x> it's ok, i now that few people are able to do it 'right now' :) . i'll hope someone will ping me today :)
Jul 07 06:38:28 <lindi-> gena2x: is it possible to make cpu frequency selection an option in u-boot or does it happen before options are parsed?
Jul 07 06:39:41 <gena2x> lindi-: frequency is not really important here.
Jul 07 06:39:49 <gena2x> lindi-: the change is in kernel.
Jul 07 06:40:02 <lindi-> gena2x: sure but the frequency changes are interesting too
Jul 07 06:40:20 <lindi-> gena2x: I'd love to have a boot option for 200 MHz that I could use for GPS tracking
Jul 07 06:40:28 <lindi-> with lower power consumption
Jul 07 06:40:39 <lindi-> and then maybe 533 MHz for video playback :)
Jul 07 06:40:58 <lindi-> of course it'd require me to boot often but that'd still be an improvement over the current situation
Jul 07 06:40:59 <gena2x> lindi-: hmm. i think it is possible, but i just used faster route - builded different uboots.
Jul 07 06:41:31 <gena2x> lindi-: in general, _my opinion_ is that it's better to fix cpu-freq.
Jul 07 06:41:44 <lindi-> gena2x: why?
Jul 07 06:41:48 <gena2x> lindi-: and do switches in linux kernel.
Jul 07 06:42:03 <lindi-> gena2x: ok but that does not work despite all the efforts
Jul 07 06:42:05 <gena2x> lindi-: and boot at somehing like 200mhz for example.
Jul 07 06:42:24 <gena2x> lindi-: i hope this can be fixed.
Jul 07 06:42:42 <gena2x> lindi-: and i'll to do it as next task.
Jul 07 06:43:27 <gena2x> lindi-: i'm sure i'll do it if i'll have debug board promised by Weiss in case of successful glamo operation.
Jul 07 06:44:14 <gena2x> lindi-: but as it not hangs, may be it's possible to fix even without dboard.
Jul 07 06:44:59 <gena2x> lindi-: why? hmm. i think in-kernel change will be enought.
Jul 07 06:45:10 <lindi-> gena2x: sure it's enough if you can make it work :)
Jul 07 06:45:46 <gena2x> lindi-: oh, of course, if i'll fail, it can be implemented in uboot.
Jul 07 06:45:58 <lindi-> but bug 2295 has been open for 13 months so I assumed it's too tricky for us to fix
Jul 07 06:46:41 <gena2x> lindi-: i think, we have all docs about serial ports?
Jul 07 06:46:50 <lindi-> gena2x: i think so
Jul 07 06:46:58 <gena2x> lindi-: so see no reason not to fix it.
Jul 07 06:47:11 <lindi-> shaz123: om-gta02-2.6.32 has no "build" script. how did you build it?
Jul 07 06:47:18 <gena2x> oh, yes. .34 is without serial ports too :)
Jul 07 06:47:54 <gena2x> lindi-: so, i concincied you to test with my binaries?
Jul 07 06:48:49 <lindi-> I'll try building .32 first :)
Jul 07 06:49:17 <gena2x> build .34.
Jul 07 06:49:26 <lindi-> _and_ writing down how to build it
Jul 07 06:49:39 <gena2x> i can share _my_ script.
Jul 07 06:49:42 <lindi-> I thought .34 would not do sound or serial so it's not very nice target for testing :)
Jul 07 06:49:46 <gena2x> scripts.
Jul 07 06:49:52 <lindi-> .32 first, then .34 perhaps
Jul 07 06:50:08 <gena2x> but he has no problems with white screens.
Jul 07 06:50:21 <gena2x> *ite
Jul 07 06:50:22 <gena2x> *it
Jul 07 06:50:33 <lindi-> I don't have white screens with .29 either
Jul 07 06:50:44 <lindi-> heh, modified ramconsole patch to repeat every character 8 times for reduncancy
Jul 07 06:51:22 <gena2x> you in finland? no wsod in winter?
Jul 07 06:51:24 <gena2x> :)
Jul 07 06:51:50 <lindi-> no wsod
Jul 07 06:52:25 <gena2x> hmm. i have :( frequenty. with qtmoko and debian kernels :(
Jul 07 06:52:28 <jluis> gena2x: I coud test your binary
Jul 07 06:52:40 <gena2x> jluis: ok.
Jul 07 06:52:53 <gena2x> jluis: are you familiar with u-boot?
Jul 07 06:52:59 <lindi-> gena2x: Qi 9ef7754b8243457c, andy-tracking a3587e4ed77974ad, xserver-xorg-video-fbdev
Jul 07 06:53:11 <jluis> where are it?
Jul 07 06:53:17 <lindi-> that has worked for at least 6 months
Jul 07 06:54:30 <gena2x> lindi-: oh, wsod i hard topic. let me do testing :)
Jul 07 06:54:31 <lindi-> shaz123: copying "build" from andy-tracking resulted in a directory with 'uImage-GTA02.bin' (no version in filename) and no modules tarball
Jul 07 06:54:52 <gena2x> jluis: ok, first - u-boot.
Jul 07 06:54:59 <jluis> gena2x: I can modify the envirmonet variabels 
Jul 07 06:55:20 <gena2x> jluis: ok. first lets try 533/88/clk2 uboot.
Jul 07 06:55:27 <lindi-> gena2x: I could maybe migrate to u-boot and see if it causes WSOD
Jul 07 06:55:43 <lindi-> gena2x: since WSOD avoidance was my only reason to move to Qi
Jul 07 06:57:29 <gena2x> jluis: first, backup your sd card.
Jul 07 06:57:46 <gena2x> jluis: also you'll need to have sdcard installed while testing.
Jul 07 06:57:59 <gena2x> jluis: which distribution you using?
Jul 07 06:58:36 <gena2x> jluis: i did backup with dd | gzip -fast, for 8gb sd it took 4 minutes.
Jul 07 06:58:40 <jluis> gena2x: I've just put a clean uSD 
Jul 07 06:58:51 <jluis> gena2x: u-SHR
Jul 07 06:58:55 <lindi-> shaz123: did you perhaps use arch/arm/configs/gta02_drm_defconfig?
Jul 07 06:59:17 <gena2x> jluis: hm. can you install debian?
Jul 07 06:59:51 <gena2x> jluis: you'll need only mplayer as software.
Jul 07 07:00:06 <gena2x> jluis: but we can try with shr-u first.
Jul 07 07:00:36 <gena2x> jluis: you'll need in fact someting working at your .. anything.
Jul 07 07:00:43 <gena2x> jluis: nand or sd.
Jul 07 07:00:44 <jluis> gena2x: which debian H1, qt, or via the script on wiki
Jul 07 07:00:56 <gena2x> jluis: i am using sid.
Jul 07 07:01:01 <gena2x> jluis: so any sid.
Jul 07 07:01:30 <gena2x> jluis: have you tried 640x480 videos on moko? 
Jul 07 07:02:41 <gena2x> but others might work too.
Jul 07 07:02:51 <jluis> gena2x: I only tried 320x480 from youtube
Jul 07 07:02:53 <vanous123> gena2x: i would like to run the test here 
Jul 07 07:03:06 <gena2x> vanous123: join.
Jul 07 07:03:14 <vanous123> gena2x: but have no time to compile, so would like the bins
Jul 07 07:04:56 <gena2x> may be qtmoko will be ok, so just install it.
Jul 07 07:05:08 <gena2x> if it'll fails, we can do slower debian install.
Jul 07 07:05:18 <gena2x> also we can check existing install.
Jul 07 07:05:30 <gena2x> so, with u-boot.
Jul 07 07:05:51 <gena2x> vanous123, jluis: bsdmn.com/openmoko/uboot500/u-boot.udfu_533_88_1.7_1.8_CLK2
Jul 07 07:06:14 <gena2x> flash and run you current distribution.
Jul 07 07:06:46 <gena2x> or sid, you no problems to install it for you.
Jul 07 07:06:58 <gena2x> s/you no/if no/
Jul 07 07:06:58 <apt> gena2x meant: or sid, if no problems to install it for you.
Jul 07 07:07:12 <gena2x> vanous123: backup sd card.
Jul 07 07:07:54 <gena2x> vanous123: on host dd if=/dev/sdX bs=1M | gzip -c -fast >backup.gz
Jul 07 07:08:32 <vanous123> gena2x: will use another card here
Jul 07 07:09:11 <gena2x> backup is faster than fresh install.
Jul 07 07:10:51 <vanous123> gena2x: ok, have flashed u-boot.udfu_533_88_1.7_1.8_CLK2 here
Jul 07 07:11:06 <vanous123> gena2x: have the card ready 
Jul 07 07:11:18 <gena2x> vanous123: sonthing installed on card?
Jul 07 07:11:33 <gena2x> vanous123: nand u-boot menu ok?
Jul 07 07:12:04 <[Rui]> gena2x: hi, got a tester yet?
Jul 07 07:12:29 <gena2x> [Rui]: yeah, 2, already. more than enough. thanks.
Jul 07 07:12:53 <vanous123> nand uboot menu ok
Jul 07 07:13:06 <gena2x> vanous123: what is on sd?
Jul 07 07:13:06 <jluis> gena2x: I've just installed your uboot and booted android on NAND  I will now istall qtmoko on a uSD
Jul 07 07:13:34 <gena2x> jluis: ok. if i'll not work we upgrade/reinstall debian.
Jul 07 07:13:36 <vanous123> hav shr-u
Jul 07 07:13:40 <vanous123> *have
Jul 07 07:13:45 <vanous123> 2.6.32
Jul 07 07:13:59 <gena2x> vanous123: ok, lets try with shr too.
Jul 07 07:14:11 <gena2x> jluis: got qtmoko?
Jul 07 07:14:16 <vanous123> have no fat, is it needed for uboot?
Jul 07 07:14:26 <gena2x> vanous123: no. need ext2.
Jul 07 07:14:33 <vanous123> have ext2
Jul 07 07:15:44 <gena2x> vanous123: so first boot your distribution with new u-boot.
Jul 07 07:16:12 <vanous123> gena2x: booting here, will it boot from uSD by default?
Jul 07 07:16:33 <gena2x> vanous123: it depends on your u-boot settings.
Jul 07 07:17:11 <gena2x> vanous123: if you not familiar with u-boot, i can describe how to configure it.
Jul 07 07:17:39 * jluis downloading qtmoko v24
Jul 07 07:17:40 <vanous123> gena2x: i have been using qi for too long... i though i need fat for usd boot
Jul 07 07:17:50 <vanous123> with uboot
Jul 07 07:18:07 <gena2x> vanous123: no. and you can also use images > 2mb with uboot.
Jul 07 07:18:23 <vanous123> yes, i have that setting
Jul 07 07:18:27 <vanous123> no problem with that
Jul 07 07:18:37 <gena2x> vanous123: so distribution boots?
Jul 07 07:18:58 <gena2x> vanous123: so ssh to it and disable X server.
Jul 07 07:19:28 <gena2x> vanous123: so ssh to it and disable X server.
Jul 07 07:19:35 <gena2x> ops, dup.
Jul 07 07:22:23 <vanous123> gena2x: it'đ running fron nand, is it a problem?
Jul 07 07:22:55 <gena2x> vanous123: ok, lets try from nand.
Jul 07 07:23:26 <vanous123> ok, no X running
Jul 07 07:23:40 <gena2x> jluis: how qtmoko?
Jul 07 07:24:17 <gena2x> vanous123: install kernel and modules bsdmn.com/openmoko/glamo/test
Jul 07 07:24:49 <gena2x> warning, this may corrupt sd.
Jul 07 07:25:02 <gena2x> and may bot corrupt.
Jul 07 07:25:07 <gena2x> and may not corrupt.
Jul 07 07:26:18 <gena2x> or produce other undesirable effects. but i am running same setup it here.
Jul 07 07:26:56 * vanous123 had to run around the house, 2 mins
Jul 07 07:27:01 <gena2x> k.
Jul 07 07:27:24 <gena2x> we almost finished in fact.
Jul 07 07:27:50 <gena2x> vanous123, jluis: ah, do not forget to install mplayer to your distro.
Jul 07 07:28:41 <gena2x> kernel hack we testing activates on first sd read.
Jul 07 07:29:01 <gena2x> so sd should be installed.
Jul 07 07:29:28 <gena2x> beeter to run from sd to have some load on it.
Jul 07 07:29:36 <gena2x> for testing purposes.
Jul 07 07:31:14 <vanous123> instaling mplayer here, but have not rebooted for new kernel yet
Jul 07 07:31:19 <jluis> gena2x: just booting it the rootfs didn't have /boot/uImage and I had to change an uboot variable :/
Jul 07 07:31:25 <vanous123> any movie file around for testing?
Jul 07 07:31:33 <gena2x> yes.
Jul 07 07:31:39 <gena2x> i'll provide movie file.
Jul 07 07:32:20 <gena2x> wait a bit please. this will be 30sec from some old soviet movie 640x480x15 mpeg2. hope no stupid rights problem.
Jul 07 07:32:38 <gena2x> if you care. i don't.
Jul 07 07:32:51 <vanous123> no problem here
Jul 07 07:33:17 <jluis> same here
Jul 07 07:36:05 <gena2x> ok. kernel boots ok?
Jul 07 07:37:55 <Weiss> eww. I googled "xdbe", and got "XdbE is an open, simple, powerful, robust and speedy Global Social Graph aggregator designed for sharing user data between ..."
Jul 07 07:37:57 <gena2x> jluis: may be need help with u-boot setup.
Jul 07 07:38:29 <gena2x> Weiss: :) no buffers?
Jul 07 07:38:31 <vanous123> gena2x: had to run an upgrade on the system, almost done
Jul 07 07:38:46 <gena2x> vanous123: ok.
Jul 07 07:41:28 <gena2x> ok, really will be 640x480x12. i lowered settings abit in this kernel.
Jul 07 07:42:17 <jluis> gena2x: the kernel booted ok but I had problems with userspace now I will try with a tested uSD
Jul 07 07:42:42 <gena2x> jluis: don't boot this kernel with unbackuped SD!
Jul 07 07:42:57 <gena2x> backup is few minutes. do it.
Jul 07 07:44:06 <gena2x> jluis: and no need in any userspace except ssh and mplayer.
Jul 07 07:46:05 <gena2x> ok, i added 11mb sample movie to same path.
Jul 07 07:46:18 <gena2x> cpu load here it 91%.
Jul 07 07:46:43 <jluis> gena2x: no problem I back-up while booting from the other one
Jul 07 07:48:55 <JaMa> blindcoder: http://cgit.freedesktop.org/xorg/xserver/commit/?id=9f0b193acdc29e491b6245390cf9f53b5222e6d3 ?
Jul 07 07:49:16 <jluis> I'vew got a WSD
Jul 07 07:49:34 <gena2x> jluis: at which moment?
Jul 07 07:50:52 <gena2x> jluis: on boot, on video playing?
Jul 07 07:51:08 <jluis> I think it was when starting qt
Jul 07 07:51:25 <gena2x> jluis: lets disable qt for a moment.
Jul 07 07:51:47 <gena2x> mv /opt/qtmoko/qpe.sh /opt/qtmoko/qpe.sh_
Jul 07 07:52:05 <gena2x> but it should work.
Jul 07 07:52:12 <jluis> I'm doing it now
Jul 07 07:52:15 <gena2x> and for sure without wsod.
Jul 07 07:52:33 <gena2x> as qt is over fb...
Jul 07 07:55:18 <gena2x> btw movie is not very good quality even on host (due to mcoder and 12fps), so don't expect something extraordinary.
Jul 07 07:55:30 <gena2x> but you should not see video frames redraw.
Jul 07 08:00:49 <gena2x> it's also possible to get red or blue screen of death, so do not scare if you'll see it :)
Jul 07 08:01:11 <gena2x>  (i had it with other timings)
Jul 07 08:01:17 <Weiss> gena2x: you're doing your work on 2.6.34, right?
Jul 07 08:01:34 <gena2x> Weiss: yes.
Jul 07 08:02:08 <gena2x> Weiss: with some patches from ThibG
Jul 07 08:02:34 <gena2x> Weiss: but they should be already somewher in git.
Jul 07 08:05:09 <gena2x> jluis, vanous123: guys, if need any help, or encounter problems related to testing, report.
Jul 07 08:06:37 * vanous123 got delayed by the upgrade idea... silly indeed, rebooting to verify distro
Jul 07 08:07:46 * jluis  in midle of an apt-get update to install mplayer
Jul 07 08:09:13 <vanous123> hehe, jluis got the same trouble :)
Jul 07 08:09:40 <gena2x> vanous123: which trouble?
Jul 07 08:10:11 <vanous123> delays with system updates, sorry for confussion
Jul 07 08:10:26 <gena2x> hp. thanks for testing so far.
Jul 07 08:11:22 <Weiss> gena2x: so, I took a look at the datasheets about memory
Jul 07 08:11:39 <gena2x> Weiss: waiting!
Jul 07 08:11:41 <Weiss> the whole chapter to do with the memory configuration registers in Glamo are just marked "Reserved".. :(
Jul 07 08:11:53 <gena2x> hm...
Jul 07 08:12:00 <Weiss> but in the host bus registers, there's some interesting looking stuff about FIFOs and bursts
Jul 07 08:12:10 <Weiss> there's some kind of pre-read cache thingy
Jul 07 08:12:11 <jluis> gena2x: mplayer dependencies, I had to create /var/cache/apt/archives /var/cache/apt/archives/partial to do the update/install
Jul 07 08:12:42 <gena2x> jluis: strange it were not created on installation.
Jul 07 08:13:17 <gena2x> Weiss: hm... is it specified how to setup host timings?
Jul 07 08:13:39 <gena2x> Weiss: and most important, should be bursts enabled on host?
Jul 07 08:14:08 <gena2x> Weiss: preread to or from glamo?
Jul 07 08:14:42 <gena2x> Weiss: btw, currently burst write is ok, burst read nok.
Jul 07 08:15:11 <gena2x> Weiss: so i am thinking how to setup it and is it possible at all.
Jul 07 08:15:38 <Weiss> gena2x: there are minimum and maximum values (measured in nanoseconds) for various electronic timings for read and write, with extra penalties when you access registers of different kinds
Jul 07 08:16:15 <gena2x> Weiss: whooh. this is exactly what i want :)
Jul 07 08:16:39 <gena2x> in nanoseconds is good.
Jul 07 08:16:57 <gena2x> and the exact names of timings.
Jul 07 08:17:19 <Weiss> also, maybe enabling the pre-read burst thingy will solve your burst read problem
Jul 07 08:17:30 <Weiss> unfortunately I don't have the datasheet at work, and still no new ADSL modem :(
Jul 07 08:18:15 <gena2x> Weiss: :( i hoped you get'll get them with you.
Jul 07 08:19:42 <jluis> gena2x: mplayer installed
Jul 07 08:19:57 <gena2x> jluis: command line: mplayer -vf pp=vb -vo fbdev -nosound /dog_heart.mkv.moko 
Jul 07 08:20:00 <gena2x> ops
Jul 07 08:20:06 <gena2x> jluis: command line: mplayer -vo fbdev -nosound /dog_heart.mkv.moko 
Jul 07 08:20:08 <gena2x> of course.
Jul 07 08:20:20 <Weiss> gena2x: :( sorry....  (I try to keep OM stuff off my Work desktop, in order to get any Work done..)
Jul 07 08:20:39 <vanous123> gena2x: getting WSOD right after kernel loading during boot from u-boot - nand
Jul 07 08:21:11 <gena2x> vanous123: after mounting rootfs?
Jul 07 08:21:38 <gena2x> vanous123: better, after partition detection or not?
Jul 07 08:22:12 <vanous123> kernel loading, ....starting kernel.... WSOD
Jul 07 08:22:20 <gena2x> oh.
Jul 07 08:22:27 <gena2x> so u-boot problem.
Jul 07 08:22:28 <vanous123> no more messages after starting kernel ...
Jul 07 08:22:30 <vanous123> hmm
Jul 07 08:22:41 <gena2x> no, not settings.
Jul 07 08:22:49 <gena2x> try other u-boot.
Jul 07 08:22:55 <vanous123> ok
Jul 07 08:22:57 <gena2x> for example default.
Jul 07 08:22:58 <vanous123> which one?
Jul 07 08:23:01 <vanous123> ok
Jul 07 08:24:08 <gena2x> u-boot-gta02v5-1.3.1+gitr650149a53dbdd48bf6dfef90930c8ab182adb512-r1
Jul 07 08:24:20 <gena2x> http://downloads.openmoko.org/distro/unstable/daily/om-gta02/20100131/u-boot-gta02v5-1.3.1+gitr650149a53dbdd48bf6dfef90930c8ab182adb512-r1.bin
Jul 07 08:24:25 <gena2x> this should work.
Jul 07 08:26:13 <jluis> gena2x: where I can get dog_heart.mkv.moko?
Jul 07 08:26:29 <vanous123> gena2x: booting
Jul 07 08:27:02 <gena2x> same location, http://www.bsdmn.com/openmoko/glamo/test/dog_heart.mkv.moko
Jul 07 08:28:07 <gena2x> you may try it on host, to get idea how it should look and about 'embedded' delays.
Jul 07 08:31:11 <vanous123> hmm, no usb and dark screen
Jul 07 08:31:40 <gena2x> no usb?
Jul 07 08:31:48 <vanous123> no
Jul 07 08:31:53 <gena2x> then screen became dark?
Jul 07 08:31:58 <vanous123> yes
Jul 07 08:32:00 <gena2x> after detecting partitions?
Jul 07 08:32:09 <vanous123> actually after starting udev
Jul 07 08:32:21 <vanous123> i got kernel, mounting filesystems, 
Jul 07 08:32:22 <gena2x> damn shr.
Jul 07 08:32:25 <vanous123> init
Jul 07 08:32:26 <vanous123> udev
Jul 07 08:32:41 <vanous123> shr logo was gone by that time, then dark
Jul 07 08:32:43 <vanous123> let me repeat
Jul 07 08:32:51 <gena2x> is it possible disable udev?
Jul 07 08:33:02 <vanous123> let me try
Jul 07 08:33:44 <vanous123> i am rebooting now to see
Jul 07 08:34:01 <vanous123> init booting
Jul 07 08:34:13 <vanous123> sshd
Jul 07 08:34:21 <vanous123> it seems like X is trying o run
Jul 07 08:34:30 <vanous123> the backlight seems on
Jul 07 08:34:33 <gena2x> no need X :)
Jul 07 08:34:39 <vanous123> i know
Jul 07 08:35:04 <gena2x> and accelerated X dies after few minutes :(
Jul 07 08:35:08 <gena2x> sometimes :(
Jul 07 08:35:16 <gena2x> in some conditions.
Jul 07 08:35:54 <vanous123> strangely enough, i get no usb (actually no dmesg report on my host after fr usb wire connect)
Jul 07 08:36:31 * vanous123 is flashing qi to verify the userspace
Jul 07 08:36:44 <gena2x> without udev it's possible...
Jul 07 08:36:53 <gena2x> dunno how to handle it.
Jul 07 08:37:17 <gena2x> udev works fine in debian/qtmoko.
Jul 07 08:37:46 <gena2x> jluis: so?
Jul 07 08:39:16 <vanous123> gena2x: the same with qi, it seems to be kernel related, trying with distro kernel
Jul 07 08:39:48 <gena2x> oh. seems shr-u is not suited. may be install soumething other?
Jul 07 08:39:54 <vanous123> eb4a7bc10ca5b5934e74166db9b95bca  uImage-b33.bin
Jul 07 08:40:01 <jluis> gena2x: mplayer run fine but I've a black screen rebooting & retesting (kernel 2.6.29-rc3-v24)
Jul 07 08:40:25 <gena2x> oh.
Jul 07 08:40:51 <gena2x> main goal to test provided kernel.
Jul 07 08:41:04 <gena2x> black screen - may be backlight?
Jul 07 08:41:09 <gena2x> om screen power 1?
Jul 07 08:41:25 * gena2x meant blank.
Jul 07 08:41:55 <vanous123> gena2x: got all working with 2.6.32.13 , will retry the b33
Jul 07 08:42:03 <JaMa> gena2x: is video playback better then with -vo glamo (glamo accelerated decoding)?
Jul 07 08:42:33 <gena2x> JaMa: i didn't saw -vo glamo for too long. is it working with nodebug?
Jul 07 08:42:57 <lindi-> I can't get 2.6.32 to boot. I just get instant WSOD:   https://docs.openmoko.org/trac/ticket/2344
Jul 07 08:43:14 <gena2x> lindi-: check your kernel config.
Jul 07 08:43:20 <lindi-> gena2x: it is included in the bug report
Jul 07 08:43:27 <gena2x> lindi-: usual thing with wrong config.
Jul 07 08:43:41 <lindi-> gena2x: where's the right config documented? ;)
Jul 07 08:43:55 <gena2x> lindi-: you may get one from shr git :)
Jul 07 08:44:09 <lindi-> gena2x: then it's bug that it's not in git.openmoko.org
Jul 07 08:44:12 <gena2x> lindi-: i tried to compare, but diff is huge.
Jul 07 08:44:33 <gena2x> lindi-: oh, or better to get may be from qtmoko.
Jul 07 08:44:41 <lindi-> gena2x: in any case. this needs to be documented
Jul 07 08:44:56 <lindi-> gena2x: please reply to the bug report :)
Jul 07 08:45:12 <jluis> gena2x: it was backlight seeing it now and loks like in my host
Jul 07 08:45:26 <gena2x> lindi-: sure, you right. and in fact i do not know will new config help and so, just had same problem... some time ago.
Jul 07 08:45:58 <JaMa> gena2x: yes, it's enabled by default in SHR builds.. here are benchmarks http://www.mail-archive.com/community@lists.openmoko.org/msg52613.html
Jul 07 08:46:36 <JaMa> lindi-: config is not in git.openmoko.org?
Jul 07 08:46:40 <gena2x> JaMa: so, -vo glamo works with current kernels in shr?
Jul 07 08:46:43 <lindi-> JaMa: read the bug report please :)
Jul 07 08:46:54 <lindi-> JaMa: i don't know what config you mean
Jul 07 08:47:09 <lindi-> JaMa: no place seems to document the right one(tm)
Jul 07 08:47:17 <JaMa> lindi-: http://git.openmoko.org/?p=kernel.git;a=commit;h=956b8809f9c3f661a59907af894ff04a8c664620
Jul 07 08:47:30 <gena2x> lindi-: right one should be defconfig in kernel.
Jul 07 08:47:34 <PaulFertser> JaMa: hey, you back, good morning :)
Jul 07 08:47:35 <gena2x> lindi-: imo.
Jul 07 08:47:45 <JaMa> gena2x: last time I tried it worked
Jul 07 08:47:51 <JaMa> PaulFertser: morning :)
Jul 07 08:48:06 <lindi-> JaMa: in the bug report I use that config
Jul 07 08:48:06 <gena2x> jluis: so, running?!
Jul 07 08:48:30 <gena2x> jluis: please, cut and paste cpu load numbers from mplayer
Jul 07 08:48:32 <lindi-> gena2x: gta02_drm_defconfig?
Jul 07 08:48:43 <gena2x> lindi-: not drm i think.
Jul 07 08:48:44 <JaMa> lindi-: and this one is working fine for shr..
Jul 07 08:48:51 <lindi-> gena2x: but JaMa says gta02_drm_defconfig
Jul 07 08:49:02 <gena2x> lindi-: jama has drm :)
Jul 07 08:49:25 <jluis> gena2x: yes. Now I will test with your kernel.  is ti  http://bsdmn.com/openmoko/uboot500/uImage-b17.bin?
Jul 07 08:49:31 <JaMa> lindi-: if you don't have drm used in userspace then you can use gta02_defconfig as qtmoko does
Jul 07 08:49:36 <gena2x> jluis: stop.
Jul 07 08:49:45 <gena2x> jluis: which kernel you test?
Jul 07 08:49:51 <lindi-> gena2x: gta02_defconfig has '# CONFIG_USB_USBNET is not set'
Jul 07 08:49:58 <gena2x> jluis: from distro.
Jul 07 08:50:24 <lindi-> JaMa: qtmoko does not do usb networking?
Jul 07 08:50:33 <gena2x> lindi-: oh. really. can't help any more. just wanted to tell that is probably cause of wsod.
Jul 07 08:50:43 <gena2x> lindi-: qtmoko do.
Jul 07 08:50:52 <lindi-> but they use gta02_defconfig which does not include it?
Jul 07 08:51:11 <gena2x> jluis: my kernel is bsdmn.com/glamo/test/
Jul 07 08:51:23 <gena2x> jluis: if you still didn't downloaded it...
Jul 07 08:51:38 <jluis> gena2x Linux neo 2.6.29-rc3-v24 #24 Sun May 23 23:32:50 CEST 2010 armv4tl GNU/Linux
Jul 07 08:51:54 <gena2x> jluis: this is not needed.
Jul 07 08:52:16 <gena2x> but can you paste numbers from mplayer?
Jul 07 08:52:38 <jluis> VO: [fbdev] 480x640 => 480x640 BGR 16-bit  V: 147.8 1775/1775 27% 84%  0.0% 0 0   
Jul 07 08:52:40 <gena2x> like this one - 34% 115% , if you did run it.
Jul 07 08:52:49 <gena2x> aha, 27-84.
Jul 07 08:52:52 <gena2x> ok.
Jul 07 08:53:05 <gena2x> now with my kernel please.
Jul 07 08:54:29 <ThibG> lindi-, what about USB_ETH?
Jul 07 08:55:14 <lindi-> ThibG: that is included
Jul 07 08:55:19 <lindi-> ThibG: so that should be used nowadays?
Jul 07 08:56:02 <ThibG> USB_ETH is for g_ether, the USB gadget we use, yes
Jul 07 08:56:13 <blindcoder> JaMa: looks like what we're looking for
Jul 07 08:56:40 <vanous123> gena2x: for some reason shr kernel .32 boots ok, the b33 ends on that black screen
Jul 07 08:56:53 <vanous123> gena2x: perhaps i can try more later, now gotta go
Jul 07 08:57:00 <gena2x> vanous123: this is something related to shr.
Jul 07 08:57:05 <vanous123> gena2x: ok
Jul 07 08:57:11 <gena2x> vanous123: ok, thank you for testing. :(
Jul 07 08:57:13 <vanous123> i may try on qtmoko later
Jul 07 08:57:17 <JaMa> blindcoder: can you try to upgrade xserver from my feed?
Jul 07 08:57:20 <vanous123> gena2x: np
Jul 07 08:57:32 <JaMa> blindcoder: my neo is not running and it will be built in few mins
Jul 07 08:57:55 <gena2x> jluis: ok. back. you last tester, so lets really test it.
Jul 07 08:58:00 <blindcoder> JaMa: feed url?
Jul 07 08:58:14 <JaMa> blindcoder: http://jama.homelinux.org/org.openembedded.shr/
Jul 07 08:58:27 <JaMa> blindcoder: but don't upgrade all, just xserver*
Jul 07 08:58:55 <JaMa> blindcoder: if you confirm the issue fixed, I'll push it to OE and build in std feeds
Jul 07 08:59:35 <mrmoku> lindi-: WSoD on boot was fixed by ThibG... guess we have a patch for 2.6.32 in OE and nobody comitted it to 2.6.32 repo
Jul 07 08:59:51 <lindi-> mrmoku: good, was there a report about it?
Jul 07 08:59:52 <lindi-> :)
Jul 07 08:59:55 <mrmoku> JaMa: welcome back :-)
Jul 07 09:00:17 <mrmoku> lindi-: don't know if ThibG added a trac ticket before fixing it
Jul 07 09:00:17 <lindi-> mrmoku: does it affect both configs?
Jul 07 09:00:36 * ThibG haven't filed any bug report
Jul 07 09:00:39 <mrmoku> lindi-: it was something about something not initialized correctly...
Jul 07 09:00:47 <mrmoku> lindi-: so config should not matter
Jul 07 09:00:52 <lindi-> ThibG: please do read https://docs.openmoko.org/trac/ticket/2344
Jul 07 09:01:02 <lindi-> mrmoku: ok so 2.6.32 is currently not buildable :(
Jul 07 09:01:04 <ThibG> lindi-, yes, I'm on it
Jul 07 09:01:13 <mrmoku> lindi-: well... not usable ;)
Jul 07 09:01:19 <mrmoku> it builds fine :P
Jul 07 09:01:57 <ThibG> lindi-, grep CONFIG_S3C24XX_GPIO_EXTRA .config
Jul 07 09:02:07 <JaMa> yes we have it in OE http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=036a0fcada952d8cf9e2f1360071730812ee1da6
Jul 07 09:02:26 <lindi-> ThibG: CONFIG_S3C24XX_GPIO_EXTRA=64 CONFIG_S3C24XX_GPIO_EXTRA64=y
Jul 07 09:02:30 <gena2x> jluis: extracted?
Jul 07 09:02:32 <ThibG> ok
Jul 07 09:02:34 <lindi-> ThibG: ... but don't you have exactly the same config there?
Jul 07 09:02:35 <gena2x> jluis: booted?
Jul 07 09:02:52 <ThibG> lindi-, I'm using a more generic config, Debian-style
Jul 07 09:02:56 <JaMa> but that was only temporary WS and only on some devices (so maybe lindi- has something a bit different)
Jul 07 09:03:27 <lindi-> ThibG: with initramfs?
Jul 07 09:03:29 <ThibG> lindi-, you might want to try this patch, but if you can always reproduce it, it might be something else
Jul 07 09:03:33 <ThibG> with initramfs, yes
Jul 07 09:03:40 <ThibG> (well, for now, d-i initramfs :))
Jul 07 09:04:52 <ThibG> lindi-, can you log into your device?
Jul 07 09:04:56 <ThibG> via ssh
Jul 07 09:05:38 <jluis> gena2x: it boots but I don't get ssh ( don't load some modules so I think I sould depmod it first)
Jul 07 09:05:39 <lindi-> ThibG: which config, with or without the patch?
Jul 07 09:06:08 <gena2x> jluis: yes, check modules please.
Jul 07 09:06:15 <ThibG> right now, when the screen is white
Jul 07 09:06:49 <lindi-> ThibG: but i'm testing different versions like you people asked :)
Jul 07 09:06:58 <ThibG> ok ok
Jul 07 09:07:16 <ThibG> well, if the patch mentionned above doesn't work, it's a completly different issue
Jul 07 09:07:24 <lindi-> ThibG: gta02_drm_defconfig and a9254be10ac2294e lets me login over ssh
Jul 07 09:07:50 <lindi-> '[   44.135000] s3c2410-wdt s3c2410-wdt: Unexpected close, not stopping watchdog' looks bad in dmesg
Jul 07 09:08:45 <ThibG> and your screen is white?
Jul 07 09:09:06 <lindi-> ThibG: yes
Jul 07 09:09:15 <ThibG> lindi-, can you try to suspend and resume?
Jul 07 09:09:41 <ThibG> mrmoku, btw, does your "temperature bug" (even if I doubt it's really temperature related) has been fixed?
Jul 07 09:10:45 <gena2x> jluis: it's nice if it boots.
Jul 07 09:11:24 <lindi-> ThibG: no change
Jul 07 09:11:37 <ThibG> hm
Jul 07 09:11:55 <Kryczek> Hi guys! I would like to make sure I email the proper persons, so could you please tell me if I am correct? :) In order to add my own AT%EM... commands to the Freerunner, I would need the moko10/moko11 source, right?
Jul 07 09:12:19 <dos1> Kryczek: yup. but you can't get them
Jul 07 09:13:04 <dos1> Kryczek: GSM firmware is closed source, only few people at Openmoko Inc. has access to it, but they can't release sources
Jul 07 09:13:24 <Kryczek> dos1: I know :) already signed the NDA
Jul 07 09:13:36 <dos1> oh :)
Jul 07 09:13:46 <ThibG> lindi-, so, it's probably something else
Jul 07 09:13:51 <ThibG> right now, I have no idea
Jul 07 09:14:03 <gena2x> lindi-: get working config and do diff.
Jul 07 09:14:04 <ThibG> have you tried SHR kernel?
Jul 07 09:14:19 <Kryczek> all that is standing between me and that is the password prompt on the https://hardward.internal.openmoko.org/... URL heh
Jul 07 09:14:32 <Kryczek> hardware* sorry
Jul 07 09:15:02 <mrmoku> ThibG: _I_ don't think WS is related to temperature
Jul 07 09:15:07 <mrmoku> ThibG: and no... still have it :/
Jul 07 09:15:28 <ThibG> mrmoku, ok
Jul 07 09:15:47 <blindcoder> JaMa: fixed :-)
Jul 07 09:15:51 <PaulFertser> Kryczek: may i ask what are you going to do with that?
Jul 07 09:15:56 <gena2x> lindi-: i can share my old .32 config.
Jul 07 09:16:04 <lindi-> gena2x: please put working config to git.openmoko.org
Jul 07 09:16:24 <gena2x> lindi-: i do not know is it _still_ working.
Jul 07 09:16:44 <gena2x> lindi-: i built .32 month or 2 ago.
Jul 07 09:17:48 <JaMa> blindcoder: ok, thx for test
Jul 07 09:18:04 <ThibG> lindi-, can you paste your dmesg somewhere?
Jul 07 09:21:50 <gena2x> lindi-: heh, even lost my config from .32. only kernel left :(
Jul 07 09:22:14 <gena2x> jluis: ok, are modules ok?
Jul 07 09:22:50 <gena2x> jluis: any troubles? why so long? something not working?
Jul 07 09:23:11 <jluis> I just ended the depmod (I had problems with mrb)
Jul 07 09:23:22 <gena2x> mrb??
Jul 07 09:23:33 <gena2x> ah, mbr?
Jul 07 09:23:43 <gena2x> ok.
Jul 07 09:25:28 * jluis runing mplayer agai
Jul 07 09:25:56 <gena2x> with my kernel?
Jul 07 09:26:12 <jluis> yes
Jul 07 09:26:16 <gena2x> ok.
Jul 07 09:26:22 <gena2x> it works?
Jul 07 09:27:30 <gena2x> any artefacts? what is cpu load?
Jul 07 09:27:57 <jluis> gena2x: sorry I was wrong  I still using 29
Jul 07 09:28:23 <gena2x> ahh.
Jul 07 09:28:30 <gena2x> np.
Jul 07 09:30:08 <jluis> I made the simbolic link to /  istead of to /boot
Jul 07 09:31:10 <gena2x> oh yesterday i forgot to copy modules and copyed em 2 times with wrong paths :)
Jul 07 09:33:45 <lindi-> ThibG: dmesg is in the bug report
Jul 07 09:35:07 <ThibG> nice, asked myself for ten minutes why µSD support was broken
Jul 07 09:35:26 <ThibG> yet to find I had removed my µSD card in my last test...
Jul 07 09:36:06 <jluis> gena2x: V: 147.8 1775/1775 29% 58%  0.0% 0 0  
Jul 07 09:36:35 <gena2x> so, 27% 84% -> 29% 58% 
Jul 07 09:37:02 <gena2x> does it look much better?
Jul 07 09:37:03 <jluis> yes 
Jul 07 09:37:34 <ThibG> lindi-, ok, gonna have a look
Jul 07 09:37:55 <gena2x> gena2x: ^^^
Jul 07 09:38:03 <gena2x> jluis: ^^^
Jul 07 09:38:31 <jluis> gena2x: need more tests now? I must go out for 30 minutes
Jul 07 09:38:51 <gena2x> jluis: thank you much. this is all i need in fact.
Jul 07 09:38:56 <ThibG> lindi-, seems glamo-fb doesn't even load...?
Jul 07 09:39:03 <dos1> gena2x: http://bsdmn.com/openmoko/glamo/memset/uImage-b31.bin - is this the latest?
Jul 07 09:39:29 <gena2x> dos1: oh, it is not working for shr anyway.
Jul 07 09:39:50 <gena2x> dos1: but i build http://www.bsdmn.com/openmoko/glamo/test/
Jul 07 09:40:03 <dos1> gena2x: i don't know such phrase as "not working" ;>
Jul 07 09:40:12 <lindi-> ThibG: is it supposed to be a kernel module?
Jul 07 09:40:14 <gena2x> dos1: so if you want to take a look you welcome.
Jul 07 09:40:25 <ThibG> lindi-, yes, or built-in
Jul 07 09:40:29 <dos1> ok, downloading
Jul 07 09:40:35 <dos1> already did SD backup too
Jul 07 09:40:37 <lindi-> ThibG: well git.openmoko.org has CONFIG_MFD_GLAMO=y
Jul 07 09:41:01 <gena2x> dos1: Weiss : so this is not cache, my setup or something else: 27% 84% -> 29% 58%.
Jul 07 09:42:02 <ThibG> You should see something like that when glamo-fb is loaded: "[    4.695000] SMEDIA Glamo frame buffer driver (C) 2007 Openmoko, Inc."
Jul 07 09:42:04 <JaMa> ThibG, lindi-: drm config has normal FB disabled (replaced by enabled KMS)
Jul 07 09:42:23 <lindi-> JaMa: so it can not be used with xserver-xorg-video-fbdev?
Jul 07 09:42:34 <gena2x> ThibG, lindi- : yes, and i told you need no-drm version :)
Jul 07 09:43:47 <JaMa> lindi-: I normaly use only xserver-xorg-video-glamo but imho it worked for mew also with fbdev (not sure if it's using /dev/fb*)
Jul 07 09:44:11 <lindi-> JaMa: how do you talk to display if not via /dev/fb0?
Jul 07 09:45:18 <gena2x>  /dev/fb1?
Jul 07 09:45:31 <gena2x> just guess ;)
Jul 07 09:45:35 <lindi-> gena2x: no fb*
Jul 07 09:45:50 <ThibG> lindi-, the KMS modules use a different architecture, but provide the framebuffer interface too
Jul 07 09:47:26 <lindi-> ThibG: I have no idea why glamo-fb does not get loaded
Jul 07 09:49:21 <Weiss> KMS kernel should not be loading glamo-fb (?)
Jul 07 09:49:56 <gena2x> Weiss: ok, so that we can do with timings?
Jul 07 09:49:58 <ThibG> lindi-, you're using non-drm defconfig, no?
Jul 07 09:50:18 <lindi-> ThibG: "5) cp ./arch/arm/configs/gta02_drm_defconfig lindi/.config"
Jul 07 09:50:30 <lindi-> -- https://docs.openmoko.org/trac/ticket/2344
Jul 07 09:51:06 <ThibG> that's why, then
Jul 07 09:51:28 <ThibG> gdrm is not merged in om-gta02-2.6.32
Jul 07 09:52:01 <lindi-> ThibG: so should I try /gta02_defconfig?
Jul 07 09:52:02 <gena2x> :)
Jul 07 09:52:03 <ThibG> yes
Jul 07 09:52:17 <dos1> gena2x: seems that your kernel works on 400_100, but hangs at 533_88
Jul 07 09:52:31 <dos1> still testing though
Jul 07 09:52:39 <gena2x> dos1: it's possible and ok and not related.
Jul 07 09:53:04 <lindi-> ThibG: can you please remove the broken config file from git.openmoko.org?
Jul 07 09:53:07 <dos1> yup
Jul 07 09:53:14 <dos1> gena2x: i'll also try with 500
Jul 07 09:53:18 <ThibG> I don't have access to git.openmoko.org
Jul 07 09:53:20 <lindi-> ThibG: it's easy to revert it back when you merge
Jul 07 09:53:25 <gena2x> dos1: if you wish.
Jul 07 09:54:06 <gena2x> dos1: in fact i already checked that glamo speed change is working not only here.
Jul 07 09:54:09 <lindi-> ThibG: well at least suggest it in the bug comment so that I can refer to it?
Jul 07 09:54:52 <lindi-> ThibG: something like "gta02_drm_defconfig does not work with om-gta02-2.6.32 since it does not contain gdrm"
Jul 07 09:54:52 <gena2x> lindi-: seems bug that kernel which contain no drm include drm config. but this sounds so minor...
Jul 07 09:55:35 <lindi-> gena2x: my downtime is increasing all the time :)
Jul 07 09:59:03 <gena2x> lindi-: hmm. need more issues? :)
Jul 07 10:01:50 <lindi-> gena2x: "With arch/arm/configs/gta02_defconfig /dev/fb0 exists and Xorg starts. Xorg can blank and unblank the screen based on touchscreen idleness. However, contents of display is still always white."
Jul 07 10:04:20 <gena2x> oh.. they say ThibG knows everything about glamo-fb :)
Jul 07 10:04:56 <ThibG> who say that? :o
Jul 07 10:05:43 <gena2x> joking, joking. but this look like issue with glamo-fb.
Jul 07 10:06:24 <dos1> gena2x: but at 533/88?
Jul 07 10:06:30 <ThibG> lindi-, ok, dmesg again?
Jul 07 10:07:07 <gena2x> dos1: ? did you run it on 400/100?
Jul 07 10:07:09 <lindi-> ThibG: after adding getty I lost ssh access but X works now. need to repeat a few times...
Jul 07 10:07:16 <lindi-> ThibG: are you using getty?
Jul 07 10:07:31 <ThibG> nope
Jul 07 10:07:57 <dos1> gena2x: i try different combinations
Jul 07 10:08:17 <gena2x> dos1: did you fix udev?
Jul 07 10:08:19 <ThibG> d-i initrd for now, I haven't X nor getty, but the d-i interface works
Jul 07 10:08:26 <gena2x> dos1: at 400/100?
Jul 07 10:08:31 <dos1> gena2x: it works with your kernel at 400/100
Jul 07 10:08:35 <lindi-> ThibG: over ssh?
Jul 07 10:08:37 <dos1> gena2x: it just hangs at 533/88
Jul 07 10:08:47 <gena2x> dos1: mplayer works too?
Jul 07 10:08:52 <ThibG> over ssh, yes, but I have the info about SSH on-screen to
Jul 07 10:08:56 <dos1> and seems to be working at both with 2.6.29
Jul 07 10:09:13 <gena2x> dos1: the u-boot is not modified.
Jul 07 10:09:22 <gena2x> dos1: this time.
Jul 07 10:09:27 <dos1> gena2x: yup, i know
Jul 07 10:09:27 <gena2x> dos1: only kernel.
Jul 07 10:09:47 <dos1> gena2x: just testing if that's only overclocking issue, of something different
Jul 07 10:09:53 <dos1> s/of/or/
Jul 07 10:09:54 <apt> dos1 meant: gena2x: just testing if that's only overclocking issue, or something different
Jul 07 10:10:29 <gena2x> dos1: it's possible overclicking. but movie is watchable with glamo settings changed, yes?
Jul 07 10:10:43 <gena2x> :) overclocking
Jul 07 10:11:21 <gena2x> dos1: and do you have sd card installed?
Jul 07 10:12:08 <dos1> gena2x: i didn't have yesterday, now i have
Jul 07 10:12:17 <gena2x> dos1: so ok.
Jul 07 10:15:59 <gena2x> dos1: so can you notice 640x480 is watchable?
Jul 07 10:16:39 <dos1> gena2x: now i'm downloading your video file
Jul 07 10:16:52 <dos1> gena2x: and i have booted 2.6.29 to check the difference
Jul 07 10:17:00 <lindi-> ThibG: thanks, I sent email to lars and kernel list
Jul 07 10:30:32 <mickey|patio> morning
Jul 07 10:32:08 <gena2x> dos1: so?
Jul 07 10:33:27 <dos1> gena2x: i'm collecting results and will give it to you all together :)
Jul 07 10:35:50 <gena2x> dos1: mplayer test is not really oriented to results, as the glamo operation is may be 50%, so if it decrease to 30% it will be noticed, but more important is that redraw is not visible.
Jul 07 10:40:01 <gena2x> but seem second number in mplayer include not only -vo operation but also yuv<>bgr conversion.
Jul 07 10:40:28 <gena2x> which is done in software, so glamo may be even less visible.
Jul 07 10:40:59 <gena2x> ok, it's never 50% at 640x480 :)
Jul 07 10:45:40 <dos1> flashing taaakes aaaageeeees
Jul 07 10:45:57 <dos1> booting too...
Jul 07 10:46:11 <dos1> it sucks when you flash, boot, want to test something, and then you discover that you flashed wrong thing ;x
Jul 07 10:46:18 <mickey|patio> indeed
Jul 07 10:47:13 <gena2x> dos1: after few days of flashing, you'll calm down, and such things will just concentrate you :)
Jul 07 10:47:25 <DocScrutinizer51> Kryczek: it seems the URL you got doesn't even have the latest sources
Jul 07 10:48:56 <DocScrutinizer51> which isn't a surprise if you got the URL from OM the Inc., as they freed all inhouse competence relating TI calypso (and seems phone in general)
Jul 07 11:07:04 <GNUtoo|laptop> hi PaulFertser 
Jul 07 11:07:16 <GNUtoo|laptop> I succeded to boot on sdcard
Jul 07 11:07:26 <GNUtoo|laptop> the thing was to use fatload and not ext2load
Jul 07 11:07:34 <GNUtoo|laptop> because my uboot was old
Jul 07 11:10:05 <DocScrutinizer51> you really think it's the old uboots that fail on ext2?
Jul 07 11:11:03 <PaulFertser> GNUtoo|laptop: hi.
Jul 07 11:11:26 <DocScrutinizer51> PaulFertser: hi
Jul 07 11:11:32 <GNUtoo|laptop> DocScrutinizer51, I couldn't load a file with the ext2load
Jul 07 11:11:42 <GNUtoo|laptop> it always failed
Jul 07 11:11:42 <PaulFertser> DocScrutinizer51: hey doc :)
Jul 07 11:12:12 <GNUtoo|laptop> http://wiki.openmoko.org/wiki/Booting_from_SD#Booting_from_SDHC_.2F_suspend_problems says:
Jul 07 11:12:15 <DocScrutinizer51> it seems to me that' related to uboot not handling 256b inodes
Jul 07 11:12:23 <GNUtoo|laptop> NOTE: The "ext2load" command is broken on u-boot binary earlier than "20080723"
Jul 07 11:12:32 <DocScrutinizer51> there's been a change in defaults of mkfs
Jul 07 11:12:33 <GNUtoo|laptop> and I've an uboot earlier than that
Jul 07 11:12:38 <GNUtoo|laptop> ah ok
Jul 07 11:12:43 <GNUtoo|laptop> for ext4 compatibility
Jul 07 11:12:59 <GNUtoo|laptop> I know...I've patched grub for that in oe
Jul 07 11:13:00 <mickey|patio> hi DocScrutinizer51 !
Jul 07 11:13:09 <mickey|patio> DocScrutinizer51: long time no see, what are you doing these days?
Jul 07 11:13:34 <DocScrutinizer51> mostly struggling with midlife crysis
Jul 07 11:13:40 <mickey|patio> aw, gee
Jul 07 11:13:46 <mickey|patio> i'm 10 years away from that ;)
Jul 07 11:15:29 <DocScrutinizer51> mickey|patio: who'd potentially sign off NDAs for OM these days?
Jul 07 11:16:27 <mickey|patio> DocScrutinizer51: no one else than Sean is allowed to do that
Jul 07 11:16:35 <mickey|patio> or his secretary, whoever this is these days
Jul 07 11:17:04 <DocScrutinizer51> mhm. thought as much. thanks
Jul 07 11:18:27 <PaulFertser> DocScrutinizer51: any other project on your horizon?
Jul 07 11:20:07 <DocScrutinizer51> not really
Jul 07 11:23:00 <dos1> gena2x: well, is that possible that other frequencies than 533/88 need different timings?
Jul 07 11:24:01 <dos1> gena2x: btw, your kernel prints lots of debug data on console when using touchscreen
Jul 07 11:24:30 <dos1> i think when testing X or QtMoko it can cause slow down s
Jul 07 11:33:26 <dos1> gena2x: ping
Jul 07 11:44:27 <dos1> gena2x: your kernel seems to be the slowest one here :(
Jul 07 11:44:38 <dos1> gena2x: and i can't boot at 533/88 with any kernel
Jul 07 11:45:10 <dos1> gena2x: http://pastebin.com/chZ9XrkZ
Jul 07 11:45:48 <dos1> gena2x: on other kernels there is huge difference between 400/100 and 500/83
Jul 07 11:45:56 <dos1> of course 500/83 is much faster ;)
Jul 07 11:46:27 <dos1> but with your b33 video is the most sluggish here... (probably due to fact, that i'm not booting with 533/88)
Jul 07 11:46:55 <dos1> gena2x: but there is huge difference in numbers reported by mplayer
Jul 07 11:48:26 <dos1> gena2x: could you test how fast is it on your neo with 500/83?
Jul 07 12:29:14 <CIA-58> freesmartphone.org: 03mickey 07cornucopia * rb34d9d0a8487 10/fsogsmd/src/ (4 files in 2 dirs): fsogsmd: implement org.freesmartphone.GSM.SIM.StoreMessage()
Jul 07 12:29:14 <CIA-58> freesmartphone.org: 03mickey 07cornucopia * r62fdf4941b6b 10/docs/TODO: TODO++
Jul 07 12:29:14 <CIA-58> freesmartphone.org: 03mickey 07cornucopia * rb70c9a136733 10/fsogsmd/src/ (4 files in 2 dirs): fsogsmd: implement org.freesmartphone.GSM.SIM.SendStoredMessage()
Jul 07 12:29:44 <CIA-58> SHR: 03seba.dos1 07libphone-ui-shr * r01c15bc1e68b 10/data/keypad.edc: edje: restore animation in every key (before that only 0 key was animated)
Jul 07 12:31:34 <dos1> mickey|patio: btw, delivery reports still broken
Jul 07 12:31:44 <mickey|patio> "still"?
Jul 07 12:31:49 <mickey|patio> that would be rather again
Jul 07 12:31:52 <mickey|patio> since they worked once for me
Jul 07 12:32:25 <dos1> mickey|patio: at least in gitr827+3dc9d7ebde32d8c29c901b52f7d3549b774b068b
Jul 07 12:33:03 <dos1> mickey|patio: i'm getting different IDs in SendTextMessage and IncomingMessageReport
Jul 07 12:33:07 <ThibG> "delivery reports"?
Jul 07 12:33:20 <dos1> mickey|patio: btw. how is that supposed to work with CSM messages?
Jul 07 12:34:47 <GNUtoo|laptop> hi mickey|patio 
Jul 07 12:35:32 <mickey|patio> hi GNUtoo|laptop 
Jul 07 12:35:39 <mickey|patio> CSM?
Jul 07 12:35:51 <mickey|patio> ThibG: sms delivery reports
Jul 07 12:35:57 <mickey|patio> ok, i'll take a look after lunch
Jul 07 12:35:58 <mickey|patio> bbl
Jul 07 12:36:02 <GNUtoo|laptop> mickey|patio, I've a question/rfc/usecase:
Jul 07 12:36:06 <dos1> mickey|patio: concatenated short messages ;)
Jul 07 12:36:12 <GNUtoo|laptop> let's say someone is using intone
Jul 07 12:36:14 <ThibG> mickey|patio, oh, nice :)
Jul 07 12:36:15 <GNUtoo|laptop> which uses mplayer
Jul 07 12:36:20 <GNUtoo|laptop> and the phone ring
Jul 07 12:36:28 <GNUtoo|laptop> we use alsa
Jul 07 12:36:29 <ThibG> there is an UI for that, now?
Jul 07 12:36:40 <GNUtoo|laptop> so we have only one app at the same time that can send audio
Jul 07 12:36:45 <GNUtoo|laptop> how do we handle that?
Jul 07 12:36:52 <GNUtoo|laptop> Note that vibration work
Jul 07 12:37:01 <GNUtoo|laptop> so we could say WONTFIX 
Jul 07 12:37:11 <GNUtoo|laptop> but when someone is listenning to music
Jul 07 12:37:23 <GNUtoo|laptop> he can't necessary ear the vibration
Jul 07 12:37:25 <mickey|patio> dos1: org.freesmartphone.GSM.SIM.StoreMessage() and SendStoreMessage() is the advanced interface for special needs. CSM are supported fine in org.freesmartphone.GSM.SMS.SendTextMessage()
Jul 07 12:37:38 <dos1> ThibG: there was already for looooooooong time in opimd-utils
Jul 07 12:37:52 <mickey|patio> GNUtoo|laptop: sooner or later audio needs to be fully under framework control
Jul 07 12:37:59 <mickey|patio> GNUtoo|laptop: we should take a look at pulseaudio for that usecase
Jul 07 12:38:03 * mickey|patio needs to run -> lunch
Jul 07 12:38:07 <dos1> mickey|patio: yup, but SendTextMessage returns only one ID, and AFAIK delivery reports come for every part of long message
Jul 07 12:38:12 <GNUtoo|laptop> mickey|patio, ok,
Jul 07 12:38:19 <GNUtoo|laptop> I was thinking about fso-raw
Jul 07 12:38:24 <GNUtoo|laptop> and something like that
Jul 07 12:38:24 <dos1> GNUtoo|laptop: "so we have only one app at the same time that can send audio" - WTF?
Jul 07 12:38:32 <mickey|patio> dos1: ooh, really? ok, i need to translate that then
Jul 07 12:38:41 <GNUtoo|laptop> dos1, is it the same on the freerunner?
Jul 07 12:39:23 <dos1> GNUtoo|laptop: alsa can handle few apps at once nicely
Jul 07 12:39:24 <GNUtoo|laptop> mickeyl, I've another idea
Jul 07 12:39:32 <GNUtoo|laptop> mickeyl, .asoundrc
Jul 07 12:39:55 <GNUtoo|laptop> mickeyl, that could make what dos1 is speaking about: andle few app at the same time
Jul 07 12:40:20 <GNUtoo|laptop> s#.asoundrd#/etc/asound.conf#
Jul 07 12:40:40 <GNUtoo|laptop> dos1, you hadle that with asound.conf on the freerunner?
Jul 07 12:42:01 <dos1> GNUtoo|laptop: http://pastebin.com/Z30cdXmk
Jul 07 12:42:07 <dos1> GNUtoo|laptop: that's default, unchanged /etc/asound.conf
Jul 07 12:42:14 <GNUtoo|laptop> ok
Jul 07 12:42:30 <GNUtoo|laptop> thanks a lot
Jul 07 12:42:30 <dos1> GNUtoo|laptop: oh, with # at beginning of first line of course
Jul 07 12:43:02 <GNUtoo|laptop> indeed
Jul 07 12:43:39 <GNUtoo|laptop> ahh I've no asound.conf
Jul 07 12:43:40 <GNUtoo|laptop> strange
Jul 07 12:44:03 <GNUtoo|laptop> I bet I'll need to put one in oe for dream
Jul 07 12:45:25 <GNUtoo|laptop> dos1, that config seem incomplete
Jul 07 12:45:31 <GNUtoo|laptop> I'll gab the one from my freerunner
Jul 07 12:46:02 <dos1> GNUtoo|laptop: that's exactly my file on SHR
Jul 07 12:46:05 <dos1> GNUtoo|laptop: 12 lines
Jul 07 12:46:10 <GNUtoo|laptop> ah ok
Jul 07 12:46:19 <dos1> with 12 being empty
Jul 07 12:46:20 <dos1> :P
Jul 07 12:47:02 <GNUtoo|laptop> I've no asound.conf on the freerunner
Jul 07 12:47:14 <GNUtoo|laptop> I use shr-u from SHR repos
Jul 07 12:51:57 <GNUtoo|laptop> on htcdream:
Jul 07 12:51:58 <GNUtoo|laptop> [AO_ALSA] alsa-lib: pcm_direct.c:877:(snd1_pcm_direct_initialize_slave) slave plugin does not support mmap interleaved or mmap noninterleaved access
Jul 07 12:52:34 <GNUtoo|laptop> I'll look
Jul 07 12:55:05 <dos1> mickeyl: mdbus2 says, that there is /org/freesmartphone/Device/LED/gta02_blue_power at org.freesmartphone.odeviced
Jul 07 12:55:07 <dos1> but
Jul 07 12:55:13 <dos1> MDBUS2> org.freesmartphone.odeviced /org/freesmartphone/Device/LED/gta02_blue_power 
Jul 07 12:55:15 <dos1> [ERR]: Unknown object path /org/freesmartphone/Device/LED/gta02_blue_power for org.freesmartphone.odeviced
Jul 07 12:55:18 <dos1> the same for other LEDs
Jul 07 12:55:32 <dos1> i guess that's why LEDs are not working with 2.6.32 :P
Jul 07 12:56:00 <GNUtoo|laptop> ah now it seem to work
Jul 07 12:56:23 <GNUtoo|laptop> ah no
Jul 07 12:56:32 <GNUtoo|laptop> [AO_ALSA] alsa-lib: pcm_hw.c:1293:(snd_pcm_hw_open) open '/dev/snd/pcmC0D0p' failed (-16): Device or resource busy
Jul 07 12:56:40 <GNUtoo|laptop> it worked only with one at the same time
Jul 07 12:56:58 <GNUtoo|laptop> I've put that:
Jul 07 12:56:59 <GNUtoo|laptop> slave.pcm "hw:0"
Jul 07 12:57:02 <GNUtoo|laptop> altough
Jul 07 13:04:21 <Q-Master> dos1: 8) they're definitely not working.
Jul 07 13:31:49 <dos1> so, vibrator stength is fixed in repo
Jul 07 13:32:09 <dos1> mrmoku or JaMa: could you commit http://patchwork.dev.bearstech.com/patch/732/ ?
Jul 07 13:33:01 <JaMa> y
Jul 07 13:34:28 <JaMa> dos1: done, you can build it
Jul 07 13:34:37 <dos1> JaMa: thanks :)
Jul 07 13:35:52 <dos1> JaMa: what about nondebug and nonpreempt kernel?
Jul 07 13:36:47 <JaMa> what about it?
Jul 07 13:37:02 <JaMa> it's nodebug from begining..
Jul 07 13:37:51 <dos1> and preempt?
Jul 07 13:38:27 <JaMa> CONFIG_PREEMPT=y
Jul 07 13:39:03 <net_tux> is there any way to get qwo working with illume2?  If not currently, any idea what would need to be done to make it work?
Jul 07 13:39:56 <dos1> JaMa: AFAIR disabling PREEMPT makes kernel faster
Jul 07 13:41:01 <JaMa> I don't remember that, iirc gena2x proved that debug makes 2.6.29 a lot slower, but I think it wasn't so clear about preempt
Jul 07 13:42:51 <dos1> ok then
Jul 07 13:43:25 <JaMa> but maybe you remember it better :)
Jul 07 13:47:29 <GNUtoo|laptop> mmap emulation don't work
Jul 07 13:47:30 <GNUtoo|laptop> hmmm
Jul 07 13:47:32 <GNUtoo|laptop> hi JaMa 
Jul 07 13:47:40 <JaMa> hi GNUtoo|laptop 
Jul 07 13:48:06 <GNUtoo|laptop> JaMa, does the installation of navit still install udev which render the phone unbootable?
Jul 07 13:48:16 <GNUtoo|laptop> (htcdream)
Jul 07 13:49:49 <JaMa> GNUtoo|laptop: navit does not depend on udev here, so I don't know why it should install udev and also on gta* installing udev doesn't break anything (it's just optional now), what makes htcdream unbootable with udev?
Jul 07 13:54:02 <JaMa> GNUtoo|laptop: it's pulled by gpsd-udev?
Jul 07 13:56:04 <GNUtoo|laptop> JaMa, maybe
Jul 07 13:56:15 <GNUtoo|laptop> I'll look later
Jul 07 13:56:26 <GNUtoo|laptop> It was just to report the issue
Jul 07 13:56:34 <GNUtoo|laptop> if it's not present on gta*
Jul 07 13:56:45 <GNUtoo|laptop> I'll see it laster
Jul 07 13:57:05 <GNUtoo|laptop> because I've xf86-video-fbdev to fix for htcdream,
Jul 07 13:57:13 <GNUtoo|laptop> I've also sent a patch to the mailing list
Jul 07 13:57:21 <JaMa> GNUtoo|laptop: gpsd-udev is also not in navit depends afaik
Jul 07 13:57:22 <GNUtoo|laptop> for xf86-* in XSERVER
Jul 07 13:57:27 <GNUtoo|laptop> ok
Jul 07 13:57:50 <JaMa> check depends.pot from testlab to see what pulled it to image
Jul 07 13:58:01 <GNUtoo|laptop> I'll see that later
Jul 07 13:58:07 <JaMa> or opkg install navit for possible candidates
Jul 07 13:58:15 <GNUtoo|laptop> because I've other more important things for dream
Jul 07 13:58:25 <GNUtoo|laptop> I would have helped only if it was an issue with gta*
Jul 07 13:58:40 <GNUtoo|laptop> I've 2 patches to take care of
Jul 07 13:58:51 <GNUtoo|laptop> then I've devtmpfs 
Jul 07 13:58:54 <GNUtoo|laptop> to fix
Jul 07 13:59:28 <GNUtoo|laptop> because mickeyl told me to remove an init script that was for devfs
Jul 07 13:59:33 <GNUtoo|laptop> and it made the phone boot
Jul 07 13:59:37 <GNUtoo|laptop> the 2 patches are:
Jul 07 13:59:39 <GNUtoo|laptop> *[PATCH] htcdream.conf: use xf86-video-fbdev and xf86-video-tslib
Jul 07 13:59:40 <GNUtoo|laptop> from oe
Jul 07 13:59:56 <GNUtoo|laptop> *a patch for xf86-video-fbdev upstream
Jul 07 14:00:43 <GNUtoo|laptop> JaMa, after having taking care of it I'll ask mrmoku to start building dream images
Jul 07 14:00:55 <GNUtoo|laptop> I need to push a new xorg.conf too
Jul 07 14:01:14 <GNUtoo|laptop> and maybe an mplayer.conf
Jul 07 14:02:04 <GNUtoo|laptop> and some cosmetic conf
Jul 07 14:02:09 <GNUtoo|laptop> like gtkrc 
Jul 07 14:07:37 <JaMa> GNUtoo|laptop: great
Jul 07 14:08:16 <GNUtoo|laptop> JaMa, are you able to hack core stuff?
Jul 07 14:08:29 <JaMa> GNUtoo|laptop: in OE?
Jul 07 14:08:35 <GNUtoo|laptop> yes
Jul 07 14:08:42 <GNUtoo|laptop> s/hack/ack
Jul 07 14:09:18 <JaMa> :) I don't think it's strcitly defined in OE rules.. so yes
Jul 07 14:09:38 <GNUtoo|laptop> ok 
Jul 07 14:09:40 <GNUtoo|laptop> thanks a lot
Jul 07 14:10:06 <GNUtoo|laptop> maybe you could ack or comment on that patch: [PATCH] htcdream.conf: use xf86-video-fbdev and xf86-video-tslib
Jul 07 14:11:00 <dos11> JaMa: about udev - maybe it's just udev-cache thing?
Jul 07 14:11:31 <dos1> JaMa: i booted my system without udev before few moments (added "exit 0" to beginning of init script), but i forgot about udev-cache
Jul 07 14:11:56 <dos1> JaMa: and after removing "exit 0" line, on next boot GSM didn't work, most of things were unrecognised
Jul 07 14:12:15 <dos1> JaMa: i had to trigger udev population of /dev manually
Jul 07 14:13:33 <JaMa> GNUtoo|laptop: IMHO you don't need ACKs for this.. mickey is listed as htcdream maintainer and if this combination works and is used in xorg.conf then it's better when it's set right in XSERVER var
Jul 07 14:14:11 <GNUtoo|laptop> I think I neeed an ack
Jul 07 14:14:13 <JaMa> dos1: why do you have udev or udev-cache?
Jul 07 14:14:18 <GNUtoo|laptop> not because of htcdream
Jul 07 14:14:26 <GNUtoo|laptop> but because of that:
Jul 07 14:14:35 <GNUtoo|laptop> recipes/tasks/task-x11.bb
Jul 07 14:14:40 <JaMa> dos1: devtmpfs + 3 mknod in init script is enough to have GSM working
Jul 07 14:14:43 <GNUtoo|laptop> that's core or will be core
Jul 07 14:15:03 <dos1> JaMa: i have 1,5 year old image, always opkg upgraded ;)
Jul 07 14:15:16 <GNUtoo|laptop> JaMa, basically before it used the XSERVER from htc-msm.inc
Jul 07 14:15:20 <GNUtoo|laptop> but that didn't work
Jul 07 14:15:25 <GNUtoo|laptop> because it doesn't use tslib
Jul 07 14:15:31 <GNUtoo|laptop> and use xf86-video-msm
Jul 07 14:15:37 <GNUtoo|laptop> which is not what our xorg.conf uses
Jul 07 14:16:00 <JaMa> GNUtoo|laptop: PR bumps are safe -  nobody will blame you for rebuilding task (quick)
Jul 07 14:16:12 <GNUtoo|laptop> I was blamed once for that
Jul 07 14:16:23 <GNUtoo|laptop> because I put a task machine arch + PR
Jul 07 14:16:28 <GNUtoo|laptop> which was core
Jul 07 14:16:35 <GNUtoo|laptop> and that made angstrom rebuild that
Jul 07 14:16:37 <GNUtoo|laptop> for every machine
Jul 07 14:16:42 <JaMa> see git log of task-x11.bb :)
Jul 07 14:18:01 <JaMa> GNUtoo|laptop: I'll ack it anyways
Jul 07 14:18:23 <GNUtoo|laptop> ah ok
Jul 07 14:22:02 <GNUtoo|laptop> thanks
Jul 07 14:23:02 <JaMa> yw
Jul 07 14:26:23 <mickey|patio> dos1: ok, i see the problem
Jul 07 14:26:33 <mickey|patio> gah, that's going to be not trivial
Jul 07 14:39:32 <mickey|patio> http://trac.freesmartphone.org/ticket/569
Jul 07 14:43:57 <dos1> mickey|patio: ok :) and what about LEDs?
Jul 07 14:45:44 <dos1> mdbus2 lists /org/freesmartphone/Device/LED/gta02_blue_power at org.freesmartphone.odeviced, but when trying to use it says:
Jul 07 14:45:52 <dos1> [ERR]: Unknown object path /org/freesmartphone/Device/LED/gta02_blue_power for org.freesmartphone.odeviced
Jul 07 14:45:57 <dos1> and the same with other LEDs
Jul 07 14:46:17 <dos1> mickey|patio: 
Jul 07 14:46:18 <dos1> root@om-gta02 ~ # ls /sys/class/leds/       
Jul 07 14:46:20 <dos1> gta02::vibrator  gta02:blue:power  gta02:orange:power  gta02:red:aux
Jul 07 14:46:32 <dos1> could it be something with those : ?
Jul 07 14:46:33 <mickey|patio> for various reasons the LEDs are atm. no longer accessible by name
Jul 07 14:46:49 <mickey|patio> but only by index
Jul 07 14:47:03 <mickey|patio> this will be fixed soon, it has to do with vala
Jul 07 14:47:21 <dos1> mickey|patio: [ERR]: No introspection data at object '/org/freesmartphone/Device/LED/0'
Jul 07 14:47:47 <dos1> mickey|patio: i think it was the other side - only by name, and not by index
Jul 07 14:47:55 <dos1> mickey|patio: and that was just kernel update who broke it
Jul 07 14:49:04 <mickey|patio> are the LEDs actually present?
Jul 07 14:49:13 <dos1> mickey|patio: yup, 50db6d2d7bdd7ae7e3bfb70f5db4bcdf64992607 - fsodeviced: kernel26_leds: register dbus objects by name, not by incremental counter
Jul 07 14:49:16 <mickey|patio> what is mdbus -s telling?
Jul 07 14:49:42 <dos1> mickey|patio: they works when using manually from sysfs, and they are listed on "mdbus2 -s org.freesmartphone.odeviced"
Jul 07 14:50:00 <mickey|patio> under which path names do they appear?
Jul 07 14:50:10 <dos1> /org/freesmartphone/Device/LED/gta02_blue_power
Jul 07 14:50:12 <dos1> /org/freesmartphone/Device/LED/gta02_orange_power
Jul 07 14:50:13 <dos1> /org/freesmartphone/Device/LED/gta02_red_aux
Jul 07 14:50:58 <mickey|patio> which mdbus2 rev do you have?
Jul 07 14:51:01 <dos1> mickey|patio: hmm... with mdbus it works, but not with mdbus2
Jul 07 14:51:18 <dos1> mickey|patio: mdbus2 - 1:2.0.0+gitr14+d2189d3f54331fb79a1ca31d6fafe2e8eb2afe46-r0.4
Jul 07 14:52:40 <mickey|patio> ah, that's too old
Jul 07 14:52:54 <mickey|patio> commit d402ed02445acb7e3f84d5c474c8d3d446570d2c
Jul 07 14:52:54 <mickey|patio> Author: Michael 'Mickey' Lauer <mickey@vanille-media.de>
Jul 07 14:52:55 <mickey|patio> Date:   Sat May 29 12:55:39 2010 +0200
Jul 07 14:52:55 <mickey|patio>     mdbus2: allow _ in object paths; fixes FSO #563
Jul 07 14:53:01 <mickey|patio> yours is from April
Jul 07 14:53:22 <dos1> mickey|patio: so we need to update mdbus2 in SHR :x thanks ;)
Jul 07 14:53:26 <mickey|patio> np
Jul 07 14:53:43 <mickey|patio> use c9629132869ab84c70ff58be458e138bcb0e9c58
Jul 07 15:00:58 <dos1> mickey|patio: btw, power LEDs now support different brightness level :)
Jul 07 15:01:29 <mickey|patio> ya, hear about that, we need to enhance/adjust the API then
Jul 07 15:01:56 <mickey|patio> is there a max_brightness node?
Jul 07 15:02:26 <mickey|patio> ok, there should be 
Jul 07 15:02:50 <dos1> mickey|patio: yup, there is
Jul 07 15:03:27 <dos1> mickey|patio: LEDs work now (what i said some time ago was false alarm), just some API enhancements would be nice to make use from it ;)
Jul 07 15:05:09 <mickey|patio> hmm, wait
Jul 07 15:05:31 <mickey|patio> org.freesmartphone.Device.LED.SetBrightness already supports a brightness level
Jul 07 15:06:19 <mickey|patio> what kind of additional calls do you want? brightness for blinking?
Jul 07 15:06:41 <mickey|patio> I'm not sure whether the triggers support that
Jul 07 15:06:58 <mickey|patio> i think pulsing would be awesome
Jul 07 15:08:30 <dos1> yup, i was thinking about pulsing
Jul 07 15:10:08 <mickey|patio> agreed, i have some code for that in the backlight class, will take a look at porting it over to LED
Jul 07 15:11:04 <mickey|patio> although i tend to think that'd be best handled in kernel
Jul 07 15:19:37 <ao2> mickey|patio, there is a "timer" trigger which you control setting delay_on delay_off sysfs attributes
Jul 07 15:20:18 <mickey|patio> yes
Jul 07 15:20:22 <mickey|patio> FSO is using that
Jul 07 15:20:32 <mickey|patio> we're talking about smooth pulsing here though
Jul 07 15:20:43 <mickey|patio> the timer trigger only supports on/off
Jul 07 15:20:45 <mickey|patio> no smooth ram
Jul 07 15:20:45 <mickey|patio> p
Jul 07 15:21:11 <ao2> now I see, _fading_
Jul 07 15:21:18 <mickey|patio> right, that's the correct term
Jul 07 15:21:29 <mickey|patio> (the apple effect ;)
Jul 07 15:21:37 <mrmoku> as that trigger has stuff like heartbeat... fading should fit in there too
Jul 07 15:22:01 <mickey|patio> yeah, i think it'd be best if the LED class had a parameter called 'softness'
Jul 07 15:22:14 <mickey|patio> to smooth all transition in a consistent way
Jul 07 15:22:35 <mickey|patio> I'm sure RP would not be against that
Jul 07 15:22:39 <mickey|patio> if someone comes up with a patch :)
Jul 07 15:22:53 <mickey|patio> (RP = Richard Purdie, led class maintainer)
Jul 07 15:23:18 <mickey|patio> it's way more efficient to do that in kernel space
Jul 07 15:23:54 <gena2x> dos1: ah, had to go away.
Jul 07 15:24:52 <dos1> gena2x: just tell me, if it's possible that your new glamo values need to be recalculated when using other frequencies than 533/88
Jul 07 15:25:07 <gena2x> dos1: lot of touchscreen debugging is one line per touch?
Jul 07 15:25:18 <dos1> gena2x: one line per touch is on SHR kernel
Jul 07 15:25:22 <dos1> gena2x: with your it was much more
Jul 07 15:26:12 <gena2x> dos1:hmmm. may be this is just wrong kernel.
Jul 07 15:26:51 <gena2x> dos1: should be 1 line. and 1 line here.
Jul 07 15:27:04 <gena2x> can you paste, what it printing?
Jul 07 15:27:06 <dos1> hmm
Jul 07 15:27:29 <dos1> gena2x: it was from evtest
Jul 07 15:27:37 <gena2x> dos1: does uname shows 2.6.34b33?
Jul 07 15:28:46 <CIA-58> SHR: 03seba.dos1 07shr-themes * r536d5877b455 10/frameworkd/frameworkd-config-shr/om-gta02/rules.yaml: frameworkd-config-shr: blink red AUX LED when there are unread messages
Jul 07 15:28:50 <CIA-58> SHR: 03seba.dos1 07shr-themes * r4bc1a7e7a59e 10/ (6 files in 5 dirs): Merge branch 'master' of git+ssh://shr.bearstech.com/shr-themes
Jul 07 15:28:51 <CIA-58> SHR: 03seba.dos1 07shr-themes * rf4195e47ed74 10/frameworkd/frameworkd-config-shr/om-gta02/rules.yaml: frameworkd-config-shr: update LED names to work with new kernel
Jul 07 15:28:55 <gena2x> dos1: also, you should avoid io like hell.
Jul 07 15:29:06 <gena2x> dos1: so look at your top.
Jul 07 15:29:19 <dos1> gena2x: yup, i was disabling everything :P
Jul 07 15:29:54 <gena2x> dos1: it should not print much data.
Jul 07 15:31:08 <gena2x> dos1: check uname please.
Jul 07 15:31:28 <dos1> gena2x: moment, now i have booted my daily distro
Jul 07 15:31:56 <gena2x> dos1: envtest??? what it it?
Jul 07 15:32:03 <dos1> gena2x: evtest
Jul 07 15:32:14 <dos1> gena2x: evtest.c IIRC, that's how those lines started
Jul 07 15:32:36 <gena2x> hm....
Jul 07 15:33:02 <mrmoku> dos1: very nice to see you full of activity again :D
Jul 07 15:33:32 <gena2x> dos1: something wrong again.
Jul 07 15:33:43 <dos1> gena2x: i'll recheck it soon
Jul 07 15:33:46 <gena2x> nothing like this here.
Jul 07 15:34:05 <gena2x> dos1: ok, i have to distract again for a hour.
Jul 07 15:36:30 <gena2x> dos1: but after that, i hope we'll be able to finally test it today.
Jul 07 15:38:23 <gena2x> this evtest thingy is soething unrelated.
Jul 07 15:39:09 * Martix_ is going to do opkg upgrade...
Jul 07 15:40:10 <dos1> Martix_: nice, just finished building :)
Jul 07 15:40:43 <dos1> mrmoku: someone has to take care of details here ;)
Jul 07 15:42:05 <dos1> oh
Jul 07 15:42:14 <dos1> frameworkd-config-shr is not autorev? ;x
Jul 07 15:46:31 <mrmoku> dos1: :P
Jul 07 15:46:42 * mrmoku implementing persistent calling identification now
Jul 07 15:47:53 <dos1> yeah ;)
Jul 07 15:48:11 <dos1> mrmoku: in meantime - http://patchwork.dev.bearstech.com/patch/733/ ;)
Jul 07 15:50:55 <dos1> ok, time to "opkg update && opkg upgrade", vibration and LEDs fixed ;)
Jul 07 15:53:56 <mrmoku> dos1: pushed
Jul 07 15:54:05 <mrmoku> and upgraded :-)
Jul 07 15:59:35 <dos1> mrmoku: why don't we upgrade cornucopia?
Jul 07 16:01:37 <mrmoku> dos1: IIRC there is that new flow controlled thing in fsogsmd...
Jul 07 16:01:40 <mrmoku> dunno though
Jul 07 16:02:06 <dos1> shouldn't we want it? :o
Jul 07 16:02:12 <dos1> mickey|patio: ^^^?
Jul 07 16:02:36 <GNUtoo|laptop> mickeyl, ping
Jul 07 16:02:44 <mickey|patio> i'm not sure, i'm not testing much on FR these days
Jul 07 16:02:58 <mrmoku> PaulFertser: your take on it? ^^
Jul 07 16:03:05 <mickey|patio> GNUtoo|laptop: pong
Jul 07 16:03:13 <mrmoku> PaulFertser: guess you're the only one having tried it :/
Jul 07 16:03:18 <PaulFertser> mrmoku: on what?
Jul 07 16:03:23 <GNUtoo|laptop> mickey|patio, did you see my message in #htc-linux ?
Jul 07 16:03:27 <mickey|patio> yes
Jul 07 16:03:29 <PaulFertser> mrmoku: i tried flowcontrol, and filed a ticket
Jul 07 16:03:30 <GNUtoo|laptop> ok
Jul 07 16:04:15 <dos1> mrmoku: well, we should at least upgrade mdbus2
Jul 07 16:05:00 <mrmoku> dos1: yup
Jul 07 16:05:11 <dos1> but i couldn't find where to do it
Jul 07 16:07:10 <mrmoku> dos1: mdbus2_git.bb... it has FSO_CORNUCOPIA_SRCREV in there... and probably needs it's own rev for now
Jul 07 16:07:45 <dos1> mrmoku: will you do that, or should i send patch?
Jul 07 16:08:00 <mrmoku> dos1: I can do
Jul 07 16:08:04 <dos1> ok
Jul 07 16:08:16 <dos1> mrmoku: c9629132869ab84c70ff58be458e138bcb0e9c58
Jul 07 16:08:24 <mrmoku> yeah saw that
Jul 07 16:08:25 <mrmoku> :)
Jul 07 16:08:34 <PaulFertser> mrmoku: i'll try to provide more debuggin info (strace) about that stuff today's evening.
Jul 07 16:09:34 <mrmoku> dos1: pushed
Jul 07 16:09:45 <dos1> thanks
Jul 07 16:09:51 <mrmoku> PaulFertser: thanks
Jul 07 16:16:05 <dos1> new mdbus2 in feeds
Jul 07 16:17:53 <Martix_> X crashed when upgrading, opkg upgrade still in progress...
Jul 07 16:22:49 <Martix_> dos1: and failed: http://pastebin.com/SZgYRt0N
Jul 07 16:22:57 <CIA-58> freesmartphone.org: 03seba.dos1 07cornucopia * re355f2debdca 10/fsodeviced/conf/openmoko_gta/fsodeviced.conf: fsodeviced: enable smooth = down for backlight in Openmoko devices
Jul 07 16:23:17 <dos1> Martix_: oh, you weren't upgrading for some long time
Jul 07 16:23:35 <Martix_> 2 weeks?
Jul 07 16:23:51 <dos1> Martix_: quite long ;)
Jul 07 16:24:37 <dos1> Martix_: opkg remove libdrm libglw1 --force-depends
Jul 07 16:24:41 <dos1> and then opkg upgrade again
Jul 07 16:25:03 <mickey|patio> at some point of time, the display controller of GTA02 was configured to do that in hardware...
Jul 07 16:25:09 <mickey|patio> i think we lost it at some point in the kernel history
Jul 07 16:25:12 <dos1> mickey|patio: yup...
Jul 07 16:25:46 <CIA-58> freesmartphone.org: 03mickey 07cornucopia * r838f00c7b9fb 10/fsogsmd/src/lib/ (atcommands.vala atmediators.vala modem.vala): fsogsmd: add +COPN
Jul 07 16:26:17 <dos1> mickey|patio: but seems that nobody is interested. i'll try to investigate, we can always disable it in fsodeviced when kernel solution comes back ;)
Jul 07 16:26:51 <mickey|patio> right
Jul 07 16:28:04 <Martix_> dos1: thanks
Jul 07 16:42:48 <dos1> hmm
Jul 07 16:42:54 <dos1> gabriel is in our repo :)
Jul 07 16:42:58 <dos1> didn't know about that
Jul 07 16:45:42 <sicu> !logs
Jul 07 16:45:42 <cdbot2> Channel logs for #openmoko-cdevel are archived at:
Jul 07 16:45:43 <cdbot2> http://hentges.net/tmp/logs/irc/%23openmoko-cdevel
Jul 07 16:45:44 <cdbot2> Live-logs are available at
Jul 07 16:45:45 <cdbot2> http://hentges.net/tmp/logs/irc/livelogs/%23openmoko-cdevel.livelog
Jul 07 16:45:47 <cdbot2> See ?? help-logs for usage instructions
Jul 07 16:54:03 <Martix_> what wrong in /etc/init.d/alignment.sh ? because I still have alignment trap errors
Jul 07 17:03:37 <gena2x> dos1: ok, i'm back
Jul 07 17:04:08 <gena2x> dos1: i don't believe you can get slowdown with my kernel except for sd i/o, which is ok.
Jul 07 17:04:58 <gena2x> dos1: i believe artefacts, hangs, or something like this.
Jul 07 17:05:27 <gena2x> dos1: i also had some touchscreen debugging enabled for earlier kernels.
Jul 07 17:05:43 <gena2x> dos1: so, can you check if your kernel is correct?
Jul 07 17:05:44 <dos1> gena2x: so maybe i have something earlier
Jul 07 17:05:52 <dos1> gena2x: i'll check in a moment
Jul 07 17:06:01 <gena2x> dos1: ok, waiting.
Jul 07 17:09:33 <gena2x> dos1: also please run top at bare system via ssh and check it eats 2.0-2.3 cpu
Jul 07 17:12:28 <TAsn> weepee! ff4 is out :P (beta1)
Jul 07 17:18:21 <gena2x> TAsn: lol: Firefox provides uninterrupted browsing for Windows, Linux, and now Mac when there is a crash in the Adobe Flash, Apple Quicktime or Microsoft Silverlight plugins. I
Jul 07 17:18:47 <TAsn> I... ?
Jul 07 17:19:41 <gena2x> TAsn: crash protection from abobe flash plugin, is really funny.
Jul 07 17:19:56 <TAsn> Oh yeah :P
Jul 07 17:19:57 <TAsn> I know.
Jul 07 17:20:13 <gena2x> TAsn: this pulically proves quality of that plugin.
Jul 07 17:20:33 <TAsn> everybody knew that...
Jul 07 17:21:04 <gena2x> TAsn: but flash pretends to be web standard.
Jul 07 17:21:54 <dos1> gena2x: moment, i noticed i have few old packages in my system non upgraded due to changed versioning scheme
Jul 07 17:22:05 <dos1> gena2x: wrote little script to fix that and now opkg is working ;)
Jul 07 17:22:09 <TAsn> gena2x, flash is a standard
Jul 07 17:22:11 <dos1> gena2x: when it's finished, i'll check your kernel
Jul 07 17:22:16 <TAsn> just a bad, broken, non-official and closed one.
Jul 07 17:22:24 <gena2x> dos1: ehh, i know such "moments" ok :)
Jul 07 17:23:33 <gena2x> TAsn: and consuming much energy as it eats much cpu almost continiously. embedded devices can't be happy with this :)
Jul 07 17:23:49 <TAsn> gena2x, that's why it's mostly unavailable for embedded devices :P
Jul 07 17:41:08 <gena2x>  dos1: checked 400/100. is it ok.
Jul 07 17:41:22 <gena2x> s/is it ok/it is ok/
Jul 07 17:41:22 <apt> gena2x meant:  dos1: checked 400/100. it is ok.
Jul 07 17:41:43 <gena2x> dos1: so check for bugs or environment.
Jul 07 17:42:08 <gena2x> err. s/bugs/wrong kernel/
Jul 07 17:43:51 <dos1> it's uImage-b33.bin
Jul 07 17:44:00 <gena2x> check uname.
Jul 07 17:44:48 <dos1> gena2x: Linux om-gta02 2.6.34b33 #68 Wed Jul 7 02:02:09 MSD 2010 armv4tl GNU/Linux
Jul 07 17:45:04 <dos1> gena2x: and when i touch screen, it's flooded with lines like:
Jul 07 17:45:08 <gena2x> dos1: hm..
Jul 07 17:45:27 <dos1> [ 102.530000] evbug.c: Event. Dev: input2, Type: 0, Code: 0, Value: 0
Jul 07 17:45:33 <dos1> type, code and value changes
Jul 07 17:45:47 <gena2x> dos1: run top please and tell how much cpu it eats.
Jul 07 17:46:14 <dos1> gena2x: ~20%
Jul 07 17:46:22 <gena2x> dos1: WHOOH
Jul 07 17:46:23 <dos1> with running only htop, which eats ~5
Jul 07 17:46:40 <gena2x> dos1: so comething wrong for sure!
Jul 07 17:46:54 <dos1> gena2x: yup... with other kernels it's ok ;x
Jul 07 17:47:03 <gena2x> dos1: chech if _anything_ is running.
Jul 07 17:47:14 <gena2x> fso, other stuff.
Jul 07 17:47:17 <mickeyl> i guess you want
Jul 07 17:47:18 <mickeyl> # CONFIG_INPUT_EVBUG is not set
Jul 07 17:47:30 <gena2x> logging.
Jul 07 17:47:31 <dos1> gena2x: nothing. just htop, init, udevd, portmap, sshd, cron, syslogd, klogd, atd, getty, sshd, sh
Jul 07 17:47:39 <dos1> gena2x: i can even kill some of them if you want :P
Jul 07 17:48:01 <gena2x> dos1: may be i placed wrong modules pack. let me rebuild and check.
Jul 07 17:48:16 <dos1> so now only htop, init, sshd, getty and sh
Jul 07 17:48:25 <dos1> stlii ~10-20% :P
Jul 07 17:48:33 <dos1> gena2x: ok
Jul 07 17:48:53 <gena2x> dos1: it top eats not 2%, this is something errh, unrelated.
Jul 07 17:49:10 <Weiss> gena2x: new modem is here :)
Jul 07 17:49:13 <Weiss> time for some experiments..
Jul 07 17:49:16 <dos1> top eats ~1-3% :P
Jul 07 17:49:21 <dos1> htop eats ~5%
Jul 07 17:49:40 <gena2x> may be some sd i/o also. as this is testing kernel, sd i/o causes huge slowdown.
Jul 07 17:50:10 <gena2x> and it is in interrupts, so you'll see 'top' eating some unusully high percents.
Jul 07 17:50:16 <gena2x> Weiss: :)
Jul 07 17:50:34 <dos1> gena2x: i'm not using SD at all, it's just mounted and idle
Jul 07 17:50:56 <gena2x> dos1: hm. this means something else.
Jul 07 17:51:03 <gena2x> dos1: ok, i am rebuilding and checking.
Jul 07 17:51:37 <gena2x> Weiss: let finish this timing idea and try to get some benefit :)
Jul 07 17:54:36 <Weiss> :D
Jul 07 17:55:00 <Weiss> first, I'd like to make a Git branch which matches what you have
Jul 07 17:55:08 <gena2x> ehh..
Jul 07 17:55:34 <Weiss> om-gta02-pimp-my-freerunner or something
Jul 07 17:56:17 <gena2x> it is om-gta02-2.6.34
Jul 07 17:56:34 <Weiss> plus patches?
Jul 07 17:56:37 <gena2x> 4-5 days ago, but this should be not significant.
Jul 07 17:57:18 <gena2x> + ts patch + ThibG patches (don't really tracked all, may be in git now).
Jul 07 17:57:41 <gena2x> Weiss: i think, you may use usual .34.
Jul 07 17:58:46 <gena2x> Weiss: i mean without something extra.
Jul 07 18:05:28 <gena2x> dos1: ah, CONFIG_INPUT_EVBUG=m. so, why you loaded it? do shr loads _all_ modules at boot!!??
Jul 07 18:05:59 <dos1> gena2x: probably udev loaded it...
Jul 07 18:06:16 <gena2x> dos1: sound like this is cause of 'slow down of udev in shr on boot'
Jul 07 18:06:55 <gena2x> dos1: unload please all kernel modules.
Jul 07 18:07:07 <gena2x> dos1: or disable this 'feature'
Jul 07 18:07:20 <gena2x> dos1: imo, modules should be loaded on demand.
Jul 07 18:08:45 <gena2x> or how they loaded in debian...
Jul 07 18:08:48 <dos1> gena2x: disabled udev at all :P
Jul 07 18:09:09 <gena2x> check lsmod
Jul 07 18:09:17 <gena2x> i have:ipv6                  256755  10 
Jul 07 18:09:17 <gena2x> g_ether                26996  0 
Jul 07 18:09:18 <gena2x> joydev                 10077  0 
Jul 07 18:09:18 <gena2x> s3c2410_ts              3941  0 
Jul 07 18:09:35 <gena2x> some really should not needed :)
Jul 07 18:09:52 <gena2x> but nothing more needed for sure.
Jul 07 18:10:21 <dos1> PTY allocation request failed on channel 0 :/
Jul 07 18:10:28 <gena2x> may be one of extra modules causes extra i/o.
Jul 07 18:10:31 <dos1> when trying to ssh... f*ck
Jul 07 18:10:41 <gena2x> yeah :)
Jul 07 18:10:56 <dos1> X boots, but touchscreen doesn't work ;x
Jul 07 18:11:06 <gena2x> it's ok.
Jul 07 18:11:16 <gena2x> you need tslib patch or xorg.conf change.
Jul 07 18:11:19 <dos1> i should really flash that new image without udev ;x
Jul 07 18:11:19 <Weiss> gena2x: ok... are those patches anywhere? also, yours?
Jul 07 18:11:24 <dos1> gena2x: yup. but ssh doesn't work :P
Jul 07 18:12:32 <gena2x> dos1: if ssh not working only way to fix it is host or other partition boot :)
Jul 07 18:13:01 <gena2x> Weiss: you really not need my patch to testing.
Jul 07 18:13:12 <dos1> gena2x: yeah... flashing qi to boot from sd :P
Jul 07 18:13:35 <gena2x> Weiss: as it fixes rates on each sd transfer.
Jul 07 18:13:43 <dos1> (i know i can do that from u-boot, i'm just too lazy to edit env :P)
Jul 07 18:14:03 <gena2x> Weiss: sufficient to boot from nand, umount all sd. and then poke with memory.
Jul 07 18:14:51 <gena2x> Weiss: but better to do this on .34 anyway, as i found strange thing on .29 - like qt on fb works, mplayer not.
Jul 07 18:15:14 <gena2x> and qt can't work after fb.
Jul 07 18:15:34 <gena2x> that's way i am asking to test with .34 kernel.
Jul 07 18:15:46 <gena2x> s/way/why/
Jul 07 18:15:47 <apt> gena2x meant: that's why i am asking to test with .34 kernel.
Jul 07 18:16:29 <gena2x> dos1 just physially remove all modules excpept listed above.
Jul 07 18:16:44 <gena2x> dos1: and give other change to udev :)
Jul 07 18:16:54 <gena2x> s/change/chance/
Jul 07 18:16:54 <apt> gena2x meant: dos1: and give other chance to udev :)
Jul 07 18:17:27 <gena2x> Weiss: wait a bit I'll test a bit modified patch...
Jul 07 18:17:51 <Weiss> gena2x: ok :D
Jul 07 18:18:14 <Weiss> mostly I'm just trying to make sure I know what's going on with 2.6.34 at all - I'm a bit out of date
Jul 07 18:19:45 <gena2x> Weiss: hm. better to ask lars :) i just tested multiple fixes from ThibG about blanking, so have xrandr and blanks flawless now.
Jul 07 18:20:38 <gena2x> Weiss: and i care only about things i am doing with .34, or critical issues (like annoying blanking WS)
Jul 07 18:21:34 <gena2x> Weiss: oh, and also i have your FIFO set to C.
Jul 07 18:22:27 <Weiss> maximum?
Jul 07 18:22:31 <gena2x> Weiss: and btw nobody had problems with it so far :)
Jul 07 18:22:46 <gena2x> as a minimum in framebuffer.
Jul 07 18:22:56 <gena2x> Weiss: yes.
Jul 07 18:23:21 <Weiss> interesting.. when I tried, I had a wobbly display
Jul 07 18:24:03 <gena2x> Weiss: may be some timings also...
Jul 07 18:24:17 <gena2x> Weiss: you may try again :)
Jul 07 18:25:05 <gena2x> gena2x: i mean "may be some timings also" == may be so timing also influenced your displau.
Jul 07 18:26:58 <gena2x> Weiss: ah, no sorry.
Jul 07 18:27:05 <gena2x> Weiss: misinformed.
Jul 07 18:27:24 <gena2x> Weiss: i have 0x4 now (my change were replaced by rebase)
Jul 07 18:27:38 <gena2x> Weiss: hmm. nice idea to try 0xC!!!
Jul 07 18:27:49 <gena2x> Weiss: i forgot about that rebase!
Jul 07 18:28:36 <gena2x> Weiss: so noone really tested C... hm. i were quite sure...
Jul 07 18:29:17 * gena2x building with C
Jul 07 18:29:20 <Weiss> I tested it when I first discovered it.. saw artifacts, went down to 8, still got the occasional artifact, so went down to 4 - the speed benefit was nearly the same
Jul 07 18:30:24 <gena2x> Weiss: something wrong with all that artifacts. may be they caused not by fifo depth, and depth is ok, but some other setting wrong?
Jul 07 18:31:44 <dos1> jffs2: Too few erase blocks (2) ;/
Jul 07 18:31:57 <gena2x> ah...
Jul 07 18:32:38 <gena2x> Weiss: just idea.
Jul 07 18:32:57 <dos1> oh
Jul 07 18:33:02 <dos1> i was using wrong node :D
Jul 07 18:34:51 <Weiss> gena2x: anything's possible..
Jul 07 18:36:43 <gena2x> Weiss: C000 is in GLAMO_REG_LCD_A_BASE2 is ok here so far.
Jul 07 18:36:51 <gena2x>  ( with fb)
Jul 07 18:37:48 <gena2x> hm......
Jul 07 18:38:10 <gena2x> k.
Jul 07 18:38:49 <gena2x> s/k.//
Jul 07 18:38:49 <apt> gena2x meant: 
Jul 07 18:39:23 <Weiss> yep, that's right for max
Jul 07 18:42:42 <gena2x> Weiss: so, kernel is ok for you?
Jul 07 18:48:23 <dos1> gena2x: V:  67.0 805/805 68% 40%  0.0% 0 0 
Jul 07 18:48:40 <gena2x> dos1: is it looks ok?
Jul 07 18:48:52 <gena2x> :)
Jul 07 18:49:18 <Weiss> gena2x: I need some patches to test :)
Jul 07 18:49:54 <gena2x> Weiss: no. you need to change timing on the fly to be able to experiment in wider range.
Jul 07 18:49:57 <gena2x> :)
Jul 07 18:50:03 <dos1> well, it's a little harder to notice redraw, but video is really jumpy
Jul 07 18:50:21 <gena2x> dos1: it's video itself. play it on host.
Jul 07 18:50:32 <gena2x> dos1: try something with 640x360.
Jul 07 18:50:32 <dos1> gena2x: i'm trying also with my videos
Jul 07 18:50:39 <gena2x> at 25fps.
Jul 07 18:50:52 <gena2x> that video is 12fps i think.
Jul 07 18:51:25 <Weiss> gena2x: oh.. you're not actually patching anything?
Jul 07 18:51:54 <gena2x> Weiss: may patch is to have working sd in parallel to glamo timings.
Jul 07 18:51:59 <gena2x> Weiss: my patch is to have working sd in parallel to glamo timings.
Jul 07 18:52:06 <gena2x> but this is workaround.
Jul 07 18:52:24 <gena2x> it sets old timings before each transfer and resets back after.
Jul 07 18:52:40 <gena2x> i mean mmc transfer.
Jul 07 18:52:47 <gena2x> or you just loose mmc data.
Jul 07 18:53:02 <gena2x> cause read is not working, and reason still not found.
Jul 07 18:53:51 <gena2x> i want people to test write, to be sure if it not my hallutination that glamo can be feed with data at higher rate.
Jul 07 18:54:03 <dos1> gena2x: really, video is more jumpy than with other kernels... and i'm out of ideas, why
Jul 07 18:54:04 <gena2x> Weiss: so, you don't need it.
Jul 07 18:54:29 <dos1> gena2x: but... it's doesn't seem to be played slower
Jul 07 18:54:39 <dos1> gena2x: it's... hmm, "music video" recorded by myself ;D
Jul 07 18:54:59 <dos1> gena2x: and lips moves are in normal speed - and that's without -framedrop
Jul 07 18:55:17 <gena2x> with older kernels screen redraw were visible.
Jul 07 18:55:27 <dos1> with other kernels moves were more smooth, but it was like playing in slow motion
Jul 07 18:55:44 <gena2x> this were main problems (for me for example) with watching.
Jul 07 18:55:59 <gena2x> your 68% 40% is actually > 100%
Jul 07 18:56:28 <gena2x> but i have <90% for my movie here with 400/100.
Jul 07 18:56:34 <gena2x> check is any process running.
Jul 07 18:56:38 <gena2x> check top again.
Jul 07 18:57:48 <dos1> ~5% of whole CPU usage
Jul 07 18:58:00 <dos1> when using htop
Jul 07 18:58:01 <gena2x> Weiss: btw i tested accelerated driver, it work for a while, but that just fails. also it seems also read memory too, so it gets some artifacts.
Jul 07 18:58:09 <dos1> with top it's 0.7%
Jul 07 18:58:10 <gena2x> dos1: check top please.
Jul 07 18:58:20 <gena2x> oh... you have busybox one...
Jul 07 18:58:26 <gena2x> can't compare.
Jul 07 18:58:53 <dos1> top is in separate package, or with coreutils?
Jul 07 18:59:18 <dos1> not in separate package ;/
Jul 07 18:59:33 <gena2x> gena@work:~/prg/openmoko/kernel5/linux-2.6$ dpkg -S `which top`
Jul 07 18:59:33 <gena2x> procps: /usr/bin/top
Jul 07 18:59:38 <Weiss> gena2x: xf86-video-glamo you mean?
Jul 07 18:59:43 <dos1> procps, thanks
Jul 07 19:00:09 <gena2x> Weiss: yes. and seem it failing after some big memory read too.
Jul 07 19:00:39 <gena2x> so, issue is same.
Jul 07 19:00:46 <Weiss> interesting..
Jul 07 19:00:59 <gena2x> of course - guess!
Jul 07 19:02:59 <dos1> gena2x: ~ 0.3-1.0%
Jul 07 19:03:25 <gena2x> dos1: ok. anyway, impossible to directly compare valus - different glibc and so.
Jul 07 19:03:32 <dos1> oh, sorry
Jul 07 19:03:40 <gena2x> also, your mplayer is different.
Jul 07 19:03:51 <dos1> ~1.7%
Jul 07 19:03:52 <apt> 0.017
Jul 07 19:03:55 <gena2x> so actually something may be differnt.
Jul 07 19:04:41 <gena2x> i am using top to see 'is a system all right, is it busy with something like irq handling or so?'
Jul 07 19:04:56 <gena2x> 'or may be some dma transfer'
Jul 07 19:05:12 <dos1> gena2x: no, seems like that's only top who eats that 1% :P
Jul 07 19:05:13 <gena2x> so, i just compare with know base value.
Jul 07 19:05:28 <lindi-> ThibG: JaMa: thanks for the kernel build help yesterday. now I hit another problem:  https://docs.openmoko.org/trac/ticket/2345
Jul 07 19:06:35 <gena2x> dos1: you can't see interrupt handling or dma transfers or may be other memory thins.
Jul 07 19:06:47 <gena2x> dos1: in top.
Jul 07 19:06:54 <dos1> V:  13.0 196/196 59% 33%  0.0% 0 0 
Jul 07 19:07:00 <dos1> with -fps 12
Jul 07 19:07:10 <gena2x> 640x480?
Jul 07 19:07:18 <dos1> 640x360
Jul 07 19:07:35 <dos1> with 13 - V:  20.7 311/311 58% 36%  0.0% 0 0 
Jul 07 19:07:58 <gena2x> so it should be smooth.
Jul 07 19:08:00 <dos1> with 14 - V:  14.2 214/214 67% 39%  0.0% 0 0 
Jul 07 19:08:15 <gena2x> hmmm mpeg2 can only do 12, 15, 25??? not?
Jul 07 19:08:28 <gena2x> is it 640x480?
Jul 07 19:08:36 <dos1> gena2x: i'm changing -fps in mplayer :P
Jul 07 19:08:38 <dos1> now
Jul 07 19:08:55 <gena2x> now?
Jul 07 19:09:40 <dos1> before i was using few videos with 12, 15 and 25 bitrares :P
Jul 07 19:09:47 <dos1> s/bitrares/frame rates/
Jul 07 19:09:47 <apt> dos1 meant: before i was using few videos with 12, 15 and 25 frame rates :P
Jul 07 19:10:53 <gena2x> but you speaking about 640x480? also bitrate is very important.
Jul 07 19:11:32 <dos1> 640x360, bitrare 400
Jul 07 19:11:37 <gena2x> try place you video file to tmpfs also.
Jul 07 19:12:03 <gena2x> to avoid delays from video transfer from fs.
Jul 07 19:13:24 <gena2x> first number depend on codec, so you can decrease bitrate to make it less.
Jul 07 19:13:44 <gena2x> second number is affected by my patch.
Jul 07 19:14:07 <dos1> yup, it's dramatically lower than with other kernels
Jul 07 19:14:16 <gena2x> drop nearly x1.7-x1.8.
Jul 07 19:14:22 <dos1> but video is still not so smooth :(
Jul 07 19:14:35 <gena2x> so you may try lower bitrate and have even 25 fps.
Jul 07 19:15:01 <gena2x> ehh. may be on 533/88/clk2 kernel :)
Jul 07 19:15:03 <Weiss> gena2x: so, I need some numbers to use..
Jul 07 19:15:24 <dos1> V:  35.7 429/429 51% 33%  0.0% 0 0 
Jul 07 19:15:25 <gena2x> Weiss: so, kernel is booted, sd card is backuped :)?
Jul 07 19:15:42 <Weiss> yep :)
Jul 07 19:16:06 <gena2x> Weiss: i were running from sd while were doing this :)
Jul 07 19:16:11 <ThibG> lindi-, hm, ok, might be worked around easily in the jbt driver
Jul 07 19:16:19 <ThibG> gena2x, if you remember how we did that ;)
Jul 07 19:17:03 <gena2x> ThibG: ahhhhhhhhh :) git log has good memory :)
Jul 07 19:17:27 <ThibG> I'm not using it personally, and didn't commit it either
Jul 07 19:17:30 <Weiss> lindi-: this is a known problem.. something's not quite right with JBT modesetting..
Jul 07 19:17:51 <gena2x> Weiss: ah. this is patch i have, but not in git :)
Jul 07 19:18:43 <ThibG> anyway, Weiss have done some modifications to JBT driver in its own tree
Jul 07 19:18:49 <Weiss> gena2x: for JBT? or for speed?
Jul 07 19:18:50 <gena2x> ThibG: also allows me to place my fr to fridge and restore from blank :)
Jul 07 19:18:52 <ThibG> I guess we should merge it before we do any work on jbt :)
Jul 07 19:19:38 <lindi-> Weiss: ok, is there a different bug report for it already?
Jul 07 19:19:51 <gena2x> berofe, white screen on blank were temperature-dependant, after - i can place it to fridge and remove without any problems.
Jul 07 19:19:53 <Weiss> lindi-: possibly.. I haven't really been keeping track..
Jul 07 19:19:59 <Weiss> gena2x: want to share? :)
Jul 07 19:20:09 <lindi-> Weiss: I'm reading all the bug reports and have not seen almost anything about 2.6.32
Jul 07 19:20:26 <gena2x> Weiss: i thought it is alreadu in git...
Jul 07 19:20:50 <dos1> gena2x: with bitrare 100 - V:   9.9 120/120 52% 33%  0.0% 0 0 
Jul 07 19:20:59 <dos1> gena2x: and it looks the same (just uglier)
Jul 07 19:21:04 <dos1> fps - 12
Jul 07 19:21:10 <gena2x> dos1: 100 is too blocky.
Jul 07 19:21:27 <gena2x> dos1: no set better fps.
Jul 07 19:21:32 <gena2x> dos1: now set better fps.
Jul 07 19:21:39 <Weiss> gena2x: don't think so... the last ones are ThibG's Glamo cleanups and one more by larsc 
Jul 07 19:21:52 <dos1> gena2x: but it's noticeably more jumpy on FR than on PC
Jul 07 19:22:26 <gena2x> dos1: this means something interrupts decoding process.
Jul 07 19:22:43 <gena2x> dos1: udev? some net? top?
Jul 07 19:23:24 * gena2x checking git log to find jbt patch
Jul 07 19:24:38 <dos1> disabled absolutely everything, now it's only kernel, sshd and mplayer
Jul 07 19:24:54 <dos1> and added -quiet to mplayer
Jul 07 19:24:56 <dos1> looks the same
Jul 07 19:25:23 <gena2x> hm.. if cpu is less than 100 it should be ok.
Jul 07 19:25:34 <lindi-> how how can I turn wifi on with a9254be10ac2294ea20165a87c09ea6 (om-gta02-2.6.32)? I used to do sudo sh -c "echo s3c2440-sdi > /sys/bus/platform/drivers/s3c2440-sdi/bind" but that path does not exist
Jul 07 19:25:38 <gena2x> without any additional 'things'
Jul 07 19:27:09 <dos1> V:  99.2 1191/1191 44% 36%  0.0% 0 0 
Jul 07 19:27:19 <dos1> gena2x: but as i said, it's different than with other kernels
Jul 07 19:27:32 <dos1> here it's jumpy, but speed is correct
Jul 07 19:27:48 <dos1> with other kernels moves are smooth, but played much slower
Jul 07 19:27:53 <gena2x> ph... 80%, you may increase fps!
Jul 07 19:28:17 <gena2x> have no idea really. it is smooth here.
Jul 07 19:28:41 <gena2x> ok, anyway, glamo speed change works for you.
Jul 07 19:29:12 <Weiss> gena2x: I haven't tried anything yet.. just vanilla 2.6.34..  need those numbers :)
Jul 07 19:30:06 <gena2x> Weiss: wait a bit, i am finding jbt patch...
Jul 07 19:30:51 <Weiss> ok..
Jul 07 19:31:12 * Weiss wonders why X doesn't even seem to try to start up on 2.6.34
Jul 07 19:31:28 <gena2x> Weiss: x is ok here.
Jul 07 19:31:40 <dos1> gena2x: the same file, same options, just 15 fps: V:  18.7 281/281 60% 42%  0.0% 0 0 
Jul 07 19:32:59 <Weiss> oh, it's another crazy ".so file is actually a directory" issue
Jul 07 19:33:42 <lindi-> how can I get resume reason with 2.6.32?
Jul 07 19:33:43 <Weiss> root@om-gta02 ~ # ls /usr/lib/libXau.so.6
Jul 07 19:33:44 <Weiss> libecore_imf-ver-pre-svn-05.so.0      libfso-glib.so.0.0.0
Jul 07 19:34:07 <lindi-> there's only /sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/resume_reason
Jul 07 19:34:45 <dos1> gena2x: hmm, after some time of playing: V:  55.6 835/835 51% 41%  0.0% 0 0 
Jul 07 19:35:06 <dos1> but it's still jumpy :( trying with 400/100
Jul 07 19:35:07 <soltys> hi, any idea how to fix http://wklej.org/id/361572/ ? 
Jul 07 19:36:04 <gena2x> Weiss, ThibG : my .34 patches: www.bsdmn.com/openmoko/jbtThibGblankfix+tscheck+voltageallow+1resumefix34.patch
Jul 07 19:36:36 <gena2x> extract drivers/video/backlight/jbt6k74.c for jbt fix
Jul 07 19:36:49 <gena2x> uncomment fix in ts if you need ts fix.
Jul 07 19:36:50 <lindi-> "/sys/class/leds has only one led" -- http://docs.openmoko.org/trac/ticket/2346
Jul 07 19:37:33 <gena2x> ah, lindi- thanks for your work for tracking issues!
Jul 07 19:40:07 <Weiss> gena2x: cool... ts=touchscreen? I only see JBT stuff in there
Jul 07 19:40:26 <gena2x> Weiss: emm... letme check...
Jul 07 19:41:37 <gena2x> Weiss:fixed.
Jul 07 19:41:55 <gena2x> Weiss: just wget created .1 file then i were checking :)
Jul 07 19:43:25 <Weiss> ah :)
Jul 07 19:43:49 <Weiss> lindi-: are you in a position to test that patch from ThibG (via gena2x)?
Jul 07 19:44:00 <lindi-> Weiss: sure
Jul 07 19:44:06 <lindi-> Weiss: if you attach it the bug report
Jul 07 19:44:29 <gena2x> Weiss: better wait for ThibG. this solution may be not optimal or only part is needed.
Jul 07 19:44:54 <lindi-> does SHR really work with 2.6.32?
Jul 07 19:45:22 <dos1> gena2x: oh :o
Jul 07 19:45:27 <dos1> gena2x: WSoD
Jul 07 19:45:30 <gena2x> as does SHR really work with .29 :)
Jul 07 19:45:41 <gena2x> dos1: ?
Jul 07 19:45:47 <dos1> lindi-: we're shiping 2.6.32 now with shr-unstable
Jul 07 19:45:48 <gena2x> usual one?
Jul 07 19:45:48 <lindi-> gena2x: well I'm just wondering since I can't figure out how to switch to host mode
Jul 07 19:45:52 <dos1> gena2x: now i tried 400/100
Jul 07 19:45:55 <lindi-> dos1: does it support usb host mode?
Jul 07 19:46:05 <ThibG> it is not optimal, indeed
Jul 07 19:46:53 <dos1> gena2x: on starting mplayer (not first time, i think ~5th), everything started to fade into white and blinking
Jul 07 19:47:16 <lindi-> don't take me wrong but LED support should be done before working on overclocking :)
Jul 07 19:47:26 <gena2x> dos1: this happenns... sometimes... rare.
Jul 07 19:47:50 <dos1> lindi-: hmm, good question
Jul 07 19:48:27 <lindi-> dos1: or the power led? ;)
Jul 07 19:48:38 <gena2x> lindi-: em... i am just working on things i want to fix. in fact i personally have no need in leds at all,
Jul 07 19:48:41 <dos1> gena2x: but with 400/100 it's playing much better
Jul 07 19:48:45 <dos1> lindi-: LEDs work
Jul 07 19:48:47 <lindi-> gena2x: yes I understand that :)
Jul 07 19:48:54 <lindi-> dos1: they do?  http://docs.openmoko.org/trac/ticket/2346
Jul 07 19:49:13 <gena2x> lindi-: also i don't know if someone do not working on leds already :)
Jul 07 19:49:20 <dos1> lindi-: at our kernel for sure they do
Jul 07 19:49:25 <dos1> lindi-: i played with them today :P
Jul 07 19:49:45 <lindi-> dos1: SHR has patches that are not in git.openmoko.org? or is it the config?
Jul 07 19:49:50 <gena2x> lindi-: check shr patches also. Jama patches some things silently :)
Jul 07 19:49:56 <lindi-> sigh
Jul 07 19:50:10 <Weiss> ThibG: what's wrong with it, in your opinion?
Jul 07 19:50:37 <lindi-> JaMa: ping? ;)
Jul 07 19:50:40 <dos1> lindi-: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-openmoko-2.6.32_git.bb
Jul 07 19:50:51 <dos1> lindi-: and http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-openmoko-2.6.32
Jul 07 19:51:01 <dos1> lindi-: maybe that's the one? http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-openmoko-2.6.32/0006-gta02-defconfigs-enable-LEDS_S3C24XX-and-dummy-batte.patch
Jul 07 19:51:47 <JaMa> 1pong
Jul 07 19:52:04 <lindi-> JaMa: how about moving these patches to git.openmoko.org? would be nice to have LEDs also in other distributions :)
Jul 07 19:52:10 <dos1> hmm, there's something for usbhost
Jul 07 19:52:23 <dos1> maybe that's just fsodeviced which needs to learn about new sysfs node
Jul 07 19:52:28 <ThibG> Weiss, first, I'm not sure if the mdelay can be avoided or not
Jul 07 19:52:43 <ThibG> 200ms is a huge delay
Jul 07 19:52:46 <lindi-> dos1: i'm not using fso
Jul 07 19:52:50 <JaMa> lindi-: I don't have R/W and I did ping larsc with that patch before probably.. but didn't want to bother him more..
Jul 07 19:53:03 <dos1> lindi-: i mean here, as from shr-settings usbhost also doesn't work ;)
Jul 07 19:53:10 <dos1> but didn't check kernel yet
Jul 07 19:53:13 <ThibG> if we can avoid it, or know when it's ready, instead of waiting that long each time
Jul 07 19:53:15 <JaMa> dos1: yes the node is changed
Jul 07 19:53:31 <JaMa> dos1: I've updated usb-host-mode script in openmoko wiki, but not shr-settings
Jul 07 19:53:35 <lindi-> JaMa: any idea where it is? I did find many others but not usb host mode
Jul 07 19:53:37 <gena2x> ThibG: may be pcf knows voltage?
Jul 07 19:53:45 <JaMa> dos1: read usbhost.patch header
Jul 07 19:53:47 <dos1> JaMa: that's not shr-settings to update, but fsodeviced :P
Jul 07 19:54:03 <JaMa> lindi-: http://git.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-openmoko-2.6.32/0003-usbhost.patch.patch
Jul 07 19:54:37 <JaMa> lindi-: or just check all SHR patches in http://gitorious.org/~jama/htc-msm-2-6-32/openmoko-kernel/
Jul 07 19:56:19 <gena2x> also may be someone is able to commit my ar6000 patch finally?
Jul 07 19:56:35 <gena2x> as anyway everyone using it.
Jul 07 19:56:39 <dos1> gena2x: rare? got the same now...
Jul 07 19:57:09 <gena2x> dos1: hm... may be this is more frequent at /100?
Jul 07 19:57:27 <dos1> and now everything is updating with that jumpy framerate as movies, even text in framebuffer
Jul 07 19:57:31 <dos1> ;x
Jul 07 19:57:42 <gena2x> :)
Jul 07 19:57:48 <gena2x> this happens.
Jul 07 19:57:54 <gena2x> hope it is fixable.
Jul 07 19:58:04 <dos1> trying 450/112 :D
Jul 07 19:58:09 <gena2x> ah :)
Jul 07 19:58:17 <lindi-> JaMa: ok, what about resume reason?
Jul 07 19:58:22 <gena2x> you may be will need 1.9 v patch.
Jul 07 19:58:29 <dos1> gena2x: kernel works :)
Jul 07 19:58:45 <dos1> i'm quite interested in this one - 450>400 and 112>100
Jul 07 19:58:51 <JaMa> lindi-: nobody ported it from .29 yet
Jul 07 19:58:52 <gena2x> good so far.
Jul 07 19:59:00 <dos1> and both still in spec, am i right?
Jul 07 19:59:09 <JaMa> lindi-: but we can live without it for now
Jul 07 19:59:10 <gena2x> 4x0  kernels are best.
Jul 07 19:59:14 <lindi-> JaMa: I can't
Jul 07 19:59:24 <lindi-> JaMa: I have periodic RTC wakeups for watchdog
Jul 07 19:59:31 <gena2x> dos1: i hope so.
Jul 07 19:59:37 <lindi-> JaMa: I need to distinguish between power button wakeup and RTC wakeup
Jul 07 19:59:50 <gena2x> dos1: i didn't check check of everything on bus.
Jul 07 19:59:57 <gena2x> dos1: i didn't check spec of everything on bus.
Jul 07 20:00:18 <gena2x> but if you kernel is ok, may be you can leave with usual voltage.
Jul 07 20:00:41 <gena2x> so you need just u-boot with usual voltage, check my page, may be it has one.
Jul 07 20:01:13 <dos1> i used u-boot.udfu_450_112_1.65_1.9
Jul 07 20:02:12 <gena2x> dos1: i didn't pushed 1_8 version....
Jul 07 20:02:34 <gena2x> dos1: but i think should be no problem running 1.9
Jul 07 20:02:47 <gena2x> and 465 is even better.
Jul 07 20:03:01 <dos1> it's running faster, less jumpy
Jul 07 20:03:14 <dos1> V:  49.5 743/743 44% 30%  0.0% 0 0 
Jul 07 20:03:20 <gena2x> :)
Jul 07 20:03:25 <dos1> that's 15.000 fps  182.5 kbps
Jul 07 20:03:26 <JaMa> lindi-: then talk with larsc, last time I've asked about it, he said it's hack not worth maintaining in om git because of minimal usage.. so maybe you can convince him..
Jul 07 20:03:34 <gena2x> you may increase bitrate and fps :)
Jul 07 20:03:36 <dos1> well, but still not really smooth ;]
Jul 07 20:04:06 <gena2x> larsc: may be add my ar6000 patch to git?
Jul 07 20:04:06 <dos1> hmm
Jul 07 20:04:18 <dos1> 15.000 fps  392.8 kbps
Jul 07 20:04:21 <dos1> V:  17.7 266/266 60% 30%  0.0% 0 0 
Jul 07 20:04:31 <larsc> gena2x: what patch?
Jul 07 20:04:33 <gena2x> dos1: better try 25 fps :)
Jul 07 20:04:40 <dos1> 24.000 fps  298.4 kbps
Jul 07 20:04:54 <dos1> little too much - V:  17.3 417/417 81% 49%  0.0% 0 0 
Jul 07 20:05:09 <gena2x> larsc: https://docs.openmoko.org/trac/ticket/2327
Jul 07 20:05:15 <dos1> but speedup is noticeable
Jul 07 20:05:22 <dos1> 500/83 is much slower
Jul 07 20:05:23 <gena2x> larsc: it is used in both qtmoko and shr for long time.
Jul 07 20:05:29 <dos1> 400/100 is also slower, but not that much
Jul 07 20:05:31 <dos1> ;)
Jul 07 20:05:44 <lindi-> JaMa: huh
Jul 07 20:05:47 <dos1> seems that memory clock is very important?
Jul 07 20:05:51 <gena2x> dos1: important to have clk2 in 500mhz kernels.
Jul 07 20:06:08 <lindi-> JaMa: i'll write all these down
Jul 07 20:06:24 <dos1> gena2x: clk2 was that one which didn't boot for me? :P
Jul 07 20:06:35 <gena2x> dos1: yeah.
Jul 07 20:06:39 <dos1> nice :P
Jul 07 20:06:46 <gena2x> dos1: see lmbench, and all will be clear.
Jul 07 20:06:47 <dos1> trying 465/116
Jul 07 20:07:16 <dos1> now 450/112 is my favorite ;)
Jul 07 20:07:33 <gena2x> the 465/116 is even better.
Jul 07 20:08:01 <dos1> when suspend/resume will work with it, i'll use 465/116 or 450/112 daily
Jul 07 20:08:14 <gena2x> but i prefer 533/88/clk2 to avoid mem voltage change.
Jul 07 20:08:30 <dos1> hmm
Jul 07 20:08:37 <gena2x> dos1: if it works at 1.8 for you, the 465 is much better.
Jul 07 20:09:01 <gena2x> and if you have unmodified kernel - it works.
Jul 07 20:09:01 <dos1> gena2x: with your kernel, it boots at 1.8?
Jul 07 20:09:18 <gena2x> dos1: you may check voltages in dmesg.
Jul 07 20:09:46 <gena2x> dos1: DOWN2 if I am not missing anything
Jul 07 20:10:00 <dos1> booted
Jul 07 20:10:06 <gena2x> dos1: or via sysfs interface.
Jul 07 20:10:16 <dos1> now waiting for crash or finishing boot :D
Jul 07 20:11:46 <dos1> gena2x: i can't see them in dmesg
Jul 07 20:11:51 <dos1> but booted ;)
Jul 07 20:11:58 <gena2x> dos1: so, ok :)
Jul 07 20:11:59 <ThibG> gena2x, maybe
Jul 07 20:12:44 <gena2x> ThibG: :)
Jul 07 20:13:05 <ThibG> I don't know a thing about pcf
Jul 07 20:13:20 <gena2x> ThibG: it has nice docs.
Jul 07 20:16:26 <dos1> gena2x: oh!
Jul 07 20:16:31 <dos1> gena2x: it resumed from suspend!
Jul 07 20:16:36 <dos1> gena2x: ...once... ;D
Jul 07 20:16:38 <gena2x> dos1: once :)
Jul 07 20:16:43 <gena2x> i know this :)
Jul 07 20:16:44 <dos1> gena2x: now it doesn't want to :D
Jul 07 20:17:01 <gena2x> it resumes once, on 400/100 kernel too.
Jul 07 20:17:18 <dos1> oh
Jul 07 20:17:21 <gena2x> and ThibG have no idea atm :)
Jul 07 20:17:25 <dos1> so i have to try this uboot with other kernels
Jul 07 20:17:31 <dos1> :)
Jul 07 20:17:58 <gena2x> Weiss: ok, lets go back to glamo timings?
Jul 07 20:19:01 <Weiss> gena2x: sure.. things are looking good with the ThibG patch, by the way
Jul 07 20:21:38 <gena2x> Weiss: i have memwrite tool to change memory from userspace.
Jul 07 20:22:04 <gena2x> Weiss: have something like this or i can share one?
Jul 07 20:22:15 <Weiss> just to poke registers?
Jul 07 20:22:22 <gena2x> poke /dev/mem.
Jul 07 20:22:57 <gena2x> ok. i'll post code...
Jul 07 20:23:44 <Weiss> could cook one up, but time saving is always good..
Jul 07 20:24:45 <gena2x> Weiss: so, some tools at bsdmn.com/openmoko/glamo/timings
Jul 07 20:26:05 <gena2x> Weiss: ahh, i accidently erased my flash (flashed u-boot to rootfs :( ) , so latest fbtest seem lost :(((
Jul 07 20:26:20 <gena2x> bad. i want it to demonstrate read problem.
Jul 07 20:26:32 <gena2x> also old one has bugs.
Jul 07 20:26:51 <gena2x> Weiss: ok, so we have memwrite.
Jul 07 20:27:01 <ThibG> lindi-, have you tried with the patch, for the WS thing with dpms settings?
Jul 07 20:27:16 <gena2x> it is urgly, but accepts two numbers : address and value
Jul 07 20:27:30 <gena2x> if only one is supplied, it shows memory.
Jul 07 20:27:38 <gena2x> our address is 1207959560
Jul 07 20:27:46 <lindi-> ThibG: building   http://docs.openmoko.org/trac/ticket/2346#comment:1
Jul 07 20:28:14 <ThibG> ok
Jul 07 20:28:25 <gena2x> you should have 7104 in it now
Jul 07 20:28:32 <gena2x> 1BC0
Jul 07 20:28:51 <gena2x> check cpu manual page 5-15 for meaning.
Jul 07 20:29:29 <gena2x> i changed this to 1BCF.
Jul 07 20:29:38 <gena2x> but CB also works.
Jul 07 20:29:56 <gena2x> may be even without paging values may be tuned to match glamo specs.
Jul 07 20:31:24 <gena2x> Weiss: see also diagrams before (for 16bit sram) and somewhere in 'electrical data'
Jul 07 20:32:37 <gena2x> Weiss: i thought in this way: why glamo bus is slow... hm. wher it is setup? blooody hell. :)
Jul 07 20:32:52 <Weiss> indeed..
Jul 07 20:33:56 <gena2x> and immediately saw this settings on first page you mail thread you mentioned.
Jul 07 20:34:09 <gena2x> wher andy didn't even tried to turn on pages.
Jul 07 20:34:44 <gena2x> or didn't tried because of glamo specs. i don't know.
Jul 07 20:35:07 <gena2x> also, i immediately realise that glamo ram is sram.
Jul 07 20:35:21 <gena2x> and that sram is generally faster than sdram.
Jul 07 20:35:31 <gena2x> and wondered much.
Jul 07 20:36:07 <gena2x> but i immediately enable burst mode and saw results.
Jul 07 20:39:57 <gena2x> ok, so you may try to play with framebuffer, check screen fill time or so.
Jul 07 20:40:15 <gena2x> glamofbtest tool may help. but may also need so changes too.
Jul 07 20:40:43 <lindi-> gena2x: ThibG: do sounds work for you with 2.6.32?
Jul 07 20:40:53 <lindi-> here speaker-test dies with 'Write error: -110,Connection timed out'
Jul 07 20:41:16 <gena2x> lindi-: last time i checked it were working. but really unsure.
Jul 07 20:41:18 <ThibG> honestly, I haven't tested anything on 2.6.32 yet :)
Jul 07 20:41:35 <gena2x> lindi-: better go fix it on .34 :)
Jul 07 20:41:42 <gena2x> lindi-: ah, recalled!
Jul 07 20:41:43 <lindi-> gena2x: ok but i'll file a bug
Jul 07 20:41:48 <gena2x> lindi-: wait
Jul 07 20:42:00 <gena2x> lindi-: try state files from shr first.
Jul 07 20:42:30 <gena2x> lindi-: i can recall something like alsa mixer names cut issue, so you can't load old statefiles
Jul 07 20:42:50 <gena2x> lindi-: so, dai mode or something like this wrong, so you can't play sound :)
Jul 07 20:43:05 <gena2x> lindi-: but i'm unsure. so check, may be kernel is ok.
Jul 07 20:43:27 <gena2x> hmmm.. btw may be same thing on .34...
Jul 07 20:44:18 <PaulFertser> gena2x: of course one can't load old andy-tracking state-files, not sure if the result should be write error though.
Jul 07 20:44:54 <gena2x> ^^^ whooh :) my memory is ok :)
Jul 07 20:46:33 <lindi-> gena2x: amixer -qc0 cset numid=50,name='DAI Mode' 0?
Jul 07 20:47:06 <gena2x> oh. not sure better try shrs to be sure.
Jul 07 20:47:12 <gena2x> and diff.
Jul 07 20:47:36 <lindi-> well hmm, no idea where shr keeps these
Jul 07 20:48:02 <gena2x> hmm. i extracted from tgz :)
Jul 07 20:48:08 <PaulFertser> gena2x: only long names were affected, so DAI shouldn't be among those.
Jul 07 20:48:09 <gena2x> afair.
Jul 07 20:48:32 <gena2x> PaulFertser: yes. that's why i am very unsure.
Jul 07 20:49:00 <gena2x> PaulFertser: but dunno which other setting may cause write error.
Jul 07 20:50:00 <lindi-> gena2x: I attached my amixer contents
Jul 07 20:50:17 <lindi-> gena2x: does sound play for you if you run   http://docs.openmoko.org/trac/raw-attachment/ticket/2347/amixer.cmds
Jul 07 20:50:39 <gena2x> lindi-: i have no .32 anymore.
Jul 07 20:50:45 <lindi-> ok
Jul 07 20:50:54 <lindi-> gena2x: and .34 changes this too?
Jul 07 20:51:21 <gena2x> lindi-: oh, yes!
Jul 07 20:51:36 <gena2x> lindi-: also check if all required modules loaded!
Jul 07 20:51:55 <lindi-> gena2x: what might those be? ;)
Jul 07 20:51:56 <gena2x> lindi-: but this memory already faded.
Jul 07 20:52:05 <gena2x> lindi-: so completly unsure.
Jul 07 20:52:06 <gena2x> :)
Jul 07 20:52:25 <gena2x> check dmesg for .29 and .32
Jul 07 20:52:36 <gena2x> from sound point of view to check this.
Jul 07 20:54:12 <lindi-> well there is 'asoc: WM8753 HiFi <-> s3c24xx-i2s mapping ok'
Jul 07 20:54:48 <gena2x> lindi-: ok. i told all i know, let me go back to glamo timings..
Jul 07 20:54:53 <lindi-> :)
Jul 07 20:55:27 <lindi-> aha, Xorg crashes if I say "xset q"
Jul 07 20:55:55 <gena2x> do you find bugs or they find you?
Jul 07 20:57:12 <lindi-> this was already reported and fixed
Jul 07 20:57:16 <lindi-> now it broke again :)
Jul 07 20:57:42 <gena2x> lindi-: i heard, that not all changes from .29 were merged to .32/.34.
Jul 07 20:58:02 <gena2x> but sounds like nice change to review solutions :)
Jul 07 20:58:53 <lindi-> wtf. i found a bug in xdm
Jul 07 20:59:26 <gena2x> lindi-: this is 5th in last 2 hours ;)
Jul 07 20:59:48 <lindi-> not a serious one but very surprising
Jul 07 21:00:02 <lindi-> with my pam setup, if you enter no username it'll login as "nobody"
Jul 07 21:00:22 <lindi-> i'm quite sure it did not do this last time I tested
Jul 07 21:02:25 <TAsn> wth?! I didn't get any spam for a whole week now.
Jul 07 21:02:35 <TAsn> Did they run out of viagra?!
Jul 07 21:03:02 <sicu> yeh, probably my fault ... i bought a large shipment ;p
Jul 07 21:04:38 <lindi-> TAsn: have you reported a bug about it? ;)
Jul 07 21:05:07 <TAsn> I tried, but I don't want to report a bug without further investigating it, I don't want to spam their inboxes for nothing...
Jul 07 21:05:18 <TAsn> I tried = I want ot
Jul 07 21:05:20 <TAsn> to
Jul 07 21:05:37 <TAsn> as I don't*
Jul 07 21:05:42 <TAsn> ffs I should get some sleep.
Jul 07 21:06:38 <TAsn> p.s
Jul 07 21:07:00 <TAsn> mrmoku|away, mickey|WM: sorry :( I was cheering for you.
Jul 07 21:07:10 <TAsn> Anyhow, ciao.
Jul 07 21:08:59 <mickey|grr> TAsn: thanks. cu
Jul 07 21:09:28 <TAsn> grr = exactly. :|
Jul 07 21:16:44 <PaulFertser> mickey|grr: hey mickey. The best cure is to dive into the work ;)
Jul 07 21:16:53 <PaulFertser> mickey|grr: i've updated the ticket with useful strace log.
Jul 07 21:17:49 <PaulFertser> mrmoku|away: ^
Jul 07 21:26:29 <PaulFertser> ~lart gsm at commands protocol developers
Jul 07 21:26:41 <PaulFertser> fuck you bloody bastards
Jul 07 21:27:02 * apt executes killall -TERM gsm at commands protocol developers
Jul 07 21:30:12 <PaulFertser> ~lart Hayes not because they did something ad hoc in the 70s but because they "started enforcing the patent, charging $1 per modem that used it"
Jul 07 21:30:13 * apt slams Hayes not because they did something ad hoc in the 70s but because they "started enforcing the patent, charging $1 per modem that used it" against a large cement Tux
Jul 07 22:12:50 <mickey|grr> PaulFertser: are you sure you attached the strace to the right bug? 
Jul 07 22:13:12 <mickey|grr> PaulFertser: strace for #567 looks good, it resumes because there is an incoming SMS
Jul 07 22:13:31 <mickey|grr> the SMS gets lost (and i think i know why), but the immediate resume seems correct at least
Jul 07 22:13:51 <PaulFertser> mickey|grr: the parser gets confused because it should wait for the unsol pdu
Jul 07 22:14:00 <PaulFertser> mickey|grr: it resumes because i have my patch applied
Jul 07 22:14:13 <PaulFertser> mickey|grr: i'm not sure why you haven't commented on it yet ;)
Jul 07 22:14:28 <mickey|grr> hmm?
Jul 07 22:14:30 <mickey|grr> i'm lost
Jul 07 22:14:55 <mickey|grr> the strace you attached to #567 looks rather like an example for the other bug you opened
Jul 07 22:15:00 <mickey|grr> the one for losing incoming SMS
Jul 07 22:15:29 <PaulFertser> mickey|grr: btw, i want to tell you i quite like how you designed fsogsmd
Jul 07 22:15:39 <PaulFertser> mickey|grr: http://trac.freesmartphone.org/attachment/ticket/567/0001-fsogsmd-fix-suspend-resume-issue-surfaced-after-intr.patch
Jul 07 22:15:46 <mickey|grr> (design) oh, thanks :)
Jul 07 22:15:54 <PaulFertser> mickey|grr: without this patch it doesn't work at all of course
Jul 07 22:16:00 <mickey|grr> sure
Jul 07 22:16:10 <mickey|grr> and i committed this immediately when you added it
Jul 07 22:16:13 <mickey|grr> didn't i?
Jul 07 22:16:48 <PaulFertser> mickey|grr: with this patch i got lost message. Probably i should have attached the strace log to another bug. But since i mentioned i still have weird problems on the ticket, i thought i should post it there. My mistake.
Jul 07 22:16:57 <mickey|grr> no problem
Jul 07 22:17:01 <mickey|grr> i'm glad for the strace
Jul 07 22:17:08 <PaulFertser> mickey|grr: (committed) tbh i'm not following your commits _that_ closely.
Jul 07 22:17:12 <mickey|grr> :)
Jul 07 22:17:14 <PaulFertser> So i might have missed it.
Jul 07 22:17:18 <PaulFertser> Sorry.
Jul 07 22:17:25 <mickey|grr> commit b1ff31cbb7f00cfe5669975e80d561dbe46350e9
Jul 07 22:17:25 <mickey|grr> Author: Paul Fertser <fercerpav@gmail.com>
Jul 07 22:17:25 <mickey|grr> Date:   Sun Jun 27 00:31:03 2010 +0400
Jul 07 22:17:48 <mickey|grr> the problem is that all my AT commands know about prefixes etc.
Jul 07 22:17:51 <mickey|grr> however
Jul 07 22:18:03 <mickey|grr> the bulk commands send @ init and suspend/resume bypass the logic
Jul 07 22:18:04 <PaulFertser> mickey|grr: endoflinePerhapsSolicited should not assume PDU is for it when pendingpdu was set by endoflineSurelyUnsolicited
Jul 07 22:18:18 <PaulFertser> mickey|grr: no?
Jul 07 22:18:23 <mickey|grr> no
Jul 07 22:18:34 <mickey|grr> the bulk commands are sent without the notion of known prefixes
Jul 07 22:18:47 <mickey|grr> and this is the actual problem
Jul 07 22:19:01 <mickey|grr> i took a shortcut here
Jul 07 22:19:02 <mickey|grr> :/
Jul 07 22:19:28 <mickey|grr> you might be right, btw.
Jul 07 22:19:30 <PaulFertser> mickey|grr: i tried to follow the code logic closely. I can imagine the +CMT: is handled by endoflineSurelyUnsolicited, sets pendingPDU. And then you emit another command.
Jul 07 22:19:43 <PaulFertser> mickey|grr: haveCommand() returns true;
Jul 07 22:19:56 <PaulFertser> so the PDU is handled by PerhapsSolicited
Jul 07 22:21:37 <mickey|grr> hmm, right
Jul 07 22:21:49 <mickey|grr> so i would need to track who set the 'pendingPDU'
Jul 07 22:21:58 <mickey|grr> or rather differenciate
Jul 07 22:22:00 <mickey|grr> unsolicitedPendingPDU
Jul 07 22:22:01 <mickey|grr> and
Jul 07 22:22:03 <mickey|grr> solicitedPendingPDU
Jul 07 22:22:34 <mickey|grr> ~kill AT
Jul 07 22:22:35 * apt shoots a inverse anti-meson gun at AT
Jul 07 22:22:57 <PaulFertser> mickey|grr: i guess so. Anyway, reading atparser.vala was surprisingly easier than i expected when i started to think about how bloody stupid the at command protocol is. Good code pays off, for real. 
Jul 07 22:23:04 <mickey|grr> :)
Jul 07 22:23:44 <mickey|grr> ok, this gives me a good headstart 
Jul 07 22:23:52 <mickey|grr> i'll try to fix this asap
Jul 07 22:23:54 <mickey|grr> thanks a lot
Jul 07 22:24:04 * mickey|grr appends the IRC log to the bug
Jul 07 22:24:27 <PaulFertser> mickey|grr: :D
Jul 07 22:24:47 <PaulFertser> mickey|grr: btw, the magically lost message case seems to be unrelated now, and still a mistery.
Jul 07 22:24:57 <mickey|grr> right
Jul 07 22:27:17 <PaulFertser> mickey|grr: (talking of open tickets) http://trac.freesmartphone.org/ticket/559 should be closed i assume.
Jul 07 22:27:31 <mickey|grr> oh right, let me do that now
Jul 07 22:30:16 <GNUtoo> mickey|grr, hi they made battery loading wotk under n900
Jul 07 22:30:23 <GNUtoo> https://elektranox.org/website/debian_on_n900.html
Jul 07 22:30:30 <GNUtoo> look the script at the end
Jul 07 22:31:03 <GNUtoo> Battery Charging is done by closed source BME daemon in Maemo. Pancake wrote a script to charge the battery without this daemon based on information from the public available specs  and the not working script from forum.
Jul 07 22:32:28 <GNUtoo> but maybe you already know
Jul 07 22:33:10 <GNUtoo> mickey|grr, btw why are you upset? tired + thing not working?
Jul 07 22:33:26 <PaulFertser> GNUtoo: you're not following the "big sport" news.
Jul 07 22:33:28 <PaulFertser> ;)
Jul 07 22:33:38 <GNUtoo> ah germany lost?
Jul 07 22:33:39 <mickey|grr> GNUtoo: no, just that the german team has played lousy and is out
Jul 07 22:33:44 <GNUtoo> ouch
Jul 07 22:33:45 <GNUtoo> ok
Jul 07 22:34:01 <mickey|grr> (n900) interesting, didn't know that. thanks
Jul 07 22:34:33 <mickey|grr> hmm, that brings the n900 back into the league of interesting devices
Jul 07 22:34:36 <PaulFertser> mickey|grr: they also got usb host mode sorta working. So the hardware is ok, but someone needs to finally write a decent consistent kernel patch.
Jul 07 22:35:04 <mickey|grr> cool
Jul 07 22:35:18 <PaulFertser> mickey|grr: of course DocScrutinizer51 was heavily involved
Jul 07 22:35:20 <mickey|grr> now where do i get one from...
Jul 07 22:35:27 <mickey|grr> can't afford buying more gadgets
Jul 07 22:35:56 <mickey|grr> also with so many half-finished, it gives me a bad feeling to go anywhere else
Jul 07 22:36:03 <GNUtoo> indeed
Jul 07 22:36:06 <GNUtoo> I'll finish dream
Jul 07 22:36:09 <PaulFertser> mickey|grr: another news: Nokia thinks their customers are shit and breaches of their privacy by Maemo update. And never apologise.
Jul 07 22:36:24 <mickey|grr> PaulFertser: :/
Jul 07 22:36:47 <gena2x> btw nice review by anre anka in community-ml.
Jul 07 22:37:02 <GNUtoo> maybe N900 is better than the palm pre then
Jul 07 22:37:21 <GNUtoo> but palm pre will be ready sooner
Jul 07 22:37:35 <GNUtoo> the issue with n900 seem to be the space bar
Jul 07 22:37:40 <GNUtoo> too bad it's not cheap
Jul 07 22:38:31 <PaulFertser> mickey|grr: http://tabulacrypticum.wordpress.com/2010/06/10/maemo-missteps-for-2010/ + http://tabulacrypticum.wordpress.com/2010/06/27/an-open-letter-to-nokia-for-2010/ for your reference if you're bored and want to read some stuff about nokia/maemo/meego
Jul 07 22:38:33 <GNUtoo> there is a free tool to interact with their bootloader...
Jul 07 22:41:05 <mickey|grr> cool, thanks for the pointers. will mark to read. but not today. g'night folks
Jul 07 22:41:16 <PaulFertser> mickey|grr: thanks, and good night
Jul 07 22:45:19 <gena2x> Weiss: still around?
**** ENDING LOGGING AT Thu Jul 08 02:59:57 2010