| 00:00:06 | amiconn | ...but writing has to be done with 16bit width |
| 00:00:34 | amiconn | How should we handle such special conditions? |
| 00:04:29 | LinusN | do we have to read them as char? |
| 00:06:19 | preglow | i wonder if i should just remove support for sv4-6 musepack streams |
| 00:06:41 | amiconn | LinusN: Yes, the datasheet says so |
| 00:07:28 | LinusN | so silly... |
| 00:07:36 | amiconn | In fact, you have to write to TCSR and TCNT with a 16 bit access to the same address (0x05FFFFB8), the high byte determines which register is written |
| 00:07:51 | LinusN | omg |
| 00:07:55 | amiconn | High byte 0x5A -> TCNT, 0xA5 -> TCSR |
| 00:08:22 | amiconn | Read address for TCSR is 0x05FFFFB8, for TCNT it is 0x05FFFFB9 |
| 00:09:14 | LinusN | linuxstb: the lowlevel functions in lcd-16bit.c should be moved to lcd-ipod.c or something... |
| 00:09:33 | linuxstb | Sure. |
| 00:09:53 | LinusN | lots of linking errors for the h300 as it is now |
| 00:10:03 | amiconn | LinusN: You're right, but then lcd-recorder.c needs some cleanup too. Today it contains the gmini lowlevel code |
| 00:10:13 | Bagder | LinusN: but nothing really serious, is there? |
| 00:10:32 | | Quit ender` (Read error: 104 (Connection reset by peer)) |
| 00:10:49 | LinusN | Bagder: no, but i'd have to #ifdef a lot in the lcd-16bit.c to make it build |
| 00:10:55 | Bagder | ah |
| 00:11:09 | LinusN | it's very ipod-centric as it is now |
| 00:11:11 | linuxstb | LinusN: Feel free to change lcd-16bit.c - I haven't made any changes locally. |
| 00:11:17 | LinusN | oki |
| 00:11:39 | linuxstb | There's also lots of dead code just copied from the h100 driver - as an example of how those functions should be implemented. |
| 00:11:56 | LinusN | inl()....outl()...yuck |
| 00:12:03 | Bagder | hehe |
| 00:12:33 | amiconn | linuxstb: http://forums.rockbox.org/index.php?topic=1780.0 |
| 00:12:55 | XShocK | just a quick equstion. gcc 4.0.2 is not supported, right? rockbox builds and strarts, but no plugins work.. |
| 00:13:11 | linuxstb | amiconn: What a stange post... |
| 00:13:23 | amiconn | hehe |
| 00:13:30 | LinusN | XShocK: you're on your own there... |
| 00:14:06 | Bagder | XShocK: start fixing! ;-) |
| 00:14:33 | | Quit linuxstb_ ("CGI:IRC (Ping timeout)") |
| 00:15:15 | XShocK | ok. will actually try now. :) |
| 00:16:06 | amiconn | LinusN: Any idea how to handle the SH1 watchdog? Separate #defines fpr reading and writing?? |
| 00:16:13 | amiconn | *for |
| 00:17:58 | LinusN | amiconn: i guess so |
| 00:21:46 | | Quit Moos ("Glory to Rockbox") |
| 00:21:50 | XavierGr | LinusN: did you read my comment about those mp3s that showed wrong lenght earlier? |
| 00:22:04 | preglow | hmm, i just tried a bootloader build for the nano, and it failed |
| 00:22:47 | preglow | riiiight, probably the tools dep error again |
| 00:23:39 | LinusN | XavierGr: no |
| 00:24:02 | XavierGr | well it seems that the same bug is reproducable in foobar |
| 00:24:11 | XavierGr | while in foobar is way worse |
| 00:24:24 | XavierGr | tags cannot be shown in these files |
| 00:25:08 | XavierGr | if the wrong lenght is smaller than the true it will skip tracks midways. |
| 00:25:13 | amiconn | Hmm, something is indeed wrong with the recorder v1 charging. Now that I charged my batteries in an external charger, runtime is already ~13h and still going |
| 00:25:19 | preglow | the rockbox.org box is really going to have a run for its money with new ipod builds as well, heh |
| 00:25:29 | amiconn | With internal charging, I get 6...7 hours of runtime |
| 00:25:41 | XavierGr | ep0ch said to upload the files and check them |
| 00:25:47 | XavierGr | any idea where to upload some? |
| 00:26:34 | XavierGr | (ep0ch said to upload the files, and he will check them) just to not misunderstand |
| 00:26:37 | Bagder | XavierGr: I'll offer a link in /msg |
| 00:28:26 | * | preglow got the ipod money |
| 00:28:39 | Bagder | yay |
| 00:28:57 | preglow | i turned out to use the same bank as zagor, so went swift enough |
| 00:28:57 | | Join linuxstb_ [0] (n=5343d4aa@labb.contactor.se) |
| 00:29:07 | linuxstb_ | Any shops still open in Oslo? |
| 00:29:15 | preglow | haha |
| 00:29:18 | preglow | seriously doubt it |
| 00:32:18 | | Join DJDD [0] (n=DJDD@220-245-186-182.static.tpgi.com.au) |
| 00:32:21 | preglow | i'll see about buying one tomorrow |
| 00:33:49 | LinusN | amiconn: from what i can see, the long-delta check is too generous in the algorithm |
| 00:36:29 | * | LinusN runs the first rockbox code on the h300 |
| 00:36:38 | XavierGr | yay |
| 00:37:02 | LinusN | just single stepping the init |
| 00:38:11 | Bagder | exciting |
| 00:41:02 | amiconn | It seems the automated builds got a lot slower than they used to be |
| 00:41:15 | amiconn | Almost an hour now |
| 00:41:24 | amiconn | ...and still running |
| 00:41:37 | Bagder | its due to other processes running on the host |
| 00:42:15 | amiconn | Yes, you mentioned that. So the number of other processes increased a lot recently? |
| 00:42:39 | | Quit XavierGr (Read error: 104 (Connection reset by peer)) |
| 00:42:57 | Bagder | actually, I don't think the build time has increased to an hour at all times |
| 00:43:09 | preglow | it doesn't |
| 00:43:22 | preglow | twelve 'o clock is usually prime cron time |
| 00:44:24 | Bagder | the last 4 builds averaged on 1875 seconds build time |
| 00:44:54 | Bagder | a little over 31 minutes |
| 00:45:09 | preglow | i wonder what it would be without ccache |
| 00:46:08 | Bagder | well I'm not gonna try ;-) |
| 00:46:58 | amiconn | LinusN: The comment in crt0.S is now wrong. |
| 00:47:52 | markun | Is it possible to get admin rights for the patch tracker? |
| 00:48:55 | LinusN | amiconn: which one? |
| 00:49:16 | amiconn | . /* Platform: iRiver H120/H140 */ |
| 00:49:21 | LinusN | ah |
| 00:49:23 | Bagder | markun: indeed, hang on |
| 00:49:35 | markun | Bagder: ok, thanks |
| 00:50:02 | markun | Bagder: sourceforge login is "marcoen" |
| 00:50:08 | | Quit matsl (Remote closed the connection) |
| 00:50:13 | Bagder | ok |
| 00:51:41 | preglow | what's up with the main.c commit? :P |
| 00:51:49 | LinusN | :-) |
| 00:52:18 | preglow | haha |
| 00:52:22 | preglow | figured that was testing code |
| 00:52:33 | LinusN | indeed |
| 00:53:17 | Bagder | markun: you should now have all the super powers there |
| 00:53:24 | markun | Yay! |
| 00:53:29 | amiconn | Using the watchdog for reset on SH1 works |
| 00:54:22 | * | amiconn has a convenient test plugin "lawbreaker", that just enabled memory guard, then tries to read from location zero |
| 00:55:27 | markun | Bagder: Too bad the summary can't be changed.. |
| 00:55:50 | *** | Saving seen data "./dancer.seen" |
| 00:55:54 | amiconn | TiMiD: There's a bug in the new list browser... |
| 00:56:15 | amiconn | If you delete the lst file in the list, the list cursor vanishes. |
| 00:56:26 | amiconn | s/lst/last/ |
| 00:59:21 | | Join XavierGr [0] (n=XavierGr@ppp49-adsl-10.ath.forthnet.gr) |
| 01:00 |
| 01:00:43 | Bagder | yahoo web crawler crawling down the viewcvs... |
| 01:01:49 | preglow | hahah |
| 01:02:04 | Bagder | I've edited the robots.txt now |
| 01:03:53 | XavierGr | ep0ch, Linus, or others that are interested: this link has 3 tracks which have the length bug with rockbox -> http://daniel.haxx.se/rockbox/xaviergr/ |
| 01:04:35 | XavierGr | I have others too but mostly classical so the size of them is prohibited for upload with my connection. |
| 01:06:53 | XavierGr | is it easy for someone to explain me what's the purpose of yield() function? |
| 01:07:02 | preglow | it passes control on to the next thread |
| 01:07:16 | XavierGr | with no parameters? |
| 01:07:19 | preglow | rockbox uses cooperative threading |
| 01:07:19 | preglow | yes |
| 01:07:34 | preglow | if there are other threads running (which there always are), you pass the control on to them |
| 01:07:37 | XavierGr | if we have 3 threads how can I switch to a specific one? |
| 01:07:39 | preglow | you can't |
| 01:07:47 | preglow | rockbox uses a simple round robin scheduler |
| 01:08:07 | XavierGr | so every time I yiled another thread takes control? |
| 01:08:15 | preglow | yes, that's the entire point of it |
| 01:08:22 | preglow | you're not supposed to care what thread is run |
| 01:08:32 | preglow | if you do, you're doing something wrong |
| 01:08:33 | | Join ashridah [0] (i=ashridah@220-253-120-111.VIC.netspace.net.au) |
| 01:09:03 | XavierGr | so what will happen if I call yield twice in a row? |
| 01:09:38 | XavierGr | will the scond time be executed? |
| 01:09:50 | TiMiD | amiconn: I'm investigating |
| 01:10:14 | Bagder | XavierGr: yes, when it has run all the other threads one lap |
| 01:10:14 | amiconn | Also, there's still the player default icon problem |
| 01:10:19 | TiMiD | yes |
| 01:10:25 | TiMiD | it's solved (I think) |
| 01:10:42 | TiMiD | I will commit if i find a way to solve this one too |
| 01:11:00 | amiconn | On target, the icon isn't always blank, sometimes it shows a garbage icon |
| 01:11:24 | XShocK | omg. i can't replicate the error i got with gcc 4.0.2... it now works as it should.... |
| 01:11:41 | TiMiD | the problem is just that when deleting, tree.c doesn't put the cursor to the right place |
| 01:15:00 | amiconn | Bagder: Does the server do one automated build for every commit, even when several commits queued up during the previous build "round"? |
| 01:15:37 | XShocK | anybody got the same result with gcc 4.0.2 ? "rockbox loads, but can't load plugins." |
| 01:16:03 | XShocK | since i built it again, put in the player, and it works perfectly... |
| 01:16:18 | Bagder | amiconn: after a build is made, it waits a minute and checks for changes |
| 01:16:28 | Bagder | any number |
| 01:16:33 | Bagder | and if any, it rebuilds |
| 01:16:41 | Bagder | if not, it waits a minute and rechecks |
| 01:19:05 | amiconn | Sounds like it should be :) |
| 01:19:33 | TiMiD | what was the previous behaviour when deleting a file ? selecting the first item of the dir, the next item, the previous one ? |
| 01:19:46 | amiconn | Hmm. |
| 01:20:13 | amiconn | Iiuc the cursor was placed on the next file, unless the last one was deleted |
| 01:20:51 | amiconn | Iirc... |
| 01:20:53 | TiMiD | ok |
| 01:21:23 | TiMiD | I will look at the old code to see how it was handled |
| 01:21:24 | linuxstb_ | That sounds natural anyway - i.e. it keeps the cursor in the same position and shifts all subsquent files up one place. |
| 01:21:54 | TiMiD | since there is no indication given to the filetree that a file has been deleted |
| 01:22:07 | TiMiD | only ONPLAY_RELOAD_DIR |
| 01:22:11 | TiMiD | :( |
| 01:22:35 | LinusN | that should be enough, shouldn't it? |
| 01:23:21 | TiMiD | I wonder what trick do they made to make it work :( |
| 01:25:10 | TiMiD | I see a way to fix it, maybe it was the one previously used |
| 01:25:36 | linuxstb_ | All you need to do is remember the cursor position in the list, reload the directory, and then check if it's still within the bounds. If not, then set it to the last file. |
| 01:26:43 | LinusN | exactly |
| 01:27:02 | TiMiD | exacly what I thought ;) |
| 01:27:40 | TiMiD | magic |
| 01:27:44 | TiMiD | it works :) |
| 01:29:42 | preglow | argghhh |
| 01:29:44 | * | preglow kicks musepack |
| 01:30:34 | XShocK | ok. IHP120 works perfectly with gcc 4 ( tested everything except audio files, since only have mp3s..) |
| 01:31:00 | linuxstb_ | preglow: You seem very determined to hammer musepack into shape. |
| 01:31:39 | preglow | linuxstb_: yes, after i realized i knew it well enough to do it |
| 01:31:45 | preglow | but it is remarkably resistant |
| 01:34:06 | linuxstb_ | XShocK: Can you test a change to libfaad with gcc4? It's part of the code that causes an internal compiler error with 3.4.x |
| 01:34:43 | linuxstb_ | You just need to change "#if 0" to "#if 1" in line 74 of apps/codecs/libfaad/fixed.h and then compile |
| 01:35:14 | XShocK | ok |
| 01:35:20 | preglow | remarkable, the stack is _JUST_ not big enough for me to stuff a couple of arrays into it |
| 01:35:40 | preglow | any reason why the codec stacks are exactly 1152*4*2 ? :) |
| 01:35:40 | linuxstb_ | XShocK: Thanks. I'm curious if gcc4 is better than gcc3 in that respect. |
| 01:39:22 | XShocK | it compiled on gcc 4 |
| 01:39:30 | XShocK | and on gc 3.4.3 it failed |
| 01:39:44 | preglow | hmm |
| 01:39:59 | linuxstb_ | Maybe that means we should all upgrade then... |
| 01:39:59 | LinusN | time to sleep, nite all |
| 01:40:00 | preglow | perhaps it's time to move on to gcc4 for m68k |
| 01:40:03 | preglow | LinusN: gnite |
| 01:40:07 | | Part LinusN |
| 01:43:22 | linuxstb_ | XShock: Could you upload a rockbox.zip compiled with gcc4 to somewhere? I can test all the codecs. |
| 01:43:35 | XShocK | ok |
| 01:44:29 | linuxstb_ | Thanks. I don't expect any problems, but you never know. |
| 01:47:57 | XShocK | http://rinat.acm.jhu.edu/rockbox.zip |
| 01:51:21 | | Join Midgey34 [0] (n=Midgey34@c-67-172-68-52.hsd1.mi.comcast.net) |
| 01:53:26 | XShocK | worked? |
| 01:53:47 | linuxstb_ | Just downloading it now. Give me 2 minutes to test. |
| 01:53:57 | | Quit linuxstb_ ("CGI:IRC") |
| 01:55:30 | preglow | hrmf |
| 01:55:39 | preglow | seems there's some dep problems with the map files or codec plugins |
| 01:56:29 | linuxstb | Wow - AAC is realtime :) |
| 01:56:46 | linuxstb | Almost... It played for 20 seconds and then a tiny pause. |
| 01:56:58 | preglow | haha |
| 01:56:58 | preglow | wow |
| 01:57:07 | linuxstb | Then another 20 seconds, and another tiny pause. |
| 01:57:30 | | Join _user_ [0] (n=c762142c@labb.contactor.se) |
| 01:57:31 | preglow | perhaps i should build myself a gcc4 toolset myself |
| 01:57:33 | linuxstb | It's very very close now. |
| 01:57:41 | linuxstb | Yes - I think we should all upgrade. |
| 01:58:10 | linuxstb | Would your multiplication cause this improvement, or do you think it's also gcc itself? |
| 01:58:56 | preglow | i tend to believe the last |
| 01:59:03 | preglow | MUL_C isn't used that often outside of sbr |
| 01:59:17 | linuxstb | In which case, most of the codecs should see an increase then. |
| 01:59:43 | preglow | it's worth a try |
| 01:59:53 | preglow | perhaps you'd like to do some quick boost ratio comparisons? :) |
| 02:00 |
| 02:00:35 | linuxstb | hehe. Just give me 200 hours... |
| 02:00:52 | | Quit novimon (Read error: 110 (Connection timed out)) |
| 02:00:57 | linuxstb | Sorry, you meant boost ratio, not runtime? |
| 02:02:13 | linuxstb | No noticeable difference with ALAC. |
| 02:03:31 | preglow | when i want to replace an array in a struct with a pointer to some outside array without modifying any source, i just replace a int hehe[400]; by int *hehe; and assign the pointer somewhere else. what if i want to do the same for 'int hehe[30][30]'? there's nothing i can do like that then, no? |
| 02:04:02 | linuxstb | I've thought about the same problem - without thinking of a solution. |
| 02:04:23 | preglow | i can fit the entire mpc_decoder struct in iram now, but i need to outsource a set of arrays like that :/ |
| 02:06:33 | amiconn | Pointers to multi-dimensional arrays are possible, but don't ask me how to insert these into a struct |
| 02:06:54 | linuxstb | Not sure if this helps: http://www.eskimo.com/~scs/cclass/int/sx9b.html |
| 02:06:57 | amiconn | Iirc TiMiD's fire plugin used these before I did my optimising work |
| 02:07:56 | preglow | amiconn: yes, they are possible, but you need to edit the source using the struct after substituting the original multidim array for a pointer |
| 02:08:45 | preglow | libmad uses them all the time |
| 02:14:12 | XShocK | brb |
| 02:14:14 | | Quit XShocK ("Leaving") |
| 02:15:11 | * | preglow has tamed musepack |
| 02:15:40 | preglow | that is, if i can find a good solution to the above problem |
| 02:15:50 | preglow | it hardly boosts at all now |
| 02:18:08 | preglow | 10% boost ratio on a standard file |
| 02:18:11 | | Join XShocK [0] (n=XShocK@centaur.acm.jhu.edu) |
| 02:18:22 | TiMiD | good night here |
| 02:18:25 | preglow | god knows how fast this could have been without the retarded math |
| 02:18:32 | preglow | it would never have boosted, that's for sure |
| 02:19:20 | XShocK | hi |
| 02:22:04 | linuxstb | XShocK: Everything seems to be working fine with your gcc4 build. |
| 02:23:35 | preglow | think i'll try myself that build as well |
| 02:25:07 | XShocK | good |
| 02:26:54 | preglow | realtime aac |
| 02:26:56 | preglow | so it is possible |
| 02:27:15 | | Quit tvelocity ("Leaving") |
| 02:30:36 | linuxstb | XShock: I'm assuming this build includes the "#if 1" change? |
| 02:31:52 | XShocK | yes |
| 02:36:00 | linuxstb | night all. |
| 02:36:05 | preglow | nightie |
| 02:36:24 | XShocK | night |
| 02:48:46 | | Join BirdFish [0] (n=bradbox8@64.108.5.134) |
| 02:53:39 | XavierGr | amiconn: unfortunately the fix you made didn't do much on the ticking issue... |
| 02:55:12 | XavierGr | and I found something new and weird... |
| 02:55:51 | *** | Saving seen data "./dancer.seen" |
| 02:56:58 | XavierGr | if I press with my finger the remote jack (while pluged-in, vertical to the player, not parallel to the ports) these ticks are almsot gone.... |
| 02:58:28 | | Join Midgey31 [0] (n=Midgey34@c-67-172-68-52.hsd1.mi.comcast.net) |
| 03:00 |
| 03:09:27 | | Quit Midgey31 ("Download Gaim: http://gaim.sourceforge.net/") |
| 03:09:51 | | Join Midgey31 [0] (n=Midgey34@c-67-172-68-52.hsd1.mi.comcast.net) |
| 03:12:49 | | Quit _user_ ("CGI:IRC (EOF)") |
| 03:14:35 | | Quit Midgey34 (Read error: 110 (Connection timed out)) |
| 03:15:20 | | Quit DJDD (Read error: 110 (Connection timed out)) |
| 04:00 |
| 04:11:26 | XavierGr | stupid windows SIM, I can't manage to run a single plug-in of my own, while it runs perfectly on the target.... |
| 04:22:36 | | Quit solexx (Read error: 104 (Connection reset by peer)) |
| 04:28:00 | | Join solexx [0] (n=jrschulz@c173025.adsl.hansenet.de) |
| 04:29:23 | Midgey31 | XavierGr: which plugin is this? |
| 04:41:46 | XavierGr | well it is a plugin that I am working to it right now. |
| 04:41:54 | | Quit hardeep ("BitchX: now Y2K compatible!") |
| 04:42:25 | Midgey31 | oh mysterious... I wait until you reveal more |
| 04:42:33 | XavierGr | the problem is that as soon as I call a function from the plug-in starting point, the sim crashes, while the target continues. |
| 04:43:18 | Midgey31 | hmm, well I don't think can be much help, no h100 to test with and very limited knowledge of C (a fact I hope to soon correct) |
| 04:43:45 | XavierGr | do you have an mp3 player at all? |
| 04:43:57 | Midgey31 | h320 |
| 04:44:07 | XavierGr | hmm nice |
| 04:44:07 | Midgey31 | my bother has a iAudio X5 |
| 04:44:17 | Midgey31 | and the other has a creative zen muvo 2 |
| 04:44:18 | XavierGr | nice too |
| 04:44:32 | XavierGr | ehmm.... |
| 04:44:34 | XavierGr | no UMS |
| 04:44:42 | XavierGr | or it? |
| 04:44:45 | XavierGr | is? |
| 04:44:56 | XavierGr | I think muvo 2 is UMS, no? |
| 04:44:58 | Midgey31 | umm, I'm not too familiar with it |
| 04:45:03 | Midgey31 | but he seems to like it |
| 04:45:16 | XavierGr | 4GB right? |
| 04:45:32 | Midgey31 | yes |
| 04:45:59 | Midgey31 | its actually the MuVo 2 Fm if that makes any difference |
| 04:46:23 | Midgey31 | the fact that it can only play MP3 and WMA is why I tend to stay away from it |
| 04:46:28 | XavierGr | yes it is UMS as far as I can remember |
| 04:46:39 | XavierGr | it was the first DAP i considered bying |
| 04:47:04 | Midgey31 | I did the same because it was so much cheaper than an iPod |
| 04:47:05 | XavierGr | then I saw a ZEN extra 60GB but I realised that without UMS capabilities I couldn't live |
| 04:47:15 | Midgey31 | I really like the Zen |
| 04:47:21 | Midgey31 | although it is a big large |
| 04:47:30 | XavierGr | then I saw an iHP-140 I fell in love with it and still I am... |
| 04:48:01 | Midgey31 | they were discontinued at the time I got my h320 and I don't have found memories with ebay |
| 04:48:35 | XavierGr | well I am considering to buy an h340 as an alternative if my unit fails... |
| 04:49:01 | XavierGr | but they are not easy to find and I don't think I can afford another 400euros |
| 04:49:42 | XavierGr | but even in thought that one day it will be the most capable Rockbox mp3 player... |
| 04:50:04 | Midgey31 | for the time being |
| 04:50:11 | Midgey31 | who knows what may come along |
| 04:50:18 | Midgey31 | but it is a powerful little bugger |
| 04:50:22 | XavierGr | In fact I will not buy another mp3 player if it isn't supported by Rockbox... |
| 04:50:55 | Midgey31 | I haven't gotten to experience rockbox, but I'm pretty sure I'll feel the same once I do |
| 04:51:50 | Midgey31 | by the way, isn't it _really_ late/early over in Greece right now? |
| 04:52:22 | XavierGr | very late, I should sleep in 1 hour and 30 mintues I should be awake... |
| 04:52:38 | Midgey31 | I don't think I could ever do that |
| 04:52:58 | Midgey31 | I have to get up in 7 hours for class and I'm not looking forward to that... |
| 04:53:00 | XavierGr | now that you mention it, I don't know if I can too. |
| 04:53:29 | Midgey31 | screw sleep, load up on caffeine and you'll be good to go |
| 04:55:05 | XavierGr | maybe I will just lye down on my bed for the rest of my time. |
| 04:55:07 | XShocK | ant there any custom firmwares for RCA Lyra? |
| 04:55:16 | XShocK | Jukebox 20gb |
| 04:55:32 | XShocK | it has DSP DM320 from TI> |
| 04:55:54 | *** | Saving seen data "./dancer.seen" |
| 04:56:46 | XShocK | or DM230, not sure.. anyway i doubt there are any firmwares around.. i couldn't even find datasheet for that DSP... only analog, C55x.. |
| 05:00 |
| 05:36:56 | | Join Lost-ash [0] (i=ashridah@220-253-120-111.VIC.netspace.net.au) |
| 05:36:56 | | Quit ashridah ("Leaving") |
| 05:38:44 | | Quit Midgey31 ("Download Gaim: http://gaim.sourceforge.net/") |
| 05:39:58 | | Nick Lost-ash is now known as ashridah (i=ashridah@220-253-120-111.VIC.netspace.net.au) |
| 05:45:11 | | Quit XShocK (Remote closed the connection) |
| 06:00 |
| 06:16:30 | XavierGr | I just ran flat my H140s battery. |
| 06:17:21 | XavierGr | I forced it to work until it reached a 2.73V level. Is that normal? I thought that this is li-ions internal limit... |
| 06:18:11 | | Join _user_ [0] (n=18d79b85@labb.contactor.se) |
| 06:19:30 | | Join DJDD [0] (n=DJDD@220-245-186-182.static.tpgi.com.au) |
| 06:33:49 | | Quit _user_ ("CGI:IRC (EOF)") |
| 06:44:55 | | Quit RotAtoR () |
| 06:52:31 | | Join XShocK [0] (n=XShocK@centaur.acm.jhu.edu) |
| 06:55:56 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:11:17 | | Quit DJDD (Read error: 110 (Connection timed out)) |
| 07:36:37 | | Join B4gder [0] (n=daniel@static-213-115-255-230.sme.bredbandsbolaget.se) |
| 07:50:36 | | Join DJDD [0] (n=DJDD@220-245-186-182.static.tpgi.com.au) |
| 08:00 |
| 08:19:34 | | Join bbad [0] (n=bbad@81.198.48.110) |
| 08:29:06 | | Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) |
| 08:42:49 | | Join ender` [0] (i=ychat@84.52.165.220) |
| 08:56:00 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 09:08:02 | | Join Paul_The_Nerd [0] (n=paulthen@cpe-66-68-93-2.austin.res.rr.com) |
| 09:08:37 | | Join LinusN [0] (n=linus@labb.contactor.se) |
| 09:24:20 | Zagor | neat, ebay phishing attempt to rockbox-dev |
| 09:27:21 | LinusN | lame |
| 09:39:00 | Paul_The_Nerd | The sad thing is that enough people fall for them that it's worth their time to keep doing it. |
| 09:42:29 | | Quit DJDD (Read error: 110 (Connection timed out)) |
| 09:43:37 | ashridah | Paul_The_Nerd: the annoying thing is that even if they send out 1 million emails and only get 10 hits, it's economical for them to do so. |
| 09:44:03 | Paul_The_Nerd | It's probably economical even if they get 1 hit. |
| 09:46:17 | | Part LinusN |
| 09:51:01 | | Quit Lynx_ (" reboot") |
| 09:53:58 | | Join Lynx_ [0] (n=lynx@tina-10-4.genetik.uni-koeln.de) |
| 09:57:22 | | Quit korpse ("brb changing encodings") |
| 09:59:40 | | Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) |
| 10:00 |
| 10:03:41 | | Quit korpse (Client Quit) |
| 10:12:32 | linuxstb | Would anyone be against requiring gcc4 to build the Coldfire version of Rockbox? Switching to it would appear to solve the ICE problems we've been experiencing with libfaad and it also appears to give a noticeable speed improvement (AAC is very very close to realtime when compiled with gcc4). |
| 10:18:11 | B4gder | why would we need to require it? |
| 10:18:18 | B4gder | can't we just recommend it? |
| 10:18:44 | | Join Jungti1234 [0] (n=jungti12@58.77.81.75) |
| 10:18:55 | Jungti1234 | hi |
| 10:19:31 | merbanan | B4gder: like "gcc4 is recommended coz then Rockbox works instead of not" :) |
| 10:19:34 | | Quit Kohlriba ("Leaving") |
| 10:19:56 | B4gder | like that |
| 10:20:08 | B4gder | I bet most people don't have aac songs anyway |
| 10:24:32 | linuxstb | Because gcc 3.4.x fails with ICEs in parts of libfaad. e.g. one of preglow's optimisations caused an ICE. |
| 10:24:33 | preglow | haha' |
| 10:24:34 | Paul_The_Nerd | They're more likely to once the iPod port is done though |
| 10:24:48 | Paul_The_Nerd | Have AACs, I mean, B4gder |
| 10:24:58 | linuxstb | Supporting 3.4.x and making full use of gcc 4 would mean #ifdefs |
| 10:25:03 | ashridah | yeah, anyone buying music off itunes potentially has AAC's don't they? |
| 10:25:31 | ashridah | does gcc 4 build all currently supported platforms without any detrimental effects? |
| 10:25:35 | linuxstb | But I think I would propose at least a transitional period where gcc4 is recommended but gcc3 would still work. |
| 10:25:41 | B4gder | ashridah: no |
| 10:25:54 | * | ashridah imagines there's code size issues |
| 10:27:16 | | Quit mbr ("leaving") |
| 10:27:17 | B4gder | there are more issues than just the size on sh1 |
| 10:27:41 | ashridah | ah |
| 10:28:05 | linuxstb | At the moment it is just one small function in libfaad that would need an #ifdef around it, but it wouldn't surprise me if we hit more ICE problems when working with libfaad - it seems very fragile in that respect. |
| 10:29:36 | | Join mbr [0] (n=mb@stz-softwaretechnik.de) |
| 10:31:02 | | Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-133-199.pools.arcor-ip.net) |
| 10:33:21 | preglow | indeed |
| 10:34:13 | preglow | we wouldn't need to use gcc4 for sh1 anyway |
| 10:34:19 | preglow | we pretty much can't |
| 10:41:28 | linuxstb | Anyone know a reason not to use gcc4 for ARM? |
| 10:42:50 | B4gder | nope |
| 10:43:58 | | Join ep0ch [0] (n=ep0ch@84.12.66.114) |
| 10:44:44 | preglow | i'd like some code size and speed tests with gcc4, but the speed part is of course not straight forward as it is |
| 10:45:04 | preglow | but i guess the fact that it at least compiles the code we need it to counts for something |
| 10:45:19 | ep0ch | XavierGr: I've got your mp3s |
| 10:46:02 | ep0ch | XavierGr: What tags are missing? In foobar2000 0.9b10 i can see tags |
| 10:46:52 | ep0ch | XavierGr: the bitrate is being reported a bit wrong though :s |
| 10:56:02 | *** | Saving seen data "./dancer.seen" |
| 11:00 |
| 11:01:46 | | Quit Jungti1234 ("Http://www.ZeroIRC.NET ¢Æ Zero IRC ¢Æ Ver 2.8") |
| 11:04:27 | ep0ch | I have a suspicion the GCC4 build is boosting mp3 more than before. |
| 11:09:33 | ep0ch | yeah my 112 kbps mp3 boosts with 6% with that GCC4 build. Bleeding edge build doesnt boost at all. |
| 11:10:20 | B4gder | :-/ |
| 11:10:41 | ep0ch | now for Vorbis! |
| 11:12:18 | linuxstb | So it seems it's not going to be straightfoward choice then... |
| 11:13:30 | preglow | i also got the impression libmad was slower, which was why i wanted speed tests :/ |
| 11:15:31 | preglow | yeah, i can confirm that, i've got a 112kbs file that now suddenly boosts |
| 11:15:46 | ep0ch | Vorbis@137: GCC3 28-29% boost, GCC4: 34% boost |
| 11:15:48 | preglow | i assume this isn't the result of lear's synth.c hack to make gcc4 work, though |
| 11:16:32 | preglow | m68k doesn't exactly seem to be an important target for gcc these days |
| 11:17:33 | ep0ch | flac aint boosting though :) |
| 11:17:38 | ep0ch | phew |
| 11:20:17 | preglow | what about codec sizes? |
| 11:24:38 | | Join Jungti1234 [0] (n=zeroirc@58.77.81.75) |
| 11:27:48 | | Quit linuxstb ("Leaving") |
| 11:28:00 | | Part Jungti1234 |
| 11:29:57 | XavierGr | ep0ch are you here? |
| 11:30:09 | XavierGr | I use foobar 0.8.3 |
| 11:30:25 | XavierGr | what length do you have for the first song? |
| 11:35:24 | | Join Jungti1234 [0] (n=jungti12@58.77.81.75) |
| 11:36:26 | ashridah | hm. if i use gcc 4.0.2, do i need to update binutils? |
| 11:37:45 | XavierGr | ep0ch: Yes foobar 0.9b10 seems to solve the tag problem |
| 11:37:54 | | Quit ashridah ("Leaving") |
| 11:38:05 | | Join ashridah [0] (i=ashridah@220-253-120-111.VIC.netspace.net.au) |
| 11:38:07 | XavierGr | ep0ch though the track length still remains. |
| 11:38:37 | ashridah | gah. |
| 11:58:10 | | Join ender1 [0] (i=ychat@84.52.165.220) |
| 12:00 |
| 12:12:02 | B4gder | ashridah: no, you can use the same binutils |
| 12:13:03 | | Quit ender` (Read error: 110 (Connection timed out)) |
| 12:17:05 | ashridah | B4gder: tah. i've already compiled it up and copied it onto my iriver anyway, it bootedokay, but haven't tested plugins yet |
| 12:25:50 | | Quit XavierGr ("Trillian (http://www.ceruleanstudios.com") |
| 12:31:16 | | Join DJDD [0] (n=DJDD@220-245-186-182.static.tpgi.com.au) |
| 12:32:18 | ep0ch | preglow: aac and flac codec size got a tiny bit smaller with gcc4 |
| 12:32:31 | ep0ch | preglow: mpa, mpc, vorbis and wavpack got bigger |
| 12:32:38 | preglow | nice...... |
| 12:33:01 | ep0ch | i can paste the actual sizes if you want |
| 12:33:38 | ep0ch | yeah aac lost a whole 23k |
| 12:35:16 | | Join XavierGr [0] (n=XavierGr@ppp49-adsl-10.ath.forthnet.gr) |
| 12:37:15 | markun | damn, this bejeweled game is keeping me from working.. level 10 now. |
| 12:38:03 | | Join DJDD_ [0] (n=DJDD@220-245-186-182.static.tpgi.com.au) |
| 12:38:55 | Paul_The_Nerd | Hahaha |
| 12:39:05 | Paul_The_Nerd | I always run out of moves around 4 or 5 |
| 12:39:25 | markun | I want to quit, but I don't want to loose the score. |
| 12:39:52 | Paul_The_Nerd | You can save the game, you know |
| 12:40:01 | markun | Yes, I know :) |
| 12:40:29 | Paul_The_Nerd | Oh, so that's "Just an excuse" |
| 12:41:24 | markun | level 11.. |
| 12:49:05 | markun | 12.. |
| 12:49:41 | | Join korpse [0] (i=korpse@rrba-146-77-149.telkomadsl.co.za) |
| 12:51:02 | Jungti1234 | Timestamp |
| 12:51:03 | Jungti1234 | 2005-11-09 01:35 |
| 12:51:09 | Jungti1234 | -_-; |
| 12:54:07 | | Quit DJDD (Read error: 110 (Connection timed out)) |
| 12:55:59 | preglow | seems they only have 2 gig nanos left around here |
| 12:56:03 | *** | Saving seen data "./dancer.seen" |
| 12:56:08 | preglow | oh well |
| 12:57:02 | markun | Will you order a 4gig one? |
| 12:57:15 | preglow | nah, i want it today :> |
| 12:58:18 | XavierGr | impatient like me preglow... |
| 12:58:27 | preglow | 2 gigs should do for my use anyway |
| 12:58:43 | XavierGr | when an idea is tuck in my head I can't get it out! |
| 12:59:18 | markun | I wonder how good the hardware of the iPod 4g is compared to H120. |
| 13:00 |
| 13:00:57 | markun | I might buy one for my girlfriend when is runs rockbox |
| 13:01:08 | ashridah | traitor! |
| 13:01:26 | markun | :) |
| 13:01:39 | XavierGr | hmmff |
| 13:01:49 | XavierGr | I am annyoed by this iPod outbreak |
| 13:02:17 | XavierGr | now I can't boast that my player is one of the unique ones that runs Rockbox |
| 13:02:24 | markun | Wait till linus finished the H300 loader, there will be another outbreak |
| 13:02:46 | XavierGr | well h300 is the same as h100 so... ;| |
| 13:02:58 | XavierGr | on the other hand |
| 13:03:08 | ep0ch | i don't mind the H300 outbreak, might mean some more people working on codecs |
| 13:03:09 | XavierGr | it will be a fair clash between H100 and an iPod |
| 13:03:33 | korpse | why would there be an outbreak? |
| 13:03:37 | korpse | (for the uninformed) |
| 13:03:42 | Paul_The_Nerd | The iPod still doesn't have a few of the features that the H100 has though? Right? |
| 13:03:48 | markun | bejeweled is finally over at 1263 points.. |
| 13:03:49 | XavierGr | ep0ch: wanted to tell me something? |
| 13:03:50 | Paul_The_Nerd | FM, Optical, most notably. |
| 13:04:04 | XavierGr | Paul_The_Nerd: A lot not some |
| 13:04:05 | markun | Paul_The_Nerd: yes, that's true |
| 13:04:12 | preglow | can't say i care what rockbox runs on |
| 13:04:21 | XavierGr | that's why I said a fair clash |
| 13:04:40 | XavierGr | iPod users were backing their reaons on the database and ease of use |
| 13:05:00 | XavierGr | but now that it will run rockbox it will be chopped |
| 13:05:03 | Paul_The_Nerd | Yeah, but neither of those will be consistent with Rockbox. |
| 13:05:09 | XavierGr | no reckording no radio, no to a lot |
| 13:05:11 | ep0ch | XavierGr: not really looked at those mp3s much. did you compress them yourself? |
| 13:05:16 | Paul_The_Nerd | Though one could conceivably support the iPod database on Rockbox |
| 13:05:37 | Paul_The_Nerd | Heck, you could even support iTunes encrypted files if you *really* wanted to, though it'd probably be a much better idea to decrypt them before copying over |
| 13:05:46 | XavierGr | ep0ch: yes, I just don't remember with which encoder... |
| 13:05:50 | XavierGr | but the timings are wrong no? |
| 13:06:06 | ep0ch | i'll try and find out about the encoder |
| 13:06:12 | ep0ch | yes times are very wrong |
| 13:06:24 | | Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
| 13:06:25 | Jungti1234 | markun: Is some because I play bejeweled game in msn messenger? |
| 13:06:35 | XavierGr | though winamp and iriver fw show it correctly... |
| 13:06:41 | ep0ch | and something wrong with the bitrate too |
| 13:07:07 | ep0ch | probably down to dodgy length |
| 13:07:32 | XavierGr | well I have made a wird outcome with this |
| 13:07:48 | XavierGr | on my player the durations are swapt between tracks |
| 13:08:00 | XavierGr | e.g the next track holds the duration of the previous one! |
| 13:08:43 | ep0ch | :s |
| 13:09:12 | XavierGr | fucked up situation |
| 13:09:27 | XavierGr | I still don't get why winamp can show it correctly |
| 13:09:39 | B4gder | because winamp prolly scan the whole file |
| 13:10:40 | XavierGr | though Linus insisted it was a rockbox bug. |
| 13:10:52 | B4gder | I didn't exclude that possibility |
| 13:11:04 | | Nick paugh is now known as AliasCoffee (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
| 13:11:05 | B4gder | comparing to winamp however is always a weak argument |
| 13:11:21 | XavierGr | and fw iriver |
| 13:11:22 | B4gder | since winamp spends loads of memory and loads of cpu that Rockbox just doesn't |
| 13:11:26 | XavierGr | but that weak too |
| 13:11:36 | ep0ch | XavierGr: compressed with lame 3.95 apparantly |
| 13:11:43 | XavierGr | I will try other players too. |
| 13:11:44 | B4gder | I think the comparison to the original much better in this case |
| 13:12:22 | XavierGr | hmm which program did I use for this.... it must have been this idiotic dbpowerAMP I can never trust it again. |
| 13:12:53 | XavierGr | and the problem is that I don't know how many mp3s are like that on my collection... |
| 13:13:02 | | Join amiconn_ [0] (n=jens@p54BD5A5B.dip.t-dialin.net) |
| 13:13:05 | XavierGr | reripping is not an option. |
| 13:13:48 | Paul_The_Nerd | dbPowerAMP has been pretty reliable for me, but I will admit I don't use MP3 |
| 13:14:21 | XavierGr | yes I use it for lossless but I can't really trust it on mp3 |
| 13:14:30 | XavierGr | I will use only EAC from now on... |
| 13:15:45 | Paul_The_Nerd | Don't they both use LAME for their encoding though? |
| 13:16:23 | XavierGr | well I had to download lame for both of the programs |
| 13:16:29 | XavierGr | at least latest version |
| 13:16:40 | XavierGr | but EAC is the sure thing anyway. |
| 13:16:52 | XavierGr | it will copy wav on disc and then encode |
| 13:16:53 | ep0ch | XavierGr: was you're original source from CD then? |
| 13:17:03 | XavierGr | and check for errors and f any reports them |
| 13:17:09 | XavierGr | yes |
| 13:17:52 | Paul_The_Nerd | The EAC error checking is just to verify the sector reads, it'd prevent skips in the MP3 and such primarily. |
| 13:18:05 | Paul_The_Nerd | It's not likely to fix encoding issues like that if I understand... |
| 13:18:27 | Paul_The_Nerd | I do the opposite really... dbPoweramp for OGG lossy, and EAC when I want to make an archival copy of a CD. |
| 13:18:31 | XavierGr | yes but still this is very usefull |
| 13:19:26 | XavierGr | I have many mp3s that have clips and bips (due to software) and I never got informed about that, only when listening, now it is too dificult for me to track down all these tracks |
| 13:23:42 | ep0ch | XavierGr: i just used Mp3 repair tool 1.5, install it, and select "Remove everything after last frame" |
| 13:23:48 | ep0ch | seems ok in foobar now |
| 13:24:09 | XavierGr | did it removed audio data or tags? |
| 13:24:13 | ep0ch | no thats a lie |
| 13:24:14 | | Join linuxstb [0] (n=linuxstb@host213-123-154-169.in-addr.btopenworld.com) |
| 13:24:28 | ep0ch | i told it to remove 1 frame at the begining |
| 13:25:02 | ep0ch | well the tags still seem to be there |
| 13:25:23 | XavierGr | linuxstb: I can say that your nick is contraddicting from now on! :) |
| 13:25:43 | XavierGr | LINUXstb to make apple ipod ports, nooooo |
| 13:26:06 | preglow | what, it's not like he's porting mac os x or something :) |
| 13:26:12 | XavierGr | ep0ch: so did it worked? |
| 13:26:13 | B4gder | what is the stb fore anyway? |
| 13:26:16 | B4gder | for |
| 13:26:33 | linuxstb | The only features missing on the iPod are digital I/O and radio. It has recording (with varying samplerates up to 96KHz) but line in/out are only available via the proprietory dock connector. |
| 13:27:09 | XavierGr | hmfrrr... |
| 13:27:19 | linuxstb | B4gder: It comes from a project I started and abandoned years ago - to develop DVB software for a linux set-top box. |
| 13:27:19 | XavierGr | fanboy :D |
| 13:27:27 | B4gder | aha |
| 13:27:27 | linuxstb | XavierGr: Advocate. I want help :) |
| 13:27:52 | XavierGr | sure |
| 13:28:10 | preglow | anywho |
| 13:28:18 | preglow | time for me to see if there's an ipod available around here |
| 13:28:18 | | Quit Kohlrabi ("Leaving") |
| 13:28:34 | ep0ch | goodluck |
| 13:28:58 | Paul_The_Nerd | Rockbox support would be the decision influencing my purchase of a Nano if I do. |
| 13:29:48 | linuxstb | My main motivation for the port is that ipods are _very_ easily available. Unlike the iriver devices now. There are millions all over the planet. |
| 13:29:53 | | Quit amiconn (Read error: 110 (Connection timed out)) |
| 13:29:54 | | Nick amiconn_ is now known as amiconn (n=jens@p54BD5A5B.dip.t-dialin.net) |
| 13:29:54 | preglow | and perhaps you'll see the first photos afterwards :) |
| 13:29:57 | preglow | linuxstb: exactly |
| 13:30:03 | Paul_The_Nerd | Yeah, that is a good reason |
| 13:30:09 | ep0ch | has the nano got that cool clicky wheel? |
| 13:30:14 | XavierGr | come to think if this port is succeesfull and finished it will be the only target that remains in the market |
| 13:30:16 | ep0ch | for scrolling etc |
| 13:30:19 | XavierGr | in fact brand new.. |
| 13:30:30 | preglow | ep0ch: i should most certainly hope so |
| 13:30:52 | ep0ch | didnt think it was big enough to act as a scroll wheel |
| 13:30:59 | linuxstb | The color ipod that I have is already obsolete - it's now replaced by the video ipod. The Nano is the only model which can still be considered current. |
| 13:31:06 | korpse | http://news.bbc.co.uk/2/hi/technology/4417344.stm |
| 13:31:13 | korpse | (with regard to the Nano) |
| 13:31:28 | DBUG | Enqueued KICK Jungti1234 |
| 13:31:28 | * | Jungti1234 ´ÔÀº ºÎÀçÁßÀ̽ʴϴÙ.(wait) |
| 13:32:13 | Paul_The_Nerd | Apparently, korpse, Apple is already replacing the ones with actually defective screens |
| 13:32:40 | korpse | oh okay |
| 13:32:52 | preglow | well, yes, with screens that are said to be not too good either |
| 13:32:59 | preglow | some people claim all nanos scratch too easily |
| 13:32:59 | Slasher | Hmm, i really don't understand why i can't get any response from the eeprom chip.. I think i will go and open the iriver again and hook up a logic analyzer |
| 13:33:20 | Paul_The_Nerd | The defect is that the LCD actually cracks beneath and gets these horrid burn-looking thigns on 'em |
| 13:33:34 | preglow | all ipods i've seen are scratched like hell anyway |
| 13:33:41 | preglow | since people refuse to use protective cases with them |
| 13:33:45 | Paul_The_Nerd | But yeah, I've heard they do scratch easily. But supposedly they're made of the same stuff as normal iPods |
| 13:33:52 | korpse | i'd like to get a portable audio player, but all of them seem to have rather annoying drawbacks |
| 13:33:57 | markun | Slasher: What |
| 13:33:57 | Paul_The_Nerd | They just have a sleeker surface so it's more apparent. |
| 13:34:06 | linuxstb | korpse: Then buy three or four :) |
| 13:34:23 | korpse | linuxstb: can i bill you? :) |
| 13:34:24 | markun | Slasher: What's in the eeprom? The code that starts the firmware from flash? |
| 13:34:37 | Slasher | markun: trying to get eeprom memory working but it doesn't answer anything to commands.. |
| 13:34:54 | Slasher | markun: it's optional setting memory, 1 KiB in size |
| 13:35:21 | korpse | the only iRiver HDD player still in production is the H10, right? |
| 13:35:27 | Slasher | we could save the config structure in there instead of disk for example |
| 13:35:41 | korpse | how does the H10 stack up against the iPod family (of audio players) |
| 13:35:45 | korpse | ? |
| 13:35:57 | Paul_The_Nerd | The H10 makes kittens cry. |
| 13:36:09 | markun | Slasher: would be nice, then we can save the config every time and don't have to worry about the drive spinning up |
| 13:36:27 | Paul_The_Nerd | (Honestly, I don't really know. But all I've heard are various complaints about battery life, and other things I haven't paid attention to) |
| 13:36:35 | korpse | Paul_The_Nerd: hmm |
| 13:36:49 | Slasher | markun: yes |
| 13:36:56 | korpse | what's the development time for the iPod version of Rockbox looking like? |
| 13:36:57 | Paul_The_Nerd | I have an h120, so when I read negative things about the H10 I kind of tend to skim over them. |
| 13:37:00 | XavierGr | Slasheri: I have a suggestion that came to my mind yesterday.... |
| 13:37:07 | korpse | actually, let me just consult the wiki |
| 13:37:33 | XavierGr | While the dircache works magnificently the same doesn't applies for the playlist viewer. |
| 13:37:39 | Paul_The_Nerd | There's no real timeline with any of this, korpse, but judging from linuxstb's obvious manic obsession, it's probably gonna go pretty well. |
| 13:37:42 | markun | I believe that H10 stays in standby mode when you turn it off (just like the ipod) and slowly drains the battery |
| 13:37:49 | XavierGr | every time I tried to see the playlist viewer the HD would kick in. |
| 13:38:01 | Slasher | XavierGr: Hmm, true. The playlist is a whole separate thing |
| 13:38:22 | Slasher | It reads part of the playlist file from disk to its own cache |
| 13:38:29 | korpse | Paul_The_Nerd: in terms of what you can actually buy (off the shelf) at the moment, do you think there is anything that beats/competes with the iPod? |
| 13:38:36 | XavierGr | I see no good reason to load names from the disk for the playlist |
| 13:38:53 | B4gder | korpse: iAudio |
| 13:39:02 | Paul_The_Nerd | iAudio X5 is supposed to be pretty impressive. |
| 13:39:23 | korpse | mmm, time to whip out google again :P |
| 13:39:30 | XavierGr | Slasher: Do you think that i caching of playlist happens it will have a major drawback? |
| 13:39:33 | Slasher | I don't exactly know how the playlist works, but for somebody who has worked with it, it might be possible to save the playlist entirely on memory on iriver |
| 13:39:54 | Slasher | XavierGr: i am not sure |
| 13:39:58 | crwl | iAudio X5 is really quite cool |
| 13:40:10 | Slasher | It eats more memory but not sure how much |
| 13:40:17 | crwl | it's mostly like h300, i think, but not so freakin' huge |
| 13:40:22 | korpse | is there an iAudio Rockbox port? |
| 13:40:29 | B4gder | korpse: there's a start of one |
| 13:40:40 | B4gder | but no more than so |
| 13:40:48 | korpse | ah okay |
| 13:41:08 | B4gder | an opportunity to show off! |
| 13:41:11 | B4gder | :-) |
| 13:41:16 | korpse | ? |
| 13:41:19 | B4gder | do the port |
| 13:41:33 | preglow | but i'm out |
| 13:41:50 | korpse | haha, the most low-level coding i've ever done was programming some crappy chip at school |
| 13:43:40 | | Quit AliasCoffee ("Leaving") |
| 13:46:58 | | Quit Paul_The_Nerd (Read error: 104 (Connection reset by peer)) |
| 13:48:04 | korpse | what is the X5L? |
| 13:48:29 | crwl | wasn't that just a thicker model with larger battery? |
| 13:48:51 | korpse | not a clue |
| 13:49:00 | korpse | that could easily be right though |
| 13:49:09 | korpse | is the M5 an older model? |
| 13:50:05 | korpse | crwl: looks as though that is the case |
| 13:53:32 | XavierGr | anyone that knows rockbox thread internals? |
| 13:53:45 | B4gder | why? |
| 13:54:05 | XavierGr | I am trying to set up a tsr plugin that will benchmark the battery. |
| 13:54:22 | ep0ch | m5 is in fact a newer model |
| 13:54:29 | ep0ch | with less features |
| 13:54:33 | XavierGr | I am on something but it is buggy and I can tell its response, cause my lack of knowledge on the matter |
| 13:54:49 | korpse | ep0ch: ah, thank you |
| 13:55:03 | XavierGr | ^^can't tell its response |
| 13:55:10 | B4gder | XavierGr: what's your question about the threads then? |
| 13:55:18 | ep0ch | and yeah X5L just has a bigger battery if i recall |
| 13:55:59 | XavierGr | ok I call a thread after I have set the stack with rb->create_thread and get the id |
| 13:56:33 | XavierGr | will that run the thread code? or do I have to call the function with the treah explicitly? |
| 13:58:04 | B4gder | create_thread() adds a new thread to the chain |
| 13:58:05 | korpse | does the iAudio's AC adapter do 110-240v? or should i look for a replacement adapter locally? |
| 13:58:40 | B4gder | korpse: I don't think you should expect very detailed iAudio knowledge in here |
| 13:59:00 | XavierGr | Bagder: and one of the arguments is the threads name (a function) will it run the code too, or do I have to call the function? |
| 13:59:35 | korpse | B4gder: just thought maybe someone owned one |
| 13:59:41 | B4gder | XavierGr: no, it adds that thread to the list of threads and then it will be run in the round-robin fashion all threads are run |
| 14:00 |
| 14:00:09 | korpse | B4gder: i know this isn't #audioplayerreviews or whatever, you guys just seem more knowledgeable than anybody else i could ask :) |
| 14:00:16 | B4gder | :-) |
| 14:00:27 | B4gder | korpse: I'm just saying, I might be proved wrong |
| 14:00:39 | korpse | heh |
| 14:00:50 | XavierGr | hmm got it and what rb->plugin_tsr exaclty does? |
| 14:01:38 | B4gder | registers a callback |
| 14:02:01 | B4gder | that will be called when another plugin wants the memory |
| 14:02:16 | B4gder | since only one plugin can be run at a single moment |
| 14:03:18 | XavierGr | so when a user has started a tsr plugin and then chooses another one, rb->plugin_tsr will run? |
| 14:03:34 | B4gder | the function you set with plugin_tsr() will be run, yes |
| 14:03:44 | XavierGr | interesting |
| 14:04:12 | XavierGr | and what if the user selects the tsr plugin that was previously started? |
| 14:04:21 | B4gder | it makes no difference |
| 14:04:41 | XavierGr | (e.g. selects alpine_cdc and the selects it again) |
| 14:04:52 | B4gder | if a plugin is started when a tsr is running, that callback is run before the new plugin is loaded |
| 14:05:16 | XavierGr | so it will just call the tsr function and end the thread? |
| 14:05:54 | B4gder | no |
| 14:06:02 | B4gder | it will call the function |
| 14:06:03 | XavierGr | or whatever we program in plugintsr( function) |
| 14:06:03 | B4gder | period |
| 14:06:08 | XavierGr | yes |
| 14:06:19 | XavierGr | now I understand |
| 14:06:19 | B4gder | the ending of thread or whatever is made in the function itself |
| 14:06:34 | XavierGr | yes that's what I meant |
| 14:06:34 | B4gder | all this is clearly visible in the alpine_cdc plugin |
| 14:07:04 | XavierGr | well... not so clear for my inexperianced eyes :( |
| 14:07:12 | XavierGr | but thanks anyway! |
| 14:07:19 | B4gder | although I believe it bugs... |
| 14:07:24 | XavierGr | now I have a more clear view of it |
| 14:07:38 | B4gder | no, I take that back |
| 14:07:48 | XavierGr | what that plugin is for anyway? |
| 14:08:01 | B4gder | its for a cd changer emulation |
| 14:08:47 | XavierGr | emulate what exactly, why someone would want this? |
| 14:10:08 | linuxstb | I'm guessing that it is to interface an Archos device running Rockbox with an in-car CD player. I'm sure hardware modifications are needed. |
| 14:10:39 | XavierGr | that's what I thought but that sounds too specific |
| 14:10:43 | B4gder | "This is a feasibility study for Archos emulating an Alpine M-Bus CD changer." |
| 14:10:51 | B4gder | this is all mentioned in the source |
| 14:11:21 | linuxstb | You're right, it is very specific. But it doesn't do any harm to have it in the standard Rockbox. |
| 14:11:24 | B4gder | "You need to make an adapter with an 8-pin DIN plug for the radio..." |
| 14:11:49 | B4gder | and it serves as a good example on how to write a tsr |
| 14:12:05 | B4gder | as it is the only one afaik |
| 14:12:08 | XavierGr | it is the only tsr plugin right? |
| 14:12:54 | XavierGr | rockbox == endless possibilities! :D |
| 14:13:39 | | Join einhirn_ [0] (i=Miranda@139.174.4.145) |
| 14:14:21 | | Quit DJDD_ ("Trillian (http://www.ceruleanstudios.com") |
| 14:17:19 | | Quit einhirn (Read error: 113 (No route to host)) |
| 14:19:15 | | Join DJDD [0] (n=DJDD@220-245-186-182.static.tpgi.com.au) |
| 14:32:16 | preglow | now let's see what we can see |
| 14:32:32 | ep0ch | you got it already? |
| 14:32:41 | preglow | yeps |
| 14:32:45 | ep0ch | :) |
| 14:32:49 | preglow | there's a mac shop ten minutes from here |
| 14:33:00 | preglow | entering mac shops is like entering a new bloody dimension |
| 14:33:01 | ep0ch | you've opened it up before even pressing play havent you :D |
| 14:33:17 | preglow | where everything is sleek and everyone are constantly fascinated at what new things the prophet has conjured up |
| 14:33:24 | ep0ch | heh |
| 14:33:33 | Zagor | it's not a shop, it's a church |
| 14:33:39 | ep0ch | ha |
| 14:33:42 | preglow | the guy selling it to me insisted i had a look at this new program mac had just released |
| 14:33:52 | preglow | work must be a blast to him |
| 14:34:00 | preglow | s/mac/apple/ |
| 14:35:06 | preglow | bloody horrid packaging |
| 14:35:53 | preglow | i think i like this thing |
| 14:36:17 | preglow | it has the scroll wheel |
| 14:36:19 | preglow | works just fine |
| 14:36:57 | ep0ch | well, hurry up and get RB working on it, i want one now :) |
| 14:37:59 | ep0ch | this will mean you have less time to optimise the codecs for ihp now :( |
| 14:38:17 | XavierGr | nooooooo |
| 14:38:29 | ep0ch | take it back take it back! |
| 14:38:53 | XavierGr | preglow: how much? |
| 14:40:39 | linuxstb | preglow: I'm going to eat now - I expect photos when I get back :) |
| 14:40:48 | preglow | haha |
| 14:40:55 | preglow | of it, or it running your bootloader? :P |
| 14:42:34 | preglow | just need to find out why it makes no sound first |
| 14:50:09 | Jungti1234 | haaa.. |
| 14:54:03 | | Quit ashridah ("Leaving") |
| 14:56:04 | *** | Saving seen data "./dancer.seen" |
| 14:56:20 | markun | preglow: is it broken or did you get sound now? |
| 14:56:26 | preglow | got sound |
| 14:56:49 | preglow | sound level is a bit weak for my tastes, but nothing major |
| 14:57:06 | markun | The quality is ok? |
| 14:57:13 | preglow | yeah, i think it's perfectly decent |
| 14:57:21 | preglow | but it badly needs some charge, i see |
| 14:57:33 | linuxstb | preglow: I think I read that Apple artificially limit the volume in their EU models. |
| 14:57:43 | preglow | linuxstb: then hip hooray |
| 14:57:54 | preglow | for that shall be fixed |
| 14:58:19 | preglow | linuxstb: i'll just give it some charge, then boot to linux and see what's up |
| 15:00 |
| 15:02:58 | linuxstb | preglow: I can't see any differences in the IPL source between the normal 4G ATA driver and the Nano ATA driver - but you will be the first person to run it.... |
| 15:09:25 | preglow | linuxstb: we'll see |
| 15:09:37 | XavierGr | wow the tsr plugin procedure works indeed, I just made a void thread (starts and exits)... now what should I write inside the thread....? |
| 15:09:52 | preglow | if the ipl guys haven't broken an ipod yet, so i wont be the first |
| 15:09:53 | XavierGr | but better take some sleep first. |
| 15:09:54 | preglow | i hope |
| 15:09:54 | preglow | heh |
| 15:11:55 | korpse | how does one upgrade the firmware on an iAudio? |
| 15:12:20 | | Quit DJDD (Read error: 110 (Connection timed out)) |
| 15:12:26 | ep0ch | rtfm |
| 15:12:29 | preglow | linuxstb: ipod has no partition type on the boot part? |
| 15:13:01 | linuxstb | SPAM WARNING: Han Soloo has registered on the Wiki. |
| 15:13:09 | preglow | yeah, i noticed |
| 15:13:39 | linuxstb | preglow: That's right, it's type 0 (zero). |
| 15:13:40 | preglow | boot part of eighty megs, seems a bit hefty |
| 15:13:57 | linuxstb | If you change it to any other type, your iPod won't work any more. |
| 15:14:04 | preglow | can i change that if i feel adventurous? |
| 15:14:06 | linuxstb | As I discovered... |
| 15:14:49 | linuxstb | preglow: I'm sure you can. I would suggest doing a "dd if=/dev/sda | gzip -9 > mynano.bin.gz" to backup the whole drive. |
| 15:15:07 | preglow | >This is your Apple iPod. You probably do not want to boot from it! |
| 15:15:07 | preglow | haha |
| 15:15:08 | linuxstb | You should then be able to restore it just by dumping that back. |
| 15:15:13 | preglow | nice message in the mbr |
| 15:17:12 | Jungti1234 | korpse: http://ihome.iaudio.com/iaudio_board/zeroboard/zboard.php?id=C08&page=1&sn1=&divpage=1&bmenu=iAUDIO&category=71&sn=off&ss=on&sc=on&select_arrange=headnum&bmenu=iAUDIO&desc=asc&no=113&bmenu=iAUDIO |
| 15:17:39 | linuxstb | preglow: Are you about to test the bootloader? |
| 15:17:48 | preglow | linuxstb: still backing up |
| 15:17:59 | preglow | but yes, that's next |
| 15:21:08 | korpse | Jungti1234: thanks, i must've missed it when i was looking |
| 15:22:43 | linuxstb | Has our Wiki been taken down by a nice webmaster or by a nasty spammer? |
| 15:23:12 | Jungti1234 | korpse: english- http://eng.iaudio.com/zeroboard/view.php?id=B15&page=1&sn1=&divpage=1&bmenu=support&sn=off&ss=on&sc=on&select_arrange=headnum&bmenu=support&desc=asc&no=83 |
| 15:23:12 | B4gder | taken down? |
| 15:23:19 | linuxstb | It appears unavailable.... |
| 15:23:35 | linuxstb | Sorry - it's back now... |
| 15:23:58 | B4gder | I'm trying to figure out why our deny of hansolo's IP address doesn't work properly |
| 15:24:32 | linuxstb | So he/she is repeatedly using the same IP address? |
| 15:24:53 | B4gder | right now at least he's using the same IP we deny in the general site |
| 15:25:35 | B4gder | 85.95.169.158 |
| 15:25:56 | preglow | my, gzip is slow |
| 15:26:01 | B4gder | russia |
| 15:27:07 | | Join _FireFly_ [0] (n=FireFly@p54A45A83.dip.t-dialin.net) |
| 15:28:30 | preglow | i can't connect to ipl cvs |
| 15:28:31 | preglow | lovely |
| 15:28:47 | linuxstb | Sourceforge.... |
| 15:28:54 | linuxstb | Do you want anything in particular? |
| 15:29:02 | preglow | make_fw, nothing much else |
| 15:29:06 | | Join uncledrax [0] (n=uncledra@ppp115-181.static.internode.on.net) |
| 15:29:39 | Jungti1234 | How many people is Korean who take part in H100 project? |
| 15:29:54 | linuxstb | http://www.davechapman.f2s.com/rockbox/make_fw.c |
| 15:30:35 | B4gder | Jungti1234: exactly zero |
| 15:31:15 | B4gder | maybe we should offer those ipl guys to host their cvs? B-] |
| 15:32:32 | B4gder | okay, I believe I've blocked HanSolo slightly better now |
| 15:32:52 | B4gder | I guess future will tell how well I've managed |
| 15:35:49 | preglow | linuxstb: i get a bad gen error on the last make_fw line |
| 15:35:53 | preglow | in the wiki |
| 15:36:06 | Zagor | B4gder: or how many other IPs he's got :-) |
| 15:36:18 | B4gder | yes, funny! |
| 15:36:21 | B4gder | :-/ |
| 15:38:21 | | Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-133-199.pools.arcor-ip.net) |
| 15:39:43 | uncledrax | yay, ipod rockbox!!! damn, i only have a mini 2nd gen. guess ill go out and get a nano :) |
| 15:39:59 | preglow | linuxstb: i replaced -g 3 with -g nano |
| 15:40:05 | preglow | linuxstb: would that be a fatal mistake? :/ |
| 15:43:05 | linuxstb | preglow: That should be fine. My mistake - they recently changed that make_fw.c option |
| 15:43:30 | preglow | ok, then i'm good to go now |
| 15:43:38 | preglow | and btw, how do i make the ipod stop displaying Do not disconnect? |
| 15:43:54 | preglow | does it even matter? |
| 15:45:59 | preglow | pumounting the partition did not help |
| 15:46:46 | korpse | who is hansolo? |
| 15:47:15 | preglow | some spammar |
| 15:47:18 | preglow | spammEr |
| 15:47:25 | preglow | i probably need some modprobe command here, no? |
| 15:48:36 | korpse | ah alright |
| 15:49:21 | Zagor | preglow: sounds like some windows/apple special hoo-daa. just yank the cable if you have unmounted. |
| 15:49:22 | preglow | insmod, i mean |
| 15:49:45 | preglow | some ipodlinux pages does insmod -r on the firewire driver |
| 15:50:00 | preglow | sure, why not |
| 15:50:20 | _FireFly_ | preglow: rmmod should also do it to remove a module :) |
| 15:50:26 | Zagor | linux does not disable device drivers while the device is connected |
| 15:51:40 | Zagor | also insmod -r is quite difficult if it's compiled-in... :-) |
| 15:51:45 | Jungti1234 | Is no there a person who is developing here unicode rockbox? |
| 15:51:53 | _FireFly_ | afaik you can't deactivate a single device if you have several devices connected which uses the same driver |
| 15:51:57 | _FireFly_ | under linux |
| 15:52:02 | preglow | ok, nothing much happened at all |
| 15:52:02 | _FireFly_ | Zagor: :) |
| 15:52:15 | preglow | i see the apple logo for some seconds, then the apple firmware boots |
| 15:52:18 | _FireFly_ | preglow: simple unplug the device after unmounting |
| 15:52:18 | preglow | i must have done something wrong |
| 15:52:30 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 15:52:30 | * | Jungti1234 ´ÔÀÌ ºÎÀçÁß¿¡¼ µ¹¾Æ¿À¼Ì½À´Ï´Ù.(wait) |
| 15:53:35 | Zagor | Jungti1234: Frank (phaedrus961) committed an update to the unicode patch yesterday |
| 15:54:01 | Jungti1234 | Did you complete? |
| 15:54:37 | Zagor | sorry, not committed. submitted, to the patch tracker. |
| 15:55:02 | Jungti1234 | Is no there a person in seat? |
| 15:55:15 | Zagor | in seat? you mean here in the channel? |
| 15:55:32 | Jungti1234 | here |
| 15:55:49 | Jungti1234 | A person who can talk now. |
| 15:55:49 | Zagor | i guess not, since nobody answered. |
| 15:56:08 | Jungti1234 | Thank answer. |
| 15:56:23 | | Quit ep0ch (Read error: 104 (Connection reset by peer)) |
| 15:56:34 | Zagor | Jungti1234: you need to sign up for evening classes in english :-) |
| 15:56:52 | Jungti1234 | yes.. |
| 15:57:20 | linuxstb | preglow: Yes, just unplug the ipod when you have finished. The "do not disconnect" message will then disappear. |
| 15:57:22 | preglow | no, i can't get this bootloader to work at all |
| 15:57:26 | Jungti1234 | English does not really. |
| 15:57:28 | preglow | all i see is the apple logo |
| 15:57:32 | preglow | then the original firmware |
| 15:57:41 | Jungti1234 | So difficult. |
| 15:58:08 | linuxstb | preglow: Try extending the usleep command in bootloader/ipod.c - change it to 15000000 (15 seconds). Maybe the bootloader is running, but not displaying anything on the LCD. |
| 15:58:30 | linuxstb | It's currently set to 5000000 (5 seconds). |
| 15:59:51 | preglow | linuxstb: does it reboot when i unplug usb? |
| 16:00 |
| 16:01:16 | linuxstb | It should do, yes. |
| 16:02:45 | preglow | linuxstb: yup, what you said is correct |
| 16:02:49 | preglow | linuxstb: doens't display shit |
| 16:04:05 | | Join Febs [0] (n=40be24f0@labb.contactor.se) |
| 16:08:58 | Zagor | open it! open it! |
| 16:09:01 | preglow | haha |
| 16:09:07 | preglow | you can't open these without breaking them in two |
| 16:09:24 | Zagor | perhaps there are enough photos on the net already |
| 16:09:40 | preglow | i think so, but that still doesn't help me |
| 16:09:49 | preglow | i think the nicer thing to do is just check out the ipl sources, heh |
| 16:13:44 | Febs | Can someone with more technical ability than me take a quick look at this revised FAQ and let me know if I accurately captured what Linus has reported over the last few days? |
| 16:13:46 | Jungti1234 | Do not you become Hangul input support in unicode rock box? |
| 16:13:46 | Febs | http://www.rockbox.org/twiki/bin/view/Main/IriverFAQ#Will_Rockbox_be_released_for_the |
| 16:18:12 | preglow | brb |
| 16:18:17 | Jungti1234 | http://jungti1234.netcci.net/iriver/h100/DSCN2088.jpg - Can you reference this picture? |
| 16:20:32 | Jungti1234 | Can no one answer? |
| 16:22:52 | Jungti1234 | good night |
| 16:22:59 | Jungti1234 | see you next time |
| 16:23:44 | | Part Jungti1234 |
| 16:23:53 | | Join ryanpg [0] (n=ryanpg@c-24-13-248-42.hsd1.il.comcast.net) |
| 16:25:51 | ryanpg | hi all... rockbox looks awesome, as an owner of an iaudio M5 I'm hoping for a succesful port, any hackers here know if the M5 is on the list for support? I'm unsure how much it differs from the X5 or M3 which are both mentioned on rockbox.org |
| 16:26:39 | B4gder | well, there's no work on any of them atm |
| 16:27:34 | ryanpg | oh... that didn't come across from reading the webpage |
| 16:27:55 | ryanpg | btw, all the M3 image links broke here -> http://www.rockbox.org/twiki/bin/view/Main/IaudioM3Info |
| 16:28:07 | B4gder | feel free to fix |
| 16:28:17 | B4gder | we had a wiki breakdown a while ago |
| 16:28:23 | B4gder | we still suffer from it |
| 16:29:47 | ryanpg | hmm... purchasing an M3, scanning pics... seems like a bit much for me to tackle right now |
| 16:30:14 | ryanpg | oh well, good luck all |
| 16:30:18 | | Part ryanpg ("Leaving") |
| 16:34:19 | linuxstb | preglow: Sorry, I'm busy working at the moment. But you're saying the bootloader is running, but the LCD doesn't change? |
| 16:34:34 | linuxstb | Does the bootloader at least turn the backlight on? |
| 16:56:07 | *** | Saving seen data "./dancer.seen" |
| 16:56:52 | preglow | seems to |
| 16:57:11 | | Join LinusN [0] (n=linus@labb.contactor.se) |
| 16:58:49 | preglow | but i think the apple one did that as well |
| 16:59:21 | linuxstb | But if it turns it on before the 15 second delay, then that's a good sign. |
| 16:59:28 | preglow | oh yes |
| 16:59:29 | preglow | long before |
| 16:59:36 | linuxstb | Then the bootloader is doing it. |
| 16:59:47 | preglow | what happens is, i see the apple logo |
| 16:59:50 | preglow | then backlight turns on |
| 16:59:53 | preglow | then delay |
| 17:00 |
| 17:00:11 | preglow | takes about a sec before backlight turn son |
| 17:00:51 | linuxstb | The flash firmware displays the apple logo (without backlight), then reads the contents of the boot partition into RAM, and then jumps to the entry point to transfer control to the program loaded from the boot partition. |
| 17:01:04 | linuxstb | i.e. the rockbox bootloader. |
| 17:05:23 | preglow | i'll have a look and see if i see something obvious |
| 17:06:51 | | Quit uncledrax (Read error: 104 (Connection reset by peer)) |
| 17:08:36 | linuxstb | I've just compared the IPL code and the Rockbox code, and can't see anything obvious. It _should_ work. |
| 17:09:15 | preglow | /* iPodLinux doesn't appear have any LCD init code for the Nano */ |
| 17:09:17 | preglow | :-) |
| 17:09:23 | linuxstb | It's true :) |
| 17:09:25 | preglow | perhaps it's just well hidden? |
| 17:09:25 | preglow | heh |
| 17:09:39 | linuxstb | Have you got a copy of the IPL cvs yet? |
| 17:09:44 | preglow | anywho, shouldn't it be init by the apple firmware loader anyway |
| 17:09:45 | preglow | ? |
| 17:09:51 | Rick | er |
| 17:09:56 | Rick | doesn't the nano like, not have an LCD? |
| 17:10:03 | Rick | or am I think of that other one |
| 17:10:04 | linuxstb | preglow: Yes, you would think so. |
| 17:10:06 | preglow | Rick: shuffle |
| 17:10:09 | LinusN | that's the shufflöe |
| 17:10:09 | Rick | ahhh |
| 17:10:21 | Rick | oh right, nano is the tiny scratchable one |
| 17:10:25 | linuxstb | That's completely different, and iPodLinux have ignored it. |
| 17:10:26 | Rick | :< |
| 17:10:40 | Rick | havn't been following players much lately |
| 17:10:53 | linuxstb | I'm sure the shuffle would benefit from a voice UI though.... |
| 17:11:10 | LinusN | you tend to ignore the rest of the market when you have a rockbox player |
| 17:11:28 | Rick | I havn't updated rockbox in like 5 months so I wouldn't say that either :P |
| 17:11:38 | * | Rick hides |
| 17:11:48 | B4gder | bad Rick, baaaad baaaad Rick |
| 17:11:56 | preglow | shame! shame! |
| 17:12:03 | LinusN | boooooh |
| 17:12:25 | _FireFly_ | but "never touch a running system" ;) |
| 17:12:27 | Rick | my player will probably be gathering dust for another 2 months until next semester :P |
| 17:12:37 | linuxstb | preglow: The IPL kernel framebuffer driver: http://www.davechapman.f2s.com/rockbox/fb.c |
| 17:13:05 | preglow | still can't login to cvs |
| 17:13:05 | preglow | gah |
| 17:13:08 | Rick | eww, mixed code formatting, evile |
| 17:13:18 | * | Rick grins |
| 17:13:42 | Rick | looks neat though |
| 17:13:53 | linuxstb | preglow: The Nano is identified by ipod_hw_ver==0xc in that code. |
| 17:14:01 | preglow | yes, figured |
| 17:14:10 | Febs | You know, all of the Mistic River H300 fanboys are despondent enough about the fact that the new iPod plays video ... |
| 17:14:23 | Febs | if you get Rockbox running on an iPod before the H300 it could send them over the edge. |
| 17:14:25 | preglow | and better than h3x0 ever will |
| 17:14:40 | preglow | it already _is_ running better on ipod than h3x0 :P |
| 17:14:46 | preglow | that will last up until linus finishes the bootloader |
| 17:15:02 | linuxstb | preglow: Looking in init_lcd(), there is no code executed for the nano.... 0x6 is my ipod - the color/photo |
| 17:16:04 | preglow | so i see |
| 17:16:06 | preglow | hmm |
| 17:16:14 | preglow | perhaps i should try the ipodlinux bootloader just for kicks |
| 17:16:27 | preglow | this would be greatly facilitated by being able to use cvs |
| 17:16:32 | linuxstb | The ipodlinux bootloader doesn't display anything. |
| 17:16:34 | Rick | er |
| 17:16:41 | Rick | the nano's lcd is bigger than the standard and mini lcds? |
| 17:16:44 | linuxstb | But you could try booting the kernel - that will display console messages. |
| 17:17:06 | preglow | linuxstb: your bootloader is able to do that currently, yes? |
| 17:17:19 | linuxstb | The Rockbox bootloader will load the kernel for you - find a linux.bin, put it on your FAT32 partition and enable it in my bootloader |
| 17:17:38 | linuxstb | preglow: Yes - you need to change a #if 0 to enable it. |
| 17:18:25 | linuxstb | Get a kernel here: http://ipodlinux.org/builds/ |
| 17:18:37 | linuxstb | Get the very newest one, obviously. |
| 17:22:25 | | Join mashalla [0] (n=5498ba9b@labb.contactor.se) |
| 17:22:57 | preglow | ok |
| 17:23:00 | preglow | ipodlinux runs |
| 17:23:04 | preglow | up until it panics |
| 17:23:17 | linuxstb | Using my bootloader? |
| 17:23:20 | preglow | yup |
| 17:23:29 | linuxstb | Cool - that confirms the ATA driver is working. |
| 17:23:32 | preglow | indeed |
| 17:24:02 | preglow | can one get decent protective cases for these things? |
| 17:24:09 | preglow | it doesn't surprise me if it scratches quickly |
| 17:25:09 | linuxstb | preglow: I've found the stupid mistake :) |
| 17:25:30 | linuxstb | CONFIG_LCD is wrong in config-ipodnano.h |
| 17:25:47 | preglow | hmm |
| 17:25:53 | preglow | i just need to remove ipodlinux now |
| 17:25:59 | preglow | doesn't seem to me that disk mode works |
| 17:26:41 | | Quit einhirn_ ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 17:28:04 | linuxstb | preglow: It should be fixed in CVS now. |
| 17:28:13 | linuxstb | Have you got it in disk mode yet? |
| 17:28:16 | preglow | no |
| 17:28:25 | linuxstb | Does the reboot work? |
| 17:28:39 | preglow | yes, sure |
| 17:28:45 | preglow | but the menu and play thing doesn't |
| 17:28:53 | linuxstb | Maybe it's different for the Nano... |
| 17:29:09 | preglow | let's just hope the mechanism exists |
| 17:29:11 | preglow | if not, i'm fucked |
| 17:29:45 | linuxstb | http://playlistmag.com/weblogs/todayatplaylist/2005/09/hiddengoodies/index.php - scroll down to "nano and Button combinations" |
| 17:30:10 | preglow | kind of hard to make a booting linux look like a manufacturer error ;) |
| 17:30:27 | linuxstb | It should be select+play - not menu and play |
| 17:30:35 | linuxstb | What did I write on the wiki? |
| 17:30:47 | preglow | menu and aply |
| 17:30:57 | linuxstb | My mistake again then... |
| 17:30:59 | preglow | works |
| 17:31:01 | preglow | :) |
| 17:31:18 | preglow | had me worried for a sec there, heh |
| 17:31:28 | linuxstb | If you update the firmware directory from CVS, rebuild the bootloader and reinstall, it should work.... |
| 17:31:33 | preglow | will |
| 17:32:34 | preglow | linuxstb: ok, it works, but the picture is very garbled |
| 17:32:54 | preglow | i think i can see what's wrong, though |
| 17:33:11 | linuxstb | It the text OK, or is that garbled as well? |
| 17:33:17 | preglow | everything |
| 17:33:26 | preglow | and the graphics stops 4/5 at the side of the screen |
| 17:33:33 | preglow | and it seems like the drawing overflows onto the next line |
| 17:33:45 | preglow | so i guess you've just got erronous line lengths somewhere |
| 17:36:37 | _FireFly_ | can i assume, if the target has no BITMAP-lcd that there is no remote ?? |
| 17:36:47 | B4gder | no |
| 17:37:00 | _FireFly_ | k |
| 17:37:43 | B4gder | if you want a remote with lcd, check HAVE_REMOTE_LCD |
| 17:39:57 | _FireFly_ | hmm it seams that the dimension of the remote-lcd is on all target(which has an remote width lcd) the same |
| 17:40:19 | B4gder | right now, yes |
| 17:40:42 | _FireFly_ | k |
| 17:41:07 | B4gder | LCD_REMOTE_WIDTH x LCD_REMOTE_HEIGHT |
| 17:41:09 | _FireFly_ | then can i use my created default wps for all remote-lcd |
| 17:42:10 | | Quit B4gder ("time to say moo") |
| 17:43:03 | _FireFly_ | but i can assume that if HAVE_BITMAP_LCD is set that then the remote has also an lcd |
| 17:47:47 | | Join Mongey| [0] (n=mongeyc@83-70-48-4.b-ras1.dbn.dublin.eircom.net) |
| 17:48:35 | Mongey| | anyone here |
| 17:48:48 | preglow | perhaps |
| 17:49:22 | Mongey| | i better leave if thers not |
| 17:49:27 | Mongey| | :D |
| 17:50:01 | Mongey| | anyway |
| 17:50:13 | Mongey| | LinusN; are you on |
| 17:50:28 | preglow | if you'v got someting to ask, just ask it |
| 17:50:33 | preglow | you've, yes |
| 17:51:07 | Mongey| | no just here to concradulat linus on his h300 work |
| 17:51:51 | Mongey| | well i do have 1 question |
| 17:52:01 | linuxstb | preglow: Any ideas about your LCD? |
| 17:52:29 | * | Mongey| is burning a suse iso now |
| 17:52:48 | preglow | linuxstb: looking through code now |
| 17:53:15 | linuxstb | There are obviously two potential problems - the writing into lcd_framebuffer and the lcd_update() function. You could try writing a pattern into lcd_framebuffer to see if that gets displayed properly. |
| 17:58:04 | | Part mashalla |
| 17:59:39 | | Join mashalla [0] (i=mashalla@p5498BA9B.dip.t-dialin.net) |
| 18:00 |
| 18:00:35 | preglow | hmm |
| 18:00:36 | preglow | weird |
| 18:02:34 | Mongey| | well thats one cd wasted |
| 18:02:58 | _FireFly_ | Mongey|: ?? |
| 18:05:03 | linuxstb | preglow: What is weird? |
| 18:05:24 | preglow | i'm trying to see a pattern in how it draws wrong |
| 18:06:09 | Mongey| | i was trying to burn a live cd thing of linux; Suse and i did it wrong cause i dont know what to do |
| 18:06:17 | preglow | first, the entire display seems to be shifted |
| 18:06:36 | preglow | i try to write at position zero, and the pixel appears in the middle of the screen |
| 18:07:03 | _FireFly_ | funny ;) |
| 18:07:14 | preglow | and the position overflows, when i try to write a straight vertical line, there are several lines spaced by several pixels |
| 18:07:44 | preglow | about 1/4 of the right part of the screen is missing |
| 18:07:46 | linuxstb | How are you drawing? Don't use the build-in lcd_???? functions. |
| 18:07:59 | preglow | linuxstb: i write directly to the framebuffer |
| 18:08:40 | preglow | for (i = 0; i < LCD_HEIGHT; ++i) { lcd_framebuffer[i][0] = 0xff; lcd_framebuffer[i][1] = 0xff; } |
| 18:08:43 | preglow | then update |
| 18:08:48 | Mongey| | Anyone know what ive to burn on for the live cd |
| 18:08:53 | | Nick ender1 is now known as ender` (i=ychat@84.52.165.220) |
| 18:09:00 | preglow | i shouldn't use update? |
| 18:09:31 | linuxstb | Yes - use lcd_update(). But most of the other functions are not implemented yet. Only the ones used by the font rendering |
| 18:09:45 | preglow | figured that |
| 18:09:55 | Mongey| | gtg |
| 18:09:59 | preglow | i see what i do is correct, but the stride and offset seems to be completely off the bat |
| 18:09:59 | Mongey| | good bye |
| 18:10:19 | Mongey| | \quit |
| 18:10:27 | Mongey| | \leave |
| 18:10:32 | _FireFly_ | wrong slash ;) |
| 18:10:34 | preglow | /quit |
| 18:10:35 | preglow | heh |
| 18:10:36 | | Part Mongey| |
| 18:11:14 | | Quit Febs ("CGI:IRC (EOF)") |
| 18:11:47 | | Join Febs [0] (n=40be24f0@labb.contactor.se) |
| 18:11:59 | linuxstb | Does lcd_clear_display() followed by lcd_update() display correctly? You should get a screen full of blue. |
| 18:12:31 | preglow | entire screen is init to blue before i start drawing at least |
| 18:13:47 | _FireFly_ | btw. about slash and back-slash http://www.techtales.com/ttales0705.html#tale41 ;) |
| 18:16:07 | linuxstb | This could be related to the old problem I used to have where the screen would be corrupted for no apparent reason. Changing unrelated code in the bootloader would fix it. |
| 18:16:36 | linuxstb | I suddenly stopped experiencing this, but I never did find out the real reason. |
| 18:17:00 | linuxstb | I think I talked about it here a few weeks ago. |
| 18:17:01 | preglow | you don't remember the nature of the corruption? |
| 18:17:37 | linuxstb | Rows of pixels seemed to be duplicated - i.e. displaying in their proper position, and then again about 4 rows further down. |
| 18:18:23 | preglow | this might perhaps look like that |
| 18:18:34 | preglow | i would take a photo, but i'm in linux, and my camera needs a windows program :/ |
| 18:18:43 | linuxstb | gphoto2 ? |
| 18:19:00 | linuxstb | Is it debian? |
| 18:19:07 | preglow | ubuntu |
| 18:19:19 | preglow | but my camera uses some proprietary transfer stuff |
| 18:19:45 | preglow | well, there you go |
| 18:19:48 | preglow | it supports my camera :P |
| 18:19:50 | linuxstb | Just try making the bootloader do different things - comment out some of the lcd_puts and sprintf lines. |
| 18:22:49 | preglow | hahah |
| 18:22:51 | preglow | excellent |
| 18:22:54 | preglow | gphoto2 works like a charm |
| 18:22:59 | _FireFly_ | :) |
| 18:24:14 | preglow | http://www.pvv.org/~thomj/rockbox/00001.jpg |
| 18:24:49 | _FireFly_ | nice ;) |
| 18:24:54 | linuxstb | That looks very different to my corruption though. |
| 18:25:23 | korpse | nice one, preglow |
| 18:25:29 | preglow | nice and nice... |
| 18:25:39 | preglow | would be nicer with a couple of intelligeble logos |
| 18:25:40 | linuxstb | Weird that only about 3/4 of the width contains anything. |
| 18:26:12 | | Quit ender` (Read error: 104 (Connection reset by peer)) |
| 18:26:13 | _FireFly_ | maybe the framebuffer doesn't cover the whole screen-width |
| 18:26:18 | preglow | it does |
| 18:26:58 | _FireFly_ | it doesn't seams that :) |
| 18:26:59 | korpse | there is some shape |
| 18:27:02 | linuxstb | Can you compare the update() functions in fb.c from IPL and in Rockbox. Hopefully the mistake is there. |
| 18:27:14 | preglow | try some other stuff first |
| 18:27:24 | preglow | ipl update does the same thing for photo and nano |
| 18:27:33 | preglow | so i don't see why it shouldn't work for me if it works for you |
| 18:28:02 | linuxstb | That's assuming that lcd_type is correctly set to 1 (it should be). You could try manually setting lcd_type=1 somewhere in lcd-16bit.c |
| 18:28:07 | preglow | i tried that |
| 18:28:09 | preglow | didn't work |
| 18:28:26 | preglow | in the code where you set lcd_type, i just edited all the lines to say lcd_type = 1 |
| 18:28:27 | _FireFly_ | is the screen-width of the photo bigger or the same as the nano ?? |
| 18:28:47 | linuxstb | preglow: But I think that code is only compiled for the color/photo |
| 18:28:55 | preglow | right |
| 18:29:03 | _FireFly_ | or the 1/4 smaller ?? |
| 18:29:06 | preglow | in that case lcd_type should be set to 1 anyway |
| 18:29:15 | linuxstb | _should be_ |
| 18:29:47 | linuxstb | _FireFly_: From memory, color/photo is 220x176, the Nano is 176x132 |
| 18:31:48 | preglow | hmmm |
| 18:31:49 | preglow | ok |
| 18:32:06 | preglow | i drew a line from x = 0 to x = max |
| 18:32:08 | preglow | at h = 0 |
| 18:32:14 | preglow | just a small bit of it appeared |
| 18:32:28 | | Join justsomeperson [0] (n=92a9198c@labb.contactor.se) |
| 18:34:00 | _FireFly_ | why are these function doesn't "exported" through playback.h although these function are used in wps ?? |
| 18:34:01 | _FireFly_ | void audio_next_dir(void); |
| 18:34:01 | _FireFly_ | void audio_prev_dir(void); |
| 18:34:30 | _FireFly_ | has it somethinng to do with thw code-size ? |
| 18:36:02 | linuxstb | preglow: I think I've found the problem again. |
| 18:36:14 | preglow | spill it |
| 18:36:33 | linuxstb | Look in fb.c - the ipod_update_photo() function. |
| 18:37:00 | linuxstb | The code to calculate the drawing region is different for the Nano - but I didn't copy that code. |
| 18:37:15 | preglow | haha |
| 18:37:16 | preglow | small wonder, then |
| 18:37:18 | preglow | i'll deal with it |
| 18:37:42 | preglow | of course |
| 18:37:56 | preglow | this has to be it |
| 18:38:00 | preglow | explains the error just nicely |
| 18:38:03 | linuxstb | hehe |
| 18:38:18 | linuxstb | Let me just check the rest of that function. |
| 18:39:22 | linuxstb | Yes - there's another check later in that function for ipod_hw_ver==0x6 which I've removed. |
| 18:39:49 | linuxstb | You should remove the line "rect2=rect4;" for Nano builds. |
| 18:40:19 | linuxstb | But that's it - two places. |
| 18:43:19 | _FireFly_ | gonna to eat something |
| 18:43:31 | | Join ender` [0] (i=ychat@84.52.165.220) |
| 18:48:04 | linuxstb | preglow: Any luck? |
| 18:48:06 | preglow | i swear, this usb plug feels like it's going to die on me tomorrow |
| 18:52:21 | preglow | http://www.pvv.org/~thomj/rockbox/wee.jpg |
| 18:52:38 | linuxstb | :) |
| 18:52:51 | linuxstb | A nice sight. |
| 18:53:00 | preglow | i'll commit the changes |
| 18:56:10 | *** | Saving seen data "./dancer.seen" |
| 18:57:59 | linuxstb | preglow: That should be LCD_IPODCOLOR.... |
| 18:58:09 | preglow | :-) |
| 18:58:20 | preglow | i forgot to even verify that, haha |
| 18:58:25 | | Join Mindship-02 [0] (n=personal@62-221-202-178.dsl.fiberworld.nl) |
| 18:58:27 | preglow | i'll fix |
| 18:59:04 | Mindship-02 | Is there a list of features and requests? And can I send in one? |
| 18:59:24 | linuxstb | http://www.rockbox.org - check the menu links on the left side of the screen. |
| 19:00 |
| 19:00:08 | Mindship-02 | linuxstb: sorry, I feel so stupid, I just didn't see it! |
| 19:00:08 | Mindship-02 | Can Rockbox record, and can it record from the radio? |
| 19:00:18 | linuxstb | Yes and Yes. |
| 19:00:33 | linuxstb | But on the iriver, the recording is still experiemental. |
| 19:00:50 | | Join hardeep [0] (n=hardeep@c-67-188-108-180.hsd1.ca.comcast.net) |
| 19:01:15 | Mindship-02 | ah, okay |
| 19:01:41 | Mindship-02 | the whole Rockbox idea is quite perfect |
| 19:01:54 | hardeep | TiMiD: around? |
| 19:01:56 | _FireFly_ | what about my question about the two functions any comments ?? |
| 19:02:14 | Mindship-02 | is it developped purely by educated programmers or too by hobby-ing people? |
| 19:02:33 | linuxstb | Most people are both. |
| 19:02:38 | _FireFly_ | :) |
| 19:03:13 | linuxstb | But we all do it for fun in our spare time. |
| 19:03:40 | TiMiD | hardeep: yes ? |
| 19:03:50 | _FireFly_ | i'm currently studying "Informatik" computer-science :) |
| 19:04:30 | Mindship-02 | Is anyone working on request 955078? I want to have boot.info (text file containing my name and adress) to be showed on boot... |
| 19:04:57 | Mindship-02 | Since I have this device two more persons bought it. I want everyone to know which one is mine... |
| 19:05:01 | hardeep | _FireFly_: Yeah, that's not correct. Both those functions should be in audio.h just like audio_next_track() |
| 19:05:22 | hardeep | TiMiD: Are you working on porting the playlist viewer to the new guilist? |
| 19:05:44 | _FireFly_ | yepp he does |
| 19:05:45 | _FireFly_ | ;) |
| 19:05:47 | hardeep | TiMiD: I was going to look into it but didn't want to duplicate the work if you're already working on it =) |
| 19:05:53 | _FireFly_ | afaik |
| 19:05:58 | linuxstb | Mindship-02: I don't think so. On the iriver, changing the bootloader is very dangerous - so it's not likely to have any "luxury" features like that one. |
| 19:06:00 | TiMiD | I'm doing it yes |
| 19:06:05 | hardeep | okay, cool |
| 19:06:09 | TiMiD | are you the one who wrote the code ? |
| 19:06:14 | TiMiD | the initial code ? |
| 19:06:15 | hardeep | yeah |
| 19:06:21 | TiMiD | owwww |
| 19:06:31 | hardeep | ? |
| 19:06:50 | preglow | dinnertime |
| 19:06:52 | TiMiD | Just that I have some problems to understant exactly how it works ... |
| 19:07:15 | Mindship-02 | linuxstb: is it dangerous to compile the bootloader? somewhere the Rockbox splash must be coded in! |
| 19:07:41 | LinusN | the splash isn't in the boot loader |
| 19:07:46 | TiMiD | why to store 2 lists in the same array for example (If I understand correctly) |
| 19:07:47 | hardeep | TiMiD: anything I can help with? |
| 19:08:03 | hardeep | 2 lists? |
| 19:08:16 | Mindship-02 | LinusN: so what about the words of linuxstb? |
| 19:08:25 | linuxstb | Mindship-02: Ignore my answer. The Rockbox splash is displayed by Rockbox itself, not the bootloader. So yes, in theory that screen could be easily changed to display anything. |
| 19:08:35 | linuxstb | Mindship-02: I was wrong. |
| 19:08:51 | TiMiD | I mean the first_index |
| 19:09:05 | Mindship-02 | ah, now it went from "not likely" to "easily"! |
| 19:09:06 | TiMiD | mut maybe I didn't understood it at all |
| 19:09:21 | hardeep | do you mean the first index versus first display index? |
| 19:09:54 | TiMiD | no |
| 19:10:04 | TiMiD | just the first index |
| 19:10:08 | linuxstb | Mindship-02: But it still needs a developer to do it, and it might not be considered an acceptable patch for general Rockbox use. |
| 19:10:13 | TiMiD | I don't understand at all :/ |
| 19:10:54 | Mindship-02 | linuxstb: how are you with your time, feel like guiding (teaching) me with this little project? :-P |
| 19:10:55 | hardeep | the first index in the viewer is used to identify the first entry in the playlist that's currently loaded in the viewer |
| 19:11:10 | _FireFly_ | hardeep: i have moved the two function definition to audio.h i |
| 19:11:16 | hardeep | the viewer doesn't load the entire playlist to save memory |
| 19:11:40 | TiMiD | and the rest of the playlist is stored where ? |
| 19:11:42 | hardeep | whenever we go beyond the first or end index, we load more information |
| 19:11:43 | _FireFly_ | so i have a problem less to worry about it by my try to make a wps-widget ;) |
| 19:11:53 | linuxstb | Mindship-02: Feel free to ask questions here. Most of the time somebody will answer. |
| 19:12:06 | hardeep | we get all the info from the playlist code (playlist.c) |
| 19:12:25 | LinusN | Mindship-02: begin with setting up a development environment |
| 19:12:53 | Mindship-02 | LinusN: any example DevEnv-s? |
| 19:13:03 | hardeep | however, the actual track names are stored on disk and we only read on demand (the playlist code saves the seek point in it's table) |
| 19:13:21 | LinusN | Mindship-02: http://www.rockbox.org/twiki/bin/view/Main/DevelopmentGuide |
| 19:13:42 | TiMiD | so each time you move inside your list, you read from disk oO |
| 19:14:00 | TiMiD | or is the entire playlist loaded into memory ? |
| 19:14:03 | hardeep | each time you go beyond what's loaded |
| 19:14:08 | TiMiD | ok |
| 19:14:15 | TiMiD | I understand |
| 19:14:23 | hardeep | we limit the amount we load to a max of 200 entries or when the buffer is full |
| 19:14:47 | TiMiD | I wouldn't have understood that by myself :) |
| 19:14:51 | * | amiconn appears, reading up logs... |
| 19:14:57 | Mindship-02 | LinusN: Thanks for the link, I'll study that first! :-) |
| 19:15:02 | hardeep | on the archos devices we don't have enough memory to cache all the playlist track names in memory |
| 19:15:18 | hardeep | on the iriver it may be possible |
| 19:15:21 | TiMiD | I wrote some code, it seems to work, excepted for some things like remove :/ |
| 19:15:52 | hardeep | what happens with remove? |
| 19:16:10 | TiMiD | strange things :) |
| 19:16:14 | hardeep | to the viewer, remove is just a call to the playlist code to remove the file... after which we just need to update the display |
| 19:16:25 | TiMiD | to remove the file ? |
| 19:16:33 | hardeep | from the playlist |
| 19:16:36 | TiMiD | I thought it was just to remove the entry in the playlist |
| 19:16:37 | hardeep | playlist_remove() |
| 19:16:40 | TiMiD | ok |
| 19:16:54 | hardeep | sorry, yeah, that's what it does |
| 19:17:08 | amiconn | hardeep: I'd rather not cache all names in memory even on iriver |
| 19:18:06 | TiMiD | if it's your code you could perhaps do it with my list :) |
| 19:18:06 | | Quit Febs ("CGI:IRC (EOF)") |
| 19:18:18 | | Join Febbs [0] (n=40be24f0@labb.contactor.se) |
| 19:18:47 | TiMiD | since I have some problems to understand your code :/ |
| 19:19:00 | hardeep | amiconn: i like it the way it is too... i just saw some people complaining about the disk access on the viewer |
| 19:19:28 | amiconn | Think of a 20000-entry playlist with 100+ chars per entry |
| 19:19:38 | amiconn | > 2 MB |
| 19:19:41 | hardeep | TiMiD: heh, i guess my documentation isn't good enough =) |
| 19:19:46 | TiMiD | also there is a load_playlist_entries and load_playlist_entries_r |
| 19:20:07 | hardeep | TiMiD: yeah, one loads from the top down and the other from the bottom up |
| 19:20:15 | hardeep | depending on which way we're moving |
| 19:20:18 | | Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU) |
| 19:20:22 | TiMiD | you could have done it in one fn no ? |
| 19:20:36 | TiMiD | just loading from pos-200 or pos |
| 19:21:07 | hardeep | except if we are unable to load 200 tracks |
| 19:21:16 | hardeep | say the buffer can only hold 100 |
| 19:21:22 | hardeep | it depends on the size of the track names |
| 19:21:52 | _FireFly_ | maybe this kind of offset could be calculated |
| 19:21:56 | TiMiD | more complicated than I expected |
| 19:22:26 | hardeep | _FireFly_: not without actually reading the track names =) |
| 19:22:29 | | Quit Mindship-02 ("shutdown") |
| 19:22:31 | _FireFly_ | ok |
| 19:23:26 | TiMiD | I will try to do it now since I have more informations |
| 19:23:27 | _FireFly_ | but how do you get the right parameter for the two function?? |
| 19:24:21 | hardeep | which two functions? |
| 19:24:33 | _FireFly_ | load_playlist_entries and load_playlist_entries_r ;) |
| 19:25:18 | hardeep | if you're scrolling down the list then we use load_playlist_entries() and pass the first track currently displayed |
| 19:25:36 | hardeep | if you're scrolling up then we use load_playlist_entries_r() and use the last track currently being displayed |
| 19:25:46 | _FireFly_ | maybe we could join these two function to one with two parameters the secend could tell the function if the value of the first parameter gives the start index or the end index |
| 19:27:05 | hardeep | it's possible to join the two together, it just seemed easier to keep them separate |
| 19:27:24 | amiconn | Maybe a parameter that indicates the search direction? |
| 19:27:34 | _FireFly_ | that was my secend parameter ;) |
| 19:27:35 | TiMiD | I think I will rewrite some code here since now there isn't drawings, some fn looks a little useless |
| 19:37:43 | preglow | oh well |
| 19:37:51 | preglow | linuxstb: what's next on your list+ |
| 19:39:26 | linuxstb | A proper interrupt-driven button driver and also implementing current_tick via a timer interrupt. |
| 19:39:32 | linuxstb | i.e. interrupts :) |
| 19:39:50 | linuxstb | But this is something I'm not very familiar with. |
| 19:40:48 | linuxstb | The other big jobs before Rockbox itself is anywhere near bootable is thread context switching and writing the startup code for crt0.S |
| 19:41:24 | linuxstb | Once those are working, Rockbox should be close to working. |
| 19:43:00 | preglow | thread context switching should be pretty easy |
| 19:43:02 | linuxstb | There is some basic button detection code in the ipodlinux bootloader, but when I tried it a while ago, it wasn't very reliable at detecting a keypress on startup. |
| 19:43:22 | linuxstb | The button driver from the kernel is the place to take the code from. |
| 19:43:42 | linuxstb | How is your knowledge of ARM assembler? |
| 19:44:17 | linuxstb | There should hopefully be a #warning in all the places we need to write code. |
| 19:45:19 | preglow | my knowledge of arm assembler is ok, but far from complete |
| 19:45:26 | preglow | hoping to improve, though |
| 19:48:54 | linuxstb | My knowledge is still almost zero. |
| 19:51:22 | linuxstb | Do you have any plans? |
| 19:53:16 | preglow | nope |
| 19:53:20 | preglow | whatever needs to be done |
| 19:53:39 | preglow | that is, i plan to test ipl, if that's possible |
| 19:55:37 | linuxstb | Good luck with ipl. Back later. |
| 19:55:41 | | Quit linuxstb ("Client Exiting") |
| 20:00 |
| 20:01:00 | preglow | bah |
| 20:01:03 | preglow | need to partition |
| 20:01:09 | preglow | well, i'm not jumping through hoops for it yet |
| 20:01:30 | _FireFly_ | :) |
| 20:01:55 | hardeep | bbl |
| 20:02:01 | | Quit hardeep (" Like VS.net's GUI? Then try HydraIRC -> http://www.hydrairc.com <-") |
| 20:03:02 | | Quit justsomeperson ("CGI:IRC") |
| 20:08:19 | preglow | my, is this thing thin |
| 20:08:32 | | Join arkascha [0] (n=arkascha@xdsl-213-168-108-151.netcologne.de) |
| 20:09:46 | _FireFly_ | ;) |
| 20:10:13 | | Part LinusN |
| 20:28:29 | amiconn | _FireFly_: You can't assume whether the remote has an lcd or not based on what the main lcd is |
| 20:29:24 | amiconn | The archos remote has no lcd, and is usable for both the player (charcell main lcd) and recorder v1 (bitmap lcd) |
| 20:31:34 | _FireFly_ | k but the code for the remote standard wps have i ifdefed with checking NB_SCREENS = 2 so in this case i can assume that the lcd in the remote is a bitmap one ;) |
| 20:32:01 | _FireFly_ | because my search on the <target>-config.h showed me that when a remote-lcd exist then it is a bitmap one |
| 20:36:11 | amiconn | I would use #ifdef HAVE_REMOTE_LCD |
| 20:36:27 | amiconn | But yes, all (current) remote lcds are bitmapped |
| 20:37:11 | amiconn | In fact there is only one remote lcd type so far, so there is no CONFIG_REMOTE_LCD |
| 20:40:48 | Febbs | preglow: as predicted, the fanboy hysteria begins: http://www.misticriver.net/showthread.php?t=12991&page=42 (post 1651) |
| 20:40:57 | | Nick Febbs is now known as Febs (n=40be24f0@labb.contactor.se) |
| 20:41:28 | | Join hardeep [0] (i=hardeeps@norge.freeshell.ORG) |
| 20:42:50 | amiconn | preglow: Congrats for your successful ipod nano bootloader run |
| 20:44:48 | HCl | ipod nano bootloader |
| 20:44:50 | HCl | wow i missed a lot |
| 20:44:51 | HCl | xD |
| 20:49:59 | TiMiD | _FireFly_: just use NB_SCREENS since it could be set to 1 even with remote plugged for debug purpose for example |
| 20:51:04 | _FireFly_ | yepp i use it :) |
| 20:53:49 | _FireFly_ | i have it mostly done the widget :) |
| 20:55:24 | preglow | amiconn: all credits go out to linuxstb for that one |
| 20:56:12 | amiconn | TiMiD: I found a way how to make the binary smaller on all platforms where NB_SCREENS == 1 |
| 20:56:14 | *** | Saving seen data "./dancer.seen" |
| 20:56:31 | TiMiD | #ifdef instead of for ? |
| 20:57:44 | amiconn | Using #ifdefs everywhere will probably be rather ugly, I have a better suggestion instead :) |
| 20:58:00 | preglow | Febs: what post would that be? i can't find any numbering |
| 20:58:29 | amiconn | A macro like FOR_ALL_SCREENS(i) , i.e. taking the loop variable as an argument. |
| 20:58:41 | amiconn | For NB_SCREENS > 1, it would expand to: |
| 20:58:53 | amiconn | for (i = 0; i < NB_SCREENS; i++) |
| 20:59:12 | amiconn | but when NB_SCREENS == 1, it would simply expand to: |
| 20:59:16 | amiconn | i = 0; |
| 20:59:35 | amiconn | Simple and elegant, imho |
| 21:00 |
| 21:01:18 | amiconn | I tried this replacement (manually) in one single place - it saved 48 bytes on archos. |
| 21:01:42 | amiconn | Now, how many occurences of for (i = 0; i < NB_SCREENS; i++) are there in your code? :) |
| 21:04:36 | _FireFly_ | i think many ;) |
| 21:06:49 | Febs | preglow: it's the last post in that thread. There is no actual hysteria yet, but give it time ... |
| 21:07:37 | Febs | Whoops. Now second-to-last, by djray. |
| 21:09:24 | | Quit Febs ("CGI:IRC") |
| 21:09:39 | | Join Febs [0] (n=40be24f0@labb.contactor.se) |
| 21:12:51 | * | Febs must learn not to hit the "back" button while using the web-based IRC client. |
| 21:13:42 | _FireFly_ | ;) |
| 21:19:40 | | Quit Mxm`Pas`Bien (Read error: 110 (Connection timed out)) |
| 21:19:41 | TiMiD | pretty good :) |
| 21:19:52 | TiMiD | the macro idea |
| 21:32:32 | | Join Acksaw [0] (i=Acksaw@spc1-stok5-4-0-cust5.bagu.broadband.ntl.com) |
| 21:33:57 | preglow | haha |
| 21:36:07 | amiconn | haha? |
| 21:36:16 | korpse | 'acksaw |
| 21:37:58 | | Join RotAtoR [0] (n=e@12-210-82-91.client.insightBB.com) |
| 21:38:53 | amiconn | TiMiD: grep tells me this for() occurs 30 times. I want those 1440 bytes back :) |
| 21:39:36 | amiconn | TiMiD: Do you want me have a go at it? |
| 21:40:52 | amiconn | Better call it FOR_NB_SCREENS(i) |
| 21:41:21 | hardeep | i'm surprised the compiler doesn't catch this |
| 21:41:35 | amiconn | yeah |
| 21:43:08 | | Quit bbad ("KVIrc 3.2.0 'Realia'") |
| 21:44:28 | XavierGr | hardeep: I was the one that made the suggestion. I said that having in mind that if the dircache is <400kb then a playlist can't be that big. Also you metnion that 200 entries are stored on ram, in my test yesterady I remember disk activity every time I entered the playlist viewer... |
| 21:44:51 | | Join manuPsi [0] (n=poupet@84.5.54.169) |
| 21:45:21 | XavierGr | also yesterday I intentionally made my player to play as long as it could reaching a 2.73V level, isn't that exhasting for the battery? |
| 21:45:36 | XavierGr | what is the limit for li-ion? |
| 21:45:45 | hardeep | XavierGr: Yeah, that happens because we need to read the playlist to get the tracknames |
| 21:45:56 | | Part manuPsi |
| 21:46:37 | XavierGr | so unless we get to the viewer nothing is stored on ram, right? |
| 21:46:44 | hardeep | right |
| 21:46:55 | hardeep | and it's cleared as soon as we exit the viewer |
| 21:47:11 | hardeep | (we share the buffer with the plugins) |
| 21:47:20 | XavierGr | oh... |
| 21:47:58 | XavierGr | that could be a problem if I tried to change that for my self. |
| 21:49:22 | hardeep | yeah =) the purpose of the 200-track cache in the viewer is just to avoid constantly accessing the disk while in the viewer. there's no global place where track names are stored in memory except when you're playing from disk |
| 21:49:55 | hardeep | i guess we could try and use the in_ram buffer for caching as much as we can |
| 21:50:42 | XavierGr | that would be very good IMHO, I think that rockbox should ty to prevent any sort of disk activity more than once |
| 21:51:04 | XavierGr | but if this trend continues I can understand that we will run out of buffer for theaudio |
| 21:51:31 | XavierGr | at least it is safe and doable for targets that have large ram. |
| 21:52:18 | | Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) |
| 21:55:12 | Acksaw | im off |
| 21:55:15 | Acksaw | see ya guys later |
| 21:55:51 | | Quit Acksaw () |
| 22:00 |
| 22:00:31 | | Quit Kohlrabi (Nick collision from services.) |
| 22:00:34 | | Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-128-235.pools.arcor-ip.net) |
| 22:01:32 | * | ehntoo is back |
| 22:02:55 | amiconn | hardeep: Hmm, some questions and thoughts: |
| 22:04:00 | amiconn | (1) If the playlist viewer uses the plugin ram to buffer track names, would it be possible to just extend the maximum line count in the buffer? The plugin buffer is 768KB instead of 32KB |
| 22:04:05 | amiconn | ...on iriver |
| 22:05:24 | amiconn | (2) Does the playlist viewer pfn_tsr_callback() before using the buffer? Otherwise rockbox might crash badly if a tsr plugin is active and the playlist viewer is called |
| 22:06:01 | amiconn | pfn_tsr_exit() I mean |
| 22:07:28 | | Join Maxime [0] (n=flemmard@fbx.flemmard.net) |
| 22:08:27 | | Join linuxstb [0] (n=5343d4aa@labb.contactor.se) |
| 22:11:03 | hardeep | amiconn: 1. yeah, this is definitely doable. I'm going to look into this |
| 22:11:44 | hardeep | 2. didn't know about this. will fix this |
| 22:17:18 | hardeep | for 2, i guess we'll need to add a new api to the plugin code to force a tsr to exit |
| 22:22:48 | amiconn | That's exactly what this callback is for |
| 22:23:25 | amiconn | A tsr plugin calls plugin_tsr() to register this callback before returning |
| 22:23:39 | amiconn | The plugin loader calls it before loading a new plugin |
| 22:24:31 | amiconn | This mechanism was implemented by [IDC]Dragon. I'm sure he would have added this handling to the playlist viewer code as well - if he would have known that the playlist viewer reuses the plugin buffer |
| 22:24:58 | amiconn | I didn't know this as well until today... |
| 22:25:35 | amiconn | TiMiD? |
| 22:30:27 | hardeep | yeah, the playlist viewer is the only non-plugin that makes use of the plugin buffer so it's easy to miss |
| 22:30:57 | XavierGr | why not change that? |
| 22:31:10 | XavierGr | why not use the same memory as the dircache? |
| 22:31:22 | hardeep | a couple of reasons |
| 22:31:29 | hardeep | 1. there is no dircache on the archos devices |
| 22:31:46 | hardeep | 2. this would overwrite the dircache |
| 22:31:55 | hardeep | actually, maybe 2 isn't an issue |
| 22:32:03 | XavierGr | 1 is an issue though |
| 22:32:10 | hardeep | yup |
| 22:32:17 | amiconn | 3. the dircache can be disabled |
| 22:32:40 | XavierGr | how much memory is the plugin buffer for archos ? |
| 22:33:06 | | Join Febbs [0] (n=40be24f0@labb.contactor.se) |
| 22:33:06 | | Quit Febs ("CGI:IRC (EOF)") |
| 22:33:10 | | Join Philip_0729 [0] (n=Philip_0@user-722.lns4-c7.dsl.pol.co.uk) |
| 22:33:15 | hardeep | amiconn: are there any tsr plugins currently? |
| 22:33:21 | preglow | i wonder if we should deal with this ipod clickwheel thing |
| 22:33:29 | * | Febbs STILL needs to learn not to hit the back button when using the web IRC client. |
| 22:33:31 | amiconn | Yes, exactly one, and only for archos so far |
| 22:33:37 | hardeep | which one? |
| 22:33:41 | | Nick Febbs is now known as Febs (n=40be24f0@labb.contactor.se) |
| 22:33:43 | amiconn | [IDC]Dragon's alpine_cdc |
| 22:33:56 | XavierGr | alpine-cdc |
| 22:34:15 | hardeep | ah, okay |
| 22:34:17 | amiconn | Perhaps we'll have battery_log soon |
| 22:34:21 | | Quit _FireFly_ ("Leaving") |
| 22:34:25 | XavierGr | I am just prepearing another one for battery benchmarks, though I don't know if Ican manage to finish it |
| 22:34:43 | XavierGr | amiconn: are you working on it? |
| 22:34:52 | amiconn | But thinking about it this would mean that using the playlist viewer would stop battery logging |
| 22:35:03 | XavierGr | yes indeed. |
| 22:35:24 | XavierGr | but anyway if a true benchmark is done the playlist viewer shouldn't be loaded. |
| 22:35:44 | XavierGr | (by the user) |
| 22:35:45 | amiconn | XavierGr: Not yet, but it should be quite easy, perhaps except the part that monitors disk activity and takes the chance to flush the log when the disk is spinning |
| 22:35:59 | XavierGr | yes that my concern |
| 22:36:10 | XavierGr | today I manged to set the thread correctly |
| 22:36:12 | hardeep | actually, instead of killing the tsr, we just need to make sure the plugin buffer size doesn't get reset to 0 |
| 22:36:12 | amiconn | I also did some tsr experiments in the past |
| 22:36:29 | XavierGr | but right now the thread is empty and I need to think something for it |
| 22:36:36 | hardeep | then the playlist viewer will only be using the buffer not being used by the tsr |
| 22:36:42 | amiconn | ...logging thread round-trip to get an idea how fast rockbox thread scheduling is, and other things |
| 22:37:14 | amiconn | hardeep: Ah yes, that sounds like a good option. |
| 22:37:29 | amiconn | tsr plugins should usually be small |
| 22:37:38 | | Join _FireFly_ [0] (n=FireFly@p54A45A83.dip.t-dialin.net) |
| 22:37:47 | XavierGr | so are you working this right now, or soon, because if you do then I will have to drop my tries on that? |
| 22:38:07 | amiconn | Right now I'm going to try my FOR_NB_SCREENS macro idea |
| 22:38:14 | amiconn | Shouldn't take long... |
| 22:38:24 | XavierGr | I am no match for you, though I still do it to learn more on programming and rockbox internals |
| 22:38:30 | * | amiconn starts reading gcc docs on macros |
| 22:41:48 | linuxstb | amiconn: I like your macro idea, but don't you think it obfuscates the code a little? |
| 22:41:58 | | Quit arkascha ("Konversation terminated!") |
| 22:43:06 | amiconn | What else would you suggest? |
| 22:44:41 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
| 22:45:01 | Philip_0729 | Hi everyone :), just read recent CVS and noticed some activety with H300 |
| 22:46:39 | preglow | yes, linus was on the prowl yesterday |
| 22:47:06 | | Quit _FireFly_ ("Leaving") |
| 22:49:18 | Philip_0729 | do we have a more accurate idea of when it will be ready for us less-technically minded ?? |
| 22:49:37 | preglow | nope |
| 22:49:49 | preglow | when he finishes the bootloader, things should happen pretty quickly |
| 22:49:55 | Philip_0729 | cool |
| 22:50:07 | Philip_0729 | but its close now? |
| 22:50:57 | preglow | i have no idea |
| 22:51:01 | preglow | don't hold your breath |
| 22:51:04 | preglow | linus has a lot on his plate |
| 22:51:20 | Philip_0729 | needs a bigger plate..... |
| 22:51:33 | preglow | i think he feels he's got a plate big enough |
| 22:51:56 | preglow | but if you've got some way of extending his day beyond 24 hours, he might want to talk to you about that |
| 22:52:13 | Philip_0729 | well there is this one thing..... |
| 22:52:13 | preglow | i would too, as a matter of fact |
| 22:52:22 | Philip_0729 | but nah |
| 22:52:29 | Philip_0729 | i'll just wait |
| 22:52:33 | preglow | i can't code on speed :> |
| 22:52:40 | linuxstb | amiconn: I have no better suggestion, just something to think about. Maybe the meaning of the macro will be obvious when it is seen in context. |
| 22:53:22 | Philip_0729 | i just can't code.. :( |
| 22:53:26 | amiconn | Okay I just did it. The real gain is a little less than expected, 896 bytes on archos |
| 22:53:48 | amiconn | It doesn't look very obfuscated to me just an arbitrary example: |
| 22:53:58 | amiconn | FOR_NB_SCREENS(i) |
| 22:53:58 | amiconn | { |
| 22:53:58 | amiconn | gui_textarea_clear(&screens[i]); |
| 22:53:58 | DBUG | Enqueued KICK amiconn |
| 22:53:58 | amiconn | } |
| 22:55:03 | | Quit dpassen1 (Read error: 110 (Connection timed out)) |
| 22:56:07 | preglow | sounds decent |
| 22:56:20 | preglow | can't think of a better solution than that |
| 22:56:21 | *** | Saving seen data "./dancer.seen" |
| 22:56:21 | linuxstb | The only alternative would be to include NB_SCREENS as a parameter - e.g. FOR_LOOP(i,NB_SCREENS) but I think I prefer your version. |
| 22:56:54 | amiconn | Hmm, in fact that's a good idea too |
| 22:57:23 | amiconn | It would allow to automatically strip single-cycle for loops |
| 22:57:42 | linuxstb | Or FOR_LOOP(i,0,NB_SCREENS) |
| 22:57:43 | amiconn | *arbitrary single-cycle for loops |
| 22:57:49 | amiconn | yes |
| 22:58:29 | amiconn | hmm |
| 22:58:54 | amiconn | The question is where such a universal macro should reside |
| 22:59:11 | | Join _FireFly_ [0] (n=FireFly@p54A45A83.dip.t-dialin.net) |
| 23:00 |
| 23:01:33 | | Join Midgey34 [0] (n=Midgey34@c-67-172-68-52.hsd1.mi.comcast.net) |
| 23:01:35 | Bagder | gosh, a new codec |
| 23:01:55 | preglow | wut? |
| 23:02:01 | linuxstb | wut? |
| 23:02:03 | Bagder | patch tracker |
| 23:02:06 | Bagder | shorten |
| 23:02:14 | linuxstb | Mmm. Seeking hell |
| 23:02:17 | Bagder | rockbox-Patches-1352575 |
| 23:02:18 | linuxstb | But a nice addition. |
| 23:02:40 | linuxstb | I hope they chose a decoder with a compatible license. |
| 23:02:49 | Bagder | "from the ffmpeg project" |
| 23:02:55 | linuxstb | Perfect. |
| 23:03:00 | linuxstb | LGPL IIRC |
| 23:03:10 | Bagder | cool |
| 23:04:07 | preglow | so, who'll deal with that patch? |
| 23:04:25 | linuxstb | I'm happy to. |
| 23:04:26 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 23:04:26 | * | Bagder steps backwards and whistles |
| 23:04:39 | preglow | linuxstb: btw, have you got any reports on doing dealing with ipods through cygwin dd? |
| 23:04:50 | XavierGr | which patch is it I can't find that number? |
| 23:05:00 | preglow | XavierGr: the patches page isn't updated yet |
| 23:05:06 | XavierGr | oh |
| 23:05:07 | linuxstb | preglow: No. All I know is what amiconn told me the other day. |
| 23:05:18 | XavierGr | which codec? |
| 23:05:21 | preglow | XavierGr: shorten |
| 23:05:24 | preglow | XavierGr: lossless thingie |
| 23:05:26 | XavierGr | ? |
| 23:05:31 | XavierGr | never heard of it |
| 23:05:35 | preglow | well, i have |
| 23:05:37 | preglow | well |
| 23:05:37 | Bagder | http://sourceforge.net/tracker/index.php?func=detail&aid=1352575&group_id=44306&atid=439120 |
| 23:05:41 | preglow | the more the merrier, if you ask me |
| 23:05:48 | XavierGr | of course |
| 23:05:54 | | Quit DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 23:06:07 | * | XavierGr wonders when someone will start midi coding again! :) |
| 23:06:46 | amiconn | preglow: I know cygwin dd is working well, I used that several times to make images of the Ondio flash disk for analysis |
| 23:06:59 | preglow | amiconn: how do i determine device names? |
| 23:07:15 | ender` | isn't shorten kinda like zip - inefficient, it's missing many features modern formats have (tagging), but it's sticking around because everybody else (well, at least among traders) uses it? |
| 23:07:30 | preglow | ender`: probably |
| 23:07:52 | linuxstb | Yes, a perfect description of shorten. |
| 23:08:20 | linuxstb | I download quite a lot of shorten files, but I always immediately convert them to flac and delete the originals. |
| 23:08:57 | preglow | linuxstb: any thoughts on how we're going to deal with the ipod buttons? |
| 23:09:29 | preglow | just pretend an increment in wheel position means left or right button press? |
| 23:09:54 | amiconn | preglow: Open "computer management", go to the "device manager" In the lower main pane, all disk and cd-rom devices are listed |
| 23:10:08 | amiconn | Each disk device has a number associated with it. |
| 23:10:38 | amiconn | Device 0 equals /dev/sda in cygwin, device 1 equals /dev/sdb etc. |
| 23:11:02 | preglow | ahh, right |
| 23:11:05 | _FireFly_ | argh my wps widget crashes rb on target but not in the sim |
| 23:11:09 | amiconn | I'm not 100% sure about the windows names, german windows here |
| 23:11:44 | preglow | i wonder if they've got an equivalent of ssh-agent on windows |
| 23:11:53 | amiconn | yes |
| 23:11:58 | preglow | the thing i love the most about developing on another box, is all the passwords |
| 23:12:01 | amiconn | I used that with sf cvs |
| 23:12:39 | preglow | cygwin component? |
| 23:12:40 | _FireFly_ | preglow: you can use the pagent from putty |
| 23:12:41 | amiconn | cygwin does have the ssh agent |
| 23:12:49 | preglow | _FireFly_: i tried that once, and it flaming didn't work |
| 23:13:02 | preglow | it used some kind of wise-ass key format |
| 23:13:04 | Bagder | cygwin has openssh and its tools |
| 23:13:17 | _FireFly_ | you must convert the ssh-private key to putty-key |
| 23:13:21 | preglow | or perhaps i should just start developing with linux |
| 23:13:23 | _FireFly_ | that it works |
| 23:13:29 | XavierGr | _FireFly_: It is usually the other way around for me |
| 23:13:37 | XavierGr | Sim crashes targets go on... |
| 23:13:43 | _FireFly_ | ?? |
| 23:14:20 | amiconn | XavierGr: I'm not sure whether tsr plugins will work in the sim. Nobody tried that so far |
| 23:14:21 | XavierGr | I mean when I test my stuff... |
| 23:14:49 | XavierGr | amiconn and emoty thread that just exits works like a charm |
| 23:15:00 | _FireFly_ | i think I0C is a segmentation fault am i right ?? |
| 23:15:06 | linuxstb | preglow: The keypad is going to be interesting. If we keep the scrollwheel functionality, then we only have up/down (or left/right - but not at the same time), and the MENU/NEXT/PREV/PLAY keys |
| 23:15:13 | XavierGr | but in my previous attempt a while loop will run for some time and then eventually crash |
| 23:15:22 | XavierGr | but maybe I have something wrong there. |
| 23:15:25 | amiconn | A thread function should never ever exit the normal way |
| 23:15:39 | amiconn | This will confuse the rockbox scheduler |
| 23:15:51 | XavierGr | yes this was a test to see what made the sim crash |
| 23:15:51 | preglow | linuxstb: i think we need to define another set of keys |
| 23:15:58 | preglow | linuxstb: just called BUTTON_INC, BUTTON_DEC or something |
| 23:16:21 | preglow | linuxstb: which every key handler can handle as fits best to the context |
| 23:16:58 | preglow | and we can alias those onto existing keys for platforms that don't have them, so we don't waste any space on those |
| 23:17:03 | linuxstb | Sounds good. |
| 23:17:20 | XavierGr | amiconn: actually it is a thread with a while that in the first run calls gTread.exiting and the exits the thread. |
| 23:17:21 | preglow | but i need some input from gurus on this, i really have _no_ idea aboyt how these parts of rockbox work |
| 23:17:27 | preglow | linuxstb: i think i should also be able to handle threading |
| 23:18:28 | amiconn | Why invent new button definitions? Do the ipods have ordinary up/down buttons in addition to th ewheel? |
| 23:18:46 | amiconn | Otherwise the wheel could just use BUTTON_UP/BUTTON_DOWN |
| 23:19:12 | amiconn | It would be possible to use different names, but this will mean more #ifdefs in the code |
| 23:19:12 | preglow | amiconn: no |
| 23:19:31 | preglow | amiconn: yes, but the wheel might mean left/right in one screen and up/down in another |
| 23:19:38 | amiconn | Yes, and? |
| 23:19:38 | preglow | amiconn: it depends on context what they should mean |
| 23:19:53 | amiconn | BUTTON_LEFT/BUTTON_RIGHT would be undefined |
| 23:20:03 | preglow | riight |
| 23:20:10 | preglow | i keep forgetting this is done per platform |
| 23:20:20 | amiconn | ...and most major places use button aliases |
| 23:20:23 | preglow | but it pretty much has to |
| 23:20:24 | preglow | yes |
| 23:20:36 | amiconn | #define TREE_UP BUTTON_UP |
| 23:20:48 | amiconn | ...depending on the keypad |
| 23:21:39 | | Part Philip_0729 |
| 23:22:17 | | Quit mashalla () |
| 23:26:39 | XavierGr | actually amiconn I think you were right |
| 23:27:01 | linuxstb | I haven't tried it yet, but the Shorten patch looks good. |
| 23:28:26 | XavierGr | Sim does not accept a thread that will run together with other threads |
| 23:28:49 | XavierGr | I just test it on target and it handled quite well an the new thread. |
| 23:29:00 | XavierGr | r/an |
| 23:30:22 | amiconn | linuxstb: Hmm, it seems a general FOR_LOOP macro isn't possible :( |
| 23:31:09 | amiconn | It would require preprocessor conditionals within the macro body. Afaik this doesn't work |
| 23:32:53 | preglow | sure? |
| 23:33:05 | preglow | i think the preprocessor does several passes |
| 23:33:11 | preglow | but that might just be for macro expansion |
| 23:33:41 | Bagder | you could also simply do #ifdef define macro #else define macro #endif |
| 23:33:51 | Bagder | instead of the other way around |
| 23:34:06 | amiconn | Not for linuxstb's idea |
| 23:34:16 | Bagder | ok |
| 23:34:23 | Bagder | didn't pay attention to the details |
| 23:34:23 | amiconn | The macro body would have to depend on the macro arguments |
| 23:34:39 | amiconn | The idea was to have FOR_LOOP(a, b, c) |
| 23:35:00 | preglow | linuxstb: what do you think about just renaming it to libffmpeg? |
| 23:35:16 | amiconn | which should expand to for(a = b; a < c; a++) if c - b > 1 |
| 23:35:28 | preglow | that wont work, no |
| 23:35:32 | amiconn | and simply to a = b; if c - b == 1 |
| 23:35:48 | linuxstb | preglow: It would be nice to rename it, but it makes a mess in CVS. |
| 23:35:57 | preglow | Bagder: subversion! |
| 23:36:08 | * | Bagder ducks |
| 23:36:14 | amiconn | The simple idea works |
| 23:36:38 | amiconn | Bagder: The original idea is to reduce code size for platforms with NB_SCREENS == 1 |
| 23:37:26 | linuxstb | There is one side-effect of not running a for loop - i will be equal to 0 at the end of the loop, not equal to NB_SCREENS. |
| 23:37:29 | amiconn | I regained 896 bytes on archos recorder |
| 23:37:53 | preglow | linuxstb: i think i'll just start filling in the lcd driver blanks |
| 23:38:09 | amiconn | I think I should commit it |
| 23:38:50 | linuxstb | preglow: OK. Linus seems to be wanting to use lcd-16bit.c for the H3x0. So he suggested moving the ipod specific parts into lcd-ipod.c |
| 23:39:02 | preglow | so do i |
| 23:39:23 | linuxstb | So you could do that - it will only be 2 or 3 functions in lcd-ipod.c |
| 23:42:57 | | Quit ehntoo (Read error: 110 (Connection timed out)) |
| 23:43:24 | linuxstb | We should probably do the same with lcd-h100.c at some point. i.e. move all the generic code to lcd-2bit.c and only keep the low-level stuff in lcd-h100.c We could then quite easily add support for the 4G b/w ipods. |
| 23:44:10 | amiconn | Yes, and lcd-recorder.c could be split in lcd-1bit.c and lcd-gmini100.c |
| 23:44:31 | linuxstb | Exactly. |
| 23:44:35 | amiconn | parts of the recorder and h100 lcd code are in lcd.S though |
| 23:45:06 | linuxstb | Is that "low" or "high" level code? Or both? |
| 23:45:28 | amiconn | Very low level - the data and command transfer routines |
| 23:45:53 | amiconn | lcd.S is also used for the player |
| 23:46:22 | linuxstb | That shouldn't be a problem. Just means those LCDs require 3 files in SOURCES |
| 23:47:36 | linuxstb | This is all assuming that the framebuffers should be organised the same for all LCDs with the same bitdepth |
| 23:48:19 | preglow | i can't think why not |
| 23:48:26 | amiconn | That's not sure |
| 23:49:12 | preglow | Bagder, Zagor: thanks for letting me have an ipod, btw, appreciated! :> |
| 23:49:13 | amiconn | The 1 and 2 bit lcds we encountered so far use the same organisation, but I know that the gmini 2xx lcd controller (4bit grey) is different |
| 23:49:39 | linuxstb | But that's 4-bit - so it must be different. |
| 23:49:42 | Bagder | preglow: that thank is really to the donors, not us |
| 23:49:55 | preglow | Bagder: i know, but the planning is up to you |
| 23:50:03 | * | preglow thanks the donors |
| 23:50:12 | Bagder | we know you do lots of goodness |
| 23:50:21 | amiconn | linuxstb: Yes, but that's not what I mean. Our 1bit and 2bit lcd use pixel "line blocks", with the bytes within the block oriented vertically |
| 23:50:28 | preglow | let's hope it extends to ipod as well |
| 23:51:13 | amiconn | The gmini 2xx controller uses horizontal orientation. |
| 23:52:35 | amiconn | Otoh, the gmini 1xx uses the same orientation as the recorder, and also the h1x0 remote lcd |
| 23:53:37 | XavierGr | http://www.toshiba.co.jp/about/press/2005_09/pr1601.htm |
| 23:53:43 | XavierGr | xaxa |
| 23:54:04 | XavierGr | in some years we will hold methanol bottles instead of water... |
| 23:54:10 | linuxstb | amiconn: Yes, but so far it's not a problem. I'll try and find out what the ipod greyscale LCD is like. |
| 23:55:25 | | Join unique311 [0] (n=uniqueph@ool-457007b2.dyn.optonline.net) |
| 23:57:27 | XavierGr | wtf according to the spec a bottle of water fulled with methanol will provide 375 days of continuous usage! |
| 23:58:34 | _FireFly_ | ?? |
| 23:58:59 | linuxstb | Mmm. I'm not 100% sure, but it looks like the ipod 2-bit LCD organises data horizontally. |
icon identifies that the person is a core developer (has commit access).