| 00:00:21 | Zagor | $revision-id.zip is pretty fixed isn't it? |
| 00:00:42 | Bagder | well, for that revision yes |
| 00:00:48 | Zagor | ah you mean the last? |
| 00:00:52 | Bagder | today the urls are fixed for _all_ revisions |
| 00:01:11 | Bagder | yes, so that we can point to a url for the latest build |
| 00:01:17 | Bagder | no matter which revision it happens to be |
| 00:01:18 | Zagor | ah, we don't host more than the latest build |
| 00:01:24 | pixelma | bluebrother: we also wondered if it would be possible to have checks like in the code for LCD_WIDTH > 128 etc. in the manual to use for \opt or \nopt |
| 00:01:26 | Bagder | exactly |
| 00:01:27 | Zagor | why would we... reverting :) |
| 00:01:53 | | Quit mt (Remote closed the connection) |
| 00:02:08 | Zagor | rasher: that sounds reasonable |
| 00:02:13 | pixelma | bluebrother: and how to get the LCD_WIDTH from the c file then |
| 00:03:30 | Bagder | so is there then a grace period after each commit? |
| 00:03:37 | Bagder | that could be... annoying |
| 00:04:16 | Zagor | Bagder: do you rather think every commit should be queued and built? |
| 00:04:17 | rasher | Bagder: That's how it is now, isn't it? |
| 00:04:36 | Bagder | rasher: no, now there's just a time period between the checks |
| 00:05:00 | rasher | Bagder: That almost amounts to the same thing. |
| 00:05:05 | rasher | With some fluctuation |
| 00:05:05 | Mikachu | and if there's a lot of commits during a build, those all get grouped together (i assume) |
| 00:05:06 | Bagder | Zagor: no, that's not very good either |
| 00:05:11 | Bagder | rasher: I disagree |
| 00:05:12 | bluebrother | well, I bet it's possible though I don't think we have someone around who could do that. Had the idea of using the preprocessor for the manual as we need it for features.txt anyway, but haven't thought about details yet. |
| 00:05:28 | rasher | Bagder: How long is there between checks now? |
| 00:05:49 | Bagder | there's a sleep 60 between each check, and after a build round |
| 00:05:54 | Mikachu | wouldn't it be pretty simple to trigger it with an svn hook? |
| 00:06:02 | Bagder | yes it will |
| 00:06:08 | Mikachu | sorry, wrong tense :) |
| 00:06:14 | rasher | Bagder: So after a commit, it'll be 0-60 seconds before the build starts, in which time more commits may happen |
| 00:06:23 | Bagder | yes, but max 60 seconds no more |
| 00:06:30 | Bagder | whatever happens |
| 00:06:40 | Bagder | if it started in idle |
| 00:06:42 | rasher | I was under the impression that it waited after a commit |
| 00:06:47 | rasher | To see if more were coming |
| 00:06:49 | Bagder | it doesn't |
| 00:06:55 | Mikachu | maybe you could check if the commit is by the same person, then it's likely a hotfix commit? |
| 00:07:39 | rasher | Maybe it could just start instantly, and then check after 60 seconds if there had been more commits, and restart? |
| 00:07:42 | Mikachu | do the clients run svn up with a specific revision btw? otherwise there could be weirdness |
| 00:07:51 | Bagder | yes they do |
| 00:07:58 | | Join homielowe [0] (n=homielow@unaffiliated/homielowe) |
| 00:08:01 | rasher | That would have the same effect as the current system, but shave 0-60 seconds off the time from commit to the builds are ready |
| 00:08:03 | Bagder | they get told exactly what rev to build |
| 00:08:27 | Bagder | rasher: except the time when a few people commit with 40 seconds interval |
| 00:08:36 | | Join AndyI [0] (i=AndyI@212.14.205.32) |
| 00:08:37 | rasher | Bagder: No |
| 00:08:48 | Bagder | you said it would restart then |
| 00:08:50 | rasher | Bagder: It should only re-check 60 seconds after the build that set the ball rolling |
| 00:08:56 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 00:09:00 | Bagder | after the first commit then |
| 00:09:02 | rasher | Yes |
| 00:09:12 | Bagder | right, that's what I asked first ;-) |
| 00:09:23 | rasher | I changed my mind halfway through |
| 00:09:44 | Bagder | the only little nit against this concept is that its less simple |
| 00:10:12 | rasher | So what I'm saying now: Start instantly on commit. 60 seconds after *that* commit, see if there are more commits, and restart with that rev. |
| 00:10:19 | rasher | This is true. |
| 00:10:59 | kugel | why not just start on any commit (with the post-commit hook) (restart of a build round is going)? |
| 00:11:26 | Bagder | so if we're in a commit craze it'll just not complete a round? |
| 00:11:29 | rasher | kugel: because that could end up postponing the result if people keep committing every 59 seconds |
| 00:11:35 | gevaerts | Why not just try to get as many clients as possible so the round is done in 60 seconds? ;) |
| 00:11:45 | * | AlexP preps his atom |
| 00:12:05 | Bagder | because we can still only hand out full builds |
| 00:12:11 | Mikachu | does arm-gcc run on rockbox yet? everyone could hook up their daps to the build system! |
| 00:12:21 | | Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) |
| 00:12:31 | gevaerts | Mikachu: we want to make the builds *faster*! |
| 00:12:34 | Zagor | rasher: is that really a big problem? we rarely get long bursts of every-minute commits |
| 00:12:36 | Mikachu | ;) |
| 00:13:00 | kugel | I actually can't remember such a rage, except funman's recently |
| 00:13:05 | rasher | Zagor: It might not be worth it if it's much more complicated |
| 00:13:09 | kugel | but that was 5s between each commit |
| 00:13:20 | Bagder | Zagor: but honestly we also rarely get "follow-up" commits just afterwards that are strictly related |
| 00:13:32 | Zagor | I think "restart if new commit within 60 seconds of previous" is the simplest way |
| 00:13:41 | kugel | We tell people to watch the build table after each commit, so it will calm down automagically :P |
| 00:13:43 | Bagder | I think not |
| 00:13:48 | * | gevaerts would just let the build complete |
| 00:13:51 | Bagder | me too |
| 00:13:55 | Zagor | Bagder: silly typos hopefully come in within 60 seconds |
| 00:14:03 | Bagder | I still don't like that |
| 00:14:04 | Zagor | gevaerts: so what about the new commit? |
| 00:14:26 | gevaerts | Zagor: it gets scheduled after the current build is done |
| 00:14:33 | Bagder | after the build round, if there are queud builds, build the newest one |
| 00:14:39 | Zagor | so we build each and every commit then |
| 00:14:45 | Bagder | I think not |
| 00:14:47 | Zagor | Bagder: ah ok |
| 00:14:56 | kugel | gevaerts: so that we have to wait 30min after a commit rage? |
| 00:14:57 | gevaerts | For two-commit bursts, yes. For longer bursts, no |
| 00:15:18 | Zagor | we only queue one build, so a new commit during a build replaces the already queued one. sounds fair to me. |
| 00:15:18 | gevaerts | kugel: no. I'd just do the new current revision |
| 00:15:19 | rasher | kugel: hopefully the build system should be done faster than 15 minutes |
| 00:15:31 | * | gevaerts wasn't clear |
| 00:15:32 | Bagder | Zagor: a right, we can just make the queue command work that way |
| 00:15:54 | Zagor | queue command? isn't that the BUILD command? |
| 00:16:02 | Bagder | there's a queue one too |
| 00:16:03 | Zagor | (from commander to server) |
| 00:16:13 | Bagder | although they could probably be one |
| 00:16:24 | Zagor | I think so, yes |
| 00:17:42 | gevaerts | What I'd do is something like let the post-commit hook set a flag and if no builds are running, start a build. At the end of the build, see if any new flags have been set, and if so, start another build with the new latest revision |
| 00:18:49 | Zagor | gevaerts: well the hook sends the revision number. so instead of a flag we simply keep/queue the latest revision. |
| 00:19:37 | Bagder | yeah, so if no buildround is active, it'll build immediately, otherwise keep the rev number for after this round |
| 00:19:43 | gevaerts | Zagor: if it looks the same from the outside, it's the same to me :) |
| 00:19:52 | Zagor | :) |
| 00:20:01 | Zagor | Bagder: exactly |
| 00:20:35 | * | gevaerts would probably implement something horrible with a directory that has files in it named after revisions... |
| 00:20:39 | rasher | I just thought it was a bit wasteful to potentially wait 60 seconds before building |
| 00:20:55 | kugel | Slasheri: ping |
| 00:21:03 | | Quit petur ("Zzzzzz") |
| 00:21:10 | gevaerts | me too. I think we should optimise for the single correct commit case. That's most of them |
| 00:21:48 | Slasheri | kugel: o/ |
| 00:22:21 | kugel | Slasheri: can dircache smash the database? |
| 00:22:21 | Bagder | rasher: this system won't wait a single second |
| 00:22:41 | Slasheri | kugel: hmm, what do you mean with that? |
| 00:22:51 | kugel | I have a very annoying problem that I don't have on my fuze (which doesn't have dircache). If I boot without µSD, the database is almost empty |
| 00:23:31 | kugel | most of my songs are on it, but I regularly exchange it between my fuze and e200. The Fuze's db stays intact without µSD, the e200's not |
| 00:23:38 | rasher | Bagder: Great - so my suggestion was just to keep the same feature of possibly grouping commits in the first build round. But if that's not a requirement, no need to complicate things |
| 00:24:14 | Slasheri | kugel: hmm, interesting. running the "update now" manually doesn't fix it? |
| 00:24:34 | pixelma | kugel: is auto-update enabled too? |
| 00:24:39 | kugel | it does, but it's annoying |
| 00:24:46 | kugel | pixelma: no |
| 00:25:14 | kugel | I expect the database to not change at all without auto-update, hence I don't want to enable it |
| 00:25:38 | Slasheri | kugel: hmm, it shouldn't change |
| 00:26:40 | kugel | it does, and I suspected dircache. I haven't tried disabling it yet, though |
| 00:27:13 | Slasheri | ah, yes. Do you load db to ram? |
| 00:27:19 | kugel | yes |
| 00:27:22 | Slasheri | in that case it does change indeed |
| 00:27:41 | CIA-71 | New commit by zagor (r21639): Clear upload dir after build round ends. |
| 00:27:54 | Slasheri | the ramloader checks with dircache (if that's available) whether those entries still exists |
| 00:28:05 | Slasheri | and if not, those are removed from the db |
| 00:28:46 | | Quit AndyIL (Read error: 113 (No route to host)) |
| 00:28:49 | Slasheri | hmm.. maybe the loader should be fixed by a check if auto-update is enabled |
| 00:28:56 | kugel | I consider this as a bug, actually |
| 00:28:57 | | Join tvelocity [0] (n=tony@adsl3-207.her.forthnet.gr) |
| 00:29:01 | Slasheri | if not, in that case it would not remove those entries |
| 00:29:08 | kugel | that sounds good |
| 00:29:21 | Slasheri | that should be easy to do |
| 00:29:38 | kugel | I'll gladly test it |
| 00:29:54 | Slasheri | i will give it a try - soon :) |
| 00:30:24 | saratoga | Slasheri: about my previous question, where should I look in the source if I want to hack up how microsd cards are mounted in the file browser? |
| 00:30:36 | kugel | eh, I know what soon means in your "timezone" :P Can you point me to the code? |
| 00:31:17 | Slasheri | saratoga: hmm, in that case maybe the file browser itself? the tree/filetree.c |
| 00:33:02 | Slasheri | kugel: hmm.. weird, in fact there is a check for the autoupdate in the code |
| 00:33:14 | Slasheri | tagcache.c:3986 |
| 00:33:53 | Slasheri | ah, no, not for dircache |
| 00:34:09 | Slasheri | just adding the check for the upper block too should be enough :) |
| 00:34:41 | kugel | it's definitely off here |
| 00:35:10 | saratoga | Slasheri: would it be better to do it in the file browser or at a lower level by faking one giant disk that spans two volumes? |
| 00:35:22 | kugel | the whole if..else.. should be within that, correct? |
| 00:35:24 | saratoga | i don't understand how rockbox works yet |
| 00:35:55 | Slasheri | kugel: in fact, no |
| 00:36:29 | kugel | because of the 2 extra lines in the dircache block? |
| 00:36:31 | Slasheri | kugel: normally you want to load the dircache pointer to the tag entry. But if the file doesn't exist, just skip the loading and delete |
| 00:36:41 | Slasheri | kugel: so you have to refactor the ifs a bit |
| 00:38:39 | Slasheri | kugel: well, just skip the delete_entry() unless auto-update is enabled |
| 00:38:42 | Slasheri | that should be enough |
| 00:38:47 | pixelma | bluebrother: how do I get the file info into the first line of a new tex file? "% $Id : Revision Date Author $ (if I "translate" the filled out ones back)? |
| 00:38:53 | kugel | alright |
| 00:40:08 | pixelma | or would |
| 00:40:14 | rasher | pixelma: Just adding % $Id$ and do svn propset svn:keywords Id filename.tex |
| 00:40:22 | kugel | I think $Id:$ is enough |
| 00:40:32 | pixelma | ok |
| 00:41:19 | Zagor | Bagder: there seems to be something not initialized right in startround(). the second BUILD round doesn't get distributed as the first. |
| 00:42:17 | Bagder | sounds like a bug then |
| 00:42:42 | Zagor | yeah. "5 builds not complete, 15 clients. 2 builds in progress" |
| 00:43:17 | Bagder | ! |
| 00:44:35 | CIA-71 | New commit by zagor (r21640): Queue last build request recieved during a build run. |
| 00:45:20 | bluebrother | pixelma: you need the svn property to at least include the value "Id". Usually the values "Author Date Id Revision" are set. And you can leave in other stuff (like old value when copying the line from another file), everthing between the $'s gets replaced |
| 00:48:20 | Zagor | Bagder: shouldn't $client{$_}{'building'} be decreased in kill_child()? |
| 00:49:03 | Zagor | or in _CANCEL perhaps |
| 00:49:37 | Bagder | oh indeed |
| 00:49:51 | Zagor | adding it to _CANCEL |
| 00:50:32 | rasher | Is http://rockbox.pastebin.com/m304d3a76 the idea with that? |
| 00:51:20 | | Join bluebrother^ [0] (n=Dom@g224237222.adsl.alicedsl.de) |
| 00:51:55 | | Quit Hillshum (Read error: 60 (Operation timed out)) |
| 00:52:24 | *** | Saving seen data "./dancer.seen" |
| 00:52:43 | Unhelpful | kugel: re exit(1)... i think there ought to be an "exit" that converts all non-zero into PLUGIN_ERROR and zero into PLUGIN_OK, and a rb_exit or similar that passes the value exactly as-is. the latter is still of value to avoid passing return values up through levels, but is better for things that are not pure ports. |
| 00:53:28 | rasher | Zagor, Bagder: that was directed at you two, sorry (http://rockbox.pastebin.com/m304d3a76) |
| 00:53:34 | kugel | Unhelpful: I thought so too |
| 00:53:55 | Bagder | rasher: yes, that looks like what we've intended |
| 00:54:01 | Zagor | rasher: yes. feel free to commit. |
| 00:54:05 | | Quit ender` (" Marriage is not a word, it's a sentence. A life sentence...") |
| 00:54:31 | kugel | Why not just print $cpu? |
| 00:54:31 | rasher | I don't know what values are possible for that, but hopefully it should be easy to fix |
| 00:55:12 | * | rasher does not question Bagder and zagor |
| 00:55:16 | Bagder | kugel: that wouldn't really help anything as then the logic would instead be put in the server |
| 00:55:19 | kugel | and why is >64 and <32 not supported? I planned to attach a emulated 8086... |
| 00:55:32 | rasher | I'd personally have put the logic in the server |
| 00:55:37 | rasher | But meh |
| 00:55:47 | rasher | It's already there, so |
| 00:55:54 | | Quit bluebrother (Nick collision from services.) |
| 00:55:58 | CIA-71 | New commit by zagor (r21641): Decrese {building} for cancelled builds. ... |
| 00:55:59 | | Nick bluebrother^ is now known as bluebrother (n=Dom@rockbox/developer/bluebrother) |
| 00:56:13 | kugel | Bagder: is the HELLO message parsed by the server or is that only for printing? |
| 00:56:23 | CIA-71 | New commit by rasher (r21642): Detect 32/64-bit targets and report (and exit with an error if the CPU is unknown). |
| 00:56:31 | Bagder | fully parsed and dealt with |
| 00:56:32 | Zagor | kugel: very much used by the server |
| 00:56:52 | bluebrother | kugel: your 8 bit build server would be too slow so there is no point in that. Get a real CPU! |
| 00:56:57 | | Nick linuxstb is now known as _____stb (n=linuxstb@rockbox/developer/linuxstb) |
| 00:57:11 | kugel | ahm, I see the $sock now |
| 00:57:16 | Unhelpful | what about a 65816? :P |
| 00:57:33 | kugel | bluebrother: 8086 is 16bit |
| 00:57:37 | bluebrother | 6502 of course! |
| 00:58:16 | bluebrother | kugel: even worse! 16 bit is *total* crap |
| 00:58:17 | Unhelpful | bluebrother: that's only 8-bit :) |
| 00:58:31 | bluebrother | who wants to use 16 bit at all? |
| 00:59:08 | * | kugel hopes bluebrother noticed that kugel was kidding |
| 00:59:41 | Unhelpful | bluebrother: you can do quite a lot only being able to count to 65535. :) |
| 01:00 |
| 01:00:02 | bluebrother | Unhelpful: as in getting headaches because you don't have enough RAM :( |
| 01:00:25 | kugel | Slasheri: that works, I'm going to commit it |
| 01:00:31 | Unhelpful | bank-switching, boyeeeeee :) |
| 01:00:48 | kugel | or do some overlay |
| 01:01:03 | | Quit DarkDefender (Remote closed the connection) |
| 01:01:07 | kugel | this is getting OT |
| 01:01:12 | Slasheri | kugel: great :) |
| 01:01:36 | kugel | also, that's going to be my first *intentional* git commit :) |
| 01:01:36 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 01:03:04 | saratoga | do we still have .map files available for svn builds? |
| 01:03:51 | * | gevaerts still wants the .elf files as well... |
| 01:05:13 | saratoga | is there a script that figures out where an address is in rockbox? |
| 01:05:57 | CIA-71 | New commit by Ubuntuxer (r21643): FS #10291: use lib highscore.h and add a new highscore table |
| 01:06:26 | | Nick _____stb is now known as linuxstb (n=linuxstb@rockbox/developer/linuxstb) |
| 01:07:37 | Zagor | saratoga: grep? ;) |
| 01:08:08 | saratoga | Zagor: i thought we had a perl script for it somewhere in svn |
| 01:09:22 | Zagor | oh. If we do, I have missed it. |
| 01:09:33 | saratoga | hmm no it only finds asm at an address |
| 01:14:55 | saratoga | we only call cpuflush on codec load if theres more then 1 CPU |
| 01:15:13 | saratoga | is that correct for a CPU like ARM with seperate instruction and data cache? |
| 01:15:49 | saratoga | i would expect that the instruction cache needs to be flushed if we modify code |
| 01:17:07 | | Quit Ubuntuxer ("Leaving.") |
| 01:18:34 | saratoga | and google confirms that it does need to be flushed |
| 01:21:17 | CIA-71 | New commit by kugel (r21644): Do not delete tagcache entries on bootup with dircache enabled but auto-update disabled. ... |
| 01:22:38 | | Quit barrywardell () |
| 01:22:44 | | Join perrikwp [0] (n=Keith@74.167.148.160) |
| 01:23:28 | kugel | saratoga: there are maps for daily builds |
| 01:23:43 | kugel | sorry, "archived" builds |
| 01:23:43 | saratoga | kugel: is there anyway to flush cache for ams in svn right now? |
| 01:23:50 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 01:24:28 | kugel | saratoga: yes, the same way as for other targets using caches |
| 01:24:43 | saratoga | do you know the function? |
| 01:25:27 | kugel | cpucache_flush |
| 01:25:57 | saratoga | thats only defined in PP50*.c files as far as I can tell |
| 01:26:19 | saratoga | guess i could just do a mcr 15, 0, r0, c7, c5, 0 in an ASM block |
| 01:26:30 | kugel | saratoga: that's defined in mmu-arm.S |
| 01:26:48 | kugel | it's an alias for clean_dcache() |
| 01:27:45 | kugel | although there's only the prototype for clean_dcache() in mmu-arm.h, so you better try that |
| 01:28:11 | saratoga | well lets see how well i remember my arm asm |
| 01:28:21 | | Quit robin0800 ("Leaving") |
| 01:28:39 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 01:28:40 | | Join barrywardell [0] (n=barrywar@86-43-167-232-dynamic.b-ras2.prp.dublin.eircom.net) |
| 01:30:16 | kugel | saratoga: just use clean_dcache(), no need for asm |
| 01:30:57 | saratoga | kugel: ASM fixed it anyway |
| 01:31:04 | kugel | fixed what? |
| 01:31:07 | | Quit robin0800 (Client Quit) |
| 01:31:10 | saratoga | the crash on codec load |
| 01:31:22 | kugel | where did you insert it? |
| 01:31:30 | saratoga | its funny i was reading an arm9 textbook yesterday and they mentioned self modifiying code and I thought "huh I'm pretty sure we don't deal with that properly when loading codecs I wonder why it doesn't matter for rockbox" |
| 01:31:50 | saratoga | before the call to codec_main in codec_crt0 |
| 01:32:07 | kugel | haha, that's nice |
| 01:32:14 | Zagor | good catch! |
| 01:32:27 | kugel | saratoga: seems sensible, we're doing that in plugin_load too |
| 01:32:57 | | Quit bluebrother ("Leaving") |
| 01:34:20 | saratoga | kugel: there is no clean_icache() function that I can see |
| 01:34:29 | | Join donutman25 [0] (n=Dagni@65.75.86.64) |
| 01:34:31 | saratoga | is it called something else |
| 01:34:34 | kugel | no, but clean_idcache |
| 01:34:40 | kugel | the very last function |
| 01:35:08 | kugel | i.e. flush both |
| 01:35:30 | kugel | I'm not sure what the difference between "invalidate" and "clean" is, both are doing the writeback |
| 01:35:44 | saratoga | should be the same |
| 01:35:50 | saratoga | where is this defined? grep is finding nothing |
| 01:36:08 | kugel | invalidate_idcache, sorry |
| 01:36:15 | kugel | the last function in mmu-arm.S |
| 01:37:20 | kugel | saratoga: btw, is this really a data abort, or rather undefined instruction? |
| 01:38:32 | saratoga | kugel: try playing an mp3 followed by another format and see for yourself :) |
| 01:38:37 | saratoga | but probably undefined instruction |
| 01:39:28 | kugel | hm |
| 01:39:40 | kugel | I actually got a prefetch abort at skipping back from the ogg |
| 01:40:04 | saratoga | do we really want to flush the dcache? it should actually be coherent at this case |
| 01:40:07 | saratoga | at this point |
| 01:40:34 | saratoga | and why does this not cause problems on the gigabeat F |
| 01:40:39 | saratoga | its ARM9 too . . . |
| 01:41:13 | kugel | saratoga: I'm not sure. we're switching codecs |
| 01:41:35 | kugel | w/o flushing, the new might use the cached data from the old, right? |
| 01:41:41 | saratoga | the switching is handled by the CPU, so any data it caches is still correct |
| 01:42:09 | saratoga | its only a problem for the icache because write backs from the dcache don't update teh icache |
| 01:42:21 | saratoga | so if data is cached in both the icache will be wrong following a write |
| 01:42:41 | saratoga | [buying this arm arch book was a great idea!] |
| 01:43:45 | kugel | I don't think flushing the dcache also is much of an issue |
| 01:44:37 | kugel | but if you're sure you can try. you should create a function in mmu-arm.S though |
| 01:45:26 | saratoga | ok |
| 01:46:27 | kugel | saratoga: the file is splitted in routines for arm11 and lower though. take care of that |
| 01:47:48 | saratoga | kugel: it looks like the beast takes care of its own mmu stuff |
| 01:47:56 | saratoga | but i don't understand why this wasn't a problem on the F |
| 01:48:14 | kugel | they have the same function names, but different code |
| 01:48:21 | saratoga | also is there some reason not to make this a #define ? |
| 01:49:34 | kugel | I don't think so. It seems it's the same for imx anyway |
| 01:50:40 | saratoga | i don't understand the asm here |
| 01:50:47 | saratoga | what does mov r0, #0 do at teh start of the function? |
| 01:50:58 | | Part donutman25 |
| 01:51:02 | kugel | you won't be able to add it to the plugin/codec api then, though |
| 01:51:12 | CIA-71 | New commit by pixelma (r21645): Start of an Iaudio M3 manual: add the necessary platform files (name the remote keymap file 'iaudio' because the keymap is shared with M5 and X5 and ... |
| 01:51:20 | | Join notlistening [0] (n=tom@94-195-105-95.zone9.bethere.co.uk) |
| 01:51:28 | kugel | saratoga: which function? |
| 01:51:29 | saratoga | oh they're just preloading a constant before the coprocessor commands |
| 01:52:41 | notlistening | can a e200v2 boot rockbox from the SD card? |
| 01:53:13 | kugel | with some source code changes, yes |
| 01:54:10 | | Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
| 01:54:16 | kugel | i.e. change BOOTDIR in config-e200v2.h, and pass −−rbdir=/<micrsd1>/.rockbox to configure |
| 01:54:40 | notlistening | humm i will try just to see what can it hurt ;) |
| 01:54:47 | saratoga | kugel: this look right to you? my asm sucks http://pastebin.com/m1f8cc43d |
| 01:55:16 | saratoga | it should work on arm11 as well so i'm going to put it outside the ifdef |
| 01:55:32 | kugel | I you should make sure r0 is 0 imo |
| 01:56:10 | saratoga | oh good catch |
| 01:56:31 | saratoga | which header does this get added to? |
| 01:57:31 | pixelma | ugh, I think I put the labels the r |
| 01:57:34 | pixelma | wr |
| 01:57:49 | pixelma | wrong way... sorry |
| 01:58:08 | kugel | I'm not sure why invalidate_dcache does the "mov r1, lr" ... "mov pc, r1" stuff though |
| 01:58:52 | kugel | bl is saving the return address on the stack, IIUC |
| 02:00 |
| 02:00:34 | saratoga | i guess they don't want to touch the stack during the flush? |
| 02:01:27 | kugel | maybe |
| 02:01:34 | Unhelpful | kugel: i thought that bl saved the return to lr? |
| 02:03:32 | kugel | yes, but I meant the previous value of lr. But I'm not too sure |
| 02:03:54 | saratoga | should i add this function to the codec api or is there some other way to get to it? |
| 02:04:46 | kugel | make it a macro, and let cpp insert it directly, or compile mmu-arm.S in |
| 02:05:10 | kugel | but adding it to the codec api is probably the cleanest |
| 02:05:50 | saratoga | you think i should add this for the gigabeat F as well? |
| 02:06:21 | | Quit Thundercloud (Remote closed the connection) |
| 02:06:38 | kugel | it's added automatically |
| 02:07:00 | kugel | the F uses the part you're editting. The beast uses the upper part of the file |
| 02:07:55 | saratoga | kugel: i mean should I add the call to flush on codec load |
| 02:08:16 | kugel | yes |
| 02:08:34 | kugel | ah you were about to #if CONFIG_CPU == AS3525? |
| 02:09:03 | saratoga | haha found my F, still running r185xx |
| 02:09:08 | kugel | i'd just put #ifdef HAVE_CPUCACHE_INVALIDATE around, that's defined in mmu-arm.h |
| 02:09:33 | kugel | saratoga: you could try to reproduce it on it |
| 02:09:41 | saratoga | thats what i'm doing |
| 02:09:52 | kugel | I'm curious too why it never hit F/X |
| 02:10:42 | | Quit mcuelenaere ("Gnight") |
| 02:11:05 | saratoga | kugel: the F does not have this problem |
| 02:11:45 | kugel | I can't really reproduce it on my fuze |
| 02:12:09 | kugel | I'm playing a mp3, ffwd to ~10% before the end, then press next |
| 02:12:25 | kugel | my playlist is 1mp3, then 12 or so oggs |
| 02:12:43 | saratoga | i did it a few times on my e200v2 |
| 02:13:01 | saratoga | i'll try the fuze |
| 02:13:21 | kugel | it should be added for all targets with icache nevertheless, I think |
| 02:15:27 | saratoga | kugel: it happens on my fuze |
| 02:17:50 | CIA-71 | New commit by zagor (r21646): Rename builds logs $rev-$id.log for keeping. |
| 02:18:54 | | Quit HellDragon (Read error: 54 (Connection reset by peer)) |
| 02:20:02 | | Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) |
| 02:22:10 | kugel | saratoga: I fail at reproducing |
| 02:25:39 | saratoga | kugel: i used the current svn build switching from vorbis to mp3 and got it |
| 02:25:52 | saratoga | from the website |
| 02:26:45 | kugel | I get a prefetch abort sometims |
| 02:26:48 | kugel | sometimes* |
| 02:26:49 | | Quit Zagor ("Clint excited") |
| 02:27:03 | kugel | at a very weird address (0x849.....) |
| 02:27:05 | saratoga | thats what i see |
| 02:27:58 | kugel | ok |
| 02:34:33 | Unhelpful | kugel: ok, why is RFAC a test case for exit-to-wps? |
| 02:34:59 | kugel | not a test case |
| 02:35:15 | Unhelpful | i suppose i mean, why would i want to go straight to WPS from it? |
| 02:35:26 | kugel | the recently added "Play shuffled" puts all folders into signle playlist |
| 02:35:40 | kugel | and starts playing it |
| 02:36:04 | kugel | but it apparently needs to exit for doing this. Exiting to the wps makes more sense than exiting to the main menu |
| 02:36:31 | Unhelpful | also, this patch seems to contain playback controls for PF as well? |
| 02:36:37 | gevaerts | it doesn't really *have* to exit, but if it doesn't, it has to reset a lot of internal state |
| 02:37:11 | kugel | Unhelpful: it just "imports" the std wps button. if it's free, it's used. If it's not free, then not |
| 02:37:12 | Unhelpful | or... just a stop button? |
| 02:37:23 | gevaerts | RFAC grabs the audio buffer, so in order to keep running (and doing something useful) it would have to stop playback again |
| 02:37:32 | kugel | stop? I have you the wrong diff then |
| 02:37:44 | Unhelpful | http://pastie.org/531932 <- this one |
| 02:40:05 | Unhelpful | it has RFAC changes for exit-to-wps, properties, pictureflow... i must've misread the PF_STOP stuff. |
| 02:40:06 | kugel | Unhelpful: thats the latest one anyway: http://pastie.org/534481 |
| 02:40:28 | kugel | yea, that was an old one |
| 02:40:36 | Unhelpful | why would you want to exit to WPS from properties? |
| 02:40:50 | rasher | Unhelpful: because you can press the "go to wps" button |
| 02:41:07 | rasher | Which is expected to work, since the properties plugin blends into the menu structure |
| 02:41:14 | kugel | in the core |
| 02:41:19 | * | rasher asked these same questions a few hours ago |
| 02:41:25 | saratoga | so arm-mmu isn't even available in apps right now |
| 02:41:25 | notlistening | just updated my svn and i am getting error on make full\ip : can't open database.ignore at /home/tom/rockbox/tools/buildzip.pl line 215. |
| 02:41:33 | saratoga | is it ok to add it to system.h? |
| 02:41:34 | Unhelpful | ...ah! in other words, it uses the new plugin feature to enable a button that usually fails (strangely) in the properties screen, which pretends not to be a plugin. |
| 02:41:52 | kugel | saratoga: it should. plugin_load calls cpucache functions |
| 02:42:00 | rasher | notlistening: did you run make first? |
| 02:42:16 | kugel | Unhelpful: exactly |
| 02:42:23 | notlistening | yeah make -j ;P |
| 02:42:59 | rasher | notlistening: Erm, I'd just try blasting the build dir (rm -rf *) and doing make && make fullzip |
| 02:43:04 | Unhelpful | kugel: the only thing i'd say ought to change is the bit we talked about before, about exit() vs an rb_exit() |
| 02:43:05 | rasher | Sounds like something went wrong somewhere |
| 02:43:21 | kugel | Unhelpful: it doesn't include any exit() business anymore |
| 02:43:27 | saratoga | kugel: it calls cpucache_invalidate which is actually defined in one of the PP system files |
| 02:43:42 | notlistening | CC apps/plugins/mpegplayer/header.c has some a whole load warnings ;) |
| 02:43:51 | Unhelpful | kugel: good deal then. also, consider putting your work up on repo.or.cz or such. ;) |
| 02:44:02 | kugel | saratoga: weird. it's the same function, though |
| 02:44:12 | saratoga | but i guess aliased onto invalidate_idcache too |
| 02:44:25 | rasher | notlistening: Is this a clean build? And are you using "our" compilers? |
| 02:44:28 | saratoga | maybe I should just use that function and accept that we'll waste a flush |
| 02:44:30 | | Quit linuxstb (Remote closed the connection) |
| 02:44:31 | rasher | notlistening: A clean sourcetree, I mean |
| 02:45:05 | notlistening | humm not so clean but almost sorry my mistake is it the boom pligin causing the problems |
| 02:45:32 | rasher | Not quite sure what you're saying |
| 02:45:43 | Unhelpful | i don't think there's a "boom" plugin? |
| 02:45:50 | kugel | saratoga: PP has it's own set of functions, it doesn't compile mmu-arm.S |
| 02:45:51 | notlistening | /home/tom/rockbox/apps/plugins/doom/rockdoom.c:216: warning: (near initialization for ‘wads_builtin[6]’) |
| 02:46:03 | kugel | saratoga: yes it is aliased |
| 02:46:11 | notlistening | lol wrong key;) |
| 02:46:30 | saratoga | ugh and HAVE_CPUCACHE_FLUSH is actually defined in somewhere else in some PP code |
| 02:46:39 | saratoga | what a mess |
| 02:47:28 | kugel | the integration of PP into the target tree is indeed a mess |
| 02:47:35 | saratoga | who should I talk to about the target tree defines? |
| 02:47:41 | saratoga | i'm clueless as to how this should be setup |
| 02:47:58 | notlistening | there a whole load. I have been trying to set the microsd from the e200-v2 to be the boot device |
| 02:48:04 | | Join Far^Side [0] (n=farside@88.84.187.18) |
| 02:48:11 | Unhelpful | try a make veryclean first, perhaps? |
| 02:48:24 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 02:48:29 | saratoga | if you're going to mess with configure you probably want to do a fresh folder |
| 02:48:49 | kugel | saratoga: just add a stub for PP, and use it with #ifdef HAVE_CPUCACHE_INVALIDATE (or flush= |
| 02:48:52 | kugel | ) |
| 02:49:35 | notlistening | Good idea will co again |
| 02:50:00 | Unhelpful | no no not co again |
| 02:50:06 | Unhelpful | a fresh build folder. |
| 02:50:20 | saratoga | kugel: thats not defined for anything but PP in /apps |
| 02:50:39 | kugel | what? It's defined in mmu-arm.h |
| 02:50:46 | saratoga | which isn't included in apps |
| 02:51:01 | Far^Side | is my iPod 5.5G dead? My iPod suddenly started showing the sad face icon after being left in the sun for a short time. I have an 8 GiB CF-card in it, an that card is working when removed from the iPod. Tried starting it in recovery mode, but it won't show up in iTunes and it restarts shortly afterwards |
| 02:51:14 | kugel | hm. then include maybe in cpu.h |
| 02:51:34 | kugel | or just directly, which is cleaner if you're going to add this functions directly to the api |
| 02:51:46 | saratoga | all this to include one line of asm :) |
| 02:51:57 | kugel | I don't see why you shouldn't include mmu-arm.h in apps |
| 02:52:02 | kugel | heh |
| 02:52:26 | *** | Saving seen data "./dancer.seen" |
| 02:53:21 | notlistening | right will try that first Unhelpful |
| 02:53:24 | saratoga | kugel: maybe as3525.h should include arm-mmu.h? |
| 02:53:33 | saratoga | since it uses the arm mmu |
| 02:54:06 | saratoga | that way we don't need stubs for arm7 targets with no arm mmu |
| 02:55:09 | kugel | probably |
| 02:59:25 | notlistening | Unhelpful, same warnings & error message on make fullzip |
| 03:00 |
| 03:01:27 | Unhelpful | ...but not on just "make"? |
| 03:01:57 | kugel | saratoga: I think I see what the problem is |
| 03:01:59 | rasher | notlistening: You need to run "make" first, then "make fullzip" |
| 03:02:52 | kugel | saratoga: F/X include mmu-arm.h in system-target.h, which is in system.h |
| 03:02:52 | | Quit Lss (Read error: 104 (Connection reset by peer)) |
| 03:02:57 | kugel | we don't do that |
| 03:03:25 | saratoga | kugel: yeah but i dont' see where they flush the cache? |
| 03:03:31 | kugel | that way we have a stub for cpucache_invalidate() in system.h instead of the actual function |
| 03:03:33 | notlistening | i am running make -j first then make fullzip |
| 03:03:45 | kugel | apps/ never calls cpucache_invalidate for AMS |
| 03:03:55 | rasher | notlistening: And does make -j complete succesfully? |
| 03:04:02 | saratoga | but it does for F/X? |
| 03:04:03 | notlistening | i have been making rockbox before |
| 03:04:10 | kugel | cpucache_invalidate is a codec api member |
| 03:04:11 | Unhelpful | notlistening: so, "make" is completely successful, but "make fullzip" produces errors? |
| 03:04:19 | notlistening | yeah it does just a few warnings as i said |
| 03:04:27 | notlistening | that right |
| 03:04:29 | rasher | notlistening: that's not completely succesful. |
| 03:04:33 | notlistening | sprry if i am being unclear |
| 03:04:36 | saratoga | kugel: yeah but only for PP |
| 03:04:38 | kugel | saratoga: the stub in system.h is within #ifdef HAVE_CPUCACHE_FLUSH |
| 03:04:46 | rasher | notlistening: Which compiler are you using? |
| 03:04:58 | kugel | system.h doesn't see that AMS has this, because we never include mmu-arm.h |
| 03:05:05 | saratoga | yes I know that |
| 03:05:22 | notlistening | the one you guys setup for me from the script |
| 03:05:38 | rasher | notlistening: which target? |
| 03:05:51 | saratoga | oh crap does plugin.c handle loading codecs as well? |
| 03:05:53 | kugel | saratoga: playback calls it, before calling some callback |
| 03:06:20 | notlistening | arm sorry |
| 03:06:28 | notlistening | Using arm-elf-gcc 4.0.3 (400) |
| 03:06:28 | notlistening | Using arm-elf-ld 2.16.1 |
| 03:07:09 | rasher | That seems correct. |
| 03:07:23 | saratoga | kugel: arrrgghhhh |
| 03:07:24 | rasher | Might -j produce errors that don't appear on -j X? |
| 03:07:31 | rasher | notlistening: try make veryclean and make -j 2 |
| 03:07:40 | saratoga | so all thats really needed is to include that one damn header |
| 03:07:49 | notlistening | ok ;) |
| 03:07:52 | kugel | saratoga: can you look if #include "mmu-target.h" in our system-target fixes it? |
| 03:08:08 | kugel | that's badly documented, really |
| 03:08:21 | saratoga | yes |
| 03:12:03 | notlistening | same error :P |
| 03:12:26 | | Part n00b81 ("Leaving") |
| 03:12:29 | notlistening | should i undo my changes? |
| 03:12:29 | kugel | notlistening: you're probably doing it wrong |
| 03:12:33 | kugel | what exactly did you change? |
| 03:12:52 | saratoga | kugel: yes it fixes |
| 03:12:53 | notlistening | the BOOTDIR bit |
| 03:12:56 | saratoga | i'm going to commit it now |
| 03:13:19 | kugel | add a comment to mmu-arm.h also please |
| 03:13:35 | kugel | such as "INCLUDE THIS INTO SYSTEM-TARGET.H OR YOU WILL DIE" |
| 03:13:43 | saratoga | ok |
| 03:13:45 | rasher | notlistening: try svn diff in the root and post the results on a pastebin |
| 03:14:00 | notlistening | ok ;) |
| 03:16:39 | notlistening | http://pastebin.com/d3979c86b |
| 03:17:30 | CIA-71 | New commit by saratoga (r21647): ARM922T's icache isn't coherent with its dcache, so we need to ensure that its flushed before changing codecs. Playback takes care of this for us, ... |
| 03:18:28 | kugel | damn, we wasted too much time on that one |
| 03:19:17 | rasher | notlistening: I'm fairly sure the microsd thing is going to work anyway.. |
| 03:20:20 | drakonik | ooh |
| 03:20:24 | drakonik | I think I found something interesting |
| 03:20:45 | kugel | notlistening: you have a typo there |
| 03:20:59 | rasher | notlistening: er, is not going to work |
| 03:21:07 | kugel | "/<micrsd1>/.rockbox" should be "/<microsd1>/.rockbox", but I don't think it's causing the compiliation failure |
| 03:21:12 | kugel | rasher: it works, I tried it |
| 03:21:29 | rasher | kugel: Shows how much I know. |
| 03:21:38 | drakonik | So I took the rockbox sim directory and put it onto my ipod in disk mode. I moved everything on the ipod into the simdisk folder. I ran the db scan, and eventually, the db scanned froze up. I could still back out of the menu, but the prompt window that opens along with the simulator gave an error message "Too many dirs open" |
| 03:22:01 | kugel | saratoga: I'm wondering if that automagically also fixes the clip playback issues |
| 03:22:30 | notlistening | I'll try changing it |
| 03:23:04 | kugel | notlistening: you have quite some other changes which are more likely to break it, actually |
| 03:24:31 | notlistening | yeah i know he radio bit is not important but the rest of the work is with rbutil |
| 03:25:08 | notlistening | and possibly the configure script ;) |
| 03:25:40 | notlistening | back to the drawing board I think |
| 03:25:42 | saratoga | kugel: yeah i was just thinking that, but greping around I don't see anything directly related to buffering using it |
| 03:26:11 | rasher | notlistening: I think we're down to "Rockbox compiles fine. Your changes broke it" |
| 03:26:21 | kugel | it apparently happens on rebuffering. there's quite a few callbacks involved I think |
| 03:26:24 | rasher | notlistening: unless you can show us that a clean tree still breaks |
| 03:27:21 | notlistening | ok doubt that sorry for causing trouble and thanks for being patient |
| 03:29:08 | kugel | saratoga: so, we basically didn't get fs corruption reports so far, did we? |
| 03:29:57 | kugel | I think we should figure out what to do with the voltage stuff (either revert for now, or pump the volts when accessing the microsd), and then put under supported asap |
| 03:30:29 | saratoga | kugel: none that i know of |
| 03:30:48 | saratoga | and I think we should revert the voltage changes until we've gotten people who reported issues to completely test any fix |
| 03:31:12 | saratoga | or leave them in but disable voltage switching for now since it clearly does not work correctly |
| 03:31:22 | saratoga | i've also noticed it now on my fuze, but it doesn't happen everytime |
| 03:31:22 | kugel | I wish a dev would have a problematic clip / microsd |
| 03:32:07 | saratoga | at least since that patch went in i sometimes get a white screen on boot with my fuze |
| 03:32:10 | saratoga | i presume they're related |
| 03:32:43 | saratoga | but yeah, aside from that what bugs are left on the fuze? |
| 03:33:19 | kugel | I'm not aware of an open bug |
| 03:33:46 | kugel | I just checked my fs again. fsck still only reports problems for the files created by the OF |
| 03:34:07 | | Quit BlakeJohnson86 (Read error: 104 (Connection reset by peer)) |
| 03:34:15 | saratoga | do we need to do anything special to create the canidate bootloaders then? |
| 03:34:47 | kugel | just tag them I think |
| 03:34:54 | | Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 03:35:32 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
| 03:35:33 | saratoga | but the binaries don't need a version number like PP ones? |
| 03:36:28 | saratoga | we should probably remove the SVN revision and replace it was a version 1.0 line |
| 03:36:29 | | Join Blue_Dude [0] (n=chatzill@uslec-66-255-178-43.cust.uslec.net) |
| 03:36:48 | rasher | Same needs to be done for the pp bootloaders.. I didn't do it for the ones in FS |
| 03:37:18 | kugel | saratoga: you mean make should create a bootloader-fuze-rXXXX.sansa? |
| 03:37:46 | kugel | or put the version into the header? |
| 03:37:59 | rasher | kugel: I think he means the version string the bootloader displays |
| 03:38:09 | kugel | ah I see |
| 03:38:31 | notlistening | rasher, my bad coding there damn i will have to hunts that down |
| 03:40:16 | kugel | saratoga: we just need to define APPVERSION accordingly |
| 03:42:36 | | Quit Minthe ("Leaving...") |
| 03:43:51 | kugel | I don't quite see where that comes from currently though |
| 03:44:28 | saratoga | yeah i'm lost too |
| 03:44:49 | | Quit Horscht ("Verlassend") |
| 03:45:43 | saratoga | it looks like its just the revision and date right now |
| 03:46:06 | saratoga | rasher: do we just redfine it for this one build ? |
| 03:47:18 | rasher | saratoga: I'm not sure |
| 03:47:42 | kugel | I think APPVERSION comes from a script during compilation |
| 03:47:52 | kugel | and yes, I think we could redefine it for a release |
| 03:47:53 | rasher | Maybe a branch for bootloader release should be made |
| 03:50:08 | | Quit notlistening ("Leaving") |
| 03:53:07 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
| 03:55:09 | saratoga | rasher: that sounds good |
| 03:55:15 | | Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) |
| 03:55:15 | | Quit pixelma (Nick collision from services.) |
| 03:55:18 | | Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) |
| 03:55:18 | | Quit amiconn (Nick collision from services.) |
| 03:55:27 | rasher | We can do AMS and PP at the same time, to simplify things |
| 03:55:30 | | Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) |
| 03:55:33 | rasher | (in the same branch) |
| 03:55:36 | | Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) |
| 03:55:53 | kugel | rasher: good idea |
| 03:57:45 | kugel | and mkamsboot also in the same branch |
| 03:58:55 | | Quit killan ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") |
| 03:59:26 | saratoga | someone needs to make mkamsboot binaries for windows |
| 03:59:29 | kugel | then we can have mkamsboot also take the svn revision |
| 03:59:47 | kugel | saratoga: did someone actually try that already? |
| 03:59:54 | saratoga | yeah funman i think |
| 04:00 |
| 04:00:04 | saratoga | i cannot get this bootloader to display what i want |
| 04:00:57 | kugel | #ifdef APPVERSION .. #undef APPVERSION .. #endif ... #define APPVERSION "Version 1.0" ? |
| 04:01:27 | saratoga | i tried doing it with printfs like the PP bootlaoders |
| 04:01:29 | saratoga | i will try that |
| 04:01:58 | kugel | saratoga: version stuff is handled in show_logo.c |
| 04:02:13 | saratoga | PP has printfs too |
| 04:02:32 | kugel | yes, but the version display is in show_logo.c for all players I think |
| 04:02:35 | rasher | kugel: also sansapatcher, ipodpatcher |
| 04:03:29 | kugel | we call that branch sansa_inferno then :) |
| 04:03:37 | saratoga | i'll make the bootloaders then post then to FS |
| 04:03:56 | rasher | saratoga: I don't think there's any sense in doing that until everything's fixed in the branch |
| 04:04:03 | kugel | or let me quickly commit a mkamsboot change, and branch now? |
| 04:04:15 | saratoga | commit what change? |
| 04:04:17 | rasher | So we can test the bootloaders that are *actually* going to be released. As in, the same exact files |
| 04:04:42 | kugel | then have some sort of RC phase to test the output on any targets we plan to support (or update the bootloader for) so that we can tag |
| 04:05:06 | kugel | saratoga: http://www.rockbox.org/tracker/task/10397#comment31453 |
| 04:05:44 | kugel | funman said we should do 1.1 after committing this anyway |
| 04:06:11 | kugel | I don't really see a reason to wait with branching. We aren't expecting changes to the bootloader, are we? |
| 04:06:32 | saratoga | ok i'll just post a patch a then with the text changes for the branch |
| 04:11:23 | saratoga | how wide is a char in the default font? |
| 04:11:25 | saratoga | 8 pixels? |
| 04:11:58 | kugel | 8x8, yes |
| 04:14:17 | rasher | I'm quite sure it's not 8x8 |
| 04:15:24 | saratoga | SYSFONT_WIDTH |
| 04:15:53 | saratoga | ok i'm too tired to do this tonight |
| 04:19:26 | saratoga | is rbutil ready to go once theres bootloaders? |
| 04:21:35 | | Quit saratoga ("CGI:IRC (EOF)") |
| 04:22:12 | kugel | it should |
| 04:25:49 | kugel | stupid clip |
| 04:25:54 | kugel | it's so small I always lose it |
| 04:28:06 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 04:28:29 | | Quit fxb (SendQ exceeded) |
| 04:28:42 | | Join fxb [0] (n=felixbru@h1252615.stratoserver.net) |
| 04:30:35 | CIA-71 | New commit by kugel (r21648): Slightly rewrite some parts of mkamsboot for better output and some sanity in the early array declarations. No functional change. |
| 04:39:11 | kugel | rasher: any idea for the branch name? |
| 04:40:54 | kugel | can a branch be renamed? :) |
| 04:49:05 | CIA-71 | New commit by kugel (r21649): Create a branch for updated bootloaders for USB-enabled PortalPlayer devices and initial Sansa AMS bootloaders, including their installers |
| 04:52:28 | *** | Saving seen data "./dancer.seen" |
| 04:56:25 | | Quit kugel (Remote closed the connection) |
| 05:00 |
| 05:09:44 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 05:27:37 | | Join Jax184 [0] (i=Jax184@d75-153-89-18.bchsia.telus.net) |
| 05:27:56 | Jax184 | Will rockbox ever be coming to the v2 e200 DAPs or any newer sandisk players? |
| 05:28:34 | | Join saratoga [0] (n=9803c6dd@rockbox/developer/saratoga) |
| 05:28:46 | scorche|sh | it is quite likely that it would be declared supported in time |
| 05:29:16 | saratoga | Jax184: kugel just branched the e200v2 installer and bootloaders an hour ago |
| 05:29:29 | Jax184 | Really? |
| 05:30:41 | saratoga | yes theres an email about it on the front page of this website |
| 05:37:10 | Jax184 | I'm having some trouble finding this, care to link me? |
| 05:37:54 | | Quit froggyman (" HydraIRC -> http://www.hydrairc.com <- IRC with a difference") |
| 05:38:22 | Jax184 | Or is that http://www.rockbox.org/mail/archive/rockbox-dev-archive-2009-07/0017.shtml ? |
| 05:39:30 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 05:55:23 | Jax184 | So on the current build page, did somebody go and pixel push every little picture of the mp3 players there? |
| 05:59:40 | | Quit CaptainKwel (Remote closed the connection) |
| 06:00 |
| 06:18:59 | | Join _lifeless [0] (n=lifeless@188.16.68.82) |
| 06:24:36 | | Quit linuxguy3 (Read error: 110 (Connection timed out)) |
| 06:34:24 | | Part Jax184 |
| 06:35:27 | | Quit __lifeless (Read error: 113 (No route to host)) |
| 06:52:30 | *** | Saving seen data "./dancer.seen" |
| 06:57:41 | | Quit barrywardell () |
| 07:00 |
| 07:23:06 | | Quit goffa__ (Read error: 104 (Connection reset by peer)) |
| 07:27:58 | | Join Horschti [0] (n=Horscht2@xbmc/user/horscht) |
| 07:29:31 | | Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") |
| 07:37:27 | | Join hd [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) |
| 07:37:47 | | Quit HellDragon (Read error: 104 (Connection reset by peer)) |
| 07:45:59 | | Quit Horscht (Read error: 110 (Connection timed out)) |
| 07:54:07 | | Join Grahack [0] (n=chri@ACaen-156-1-75-178.w90-51.abo.wanadoo.fr) |
| 08:00 |
| 08:12:26 | | Quit Llorean (Read error: 104 (Connection reset by peer)) |
| 08:13:00 | | Join Llorean [0] (n=DarkkOne@adsl-99-182-52-92.dsl.hstntx.sbcglobal.net) |
| 08:15:20 | | Part toffe82 |
| 08:23:55 | | Join robin0800 [0] (n=robin080@general-ld-216.t-mobile.co.uk) |
| 08:41:02 | | Join stoffel [0] (n=quassel@p57B4ED67.dip.t-dialin.net) |
| 08:41:38 | | Quit stoffel (Remote closed the connection) |
| 08:42:16 | | Join stoffel [0] (n=quassel@p57B4ED67.dip.t-dialin.net) |
| 08:52:06 | | Quit robin0800 ("Leaving") |
| 08:52:33 | *** | Saving seen data "./dancer.seen" |
| 08:58:52 | | Join Rob2223 [0] (n=Miranda@p4FDCE92E.dip.t-dialin.net) |
| 08:59:00 | | Quit beta_ (Read error: 60 (Operation timed out)) |
| 09:00 |
| 09:00:34 | | Join beta_ [0] (n=beta@d24-36-78-223.home1.cgocable.net) |
| 09:02:38 | | Join Dhraakellian [0] (n=ntryon@cpe-72-226-197-191.rochester.res.rr.com) |
| 09:17:35 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
| 09:26:25 | | Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) |
| 09:40:44 | | Quit advcomp2019 (Read error: 104 (Connection reset by peer)) |
| 09:41:17 | | Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) |
| 09:47:56 | | Quit r0b- (Read error: 110 (Connection timed out)) |
| 09:48:13 | | Join r0b- [0] (n=rob@adsl-76-235-168-174.dsl.klmzmi.sbcglobal.net) |
| 09:49:48 | | Join JdGordonn [0] (n=irchon@32.156.190.68) |
| 09:50:08 | | Quit JdGordonn (Remote closed the connection) |
| 09:51:29 | | Quit jordan` (Read error: 110 (Connection timed out)) |
| 10:00 |
| 10:01:51 | pixelma | AlexP: morning... I'm currently go through your changes in the manual related to the H100 remote control columns and have some questions |
| 10:09:16 | pixelma | or basically just one - why not use \opt{HAVEREMOTEKEYMAP} for all the \ActionRC stuff. This way you don't need the \opt this pad and \opt that pad in the button tables which was the point of putting them into the keymap platform files (as I see it) |
| 10:11:18 | pixelma | you also had that in the first commit in some parts (and with underscores though) |
| 10:25:48 | CIA-71 | New commit by funman (r21650): mkamsboot: change version string to 1.1, move devices list in the header |
| 10:31:58 | | Join robin0800 [0] (n=robin080@general-ld-216.t-mobile.co.uk) |
| 10:43:11 | | Join wincent [0] (n=wincent@host-091-097-067-213.ewe-ip-backbone.de) |
| 10:48:05 | | Join {phoenix} [0] (n=dirk@p54B466BD.dip.t-dialin.net) |
| 10:48:15 | | Quit desowin (Remote closed the connection) |
| 10:49:58 | | Join desowin [0] (n=desowin@atheme/member/desowin) |
| 10:52:36 | *** | Saving seen data "./dancer.seen" |
| 10:53:42 | | Quit homielowe (Read error: 110 (Connection timed out)) |
| 10:54:27 | | Join funman [0] (n=fun@2001:0:53aa:64c:cfc:53b2:a9b7:588b) |
| 10:54:47 | | Quit flydutch ("/* empty */") |
| 11:00 |
| 11:00:16 | | Join _Auron_ [0] (n=DarkAuro@adsl-76-203-192-240.dsl.rcsntx.sbcglobal.net) |
| 11:00:53 | | Join homielowe [0] (n=homielow@unaffiliated/homielowe) |
| 11:00:55 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
| 11:07:04 | | Join alexteq [0] (n=5e461110@gateway/web/cgi-irc/labb.contactor.se/x-064345255963b9d3) |
| 11:07:46 | | Quit robin0800 ("Leaving") |
| 11:07:49 | alexteq | hee |
| 11:08:55 | alexteq | hello is this the right place to ask if rockbox will be supported for sandisk sansa view? |
| 11:10:32 | JdGordon | this is as good as any.... but its techinally not the right place |
| 11:10:45 | JdGordon | either way, the answer will always be "maybe" |
| 11:10:57 | pixelma | there's a port started but no-one can tell if and when it will be finished. Best place to read up on it is probably the corresponding "New Port" thread in the Rockbox forums |
| 11:11:50 | pixelma | AlexP: I'd also like to revert the changes to nim.tex (Player only plugin) and split_editor.tex (bitmap Archos only)... objections? |
| 11:17:50 | | Join TechOutsider [0] (n=ca7968e7@gateway/web/cgi-irc/labb.contactor.se/x-604a17ecc0ed1933) |
| 11:19:01 | alexteq | i see! if i wanted to get involved in the development of rockbox what technical or programming skills would it require ? |
| 11:20:48 | TechOutsider | can i dualboot original ipod firmware w/ original ipod firmware? |
| 11:23:56 | pixelma | can you rephrase, the question doesn't make sense to me, do you mean dualboot the original firmware with Rockbox? Also, please don't use shorthands like /w as per the guidelines (this is to help screenreaders and automated translation) |
| 11:24:58 | CIA-71 | New commit by funman (r21651): Sansa AMS : don't reinvent adc_read(), patch by FlynDice |
| 11:26:12 | Grahack | alexteq: I'm quite new here but I know the areas where we can contribute are vast: translations, RB docs, C code, electronics, DAP docs and charts... |
| 11:27:40 | | Join matsl [0] (n=matsl@host-90-233-180-166.mobileonline.telia.com) |
| 11:28:17 | TechOutsider | i mean dual boot original firmware with the original firmware |
| 11:28:24 | | Join homielowe_ [0] (n=homielow@S01060011954e0432.no.shawcable.net) |
| 11:28:26 | TechOutsider | so it shows up as two ipods in iTunes |
| 11:29:16 | funman | no, it doesn't make sense. and also the original firmware is not on topic on #rockbox |
| 11:29:38 | pixelma | I don't know why you would want to do that and I also doubt you'll find the answer here (what funman said) |
| 11:29:54 | TechOutsider | well maybe i could use the rockbox bootloader |
| 11:30:03 | | Join lilltiger [0] (n=lilltige@82.145.152.217) |
| 11:30:30 | alexteq | Grahack: thank you |
| 11:31:25 | bertrik | does anyone have a problem with using a typedef in target-specific driver code? |
| 11:32:39 | funman | i think it depends how spread the structure usage is, and if it's small an additional 'struct' isn't very annoying |
| 11:32:40 | | Quit TechOutsider ("CGI:IRC (EOF)") |
| 11:35:08 | | Join homielowe__ [0] (n=homielow@66.183.72.25) |
| 11:35:16 | | Quit homielowe (Read error: 110 (Connection timed out)) |
| 11:37:12 | | Quit alexteq ("CGI:IRC") |
| 11:37:56 | Grahack | alexteq: wandering around your question, I just read that you can contribute setting up a build server too http://www.rockbox.org/twiki/bin/view/Main/BuildServer |
| 11:39:01 | | Quit funman ("free(random());") |
| 11:45:03 | | Quit homielowe_ (Success) |
| 11:53:02 | * | pixelma wonders why splitedit.c has buttons for the H100s defined when it is excluded for swcodec targets in apps/plugins/SOURCES |
| 11:54:01 | pixelma | maybe that's something from before this control file was invented (or someone wanted to port it at one point) |
| 11:57:35 | | Join n00b81 [0] (n=taylor@unaffiliated/n00b81) |
| 11:58:09 | gibbon_ | is there away to find out, if my new-style buildhost has produced anything meaningful yet? |
| 12:00 |
| 12:00:14 | GodEater | gibbon_: The new build client results aren't being distributed yet as far as I know |
| 12:01:37 | gibbon_ | but thes are sent back to the server? |
| 12:02:00 | GodEater | yes, but I'm not sure they're being kept at the moment |
| 12:02:54 | pixelma | I guess one of the Swedes could tell you |
| 12:07:49 | gibbon_ | well ok... its nothing urgent... i just wanted to make sure, that i did everything right |
| 12:08:07 | gibbon_ | the debugging output currently is not that clear about if anything went wrong |
| 12:08:25 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 12:08:38 | gibbon_ | but thank you |
| 12:08:45 | kugel | hm, I had other plans for mkamsboot v1.1 |
| 12:09:03 | gibbon_ | i mainly wanted to make sure that the given performance is enough |
| 12:10:41 | gibbon_ | s/enough/sufficient/ |
| 12:13:44 | | Quit lilltiger (Read error: 110 (Connection timed out)) |
| 12:17:35 | | Join KBH [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
| 12:17:58 | | Part homielowe__ |
| 12:19:24 | AlexP | pixelma: For the second part, no problem |
| 12:19:53 | AlexP | pixelma: For the first part, I did it specifically on the H100 as some remotes are so short of buttons that they won't have all the actions |
| 12:20:09 | | Join barrywardell [0] (n=barrywar@86-43-162-146-dynamic.b-ras2.prp.dublin.eircom.net) |
| 12:20:13 | AlexP | That's why I was asking about the archos remote and how many buttons it has |
| 12:20:25 | AlexP | The gigabeat remote is also slightly short |
| 12:20:45 | pixelma | I also wonder if we need to include the complete licenses text in the manual - that's 15 pages in our current layout that won't be read much I guess |
| 12:20:54 | AlexP | But if there are actions that are covered by all the remotes, then yes it is better to opt on have_remote |
| 12:21:22 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
| 12:21:36 | kugel | Unhelpful: ping |
| 12:21:56 | AlexP | pixelma: In fact, thinking about it, that was silly :) |
| 12:22:11 | pixelma | AlexP: the first case could be also handled iwith \Actions in the platform files - just "declare" them as empty |
| 12:22:16 | AlexP | pixelma: Yes, they should all be opted on haveremote |
| 12:22:28 | pixelma | not sure which is the cleaner solution |
| 12:22:33 | AlexP | I didn't think about that - silly old me :) |
| 12:22:44 | pixelma | already did ;) |
| 12:23:22 | AlexP | No, I agree with you - it is better to do it on haveremote |
| 12:23:35 | AlexP | and then just have it blank in the platform file |
| 12:24:02 | | Quit HBK (Read error: 60 (Operation timed out)) |
| 12:24:27 | pixelma | ok, commit probably coming up after lunch |
| 12:24:35 | AlexP | OK, sounds good :) |
| 12:32:59 | | Join jordan` [0] (i=gromit@78.235.252.137) |
| 12:35:29 | | Join elliott [0] (n=a6526b8a@gateway/web/cgi-irc/labb.contactor.se/x-16ce312143828e56) |
| 12:35:50 | CIA-71 | New commit by kugel (r21652): Change to versioning for mkamsboot to <rXXXXX>-<DATE> for svn builds. A fixed number like 1.1 can (and should) be used for releases. |
| 12:37:19 | | Join elliott1 [0] (n=elliott@h138.107.82.166.ip.windstream.net) |
| 12:38:47 | | Part elliott1 ("WeeChat 0.3.0-dev") |
| 12:40:28 | | Quit elliott ("CGI:IRC (Ping timeout)") |
| 12:46:19 | CIA-71 | New commit by kugel (r21653): Backport r21652 and give mkamsboot "1.1RC". |
| 12:52:38 | *** | Saving seen data "./dancer.seen" |
| 12:53:01 | | Quit stoffel (Remote closed the connection) |
| 12:53:30 | | Join ender [0] (i=krneki@foo.eternallybored.org) |
| 12:54:30 | kugel | What should release bootloader actually say? |
| 12:54:41 | kugel | Boot Ver. 1.0? |
| 12:55:17 | | Quit {phoenix} (Read error: 110 (Connection timed out)) |
| 12:56:34 | pixelma | when I first saw the "Boot Ver." on my c200, I thought that it doesn't sound good (language wise). Maybe a native speaker can comment |
| 12:57:29 | kugel | pixelma: what did it say after the ver.? |
| 12:57:40 | | Quit daurn ("Cyas") |
| 12:58:26 | pixelma | currently 5.0 for me here |
| 12:59:26 | kugel | so just "Boot Ver. 5.0" ? I don't have seen a released bootloader for a long time :/ |
| 13:00 |
| 13:01:18 | | Quit Grahack ("Leaving.") |
| 13:02:43 | pixelma | yes - at a similar looking screen as the real boot one. On the M5 on the other hand it is "Rockbox boot loader" and on the next line "Version 4" - everything on the top of the screen (and I think deliberately without logo which was only in use on the Sansa, I think not everyone agreed though) |
| 13:03:03 | | Join daurnimator [0] (n=daurnima@unaffiliated/daurnimator) |
| 13:04:18 | kugel | hm |
| 13:05:43 | kugel | I think we'll be going with "Boot Ver. 1.0" then for now |
| 13:09:37 | | Quit daurnimator ("Cyas") |
| 13:11:29 | | Quit ender` (Read error: 110 (Connection timed out)) |
| 13:12:21 | CIA-71 | New commit by kugel (r21654): Version 1.0RC for the Sansa AMS bootloader. |
| 13:12:55 | | Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) |
| 13:13:04 | kugel | so, they just need a quick verification now (the fuze bootloader works) |
| 13:24:12 | bertrik | kugel, you were referring to r21647? |
| 13:24:37 | bertrik | does that patch fix the playback stops on the clip? |
| 13:25:53 | | Join elliott1 [0] (n=elliott@h138.107.82.166.ip.windstream.net) |
| 13:26:13 | kugel | bertrik: yes, I am. I don't whether it fixes it. I can't find my clip |
| 13:26:36 | kugel | the whole apps/ code didn't see any cpu cache related functions before |
| 13:26:40 | elliott1 | little bastards are too easy to lose...i just found mine after 2 months... |
| 13:26:53 | kugel | indeed |
| 13:28:01 | kugel | elliott1: this is the exact revision. I guess if you still have it then it didn't fix it |
| 13:28:30 | | Join daurnimator [0] (n=daurnima@unaffiliated/daurnimator) |
| 13:29:29 | kugel | bertrik: it would be nice if we can test the branched bootloader/mkamsboot quickly, so that the branch is free for the PPs |
| 13:31:15 | | Quit gevaerts (Nick collision from services.) |
| 13:31:27 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 13:31:48 | kugel | and we should poke FlynDice about the voltage thing |
| 13:32:19 | elliott1 | i can't seem to reproduce the problem, it seems to play certain songs just fine once then the next time it will freeze half way through |
| 13:32:35 | elliott1 | i haven't found a song that it fails every time on |
| 13:37:50 | elliott1 | of course, now that i said that, it has stopped twice in a row on this one |
| 13:40:31 | elliott1 | 3 times and this time it is a hard lock...it is 225KBit, 44100Hz |
| 13:40:43 | | Quit barrywardell () |
| 13:41:30 | * | bertrik is playing a 2 second music clip in the rockbox bootloader on the meizu m3 |
| 13:42:11 | mcuelenaere | bertrik: \o/ |
| 13:42:13 | kugel | wow, where's the ladies and gentlemen main? |
| 13:42:18 | kugel | mail* |
| 13:44:21 | bertrik | it's only 2 seconds raw wave (for space reasons) and requires various hacks, but it works :P |
| 13:44:36 | n00b81 | Nice job, bertrik :) |
| 13:50:24 | | Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) |
| 13:50:32 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 13:51:06 | | Join barrywardell [0] (n=barrywar@86.43.162.146) |
| 14:00 |
| 14:00:47 | | Quit daurnimator (Read error: 110 (Connection timed out)) |
| 14:02:47 | | Quit barrywardell () |
| 14:04:09 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 14:04:54 | | Quit elliott1 ("WeeChat 0.3.0-dev") |
| 14:07:31 | | Join donutman25 [0] (n=Dagni@65.75.86.64) |
| 14:10:17 | | Join daurnimator [0] (n=daurnima@unaffiliated/daurnimator) |
| 14:14:42 | pixelma | AlexP: you also have the h100 remote, right? Could you tell me (or make a sketch) how the buttons are called so I could label them? |
| 14:15:22 | AlexP | pixelma: Sure |
| 14:15:30 | AlexP | Do you have your picture? |
| 14:15:48 | pixelma | let's see |
| 14:17:14 | AlexP | bertrik: Awesome :) |
| 14:19:53 | bertrik | AlexP, thanks. The biggest stumbling block after this is reading (and interpreting) the flash for the file system I think |
| 14:20:26 | CIA-71 | New commit by alex (r21655): Swap order of H100 remote keys in a table. |
| 14:20:42 | AlexP | To be clear - one set of buttons on one table :) |
| 14:21:06 | AlexP | bertrik: Does it share anything with the other direct flash access targets? |
| 14:21:09 | Torne | is the website down? |
| 14:21:25 | AlexP | Torne: Works here |
| 14:21:47 | Torne | i get a timeout :( |
| 14:22:02 | bertrik | AlexP, not sure, but I think so. It uses the 'whimory' flash stack if I understand correctly (also used in the iPhone). |
| 14:22:09 | Torne | i think i worked out what gpio3 bits 10/11 on the beast mean, though :) |
| 14:22:29 | AlexP | Torne: do_stupid_format ? |
| 14:22:34 | Torne | unfortunately no |
| 14:22:37 | Torne | nothing *relevant* |
| 14:22:43 | Torne | if they're zero it sets up flash and ram differently in a way that seems to probably match the devboard |
| 14:22:50 | Torne | (more banks of ram etc) |
| 14:22:52 | AlexP | bertrik: So hopefully that'll help a little |
| 14:22:59 | AlexP | Torne: woo! |
| 14:23:11 | pixelma | AlexP: only the picture with all remotes currently online: http://home.infocity.de/m.arnold/temp/Remotes.svg |
| 14:23:35 | AlexP | pixelma: OK, so looking at that: |
| 14:23:49 | AlexP | Along the top are two rocker switches, that can also be pushed in |
| 14:24:09 | bertrik | AlexP, I hope it's not too complicated for reading at least |
| 14:24:11 | pixelma | yep, got that |
| 14:24:25 | AlexP | The one on the left is rewind when rocked left, fast forward when rocked right, and pushed in it is labelled Navi/Menu |
| 14:24:39 | AlexP | I called those Rewind, Forward, and Navi |
| 14:25:16 | AlexP | The top right rocker switch is labelled Source/Type when pushed left (I called it Source), Bitrate when pushed right, and Rec when pushed in |
| 14:25:34 | AlexP | Along the bottom, on the left is the hold switch |
| 14:26:18 | AlexP | On the bottom right is a third rocker switch - labelled Vol - left, Vol + right, and A-B/Mode when pushed in (I called this A/B) |
| 14:26:40 | AlexP | Then there is play/pause and stop on the face (as you can see) |
| 14:27:14 | AlexP | voila! |
| 14:27:37 | | Quit n00b81 ("Leaving") |
| 14:28:02 | pixelma | alright, thanks. It's there in the logs when I find the time to label it :) |
| 14:28:08 | AlexP | yep :) |
| 14:29:56 | | Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) |
| 14:34:39 | pixelma | AlexP: sorry to bother you once more... can you take a look at the manual's main_menu/fmradio.tex - can you tell me why you called the action \ActionRCFMVolDown (as for the main unit - and also in the c code it's actually using the settings inc/dec)? |
| 14:36:27 | pixelma | ah hmm... the h100 remote has a second set for those in the radio screen |
| 14:41:22 | * | pixelma wonders how to deal best with that - opting in fmradio.tex or something in the keymap file :\\ |
| 14:41:33 | AlexP | yeah, not sure |
| 14:42:06 | AlexP | Sorry, got to pop off for a bit n ow |
| 14:42:10 | AlexP | Will be back later |
| 14:42:35 | pixelma | the Iaudio remote uses the same as for settings inc/dec as everywhere else (which is volume up/down) |
| 14:43:13 | | Part wincent ("Kopete 0.12.7 : http://kopete.kde.org") |
| 14:51:52 | | Quit kugel (Read error: 110 (Connection timed out)) |
| 14:52:39 | *** | Saving seen data "./dancer.seen" |
| 14:53:03 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 15:00 |
| 15:03:26 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 15:05:10 | | Join n00b81 [0] (n=taylor@unaffiliated/n00b81) |
| 15:09:34 | | Join mt [0] (n=MTee@41.206.134.155) |
| 15:12:56 | | Quit kachna|lappy (Read error: 113 (No route to host)) |
| 15:17:32 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 15:20:42 | mt | I've added another version of the latest patch in FS #10182 |
| 15:21:16 | mt | saratoga, linuxstb : ^^^ |
| 15:23:50 | | Quit daurnimator (Remote closed the connection) |
| 15:24:09 | mt | One persistent issue is that, when compiling bitstream.c, gcc warns about signed and unsigned types (comparision/in conditional expression), does the build server have these warnings enabled ? |
| 15:31:47 | | Quit Xerion (" ") |
| 15:33:27 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 15:34:43 | funman | kugel: ping |
| 15:36:59 | | Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) |
| 15:41:19 | CIA-71 | New commit by bertrik (r21656): S5L8700: initial framework for PCM (using DMA transfers) |
| 15:55:32 | kugel | funman: ping |
| 15:55:36 | kugel | pong* |
| 15:55:48 | funman | nice to see the bootloaders stabilize ;) |
| 15:56:04 | funman | i had a question about r21652 but i answered it myself |
| 15:56:53 | kugel | funman: we haven't had any fs corruption reports, did we? |
| 15:56:53 | funman | APPSVERSION is only used in bootloader/*.c , and the "Boot Ver. 1.1RC" string fits on Clip/m200v4 screens, unlike "Boot Ver. rxxxxx-yyyyyy" |
| 15:56:59 | funman | i don't think so |
| 15:57:23 | kugel | We should probably revert (or #if 0) the voltage stuff for now, so that it doesn't block the supported status |
| 15:57:52 | funman | is there any functional change with using adc_read() ? |
| 15:58:09 | funman | well yes, it reads the top bits of ADC at least |
| 15:58:11 | kugel | no idea. I don't experience any problems |
| 15:58:49 | funman | we aren't in a hurry so we can let it like it is, waiting to know if it's still buggy and what FlynDice thinks about it |
| 15:59:01 | kugel | mc2739 said adc_read doesn't fix his problems |
| 15:59:39 | kugel | yea, we definitely wait if FlynDice has ideas |
| 16:00 |
| 16:00:17 | kugel | but I don't think lowering voltage is major enough in the long term |
| 16:00:31 | kugel | in the short* term |
| 16:01:52 | funman | kugel: can you build a 32bits linux binary of mkamsboot ? |
| 16:01:57 | kugel | yes |
| 16:02:40 | funman | i have win32 & x86_64 (can't access an intelmac atm). Where should we put these binaries, in a 1.1RC folder of the download server or a FS ticket? |
| 16:03:15 | kugel | don't know. should we put them anywhere at all? |
| 16:03:27 | mt | Anyone with a big endian target willing to test RM patch ? |
| 16:03:48 | kugel | I planned that we quickly verify mkamsboot and the bootloaders (at least on the targets to be supported), and then release |
| 16:04:07 | funman | mt: i had a look, i think only coldfire (irivers) are big endian. |
| 16:04:18 | funman | kugel: makes sense |
| 16:04:20 | kugel | But I don't think we should release before really putting the main build up too |
| 16:05:06 | funman | why is a svn branch needed for AMS ? |
| 16:05:34 | kugel | because we can hack in version strings better. Plus, the branch is also for PP bootloaders |
| 16:05:46 | | Join linuxguy3 [0] (n=timj@68.253.209.227) |
| 16:06:34 | kugel | I rather branch, instead of hacking in the version string, then release, and then revert the whole thing agian |
| 16:08:45 | kugel | we can tag off the branch then, and don't mess with it at all in the trunk |
| 16:08:50 | mt | funman: If I compiled a simbuild for an iriver, do you think the results would be significant ? |
| 16:09:11 | funman | mt: no, unless you compile it on a big endian system (like OSX PPC) |
| 16:09:54 | mt | hmm.. I'll just wait then till an iriver owner could test the patch. |
| 16:11:53 | | Join stripwax5443 [0] (n=Miranda@87.194.34.169) |
| 16:12:12 | stripwax5443 | someone need help testing on iriver target? |
| 16:12:53 | mt | stripwax5443: Yes, FS #10182, latest patch. :) |
| 16:13:04 | | Join jon-kha [0] (i=jon-kha@kahvi.eu.org) |
| 16:13:08 | stripwax5443 | hm, rockbox.org down for me |
| 16:13:53 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
| 16:14:17 | stripwax5443 | rockbox.org working for everyone else? |
| 16:15:03 | n00b81 | works for me |
| 16:16:24 | | Join stripwax_ [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 16:16:34 | pixelma | works for me too... I see testing on a coldfire target is needed? |
| 16:17:13 | pixelma | but I have no .rm files |
| 16:17:22 | kugel | funman: I think we should slowly start to agree on a release date. We aren't in a hurry but it would be nice to get this done |
| 16:17:57 | * | stripwax_ goes for the reboot option .. |
| 16:18:13 | | Quit stripwax_ (Read error: 104 (Connection reset by peer)) |
| 16:18:52 | funman | kugel: release date is mid september ? |
| 16:19:12 | funman | 3 months after 3.3 |
| 16:19:28 | mt | pixelma: Here are some samples http://samples.mplayerhq.hu/real/AC-cook/ |
| 16:22:03 | kugel | funman: I don't mean that release. We don't need to wait for 3.4 to put the AMSes under supported |
| 16:22:07 | | Quit stripwax5443 (Read error: 104 (Connection reset by peer)) |
| 16:22:08 | | Quit stripwax (Read error: 104 (Connection reset by peer)) |
| 16:23:02 | funman | kugel: there is only 1 kind of release and it's rockbox releases. |
| 16:23:14 | dz | what C library should I be using for arm? (trying to do a toolchain using crossdev on gentoo, complains about missing keyword for newlib) |
| 16:23:29 | funman | I'm not sure we need to define a date, rather we should mark the AMS builds as supported when there is no major bug in them (which we still aren't sure?) |
| 16:23:35 | kugel | funman: yes, but we can always offer current builds + installation (etc) without a release |
| 16:23:50 | funman | dz: use the rockboxdev.sh script in tools/ (no libc is needed) |
| 16:24:10 | funman | kugel: of course, but i still don't think we need to give us a deadline |
| 16:24:24 | kugel | hence the "slowly" |
| 16:24:43 | dz | funman: alright, I suppose someone should take the crossdev instructions off of the wiki page then? |
| 16:24:45 | | Quit matsl (Read error: 110 (Connection timed out)) |
| 16:24:58 | funman | dz: i think so, which page is it ? |
| 16:25:21 | kugel | What I basically mean was that we should watch for issues now, and if we don't find a major one in a timeframe of say 2 weeks, let's put the builds up |
| 16:25:47 | dz | funman: http://www.rockbox.org/twiki/bin/view/Main/CrossCompiler |
| 16:25:48 | | Join matsl [0] (n=matsl@host-90-233-230-237.mobileonline.telia.com) |
| 16:25:57 | kugel | the fs corruption appears to be gone with your bank switch fix, the only issue I know is the voltage thing |
| 16:27:20 | funman | i think the instructions for manual build should be removed as well (not the instructions for GDB though) |
| 16:27:27 | dz | funman: actually, looks like adding −−without-headers may fix it |
| 16:28:01 | kugel | funman: why? |
| 16:28:08 | funman | kugel: some people mentioned corruptions and deadlock at least before r21550 |
| 16:28:31 | funman | kugel: are these instructions supported ? (and maintained). This is not the case for the gentoo instructions at least |
| 16:28:51 | crashd | is there any way to remap the ipod hold function to be something else other than the hw hold switch? |
| 16:28:53 | kugel | it's a wiki, it has many things we don't maintain |
| 16:28:56 | crashd | or is that going to be a meaty code hack |
| 16:29:36 | kugel | funman: hence I said it appears to be gone since that commt |
| 16:29:39 | funman | kugel: this page is linked to from the docs index so the instructions are official |
| 16:29:55 | kugel | I don't think they should be removed |
| 16:30:14 | kugel | why should they? Are they not working? |
| 16:30:24 | funman | kugel: just look what dz said |
| 16:30:32 | kugel | gentoo doesn't work, yes |
| 16:30:57 | kugel | but they still are more helpful than no instructions at all, or am I wrong here? |
| 16:31:04 | pixelma | crashd: there already is a software hold feature for targets that don't have a hold switch, maybe you can reuse that |
| 16:31:12 | kugel | and I'm fairly sure the manual way also still works |
| 16:31:13 | dz | gentoo seems to be working with the −−without-headers flag added |
| 16:31:20 | crashd | pixelma: interesting |
| 16:31:31 | crashd | my hw hold switch is broke ysee so im looking into a workaround |
| 16:31:39 | crashd | how does it work on software hold targets? |
| 16:31:46 | pixelma | crashd: I believe there were already threads in the forums about it and there were some more answers |
| 16:31:51 | funman | http://www.anythingbutipod.com/forum/showpost.php?p=370168&postcount=157 mentions deadlock after r21550 |
| 16:32:03 | kugel | funman: if that page is so official, then the instructions are probably also supported. |
| 16:32:22 | pixelma | crashd: you push a certain key combo to enable softwaree hold (in the WPS) and press it again to disable it |
| 16:32:27 | funman | kugel: i just meant that only rockboxdev.sh is supported |
| 16:32:40 | kugel | I don't think that's true |
| 16:33:03 | kugel | it's a convinient script, but we're not forcing anyone on how to build the crosscompilers |
| 16:33:08 | crashd | seems pretty trivial to cchange the HAVE_SW_HOLD define |
| 16:33:10 | crashd | thanks pixelma :) |
| 16:33:32 | funman | kugel: not forcing, but we're not helping people who don't want to use rockboxdev.sh |
| 16:33:49 | kugel | funman: how come you think he was using a build after r21550? |
| 16:34:04 | pixelma | crashd: the presses aren't discarded completely (backlight lights up but you can't do accidentally changes... you probably need to edit your keymap file to assign a key combo |
| 16:34:10 | funman | "latest patch" |
| 16:34:35 | funman | and he says incorrect display was fixed |
| 16:34:36 | kugel | that doesn't mean anything |
| 16:34:44 | crashd | pixelma: that's great |
| 16:34:45 | funman | true |
| 16:34:46 | crashd | thanks for the help :) |
| 16:35:15 | kugel | and even if, do we know he reformatted before updating to "the latest patch"? |
| 16:35:41 | funman | it doesn't matter |
| 16:35:58 | kugel | I don't really give a shit on reports of 1 individual who provided such loose informations |
| 16:36:38 | kugel | It doesn't matter? You said yourself in the commit message to only report bugs on freshly formatted devices |
| 16:36:47 | funman | what i want to say is that no bug report doesn't mean no bug |
| 16:37:12 | funman | it only matters when seeing filesystem corruption (incorrect code loaded like codecs or plugins) |
| 16:37:39 | funman | not for a lock (which comes from an unrecoverable error in an hardware SD operation) |
| 16:38:02 | pixelma | crashd: you can look up ACTION_STD_KEYLOCK in one of the Archoses' keymap files |
| 16:38:26 | | Quit Nico_P (Remote closed the connection) |
| 16:38:37 | funman | if we make mkamsboot/bootloaders builds we could ask on the forum thread for testers (I think there is a lot of people waiting to test) |
| 16:38:39 | kugel | funman: I can't follow you |
| 16:38:52 | funman | kugel: what's wrong? |
| 16:39:05 | kugel | I didn't understand what you were trying to tell me |
| 16:39:25 | funman | in which sentence? |
| 16:39:46 | kugel | the three after it doesn't matter |
| 16:40:29 | funman | the 1st sentence was separated from the 2 following |
| 16:40:45 | kugel | Also, what's the point of making test builds of the bootloader and mkamsboot and asking for tests (i.e. support those)? A current build is a test build, so we can put all that stuff up, making it supported. It's the same afterall |
| 16:41:24 | funman | we need testing before we support it |
| 16:41:38 | funman | and for testing we need bootloaders and mkamsboot binaries so people can use the current build |
| 16:42:15 | kugel | That's no different from putting the binaries on the download server |
| 16:42:36 | funman | i'm not saying something different |
| 16:44:01 | kugel | I don't think we need to mess with putting something in the forum. If we don't know of a major bug, then we can do all the supported stuff, and receive testing that way (that's what the current build is for afterall) |
| 16:44:12 | funman | i know of a major bug |
| 16:44:34 | funman | and i need lots of testing to be sure it was fixed by r21550 |
| 16:45:11 | kugel | what major bug (aside from the voltage thing?) |
| 16:45:16 | funman | if it wasn't, i have no idea of how much time is needed for fixing this |
| 16:45:22 | funman | SD driver deadlocking |
| 16:45:25 | kugel | s/?)/)?/ |
| 16:45:43 | kugel | That's caused by the voltage change |
| 16:45:49 | funman | no |
| 16:46:01 | kugel | What sd driver deadlocking then? |
| 16:46:37 | funman | the sd controller reporting a DATA TIMEOUT indefinitely |
| 16:46:58 | kugel | that's useless |
| 16:47:30 | funman | i don't think that's useless, if the hardware reports this error it really happened. |
| 16:48:12 | kugel | a) I don't have that b) "the sd controller reporting a DATA TIMEOUT indefinitely" is information only you can provide so I can connect it to any other report in the forum for example |
| 16:48:47 | funman | http://forums.rockbox.org/index.php?topic=14064.msg152510#msg152510 |
| 16:49:41 | kugel | I can't find where that guy tells something about data timeout |
| 16:49:54 | funman | I detailed the problem in my edit of http://forums.rockbox.org/index.php?topic=14064.msg151588#msg151588 |
| 16:50:21 | funman | currently the code will just go into an infinite loop, I got this information by adding debug code |
| 16:51:12 | funman | i want to make the driver print a useful error message if this happen, but it's still on my TODO list |
| 16:51:17 | kugel | that's long ago. I thought it's fixed with aligned buffers and the bank swithc fix |
| 16:51:32 | kugel | can you still reproduce it with current svn? |
| 16:51:43 | funman | kugel: i don't know if it was fixed, we can only tell with wide testing |
| 16:51:51 | funman | no since i have no method to reproduce it |
| 16:52:17 | kugel | See. And we get the best testing by supporting it with all downloads and stuff |
| 16:52:31 | kugel | I don't see why we need to make it locally to the forums first |
| 16:52:41 | *** | Saving seen data "./dancer.seen" |
| 16:52:46 | funman | kugel: but if it's still buggy, what's the point of supporting the buggy builds? |
| 16:53:21 | kugel | it's not a known bug as such, because there were many commits that are not unlikely to fix it and we don't get reliable bug reports for that issue |
| 16:53:38 | kugel | and if we have no known bug, there's no reason to hold anything back |
| 16:53:46 | funman | like i said, no bug report doesn't mean no bug |
| 16:54:12 | funman | that, because the bug appears randomly |
| 16:54:34 | kugel | so we never put it supported? |
| 16:54:39 | kugel | because it may be buggy? |
| 16:54:49 | | Join mt_ [0] (n=MTee@41.206.137.59) |
| 16:54:59 | funman | i suggested that we ask people to test it before supporting the Sansa AMS |
| 16:54:59 | kugel | That's the definition of the current build, and we have to get wide testing for potentially buggy stuff |
| 16:55:14 | funman | with enough testers we can make sure this bug was fixed |
| 16:56:01 | | Quit mt_ (Client Quit) |
| 16:56:15 | kugel | I think you're putting a bit too much into the "being supported" thing |
| 16:56:23 | | Join mt_ [0] (n=MTee@41.206.137.59) |
| 16:56:31 | funman | what do you think is wrong with some testing before supporting the builds ? |
| 16:56:38 | kugel | it doesn't mean we're guaranteeing a flawless build |
| 16:57:08 | pixelma | what's the point in calling it supported too quickly? If there are potentially still enough users who can damage their filesystem (maybe lose important data) I think I'd give testing another round. And my impression is that there are enough testers around |
| 16:57:19 | kugel | nothing as such, except that it's effectivly the same as supporting, with the difference that we get even more testers with supporting |
| 16:57:53 | kugel | as you said yourself, we are not doing a release |
| 16:57:57 | funman | kugel: well if there is no difference for you, then I prefer calling for testers before calling Sansa AMS supported |
| 16:58:42 | kugel | then let's do it that way |
| 16:59:25 | funman | when do you want to make builds of mkamsboot and bootloaders ? |
| 16:59:54 | kugel | I could make it right now |
| 17:00 |
| 17:00:28 | funman | go for it, and mail them to Bagder so he can put them on the download server |
| 17:00:54 | kugel | I'll do them off the branch so that they're still RC |
| 17:00:57 | | Quit mt (Read error: 104 (Connection reset by peer)) |
| 17:01:05 | | Nick mt_ is now known as mt (n=MTee@41.206.137.59) |
| 17:01:19 | funman | kugel: so you want to do a candidate release ? |
| 17:01:20 | kugel | we should probably also announce it on abi |
| 17:01:53 | kugel | funman: do you want to have them final before putting the players supported? |
| 17:02:28 | | Quit mt ("ChatZilla 0.9.84 [Firefox 3.0.11/2009060215]") |
| 17:02:30 | funman | why not? There is no known bugs in mkamsboot and the bootloaders; only in the "normal" rockbox.sansa build |
| 17:02:52 | kugel | it's just a matter of changing the version string |
| 17:03:06 | funman | Note that the c200v2 bootloader is buggy (missing buttons and buggy LCD driver), but the others work fine |
| 17:03:15 | kugel | but I don't see why we should already make them final before. I'd rather do that in parallel with the supported status |
| 17:03:39 | funman | kugel: the choice is up to you ;) |
| 17:03:52 | kugel | I also thought we start off with e200v2 and fuze only, since the others have indeed major bugs |
| 17:04:52 | funman | bootloaders are unaffected, but there is no point of having bootloaders without a supported (or planned shortly) build |
| 17:05:46 | kugel | so what now? |
| 17:06:09 | funman | i don't know, what's your opinion? |
| 17:06:17 | kugel | what I said above |
| 17:06:40 | funman | ok with me |
| 17:06:46 | kugel | we're calling for testing since we want to know about bugs we don't know aout yet |
| 17:07:08 | kugel | there's no use if we get repeated reports of "missing buttons" or "stopping playback" |
| 17:08:21 | | Join Lss [0] (n=Lss@cm33.zeta237.maxonline.com.sg) |
| 17:13:08 | pixelma | mt left? |
| 17:13:39 | funman | 17:02 < mt> I'll be back in an hour or so. |
| 17:16:10 | * | dz hopes he is not causing too much distress to the svn server |
| 17:16:35 | | Join toffe82 [0] (n=chatzill@ppp-71-138-19-215.dsl.frs2ca.pacbell.net) |
| 17:17:00 | bertrik | AFAIK, denes was the last guy to have a serious look at the Meizu flash, but it's been 4 months since he was last online :( |
| 17:18:14 | pixelma | for the logs: the sample .rm (took the vetenskap ones) don't sound correctly on my M5 (there is noise but not a continuous thing). I also notice in my WPS that the reported playback times "jump around" like mad, even negative numbers). |
| 17:18:20 | pixelma | ^mt |
| 17:19:04 | kugel | funman: so I'll mail him the bootloaders and mkamsboot for linux x86, when will you build for win32 and linux x86_64? |
| 17:20:53 | | Join mt [0] (n=MTee@41.233.147.176) |
| 17:21:04 | funman | now, should I use the 1.1RC version in the branch? |
| 17:21:23 | | Join AndyIL [0] (i=AndyI@212.14.205.32) |
| 17:21:24 | kugel | would be nice |
| 17:21:33 | funman | i can send it to you so you mail the whole thing to him |
| 17:22:09 | kugel | too late :> |
| 17:22:38 | kugel | I wrote that he'll receive those from you |
| 17:23:11 | kugel | if you're interested, I put mkamsboot into "ams-testing/mkamsboot-v1.1RC/" in the zip file |
| 17:26:17 | funman | what else is in the zip? |
| 17:26:38 | kugel | the bootloaders in "ams-testing/bootloaders-v1.0RC", but you don't need to rebuild them |
| 17:27:51 | kugel | how do you build for win32? Cygwin? |
| 17:28:14 | funman | cross compiler |
| 17:28:17 | gevaerts | for sansapatcher, I've used mingw in the past |
| 17:28:21 | funman | mingw-* packages in debian/ubuntu |
| 17:28:24 | pixelma | mt: put my results on my M5 in the logs for you... I also checked now that the files play correctly on PC (with VLC) and check the build log, there is a warning in get_metadata and about signedness in libcook/bitstream.c. To be sure I compiled after a make clean and rerun of configure |
| 17:28:25 | kugel | ah I see |
| 17:29:05 | kugel | gevaerts: mkamsboot needs cross-compiler, though, that complicates things |
| 17:29:24 | gevaerts | kugel: in what way? |
| 17:29:43 | kugel | you need arm-elf-gcc |
| 17:29:53 | kugel | i.e. plain mingw won't work |
| 17:30:12 | kugel | and we still don't have the dualboot binaries in svn |
| 17:30:14 | gevaerts | kugel: I don't run mingw on windows :) |
| 17:30:38 | kugel | we should probably do that when we tag mkamsboot 1.1 |
| 17:30:42 | funman | kugel: arm-elf-gcc is not needed anymore ? |
| 17:30:50 | kugel | no? |
| 17:31:09 | funman | dualboot.{c,h} were committed in r21118 |
| 17:31:28 | kugel | oh, I forgot about that |
| 17:31:48 | kugel | plain machine code in C arrays, right |
| 17:31:58 | funman | i think gevaerts meant "mingw" as in "the mingw package provided by debian" ? |
| 17:32:05 | gevaerts | I did indeed |
| 17:32:07 | pixelma | mt: that's with the rm_playback.v1.1.patch one |
| 17:32:21 | kugel | did anyone actually try if it runs on windows too? |
| 17:32:30 | funman | there is also a "mingw" which is similar to cygwin (runs on windows), I don't know if they are related |
| 17:32:33 | funman | kugel: it runs in wine ;) |
| 17:32:53 | gevaerts | kugel: last time I did it, yes. Still sansapatcher though, not mkamsboot |
| 17:33:11 | CIA-71 | New commit by mcuelenaere (r21657): Lua: add script which wraps not-yet ported C functions to Lua |
| 17:33:12 | | Quit AndyI (Read error: 110 (Connection timed out)) |
| 17:33:17 | mt | pixelma: I know about the signedness warning, I asked before if the build server would complain about them too.. Just wanted to check the parsing of the file is correct and that the codec plays. I'll check the codec again to see what could be causing the noise you mentioned. Thanks alot, much appreciated. :) |
| 17:33:19 | kugel | funman: we'll see in the forum thread :) |
| 17:34:46 | pixelma | mt: well, the track isn't recognisable. On the upside, it doesn't crash my player :) |
| 17:35:22 | mt | pixelma: Was just writing a question about it being recognizable. :) |
| 17:39:11 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
| 17:39:20 | CIA-71 | New commit by mcuelenaere (r21658): Add a Rockbox header.. |
| 17:41:14 | Unhelpful | kugel: what? :) |
| 17:41:19 | | Part donutman25 |
| 17:42:20 | kugel | Unhelpful: uhm, that was shortly after waking up, I totally forgot what I wanted |
| 17:43:37 | | Quit alexbobp (Connection timed out) |
| 17:43:53 | kugel | Unhelpful: ah I think I remember: I get audio dropouts and the empty slide often when scrolling in PF. I never get either of those on my e200, a much slower dap |
| 17:44:37 | kugel | there's probably something yielding not enough, any idea what that could be? |
| 17:45:29 | CIA-71 | New commit by mcuelenaere (r21659): Fix actions.lua & buttons.lua make errors |
| 17:45:44 | Unhelpful | there's a yield per slide rendered... don't really think we should make that more often. i don't remember precisely how often the load thread yields, but it has rather high priority. |
| 17:46:12 | kugel | I'm wondering why this isn't a problem on the e200 |
| 17:46:33 | gevaerts | The current sansa bootloader is 5.0, right? |
| 17:46:38 | kugel | yes |
| 17:47:14 | Unhelpful | very hard to say. display runs ahead of load on beast also... perhaps that happens more easily on targets that can finish rendering a screen faster? |
| 17:47:26 | kugel | gevaerts: are you looking into updating the PP bootloaders and patchers? |
| 17:47:32 | gevaerts | yes |
| 17:47:55 | kugel | good. the branch is though for those also |
| 17:48:02 | gevaerts | I'm mainly trying to work out how to set the bootloader version properly |
| 17:48:14 | kugel | I just hacked into show_logo.c |
| 17:48:39 | kugel | passing VERSION=XX to make didn't seem to work |
| 17:49:12 | gevaerts | So this would be 6.0, right? |
| 17:49:18 | kugel | yea |
| 17:50:05 | Unhelpful | maybe we ought to adjust the thread priorities dynamically - boost the load thread if we're running out of slides? |
| 17:50:22 | kugel | even more audio dropouts? |
| 17:50:24 | gevaerts | The problem I see is that it's probably not 6.0 on mr100 and h10 |
| 17:51:01 | rasher | Maybe it should be |
| 17:51:02 | kugel | can't you just do #ifdef IRIVER_H10 for example? |
| 17:51:16 | kugel | or what rasher said |
| 17:52:10 | CIA-71 | New commit by mcuelenaere (r21660): Fix sim_* errors when compiling Lua |
| 17:56:21 | bertrik | I wonder, in the current meizu framework we reserve room for the FIQ and IRQ stacks, but this doesn't seem to be done for the sandisk targets |
| 17:56:38 | bertrik | (looking at boot.lds) |
| 17:56:46 | Unhelpful | kugel: or maybe reduce the render thread priority instead? or not thread loads at all, and just attempt to load threads in the render thread? |
| 17:56:51 | Unhelpful | load *slides*. |
| 18:00 |
| 18:01:39 | | Join BryanJacobs [0] (n=bryanjac@cpe-74-67-191-154.rochester.res.rr.com) |
| 18:04:24 | kugel | Unhelpful: also, what happened to your scrolling work? |
| 18:06:23 | BryanJacobs | plugins take a long time to build, is there some easy way to turn them off with tools/configure? |
| 18:06:27 | | Quit matsl (Read error: 60 (Operation timed out)) |
| 18:06:37 | kugel | I'd like to make pf more "sane" maybe, i.e. not boosting all the time, not updating while it's rendering nothing, no backlight which is constantly on |
| 18:06:39 | rasher | BryanJacobs: plugins=no |
| 18:06:46 | BryanJacobs | rasher: thanks |
| 18:06:48 | rasher | BryanJacobs: In the target's section |
| 18:07:13 | rasher | BryanJacobs: Line 850 onwards |
| 18:07:14 | Unhelpful | kugel: not updating while not scrolling was something i had working on color targets. :/ |
| 18:08:01 | BryanJacobs | rasher: found it, I was hoping there'd be a parameter instead of editing the file <shrug> |
| 18:08:20 | rasher | BryanJacobs: I don't believe there is |
| 18:08:29 | gevaerts | I can compile proper v6.0 bootloaders by editing the makefile, i.e. I can't commit this. Is that good enough? |
| 18:08:38 | Unhelpful | it was part of the core scrolling work... disappeared when my laptop got formatted. it should be much faster to write again. :) |
| 18:08:41 | BryanJacobs | ah well, I'll just turn that off so I don't have to build Doom to test a codec |
| 18:08:55 | kugel | ah I see |
| 18:09:10 | mcuelenaere | BryanJacobs: you could do make bin |
| 18:09:28 | mcuelenaere | (and make bin && make codecs if you want codecs too) |
| 18:09:29 | kugel | that doesn't build codecs, which is probably not what he wants :) |
| 18:10:03 | BryanJacobs | what exactly is "make bin", just the rockbox monolithic core? |
| 18:10:15 | kugel | yea |
| 18:10:22 | mcuelenaere | see make help |
| 18:10:23 | Unhelpful | probably it should unboost when it enters the static scrolling mode... |
| 18:10:28 | | Quit mt (Read error: 104 (Connection reset by peer)) |
| 18:10:30 | kugel | stops after rockbox.<target> |
| 18:11:25 | BryanJacobs | arr, why is move_handle called on a pretty-much-empty buffer?! |
| 18:12:14 | mcuelenaere | hmm is it normal that one can't do rb->audio_play(foo); in sim builds? |
| 18:12:43 | mcuelenaere | results in a error: ‘const struct plugin_api’ has no member named ‘sim_audio_play’ |
| 18:12:56 | | Join webguest24 [0] (n=d1c345e7@gateway/web/cgi-irc/labb.contactor.se/x-af4ef0e42cbd3078) |
| 18:13:16 | BryanJacobs | does anyone know why move_handle doesn't check whether the handle being moved crosses another one? |
| 18:13:23 | CIA-71 | New commit by kugel (r21661): Sansa Fuze: Correct some solitaire controls. |
| 18:13:39 | | Quit webguest24 (Client Quit) |
| 18:13:41 | BryanJacobs | I mean, there's no RINGBUF_ADD_CROSS(loc,moveamt,handlebeingmoved->next) in the source |
| 18:14:55 | BryanJacobs | also, WHY are handles not located right before their data all the time? |
| 18:15:11 | BryanJacobs | I mean, is there a good reason not to have the struct memhandle border that handle's data? |
| 18:15:44 | kugel | Unhelpful: it seems the fuze's lcd is just too slow |
| 18:15:57 | kugel | I don't get drop outs with a faster driver |
| 18:15:59 | rasher | BryanJacobs: the people who know about the playback/buffering system are unfortunately few and far between |
| 18:16:08 | BryanJacobs | hm. |
| 18:16:37 | BryanJacobs | I think I pretty thoroughly understand it now, but I see what I perceive to be poor design choices occasionally... The system looks to have kind of spitballed up |
| 18:17:08 | Unhelpful | kugel: basically, i had it set up so that the scroll functions returned a pointer to the struct scrollinfo, and some extra style flags and a global pointer for custom scroll styles. |
| 18:17:10 | BryanJacobs | like, for example, shrink_handle moving a struct memhandle to be next to its data but other code assuming that already is so |
| 18:17:40 | kugel | no, no they're not totally gone |
| 18:19:25 | kugel | BryanJacobs: feel free to improve ;> |
| 18:20:41 | BryanJacobs | kugel: I've got a system that allows multiple handles almost ready |
| 18:20:53 | BryanJacobs | err, multiple "current" handles |
| 18:21:18 | BryanJacobs | which will in turn allow multiple files and more efficient utilization of buffer space |
| 18:22:55 | kugel | BryanJacobs: I wonder if that could be reused for crossfade. The current implementation is rather awful |
| 18:23:53 | BryanJacobs | kugel: well, the old buffering code actually could have been |
| 18:24:16 | BryanJacobs | previously when you called bufopen() a second time, the buffering system allocated space and requested that buffering the previous file be finished |
| 18:24:27 | BryanJacobs | which means the old file would be memory-resident and thus available to play |
| 18:24:49 | | Quit Sajber^ (Read error: 104 (Connection reset by peer)) |
| 18:24:57 | BryanJacobs | the major change I've made is that a newly allocated handle won't necessarily reside at the buffer write index position |
| 18:36:57 | | Join aaron424 [0] (n=chatzill@adsl-065-013-002-216.sip.asm.bellsouth.net) |
| 18:38:35 | * | bertrik fails at setting up a simple interval timer on the meizu |
| 18:41:19 | CIA-71 | New commit by mcuelenaere (r21662): Lua: implement gui_syncyesno_run |
| 18:41:20 | funman | "to use this software, you must press a specific button every 10ms" |
| 18:42:05 | BryanJacobs | funman: lol |
| 18:44:00 | | Join killan [0] (n=nnscript@c-0efa70d5.06-397-67626721.cust.bredbandsbolaget.se) |
| 18:45:11 | | Quit funman ("free(random());") |
| 18:46:24 | | Join Horscht86 [0] (n=Horscht2@p4FD4DAB9.dip.t-dialin.net) |
| 18:51:29 | | Quit flydutch ("/* empty */") |
| 18:52:43 | *** | Saving seen data "./dancer.seen" |
| 18:53:44 | BryanJacobs | see, this is the kind of code I'm talking about: |
| 18:54:01 | | Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) |
| 18:54:01 | BryanJacobs | copy_mp3entry((struct mp3entry *)h->data, (const struct mp3entry *)src); |
| 18:54:14 | BryanJacobs | h->data is a size_t >_< |
| 18:54:30 | BryanJacobs | you can't cast it to struct mp3entry* and have it work |
| 18:54:40 | BryanJacobs | this code must not ever be exercised |
| 18:54:53 | rasher | Oh dear |
| 18:57:47 | | Quit bluebrother (Read error: 104 (Connection reset by peer)) |
| 18:58:10 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
| 18:58:26 | | Quit tvelocity (Remote closed the connection) |
| 18:58:40 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 19:00 |
| 19:03:31 | | Join AndyI [0] (i=AndyI@212.14.205.32) |
| 19:03:49 | | Quit Horschti (Read error: 110 (Connection timed out)) |
| 19:07:02 | | Quit flydutch ("/* empty */") |
| 19:07:30 | | Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) |
| 19:08:21 | | Quit AndyI (Client Quit) |
| 19:09:30 | | Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) |
| 19:10:35 | JdGordon | kugel: pong |
| 19:11:40 | kugel | JdGordon: ping |
| 19:11:55 | JdGordon | you pinged me yesterday? |
| 19:12:21 | kugel | yea |
| 19:12:33 | JdGordon | bertrik: congrats! |
| 19:12:43 | kugel | I can't recall why though |
| 19:12:47 | bertrik | JdGordon, thanks! |
| 19:13:46 | gevaerts | kugel: maybe the exit to WPS thing? |
| 19:14:11 | kugel | right! |
| 19:14:16 | JdGordon | anyone want to test out 10406? I'm pretty sure its ready for commit, assumine ghtere is no objection |
| 19:14:39 | | Quit AndyIL (Read error: 110 (Connection timed out)) |
| 19:14:56 | kugel | I won't object, unless you still can't tell me more about your doubts regarding going to the wps from a plugin :) |
| 19:14:59 | rasher | JdGordon: why would you want the statusbar to be enabled on some screens (which?) but not others? |
| 19:15:27 | rasher | oh, display. Ignore me. |
| 19:15:55 | | Join mt [0] (n=mt@41.233.147.176) |
| 19:15:55 | JdGordon | lovely terminolody we have isnt it? :p |
| 19:16:12 | rasher | It makes sense, I was just not thinking |
| 19:22:30 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 19:24:18 | pixelma | bluebrother: is there a macro I could use to have e.g a file called iaudio-remote.svg included for all Iaudios? I know there is something similar for the screenshots but didn't know whether and how I could use it for the player's images (and didn't even see where either \specimg or \genericimg are defimed, one is in preamble the other a mystery to me) |
| 19:24:24 | kugel | OBJECT! You have trailing spaces in the recscreen hunk |
| 19:25:28 | | Nick Horscht86 is now known as Horscht (n=Horscht2@p4FD4DAB9.dip.t-dialin.net) |
| 19:25:51 | bertrik | weird, timer A works, but timer B, C, D doesn't quite work |
| 19:26:33 | | Join AndyI [0] (i=AndyI@212.14.205.32) |
| 19:27:15 | kugel | JdGordon: why aren't you using VP_SB_ONSCREEN (for statusbar_enabled in viewport.c, for example)? |
| 19:27:30 | mt | pixelma: ping |
| 19:27:45 | pixelma | pong |
| 19:27:59 | mt | Are you free for a bit more testing of rm ? |
| 19:28:23 | JdGordon | kugel: instead of? |
| 19:28:39 | kugel | |= 2 in that case |
| 19:28:48 | pixelma | mt: a bit (as I'm also working on the manual and compile with cygwin, so a bit slower ;) ) |
| 19:29:32 | kugel | you could also extent the macros to have another bit for top or bottom and save a whole lot of #ifdefs |
| 19:30:56 | | Join Sajber^ [0] (n=Sajber@h-142-185.A213.priv.bahnhof.se) |
| 19:31:06 | bluebrother | pixelma: \genericimg and \specimg are defined in the platform files |
| 19:31:18 | mt | pixelma: OK, I'll just upload the new patch so that you could test it whenever you have time. |
| 19:31:52 | bluebrother | you should be able to use \opt{iaudio} |
| 19:34:49 | pixelma | I'd like to have it included automatically like the xxx-front images are, just that it also uses iaudio-remote instead of only m3-remote so I can use one image for all 3 Iaudios |
| 19:35:14 | | Quit flux (Read error: 54 (Connection reset by peer)) |
| 19:35:16 | pixelma | can I assign \specimg twice? |
| 19:35:36 | pixelma | guess not |
| 19:35:59 | bluebrother | as in two values? No |
| 19:36:02 | | Join saratoga_home [0] (n=41becb3b@gateway/web/cgi-irc/labb.contactor.se/x-4eeb644110ee8e6e) |
| 19:36:37 | bluebrother | you could use \playerman though that uses a capital as first letter. |
| 19:36:42 | saratoga_home | mt: wma needed a define to convert ROCKBOX_BIG_ENDIAN to WORDS_BIGENDIAN for the ffmpeg bistream parsing |
| 19:38:21 | mt | pixelma: When you're free to test, you could try the new patch on a clean checkout or just do this on the v1.1 patched one : http://pastebin.com/m4a6113c5 |
| 19:38:49 | mt | saratoga_home : Just changed WORDS_BIGENDIAN in bswap.h in the new patch. |
| 19:39:05 | saratoga_home | ah then i am too slow |
| 19:39:09 | | Quit BryanJacobs ("Java user signed off") |
| 19:40:11 | pixelma | bluebrother: the thing is that it will be different for the Irivers but the Iaudios could use the same image. I remember that genericimg is a bit flexible there - e.g. use xxx-ondiofm if it exists otherwise xxx-ondio etc. I hoped there could be a similar thing there (the other one uses specimg but that's tied to screenshots, right?) |
| 19:40:35 | mt | saratoga_home: I'd say it's me that's slow (very late reply) :) |
| 19:40:58 | pixelma | bluebrother: sorry, genericimg in the end too |
| 19:41:15 | mt | pixelma: Still didn't fix the signedness warnings though, so you'll still be getting them. |
| 19:41:24 | bluebrother | well, we could of course invent something similar here :) |
| 19:41:50 | mt | saratoga_home: Do you know if the build server complains about comarisons between signed and usnsigned or not ? |
| 19:41:52 | pixelma | would be nice :) |
| 19:42:51 | kugel | mt: why don't you just fix it instead? |
| 19:43:02 | | Nick n00b81 is now known as n00b81|afk (n=taylor@unaffiliated/n00b81) |
| 19:43:27 | | Join Blue_Dude [0] (n=chatzill@uslec-66-255-178-43.cust.uslec.net) |
| 19:43:41 | pixelma | mt: will do |
| 19:44:18 | | Join flux [0] (i=flux@jolt.modeemi.cs.tut.fi) |
| 19:44:22 | mt | kugel: I'm working on it now, just focusing on fixing the BE issue first. |
| 19:44:28 | mt | pixelma: Thanks. |
| 19:45:15 | saratoga_home | mt: yes it will complain |
| 19:45:21 | bluebrother | pixelma: I'm out the next hour or so. Will try to give it a look later if time permits. |
| 19:45:43 | saratoga_home | the build servers are just various developer's PCs, so they should behave exactly as your own |
| 19:46:08 | pixelma | bluebrother: nice, take your time - have to do other things myself either way :) |
| 19:46:47 | pixelma | mt: a make clean to be safe first or is it not needed? |
| 19:46:55 | | Join andrea [0] (i=4f345713@gateway/web/freenode/x-3ae63a4014ef72d7) |
| 19:47:12 | mt | pixelma: If you followed the pastebin it is not needed. |
| 19:47:23 | | Nick andrea is now known as Guest33434 (i=4f345713@gateway/web/freenode/x-3ae63a4014ef72d7) |
| 19:49:40 | | Quit Guest33434 (Client Quit) |
| 19:55:31 | JdGordon | kugel: see anything else in the diff that should be fixed? |
| 19:57:21 | pixelma | mt: I don't notice any difference, but I just notice that bswap.h wasn't listed as compiled again - shouldn't it? |
| 19:57:23 | | Join sakuramboo [0] (n=sakuramb@ool-43504efe.dyn.optonline.net) |
| 19:58:15 | kugel | I'm not sure whether "remote_statusbar" is needed, I'd rather see the VP_SB_* macros to be used, but I guess that's not really doable with the current settings code |
| 19:58:28 | saratoga_home | pixelma: its a header, so only the files that include it are recompiled |
| 19:58:44 | mt | pixelma: it should recompile libcook/bitstream.c and libcook/cook.c |
| 19:59:14 | pixelma | yes, it did |
| 19:59:40 | pixelma | also codecs/cook |
| 19:59:48 | CIA-71 | New commit by mcuelenaere (r21663): Also make rocklib_aux.c depend on $(LUA_OBJ) |
| 19:59:56 | pixelma | .c |
| 20:00 |
| 20:01:05 | mt | I'll recheck. |
| 20:05:35 | sakuramboo | on the iPod versions, is there a function to stop the arm on the hard drive from moving when the "battery dead" symbol flashes on the screen? |
| 20:06:10 | CIA-71 | New commit by mcuelenaere (r21664): Take 2 at 'Consolidate all fixed point math routines in one library' (FS #10400) by Jeffrey Goode |
| 20:06:21 | | Join alexbobp [0] (n=alex@ppp-70-253-66-27.dsl.austtx.swbell.net) |
| 20:07:57 | mt | pixelma: could you pastebin the output of make ? |
| 20:08:03 | CIA-71 | New commit by jdgordon (r21665): FS #10406 - split the statusbar setting into one for each display, and allow the bar to be at the top or bottom of the display |
| 20:11:09 | pixelma | mt: from the second run? |
| 20:11:37 | Bagder | hm bootloader/sandisk-sansa/[model] is the path to the sansa PP bootloaders |
| 20:11:48 | Bagder | anyone has a suggestion for the ams ones? |
| 20:12:02 | kugel | mcuelenaere: many files had svn:executable |
| 20:12:04 | Bagder | or should we have them in the same spot? |
| 20:12:06 | mt | pixelma: yes, after editing bswap. |
| 20:12:10 | Bagder | the model names are different |
| 20:12:14 | mcuelenaere | kugel: bah, git.. |
| 20:12:40 | kugel | mcuelenaere: I mean in the patch, I don't know what git does to those |
| 20:13:05 | mcuelenaere | ah, I don't know how to set SVN properties in git |
| 20:13:05 | saratoga_home | model is e200v2 right? |
| 20:13:13 | Bagder | I guess, yes |
| 20:13:20 | kugel | Bagder: Same spot I'd say. |
| 20:13:23 | mcuelenaere | patch should ignore SVN properties; but git has its own version (git apply) |
| 20:13:59 | kugel | but IIRC git svn doesn't handle setting properties |
| 20:15:51 | pixelma | mt: http://rockbox.pastebin.ca/1484862 but I try again in case I made a mistake somewhere |
| 20:16:19 | mcuelenaere | kugel: then I suppose no SVN property will be set/changed :) |
| 20:17:53 | mt | pixelma: The audio is still unrecognizable, right ? |
| 20:19:12 | kugel | mcuelenaere: seems so :) |
| 20:20:04 | pixelma | AlexP: hope that change merged correctly now... |
| 20:20:05 | dz | alright, only 1600 revisions to go until I stop abusing the svn server -_- |
| 20:20:42 | kugel | what are you doing? |
| 20:21:03 | dz | git svn clone |
| 20:21:19 | kugel | dz: there's a git repo that already has this done |
| 20:21:24 | dz | :< |
| 20:21:25 | CIA-71 | New commit by pixelma (r21666): Manual: clean up some things related to the inclusion of the remotes. For button tables that use the 'Action' defines use HAVEREMOTEKEYMAP instead of ... |
| 20:21:43 | kugel | dz: http://www.rockbox.org/twiki/bin/view/Main/GitVersionControl#The_public_Rockbox_git_repositor |
| 20:22:43 | JdGordon | sweet, I get to blame the delta from my patch on mcuelenaere :) |
| 20:22:44 | kugel | I cloned that and got the full svn history |
| 20:23:09 | mcuelenaere | JdGordon: heh, no you don't; my patch doesn't change binsize ;) |
| 20:23:16 | mcuelenaere | well not really 'mine' |
| 20:23:20 | Bagder | ok, the ams bootloaders and mkamsboot are now placed on the download server |
| 20:23:23 | JdGordon | not at all? :( |
| 20:23:33 | Bagder | but the version numbers are going to look even crazier now |
| 20:23:35 | | Join Rondom [0] (n=Rondom@dslb-084-057-179-018.pools.arcor-ip.net) |
| 20:23:36 | mcuelenaere | it shouldn't, only decrease plugin binsize |
| 20:23:51 | AlexP | pixelma: They should probably be moved to be after all the main unit ones and just before the description |
| 20:24:21 | kugel | Bagder: I don't see then, is this due to the mirror business? |
| 20:24:26 | kugel | them* |
| 20:24:27 | AlexP | pixelma: Otherwise any targets with the main unit keys opted after the HAVEREMOTEKEYMAP will have the main and remote keys swapped in the tables |
| 20:24:36 | Bagder | yes, it'll take up to an hour for the mirrors to show them |
| 20:25:03 | pixelma | AlexP: how so? |
| 20:25:17 | | Quit SirFunk (Remote closed the connection) |
| 20:25:51 | pixelma | mt: yes, still unrecognisable |
| 20:25:56 | CIA-71 | New commit by gevaerts (r21667): bump sansapatcher version |
| 20:26:03 | AlexP | pixelma: If there is an \opt{HAVEREMOTE}{Remote key} then \opt{Some other keymap}{Main Key} Description |
| 20:26:11 | Unhelpful | mcuelenaere: you can't set svn props in git. ask somebody who doesn't hate perl to fix that. ;) |
| 20:26:23 | AlexP | pixelma: Then it'll expand to Remote Key Main Key Description, and not Main, Remote, Desc |
| 20:26:30 | * | JdGordon curses the player target |
| 20:26:31 | mt | pixelma: ok. Thanks. |
| 20:26:50 | AlexP | pixelma: And I put the h100_remote_keymap opts right after the H100 opt |
| 20:27:17 | AlexP | pixelma: So if there are targets with remotes that have the key for that table opted after the h100 was, they will be in the wrong order |
| 20:27:19 | Unhelpful | when adding files, i generate a patch from git and apply it to an svn checkout so i can add properties. |
| 20:27:42 | AlexP | pixelma: Anyway, I'll go through and check in a bit |
| 20:28:04 | pixelma | AlexP: ah, yes. For targets with remote |
| 20:28:44 | | Quit _Auron_ ("Infinity repeatedly denies rumours of plotting with zero to bring down the Universe.") |
| 20:29:19 | pixelma | hrrmm... forgot to mention that with this there are already some tables filled out in the Iaudio M3 manual... |
| 20:29:34 | AlexP | I'll just move the remote ones to the end |
| 20:29:38 | AlexP | That way it is sure |
| 20:30:03 | CIA-71 | New commit by jdgordon (r21668): fix yellow |
| 20:30:19 | | Join matsl [0] (n=matsl@host-90-233-230-237.mobileonline.telia.com) |
| 20:30:39 | rasher | JdGordon: that's a really poor commit message |
| 20:30:48 | JdGordon | which one? |
| 20:30:53 | rasher | "fix yellow" |
| 20:31:06 | rasher | (and yeah, I know you're not the only one) |
| 20:31:16 | pixelma | AlexP: so which tables will you change now? I ask because the ones that don't use \ActionSomething still need changing for IAUDIO_RC_PAD |
| 20:31:17 | JdGordon | mcuelenaere: you sure your patch doesnt affect bin size? there is no way mine could have done that much of a hit |
| 20:31:35 | mcuelenaere | according to Blue_Dude it shouldn't.. |
| 20:31:36 | JdGordon | rasher: welcome to rockbox... you know we've been doing that sort of message for *years* right? |
| 20:31:39 | kugel | JdGordon: haha, it was so totally clear that this happens :D |
| 20:31:52 | JdGordon | ? |
| 20:31:54 | rasher | JdGordon: What did I just say? Doesn't make it any better. |
| 20:32:11 | rasher | I think it's a very poor "tradition" |
| 20:32:18 | kugel | JdGordon: that a commit of yours clashes with the player |
| 20:32:23 | JdGordon | ah |
| 20:32:25 | AlexP | pixelma: Definately the action ones - for the others do you think it is best to have all the remote ones together at the end, or to keep main and remote together? |
| 20:32:35 | Blue_Dude | Yeah, I just noticed that the bins did grow some. |
| 20:32:43 | pixelma | JdGordon, mcuelenaere: looks like BlueDude's change from the last time - as the Archos binsize hit is a lot smaller |
| 20:33:08 | Blue_Dude | What I'm not sure if is *why* they should grow. |
| 20:33:14 | JdGordon | yeah, less though but its still there |
| 20:33:21 | Blue_Dude | I mean, it's mostly moving code around, not adding it. |
| 20:33:33 | JdGordon | I dont care about it, just making sure I'm not going to have to revert because of it :) |
| 20:34:01 | kugel | Blue_Dude: take a peek at utils/analysis/bloat-o-meter.py or objdiff.py |
| 20:34:02 | Unhelpful | rasher: but it's so thoroughly entrenched that as a newcomer to the project i felt kind of silly giving verbose descriptions of build fixes |
| 20:34:39 | rasher | Unhelpful: Yeah. I don't like it one bit. |
| 20:34:42 | Blue_Dude | kugel: if I had a clue what you just said, I might. I don't know how to use those tools though. |
| 20:35:34 | kugel | Blue_Dude: go back 1 revision, build the main binary (rockbox.elf), then to HEAD again and build the main binary, and pass both elf files to one of those scripts |
| 20:35:48 | pixelma | AlexP: I think at the end is best there too (so it's column after column and it also leaves the possibility to combine them if thy use the same RC button) |
| 20:35:56 | kugel | then you'll see what exactly caused the binsize increase |
| 20:36:03 | AlexP | pixelma: Yes, I think so too |
| 20:36:20 | AlexP | pixelma: I'll do actions first, then come to plugins later :) |
| 20:36:34 | Blue_Dude | kugel: over my head. I'll take a look though. |
| 20:36:40 | mcuelenaere | kugel, Blue_Dude: on it |
| 20:36:58 | Blue_Dude | Thanks. |
| 20:37:03 | mt | saratoga_home: I'll try using wma's bswap instead. |
| 20:37:08 | | Join lilltiger [0] (n=lilltige@82.145.152.217) |
| 20:38:00 | pixelma | AlexP: and I thought I could let you add the IAUDIO_RC_PAD there too while you are at it ;) |
| 20:38:08 | AlexP | Where? |
| 20:38:12 | AlexP | plugins? |
| 20:38:20 | pixelma | yes ;) |
| 20:38:31 | mt | pixelma: One last try - http://pastebin.com/m16935b6f :) |
| 20:38:35 | mcuelenaere | Blue_Dude: http://pastie.org/534925 |
| 20:38:46 | AlexP | hehe, I have h100 plugins to do first :) |
| 20:38:53 | mcuelenaere | but fp_factor & fp_sincos aren't build for main Rockbox, are they? |
| 20:39:39 | JdGordon | looks like they are |
| 20:40:09 | * | mcuelenaere wonders about the __cmpdi2 routine, looks like a floating point one.. ? |
| 20:41:35 | pixelma | AlexP: that we don't work on the same files, I'm a bit confused what you are doing currently |
| 20:41:47 | pixelma | or should I just wait for a commit? |
| 20:41:49 | saratoga_home | why is replaygain.c doing fp mul and fp divs anyway? |
| 20:42:54 | Blue_Dude | replaygain need to calculate a gain factor from the replaygain decibel tags. |
| 20:43:10 | saratoga_home | why can't that be done in fixed precision? |
| 20:43:26 | Blue_Dude | fp is fixed point here. |
| 20:43:42 | kugel | mcuelenaere, Blue_Dude: fp_sincos is within #if (!defined(PLUGIN) && !defined(CODEC)) actually, so for core only |
| 20:43:48 | AlexP | pixelma: Nothing in actual fact |
| 20:43:58 | mcuelenaere | kugel: yes I know, that's why I'm wondering what's wrong here |
| 20:43:59 | kugel | fp_factor I mean |
| 20:44:00 | AlexP | pixelma: I was going to move all the action related ones to the end |
| 20:44:09 | AlexP | pixelma: But they are already there |
| 20:44:11 | Blue_Dude | kugel: right. Only replaygain needs it for now. |
| 20:44:21 | mcuelenaere | kugel: perhaps I switched the arguments to bloat-o-meter.py |
| 20:44:30 | CIA-71 | New commit by gevaerts (r21669): fix bin2c.c path |
| 20:44:41 | AlexP | pixelma: I'll do plugins another day, so don't worry for now |
| 20:44:51 | Blue_Dude | But replaygain had something like it already. Why the delta? |
| 20:44:53 | kugel | mcuelenaere: no, it would show a overall decrease then |
| 20:45:05 | | Join rob [0] (n=rob@adsl-76-235-168-174.dsl.klmzmi.sbcglobal.net) |
| 20:45:12 | saratoga_home | Blue_Dude: are you sure? I can't even tell what fp_mul is doing |
| 20:45:15 | CIA-71 | New commit by gevaerts (r21670): fix bin2c.c path |
| 20:45:35 | mcuelenaere | Blue_Dude: replaygain actually shows a decrease in size (convert_gain) |
| 20:45:48 | pixelma | AlexP: well, if I add the Iaudio one anyways... although moving is a bit more work than search and replace... |
| 20:45:57 | Blue_Dude | fp_mul is a macro. As far as I know it's not even used by anything. fp_mul64 is an internal macro in fixedpoint.c that is used. |
| 20:46:10 | kugel | I'm also unsure why fp_factor is so big |
| 20:46:17 | AlexP | pixelma: yeah :/ |
| 20:46:26 | AlexP | pixelma: But sure, if you are going to add them :) |
| 20:46:27 | saratoga_home | on the functions are defined out |
| 20:46:33 | saratoga_home | in that case maybe we could just delete them? |
| 20:46:43 | Blue_Dude | I did rewrite fp_factor. It wasn't legacy code. But it's not that big either... |
| 20:47:16 | Blue_Dude | You can comment out fp_mul. But fp_factor is being used. I commented out everything else that's not in use. |
| 20:47:20 | kugel | probably because fp_exp10 is inlined by gcc, and it contains lot of 64bit data |
| 20:47:24 | Blue_Dude | Or conditionally compiled them. |
| 20:47:52 | Blue_Dude | fp_exp10 was in replaygain.c before though. |
| 20:48:09 | Blue_Dude | My version is actually a bit leaner. One less function call. |
| 20:48:32 | kugel | Blue_Dude: the old one doesn't have 64 datatyes though, it seems |
| 20:48:55 | Blue_Dude | Well I did rewrite it to be capable of more than a single fixed point precision though. |
| 20:49:14 | Blue_Dude | Um. I think it did internally... |
| 20:49:19 | kugel | you should probably said that :) |
| 20:49:22 | Blue_Dude | Crud, I can't remember. |
| 20:49:33 | pixelma | mt: audio works now! :D but the playback time jumping is still there (makes the progressbar look... interesting too) |
| 20:50:33 | kugel | Blue_Dude: any idea what's the speed hit if this? I think we could live with 1.6K if it doesn't have a huge speed hit |
| 20:51:05 | Blue_Dude | The speed should be fine. That's one reason I streamlined the exp10 routine. |
| 20:51:09 | mt | pixelma: Thanks ! :) \o/ |
| 20:51:19 | pixelma | mt: guess that also has to do with missing seeking report? |
| 20:51:47 | kugel | sadly, there's no easy way to detect this :( |
| 20:51:55 | gevaerts | Anyone with an e200r around? |
| 20:51:57 | Blue_Dude | kugel: Also, fp_factor just isn't called that often. |
| 20:52:04 | | Join stripwax [0] (n=dave@87-194-34-169.bethere.co.uk) |
| 20:52:31 | kugel | what's the gain of double precision here? |
| 20:52:48 | *** | Saving seen data "./dancer.seen" |
| 20:53:30 | mt | pixelma: I don't think so .. I don't have a jumping progress bar like what you're mentioning .. does happen all the time or when playback is approaching the end ? |
| 20:53:33 | Blue_Dude | kugel: the old routine was locked into 12 bits of fractional precision. If that was raised much, it would overflow very easily. Exp generates bigs numbers. |
| 20:53:47 | pixelma | mt: all tj |
| 20:53:56 | pixelma | s/tj/the time |
| 20:54:05 | saratoga_home | Blue_Dude: does anything need more precision? |
| 20:55:30 | Blue_Dude | I dunno. My original goal was to consolidate a library. The replaygain stuff was very useful, but locked into a specific implementation. I widened it some. |
| 20:55:33 | mt | pixelma: I guess I would be able to see than on a sim build, so I'll work on that later. Thanks a lot for your help. |
| 20:56:21 | kugel | pixelma: I figure you can test the PLA rework now? :D |
| 20:56:45 | Blue_Dude | I suppose I could go back and make it a fixed 12 bit routine to get the size back down. I'm not sure it would help much. |
| 20:57:27 | pixelma | mt: you're welcome. Hopefully this is really a problem that shows also in the sim... :) |
| 20:58:02 | mt | saratoga_home: since wma's bswap.h is already optimised, should I point cook's bitstream to it or have another copy for cook ? |
| 20:58:02 | Blue_Dude | One problem I found was that even with 12 bits, the routine would break - overflow with some inputs and give wildly incorrect results. Going to long long integers internally fixed that. |
| 20:58:07 | mt | pixelma: hopfully :) |
| 20:58:09 | CIA-71 | New commit by mcuelenaere (r21671): Onda VX747 backlight: use a higher frequency to reduce flickering |
| 20:58:29 | Blue_Dude | It's possible that we've been getting occasional bad numbers all along. |
| 20:58:46 | saratoga_home | mt: for now I would duplicate it |
| 20:59:02 | pixelma | kugel: trying out some plugins take a little bit more time to test though... |
| 20:59:12 | Blue_Dude | I don't believe I have to do this two days ina row, but I gotta bail to my paying job. |
| 21:00 |
| 21:00:13 | kugel | so it actually was calculating wrong regularly (not only rarely)? |
| 21:00:17 | Blue_Dude | If there are other issues, I'll check the logs when I get home. |
| 21:00:19 | mt | pixelma: What's your target again ? |
| 21:00:27 | saratoga_home | mt: do you think they are called frequently enough to need further optimization? i admit i haven't looked at that file since we commited it |
| 21:00:58 | pixelma | mt: Iaudio M5 (my target from the coldfire family) |
| 21:01:07 | saratoga_home | kugel: hopefully plugin developers were aware their operations can overflow if they give very large values |
| 21:01:31 | Blue_Dude | kugel: yeah. Even though you thought you were giving it numbers in range, it would break internally. |
| 21:01:32 | kugel | replaygain is a core thing |
| 21:01:45 | | Quit r0b- (Read error: 110 (Connection timed out)) |
| 21:02:03 | kugel | Correct code is worth it I guess |
| 21:02:04 | Blue_Dude | Give exp10 2.0 and it would work. 2.4 would spit out a negative number. |
| 21:02:07 | Blue_Dude | etc. |
| 21:02:32 | kugel | but I think it should've been a seperate patch |
| 21:02:34 | saratoga_home | kugel: replaygain checks for overflow and clamps values to prevent it |
| 21:02:53 | Blue_Dude | No it would break on in range numbers too. |
| 21:03:09 | Blue_Dude | Crud. No time. Sorry guys. |
| 21:03:12 | | Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") |
| 21:04:34 | | Nick hd is now known as HellDragon (i=jd@Wikipedia/HellDragon) |
| 21:05:18 | mt | saratoga_home: I don't think further optimizations would make a significant change. I'm a bit in a hurry though, so I'll dig deeper later. |
| 21:05:26 | saratoga_home | kugel: see the convert_gain function in replaygain.c |
| 21:05:33 | saratoga_home | ok |
| 21:05:34 | kugel | saratoga: the ams installers are on the download server now. I and funman planned to make a forum post in the "Official test build" forum (ie not put it under support for now)" |
| 21:05:37 | saratoga_home | just curious |
| 21:06:16 | saratoga_home | is swap32 assemblerized on arm? |
| 21:07:32 | pixelma | kugel: I agree with Llorean on the repeat for the quit button one. Some plugins on my Ondio (and on the c200) use it at least for an additional exit without menu (e.g. sudoku) and I don't find it inconvenient at all, easier than going through the menu or a button combo and you need the other buttons, can't remember accidentally shutting down because of it (hard power off is only after 10..15 seconds on both) |
| 21:07:51 | kugel | .... |
| 21:08:09 | kugel | software poweroff isn't always disabled |
| 21:09:17 | CIA-71 | New commit by bertrik (r21672): S5L8700: implement kernel timer |
| 21:09:49 | kugel | ok, then let's rate convenience over unexpected behavior. |
| 21:09:55 | pixelma | still, no accidental shutdown for me and it's better than the alternatives. I don't know which current PLA plugins could be affected now though |
| 21:10:13 | pixelma | I don't think it's unexpected |
| 21:10:33 | kugel | I can't say long power is expected to do anything but power of on a e200 |
| 21:11:27 | pixelma | well, the Ondio has a lot less buttons - and e.g. a stop in the WPS or the Radio is a long Off too (short Off for pause) |
| 21:11:44 | pixelma | there |
| 21:11:45 | kugel | it has enough for my PLA |
| 21:12:02 | gevaerts | I've uploaded Portalplayer RC bootloaders to my webspace, and started a thread in Official Test Builds |
| 21:12:28 | pixelma | what do you need - four directions, select, quit (or a menu too?) |
| 21:12:46 | kugel | these 6, yes |
| 21:12:56 | pixelma | so no menu? |
| 21:13:06 | kugel | yes, no menu |
| 21:13:23 | pixelma | where would you put it if you need one? |
| 21:13:39 | kugel | put it onto quit, and have a exit item |
| 21:14:17 | | Quit BHSPitLappy (Remote closed the connection) |
| 21:14:38 | pixelma | as I said, an additional way to exit is quite convenient there and works nicely in some plugins |
| 21:14:49 | CIA-71 | New commit by bertrik (r21673): Update initialisation and display of debug info in meizu M3 bootloader |
| 21:15:11 | pixelma | well maybe that's non-PLA then |
| 21:15:16 | kugel | No, it's ok, I'll do it. Still better than the current pla |
| 21:15:27 | kugel | We'll get reports if it's such an issue |
| 21:15:52 | pixelma | you don't have to use the repeat action, do you? |
| 21:16:57 | kugel | not necessarily, no |
| 21:21:14 | saratoga_home | gevaerts: can you do sansapatcher too? |
| 21:21:15 | kugel | gevaerts: you don't plan to commit to the branch? |
| 21:21:38 | gevaerts | saratoga_home: sansapatcher should be in there |
| 21:21:38 | gevaerts | kugel: commit what? |
| 21:21:59 | kugel | version string maybe, I don't know |
| 21:22:11 | gevaerts | All changes to svn code are committed. I put the version numbers in build/Makefile |
| 21:22:34 | kugel | hm |
| 21:22:49 | kugel | we won't get a tagged release resulting in the same bootloader then, though |
| 21:23:10 | gevaerts | no. That's a problem... |
| 21:23:20 | saratoga_home | can't we just hardcode the bootloader file? |
| 21:23:30 | | Quit toffe82 (Remote closed the connection) |
| 21:23:41 | kugel | that's what I did. I don't think it's a big problem |
| 21:23:43 | Llorean | kugel: On what target is software poweroff happening in plugins? I asked you this earlier and you told me it's "not relevant" but it clearly is if you're citing it./ |
| 21:23:44 | gevaerts | hm, since I now made all PP bootloaders 6.0, I could hardcode them |
| 21:24:17 | JdGordon | oh crud... does the manualk still have the config values listing? |
| 21:24:37 | Llorean | And why can't we make the quit shortcut work on those by having it quit, then if continued to be held for another long press, soft poweroff? |
| 21:24:49 | kugel | Llorean: run bubbles on the e200, and keep pressing stop ingame, for example |
| 21:25:06 | CIA-71 | New commit by gevaerts (r21674): bump version for new release. No code changes |
| 21:25:23 | pixelma | JdGordon: what? |
| 21:25:24 | | Part stripwax |
| 21:25:26 | saratoga_home | speaking of which, could we make the poweroff time a little shorter on the e200/e200v2? |
| 21:25:34 | saratoga_home | i often find myself letting go too soon |
| 21:25:56 | Llorean | kugel: And it can be disabled on that target without any serious repercussions. Is there anywhere it's actually *necessary* that it not exit the plugin first, like i suggested? |
| 21:26:02 | saratoga_home | even a half second shorter would be really nice i think |
| 21:26:12 | kugel | Llorean: it's fine, you don't need to discuss |
| 21:26:21 | kugel | I will do the CANCEL_REPEAT thing |
| 21:26:21 | pixelma | saratoga_home: I'd say that's better than accidentally shutting down, and people are different |
| 21:26:35 | pixelma | saratoga_home: I admit that I never tried an e200 though |
| 21:26:40 | JdGordon | pixelma: is this change ok? http://pastebin.com/m7b73966e |
| 21:26:50 | saratoga_home | it seems worse to me on the e200v2 for some reason |
| 21:27:03 | saratoga_home | as if the button sensitivity where different |
| 21:27:23 | saratoga_home | pixelma: its a fairly long delay on the e200, so i've never accidently shutdown |
| 21:27:36 | saratoga_home | much longer then i would naturally press a button for in the UI |
| 21:28:11 | JdGordon | can someone reword the statusbar text in the manual for the behaviour please? |
| 21:28:41 | CIA-71 | New commit by gevaerts (r21675): Set PP bootloader version to 6.0 |
| 21:28:54 | pixelma | JdGordon: just use "renote" for the opt, that's parsed from the languages' features.txt and is only valid for lcd remotes (as that's what it's used in the languages for) |
| 21:28:59 | JdGordon | hmm, actually I can maybe do it |
| 21:29:00 | saratoga_home | yahhh new bootloaders |
| 21:29:11 | gevaerts | kugel: better? ;) |
| 21:29:17 | kugel | hehe |
| 21:29:47 | kugel | I just don't think we need a super sophisticated system if we're doing a mere release in two years |
| 21:30:09 | kugel | but JdGordon's idea was a good one, imo. |
| 21:30:11 | saratoga_home | with any luck we'll only need one more release, and that will be if we ever get USB in the PP bootloaders |
| 21:30:41 | gevaerts | kugel: we need a sophisticated system just because we only release every few years. If not, things *will* go wrong |
| 21:31:20 | kugel | Maybe JdGordon should extend his patch to bootloaders |
| 21:31:34 | JdGordon | I have a patch somewhere on the tracker to add a RB_RELEASE define which can be passed to configure... |
| 21:32:05 | | Quit saratoga_home ("CGI:IRC (EOF)") |
| 21:32:38 | kugel | gevaerts: the patcher also have a version number, btw :) |
| 21:33:08 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 21:33:13 | JdGordon | pixelma: http://pastebin.com/m1e0175c0 ? |
| 21:33:18 | kugel | sansapatcher 0.8 is due |
| 21:33:26 | gevaerts | kugel: I know :) |
| 21:33:55 | gevaerts | That's why I updated those as well! |
| 21:34:12 | kugel | at least we got the stone rolling, it was kinda annyoing that we didn't manage to release new bootloaders |
| 21:34:15 | JdGordon | FS #10278 is my changes to the release scripts which might be useful for the bootloader |
| 21:35:00 | CIA-71 | New commit by mcuelenaere (r21676): Lua: use rb->screens[] to do painting |
| 21:37:24 | pixelma | JdGordon: seems better with the opt, just a typo in the item: Rremote - btw. I don't think I would put the current statusbar at the bottom... |
| 21:37:27 | kugel | soo, let's wait for FlynDice's opinion and then post the AMS thread |
| 21:37:53 | | Nick n00b81|afk is now known as n00b81 (n=taylor@unaffiliated/n00b81) |
| 21:38:12 | JdGordon | pixelma: some people might.... I figured it would be fun to add anyway seen as I was splitting the setting up |
| 21:38:26 | | Join Lear [0] (i=chatzill@rockbox/developer/lear) |
| 21:38:32 | JdGordon | that diff is OK to commit after the typo fix? I cant build the manual so have no idea if its correct |
| 21:38:52 | kugel | we will see tomorrow |
| 21:38:58 | pixelma | turning it off on the remote only xseems nice though |
| 21:39:50 | pixelma | or a smaller font on the remote... |
| 21:41:40 | pixelma | JdGordon: haven't tried compiling but don't see any obvious. It could be that the period would be after a space for non-lcd-remote targets |
| 21:42:45 | JdGordon | there is no space after the word statusbar |
| 21:44:02 | | Join lifeless [0] (n=lifeless@188.16.87.166) |
| 21:44:07 | pixelma | I mean at the end of the description where " on the remote display" is opted |
| 21:45:03 | JdGordon | me too |
| 21:45:36 | JdGordon | should i commit that? |
| 21:45:55 | pixelma | but there is a line break and I think tex makes va space out of it (just one) |
| 21:46:07 | pixelma | s/va/a |
| 21:46:13 | JdGordon | oh |
| 21:46:28 | gevaerts | Is there a full diff of these manual changes somewhere? I can test-build if needed |
| 21:47:03 | | Quit lifeless (Remote closed the connection) |
| 21:47:16 | pixelma | http://pastebin.com/m1e0175c0 (except the small typo) |
| 21:47:19 | | Join lifeless [0] (n=lifeless@188.16.87.166) |
| 21:47:24 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 21:47:24 | | Quit lifeless (Read error: 54 (Connection reset by peer)) |
| 21:47:25 | JdGordon | http://pastebin.com/pastebin.php?dl=m5cca685 |
| 21:47:26 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 21:47:38 | JdGordon | that has the tpo fixed and hopefully no space |
| 21:48:28 | | Quit lyngaas ("Leaving.") |
| 21:49:00 | | Join lyngaas [0] (n=staale@19.81-167-149.customer.lyse.net) |
| 21:49:14 | pixelma | guess the space between }{ is too much |
| 21:49:33 | pixelma | that looks odd |
| 21:50:37 | gevaerts | the pdf seems to look fine |
| 21:51:16 | JdGordon | pixelma: which one? |
| 21:51:27 | * | JdGordon is happy to leave this to you if you want it :) |
| 21:51:40 | pixelma | on the line you just changed |
| 21:51:47 | JdGordon | oh remove the space? |
| 21:52:36 | pixelma | just between \opt{remote} and the next { |
| 21:53:09 | pixelma | not sure whether that's important though |
| 21:53:11 | JdGordon | ok, done |
| 21:53:16 | JdGordon | commiting.... |
| 21:53:40 | gevaerts | JdGordon: gevaerts/e200.pdf">http://www.evonet.be/~gevaerts/e200.pdf (no remote) and http://www.evonet.be/~gevaerts/h120.pdf |
| 21:54:14 | JdGordon | ta |
| 21:54:24 | CIA-71 | New commit by jdgordon (r21677): fix the manual for the statusbar changes |
| 21:57:07 | pixelma | gevaerts: could you also try for a non-lcd-remote target? |
| 21:57:30 | gevaerts | gigabeat f ok? |
| 21:57:41 | pixelma | should be |
| 21:57:47 | kugel | gevaerts: the ipod nano also doesn't have usb? |
| 21:57:58 | | Join stoffel [0] (n=quassel@p57B4FBD8.dip.t-dialin.net) |
| 21:59:29 | Mikachu | what does "have usb" mean here? |
| 22:00 |
| 22:01:02 | gevaerts | pixelma: gevaerts/gigabeat.pdf">http://www.evonet.be/~gevaerts/gigabeat.pdf |
| 22:01:08 | gevaerts | looks OK to me |
| 22:01:24 | gevaerts | kugel: rockbox usb is disabled on all ipods |
| 22:01:38 | CIA-71 | New commit by bertrik (r21678): s5l8700: fix off-by-one error in DMA count |
| 22:01:44 | kugel | ah ok |
| 22:01:59 | Mikachu | only in the releases |
| 22:02:11 | gevaerts | but that doesn't matter anyway, since ipods handle usb-on-boot differently |
| 22:04:39 | pixelma | gevaerts: yes, although it made me notice that it's sometimes "statusbar" and then "status bar" :\ |
| 22:06:42 | | Quit Silicium ("leaving") |
| 22:08:01 | | Quit _lifeless (Read error: 113 (No route to host)) |
| 22:08:55 | | Join toffe82 [0] (n=chatzill@ppp-71-138-19-215.dsl.frs2ca.pacbell.net) |
| 22:09:07 | | Quit toffe82 (Client Quit) |
| 22:10:41 | CIA-71 | New commit by bertrik (r21679): S35390a RTC: fix duplicate i2c initialisation |
| 22:16:27 | markun | bertrik: great work on the meizus! |
| 22:16:35 | markun | I'll get your M6SL tomorrow :) |
| 22:20:10 | | Join AfterDeath [0] (n=icxcnika@freenode/weird-exception/network-troll/afterdeath) |
| 22:23:33 | | Quit stoffel (Remote closed the connection) |
| 22:31:26 | | Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) |
| 22:37:10 | | Join petur [0] (n=peter@rockbox/developer/petur) |
| 22:41:47 | | Quit KBH (Read error: 110 (Connection timed out)) |
| 22:45:41 | | Quit Lear ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") |
| 22:50:55 | pixelma | has anyone with an X5 ever had a problem that the tuner wouldn't work and which was fixed by a restart? It sounded like it actually was fixed at the lowest frequency no matter whether I went through the presets etc.) |
| 22:52:51 | *** | Saving seen data "./dancer.seen" |
| 22:55:40 | | Quit aaron424 (Remote closed the connection) |
| 22:59:13 | kugel | JdGordon: can you explain your objections against plugin-goto-wps now? |
| 23:00 |
| 23:04:09 | bluebrother | urgh. The ability to put the statusbar on the bottom eats up 1k? |
| 23:04:37 | | Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
| 23:04:50 | kugel | no |
| 23:05:16 | | Quit Rondom (Nick collision from services.) |
| 23:05:32 | | Join Rondom [0] (n=Rondom@dslb-084-057-130-041.pools.arcor-ip.net) |
| 23:05:38 | linuxstb | bluebrother: It looks like the build was combined with the fixed-point lib... |
| 23:05:52 | * | linuxstb wonders how that can happen |
| 23:06:10 | Unhelpful | is the "new" build system doing the builds yet? |
| 23:06:16 | Bagder | no |
| 23:06:17 | | Join webguest89 [0] (n=566b3421@gateway/web/cgi-irc/labb.contactor.se/x-4fb9d4f30faa2b56) |
| 23:07:04 | Unhelpful | then they can still be combined if commits are close enough together. |
| 23:07:46 | Mikachu | there was a commit at 17:59, both the other commits were done before that round finished |
| 23:07:55 | Mikachu | at 18:06 and 18:07 |
| 23:08:09 | webguest89 | uh, sorry to bother (and new to this IRC) but I've got a problem with the latest release. My iPod nano light doesn't turn on anymore after it turns off. And my blackglass theme is broken :( help. |
| 23:08:19 | * | bluebrother would expect combining the fixed point math routines in a lib would not create a red delta |
| 23:08:37 | Unhelpful | bluebrother: putting them in core would... |
| 23:08:37 | linuxstb | Bagder: Does the new system deal with rapid-fire commits better (perfectly?) ? |
| 23:08:39 | kugel | bluebrother: read the logs, it explains the delta |
| 23:08:52 | * | bluebrother puts some help in the channel |
| 23:09:02 | bluebrother | Unhelpful: oh, they weren't in the core before? |
| 23:09:03 | Bagder | linuxstb: so what is "perfect treatment" in that sense you mean? |
| 23:09:11 | linuxstb | Bagder: I mean one build per commit... |
| 23:09:18 | Bagder | I wouldn't like that |
| 23:09:19 | linuxstb | s/commit/revision/ (but same thing?) |
| 23:09:37 | Bagder | imagine 7 fast commits, it'll take ages until the guys get the results for the last |
| 23:09:56 | linuxstb | I would prefer that to not getting all the build info for each revision. |
| 23:10:12 | Mikachu | <insane idea>you could queue up the old commits, so when the latest finishes, you do the old commits and fill in the table when nothing more important is going on</insane idea> |
| 23:10:53 | linuxstb | Bagder: So I guess you didn't design that feature into the new system (as you don't want it!) ? |
| 23:10:53 | Bagder | Mikachu: yeah, that _could_ of course be done, but I wouldn't consider that very fun to work on get going |
| 23:10:59 | gevaerts | webguest89: you mean the backlight? |
| 23:11:11 | Bagder | linuxstb: correct, but it wouldn't be very hard to make it act like that |
| 23:12:03 | webguest89 | yep, the backlight. sorry for ambiguous posting. it doesn't work properly. |
| 23:12:18 | linuxstb | Bagder: It's not a big deal, it's just that I would have expected our build system to always do one build per revision... |
| 23:12:22 | | Quit petur ("Zzzzz") |
| 23:12:37 | * | linuxstb stops assuming |
| 23:12:41 | Bagder | :-) |
| 23:13:01 | Bagder | when we get build times down to less than a minute I'll join that camp ;-) |
| 23:13:24 | linuxstb | Easy, drop support for swcodec... |
| 23:13:24 | gevaerts | webguest89: the hold switch isn't on? |
| 23:13:40 | | Quit kugel (Nick collision from services.) |
| 23:13:48 | | Join kugel [0] (n=kugel@e178109164.adsl.alicedsl.de) |
| 23:14:21 | webguest89 | doesn't matter. ipod works fine. light doesnt until I reboot. Of course hold isn't on :) |
| 23:14:37 | gevaerts | hm, weird. |
| 23:14:40 | | Join wincent [0] (n=wincent@host-091-097-067-213.ewe-ip-backbone.de) |
| 23:14:47 | webguest89 | It's a bug, I bet it is. |
| 23:15:08 | Mikachu | Bagder: i got another crazy idea, most build clients use ccache right? you could send all builds to all clients after the round finishes, just to prime their caches :) |
| 23:15:15 | * | bluebrother is really fond of "read the logs" if the question can be answered with a single sentence :< |
| 23:15:20 | gevaerts | well, yes, but I haven't heard about it before. This isn't the sort of bug that people don't notice |
| 23:15:54 | Bagder | Mikachu: haha. but seriously, this concept favors the same build to the same client on repeated builds anyway, to be ccache friendly |
| 23:16:03 | Mikachu | okay :) |
| 23:16:27 | Bagder | and all the killed builds will actually help with feeding ccache |
| 23:16:36 | linuxstb | webguest89: Before you installed the latest release, when did you last install/update Rockbox? |
| 23:17:19 | Unhelpful | Mikachu: ccache can easily have poor performance anyway... since the key for matching files is the the preprocessed source, you just have to change a widely-used header file to get nearly everything rebuilt. |
| 23:17:22 | pixelma | webguest89: also, did you check the backlight settings? |
| 23:17:22 | webguest89 | uh... kinda half a year ago or more. But I checked. All new files are installed properly |
| 23:17:36 | webguest89 | of course I did |
| 23:17:52 | Mikachu | Unhelpful: yeah, that's why after such a change it helps to make subsequent builds faster if all clients did a build in between commits with the change |
| 23:18:06 | * | Mikachu sprinkles some grammar on that sentence |
| 23:18:52 | webguest89 | in fact, when I turn it off from the settings and turn it back on again absolutely nothing happens. only solution is to leave it on all the time |
| 23:19:17 | | Quit n00b81 ("Leaving") |
| 23:19:21 | webguest89 | but the battery won't last long |
| 23:20:21 | webguest89 | and I don't have a backup at hand (but I have home one). What do I do now? Leave it as it is? |
| 23:20:59 | gevaerts | webguest89: can you upload the contents of your .rockbox/config.cfg somewhere (e.g. http://pastie.org/) |
| 23:21:32 | | Quit Rondom (Read error: 104 (Connection reset by peer)) |
| 23:21:36 | Unhelpful | he could rename .rockbox/config.cfg and see if that fixes it... |
| 23:22:28 | kugel | bluebrother: I thought the logs explain it better, as it shows Blue_Dude explaining why he did what |
| 23:23:02 | webguest89 | grrrr dunno, I could upload them on rapidshare. Or I could drag and drop them in my apache web server (don't ask). But then I'll have to tell you my IP and make sure I don't sturn off the computer until you grab them |
| 23:23:18 | linuxstb | webguest89: Just upload it to http://pastebin.com |
| 23:23:31 | webguest89 | doesn't work. tried playing around with that |
| 23:23:32 | Unhelpful | or you can paste them into a web form and be done... |
| 23:23:33 | Unhelpful | it's text |
| 23:23:47 | linuxstb | webguest89: Then try a different pastebin - e.g. pastebin.ca |
| 23:24:20 | webguest89 | wait a sec. I never used that before |
| 23:25:47 | kugel | Unhelpful: "mkamsboot Version unknown-090705", after make clean && make in the master branc |
| 23:27:05 | kugel | Unhelpful: I didn't know I need to pass something to it |
| 23:27:22 | kugel | it worked for svn, so I thought it was a git issue maybe |
| 23:27:53 | pixelma | AlexP: at least the shifting around IRIVER_RC_H100_PAD made me find a bug in sliding_puzzle.tex... I also decided to make that two commits (shifting and then adding the Iaudio one) |
| 23:28:27 | pixelma | sorry, only called "sliding.tex" |
| 23:29:14 | | Quit kugel (Nick collision from services.) |
| 23:29:20 | | Join kugel [0] (n=kugel@e178120096.adsl.alicedsl.de) |
| 23:29:55 | webguest89 | http://pastebin.com/d47965e1a okay, here are some. Might have gotten mixed up while I was panicking about my iPod being broken, but none work |
| 23:29:56 | | Join stripwax [0] (n=dave@87-194-34-169.bethere.co.uk) |
| 23:30:44 | pixelma | AlexP: I wonder though if and how we could make the switch between columns more visible |
| 23:31:23 | gevaerts | webguest89: so if you set the backlight timeout to e.g. 10 seconds, it turns off after 10 seconds but pressing a button doesn't make it turn on again? |
| 23:32:01 | webguest89 | no. it doesn't turn on _anymore_ no matter what I try |
| 23:32:56 | gevaerts | Have you tried resetting the settings? |
| 23:33:03 | pixelma | what if you switch off the backlight fade in and out? |
| 23:33:11 | webguest89 | but it stays on while it's plugged in my usb and appears as a disk drive. Yes, I've tried. |
| 23:33:50 | webguest89 | none work. tried all settings. just doesn't turn on until I reboot |
| 23:34:51 | | Quit bmbl ("Bye!") |
| 23:37:12 | gevaerts | webguest89: the "backlight fade in" and "backlight fade out" settings look weird. They should be "on" or "off", not a number |
| 23:37:50 | webguest89 | I think it might be the firmware. And what I was trying to say above was, that perviously, when I plugged it in, the usb sign would show for a sec and then it would reboot in "file mode" (like all ipods do) And not with that stupid light on. |
| 23:38:31 | | Join safetydan [0] (n=deverton@rockbox/developer/safetydan) |
| 23:38:55 | webguest89 | fade in and fade out can have numerical settings since it's a matter of "in how many seconds will it fade out" I guess. I could be wrong, tho |
| 23:39:16 | gevaerts | Which exact version are you running? |
| 23:39:49 | webguest89 | latest. downloaded it just an hour ago from the site |
| 23:39:54 | kugel | gevaerts: they're numbers for ipods |
| 23:40:09 | kugel | for all pwm fading targets, acutally |
| 23:40:11 | gevaerts | kugel: ah. I didn't know that... |
| 23:40:20 | kugel | gevaerts: rtfm :D |
| 23:40:58 | linuxstb | webguest89: Latest official release (i.e. v3.3), latest "current build" or latest "daily build" ? |
| 23:41:17 | Llorean | webguest89: "latest" isn't an exact version anyway. It changes every time a developer commits something, so can change sometimes a few dozen times in an hour during active periods. |
| 23:41:51 | webguest89 | ummm... don't ask me, I dunno. I downloaded it manually from that page with many shiny players on it |
| 23:41:58 | | Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
| 23:42:09 | gevaerts | have a look at System->Rockbox Info |
| 23:42:47 | Llorean | webguest89: Unfortunately, none of us can come over and look at your iPod. That means you're going to get asked a lot of questions that need specific and clear answers, because nobody else is having this problem, so we need to know a lot of details about your specific case and what might make it different. |
| 23:43:09 | webguest89 | yup. r21672-090705 |
| 23:43:58 | webguest89 | I know, I know. Just wasn't sure where what "version" he meant |
| 23:44:56 | | Quit bluebrother ("leaving") |
| 23:44:57 | JdGordon | kugel: i dont have objectsions... it just doesnt sit right with me |
| 23:46:30 | kugel | ok, then I'll go for it |
| 23:48:59 | Dhraakellian | hmm... rockboxdev.sh is failing on me because "/usr/include/linux/errno.h:4:23: error: asm/errno.h: No such file or directory" |
| 23:49:18 | Bagder | wow |
| 23:49:18 | * | Unhelpful thinks that "make go-to-wps work in parts of rockbox implemented as plugins" is one good reason |
| 23:49:47 | * | Dhraakellian notices a bugzilla link in his google results that he hadn't previously seen |
| 23:50:01 | webguest89 | oh, and btw, the fade out option doesn't work at all. forgot to mention. it just turns off suddenly. It went just fine before I did the update |
| 23:52:23 | linuxstb | webguest89: I don't know if you've answered this question already, but have you tried resetting your settings? (there's a menu option in Rockbox to do that). |
| 23:54:26 | webguest89 | In what rockbox? The utility? Though I did manually put a clean version and still the same stuff. |
| 23:54:38 | Bagder | http://daniel.haxx.se/blog/2009/07/05/concepts-of-a-new-distributed-build/ |
| 23:54:52 | linuxstb | webguest89: Yes, in Rockbox itself. |
icon identifies that the person is a core developer (has commit access).