00:02:10 | | Join Bagder [0] (~daniel@as3-3-2.ras.s.bonet.se) |
00:54:13 | *** | Saving seen data "./dancer.seen" |
01:00 |
01:18:47 | | Part Bagder |
01:51:03 | | Join MeRWiN [0] (~merwin@63.98.122.204) |
01:56:48 | | Quit MeRWiN () |
02:00 |
02:11:49 | | Join mistaRx [0] (mistaX@t4o75p117.telia.com) |
02:30:03 | | Quit datazone ("Client Exiting") |
02:37:47 | | Quit mistaRx () |
02:45:56 | | Quit Tumm (Read error: 113 (No route to host)) |
02:54:17 | *** | Saving seen data "./dancer.seen" |
03:00 |
03:32:24 | | Join MeRWiN [0] (~merwin@63.98.122.204) |
03:48:51 | MeRWiN | how often is a tick? |
04:00 |
04:00:42 | elinenbe | a tick or a tock? |
04:04:22 | MeRWiN | heh |
04:04:59 | MeRWiN | OK, any clue on how to sleep() a thread from within wps.c? |
04:09:57 | elinenbe | give it a bed. Some nice pillows will help too. Maybe some soft music and warm milk. |
04:15:15 | | Join MrHad [0] (~chad@sub18-251.member.dsl-only.net) |
04:24:53 | MeRWiN | that is true |
04:24:56 | MeRWiN | i should try that |
04:25:05 | MeRWiN | although i think the archos wouldn't like that too much |
04:28:58 | | Join Bombelman [0] (george@206.61.44.18) |
04:29:04 | Bombelman | hi |
04:29:39 | Bombelman | anyone here ? |
04:30:13 | | Quit Bombelman (Client Quit) |
04:54:19 | *** | Saving seen data "./dancer.seen" |
05:00 |
05:03:26 | MrHad | Hi all great project. |
05:03:27 | | Quit MeRWiN (Read error: 104 (Connection reset by peer)) |
05:09:45 | | Join datazone [0] ([d8A2tDIdR@207.136.36.203) |
05:25:32 | | Quit elinenbe ("User pushed the X - because it's Xtra, baby") |
05:28:13 | | Nick dwihno is now known as dwihno|gone (dwihno@193.180.246.67) |
05:30:33 | | Quit MrHad (Remote closed the connection) |
05:52:57 | | Join MeRWiN [0] (~merwin@63.98.122.204) |
06:00 |
06:16:32 | | Join elinenbe [0] (trilluser@pcp02254422pcs.wanarb01.mi.comcast.net) |
06:24:29 | | Join elinenbe_ [0] (trilluser@pcp02254422pcs.wanarb01.mi.comcast.net) |
06:24:30 | | Quit elinenbe (Read error: 104 (Connection reset by peer)) |
06:54:24 | *** | Saving seen data "./dancer.seen" |
06:56:53 | | Quit MeRWiN () |
07:00 |
07:27:09 | | Join Linus [0] (~linus@193.15.23.131) |
07:32:56 | elinenbe_ | morning Linus. |
07:33:00 | elinenbe_ | I must head to sleep soon |
07:33:10 | Linus | morning |
07:34:59 | elinenbe_ | well, I am going to sleep. Good luck on the project today. What do you think about dynamic watermarks? |
07:35:11 | | Nick elinenbe_ is now known as elinenbe|snooze (trilluser@pcp02254422pcs.wanarb01.mi.comcast.net) |
07:35:36 | Linus | i don't think it is the solution to Alex's problem |
07:35:52 | Linus | my unit doesn't skip |
07:36:00 | Linus | on 320kbit/s songs |
07:36:42 | elinenbe|snooze | but, wouldn't that be a more elegant solution anyway? |
07:37:17 | Linus | yeah, probably |
07:40:48 | Linus | does anybody else experience skipping? |
07:49:01 | | Join MeRWiN [0] (~merwin@63.98.122.204) |
08:00 |
08:09:56 | MeRWiN | hey linus |
08:10:24 | Linus | yo |
08:10:48 | MeRWiN | I tried to get some sort of scroll_sleep function going, but couldn't quite get it |
08:10:55 | Linus | ok |
08:11:08 | MeRWiN | without creating propriatery code inside of lcd.c |
08:11:21 | MeRWiN | ie: linking it to wps.c |
08:11:24 | MeRWiN | and such |
08:11:50 | Linus | why? |
08:12:34 | MeRWiN | well, basically I didn't know how to sleep a particular thread from within wps.c |
08:13:30 | | Join Bagder [0] (~daniel@as3-3-2.ras.s.bonet.se) |
08:13:39 | Bagder | morning |
08:13:40 | MeRWiN | morn |
08:14:27 | MeRWiN | Bagder: what time is it over there? |
08:14:39 | Bagder | 08:12 am |
08:14:49 | MeRWiN | you get up early :) |
08:14:56 | Linus | i was here at 7 |
08:15:05 | MeRWiN | I'm going to have to get up at 8:30am east coast time this morning... it's already 2:15 am |
08:15:18 | Linus | Bagder and I live in the same town |
08:15:19 | MeRWiN | strange strange people :) are both of you at work? |
08:15:25 | * | Bagder nods |
08:15:27 | Linus | yup |
08:15:40 | * | Bagder eats his breakfast sandwich right now |
08:15:42 | MeRWiN | ahh... that explains it. I usually get to work around 9 or 9:30... |
08:15:58 | MeRWiN | unless i'm traveling (80% of the time) at which point i'm at work 24/7 |
08:17:14 | MeRWiN | I've decided that i'm a much better UI person for now... until i learn the code more deeply |
08:18:03 | Bagder | I fsck'ed my disk last night, and yes it had some bad clusters |
08:18:58 | MeRWiN | ouch |
08:19:12 | MeRWiN | Bagder: been shakin' and droppin' your rockbox? |
08:19:24 | Bagder | no |
08:19:31 | Bagder | I don't know why it happened |
08:19:36 | MeRWiN | original hd? |
08:19:40 | Bagder | yeps |
08:19:44 | MeRWiN | bah, return it to archos |
08:23:03 | Linus | MeRWiN: use a boolean in scroll_thread called, for example, scroll_allowed |
08:23:51 | MeRWiN | excuse me? i didn't quite get that |
08:25:18 | Linus | even easier, set scroll_count to 0 to stop scrolling, and set it to 1 to continue |
08:26:10 | MeRWiN | but how does scroll_thread know to set the scroll_count to 0? you need to perform the sleep inside of scroll_thread |
08:27:18 | Linus | add a function, pause_scroll() that sets the count to 0 |
08:27:32 | Linus | and another function, resume_scroll() that sets it to 1 |
08:27:42 | Linus | and call those from wps.c |
08:27:54 | MeRWiN | Linus: how do i tell how much time has passed then? |
08:28:06 | Linus | wps has to know that |
08:28:32 | Linus | that is the easy solution |
08:29:26 | MeRWiN | the only way i see of doing that is using the remaining time in the song, but what if there is only like 1 second left in the song and you want to sleep for 5 seconds |
08:30:53 | Linus | why does the song time has anything to do with the scroll pause? |
08:30:57 | Bagder | we should offer some kind of timeout-functionality |
08:31:08 | Linus | Bagder: i have been thinking of that |
08:31:14 | MeRWiN | how do i tell elapsed time i mean |
08:31:26 | Linus | a soft timer that posts events, and a button_get(timeout) |
08:31:38 | Linus | MeRWiN: current_tick |
08:31:46 | MeRWiN | how long is a tick |
08:32:06 | Linus | a tick is 1/HZ seconds long |
08:32:15 | MeRWiN | so 3 seconds is HZ*3 |
08:32:19 | Linus | today HZ = 100 |
08:32:25 | MeRWiN | that's what i thought HZ meant |
08:32:34 | Linus | thus, a tick is 10ms |
08:33:39 | MeRWiN | ok, so then would I create a thread and have it terminate when it hits the appropriate amount of ticks? |
08:33:47 | Linus | no |
08:34:02 | Bagder | no dynamic threads please ;-) |
08:34:07 | MeRWiN | aww |
08:34:10 | Linus | we can't kill threads |
08:36:10 | Linus | maybe it is time for an timeout_event function? |
08:36:19 | MeRWiN | what is that? |
08:36:43 | Bagder | yes, I think it would be a useful addition |
08:38:34 | Linus | MeRWiN: it would send an event to a queue after an amount of time |
08:38:48 | MeRWiN | ahhh... yes, we need that :) |
08:40:16 | MeRWiN | woo! that simple addition worked... just use lcd_pause_scroll() before calling display_keylock_text() and lcd_resume_scroll() after it |
08:40:19 | MeRWiN | works like a charm :)\ |
08:41:06 | MeRWiN | or rather, i should do it inside of display_keylock_text() |
08:44:17 | Linus | in today's solution, yes |
08:44:35 | Linus | tomorrow, we should use timeout_event |
08:45:09 | Linus | hehe, i have doubled the bitswap speed by putting the code in internal RAM |
08:45:32 | Bagder | nice! |
08:46:05 | MeRWiN | either way, for the display_keylock_text you need to do it this way i think.... it needs to keep the screen clear and not let anything else on the screen update while it's being displayed. that's why the sleep function is inside of the display_keylock_text() function |
08:47:14 | Linus | i think draw_screen should do the screen updates, and output the "keylock ON" message while the timeout hasn't occurred yet |
08:47:33 | MeRWiN | would it even know that the timeout is there? |
08:48:01 | Linus | yes, because you would use a state variable that it can read |
08:48:26 | MeRWiN | hmm.... |
08:48:32 | Linus | like enum display_state(NORMAL, KEYLOCK, ...) |
08:48:47 | Linus | and draw_screen whould check that |
08:49:00 | MeRWiN | and muted? |
08:49:07 | Linus | and whatever |
08:49:41 | MeRWiN | that seems like it would just over-complicate things |
08:49:58 | Linus | really? |
08:50:17 | Linus | the sleep() effectively slows down the responsiveness |
08:50:24 | Linus | it is bad, bad, bad |
08:50:50 | * | Bagder agrees with Linus on this |
08:50:55 | MeRWiN | that is true... it would get rid of the problem with pressing the keylock key 5 times in a row taking 5 seconds to get through |
08:51:00 | Linus | yes |
08:51:24 | MeRWiN | does current_tick ever reset itself? |
08:51:32 | MeRWiN | seems as if that number would grow big very quickly |
08:51:38 | Linus | yes it wraps |
08:51:53 | Linus | there are macros in kernel.h that takes that into account |
08:52:04 | Linus | TIME_BEFORE() and TIME_AFTER() |
08:52:19 | Linus | look in kernel.c and watch how sleep() is implemented |
08:52:46 | MeRWiN | k |
08:53:23 | MeRWiN | what does continue() do? |
08:53:45 | Linus | the continue keyword starts the loop over again |
08:54:26 | *** | Saving seen data "./dancer.seen" |
08:54:44 | Linus | that is, it goes to the top of the loop without executing the rest of the loop body |
08:54:50 | MeRWiN | ahh... |
08:55:00 | Linus | like "next" in Perl |
08:58:09 | MeRWiN | I don't quite understand how you could implement a timeout function that wouldn't interrupt other code |
08:58:22 | MeRWiN | without creating a different thread for it |
08:59:43 | Linus | you mean how to implement timeout_event()? |
08:59:48 | MeRWiN | yeah |
09:00 |
09:00:32 | Linus | i would implement timeout_event by adding a list of timers that are decremented by the tick interrupt |
09:00:56 | Linus | and the tick interrupt code would send an event to the queue that "owns" the timer that has reached 0 |
09:01:06 | Linus | a kernel functionality |
09:01:40 | MeRWiN | ahhh... something just a bit above my head right now. |
09:01:56 | Linus | i can implement that later if you wish |
09:02:09 | MeRWiN | if you can implement it, i can fix code to use it :P\ |
09:02:32 | Linus | good, but it'll have to wait a little. many things to do right now... |
09:02:35 | Bagder | coffee! |
09:02:42 | MeRWiN | conceptually, i've got threading down... actually in practice i'm not so good at it |
09:03:05 | Linus | good, learning by doing is the best practice |
09:04:09 | MeRWiN | I wish I had a laptop that worked right. heh. I'd do it on the plane ride home if I did. |
09:07:28 | MeRWiN | time for sleep |
09:07:39 | | Nick MeRWiN is now known as MeRWiN|Sleep (~merwin@63.98.122.204) |
09:10:24 | Bagder | night MeRWiN |
09:18:13 | Bagder | http://daniel.haxx.se/logo-contest/rockbox3540.png |
09:18:21 | Bagder | this image is broken, isn't it? |
09:18:27 | Bagder | mozilla shows it very oddly |
09:18:32 | PsycoXul | hey can the firmware be able to read from the HD while in usb mode? |
09:19:21 | Linus | PsycoXul: no |
09:19:36 | PsycoXul | oh :/ |
09:19:39 | Linus | Bagder: it is a large "Box" |
09:19:44 | PsycoXul | Bagder: all i can see is a really big "box" in the middle |
09:20:01 | Bagder | yeah :-/ |
09:21:15 | Bagder | convert doesn't manage to create a good png from the tif |
09:22:00 | Bagder | http://daniel.haxx.se/tshirt-contest/ |
09:22:10 | Bagder | anything preventing me from announcing this asap? |
09:24:08 | Linus | Bagder: maybe we should discuss it you and me first |
09:24:18 | Bagder | yes |
09:24:29 | Linus | Bagder: switch to the secure frequency |
09:24:34 | Bagder | hehe |
09:24:38 | Bagder | roger that ;-) |
09:30:35 | * | adi|home wants in on it too |
09:30:37 | adi|home | wahhhhhh |
09:47:11 | MeRWiN|Sleep | Bagder: why can't i access any of those webpages? :p |
09:47:18 | | Nick MeRWiN|Sleep is now known as MeRWiN|SleepWalk (~merwin@63.98.122.204) |
09:47:21 | Bagder | I moved it |
09:47:28 | MeRWiN|SleepWalk | aww |
09:47:35 | Linus | they are not official yet |
09:47:39 | Bagder | Linus and I are discussing it just now |
09:47:50 | MeRWiN|SleepWalk | I don't even know what they are. heh |
09:47:57 | Bagder | hehe |
09:48:11 | MeRWiN|SleepWalk | I've officially given up on sleep |
09:50:29 | * | PsycoXul starts designing :p |
09:50:30 | PsycoXul | mwahahaha |
09:53:11 | Bagder | :-) |
09:56:54 | | Quit MeRWiN|SleepWalk () |
10:00 |
10:20:15 | | Join MeRWiN|SleepWalk [0] (~merwin@63.98.122.204) |
10:20:19 | | Nick MeRWiN|SleepWalk is now known as MeRWiN (~merwin@63.98.122.204) |
10:20:29 | adi|home | anyone around willing to take a look at my resume and offer suggestions? |
10:20:43 | MeRWiN | sure |
10:20:48 | MeRWiN | where can i find it |
10:20:50 | adi|home | k.. what format you want it in? |
10:20:57 | adi|home | i can dcc it to you in a min if you want |
10:21:00 | MeRWiN | ok |
10:21:02 | MeRWiN | in doc format if you please |
10:21:06 | adi|home | np.. |
10:21:06 | MeRWiN | i think dcc will work. |
10:21:17 | Hes | Hmm, are these internal RAM changes speedups? faster than the flash rom? |
10:21:33 | Linus | faster than Dynamic RAM |
10:21:45 | Hes | internal RAM is on the cpu? |
10:21:54 | MeRWiN | Linus: what will this speed up? |
10:22:07 | Linus | double speed disk read and bitswap |
10:22:09 | Hes | way cool. |
10:22:20 | MeRWiN | we need faster disk reading, so this is great |
10:22:21 | Hes | i'm stunned. |
10:22:21 | MeRWiN | definately |
10:22:28 | Linus | i havent benchmarked the thread swutch though |
10:22:45 | Linus | but it should be way faster now |
10:22:58 | Linus | please try it out |
10:23:11 | MeRWiN | when is it going to be in cvs? |
10:23:31 | Linus | it is now |
10:23:43 | Linus | that's how the others found out |
10:23:52 | MeRWiN | how often are things updated on the webpage then? |
10:24:04 | Linus | every X minutes |
10:24:44 | Linus | but some of us have joined the CVS update mailing list |
10:24:54 | MeRWiN | i try clicking on anything in the "batch" column on the daily build page and it shows only a blank page |
10:24:59 | Linus | so we get instant CVS activity reports |
10:25:20 | Hes | Must upgrade by recorder right away. 8-) |
10:25:37 | Bagder | the "batch" column? |
10:25:54 | Bagder | ah |
10:25:55 | MeRWiN | CVS compile status on the daily build page... |
10:25:57 | Linus | MeRWiN: blank? no. i get a CVS history report |
10:26:03 | Linus | what browser? |
10:26:12 | Bagder | they should cvs logs to me |
10:26:12 | MeRWiN | Linus: IE... it was just working 10 minutes ago |
10:26:14 | Bagder | show |
10:26:46 | Linus | it is still working for me |
10:27:39 | MeRWiN | I'm going to reboot... i think my stupid compaq is freakin' |
10:27:42 | | Quit MeRWiN () |
10:35:33 | | Join MeRWiN [0] (~merwin@63.98.122.204) |
10:36:27 | MeRWiN | heh, that looks much better |
10:37:11 | Bagder | goodie |
10:39:19 | Hes | The new build does not seem to boot for me. |
10:39:30 | Hes | The thing boots to the archos firmware. |
10:39:39 | Bagder | uuh |
10:39:58 | MeRWiN | hes: try again |
10:40:02 | MeRWiN | copy it over again |
10:40:21 | Hes | I'm already doing my 3rd try 8-) now building again too. |
10:40:51 | Hes | hessu@funk:/opt/src/archos/src/build$> mount /archos/ |
10:40:51 | Hes | hessu@funk:/opt/src/archos/src/build$> md5sum ajbrec.ajz /archos/ajbrec.ajz |
10:40:51 | Hes | 15e91badcd26c3e281f1236347f23f26 ajbrec.ajz |
10:40:51 | DBUG | Enqueued KICK Hes |
10:40:51 | Hes | 15e91badcd26c3e281f1236347f23f26 /archos/ajbrec.ajz |
10:40:51 | Hes | hessu@funk:/opt/src/archos/src/build$> umount /archos/ |
10:41:18 | Hes | Seems to be ok (i invalidated the cache after the copy by disconnecting and unmounting) |
10:41:43 | MeRWiN | hmm... |
10:41:46 | MeRWiN | mine booted to archos too |
10:41:49 | Hes | Won't bood. |
10:41:51 | Hes | Won't boot. |
10:42:20 | Bagder | I didn't even know it could boot into archos firmware if the file is there |
10:42:27 | MeRWiN | apparently it can :) |
10:42:38 | Hes | It can, i've seen it with a broken firmware before |
10:42:54 | MeRWiN | i'm doing a make clean and remake it |
10:43:03 | Bagder | so how does it know when to run the internal? |
10:43:10 | PsycoXul | Bagder: yeah of course it can.. if it fails to boot the file |
10:43:25 | Bagder | yes, but the scramble and things should be fine here |
10:43:41 | MeRWiN | hehe.. the archos.mod file is 318k :) |
10:43:46 | PsycoXul | Bagder: when the file is no good, or over ~200K according to my tests on my player, it boots the internal rom |
10:43:52 | | Part Bagder |
10:44:03 | | Join Bagder [0] (~daniel@as3-3-2.ras.s.bonet.se) |
10:44:10 | MeRWiN | Bagder: my archos.mod is 318k |
10:44:18 | MeRWiN | whoops |
10:44:19 | Bagder | gosh |
10:44:34 | Hes | -rw-rw-r−− 1 hessu hessu 364470 Aug 1 11:38 ajbrec.ajz |
10:44:41 | Bagder | yeah, too big that's why |
10:44:41 | Hes | whoa! |
10:44:44 | Bagder | it isn't loaded |
10:44:53 | Bagder | Linus changed the link control file |
10:45:02 | MeRWiN | I think it needs to be re-looked at :) |
10:45:05 | Linus | maybe i broke something really bad |
10:45:16 | Hes | Linus: yours booted? |
10:45:17 | Bagder | amen |
10:45:19 | Bagder | :-) |
10:48:01 | MeRWiN | well this is problematic with such a nice feature added |
10:48:27 | adi|home | which feature was added? |
10:48:28 | MeRWiN | This is as bad as microsoft... add one optimization and the code size multiplies by 10 :) |
10:49:10 | MeRWiN | adi|work: go to the home rockbox page |
10:49:28 | MeRWiN | adi|home: check out the cvs updates |
10:49:48 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
10:49:48 | * | adi|home is lazy :) |
10:50:00 | MeRWiN | adi|home: things were moved into internal RAM |
10:50:07 | MeRWiN | speeds up stuff about 100% |
10:50:11 | MeRWiN | some stuff |
10:52:13 | adi|home | got ya |
10:52:39 | adi|home | what exactly is that doing? |
10:52:46 | * | adi|home isnt a hard wear guy too much |
10:52:50 | MeRWiN | got me :) |
10:53:00 | MeRWiN | i just know that it's faster |
10:53:01 | Bagder | executes code in a different ram location |
10:53:03 | adi|home | lol |
10:53:05 | Bagder | faster ram |
10:53:30 | adi|home | Bagder: could you give a "laymens, adi is a dumb post" kinda explaination of how we got there? |
10:53:57 | Bagder | we have "internal" and "external" ram on the CPU |
10:54:11 | Bagder | we can have code in both |
10:54:20 | Bagder | executing code in the internal ram is faster |
10:54:25 | adi|home | okay... |
10:54:27 | *** | Saving seen data "./dancer.seen" |
10:54:34 | Bagder | up until now, we only used the external one |
10:54:39 | adi|home | is there any similarity for this to a desktop pc? |
10:54:46 | Bagder | not really |
10:54:48 | * | adi|home tries to draw a mental map |
10:54:51 | adi|home | nods |
10:55:09 | adi|home | okay, so internal and external ram |
10:55:16 | Bagder | it's like if you insert two different SIMMs in a PC, one is fast and one is slow |
10:55:23 | * | adi|home nods |
10:55:27 | adi|home | that makes sense.. |
10:55:39 | Bagder | the external one is of course much bigger than the internal |
10:55:43 | adi|home | nods |
10:55:57 | adi|home | since its bigger, bigger address space, slower look ups? |
10:56:04 | adi|home | or is there another reason its slower? |
10:56:32 | Linus | dynamic ram is slow |
10:57:41 | * | adi|home avoids driving you nuts like he did to his science teachers, always asking 'why?; |
10:57:55 | adi|home | okay.. so when we boot, we load from ext ram to int ram |
10:58:01 | adi|home | how exactly is that done? |
10:58:10 | adi|home | do we write to a specifc location in the int ram? |
10:58:22 | adi|home | and the processor just knows to pull from there if there is data? |
10:58:36 | Bagder | the different rams are on different addresses |
10:59:15 | adi|home | so you just reference the correct address when you go to write.. got ya.. |
10:59:26 | Bagder | correct |
10:59:30 | MeRWiN | so do we know what is wrong with the current code? |
10:59:48 | | Join yro [0] (~yves@ns1.alcove-solutions.com) |
10:59:53 | yro | Hi there |
10:59:56 | Bagder | hey yro |
11:00 |
11:00:06 | adi|home | okay.. one last question on this... |
11:00:11 | Bagder | hehe |
11:00:19 | Linus | i just committed a correction to the linker scripts |
11:00:23 | adi|home | how are we deciding what does and does not go into the ram? |
11:00:45 | Bagder | adi|home: the internal ram is *very* small, we can only have a few selected and important functions there |
11:00:50 | Linus | adi|home: you set an attribute to the function, telling which section it should go to |
11:01:10 | Linus | look at thread.c for example |
11:01:32 | MeRWiN | Linus: so a CVS update should fix it? |
11:01:41 | Bagder | it does, I just tried |
11:01:42 | adi|home | k... |
11:01:59 | * | adi|home hasn't updated his cvs version in like 2 months |
11:02:00 | * | adi|home smirks |
11:02:11 | MeRWiN | mine is still 318686 |
11:02:38 | Bagder | Linus: did you fix the player version too? |
11:07:52 | | Join notch [0] (hidden-use@212.250.215.13) |
11:09:12 | Linus | fixed |
11:09:30 | MeRWiN | thanks :) worked |
11:09:35 | MeRWiN | or at least it's the correct size now |
11:10:39 | Linus | The internal RAM is 4Kbytes |
11:11:02 | Linus | and i have second thoughts about putting the LCD frame buffer in iram |
11:11:26 | Linus | putting data in iram does not give that much impact |
11:11:41 | Linus | code is better |
11:11:47 | MeRWiN | it seems as if the disk spins down very quickly |
11:12:15 | Bagder | Linus: so maybe lcd_update() should go there instead |
11:12:19 | Linus | yes |
11:12:53 | MeRWiN | Linus: is there any way to keep the disk spinning for say like... 3 seconds? (or at least when you're switching tracks) |
11:12:59 | MeRWiN | just curious |
11:13:32 | Linus | MeRWiN: the disk spin down timeout is 5 secs |
11:13:39 | Linus | or at least, should be |
11:14:14 | Linus | but not when playing music |
11:14:33 | MeRWiN | is there a way to set it to 5 second spindown when switching tracks? |
11:14:35 | Linus | the mpeg loader spins down the disk as soon as the track has loaded |
11:15:00 | Linus | MeRWiN: of course there is a way |
11:15:07 | MeRWiN | I think that may be part of the problem with not being able to change tracks correctly immediately after loading a track |
11:15:07 | Linus | this is software |
11:15:59 | Linus | the disk spindown is not the track switch problem |
11:16:23 | Linus | it is the MPEG_NEED_DATA and MPEG_SWAP_DATA event queue |
11:16:27 | MeRWiN | would leaving the disk spinned up for a couple seconds speed up immediate track changes though? |
11:16:30 | Hes | WHOA |
11:16:53 | Hes | the speed increase is really noticeable, I didn't expect it to matter _this_ much |
11:17:12 | Hes | very much faster while browsing directories & starting playback |
11:17:25 | Linus | MeRWiN: all disk accesses would of course be faster if the disk didn't spin down |
11:17:27 | Bagder | will we see a noticable increased battery life time? |
11:17:31 | Linus | yes |
11:17:35 | Linus | i think so |
11:17:57 | MeRWiN | Linus: where would I go to change the spindown time on track changes? |
11:18:22 | Linus | there is no such thing in the code that takes care of track chenges |
11:18:37 | MeRWiN | or rather, spindown time when playing |
11:18:44 | Linus | you can remove the ata_spindown call in mpeg.c |
11:18:50 | MeRWiN | k |
11:19:16 | Linus | then it will always wait 5 secs before it spins down |
11:19:28 | Bagder | isn't that spindown causing problems if another thread is using the disk while it is called? |
11:19:55 | MeRWiN | there is no ata_spindown in mpeg.c |
11:20:04 | MeRWiN | there's an ata_sleep though |
11:20:10 | Linus | same thing |
11:20:12 | MeRWiN | k |
11:20:27 | Linus | Bagder: no, the mutex takes care of thet |
11:21:00 | Bagder | Linus: yes, but it will make the other thread perform worse, right? |
11:21:24 | Bagder | and require an extra spinup |
11:21:41 | Linus | Bagder: of course |
11:22:02 | Linus | do you have a better idea? |
11:22:26 | MeRWiN | Linus: removing the ata_sleep speeds up an immediate track change about 200%... probably uses a bit more battery though |
11:22:54 | Bagder | Linus: well, it would be if it would somehow be able to detect that the other thread uses the disk |
11:22:57 | MeRWiN | Linus: and also fixes the playlist immediate trackchange problem!!! |
11:24:31 | MeRWiN | it could be compensated for somewhat by changing the spindown time to 3 seconds from 5... seems as if that may be sufficient |
11:25:25 | Bagder | Linus: wouldn't it be possible to instead of doing ata_sleep(), just set a timeout on like 0.5 seconds, so that if another thread is using the disk within that time, it won't spindown? |
11:26:19 | Linus | you mean that mpeg.c only would alter the timeout instead of calling ata_sleep() |
11:26:26 | Bagder | yes |
11:26:31 | Linus | hmmm |
11:26:36 | MeRWiN | the timeout would have to be set back though... |
11:26:53 | Bagder | yes, but I guess that anything that uses the disk will do that |
11:27:34 | MeRWiN | the ata_sleep() seems to be a problem in any case |
11:28:14 | Linus | i just did the coolest thing |
11:28:31 | MeRWiN | what would that be |
11:28:31 | Bagder | you streaked across your work office? :-P |
11:28:34 | MeRWiN | haha |
11:28:58 | Linus | instead of telling the disk to go to sleep, i just shut off the power to it |
11:29:15 | Linus | and it works |
11:29:25 | Linus | what a battery saver! |
11:29:30 | notch | hehe |
11:29:34 | MeRWiN | hmm... would that hurt it at all? |
11:29:39 | Linus | i guess not |
11:30:06 | Linus | except that it works only on the recorder |
11:30:09 | MeRWiN | ahh |
11:30:50 | notch | I think it's safter to shut of the power only when you know you are not reading writing to the disk... |
11:32:20 | notch | but I'm guessing that's the case? |
11:32:20 | Linus | notch: of course |
11:32:41 | Linus | the sleep is done only when nobody is accessing the disk |
11:32:57 | Linus | even before my power down change |
11:33:05 | Linus | it is essential |
11:33:27 | MeRWiN | how much battery drain would increase by getting rid of the ata_sleep in mpeg.c? |
11:33:41 | Linus | but i don't think the power down will increase the battery life that much |
11:34:07 | MeRWiN | Linus: it's nice to be able to change the song within 5 seconds of starting it and not have to spin up the drive |
11:34:10 | MeRWiN | :) |
11:35:10 | Linus | how about this: |
11:35:37 | Linus | directory reads sets the timeout to 5 secs, and file reads set it to 0.5 sec |
11:35:49 | MeRWiN | Linus: make it 2 and you've got a deal :) |
11:35:50 | MeRWiN | heh |
11:36:16 | Linus | i smell config options... |
11:36:23 | adi|home | no.. |
11:36:24 | adi|home | thats just me |
11:36:26 | MeRWiN | AHH!! I'll write that one :) |
11:36:28 | adi|home | i haven't showered yet |
11:36:38 | * | Bagder chuckles |
11:36:42 | | Join ripnetuk [0] (~george@ripnet.fsnet.co.uk) |
11:36:54 | MeRWiN | Linus: config options i can do. heh. create a new global variable? |
11:36:57 | Hes | http://www.asmparty.net/cam/webcam.jpg ... asm '02 is opening |
11:37:04 | Bagder | Linus: 5 / 0.5 is fine to run as a test to start with |
11:37:07 | Linus | that would make two hard disk sleep timers |
11:37:26 | MeRWiN | oh my god... a stadium full of geeks |
11:37:30 | Linus | we need to think about this |
11:37:37 | notch | Hes: What was the link? |
11:37:46 | Bagder | Linus: it could be one timer still, only raised to 5 or 0.5 by different functions |
11:37:51 | Hes | notch: ? |
11:37:58 | Linus | maybe we don't want playlist file reads to timeout that quickly? |
11:38:12 | Linus | Bagder: i was talking about the config options |
11:38:12 | Bagder | Linus: why not? |
11:38:16 | Bagder | ah |
11:38:25 | Bagder | I don't think we need them as config options yet |
11:38:40 | Linus | starting to play a playlist would require two spindowns |
11:38:46 | Bagder | why? |
11:38:57 | MeRWiN | Bagder: config would be good... you either get longer battery life, or quicker track changes |
11:39:23 | Linus | read playlist (0.5s timeout)...parse it...scramble it...start playing first somg |
11:39:43 | Linus | the disk will spin down before the first song starts playing |
11:39:45 | Bagder | Linus: hm, yes I guess you're right, for big playlists it'll take longer than 0.5 |
11:39:54 | MeRWiN | will it be less than 1 second still? |
11:40:02 | Bagder | but then, the playlist code could deliberately prolong the time-out |
11:40:07 | Linus | about 1 sec per 1000 tracks |
11:40:16 | MeRWiN | Bagder: that's true |
11:40:20 | Bagder | Linus: the load time, yes |
11:40:21 | notch | Hes: Guess I'm not a geek! :-) |
11:40:28 | MeRWiN | Bagder: delay it to a few seconds |
11:40:57 | Bagder | Linus: the post-load code will not take 1 sec per 1000 tracks |
11:41:10 | Bagder | it is only a fraction of a second on my 3200 song playlist |
11:41:12 | Hes | notch: You should be seeing over 3000 nerds in that webcam in a single shot tomorrow evening 8-) |
11:41:12 | Linus | meybe not |
11:41:26 | Hes | and over the weekend... slightly less today. |
11:42:19 | Linus | according to Fujitsu, the power requirements say 2.3W for an active drive and 0.1W for a sleeping drive |
11:42:41 | Linus | so shutting it off completely would probably not make that much of a difference |
11:43:02 | MeRWiN | so leaving the drive active for a couple seconds won't make too much of a power drain? |
11:43:33 | Linus | MeRWiN: leaving it active makes a difference |
11:43:36 | notch | That's 25mA ! |
11:43:58 | notch | 0.1W that is |
11:44:01 | MeRWiN | Linus: would the config option be a global var? |
11:44:20 | Linus | i will let my recorder play until it drops and see how much longer the battery life is |
11:44:32 | Linus | MeRWiN: a global_option |
11:44:48 | | Nick notch is now known as notch|learningto (hidden-use@212.250.215.13) |
11:44:58 | Linus | global_settings.spindown |
11:45:02 | Linus | or something |
11:45:11 | MeRWiN | yeah |
11:45:25 | Linus | but we need to work out the technical details first |
11:45:29 | MeRWiN | yeah... |
11:46:46 | MeRWiN | doesn't hurt to create the menu though :) |
11:48:13 | Linus | no, i guess not |
11:50:40 | Linus | the CPU takes about 60-90 mA when running |
11:52:11 | MeRWiN | There, there's a menu for it now... |
11:52:58 | MeRWiN | Linus: where is the 5 second spindown actually set? |
11:55:25 | Linus | ata.c |
11:55:30 | Linus | sleep_timeout |
11:57:40 | MeRWiN | what would be the "legal" way to set sleep_timeout to global_settings.spindown |
11:57:42 | MeRWiN | ? |
11:57:51 | Linus | no |
11:58:16 | Linus | it should be done in the same way as the scroll_timer |
11:58:22 | Linus | and the backlight timer |
11:58:25 | MeRWiN | ? |
11:59:33 | Linus | i thought you would look at the code when i wrote that |
12:00 |
12:00:03 | Linus | i mean that the load_settings() calls the set_xxx_timer() functions when it loads the settings |
12:03:11 | MeRWiN | ahh |
12:14:00 | | Quit notch|learningto (Read error: 104 (Connection reset by peer)) |
12:14:23 | MeRWiN | got the config item working... it sets the default GLOBAL spindown time :) setting it to 1 second actually seems to function properly |
12:14:34 | MeRWiN | unless you hit something like a playlist and try to change immediately |
12:14:52 | MeRWiN | I personally like 3 seconds |
12:21:21 | Bagder | time to get food |
12:28:38 | Linus | I made some measurements regarding the power usage |
12:29:04 | Linus | with ATA_SLEEP: 200mA |
12:29:14 | Linus | with ATA poweroff: 75mA |
12:29:20 | Linus | whabang! |
12:29:41 | MeRWiN | wow |
12:29:43 | MeRWiN | nice power change |
12:29:58 | Linus | and it's about 500mA when reading from disk |
12:30:10 | Linus | and about 7-800 when spinning up |
12:30:50 | MeRWiN | in some cases, leaving it spinned up is better than spinning it up every 3 seconds? |
12:31:17 | Linus | and 250 when the disk is spinning and idle |
12:32:28 | Linus | from this, i can see that our SLEEP doesn't work as expected |
12:32:44 | MeRWiN | nah |
12:32:49 | Linus | it draws too much current when sleeping |
12:33:07 | Linus | the sleep should take about 50mA |
12:33:33 | Linus | and the CPU about 70 |
12:33:50 | MeRWiN | hmm |
12:34:52 | MeRWiN | any clue why? |
12:35:08 | MeRWiN | how can sleep take less than poweroff? |
12:35:20 | Linus | it doesn't |
12:35:32 | MeRWiN | you said that sleep is supposed to be 50mA and poweroff is 75mA |
12:35:47 | Linus | i was talking about the HD itsels, sorry |
12:35:52 | Linus | itself |
12:35:52 | MeRWiN | ah |
12:36:03 | Linus | HD+CPU+memory+LCD....it all adds up |
12:36:23 | MeRWiN | yeah |
12:36:24 | Linus | Uwe measured the Archos firmware power consumtion |
12:36:45 | Linus | they use 95mA when idle |
12:37:09 | MeRWiN | yeah, definately too much for ours |
12:38:11 | Linus | that must mean that they use the SLEEP function for the HD |
12:38:28 | Linus | and that they put the CPU to sleep |
12:39:03 | MeRWiN | hmm... why would you put the cpu to sleep |
12:39:12 | Linus | to save power of course |
12:39:25 | Linus | you save 20mA |
12:39:44 | Linus | not really. |
12:39:49 | Linus | those numbers are for 5V |
12:40:04 | MeRWiN | aren't we 5v? |
12:40:36 | Linus | 3V |
12:40:58 | MeRWiN | oh |
12:41:09 | MeRWiN | so it would be more like saving 12mA? |
12:41:21 | Linus | i guess |
12:41:54 | Linus | i wonder why our ata sleep takes so much power... |
12:42:18 | MeRWiN | dunno, but it's a great power drain though. Probably reduces overall life by about an hour |
12:43:34 | Linus | but maybe the drive wears out faster because of all the power cycling? |
12:43:52 | MeRWiN | hmm. |
12:45:27 | MeRWiN | i'm working on a quick track skipping method right now (holding down the next track button to cycle through tracks) |
12:45:47 | Linus | don't do that |
12:45:57 | MeRWiN | why? |
12:46:13 | Linus | we want to use those keys for fast wind/rewind |
12:46:17 | Hes | It's needed for seeking inside a file |
12:46:35 | MeRWiN | ah... |
12:46:42 | MeRWiN | well, i'll trash that code then :) |
12:50:26 | MeRWiN | in any case, I've got that HD spindown code done.... |
12:51:26 | Linus | i tried using ATA_STANDBY instead, and i got less power consumption than ATA_SLEEP... |
12:51:41 | Linus | weird indeed! |
12:51:44 | Bagder | weird |
12:51:53 | MeRWiN | how much less? |
12:53:57 | Linus | 200mA with sleep |
12:54:02 | Linus | 125 with standby |
12:54:10 | Bagder | woo |
12:54:30 | *** | Saving seen data "./dancer.seen" |
12:54:31 | Linus | we must do something wrong when using SLEEP |
12:56:10 | Linus | lunch time |
12:56:25 | | Nick Linus is now known as Linus|lunch (~linus@193.15.23.131) |
13:00 |
13:01:11 | | Nick yro is now known as yro|lunch (~yves@ns1.alcove-solutions.com) |
13:04:08 | MeRWiN | how do i use patch? |
13:04:17 | MeRWiN | to redo a diff that I made |
13:04:28 | MeRWiN | err.. implement a diff that i made |
13:04:35 | Bagder | patch < file |
13:05:19 | MeRWiN | thanks |
13:23:50 | | Quit MeRWiN (Read error: 110 (Connection timed out)) |
13:25:06 | | Nick Linus|lunch is now known as Linus (~linus@193.15.23.131) |
13:36:59 | | Part Bagder |
13:37:09 | | Join Bagder [0] (~daniel@as3-3-2.ras.s.bonet.se) |
13:37:29 | Mode | "#rockbox +o Bagder " by ChanServ (ChanServ@services.) |
13:44:26 | | Nick yro|lunch is now known as yro (~yves@ns1.alcove-solutions.com) |
13:57:43 | | Join Mighty [0] (mboss@h76n2fls35o931.telia.com) |
14:00 |
14:05:05 | Hes | The deep discharge mode of the charger seems to work too. |
14:05:15 | Linus | deep discharge? |
14:05:49 | Hes | the charger patch has a toggle to change the max charge level to start charging |
14:05:54 | Hes | between 10% and 90% |
14:06:09 | Hes | in 'deep discharge' mode it only starts charging when the charge has gone down to 10%. |
14:07:07 | Linus | aha |
14:07:29 | Linus | is the battery charging code cleanly separated from the graph code? |
14:10:49 | Hes | Yes, quite well |
14:11:18 | Hes | can easily remove/disable the graph/debug stuff |
14:11:32 | Hes | there are some global variables used instead of functions to set them |
14:11:45 | Hes | which could be cleaned up if that's the preferred way |
14:12:06 | | Quit fragglet (lerouge.openprojects.net irc.openprojects.net) |
14:12:06 | NSplit | lerouge.openprojects.net irc.openprojects.net |
14:12:42 | Linus | i have no problems with global variables, quite the opposite |
14:14:47 | | Quit Mighty ("BitchX: its wax ecstatic") |
14:16:24 | NHeal | lerouge.openprojects.net irc.openprojects.net |
14:16:24 | NJoin | fragglet [0] (~fraggle@pc1-guil4-0-cust151.gfd.cable.ntl.com) |
14:17:41 | Bagder | so linus, any thoughts on 1.2? |
14:18:30 | Hes | I've seen the approach of set_foo_bar() being exported from the firmware side, and the function actually just sets a local variable in the firmware |
14:18:40 | Hes | sounds like a waste of time for most cases |
14:19:15 | Bagder | yes, but sometimes it is handy to begin with if we haven't quite thought out all details |
14:20:02 | Bagder | but for a single global, I agree that it makes little sense |
14:26:12 | | Quit fragglet (lerouge.openprojects.net irc.openprojects.net) |
14:26:29 | NJoin | fragglet [0] (~fraggle@pc1-guil4-0-cust151.gfd.cable.ntl.com) |
14:26:44 | Linus | Bagder: i still haven't worked out the distortion issue |
14:31:47 | Bagder | a "Hold function" is the key lock we already have, isn't it? |
14:31:57 | * | Bagder reads feature-requests |
14:32:39 | Linus | Yes |
14:34:04 | | Join jedix [0] (~liam@fwott1-1.cis.ec.gc.ca) |
14:36:35 | Linus | Bagder: i have already browsed all the feature requests |
14:36:53 | Linus | but i decided not to close them until they are implemented in an official release |
14:38:18 | Bagder | I don't think that very good, as people will use the feature-request list as items to implement as long as they're open and uncommented |
14:38:41 | Linus | maybe you are right... |
14:39:09 | Bagder | I also find it very odd that only 3 people can get a feature request assigned to them |
14:39:25 | Bagder | and the categories and groups stink |
14:39:42 | Bagder | I know, that's Björn's area |
14:40:04 | Linus | it also stinks that we can't remove groups and categories |
14:40:17 | Bagder | yes |
14:41:11 | | Quit fragglet (lerouge.openprojects.net irc.openprojects.net) |
14:41:11 | NSplit | lerouge.openprojects.net irc.openprojects.net |
14:41:24 | NHeal | lerouge.openprojects.net irc.openprojects.net |
14:41:24 | NJoin | fragglet [0] (~fraggle@pc1-guil4-0-cust151.gfd.cable.ntl.com) |
14:42:06 | Bagder | gosh |
14:42:12 | Bagder | I could add people ;-) |
14:45:09 | | Quit fragglet (lerouge.openprojects.net irc.openprojects.net) |
14:45:09 | NSplit | lerouge.openprojects.net irc.openprojects.net |
14:45:38 | NHeal | lerouge.openprojects.net irc.openprojects.net |
14:45:38 | NJoin | fragglet [0] (~fraggle@pc1-guil4-0-cust151.gfd.cable.ntl.com) |
14:54:31 | *** | Saving seen data "./dancer.seen" |
14:57:53 | Hes | Btw... the idle poweroff timer would be nice to have |
14:58:10 | Hes | I've accidentally powered it on a few times and then it has discharged in the bag.... um... pouch. |
14:58:28 | Linus | Hes: care to implement it? |
14:58:32 | Hes | It'd be good for charging too (can the device be powered off while connected to a supply?) |
14:58:51 | Linus | you can shut off the hard drive |
14:59:15 | Hes | if the device is not being used, it should be turned as off as possible when the battery is fully charged |
14:59:22 | Linus | and yes, you can shut off the unit, but it will restart again, to the archos charger |
14:59:35 | Hes | Doh. |
14:59:42 | Hes | So we just sleep as well as we can, right? |
15:00 |
15:00:01 | Linus | lcd_update in DRAM: 36ms |
15:00:12 | Linus | lcd_update in IRAM: 20ms |
15:00:24 | Bagder | neat |
15:00:35 | Linus | i was thinking about memset() |
15:00:39 | Linus | amd memcpy() |
15:00:44 | Bagder | ah, good idea |
15:00:48 | Linus | more candidates? |
15:00:53 | Hes | Very neat. It feels and looks much faster now. |
15:01:19 | Hes | Screen drawing routines? |
15:01:24 | Linus | yeah |
15:01:51 | Bagder | yeay, lcd_bitmap() is a candidate |
15:02:49 | Hes | Argh, i'm going to the machine room to fix a switch. |
15:03:02 | Hes | The bandwidth limiter for asm02 just melt down. |
15:13:29 | Bagder | so maybe we can get the charger code comitted too before 1.2 is released |
15:13:39 | Linus | yeah |
15:13:58 | Linus | I'd like to test it though |
15:14:09 | Bagder | yeah, me too |
15:14:10 | Linus | but i want his lates patch |
15:14:38 | Linus | the rockbox really flies with the IRAM patch |
15:14:41 | elinenbe|snooze | hoe large is the internal ram? |
15:14:45 | Bagder | but it feels so unproductive having to mail around patches instead of simply comitting and sit on the bleeding edge instead |
15:14:46 | Linus | 4Kbytes |
15:14:53 | | Nick elinenbe|snooze is now known as elinenbe|wake (trilluser@pcp02254422pcs.wanarb01.mi.comcast.net) |
15:15:14 | * | Bagder wants to fly too |
15:15:22 | Linus | Bagder: you are right, but killing batteries is nothing to be taken lightly |
15:15:33 | Bagder | I guess not |
15:15:52 | elinenbe|wake | Badger: agreed. too many patches on the email list −− they should be in the CVS |
15:15:56 | Linus | i would like to enable the disk saving of settings too |
15:16:27 | Linus | Zagor is away, let's dance on the table and merge those suckers |
15:16:34 | Linus | :-) |
15:16:39 | Bagder | hehe |
15:17:07 | Linus | We should merge the charger patch first, because the disk save depends on the battery status filter |
15:17:33 | elinenbe|wake | has anyone tried the "ipod UI" patch that was posted to the list? |
15:17:40 | Linus | what? |
15:18:01 | Bagder | "[PATCH] progressbar and slidebar" ? |
15:18:24 | elinenbe|wake | yeah, that is the one. |
15:18:31 | Bagder | I'm about to apply |
15:18:34 | elinenbe|wake | I am checking that out right now. |
15:18:35 | mbr_ | This is a patch from me. Hope the code is not too bad :) |
15:18:50 | Bagder | looks fine |
15:19:16 | mbr_ | BTW. Is someone working on the remote? |
15:19:23 | Bagder | no |
15:19:31 | Bagder | you go ahead ;-) |
15:19:34 | Linus | Yes, i can't remember who it is, though |
15:19:39 | Bagder | oh |
15:19:49 | Linus | check the irc logs |
15:19:57 | mbr_ | OK .... |
15:20:06 | mbr_ | nothc? |
15:20:09 | mbr_ | notch? |
15:20:21 | elinenbe|wake | anyone, how do you apply a diff? |
15:20:30 | | Nick elinenbe|wake is now known as elinenbe (trilluser@pcp02254422pcs.wanarb01.mi.comcast.net) |
15:20:40 | Bagder | patch < file |
15:20:48 | Bagder | or sometimes patch -p0 < file |
15:20:59 | Bagder | like in mbr's patch |
15:23:54 | Bagder | mbr_: you happen to have a screen dump of your progress bar running? |
15:24:14 | mbr_ | No, sadly not. |
15:24:19 | Bagder | ok |
15:26:00 | mbr_ | I make on in simulator. One moment please ... |
15:29:08 | mbr_ | Badger: http://www.stz-softwaretechnik.de/~mb/slide.png and http://www.stz-softwaretechnik.de/~mb/progress.png |
15:29:17 | mbr_ | This is my test screen |
15:29:19 | Hes | I'm pretty sure the charger can't kill batteries. It might not charge them to the absolute max, which could reduce their capacity, but just a little. |
15:29:56 | Bagder | they look great! |
15:29:56 | Linus | mbr_: looks cool! |
15:30:17 | Bagder | I'll commit |
15:30:40 | mbr_ | cool, my first code in rockbox :) |
15:31:58 | Bagder | congrats! |
15:32:03 | Bagder | and thanks |
15:32:33 | mbr_ | np, thats what oen source is for |
15:32:39 | mbr_ | open source |
15:32:45 | elinenbe | I think it looks great too. |
15:33:00 | elinenbe | now we just need a slider like that for the volume,bass,etc... |
15:33:02 | Bagder | its now in CVS |
15:34:00 | Linus | Bagder: don't forget credits.c |
15:34:05 | Bagder | ah |
15:34:17 | Bagder | we should automate |
15:34:22 | Linus | maybe a script? |
15:35:54 | Bagder | yes, "one day" ;-) |
15:36:00 | elinenbe | I think that widgets like mbr_'s are wonderful. Our entire UI should be full of widgets. Sliders, tabs, etc... |
15:36:56 | Bagder | yes, it makes it more good-looking |
15:37:07 | Bagder | and look *is* important |
15:38:15 | elinenbe | I couldn't agree more. |
15:38:19 | | Join mistaRx [0] (mistaX@t1o975p93.telia.com) |
15:39:29 | mistaRx | hello?! |
15:39:52 | Bagder | hey ho |
15:40:37 | mistaRx | it was u who gave me a "#define Save_To_disk" mo, right?! |
15:40:38 | Linus | yo |
15:40:44 | Linus | i did |
15:40:50 | Linus | i think |
15:41:10 | Bagder | does it matter who? |
15:41:31 | mistaRx | ok, it doesn't work, can't u do a new one with the newest build, pleez..?! |
15:41:37 | Linus | hang on... |
15:41:57 | Linus | old LCD, right? |
15:42:08 | mistaRx | right |
15:42:54 | | Quit yro ("ircII EPIC4-1.1.5 -- Are we there yet?") |
15:43:24 | Linus | http://linus.haxx.se/archos.mod |
15:43:38 | mistaRx | loading... |
15:43:53 | Bagder | woo, linus.haxx.se! ;-) |
15:44:15 | Bagder | "Hejsan alla barn" |
15:44:20 | * | Bagder laughs |
15:45:05 | mistaRx | thanks |
15:49:55 | mistaRx | WEHEEJ!! it's working |
15:51:35 | mistaRx | do u know if it afects the battery life?! |
15:52:26 | Linus | only very, very slightly |
15:52:49 | Linus | since it only writes to disk when you change anything via the settings menu |
15:53:01 | elinenbe | pictures of latest firmware in action (with slider) elinenbe/archos/temp/2.jpg">http://www-personal.umich.edu/~elinenbe/archos/temp/2.jpg |
15:53:04 | elinenbe | elinenbe/archos/temp/3.jpg">http://www-personal.umich.edu/~elinenbe/archos/temp/3.jpg |
15:53:05 | mistaRx | ok, was just going to ask that.. |
15:53:24 | elinenbe | elinenbe/archos/temp/1.jpg">http://www-personal.umich.edu/~elinenbe/archos/temp/1.jpg |
15:53:44 | elinenbe | the pictures were taken with a $5 digital camera so beware! |
15:55:20 | Bagder | hehe, yeah the quality of the pics ain't top notch but I get the point ;-) |
15:55:54 | mistaRx | well gotta go, bye bye |
15:56:00 | Linus | bye |
15:56:05 | | Quit mistaRx () |
15:56:59 | Linus | i'm running the slider patch now. looks great! |
15:59:12 | elinenbe | what used to be on that line? |
15:59:23 | Bagder | nothing |
15:59:26 | Linus | nothing, i think |
15:59:30 | Bagder | just the battery line below it |
15:59:36 | mbr_ | There was nothing before |
16:00 |
16:00:13 | Linus | mbr_: since you are at it, would you like to do a status bar? |
16:00:26 | mbr_ | Status bar? |
16:00:29 | Linus | containing battery status, play status, volume and so on |
16:00:36 | mbr_ | with battery and so on? |
16:00:49 | Linus | that one would be dislayed in almost every screen |
16:01:00 | Linus | just do the status_draw() function |
16:01:08 | Bagder | see upcoming mail from me |
16:01:09 | Linus | status.c |
16:01:13 | Linus | apps/status.c |
16:01:22 | mbr_ | Can do it, but i am not a gui design guru |
16:01:32 | Bagder | now you are ;-) |
16:01:33 | Linus | ok |
16:01:55 | mbr_ | I'll look into it this evening |
16:02:13 | Linus | no pressure |
16:02:31 | mbr_ | OK. |
16:03:13 | Linus | gotta go. cu guys! |
16:03:24 | | Part Linus |
16:03:41 | mbr_ | I have to go too, bye! |
16:03:46 | Bagder | see ya |
16:06:56 | | Join sam___ [0] (nio@80.9.49.206) |
16:07:15 | sam___ | Hi |
16:07:21 | Bagder | hey |
16:11:46 | sam___ | Got a question , read yahoo groups mailing archive but only find few answer, i'm going to by a pda and want to know if there is a way to use my archos jukebox as mass storage ? |
16:12:55 | sam___ | I prefer palmos but i was thinking that if somebody port an usb driver will be more easy on windows ce |
16:13:09 | Bagder | if the PDA can act as a USB master, then yes |
16:14:30 | sam___ | hum , ok found this on msdn http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceddk40/htm/cxconSampleUSBMassStorageClassDriver.asp so seems to be possible |
16:15:36 | Bagder | yes, it indicates that windows CE can run as a USB master |
16:15:45 | Bagder | it doesn't necessarily mean that all PDAs running it can |
16:16:17 | | Nick dwihno|gone is now known as dwihn0r (dwihno@193.180.246.67) |
16:16:22 | dwihn0r | Has anyone seen edx lately? |
16:16:36 | Bagder | he popped in quickly the other day and vanished again |
16:16:54 | dwihn0r | has he gone for a trip or something? |
16:17:24 | Bagder | I don't know |
16:18:50 | | Quit sam___ () |
16:23:33 | dwihn0r | :-) |
16:23:39 | * | dwihn0r hands Bagder some coffee |
16:23:57 | dwihn0r | I need to get the win32.mak files so I can compile rockbox on my new development (kickass) box :) |
16:24:16 | dwihn0r | I see you merged the patch with the progress bar. Is it neato? |
16:24:33 | Bagder | it is n-e-a-t-o ;-) |
16:24:42 | dwihn0r | :-D |
16:24:55 | * | dwihn0r went to Ö.B and bought cheap noodles |
16:25:01 | dwihn0r | and cheap godis |
16:27:47 | Hes | Excellent, now we have a GUi design guru 8-) |
16:28:04 | Bagder | heheh, exactly |
16:32:23 | dwihn0r | anyone with a build I can test? I'd love to see :) |
16:32:56 | Bagder | hang on |
16:33:30 | dwihn0r | yay :) |
16:33:31 | Bagder | http://storebror.haxx.se/archos/ |
16:34:13 | Bagder | it is also much faster now |
16:34:49 | dwihn0r | it is? |
16:34:57 | Bagder | yes |
16:34:58 | dwihn0r | many tweaks? |
16:35:16 | Bagder | lots of important functions now run in the faster internal ram |
16:37:01 | dwihn0r | cool |
16:37:06 | dwihn0r | I read something in the CVS logs |
16:37:14 | dwihn0r | The sound settings has gone through a major improvement as well |
16:38:19 | Bagder | gotta run, see ya |
16:38:20 | | Part Bagder |
16:54:35 | *** | Saving seen data "./dancer.seen" |
17:00 |
17:00:22 | | Join elinenbe- [0] (~elinenbe@vanguard.gpcc.itd.umich.edu) |
17:00:27 | elinenbe- | hi |
17:00:53 | elinenbe- | i am on my palmphone |
17:01:07 | elinenbe- | bye |
17:01:09 | | Quit elinenbe- (Client Quit) |
17:03:39 | | Join notch|learningto [0] (hidden-use@arthur.techprt.co.uk) |
17:04:11 | notch|learningto | just built a serial remote for the player... |
17:04:39 | notch|learningto | works fine on a recoreder, but does not work at all on the player... |
17:04:42 | notch|learningto | any ideas? |
17:13:15 | | Join elinenbe_ [0] (~elinenbe@asteroids.gpcc.itd.umich.edu) |
17:13:15 | | Quit ripnetuk (Read error: 104 (Connection reset by peer)) |
17:13:31 | elinenbe_ | Hello there again. |
17:17:28 | elinenbe_ | exit |
17:17:32 | | Quit elinenbe_ (Client Quit) |
17:17:47 | | Quit ironi_ (Read error: 110 (Connection timed out)) |
17:18:01 | | Quit notch|learningto () |
17:40:12 | | Join ironi__ [0] (~ironi@80.88.116.93) |
17:43:41 | | Join Tumm [0] (coyote@mysko.net) |
18:00 |
18:40:29 | dwihn0r | ironi: I got my new box now ;D Yay! |
18:54:39 | *** | Saving seen data "./dancer.seen" |
19:00 |
19:04:45 | | Join ripnetuk [0] (~george@62.137.133.101) |
19:24:02 | | Quit ripnetuk () |
19:24:05 | | Join ripnetuk [0] (~george@ripnet.fsnet.co.uk) |
19:24:08 | | Quit ripnetuk (Client Quit) |
19:33:51 | | Join ripnetuk [0] (~george@ripnet.fsnet.co.uk) |
19:58:06 | | Join champi [0] (~champi@AVelizy-108-1-3-138.abo.wanadoo.fr) |
20:00 |
20:01:13 | | Quit champi (Client Quit) |
20:05:18 | | Join mistaRx [0] (mistaX@195.198.190.205) |
20:14:39 | | Quit mistaRx () |
20:54:41 | *** | Saving seen data "./dancer.seen" |
21:00 |
21:23:47 | | Join WetFlax [0] (~wettoad@flax.mbi-berlin.de) |
21:46:46 | | Join mistaRx [0] (mistaX@t2o975p85.telia.com) |
21:56:30 | | Part mbr_ |
21:58:21 | | Join mbr [0] (~tiw4mabr@rhlx01.fht-esslingen.de) |
22:00 |
22:19:34 | | Quit datazone (Read error: 110 (Connection timed out)) |
22:31:00 | | Quit mistaRx () |
22:42:34 | | Quit adi|home (Read error: 110 (Connection timed out)) |
22:54:42 | *** | Saving seen data "./dancer.seen" |
23:00 |
23:09:25 | | Join adiamas [0] (~adiamas@as5300-9.216-194-23-139.nyc.ny.metconnect.net) |
23:11:36 | | Nick adiamas is now known as adi|home (~adiamas@as5300-9.216-194-23-139.nyc.ny.metconnect.net) |
23:11:36 | | Quit adi|home (Remote closed the connection) |
23:11:44 | | Join adiamas [0] (~adiamas@as5300-9.216-194-23-139.nyc.ny.metconnect.net) |
23:12:21 | | Nick adiamas is now known as adi|home (~adiamas@as5300-9.216-194-23-139.nyc.ny.metconnect.net) |
23:13:28 | | Nick adi|home is now known as adi (~adiamas@as5300-9.216-194-23-139.nyc.ny.metconnect.net) |
23:13:28 | adi | hmmm oddd |
23:13:28 | adi | can't seem to change my nick |
23:13:28 | | Nick adi is now known as adi|home (~adiamas@as5300-9.216-194-23-139.nyc.ny.metconnect.net) |
23:58:43 | | Quit jedix (Remote closed the connection) |