Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2009-08-11

00:00:08kugellinuxstb: 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:08linuxstbThe LCD looks fine there - i.e. there is an area of black between the top and the case.
00:01:39CIA-6New commit by 03kugel (r22245): Remove the comment also, Thanks to Rafaël Carré for spotting.
00:02:02kugellinuxguy3: 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:06kugelbut, 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:20kugellinuxguy3: 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:09saratogafor 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:54Zagorbuild-in-progress indicator now added
00:20:58ej0rgeThat'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:31bertrikdoes this also happen in the original firmware?
00:21:50 Quit JdGordon (Ping timeout: 180 seconds)
00:22:29CIA-6New commit by 03zagor (r22246): Added saving round information to db. Fixed bug in client speed calculation.
00:22:33ej0rgeyeah, they just don't print anything of consequence up there iirc
00:23:21ej0rgeTo 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:50ej0rgebertrik: 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:42ej0rgeI 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:28bertrikok, 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:54ej0rgeYeah. 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:42ej0rgeThere 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:55ej0rgekugel: 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:27kugelej0rge: thanks, but I was quite confident that it fixes the problem
00:53:33kugelI have a fuze too :)
00:54:16ej0rgeahh
00:54:34kugelbertrik: I don't think we should take it into account any further
00:54:45ej0rgeWell I'm a QA guy. It's not that we're untrusting, it's that we have a compulsion to verify.
00:54:58kugel:D
00:56:36bertrikkugel, ok agreed
00:56:39ej0rgeI 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:49ej0rgeand not "dur, uh . . . "
01:00
01:02:19 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk)
01:04:14 Quit faemir ("Leaving")
01:05:34saratogawould making crossfade a compile time option be attractive?
01:05:45 Quit captainkwel ("Page closed")
01:05:50saratogai'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:44bertriksaratoga, any idea how easy it is to make it a compile time option?
01:06:53saratogabertrik: rather hard
01:07:03saratogaits quite deeply embedded into both playback and buffering
01:08:07saratogaof 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:08linuxstbDoes 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:35bertrikI wouldn't mind it being a compile option, but I can't oversee the consequences yet
01:11:37saratogait only causes problems when enabled (it breaks playback entirely I believe)
01:11:56saratogamostly i was thinking about memory savings on low memory targets like AMS and TCC
01:12:05saratogathough I admit i don't know if it saves enough to be worthwhile
01:12:19saratogai presume it allocated memory only after its enabled right?
01:12:32***Saving seen data "./dancer.seen"
01:12:38linuxstbI've no idea, I've never enabled it...
01:12:49 Quit DarkSpectrum ()
01:14:35saratogait 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:26linuxstbI would imagine it just relies on a large enough PCM buffer - that's the only memory it needs.
01:17:23[1]niftywell there is a booter
01:17:33[1]niftyand a manipulator to get the firmware running on ipod touch :)
01:17:36[1]niftyjust 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:06JdGordoncrossfade is in the buffering code?!
01:20:39saratogapcmbuf rather
01:20:49saratoganot disk buffering
01:20:51JdGordonthats completly different
01:21:03saratogait takes up a substantial fraction of pcmbuf.c actually
01:21:15saratogai wish we hadn't allowed it to become so intertwined with basic pcm buffering
01:21:41JdGordonis that you volanteering to seperate them? :)
01:21:57saratoga:)
01:22:28saratogawell i have to run, still i'd be interested in knowing if having a compile time option for it is considered worthwhile
01:22:33saratogamight be more ifdef mess then its worth
01:23:14JdGordonspeaking 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:11linuxstbHow 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:49DarkSpectrumvolume normalizeing cross fading i think he means
01:26:18linuxstbWouldn't replaygain do that already?
01:29:04JdGordonyeah, DarkSpectrum got it
01:29:32JdGordoni 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:48linuxstbWouldn't replaygain do that already?
01:36:54JdGordondont 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:54linuxstbJdGordon: You add replaygain info to the tags. So it depends on your definition of modify...
01:46:13JdGordonyeah, ok
01:46:20JdGordonoh 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
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:16JdGordonhave we got a byte->hex function in rockbox anywhere?
02:05:16JdGordonwill 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:24saratogado we have a tool for checking bin size changes?
02:17:53kugelutils/analysis has 2
02:18:27saratogais either preferable to the other?
02:19:51kugelbloot-o-meter is a bit nicer output
02:22:22 Quit jgarvey ("Leaving")
02:33:29JdGordondoes 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:52saratogaactually 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:33saratogaonly 4 ifdefs to do it :)
02:58:41JdGordonwhy are you remoinving it?
02:58:45JdGordonjust because?
03:00
03:00:16saratogaits dead code on low mem targets, so i don't see any sense in leaving it in
03:00:28Unhelpfulgevaerts: 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:42saratogai can post the patch on the tracker for review
03:05:27Unhelpfulactually, 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:27Unhelpful...
03:07:17JdGordonslides in th
03:07:22JdGordon...
03:08:06 Quit yawnage ("leaving")
03:08:17 Join yawnage [0] (i=user36@i.am.at.war.with.firewar.us)
03:09:11CIA-6New 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:07JdGordonsaratoga: removing the menu saves 1.5K and 4 ifdefs? or from pcmbuf?
03:11:58JdGordonalso... 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:56saratogaJdGordon: 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:06saratogathe menus save 400 bytes
03:16:26saratogaremoving some of the cross fade code saves another 1700 bytes or so
03:16:38JdGordonI 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:51JdGordonyep, line 610 is what happens for dir/tag caches
03:19:59saratogathe build system says the savings is much larger then bloat-o-meter
03:21:51UnhelpfulJdGordon: 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:46Unhelpfulsaratoga: 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:04Unhelpfulalso, some of the targets have rather large section alignments, i think?
03:24:02JdGordonUnhelpful: I was saying you got cut off...
03:24:34 Join TruthTaco [0] (n=truthtac@adsl-74-10-158.aby.bellsouth.net)
03:24:38UnhelpfulJdGordon: in the corners. weird, xchat split overlong messages. :/
03:26:04rasherUnhelpful: not very well
03:26:56Unhelpfulrasher: 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:36rasherAh, you're not using xchat. I thought you were saying it was supposed to do it for you
03:31:07saratogaFS #10506 - Don't compile crossfade on lowmem targets
03:37:32kugelsaratoga: I think it should be HAVE_CROSSFADE, defined somewhere in the beginning of pcmbuf
03:38:03saratogakugel: in pcmbuf?
03:38:16kugelyea
03:38:32saratogabased on memory size?
03:38:38kugelalso, it seems you missed *crossfade_chunk, ir is it used elsewhere?
03:38:40kugelyea
03:39:35JdGordonnot in pcmbuf
03:39:38JdGordonin config.h
03:39:38saratogakugel: its used elsewhere and I prefer not to cut up functions with preprocessor junk to save a few bytes
03:41:47JdGordonMEMORYSIZE > 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:53n17ikhWith my sansa e260v1, USB only works the second time I plug it in after powering on. Is this a known bug?
03:43:12n17ikhit doesn't enumerate on the bus the first time I plug it in, but shows the "USB Mode" screen
03:43:18n17ikhthis using the latest daily build.
03:43:20kugelJdGordon: why?
03:43:28n17ikhbut if I re-plug it, it shows up fine
03:43:39n17ikhtested on vista, XP, and linux
03:45:21 Part kkurbjun
03:48:20saratogai tend to think the config files are neater as well
03:48:34JdGordonkugel: why what?>
03:49:19*Dhraakellian svn ups (svns up?) and compiles
03:49:22saratogai just don't feel like editing 50 of them
03:49:50kugelJdGordon: I was refering to your last sentence
03:50:12kugelsaratoga: I think he was saying config.h, not each config-target.h
03:50:46JdGordonkugel: ok, what does MEMSIZE > 2 actually mean? think about coming back to this code in 3 months and try to figure out...
03:50:56JdGordonHAVE_BLAA is 100000x more understandable
03:51:02saratogawell i did put a comment explaining it
03:51:12JdGordonand yes, I did mean a single #if in config.h not in each targets config
03:53:41kugelyea, I can agree with that
03:56:46saratogai guess I should change the stuff in settings too?
03:58:28Dhraakellianwhat's the status of the e200v2 port? roughly on par with the FuzeV1 port overall?
03:59:30saratogapretty much
03:59:37saratogacheck the current status link on the front page
04:00
04:00:25Dhraakellianyeah, I saw that they have pretty much the same greens and reds in the table
04:01:24DhraakellianI 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:29DhraakellianI could be misremembering
04:02:22saratogai think you are
04:02:42Dhraakelliangood to know without having to reread the entire thread
04:02:58saratogaok i'm going to commit the crossfade stuff now
04:05:42CIA-6New 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:10saratogafor 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:02saratogayou should be able to
04:11:29saratogabut it'll just crash as before
04:11:46saratogai don't like how the new build system shows all reds until the build finishes
04:11:49saratogaits a bit unnerving
04:12:11kugelyea that was weird
04:12:20saratogawoot 1750 bytes saved
04:13:21kugelsaratoga: you also deactivated replaygain and beep?
04:14:08 Quit Strife89 (Read error: 110 (Connection timed out))
04:14:28kugelhttp://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:48saratogahmm that is wrong
04:14:50saratogai'll fix it
04:18:41CIA-6New 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:21saratogarockboxdev.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:47JdGordonsaratoga: did that config.h change get into a #if SWCODEC block?
04:51:19saratogaprobably not, but it should never occur in code thats compiled elsewhere
04:51:47saratogaunless we do crossfade on hwcodec?
04:52:45JdGordoni dont know..
04:53:05JdGordonprobably would have been beter with the SWCODEC check.. but deltas suggest nothing changed so maybe dont worry
04:54:55saratogayeah pcmbuf.c is swcodec only
04:58:47 Join Blue_Dude [0] (n=chatzill@adsl-235-206-199.mco.bellsouth.net)
04:59:15Blue_DudeHi. Anyone have a chance to check out my patch to test_codec?
05:00
05:04:50saratogaBlue_Dude: i'll take a quick look at it now, but i probably shouldn't be the one to commit
05:05:31Blue_DudeOK. It adds a DSP benchmarking and wav writing function, as requested.
05:06:40saratogawhats the advantage of flipping around that enum?
05:07:42 Quit Zarggg ()
05:08:44Blue_DudeIt now reads in sequential order. Easier to see what "convert" is actually addressing.
05:11:26saratogaBlue_Dude: is there anyway to disable the screen fadeout while running test codec?
05:11:46Blue_DudeI don't know. It does fade back in when done though.
05:12:39***Saving seen data "./dancer.seen"
05:13:20saratogayeah i just wasn't sure how much cpu that uses
05:13:22saratogadoesn't matter for now
05:18:10saratogaso DSP uses about 2 MHz as we suspected
05:18:17saratogaif everything is off
05:19:02 Quit rasher (Read error: 60 (Operation timed out))
05:21:41Blue_DudeI'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:45saratogai wonder why dsp only takes interleaved audio when nearly all codecs internally work on seperate channels
05:24:10saratogaBlue_Dude: this looks fine to me
05:24:17saratogadid anyone else comment on it?
05:25:24Blue_DudeNo. 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:51saratoganot many people work with codecs, and even fewer of them are around these days
05:26:20saratogai'll ask around tomorrow and if no one else says anything i'll commit it then
05:26:27Blue_Dudek.
05:27:35Blue_DudeAs 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:39saratogaBlue_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:21saratogaalso, what target are you using?
05:31:30Blue_DudeDSP does seem pretty patched together. But it's relatively easy to add new functions though.
05:31:38Blue_DudeSansa E280
05:31:44saratogaah ok same as me
05:31:56Blue_DudeCool. Nice DAP.
05:31:57saratogaDSP is one of the cleaner parts of playback
05:32:17saratogaand generally works pretty well
05:32:25saratogathe rest of playback though
05:33:06Blue_DudeHang 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:25Blue_DudeBack. 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:46saratogathats been talked about for years
05:46:02Blue_DudeYeah, and who really wants to tackle that one?
05:46:12saratogai've been reading through pcmbuf.c tonight and its not really too bad once you ignore all the crossfade stuff
05:46:22saratogaplayback is a nightmare though
05:46:51Blue_DudeI'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:18saratogai feel bad for having waited all these years to look at what pcmbuf_insert actually does
05:48:02Blue_DudeI put that in the black box "don't need to know" category. :)
06:00
06:03:48 Quit kugel (Remote closed the connection)
06:04:14 Quit panni__ (Client Quit)
06:04:54safetydanat some point, wasn't there a state machine type diagram of playback?
06:07:11JdGordonthere have been at least 2 i think, showing different parts of it
06:10:40saratogai'd be vaguely interested in seeing that
06:13:18JdGordonit will be in the logs somewhere... i cant find it in my downloads.... nico did one
06:13:44saratogait'll be really intersting to see what causes the current low memory deadlocks in buffering
06:13:46JdGordondo a search in the logs for his full name (i tihnk thats his webhosting url)
06:13:55Blue_DudeWas playback actually designed or did it just grow that way?
06:14:13saratogamostly grew that way
06:14:24saratogathough at several points substantial parts of it have been rewritten
06:14:59JdGordonBlue_Dude: it used to be worse!
06:15:09Blue_DudeThat's scary...
06:16:14saratogadoes buffering work more or less the same in the sim?
06:16:37JdGordonfile reading you mean?
06:16:45JdGordonI assume its the exact same buffering code
06:16:50Blue_DudeI 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:52JdGordonthe difference is the disk layer
06:18:08saratogai wonder if the lowmemory deadlock problem is reproducible on the sim
06:19:34JdGordonis this the clip issue? or something else?
06:20:34saratogayeah
06:20:44saratogawell its any target with low enough memory
06:21:00saratogai can reproduce it on the fuze as well if i shrink the compressed buffer enough
06:21:11saratogai think the playback engine has some nasty assumptions about free memory built in
06:21:32JdGordonwhat do you mean free memory?
06:21:48saratogaerr, 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:46JdGordonyou mean an assumption about the minimum space avialble for the buffer?
06:23:58saratogayes, or rather the minimum buffer size
06:24:15JdGordonthere is a way to find out... a very tedious way....
06:24:26saratogasince apparently if you shrink it deadlocks become progressively more common
06:24:41JdGordonmangle playback to work with like 3mb on a 8mb target
06:24:53saratogathats what I did on my fuze
06:24:58saratogait 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:00
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:33safetydanit 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:00
08:05:07JdGordonwell 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:00
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:00
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:00
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:00
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:47pyro_maniacfunman: did you take a look at the yh-920 bootloader?
12:57:10pyro_maniaci mean had you ever?
12:57:42funmanyes, but didn't spend enough time on it for significant results/understanding
12:58:15pyro_maniaci was comparing the yh925 and the yh920 one
12:58:17 Join jernejovc [0] (n=jernejov@195.250.215.149)
12:58:55pyro_maniacbecause both have a codec test programm which look similar to each other
12:59:07pyro_maniacbut there seems to be a different value
12:59:34funmani had found the initialization code that lowlight wrote, but nothing else
13:00
13:00:30pyro_maniacso this codec test doesn't help in finding the error at yh920 sound?
13:01:20funmanno idea
13:01:35funmani think looking everywhere is the right thing to do
13:04:44pyro_maniaci thought this place would be the best because its a small area and better to overlook
13:05:02funmanthen 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:31Jaykayis 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:44pyro_maniacfunman. is line-in also handled by codec?
13:26:36funmanno idea
13:28:42pyro_maniacthere is a line-in test in the bootloader before the codec test. thats why i am asking.
13:35:10funmanlogfdump 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:47pamauryHello, 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:37Torneif you know the fix submit a patch
13:50:59funmanthe patch is already on the forum
13:52:10pamauryIs it sufficient to have it on the forum ?
13:52:41 Quit jernejovc (Read error: 110 (Connection timed out))
13:52:50Torneit's more likely to be noticed if you submit it to FS.
13:53:24funmanand come here regularly until someone takes a look at it :)
13:53:33pamauryok.
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:38pamauryI 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:45funmandircache.c doesn't check volume names (for mkdir("<microSD1>/.." for example) while dir_uncached.c seems to do
13:56:09Tornepamaury: that doesn't mean you can't post a patch
13:56:17Tornepost the patch and state what your concerns are about it
13:56:32TorneFS is the right place to put these things, it doesn't have to be a finished piece of work
13:56:49funmanpatches can be refined until they are acceptable
13:56:54pamauryok
13:57:26Tornethe more of the developers' work you can do for them the more likely it is to get dealt with quickly :)
13:58:38funmanhum 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
14:00:47gevaertspamaury: 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:48pamaurygevaert: 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:38funmani'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:39pamauryI have submitted it.
14:16:48funmanpamaury: thanks it works fine, i'll commit it
14:22:07CIA-6New commit by 03funman (r22250): Fix logfdump multilines handling ...
14:23:09pamaurygevaerts: 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:18funmanpamaury: thanks!
14:23:30gevaertspamaury: ok. I'll commit that fix later today
14:23:57pamauryI will submit it to FS anyway
14:27:02gevaertsok
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:09moosfunman: you missed the CREDITS part on this commit (salut btw)
14:29:30funmanmoos: right, gevaerts can you fix it in the next commit?
14:30:14 Join LambdaCalculus37 [0] (i=44a0430d@rockbox/staff/LambdaCalculus37)
14:30:20funmanusing "/<microSD1>/__TEST__" in test_disk.c works fine (leading / was missing) until creat()
14:30:27gevaertsfunman: you mean you forgot, and now I have to remember? ;)
14:30:47funmani mean it ! (my tree is dirty)
14:30:47mooshaha :D
14:30:51*gevaerts thinks that that is cheating! ;)
14:33:21funmanis 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:42funmanand i can't delete files in that directory
14:34:12funmaneject/insert/delete directory => unhandled IRQ 00 watchdog
14:35:36 Join panni_ [0] (i=hannes@ip-95-222-19-21.unitymediagroup.de)
14:39:34pamauryI 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:01funmanif characters have different widths, then no
14:42:14funmanfont_get_width() in font.c seems to say it's the case
14:45:18pamauryI'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:44tmztis there a reason for using a variable width font for the logging?
14:46:57tmztor is this because rockbox only supports one font?
14:48:26pamauryThis is probably because it uses the default font to display the log and the default font has wariable widths
14:48:58gevaertsnot on all targets
14:49:44Tornelcd_getstringsize returns the wrong answer if the font is variable width, is why
14:49:51Torneiirc
14:50:24Torneer, or am i thinking of something else
14:50:47GodEaterdoesn't it make more sense for the system font to be used to display the log ?
14:51:43Torneoh sorry, i'm thinking of the weird thing with puts
14:52:01Torneyes, lcd_getstringsize should work to see where to wrap/truncate the log
14:52:37pamauryThe 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:03funmanGodEater: the system font is fixed width, and easily usable?
14:53:39Tornecan't you just print a string that's too long anyway?
14:53:43GodEaterfunman: I don't recall - haven't written anything for rockbox is ages :)
14:53:46GodEaters/is/in
14:53:55Torneyes, you can :)
14:54:08Torneyou can just print it and it will get truncated in the course of lcd_putsxyofs
14:54:23Tornewhich just stops printing characters when it passes the current viewport width
14:54:35Torneso if you actually want truncation that's easy
14:55:19pamauryyes 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:23Tornetechnically that's doable anyway
14:56:28Tornejust go back and print the > afterward ;)
14:56:48pamauryyes :)
14:56:54TorneI dunno. just pointing out that lcd_puts truncates *anyway*.
14:57:58pamauryThe 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
15:00:38pamauryI will try to use the system font on my sansa, to see the result
15:00:46Jaykaysecond try: >is there any rule how builds should be named? (because of the incosistency documented in BuildNames)
15:01:32Tornepamaury: the system font is monospace which *generally* makes it fit less horizontally than the user font
15:01:43Torneunless the user has picked a particularly big user font
15:02:06funmanJaykay: no
15:02:27funmanthe name should be descriptive that's all
15:02:41Torneif 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:43Jaykaythen we wouldn't need BuildNames
15:02:56Jaykay"...so we can hopefully bring everything in line to make things less confusing. "
15:04:05pamauryyes, but I have no idea how many chars fit on my target. I doubt there is enough room for 30 chars
15:04:31Torneusing the system font at least means you will always know exactly how many chars *will* fit.
15:04:50Tornebut it probably reduces the average number of characters that will fit for most people
15:05:10funmanJaykay: 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:24Torneyou could always put the line continuation markers at the beginning of the continuing lines, instead of the end of the continued lines
15:06:59pamauryIt's true that just printing the line and letting the lcd code truncate would really simplify the code
15:07:18Jaykayfunman: so the configure names should persist and all the other names should be brought in line with the configure name?
15:08:22funmanJaykay: the configure name can be changed as well
15:08:56funmanTorne: putting the marker at the start of newline makes sense
15:09:24pamauryyes that's true
15:09:27funmangevaerts: did you try modifying test_disk base directory to "/<microSD1>/__TEST__" ?
15:09:50gevaertsno
15:09:56funmanthat's what I was doing but seeing if this approach works fine is disturbed by the AMS-specific bugs
15:10:39funmanperhaps i could try with a ramdisk
15:10:53Tornefunman: 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:12Jaykayhow 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:25Jaykayfor the more-ram-targest just add 64mb
15:11:27gevaertsfunman: ramdisk is a bit annoying because you have to format it first, which won't be easy on ams
15:11:52gevaertsJaykay: so "sansa e200"?
15:11:58Jaykayyes
15:12:03*gevaerts thinks he spots a flaw
15:12:36Jaykaygevaerts: where is the problem?
15:12:46amiconnfunman: test_disk works fine on the Ondio's MMC when changing the test dir to /<MMC1>/__TEST__
15:12:47gevaertsJaykay: *which* sansa e200?
15:12:51***Saving seen data "./dancer.seen"
15:13:15gevaertsJaykay: also, if you don't put in the manufacturer somewhere, you'll get duplicates (e.g. M3)
15:13:23amiconnIf it doesn't work on AMS, there must be a bug in the ams specific driver
15:13:28Jaykaygevaerts: i forgot... when there are different versions then just add the version (v2)
15:13:48funmanamiconn: thanks
15:14:04funmanthere 'must be' no bugs in ams specific driver
15:14:09Jaykaygevaerts: and it would be iaudiom3 and m3, but i see thats not perfect
15:14:17funmanthere 'are' bugs
15:14:20gevaertsJaykay: you're back to where we are now then
15:14:45 Join thegeek_ [0] (n=nnscript@s243b.studby.ntnu.no)
15:14:55Jaykaygevaerts: look at the configure names, they're different
15:16:10gevaertsJaykay: and?
15:16:45pamauryTorne: 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:50Jaykayyou said i would be back to where you are now... but the names are now different to my suggestion.
15:16:50gevaertsI can see they are different, but I have no idea why you point to that fact
15:17:12gevaertsso your suggestion is just "let's change the names a bit"?
15:17:13funmanJaykay: perhaps add a column with a proposed names
15:17:15Tornepamaury: it technically needs to be 30 though, for the char used for line continuation :)
15:18:02pamaurywell 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:26Jaykaygevaerts: exactly... for consistency, BuildNames says there should be consistency
15:18:28pamauryAnyway, it fir exactly while displaying a multiline so it should no be 30
15:18:33pamaury*fit
15:19:02Torneeach 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:03gevaertsJaykay: what you proposed does not give us consistency
15:19:12Jaykaywhy not?
15:19:16Torneit doesn't have a terminating null, it's padded with spaces
15:19:19gevaerts15:14 < Jaykay> gevaerts: and it would be iaudiom3 and m3, but i see thats not perfect
15:20:07funmanpamaury: your name is written with capitals ? (Amaury Pouly) i'll add you to the credits
15:20:10Jaykaygevaerts: iaudiom3 is consistent, m3 is the only proble... maybe we could take meizu there as the name of the series
15:20:14Tornepamaury: the buffer being used in logfdisplay is 31 bytes, to make room for the null.
15:20:18Jaykay*problem
15:20:28pamauryfunman: yes
15:20:31pamaurythanks
15:20:59CIA-6New commit by 03funman (r22251): Sansa AMS: identify interrupts with no source set ...
15:21:01CIA-6New commit by 03funman (r22252): Add Amaury Pouly to the credits
15:21:08pamauryTorne: 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:22pamauryTorne: the one just before the last one is a 0
15:21:35 Quit funman ("free(random());")
15:21:50pamauryso there are in reality 28 characters per line
15:22:30Torneno, you're wrong, sorry.
15:23:21Tornelogfbuffer is not null terminate at all; it happens that the byte for "single line" is a null.
15:23:39pamauryNo, see the bug report I submit today
15:23:58pamauryThe reason is simple:
15:24:02pamauryIn logf.c:
15:24:02pamaurystrlcpy(ptr, buf + tlen, MAX_LOGF_ENTRY);
15:24:08 Join kugel [0] (n=kugel@rockbox/developer/kugel)
15:24:36Torneah
15:24:44Tornethat means the change to strlcpy has changed the logf behaviour, then
15:24:54pamauryyes that's possible
15:25:02Torneit was previously *not* null terminated
15:25:25Tornebut it's been changed to do strlcpy instead :)
15:26:01pamauryThat would explain the logfdump bug
15:26:10TorneAnd now it no longe rbehaves as the comments in logf.c say
15:26:44Torneinteresting :)
15:27:28Tornehm, it still space-pads it though
15:27:31Tornethis is.. weird
15:27:37Tornei think this is broken :)
15:27:42kugelwhy's that line breaking such a problem? splash(f) does it fine too
15:27:44pamauryyes you're right
15:27:45Torneshould probably be changed back to memcpy
15:28:01Tornewrapped lines are being wrapped at 28 bytes then null terminated
15:28:12Tornenon-wrapped lines or the last bit of wrapped lines are being allowed to be 29 bytes, and space padded.
15:28:17Torneunless i'm misreading logf.c
15:28:39kugelwhere's the strlcpy?
15:28:50Tornein _logf
15:28:51Jaykaythe the build for ipodvideo also work on the ipodvideo64mb?
15:28:58TorneJaykay: yes
15:29:04Torneit just doesn't use all the ram
15:29:07pamaurycurrently, all lines are at most 28 characters long, whatever the type of line is
15:29:16Tornepamaury: no, they're not
15:29:27JaykayTorne: then why is there a separate download for it?
15:29:33TorneJaykay: because it doesn't use all the ram
15:29:41pamauryhum yes you right
15:30:01pamaurythere is a weird behaviour for string with length that is exactly MAX_LOGF_ENTRY
15:30:01Torner21863 has broken logf
15:30:25Tornepamaury: 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:34JaykayTorne: the last question: can configure build the 64mb version?
15:30:35Torner21863, the strlcpy change, has been done wrong.
15:30:45TorneJaykay: 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:55pamauryyes you can turn it the way you want :)
15:31:16Tornepamaury: 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:19JaykayTorne: ok, thanks
15:31:20pamaurybut 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:19Tornethe use of strlcpy should be changed to memcpy
15:32:19pamauryThen it should be noted that the logfdump code would be broken (because of my fix)
15:32:45kugelTorne: the \0 added for long strings is overwritten by LOGF_TERMINATE_CONTINUE_LINE isn't it?
15:32:51Jaykaywhy is the h10_5gb in rbutil named h10_5gbums/ h10_5gbmtp?
15:32:57Tornekugel: no, MAX_LOGF_ENTRY is 29
15:33:16Tornekugel: so it ends up with 28 bytes of string then the null then LOGF_TERMINATE_CONTINUE_LINE
15:33:20kugelso?
15:33:34Torneand there's no need for that to be strlcpy anyway; it's always copying exactly the same number of bytes :)
15:33:46kugelstrlcpy will add a \0 add ptr[MAX_LOGF_ENTRY] if the src is too long
15:33:55kugeland ptr[LOGF_TERMINATE_CONTINUE_LINE] is being overwritten
15:34:04pamauryno stlcpy will add a '0' ANYWAY
15:34:08Tornekugel: no it won't
15:34:15Torneit will add one at ptr[MAX_LOGF_ENTRY-1]
15:34:19pamaurybut it will add it at MAX_LOG_ENTRY-1
15:34:34kugeluhm
15:34:34kugelyea
15:34:46Tornesomeone should just change it to memcpy there
15:34:51pamaurythat's the definition of strlcpy: it will write at most MAX_LOG_ENTRY characters, INCLUDING the 0
15:34:52Tornebefore we do anything else with the log dumper :)
15:35:00kugelpamaury: I know
15:35:02Tornebecause changing th elog dumper to accomodate this bug is silly :)
15:35:17pamaurythat's what happened :)
15:35:34 Join evilnick [0] (i=0c140464@gateway/web/freenode/x-1ee78bf24d2c82c4)
15:35:36Torneoh, that already got committed? :)
15:35:44pamauryyes
15:36:06Torneand funman has gone :(
15:36:23kugelbut it should add a \0 if src is short, shouldn't it?
15:36:36Tornekugel: src is never short in that case
15:36:46kugelthat's weird code still!
15:36:47Tornekugel: the strlcpy only gets called when the original string is >MAX_LOGF_ENTRY
15:37:01Torneif you read the comment at the top of the file it says the buffer is space-padded with no terminators.
15:37:17pamauryI can write a patch for that and submit it after some testing
15:37:33Tornewhich is what it does with the strcpy lower down in the function.
15:37:58kugelit should've used memcpy in the first place
15:38:04Tornekugel: yes
15:38:31Torneoh wait
15:38:38Torneactually if you look at the diff it was wron gbefore as well :)
15:38:44Torneas it was doing strncpy with MAX_LOGF_ENTRY-1
15:38:56Torneso 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:24pamauryI have to leave, come back later
15:39:43Torneseveral previous sets of people appear to have had the same misunderstanding about how the logf buffer is supposed to work
15:40:37Tornethe multiline logf thing seems to have never really worked right, possibly, looking at the file history :)
15:40:53kugelwhat does the space-padding?
15:41:01Tornea few lines lower down
15:41:19Tornestrcpy(ptr, buf + tlen); then it pads with spaces
15:41:48Tornethat strcpy is also kinda weird. it will always work in this particulra case
15:42:26Tornebut 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:43TorneBoth of them should be memcpy really
15:43:13Tornesince it's not really null terminated strings being dealt with
15:43:17kugelor that weird code should be fixed to be human understandable
15:43:24TorneHehe
15:43:53Torneit's not entirely obvious *why* it's supposed to be space padded
15:44:17kugel"padded for easier and faster output on screen" doesn't make any sense for me
15:44:20Torneno.
15:44:25Torne...also, er
15:44:35Torneif we now support multiline logf anyway, with all this wrapping stuff
15:44:45Tornewhy is there even a fixed length record in the first place.
15:44:53Tornei'm not seeing hte advantage, tbh :)
15:45:19Tornea 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:58gevaertsthe starting address is slightly less clear
15:46:35Tornehow so?
15:48:33Tornelogfindex could just be bytes instead of records, i don't see how tha tmakes any difference for either side
15:48:37gevaertsI 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:04TorneOh, you mean the first line in the buffer being only the last bit
15:49:09Tornebecause of partial overwriting.
15:49:19gevaertsyes
15:49:27Torneyes, that's true.
15:49:37Tornebut you could just throw that line away, for all the difference it really makes
15:49:41Tornetruncated or not
15:49:56gevaertsSomething 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:10Tornebut it currently doens't use a fixed width font :)
15:50:19gevaertsit probably did originally I guess :)
15:50:23Torneif you have a free running circular buffer then you have no guarantee you are getting the right data nayway
15:50:26kugelI think it never did
15:50:30Torneyou are always going to drop stuff
15:50:41Torneso you can just throw away the first bit in the buffer, assuming it's been partially overwritten.
15:50:49Tornei mean the entire implementation here isn't threadsafe anyway
15:51:01gevaertskugel: sure it did. Remember the Player? :)
15:51:02Torneso the data already has a nonzero chance of being overwritten while you are in th emiddle of using it
15:51:07kugelzzz
15:51:11Torneand just being unreadable garbage to begin with
15:51:17Torne:)
15:51:38gevaertsTorne: remember cooperative multitasking? :)
15:52:01Torneoh right.
15:52:03Torne:)
15:52:09Torneyeah ok *apart* from that *g*
15:52:13gevaertskugel: seriously, I wouldn't be surprised if the space-padding idea is that old
15:52:29Tornei would guess that is why it's space padded, yes
15:52:56gevaertsand yes, in modern variable width font times it doesn't make much sense
15:53:39kugelgevaerts: 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:21Tornegevaerts: 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:00
16:08:54 Join Tristan [0] (n=Tristan@i.dont.want.to.die.virgin.net.in)
16:10:19pamauryhello 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:35pamauryhave you worked out the logf bug ?
16:19:17bertrikgevaerts, actually I did add some mutexes for the i2c and adc parts of the s5l8700
16:19:32gevaertsbertrik: interrupt contexts?
16:19:56bertrikthe 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:21bertrikyeah, mutexes can be problematic to use in interrupt context
16:20:38bertrikimpossible 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:08bertrikin 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:12pamauryTorne: are you there ?
16:24:19Tornepamaury: We've worked out that it definately doesn't behave as documented
16:24:29Torneand also that it's kinda confusing and is probably only that way for historical reasons
16:24:39Torneit could be put back to working as documented fairly easily i think
16:24:52Tornebut 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:56pamauryHow 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:39pamauryHaving only one big buffer and append at the end ?
16:27:19Blue_DudeI just posted a bug report at FS #10512 regarding problems with bookmarking. Has something changed recently?
16:27:41Tornepamaury: just treating it as a buffer of bytes, with each entry separated by a single null
16:27:54Tornei dunno tha tanyone agrees with me
16:27:57Tornebut it was a suggestion.
16:28:20pamaurywell it's would be much simpler, seeing how complex is the code just to support multiline
16:28:36pamaury(in logfdump for example)
16:28:39gevaertsTorne: one more problem with non-fixed-size would be that you can wrap around halfway a line
16:28:45Tornegevaerts: so?
16:28:52Tornedoes that matter?
16:29:06gevaertsno, it just adds code
16:29:13Torneprobably not more than it *removes*, though
16:29:16pamauryIt would move the complexing to the display code that would have to wrap correctly
16:30:04pamauryI agree with Torne that doing so would probably remove more code than it adds and the code would be more human understandable
16:31:13Tornethe advantages of the fixed length records were fine when we didn't allow people to logf more data than htat
16:31:20Tornenow it has the code to split lines anyway it seems less worthwhile
16:32:37pamaurythe inconvenient is that it would require a full screen redraw in logf if i'm correct
16:32:52gevaertswhy?
16:33:20pamaurybecause it would not be fixed-width
16:33:41pamaurywith space-padding, drawing a line erases the previous one, no ?
16:34:08gevaertsyes, but that doesn't mean you suddenly have to redraw the entire screen
16:34:32pamauryhow do you redraw only part of the screen if you scroll one line for example ?
16:37:21Torneer, it already redraws the whole screen when you scroll up and down, no?
16:37:48pamaurywell yes :)
16:37:52bertrikI think so too
16:38:12bertrikat least the parts that changed
16:39:45pamauryso I see only advantages to having one big buffer and entries separated by a single null
16:40:33Tornepamaury: the disadvantage is that the 'first' entry in the buffer may have been partially overwritten
16:40:51pamauryyes but it's the same thing with the actual code
16:41:03Tornebut at the moment you can *tell* there is a partially overwritten line
16:41:15Torneno, wait, you can't
16:41:20pamauryno you can't
16:41:21Tornebecause it doesn't mark the *first* continued line specially
16:41:27TorneHeh. 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:11pamauryTorne: 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:44Tornethat's just a special case of the first line being partially overwritten
16:48:54pamauryYes but that would introduce an extra blank line
16:48:58Torneso?
16:49:13Torneoverwriting one less byte would introduce an extra line with one useless character on it :)
16:49:40Torneif 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:35pamauryyes
16:54:30Torneanyway, 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:09pamauryI have written a fix for the actual code and tested it
16:55:26Torneyou also fixed the references to MAX_LOGF_ENTRY-1?
16:55:48Tornepastebin the diff somewhere?
16:56:41pamauryyes, do you a site where I can paste the diff ?
16:57:16evilnickpastebin? pastie.org
16:57:54pamauryhttp://pastie.org/580060
16:58:19pamauryIt also uses the system font to draw the log
16:59:07Tornethe fix to logf is fine
16:59:10Tornei 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:00:17pamauryWall it fixes logf, logfdump and logfdisp. I trick to use the system font optional
17:00:24pamaury*the trick
17:00:36Torneisn't it also necessary to revert the change that funman just committed
17:01:27pamauryyes that's what I was looking for
17:01:33Tornehttp://svn.rockbox.org/viewvc.cgi/trunk/apps/logfdisp.c?r1=20743&r2=22250
17:01:49pamauryI don't think I have the last version
17:01:53Torneand 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:54pamauryHum, 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:20Tornei would just leave the log display alone for now
17:03:23Tornefix one thing at a time
17:03:40Tornethe diff there to logf, plus reverting funman's change, should sort the actual problem
17:04:00Tornethe display issue is, well, just a display issue :)
17:04:40pamauryok, I change the diff and paste it
17:05:56pamauryShould I include the system font change or not ?
17:06:16Torneno. i think that has the potential to make it worse on average :)
17:07:00Tornethe display issue i think is better fixed in a different way
17:07:08pamauryhttp://pastie.org/580071
17:07:14Tornethere are several possible different ways. one of which is just to stop doing the fixed length records at all.
17:07:26Torne(but it could also rewrap the lines)
17:07:45pamauryYes, but we can still fix the existing code and write a new one later
17:07:48Tornepamaury: yah, that looks right to me. I mean i've not tried it or anything :)
17:08:02pamauryI will test it now
17:08:20Tornepamaury: 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:08Torneit might look better on your particular player but i don't think this is universal
17:09:39Tornerewrapping 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:02pamauryIt's not as complex
17:10:37Tornebut 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:44Torneso i don't think it's a good idea :)
17:11:18pamauryyes I agree
17:11:33pamaurybut it's a different problem than rewriting the underlying code
17:11:43TorneYes, but it's related
17:11:58TorneRewrapping the lines is the nicest fix, really
17:12:14Torne(which would be easier if done with sysfont, also)
17:12:32pamauryit'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:05Tornebut 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:30pamauryyes
17:13:57Torneanyway you should chuck the patch just to fix logf into FS
17:14:07Torneand poke funman if he comes back :)
17:15:12pamauryI'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:53pamauryfunman: 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:03pamaurys/add/had
17:53:14pamauryI submitted a patch to FS about it
17:53:19funmani'm reading the log
17:54:08funmanbertrik: mutexes are impossible to use in interrupt context, because they need a thread context
17:54:25bertrikyes I know
17:54:50bertrikI wonder what would happen in practice though when attempting to grab a mutex in interrupt context
17:55:37gevaertstry it!
17:55:44bertrikI wouldn't mind some kind of check on that
17:56:05 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother)
17:56:08funmani believe it acts like the thread running before the isr took the lock
17:56:52funmansince the thread is cores[CURRENT_CORE].running
17:56:57 Join TheSphinX^ [0] (n=cold@p54A5C007.dip.t-dialin.net)
18:00
18:01:41 Join Jaykay_ [0] (n=chatzill@p5DDC5D2B.dip.t-dialin.net)
18:01:56 Quit stoffel (Remote closed the connection)
18:02:50funmanpamaury: 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:01pamauryfunman: 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:40pamaurythis 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:55pamaurythis explain why logfdump was buggy
18:05:40funmanok i misread
18:06:12funmanlen & tlen are offset to the source pointer, not the dest pointer
18:06:40pamauryyes
18:07:31 Join stoffel [0] (n=quassel@p57B4CDC4.dip.t-dialin.net)
18:07:41pamaurythe 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:40funman:)
18:09:47 Join linuxstb [0] (n=root@rockbox/developer/linuxstb)
18:12:07CIA-6New commit by 03funman (r22253): Fix logf() multilines handling ...
18:12:29funmani hope you'll stop finding problems now!
18:13:41pamaurywell 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:05funmanif 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:53kugelpamaury: 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:31pamaurykugel: 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:35funmanpamaury: 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:01Tornefunman: it's not a huge thing..
18:29:15Tornethe suggestion was just to change logf to be a circular buffer of bytes, with messages separated by nulls
18:29:24Tornerather than a buffer of fixed length records with explicit continuation markers
18:29:27funmanlooks good to me
18:30:05Tornesince the fixed length records appear to exist to make it convenient to print it to the screen on the Player
18:30:06funmani won't be the one writing the patch though, perhaps i misunderstood pamaury's concern
18:30:11Tornewhich is a somewhat outdated requirement now
18:31:01pamauryno I'm not expecting you to write the code :)
18:31:36funmanpamaury: i mean i'm not sure why you want to be sure it needs to be rewritten
18:32:00gevaertsfunman: I guess s/needs to be rewritten/will be committed if rewritten/
18:32:03pamaurybecause otherwise it's useless :)
18:32:23pamaurygevaerts: yes
18:32:34funmancircular buffer with '\0' markers look simpler, so better, so committable
18:33:12funmanand buffer size adjustement would be simpler as well
18:33:14Tornepamaury: there's not much formality :)
18:33:36funmani'd say go for it!
18:34:17pamauryok. 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:53Tornewrapping the text is likely to come out as a bigger diff, yes :)
18:35:27funmani thought wrapping was made by lcd code?
18:36:26 Quit maruk ("Leaving.")
18:36:44pamauryno I don't think so, truncating yes, but not wrapping
18:37:38Tornefunman: lcd_puts* just truncate.
18:38:01funmanoh
18:38:12funmanlogfdump+texteditor ftw
18:38:22Torneheh
18:38:49Torneactually, *is* there a remotely sensible way to print wrapping text?
18:38:51 Quit petur ("work->home")
18:39:00Tornelcd_puts* have all the information to tell you where the wrap point is
18:39:06Tornebut then they throw that information away :)
18:39:40Tornewell, 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:29pamauryTorne: the lcd_puts function just call font_get_width for each character so it's quite easy to determine where to wrap
18:41:41Tornepamaury: yes, but that's what i mean
18:41:47Tornelcd_puts already calls font_get_width for every character
18:42:02Torneto implement wrapping yourself you would *also* need to do that, and then call lcd_puts on the result :)
18:42:05Tornethus doing the work twice.
18:42:24Torneplugins 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:36Tornebut for trivially just folding text around at the edge of the screen this seems kinda sucky ;)
18:44:05funmanthe code wouldn't be complex to write i think
18:44:37funmanlogf display isn't built by default, and the buffer can be dumped to a file
18:44:53Torneoh sure, i'm not suggesting it's a real problem
18:45:12Torneit 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:17pamauryanyway, 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:02kugelTorne: we really should have a lcd_puts_wrapped()
18:48:29kugelmaybe wait for Unhelpful committing his lcd driver unifying work
18:48:43funmanif lcd_puts() already has the info, there could be a parameter for wrapping
18:49:52Torneyeah, it knows when it's gone too wide.
18:50:05Torneit quits the loop once it's gone pas the edge of the screen
18:50:41funmannote that code usually tracks the line it is writing (as an argument to lcd_puts) and increment over it
18:51:21funmanyou wouldn't want to put the end of a long line on the line below and see if overwritten just after
18:51:26kugelfunman: that's putsxy, and wrapping obviously wouldn't work for it
18:51:31kugelIIRC
18:51:36Tornewhile we're on the topic.. lcd_puts (rather than putsxy) behaves *really weirdly* for proportional fonts :)
18:51:59pamaurywhy ?
18:52:03Torneif you pass an X coord other than 0 in a proportional font the position it writes to is very very odd
18:52:04funmanlcd_puts() takes the same argument than lcd_putsxy() : a x, a y, and a string
18:52:30Tornebecause 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:33Tornethen multiplying that by x
18:52:52pamauryah...
18:52:57pamauryweird...
18:52:57Tornewhich means printing "iii" and "MMM" go to different places on the screen
18:53:00Tornegiven the same coordinates :)
18:53:21pamauryonly the y coordinates in meaningful
18:53:30Torneit'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:35Torneand for proportional it's meaningless.
18:53:43funmankugel: lcd_putsxy takes pixel positions while lcd_puts takes characters position
18:53:46Torneit should probably use the width of some particulra character.
18:54:13funman'.'
18:55:12Torneheh, my instinct says '0'
18:55:17Torne(because that's what the z-machine says)
18:55:18Tornebut hey
18:55:30pamauryjust 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:22Tornelcd_putc doesn't exist on bitmap targets
18:56:44pamauryah, a good thing to know
18:56:44Tornealso that's a pain :)
18:57:20pamaurywhy doesn't it exist ? It could always be implemented with lcd_puts (it sucks but it's possible)
18:57:41funmanbecause it sucks
18:57:46saratogaatrac3 looks like fun to port to fixed point
18:57:57saratogathe code is clean and theres hardly any constants to convert
18:58:11Torneanwyay all this woul dbe better left until the lcd drivers were unified :)
18:59:07pamaurywhat will be the changes ?
18:59:37*Torne leaves for now though :)
19:00
19:00:39kugelpamaury: killing code duplication
19:00:41 Quit robin0800_ ("Leaving")
19:01:21pamaurybut will the api change ?
19:01:38kugelno
19:01:57funmani thought Unhelpful was only related to scrolling?
19:02:17funmanUnhelpful's work on lcd*
19:02:18kugelthat's another project :)
19:02:38CIA-6New 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:04n1ss/be/breaking the logf thingy/ :/
19:04:09 Quit darkhamm (Client Quit)
19:04:40funmann1s: 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:47kugelfunman: http://www.rockbox.org/tracker/task/4817
19:06:53kugeln1s: 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:32Blue_Dudekugel: bookmarking broke a few days back and I think I've traced it to a code cleanup you did (r22192/22193).
19:12:16Blue_DudeThe 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:02bluebrotherBagder: 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:35BagderI 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:50saratogaFS #10514 - itunes compatible time setting
19:31:43kugelBagder: it would absolutely awesome
19:31:49kugel+be
19:36:20Blue_Dudekugel: FS #10512
19:45:01LloreanIs 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:30n1sLlorean: think o
19:49:31n1sso
19:50:53 Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]")
19:51:21Lloreann1s: The threshold may be too low then
19:51:44LloreanMy 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:09n1syeah, that sounds plausible
19:54:40 Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net)
19:54:51CIA-6New 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:39n1sLlorean: the shutoff voltage is 3.4V
19:57:46saratogawill itunes sync time on a rockbox'ed ipod ?
19:59:51gevaertsI suspect not (unless we do the xml descriptor thing as well), but the ipod-time-sync tool from libgpod will
20:00
20:00:08gevaertsI also suspect that some future version of rbutil will
20:00:55gevaertsok, this is not good :\
20:01:57gevaertsI disclaim any responsibility for the red though
20:02:27Zagorthat's an odd error
20:07:16 Join darkhamm [0] (n=darkhamm@95.234.18.47)
20:07:17CIA-6New commit by 03gevaerts (r22256): Fix "statement with no effect" warning
20:07:33 Quit faemir ("Leaving")
20:08:33gevaertsWhat'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:02kugelI find the delta surprisingly high
20:10:09Zagorgevaerts: 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:09kugelit's little code added
20:12:28kugelhow about automatically calling bloat-o-meter? :)
20:13:35*gevaerts thinks he found something
20:13:40pixelmakugel: what about your WPS (or viewport?) code shuffle delta?
20:14:00kugelthat was weird also
20:14:07gevaertshm, no
20:14:54 Quit chandoo_ ("Leaving")
20:15:46Zagorperhaps 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:59bertrikhow did that work again?
20:17:20bertrikit only links the functions that are actually used, when linking against a library?
20:17:45Zagoryes. 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:50bertrikinstead 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:40evilnickDoes 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:04JdGordon|28 isnt it?
20:23:15JdGordon|+ 15 or so in progress
20:23:59gevaerts28ish 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:50CreposucreHi
20:31:32kugeldoes anyone mind introducing __attribute__((unused))?
20:31:46 Join p3tur [50] (n=petur@rockbox/developer/petur)
20:32:38kugelI 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:43bertrikI'd rather avoid using attributes unless absolutely necessary
20:33:24kugelwhy?
20:33:54bertrikit's something compiler-specific, I like doing stuff with plain C
20:34:06 Quit flydutch ("/* empty */")
20:34:18JdGordon|whats the point of the change?
20:34:29CreposucreDoes anyone know if any rockboxed or rockboxable player has a remote tuner?
20:35:03Creposucreexcept ipods
20:35:04JdGordon|Creposucre: hey, I added a slightly better logging patch to 9951.. dunno if oyu saw it
20:35:07kugelremoving various (void)var; (which isn't even optmized away always), make it clearer that a paramter may be unused
20:35:11JdGordon|(/me hoping he isnt confusing nicks)
20:36:12Creposucreno, i didn't saw it
20:36:15Creposucregonna try it ;)
20:37:24 Join darkhamm [0] (n=darkhamm@95.234.18.47)
20:38:34Creposucrei'll be right back
20:40:24 Quit pamaury ("Quitte")
20:42:21DarkSpectrumok i'm lookin to try out my m200v4, where is the page with firmware instructions?
20:42:43kugelI'm not trying to kill every (void)foo, but for certain functions, like callbacks
20:43:20bertrikwhat does the bloat-o-meter.py do?
20:43:22JdGordon|I tinhk adding that to the function is going to make it harder to read than adding a (void)foo; line
20:43:40Unhelpfulfunman: 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:16Unhelpfulbertrik: breaks down binary size changes per-symbol, showing which symbols have been added or removed, and which have changed size
20:45:22bertrikwhat kind of files does it take?
20:45:56domonokyDarkSpectrum: the SansaAMS wiki page contains install instructions for this.
20:46:07Unhelpfulany 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:50domonokyDarkSpectrum: installation is the similar for all AMS Sansa devices
20:47:21 Quit HellDragon (Read error: 54 (Connection reset by peer))
20:47:22bertrikDarkSpectrum, 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:57DarkSpectrumi 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:03bertrikalso, last time I tried it, I found the volume quite low already compared to other as3525 players
20:48:45bertrikDarkSpectrum, maybe you could have a look at fixing this if you feel like it
20:48:55domonokyyes, 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:52bertrikmy 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:30bertrikdomonoky, we (I even) could have a look at the OF powermanagement setup
20:52:34domonokythat would be good. (but i am not good enough with asm).
20:52:37kugelJdGordon|: how?
20:53:16DarkSpectrumi could test ;P
20:53:19bertrikdomonoky, I guess I can find it within an hour, I'll have a go at it tonight
20:53:23DarkSpectrumfigured out how to install
20:53:43JdGordon|I assume they get added like void foo(int bar __attribute__((unused)), int boo) ?
20:53:46kugelI'm using UNUSED_ATTR instead of __attribute__((unused)) directly
20:54:00kugellike this: enum plugin_status plugin_start(UNUSED_ATTR const void* parameter)
20:54:17CIA-6New commit by 03gevaerts (r22257): rework new time handling functions a bit to be more memory efficient
20:54:31JdGordon|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:26kugelJdGordon|: 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:25kugelit's not a no-op always
20:58:29kugelBagder tested it
20:58:34 Join FOAD [0] (n=dok@dinah.blub.net)
20:58:44kugelmuch code without -O2 for example
20:59:37gevaertsbetter, but not good enough
21:00
21:00:00*gevaerts means the delta, not the unused parameter things
21:00:38kugelI rather not count on gcc optimizing it if we can force it
21:00:47domonokythe question is: how much does it hurt ? in a place like plugin_start a extra instuction doesnt hurt.
21:01:21kugelthere are many places in the core too
21:01:39kugelI think it always hurts if we can avoid it easily
21:03:56Zagoradding compiler-specific kludges isn't exactly a pretty solution either. even if we are rather locked into gcc anyway.
21:05:59ZagorI'm split, personally. both solutions are rather ugly.
21:06:01kugelwe're heavily locked. and this unused won't even break other compilers, just give a few warnings
21:06:18Zagorwhere is it used in the core?
21:07:05kugelevent callbacks, a few functions which do nothing on #ifndef HAVE_XXX
21:07:10kugelfew other cases too
21:07:21 Quit stoffel (Read error: 104 (Connection reset by peer))
21:07:59kugelI 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:15kugelsome #if branches just exist for doing that (void)foo;
21:10:03gevaertsAny 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:25JdGordon|kugel: wait what? you can add (void)foo lines even if it is used
21:10:49JdGordon|but in any case... neither hsould be used when it *might* be used... or "partially" used
21:10:52kugelgevaerts: usb_storage seems a bad place :( maybe just a new usb_time.c?
21:11:11kugelJdGordon|: huh why neither?
21:11:12gevaertskugel: that doesn't sound much better I think
21:11:29kugelgevaerts: sounds much better to me, but that's just my opinion
21:11:46bluebrothergevaerts: 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:52JdGordon|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:59JdGordon|thats an abomination! :D
21:12:10JdGordon|(void)foo is much nicer in that case
21:12:13gevaertskugel: 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:34kugelJdGordon|: I can't agree with that
21:12:42JdGordon|you can and you will!!!
21:12:47*JdGordon| lays down the law!
21:12:49*bluebrother also likes (void)foo better
21:12:52saratogacant you just leave them where they are and add an ifdef?
21:12:53JdGordon|... not really :p
21:12:56kugelgevaerts: I'm more concerned of the _storage bit
21:12:59***Saving seen data "./dancer.seen"
21:13:01saratogaHAVE_TIME_FUNCTIONS
21:13:27bluebrothergevaerts: call it usb_misc.c? Or usb_kludge.c? ;-)
21:13:39bertrikgevaerts, what about Zagor's suggestion?
21:13:41DarkSpectrumin cygwin where is libsdl-dev
21:13:42DarkSpectrum?
21:13:51JdGordon|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:55bluebrotherin a cygwin package?
21:13:59JdGordon|screw the delta... it shuold go in time_funcs
21:14:11gevaertsbertrik: that's not going to be easy
21:14:15DarkSpectrumyes
21:14:35ZagorI agree the time code should stay in timefuncs. delta is not everything.
21:14:42bluebrothersimply #ifdef them ... that makes it clear that only USB_STORAGE uses them.
21:15:00saratogacan SD cards be powered down when they're not being read?
21:15:08kugelit doesn't have anything to do with storage IIUC
21:15:29bertrikI also wonder if these kind of functions (day of week etc.) are not already implemented somewhere else
21:15:39bluebrotherwhy doesn't it have anything to do with storage if only storage uses the functions?
21:16:44kugelbertrik: I think every rtc driver has some sort of day_of_weak()
21:17:27bertrikregarding 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:47kugelJdGordon|: 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:57pixelmait's been a weak day? ;)
21:18:16bluebrotherpixelma: definitely ;-)
21:18:22Zagorisn't the attribute put in plugin.h?
21:18:28JdGordon|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:51kugelno
21:18:58JdGordon|no?
21:19:16kugelit's also meant to indicate the parameter for a function type, not for single functions
21:20:15DarkSpectrumtrying to setup a build system and i can not find libsdl-dev
21:20:29DarkSpectrumerr 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:00kugelbertrik: this is -O0 vs -O2 http://pastie.org/580378
21:30:23CIA-6New commit by 03gevaerts (r22258): Consolidate day of week calculation
21:31:39Zagorkugel: surely it is not surprising that disabling optimisation does not optimise that?
21:32:12gevaertsAfter 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:12kugelno, not really
21:32:35kugel(for Zagor)
21:32:49kugelbut I think we don't build all targets with -O?
21:32:51JdGordon|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:03gevaertsJdGordon|: 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:41kugelDarkSpectrum: 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:59JdGordon|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:18gevaertsWhy 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:47gevaertsZagor: can you reschedule the build? I'd really like to see those deltas
21:38:08Zagoryes, I will
21:38:13gevaertsthanks
21:38:15kugeli think usb_storage.c is a bad place for even the RECEIVING_TIME case, what does it have to do with storage?
21:38:31gevaertskugel: we can rename it to usb_scsi...
21:38:47kugelwe should do so then
21:38:53gevaertsI can't move it out of there. It's part of the scsi handling
21:39:29kugelthe whole file seems to be a mix of storage and scsi
21:41:18gevaertsbut do we rename an entire file away from the expected name because it happens to handle one unrelated function?
21:42:15linuxstbIsn't storage and scsi basically the same thing?
21:42:36gevaertsusb storage is scsi, yes
21:42:47kugeland other stuff, apparently
21:42:55kugel:p
21:43:01linuxstbThen I don't see any problem. This time thing is a non-standard extension to UMS IIUC.
21:43:15gevaertskugel: no. usb_storage is also other things, usb storage isn't ;)
21:43:22linuxstb(or do I not UC?)
21:43:33kugelgevaerts: that's what I meant :)
21:44:15gevaertslinuxstb: 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:09JdGordon|UAS?
21:46:49kugelgevaerts: the tm struct could've been local to the case (minor picking :) )
21:46:49gevaertsUSB Attached SCSI. A new spec that properly does SCSI over USB instead of the hackish way that UMS uses
21:47:30gevaertsJdGordon|: if we hurry, we're first. Neither linux nor windows have it yet :)
21:47:53linuxstbThat would make testing an interesting challenge...
21:48:05tmztisn't the transport used for ATAPI/mmc enough?
21:48:15kugelgevaerts: neither wikipedia, apparently
21:48:15gevaertstmzt: huh?
21:48:29tmztfor SCSI commands I mean
21:48:36tmztoh, new spec
21:49:05tmztmmc is that case being what cd recorders use, not multimedia card
21:50:00gevaertsindeed. I'd like to do mmc at some point to allow pretending to be a CD drive to boot from
21:50:53gevaertsor possibly even to export playlists as CDs to the host :)
21:50:53JdGordon|with iso9660 mounting.....
21:51:32amiconnkugel: 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:42amiconngevaerts: 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:30gevaertsamiconn: 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:41gevaertsthe 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
22:00:05linuxstbgevaerts: I think I agree with moving that function into usb_storage - it's the least worst option...
22:03:17JdGordon|I dont see the problem with adding USB ifdefs to timefuncs...
22:03:31JdGordon|I thing that is far less bad than adding timefuncs to the usb storage drivre
22:03:59 Part pyro_maniac ("Leaving.")
22:04:02CIA-6New 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:33Jaykay_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:54kugelZagor: how does this best fit work? I'm constantly getting the hardest build eventhough I don't have a particular strong client
22:08:25gevaertskugel: that means that that particular build just fits the expected round time on your client
22:08:52Zagorkugel: 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:25kugelah, alright
22:16:17rasherThe graph does reflect that fairly well
22:16:28rasherLots 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:06Creposucre JdGordon|: I tried your patch
22:18:14Creposucreworks great
22:18:20JdGordon|in and out?
22:18:35JdGordon|my video only logged in comms (or out... cant remembeer which)
22:18:41Creposucreyes
22:19:20bertrikdomonoky, found some m200v4 power management code, I'll see if I can compare it with the other targets
22:19:27JdGordon|is the log buffer a good size?
22:19:31domonokynice :-)
22:20:30Creposucrei just get a strange character before each log
22:20:45Creposucrebut it doesn't matter
22:21:09 Quit jgarvey (Read error: 110 (Connection timed out))
22:21:33JdGordon|yeah, maybe some logic to make sure we dont try writing one byte at the start would be good
22:21:58JdGordon|also writing the \0 to the log file isnt a good idea yeah?
22:22:07Creposucrealso i was thinking about your dock power feature
22:22:20Creposucreyes i agree
22:23:20Creposucredid you get something like FF 55 XX 02 00 00 00 0X XX?
22:24:45JdGordon|my log is filled with IN 040200X000 where X is either 1 or 0
22:25:09JdGordon|also a few 0402000800
22:25:28CreposucreOk
22:26:04Creposucrethis is mode 2 of accessory protocol, which isn't complete yet
22:26:26Creposucreand there is a power command which may be what you have
22:26:27JdGordon|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:13CreposucreAnd in apple mode, dthe power button put it in sleep mode or hibernate mode?
22:30:30JdGordon|sleep I'd guess.... havnt tried it
22:32:18Creposucrewe could, in rockbox mode, make it hibernate when it receive the power off signal
22:32:24 Quit J-23 (K-lined)
22:32:34gevaertsexcept that we don't hibernate at all
22:32:50Creposucrebut i never tried the alarm feature, it can boot the ipod by itself?
22:33:15Creposucreby hibernate, i mean power it off
22:33:18JdGordon|untill we get hibernate.. I'd expect power to be the same as play/pause
22:33:31JdGordon|or turn off completly
22:33:38JdGordon|yeah, the docks alarm should turn the ipod on
22:33:50Creposucreok
22:33:58 Quit Jaykay ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]")
22:34:37Creposucrei'll try to add some others commands tomorrow
22:38:32Creposucredid you made some experiments on you mini?
22:38:46Creposucrefor the serial
22:39:34JdGordon|no, didnt get around to it
22:39:58 Quit readability (Read error: 110 (Connection timed out))
22:40:06CIA-6New commit by 03bluebrother (r22260): Fix Rockbox Utility build on W32.
22:41:29 Quit TheSphinX^ ("XChat@Linux")
22:42:32Creposucreput myself in sleep mode
22:42:41Creposucregood 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:54pamauryTorne: are you there ?
22:55:00Torneyes
22:56:03pamauryI 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:16pamaurymemcpy(ptr, buf + tlen,len-tlen);
22:56:36Tornewell apparently i didn't see it
22:56:42Tornethat's what you get for trusting me :)
22:56:55*Torne is not a dev or anything
22:57:14pamauryYes, in fact len is decreasing by the loop so the correct code is:
22:57:21pamaurymemcpy(ptr, buf + tlen,len);
22:57:21Torneit was technically safe, if slightly obscure, with a strcpy for that
22:57:32Torneah yes
22:57:41Tornenothing is ever easy
22:58:12pamauryThis is horrible because len-tlen is often negative ! This can lead to a much undefined behaviour
22:58:47Tornemeh
22:58:50Tornei wouldn't worry a great deal :)
22:59:00Tornelogf is compiled out by default, just poke someone to fix it
22:59:06Torneit's not going to have broken anyone's actual build
23:00
23:00:23pamauryI will submit a patch to FS. These logf things will never be over :)
23:01:03CIA-6New commit by 03gevaerts (r22261): Fix endpoint allocation ...
23:02:01linuxstbgevaerts: Do we have any other working USB drivers, or is it just "arc" ?
23:02:10Torneat least you spotted it
23:02:56pamaurywell I had a nice surprise when doing some tests, I don't understand how I missed it
23:04:01gevaertslinuxstb: we have more, but the others have quite different endpoint allocation, so I don't expect this bug there
23:04:56linuxstbgevaerts: I was just asking in general, nothing to do with that commit
23:05:48gevaertsah, 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:52pixelma_DarkSpectrum: are you running a cygwin server?
23:05:59DarkSpectrumyes
23:06:05DarkSpectrumupdating it now
23:06:36pixelma_it shows some weird warnings (known problem on cygwin and mingw) for the sims
23:07:00pixelma_I guess easiest is to not let it build sdl
23:07:05DarkSpectrumhmmm.... ok i'll just run vmware then
23:07:12DarkSpectrumor i could do that
23:07:13n1spixelma: ah, does this affect newer gcc's too?
23:07:23pixelma_no idea
23:07:59DarkSpectrumis sdl the only problem with cygwin?
23:07:59n1sbut yeah, easiest to drop sdl builds
23:08:16pixelma_DarkSpectrum: vmware will be a bit faster, so probably more usefull
23:08:56bluebrothervmware should be noticably faster ...
23:09:09DarkSpectrumdo i want vmware player?
23:09:24bluebrotheryes, if going the vmware route.
23:09:52bluebrotheryou 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:11bluebrotherin case you prefer using VirtualBox
23:10:12DarkSpectrumonly 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:35DarkSpectrumdownloading 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:05linuxstbbluebrother: 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:16bluebrotherlinuxstb: yes. I also thought about the new time stuff :)
23:14:41linuxstbWhat about the case when Rockbox USB is running?
23:14:45Bagderis 187 seconds the current buildround record?
23:15:00ZagorBagder: that's actually wrong. it was a failed round.
23:15:02bluebrotheras for the 64MB detection I'd like to give multi device detection a go the same time.
23:15:07Bagderah
23:15:22linuxstbbluebrother: You mean more than one device connected at the same time?
23:15:25bluebrotherif Rockbox USB is running we still can figure the player by the rockbox-info.txt file
23:15:27BagderDarkSpectrum's client seems to be... bad
23:15:41ZagorBagder: yeah, cygwin is messy
23:15:42DarkSpectrumi killed it
23:15:44bluebrotheryes. domonoky made a patch for that a while ago, but unfortunately it's kinda outdated.
23:15:47pixelma_Bagder: already solved
23:15:48DarkSpectrumsetting up vmware
23:16:04linuxstbbluebrother: Well, that assumes that file is correct... But I agree it's probably good enough.
23:16:20pixelma_Bagder: I mean the "why" of it
23:16:32bluebrotherI'd like to get that finished, at least the basics, with better reporting of unsupported devices. Seems quite some people miss that.
23:17:03linuxstbbluebrother: What does rbutil when it detects multiple devices, gives the user a choice?
23:17:08bluebrotherlinuxstb: 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:52linuxstbIs Rockbox USB enabled on ipods yet?
23:17:53bluebrothercurrently 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:31bluebrotherit's enabled at least for svn builds.
23:18:41domonokycurrently it just detects the first device it finds.. and the code could need improvement so it easier to extend to new targets.
23:18:46bluebrotherdon't know about the lasest release.
23:19:09bluebrotherdomonoky: 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:42domonokybluebrother: 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:36bluebrothernot 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:44domonokyyes
23:20:57domonokymulti-device detection could solve that..
23:21:13bluebrotherit should :)
23:21:25bluebrotherthough it isn't that easy, unfortunately
23:21:40domonokyat least we can present the user with a list and a warning if rbutil isnt sure what is what.
23:22:16linuxstbOr simply tell the user to disconnect one...
23:22:25 Quit thegeek_ ("( www.nnscript.com :: NoNameScript 4.2 :: www.regroup-esports.com )")
23:22:48n1sanyone with multiple robckboxable DAP's is probably an rb dev anyway :)
23:22:48bluebrotherallowing multiple devices to be connected is nicer ;-)
23:23:22amiconnn1s: Those warnings are mingw-sdl speficic, not cygwin only. They also appear when crosscompiling a win32 sim
23:23:40bluebrothern1s: are we writing rbutil for users? ;-)
23:23:41amiconnIt has nothing to do with gcc version, but with gcc target
23:23:52domonokyand it helps if we missdetect something, or can not distingush two targets.. or have multiple potential mountpoints for a device.
23:24:15n1samiconn: 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:29n1s... on win32
23:25:17amiconnIiuc it's emitted when -ffunction-sections is used for some (gcc) targets. win32 is one of them
23:25:34amiconnThere's a whole thread on the gcc ml regarding this warning...
23:25:47n1suseful :/
23:29:21 Quit domonoky (Read error: 104 (Connection reset by peer))
23:31:30UtchybannI have a question about tab allocation in functions. Why is it better to declare them as 'static' ?
23:31:51Zagortab allocation?
23:32:20Utchybanns/tab/array/
23:32:24 Join ehntoo [0] (n=ehntoo@adsl-99-156-195-44.dsl.applwi.sbcglobal.net)
23:32:24n1sbecause you then don't need to create them on the stack, *if* they are const
23:32:40n1sso you save a bit of code
23:32:58Zagorbut you waste a bit of ram
23:33:13n1sZagor: not really
23:33:17Bagdernot if they are const, then they need to be there in the first place too
23:33:24Zagorright, not if they are const
23:44:38UtchybannI 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:00amiconnA const array is in .rodata
23:45:16amiconnAnd on targets where rockbox can run from flash, this saves RAM
23:45:42amiconn.data needs to be copied to RAM in crt0, .rodata doesn't
23:46:34pamaurygevaerts: have you ever of "usb debug device" or "usb debug port" ?
23:46:40pamaury* ever head
23:46:40 Quit evilnick ("Page closed")
23:46:44pamaury*ever heard
23:47:00Utchybannamiconn: thanks. I'm new to rockbox. Sorry for the noise.
23:47:33gevaertspamaury: not sure. What do you mean?
23:47:43tmztwhat 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:59pamaurygevaerts: 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:27gevaertsI don't know about it...
23:50:06pamauryI 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:44tmztyes, that's the low level debug functionality in some host chipsets and motherboards
23:54:04DarkSpectrumwhat is the rockbox vmware root login?
23:54:31pamauryok
23:58:24 Quit darkhamm ("Sto andando via")

Previous day | Next day