--- Log for 13.10.109 Server: verne.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 2 days and 15 hours ago 00.03.23 Quit shai ("Leaving") 00.03.29 # gevaerts: I suppose a single USB transmission will never exceed 512 kiB? 00.03.41 Quit barrywardell () 00.03.54 # TheSeven: in theory it could :) 00.04.19 # However, MSC does 64K at most, and I guess other protocols won't go over that either 00.04.56 # * TheSeven also supposes everyone trying to introduce a buffer that's that big would get slapped 00.07.06 Join Strife89 [0] (n=michael@adsl-220-108-49.mcn.bellsouth.net) 00.07.16 # gevaerts: what should i do if a transfer fails, that was started using usb_drv_send_nonblocking? just forget about it? 00.07.32 Join polobric1lo [0] (n=paul@AGrenoble-257-1-77-78.w86-211.abo.wanadoo.fr) 00.08.55 # TheSeven: call usb_core_transfer_complete() with a nonzero status 00.09.13 # ah, this thing has a callback :-) 00.09.23 # that API really needs documentation 00.09.48 Join intrados2 [0] (n=intrados@cpe-75-187-57-252.columbus.res.rr.com) 00.10.04 # documentation? What's that? 00.10.36 # * DerPapst never heared of that 00.10.38 # but yes, some documentation would be good... 00.10.44 # * linuxstb thought TheSeven enjoyed reverse-engineering 00.11.00 # rasher: The bar line-selector has no issues on e200 target. Trying sim now 00.11.14 # TheSeven: now close those source files you're looking into for reference! You're supposed to start from rockbox.ipod! 00.15.10 Quit HellDragon (Read error: 54 (Connection reset by peer)) 00.15.21 Join HellDragon [0] (n=jd@vpn.exhort.ca) 00.16.41 # TheSeven: I think the blocking versions also call usb_core_transfer_complete() 00.19.07 Quit polobricolo (Read error: 110 (Connection timed out)) 00.19.51 Quit intrados1 (Connection timed out) 00.23.01 Nick bertrik_ is now known as bertrik (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 00.24.07 *** Saving seen data "./dancer.seen" 00.25.34 # Hello. I'd like to add information about the USB/Power connector on http://www.rockbox.org/wiki/SamsungYH920. However access is denied. Could somebody help me? 00.26.15 # gevaerts: are there any non-EP0 control transactions? I have different interrupt bits for SETUP done and XFER complete, how should I handle that for non-EP0? 00.26.27 # TheSeven: no 00.26.58 # in theory there could be control transactions involving up to 3 setup packets in a single transfer :-/ 00.27.18 # we don't do those! 00.27.29 Quit domonoky (Read error: 104 (Connection reset by peer)) 00.27.54 # ysae: you need to get write access from someone. I knew how to do that, but the wiki software changed, and apparently it's different now :\ 00.28.28 # * gevaerts looks around. Does someone else know? 00.28.45 # ysae: do you already have an account and if so what's your wiki name? 00.29.17 # DerPapst: Yes, I do. It's DennisRoch. 00.29.54 # rasher: I can't reproduce on e200sim. Please verify you've got a clean and updated tree, then recompile into an empty directory. I'm just checking to make sure of course... This is what I did. 00.30.05 # * tomers Going to sleep 00.30.46 # ysae: added 00.31.19 # oh, they just dropped the T? 00.31.45 # saratoga: how do you add people? 00.32.13 # DerPapst: edit WikiUsersGroup 00.32.59 # tomers: sorry for wasting your time, I was a few revisions behind 00.33.06 # gevaerts: thanks ;) 00.33.19 # thanks alot 00.34.04 # gevaerts: How should the blocking send behave? I see the TCC driver disabling IRQs during the whole transfer!? 00.35.06 Quit killan_ ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") 00.35.26 # adding people works the same as the old wiki 00.35.39 Quit togetic ("WeeChat 0.3.0") 00.36.05 # TheSeven: that doesn't sound good... On ARC there's a transfer_complete() function that gets called from the interrupt handler, and that one makes the call unblock 00.36.07 # * DerPapst didn't know how it worked there :P 00.36.40 # TheSeven: look for transfer_completion_signal in usb-drv-arc.c 00.36.56 # * gevaerts isn't too familiar with the other drivers 00.37.22 # * TheSeven doesn't like that bloaty ARC chip 00.37.24 Quit DerPapst ("Leaving.") 00.38.55 # has anybody ever thought about implementing a sound card function driver? :-P 00.39.01 Nick YPSY is now known as Ypsy (n=ypsy@87.106.45.183) 00.39.10 # of course 00.39.30 # * gevaerts still wants that 00.39.51 # is it just lack of time as usual, or are there some blockers? 00.40.43 # We haven't done isochronous transfers yet on any hardware, apart from that it should be reasonably straighforward 00.40.58 # * linuxstb still wants his usb printer 00.40.59 # In a way I've actually done a full usb audio implementation :) 00.41.09 # * bertrik thinks it's nice as an exercise, but probably pretty useless in practice 00.41.25 Join killan [0] (n=nnscript@c-0efa70d5.06-397-67626721.cust.bredbandsbolaget.se) 00.41.27 # See FS#8747 for a really useless usb audio device 00.41.34 # any clue why the nano2g playback performance is poor? 00.41.55 # performance in which terms? 00.42.02 # CPU usage 00.42.21 Part froggyman 00.42.26 # I did some tests last night, and audio was decoding slower than we would expect compared to other targets 00.42.29 # bertrik: why? There's lots of possibilities 00.43.11 # slower then other ARM9TDMI targets lacking IRAM 00.43.54 # suggesting either a lot of time wasted in some thread, extremely slow RAM/IRAM access, or that its not clocked as fast as we think it is 00.43.57 # caches are already properly enabled, right? 00.44.41 # maybe DRAM access is poorly set up? 00.45.07 # are we setting up SDRAM access at all? I think apple sets that to 32MHz 00.45.19 # the difference in MP3 which should be almost entirely IRAM is large, suggesting that its not just DRAM 00.45.36 # unless IRAM somehow depends on the DRAM clock 00.45.44 # saratoga: how much MHz did an average MP3 use? 00.46.02 # mine still played back fine at 50MHz, but the pcm buffer was almost empty all the time 00.46.03 # I would expect < 40MHz for ARM9TDMI with fast IRAM 00.46.14 # linuxstb measured 50MHz 00.46.33 # so something is consuming 10-12MHz easily 00.46.50 # AAC+ was something like 50MHz slower then expected 00.46.59 # does it have a proper lcd_update_rect already? 00.47.05 # Yes 00.47.16 # should i do some tests by actually clocking it down to 40MHz and trying to play back MP3? 00.47.40 # i don't think that would tell us much 00.48.23 # how are iram latencies for that 940T? 00.48.33 # implementation dependent 00.48.43 # maybe disabling icache/dcache for IRAM could improve performance? 00.48.51 Quit ender` (" Progress isn't made by early risers. It's made by lazy men trying to find easier ways to do something. -- Robert A. Heinlei") 00.48.58 # on previous targets it hurts performance 00.49.36 # let's play around. 00.49.41 # plus the AAC+ results suggest that its not a purely IRAM problem since that format uses very little IRAM 00.49.43 Quit tomers (Read error: 113 (No route to host)) 00.50.22 # * TheSeven suggests measurements with WAV files to check if there's some CPU hog in the PCM code 00.50.30 Quit shotofadds ("Leaving") 00.50.51 # These tests were with the test_codec plugin, which just decodes audio and discards the output. 00.50.52 # could it be the bus clocking scheme? like fastbus vs. sync vs. async? 00.51.31 # we're running async 00.51.51 # MP3 is all IRAM and is 25% slower, AAC+ is very little IRAM and roughly the same percent slower 00.52.03 # from that 940t specsheet it looks like async vs. sync isn't any penalty 00.52.22 # on AMS there is a small penalty IIRC due to needing to sync data across the two 00.52.28 # but it was extremely small 00.52.49 # we could try sync at 192MHz instead of async at 200MHz 00.53.20 # although AMS was always slower then I expected 00.53.30 # for some reason it seemed like IRAM was artificially slow 00.54.16 # i think it will be funny if PP of all things ends up being the fastest ARM target per clock (a meaningless metric of course) 00.55.24 Join MethoS- [0] (n=clemens@134.102.106.250) 00.57.58 # gevaerts: what are the usb_send functions supposed to do if there is already a transfer running on the specified endpoint? 01.00.07 Quit liar|netbook (Read error: 148 (No route to host)) 01.00.46 # do we prefer a) typdef, b) typeof, c) a define, or d) wobbly duplication of a datatype? 01.01.08 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 01.01.53 # kugel: What's the context? 01.02.40 Nick fxb is now known as fxb__ (n=felixbru@85.214.97.64) 01.03.04 # struct foo has a function pointer type (returning bool, taking two pointers), I need that very type in struct bar too 01.03.59 # http://pastie.org/652225 is what it's about 01.04.06 Join TrollKing [0] (n=chatzill@98.192.1.183) 01.04.49 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 01.05.20 # we should make a rockbox mp3 player 01.05.36 # I don't have any strong opinions, but I would probably just duplicate the definition. At least it's then clearer to a reader what it is, without needing to refer elsewhere. 01.05.39 # maybe even one in the shape of a giant pod 01.07.00 # TrollKing: what about the lyre? 01.07.04 # linuxstb: I consider this as the worst solution :/ 01.07.23 # kugel: Why? Is that function likely to change? 01.07.25 # pods are better 01.07.37 # you never know 01.07.40 # an eggshaped mp3 player you have to hold with both hands 01.07.51 # 1tb of space, 100 hours of playback 01.08.00 # I rather not give expectations on whether code changes or not 01.08.19 # with the sound quality of $100-200 computer sound cards 01.08.36 # But that's not really my point. I just don't like hiding things. But as I said, I don't feel strongly, so do whatever... 01.08.44 # TrollKing: and of course integrated hifi speakers 01.08.56 # but this should really go to #rockbox-community 01.09.08 # ok i wanted to ask one rockbox question 01.09.36 # there's a computer media player that buffers the entire album to ram, if i had an mp3 player with 1gb of ram, would it be too energy costly to do that? 01.10.06 # would there be any point in doing that? 01.10.15 # I think the issue is less energy than price 01.10.39 # supposedly when you use a computer you can buffer a full album into ram to cause less I/O intereference 01.10.49 # from constantly moving files from the hard drive 01.11.04 # "constantly" ? 01.11.36 # * TheSeven wonders who wrote the TCC USB driver 01.11.51 # it's disabling interrupts in lots of places where it's absolutely unneeded 01.12.06 # Rockbox buffers as much as it can to RAM. If you're using a lossy format like MP3 at a relatively low bitrate, then most of an album will fit into the 32MB of RAM most of our targets has. 01.12.32 # I use a virtual drive in RAM (RAM Disk) to load my CD, how does cMP improve on this? Memory playback is achieved via the system cache and not through a simulated virtual drive. Using the system cache removes Windows disk I/O overheads (irrespective of whether disk is physical or virtual). This is more optimal. 01.12.45 # cool linux 01.12.48 Join efyx_ [0] (n=efyx@lap34-1-82-225-185-146.fbx.proxad.net) 01.12.53 # linuxstb: I'll just drop the second struct and use a union instead 01.13.36 # that bool is going to be 4 bytes anyway 01.13.51 # i want to make a mini pc with some sound card as a giant mp3 player and use rockbox then 01.14.03 # i think rockbox may even be better than cmp and cplay 01.14.11 # * TheSeven would rather suggest using a different OS for that 01.14.20 # better on which aspect? 01.14.26 # rockbox os is probably better 01.14.40 # better as in less inefficient software 01.14.53 # with cplay+cmp you still have a few windows processes running 01.15.06 # what do you need efficiency for with such an oversized system? 01.15.07 # it disables explorer.exe and other stuff but still has to use some 01.15.22 # i want to make a mini notebook mp3 player 01.15.26 # in the hsape of a pod 01.15.32 # or a beaver 01.15.44 # and rockbox it 01.16.04 # bertrik: what do we do about your patch? 01.16.14 Quit bertrik (Read error: 113 (No route to host)) 01.16.34 Quit n1s ("Lämnar") 01.16.50 Quit flydutch ("/* empty */") 01.23.51 Join undersys [0] (n=remote@ppp217-100.static.internode.on.net) 01.24.07 Quit Thundercloud (Remote closed the connection) 01.25.12 Quit notlistening (Read error: 60 (Operation timed out)) 01.28.35 Quit MethoS- (Remote closed the connection) 01.29.40 Join midgey [0] (n=tjross@141-211-4-063.vpn.umnet.umich.edu) 01.29.49 Quit Strife89 (Read error: 104 (Connection reset by peer)) 01.30.17 Join Strife89 [0] (n=michael@adsl-220-108-49.mcn.bellsouth.net) 01.33.46 Join togetic [0] (n=togetic@unaffiliated/ibuffy) 01.34.43 Join z35 [0] (n=z35@ool-45717f0e.dyn.optonline.net) 01.35.55 Join dfkt_ [0] (i=dfkt@unaffiliated/dfkt) 01.37.03 Quit dfkt (Nick collision from services.) 01.37.06 Nick dfkt_ is now known as dfkt (i=dfkt@unaffiliated/dfkt) 01.37.26 Quit robin0800 (Remote closed the connection) 01.37.51 Quit efyx_ (Remote closed the connection) 01.39.59 Quit mcuelenaere () 01.43.47 Quit TrollKing ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]") 01.44.32 Join ShapeShifter499 [0] (n=chatzill@adsl-69-105-84-31.dsl.scrm01.pacbell.net) 01.45.09 # saratoga: The beast is certainly faster per-clock than any PP 01.45.22 # linuxstb: Did you test APE performance on the nano2g? 01.45.35 # No, not yet. 01.46.55 # What arm core is used in the S5L8701? 01.46.56 Part toffe82 01.47.13 # Are we compiling for the correct ARM_ARCH? 01.47.35 # It's 940T I think 01.48.58 # yes 01.49.31 # Hmm, so only v4, ok 01.50.04 # Plus it has a "CalmADM2E (130MHz) CALMRISC16+MAC2424 with 4KB instruction cache, 6KB Y cache and 6KB X cache" 01.50.54 # (or at least, that's what the S5L8700 datasheet says...) 01.51.08 # linuxstb: we haven't yet checked if that thing even exists at all 01.51.22 # Performance should be very similar to gigabeat F (scaled due to clock differences) then 01.51.45 # Gigabeat F is ARM920T - the core & caches are identical iiuc 01.52.04 # TheSeven: True. It wouldn't surprise me if it was missing... 01.52.08 # linuxstb: Eww, calmrisc of all things.... 01.52.30 # 16 bit arch and pure harvard architecture 01.54.36 Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) 01.55.17 # * amiconn scratches head 01.56.07 # Comparing APE performance for Gigabeat F and Sansa Clip http://www.rockbox.org/wiki/SoundCodecMonkeysAudio tells me that one of the stated clock frequencies is wrong 01.57.02 # The figures scale ideally from -c1000 to -c4000; -c5000 being slower on AS3525 is due to it having only half the cache 01.57.33 Quit faemir ("Leaving") 01.58.12 # AMS experts / gigabeat F experts: any comments? 01.59.25 Join dfkt_ [0] (n=dfkt@unaffiliated/dfkt) 02.01.01 Quit dfkt (Nick collision from services.) 02.01.03 Nick dfkt_ is now known as dfkt (n=dfkt@unaffiliated/dfkt) 02.01.17 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 02.04.05 # amiconn, I do not believe the gigabeat F frequency is wrong 02.05.25 # I checked it at some point to verify the pll settings unless the reference clock was wrong, but I think there is a standard recommended frequency for the ref clock on the 2440 02.06.15 # the gigabeat F doesn't have any iram that is used- I'm not sure if that's different for the ams 02.07.08 # * TheSeven is compiling a build with USB support... 02.07.41 # not that I would expect anything to work at all, but wish me luck nevertheless :-) 02.12.36 Quit LambdaCalculus37 ("Fwump") 02.13.16 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 02.14.58 Join AndyI [0] (n=pasha_in@212.14.205.32) 02.20.50 Quit Stephen__ ("Leaving") 02.24.09 *** Saving seen data "./dancer.seen" 02.24.27 Join midgey_ [0] (n=tjross@141-211-4-161.vpn.umnet.umich.edu) 02.26.22 Quit AndyIL (Read error: 110 (Connection timed out)) 02.29.22 Quit midgey (Read error: 110 (Connection timed out)) 02.29.22 Nick midgey_ is now known as midgey (n=tjross@rockbox/developer/midgey) 02.29.42 # bah. rockbox is crashing as soon as I connect USB 02.33.29 Quit robin0800 (Remote closed the connection) 02.38.54 # * TheSeven will give up for tonight... and still wonders why charger_inserted() is returning correct results, but the backlight timer is doing nonsense 02.41.38 # amiconn: i don't follow ? 02.46.19 Quit nosa- ("lol") 02.51.38 Quit fdinel (Read error: 110 (Connection timed out)) 02.58.11 Quit amiconn (Nick collision from services.) 02.58.12 Quit pixelma (Nick collision from services.) 02.58.13 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 02.58.14 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 02.58.45 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 02.58.45 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 03.03.08 Quit Strife89 (Read error: 104 (Connection reset by peer)) 03.03.31 Join Strife89 [0] (n=michael@adsl-220-108-49.mcn.bellsouth.net) 03.05.15 # phew, new statusbar patch up 03.05.28 # I redid the multi aa thing, it's abit simpler now 03.07.24 Nick Ypsy is now known as YPSY (n=ypsy@87.106.45.183) 03.07.29 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 03.08.46 Quit togetic (Read error: 110 (Connection timed out)) 03.15.47 Quit kkurbjunW (Remote closed the connection) 03.16.42 Join kkurbjunW [0] (n=karlk@12.41.166.9) 03.32.51 Quit kugel (Remote closed the connection) 03.33.20 Join toffe82 [0] (n=chatzill@ppp-71-130-79-58.dsl.frs2ca.pacbell.net) 03.43.20 Join togetic [0] (n=togetic@unaffiliated/ibuffy) 03.47.29 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 03.47.39 # ~ sweet ~ 03.48.12 # i tihnk i've been mostly awake for 36 odd hours now 03.49.35 Quit midgey (Read error: 104 (Connection reset by peer)) 03.53.47 Join midgey|web [0] (i=8dd5374b@gateway/web/freenode/x-yasjbfmdfjfrsxws) 03.56.12 Join evilnick [0] (n=evilnick@rockbox/staff/evilnick) 04.00.49 Quit Strife89 ("Bed.") 04.05.34 Quit TheSeven (Nick collision from services.) 04.05.53 Join The_Seven [0] (n=theseven@rockbox/developer/TheSeven) 04.06.04 Nick The_Seven is now known as TheSeven (n=theseven@rockbox/developer/TheSeven) 04.19.40 Quit ysae ("getting some sleep") 04.19.42 Quit pjm0616 (verne.freenode.net irc.freenode.net) 04.19.42 NSplit verne.freenode.net irc.freenode.net 04.20.04 NHeal verne.freenode.net irc.freenode.net 04.20.04 NJoin pjm0616 [0] (n=user@61.250.113.98) 04.20.13 Join BagderTN [0] (n=189e9a70@giant.haxx.se) 04.22.38 Join CaptainKewl [0] (n=jason@pool-138-88-158-134.esr.east.verizon.net) 04.24.11 *** Saving seen data "./dancer.seen" 04.30.10 Quit togetic (Read error: 110 (Connection timed out)) 04.36.00 Join togetic [0] (n=togetic@unaffiliated/ibuffy) 04.38.13 Quit Rondom (Nick collision from services.) 04.38.23 Join Rondom [0] (n=Rondom@84.57.190.255) 04.43.13 Nick intrados2 is now known as intrados (n=intrados@cpe-75-187-57-252.columbus.res.rr.com) 05.00.14 Join saratogalab [0] (n=9803c264@giant.haxx.se) 05.37.41 Quit midgey|web ("Page closed") 05.48.43 Quit Horscht ("Verlassend") 05.50.12 Part toffe82 05.53.24 Join elinenbe_ [0] (n=elinenbe@207-237-212-81.c3-0.80w-ubr4.nyr-80w.ny.cable.rcn.com) 05.53.24 Quit elinenbe (Read error: 104 (Connection reset by peer)) 05.53.29 Nick elinenbe_ is now known as elinenbe (n=elinenbe@207-237-212-81.c3-0.80w-ubr4.nyr-80w.ny.cable.rcn.com) 05.56.10 Quit saratogalab ("CGI:IRC (EOF)") 06.00.16 Quit BagderTN ("CGI:IRC (EOF)") 06.16.18 Join Rand_Althor [0] (n=chatzill@adsl-76-235-51-97.dsl.dytnoh.sbcglobal.net) 06.17.16 # have any programmers ever considered adding FLAC as a recording format? If so is it ever likely? 06.20.05 # Rand_Althor: I haven't seen an integer flac encoder 06.20.15 # if one exists that would make it significantly easier to add 06.20.32 # ah. ok 06.21.15 # actually according to the flac website you can do integer flac encoding but its somewhat less efficient due to disabled features 06.21.25 # so i guess its at least in theory possible 06.22.17 # hmm 06.24.13 *** Saving seen data "./dancer.seen" 06.24.44 Quit Rand_Althor ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]") 06.30.31 Quit elinenbe (Read error: 60 (Operation timed out)) 06.30.37 Quit saratoga ("Page closed") 06.39.08 Join tomers [0] (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) 06.49.50 Quit panni_ (Read error: 104 (Connection reset by peer)) 07.03.43 Quit lifeless_ ("Ex-Chat") 07.14.42 Quit kkurbjunW (Remote closed the connection) 07.15.02 Join kkurbjunW [0] (n=karlk@12.41.166.8) 07.25.56 Join lifeless_ [0] (n=lifeless@90.151.210.76) 07.28.09 Join DerPapst [0] (n=DerPapst@p4FE8F9EA.dip.t-dialin.net) 07.33.00 Quit lifeless_ ("Ex-Chat") 07.33.35 Join lifeless_ [0] (n=lifeless@90.151.210.76) 07.36.21 Join stoffel [0] (n=quassel@p57B4F58D.dip.t-dialin.net) 07.37.18 Quit DerPapst ("Leaving.") 07.39.22 Join LinusN [0] (n=linus@rockbox/developer/LinusN) 07.42.23 Quit lifeless_ ("Ex-Chat") 07.48.16 Join lifeless_ [0] (n=lifeless@90.151.210.76) 07.49.07 Quit lifeless_ (Client Quit) 07.49.34 Join lifeless_ [0] (n=lifeless@90.151.210.76) 08.24.17 *** Saving seen data "./dancer.seen" 08.24.51 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.24.57 Quit stoffel (Remote closed the connection) 08.30.46 Join Rob2223 [0] (n=Miranda@p4FDCD927.dip.t-dialin.net) 08.42.29 Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) 08.45.28 Quit Rob2222 (Read error: 110 (Connection timed out)) 08.45.53 Quit tomers (Read error: 113 (No route to host)) 08.48.23 Join pcc1 [0] (n=peter@master.pcc.me.uk) 08.58.28 Join Thundercloud [0] (i=thunderc@81.187.69.84) 09.03.42 Join petur [50] (n=petur@rockbox/developer/petur) 09.23.53 Join maruk [0] (n=papier@titanium.sdv.fr) 09.32.15 Part linuxstb ("Leaving") 09.45.57 Quit Thundercloud (Remote closed the connection) 09.48.24 Join DerPapst [0] (n=DerPapst@wlan-nat-24.fh-friedberg.de) 09.56.00 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 09.58.29 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 10.03.00 # New commit by 03dave (r23142): ipodpatcher and rbutil support for the Nano2G - FS#10609 with a few further changes. 10.03.56 Quit DerPapst ("Leaving.") 10.04.54 # New commit by 03dave (r23143): Don't touch the clocks in Nano2G bootloader - this breaks the Apple firmware (audio playback didn't work). 10.06.42 Quit sbhsu (Read error: 60 (Operation timed out)) 10.10.14 Join sbhsu [0] (n=a6530466@192.192.120.197) 10.12.19 # New commit by 03dave (r23144): Tag release 4.0 of ipodpatcher, including v1.0 of the Nano2G bootloader. The actual bootloaders included for PP ipods are v3.0 - from the tag ... 10.13.57 # Zagor: Can you put http://linuxstb.cream.org/rockbox/bootloader-nano2g.ipodx on the download server (/bootloader/ipod/) and also add it into the "bootloaders.zip" file in that directory? 10.14.07 # sure 10.14.32 # I'll have a new ipodpatcher soon... 10.14.55 # TheSeven: if a function driver sends a transfer on a busy endpoint, feel free to panic 10.14.57 # should it be called that, or renamed to bootloader-ipodnano2g.ipod ? 10.15.04 # It's called that. 10.15.28 # ".ipod" is the convention for unencrypted firmware files (like the old ipods), and ".ipodx" is encrypted. 10.15.44 # right, but what about the basename? it doesn't match the other files in the dir 10.15.54 # such as bootloader-ipodnano.ipod 10.15.57 # Oops, sorry - it should be ipodnano2g 10.16.02 # ok 10.16.11 # The URL I mentioned shouldn't exist... 10.16.46 # neither does http://linuxstb.cream.org/rockbox/bootloader-ipodnano2g.ipodx 10.17.21 # Zagor: Sorry, it does now. 10.17.39 # 48d1a56168223222f2f2a6edaefad9e1 bootloader-ipodnano2g.ipodx 10.17.52 # yup 10.18.25 # added now 10.19.06 # Thanks. Will you be around for the next 30 minutes or so? 10.19.14 # yes 10.20.00 # OK, thanks. 10.20.46 Join liar|netbook [0] (n=liar@213162066157.public.t-mobile.at) 10.21.21 Join barrywardell [0] (n=barrywar@rockbox/developer/barrywardell) 10.24.21 *** Saving seen data "./dancer.seen" 10.24.39 # regarding targets with internal nand, should we perhaps make an option to store temporary files on an external card? it would make such targets usable sooner 10.32.55 Quit liar|netbook (Read error: 60 (Operation timed out)) 10.33.35 # Zagor: http://linuxstb.cream.org/rockbox/ipodpatcher-4.0.tgz - can you do "mkdir 3.0 && mv ipodpatcher 3.0/" and then untar that .tgz to create a new ipodpatcher dir? 10.34.31 # And I guess you might want to copy all of the bootloader-ipod*.ipod files into that new 3.0 directory as well. (even though they are the same for 3.0 and 4.0 ipodpatcher for the older ipods) 10.38.42 # do we need to save old versions? 10.39.23 # "better safe than sorry" ? 10.39.30 Join liar|netbook [0] (n=liar@212067224132.public.telering.at) 10.43.06 # Anyone have any objections to the Nano2G being promoted to "Unstable" ? 10.45.04 # does anyone have an idea why USB properly detects whether the cable is connected or not (via charger_inserted()) but the backlight timer doesn't? 10.45.18 # linuxstb: what button boots nano2g to OF ? 10.45.27 Join lucent [0] (i=lucent@unaffiliated/shadows) 10.45.49 # The hold switch 10.46.32 # wow, my nano was playing music all night (8 hours) and is still at 3.95V 10.46.49 # Did you forget to unplug it? ;) 10.47.29 Join n1s [0] (n=n1s@rockbox/developer/n1s) 10.48.03 # i don't remember how to shut down from the OF :) 10.48.20 # You can't... 10.48.24 # i just tried your latest patcher/bootloader versions and it all works fine on my 2GB nano 2G 10.48.29 # You have to reset = MENU+SELECT 10.48.43 # yup 10.48.47 # back to pretty rockbox 10.49.18 # rockbox info still believes it's charging despite not being hooked up to the usb cable 10.49.26 # r23141 10.50.24 # topik: does it always believe it's charging? mine somethimes thinks it's charging and sometimes not, but I can't see any correlation to what's actually plugged :-) 10.51.05 # Could that be when it's fully charged? 10.51.11 # TheSeven: mine also believes it's charging. 10.51.18 # it always says charging 10.51.43 # Zagor: I've one last file for today - http://linuxstb.cream.org/nano2g/mbr-nano2g-2GB.bin 10.51.49 # linuxstb: and it's not full. 10.52.04 Join wincent [0] (n=wincent@f048113038.adsl.alicedsl.de) 10.52.22 # battery says it is at 4.191 10.52.52 # which is pretty much full 10.52.58 # battery 3.904 10.53.20 Quit liar|netbook (Read error: 60 (Operation timed out)) 10.56.14 # linuxstb: done 10.56.26 # Zagor: Thanks. 10.56.31 # shame my hold button is broken 10.57.34 Join Dgby714 [0] (n=Dgby714@pool-173-78-91-222.tampfl.fios.verizon.net) 10.58.15 # then again, no point to ever visit the OF again 11.01.06 # Dgby714: You wanted write access to the wiki? What's your wiki name? 11.01.26 # JohnP 11.01.30 # i was reading the guidelines... 11.01.40 # Yes, you'll need to re-register.... 11.02.53 # topik: try iLoader http://l4n.clustur.com/index.php/ILoader_Howto. 11.03.58 # New commit by 03dave (r23145): Move Nano2G up a category to Unstable - it now has installation support in the newly released ipodpatcher v4.0. 11.04.42 # Zagor: Sorry, another ping.... Can you update the front page? 11.04.53 # New commit by 03theseven (r23146): Fix iPod Nano 2G charging detection 11.05.13 # done 11.06.00 # wow the nano2g port has progressed really fast, great work guys :) 11.06.00 Join lennyk [0] (n=lennyk@dynamic2-254-138.usc.edu) 11.06.15 # it proves hard to keep up with TheSeven :) 11.06.20 # Zagor: Thanks. Also, http://www.rockbox.org/wiki/System/UserRegistration doesn't seem to have the real name policy any more... 11.06.41 # maruk: what am i trying iloader for? 11.07.09 # Zagor: while you're here, should the "since3.3" link on the frontpage under the svn table be changed to since3.4 maybe? 11.07.10 # linuxstb: no, but http://www.rockbox.org/wiki/UserRegistration does. from where did you get the System link? 11.07.19 # n1s: indeed 11.07.38 # Zagor: From the top of here - http://www.rockbox.org/wiki/WebHome 11.07.58 # topik: I think that was just a hint that iLoader won't need a working hold switch 11.08.18 # topik: iLoader is another bootloader for nano2g. It does not use hold to select the firmware.... 11.08.24 # linuxstb: thanks. fixed now. 11.08.41 # ah ok. my nano is not stuck on hold. the switch is brokenish so it doesn't connect when moved to hold most of the time 11.08.45 # thanks for the suggestions 11.08.57 Quit JackWinter4 (Read error: 110 (Connection timed out)) 11.09.43 # linuxstb: JohnPeel 11.12.03 # New commit by 03zagor (r23147): Updated svn link 'since 3.3' to 3.4 11.12.40 Join JackWinter4 [0] (n=jack@vodsl-10804.vo.lu) 11.15.02 Quit kkurbjunW (Remote closed the connection) 11.15.49 Join kkurbjunW [0] (n=karlk@12.41.166.9) 11.16.01 # * TheSeven wonders what's making my ipod crash as soon as usb_detect() returns USB_INSERTED, even if the usb driver is just doing nothing (not even initializing the USB core) 11.19.38 # seems nano 2g charges in a hurry 11.19.51 # Dgby714: You should now have write access. 11.19.57 # thanks 11.20.15 # linuxstb: in which file was your "reboot to disk mode on usb connection" code? 11.20.31 # usb-s5l8700.c 11.20.44 # hmm, that file shouldn't be included at all 11.20.59 # did you re-commit it? 11.20.59 # Why not? 11.21.03 # No 11.21.13 # ok, so that's not what's fooling me at least 11.21.33 # There's a #USE_ROCKBOX_USB define or similar, which you should use to enable/disable your USB code until it's stable enough for users. 11.22.06 # But I think I should recommit that USB code - it's how Rockbox works on the other ipods. 11.23.10 # my current problem is that something decides to crash or reboot (not sure) as soon as i plug USB, even with the USB code disabled, as soon as usb_detect returns USB_INSERTED 11.23.34 # New commit by 03dave (r23148): Re-commit r23070 - reboot to disk mode on the Nano2G when USB is inserted. This was accidentally reverted in r23099 11.25.18 # TheSeven: I'm lost in the maze of different USB defines... 11.25.25 # Access check on Main.JohnPeel failed. Action "CHANGE": access not allowed on web 11.26.26 # Dgby714: I don't know... I added you to WikiUsersGroup, which should be enough. Zagor? 11.28.16 # Dgby714: which page are you trying to edit? 11.28.38 # New commit by 03dave (r23149): Oops, forgot to remove Nano2G from Unusable 11.28.38 # JohnPeel mine.. 11.28.56 # Zagor: Another index.t change... 11.29.12 # Dgby714: looks like you are logged in as JohnP 11.29.31 # hmm.. how do i logout? 11.29.49 # I think you have to close your browser. 11.29.52 # Dgby714: restart your browser 11.30.12 # linuxstb: done 11.41.03 Quit r00s (Read error: 60 (Operation timed out)) 11.42.01 # * linuxstb adds some installation instructions to IPodNano2GPort and thinks we're done for now... 11.44.45 Join r00s [0] (n=ru@zentrale.profitables.biz) 11.45.20 # congrats linuxstb and TheSeven 11.45.24 # really impressive 11.45.46 # * TheSeven is entirely confused now 11.46.13 # for some reason all GPIOs are reading 0xFF 11.48.21 Join daurn| [0] (n=daurnima@freenode/staff/daurnimator) 11.51.42 # bah. something's masking the GPIO clock!? 11.55.34 # WTF. Something's calling system_reboot() when I plug USB. 12.00.32 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 12.02.15 # TheSeven: Current svn will do that (now that I've restored usb-s5l8700.c). Unless your reboot is something else... 12.02.57 # i haven't updated to your revision yet 12.03.07 # and i don't even have that file in my SOURCES any more 12.03.19 # I didn't think so... 12.03.41 # BTW, I think now that we are a more official port, we need to be careful about breaking SVN... ;) 12.03.49 # * linuxstb recalls the NAND problems 12.04.12 # I suspect usb.c:112 12.04.48 Quit daurn (Read error: 110 (Connection timed out)) 12.06.04 Quit barrywardell (Read error: 60 (Operation timed out)) 12.07.15 # New commit by 03theseven (r23150): Fixed a confusing typo 12.13.56 Quit KBH (Read error: 104 (Connection reset by peer)) 12.15.11 Join KBH [0] (i=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 12.15.41 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 12.19.14 # gevaerts: could usb_enable be called from an IRQ? I need a sleep in there and it's locking up. 12.21.42 Join AlexP [0] (n=86ceaf40@rockbox/staff/AlexP) 12.24.23 *** Saving seen data "./dancer.seen" 12.32.27 # hm, not sure 12.35.01 Nick fxb__ is now known as fxb (n=felixbru@85.214.97.64) 12.42.03 Join MethoS- [0] (n=clemens@134.102.106.250) 12.42.56 # * TheSeven shouts at his OTG 12.43.04 # it just won't ACK a reset 13.03.40 Join notlistening [0] (n=tom@94-195-105-95.zone9.bethere.co.uk) 13.05.09 # fyi, i just did some measurements, and the nano is running at 192, not 200, mhz 13.07.52 # calculated osc freq: 1,846153 MHz 13.08.02 # is there any standard osc freq in that range? 13.13.07 Join DerPapst [0] (n=DerPapst@79.232.239.237) 13.13.44 # nano 2g gives a fair 'pop' sound when it starts rockbox and reaches the main menu 13.14.39 Nick JackWinter4 is now known as JackWinter (n=jack@vodsl-10804.vo.lu) 13.15.44 # yeah 13.24.26 Join krooney [0] (n=59f18a06@giant.haxx.se) 13.24.33 Join lifeless__ [0] (n=lifeless@90.151.216.8) 13.24.54 # http://forums.rockbox.org/index.php?topic=22925.0 could anyone help with this post please 13.27.51 Quit ShapeShifter499 (Read error: 110 (Connection timed out)) 13.30.45 # doesn't apple have a pop sound, too, even if it's not that bad? 13.31.02 # yay! windows just told me it found a misbehaving usb device! 13.31.14 # so the PHY is up and running... 13.31.24 Join ShapeShifter499 [0] (n=chatzill@adsl-68-122-191-88.dsl.scrm01.pacbell.net) 13.31.48 # TheSeven: linux has much more detailed messages for these things 13.31.57 # i know 13.32.02 # and lsusb helpfully hangs under certain circumstances 13.32.03 # ok 13.32.21 Quit lifeless_ (Read error: 145 (Connection timed out)) 13.32.52 # TheSeven: \o/ 13.32.56 # funny. not even "device doesn't accept new address ..." 13.33.03 # so we're already past that stage? 13.33.12 # * linuxstb doesn't know 13.33.14 # [ 9784.180041] usb 2-1: new full speed USB device using uhci_hcd and address 2 13.33.19 # and lsusb hangs, as always 13.33.52 # * TheSeven needs to quickly set up libpcap and wireshark on that box 13.35.55 # tcpdump should work with kernel support 13.37.20 Quit notlistening ("Leaving") 13.37.58 # karmic wireshark should already have USB support, but libpcap doesn't 13.38.22 # * linuxstb wonders where the Rockbox hardware USB sniffer is, in case it's useful 13.38.54 # JdGordon has it 13.39.06 # what device is this, nano2g? 13.39.46 # tmzt: Yes, TheSeven is working on nano2g USB 13.39.59 # ok, still no work on ams usb support? 13.40.28 Join solar_sea [0] (n=chatzill@85.14.14.82) 13.40.35 # * linuxstb doesn't know 13.41.36 # send all your troubled devices to TheSeven 13.41.36 # an old twiki article about some sansa player says that rockbox supports the TPG06292 fm radio chip 13.41.53 # was this implemented from scratch or taken from somewhere ? 13.42.51 # solar_sea: You could look at the actual code (in firmware/drivers/tuner/ I think) and see what the comments there say. 13.43.15 # linuxstb: thanks, will do that 13.44.21 # ok, fine, wireshark up and running 13.44.49 # oes anyone know of a utility i can use on windows to access my gigabeat hard drive, when the thing wont load cause it keeps saying firmware updated 13.44.54 # does* 13.45.28 # karmic procedure: sudo apt-get install build-essential wireshark flex bison, pull the libpcab git, ./configure && make && make install, sudo wireshark& 13.48.32 # krooney: have you seen http://www.rockbox.org/wiki/GigabeatFXPort#Gigabeat_Recovery_Procedures ? 13.48.56 # krooney: Which gigabeat? 13.49.07 # linuxstb: where do I download the source for rockbox, all that I find at the main page are releases for specific players 13.49.20 # solar_sea: http://www.rockbox.org/wiki/UsingSVN 13.49.30 # thanks! 13.50.57 # grr. it's responding with all-zero packets 13.51.16 # so probably DMA vs cache yet again 13.52.09 # TheSeven: that's good. It means it's a problem you've got experience with :) 13.52.31 # yes, but i still haven't found a way to fix this without copying over everything 13.52.48 # the problem is that i can't enforce alignment constraints on the buffers i get passed 13.54.09 # (and even with copying everything it's pretty tricky) 13.54.18 # if alignment helps to find out what's going on, all initial USB data use response_data in usb_core.c so aligning that should be easy, and MSC always aligns everything on 32 bytes 13.54.59 # Can you try testing with caches disabled? 13.55.04 # can i be sure that also it's end is aligned? e.g. there's nothing packed into the tail of the last cache line? 13.55.19 # (or all buffer sizes in MSC are multiples of 16) 13.56.36 # transfer sizes may not be aligned, but all MSC transfers share the same buffer that's guaranteed to not be used for anything else while USB is active (it steals the entire audio buffer) 13.56.58 Join pamaury [0] (n=pamaury@140.77.26.46) 13.59.11 Join roolku [0] (n=roolku@77-99-223-115.cable.ubr16.sgyl.blueyonder.co.uk) 13.59.17 Join Rand_Althor [0] (n=chatzill@adsl-76-235-51-97.dsl.dytnoh.sbcglobal.net) 13.59.50 # can I check my battery charge level while it's connected to the computer? 14.00.26 # What is "it" ? 14.00.40 # e200 14.00.52 # New commit by 03roolku (r23151): brickmania: There are only 9 powerups 14.00.59 Quit intrados (Connection timed out) 14.01.00 Join elinenbe [0] (n=elinenbe@207-237-212-81.c3-0.80w-ubr4.nyr-80w.ny.cable.rcn.com) 14.01.07 # oh sorry - the player 14.01.14 Quit ShapeShifter499 (Read error: 110 (Connection timed out)) 14.02.03 # The normal status bar doesn't appear at the top of the screen? 14.03.15 # yeah, but it reads "93" then when i disconnect it's "81" 14.03.21 Quit antil33t (Read error: 131 (Connection reset by peer)) 14.03.41 Join antil33t [0] (n=Mudkips@119.224.12.185) 14.04.27 # linuxstb, saratoga: My nano can't even decode MP3 realtime with caches disabled!? 14.04.28 # * linuxstb doesn't know the details of the e20 14.04.51 # shouldn't hurt too much as it's in iram anyways, huh? 14.05.12 # That does seem wrong... 14.05.31 # it's ~20% realtime, which just can't be right 14.05.41 # TheSeven: it's an ARM9, right? 14.05.47 # 940T 14.05.50 # that doesn't seem too surprising to me i'm afraid 14.06.03 # is it's IRAM that slow? 14.06.04 # are you turning the icache off too? 14.06.12 # yes 14.06.19 # yeah. that stalls the hell out of the pipeline 14.06.25 # fetches are absurdly delayed 14.06.29 # er, instruction fetches 14.06.38 # Torne: So is there any point in using it? i.e. could just using DRAM be better? 14.07.14 # an interesting question 14.07.23 # generally you want to hope that your icache hit rate is 90%+ 14.07.25 # * TheSeven will retry with icache on but dcache off 14.07.36 # at which point there's maybe no point in having code in iram, indeed 14.07.43 # but keeping data in iram is probably a solid win regardless 14.08.27 # i guess you don't know the timings for iram 14.08.35 # or do you? (waitstates etc) 14.08.41 Quit Rand_Althor ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]") 14.10.47 # icache on, dcache off is easily realtime 14.12.44 # Yah 14.13.05 # It's hard to measure it on production hardware but I would randomly guess that the mp3 decoder's inner loop probably has a 90-95% icache hit rate if not better 14.13.24 # and unless the iram is 0 wait states (which is unlikely these days) then it's hard for it to compete with that 14.13.29 Join flydutch [0] (n=flydutch@host77-167-dynamic.15-87-r.retail.telecomitalia.it) 14.16.48 # i forget how many stages the ARM9 pipelines are but it's "more than 5" 14.17.01 # icache misses mean horrible stalls :) 14.21.30 Quit lucent (Read error: 145 (Connection timed out)) 14.24.10 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 14.24.24 *** Saving seen data "./dancer.seen" 14.26.19 Part aidy 14.26.59 Join kugel [0] (n=kugel@rockbox/developer/kugel) 14.27.21 # TheSeven: that'S about the same figures we got on the samsas 14.28.00 # would be interesting to know if ICODE does make any sense then 14.28.07 Quit krooney ("CGI:IRC (EOF)") 14.28.13 # or if one should rather push some data buffers into IRAM 14.29.33 Join funman [0] (n=fun@rockbox/developer/funman) 14.31.29 # TheSeven: you can copy all buffers into aligned and uncached memory 14.31.46 # if it's uncached you are sure nothing is left in the cache 14.32.06 Join panni_ [0] (i=hannes@95.222.21.143) 14.33.00 # TheSeven: is it just codecs that push stuff into icode? 14.33.15 # i mean, it doesn't *hurt* for stuff to be in iram, obviously 14.33.36 # but if there's data that's not in iram then i would guess it's definately worth trying switching it around 14.37.40 # can i somehow view logf while connected to usb? 14.37.56 # code mostly gets read in order, and even for branches ARM9 has static prediction, so it's easy for the icache to be right 14.38.50 Quit solar_sea (Read error: 104 (Connection reset by peer)) 14.39.00 # TheSeven: uncomment #define USB_ENABLE_SERIAL in config.h ? 14.39.24 # funman: That probably won't help if he wants to debug usb 14.47.07 Quit bubsy (Read error: 54 (Connection reset by peer)) 14.48.07 # funman: will you retag mkamsboot? 14.48.32 # no 14.48.52 # why? 14.49.43 # Did you read http://www.rockbox.org/mail/archive/rockbox-dev-archive-2009-10/0054.shtml ? 14.50.26 # yes 14.50.50 # I ask you to redo the tag you have removed 14.51.55 # and I told you I'm done with mkamsboot in the other email 14.53.15 Join teru [0] (n=teru@KD059133112132.ppp.dion.ne.jp) 14.54.45 # please bring back what you have undone 14.57.19 # you clearly said it's your area, I don't want to touch it anymore 14.58.33 # i don't mind your childish reaction, i do mind if you don't restore what you broke 15.00.44 # alright, one last time then (aka piece!) 15.00.51 # peace* 15.03.00 # TheSeven: I assume you have a UART cable? Rockbox supports logf-over-serial on other devices. 15.03.17 # (or maybe it's DEBUGF...) 15.04.42 # funman: with or without linuxstb's APPVERSION change? 15.04.54 # doesn't matter 15.05.09 # before the addition of new fuze of however 15.05.44 # kugel: Maybe nicer to include it. I want to create something like a "BootloaderReleaseHistory" page to document when/how bootloaders are released. 15.06.17 # So if even though funman edited that string manually, we could document the release as being built using "make VERSION=1.1" 15.06.38 Quit kkurbjun ("Leaving.") 15.06.39 # (unless such a wiki page already exists - I haven't looked....) 15.13.40 Quit kkurbjunW (Remote closed the connection) 15.14.54 Join kkurbjunW [0] (n=karlk@12.41.166.8) 15.16.10 Join JackWinter2 [0] (n=jack@vodsl-10804.vo.lu) 15.18.25 # linuxstb: in the forum nano2g thread you state that the nano2g has moved to "Unusable" - I think you meant "Unstable" 15.19.33 # mc2739: Thanks - fixed. 15.27.23 Quit kugel (Read error: 145 (Connection timed out)) 15.28.01 Quit JackWinter (Read error: 110 (Connection timed out)) 15.28.26 Join kyle6513 [0] (n=kyle6513@58.174.128.189) 15.28.34 Join liar|netbook [0] (n=liar@213162066159.public.t-mobile.at) 15.32.29 Join intrados [0] (n=intrados@cpe-75-187-57-252.columbus.res.rr.com) 15.42.18 Quit DerPapst ("Leaving.") 15.42.26 # hello, does someone here as a precise knowledge of how dircache works ? I have some questions/critics about how dircache_remove is implemented 15.43.58 # arm/crt0.S uses supervisor mode while we rather should use system mode. supervisor is reserved for software interrupts, so I don't think it's a problem since we do not use them 15.45.35 Quit teru ("Quit") 15.45.59 # ping gevaerts 15.47.21 Quit bmbl (Connection timed out) 15.48.41 # gevaerts: are you there ? 15.48.56 # pamaury: Slasheri implemented dircache... 15.51.21 # on my ipod nano2g there is a bug in the filebrowser(if you press forward it doesnt switch into the selected dir, but it selects the first item in the list), the first time i saw that was in r23110 and the last revision i know without that bug was 23083 15.52.48 # * linuxstb installs the current build to test 15.54.48 # liar|netbook: Seems to be fine for me. If I press and hold "forward" (i.e. a long press), then nothing happens. If I do a short press and release, I go into the dir. 15.55.16 # pamaury: pong 15.55.25 # gevaerts: tic 15.55.30 # :) 15.55.44 # toc? 15.55.55 # tac 15.55.56 # Slasheri: are you there ? 15.56.38 Quit roolku () 15.57.18 # funman: if you never do SWI then it doesn't really matter if you use svc or sys mode really.. everyone got by without sys mode on ARMv3 and earlier :) 15.57.52 # funman: and reset still leaves you in svc mode, so hey. 15.59.25 # funman: in fact if you never use user mode you can stay in svc mode all the time and use swi *anyway*, treating it like a regular bl :) 15.59.44 # linuxstb: is Slasheri the only one who really know the details of dircache implementation ? 16.00.04 # Torne: that's how iBugger is working 16.00.37 # Torne: ok, i was just reading that the 'normal' sd/lr registers are accessible in user and system mode, not supervisor 16.00.41 # sp* 16.01.03 # funman: yes, in svc mode you are using r13_svc and r14_svc. but it doesn't matter. 16.01.24 # the only time you would notice the difference is if you explicitly went and dumped all the banked registers, say with a hardware debugger. 16.01.28 Join esperegu [0] (n=quassel@s559081d2.adsl.wanadoo.nl) 16.01.29 # pamaury: Wait and see if anyone says anything, but I can't recall anyone else touching that code... 16.01.36 # ok 16.02.47 # funman: what the point of system mode is is not very clear, tbh :) 16.02.51 Join sampattuzzi [0] (n=sampattu@88-106-156-149.dynamic.dsl.as9105.com) 16.02.56 Join pyro_maniac [0] (i=foobar@p57BB8AC8.dip0.t-ipconnect.de) 16.03.14 # Where can I find out more about the internal workings of rockbox? Any links? 16.03.19 # it seems to be useless unless you really do want to run what would normally be a user mode thread with supervisor privileges, without breaking the way that swi i shandled 16.03.36 # i.e. if you were still running under a regular kernel with a normal syscall interface. 16.03.37 # funman: what prevents the YH820 to get unstable? 16.04.04 # pyro_maniac: someone needs to say if it's usable (i can't) 16.04.13 # funman: http://forums.rockbox.org/index.php?topic=6135.msg156860#msg156860 16.04.41 # then someone needs to modify all the needed pages 16.04.58 # the wiki pages? 16.05.12 # nope, www 16.05.20 # i'll do it 16.05.40 # Zagor: http://www.rockbox.org/wiki/RockboxUsbHandling is broken 16.05.43 Join evilnick_ [0] (i=0c140464@rockbox/staff/evilnick) 16.06.20 # gevaerts: broken how? 16.06.28 # I get an edit page 16.06.34 # sampattuzzi: There are bits and pieces around on the wiki, but the real documentation is the code 16.06.37 # wow. I don't 16.06.44 # nether do i 16.07.03 # gevaerts: Works here 16.07.07 # New commit by 03funman (r23152): Move the Samsung YH820 to Unstable 16.07.25 # hm, it works now 16.07.48 # sampattuzzi: http://www.rockbox.org/wiki/DocsIndex#About_the_Code has some information, although parts of it are probably outdated 16.08.34 # New commit by 03funman (r23153): rbutil: YH820 Unstable support 16.09.01 # what is logfdump? how does this work? 16.09.22 # creates a .rockbox/logf.txt with logf buffer content 16.09.22 # It should save contents of the logf buffer to a file on disk. 16.10.09 Join blitzwing [0] (n=7c26ecf6@giant.haxx.se) 16.10.19 Quit blitzwing (Client Quit) 16.10.34 Join saratoga [0] (i=98039f25@gateway/web/freenode/x-miqlsklvuiifsswg) 16.10.57 Join blitzwing [0] (n=7c26ecf6@giant.haxx.se) 16.11.11 # but only once? 16.11.25 # i would need something that dumps it at it is written to the buffer 16.11.45 # has lowlight been around lately? i wonder why the gogear isn't unstable yet? 16.12.01 # TheSeven: see saratoga. I think he has a patch for that 16.12.37 # hey there. I have a question about the gigabeat T series. has anyone figured out if rockbox will work or not on it yet? 16.12.49 # oh, yes I hacked one together for the clip 16.12.58 # i was reading some logs and figured i might as well pop in here hehe 16.13.05 # blitzwing: i sent one to lambda ages ago but i don't think he did much with it 16.13.21 # ahh 16.13.45 # TheSeven: http://duke.edu/~mgg6/rockbox/cliploggingv3.patch 16.13.56 # all sorts of crap in there but the logf stuff should be pretty easy to spot 16.14.25 # compile a build with logf, include logf.h where you need it, and make sure HAS_LOGF or whatever it is gets defined in the right files 16.14.27 # i was poking around in a box in my closet and found my T series at the bottom of a pile; realized that there were some official firmware updates and so decided to recheck here 16.15.12 # though, they were updates from jan. haha... 16.15.47 # funman: i still got a more hardware related question. i really got an battery drain after power down. could this get caused by my not working led aside the play button? 16.16.18 # pyro_maniac: nope, the battery reading is implemented, but not battery levels 16.16.44 # the value read from ADC is not correctly translated to volts 16.16.44 # funman: you seen the latest in FS#10605 - Patch for stable playback for clip_v1 16.16.58 # saratoga: yes, i have trouble understanding matsch explanations 16.17.20 # as do I but I think he is probably onto something 16.18.02 # funman: but i get a real battery drain. this is also detected in OF 16.18.05 # we need to get nico_p on this! 16.18.08 # saratoga: actually it should be easier to salvage the logf buffer with a coldboot attack, huh? 16.18.20 # TheSeven:? 16.18.25 # pyro_maniac: this is because rockbox doesn't shut down when the battery level gets critical 16.18.32 # * TheSeven will just try that 16.18.51 # what is a coldboot attack ? 16.18.52 # funman: if our problems are due to a buffer not being wrapped properly if a codec is buffered, it would explain why disabling codec buffering helps so much 16.19.08 # funman: ok so i test again after battery read is fixed. 16.19.08 # well codec or anything else that cannot be wrapped (not sure what that might be) 16.19.15 # funman, saratoga: salvaging stuff left over in RAM after a reboot 16.21.09 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 16.21.45 # bugger. someone with a large disk build for ipodvideo says that the ata dma patch causes crashes for them :( 16.24.06 # TheSeven: on a flash target dumping logf's to disk is pretty easy 16.24.28 *** Saving seen data "./dancer.seen" 16.24.38 # bool can_wrap = type==TYPE_PACKET_AUDIO || type==TYPE_CODEC; 16.24.51 # what would happen if I just hacked it so that no audio buffer data could wrap 16.25.09 # saratoga: hrm; you don't suppose lambda would give it another shot would you? but perhaps people have moved on from the lil' old T :( 16.25.27 # saratoga: what about the move_handle(...,true) in shrink_handle() ? 16.25.29 # blitzwing: i have no idea what hes interested in 16.26.01 # haha, i guess i'll have to track him down myself then 16.26.09 # does he come around here much these days? 16.26.38 # /msg logbot seen lambdacalculus37 16.27.09 # ah, thanks 16.27.13 # yeah he's here regularly 16.28.25 # and there is a bug in the plugins menu, i have to press at least twice to change into a submenu 16.28.56 # alright. i'll drop in and try to catch him later. thanks all. :) 16.30.11 # liar|netbook: no pb here (r23133). could it be your clickwheel ? 16.30.43 # dont think so, its working fine in the OF 16.31.05 # ok, downstream control is working properly now, however not upstream 16.31.23 Quit blitzwing ("CGI:IRC (EOF)") 16.31.26 # blitzwing: I can ask him later on 16.31.28 # Darn 16.31.32 # liar|netbook: ah. 16.32.02 Quit T44 (Read error: 104 (Connection reset by peer)) 16.32.14 Join toffe82 [0] (n=chatzill@12.169.218.14) 16.34.10 Part pyro_maniac ("Leaving.") 16.34.22 Join Topy44 [0] (n=Topy44@f049029014.adsl.alicedsl.de) 16.35.00 Join DreamMonchi [0] (n=5e861fad@giant.haxx.se) 16.35.16 # hio 16.36.03 # is there anybody out there ? 16.36.45 # DreamMonchi: don't do that, and read the IRC guidelines before you post here 16.36.51 # DreamMonchi: If you have a (Rockbox-related) question then ask it 16.39.29 # New commit by 03dave (r23154): Fix Nano2G bootloader installation - no longer assume that the OSOS image is the first. 16.40.24 # My question: I#ve got a Archos3 Vision. is it possible, to install Rockbox ? 16.40.49 # Only if you do all the work here http://www.rockbox.org/wiki/NewPort 16.43.53 Quit DreamMonchi ("CGI:IRC (EOF)") 16.47.29 Join bubsy [0] (n=bubsy@94.139.72.137) 16.47.37 Quit bubsy (Read error: 54 (Connection reset by peer)) 16.47.39 Join bubsy [0] (n=bubsy@94.139.72.137) 16.55.41 Quit liar|netbook (Remote closed the connection) 16.55.45 Join Strife89 [0] (n=michael@168.16.239.253) 16.57.31 Quit Horscht ("Verlassend") 17.01.29 Part LinusN 17.02.32 Join lifeless_ [0] (n=lifeless@90.151.216.8) 17.03.45 Quit pamaury ("exit(*(int *)0 / 0);") 17.06.01 Quit Zagor ("Don't panic") 17.09.06 # something seems to be broken with our wiki: http://www.rockbox.org/wiki/RockboxUsbHandling always asks for user/password, even when i just want to view it. 17.11.58 # Perfect timing - Zagor just left... 17.13.01 # doesn't matter. He denies :) 17.14.04 # They magically fix themselves when he's around though. 17.14.07 # also the daily build page seems to broken. no picture and build for fuze. 17.14.35 # gevaerts: WORKSFORME 17.14.36 # also no voicefiles available on this page :-/ 17.17.15 Quit lifeless__ (Read error: 113 (No route to host)) 17.20.06 # Who do I need to poke to get "ipodnano2g" added to the themes site? 17.20.14 # hm, on the download server there are some voicefiles available, but not for all targets, and the links on the daily page are missing. 17.20.20 # * linuxstb assumes rbutil needs that 17.21.26 # linuxstb: true, rbutil needs it. if you give me the info needed i can add it. (but it also needs a checkwps build). 17.22.05 # What info do you need? Everything is identical to the 1st gen nano. 17.22.15 # what is the checkwps name for the ipod nano 2gen ? 17.22.30 # checkwps.ipodnano2g I assume. 17.22.31 # and whats the resolution ? 17.22.36 # 176x132 17.22.40 # (x16) 17.23.06 Join Dege [0] (i=Dege@151.61.192.205) 17.24.08 # Yes, checkwps comes out as checkwps.ipodnano2g 17.24.08 # * TheSeven has a very weird IRQ problem 17.24.11 # * domonoky added it. now it only needs a ipodnano2g picture, and a update of the checkwps tool. 17.24.11 # looks like something's preventing USB irqs from coming through as long as it's connected 17.24.19 # as soon as i unplug it, one of them fires 17.24.35 # as if someone would be masking that int 17.24.48 # domonoky: How is the checkwps tool updated? 17.25.37 # domonoky: I think it should just be called "iPod Nano 2G" to be consistent with "iPod Mini 1G" and "iPod Mini 2G". 17.25.42 # add it to tools\checkwps\targets.txt and then prod rasher 17.25.56 # Although personally I would prefer "1st gen" and "2nd gen" to avoid confusion with GB 17.26.27 # And "iPod Nano" should probably now be explicitly called "1st gen" (or 1G) 17.26.47 # linuxstb: too late, i can only add, not change the info :-) 17.27.12 # domonoky: Hmm, it's showing zero themes... 17.27.18 # i choose 2nd gen, because its similar to "Ipod 1st and 2nd gen" :-) 17.27.33 # Yes, but you inserted "Apple" at the start as well 17.27.39 # it will show 0 themes, until rasher updated checkwps on the theme server. 17.28.05 # true, rasher should change that too.. :-) 17.28.17 # OK, thanks for your help ;) 17.28.39 # * linuxstb pings rasher, just in case he missed the previous highlights... 17.28.58 # * TheSeven is getting angry 17.29.09 # IRQs don't like me today :-/ 17.29.19 # * linuxstb knows that feeling 17.29.33 Join lifeless__ [0] (n=lifeless@90.151.216.8) 17.29.57 # * scorche|sh hides 17.30.28 # * funman would like to exchange this with a SD controller not liking him 17.31.00 # * TheSeven figures SD can't be much harder than USB 17.31.16 # checkwps is updated automatically, provided the target is listed in buildall.sh 17.31.26 # TheSeven: is the USB controller in nano2G documented? 17.31.29 Quit lifeless_ (Read error: 113 (No route to host)) 17.31.32 # rasher: Ah, so it's not using the new tools/configure build method? 17.31.52 # funman: sort of. the s3c6400x datasheet seems to fit with very few exceptions 17.32.21 # * funman still wants to exchange then 17.32.40 # rasher: OK, I'll add 17.33.51 # New commit by 03dave (r23155): Add ipodnano2g 17.33.59 # rasher: Done 17.34.21 # rasher: What do you think about using "1st gen", "2nd gen" etc consistently for the ipod names? 17.38.56 Join kugel [0] (n=kugel@rockbox/developer/kugel) 17.43.09 Quit kyle6513 ("Leaving") 17.48.19 # funman: now that I've had some coffee i think I sort of understand matsch's buffering patch 17.48.52 # * funman feeds 1L of coffee to saratoga 17.49.14 # magic coffee 17.51.01 # funman: however I don't really understand his memmove changes 17.51.15 # shouldn't memmove always be safe even if the src and dst overlap? 17.52.24 # unless we overwrite the source buffer of the 2nd call with the 1st call 17.52.54 # ah ok i guess thats what hes concerned about 17.53.44 # the rest of his changes basically just concern disabling wrapping of the codec files on the buffer, since it appears that they need to be continuous 17.53.49 Quit esperegu (Read error: 104 (Connection reset by peer)) 17.54.28 # and I think some corner case in which a file that couldn't be wrapped was wrapped anyway 17.54.52 # from my test builds it does seem like most crashes involve move_handle directly 17.55.11 # i'm holding out hope that simply fixing it will make the other go away too (perhaps because move_handle corrupted the buffer) 17.56.10 # it would make sense though, the odds of a codec ever being wrapped on a 32MB RAM target are astronomically small 17.56.24 # we would never have noticed 17.56.33 # and of course the archos can't ever buffer a codec file 17.57.14 # saratoga: Hmm, there shouldn't be a need to ensure codecs are contiguous - but it sounds like the code in Rockbox that copies them to the codec buffer makes that assumption (I would fix that, not the buffering code) 17.57.15 # (IIUC) 18.00.19 Quit funman ("free(random());") 18.01.25 # linuxstb: seen the last post here: http://www.rockbox.org/tracker/task/10605 ? 18.01.31 # I thought only the audio file is allwed to wrap in the buffer? 18.01.44 # its possibly i'm misunderstanding his english . . . 18.02.37 # JdGordon: Shouldn't everything that's copied (codecs, AA, metadata) be allowed to wrap? (I'm assuming all those things are copied, rather than used directly, but I may be wrong) 18.03.04 # the current code only allows packet audio (but not atomic audio) and codec files to wrap 18.03.08 # nothing else is allowed to 18.03.25 # i think atomic audio is some odd tracker format or something 18.03.31 # they arnt always copied, so no, they need to be continuous 18.03.35 Quit HellDragon (Connection timed out) 18.03.56 # i think only the codec's callbacks are smart enough to deal with wrapped audio actually 18.04.03 # err wrapped files 18.04.04 # JdGordon: What isn't copied? I can't imagine codecs being used directly. 18.04.33 # jpeg data probbably isn't copied 18.04.39 # for example 18.05.03 # but yes codecs are copied, and i think matsch's intention is to have codecs wrappable and he just hasn't figured out how 18.05.08 # I thought it was? Or what happens with very large files, do we leave a hole now? 18.05.11 Quit petur ("now sports...") 18.05.12 # he has a habbit of doing too much in each patch 18.05.16 # i will ask him about it 18.05.44 # linuxstb: I'm not sure, but the check for wrapping does not include any kidn of album art 18.06.03 # at least not that i found 18.06.31 # But I imagine album art needs to be contiguous for the bitmap loader. 18.07.30 # (and same for metadata, when it's being read, assuming get_metadata() writes directly into the audio buffer) 18.09.17 # linuxstb: AA is used directly 18.09.46 # kugel: So it's kept for the lifetime of the track, even if the track is 3x the size of the audio buffer? 18.10.03 # yes 18.10.25 # And shuffled around? 18.10.27 # the aa handle is closed when the track is finished. the same applies for id3 18.11.29 Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) 18.11.31 # hello, who is responsible for the build-clients again? 18.11.33 # So id3 info is no longer copied into static buffers? 18.11.34 # id3 isnt used directly, it is copied out of the buffer 18.11.43 Quit Strife89 ("The number of files on my hard drive is OVER 9000!") 18.11.54 # i don't see any real advantage to making codecs wrappable given how small they are and how rarely they need to be buffered, but it is a fairly ugly hack 18.11.57 # I tihnk it still needs to be continous though 18.12.21 # JdGordon: ah right, sorry. 18.12.35 # the codec probably must not wrap because of alignment fixes 18.12.49 # kugel: ? 18.13.01 # alignment? 18.13.15 # * linuxstb thinks if everyone put their brains together, we _might_ know how playback works... 18.13.34 # well, I'm just guess here, but if a codec wrapped, and the alignment of the data is corrected, then the code gets corrupted. 18.14.06 # linuxstb: no, there'd still be holes :( 18.14.33 # alignment shouldnt be an issue because the codec is copied to the correct alignment before use anyway 18.14.40 # i think the buffering code realigns things as they're moved anyway 18.15.13 # for example: /* The value of delta might change for alignment reasons */ followed by updating the pointers if the values change 18.16.15 Join faemir [0] (n=faemir@78.33.109.163) 18.17.21 Quit gevaerts (Nick collision from services.) 18.17.33 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 18.18.10 Join arohtar [0] (n=faemir@78.33.109.163) 18.18.14 # install instructions on http://www.rockbox.org/wiki/SansaAMS link to http://build.rockbox.org/data/rockbox-fuze.zip (r22777-090921) instead of http://build.rockbox.org/data/rockbox-sansafuze.zip 18.19.11 # topik: Would you like write access to the wiki? ;) 18.19.36 # did you find someone who knows how to give that access ;) 18.20.24 # Anyone can. 18.20.35 # Or rather, any person with write access already can. 18.21.03 # if it's less trouble than changing the link, sure 18.21.29 # seems it's too late 18.22.24 # topik: I was just trying to recruit you as a new contributor to the wiki... 18.23.36 Quit bluebrother (Nick collision from services.) 18.23.37 Join bluebroth3r [0] (n=dom@rockbox/developer/bluebrother) 18.23.50 # topik: But isn't "fuze" the right name? 18.24.19 # it was, it is sansafuze now 18.24.22 # the zips 18.24.30 *** Saving seen data "./dancer.seen" 18.24.41 # kugel fixed the link a moment ago 18.26.25 # on a side note, the last log someone posted from a clip clearly shows the system crashing trying to move a wrappable across the ring buffer wrap point 18.26.43 # linuxstb: the name of the zip was changed to rockbox-sansafuze.zip for consitency with other sansas. 18.27.03 # Yes, but inconsistency with other targets, which are rockbox-$targetname.zip 18.27.53 # linuxstb: yes, the whole naming situation is a mess 18.28.09 Quit mc2739 (Read error: 110 (Connection timed out)) 18.28.15 # And the rockbox-fuze.zip is still on the server... 18.28.27 Quit maruk ("Leaving.") 18.30.11 # strange, are both fuze and sansafuze built ? 18.30.25 # No, but the old one was never deleted. 18.31.02 # * linuxstb thinks we now have more inconsistency (i.e. more targets not using $targetname)... 18.31.16 # both have current timestamps ? strange 18.31.47 # the same for the sansa clip 18.31.58 # Not for me (downloaded with wget) - rockbox-fuze.zip is from September 21st 18.32.55 # bah. the USB core is killing my driver 18.34.47 Quit faemir (Read error: 110 (Connection timed out)) 18.34.59 # * domonoky doesnt care if its $manufacturer$targetname or only $targetname, as long as its consitent for all device from one manufacturer, and more important, the same name on all places (rbutil currently deals with 3-4 different names per target) 18.37.36 # domonoky: IMO it should be whatever is "$modelname" in tools/configure. That's what is used for bootloader filenames (for Sansas), as well as checkwps. 18.38.28 # The Sansas seem to be a pain as the convention was to not use it there, but then to add it in other places... 18.39.31 # linuxstb: using the name from configure would be fine (and would solve some naming things) but there are more targets to differentiate then configure knows. 18.40.23 # * bluebroth3r wonders if a discussion about the BuildNames is going on 18.40.35 Nick bluebroth3r is now known as bluebrother (n=dom@rockbox/developer/bluebrother) 18.41.03 # bluebroth3r: another attempt yes... but it will probably never change :-/ 18.41.09 # hm, the current code lets codecs wrap (looking at the patch only at the moment)? 18.41.22 Join liar_ [0] (n=liar@83.175.83.185) 18.41.22 # New commit by 03funman (r23156): Sansa AMS PCM : replace buggy and confusing one-liner ... 18.41.25 # well, we can't go on like this forever. 18.41.37 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.41.37 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 18.41.58 # bluebrother: You missed bootloader filenames from that table... 18.42.40 # is that different from the build names too? Urgh. 18.42.50 Quit KBH (Read error: 54 (Connection reset by peer)) 18.42.50 # Is the same as $modelname 18.42.51 Join bertrik_ [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.43.48 # http://rasher.dk/rockbox/targetnames.php 18.43.50 # kugel: yes they can wrap, not sure how successful it is though 18.43.54 Join KBH [0] (i=hbk@97.77.51.170) 18.43.56 # well, ideally we have a string that uniquely identifies a player and is used for all downloads, as well as for identifying the player with all scripts. Decorative or shortnames can still get supported 18.43.58 # bluebrother: sure its different, or else we wont need a bootloadername entry in rbutil.ini 18.44.24 # But some bootloaders need the filename of the OF - things like PP5022.mi4 18.44.27 # domonoky: well, that entry also holds the path. I was thinking about the basename 18.44.27 # I'm in favor of company/linemodel 18.45.12 # bluebrother: the path did come later, it was first introduced because the name was again different. :-) 18.45.45 # linuxstb: we could solve that by using the unique identifier as path for bootloaders, then whatever name the bootloader needs as filename -- if it's a single file per folder the filename doesn't matter much anymore 18.46.35 # domonoky: if my memory serves me correctly I introduced that when reworking the bootloader class to move the names out of the class itself, and also added the path the same time 18.47.16 # but anyway, as bootloader files might need a special filename using a path instead might be a solution. At least one I can think of ;-) 18.49.01 # having runtime detection of RAM would be a good thing as well -- no need for recorderfm8mb and ipodvideo64mb builds anymore 18.49.45 # I can't see anyone fixing that in the near future - it's been on MrSomeone's to-do list for years... 18.50.18 # true :( 18.50.22 Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) 18.51.34 # BTW, anyone know the forum policy for "Unstable" ports? e.g. can Nano2G install questions now go in the Apple manual installation forum? 18.52.22 # well, how should a cleaned up targetname look like? IMO we should have something combined, like -[-] 18.52.40 # linuxstb: sure 18.52.48 # with the we could catch all those different-sized RAM targets 18.52.54 # I've splitted the USB issues down now, there are 3 of them 18.53.05 Quit AlexP ("CGI:IRC (EOF)") 18.53.08 # 1st of course DMA trouble again (because of misalignment - need to fix this) 18.53.44 # 2nd the USB controller not asserting EP interrupts correctly, currently circumvented by polling 18.54.26 # 3rd the USB core running into some deadlock with IRQs disabled immediately after driver startup (gevaerts?) 18.55.21 # bluebrother: hyphens would be a minor problem for ipodpatcher and sansapatcher, as the targetname is used for the name of the C array containing the bootloader... (but I guess I can do s/-/_/) 18.56.25 # bluebrother: Also I don't think we want "apple-ipodcolor" or "sandisk-sansae200" do we? 18.56.36 # (or do we?) 18.57.56 # linuxstb: why not? It's a bit lengthy, but ideally all those are handled by tools so people won't have much contact with that. 18.58.28 # * linuxstb thinks the current "build download" names are fine - the main thing is the same name is used everywhere, rather than enforcing a convention across them all. 18.59.00 # we could use a different character for separating the parts. Like a dot. 18.59.22 # or use a / and actually make it a path -- just leave that path out when building. 19.03.11 # and that still leaves the problem with variant names like fmrecorder8mb. As a first step, we could define a split character that splits off this variant part. This would make it easier for rbutil and possibly other tools to find out that fmrecorder8mb is in fact fmrecorder for everything but the build 19.03.33 # bluebrother: You could also argue that because they're only seen by tools, they don't have to be long and meaningful, just consistent and unique... 19.03.54 # linuxstb: true. 19.03.55 # could we ask the rsb to decide on one of the suggestions on rashers page? 19.04.30 # They're also in the config-$modelname.h files (although I don't think it's created like that). 19.05.15 # kugel: better than submitting it to the bikeshed-painting committee 19.05.28 # I mean, the different names are highly annoying, but making them consistent/predictable doesn't have enough impact for a great discussion, so I'd like to have a quick decision 19.05.49 # bluebrother: I've just got a feeling that keeping then as a single sequence of letters and numbers (like they are now) will give us less problems. 19.06.05 # linuxstb: but one can also argue that it would be nice to have them still human-readable and uniquely recognizable even when read by someone not familiar with the names :) 19.06.34 # linuxstb: hmm, probably. On the other hand, if there are tools that run into problems they need fixing anyway ;-) 19.07.51 Quit sampattuzzi (Remote closed the connection) 19.08.59 # bluebrother: Maybe some things can't be fixed though - if the names are used (or could be used) in places that don't allow certain characters. 19.09.34 # ok, a few renames in configure would make the table noticably more consistent 19.10.13 # linuxstb: you've got a point, though I'd prefer to assume this issue not arising ;-) 19.12.09 # Well, the obvious first thing is the sansas. If we simply agree that all names should be sansaXXXX, then what are the consequences? 19.13.20 # * linuxstb sees that Sansapatcher is consistent with tools/configure, so lots of things should change there. 19.13.29 # * linuxstb doesn't know if rbutil would then need changing... 19.13.51 # any objections to renaming the configure names for sansas to sansa, ipodmini to ipodmini1g, {x,m}* to iaudio{x,m}*? 19.13.58 Quit kkurbjunW (Remote closed the connection) 19.14.09 # bluebrother: YES! (if you mean you want to do it immediately...) 19.14.55 # linuxstb: not immediately, but I'd like to get that cleaned up as soon as possible. 19.15.25 # oh, and ipod4g -> ipod4gray 19.15.51 # Oh no, that should be ipod4g... 19.16.35 # well, changing the configure string should break less. If the download filename gets changed we need redirects until rbutil knows about the new names too 19.16.45 # But it's simply wrong ;) 19.16.51 # true :) 19.17.12 # But I disagree - the configure string is also used in lots of places. 19.17.23 Join kkurbjunW [0] (n=karlk@12.41.166.8) 19.17.24 # is Bagder around again? If he can setup redirects then there's notihing against doing so 19.17.51 # where? The buildserver. Which places else? 19.18.10 Join stoffel [0] (n=quassel@p57B4F487.dip.t-dialin.net) 19.18.19 Join esperegu [0] (n=quassel@145.116.11.103) 19.18.19 Join JdGordon| [0] (n=Miranda@nat/microsoft/x-cutgszpdpxmsrqwr) 19.19.05 # I'd rather agree on one of the suggestions, so that we can fix all targets with one hit. changing a few targets doesn't get us further 19.19.07 # ipodpatcher is using them. The configure script itself is using them in two places (an alternative name for the target, and then $modelname, which is used for build targets). checkwps uses them, so I guess the themes site also does. 19.19.34 # As I said earlier, sansapatcher is using them (so rbutil might be as well) 19.20.05 # * TheSeven should really document things 19.20.11 # kugel: No, but thinking about one target is a way to find out what the consequences will be for the big rename... 19.20.31 # i now have an issue that i also had with ibugger - i fixed it there somehow, but I can't remember what it was 19.20.35 # hmm, seems I missed quite a few places. Dang :( 19.20.44 # Also lang giles... 19.20.47 # s/giles/files/ 19.20.50 # And the manual? 19.20.56 Quit arohtar (Client Quit) 19.21.06 # (the target-specific strings in lang files) 19.21.31 # afaik those are now mostly handled by features.txt 19.21.46 # bluebrother: "mostly"... 19.22.57 # * linuxstb thinks the names in configure are good enough, and it will be far less work to just change to using them 19.24.14 # The themes site seems consistent with configure. 19.25.48 # bluebrother: If you look on your BuildNames table, there are only relatively few reds... 19.27.11 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 19.27.31 # yes. The samsung reds can get fixed in rbutil. 19.28.00 # but wouldn't it be a bit strange to have download files like x5.zip? Do you think that's fine? 19.28.25 Quit bertrik_ (Remote closed the connection) 19.28.39 # bluebrother: The alternative scares me more... 19.29.02 # too short names are dangerious. there might be another target named x5 in the future. 19.29.12 # Like the meizum3... 19.29.18 Join bertrik_ [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 19.29.58 # Yes, the m3/m5/x5 are bad though... 19.30.34 # jup, there is already a naming clash if we use only $targetname 19.30.56 # No, there's no clash - the Meizu M3 target name is meizum3 19.31.24 # it's no clash, but it can be confusing 19.32.16 # ah, we would stay with the current naming in configure ? 19.32.57 # but configure names also could need some cleanup, like ipodmini -> ipodmini1g 19.33.55 # well, at least I would prefer configure names to be less confusing. I.e. m3 -> iaudiom3 19.34.49 # has anyone actually looked at http://rasher.dk/rockbox/targetnames.php ? 19.35.37 # names like x5 will sooner or later give us problems 19.36.39 # domonoky: I'm suggesting that's a practical (i.e. least work) way to clean up the inconsistency.... 19.38.48 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 19.39.08 # isn't the question rather how much pain (and work) we're willing to put into the cleanup? Moving to completely different names (like company/line-model variant) is definitely noticably more work than simply adjusting a few zip filenames 19.40.19 Join barrywardell [0] (n=barrywar@rockbox/developer/barrywardell) 19.42.59 # bluebrother: Yes - do we have any volunteers, e.g. for fixing every lang file? 19.44.20 Join efyx_ [0] (n=efyx@lap34-1-82-225-185-146.fbx.proxad.net) 19.47.52 # linuxstb: well, I'm willing to work on that, though I guess that the "big" solution is nothing that can be done alone. Plus, there's always this stupid problem with lack of free time :/ 19.48.00 # * bluebrother has to leave for a while now 19.48.31 Quit saratoga ("Page closed") 19.48.48 # bluebrother: Yes, we would need a big co-ordinated cleanup effort, with everything changing at the same time... 19.49.50 # linuxstb: I think sed volunteers for the lang files :) 19.50.06 # He doesn't work alone though ;) 19.50.59 # you could fix the langs with any semi-decent text editor in a few minutes 19.51.14 # * linuxstb thinks we have a volunteer.... ;) 19.52.00 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 19.52.22 # do we have a useful suggestion for problems like recorder vs recorder8mb? 19.52.44 # (same configure target, but different build) 19.54.11 # IRC logs are really helpful sometimes 19.57.17 Quit intrados (Read error: 60 (Operation timed out)) 19.57.28 Join Horschti [0] (n=Horscht2@xbmc/user/horscht) 19.58.28 # * linuxstb wonders if pixelma has had time to work on a pretty nano2g picture 19.58.32 Quit CaptainKewl (Remote closed the connection) 20.01.04 Join ender [0] (i=krneki@foo.eternallybored.org) 20.06.06 Join intrados [0] (n=intrados@cpe-75-187-57-252.columbus.res.rr.com) 20.06.32 Quit Dege (Read error: 110 (Connection timed out)) 20.06.57 Join Horscht86 [0] (n=Horscht2@p4FD4D232.dip.t-dialin.net) 20.10.33 # Anyone around with a 1st gen Nano? What's the range of the volume? 20.10.39 Join T44 [0] (n=Topy44@f048220190.adsl.alicedsl.de) 20.10.47 Quit stoffel (Read error: 60 (Operation timed out)) 20.13.46 Join midgey [0] (n=tjross@rockbox/developer/midgey) 20.14.45 Quit kugel (Read error: 113 (No route to host)) 20.15.18 # linuxstb: manual says -72 to +6 20.15.30 # midgey: I know - I think it's wrong... 20.15.35 Quit Horscht (Read error: 110 (Connection timed out)) 20.15.55 # It has the same audio codec as the ipodcolor, ipodnano2g and others, where the range is -74 to +6 20.16.01 # possibly, look at whats written for giga-f.... 20.16.01 Quit ender` (Read error: 110 (Connection timed out)) 20.18.30 Nick Horscht86 is now known as Horscht (n=Horscht2@p4FD4D232.dip.t-dialin.net) 20.23.05 # if anyone wants to take a look, the manual for Sound Settings > Volume is messed up on gigabeat fx and ipod mini 20.23.27 Quit Horschti (Read error: 110 (Connection timed out)) 20.23.47 # mini cuts out in the middle of a sentence, and the gigabeat says "The volume can be adjusted from a minimum of -73 dB to a maximum of +6 dB.minimum of -74 dB to a maximum of +6 dB. " 20.24.32 *** Saving seen data "./dancer.seen" 20.25.30 Join d__Blanck_ [0] (n=infinity@cust-25-210.on5.ontelecoms.gr) 20.27.35 # midgey: would be nice if you could post a bug with that, things like this tends to be forgotten 20.28.11 # Hi, only recently ( even after updating to the latest Rockbox ) i can't automount my H10-20G with Thunar file manager. dmesg states "FAT: IO charset ANSI_X3.4-1968 not found" Does this have anything to do with rockbox? I can mount it manually. thnx ^_^/'' 20.28.20 Quit Topy44 (Read error: 110 (Connection timed out)) 20.28.52 Quit flydutch ("/* empty */") 20.41.44 Quit z35 (Read error: 110 (Connection timed out)) 20.44.00 # * topik converted his favorite fuze(-compatible) theme to his ipod nano2g. pretty! 20.48.16 # topik: where can i get it? :-) 20.49.26 Part wincent ("Kopete 0.12.7 : http://kopete.kde.org") 20.49.39 Join stoffel [0] (n=quassel@p57B4F487.dip.t-dialin.net) 20.50.16 # uhm 20.51.22 # wireshark is just too big 20.51.31 # I'm compiling that since an hour now 20.51.43 Join tomers [0] (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) 20.53.29 # topik: You could upload it to the themes site... (just select the 1st gen Nano for now...) 20.54.17 # i asked the original author for permission 20.54.21 # but for now: http://members.chello.nl/~m.aarts5/electricbarsofcolour_176x132.zip 20.54.31 # topik: So the original wasn't on the themes site? 20.54.37 # it is there yes 20.54.44 # Then you don't need to ask... 20.54.51 # it's polite to do so anyway? 20.55.05 # The author explicitly gave permission when licensing it under the CC 20.55.24 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 20.56.08 # topik: I wouldn't say it's impolite to not ask... 20.57.01 # i'll add it 20.57.46 Quit esperegu (Read error: 131 (Connection reset by peer)) 20.58.00 Join esperegu [0] (n=quassel@145.116.11.103) 20.58.40 Nick YPSY is now known as Ypsy (n=ypsy@87.106.45.183) 21.00.37 # there we go 21.01.01 # now all that's needed it is for someone to link the 2g to the 1g themes :) 21.01.16 # That's waiting for rasher to do some magic... 21.01.54 # I guess the "works with release 3.4" text under that won't be applicable for the 2nd gen 21.03.15 # no such thing exists, so few will try it i suppose 21.03.49 Nick Ypsy is now known as YPSY (n=ypsy@87.106.45.183) 21.04.15 # the nano 2g screen is not very vibrant 21.04.32 # You could try increasing the brightness. 21.04.36 # (backlight brightness) 21.05.03 # I'm just curious if the theme site is smart enough to know the first release a target was included in... 21.06.37 # linuxstb: i think the theme site just shows themes which passed the checkwps thing. so it will only say works in release 3.4 if the 3.4 checkwps for this target there and gives green light for this theme. 21.06.48 # +is 21.07.10 # Sounds perfect. 21.09.04 # the simulator gives challenging line numbers with its errors if the wps has any. i think it ignores comment lines or something 21.10.05 Quit bmbl (Read error: 145 (Connection timed out)) 21.11.11 Join HellDragon_ [0] (n=jd@vpn.exhort.ca) 21.11.44 Join kugel [0] (n=kugel@rockbox/developer/kugel) 21.13.23 # I tihnk its supposed to keep the correct line count 21.13.34 # linuxstb: it doesn't show "Works on release 3.4" for the fuze 21.13.59 # i uploaded it to the nano 1g page, which works with 3.4 21.14.23 # kugel: So it doesn't... I didn't think to check other new targets. 21.14.45 Quit Utchybann (Read error: 148 (No route to host)) 21.15.07 # linuxstb: just confirming domonoky, I don't think it should be changed either 21.15.30 # why is the nano2g special getting Apple in its name? 21.15.44 Quit HellDragon (Read error: 60 (Operation timed out)) 21.15.52 # I don't think it is - that was a mistake by domonoky ;) 21.16.02 # because i did it accidently. :-) 21.16.08 # s/mistake/accident/ 21.16.15 # topik: OH! i tihnk i know what the problem is.. I tihnk tokens which take up the whole line dont increment the line counter... (like the %xl| lines) 21.16.33 # and the admin interface only allows to add targets, no changes possible at moment. 21.17.15 # also... I love how the e200 has one more theme than the e200v2 21.17.28 # takes a few seconds for rasher to delete it again, I made a mistake too when I added the fuze 21.17.38 # that could be it JdGordon|. that would just about make up the difference 21.17.44 # ironically, I forgot to add the Sandisk, which other sansas have :p 21.17.45 # JdGordon|: Have you spotted which one? 21.18.03 # topik: can you file a bug in the tracker and ill try to fix it this arvo? 21.18.11 # linuxstb: no 21.18.35 # JdGordon|: I love how the fuze has 1 less as the h300. The one missing is easily noticable :p 21.18.56 # linuxstb: yes.. Spartan Black 21.19.00 # linuxstb: easy to spot... it's the wrong sized one 21.19.04 # if only i still had the offending wps file 21.19.11 # i accidentally fixed it 21.19.26 # JdGordon|: Yes, I just noticed that - it says it works with 3.2 and the current build... 21.19.27 # just add that message I just replied with and it wont need an offending wps 21.19.49 # it also happens to be the wrong size lcd! 21.20.01 # who wrote that site :) /me slaps scorche 21.20.10 # I think rasher did 21.20.10 # would the 'plain_v2' theme on the ipod color/photo page actually work? it is a different size 21.20.54 # JdGordon|: Maybe the theme itself is OK, just the screenshots are wrong (stolen from the original?) 21.21.23 # dunno.. cant spend more time now checking 21.21.26 # that Spartan Black one also appears wrongly on the 160x128x16 in a bigger version... I think the theme exists in a few different sized "ports" and I remember rasher saying that the theme site doesn't handle different themes with the same name too well (though I don't know if it was fixed) 21.22.16 # pixelma: Yes, I downloaded it, and it gave me a 220x176 version 21.22.42 # if you hover over the images, you can see the download url includes 220x176 in the path 21.22.57 # * linuxstb wonders where rasher is hiding... ;) 21.23.14 Quit HellDragon_ (Client Quit) 21.23.14 # it's also the difference why some targets with 160x128x16 screens have 18 themes and the Samsung one 17 21.23.25 # * linuxstb guesses rasher will point us all to the source code to the site in SVN.... 21.23.27 Join HellDragon [0] (n=jd@vpn.exhort.ca) 21.23.31 Part d__Blanck_ 21.24.57 Part Grahack 21.25.40 # pixelma: Do you have any advice on debugging a manual compilation error? The errors seem to relate to the page in the output document, not the source file... 21.25.59 # (I'm trying to create a nano2g manual) 21.27.23 # it's always hard to debug as the underfull and overfull warnings get in the way. Does compiling stop fully or do you get something? 21.28.10 # I'm is just getting "! Undefined control sequence." followed by some text that grep doesn't actually find... 21.28.24 # But I think I've tracked it down to something in pictureflow.tex - which I haven't changed... 21.28.34 # If I delete the contents of that file, the error goes away 21.28.47 # task added JdGordon. thanks! 21.29.33 # the error message is often before that, I guess you are missing some keymap macros but hard to tell "in theory". Could you post the log somewhere? 21.29.42 # pixelma: It's something in the buttonmap, but the nano2g is defining IPOD_4G_PAD - the same as all the others. 21.30.13 # topik: haha, you could have fixed my typos in the message :D 21.30.25 # I mean *right* before the stop 21.30.41 # pixelma: I'm just doing a clean rebuild now, and will post the log. 21.31.07 # i was very close to add a sub-task (comment) on your inability to type 'think' :) 21.31.17 # pixelma: http://linuxstb.cream.org/rockbox/manual-log.txt 21.33.21 # "just IPOD_4G_PAD" <- do you link to keymap-ipod4g.tex then in the platform file? 21.33.45 # pixelma: And these are my changes - http://linuxstb.cream.org/rockbox/manual-nano2g.txt 21.33.56 # Yes 21.33.57 Quit bluebrother (Read error: 113 (No route to host)) 21.34.19 # pixelma: I just copied the ipodnano platform file, and renamed "ipodnano" to "ipodnano2g" 21.35.05 # I also searched for everywhere "ipodnano" was referenced, and added ipodnano2g references as well... 21.35.17 # The ipodnano manual is building fine for me... 21.35.55 Quit stoffel (Read error: 113 (No route to host)) 21.40.07 # pixelma: Ah, the problem seems to be that "features" doesn't include "scrollwheel" 21.40.46 # ... because config-ipodnano2g.h doesn't have it... 21.40.52 # Hmm... 21.40.57 # hmm... wanted to ask you about features but then looked at the diffs 21.41.05 # or the one diff 21.41.54 # linuxstb: is the scrollwheel not working yet or what? 21.42.20 # Yes, it's working fine. 21.42.41 # So it's something wrong with the main config files - not the manual... 21.48.18 # kugel: obviously cant look at the code right now... but initial reaction is why are you adding any arrays? 21.49.05 # playback doesn't allow anything else 21.49.05 Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) 21.49.21 # this is to keep track of the AA handles? 21.49.26 # yes 21.49.43 # hmm... ok 21.49.45 # there's currently a aa_hid for each track, multiple albumart needs converting this into an array 21.50.04 # for some reason I thought you could use the aa struct in the skin 21.50.09 # I tried several approaches to make it on the skin buffer but it just can't work 21.50.24 # New commit by 03tomers (r23157): USB: Use explicit casting when setting wTotalLength field in descriptor 21.50.30 # I actually scrached my head several times the past week about it, starting like 5 different approaches, all failing 21.50.42 Quit Thundercloud (Remote closed the connection) 21.51.35 # the main problems with using the skin buffer is (a) properly bufclosing per track, and (b) not losing the handle ids by changing the skin 21.51.38 # so can a single skin have multiple AA's yet? 21.51.41 # OS X 10.4 users - please try whether r23157 fix "FS#10666 - Rockbox software USB doesn't connect with OS X 10.4" 21.51.53 Quit esperegu (Read error: 104 (Connection reset by peer)) 21.52.04 # * linuxstb wonders how the Nano2G was working without an HAVE_SCROLLWHEEL define... 21.52.18 # JdGordon|: that would be fairly easy to add. 21.52.41 # yes and no... 21.52.59 # for different sizes yes, but I want to load actually different images 21.53.13 # in my latest approach, each skin allocates a albumart slot (given by playback), saved in the skin_albumart struct. so theoretically each struct can have a slot 21.53.29 # well, not allocating technically 21.53.40 Quit rphillips (Client Quit) 21.53.55 Join rphillips [0] (n=rphillip@66-90-184-91.dyn.grandenetworks.net) 21.54.31 # New commit by 03Domonoky (r23158): rbutil: split tts.cpp/h into individual files. 21.54.33 # JdGordon|: displaying the next track aa would easy too 21.55.25 # it's just very troublesome since it might not be buffered (same problem with the id3 struct for the first unbuffered track) 21.56.59 # it's just a matter of returning the aa hid of track_ridx (+wps_offset)+1 21.58.32 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 21.58.53 # except what if we want next track smaller than it this track? 22.00.02 # my patch obviously includes a way to get aa of different sizes 22.00.40 # linuxstb: btw. I considered drawing this svg fo today in the evening even before I read your question here. Looks like it's really easy, the proportions seem to be exactly the same compared to those of the 1st gen (except the rounded corners of course), even screen and scrollwheel position. 22.00.48 # linuxstb: do you think that define was what broke rockboy on the nano2g? 22.00.53 # sure.. right... but you couldnt just grab the next tracks aa image if they arent the same size... it needs to be loaded twice 22.01.07 # Dgby714: Is Rockboy broken? 22.01.22 # certain default buttons dont work 22.01.25 # pixelma: Yes, I think it is. 22.01.29 # JdGordon|: yes I'm aware of that, it surely needs to be buffered twice 22.01.49 # that just worsens the problem of that the next track aa might not be buffered at all 22.01.49 # Rockboy is using those touch positions though 22.02.04 # Dgby714: I'm not sure... I can't see rockboy using that #define. 22.02.18 # linuxstb: ok 22.02.45 # * linuxstb tries copying the nano1g defines, and the scrollwheel is now crazy - it just needs a _very_ tiny movement to move items. 22.03.05 Join stoffel [0] (n=quassel@p57B4F487.dip.t-dialin.net) 22.03.23 # I don't think showing the next's track aa is a worthwhile enough feature considering the problems that arise 22.03.53 # linuxstb: if I trust my first gen Nano drawing it is ;) Are the labels on the buttons the same colour as the case - and the position of the hold switch top left if you hold it screen facing you? 22.04.51 # kugel: if it can be resized then heck yeah it would be a good feature 22.05.00 # pixelma: no and yes 22.05.12 # pixelma: Yes, I was looking at the 1st gen picture in the manual, and it's almost identical to my Nano, apart from the differences you said. My Nano2g is silver, with a white wheel, and silver labels. 22.05.24 # hmm... no. I meant button labels... they look grey in another picture 22.05.30 # JdGordon|: what would you do against the problem I mentioned? 22.05.30 # the labels are grey not the color of the case 22.05.38 # My case is grey... 22.05.43 # ;) 22.05.44 Join mrtok1 [0] (n=dummy@p4FCC6DAF.dip.t-dialin.net) 22.05.45 # call it "silver" ;) 22.05.45 # my case is blue 22.05.46 # assuming next track is always smaller than this track (or the same size in which case there is no problem), we could allocate a buffer in the skin buffer for it, so it then resizes from the MoB once its bufffered 22.06.25 # someone here knowing some insights of ipod nano 1g ? 22.06.37 # that means *only* de-rounding the corners and another gradient 22.07.15 # JdGordon|: that would break on rashers theme 22.07.17 # mrtok1: What do you mean? Do you have any specific questions? 22.07.32 # why? 22.07.46 # it's already using 95% of the skin buffer just for the skin alone 22.08.03 Join HBK- [0] (i=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 22.08.09 # linuxstb: yes - i see on my debug screen a cpu freq of max 80MHz - i think this is harwired to a crystal osc? 22.08.24 Quit KBH (Read error: 131 (Connection reset by peer)) 22.08.41 # and that still doesn't solve the problem that the next's track AA might not be buffered at all 22.09.06 # oh.. his widecabbie theme? didnt we alreqdy decide it was doing it very badly anyway? 22.09.22 # * Dgby714 wants to know why people go into a menu option that says "Keep Out!" in its name... 22.09.23 # and no... if its not buffered the %?Cn tag would be false 22.10.04 # I wouldn't get next's track AA on every song on my fuze... 22.10.54 Quit gevaerts (Nick collision from services.) 22.10.54 # /me just did an "svn up" and was suprised by the number of files chaged in a few days 22.10.58 # it would work the same as next *any* tag... it wouldnt be avilable untill its loaded 22.11.01 # *changed 22.11.03 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 22.11.13 # Dgby714: you said you have a blue Nano - do you know how it compares to the Mini's blue case (because I found a nicer pic of that one) 22.11.21 # linuxstb: i wrote some kind of soundprocessing very cpu intensive - don´t know where to tweak more except overclocking... 22.11.25 # unless you want to buffer next's track aa even if the currently playing song is still not buffered completely 22.11.25 # and showing next track's AA would be stupid for me most of them time because i usually only do albums, not mixes 22.12.08 # the fuze's audio buffer is so small, that it's more than full by a single song + id3 and aa 22.12.36 # mrtok1: the cpu frequency is variable. if you call boost() in you plugin, you will the 80Mhz, thats all you can get (without using the other core somehow). 22.12.43 # +get 22.12.45 # pixelma: never seen a mini before O.o Pic on my ipod ---> http://l4n.clustur.com/index.php/File:Rockbox.jpg 22.12.59 # s/on/of/ 22.13.10 # for other targets too, it would be unavailable too often to be usefull at all 22.13.19 # kugel: sure, but the targets with more than 8MB buffer could easily have 2 or 3 images in the buffer.... so it would be a great feature to add... despite some obvious flaws 22.13.56 # Dgby714: I was already pointed to that one but thanks again :) 22.14.05 # lol 22.14.12 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 22.14.32 # * Dgby714 's ipod is all scar'd up 22.14.35 # domonoky: when i use my plugin i see the 80MHz on the debug screens for pcm buf thread - and thats not so good silence, when pcm becomes empty... 22.15.06 # mrtok1: Are you using floating-point math? 22.15.19 # linuxstb: no 22.15.30 # linuxstb: all fixed-point + asm 22.15.49 # I guess using the COP (second CPU) is an option... 22.16.02 # mrtok1: if you already call boost in your plugin, the only way to get better performance it to improve the code (or somehow use the other core) 22.16.10 # linuxstb: a second cpu? 22.16.14 # multiple AA per skin *and* per screen needs additional work, it needs some more work despite my patch 22.16.21 # ipods have 2 80Mhz cores. 22.16.22 # mrtok1: Yes ;) Although some audio codecs are already using that... 22.16.36 # linuxstb: sounds great ! 22.16.49 # mrtok1: And it's not straightfoward to use - they have independent caches, so you need to deal with that. 22.17.18 # linuxstb: some pointers to codec which make use of the second cpu? 22.17.24 # If you wait until later tonight, saratoga may be around - he ported the mp3 codec to use both CPUs, so may have some ideas. 22.17.46 # mrtok1: mp3 is one. spc is another (I think). 22.18.17 # linuxstb: could you clarify? what means later - have to watch 24 right now ;-) 22.18.42 # He's normally around in the US evening - i.e. 2 or 3 hours from now. 22.20.45 # linuxstb: thank you very much! will check that bits - and maybe i´m back later - thx again! 22.20.57 # mrtok1: So you've written a plugin, not a DSP function? i.e. you don't process the normal audio that's played in Rockbox? 22.21.04 # need some help: If I want to use the INT_DMAC isr in dma-pl081.c to signal the wakeup_wait in ata_sd_as3525 how do I tell it where &transfer_completion_signal is which is declared in ata_sd_as3525... 22.21.19 # linuxstb: dsp function 22.21.36 # mrtok1: OK... Go and watch 24 now ;) 22.21.46 # linuxstb: hooked in ChannelConfiguration 22.22.05 # linuxstb: yes ... bye 22.23.10 # FlynDice, I'll have a look 22.23.43 # FlynDice: use a function to access it (cleaner) or make it non-static and declare it as extern in dma-pl081.c (less overhead) 22.23.49 # bertrik_: Great! You actually know what you're doing... 22.24.13 Quit mrtok1 () 22.24.33 *** Saving seen data "./dancer.seen" 22.24.39 # kugel: thanks I'll go look at that 22.24.55 # FlynDice, I think the natural think to do is to use the dma callback 22.25.12 # New commit by 03dave (r23159): Add HAVE_SCROLLWHEEL for the Nano2G, as they have a scrollwheel. 22.25.41 # linuxstb: interesting, the scrollwheel worked without? 22.26.06 # you probably also want HAVE_SCROLLWHEEL_ACCELERATION 22.26.08 # Yes, that define isn't used in many places. 22.26.37 # kugel: That's for later... I tried copying the #defines for that from the nano1g, and the wheel was far too sensitive. 22.26.50 # * linuxstb can't believe Rockbox is like that on the nano1g... 22.26.53 # FlynDice, currently this callback mechanism is unused in ata_sd_as3525, but you can provide a function to dma_enable_channel that is called when DMA is finished 22.27.05 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 22.27.19 # is there a way to have to .rockbox dirs and have two rockbox bin (on the nano2g make one be rockbox.ipod, the other one custom.bin) to have one RO and one RW so if the RW crashes it doesn't trash all the RO files ? 22.27.21 # bertrik_: that seems like the best way to do 22.27.29 # is it crazy sensitive on the 2g now too, linuxstb ? 22.27.59 # New commit by 03dave (r23160): Changes to build a Nano2G manual. It is now just missing the ipodnano2g-front.* images 22.28.19 # topik: No, I didn't commit that change. Just the change to say that it has a wheel. 22.29.09 # linuxstb: I changed it a while ago, HAVE_SCROLLWHEEL is only used for keymaps stuff these days 22.29.29 # it doesn't bring any generic wheel code with it (or shouldn't, rather) 22.29.48 # bertrik_: Sorry, I'm still learning here and callback is in tomorrow's lesson... I see the PCM callback and understand what It's doing but actually implementing it is a bit beyond me right now... 22.30.16 # polobric1lo: Use the "--rbdir" when you run tools/configure to change ".rockbox" to something else. Then use that resulting "rockbox.bin" as your "custom.bin" 22.30.16 # * bluebrother figured the libspeex issue with rbutil 22.30.37 # linuxstb: ok thanks 22.32.53 # FlynDice, callbacks are often used to keep things loosely coupled, so low-level functionality DMA doesn't explicitly need to know about higher-level functionality like PCM and SD transfers. It's a quite ingenious and powerful thing :) 22.32.57 # Dgby714: Rockboy might not be working because HAVE_WHEEL_POSITION isn't defined for the nano2g... 22.33.21 # ah 22.33.54 # wow rockbox looks much more stable than before on the nano2g 22.34.10 Join pamaury [0] (n=pamaury@91-164-182-50.rev.libertysurf.net) 22.34.15 # Dgby714: Wait a few minutes - I'm just doing a test build, then I'll commit. 22.34.16 Quit JackWinter2 (Read error: 60 (Operation timed out)) 22.34.30 # ok kool 22.34.52 Quit stoffel (Remote closed the connection) 22.34.55 Join JackWinter2 [0] (n=jack@vodsl-10804.vo.lu) 22.34.57 # oh no i got a panic on reboot 22.35.06 Quit bmbl ("Bye!") 22.35.49 # "FTL: Scheduling bank 1 bloxk 3081 for remap" what does that mean 22.36.05 # it wants norboot to remap it ? 22.36.22 # New commit by 03dave (r23161): The Nano2G also qualifies for HAVE_WHEEL_POSITION 22.36.31 # are you using the latest revision? 22.36.42 Quit TheSeven (Read error: 113 (No route to host)) 22.36.43 # haven't seen that ftl error for a day or so 22.36.53 # * linuxstb guesses no-one is using the latest revision, as he committed it 30 seconds ago 22.37.07 # lol i am =) 22.37.31 # do the new defines change anything 22.37.52 # I would hope so, otherwise why did I add them? ;) 22.37.55 # err was... waiting on this commit to inclue HAVE_WHEEL_POSITION 22.38.12 # lol 22.38.18 # linuxstb: to make the code cleaner ? 22.38.34 # polobric1lo: The first was just some minor buttonmap/cosmetic change, the second should make rockboy work. 22.38.43 # HAVE_WHEEL_POSITION should fix the button problem in rockboy 22.38.44 # s/work/work better/ 22.38.55 # linuxstb beat me 22.38.56 # Or rather, "suck less" 22.39.00 # lol 22.39.17 # * Dgby714 is gonna beat a few pokemon games tonight =O 22.39.21 # err 22.39.28 # beats not the word.. 22.42.18 # s/beat/get bored of/ 22.42.38 # * linuxstb sees another place $modelname from configure is used - name of images in the UI simulator... 22.45.07 # hmm is there a way to make a vmware drive bigger? 22.45.28 # yes, but that is drifting off the topic of this channel 22.46.44 # ok umm i get a error when trying to install the tetex-base and thing to build the manuals, my drive is too small 22.48.44 Join funman [0] (n=fun@rockbox/developer/funman) 22.49.46 # FlynDice: you can have a look at r19714 22.50.35 # Dgby714: then enlarge the drive...either way, it is a vmware issue, not a rockbox one.. 22.51.22 # New commit by 03Domonoky (r23162): rbutil: rework and rename the "dont overwrite talkfiles" option so it really generates only new Talkfiles. 22.51.29 # New commit by 03dave (r23163): Changes to make the Nano2G sim build. It is still missing a UI-ipodnano2g.bmp 22.52.32 # so 22.52.43 # assuming i have a very limited knowledge of programming 22.52.58 # how difficult would it be for me to write a sbagen plugin? 22.53.28 # New commit by 03bluebrother (r23164): Fix building Rockbox Utility when using newer versions of libspeex. 22.55.57 # New commit by 03bluebrother (r23165): Add the left brace again that was unintentionally lost. 22.56.34 # HBK-: depends on how easily you can improve your coding knowledge :-) 22.56.53 # hrmmmmm 22.57.07 Nick polobric1lo is now known as polobricolo (n=paul@AGrenoble-257-1-77-78.w86-211.abo.wanadoo.fr) 23.00.14 # linuxstb, Dgby714: is the select button a bit hmm "rounded" or flat? 23.00.36 # rounded into the ipod 23.00.48 # but very slightly 23.03.27 # hrm 23.03.33 # i suppose it should be a codec 23.07.36 Quit Lss (Read error: 54 (Connection reset by peer)) 23.09.40 Join FOAD_ [0] (n=dok@dinah.blub.net) 23.15.21 Join stephen_ [0] (n=stephen@86-45-101-88-dynamic.b-ras2.srl.dublin.eircom.net) 23.18.37 Quit kkurbjunW (Remote closed the connection) 23.19.58 Quit funman ("free(random());") 23.20.24 Join kkurbjunW [0] (n=karlk@12.41.166.9) 23.21.38 Quit FOAD (Read error: 110 (Connection timed out)) 23.21.39 Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) 23.22.00 Join TheSeven [0] (n=theseven@rockbox/developer/TheSeven) 23.22.24 Quit feisar-_ (Read error: 104 (Connection reset by peer)) 23.22.34 # hm, a new ipodpatcher got released and it still has the same pp bootloaders? :( 23.23.04 Join freddyb [0] (n=46695b5e@83.168.254.42) 23.23.16 Quit evilnick_ ("Page closed") 23.28.06 # Torne: not the 0.6 ones? 23.29.08 Quit TheSeven (Nick collision from services.) 23.29.25 Join The_Seven [0] (n=theseven@rockbox/developer/TheSeven) 23.29.36 # no, 3.0 23.29.37 Nick The_Seven is now known as TheSeven (n=theseven@rockbox/developer/TheSeven) 23.29.57 # but i've been prodding people for a while to do a new version of the ipod bootloader 23.29.59 Quit pamaury ("exit(*(int *)0 / 0);") 23.30.05 # (with the changes to allow booting rockbox from OSOS) 23.30.08 # and that's still not in there 23.33.48 Quit freddyb ("CGI:IRC (EOF)") 23.33.54 Quit bertrik_ (Remote closed the connection) 23.37.42 # Torne: I assumed as there had just been a new PP bootloader release that nothing had changed... Why weren't they included last time? 23.37.44 Join DerPapst1 [0] (n=DerPapst@p4FE8EFED.dip.t-dialin.net) 23.37.53 # because nobody listened to me last time :) 23.38.09 # unfortunately i pointed out that the ipod bootloaders *already* didn't reboot to the OF on USB connection 23.38.20 # and thus someone decided that there was no change in behaviour and no new ipod bootloader was needed 23.39.00 # the ipod bootloader is kinda seperate to the other PP oens 23.39.41 # it's not vital or anything 23.40.09 # but it would let me simplify the alternate-install-method instructions on the IpodPatcher wiki page (as currently you need to build your own bootloader to use them) 23.40.11 Part domonoky 23.40.15 # Torne: Can you remind me what your change was? Have you seen how the nano2g boots? (I rename "osos" to "osbk" and install the Rockbox bootloader as a new osos image. dual-boot works by loading osbk) 23.40.36 # my change was to have the "load rockbox" option check to see if the OSOS image already in ram is in fact rockbox 23.40.46 # i.e. if the OSOS is rockbox with the bootloader appended 23.41.05 # http://www.rockbox.org/wiki/IpodPatcher#2_OSOS_contains_Rockbox_and_the <- this way 23.41.05 # Ah, option 2) here? http://www.rockbox.org/wiki/IpodPatcher 23.41.08 # yes 23.41.20 # the 3.4 stable release now has the rockbox-side code to make that work 23.41.32 # so if there was an ipodpatcher which had the bootloader-side code, people could do that without compiling. 23.42.41 # like i said it's not a big deal 23.42.52 # anyone who's likely to want to actually *do* that is probably compiling themselves anyway :) 23.43.19 # i just would've mentioned it again slightly sooner if I'd noticed you were doing a new ipodpatcher release in time ;) 23.44.30 # Everyone interested in the BuildNames cleanup: I've started a table on the BuildNames wiki page to collect where a name is used. I hope to get this filled :) 23.44.31 # I just wanted to get binaries for the nano2g released, I wasn't keen on doing a whole ipod bootloader release... 23.44.40 # it's ok 23.44.53 # ultimately it was my itch 23.44.59 # and i use my own build and my own bootloader anyway ;) 23.45.11 # but there are a couple of other people on the forums who do it that way, at least. 23.45.25 # i didn't exactly advertise it, as it's not trivial :) 23.46.06 Join bertrik_ [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 23.46.27 # bluebrother: Shouldn't that table be transposed? i.e. I think we have few names, but lots of places 23.47.51 # linuxstb: probably. I was thinking about that for a bit and then decided to just add it for now :) 23.49.32 # the table at the bottom looks weird, how do I use it? 23.50.24 # TheSeven: what does your HAVE_USB_CHARGING_ENABLE code do on ipodnano2g? is it enabling/disabling usb charging entirely, or just selecting 100/500mA? 23.50.40 # * Torne is looking at sorting this usb charging stuff on ipodvideo (and similar) 23.50.49 # ah I think I understand. configure name is used for the theme site. shouldn't be configure is used for configre there too (for completeness)? 23.52.03 # is there some way to get rockbox to not preload the whole song before it starts playing? 23.52.14 # it doesn't 23.52.38 # it does for me 23.54.59 # ender: Are you talking about the first song, or subsequent songs? 23.55.26 # first song 23.55.37 # i don't care about subsequent songe 23.55.38 # linuxstb: will you keep the ipodnano2g as "specimg"? I just want to know to get the name right so it'll be used for the manual 23.55.38 Quit HBK- (Read error: 104 (Connection reset by peer)) 23.55.49 # automatically 23.56.18 # pixelma: I'm not sure what you mean. "ipodnano2g" is the name I'm using everywhere for it. 23.56.51 # (those get loaded while the song is already playing, so they don't make me wait) 23.56.51 Join HBK- [0] (i=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 23.57.27 # ender: it really doesn't. it has to read the metadata, album art, and the codec itself if it's different to the last one 23.57.51 Quit HBK- (Read error: 104 (Connection reset by peer)) 23.58.19 # how do you know it's loading the whole song? 23.58.21 # ender: it *really* doesn't 23.58.31 # are you actually watching the buffering debug screen? 23.58.35 # or are you just guessing based on how long it takes/ 23.58.41 # what you notice might be delay resulting from scaling up/down the albumart 23.58.56 # linuxstb: Rockboy is working great