--- Log for 31.05.109 Server: jordan.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 11 days and 16 hours ago 00.00.28 Part BryanJacobs ("Leaving.") 00.01.24 # New commit by 03amiconn (r21138): Fix shutdown splash. It is meant to be shown on an empty screen. 00.04.32 Quit AndrewRB ("wheeeeeeeeeeeeeeeeeeeeeeeee!") 00.04.39 # Smarty error: http://themes.rockbox.org/index.php?target=h300 00.05.58 # amiconn: can the fore/background pattern for greyscale be made so that accessing viewport.fg_pattern and .bg_pattern is the same as calling lcd_set_foreground and _background? 00.06.22 # no 00.06.29 Quit AlexP (Read error: 60 (Operation timed out)) 00.06.32 # That's why these functions exist. 00.06.40 Join AlexP [0] (n=alex@rockbox/staff/AlexP) 00.08.01 # Greyscale foreground/background is an integer with a range of 0..(num_greylevels-1). The patterns are derived from that, however, the way they're derived differs between greyscale formats 00.08.49 # Even the number of bits is different. For horizontally and vertically packed greyscale, they're 8 bit, but for vertically interleaved greyscale they're 16 bit 00.10.13 # hm 00.11.10 Quit MarcGuay_ (Read error: 54 (Connection reset by peer)) 00.11.30 # the patterns are an abstracted already for the different formats, so they wouldn't be the problem 00.11.56 Join BdN3504 [0] (n=55b2079f@gateway/web/cgi-irc/labb.contactor.se/x-89496f4a86fe7bb6) 00.12.22 Quit stoffel ("leaving") 00.12.27 Quit calman_ (Read error: 110 (Connection timed out)) 00.13.17 Quit amiconn (Nick collision from services.) 00.13.20 Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) 00.13.39 Join moos [0] (i=mustapha@rockbox/staff/moos) 00.13.39 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 00.13.46 # fg_pattern and bg_pattern are an internal optimisation and are not meant for direct access from outside the lcd drawing code 00.14.02 Quit pixelma (Nick collision from services.) 00.14.04 Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) 00.14.22 Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) 00.15.15 # They will stay correct if you copy them from one viewport to another, but you shouldn't make any assumption about the relation between the argument for lcd_set_XXXground() and the pattern value 00.15.15 Quit {phoenix} (Remote closed the connection) 00.15.22 Quit advcomp2019 ("Nice Scotty, now beam my clothes up too!") 00.15.31 # yes, I noticed that 00.15.38 # that's why I'm asking if that can be changed 00.16.38 Quit ender` (" Today is the tomorrow you worried about yesterday.") 00.17.05 # commit r21138 is womewhat funny, it displays the wps background file. i think this should be the backdrop. 00.17.18 Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) 00.17.30 # Hmm, actually the pattern values in the viewport struct are equal to the argument, however, the driver needs to update its internal patterns accordingly 00.18.10 # yes 00.18.56 # * amiconn wonders what kugel is trying to do 00.19.19 # nothing, I was just confused by the fact that setting the viewport members doesn't work 00.19.35 # since that works for mono and color, but not for greyscale 00.19.59 # if i don't rb->close a file from a plugin, does it leak? 00.20.24 Quit Zarggg (Read error: 60 (Operation timed out)) 00.20.56 # kugel: Imo colour should do the same, for speed reasons 00.21.28 # Right now each and every drawing function in lcd-16bit.c does the current_vp->XX_pattern lookup, over and over 00.22.02 # current_vp is in iram, but the next data fetch might even hit dram (depending on whether the viewport is in iram or dram) 00.22.22 # Mono has no problem here because there are no "colours" 00.22.47 Quit BdN3504 ("CGI:IRC (EOF)") 00.23.58 Quit calman__ () 00.24.07 Quit advcomp2019 ("I was raided by the FBI and all I got to keep was this lousy quit message!") 00.25.16 Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) 00.25.52 # Hmm. Drawing functions are reading other viewport members as well. Performance tests would show whether caching them in iram variables makes sense. 00.26.37 Quit advcomp2019 (Client Quit) 00.27.14 Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) 00.28.06 # saratoga: going to wps turned out quite easy 00.28.38 # I just needed to add a new return type to the enum and adapt the lists to catch that 00.30.36 Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 00.34.59 Quit bluebrother ("Leaving") 00.36.25 # Llorean, outside the fact battery_bench is failing to write records on AC charge...going ok. 00.36.51 # I was out of town for two nights there, so there was a pause. Doing the USB charge with #8802 as we speak. 00.36.54 Quit intrados (Read error: 60 (Operation timed out)) 00.37.32 # I'm less concerned about the AC situation, as can confirm stock is charging (at least when playback is inactive). 00.39.19 Quit Tristan (Remote closed the connection) 00.41.56 Quit advcomp2019 ("+++ OK ATH OK") 00.43.31 Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) 00.46.46 Quit pat_mulchrone (Read error: 104 (Connection reset by peer)) 00.47.00 # Unhelpful: ping 00.47.01 Join pat_mulchrone [0] (n=pat@99-13-70-2.lightspeed.cicril.sbcglobal.net) 00.47.55 Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) 00.52.34 Quit Beta2K (Read error: 60 (Operation timed out)) 00.55.29 Join lee321987 [0] (n=chatzill@1Cust6177.an1.cle11.da.uu.net) 00.56.32 # Does lua script support RB "Copy" and "Paste" commands? 01.00.13 Quit n1s (Remote closed the connection) 01.05.08 Quit robin0800 (Remote closed the connection) 01.05.25 Join perfectdrug [0] (n=marko@p5B0ED8E9.dip.t-dialin.net) 01.06.15 # Does Maurus Cuelenaere ever hang out here? (I thin his nick starts like "MCu------") 01.07.03 # pixelma: I just added the last SVG for the AMS sansas FS#10265 - sansa m200 :) 01.07.27 Quit bertrik (Read error: 60 (Operation timed out)) 01.08.26 # lee321987: yes 01.09.00 Quit toffe82 (Remote closed the connection) 01.16.47 Quit lee321987 ("ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]") 01.35.49 # New commit by 03amiconn (r21139): Two tiny optimisations for mono bitmap drawing on greyscale displays: (1) H1x0, M5: Manipulate destination masks directly for the aligned case - ~0.7% ... 01.38.20 *** Saving seen data "./dancer.seen" 01.42.29 Quit DarkDefender ("Leaving") 01.57.13 Join kperri [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-c475d87f2e960e56) 02.02.55 Join Tristan [0] (n=Tristan@i.dont.want.to.die.virgin.net.in) 02.03.05 Quit Nico_P (Remote closed the connection) 02.06.44 # kugel: yes? 02.08.13 Quit pat_mulchrone (Read error: 104 (Connection reset by peer)) 02.09.56 Quit matsl_ (Read error: 110 (Connection timed out)) 02.09.59 # Unhelpful: I'm having problems with the keymap in pf 02.10.25 # kugel: if it's about the button-map business you mentioned in the other other channel, i'd suggest that you use the tracklist view, which is the same as the core standard context except for the dedicated quit key. 02.10.39 # I was trying to chain in CONTEXT_TREE, but it didn't work at all 02.11.05 # no, those contexts are designed to chain to CONTEXT_STD. use TREE by itself, maybe? 02.11.23 # as a third context? 02.12.08 # and why should pf context > CONTEXT_TREE > CONTEXT_LIST > CONTEXT_STD not work (context list actually works, but that doesn't give the WPS button) 02.20.13 Join pat_mulchrone [0] (n=pat@99-13-70-2.lightspeed.cicril.sbcglobal.net) 02.20.24 # because tree and list mask things in standard that i want, sometimes. also, the "core" list or tree context is sometimes really CONTEXT_LIST|CONTEXT_CUSTOM, etc - and that won't work with get_custom_action. 02.21.19 # what exactly do you want that's not in PF's tracklist context? it has select, context, cancel, quit, and scroll... 02.23.34 # Unhelpful: CONTEXT_TREE is in the context enum 02.23.50 # amiconn: if i have a non-aligned int array on targets, i need to read it as characters and use shift/or to build whole ints, don't i? or if it's short-aligned, i can read half an int at a time... 02.23.56 # kugel: ok? 02.24.16 # go to wps. That's what I want 02.24.57 # do you want that from anywhere in pictureflow? 02.25.29 Join KBH- [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 02.25.55 # if possible, of course 02.26.41 # it's a list button, so it will automagically work in the tracklist and album view I guess 02.27.19 # I think I know what the problem is 02.27.41 # that's not a good assumption. tracklist is really just standard with the quit button added. album is tracklist with horizontal scroll added, and remapping for things that that masks. 02.28.24 Part perfectdrug 02.28.27 # if you want to add a new button mapping for everywhere in PF, add it to pf_context_buttons 02.28.43 # anything in there appears in tracklist and album list 02.30.25 # if it's started from WPS, won't core go back there when it's quit? 02.30.41 # no 02.30.55 # there's no way to go directly to the wps in SVN 02.32.06 # there's nothing like starting wps from PF in svn. :) 02.32.19 # PF will need to clean up its thread, and exit, i'd think? 02.32.30 # sure 02.32.38 # I added a PLUGIN_GOTO_WPS exit code 02.33.21 # well, one thing you could do is pass a parameter when starting it from WPS, so that it will "know" to return PLUGIN_GOTO_WPS on quit. 02.34.31 # I'm not starting it from wps yet 02.35.32 # i'm not really sure we need a dedicate "go to WPS" button, but if you're looking to add a button to both views in PF, pf_context_buttons is the place. 02.36.44 # I'm not looking into adding the buttons manually 02.36.52 # I would really like to use the standard core button for that 02.38.12 Quit KBH (Read error: 104 (Connection reset by peer)) 02.38.13 Nick KBH- is now known as KBH (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 02.38.20 # i tried to use context_tree. the "proper" context_tree is completely incompatible with custom actions on some targets, and besides that it masks some things in context_std. 02.39.53 Join intrados [0] (n=intrados@cpe-71-67-129-220.woh.res.rr.com) 02.41.26 # aside from that, PF's contexts were designed *by hand* to go on top of a specific core context. just changing that context stands a good chance of breaking the whole thing. 02.44.31 # so, you think I'm better off adding them manually? 02.45.09 Join KBH- [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 02.45.12 # TREE and LIST only add 4 buttons on top of STD, 2 of them are mostly rarely used combos 02.47.10 # which target are you looking at? :) 02.48.31 # the CONTEX_CUSTOM thing is still going to be a problem, also. 02.49.11 # if you chain to CONTEXT_TREE on gigabeat, core will chain to CONTEXT_CUSTOM|CONTEXT_TREE, which will get passed back to PF, even though it doesn't know what to do with that. 02.50.09 # i suggested this back then, and ended up fixing it by using CONTEXT_STD as a base, but a "proper" soluting would be to replace CONTEXT_CUSTOM for "use the custom action function" with CONTEXT_PLUGIN 02.50.19 # since core also uses CONTEXT_CUSTOM 02.50.33 Quit KBH (Read error: 104 (Connection reset by peer)) 02.50.45 Nick KBH- is now known as KBH (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 02.56.38 Nick efyx_ is now known as efyx_zZz (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 02.57.27 # Unhelpful: Why does the beast that? 02.59.31 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 02.59.54 # core selects from two tree contexts based on a setting, when passed CONTEXT_TREE. they're both based on CONTEXT_TREE|CONTEXT_CUSTOM. 03.00.22 # grml 03.00.43 # ipod has CONTEXT_TREE|CONTEXT_CUSTOM as well. 03.00.46 # ok, with CUSTOM_CONTEXT2, the thing works better, but it doesn't really chain 03.03.07 # in the album view, it should go "album map (pf_contexts[0]) > normal map [pf_contexts[1]) > context_std", right? 03.04.02 # CUSTOM_CONTEXT2 won't cause get_action_worker to call the context hook again. if you want to be able to chain to *any* core context, you need to create a context for that purpose that is not used for anything by core - like i said, CONTEXT_PLUGIN, and replace the CONTEXT_CUSTOM in PF and PLA with that as well. 03.04.34 # and yes, that's how the PF contexts chain currently. 03.05.34 # i still think adding a button manually might be easier. you'll need to think about how it would work on each target *anyway* :) 03.08.41 # I see 03.11.21 Join shadoxx [0] (n=witherb@MW1-DSL-74-215-1-115.fuse.net) 03.12.43 # Unhelpful: I guess we want pf to be able to go to the wps if it gets database integration 03.25.02 Join KBH- [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 03.26.37 Join toffe82 [0] (n=chatzill@adsl-75-12-169-110.dsl.frs2ca.sbcglobal.net) 03.27.35 Quit efyx_zZz (Remote closed the connection) 03.34.10 # kugel: so that selecting a track plays the set and takes you to WPS, as it would from the DB? 03.35.05 # Unhelpful: that could be done, but I wouldn't want that in the pf case 03.35.39 # since pf is purely eyecandy, one might want to stay longer there after selecting a file 03.36.00 # (also since you can't get easily back to pf as you can from the database) 03.36.36 # but it shouldn't be more than 1 or 2 button presses away imo 03.37.55 # what about a "quit to WPS" menu item? the menu is one press everywhere :) 03.38.24 *** Saving seen data "./dancer.seen" 03.45.17 # Unhelpful: see the patch I just upload (before you mentioned it :) ) 03.46.28 # ah. nice. :) 03.46.49 # i think a menu item is fine, at least until somebody fixes CONTEXT_CUSTOM or adds keys for it. 03.47.41 Quit KBH (Read error: 110 (Connection timed out)) 03.47.41 Nick KBH- is now known as KBH (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 03.49.16 # Unhelpful: would be nice if you look at the 3rd patch, I plan to commit it soon (without the tagtree and go to wps bits) 03.49.50 # also, we have to figure out how we get the core context menu attached 03.50.26 # did you change any of those CONFIG_ defines, or is that part just tab-nanny stuff? 03.50.36 # tab-nanny 03.51.07 # the third patch is the one above though :) 03.51.29 # mapped to ACTION_NONE in PF doesn't mean "not used" - it usually means "masking a troublesome item from CONTEXT_STD" 03.51.45 # sorry, i looked at the one that said "v3" ;P 03.52.17 Quit Thundercloud (Remote closed the connection) 03.52.44 # ah yea, the 2nd one wasn't really v2 worth :) 03.54.23 # I hope the \n placeholder isn't too much of a hack :/ 03.54.32 # fn_offset can be calculated, by using strlen. track_names + tracks[track_index].name_idx + rb->strlen(&(track_names + tracks[track_index].name_idx)) 03.54.57 # fn_offset is calculated 03.54.57 # or you could store the actual index for it and not have to sum with name_idx 03.55.02 # it's the return val of snprintf 03.55.48 # what's the purpose of the \n? 03.55.56 # to make strcat work 03.56.03 # Unhelpful: are you sure about that &? 03.56.38 # Mikachu: you're right, the & doesn't belong... and that lets you drop a set of parens as well. 03.57.04 # arguably &track_names[tracks[track_index].name_idx] is better 03.58.30 # Unhelpful: strcat replaces the \0 in dest, hence a byte is lost 03.58.48 # a needed one 03.59.04 # kugel: why use strcat at all? why not fetch the filename directly into the buffer? 03.59.29 # I tried that, but that didn't really work 03.59.49 # it's working fine for my local tree with album names. 04.01.55 # * kugel tries harder 04.02.52 # after you've got len, do the tag fetch with &names[string_index] as the target. then do strlen(&names[string_index]) to find out how long it was. 04.03.38 # btw, you should pre-check that MAX_PATH space is available, because tagcache_retrieve doesn't fail on EOM. 04.05.49 # perhaps the "free buffer until we have X bytes" loop needs to be split out. 04.06.17 # Unhelpful: that strlen after might get a bit trick then though 04.07.01 # hm, I just need to substract actually 04.07.27 # hm no 04.08.48 # ok, seems to work 04.09.18 # Unhelpful: I thought passing avail to tagcache_retrieve was ok 04.10.51 # kugel: it is, but if you look at tagcache_retrieve it uses the passed size as a length limit, but doesn't *fail* on hitting it - it can return true when you don't have the whole string. 04.11.18 # uhm 04.11.22 # not nice 04.11.28 # that should be fixed 04.11.49 # it returns false on failure to retrieve. 04.12.20 # maybe it thinks not having the full string isn't significant enough to fail at all 04.12.51 # we could diffentiate the return values with ints 04.13.52 # even so, the "free until we have X bytes" loop ought to be split out into a free_buffer() function so that we can use it to avoid failure due to lack of space on the filename fetch. you wouldn't want to free more buffer to load the title, but just fail if you can't fit the filename. 04.13.53 # how to handle avail to small anyway? 04.14.15 # that's what that loop is for :) 04.15.09 # free_slide_prio will free the lowest-priority slide. then buffer_out gets you the space that was freed, as a chunk cut from the front of buflib's buffer. 04.15.52 # I didn't really look at that part of the function :) 04.16.32 # Unhelpful: ok, the hunk looks like that now: http://pastie.org/495400 04.17.39 # btw, the colons should be dots, as per tagree imo 04.17.48 # tagtree* 04.18.59 Join lude187 [0] (n=chris@cpe-75-187-51-53.columbus.res.rr.com) 04.19.05 # um, the len>avail check is gone? 04.19.26 # nevermind, pushed down :) 04.20.20 Quit lude187 (Client Quit) 04.20.23 # i think that looks good. maybe retrieve should return length, -1 on fail? 04.20.25 # fn_off should maybe substracted from avail :S 04.20.47 # that seems like a great idea 04.21.25 # kugel: i don't think you need to subtract it from avail - you've added it to len. 04.21.35 # hah, right 04.21.45 # way too late here :( 04.22.04 # might be time to call it a night. it certainly is for me. 04.22.24 # but wait, it should, since it's passed to tagcache_retrieve 04.22.30 # actually retrieve needs two error codes, -1 for fail, -2 for EOM. 04.23.07 # just use avail-fn_off, since you'll be subtracting len from avail later. or don't include fn_off in len. 04.24.20 Join __lifeless [0] (n=lifeless@188.16.121.77) 04.26.36 # Unhelpful: will you change the error code soon (as in before I commit this or after)? 04.29.36 # hrm, actually, couldn't retrieve just return needed len or -1 on error? caller can decide if len>avail is important. 04.30.45 # that would, aside from the -1, work "just like snprintf" :) 04.31.47 # i can't bang on the error code issue right now. if you want to make it safe for now, do the free+retry on avail < fn_off +MAX_PATH 04.32.15 # -1 includes the EOM case? 04.32.37 # I'd be fine with -2 on EOM. 04.33.09 # kugel: i'd prefer length-needed-on-EOM because then the caller *also* knows how much more space it needs. :) 04.33.10 # one shouldn't ask for -1 at snprintf anyway, but < 0 04.34.55 # how would needed len look like? 04.37.01 Quit __lifeless (Read error: 54 (Connection reset by peer)) 04.37.11 Join __lifeless [0] (n=lifeless@188.16.121.77) 04.38.50 # Unhelpful: having it work like snprintf would work well. that makes EOM detectable 04.39.13 Quit _lifeless (Read error: 113 (No route to host)) 04.39.42 # also, does tagcache_retrieve write the \0 byte? 04.43.17 Quit kugel ("exit(0);") 04.45.29 Join Andrew_ [0] (n=chatzill@71-14-69-177.dhcp.stls.mo.charter.com) 04.45.37 # hello? 04.45.55 Nick Andrew_ is now known as Guest57333 (n=chatzill@71-14-69-177.dhcp.stls.mo.charter.com) 04.46.28 # hello? 04.46.52 # Guest57333, hello.. you have question? 04.46.58 # yah! 04.47.00 # HEY 04.47.04 # whats up dude 04.47.10 # its AndrewJ from ABI 04.47.34 Join itcheg [0] (i=62db4c46@gateway/web/ajax/mibbit.com/x-db6ec96601e24057) 04.48.02 # advcomp2019? 04.48.09 Nick Guest57333 is now known as AndrewJ (n=chatzill@71-14-69-177.dhcp.stls.mo.charter.com) 04.48.33 # AndrewJ, look at the topic 04.49.23 # advcomp2019: sorry 04.52.52 Quit chandoo ("Leaving") 04.56.56 Join guest [0] (n=62d4a6c0@gateway/web/cgi-irc/labb.contactor.se/x-482fbe0a3073cfa8) 04.57.12 # Hello 04.57.24 Nick guest is now known as Guest24253 (n=62d4a6c0@gateway/web/cgi-irc/labb.contactor.se/x-482fbe0a3073cfa8) 04.58.12 # Is there anyone here that could point me to the proper link to the latest version of the source for Rockbox on the fuze? 04.58.36 # I understand that it's not a proper port yet and unsupported, but I can't find any link to the current testing build. 04.58.41 # Could anyone please help? Thanks. 04.58.55 # svn.rockbox.org 05.01.27 # Scorche, is this in response to my q? If so, could you please let me know where the file would be located. Sorry that I'm a little unsteady on my feet, but I'm a n00b at rockbox specifically. 05.02.28 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 05.03.15 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 05.03.50 # Guest24253: yes...you asked where the source is, so i pointed you at the source...there is no "file" yet as it is not completed yet, as you mentioned 05.04.17 # until it reaches that point, it is not really suitable for "n00bs" as you put it 05.06.26 Quit fyrestorm (Read error: 104 (Connection reset by peer)) 05.11.24 # Does anyone here know how to get the Funny Languages (http://www.rockbox.org/twiki/bin/view/Main/FunnyLangs) to work? I have not the slightest idea how to 05.15.17 # scorche, thanks for the input 05.15.32 # however, all I meant was that I was unfamiliar with the rockbox website 05.15.53 # I know my way around UNIX and Linux quite well, and I'm well-versed in several programming languages. 05.16.14 # And I'm just a little put-off by your rudeness. 05.16.20 Join fyrestorm [0] (n=nnscript@cpe-24-90-81-178.nyc.res.rr.com) 05.18.13 # erm...ok... 05.23.40 # Sorry to sound rude myself, but I came on here with a question and you immediately shut me down. 05.23.57 # And I know people who have compiled source from the Fuze distro. 05.24.04 # So I was just looking for a little help... 05.24.24 Quit shadoxx (Read error: 113 (No route to host)) 05.25.11 Quit Guest24253 ("CGI:IRC (EOF)") 05.30.00 Quit RandomDestructn (Remote closed the connection) 05.34.09 Join shadoxx [0] (n=witherb@MW1-DSL-74-215-1-115.fuse.net) 05.36.11 Quit mirak ("Ex-Chat") 05.38.26 *** Saving seen data "./dancer.seen" 05.46.35 Join BabaChoowa [0] (n=noisybit@c-24-5-234-17.hsd1.ca.comcast.net) 05.55.57 Join rethgir [0] (n=jason@cpe-174-106-024-033.ec.res.rr.com) 06.10.54 Quit shadoxx (Read error: 60 (Operation timed out)) 06.11.27 # I've recently registered to edit the rockbox wiki and would like to request edit privileges if possible. Thanks in advance! 06.12.10 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 06.35.09 Join AndyIL [0] (i=AndyI@212.14.205.32) 06.36.57 Join AndrewRB [0] (n=andrewbe@88-109-116-126.dynamic.dsl.as9105.com) 06.37.19 # hi 06.38.29 # could anybody help me get my desired functionality with the WPS Keymap for the D2? 06.38.40 # have a look at these two lines: http://pastebin.com/m3bf109d 06.39.32 # what I want is to be able to press the holdmenu button once to "play/pause", or hold it briefly to skip to the next track 06.39.48 # rethgir: you should have privileges now 06.40.13 # with those two lines as they are, it does that, except when I hold the button it skips the track *and* pauses. 06.40.21 Join timc [0] (n=aoeu@119.109.101.213) 06.40.35 # clearly, holding it is activating the first line and the second. 06.41.06 # please could somebody explain how I could do that? (unless it isn't possible) 06.42.35 # kkurbjun: Thank you very much! :) 06.45.54 # have i asked at a bad time, or did i say too much too fast? (i don't mean to sound demanding ><) 06.47.28 # AndrewRB, there are not too many people active at this time of the day, I'm not sure on the keymaps offhand, there is a way to make short presses and long presses do different actions, but again, I'm not sure on the method offhand 06.48.22 # can someone here give me a hint how to start software developing for the iriver e100? 06.48.33 # I would suspect that it has something to do with the BUTTON_REL that you have since that should activate the action when you release 06.48.35 Quit AndyI (Read error: 110 (Connection timed out)) 06.48.58 # I think you would want something that includes BUTTON_REPEAT immediately 06.49.14 # kkurbjun: ok, thanks for responding =) Well, I already have it responding to a "long press" - it skips to the next track when you *release* the button after *repeating* the button (holding it down) 06.49.43 # the problem is that when it is pressed initially, it pauses it (then goes on the "repeat", then when released it "skips") 06.51.41 # hmmm. maybe if i changed the first line's button code to "BUTTON_HOLDMENU|BUTTON_REL" 06.51.43 # yeah, I think it's still with that REL line in there, that second line should always active on a release event, I think 06.52.56 Quit froggyman ("CGI:IRC (Ping timeout)") 06.53.14 # well, the first line as it is is activating whenever the button is pressed, and by "pressed" i assume that is on press, not on release. 06.53.36 # I think what you might want is for the second line to have something like BUTTON_HOLDMENU|BUTTON_REPEAT, BUTTON_NONE }, 06.53.39 # the second line is activating whenever the button is released, *after being repeated* 06.53.49 # that should activate when the button is pressed and held 06.53.57 # and there is no pre-req 06.54.20 # the d2 might not be handling repeats properly though too 06.54.31 # I tried that initially - problem with that is it repeats that action while the button is held - so in reality it skips the track several times. 06.54.31 # it's touchscreeen right? 06.54.42 # oh, gotcha 06.54.44 # yeah, but I'm not using the touch screen in this case 06.55.57 # hmm, maybe try oring in the REL with the repeat too, but I don't know if that is correct.. I'm sure there are some other targets that show how it should be done 06.56.04 # if the prereq is BUTTON_NONE, does that mean the pre-button doesnt matter, or it must be nothing? 06.56.12 # the gigabeat should have an example on the menu button for going to the quickscreen 06.56.36 # I think it means that it doesn't matter 06.57.10 Quit intrados (Read error: 104 (Connection reset by peer)) 06.57.14 # yeah, the gigabeat has an example in the WPS mappings for the menu 06.57.25 # right. because all i really want is for the first line to *only* activate when the button is pressed once, not repeated - so if the prereq was exclusively "nothing" then that would solve the problem 06.57.32 # ok lemme have a look, thanks 06.58.10 # what does quickscreen do? 06.58.36 # it brings up a menu that only has 3 options that are customizable 06.59.32 # so in the gigabeat file, "BUTTON_MENU|BUTTON_REPEAT, BUTTON_MENU" is a "long press" and "BUTTON_MENU|BUTTON_REL, BUTTON_MENU" is a "short press", right? 06.59.38 Nick JdGordon|afk is now known as JdGordon (n=jonno@rockbox/developer/JdGordon) 06.59.54 # yep 06.59.57 # should be 07.00.31 # thanks, let me compile and test 07.02.20 # perfect =) 07.02.22 # thankyou very much 07.02.33 # :), glad it worked 07.02.53 # i had actually been looking at other ports, but not the gigabeat one. besides, with no real knowledge of what things were meant to do, i was just guessing. 07.03.10 # now i can fiddle with other things again, haha. 07.05.43 Join intrados [0] (n=intrados@cpe-71-67-129-220.woh.res.rr.com) 07.15.07 # Hi there! Did someone give a try to port rockbox to the iriver e100? 07.17.42 # MarcGuay: pong? 07.20.16 Quit AndrewJ ("ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]") 07.26.37 # BabaChoowa: http://forums.rockbox.org/index.php?topic=19522 07.26.54 # in short, yes they thought about it. no it probably isn't goign to happen 07.27.37 # oh... too bad. 07.27.44 # thank you for the link! 07.27.51 # i'll check it. 07.28.00 # forums -> search -> type "e100" 07.32.01 # i see. unfortunately there is not that much. hmmm... Andrew, do you have an idea how "someone" could start porting rockbox to the e100? Where should that guy start? 07.32.06 Quit advcomp2019 ("Going!") 07.32.36 # we need someone to figure out the firmware encryption... 07.32.46 # or find a way to run our own code on it.... 07.33.12 # * AndrewRB was about to point at JdGordon =) 07.34.35 # really, cowon makes it easy for us - the firmware update files can be used as a way to run code on the player 07.34.41 # thank you JdGordon. I see... encryption makes reverse engineering quite hard. 07.35.49 # Just for my understanding, cowon is a company? 07.36.11 # sure, who make the only player i own (the Cowon D2) 07.36.41 Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) 07.37.11 # *g* ... i see 07.38.29 *** Saving seen data "./dancer.seen" 07.40.56 Part toffe82 07.44.27 # goodnight guys. thanks again for the help kkurbjun. (i say "night", but it is 6.44 AM... oops) 07.44.54 Quit AndrewRB ("ZZZZZZZzzzzzzzzzzzzzzzzzzzz..............") 07.48.12 # New commit by 03jdgordon (r21140): fix FS#10261 - the files context menu (as an example) would get skipped and the first items context menu get shown instead 07.52.00 Quit jmillikin (Read error: 110 (Connection timed out)) 07.58.21 Join Horschti [0] (n=Horscht@xbmc/user/horscht) 08.07.40 Join evilnick_home1 [0] (n=evilnick@pool-173-52-142-29.nycmny.east.verizon.net) 08.15.45 Quit Horscht (Read error: 110 (Connection timed out)) 08.19.24 Quit evilnick_home (Read error: 110 (Connection timed out)) 08.24.31 # Unhelpful: Depends on the target. Coldfire supports reading & writing unaligned (although it's slower, hence not recommended for performance reasons). ARM and SH1 don't - you'll get an exception (Data Abort on ARM, CPUAdrErr on SH1). I don't know about MIPS 08.28.51 # If you have a struct that is decalred with __attribute__((packed)), gcc will take care of unaligned accesses to multi-byte variables within the struct 08.29.34 # * amiconn used this gcc feature in ata_mmc.c - see send_cmd() (line 330) 08.29.55 Join Rob2222 [0] (n=Miranda@p4FDCF196.dip.t-dialin.net) 08.30.17 Join n1s [0] (n=n1s@rockbox/developer/n1s) 08.33.21 Quit kkurbjun (Read error: 110 (Connection timed out)) 08.37.28 Quit BlakeJohnson86 (Remote closed the connection) 08.46.51 Quit dmb (Nick collision from services.) 08.47.52 Quit Rob2223 (Read error: 110 (Connection timed out)) 08.49.49 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 08.50.15 Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 09.27.45 # New commit by 03amiconn (r21141): Use bit-doubled mask everywhere in mono bitmap drawing. ~2% speedup, and smaller. 09.38.31 *** Saving seen data "./dancer.seen" 09.44.40 # is the sorting order in the third parties forum screwed? 09.45.13 # looks like its going by first post date instead of last post date 10.11.42 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 10.13.03 Join ender` [0] (i=krneki@foo.eternallybored.org) 10.18.54 Join stoffel [0] (n=sfr@p57B4F74F.dip.t-dialin.net) 10.22.11 Join flydutch [0] (n=flydutch@host100-164-dynamic.8-87-r.retail.telecomitalia.it) 10.22.43 Quit kperri ("http://www.mibbit.com ajax IRC Client") 10.23.32 Part BabaChoowa 10.24.31 Quit BHSPitLappy (Remote closed the connection) 10.44.04 Join PaulJam [0] (i=PaulJam_@vpn-3004.gwdg.de) 10.53.14 Join tvelocity [0] (n=tony@194.219.254.2) 11.02.12 Quit intrados (Read error: 104 (Connection reset by peer)) 11.04.55 Quit fyrestorm (Read error: 104 (Connection reset by peer)) 11.07.39 Join merbanan [0] (n=banan@c-83-233-163-22.cust.bredband2.com) 11.10.18 Join robin0800 [0] (n=robin080@general-ld-216.t-mobile.co.uk) 11.13.42 Quit robin0800 (Client Quit) 11.14.02 Join robin0800 [0] (n=robin080@general-ld-216.t-mobile.co.uk) 11.15.17 Join fyrestorm [0] (n=nnscript@cpe-24-90-81-178.nyc.res.rr.com) 11.18.20 Quit planetbeing ("leaving") 11.28.47 Join Makuseru [0] (n=max@163.106.40.24.aeneasdsl.com) 11.29.19 Quit flydutch (Read error: 104 (Connection reset by peer)) 11.30.05 Nick J-23 is now known as wioska_troglodyt (n=zelazko@unix.net.pl) 11.30.16 Nick wioska_troglodyt is now known as J-23 (n=zelazko@unix.net.pl) 11.38.35 *** Saving seen data "./dancer.seen" 12.00.00 Quit merbanan (Read error: 60 (Operation timed out)) 12.09.01 Quit bmbl ("Woah!") 12.14.51 Quit __lifeless (Remote closed the connection) 12.15.07 Join __lifeless [0] (n=lifeless@188.16.69.44) 12.16.55 Quit timc (Connection timed out) 12.19.36 Join timc [0] (n=aoeu@119.109.110.143) 12.22.15 # amiconn: it's not a struct. i'm looking at a hash for album titles, and it has a word-at-a-time optimization. unless a packed struct along the lines of struct unalignedwordarry { uint32_t words[0] } would work. 12.25.19 Join _lifeless [0] (n=lifeless@188.16.103.246) 12.35.46 Join PaulJam_ [0] (i=PaulJam_@vpn-3016.gwdg.de) 12.39.15 Quit __lifeless (Read error: 110 (Connection timed out)) 12.46.12 Quit PaulJam (Read error: 113 (No route to host)) 12.47.18 Join robin0800_ [0] (n=robin080@general-ld-216.t-mobile.co.uk) 12.54.46 Join freeworldstat [0] (n=david@c-69-245-18-76.hsd1.tn.comcast.net) 12.55.59 Part freeworldstat 13.00.21 # Maybe logf-over-HID would be useful 13.02.18 # can you enable the hid without going into disk mode? 13.03.40 # HID is always enabled during connection on players that support it. Currently you only get button handling in a full connection that includes storage, but that's not a fundamental issue 13.05.39 # i imagine it will be fixed soon 13.06.19 Quit ender` (Read error: 104 (Connection reset by peer)) 13.08.09 # it's not a bug, so it can't be fixed 13.08.33 # at some point there will certainly be more flexibility though 13.09.01 Join Lear [0] (i=chatzill@rockbox/developer/lear) 13.09.08 # ah 13.09.11 Quit robin0800 (Read error: 110 (Connection timed out)) 13.09.25 # i couldn't work out how the debug hid entries were supposed to work if it was only enabled in disk mode :) 13.11.28 Quit rethgir (Read error: 110 (Connection timed out)) 13.14.19 Quit Makuseru (Read error: 104 (Connection reset by peer)) 13.17.11 Quit robin0800_ (Remote closed the connection) 13.17.36 Join robin0800_ [0] (n=robin080@general-ld-216.t-mobile.co.uk) 13.21.15 Quit _lifeless (Remote closed the connection) 13.21.31 Join _lifeless [0] (n=lifeless@188.16.102.197) 13.26.37 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 13.28.40 Quit fyrestorm (Read error: 104 (Connection reset by peer)) 13.29.11 Quit stoffel (Read error: 113 (No route to host)) 13.30.42 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 13.34.29 Join ender` [0] (i=krneki@foo.eternallybored.org) 13.35.25 Quit gevaerts (Nick collision from services.) 13.35.34 Quit Lear ("ChatZilla 0.9.84 [Firefox 3.5pre/20090529044053]") 13.35.34 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 13.38.38 *** Saving seen data "./dancer.seen" 13.39.32 # hm... i'm storing the strings myself, i could just force the alignment. 13.42.40 Quit _lifeless (Read error: 110 (Connection timed out)) 13.44.16 Quit perrikwp (Read error: 104 (Connection reset by peer)) 13.44.29 Join stoffel [0] (n=sfr@p57B4F74F.dip.t-dialin.net) 13.44.34 Quit saratoga ("http://www.mibbit.com ajax IRC Client") 13.47.58 Join PaulJam [0] (i=PaulJam_@vpn-3040.gwdg.de) 13.53.01 Quit PaulJam_ (Read error: 104 (Connection reset by peer)) 14.01.45 # is there anyway to set a different color for the statusbar in the wps screen than the menu? 14.04.41 Join _lifeless [0] (n=lifeless@188.16.108.236) 14.05.08 # Mikachu: you could try to "rebuild" the statusbar in the WPS with your desired colour. 14.05.17 # that is what i wanted to avoid, yes 14.17.02 # might be worthwhile to have an example on the wiki for the statusbar as WPS ;) 14.23.43 # JdGordon: Figured it out myself - thanks. 14.32.38 # * Mikachu cheated; http://git.mika.l3ib.org/?p=rockbox-svn.git;a=commitdiff;h=f5218d5b6a 14.36.57 Join fyrestorm [0] (n=nnscript@cpe-24-90-81-178.nyc.res.rr.com) 14.56.41 Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) 14.59.25 Join Xerion_ [0] (i=xerion@82-170-197-160.ip.telfort.nl) 15.01.20 Join _Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) 15.01.52 # Getting this error when I'm trying to build for the GoGear HDD6330 as a separate target: http://lambdacalculus379.pastebin.com/m38a4b6e5 15.03.14 Join _Xerion_ [0] (i=xerion@82-170-197-160.ip.telfort.nl) 15.03.14 *** Alert Mode level 1 15.03.14 DBUG Enqueued KICK Xerion 15.03.14 DBUG Enqueued KICK Xerion_ 15.03.14 *** Alert Mode level 2 15.03.14 DBUG Enqueued KICK _Xerion 15.03.14 DBUG Enqueued KICK _Xerion_ 15.03.14 *** Alert Mode level 3 15.05.46 Quit Xerion_ (Read error: 60 (Operation timed out)) 15.05.53 # LambdaCalculus37: How have you defined CONFIG_KEYPAD ? 15.08.41 # linuxstb: Let me check; where would I define it? 15.09.16 # In your config-targetname.h file 15.10.16 Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 15.13.15 *** Alert Mode OFF 15.14.52 Quit Xerion (Connection timed out) 15.14.52 Nick _Xerion_ is now known as Xerion (i=xerion@82-170-197-160.ip.telfort.nl) 15.14.52 DBUG Enqueued KICK Xerion 15.17.17 # linuxstb: I do have it defined, as CONFIG_HDD6330_KEYPAD. 15.18.01 # So it's a different keypad to the HDD1630? 15.20.21 Quit _Xerion (Read error: 110 (Connection timed out)) 15.21.05 # linuxstb: It is a different keypad, but currently there doesn't seem to be a driver for it. What's there is just a re-use of the HDD1630 keypad. 15.21.48 # Then you need to take care of button mappings - debug_menu.c is the first (search for CONFIG_KEYPAD) 15.23.05 # linuxstb: Ahh, found it. Thanks! 15.23.20 Ctcp Ignored 5 channel CTCP requests in 11 minutes and 38 seconds at the last flood 15.23.20 # * LambdaCalculus37 adds PHILIPS_HDD6330_PAD 15.23.41 Join ved_ [0] (n=ved2@137-mi2-1.acn.waw.pl) 15.23.41 Quit vedlith (Read error: 54 (Connection reset by peer)) 15.24.43 # linuxstb: Great success. :) 15.25.56 # Snag #2: http://lambdacalculus379.pastebin.com/m65292fdd 15.27.04 # Looks like the same thing... 15.27.35 Join cool_walking_ [0] (n=anthony@203.161.101.209.static.amnet.net.au) 15.27.42 Quit Xerion (Read error: 60 (Operation timed out)) 15.28.52 # linuxstb: I'm on it. 15.33.46 Join mishu [0] (n=5679d00f@gateway/web/cgi-irc/labb.contactor.se/x-daf80452e28f90d7) 15.34.03 # hi to all 15.34.23 # i have a problem with my sansa 15.34.30 # ok? 15.34.34 # some help 15.34.37 # ?? 15.34.48 # Maybe, what's your problem? 15.35.23 # on my screen appear 15.35.26 # Load main image failed Switch to Recovery mode 15.35.45 # what shoud i do? 15.35.57 # What did you do? 15.36.17 # my brother has performed a format 15.36.21 # (I think it's bricked or something, but Im not sure) 15.36.23 # from xp pro 15.37.11 # I bricked my sansa some days ago and successfully unbricked it 15.37.12 # i searched all over the net and forums 15.37.16 # It was cool :) 15.37.28 # no success 15.38.03 # it is a sansa e280 8g 15.38.05 # linuxstb: I disabled the USB stack for the time being. It builds now. 15.38.26 # Bah, spoke too soon. :/ 15.38.39 *** Saving seen data "./dancer.seen" 15.39.20 # mishu: I used this guide on my Sansa e250 some days ago: http://fixmysansa.blogspot.com/ 15.39.55 # i tried some softwares but .. no luck 15.40.00 # let's see 15.40.02 # :) 15.40.34 # LambdaCalculus37: You shouldn't have needed to do that - just add definitions for the USB buttons in firmware/export/usb.h 15.40.37 # e200tool is alphasoftware, but it worked for me 15.40.45 # from windows dosen't work? 15.41.28 # I don't know, I don't run windows 15.41.35 # Etu: It's not really "alpha", just something designed for low-level hacking - not general users. 15.41.39 # linuxstb: Okay. 15.41.46 # please escuse my english 15.41.58 # linuxstb: The text told me so. 15.42.20 # mishu: With a lot of effort I think it can be made to work in Windows, but it's far easier in Linux or OS X. 15.43.34 # mishu: The first part in the guide I sent you tells you how to make a liveCD to run it from 15.43.43 # oke 15.43.48 # i will try it 15.44.00 # Good Luck :) 15.44.12 # i make this thing in windows 15.44.21 # thx 15.44.22 # no luck 15.45.39 # it work's from centos live cd? 15.45.47 # centos 5.2 15.47.23 # I think so 15.47.36 # what linux system isn't so important 15.47.42 # I did it from gentoo 15.47.48 # oke 15.50.53 # Etu: what is e200tool and sansa.fmt? 15.51.23 # the rest of files i have them 15.52.42 Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-55c62a984dbea704) 15.59.34 # mishu: "e200tool" is the e200tool program itself. "sansa.fmt" can be any file - the content isn't important, it just needs to have that name. 16.01.38 Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) 16.05.13 Quit robin0800_ (Remote closed the connection) 16.05.37 Join robin0800_ [0] (n=robin080@general-ld-216.t-mobile.co.uk) 16.07.59 Join Rawkins [0] (n=52e74d63@gateway/web/cgi-irc/labb.contactor.se/x-c6a76436b3bdc06c) 16.08.03 Join flydutch [0] (n=flydutch@host46-210-dynamic.15-87-r.retail.telecomitalia.it) 16.08.31 Join kugel [0] (n=kugel@rockbox/developer/kugel) 16.09.07 Join Moi123 [0] (n=Moi123@slo68-1-82-231-77-99.fbx.proxad.net) 16.09.17 # Hi everybody 16.09.29 # Etu: i see it, sorry 16.09.42 # * kugel is going to commit the pictureflow-start-playback patch 16.09.49 # I wanted to know, if it's possible to install Rockbox on a 4th generation iPod nano (chromatic) ? 16.10.21 # no 16.10.34 # Oh :( 16.10.36 # Ok ! 16.10.55 # And something is under developpement to support this iPod or it's just impossible ? 16.11.06 # (sorry for my English, I'm french) 16.11.54 # It's been impossible so far... 16.11.56 Quit LambdaCalculus37 ("Fwump") 16.12.23 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 16.13.02 Quit Rawkins ("CGI:IRC (Ping timeout)") 16.13.16 # Ok 16.13.19 # thanks all 16.13.33 # It's the same for iPodLinux I presume ? 16.15.00 # yes 16.15.06 # don't you think if they had it working, rockbox would too? 16.15.50 Join petur [50] (n=petur@rockbox/developer/petur) 16.16.13 Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) 16.17.34 Join gregzx [0] (n=chatzill@dsa64.neoplus.adsl.tpnet.pl) 16.27.04 Quit robin0800_ (Remote closed the connection) 16.27.45 Quit mishu ("CGI:IRC") 16.27.57 Join mishu [0] (n=5679d00f@gateway/web/cgi-irc/labb.contactor.se/x-b39363b0e2147acf) 16.28.33 # kugel: What exactly are you planning on committing? Wasn't there objections to committing some parts of that patch? 16.28.57 # only the playback starting part 16.29.14 # there was objections to the database integration part 16.33.37 # New commit by 03kugel (r21142): playlist start can only have 1 return value (0), so make it return nothing. 16.33.40 Quit antitrons (Read error: 104 (Connection reset by peer)) 16.33.54 Join antil33t [0] (n=Mudkips@119.224.12.185) 16.38.27 Quit Thundercloud (Remote closed the connection) 16.40.28 # New commit by 03kugel (r21143): Commit the first part of FS#10263: Starting playback from within pictureflow, by creating a playlist from the tracklist and playing it. The database ... 16.42.32 Join lyngaas [0] (n=staale@19.81-167-149.customer.lyse.net) 16.43.06 *** Alert Mode level 1 16.43.06 # New commit by 03kugel (r21144): Bump plugin api version. 16.53.07 *** Alert Mode OFF 17.03.02 # I was also under the impression that there was no agreement yet on using pictureflow to start playback 17.04.12 # I don't see why it shouldn't. I agree about not integrating it too much before it's more or less complete, but what's wrong with starting playback? 17.06.55 # I didn't see any discussion about it 17.07.59 # bertrik: You disagree that pictureflow should start playback? 17.08.09 # New commit by 03kugel (r21145): Attach the playback control menu to pictureflow's main menu. 17.08.10 # no 17.09.15 # bertrik: Then what do you think needs discussing? I'm not sure if anyone has disagreed with the idea of that feature. 17.11.12 # ok, I'm not against the feature, but I just remember stuff like this being discussed before being committed, now it seems it's the other way around 17.12.29 Join kkurbjun [0] (n=kkurbjun@rockbox/developer/kkurbjun) 17.13.11 # we discussed yesterday a bit, where no explicit objections against the playback feature were made (Llorean even explicitely said he isn't against it) 17.13.12 # I think there's been some discussion about how to integrate it in the core, but I haven't really been paying attention. There's also a tendancy for -community to host discussions nowadays... :( 17.13.34 # I don't see why a much-asked-for addition to a plugin needs much discussion 17.13.57 # there was no discussion in -community about it (not when I was there at least) 17.14.30 Join robin0800 [0] (n=robin080@general-kt-199.t-mobile.co.uk) 17.15.05 # evil %BR% in MajorChanges :( 17.15.08 # i think that it's the general direction of pf and the database UI that should be discussed so we can agree how pf should be integrated in the database browser. (since it seems everybody want's to be) 17.15.44 # sure 17.16.08 # integration of plugins into the core is always controversial and needs discussion 17.16.20 # kugel, I don't disagree with the new feature, but I can't follow your reasoning that a much-asked-for-addition to a plugin should not need discussion 17.17.32 # why do you think it needs discussion? 17.18.57 # bertrik: The objection wasn't to having it start playback (from me at least) but rather from having it presented as part of the database while still missing a lot of functionality 17.19.43 # ok, I see 17.20.06 # linuxstb: The current status of the plugin is that it can start playback, but it can't do just about everything else. I'm all for including it, but I think it should be a demo, and not part of the database list, until it can at least do the Playlist-related context menu stuff, and let you resume/stop/manipulate playback via the normal buttons that work in list contexts. 17.20.22 # Unhelpful: What's the fastest speed pf could autoscroll without showing empty slides? 17.21.20 # kugel: that obviously depends on how the scheduler handles the cache thread, and on how responsive storage is. 17.21.35 # Llorean: it can also control playback via the plugin's playback control menu. And going directly to the wps is just a keymap issue (I've implemented directly from plugin to the wps) 17.21.42 Join preglow [0] (i=thomj@rockbox/developer/preglow) 17.22.31 # kugel: That still leaves playlisting, and if you can do it via the plugin's playback menu shouldn't using the normal keys for it also just be a keymap issue? 17.23.09 # you can't control playback in the list either (except for stopping) 17.23.12 Join shadoxx [0] (n=witherb@MW1-DSL-74-215-1-115.fuse.net) 17.23.24 # kugel: On the Gigabeat S you can skip forward and back 17.23.31 # And on the Gigabeat F and S you can adjust volume 17.23.49 # well, I think it should be possible to do that in pf 17.24.35 # it's "just" a list too, so all core list keymaps should be possible to implement in pf 17.24.45 # That's more or less what I expected. 17.25.08 # That's why the main issue I've talked about is the playlisting one. 17.26.33 # also, if we want pf as a valuable alternative, we should reconsider the backlight settings and perma-boosts it uses 17.27.09 # I think perma-boost is okay, but it should follow the core backlight settings. 17.27.20 # kugel: why don't i try a patch for CONTEXT_CUSTOM, and see if rebasing on CONTEXT_TREE works... 17.27.40 # :? 17.28.29 # kugel: to get those other key mappings. even if it means some reworking of the existing PF contexts. 17.29.09 # I didn't understand your sentence 17.29.11 Quit mishu ("CGI:IRC (Ping timeout)") 17.30.02 # kugel: i'm going to try the changes i mentioned last night to make it possible to chain to CONTEXT_TREE from get_custom_action, and see just how badly doing so breaks things :) 17.30.20 Join cmwslw [0] (n=cmwslw@c-98-249-113-152.hsd1.tn.comcast.net) 17.30.21 Join mishu [0] (n=5679d00f@gateway/web/cgi-irc/labb.contactor.se/x-b6c92abcd71bb35e) 17.30.27 # that would be nice 17.31.17 Quit cmwslw (Client Quit) 17.31.25 Join cmwslw [0] (n=cmwslw@c-98-249-113-152.hsd1.tn.comcast.net) 17.31.25 Quit mishu (Client Quit) 17.36.28 Join Lear [0] (i=chatzill@rockbox/developer/lear) 17.37.24 # kugel: one thing I wonder is what the plans are for the pictureflow plugin. E.g. is it planned for it to become a full replacement for the current database? 17.38.40 *** Saving seen data "./dancer.seen" 17.39.08 # bertrik: The idea is for it to have limited uses within the current database, I believe 17.39.47 # Initially, just an option to view all albums via cover, rather than simply as text, but (hopefully) later to be extended so it can be used in place of the "Album" filter anywhere albums are listed, just as an alternative within tagnavi. 17.40.47 # bertrik: surely not a replacement, but hopefully a usable alternative 17.41.59 # pf is pretty useless if you don't have albumart in the first place :) 17.43.19 # * Unhelpful thinks an "alternative" is a much better idea, though including it in the standard tagnavi as "covers" without removing "albums" seems reasonable. 17.43.26 # * Llorean would very much like the pictureflow work end result be several interesting database visualization and custom filter plugins. 17.43.45 # kugel: try this: http://pastie.org/495713 17.43.48 # But that still requires the not-insignificant step of actually being able to use plugins as filters. 17.44.49 # ok cool, like allowing capable targets to start pictureflow on power-on and have basic playback capabilities from it 17.45.29 # i'm not really sure what to do on M3, since CONTEXT_TREE falls through to CONTEXT_STD (without any remote buttons :/) 17.45.46 # In thread.c, there's a "#elif CPU_MIPS == 32" line. Shouldn't that be "defined(CPU_MIPS)" like everywhere else CPU_MIPS is used? 17.45.54 # bertrik: "capable targets" are all bitmap ones :) 17.47.38 # M3 might just need the ok/cancel/context/scroll remote maps pulled into pictureflow's buttons context 17.49.16 Join kugel_ [0] (n=kugel@e178107063.adsl.alicedsl.de) 17.49.30 Join mcuelenaere [0] (n=mcuelena@vpnb095.ugent.be) 17.49.32 Quit kugel (Nick collision from services.) 17.49.40 Nick kugel_ is now known as kugel (n=kugel@e178107063.adsl.alicedsl.de) 17.49.46 # Lear: I think I did that for being future-compatible with 64-bit MIPS processors 17.51.08 # mcuelenaere: I see. I get warnings from GCC 4.4 about it though. :) 17.51.23 # hmm what warnings? 17.52.16 # About comparing 32 against something that isn't defined. 17.52.40 # add a defined(CPU_MIPS) && first :) 17.53.14 # n1s: Will that work (from your email)? I'm not too familiar with shell type things, but shouldn't it be something like &> because they're stderr? 17.53.48 # Hm, there seem to be a flac problem. test_codec fails after the flac tracks... 17.54.49 # Llorean: ah, you're right, wasn't thinking clearly 17.55.29 # New commit by 03learman (r21146): Fix typo. Not sure how it will affect targets with that CPU though... 17.55.51 # Lear: probably related to the issue I was talking about yesterday 17.56.26 # kugel: Yep. 17.57.16 # Lear: testing gcc4.4? 17.58.06 Join bluebrother [0] (n=Dom@f053155148.adsl.alicedsl.de) 17.58.07 # n1s: Yes, thought I should give it a go. Builds without much trouble and generates smaller code. That's all I know for now. 17.58.41 # Lear: How's code speed? 17.58.49 # Unhelpful: seems to work 17.59.04 # Lear: which targets are you testing? 17.59.23 # Llorean: Haven't gotten that far yet. n1s: ARM only (for now at least). 17.59.24 # Lear: I think we already tested gcc4.4 18.00.06 # some guy in the ml tested a gcc 4.4 rc for ar i think, he got slightly worse speeds overall iirc 18.00.08 # one guy on the -dev ml tested 4.4-RCsomething, and I myself tested the last 4.3.x release 18.00.43 # This is the release version though. 18.01.07 # kugel: if existing controls work on supported target sims, then it probably doesn't break anything. 18.01.09 # n1s: I think the glibc might actually be the problem? We know dreppers view on ARM 18.01.17 # yes, it may indeed behave differently 18.01.52 # kugel: wasn't eglibc created for that? 18.02.03 # I think so, yes. 18.02.19 # * n1s is confused 18.02.28 # I didn't compile gcc though with eglibc 18.03.22 # Unhelpful: my e200 seems fine 18.03.29 # but we don't use libc 18.03.46 # n1s: we do when compiling gcc 18.04.01 # I think 18.04.13 # Vorbis didn't work at least... 18.04.46 # kugel: then i guess you can try hooking up the extra button maps you wanted to something :) 18.04.48 # kugel: yes (basically *everything* on a unix system uses it) but why should it affect the performance of the output of gcc? 18.05.21 # if the cross-compiler is broken, the generated code might be broken too 18.05.48 # I accept that a newer compiler might be *a bit* slower, but not that e.g. several codecs don't work at all 18.06.08 # We've seen cross-compilers known to work elsewhere build completely nonworking (or very strangely working) versions of Rockbox before. 18.06.42 # I dont' understand what you mean or why some obscure glibc bug should cause this? 18.07.03 # * Llorean was chiming in without context, feel free to ignore me if that info makes no sense here. 18.07.05 # kugel: i used distribution-built cross-compilers for a bit... found out when i tried to build for archos that they couldn't build a text_editor that would fit in the plugin buffer. 18.08.07 # n1s: we build the cross-compiler using the stock glibc. It's known that Drepper gives a shit on e.g. ARM, so it's not unlikely that the ARM-cross-compiler is bugged 18.08.30 # * n1s had to patch quite a few places to get a working rockbox out of gcc 4.3 but i dont' really blame the compiler for that 18.09.03 # * Mikachu still uses his super old gcc 4.0.3 arm gcc 18.09.06 Join toffe82 [0] (n=chatzill@ppp-69-238-95-241.dsl.frs2ca.pacbell.net) 18.09.10 # to my knowledge glibc should not be effecting the cross compiled code at all, if there was a bug in glibc you would see some more serious problem on your system 18.09.13 # kugel: but your cross compiler uses your native glibc 18.09.21 # n1s, were those bugs in rockbox? 18.09.30 # rockbox doesn't use it at all on target 18.09.39 # bertrik: well, sort of 18.10.16 # kkurbjun: If that's true then I'm sorry 18.10.44 Join saratoga [0] (n=41becb3b@gateway/web/cgi-irc/labb.contactor.se/x-e8db48cbc0ebee74) 18.10.44 Quit saratoga (Client Quit) 18.10.47 # the problem with using newer compilers to my knowledge with code breaking is how it approaches optimizations and how much you used compiler specific flags to get things working (code size can also be a problem as unhelpful mentioned) 18.10.52 Join saratogahome [0] (n=41becb3b@gateway/web/cgi-irc/labb.contactor.se/x-dc2d34c6711792f0) 18.11.05 # bertrik: mainly that newer gcc can decide to delete asm statements that it deems to have no side effect if they are not volatile and a subtle change in linker script syntax 18.11.37 # lack of volatile keywords in rockbox sounds like a potiential bug on our part 18.11.40 # code size was a problem too and a real bug in the m68k compiler that's fixed in 4.4 18.12.58 # and a few of the issues we ran into when switching to Os on coldfire with gcc 3.4 (deletion of delay loops in c basically) 18.13.13 # Unhelpful: are you going to try a few sims? 18.13.20 # hmm, dirskip crashes the h100 reproducably :( 18.13.24 # saratogahome: yes, i meant to commit that patch but never got around to it 18.13.44 # maybe i should do that now :) 18.14.11 # saratogahome: depends, non-volatile asm that gcc is able to understand can give it a chance to optimize. 18.15.23 # thats true, but i think the parts getting optimized away are probably delay loops and such, since the list of output registers for real functions should prevent this problem anyway i think 18.15.26 # I wouldn't be surprised if gcc recognizes dozens of consecutive nosp and optimises them away 18.15.44 # n1s, ok, sounds like a good thing to fix (even if it doesn't occur with the current gcc) 18.15.47 # though i admit i have no idea how gcc works 18.16.09 # Unhelpful: ACTION_TREE_STOP works too 18.16.25 # kugel: OK? 18.16.46 # was that a question? 18.17.16 # i tried on my beast, and it works ok... beast uses the windows button for the PF menu, though, and that's the return to WPS button :/ 18.17.58 # kugel: i wasn't sure what you wanted ACTION_TREE_STOP for... as a stop playback hotkey? 18.18.14 # yes 18.18.23 # meh, I can't really get a grip on reliable i2c communication on as3525 when the CPU clock is much higher than the i2c clock. I wish I could find more detailed info about it than what is available in the as3525 datasheet (maybe have a look in the linux kernel) 18.18.52 # i think i stole that button on more than a few targets for the "quit PF" mapping. 18.19.10 # but using cancel or the menu to exit would be acceptable, i suppose 18.19.26 # if we're going to chain lists, then the ACTION_STD_CANCEL button shold handle pf quit IMO 18.19.35 # which is e.g. |<< on e200 18.20.10 Quit killan (Read error: 54 (Connection reset by peer)) 18.20.16 Join killan [0] (n=nnscript@c-5ef170d5.06-397-67626721.cust.bredbandsbolaget.se) 18.20.49 # kugel: ACTION_STD_CANCEL already *does* quit PF if in the album list. but the dedicated quit mapping quits from tracklist as well. 18.21.02 Part cmwslw ("Ex-Chat") 18.21.06 # yep, I noticed that 18.23.58 # several devs still thought a dedicated quit wasn't entirely redundant... but i'd say it's fair to replace dedicated quit with a playback control. you get to edit the manual, too, though ;) 18.25.14 Quit petur ("Zzzzzz") 18.26.01 # Unhelpful: no, AlexP does :P 18.27.19 # I don't think it's entirely reduntant either, just depends on whether the target has enough buttons 18.27.21 Quit n1s (Read error: 104 (Connection reset by peer)) 18.27.29 Join n1s [0] (n=n1s@rockbox/developer/n1s) 18.28.36 # Unhelpful: that giant CONFIG_KEYPAD is just for excluding scrollwheel targets, isn't it? 18.30.08 # kugel: no, that's a large set of targets with the same button mappings. 18.30.54 Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-a8cfbd0776e1fc21) 18.31.11 # basically everything other than ondio and m3 - m3 because it should be using the remote buttons, ondio because it needs to explicitly mask some CONTEXT_STD mappings. 18.32.06 # I'm thinking the ondio,m3,mrobe500 cases should be moved up, and the giant construct be replaced with #elif !defined(HAVE_SCROLLWHEEL) 18.32.15 # s/should/could/ 18.32.38 # that should work fine. 18.33.25 # New commit by 03nls (r21147): Old patch from FS#7832: Sprinkle 'volatile' in the various inline assembler statements, needed for the driver to work when compiled with newer gcc, ... 18.38.22 # Unhelpful: does that look good? http://pastie.org/495739 18.38.52 # I also put the ondio within the the !HAVE_SCROLLWHEEL, keeping the extra definitions 18.40.39 # kugel: perhaps the album list context itself should be in !HAVE_SCROLLWHEEL? 18.41.17 # that should work 18.41.30 # but that needs another #ifdef at get_action, then 18.42.51 # i still think it's a good idea, seeing as it reduces static data and code on scrollwheel targets. 18.44.30 Quit shadoxx (Read error: 113 (No route to host)) 18.44.57 Quit cool_walking_ (Remote closed the connection) 18.45.03 Join webguest00 [0] (n=c3893ab3@gateway/web/cgi-irc/labb.contactor.se/x-eaf7ac5b7474c404) 18.45.45 Join jmillikin [0] (n=jmilliki@c-24-130-227-85.hsd1.ca.comcast.net) 18.46.07 # if we're killing the dedicated quit button, you know, that actually means that we don't need to use custom actions at all on scrollwheel targets, and that there's only one custom action context on other targets. 18.47.28 # right, I actually deleted the PF_QUIT for e200 18.47.39 Quit webguest00 (Client Quit) 18.48.24 # the touchscreen stuff can probably go? 18.50.41 # though, scrollwheel targets might still want a dedicated quit button 18.50.57 # or cobo 18.50.58 Join archivator [0] (n=archivat@77.70.28.57) 18.50.59 # combo* 18.51.02 # what's wrong with cancel and the menu quit option? 18.51.39 # I'm getting Connection refused on git.rockbox.org, is the address changed or did you drop git support entirely? 18.52.29 # git's been down a few days now, i'm not sure what's happening with it. git-svn still works fine. 18.53.05 Join PaulJam_ [0] (i=PaulJam_@vpn-3016.gwdg.de) 18.53.16 # Hmm, I never set up git-svn, guess now is as good a time as any :) 18.54.45 # Unhelpful: c200 still works, I'm going to commit the cleanup 18.55.06 Join PaulJam__ [0] (i=PaulJam_@vpn-3022.gwdg.de) 18.55.11 # kugel: i'm going to go over the supported-target keymaps and check for conflicts, and then go ahead and commit the rebase of the PF contexts from CONTEXT_STD to CONTEXT_TREE... it looks like it should be safe, though. 18.55.19 Quit mcuelenaere () 18.55.29 Join VytenisS [0] (n=bxcracer@78-56-8-132.static.zebra.lt) 18.55.38 Quit Chex (Read error: 110 (Connection timed out)) 18.55.49 Quit MarcGuay (Read error: 110 (Connection timed out)) 18.56.57 # New commit by 03kugel (r21148): Restructure/cleanup the album list buttom mapping, removing it entirely for scrollwheel. No functional change (scrollwheel didn't use it before, ... 18.58.15 Quit PaulJam (Read error: 60 (Operation timed out)) 18.59.54 # kugel: hi, nice work on pictureflow :) 19.02.35 # Nico_P: Thanks :) 19.03.03 Quit PaulJam_ (Read error: 113 (No route to host)) 19.05.34 Quit toffe82 (Read error: 110 (Connection timed out)) 19.09.24 # kugel: 8799.... 19.13.11 # yay, I think I have a workaround for the i2c problem on ams sansas with high cpu clock 19.14.54 Join PaulJam [0] (i=PaulJam_@vpn-3003.gwdg.de) 19.14.59 Join MarcGuay [0] (n=chatzill@ip216-239-78-116.vif.net) 19.17.09 # hm, there's a problem with the playlist created by pf 19.17.42 Quit robin0800 (Remote closed the connection) 19.18.18 # what's the problem? 19.19.04 Quit Moi123 (Read error: 113 (No route to host)) 19.19.18 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 19.19.21 Join FlynDice [0] (n=FlynDice@65.89.200.2) 19.20.06 Quit PaulJam__ (Read error: 60 (Operation timed out)) 19.21.31 Join toffe82 [0] (n=chatzill@ppp-69-238-95-241.dsl.frs2ca.pacbell.net) 19.24.43 # bertrik: I've been playing with i2c delays a lot lately with varying results, I see you think you found a workaround? 19.26.03 Join PaulJam_ [0] (i=PaulJam_@vpn-3021.gwdg.de) 19.26.20 # FlynDice, yes, I'm testing it more thoroughly now. The essence is that instead of waiting for the busy bit, we wait for the DACNT register to become 0. The DACNT contains the number of pending i2c bytes to be read/written. 19.27.28 # Unhelpful: you can't resume it after reboot 19.27.50 # kugel: i wonder why? 19.28.09 # so I do 19.29.11 Join SirFunk__ [0] (n=Sir@208-15-25-145.netsync.net) 19.29.33 Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]") 19.29.34 Join dmb [0] (n=dmb@unaffiliated/dmb) 19.30.14 # Llorean: usb charge patch? in for 3.3 or not? and the thread sorting in the 3rd party forum is on first post not last post... 19.30.41 Join __lifeless [0] (n=lifeless@188.16.108.236) 19.31.16 # bertrik: Great!! Any chance this would benefit the radio function on the e200's that fails when the mmu is enabled or is that going to be separate? 19.31.25 # JdGordon: We either need the charge patch, or USB should still be disabled for the iPods (but can be disabled for the Sansas I believe). I think the charge patch should at least be committed one way or another as long as someone's willing to sign off on "it shouldn't damage any hardware, we think" 19.31.30 Join SeaWeed [0] (n=SeaWeed@c-67-187-7-172.hsd1.va.comcast.net) 19.31.38 # AFAIK it's the same basic thing the H300 does, but I'm hardly in a position to be too knowledgeable about it. 19.32.08 # kugel: a lot of targets seem to do funky redefines of left/right with various release or repeat flags. i think rebasing on CONTEXT_TREE will have to mean moving the masking items for those to all targets. 19.32.11 # get artound to testig it? 19.32.27 # JdGordon: Oh, thought you meant a different patch. 19.32.39 # If you mean *your* patch, I didn't notice you'd updated a new one since I said it didn't compile? 19.32.45 Quit PaulJam (Read error: 113 (No route to host)) 19.32.51 # oh, i didnt remember that 19.32.54 # ill fix it up now 19.32.56 # The LANG issue? 19.33.02 # Unhelpful: why? you're overriding their left/right definitions? 19.33.10 # Anyway, as long as your patch does what it says it does (and it seems like it ought to), I'm for it being included. 19.33.13 # I think we should enable USB on the sansas, leave it disabled on ipods, and think about the others 19.33.18 # JdGordon: Which third party forum? 19.33.29 # gevaerts: Any opinions on the charging patch? 19.33.35 # 3rd party tools or whatevr its called 19.33.45 # I'd *really* like it if we could enable it on the iPods as well, but charging is necessary. 19.34.00 # JdGordon: Other utilities, I see 19.34.28 # kugel: for example, several map BUTTON_LEFT|BUTTON_REL, BUTTON_LEFT to cancel, with the result that the button down might start PF scrolling, but the button up would quit PF. 19.35.06 # Unhelpful: pf should map this to scroll anyway, imo 19.35.18 # JdGordon: Forum should be fixed, assuming I'm looking at the right one. Check for me? 19.35.40 # yep, cheers 19.35.54 Quit archivator () 19.36.14 Join froggyman [0] (n=47ba0b80@gateway/web/cgi-irc/labb.contactor.se/x-d6ef4e952052f391) 19.36.15 # kugel: the problem is that these defines are not universally using the same preconditions, and that they can change based on a setting. safest bet is for the PF scroll button to be down without precondition, and repeat without precondition to repeat, and to mask any with-precondition mappings. 19.36.30 # FlynDice, you mean the radio issue on e200v2s? that is completely separate from ascodec i2c 19.36.41 Join gregzx [0] (n=chatzill@dsa64.neoplus.adsl.tpnet.pl) 19.37.01 # Ybertrik 19.37.21 # bertrik: yes I see that now :( 19.38.01 # Llorean: I'll try to find some time to integrate that properly with the usb code. I have no opinion on whether it's correct though 19.38.03 # that can probably be fixed by using a larger/smarter delay loop in fm_delay in fmradio-i2c-as3525 19.38.40 # gevaerts: Well, as long as it's what the H300 does (and we offer the same option name for USB charging, whatever it's called) I think it should be okay to include it. 19.38.43 *** Saving seen data "./dancer.seen" 19.38.52 # soap offered some concerns as to whether it could cause damage to accessories. 19.39.40 # * soap offered his interpretation of what dreamlayers appeared to be warning against. ;) 19.40.13 Quit SirFunk_ (Read error: 110 (Connection timed out)) 19.40.21 # Llorean: H300-style is the minimum, which should be easy. Integrating it into proper USB handling should be reasonably easy as well. Evaluating whether things will blow up is outside my area of expertise 19.40.49 # I use the patch everyday. What sort of potential problems should I be looking for? 19.40.52 # gevaerts: Well, the OF for the H300 didn't warn things might blow 19.41.06 # (outside hubs catching on fire, dogs and cats living together...) 19.41.14 # One would expect iRiver to at least provide warnings to help prevent lawsuits for blown hubs 19.41.16 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 19.41.39 # soap: From what I was told (I think by LinusN) worst case should just be if the port can't provide enough power, USB won't connect period. 19.42.53 # Let me reread the comments (as I don't grok the code), but I thought the issue was with the patch that 500 was being taken, without request, so the connection might very well happen "under false pretenses". 19.43.11 # Llorean: updated 19.44.45 Quit Lear ("ChatZilla 0.9.84 [Firefox 3.5pre/20090529044053]") 19.46.25 Quit _lifeless (Read error: 113 (No route to host)) 19.46.54 Quit stoffel (Read error: 113 (No route to host)) 19.47.59 # New commit by 03unhelpful (r21149): Replace use of CONTEXT_CUSTOM by get_custom_action with new CONTEXT_PLUGIN, to prevent conflicts with core contexts using CONTEXT_CUSTOM, and use ... 19.48.21 # New commit by 03bertrik (r21150): Use I2C2_DACNT register (number of pending i2c bytes to read/write) to determine if an ascodec i2c transfer is done. This should fix i2c problems with ... 19.50.36 Quit antil33t (Read error: 104 (Connection reset by peer)) 19.50.37 # kugel: now you can go mapping tree-context playback controls and such :) 19.50.50 # ah wonderful :) 19.50.51 Join antil33t [0] (n=Mudkips@119.224.12.185) 19.52.29 # in the long run, i'd say remove pf_context_buttons entirely, except on M3, where it can be a copy of the core remote standard context so that we get the right buttons for core cancel etc on remote 19.59.05 # Unhelpful: got the playlist thing 20.02.20 # Hello, can anyone have a look at http://www.rockbox.org/tracker/task/10255 and commit if everything is ok ? 20.03.24 # bertrik: is that commit mostly for the radio or do other things use i2c? 20.04.03 # saratogahome, this commit was only for the i2c towards the "ascodec" part in the as3525 20.04.24 # the radio in the ams targets uses i2c-over-GPIO 20.05.06 # ah 20.05.26 # bertrik: any chance it fixes existing prolems? 20.05.39 # the as3525 does have another i2c bus, but so far it appears it's not used for anything 20.06.33 # kugel, maybe, at least it should take away another unsure variable from getting the MMU to work 20.08.44 # making mmu build with it right now... 20.09.37 # the latest patch from funman on FS#10048 gives me a black screen 20.14.54 # Well, similar problems with playback still but it does solve the problem we were using the i2c_busy delays for. 20.16.21 Quit SirFunk__ (Connection timed out) 20.17.15 # my gut feeling is there's still something wrong with pcm on ams sansa, maybe a problem when both the sd and pcm want to DMA for example 20.17.32 Join SirFunk [0] (n=Sir@208-15-25-145.netsync.net) 20.18.11 # 2 different channels though, should that be a problem? 20.18.47 # * JdGordon requests testers for FS#10198 so it can hopefully go in before the freeze... 20.25.15 # JdGordon: It doesn't seem that major, why not just commit it? 20.25.34 # because i might have stuffed it... 20.27.37 # we'll find out if you commit it! 20.28.08 # Have a little confidence in yourself 20.28.32 # It's a relatively simple patch, and it works for you, right? 20.28.55 # You can get a little widespread testing in the few days before freeze, that's much better! :-P 20.29.38 # you're doing reverse pycology on me arnt you!!... 20.30.40 # Seriously though, I read it, it's not terribly complex. If you stuffed it up it's most likely just gonna be a typo you can fix in a moment or two anyway, right? 20.32.19 # FlynDice, you are testing on a sansa fuze right, I can't get my clip's screen to show with funman's latest patch 20.33.42 # bertrik: e280V2 I'm runing part funman part my code right now, I'll try and post a patch later tonight. 20.34.59 Quit SeaWeed (Remote closed the connection) 20.44.20 # Llorean: what I think we should do long-term (for 3.3 if possible, but there's not that much time...) is to (a) properly negotiate with the host, and (b) have a "charge over USB" setting which specifies whether we should try to get 100mA or 500mA in that negotiation. 20.45.02 # That would mean that if you have charge over usb enabled, and the host says no, the player doesn't connect, but it can't blow up stuff either 20.45.25 # At the same time, it provides a workaround if you have one of those 100mA only ports 20.45.37 # gevaerts: I *think* that's more or less the H300's behaviour 20.45.52 # It has a charge setting, and I think the hardware itself handles the negotiation because it's hardware USB. But I'm not sure. 20.46.13 # sounds plausible anyway 20.46.45 # Either way, I'd like to see USB and I think it should be enabled for everything that won't have the battery die while it's connected 20.47.43 # I'll do my best to have something during the next week. We can then decide later on if we find the speed acceptable 20.48.11 # I don't think speed should be a major concern. 20.48.14 Quit Nico_P (Remote closed the connection) 20.49.11 # I don't think we're slower than disk mode, so that shouldn't be a problem 20.50.00 # * Llorean nods 20.50.45 # we're still be a bit slower on e200, but that's compensated by this database update thing 20.51.03 # 4.2MB/s vs 4.8MB/s in my measurements 20.51.55 # It's fine by me as long as dual boot remains an option, and data won't be lost/corrupted from battery failures. :-P 20.52.22 Join webguest36 [0] (n=47f0bd95@gateway/web/cgi-irc/labb.contactor.se/x-8e2b6b7f5f6c3ea2) 20.53.02 # do we know if charging over USB works properly on other PP502x devices? 20.53.08 Quit webguest36 (Client Quit) 20.53.32 # i.e. H10 and mr100 20.54.10 Join chandoo [0] (n=chandoo@ool-4353b978.dyn.optonline.net) 20.54.49 # I haven't heard reports either way on those. 20.55.21 # I imagine it probably doesn't. It had to be setup on the Sansa too, that just happens to have been done before we had USB IIRC. 20.57.00 Join matsl_ [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 20.57.20 Quit kugel (Read error: 110 (Connection timed out)) 20.57.54 # so what do we do with those? 20.58.17 # H10 users aren't very happy about their disk mode right now 20.58.41 # Well, in my opinion slow/fast charging doesn't matter as much as "will the battery die in long transfers" 20.59.06 # So I guess we need a test. A long transfer and a check to see if the battery is lower or higher afterward. 20.59.36 # As long as the battery isn't going to die mid-transfer, I think it's okay to enable USB disk mode with a warning that if they want to charge they should follow some alternative procedure. 20.59.50 Join kugel [0] (n=kugel@rockbox/developer/kugel) 21.00.26 # that also depends a lot on battery state 21.00.58 # State how? Shouldn't it simply be "if the current used to run the device is less than the current received over USB, the battery won't drain"? 21.02.00 # well, does the charger get its allowed 100mA when not configured, and is 100mA enough to keep the battery topped up? 21.02.21 # A lot depends on exact charger design and setup I think, and I know nearly nothing about that 21.02.22 Quit froggyman ("CGI:IRC (EOF)") 21.02.41 # Ah. 21.02.47 # * gevaerts thinks he should build a measurement USB cable 21.02.50 # Well, either way they need investigated so we at least know the current behaviour. 21.02.53 Join froggyman [0] (n=47ba0b80@gateway/web/cgi-irc/labb.contactor.se/x-dced5d940b6f07d2) 21.03.42 Join PaulJam [0] (i=PaulJam_@vpn-3020.gwdg.de) 21.03.42 # I can test H10/5 as soon as I get this cable cut correctly so I can measure current, which should be a lot more reliable than seeing if it goes up a bit 21.04.33 # Don't H10s have user-replaceable batteries? 21.05.00 # I may be able to test mr100 as well, but it needs an OF restore first as it currently doesn't boot at all. It also *may* have a bad disk... 21.05.13 # the h10 battery is replaceable, yes 21.06.53 # Would it be possible to see if USB power is enough to run it without the battery present, or is it unable to run without the battery period? 21.07.15 # I should test that 21.09.48 # I can't boot rockbox yet (empty battery), but the ROM usb mode aparently keeps working if I remove the battery 21.10.22 Quit PaulJam_ (Read error: 60 (Operation timed out)) 21.11.24 Quit saratogahome ("CGI:IRC (EOF)") 21.17.09 Join _lifeless [0] (n=lifeless@188.16.108.236) 21.17.18 Quit bmbl ("Woah!") 21.17.20 Join merbanan [0] (n=banan@c-83-233-163-22.cust.bredband2.com) 21.17.37 # heh, the bot is nice 21.17.48 # no message means my commit probably didn't come through 21.19.37 # New commit by 03kugel (r21151): A bit more work on playback controlling pictureflow: ... 21.21.45 # gevaerts: I think it's safe to have any button work, since otherwise what button is harmless changes from screen to screen 21.22.31 # kugel, are you still seeing some kind of positive effect on your player from the DBOP FIFO patch? 21.22.38 # For example, holding "left" is extremely harmless in the root menu, while holding "menu" or "select" (traditional buttons for USB avoidance on many of our players) leaves you in other menus, one of which (the quickscreen) often leaves people with changed settings the first time they try to leave it and press the wrong thing 21.22.44 # Llorean: usually the chosen button is menu or equivalent. That should be harmless on any screen 21.22.49 # bertrik: not anymore, after I did svn up it went away 21.22.59 # ah, yes. The quickscreen one... 21.23.03 Quit __lifeless (Read error: 60 (Operation timed out)) 21.23.09 # and I don't have a record of the local changes anymore :/ 21.23.15 # gevaerts: I suspect every time someone changes file view from "supported" to "playlists" or "folders" it's because they tried to leave the quickscreen by pressing menu again. 21.23.18 # Well, menu is always harmless on its own :) 21.23.39 # but yes, you have a point there 21.24.23 # Perhaps the manual entry should include the suggestion "In most screens, the safest button to hold while inserting USB will be select. This will open the context menu, but perform no further actions while you hold it." or something similar 21.24.46 # yes. That should avoid most problems 21.24.48 # kugel, ok, too bad :P I find it a bit surprising that it doesn't seem to help at all after all 21.25.02 # me too 21.25.10 # svn is slower than what I had with your path 21.25.36 # I think I'll look into it further once we have stable high speed with MMU on ams sansas 21.26.13 # I was assuming that the FIFO is always enabled, but maybe it needs to be explicitly enabled somehow 21.33.22 Join PaulJam_ [0] (i=PaulJam_@vpn-3020.gwdg.de) 21.38.46 *** Saving seen data "./dancer.seen" 21.39.51 # I see we don't use the timer in the as3525 yet, right? 21.40.29 Join pp0000 [0] (n=621cc6c1@gateway/web/cgi-irc/labb.contactor.se/x-0ed9c2a9d9614cfc) 21.40.40 # bertrik: we do 21.41.00 # at least 1, I'm not entirely sure if the 2nd one is setup 21.41.00 # * gevaerts doesn't entirely understand the beast USB ccharge logic 21.41.56 Quit pp0000 (Client Quit) 21.41.59 Join pp0000 [0] (n=621cc6c1@gateway/web/cgi-irc/labb.contactor.se/x-9f5334e65f9883d3) 21.42.04 # I thought it handled non-PC (i.e. pure charger) connections, but I can't see that in the code 21.43.09 # kugel, ah ok I see, it's handled in kernel-as3525.c 21.43.46 # and that's kind of essential on sansa and ipod, where there are no other chargers usually 21.44.49 # that's just vbus detect though? 21.45.24 # gevaerts: Pure chargers used to be handled on iPods at least. 21.45.39 # tmzt: not really. To do it properly (which you really can't, but never mind) it's vbus and no data 21.46.31 # but how do you know how much current you can draw with a pure charger? 21.46.40 # is the only safe value 100mA? 21.46.40 # Llorean: they are handled in the sense that it doesn't go into any sort of USB mode, but the 100mA vs 500mA bit doesn't handle it 21.46.59 Quit pp0000 ("CGI:IRC (Ping timeout)") 21.47.00 # Pure chargers shouldn't need to attempt to draw any specific amount, right? 21.47.19 # tmzt: the only safe value is 100mA, yes. Being strict about that isn't going to gain any friends though 21.47.25 # I know that iPod chargers actually provide 1000mA 21.47.47 # (an hour late) but even if we were 1/4th the USB speed on Sansa - the fact Rockbox can see a SDHC card (and the OF can't) should be compelling enough, no? 21.47.48 # kugel, I was thinking about using the timer as an microsecond or 0.1 microsecond free running counter to create small delays, so we rather arbitrary NOP loops 21.47.51 Quit PaulJam (Read error: 113 (No route to host)) 21.48.21 # bertrik: I think we can do that 21.48.22 # gevaerts: I have a usb charger capability on my laptop, even in suspend or poweroff (depending on bios setting) 21.48.40 # that's done on several other targets too 21.48.41 # gevaerts: I have no idea what the max current it can handle is though 21.48.56 # soap: well, at 1/4th the speed I wouldn't be sure, but we're at 85% on write and 140% on read, so that's fine 21.50.40 # tmzt, Llorean: I suspect that it's safe to assume that if we detect vbus and we don't detect any bus activity for a few seconds, it's a charger and you can grab whatever you need 21.51.05 # So the logic we need is this "wait a few seconds and see if anything happens" 21.51.19 # bertrik: IIRC, TIMER2 is used for the tick tasks, and TIMER1 somewhere in timer.c, but I don't know whether it's actually used there 21.51.44 # What /would/ the consequences be grabbing too much? My brain isn't set up for thinking about the 400ma difference as dangerous. 21.51.45 # Anyway, if we can control precisely, I wouldn't go over 500mA in any case. I'm not sure if we can do that however 21.53.11 # soap: what if you have 4 ipods on a bus powered hub? That's suddenly 1600mA too much, and that is the case the USB limits are guarding against 21.55.31 Join saratoga [0] (i=9803c6dd@rockbox/developer/saratoga) 21.55.46 # The problem we have left (after implementing everything as well as we can, which I'll try next week) is that you either don't support "USB" chargers, or you assume that anything that doesn't talk on the bus is a charger. That assumption will be false every now and then, as in tmzt's BIOS setting case, but I'd expect those cases to be able to handle 500mA anyway 21.56.36 # its surprising theres no way to detect a device thats failing to deliever enough current 21.56.46 # you would think that would be a neccesary safety precaution 21.57.00 # gevaerts: does the spec say what to do if a device tries to draw too much? 21.57.31 # n1s: yes. You're allowed to cut it off. Unfortunately the electronics needed are not mandatory 21.58.04 # ah, that's unfortunate 21.58.48 Quit kugel ("exit(0);") 22.00.23 Join {phoenix} [0] (n=dirk@p54B4644C.dip.t-dialin.net) 22.01.41 Join PaulJam [0] (i=PaulJam_@vpn-3043.gwdg.de) 22.02.57 Quit jhulst ("Read error: EOF") 22.04.37 # kugel: Do you know where I can check if the backlight is on for the AMSSansas? I tried to use "bool lcd_active(void)" but that doesn't seem to work. 22.05.28 # kugel, indeed TIMER1 is used in timer.c as a general timer and TIMER2 in kernel-as3525 to do call_tick_tasks ... 22.06.33 Quit PaulJam_ (Read error: 60 (Operation timed out)) 22.08.39 # hm, this timer stuff is confusing 22.12.21 Join Mac [0] (n=c3cc377a@gateway/web/cgi-irc/labb.contactor.se/x-98f9f03d33730df7) 22.14.09 Quit Mac (Client Quit) 22.15.31 Quit martian67 (Remote closed the connection) 22.16.02 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 22.18.42 Quit FlynDice (Remote closed the connection) 22.21.13 Join PaulJam_ [0] (i=PaulJam_@vpn-3021.gwdg.de) 22.21.42 Join BdN3504 [0] (n=55b22781@gateway/web/cgi-irc/labb.contactor.se/x-1fb9f38f008168b0) 22.23.06 Quit Bagder (Read error: 110 (Connection timed out)) 22.23.36 # who comitted the new pictureflow playback capability? 22.24.49 # Whoever it was: I want to thank you! This is one of the sexiest features of Rockbox! 22.26.49 # kugel 22.27.14 # Vielen Dank Thomas du bist der Beste! 22.28.09 Quit PaulJam (Read error: 60 (Operation timed out)) 22.31.12 Quit BdN3504 ("CGI:IRC (EOF)") 22.35.49 Quit thegeek (Read error: 104 (Connection reset by peer)) 22.36.00 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 22.36.04 # * bluebrother doesn't understand why a feature can be sexy at all 22.46.31 Join beta_ [0] (n=beta@d24-36-124-26.home1.cgocable.net) 23.05.43 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 23.11.38 Quit moos ("Rockbox rules the DAP world") 23.17.20 Join lee321987 [0] (n=chatzill@node127.35.251.72.1dial.com) 23.17.36 Quit lee321987 (Client Quit) 23.25.54 Nick ved_ is now known as vedlith (n=ved2@137-mi2-1.acn.waw.pl) 23.26.01 Join safetydan [0] (n=deverton@rockbox/developer/safetydan) 23.28.48 Join wincent [0] (n=wincent@host-091-097-048-211.ewe-ip-backbone.de) 23.33.45 Quit bluebrother (Read error: 113 (No route to host)) 23.38.48 *** Saving seen data "./dancer.seen" 23.45.17 Join Res1 [0] (n=Res@user-0c6s6hp.cable.mindspring.com) 23.45.34 Quit n1s ("Lämnar") 23.46.08 # hello; does anyone know if there are windows drivers for rockbox available? When I plug in the USB cable to my ipod and hold the menu button, windows IDs my ipod as a rockbox device; is there anything special about this? 23.47.09 # what version of rockbox do you have? 23.48.35 # the latest stable version (3.2-090323) 23.49.37 # i'm not sure, but i don't think that version supports disk mode from rockbox 23.54.52 # Mikachu: i'm pretty sure it doesn't, the portalplayer USB driver still had some issues that were not worked out yet, so it was disabled for the release. 23.55.42 # it seems to work okay for me with the dailies, but maybe i'm slowly corrupting my disk 23.56.03 # hm 23.56.03 # OK 23.56.13 # Res1: for now just use the disk mode or apple firmware i guess 23.56.17 # Mikachu: i believe that issue has since been resolved. 23.56.28 # Well it is good to know this is in development, but I've never needed to use it I suppose 23.56.32 # yeah, from what i understand the only issue is charging 23.56.51 # Res1: if you install a daily, you'll be able to control your pc audio player with your ipod ;) 23.56.57 # BTW, I just tested the recording feature, way cool :) 23.57.13 # * Mikachu doesn't have a dock or line-in cable 23.57.37 # I am using a 4g U2 ipod, I can use my headphones as a mic. 23.58.51 # nanos can't