--- Log for 18.06.110 Server: hubbard.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 2 days and 5 hours ago 00.01.11 Quit voRia (Ping timeout: 258 seconds) 00.03.16 # * domonoky1 sees FS#11414 and looks at app/metadata/mod.c and sees a comment: /* Copy Title as artist */ so thats intended behavior.. but why ? 00.03.29 # preglow: ping ? 00.03.46 # does preglow exist anymore or is that just a data ghost? 00.05.19 # so should we change that so that a mod title is actually the title in metadata and not the artist ? 00.05.35 *** Saving seen data "./dancer.seen" 00.08.43 # does it even have an artist field? 00.08.52 # domonoky1: the comment seems weird. if it wasn't there I'd say "sure go ahead" 00.10.57 Quit jgarvey (Quit: Leaving) 00.12.15 # New commit by 03alle (r26901): Do not produce additional space after 'to the picture above' 00.12.16 # ummm...just see if it works? :) 00.13.02 Quit simabeis (Ping timeout: 252 seconds) 00.13.20 Join voRia [0] (~voria@ppp-192-65.98-62.inwind.it) 00.14.11 # r26901 build result: All green 00.14.56 # iriver_flash.c doesn't look safe to use. It introduces delays by simple C busy loop. The story with D2 shows this is not the way to go. 00.15.00 # domonoky1: from the description of the mod file format I found, only the title can be stored. So putting the title in the artist field seems rather bizarre 00.15.44 # wodz: I think there are such loops everything. I recently saw once in something as2525 related 00.15.49 # *everywhere 00.15.54 # I think we can make the amsv2s quite easily run at 248 MHz too, just like the sansa ams players, I'll try it out now 00.16.36 # pamaury: This doesn't mean it is safe :-) 00.16.59 # bertrik: wouldn't that be a bit off too? 00.17.17 # yes, but already a lot better 00.18.08 # why not try out the 243MHz suggestion from saratoga first? 00.18.27 # I don't see why 00.18.33 # well if both give low error, might as well use the amsv1 settings 00.19.13 # bertrik: lower error? 00.19.33 # i meant closer to 44100 hz 00.20.08 # haha, the comments about busyloop timing are the same in rockbox_flash.c and iriver_flash.c. I bet running time of the loop *IS* different on sh and coldfire 00.21.12 # 240 MHz gives 1.1% error, 243 MHz gives 0.11%, 248 MHz gives 0.15% error 00.21.55 # The change from 240 to 248 is quite simple, just adjust the multiplier from 60 to 62 00.22.31 # then might as well do that and get this fixed 00.25.24 # bertrik: 61 as multiplier would work as well I guess 00.25.43 # but 0.15% is quite good already 00.26.11 # I have been happy with the v1 sound quality, so doing the same on v2 can't be bad :) 00.26.53 Join halmi [0] (~netbook@80-123-43-32.adsl.highway.telekom.at) 00.26.59 # the oscillator probably isn't much more stable anyway, so no sense worrying about it 00.28.49 # are you sure? I heard that even the cheapest oscillators manage 10^-4+ % 00.29.05 # Well, xtals do 00.29.08 Quit halmi_ (Ping timeout: 248 seconds) 00.30.18 Quit bmbl (Quit: Bye!) 00.30.42 # Even cheaper RC oscillators are less precise, but those aren't used for CPU clocking in our targets. They are used for stuff like LCD controller clock though 00.31.26 Quit scorche (Disconnected by services) 00.31.36 Join scorche` [0] (~scorche@rockbox/administrator/scorche) 00.32.12 # amiconn: have You explored the idea of using EMAC unit in phases calculation? 00.32.26 # Yes, I tested it 00.32.43 # It's not worth the hassle (dealing with EMAC state saving) 00.33.15 # Speedup at 124MHz is immeasurable; at 45MHz it reduces ISR load from 37% to 35% (measured on H1x0) 00.34.26 # I intend to fiddle a bit with the HD200 asm soon though (using more line accesses and arranging lcd controller writes so that stalls are avoided) 00.35.32 # nice 00.35.47 Quit pamaury (Remote host closed the connection) 00.36.03 # what do You think about spline interpolation in test_grey ? 00.36.12 # Regarding fs #11413, I'll maybe try it tomorrow 00.36.41 # I can't say much regarding the actual mathematic and assume you did it correctly if I get reasonable results 00.36.50 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 00.37.22 # Other than that it'll hopefully still fit on archos 00.38.00 Quit Highlander (Quit: Quitte) 00.41.30 # amiconn: Memmory cost should not be that much - 2 arrays of 16 ints each, 1 array 17 ints, 3 ints for coefficients ~108 bytes of ram usage more 00.44.15 # Plus code 00.44.32 # yes 00.44.33 Part captainewkllllll 00.46.48 # it can be a bit smaller at cost of lower computation efficiency (but I don't know if this matter) 00.47.52 # I don't know either without testing - the plugin allocates the greylib buffer dynamically, so the .map file doesn't tell whether it'll actually work 00.55.07 Quit t0rc (Quit: Leaving) 00.55.50 # hmm at least one 16 ints array and 3 variables with coefficients can be saved 00.57.13 Quit bertrik (Quit: De groeten) 00.57.25 Quit wodz (Quit: Leaving) 01.01.19 Quit kugel (Remote host closed the connection) 01.03.28 Join evilnick_BS [0] (620ec24b@rockbox/staff/evilnick) 01.10.44 Join webguest67 [0] (www-data@giant.haxx.se) 01.11.11 Part toffe82 01.12.23 # hi, I am looking for some help regarding the 'new' eabi compiler 01.13.07 Quit bluebrother (Disconnected by services) 01.13.11 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 01.13.31 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 01.14.04 # I am unsure how to set things up, i have found various things talking about re-running /tools/rockboxdev.sh, however I am unsure how to go about doing that 01.14.33 Quit domonoky1 (Read error: Connection reset by peer) 01.14.43 # I am using cygwin and set things up according to the instructions in the wiki if that helps 01.15.20 Quit rob (Read error: Connection reset by peer) 01.15.38 Join rob [0] (~nnscript@adsl-76-235-215-255.dsl.klmzmi.sbcglobal.net) 01.17.11 Quit BradC (Read error: Connection reset by peer) 01.19.04 Quit webguest67 (Quit: CGI:IRC (EOF)) 01.20.34 Quit voRia (Quit: Leaving.) 01.26.53 Quit halmi (Read error: Connection reset by peer) 01.32.08 Quit evilnick_BS (Ping timeout: 252 seconds) 01.45.43 Join BradC [0] (heh23794@202-89-178-44.static.dsl.amnet.net.au) 01.48.44 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 01.49.18 Quit efyx (Remote host closed the connection) 01.50.11 Quit BradC (Read error: Connection reset by peer) 01.50.54 Join BradC [0] (heh24665@202-89-178-44.static.dsl.amnet.net.au) 02.01.34 Quit BradC (Read error: Connection reset by peer) 02.05.37 *** Saving seen data "./dancer.seen" 02.18.33 Quit DerPapst (Quit: Leaving.) 02.29.44 Join BradC [0] (heh30602@202-89-178-44.static.dsl.amnet.net.au) 02.47.34 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 03.04.02 Quit Xerion (Ping timeout: 240 seconds) 03.05.40 Quit linuxguy3 (Read error: Operation timed out) 03.21.58 # bieber: where do you get the settings list from? 03.35.04 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 03.41.37 # JdGordon: From the .cfg file: they're loaded when you "Open Project" 03.44.29 Quit steve|m (Ping timeout: 276 seconds) 03.44.36 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 03.44.52 # bieber: sorry, no, I meant the list of possible config options 03.44.54 # in the drop down 03.47.26 # New commit by 03funman (r26902): usb-drv-as3525: build with LOGF_ENABLE undefined 03.47.31 # New commit by 03funman (r26903): usb-drv-as3525: use udelay() and not a C busy loop ... 03.47.36 # New commit by 03funman (r26904): sd-as3525: enable writing, sd_enable() and card_get_info_target() in bootloader ... 03.47.41 # New commit by 03funman (r26905): as3525: bootloader USB mode ... 03.49.10 # There's a file in /resources, I think I called it "configkeys", that it loads from 03.49.18 # r26902 build result: All green 03.49.21 # I got the keys from an appendix in the RB manual someone pointed me to 03.49.55 # The file is just plaintext, one key per line, with a - for the separator between more common and less common keys (which I've kind of arbitrarily decided for now) 03.50.46 # OK, just a bit worried that is just another thing which will eventually get outdated 03.51.02 # r26905 build result: All green 03.51.40 # Hmm 03.52.01 # It's easy enough to edit, I'm not sure how you could automate it. Is there a list somewhere in the RB sources of valid keys? If so, I'm sure I could just load that 03.52.24 # no, there isnt 03.52.34 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 03.52.34 # same problem with the manual though 03.52.58 # At least they're also text edit boxes, so you can always enter any key you want, if it comes down to it 03.53.06 # ok 03.53.45 # btw, the backdrop image isn't for WPS, is it? I think I botched that earlier today 03.54.43 # the backdrop worlks like this:... if one is set in the config then any skill will use it unless either the skin has the %X() tag (so it loads a seperate bmp) or %X(d) which uses no backdrop 03.55.05 # Oh, okay 03.55.12 # And in the absence of a backdrop, just use the background color? 03.55.19 # yes 03.55.26 # Cool 03.55.45 # I'm going to start working on viewports tonight, hopefully I'll have at least some rudimentary display of them by tomorrow morning 03.58.17 Join steve|m [0] (~steve@p4FD47C98.dip.t-dialin.net) 04.05.23 Quit elcan (Read error: Connection reset by peer) 04.05.38 *** Saving seen data "./dancer.seen" 04.05.38 Join elcan [0] (user36@pr0.us) 04.16.32 Join Barahir_ [0] (~jonathan@frnk-590f521e.pool.mediaWays.net) 04.19.44 Quit Barahir (Ping timeout: 240 seconds) 04.23.36 Quit crculver (Quit: Leaving) 04.24.25 Join linuxguy3 [0] (~timj@adsl-75-57-168-7.dsl.emhril.sbcglobal.net) 04.25.33 Quit BradC (Ping timeout: 264 seconds) 04.37.10 Quit pixelma (Disconnected by services) 04.37.10 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.37.11 Quit amiconn (Disconnected by services) 04.37.14 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.37.22 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.37.31 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.38.29 Join binaryhermit [0] (~binaryher@adsl-75-63-51-213.dsl.emhril.sbcglobal.net) 05.00.18 Quit TheSeven (Ping timeout: 260 seconds) 05.04.13 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 05.09.49 Nick scorche` is now known as scorche (~scorche@rockbox/administrator/scorche) 05.10.20 # New commit by 03jethead71 (r26906): For multiprocessor targets, do the thread_exit routine such that we don't need to rely on the compiler's good graces to have stack switching be ... 05.11.59 # r26906 build result: All green 05.22.22 Join DerPapst [0] (~Alexander@p4FE8EDC9.dip.t-dialin.net) 05.30.35 Quit Horscht (Quit: Verlassend) 05.37.35 Quit jordan` (Ping timeout: 265 seconds) 05.40.00 Join hebz0rl [0] (~hebz0rl@dslb-088-065-061-076.pools.arcor-ip.net) 05.50.57 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 05.52.00 Join kramer3d_ [0] (~kramer@unaffiliated/kramer3d) 06.02.57 Quit DerPapst (Ping timeout: 240 seconds) 06.05.41 *** Saving seen data "./dancer.seen" 06.15.18 Join BHSPitMini [0] (~BHSPitMon@tx-76-6-68-177.dhcp.embarqhsd.net) 06.22.34 # hmm 06.22.53 # my FuzeV1 flickers (screen and wheel) when coming back from hold 06.23.15 # svn from about 5 days ago, r26834 06.23.39 # * Dhraakellian doesn't remember when it started 06.23.49 Join DerPapst [0] (~Alexander@p4FE8EDC9.dip.t-dialin.net) 06.23.56 # * Dhraakellian goes to update, glance at the bugtracker, hope it's not a hardware issue 06.40.10 Quit anewuser (Quit: for SELL 2 by the price of 1 now!) 06.45.46 Quit JdGordon (Quit: Leaving.) 06.54.29 Quit jhMikeS (Ping timeout: 240 seconds) 06.55.51 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 06.55.57 # New commit by 03ranma (r26907): Move usb-drv-as3525 defines into header file 06.57.44 # r26907 build result: All green 07.05.17 # oh, and I got 15h5 play time when I tested my new (refurb) clip+ 07.05.34 # Bruckner symphony cycle in q6 Ogg Vorbis set to repeat 07.07.02 # New commit by 03ranma (r26908): Avoid ifdefs 07.07.12 # hold on most of the time, minimal interaction 07.07.32 # iirc, that's better than my FuzeV1 gets, but I haven't checked it in a while 07.08.13 Quit kramer3d_ (Read error: Connection reset by peer) 07.08.33 Join kramer3d_ [0] (~kramer@unaffiliated/kramer3d) 07.08.34 # r26908 build result: 25 errors, 79 warnings (ranma committed) 07.09.00 Join kramer3d__ [0] (~kramer@ip98-169-198-182.dc.dc.cox.net) 07.12.25 Quit kramer3d (Ping timeout: 272 seconds) 07.12.36 Quit binaryhermit (Quit: Leaving) 07.22.25 Join stooo [0] (~sto@g230133053.adsl.alicedsl.de) 07.22.41 Part stooo 07.28.44 Nick kramer3d__ is now known as kramer3d (~kramer@ip98-169-198-182.dc.dc.cox.net) 07.38.10 Quit BHSPitMini (Ping timeout: 264 seconds) 07.38.38 Join Buschel [0] (~~andree@p54A3EA75.dip.t-dialin.net) 07.43.03 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 07.47.46 Quit kramer3d (Quit: Leaving) 07.53.42 Quit DerPapst (Read error: Connection reset by peer) 07.54.08 Join DerPapst [0] (~Alexander@p4FE8EDC9.dip.t-dialin.net) 08.05.44 *** Saving seen data "./dancer.seen" 08.09.55 Join LinusN [0] (linus@rockbox/developer/LinusN) 08.11.03 Quit Buschel (Ping timeout: 260 seconds) 08.22.10 Join ender` [0] (krneki@foo.eternallybored.org) 08.30.32 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 08.32.26 Quit hebz0rl (Ping timeout: 265 seconds) 08.35.06 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 08.35.58 Quit TheSeven (Ping timeout: 240 seconds) 08.37.15 Join Zagor [0] (bjst@rockbox/developer/Zagor) 08.47.18 Join flydutch [0] (~flydutch@host110-154-dynamic.14-87-r.retail.telecomitalia.it) 08.48.18 Join B4gder [0] (~daniel@rockbox/developer/bagder) 08.54.59 # New commit by 03jethead71 (r26909): Squeeze down the PP5002 cache routines a bit. 08.56.46 # r26909 build result: 3 errors, 0 warnings (jethead71 committed) 08.56.52 # JdGordon: Question about viewports, if you're here 08.57.50 # We have the last two parameters as ints in the tag table, but don't we need a string for RGB colors? 08.58.33 # wow, strange error 09.01.16 # well the sansafuzev2 port built successfully 09.01.37 # svn up\nAt revision 26909. 09.01.53 Join Rob2222 [0] (~Miranda@p4FDCB707.dip.t-dialin.net) 09.02.31 Join hebz0rl [0] (~hebz0rl@dslb-088-065-061-076.pools.arcor-ip.net) 09.05.55 Quit Rob2223 (Ping timeout: 252 seconds) 09.14.58 Join petur [0] (~petur@rockbox/developer/petur) 09.17.39 # Igor Poretsky looks like a capable guy 09.17.46 # (http://poretsky.homelinux.net/rockbox/) 09.20.07 # wow, decent list of patches applied 09.20.30 Join pondlife [0] (~Steve@rockbox/developer/pondlife) 09.20.38 # and a pile of his own stuff too. and everything very tidy and orderly. 09.21.15 # I'm sending him a mail inviting him to join the list and irc. 09.22.28 # good idea 09.23.25 # the mail by Sergei says that somehow "he is not able to subscribe to the list" 09.23.43 # yeah, I don't know what that means. I'll just ask. 09.26.23 Quit bertrik (Quit: De groeten) 09.28.06 Quit pondlife (Quit: Leaving.) 09.36.12 Join CGL [0] (~CGL@190.207.202.226) 09.36.40 Join Kitr88 [0] (~Kitar_st@BSN-182-25-28.dial-up.dsl.siol.net) 09.38.41 Join swilde [0] (~wilde@aktaia.intevation.org) 09.39.28 Quit Kitar|st (Ping timeout: 248 seconds) 09.40.50 Quit Kitr88 (Ping timeout: 240 seconds) 09.41.29 Quit leavittx (Ping timeout: 258 seconds) 09.42.48 Quit DerPapst (Quit: Leaving.) 09.45.20 Join Kitar|st [0] (Kitar_st@BSN-142-72-111.dial-up.dsl.siol.net) 09.49.13 Join pyro_maniac_ [0] (foobar@p57BB9CE2.dip0.t-ipconnect.de) 09.52.15 Quit pyro_maniac (Ping timeout: 240 seconds) 09.53.13 Join wodz [0] (~wodz@skatol.ch.pw.edu.pl) 09.54.38 Join mitk [0] (~mitk@195.117.162.130) 09.56.26 Quit liar (Ping timeout: 258 seconds) 09.58.07 Quit hebz0rl (Ping timeout: 265 seconds) 09.59.44 Join Rob2223 [0] (~Miranda@p4FDCBBDE.dip.t-dialin.net) 10.01.52 Quit linuxguy3 (Ping timeout: 245 seconds) 10.02.54 Join Buschel [0] (~~andree@p54A3B671.dip.t-dialin.net) 10.03.26 Quit Rob2222 (Ping timeout: 272 seconds) 10.03.28 Join kugel [0] (~kugel@rockbox/developer/kugel) 10.03.46 Join linuxguy3 [0] (~timj@adsl-75-57-168-7.dsl.emhril.sbcglobal.net) 10.04.43 Join leavittx [0] (~leavittx@89.221.199.187) 10.05.45 *** Saving seen data "./dancer.seen" 10.19.56 Quit CGL (Remote host closed the connection) 10.31.17 # what happened about 3.6.1 for fuzev1? 10.32.15 Quit Buschel (Ping timeout: 240 seconds) 10.32.27 Join BradC [0] (heh4817@202-89-178-44.static.dsl.amnet.net.au) 10.41.25 Join stoffel [0] (~quassel@p57B4D69A.dip.t-dialin.net) 10.45.40 Join DerPapst [0] (~Alexander@p5099d40e.dip0.t-ipconnect.de) 10.49.34 Nick pyro_maniac_ is now known as pyro_maniac (foobar@p57BB9CE2.dip0.t-ipconnect.de) 10.51.41 Join wpspb [0] (www-data@giant.haxx.se) 10.54.09 # I want to use %pb without a image, which is the correct syntax ?; 1) %pb||x|y|width|height| or 2) %pb|x|y|width|height| 10.54.54 # neither 10.55.25 # %pb(x,y,width,height) 10.55.49 # thanks 10.56.01 # (well, for the new skin syntax) 10.56.29 # if you're using 3.6 or lower, then %pb|x|y|width|height| will do the trick 10.57.11 # oh...actually. no. 10.57.20 # I forgot what I was talking about. 10.57.37 # I have time :-) 10.57.39 # If you just want to use the inbuild playbar, then just use %pb 10.57.42 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 10.57.45 # %pb|image.bmp|x|y|width|height| or plain %pb for the inbuild peakmeter, no? 10.58.21 # kugel: Yep, I just remembered that mayself. (playbar btw, not peakmeter) 10.58.31 # %pb|-|x|y|width|height| *might* work, but I don't know. if not you need to fiddle with viewports for resizing the peakmeter 10.58.38 # err, playback, right 10.58.46 # *bar ;) 10.58.51 # GRR 10.58.52 # yes %pb without a image 10.59.05 # sweet, than just use %pb 10.59.24 # as in literally, just "%pb" no other parameters 11.00.09 # so, how does it know where to place itself, or is that defined by it's position in the list 11.00.58 # put it in a viewport. 11.01.26 # *gives Saint his best blank look* 11.01.48 # callibrating greylib is tricky :-/ 11.03.25 # IIRC, the inbuilt playbars height is defined by the height of the font used. 11.04.06 # and, if your WPS isn't using viewports, then it is positioned by the line it corresponds to in the WPS 11.04.33 # but, you really *should* be using viewports. 11.05.05 # wpspb: http://www.rockbox.org/wiki/Main/CustomWPS 11.05.26 # that link will tell you what you need to know about viewports, and anything WPS related. 11.06.00 # there is also this: http://www.rockbox.org/wiki/Main/SimpleGuideToWPSMaking 11.06.24 # wpspb: ^ 11.07.59 # aha. Viewports is way out of my league. i use a _extremely_ simple three line wps, 'cause as a non coder it's time consuming trying to figure out where the tiny syntax change is that breaks the thing 11.08.05 # for info these two pages weren't very informative on thsi subject, i.e. %pb without a image http://www.rockbox.org/wiki/CustomWPS#File_Info ; and; http://www.rockbox.org/wiki/SimpleGuideToWPSMaking 11.09.10 # then just put a %pb into the wps somewhere and it'll show somewhere :) 11.09.35 # that's perfect. thanks 11.09.44 # * pixelma already wondered if CustomWPS had been updated to the new syntax 11.09.52 # doesn't look like it 11.09.56 # yes, as I said earlier...if you're not using viewports then the position is defined by the line it corresponds to in the WPS code. 11.11.04 # if you put %pb as the first line of the WPS, it will be on the top line, if you put it on the second line, then it'll be on the second "line" in the WPS and so on. 11.11.41 # by the way, I still can't follow why colour is not a viewport parameter but separate 11.11.46 # now 11.11.55 # a "line" is defined by the font height. for example, if your font is 10px high, and the players screen is 100px high, then there are 10 "lines" on the screen. 11.12.45 # pixelma: Niether can I really...but I think it boils down to the fact that the colour *can* change, or, *could* change rather. 11.13.03 # There's no reason it needs to be permanantly defined by the viewport. 11.13.27 # I think the intention is to be able to make the FG/BG colours conditional? 11.13.47 # you could win me over if that makes it simpler to have inverse draw mode, i.e. white on black on monochrome more easily 11.14.13 # I think this is possible with the new parser. 11.14.22 # But don't quote me on it ;) 11.15.23 # wpspb: Did you see my description of line placement for non viewport WPS' above? 11.15.54 # *looks 11.16.32 # yes thanks, nice info, it would be nice to hve that in the wiki 11.16.58 # I believe it is...but, not using viewports is generally frowned upon. 11.17.19 # just call me simple 11.17.31 # * S_a_i_n_t_ calls wpspb simple 11.17.34 # \0/ 11.18.14 # :-) 11.18.33 # Using viewports makes it less likely that doing something as simple as changing the font doesn't completely break the alignment of the theme. 11.19.16 # an example being if you have the playbar as the very bottom line, and then change the font height, it will almost definitely be pushed off the screen. 11.22.10 # wpspb: The manual for your player also has a nice description of WPS code in it. 11.23.01 # since when is not using viewports "frowned upon"? 11.23.51 # I understand that there are advantages to the advancements in the wps, but call me old fashioned or simple, but as a non coder I really enjoy the simplicity of a three line wps, complex syntax changes and concept changes are almost impossible for me to relsove. On my H140 simple is good Artist, Title %pb, Album, that's it 11.24.08 # well, it's just...ugly. especially for the reason I mentioned regarding font change vs. alignment. 11.24.46 # pixelma: ^ 11.24.57 # I don't change font at all, nimbus 12 rules :-) 11.25.22 # wpspb: The syntax change actually makes the WPS code easier to read. 11.25.35 # (and write) 11.26.23 # yes but code IS a language and as in any language the nuances are only appreciated by those who know how to speak it 11.26.29 # But, as you said if you're just using a three line WPS...then you probably don't really care much :D 11.27.09 # If you break it down into sections...then WPS code really is very simple. 11.27.09 # that sums it up quite nicely :-) 11.27.16 # S_a_i_n_t_: that sounds more like your opinion. Purely text based WPS are at least a bit more flexible 11.27.54 # pixelma: Until you change the font height... 11.28.14 # then bits start magically dissappearing off the screen. 11.29.02 Join n1s [0] (~n1s@90-230-78-242-no134.tbcn.telia.com) 11.29.03 Quit n1s (Changing host) 11.29.03 Join n1s [0] (~n1s@rockbox/developer/n1s) 11.29.09 # Even if a WPS is simple text, it should still use viewports if it is supported by the target. 11.29.20 # depends how much space you have left. And the same problem would exist with viewports too, even making it worse 11.29.27 # Even if it is solely for that reason. (font change) 11.30.55 # with viewports (if used correctly) changing the font height will just lose some text. Not push the playbar or whatever off the screen. 11.31.07 # the placement of other items will still remain the same. 11.32.50 # S_a_i_n_t_: Viewports are great and all, but I don't recall not using them being frowned on 11.33.04 # This all sounds like your opinion :) 11.34.16 # IIRC text will completely disappear in a viewport if it would exceed its limits 11.34.22 # When I first showed up here...I got a semi-lecture from Jd about "the beauty of viewports, and why not using then is bad", and after looking into it, I happen to agree. 11.35.22 # pixelma: How do you mean "completely dissappear"? If it can't draw a full line, it wont. But it will draw all the full lines it can. 11.35.49 Join dfkt [0] (dfkt@unaffiliated/dfkt) 11.36.50 # S_a_i_n_t_: if the height of the viewport is less than the font height 11.36.53 # where's the difference to not using viewports then? If you do use them, they are usually smaller than fullscreen, so things will start disappearing earlier 11.37.40 # S_a_i_n_t_: Sure, they are great, but there isn't a position on it. You just seemed to come across a bit strong 11.37.45 # or just differently 11.38.16 Quit kugel (Ping timeout: 260 seconds) 11.38.54 # There isn't a hould use viewports about it - if they aren't needed, then great 11.38.59 # *should 11.40.03 # * S_a_i_n_t_ wishes JdGordon were here to chime in... 11.40.25 # Why? 11.40.35 # The talk I was given when I first showed up equated to "drawing in the default viewport is evil" 11.40.53 # yeah, maybe I'm more annoyed that it came across as speaking for everyone here 11.40.56 # I fully agree that viewports are great, and the only way to do it if you want any sort of proper control over position 11.41.23 # And in most circumstances they should be used, yes imo 11.41.38 # But you can't speak for everyone 11.42.18 # I didn't...I understand how it was percieved that way, and I do wish I worded it differently now, but its down to perception. 11.42.40 # And it isn't a big deal either :) 11.42.49 # No, it isn't ;) 11.42.52 Join Highlander [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) 11.44.26 # IMO, WPSs without using viewports (or just the default viewport) still have some advantages depending on what you want and should still be "supported". If you start using viewports, drawing in the default viewport is another thing if it causes complication (in the code or for screen updates etc.) 11.45.32 # Heh...well, as we found out last night that's not even supposed to work ;) 11.45.52 # we did? 11.45.54 # (drawing in the default viewport whilst another viewport is specified) 11.46.26 # I ploted lcdlinear matrix for various targets -> http://www.rockbox.org/wiki/GreylibCalibration this at least shows what should one expect :-) 11.46.34 # And yeah, we did. 11.51.16 Join hebz0rl [0] (~hebz0rl@dslb-088-065-061-076.pools.arcor-ip.net) 11.55.14 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 11.58.03 Join Piggz [0] (~Piggz@nat65.mia.three.co.uk) 11.58.24 Quit wpspb (Quit: CGI:IRC) 11.59.22 # hi...a quick question, my ipod 5gen video, even after a restore, just shows the apple logo on startup. So I installed Rockbox and it works fine, any idea why? 12.02.18 # apple logo comes for early bootloader which is not touched with standard installation method 12.03.21 Join watto [0] (~watto@193.203.81.165) 12.03.32 # Piggz: Do you mean that when you try to boot the Apple firmware, it just shows that Apple logo, and nothing more? 12.03.42 # (ie. doesn't finish booting) 12.05.24 # when I put it into disk mode, and used itunes to restore it, it reboots and sticks at the apple logo....so I put it in disk mode again, installed Rockbox, and it loads Rockbox ok..... 12.05.38 Join simabeis [0] (~simabeis@lobmenschen.de) 12.05.46 *** Saving seen data "./dancer.seen" 12.05.52 # If I then do do boot trick to load the apple fw with the hold button, it doesn't boot 12.09.19 # That is quite odd... 12.09.31 # At least it can still boot Rockbox ;) 12.09.53 Part watto 12.14.23 # yes :) I got it from ebay as faulty...didn't cost much, so I'm happy Rockbox runs on it 12.26.14 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.30.00 Join robin0800 [0] (~quassel@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 12.34.35 # What is this "bootloader usb mode" that funman committed ? 12.42.11 Part LinusN 12.43.01 # usb mode in the bootloader? 12.44.09 # pamaury: AFAICS he changed the bootloader so that it will load the usb_storage driver if usb is connected while the bootloader starts up 12.44.20 # Why ? 12.44.34 # Don't ask me, I was kind of wondering too :) 12.47.06 # BTW usb storage reads work, but on writes I get a panic, because the driver tries to receive dma a packet from the host, when rockbox hasn't called recv() yet. :/ 12.47.50 # In theory I think setting NAK on the EP should prevent that, but for some reason it happens anyway... 12.53.36 # I have the complementary problem on clip+, whatever I do, the usb phy doesn't trigger an interrupt on setup packet :( 12.54.08 Quit petur (Quit: *plop*) 12.54.44 Quit robin0800 (Remote host closed the connection) 12.58.10 Join DerPapst1 [0] (~Alexander@dslb-088-069-158-170.pools.arcor-ip.net) 12.58.46 Quit stoffel (Ping timeout: 265 seconds) 13.00.10 Quit DerPapst (Ping timeout: 240 seconds) 13.01.31 # pamaury: BTW, did you have a look at drivers/usb/gadget/s3c-hsotg.c? I read yesterday on lwn that's also a DesignWare part. Register names seem to match Clip+ 13.01.51 # (arch/arm/plat-samsung/include/plat/regs-usb-hsotg.h) 13.03.32 # No, I already have the linux patch so I basically know all the registers. I'll have a look at it but currently I'm stuck and I don't know why it doesn't work. 13.07.03 # The linux patch usb_otg_if.c doesn't seem to implement packet recv/transmit AFAICS on a quick glance though :) 13.08.19 # Compared to that the official s3c-hsotg.c driver should be quite working (used in then OpenMoko mobile phone) 13.10.09 # And since it's part of the normal vanilla Linux kernel it's GPL of course 13.10.40 Join dfkt|x [0] (~dfkt@chello062178002170.1.11.univie.teleweb.at) 13.10.40 Quit dfkt|x (Changing host) 13.10.41 Join dfkt|x [0] (~dfkt@unaffiliated/dfkt) 13.17.33 Join jordan` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net) 13.18.03 Quit dfkt|x (Remote host closed the connection) 13.22.08 Join teru [0] (~teru@M016207.ppp.dion.ne.jp) 13.26.48 Quit B4gder (Quit: It is time to say moo) 13.41.47 # ranma: usb_otg_if.c is the init code, the rest of the driver is in drivers/usb/gadget and it's quite big :) 13.42.19 Join watto [0] (~watto@193.203.81.165) 13.58.28 # New commit by 03wodz (r26910): HD200 - calibrate lcdlinear[] matrix 14.00.16 # r26910 build result: All green 14.01.12 Quit hebz0rl (Ping timeout: 276 seconds) 14.05.50 *** Saving seen data "./dancer.seen" 14.08.16 Join grawity [0] (grawity@94.23.20.44) 14.14.50 Join robin0800 [0] (~quassel@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 14.18.34 # Is there a way to remove some characters from a .fnt, and only keep ASCII? (It takes a long time to load a .wps with 3 fonts...) 14.19.38 Quit wodz (Quit: Leaving) 14.21.37 Join petur [0] (~petur@rockbox/developer/petur) 14.28.34 # New commit by 03mcuelenaere (r26911): Lua: make actions.lua, buttons.lua and rocklib_aux.c depend on it generators 14.28.36 # New commit by 03mcuelenaere (r26912): Lua: document rocklib_aux.pl a bit, so it's easier to find out about it when stumbling over a CC error in rocklib_aux.c 14.29.12 Quit robin0800 (Remote host closed the connection) 14.30.20 # r26911 build result: All green 14.30.55 # grawity: http://svn.rockbox.org/viewvc.cgi/trunk/fonts/README?revision=18390&view=markup&pathrev=26910 Take a look at point 4. 14.31.42 # r26912 build result: All green 14.34.53 # mitk: I see... however, in this case, one font is only used for numbers; would it not be possible to have two copies (full and ASCII)? It's mostly for my personal use, anyway. 14.36.34 Join ender1 [0] (krneki@foo.eternallybored.org) 14.38.20 # grawity: For personal use: Edit *.bdf file in trunk/fonts directory with FontForge, compile rockbox and you will get custom build with your custom fonts. 14.39.59 Quit ender` (Ping timeout: 276 seconds) 14.41.01 # gravity: IIRC font with numbers only is used to display frequency on FM screen for targets with really big displays. 14.42.13 # Well, it is used differently here. 14.42.19 # http://i.imgur.com/SsXzd.png - time and playlist position 14.44.29 # gravity: I sad IIRC ;) 14.45.26 # * grawity tries to make a nicer volume indicator 14.47.19 Join funman [0] (~fun@rockbox/developer/funman) 14.49.01 # ranma, pamaury: USB in bootloader can be helpful if the filesystem is corrupted / .rockbox is absent 14.50.04 # but it makes the bootloader much more complicated... 14.50.30 # some other targets do it, but I don't understand how mass storage works at all here, i think these bootloaders haven't been tested in some time 14.50.36 # why? 14.51.22 # ranma: i could write an empty file yesterday but copying rockbox.sansa didn't succeed 14.51.36 # You have to include the whole usb stack 14.51.55 # Which is not simple piece of software 14.52.05 # funman: Got the BNA panic I expect? 14.52.23 # screen was off 14.52.35 # pamaury: well the code is there already 14.52.37 # mitk: the font which only contained numbers was taken back first (and then made into a more complete font) 14.53.07 # funman: Anything against calling _backlight_on() in system_exception_wait() 14.53.08 # and it's not used anywhere by default yet 14.53.13 # now i just need to see why the disk isn't reported correctly 14.53.15 # pixelma: 35-Nimbus? 14.53.47 # ranma: yes we talked about this with amiconn: backlight can be more complex than just setting a GPIO pin 14.54.10 Quit bieber (Ping timeout: 260 seconds) 14.54.13 # mitk: yes, IIRC 14.54.42 # also we would need to enable the LCD again 14.54.51 # if it works on all sansa ams why not 14.55.43 # pixelma: Thanks. Btw IIRC is lifesaving abbreviation ;) 14.55.47 # afaiu, all bootloaders using USB (but AMS) will report a device with 0 interfaces 14.56.11 # Augh. "*PANIC* Stkov usb" when trying to use the screendump feature. 14.56.25 # I'm not aware of any bootloader other than gigabeat S that uses the rockbox USB stack 14.56.37 # Well on C200v2 at least it works. _backlight_on() already calls lcd_enable() for C200v2 at least 14.56.57 # grawity: on which target ? I thought it was fixed... 14.56.59 Quit Piggz (Ping timeout: 240 seconds) 14.57.18 # pamaury: ipodnano2g, yesterday's build 14.58.03 # probably a sector buffer hanging around on the stack 14.58.21 # iriver h1x0, iriver h300, mrobe500, mpiohd200 14.58.23 Join DannyA [0] (www-data@giant.haxx.se) 14.59.05 Join detaos_ [0] (~quassel@ip72-218-104-242.hr.hr.cox.net) 14.59.05 # see? :) 14.59.19 Quit detaos (Ping timeout: 240 seconds) 14.59.36 # mrobe500 uses the rockbox USB stack, but it boots from the OF, so I doubt if anyone has ever tried USB from the bootloader 14.59.47 # the other three use a bridge chip 15.00.37 # isn't it the gigabeat *F* which uses usb ? 15.00.47 # also a bridge chip 15.01.17 # gigabeat S uses USB from the bootloader mainly because it 15.01.21 # Greetings. My server is a Rockbox build client. It was working OK until yesterday, but now I just get "Your build client has been temporarily blocked by the administrators due to: has weird issues. Please go to #rockbox to enable your client again." Does anyone have any ideas? 15.01.24 # 's needed for a reasonably easy install 15.02.45 # DannyA: it failed all builds submitted to it 15.03.11 # Have you tried a manual build in the build client's checkout? 15.04.36 # ranma: just curious: what's wrong with ifdefs ? (we already use and abuse them a lot in rockbox) 15.05.28 # It makes the code less easy to read if there ifdefs within a function 15.05.38 # gevaerts: it's also very handy if you manage to break rockbox since the OF isn't helpful when you just want to transfer some files :) 15.06.03 # n1s: I'd consider that to be the same case as installing actually :) 15.08.33 Quit kramer3d_ (Ping timeout: 245 seconds) 15.10.16 # New commit by 03funman (r26913): FS#11347 by me: *dir LUA functions: luadir module ... 15.10.30 # funman: If the bootloader is uncached, making invalidate_dcache() and friends noops in the bootloader would also be a nice solution IMHO (and require neither ifs nor ifdefs in the usb-drv-as3525 code) 15.11.04 # perhaps we should just enable MMU in the bootloader 15.11.47 # we'll need a new release for all AMSv1 when USB works so now is a good time to make bootloader changes 15.12.08 # r26913 build result: All green 15.12.45 Quit petur (Quit: *plop*) 15.14.54 Join pyro_maniac_ [0] (foobar@p57BB9CE2.dip0.t-ipconnect.de) 15.15.34 Quit pyro_maniac (Read error: Connection reset by peer) 15.18.47 # ranma: btw udelay(1000) works fine on c200v2 ? (different timer settings) 15.19.04 # Seems to work fine 15.19.52 # mitk: the Ondio build you once provided - which gcc version was that made with? (As my impression was that the ajbrec.ajz was bigger for no apparent reason) 15.20.41 # pamaury: D2 works with eabi ? 15.20.45 # gevaerts: The builds directory is empty. Does that look right? 15.21.08 # DannyA: that bit is probably right 15.21.27 # So how do I do a manual build? 15.21.43 # the way you do any build 15.21.50 # funman: I think so. I didn't try the commit made by Rob but I tried a similar one I wrote and it worked. I didn't try the plugins hozever, perhaps some of them are broken 15.21.55 # Make a directory (or use builds/), run configure, and run make 15.22.32 Quit pyro_maniac_ (Remote host closed the connection) 15.23.08 # pixelma: IIRC ;) host gcc was 4.4.3. Do you still have this build? rockbox-info.txt was included in it. 15.25.19 # I know, but I don't have it anymore. Host gcc doesn't matter for target builds, just for sims IIRC ;) . The gcc-sh (or however it is called exactly) is important 15.26.07 # gevaerts: In fact many targets with usb-storage bridge do bootloader usb 15.26.55 # mitk: Did you build your toolchains using rockboxdev.sh? 15.27.01 # pixelma: then it was gcc version used these days for standard builds. 15.27.10 # If not, your sh-elf-gcc might be unpatched, which is a bad thing 15.27.46 # pixelma: yes. version was 4.0.sth 15.28.50 # gevaerts: D'Oh! Now I realise what was wrong... I reinstalled Linux, but 32bit instead of 64bit. So the Rockbox tools no longer worked. I emptied the tools directory and restored it from svn. Seems to be working now. 15.30.27 # New commit by 03funman (r26914): Sansa AMS: fix bootloader USB mode 15.31.06 # New commit by 03gevaerts (r26915): re-allow frederico-dannya 15.31.21 # DannyA: great! We'll see after the next build :) 15.31.27 # Thank you 15.31.59 # r26914 build result: All green 15.33.25 # New commit by 03teru (r26916): use int instead of enum. 15.34.11 # fuzev1 bootloader with usb: 104kB too large for IRAM (same number with thumb + -Os?) 15.35.01 # r26916 build result: All green 15.35.12 # ah no, 104kB with thumb/Os, 116kB with arm/O 15.37.22 # pixelma: Ooops! I sad 4.0.sth, former version for arm targets. But I'm sure it was version used for Ondio these days 15.38.09 # heh, inserting the charger cancels a yes/no question, i guess it counts as abuttonpress 15.39.56 Quit Highlander (Quit: Quitte) 15.40.57 Join evilnick_B [0] (0c140464@rockbox/staff/evilnick) 15.43.03 # do we need full unicode support in bootloader? 15.43.13 # funman: How about this: http://pastebin.com/JNqVn5St 15.44.30 # looks good 15.45.27 # New commit by 03ranma (r26917): Enable display and backlight on panic. 15.47.39 # New commit by 03nls (r26918): libmad: Optimize away 2 instructions from coldfire III_imdct, no measurable speed difference. 15.49.38 # New commit by 03teru (r26919): reorder apps/plugins/lib/SOURCES. 15.51.22 # r26919 build result: All green 15.52.57 # r26918 build result: All green 15.56.28 # huh? out-of-order build results 15.57.23 Quit Strife89 (Quit: Reboot to Windows.) 15.58.07 Quit mitk (Quit: Leaving) 15.58.31 # and r26917 hasn't been announced (and had some red in it) 15.59.28 # 917 was aborted due to dropped network connection 16.00.43 # the server actually did run 919 before 918. the question is why/how... 16.01.40 Quit guymann (Quit: brb guys) 16.01.58 # HAL is taking over! 16.05.45 Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) 16.05.48 # i think it feels it hasn't gotten enough attention lately 16.05.53 *** Saving seen data "./dancer.seen" 16.06.00 # ahh, now I see it 16.06.14 # http://pastie.org/1010089 < bss of fuzev1 bootloader sorted by size 16.07.18 # 918 was committed before 917 was done, thus putting 918 in the "next build" slot. but then 917 was aborted due to all clients being disconnected. and when the clients came back 919 was committed, which triggered a new round for 919. and once 919 was done, the server looked in the "next build" slot and started 918... 16.08.06 # not the most common case perhaps :) 16.08.22 # no :) 16.08.38 # funman: is the codepage thing used in the bootloader? 16.09.50 # i think not 16.10.21 # ah it comes from unicode.c 16.10.50 # i think not supporting unicode in the bootloader would be fine 16.10.58 Quit Dark_Rak3r (Ping timeout: 258 seconds) 16.11.04 # but fat code uses it so it needs some tweaking 16.11.09 # aha 16.11.32 # Zagor: What happened to the occasional wrong build assignment? 16.11.43 # New commit by 03ranma (r26920): C200v2 lcd controller still gets stuck sometimes, do a full controller init in lcd_enable() 16.11.46 # fat doesn't support unicode but it supports a lot of iso encodings 16.12.01 # amiconn: which wrong build assignment? 16.12.03 # vfat is *always* ucs-2 16.12.18 # what's vfat? 16.12.28 # if you mean the wrong packaging then that was fixed 16.12.35 Join Strife89 [0] (~Strife89@adsl-80-197-231.mcn.bellsouth.net) 16.12.39 # funman: long filename support on fat 16.13.03 # i think we don't need lcd scrolling either 16.13.11 # r26920 build result: All green 16.13.31 # funman: Some things are included in the bootloaders in order to avoid too much ifdefing 16.14.09 # that means there is some things which can be removed then 16.14.28 # The question is whether they should be removed 16.14.46 # we must look at each thing one by one 16.15.36 # the player's codepage_table buffer is only 640 entries long while it's 32k entries for bitmap targets so you should just be able to shrink the buffer 16.15.40 # hm supposedly the bootloader only needs to look at '.rockbox' + the ascii filename of the rockbox file 16.15.46 # (or OF) 16.16.23 # The bootloader does need unicode support in order to decode ucs-2 16.17.00 Join Dark_Rak3r [0] (~DarkRak3r@cpe-67-244-88-91.nyc.res.rr.com) 16.17.34 # There is no such thing as an ascii filename 16.17.46 # amiconn: but that works on the player with the small buffer, no? 16.17.51 # vfat is UTF-16, not UCS-2. 16.18.22 # UTF-16 and UCS-2 is the same except the former also supports characters outside the BMP 16.18.37 # But rockbox does only support the BMP, so it's essentially the same 16.19.05 # New commit by 03zagor (r26921): Cumulative commit of various build server changes. 16.19.47 # scrolling is ~40kB 16.20.18 # grawity: UCS-2 is older than UTF16 iirc, it has been superseeded by UTF16 but still, this is the one used in FAT 16.20.46 # Huh? The whole bootloader is little more than that... 16.21.05 # should I use #ifndef BOOTLOADER or put a #define HAVE_LCD_SCROLL in lcd.h ? 16.21.17 # amiconn: bss is large 16.22.36 # Hmm, I think the udelay(1000) in usb-drv-as3525.c is likely to run into panicf("%s(): %d too high!", __func__, usecs) for very low backlight brightness 16.23.01 # ranma: perhaps we could extend udelay to support arbitrary high argument 16.23.36 # With my current brightness level I haven't seen any problems, but with the lowest on the low BGLOAD value should be about 210us 16.23.47 # Didn't know you were talking about ram usage. 16.23.51 # s@lowest on@lowest level@ 16.24.02 # Does that matter on some target(s)? 16.24.19 # amiconn: fuzev1 384kB of iram is full when enabling USB 16.24.29 # 105kB or so overflow 16.24.38 # mostly due to the 128kB USB storage buffer 16.24.59 # funman: You can also reduce the usb storage buffer I think 16.25.07 # sure but that's too easy! 16.25.17 # *g* 16.25.34 # and afaiu it could impact USB performance (but we need to test it at some point) 16.25.58 # Will Rockbox have some kind of "sleep" mode like the original iPod firmware does? (Rockbox does boot a lot faster, but still not instant.) 16.26.03 Join guymann [0] (~charlie@69.0.83.229) 16.27.29 # funman: but usb speed is maybe not the most important thinng in the bootloader ;) 16.27.40 # grawity: if someone implements it, sure 16.27.51 # and it's not trivial 16.30.15 Quit DannyA (Quit: CGI:IRC (EOF)) 16.33.46 # hm some bootloaders use scrolling :/ 16.34.10 # they do !? 16.34.13 # just for debug though 16.34.25 # i thought that required threads 16.34.33 # threads work fine in bootloader 16.35.09 # there's just one thing in lcd-charcell.c : lcd_put_cursor uses lcd_scroll_info.ticks 16.36.35 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 16.37.02 # does it blink faster when scrolling ? 16.39.02 # I think we could use the watchdog timer for udelay 16.41.50 # New commit by 03mcuelenaere (r26922): Simplify check in gui_synclist_do_touchscreen(), no functional changes. 16.43.13 # r26922 build result: 21 errors, 0 warnings (mcuelenaere committed) 16.44.05 # hm archos needs scrolling for rolo 16.44.37 # * funman curses archos! 16.45.32 # minimum width is 14 characters? 16.45.46 # New commit by 03mcuelenaere (r26923): Fix error: assignment of read-only variable 'list_width' 16.46.51 # funman: No it doesn't blink faster when scrolling, but the scroll tick function handles both scrolling and cursor blinking 16.47.11 # yep i noticed that 16.47.25 # r26923 build result: All green 16.47.33 # The newlcd has a hardware cursor, but we don't use that because it's unknown for the oldlcd 16.47.58 # I have a strong suspicion regarding the oldlcd controller, but no device to verify :( 16.48.01 # i want to modify rolo to not use scrolling 16.49.13 # * amiconn wonders why funman does suddenly want to change stuff that's been working for years, and there has been consensus not to use special handling for the bootloader if it means too much hassle 16.49.23 Join toffe82 [0] (~chatzilla@12.169.218.14) 16.49.37 # amiconn: read backlog 16.50.27 # Any reason why the bootloader uses iram only? 16.50.51 # it's been working for years, and there has been consensus to not use special handling for the bootloader if it means too much hassle 16.51.37 # ?? 16.52.11 # Anyway, rolo needs scrolling because otherwise you have no chance to read the various error messages 16.52.58 # all messages fit in 1 or 2 lines 16.53.53 # archos player lines* 16.54.51 # No they don't, especially not considering that rolo_error() effectively uses only one line for the actual message 16.55.22 # longest message is 28 characters so surely it will fit on 2 14 chars line? 16.55.34 # There are 11 chars per line 16.55.37 # Not 14 16.56.28 # hm i was counting 112 pixels & 8 pixels per char 16.57.14 # The player is charcell, and has two lines of 11 characters each 16.57.47 # The recorders and Ondios are no problem if the application part of rolo is moved to apps/ and changed to use splash() or similar 16.57.51 # funman: 112 pixels are the bitmap archoses and sysfont is 6 characters wide, but there is teh Player 16.57.53 # 2 lines :/ 16.58.23 # ondios / recorders use bootbox too ? 16.59.11 # All archoses do 16.59.21 # New commit by 03funman (r26924): rolo is only needed in SH bootloaders, not other bootloaders 16.59.25 # New commit by 03bluebrother (r26925): Fix source string spelling. 16.59.25 # (when flashed, of course) 17.01.07 # r26924 build result: All green 17.01.37 Join stoffel [0] (~quassel@p57B4D69A.dip.t-dialin.net) 17.02.43 # r26925 build result: 25 errors, 79 warnings (bluebrother committed) 17.03.35 # That one again :( 17.03.45 # * gevaerts wants that build issue to go away! 17.04.59 Quit stoffel (Remote host closed the connection) 17.06.46 # * bluebroth3r wonders what the build system did 17.07.53 Part Zagor 17.07.57 Quit grawity (Quit: Leaving.) 17.08.19 Join hebz0rl [0] (~hebz0rl@dslb-088-065-061-076.pools.arcor-ip.net) 17.08.38 # bluebroth3r: a dependency issue, probably 17.08.45 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 17.09.35 # definitely not related to my commit though :) 17.10.45 # no 17.10.59 # If you see "25 errors, 79 warnings", it's likely to be this one 17.16.30 Nick ender1 is now known as ender` (krneki@foo.eternallybored.org) 17.17.55 Join Buschel [0] (~~andree@p54A3ABF1.dip.t-dialin.net) 17.23.40 Join Zigtown [0] (~Zigtown@CPE00259ce0fdb2-CM0014f8cc807a.cpe.net.cable.rogers.com) 17.23.46 Quit teru (Quit: Quit) 17.27.53 # amiconn: did you ever check 2g? I'm fairly sure eabi should work now. 17.39.16 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 17.45.16 Quit Strife89 (Quit: Reboot back to Linux.) 17.48.07 Join Strife89 [0] (~Strife89@adsl-80-197-231.mcn.bellsouth.net) 17.49.47 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 17.50.41 Quit Buschel (Ping timeout: 260 seconds) 17.51.38 # interesting. if I compile 3g using arm9tdmicc for cpu, the strange pictureflow lines go away 18.01.41 Join Highlander [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) 18.05.57 *** Saving seen data "./dancer.seen" 18.07.11 Join stoffel [0] (~quassel@p57B4D69A.dip.t-dialin.net) 18.12.15 Quit panni_ (Read error: Connection reset by peer) 18.19.05 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 18.19.16 Join robin0800 [0] (~quassel@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 18.20.14 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 18.23.13 Quit Zigtown (Remote host closed the connection) 18.31.56 Quit hebz0rl (Quit: Ex-Chat) 18.37.27 Quit swilde (Quit: ERC Version 5.3 (IRC client for Emacs)) 18.38.04 Quit n1s (Quit: Lämnar) 18.38.34 # funman: http://pastebin.com/Se59LeF5 18.39.50 # how are you avoiding the race condition? 18.40.19 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 18.41.03 Join CGL [0] (~CGL@190.207.202.226) 18.41.11 # By reading the period value twice. Hmm, now that I think about it again I think if it is detected I should also read now again... 18.41.13 Quit rob (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) 18.41.54 # compiler won't optimize this out since the register is volatile 18.42.09 # It's not a register on !C200V2 18.42.27 # oops ok the TIMER2_ confused me 18.42.28 # It's defined as (KERNEL_TIMER_FREQ/HZ) in that case 18.42.50 Quit robin0800 (Remote host closed the connection) 18.43.12 Join robin0800 [0] (~quassel@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 18.43.48 # can the period change anytime while we are running the loop? 18.44.14 # If pwm is enabled it changes on every timer underrun 18.44.48 Join rob [0] (~nnscript@adsl-76-235-215-255.dsl.klmzmi.sbcglobal.net) 18.45.08 # i'd just disable interrupts, get the period value, and handle 1 possible period change 18.45.57 # If you disable interrupts it can't change in between 18.46.39 # But if we disable interrupts we don't really have to muck about with the timer at all 18.46.51 # And could just use a delay loop instead :) 18.47.29 # i mean disable it while reading the period, enable it afterwards, and handle at most one timer wrap (and at most one period change) 18.48.13 # or modify the code so we can delay for more timer wraps (then no need to check if asked delay is too high) 18.48.52 # If you disable it while reading the period you can still get a timer wrap that would screw up the calculation 18.48.54 # btw if you built the USB code with gcc-eabi, the delay loop had been optimized away so it's perhaps not needed 18.49.16 # ranma: it can't happen while you're reading the period? 18.50.20 # what about watchdog, wasn't that simpler to use ? 18.50.42 # The problem with watchdog is that the frequency is not very nice. 18.50.51 # It's fixed at PCLK/256 18.51.08 # => 242187Hz 18.51.30 # how is that not nice? 18.52.08 # So converting between usecs and watchdog ticks can not be easily done with shifts. 18.52.44 # we could switch the PLL to 384MHz 18.53.08 # What's PCLK then? 18.53.14 # 64 18.53.22 # and fclk 240 18.53.50 # but we need test_codec + battery_bench results 18.54.10 # Maybe use watchdog for timer-as3525.c? 18.54.23 # And then use TIMER2 only for udelay 18.55.04 # dunno 18.55.24 # So for now fixing udelay seemed easiest for me :) 18.55.27 # we could just have a simple busy loop depending on fclk setting (we only have 2 settings) 18.56.36 # 4 cycles per loop => (FREQ/4) loops per sec => FREQ/1000000/4 loops per µsec 18.56.38 # That would probably be a bigger function though (if you want it to be inlined) 18.56.54 # I don't really see the point in forcing udelay to be an inline though... 18.57.09 # true, and i think the function would be qutie small anyway 18.57.54 # loops = ((cpu_frequency == CPUFREQ_MAX) ? 248 : 62) / 4; + 2 instructions for the loop 19.00.39 # But you have to disable interrupts during the udelay. 19.00.55 # That the timer based udelay doesn't have to disable interrupts is kind of a nice property 19.00.57 # we can wait a tad bit longer, not a problem 19.01.23 # The problem comes when someone changes the cpu frequency in between :) 19.01.32 # Hmm, or just check dthe cpu freq in each inner loop 19.01.41 # true but we won't give back thread control 19.01.43 # That could work quite well 19.01.57 # no because it could change after you have read it 19.02.26 # But it doesn't change that often, so the error would be small 19.03.04 # we want a minimal delay 19.03.35 # http://pastie.org/1010333 19.03.59 # only threads change the cpu freq, not code that runs in interrupts so it's ok 19.04.35 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 19.04.36 # But udelay could be called from a thread? 19.04.54 # yes, and since it blocks other threads cpufreq won't change 19.05.13 # How does it block other threads if it doesn't disable interrupts? 19.05.35 # blocking == not explicitely giving control back with yield/sleep/functions with timeout 19.06.02 # Oh, I thought we are using preemptive multitasking using the timer interrupt :) 19.06.05 # (thanks to cooperative threading) 19.06.05 Quit liar (Client Quit) 19.06.51 # you want to test this function? i can do it later 19.07.07 # Great, so let's just switch to a simple udelay like that one :) 19.07.15 # now i'm trying to change bootloader memory map 19.07.32 # sorry if you had more complex things in mind ;) 19.07.42 # I'll change it so it doesn't need the multiply and test it 19.08.18 # subs %0, %0, %1 ? 19.09.25 # we need (cycles_per_usec+3)/4 also, to make suer we don't wait too little time 19.09.47 # and CPUFREQ... + 999999 ? 19.12.37 Join Buschel [0] (~~andree@p54A3F303.dip.t-dialin.net) 19.14.09 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 19.15.58 Join JohannesSM64 [0] (~johannes@cm-84.209.27.113.getinternet.no) 19.21.00 Quit pixelma (Quit: .) 19.21.22 Join pixelma [0] (quassel@rockbox/staff/pixelma) 19.21.35 # funman, I think I found out how to configure the PLL on the AMSv2 sansas 19.22.07 # we can set the PLLA to 248 MHz, just like the AMSv1 sansas, for example 19.24.54 Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) 19.31.38 Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) 19.32.31 Join Jaykay [0] (~chatzilla@p5DC57387.dip.t-dialin.net) 19.33.56 # New commit by 03funman (r26926): as3525*: enable MMU in bootloader ... 19.34.59 # now bootloader with USB links fine 19.35.25 # r26926 build result: All green 19.36.47 Quit DerPapst1 (Quit: Leaving.) 19.36.52 Join DerPapst [0] (~Alexander@dslb-088-069-158-170.pools.arcor-ip.net) 19.37.37 Quit pamaury (Remote host closed the connection) 19.39.24 # New commit by 03funman (r26927): as3525*: enable USB stack in bootloader (but not USE_ROCKBOX_USB yet) 19.40.50 Quit DerPapst (Ping timeout: 240 seconds) 19.41.27 # r26927 build result: 7252 errors, 1155 warnings (funman committed) 19.42.47 # just a couple of errors 19.43.02 Join fml [0] (~chatzilla@p5DD2C82E.dip.t-dialin.net) 19.43.26 # Hello. Have the manuals been built today? 19.47.08 # New commit by 03funman (r26928): fix endif wrongly removed (should have been moved) in r26927 19.48.10 Quit linuxguy3 (Ping timeout: 245 seconds) 19.48.36 # r26928 build result: All green 19.48.58 Quit S_a_i_n_t_ () 19.49.13 # ranma: i don't see µSD drive on fuzev1 19.50.04 # * ranma hasn't tried the slot on his C200v2 yet 19.50.09 Join linuxguy3 [0] (~timj@75.57.170.49) 19.50.56 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.248) 19.52.18 # also lsusb -v gives some errors (if that helps) 19.53.21 # if i do that, rb stays stuck on USB screen after unplug 19.54.24 Quit Buschel (Ping timeout: 252 seconds) 19.54.50 # % sg_luns /dev/sg6 19.54.50 # Lun list length = 16 which imples 2 lun entries 19.55.24 # i guess that means the sd slot is around 19.55.52 # 1 lun entry on clipv1 19.56.52 Quit powell14ski_ (Read error: Connection reset by peer) 19.57.23 Join powell14ski [0] (~powell14s@c-24-9-7-198.hsd1.co.comcast.net) 19.57.42 # about USB bootloader mode, since it's intended as a recovery tool, perhaps we could enable it only on a certain keypress 20.02.24 Quit powell14ski (Ping timeout: 276 seconds) 20.03.10 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 20.03.29 # bertrik: what gives most accuracy: 248 or 384 ? 20.04.39 # 384 MHz gives most accuracy 20.06.01 *** Saving seen data "./dancer.seen" 20.06.53 Quit fml (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 20.08.01 # if we use 384MHz PLL we could use it also for USB 20.09.12 # we would need to max out the CPU at 240MHz, not a big difference, and perhaps the faster pclk on AMSv1 would lower this difference 20.11.15 # Changing to 248 MHz is a small change, just change from 4 MHz * 60 to 4 MHz * 62. For 384 MHz we may have to experiment a bit to make sure we don't exceed limits of the internal PLL signals (Fvco and Ffbk) 20.11.27 # To not have to change voltage for cpu frequency switching 200MHz would better IIRC? 20.12.00 # ranma: this doesn't work on devices with sd slot and gives very limited battery savings (last time i tested on clipv1) 20.12.34 # bertrik: we can make 2 changes: 1/ switch AMSv2 to 248MHz so they use the same code than AMSv1 20.12.58 # 2/ see if using 384MHz PLL has no drawback on AMSv1, and see if we can use a 384MHz setting on AMSv2 20.15.05 # funman, we can generate the 240 MHz CPU clock from the 384 MHz? (using the pre-divider for example) 20.16.14 # yes, 384*5/8 == 240 20.17.08 # By the way, I realised we can just use the 2nd PLL for USB only, because the extra 2.5 mW power consumption is not important when we're connected to a PC anyway (we're probably charging then) 20.18.17 Join kugel [0] (~kugel@rockbox/developer/kugel) 20.18.40 # nice idea 20.20.45 # yes that's what the code does now, so using 384MHz pll would just give more accurate playback freq and rounder frequencies 20.20.49 Quit stoffel (Remote host closed the connection) 20.21.10 # (the latter helps with the planned new udelay() ) 20.22.13 Quit t0rc (Remote host closed the connection) 20.24.11 # Not tested yet, but this one doesn't need the mul, but may be not that accurate :/ http://pastebin.com/rJgZavw1 20.25.40 # why not using mul? 20.25.51 # What do we need super-accurate udelay for? 20.26.04 # iiuc it's not as terribly slow as division 20.26.18 # bertrik: not super-accurate, just guaranteed minimal delay 20.27.04 # -> to avoid surprises when changing compiler/whatever like it happened on the D2 (at least) 20.30.03 Join petur [0] (~petur@rockbox/developer/petur) 20.30.42 # ok 20.31.16 # New commit by 03funman (r26929): arm/crt0.S: comment why the reset vector doesn't use absolute addressing 20.31.57 Join binaryhermit [0] (~binaryher@adsl-75-63-51-213.dsl.emhril.sbcglobal.net) 20.31.58 # Ok, so just this simple one then: http://pastebin.com/q4WMvANU 20.32.32 # ranma: i agree with what you said earlier: no need to inline it 20.32.39 # New commit by 03bertrik (r26930): as3525v2: document PLL bits and show current PLL frequency in the debug menu 20.32.45 # r26929 build result: 207 errors, 62 warnings (funman committed) 20.32.51 # grr 20.33.11 # ah it's not me :) 20.33.18 # Interestingly the +3 is optimized away completely :) 20.33.34 # funman: Put it in system-as3525? 20.33.36 # * kugel thinks udelay should be as accurate as possible, so inline if doable 20.33.46 # ranma: if usecs is always a multiple of 2, yes 20.34.10 # r26930 build result: 207 errors, 62 warnings (bertrik committed) 20.34.32 # kugel, that depends on whether you want some *guaranteed minimal* delay or super-accurate 20.34.44 # But udelay can be used in quite a few places, so forcing it inline bloats the code 20.35.12 # One could probably add a udelay_inline() if that's needed anywhere 20.35.30 # that would just call udelay? :P 20.35.34 # bertrik: both ideally :) 20.35.49 # kugel: well with this change we don't take in account time spent in interrupts 20.35.57 # but it should be quite small anyway 20.36.03 # ranma: the current udelay is tiny on !C200V2 because of constant parameter optimization 20.36.06 Join DerPapst [0] (~Alexander@p4FE8F827.dip.t-dialin.net) 20.36.16 # I checked disassembly 20.37.04 # The delay we currently use in firmware/target/arm/as3525/fmradio-i2c-as3525.c is probably way off 20.37.06 # 5-6 insn basically 20.37.22 # kugel: Well, as I said, if we would change timer-as3525.c to use the watchdog we could use TIMER2 exclusively for udelay :) 20.37.49 # This udelay is 11 instructions 20.38.04 # or the other way around :) 20.38.14 # both have 1.5MHz so it doesn't really matter does it? 20.38.49 # kugel: No, watchdog is not 1.5MHz 20.38.59 # It's PCLK/256 20.39.09 # and PCLK is? 20.39.12 # 62MHz 20.39.16 # ranma: btw did you check if usb_delay() was removed when built with eabi ? 20.39.24 # sdram_delay() wasn't so i removed it completely 20.39.33 # (forgot to mention that in the svn log) 20.39.33 # funman: No, did not check. 20.39.50 # i mean it *was* removed (it wasn't present) 20.40.21 # ranma: but does watchdog really work for timer? timer restarts automatically independantly of how long the tick tasks run (so the timer doesn't get off by the time the ticks need to run) 20.40.34 # kugel: Yes, it has automatic reload 20.41.08 # I poked at it using JTAG and verified that :) 20.41.47 # bertrik: where does the 12MHz freq comes from ? 20.41.59 # you could also use watchdog for backlight on the c200v2 and the current udelay could stay as is, couldn't you? 20.42.05 # when clk_sel == 0, the source is 24MHz like on AMSv1 20.42.13 # it works well where TIMER_FREQ is a constant 20.42.19 # funman, I don't know 20.42.33 # does the other 240MHz setting match with these bits? 20.42.52 # yes 20.43.13 # hum i see a 384MHz setting in clip+ OF 20.43.15 # 181F 20.43.21 # Not as easy, the watchdog timer has no bgload register, could possibly work well enough anyway 20.43.41 # also 232 and 234MHz (table is at 0x8CC0) 20.43.54 Quit JohannesSM64 (Quit: WeeChat 0.3.3-dev) 20.44.13 # kugel: what's wrong with using a busyloop for udelay? 20.45.01 # what's wrong with the current one? 20.45.16 # doesn't work on c200v2 20.45.22 # and it's long & complex 20.46.15 # bertrik: do you need me to test on fuzev2/clipv2 before committing the change to 248MHz ? 20.46.26 # funman: I disagree 20.46.50 # it works on c200v2 if you call it in a loop with smaller delays, doesn't it? 20.46.55 # no 20.46.59 # 232 MHz would result in exactly the sample rate error that the OF makes that dfkt posted an image of 20.47.16 Quit flydutch (Quit: /* empty */) 20.47.41 # funman: With my small changes it should work reliably :) 20.47.56 # funman: it's optimized and inlined very few instructions 20.48.04 # ranma: which one? 20.48.18 # and it could be cleaned up if the c200v2 can get a fixed TIMER_FREQ 20.48.20 # kugel: perhaps it's small in binary but the source is hard to read 20.48.38 # kugel: http://pastebin.com/Se59LeF5 20.48.40 # funman: you re-wrote it a bit, I found it very readble in my first version 20.49.08 # i fixed a bug 20.49.25 # funman, yes please. Shall we change it to 248 MHz now, and consider changing/trying the PLL to 384 MHz in the coming weeks? 20.49.27 # ranma: well without locking it can't work.. 20.49.32 # bertrik: sure 20.50.07 # Why do you think it can't work? 20.50.18 # ranma: also what makes me feel bad is that we need a full page of comments to explain the code 20.50.36 # "avoid race condition" <- how exactly is it avoiding a race condition if you don't lock? 20.50.38 # The double-read of TIMER_PERIOD should catch the wrap-around race 20.50.49 # unless it wraps again after you have read it 20.51.47 # That shouldn't happen unless you get a (non-timer) interrupt between the first read and the correction 20.51.53 # udelay() is a 'somewhat inaccurate delay', writing it in 10 lines is better than in 60 lines 20.52.08 # And then that would probably add so much additional delay that it doesn't matter 20.52.22 # better write a 10 lines function which needs no special case and not 30 lines of comments 20.53.14 # we just need something which will gives at minimum the same delay, not depending on current cpufreq or compiler used 20.53.41 # if simple busy loop achieves that, why not going the simple way? 20.54.56 # I agree that a simple busy loop is probably quite sufficient 20.55.48 # also we can limit parameter to unsigned short and use 16*16 MUL ? 20.57.00 # The disassembly I see here is doing a simple "mul r3, r1, r2" 20.57.25 # Followed by "mov r3, r3, lsr#2" for the /4 20.57.26 # that works but if we use longer than 1<<16 argument the compiler would warn 20.58.14 # i'll test on the devices i have 21.01.39 # how do you enter a newline in the text editor? 21.04.08 # New commit by 03bluebrother (r26931): Make System and Utils class based on QObject. ... 21.04.14 # New commit by 03bluebrother (r26932): Rockbox Utility translation updates. ... 21.05.38 # r26931 build result: 207 errors, 62 warnings (bluebrother committed) 21.07.11 # r26932 build result: All green 21.07.40 # funman: Can you explain why the r26118 changes were necessary? They are preventing charging from being enabled when booting with USB connected. 21.08.18 Part watto 21.08.33 # mc2739: it prevents entering USB mode if usbstack is enabled and used 21.08.50 # hmm, jakorasia-cg seems to announce sdl but misses at least SDL.h 21.08.50 # well, before the change 21.11.15 # mc2739: does charging work with these changes removed? 21.12.36 # funman: busy loops are the things that are usually cpu freq and compiler dependant 21.13.57 # Well, the loop itself is inlince assembler and it's taking cpu freq into account 21.14.11 # New commit by 03funman (r26933): as3525*: make udelay() be a simple busy loop ... 21.14.35 # Given that the multitasking is cooperative the freq shouldn't change while the delay loop is running 21.14.41 Join piggz [0] (~piggz@89.243.102.220) 21.15.33 # mc2739: http://pastie.org/1010534 works? 21.15.52 # r26933 build result: 207 errors, 62 warnings (funman committed) 21.16.42 # mc2739: IIUC the problem is that when we boot with USB/charger inserted, there is no edge detection so we need to get the status at init 21.16.50 # New commit by 03bluebrother (r26934): block jakorasia-cg build client 21.18.22 # mc2739: btw about your mkamsboot patch for docking, if we harass ranma often enough he will make the USB driver full-featured and we will be able to remove USB check from mkamsboot ;) 21.18.35 # does rockbox support any features of an ipod dock? i have a sony dab radio with ipod dock....sound works ok, but no controls 21.20.23 # piggz: Rockbox has basic accessory support, but the results differ between accessories. 21.21.26 # ok 21.21.28 Join 50UAAFOUW [0] (~powell14s@c-174-51-160-240.hsd1.co.comcast.net) 21.21.48 # IIRC there's a wiki page listing accessories that have been tested. 21.22.18 # ah, here: http://www.rockbox.org/wiki/IpodAccessories 21.24.24 # bertrik: got a diff for me to test, or shall i make it myself? 21.25.02 # at the moment, when i plug into my usb port, its not switching to disk mode...it was yesterday, any ideas? 21.25.43 # funman, in clock-target.h: -#define AS3525_PLLA_SETTING 0x113B 21.25.43 # +#define AS3525_PLLA_SETTING 0x113D 21.26.08 # wait, that's not all sorry, I'll make a patch 21.26.42 # piggz: try holding Menu while plugging it in. That will make it not change into USB but only charge. 21.26.57 # http://pastebin.ca/1885969 21.27.13 # though I don't understand why it changes into USB mode -- this would mean that the dock acts as USB host. 21.27.31 # bluebroth3r: im talking about my laptop now :) 21.29.04 # piggz: err ... what do you expect when connecting the Ipod to a PC? 21.29.31 # bluebroth3r: what is supposed to happen? 21.29.55 # bertrik: hm that doesn't give a round pclk for fuzev2 21.30.19 # piggz: well, I would expect it to change into USB connection mode :) 21.30.33 # aah, misread. It's _not_ going into usb mode :o 21.30.59 # bluebroth3r: yes :) ....... well, actually, it is when i plug it into a different port 21.31.08 # the usual things to test: try a different usb port and cable. 21.31.25 # especially front usb ports have been reported to be flaky at times. 21.31.34 # so, i one port, it goes into disk mode, the other says something about usb presentation multimedia 21.31.35 # funman: Sorry, had to step away for a bit. Yes, charging works with r26118 reverted. It also works with http://pastie.org/1010534 21.31.59 # hmm. You will always get USB HID mode unless you turned that off. 21.32.02 # mc2739: ok i will commit this diff (with the ';' added :p ) 21.32.41 # however, if the connection is flaky I could imagine that the PC gets a bit confused by the multiple functionality. Turn HID mode of if you don't use it (IMO it should default to off anyway) 21.33.37 # On the defaults note, is there a reason why dircache isn't on by default? 21.34.05 # AlexP: afaik there are some bugs with dircache. Though I can't remember observing them in the last years. 21.34.24 # I've not seen any personally, but that doesn't mean much :) 21.34.28 # pamaury fixed a couple of bugs with dircache IIRC 21.34.30 # funman: is USB detection still working with that patch? 21.34.34 # piggz: HID mode is known to cause problems on OS X. In case you're using a Mac :) 21.34.35 # And pamaury has been working on it not too long ago 21.34.41 # mc2739: i didn't test but it should 21.34.43 # AlexP: indeed :) 21.35.02 # I'll bug pamaury next time he drops by 21.35.26 # btw, what do people think about making ipodpatcher / sansapatcher and company use a version.h file instead of using -DVERSION=...? 21.35.54 # bluebroth3r: no, linux 21.36.45 # bluebroth3r: I could even send a mail asking, inspired by the recent mail exchanges :) 21.37.36 # bertrik: http://pastie.org/1010558 <- it will give 41.333333... MHz pclk on fuzev2 21.37.42 # AlexP: sounds reasonable :) 21.38.18 # oh, and another thing I'm considering: how about moving rbutil to the utils folder? It's a bit strange to have this separation. 21.38.59 # funman, what's the usual PCLK for as3525v2 targets? 21.39.20 # so what is the point of hid mode? surely, when you plug it in, you want to be able to copy media to it? 21.39.25 # bertrik: ~line 89 of clock-target.h 21.39.27 # AlexP: if I recall dircache chokes on too many small files (main example often mentioned was the HVSC) 21.39.29 # funman: Why limit udelay to unsigned short? 21.39.49 # ranma: multiplication result fits in 32 bits 21.39.58 # oh, just 21 MHz!? 21.40.05 # 24MHz on clipv2/clip+ 21.40.21 # With cycles_per_usec == 248 for 248MHz it should work very well for more than that 21.40.35 # pixelma: OK, I'll try that, cheers. I've just sent my mail, so maybe you could respond there too if you get a min 21.40.39 # true but that way no need to check for overflow 21.41.11 # Not quite true, it doesn't warn on usb_delay(100), does it? 21.41.32 # 1000*100 gets truncated to 34464... 21.41.37 # hm i didn't see this 21.41.50 # AlexP: it's also quite RAM hungry and would need a reboot anyway 21.42.27 # Maybe only on as default on HD targets 21.42.34 # or not? Not sure as I don't use it... but the former is the reason why it's not even there on lowmem targets 21.42.39 # on my test it doesn't get truncated but it doesn't warn either 21.42.41 # It increases performance really quite a lot there 21.43.05 # it warns only when assigned to a short 21.43.12 # With unsigned it should work for delays up to 17318416 (17 seconds) 21.43.31 # So I don't think a check for overflow is needed there 21.43.45 # then just remove the short and perhaps add a comment to give the higher limit 21.44.19 # not that we'd want to sleep for 17 seconds anyway :) 21.44.33 # piggz: normally the Ipod should do HID and UMS at the same time. 21.44.53 # funman, is it a problem that PCLK is non-integer for fuzev2? 21.45.09 # Also PCLK on as3525v2 seems quite slow compared to as3525 21.45.14 # no i think it's ok, it justs shifts udelay a bit 21.45.42 # bertrik: slower = less power needed = better ? 21.46.47 # New commit by 03bluebrother (r26935): Log filesystem free value to system trace. 21.47.33 # http://pastie.org/1010558 21.47.39 # bluebroth3r: ok..that seems to not be happening here....on one port...the ipod seems to reboot into some standard disk mode, with flashing stop sign....in the other port it stays in rockbox with a usb icon, but doesnt show as a disk 21.47.51 # I thought you set some DRAM clock stop bit some time ago, so maybe faster is no longer more power consuming 21.48.00 # New commit by 03funman (r26936): as3525: cache first read of enrd0 register ... 21.48.16 # it was for DRAM but pclk keeps running no? 21.48.16 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 21.48.26 # r26935 build result: All green 21.48.28 # yes, I think so 21.48.48 # piggz: that is strange. Rockbox does reboot into the Apple firmware for disk access, but this is only true for releases. Current builds of Rockbox use the Rockbox usb stack. 21.48.53 # I'd expect that the CPU wastes cycles waiting for the slow DRAM, but maybe only when boosted 21.49.01 # I'd try disabling HID. 21.49.06 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 21.49.19 # bluebroth3r: oh, im using the 3.6 release 21.49.43 # funman, is this easy to change? I could do a battery bench with a different DRAM clock. 21.49.47 # ah, ok. Then there's something wrong with the connection detection on this one port. 21.49.54 # bertrik: sure, clock-target is here for that 21.50.03 # AlexP: IIRC the main dircache issue is that it fails non-gracefully if you have too many files and/or directories. I don't know the details 21.50.10 # ok, so just change AS3525_DRAM_FREQ, right? 21.50.10 # nevertheless, try disabling HID :) 21.50.20 # right 21.50.28 # ok...with hid disabled, what is the expected bahaviour? 21.50.29 # r26936 build result: 207 errors, 62 warnings (funman committed) 21.50.47 # but this pretty much sounds like that USB port on the PC is acting up a bit. 21.50.54 # piggz: reboot into USB mode. 21.51.01 # k, ta 21.51.16 # funman: Did you test the udelay? Seems off (too slow) here... 21.51.25 # i didn't time it 21.51.32 # would you reccomend i install the latest build? 21.51.33 # * bluebroth3r remembers his Windows box telling about overcurrent on USB the other day but no USB devices were attached to the machine 21.52.00 # I thought jakorasia-cg had been disabled? 21.52.01 Quit jgarvey (Quit: Leaving) 21.52.04 # gevaerts: I've just downloaded the HVSC to try - it must be a chiptune thing as I have a 120 GB drive full of mp3/ogg and that isn't enough files to get it to die 21.52.17 # well, not chiptune specifically of course 21.52.41 # But only if hou have a huge numbers of very small files as chiptune collections tend to be 21.52.44 # Did a for (i=0; i<10; i++) { backlight_on(); udelay(500*1000); backlight_off() udelay(500*1000); } at the end of system_init() 21.52.47 # ranma: it *will* be slower, what is the difference you are measuring? 21.52.51 # And it seems to take about 40 seconds 21.52.53 # it depends if you want a "more stable" build. Releases are generally considered more stable, but I'm using current builds all the time. However, there was a change in the theme syntax since 3.6, so your old themes won't work anymore (in case you use themes that aren't shipped with the default Rockbox install) 21.52.58 # AlexP: well it's called "High voltage *sid* collection" for a reason ;) 21.53.07 # indeed so :) 21.53.29 # ranma: cpu_frequency might be uninitialized 21.54.05 # bertrik: http://pastie.org/1010558 works on all AMSv2, should I commit it ? 21.54.33 # Yeah, but if it's != CPUFREQ_MAX it should use the lower cycles_per_usec value, which shouldn't take longer than expected 21.54.33 # FWIW higher pclk means faster codecs and less boosting 21.55.03 # funman, yes, let's do it! :) 21.55.25 # gevaerts: did I something wrong when trying to block jakorasia-cg? It got an SDL build again 21.56.23 Join einhirn [0] (~Miranda@p548515B1.dip0.t-ipconnect.de) 21.56.31 # New commit by 03funman (r26937): as3525v2: use 248MHz PLL (reverse engineered by bertrik) ... 21.57.35 # Ok, never mind, it was initialized to _MAX, but actually running at _NORMAL 21.57.52 # i think it's only set correctly after the first cpu_boost() 21.57.59 # r26937 build result: All green 21.58.16 # Adding a set_cpu_frequency(CPUFREQ_NORMAL) before the test fixed it. 21.58.21 # can these PLL settings be used on amsv1? having unboosted = pclk = 41MHz would be nice for battery life on those players 21.58.37 # saratoga: sure, we just need to make sure display/wheel is fast enough 21.59.12 # 40mhz is about what a lot of the codecs use, so I think it should be fast enough for display/ui 21.59.14 # saratoga: ok for reverting r26396 ? (clip+ button change) : it would make quickscreen the same on all the clips and make some people happy (myself i only care about common keymap across clips) 21.59.25 # funman: yeah go for it 21.59.50 # when i get a chance i'm going to software hold to hotkeys and then see if i can get them on the clip+ 21.59.56 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 22.00.15 # 'going to add software hold to hotkeys' 22.02.00 # that sounds weird 22.02.53 # saratoga, the display runs at 1/16 of PCLK, so PCLK at 41 MHz would limit framerate to 66 fps on the fuzes (could be enough, but I think kugel likes it faster) 22.03.36 # bertrik: I think it's not too slow, but the code could be smarter to make better use of it 22.03.41 # New commit by 03funman (r26938): clip+ keymap: revert r26396 ... 22.04.04 # we need another DMA channel so we can update the screen with DMA ! 22.04.16 # dfkt: ^ now you 'owe' us a keymap patch ;) 22.04.19 # New commit by 03ranma (r26939): With a max delay of 17 seconds before overflow happens limiting to unsigned short shouldn't be necessary. 22.04.23 # bertrik: thats only when unboosted right? 22.04.28 # hm, I think DBOP does support DMA indeed 22.04.59 # saratoga, no, I thought PCLK was basically fixed and we only increase FCLK when boosting 22.05.09 # r26938 build result: 204 errors, 62 warnings (funman committed) 22.05.30 # is he banned only of odd revisions builds? 22.05.45 # ideally we should always have pclk as high as it can go for a given fclk, so that would mean changing pclk too 22.06.00 # since boosting the CPU but leaving the ram underclocked is not the best idea 22.06.03 *** Saving seen data "./dancer.seen" 22.06.38 # pclk is 65MHz max, and ram freq 90MHz max but we could never use ram freq higher than 65 (well, 64) 22.06.45 # r26939 build result: All green 22.07.40 # does the build system allow banning based on revision numbers? :o 22.07.57 # there is a lot of code we should battery benchmark, the code in AMSv1 sd_enable only had very minor impact 22.08.07 # bluebroth3r: perl can do anything ;) 22.08.43 # magic! ;-) 22.08.53 # looks like it's trying to draw a curve on our build table 22.09.35 # i think i never tested the dma_retain() / dma_release() also 22.11.20 Join DataGhost [0] (~dataghost@17-18-ftth.onsnetstudenten.nl) 22.11.20 Quit DataGhost (Changing host) 22.11.20 Join DataGhost [0] (~dataghost@unaffiliated/dataghost) 22.13.39 Quit funman (Quit: ++) 22.15.20 # dfkt: ^ now you 'owe' us a keymap patch ;) <-- hug kiss kiss hug!!!!! 22.15.35 # and didn't i deliver a decent keymap already? ;) 22.24.43 # bluebroth3r: I don't see anything wrong. Maybe Zagor or Bagder can check if the build server uses the correct block file 22.28.22 # bluebroth3r: i installed the latest build...with hid mode on, when i plug it in, it switch to 'usb keypad mode', but the kernel says hub 2-0:1.0: unable to enumerate USB device on port 3 22.28.42 Quit Jaykay (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 22.30.20 # bluebroth3r: i take it back...it eventuall showed up 22.32.41 Join Buschel [0] (~~andree@p54A3EF39.dip.t-dialin.net) 22.34.18 # piggz: nice to hear 22.36.29 # gevaerts: ok, thanks for checking 22.40.19 Quit Buschel (Ping timeout: 272 seconds) 22.48.52 Join dfkt_ [0] (~dfkt@unaffiliated/dfkt) 22.49.31 Quit dfkt (Disconnected by services) 22.49.36 Nick dfkt_ is now known as dfkt (~dfkt@unaffiliated/dfkt) 22.51.25 Quit MagusG (Ping timeout: 276 seconds) 23.05.04 Quit petur (Quit: Zzzzz) 23.10.02 # New commit by 03bieber (r26940): Theme Editor: Working on rendering viewports, display will now show %V(...) viewports as red rectangles over backdrop or background color 23.11.33 # r26940 build result: All green 23.12.48 Join anewuser [0] (anewuser@unaffiliated/anewuser) 23.19.09 Quit evilnick_B (Quit: Page closed) 23.23.07 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 23.24.54 Join hamish_ [0] (~hamish@119.224.50.74) 23.27.29 Join kramer3d_ [0] (~kramer@unaffiliated/kramer3d) 23.27.35 Quit hamish_ (Client Quit) 23.35.07 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 23.35.34 Join funman [0] (~fun@rockbox/developer/funman) 23.36.48 # dfkt: did you make a patch for keymap-clip.c or only described a better keymap? 23.37.29 Quit dfkt (Disconnected by services) 23.37.35 Nick dfkt_ is now known as dfkt (dfkt@unaffiliated/dfkt) 23.37.55 Quit komputes (Quit: I haven't slept for ten days, because that would be too long.) 23.40.47 # dfkt: ^ 23.41.56 # funman, i think you saw my response in the logs? :) 23.42.18 # and no, i doin't know how to code C, i didn't make a keymap, i only described it to you 23.43.21 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 23.44.28 Quit piggz (Remote host closed the connection) 23.44.45 # ok just to be sure, i'll look at it again to make the patch 23.46.17 # i found http://pastebin.com/sG9XGmRE for recording but iirc you had devised something for FM too 23.46.38 # 'move menu from down to center' ok 23.46.52 # the only thing that was distracting in the FM keymap was that it used the down key for menu function instead of the center button 23.47.02 # yep 23.47.14 # btw apps/keymap/keymap-clip.c requires no C knowledge (IMO) 23.47.55 # maybe i could cobble something together, but don't take my word for it ;) 23.48.06 # center is already used for 'FM_PRESET' 23.48.16 # come to me when it's about usability, or measurements, but not coding :) 23.48.29 # jhMikeS: Not yet 23.48.37 # i didn't perceive any function on the center button? lemme check 23.48.44 # can't see any either :/ 23.48.58 # The strange lines probably have to do with signed vs. unsigned shifts or similar. Need to compare disassemblies 23.49.26 # no function in either preset or scan mode 23.49.43 # the thing that sticks out most for me on the clip fm screen is that you need POWER to exit 23.50.11 # isn't POWER the exit function to pretty much everything on clip? 23.50.18 # plugins, playback, etc 23.50.19 # indeed 23.51.35 # the home button is unused in FM mode too, one could use it for exit as well 23.52.07 # i'm not sure how the consensus on redundancy of buttons is in rockbox 23.52.34 # we usually have more functionality than we have buttons :) 23.52.43 # i don't know, but the consensus on consensus is you should avoid talking about them ;) 23.52.53 # heh 23.53.56 # FM menu uses context settings so SELECT is (also?) ACTION_SETTINGS_RESET iiuc 23.55.44 Quit stripwax (Quit: http://miranda-im.org) 23.55.54 # What annoys me about the clip keymap is that there doesn't seem to be a button to resume/ return to the wps 23.56.34 # amiconn, that's what i think too 23.57.05 # return to wps could be (once again) mapped to the power button, no matter where in the menu one is 23.57.16 # if you are in the WPS and press HOME, you go to the menu, press HOME again and you're in the WPS again 23.57.20 Part toffe82 23.57.21 # or the home (sic) key) 23.57.26 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 23.58.02 # bertrik, when you go to the file/folder list, there isn't a fast way to return to wps, afaik? 23.58.34 # dfkt, indeed there isn't, HOME just seems to go one screen back