--- Log for 30.08.109 Server: orwell.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 3 days and 1 hour ago 00.00.06 # It looks to me like there is a gap between the colour of the last row and the line in the new version that wasn't there before (clearly only visible if the last row is blue) 00.00.45 # AlexP: this was also the case with the original booktabs. I really like it. 00.00.56 Quit stoffel (Remote closed the connection) 00.00.57 # I much prefer it without the space :) 00.01.41 # But I will bow to the majority view: pixelma, bluebrother? 00.02.32 # fml: Is the line between the header and the table easily movable? 00.02.48 # between the header and the body of the table that is 00.03.06 # AlexP: that would be hard to implement (IMO) since at the point of the macro def you don't know the color of the row. Its number is available through some macro but it's too much magic for me. I'm not a texnitian! :-) 00.03.32 # AlexP: that will be another patch :-) 00.03.39 # fml: OK, cool :) 00.06.58 # AlexP: actually, here's the patch that does both (first and the last rows): http://pastebin.ca/1547663 Please test. But don't tell me it doesn't work!!! 00.07.09 # hehe, I'll try :) 00.08.05 # AlexP: all is much simpler than I thought! 00.10.02 # AlexP: sorry, you don't need that line with tabrowstrut. It's a rest from an earlier try. 00.10.48 # which line? 00.10.55 # Is this latest from clean svn? 00.11.22 # AlexP: line #15 in the patch. Yes, it's relative to the last svn 00.13.42 # looks good! 00.14.09 # What about cygwin (pixelma)? 00.15.48 # I'll leave soon. SHould I commit and hope that cygwin won't complain? 00.16.19 *** Saving seen data "./dancer.seen" 00.16.21 # Not sure :) 00.16.42 # I'm testing 00.17.01 # OK. I'm going in busy waiting mode 00.18.07 # New commit by 03kugel (r22551): Samsung YH: Many keymap fixes for keyboard screen, wps, set time/date and quickscreen. Little kludge for quickscreen: Entering the quickscreen ... 00.18.51 # yes, I do like the quickscreen 00.19.43 # fml: I wonder a bit why I get cr/lf with your patches although I select "download raw" from pastebin 00.19.57 # nothing major, just out of interest 00.20.34 # pixelma: because pastebin first lets me enter the patch in a text field in the browser (I think) 00.20.44 Join Llorean [0] (n=DarkkOne@rockbox/user/Llorean) 00.20.49 # that's because pastebin adds them. Just about any paste service does that for some reason 00.21.15 # pixelma: sill compiling? Not complaining? ;-) 00.21.25 # you should paste them base64 encoded :) 00.21.27 # *still 00.21.42 # no, but I wanted to have a look at the result 00.23.46 # pixelma: now? Or tomorrow? 00.23.56 # New commit by 03kugel (r22552): Samsung YH: Make going back to the main menu by keeping cancel press also work. For some reason, this needed on Samsung YH, but not on an e200 (it ... 00.25.54 # I just looked at the time I had to answer your questions first... I think the spacing at the table end looks a bit weird but all that has the small advantage that the black horizontal lines are more likely to show up - in some cases they don't and I couldn't discover a pattern why and which tables are affected 00.26.29 # as you can understand from this, building works fine still 00.27.03 # fml ^ 00.27.14 # What places look weird? Can you tell the page no? 00.27.33 # *number 00.28.24 # I'll commit then. 00.29.25 # New commit by 03alle (r22553): Manual: Fix the vertical spacing in the first and the last rows in tables 00.30.42 # What??? It didn't build after the commit for me! 00.31.15 # Ah, now it does. Weird. 00.31.34 # pixelma: thanks for testing 00.31.53 # pixelma: same from me! 00.32.27 # e.g. *some* plugin button tables (doesn't have to be all tables on a page), e.g. there are 2 on page 65 of an OndioFM manual (both brickmania ones), but e.g. in the split editor chapter one is affected, the other is not 00.33.39 # pixelma: I don't build the manual for those players. Are the tables made using the environment (btnmap)? 00.33.47 # AlexP: did you take the jackpot screenshot of an Ondio for all Archoses? 00.34.06 # * fml Leaves. Bye! 00.34.09 Quit fml ("CGI:IRC 0.5.9 (2006/06/06)") 00.34.21 # pixelma: I can't remember if it was an Ondio, but it was the same one (recorder I think) 00.35.34 # Or rather, I just took one screenshot for the screen size 00.36.26 # fml (for the logs): yes, in the split editor case - both are btnmap, one shows up completely correct the other doesn't 00.38.02 # AlexP: you must have used an Ondio one sim then (or the screenshot function is broken) - as this screenshot has the Ondio "backlight" background colour. The screenshot has more target specific colours for a while now but this hasn't been adapted for the manuals yet 00.38.27 # but this screenshot stands out now because it's blueish not greenish 00.38.40 # ah right, I just picked a random target of that screen size 00.39.04 # are all the others done with a different target? 00.39.54 # so either we would always take Recorder ones for Archos manuals or start updating screenshots per target. Well, before the Ondio screenshots showed the same background colour 00.40.31 # I don't envy the person that redoes every single screen shot for a specific target 00.40.37 # some had to be made with/for the Ondio, e.g. all that don't show a clock... 00.41.21 # er.... I mean - ones that show a clock on RTC targets 00.41.55 Quit Llorean ("Leaving.") 00.44.52 # AlexP: same applies to H100/M5/Ipod Greyscale screenshots (though the differences are more subtle) 00.46.37 Quit stripwax ("http://miranda-im.org") 00.46.52 Join CaptainKwel [0] (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 00.47.06 Quit domonoky1 (Read error: 104 (Connection reset by peer)) 00.48.03 # would be nice if screenshots for the manual could somehow be automated. Doing those screenshots for same sized displays but different targets (with different colours) would also mean a lot of almost duplication :\ but would be a bit nicer for the readers of the manual 00.50.01 # pixelma: i guess it could be done by executing a set of actions but it would be hard for plugins 00.51.30 Quit funman ("free(random());") 00.55.35 Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) 01.01.11 Quit GeekShado_ (Read error: 60 (Operation timed out)) 01.03.41 # I bet you could do something with xte 01.04.31 Quit n1s ("Lämnar") 01.05.55 Join rotzbouw [0] (n=thierry@dslb-092-075-212-134.pools.arcor-ip.net) 01.05.59 # hi 01.06.34 # so how do I do this to make my ipod be identified as a usb mass storage device rather than the ipod upon connecting/mounting it? 01.08.14 # it's worked before but today I had to reset it with itunes and now it always gets identified as apple ipod rather than 'rockbox audio player' in dmesg (on debian) 01.10.50 # grml, the lcd init on the yh925 isn't correct I think 01.11.03 # it seems we actually flip the display in rockbox 01.11.29 # omitting 1 lcd command in the init makes the OF work correct, but that obviously breaks rockbox 01.14.45 Quit robin0800 (Remote closed the connection) 01.15.01 # ah, i think i got it.. it was disabled in 3.3? current build's looking better 01.22.33 Join FOAD_ [0] (n=dok@dinah.blub.net) 01.27.39 Quit rotzbouw (Remote closed the connection) 01.31.17 Quit FOAD (Read error: 145 (Connection timed out)) 01.31.17 Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) 01.31.56 Quit Klowner (Remote closed the connection) 01.31.59 Join Klowner [0] (n=klown@71-209-101-211.dvnp.qwest.net) 01.50.45 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 01.52.39 Join Llorean [0] (n=DarkkOne@rockbox/user/Llorean) 01.54.15 # Did the release schedule change at some point? 01.57.32 Quit stripwax ("http://miranda-im.org") 02.10.47 Part Buschel 02.10.51 # Don't think so. Are we due? 02.11.06 # Dunno 02.11.09 # anyone want to test the latest ATRAC3 patch on CF? 02.11.21 # But it was posted in the forums by Saratoga that it's every 4 months, so I wanted to know if that was a typo or if we changed it. 02.11.21 # well preferably an iaudio i guess so the IRAM changes apply 02.12.07 # that should have been 4 times a year not 4 months 02.12.20 # Pretty sure it's still 3 months. How long was the freeze/branch periods? Last one was June 16th 02.12.23 # eh, 19th 02.12.31 # ok fixed the post 02.12.35 # So, fairly soon. 02.12.47 # yep 02.13.06 # Alright. I was just curious that I might've missed some schedule changing. 02.13.39 # saratoga: if you tell me where to get an atrac file from and have a few minutes time I volunteer testing with my M5 02.16.21 *** Saving seen data "./dancer.seen" 02.18.07 # pixelma: http://samples.mplayerhq.hu/real/AC-atrc/ 02.18.30 # with and without v7 of this patch: http://www.rockbox.org/tracker/task/10565 02.18.33 # if possible 02.18.49 # someone on the forums asked about tagging NSF files 02.18.55 # do we even support that 02.19.34 # Since a single NSF file has multiple tracks in it, which may be composed by different people and have unique names (sometimes even just being sound effects) there's no suitable way to database them 02.19.56 # looking at the code i don't even see a metadata parser, but he says theres tags when he plays it 02.21.00 # I thought there were. 02.21.15 # I haven't played an NSF in ages though, and don't have the player they're on with me. 02.21.37 # the codec itself seems to know about the file tags, is it possible for it to update teh WPS during playback (well after buffering) 02.23.07 Quit bertrik (Read error: 113 (No route to host)) 02.25.31 Join jboy_ [0] (n=langzeit@p5B17E891.dip.t-dialin.net) 02.27.52 # saratoga: I used the "Goodbye Caroline" track and without the patch playback stalls every second, buffering takes longer than usual, put on a patched build now 02.30.46 # pixelma: could you try test_codec? 02.30.52 # thats mostly what I'm curious about 02.33.11 # is that a standalone program? 02.33.15 # I'll try but I hope it won't take too long 02.34.18 # is that FUN_RM a real track I could use for testing purpose? 02.36.46 Quit GeekShadow (Read error: 110 (Connection timed out)) 02.37.31 # pixelma: I don't see why not 02.38.20 # tmzt: its a rockbox plugin, but there is a patch that allows it to compile outside of rockbox, although the process is not trivial 02.42.12 # is it not possible to interrupt test_codec? 02.42.39 Quit langzeitstudent_ (Read error: 110 (Connection timed out)) 02.42.51 # * pixelma curses not having chosen a shorter track 02.43.13 # as I wanted to 02.44.13 # force a reboot 02.48.40 # speed test result of the fun_rm track with path: 19.31% realtime, 643.11 MHz needed 02.48.49 # patch too 02.49.11 Quit AndyI (Read error: 104 (Connection reset by peer)) 02.53.12 # without patch: 18.24% realtime, 680.84 MHz 02.55.07 Join AndyI [0] (i=AndyI@212.14.205.32) 02.59.17 # wow 03.00.13 Quit z35 (Read error: 110 (Connection timed out)) 03.02.00 Join z35 [0] (n=z35@ool-45701ce5.dyn.optonline.net) 03.05.02 # * pixelma reads something about realtime on PP in the patch description... 03.07.02 Quit Thundercloud (Remote closed the connection) 03.07.43 # I'm off for sleep now though, bye 03.08.17 # pixelma: its due to lack of ASM for fixed point functions on CF 03.08.25 # well in large part 03.13.21 Quit Llorean ("Leaving.") 03.31.42 Quit AndyI (Read error: 104 (Connection reset by peer)) 03.34.30 Quit chandoo ("Leaving") 03.34.33 Join AndyI [0] (i=AndyI@212.14.205.32) 03.38.37 Join toffe82 [0] (n=chatzill@64.146.249.41) 03.57.41 Join xavieran [0] (n=xavieran@ppp118-208-247-54.lns10.mel6.internode.on.net) 04.01.33 Join xavieran_ [0] (n=xavieran@ppp118-208-165-223.lns10.mel4.internode.on.net) 04.01.49 # New commit by 03kugel (r22554): Samsung YH925: Implement lcd flipping. Although it's a questionable feature, it should enable us to fix the problem that the OF's display is flipped ... 04.02.05 # so, finished 4h of trial and error :p 04.04.46 Quit xavieran (Read error: 60 (Operation timed out)) 04.04.50 Nick TheSeven is now known as UselessTron (n=theseven@dslb-084-056-146-066.pools.arcor-ip.net) 04.04.58 Nick UselessTron is now known as TheSeven (n=theseven@dslb-084-056-146-066.pools.arcor-ip.net) 04.06.00 Quit TheSeven (Nick collision from services.) 04.06.18 Join The_Seven [0] (n=theseven@84.56.185.82) 04.06.24 Nick The_Seven is now known as TheSeven (n=theseven@84.56.185.82) 04.07.38 Join SimSimma [0] (i=SimSimma@c-68-33-26-6.hsd1.md.comcast.net) 04.08.58 # kugel: celebrate by posting yh bootloaders 04.13.19 # will do, later :) 04.13.35 # wow someone posted an NSF metadata parser 04.14.59 # someone needs a life. 04.16.23 *** Saving seen data "./dancer.seen" 04.16.43 # limiter preamp isn't an exactly cheap feature :/ 04.18.59 # CaptainKwel: reviewed your patch 04.22.01 # saratoga: I'm not sure why we're flipped compared to the OF, the comments in the file suggest it's based on disassembly 04.22.26 # but there's a big copy&paste business for that controller going, the comments are probably horrible inaccurate 04.22.48 # kugel: maybe whenever the code was reverse engineered it happened to be flipped by accident and no one ever fixed it 04.22.53 # saratoga: thanks for the catch, copied and pasted without thinking. 04.23.12 # clean it up and i see no reason not to commit it 04.29.37 # New commit by 03kugel (r22555): Dreaded last minute changes at 4am :( Fix red. 04.38.50 Join dys` [0] (n=andreas@95.114.214.254) 04.42.50 # New commit by 03kugel (r22556): Fix x_offset for YUV blitting. 04.43.22 Quit Rondom (Nick collision from services.) 04.43.32 Join Rondom [0] (n=Rondom@dslb-084-057-182-231.pools.arcor-ip.net) 04.43.46 # saratoga: I think I'll just change our behavior instead of calling lcd_set_flip() in the bootloader 04.47.16 # CaptainKwel: looks good but I wonder where the 120 seconds thing comes from for length? 04.48.18 # Anybody know the progress of rockbox for the sansa fuze? 04.48.35 # check the status link on the front page 04.48.47 # okey dokey 04.48.58 # i guess the 120 is just a dummy variable taken from mod since we don't know the NSF length? 04.50.05 # Just thought it would be better than leaving it at 0. I think SPC tracks loop? Not sure if there's a way to calculate length without actually playing through the file. 04.51.13 # ok it seems reasonable enough 04.51.38 # is this your first patch accepted? 04.51.45 # Yes. 04.52.17 # ok i'll add you to credits too 04.52.40 # Cool. Thanks. 04.53.12 Quit dys (Connection timed out) 04.53.18 # New commit by 03saratoga (r22557): Accept FS#10570 by Jason Yu. Adds metadata parsing for NSF files. 04.53.27 Quit sinthetek (Read error: 54 (Connection reset by peer)) 04.54.16 Quit SimSimma ("Leaving") 04.55.40 Quit panni_ ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 05.14.38 # saratoga: I think you left out metadata/nsf.c 05.15.45 # New commit by 03saratoga (r22558): Patch doesn't SVN add . . . 05.26.39 Join ademille [0] (n=ademille@c-24-10-232-214.hsd1.ut.comcast.net) 05.37.06 # saratoga: gaah, the OF is also flipped horizontally 05.38.01 # haha 05.39.01 # I don't really bother to fix that also :/ 05.39.28 # we have 1, maybe 2 or 3 yh925 users. I doubt anyone of them wants to go into the of 05.43.30 Quit gevaerts (Nick collision from services.) 05.43.32 # CaptainKwel: still awake? 05.43.42 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 05.43.56 # yes 05.44.26 # else if (memcmp(buf, "NESM",4)) should be else if (!memcmp(buf, "NESM",4)) right? 05.45.06 Quit kadoban (Remote closed the connection) 05.45.27 Join kadoban [0] (n=mud@24.93.17.195) 05.46.25 # we want to continue if it is NESM 05.47.13 # Yeah, I think I screwed up my logic. 05.47.35 # * kugel likes being explicit for that reasons for functions returning 0 on success for that reason 05.48.01 # yes the return values here are confusing 05.48.10 # e.g. with if (blah != 0) or something 05.49.46 # http://pastebin.com/m25793c34 05.49.48 # look good? 05.50.59 # Yes. 05.52.10 Quit kugel (Remote closed the connection) 05.52.15 # New commit by 03saratoga (r22559): Logic was backwards on the check for NSF file format. Fix that and save one memcmp. 05.59.41 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 06.00.48 Join Ronoh55 [0] (n=41bda16d@gateway/web/cgi-irc/labb.contactor.se/x-mhxqnpfbhfzssopo) 06.01.25 Join Llorean [0] (n=DarkkOne@rockbox/user/Llorean) 06.01.29 # CaptainKwel: looking at this closer, does the strlen logic work? 06.02.01 # p += strlen(p)+1; is only going to increment the length by whatever the length of the first string was, not the length of the one you just added 06.03.14 # oh nevermind 06.03.55 # its too late for me to be thinking about this 06.04.12 # though i do wonder if its a good idea to assume the input is a null terminated string 06.04.57 Quit saratoga ("Page closed") 06.06.14 Quit Ronoh55 ("CGI:IRC (Ping timeout)") 06.07.26 Quit Llorean ("Leaving.") 06.16.27 *** Saving seen data "./dancer.seen" 06.28.22 Part toffe82 06.44.00 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 06.50.58 Part ademille 07.06.09 Join Horschti [0] (n=Horscht2@xbmc/user/horscht) 07.24.48 Quit Horscht (Read error: 110 (Connection timed out)) 08.06.28 Join saratoga [0] (i=463f90ed@gateway/web/freenode/x-uitgberxsnkzgvlj) 08.07.09 # theres apparently a new Sansa Clip revision floating around with a microsd slot 08.10.21 Join NooB23 [0] (n=noob23@ppp-93-104-182-201.dynamic.mnet-online.de) 08.11.02 Quit saratoga (Client Quit) 08.16.29 *** Saving seen data "./dancer.seen" 08.34.45 # how can i write chars like 'ö,ä,ü,...' on the display with 'rb->lcd_puts(0, 0, XXX);'? 08.38.30 Quit alexbobp (Read error: 110 (Connection timed out)) 08.39.13 Join Rob2223 [0] (n=Miranda@p4FDCF1BA.dip.t-dialin.net) 08.50.04 Join stoffel [0] (n=quassel@p57B4F124.dip.t-dialin.net) 08.51.39 Join n1s [0] (n=n1s@rockbox/developer/n1s) 08.56.40 Quit Rob2222 (Read error: 110 (Connection timed out)) 09.14.40 Join stoffel_ [0] (n=quassel@p57B4EE99.dip.t-dialin.net) 09.20.05 Join advcomp2019_ [0] (n=advcomp2@unaffiliated/advcomp2019) 09.20.36 Quit timc (Read error: 110 (Connection timed out)) 09.22.43 Join timc [0] (n=aoeu@221.201.155.114) 09.28.45 Quit stoffel (Read error: 110 (Connection timed out)) 09.32.57 Quit advcomp2019 (Read error: 113 (No route to host)) 09.47.41 Quit NooB23 (Excess Flood) 09.47.44 Join flydutch [0] (n=flydutch@host214-146-dynamic.15-87-r.retail.telecomitalia.it) 09.47.57 Join NooB23 [0] (n=noob23@ppp-93-104-182-201.dynamic.mnet-online.de) 09.57.22 Join mt [0] (n=MTee@rockbox/developer/mt) 09.57.22 Quit MG_Man ("...GOT AWAY SAFELY!") 10.03.07 Quit flydutch ("/* empty */") 10.07.47 # i wonder if the masking should be done everywhere we convert from bcd, it only seems to be necessary for som rtc's 10.13.29 Quit timc (Read error: 110 (Connection timed out)) 10.16.32 *** Saving seen data "./dancer.seen" 10.25.28 Quit crashd_ ("leaving") 10.25.37 Join crashd [0] (i=foobar@lostnode.org) 10.37.34 # bluebrother: if you're awake, could you test the new version of fs#10569 on that rtc modded h100? 10.40.13 # is it possible to print 'ä,ö,ü,...' on the lcd? 10.44.06 # yes 10.44.36 # rockbox supports unicode 10.47.07 # on my simulator i have the ISO-8859-1 active and this side (http://www.binaryessence.de/csf/de000215.htm) say that 0xE4 is the code for 'ä'... so i write in my string \xe4 but it does not work 10.48.18 # Rockbox always uses utf-8 internally 10.49.10 Join decayedcell [0] (n=decayed_@60-241-92-53.static.tpgi.com.au) 10.49.42 # The codepage setting applies to tags only, as rockbox cannot figure out the encoding itself for some tagging formats 10.50.59 # ahhh ok, so i have to print the utf8-code of the char i want 10.53.52 # is this command the right for me 'utf8decode(ASCII,OFFSET)' (dont know if i really understand it) 11.01.12 # Just use an utf-8 string. Decoding a constant at runtime would be a waste 11.05.42 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 11.09.02 Join flydutch [0] (n=flydutch@host214-146-dynamic.15-87-r.retail.telecomitalia.it) 11.11.51 # utf8encode(0xe115, buf); thisone? 11.13.39 # No. just rb->lcd_puts(l, c, "ÄÖÜäöü"); 11.14.02 # Your editor needs to be set to utf-8 when writing this 11.22.05 Nick Horschti is now known as Horscht (n=Horscht2@xbmc/user/horscht) 11.25.29 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 11.31.54 Quit NooB23 ("Nettalk6 - www.ntalk.de") 11.40.56 # rasher: about your automatic screenshot patch - would it be possible to make the script hook up a bit "deeper/earlier", i.e. at the moment you would need probably one script per target, if it could send the ACTION_SOMETHING or BUTTON_SOMETHING in the plugins you could use one script for almost all targets, no? 11.41.49 # s/target/keypad 11.42.56 Quit BHSPitLappy (Remote closed the connection) 11.43.07 # Pretty sure it'd require an entirely different approach 11.43.45 # That hooked into Rockbox itself. Which I don't really have any idea how would work 11.47.38 Join Lynx_ [0] (n=Lynx@xdsl-87-78-38-198.netcologne.de) 11.51.04 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 12.00.27 Join petur [50] (n=petur@rockbox/developer/petur) 12.16.34 *** Saving seen data "./dancer.seen" 12.19.28 Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) 12.38.42 Join __lifeless [0] (n=lifeless@94.51.194.186) 12.46.16 Join ender` [0] (i=krneki@foo.eternallybored.org) 12.51.00 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 12.52.56 Quit _lifeless (Read error: 110 (Connection timed out)) 12.53.22 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 12.53.30 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 13.01.10 Join Bagder [241] (n=daniel@rockbox/developer/bagder) 13.04.05 Join Buschel [0] (n=AndreeBu@p54A3C2AC.dip.t-dialin.net) 13.13.56 Join Lear [0] (i=chatzill@rockbox/developer/lear) 13.28.29 Join GeekShado_ [0] (n=Antoine@38.222.192-77.rev.gaoland.net) 13.45.24 Quit petur ("lunch!") 13.45.25 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 13.47.08 Quit GeekShadow (Read error: 110 (Connection timed out)) 14.03.24 Join pamaury [0] (n=apouly@slsu0-19.ens-lyon.fr) 14.04.43 # anyone with an M5/X5 willing to support me with testing a patch? 14.07.24 # if you mean the one in the tracker, I tested this night when saratoga asked - should be in the logs 14.08.11 # pixelma: yes, I already saw it. but now I have some more coldfire stuff to test 14.08.57 # ok, where can I find the new things? 14.09.04 # http://pastebin.com/m1f1ac829 14.10.33 # shall I apply this instead of the old or additionally 14.10.42 # instead of the old one 14.10.53 Join _lifeless [0] (n=lifeless@94.51.194.186) 14.12.19 # ok, building 14.15.08 # I get build errors (and warnings) though 14.15.20 # hmm, can you pastebin? 14.15.26 # *them 14.16.38 *** Saving seen data "./dancer.seen" 14.19.17 # the sims just use SDL for keyboard events, right? would it be hard to make them accept commands from the console or via a named pipe that they're passed as an argument? 14.19.55 # that would get rid of the focus issues with the screenshot script 14.20.29 # Buschel: http://pastebin.com/d7b83dfcf 14.22.55 # forgot the last line - which was just that make fails 14.23.40 # pixelma: i'll need some time now... thanks so far. you stay online for a while? 14.24.13 Quit pamaury ("Parti") 14.24.45 # online - always (except in case of technical failure), at keyboard - most probably 14.25.52 # Unhelpful: sounds like a useful solution. The focus thing isn't a great problem - just don't touch the computer while it runs :-) 14.26.55 Quit __lifeless (Read error: 113 (No route to host)) 14.27.42 # a pipe could also accept commands that map directly to actions, instead of to simulated buttons that map to actions, so that you wouldn't have to worry about per-target keymaps at all. 14.28.57 # ie, "cancel\n" on the pipe could send ACTION_STD_CANCEL directly :) 14.32.07 Join BdN3504 [0] (n=55b235c8@gateway/web/cgi-irc/labb.contactor.se/x-faqwqhdjittnhucq) 14.33.11 Quit flydutch ("/* empty */") 14.34.07 # is it possible that i build the manual without having a vm installed on a winxp machine? 14.34.56 # BdN3504: if all of the needed tools are available for cygwin, i don't see why not. 14.34.58 # i have miktex, texniccenter and tortoisesvn installed and already checked out the latest revision into a folder with tortoisesvn 14.35.37 # the PDF manual can be build with cygwin 14.36.09 # ok, i'll make myself familiar with cygwin then. thanks 14.36.42 # the HTML one probably *could* if someone figures out (and tells me) how to manually install the tex4ht package - or it becomes available for automatic installation 14.37.45 Nick YpsyZNC is now known as Ypsy (n=ypsy@geekpadawan.de) 14.38.27 # so when i have installed cygwin right, i will be able to run ../tools/configure from within the windows commandline? or does it work differently? 14.39.10 # from within the cygwin shell 14.39.14 # ok 14.39.32 # isn't cygwin *slower* than the emulators? 14.40.41 # VM is probably quicker but it's ok for building the manuals 14.45.26 Join pamaury [0] (n=pamaury@140.77.26.34) 14.46.46 # pixelma: which option will i have to take to install unicode suppport on cygwin? http://www.rockbox.org/twiki/bin/view/Main/ManualHowto#manually_installing_unicode_supp 14.49.37 # the first (manual), I put the files in the place where LaTex complained it couldn't find them after a first make manual (although I think it doesn't matter much) - and I had to run mktexlsr 14.50.57 # Unhelpful: sounds good. I look forward to the patch! 15.16.06 # pixelma: can you try this one? -> http://pastebin.com/m16921224 15.18.31 # New commit by 03mcuelenaere (r22560): Fix Onda VX777 boot extension 15.21.50 Quit TheSeven (Excess Flood) 15.21.56 Join lyngaas [0] (n=staale@19.81-167-149.customer.lyse.net) 15.22.28 Join TheSeven [0] (n=theseven@dslb-084-056-185-082.pools.arcor-ip.net) 15.24.49 # funman, I looked a bit closer at the c200v2 button readout, it gets 9 bits in total (bits 2..6 and bits 12..15) from the DBOP IN, the power button is read separately 15.31.38 Join flydutch [0] (n=flydutch@host214-146-dynamic.15-87-r.retail.telecomitalia.it) 15.32.51 Part decayedcell 15.34.13 Quit parafin (Read error: 60 (Operation timed out)) 15.36.32 Join parafin [0] (i=parafin@paraf.in) 15.38.32 Quit pamaury (Read error: 60 (Operation timed out)) 15.41.41 Quit BdN3504 ("CGI:IRC") 15.42.13 Quit bluebrother (Nick collision from services.) 15.42.18 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 15.43.50 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 15.47.28 Join funman [0] (n=fun@rockbox/developer/funman) 15.48.57 Join pamaury [0] (n=pamaury@140.77.26.34) 15.49.39 # hello, I have some questions. The first one is about tagcache: I noticed that there is a tagcache_retrieve method to retrieve a string tag of any entry indexed by it "idx_id". But why there is no equivalent method for numeric tags ? Then, what is the size of the audio buffer or the minimum size I can assume ? 15.49.47 # Buschel: will do 15.51.08 Join timc [0] (n=aoeu@116.3.145.189) 15.51.40 Join fyrestorm [0] (n=nnscript@cpe-68-173-235-106.nyc.res.rr.com) 15.52.52 # pixelma: perfect :) at least it should compile now 15.55.04 Join cfp [0] (n=cfp@abo-152-58-68.mts.modulonet.fr) 15.55.27 # indeed it does. I assume you want a speed test again? 15.56.00 # pixelma: yesm and of course a quick listening test whether it still decodes fine 15.57.09 # pamaury: i don't know for tagcache but the audio buffer can range from 30kB to 30MB 15.57.31 # 60MB 15.57.47 # well, currently 16.00.17 # ah right, basically rockbox runs on targets with 2, 8, 16, 32, 64 MB of SDRAM. Some only have 1MB but I believe they are not supported and porting on them is now inactive 16.03.15 # Buschel: wow, speed test (with the same track as earlier) - 134.76% realtime, 92.15 MHz CPU needed. Listening test - yes, I can actually listen to the song now and recognise it! Everything in the WPS looks alright and seeking works too. :D 16.03.35 # strrrike! :) 16.04.16 # * Buschel dances the realtime dance 16.04.29 # pamaury: depending on how much buffer you need to allocate, you can make your code conditional on memory size 16.06.08 # This is MTP related. The problem is that tagcache seems really sloooooooooooow. So perhaps some caching would be useful 16.06.24 Join panni_ [0] (i=hannes@ip-95-222-19-21.unitymediagroup.de) 16.06.55 # But caching the whole database requires toomuch some memory I think 16.08.04 # * mt hands Buschel some nice stuff for his optimizations :) 16.08.31 Quit bzed (Read error: 60 (Operation timed out)) 16.11.03 Quit stoffel_ (Remote closed the connection) 16.11.16 # funman, DBOP bits 12..15 are not mapped to a GPIO pin so that probably explains why we could not find them yet 16.11.42 # (DBOP bits 12..15 are connected to some buttons) 16.12.16 Join bzed [0] (n=bzed@78.47.255.100) 16.13.51 # i remember having checked all the dbop bits, currently we read bits 2 to 6 16.14.04 # (assuming you speak about the c200v2) 16.14.26 # New commit by 03Buschel (r22561): Further performance optimization of the atrac3 decoder. Rework the internal sample representation and usage of dsp routines. For now a quick and dirty ... 16.14.51 # the c200v2 OF also does something button-related with DBOP bits bits 12-15 16.15.44 # +639%, wow !! 16.16.40 *** Saving seen data "./dancer.seen" 16.17.00 Quit n17ikh (Connection timed out) 16.19.04 # and there is still room for more ;o) 16.19.18 # i'll look again in a few moments, my c200v2 was completely discharged 16.19.26 # bertrik: where do you see this code ? 16.19.35 # Buschel: impressive, indeed! :) 16.19.57 # i'm using c200v2 OF v3.02.05 16.19.59 Join saratoga [0] (i=463f90ed@gateway/web/freenode/x-sbjjjhtbrdvoxrxt) 16.20.49 # Unhelpful: such a command interface could even contain commands such as starting a specific .rock 16.22.01 # the button read routine is at 0x3e6c, it reads the DBOP and re-arranges some bits of the value read, then adds the power button bit 16.24.48 # at 0x3E80 it only keeps bits 6:2 16.25.39 # Does the sdl sim simulate button-reading delays somehow? When sending automated keypress/release events, I have to sleep between each, or it gets eaten rather than added to the button queue 16.25.51 # mt/saratoga: I forgot to mention that I have compared rockbox atrac3-decoding output to ffmpeg's (as a reference). The channels were definately switched in svn before r22561. Also: the current rockbox output is inverted (caused my change of the imdtc-window). But the worst is: rockbox's output differs a lot from ffmpeg's (even before my optimizations). The noise is ~20dB below the signal. 16.26.54 Join _zic [0] (n=user@91-165-233-183.rev.libertysurf.net) 16.28.15 Quit Buschel () 16.28.58 # funman, at 0x3e86 it shifts the dbop_in bits right by 7 bits and at 0x3e90 it ANDs it with 0x1E0, thereby keeping bits 12..15 16.31.00 # ah right, and then it's OR'd with the bits 6:2 16.32.16 # yes 16.32.46 Quit mt (Read error: 113 (No route to host)) 16.39.07 # funman, do you know how the buttons are actually connected to the DBOP lines in the ams sansas? 16.39.38 # I mean, do the button switches enable some kind of weak pull-down resistor on the DBOP lines? 16.39.54 # no idea i'm very stupid wrt electrics 16.41.25 Join Buschel [0] (n=abc@p54A3C2AC.dip.t-dialin.net) 16.43.36 # bits 15:8 are always 0 whenever i press buttons or not 16.43.50 # it seems a bit silly that we send some LCD command to write outside of the visible area in order to pre-charge the DIN lines 16.44.30 # I think it's possible to manipulate the DBOP data lines directly without having to send an actual LCD command, simply don't toggle any of the command lines 16.45.14 # in fact the OF writes some bits after each read 16.49.33 # weird that you don't see anything on DBOP bits 12..15, I'm convinced something must be connected there 16.50.01 # also, don't you see anything on bit 2? 16.51.20 # bit 2 is left button 16.52.26 # ah ok, the SansaAMSHardwareMappings wiki is not up-to-date 16.53.06 # well perhaps it was not possible to read the left button on the GPIO 16.54.47 # I think I should add bit 2 to the table, even though it's not readable through GPIO, it's at least somehow connected to that pin 16.56.33 # I'll check if we're using 16-bit mode when reading DBOP, that could explain our current inability to read bits 12..15 16.57.35 # I would like to borrow a c200v2 for cleaning up the c200v2 lcd and button reading 16.57.58 Join n17ikh [0] (n=n17ikh@host-69-59-126-212.nctv.com) 16.58.04 # well i could send you the one ej0rge sent me 16.59.03 # indeed we are using 8 bits mode 16.59.08 # I would appreciate that 16.59.56 Quit pamaury ("exit(*(int *)0 / 0);") 17.04.16 # bertrik: bit 12 of dbop_ctrl is for *output* data width 17.13.05 # data input is always 16 bits according to the register description 17.13.29 # although the summary of 7.3.12 mentions 8 and 16 bits 17.16.07 # the code starting at 0x4450 does seem to explicitly enable 16-bit mode before reading DBOP_DIN 17.16.44 Quit _lifeless (Remote closed the connection) 17.17.02 # i haven't detailed the exact bit sets in my disassembly 17.17.18 # i have set bit 12 in button_read_dbop though and bits 15:8 still are 0 17.18.13 Quit cfp ("Quitte") 17.18.27 Quit Lynx_ (" HydraIRC -> http://www.hydrairc.com <- It'll be on slashdot one day...") 17.19.42 Join merbanan [0] (n=banan@c-83-233-172-245.cust.bredband2.com) 17.22.12 Part Ypsy ("WeeChat 0.2.6.3") 17.23.08 Join kugel [0] (n=kugel@rockbox/developer/kugel) 17.23.24 # funman: the c200v2 uses 8bit mode? Why that? 17.23.55 # kugel: you can't switch between 8 and 16 bits for dbop _input_ 17.24.15 # saratoga, I really really appreciate the way you leave a note at the end of the threads you send to the trash. Thanks. 17.25.31 # funman: I mean for output 17.25.52 # well i don't know 17.26.25 # DBOP_DOUT = *data << 8 | *data >> 8; 17.26.28 # it's a 16bit display, I'd expect at least 16bit written at a time. the fuze/e200v1 also use 16bit mode 17.26.35 # that means it's at least using 32 bits 17.28.06 # it just the bytes in data, doesn't it? 17.28.20 # fb_data is 16bit 17.28.51 # oh so it's doing a byte swap 17.29.20 # hm right 17.29.26 # since DBOP_DOUT is a short* 17.29.40 # do we have macros for fast byte swapping? 17.30.34 # gcc adds 2 useless instructions :/ 17.30.51 # lsl 16, lsr 16 to clear the 16 msb, and then it uses strh 17.32.18 # I've often wondered about memory-mapped IO pointers being smaller than 32 bit 17.32.41 # the pointers, or the memory pointed to ? 17.32.44 # DBOP can be 32bit too, but we don't use it so far 17.32.52 # DBOP out, at least 17.33.16 # kugel: ah the FIFO can be 32 bits, but not the real output 17.33.24 # perhaps we can use 32 bits only with DMA 17.34.36 # funman: the table under table 71 shows 2 32bit modes 17.35.10 # the FIFO is always 32bit, so depending on DBOP_DOUT 24, 16 or 0 bits are wasted per transfer 17.35.15 # funman, one write cycle takes 16 PCLK cycles, so it's quite slow. Also we're keeping the DBOP FIFO topped up, so the byte swap probably isn't slowing things down, I expect most of the time is "wasted" in the while-FIFO-full loop 17.36.15 # funman, I mean the IO memory locations 17.38.51 # I can imagine that you get useful compiler warnings if you try to access a peripheral register with more bits than actually used by the peripheral, but I expect that most of the time this just results in useless truncations/casts 17.39.15 # has anyone heard from FlynDice recently about the SD clocks on AMS? 17.39.30 # it seemed like he had good results 17.40.06 # rasher: that might be hard to do in the sim... 17.40.09 # btw, what are you thinking about boosting during SD transfers in favor of the CPU voltage scaling? 17.40.58 # most transfers are boosted anyway, such as during buffering or copy/move/delete actions 17.41.06 # if there is a narrow bus between the processor and the peripheral, it probably helps to also keep the peripheral accesses as narrow as possible 17.41.13 # saratoga: according to the opened flyspray patch, he had made a mistake in the last patch 17.42.02 # bertrik: compiler will cast according to the pointer type, but here it's doing useless truncation because strh only read/writes the 16 lsb 17.42.52 Nick advcomp2019_ is now known as advcomp2019 (n=advcomp2@unaffiliated/advcomp2019) 17.44.31 Quit Lear ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]") 17.44.50 # Unhelpful: Well, I'm looking into the first part at least 17.46.35 # no opinions?? 17.47.02 Join mikkas [0] (n=cbdbe3a8@gateway/web/cgi-irc/labb.contactor.se/x-gmoqtdfpgkeyzphg) 17.47.10 # I love you guys. 17.47.32 # hello? 17.47.35 # Hello 17.47.58 # :D 17.51.24 # * kugel slaps funman, saratoga and bertrik 17.52.48 # kugel: without proper SD clocking i don't think we can really think about that? 17.53.06 # why? 17.53.54 # it enables cpu voltage scaling 17.56.39 # I think voltage scaling isn't that important yet 17.56.41 # i thought there was an issue with voltage scaling and the sd card? 17.59.56 Quit mikkas ("CGI:IRC (EOF)") 18.05.30 # saratoga: yea, boosting gets around that 18.05.47 # I don't think it's bad as virtually any transfer is boosted anyway 18.06.00 Join gregzx [0] (n=chatzill@dtc44.neoplus.adsl.tpnet.pl) 18.06.27 Join AndyIL [0] (i=AndyI@212.14.205.32) 18.06.39 # i would prefer to work out the clocking issues and see if boosting is still needed 18.06.50 # the whole issue may just be that we're overclocking the sd cards 18.07.10 Quit AndyI (Read error: 60 (Operation timed out)) 18.08.18 # saratoga, you measured it, right? so we should know now if we're overclocking or not 18.08.25 # we do 18.08.31 Join stoffel [0] (n=quassel@p57B4ED57.dip.t-dialin.net) 18.08.51 # basically the card is clocked with pclk, and attempts to lower the clock make transfers fail 18.09.27 # http://www.bestbuy.com/site/olspage.jsp?skuId=9448537&type=product&id=1218106627473 18.09.39 # wonder if its AS3531 18.10.32 # the whole voltage thing may just be that when run out of spec the cards require higher voltage (or the sd interface requires higher voltage) 18.15.07 # that's what I'm thinking, in that case boosting would almost proper 18.15.25 # saratoga: we could guess by having a firmware file 18.16.28 # funman: so far i haven't found one 18.16.43 *** Saving seen data "./dancer.seen" 18.17.03 # there's no point for them to put a firmware file available for download if they don't have released a newer version of what the clip+ ships with 18.17.34 # since the clip+ features folder browsing, we might see clipv1/v2 updates in a short future, not sure about a clip+ update 18.17.58 Join alexbobp [0] (n=alex@adsl-75-34-100-218.dsl.austtx.sbcglobal.net) 18.18.20 # the firmware sounds very similar feature-wise to the fuze, so its probably a 3531 18.19.24 # which new features did they add except µSD/slotradio ? 18.19.44 # clipv2 has no new features wrt the clipv1, but I suppose AMS just stopped producing as3525 18.20.50 # its got the folder browser 18.21.03 # i don't think the clip had that, though maybe they thought it wasn't useful enough without SD 18.21.22 # botj have that 18.21.34 # I think. the fuzev1 definitely got it with an update 18.21.44 # folder view was added in a firmware update of the fuze 18.22.16 # clipv1/v2 still don't feature it, but i expect it soon since it has been requested a lot of times (on sandisk forums) 18.29.32 # saratoga: I find myself "chasing windmills" through the ams sd code and have just stopped screaming like a senile fool every time I think I've found something..... I think thats an improvement? Quite frustrating. Still trying though. 18.31.14 # maybe the clip doesn't have enough RAM (for sandisks implementation of folder view) 18.31.37 # FlynDice: what do you think the main problem is? I would have tought slightly changing the clock speed would have been straightforward 18.31.48 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 18.31.54 # hrm, the mr500 is on the current build page. does that mean it's supported? 18.32.06 Quit Buschel (Read error: 54 (Connection reset by peer)) 18.32.17 Join Buschel [0] (n=abc@p54A3C2AC.dip.t-dialin.net) 18.32.19 # the question was asked some days ago but i don't remember the outcome 18.32.28 # if yes then it should be added to the front page; if no then I'd like to have e200v2/fuze there too 18.32.43 # saratoga: changing it is straightforward, figuring why we can't use the card after doing that is not :/ 18.40.19 Join domonoky1 [0] (n=Domonoky@e179169248.adsl.alicedsl.de) 18.40.30 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 18.40.45 Quit saratoga ("Page closed") 18.51.39 # JdGordon: have you thought of moving the wps backdrop into the skin buffer? currently it's somewhere else which doesn't really allow for fms backdrops for example 18.51.51 # i have 18.52.05 # * pixelma wonders since when exactly returning from the WPS to the browser when stopping playback (end of playlist, manual stop) takes aaagges on the Ondio :\\ 18.52.36 # bisect it :) 18.52.38 # the problem with that is the size needed for the skin buffer.... 18.53.23 # well, moving the wps backdrop alone is +-0, adding others will be a huge ram usage hit, on color at least :) 18.53.32 # maybe the better way to do it is store the filename for the backdrop in the gui_wps struct and reload it when it needs to be 18.54.02 # disk spinnup when going from wps to fms sounds sucky 18.54.05 Join PaulJam [0] (n=Paule@p54BEF45C.dip.t-dialin.net) 18.54.54 Quit _zic (Read error: 60 (Operation timed out)) 18.56.08 # gevaerts: I think I can manage adding multiple album art sizes, I've had a look 18.56.49 # testing builds on the Ondio is not much fun because disk access is slow so that copying different builds takes a while, here at least the firmware file is enough :/ 18.57.38 # do you have fade on stop/pause enabled? 18.58.02 Quit domonoky (Read error: 110 (Connection timed out)) 18.58.03 # turning it off shows how long it really takes 18.59.53 # it's one thing I always turn off if for some reason I got the default settings again - and playback stops quite quickly, just drawing the browser doesn't. If I go to the browser or menu while music is still playing it's not slow either 19.00.40 # yea, showing the browser is a bit slower than showing the main menu, I noticed that also 19.01.27 # kugel: nice. I can't wait :) 19.01.35 # stopping playback writes resume info onto disk (IIRC) which delays it even more 19.01.54 # but it's slower than it was 19.03.45 # meh, and then there was this problem with testing old builds and having newer flashed... it doesn't work (I get crashes) :( 19.04.03 Join polobricolo [0] (n=paul@AGrenoble-257-1-122-185.w90-27.abo.wanadoo.fr) 19.05.50 # multiple AA sizes (and images) is technically very doable from the skin P.O.V... the trickyness is the loading side of it 19.09.00 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 19.09.06 Join pamaury [0] (n=apouly@slsu0-19.ens-lyon.fr) 19.11.50 # which is what I looked at 19.12.08 # the loading side? 19.12.10 Quit pamaury (Client Quit) 19.15.14 # yes 19.15.36 # loading is not hard actually, the trick is to get the correct handle by aa size 19.19.55 # I'd also like it to look for back.jpg (or similar) 19.27.15 # ah, part of the problem seems to be that I had still turned "cuesheet support" on from my tests after the rework last month - can't tell how slow it was with it turned on before... 19.27.34 # at least turning it off again seems to have sped things up a bit again 19.40.07 Part glass-eye 19.47.19 # n1s: new RTC patch works on h100. It gives a warning though, I've added it to FS again. 19.52.23 Join Ubuntuxer [0] (n=johannes@dslb-094-221-092-123.pools.arcor-ip.net) 19.53.10 Part Ubuntuxer 19.55.03 # funman, can you try setting bit 12 in the DBOP_CTRL register in button_read_dbop? 19.55.10 # I can provide a patch if you want 19.56.06 # (or anyone else with a c200v2 who is ready to test something) 19.56.29 # i did already 19.56.36 # bertrik: http://www.rockbox.org/irc/log-20090830#17:17:18 19.56.36 # and it didn't help? 19.56.39 # * kugel too slow 20.14.59 # bluebrother: great, thanks for testing :) 20.16.11 # n1s: you're welcome :) 20.16.13 # amiconn: you said the lcd controller of h10/etc is documented, where can I find this documents? 20.16.31 # * n1s wants a way to make builds stop on warnings, they are way too easy to miss :/ 20.16.45 *** Saving seen data "./dancer.seen" 20.17.35 # IIRC, gcc has a flag that treats warnings as errors 20.18.05 # -Werror 20.20.59 # easy to miss? on an eeepc? You should've plenty time to look at every single line :) 20.23.17 # pixelma: you sure its the cuesheet setting making it slow? that sounds rather odd.... 20.23.18 # bertrik: but that means manually editing each makefile :( 20.23.55 # I think you can do that once in tools/configure and then do make reconf for each target 20.25.52 Quit BHSPitLappy (Remote closed the connection) 20.28.22 # hmm, maybe 20.28.58 # CFLAGS=$CFLAGS" -Werror" make ? 20.29.09 # maybe with a +, don't know 20.29.13 Quit merbanan (Remote closed the connection) 20.31.15 Quit moos ("Allez l' O.M !!!") 20.31.32 Join rds [0] (n=rogelio@189.180.108.54) 20.33.50 # kugel: tried, it does nothing 20.33.50 Join banan_ [0] (n=banan@c-83-233-172-245.cust.bredband2.com) 20.34.27 # eh noting else than a regular make, warnings just scroll by and the buid continues 20.35.10 # Hi. would it be possible to route sound through a rockbox device to the PC? I mean, connect the rockbox device (ipod in my case) by USB to my PC, play some mp3 _in_ the rockbox device and listen the sound in my PC speakers? 20.35.43 Quit banan_ (Client Quit) 20.35.46 Join merbanan [0] (n=banan@c-83-233-172-245.cust.bredband2.com) 20.37.28 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 20.38.32 Quit PaulJam (Read error: 113 (No route to host)) 20.39.50 Quit jchillerup (Remote closed the connection) 20.40.51 Quit Thundercloud (Remote closed the connection) 20.41.37 # rds: maybe somtime in the future, when we have usb-audio. But at moment its not possible. 20.42.53 Quit amiconn (Nick collision from services.) 20.42.56 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 20.42.56 Quit pixelma (Nick collision from services.) 20.42.57 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 20.43.04 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 20.43.13 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 20.44.00 # domonoky1: It would be great. Is somebody currently working on it? 20.44.48 # rds: i am not sure. feel free to help out :-) 20.45.38 # FS#8663 patch is this still applicable? as so many changes have now been made now to SD handling and I personally have never needed this patch 20.47.10 Part bertrik ("Ik ben weg") 20.47.38 # domonoky1: I will give it a look, thanks for replying 20.54.02 # bluebrother the warning was caused by a sourious ; on line 129, which should mean that read_datetime should give a wday that was 1 too high... 20.54.40 Quit kugel (Read error: 110 (Connection timed out)) 20.54.52 Join kugel [0] (n=kugel@rockbox/developer/kugel) 20.55.37 # s/sourious/spurious/ 20.57.34 Join BdN3504 [0] (n=5ce2251e@gateway/web/cgi-irc/labb.contactor.se/x-biyqhxyqbqqrjsdf) 20.58.42 # this is slightly off topic but: i want to write a bash script that'll cope with the manual building process. i am using the case variable my question concerns case. 20.59.00 # i have options called e200) giabeat) etc. 20.59.42 # how do i put it into case that two strings can be matched? is [e200 gigabeat]) correct? 21.00.13 # kugel: If you're talking about the big h10 - it uses the same controller as the H300, one version of the ipod color etc: Renesas HD66789R 21.01.09 # That datasheet has been in our wiki for ages 21.02.09 Join getchar [0] (n=qwaszx@189.70.86.223) 21.02.20 Quit rds (Client Quit) 21.02.29 Part getchar 21.09.01 # BdN3504: e200|gigabeatf) 21.09.52 Quit kugel (Nick collision from services.) 21.10.00 Join kugel [0] (n=kugel@e178093163.adsl.alicedsl.de) 21.10.33 Quit Topy (Read error: 104 (Connection reset by peer)) 21.10.53 Join Topy [0] (n=Topy44@f049152250.adsl.alicedsl.de) 21.12.23 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 21.13.42 # If anyone who knows how buttons are handled could take a look at my attempts at simulator "remote control" using a named pipe, that'd be grand: FS#10575 21.19.32 # rasher: can you pass the button from the pipe directly into the sims regular button handler? 21.19.47 Quit stoffel (Remote closed the connection) 21.20.17 # JdGordon: No, because the sim's regular button handler expects SDL keys 21.20.20 # not target keys 21.20.29 # otherwise, yes you need to handle button_repeat and button_rel events manually 21.20.44 # do we know for the ams sansas (c200v2 for example) how the the DBOP control pins are connected? 21.20.48 # JdGordon: I don't need to *handle* them, I just need to fake them :) 21.20.50 # (for now, anyway) 21.20.59 # yes 21.21.33 # That is, when I receive "BUTTON_RIGHT" from the pipe, I want it to look to Rockbox like right was "clicked" (press+release) 21.21.34 # its certainly an interesting idea :p 21.21.51 # I could hook it up to my LIRC remote with this! 21.21.57 # ! 21.22.13 # Or other interesting things 21.22.15 # well.. the simplest solution is to post the release event staright after the press 21.22.41 # What does a release event look like? 21.22.49 Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) 21.23.08 # |BUTTON_REL 21.23.16 # Ah, so simple 21.23.23 # that may not work well with scroll buttons though 21.23.41 # as far as I can see for the c200v2, control C0 = always 1, C1 = LCD reset?, C2 = data/instruction select, C3 = write strobe 21.24.03 # * JdGordon waits for an abomination in the sim with the beasts' LCD and the h300 buttons 21.24.24 # JdGordon: It does in fact work. Thanks 21.24.36 # rasher: thanks! 21.24.39 # BUTTON_REPEAT also needs to be "handled" somehow 21.25.32 # Yeah, the cmdpipe reader should accept more complicated events, but right now this will do 21.25.45 # there is a unix command to see if a file handle has input to read yeah? you might want to loop forever and easily handle button_rel if there is nothing to be read, and button_REPEAT if its the same button twice 21.26.25 # button_defines.h should be auto-gened if you take this further... 21.26.59 # JdGordon: Why? It's rarely a new button type gets added 21.27.18 # for completeness's sake.. but yeah maybe not 21.27.26 # A new target that uses the current button define names wouldn't need any adjustment 21.27.39 # Doesn't seem terribly critical 21.28.30 Quit GeekShado_ (Read error: 60 (Operation timed out)) 21.29.49 # rasher: "other interesting things" as in "write a test framework"? ;-) 21.31.53 # * JdGordon runs away screeeming 21.32.45 # * gevaerts thinks that we need people who have experience in testing for that :) 21.33.35 # experience with the GUI? I'm only experienced with Qt GUIs. 21.33.56 # with testing 21.33.59 # though I was thinking about using QTestLib (and how it could be used) for testing rbutil. 21.34.02 # * JdGordon goes about writing a unit testing framework for rockbox in c# 21.34.17 # * bluebrother slaps JdGordon with a # 21.34.56 # you're definitely using the wrong language at work. If you'd go writing it in whitespace, ok, ... 21.35.52 Quit jordan` (Read error: 131 (Connection reset by peer)) 21.39.08 Join jordan` [0] (i=gromit@78.235.252.137) 21.40.12 Quit funman (Remote closed the connection) 21.40.24 Join funman [0] (n=fun@rockbox/developer/funman) 21.43.13 # What's the **pd in sim_plugin_load? I can't make sense of what it's doing 21.47.41 # which file? 21.48.59 # uisimulator/common/io.c 21.50.03 # sim plugin loading is different to target.. 21.50.23 # *pd = NULL; *pd = bla; < looks wrong to me 21.51.05 Join ender [0] (i=krneki@foo.eternallybored.org) 21.51.17 # rasher: probably to keep the handle to give to sim_plugin_close 21.51.18 # funman, how well does the c200v2 display work at all? 21.51.32 # bertrik: fine, but sometimes (often) i have no display at all in the bootloader 21.52.11 # rasher: s/probably// 21.52.17 # funman: ah 21.52.42 Join _lifeless [0] (n=lifeless@94.51.194.186) 21.52.47 # too many *'s for me :p 21.53.57 Quit n1s ("Lämnar") 21.53.58 Quit bmbl ("Bye!") 21.55.13 # rasher: i think part of the problem is going to be that the simulator, as i understand it, is in part an implementation of the rockbox kernel on top of SDL and system I/O, threads, etc. so we can fake key inputs to it, and maybe directly fake actions if we mess with the code for fetching them a bit, but since the plugins are actually run in-process by the UI thread, i'm not sure how we'd force starting one. 21.55.57 # autorock 21.56.07 # Unhelpful: I tried running sim_plugin_load("/blabla", &somewhere); but it didn't seem to load 21.56.13 # JdGordon: that doens't apply 21.56.22 # ? 21.56.58 # autorock starts *on boot* we want to start plugins on demand (from the pipe) 21.57.14 # ah 21.57.24 # rasher: it has to run in the UI thread as i understand it. what i *think* might work would be to have code in the main menu, only compiled for sim, that recognizes a special event. when that event is received instead of one of the usual key-triggered events, read a plugin to load from a shared memory buffer. 21.57.57 # yes, but call plugin_load() instead of doing it manually 21.59.12 Quit BdN3504 ("CGI:IRC (EOF)") 21.59.51 # rasher: why not plugin_load() ? 21.59.51 Quit Sajber^ (orwell.freenode.net irc.freenode.net) 21.59.51 NSplit orwell.freenode.net irc.freenode.net 21.59.51 Quit bah_ (orwell.freenode.net irc.freenode.net) 22.00.03 NHeal orwell.freenode.net irc.freenode.net 22.00.03 NJoin bah_ [0] (n=bah@c-76-105-203-173.hsd1.wa.comcast.net) 22.00.49 NJoin Sajber^ [0] (n=Sajber@c-923571d5.012-155-73746f22.cust.bredbandsbolaget.se) 22.01.55 # funman: if I #include plugin.h, everything blows up 22.02.27 # where? 22.02.29 # what if you just give plugin_load prototype? 22.03.03 # funman: let me try that 22.03.16 # rasher: Unhelpful is right.... you need to load the plugin from the ui thread... so putting handling in the main menu (root_menu.c) is the way to go 22.05.55 # New commit by 03Domonoky (r22562): rbutil: correct usb-id reading on windows. 22.06.58 # domonoky1: what was broken there? Windows does also return a revision number here. 22.07.37 # bluebrother: yes, but somehow it didnt like the Rev of my e200v2, and as it isnt used i removed it. 22.07.56 # how does the registry string look on that player? 22.08.48 Quit ender` (Read error: 110 (Connection timed out)) 22.09.19 # if it doesn't like the revision for your player it would be better to figure why it doesn't like that instead of removing it ... 22.09.27 # "USB\Vid_0781&Pid_7423&Rev_4" dont know why this _stscanf wouldnt pick that up, but it doesnt. now it works :-) 22.09.54 # that's a bad solution. 22.10.11 # why, if we dont need the revision, why extract it ? 22.10.42 Quit Buschel () 22.10.44 # true, but if it breaks then something is fishy so we should figure why it breaks. 22.10.52 # I can't see anything problematic with that code. 22.12.26 # btw, you didn't add a prefix to the qDebug() call. Somewhat nasty given that now users can access the debug output. 22.13.01 # Well, I managed to load matrix.rock 22.13.06 # true, will fix the debug output. 22.13.21 # * bluebrother really hates things getting called "fix" if they don't actually fix an issue but work around one 22.14.17 Quit gregzx ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]") 22.14.30 # New commit by 03Domonoky (r22563): rbutil: correct debug output. 22.14.49 # But that seems to have taken over control 22.15.52 Join mt [0] (n=MTee@rockbox/developer/mt) 22.16.39 # domonoky1: does this also break? And how? http://www.alice-dsl.net/dominik.riebeling/rockbox/usblister.exe 22.16.48 *** Saving seen data "./dancer.seen" 22.18.17 # bluebrother: yes it also doesnt find the e200v2 22.18.27 # interesting. 22.19.14 # what revision numbers does it find for other devices? Numbers less than 10? 22.22.04 # it doesnt list a usb-device with revision < 10 but, there is also no such device connect (without the e200v2) 22.22.39 # well, do other devices like mice etc have a revision number > 9? 22.24.15 # i have no such device, so i dont know. 22.25.13 # ah, the otherway round: other devices have revision numbers listed, all > 0x100 22.25.47 # well, it might be related to that. 22.29.28 Join stoffel [0] (n=quassel@p57B4ED57.dip.t-dialin.net) 22.30.36 Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) 22.33.24 # interesting. A small test program not using unicode works fine. 22.34.30 Quit merbanan (Remote closed the connection) 22.36.40 # but the string read out from the Registry is correct? 22.40.22 # @domonoky1 22.41.44 # yes, i already pasted what rbutil gets from the registry. just this _stscanf seems to have problems. 22.42.07 # this is really weird. Have you checked the return value from _stscanf? 22.42.24 # plus the contents of the variables it writes to 22.43.50 Quit timc (Read error: 110 (Connection timed out)) 22.47.57 # return value is 2. 22.48.14 # hmm. Does the rev value have the correct value? 22.48.51 # no 22.49.13 # interesting. So it didn't match the last number correctly. 22.49.32 # yes 22.50.47 Quit stoffel (Remote closed the connection) 22.53.00 # * bluebrother tried again with another test program, still works. 22.53.51 Join Llorean [0] (n=DarkkOne@rockbox/user/Llorean) 22.53.57 # * bluebrother wonders when this Qt build will finally finish 22.53.59 Quit flydutch ("/* empty */") 23.01.20 Quit niekie (Read error: 104 (Connection reset by peer)) 23.27.14 Quit _lifeless (Read error: 54 (Connection reset by peer)) 23.28.17 Join GeekShado_ [0] (n=Antoine@36.201.192-77.rev.gaoland.net) 23.30.32 # Zagor: I noticed the "pessimistic" points system is slower? 23.30.45 Quit GeekShadow (Read error: 60 (Operation timed out)) 23.31.03 # kugel: I'm testing tweaks on lots of parameters, not just that 23.31.31 # I looked at the client table, and builds where gevaerts had only ~500 have been generally much slower 23.32.20 # well, the last 188 second build is also using pessimistic speed calculation. the speeds vary a lot depending on lots of factors. 23.32.45 # the most recent one? 23.32.51 # yes 23.33.17 # gevaerts has 900 on that one, so I thought it wasn't a pessimistic one 23.34.25 # the pessimitic calculation uses a "33% median" speed value instead of normal average 23.34.47 # so it naturally will change too. especially for gevaerts since his clients run so many builds each round. 23.35.32 # gevearts has a lot of clients ? 23.35.43 # i meant "client" 23.36.01 # funman: it's gevaerts! 23.36.06 # * gevaerts is a successful entrepreneur! 23.36.15 Quit funman ("free(random());") 23.38.18 Join moos [0] (i=mostafa@rockbox/staff/moos) 23.41.49 Join safetydan [0] (n=deverton@rockbox/developer/safetydan) 23.42.54 # yay, 179 seconds. that's just 15 seconds more than the projected time. 23.46.35 # hmm, I need to redo the build allocation. slow clients cannot be allowed to run a single build the whole time. they always get overrun. 23.47.09 # (since fast clients finish faster than estimated, and start the slow clients' builds speculatively) 23.50.41 # rasher: where exactly *is* the main event loop for the UI thread? wherever it's *normally* calling get_action and such is where we probably want to hook it. 23.52.44 # Unhelpful: root_menu() 23.56.41 Join low_light [0] (i=ad58bb86@gateway/web/freenode/x-xyezrwdddvzcatmp) 23.58.58 # kugel: The yh925 OF handles the screen rotation in software. It needs the of reset back to how the bootloader does it. This is the first OF that I've seen not re-init the lcd.