--- Log for 01.04.110 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 3 days and 5 hours ago 00.00.06 Join Strife89 [0] (~michael@adsl-154-2-49.mcn.bellsouth.net) 00.02.17 Quit evilnick (Quit: Page closed) 00.03.26 Join webguest77 [0] (~5edf559a@giant.haxx.se) 00.04.10 Quit webguest77 (Client Quit) 00.07.13 Quit hd (Quit: Ω) 00.09.41 Join jd [0] (~jd@bas1-montreal33-1279639532.dsl.bell.ca) 00.09.41 Quit jd (Changing host) 00.09.41 Join jd [0] (~jd@Wikipedia/HellDragon) 00.15.41 # I'd like to drop another keymap bomb in here. I noticed that there are optional key assignments for all sorts of things: playlist, track info, pitchscreen, and those are just for the WPS. I originally planned to replace the view playlist key with an assignable key but that's not going to be practical across all targets. 00.16.43 # So what about just leaving all the optional code in and just taking over a likely keypress? Would there be much heartburn if we lose the track info or pitchscreen keys but gain an assignable key? 00.16.53 Join komputes [0] (~komputes@ubuntu/member/komputes) 00.17.58 # What do you mean? I don't understand "lose the pitchscreen keys" 00.20.23 # Well, they'll still be in the code, but on some targets maybe they'll lose the dedicated keypress due to other keymap conflicts. It'll always be available in the context menu. 00.20.52 Join qfr [0] (void@unaffiliated/yw) 00.21.14 # I am running Rockbox on a Sansa Fuze v1 and I was just showing the Doom game on it to my flatmate - doesn't it have any sound? 00.21.52 # On many targets (can't say for yours) it has sound effects but no music. 00.21.52 # The normal playback of audio files works fine but the game doesn't appear to emit any sounds :( 00.21.58 # Hmmm 00.25.26 Join hd [0] (jd@bas1-montreal33-1279639532.dsl.bell.ca) 00.25.26 Quit hd (Changing host) 00.25.26 Join hd [0] (jd@Wikipedia/HellDragon) 00.26.46 Quit flydutch (Quit: /* empty */) 00.28.23 Quit jd (Ping timeout: 246 seconds) 00.28.53 # aha, the proper bootcharting patch reveals that i'm an idiot and check_bootfile isn't even called on ipod 00.29.06 # the 1.5 seconds it takes when cabbie is seleected is indeed loading the wps 00.29.09 # which isn't a huge surprise ;) 00.29.16 # the font still takes 6 seconds 00.29.23 # That seems crazy 00.29.46 # What does it do for all that time? 00.29.49 # Llorean: apparently it's always taken that long, or at least for a long time 00.29.59 # i went back a couple of thousand revisions to before sbs/multifont/etc 00.30.08 # Did you compare 3.4 and 3.5? 00.30.13 # and it still takes 6 seconds to load the font 00.30.20 # not yet 00.30.22 Join hebz0rl [0] (~hebz0rl@dslb-088-065-049-146.pools.arcor-ip.net) 00.30.36 # Someone in a recent forum post complained that 3.5 booted slower than 3.4 on his... It was either an h100 or h300 00.30.41 # yup 00.30.42 # I remember thinking "so it's not just ARM" 00.30.59 # Didn't expect it would be, or anything. 00.32.34 # Torne: How far have you gone back? 00.33.07 # but yeah, with compeltely default settings, having already boted once so glyphcache exists, boot goes like this: font_load starts at 0.56 seconds, then finishes at 6.66 seconds 00.33.21 # loading icons takes 150ms 00.33.41 Quit geertvdijk (Remote host closed the connection) 00.33.43 # init_tagcache takes 400ms even thugh it's not initialised and isn't laoding to ram 00.33.57 # and then loading the wps takes 1.5s 00.34.01 # total time 9.22s 00.34.23 # so yeah. 2/3 of boot is font_load, 1/6 is wps loading 00.34.40 # (to get to root_menu()) 00.34.46 # Maybe something related to glyphcache broke? 00.34.59 # gevaerts: it's approx. equal time whether the glyph cache exists or not 00.35.17 Quit hd (Quit: Ω) 00.35.22 # exactly. If it doesn't check properly anymore, this is what you'd get 00.35.28 # ..heh 00.35.45 # uhm 00.35.48 # the home page 00.35.52 # has been hacked again 00.35.56 # this time, the word smurf 00.36.00 # is everywhere.. 00.36.03 Join jd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca) 00.36.04 Quit jd (Changing host) 00.36.04 Join jd [0] (~jd@Wikipedia/HellDragon) 00.36.29 # hahaha 00.36.39 # wodz: (for the logs) I started on the SVG for the mpio hd200 manual, i put it on flyspray later today for review 00.36.52 # Smurfa Fuze it's an amazing name :D 00.37.15 # oh well... it's the first of april already? :D 00.37.21 # Torne: What's the earliest revision you tested? 00.37.51 # linuxstb: 23257 00.37.56 # the one immediately before SBS was committed 00.38.34 # so, after 3.4 00.38.37 Quit Geert_van_Dijk (Quit: ChatZilla 0.9.86 [Firefox 3.6.2/20100316074819]) 00.39.14 # Torne: Hmm... font.c at least wasn't changed between 18609 (Sept 2008) and 23742 00.39.55 # yeah, i noticed 00.40.07 # I guess 18608 would be worth testing... 00.40.10 # nothing significant seems to have changed about fonts, other than multifont :) 00.40.44 # i'll try various points 00.41.05 # it'll be slightly inconvenient to go back past the logf rework and keep bootchart though :) 00.41.30 # hm, actually if it's just fonts i can do taht only 00.41.56 Join funman [0] (~fun@rockbox/developer/funman) 00.42.08 # diacritic support was added not too long ago, wasn't it? 00.42.23 # pixelma: Yes, but Torne has checked before that. 00.42.23 # that was after the revision i tested also, i think 00.42.36 # ok 00.42.41 # i'll just go back a bunch and do a two line change to just time font_load 00.42.48 # and see if i can find anything ;) 00.43.00 # Haha I should write an NFO viewer for Rockbox 00.43.07 # hello-smurf 00.43.10 # Torne: Or did the font itself change? 00.43.19 # linuxstb: hm, possible i guess 00.43.32 # linuxstb: i'd like someoen to try on a different player entirely, also 00.43.49 # and jsut see if the boot times are proportional 00.44.13 # * linuxstb looks around for a charged target... 00.45.53 Quit perfectdrug (Ping timeout: 246 seconds) 00.45.59 # * Torne grabs the bzr bisect plugin :) 00.46.03 # * pixelma can't see one joined 00.48.16 Join perfectdrug [0] (~marko@p5B0EC16F.dip.t-dialin.net) 00.48.38 Quit bertrik (Quit: De groeten) 00.49.44 # Torne: Do you have a patch somewhere? 00.49.51 # qfr: i have sound in doom on fuzev1, perhaps it depends of the WAD file ? 00.49.59 Quit jgarvey (Quit: Leaving) 00.50.06 # I haven't installed any WAD file D: 00.50.12 # Just the normal setup 00.50.14 # FreeDoom 00.50.17 # Or whatever it is called 00.50.54 # looks like you need to enable sound in the menu: it's off by default 00.53.28 # Oh. 00.54.21 Part captainkewlllll 00.58.59 # Torne: Font loading can't always have been that slow. Archos recorder (with an 11MHz CPU!) used to boot in 5..6 seconds 00.59.21 # amiconn: yeah, i'm bisecting now 00.59.24 # That's from power-on to menu (with rockbox in flash but obviously loading fonts and stuff from disk) 00.59.30 # but it's slow ;) 00.59.51 # I'm quite sure this slowdown happened less than half a year ago 01.00.35 *** Saving seen data "./dancer.seen" 01.00.48 # I don't use any bitmaps in my wps'es but I always use an on-disk font (usually rockfont on small displays and some nimbus variant on the larger ones) 01.01.00 # Ah funman, you were right! Fabulous! 01.01.08 Quit Stephen__ (Quit: Leaving) 01.01.20 # amiconn: well it only takes 1.5s to load the cabbiev2 wps for me 01.01.32 # 6s for the font cabbiev2 uses :( 01.05.48 # smurfy night to everyone! 01.05.51 Quit Luca_S (Quit: CGI:IRC) 01.07.33 # ...and rbutil now supports parallel voicing ... a good night for voice users, methinks :) 01.07.37 Quit archivator (Quit: Leaving) 01.07.45 Join Darkknight512 [0] (~Darkknigh@CPE00212968356c-CM00186845dd46.cpe.net.cable.rogers.com) 01.08.54 Quit dfkt (Read error: Connection reset by peer) 01.09.51 Quit ender` (Quit: A computer program will always do what you tell it to, and seldom what you want it to.) 01.10.07 Join crculver [0] (~crculver@59.178.196.106) 01.10.58 # I reformatted my ipod's vfat file system after disk corruption. Although I can connect in disk mode and reinstall rockbox, the rb bootloader now tells me "No partition found" 01.11.31 # good news: doom runs fine on Clip+ ! 01.12.09 # find the blue door? 01.12.11 # yeah 01.12.12 # crculver: what dd you frmat it with, and wich ipod is it? 01.12.19 Nick Schmo is now known as Schmogel (~Miranda@p3EE21EF1.dip0.t-ipconnect.de) 01.12.53 # Torne, It's an iPod Video, 30gb, I used mkdosfs to format it. 01.13.10 Join smurf [0] (~58d9759a@gateway/web/freenode/x-dmlphevqxmueiugy) 01.13.10 # you need to explicitly specify the sector size 01.13.37 # the 5.5G disks are supposed to be formatted with 2048 byte sectors 01.13.56 # add -S 2048 01.14.04 Quit jd (Quit: Ω) 01.14.31 # Torne, Thanks. Too bad I'll have to copy all my music all over again. :-\ 01.16.12 Quit komputes (Ping timeout: 268 seconds) 01.16.31 Join Tomis [0] (~Tomis@70.134.100.153) 01.16.32 # amiconn: 18086 also takes 6 seconds to load the font 01.17.18 Join jd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca) 01.17.18 Quit jd (Changing host) 01.17.18 Join jd [0] (~jd@Wikipedia/HellDragon) 01.17.49 # Torne, I continue to get the error. 01.18.37 # crculver: try with mformat from mtools 01.18.46 # http://www.rockbox.org/wiki/IpodManualRestore 01.18.57 # this is how peopel ahve restored without itunes in the apst 01.19.11 # easier option, if you have any access to a windows machine: use itunes :) 01.19.51 # amiconn: so tha's well past the last 6 months.. 01.20.06 # amiconn: that's the same 18 months ago 01.20.25 # 22 months even 01.21.50 # amiconn: maybe other people are not having this issue :) 01.22.17 # oh wait, i forgot about the glyphcache 01.23.20 Quit Llorean (Quit: Leaving.) 01.23.35 Join evilnick [0] (~48e51a1b@rockbox/staff/evilnick) 01.27.38 Part toffe82 01.28.25 # The iPod Video is 5.5G? 01.28.34 # All right, I'm ready to commit the hotkey patch. Any last words? 01.29.13 # crculver: some of them are 01.29.22 Join merbanan [0] (~banan@c-62-220-165-110.cust.bredband2.com) 01.29.28 # crculver: the 30GB model it's ahrd to tell without checking the serial number 01.29.46 # Blue_Dude: your keymaps look a bit hmm... too simple 01.29.58 Join komputes [0] (~komputes@ubuntu/member/komputes) 01.30.02 # ? 01.30.03 # love the new site design 01.30.30 # amiconn: yeah, i've gone righ back to 15756 and it still takes 6 seconds to load a font, and that was before cabbie was even *included* 01.30.51 # pixelma: I didn't design the keymaps, just stole a key from another function. 01.30.55 # amiconn: so it looks like font loading *has* always been slow on ipod video 5.5g 01.31.10 # Blue_Dude: from what I remember about looking at it today in the morning. The playlist viewer shortcut also had the problem, I know 01.31.16 # amiconn: i can't go back much further or 5.5g won't even boot :) 01.32.06 # pixelma: Oh, I see. Yeah, I think all the keymaps need revisiting. A lot of the assignments are kind of random. DevCon topic, maybe? 01.32.13 # so i think it's safe to say that whatever slowdown other people are experiencing i'm not reproducing it here  01.33.43 # Blue_Dude: I don't mean randomness, I mean "unclean" implementation - many just assign a button combo without checking pre conditions so that you need to be pressing the two buttons *exactly* at the same time, especially if one or both keys are already assigned tto other functions 01.33.48 # Anyway, all I'm doing is stealing a key and the default is to duplicate the same function. The average user shouldn't notice any changes. I think we need to have the conversation about rethinking keymaps, but that's not what this patch is for. 01.34.25 # and it's not so easy to improve the keymaps 01.34.51 # pixelma: I entirely agree. Some top down rethinking is in order. 01.35.07 # But maybe not right this minute. :) 01.35.18 # I'm not so positive that this would help any 01.35.41 # No it won't. But it doesn't hurt anything either, which is something I tried hard to avoid. 01.36.08 # Blue_Dude: you didn't say something about the targets that don't have the playlist viewer shortcut at all... I don't expect tthat they'll get it, just making sure you are aware 01.36.14 # Maybe it'll prompt some skull work though. 01.36.56 # amiconn: does the Iaudio M3 also have retrictions in button combos? 01.37.01 # Yeah, I noticed, and those targets are switched off in their configs. They can be switched on after some keymap redesign. 01.37.04 # restrictions too 01.38.49 Join kugel [0] (~kugel@rockbox/developer/kugel) 01.38.53 # pixelma: I only switched on those targets that already had the VIEW_PLAYLIST key that also didn't conflict with any tree/list/standard keypresses. That left quite a few targets ready to go without further work, but a number need another look. 01.39.15 # pixelma: "just assign a button combo without checking pre conditions so that you need to be pressing the two buttons *exactly* at the same time" I'm not sure if this is true 01.39.24 # kugel: You magnificent bastard, I read your post! 01.39.34 # kugel: read on 01.39.53 # * Blue_Dude watched the intro to Patton recently. 01.40.33 # kugel: Still not sure what you meant though... 01.40.48 # what did I do? :( 01.40.56 # pixelma: ? 01.42.00 # pixelma: yes 01.42.50 # if the buttons (used on their own) already trigger an action, then you have to make sure that this one isn't already true before you can hold your button combo (hence pre conditions are needed) 01.42.52 # No button combos possible except with PLAY. But long Play is shutdown so it's not really useful. Applies to both main and remote. 01.43.06 # that was to kugel 01.43.11 # kugel: I'm referring to your comment on FS#11081. I did go back and remove the conditionals around wps_view_playlist, so it will compile all the time. That's to open up remapping possibilities without forgetting something important. 01.43.57 # wps_view_playlist? 01.44.15 # I really really doubt you'll find more targets with a spare button... the keymaps are already quite crammed 01.44.17 # pixelma: Yes, some keypresses need to have their pre-conditions explicitly defined, other than the all-too-common BUTTON_NONE. 01.44.45 # pixelma: Which is why I resorted to stealing an existing one. 01.45.06 # the last patch has "case ACTION_WPS_VIEW_PLAYLIST:" #ifdef'd. I suggested to remove the entire case and move the code (and the #ifdef) into "case ACTION_WPS_HOTKEY:" 01.45.15 # Shameless but effective! Especially when also defining the same behavior as the default. 01.45.36 # Torne: Now that *is* odd. It also means the behaviour you're observing is not the same as on other targets :\ 01.45.40 # well even that one wasn't easy... and maybe doesn't work everywhere (see the statements about the M3) 01.46.17 # kugel: I did take out the ifdefs, but I can't move the code to ACTION_WPS_HOTKEY. If I did, the key wouldn't be reassignable. You might not *always* want the hotkey to behave that way. 01.46.20 # effectively replacing the ACTION_WPS_PLAYLIST action with ACTION_WPS_HOTKEY, removing the need to put all the ifdefs in the target key files (since both actions are mutually exclusive) 01.46.20 # the playlist viewer shortcut key is one of the most recent additions 01.46.37 # Torne: Is that an 80GB G5.5 (precisely one with an MK8011GAH)? 01.46.40 # amiconn: yes 01.46.47 # Blue_Dude: I'm looking at your latest patch, I'm not sure what you're looking at :p 01.46.48 # in keymaps (except new ports) 01.47.02 # amiconn: er, no, 8010GAH 01.47.05 # kugel: I didn't upload the very latest. 01.47.06 # pixelma: that's not what you said 01.47.10 # * amiconn wonders whether the slow font loading might be due to the 1K sector handling 01.47.12 # But i will now. 01.47.22 # Blue_Dude: well you should if you want that my talk makes sense :) 01.47.23 # kugel: what? 01.47.43 # amiconn: also, re your comments eearlier about handling sector sizes better, i am aware of hte problems and i'm gonna experiment with it, i ahve this drive to test on. 01.47.51 # you said you need the precondition since otherwise the buttons all need to be pressed exactly at the same time 01.47.57 Quit perfectdrug (Ping timeout: 265 seconds) 01.48.08 # Seems like I need to test boot speed myself on various targets. I won't do that now though 01.48.08 # and explained later why 01.48.21 # amiconn: well, I'm going to post my bootcharting patch on FS in a sec 01.48.31 # amiconn: i want to put it in svn but the macro usage may be objectionable 01.48.42 # kugel: I didn't go into detail that much though but it was still in the same sentence 01.48.47 # pixelma: you said "especially" which sounds as an additional problem, not like an explaination 01.48.48 # +detail 01.49.14 # amiconn: it would probably make this easier, anyway, because it's easier to compare results this way :) 01.50.41 # kugel: OK, it's up. 01.51.41 # kugel: the more I work on it, the less the patch does to the existing code. Maybe that's a good sign. :) 01.52.42 # Blue_Dude: so, the playlist viewer is now accessed via onplay instead of directly returning VIEW_PLAYLIST from the wps? 01.53.04 # anyway, I'm not sure why ACTION_WPS_VIEW_PLAYLIST needs to stay in the keymap files now 01.53.17 # kugel: Yes, exactly. The hotkey execution doesn't go into the WPS code at all. 01.53.24 # amiconn: linuxstb: gevaerts: http://www.rockbox.org/tracker/task/11161 <- bootchart patch, finalised 01.53.36 # kugel: That's why I ifdef'd it out to begin with... 01.53.42 # anyone who has an opinion on use of weird macros, please have a look :0 01.53.54 # going to bed now tho. 01.54.32 # Blue_Dude: what happens if I #undef HAVE_HOTKEY? can I still access the playlist? 01.55.33 # kugel: You can always access it. But if HOTKEY is defined, it just won't have its own dedicated keypress. 01.55.46 # just a minor thing, I think it should have been HAVE_HOTKEY instead of just HOTKEY 01.56.04 # You can still get to it from the context menu for instance. 01.56.13 # Or the main menu, etc. 01.56.33 # I mean using the short cut that's in svn 01.56.44 # Hm. I can do a global search and replace on that. Not a bad idea. 01.56.56 Quit smurf (Quit: happy smurfing) 01.57.07 # kugel: ??? 01.57.29 # svn has a hotkey in svn that goes to the playlist viewer from the wps 01.58.01 # it looks like you remove it for the !defined(HOTKEY) variant 01.58.20 Join perfectdrug [0] (~marko@p5B0EC16F.dip.t-dialin.net) 01.58.54 # (I can imagine that instead of "(void)hotkey" "if (context == CONTEXT_WPS && hotkey) return ONPLAY_VIEW_PLAYLIST" would revive it 02.00.09 # kugel: I see what you're saying. No, I didn't take anything out. Where are you looking? 02.00.17 # kugel: the now hotkey replaces the playlist viewer shortcut - with the default being a shortcut to the playlist viewer 02.00.22 # Blue_Dude: still your patch 02.00.52 # the case ACTION_WPS_VIEW_PLAYLIST: is removed as far as I can see 02.01.22 # (as I suggested, but without ability to do what it does now without HOTKEY defined) 02.02.13 Quit z35 (Ping timeout: 252 seconds) 02.02.29 # ah, now... you're speaking about the targets that have the playlist viewer shortcut but don't have the hotkey because of conflicts in lists 02.02.47 # yep 02.03.14 # kugel: I originally defined that case out because it wasn't needed anymore - assuming that that key would always have been replaced. Since that may not be true, I'm leaving it in for now. 02.03.33 # why? 02.03.40 # kugel: but if the keypress isn't replaced, HOTKEY isn't defined. 02.03.47 # So there's no change. 02.04.06 # you again don't understand what I'm saying 02.04.26 # No, I guess not... :( 02.05.01 # ACTION_WPS_HOTKEY basically replaces ACTION_WPS_VIEW_PLAYLIST, so the ACTION_WPS_HOTKEY case should do what the ACTION_WPS_VIEW_PLAYLIST case does now, for targets that don't #define HOTKEY 02.07.12 # plus, because of that ACTION_WPS_VIEW_PLAYLIST isn't needed anymore in the keymap files 02.08.59 # kugel: I can do that, but the key label won't be very indicative for non-hotkey targets. Besides, I might try to steal another keypress other than VIEW_PLAYLIST on those targets and leave VIEW_PLAYLIST alone. 02.09.27 # but they are mutually exclusive? 02.09.31 # Adding the case won't hurt anything, but if the keymap is correctly setup, it won't ever fire either. 02.09.53 # That was the original plan, but it's not essential. 02.10.11 Quit perfectdrug (Ping timeout: 265 seconds) 02.10.21 # why should a target have the playlist key and the hotkey? 02.10.37 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 02.10.39 # that doesn't make sense since hotkey can do that, it is the default even 02.10.41 # Torne, Alright, that was a long process, but in the end it worked, I have rb back. Thanks for your help 02.10.44 # I could take over SHOW_TRACK_INFO or PITCHSCREEN or something else instead. 02.11.15 # In which case perhaps those could be the default behavior instead. 02.11.32 # or make it so that track info and pitchscreen can be put on the hotkey instead :) 02.12.05 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 02.12.54 # what you describe doesn't appear to be likely to happen, and we usually don't code for the future 02.14.14 # Which I did do... 02.14.38 Part crculver ("Leaving") 02.15.23 # the keymaps do have the hotkey and playlist key mutually exclusive (in your latest patch), and it's the same button for all targets. I don't see why to keep the playlist button 02.15.28 # So far, delete, view playlist, open with, show track info, pitchscreen, and insert playlist can all be assigned. 02.16.16 # They are only mutually exclusive for the targets that are ready to be switched on. They are not mutually exclusive by design. That was the original intention, but it's not strictly necessary. 02.17.05 # I can remove the conditional ifdefs from the keymaps. I just thought it would be easier to troubleshoot if I didn't though. 02.18.26 Join CaptainKewl [0] (jds@207-237-106-60.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 02.20.25 # I just thought of a reason to keep the define as HOTKEY instead of HAVE_HOTKEY: maybe the define itself can designate which key is being replaced. It would solve some problems. Have it be: #define HOTKEY PLAYLIST or #define HOTKEY TRACK for instance. 02.21.13 # CONFIG_HOTKEY then :) 02.21.44 Join z35 [0] (~z35@ool-18bd3f51.dyn.optonline.net) 02.22.23 # I think I didn't add the playlist viewer to all targets because of lacking buttons, some of them had a track info hotkey; I guess it would make sense to use that button instead then 02.22.25 # Hm, I could see that. 02.22.40 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 02.22.42 # but I don't think the defaults should differ across targets just because of that 02.23.16 # The conditional defines would go back in, and the default logic in hotkey.h would be a little more complex, but so be it. It works better. 02.23.58 # what conditional defines? 02.24.33 # kugel: That's an education and manual issue. In making it transparent, you're going to get some compromises somewhere. 02.24.42 # The ones in wps.c 02.24.51 # Around the case. 02.24.52 # I don't understand 02.25.11 # Which? :) 02.25.49 # I hope you're not trying to make the default conditional on what button you've stolen 02.26.39 # Well, yeah, that would be transparent, wouldn't it? Someone would miss that special button and complain and then where would we be? 02.27.00 # tell him to change the hotkey then 02.27.39 # we absolutely hate different defaults across targets, and "being transparent" is no justification 02.27.43 # Yah, I'm right there with you on that, but Joe User probably doesn't care. He wants it to work the same. 02.27.55 # We worked hard to make rockbox the same across so many targets 02.28.17 # Then the default ought to be "no hotkey set" and let the chips fall where they may. 02.28.35 # I don't see why 02.28.46 # And then I can get rid of hotkey.h too. 02.29.42 # There's no point in preassigning a key function if it duplicates another key, for instance. 02.29.51 Quit evilnick (Quit: Page closed) 02.30.00 # still better than doing nothing 02.30.42 # I chose view_playlist only because I wanted that key on the e200 target not because I liked the function. I never use it. 02.31.23 # I'd rather do something cool like launch the fireworks plugin. :) 02.31.34 # No I'm not going to do that. 02.31.48 # well, why not? :p 02.31.53 # Doom! 02.32.07 # Debug menu, something. 02.32.17 # test_codec. 02.32.19 # we could have a hotkey.rock (similar to the autorock.rock which is auto-launched on boot) 02.32.37 # I ain't gunna go there, no sirree. 02.35.05 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 02.36.43 # OK, so what ought the default be? Still view_playlist? 02.37.08 # I suppose, since that's the most-stolen button, isn't it? 02.37.35 # aren't it just 3-4 targets anyway where you steal another buttons? 02.39.33 # I haven't stolen *any* other buttons yet, just leaving the possibility to do so. 02.40.02 # so yes, let it be playlist 02.40.22 Quit merbanan (Ping timeout: 245 seconds) 02.42.59 # btw, I find it nice that you (accidentally) finished my initial patch (FS#9873) :) 02.43.10 # I didn't dare to commit the tree-part of it :p 02.44.04 # kugel: I just put this in wps.c around the view_playlist portion. Look right? #if !defined(CONFIG_HOTKEY) || (CONFIG_HOTKEY != PLAYLIST) 02.45.23 # * kugel wonders how's that supposed to work for other targets 02.45.31 # *new targets 02.45.45 # I don't see a point in #define CONFIG_HOTKEY XXX 02.46.27 # Hm. I was thinking conditional defaults but since we're abandoning that idea... 02.46.39 # Save a few bytes? :) 02.46.44 # OK, bad idea. 02.53.58 Quit komputes (Ping timeout: 258 seconds) 02.55.39 # Refresh my memory, enum don't cost anything if they're not referenced, correct? They don't have to be defined out? 02.57.13 # If a value is left in an enum, or even if an entire enum table is left in, it won't cost anything in bin size? 02.57.32 Join webguest76 [0] (~45448474@giant.haxx.se) 02.58.54 # Anyone? 02.59.15 Quit webguest76 (Client Quit) 03.00.36 *** Saving seen data "./dancer.seen" 03.00.59 # enum definitions don't cost anything right, just like struct definitions 03.01.32 # ok, thanks 03.01.39 # but they do represent a data type which of course costs memory if you alloc an "object" of that type 03.04.27 # My enums only assign values to labels. They don't have names. 03.04.59 # So I think it's OK to take the conditional ifdefs away. 03.09.38 Join hebz0rl_ [0] (~hebz0rl@dslb-088-065-056-058.pools.arcor-ip.net) 03.10.48 Join komputes [0] (~komputes@ubuntu/member/komputes) 03.13.10 Quit hebz0rl (Ping timeout: 252 seconds) 03.17.36 Quit Darkknight512 (Remote host closed the connection) 03.23.18 Quit hebz0rl_ (Quit: Ex-Chat) 03.25.46 Join n1s [0] (~n1s@rockbox/developer/n1s) 03.28.03 # Ah, embedded systems. Where people still care about their code (sure, it's because they have to, but still. It's nice.) 03.29.15 Quit Schmogel (Ping timeout: 264 seconds) 03.32.06 # OK, latest patch is at FS#11081. 03.32.33 # I'd like to commit this one. It's about as clean as it can be at this stage. 03.33.29 # Blue_Dude: some keymap files have still both? 03.33.45 # Yeah, the ones that need work. They're not active yet. 03.35.19 # Once the keymaps are fixed, the conditionals can come out. 03.35.58 # BTW, that patch has a bug in features.txt. I'm fixing it. 03.39.23 # All right, I'm off for an hour or so. Please take a look. I'll commit later tonight when I have time to handle any issues that come up. 03.40.03 Quit komputes (Ping timeout: 264 seconds) 03.42.16 # are there antialiased fonts for rb?? 03.43.05 # no 03.47.58 Join saratoga_lab [0] (~9803c20d@gateway/web/freenode/x-fbghvgjwklsvbywn) 03.49.42 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 03.52.12 Join anewuser [0] (anewuser@unaffiliated/anewuser) 04.00.49 Join TillW [0] (~Till@h145-net09.simres.netcampus.ca) 04.03.57 Join Barahir_ [0] (~jonathan@gssn-5f75522e.pool.mediaWays.net) 04.07.23 Quit Barahir (Ping timeout: 260 seconds) 04.08.18 # CGU_PROC is exactly the same in as3525v2 than in as3525 04.14.14 # so mp3@128kbps decodes at ~30MHz on clip+ 04.14.27 # does it look sane ? 04.14.37 # yes 04.15.27 # funman: I thought test_codec says we're slower? 04.16.11 # funman: i'd say not very sane 04.16.17 # kugel: yes because the CPU really runs at 120MHz (240/2) 04.16.29 # PP takes about 38MHz, and it has basically zero latency memory 04.16.49 # funman: did you clock it higher now? 04.17.04 Quit CaptainKewl (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) 04.17.21 Quit arjunvj3 (Remote host closed the connection) 04.17.40 # though i guess the ARM9E has a faster multiplier and faster load/store, maybe if the IRAM is also zero latency it could be really efficient 04.18.18 # kugel: trying to 04.18.28 # test_codec tells me "cannot create logfile" now ? 04.18.36 # ah, the 30MHz are at 120MHz? 04.18.50 # nope, i just divided the 59MHz test_codec previously told me 04.18.58 # ah 04.19.25 # with the IRAM running at 65MHz like on the AMSv1, I'd expect something more like 45MHz 04.19.35 # also the smurfed out front page is growing on me 04.20.50 # nvm i a new test_codec.rock in apps/ and an obsolete (wrt plugin API) in viewers/ 04.21.36 # funman: hmm kugel's fuzev1 benchmarks show mp3 being oddly fast on AMS, so maybe it is more reasonable 04.21.48 # saratoga_lab: do you test different bitrates? 04.22.02 # 128k and above are all nearly the same 04.22.12 # its only below that where decoding becomes simplier 04.22.35 # they're oddly fast? 04.22.39 # yeah 04.22.44 # way faster then I'd expect 04.22.51 # why? 04.23.06 # vorbis is way faster then mp3 on everything but AMS, where they're basically tied 04.23.54 # (ignoring dual core that is) 04.24.19 # well, vorbis/wma is rather slow on them 04.25.01 # on PP vorbis is 25MHz while MP3 is more like 38MHz, then on AMS vorbis and mp3 are both ~38MHz 04.25.42 # so mp3 stays the same but vorbis get ~50% slower 04.25.46 # funman: i love you! i'm so proud that you and whoever got fuze v2 rb'd! 04.25.47 # why is vorbis so much faster on pp? 04.26.27 # does your mdct get huge improvements simply by fast iram? 04.26.58 # even without the new mdct it was already much faster 04.27.14 # but i think the new mdct speed up the gigabeat F by a bunch too, and it is arm9 without IRAM 04.27.36 # but looking at decode time, samsa is 2x faster again 04.27.53 # 29.29MHz for mp3 04.28.17 # has anyone ever benched the D2? 04.28.24 # IIRC its arm9e like amsv2 04.28.37 # same cpu according to configure 04.29.03 # saratoga: can you explain why the MHz is lower for PP even though its decode time is 2x? 04.29.08 # mp3 does do a lot of single loads and stores because of how its filterbank works out 04.29.20 # kugel: much lower clock speed 04.29.28 # 80MHz vs. 250MHz on AMS 04.29.43 Quit planetbeing_ (Remote host closed the connection) 04.30.10 # 29.19MHz for 128bkps vorbis 04.30.19 # but, samsa clearly decodes the files twice as fast, so the MHz needed for realtime should be lower by about the same regardless of the max clock 04.31.31 # kugel: the MHz for decode doesn't depend on the max clock 04.31.48 # if it takes 30MHz for real time it takes 30MHz regardless of the CPU clocking at 3 or 300MHz 04.31.57 # it doesn't make sense that it needs more (minimum) MHz to decode without stuttering even though it decods twice asfast 04.32.07 # why not? 04.32.11 # saratoga_lab: right, that's why it's confusing for me 04.32.58 # 40MHz needed, decode in 30s vs 25MHz, decode in 60s ? 04.33.10 # no it always decodes at max clock 04.33.17 # the test_codec plugin boosts 04.33.51 # * kugel is maybe too tired 04.34.03 Join Rob2223 [0] (~Miranda@p4FDC9BD2.dip.t-dialin.net) 04.34.09 # the MHz column is just clock speed / percentage real time 04.34.19 # kugel: 30% of 80mhz is smaller than 15% of 240mhz 04.34.28 # so it normalizes the overall performance of codec by the cpu clock 04.34.46 # its not really all that physically meaninfgful actually, but it serves two purposes: 04.34.50 # The percentages are completely made up, but illustrate the point - the time is relative to clock rather than absolute 04.34.58 # 1) lets us compare decode performance on targets with different clocks 04.36.08 # 2) provides a number proportional to 1/percentage real time, which is often more intuitive, since percent realtime scales nonlinearly with increasing speed up (e.g the increase from 100% to 200% is much more significant to battery life then from 200 to 400%) 04.37.15 Quit Rob2222 (Ping timeout: 265 seconds) 04.37.26 # should I just lock that avi thread so people don't pile on that guy explaining why hes out of his mind 04.38.58 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 04.39.28 # New commit by 03funman (r25413): as3525v2: adjustable CPU freq : CGU_PROC is identical to as3525 after all ... 04.39.48 # yes, tell him to open a new thread when he's got some code to show? 04.40.09 Quit adnyxo (Read error: Operation timed out) 04.40.41 # saratoga_lab: I'd wait for a last response to my last post 04.41.10 # But if he's still unwilling, lock it with a "come back when you want to be part of the community" 04.41.39 Join webguest32 [0] (~4245faa4@giant.haxx.se) 04.41.41 # i'd rather just delete it actually and PM him something so that its less confrontational 04.42.03 # I don't think my last post was at all confrontational 04.42.30 # no but even if i lock it other people will still post, since like half our forum can post in locked threads :) 04.42.37 # funman: 240MHz? Didn't we run at 248MHz? 04.42.43 Quit JohannesSM64 (Quit: WeeChat 0.3.2-dev) 04.42.59 # kugel: nope we use a fixed setting of 240MHz for PLLA on v2, because we don't know how CGU_PLLA works 04.43.02 Join JohannesSM64 [0] (~johannes@cm-84.215.75.42.getinternet.no) 04.43.17 # ah, the PLL settings are still different, got it 04.43.23 # saratoga_lab: But I think if it's locked before he can respond, that may seem more confrontational to him. 04.43.23 # it would be easy (although a bit long) to find out, but do we really want to know? 04.43.24 # something is really screwy with AMS performance, I wonder if theres some weird restrictions on IRAM performance or something, like certain accesses are fast and other are slow 04.43.41 # => modify a bit of CGU_PLLA, measure CPU speed, repeat 04.43.53 # like on PP5020 with different IRAM banks having different access times 04.44.51 # * kugel would really love to re-enable voltage scaling 04.45.22 # saratoga_lab: we could write a test_memory plugin, but i'm not sure how we could test different banks 04.45.49 # perhaps define a small block size? 04.45.57 Quit webguest32 (Client Quit) 04.46.07 # I suspect the delay when waiting for the voltage to be high wasn't enough. we could put a while(delay--); or poll the voltage register more (so that we don't believe the voltage has stabilized enough until we read it say 5 times) 04.46.27 # kugel: iirc it caused problems with µSD ? 04.47.00 # yes, but there *must* be some way to make it work 04.48.09 # funman: its 5 banks of 64KB, so testing them should be easy, but it seems like a long shot 04.49.04 # the difference is the number of cycles required to make a read? 04.49.10 # if µsd works with high voltage all the time, it must also work with reverting the voltage when accessing the µsd 04.49.43 # funman: well its one random theory i just pulled out of my butt :) 04.50.05 # i should run updated tests on the gigabeat F and see how it compares to AMS 04.50.31 # didn't amiconn find what happened there? 04.51.17 # oh on PP5020 04.51.34 # yeah basically the device has 2 cores, and theres a crossbar switch between them 04.51.49 # so accessing a core's "local" bank is faster then accessing a remote bank due to some bug 04.51.54 # they fixed it in the PP5022 04.52.10 # oh ok 04.52.36 # but something similar could happen on AMS, maybe only one bank can be on the bus at a time and theres a cost to switching them or something like that 04.53.03 Quit kadoban__ (Read error: Connection reset by peer) 04.53.31 Join kadoban__ [0] (~mud@cpe-67-247-80-129.rochester.res.rr.com) 04.54.50 Quit kugel (Remote host closed the connection) 04.59.45 Quit TheSeven (Disconnected by services) 04.59.57 Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) 05.00.07 Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) 05.00.40 *** Saving seen data "./dancer.seen" 05.04.41 # hm wtf .. my Clip+ shows black screen now.. 05.05.38 # who needs a screen 05.07.53 # saratoga_lab: the as3525 datasheet says the iram on as3525 is 5 macros of 64kB 05.09.07 Join SirFunk [0] (~Sir@97-92-38-108.dhcp.aldl.mi.charter.com) 05.14.47 # New commit by 03Blue_Dude (r25414): FS#11081 - Hotkey patch. Many targets supported, but some keymaps need work before they can be switched on 05.16.18 # Builds are much faster. More clients now? 05.19.59 # All green. Excellent. Red deltas as expected. It's really easy to see which ones were switched on. 05.22.51 # New commit by 03funman (r25415): as3525*: set up CGU_COUNT register before turning on / modifying PLLs ... 05.23.33 # post commit stuck 05.24.56 Quit JohannesSM64 (Quit: WeeChat 0.3.2-dev) 05.29.54 # roolku seems to have added a half dozen extremely fast machines 05.30.32 Quit anewuser () 05.31.51 # I like 3 minute builds. Very nice. 05.34.40 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.2/20100316074819]) 05.34.43 # grmbl clip+ still doesn't boot, wtf 05.38.49 Quit Horscht (Quit: Verlassend) 05.55.51 # New commit by 03funman (r25416): as3525*: make sure fclk is 24MHz before using it as the clock source for pclk ... 05.58.04 # it seems i can't reliabily use test_fps to measure pclk, probably SSP is too limiting 06.06.14 # 1k for such a change? :/ 06.07.36 # oooh there's no fastbus/synchronous/asynchronous modes in arm926-ejs 06.09.13 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 06.10.08 # FlynDice_: we need you with a working laptop! 06.10.16 Join joshin [0] (~joshin@174-17-234-237.phnx.qwest.net) 06.10.16 Quit joshin (Changing host) 06.10.16 Join joshin [0] (~joshin@unaffiliated/joshin) 06.13.35 # funman: I got one today, downloading ubuntu disk as we speak.... I saw your last comment and went looking and I'm quite surprised, I thought I saw the bus mode switching code in the disassembly... You appear to be right though. 06.14.05 # it doesn't appear to have nasty side effects though 06.14.24 # but that also means currently as3525v2 is always boosted 06.15.01 # well if i remove those calls => black screen :o 06.16.36 # actually I kind of hope it prevents writes to the SD........ 06.18.24 Quit Hillshum (Ping timeout: 260 seconds) 06.20.00 # hm if i leave the first change in system_init (bic => fastbus) it boots, and the technical manual says writing as 0 is OK 06.20.33 # but cpu is running at 240MHz even if rockbox says unboosted 06.20.45 Join Hillshum [0] (~hillshum@75-165-244-84.slkc.qwest.net) 06.21.43 Join dmb_ [0] (~Dmb@unaffiliated/dmb) 06.23.06 Nick dmb_ is now known as dmb (~Dmb@unaffiliated/dmb) 06.30.50 # alright i've got it working, just needs to adapt the debug menu o: 06.37.20 # New commit by 03funman (r25417): Fix boosting on as3525v2 ... 06.37.41 Part jeffp 06.37.58 # FlynDice_: how would you measure pclk ? 06.38.40 # hm test_fps might just work .. 06.39.53 # I don't know how to measure it, I just calculated it with plla and the 2 dividers 06.40.02 # 870fps at fclk=240MHz, pclk=30MHz; and 108 fps at fclk=30MHz (the 30MHz is supposedly) 06.42.22 # 1164 fps at fclk=240MHz, pclk=60MHz; and 290 fps at fclk=60MHz 06.42.41 # at least there's an effect 06.51.15 Quit joshin (Quit: leaving) 06.53.29 Join JdGordon| [0] (~jonno@110.22.122.97) 06.54.54 # not much different results between 15 & 30MHz and 40 & 60 06.58.36 # setting bit 6 of CGU_PERI : data abort 06.59.45 # with the as3525(v1) reading it should only make pclk twice lower though 07.00.42 *** Saving seen data "./dancer.seen" 07.03.56 # funman: I could never make CGU_PERI bit 6 1 without a white screen for as3525v1 07.06.36 # it could be set according to http://forums.rockbox.org/index.php?topic=14064.msg162645#msg162645 07.08.09 # saratoga said he thought he saw some comments in the as3525 linux patch hinting that this would need to happen in the bootloader. 07.24.15 # so how exactly do I smurf my iSmurf? 07.24.20 Quit xiainx (Ping timeout: 246 seconds) 07.28.43 # froggyman: you need to download iSmurfSmurfer 07.29.17 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 07.29.47 # thats sounds like it might be a virus... what if it makes a mistake while smurfing my iSmurf? 07.39.40 # funman: thats the memory clock divider right? 07.39.50 # 1<<6 , yes 07.40.19 # IIRC the linux patch says something like "don't do this while the system is running, it clears dram" 07.40.59 # oh 07.41.12 Quit xiainx (Ping timeout: 240 seconds) 07.42.25 # by the way, if AMSv2 can do mp3 decoding at 30MHz, then 25-30MHz is a great choice of the idle clock 07.42.32 # err unboosted clock 07.42.43 # true 07.43.23 # any multiple of 240/16 07.44.01 # there is someone on ABI forum who measured battery life (14hours with flac), i asked him if he could do it with 60<->240MHz 07.44.33 # btw we could support 3 (or more) freqs instead of the current 2 07.45.27 # yeah thats something we've talked about a lot since a few targets could use it 07.45.51 # now there are 3 settings but i don't remember the difference between the 2 lowest 07.46.10 # MAX (easy to understand), NORMAL and DEFAULT 07.46.25 # IIRC default is only when playback is competely idle 07.46.29 # DEFAULT & NORMAL are bad names anyway 07.46.36 # yes 07.46.41 # default rarely happens and so doesn't really matter 07.46.55 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 07.47.18 # a way to do 25MHz for normal playback, 100 for boosted playback, and 250 for APE and MPEGplayer would be ideal 07.47.25 # but i guess thats not too important this early 07.48.02 # maybe someday add a codec/plugin api function that toogles between medium and high boost frequencies 07.48.24 # hm i can measure pclk with the timer 07.55.45 Join Buschel [0] (~ab@p54A3F4C8.dip.t-dialin.net) 08.01.43 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 08.02.53 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 08.03.15 # well it looks alright 08.05.26 # New commit by 03funman (r25418): as3525v2: assume plla is the source for pclk (verified with timer frequency) ... 08.05.41 # that means we could tune pclk with test_codec/battery_bench 08.07.38 # IRAM is driven off pclk like on the AMSv1 players right? 08.08.35 # I think it's off of hclk which == pclk if it makes a difference 08.11.17 # then pclk = core clock probably works best for unboosted, and pclk == high as possible (64MHz?) for boosted 08.12.02 Quit linuxstb (Ping timeout: 276 seconds) 08.12.05 Quit tmzt_ (Read error: Connection reset by peer) 08.12.21 Join tmzt_ [0] (~ircuser@99-157-224-139.lightspeed.bcvloh.sbcglobal.net) 08.14.41 Quit Buschel () 08.21.07 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 08.23.06 Join ender` [0] (krneki@foo.eternallybored.org) 08.25.41 Quit linuxstb (Ping timeout: 240 seconds) 08.26.10 # saratoga_lab: AMS IRAM isn't single cycle, is it? 08.26.32 # amiconn: not on the v1 devices anyway, don't know about the new ones 08.26.48 # but i guess it can't be boosted since the IRAM clock is only 64MHz IIRC 08.27.22 # Iiuc it is plain dram which happens to be embedded, and is a bit faster than external dram 08.27.45 # True single cycle requires sram 08.29.25 # the v2 players are weird, they have a ridiculous amount of not very fast IRAM, and then a lot more DRAM 08.31.13 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 08.31.59 # i should re test *RAM on amsv2, especially with different cpu clk & pclk 08.32.18 # if iram isn't faster then DRAM maybe its not worth using 08.32.28 # or put the plugin buffer there 08.32.51 # or perhaps disable its clock and get more battery 08.33.38 Join mitk [0] (~mitk@195.117.162.130) 08.35.23 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 08.35.56 Join Strife1989 [0] (~michael@adsl-154-2-49.mcn.bellsouth.net) 08.38.57 Quit xiainx (Ping timeout: 260 seconds) 08.39.17 Quit Strife89 (Ping timeout: 276 seconds) 08.40.38 Quit n1s (Ping timeout: 276 seconds) 08.41.24 Join n1s [0] (~n1s@rockbox/developer/n1s) 08.41.30 Join rockabocks [0] (~72f439b2@gateway/web/freenode/x-zclthvrrxipnebrq) 08.41.57 # hi, is there an installer available for macs or linux? 08.43.25 # rockabocks: http://www.rockbox.org/download/ 08.43.39 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 08.44.39 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.1.208) 08.46.30 Quit rockabocks (Quit: Page closed) 08.46.51 Quit saratoga_lab (Quit: Page closed) 08.47.30 Quit S_a_i_n_t (Ping timeout: 276 seconds) 08.50.31 Quit JdGordon| (Quit: Bye) 08.51.02 Quit xiainx (Ping timeout: 276 seconds) 08.52.12 Join Luca_S [0] (~5d3fc54b@giant.haxx.se) 08.55.25 Join LinusN [0] (~linus@rockbox/developer/LinusN) 08.55.35 Join flydutch [0] (~flydutch@host225-165-dynamic.15-87-r.retail.telecomitalia.it) 08.56.22 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 08.58.37 # FuzeV2: r25418 - got a panic - wait for TRAN state failed (STBY) 1 08.59.52 # playing from the microSD, playback started fine, pressed the home button, got into the playlist viewer, pressed >>|, the storage icon went on, then panic 09.00.31 # the problem can be reproduced 09.00.43 *** Saving seen data "./dancer.seen" 09.02.10 # I'd bisect it if there is an archive of previous builds... I don't have a build environment here 09.04.38 Quit n1s (Ping timeout: 248 seconds) 09.07.09 Join petur [0] (~petur@rockbox/developer/petur) 09.10.57 # there is http://www.rockbox.org/daily.shtml 09.11.38 Join n1s [0] (~n1s@rockbox/developer/n1s) 09.11.44 # btw DeviceChart doesn't have the AMS 09.15.14 Quit xiainx (Ping timeout: 246 seconds) 09.19.24 # the guy on ABI will give Clip+ battery bench results tomorrow with adjustable cpufreq enabled 09.20.34 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 09.20.37 # funman: the fuzev2 is not on that page 09.21.13 # http://www.rockbox.org/dl.cgi?bin=sansafuzev2 09.23.55 # how can we add fuzev2 to the daily.shtml ? i can't read dailymod.pl and i'm not sure the info is there anyway 09.24.42 # apparently there's a 'usablebuilds' defined? 09.25.13 # ah it's in trunk/ .. 09.26.11 # r25412 doesn't exhibit the problem, but that is the latest version on the dl.cgi page, thus i can't bisect the exact commit 09.26.33 Quit BHSPitMonkey (Remote host closed the connection) 09.26.49 # New commit by 03funman (r25419): Promote Fuzev2 to unstable 09.27.00 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 09.27.24 Quit CGL (Quit: Saliendo) 09.28.26 # kark00fka 09.28.35 # Luca_S: a quick test, playing from µSD and browsing playlist works on Clip+ 09.28.55 # oops. Sorry, wrong keyboard 09.29.06 # it could be related to my commits between the revisions you tested, and it could also be a random problem 09.29.17 # mitk: time to change password? B) 09.29.48 # I think so :( 09.29.57 # funman: to upgrade, I simply replaced the .rockbox folder. do I need to reload the boot loader too? 09.30.12 # nope, no need to change the bootloader 09.31.18 Quit xiainx (Ping timeout: 245 seconds) 09.32.11 # now trying to reload the latest revision.. 09.33.06 # also since the wheel doesn't work you can't change cpufreq setting for example 09.33.33 # unluckily no 09.33.47 # hm e200R is in the daily builds 09.34.02 # isn't it possible to change the lower button to mimic the "scroll down" action, at least temporarily? 09.34.03 # should I remove it ? 09.34.47 # Luca_S: perhaps, but i think it's not important at this stage 09.35.52 # saratoga: ^ 09.36.38 # uhm, r25419: screen corruptions 09.36.57 # yeah and black screen according to ABI guys :( 09.37.21 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 09.37.40 # and the panic wait for tran state is still here 09.38.33 # looks like i broke pretty much AMSv2 09.40.03 # good thing it's april 1, or people would be upset 09.40.31 # New commit by 03funman (r25420): Remove e200R from daily builds 09.41.02 # testers are called testers for a reason ;) 09.41.16 # i believe they're smurfs today 09.41.37 # Luca_S: testing the same thing than you on fuzev2: no crashes 09.42.04 # screen corruption is there, we probably just need to tweak the delays in lcd driver 09.42.20 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 09.44.43 Quit xiainx (Ping timeout: 264 seconds) 09.45.09 # and the clip+ current build doesn't work for me either 09.45.14 # i wonder what's wrong in my test setup 09.45.50 # usually i just do make bin && cp rockbox.sansa /path/to/.rockbox && umount 09.49.08 Join merbanan [0] (~banan@c-62-220-165-110.cust.bredband2.com) 09.50.28 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 09.50.34 # build from a clean directory just works but the binary is very different from current build (although the difference of rockbox.sansa is only 4 bytes) 09.51.32 # same arm-elf-gcc/ld , different host gcc 09.51.40 # maybe some build client has different chain? 09.52.05 # too late :D 09.53.20 # system_init() is identical for the 2 though 09.54.19 Join stoffel [0] (~quassel@p57B4CF72.dip.t-dialin.net) 09.56.18 # the difference is likely due to different offsets of functions being called 09.57.27 Join spaax [0] (opera@85-31-247-126.internetia.net.pl) 10.01.21 Part spaax 10.09.26 # hm if CGU_PERI is always based off PLLA and we clear the divider it might be insanely high 10.12.13 Join dfkt [0] (dfkt@unaffiliated/dfkt) 10.17.08 Part froggyman 10.20.45 Quit stoffel (Remote host closed the connection) 10.20.45 # hu oh µSD error too on Clip+ 10.21.23 # New commit by 03funman (r25421): Try to fix problems on Clip+ (not sure why they appear randomly) 10.25.11 Quit Luca_S (Quit: CGI:IRC) 10.28.48 Join JanDo [0] (~JanDo@212.44.150.75) 10.29.31 # New commit by 03funman (r25422): Fuzev2 LCD: replace delays by calls to lcd_delay() (delays not changed) 10.31.16 # * funman commits without testing 10.31.23 Join Luca_S [0] (~5d3fc54b@giant.haxx.se) 10.31.38 Part JanDo 10.31.40 # now testing :) 10.31.57 # you get also bad colors (pink like) on part of the screen? 10.31.59 Join JanDo [0] (~JanDo@212.44.150.75) 10.32.08 Quit merbanan (Ping timeout: 276 seconds) 10.32.42 # why the green delta ? :/ 10.32.53 # the function is inline 10.33.16 Quit linuxstb (Ping timeout: 246 seconds) 10.33.51 # did it change build client? 10.34.16 # no more panic it seems, and no screen corruptions 10.34.29 # I stand corrected, screen corruptions are there 10.34.34 Join Jaykay [0] (~chatzilla@p5DC577F6.dip.t-dialin.net) 10.35.03 # and the panic too 10.35.12 # no (althought it could have), and the usual random change sare smaller than that 10.35.28 # screen corruption = part of screen has a bad color ? 10.35.35 # consistent over that part 10.37.02 # right, it seems pinkish from about two thirds of the screen till bottom, it lasts about a third of a second before returning fine 10.37.10 # right, it seems pinkish from about two thirds of the screen till bottom, it lasts about a third of a second before returning fine 10.38.58 # perhaps kugel will have an idea, at least it's not shifted like if we missed some pixels 10.39.11 Join Luca_S_ [0] (~5d3fc54b@giant.haxx.se) 10.40.14 Join Kitr88 [0] (Kitr88@BSN-182-4-208.dial-up.dsl.siol.net) 10.40.59 # huh, someone hacked rockbox ? 10.41.03 # just a question: why did you say that remapping the "playlist" button to "scroll down" wouldn't be useful now? 10.41.04 # rockobx.org ? 10.41.15 # There are 'smurf' everywhere !!! 10.42.22 # those damn smurf hackers 10.42.29 Quit Luca_S (Quit: CGI:IRC (Ping timeout)) 10.42.34 # smurf them 10.42.36 Quit Kitar|st (Ping timeout: 265 seconds) 10.42.46 # who are there ? What does 'smurf' means ? 10.42.54 # Luca_S_: yes i think it wouldn't be useful now 10.42.59 # pamaury: smurf = schtroumpf 10.43.09 # and how did they do ? 10.43.10 # pamaury: http://images.google.it/images?hl=it&q=smurf&um=1&ie=UTF-8&sa=N&tab=wi 10.43.56 # funman: I could test playing music from the internal storage if I could move the list selection down... 10.44.19 # pamaury: a sarsaparilla trojan, I think 10.44.34 # Luca_S_: true but we can test on other similar devices (Clipv2/Clip+), and i trust kugel for writing scrollwheel support soon 10.44.48 # Zagor: Azrael1.0 ? 10.45.01 # ahhh, I didn't know he was working on it, sorry ;) 10.45.03 # Zagor: 'sarsaparilla' ? 10.47.07 # Only the frontpage seems to have changed 10.48.05 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 10.48.34 Quit xiainx (Ping timeout: 268 seconds) 10.50.54 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 10.54.06 Join f_coco [0] (~dcf96389@giant.haxx.se) 10.55.10 Quit phanboy4 (Ping timeout: 265 seconds) 10.56.55 Quit f_coco (Client Quit) 10.56.59 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 11.00.44 Quit dfkt (Ping timeout: 276 seconds) 11.00.46 *** Saving seen data "./dancer.seen" 11.06.15 Quit xiainx (Ping timeout: 252 seconds) 11.11.13 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 11.11.37 Quit funman (Quit: free(random());) 11.12.34 Quit Zarggg (Ping timeout: 240 seconds) 11.13.24 Join Zarggg [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 11.14.46 Quit linuxstb (Ping timeout: 248 seconds) 11.15.22 Quit Luca_S_ (Quit: CGI:IRC (EOF)) 11.20.11 Join Luca_S [0] (~5d3fc54b@giant.haxx.se) 11.21.20 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 11.26.44 Quit xiainx (Ping timeout: 276 seconds) 11.31.40 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 11.33.06 Join perfectdrug [0] (~marko@p5B0EC16F.dip.t-dialin.net) 11.33.17 Join user124345 [0] (~51e05113@gateway/web/freenode/x-hnvgravewgntvogf) 11.38.40 Quit xiainx (Ping timeout: 240 seconds) 11.41.21 Quit linuxstb (Ping timeout: 264 seconds) 11.41.50 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 11.42.39 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 11.50.14 Quit xiainx (Ping timeout: 268 seconds) 11.50.59 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 11.53.01 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 12.08.20 Join akur [0] (~akur@93.102.82.102.rev.optimus.pt) 12.10.27 Quit Jaykay (Quit: ChatZilla 0.9.86 [Firefox 3.6.2/20100316074819]) 12.10.39 Join archivator [0] (~archivato@77.70.28.57) 12.14.44 Part LinusN 12.16.54 Quit archivator (Remote host closed the connection) 12.23.24 Part akur 12.25.28 Join niekie [0] (~niek@CAcert/Assurer/niekie) 12.28.45 Quit xiainx (Ping timeout: 252 seconds) 12.32.52 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 12.35.58 Join krabador [0] (~darkham@host128-183-dynamic.46-79-r.retail.telecomitalia.it) 12.44.56 Quit xiainx (Ping timeout: 264 seconds) 12.47.26 # the website is still smurfing ? 12.48.37 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 12.49.58 # it might have something to do with the date 12.51.48 # ah lol 12.57.56 # New commit by 03funman (r25423): Move fuzev2 to unusable 13.00.48 *** Saving seen data "./dancer.seen" 13.03.04 Join archivator [0] (~archivato@77.70.28.57) 13.03.57 Part JanDo (" www.qip.im ") 13.07.13 Join perfectdrug1 [0] (~marko@p5B0EDA4D.dip.t-dialin.net) 13.08.45 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 13.09.31 Quit perfectdrug (Ping timeout: 265 seconds) 13.09.36 Quit xiainx (Ping timeout: 245 seconds) 13.10.25 Join JanDo [0] (~JanDo@212.44.150.75) 13.12.59 Join merbanan [0] (~banan@c-62-220-165-110.cust.bredband2.com) 13.14.47 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 13.20.49 # April Fools Day is not a global phenomenom sadly 13.21.46 Quit blairb (Quit: Leaving) 13.22.02 # fools are though 13.25.16 Quit TheSeven (Quit: ChatZilla 0.9.86 [Firefox 3.6.2/20100316074819]) 13.34.14 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 13.36.41 Quit xiainx (Ping timeout: 245 seconds) 13.38.16 Join huelk_ [0] (~huelk@dtmd-4db78ea6.pool.mediaWays.net) 13.39.50 Quit huelk_ (Client Quit) 13.39.57 Quit yosafbridge (Quit: Coyote finally caught me) 13.41.59 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 13.54.23 Join Schmogel [0] (~Miranda@p3EE21F35.dip0.t-ipconnect.de) 13.58.33 Nick dfkt_ is now known as dfkt (dfkt@unaffiliated/dfkt) 14.09.59 Join robin0800 [0] (~quassel@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 14.10.00 Quit robin0800 (Read error: Connection reset by peer) 14.10.31 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 14.12.35 Quit evilnick (Quit: Leaving) 14.15.04 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 14.16.25 Quit krabador (Read error: Connection reset by peer) 14.20.10 # gevaerts: mcuelenaere suggests using the profiling code to implement the boot charting.. 14.20.33 # this seems rather frightening ;) 14.26.41 Quit xiainx (Ping timeout: 264 seconds) 14.28.26 # Torne: hm, yes... I don't know anything about that code, but it *might* work well 14.29.09 # Well, I could add -finstrument-functions but not define RB_PROFILE 14.29.18 # and then implement my own profiling function 14.29.27 # which does rather less than what profile.c does. 14.29.43 # but this seems like a disproportionate amount of work, tbh.. 14.29.49 # and it adds a load of overhead at runtime 14.30.10 # if CHART_CALL is really that objectionable I would probably prefer to just put all the strings in manually, tbh 14.30.17 # for the sake of 28 functions it's really not worth it :) 14.30.30 # it'll only take ten minutes. *g* 14.30.48 # Torne: I think I have an alternative solution using C preprocessor trick but I'm trying to make it work 14.30.52 # Oh? 14.30.57 # paste what you've got? 14.32.26 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 14.32.35 # The idea is that if you want to log a function "foo" you define: "#define foo(...) (logf("call foo");foo(__VA_ARGS__)) 14.32.51 # The problem is that you have to it manually for each function 14.33.08 # I dont tihnk the CHART_CALL() macro is too intrusive 14.33.17 # especially if we limit to the init funcs 14.33.19 # pamaury: we considered that kind of thing.. 14.33.31 # JdGordon: yeah, like i said it's used 28 times, only in main.c and settings.c 14.33.38 # it's not meant to be put *everywhere* 14.33.45 # because if nothing else the logf buffer will wrap 14.34.01 # i put one on various interesting seemign points in init() and settings_apply() 14.34.05 # I'd still like someone to work on making the apps main() less hardware fidly 14.34.14 # yes, that would also be good, but unrelated ;) 14.34.20 # Torne: and what is the problem with this solution ? 14.34.29 # pamaury: I wasn't thinking of doing it quite that way 14.34.35 # I was thinking renaming the symbols, but yeah 14.34.46 # This way you avoid any renaming 14.34.49 # the macro will work since macros can't be applied to their own output 14.35.15 # it also produces nicer logs, actually 14.35.15 Quit Luca_S (Quit: CGI:IRC (EOF)) 14.35.34 # since CHART_CALL(rc = foo(bar, baz, bash)); actually logs the whole string "rc = foo(bar, baz, bash)" 14.35.47 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 14.36.57 # so, hm 14.37.13 # You'd end up with a header file contianing a list of htem 14.37.18 # and you just include that header into main.c and settings.c 14.37.34 # I guess it might also accidentally decorate some other instances of the same functions in those files? not sure. 14.37.38 # but that's probbaly not a huge deal 14.37.46 # you can cut the log off once you see it enter root_menu 14.38.07 # the problem with my solution is that it with log all calls, even some you don't want 14.38.19 # Most of the things being logged are only called once 14.38.22 # The problem with the proposed sqolution is that you need to decorate each call 14.38.31 # and it won't be all calls, because you only need to include it in a couple of files 14.38.44 # Yes, all calls within the file 14.38.48 # basically everything interesting is called from main(), init(), or settings_apply() 14.38.57 # i suspect the "collision rate" is virtually zero 14.39.04 # maybe even actually zero, not sure. 14.39.09 # probably 14.39.18 # so yeah, i think it would do 14.39.20 # i'll try it in a mo 14.40.01 # You'd still need some explicit CHART_STR's for a few points that aren't function calls 14.40.05 # but htat's ok 14.42.11 Join anewuser [0] (anewuser@unaffiliated/anewuser) 14.42.11 # Hum, my solution also requires to be careful about definition and declarations, the c preprocessor doesn't make a difference 14.42.57 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 14.43.16 # You'd need to include the header last 14.43.33 # Hm, but that might not even be sufficient, some of hte functions init() calls are also defined in main.c 14.43.55 # yeah, that's my point 14.44.07 # Indirect self-references are not expanded, i notice, also, which means you can in fact define foo in terms of CHART_CALL or similar anyway ;) 14.44.08 # I don't see a way to get around this problem easily 14.44.14 # Oh, er 14.44.23 # Your solution also doesn't work for rc = init_foo() 14.44.27 # yes it works 14.44.28 # because the macro doesn't expand to an expression 14.44.37 # #define foo(...) (printf("You call: " #__VA_ARGS__),foo(__VA_ARGS__)) 14.44.47 # notice the parenthesis and the "," 14.44.48 Quit kio (Quit: Leaving) 14.45.04 # Heh 14.45.08 # But then how do you trace afterward? :) 14.45.25 # (you can do it if you know which functions return values and which are void, i guess) 14.45.42 # i need a trace before 8and* after, because not everything during init has a trace 14.45.48 # err, you're right, give a minute to try to find another trick 14.45.49 # so it's not sufficient to measure the time from one thing to the next 14.46.04 # You can do it if you have seperate macros for void functoins and int functions 14.46.29 # Oh, no 14.46.35 # yes but in one macro :) 14.46.38 # again, not easily because you can't put a variable declaration inside an expression :) 14.46.45 # yes you can 14.46.46 # : 14.46.52 # ...ok, maybe gcc can 14.47.01 # ({int a; ...; a}) 14.47.03 # but the idea makes me throw up in my mouth a little 14.47.05 # :) 14.47.17 # i guess abusing gcc extensions is fine 14.47.27 # but that's still pretty horrifying to look at. but i guess only if you look in bootchart.h 14.47.36 # :) 14.48.56 # Torne: that thing works: 14.48.57 # #define foo(...) ({printf("You call: " #__VA_ARGS__);int a=foo(__VA_ARGS__);printf("end of call");a;}) 14.49.06 # Yeah 14.49.11 # wonderful isn't it ;) 14.49.16 # not really... 14.49.21 Quit merbanan (Ping timeout: 260 seconds) 14.49.21 # but not for funcitons that return anything other than int 14.49.23 # surely 14.49.38 # i'm looking at __builtin_apply and being slightly afraid 14.49.51 # that would have to be a functoin, though, which means you are back at symbol renaming ;) 14.51.48 # Torne: why ? 14.52.14 # __builtin_return returns from the containing function with the result of calling the function referred to by __builtin_apply 14.52.27 # so you'd ahve to rename the real init_whatever to something else and implement a shim init_whatever that used that 14.52.53 # no, the macro I have you before works out of the box the function name is foo 14.53.09 # but it won't compile if foo returns void 14.53.19 # so you'd need at least two of them 14.53.27 # no, but you just have to have two macros, that's not too much 14.53.35 # And it will be hidden in a header 14.53.49 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 14.54.09 # right. 14.54.11 # hm 14.54.13 # i'll try it 14.54.24 # it's better than -finstrument-functions ;) 14.57.17 Join merbanan [0] (~banan@c-62-220-165-110.cust.bredband2.com) 14.58.49 # Torne: I think there are ugly C extension to do it with one macro, I'm testing 15.00.49 *** Saving seen data "./dancer.seen" 15.07.31 Quit linuxstb (Ping timeout: 245 seconds) 15.10.44 Quit xiainx (Ping timeout: 264 seconds) 15.15.45 # I just enabled suexec on www.rockbox.org. ping or mail me if something is broken. 15.15.59 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 15.17.18 # Zagor: http://www.rockbox.org/download/byhand.cgi is getting Server Error! - Error 500 15.18.08 # Torne: I have a solution with one macro only ! 15.18.58 # Zagor: same for http://www.rockbox.org/mail/ 15.20.16 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 15.21.10 # pamaury: oh? :) 15.21.35 # Torne: yes, I can still simplify it but I'll paste it 15.22.16 # (5 lines is small enough or I'll get kick by pasting ?) 15.24.47 # mc2739, gevaerts: thank you. fixed now. 15.24.56 # Torne: 15.24.57 # #define foo2(...) ({printf("You call: " #__VA_ARGS__);int a= \ 15.24.57 # __builtin_choose_expr( \ 15.24.57 DBUG Enqueued KICK pamaury 15.24.57 # __builtin_types_compatible_p(__typeof(foo2(__VA_ARGS__)),void), \ 15.24.57 # (foo(__VA_ARGS__),0),foo2(2,3));printf("end of call");(__typeof(foo2(__VA_ARGS__)))a;}) 15.24.58 *** Alert Mode level 1 15.24.58 # :) 15.25.39 # oops, s/2,3/__VA_ARGS__ 15.27.25 Join leavittx__ [0] (~leavittx@89.221.199.187) 15.27.59 Join User67703 [0] (~theuser12@c39.dnepro.net) 15.29.32 # no..... just no! 15.30.02 # oops, other mistake: s/foo/foo2 15.31.07 # JdGordon: why ? It's horrible to write but it works nicely, it will be hidden in a header 15.31.18 # Otherwise, use two macros 15.32.24 Join einhirn [0] (~Miranda@p5485A3F0.dip0.t-ipconnect.de) 15.33.46 # New commit by 03zagor (r25424): Path change for mod_suexec 15.33.57 Quit xiainx (Ping timeout: 276 seconds) 15.34.09 Quit antil33t (Read error: Connection reset by peer) 15.34.15 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 15.34.28 # that's an impressive achievement 15.34.33 # but I really dislike it, i'm afraid :) 15.34.58 # two macros is better 15.34.59 *** Alert Mode OFF 15.35.04 # i'll have a fiddle, anyway 15.35.11 # ..wait 15.35.15 # isn't the declarations still a problem 15.35.43 # Torne: yes, unfortunately 15.35.58 # I can't see a way to get around this problem for now 15.36.03 # anyway, seriously 15.36.14 # I think an elegant solution is basically out of the question 15.36.27 # cpp is just not metaprogrammey enough 15.36.33 # yes, two macros seems ok to me 15.36.40 # two macros doesn't fix the declarations 15.37.01 # i seriously think the choice is between CHART_CALL as-is, and just writing the trace strings manually ;) 15.37.20 # then do it manually if it's just in one function 15.37.24 # i mean, compliments to you for being able to divine the above macro declaration ;) 15.37.27 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 15.37.40 # no, it's too horrible to be useful, just an amusement :) 15.37.43 # but i think actually using it is just too nightmarish, especially if it won't really work because it'll splat the declarations of the functions 15.38.22 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 15.38.22 # * Torne will just write the traces manually. :) 15.38.36 # we've spent far longer than that would take already ;) 15.38.37 # It seems to me that a manual solution is better than the CHAR_ macro which makes it hard to read 15.38.52 # and while it's more lines, it's obviously ignorable to a reader who doesn't know what it is 15.38.59 # because it obviously looks like trace/debug info 15.40.04 # (and it makes a slightly better looking chart anywya) 15.41.19 Quit beta2k (Ping timeout: 264 seconds) 15.42.05 Quit JdGordon (Quit: Leaving.) 15.42.24 Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) 15.47.33 Quit linuxstb (Ping timeout: 265 seconds) 15.53.39 Quit mitk (Quit: Leaving) 16.04.51 Quit perfectdrug1 (Quit: Leaving.) 16.34.06 # hm. should bootchart mode automatically enable logf? it's not any use on target othewise, and on the sim it's probably useless to begin with 16.37.42 # you can log it to a file but it makes sense to enable logf 16.38.12 # it starts before storage_init so it would be a huge pain to log to a file :) 16.38.17 # * pamaury also notices that logf has an advantage over file logging on target where write is not implemented 16.38.34 # at th emoment it does _logf or DEBUGF depending if logf is available 16.38.46 # but supporting the sim is probably useless. 16.38.52 # nobody cares about benchmarks there :) 16.39.01 # i'll just force logf on as well 16.39.51 Join spaax [0] (opera@85-31-247-126.internetia.net.pl) 16.40.16 # use _logf and force to compile with logf enabled, so that you still choose to logf the rest of the file 16.40.37 # Yeah, that's what i was doing 16.40.52 # ok, perfect 16.44.52 # ..hm, now it doesn't compile 16.45.06 # * Torne looks to see what he screwed up :) 16.46.53 Join toffe82 [0] (~chatzilla@12.169.218.14) 16.52.21 Quit merbanan (Ping timeout: 276 seconds) 16.52.43 Part spaax 16.58.37 Quit arbingordon (Ping timeout: 246 seconds) 17.00.52 *** Saving seen data "./dancer.seen" 17.02.03 Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) 17.02.07 Join einhirn_ [0] (Miranda@vpn10.rz.tu-clausthal.de) 17.02.12 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 17.02.17 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 17.05.39 Part JanDo (" www.qip.im ") 17.05.42 Join arbingordon [0] (~w@unaffiliated/arbingordon) 17.05.55 Quit einhirn (Ping timeout: 264 seconds) 17.07.31 Join kugel [0] (~kugel@rockbox/developer/kugel) 17.07.39 # \o/ 17.07.43 # win! I found the scrollwheel bits 17.09.22 # áëÿ 17.09.28 # oops 17.09.30 # sorry 17.09.49 Join dmb_ [0] (~Dmb@unaffiliated/dmb) 17.10.17 # \o/ 17.10.40 Quit dmb (Read error: Operation timed out) 17.12.13 Quit planetbeing_ (Quit: Poof.) 17.18.38 # * linuxstb wonders if there has been any discussion of http://www.talkingmp3players.com/index.html and if they comply with the GPL. 17.19.34 # linuxstb: It was mentioned a while back in -community 17.19.55 # I'll check the logs then... Err... 17.20.03 # IIRC, AlexP was going to email them and ask them to supply the source 17.21.55 # it even works :) 17.23.35 # yeah, their binary downloads just contian the contents of .rockbox 17.23.39 # not even the .rockbox folder itself, amusingly 17.23.49 # and ther'es no mention of source or license anywhere on their site or in the archive 17.24.04 # so no, they aren't complying 17.24.10 Quit User67703 (Ping timeout: 245 seconds) 17.25.23 # Torne: They make Rockbox itself available for download? I just saw rbutilqt.exe 17.25.37 # http://www.talkingmp3players.com/support.html 17.25.37 Quit pamaury (Quit: Quitte) 17.25.37 # Ah yes, I see them now... 17.25.38 # they have "firmware updates" 17.26.54 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 17.26.58 # And also include the most recent bookmark in the "firmware update" 17.27.34 # well, it makes me still a bit happy that there are mp3 players sold that ship rockbox no matter of gpl ;) 17.28.03 Quit linuxstb (Quit: Leaving) 17.28.15 # oh sure, i'm sure they'r enot doing it on purpose 17.28.20 Quit anewuser (Ping timeout: 246 seconds) 17.28.21 Join User67703 [0] (~theuser12@c39.dnepro.net) 17.28.36 # they probably haven't modified it even 17.30.10 Quit User67703 (Client Quit) 17.31.07 Join anewuser [0] (anewuser@unaffiliated/anewuser) 17.31.51 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 17.34.33 Join dockimble [0] (~dockimble@77.227.1.24) 17.35.34 Nick Strife1989 is now known as Strife89 (~michael@adsl-154-2-49.mcn.bellsouth.net) 17.35.42 # On the one hand I'm happy they are offering this service. But we have the issue of out-of-date files being distributed, plus no credit for us etc. 17.36.46 # It would be nice to open a friendly dialog with them. 17.42.26 Join dmb [0] (~Dmb@unaffiliated/dmb) 17.42.33 # Ouch, the "update" is from 21st Jan for all three devices - so not even 3.5 17.43.19 Quit TillW (Quit: This now concludes our broatcast day.) 17.46.53 Quit FlynDice_ (Ping timeout: 246 seconds) 17.47.11 Join FlynDice_ [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 17.51.53 # domonoky: did you see fs#11160? :) I was actually surprised how little time it took to rewrite a major part of the processing :) 17.52.15 # will take a look. 17.55.45 # using setMaxThreadCount = 1 to make it sequential is a nice idea. :-) 17.56.44 # * kugel wonders why my changes make the scrollwheel move insanely fast 17.59.07 # domonoky: yeah, it simplified things a lot. Goes to say how well-designed Qt really is :) 18.04.25 Quit bluebroth3r (Ping timeout: 246 seconds) 18.05.11 # you should use the Qt Macros for the flags like its done in the bootloader base class. This way the flags get typesafe. 18.05.31 Quit linuxstb (Ping timeout: 258 seconds) 18.06.19 Join bluebrother [0] (~dom@g224237052.adsl.alicedsl.de) 18.06.19 Quit bluebrother (Changing host) 18.06.19 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 18.06.30 # Haven't looked at the bootloader classes, will fix it after the weekend 18.07.59 # New commit by 03kugel (r25425): Fuzev2: Scrollwheel works like a charm :) ... 18.08.22 # its just two macro calls and using the newĺy generated type instead of int in capabilitys() 18.08.48 Join mitk [0] (~mitk@chello089078013146.chello.pl) 18.08.57 Join froggyman [0] (~me@unaffiliated/froggyman) 18.09.25 # and as you mentioned in the patch tracker, it would be better to move this new pointers into a sub struct. 18.09.47 # (in TalkEntry) 18.10.05 Quit petur (Quit: *plop*) 18.11.45 # Yeah, I'll put in some cosmetic touches like that for the final version. I just wanted to prove to myself that it's doable and, more importantly, improves performance. 18.18.53 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 18.20.13 Join komputes [0] (~komputes@ubuntu/member/komputes) 18.27.25 # New commit by 03torne (r25426): Boot charting support. ... 18.29.22 Part qfr 18.30.33 Join Eugenpaul [0] (~ugnpaul@65.226.32.95.dsl-dynamic.vsi.ru) 18.30.44 Join dockimble1 [0] (~dockimble@77.227.1.24) 18.31.36 # does the fuzev2 scrollwheel work in the latest build? 18.33.54 Quit linuxstb (Ping timeout: 252 seconds) 18.34.49 Quit MagusG (Read error: Connection reset by peer) 18.35.33 Part Eugenpaul 18.35.43 Join Eugenpaul [0] (~ugnpaul@65.226.32.95.dsl-dynamic.vsi.ru) 18.36.00 Part Eugenpaul 18.36.54 # dockimble1: this from 5.05 Fuzev2: Scrollwheel works like a charm 18.37.38 Join fyrestorm [0] (~nnscript@static-71-249-251-152.nycmny.east.verizon.net) 18.38.01 Quit dockimble1 (Quit: WeeChat 0.2.6.3) 18.39.33 # hm, is the build server stuck? 18.39.44 # it's been doing r25425 for half an hour 18.39.58 # Torne: its probably smurfing :-) 18.40.39 # heh 18.41.58 Join Adubb [0] (~Aldubuc@bas15-toronto63-1279474082.dsl.bell.ca) 18.42.16 Quit archivator (Remote host closed the connection) 18.43.32 # dockimble: yes 18.44.10 # awesome 18.44.36 # evilnick_B: I didn't do anything, but someoone should 18.45.00 # Zagor, B4gder: can you slap the build server a bit, it's lagging 18.46.45 Quit froggyman (Read error: Connection reset by peer) 18.47.27 Join froggyman [0] (~me@unaffiliated/froggyman) 18.48.33 Join dockimble1 [0] (~dockimble@77.227.1.24) 18.50.45 Quit dockimble (Ping timeout: 258 seconds) 18.52.33 Quit antil33t (Read error: Connection reset by peer) 18.52.39 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 18.53.30 Quit slck (Ping timeout: 240 seconds) 18.55.09 # dockimble1: does the latest build work? 18.55.13 Part froggyman 18.56.37 Join slck [0] (Venci@Slackware.SlackPix.Com) 18.57.08 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 19.00.55 *** Saving seen data "./dancer.seen" 19.01.02 Quit Hillshum (Ping timeout: 276 seconds) 19.05.18 Quit dmb (Ping timeout: 246 seconds) 19.06.03 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 19.06.53 Join funman [0] (~fun@rockbox/developer/funman) 19.08.42 # kugel: works if i reduce fclk to 120MHz, else doesn't work 19.09.09 Quit anewuser () 19.09.31 # the delays aren't quite worked out still, it works ok when unboosted 19.10.04 # did you test with trunk or updated your tree only when you committed? 19.10.24 # no, trunk worked for me unboosted 19.10.42 # but I'm now trying some cleanup and it doesn't work well when unboosted 19.11.01 # * bluebrother spots a bug entry for something he already worked on and changed 19.11.04 # also some reports on ABI that Clip+ buttons don't work 19.11.07 # however when boosted it seems to be fine which is strange 19.11.40 # with my cleanup, I get lcd corruption and sluggish UI. when boosted both is fixed 19.11.46 # * bluebrother grumbles a bit 19.12.04 # shouldn't it be the other way around? 19.12.23 # did we really get the unboosting right? 19.12.46 # yes 19.13.36 # I'm wondering why the delays seems to fit when we're running faster 19.14.27 # delay too long? 19.14.43 # try highering unboosted frequency 19.14.45 # it works fine again if I double them 19.15.13 # hm I suppose we should set the unboosted freq to 24MHz immediately 19.18.42 # that will work better? 19.19.10 # no but it could save some battery (alas measuring it without battery_bench would be tedious) 19.19.28 # and if we have to tweak the delays in each driver, better do it to the final value now 19.19.50 # I can hardly tweak if I get something this strange :\ 19.19.50 # New commit by 03funman (r25427): fuzev2: enable plugins 19.20.12 # no problems with the LCD ? 19.20.18 # heh, I was just about to do that 19.20.22 Join mt [0] (~chatzilla@41.233.151.87) 19.20.47 # the UI is very slow when unboosted .. 19.20.57 # at 60MHz ? 19.21.00 # yes 19.22.47 Join Tomis2 [0] (~Tomis@70.134.93.53) 19.22.49 # judging by test_boost, boosting doesn't really work 19.23.53 # the counter isn't any faster 19.24.16 # New commit by 03funman (r25428): Clip+: remove button_hold() : we use software hold 19.25.10 # ah no it seems to be bugged 19.25.18 Quit Tomis (Ping timeout: 268 seconds) 19.25.18 Nick Tomis2 is now known as Tomis (~Tomis@70.134.93.53) 19.26.01 # now scrollwheel works although i didn't change anything related 19.26.48 # kugel: test_boost works: up to boost, down to unboost 19.26.57 # btw it could use rtc 19.27.31 # funman: yes but it looks like if you press up twice, and then only once down, it displays normal but still runs boosted 19.28.00 # cpu_boost() keeps an internal counter 19.28.24 # I know, test_boost is doing it wrong 19.30.29 Quit bmbl (Quit: Bye!) 19.35.04 # B4gder/ Zagor: ping 19.37.12 # I'm around, but busy... 19.37.21 # Hanging build 19.37.25 # I know 19.39.31 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 19.40.56 Quit n1s (Quit: Lämnar) 19.44.46 Quit flydutch (Quit: /* empty */) 19.45.20 Join MagusG [0] (magusg@c-76-97-148-35.hsd1.ga.comcast.net) 19.50.37 # New commit by 03kugel (r25429): Fix test_boost boost handling. Also show the number of loops per second. 19.56.13 # I suspect Zagor has broken the build server 19.56.49 # is it really smurfed up? 19.56.57 # (physically) 19.57.03 # The smurfexec feature? 19.57.27 # yes something related to that 19.57.53 Quit phanboy4 (Ping timeout: 265 seconds) 19.58.26 # i wonder if different CPU clocks would make a difference if i leave the Clip+ backlight on 20.00.32 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 20.02.53 Quit kugel (Remote host closed the connection) 20.03.17 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 20.03.57 # I start benching Clip+ @60MHz 20.04.20 Part toffe82 20.06.18 Join phanboy_iv [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 20.06.18 # I just hope it lasts less than 24h, i don't have enough storage for 24h of stereo pcm O:-) 20.06.28 Join Luca_S [0] (~pjIRC@87.18.82.107) 20.06.56 # the cgi chat is broken too, not just the build server :/ 20.07.27 # too bad, I'm eager to try the fuzev2- scrollwheel build :D 20.09.29 Quit phanboy4 (Ping timeout: 265 seconds) 20.20.13 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 20.21.37 Quit alexbobp (Quit: leaving) 20.21.44 Join alexbobp [0] (~alex@66.112.249.238) 20.22.28 Join Horschti [0] (~Horscht2@xbmc/user/horscht) 20.24.43 Quit Horscht (Ping timeout: 258 seconds) 20.27.31 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 20.29.17 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 20.29.21 Nick Horschti is now known as Horscht (~Horscht2@xbmc/user/horscht) 20.29.27 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 20.29.55 # 8GB clips for 35 shipped in the US today on sellout.woot 20.30.10 Quit mitk (Quit: Leaving) 20.32.12 Quit phanboy_iv (Ping timeout: 265 seconds) 20.35.53 Quit kadoban__ (Remote host closed the connection) 20.36.18 Join kadoban__ [0] (~mud@cpe-67-247-80-129.rochester.res.rr.com) 20.38.07 Join dmb__ [0] (~Dmb@198.138.209.17) 20.40.32 Join spaax [0] (opera@85-31-247-126.internetia.net.pl) 20.45.15 Quit Luca_S (Quit: www.pjirc.it by IRCItaly.net) 20.54.25 Part spaax 20.54.41 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 20.54.48 Join petur [0] (~peter@d54C6FA7C.access.telenet.be) 20.54.49 Quit petur (Changing host) 20.54.49 Join petur [0] (~peter@rockbox/developer/petur) 20.56.19 Quit petur (Client Quit) 21.00.56 *** Saving seen data "./dancer.seen" 21.09.24 Quit phanboy4 (Ping timeout: 265 seconds) 21.11.01 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 21.11.05 # Hmmm, my build client lost a log somewhere. 21.11.34 # "Server message: fatal build error: missing log file. [This client] has been temporarily disabled." 21.11.41 # Any remedies/checks? 21.11.59 Quit phanboy4 (Read error: Connection reset by peer) 21.12.47 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 21.13.03 # restart the client 21.13.43 # If that's the best solution, then I'll do it later. 21.13.56 # I'd rather not abort these file transfers right now. 21.14.30 # (a) the client, not the PC, and (b) there are problems with the build server right now 21.14.44 # Ah. 21.17.33 Quit linuxstb (Ping timeout: 258 seconds) 21.25.00 Join huelk_ [0] (~huelk@2001:4c50:ffff:a9a0:224:21ff:fe8d:132d) 21.27.22 Nick kadoban__ is now known as kadoban (~mud@cpe-67-247-80-129.rochester.res.rr.com) 21.31.16 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 21.32.48 Quit phanboy4 (Read error: Connection reset by peer) 21.36.19 Quit robin0800 (Remote host closed the connection) 21.36.29 Quit linuxstb (Ping timeout: 252 seconds) 21.42.55 # Torne: on my gigabeat F font loading doesn't seem to take very long 21.43.30 # loading sbs and wps however... 21.44.22 # odd 21.45.05 Quit pamaury (Quit: Page closed) 21.45.33 # ah, dircache slows it down 21.46.06 # you're using the bootchart? 21.46.41 # http://www.evonet.be/~gevaerts/logf-dircache.txt and http://www.evonet.be/~gevaerts/logf-no-dircache.txt 21.46.44 # yes 21.47.26 # holy crap that's slow 21.47.41 # i guess that's not cabbiev2 21.47.47 Join yosafbridge [0] (~yosafbrid@li14-39.members.linode.com) 21.48.10 # no. It's http://themes.rockbox.org/index.php?themeid=258&target=gigabeatfx 21.48.16 # Do you want results with cabbiev2? 21.48.19 # but yeah, wjy does it take 100x longer to load a font for me? 21.48.24 # :) 21.48.54 # well, i don't desperately want any results, tbh ;) 21.49.20 # i thought it had gotten slower for me too but it turns out i'm mistaken 21.49.37 # so, i can't really reproduce this slowdown other people are experiencing.. 21.49.47 # for me it's just dominated by the fact that font_load takes an eternity 21.50.01 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 21.50.05 # but it's always done that, i went back nearly 2 years and it made no difference 21.52.16 # http://www.evonet.be/~gevaerts/logf-cabbiev2-dircache.txt and http://www.evonet.be/~gevaerts/logf-cabbiev2-no-dircache.txt 21.52.43 # wait, but cabbie doesn't even have an sbs 21.53.08 # the dircache load *really* messes that up 21.53.16 # which it doesn't seem to for me 21.53.34 # yes, three seconds to not load an sbs seems excessive 21.53.35 # dircache makes no measurable difference to boot time for me, as long as it's not loading dircache in the foreground 21.53.48 # for me it's just 6 seconds for font, then 1.5s for wps 21.53.52 # regardless of dircache 21.54.03 # fragmentation? 21.54.05 # and then maybe 1.2s for everythign else, total time under 9 secs 21.54.12 # for who? 21.54.24 # mine can't be very fragmented.. i have the first ~500mb of the disk reseved for rockbox 21.54.38 # i do install/remove builds quite often but i can't see how it could get very fragmented. 21.54.41 Quit xiainx (Ping timeout: 248 seconds) 21.54.54 # My disk could be fragmented. I actually don't know 21.55.05 # i'm leaning towards "font_load is provoking worst case behaviour of the sector caching thing" 21.55.16 # which is why i see it on 5.5G and nobody else sees it on other devices 21.55.25 # ah, right. That's there as well... 21.55.39 # but yeah, maybe your disk is fragmented, i dunno 21.55.41 # mien isn't 21.56.01 # i formatted the disk recently, put on a large padding file to occupy the start, rsynced music, then deleted padding and installed rockbox 21.56.10 # music fils ahve never changed, so i should have basically no fragmented files at all 22.05.32 # No fragmentation where it could hurt. Some audio files are fragmented, but nothing in .rockbox 22.10.51 Join Tomis2 [0] (~Tomis@70.134.100.179) 22.12.10 Quit huelk_ (Ping timeout: 260 seconds) 22.13.12 Quit Tomis (Ping timeout: 260 seconds) 22.13.12 Nick Tomis2 is now known as Tomis (~Tomis@70.134.100.179) 22.13.33 # When was the slowdown rumoured to have occured again? 22.14.42 # around the addition of sbs 22.15.53 # ok, so october more or less 22.17.22 # Looking at my numbers, that could be misleading. When using dircache the sbs load does indeed add 3 seconds, but that's only 0.3 seconds without dircache. The main problem is that dircache slows everything down so much... 22.17.40 # moos named r23258 22.17.45 # Of course I now fully expect someone else to come with another set of numbers where something else is slow :) 22.19.20 # I think Llorean at least has some numbers which pointed towards dircache too but I can't remember if the theory still stands 22.19.56 # s/has/had 22.21.10 Join perfectdrug [0] (~marko@p5B0EDA4D.dip.t-dialin.net) 22.22.28 Quit pixelma (Disconnected by services) 22.22.28 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 22.22.44 Quit amiconn (Disconnected by services) 22.22.46 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 22.22.47 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 22.23.08 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 22.23.13 # pixelma: I don't know what the theory is. 22.23.42 # I just know that when I disable dirache it boots fast. When dircache does the foreground scan with a splash, it boots fast. When dircache does a background scan during boot, it boots measurably slower. 22.24.21 # This could be because of something else occurring during the scan, or it could be dircaches fault. I don't really have the knowledge about what goes on during boot to hypothesize about causes. 22.24.53 # I really don't think the foreground scan should result in a shorter boot though. If that's the case, it should just always do it. 22.26.43 # OK, I have no idea if this is correct or safe, but moving init_dircache(false); to the end of init(); in main.c seems to fix things. It then boots in no-dircache time again, with the disk staying busy for a while longer 22.27.27 # So that just delays the start of the background dircache scan? 22.28.08 # probably. Well, it does, but I don't know if it has other bad effects 22.29.24 # Llorean: well, i committed the boot charting patch 22.29.27 # Llorean: so you can try that? :) 22.30.34 # It sounds like gevaerts may have a solution (or at least, general area to look for one) already. But how do I use it? I can try to get more information later if needed. 22.30.53 # I'm definitely not convinced that this is a solution 22.31.40 # Llorean: boot charting? it's an advanced option in configure 22.31.49 # Llorean: hit advanced, then b for bootchart 22.31.51 # Llorean: I wasn't sure if you could still trsce it back to dircache or if you found something else in the meantime or if there was something which mislead you. Maybe I put it wrong but also wanted to get your attention to report yourself :) 22.32.07 # then once it boots, it just stores it in logf, you can dump it to a file from the debug menu 22.32.20 # Sounds plenty straightforward. 22.32.26 # that was the idea 22.32.27 # :) 22.32.44 # the last number on each line is the time in centiseconds 22.33.43 # gevaerts: Well it seems to "solve" the problem, so it's at least a workaround assuming it's not likely to cause other problems. Who do we ask about that? 22.34.51 # slasheri or pamaury I guess 22.34.58 # Someone who knows how dircache works 22.35.09 # we should probably see if we can trace this back, also 22.35.14 # where by we i mean you 22.35.22 # since it doesn't seem to have a problem on my ipod 22.35.28 # well not *this* prob blem 22.35.28 # :) 22.35.43 # Did you post your trace somewhere? 22.35.50 # Torne: If it's apparently dircache making other things take longer, that's not new / unexpected, is it? It's just that more other things were added to occur while dircache ran. 22.36.00 # True 22.36.04 # gevaerts: no, i ahven't posted mine 22.36.10 # I'm not sure what you'd trace it back to. 22.36.17 # Llorean: well, i guess. 22.36.41 # it makes sense to kick the backgronud stuff off *after* we've done all the foreground stuff.. 22.36.49 # Was the WPS loaded at boot back in the pre-sbs days? 22.37.00 # since the dircache scan won't've managed to get far enough to actually help by then, prob ably 22.37.03 # so it's just a hinderance 22.37.22 # Well, it will suddenly start interfering more with buffering if we just postpone it 22.37.37 # but it's not postponing it by a lot, though, is it? 22.37.49 # if loading the sbs/wps only takes <1sec when it's done before dircache.. 22.37.50 # 10 seconds :) 22.37.55 # then we're only delaying it by 1 second 22.38.06 # And even if it interferes with buffering a little bit, shouldn't music still start more or less immediately? It doesn't wait for a full first buffer, does it? 22.38.07 # yes, true 22.38.24 # I'm not sure it matters if the first buffer takes 5 seconds longer, as long as the user doesn't see playback starting noticeably later. 22.38.45 # And, in this case, possibly earlier because of the shortened boot 22.39.03 # The basic problem is that we don't have a proper IO scheduler 22.39.34 # And no crystal-ball function 22.39.37 # heh 22.40.28 # hm, could the dircache building thread just back off for 100ms (or any other random number) whenever unrelated disk access occurs? 22.40.58 # That way it should get out of the way immediately during buffering or wps loading 22.45.16 # * gevaerts isn't sure if he wants to think about the added weird code interdependencies involved 22.45.27 Join Tomis2 [0] (~Tomis@70.134.99.192) 22.46.12 Quit Tomis (Read error: Connection reset by peer) 22.46.12 Nick Tomis2 is now known as Tomis (~Tomis@70.134.99.192) 22.50.02 # Basically store the current tick and current thread from *_write_sectors() and *_read_sectors(), and provide a function to get those, or check them. 22.50.10 # Or possibly do this in the FAT code 22.54.16 # hm, we do have storage_last_disk_activity(), so we only miss the thread info I think, unless the dircache code could derive that from looking at the activity numbers 22.54.38 Join Tomis2 [0] (~Tomis@70.134.89.152) 22.55.35 Quit Tomis (Ping timeout: 246 seconds) 22.55.36 Nick Tomis2 is now known as Tomis (~Tomis@70.134.89.152) 23.00.53 Join piepiepie [0] (~colson@adsl-222-183-164.clt.bellsouth.net) 23.00.57 *** Saving seen data "./dancer.seen" 23.01.08 # Hello. 23.01.22 Quit piepiepie (Client Quit) 23.02.24 Join ClosetotheEdge [0] (~4c402893@gateway/web/freenode/x-ssuuorbjaeocpeyw) 23.02.29 Join xiainx [0] (xiainx@wpa058006.Wireless.McGill.CA) 23.03.02 # Hey, how's it going? I was wondering, I have a question about downloading a new revision but it seems to be stalled on the website. r25425 23.03.13 Join AlexP_ [0] (~ap@rockbox/staff/AlexP) 23.03.18 Quit AlexP (Read error: Connection reset by peer) 23.03.18 Quit xiainx (Client Quit) 23.03.25 # Is there a way I can get the files on the revision otherwise or manually add the changes in this revision to my player? 23.03.55 # http://svn.rockbox.org/viewvc.cgi/trunk/firmware/target/arm/as3525/sansa-fuzev2/button-fuzev2.c?revision=25425&view=markup&pathrev=25425 23.04.02 Quit evilnick_B (Quit: Page closed) 23.05.02 Quit efyx (Quit: Quitte) 23.05.49 # ClosetotheEdge: you can build yourself, yes. There's an issue with the build server right now, which should be resolved soonish 23.06.02 # How do I go about building in the changes? 23.07.34 Join kio [0] (~kio@38.98.68.19) 23.07.36 # http://www.rockbox.org/wiki/SimpleGuideToCompiling 23.07.58 # just want to say thank you. :) 23.08.00 # Thank you 23.08.18 Quit dionoea (Ping timeout: 276 seconds) 23.08.20 Join dionoea [0] (~dionoea@yop.chewa.net) 23.10.48 Join mapi [0] (~mapi@KHP222006067242.ppp-bb.dion.ne.jp) 23.12.07 Quit ClosetotheEdge (Quit: Page closed) 23.15.04 # wow 23.15.19 # * gevaerts 's idea seems to work spectacularly well 23.16.35 # oh? 23.17.49 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 23.18.06 # Well, with the standard build and dircache, you've seen the bootchart. With my earlier change (delay dircache init), it boots faster, but if I then start playback immediately, I still have to wait 10 or more seconds to actually get sound 23.18.26 # With my new changes, it boots fast, and playback starts right away 23.18.36 # That sounds very hopeful 23.19.01 # Hey, where's the "attach file" gone to on flyspray? 23.19.19 Quit anewuser () 23.19.37 # http://www.evonet.be/~gevaerts/dircache_backoff.diff 23.19.42 # can we do the same for tagcache load-to-ram? 23.19.50 # Oh, definitely 23.20.14 # Early code without much attention to doing things cleanly, and only for ata, but it works 23.22.41 # the time for me to reach playback is substantially more than the time to get to root_menu() 23.22.57 # so, yeah, i suspect i am also being impeded by this 23.23.05 # and it just happens that for some reasno the wps load isn't very badly affected 23.23.18 Quit GeekShadow (Ping timeout: 245 seconds) 23.23.28 # Well, have a go with this thing :) 23.23.41 # later 23.24.40 # I'd put it on flyspray, but that seems to be a bit broken right now 23.25.07 Join anewuser [0] (anewuser@unaffiliated/anewuser) 23.25.37 Join efgpinto [0] (~dexter@193.136.33.132) 23.26.27 # * gevaerts uploads a new version that should be fully correct, instead of mostly 23.27.20 # well i'm glad i did the chart code now ;) 23.27.20 # Hi there... I'm really interested in applying for GSoC at rockbox.. But, I've some doubts about it... 23.27.53 # efgpinto: welcome! 23.28.20 # Torne: well, I don't actually need chart code to see a difference between ten seconds and one :) 23.28.36 # gevaerts: well no ;) 23.28.57 # i seriously had no idea it was font loading making mine slow though 23.28.57 # efgpinto: what sort of doubts? 23.29.05 # and it's at least a hint where to look :) 23.29.06 # Is it possible to test rockbox without having an compatible mp3 or whatever? 23.29.25 # efgpinto: yes, we do have simulators that run on a PC 23.29.47 # They're not emulators though, so depending on what sort of project you're applying for, you may still need a physical player. 23.31.14 # oh ok... That nice.. Honestly, I was thinking about one of the secundary projects... 23.32.27 # I feel really confortable with C/C++, so I think those fit better my knowledge and experience.. 23.33.35 # Well, most project ideas are C 23.33.51 # What did you have in mind? 23.35.29 # is there a good argment for not turning LBA48 on for all the ATA-based platforms? it takes 300 bytes and it means upgraded disks will Just Work. (also it means you can possibly do larger DMA requests) 23.36.05 # Torne: I think not any more. I'd guess that the argument was mainly that they were pretty uncommon 23.36.21 # FS#11167 23.36.22 Nick dmb__ is now known as dmb (~Dmb@198.138.209.17) 23.36.28 Quit dmb (Changing host) 23.36.28 Join dmb [0] (~Dmb@unaffiliated/dmb) 23.37.36 # gevaerts: what player are the numbers for mentioned in 23.37.46 # FS#11167? 23.37.50 # bluebrother: ah, right. Gigabeat F 23.38.08 # gevaerts: i also need to look at if we can detect the broken 5.5G-style hard driv es and not do sector emulation for them 23.38.14 # gevaerts: but i need to test that 23.38.41 # gevaerts: it should work on any target using ata, i.e. all hdd players, right? 23.38.47 # yes 23.38.59 # Well, except the elio 23.39.03 # nice. Will try to check it out on my hdd targets tomorrow morning 23.39.22 # especially the mr100 could be interesting as that has a really slow disk 23.40.46 # It should be easy to extend to work on all players, but I'm a bit tired right now. I'll try to do that tomorrow evening 23.41.04 # gevaerts: I was thinking about... Rockbox Playback Test Driver or Clean up the radio code 23.42.04 # efgpinto: ah, right. I don't know much about those... 23.42.29 # You need saratoga or JdGordon respectively (unless I remember wrong) 23.47.14 # Torne: if we add this backoff mechanism to more than one thread we have to be careful that they don't start waiting for each other 23.47.16 # tks anyway gevaerts 23.47.25 # gevaerts: Heh, indeed 23.47.38 # gevaerts: do dircache/tagcache load in parallel, btw? 23.47.44 # because that seems like a bad idea *anyway* 23.47.51 # If they both load in background, I suspect so 23.47.56 # * gevaerts doesn't actually know 23.48.00 # that doesn't seem like a winning design, if so 23.48.05 # :) 23.53.19 # Maybe a priority scheme? bool storage_is_busy_elsewhere(int prio) ? 23.53.39 # hm, not that easy 23.54.20 # well if dircache and tagcache *do* load at once then i would suggest we make them, er, not do that 23.54.23 # which solves the problem :) 23.54.43 # i would assume that loading dircache is more important, but i could be wrong 23.55.54 # Well, people who use the database can't start playing until the database is ready. I don't know the implications on that from RAM loading 23.56.53 # The problem I see is that the design basically allows both to suddenly decide to reload things. They currently do that at boot, and presumably on usb disconnect 23.58.05 # Doesn't having dircache available make the database scan significantly quicker? 23.58.31 # Yes, but it's not only the scan, it's also the loading to RAM