--- Log for 11.08.109 Server: simmons.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 2 months and 9 days ago 00.00.08 # linuxstb: as naked as the fuze in that picture http://alhaz.fttp.xmission.com/gallery/8-3-09/IMG_0119 00.00.40 Join truthtaco_ [0] (n=truthtac@adsl-74-10-158.aby.bellsouth.net) 00.01.08 # The LCD looks fine there - i.e. there is an area of black between the top and the case. 00.01.39 # New commit by 03kugel (r22245): Remove the comment also, Thanks to Rafaël Carré for spotting. 00.02.02 # linuxguy3: that's not my fuze 00.02.19 Join JdGordon [0] (i=209e4215@gateway/web/freenode/x-64c08d380b5b30e1) 00.02.46 Quit petur (Remote closed the connection) 00.03.06 # but, the going by the angle, it looks like at least 1 or 2 rows would also be cut off on that one (the black border between the red case and the display is from the case and you can't look through it) 00.05.20 # linuxguy3: sorry for miss-pinging, I meant linuxstb 00.07.28 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 00.11.51 Join saratoga [0] (i=9803c6dd@gateway/web/freenode/x-43de72077fb3971f) 00.12.09 # for what its worth my fuze probably cuts off the top pixel, though if i tilt it enough i can more or less see them all 00.13.37 Quit bluebrother ("leaving") 00.14.12 Part toffe82 00.14.46 Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) 00.17.09 Quit TruthTaco (Read error: 110 (Connection timed out)) 00.18.54 # build-in-progress indicator now added 00.20.58 # That's my fuze. And yeah it's a design issue - there's a black border that covers the first line or so of pixels depending on how you angle it. 00.21.31 # does this also happen in the original firmware? 00.21.50 Quit JdGordon (Ping timeout: 180 seconds) 00.22.29 # New commit by 03zagor (r22246): Added saving round information to db. Fixed bug in client speed calculation. 00.22.33 # yeah, they just don't print anything of consequence up there iirc 00.23.21 # To be fair all of my fuzes are composites built from parts of other fuzes - but i could check the 5 other fuzes i have and see if they have the same feature 00.24.20 Quit LambdaCalculus37 ("This computer has gone to sleep") 00.24.51 Quit Zagor ("Clint excited") 00.25.50 # bertrik: In the OF the top row of pixels is unusually bright, probably due to backlight optics. They use a fairly big blue border at the top, so this occult bezel could have been intentional 00.27.42 # I mean the top bar of their 'while playing' screen is pretty wide compared to most rockbox WPS 00.28.36 Quit tvelocity (Remote closed the connection) 00.30.28 # ok, hard to take stuff like that into account in rockbox in a clean way ... 00.31.50 Nick DarkSpectrum- is now known as DarkSpectrum (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 00.31.54 # Yeah. If someone uses the status bar at the top it could potentially annoy 00.34.30 Join HBK- [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 00.34.42 # There are certainly 2 versions of the fuze case (one version has three screws holding down the board, the other has two screws and a post) but i haven't noticed two versions of the LCD 00.36.03 Quit ender` (" The reason they call it the American Dream is because you have to be asleep to believe it. -- George Carlin") 00.38.30 Quit gregzx ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]") 00.40.09 Quit KBH (Read error: 60 (Operation timed out)) 00.42.17 Quit evilnick ("Page closed") 00.43.47 Quit darkhamm (Connection timed out) 00.44.55 # kugel: In case there was any curiosity, i can verify that r22245 fixes fs#10486 on my fuze 00.45.21 Quit JdGordon_ ("Page closed") 00.47.12 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 00.51.28 Quit pixelma_ (" .") 00.53.27 # ej0rge: thanks, but I was quite confident that it fixes the problem 00.53.33 # I have a fuze too :) 00.54.16 # ahh 00.54.34 # bertrik: I don't think we should take it into account any further 00.54.45 # Well I'm a QA guy. It's not that we're untrusting, it's that we have a compulsion to verify. 00.54.58 # :D 00.56.36 # kugel, ok agreed 00.56.39 # I may BELIEVE that something works, but if it breaks down the road i want to be able to say "It worked when i actually tried it" 00.56.49 # and not "dur, uh . . . " 01.02.19 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 01.04.14 Quit faemir ("Leaving") 01.05.34 # would making crossfade a compile time option be attractive? 01.05.45 Quit captainkwel ("Page closed") 01.05.50 # i'm thinking it might be nice to do so that it can be disabled on low memory targets like the clip where it doesn't work anyway 01.06.44 # saratoga, any idea how easy it is to make it a compile time option? 01.06.53 # bertrik: rather hard 01.07.03 # its quite deeply embedded into both playback and buffering 01.08.07 # of course since the feature doesn't work on the clip anyway, it can be done incrementally with the obvious parts removed first until nothing is left 01.11.08 # Does it only cause problems when enabled, or does any the code itself cause issues? I'm assuming you have a smaller PCM buffer? 01.11.35 # I wouldn't mind it being a compile option, but I can't oversee the consequences yet 01.11.37 # it only causes problems when enabled (it breaks playback entirely I believe) 01.11.56 # mostly i was thinking about memory savings on low memory targets like AMS and TCC 01.12.05 # though I admit i don't know if it saves enough to be worthwhile 01.12.19 # i presume it allocated memory only after its enabled right? 01.12.32 *** Saving seen data "./dancer.seen" 01.12.38 # I've no idea, I've never enabled it... 01.12.49 Quit DarkSpectrum () 01.14.35 # it works without a reboot, so I guess its not allocating anything 01.15.12 Join DarkSpectrum [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 01.15.28 Quit bertrik ("sleep") 01.16.26 # I would imagine it just relies on a large enough PCM buffer - that's the only memory it needs. 01.17.23 # <[1]nifty> well there is a booter 01.17.33 # <[1]nifty> and a manipulator to get the firmware running on ipod touch :) 01.17.36 # <[1]nifty> just informing 01.17.49 # * linuxstb can understand crossfade being embedded into the playback code, but why buffering? 01.18.47 # * linuxstb can't see any references to crossfade in buffering.c 01.20.06 # crossfade is in the buffering code?! 01.20.39 # pcmbuf rather 01.20.49 # not disk buffering 01.20.51 # thats completly different 01.21.03 # it takes up a substantial fraction of pcmbuf.c actually 01.21.15 # i wish we hadn't allowed it to become so intertwined with basic pcm buffering 01.21.41 # is that you volanteering to seperate them? :) 01.21.57 # :) 01.22.28 # well i have to run, still i'd be interested in knowing if having a compile time option for it is considered worthwhile 01.22.33 # might be more ifdef mess then its worth 01.23.14 # speaking of which.... is it techinally possible for the output volume to gradually change up/down between tracks if they arnt about the same volume? 01.25.11 # How can you "gradually change" "between tracks? There is no time between tracks. 01.25.44 Join fyrestorm [0] (n=nnscript@cpe-24-90-84-159.nyc.res.rr.com) 01.25.49 # volume normalizeing cross fading i think he means 01.26.18 # Wouldn't replaygain do that already? 01.29.04 # yeah, DarkSpectrum got it 01.29.32 # i dont want to actually do anything to my tracks... just not go deaf when going from a very quiet track to a loud one 01.32.48 # Wouldn't replaygain do that already? 01.36.54 # dont you need to modify the files to do it? 01.37.06 Quit bmbl ("Bye!") 01.39.57 Join moos [0] (i=mustapha@rockbox/staff/moos) 01.42.32 Quit truthtaco_ ("Leaving") 01.43.49 Quit efyx (Remote closed the connection) 01.45.54 # JdGordon: You add replaygain info to the tags. So it depends on your definition of modify... 01.46.13 # yeah, ok 01.46.20 # oh well 01.47.23 Join ehntoo [0] (n=ehntoo@adsl-99-156-195-44.dsl.applwi.sbcglobal.net) 01.54.25 Quit Thundercloud (Remote closed the connection) 02.00.58 Quit Rondom (Nick collision from services.) 02.01.09 Join Rondom [0] (n=Rondom@dslb-084-057-173-035.pools.arcor-ip.net) 02.01.16 # have we got a byte->hex function in rockbox anywhere? 02.05.16 # will http://pastebin.com/m6e1072dc work? 02.05.22 # * JdGordon is half asleep 02.09.00 # * JdGordon cheats and copies printf's MUCH simpler way of doing it :p 02.11.31 Quit linuxstb (Read error: 110 (Connection timed out)) 02.15.52 Join CaptainKwel [0] (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 02.17.24 # do we have a tool for checking bin size changes? 02.17.53 # utils/analysis has 2 02.18.27 # is either preferable to the other? 02.19.51 # bloot-o-meter is a bit nicer output 02.22.22 Quit jgarvey ("Leaving") 02.33.29 # does anyone know who the face in http://www.rockbox.org/twiki/pub/Main/TowerOfRockbox/empirerockboxbuilding.jpg is ? 02.35.45 Join Strife89 [0] (n=michael@adsl-146-208-210.mcn.bellsouth.net) 02.44.56 Quit GeekShadow ("The cake is a lie !") 02.51.19 Quit stripwax ("http://miranda-im.org") 02.53.52 # actually disabling most of the crossfade code is pretty easy and saves almost 1.5KB extra so I think i'm going to do it 02.56.33 # only 4 ifdefs to do it :) 02.58.41 # why are you remoinving it? 02.58.45 # just because? 03.00.16 # its dead code on low mem targets, so i don't see any sense in leaving it in 03.00.28 # gevaerts: the PF renderer at present can't handle tilting slides around a horizontal axis. tilt on one axis or the other might be possible without *huge* code bloat. 03.00.42 # i can post the patch on the tracker for review 03.05.27 # actually, tilt-either-way might be a good idea *anyway*, to allow for rotating the display (pictureflow is *much* nicer in landscape than portrait layout). the whole display could be rotated without changing cache layout. tilting a non-rotated image on the other axis without more math would require storing both transposed and non-transposed copies of each slide in cache, and i'm not sure what 2D scrolling would want to do with slides in th 03.05.27 # ... 03.07.17 # slides in th 03.07.22 # ... 03.08.06 Quit yawnage ("leaving") 03.08.17 Join yawnage [0] (i=user36@i.am.at.war.with.firewar.us) 03.09.11 # New commit by 03saratoga (r22247): Disable crossfade menu option (but nothing more) on lowmem (<=2MB) targets because it apparently needs a larger PCM buffer then is available. 03.11.07 # saratoga: removing the menu saves 1.5K and 4 ifdefs? or from pcmbuf? 03.11.58 # also... those should maybe be changed to HAVE_CROSSFADE, that deing defined in config.c for  #if CONFIG_CODEC == SWCODEC && MEMORYSIZE > 2 03.12.36 *** Saving seen data "./dancer.seen" 03.15.56 # JdGordon: yes I was thinking that as well, though I wasn't sure if its preferable to have it in the config files or not 03.16.06 # the menus save 400 bytes 03.16.26 # removing some of the cross fade code saves another 1700 bytes or so 03.16.38 # I think something like crossfade where we want it on every target that can have it, it should go in config.h like dircache (iirc) 03.17.27 Join bubsy [0] (i=Bubsy@94.139.72.137) 03.17.51 # yep, line 610 is what happens for dir/tag caches 03.19.59 # the build system says the savings is much larger then bloat-o-meter 03.21.51 # JdGordon: gevaerts suggested 2D scrolling in PF... in the other channel, so perhaps he was joking. it may not be a *completely* stupid idea, though. :) 03.22.46 # saratoga: i don't think those tools account for any alignment padding at all, so they may be leaving out quite a bit of space if we have targets where function or symbol alignment is larger than one instruction or one int. 03.23.04 # also, some of the targets have rather large section alignments, i think? 03.24.02 # Unhelpful: I was saying you got cut off... 03.24.34 Join TruthTaco [0] (n=truthtac@adsl-74-10-158.aby.bellsouth.net) 03.24.38 # JdGordon: in the corners. weird, xchat split overlong messages. :/ 03.26.04 # Unhelpful: not very well 03.26.56 # rasher: yes, but at least people could figure out what i was saying when i used xchat. quassel doesn't tell me i'm over any limit, and i can't see that my message was truncated. 03.27.36 # Ah, you're not using xchat. I thought you were saying it was supposed to do it for you 03.31.07 # FS#10506 - Don't compile crossfade on lowmem targets 03.37.32 # saratoga: I think it should be HAVE_CROSSFADE, defined somewhere in the beginning of pcmbuf 03.38.03 # kugel: in pcmbuf? 03.38.16 # yea 03.38.32 # based on memory size? 03.38.38 # also, it seems you missed *crossfade_chunk, ir is it used elsewhere? 03.38.40 # yea 03.39.35 # not in pcmbuf 03.39.38 # in config.h 03.39.38 # kugel: its used elsewhere and I prefer not to cut up functions with preprocessor junk to save a few bytes 03.41.47 # MEMORYSIZE > 2 is definetly not the way to do it :) 03.42.43 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 03.42.53 # With my sansa e260v1, USB only works the second time I plug it in after powering on. Is this a known bug? 03.43.12 # it doesn't enumerate on the bus the first time I plug it in, but shows the "USB Mode" screen 03.43.18 # this using the latest daily build. 03.43.20 # JdGordon: why? 03.43.28 # but if I re-plug it, it shows up fine 03.43.39 # tested on vista, XP, and linux 03.45.21 Part kkurbjun 03.48.20 # i tend to think the config files are neater as well 03.48.34 # kugel: why what?> 03.49.19 # * Dhraakellian svn ups (svns up?) and compiles 03.49.22 # i just don't feel like editing 50 of them 03.49.50 # JdGordon: I was refering to your last sentence 03.50.12 # saratoga: I think he was saying config.h, not each config-target.h 03.50.46 # kugel: ok, what does MEMSIZE > 2 actually mean? think about coming back to this code in 3 months and try to figure out... 03.50.56 # HAVE_BLAA is 100000x more understandable 03.51.02 # well i did put a comment explaining it 03.51.12 # and yes, I did mean a single #if in config.h not in each targets config 03.53.41 # yea, I can agree with that 03.56.46 # i guess I should change the stuff in settings too? 03.58.28 # what's the status of the e200v2 port? roughly on par with the FuzeV1 port overall? 03.59.30 # pretty much 03.59.37 # check the current status link on the front page 04.00.25 # yeah, I saw that they have pretty much the same greens and reds in the table 04.01.24 # I just thought I remembered seeing some stuff in the test build thread and such about different sets of issues compared to the Fuze 04.01.29 # I could be misremembering 04.02.22 # i think you are 04.02.42 # good to know without having to reread the entire thread 04.02.58 # ok i'm going to commit the crossfade stuff now 04.05.42 # New commit by 03saratoga (r22248): FS#10506. Don't compile various crossfade only functions in pcmbuf.c on low memory targets (mainly AMS) to save memory. Some crossfade related items ... 04.06.08 Quit TheSeven (Nick collision from services.) 04.06.10 # for what its worth, my clip still deadlocked after an hour with these changes, so crossfade was unlikely to have been the source of our playback problems 04.06.24 Join The_Seven [0] (n=theseven@dslb-084-056-175-088.pools.arcor-ip.net) 04.06.28 Nick The_Seven is now known as TheSeven (n=theseven@dslb-084-056-175-088.pools.arcor-ip.net) 04.09.22 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 04.10.13 # * kugel wonders where you still can enable (or try to...) from a settings file 04.11.02 # you should be able to 04.11.29 # but it'll just crash as before 04.11.46 # i don't like how the new build system shows all reds until the build finishes 04.11.49 # its a bit unnerving 04.12.11 # yea that was weird 04.12.20 # woot 1750 bytes saved 04.13.21 # saratoga: you also deactivated replaygain and beep? 04.14.08 Quit Strife89 (Read error: 110 (Connection timed out)) 04.14.28 # http://svn.rockbox.org/viewvc.cgi/trunk/apps/settings_list.c?r1=22247&r2=22246&pathrev=22247 < that diff suggests that, And I think loading it via config.cfg shouldn't be possible if the code doesnt run (deactivated in pcfbuf.c) 04.14.48 # hmm that is wrong 04.14.50 # i'll fix it 04.18.41 # New commit by 03saratoga (r22249): Fix defines from the last commit that made replaygain depend on crossfade. Thanks to Thomas Martitz for pointing that out. 04.19.21 # rockboxdev.sh works on cygwin right? 04.22.46 Quit ehntoo (Read error: 110 (Connection timed out)) 04.29.59 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 04.38.17 Join darkhamm [0] (n=darkhamm@host106-36-dynamic.50-79-r.retail.telecomitalia.it) 04.50.47 # saratoga: did that config.h change get into a #if SWCODEC block? 04.51.19 # probably not, but it should never occur in code thats compiled elsewhere 04.51.47 # unless we do crossfade on hwcodec? 04.52.45 # i dont know.. 04.53.05 # probably would have been beter with the SWCODEC check.. but deltas suggest nothing changed so maybe dont worry 04.54.55 # yeah pcmbuf.c is swcodec only 04.58.47 Join Blue_Dude [0] (n=chatzill@adsl-235-206-199.mco.bellsouth.net) 04.59.15 # Hi. Anyone have a chance to check out my patch to test_codec? 05.04.50 # Blue_Dude: i'll take a quick look at it now, but i probably shouldn't be the one to commit 05.05.31 # OK. It adds a DSP benchmarking and wav writing function, as requested. 05.06.40 # whats the advantage of flipping around that enum? 05.07.42 Quit Zarggg () 05.08.44 # It now reads in sequential order. Easier to see what "convert" is actually addressing. 05.11.26 # Blue_Dude: is there anyway to disable the screen fadeout while running test codec? 05.11.46 # I don't know. It does fade back in when done though. 05.12.39 *** Saving seen data "./dancer.seen" 05.13.20 # yeah i just wasn't sure how much cpu that uses 05.13.22 # doesn't matter for now 05.18.10 # so DSP uses about 2 MHz as we suspected 05.18.17 # if everything is off 05.19.02 Quit rasher (Read error: 60 (Operation timed out)) 05.21.41 # I've only tried running it on target once. I was doing a before/after of a dsp.c change, not really looking at DSP/non-DSP. There is some overhead but I didn't write down how much. 05.23.44 Join rasher [0] (n=rasher@0x5550f5a3.adsl.cybercity.dk) 05.23.45 # i wonder why dsp only takes interleaved audio when nearly all codecs internally work on seperate channels 05.24.10 # Blue_Dude: this looks fine to me 05.24.17 # did anyone else comment on it? 05.25.24 # No. I put it in three days ago. I'm a little surprised since it's apparently been on the wish list for a while. 05.25.51 # not many people work with codecs, and even fewer of them are around these days 05.26.20 # i'll ask around tomorrow and if no one else says anything i'll commit it then 05.26.27 # k. 05.27.35 # As for the interleaved audio, I think it's because that way you don't have to reserve separate buffers for each channel. ??? 05.28.18 Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 05.30.39 # Blue_Dude: yeah but it would be nice to have put that in DSP originally, instead of us having 2 dozen seperate functions to handle it 05.31.21 # also, what target are you using? 05.31.30 # DSP does seem pretty patched together. But it's relatively easy to add new functions though. 05.31.38 # Sansa E280 05.31.44 # ah ok same as me 05.31.56 # Cool. Nice DAP. 05.31.57 # DSP is one of the cleaner parts of playback 05.32.17 # and generally works pretty well 05.32.25 # the rest of playback though 05.33.06 # Hang on. Duty calls. Back in a few... 05.36.10 Quit Lss__ (Read error: 110 (Connection timed out)) 05.43.02 Quit StealthyXIIGer (Read error: 110 (Connection timed out)) 05.43.25 Quit [1]nifty (" HydraIRC -> http://www.hydrairc.com <- Wibbly Wobbly IRC") 05.44.18 Join kkurbjun [0] (n=kkurbjun@rockbox/developer/kkurbjun) 05.44.25 # Back. Anyway, I thought playback.c and pcmbuf.c were more than a little complex. It works, though I wonder if a rewrite would be more efficient. 05.45.46 # thats been talked about for years 05.46.02 # Yeah, and who really wants to tackle that one? 05.46.12 # i've been reading through pcmbuf.c tonight and its not really too bad once you ignore all the crossfade stuff 05.46.22 # playback is a nightmare though 05.46.51 # I'm pretty well versed in pcmbuf by now. You're dead on there. Playback is much harder to get through. 05.47.06 Quit Horscht ("Verlassend") 05.47.18 # i feel bad for having waited all these years to look at what pcmbuf_insert actually does 05.48.02 # I put that in the black box "don't need to know" category. :) 06.03.48 Quit kugel (Remote closed the connection) 06.04.14 Quit panni__ (Client Quit) 06.04.54 # at some point, wasn't there a state machine type diagram of playback? 06.07.11 # there have been at least 2 i think, showing different parts of it 06.10.40 # i'd be vaguely interested in seeing that 06.13.18 # it will be in the logs somewhere... i cant find it in my downloads.... nico did one 06.13.44 # it'll be really intersting to see what causes the current low memory deadlocks in buffering 06.13.46 # do a search in the logs for his full name (i tihnk thats his webhosting url) 06.13.55 # Was playback actually designed or did it just grow that way? 06.14.13 # mostly grew that way 06.14.24 # though at several points substantial parts of it have been rewritten 06.14.59 # Blue_Dude: it used to be worse! 06.15.09 # That's scary... 06.16.14 # does buffering work more or less the same in the sim? 06.16.37 # file reading you mean? 06.16.45 # I assume its the exact same buffering code 06.16.50 # I had to wade into playback about 6 weeks ago to kill a bug. Took all friggin day and I ended up changing part of a single line to fix it. 06.16.52 # the difference is the disk layer 06.18.08 # i wonder if the lowmemory deadlock problem is reproducible on the sim 06.19.34 # is this the clip issue? or something else? 06.20.34 # yeah 06.20.44 # well its any target with low enough memory 06.21.00 # i can reproduce it on the fuze as well if i shrink the compressed buffer enough 06.21.11 # i think the playback engine has some nasty assumptions about free memory built in 06.21.32 # what do you mean free memory? 06.21.48 # err, buffer memory 06.22.44 Quit bah_ (Read error: 60 (Operation timed out)) 06.22.51 Join bah_ [0] (n=bah@c-76-105-203-173.hsd1.wa.comcast.net) 06.23.46 # you mean an assumption about the minimum space avialble for the buffer? 06.23.58 # yes, or rather the minimum buffer size 06.24.15 # there is a way to find out... a very tedious way.... 06.24.26 # since apparently if you shrink it deadlocks become progressively more common 06.24.41 # mangle playback to work with like 3mb on a 8mb target 06.24.53 # thats what I did on my fuze 06.24.58 # it deadlocks just as the clip 06.38.35 Quit JdGordon (Remote closed the connection) 06.41.25 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 06.48.33 Quit CaptainKwel (Remote closed the connection) 06.48.51 Join bmathis [0] (n=brian@c-71-195-184-199.hsd1.ca.comcast.net) 06.50.53 Join jernejovc_ [0] (n=jernejov@195.250.215.149) 06.53.04 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 07.03.06 Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]") 07.05.24 Join DarkSpectrum- [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 07.05.50 Quit yawnage (Remote closed the connection) 07.05.56 Join yawnage [0] (i=user36@i.am.at.war.with.firewar.us) 07.05.58 Quit jernejovc (Read error: 110 (Connection timed out)) 07.06.15 Quit DarkSpectrum (Read error: 104 (Connection reset by peer)) 07.12.41 *** Saving seen data "./dancer.seen" 07.25.42 Part bmathis 07.28.27 Join fyre^OS [0] (n=nnscript@cpe-68-173-235-106.nyc.res.rr.com) 07.29.39 Quit intrados (Read error: 104 (Connection reset by peer)) 07.31.33 # it should be same buffering code running on the sim 07.31.49 Join stoffel [0] (n=quassel@p57B4CDC4.dip.t-dialin.net) 07.43.17 Quit fyrestorm (Read error: 110 (Connection timed out)) 07.48.37 Join Kumool [0] (n=Khwerz@adsl-72-50-69-137.prtc.net) 07.49.49 Part safetydan ("Leaving.") 07.59.49 # * FlynDice has uSD playing at spec freqs on e280v2 31MHz and 15.5 MHz posting patch to FS 08.05.07 # well done! 08.18.28 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.18.53 Join Rob2223 [0] (n=Miranda@p4FDCD805.dip.t-dialin.net) 08.27.07 Join flydutch [0] (n=flydutch@host214-146-dynamic.15-87-r.retail.telecomitalia.it) 08.36.55 Quit Rob2222 (Read error: 110 (Connection timed out)) 09.03.55 Quit Stephen_ ("Leaving") 09.08.16 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 09.12.06 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 09.12.43 *** Saving seen data "./dancer.seen" 09.26.47 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 09.33.38 Quit scorche (Nick collision from services.) 09.34.25 Join scorche [50] (n=scorche@rockbox/administrator/scorche) 09.35.17 Join petur [50] (n=petur@rockbox/developer/petur) 09.35.54 Quit BHSPitMonkey ("Ex-Chat") 09.37.58 Quit scorche (Read error: 104 (Connection reset by peer)) 09.39.03 Join scorche [50] (n=scorche@rockbox/administrator/scorche) 09.43.34 Quit Thundercloud (Remote closed the connection) 09.50.40 Join pyro_maniac [0] (i=foobar@p57BB9AC8.dip0.t-ipconnect.de) 09.52.59 Join iNobue [0] (n=taokaka@203.96.218.184) 09.53.03 Part iNobue 10.14.03 Join efyx [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 10.28.48 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 10.33.12 Join LinusN [0] (n=linus@rockbox/developer/LinusN) 10.35.09 Quit scorche (Nick collision from services.) 10.35.55 Join scorche [50] (n=scorche@rockbox/administrator/scorche) 10.37.28 Quit kachna (Read error: 113 (No route to host)) 11.02.55 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 11.12.45 *** Saving seen data "./dancer.seen" 11.36.38 Join Lynx_ [0] (n=Lynx@xdsl-87-79-87-228.netcologne.de) 11.53.47 Quit bubsy (Read error: 60 (Operation timed out)) 11.56.38 Quit jernejovc_ (Read error: 60 (Operation timed out)) 12.05.38 Join xavieran [0] (n=xavieran@ppp118-208-193-94.lns10.mel6.internode.on.net) 12.07.01 Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) 12.11.25 Part Spads 12.13.12 Join pamaury [0] (n=pamaury@sal63-1-82-243-96-220.fbx.proxad.net) 12.15.43 Join funman [0] (n=fun@rockbox/developer/funman) 12.17.23 Join Sergg [0] (n=opera@line6-66.adsl.kirov.ru) 12.20.00 Join jernejovc [0] (n=jernejov@195.250.215.149) 12.20.26 Part Sergg 12.25.25 Quit Sajber^1 (Read error: 104 (Connection reset by peer)) 12.26.01 Quit stoffel (Read error: 60 (Operation timed out)) 12.28.27 Quit pamaury ("Quitte") 12.35.03 Quit martian67_ (Remote closed the connection) 12.37.29 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 12.38.12 Quit linuxstb (Read error: 110 (Connection timed out)) 12.39.54 Quit martian67 (SendQ exceeded) 12.40.34 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 12.41.45 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 12.43.31 Join lasser [0] (n=chatzill@W963e.w.pppool.de) 12.45.23 Quit darkhamm ("Sto andando via") 12.47.05 Quit lasser (Client Quit) 12.56.38 Quit jernejovc (Read error: 54 (Connection reset by peer)) 12.56.47 # funman: did you take a look at the yh-920 bootloader? 12.57.10 # i mean had you ever? 12.57.42 # yes, but didn't spend enough time on it for significant results/understanding 12.58.15 # i was comparing the yh925 and the yh920 one 12.58.17 Join jernejovc [0] (n=jernejov@195.250.215.149) 12.58.55 # because both have a codec test programm which look similar to each other 12.59.07 # but there seems to be a different value 12.59.34 # i had found the initialization code that lowlight wrote, but nothing else 13.00.30 # so this codec test doesn't help in finding the error at yh920 sound? 13.01.20 # no idea 13.01.35 # i think looking everywhere is the right thing to do 13.04.44 # i thought this place would be the best because its a small area and better to overlook 13.05.02 # then it makes more sense to study it first 13.05.07 Join darkhamm [0] (n=darkhamm@host106-36-dynamic.50-79-r.retail.telecomitalia.it) 13.10.55 Quit linuxstb (Read error: 110 (Connection timed out)) 13.12.24 Join Jaykay [0] (n=chatzill@p5DDC57E9.dip.t-dialin.net) 13.12.50 *** Saving seen data "./dancer.seen" 13.15.31 # is there any rule how builds should be named? (i just looked at BuildNames) 13.18.15 Join thegeek_ [0] (n=nnscript@s243b.studby.ntnu.no) 13.25.44 # funman. is line-in also handled by codec? 13.26.36 # no idea 13.28.42 # there is a line-in test in the bootloader before the codec test. thats why i am asking. 13.35.10 # logfdump bug report : http://forums.rockbox.org/index.php?topic=22442.0 13.36.40 Quit thegeek_ (Read error: 113 (No route to host)) 13.36.53 Quit thegeek (Read error: 113 (No route to host)) 13.39.52 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 13.44.38 Join pamaury [0] (n=pamaury@sal63-1-82-243-96-220.fbx.proxad.net) 13.47.02 Join AndyIL [0] (i=AndyI@212.14.205.32) 13.47.45 Quit pyro_maniac (Read error: 60 (Operation timed out)) 13.47.52 Quit gevaerts (Nick collision from services.) 13.48.02 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 13.49.47 # Hello, yesterday I wrote on the forum about the logfdump function being buggy (http://forums.rockbox.org/index.php?topic=22442.0). Should I submit a bug on FS or a patch (because the fix sseems simple) ? 13.50.37 # if you know the fix submit a patch 13.50.59 # the patch is already on the forum 13.52.10 # Is it sufficient to have it on the forum ? 13.52.41 Quit jernejovc (Read error: 110 (Connection timed out)) 13.52.50 # it's more likely to be noticed if you submit it to FS. 13.53.24 # and come here regularly until someone takes a look at it :) 13.53.33 # ok. 13.53.33 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 13.55.38 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 13.55.38 # I also wrote a topic about a bug of the usb driver of the sansa e200 (usb-drv-arc). The fix also seems simple but I guess the usb driver is more important than logfdump so I would prefer than someone check that I'm correct 13.55.45 # dircache.c doesn't check volume names (for mkdir("/.." for example) while dir_uncached.c seems to do 13.56.09 # pamaury: that doesn't mean you can't post a patch 13.56.17 # post the patch and state what your concerns are about it 13.56.32 # FS is the right place to put these things, it doesn't have to be a finished piece of work 13.56.49 # patches can be refined until they are acceptable 13.56.54 # ok 13.57.26 # the more of the developers' work you can do for them the more likely it is to get dealt with quickly :) 13.58.38 # hum but dircache only seems to be enabled if there is more than 8MB of RAM (not the case on my Fuze) 13.59.56 Quit AndyI (Read error: 110 (Connection timed out)) 14.00.47 # pamaury: I've just looked at your usb_drv_arc forum post, and I agree that that most likely is the issue. Did you test it? 14.01.08 Quit bzed ("leaving") 14.01.29 Join bzed [0] (n=bzed@devel.recluse.de) 14.02.48 # gevaert: no I have not tested it, I will first submit the logfdump bug because the fix works, then I'll test usb-drv-arc fix 14.04.46 Join stoffel [0] (n=quassel@p57B4CDC4.dip.t-dialin.net) 14.09.38 # i'll test your logf fix in a second (i confirmed the bug at least) 14.10.04 Join thegeek_ [0] (n=nnscript@s243b.studby.ntnu.no) 14.12.39 # I have submitted it. 14.16.48 # pamaury: thanks it works fine, i'll commit it 14.22.07 # New commit by 03funman (r22250): Fix logfdump multilines handling ... 14.23.09 # gevaerts: I have tried to replace the "return -1" by "continue" in the driver and it seems to work: at least it does not breaks anything as far as I can tell and it fixes the inital bug in my code 14.23.18 # pamaury: thanks! 14.23.30 # pamaury: ok. I'll commit that fix later today 14.23.57 # I will submit it to FS anyway 14.27.02 # ok 14.27.35 Quit thegeek (Read error: 110 (Connection timed out)) 14.27.58 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 14.28.09 # funman: you missed the CREDITS part on this commit (salut btw) 14.29.30 # moos: right, gevaerts can you fix it in the next commit? 14.30.14 Join LambdaCalculus37 [0] (i=44a0430d@rockbox/staff/LambdaCalculus37) 14.30.20 # using "//__TEST__" in test_disk.c works fine (leading / was missing) until creat() 14.30.27 # funman: you mean you forgot, and now I have to remember? ;) 14.30.47 # i mean it ! (my tree is dirty) 14.30.47 # haha :D 14.30.51 # * gevaerts thinks that that is cheating! ;) 14.33.21 # is it only on my Fuze's µSD that I can't delete directories ? (i see the busy bar which vanishes after a bit, but the directory stays there) 14.33.42 # and i can't delete files in that directory 14.34.12 # eject/insert/delete directory => unhandled IRQ 00 watchdog 14.35.36 Join panni_ [0] (i=hannes@ip-95-222-19-21.unitymediagroup.de) 14.39.34 # I also have a question about the "logf" entry of the debug menu: on my sansa e200 it truncates lines whereas there is still space available. I've looked at the code and it seems that it computes the number of displayable characters by using the size of 'A'. Is there any reason for that ? 14.40.50 Quit thegeek_ (Read error: 110 (Connection timed out)) 14.42.01 # if characters have different widths, then no 14.42.14 # font_get_width() in font.c seems to say it's the case 14.45.18 # I've seen that there is a lcd_getstringsize function which is used to get the size of 'A'. It should be possible to call it for each line and then to see if it should be truncated or not. It would probably slow down the display but would be more precise. I don't know if it's worthwhile to modify it 14.46.44 # is there a reason for using a variable width font for the logging? 14.46.57 # or is this because rockbox only supports one font? 14.48.26 # This is probably because it uses the default font to display the log and the default font has wariable widths 14.48.58 # not on all targets 14.49.44 # lcd_getstringsize returns the wrong answer if the font is variable width, is why 14.49.51 # iirc 14.50.24 # er, or am i thinking of something else 14.50.47 # doesn't it make more sense for the system font to be used to display the log ? 14.51.43 # oh sorry, i'm thinking of the weird thing with puts 14.52.01 # yes, lcd_getstringsize should work to see where to wrap/truncate the log 14.52.37 # The problem is that if it has to truncate, then it must be called lots of times to determine where to cut 14.52.45 Join robin0800_ [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 14.53.03 # GodEater: the system font is fixed width, and easily usable? 14.53.39 # can't you just print a string that's too long anyway? 14.53.43 # funman: I don't recall - haven't written anything for rockbox is ages :) 14.53.46 # s/is/in 14.53.55 # yes, you can :) 14.54.08 # you can just print it and it will get truncated in the course of lcd_putsxyofs 14.54.23 # which just stops printing characters when it passes the current viewport width 14.54.35 # so if you actually want truncation that's easy 14.55.19 # yes but then there would have a problem with multilines: it add '>' at the end of each intermediate line. If it's truncated, then the '>' is not displayed. Not a big deal though 14.56.23 # technically that's doable anyway 14.56.28 # just go back and print the > afterward ;) 14.56.48 # yes :) 14.56.54 # I dunno. just pointing out that lcd_puts truncates *anyway*. 14.57.58 # The point is: is the system font small enought to display a whole line of log on the screen ? Of at least the majority, otherwise it's useless 15.00.38 # I will try to use the system font on my sansa, to see the result 15.00.46 # second try: > is there any rule how builds should be named? (because of the incosistency documented in BuildNames) 15.01.32 # pamaury: the system font is monospace which *generally* makes it fit less horizontally than the user font 15.01.43 # unless the user has picked a particularly big user font 15.02.06 # Jaykay: no 15.02.27 # the name should be descriptive that's all 15.02.41 # if there's room for 30 chars across the screen in the system font on your target that avoids the whole issue, but i doubt this is the case for all targets 15.02.43 # then we wouldn't need BuildNames 15.02.56 # "...so we can hopefully bring everything in line to make things less confusing. " 15.04.05 # yes, but I have no idea how many chars fit on my target. I doubt there is enough room for 30 chars 15.04.31 # using the system font at least means you will always know exactly how many chars *will* fit. 15.04.50 # but it probably reduces the average number of characters that will fit for most people 15.05.10 # Jaykay: the page is about using the same string for configure target, and downloaded files 15.05.41 # * Torne would go with just printing the whole thing and letting the lcd code truncate it, and using some other way of marking where the line continuations are. 15.06.24 # you could always put the line continuation markers at the beginning of the continuing lines, instead of the end of the continued lines 15.06.59 # It's true that just printing the line and letting the lcd code truncate would really simplify the code 15.07.18 # funman: so the configure names should persist and all the other names should be brought in line with the configure name? 15.08.22 # Jaykay: the configure name can be changed as well 15.08.56 # Torne: putting the marker at the start of newline makes sense 15.09.24 # yes that's true 15.09.27 # gevaerts: did you try modifying test_disk base directory to "//__TEST__" ? 15.09.50 # no 15.09.56 # that's what I was doing but seeing if this approach works fine is disturbed by the AMS-specific bugs 15.10.39 # perhaps i could try with a ramdisk 15.10.53 # funman: tbh preserving the logf 29-char line wrapping on a target that can't fit 29 chars across the screen is kinda doomed to be hard to read regardless :) 15.11.12 # how about just taking the name of the complete series (like sansa, ipod, vx, yh) and the "exact" model name (e200, 4g, 767)... this should be consistent and easy 15.11.25 # for the more-ram-targest just add 64mb 15.11.27 # funman: ramdisk is a bit annoying because you have to format it first, which won't be easy on ams 15.11.52 # Jaykay: so "sansa e200"? 15.11.58 # yes 15.12.03 # * gevaerts thinks he spots a flaw 15.12.36 # gevaerts: where is the problem? 15.12.46 # funman: test_disk works fine on the Ondio's MMC when changing the test dir to //__TEST__ 15.12.47 # Jaykay: *which* sansa e200? 15.12.51 *** Saving seen data "./dancer.seen" 15.13.15 # Jaykay: also, if you don't put in the manufacturer somewhere, you'll get duplicates (e.g. M3) 15.13.23 # If it doesn't work on AMS, there must be a bug in the ams specific driver 15.13.28 # gevaerts: i forgot... when there are different versions then just add the version (v2) 15.13.48 # amiconn: thanks 15.14.04 # there 'must be' no bugs in ams specific driver 15.14.09 # gevaerts: and it would be iaudiom3 and m3, but i see thats not perfect 15.14.17 # there 'are' bugs 15.14.20 # Jaykay: you're back to where we are now then 15.14.45 Join thegeek_ [0] (n=nnscript@s243b.studby.ntnu.no) 15.14.55 # gevaerts: look at the configure names, they're different 15.16.10 # Jaykay: and? 15.16.45 # Torne: I've checked using the system font and 29 characters fit exactly on my target. The result is really small but it's readable 15.16.50 # you said i would be back to where you are now... but the names are now different to my suggestion. 15.16.50 # I can see they are different, but I have no idea why you point to that fact 15.17.12 # so your suggestion is just "let's change the names a bit"? 15.17.13 # Jaykay: perhaps add a column with a proposed names 15.17.15 # pamaury: it technically needs to be 30 though, for the char used for line continuation :) 15.18.02 # well no, iirc MAX_LOGF_LINE=29 and it contains a terminating '0' so there are in reality 28 characters +1 with the continuation one 15.18.26 # gevaerts: exactly... for consistency, BuildNames says there should be consistency 15.18.28 # Anyway, it fir exactly while displaying a multiline so it should no be 30 15.18.33 # *fit 15.19.02 # each logf record is 30 bytes. MAX_LOGF_ENTRY is 29, the last byte is used to indicate whether it's a continuation or not 15.19.03 # Jaykay: what you proposed does not give us consistency 15.19.12 # why not? 15.19.16 # it doesn't have a terminating null, it's padded with spaces 15.19.19 # 15:14 < Jaykay> gevaerts: and it would be iaudiom3 and m3, but i see thats not perfect 15.20.07 # pamaury: your name is written with capitals ? (Amaury Pouly) i'll add you to the credits 15.20.10 # gevaerts: iaudiom3 is consistent, m3 is the only proble... maybe we could take meizu there as the name of the series 15.20.14 # pamaury: the buffer being used in logfdisplay is 31 bytes, to make room for the null. 15.20.18 # *problem 15.20.28 # funman: yes 15.20.31 # thanks 15.20.59 # New commit by 03funman (r22251): Sansa AMS: identify interrupts with no source set ... 15.21.01 # New commit by 03funman (r22252): Add Amaury Pouly to the credits 15.21.08 # Torne: no I express myself no correctly. logfbuffer is MAX_LOGF_ENTRY+1 large. The last char is the type of line (single, multi, continue). 15.21.22 # Torne: the one just before the last one is a 0 15.21.35 Quit funman ("free(random());") 15.21.50 # so there are in reality 28 characters per line 15.22.30 # no, you're wrong, sorry. 15.23.21 # logfbuffer is not null terminate at all; it happens that the byte for "single line" is a null. 15.23.39 # No, see the bug report I submit today 15.23.58 # The reason is simple: 15.24.02 # In logf.c: 15.24.02 # strlcpy(ptr, buf + tlen, MAX_LOGF_ENTRY); 15.24.08 Join kugel [0] (n=kugel@rockbox/developer/kugel) 15.24.36 # ah 15.24.44 # that means the change to strlcpy has changed the logf behaviour, then 15.24.54 # yes that's possible 15.25.02 # it was previously *not* null terminated 15.25.25 # but it's been changed to do strlcpy instead :) 15.26.01 # That would explain the logfdump bug 15.26.10 # And now it no longe rbehaves as the comments in logf.c say 15.26.44 # interesting :) 15.27.28 # hm, it still space-pads it though 15.27.31 # this is.. weird 15.27.37 # i think this is broken :) 15.27.42 # why's that line breaking such a problem? splash(f) does it fine too 15.27.44 # yes you're right 15.27.45 # should probably be changed back to memcpy 15.28.01 # wrapped lines are being wrapped at 28 bytes then null terminated 15.28.12 # non-wrapped lines or the last bit of wrapped lines are being allowed to be 29 bytes, and space padded. 15.28.17 # unless i'm misreading logf.c 15.28.39 # where's the strlcpy? 15.28.50 # in _logf 15.28.51 # the the build for ipodvideo also work on the ipodvideo64mb? 15.28.58 # Jaykay: yes 15.29.04 # it just doesn't use all the ram 15.29.07 # currently, all lines are at most 28 characters long, whatever the type of line is 15.29.16 # pamaury: no, they're not 15.29.27 # Torne: then why is there a separate download for it? 15.29.33 # Jaykay: because it doesn't use all the ram 15.29.41 # hum yes you right 15.30.01 # there is a weird behaviour for string with length that is exactly MAX_LOGF_ENTRY 15.30.01 # r21863 has broken logf 15.30.25 # pamaury: no, the weird behaviour is for strings which are wrapped. if you read the comment at the top of the file, it's not *supposed* to be null terminated, in *any* case. 15.30.34 # Torne: the last question: can configure build the 64mb version? 15.30.35 # r21863, the strlcpy change, has been done wrong. 15.30.45 # Jaykay: yes, but mem size is a seperate prompt from the target type :) 15.30.49 Quit beta_ (Read error: 110 (Connection timed out)) 15.30.55 # yes you can turn it the way you want :) 15.31.16 # pamaury: strings <=MAX_LOGF_ENTRY are being handled the same as they have always been, it's only strings longer whose behaviour has changed from how it's documented to work :) 15.31.19 # Torne: ok, thanks 15.31.20 # but you're right, there are not expected to be null terminated 15.31.59 Join bubsy [0] (i=Bubsy@94.139.72.137) 15.32.03 Quit thegeek (Read error: 110 (Connection timed out)) 15.32.19 # the use of strlcpy should be changed to memcpy 15.32.19 # Then it should be noted that the logfdump code would be broken (because of my fix) 15.32.45 # Torne: the \0 added for long strings is overwritten by LOGF_TERMINATE_CONTINUE_LINE isn't it? 15.32.51 # why is the h10_5gb in rbutil named h10_5gbums/ h10_5gbmtp? 15.32.57 # kugel: no, MAX_LOGF_ENTRY is 29 15.33.16 # kugel: so it ends up with 28 bytes of string then the null then LOGF_TERMINATE_CONTINUE_LINE 15.33.20 # so? 15.33.34 # and there's no need for that to be strlcpy anyway; it's always copying exactly the same number of bytes :) 15.33.46 # strlcpy will add a \0 add ptr[MAX_LOGF_ENTRY] if the src is too long 15.33.55 # and ptr[LOGF_TERMINATE_CONTINUE_LINE] is being overwritten 15.34.04 # no stlcpy will add a '0' ANYWAY 15.34.08 # kugel: no it won't 15.34.15 # it will add one at ptr[MAX_LOGF_ENTRY-1] 15.34.19 # but it will add it at MAX_LOG_ENTRY-1 15.34.34 # uhm 15.34.34 # yea 15.34.46 # someone should just change it to memcpy there 15.34.51 # that's the definition of strlcpy: it will write at most MAX_LOG_ENTRY characters, INCLUDING the 0 15.34.52 # before we do anything else with the log dumper :) 15.35.00 # pamaury: I know 15.35.02 # because changing th elog dumper to accomodate this bug is silly :) 15.35.17 # that's what happened :) 15.35.34 Join evilnick [0] (i=0c140464@gateway/web/freenode/x-1ee78bf24d2c82c4) 15.35.36 # oh, that already got committed? :) 15.35.44 # yes 15.36.06 # and funman has gone :( 15.36.23 # but it should add a \0 if src is short, shouldn't it? 15.36.36 # kugel: src is never short in that case 15.36.46 # that's weird code still! 15.36.47 # kugel: the strlcpy only gets called when the original string is >MAX_LOGF_ENTRY 15.37.01 # if you read the comment at the top of the file it says the buffer is space-padded with no terminators. 15.37.17 # I can write a patch for that and submit it after some testing 15.37.33 # which is what it does with the strcpy lower down in the function. 15.37.58 # it should've used memcpy in the first place 15.38.04 # kugel: yes 15.38.31 # oh wait 15.38.38 # actually if you look at the diff it was wron gbefore as well :) 15.38.44 # as it was doing strncpy with MAX_LOGF_ENTRY-1 15.38.56 # so it was logical for someone to change that to strlcpy with MAX_LOGF_ENTRY 15.39.09 Join aaron424 [0] (n=chatzill@adsl-065-013-002-216.sip.asm.bellsouth.net) 15.39.24 # I have to leave, come back later 15.39.43 # several previous sets of people appear to have had the same misunderstanding about how the logf buffer is supposed to work 15.40.37 # the multiline logf thing seems to have never really worked right, possibly, looking at the file history :) 15.40.53 # what does the space-padding? 15.41.01 # a few lines lower down 15.41.19 # strcpy(ptr, buf + tlen); then it pads with spaces 15.41.48 # that strcpy is also kinda weird. it will always work in this particulra case 15.42.26 # but if you logf() MAX_LOGF_ENTRY bytes then that strcpy will indeed set the 30th byte in the entry to 0, which will then get reset later 15.42.43 # Both of them should be memcpy really 15.43.13 # since it's not really null terminated strings being dealt with 15.43.17 # or that weird code should be fixed to be human understandable 15.43.24 # Hehe 15.43.53 # it's not entirely obvious *why* it's supposed to be space padded 15.44.17 # "padded for easier and faster output on screen" doesn't make any sense for me 15.44.20 # no. 15.44.25 # ...also, er 15.44.35 # if we now support multiline logf anyway, with all this wrapping stuff 15.44.45 # why is there even a fixed length record in the first place. 15.44.53 # i'm not seeing hte advantage, tbh :) 15.45.19 # a ring buffer of consecutive null terminated strings would work just as well.. maybe better.. unless there's some use case i'm not seeing 15.45.58 # the starting address is slightly less clear 15.46.35 # how so? 15.48.33 # logfindex could just be bytes instead of records, i don't see how tha tmakes any difference for either side 15.48.37 # I mean, with a fixed-line ring buffer, you don't have pesky calculations to work out if the line you're looking at is still fully there, or it's been overwritten by a new line. It's a very minor thing though, and I probably don't explain it properly 15.49.04 # Oh, you mean the first line in the buffer being only the last bit 15.49.09 # because of partial overwriting. 15.49.19 # yes 15.49.27 # yes, that's true. 15.49.37 # but you could just throw that line away, for all the difference it really makes 15.49.41 # truncated or not 15.49.56 # Something that probably is a real difference though is that at least with a fixed width font, if you use space padding, clearing the on-screen line you're going to overwrite is automatic 15.50.10 # but it currently doens't use a fixed width font :) 15.50.19 # it probably did originally I guess :) 15.50.23 # if you have a free running circular buffer then you have no guarantee you are getting the right data nayway 15.50.26 # I think it never did 15.50.30 # you are always going to drop stuff 15.50.41 # so you can just throw away the first bit in the buffer, assuming it's been partially overwritten. 15.50.49 # i mean the entire implementation here isn't threadsafe anyway 15.51.01 # kugel: sure it did. Remember the Player? :) 15.51.02 # so the data already has a nonzero chance of being overwritten while you are in th emiddle of using it 15.51.07 # zzz 15.51.11 # and just being unreadable garbage to begin with 15.51.17 # :) 15.51.38 # Torne: remember cooperative multitasking? :) 15.52.01 # oh right. 15.52.03 # :) 15.52.09 # yeah ok *apart* from that *g* 15.52.13 # kugel: seriously, I wouldn't be surprised if the space-padding idea is that old 15.52.29 # i would guess that is why it's space padded, yes 15.52.56 # and yes, in modern variable width font times it doesn't make much sense 15.53.39 # gevaerts: I wouldn't be either. I yesterday asked for a feature in another project. the dev told me it was deactivated some time ago because it didn't work. That's was 3 years ago (r2xx, HEAD is r41xx) 15.54.21 # gevaerts: anyway i think it should either be fixed to use memcpy and someone check that that makes it behave as documented.. or it should just lose the fixed length records entirely :) 15.57.50 Quit darkhamm (Read error: 60 (Operation timed out)) 15.59.20 Join darkhamm [0] (n=darkhamm@host41-155-dynamic.6-87-r.retail.telecomitalia.it) 16.08.54 Join Tristan [0] (n=Tristan@i.dont.want.to.die.virgin.net.in) 16.10.19 # hello back 16.11.49 Quit bah_ (Read error: 110 (Connection timed out)) 16.11.52 Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) 16.12.35 # have you worked out the logf bug ? 16.19.17 # gevaerts, actually I did add some mutexes for the i2c and adc parts of the s5l8700 16.19.32 # bertrik: interrupt contexts? 16.19.56 # the as3525 targets just block for i2c to complete (for example), but it's actually nicer to wakeup_wait and let the interrupt do wakeup_signal 16.20.21 # yeah, mutexes can be problematic to use in interrupt context 16.20.38 # impossible probably 16.20.41 Join bah_ [0] (n=bah@c-76-105-203-173.hsd1.wa.comcast.net) 16.21.53 Quit Trista824 (Read error: 113 (No route to host)) 16.22.08 # in hindsight, I was worrying about spin loops on the order of 100 us, while probably 10s of miliseconds are wasted in spinloops in some lcd drivers 16.24.12 # Torne: are you there ? 16.24.19 # pamaury: We've worked out that it definately doesn't behave as documented 16.24.29 # and also that it's kinda confusing and is probably only that way for historical reasons 16.24.39 # it could be put back to working as documented fairly easily i think 16.24.52 # but i suggested we might just give up having fixed length records altogether :) 16.25.44 Join beta_ [0] (n=beta@d24-36-68-97.home1.cgocable.net) 16.25.56 # How do you want to achieve that ? 16.26.19 Nick beta_ is now known as Beta2K (n=beta@d24-36-68-97.home1.cgocable.net) 16.26.19 Join Blue_Dude [0] (n=chatzill@adsl-235-206-199.mco.bellsouth.net) 16.26.39 # Having only one big buffer and append at the end ? 16.27.19 # I just posted a bug report at FS#10512 regarding problems with bookmarking. Has something changed recently? 16.27.41 # pamaury: just treating it as a buffer of bytes, with each entry separated by a single null 16.27.54 # i dunno tha tanyone agrees with me 16.27.57 # but it was a suggestion. 16.28.20 # well it's would be much simpler, seeing how complex is the code just to support multiline 16.28.36 # (in logfdump for example) 16.28.39 # Torne: one more problem with non-fixed-size would be that you can wrap around halfway a line 16.28.45 # gevaerts: so? 16.28.52 # does that matter? 16.29.06 # no, it just adds code 16.29.13 # probably not more than it *removes*, though 16.29.16 # It would move the complexing to the display code that would have to wrap correctly 16.30.04 # I agree with Torne that doing so would probably remove more code than it adds and the code would be more human understandable 16.31.13 # the advantages of the fixed length records were fine when we didn't allow people to logf more data than htat 16.31.20 # now it has the code to split lines anyway it seems less worthwhile 16.32.37 # the inconvenient is that it would require a full screen redraw in logf if i'm correct 16.32.52 # why? 16.33.20 # because it would not be fixed-width 16.33.41 # with space-padding, drawing a line erases the previous one, no ? 16.34.08 # yes, but that doesn't mean you suddenly have to redraw the entire screen 16.34.32 # how do you redraw only part of the screen if you scroll one line for example ? 16.37.21 # er, it already redraws the whole screen when you scroll up and down, no? 16.37.48 # well yes :) 16.37.52 # I think so too 16.38.12 # at least the parts that changed 16.39.45 # so I see only advantages to having one big buffer and entries separated by a single null 16.40.33 # pamaury: the disadvantage is that the 'first' entry in the buffer may have been partially overwritten 16.40.51 # yes but it's the same thing with the actual code 16.41.03 # but at the moment you can *tell* there is a partially overwritten line 16.41.15 # no, wait, you can't 16.41.20 # no you can't 16.41.21 # because it doesn't mark the *first* continued line specially 16.41.27 # Heh. So yes, it's no worse. 16.43.54 Join toffe82 [0] (n=chatzill@74.0.180.178) 16.46.58 Join Lss [0] (n=Lss@cm119.delta88.maxonline.com.sg) 16.47.22 Quit aaron424 (Read error: 60 (Operation timed out)) 16.47.59 Part LinusN 16.48.11 # Torne: there is one disadvantage but it's minor: when the buffer would wrap you can end up with the first line being empty because the buffer has erased the whole line except the '0'. So there would have to consecuting '0' in the buffer 16.48.44 # that's just a special case of the first line being partially overwritten 16.48.54 # Yes but that would introduce an extra blank line 16.48.58 # so? 16.49.13 # overwriting one less byte would introduce an extra line with one useless character on it :) 16.49.40 # if it's particularly concerning you can just skip everything from the current write position tot he next null 16.49.53 Join maruk [0] (n=papier@titanium.sdv.fr) 16.50.35 # yes 16.54.30 # anyway, whether to do this is kinda a different matter to the actual problem, which i can write a patch for but don't have a convenient way to test right now 16.55.09 # I have written a fix for the actual code and tested it 16.55.26 # you also fixed the references to MAX_LOGF_ENTRY-1? 16.55.48 # pastebin the diff somewhere? 16.56.41 # yes, do you a site where I can paste the diff ? 16.57.16 # pastebin? pastie.org 16.57.54 # http://pastie.org/580060 16.58.19 # It also uses the system font to draw the log 16.59.07 # the fix to logf is fine 16.59.10 # i dunno about the rest.. 16.59.33 Join aaron424 [0] (n=chatzill@adsl-065-013-002-216.sip.asm.bellsouth.net) 16.59.38 Join captainkwel [0] (i=2669ecc2@gateway/web/freenode/x-8a2f15f40466d46d) 17.00.17 # Wall it fixes logf, logfdump and logfdisp. I trick to use the system font optional 17.00.24 # *the trick 17.00.36 # isn't it also necessary to revert the change that funman just committed 17.01.27 # yes that's what I was looking for 17.01.33 # http://svn.rockbox.org/viewvc.cgi/trunk/apps/logfdisp.c?r1=20743&r2=22250 17.01.49 # I don't think I have the last version 17.01.53 # and i'm not sure what lines 28/29 of the diff are for 17.02.26 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 17.02.54 # Hum, that's because on my target at leats it will overwrite the last character of the line but it's a hack, perhaps we should simply drop this '>' 17.03.20 # i would just leave the log display alone for now 17.03.23 # fix one thing at a time 17.03.40 # the diff there to logf, plus reverting funman's change, should sort the actual problem 17.04.00 # the display issue is, well, just a display issue :) 17.04.40 # ok, I change the diff and paste it 17.05.56 # Should I include the system font change or not ? 17.06.16 # no. i think that has the potential to make it worse on average :) 17.07.00 # the display issue i think is better fixed in a different way 17.07.08 # http://pastie.org/580071 17.07.14 # there are several possible different ways. one of which is just to stop doing the fixed length records at all. 17.07.26 # (but it could also rewrap the lines) 17.07.45 # Yes, but we can still fix the existing code and write a new one later 17.07.48 # pamaury: yah, that looks right to me. I mean i've not tried it or anything :) 17.08.02 # I will test it now 17.08.20 # pamaury: my point is it's not a fix. it makes it different, in a way which may be better or worse depending exactly how big your font/screen are and how long your logf messages are on average :) 17.09.08 # it might look better on your particular player but i don't think this is universal 17.09.39 # rewrapping the lines, or letting hte lcd code truncate it and displaying the wraps some other way, would be a universal fix but is not as trivial :) 17.10.02 # It's not as complex 17.10.37 # but my point is that for some font/screen combinations changing it to sysfont may make *less* information fit on the screen, not more. 17.10.44 # so i don't think it's a good idea :) 17.11.18 # yes I agree 17.11.33 # but it's a different problem than rewriting the underlying code 17.11.43 # Yes, but it's related 17.11.58 # Rewrapping the lines is the nicest fix, really 17.12.14 # (which would be easier if done with sysfont, also) 17.12.32 # it's mostly a font problem, it's possible to code it in a way that it corretly wraps whatever the font is 17.12.53 *** Saving seen data "./dancer.seen" 17.13.05 # but it's not unrealated, because wrapped printing would be required anyway if the log records stopped being fixed length 17.13.12 # * Torne shrugs 17.13.30 # yes 17.13.57 # anyway you should chuck the patch just to fix logf into FS 17.14.07 # and poke funman if he comes back :) 17.15.12 # I've tested the fix I posted and it worked on my sansa as far as I can tell 17.22.05 Quit darkhamm (Read error: 104 (Connection reset by peer)) 17.23.57 Quit aaron424 ("ChatZilla 0.9.85 [Firefox 3.0.13/2009080311]") 17.29.10 Join Sajber^ [0] (n=Sajber@c-473171d5.012-155-73746f22.cust.bredbandsbolaget.se) 17.29.45 Quit Sajber^ (Read error: 104 (Connection reset by peer)) 17.30.45 Join Sajber^ [0] (n=Sajber@c-473171d5.012-155-73746f22.cust.bredbandsbolaget.se) 17.30.54 Quit Sajber^ (Read error: 54 (Connection reset by peer)) 17.31.50 Join Sajber^ [0] (n=Sajber@c-473171d5.012-155-73746f22.cust.bredbandsbolaget.se) 17.36.36 Join chandoo_ [0] (n=chandoo@ool-4353b978.dyn.optonline.net) 17.42.48 Join JdGordon_ [0] (i=63cb7a73@gateway/web/freenode/x-92b65e7ca3f74c69) 17.46.15 Quit moos (Read error: 104 (Connection reset by peer)) 17.46.17 Join DrMoos [0] (i=mustapha@85-169-147-55.rev.numericable.fr) 17.47.01 Nick DrMoos is now known as moos (i=mustapha@85-169-147-55.rev.numericable.fr) 17.48.58 Join funman [0] (n=fun@rockbox/developer/funman) 17.52.53 # funman: we add with Torne and gevaerts a discussion about logf and concluded that the current implementation contains a long standing bug that my patch revealed. 17.53.03 # s/add/had 17.53.14 # I submitted a patch to FS about it 17.53.19 # i'm reading the log 17.54.08 # bertrik: mutexes are impossible to use in interrupt context, because they need a thread context 17.54.25 # yes I know 17.54.50 # I wonder what would happen in practice though when attempting to grab a mutex in interrupt context 17.55.37 # try it! 17.55.44 # I wouldn't mind some kind of check on that 17.56.05 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 17.56.08 # i believe it acts like the thread running before the isr took the lock 17.56.52 # since the thread is cores[CURRENT_CORE].running 17.56.57 Join TheSphinX^ [0] (n=cold@p54A5C007.dip.t-dialin.net) 18.01.41 Join Jaykay_ [0] (n=chatzill@p5DDC5D2B.dip.t-dialin.net) 18.01.56 Quit stoffel (Remote closed the connection) 18.02.50 # pamaury: i understand LOGF_TERMINATE_CONTINUE_LINE is overwritten in each loop ? in firmware/logf.c 18.02.59 Join stoffel [0] (n=quassel@p57B4CDC4.dip.t-dialin.net) 18.03.15 Join merbanan [0] (n=banan@c-83-233-172-245.cust.bredband2.com) 18.04.01 # funman: no the problem we encountered is that each time a log line is greater than MAX_LOGF_ENTRY, the current code split it but the intermediate lines created are '0' terminated whereas they should not 18.04.04 Quit Blue_Dude (Read error: 110 (Connection timed out)) 18.04.40 # this mean that single lines have MAX_LOGF_ENTRY characters whereas multlines have MAX_LOGF_ENTRY-1 characters each and a terminating '0' 18.04.50 Quit stoffel (Remote closed the connection) 18.04.55 # this explain why logfdump was buggy 18.05.40 # ok i misread 18.06.12 # len & tlen are offset to the source pointer, not the dest pointer 18.06.40 # yes 18.07.31 Join stoffel [0] (n=quassel@p57B4CDC4.dip.t-dialin.net) 18.07.41 # the funny thing is that the logfdump code for which I submit a patch was indeed correct, that was the logf code that was wrong 18.08.40 # :) 18.09.47 Join linuxstb [0] (n=root@rockbox/developer/linuxstb) 18.12.07 # New commit by 03funman (r22253): Fix logf() multilines handling ... 18.12.29 # i hope you'll stop finding problems now! 18.13.41 # well it's not clear, this is just a fix but Torne suggest a complete rewrite of the logf code but it's just a suggestion :) 18.15.05 # if it's a good idea you could add it to http://www.rockbox.org/twiki/bin/view/Main/MrSomeonesTodoList 18.15.10 Quit Jaykay (Read error: 110 (Connection timed out)) 18.15.43 Quit stoffel (Read error: 104 (Connection reset by peer)) 18.15.53 # pamaury: it just needs someone to do it :) I think the corrent code is rather "suboptimal" 18.17.43 Quit JdGordon_ (Ping timeout: 180 seconds) 18.18.24 Quit linuxstb ("Lost terminal") 18.20.02 Quit bluebrother (Nick collision from services.) 18.20.07 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 18.20.52 Quit xavieran (Read error: 113 (No route to host)) 18.22.46 Quit domonoky (Read error: 104 (Connection reset by peer)) 18.23.17 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 18.24.43 Quit TheSphinX^ ("XChat@Linux") 18.26.31 # kugel: I can do it in my free time (I have plenty for now) but we have to be sure we want to rewrite it 18.27.34 Join JdGordon| [0] (n=Miranda@nat/microsoft/x-16cf08f26d5bade2) 18.28.35 # pamaury: you could send an email to the developers mailing list explaining what you want to do and see if someone already started working on this idea or something similar 18.29.01 # funman: it's not a huge thing.. 18.29.15 # the suggestion was just to change logf to be a circular buffer of bytes, with messages separated by nulls 18.29.24 # rather than a buffer of fixed length records with explicit continuation markers 18.29.27 # looks good to me 18.30.05 # since the fixed length records appear to exist to make it convenient to print it to the screen on the Player 18.30.06 # i won't be the one writing the patch though, perhaps i misunderstood pamaury's concern 18.30.11 # which is a somewhat outdated requirement now 18.31.01 # no I'm not expecting you to write the code :) 18.31.36 # pamaury: i mean i'm not sure why you want to be sure it needs to be rewritten 18.32.00 # funman: I guess s/needs to be rewritten/will be committed if rewritten/ 18.32.03 # because otherwise it's useless :) 18.32.23 # gevaerts: yes 18.32.34 # circular buffer with '\0' markers look simpler, so better, so committable 18.33.12 # and buffer size adjustement would be simpler as well 18.33.14 # pamaury: there's not much formality :) 18.33.36 # i'd say go for it! 18.34.17 # ok. I'll write some code tomorrow and see if we missed some things. I guess the real work is to rewrite the logf display 18.34.53 # wrapping the text is likely to come out as a bigger diff, yes :) 18.35.27 # i thought wrapping was made by lcd code? 18.36.26 Quit maruk ("Leaving.") 18.36.44 # no I don't think so, truncating yes, but not wrapping 18.37.38 # funman: lcd_puts* just truncate. 18.38.01 # oh 18.38.12 # logfdump+texteditor ftw 18.38.22 # heh 18.38.49 # actually, *is* there a remotely sensible way to print wrapping text? 18.38.51 Quit petur ("work->home") 18.39.00 # lcd_puts* have all the information to tell you where the wrap point is 18.39.06 # but then they throw that information away :) 18.39.40 # well, wrapping at the edge, anyway (not neatly word wrapping) 18.40.32 Join Lynx [0] (n=Lynx@xdsl-78-34-216-147.netcologne.de) 18.40.57 Nick Lynx is now known as Guest71901 (n=Lynx@xdsl-78-34-216-147.netcologne.de) 18.41.19 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 18.41.29 # Torne: the lcd_puts function just call font_get_width for each character so it's quite easy to determine where to wrap 18.41.41 # pamaury: yes, but that's what i mean 18.41.47 # lcd_puts already calls font_get_width for every character 18.42.02 # to implement wrapping yourself you would *also* need to do that, and then call lcd_puts on the result :) 18.42.05 # thus doing the work twice. 18.42.24 # plugins like the text viewer suffer through this because they are word wrapping so they have to keep track of hyphens and spaces and stuff 18.42.36 # but for trivially just folding text around at the edge of the screen this seems kinda sucky ;) 18.44.05 # the code wouldn't be complex to write i think 18.44.37 # logf display isn't built by default, and the buffer can be dumped to a file 18.44.53 # oh sure, i'm not suggesting it's a real problem 18.45.12 # it just seems wasteful for any case where things might want to print wrapping text :) 18.45.18 Quit Lynx_ (Read error: 60 (Operation timed out)) 18.45.18 Nick Guest71901 is now known as Lynx_ (n=Lynx@xdsl-78-34-216-147.netcologne.de) 18.46.17 # anyway, a call to font_get_width should be very quick, just a lookup in a table, this is nothing compared to the real printing operation done by lcd_puts 18.48.02 # Torne: we really should have a lcd_puts_wrapped() 18.48.29 # maybe wait for Unhelpful committing his lcd driver unifying work 18.48.43 # if lcd_puts() already has the info, there could be a parameter for wrapping 18.49.52 # yeah, it knows when it's gone too wide. 18.50.05 # it quits the loop once it's gone pas the edge of the screen 18.50.41 # note that code usually tracks the line it is writing (as an argument to lcd_puts) and increment over it 18.51.21 # you wouldn't want to put the end of a long line on the line below and see if overwritten just after 18.51.26 # funman: that's putsxy, and wrapping obviously wouldn't work for it 18.51.31 # IIRC 18.51.36 # while we're on the topic.. lcd_puts (rather than putsxy) behaves *really weirdly* for proportional fonts :) 18.51.59 # why ? 18.52.03 # if you pass an X coord other than 0 in a proportional font the position it writes to is very very odd 18.52.04 # lcd_puts() takes the same argument than lcd_putsxy() : a x, a y, and a string 18.52.30 # because it works out the pixel coord by getting the width of the string being printed in pixels and dividing it by the length in characters 18.52.33 # then multiplying that by x 18.52.52 # ah... 18.52.57 # weird... 18.52.57 # which means printing "iii" and "MMM" go to different places on the screen 18.53.00 # given the same coordinates :) 18.53.21 # only the y coordinates in meaningful 18.53.30 # it's basically just useless logic, since for a fixed width font it's wasted effort (you can just check the font width once) 18.53.35 # and for proportional it's meaningless. 18.53.43 # kugel: lcd_putsxy takes pixel positions while lcd_puts takes characters position 18.53.46 # it should probably use the width of some particulra character. 18.54.13 # '.' 18.55.12 # heh, my instinct says '0' 18.55.17 # (because that's what the z-machine says) 18.55.18 # but hey 18.55.30 # just about the discussion on the work being done twice, isn't possible to write a lcd_puts_wrapped just by using lcd_putc ? This way, font_get_width would be called once for each character (except if lcd_putcs calls it of course) 18.56.18 Nick DarkSpectrum- is now known as DarkSpectrum (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 18.56.22 # lcd_putc doesn't exist on bitmap targets 18.56.44 # ah, a good thing to know 18.56.44 # also that's a pain :) 18.57.20 # why doesn't it exist ? It could always be implemented with lcd_puts (it sucks but it's possible) 18.57.41 # because it sucks 18.57.46 # atrac3 looks like fun to port to fixed point 18.57.57 # the code is clean and theres hardly any constants to convert 18.58.11 # anwyay all this woul dbe better left until the lcd drivers were unified :) 18.59.07 # what will be the changes ? 18.59.37 # * Torne leaves for now though :) 19.00.39 # pamaury: killing code duplication 19.00.41 Quit robin0800_ ("Leaving") 19.01.21 # but will the api change ? 19.01.38 # no 19.01.57 # i thought Unhelpful was only related to scrolling? 19.02.17 # Unhelpful's work on lcd* 19.02.18 # that's another project :) 19.02.38 # New commit by 03bluebrother (r22254): Clean up accessing system setting values for a specific player. ... 19.02.47 Join darkhamm [0] (n=darkhamm@95.234.18.47) 19.03.48 # * n1s aplologizes for be 19.04.04 # s/be/breaking the logf thingy/ :/ 19.04.09 Quit darkhamm (Client Quit) 19.04.40 # n1s: it's ok, i have no problem for you being 19.05.12 Join stoffel [0] (n=quassel@p57B4CDC4.dip.t-dialin.net) 19.05.24 Join darkhamm [0] (n=darkhamm@95.234.18.47) 19.06.47 # funman: http://www.rockbox.org/tracker/task/4817 19.06.53 # n1s: wasn't your fault 19.08.26 Quit parafin ("So long and thanks for all the fish") 19.10.39 Join Blue_Dude [0] (n=chatzill@adsl-235-206-199.mco.bellsouth.net) 19.11.15 Join kachna [0] (n=kachna@r4ax178.net.upc.cz) 19.11.32 # kugel: bookmarking broke a few days back and I think I've traced it to a code cleanup you did (r22192/22193). 19.12.16 # The fix looks simple, and I'm finishing it up now. 19.12.24 Quit darkhamm ("Sto andando via") 19.12.54 *** Saving seen data "./dancer.seen" 19.15.33 Join faemir [0] (n=faemir@78.33.109.163) 19.16.16 Quit stoffel (Remote closed the connection) 19.16.44 Join stoffel [0] (n=quassel@p57B4CDC4.dip.t-dialin.net) 19.17.05 Join parafin [0] (n=operator@paraf.in) 19.18.25 Quit parafin (Client Quit) 19.18.27 Join parafin [0] (n=operator@paraf.in) 19.19.02 # Bagder: wouldn't it be nice to use a fixed-width font for the viewvc diffs? 19.21.14 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 19.22.35 # I agree 19.27.07 Quit parafin ("So long and thanks for all the fish") 19.27.16 Join parafin [0] (i=parafin@paraf.in) 19.27.46 Quit funman ("free(random());") 19.30.50 # FS#10514 - itunes compatible time setting 19.31.43 # Bagder: it would absolutely awesome 19.31.49 # +be 19.36.20 # kugel: FS#10512 19.45.01 # Is there low battery shutdown on the Gigabeat S yet? 19.49.26 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 19.49.30 # Llorean: think o 19.49.31 # so 19.50.53 Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]") 19.51.21 # n1s: The threshold may be too low then 19.51.44 # My Gigabeat with low battery hung at disc spinup. Sat there, just kinda waiting, until I plugged in AC after which it resumed playing as normal 19.52.09 # yeah, that sounds plausible 19.54.40 Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) 19.54.51 # New commit by 03gevaerts (r22255): Add support for setting the clock using a special SCSI command. This is the same method that itunes uses, and there are host-side tools for it (e.g. ... 19.57.39 # Llorean: the shutoff voltage is 3.4V 19.57.46 # will itunes sync time on a rockbox'ed ipod ? 19.59.51 # I suspect not (unless we do the xml descriptor thing as well), but the ipod-time-sync tool from libgpod will 20.00.08 # I also suspect that some future version of rbutil will 20.00.55 # ok, this is not good :\ 20.01.57 # I disclaim any responsibility for the red though 20.02.27 # that's an odd error 20.07.16 Join darkhamm [0] (n=darkhamm@95.234.18.47) 20.07.17 # New commit by 03gevaerts (r22256): Fix "statement with no effect" warning 20.07.33 Quit faemir ("Leaving") 20.08.33 # What's the best way to fix that delta for non-USB players? It comes from new functions in firmware/common/timefuncs.c, and I'd really like not to put #ifdef HAVE_USBSTACK and friends in there 20.10.02 # I find the delta surprisingly high 20.10.09 # gevaerts: I'm a bit amazed that patch adds nearly a KB on some targets 20.11.03 Join pyro_maniac [0] (n=pyro@91-64-165-18-dynip.superkabel.de) 20.12.09 # it's little code added 20.12.28 # how about automatically calling bloat-o-meter? :) 20.13.35 # * gevaerts thinks he found something 20.13.40 # kugel: what about your WPS (or viewport?) code shuffle delta? 20.14.00 # that was weird also 20.14.07 # hm, no 20.14.54 Quit chandoo_ ("Leaving") 20.15.46 # perhaps we should look at making one or more libraries for support functions, so the linker can skip them 20.16.24 Part Llorean 20.16.59 # how did that work again? 20.17.20 # it only links the functions that are actually used, when linking against a library? 20.17.45 # yes. all code from .o files are included even if they are not used. but code from .a files are only linked when referred to. 20.17.50 # instead of all functions in each object file that is specified 20.20.36 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 20.22.40 # Does anyone know offhand how many Supported targets there are? (individual models, so Sansa E-series would be 1, not 1 per capacity of internal flash) 20.23.04 # 28 isnt it? 20.23.15 # + 15 or so in progress 20.23.59 # 28ish yes, depending on how you count ipod video 64MB and things like that 20.25.43 Join Llorean [0] (n=DarkkOne@adsl-99-182-52-92.dsl.hstntx.sbcglobal.net) 20.27.48 Quit darkhamm ("Sto andando via") 20.30.31 Join Creposucre [0] (n=53c3739e@gateway/web/cgi-irc/labb.contactor.se/x-d3450091697a82a7) 20.30.44 Join faemir [0] (n=faemir@78.33.109.163) 20.30.50 # Hi 20.31.32 # does anyone mind introducing __attribute__((unused))? 20.31.46 Join p3tur [50] (n=petur@rockbox/developer/petur) 20.32.38 # I have a patch that touches plugins a bit, i.e. all plugin_start() and cleanup() definitions get their parameter attributed with that to remove various (void)var statements 20.32.43 # I'd rather avoid using attributes unless absolutely necessary 20.33.24 # why? 20.33.54 # it's something compiler-specific, I like doing stuff with plain C 20.34.06 Quit flydutch ("/* empty */") 20.34.18 # whats the point of the change? 20.34.29 # Does anyone know if any rockboxed or rockboxable player has a remote tuner? 20.35.03 # except ipods 20.35.04 # Creposucre: hey, I added a slightly better logging patch to 9951.. dunno if oyu saw it 20.35.07 # removing various (void)var; (which isn't even optmized away always), make it clearer that a paramter may be unused 20.35.11 # (/me hoping he isnt confusing nicks) 20.36.12 # no, i didn't saw it 20.36.15 # gonna try it ;) 20.37.24 Join darkhamm [0] (n=darkhamm@95.234.18.47) 20.38.34 # i'll be right back 20.40.24 Quit pamaury ("Quitte") 20.42.21 # ok i'm lookin to try out my m200v4, where is the page with firmware instructions? 20.42.43 # I'm not trying to kill every (void)foo, but for certain functions, like callbacks 20.43.20 # what does the bloat-o-meter.py do? 20.43.22 # I tinhk adding that to the function is going to make it harder to read than adding a (void)foo; line 20.43.40 # funman: the scrolling style hooks patch layers on another one that unifies all styled text drawing - it's just so much easier if i don't have to make the edits in five different files 20.44.16 # bertrik: breaks down binary size changes per-symbol, showing which symbols have been added or removed, and which have changed size 20.45.22 # what kind of files does it take? 20.45.56 # DarkSpectrum: the SansaAMS wiki page contains install instructions for this. 20.46.07 # any elf objects, i think... obviously it's only useful if they're *related* objects. :) 20.46.14 # * DarkSpectrum doesnt see it for the m200v4 20.46.16 Quit HellDragon (Read error: 104 (Connection reset by peer)) 20.46.28 Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) 20.46.50 # DarkSpectrum: installation is the similar for all AMS Sansa devices 20.47.21 Quit HellDragon (Read error: 54 (Connection reset by peer)) 20.47.22 # DarkSpectrum, there are some serious issues with the m200v4 port, like shutting down when the volume goes too high 20.47.33 Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) 20.47.57 # i saw that, i don't even care if i brick it, it's not like it's a player i use anyway, just interested in playing with it 20.48.03 # also, last time I tried it, I found the volume quite low already compared to other as3525 players 20.48.45 # DarkSpectrum, maybe you could have a look at fixing this if you feel like it 20.48.55 # yes, something is wrong with volume on m200v4, but apart from that it works (of course the general low-mem playback bug also applies) 20.49.35 # * DarkSpectrum is already commited to a project 20.50.33 # * domonoky thinks some powermanagement init is missing on the m200v4 (its the only ams target with 1.5v supply) 20.50.52 # my gut feeling is that there is something wrong with the power management setup, the big difference between the m200v4 and other as3525 sansas is that it is AA powered instead of lithium 20.50.58 Quit Lss (Read error: 104 (Connection reset by peer)) 20.51.30 # domonoky, we (I even) could have a look at the OF powermanagement setup 20.52.34 # that would be good. (but i am not good enough with asm). 20.52.37 # JdGordon|: how? 20.53.16 # i could test ;P 20.53.19 # domonoky, I guess I can find it within an hour, I'll have a go at it tonight 20.53.23 # figured out how to install 20.53.43 # I assume they get added like void foo(int bar __attribute__((unused)), int boo) ? 20.53.46 # I'm using UNUSED_ATTR instead of __attribute__((unused)) directly 20.54.00 # like this: enum plugin_status plugin_start(UNUSED_ATTR const void* parameter) 20.54.17 # New commit by 03gevaerts (r22257): rework new time handling functions a bit to be more memory efficient 20.54.31 # thats still not pretty 20.54.33 # * bertrik spots m200 disassembly pictures on the forums of sandisk.com :\ 20.54.38 Quit stripwax ("http://miranda-im.org") 20.55.26 # JdGordon|: I think it is, definitely more pretty than (void)parameter everywhere. 20.56.18 # * domonoky likes "(void)parameter;" more. and its not compiler specific... 20.57.15 Join FOAD_ [0] (n=dok@dinah.blub.net) 20.58.09 Quit FOAD ("Lost terminal") 20.58.09 Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) 20.58.17 Quit FOAD (Client Quit) 20.58.25 # it's not a no-op always 20.58.29 # Bagder tested it 20.58.34 Join FOAD [0] (n=dok@dinah.blub.net) 20.58.44 # much code without -O2 for example 20.59.37 # better, but not good enough 21.00.00 # * gevaerts means the delta, not the unused parameter things 21.00.38 # I rather not count on gcc optimizing it if we can force it 21.00.47 # the question is: how much does it hurt ? in a place like plugin_start a extra instuction doesnt hurt. 21.01.21 # there are many places in the core too 21.01.39 # I think it always hurts if we can avoid it easily 21.03.56 # adding compiler-specific kludges isn't exactly a pretty solution either. even if we are rather locked into gcc anyway. 21.05.59 # I'm split, personally. both solutions are rather ugly. 21.06.01 # we're heavily locked. and this unused won't even break other compilers, just give a few warnings 21.06.18 # where is it used in the core? 21.07.05 # event callbacks, a few functions which do nothing on #ifndef HAVE_XXX 21.07.10 # few other cases too 21.07.21 Quit stoffel (Read error: 104 (Connection reset by peer)) 21.07.59 # I like it as it makes clear it's potentially not used (even if it's used), you'll find (void)foo; only if it's actually unused 21.08.15 # some #if branches just exist for doing that (void)foo; 21.10.03 # Any opinions on moving day_of_week() and yearday_to_daymonth() to usb_storage.c? That's the only place they're used right now, and it seems like the easiest way to get binsize back on non-usb targets 21.10.25 # kugel: wait what? you can add (void)foo lines even if it is used 21.10.49 # but in any case... neither hsould be used when it *might* be used... or "partially" used 21.10.52 # gevaerts: usb_storage seems a bad place :( maybe just a new usb_time.c? 21.11.11 # JdGordon|: huh why neither? 21.11.12 # kugel: that doesn't sound much better I think 21.11.29 # gevaerts: sounds much better to me, but that's just my opinion 21.11.46 # gevaerts: sounds a bit odd to me, but still somewhat reasonable. The only thing that might get problematic is someone adding the same functionality in time_funcs.c later 21.11.50 Join TheSphinX^ [0] (n=cold@p54A5C007.dip.t-dialin.net) 21.11.52 # if I see the ATTR_UNUSED thing next to a var.. it would be damn confusing to then go and see it being used... 21.11.59 # thats an abomination! :D 21.12.10 # (void)foo is much nicer in that case 21.12.13 # kugel: usb_storage is bad because these functions have nothing to do with usb as such. Putting them in a new usb_time.c still implies usb 21.12.34 # JdGordon|: I can't agree with that 21.12.42 # you can and you will!!! 21.12.47 # * JdGordon| lays down the law! 21.12.49 # * bluebrother also likes (void)foo better 21.12.52 # cant you just leave them where they are and add an ifdef? 21.12.53 # ... not really :p 21.12.56 # gevaerts: I'm more concerned of the _storage bit 21.12.59 *** Saving seen data "./dancer.seen" 21.13.01 # HAVE_TIME_FUNCTIONS 21.13.27 # gevaerts: call it usb_misc.c? Or usb_kludge.c? ;-) 21.13.39 # gevaerts, what about Zagor's suggestion? 21.13.41 # in cygwin where is libsdl-dev 21.13.42 # ? 21.13.51 # gevaerts: yeah, dont put them in the storage driver.... thats either going to lead to mess later, and/or code doubling up.. or just good old oplain nasty mess 21.13.55 # in a cygwin package? 21.13.59 # screw the delta... it shuold go in time_funcs 21.14.11 # bertrik: that's not going to be easy 21.14.15 # yes 21.14.35 # I agree the time code should stay in timefuncs. delta is not everything. 21.14.42 # simply #ifdef them ... that makes it clear that only USB_STORAGE uses them. 21.15.00 # can SD cards be powered down when they're not being read? 21.15.08 # it doesn't have anything to do with storage IIUC 21.15.29 # I also wonder if these kind of functions (day of week etc.) are not already implemented somewhere else 21.15.39 # why doesn't it have anything to do with storage if only storage uses the functions? 21.16.44 # bertrik: I think every rtc driver has some sort of day_of_weak() 21.17.27 # regarding the unused attribute, this could be a nice opportunity to use the bloat-o-meter to see if it has any binsize-benefit 21.17.47 # JdGordon|: I meant to add it too all callbacks, like I did to every plugin_start() no matter of the parameter actually being used 21.17.57 # it's been a weak day? ;) 21.18.16 # pixelma: definitely ;-) 21.18.22 # isn't the attribute put in plugin.h? 21.18.28 # kugel: there is no need to add it to everything... especially when it introduces confusion.... but yes, when the callback has it as "void* unused" by all means do it 21.18.51 # no 21.18.58 # no? 21.19.16 # it's also meant to indicate the parameter for a function type, not for single functions 21.20.15 # trying to setup a build system and i can not find libsdl-dev 21.20.29 # err a build client 21.24.23 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 21.28.04 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 21.28.16 Nick p3tur is now known as petur (n=petur@rockbox/developer/petur) 21.30.00 # bertrik: this is -O0 vs -O2 http://pastie.org/580378 21.30.23 # New commit by 03gevaerts (r22258): Consolidate day of week calculation 21.31.39 # kugel: surely it is not surprising that disabling optimisation does not optimise that? 21.32.12 # After this there's only yearday_to_daymonth() left. I think it can be argued that it is specific enough to make it a static function in usb_storage.c 21.32.12 # no, not really 21.32.35 # (for Zagor) 21.32.49 # but I think we don't build all targets with -O? 21.32.51 # gevaerts: I was going to suggest, why not just add a set_time_from_usb() in timefuncs and then just pass the scsi message directly and do no proccessing in usb_Storage at all? 21.34.03 # JdGordon|: I can't think of good arguments right now, but I don't like that idea 21.34.16 Quit amiconn (Nick collision from services.) 21.34.19 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 21.34.39 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 21.34.41 # DarkSpectrum: interesting, no configure? :) 21.34.55 Quit pixelma (Nick collision from services.) 21.34.56 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 21.34.59 # is that worse than having time stuff in usb storage (which obviously isnt a good place for it?) 21.35.13 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 21.36.18 # Why is it obviously not a good place for it? I fully agree about the day_of_week thing, but the other one? 21.37.22 Quit moos ("Rockbox rules the DAP world") 21.37.47 # Zagor: can you reschedule the build? I'd really like to see those deltas 21.38.08 # yes, I will 21.38.13 # thanks 21.38.15 # i think usb_storage.c is a bad place for even the RECEIVING_TIME case, what does it have to do with storage? 21.38.31 # kugel: we can rename it to usb_scsi... 21.38.47 # we should do so then 21.38.53 # I can't move it out of there. It's part of the scsi handling 21.39.29 # the whole file seems to be a mix of storage and scsi 21.41.18 # but do we rename an entire file away from the expected name because it happens to handle one unrelated function? 21.42.15 # Isn't storage and scsi basically the same thing? 21.42.36 # usb storage is scsi, yes 21.42.47 # and other stuff, apparently 21.42.55 # :p 21.43.01 # Then I don't see any problem. This time thing is a non-standard extension to UMS IIUC. 21.43.15 # kugel: no. usb_storage is also other things, usb storage isn't ;) 21.43.22 # (or do I not UC?) 21.43.33 # gevaerts: that's what I meant :) 21.44.15 # linuxstb: it depends on how you look at it. It uses the SCSI WRITE_BUFFER command, which is standard, and valid for all SCSI devices. It uses the vendor specific mode of that though 21.44.39 # * gevaerts isn't sure what to do if/when we implement UAS 21.46.09 # UAS? 21.46.49 # gevaerts: the tm struct could've been local to the case (minor picking :) ) 21.46.49 # USB Attached SCSI. A new spec that properly does SCSI over USB instead of the hackish way that UMS uses 21.47.30 # JdGordon|: if we hurry, we're first. Neither linux nor windows have it yet :) 21.47.53 # That would make testing an interesting challenge... 21.48.05 # isn't the transport used for ATAPI/mmc enough? 21.48.15 # gevaerts: neither wikipedia, apparently 21.48.15 # tmzt: huh? 21.48.29 # for SCSI commands I mean 21.48.36 # oh, new spec 21.49.05 # mmc is that case being what cd recorders use, not multimedia card 21.50.00 # indeed. I'd like to do mmc at some point to allow pretending to be a CD drive to boot from 21.50.53 # or possibly even to export playlists as CDs to the host :) 21.50.53 # with iso9660 mounting..... 21.51.32 # kugel: All parts of rockbox are built with some -O level. Most use -O2, some use -O (== -O1) or -O3. Lowmem targets use -Os in many places instead 21.53.42 # gevaerts: Why does this clock setting stuff cause a red delta on all targets? I would expect it to apply to software usb targets only 21.55.30 # amiconn: that's what we're debating about right now. There are two new functions in timefuncs.c. One of them (set_day_of_week()) belongs there IMO, and I've changed screens.c to use it instead of doing the same calculation itself. The other, yearday_to_daymonth() is specific enough to move to usb_storage.c I think, but others disagree 21.57.41 # the alternatives are to either live with the delta (which I think is not a good idea) or add USB ifdefs to timefuncs.c (which I think is even worse) 21.59.21 Quit LambdaCalculus37 () 22.00.05 # gevaerts: I think I agree with moving that function into usb_storage - it's the least worst option... 22.03.17 # I dont see the problem with adding USB ifdefs to timefuncs... 22.03.31 # I thing that is far less bad than adding timefuncs to the usb storage drivre 22.03.59 Part pyro_maniac ("Leaving.") 22.04.02 # New commit by 03gevaerts (r22259): Move yearday_to_daymonth() to usb_storage.c. It's the only user, this function is pretty specific, and it seems to be the cleanest way to avoid ram ... 22.04.34 # * kugel agrees with JdGordon| but won't argue further seeing it's too late :p 22.05.33 # will the volume affect battery life? i did two battery benches a few months ago and it didn't, but maybe i did something wrong... 22.05.50 Quit darkhamm (Read error: 110 (Connection timed out)) 22.05.52 Nick Jaykay_ is now known as Jaykay (n=chatzill@p5DDC5D2B.dip.t-dialin.net) 22.06.49 Quit merbanan ("Leaving") 22.07.08 Quit panni_ ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 22.07.44 Join panni_ [0] (i=hannes@ip-95-222-19-21.unitymediagroup.de) 22.07.54 # Zagor: how does this best fit work? I'm constantly getting the hardest build eventhough I don't have a particular strong client 22.08.25 # kugel: that means that that particular build just fits the expected round time on your client 22.08.52 # kugel: yes, you get the hardest build you are expected to be able to complete, plus some small builds to fill out the time 22.09.25 # ah, alright 22.16.17 # The graph does reflect that fairly well 22.16.28 # Lots of bars filling most of the round 22.17.03 Join Strife89 [0] (n=michael@adsl-220-100-163.mcn.bellsouth.net) 22.17.33 Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) 22.18.06 # JdGordon|: I tried your patch 22.18.14 # works great 22.18.20 # in and out? 22.18.35 # my video only logged in comms (or out... cant remembeer which) 22.18.41 # yes 22.19.20 # domonoky, found some m200v4 power management code, I'll see if I can compare it with the other targets 22.19.27 # is the log buffer a good size? 22.19.31 # nice :-) 22.20.30 # i just get a strange character before each log 22.20.45 # but it doesn't matter 22.21.09 Quit jgarvey (Read error: 110 (Connection timed out)) 22.21.33 # yeah, maybe some logic to make sure we dont try writing one byte at the start would be good 22.21.58 # also writing the \0 to the log file isnt a good idea yeah? 22.22.07 # also i was thinking about your dock power feature 22.22.20 # yes i agree 22.23.20 # did you get something like FF 55 XX 02 00 00 00 0X XX? 22.24.45 # my log is filled with IN 040200X000 where X is either 1 or 0 22.25.09 # also a few 0402000800 22.25.28 # Ok 22.26.04 # this is mode 2 of accessory protocol, which isn't complete yet 22.26.26 # and there is a power command which may be what you have 22.26.27 # it would be nice if more info was in the log.. like if the command was recognised 22.26.52 Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) 22.28.34 Join readabil1ty [0] (n=chad@206.248.173.89) 22.28.52 Quit pixelma_ (" .") 22.29.13 # And in apple mode, dthe power button put it in sleep mode or hibernate mode? 22.30.30 # sleep I'd guess.... havnt tried it 22.32.18 # we could, in rockbox mode, make it hibernate when it receive the power off signal 22.32.24 Quit J-23 (K-lined) 22.32.34 # except that we don't hibernate at all 22.32.50 # but i never tried the alarm feature, it can boot the ipod by itself? 22.33.15 # by hibernate, i mean power it off 22.33.18 # untill we get hibernate.. I'd expect power to be the same as play/pause 22.33.31 # or turn off completly 22.33.38 # yeah, the docks alarm should turn the ipod on 22.33.50 # ok 22.33.58 Quit Jaykay ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]") 22.34.37 # i'll try to add some others commands tomorrow 22.38.32 # did you made some experiments on you mini? 22.38.46 # for the serial 22.39.34 # no, didnt get around to it 22.39.58 Quit readability (Read error: 110 (Connection timed out)) 22.40.06 # New commit by 03bluebrother (r22260): Fix Rockbox Utility build on W32. 22.41.29 Quit TheSphinX^ ("XChat@Linux") 22.42.32 # put myself in sleep mode 22.42.41 # good night 22.43.58 Quit Creposucre ("CGI:IRC (EOF)") 22.46.36 Join dmb [0] (n=Dmb@unaffiliated/dmb) 22.52.41 Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) 22.53.36 Quit killan_ (Read error: 104 (Connection reset by peer)) 22.53.51 Join pamaury [0] (n=pamaury@sal63-1-82-243-96-220.fbx.proxad.net) 22.54.54 # Torne: are you there ? 22.55.00 # yes 22.56.03 # I made mistake in the patch of logf :) The logf in still buffy, I made a horrible computation error in the memcpy 22.56.15 Join killan [0] (n=nnscript@c-0efa70d5.06-397-67626721.cust.bredbandsbolaget.se) 22.56.16 # memcpy(ptr, buf + tlen,len-tlen); 22.56.36 # well apparently i didn't see it 22.56.42 # that's what you get for trusting me :) 22.56.55 # * Torne is not a dev or anything 22.57.14 # Yes, in fact len is decreasing by the loop so the correct code is: 22.57.21 # memcpy(ptr, buf + tlen,len); 22.57.21 # it was technically safe, if slightly obscure, with a strcpy for that 22.57.32 # ah yes 22.57.41 # nothing is ever easy 22.58.12 # This is horrible because len-tlen is often negative ! This can lead to a much undefined behaviour 22.58.47 # meh 22.58.50 # i wouldn't worry a great deal :) 22.59.00 # logf is compiled out by default, just poke someone to fix it 22.59.06 # it's not going to have broken anyone's actual build 23.00.23 # I will submit a patch to FS. These logf things will never be over :) 23.01.03 # New commit by 03gevaerts (r22261): Fix endpoint allocation ... 23.02.01 # gevaerts: Do we have any other working USB drivers, or is it just "arc" ? 23.02.10 # at least you spotted it 23.02.56 # well I had a nice surprise when doing some tests, I don't understand how I missed it 23.04.01 # linuxstb: we have more, but the others have quite different endpoint allocation, so I don't expect this bug there 23.04.56 # gevaerts: I was just asking in general, nothing to do with that commit 23.05.48 # ah, ok. We have arc, tcc, the one in the mr500, the ingenic one, and whatever is in the zvm (although that one probably is a bit behind) 23.05.52 # DarkSpectrum: are you running a cygwin server? 23.05.59 # yes 23.06.05 # updating it now 23.06.36 # it shows some weird warnings (known problem on cygwin and mingw) for the sims 23.07.00 # I guess easiest is to not let it build sdl 23.07.05 # hmmm.... ok i'll just run vmware then 23.07.12 # or i could do that 23.07.13 # pixelma: ah, does this affect newer gcc's too? 23.07.23 # no idea 23.07.59 # is sdl the only problem with cygwin? 23.07.59 # but yeah, easiest to drop sdl builds 23.08.16 # DarkSpectrum: vmware will be a bit faster, so probably more usefull 23.08.56 # vmware should be noticably faster ... 23.09.09 # do i want vmware player? 23.09.24 # yes, if going the vmware route. 23.09.52 # you should also be able to use VirtualBox and run the vmware image, though I've never tried that with the Rockbox vmware image. 23.10.11 # in case you prefer using VirtualBox 23.10.12 # only thing i've ever done is virtualpc, never vmware 23.11.27 # * bluebrother uses VirtualBox a lot. Especially for building releases of Rockbox Utility :) 23.11.35 # downloading vmware player now, i downloaded the RB vmware image a few months ago, does it change, hence should i grab a new copy? 23.12.05 # bluebrother: Have you thought about incorporating the 32MB/64MB detection into rbutil? 23.12.18 Join darkhamm [0] (n=darkhamm@95.234.18.47) 23.13.03 *** Saving seen data "./dancer.seen" 23.14.16 # linuxstb: yes. I also thought about the new time stuff :) 23.14.41 # What about the case when Rockbox USB is running? 23.14.45 # is 187 seconds the current buildround record? 23.15.00 # Bagder: that's actually wrong. it was a failed round. 23.15.02 # as for the 64MB detection I'd like to give multi device detection a go the same time. 23.15.07 # ah 23.15.22 # bluebrother: You mean more than one device connected at the same time? 23.15.25 # if Rockbox USB is running we still can figure the player by the rockbox-info.txt file 23.15.27 # DarkSpectrum's client seems to be... bad 23.15.41 # Bagder: yeah, cygwin is messy 23.15.42 # i killed it 23.15.44 # yes. domonoky made a patch for that a while ago, but unfortunately it's kinda outdated. 23.15.47 # Bagder: already solved 23.15.48 # setting up vmware 23.16.04 # bluebrother: Well, that assumes that file is correct... But I agree it's probably good enough. 23.16.20 # Bagder: I mean the "why" of it 23.16.32 # I'd like to get that finished, at least the basics, with better reporting of unsupported devices. Seems quite some people miss that. 23.17.03 # bluebrother: What does rbutil when it detects multiple devices, gives the user a choice? 23.17.08 # linuxstb: well, I thought about that too. The main problem I see is that we're going to wrongly detect the player once a wrong build has been installed. 23.17.52 # Is Rockbox USB enabled on ipods yet? 23.17.53 # currently it has no handling of multiple devices. It's even buggy in that aspect: I had two players connected a while ago, and it detected one player but the mountpoint of the other. 23.18.31 # it's enabled at least for svn builds. 23.18.41 # currently it just detects the first device it finds.. and the code could need improvement so it easier to extend to new targets. 23.18.46 # don't know about the lasest release. 23.19.09 # domonoky: spotted the bug I've mentioned? It gets confused with multiple devices 23.19.41 Join Stephen [0] (n=S@86-40-176-149-dynamic.b-ras2.srl.dublin.eircom.net) 23.19.42 # bluebrother: yes, thats because we have no way to map usb-ids to mountpounts.. 23.19.51 Nick Stephen is now known as Guest53570 (n=S@86-40-176-149-dynamic.b-ras2.srl.dublin.eircom.net) 23.20.01 Nick Guest53570 is now known as Stephen__ (n=S@86-40-176-149-dynamic.b-ras2.srl.dublin.eircom.net) 23.20.36 # not only. It's also because we trust USB IDs, and then fill in the missing parts, ignoring that the first matching USB ID could be something different than the first non-usb-detected player. 23.20.44 # yes 23.20.57 # multi-device detection could solve that.. 23.21.13 # it should :) 23.21.25 # though it isn't that easy, unfortunately 23.21.40 # at least we can present the user with a list and a warning if rbutil isnt sure what is what. 23.22.16 # Or simply tell the user to disconnect one... 23.22.25 Quit thegeek_ ("( www.nnscript.com :: NoNameScript 4.2 :: www.regroup-esports.com )") 23.22.48 # anyone with multiple robckboxable DAP's is probably an rb dev anyway :) 23.22.48 # allowing multiple devices to be connected is nicer ;-) 23.23.22 # n1s: Those warnings are mingw-sdl speficic, not cygwin only. They also appear when crosscompiling a win32 sim 23.23.40 # n1s: are we writing rbutil for users? ;-) 23.23.41 # It has nothing to do with gcc version, but with gcc target 23.23.52 # and it helps if we missdetect something, or can not distingush two targets.. or have multiple potential mountpoints for a device. 23.24.15 # amiconn: aha, is it because of -g together with -ffunction-sections? 23.24.17 Join J-23 [0] (n=kvirc@a105.net128.okay.pl) 23.24.29 # ... on win32 23.25.17 # Iiuc it's emitted when -ffunction-sections is used for some (gcc) targets. win32 is one of them 23.25.34 # There's a whole thread on the gcc ml regarding this warning... 23.25.47 # useful :/ 23.29.21 Quit domonoky (Read error: 104 (Connection reset by peer)) 23.31.30 # I have a question about tab allocation in functions. Why is it better to declare them as 'static' ? 23.31.51 # tab allocation? 23.32.20 # s/tab/array/ 23.32.24 Join ehntoo [0] (n=ehntoo@adsl-99-156-195-44.dsl.applwi.sbcglobal.net) 23.32.24 # because you then don't need to create them on the stack, *if* they are const 23.32.40 # so you save a bit of code 23.32.58 # but you waste a bit of ram 23.33.13 # Zagor: not really 23.33.17 # not if they are const, then they need to be there in the first place too 23.33.24 # right, not if they are const 23.44.38 # I don't see the difference between a static array and a static const array. They are both in the .data section of the executable ? 23.45.00 # A const array is in .rodata 23.45.16 # And on targets where rockbox can run from flash, this saves RAM 23.45.42 # .data needs to be copied to RAM in crt0, .rodata doesn't 23.46.34 # gevaerts: have you ever of "usb debug device" or "usb debug port" ? 23.46.40 # * ever head 23.46.40 Quit evilnick ("Page closed") 23.46.44 # *ever heard 23.47.00 # amiconn: thanks. I'm new to rockbox. Sorry for the noise. 23.47.33 # pamaury: not sure. What do you mean? 23.47.43 # what re you aksing about? 23.48.37 Quit DarkSpectrum (Read error: 104 (Connection reset by peer)) 23.48.39 Join DarkSpectrum- [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 23.48.43 Nick DarkSpectrum- is now known as DarkSpectrum (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 23.48.59 # gevaerts: just curious, I ran lsusb and the sansa receive a strange get_descriptor request, ask for 0xA type. But the usb spec does define such a descriptor so by using lsusb code I found out that it was a "debug descriptor' 23.49.27 # I don't know about it... 23.50.06 # I manage to find references about in EHCI doc and a strange "usb debug device" spec on google (but not on usb-if) 23.50.21 Quit petur (Remote closed the connection) 23.50.44 # yes, that's the low level debug functionality in some host chipsets and motherboards 23.54.04 # what is the rockbox vmware root login? 23.54.31 # ok 23.58.24 Quit darkhamm ("Sto andando via")