| 00:00:06 | | Quit PaulJam (".") |
| 00:00:07 | saratoga | ah I see its in the main manual |
| 00:00:10 | Llorean | markun: The manual should link that. |
| 00:00:12 | saratoga | sorry main patch |
| 00:00:33 | saratoga | stop confusing me with your questions |
| 00:00:41 | | Quit webguest23 ("CGI:IRC (Ping timeout)") |
| 00:01:19 | kugel | saratoga: the patch moved the algorithm from apps/plugins/lib to apps/recorder (and also into the core) |
| 00:01:32 | | Quit midgey () |
| 00:02:09 | kugel | the resize_in_core patch, that is |
| 00:02:23 | saratoga | it might be helpful if someone familar with buffering and display could state where the correct place to hook resizing onto is |
| 00:02:36 | | Quit lasser ("ChatZilla 0.9.83 [Firefox 2.0.0.16/2008070200]") |
| 00:02:56 | | Quit meven ("good night") |
| 00:03:04 | | Quit domonoky (Read error: 104 (Connection reset by peer)) |
| 00:03:05 | saratoga | i'm semifamilar with rockbox code and I don't even have an idea where it would go |
| 00:04:25 | kugel | metadata buffering |
| 00:04:54 | Dan89 | thank you llorean an markun |
| 00:05:06 | kugel | the output image should go into the metadata buffer |
| 00:05:49 | | Quit Munkie () |
| 00:06:36 | kugel | that's what the patch already does. Also, this is of course only for album art |
| 00:08:06 | | Quit funman ("'night") |
| 00:09:16 | | Quit denes (Remote closed the connection) |
| 00:09:45 | | Quit mcuelenaere ("Zzzz") |
| 00:10:18 | kugel | saratoga: did that answer your question? |
| 00:14:54 | | Quit Dan89 ("CGI:IRC (EOF)") |
| 00:17:30 | | Quit mf0102__ ("Ex-Chat") |
| 00:27:50 | | Join UncleRemus [0] (n=caj@78-69-154-184-no176.tbcn.telia.com) |
| 00:32:08 | | Join krazykit [0] (n=kkit@host-69-145-35-234.static.bresnan.net) |
| 00:32:29 | | Join Dan89 [0] (n=598b3ce8@gateway/web/cgi-irc/labb.contactor.se/x-bd566fb295d40711) |
| 00:32:45 | Dan89 | hi there i have another question. |
| 00:33:10 | | Join dan_a [0] (n=user@217.23.173.156) |
| 00:33:11 | Dan89 | i can see the music files when i connect my player |
| 00:33:36 | Dan89 | *i cant |
| 00:34:32 | Llorean | Rockbox doesn't move them. They're wherever you put them originally. |
| 00:34:36 | markun | Dan89: I believe the sansa music dir is hidden |
| 00:35:00 | markun | Llorean: or not? |
| 00:35:20 | | Join AaronShort [0] (n=c6ec2b02@gateway/web/cgi-irc/labb.contactor.se/x-bc97f55a824f0a92) |
| 00:35:41 | Llorean | markun: The folder may be hidden, yes. But you don't have to put them in there, and if you did you kinda knew about that factor, right? |
| 00:35:43 | Dan89 | ii dont know where they are because the installation |
| 00:35:56 | Dan89 | this is not hiden |
| 00:36:00 | Dan89 | i check it |
| 00:36:53 | Dan89 | the music folder disaper |
| 00:36:53 | | Quit merbzt (Read error: 104 (Connection reset by peer)) |
| 00:37:12 | Llorean | Dan89: It becomes hidden. |
| 00:37:39 | | Join kushal_10022008 [0] (i=4596a301@gateway/web/ajax/mibbit.com/x-54acc1d92730644a) |
| 00:37:55 | Dan89 | so how can i fix it? |
| 00:38:05 | AaronShort | I'm a developer and new to rockbox. so far I'm loving it. I've been playing with the simulator and noticed that the key mapings for the ipod are klunky. If I create a patch with more intuitive keymapings would that be something that the current devs would use? I wanted to check before I took the time to code. |
| 00:38:59 | markun | AaronShort: it depends. The devs are a bit conservative, but the best thing is to just do it and then discuss why it's an improvement in here. |
| 00:39:07 | Llorean | Dan89: Just set your computer to show hidden files. |
| 00:39:22 | markun | or set rockbox to show hidden folders |
| 00:39:27 | markun | hidden files |
| 00:39:35 | | Quit jhulst_ (Read error: 113 (No route to host)) |
| 00:39:37 | Llorean | markun: He's got file view set to all from earlier. |
| 00:39:39 | linuxstb | AaronShort: How are you proposing to deal with the scrollwheel? |
| 00:39:43 | pixelma | someone left a bit of yellow in the build table, doesn't look important though |
| 00:41:51 | AaronShort | right now the keys are 8 and 2 to scroll. and . for menu and + to play. these are backwards of what the key layout on the ipod is. I want to move the scrolls to 7 and 9 (above the 4 and 6 for forward back) then move the menu and play to 8 and 2. I think overall this will feel a lot more natural and intuitive |
| 00:42:53 | linuxstb | AaronShort: The scrollwheel is "forward" and "back", which maps to "down" and "up" in some places, and "right" and "left" in other places... |
| 00:42:58 | pixelma | 8 and 2 were chosen I believe so that you can use the up and down arrow keys as an alternative (especially in lists and menus), handy when on a laptop |
| 00:43:03 | Dan89 | Llorean there is no such option for - show "hidden files" only to single folders |
| 00:45:06 | AaronShort | that makes sense but it doesn't flow right in use. i get the arrows for laptops but there are really 6 keys not 4 on the ipod with the scrolls. as an alternative we could use the old wasd setup like in games and then use q and e for the scrolls. I think that would be better for both |
| 00:46:06 | Llorean | Dan89: I can't tell you how to use your PC. I can only tell you the folder is hidden, but Rockbox does not do anything to it. |
| 00:47:23 | pixelma | AaronShort: it will never feel right I guess unless you have a scrollwheel on your keyboard :) |
| 00:47:31 | kushal_10022008 | Llorean, I have a great idea. When the rockbox folder is zipped, could you zip it without the . in the front and ask us to rename it and put a dot afterwards? |
| 00:47:52 | Dan89 | are you sure the problem is the PC? becuase i really can make the hole player as not hiiden, only single folder.. =/ |
| 00:48:04 | Llorean | kushal_10022008: That doesn't make any sense. |
| 00:48:10 | pixelma | kushal_10022008: that won't work (for the average user) on windows |
| 00:48:34 | Llorean | Dan89: the original firmware automatically hides the MUSIC folder. |
| 00:48:42 | | Quit shotofadds ("Leaving") |
| 00:49:03 | Llorean | Dan89: What do you mean about "make the whole player not hidden"? |
| 00:49:43 | linuxstb | Dan89: Exactly what are you doing to try and unhide it? |
| 00:49:45 | Dan89 | i mean that i can show folderes inside the player not the whole player |
| 00:49:48 | kushal_10022008 | Llorean .rockbox is a hidden folder on the mac. because it begins with a dot. It has nothing to do with the previous conversation. |
| 00:49:54 | Llorean | Dan89: Is the whole player missing? |
| 00:50:04 | Dan89 | right click on the mouse |
| 00:50:10 | Llorean | kushal_10022008: Yes, but if you follow either of the official install instructions, you never need to see the .rockbox folder. |
| 00:50:11 | Dan89 | no.. |
| 00:50:27 | Dan89 | only music im think |
| 00:50:39 | AaronShort | well of course there isn't a scroll wheel but I still think the layout could be improved to be more intuitive. the keys on the ipod are in a cross so maping them outside of that feels clunky. oh and yea it's 7 not 6 keys like i said earlier... |
| 00:50:54 | Dan89 | after the right click i can click on "hidden" |
| 00:51:14 | linuxstb | Dan89: What is the mouse pointing to when you right-click? |
| 00:51:18 | Dan89 | but i cant do it on the player, its like a diffrent partition |
| 00:52:18 | Dan89 | about the hardware of the player.. =/ |
| 00:52:27 | linuxstb | I thought the option was somewhere in the menus in Explorer (something like View -> Folder options), but I'll let a Windows user explain.... |
| 00:53:37 | linuxstb | Dan89: http://www.google.com/search?q=windows+explorer+show+hidden+files |
| 00:54:12 | Dan89 | thanks |
| 00:54:24 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
| 00:55:22 | n1s | gevaerts: a bit of yellow in the best bootloader |
| 00:55:30 | AaronShort | well i guess i'll try to setup a dev invironment and create the patch. it might be easier to argue my case with an actual patch.... |
| 00:55:36 | n1s | s/best/beast/ |
| 00:56:25 | linuxstb | AaronShort: You should also remember that Rockbox works on many different devices, and we like things to be consistent - so if you propose changes for ipods, you should investigate other targets. e.g. the Sansas have a similar scrollwheel. |
| 00:57:19 | n1s | Personally i like having the wheel on 2 and 8 because it is the same as up/down on other sims so testing for different targets is pretty similar |
| 00:57:20 | Dan89 | thank you i solve the problem |
| 00:57:35 | AaronShort | does it scroll in a circle or up down? |
| 00:58:05 | AaronShort | well see is why I asked |
| 00:58:14 | AaronShort | n1s: |
| 00:58:24 | AaronShort | hmm.... |
| 00:59:08 | pixelma | I think in the Sansa sim the scrollwheel was mapped to 9 and 3 in the beginning and then changed to 8 and 2 to be consistent, if I remember correctly I didn't like the first behaviour too much but that's already a while ago |
| 00:59:10 | n1s | AaronShort: in a list it wors exactly like up/down |
| 00:59:34 | pixelma | e200 sim to be precise |
| 00:59:52 | AaronShort | picelma: funny I was just going to suggest something like that |
| 01:00 |
| 01:01:11 | pixelma | my thinking is that this would only shift clunkyness from one place to another. It may feel better in one context/screen but worse in others (e.g. in lists as n1s said). |
| 01:02:15 | | Quit Dan89 ("CGI:IRC (EOF)") |
| 01:02:51 | | Quit ender` (" Anyone who goes to a psychiatrist ought to have his head examined.") |
| 01:03:02 | pixelma | only a theory though based on trying to imagine |
| 01:03:32 | AaronShort | well scroll back could be 7 and scroll forward could be 9 and 1 so that it would feel natural however the user used it but I guess the whole point of the sim is be able to test things across players and consistency is more important in that case |
| 01:04:31 | AaronShort | the bigest issue is that I didn't know what the mappings were because they were on the wiki for the ipod but I've fixed that so.... |
| 01:04:41 | AaronShort | were not on |
| 01:04:57 | *** | Saving seen data "./dancer.seen" |
| 01:05:01 | linuxstb | AaronShort: There's also the "−−background" option when you run the sim... |
| 01:05:18 | * | linuxstb wonders why that isn't the default |
| 01:06:35 | AaronShort | −−background? I havn't tried that yet as I'm just getting up to speed. |
| 01:07:04 | linuxstb | i.e. run "./rockboxui −−background" |
| 01:08:29 | AaronShort | oh yea look at that |
| 01:09:05 | pixelma | I guess 7 and 9 will feel unnatural still in places where the scroll wheel is used for up and down |
| 01:09:20 | AaronShort | yea that looks like that should be the default. i assume there is one of those for every player? |
| 01:09:37 | linuxstb | Yes, every sim has one of those images |
| 01:09:56 | linuxstb | They're in uisimulator/sdl/ in the source |
| 01:10:06 | AaronShort | most devs don't have many diff players and that would make sense... |
| 01:12:02 | AaronShort | well there you go how sexy are those! I already svn'd the source but havn't compiled it yet.... |
| 01:13:51 | | Join mackes [0] (n=root@cpe-76-180-145-138.buffalo.res.rr.com) |
| 01:14:38 | AaronShort | well i'm off to go play with themes good thing I checked about the key mappings before coding thanks. |
| 01:16:09 | | Quit AaronShort ("CGI:IRC (EOF)") |
| 01:17:19 | | Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
| 01:21:57 | | Part dan_a |
| 01:24:41 | | Quit n1s () |
| 01:26:11 | | Join LambdaCalculus37 [0] (n=LambdaCa@c-24-0-218-198.hsd1.nj.comcast.net) |
| 01:26:36 | | Quit Thundercloud (Remote closed the connection) |
| 01:28:13 | | Quit HBK (Read error: 104 (Connection reset by peer)) |
| 01:31:07 | | Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
| 01:37:35 | | Join cinic [0] (i=cinic@modemcable032.151-80-70.mc.videotron.ca) |
| 01:39:11 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
| 01:40:12 | | Quit cinic () |
| 01:41:22 | | Quit culture (Read error: 110 (Connection timed out)) |
| 01:48:22 | | Quit Nico_P (Remote closed the connection) |
| 01:53:25 | soap | FS #9428 needs love. |
| 01:53:42 | soap | (or at least attention from someone with commit rights.) |
| 01:55:28 | * | LambdaCalculus37 goes to have a peek at FS #9428 |
| 01:56:54 | LambdaCalculus37 | soap: So this is for HWCODEC targets only? |
| 01:57:09 | soap | the changes are for SWCODEC only. |
| 01:57:16 | LambdaCalculus37 | Ahh, I see it now. |
| 01:57:31 | soap | the bug is that battery_bench's messages assume HWCODEC. |
| 01:58:37 | pixelma | I'm sorry, somehow this relating to HWCODEC irritates me (also in the tracker entry) - it's just coincidence that there is no "Off" buttons used on other targets |
| 01:59:56 | soap | you're taking offense at what I consider a pretty safe assumption that battery bench was never updated from its original messaging? |
| 02:00 |
| 02:00:30 | soap | And regardless of if I am right or wrong in that assumption, it does nothing to change the state of the bug. |
| 02:01:27 | pixelma | no offense, just irritation because the battery_bench itself has nothing to do with HW/SWCODEC |
| 02:01:28 | | Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) |
| 02:01:58 | soap | but the _bug_ only affects targets which are SWCODEC, be that coincidence or not. |
| 02:02:20 | soap | what category should I have put it under? |
| 02:03:21 | | Part toffe82 |
| 02:03:53 | soap | I can't select Player Type "iPod" and Player Type "Sandisk" and Player Type "Gigabeat"... Selecting Player Type "all" would have been flat out wrong. |
| 02:04:04 | pixelma | category might have been fine, just thinking the title could have been nicer. No need for a lengthy discussion though as there are worse titles |
| 02:07:32 | | Quit kushal_10022008 ("http://www.mibbit.com ajax IRC Client") |
| 02:08:30 | LambdaCalculus37 | soap: I'm building with the patch applied. |
| 02:10:53 | | Quit nuonguy ("Leaving") |
| 02:11:07 | soap | Two messages are changed, one in back-end method, the other in content as well as method. |
| 02:11:36 | soap | The one changed in content is the one which pops up when you attempt to load another plugin while bb is already running. |
| 02:12:13 | soap | second patch should appear exactly the same, but I consider the method more elegant. |
| 02:13:18 | soap | Part of me thinks a v3 of the patch with the same thing done to BATTERY_ON_TXT would be prettier still, but there is no functional need for doing so. |
| 02:14:25 | amiconn | linuxstb: The ape filters seem to be memory bound on the beast :\ |
| 02:14:58 | amiconn | I have something that is measurably faster than svn, but not nearly as much as I thought it would be... |
| 02:16:37 | | Quit jeffdameth (Remote closed the connection) |
| 02:17:35 | | Join Owner_ [0] (n=chatzill@c220-239-136-13.frank2.vic.optusnet.com.au) |
| 02:17:45 | | Nick Owner_ is now known as Jai (n=chatzill@c220-239-136-13.frank2.vic.optusnet.com.au) |
| 02:18:17 | | Nick Jai is now known as Jaid (n=chatzill@c220-239-136-13.frank2.vic.optusnet.com.au) |
| 02:19:21 | | Quit Jaid (Client Quit) |
| 02:20:03 | | Quit massiveH ("Leaving") |
| 02:20:04 | | Quit coatman (Remote closed the connection) |
| 02:20:18 | | Join powr-toc [0] (n=user@84-51-129-124.rickmo645.adsl.metronet.co.uk) |
| 02:20:32 | | Nick JdGordon|zzz is now known as JdGordon (n=jonno@rockbox/developer/JdGordon) |
| 02:20:55 | powr-toc | I'm looking to buy a new mp3 player to run rockbox on... Preferably one with tonnes of storage... any suggestions?? |
| 02:21:08 | | Quit kugel ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") |
| 02:21:38 | krazykit | powr-toc, read the BuyersGuide wiki page |
| 02:22:03 | powr-toc | krazykit: cheers :-) |
| 02:22:33 | | Join coatman [0] (n=coatman@r01jvgmb7.device.mst.edu) |
| 02:23:04 | | Quit mmadia ("Vision[0.9.7-SF-010705]: i've been blurred!") |
| 02:23:18 | LambdaCalculus37 | soap: Light is green... patch builds clean. :) |
| 02:31:22 | | Quit powr-toc (Read error: 104 (Connection reset by peer)) |
| 02:37:32 | | Join mmadia [0] (n=mmadia@pool-138-89-96-141.mad.east.verizon.net) |
| 02:47:00 | | Join mc2739 [0] (n=mc2739@cpe-67-10-238-175.satx.res.rr.com) |
| 02:48:41 | | Join |AhIoRoS| [0] (n=ahioros@200.75.224.98) |
| 02:48:51 | | Quit ZincAlloy ("CGI:IRC (EOF)") |
| 02:53:53 | LambdaCalculus37 | soap: I'm committing your patch. |
| 02:54:19 | LambdaCalculus37 | Anyone have any objections? |
| 02:58:34 | * | LambdaCalculus37 looks around |
| 03:00 |
| 03:00:22 | | Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) |
| 03:02:29 | pixelma | now you ask at 3AM (+/- 1) in most parts of Europe |
| 03:02:37 | mmadia | any suggestions on a replacement for chicago12.fnt ? |
| 03:02:56 | pixelma | 13-Nimbus |
| 03:04:43 | pixelma | Chicago was dropped due to licensing issues and Nimbus was very very similar and already had more characters anyways, chicago12 was actually 13 pixels tall IIRC |
| 03:05:00 | *** | Saving seen data "./dancer.seen" |
| 03:05:01 | mmadia | i trust you :) |
| 03:05:24 | pixelma | speaking of the Chicago font by the way, not the city ;) |
| 03:05:36 | wpyh | pixelma: do you know where we got the helvetica font from? |
| 03:06:11 | wpyh | I couldn't find its free license anywhere on the web. |
| 03:06:31 | pixelma | no, but it was mentioned here during the renaming process some weeks ago |
| 03:06:44 | pixelma | and markun knows |
| 03:06:59 | wpyh | ok |
| 03:14:01 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 03:19:14 | | Quit MethoS- (Read error: 104 (Connection reset by peer)) |
| 03:22:24 | JdGordon | LambdaCalculus37: you got red! |
| 03:22:28 | JdGordon | and I got yellow :'( |
| 03:22:32 | mmadia | pixelma what about helvB10 and B12 ? |
| 03:22:33 | JdGordon | (forgot to check before :p ) |
| 03:23:06 | JdGordon | and gevaerts is a naughty bugger also :p |
| 03:23:29 | mmadia | nm ... im guessing 10-Adobe-Helvetica-Bold.fnt |
| 03:25:05 | pixelma | if it's the same as the helvR ones in name not matching the size then helvB10 would be 12-* and helvB12 is 15-* |
| 03:26:10 | mmadia | helvR08 become 10-* ? |
| 03:26:13 | saratoga | does anyone know if the H10 can charge in rockbox? |
| 03:27:30 | pixelma | mmadia: in case those fonts are in SVN, they should appear in this README file (I think it was linked in the thread but it is in the font folder)... and I don't see them there... |
| 03:27:59 | mmadia | yeah, i'm looking at the fonts README |
| 03:29:08 | mmadia | i'm keeping track of the fonts that aren't in the README, later i'll post the info ( to see if anyone disagrees ) |
| 03:31:25 | LambdaCalculus37 | JdGordon: Crap, and on the Player, too! |
| 03:33:14 | * | LambdaCalculus37 decides to temporarily revert the patch and reopen FS #9428 |
| 03:33:15 | | Quit massiveH ("Leaving") |
| 03:35:55 | | Quit DerDome (Nick collision from services.) |
| 03:35:56 | | Join DerDome1 [0] (n=DerDome@82.83.210.251) |
| 03:36:06 | | Nick DerDome1 is now known as DerDome (n=DerDome@82.83.210.251) |
| 03:37:41 | | Quit bmbl ("Woah!") |
| 03:38:17 | | Quit scorche (Nick collision from services.) |
| 03:39:07 | | Join scorche [0] (i=Blah@rockbox/administrator/scorche) |
| 03:42:32 | | Quit mackes ("Ex-Chat") |
| 03:45:20 | pixelma | mmadia: if you want to rename fonts currently not in SVN to something that follows the naming scheme - the number in front tells something about the font size (actually line height). I don't know how right or wrong helvR08 is you would need to find out yourself, one indicator is how much lines fit on the screen - or count in a screenshot |
| 03:47:35 | | Part pixelma |
| 03:48:09 | | Join pixelma2 [0] (n=marianne@rockbox/staff/pixelma) |
| 03:49:43 | | Quit krazykit ("Connection reset by beer") |
| 03:53:56 | | Join Mitchell [0] (n=chatzill@stjhnf0112w-142162171052.pppoe-dynamic.nl.aliant.net) |
| 03:54:13 | Mitchell | Hey everyone |
| 03:55:14 | | Join Darksair [0] (n=user@221.221.164.210) |
| 03:55:24 | Mitchell | Think anyone can help me? I am playing doom on my ipod with rockbox and I have a broken hold switch so I can't exit or do a hard reset |
| 03:56:41 | saratoga | Mitchell: you can change the source code and recompile it, otherwise no |
| 03:56:58 | saratoga | the keybindings are fixed for all plugins as far as I know |
| 03:57:02 | Mitchell | I mean I can't close the game at all nor can i turn the game or ipod off |
| 03:57:07 | Mitchell | even when I plug it in |
| 03:57:20 | saratoga | theres a hardware reset combo on the ipod, try that |
| 03:57:26 | Mitchell | I did |
| 03:57:30 | Mitchell | doom overides it |
| 03:57:38 | saratoga | no it does not |
| 03:57:44 | saratoga | it cannot be overridden |
| 03:58:01 | Mitchell | select+ play will not work for me as it usually does though |
| 03:58:11 | Mitchell | the game runs well though |
| 03:59:36 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 04:00 |
| 04:00:18 | Mitchell | I'm so confused, I thought it couldn't be over rideden either |
| 04:00:25 | Mitchell | ridden* |
| 04:00:33 | | Join JesseL627 [0] (n=Lemon@ip98-181-45-13.br.br.cox.net) |
| 04:00:38 | | Quit LambdaCalculus37 ("Ka-chunka") |
| 04:03:07 | Mitchell | I'll just open it up and pop the battery out |
| 04:03:39 | | Part JesseL627 |
| 04:06:00 | Mitchell | yep guess that means no doom playing for me |
| 04:06:11 | Mitchell | thanks for the help I guess |
| 04:06:20 | | Quit Mitchell ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") |
| 04:07:19 | | Quit scorche (Nick collision from services.) |
| 04:07:27 | | Join Zarggg_ [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
| 04:07:45 | | Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) |
| 04:08:10 | | Join scorche [0] (i=Blah@rockbox/administrator/scorche) |
| 04:11:52 | | Join goffa_ [0] (n=goffa@216.220.23.105) |
| 04:12:14 | | Join miepchen^schlaf_ [0] (n=miepchen@87.158.205.228) |
| 04:12:29 | | Quit wpyh ("Leaving.") |
| 04:20:34 | | Quit miepchen^schlaf (Read error: 110 (Connection timed out)) |
| 04:22:57 | | Quit goffa (Read error: 110 (Connection timed out)) |
| 04:23:49 | | Join FOX9P3400 [0] (n=chatzill@75.110.23.144) |
| 04:23:57 | | Quit FOX9P3400 ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") |
| 04:24:00 | | Quit Zarggg (Read error: 110 (Connection timed out)) |
| 04:24:13 | | Join FOX9P3400 [0] (n=chatzill@75.110.23.144) |
| 04:25:12 | FOX9P3400 | CAn i get some help locating a c200eraser? |
| 04:27:58 | | Quit FOX9P3400 (Client Quit) |
| 04:32:39 | | Quit mc2739 () |
| 04:37:19 | | Nick JdGordon is now known as JdGordon|afk (n=jonno@rockbox/developer/JdGordon) |
| 04:37:24 | | Quit JdGordon|afk ("Konversation terminated!") |
| 04:39:15 | | Quit XavierGr () |
| 04:40:37 | | Quit |AhIoRoS| ("Abandonando, see you http://ahioros.vidao2.com") |
| 04:44:09 | soap | how the heck did that break s@#$? |
| 04:45:15 | | Join blkhawk- [0] (n=blkhawk@f051066054.adsl.alicedsl.de) |
| 05:00 |
| 05:01:04 | | Quit blkhawk (Read error: 110 (Connection timed out)) |
| 05:01:13 | | Nick blkhawk- is now known as blkhawk (n=blkhawk@f051066054.adsl.alicedsl.de) |
| 05:04:59 | | Quit saratoga ("CGI:IRC (Ping timeout)") |
| 05:05:01 | *** | Saving seen data "./dancer.seen" |
| 05:06:10 | | Join m0f0x [0] (n=m0f0x@189-47-65-118.dsl.telesp.net.br) |
| 05:24:41 | | Join Twisty [0] (n=mhesten@242.80-202-24.nextgentel.com) |
| 05:37:30 | | Quit massiveH ("Leaving") |
| 05:37:50 | | Quit Zarggg_ () |
| 05:38:36 | | Quit AndyI () |
| 05:40:11 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 05:40:56 | | Join perrikwp [0] (i=d1a8d351@gateway/web/ajax/mibbit.com/x-ed4a7b1a69ba409f) |
| 05:42:27 | | Quit Twst (Read error: 113 (No route to host)) |
| 05:44:25 | | Quit mmadia ("Vision[0.9.7-SF-010705]: i've been blurred!") |
| 05:48:43 | | Join ajonat [0] (n=ajonat@190.48.123.108) |
| 05:49:04 | | Join AndyI [0] (i=AndyI@212.14.205.32) |
| 06:00 |
| 06:06:25 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 06:07:21 | | Join massiveH [0] (n=massiveH@pool-70-105-170-62.nwrknj.fios.verizon.net) |
| 06:13:22 | | Join VisaNick [0] (n=456ca29a@gateway/web/cgi-irc/labb.contactor.se/x-918577679522851d) |
| 06:13:27 | VisaNick | Hello all |
| 06:13:31 | VisaNick | got a quick one for ya |
| 06:13:56 | VisaNick | how the heck do install rockbox |
| 06:14:02 | VisaNick | i am tryed alot of stuff |
| 06:14:07 | VisaNick | but nothing ;( |
| 06:14:15 | VisaNick | i have unlock iphones before |
| 06:14:25 | VisaNick | its a first gen nano |
| 06:14:28 | VisaNick | 4GB |
| 06:17:32 | advcomp2019 | VisaNick, you can use the the rockbox utility |
| 06:18:09 | ameyer | you sure it's a 1st gen nano? If it is, http://www.rockbox.org/twiki/bin/view/Main/RockboxUtility |
| 06:18:13 | advcomp2019 | plus read the guidelines of the channel, too |
| 06:18:24 | VisaNick | i have the tool |
| 06:18:28 | VisaNick | and running |
| 06:18:29 | VisaNick | it |
| 06:18:32 | VisaNick | but it says nothing |
| 06:18:37 | VisaNick | 0% |
| 06:18:48 | ameyer | please |
| 06:18:50 | advcomp2019 | plus do not hit enter |
| 06:18:50 | ameyer | don't |
| 06:18:57 | ameyer | use enter as punctuation |
| 06:19:28 | VisaNick | ok, sorry about that.. i am reading just want to make sure theres no quick ideas you have for me |
| 06:19:32 | advcomp2019 | are you sure it is a 1st gen? |
| 06:20:02 | VisaNick | no |
| 06:20:18 | advcomp2019 | what color is it? |
| 06:20:36 | VisaNick | pink firmware 1.1.3 4GB |
| 06:20:52 | ameyer | 1st gen was black and white only IIRC |
| 06:20:54 | advcomp2019 | then it is a 2nd gen |
| 06:21:06 | VisaNick | nice thanks alot ;) |
| 06:21:16 | ameyer | advcomp2019: couldn't it be a 3rd or 4th gen? |
| 06:21:33 | | Join reacocard [0] (n=reacocar@134.173.59.155) |
| 06:21:51 | ameyer | but probably a 2nd gen |
| 06:21:54 | VisaNick | its a nano |
| 06:22:15 | advcomp2019 | VisaNick, there is 4 gens of nanos |
| 06:22:36 | VisaNick | oh ok, well how can i find out for sure what i have? |
| 06:23:21 | ameyer | 2nd gen: http://upload.wikimedia.org/wikipedia/commons/b/b2/Nano_omores.jpg |
| 06:23:47 | VisaNick | yes that looks right |
| 06:24:09 | advcomp2019 | VisaNick, the 1st gen only came in white and black |
| 06:24:10 | ameyer | 3rd gen was shorter and fatter, 4th gen was taller and thinner |
| 06:24:56 | VisaNick | do i have to put it in like a dfu mode or something to get it to install the rockbox uttly i cant get it to do anything ;( or maybe should i downgrade my itunes back to 7.* ? |
| 06:25:15 | ameyer | for comparison, 3rd gen: http://upload.wikimedia.org/wikipedia/en/1/1f/Ipod_nano_g3_003.jpg 4th gen: http://en.wikipedia.org/wiki/Image:Ipod_Nano_4G_20080911.JPG |
| 06:25:46 | ameyer | VisaNick: there's nothing you can do, rockbox doesn't support any nano generation except the 1st gen |
| 06:26:06 | ameyer | well, you could sell it on ebay and buy a 1st gen nano |
| 06:26:46 | Unhelpful | later generations have various locks against hacking that have not yet been defeated, i believe. also differences in hardware to be dealt with after figuring out how to load and run custom code. |
| 06:27:29 | VisaNick | ...well shit! so theres nothing i can do with this huh? |
| 06:27:35 | ameyer | also, you could try to contribute to a potential 2nd gen nano port |
| 06:27:57 | Unhelpful | you can listen to itunes store songs, as well as mp3 or aac songs you encode yourself and load onto it with itunes. |
| 06:28:06 | VisaNick | lol :) |
| 06:28:21 | ameyer | Unhelpful: or apple lossless or wav/aiff |
| 06:28:23 | VisaNick | ipod linux ? |
| 06:28:50 | ameyer | does ipodlinux work with anything after the 3rd gen ipod? |
| 06:29:41 | | Quit Llorean (Read error: 104 (Connection reset by peer)) |
| 06:29:55 | ameyer | or, more directly, they have to deal with the same locks that rockbox has to deal with. |
| 06:30:11 | | Join Llorean [0] (n=DarkkOne@ppp-70-242-15-169.dsl.hstntx.swbell.net) |
| 06:32:31 | VisaNick | Well thanks alot for the input and help! its my wifes ipod just got her a iphone so shes not using it and we paid like 200 for this damn thing like a year ago was trying to mod it but i see theres nothing i can do with it thanks again ! |
| 06:32:48 | ameyer | actually, forget my question about whether ipl supports anything after the 3rd gen ipod. It seems to support the same ipods as rockbox |
| 06:34:05 | | Quit VisaNick ("CGI:IRC (EOF)") |
| 06:34:49 | Llorean | ameyer: There's a lot of code sharing between the projects. |
| 06:35:03 | ameyer | as there should be. |
| 06:48:18 | | Quit massiveH ("Leaving") |
| 06:52:10 | | Join cool_walking_ [0] (i=cb3b81c3@gateway/web/ajax/mibbit.com/x-f53093762de92af5) |
| 06:52:33 | cool_walking_ | GigabeatSInstallation says under Bootloader installation (dual-boot version): "[To be completed - there is currently no source for the required original firmware =nk.bin=]", but there is a (unofficial) source which is linked from GigabeatSInfo. Also, daniel.haxx.se hosts the mi4 firmwares. Isn't that the same thing? Should the GigabeatSInfo link be removed, or GigabeatSInstallation updated? |
| 06:53:20 | Llorean | cool_walking_: The MI4 firmwares are distributed by sandisk. |
| 06:53:30 | Llorean | Toshiba doesn't actually provide a firmware update we can extract the firmwares from. |
| 06:54:19 | Llorean | Daniel's willing to say "Sandisk gives these away for free, so I'm going to keep copies around here." Toshiba doesn't give them away for free, you only get a copy of the firmware if you buy the player and that's the one already installed to it. |
| 06:54:33 | cool_walking_ | Shouldn't the rapidshare link to the firmware be removed from GigabeatSInfo then? |
| 06:54:45 | Llorean | Yes. |
| 06:57:48 | cool_walking_ | okay done |
| 07:00 |
| 07:05:06 | *** | Saving seen data "./dancer.seen" |
| 07:09:49 | cool_walking_ | Is that "push the black square to reseat the memory" for e200 sufficiently proven to add to SansaE200Unbrick or SansaFAQ? |
| 07:10:52 | Unhelpful | they do provide a V firmware update, though? would extracting the nk.bin from that and modding it to produce a dual-boot bootloader, or to revert to stock firmware, be beyond the scope of rbutil? |
| 07:12:56 | Llorean | cool_walking_: No, not even remotely |
| 07:13:41 | Llorean | cool_walking_: If anything that's a physical damage issue, and if you need to push the memory back into place you should be doing it with everything in plain sight anyway, not by squeezing a panel. |
| 07:17:12 | cool_walking_ | Too early to start a GigabeatSFAQ to mention that an error [i forget the error number, i'll check tonight] is commonly caused by the HDD cable falling out? |
| 07:19:01 | Llorean | Unhelpful: Well, we do have RBUtil descramble and patch the .hex files for the H100/H300. I think that would be pretty similar. |
| 07:19:23 | Llorean | I can't state a firm policy or anything, but I bet a patch to do that would at least be discussed positively. |
| 07:19:54 | | Quit setkeh ("Leaving") |
| 07:20:43 | Unhelpful | cool_walking_: that's #5... i think. |
| 07:22:32 | | Quit coatman (Read error: 113 (No route to host)) |
| 07:25:26 | | Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) |
| 07:29:08 | | Join tvelocity [0] (n=tony@195.167.65.109) |
| 07:35:01 | | Join Bagderr [241] (n=daniel@rockbox/developer/bagder) |
| 07:35:26 | | Nick Bagderr is now known as B4gder (n=daniel@rockbox/developer/bagder) |
| 07:46:36 | | Quit tvelocity (Remote closed the connection) |
| 08:00 |
| 08:08:50 | | Quit Seed ("cu, Andre") |
| 08:15:20 | | Quit Acksaw (Read error: 104 (Connection reset by peer)) |
| 08:21:14 | | Join n1s [0] (n=nils@rockbox/developer/n1s) |
| 08:23:12 | | Join Acksaw [0] (n=omgwtfbb@cpc2-stok5-0-0-cust754.bagu.cable.ntl.com) |
| 08:29:41 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 08:33:16 | | Join ompaul [0] (n=ompaul@gnewsense/friend/ompaul) |
| 08:40:45 | | Quit BigBambi (Read error: 113 (No route to host)) |
| 08:41:43 | | Join Rob2223 [0] (n=Miranda@p4FDCC456.dip.t-dialin.net) |
| 08:51:17 | | Join pondlife [50] (n=Steve@rockbox/developer/pondlife) |
| 08:53:47 | n1s | wow, chessclock is really strange to navigate... |
| 08:54:19 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
| 08:54:20 | * | linuxstb doesn't understand JdGordon's fix |
| 08:55:13 | amiconn | gevaerts: yellow... |
| 08:56:16 | | Quit BHSPitMonkey (Remote closed the connection) |
| 08:58:10 | | Quit bertrik (Remote closed the connection) |
| 08:59:12 | linuxstb | amiconn: How much of an improvement did you get with APE? |
| 08:59:22 | amiconn | gevaerts: call_ata_idle_notifys() is an empty macro in bootloaders |
| 08:59:53 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
| 09:00 |
| 09:01:03 | amiconn | linuxstb: -c2000: 363% rt (+0.8%), -c3000: 240% rt (+4.8%), -c4000: 91% rt (+8.3%), -c5000: 21% (+10.5%) |
| 09:01:20 | | Quit gevaerts (Nick collision from services.) |
| 09:01:32 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 09:01:49 | linuxstb | amiconn: Hmm... |
| 09:03:56 | amiconn | I tried reordering the memory accesses in various ways in my version which had practically no effect |
| 09:04:30 | | Join petur [50] (n=petur@rockbox/developer/petur) |
| 09:05:03 | amiconn | The beast has 16KB IRAM - do we use that? |
| 09:05:11 | *** | Saving seen data "./dancer.seen" |
| 09:05:17 | n1s | don't think so |
| 09:07:01 | amiconn | Otoh it also has 16KB L1 data cache, which should be as fast as the IRAM |
| 09:09:20 | | Join massiveH [0] (n=massiveH@pool-70-105-170-62.nwrknj.fios.verizon.net) |
| 09:09:32 | n1s | from config.h:486-512 it seems like we don't at least |
| 09:10:54 | | Quit ompaul (Client Quit) |
| 09:14:11 | * | linuxstb wonders what he's missing about JdGordon's commit - it seems to be saying "if (x==-1) { x = -1 ; } Plus, last_screen looks like it should be "signed char". |
| 09:15:19 | | Join goffa [0] (n=goffa@216.220.23.105) |
| 09:18:12 | | Quit pondlife (Read error: 110 (Connection timed out)) |
| 09:21:43 | * | petur sees no svn activity on the front page |
| 09:22:04 | | Quit pixelma2 ("-") |
| 09:22:17 | | Join Bagderr [0] (n=daniel@gateway/web/cgi-irc/labb.contactor.se/x-5409b67afad73ca4) |
| 09:22:19 | | Join pixelma [50] (i=pixelma@rockbox/staff/pixelma) |
| 09:22:23 | * | linuxstb also wonders why LamdaCalculus37/Soap didn't just add the missing #define for the player, instead of reverting |
| 09:22:51 | | Quit B4gder (Read error: 104 (Connection reset by peer)) |
| 09:22:59 | | Nick Bagderr is now known as B4gder (n=daniel@gateway/web/cgi-irc/labb.contactor.se/x-5409b67afad73ca4) |
| 09:24:49 | * | amiconn wonders the same |
| 09:24:59 | n1s | any suggestions on how to figure out where something gets stuck in an infinite loop? |
| 09:25:53 | n1s | linuxstb: about that patch, we (I) have rejected such patches before because that kind of thing is supposed to be fixed in a nicer way by the plugin localization patch |
| 09:26:38 | * | linuxstb wonders about the state of the plugin localization patch |
| 09:26:48 | pixelma | linuxstb: to up his commit count? ;) |
| 09:26:52 | * | n1s too |
| 09:26:59 | * | pixelma too |
| 09:27:40 | | Quit goffa_ (Read error: 110 (Connection timed out)) |
| 09:29:01 | linuxstb | n1s: I think it's a bit harsh to reject those kinds of patches - it's not nice to have obviously wrong text displayed. But I guess you expected plugin localization to have been added by now... |
| 09:29:49 | n1s | indeed and tbh most of them were just adding some string for one target and left mos as they were |
| 09:32:31 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 09:34:56 | linuxstb | n1s: Does your infinite loop happen on the sim? |
| 09:35:06 | n1s | linuxstb: yep |
| 09:35:21 | linuxstb | Tried gdb? |
| 09:35:39 | | Quit jfc (Read error: 104 (Connection reset by peer)) |
| 09:35:52 | | Join jfc [0] (n=john@dpc691978010.direcpc.com) |
| 09:36:08 | n1s | well, I'm not very good at gdb... basically know 'r' and 'bt' :) any hints? |
| 09:36:31 | linuxstb | I'm not either, but I think if you just press CTRL+C when it is stuck in that loop, it will tell you where in the program it is |
| 09:37:25 | B4gder | you can even attach gdb to the running process |
| 09:37:33 | B4gder | gdb -p [pid] |
| 09:38:08 | | Quit Acksaw (Read error: 104 (Connection reset by peer)) |
| 09:38:28 | | Join Acksaw [0] (n=omgwtfbb@cpc2-stok5-0-0-cust754.bagu.cable.ntl.com) |
| 09:38:36 | * | GodEater prefers using ddd as a front end to gdb |
| 09:40:06 | | Join LinusN [0] (n=linus@rockbox/developer/LinusN) |
| 09:42:40 | | Join Zagor [0] (n=bjorn@rockbox/developer/Zagor) |
| 09:43:51 | amiconn | That calendar fix is odd.... looks like calendar just faked some struct tm values back when that data wasn't really avaliable, and later that hack was just forgotten |
| 09:44:02 | amiconn | (in the sim I mean) |
| 09:47:01 | n1s | amiconn: yep, i tested on the sim and it works as expected now (that sim hack was in the initial calendar commit, 3877 iirc) |
| 09:51:50 | | Quit massiveH ("Leaving") |
| 09:55:23 | amiconn | n1s: Such happens if a plugin is for only one target :\ |
| 09:56:13 | * | amiconn would really like to see rockcalendar and the old calendar combined, taking the best of each, and then committed and enabled for all rtc targets |
| 10:00 |
| 10:01:04 | * | n1s seems to have fixed the infinite loop but didn't really figure it out... |
| 10:03:01 | n1s | amiconn: in lcd16bit.c:518 is there a reason that test doesn't cast to unsigned like the hline one does and the various other ld drivers do too? |
| 10:03:09 | n1s | s/ld/lcd/ |
| 10:04:19 | n1s | if i change that to cast like the others the (almost) infinite loop in spacerocks goes away and i guess this could be the cause for other misbehaviour in spacerocks too |
| 10:04:50 | | Join vitja [0] (n=vitja@79.120.98.174) |
| 10:06:16 | | Quit vitja (Remote closed the connection) |
| 10:06:39 | | Join vitja [0] (n=vitja@79.120.98.174) |
| 10:07:17 | amiconn | n1s: The 'x' test should be cast to unsigned. Seems like someone wasn't fully awake when porting that driver to viewports... |
| 10:07:53 | amiconn | This cast is done to save a comparison |
| 10:08:11 | amiconn | ...because it will also signal out-of-limit when x is negative |
| 10:08:30 | n1s | yes, that's what i thought, Will commit the fix then |
| 10:09:01 | amiconn | The y1/y2 check must not use this cast, of course |
| 10:09:20 | vitja | gevaerts: why do you say that your patch need >500 bytes of ram? |
| 10:12:39 | n1s | haha, if i connect usb while in spacerocks the statusbar in the usb screen is green (usually white) :) |
| 10:13:18 | amiconn | There are a dozen glitches like this wrt status bar in plugins |
| 10:13:45 | amiconn | Some you'll only see if you use cabbie, others you'll only see when using the old rockbox default colours |
| 10:14:19 | amiconn | I think you'll see all of them if you select unusual foreground and background colours, e.g. dark blue text on yellow background |
| 10:14:43 | | Quit domonoky (Read error: 104 (Connection reset by peer)) |
| 10:17:25 | n1s | gevaerts: any tips on reproducing FS #9380, i can't seem to get it on my h300 with or without the fix |
| 10:19:58 | linuxstb | n1s: Thanks for fixing my lcd-16bit.c error... |
| 10:20:09 | * | linuxstb apologises and seeks forgiveness |
| 10:25:20 | amiconn | n1s: Hmm, this bug is also in 3.0 then... are there reports for the infinite loop issue in spacerocks in 3.0? |
| 10:26:21 | n1s | amiconn: there are two open bugs for spacerocks afaik, one about crashes on arm based targets and one about the asteroids getting strange shapes on coldfire |
| 10:27:27 | pixelma | maybe the crash has the same reason, just that coldfire gets along with it a tad bit "better"? |
| 10:27:35 | n1s | and the arm one seems quite probably to be caused by this as it happened after you optimized _lcd_drawline calls with vline/hline instead |
| 10:28:06 | n1s | hmm, someone posted a patch with the same fix in the earlier bugreport... |
| 10:38:49 | n1s | anyone with an x5 that can test FS #9220 or should i just close it? |
| 10:41:03 | gevaerts | n1s: just start it and let it run for a while |
| 10:41:07 | Llorean | n1s: it's considerably more than a week later. :) |
| 10:41:23 | gevaerts | vitja: comparing rockbox-info.txt with and without the patch shows that |
| 10:41:36 | gevaerts | amiconn: spacerocks was removed from 3.0 |
| 10:41:51 | n1s | gevaerts: i tried that but nothing happened, then played through 4 levels with no problem... |
| 10:42:08 | n1s | Llorean: ok, closed it is then |
| 10:42:17 | | Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) |
| 10:42:24 | * | gevaerts will try again tonight |
| 10:42:33 | vitja | gevaerts: binary size, do you think 500 bytes is too much? |
| 10:42:40 | | Quit cool_walking_ ("http://www.mibbit.com ajax IRC Client") |
| 10:43:20 | vitja | gevaerts: what do you think if request_endpoint will return endpoint with direction, e.g.: 0x81, 0x01? |
| 10:43:22 | gevaerts | vitja: I think it's a lot for basically the same functionality. If we can't get it smaller, we can live with it |
| 10:44:17 | gevaerts | vitja: endpoint numbers are used as indices in arrays, so I'd prefer to avoid this |
| 10:45:05 | vitja | gevaerts: we can add handlers for in and out in ep_data, call the right one |
| 10:46:08 | amiconn | How many endpoints can exist? |
| 10:46:11 | vitja | gevaerts: and take ep_data[ep&~0x80].handlers[ep>>7] |
| 10:46:49 | amiconn | If it's 0..15, why not use bit 4 instead of bit 7 for indicating in/out? |
| 10:47:47 | gevaerts | amiconn: bit 7 is used by the usb protocol, so using that makes things easier. |
| 10:47:56 | amiconn | ah |
| 10:48:39 | amiconn | But you could mangle the bit for array indexing |
| 10:48:59 | amiconn | Btw, did you spot the yellow? |
| 10:49:15 | gevaerts | I did, yes. I'll fix that during my lunch break |
| 10:51:47 | gevaerts | vitja: that would work. Feel free to change it |
| 10:52:07 | amiconn | aaargh! |
| 10:52:25 | vitja | gevaerts: will try tonight |
| 10:52:27 | amiconn | Damn -m |
| 10:54:21 | amiconn | phew, thanks my lcd-16bit.c is out of date. Didn't spot that immediately... |
| 10:58:10 | | Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) |
| 10:58:14 | | Quit reacocard (Read error: 110 (Connection timed out)) |
| 10:59:49 | amiconn | linuxstb: I've committed my armv6 ape optimisation now. Armv5te could have a similar (*slightly slower*) optimisation for the scalarproduct(), but not for vector_add() and vector_sub() |
| 11:00 |
| 11:00:14 | | Join J-23 [0] (n=aldwulf@a105.net128.okay.pl) |
| 11:00:28 | amiconn | That said, the optimised vector_*() functions for armv6 are not really faster than the C version, just smaller |
| 11:01:45 | amiconn | (armv5te has no 'smlad', so the aligned case in scalarproduct would use a 'smlabb' / 'smlatt' pair instead) |
| 11:02:00 | | Join reacocard [0] (n=reacocar@WL-431.CINE.HMC.Edu) |
| 11:05:12 | *** | Saving seen data "./dancer.seen" |
| 11:05:45 | | Quit petur ("reboot") |
| 11:07:27 | | Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) |
| 11:13:11 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 11:13:55 | | Join petur [50] (n=petur@rockbox/developer/petur) |
| 11:14:13 | | Quit ajonat () |
| 11:14:29 | * | amiconn is slightly confused now... |
| 11:17:24 | amiconn | Seems like the darn build system fooled me :\ |
| 11:17:55 | amiconn | The speedup is significantly higher than I thought |
| 11:17:57 | linuxstb | The "codec not relinking" bug/ |
| 11:17:58 | linuxstb | ? |
| 11:18:21 | amiconn | I have even used some 'rm' commands to get around that, but obviously not enough |
| 11:18:45 | linuxstb | So what's the real speedup? |
| 11:18:48 | Unhelpful | amiconn: which would explain you previously thinking that it was rather lower than you expected... if i remember you saying that? |
| 11:18:56 | amiconn | yes |
| 11:19:22 | amiconn | It seems I measured only part of my optimisations, with other parts using intermediate, experimental stuff |
| 11:20:11 | amiconn | linuxstb: YOu can get around that relinking bug by deleting the .codec and the .elf, but if only a .h file changes in the library, the library isn't rebuilt either... |
| 11:20:56 | linuxstb | Ah, so that will be a different bug, in the libdemac Makefile... |
| 11:21:10 | linuxstb | (maybe...) |
| 11:22:11 | Unhelpful | a "make-doesn't-have-all-the-deps" issue, sounds like? |
| 11:22:47 | * | amiconn now deletes the filter_*.o files as well |
| 11:23:14 | | Nick Horschti is now known as Horscht (n=Horscht@xbmc/user/horscht) |
| 11:24:13 | amiconn | linuxstb: -c3000 is 309% realtime now |
| 11:24:58 | amiconn | Now that I know that something went wrong, I'll try reordering stuff again |
| 11:25:31 | amiconn | And it seems -c4000 can be played realtime, without going >264MHz |
| 11:26:01 | | Join nuonguy [0] (n=john@c-71-198-1-139.hsd1.ca.comcast.net) |
| 11:26:14 | linuxstb | That seems better :) |
| 11:26:48 | * | amiconn will know in a minute or so |
| 11:27:08 | preglow | you got a gigabeat s, amiconn? :) |
| 11:27:26 | markun | preglow: I couldn't believe it myself :) |
| 11:27:38 | preglow | now that i did not see coming :P |
| 11:27:46 | preglow | it's got fun dsp instructions, tho |
| 11:27:57 | preglow | just stay away from that floating point! |
| 11:28:02 | linuxstb | Could the vector FPU help integer codecs like APE? |
| 11:28:10 | amiconn | linuxstb: Yeps, -c4000 is 145% realtime :) |
| 11:28:29 | preglow | linuxstb: not without compromising the lossless part of everything |
| 11:28:40 | linuxstb | amiconn: I'm curious about "insane" - will it be realtime with the full clock speed...? |
| 11:29:06 | amiconn | This is using what I committed to svn (just that there's a wrong comment) |
| 11:29:56 | amiconn | linuxstb: Test running... |
| 11:30:56 | | Join lasser [0] (n=chatzill@W8f5b.w.pppool.de) |
| 11:31:24 | * | linuxstb wonders how efficient Windows Media Lossless is - is it a co-incidence that the Zune seems to the be only hardware supporting it? |
| 11:33:46 | | Quit nuonguy ("This computer has gone to sleep") |
| 11:34:04 | preglow | how well does it compress? |
| 11:34:28 | preglow | it sounds kind of unlikely to me they invented something as expensive as monkey's audio |
| 11:34:34 | Unhelpful | linuxstb: only apple supports alac, no? i suspect it has more to do with vendors either choosing FLAC, or the codec *they* own... |
| 11:34:36 | preglow | which is quite frankly just overkill in its methods |
| 11:35:16 | Unhelpful | preglow: considering what TAK seems to achieve, with flac-like playback. i'd love to see format specs or source. :/ |
| 11:35:58 | | Join massiveH [0] (n=massiveH@pool-70-105-170-62.nwrknj.fios.verizon.net) |
| 11:36:55 | preglow | he's been delaying that for rather a long while, tho |
| 11:37:47 | linuxstb | Unhelpful: Microsoft license their codecs to third-parties, Apple don't. Almost every vendor includes at least one MS codec (WMA standard), but not lossless... |
| 11:38:16 | amiconn | Maybe endors think lossless isn't that important? |
| 11:38:26 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
| 11:38:28 | amiconn | *vendors |
| 11:38:57 | Unhelpful | linuxstb: for a good while, the codec library they gave to vendors didn't support wma lossless. or at least, that was UK Rio Engineer's stated reason on riov forum. |
| 11:39:09 | linuxstb | Yes, it doesn't make sense on small flash-based players anyway, and hard-disk based DAPs are almost non-existent... |
| 11:40:01 | GodEater | Unhelpful: any idea which rio engineer? (/me knew a lot of them) |
| 11:40:30 | Unhelpful | GodEater: that was his actual forum handle. a couple years ago i might have been able to give you his first name. sorry. :/ |
| 11:40:53 | GodEater | never mind ;) |
| 11:41:10 | at0m|c | hi, i've read something about a default file path where rockbox internals (wps, album art etc) look for files. i don't seem to find the page again today, could anyone hint me? for now, i've put all files in /music/%artist/%filename.%ext.. is the file location really relevant? |
| 11:41:47 | amiconn | linuxstb: -c5000 is 40% realtime now. I corrected the numbers at SoundCodecMonkeysAudio |
| 11:42:16 | Llorean | at0m|c: Rockbox doesn't care where your music is. |
| 11:43:14 | Unhelpful | if you use file browser, organize it however you like. if you use database, just make sure your tags are nice. |
| 11:45:14 | at0m|c | Llorean, cheers |
| 11:47:30 | at0m|c | Unhelpful, ye all is properly tagged for Amarok's db |
| 11:48:00 | at0m|c | so will edit the cover script to put all cover.bmp in the right place.. |
| 11:48:30 | amiconn | gah |
| 11:49:49 | * | amiconn should really check quick-fixes |
| 11:50:01 | amiconn | Now the armv6 version produces static... |
| 11:51:13 | | Quit miepchen^schlaf_ () |
| 11:51:54 | | Join einhirn [0] (i=Miranda@p5B030C4D.dip0.t-ipconnect.de) |
| 11:52:29 | amiconn | The scalarproduct() is ok, so the bug is in the vector_*() function(s) |
| 11:53:11 | | Join miepchen^schlaf [0] (n=miepchen@p579ECDE4.dip.t-dialin.net) |
| 11:56:34 | | Quit robin0800 (Remote closed the connection) |
| 12:00 |
| 12:06:14 | | Join mf0102 [0] (n=michi@85-127-180-92.dynamic.xdsl-line.inode.at) |
| 12:09:11 | | Join Nibbler [0] (n=Nibbler@e181104249.adsl.alicedsl.de) |
| 12:13:15 | | Part J-23 |
| 12:14:12 | | Join J-23 [0] (n=aldwulf@a105.net128.okay.pl) |
| 12:14:13 | Unhelpful | re: using vector fpu for lossless, i wonder how much one can rely on rounding errors not happening when one does operations on integers within the range of the number of mantissa bits provided... those should be safe, if the hardware works "right"... |
| 12:15:17 | | Join mmadia [0] (n=mmadia@pool-138-89-96-141.mad.east.verizon.net) |
| 12:16:55 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 12:21:05 | | Quit massiveH ("Leaving") |
| 12:26:24 | | Quit Acksaw (Read error: 104 (Connection reset by peer)) |
| 12:26:57 | | Join Acksaw [0] (n=omgwtfbb@cpc2-stok5-0-0-cust754.bagu.cable.ntl.com) |
| 12:27:57 | | Join einhirn [0] (i=Miranda@p5B030C4D.dip0.t-ipconnect.de) |
| 12:36:51 | | Join tvelocity [0] (n=tony@gw1.mycosmos.gr) |
| 12:41:32 | | Quit mmadia (Read error: 110 (Connection timed out)) |
| 12:47:55 | vitja | gevaerts: I've attached new patch to your ticket |
| 12:49:06 | | Join {phoenix} [0] (n=dirk@p54B4737C.dip.t-dialin.net) |
| 12:49:56 | gevaerts | vitja: thanks |
| 12:54:55 | | Join FOX9P3400 [0] (n=chatzill@75.110.23.144) |
| 12:55:08 | | Quit FOX9P3400 (Client Quit) |
| 12:56:09 | | Join BigBambi [0] (i=86ceaf40@rockbox/staff/BigBambi) |
| 12:59:41 | | Quit {phoenix} (Remote closed the connection) |
| 13:00 |
| 13:00:04 | | Join moos [0] (i=moos@81-66-128-18.rev.numericable.fr) |
| 13:05:13 | *** | Saving seen data "./dancer.seen" |
| 13:06:04 | | Join {phoenix} [0] (n=dirk@p54B4737C.dip.t-dialin.net) |
| 13:10:36 | BigBambi | markun: So do you have any feeling for how the buttons will work on the M6 |
| 13:10:46 | BigBambi | M6SL that is |
| 13:11:09 | markun | for the M6SL it's quite logical I think, if we use the strip as 3 different buttons |
| 13:11:39 | BigBambi | does it have obvious candidates for left and right? |
| 13:11:57 | markun | yes, to the left and right of the strip there are the REW and FF buttons |
| 13:13:04 | BigBambi | As that is the main problem with the M3 - I guess we could have 5 buttons on the strip - the existing 'hard buttons' at the top and bottom and then make the strip itself into three - that could be highly confusing though as you would have to touch the strip but not push it to differentiate between the 'soft' and 'hard button' |
| 13:13:15 | pixelma | so "only" the four directions and "select"? That's one less than the Ondio |
| 13:13:21 | BigBambi | Also, you would have to have delays to see which one the person was actually going to press |
| 13:13:38 | BigBambi | and other than the strip the M3 only has one other button (and hold) |
| 13:13:57 | markun | pixelma: the four directions + select + menu + play/pause |
| 13:14:09 | markun | and there is a hold switch, but I don' |
| 13:14:11 | BigBambi | pixelma: The meizu M3 has a strip that could be three, one additional button and hold - so up, down, select and another |
| 13:14:17 | | Quit Dementio_ (Read error: 54 (Connection reset by peer)) |
| 13:14:20 | markun | t think we want to abuse it like it's done on the ipod |
| 13:14:21 | | Join mc2739 [0] (n=mc2739@cpe-67-10-238-175.satx.res.rr.com) |
| 13:14:44 | | Join Dementio_ [0] (n=dementio@211.45.234.45) |
| 13:15:14 | BigBambi | http://www.erenumerique.fr/images/news/20070402/meizu_m3.jpg is an M3, and that is all there is |
| 13:15:18 | markun | BigBambi: do you think the left-right button on the M3 should be use as a 'back' button in the file browser? Probably |
| 13:15:39 | BigBambi | M3: I imagine so, and use select to go forwards |
| 13:16:02 | markun | not too bad even |
| 13:16:03 | BigBambi | Then we will have to have some button that cycles through skip, seek, volume, etc whilst in WPS |
| 13:16:39 | linuxstb | markun: That sounds like the same buttons as the ipods - scroll fwd, scroll back, left, right, select, menu and play/pause, . |
| 13:16:45 | BigBambi | So maybe up and down do volume, press select now up and down skip tracks, press select now up and down seeks etc |
| 13:17:12 | markun | linuxstb: that's for the M6SL, the M3 has 1 button for forward and back :( |
| 13:17:40 | markun | BigBambi: or maybe use the forward-backward button for that in the WPS |
| 13:17:47 | markun | makes more sense if you ask me |
| 13:18:10 | linuxstb | What's the current state of the meizu ports? Are you running code? Any drivers working? |
| 13:18:13 | BigBambi | linuxstb: The M3 has an up down scroll pad with a proper button incorperated into the top and bottom of the scroll pad, a soft button for select in the middle of the scrolpad (in the OF°, and one other button |
| 13:18:26 | BigBambi | markun: sure, that would work too |
| 13:18:26 | pixelma | BigBambi: I had a similar idea (the "switch" one) but then realised that you could easily forget or confuse which mode you're in. Maybe this would need an indicator... |
| 13:18:44 | markun | linuxstb: we're running code, reading the touchpad driver through SPI, toggeling the backlight |
| 13:18:52 | BigBambi | pixelma: Yes, I think it needs an indicator, but I also think it is the only way to do it |
| 13:19:03 | BigBambi | There just aren't enough buttons to do anything else |
| 13:19:05 | markun | we also initialised the LCD, but since it doesn't display anything we're doing something wrong |
| 13:19:22 | pixelma | BigBambi: possibly |
| 13:19:50 | BigBambi | pixelma: Any other ideas? |
| 13:19:51 | markun | BigBambi, pixelma: we'll get a lot of complaints about people not being able to fish zelda on the M3 :) |
| 13:20:03 | markun | fish -> finish |
| 13:20:22 | pixelma | BigBambi: no |
| 13:20:22 | linuxstb | markun: Be careful, the SansaV2 ports are catching you up ;) |
| 13:21:03 | BigBambi | In the OF, the 'skip' button if you short click it will skip a track forward, if you long click it changes to being skip back, then you short click again and it skips a track back. The scroll pad for instance might be volume, then you press the middle of the scroll pad and it changes the scroll pad to be seek and now the scroll pad up and down seeks in the track |
| 13:21:04 | pixelma | markun: rockboy isn't enabled on the Ondios too due to the lack of buttons... |
| 13:21:40 | BigBambi | and the two scroll pad 'hard buttons' are play/pause and a menu button |
| 13:22:54 | markun | linuxstb: one thing which sucks is that we need runtime detection of the DAC on some of the players :( |
| 13:23:17 | markun | not sure yet how we are going to do that, since we changed all the codecs to use the same function names |
| 13:23:36 | linuxstb | markun: Hmm, that seemed a good idea at the time... |
| 13:24:04 | linuxstb | I assume meizu does that in their firmware? |
| 13:24:17 | markun | I believe so |
| 13:24:28 | B4gder | we can change the current names to become function pointers |
| 13:24:55 | markun | yes, and then prefix the existing functions |
| 13:25:03 | B4gder | exactly |
| 13:25:16 | linuxstb | Does this affect all the meizu players? |
| 13:25:20 | markun | should have little impact on size and speed, right? |
| 13:25:40 | | Join robin0800 [0] (n=ubuntu@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) |
| 13:25:53 | markun | linuxstb: at least the M3, not sure about the M6SL |
| 13:26:24 | markun | we also need to take different LCD drivers into account, but that's not realy a problem |
| 13:26:36 | * | linuxstb doesn't like having two M3s, so thinks we could just drop the meizu M3 ;) |
| 13:26:54 | markun | or refer to it as meizu3 |
| 13:27:03 | | Join jeffdameth [0] (n=jeff@dyndsl-085-016-239-112.ewe-ip-backbone.de) |
| 13:27:15 | | Join LambdaCalculus37 [0] (n=LambdaCa@nmd.sbx09467.newyony.wayport.net) |
| 13:27:31 | pixelma | meizum3 ;) |
| 13:27:43 | B4gder | m3 and M3 ;-) |
| 13:27:44 | markun | mei3? |
| 13:27:47 | markun | ;) |
| 13:27:52 | * | linuxstb slaps B4gder |
| 13:28:01 | | Quit {phoenix} (Remote closed the connection) |
| 13:28:30 | pixelma | Me3 and IM3 |
| 13:28:39 | markun | m3a m3b |
| 13:29:08 | linuxstb | Although it's good that Rockbox supports so many players, just the model name isn't enough to uniquely identify one... |
| 13:29:08 | markun | *sigh* |
| 13:29:14 | | Join robin0800_ [0] (n=ubuntu@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) |
| 13:29:19 | | Join DrMoos [0] (i=moos@81-66-128-18.rev.numericable.fr) |
| 13:29:22 | | Quit moos (Read error: 104 (Connection reset by peer)) |
| 13:29:27 | | Nick DrMoos is now known as moos (i=moos@81-66-128-18.rev.numericable.fr) |
| 13:29:39 | markun | moos: welcome back :) |
| 13:29:57 | moos | thanks and hi :) |
| 13:30:08 | | Quit robin0800_ (Remote closed the connection) |
| 13:30:08 | | Quit robin0800 (Remote closed the connection) |
| 13:30:16 | markun | would be nice if LCD drivers had some kind of test-mode |
| 13:30:26 | | Join {phoenix} [0] (n=dirk@p54B4737C.dip.t-dialin.net) |
| 13:30:39 | | Join robin0800 [0] (n=ubuntu@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) |
| 13:31:10 | linuxstb | markun: You mean LCD controllers? |
| 13:31:50 | markun | yes |
| 13:31:58 | markun | since we don't know where we made a mistake |
| 13:32:15 | markun | if it could display some test image to verify that the init was correct.. |
| 13:34:37 | markun | gevaerts: wasn't there 1 LCD controller register we were writing to which wasn't documented? I can't find it, but remember you telling me that |
| 13:35:31 | LambdaCalculus37 | linuxstb: I read the logs; in reference to your question about why I didn't add the missing #define... I know, I should've aded it. I'm going to do that. |
| 13:35:40 | * | LambdaCalculus37 realized that in hindsight, the missing #define should've been added *first* |
| 13:41:58 | | Quit mc2739 () |
| 13:42:39 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
| 13:43:38 | | Quit tvelocity ("Αποχώρησε") |
| 13:44:41 | linuxstb | LambdaCalculus37: Don't worry about the red - everyone causes those kinds of problems occasionally. Maybe commit things in future at times when more devs are around in case of problems though... |
| 13:45:02 | LambdaCalculus37 | linuxstb: Understood. |
| 13:45:13 | * | amiconn pushed ape performance on armv6 a little further |
| 13:45:37 | LambdaCalculus37 | linuxstb: The patch appears to have all of the proper #define's in it. That's why I was initially confused as to what caused the red. |
| 13:47:05 | * | linuxstb notes that most devs seem to work on features they don't actually use... |
| 13:48:38 | * | LambdaCalculus37 decides to recommit FS #9428; the patch looks fine to him |
| 13:49:40 | LambdaCalculus37 | And it does work; I rolled builds for a few of my targets, and they all work properly. |
| 13:49:48 | linuxstb | gevaerts: Have you noticed the yellow your commit caused yesterday? |
| 13:52:26 | LambdaCalculus37 | Can a couple of Player owners try out the latest build with FS #9428 applied and let me know if battery_bench works? |
| 13:52:57 | | Quit LambdaCalculus37 ("Ka-chunka") |
| 13:55:25 | pixelma | linuxstb: gevaerts already answered that earlier and wanted to fix in his lunch break... |
| 13:55:40 | * | linuxstb looks at the patch and expects the same red... |
| 13:55:51 | linuxstb | pixelma: OK, I scanned the logs, but didn't see him respond... |
| 13:58:07 | * | linuxstb wonders why LambdaCalculus37 did a commit and run... |
| 13:59:18 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 13:59:31 | | Join funman [0] (n=fun@86.219.158.180) |
| 14:00 |
| 14:01:48 | markun | amiconn: will you try video after this? |
| 14:03:22 | | Join nplus [0] (n=nplus@141.25.Globcom.Net) |
| 14:05:26 | | Join fragilematter [0] (n=fragilem@92.81.235.177) |
| 14:06:00 | | Part LinusN |
| 14:06:53 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
| 14:06:59 | | Quit vitja (Read error: 104 (Connection reset by peer)) |
| 14:08:02 | funman | I wonder what's the best way to move mkamsboot in tools/ |
| 14:08:28 | funman | I see that another tool has pre-built assembly code as a uint32_t array |
| 14:08:29 | markun | gevaerts: did you run some code on the M6SP? |
| 14:08:59 | funman | since this code is unlikely to change, I could put it in a .h file, with the corresponding .S file as a comment |
| 14:09:18 | linuxstb | funman: I think that would be ugly... |
| 14:09:36 | | Join LambdaCalculus37 [0] (i=44a04303@gateway/web/ajax/mibbit.com/x-39c116ae622b0a1a) |
| 14:10:22 | LambdaCalculus37 | linuxstb: I had to get to work. |
| 14:10:45 | linuxstb | Did you accidentally commit the same patch as before? |
| 14:11:19 | gevaerts | markun: yes, but just backlight toggling |
| 14:11:37 | LambdaCalculus37 | linuxstb: Yes, just noticed. |
| 14:11:59 | LambdaCalculus37 | linuxstb: But now I know where to look to fix the problem. |
| 14:12:07 | markun | gevaerts: do you still have the code to read the LCD controller ID? |
| 14:12:08 | funman | now I also notice tools/fwpatcher , is that the prefered location for it ? |
| 14:12:26 | markun | maybe we have more luck with the LCD init this time |
| 14:12:56 | kugel | funman: well, sansapatcher and ipodpatcher are in rbutil/, so I guess there's no preferred location |
| 14:13:04 | linuxstb | funman: How are you planning on dealing with the "dual_boot.S" ? Won't that need to be target-specific (for the button checks) ? |
| 14:13:14 | gevaerts | markun: that code is still there, and it didn't work on teh sp |
| 14:13:25 | funman | linuxstb: we can use the TARGET define |
| 14:13:27 | pixelma | LambdaCalculus37: try avoid committing when you're in a hurry :) |
| 14:13:48 | linuxstb | funman: Yes, but I mean the code in tools/ doesn't get compiled in a target-specific way - they are generic. |
| 14:13:56 | funman | oh |
| 14:13:58 | | Quit GodEater ("http://www.mibbit.com ajax IRC Client") |
| 14:14:10 | funman | well I don't know yet then |
| 14:14:42 | LambdaCalculus37 | pixelma: I will. Sorry 'bout that. :) |
| 14:15:06 | funman | Also if I grep for mktccboot I can see that tcc77x/crt0.S depends on it; I see the Makefile rules to build this tool, I see that it's built when a target use "$tccbitmaptools", but I don't see where it is invoked |
| 14:15:27 | funman | do we expect the user to run it manually against its firmware file ? |
| 14:15:28 | LambdaCalculus37 | linuxstb: Line 219 of apps/plugins/battery_bench.c is what's breaking the Player builds. |
| 14:15:43 | linuxstb | LambdaCalculus37: Yes, because you haven't defined BATTERY_OFF_TXT for the Player. |
| 14:16:04 | pixelma | in PLAYER_PAD |
| 14:16:25 | markun | gevaerts: is there some value in the s6d0154 init so that the screen will be white if the init was successful? (some polarity reverse bit) |
| 14:16:27 | LambdaCalculus37 | I'm fixing that now, but I can't access svn from work due to no wireless here. |
| 14:16:43 | LambdaCalculus37 | Can I just post a patch on FS and someone add it to SVN for me? |
| 14:17:05 | LambdaCalculus37 | Or should I just wait till I'm at a wireless point? |
| 14:17:14 | linuxstb | funman: Yes. Or eventually, the functionality will be incorporated into rbutil, where the user will need to provide an OF file, and rbutil will create the patched file. |
| 14:17:31 | markun | gevaerts: found it, never mind |
| 14:18:58 | linuxstb | funman: I'm thinking that "dual_boot.S" belongs in bootloader/, so the user will need to provide the OF, dual_boot.bin and bootloader.bin to mkamsboot. rbutil will be able to download dual_boot.bin and bootloader.bin for the specific target from the download server. |
| 14:18:59 | | Join Siku [0] (n=Siku@e212-246-66-148.elisa-laajakaista.fi) |
| 14:19:29 | linuxstb | funman: The ucl unpack function is generic, so can be put in tools/ with mkamsboot.c, and embedded in the mkamsboot binary |
| 14:19:48 | funman | "embed", like in "link" ? |
| 14:20:03 | linuxstb | funman: Or alternatively, we incorporate everything into our bootloader.bin file... |
| 14:20:06 | | Join GodEater [0] (i=c2cbc962@gateway/web/ajax/mibbit.com/x-4735685be63edecc) |
| 14:20:12 | linuxstb | funman: Yes. |
| 14:20:12 | | Quit GodEater (Client Quit) |
| 14:20:21 | | Quit robin0800 (Remote closed the connection) |
| 14:20:21 | funman | I need to think about all this |
| 14:20:24 | | Join GodEater [0] (i=c2cbc962@gateway/web/ajax/mibbit.com/x-692014af1511ae1a) |
| 14:22:29 | | Join spiorf [0] (n=spiorf@host83-227-dynamic.25-79-r.retail.telecomitalia.it) |
| 14:23:28 | linuxstb | funman: Do you have a Rockbox bootloader.bin for a V2 target building now? |
| 14:23:35 | funman | yes |
| 14:23:52 | funman | it's done in a rather hasty way |
| 14:24:00 | funman | but at least the reset vector will call main() |
| 14:25:57 | LambdaCalculus37 | linuxstb, pixelma: I have a fix up at FS #9446. |
| 14:28:03 | pixelma | if I see correctly the BUTTON_ON_TXT isn't needed because it's only used inside an HAVE_LCD_BITMAP later |
| 14:28:37 | markun | I read "For details, see the Reversed Display Function section" but can't find it in the datasheet |
| 14:28:40 | linuxstb | pixelma: I noticed that, but it doesn't hurt to define it - and may save a future red... |
| 14:29:28 | linuxstb | Could be nice to fix the text so it is used though. |
| 14:29:51 | pixelma | I agree |
| 14:31:00 | pixelma | not that this counts much :) |
| 14:31:08 | LambdaCalculus37 | I managed to build without errors here. |
| 14:31:10 | linuxstb | LambdaCalculus37: Welcome to Rockbox - where a trivial patch can turn into a life's work... |
| 14:31:29 | LambdaCalculus37 | linuxstb: Hehe... :) |
| 14:32:04 | | Quit spiorf (Remote closed the connection) |
| 14:33:56 | | Join Nibbl [0] (n=Nibbler@e181068141.adsl.alicedsl.de) |
| 14:36:28 | LambdaCalculus37 | linuxstb: I'll probably just commit the fix myself if anything, but it won't be until around 12:30 GMT-5. |
| 14:36:49 | linuxstb | amiconn: Do you know anything about the armv5 "preload" (PLD) instructions? Could they be helpful? |
| 14:36:50 | | Join jingjing [0] (n=com@117.47.125.20) |
| 14:37:34 | | Quit {phoenix} (Remote closed the connection) |
| 14:40:11 | | Quit funman ("leaving") |
| 14:41:42 | markun | gevaerts: I tried this, but the screen is still black: http://130.89.160.166/temp/polarity.diff |
| 14:43:06 | amiconn | linuxstb: I doubt it would help here. It's a caching hint instruction, and the ape filters loop many times over the same arrays, so everything should be (nearly) always cached |
| 14:43:47 | amiconn | New performance figures are up. Seems we won't get -c5000 realtime. 44% @264MHz equals 600MHz for realtime... |
| 14:44:24 | * | amiconn already tried some things in the vector_*() functions without luck |
| 14:44:25 | linuxstb | We can adjust the block size (i.e. number of samples decoded in one call to the library) if we want to - could that help by ensuring things are within the cache? The current value is just chosen arbitrarily... |
| 14:44:43 | amiconn | How big is a block right now? |
| 14:45:02 | linuxstb | #define BLOCKS_PER_LOOP 4608 |
| 14:45:16 | linuxstb | Which means 4608 sample pairs. |
| 14:45:41 | amiconn | Hmm, if that's *pairs*, it's not good on the beast... |
| 14:45:43 | linuxstb | APE calls a sample pair (or sample, for mono tracks) a "block" |
| 14:46:07 | amiconn | Data cache is 16KB, and 4608*4 already exceeds that |
| 14:46:19 | linuxstb | It's in codecs/ape.c |
| 14:46:27 | amiconn | The filter array adds to the caching requirements |
| 14:46:39 | amiconn | (or array*s*) |
| 14:47:21 | | Join dabujo [0] (i=xx@p4FDB19DA.dip0.t-ipconnect.de) |
| 14:47:24 | linuxstb | Aren't most of the arrays 32-bit as well - so 4608*8 ? |
| 14:47:45 | amiconn | decoder.c: lines 35..43 |
| 14:48:25 | linuxstb | Ah yes, the history buffers... |
| 14:48:38 | amiconn | The 'insane' array alone exceeds the cache size :( |
| 14:48:58 | | Quit Nibbler (Read error: 110 (Connection timed out)) |
| 14:51:59 | amiconn | Is there a reason for this somewhat strange BLOCKS_PER_LOOP value? |
| 14:52:08 | amiconn | Why not 4096, or 5000 or such? |
| 14:53:06 | amiconn | Halving the BLOCKS_PER_LOOP does indeed speed up things |
| 14:53:37 | linuxstb | amiconn: I think there's a logic - it's the default block size in FLAC. |
| 14:53:49 | amiconn | For PP it would need to be even lower (only 8KB cache) |
| 14:58:56 | amiconn | Hmm, somehow it only helps the lower compression levels... |
| 14:59:36 | linuxstb | I guess the larger filter histories fill the cache? |
| 15:00 |
| 15:00:14 | amiconn | I would've expected -c4000 to see a speedup, but it doesn't |
| 15:00:59 | linuxstb | Also, aren't all the important things in iram on PP, so it wouldn't help there? |
| 15:01:51 | amiconn | true |
| 15:02:10 | amiconn | -c1000..-c3000 do see a speedup on the beast |
| 15:02:20 | linuxstb | Do you have numbers? |
| 15:02:39 | amiconn | -c1000: 539%, -c2000: 410%, -c3000: 318% |
| 15:02:45 | amiconn | Compare to the wiki |
| 15:03:28 | linuxstb | So tiny, but measurable. |
| 15:04:07 | linuxstb | And -c4000 is the same? |
| 15:04:49 | amiconn | yes |
| 15:05:16 | *** | Saving seen data "./dancer.seen" |
| 15:09:12 | amiconn | To answer your earlier question - the samples in libdemac are 16 bit. That's why those armv6 simd instructions can be used... |
| 15:10:22 | | Join funman [0] (n=fun@86.219.158.180) |
| 15:11:25 | amiconn | Going down to 1024 blocks per loop speeds things up further, and also makes -c4000 see a bit of speedup |
| 15:11:32 | funman | linuxstb: putting the dual-boot.S in bootloader/ is not possible right away, because it will be linked to the bootloader, while we want it to "link" to the compressed bootloader |
| 15:11:50 | linuxstb | amiconn: I thought the filter history was 16-bit, but the samples themselves are 32? |
| 15:11:53 | funman | We can put the code into the bootloader-specific crt0.S, but then we can not compress it |
| 15:11:55 | linuxstb | funman: That depends how you compile it... |
| 15:12:10 | soap | linuxstb, can you explain why my battery bench patch borked the player? It is something I don't fully understand. |
| 15:12:18 | funman | I added it in SOURCES since I saw no target specific files in Makefile |
| 15:12:22 | amiconn | -c1000: 553%, -c2000: 412%, -c3000: 320%, -c4000: 155% |
| 15:12:29 | linuxstb | soap: You didn't include the correct #define for the Player (in the PLAYER_PAD section) |
| 15:12:49 | amiconn | linuxstb: nope |
| 15:12:53 | funman | I think I'm gonna put it in crt0.S and hope the bootloader stays under 40kB |
| 15:12:57 | linuxstb | funman: If we decide to put dual_boot.S there, it will need to have some target-specific Makefile rules |
| 15:13:08 | * | amiconn wonders why linuxstb knows his own code that bad |
| 15:13:18 | linuxstb | amiconn: No, the samples are definitely 32 bit... |
| 15:13:35 | funman | or maybe put it in bootloader/bootloader ? :) |
| 15:14:47 | funman | I'm going to use non compressed rockbox bootloader, and report that problem - hopefully we don't have to deal with it in the future |
| 15:15:07 | soap | I thought, linuxstb, that everywhere there was an existing BATTERY_OFF_TXT I changed it. Why was an additional one needed? |
| 15:15:43 | soap | I don't mean to come across as an idiot, but I thought this was a simple substitution fix... |
| 15:15:46 | amiconn | linuxstb: Maybe I'm a little confused. The vector math functions only see 16 bit data though |
| 15:16:45 | blkhawk | i see there has been some progress on the sansa e200v2 port - anything i can test? |
| 15:17:08 | linuxstb | soap: The code " rb->lcd_puts_scroll(0, 1, "Press OFF to cancel the test");" was changed to use BATTERY_OFF_TXT |
| 15:17:14 | funman | blkhawk: nothing yet |
| 15:17:38 | blkhawk | ah - too bad |
| 15:17:51 | blkhawk | i will play with my atmels then :) |
| 15:18:23 | LambdaCalculus37 | soap: I thought so too, but adding the #defines for BATTERY_OFF_TXT to PLAYER_PAD fixed the issue. |
| 15:18:23 | funman | as far as i know nobody develops drivers for e200 hardware, maybe you can help there? |
| 15:18:25 | soap | linuxstb, ahh, and there was no existing BATTERY_OFF_TXT for player, I get it. |
| 15:18:26 | LambdaCalculus37 | soap: http://build.rockbox.org/showlog.cgi?date=20081003T123031Z&type=Player%20-%20Normal |
| 15:18:45 | blkhawk | getting playlists to work was all too much of a hassel with the sansa OF |
| 15:19:41 | LambdaCalculus37 | soap: Linus's Law did indeed come into play here. ;) |
| 15:20:55 | amiconn | linuxstb: Lowering the BLOCKS_PER_LOOP would allow putting the insane array into IRAM even on targets with only 48KB codec IRAM |
| 15:21:15 | soap | I didn't pay enough attention to the behavior for non lcd bitmap. |
| 15:21:22 | soap | important lesson |
| 15:21:23 | amiconn | (not that it'd really matter as it's far from realtime on those...) |
| 15:21:26 | linuxstb | amiconn: There doesn't seem any benefit to that though - I can't imagine insane files ever working... |
| 15:21:34 | linuxstb | (apart from maybe on the S) |
| 15:22:10 | linuxstb | I wonder if the IRAM could be put to better use elsewhere though... |
| 15:22:10 | amiconn | Yes, but the S profits from less BLOCKS_PER_LOOP (due to better cacheability) |
| 15:22:41 | amiconn | Hence I wonder whether we should just lower it for all targets (if it doesn't hurt them) |
| 15:26:02 | soap | Something else _I_ would like for battery_bench is the inclusion of target name and svn revision in the output filename. This would (likely) break battery_bench resuming, though. 1 - under what circumstances is resuming battery bench desired? 2 - ? |
| 15:26:29 | * | linuxstb didn't know battery bench could be resumed... |
| 15:26:37 | | Part J-23 |
| 15:26:59 | | Join J-23 [0] (n=aldwulf@a105.net128.okay.pl) |
| 15:27:14 | gevaerts | soap: r18569? |
| 15:28:39 | amiconn | linuxstb: Lower BLOCKS_PER_LOOP should also help the gigabeat F and X |
| 15:28:44 | gevaerts | oh, file _name_ |
| 15:29:36 | amiconn | Someone around who could check that? |
| 15:29:48 | | Join PaulJam [0] (i=PaulJam_@vpn-3048.gwdg.de) |
| 15:31:13 | * | n1s wants ipod people with ipods to test the latest batch of bootloaders in FS #9369 color is already done so only 7 to go :) |
| 15:31:16 | soap | I guess I could have it check for any existing battery bench file of the same SVN revision number. |
| 15:31:32 | n1s | so that we can finally get those on the download site |
| 15:32:08 | n1s | umm s/ipod people/regular people/ ? :) |
| 15:32:09 | soap | gevaerts, it would make the *Runtime wiki pages much nicer if all the battery bench text files not only were unique, but also quickly were sortable by the identification information. |
| 15:32:53 | linuxstb | soap: I'm not sure what the resume problem is - if the svn revision (or target name!) have changed, shouldn't that be a different benchmark? |
| 15:33:24 | | Join MethoS- [0] (n=clemens@host-091-096-208-049.ewe-ip-backbone.de) |
| 15:33:31 | soap | yea, the problem is I was also thinking about adding the date - which could just be ignored in the check |
| 15:33:45 | linuxstb | Why would you want the date? |
| 15:34:10 | LambdaCalculus37 | linuxstb: Maybe for logging purposes, e.g. when the bench was run? |
| 15:34:15 | soap | because _I_ do multiple benchmarks and use the average of multiple identical tests. |
| 15:34:49 | soap | but, yes, date is the least important of the information to add. |
| 15:36:38 | linuxstb | Isn't there already a function (used in the recording code?) to create those kind of filenames? I think you give it a prefix, and it will append either the date/time or a unique integer. |
| 15:36:53 | linuxstb | (depending on whether the target has an RTC) |
| 15:37:17 | soap | That makes sense, I didn't even think of looking there for examples. |
| 15:37:50 | linuxstb | create_numbered_filename() in apps/misc.c |
| 15:38:20 | soap | no no no. Stop telling me such things! ;) |
| 15:38:45 | linuxstb | Seems there are two functions - one for all targets (with a number), and one only for RTC targets (for date/time) |
| 15:38:47 | soap | I want to figure this out on my own. I know most of you could do this in 5 minutes while running on a treadmill. |
| 15:39:29 | soap | I was just testing the waters to make sure it wasn't a horrible no-do idea. |
| 15:39:30 | LambdaCalculus37 | soap: I'm not quite in that league yet. ;) |
| 15:39:36 | amiconn | It should help the Gigabeat F/X even more since the S3C2440 has no L2 cache |
| 15:40:00 | amiconn | No takers? |
| 15:40:22 | | Join midgey [0] (n=tjross@c-68-42-68-108.hsd1.mi.comcast.net) |
| 15:40:24 | linuxstb | amiconn: I can't now, but maybe this evening.... |
| 15:43:30 | amiconn | It seems that while the beast doesn't charge in rockbox, it runs entirely from charger power when the charger is connected, so the battery won't drain either |
| 15:43:58 | amiconn | I noticed this when I wanted to shut down after a panic using the battery switch, and wondered why nothing happened... |
| 15:44:07 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 15:44:10 | | Quit jhulst (Read error: 113 (No route to host)) |
| 15:44:28 | * | linuxstb thought his beast was dead when he first bought it, until he spotted the tiny battery switch... |
| 15:45:10 | * | LambdaCalculus37 wonders why the battery switch on the X and S were made so tiny, when it was bigger on the F |
| 15:45:47 | amiconn | But when the charger is connected and the hdd spins up, there's a whirring noise in the headphone output |
| 15:46:51 | * | amiconn wonders when LambdaCalculus37 will fix his mess... |
| 15:49:39 | | Quit UncleRemus ("leaving") |
| 15:50:26 | LambdaCalculus37 | amiconn: When I can get to a wireless access point. |
| 15:50:54 | moos | 14.36.28 # <LambdaCalculus37> linuxstb: I'll probably just commit the fix myself if anything, but it won't be until around 12:30 GMT-5. |
| 15:51:00 | moos | oops too slow :) |
| 15:51:56 | | Quit midgey () |
| 15:52:44 | amiconn | LambdaCalculus37: Overlooked that, sorry |
| 15:53:10 | | Quit petur ("*plop*") |
| 15:53:47 | LambdaCalculus37 | amiconn: No worries. |
| 15:54:22 | funman | http://paste.ubuntu.com/53447/ < is that diff acceptable for rockbox ? |
| 15:56:41 | | Join {phoenix} [0] (n=dirk@p54B47C46.dip.t-dialin.net) |
| 15:57:53 | | Quit BigBambi ("http://www.mibbit.com ajax IRC Client") |
| 15:57:59 | funman | I mean does it integrate well with your Makefile ? |
| 15:58:13 | | Quit Darksair ("ERC Version 5.3 (IRC client for Emacs)") |
| 15:59:49 | funman | hum it's not correct, it prevents the bootloader to be built |
| 16:00 |
| 16:03:35 | funman | did you consider using automake ? |
| 16:04:04 | * | amiconn thinks funman should better not mention automake... |
| 16:04:16 | funman | why ? |
| 16:05:34 | amiconn | Iirc some people are very firmly against it. I'm not sure why though as I never used it. Should be in the logs somewhere |
| 16:05:47 | funman | I know that |
| 16:06:06 | funman | but I don't know of any better solution |
| 16:06:17 | amiconn | For what? |
| 16:06:39 | funman | building programs |
| 16:06:45 | amiconn | The current build system works rather well, apart from some minor dependency quirks (things not rebuilt when they should) |
| 16:06:58 | funman | well for me it works rather badly |
| 16:07:06 | amiconn | But I think these quirks are fixable without introducing an additional system |
| 16:07:17 | funman | maybe I need some hacking before understanding the inners |
| 16:07:28 | funman | adding a dependancy just skips some other |
| 16:07:40 | B4gder | eh, that's plain makefile |
| 16:07:47 | B4gder | automake doesn't fix those issues |
| 16:08:06 | funman | at least I understand the Makefiles it does generate |
| 16:08:23 | B4gder | then you must be special, as a vast amount of people don't - including me |
| 16:08:44 | funman | I may hit a corner case |
| 16:09:03 | B4gder | the current build system has grown a bit too complicated though |
| 16:09:13 | funman | % make $PWD/bootloader/bootloader.bin |
| 16:09:13 | funman | make: *** No rule to make target `/media/bordel/bootloader/bootloader/bootloader.bin'. Stop. |
| 16:09:44 | B4gder | and your makefile has a rule for that target? |
| 16:09:58 | funman | I did not delete the rule |
| 16:10:11 | B4gder | did you create it? |
| 16:10:17 | amiconn | Making single files never worked for me in rockbox builds |
| 16:10:22 | funman | the full diff is here : http://paste.ubuntu.com/53447/ |
| 16:10:31 | B4gder | the main makefile has no rule for that file afair |
| 16:10:37 | amiconn | A simple 'make', or one of the phony targets (bin, rocks) work for me |
| 16:11:09 | funman | the rule is in bootloader/Makefile |
| 16:11:27 | B4gder | but where did you invoke make? |
| 16:11:33 | funman | in the root |
| 16:11:52 | B4gder | so then it uses the root Makefile |
| 16:12:31 | funman | which will run make in bootloader/ |
| 16:12:40 | B4gder | no |
| 16:12:51 | B4gder | you specified a target on the command line |
| 16:12:53 | funman | don't get me wrong: the build is fine, until I modify it |
| 16:13:17 | funman | only to narrow down the problem |
| 16:13:23 | funman | I can paste the useless full log if you desire |
| 16:13:47 | B4gder | not now, I have a peek at it tonight |
| 16:13:51 | B4gder | I can even |
| 16:13:56 | funman | ok |
| 16:15:17 | funman | oh .. I know |
| 16:15:30 | funman | my new target is the first one in the Makefile |
| 16:15:57 | funman | it's fine if I move it after "all:" |
| 16:16:36 | | Quit n1s () |
| 16:17:24 | kugel | B4gder: I wanted to ask you if you can give me the sansav2/as3525 datasheet |
| 16:17:38 | kugel | I promise not to re-distribute or publish it |
| 16:17:57 | B4gder | sure, lemme do that tonight too |
| 16:18:09 | kugel | cool, thanks |
| 16:23:27 | amiconn | linuxstb: Apart from the insane buffer and the initial coefficients, all data defined in the codec itself is already in IRAM (on targets with IRAM support). Gcc includes __clz_tab from libgcc though, and that's not in iram |
| 16:23:28 | | Join jgarvey [0] (n=jgarvey@cpe-098-026-069-229.nc.res.rr.com) |
| 16:23:36 | amiconn | Do you know where this might be used? |
| 16:24:52 | linuxstb | Is that clz as in "count leading zeros" ? |
| 16:24:56 | amiconn | yes |
| 16:25:08 | funman | amiconn: you can use gcc -S and look for it in the preprocessed source |
| 16:25:11 | linuxstb | Maybe the range codiing, but I can't remember it... |
| 16:25:24 | amiconn | It's the table used by that function. The function itself must be inlined, because there's nothing visible in .text |
| 16:25:40 | amiconn | *If* this is used often, it'll especially hurt coldfire |
| 16:26:12 | amiconn | We should probably roll our own clz() for those armv4 and coldfire |
| 16:27:08 | linuxstb | Isn't there one in the alac decoder? Written by you I think... |
| 16:27:11 | * | amiconn thinks it's probably easier to check the symbol tables of the object files |
| 16:27:32 | amiconn | linuxstb: Yeah, the function isn't the problem. I need to find out where it's used though |
| 16:29:29 | | Quit rvvs89 (Read error: 54 (Connection reset by peer)) |
| 16:32:55 | | Join rvvs89 [0] (n=rvvs89@pdpc/supporter/active/rvvs89) |
| 16:33:28 | | Quit TMM (Read error: 104 (Connection reset by peer)) |
| 16:34:42 | | Join TMM [0] (n=hp@5ED10264.cable.ziggo.nl) |
| 16:36:19 | | Quit TMM (Read error: 104 (Connection reset by peer)) |
| 16:36:55 | | Join TMM [0] (n=hp@5ED10264.cable.ziggo.nl) |
| 16:37:07 | funman | can I invoke the cross compiler in tools/ ? CC is not set and defaults to 'gcc' |
| 16:37:59 | funman | or maybe I should create a precompiled version of the arm thumb nrv2ed8 decompressor since it's unlikely to change |
| 16:38:24 | kugel | funman: add it to the tools target |
| 16:38:35 | kugel | so that make tools will build it |
| 16:38:59 | funman | that's what I wanted to do first, but like I said it seems to be meant for host tools, not target code |
| 16:39:17 | amiconn | funman: Imho target code shouldn't be in tools/ |
| 16:39:27 | kugel | then tools/ isn't suitable, yes |
| 16:39:29 | amiconn | It should probably be in bootloader/ |
| 16:39:51 | funman | it's needed for the firmware patcher |
| 16:39:52 | amiconn | linuxstb: Looks like gcc uses __clz_tab for its division routines... |
| 16:40:09 | funman | not for the bootloader |
| 16:40:14 | kugel | funman: other firmware patchers aren't in tools either |
| 16:40:33 | amiconn | But then I don't understand why it includes this for coldfire, which has a 'div' instruction... |
| 16:40:43 | funman | kugel: at least 4 of them are (mk*boot.c) |
| 16:40:59 | B4gder | they're for host tools |
| 16:41:17 | B4gder | patching is done on host |
| 16:41:27 | kugel | funman: E.g. sansapatcher, there you need to build a bootloader in bootloader/ first, and use the created file to build sansapatcher in rbutil/sansapatcher/ |
| 16:41:34 | | Join spiorf [0] (n=spiorf@host83-227-dynamic.25-79-r.retail.telecomitalia.it) |
| 16:41:49 | preglow | did that FLOSS interview ever surface somewhere? i can't seem to find the most recent one |
| 16:41:55 | amiconn | Hmm, 64 bit division... |
| 16:42:03 | B4gder | preglow: I think it is supposed to pop out tonight US time |
| 16:42:06 | GodEater | preglow: funny, I just complained in community |
| 16:42:06 | GodEater | :) |
| 16:42:11 | preglow | ah, ok |
| 16:42:15 | funman | hm so I should move mkamsboot.c & the arm code in rbutil/ , not in tools ? |
| 16:42:53 | kugel | I'd rather move mkamsboot into rbutil and the arm code in bootloader |
| 16:42:58 | linuxstb | amiconn: Ouch, where does that happen? |
| 16:43:06 | amiconn | In ape.c itself... |
| 16:43:15 | | Quit fragilematter ("Leaving.") |
| 16:43:25 | B4gder | I'd rather move mkamsboot into tools and the arm code in bootloader/ |
| 16:43:27 | linuxstb | Ah, for the elapsed time or similar? |
| 16:43:31 | B4gder | I think |
| 16:43:47 | funman | right, but this arm code is needed by mkamsboot |
| 16:43:54 | funman | isn't that a problem ? |
| 16:44:10 | B4gder | I bet ;-) |
| 16:44:47 | B4gder | it's not such a big deal imo |
| 16:44:48 | | Quit fyrestorm ("irc protip: try "DCC SEND STARTKEYLOGGER 0 0 0" to hack noobs!") |
| 16:45:04 | B4gder | I'd start with putting them all in tools |
| 16:45:04 | funman | I think I'll hack all this without caring about rockbox guidelines, and deal with the problems when the full bootloader is ready |
| 16:45:11 | | Quit amiconn (Nick collision from services.) |
| 16:45:14 | | Join fyrestorm [0] (n=fyre@cpe-68-173-234-148.nyc.res.rr.com) |
| 16:45:17 | | Join amiconn [0] (n=jens@p54BD6CEF.dip.t-dialin.net) |
| 16:45:23 | kugel | probably a good idea |
| 16:45:28 | linuxstb | funman: I would like to think about how to deal with that, but I'm busy on real work at the moment. My current thoughts are that maybe we should just put everything in "bootloader.bin", including the ucl uncompress function. But I need to think about that more this evening... |
| 16:45:44 | funman | linuxstb: the bootlader.bin needs to be compressed |
| 16:45:55 | LambdaCalculus37 | Yay, no more red on Players! :) |
| 16:45:56 | funman | hence the decompressing code can not be included |
| 16:46:27 | amiconn | This 64 bit calculation won't hit decoding performance |
| 16:46:28 | kugel | we don't know yet, if it really *must* be compressed |
| 16:46:42 | funman | it can't harm |
| 16:46:46 | kugel | at this point it's rather optional |
| 16:46:57 | funman | empty bootloader is already 9.4kB |
| 16:47:02 | linuxstb | funman: I know, my plan doesn't stop that... "bootloader.bin" would consist of the ucl unpack code, plus the ucl-compressed copy of the real bootloader.bin. We need better names... |
| 16:47:21 | amiconn | funman: Why can't it? |
| 16:47:36 | funman | amiconn: why could it ? |
| 16:47:45 | amiconn | Like linuxstb said... |
| 16:48:05 | | Quit Zagor ("Client exiting") |
| 16:48:33 | amiconn | It could even be made conditional, like the self-extracting archos binaries |
| 16:49:03 | amiconn | if (uncompressed_bootloader_too_big()) make_compressed_version(); in the Makefile |
| 16:49:37 | funman | hmm you confuse me too much |
| 16:50:01 | funman | how can we even know if the file is too big in a Makefile ? |
| 16:50:09 | amiconn | Check the size... |
| 16:50:36 | funman | against what ? the available size is given by a tool ran on the original firmware file |
| 16:51:14 | kugel | you build the "real bootloader.bin", then decide if it needs to be compressed, and put the ucl decompresser + the compressed or not compressed bootloader.bin to the resulting bootloader.bin |
| 16:51:17 | markun | funman: can't the make run this tool to check for the size? |
| 16:51:25 | amiconn | Then run that tool as part of the bootloader build process |
| 16:51:28 | markun | the makefile |
| 16:51:45 | linuxstb | The max size depends on the OF file we're patching - so I think it's easier to either always compress or never compress. |
| 16:52:21 | linuxstb | Otherwise, you need the OF file to build the bootloader... |
| 16:52:52 | amiconn | Then simply always compress |
| 16:53:00 | funman | that's what we want |
| 16:53:06 | markun | ok :) |
| 16:53:18 | funman | maybe I can do that with $boottool |
| 16:53:58 | funman | bootoutput=rockbox.bin which is the real rockbox bootloader, which doesn't care about dualbooting |
| 16:54:26 | linuxstb | funman: I'm also thinking the dual-boot code should go in there... |
| 16:54:40 | linuxstb | (in crt0.S for bootloader builds) |
| 16:54:56 | funman | I don't like much this idea |
| 16:55:19 | linuxstb | funman: I agree it's less safe for development, but for long-term use, I think it's the right place. |
| 16:55:23 | funman | if we link incorrectly, we may brick the devices |
| 16:57:15 | funman | well I'll continue |
| 16:57:22 | funman | thanks for the input |
| 16:58:44 | J-23 | can I use sansapatcher with firmware.mi4 newer than firmware I have on my player? |
| 16:59:05 | | Quit funman ("leaving") |
| 17:00 |
| 17:01:05 | | Quit m0f0x (Read error: 110 (Connection timed out)) |
| 17:05:20 | *** | Saving seen data "./dancer.seen" |
| 17:05:59 | | Part B4gder |
| 17:08:32 | | Quit MethoS- (Remote closed the connection) |
| 17:08:52 | J-23 | hmm, Rockbox bootloader on my Sansa c240 hangs after "Binary type: RBOS" message |
| 17:09:30 | amiconn | hah, something not IRAMified that seems to be used often.. |
| 17:09:52 | J-23 | is it possible to fix that? |
| 17:10:28 | | Join HBK- [0] (i=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
| 17:10:39 | J-23 | I installed new bootloader (SVN) as it's described in rbutil/sansapatcher/README, but it didn't help. |
| 17:11:08 | amiconn | Do you have a microsdhc card plugged? |
| 17:11:23 | J-23 | no. |
| 17:11:32 | J-23 | there are no cards in slot |
| 17:11:45 | amiconn | Ok, then it's not what I thought |
| 17:12:13 | kugel | J-23: The SVN bootloader seems to have a problem. bertrik and gevaerts have such problems too (IIRC) |
| 17:12:45 | amiconn | linuxstb: I have a nice speedup on coldfire :) (-c1000: 211% -> 253%) |
| 17:13:00 | amiconn | The rangecoder struct was not in IRAM |
| 17:13:17 | linuxstb | Ah, nice ;) |
| 17:13:19 | amiconn | That's a tiny struct - just 16 bytes |
| 17:13:37 | amiconn | Such happens if you put actual code in .h files :\ |
| 17:14:10 | * | linuxstb lowers head in shame |
| 17:16:17 | | Join midgey [0] (n=tjross@c-68-42-68-108.hsd1.mi.comcast.net) |
| 17:20:24 | gevaerts | amiconn: do you still need testing on gigabeat F? |
| 17:20:31 | amiconn | yes |
| 17:20:42 | * | gevaerts gets his F60 |
| 17:21:14 | gevaerts | Yesterday's build (or so) versus current svn for APE, right? |
| 17:21:23 | amiconn | No |
| 17:21:34 | | Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) |
| 17:21:42 | gevaerts | hm, I'm misremembering then |
| 17:22:13 | amiconn | First check current SVN. Then open apps/codecs/ape.c, change BLOCKS_PER_LOOP to 1024, and test that |
| 17:22:20 | gevaerts | ok |
| 17:22:27 | | Quit {phoenix} ("Konversation terminated!") |
| 17:23:28 | amiconn | You can probably leave out -c5000 for the baseline |
| 17:23:48 | amiconn | ...although it doesn't take *that* long on a gigabeat |
| 17:24:25 | amiconn | Make sure you delete apps/codecs/ape.* to force a relink (or make clean) |
| 17:24:42 | amiconn | (in the build directory of course) |
| 17:25:16 | | Join herrwaldo [0] (n=waldo@ip-81-11-212-219.dsl.scarlet.be) |
| 17:25:24 | gevaerts | I'll do a make clean. Building is pretty fast here anyway, and it can rebuild while test_codec is doing its things |
| 17:27:35 | | Quit HBK (Read error: 110 (Connection timed out)) |
| 17:27:48 | | Quit Twisty (Read error: 110 (Connection timed out)) |
| 17:30:20 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
| 17:30:32 | soap | so any theories on why my build server barfs randomly (?) on sim builds? |
| 17:30:48 | gevaerts | soap: have you run memtest86 on it? |
| 17:31:08 | soap | no, I haven't. Why only sim builds, though? |
| 17:31:16 | soap | I can do that in a second. |
| 17:32:38 | | Part jingjing |
| 17:33:05 | rasher | soap: I had that as well when I ran a buildserver. Never got to the bottom of it |
| 17:33:10 | rasher | soap: segfaults? |
| 17:33:13 | soap | yes |
| 17:33:30 | rasher | Which distro, and cpu? |
| 17:33:56 | soap | ubuntu 8.04 and Xeon (C2D) |
| 17:34:10 | kugel | does test codec take activated dsp effects into account? |
| 17:34:45 | gevaerts | kugel: not as far as I know |
| 17:34:51 | rasher | soap: Not at all like mine then (Debian and amd xp2800) |
| 17:35:11 | kugel | hm, sad :( I'd like to know how much CPU e.g. crossfeed eats |
| 17:35:27 | kugel | soap: 64bit? |
| 17:35:30 | soap | no |
| 17:36:31 | soap | kugel, you could monitor boost percentage? |
| 17:36:56 | soap | or I could do a battery bench for you tonight |
| 17:37:30 | kugel | Yea, that's what I've done until now. But I'd like to have an exact value |
| 17:37:40 | soap | your choice. I just did four tests on my Nano, no problem to do another one. |
| 17:38:17 | kugel | Sure, how could I say no to that offer :) Thanks |
| 17:38:20 | soap | you'd have a with and without example, and the pairs of benches have matched to within two minutes, so the test should be fairly indicative |
| 17:39:11 | soap | Do you have an idea which would be more accurate: Doing the crossfeed test pre MP3 dual core or post MP3 dual core? |
| 17:39:43 | gevaerts | You can always do it with non-mp3 |
| 17:39:45 | | Quit faemir (Read error: 104 (Connection reset by peer)) |
| 17:40:13 | soap | Is there a specific reason not to do it with MP3? |
| 17:40:42 | kugel | I'm bored. I think I'll just update the CodecPerformaceComparison table for e200 |
| 17:40:51 | kugel | it's rather old |
| 17:42:01 | soap | FWIW, saratoga believes the MP3 dual core work should currently free up around 6 mhz (30 mhz unboosted could be lowered to 24 mhz unboosted) so anything which uses 6 mhz or less might very well go unnoticed) (I hope I am paraphrasing him correctly) |
| 17:42:04 | kugel | Am I required to use the encoders on that page or can I use other ones? |
| 17:42:13 | | Join faemir [0] (n=quassel@88-106-165-155.dynamic.dsl.as9105.com) |
| 17:42:33 | kugel | It just said 21.xMHz |
| 17:42:54 | gevaerts | kugel: if you want comparable results, I think you need the same encoders |
| 17:43:47 | | Join MethoS- [0] (n=clemens@pD955DFE7.dip.t-dialin.net) |
| 17:44:38 | kugel | on another file though |
| 17:44:48 | kugel | gevaerts: sad to hear :( |
| 17:45:11 | | Join hannesd [0] (n=light@p5B163AD3.dip0.t-ipconnect.de) |
| 17:45:17 | | Join perrikwp [0] (i=d1a8d351@gateway/web/ajax/mibbit.com/x-b454561beedf829d) |
| 17:45:23 | kugel | but I think I can live with it |
| 17:52:02 | * | ameyer twiddles his thumbs as he waits for the mailman and potentially 4 HDDVDs and an iPod mini |
| 17:56:09 | | Quit Siku () |
| 17:56:57 | kugel | hddvd is dead |
| 17:57:08 | * | gevaerts points to the topic |
| 17:59:24 | ameyer | kugel: I'm aware |
| 17:59:33 | * | ameyer gets back on-topic |
| 18:00 |
| 18:03:48 | | Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) |
| 18:03:48 | | Join bluebrother [0] (i=d55f4408@gateway/web/ajax/mibbit.com/x-ecf218da6223fcb9) |
| 18:10:30 | | Join {phoenix} [0] (n=dirk@p54B47741.dip.t-dialin.net) |
| 18:11:14 | | Join intrinsic [0] (n=93206089@gateway/web/cgi-irc/labb.contactor.se/x-baf2e364e56e19eb) |
| 18:11:46 | ameyer | although my first statement was at least close to on-topic |
| 18:11:46 | | Quit moos ("have a nice day all") |
| 18:11:58 | | Nick intrinsic is now known as intrnsic (n=93206089@gateway/web/cgi-irc/labb.contactor.se/x-baf2e364e56e19eb) |
| 18:12:00 | gevaerts | ameyer: please... |
| 18:12:36 | ameyer | gevaerts: please what? |
| 18:12:56 | | Quit miepchen^schlaf () |
| 18:14:09 | gevaerts | Try to stay on topic. We don't need to know what the mailman will bring you, _and_ we don't care about hd dvd |
| 18:14:42 | intrnsic | i'm trying to get a custom theme to work; the font changes correctly when I select the theme but the WPS stays at the rockbox_default WPS |
| 18:14:45 | ameyer | you know what, f this |
| 18:14:47 | | Part ameyer |
| 18:14:56 | intrnsic | what are some possible causes |
| 18:15:06 | | Quit midgey () |
| 18:15:24 | intrnsic | i've made sure that the theme's .cfg and .wps files are both Unix formatted instead of Windows |
| 18:15:39 | intrnsic | and I've tried it with both 8 bit and 24 bit bitmap images |
| 18:15:53 | intrnsic | I can upload the files I'm using if that will help |
| 18:16:00 | gevaerts | intrnsic: try running them in the simulator. You should get error messages then |
| 18:16:27 | intrnsic | where's this simulator |
| 18:16:32 | robin0800 | intrnsic: look in forums at WPS for recent syntax changes |
| 18:17:33 | | Join MethoS-- [0] (n=clemens@pD955DA28.dip.t-dialin.net) |
| 18:17:43 | gevaerts | intrnsic: there are windows simulator builds at rasher.dk/rockbox/simulator/.">http://rasher.dk/rockbox/simulator/. For linux or mac, you'll have to compile yourself |
| 18:17:49 | intrnsic | ty |
| 18:18:42 | rasher | Which reminds me that those are horribly out of date |
| 18:18:45 | amiconn | linuxstb: I know what could be put into the extra IRAM when lowering BLOCKS_PER_LOOP: code... |
| 18:19:08 | amiconn | This would definitely help PP5002, and also coldfire a bit |
| 18:19:20 | gevaerts | rasher: I think they are recent enough for WPS use |
| 18:19:20 | | Quit MethoS- (Read error: 60 (Operation timed out)) |
| 18:19:26 | | Quit soap (Remote closed the connection) |
| 18:19:41 | rasher | gevaerts: should be, yes |
| 18:19:49 | amiconn | It should probably be excluded for PP502x, as that usually becomes slower with ICODE (probably due to the longcalls) |
| 18:20:35 | | Join midgey [0] (n=tjross@c-68-42-68-108.hsd1.mi.comcast.net) |
| 18:23:56 | | Join Acky [0] (n=omgwtfbb@cpc2-stok5-0-0-cust754.bagu.cable.ntl.com) |
| 18:24:14 | gevaerts | amiconn: http://pastebin.ca/1218156 |
| 18:25:33 | amiconn | Thanks |
| 18:25:44 | amiconn | Looks like lowering the block size is a good idea |
| 18:26:07 | amiconn | It doesn't hurt the other targets, and even frees some IRAM on them |
| 18:26:22 | amiconn | It speeds things up on Gigabeat F/X and S |
| 18:26:50 | | Join {-phoenix-} [0] (n=dirk@p54B47C42.dip.t-dialin.net) |
| 18:26:57 | gevaerts | It may slows things down a bit for c5000, but as long as that's so slow it doesn't count |
| 18:27:16 | amiconn | According to your results it doesn't |
| 18:27:47 | gevaerts | 0.02% is probably well within measurement accuracy, yes |
| 18:27:57 | amiconn | -c5000 is practically unaffected because its history buffer alone is too large for the cache |
| 18:28:18 | amiconn | (S3C2440 has 16KB data cache, as does the I.MX31L) |
| 18:29:50 | amiconn | linuxstb: Any reason why this shouldn't be changed? |
| 18:30:01 | linuxstb | amiconn: No, I can't think of any. |
| 18:30:38 | linuxstb | Unless the size of data passed to pcmbuf_insert() affects anything - e.g. the DSP processing. But I know nothing about that |
| 18:35:08 | intrnsic | ok, thanks for the link to the simulator.On loading the .wps, It's telling me "ERR: Failed parsing on line 12 : ERR: Unexpected conditional char after token 2: "String 'pb.bmp'" |
| 18:35:14 | intrnsic | the line in question is %P|pb.bmp| |
| 18:35:37 | linuxstb | intrnsic: Now read the description of %P on the CustomWPS wiki page |
| 18:35:39 | intrnsic | the entire .wps file, renamed to .txt, is here: http://www.fileden.com/files/18968/d2.txt |
| 18:35:45 | | Join Darksair [0] (n=user@221.221.164.210) |
| 18:37:18 | | Quit Acksaw (Connection timed out) |
| 18:38:06 | intrnsic | i don't see any description of %P |
| 18:38:14 | intrnsic | do I need to rewrite it as %pb? |
| 18:38:42 | linuxstb | intrnsic: I expect so - I know the syntax has changed, but forget the details. |
| 18:41:37 | | Quit {phoenix} (Read error: 110 (Connection timed out)) |
| 18:41:38 | intrnsic | where is pixel (1,1) |
| 18:41:47 | | Join fragilematter [0] (n=fragilem@92.83.251.216) |
| 18:42:13 | | Quit Nico_P (Remote closed the connection) |
| 18:42:17 | | Quit midgey () |
| 18:42:32 | intrnsic | which corner |
| 18:42:55 | bluebrother | top left |
| 18:43:46 | | Join Acksaw [0] (n=omgwtfbb@cpc2-stok5-0-0-cust754.bagu.cable.ntl.com) |
| 18:44:04 | intrnsic | ty |
| 18:45:41 | | Join rniamo [0] (n=rniamo@abo-192-221-68.trs.modulonet.fr) |
| 18:45:44 | rniamo | hi |
| 18:46:44 | rniamo | i would like to know if rockbox is compatoble with ipod nano 4G |
| 18:47:09 | gevaerts | It isn't |
| 18:47:25 | gevaerts | (if you mean 4th generation, that is.) |
| 18:47:53 | rniamo | ok, thanks |
| 18:47:58 | | Quit Kopfgeldjaeger ("Serverwechsel") |
| 18:48:41 | | Quit Acky (Connection timed out) |
| 18:49:50 | | Quit {-phoenix-} ("Konversation terminated!") |
| 18:50:04 | | Join {-phoenix-} [0] (n=dirk@p54B47C42.dip.t-dialin.net) |
| 18:50:25 | | Part rniamo ("Quitte") |
| 18:51:18 | intrnsic | how can I use the simulator to test my WPS? It gives me errors if I try and play an mp3. I just need to see the screen so I can test the positions of everything |
| 18:51:30 | | Join webguest50 [0] (n=4dfdf7e1@gateway/web/cgi-irc/labb.contactor.se/x-108e4d6370d1ef1b) |
| 18:51:38 | | Quit webguest50 (Client Quit) |
| 18:51:48 | linuxstb | intrnsic: What error is it giving? Did you build the sim yourself, or download it? |
| 18:51:49 | intrnsic | also for bitmaps that I'm using, when referring to the location in the .wps file, is the location listed the location of the top left pixel? |
| 18:51:55 | | Join YoJI [0] (n=4dfdf7e1@gateway/web/cgi-irc/labb.contactor.se/x-61af93389bea7087) |
| 18:52:03 | intrnsic | downloaded it |
| 18:52:05 | intrnsic | windows binary |
| 18:52:07 | linuxstb | intrnsic: Yes. And (0,0) is the top-left pixel, not (1,1) |
| 18:52:11 | intrnsic | ok |
| 18:52:27 | | Join Kopfgeldjaeger [0] (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) |
| 18:52:41 | | Join soap [50] (n=soap@rockbox/staff/soap) |
| 18:52:53 | intrnsic | it's giving me a Windows error message, not in the console, for "rockboxui.exe - Bad image" |
| 18:53:06 | intrnsic | "_temp_codec0.dll is not a valid Windows image" |
| 18:53:08 | YoJI | hello |
| 18:53:27 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 18:53:35 | linuxstb | intrnsic: Have you copied the .rockbox folder from a real device to the simulator's directory? |
| 18:54:47 | | Join miepchen^schlaf [0] (n=miepchen@p57BB7D02.dip.t-dialin.net) |
| 18:54:48 | intrnsic | yes |
| 18:54:52 | intrnsic | yes |
| 18:55:01 | linuxstb | That's the problem - you shouldn't do that. |
| 18:55:14 | intrnsic | ok |
| 18:56:18 | linuxstb | At least the files in .rockbox/rocks (plugins) and .rockbox/codecs (codecs) need to be the simulator versions. |
| 18:56:19 | | Quit YoJI (Client Quit) |
| 18:56:20 | | Join wpyh [0] (n=william@123.151.132.200) |
| 18:58:57 | markun | wpyh: HelvR12 was downloaded here: http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html |
| 19:00 |
| 19:00:27 | wpyh | ok |
| 19:00:56 | linuxstb | markun: What's the license for them? |
| 19:01:22 | linuxstb | i.e. do they allow distribution of modified versions? I'm assuming they do if they're in Rockbox... |
| 19:02:19 | linuxstb | wpyh: For the benefit of the logs, what are you wanting to do? |
| 19:02:24 | pixelma | markun: and that's called 15-Adobe-Helvetica now :) |
| 19:03:15 | wpyh | linuxstb: Helvetica uses a BSD-like license, while WenQuanYi uses the GPL+font-embedding-exception |
| 19:03:52 | wpyh | linuxstb: I want to replace glyphs in WenQuanYi with those in Helvetica, so that we get nice latin characters and nice chinese characters in the same font. |
| 19:04:13 | linuxstb | For code, BSD and GPL are compatible, so I would expect it to work the same for fonts. |
| 19:05:08 | | Quit mf0102 (Remote closed the connection) |
| 19:05:22 | *** | Saving seen data "./dancer.seen" |
| 19:05:46 | wpyh | linuxstb: I hope so... though I heard that there's one version of BSD (4-clause?) that is not compatible with the GPL |
| 19:05:51 | * | wpyh goes to check fsf's website |
| 19:06:31 | linuxstb | Isn't that the advertising clause? |
| 19:06:47 | wpyh | linuxstb: yeah |
| 19:06:48 | gevaerts | Yes |
| 19:06:49 | | Quit J-23 (Read error: 104 (Connection reset by peer)) |
| 19:07:13 | | Join J-23 [0] (n=aldwulf@a105.net128.okay.pl) |
| 19:07:51 | * | kugel hopes test_codec finishes ape_insane test before the battery is empty |
| 19:09:02 | | Join hannesd_ [0] (n=light@p5B1600E1.dip0.t-ipconnect.de) |
| 19:10:12 | | Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) |
| 19:11:16 | | Part fragilematter |
| 19:11:39 | | Quit soap (Remote closed the connection) |
| 19:20:14 | | Quit robin0800 (Read error: 110 (Connection timed out)) |
| 19:21:25 | | Join dan_a [0] (n=user@217.23.173.156) |
| 19:23:55 | | Quit hannesd (Read error: 110 (Connection timed out)) |
| 19:23:56 | | Nick hannesd_ is now known as hannesd (n=light@p5B1600E1.dip0.t-ipconnect.de) |
| 19:24:44 | amiconn | kugel: e200? And how long is your track? |
| 19:25:12 | kugel | the sample track |
| 19:25:22 | kugel | 175.x seconds IIRC |
| 19:25:25 | intrnsic | How can I align the clock and volume text at the top of the screen? http://www.fileden.com/files/18968/h10.1.PNG is what I have now. As far as I can tell the line of code which is doing this is: %al %cH:%cM%ar%pv |
| 19:26:13 | * | amiconn is slightly confused about ape speed with ICODE_ATTR on PP5002 |
| 19:26:40 | pixelma | intrnsic: move that line one up in your wps file |
| 19:26:42 | kugel | intrnsic: You just put it onto the first line |
| 19:26:50 | kugel | after the image definitions |
| 19:28:04 | intrnsic | the only thing before that, and after the image definitions is %wd |
| 19:28:07 | intrnsic | where should I move that to? |
| 19:28:22 | intrnsic | also does whitespace matter? |
| 19:28:34 | amiconn | kugel: Expect around 1h 20min for that test, then |
| 19:28:50 | kugel | sounds like fun |
| 19:29:47 | pixelma | intrnsic: right below the %wd and then insert a blank line if you don't want the other things one line up in the WPS. The lines on the screen correspond to the lines in your WPS if you don't use viewports and not for things you specify x- and y-coordinates for |
| 19:30:58 | | Join Horschti [0] (n=Horscht@p4FD4E769.dip.t-dialin.net) |
| 19:31:42 | | Quit Horscht (Nick collision from services.) |
| 19:32:56 | | Nick Horschti is now known as Horscht (n=Horscht@xbmc/user/horscht) |
| 19:33:37 | | Join soap [50] (n=soap@rockbox/staff/soap) |
| 19:38:02 | | Join bughunter2 [0] (n=Jelle@77.164.66.126) |
| 19:44:35 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 19:48:01 | | Join goffa_ [0] (n=goffa@216.220.23.105) |
| 19:50:06 | | Join perrikwp [0] (i=d1a8d351@gateway/web/ajax/mibbit.com/x-4eebe48c1350fc99) |
| 19:54:32 | | Quit einhirn (Read error: 104 (Connection reset by peer)) |
| 19:58:25 | | Quit goffa (Read error: 110 (Connection timed out)) |
| 20:00 |
| 20:02:10 | | Quit soap (Remote closed the connection) |
| 20:02:32 | kugel | amiconn: Would it hurt if ape decoding would yield() sometimes? My sansa is completely unresponsive |
| 20:03:05 | kugel | oh, it crashed |
| 20:04:22 | linuxstb | kugel: That's simply because the codec is too slow with insane files. You shouldn't be using them.... |
| 20:04:43 | kugel | Well, I know |
| 20:05:11 | kugel | I'm testing codec performance (for the CodecPerfomanceComparison page) |
| 20:05:19 | linuxstb | I know. |
| 20:07:24 | | Join m0f0x [0] (n=m0f0x@189-47-72-141.dsl.telesp.net.br) |
| 20:07:36 | | Join mirak [0] (n=mirak@81-66-70-98.rev.numericable.fr) |
| 20:08:48 | amiconn | Afaik you cannot interrupt test_codec |
| 20:10:02 | | Quit Darksair ("ERC Version 5.3 (IRC client for Emacs)") |
| 20:13:26 | kugel | amiconn: Yea, I've noticed that... |
| 20:14:51 | | Join fragilematter [0] (n=fragilem@92.83.251.216) |
| 20:14:54 | wpyh | btw, this is the license for helvetica: http://pastebin.ca/1218244 |
| 20:16:18 | wpyh | and this is the comment block for WenQuanYi, mentioning "GPL v2.0 (with font embedding exception)": http://pastebin.ca/1218246 |
| 20:17:54 | | Join EspeonEefi [0] (i=espeonee@18.74.7.76) |
| 20:18:07 | wpyh | since helvetica's license is similar to the bsd license (without the advertising clause), we can combine both fonts legally. |
| 20:18:52 | | Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") |
| 20:19:10 | | Join LambdaCalculus37 [0] (i=44a04303@gateway/web/ajax/mibbit.com/x-c1cda5b747c26c27) |
| 20:19:12 | * | kugel is thinking of which target I could implement backlight fading next |
| 20:19:23 | wpyh | kugel: ah, I was looking for you the other day |
| 20:19:32 | wpyh | on my ipod nano and ipod video, backlight fading is weird |
| 20:20:05 | kugel | well, that's hardware pwm fading |
| 20:20:45 | wpyh | can we modify the fading to make it more linear? |
| 20:21:09 | kugel | possibly not |
| 20:21:17 | wpyh | hm.. ok... |
| 20:21:29 | kugel | I haven't looked into it though |
| 20:21:32 | pixelma | kugel: the Ondio! :P </sarcasm> |
| 20:21:37 | wpyh | kugel: would you please? :) |
| 20:22:07 | kugel | pixelma: your wish is my command :) |
| 20:22:28 | pixelma | haha, how would you do that? |
| 20:23:01 | kugel | the same way I've done it's done on e200/c200 and gigabeat s (at FS #6800) |
| 20:23:22 | kugel | basically software fading by looping through the brightness levels |
| 20:23:39 | pixelma | a) stock Ondios don't have backlight, b) backlight modded Ondios have EL backlighting |
| 20:23:51 | kugel | EL? |
| 20:23:57 | pixelma | there is no backlight brightness |
| 20:24:12 | kugel | ah, then it's not possible :( |
| 20:26:12 | * | amiconn wonders whether/ how we could utilize dual core in the ape codec |
| 20:26:22 | pixelma | kugel: http://www.rockbox.org/twiki/bin/view/Main/OndioBacklight |
| 20:26:42 | kugel | wpyh: It's dependant if you can even choose the pwm levels. On beast e.g. the levels are chosen in such a manner, that it's not so smooth on highler brightness levels |
| 20:26:55 | wpyh | ok |
| 20:27:01 | amiconn | kugel: The backlight *fading* on ipod Nano and Video is not hardware |
| 20:27:36 | kugel | Oh I thought so |
| 20:27:47 | amiconn | It's software pwm as also used on other ipods, and the H1x0. It is applied *in addition* to the hardware brightness setting |
| 20:28:18 | kugel | so, basically what I've done on the beast? |
| 20:28:45 | amiconn | It's implemented that way in order to get proper fading even at lower brightness levels |
| 20:29:18 | amiconn | If you only use hw brightness for fading the steps are visible |
| 20:29:50 | wpyh | amiconn: so it's like software pwm steps between hardware brightness levels? |
| 20:30:03 | amiconn | no |
| 20:30:16 | kugel | amiconn: have you tried my patch already? It's *very smooth*, even on e200 which has only 12 levels at max |
| 20:30:19 | amiconn | The hardware brightness setting isn't touched at all for fading |
| 20:30:22 | | Quit Acksaw (Read error: 104 (Connection reset by peer)) |
| 20:30:38 | | Join Acksaw [0] (n=omgwtfbb@cpc2-stok5-0-0-cust754.bagu.cable.ntl.com) |
| 20:30:41 | wpyh | ok |
| 20:31:29 | amiconn | The software pwm just switches backlight power, so that this pwm is superimposed to the hardware brightness (which is probably also pwm but at a higher frequency) |
| 20:32:00 | | Join ompaul [0] (n=ompaul@gnewsense/friend/ompaul) |
| 20:32:04 | wpyh | amiconn: ok, then it should be easy to change it... |
| 20:32:14 | amiconn | The software pwm should probably use a quadratic scale for better appearance |
| 20:32:45 | kugel | amiconn: as far as I can see the ipods don't use the backlight thread for fading (udelay instead), which was considered as bad (you can see in the comments of FS #6800) |
| 20:33:02 | | Quit funky ("leaving") |
| 20:33:18 | amiconn | They do not use udelay, but an isr for fading |
| 20:33:34 | | Join nuonguy [0] (n=john@c-71-198-1-139.hsd1.ca.comcast.net) |
| 20:33:43 | amiconn | And since backlight power is controlled via GPIO on the ipods and H1x0, this is okay |
| 20:34:11 | wpyh | amiconn: ah... which explains the problem... |
| 20:34:20 | kugel | and what does udelay(10); in backlight-nano_video.c ten? |
| 20:34:25 | wpyh | I think the backlight fades too quickly at the start |
| 20:34:41 | kugel | s/ten/mean then/ |
| 20:34:53 | amiconn | kugel: This is for brightness setting, not for fading |
| 20:35:15 | amiconn | And it must be done that way because the brightness controller is pulse controlled |
| 20:36:17 | amiconn | Check the parts which are ifdefed HAVE_BACKLIGHT_PWM_FADING in backlight.c |
| 20:36:34 | kugel | I spotted current_dim and a loop, that's why I thought it's used for fading |
| 20:37:37 | amiconn | These are necessary to track the current brightness |
| 20:38:12 | kugel | if you have a sansa or beast, feel free to test my patch at FS #6800 and tell me your opinion about |
| 20:38:15 | amiconn | The chip is pulse controlled, and comes up at medium brightness (level 16, the range is 1..32) |
| 20:38:23 | kugel | ah ok |
| 20:39:05 | amiconn | So if we want to set brightness to 10 we need to remember what it was before (e.g. 16) and then send the appropriate number of pulses (e.g. 6 "dim-down" pulses) |
| 20:39:32 | kugel | pulse controlled means that you need to regulary "fire on" the controller to rise the brightness? |
| 20:40:01 | kugel | and otherwise it would just go out? |
| 20:40:07 | amiconn | no |
| 20:40:59 | amiconn | It works similar to those touch controlled dimmers. |
| 20:41:14 | amiconn | It keeps the brightness constant, unless you send it some pulses |
| 20:41:48 | amiconn | Short pulses increase brightness, long pulses decrease it |
| 20:42:02 | kugel | ah well |
| 20:42:09 | gevaerts | Looks like a real dimmer chip |
| 20:42:12 | kugel | didn't know that |
| 20:42:56 | amiconn | The ISR used for software pwm fading calls only _backlight_on_isr() and _backlight_off_isr(), which are defined as _backlight_led_on() and _backlight_led_off() for ipod video |
| 20:43:27 | amiconn | And those are just GPIO bit manipulations, switching the LED power (dimmer chip power is on a separate pin) |
| 20:43:59 | kugel | aha ok |
| 20:44:24 | amiconn | (ipod video == ipod nano as far as the backlight circuit is concerned) |
| 20:44:53 | amiconn | Btw, backlight brightness on Nano is a rockbox first. The OF doesn't offer this |
| 20:45:24 | kugel | heh, same would go for e200/c200 if the patch was committed |
| 20:45:40 | * | kugel doesn't know about gigabeat s OF |
| 20:46:14 | LambdaCalculus37 | kugel: The beast OF is based off of Windows Mobile. |
| 20:46:37 | kugel | I know that, but that doesn't tell me about backlight fading :) |
| 20:46:53 | gevaerts | kugel: amiconn didn't say "fading" :) |
| 20:47:09 | kugel | oh lol, true |
| 20:47:14 | | Part fragilematter |
| 20:47:38 | amiconn | That reminds me - one reason for getting an iPod Color was for looking into its brightness adjustment... |
| 20:47:41 | kugel | you read what you want to read ;) |
| 20:48:05 | pixelma | my favourite on the c200 (probably e200 as well) is that Rockbox decouples lcd backlight and button/wheel lights which the OF doesn't |
| 20:48:58 | kugel | scratch the probably |
| 20:49:14 | kugel | but yea, I like that too |
| 20:49:19 | | Join soap [50] (n=soap@rockbox/staff/soap) |
| 20:49:48 | kugel | particularly that you deactivate either completely |
| 20:53:27 | | Quit spiorf (Remote closed the connection) |
| 20:57:46 | kugel | looks like there aren't much targets left suitable for backlight fading |
| 20:59:15 | | Quit m0f0x (Read error: 110 (Connection timed out)) |
| 21:00 |
| 21:02:57 | | Join m0f0x [0] (n=m0f0x@189-47-54-138.dsl.telesp.net.br) |
| 21:05:25 | *** | Saving seen data "./dancer.seen" |
| 21:05:45 | * | pixelma got a very helpfull original pegbox graphics package and a real name that goes with it :) |
| 21:06:13 | bertrik | \o/ |
| 21:08:53 | | Join fragilematter [0] (n=fragilem@92.83.251.216) |
| 21:09:46 | | Join Cannoli [0] (n=Email@d38-36-117.commercial1.cgocable.net) |
| 21:10:28 | Cannoli | hi there. i just upgraded to rockbox 3 and when i change themes, the play screen does not change with the theme |
| 21:10:40 | | Join funman [0] (n=fun@86.219.158.180) |
| 21:10:54 | | Quit EspeonEefi (Read error: 60 (Operation timed out)) |
| 21:11:09 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 21:11:16 | | Join perrikwp [0] (i=d1a8d351@gateway/web/ajax/mibbit.com/x-a0f83e7597384714) |
| 21:11:29 | Cannoli | it stays the screen with the progress bar and 2 bars (left and right output) under the progress bar |
| 21:11:40 | amiconn | linuxstb: Do you have an idea regarding dual core support in ape? |
| 21:11:51 | soap | Cannoli, how long ago did you last update? I ask because the theme syntax has changed, breaking the older version of many (most) themes. |
| 21:12:07 | Cannoli | today was my first update in months |
| 21:12:27 | amiconn | Perhaps run entropy decoding on CPU, filter+predictor on COP, then decorrelation (for stereo) on CPU again? |
| 21:12:28 | | Join meven [0] (n=meven@lav35-1-82-236-137-162.fbx.proxad.net) |
| 21:12:30 | kugel | funman: don't make it too clip centric |
| 21:12:30 | linuxstb | amiconn: I guess we would need to benchmark the different stages - maybe the entropy decoding could be done on one core, and everything else on the other. |
| 21:12:47 | soap | Cannoli, the best bet for you is to redownload themes from the wiki, though not all of them have been fixed at this time. If you are more adventurous you can repair said broken themes yourself, the discussion on what needs done is in the forums. |
| 21:12:47 | funman | linuxstb: I link mkamsboot.c to libucl and have put nrv2e decompressor into a .h file, so I only have to give the dual-boot binary, the rockbox bootloader, and the original firmware in the command line |
| 21:12:58 | kugel | funman: I assume the vast majority of firmware/ and bootloader/ code will be shared |
| 21:13:02 | | Quit bluebrother ("mibbit.com: going home ...") |
| 21:13:11 | Cannoli | alrighty. thanks alot for the help |
| 21:13:17 | amiconn | entropy and predictor need about the same cpu time. Filters are only applied for -c2000 and higher. Not sure about the decorrelation |
| 21:13:17 | funman | kugel: well I only added the clip target, but I can send you the patch and you can add fuze (and e200) |
| 21:13:33 | amiconn | It certainly doesn't need much, but maybe it needs to be considered |
| 21:13:56 | funman | I think I will move mkamsboot.c into rbutil/sansav2patcher and ask the user to specify its model on the command line (make MODEL=CLIP for example) |
| 21:13:57 | kugel | funman: Sure |
| 21:14:23 | linuxstb | funman: I don't think sansav2patcher is a good name - it's a very different process. |
| 21:14:41 | funman | as3525 patcher ? |
| 21:14:45 | linuxstb | Just call it mkamsboot... |
| 21:15:15 | funman | it *patches* an original firmware, with a tiny dual boot program, and the provided rockbox bootloader |
| 21:15:36 | linuxstb | funman: Yes, that's what the mk*boot programs in tools/ does. |
| 21:15:39 | linuxstb | s/does/do/ |
| 21:15:42 | amiconn | Couldn't it be made like ipodpatcher? |
| 21:16:01 | linuxstb | sansapatcher/ipodpatcher actually write to the firmware partition on the disk - that's not visible on the V2 targets |
| 21:16:11 | funman | linuxstb: I trust you: where do I move the code, how do I call it ? |
| 21:16:20 | amiconn | I.e. either take a bootloader file, or have all the various ams bootloaders built in? |
| 21:17:30 | linuxstb | amiconn: The process will be very similar to the iriver h140 and other targets - take an OF firmware file, patch a bootloader into it, copy that new firmware file on the device, the OF then flashes that firmware. |
| 21:17:31 | amiconn | I'm not talking about the actual installatio, but about the method to access the bootloader needed for patching the respective OF |
| 21:17:47 | amiconn | Yes, I understand that |
| 21:18:03 | linuxstb | I guess it will just be like the other mkboot tools - and rbutil can incorporate that feature and download the binaries. |
| 21:18:20 | amiconn | Btw, "and other targets" only applies to the H300 (as of now) |
| 21:18:39 | funman | I use this currently in tools/configure: boottool="$rootdir/tools/mkamsboot /home/fun/m300.bin /media/bordel/test/bootloader/sansav2_dualboot.bin" |
| 21:18:54 | linuxstb | amiconn: The telechips devices will work the same way. |
| 21:19:06 | amiconn | aha |
| 21:19:29 | amiconn | We would need to do the same for iAudio dualboot, but that's not mandatory |
| 21:19:54 | amiconn | iAudio can be flashed even without the OF, as it's done by the flash loader which is always present |
| 21:20:20 | funman | where is the code for iaudio ? |
| 21:20:26 | linuxstb | funman: I don't think you should refer to mkamsboot in the configure script - it's a manual process afterwards, and depends on the user having an OF file |
| 21:20:33 | funman | tools/*iaudio* rbtil/*iaudio* doesn't give anything |
| 21:20:40 | funman | linuxstb: sure, that's just a very crude hack |
| 21:21:05 | linuxstb | Rockbox doesn't dual-boot on iaudio (officially - there's a patch) |
| 21:25:11 | | Join EspeonEefi [0] (i=espeonee@STRATTON-SEVEN-TWENTY-ONE.MIT.EDU) |
| 21:26:07 | * | bertrik wonders what hardware the sansa clip v2 has |
| 21:26:22 | pixelma | Iaudio7 might be a different thing... ;) |
| 21:30:20 | | Join jhulst [0] (n=jhulst@c-71-205-165-118.hsd1.mi.comcast.net) |
| 21:30:39 | linuxstb | bertrik: It's another AS3525 target - the firmware looks the same as other V2 models |
| 21:31:48 | kugel | wait, there's already a clip v2? |
| 21:31:54 | kugel | ;) |
| 21:32:43 | | Part J-23 |
| 21:32:48 | linuxstb | kugel: Yes, the port is obsolete already... |
| 21:39:33 | funman | # |
| 21:39:45 | funman | new clip firmware: "Improved the time to rebuild the metadata" is a lie |
| 21:40:17 | gevaerts | funman: the new time is better. They didn't say anything about shorter |
| 21:40:51 | funman | I only notice a new library block for flac decoder |
| 21:41:16 | kugel | new clip firmware released? |
| 21:41:40 | funman | yes, a new one for v1, as well as the first update for new v2 clip |
| 21:42:09 | bertrik | kugel, see the sandisk forums : http://forums.sandisk.com/sansa/board?board.id=clip |
| 21:42:14 | kugel | linuxstb, bertrik: looks like there's really a clip v2. The sandisk forums mention 2 different hardware revisions |
| 21:42:49 | * | linuxstb wonders if they've added a RAM chip... |
| 21:43:02 | linuxstb | Which would explain the larger (15MB vs 5MB) OF download |
| 21:43:05 | funman | linuxstb: so is rbutil/mkamsboot/ with dualboot and ucl decompressor assembly code suitable for rockbox ? (would take an original firmware and a bootloader as an argument, as well as the specific sansav2 model) |
| 21:44:51 | linuxstb | funman: I agree with the location and the name. I'm still not sure about whether it should have assembly code, but I think it's fine for now. |
| 21:44:58 | funman | the firmware is called m30pa.bin (similar to e200pa.bin for e200v2) |
| 21:45:06 | funman | ok |
| 21:45:44 | | Join Schmogel [0] (n=Miranda@p3EE21A80.dip0.t-ipconnect.de) |
| 21:45:59 | amiconn | linuxstb: Imho the assembly code should be part of the bootloader.bin, which you then feed to mkamsboot together with the OF |
| 21:46:30 | amiconn | For a release it could optionally be built in like in the standalone ipodpatcher |
| 21:47:05 | linuxstb | amiconn: Yes, that's what I've said as well. But I think funman wants to keep it separate for this early development - so he has a tested and reliable "mini-bootloader" which then decompresses and runs a test bootloader. |
| 21:47:19 | | Quit fragilematter ("goin' to windozeland to flash my freakin camera") |
| 21:47:46 | amiconn | Then make it all separate, like the flash loader for archos is |
| 21:49:05 | funman | amiconn: can you point me to the code for archos ? |
| 21:49:39 | amiconn | flash/bootloader is the bootloader code |
| 21:50:08 | funman | I had never opened flash/ :/ |
| 21:50:13 | amiconn | flash/bootbox/ is what bootloader/ is in your case (the main one) |
| 21:50:47 | funman | thanks! |
| 21:51:34 | amiconn | And flash/make_firmware is similar to what mkamsboot does. It doesn't combine with an OF though (at least that's not intended), but it prepares a file for flashing, containing the flash loader and one or two ucl compressed images |
| 21:51:39 | | Join bluebrother [0] (n=dom@rockbox/staff/bluebrother) |
| 21:51:47 | funman | linuxstb: the new firmware's header is 0x24 bytes instead of 0x20 |
| 21:52:07 | | Join fragilematter [0] (i=5c51fc23@gateway/web/ajax/mibbit.com/x-25710c6bee134886) |
| 21:52:13 | amiconn | The second image can be replaced from within rockbox one the thing is first-time flashed |
| 21:52:24 | amiconn | As I said, it's similar but not identical |
| 21:52:59 | amiconn | The combining must be done manually, without help from the build system |
| 21:53:06 | funman | that's fine |
| 21:59:23 | | Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") |
| 22:00 |
| 22:02:11 | | Quit ch4os (Remote closed the connection) |
| 22:03:07 | | Part fragilematter |
| 22:04:50 | | Join ch4os [0] (n=ch4os@unaffiliated/ch4os/x-059673) |
| 22:07:43 | funman | linuxstb: new firmware inserts a new 32 bits word at offset 0x4 |
| 22:08:37 | funman | and replaces 0xffffffff with a checksum(?) at 0x1fc and 0x3fc |
| 22:08:45 | kugel | funman: the firmware format changed? or are you talking aout the clipv2 firmware? |
| 22:09:16 | funman | clipv2 firmware |
| 22:09:29 | funman | new clipv1 firmware format is the same |
| 22:09:33 | | Quit Cannoli ("-= TMD-RecruitServer 5.1=-") |
| 22:09:49 | kugel | phew |
| 22:17:56 | | Quit ender` (" A man without religion is like a fish without a bike.") |
| 22:19:24 | funman | advcomp2019: last time I checked the clips did only go until 4GB so 8GB may be the v2 |
| 22:20:14 | advcomp2019 | there was a silver 4gb clip |
| 22:20:39 | funman | maybe they have a recovery mode |
| 22:21:03 | linuxstb | funman: Hmm, I wonder what that new number it at the end of the two header blocks - it's varies (slightly) in the two headers... |
| 22:22:00 | linuxstb | funman: From looking at the new firmware, do you think the new Clip has more RAM? |
| 22:22:58 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
| 22:22:58 | funman | linuxstb: a 32bit checksum, +1 for the 2nd one ? |
| 22:23:01 | | Quit jeffdameth (Read error: 113 (No route to host)) |
| 22:23:29 | funman | linuxstb: I did not disassembled it yet, I'm busy reading flash/ and concluding that I'll go the way I like, and leave "cleaning" up to you guys ;) |
| 22:23:41 | linuxstb | funman: A checksum of the header block? |
| 22:23:44 | funman | yep |
| 22:24:00 | | Quit meven ("gn") |
| 22:24:01 | funman | 1st one: 1b6317a9 |
| 22:24:10 | funman | 2nd one: 1b6317aa |
| 22:24:20 | funman | I'm 100% sure it's a checksum |
| 22:24:40 | | Join jeffdameth [0] (n=jeff@dyndsl-091-096-052-013.ewe-ip-backbone.de) |
| 22:24:53 | funman | because the contents of the 2 blocks are identical, except the byte at 0x20 & 0x220 (which is 0 in the first and 1 in the 2nd block) |
| 22:25:19 | funman | both firmware block and whole file use simple sum of all 32 bits words |
| 22:25:30 | linuxstb | Yes, that sounds right. |
| 22:25:44 | * | amiconn found another small optimisation for the ape filters on armv6 |
| 22:25:58 | amiconn | Saturation can be done with a single instruction |
| 22:27:44 | | Join midgey [0] (n=tjross@c-68-42-68-108.hsd1.mi.comcast.net) |
| 22:27:53 | bluebrother | Llorean: shouldn't LambdaCalculus get a dev badge on the forums? |
| 22:28:25 | funman | hm there is a pretty big chunk of code in the clipv2 firmware, just after the reset handler |
| 22:30:06 | funman | advcomp2019: http://www.sandisk.com/products/default.aspx?catid=1363 I don't see a 8GB Clip |
| 22:31:32 | pixelma | bluebrother: there are more people with commit rights but "only" expert badge (I'm quite happy with it by the way). Also, I think LambdaCalculus became expert only after getting commit rights |
| 22:31:35 | advcomp2019 | funman, it was on the homepage of abi, but there was a store with 8gb: http://www.materiel.net/search.html?search=sansa+clip&cat=&x=0&y=0 |
| 22:33:19 | pixelma | bluebrother: just stating how it is without any valuation |
| 22:33:41 | | Join fml [0] (n=4fd3f9fb@gateway/web/cgi-irc/labb.contactor.se/x-b30f5860767cb686) |
| 22:34:12 | advcomp2019 | funman, it was a just a rumor so far, but do not know it is real or a mistake tho |
| 22:34:18 | linuxstb | advcomp2019: What do you know about the v2 hardware? Is it looking like all new Clips have this new hardware? |
| 22:34:41 | advcomp2019 | linuxstb, do not know |
| 22:35:34 | funman | linuxstb: right, the new clip has external memory |
| 22:35:56 | fml | Hello. This might have already been asked but I wander why the quite complex ifdef's are used all the time in ata.c. Wouldn't it be better to locally conditionally define a symbol and use it instead? |
| 22:36:03 | advcomp2019 | i have not seen one yet |
| 22:36:21 | Llorean | bluebrother: Traditionally, "people with commit access for documentation work" have gotten the "Expert" badge. I thought that was what he was given commit access for? |
| 22:36:42 | funman | it compares the instruction at #0x8 with "ldr pc, [pc, #0x58]" (the instruction of v1 firmware) and enables the external memory if it's not equal |
| 22:36:46 | Llorean | Sorry, "people given commit access for documentation work" |
| 22:36:55 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 22:38:31 | funman | the v2 firmware modifies the 5 first vectors after initialisation |
| 22:38:33 | linuxstb | fml: ata.c is one of those files that's been hacked by lots of different people over time - so I'm sure it could do with some cleaning. |
| 22:38:47 | pixelma | Llorean: am I not allowed to work on anything else then? ;) |
| 22:39:08 | pixelma | but really I'm wuite happy being an "expert" |
| 22:39:19 | pixelma | quite too |
| 22:39:19 | linuxstb | fml: But what are you talking about in particular? |
| 22:39:20 | fml | linuxstb: I mean the ifdef's in the last commit |
| 22:39:34 | * | linuxstb should keep a closer eye on commits... |
| 22:40:11 | Llorean | pixelma: It's more to help the people identify who's doing what. When you see a "Developer" tag it's supposed to be indicative that this person fairly regularly does (or has) coded for Rockobox. |
| 22:40:11 | bluebrother | Llorean: haven't followed that closely, I just noticed it. |
| 22:40:12 | * | Llorean notes that he doesn't have a Developer badge either. |
| 22:42:06 | pixelma | yeah, I like it that way because I probably couldn't answer questions that are related to real "coding" - some small changes here and there but that's it |
| 22:42:18 | Llorean | That was more or less the idea. :) |
| 22:42:31 | gevaerts | I think this should basically be up to each committer to decide |
| 22:42:56 | bluebrother | good point. |
| 22:42:56 | Llorean | gevaerts: I've been, so far, trying to go based on what was said in the offer for commit access. |
| 22:43:41 | gevaerts | Llorean: well, yes. You (as forum admin) need to make some sort of informed guess of course. |
| 22:43:49 | fml | gevaerts: aha, you're also here! Why did you choose to use rather complex ifdef's multiple times? I assume you did have a good reason to do so what what was it? |
| 22:44:10 | Llorean | gevaerts: I have no objection to shifting people to "Developer" later if they get more involved in that side of the work. |
| 22:44:18 | * | linuxstb also wonders what the difference is between USE_ROCKBOX_USB and HAVE_USBSTACK |
| 22:44:27 | gevaerts | fml: I did have an excellent reason: it's not actually my patch :) |
| 22:44:35 | linuxstb | i.e. when you would define one, but not the other. |
| 22:44:52 | kugel | use_rockbox_usb is going to disappear iirc |
| 22:45:00 | kugel | with a reliable usb code |
| 22:45:10 | gevaerts | linuxstb: simple. HAVE_USBSTACK is always true for software usb targets, and decides whether the basic stack is there |
| 22:45:27 | | Quit Schmogel (Read error: 104 (Connection reset by peer)) |
| 22:45:35 | gevaerts | USE_ROCKBOX_USB is used to decide on whether to reboot on connect or hand over to the rockbox stack |
| 22:45:44 | pixelma | Llorean: my thinking too. By the way... didn't you want to "split" the artist badge group into people who did SVN graphics and ones that did themes? |
| 22:45:46 | | Quit ompaul (Nick collision from services.) |
| 22:46:06 | Llorean | pixelma: Yes. That's kinda waiting on the new theme site though. |
| 22:46:10 | | Join ompaul [0] (n=ompaul@gnewsense/friend/ompaul) |
| 22:46:26 | Llorean | When it comes out, I want to re-set all "Artists" and then give people with themes on the new site a badge relating to being a theme creator. |
| 22:47:08 | funman | At first reset, the 5 first vectors of Clipv2 point to a procedure which enables RAM, and modifies these 5 first vectors to point to another piece of code |
| 22:47:20 | pixelma | ah, didn't remember that there was this dependency. *wondering how long that'll take then* :) |
| 22:47:20 | gevaerts | OK. This usb rework is clearly not bugfree yet... |
| 22:47:54 | fml | gevaerts: ah-he-he! That's really a very good reason! :-) |
| 22:48:11 | advcomp2019 | funman, http://forums.sandisk.com/sansa/board/message?board.id=clip&message.id=10553#M10553 |
| 22:48:15 | linuxstb | funman: That's a bit disappointing - less motivation to squeeze Rockbox into 320KB... |
| 22:48:47 | Llorean | pixelma: I just think that would be the best, and easiest, overall time to do it. |
| 22:48:50 | funman | linuxstb: unless you offer me such a new Clip, I tend to disagree :) |
| 22:49:13 | gevaerts | funman: or two, as the case may be? |
| 22:49:27 | funman | gevaerts: 3, if I don't exchange it at the shop this time |
| 22:49:33 | pixelma | Llorean: probably, and it's not very important. I just remembered that now |
| 22:49:59 | funman | advcomp2019: so it really is a new hardware, but I wonder which new features it has to offer compared to the Clipv1 |
| 22:50:05 | pixelma | (that = this idea) |
| 22:50:05 | bluebrother | speaking of themes −− any news on the new themes site? |
| 22:50:42 | Llorean | funman: If they're not distinguishing them in stores, it's probably not got any new "features" really. |
| 22:51:12 | funman | why adding new memory on the PCB then ? maybe the manufacturer stop selling versions without it ? |
| 22:51:28 | advcomp2019 | funman, i think this is what you want then: http://forums.sandisk.com/sansa/board/message?board.id=clip&message.id=10551#M10551 |
| 22:51:29 | | Join ompaul_ [0] (n=ompaul@gnewsense/friend/ompaul) |
| 22:51:29 | | Join Schmogel [0] (n=Miranda@p3EE21A80.dip0.t-ipconnect.de) |
| 22:51:43 | funman | or maybe these new features are in development and will appear in future releases |
| 22:51:51 | gevaerts | That would be my guess |
| 22:52:07 | | Quit ompaul_ (Read error: 104 (Connection reset by peer)) |
| 22:52:35 | funman | advcomp2019: well it just shows they shipped the hardware with the current "HEAD" of their software, and they waited a bit before releasing it |
| 22:55:42 | | Quit fml ("CGI:IRC") |
| 22:58:16 | | Join setkeh [0] (n=setkeh@CPE-124-181-6-74.vic.bigpond.net.au) |
| 22:59:05 | | Quit bluebrother ("leaving") |
| 23:00 |
| 23:02:25 | amiconn | linuxstb: I am about to commit a demac_iram.h similar to mad_iram.h. Should this have a rockbox header or a libdemac header? |
| 23:05:28 | *** | Saving seen data "./dancer.seen" |
| 23:07:38 | | Join barrywardell [0] (n=barrywar@79.97.87.130) |
| 23:10:17 | linuxstb | amiconn: If it's Rockbox-specific, I would say Rockbox, but I don't feel strongly either way - so whatever you think. |
| 23:17:17 | | Quit hannesd (No route to host) |
| 23:19:36 | funman | anyone with an E200 willing to test potentially bricking (but looking safe in disassembly and emulator) code ? |
| 23:20:03 | Llorean | funman: You mean a v2, I assume? |
| 23:20:18 | funman | yes, sorry for being implicit |
| 23:21:38 | | Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-830cd650811003c9) |
| 23:21:55 | funman | blkhawk: are you still here ? |
| 23:22:03 | | Join webguest54 [0] (n=d572de0b@gateway/web/cgi-irc/labb.contactor.se/x-9a94a4369602c133) |
| 23:22:26 | | Quit webguest54 (Client Quit) |
| 23:23:14 | | Quit bertrik (Remote closed the connection) |
| 23:23:25 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 23:25:20 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 23:29:49 | XavierGr | Llorean: maybe then I should remove the Developer badge that I have. I think it was given to me by you, back in the early days of the forum and you gave that badge to everyone with tracker rights. |
| 23:31:53 | | Quit miepchen^schlaf () |
| 23:33:22 | | Join kushal_12_27_200 [0] (n=kushal@12.169.180.178) |
| 23:36:19 | | Quit jhulst (No route to host) |
| 23:38:00 | | Quit setkeh ("Leaving") |
| 23:39:04 | | Quit midgey () |
| 23:45:28 | | Quit jgarvey ("Leaving") |
| 23:47:36 | | Join nutrientman [0] (n=magnavox@c-69-181-122-127.hsd1.ca.comcast.net) |
| 23:48:42 | nutrientman | i'm having a problem loading my music to an IPOD 3rd gen with rockbox. when its fully charged, it won't allow me to write for more than 10 min straight before the battery gives out. is there a setting that will allow me to charge from a usb cable? |
| 23:50:00 | | Quit kushal_12_27_200 ("Leaving") |
| 23:50:13 | dan_a | nutrientman: Unfortunately the hardware in the 3rd gen only allows charging over firewire. |
| 23:51:22 | dan_a | But there are (or there used to be) cables with both firewire and USB on them, so you can use USB while charging. |
| 23:52:06 | nutrientman | so i can sync with usb and charge with firewire at the same time? |
| 23:52:16 | dan_a | Yes |
| 23:52:26 | nutrientman | good idea, thanks |
| 23:52:45 | dan_a | You're welcome |
| 23:53:08 | nutrientman | have you had experience with writing to the ipod draining the battery very fast |
| 23:53:43 | nutrientman | i thought that the battery time should be the same as long as the drive is spining, read or write |
| 23:54:57 | dan_a | I've not noticed any difference on mine, and can't think of anything obvious which would cause a problem |
| 23:55:07 | dan_a | *cause that problem |
| 23:55:16 | nutrientman | maybe i should buy a battery too |
| 23:56:27 | funman | it may not be related, but I have several problems with my aged laptop battery, including very fast uncharging and kernel crashes |
icon identifies that the person is a core developer (has commit access).