| 00:00:08 | kugel | linuxstb: as naked as the fuze in that picture http://alhaz.fttp.xmission.com/gallery/8-3-09/IMG_0119 |
| 00:00:40 | | Join truthtaco_ [0] (n=truthtac@adsl-74-10-158.aby.bellsouth.net) |
| 00:01:08 | linuxstb | The LCD looks fine there - i.e. there is an area of black between the top and the case. |
| 00:01:39 | CIA-6 | New commit by kugel (r22245): Remove the comment also, Thanks to Rafaël Carré for spotting. |
| 00:02:02 | kugel | linuxguy3: that's not my fuze |
| 00:02:19 | | Join JdGordon [0] (i=209e4215@gateway/web/freenode/x-64c08d380b5b30e1) |
| 00:02:46 | | Quit petur (Remote closed the connection) |
| 00:03:06 | kugel | but, the going by the angle, it looks like at least 1 or 2 rows would also be cut off on that one (the black border between the red case and the display is from the case and you can't look through it) |
| 00:05:20 | kugel | linuxguy3: sorry for miss-pinging, I meant linuxstb |
| 00:07:28 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
| 00:11:51 | | Join saratoga [0] (i=9803c6dd@gateway/web/freenode/x-43de72077fb3971f) |
| 00:12:09 | saratoga | for what its worth my fuze probably cuts off the top pixel, though if i tilt it enough i can more or less see them all |
| 00:13:37 | | Quit bluebrother ("leaving") |
| 00:14:12 | | Part toffe82 |
| 00:14:46 | | Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) |
| 00:17:09 | | Quit TruthTaco (Read error: 110 (Connection timed out)) |
| 00:18:54 | Zagor | build-in-progress indicator now added |
| 00:20:58 | ej0rge | That's my fuze. And yeah it's a design issue - there's a black border that covers the first line or so of pixels depending on how you angle it. |
| 00:21:31 | bertrik | does this also happen in the original firmware? |
| 00:21:50 | | Quit JdGordon (Ping timeout: 180 seconds) |
| 00:22:29 | CIA-6 | New commit by zagor (r22246): Added saving round information to db. Fixed bug in client speed calculation. |
| 00:22:33 | ej0rge | yeah, they just don't print anything of consequence up there iirc |
| 00:23:21 | ej0rge | To be fair all of my fuzes are composites built from parts of other fuzes - but i could check the 5 other fuzes i have and see if they have the same feature |
| 00:24:20 | | Quit LambdaCalculus37 ("This computer has gone to sleep") |
| 00:24:51 | | Quit Zagor ("Clint excited") |
| 00:25:50 | ej0rge | bertrik: In the OF the top row of pixels is unusually bright, probably due to backlight optics. They use a fairly big blue border at the top, so this occult bezel could have been intentional |
| 00:27:42 | ej0rge | I mean the top bar of their 'while playing' screen is pretty wide compared to most rockbox WPS |
| 00:28:36 | | Quit tvelocity (Remote closed the connection) |
| 00:30:28 | bertrik | ok, hard to take stuff like that into account in rockbox in a clean way ... |
| 00:31:50 | | Nick DarkSpectrum- is now known as DarkSpectrum (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) |
| 00:31:54 | ej0rge | Yeah. If someone uses the status bar at the top it could potentially annoy |
| 00:34:30 | | Join HBK- [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
| 00:34:42 | ej0rge | There are certainly 2 versions of the fuze case (one version has three screws holding down the board, the other has two screws and a post) but i haven't noticed two versions of the LCD |
| 00:36:03 | | Quit ender` (" The reason they call it the American Dream is because you have to be asleep to believe it. -- George Carlin") |
| 00:38:30 | | Quit gregzx ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]") |
| 00:40:09 | | Quit KBH (Read error: 60 (Operation timed out)) |
| 00:42:17 | | Quit evilnick ("Page closed") |
| 00:43:47 | | Quit darkhamm (Connection timed out) |
| 00:44:55 | ej0rge | kugel: In case there was any curiosity, i can verify that r22245 fixes fs#10486 on my fuze |
| 00:45:21 | | Quit JdGordon_ ("Page closed") |
| 00:47:12 | | Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) |
| 00:51:28 | | Quit pixelma_ (" .") |
| 00:53:27 | kugel | ej0rge: thanks, but I was quite confident that it fixes the problem |
| 00:53:33 | kugel | I have a fuze too :) |
| 00:54:16 | ej0rge | ahh |
| 00:54:34 | kugel | bertrik: I don't think we should take it into account any further |
| 00:54:45 | ej0rge | Well I'm a QA guy. It's not that we're untrusting, it's that we have a compulsion to verify. |
| 00:54:58 | kugel | :D |
| 00:56:36 | bertrik | kugel, ok agreed |
| 00:56:39 | ej0rge | I may BELIEVE that something works, but if it breaks down the road i want to be able to say "It worked when i actually tried it" |
| 00:56:49 | ej0rge | and 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:34 | saratoga | would making crossfade a compile time option be attractive? |
| 01:05:45 | | Quit captainkwel ("Page closed") |
| 01:05:50 | saratoga | i'm thinking it might be nice to do so that it can be disabled on low memory targets like the clip where it doesn't work anyway |
| 01:06:44 | bertrik | saratoga, any idea how easy it is to make it a compile time option? |
| 01:06:53 | saratoga | bertrik: rather hard |
| 01:07:03 | saratoga | its quite deeply embedded into both playback and buffering |
| 01:08:07 | saratoga | of course since the feature doesn't work on the clip anyway, it can be done incrementally with the obvious parts removed first until nothing is left |
| 01:11:08 | linuxstb | Does it only cause problems when enabled, or does any the code itself cause issues? I'm assuming you have a smaller PCM buffer? |
| 01:11:35 | bertrik | I wouldn't mind it being a compile option, but I can't oversee the consequences yet |
| 01:11:37 | saratoga | it only causes problems when enabled (it breaks playback entirely I believe) |
| 01:11:56 | saratoga | mostly i was thinking about memory savings on low memory targets like AMS and TCC |
| 01:12:05 | saratoga | though I admit i don't know if it saves enough to be worthwhile |
| 01:12:19 | saratoga | i presume it allocated memory only after its enabled right? |
| 01:12:32 | *** | Saving seen data "./dancer.seen" |
| 01:12:38 | linuxstb | I've no idea, I've never enabled it... |
| 01:12:49 | | Quit DarkSpectrum () |
| 01:14:35 | saratoga | it works without a reboot, so I guess its not allocating anything |
| 01:15:12 | | Join DarkSpectrum [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) |
| 01:15:28 | | Quit bertrik ("sleep") |
| 01:16:26 | linuxstb | I would imagine it just relies on a large enough PCM buffer - that's the only memory it needs. |
| 01:17:23 | [1]nifty | well there is a booter |
| 01:17:33 | [1]nifty | and a manipulator to get the firmware running on ipod touch :) |
| 01:17:36 | [1]nifty | just informing |
| 01:17:49 | * | linuxstb can understand crossfade being embedded into the playback code, but why buffering? |
| 01:18:47 | * | linuxstb can't see any references to crossfade in buffering.c |
| 01:20:06 | JdGordon | crossfade is in the buffering code?! |
| 01:20:39 | saratoga | pcmbuf rather |
| 01:20:49 | saratoga | not disk buffering |
| 01:20:51 | JdGordon | thats completly different |
| 01:21:03 | saratoga | it takes up a substantial fraction of pcmbuf.c actually |
| 01:21:15 | saratoga | i wish we hadn't allowed it to become so intertwined with basic pcm buffering |
| 01:21:41 | JdGordon | is that you volanteering to seperate them? :) |
| 01:21:57 | saratoga | :) |
| 01:22:28 | saratoga | well i have to run, still i'd be interested in knowing if having a compile time option for it is considered worthwhile |
| 01:22:33 | saratoga | might be more ifdef mess then its worth |
| 01:23:14 | JdGordon | speaking of which.... is it techinally possible for the output volume to gradually change up/down between tracks if they arnt about the same volume? |
| 01:25:11 | linuxstb | How can you "gradually change" "between tracks? There is no time between tracks. |
| 01:25:44 | | Join fyrestorm [0] (n=nnscript@cpe-24-90-84-159.nyc.res.rr.com) |
| 01:25:49 | DarkSpectrum | volume normalizeing cross fading i think he means |
| 01:26:18 | linuxstb | Wouldn't replaygain do that already? |
| 01:29:04 | JdGordon | yeah, DarkSpectrum got it |
| 01:29:32 | JdGordon | i dont want to actually do anything to my tracks... just not go deaf when going from a very quiet track to a loud one |
| 01:32:48 | linuxstb | Wouldn't replaygain do that already? |
| 01:36:54 | JdGordon | dont you need to modify the files to do it? |
| 01:37:06 | | Quit bmbl ("Bye!") |
| 01:39:57 | | Join moos [0] (i=mustapha@rockbox/staff/moos) |
| 01:42:32 | | Quit truthtaco_ ("Leaving") |
| 01:43:49 | | Quit efyx (Remote closed the connection) |
| 01:45:54 | linuxstb | JdGordon: You add replaygain info to the tags. So it depends on your definition of modify... |
| 01:46:13 | JdGordon | yeah, ok |
| 01:46:20 | JdGordon | oh well |
| 01:47:23 | | Join ehntoo [0] (n=ehntoo@adsl-99-156-195-44.dsl.applwi.sbcglobal.net) |
| 01:54:25 | | Quit Thundercloud (Remote closed the connection) |
| 02:00 |
| 02:00:58 | | Quit Rondom (Nick collision from services.) |
| 02:01:09 | | Join Rondom [0] (n=Rondom@dslb-084-057-173-035.pools.arcor-ip.net) |
| 02:01:16 | JdGordon | have we got a byte->hex function in rockbox anywhere? |
| 02:05:16 | JdGordon | will http://pastebin.com/m6e1072dc work? |
| 02:05:22 | * | JdGordon is half asleep |
| 02:09:00 | * | JdGordon cheats and copies printf's MUCH simpler way of doing it :p |
| 02:11:31 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
| 02:15:52 | | Join CaptainKwel [0] (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) |
| 02:17:24 | saratoga | do we have a tool for checking bin size changes? |
| 02:17:53 | kugel | utils/analysis has 2 |
| 02:18:27 | saratoga | is either preferable to the other? |
| 02:19:51 | kugel | bloot-o-meter is a bit nicer output |
| 02:22:22 | | Quit jgarvey ("Leaving") |
| 02:33:29 | JdGordon | does anyone know who the face in http://www.rockbox.org/twiki/pub/Main/TowerOfRockbox/empirerockboxbuilding.jpg is ? |
| 02:35:45 | | Join Strife89 [0] (n=michael@adsl-146-208-210.mcn.bellsouth.net) |
| 02:44:56 | | Quit GeekShadow ("The cake is a lie !") |
| 02:51:19 | | Quit stripwax ("http://miranda-im.org") |
| 02:53:52 | saratoga | actually disabling most of the crossfade code is pretty easy and saves almost 1.5KB extra so I think i'm going to do it |
| 02:56:33 | saratoga | only 4 ifdefs to do it :) |
| 02:58:41 | JdGordon | why are you remoinving it? |
| 02:58:45 | JdGordon | just because? |
| 03:00 |
| 03:00:16 | saratoga | its dead code on low mem targets, so i don't see any sense in leaving it in |
| 03:00:28 | Unhelpful | gevaerts: the PF renderer at present can't handle tilting slides around a horizontal axis. tilt on one axis or the other might be possible without *huge* code bloat. |
| 03:00:42 | saratoga | i can post the patch on the tracker for review |
| 03:05:27 | Unhelpful | actually, tilt-either-way might be a good idea *anyway*, to allow for rotating the display (pictureflow is *much* nicer in landscape than portrait layout). the whole display could be rotated without changing cache layout. tilting a non-rotated image on the other axis without more math would require storing both transposed and non-transposed copies of each slide in cache, and i'm not sure what 2D scrolling would want to do with slides in th |
| 03:05:27 | Unhelpful | ... |
| 03:07:17 | JdGordon | slides in th |
| 03:07:22 | JdGordon | ... |
| 03:08:06 | | Quit yawnage ("leaving") |
| 03:08:17 | | Join yawnage [0] (i=user36@i.am.at.war.with.firewar.us) |
| 03:09:11 | CIA-6 | New commit by saratoga (r22247): Disable crossfade menu option (but nothing more) on lowmem (<=2MB) targets because it apparently needs a larger PCM buffer then is available. |
| 03:11:07 | JdGordon | saratoga: removing the menu saves 1.5K and 4 ifdefs? or from pcmbuf? |
| 03:11:58 | JdGordon | also... those should maybe be changed to HAVE_CROSSFADE, that deing defined in config.c for #if CONFIG_CODEC == SWCODEC && MEMORYSIZE > 2 |
| 03:12:36 | *** | Saving seen data "./dancer.seen" |
| 03:15:56 | saratoga | JdGordon: yes I was thinking that as well, though I wasn't sure if its preferable to have it in the config files or not |
| 03:16:06 | saratoga | the menus save 400 bytes |
| 03:16:26 | saratoga | removing some of the cross fade code saves another 1700 bytes or so |
| 03:16:38 | JdGordon | I think something like crossfade where we want it on every target that can have it, it should go in config.h like dircache (iirc) |
| 03:17:27 | | Join bubsy [0] (i=Bubsy@94.139.72.137) |
| 03:17:51 | JdGordon | yep, line 610 is what happens for dir/tag caches |
| 03:19:59 | saratoga | the build system says the savings is much larger then bloat-o-meter |
| 03:21:51 | Unhelpful | JdGordon: gevaerts suggested 2D scrolling in PF... in the other channel, so perhaps he was joking. it may not be a *completely* stupid idea, though. :) |
| 03:22:46 | Unhelpful | saratoga: i don't think those tools account for any alignment padding at all, so they may be leaving out quite a bit of space if we have targets where function or symbol alignment is larger than one instruction or one int. |
| 03:23:04 | Unhelpful | also, some of the targets have rather large section alignments, i think? |
| 03:24:02 | JdGordon | Unhelpful: I was saying you got cut off... |
| 03:24:34 | | Join TruthTaco [0] (n=truthtac@adsl-74-10-158.aby.bellsouth.net) |
| 03:24:38 | Unhelpful | JdGordon: in the corners. weird, xchat split overlong messages. :/ |
| 03:26:04 | rasher | Unhelpful: not very well |
| 03:26:56 | Unhelpful | rasher: yes, but at least people could figure out what i was saying when i used xchat. quassel doesn't tell me i'm over any limit, and i can't see that my message was truncated. |
| 03:27:36 | rasher | Ah, you're not using xchat. I thought you were saying it was supposed to do it for you |
| 03:31:07 | saratoga | FS #10506 - Don't compile crossfade on lowmem targets |
| 03:37:32 | kugel | saratoga: I think it should be HAVE_CROSSFADE, defined somewhere in the beginning of pcmbuf |
| 03:38:03 | saratoga | kugel: in pcmbuf? |
| 03:38:16 | kugel | yea |
| 03:38:32 | saratoga | based on memory size? |
| 03:38:38 | kugel | also, it seems you missed *crossfade_chunk, ir is it used elsewhere? |
| 03:38:40 | kugel | yea |
| 03:39:35 | JdGordon | not in pcmbuf |
| 03:39:38 | JdGordon | in config.h |
| 03:39:38 | saratoga | kugel: its used elsewhere and I prefer not to cut up functions with preprocessor junk to save a few bytes |
| 03:41:47 | JdGordon | MEMORYSIZE > 2 is definetly not the way to do it :) |
| 03:42:43 | | Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
| 03:42:53 | n17ikh | With my sansa e260v1, USB only works the second time I plug it in after powering on. Is this a known bug? |
| 03:43:12 | n17ikh | it doesn't enumerate on the bus the first time I plug it in, but shows the "USB Mode" screen |
| 03:43:18 | n17ikh | this using the latest daily build. |
| 03:43:20 | kugel | JdGordon: why? |
| 03:43:28 | n17ikh | but if I re-plug it, it shows up fine |
| 03:43:39 | n17ikh | tested on vista, XP, and linux |
| 03:45:21 | | Part kkurbjun |
| 03:48:20 | saratoga | i tend to think the config files are neater as well |
| 03:48:34 | JdGordon | kugel: why what?> |
| 03:49:19 | * | Dhraakellian svn ups (svns up?) and compiles |
| 03:49:22 | saratoga | i just don't feel like editing 50 of them |
| 03:49:50 | kugel | JdGordon: I was refering to your last sentence |
| 03:50:12 | kugel | saratoga: I think he was saying config.h, not each config-target.h |
| 03:50:46 | JdGordon | kugel: ok, what does MEMSIZE > 2 actually mean? think about coming back to this code in 3 months and try to figure out... |
| 03:50:56 | JdGordon | HAVE_BLAA is 100000x more understandable |
| 03:51:02 | saratoga | well i did put a comment explaining it |
| 03:51:12 | JdGordon | and yes, I did mean a single #if in config.h not in each targets config |
| 03:53:41 | kugel | yea, I can agree with that |
| 03:56:46 | saratoga | i guess I should change the stuff in settings too? |
| 03:58:28 | Dhraakellian | what's the status of the e200v2 port? roughly on par with the FuzeV1 port overall? |
| 03:59:30 | saratoga | pretty much |
| 03:59:37 | saratoga | check the current status link on the front page |
| 04:00 |
| 04:00:25 | Dhraakellian | yeah, I saw that they have pretty much the same greens and reds in the table |
| 04:01:24 | Dhraakellian | I just thought I remembered seeing some stuff in the test build thread and such about different sets of issues compared to the Fuze |
| 04:01:29 | Dhraakellian | I could be misremembering |
| 04:02:22 | saratoga | i think you are |
| 04:02:42 | Dhraakellian | good to know without having to reread the entire thread |
| 04:02:58 | saratoga | ok i'm going to commit the crossfade stuff now |
| 04:05:42 | CIA-6 | New commit by saratoga (r22248): FS #10506. Don't compile various crossfade only functions in pcmbuf.c on low memory targets (mainly AMS) to save memory. Some crossfade related items ... |
| 04:06:08 | | Quit TheSeven (Nick collision from services.) |
| 04:06:10 | saratoga | for what its worth, my clip still deadlocked after an hour with these changes, so crossfade was unlikely to have been the source of our playback problems |
| 04:06:24 | | Join The_Seven [0] (n=theseven@dslb-084-056-175-088.pools.arcor-ip.net) |
| 04:06:28 | | Nick The_Seven is now known as TheSeven (n=theseven@dslb-084-056-175-088.pools.arcor-ip.net) |
| 04:09:22 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 04:10:13 | * | kugel wonders where you still can enable (or try to...) from a settings file |
| 04:11:02 | saratoga | you should be able to |
| 04:11:29 | saratoga | but it'll just crash as before |
| 04:11:46 | saratoga | i don't like how the new build system shows all reds until the build finishes |
| 04:11:49 | saratoga | its a bit unnerving |
| 04:12:11 | kugel | yea that was weird |
| 04:12:20 | saratoga | woot 1750 bytes saved |
| 04:13:21 | kugel | saratoga: you also deactivated replaygain and beep? |
| 04:14:08 | | Quit Strife89 (Read error: 110 (Connection timed out)) |
| 04:14:28 | kugel | http://svn.rockbox.org/viewvc.cgi/trunk/apps/settings_list.c?r1=22247&r2=22246&pathrev=22247 < that diff suggests that, And I think loading it via config.cfg shouldn't be possible if the code doesnt run (deactivated in pcfbuf.c) |
| 04:14:48 | saratoga | hmm that is wrong |
| 04:14:50 | saratoga | i'll fix it |
| 04:18:41 | CIA-6 | New commit by saratoga (r22249): Fix defines from the last commit that made replaygain depend on crossfade. Thanks to Thomas Martitz for pointing that out. |
| 04:19:21 | saratoga | rockboxdev.sh works on cygwin right? |
| 04:22:46 | | Quit ehntoo (Read error: 110 (Connection timed out)) |
| 04:29:59 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 04:38:17 | | Join darkhamm [0] (n=darkhamm@host106-36-dynamic.50-79-r.retail.telecomitalia.it) |
| 04:50:47 | JdGordon | saratoga: did that config.h change get into a #if SWCODEC block? |
| 04:51:19 | saratoga | probably not, but it should never occur in code thats compiled elsewhere |
| 04:51:47 | saratoga | unless we do crossfade on hwcodec? |
| 04:52:45 | JdGordon | i dont know.. |
| 04:53:05 | JdGordon | probably would have been beter with the SWCODEC check.. but deltas suggest nothing changed so maybe dont worry |
| 04:54:55 | saratoga | yeah pcmbuf.c is swcodec only |
| 04:58:47 | | Join Blue_Dude [0] (n=chatzill@adsl-235-206-199.mco.bellsouth.net) |
| 04:59:15 | Blue_Dude | Hi. Anyone have a chance to check out my patch to test_codec? |
| 05:00 |
| 05:04:50 | saratoga | Blue_Dude: i'll take a quick look at it now, but i probably shouldn't be the one to commit |
| 05:05:31 | Blue_Dude | OK. It adds a DSP benchmarking and wav writing function, as requested. |
| 05:06:40 | saratoga | whats the advantage of flipping around that enum? |
| 05:07:42 | | Quit Zarggg () |
| 05:08:44 | Blue_Dude | It now reads in sequential order. Easier to see what "convert" is actually addressing. |
| 05:11:26 | saratoga | Blue_Dude: is there anyway to disable the screen fadeout while running test codec? |
| 05:11:46 | Blue_Dude | I don't know. It does fade back in when done though. |
| 05:12:39 | *** | Saving seen data "./dancer.seen" |
| 05:13:20 | saratoga | yeah i just wasn't sure how much cpu that uses |
| 05:13:22 | saratoga | doesn't matter for now |
| 05:18:10 | saratoga | so DSP uses about 2 MHz as we suspected |
| 05:18:17 | saratoga | if everything is off |
| 05:19:02 | | Quit rasher (Read error: 60 (Operation timed out)) |
| 05:21:41 | Blue_Dude | I've only tried running it on target once. I was doing a before/after of a dsp.c change, not really looking at DSP/non-DSP. There is some overhead but I didn't write down how much. |
| 05:23:44 | | Join rasher [0] (n=rasher@0x5550f5a3.adsl.cybercity.dk) |
| 05:23:45 | saratoga | i wonder why dsp only takes interleaved audio when nearly all codecs internally work on seperate channels |
| 05:24:10 | saratoga | Blue_Dude: this looks fine to me |
| 05:24:17 | saratoga | did anyone else comment on it? |
| 05:25:24 | Blue_Dude | No. I put it in three days ago. I'm a little surprised since it's apparently been on the wish list for a while. |
| 05:25:51 | saratoga | not many people work with codecs, and even fewer of them are around these days |
| 05:26:20 | saratoga | i'll ask around tomorrow and if no one else says anything i'll commit it then |
| 05:26:27 | Blue_Dude | k. |
| 05:27:35 | Blue_Dude | As for the interleaved audio, I think it's because that way you don't have to reserve separate buffers for each channel. ??? |
| 05:28:18 | | Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
| 05:30:39 | saratoga | Blue_Dude: yeah but it would be nice to have put that in DSP originally, instead of us having 2 dozen seperate functions to handle it |
| 05:31:21 | saratoga | also, what target are you using? |
| 05:31:30 | Blue_Dude | DSP does seem pretty patched together. But it's relatively easy to add new functions though. |
| 05:31:38 | Blue_Dude | Sansa E280 |
| 05:31:44 | saratoga | ah ok same as me |
| 05:31:56 | Blue_Dude | Cool. Nice DAP. |
| 05:31:57 | saratoga | DSP is one of the cleaner parts of playback |
| 05:32:17 | saratoga | and generally works pretty well |
| 05:32:25 | saratoga | the rest of playback though |
| 05:33:06 | Blue_Dude | Hang on. Duty calls. Back in a few... |
| 05:36:10 | | Quit Lss__ (Read error: 110 (Connection timed out)) |
| 05:43:02 | | Quit StealthyXIIGer (Read error: 110 (Connection timed out)) |
| 05:43:25 | | Quit [1]nifty (" HydraIRC -> http://www.hydrairc.com <- Wibbly Wobbly IRC") |
| 05:44:18 | | Join kkurbjun [0] (n=kkurbjun@rockbox/developer/kkurbjun) |
| 05:44:25 | Blue_Dude | Back. Anyway, I thought playback.c and pcmbuf.c were more than a little complex. It works, though I wonder if a rewrite would be more efficient. |
| 05:45:46 | saratoga | thats been talked about for years |
| 05:46:02 | Blue_Dude | Yeah, and who really wants to tackle that one? |
| 05:46:12 | saratoga | i've been reading through pcmbuf.c tonight and its not really too bad once you ignore all the crossfade stuff |
| 05:46:22 | saratoga | playback is a nightmare though |
| 05:46:51 | Blue_Dude | I'm pretty well versed in pcmbuf by now. You're dead on there. Playback is much harder to get through. |
| 05:47:06 | | Quit Horscht ("Verlassend") |
| 05:47:18 | saratoga | i feel bad for having waited all these years to look at what pcmbuf_insert actually does |
| 05:48:02 | Blue_Dude | I 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:54 | safetydan | at some point, wasn't there a state machine type diagram of playback? |
| 06:07:11 | JdGordon | there have been at least 2 i think, showing different parts of it |
| 06:10:40 | saratoga | i'd be vaguely interested in seeing that |
| 06:13:18 | JdGordon | it will be in the logs somewhere... i cant find it in my downloads.... nico did one |
| 06:13:44 | saratoga | it'll be really intersting to see what causes the current low memory deadlocks in buffering |
| 06:13:46 | JdGordon | do a search in the logs for his full name (i tihnk thats his webhosting url) |
| 06:13:55 | Blue_Dude | Was playback actually designed or did it just grow that way? |
| 06:14:13 | saratoga | mostly grew that way |
| 06:14:24 | saratoga | though at several points substantial parts of it have been rewritten |
| 06:14:59 | JdGordon | Blue_Dude: it used to be worse! |
| 06:15:09 | Blue_Dude | That's scary... |
| 06:16:14 | saratoga | does buffering work more or less the same in the sim? |
| 06:16:37 | JdGordon | file reading you mean? |
| 06:16:45 | JdGordon | I assume its the exact same buffering code |
| 06:16:50 | Blue_Dude | I had to wade into playback about 6 weeks ago to kill a bug. Took all friggin day and I ended up changing part of a single line to fix it. |
| 06:16:52 | JdGordon | the difference is the disk layer |
| 06:18:08 | saratoga | i wonder if the lowmemory deadlock problem is reproducible on the sim |
| 06:19:34 | JdGordon | is this the clip issue? or something else? |
| 06:20:34 | saratoga | yeah |
| 06:20:44 | saratoga | well its any target with low enough memory |
| 06:21:00 | saratoga | i can reproduce it on the fuze as well if i shrink the compressed buffer enough |
| 06:21:11 | saratoga | i think the playback engine has some nasty assumptions about free memory built in |
| 06:21:32 | JdGordon | what do you mean free memory? |
| 06:21:48 | saratoga | err, buffer memory |
| 06:22:44 | | Quit bah_ (Read error: 60 (Operation timed out)) |
| 06:22:51 | | Join bah_ [0] (n=bah@c-76-105-203-173.hsd1.wa.comcast.net) |
| 06:23:46 | JdGordon | you mean an assumption about the minimum space avialble for the buffer? |
| 06:23:58 | saratoga | yes, or rather the minimum buffer size |
| 06:24:15 | JdGordon | there is a way to find out... a very tedious way.... |
| 06:24:26 | saratoga | since apparently if you shrink it deadlocks become progressively more common |
| 06:24:41 | JdGordon | mangle playback to work with like 3mb on a 8mb target |
| 06:24:53 | saratoga | thats what I did on my fuze |
| 06:24:58 | saratoga | it deadlocks just as the clip |
| 06:38:35 | | Quit JdGordon (Remote closed the connection) |
| 06:41:25 | | Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) |
| 06:48:33 | | Quit CaptainKwel (Remote closed the connection) |
| 06:48:51 | | Join bmathis [0] (n=brian@c-71-195-184-199.hsd1.ca.comcast.net) |
| 06:50:53 | | Join jernejovc_ [0] (n=jernejov@195.250.215.149) |
| 06:53:04 | | Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) |
| 07: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:33 | safetydan | it should be same buffering code running on the sim |
| 07:31:49 | | Join stoffel [0] (n=quassel@p57B4CDC4.dip.t-dialin.net) |
| 07:43:17 | | Quit fyrestorm (Read error: 110 (Connection timed out)) |
| 07:48:37 | | Join Kumool [0] (n=Khwerz@adsl-72-50-69-137.prtc.net) |
| 07:49:49 | | Part safetydan ("Leaving.") |
| 07:59:49 | * | FlynDice has uSD playing at spec freqs on e280v2 31MHz and 15.5 MHz posting patch to FS |
| 08:00 |
| 08:05:07 | JdGordon | well done! |
| 08:18:28 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
| 08:18:53 | | Join Rob2223 [0] (n=Miranda@p4FDCD805.dip.t-dialin.net) |
| 08:27:07 | | Join flydutch [0] (n=flydutch@host214-146-dynamic.15-87-r.retail.telecomitalia.it) |
| 08:36:55 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
| 09: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:47 | pyro_maniac | funman: did you take a look at the yh-920 bootloader? |
| 12:57:10 | pyro_maniac | i mean had you ever? |
| 12:57:42 | funman | yes, but didn't spend enough time on it for significant results/understanding |
| 12:58:15 | pyro_maniac | i was comparing the yh925 and the yh920 one |
| 12:58:17 | | Join jernejovc [0] (n=jernejov@195.250.215.149) |
| 12:58:55 | pyro_maniac | because both have a codec test programm which look similar to each other |
| 12:59:07 | pyro_maniac | but there seems to be a different value |
| 12:59:34 | funman | i had found the initialization code that lowlight wrote, but nothing else |
| 13:00 |
| 13:00:30 | pyro_maniac | so this codec test doesn't help in finding the error at yh920 sound? |
| 13:01:20 | funman | no idea |
| 13:01:35 | funman | i think looking everywhere is the right thing to do |
| 13:04:44 | pyro_maniac | i thought this place would be the best because its a small area and better to overlook |
| 13:05:02 | funman | then it makes more sense to study it first |
| 13:05:07 | | Join darkhamm [0] (n=darkhamm@host106-36-dynamic.50-79-r.retail.telecomitalia.it) |
| 13:10:55 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
| 13:12:24 | | Join Jaykay [0] (n=chatzill@p5DDC57E9.dip.t-dialin.net) |
| 13:12:50 | *** | Saving seen data "./dancer.seen" |
| 13:15:31 | Jaykay | is there any rule how builds should be named? (i just looked at BuildNames) |
| 13:18:15 | | Join thegeek_ [0] (n=nnscript@s243b.studby.ntnu.no) |
| 13:25:44 | pyro_maniac | funman. is line-in also handled by codec? |
| 13:26:36 | funman | no idea |
| 13:28:42 | pyro_maniac | there is a line-in test in the bootloader before the codec test. thats why i am asking. |
| 13:35:10 | funman | logfdump bug report : http://forums.rockbox.org/index.php?topic=22442.0 |
| 13:36:40 | | Quit thegeek_ (Read error: 113 (No route to host)) |
| 13:36:53 | | Quit thegeek (Read error: 113 (No route to host)) |
| 13:39:52 | | Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) |
| 13:44:38 | | Join pamaury [0] (n=pamaury@sal63-1-82-243-96-220.fbx.proxad.net) |
| 13:47:02 | | Join AndyIL [0] (i=AndyI@212.14.205.32) |
| 13:47:45 | | Quit pyro_maniac (Read error: 60 (Operation timed out)) |
| 13:47:52 | | Quit gevaerts (Nick collision from services.) |
| 13:48:02 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 13:49:47 | pamaury | Hello, yesterday I wrote on the forum about the logfdump function being buggy (http://forums.rockbox.org/index.php?topic=22442.0). Should I submit a bug on FS or a patch (because the fix sseems simple) ? |
| 13:50:37 | Torne | if you know the fix submit a patch |
| 13:50:59 | funman | the patch is already on the forum |
| 13:52:10 | pamaury | Is it sufficient to have it on the forum ? |
| 13:52:41 | | Quit jernejovc (Read error: 110 (Connection timed out)) |
| 13:52:50 | Torne | it's more likely to be noticed if you submit it to FS. |
| 13:53:24 | funman | and come here regularly until someone takes a look at it :) |
| 13:53:33 | pamaury | ok. |
| 13:53:33 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 13:55:38 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
| 13:55:38 | pamaury | I also wrote a topic about a bug of the usb driver of the sansa e200 (usb-drv-arc). The fix also seems simple but I guess the usb driver is more important than logfdump so I would prefer than someone check that I'm correct |
| 13:55:45 | funman | dircache.c doesn't check volume names (for mkdir("<microSD1>/.." for example) while dir_uncached.c seems to do |
| 13:56:09 | Torne | pamaury: that doesn't mean you can't post a patch |
| 13:56:17 | Torne | post the patch and state what your concerns are about it |
| 13:56:32 | Torne | FS is the right place to put these things, it doesn't have to be a finished piece of work |
| 13:56:49 | funman | patches can be refined until they are acceptable |
| 13:56:54 | pamaury | ok |
| 13:57:26 | Torne | the more of the developers' work you can do for them the more likely it is to get dealt with quickly :) |
| 13:58:38 | funman | hum but dircache only seems to be enabled if there is more than 8MB of RAM (not the case on my Fuze) |
| 13:59:56 | | Quit AndyI (Read error: 110 (Connection timed out)) |
| 14:00 |
| 14:00:47 | gevaerts | pamaury: I've just looked at your usb_drv_arc forum post, and I agree that that most likely is the issue. Did you test it? |
| 14:01:08 | | Quit bzed ("leaving") |
| 14:01:29 | | Join bzed [0] (n=bzed@devel.recluse.de) |
| 14:02:48 | pamaury | gevaert: no I have not tested it, I will first submit the logfdump bug because the fix works, then I'll test usb-drv-arc fix |
| 14:04:46 | | Join stoffel [0] (n=quassel@p57B4CDC4.dip.t-dialin.net) |
| 14:09:38 | funman | i'll test your logf fix in a second (i confirmed the bug at least) |
| 14:10:04 | | Join thegeek_ [0] (n=nnscript@s243b.studby.ntnu.no) |
| 14:12:39 | pamaury | I have submitted it. |
| 14:16:48 | funman | pamaury: thanks it works fine, i'll commit it |
| 14:22:07 | CIA-6 | New commit by funman (r22250): Fix logfdump multilines handling ... |
| 14:23:09 | pamaury | gevaerts: I have tried to replace the "return -1" by "continue" in the driver and it seems to work: at least it does not breaks anything as far as I can tell and it fixes the inital bug in my code |
| 14:23:18 | funman | pamaury: thanks! |
| 14:23:30 | gevaerts | pamaury: ok. I'll commit that fix later today |
| 14:23:57 | pamaury | I will submit it to FS anyway |
| 14:27:02 | gevaerts | ok |
| 14:27:35 | | Quit thegeek (Read error: 110 (Connection timed out)) |
| 14:27:58 | | Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) |
| 14:28:09 | moos | funman: you missed the CREDITS part on this commit (salut btw) |
| 14:29:30 | funman | moos: right, gevaerts can you fix it in the next commit? |
| 14:30:14 | | Join LambdaCalculus37 [0] (i=44a0430d@rockbox/staff/LambdaCalculus37) |
| 14:30:20 | funman | using "/<microSD1>/__TEST__" in test_disk.c works fine (leading / was missing) until creat() |
| 14:30:27 | gevaerts | funman: you mean you forgot, and now I have to remember? ;) |
| 14:30:47 | funman | i mean it ! (my tree is dirty) |
| 14:30:47 | moos | haha :D |
| 14:30:51 | * | gevaerts thinks that that is cheating! ;) |
| 14:33:21 | funman | is it only on my Fuze's µSD that I can't delete directories ? (i see the busy bar which vanishes after a bit, but the directory stays there) |
| 14:33:42 | funman | and i can't delete files in that directory |
| 14:34:12 | funman | eject/insert/delete directory => unhandled IRQ 00 watchdog |
| 14:35:36 | | Join panni_ [0] (i=hannes@ip-95-222-19-21.unitymediagroup.de) |
| 14:39:34 | pamaury | I also have a question about the "logf" entry of the debug menu: on my sansa e200 it truncates lines whereas there is still space available. I've looked at the code and it seems that it computes the number of displayable characters by using the size of 'A'. Is there any reason for that ? |
| 14:40:50 | | Quit thegeek_ (Read error: 110 (Connection timed out)) |
| 14:42:01 | funman | if characters have different widths, then no |
| 14:42:14 | funman | font_get_width() in font.c seems to say it's the case |
| 14:45:18 | pamaury | I've seen that there is a lcd_getstringsize function which is used to get the size of 'A'. It should be possible to call it for each line and then to see if it should be truncated or not. It would probably slow down the display but would be more precise. I don't know if it's worthwhile to modify it |
| 14:46:44 | tmzt | is there a reason for using a variable width font for the logging? |
| 14:46:57 | tmzt | or is this because rockbox only supports one font? |
| 14:48:26 | pamaury | This is probably because it uses the default font to display the log and the default font has wariable widths |
| 14:48:58 | gevaerts | not on all targets |
| 14:49:44 | Torne | lcd_getstringsize returns the wrong answer if the font is variable width, is why |
| 14:49:51 | Torne | iirc |
| 14:50:24 | Torne | er, or am i thinking of something else |
| 14:50:47 | GodEater | doesn't it make more sense for the system font to be used to display the log ? |
| 14:51:43 | Torne | oh sorry, i'm thinking of the weird thing with puts |
| 14:52:01 | Torne | yes, lcd_getstringsize should work to see where to wrap/truncate the log |
| 14:52:37 | pamaury | The problem is that if it has to truncate, then it must be called lots of times to determine where to cut |
| 14:52:45 | | Join robin0800_ [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 14:53:03 | funman | GodEater: the system font is fixed width, and easily usable? |
| 14:53:39 | Torne | can't you just print a string that's too long anyway? |
| 14:53:43 | GodEater | funman: I don't recall - haven't written anything for rockbox is ages :) |
| 14:53:46 | GodEater | s/is/in |
| 14:53:55 | Torne | yes, you can :) |
| 14:54:08 | Torne | you can just print it and it will get truncated in the course of lcd_putsxyofs |
| 14:54:23 | Torne | which just stops printing characters when it passes the current viewport width |
| 14:54:35 | Torne | so if you actually want truncation that's easy |
| 14:55:19 | pamaury | yes but then there would have a problem with multilines: it add '>' at the end of each intermediate line. If it's truncated, then the '>' is not displayed. Not a big deal though |
| 14:56:23 | Torne | technically that's doable anyway |
| 14:56:28 | Torne | just go back and print the > afterward ;) |
| 14:56:48 | pamaury | yes :) |
| 14:56:54 | Torne | I dunno. just pointing out that lcd_puts truncates *anyway*. |
| 14:57:58 | pamaury | The point is: is the system font small enought to display a whole line of log on the screen ? Of at least the majority, otherwise it's useless |
| 15:00 |
| 15:00:38 | pamaury | I will try to use the system font on my sansa, to see the result |
| 15:00:46 | Jaykay | second try: >is there any rule how builds should be named? (because of the incosistency documented in BuildNames) |
| 15:01:32 | Torne | pamaury: the system font is monospace which *generally* makes it fit less horizontally than the user font |
| 15:01:43 | Torne | unless the user has picked a particularly big user font |
| 15:02:06 | funman | Jaykay: no |
| 15:02:27 | funman | the name should be descriptive that's all |
| 15:02:41 | Torne | if there's room for 30 chars across the screen in the system font on your target that avoids the whole issue, but i doubt this is the case for all targets |
| 15:02:43 | Jaykay | then we wouldn't need BuildNames |
| 15:02:56 | Jaykay | "...so we can hopefully bring everything in line to make things less confusing. " |
| 15:04:05 | pamaury | yes, but I have no idea how many chars fit on my target. I doubt there is enough room for 30 chars |
| 15:04:31 | Torne | using the system font at least means you will always know exactly how many chars *will* fit. |
| 15:04:50 | Torne | but it probably reduces the average number of characters that will fit for most people |
| 15:05:10 | funman | Jaykay: the page is about using the same string for configure target, and downloaded files |
| 15:05:41 | * | Torne would go with just printing the whole thing and letting the lcd code truncate it, and using some other way of marking where the line continuations are. |
| 15:06:24 | Torne | you could always put the line continuation markers at the beginning of the continuing lines, instead of the end of the continued lines |
| 15:06:59 | pamaury | It's true that just printing the line and letting the lcd code truncate would really simplify the code |
| 15:07:18 | Jaykay | funman: so the configure names should persist and all the other names should be brought in line with the configure name? |
| 15:08:22 | funman | Jaykay: the configure name can be changed as well |
| 15:08:56 | funman | Torne: putting the marker at the start of newline makes sense |
| 15:09:24 | pamaury | yes that's true |
| 15:09:27 | funman | gevaerts: did you try modifying test_disk base directory to "/<microSD1>/__TEST__" ? |
| 15:09:50 | gevaerts | no |
| 15:09:56 | funman | that's what I was doing but seeing if this approach works fine is disturbed by the AMS-specific bugs |
| 15:10:39 | funman | perhaps i could try with a ramdisk |
| 15:10:53 | Torne | funman: tbh preserving the logf 29-char line wrapping on a target that can't fit 29 chars across the screen is kinda doomed to be hard to read regardless :) |
| 15:11:12 | Jaykay | how about just taking the name of the complete series (like sansa, ipod, vx, yh) and the "exact" model name (e200, 4g, 767)... this should be consistent and easy |
| 15:11:25 | Jaykay | for the more-ram-targest just add 64mb |
| 15:11:27 | gevaerts | funman: ramdisk is a bit annoying because you have to format it first, which won't be easy on ams |
| 15:11:52 | gevaerts | Jaykay: so "sansa e200"? |
| 15:11:58 | Jaykay | yes |
| 15:12:03 | * | gevaerts thinks he spots a flaw |
| 15:12:36 | Jaykay | gevaerts: where is the problem? |
| 15:12:46 | amiconn | funman: test_disk works fine on the Ondio's MMC when changing the test dir to /<MMC1>/__TEST__ |
| 15:12:47 | gevaerts | Jaykay: *which* sansa e200? |
| 15:12:51 | *** | Saving seen data "./dancer.seen" |
| 15:13:15 | gevaerts | Jaykay: also, if you don't put in the manufacturer somewhere, you'll get duplicates (e.g. M3) |
| 15:13:23 | amiconn | If it doesn't work on AMS, there must be a bug in the ams specific driver |
| 15:13:28 | Jaykay | gevaerts: i forgot... when there are different versions then just add the version (v2) |
| 15:13:48 | funman | amiconn: thanks |
| 15:14:04 | funman | there 'must be' no bugs in ams specific driver |
| 15:14:09 | Jaykay | gevaerts: and it would be iaudiom3 and m3, but i see thats not perfect |
| 15:14:17 | funman | there 'are' bugs |
| 15:14:20 | gevaerts | Jaykay: you're back to where we are now then |
| 15:14:45 | | Join thegeek_ [0] (n=nnscript@s243b.studby.ntnu.no) |
| 15:14:55 | Jaykay | gevaerts: look at the configure names, they're different |
| 15:16:10 | gevaerts | Jaykay: and? |
| 15:16:45 | pamaury | Torne: I've checked using the system font and 29 characters fit exactly on my target. The result is really small but it's readable |
| 15:16:50 | Jaykay | you said i would be back to where you are now... but the names are now different to my suggestion. |
| 15:16:50 | gevaerts | I can see they are different, but I have no idea why you point to that fact |
| 15:17:12 | gevaerts | so your suggestion is just "let's change the names a bit"? |
| 15:17:13 | funman | Jaykay: perhaps add a column with a proposed names |
| 15:17:15 | Torne | pamaury: it technically needs to be 30 though, for the char used for line continuation :) |
| 15:18:02 | pamaury | well no, iirc MAX_LOGF_LINE=29 and it contains a terminating '0' so there are in reality 28 characters +1 with the continuation one |
| 15:18:26 | Jaykay | gevaerts: exactly... for consistency, BuildNames says there should be consistency |
| 15:18:28 | pamaury | Anyway, it fir exactly while displaying a multiline so it should no be 30 |
| 15:18:33 | pamaury | *fit |
| 15:19:02 | Torne | each logf record is 30 bytes. MAX_LOGF_ENTRY is 29, the last byte is used to indicate whether it's a continuation or not |
| 15:19:03 | gevaerts | Jaykay: what you proposed does not give us consistency |
| 15:19:12 | Jaykay | why not? |
| 15:19:16 | Torne | it doesn't have a terminating null, it's padded with spaces |
| 15:19:19 | gevaerts | 15:14 < Jaykay> gevaerts: and it would be iaudiom3 and m3, but i see thats not perfect |
| 15:20:07 | funman | pamaury: your name is written with capitals ? (Amaury Pouly) i'll add you to the credits |
| 15:20:10 | Jaykay | gevaerts: iaudiom3 is consistent, m3 is the only proble... maybe we could take meizu there as the name of the series |
| 15:20:14 | Torne | pamaury: the buffer being used in logfdisplay is 31 bytes, to make room for the null. |
| 15:20:18 | Jaykay | *problem |
| 15:20:28 | pamaury | funman: yes |
| 15:20:31 | pamaury | thanks |
| 15:20:59 | CIA-6 | New commit by funman (r22251): Sansa AMS: identify interrupts with no source set ... |
| 15:21:01 | CIA-6 | New commit by funman (r22252): Add Amaury Pouly to the credits |
| 15:21:08 | pamaury | Torne: no I express myself no correctly. logfbuffer is MAX_LOGF_ENTRY+1 large. The last char is the type of line (single, multi, continue). |
| 15:21:22 | pamaury | Torne: the one just before the last one is a 0 |
| 15:21:35 | | Quit funman ("free(random());") |
| 15:21:50 | pamaury | so there are in reality 28 characters per line |
| 15:22:30 | Torne | no, you're wrong, sorry. |
| 15:23:21 | Torne | logfbuffer is not null terminate at all; it happens that the byte for "single line" is a null. |
| 15:23:39 | pamaury | No, see the bug report I submit today |
| 15:23:58 | pamaury | The reason is simple: |
| 15:24:02 | pamaury | In logf.c: |
| 15:24:02 | pamaury | strlcpy(ptr, buf + tlen, MAX_LOGF_ENTRY); |
| 15:24:08 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 15:24:36 | Torne | ah |
| 15:24:44 | Torne | that means the change to strlcpy has changed the logf behaviour, then |
| 15:24:54 | pamaury | yes that's possible |
| 15:25:02 | Torne | it was previously *not* null terminated |
| 15:25:25 | Torne | but it's been changed to do strlcpy instead :) |
| 15:26:01 | pamaury | That would explain the logfdump bug |
| 15:26:10 | Torne | And now it no longe rbehaves as the comments in logf.c say |
| 15:26:44 | Torne | interesting :) |
| 15:27:28 | Torne | hm, it still space-pads it though |
| 15:27:31 | Torne | this is.. weird |
| 15:27:37 | Torne | i think this is broken :) |
| 15:27:42 | kugel | why's that line breaking such a problem? splash(f) does it fine too |
| 15:27:44 | pamaury | yes you're right |
| 15:27:45 | Torne | should probably be changed back to memcpy |
| 15:28:01 | Torne | wrapped lines are being wrapped at 28 bytes then null terminated |
| 15:28:12 | Torne | non-wrapped lines or the last bit of wrapped lines are being allowed to be 29 bytes, and space padded. |
| 15:28:17 | Torne | unless i'm misreading logf.c |
| 15:28:39 | kugel | where's the strlcpy? |
| 15:28:50 | Torne | in _logf |
| 15:28:51 | Jaykay | the the build for ipodvideo also work on the ipodvideo64mb? |
| 15:28:58 | Torne | Jaykay: yes |
| 15:29:04 | Torne | it just doesn't use all the ram |
| 15:29:07 | pamaury | currently, all lines are at most 28 characters long, whatever the type of line is |
| 15:29:16 | Torne | pamaury: no, they're not |
| 15:29:27 | Jaykay | Torne: then why is there a separate download for it? |
| 15:29:33 | Torne | Jaykay: because it doesn't use all the ram |
| 15:29:41 | pamaury | hum yes you right |
| 15:30:01 | pamaury | there is a weird behaviour for string with length that is exactly MAX_LOGF_ENTRY |
| 15:30:01 | Torne | r21863 has broken logf |
| 15:30:25 | Torne | pamaury: no, the weird behaviour is for strings which are wrapped. if you read the comment at the top of the file, it's not *supposed* to be null terminated, in *any* case. |
| 15:30:34 | Jaykay | Torne: the last question: can configure build the 64mb version? |
| 15:30:35 | Torne | r21863, the strlcpy change, has been done wrong. |
| 15:30:45 | Torne | Jaykay: yes, but mem size is a seperate prompt from the target type :) |
| 15:30:49 | | Quit beta_ (Read error: 110 (Connection timed out)) |
| 15:30:55 | pamaury | yes you can turn it the way you want :) |
| 15:31:16 | Torne | pamaury: strings <=MAX_LOGF_ENTRY are being handled the same as they have always been, it's only strings longer whose behaviour has changed from how it's documented to work :) |
| 15:31:19 | Jaykay | Torne: ok, thanks |
| 15:31:20 | pamaury | but you're right, there are not expected to be null terminated |
| 15:31:59 | | Join bubsy [0] (i=Bubsy@94.139.72.137) |
| 15:32:03 | | Quit thegeek (Read error: 110 (Connection timed out)) |
| 15:32:19 | Torne | the use of strlcpy should be changed to memcpy |
| 15:32:19 | pamaury | Then it should be noted that the logfdump code would be broken (because of my fix) |
| 15:32:45 | kugel | Torne: the \0 added for long strings is overwritten by LOGF_TERMINATE_CONTINUE_LINE isn't it? |
| 15:32:51 | Jaykay | why is the h10_5gb in rbutil named h10_5gbums/ h10_5gbmtp? |
| 15:32:57 | Torne | kugel: no, MAX_LOGF_ENTRY is 29 |
| 15:33:16 | Torne | kugel: so it ends up with 28 bytes of string then the null then LOGF_TERMINATE_CONTINUE_LINE |
| 15:33:20 | kugel | so? |
| 15:33:34 | Torne | and there's no need for that to be strlcpy anyway; it's always copying exactly the same number of bytes :) |
| 15:33:46 | kugel | strlcpy will add a \0 add ptr[MAX_LOGF_ENTRY] if the src is too long |
| 15:33:55 | kugel | and ptr[LOGF_TERMINATE_CONTINUE_LINE] is being overwritten |
| 15:34:04 | pamaury | no stlcpy will add a '0' ANYWAY |
| 15:34:08 | Torne | kugel: no it won't |
| 15:34:15 | Torne | it will add one at ptr[MAX_LOGF_ENTRY-1] |
| 15:34:19 | pamaury | but it will add it at MAX_LOG_ENTRY-1 |
| 15:34:34 | kugel | uhm |
| 15:34:34 | kugel | yea |
| 15:34:46 | Torne | someone should just change it to memcpy there |
| 15:34:51 | pamaury | that's the definition of strlcpy: it will write at most MAX_LOG_ENTRY characters, INCLUDING the 0 |
| 15:34:52 | Torne | before we do anything else with the log dumper :) |
| 15:35:00 | kugel | pamaury: I know |
| 15:35:02 | Torne | because changing th elog dumper to accomodate this bug is silly :) |
| 15:35:17 | pamaury | that's what happened :) |
| 15:35:34 | | Join evilnick [0] (i=0c140464@gateway/web/freenode/x-1ee78bf24d2c82c4) |
| 15:35:36 | Torne | oh, that already got committed? :) |
| 15:35:44 | pamaury | yes |
| 15:36:06 | Torne | and funman has gone :( |
| 15:36:23 | kugel | but it should add a \0 if src is short, shouldn't it? |
| 15:36:36 | Torne | kugel: src is never short in that case |
| 15:36:46 | kugel | that's weird code still! |
| 15:36:47 | Torne | kugel: the strlcpy only gets called when the original string is >MAX_LOGF_ENTRY |
| 15:37:01 | Torne | if you read the comment at the top of the file it says the buffer is space-padded with no terminators. |
| 15:37:17 | pamaury | I can write a patch for that and submit it after some testing |
| 15:37:33 | Torne | which is what it does with the strcpy lower down in the function. |
| 15:37:58 | kugel | it should've used memcpy in the first place |
| 15:38:04 | Torne | kugel: yes |
| 15:38:31 | Torne | oh wait |
| 15:38:38 | Torne | actually if you look at the diff it was wron gbefore as well :) |
| 15:38:44 | Torne | as it was doing strncpy with MAX_LOGF_ENTRY-1 |
| 15:38:56 | Torne | so it was logical for someone to change that to strlcpy with MAX_LOGF_ENTRY |
| 15:39:09 | | Join aaron424 [0] (n=chatzill@adsl-065-013-002-216.sip.asm.bellsouth.net) |
| 15:39:24 | pamaury | I have to leave, come back later |
| 15:39:43 | Torne | several previous sets of people appear to have had the same misunderstanding about how the logf buffer is supposed to work |
| 15:40:37 | Torne | the multiline logf thing seems to have never really worked right, possibly, looking at the file history :) |
| 15:40:53 | kugel | what does the space-padding? |
| 15:41:01 | Torne | a few lines lower down |
| 15:41:19 | Torne | strcpy(ptr, buf + tlen); then it pads with spaces |
| 15:41:48 | Torne | that strcpy is also kinda weird. it will always work in this particulra case |
| 15:42:26 | Torne | but if you logf() MAX_LOGF_ENTRY bytes then that strcpy will indeed set the 30th byte in the entry to 0, which will then get reset later |
| 15:42:43 | Torne | Both of them should be memcpy really |
| 15:43:13 | Torne | since it's not really null terminated strings being dealt with |
| 15:43:17 | kugel | or that weird code should be fixed to be human understandable |
| 15:43:24 | Torne | Hehe |
| 15:43:53 | Torne | it's not entirely obvious *why* it's supposed to be space padded |
| 15:44:17 | kugel | "padded for easier and faster output on screen" doesn't make any sense for me |
| 15:44:20 | Torne | no. |
| 15:44:25 | Torne | ...also, er |
| 15:44:35 | Torne | if we now support multiline logf anyway, with all this wrapping stuff |
| 15:44:45 | Torne | why is there even a fixed length record in the first place. |
| 15:44:53 | Torne | i'm not seeing hte advantage, tbh :) |
| 15:45:19 | Torne | a ring buffer of consecutive null terminated strings would work just as well.. maybe better.. unless there's some use case i'm not seeing |
| 15:45:58 | gevaerts | the starting address is slightly less clear |
| 15:46:35 | Torne | how so? |
| 15:48:33 | Torne | logfindex could just be bytes instead of records, i don't see how tha tmakes any difference for either side |
| 15:48:37 | gevaerts | I mean, with a fixed-line ring buffer, you don't have pesky calculations to work out if the line you're looking at is still fully there, or it's been overwritten by a new line. It's a very minor thing though, and I probably don't explain it properly |
| 15:49:04 | Torne | Oh, you mean the first line in the buffer being only the last bit |
| 15:49:09 | Torne | because of partial overwriting. |
| 15:49:19 | gevaerts | yes |
| 15:49:27 | Torne | yes, that's true. |
| 15:49:37 | Torne | but you could just throw that line away, for all the difference it really makes |
| 15:49:41 | Torne | truncated or not |
| 15:49:56 | gevaerts | Something that probably is a real difference though is that at least with a fixed width font, if you use space padding, clearing the on-screen line you're going to overwrite is automatic |
| 15:50:10 | Torne | but it currently doens't use a fixed width font :) |
| 15:50:19 | gevaerts | it probably did originally I guess :) |
| 15:50:23 | Torne | if you have a free running circular buffer then you have no guarantee you are getting the right data nayway |
| 15:50:26 | kugel | I think it never did |
| 15:50:30 | Torne | you are always going to drop stuff |
| 15:50:41 | Torne | so you can just throw away the first bit in the buffer, assuming it's been partially overwritten. |
| 15:50:49 | Torne | i mean the entire implementation here isn't threadsafe anyway |
| 15:51:01 | gevaerts | kugel: sure it did. Remember the Player? :) |
| 15:51:02 | Torne | so the data already has a nonzero chance of being overwritten while you are in th emiddle of using it |
| 15:51:07 | kugel | zzz |
| 15:51:11 | Torne | and just being unreadable garbage to begin with |
| 15:51:17 | Torne | :) |
| 15:51:38 | gevaerts | Torne: remember cooperative multitasking? :) |
| 15:52:01 | Torne | oh right. |
| 15:52:03 | Torne | :) |
| 15:52:09 | Torne | yeah ok *apart* from that *g* |
| 15:52:13 | gevaerts | kugel: seriously, I wouldn't be surprised if the space-padding idea is that old |
| 15:52:29 | Torne | i would guess that is why it's space padded, yes |
| 15:52:56 | gevaerts | and yes, in modern variable width font times it doesn't make much sense |
| 15:53:39 | kugel | gevaerts: I wouldn't be either. I yesterday asked for a feature in another project. the dev told me it was deactivated some time ago because it didn't work. That's was 3 years ago (r2xx, HEAD is r41xx) |
| 15:54:21 | Torne | gevaerts: anyway i think it should either be fixed to use memcpy and someone check that that makes it behave as documented.. or it should just lose the fixed length records entirely :) |
| 15:57:50 | | Quit darkhamm (Read error: 60 (Operation timed out)) |
| 15:59:20 | | Join darkhamm [0] (n=darkhamm@host41-155-dynamic.6-87-r.retail.telecomitalia.it) |
| 16:00 |
| 16:08:54 | | Join Tristan [0] (n=Tristan@i.dont.want.to.die.virgin.net.in) |
| 16:10:19 | pamaury | hello back |
| 16:11:49 | | Quit bah_ (Read error: 110 (Connection timed out)) |
| 16:11:52 | | Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) |
| 16:12:35 | pamaury | have you worked out the logf bug ? |
| 16:19:17 | bertrik | gevaerts, actually I did add some mutexes for the i2c and adc parts of the s5l8700 |
| 16:19:32 | gevaerts | bertrik: interrupt contexts? |
| 16:19:56 | bertrik | the as3525 targets just block for i2c to complete (for example), but it's actually nicer to wakeup_wait and let the interrupt do wakeup_signal |
| 16:20:21 | bertrik | yeah, mutexes can be problematic to use in interrupt context |
| 16:20:38 | bertrik | impossible probably |
| 16:20:41 | | Join bah_ [0] (n=bah@c-76-105-203-173.hsd1.wa.comcast.net) |
| 16:21:53 | | Quit Trista824 (Read error: 113 (No route to host)) |
| 16:22:08 | bertrik | in hindsight, I was worrying about spin loops on the order of 100 us, while probably 10s of miliseconds are wasted in spinloops in some lcd drivers |
| 16:24:12 | pamaury | Torne: are you there ? |
| 16:24:19 | Torne | pamaury: We've worked out that it definately doesn't behave as documented |
| 16:24:29 | Torne | and also that it's kinda confusing and is probably only that way for historical reasons |
| 16:24:39 | Torne | it could be put back to working as documented fairly easily i think |
| 16:24:52 | Torne | but i suggested we might just give up having fixed length records altogether :) |
| 16:25:44 | | Join beta_ [0] (n=beta@d24-36-68-97.home1.cgocable.net) |
| 16:25:56 | pamaury | How do you want to achieve that ? |
| 16:26:19 | | Nick beta_ is now known as Beta2K (n=beta@d24-36-68-97.home1.cgocable.net) |
| 16:26:19 | | Join Blue_Dude [0] (n=chatzill@adsl-235-206-199.mco.bellsouth.net) |
| 16:26:39 | pamaury | Having only one big buffer and append at the end ? |
| 16:27:19 | Blue_Dude | I just posted a bug report at FS #10512 regarding problems with bookmarking. Has something changed recently? |
| 16:27:41 | Torne | pamaury: just treating it as a buffer of bytes, with each entry separated by a single null |
| 16:27:54 | Torne | i dunno tha tanyone agrees with me |
| 16:27:57 | Torne | but it was a suggestion. |
| 16:28:20 | pamaury | well it's would be much simpler, seeing how complex is the code just to support multiline |
| 16:28:36 | pamaury | (in logfdump for example) |
| 16:28:39 | gevaerts | Torne: one more problem with non-fixed-size would be that you can wrap around halfway a line |
| 16:28:45 | Torne | gevaerts: so? |
| 16:28:52 | Torne | does that matter? |
| 16:29:06 | gevaerts | no, it just adds code |
| 16:29:13 | Torne | probably not more than it *removes*, though |
| 16:29:16 | pamaury | It would move the complexing to the display code that would have to wrap correctly |
| 16:30:04 | pamaury | I agree with Torne that doing so would probably remove more code than it adds and the code would be more human understandable |
| 16:31:13 | Torne | the advantages of the fixed length records were fine when we didn't allow people to logf more data than htat |
| 16:31:20 | Torne | now it has the code to split lines anyway it seems less worthwhile |
| 16:32:37 | pamaury | the inconvenient is that it would require a full screen redraw in logf if i'm correct |
| 16:32:52 | gevaerts | why? |
| 16:33:20 | pamaury | because it would not be fixed-width |
| 16:33:41 | pamaury | with space-padding, drawing a line erases the previous one, no ? |
| 16:34:08 | gevaerts | yes, but that doesn't mean you suddenly have to redraw the entire screen |
| 16:34:32 | pamaury | how do you redraw only part of the screen if you scroll one line for example ? |
| 16:37:21 | Torne | er, it already redraws the whole screen when you scroll up and down, no? |
| 16:37:48 | pamaury | well yes :) |
| 16:37:52 | bertrik | I think so too |
| 16:38:12 | bertrik | at least the parts that changed |
| 16:39:45 | pamaury | so I see only advantages to having one big buffer and entries separated by a single null |
| 16:40:33 | Torne | pamaury: the disadvantage is that the 'first' entry in the buffer may have been partially overwritten |
| 16:40:51 | pamaury | yes but it's the same thing with the actual code |
| 16:41:03 | Torne | but at the moment you can *tell* there is a partially overwritten line |
| 16:41:15 | Torne | no, wait, you can't |
| 16:41:20 | pamaury | no you can't |
| 16:41:21 | Torne | because it doesn't mark the *first* continued line specially |
| 16:41:27 | Torne | Heh. So yes, it's no worse. |
| 16:43:54 | | Join toffe82 [0] (n=chatzill@74.0.180.178) |
| 16:46:58 | | Join Lss [0] (n=Lss@cm119.delta88.maxonline.com.sg) |
| 16:47:22 | | Quit aaron424 (Read error: 60 (Operation timed out)) |
| 16:47:59 | | Part LinusN |
| 16:48:11 | pamaury | Torne: there is one disadvantage but it's minor: when the buffer would wrap you can end up with the first line being empty because the buffer has erased the whole line except the '0'. So there would have to consecuting '0' in the buffer |
| 16:48:44 | Torne | that's just a special case of the first line being partially overwritten |
| 16:48:54 | pamaury | Yes but that would introduce an extra blank line |
| 16:48:58 | Torne | so? |
| 16:49:13 | Torne | overwriting one less byte would introduce an extra line with one useless character on it :) |
| 16:49:40 | Torne | if it's particularly concerning you can just skip everything from the current write position tot he next null |
| 16:49:53 | | Join maruk [0] (n=papier@titanium.sdv.fr) |
| 16:50:35 | pamaury | yes |
| 16:54:30 | Torne | anyway, whether to do this is kinda a different matter to the actual problem, which i can write a patch for but don't have a convenient way to test right now |
| 16:55:09 | pamaury | I have written a fix for the actual code and tested it |
| 16:55:26 | Torne | you also fixed the references to MAX_LOGF_ENTRY-1? |
| 16:55:48 | Torne | pastebin the diff somewhere? |
| 16:56:41 | pamaury | yes, do you a site where I can paste the diff ? |
| 16:57:16 | evilnick | pastebin? pastie.org |
| 16:57:54 | pamaury | http://pastie.org/580060 |
| 16:58:19 | pamaury | It also uses the system font to draw the log |
| 16:59:07 | Torne | the fix to logf is fine |
| 16:59:10 | Torne | i dunno about the rest.. |
| 16:59:33 | | Join aaron424 [0] (n=chatzill@adsl-065-013-002-216.sip.asm.bellsouth.net) |
| 16:59:38 | | Join captainkwel [0] (i=2669ecc2@gateway/web/freenode/x-8a2f15f40466d46d) |
| 17:00 |
| 17:00:17 | pamaury | Wall it fixes logf, logfdump and logfdisp. I trick to use the system font optional |
| 17:00:24 | pamaury | *the trick |
| 17:00:36 | Torne | isn't it also necessary to revert the change that funman just committed |
| 17:01:27 | pamaury | yes that's what I was looking for |
| 17:01:33 | Torne | http://svn.rockbox.org/viewvc.cgi/trunk/apps/logfdisp.c?r1=20743&r2=22250 |
| 17:01:49 | pamaury | I don't think I have the last version |
| 17:01:53 | Torne | and i'm not sure what lines 28/29 of the diff are for |
| 17:02:26 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 17:02:54 | pamaury | Hum, that's because on my target at leats it will overwrite the last character of the line but it's a hack, perhaps we should simply drop this '>' |
| 17:03:20 | Torne | i would just leave the log display alone for now |
| 17:03:23 | Torne | fix one thing at a time |
| 17:03:40 | Torne | the diff there to logf, plus reverting funman's change, should sort the actual problem |
| 17:04:00 | Torne | the display issue is, well, just a display issue :) |
| 17:04:40 | pamaury | ok, I change the diff and paste it |
| 17:05:56 | pamaury | Should I include the system font change or not ? |
| 17:06:16 | Torne | no. i think that has the potential to make it worse on average :) |
| 17:07:00 | Torne | the display issue i think is better fixed in a different way |
| 17:07:08 | pamaury | http://pastie.org/580071 |
| 17:07:14 | Torne | there are several possible different ways. one of which is just to stop doing the fixed length records at all. |
| 17:07:26 | Torne | (but it could also rewrap the lines) |
| 17:07:45 | pamaury | Yes, but we can still fix the existing code and write a new one later |
| 17:07:48 | Torne | pamaury: yah, that looks right to me. I mean i've not tried it or anything :) |
| 17:08:02 | pamaury | I will test it now |
| 17:08:20 | Torne | pamaury: my point is it's not a fix. it makes it different, in a way which may be better or worse depending exactly how big your font/screen are and how long your logf messages are on average :) |
| 17:09:08 | Torne | it might look better on your particular player but i don't think this is universal |
| 17:09:39 | Torne | rewrapping the lines, or letting hte lcd code truncate it and displaying the wraps some other way, would be a universal fix but is not as trivial :) |
| 17:10:02 | pamaury | It's not as complex |
| 17:10:37 | Torne | but my point is that for some font/screen combinations changing it to sysfont may make *less* information fit on the screen, not more. |
| 17:10:44 | Torne | so i don't think it's a good idea :) |
| 17:11:18 | pamaury | yes I agree |
| 17:11:33 | pamaury | but it's a different problem than rewriting the underlying code |
| 17:11:43 | Torne | Yes, but it's related |
| 17:11:58 | Torne | Rewrapping the lines is the nicest fix, really |
| 17:12:14 | Torne | (which would be easier if done with sysfont, also) |
| 17:12:32 | pamaury | it's mostly a font problem, it's possible to code it in a way that it corretly wraps whatever the font is |
| 17:12:53 | *** | Saving seen data "./dancer.seen" |
| 17:13:05 | Torne | but it's not unrealated, because wrapped printing would be required anyway if the log records stopped being fixed length |
| 17:13:12 | * | Torne shrugs |
| 17:13:30 | pamaury | yes |
| 17:13:57 | Torne | anyway you should chuck the patch just to fix logf into FS |
| 17:14:07 | Torne | and poke funman if he comes back :) |
| 17:15:12 | pamaury | I've tested the fix I posted and it worked on my sansa as far as I can tell |
| 17:22:05 | | Quit darkhamm (Read error: 104 (Connection reset by peer)) |
| 17:23:57 | | Quit aaron424 ("ChatZilla 0.9.85 [Firefox 3.0.13/2009080311]") |
| 17:29:10 | | Join Sajber^ [0] (n=Sajber@c-473171d5.012-155-73746f22.cust.bredbandsbolaget.se) |
| 17:29:45 | | Quit Sajber^ (Read error: 104 (Connection reset by peer)) |
| 17:30:45 | | Join Sajber^ [0] (n=Sajber@c-473171d5.012-155-73746f22.cust.bredbandsbolaget.se) |
| 17:30:54 | | Quit Sajber^ (Read error: 54 (Connection reset by peer)) |
| 17:31:50 | | Join Sajber^ [0] (n=Sajber@c-473171d5.012-155-73746f22.cust.bredbandsbolaget.se) |
| 17:36:36 | | Join chandoo_ [0] (n=chandoo@ool-4353b978.dyn.optonline.net) |
| 17:42:48 | | Join JdGordon_ [0] (i=63cb7a73@gateway/web/freenode/x-92b65e7ca3f74c69) |
| 17:46:15 | | Quit moos (Read error: 104 (Connection reset by peer)) |
| 17:46:17 | | Join DrMoos [0] (i=mustapha@85-169-147-55.rev.numericable.fr) |
| 17:47:01 | | Nick DrMoos is now known as moos (i=mustapha@85-169-147-55.rev.numericable.fr) |
| 17:48:58 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 17:52:53 | pamaury | funman: we add with Torne and gevaerts a discussion about logf and concluded that the current implementation contains a long standing bug that my patch revealed. |
| 17:53:03 | pamaury | s/add/had |
| 17:53:14 | pamaury | I submitted a patch to FS about it |
| 17:53:19 | funman | i'm reading the log |
| 17:54:08 | funman | bertrik: mutexes are impossible to use in interrupt context, because they need a thread context |
| 17:54:25 | bertrik | yes I know |
| 17:54:50 | bertrik | I wonder what would happen in practice though when attempting to grab a mutex in interrupt context |
| 17:55:37 | gevaerts | try it! |
| 17:55:44 | bertrik | I wouldn't mind some kind of check on that |
| 17:56:05 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
| 17:56:08 | funman | i believe it acts like the thread running before the isr took the lock |
| 17:56:52 | funman | since 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:50 | funman | pamaury: i understand LOGF_TERMINATE_CONTINUE_LINE is overwritten in each loop ? in firmware/logf.c |
| 18:02:59 | | Join stoffel [0] (n=quassel@p57B4CDC4.dip.t-dialin.net) |
| 18:03:15 | | Join merbanan [0] (n=banan@c-83-233-172-245.cust.bredband2.com) |
| 18:04:01 | pamaury | funman: no the problem we encountered is that each time a log line is greater than MAX_LOGF_ENTRY, the current code split it but the intermediate lines created are '0' terminated whereas they should not |
| 18:04:04 | | Quit Blue_Dude (Read error: 110 (Connection timed out)) |
| 18:04:40 | pamaury | this mean that single lines have MAX_LOGF_ENTRY characters whereas multlines have MAX_LOGF_ENTRY-1 characters each and a terminating '0' |
| 18:04:50 | | Quit stoffel (Remote closed the connection) |
| 18:04:55 | pamaury | this explain why logfdump was buggy |
| 18:05:40 | funman | ok i misread |
| 18:06:12 | funman | len & tlen are offset to the source pointer, not the dest pointer |
| 18:06:40 | pamaury | yes |
| 18:07:31 | | Join stoffel [0] (n=quassel@p57B4CDC4.dip.t-dialin.net) |
| 18:07:41 | pamaury | the funny thing is that the logfdump code for which I submit a patch was indeed correct, that was the logf code that was wrong |
| 18:08:40 | funman | :) |
| 18:09:47 | | Join linuxstb [0] (n=root@rockbox/developer/linuxstb) |
| 18:12:07 | CIA-6 | New commit by funman (r22253): Fix logf() multilines handling ... |
| 18:12:29 | funman | i hope you'll stop finding problems now! |
| 18:13:41 | pamaury | well it's not clear, this is just a fix but Torne suggest a complete rewrite of the logf code but it's just a suggestion :) |
| 18:15:05 | funman | if it's a good idea you could add it to http://www.rockbox.org/twiki/bin/view/Main/MrSomeonesTodoList |
| 18:15:10 | | Quit Jaykay (Read error: 110 (Connection timed out)) |
| 18:15:43 | | Quit stoffel (Read error: 104 (Connection reset by peer)) |
| 18:15:53 | kugel | pamaury: it just needs someone to do it :) I think the corrent code is rather "suboptimal" |
| 18:17:43 | | Quit JdGordon_ (Ping timeout: 180 seconds) |
| 18:18:24 | | Quit linuxstb ("Lost terminal") |
| 18:20:02 | | Quit bluebrother (Nick collision from services.) |
| 18:20:07 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
| 18:20:52 | | Quit xavieran (Read error: 113 (No route to host)) |
| 18:22:46 | | Quit domonoky (Read error: 104 (Connection reset by peer)) |
| 18:23:17 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 18:24:43 | | Quit TheSphinX^ ("XChat@Linux") |
| 18:26:31 | pamaury | kugel: I can do it in my free time (I have plenty for now) but we have to be sure we want to rewrite it |
| 18:27:34 | | Join JdGordon| [0] (n=Miranda@nat/microsoft/x-16cf08f26d5bade2) |
| 18:28:35 | funman | pamaury: you could send an email to the developers mailing list explaining what you want to do and see if someone already started working on this idea or something similar |
| 18:29:01 | Torne | funman: it's not a huge thing.. |
| 18:29:15 | Torne | the suggestion was just to change logf to be a circular buffer of bytes, with messages separated by nulls |
| 18:29:24 | Torne | rather than a buffer of fixed length records with explicit continuation markers |
| 18:29:27 | funman | looks good to me |
| 18:30:05 | Torne | since the fixed length records appear to exist to make it convenient to print it to the screen on the Player |
| 18:30:06 | funman | i won't be the one writing the patch though, perhaps i misunderstood pamaury's concern |
| 18:30:11 | Torne | which is a somewhat outdated requirement now |
| 18:31:01 | pamaury | no I'm not expecting you to write the code :) |
| 18:31:36 | funman | pamaury: i mean i'm not sure why you want to be sure it needs to be rewritten |
| 18:32:00 | gevaerts | funman: I guess s/needs to be rewritten/will be committed if rewritten/ |
| 18:32:03 | pamaury | because otherwise it's useless :) |
| 18:32:23 | pamaury | gevaerts: yes |
| 18:32:34 | funman | circular buffer with '\0' markers look simpler, so better, so committable |
| 18:33:12 | funman | and buffer size adjustement would be simpler as well |
| 18:33:14 | Torne | pamaury: there's not much formality :) |
| 18:33:36 | funman | i'd say go for it! |
| 18:34:17 | pamaury | ok. I'll write some code tomorrow and see if we missed some things. I guess the real work is to rewrite the logf display |
| 18:34:53 | Torne | wrapping the text is likely to come out as a bigger diff, yes :) |
| 18:35:27 | funman | i thought wrapping was made by lcd code? |
| 18:36:26 | | Quit maruk ("Leaving.") |
| 18:36:44 | pamaury | no I don't think so, truncating yes, but not wrapping |
| 18:37:38 | Torne | funman: lcd_puts* just truncate. |
| 18:38:01 | funman | oh |
| 18:38:12 | funman | logfdump+texteditor ftw |
| 18:38:22 | Torne | heh |
| 18:38:49 | Torne | actually, *is* there a remotely sensible way to print wrapping text? |
| 18:38:51 | | Quit petur ("work->home") |
| 18:39:00 | Torne | lcd_puts* have all the information to tell you where the wrap point is |
| 18:39:06 | Torne | but then they throw that information away :) |
| 18:39:40 | Torne | well, wrapping at the edge, anyway (not neatly word wrapping) |
| 18:40:32 | | Join Lynx [0] (n=Lynx@xdsl-78-34-216-147.netcologne.de) |
| 18:40:57 | | Nick Lynx is now known as Guest71901 (n=Lynx@xdsl-78-34-216-147.netcologne.de) |
| 18:41:19 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 18:41:29 | pamaury | Torne: the lcd_puts function just call font_get_width for each character so it's quite easy to determine where to wrap |
| 18:41:41 | Torne | pamaury: yes, but that's what i mean |
| 18:41:47 | Torne | lcd_puts already calls font_get_width for every character |
| 18:42:02 | Torne | to implement wrapping yourself you would *also* need to do that, and then call lcd_puts on the result :) |
| 18:42:05 | Torne | thus doing the work twice. |
| 18:42:24 | Torne | plugins like the text viewer suffer through this because they are word wrapping so they have to keep track of hyphens and spaces and stuff |
| 18:42:36 | Torne | but for trivially just folding text around at the edge of the screen this seems kinda sucky ;) |
| 18:44:05 | funman | the code wouldn't be complex to write i think |
| 18:44:37 | funman | logf display isn't built by default, and the buffer can be dumped to a file |
| 18:44:53 | Torne | oh sure, i'm not suggesting it's a real problem |
| 18:45:12 | Torne | it just seems wasteful for any case where things might want to print wrapping text :) |
| 18:45:18 | | Quit Lynx_ (Read error: 60 (Operation timed out)) |
| 18:45:18 | | Nick Guest71901 is now known as Lynx_ (n=Lynx@xdsl-78-34-216-147.netcologne.de) |
| 18:46:17 | pamaury | anyway, a call to font_get_width should be very quick, just a lookup in a table, this is nothing compared to the real printing operation done by lcd_puts |
| 18:48:02 | kugel | Torne: we really should have a lcd_puts_wrapped() |
| 18:48:29 | kugel | maybe wait for Unhelpful committing his lcd driver unifying work |
| 18:48:43 | funman | if lcd_puts() already has the info, there could be a parameter for wrapping |
| 18:49:52 | Torne | yeah, it knows when it's gone too wide. |
| 18:50:05 | Torne | it quits the loop once it's gone pas the edge of the screen |
| 18:50:41 | funman | note that code usually tracks the line it is writing (as an argument to lcd_puts) and increment over it |
| 18:51:21 | funman | you wouldn't want to put the end of a long line on the line below and see if overwritten just after |
| 18:51:26 | kugel | funman: that's putsxy, and wrapping obviously wouldn't work for it |
| 18:51:31 | kugel | IIRC |
| 18:51:36 | Torne | while we're on the topic.. lcd_puts (rather than putsxy) behaves *really weirdly* for proportional fonts :) |
| 18:51:59 | pamaury | why ? |
| 18:52:03 | Torne | if you pass an X coord other than 0 in a proportional font the position it writes to is very very odd |
| 18:52:04 | funman | lcd_puts() takes the same argument than lcd_putsxy() : a x, a y, and a string |
| 18:52:30 | Torne | because it works out the pixel coord by getting the width of the string being printed in pixels and dividing it by the length in characters |
| 18:52:33 | Torne | then multiplying that by x |
| 18:52:52 | pamaury | ah... |
| 18:52:57 | pamaury | weird... |
| 18:52:57 | Torne | which means printing "iii" and "MMM" go to different places on the screen |
| 18:53:00 | Torne | given the same coordinates :) |
| 18:53:21 | pamaury | only the y coordinates in meaningful |
| 18:53:30 | Torne | it's basically just useless logic, since for a fixed width font it's wasted effort (you can just check the font width once) |
| 18:53:35 | Torne | and for proportional it's meaningless. |
| 18:53:43 | funman | kugel: lcd_putsxy takes pixel positions while lcd_puts takes characters position |
| 18:53:46 | Torne | it should probably use the width of some particulra character. |
| 18:54:13 | funman | '.' |
| 18:55:12 | Torne | heh, my instinct says '0' |
| 18:55:17 | Torne | (because that's what the z-machine says) |
| 18:55:18 | Torne | but hey |
| 18:55:30 | pamaury | just about the discussion on the work being done twice, isn't possible to write a lcd_puts_wrapped just by using lcd_putc ? This way, font_get_width would be called once for each character (except if lcd_putcs calls it of course) |
| 18:56:18 | | Nick DarkSpectrum- is now known as DarkSpectrum (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) |
| 18:56:22 | Torne | lcd_putc doesn't exist on bitmap targets |
| 18:56:44 | pamaury | ah, a good thing to know |
| 18:56:44 | Torne | also that's a pain :) |
| 18:57:20 | pamaury | why doesn't it exist ? It could always be implemented with lcd_puts (it sucks but it's possible) |
| 18:57:41 | funman | because it sucks |
| 18:57:46 | saratoga | atrac3 looks like fun to port to fixed point |
| 18:57:57 | saratoga | the code is clean and theres hardly any constants to convert |
| 18:58:11 | Torne | anwyay all this woul dbe better left until the lcd drivers were unified :) |
| 18:59:07 | pamaury | what will be the changes ? |
| 18:59:37 | * | Torne leaves for now though :) |
| 19:00 |
| 19:00:39 | kugel | pamaury: killing code duplication |
| 19:00:41 | | Quit robin0800_ ("Leaving") |
| 19:01:21 | pamaury | but will the api change ? |
| 19:01:38 | kugel | no |
| 19:01:57 | funman | i thought Unhelpful was only related to scrolling? |
| 19:02:17 | funman | Unhelpful's work on lcd* |
| 19:02:18 | kugel | that's another project :) |
| 19:02:38 | CIA-6 | New commit by bluebrother (r22254): Clean up accessing system setting values for a specific player. ... |
| 19:02:47 | | Join darkhamm [0] (n=darkhamm@95.234.18.47) |
| 19:03:48 | * | n1s aplologizes for be |
| 19:04:04 | n1s | s/be/breaking the logf thingy/ :/ |
| 19:04:09 | | Quit darkhamm (Client Quit) |
| 19:04:40 | funman | n1s: it's ok, i have no problem for you being |
| 19:05:12 | | Join stoffel [0] (n=quassel@p57B4CDC4.dip.t-dialin.net) |
| 19:05:24 | | Join darkhamm [0] (n=darkhamm@95.234.18.47) |
| 19:06:47 | kugel | funman: http://www.rockbox.org/tracker/task/4817 |
| 19:06:53 | kugel | n1s: wasn't your fault |
| 19:08:26 | | Quit parafin ("So long and thanks for all the fish") |
| 19:10:39 | | Join Blue_Dude [0] (n=chatzill@adsl-235-206-199.mco.bellsouth.net) |
| 19:11:15 | | Join kachna [0] (n=kachna@r4ax178.net.upc.cz) |
| 19:11:32 | Blue_Dude | kugel: bookmarking broke a few days back and I think I've traced it to a code cleanup you did (r22192/22193). |
| 19:12:16 | Blue_Dude | The fix looks simple, and I'm finishing it up now. |
| 19:12:24 | | Quit darkhamm ("Sto andando via") |
| 19:12:54 | *** | Saving seen data "./dancer.seen" |
| 19:15:33 | | Join faemir [0] (n=faemir@78.33.109.163) |
| 19:16:16 | | Quit stoffel (Remote closed the connection) |
| 19:16:44 | | Join stoffel [0] (n=quassel@p57B4CDC4.dip.t-dialin.net) |
| 19:17:05 | | Join parafin [0] (n=operator@paraf.in) |
| 19:18:25 | | Quit parafin (Client Quit) |
| 19:18:27 | | Join parafin [0] (n=operator@paraf.in) |
| 19:19:02 | bluebrother | Bagder: wouldn't it be nice to use a fixed-width font for the viewvc diffs? |
| 19:21:14 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
| 19:22:35 | Bagder | I agree |
| 19:27:07 | | Quit parafin ("So long and thanks for all the fish") |
| 19:27:16 | | Join parafin [0] (i=parafin@paraf.in) |
| 19:27:46 | | Quit funman ("free(random());") |
| 19:30:50 | saratoga | FS #10514 - itunes compatible time setting |
| 19:31:43 | kugel | Bagder: it would absolutely awesome |
| 19:31:49 | kugel | +be |
| 19:36:20 | Blue_Dude | kugel: FS #10512 |
| 19:45:01 | Llorean | Is there low battery shutdown on the Gigabeat S yet? |
| 19:49:26 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 19:49:30 | n1s | Llorean: think o |
| 19:49:31 | n1s | so |
| 19:50:53 | | Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]") |
| 19:51:21 | Llorean | n1s: The threshold may be too low then |
| 19:51:44 | Llorean | My Gigabeat with low battery hung at disc spinup. Sat there, just kinda waiting, until I plugged in AC after which it resumed playing as normal |
| 19:52:09 | n1s | yeah, that sounds plausible |
| 19:54:40 | | Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
| 19:54:51 | CIA-6 | New commit by gevaerts (r22255): Add support for setting the clock using a special SCSI command. This is the same method that itunes uses, and there are host-side tools for it (e.g. ... |
| 19:57:39 | n1s | Llorean: the shutoff voltage is 3.4V |
| 19:57:46 | saratoga | will itunes sync time on a rockbox'ed ipod ? |
| 19:59:51 | gevaerts | I suspect not (unless we do the xml descriptor thing as well), but the ipod-time-sync tool from libgpod will |
| 20:00 |
| 20:00:08 | gevaerts | I also suspect that some future version of rbutil will |
| 20:00:55 | gevaerts | ok, this is not good :\ |
| 20:01:57 | gevaerts | I disclaim any responsibility for the red though |
| 20:02:27 | Zagor | that's an odd error |
| 20:07:16 | | Join darkhamm [0] (n=darkhamm@95.234.18.47) |
| 20:07:17 | CIA-6 | New commit by gevaerts (r22256): Fix "statement with no effect" warning |
| 20:07:33 | | Quit faemir ("Leaving") |
| 20:08:33 | gevaerts | What's the best way to fix that delta for non-USB players? It comes from new functions in firmware/common/timefuncs.c, and I'd really like not to put #ifdef HAVE_USBSTACK and friends in there |
| 20:10:02 | kugel | I find the delta surprisingly high |
| 20:10:09 | Zagor | gevaerts: I'm a bit amazed that patch adds nearly a KB on some targets |
| 20:11:03 | | Join pyro_maniac [0] (n=pyro@91-64-165-18-dynip.superkabel.de) |
| 20:12:09 | kugel | it's little code added |
| 20:12:28 | kugel | how about automatically calling bloat-o-meter? :) |
| 20:13:35 | * | gevaerts thinks he found something |
| 20:13:40 | pixelma | kugel: what about your WPS (or viewport?) code shuffle delta? |
| 20:14:00 | kugel | that was weird also |
| 20:14:07 | gevaerts | hm, no |
| 20:14:54 | | Quit chandoo_ ("Leaving") |
| 20:15:46 | Zagor | perhaps we should look at making one or more libraries for support functions, so the linker can skip them |
| 20:16:24 | | Part Llorean |
| 20:16:59 | bertrik | how did that work again? |
| 20:17:20 | bertrik | it only links the functions that are actually used, when linking against a library? |
| 20:17:45 | Zagor | yes. all code from .o files are included even if they are not used. but code from .a files are only linked when referred to. |
| 20:17:50 | bertrik | instead of all functions in each object file that is specified |
| 20:20:36 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
| 20:22:40 | evilnick | Does anyone know offhand how many Supported targets there are? (individual models, so Sansa E-series would be 1, not 1 per capacity of internal flash) |
| 20:23:04 | JdGordon| | 28 isnt it? |
| 20:23:15 | JdGordon| | + 15 or so in progress |
| 20:23:59 | gevaerts | 28ish yes, depending on how you count ipod video 64MB and things like that |
| 20:25:43 | | Join Llorean [0] (n=DarkkOne@adsl-99-182-52-92.dsl.hstntx.sbcglobal.net) |
| 20:27:48 | | Quit darkhamm ("Sto andando via") |
| 20:30:31 | | Join Creposucre [0] (n=53c3739e@gateway/web/cgi-irc/labb.contactor.se/x-d3450091697a82a7) |
| 20:30:44 | | Join faemir [0] (n=faemir@78.33.109.163) |
| 20:30:50 | Creposucre | Hi |
| 20:31:32 | kugel | does anyone mind introducing __attribute__((unused))? |
| 20:31:46 | | Join p3tur [50] (n=petur@rockbox/developer/petur) |
| 20:32:38 | kugel | I have a patch that touches plugins a bit, i.e. all plugin_start() and cleanup() definitions get their parameter attributed with that to remove various (void)var statements |
| 20:32:43 | bertrik | I'd rather avoid using attributes unless absolutely necessary |
| 20:33:24 | kugel | why? |
| 20:33:54 | bertrik | it's something compiler-specific, I like doing stuff with plain C |
| 20:34:06 | | Quit flydutch ("/* empty */") |
| 20:34:18 | JdGordon| | whats the point of the change? |
| 20:34:29 | Creposucre | Does anyone know if any rockboxed or rockboxable player has a remote tuner? |
| 20:35:03 | Creposucre | except ipods |
| 20:35:04 | JdGordon| | Creposucre: hey, I added a slightly better logging patch to 9951.. dunno if oyu saw it |
| 20:35:07 | kugel | removing various (void)var; (which isn't even optmized away always), make it clearer that a paramter may be unused |
| 20:35:11 | JdGordon| | (/me hoping he isnt confusing nicks) |
| 20:36:12 | Creposucre | no, i didn't saw it |
| 20:36:15 | Creposucre | gonna try it ;) |
| 20:37:24 | | Join darkhamm [0] (n=darkhamm@95.234.18.47) |
| 20:38:34 | Creposucre | i'll be right back |
| 20:40:24 | | Quit pamaury ("Quitte") |
| 20:42:21 | DarkSpectrum | ok i'm lookin to try out my m200v4, where is the page with firmware instructions? |
| 20:42:43 | kugel | I'm not trying to kill every (void)foo, but for certain functions, like callbacks |
| 20:43:20 | bertrik | what does the bloat-o-meter.py do? |
| 20:43:22 | JdGordon| | I tinhk adding that to the function is going to make it harder to read than adding a (void)foo; line |
| 20:43:40 | Unhelpful | funman: the scrolling style hooks patch layers on another one that unifies all styled text drawing - it's just so much easier if i don't have to make the edits in five different files |
| 20:44:16 | Unhelpful | bertrik: breaks down binary size changes per-symbol, showing which symbols have been added or removed, and which have changed size |
| 20:45:22 | bertrik | what kind of files does it take? |
| 20:45:56 | domonoky | DarkSpectrum: the SansaAMS wiki page contains install instructions for this. |
| 20:46:07 | Unhelpful | any elf objects, i think... obviously it's only useful if they're *related* objects. :) |
| 20:46:14 | * | DarkSpectrum doesnt see it for the m200v4 |
| 20:46:16 | | Quit HellDragon (Read error: 104 (Connection reset by peer)) |
| 20:46:28 | | Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) |
| 20:46:50 | domonoky | DarkSpectrum: installation is the similar for all AMS Sansa devices |
| 20:47:21 | | Quit HellDragon (Read error: 54 (Connection reset by peer)) |
| 20:47:22 | bertrik | DarkSpectrum, there are some serious issues with the m200v4 port, like shutting down when the volume goes too high |
| 20:47:33 | | Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) |
| 20:47:57 | DarkSpectrum | i saw that, i don't even care if i brick it, it's not like it's a player i use anyway, just interested in playing with it |
| 20:48:03 | bertrik | also, last time I tried it, I found the volume quite low already compared to other as3525 players |
| 20:48:45 | bertrik | DarkSpectrum, maybe you could have a look at fixing this if you feel like it |
| 20:48:55 | domonoky | yes, something is wrong with volume on m200v4, but apart from that it works (of course the general low-mem playback bug also applies) |
| 20:49:35 | * | DarkSpectrum is already commited to a project |
| 20:50:33 | * | domonoky thinks some powermanagement init is missing on the m200v4 (its the only ams target with 1.5v supply) |
| 20:50:52 | bertrik | my gut feeling is that there is something wrong with the power management setup, the big difference between the m200v4 and other as3525 sansas is that it is AA powered instead of lithium |
| 20:50:58 | | Quit Lss (Read error: 104 (Connection reset by peer)) |
| 20:51:30 | bertrik | domonoky, we (I even) could have a look at the OF powermanagement setup |
| 20:52:34 | domonoky | that would be good. (but i am not good enough with asm). |
| 20:52:37 | kugel | JdGordon|: how? |
| 20:53:16 | DarkSpectrum | i could test ;P |
| 20:53:19 | bertrik | domonoky, I guess I can find it within an hour, I'll have a go at it tonight |
| 20:53:23 | DarkSpectrum | figured out how to install |
| 20:53:43 | JdGordon| | I assume they get added like void foo(int bar __attribute__((unused)), int boo) ? |
| 20:53:46 | kugel | I'm using UNUSED_ATTR instead of __attribute__((unused)) directly |
| 20:54:00 | kugel | like this: enum plugin_status plugin_start(UNUSED_ATTR const void* parameter) |
| 20:54:17 | CIA-6 | New commit by gevaerts (r22257): rework new time handling functions a bit to be more memory efficient |
| 20:54:31 | JdGordon| | thats still not pretty |
| 20:54:33 | * | bertrik spots m200 disassembly pictures on the forums of sandisk.com :\ |
| 20:54:38 | | Quit stripwax ("http://miranda-im.org") |
| 20:55:26 | kugel | JdGordon|: I think it is, definitely more pretty than (void)parameter everywhere. |
| 20:56:18 | * | domonoky likes "(void)parameter;" more. and its not compiler specific... |
| 20:57:15 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 20:58:09 | | Quit FOAD ("Lost terminal") |
| 20:58:09 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 20:58:17 | | Quit FOAD (Client Quit) |
| 20:58:25 | kugel | it's not a no-op always |
| 20:58:29 | kugel | Bagder tested it |
| 20:58:34 | | Join FOAD [0] (n=dok@dinah.blub.net) |
| 20:58:44 | kugel | much code without -O2 for example |
| 20:59:37 | gevaerts | better, but not good enough |
| 21:00 |
| 21:00:00 | * | gevaerts means the delta, not the unused parameter things |
| 21:00:38 | kugel | I rather not count on gcc optimizing it if we can force it |
| 21:00:47 | domonoky | the question is: how much does it hurt ? in a place like plugin_start a extra instuction doesnt hurt. |
| 21:01:21 | kugel | there are many places in the core too |
| 21:01:39 | kugel | I think it always hurts if we can avoid it easily |
| 21:03:56 | Zagor | adding compiler-specific kludges isn't exactly a pretty solution either. even if we are rather locked into gcc anyway. |
| 21:05:59 | Zagor | I'm split, personally. both solutions are rather ugly. |
| 21:06:01 | kugel | we're heavily locked. and this unused won't even break other compilers, just give a few warnings |
| 21:06:18 | Zagor | where is it used in the core? |
| 21:07:05 | kugel | event callbacks, a few functions which do nothing on #ifndef HAVE_XXX |
| 21:07:10 | kugel | few other cases too |
| 21:07:21 | | Quit stoffel (Read error: 104 (Connection reset by peer)) |
| 21:07:59 | kugel | I like it as it makes clear it's potentially not used (even if it's used), you'll find (void)foo; only if it's actually unused |
| 21:08:15 | kugel | some #if branches just exist for doing that (void)foo; |
| 21:10:03 | gevaerts | Any opinions on moving day_of_week() and yearday_to_daymonth() to usb_storage.c? That's the only place they're used right now, and it seems like the easiest way to get binsize back on non-usb targets |
| 21:10:25 | JdGordon| | kugel: wait what? you can add (void)foo lines even if it is used |
| 21:10:49 | JdGordon| | but in any case... neither hsould be used when it *might* be used... or "partially" used |
| 21:10:52 | kugel | gevaerts: usb_storage seems a bad place :( maybe just a new usb_time.c? |
| 21:11:11 | kugel | JdGordon|: huh why neither? |
| 21:11:12 | gevaerts | kugel: that doesn't sound much better I think |
| 21:11:29 | kugel | gevaerts: sounds much better to me, but that's just my opinion |
| 21:11:46 | bluebrother | gevaerts: sounds a bit odd to me, but still somewhat reasonable. The only thing that might get problematic is someone adding the same functionality in time_funcs.c later |
| 21:11:50 | | Join TheSphinX^ [0] (n=cold@p54A5C007.dip.t-dialin.net) |
| 21:11:52 | JdGordon| | if I see the ATTR_UNUSED thing next to a var.. it would be damn confusing to then go and see it being used... |
| 21:11:59 | JdGordon| | thats an abomination! :D |
| 21:12:10 | JdGordon| | (void)foo is much nicer in that case |
| 21:12:13 | gevaerts | kugel: usb_storage is bad because these functions have nothing to do with usb as such. Putting them in a new usb_time.c still implies usb |
| 21:12:34 | kugel | JdGordon|: I can't agree with that |
| 21:12:42 | JdGordon| | you can and you will!!! |
| 21:12:47 | * | JdGordon| lays down the law! |
| 21:12:49 | * | bluebrother also likes (void)foo better |
| 21:12:52 | saratoga | cant you just leave them where they are and add an ifdef? |
| 21:12:53 | JdGordon| | ... not really :p |
| 21:12:56 | kugel | gevaerts: I'm more concerned of the _storage bit |
| 21:12:59 | *** | Saving seen data "./dancer.seen" |
| 21:13:01 | saratoga | HAVE_TIME_FUNCTIONS |
| 21:13:27 | bluebrother | gevaerts: call it usb_misc.c? Or usb_kludge.c? ;-) |
| 21:13:39 | bertrik | gevaerts, what about Zagor's suggestion? |
| 21:13:41 | DarkSpectrum | in cygwin where is libsdl-dev |
| 21:13:42 | DarkSpectrum | ? |
| 21:13:51 | JdGordon| | gevaerts: yeah, dont put them in the storage driver.... thats either going to lead to mess later, and/or code doubling up.. or just good old oplain nasty mess |
| 21:13:55 | bluebrother | in a cygwin package? |
| 21:13:59 | JdGordon| | screw the delta... it shuold go in time_funcs |
| 21:14:11 | gevaerts | bertrik: that's not going to be easy |
| 21:14:15 | DarkSpectrum | yes |
| 21:14:35 | Zagor | I agree the time code should stay in timefuncs. delta is not everything. |
| 21:14:42 | bluebrother | simply #ifdef them ... that makes it clear that only USB_STORAGE uses them. |
| 21:15:00 | saratoga | can SD cards be powered down when they're not being read? |
| 21:15:08 | kugel | it doesn't have anything to do with storage IIUC |
| 21:15:29 | bertrik | I also wonder if these kind of functions (day of week etc.) are not already implemented somewhere else |
| 21:15:39 | bluebrother | why doesn't it have anything to do with storage if only storage uses the functions? |
| 21:16:44 | kugel | bertrik: I think every rtc driver has some sort of day_of_weak() |
| 21:17:27 | bertrik | regarding the unused attribute, this could be a nice opportunity to use the bloat-o-meter to see if it has any binsize-benefit |
| 21:17:47 | kugel | JdGordon|: I meant to add it too all callbacks, like I did to every plugin_start() no matter of the parameter actually being used |
| 21:17:57 | pixelma | it's been a weak day? ;) |
| 21:18:16 | bluebrother | pixelma: definitely ;-) |
| 21:18:22 | Zagor | isn't the attribute put in plugin.h? |
| 21:18:28 | JdGordon| | kugel: there is no need to add it to everything... especially when it introduces confusion.... but yes, when the callback has it as "void* unused" by all means do it |
| 21:18:51 | kugel | no |
| 21:18:58 | JdGordon| | no? |
| 21:19:16 | kugel | it's also meant to indicate the parameter for a function type, not for single functions |
| 21:20:15 | DarkSpectrum | trying to setup a build system and i can not find libsdl-dev |
| 21:20:29 | DarkSpectrum | err a build client |
| 21:24:23 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 21:28:04 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 21:28:16 | | Nick p3tur is now known as petur (n=petur@rockbox/developer/petur) |
| 21:30:00 | kugel | bertrik: this is -O0 vs -O2 http://pastie.org/580378 |
| 21:30:23 | CIA-6 | New commit by gevaerts (r22258): Consolidate day of week calculation |
| 21:31:39 | Zagor | kugel: surely it is not surprising that disabling optimisation does not optimise that? |
| 21:32:12 | gevaerts | After this there's only yearday_to_daymonth() left. I think it can be argued that it is specific enough to make it a static function in usb_storage.c |
| 21:32:12 | kugel | no, not really |
| 21:32:35 | kugel | (for Zagor) |
| 21:32:49 | kugel | but I think we don't build all targets with -O? |
| 21:32:51 | JdGordon| | gevaerts: I was going to suggest, why not just add a set_time_from_usb() in timefuncs and then just pass the scsi message directly and do no proccessing in usb_Storage at all? |
| 21:34:03 | gevaerts | JdGordon|: I can't think of good arguments right now, but I don't like that idea |
| 21:34:16 | | Quit amiconn (Nick collision from services.) |
| 21:34:19 | | Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) |
| 21:34:39 | | Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) |
| 21:34:41 | kugel | DarkSpectrum: interesting, no configure? :) |
| 21:34:55 | | Quit pixelma (Nick collision from services.) |
| 21:34:56 | | Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) |
| 21:34:59 | JdGordon| | is that worse than having time stuff in usb storage (which obviously isnt a good place for it?) |
| 21:35:13 | | Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) |
| 21:36:18 | gevaerts | Why is it obviously not a good place for it? I fully agree about the day_of_week thing, but the other one? |
| 21:37:22 | | Quit moos ("Rockbox rules the DAP world") |
| 21:37:47 | gevaerts | Zagor: can you reschedule the build? I'd really like to see those deltas |
| 21:38:08 | Zagor | yes, I will |
| 21:38:13 | gevaerts | thanks |
| 21:38:15 | kugel | i think usb_storage.c is a bad place for even the RECEIVING_TIME case, what does it have to do with storage? |
| 21:38:31 | gevaerts | kugel: we can rename it to usb_scsi... |
| 21:38:47 | kugel | we should do so then |
| 21:38:53 | gevaerts | I can't move it out of there. It's part of the scsi handling |
| 21:39:29 | kugel | the whole file seems to be a mix of storage and scsi |
| 21:41:18 | gevaerts | but do we rename an entire file away from the expected name because it happens to handle one unrelated function? |
| 21:42:15 | linuxstb | Isn't storage and scsi basically the same thing? |
| 21:42:36 | gevaerts | usb storage is scsi, yes |
| 21:42:47 | kugel | and other stuff, apparently |
| 21:42:55 | kugel | :p |
| 21:43:01 | linuxstb | Then I don't see any problem. This time thing is a non-standard extension to UMS IIUC. |
| 21:43:15 | gevaerts | kugel: no. usb_storage is also other things, usb storage isn't ;) |
| 21:43:22 | linuxstb | (or do I not UC?) |
| 21:43:33 | kugel | gevaerts: that's what I meant :) |
| 21:44:15 | gevaerts | linuxstb: it depends on how you look at it. It uses the SCSI WRITE_BUFFER command, which is standard, and valid for all SCSI devices. It uses the vendor specific mode of that though |
| 21:44:39 | * | gevaerts isn't sure what to do if/when we implement UAS |
| 21:46:09 | JdGordon| | UAS? |
| 21:46:49 | kugel | gevaerts: the tm struct could've been local to the case (minor picking :) ) |
| 21:46:49 | gevaerts | USB Attached SCSI. A new spec that properly does SCSI over USB instead of the hackish way that UMS uses |
| 21:47:30 | gevaerts | JdGordon|: if we hurry, we're first. Neither linux nor windows have it yet :) |
| 21:47:53 | linuxstb | That would make testing an interesting challenge... |
| 21:48:05 | tmzt | isn't the transport used for ATAPI/mmc enough? |
| 21:48:15 | kugel | gevaerts: neither wikipedia, apparently |
| 21:48:15 | gevaerts | tmzt: huh? |
| 21:48:29 | tmzt | for SCSI commands I mean |
| 21:48:36 | tmzt | oh, new spec |
| 21:49:05 | tmzt | mmc is that case being what cd recorders use, not multimedia card |
| 21:50:00 | gevaerts | indeed. I'd like to do mmc at some point to allow pretending to be a CD drive to boot from |
| 21:50:53 | gevaerts | or possibly even to export playlists as CDs to the host :) |
| 21:50:53 | JdGordon| | with iso9660 mounting..... |
| 21:51:32 | amiconn | kugel: All parts of rockbox are built with some -O level. Most use -O2, some use -O (== -O1) or -O3. Lowmem targets use -Os in many places instead |
| 21:53:42 | amiconn | gevaerts: Why does this clock setting stuff cause a red delta on all targets? I would expect it to apply to software usb targets only |
| 21:55:30 | gevaerts | amiconn: that's what we're debating about right now. There are two new functions in timefuncs.c. One of them (set_day_of_week()) belongs there IMO, and I've changed screens.c to use it instead of doing the same calculation itself. The other, yearday_to_daymonth() is specific enough to move to usb_storage.c I think, but others disagree |
| 21:57:41 | gevaerts | the alternatives are to either live with the delta (which I think is not a good idea) or add USB ifdefs to timefuncs.c (which I think is even worse) |
| 21:59:21 | | Quit LambdaCalculus37 () |
| 22:00 |
| 22:00:05 | linuxstb | gevaerts: I think I agree with moving that function into usb_storage - it's the least worst option... |
| 22:03:17 | JdGordon| | I dont see the problem with adding USB ifdefs to timefuncs... |
| 22:03:31 | JdGordon| | I thing that is far less bad than adding timefuncs to the usb storage drivre |
| 22:03:59 | | Part pyro_maniac ("Leaving.") |
| 22:04:02 | CIA-6 | New commit by gevaerts (r22259): Move yearday_to_daymonth() to usb_storage.c. It's the only user, this function is pretty specific, and it seems to be the cleanest way to avoid ram ... |
| 22:04:34 | * | kugel agrees with JdGordon| but won't argue further seeing it's too late :p |
| 22:05:33 | Jaykay_ | will the volume affect battery life? i did two battery benches a few months ago and it didn't, but maybe i did something wrong... |
| 22:05:50 | | Quit darkhamm (Read error: 110 (Connection timed out)) |
| 22:05:52 | | Nick Jaykay_ is now known as Jaykay (n=chatzill@p5DDC5D2B.dip.t-dialin.net) |
| 22:06:49 | | Quit merbanan ("Leaving") |
| 22:07:08 | | Quit panni_ ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") |
| 22:07:44 | | Join panni_ [0] (i=hannes@ip-95-222-19-21.unitymediagroup.de) |
| 22:07:54 | kugel | Zagor: how does this best fit work? I'm constantly getting the hardest build eventhough I don't have a particular strong client |
| 22:08:25 | gevaerts | kugel: that means that that particular build just fits the expected round time on your client |
| 22:08:52 | Zagor | kugel: yes, you get the hardest build you are expected to be able to complete, plus some small builds to fill out the time |
| 22:09:25 | kugel | ah, alright |
| 22:16:17 | rasher | The graph does reflect that fairly well |
| 22:16:28 | rasher | Lots of bars filling most of the round |
| 22:17:03 | | Join Strife89 [0] (n=michael@adsl-220-100-163.mcn.bellsouth.net) |
| 22:17:33 | | Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) |
| 22:18:06 | Creposucre | JdGordon|: I tried your patch |
| 22:18:14 | Creposucre | works great |
| 22:18:20 | JdGordon| | in and out? |
| 22:18:35 | JdGordon| | my video only logged in comms (or out... cant remembeer which) |
| 22:18:41 | Creposucre | yes |
| 22:19:20 | bertrik | domonoky, found some m200v4 power management code, I'll see if I can compare it with the other targets |
| 22:19:27 | JdGordon| | is the log buffer a good size? |
| 22:19:31 | domonoky | nice :-) |
| 22:20:30 | Creposucre | i just get a strange character before each log |
| 22:20:45 | Creposucre | but it doesn't matter |
| 22:21:09 | | Quit jgarvey (Read error: 110 (Connection timed out)) |
| 22:21:33 | JdGordon| | yeah, maybe some logic to make sure we dont try writing one byte at the start would be good |
| 22:21:58 | JdGordon| | also writing the \0 to the log file isnt a good idea yeah? |
| 22:22:07 | Creposucre | also i was thinking about your dock power feature |
| 22:22:20 | Creposucre | yes i agree |
| 22:23:20 | Creposucre | did you get something like FF 55 XX 02 00 00 00 0X XX? |
| 22:24:45 | JdGordon| | my log is filled with IN 040200X000 where X is either 1 or 0 |
| 22:25:09 | JdGordon| | also a few 0402000800 |
| 22:25:28 | Creposucre | Ok |
| 22:26:04 | Creposucre | this is mode 2 of accessory protocol, which isn't complete yet |
| 22:26:26 | Creposucre | and there is a power command which may be what you have |
| 22:26:27 | JdGordon| | it would be nice if more info was in the log.. like if the command was recognised |
| 22:26:52 | | Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) |
| 22:28:34 | | Join readabil1ty [0] (n=chad@206.248.173.89) |
| 22:28:52 | | Quit pixelma_ (" .") |
| 22:29:13 | Creposucre | And in apple mode, dthe power button put it in sleep mode or hibernate mode? |
| 22:30:30 | JdGordon| | sleep I'd guess.... havnt tried it |
| 22:32:18 | Creposucre | we could, in rockbox mode, make it hibernate when it receive the power off signal |
| 22:32:24 | | Quit J-23 (K-lined) |
| 22:32:34 | gevaerts | except that we don't hibernate at all |
| 22:32:50 | Creposucre | but i never tried the alarm feature, it can boot the ipod by itself? |
| 22:33:15 | Creposucre | by hibernate, i mean power it off |
| 22:33:18 | JdGordon| | untill we get hibernate.. I'd expect power to be the same as play/pause |
| 22:33:31 | JdGordon| | or turn off completly |
| 22:33:38 | JdGordon| | yeah, the docks alarm should turn the ipod on |
| 22:33:50 | Creposucre | ok |
| 22:33:58 | | Quit Jaykay ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]") |
| 22:34:37 | Creposucre | i'll try to add some others commands tomorrow |
| 22:38:32 | Creposucre | did you made some experiments on you mini? |
| 22:38:46 | Creposucre | for the serial |
| 22:39:34 | JdGordon| | no, didnt get around to it |
| 22:39:58 | | Quit readability (Read error: 110 (Connection timed out)) |
| 22:40:06 | CIA-6 | New commit by bluebrother (r22260): Fix Rockbox Utility build on W32. |
| 22:41:29 | | Quit TheSphinX^ ("XChat@Linux") |
| 22:42:32 | Creposucre | put myself in sleep mode |
| 22:42:41 | Creposucre | good night |
| 22:43:58 | | Quit Creposucre ("CGI:IRC (EOF)") |
| 22:46:36 | | Join dmb [0] (n=Dmb@unaffiliated/dmb) |
| 22:52:41 | | Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) |
| 22:53:36 | | Quit killan_ (Read error: 104 (Connection reset by peer)) |
| 22:53:51 | | Join pamaury [0] (n=pamaury@sal63-1-82-243-96-220.fbx.proxad.net) |
| 22:54:54 | pamaury | Torne: are you there ? |
| 22:55:00 | Torne | yes |
| 22:56:03 | pamaury | I made mistake in the patch of logf :) The logf in still buffy, I made a horrible computation error in the memcpy |
| 22:56:15 | | Join killan [0] (n=nnscript@c-0efa70d5.06-397-67626721.cust.bredbandsbolaget.se) |
| 22:56:16 | pamaury | memcpy(ptr, buf + tlen,len-tlen); |
| 22:56:36 | Torne | well apparently i didn't see it |
| 22:56:42 | Torne | that's what you get for trusting me :) |
| 22:56:55 | * | Torne is not a dev or anything |
| 22:57:14 | pamaury | Yes, in fact len is decreasing by the loop so the correct code is: |
| 22:57:21 | pamaury | memcpy(ptr, buf + tlen,len); |
| 22:57:21 | Torne | it was technically safe, if slightly obscure, with a strcpy for that |
| 22:57:32 | Torne | ah yes |
| 22:57:41 | Torne | nothing is ever easy |
| 22:58:12 | pamaury | This is horrible because len-tlen is often negative ! This can lead to a much undefined behaviour |
| 22:58:47 | Torne | meh |
| 22:58:50 | Torne | i wouldn't worry a great deal :) |
| 22:59:00 | Torne | logf is compiled out by default, just poke someone to fix it |
| 22:59:06 | Torne | it's not going to have broken anyone's actual build |
| 23:00 |
| 23:00:23 | pamaury | I will submit a patch to FS. These logf things will never be over :) |
| 23:01:03 | CIA-6 | New commit by gevaerts (r22261): Fix endpoint allocation ... |
| 23:02:01 | linuxstb | gevaerts: Do we have any other working USB drivers, or is it just "arc" ? |
| 23:02:10 | Torne | at least you spotted it |
| 23:02:56 | pamaury | well I had a nice surprise when doing some tests, I don't understand how I missed it |
| 23:04:01 | gevaerts | linuxstb: we have more, but the others have quite different endpoint allocation, so I don't expect this bug there |
| 23:04:56 | linuxstb | gevaerts: I was just asking in general, nothing to do with that commit |
| 23:05:48 | gevaerts | ah, ok. We have arc, tcc, the one in the mr500, the ingenic one, and whatever is in the zvm (although that one probably is a bit behind) |
| 23:05:52 | pixelma_ | DarkSpectrum: are you running a cygwin server? |
| 23:05:59 | DarkSpectrum | yes |
| 23:06:05 | DarkSpectrum | updating it now |
| 23:06:36 | pixelma_ | it shows some weird warnings (known problem on cygwin and mingw) for the sims |
| 23:07:00 | pixelma_ | I guess easiest is to not let it build sdl |
| 23:07:05 | DarkSpectrum | hmmm.... ok i'll just run vmware then |
| 23:07:12 | DarkSpectrum | or i could do that |
| 23:07:13 | n1s | pixelma: ah, does this affect newer gcc's too? |
| 23:07:23 | pixelma_ | no idea |
| 23:07:59 | DarkSpectrum | is sdl the only problem with cygwin? |
| 23:07:59 | n1s | but yeah, easiest to drop sdl builds |
| 23:08:16 | pixelma_ | DarkSpectrum: vmware will be a bit faster, so probably more usefull |
| 23:08:56 | bluebrother | vmware should be noticably faster ... |
| 23:09:09 | DarkSpectrum | do i want vmware player? |
| 23:09:24 | bluebrother | yes, if going the vmware route. |
| 23:09:52 | bluebrother | you should also be able to use VirtualBox and run the vmware image, though I've never tried that with the Rockbox vmware image. |
| 23:10:11 | bluebrother | in case you prefer using VirtualBox |
| 23:10:12 | DarkSpectrum | only thing i've ever done is virtualpc, never vmware |
| 23:11:27 | * | bluebrother uses VirtualBox a lot. Especially for building releases of Rockbox Utility :) |
| 23:11:35 | DarkSpectrum | downloading vmware player now, i downloaded the RB vmware image a few months ago, does it change, hence should i grab a new copy? |
| 23:12:05 | linuxstb | bluebrother: Have you thought about incorporating the 32MB/64MB detection into rbutil? |
| 23:12:18 | | Join darkhamm [0] (n=darkhamm@95.234.18.47) |
| 23:13:03 | *** | Saving seen data "./dancer.seen" |
| 23:14:16 | bluebrother | linuxstb: yes. I also thought about the new time stuff :) |
| 23:14:41 | linuxstb | What about the case when Rockbox USB is running? |
| 23:14:45 | Bagder | is 187 seconds the current buildround record? |
| 23:15:00 | Zagor | Bagder: that's actually wrong. it was a failed round. |
| 23:15:02 | bluebrother | as for the 64MB detection I'd like to give multi device detection a go the same time. |
| 23:15:07 | Bagder | ah |
| 23:15:22 | linuxstb | bluebrother: You mean more than one device connected at the same time? |
| 23:15:25 | bluebrother | if Rockbox USB is running we still can figure the player by the rockbox-info.txt file |
| 23:15:27 | Bagder | DarkSpectrum's client seems to be... bad |
| 23:15:41 | Zagor | Bagder: yeah, cygwin is messy |
| 23:15:42 | DarkSpectrum | i killed it |
| 23:15:44 | bluebrother | yes. domonoky made a patch for that a while ago, but unfortunately it's kinda outdated. |
| 23:15:47 | pixelma_ | Bagder: already solved |
| 23:15:48 | DarkSpectrum | setting up vmware |
| 23:16:04 | linuxstb | bluebrother: Well, that assumes that file is correct... But I agree it's probably good enough. |
| 23:16:20 | pixelma_ | Bagder: I mean the "why" of it |
| 23:16:32 | bluebrother | I'd like to get that finished, at least the basics, with better reporting of unsupported devices. Seems quite some people miss that. |
| 23:17:03 | linuxstb | bluebrother: What does rbutil when it detects multiple devices, gives the user a choice? |
| 23:17:08 | bluebrother | linuxstb: well, I thought about that too. The main problem I see is that we're going to wrongly detect the player once a wrong build has been installed. |
| 23:17:52 | linuxstb | Is Rockbox USB enabled on ipods yet? |
| 23:17:53 | bluebrother | currently it has no handling of multiple devices. It's even buggy in that aspect: I had two players connected a while ago, and it detected one player but the mountpoint of the other. |
| 23:18:31 | bluebrother | it's enabled at least for svn builds. |
| 23:18:41 | domonoky | currently it just detects the first device it finds.. and the code could need improvement so it easier to extend to new targets. |
| 23:18:46 | bluebrother | don't know about the lasest release. |
| 23:19:09 | bluebrother | domonoky: spotted the bug I've mentioned? It gets confused with multiple devices |
| 23:19:41 | | Join Stephen [0] (n=S@86-40-176-149-dynamic.b-ras2.srl.dublin.eircom.net) |
| 23:19:42 | domonoky | bluebrother: yes, thats because we have no way to map usb-ids to mountpounts.. |
| 23:19:51 | | Nick Stephen is now known as Guest53570 (n=S@86-40-176-149-dynamic.b-ras2.srl.dublin.eircom.net) |
| 23:20:01 | | Nick Guest53570 is now known as Stephen__ (n=S@86-40-176-149-dynamic.b-ras2.srl.dublin.eircom.net) |
| 23:20:36 | bluebrother | not only. It's also because we trust USB IDs, and then fill in the missing parts, ignoring that the first matching USB ID could be something different than the first non-usb-detected player. |
| 23:20:44 | domonoky | yes |
| 23:20:57 | domonoky | multi-device detection could solve that.. |
| 23:21:13 | bluebrother | it should :) |
| 23:21:25 | bluebrother | though it isn't that easy, unfortunately |
| 23:21:40 | domonoky | at least we can present the user with a list and a warning if rbutil isnt sure what is what. |
| 23:22:16 | linuxstb | Or simply tell the user to disconnect one... |
| 23:22:25 | | Quit thegeek_ ("( www.nnscript.com :: NoNameScript 4.2 :: www.regroup-esports.com )") |
| 23:22:48 | n1s | anyone with multiple robckboxable DAP's is probably an rb dev anyway :) |
| 23:22:48 | bluebrother | allowing multiple devices to be connected is nicer ;-) |
| 23:23:22 | amiconn | n1s: Those warnings are mingw-sdl speficic, not cygwin only. They also appear when crosscompiling a win32 sim |
| 23:23:40 | bluebrother | n1s: are we writing rbutil for users? ;-) |
| 23:23:41 | amiconn | It has nothing to do with gcc version, but with gcc target |
| 23:23:52 | domonoky | and it helps if we missdetect something, or can not distingush two targets.. or have multiple potential mountpoints for a device. |
| 23:24:15 | n1s | amiconn: aha, is it because of -g together with -ffunction-sections? |
| 23:24:17 | | Join J-23 [0] (n=kvirc@a105.net128.okay.pl) |
| 23:24:29 | n1s | ... on win32 |
| 23:25:17 | amiconn | Iiuc it's emitted when -ffunction-sections is used for some (gcc) targets. win32 is one of them |
| 23:25:34 | amiconn | There's a whole thread on the gcc ml regarding this warning... |
| 23:25:47 | n1s | useful :/ |
| 23:29:21 | | Quit domonoky (Read error: 104 (Connection reset by peer)) |
| 23:31:30 | Utchybann | I have a question about tab allocation in functions. Why is it better to declare them as 'static' ? |
| 23:31:51 | Zagor | tab allocation? |
| 23:32:20 | Utchybann | s/tab/array/ |
| 23:32:24 | | Join ehntoo [0] (n=ehntoo@adsl-99-156-195-44.dsl.applwi.sbcglobal.net) |
| 23:32:24 | n1s | because you then don't need to create them on the stack, *if* they are const |
| 23:32:40 | n1s | so you save a bit of code |
| 23:32:58 | Zagor | but you waste a bit of ram |
| 23:33:13 | n1s | Zagor: not really |
| 23:33:17 | Bagder | not if they are const, then they need to be there in the first place too |
| 23:33:24 | Zagor | right, not if they are const |
| 23:44:38 | Utchybann | I don't see the difference between a static array and a static const array. They are both in the .data section of the executable ? |
| 23:45:00 | amiconn | A const array is in .rodata |
| 23:45:16 | amiconn | And on targets where rockbox can run from flash, this saves RAM |
| 23:45:42 | amiconn | .data needs to be copied to RAM in crt0, .rodata doesn't |
| 23:46:34 | pamaury | gevaerts: have you ever of "usb debug device" or "usb debug port" ? |
| 23:46:40 | pamaury | * ever head |
| 23:46:40 | | Quit evilnick ("Page closed") |
| 23:46:44 | pamaury | *ever heard |
| 23:47:00 | Utchybann | amiconn: thanks. I'm new to rockbox. Sorry for the noise. |
| 23:47:33 | gevaerts | pamaury: not sure. What do you mean? |
| 23:47:43 | tmzt | what re you aksing about? |
| 23:48:37 | | Quit DarkSpectrum (Read error: 104 (Connection reset by peer)) |
| 23:48:39 | | Join DarkSpectrum- [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) |
| 23:48:43 | | Nick DarkSpectrum- is now known as DarkSpectrum (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) |
| 23:48:59 | pamaury | gevaerts: just curious, I ran lsusb and the sansa receive a strange get_descriptor request, ask for 0xA type. But the usb spec does define such a descriptor so by using lsusb code I found out that it was a "debug descriptor' |
| 23:49:27 | gevaerts | I don't know about it... |
| 23:50:06 | pamaury | I manage to find references about in EHCI doc and a strange "usb debug device" spec on google (but not on usb-if) |
| 23:50:21 | | Quit petur (Remote closed the connection) |
| 23:50:44 | tmzt | yes, that's the low level debug functionality in some host chipsets and motherboards |
| 23:54:04 | DarkSpectrum | what is the rockbox vmware root login? |
| 23:54:31 | pamaury | ok |
| 23:58:24 | | Quit darkhamm ("Sto andando via") |
icon identifies that the person is a core developer (has commit access).