--- Log for 12.08.109 Server: simmons.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 2 months and 10 days ago 00.00.04 Join linuxstb_ [0] (n=linuxstb@rockbox/developer/linuxstb) 00.00.10 Quit linuxstb (Nick collision from services.) 00.00.14 Nick linuxstb_ is now known as linuxstb (n=linuxstb@rockbox/developer/linuxstb) 00.00.46 # DarkSpectrum, toor? 00.01.03 # nope 00.01.09 # isnt it in the wiki page? 00.01.13 # nope 00.01.17 # root:rockbox 00.01.19 # only has the user login 00.01.23 # user:rockbox 00.01.26 # DarkSpectrum: check the wiki, IIRC it's documented somewhere there. 00.01.27 # root:password 00.01.32 # got it 00.01.34 # thanks 00.01.43 # add it to the wiki 00.01.45 # which was it? 00.02.49 # VMwareDevelopmentPlatform 00.04.27 Quit bluebrother ("leaving") 00.10.58 Quit bmbl ("Bye!") 00.12.43 Quit Lynx_ (" Try HydraIRC -> http://www.hydrairc.com <-") 00.16.53 Quit TruthTaco (Read error: 110 (Connection timed out)) 00.17.38 Join TruthTaco [0] (n=truthtac@adsl-74-11-71.aby.bellsouth.net) 00.17.55 Quit stripwax (Read error: 104 (Connection reset by peer)) 00.19.19 Quit J-23 ("Flying cow pressed ^D on my keyboard.") 00.21.12 Quit pamaury ("Quitte") 00.29.41 Quit linuxstb (Read error: 110 (Connection timed out)) 00.34.28 Quit ender` (" Computers work fine as long as users aren't allowed anywhere near them.") 00.36.08 Quit efyx (Remote closed the connection) 00.36.19 Quit captainkwel ("Page closed") 00.46.25 Join bittin_ [0] (i=bittin@anapnea.net) 00.55.57 Quit Zagor ("Clint excited") 00.57.12 Quit bertrik (Read error: 113 (No route to host)) 00.57.48 Quit GeekShadow ("The cake is a lie !") 00.59.27 # gevaerts: if it's 2D, are there going to be "corner" covers, or just covers extending up and down from center as well as to each side? 01.00.21 # I'd just use a cross 01.00.39 # i go to album *fairly* often, because when i'm out with my family that's a faster way to find something that i can actually listen to with my daughter 01.01.47 # ok... a cross with the up/down items displayed flat is fairly easy to draw. with the up/down items tilted will require some new drawing code. with corner covers that are tilted around both x and y axes i don't want to touch (and it will be slow on archos then ;) 01.03.46 Join Strife1989 [0] (n=michael@adsl-146-208-20.mcn.bellsouth.net) 01.03.49 # i have no idea how i would actually organize the data in that case, either... i suppose keeping the same all-albums list adding an artist list with a pointer to the first album per artist would do 01.04.12 Quit Strife89 (Nick collision from services.) 01.04.20 Nick Strife1989 is now known as Strife89 (n=michael@adsl-146-208-20.mcn.bellsouth.net) 01.04.52 # also, nobody but you has "artist art"... and you have that as your album covers :P 01.06.25 # well, maybe there's another way, but I really think that a single linear list of all albums must be about the worst possible way to organise your music 01.07.27 Quit jfc (Read error: 104 (Connection reset by peer)) 01.07.36 # gevaerts: it's pretty, though ;) 01.08.44 Quit dmb (Read error: 104 (Connection reset by peer)) 01.11.00 # letting the accel go faster doesn't, by itself, strike me as a great idea, since at top speed the animation gets down to about one frame per cover. i think that switching to letters when you hit the accel cap might be nifty... 01.13.04 *** Saving seen data "./dancer.seen" 01.21.15 Join webguest63 [0] (n=8fa6e22a@gateway/web/cgi-irc/labb.contactor.se/x-c21e4d5c1a472e83) 01.21.53 Quit z35 (Read error: 113 (No route to host)) 01.24.05 Quit webguest63 (Client Quit) 01.25.58 Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 01.26.25 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 01.32.49 Quit Thundercloud (Remote closed the connection) 01.41.49 Join JdGordon_ [0] (i=ad7541b0@gateway/web/freenode/x-ebdf8a0f67211f03) 01.43.04 Join brenosabino [0] (n=bb28bc6d@gateway/web/cgi-irc/labb.contactor.se/x-d35ef50388e8806f) 01.45.14 Join CaptainKwel [0] (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 01.47.41 Quit Strife89 (Read error: 110 (Connection timed out)) 01.49.02 Quit faemir ("Leaving") 01.50.57 # Hello 01.56.29 Quit brenosabino ("CGI:IRC (EOF)") 01.57.39 Part toffe82 02.00.08 Quit jgarvey ("Leaving") 02.00.40 Quit Rondom (Nick collision from services.) 02.00.51 Join Rondom [0] (n=Rondom@dslb-084-057-149-134.pools.arcor-ip.net) 02.04.43 Quit pixelma_ (" .") 02.04.44 Quit DarkSpectrum (Read error: 104 (Connection reset by peer)) 02.05.25 Quit JdGordon_ (Ping timeout: 180 seconds) 02.44.43 Join advcomp2019_ [0] (n=advcomp2@unaffiliated/advcomp2019) 02.46.12 Quit markun (simmons.freenode.net irc.freenode.net) 02.46.12 NSplit simmons.freenode.net irc.freenode.net 02.46.12 Quit panni_ (simmons.freenode.net irc.freenode.net) 02.46.12 Quit Beta2K (simmons.freenode.net irc.freenode.net) 02.46.12 Quit gevaerts (simmons.freenode.net irc.freenode.net) 02.46.12 Quit AndyIL (simmons.freenode.net irc.freenode.net) 02.46.12 Quit Ridayah (simmons.freenode.net irc.freenode.net) 02.46.12 Quit Dhraakellian (simmons.freenode.net irc.freenode.net) 02.46.12 Quit maraz (simmons.freenode.net irc.freenode.net) 02.46.12 Quit linuxguy3 (simmons.freenode.net irc.freenode.net) 02.46.12 Quit blithe_ (simmons.freenode.net irc.freenode.net) 02.48.57 Quit Llorean (simmons.freenode.net irc.freenode.net) 02.48.57 Quit tarbo_ (simmons.freenode.net irc.freenode.net) 02.48.57 Quit krazykit (simmons.freenode.net irc.freenode.net) 02.48.57 Quit preglow (simmons.freenode.net irc.freenode.net) 02.48.57 Quit rphillips (simmons.freenode.net irc.freenode.net) 02.48.57 Quit avacore^ (simmons.freenode.net irc.freenode.net) 02.48.57 Quit advcomp2019 (simmons.freenode.net irc.freenode.net) 02.48.57 Quit dionoea (simmons.freenode.net irc.freenode.net) 02.48.57 Quit fuzzie (simmons.freenode.net irc.freenode.net) 02.48.57 Quit gibbon_ (simmons.freenode.net irc.freenode.net) 02.48.57 Quit pike (simmons.freenode.net irc.freenode.net) 02.49.14 # Unhelpful: any plans on committing the lcd driver work? 02.49.35 NHeal simmons.freenode.net irc.freenode.net 02.49.35 NJoin panni_ [0] (i=hannes@ip-95-222-19-21.unitymediagroup.de) 02.49.35 NJoin Beta2K [0] (n=beta@d24-36-68-97.home1.cgocable.net) 02.49.35 NJoin gevaerts [0] (n=fg@rockbox/developer/gevaerts) 02.49.35 NJoin AndyIL [0] (i=AndyI@212.14.205.32) 02.49.35 NJoin Ridayah [0] (n=ridayah@173-19-229-228.client.mchsi.com) 02.49.35 NJoin linuxguy3 [0] (n=timj@adsl-68-253-209-176.dsl.emhril.ameritech.net) 02.49.35 NJoin maraz [0] (i=maraz@xob.kapsi.fi) 02.49.35 NJoin Dhraakellian [0] (n=ntryon@cpe-72-226-197-191.rochester.res.rr.com) 02.49.35 NJoin markun [50] (n=markun@rockbox/developer/markun) 02.49.35 NJoin blithe_ [0] (n=blithe@blakesmith.me) 02.49.51 Join Llorean [0] (n=DarkkOne@rockbox/user/Llorean) 02.49.51 NJoin tarbo_ [0] (n=me@unaffiliated/tarbo) 02.49.51 NJoin krazykit [0] (n=kkit@c-24-218-166-241.hsd1.ma.comcast.net) 02.49.51 NJoin preglow [0] (i=thomj@tvilling2.pvv.ntnu.no) 02.49.51 NJoin pike [0] (n=pike@xbmc/gc/pike) 02.49.51 NJoin advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) 02.49.51 NJoin rphillips [0] (n=rphillip@unaffiliated/rphillips) 02.49.51 NJoin fuzzie [0] (n=fuzzie@twinsen.warpedgames.com) 02.49.51 NJoin gibbon_ [0] (i=gibbon_@could.become.a.servant4you.org) 02.49.51 NJoin avacore^ [0] (i=nobody@1008ds1-rdo.0.fullrate.dk) 02.49.51 NJoin dionoea [0] (n=dionoea@videolan/developer/dionoea) 02.49.59 # kugel: markun had remembered objections being raised to the merge at some point... i was thinking i ought to take a call on the mail list for comment before merge. 02.50.17 # what objection? 02.50.29 # he didn't remember that part :) 02.50.35 # huh 02.50.53 # that's not a valid objection then 02.50.57 # I can't really imagine any 02.52.45 # coding style comes to mind, or binsize - a choice has to be made between accepting positive deltas on some targets or having C-code includes. 02.52.45 Quit thegeek (Read error: 54 (Connection reset by peer)) 02.53.24 # i personally think that the latter are OK pretty much any time that they provide benefits - in this case reduced duplication without a binsize hit. 02.54.31 Quit jhulst ("Read error: EOF") 02.54.51 Join jhulst [0] (n=jhulst@jhulst.com) 03.01.15 Quit preglow (simmons.freenode.net irc.freenode.net) 03.01.15 Quit Llorean (simmons.freenode.net irc.freenode.net) 03.01.15 Quit rphillips (simmons.freenode.net irc.freenode.net) 03.01.15 Quit avacore^ (simmons.freenode.net irc.freenode.net) 03.01.15 Quit advcomp2019 (simmons.freenode.net irc.freenode.net) 03.01.15 Quit dionoea (simmons.freenode.net irc.freenode.net) 03.01.15 Quit fuzzie (simmons.freenode.net irc.freenode.net) 03.01.15 Quit gibbon_ (simmons.freenode.net irc.freenode.net) 03.01.15 Quit pike (simmons.freenode.net irc.freenode.net) 03.01.15 Quit krazykit (simmons.freenode.net irc.freenode.net) 03.01.15 Quit tarbo_ (simmons.freenode.net irc.freenode.net) 03.01.25 # Unhelpful: what are you talking about? 03.01.32 # where do you want to include c code? 03.01.40 # kugel: look at the patch? :P 03.02.25 # it replaces the bulk of the LCD bitmap text code in each lcd driver with #include 03.02.45 NJoin Llorean [0] (n=DarkkOne@rockbox/user/Llorean) 03.02.45 NJoin tarbo_ [0] (n=me@unaffiliated/tarbo) 03.02.45 NJoin krazykit [0] (n=kkit@c-24-218-166-241.hsd1.ma.comcast.net) 03.02.45 NJoin preglow [0] (i=thomj@tvilling2.pvv.ntnu.no) 03.02.45 NJoin pike [0] (n=pike@xbmc/gc/pike) 03.02.45 NJoin advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) 03.02.45 NJoin rphillips [0] (n=rphillip@unaffiliated/rphillips) 03.02.45 NJoin fuzzie [0] (n=fuzzie@twinsen.warpedgames.com) 03.02.45 NJoin gibbon_ [0] (i=gibbon_@could.become.a.servant4you.org) 03.02.45 NJoin avacore^ [0] (i=nobody@1008ds1-rdo.0.fullrate.dk) 03.02.45 NJoin dionoea [0] (n=dionoea@videolan/developer/dionoea) 03.02.48 # Unhelpful: uh, I didn't see that yet 03.02.52 # why is that? 03.03.23 Quit tarbo_ (SendQ exceeded) 03.03.35 # if the functions live in a different file some targets take a binsize and speed hit due to long calls - almost all of the ARM7, and i don't *know* how it works on coldfire but binsize was larger there without the include. 03.04.04 Quit Llorean (Connection timed out) 03.04.21 Join jhulst_ [0] (n=jhulst@jhulst.com) 03.04.25 # I think you're a bit too obsessed with that long calls 03.04.52 # I don't like this including either 03.04.53 # and i think that this shouldn't cost speed or size if it doesn't have to. :) 03.04.54 Quit advcomp2019 (Connection timed out) 03.05.00 Quit jhulst (Success) 03.05.00 Nick jhulst_ is now known as jhulst (n=jhulst@jhulst.com) 03.05.14 # all of the LCD remote drivers work this way already, btw. :) 03.05.50 # it's not *just* that, either. without the include some static variables have to be non-static, which leads to them needing renames to avoid name clashes. 03.06.34 # which? the default viewport? 03.06.42 # no, the current viewport. 03.08.27 # on targets with a remote, making this non-static is a minor problem as they have the same name. either the current viewport needs a different name per display, or only the main-LCD current VP can be declared non-static. i don't like conditional qualifiers *much* better than a C-file include. 03.08.29 # I'm not really convinced of that including, but this stuff is still better than the massive duplication we have now 03.10.21 # bringing it up on the is an awesome idea :> 03.10.32 # ML? :) 03.11.04 # yea 03.13.08 *** Saving seen data "./dancer.seen" 03.17.52 # Unhelpful: I don't think the name clash is much of a problem 03.18.43 Join moos [0] (i=mustapha@rockbox/staff/moos) 03.18.46 # well, adding prefixes is a rather invasive change that i'd like to stay away from 03.20.06 # it's a search&replace job, much less controversial 03.20.15 # a conditional static qualifier is a better change - i'm *assuming* that the existence of a non-static current_vp will not override the static one in the LCD remote driver at link time? 03.21.22 # and most of the time "current_vp" can be a #define to main_current_vp or remote_current_vp 03.22.23 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 03.22.31 Join tarbo [0] (n=me@unaffiliated/tarbo) 03.22.46 # i also don't like the idea of this costing binsize on some targets. on top of that, there would *still* be a C-file include from lcd-remote-bitmap-common.c ;) 03.43.23 Join darkham [0] (n=Soreme@95.234.18.47) 03.44.03 Join StealthyXIIGer [0] (n=stealthy@ppp-69-216-120-135.dsl.sfldmi.ameritech.net) 03.46.51 Quit kugel (Remote closed the connection) 03.54.22 Join Strife89 [0] (n=michael@adsl-220-102-147.mcn.bellsouth.net) 03.54.54 Quit panni_ ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 03.57.41 Quit parafin (simmons.freenode.net irc.freenode.net) 03.57.41 NSplit simmons.freenode.net irc.freenode.net 03.57.41 Quit Tristan (simmons.freenode.net irc.freenode.net) 03.57.41 Quit bubsy (simmons.freenode.net irc.freenode.net) 03.57.41 Quit Erant (simmons.freenode.net irc.freenode.net) 03.57.41 Quit Galois (simmons.freenode.net irc.freenode.net) 03.58.32 Part darkham 04.00.33 Join bubsy_ [0] (i=Bubsy@94.139.72.137) 04.00.33 NHeal simmons.freenode.net irc.freenode.net 04.00.33 NJoin parafin [0] (i=parafin@paraf.in) 04.00.33 NJoin Tristan [0] (n=Tristan@i.dont.want.to.die.virgin.net.in) 04.00.33 NJoin Galois [0] (i=djao@efnet.math.uwaterloo.ca) 04.00.34 NJoin Erant [0] (i=erant@plz.stfu.kthnx.org) 04.06.48 Quit TheSeven (Nick collision from services.) 04.07.03 Join The_Seven [0] (n=theseven@dslb-084-056-132-201.pools.arcor-ip.net) 04.07.07 Nick The_Seven is now known as TheSeven (n=theseven@dslb-084-056-132-201.pools.arcor-ip.net) 04.07.07 Join brenosabino [0] (n=bb28bc6d@gateway/web/cgi-irc/labb.contactor.se/x-b868dd776d318953) 04.09.12 # hey guys, has anyone got playback working on c200v2? 04.09.32 # i think the wiki says it works 04.10.00 # its not working for me in the latest build 04.10.11 Quit timc (Read error: 110 (Connection timed out)) 04.12.29 # try running a build thats reported to work and see if it works for you 04.12.40 # then you'll know if its something wrong with your end or the current build 04.15.43 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 04.16.38 # i dont know which build was working. in the latest releases they fixed something for low ram devices like mine but it didn't help. 04.18.48 # I commited that, and it doesn't fix anything, it just disables a feature which doesn't work on those targets 04.20.20 # btw on the latest release when i compiled it didnt had fm radio or any plugin anymore in the build 04.20.59 Join Adam-g1 [0] (i=Adam-g1@ip68-103-98-103.ks.ok.cox.net) 04.21.28 # hey all, I need some help with rockbox on my cowon d2 >.> anybody help me please? 04.21.47 Quit StealthyXIIGer (Read error: 110 (Connection timed out)) 04.22.12 # ask a question 04.23.00 # * JdGordon would just about kill for multifont about now... 04.23.18 # well.. it seems to work pretty nicely, but when I try to play my mp3's, I can't seem to find my memory card in the file browser 04.23.40 # does it not support memory cards yet? 04.24.46 # I can seem to only access the memory that's on the D2 :/ 04.26.47 # -_- 04.29.13 # New commit by 03kkurbjun (r22262): M:Robe 500: Make endpoint requests more flexible. 04.29.23 # Is there any chance that flac playback works someday on c200v2? 04.29.54 # I could play my flacs at my nokia phone but it has a damn hiss problem at the 2.5mm port. 04.29.57 # no reason why not... assuming that is a target we are working on 04.30.06 # it'll probably be fixed eventually since its so similar to the clip 04.31.19 Nick bubsy_ is now known as bubsy (i=Bubsy@94.139.72.137) 04.33.53 Quit Adam-g1 () 04.34.10 # New commit by 03kkurbjun (r22263): M:Robe 500: Put the irq stack and fiq stack in iram. Reduce memory for fiq stack since it is currently unused. 04.45.58 Quit Strife89 ("Bed.") 04.51.24 Nick advcomp2019_ is now known as advcomp2019 (n=advcomp2@unaffiliated/advcomp2019) 05.05.13 # ill try build 21693 at my c240v2 now. seems to be the last working build on the clipv1 according to anythingbutipod forums 05.13.12 *** Saving seen data "./dancer.seen" 05.14.12 # can i patch the firmware with old bootloader using the newest mkamsboot? Or do I need to compile the old version too? 05.16.04 Quit brenosabino ("CGI:IRC") 05.16.08 Join brenosabino [0] (n=bb28bc6d@gateway/web/cgi-irc/labb.contactor.se/x-068b4ccd5941f47e) 05.20.46 # . 05.23.00 # ffffffffuu.... 05.23.20 # still just plays a few seconds even with a very low bitrate (32bkps) mp3 05.24.13 # time to go to bed. 05.24.31 Quit brenosabino ("CGI:IRC") 05.33.22 Quit tchan ("WeeChat 0.3.0-rc2") 05.35.24 Join tchan [0] (n=tchan@lunar-linux/developer/tchan) 05.39.13 Quit ehntoo (Read error: 110 (Connection timed out)) 05.50.38 Quit Horscht ("Verlassend") 05.51.21 Join Necos [0] (i=1001@cpe-76-169-21-84.socal.res.rr.com) 05.52.43 # is there anyone using the japanese language pack around? 05.55.24 # just trying to figure out why some characters showed up under the japanese sansa firmware and not the rockbox lang pack 05.56.12 # missing glyphs in the fonr 05.56.14 # fopnt 05.56.16 # font 05.56.42 # according to the svn notes, there are no glyphs missing... just an oversight? 05.57.16 # which font is this? 05.57.17 # it could be 05.57.26 # 16-gnu 05.58.44 # 16-GNU-Unifont 05.58.52 Join DarkSpectrum [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 05.58.59 # that should support everything in unicode 05.59.18 # are your tags originally in unicode? 05.59.35 # that's what i thought... i could be wrong 06.01.20 # 浜崎あゆみ <---- doubt this shows up properly 06.02.32 # i thought they were all in UTF-8... i might have screwed something up nonetheless... 06.02.47 # audacious and winamp both pick up the fonts, however... 06.03.25 # although i have the auto-detection in audacious set for japanese 06.03.44 # thats awsome, didn't even know i was using a unicode font 06.04.37 # did it show up properly? 06.04.58 # for me it did 06.05.11 # it didn't even show up for me in urxvt lol 06.05.25 # anyway, on topic, is my build client still showing warnings? 06.07.28 # i see the 15 warnings on build 22260, but i want to verify my last build was submitted without warnings 06.07.49 # what build client? 06.08.59 # SaturnCore-DarkSpectrum 06.09.27 # I don't see any errors on the build table 06.09.47 # trying to see if mine even submitted anything 06.09.58 # the logs say you did a few builds 06.10.42 # is there an easy way i can search the log to see what i've done? 06.10.51 # i'll have to double-check my fonts and make sure they're in utf-8... i'll bbl 06.11.41 # theres a link next to each build in the table showing who built what 06.12.01 Quit Kumool ("Leaving") 06.13.00 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 06.13.24 # yeah but there has to be a faster way then hovering over each one to see who did it 06.14.12 # theres a link listing each build that you can search, its on the left hand side next to each build round 06.14.18 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 06.14.55 # ty 06.34.58 Quit mt (Read error: 104 (Connection reset by peer)) 06.35.46 Join mt [0] (n=MTee@rockbox/developer/mt) 06.44.02 Join intrados [0] (n=intrados@cpe-71-67-138-190.woh.res.rr.com) 06.59.43 Quit mt (Read error: 113 (No route to host)) 07.07.15 Join ehntoo [0] (n=ehntoo@adsl-99-156-195-44.dsl.applwi.sbcglobal.net) 07.13.15 *** Saving seen data "./dancer.seen" 07.23.36 Join timc [0] (n=aoeu@c-68-45-191-214.hsd1.pa.comcast.net) 07.24.27 Quit CaptainKwel (Remote closed the connection) 07.30.56 Join stoffel [0] (n=quassel@p57B4CC48.dip.t-dialin.net) 07.32.17 Quit ehntoo (Read error: 110 (Connection timed out)) 07.34.57 Join FOAD_ [0] (n=dok@dinah.blub.net) 07.51.51 Quit FOAD (Read error: 110 (Connection timed out)) 07.51.52 Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) 07.56.19 Quit bzed (simmons.freenode.net irc.freenode.net) 07.56.19 NSplit simmons.freenode.net irc.freenode.net 07.56.19 Quit martian67 (simmons.freenode.net irc.freenode.net) 07.57.21 NHeal simmons.freenode.net irc.freenode.net 07.57.21 NJoin bzed [0] (n=bzed@devel.recluse.de) 07.57.21 NJoin martian67 [0] (n=martian6@about/linux/regular/martian67) 07.58.35 # Unhelpful: Some lcd drivers use C code includes already (the ones where the same pixel format exists for main and remote displays) 07.59.23 # Including a .c isn't really nice, but okay to avoid duplication. Just never ever put such (non-inline) stuff in a .h 08.01.53 # amiconn: that was my feeling, including a .c when there's a reason is not really that awful. and i mentioned the remote LCD includes to kugel as well. :) 08.02.11 # Unhelpful: Btw, what happened to the long-call veneer stuff? 08.02.51 # i was never able to produce a decently concise source and linker script to trigger the offset problem :/ 08.03.39 # an .xpm is a c file, and it's designed to be included 08.03.43 # (just an example) 08.05.01 # amiconn: markun had said he thought he remembered you having concerns about unifying LCD code - i *assume* that would be one of the earlier FS#4817 patches. he couldn't remember *what* the problem had been, though, and it's surely possible that it wasn't even you :) 08.11.17 Join flydutch [0] (n=flydutch@host214-146-dynamic.15-87-r.retail.telecomitalia.it) 08.14.13 Quit krazykit (Remote closed the connection) 08.14.24 Join krazykit [0] (n=kkit@c-24-218-166-241.hsd1.ma.comcast.net) 08.14.38 # If current_vp needs to be non-static, you could use the very same mechanism as the combined main+remote lcd drivers (using LCDFN() to prepend either lcd_ or lcd_remote_). The include solution wouldn't need that, of course, as it can stay static 08.17.42 Join Rob2222 [0] (n=Miranda@p4FDCE1CE.dip.t-dialin.net) 08.18.38 # another reason that i favor the include way, but mostly i don't like the idea of this costing a binsize increase on some targets 08.18.38 # Regarding the concerns I'm not sure whether it was me. If it was, it was a long time ago. Need to dig in the logs 08.21.14 # i tried google, but only found people asking if the task was old and needed closing, and linusn suggesting at one point that it should wait until after VP merge... that's already getting a bit ancient-history ;) 08.21.31 Quit stoffel (Read error: 104 (Connection reset by peer)) 08.25.05 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.28.36 Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) 08.35.49 Quit Rob2223 (Read error: 110 (Connection timed out)) 08.38.05 Join petur [50] (n=petur@rockbox/developer/petur) 08.41.54 Quit Stephen__ ("Leaving") 08.59.25 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 09.04.51 Quit n1s (Remote closed the connection) 09.06.10 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 09.11.46 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 09.12.53 Quit TheSeven (Read error: 113 (No route to host)) 09.13.19 *** Saving seen data "./dancer.seen" 09.27.47 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 09.30.59 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 09.40.30 Quit DarkSpectrum (Read error: 104 (Connection reset by peer)) 09.40.49 Join mt [0] (n=MTee@41.206.137.118) 09.40.50 Quit shaggy-h () 09.41.03 Join DarkSpectrum [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 09.43.02 Join sbhsu_ [0] (n=a6530466@Zion.dorm.au.edu.tw) 09.43.53 Quit FlynDice (Remote closed the connection) 09.44.14 Join FlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 09.46.20 Quit Thundercloud (Remote closed the connection) 09.50.02 Join shaggy-h [0] (n=kiwi@87.74.127.193) 09.52.30 Join gammy [0] (n=gam@c83-251-133-108.bredband.comhem.se) 09.53.17 # I just blew something related to analogue audio out on my iRiver iHP-120. Does anyone have just the board (or a complete player) for sale? 09.58.32 Quit sbhsu (Read error: 110 (Connection timed out)) 10.01.18 Join LinusN [0] (n=linus@rockbox/developer/LinusN) 10.02.20 Join J-23 [0] (n=zelazko@unix.net.pl) 10.12.05 Quit kachna (Read error: 113 (No route to host)) 10.13.42 Quit BHSPitMonkey ("Ex-Chat") 10.16.46 Join efyx [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 10.21.15 Quit martian67 (simmons.freenode.net irc.freenode.net) 10.21.15 NSplit simmons.freenode.net irc.freenode.net 10.21.15 Quit bzed (simmons.freenode.net irc.freenode.net) 10.21.56 NHeal simmons.freenode.net irc.freenode.net 10.21.56 NJoin bzed [0] (n=bzed@devel.recluse.de) 10.21.56 NJoin martian67 [0] (n=martian6@about/linux/regular/martian67) 10.22.08 Quit mortti (Read error: 60 (Operation timed out)) 10.22.11 Join mortti [0] (i=mortti@beer.modeemi.cs.tut.fi) 10.22.44 Quit Zagor ("reboot time") 10.27.25 Join pamaury [0] (n=pamaury@sal63-1-82-243-96-220.fbx.proxad.net) 10.27.54 Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) 10.33.40 Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) 10.42.52 # hello, I tried to build a simulator version of rockbox following the wiki instructions and it fails at the "make fullinstall" step: "Installing a full setup in your '' dir" "ERROR: No PREFIX given" 10.43.02 # Can someone explain me why ? 10.52.14 # pamaury: Presumably because no [installation] prefix was given. Iknow nothing of this simulator business, but that's my assumption. Perhaps you could rectify this by specifying "--prefix=" during the configure. 10.53.34 # pamaury: you could also check the Makefile to see what PREFIX relates too. Perhaps you can set an environment variable for it, eg "mkdir dir; PREFIX=./dir/ make fullinstall" 10.53.42 # "relates _to_" even 10.54.12 # that's what I was trying to do but it doesn't work if I do only for make fullinstall so I'm trying it with configure. Wait and see :) 10.54.47 # It works ! 10.54.56 # Win. 11.03.55 Join mt_ [0] (n=MTee@41.206.136.134) 11.07.06 Quit martian67 (simmons.freenode.net irc.freenode.net) 11.07.06 NSplit simmons.freenode.net irc.freenode.net 11.07.06 Quit bzed (simmons.freenode.net irc.freenode.net) 11.08.01 NHeal simmons.freenode.net irc.freenode.net 11.08.01 NJoin bzed [0] (n=bzed@devel.recluse.de) 11.08.01 NJoin martian67 [0] (n=martian6@about/linux/regular/martian67) 11.13.24 *** Saving seen data "./dancer.seen" 11.13.33 Quit freqmod (Read error: 60 (Operation timed out)) 11.15.26 Join pyro_maniac [0] (i=foobar@p57BB94FD.dip0.t-ipconnect.de) 11.17.44 Quit martian67 (simmons.freenode.net irc.freenode.net) 11.17.44 Quit bzed (simmons.freenode.net irc.freenode.net) 11.18.43 NJoin bzed [0] (n=bzed@devel.recluse.de) 11.18.43 NJoin martian67 [0] (n=martian6@about/linux/regular/martian67) 11.21.20 Join n1s [0] (n=n1s@rockbox/developer/n1s) 11.25.23 Join raphi [0] (n=raphi@pub082136118205.dh-hfc.datazug.ch) 11.25.51 Quit mt (Read error: 110 (Connection timed out)) 11.26.17 Quit advcomp2019 (Read error: 54 (Connection reset by peer)) 11.26.40 Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) 11.26.51 Nick mt_ is now known as mt (n=MTee@41.206.136.134) 12.01.54 Quit linuxstb ("Leaving") 12.02.03 Quit DarkSpectrum (Read error: 104 (Connection reset by peer)) 12.02.10 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 12.02.22 Join freqmod [0] (i=quasselg@dhcp208-240.ed.ntnu.no) 12.02.25 Join DarkSpectrum [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 12.07.59 Join funman [0] (n=fun@rockbox/developer/funman) 12.11.52 # i got an answer from the marketing product manager at austriamicrosystems 12.11.57 # "I think the specification for our device (AS353x series) might not give you additional information about the chip you are searching for." 12.14.07 # what a totally useless answer.... 12.15.24 # perhaps he means the chip in sansa clipv2/fuzev2 is not an as353x? 12.17.30 # I have no idea. Well, it's nice at least to get an response at all. 12.19.48 # funman: I submit a patch on FS: the previous bugfix of logf contained a bug ! 12.21.46 # is there by the way anyone thinking / working on alternative filesystems that can be used in rockbox? like ext or others? 12.23.02 # a patent ridden ratsnest like fat would be nice to avoid completely 12.23.53 # hatseflats: rockbox isn't likely to be sued as it is nonprofit 12.24.15 # and the fat patent used against tomtom could be worked around in the linux kernel 12.24.18 # furthermore fat is really simple to implement and works flawlessly on windows and linux 12.24.49 # so, no there isn't anyone thinking on alternative filesystems, fat just is enough and other filesystems are not wanted 12.24.50 # which is not the case of ext2/ext3. Except if we have a working MTP implementation 12.25.54 # I have the austriamicrosystems guy's cellphone but international calls are expensive 12.25.55 # flawlessly would be such that I don't have to hack my kernel so I don't get the wrong device total after formatting 12.26.27 # hatseflats: if you see a bug in rockbox fat driver, you can send a patch/bug report 12.26.42 # is there a bug in the fat driver ? 12.26.45 # funman: sure, but I'm not quite decided on who's fault it is :) 12.28.14 # hatseflats: There's resistence amongst Rockbox devs to the idea of supporting alternative filesystems - it's even on the "no-do" list. But personally I would use ext2/3 if Rockbox supported it... It just needs to be implemented in a very clean way, so targets short on RAM can easily disable it, and so it also doesn't add unneeded complexity (read: increase in code size) to the existing FAT driver. 12.31.54 # one way would be to have probing code and then load the needed filesystem code 12.32.17 # oh .. you can't load code from the storage if you don't have a filesystem driver yet 12.32.51 # And what about the bootloader? 12.33.24 # But I think that's a problem we don't need to solve until someone actually implements a new filesystem. Which to be honest I doubt anyone ever will... 12.34.06 # maybe a flash file system ... 12.34.46 # that also means losing compatibility with the OF at some point 12.34.47 Join DarkSpectrum- [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 12.34.47 Join gtkspert_ [0] (n=gtkspert@124-169-230-52.dyn.iinet.net.au) 12.34.55 # bertrik: You mean instead of FAT32 on top of a FTL? 12.35.39 # funman: Yes, but anyone who wants to use an alternative FS would expect that. 12.35.47 # (unless we're talking HFS+ on ipods) 12.35.49 # yes, just dreaming for now though 12.36.43 # Won't that require support for the same filesystem on the user's PC? 12.38.45 # linuxstb: MTP would be a better bet there. 12.38.45 # either that, or have MTP support in rockbox 12.39.01 # It's all but impossible to do flash filesystems over USB 12.39.13 # they're incompatible with standard block devices, and thus also with MSC 12.39.46 # Torne, ah right, didn't think o fthat 12.39.47 # * linuxstb wonders if enough devs are interested in using ext2 (or at least, are not against an implementation) to propose it as a Google SoC project next year... 12.40.23 # bertrik: MTP would have to come first before a non-block-device FS :) 12.40.24 # That would seem a step backwards though - one of the main features of Rockbox has always been plain MSC access. 12.40.28 # I see no practical advantage in ext2 12.41.12 # MSC is shit, though :L) 12.41.29 # FAT as a transport protocol needs to be shuffled off this earth as soon as is possible :) 12.41.39 Quit mt (Read error: 104 (Connection reset by peer)) 12.41.47 # though there are alternatives other than MTP as a replacement, admittedly 12.41.58 # the object storage extensions to SCSI are quite delicious. :) 12.43.12 # plain MSC support is only an advantage because most of the alternatives are poorly supported or just plain awful at present 12.43.15 # this won't always be true 12.47.39 # bertrik: a flash optimized fs is generally a bad idea (tm) nowadays because of hardware wearlevelling, so if it was implemented, it should be covered in red tape and exclemation points 12.47.52 # so that people only use it if and when it's a good idea 12.48.16 # not all rockbox targets have hardware wearlevelling 12.48.23 # hatseflats: Presumably it would only be enabled on targets where there is no hardware wear-levelling. Lots of our newer flash-based targets are like that. 12.48.25 # not all, exactly. 12.48.53 # I expect more potential targets to use flash instead of sdcard or harddisk in the future 12.48.58 # sandisk use SD, probably because they don't have to pay royalties 12.49.23 # imo it should be up to the user to use a fs, and rockbox should silently take it like a sm slave, but I'm having ifs and doubts with software wearlevelling fs's 12.49.26 # o hwell 12.49.28 # * oh well 12.49.32 # hatseflats: er, why? 12.49.36 Quit gtkspert (Read error: 101 (Network is unreachable)) 12.49.41 # it's a non-problem IMO 12.49.44 # If you have bare NAND flash as many devices do then you have to do it in software 12.49.52 # aye 12.50.02 # and doing it in the FS is *better* 12.50.37 # at least in theory. you have more information. 12.50.44 # specific implementations may or may not be better 12.51.28 # If we would have a flash file system, we would not have to force it on non-flash block-based devices too 12.51.46 # Uhm, flash filesystems can't be used on block based devices 12.51.51 # without emulation layers in between 12.51.54 # the opposite of an FTL, almost :) 12.51.56 # We could just make it some kind of compile-time option, specific for each target 12.52.03 # they are completely independant concepts 12.52.40 # block device flash emulatoin is only used for stuff like testing flash filesystems on loopback devices :) 12.53.18 Quit DarkSpectrum (Read error: 110 (Connection timed out)) 12.54.50 # hatseflats: i think you are misunderstanding how flash FSes work, anyway. real flash FSes *cannot be used* on block devices unless you insert an emulation layer. Anything with hardware wear levelling has a block device interface. 12.55.21 # It's only possible to make such a mistake on an OS which has this kind of emulation support for testing, if you go and force the emulataion layer to get loaded and used (as people have been known to do with the mtdblock device in linux) 12.56.29 # Torne, file systems using simple block-devices have a very simple interface between them, essentially just read block X and write block X. Is there a similar interface between flash file systems and flash memories? 12.56.48 # Yes, but it's much less simple 12.57.08 # and it's not necessarily the same for all types of flash either 12.58.17 # http://www.linux-mtd.infradead.org/tech/mtdnand/index.html <- this is the standard linux mtd nand interface 12.58.29 # ah, directly speaking with the nand fs's 12.58.35 # you'll notice that api has dozens of functoins 12.58.35 # don't know them, you are right. 12.58.42 # rather than the handful that a block device has 12.59.26 # hatseflats: there's a difference between an FS that's aware it may be running on an SSD and knows how to tweak its access pattern/etc and maybe issue ATA TRIM and similar 12.59.44 # and an FS like UBIFS or JFFS which is constructed entirely around erase blocks and linear write block ordering and so on 13.02.19 # isn't there a standard ftl though? 13.02.27 # for these Samsung devices? 13.02.28 # tmzt: there are loads and loads of standard FTLs 13.02.36 # dozens, i would expect 13.02.45 # most of them only work on specific kinds of flash 13.03.15 # Samsung have several FTLs that they license for their flash parts 13.03.18 # okay, so those devices with that ftl support a block layer, but a raw mtd filesystem like ubifs or jffs or yaffs2 or (I think) logfs doesn't need the ftl 13.03.32 # tmzt: an mtd filesystem can't even *use* the ftl. 13.03.38 # it's not tha tit doens't need it, it literally can't work :) 13.03.39 # right 13.04.27 # ubifs is also a special case as ubifs uses a *different* interface, ubi, to talk to the flash, which is a higher level interface than mtd but still distinct from a block devie 13.04.52 # unstructured/unordered block interface? 13.05.06 # unordered, yes 13.05.33 # UBI does wear levelling and bad block replacement, presenting an interface which is a series of unordered logical erase blocks 13.05.38 # what is this about? is rockbox considering adopting one of those? 13.06.19 # or is this about refactoring the ata stuff, since it won't support flash that doesn't resembled a disk device 13.06.20 # people were suggesting that one day we could use a flash fs instead of implementing the OFW's FTL, perhaps. 13.06.38 # on devices whose storage is raw flash 13.06.51 # but it would have to be able to share space with OF, or is this removing OF entirely? 13.10.41 # That would be removing the OF entirely. 13.10.53 # FTLs generally don't support flash partitioning. 13.11.07 Quit funman ("free(random());") 13.13.25 *** Saving seen data "./dancer.seen" 13.14.56 Join ehntoo [0] (n=ehntoo@adsl-99-156-195-44.dsl.applwi.sbcglobal.net) 13.18.55 # it seems the Samsung FTL uses a NAND API with a few functions like init, probe, read, write, erase and sync 13.24.48 # I have a question about sprintf and friends: the current implementation relies on a more general function called "format" which is nice because its uses a function instead of a buffer to write. Wouldn't it make sense to make it available through a header rather than hiding it ? 13.28.19 # bertrik: that's not sufficient for all possible situations; e.g. when there is hardware to calculate and check ECCs. 13.28.48 # and it depends if you want to address the OOB data seperately or not, and so on 13.39.40 Quit gammy ("fuck it") 13.48.06 Join AndyI [0] (i=AndyI@212.14.205.32) 13.49.45 # Torne: do you what HAVE_REMOTE_LCD stands for ? In logf there is a strange displayremote which looks similar to logfdisp but called every time logf is called 13.49.59 # it means there is a remote with an LCD on it 13.50.07 # logf prints to this LCD if it exists. 13.50.27 # ok 13.58.54 Part pike 13.59.56 Quit AndyIL (Read error: 110 (Connection timed out)) 14.02.27 # linuxstb: what would be the practical benefit of ext2? 14.04.48 Quit ehntoo (Read error: 110 (Connection timed out)) 14.12.35 Part pyro_maniac ("Leaving.") 14.15.09 Join fml [0] (n=4fd3c9b1@gateway/web/cgi-irc/labb.contactor.se/x-86375ca78bb58c41) 14.15.50 Join funman [0] (n=fun@rockbox/developer/funman) 14.17.25 # Hello. I have a weird problem with the H120 simulator. After setting all settings to their default values, if I clear the backdrop image, the screen of the main unit is drawed black. Only the icons are visible. Does anybody see this too? 14.18.28 # The remote is drawed correctly. I use it to again go to the settings and reset them (so that the backdrop image is set again) -- that "repairs" the main screen. 14.22.07 Join kugel [0] (n=kugel@rockbox/developer/kugel) 14.22.55 # fml: http://www.rockbox.org/tracker/task/10505 14.23.29 Join DarkSpectrum [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 14.29.46 Quit linuxstb (Read error: 60 (Operation timed out)) 14.38.28 Join lasser [0] (n=chatzill@Wa4a8.w.pppool.de) 14.39.45 Join LambdaCalculus37 [0] (i=44a0430d@rockbox/staff/LambdaCalculus37) 14.40.12 Quit lasser (Client Quit) 14.42.17 Quit DarkSpectrum- (Read error: 110 (Connection timed out)) 14.50.07 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 14.51.02 Quit n1s ("Lmnar") 15.02.18 # kugel: Ok, I commented in that task. 15.04.17 # New commit by 03kugel (r22264): Fix FS#10505 - "Background changes to inverted when cleared" as well as a problem that lets the viewport parser reject correct WPSes, both introduced ... 15.06.05 Join stoffel [0] (n=quassel@p57B4CC48.dip.t-dialin.net) 15.08.42 Quit antil33t (Read error: 104 (Connection reset by peer)) 15.08.56 Join antil33t [0] (n=Mudkips@119.224.12.185) 15.10.05 # New commit by 03gevaerts (r22265): blacklist jdgordon-qnap. It misses "nice" 15.13.29 *** Saving seen data "./dancer.seen" 15.14.52 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 15.14.53 # fml: the viewport_load_config is probably a left over from before the viewport'ified lists were committed (the patch contained costumizability) 15.15.23 # NULL instead of VP_ERROR would work too 15.15.28 # kugel: I wonder why we don't get compiler warnings on this 15.15.48 # it's just a declaration, that never throws warnings 15.16.18 # kugel: I'd say it the other way around: VP_ERROR works too (by a pure chance) 15.16.47 # feel free to change it 15.17.20 # my customlist patch uses VP_ERROR for other functions too, that's why it's there. 15.17.35 # but I don't really care, NULL is technically more correct in this case 15.18.10 Join evilnick [0] (i=0c140464@gateway/web/freenode/x-27321350bd977513) 15.19.05 # kugel: as of now, I'd say it's absolutely the same _technically_. But not semantically :-) Try to change the value of VP_ERROR and you'll see :-) I'll change soon. 15.20.15 # fml: try to change NULL and you'll get the same :) 15.32.18 Quit AB3JU (simmons.freenode.net irc.freenode.net) 15.32.18 NSplit simmons.freenode.net irc.freenode.net 15.32.56 NHeal simmons.freenode.net irc.freenode.net 15.32.56 NJoin AB3JU [0] (n=dz@alt.dissonance.nl) 15.37.11 # New commit by 03alle (r22266): Remove unneeded symbols and improve the comment to the VP parsing function 15.44.54 # New commit by 03alle (r22267): Change the function name in strnatsort so that the code doesn't contradict itself 15.49.32 # New commit by 03alle (r22268): Remove dead code 15.51.03 # maybe I shouldn't have used #if 0, but #ifndef ROCKBOX ... 15.54.51 Quit funman ("free(random());") 15.58.01 # kugel: I thought about defining or not defining IGNORE_LEADING_SPACES but then decided against it. 16.00.15 Part LinusN 16.19.14 Quit linuxstb (Read error: 110 (Connection timed out)) 16.31.11 Quit DarkSpectrum (Read error: 54 (Connection reset by peer)) 16.31.33 Join DarkSpectrum [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 16.32.24 Quit evilnick ("Page closed") 16.38.29 # New commit by 03kugel (r22269): Make kbd_input() show a cancel splash to indicate user abort better and for better consistency all over the place. Change checking for its return ... 16.47.16 Join gtkspert [0] (n=gtkspert@124-169-242-228.dyn.iinet.net.au) 16.50.34 # Why doesn't the "may be used initialized" warning come up in the sims? 16.50.46 # * fml spots a typo in rockboymenu.c (wrong result checking) 16.51.01 # rockboy/menu.c ^^ 16.51.15 # New commit by 03kugel (r22270): Both of this isn't needed anymore as it's done at the end of the function. 16.51.19 # New commit by 03kugel (r22271): Fix yellows. 16.53.34 # New commit by 03zagor (r22272): Jdgordon got nice 16.53.50 Join toffe82 [0] (n=chatzill@74.0.180.178) 16.53.51 # hehe 16.54.46 # fml: indeed 16.55.12 # Zagor: I wont be reneabled untill the next commit? 16.55.35 # oh, its in the middle of a round 16.55.44 # yup 16.55.59 # you should be now, there's another round :) 16.56.34 # the block file is only loaded every 10 minutes 16.57.16 Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) 17.00.19 # New commit by 03kugel (r22273): Fix mistake at checking the return in rockboy. Thanks Al Le for spotting. 17.01.33 # I guess I was too early then 17.01.48 Quit gtkspert_ (Read error: 101 (Network is unreachable)) 17.03.50 Quit TruthTaco (Read error: 60 (Operation timed out)) 17.10.28 Join TruthTaco [0] (n=truthtac@adsl-74-11-71.aby.bellsouth.net) 17.12.36 Quit Zagor ("Don't panic") 17.13.33 *** Saving seen data "./dancer.seen" 17.20.46 Quit bmbl ("Bye!") 17.21.12 # Zagor: (logs) http://pastie.org/581409 17.21.45 # and http://pastie.org/581410 17.22.05 Join Blue_Dude [0] (n=chatzill@adsl-235-222-153.mco.bellsouth.net) 17.25.47 Quit fml ("CGI:IRC (EOF)") 17.26.06 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 17.34.45 # New commit by 03kugel (r22274): Protect viewport.h against multiple inclusion. 17.39.06 Join Strife89 [0] (n=michael@adsl-154-13-156.mcn.bellsouth.net) 17.41.29 Join evilnick [0] (i=0c140464@gateway/web/freenode/x-6dda82f8cf9334a2) 17.41.56 Join funman [0] (n=fun@rockbox/developer/funman) 17.46.19 # FlynDice: i'll check if AMS OF uses widebus mode for SD cards 17.47.01 # obo: how's going view's work? 17.50.15 # funman: I can get widebus to work for browsing files and loading album art but playback will not work for more than 3-4 secs, eerily similar to the spot we were in with the mmu before you found the CCU setting... 17.50.43 # what happens after those 3-4 seconds? 17.51.12 # player is functional besides playback it seems 17.51.58 # anything useful in buffering thread debug menu perhaps? 17.51.59 # the cpu frq is locked at 248 and the lcd disk light is on steady 17.52.50 # i don't see where i could have left a deadlock which wouldn't trigger a panic 17.53.04 # yes cpu is steady boosted and I2SO is off 17.53.08 # i need to look at that file carefully again : i want to add retry on send_cmd errors 17.53.28 # what's the state of bufferign thread? empty? 17.53.56 # we seem to get an ok transfer speed without widebus though 17.54.34 # we hadn't set up the controller for wide bus so that looks normal 17.54.53 # i mean, i can understand we see the same performance, not explain it :) 17.54.55 # funman: does FlynDice fix your non-working uSD? 17.55.26 # kugel: no, as written in the flyspray entry 17.55.56 # i listened to music stored on this µSD this afternoon while skating without any crashes though 17.56.14 # funman: yea, but your first comment was "Thanks for the patch, it works fine with my 2 µSD cards", hence I was confused 17.56.38 # the 2nd comment starts with "correction" 17.57.19 # i have no way to reproduce an error in data transfer from/to this card 17.57.44 # i formatted it since, i'll try again test_disk on it in the future 18.04.52 # New commit by 03blue_dude (r22275): New committer! 18.05.12 # Blue_Dude: Welcome! \o/ 18.05.20 # FlynDice: did you try test disk? 18.05.22 # Thanks! 18.06.09 # kugel: not yet I've been trying to get widebus working 18.07.35 # funman: did you look at the logf fix I posted on FS recently (FS#10515) ? 18.09.12 Quit petur ("work->home") 18.10.09 # New commit by 03funman (r22276): Fix a wrong memcpy in logf() introduced in r22253 ... 18.10.23 # * LambdaCalculus37 sees a new committer :) 18.10.36 # pamaury: no i hadn't looked at it :) 18.10.44 # thanks :) 18.12.01 # I have a question about usb_drv_* things ? Is there any usb expert here ? 18.12.04 # kugel: One other thought I had re widebus. Do you think the GPIOD being dual use with MMC/SD could be an issue? I'm not all that familiar and you worked with that for the buttonlight on disk access issue 18.12.41 # could be, build without HAVE_BUTTON_LIGHT to be sure 18.14.23 # funman: you could probably deactivate it also when messing with the problematic microsd, I don't really knno how this buttonlight business affects our driver 18.15.08 # kugel: did you see how the OF deactivate button light while SD transfers? 18.15.25 # no 18.15.45 # I haven't really looked at the of, except for the SD_MCI_POWER thing 18.15.51 # Blue_Dude: congratulations! 18.16.08 # * gevaerts sees pamaury's question and tries to hide 18.16.16 # ty! 18.17.04 # gevaerts: ah I though you weren't there :) 18.17.05 # pamaury: gevaerts! gevaerts! gevaerts! 18.17.25 # I'm not! I don't exist! 18.17.49 # New commit by 03gevaerts (r22277): block qnap-jdgordon again: it doesn't have perl in the expected place 18.18.03 # I was wondering: what happen if someone call usb_drv_send_nonblocking while another call has been issued and the transaction is not finished 18.18.18 # on the same endpoint? Don't do that 18.18.28 # gevaerts: what about a simple script which checks basic requirements? nice, perl in some place, etc? 18.18.39 # did JdGordon actually any successful build before attaching as client? 18.18.39 # yes on the same endpoint 18.19.09 # well I was sure I would get that answer... That's related to the usbserial driver in fact 18.19.17 # pamaury: I don't think any of the drivers will handle that properly. ARC certainly doesn't. 18.19.53 # gevaerts: so weird things could arise if someone calls usbserial_send two times on a row 18.19.56 # ? 18.19.58 # they aren't thread safe? 18.20.07 # kugel: nothing to do with threads 18.20.14 # the same thread 18.20.45 # example: usbserial_send('a',1);usbserial_send('b',1); The first transaction won't be finished when the second will happened 18.20.58 # * kugel read "usb_drv_send_nonblocking while another call has been issued and the transaction is not finished" as "call it, while a previous call didn't return" 18.21.19 # pamaury: usb_serial_send() just puts things in a ringbuffer 18.21.23 # kugel: *nonblocking 18.22.28 # hum, so there shouldn't be any problem calling it lots of time on a row ? 18.23.18 # pamaury: there shouldn't be, no. You can overflow the ringbuffer of course, but that should only eat data, not crash. That doesn't mean it's guaranteed bug-free of course 18.23.26 Quit jordan`` (Read error: 110 (Connection timed out)) 18.24.22 # ok I will test more, because I'm working on a new implementation of logf and for practical reasons it's simpler to call usbserial_send for each character rather than one or two times at the end 18.24.33 # And I get really weird results with that 18.24.45 Join JdGordon| [0] (n=Miranda@nat/microsoft/x-e6e62c1c0350c22e) 18.25.25 # pamaury: please try to avoid that. It should work well, but I don't really like the idea 18.25.35 # why ? 18.25.47 # because it's subsubsubsuboptimal ? 18.25.55 # it could be I think, yes 18.26.53 # ok,I will avoid that but still I'm wondering why I get different results 18.26.53 # although that will depend on the case. If you log a line every now and then, I expect two transactions instead of one. If you log lots in a row, it won't be too bad, but you'll overflow the ringbuffer anyway 18.27.22 # what's the size of the ringbuffer ? 18.27.40 # default 512 bytes 18.27.49 # you can change the define though 18.28.05 # should be large enough normally 18.28.23 # I expect so, yes 18.29.34 # if we want to use it for other things than logging (ppp?), I guess just usb_serial_send() isn't a good API. I'm not sure how likely that is to happen 18.31.11 # that's for logging 18.31.14 # (here) 18.32.39 # I know. I can just imagine some usecases actually wanting to know when their actual bytes go out 18.35.14 Join _Shaid [0] (i=adam@lurking.shaid.net) 18.36.01 # yes that's true 18.36.58 # Also, is the usbserial implementation really working ? I have lots of problem with my sansa (or perhaps my logf is buggy related to usbserial) 18.37.22 # it's not always very reliable. I haven't used it recently 18.38.07 # why ? I is a usb problem or really the usbserial ? 18.38.28 # not sure 18.38.53 # last time I looked at usbserial for another project (this is a few years ago), there were also some peculiarities in the windows xp drivers 18.38.57 Quit Shaid (Read error: 104 (Connection reset by peer)) 18.38.57 Nick _Shaid is now known as Shaid (i=adam@lurking.shaid.net) 18.39.07 # New commit by 03gevaerts (r22278): JdGordon promises that qnap-jdgordon now works fine 18.39.33 # * JdGordon| promises nothing 18.39.43 # I guess for Windows, a simple interface like this won't suffice, it problem requires the whole CDC-ACM things 18.39.44 # yes, our current implementation does not work with xp, due to it being pretty incomplete 18.39.54 # JdGordon| doesn't, but JdGordon does! 18.40.15 # * JdGordon| wouldnt trust that guy.... 18.41.02 # gevaerts, what is missing then? 18.41.49 # IIRC, windows just sends some of those line control commands (DTR) when opening a USB serial port and not much more 18.41.49 # bertrik: I'm not exactly sure, but IIRC there needs to be an interrupt endpoint that does some things, and some control things 18.42.16 # it may not use the other things, but it could very well check if the endpoint is there 18.42.27 # scorche: all our flights suck... assuming the 3 of us goto the airport together you will be stuffing around for 2 hours and me 1... +any extra time for gev to make his flight 18.42.41 # WTF? gev in that sentance chanegd it to 24/7! 18.42.53 # * gevaerts denies being 24/7 18.43.00 # sorry, wrong window 18.49.57 Join mt [0] (n=MTee@rockbox/developer/mt) 18.49.58 Quit funman ("Lost terminal") 18.50.25 Join funman [0] (n=fun@rockbox/developer/funman) 18.54.41 # wtf 18.54.55 # where is gui_statusbar_set_screen() defined? it's called but I can't find it 18.55.16 # I have a feeling thats #defined in screen_access.h 18.55.30 # or used to be 18.56.07 # ah got it 18.57.09 # * kugel wonders whether "/* Must be done before any code uses the multi-screen APi */" before gui_syncstatusbar_init() is still valid 18.57.30 # probbaly not 18.59.26 # * kugel tries 18.59.30 # gevaerts: there is a really strange thing with usbserial: if send a burst of usbserial_send (each of size >= 16 in this case) then only the first seems to be catched by usbserial on linux and in fact on the first seems to be actually sent. 18.59.53 # But if I introduce a sleep(HZ/10) between each call, then everything works ! 19.00.24 # pamaury: that seems to point to the ringbuffer not working properly 19.00.53 # ok, I'll investigate that 19.03.57 # gevaerts: I also have a question about usbserial: what does this line of code means (in subserial_init_connection) ? 19.04.02 # usb_drv_recv(ep_out, receive_buffer, sizeof receive_buffer); 19.04.38 # there also is a comment: 19.04.42 # pamaury: tell the driver to receive some data 19.04.50 # prime rx endpoint 19.04.55 # what does that mean ? 19.05.32 # stupid setttings_apply() at boot 19.05.34 # hm, that comment should probably be changed. That's a bit specific to the ARC driver. "priming an endpoint" means telling the hardware to expect data 19.06.32 # Without this it would accept data from the host ? 19.06.37 # *wouldn't 19.07.06 # exactly 19.07.28 # But the drivers shouldn't be aware of that no ? 19.07.56 # why not? The driver decides where to put the data... 19.08.10 # well, that's true :) 19.09.02 Join captainkwel [0] (i=2669ecc2@gateway/web/freenode/x-aceee27dadef84bc) 19.11.14 Join sajes [0] (n=sajes@67.143.34.85) 19.11.40 # Oi. Just rockboxed my samsa. :D. 19.13.37 *** Saving seen data "./dancer.seen" 19.17.07 Join AsaelReiter [0] (n=d44c6c11@gateway/web/cgi-irc/labb.contactor.se/x-0fe50a30dc382d4c) 19.20.28 # funman: re: [08:46] FlynDice: i'll check if AMS OF uses widebus mode for SD cards, I would be interested if you find a SET_CLR_CARD_DETECT(ACMD42) associated with this also. It controls a pull-up resistor on DAT3. 19.21.41 # FlynDice: i have some troubles to start disassembling (can't find a correct blue color for my terminal) 19.22.22 Join merbanan [0] (n=banan@c-83-233-172-245.cust.bredband2.com) 19.22.37 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 19.25.52 # gevaerts: is there any way to sniff the usb packets on linux ? 19.30.00 # there's wireshark+usbmon these days 19.31.19 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 19.32.25 Join n1s [0] (n=n1s@rockbox/developer/n1s) 19.40.09 Quit kugel (Read error: 110 (Connection timed out)) 19.40.33 Join kugel [0] (n=kugel@rockbox/developer/kugel) 19.42.08 Join StealthyXIIGer [0] (n=stealthy@ppp-69-216-120-135.dsl.sfldmi.ameritech.net) 19.48.54 # I'm going to commit a couple of plugin changes: FS#10502 and FS#10504. I won't be able to close the FS items yet though. 19.49.08 # Blue_Dude: What are those plugin changes, exactly? 19.49.58 # 10502 adds DSP benchmarking to test_codec. 10504 makes use of dsp_output_count and dsp_input_count in the mpegplayer audio thread. 19.50.35 # FS#10502 could probably be closed 19.51.33 # Yeah. I'd like to commit the change first though. 20.00.11 Join Strife1989 [0] (n=michael@adsl-154-13-156.mcn.bellsouth.net) 20.00.17 Quit Strife89 (Nick collision from services.) 20.00.31 Nick Strife1989 is now known as Strife89 (n=michael@adsl-154-13-156.mcn.bellsouth.net) 20.01.46 Quit pamaury ("Quitte") 20.01.59 Join pamaury [0] (n=pamaury@sal63-1-82-243-96-220.fbx.proxad.net) 20.05.29 # Hm. Having trouble using patch at the command line. Says can't find files and suggests using --strip. 20.06.02 # use -p0 or maybe higher int 20.06.05 # Blue_Dude: perhaps you need to tweak -p level 20.06.07 # if it was made with git 20.06.21 # -pN will strip the N first leading directories from the patch 20.06.56 # I used svn diff to generate the patch. Now I need to apply it to another branch. 20.07.33 # you would use patch -p0, provided you are in the root of rockbox checkout and generated the diff from the root of a rockbox checkout 20.07.39 # try incrementing the p level until it takes 20.07.48 Quit alexbobp (Connection timed out) 20.07.56 # gevaerts: does it require a custom kernel build or any kernel will do ? 20.08.17 # ok, it liked -p0 20.08.33 # most SVN diffs will need p0 20.08.38 # pamaury: depends. Some distributions have usbmon by default, but presumably some don't 20.08.41 Join jordan` [0] (i=gromit@78.235.252.137) 20.08.47 # Blue_Dude: when looking at the patch, pay attention to the line "diff --git a/firmware/logf.c b/firmware/logf.c 20.08.59 # * pamaury believes ubuntu don't :( 20.09.06 # in short, use -p1 for patches made by funman :) 20.09.10 # "patch" will attempt to patch "b/firmware/logf.c" and "patch -p1" will patch firmware/logf.c 20.09.29 # the patchlevel could be different if you ran svn diff while working inside firmware/ directory 20.09.41 # well, you'd have to cd firmware/ first . 20.09.48 # pamaury: "grep USB_MON /boot/config-*" will tell you 20.09.52 # The weird thing is that I ran the patch from the root and tried to apply it at the root. 20.10.05 # --ran the diff -- 20.10.26 # gevarts: seems to support it: CONFIG_USB_MON=y 20.10.45 # gevaerts: but I can't modprobe usbmon 20.11.04 # pamaury: "y" means it's built-in, no modprobe needed 20.11.07 Join stephen__ [0] (n=stephen@86-45-95-206-dynamic.b-ras2.srl.dublin.eircom.net) 20.11.14 Quit AsaelReiter ("CGI:IRC (EOF)") 20.11.21 # gevaerts: ah :) 20.11.53 # but when I run wireshark it doesn't show any usb interface 20.11.55 # Blue_Dude: patch manpage says if you don't specify -p it will strip ALL leading directories 20.12.13 # Aha. 20.12.28 # New commit by 03blue_dude (r22279): Adds DSP testing and WAV writing to test_codec 20.12.34 # pamaury: as root? 20.12.52 # gevaerts: ah that could explain the thing 20.13.22 # Blue_Dude: please try to reference to a FS# if there's any related one 20.13.39 Quit StealthyXIIGer (Connection timed out) 20.13.51 # kugel: Yeah you're right. Forgot. That was FS#10502. 20.13.53 # gevaerts: I don't have any usb interface, I have ethernet interfaces only 20.14.07 # Blue_Dude: an advantage of doing that, is that direct links to the FS are generated in the irclogs 20.14.53 # pamaury: maybe you need to mount the debugs thing? I don't know... 20.15.08 # * gevaerts hasn't used wireshark for usb in a very long time 20.15.13 # funman: and on the front page :) 20.16.03 # gevaerts: I have found out, it requires another obscure mount command line with usbfs 20.17.19 # funman: Happily climbing the learning curve... 20.17.42 # FS# 10502 is OK to close now, too. 20.18.57 Join alexbobp [0] (n=alex@adsl-75-42-225-23.dsl.austtx.sbcglobal.net) 20.19.46 # Blue_Dude: your wish is my command :> 20.19.58 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 20.21.23 # Blue_Dude: A bit late, but congratulations ! :) 20.21.42 # ty! 20.22.58 Quit saratoga ("Page closed") 20.23.59 Quit funman ("free(random());") 20.25.29 Quit Strife89 ("Bad weather, better unplug stuff.") 20.28.34 # New commit by 03blue_dude (r22280): FS#10504: Make mpegplayer audio thread use correct sample count 20.29.22 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 20.29.54 # gevaerts: is there a way to workaround the capture size which is quite limited... ? 20.30.12 # I don't know. I haven't ever used it for real 20.30.30 # I've just played around with it a bit 20.36.30 Quit timc (Remote closed the connection) 20.38.42 # Blue_Dude: congratz. and ask Zagor for dev access on FS 20.39.14 # nls: thanks. I'm keeping an eye out for him. Will probably just shoot him an email. 20.42.17 # New commit by 03blue_dude (r22281): FS#10512: Bookmarking does not behave correctly (fixes r22192) 20.45.23 # * moos joins the congratulations and add bravo for the green ;) 20.45.40 Quit n1s ("Lmnar") 20.46.40 # I have a question about list.c 20.47.01 # We have three of those, a common list.c, a list.c for charcell and a list.c for bitmap targets, right? 20.47.53 # the common list.c now seems to contain some list functions that are completely enclosed in #ifdef HAVE_LCD_BITMAP, can't we move those to the list.c for bitmap targets? 20.50.24 # for example function gui_list_get_item_offset is implemented in the common list.c but is never used there, it's only used in bitmap/list.c 20.51.17 # sounds like a clear thing to move 20.52.42 # ok, I'll carefully go ahead with that 20.53.16 Quit flydutch ("/* empty */") 20.55.23 # oh, that would be too easy of course, it refers to some local variables 20.55.45 # of course :) 20.57.17 # aaa 20.57.21 # oops sorry 21.00.00 # bertrik: the other bitmap is only for drawing actually 21.00.22 # the other list.c* 21.00.34 # New commit by 03blue_dude (r22282): FS#10446: Bug defense in dsp.c, minor tweaks and comments 21.01.39 # And that clears my backlog... Whew. 21.02.31 # bertrik: I'd rather rename instead of breaking this separation 21.02.47 # I don't get it 21.03.09 # the list.c in the subfolders do the drawing, the normal list.c is the logic code 21.03.14 # I'd just like to move some of the bitmap specific code from apps/gui/list.c to apps/gui/bitmap/list.c 21.04.00 # the charcell/list.c only does list_draw indeed 21.04.09 # yes, but that would mix logic and drawing code, I wouldn't want that, hence renaming the list.c's in the subfolders 21.04.14 # but the bitmap/list.c does a lot more 21.04.19 # no 21.05.43 Quit fdinel (Read error: 104 (Connection reset by peer)) 21.06.09 # well, the touchscreen stuff is a bit more it seems 21.07.29 # when something is only used by the list_draw function from apps/gui/bitmap/list.c, wouldn't it make sense to actually move it to apps/gui/bitmap/list.c ? 21.07.50 # how about I make a patch so you can have a look at it? 21.08.32 # what is only used by list_draw? 21.10.33 # Function gui_list_get_item_offset. Functions gui_synclist_scroll_right/left are referred from apps/gui/list.c but only #ifdef HAVE_LCD_BITMAP 21.12.43 # the former seems fine to move, the other two not really 21.12.54 Join n1s [0] (n=n1s@rockbox/developer/n1s) 21.13.38 *** Saving seen data "./dancer.seen" 21.14.10 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 21.14.49 # New commit by 03rob (r22283): D2: Re-enable SD(HC) driver as there have been no further reports of damaged cards. 21.15.34 # maybe a subfolder list/ with list-engine.c, list-draw-[bitmap|charcell].c, simplelist.c would be a good idea 21.17.55 # heh, it started as a simple fix (just remove some extern declarations from a C file) and before you know I'm creating entire new source files ... :P 21.21.47 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 21.26.08 # New commit by 03rob (r22284): TCC: Implement ECC error correction for sectors read from NAND. Tested on D2 (78x, MLC) and M200 (77x, SLC). 21.33.04 Quit efyx (Remote closed the connection) 21.34.54 # gevaerts: I have some new info about the usbserial problem 21.34.56 # kugel: FOLDERS FOR EVERYONE.... ahahhehhehehee 21.35.00 Quit amiconn (Nick collision from services.) 21.35.02 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 21.35.13 Quit pixelma (Nick collision from services.) 21.35.14 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 21.35.22 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 21.35.31 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 21.35.32 # a folder for three separate files? Sounds like overkill to me 21.36.00 # overkill? does a folder cost anything? 4 files, btw 21.36.23 # it doesn't cost anything, but it does cost time to navigate. 21.36.35 # so yes, it does cost something. 21.36.49 # also, right now in apps/gui/ there are 2 folders with 1 file each 21.37.16 # bluebrother: sorry, that sounds absurt to me 21.37.23 # absurd* 21.38.00 # doesn't sound like a good thing to me either. Either other files in those folders have been deleted, or files that are planned to be put there haven't been put there yet. Or someone thinking that a deep deep folder structure makes it easier to find things 21.38.13 # pamaury: what sort of info? 21.38.41 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 21.38.48 # bluebrother: no, the guy who just cried "FOLDERS FOR EVERYONE" added those :) 21.38.54 # kugel: feel free to disagree with me, but splitting things up too much can be a slowdown as much as not splitting things up when necessary. 21.38.54 Join Strife89 [0] (n=michael@adsl-154-13-156.mcn.bellsouth.net) 21.39.02 # then blame that guy :) 21.39.38 # I disagree in this case at least 21.39.42 # gevaerts: On my computer with my target, with my program to read usbserial packets, then usbserial seems not to send any usb packet when the size becomes too importants (in my exemple 142 characters) 21.40.08 # thing is, the question of splitting things in a folder or not is a tightrope walk. One needs to consider carefully if the added folder is a benefit or does make things more dungeon-like. 21.40.42 # I think there are things you need to consider more carefully 21.40.59 # gevearts: I've tried lots of combinaisons and reached the conclusion that its fails only when the size left to transfer in the ringbuffer is too big (but lower than the ringbuffer size still) 21.41.14 # well structured code is important imo, even if it means to browser 1 additional subfolder at times 21.41.18 # pamaury: any clue whether it's usb_serial.c or the driver? 21.41.18 # I will try to determine the exact value 21.41.55 # gevearts: to me, it's the driver because I've put logf things everywhere and usbserial forwards directly the request and the buffer to the driver 21.41.56 # kugel: did I say *anything* about the importance of other things? 21.42.11 # or the relation to the importance of other decisions? 21.42.19 # * bluebrother shakes head 21.42.21 # No you didn't 21.42.34 # so what's the point in that? 21.42.40 # but I don't understand why it would fail with usbserial whereas mass-storage works and involves transfers greater than that I beleive 21.42.57 # bluebrother: you're leaving the topic 21.43.28 # pamaury: one special thing about storage is that it only sends either small packets (commands), or full 512-byte packets. Never anything in between 21.43.33 # you consider other things more important? Fine, but the decision under discussion is still a tightrope walk. Doesn't change simply because you consider other things more important. 21.43.40 # kugel: no I don't. 21.44.59 # gevearts: that's strange then. I've though about a weird bug being a combinaison of rockbox+kernel+libusb but it also fails with linux usbserial module iirc 21.45.06 # tightrope walk is excessivly exaggerated 21.45.25 # gevearts: the strangest thing is that *it doesn't send any packet* 21.46.52 # pamaury: did you verify that it properly gets to sendout()? 21.47.02 # well, then consider it exaggerated. Still it's a decision that isn't easy in quite some cases. So why not call it tightrope walk? 21.47.17 # yes: it sendout the same buffer and buffer size. I will investigate more about this issue 21.47.44 # oh dear... 21.48.04 Join Strangelove [0] (n=4fb52117@gateway/web/cgi-irc/labb.contactor.se/x-e549481a3eeef8f7) 21.48.12 # I've seen enough cases where deep folder structures holding only a little amount of files got confusing, even to the people who created it. So at least *I* consider it an important question. If you don't, fine. 21.48.20 # hello 21.48.52 # 3 isn't deep, and not even deeper as right now 21.49.44 # i have a question.. how do u sync files into the iPod when using Rockbox? i've went through the FAQ and 21.49.57 # manual and didn't see anything regarding that... 21.50.00 # kugel: this doesn't change my opinion that folder structure decisions aren't easy. It might be unproblematic in this case, but I wasn't referring to this case anymore. What on earth is the point? 21.50.07 # Strangelove: any way you like. 21.50.23 # ? 21.50.31 # you can use Windows Explorer (in case you're using Windows), iTunes, or any other software that syncs to a player. 21.50.34 # Strangelove: you can drag&drop or use any syncing tool (in disk mode I think) 21.50.38 # nice.. 21.50.48 # i HATE itunes.. 21.50.48 # Rockbox does not need any special folder structure or database file so it's completely up to you. 21.50.49 # or rockbox usb that is 21.51.13 # i had a Zen vision:M that worked great and was soooo easy to organize 21.51.35 # and now i got an iPod Classic 120gb and it only uses that horrible itunes software.. 21.53.11 # that leads to just one more question.. i didn't understand with all the generations talks, whetever Rockbox supports the new iPod Classic 120gb? 21.54.08 # no it doesn't support the classic yet 21.54.32 # gevearts: seems to fail when size>=97 21.54.57 # :-( well i have patience, i'll wait for it, it looks like it's worth the wait.. 21.55.08 Join aaron424 [0] (n=chatzill@adsl-065-013-002-216.sip.asm.bellsouth.net) 21.55.11 # thanks allot guys 21.55.59 # ta ta 21.56.01 Quit Strangelove ("CGI:IRC") 21.56.02 # gevearts: here is what wireshark say: at size=96 works like a charm but at size=97: cannot send after transport endpoint shutdown 21.56.59 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 21.57.20 Quit robin0800 (Remote closed the connection) 21.58.27 Quit LambdaCalculus37 () 21.58.48 # pamaury: weird... Anyway, that should mean that if sendout() adds "buffer_transitlength = MIN(buffer_transitlength,96); 21.59.04 Join heavysidecar [0] (n=heavysid@82.36.170.20) 21.59.07 # " it should work. Maybe that's worth a try? 21.59.39 # It's not a real solution of course, but it's certainly a useful indication 22.01.35 # I'll do just one more test to be sure it's 96 22.03.23 # bluebrother, the intention of the list subdirectory was to make file naming easier and less confusing 22.03.53 # currently we have already have two subdirs containing only one list.c file each 22.05.09 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 22.06.45 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 22.06.45 # gevearts: here's my logf: http://pastie.org/581798 22.07.05 # gevearts: variables refers to the ones in usbserial 22.07.16 # JdGordon|: customlist looks good imo 22.08.21 Join kachna [0] (n=kachna@r4ax178.net.upc.cz) 22.08.25 # good... how? 22.08.59 # committable very soon 22.10.53 # pamaury: ok, so it's definitely not related to ringbuffer wraparound or anything like that. Could you try something like http://pastie.org/581804? 22.12.15 # bertrik: it might make sense in this case, especially if it consolidates folders. I still stand by my opinion that creating a good folder structure is non-trivial ;-) 22.13.51 Quit stephen__ ("Leaving") 22.13.51 # kugel: whats missing? 22.14.06 # gevearts: you trick works which is not very surprising 22.14.14 # JdGordon|: no idea 22.14.36 # geveaerts: I have also tried to do a usb_serial_send(buffer,512); but it doesn't seem to work (will confirm in a minute) 22.14.53 Quit merbanan (Remote closed the connection) 22.15.02 Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) 22.15.23 # there isn't missing much since a long time, I just kept being undecided on the api and stuff 22.15.34 # which api? 22.15.38 # pamaury: not surprising indeed, but still good to know 22.16.01 Join fg56lx [0] (n=quassel@163.106.40.24.aeneasdsl.com) 22.16.14 # gevearts: the usb_serial_send with 512 chars also fails, that's really strange. I will check with ubserial module 22.16.24 # JdGordon|: activating/deactiving for example, or overridding the ui viewport 22.16.34 # Got to go, but I just posted an optimized and speeded up version of the limiter DSP process I've been tinkering with at FS#10199. It is as fast as I can make it, and it doesn't take a hit on system performance when it isn't active. I've been running it on target for a few weeks and it *does* work. 22.17.12 # kugel: we were going to work on that post commit though wernt we? 22.17.29 # this is the viewport.c mess? 22.17.34 # yea 22.17.40 # but it's good now I think 22.17.47 # gevearts: no it doesn't work. Will would it fail with usbserial and not with mass storage ? 22.17.54 # or rather, acceptable :> 22.18.07 Quit evilnick ("Page closed") 22.18.19 # do you wanna put some test builds in the forums? 22.18.45 # do you think it's needed? 22.18.47 # * JdGordon| tries to put some time aside tonight to give the patch a good looking over 22.18.52 # pamaury: maybe related to alignment? What happens if you change the aligned(32) to aligned(512) for send_buffer? 22.19.03 # kugel: no, not really... others might disagree thoguh... 22.19.10 # bbs 22.20.08 # Zagor: There is a gap which can't be seen in the SVN backlogs on the website 22.20.32 Join Llorean [0] (n=DarkkOne@adsl-99-182-52-92.dsl.hstntx.sbcglobal.net) 22.21.06 # amiconn: 22264-22266? 22.21.19 Join efyx [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 22.21.26 # Today's log (already the extended one on recent.shtml goes back to r22267, and the next older one ("last 4 week") only goes up to r22263 22.22.13 Quit raphi ("leaving...") 22.22.30 Join aaron424_ [0] (n=chatzill@adsl-065-013-002-216.sip.asm.bellsouth.net) 22.23.18 Part Blue_Dude 22.23.57 # gevearts: no it doesn't seem to work 22.24.17 # gevearts: is the usb storage buffer 512 bytes aligned ? 22.24.18 Quit aaron424 ("ChatZilla 0.9.85 [Firefox 3.0.13/2009073022]") 22.24.28 Nick aaron424_ is now known as aaron424 (n=chatzill@adsl-065-013-002-216.sip.asm.bellsouth.net) 22.24.38 # Zagor: what I also noticed is that since-12-month doesn't go 12 month back 22.24.52 # pamaury: no, also only 32 bytes. 22.25.03 # * gevaerts misremembered that for a moment 22.25.38 # oh wait, it does now 22.26.27 # the archive files are not created as often as the front-page list 22.27.03 # I got the shuffled list stuff compiling at last, it doesn't make much binsize difference (as expected) 22.30.02 # pamaury: I think I'm going to commit the packet size limiting. It doesn't fix the real underlying problem, but at least then usb_serial will actually be usable 22.30.50 # I'll limit it to 32 though. That 96 sounds weird to me, and I suspect that it might be just a random multiple of 32, depending on where exactly in memory the buffer ends up 22.31.24 # yes, limit it to 32, we don't understand what this 96 is. Perhaps it's even related to the host 22.31.31 Quit fg56lx (Read error: 104 (Connection reset by peer)) 22.31.35 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 22.32.25 # gevearts: your previous fix wasn't sufficient, you need two MIN instead of one 22.34.44 # gevearts: is the usb_drv_arc doing packet splitting or is this done in hardware or even never done ? 22.35.05 # New commit by 03gevaerts (r22285): Limit usb_serial packets to 32 bytes. It's unclear why this is needed, but usb serial packets larger than 96 bytes seem to never be sent. ... 22.36.05 # pamaury: that's done in hardware... Hm, maybe the hardware isn't set up right... 22.36.46 # pamaury: is the fix I just committed still wrong? 22.36.48 # gevaerts, could it be that the usb serial host driver doesn't expect large packets? 22.36.50 # don't know. I get strange results with wireshark: sometimes it's a "transport endpoint shutdown" and sometimes its "protocal error" 22.36.57 # gevearts: no it seems ok 22.39.39 # ok. I'll leave it like this for now then 22.40.01 # bertrik: we set up a maxpacketsize of 512. AFAIK the host has to accept that... 22.41.53 # nearly any computer host will accept 512 I think. This is perhaps not the case if the host is a portable device 22.42.13 # it has to, or it shouldn't claim to speak usb 22.42.25 # it's in the spec ? 22.42.46 # allowed packetsizes are in the spec, yes 22.43.39 # which host driver is used for the usb serial port? 22.45.44 # I use the generic linux usbserial driver 22.45.58 Join petur [0] (n=peter@d54C6F282.access.telenet.be) 22.46.37 # It's not even related to usbserial driver. I've tried using a custom program using libusb. 22.46.37 # I thought usbserial was for "weird" usb serial devices and cdc-acm for normal cdc compliant devices 22.46.37 Join andrewbeveridge [0] (n=chatzill@88-109-234-58.dynamic.dsl.as9105.com) 22.47.12 # yes but cdc-acm requires a cdc-acm compatible device :) 22.47.22 # bertrik: ah, maybe. Well, we don't have all features that a cdc compliant device needs, so that's ok :) 22.47.33 # ok 22.48.15 # hi, could anybody explain why the "ACTION_WPS" action codes do not work in any context other than the WPS itself? 22.49.48 # because they were made to work in the wps context only? If you combine contexts you can easily get "overlapping" and unwanted effects 22.50.40 # yeah, it's, like the whole point of the context sensitive actions :) 22.50.48 # so for example, a player with a dedicated "play/pause" button. if one is not on the wps, the button is useless? 22.50.58 # no 22.51.17 # the button can hava a different action in another context 22.51.26 # have* 22.51.29 # right 22.51.39 # e.g. resume 22.51.44 # so there is no way to control music playback while on another screen? 22.52.27 Nick andrewbeveridge is now known as andrewRB (n=chatzill@88-109-234-58.dynamic.dsl.as9105.com) 22.53.02 # andrewbeveridge: depending on the target... some targets can use their stop button and play/pause/resume in some other screens than wps 22.53.07 # some players that have dedicated volume buttons (like the Gigabeat F and the sansa c200) give you the possibility to control the volume while in lists (menu, browser) 22.54.06 Quit Zagor ("Clint excited") 22.54.07 # but this has nothing to do with the actions, WPS* actions are for the wps, an action performed in a different context while it might do the same thing is not a wps action 22.54.41 # that's true 22.54.56 # man, something is wrong 22.55.14 # ok, well the target I am working on is the Cowon D2, so could you explain what I should be looking at if not the target specific keymap please? 22.55.14 # the whole recompiles from time to time :( 22.55.19 # +source 22.55.53 Quit amiconn (Remote closed the connection) 22.55.54 Quit pixelma (Remote closed the connection) 22.56.01 # (it has dedicated volume buttons, that is exactly what I would like to achieve) 22.56.23 # hm, http://build.rockbox.org/shownewlog.cgi?rev=22285;type=ipodmini2g#prob1 22.56.29 Join AsaelReiter [0] (n=d44c6c11@gateway/web/cgi-irc/labb.contactor.se/x-ac79f1aa9925e981) 22.56.58 # and http://build.rockbox.org/shownewlog.cgi?rev=22276;type=mrobe500 22.57.42 # New commit by 03gevaerts (r22286): fix typo 22.57.50 # ah, i see. for example the c200 - i see "ACTION_LIST_VOLUP" 22.57.51 # gevearts: did someone manage to raise a gcc internal error ? 22.58.04 # pamaury: I suspect things like bad RAM 22.58.28 # andrewRB: there are other targets that have dedicated volume buttons too, like the gigabeats for example, they use them for ACTION_LIST_VOLUP (and down) in the list 22.58.37 # if the same build client does that a few times more, I guess it's blacklist+talk to owner time 22.58.38 # Hi 22.58.38 # * n1s slow 22.58.50 # How can I check the CPU usage of a plugin? 22.59.15 # gevearts: would it be possible that you or someone else try to see if this 96 limit for usbserial maintains for other target and with other hosts ? 22.59.29 # pamaury: I can, but not today 22.59.53 # gevearts: Ok, I will try myself on a another computer 23.04.04 Part heavysidecar ("Ex-Chat") 23.04.08 # n1s: thanks, I now see what I want in the gigabeat-s keymap. Still not sure which file I should be looking at though =/ 23.04.26 Part Llorean 23.06.07 Join pixelma [0] (i=quassel@rockbox/staff/pixelma) 23.06.11 Join amiconn [0] (i=quassel@rockbox/developer/amiconn) 23.06.12 # andrewRB: what are you tring to do? 23.06.34 # gevearts: I have the same problem on another computer 23.07.22 # the D2 has three hardware buttons; volume up/down, and play/pause. I want these to control music playback, whatever screen I am on, since the touch screen is used for navigation. 23.08.08 # you need to add some new actions, and then in every screen you want them to work you need to add handlign for thme 23.08.15 # I thought I could simply edit "keymap-cowond2.c" but I was wrong 23.08.38 # the other option is add the handling to default_event_handler(), but thats not very nice 23.09.26 # omg again! 23.09.59 # maybe a better question for me to ask was, is there anything I can read to help me learn my way around the rockbox source? Simply reading the code, I'm going round in circles. 23.10.11 # there isnt... 23.11.32 # andrewRB: the only easy place to add these actions is in the list context as other targets already have that functionality, other contexts will be a little more work 23.12.02 # ok, thanks. 23.12.13 Join ehntoo [0] (n=ehntoo@adsl-99-156-195-44.dsl.applwi.sbcglobal.net) 23.12.18 Quit stoffel (Remote closed the connection) 23.13.40 *** Saving seen data "./dancer.seen" 23.13.52 # * scorche prods petur and 2 other missing people into -gsoc 23.17.11 # would there be any reason for me not to add "ACTION_STD_VOLUP"? 23.18.07 # well... ideally every ACTION_STD_ must be handled in every action handler... and that each target should have it 23.18.14 # putting it in the list context makes more sense 23.18.27 # gevearts: Are there any specifications available for the usb drivers ? (more precisely for sansa e200 --> usb_drv_arc ?) 23.19.05 # JdGordon|: the list context includes the menu and file browser, right? 23.19.13 # yes 23.19.21 # anything that has that obvious list look 23.19.29 # haha. great, thanks 23.19.38 # i.e 90% of rockbox's ui 23.21.21 # AsaelReiter - which plugin? simple answer is probably 'not easily', but by using profiling you might be able to compare cpu time to clock time 23.21.36 # pamaury: yes. The iMX31 reference manual (MCIMX31RM.pdf) from http://www.freescale.com/webapp/sps/site/prod_summary.jsp?ProdMetaId=PID%2FDC%2Fi.MX31&isAdvanceSearch=false&showCustomCollateral=false&RELEVANCE=true&Documentation=Documentation/13010Ksfwlk``Reference Manuals&fromTrng=false&fromPSP=true&showAllCategories=false&fpsp=1&SelectedAsset=Documentation&&assetLocked=false&leftNavCode=1&assetLockedForNavigation=true&code=i.MX31&isResult=false&c 23.22.20 # stripwax: brickmania, with some changes that I wrote 23.22.49 # pamaury: http://tinyurl.com/nmx6zo is going to work better. That's the SoC of the gigabeat S, but the USB controller is the same as the one in the PP502x chips 23.24.07 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 23.26.41 # AsaelReiter - if it's possible to isolate your code change, and profile that in a standalone environment, then you could try that. 23.26.48 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 23.28.20 # I think it's not possible. 23.30.14 # (The most important change is simplify some colossal loops) 23.31.25 # If the code is simplified, and the algorithmic complexity doesn't increase, and the instruction count goes down, then it sounds like a good change, even if the benefit can't easily be quantified 23.31.34 # gevearts: it there a document for usb programming in the link you gave me or is it only an electrical sheet ? 23.32.06 Quit stripwax ("http://miranda-im.org") 23.32.10 # pamaury: MCIMX31RM.pdf has the full programming interface 23.33.08 Quit AsaelReiter ("CGI:IRC") 23.33.19 Quit HellDragon (Client Quit) 23.33.27 Join AsaelReiter [0] (n=d44c6c11@gateway/web/cgi-irc/labb.contactor.se/x-70d0eb4621e0607b) 23.35.13 # gevearts: perhaps I'm stupid but I can't find it. There are 146 pages and I can't find the full programming interface except board regaisters 23.37.42 # pamaury: you mean 146 pages of USB docs, or 146 pages total? If the latter, you've got the wrong file 23.38.18 # the latter, but that's the MCIMX31.pfg 23.38.24 # I'll try you're first link 23.38.38 # pamaury: you need MCIMX31RM 23.39.08 # you can try google for MCIMX31RM.pdf I guess 23.39.23 # yes that's what I mean, I downloaded the MCIMX31RM.pdf and it's only 146 pages long 23.39.44 # the whole RM is thousands of pages 23.40.32 # 2364 pages, ~14MB 23.41.25 # definitely I downloaded the wrong one but I can't find it. 23.41.41 # hm, there seems to be something wrong there 23.42.10 Join safetydan [0] (n=deverton@rockbox/developer/safetydan) 23.42.59 # amiconn: there's a newer rev with even more pages, not sure if the additions are very interesting though 23.46.16 # are you sure the link you gave me is still good ? 23.46.37 Quit krazykit ("Lost terminal") 23.46.43 # it looks like the version they have now isn't complete 23.46.47 # this is the real RM http://www.freescale.com/files/32bit/doc/ref_manual/MCIMX31RM.pdf?fpsp=1&WT_TYPE=Reference%20Manuals&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation 23.47.13 # hmm, or maybe not 23.47.19 Join krazykit [0] (n=kkit@c-24-218-166-241.hsd1.ma.comcast.net) 23.47.30 # says rev 2.4 but only 3MB 23.47.34 # it's the same: 146 pages lonk 23.47.36 # *long 23.48.54 # .ll,s.k 23.48.57 Quit AsaelReiter ("CGI:IRC") 23.49.10 # looks like freescale replaced the file on their server 23.49.31 # :/ 23.49.37 # http://www.christian-gmeiner.info/soc/MCIMX31RM.pdf 23.49.51 # google found it in the rockbox irc logs :-) 23.50.00 # thanks :) 23.52.01 Quit petur ("Zzzzzz") 23.52.02 # I think the other ARM-based imx SoCs have the same USB core 23.52.48 Join AsaelReiter [0] (n=d44c6c11@gateway/web/cgi-irc/labb.contactor.se/x-2dd38461f03d88f9) 23.52.49 # does this include the sansa ? 23.53.53 # sansa is PortalPlayer 5022. We don't have a datasheet for that at all, but the USB core is clearly the same (otherwise the driver wouldn't work) 23.53.56 Quit bmbl ("Bye!") 23.55.07 # On the whole, have you got access to lots of specifications ? 23.56.10 # gevaerts: this ofcourse only applys to the current supported sansas. :-) 23.56.27 # of course :) 23.57.05 Quit AsaelReiter (Client Quit) 23.57.30 # pamaury: it depends. Some manufacturers like freescale have freely available specs, others like portalplayer (now nvidia) have none at all. There's everything in between those two 23.58.30 # And won't portalplayer give you the spec (I read somewhere that they contacted you no ?) 23.58.32 # ? 23.58.49 # Sandisk contacted us, not PortalPlayer. 23.58.59 # and then there is the very seldom case where a manufacturer provides us with normally not public specs (i think only AMS did that) :-)