--- Log for 03.10.108 Server: card.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 1 day and 18 hours ago 00.00.06 Quit PaulJam (".") 00.00.07 # ah I see its in the main manual 00.00.10 # markun: The manual should link that. 00.00.12 # sorry main patch 00.00.33 # stop confusing me with your questions 00.00.41 Quit webguest23 ("CGI:IRC (Ping timeout)") 00.01.19 # 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 # the resize_in_core patch, that is 00.02.23 # 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 # i'm semifamilar with rockbox code and I don't even have an idea where it would go 00.04.25 # metadata buffering 00.04.54 # thank you llorean an markun 00.05.06 # the output image should go into the metadata buffer 00.05.49 Quit Munkie () 00.06.36 # 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 # 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 # hi there i have another question. 00.33.10 Join dan_a [0] (n=user@217.23.173.156) 00.33.11 # i can see the music files when i connect my player 00.33.36 # *i cant 00.34.32 # Rockbox doesn't move them. They're wherever you put them originally. 00.34.36 # Dan89: I believe the sansa music dir is hidden 00.35.00 # Llorean: or not? 00.35.20 Join AaronShort [0] (n=c6ec2b02@gateway/web/cgi-irc/labb.contactor.se/x-bc97f55a824f0a92) 00.35.41 # 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 # ii dont know where they are because the installation 00.35.56 # this is not hiden 00.36.00 # i check it 00.36.53 # the music folder disaper 00.36.53 Quit merbzt (Read error: 104 (Connection reset by peer)) 00.37.12 # Dan89: It becomes hidden. 00.37.39 Join kushal_10022008 [0] (i=4596a301@gateway/web/ajax/mibbit.com/x-54acc1d92730644a) 00.37.55 # so how can i fix it? 00.38.05 # 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 # 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 # Dan89: Just set your computer to show hidden files. 00.39.22 # or set rockbox to show hidden folders 00.39.27 # hidden files 00.39.35 Quit jhulst_ (Read error: 113 (No route to host)) 00.39.37 # markun: He's got file view set to all from earlier. 00.39.39 # AaronShort: How are you proposing to deal with the scrollwheel? 00.39.43 # someone left a bit of yellow in the build table, doesn't look important though 00.41.51 # 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 # 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 # 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 # Llorean there is no such option for - show "hidden files" only to single folders 00.45.06 # 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 # 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 # AaronShort: it will never feel right I guess unless you have a scrollwheel on your keyboard :) 00.47.31 # 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 # 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 # kushal_10022008: That doesn't make any sense. 00.48.10 # kushal_10022008: that won't work (for the average user) on windows 00.48.34 # Dan89: the original firmware automatically hides the MUSIC folder. 00.48.42 Quit shotofadds ("Leaving") 00.49.03 # Dan89: What do you mean about "make the whole player not hidden"? 00.49.43 # Dan89: Exactly what are you doing to try and unhide it? 00.49.45 # i mean that i can show folderes inside the player not the whole player 00.49.48 # 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 # Dan89: Is the whole player missing? 00.50.04 # right click on the mouse 00.50.10 # kushal_10022008: Yes, but if you follow either of the official install instructions, you never need to see the .rockbox folder. 00.50.11 # no.. 00.50.27 # only music im think 00.50.39 # 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 # after the right click i can click on "hidden" 00.51.14 # Dan89: What is the mouse pointing to when you right-click? 00.51.18 # but i cant do it on the player, its like a diffrent partition 00.52.18 # about the hardware of the player.. =/ 00.52.27 # 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 # Dan89: http://www.google.com/search?q=windows+explorer+show+hidden+files 00.54.12 # thanks 00.54.24 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 00.55.22 # gevaerts: a bit of yellow in the best bootloader 00.55.30 # 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 # s/best/beast/ 00.56.25 # 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 # 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 # thank you i solve the problem 00.57.35 # does it scroll in a circle or up down? 00.58.05 # well see is why I asked 00.58.14 # n1s: 00.58.24 # hmm.... 00.59.08 # 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 # AaronShort: in a list it wors exactly like up/down 00.59.34 # e200 sim to be precise 00.59.52 # picelma: funny I was just going to suggest something like that 01.01.11 # 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 # only a theory though based on trying to imagine 01.03.32 # 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 # 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 # were not on 01.04.57 *** Saving seen data "./dancer.seen" 01.05.01 # 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 # --background? I havn't tried that yet as I'm just getting up to speed. 01.07.04 # i.e. run "./rockboxui --background" 01.08.29 # oh yea look at that 01.09.05 # I guess 7 and 9 will feel unnatural still in places where the scroll wheel is used for up and down 01.09.20 # yea that looks like that should be the default. i assume there is one of those for every player? 01.09.37 # Yes, every sim has one of those images 01.09.56 # They're in uisimulator/sdl/ in the source 01.10.06 # most devs don't have many diff players and that would make sense... 01.12.02 # 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 # 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 # FS#9428 needs love. 01.53.42 # (or at least attention from someone with commit rights.) 01.55.28 # * LambdaCalculus37 goes to have a peek at FS#9428 01.56.54 # soap: So this is for HWCODEC targets only? 01.57.09 # the changes are for SWCODEC only. 01.57.16 # Ahh, I see it now. 01.57.31 # the bug is that battery_bench's messages assume HWCODEC. 01.58.37 # 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 # you're taking offense at what I consider a pretty safe assumption that battery bench was never updated from its original messaging? 02.00.30 # 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 # 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 # but the _bug_ only affects targets which are SWCODEC, be that coincidence or not. 02.02.20 # what category should I have put it under? 02.03.21 Part toffe82 02.03.53 # 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 # 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 # soap: I'm building with the patch applied. 02.10.53 Quit nuonguy ("Leaving") 02.11.07 # Two messages are changed, one in back-end method, the other in content as well as method. 02.11.36 # 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 # second patch should appear exactly the same, but I consider the method more elegant. 02.13.18 # 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 # linuxstb: The ape filters seem to be memory bound on the beast :\ 02.14.58 # 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 # 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 # powr-toc, read the BuyersGuide wiki page 02.22.03 # 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 # 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 # soap: I'm committing your patch. 02.54.19 # Anyone have any objections? 02.58.34 # * LambdaCalculus37 looks around 03.00.22 Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) 03.02.29 # now you ask at 3AM (+/- 1) in most parts of Europe 03.02.37 # any suggestions on a replacement for chicago12.fnt ? 03.02.56 # 13-Nimbus 03.04.43 # 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 # i trust you :) 03.05.24 # speaking of the Chicago font by the way, not the city ;) 03.05.36 # pixelma: do you know where we got the helvetica font from? 03.06.11 # I couldn't find its free license anywhere on the web. 03.06.31 # no, but it was mentioned here during the renaming process some weeks ago 03.06.44 # and markun knows 03.06.59 # 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 # LambdaCalculus37: you got red! 03.22.28 # and I got yellow :'( 03.22.32 # pixelma what about helvB10 and B12 ? 03.22.33 # (forgot to check before :p ) 03.23.06 # and gevaerts is a naughty bugger also :p 03.23.29 # nm ... im guessing 10-Adobe-Helvetica-Bold.fnt 03.25.05 # 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 # helvR08 become 10-* ? 03.26.13 # does anyone know if the H10 can charge in rockbox? 03.27.30 # 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 # yeah, i'm looking at the fonts README 03.29.08 # 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 # 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 # 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 # Hey everyone 03.55.14 Join Darksair [0] (n=user@221.221.164.210) 03.55.24 # 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 # Mitchell: you can change the source code and recompile it, otherwise no 03.56.58 # the keybindings are fixed for all plugins as far as I know 03.57.02 # I mean I can't close the game at all nor can i turn the game or ipod off 03.57.07 # even when I plug it in 03.57.20 # theres a hardware reset combo on the ipod, try that 03.57.26 # I did 03.57.30 # doom overides it 03.57.38 # no it does not 03.57.44 # it cannot be overridden 03.58.01 # select+ play will not work for me as it usually does though 03.58.11 # the game runs well though 03.59.36 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 04.00.18 # I'm so confused, I thought it couldn't be over rideden either 04.00.25 # 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 # I'll just open it up and pop the battery out 04.03.39 Part JesseL627 04.06.00 # yep guess that means no doom playing for me 04.06.11 # 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 # 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 # how the heck did that break s@#$? 04.45.15 Join blkhawk- [0] (n=blkhawk@f051066054.adsl.alicedsl.de) 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.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 # Hello all 06.13.31 # got a quick one for ya 06.13.56 # how the heck do install rockbox 06.14.02 # i am tryed alot of stuff 06.14.07 # but nothing ;( 06.14.15 # i have unlock iphones before 06.14.25 # its a first gen nano 06.14.28 # 4GB 06.17.32 # VisaNick, you can use the the rockbox utility 06.18.09 # you sure it's a 1st gen nano? If it is, http://www.rockbox.org/twiki/bin/view/Main/RockboxUtility 06.18.13 # plus read the guidelines of the channel, too 06.18.24 # i have the tool 06.18.28 # and running 06.18.29 # it 06.18.32 # but it says nothing 06.18.37 # 0% 06.18.48 # please 06.18.50 # plus do not hit enter 06.18.50 # don't 06.18.57 # use enter as punctuation 06.19.28 # ok, sorry about that.. i am reading just want to make sure theres no quick ideas you have for me 06.19.32 # are you sure it is a 1st gen? 06.20.02 # no 06.20.18 # what color is it? 06.20.36 # pink firmware 1.1.3 4GB 06.20.52 # 1st gen was black and white only IIRC 06.20.54 # then it is a 2nd gen 06.21.06 # nice thanks alot ;) 06.21.16 # 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 # but probably a 2nd gen 06.21.54 # its a nano 06.22.15 # VisaNick, there is 4 gens of nanos 06.22.36 # oh ok, well how can i find out for sure what i have? 06.23.21 # 2nd gen: http://upload.wikimedia.org/wikipedia/commons/b/b2/Nano_omores.jpg 06.23.47 # yes that looks right 06.24.09 # VisaNick, the 1st gen only came in white and black 06.24.10 # 3rd gen was shorter and fatter, 4th gen was taller and thinner 06.24.56 # 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 # 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 # VisaNick: there's nothing you can do, rockbox doesn't support any nano generation except the 1st gen 06.26.06 # well, you could sell it on ebay and buy a 1st gen nano 06.26.46 # 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 # ...well shit! so theres nothing i can do with this huh? 06.27.35 # also, you could try to contribute to a potential 2nd gen nano port 06.27.57 # 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 # lol :) 06.28.21 # Unhelpful: or apple lossless or wav/aiff 06.28.23 # ipod linux ? 06.28.50 # 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 # 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 # 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 # 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 # ameyer: There's a lot of code sharing between the projects. 06.35.03 # 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 # 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 # cool_walking_: The MI4 firmwares are distributed by sandisk. 06.53.30 # Toshiba doesn't actually provide a firmware update we can extract the firmwares from. 06.54.19 # 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 # Shouldn't the rapidshare link to the firmware be removed from GigabeatSInfo then? 06.54.45 # Yes. 06.57.48 # okay done 07.05.06 *** Saving seen data "./dancer.seen" 07.09.49 # Is that "push the black square to reseat the memory" for e200 sufficiently proven to add to SansaE200Unbrick or SansaFAQ? 07.10.52 # 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 # cool_walking_: No, not even remotely 07.13.41 # 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 # 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 # 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 # 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 # 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.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 # 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 # gevaerts: yellow... 08.56.16 Quit BHSPitMonkey (Remote closed the connection) 08.58.10 Quit bertrik (Remote closed the connection) 08.59.12 # amiconn: How much of an improvement did you get with APE? 08.59.22 # gevaerts: call_ata_idle_notifys() is an empty macro in bootloaders 08.59.53 Quit Rob2222 (Read error: 110 (Connection timed out)) 09.01.03 # 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 # amiconn: Hmm... 09.03.56 # 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 # The beast has 16KB IRAM - do we use that? 09.05.11 *** Saving seen data "./dancer.seen" 09.05.17 # don't think so 09.07.01 # 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 # 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 # any suggestions on how to figure out where something gets stuck in an infinite loop? 09.25.53 # 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 # 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 # 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 # 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 # n1s: Does your infinite loop happen on the sim? 09.35.06 # linuxstb: yep 09.35.21 # 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 # well, I'm not very good at gdb... basically know 'r' and 'bt' :) any hints? 09.36.31 # 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 # you can even attach gdb to the running process 09.37.33 # 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 # 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 # (in the sim I mean) 09.47.01 # 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 # 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.01.04 # * n1s seems to have fixed the infinite loop but didn't really figure it out... 10.03.01 # 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 # s/ld/lcd/ 10.04.19 # 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 # 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 # This cast is done to save a comparison 10.08.11 # ...because it will also signal out-of-limit when x is negative 10.08.30 # yes, that's what i thought, Will commit the fix then 10.09.01 # The y1/y2 check must not use this cast, of course 10.09.20 # gevaerts: why do you say that your patch need >500 bytes of ram? 10.12.39 # haha, if i connect usb while in spacerocks the statusbar in the usb screen is green (usually white) :) 10.13.18 # There are a dozen glitches like this wrt status bar in plugins 10.13.45 # Some you'll only see if you use cabbie, others you'll only see when using the old rockbox default colours 10.14.19 # 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 # 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 # n1s: Thanks for fixing my lcd-16bit.c error... 10.20.09 # * linuxstb apologises and seeks forgiveness 10.25.20 # 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 # 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 # maybe the crash has the same reason, just that coldfire gets along with it a tad bit "better"? 10.27.35 # 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 # hmm, someone posted a patch with the same fix in the earlier bugreport... 10.38.49 # anyone with an x5 that can test FS#9220 or should i just close it? 10.41.03 # n1s: just start it and let it run for a while 10.41.07 # n1s: it's considerably more than a week later. :) 10.41.23 # vitja: comparing rockbox-info.txt with and without the patch shows that 10.41.36 # amiconn: spacerocks was removed from 3.0 10.41.51 # gevaerts: i tried that but nothing happened, then played through 4 levels with no problem... 10.42.08 # 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 # 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 # gevaerts: what do you think if request_endpoint will return endpoint with direction, e.g.: 0x81, 0x01? 10.43.22 # 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 # vitja: endpoint numbers are used as indices in arrays, so I'd prefer to avoid this 10.45.05 # gevaerts: we can add handlers for in and out in ep_data, call the right one 10.46.08 # How many endpoints can exist? 10.46.11 # gevaerts: and take ep_data[ep&~0x80].handlers[ep>>7] 10.46.49 # If it's 0..15, why not use bit 4 instead of bit 7 for indicating in/out? 10.47.47 # amiconn: bit 7 is used by the usb protocol, so using that makes things easier. 10.47.56 # ah 10.48.39 # But you could mangle the bit for array indexing 10.48.59 # Btw, did you spot the yellow? 10.49.15 # I did, yes. I'll fix that during my lunch break 10.51.47 # vitja: that would work. Feel free to change it 10.52.07 # aaargh! 10.52.25 # gevaerts: will try tonight 10.52.27 # Damn -m 10.54.21 # 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 # 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.14 Join J-23 [0] (n=aldwulf@a105.net128.okay.pl) 11.00.28 # That said, the optimised vector_*() functions for armv6 are not really faster than the C version, just smaller 11.01.45 # (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 # Seems like the darn build system fooled me :\ 11.17.55 # The speedup is significantly higher than I thought 11.17.57 # The "codec not relinking" bug/ 11.17.58 # ? 11.18.21 # I have even used some 'rm' commands to get around that, but obviously not enough 11.18.45 # So what's the real speedup? 11.18.48 # amiconn: which would explain you previously thinking that it was rather lower than you expected... if i remember you saying that? 11.18.56 # yes 11.19.22 # It seems I measured only part of my optimisations, with other parts using intermediate, experimental stuff 11.20.11 # 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 # Ah, so that will be a different bug, in the libdemac Makefile... 11.21.10 # (maybe...) 11.22.11 # 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 # linuxstb: -c3000 is 309% realtime now 11.24.58 # Now that I know that something went wrong, I'll try reordering stuff again 11.25.31 # 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 # That seems better :) 11.26.48 # * amiconn will know in a minute or so 11.27.08 # you got a gigabeat s, amiconn? :) 11.27.26 # preglow: I couldn't believe it myself :) 11.27.38 # now that i did not see coming :P 11.27.46 # it's got fun dsp instructions, tho 11.27.57 # just stay away from that floating point! 11.28.02 # Could the vector FPU help integer codecs like APE? 11.28.10 # linuxstb: Yeps, -c4000 is 145% realtime :) 11.28.29 # linuxstb: not without compromising the lossless part of everything 11.28.40 # amiconn: I'm curious about "insane" - will it be realtime with the full clock speed...? 11.29.06 # This is using what I committed to svn (just that there's a wrong comment) 11.29.56 # 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 # how well does it compress? 11.34.28 # it sounds kind of unlikely to me they invented something as expensive as monkey's audio 11.34.34 # 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 # which is quite frankly just overkill in its methods 11.35.16 # 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 # he's been delaying that for rather a long while, tho 11.37.47 # 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 # Maybe endors think lossless isn't that important? 11.38.26 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) 11.38.28 # *vendors 11.38.57 # 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 # Yes, it doesn't make sense on small flash-based players anyway, and hard-disk based DAPs are almost non-existent... 11.40.01 # Unhelpful: any idea which rio engineer? (/me knew a lot of them) 11.40.30 # 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 # never mind ;) 11.41.10 # 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 # linuxstb: -c5000 is 40% realtime now. I corrected the numbers at SoundCodecMonkeysAudio 11.42.16 # at0m|c: Rockbox doesn't care where your music is. 11.43.14 # if you use file browser, organize it however you like. if you use database, just make sure your tags are nice. 11.45.14 # Llorean, cheers 11.47.30 # Unhelpful, ye all is properly tagged for Amarok's db 11.48.00 # so will edit the cover script to put all cover.bmp in the right place.. 11.48.30 # gah 11.49.49 # * amiconn should really check quick-fixes 11.50.01 # 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 # 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.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 # 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 # 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 # 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.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 # markun: So do you have any feeling for how the buttons will work on the M6 13.10.46 # M6SL that is 13.11.09 # for the M6SL it's quite logical I think, if we use the strip as 3 different buttons 13.11.39 # does it have obvious candidates for left and right? 13.11.57 # yes, to the left and right of the strip there are the REW and FF buttons 13.13.04 # 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 # so "only" the four directions and "select"? That's one less than the Ondio 13.13.21 # Also, you would have to have delays to see which one the person was actually going to press 13.13.38 # and other than the strip the M3 only has one other button (and hold) 13.13.57 # pixelma: the four directions + select + menu + play/pause 13.14.09 # and there is a hold switch, but I don' 13.14.11 # 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 # 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 # http://www.erenumerique.fr/images/news/20070402/meizu_m3.jpg is an M3, and that is all there is 13.15.18 # 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 # M3: I imagine so, and use select to go forwards 13.16.02 # not too bad even 13.16.03 # Then we will have to have some button that cycles through skip, seek, volume, etc whilst in WPS 13.16.39 # markun: That sounds like the same buttons as the ipods - scroll fwd, scroll back, left, right, select, menu and play/pause, . 13.16.45 # 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 # linuxstb: that's for the M6SL, the M3 has 1 button for forward and back :( 13.17.40 # BigBambi: or maybe use the forward-backward button for that in the WPS 13.17.47 # makes more sense if you ask me 13.18.10 # What's the current state of the meizu ports? Are you running code? Any drivers working? 13.18.13 # 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 # markun: sure, that would work too 13.18.26 # 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 # linuxstb: we're running code, reading the touchpad driver through SPI, toggeling the backlight 13.18.52 # pixelma: Yes, I think it needs an indicator, but I also think it is the only way to do it 13.19.03 # There just aren't enough buttons to do anything else 13.19.05 # we also initialised the LCD, but since it doesn't display anything we're doing something wrong 13.19.22 # BigBambi: possibly 13.19.50 # pixelma: Any other ideas? 13.19.51 # BigBambi, pixelma: we'll get a lot of complaints about people not being able to fish zelda on the M3 :) 13.20.03 # fish -> finish 13.20.22 # BigBambi: no 13.20.22 # markun: Be careful, the SansaV2 ports are catching you up ;) 13.21.03 # 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 # markun: rockboy isn't enabled on the Ondios too due to the lack of buttons... 13.21.40 # and the two scroll pad 'hard buttons' are play/pause and a menu button 13.22.54 # linuxstb: one thing which sucks is that we need runtime detection of the DAC on some of the players :( 13.23.17 # 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 # markun: Hmm, that seemed a good idea at the time... 13.24.04 # I assume meizu does that in their firmware? 13.24.17 # I believe so 13.24.28 # we can change the current names to become function pointers 13.24.55 # yes, and then prefix the existing functions 13.25.03 # exactly 13.25.16 # Does this affect all the meizu players? 13.25.20 # 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 # linuxstb: at least the M3, not sure about the M6SL 13.26.24 # 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 # 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 # meizum3 ;) 13.27.43 # m3 and M3 ;-) 13.27.44 # mei3? 13.27.47 # ;) 13.27.52 # * linuxstb slaps B4gder 13.28.01 Quit {phoenix} (Remote closed the connection) 13.28.30 # Me3 and IM3 13.28.39 # m3a m3b 13.29.08 # Although it's good that Rockbox supports so many players, just the model name isn't enough to uniquely identify one... 13.29.08 # *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 # moos: welcome back :) 13.29.57 # thanks and hi :) 13.30.08 Quit robin0800_ (Remote closed the connection) 13.30.08 Quit robin0800 (Remote closed the connection) 13.30.16 # 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 # markun: You mean LCD controllers? 13.31.50 # yes 13.31.58 # since we don't know where we made a mistake 13.32.15 # if it could display some test image to verify that the init was correct.. 13.34.37 # 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 # 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 # 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 # linuxstb: Understood. 13.45.13 # * amiconn pushed ape performance on armv6 a little further 13.45.37 # 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 # And it does work; I rolled builds for a few of my targets, and they all work properly. 13.49.48 # gevaerts: Have you noticed the yellow your commit caused yesterday? 13.52.26 # 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 # 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 # 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.01.48 # 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 # I wonder what's the best way to move mkamsboot in tools/ 14.08.28 # I see that another tool has pre-built assembly code as a uint32_t array 14.08.29 # gevaerts: did you run some code on the M6SP? 14.08.59 # 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 # 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 # linuxstb: I had to get to work. 14.10.45 # Did you accidentally commit the same patch as before? 14.11.19 # markun: yes, but just backlight toggling 14.11.37 # linuxstb: Yes, just noticed. 14.11.59 # linuxstb: But now I know where to look to fix the problem. 14.12.07 # gevaerts: do you still have the code to read the LCD controller ID? 14.12.08 # now I also notice tools/fwpatcher , is that the prefered location for it ? 14.12.26 # maybe we have more luck with the LCD init this time 14.12.56 # funman: well, sansapatcher and ipodpatcher are in rbutil/, so I guess there's no preferred location 14.13.04 # 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 # markun: that code is still there, and it didn't work on teh sp 14.13.25 # linuxstb: we can use the TARGET define 14.13.27 # LambdaCalculus37: try avoid committing when you're in a hurry :) 14.13.48 # funman: Yes, but I mean the code in tools/ doesn't get compiled in a target-specific way - they are generic. 14.13.56 # oh 14.13.58 Quit GodEater ("http://www.mibbit.com ajax IRC Client") 14.14.10 # well I don't know yet then 14.14.42 # pixelma: I will. Sorry 'bout that. :) 14.15.06 # 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 # do we expect the user to run it manually against its firmware file ? 14.15.28 # linuxstb: Line 219 of apps/plugins/battery_bench.c is what's breaking the Player builds. 14.15.43 # LambdaCalculus37: Yes, because you haven't defined BATTERY_OFF_TXT for the Player. 14.16.04 # in PLAYER_PAD 14.16.25 # 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 # I'm fixing that now, but I can't access svn from work due to no wireless here. 14.16.43 # Can I just post a patch on FS and someone add it to SVN for me? 14.17.05 # Or should I just wait till I'm at a wireless point? 14.17.14 # 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 # gevaerts: found it, never mind 14.18.58 # 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 # 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 # "embed", like in "link" ? 14.20.03 # 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 # funman: Yes. 14.20.12 Quit GodEater (Client Quit) 14.20.21 Quit robin0800 (Remote closed the connection) 14.20.21 # 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 # funman: Do you have a Rockbox bootloader.bin for a V2 target building now? 14.23.35 # yes 14.23.52 # it's done in a rather hasty way 14.24.00 # but at least the reset vector will call main() 14.25.57 # linuxstb, pixelma: I have a fix up at FS#9446. 14.28.03 # 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 # I read "For details, see the Reversed Display Function section" but can't find it in the datasheet 14.28.40 # pixelma: I noticed that, but it doesn't hurt to define it - and may save a future red... 14.29.28 # Could be nice to fix the text so it is used though. 14.29.51 # I agree 14.31.00 # not that this counts much :) 14.31.08 # I managed to build without errors here. 14.31.10 # LambdaCalculus37: Welcome to Rockbox - where a trivial patch can turn into a life's work... 14.31.29 # 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 # 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 # 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 # gevaerts: I tried this, but the screen is still black: http://130.89.160.166/temp/polarity.diff 14.43.06 # 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 # 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 # 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 # How big is a block right now? 14.45.02 # #define BLOCKS_PER_LOOP 4608 14.45.16 # Which means 4608 sample pairs. 14.45.41 # Hmm, if that's *pairs*, it's not good on the beast... 14.45.43 # APE calls a sample pair (or sample, for mono tracks) a "block" 14.46.07 # Data cache is 16KB, and 4608*4 already exceeds that 14.46.19 # It's in codecs/ape.c 14.46.27 # The filter array adds to the caching requirements 14.46.39 # (or array*s*) 14.47.21 Join dabujo [0] (i=xx@p4FDB19DA.dip0.t-ipconnect.de) 14.47.24 # Aren't most of the arrays 32-bit as well - so 4608*8 ? 14.47.45 # decoder.c: lines 35..43 14.48.25 # Ah yes, the history buffers... 14.48.38 # The 'insane' array alone exceeds the cache size :( 14.48.58 Quit Nibbler (Read error: 110 (Connection timed out)) 14.51.59 # Is there a reason for this somewhat strange BLOCKS_PER_LOOP value? 14.52.08 # Why not 4096, or 5000 or such? 14.53.06 # Halving the BLOCKS_PER_LOOP does indeed speed up things 14.53.37 # amiconn: I think there's a logic - it's the default block size in FLAC. 14.53.49 # For PP it would need to be even lower (only 8KB cache) 14.58.56 # Hmm, somehow it only helps the lower compression levels... 14.59.36 # I guess the larger filter histories fill the cache? 15.00.14 # I would've expected -c4000 to see a speedup, but it doesn't 15.00.59 # Also, aren't all the important things in iram on PP, so it wouldn't help there? 15.01.51 # true 15.02.10 # -c1000..-c3000 do see a speedup on the beast 15.02.20 # Do you have numbers? 15.02.39 # -c1000: 539%, -c2000: 410%, -c3000: 318% 15.02.45 # Compare to the wiki 15.03.28 # So tiny, but measurable. 15.04.07 # And -c4000 is the same? 15.04.49 # yes 15.05.16 *** Saving seen data "./dancer.seen" 15.09.12 # 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 # Going down to 1024 blocks per loop speeds things up further, and also makes -c4000 see a bit of speedup 15.11.32 # 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 # amiconn: I thought the filter history was 16-bit, but the samples themselves are 32? 15.11.53 # We can put the code into the bootloader-specific crt0.S, but then we can not compress it 15.11.55 # funman: That depends how you compile it... 15.12.10 # linuxstb, can you explain why my battery bench patch borked the player? It is something I don't fully understand. 15.12.18 # I added it in SOURCES since I saw no target specific files in Makefile 15.12.22 # -c1000: 553%, -c2000: 412%, -c3000: 320%, -c4000: 155% 15.12.29 # soap: You didn't include the correct #define for the Player (in the PLAYER_PAD section) 15.12.49 # linuxstb: nope 15.12.53 # I think I'm gonna put it in crt0.S and hope the bootloader stays under 40kB 15.12.57 # 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 # amiconn: No, the samples are definitely 32 bit... 15.13.35 # or maybe put it in bootloader/bootloader ? :) 15.14.47 # 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 # I thought, linuxstb, that everywhere there was an existing BATTERY_OFF_TXT I changed it. Why was an additional one needed? 15.15.43 # I don't mean to come across as an idiot, but I thought this was a simple substitution fix... 15.15.46 # linuxstb: Maybe I'm a little confused. The vector math functions only see 16 bit data though 15.16.45 # i see there has been some progress on the sansa e200v2 port - anything i can test? 15.17.08 # 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 # blkhawk: nothing yet 15.17.38 # ah - too bad 15.17.51 # i will play with my atmels then :) 15.18.23 # soap: I thought so too, but adding the #defines for BATTERY_OFF_TXT to PLAYER_PAD fixed the issue. 15.18.23 # as far as i know nobody develops drivers for e200 hardware, maybe you can help there? 15.18.25 # linuxstb, ahh, and there was no existing BATTERY_OFF_TXT for player, I get it. 15.18.26 # soap: http://build.rockbox.org/showlog.cgi?date=20081003T123031Z&type=Player%20-%20Normal 15.18.45 # getting playlists to work was all too much of a hassel with the sansa OF 15.19.41 # soap: Linus's Law did indeed come into play here. ;) 15.20.55 # 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 # I didn't pay enough attention to the behavior for non lcd bitmap. 15.21.22 # important lesson 15.21.23 # (not that it'd really matter as it's far from realtime on those...) 15.21.26 # amiconn: There doesn't seem any benefit to that though - I can't imagine insane files ever working... 15.21.34 # (apart from maybe on the S) 15.22.10 # I wonder if the IRAM could be put to better use elsewhere though... 15.22.10 # Yes, but the S profits from less BLOCKS_PER_LOOP (due to better cacheability) 15.22.41 # Hence I wonder whether we should just lower it for all targets (if it doesn't hurt them) 15.26.02 # 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 # soap: r18569? 15.28.39 # linuxstb: Lower BLOCKS_PER_LOOP should also help the gigabeat F and X 15.28.44 # oh, file _name_ 15.29.36 # 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 # I guess I could have it check for any existing battery bench file of the same SVN revision number. 15.31.32 # so that we can finally get those on the download site 15.32.08 # umm s/ipod people/regular people/ ? :) 15.32.09 # 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 # 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 # yea, the problem is I was also thinking about adding the date - which could just be ignored in the check 15.33.45 # Why would you want the date? 15.34.10 # linuxstb: Maybe for logging purposes, e.g. when the bench was run? 15.34.15 # because _I_ do multiple benchmarks and use the average of multiple identical tests. 15.34.49 # but, yes, date is the least important of the information to add. 15.36.38 # 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 # (depending on whether the target has an RTC) 15.37.17 # That makes sense, I didn't even think of looking there for examples. 15.37.50 # create_numbered_filename() in apps/misc.c 15.38.20 # no no no. Stop telling me such things! ;) 15.38.45 # Seems there are two functions - one for all targets (with a number), and one only for RTC targets (for date/time) 15.38.47 # 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 # I was just testing the waters to make sure it wasn't a horrible no-do idea. 15.39.30 # soap: I'm not quite in that league yet. ;) 15.39.36 # It should help the Gigabeat F/X even more since the S3C2440 has no L2 cache 15.40.00 # No takers? 15.40.22 Join midgey [0] (n=tjross@c-68-42-68-108.hsd1.mi.comcast.net) 15.40.24 # amiconn: I can't now, but maybe this evening.... 15.43.30 # 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 # 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 # 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 # amiconn: When I can get to a wireless access point. 15.50.54 # 14.36.28 # 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 # oops too slow :) 15.51.56 Quit midgey () 15.52.44 # LambdaCalculus37: Overlooked that, sorry 15.53.10 Quit petur ("*plop*") 15.53.47 # amiconn: No worries. 15.54.22 # 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 # 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 # hum it's not correct, it prevents the bootloader to be built 16.03.35 # did you consider using automake ? 16.04.04 # * amiconn thinks funman should better not mention automake... 16.04.16 # why ? 16.05.34 # 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 # I know that 16.06.06 # but I don't know of any better solution 16.06.17 # For what? 16.06.39 # building programs 16.06.45 # The current build system works rather well, apart from some minor dependency quirks (things not rebuilt when they should) 16.06.58 # well for me it works rather badly 16.07.06 # But I think these quirks are fixable without introducing an additional system 16.07.17 # maybe I need some hacking before understanding the inners 16.07.28 # adding a dependancy just skips some other 16.07.40 # eh, that's plain makefile 16.07.47 # automake doesn't fix those issues 16.08.06 # at least I understand the Makefiles it does generate 16.08.23 # then you must be special, as a vast amount of people don't - including me 16.08.44 # I may hit a corner case 16.09.03 # the current build system has grown a bit too complicated though 16.09.13 # % make $PWD/bootloader/bootloader.bin 16.09.13 # make: *** No rule to make target `/media/bordel/bootloader/bootloader/bootloader.bin'. Stop. 16.09.44 # and your makefile has a rule for that target? 16.09.58 # I did not delete the rule 16.10.11 # did you create it? 16.10.17 # Making single files never worked for me in rockbox builds 16.10.22 # the full diff is here : http://paste.ubuntu.com/53447/ 16.10.31 # the main makefile has no rule for that file afair 16.10.37 # A simple 'make', or one of the phony targets (bin, rocks) work for me 16.11.09 # the rule is in bootloader/Makefile 16.11.27 # but where did you invoke make? 16.11.33 # in the root 16.11.52 # so then it uses the root Makefile 16.12.31 # which will run make in bootloader/ 16.12.40 # no 16.12.51 # you specified a target on the command line 16.12.53 # don't get me wrong: the build is fine, until I modify it 16.13.17 # only to narrow down the problem 16.13.23 # I can paste the useless full log if you desire 16.13.47 # not now, I have a peek at it tonight 16.13.51 # I can even 16.13.56 # ok 16.15.17 # oh .. I know 16.15.30 # my new target is the first one in the Makefile 16.15.57 # it's fine if I move it after "all:" 16.16.36 Quit n1s () 16.17.24 # B4gder: I wanted to ask you if you can give me the sansav2/as3525 datasheet 16.17.38 # I promise not to re-distribute or publish it 16.17.57 # sure, lemme do that tonight too 16.18.09 # cool, thanks 16.23.27 # 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 # Do you know where this might be used? 16.24.52 # Is that clz as in "count leading zeros" ? 16.24.56 # yes 16.25.08 # amiconn: you can use gcc -S and look for it in the preprocessed source 16.25.11 # Maybe the range codiing, but I can't remember it... 16.25.24 # It's the table used by that function. The function itself must be inlined, because there's nothing visible in .text 16.25.40 # *If* this is used often, it'll especially hurt coldfire 16.26.12 # We should probably roll our own clz() for those armv4 and coldfire 16.27.08 # 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 # 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 # can I invoke the cross compiler in tools/ ? CC is not set and defaults to 'gcc' 16.37.59 # or maybe I should create a precompiled version of the arm thumb nrv2ed8 decompressor since it's unlikely to change 16.38.24 # funman: add it to the tools target 16.38.35 # so that make tools will build it 16.38.59 # 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 # funman: Imho target code shouldn't be in tools/ 16.39.27 # then tools/ isn't suitable, yes 16.39.29 # It should probably be in bootloader/ 16.39.51 # it's needed for the firmware patcher 16.39.52 # linuxstb: Looks like gcc uses __clz_tab for its division routines... 16.40.09 # not for the bootloader 16.40.14 # funman: other firmware patchers aren't in tools either 16.40.33 # But then I don't understand why it includes this for coldfire, which has a 'div' instruction... 16.40.43 # kugel: at least 4 of them are (mk*boot.c) 16.40.59 # they're for host tools 16.41.17 # patching is done on host 16.41.27 # 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 # did that FLOSS interview ever surface somewhere? i can't seem to find the most recent one 16.41.55 # Hmm, 64 bit division... 16.42.03 # preglow: I think it is supposed to pop out tonight US time 16.42.06 # preglow: funny, I just complained in community 16.42.06 # :) 16.42.11 # ah, ok 16.42.15 # hm so I should move mkamsboot.c & the arm code in rbutil/ , not in tools ? 16.42.53 # I'd rather move mkamsboot into rbutil and the arm code in bootloader 16.42.58 # amiconn: Ouch, where does that happen? 16.43.06 # In ape.c itself... 16.43.15 Quit fragilematter ("Leaving.") 16.43.25 # I'd rather move mkamsboot into tools and the arm code in bootloader/ 16.43.27 # Ah, for the elapsed time or similar? 16.43.31 # I think 16.43.47 # right, but this arm code is needed by mkamsboot 16.43.54 # isn't that a problem ? 16.44.10 # I bet ;-) 16.44.47 # 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 # I'd start with putting them all in tools 16.45.04 # 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 # probably a good idea 16.45.28 # 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 # linuxstb: the bootlader.bin needs to be compressed 16.45.55 # Yay, no more red on Players! :) 16.45.56 # hence the decompressing code can not be included 16.46.27 # This 64 bit calculation won't hit decoding performance 16.46.28 # we don't know yet, if it really *must* be compressed 16.46.42 # it can't harm 16.46.46 # at this point it's rather optional 16.46.57 # empty bootloader is already 9.4kB 16.47.02 # 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 # funman: Why can't it? 16.47.36 # amiconn: why could it ? 16.47.45 # Like linuxstb said... 16.48.05 Quit Zagor ("Client exiting") 16.48.33 # It could even be made conditional, like the self-extracting archos binaries 16.49.03 # if (uncompressed_bootloader_too_big()) make_compressed_version(); in the Makefile 16.49.37 # hmm you confuse me too much 16.50.01 # how can we even know if the file is too big in a Makefile ? 16.50.09 # Check the size... 16.50.36 # against what ? the available size is given by a tool ran on the original firmware file 16.51.14 # 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 # funman: can't the make run this tool to check for the size? 16.51.25 # Then run that tool as part of the bootloader build process 16.51.28 # the makefile 16.51.45 # 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 # Otherwise, you need the OF file to build the bootloader... 16.52.52 # Then simply always compress 16.53.00 # that's what we want 16.53.06 # ok :) 16.53.18 # maybe I can do that with $boottool 16.53.58 # bootoutput=rockbox.bin which is the real rockbox bootloader, which doesn't care about dualbooting 16.54.26 # funman: I'm also thinking the dual-boot code should go in there... 16.54.40 # (in crt0.S for bootloader builds) 16.54.56 # I don't like much this idea 16.55.19 # funman: I agree it's less safe for development, but for long-term use, I think it's the right place. 16.55.23 # if we link incorrectly, we may brick the devices 16.57.15 # well I'll continue 16.57.22 # thanks for the input 16.58.44 # can I use sansapatcher with firmware.mi4 newer than firmware I have on my player? 16.59.05 Quit funman ("leaving") 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 # hmm, Rockbox bootloader on my Sansa c240 hangs after "Binary type: RBOS" message 17.09.30 # hah, something not IRAMified that seems to be used often.. 17.09.52 # 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 # I installed new bootloader (SVN) as it's described in rbutil/sansapatcher/README, but it didn't help. 17.11.08 # Do you have a microsdhc card plugged? 17.11.23 # no. 17.11.32 # there are no cards in slot 17.11.45 # Ok, then it's not what I thought 17.12.13 # J-23: The SVN bootloader seems to have a problem. bertrik and gevaerts have such problems too (IIRC) 17.12.45 # linuxstb: I have a nice speedup on coldfire :) (-c1000: 211% -> 253%) 17.13.00 # The rangecoder struct was not in IRAM 17.13.17 # Ah, nice ;) 17.13.19 # That's a tiny struct - just 16 bytes 17.13.37 # 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 # amiconn: do you still need testing on gigabeat F? 17.20.31 # yes 17.20.42 # * gevaerts gets his F60 17.21.14 # Yesterday's build (or so) versus current svn for APE, right? 17.21.23 # No 17.21.34 Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) 17.21.42 # hm, I'm misremembering then 17.22.13 # First check current SVN. Then open apps/codecs/ape.c, change BLOCKS_PER_LOOP to 1024, and test that 17.22.20 # ok 17.22.27 Quit {phoenix} ("Konversation terminated!") 17.23.28 # You can probably leave out -c5000 for the baseline 17.23.48 # ...although it doesn't take *that* long on a gigabeat 17.24.25 # Make sure you delete apps/codecs/ape.* to force a relink (or make clean) 17.24.42 # (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 # 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 # so any theories on why my build server barfs randomly (?) on sim builds? 17.30.48 # soap: have you run memtest86 on it? 17.31.08 # no, I haven't. Why only sim builds, though? 17.31.16 # I can do that in a second. 17.32.38 Part jingjing 17.33.05 # soap: I had that as well when I ran a buildserver. Never got to the bottom of it 17.33.10 # soap: segfaults? 17.33.13 # yes 17.33.30 # Which distro, and cpu? 17.33.56 # ubuntu 8.04 and Xeon (C2D) 17.34.10 # does test codec take activated dsp effects into account? 17.34.45 # kugel: not as far as I know 17.34.51 # soap: Not at all like mine then (Debian and amd xp2800) 17.35.11 # hm, sad :( I'd like to know how much CPU e.g. crossfeed eats 17.35.27 # soap: 64bit? 17.35.30 # no 17.36.31 # kugel, you could monitor boost percentage? 17.36.56 # or I could do a battery bench for you tonight 17.37.30 # Yea, that's what I've done until now. But I'd like to have an exact value 17.37.40 # your choice. I just did four tests on my Nano, no problem to do another one. 17.38.17 # Sure, how could I say no to that offer :) Thanks 17.38.20 # 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 # 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 # You can always do it with non-mp3 17.39.45 Quit faemir (Read error: 104 (Connection reset by peer)) 17.40.13 # Is there a specific reason not to do it with MP3? 17.40.42 # I'm bored. I think I'll just update the CodecPerformaceComparison table for e200 17.40.51 # it's rather old 17.42.01 # 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 # 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 # It just said 21.xMHz 17.42.54 # 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 # on another file though 17.44.48 # 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 # 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 # hddvd is dead 17.57.08 # * gevaerts points to the topic 17.59.24 # kugel: I'm aware 17.59.33 # * ameyer gets back on-topic 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 # 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 # ameyer: please... 18.12.36 # gevaerts: please what? 18.12.56 Quit miepchen^schlaf () 18.14.09 # 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 # 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 # you know what, f this 18.14.47 Part ameyer 18.14.56 # what are some possible causes 18.15.06 Quit midgey () 18.15.24 # i've made sure that the theme's .cfg and .wps files are both Unix formatted instead of Windows 18.15.39 # and I've tried it with both 8 bit and 24 bit bitmap images 18.15.53 # I can upload the files I'm using if that will help 18.16.00 # intrnsic: try running them in the simulator. You should get error messages then 18.16.27 # where's this simulator 18.16.32 # 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 # intrnsic: there are windows simulator builds at http://rasher.dk/rockbox/simulator/. For linux or mac, you'll have to compile yourself 18.17.49 # ty 18.18.42 # Which reminds me that those are horribly out of date 18.18.45 # linuxstb: I know what could be put into the extra IRAM when lowering BLOCKS_PER_LOOP: code... 18.19.08 # This would definitely help PP5002, and also coldfire a bit 18.19.20 # 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 # gevaerts: should be, yes 18.19.49 # 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 # amiconn: http://pastebin.ca/1218156 18.25.33 # Thanks 18.25.44 # Looks like lowering the block size is a good idea 18.26.07 # It doesn't hurt the other targets, and even frees some IRAM on them 18.26.22 # 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 # It may slows things down a bit for c5000, but as long as that's so slow it doesn't count 18.27.16 # According to your results it doesn't 18.27.47 # 0.02% is probably well within measurement accuracy, yes 18.27.57 # -c5000 is practically unaffected because its history buffer alone is too large for the cache 18.28.18 # (S3C2440 has 16KB data cache, as does the I.MX31L) 18.29.50 # linuxstb: Any reason why this shouldn't be changed? 18.30.01 # amiconn: No, I can't think of any. 18.30.38 # 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 # 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 # the line in question is %P|pb.bmp| 18.35.37 # intrnsic: Now read the description of %P on the CustomWPS wiki page 18.35.39 # 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 # i don't see any description of %P 18.38.14 # do I need to rewrite it as %pb? 18.38.42 # 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 # 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 # which corner 18.42.55 # top left 18.43.46 Join Acksaw [0] (n=omgwtfbb@cpc2-stok5-0-0-cust754.bagu.cable.ntl.com) 18.44.04 # ty 18.45.41 Join rniamo [0] (n=rniamo@abo-192-221-68.trs.modulonet.fr) 18.45.44 # hi 18.46.44 # i would like to know if rockbox is compatoble with ipod nano 4G 18.47.09 # It isn't 18.47.25 # (if you mean 4th generation, that is.) 18.47.53 # 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 # 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 # intrnsic: What error is it giving? Did you build the sim yourself, or download it? 18.51.49 # 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 # downloaded it 18.52.05 # windows binary 18.52.07 # intrnsic: Yes. And (0,0) is the top-left pixel, not (1,1) 18.52.11 # 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 # it's giving me a Windows error message, not in the console, for "rockboxui.exe - Bad image" 18.53.06 # "_temp_codec0.dll is not a valid Windows image" 18.53.08 # hello 18.53.27 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.53.35 # 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 # yes 18.54.52 # yes 18.55.01 # That's the problem - you shouldn't do that. 18.55.14 # ok 18.56.18 # 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 # wpyh: HelvR12 was downloaded here: http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html 19.00.27 # ok 19.00.56 # markun: What's the license for them? 19.01.22 # i.e. do they allow distribution of modified versions? I'm assuming they do if they're in Rockbox... 19.02.19 # wpyh: For the benefit of the logs, what are you wanting to do? 19.02.24 # markun: and that's called 15-Adobe-Helvetica now :) 19.03.15 # linuxstb: Helvetica uses a BSD-like license, while WenQuanYi uses the GPL+font-embedding-exception 19.03.52 # 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 # 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 # 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 # Isn't that the advertising clause? 19.06.47 # linuxstb: yeah 19.06.48 # 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 # kugel: e200? And how long is your track? 19.25.12 # the sample track 19.25.22 # 175.x seconds IIRC 19.25.25 # 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 # intrnsic: move that line one up in your wps file 19.26.42 # intrnsic: You just put it onto the first line 19.26.50 # after the image definitions 19.28.04 # the only thing before that, and after the image definitions is %wd 19.28.07 # where should I move that to? 19.28.22 # also does whitespace matter? 19.28.34 # kugel: Expect around 1h 20min for that test, then 19.28.50 # sounds like fun 19.29.47 # 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.02.10 Quit soap (Remote closed the connection) 20.02.32 # amiconn: Would it hurt if ape decoding would yield() sometimes? My sansa is completely unresponsive 20.03.05 # oh, it crashed 20.04.22 # kugel: That's simply because the codec is too slow with insane files. You shouldn't be using them.... 20.04.43 # Well, I know 20.05.11 # I'm testing codec performance (for the CodecPerfomanceComparison page) 20.05.19 # 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 # Afaik you cannot interrupt test_codec 20.10.02 Quit Darksair ("ERC Version 5.3 (IRC client for Emacs)") 20.13.26 # amiconn: Yea, I've noticed that... 20.14.51 Join fragilematter [0] (n=fragilem@92.83.251.216) 20.14.54 # btw, this is the license for helvetica: http://pastebin.ca/1218244 20.16.18 # 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 # 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 # kugel: ah, I was looking for you the other day 20.19.32 # on my ipod nano and ipod video, backlight fading is weird 20.20.05 # well, that's hardware pwm fading 20.20.45 # can we modify the fading to make it more linear? 20.21.09 # possibly not 20.21.17 # hm.. ok... 20.21.29 # I haven't looked into it though 20.21.32 # kugel: the Ondio! :P 20.21.37 # kugel: would you please? :) 20.22.07 # pixelma: your wish is my command :) 20.22.28 # haha, how would you do that? 20.23.01 # the same way I've done it's done on e200/c200 and gigabeat s (at FS#6800) 20.23.22 # basically software fading by looping through the brightness levels 20.23.39 # a) stock Ondios don't have backlight, b) backlight modded Ondios have EL backlighting 20.23.51 # EL? 20.23.57 # there is no backlight brightness 20.24.12 # 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 # kugel: http://www.rockbox.org/twiki/bin/view/Main/OndioBacklight 20.26.42 # 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 # ok 20.27.01 # kugel: The backlight *fading* on ipod Nano and Video is not hardware 20.27.36 # Oh I thought so 20.27.47 # 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 # so, basically what I've done on the beast? 20.28.45 # It's implemented that way in order to get proper fading even at lower brightness levels 20.29.18 # If you only use hw brightness for fading the steps are visible 20.29.50 # amiconn: so it's like software pwm steps between hardware brightness levels? 20.30.03 # no 20.30.16 # amiconn: have you tried my patch already? It's *very smooth*, even on e200 which has only 12 levels at max 20.30.19 # 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 # ok 20.31.29 # 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 # amiconn: ok, then it should be easy to change it... 20.32.14 # The software pwm should probably use a quadratic scale for better appearance 20.32.45 # 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 # 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 # And since backlight power is controlled via GPIO on the ipods and H1x0, this is okay 20.34.11 # amiconn: ah... which explains the problem... 20.34.20 # and what does udelay(10); in backlight-nano_video.c ten? 20.34.25 # I think the backlight fades too quickly at the start 20.34.41 # s/ten/mean then/ 20.34.53 # kugel: This is for brightness setting, not for fading 20.35.15 # And it must be done that way because the brightness controller is pulse controlled 20.36.17 # Check the parts which are ifdefed HAVE_BACKLIGHT_PWM_FADING in backlight.c 20.36.34 # I spotted current_dim and a loop, that's why I thought it's used for fading 20.37.37 # These are necessary to track the current brightness 20.38.12 # 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 # The chip is pulse controlled, and comes up at medium brightness (level 16, the range is 1..32) 20.38.23 # ah ok 20.39.05 # 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 # pulse controlled means that you need to regulary "fire on" the controller to rise the brightness? 20.40.01 # and otherwise it would just go out? 20.40.07 # no 20.40.59 # It works similar to those touch controlled dimmers. 20.41.14 # It keeps the brightness constant, unless you send it some pulses 20.41.48 # Short pulses increase brightness, long pulses decrease it 20.42.02 # ah well 20.42.09 # Looks like a real dimmer chip 20.42.12 # didn't know that 20.42.56 # 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 # And those are just GPIO bit manipulations, switching the LED power (dimmer chip power is on a separate pin) 20.43.59 # aha ok 20.44.24 # (ipod video == ipod nano as far as the backlight circuit is concerned) 20.44.53 # Btw, backlight brightness on Nano is a rockbox first. The OF doesn't offer this 20.45.24 # 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 # kugel: The beast OF is based off of Windows Mobile. 20.46.37 # I know that, but that doesn't tell me about backlight fading :) 20.46.53 # kugel: amiconn didn't say "fading" :) 20.47.09 # oh lol, true 20.47.14 Part fragilematter 20.47.38 # That reminds me - one reason for getting an iPod Color was for looking into its brightness adjustment... 20.47.41 # you read what you want to read ;) 20.48.05 # 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 # scratch the probably 20.49.14 # but yea, I like that too 20.49.19 Join soap [50] (n=soap@rockbox/staff/soap) 20.49.48 # particularly that you deactivate either completely 20.53.27 Quit spiorf (Remote closed the connection) 20.57.46 # looks like there aren't much targets left suitable for backlight fading 20.59.15 Quit m0f0x (Read error: 110 (Connection timed out)) 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 # \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 # 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 # it stays the screen with the progress bar and 2 bars (left and right output) under the progress bar 21.11.40 # linuxstb: Do you have an idea regarding dual core support in ape? 21.11.51 # 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 # today was my first update in months 21.12.27 # 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 # funman: don't make it too clip centric 21.12.30 # 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 # 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 # 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 # 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 # alrighty. thanks alot for the help 21.13.17 # 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 # 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 # It certainly doesn't need much, but maybe it needs to be considered 21.13.56 # 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 # funman: Sure 21.14.23 # funman: I don't think sansav2patcher is a good name - it's a very different process. 21.14.41 # as3525 patcher ? 21.14.45 # Just call it mkamsboot... 21.15.15 # it *patches* an original firmware, with a tiny dual boot program, and the provided rockbox bootloader 21.15.36 # funman: Yes, that's what the mk*boot programs in tools/ does. 21.15.39 # s/does/do/ 21.15.42 # Couldn't it be made like ipodpatcher? 21.16.01 # sansapatcher/ipodpatcher actually write to the firmware partition on the disk - that's not visible on the V2 targets 21.16.11 # linuxstb: I trust you: where do I move the code, how do I call it ? 21.16.20 # I.e. either take a bootloader file, or have all the various ams bootloaders built in? 21.17.30 # 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 # 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 # Yes, I understand that 21.18.03 # I guess it will just be like the other mkboot tools - and rbutil can incorporate that feature and download the binaries. 21.18.20 # Btw, "and other targets" only applies to the H300 (as of now) 21.18.39 # 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 # amiconn: The telechips devices will work the same way. 21.19.06 # aha 21.19.29 # We would need to do the same for iAudio dualboot, but that's not mandatory 21.19.54 # iAudio can be flashed even without the OF, as it's done by the flash loader which is always present 21.20.20 # where is the code for iaudio ? 21.20.26 # 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 # tools/*iaudio* rbtil/*iaudio* doesn't give anything 21.20.40 # linuxstb: sure, that's just a very crude hack 21.21.05 # 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 # 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 # bertrik: It's another AS3525 target - the firmware looks the same as other V2 models 21.31.48 # wait, there's already a clip v2? 21.31.54 # ;) 21.32.43 Part J-23 21.32.48 # kugel: Yes, the port is obsolete already... 21.39.33 # # 21.39.45 # new clip firmware: "Improved the time to rebuild the metadata" is a lie 21.40.17 # funman: the new time is better. They didn't say anything about shorter 21.40.51 # I only notice a new library block for flac decoder 21.41.16 # new clip firmware released? 21.41.40 # yes, a new one for v1, as well as the first update for new v2 clip 21.42.09 # kugel, see the sandisk forums : http://forums.sandisk.com/sansa/board?board.id=clip 21.42.14 # 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 # Which would explain the larger (15MB vs 5MB) OF download 21.43.05 # 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 # 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 # the firmware is called m30pa.bin (similar to e200pa.bin for e200v2) 21.45.06 # ok 21.45.44 Join Schmogel [0] (n=Miranda@p3EE21A80.dip0.t-ipconnect.de) 21.45.59 # 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 # For a release it could optionally be built in like in the standalone ipodpatcher 21.47.05 # 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 # Then make it all separate, like the flash loader for archos is 21.49.05 # amiconn: can you point me to the code for archos ? 21.49.39 # flash/bootloader is the bootloader code 21.50.08 # I had never opened flash/ :/ 21.50.13 # flash/bootbox/ is what bootloader/ is in your case (the main one) 21.50.47 # thanks! 21.51.34 # 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 # 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 # The second image can be replaced from within rockbox one the thing is first-time flashed 21.52.24 # As I said, it's similar but not identical 21.52.59 # The combining must be done manually, without help from the build system 21.53.06 # that's fine 21.59.23 Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") 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 # linuxstb: new firmware inserts a new 32 bits word at offset 0x4 22.08.37 # and replaces 0xffffffff with a checksum(?) at 0x1fc and 0x3fc 22.08.45 # funman: the firmware format changed? or are you talking aout the clipv2 firmware? 22.09.16 # clipv2 firmware 22.09.29 # new clipv1 firmware format is the same 22.09.33 Quit Cannoli ("-= TMD-RecruitServer 5.1=-") 22.09.49 # phew 22.17.56 Quit ender` (" A man without religion is like a fish without a bike.") 22.19.24 # advcomp2019: last time I checked the clips did only go until 4GB so 8GB may be the v2 22.20.14 # there was a silver 4gb clip 22.20.39 # maybe they have a recovery mode 22.21.03 # 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 # 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 # linuxstb: a 32bit checksum, +1 for the 2nd one ? 22.23.01 Quit jeffdameth (Read error: 113 (No route to host)) 22.23.29 # 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 # funman: A checksum of the header block? 22.23.44 # yep 22.24.00 Quit meven ("gn") 22.24.01 # 1st one: 1b6317a9 22.24.10 # 2nd one: 1b6317aa 22.24.20 # 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 # 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 # both firmware block and whole file use simple sum of all 32 bits words 22.25.30 # Yes, that sounds right. 22.25.44 # * amiconn found another small optimisation for the ape filters on armv6 22.25.58 # 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 # Llorean: shouldn't LambdaCalculus get a dev badge on the forums? 22.28.25 # hm there is a pretty big chunk of code in the clipv2 firmware, just after the reset handler 22.30.06 # advcomp2019: http://www.sandisk.com/products/default.aspx?catid=1363 I don't see a 8GB Clip 22.31.32 # 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 # 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 # 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 # funman, it was a just a rumor so far, but do not know it is real or a mistake tho 22.34.18 # advcomp2019: What do you know about the v2 hardware? Is it looking like all new Clips have this new hardware? 22.34.41 # linuxstb, do not know 22.35.34 # linuxstb: right, the new clip has external memory 22.35.56 # 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 # i have not seen one yet 22.36.21 # 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 # 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 # Sorry, "people given commit access for documentation work" 22.36.55 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 22.38.31 # the v2 firmware modifies the 5 first vectors after initialisation 22.38.33 # 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 # Llorean: am I not allowed to work on anything else then? ;) 22.39.08 # but really I'm wuite happy being an "expert" 22.39.19 # quite too 22.39.19 # fml: But what are you talking about in particular? 22.39.20 # linuxstb: I mean the ifdef's in the last commit 22.39.34 # * linuxstb should keep a closer eye on commits... 22.40.11 # 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 # 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 # 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 # That was more or less the idea. :) 22.42.31 # I think this should basically be up to each committer to decide 22.42.56 # good point. 22.42.56 # gevaerts: I've been, so far, trying to go based on what was said in the offer for commit access. 22.43.41 # Llorean: well, yes. You (as forum admin) need to make some sort of informed guess of course. 22.43.49 # 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 # 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 # fml: I did have an excellent reason: it's not actually my patch :) 22.44.35 # i.e. when you would define one, but not the other. 22.44.52 # use_rockbox_usb is going to disappear iirc 22.45.00 # with a reliable usb code 22.45.10 # 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 # USE_ROCKBOX_USB is used to decide on whether to reboot on connect or hand over to the rockbox stack 22.45.44 # 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 # 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 # 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 # 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 # ah, didn't remember that there was this dependency. *wondering how long that'll take then* :) 22.47.20 # OK. This usb rework is clearly not bugfree yet... 22.47.54 # gevaerts: ah-he-he! That's really a very good reason! :-) 22.48.11 # funman, http://forums.sandisk.com/sansa/board/message?board.id=clip&message.id=10553#M10553 22.48.15 # funman: That's a bit disappointing - less motivation to squeeze Rockbox into 320KB... 22.48.47 # pixelma: I just think that would be the best, and easiest, overall time to do it. 22.48.50 # linuxstb: unless you offer me such a new Clip, I tend to disagree :) 22.49.13 # funman: or two, as the case may be? 22.49.27 # gevaerts: 3, if I don't exchange it at the shop this time 22.49.33 # Llorean: probably, and it's not very important. I just remembered that now 22.49.59 # 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 # (that = this idea) 22.50.05 # speaking of themes -- any news on the new themes site? 22.50.42 # funman: If they're not distinguishing them in stores, it's probably not got any new "features" really. 22.51.12 # why adding new memory on the PCB then ? maybe the manufacturer stop selling versions without it ? 22.51.28 # 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 # or maybe these new features are in development and will appear in future releases 22.51.51 # That would be my guess 22.52.07 Quit ompaul_ (Read error: 104 (Connection reset by peer)) 22.52.35 # 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.02.25 # 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 # 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 # anyone with an E200 willing to test potentially bricking (but looking safe in disassembly and emulator) code ? 23.20.03 # funman: You mean a v2, I assume? 23.20.18 # yes, sorry for being implicit 23.21.38 Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-830cd650811003c9) 23.21.55 # 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 # 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 # 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 # nutrientman: Unfortunately the hardware in the 3rd gen only allows charging over firewire. 23.51.22 # 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 # so i can sync with usb and charge with firewire at the same time? 23.52.16 # Yes 23.52.26 # good idea, thanks 23.52.45 # You're welcome 23.53.08 # have you had experience with writing to the ipod draining the battery very fast 23.53.43 # i thought that the battery time should be the same as long as the drive is spining, read or write 23.54.57 # I've not noticed any difference on mine, and can't think of anything obvious which would cause a problem 23.55.07 # *cause that problem 23.55.16 # maybe i should buy a battery too 23.56.27 # it may not be related, but I have several problems with my aged laptop battery, including very fast uncharging and kernel crashes