--- Log for 20.12.108 Server: niven.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 11 days and 15 hours ago 00.01.57 Join herrwaldo [0] (n=waldo@ip-81-11-202-191.dsl.scarlet.be) 00.02.18 Quit Nibbler (Read error: 148 (No route to host)) 00.02.28 Join t0mas [0] (n=tomas@rockbox/developer/t0mas) 00.03.08 Join jhulst_ [0] (n=jhulst@unaffiliated/jhulst) 00.04.16 Quit jhulst (Read error: 60 (Operation timed out)) 00.06.08 Quit ender` (" It's bad luck to be superstititious. -- Law of Superstition") 00.07.42 Nick jhulst_ is now known as jhulst (n=jhulst@unaffiliated/jhulst) 00.13.22 Join Nibbler [0] (n=Nibbler@e181121173.adsl.alicedsl.de) 00.13.59 Quit bertrik (Remote closed the connection) 00.17.56 Join tvelocity [0] (n=tony@adsl18-206.her.forthnet.gr) 00.18.01 Quit Nibbler (Client Quit) 00.18.08 Quit jhulst (Remote closed the connection) 00.18.15 Quit t0mas ("Leaving") 00.20.38 Join BigBambi [0] (n=alex@72.198.66-86.rev.gaoland.net) 00.20.58 Quit BigBambi (Remote closed the connection) 00.21.13 Join BigBambi [0] (n=Alex@rockbox/staff/BigBambi) 00.21.21 Quit BigBambi__ ("Leaving") 00.22.49 Quit domonoky (Read error: 54 (Connection reset by peer)) 00.24.48 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 00.24.48 Quit bluebrother ("leaving") 00.25.13 Quit lasser ("ChatZilla 0.9.84 [Iceweasel 3.0.4/2008112309]") 00.26.27 # For the tracks on just one album that I have, %in is displaying "5/17" etc. instead of just a single number. 1) what tag is it pulling that info from, and 2) is there any way I can make it not happen? 00.27.14 # hobbs, change that tag on your file 00.27.26 # like I just asked, what tag? 00.27.29 # the track tag is set to 5. 00.27.32 # (or whatever) 00.27.33 Join |mr [0] (n=lymeca@dsl-74-220-76-75.cruzio.com) 00.28.21 # the id3 tag 00.28.49 Join n1s [0] (n=nils@rockbox/developer/n1s) 00.29.01 # please tell me you're just _pretending_ to be clueless. 00.29.23 # hobbs, what file type? you may have two different tag types on the file (that is, both id3 and ape, or something like that) 00.29.45 # krazykit: MP3; ID3v2 is the only tag I'm aware of. 00.30.58 # but now that I look at it, the tags are responsible, it's just that the "id3v2" util was hiding the info from me 00.31.17 Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) 00.31.35 Quit massiveH (Client Quit) 00.35.18 Quit Aurix_Lexico (Remote closed the connection) 00.36.28 Join Aurix_Lexico [0] (n=comrade@c-68-56-205-239.hsd1.fl.comcast.net) 00.37.22 Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) 00.37.39 # Aurix_Lexico: the PIC code is in the EXT0 block 00.38.12 # I think IDA is able to disassemble it (I tried it several times, but as I didn't understand the PIC architecture nor it's instructions it didn't really make sense to me) 00.38.50 # but it did look like legitimate code 00.40.05 Quit lymeca (Read error: 110 (Connection timed out)) 00.41.05 *** Saving seen data "./dancer.seen" 00.41.45 Quit n1s (Remote closed the connection) 00.42.20 # yeah, I was able to extract it, and disassemble it with IDA 00.42.54 Join lymeca [0] (n=lymeca@dsl-74-220-76-61.cruzio.com) 00.43.23 # I found a some college's course notes on PIC assembly, and have the PIC datasheet 00.43.55 # it still looks pretty confusing though :/ 00.45.57 # yeah I think the PIC datasheet isn't hard to find 00.46.19 # but still, it's way more embedded then the ARM processor 00.46.57 Quit DataGhost (Read error: 104 (Connection reset by peer)) 00.46.59 # ha, with proper watermarks even a 67KB buffer is not too small 00.47.24 # will the scroll thread do its own lcd_update() or is this the responsibility of the main thread? 00.48.03 Quit Hillshum ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") 00.49.02 Join mud-rb [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 00.49.04 # wav is rather busy with such a small buffer though... 00.49.47 # Now go for a 67B buffer :) 00.50.37 Quit jhulst (Read error: 113 (No route to host)) 00.51.00 # gevaerts: :) 00.51.17 # Hmm utf8.def not found building the manual.. 00.51.37 Quit |mr (Read error: 110 (Connection timed out)) 00.52.29 # hmm seems like it does do its own lcd_update()'s.. 00.54.01 # when I have a scrolling line and the main LCD thread only does lcd_update() every sleep(50); I see that the scrolling line also updates about every 50 ticks. is this normal behaviour? 00.55.11 Part toffe82 00.55.56 Quit Zagor ("Leaving") 00.56.09 # hmm never mind, it seems like the lcd driver doesn't support partial lcd drawing 00.56.15 Join admin1lbo [0] (n=admin1lb@pool-72-88-166-100.nwrknj.east.verizon.net) 00.56.21 Nick admin1lbo is now known as QUICKSTART (n=admin1lb@pool-72-88-166-100.nwrknj.east.verizon.net) 01.00.16 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 01.00.32 Join Bensawsome [0] (n=Bensawso@unaffiliated/bensawsome) 01.01.58 # mcuelenaere: thanks, i didn't know we *had* dependencies in FS 01.02.18 # np :) 01.02.19 # also, i have another nail in the vc-dither's coffin. we can make bayer a *lot* cheaper than it is now. 01.03.17 # it's currently a lookup in a 16x16 table. we can replace that with lookups in two 16-byte tables, and an xor, or even one table, if we throw in a shift-by-one and another bitwise logical op. 01.04.42 Join lasser [0] (n=chatzill@W8610.w.pppool.de) 01.04.52 Quit DerDome ("Leaving.") 01.04.57 Quit lymeca (Read error: 110 (Connection timed out)) 01.07.56 # ...actually, i can get rid of the shift. the whole thing can be done with one table lookup and one bitwise and per row, and one table lookup and one bitwise xor per pixel 01.08.01 Join lymeca [0] (n=lymeca@dsl-74-220-76-75.cruzio.com) 01.15.42 Quit jhMikeS (Nick collision from services.) 01.15.48 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 01.17.57 # Looks like utf8.def has been renamed utf8x.def in the new Latex package. 01.19.47 # it snowboards with umlauts 01.25.05 Quit lymeca (Connection timed out) 01.27.40 Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") 01.28.07 Join hd [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) 01.28.37 Quit HellDragon (Read error: 104 (Connection reset by peer)) 01.28.37 Quit hd (Read error: 104 (Connection reset by peer)) 01.28.45 Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) 01.38.58 # it works, with one bitwise and, one 1D array lookup and one bitwise xor in the inside loop. should that be of comparable speed to two bitwise and + a 2D array lookup? 01.40.18 # binsize diff is -216B on arm 01.45.09 Quit HellDragon (Connection reset by peer) 01.46.33 Quit wpyh (Read error: 110 (Connection timed out)) 01.47.42 # that's on ipod4g... m5/x5 will probably improve slightly less as they have one more place that looks up dither values 01.48.56 Join midkay [0] (n=midkay@rockbox/developer/midkay) 01.49.22 # Unhelpful: I didn't read up everything yet, but regarding to your last question I think it should be even faster 01.49.36 # 1D array lookup requires less address calculation 01.50.30 # it also saves ~200B, give or take a bit depending on arch whether or not there's a remote 01.52.13 Quit _Auron_ (Read error: 104 (Connection reset by peer)) 01.52.18 # i was thinking of committing my current batch of scaler improvements, if there are no objections. should be binsize and speed improvements everywhere but greyscale, but those get a HQ scaler to replace the nearest-neighbor one, so it's not too bad a deal, i'd say 01.52.19 Join _Auron_ [0] (n=DarkAuro@ppp-70-244-161-118.dsl.rcsntx.swbell.net) 01.53.44 Quit lasser (Remote closed the connection) 01.57.08 Join wpyh [0] (n=william@125.163.88.253) 02.01.56 Quit Schmogel (Read error: 104 (Connection reset by peer)) 02.04.09 Quit QUICKSTART (Remote closed the connection) 02.06.52 Join lymeca [0] (n=lymeca@dsl-74-220-76-61.cruzio.com) 02.10.03 Quit aneqrs () 02.17.09 Join Makuseru [0] (n=max@163.106.40.24.aeneasdsl.com) 02.24.12 Join grndslm [0] (n=grndslm@24-116-87-97.cpe.cableone.net) 02.25.32 Quit grndslm (SendQ exceeded) 02.26.27 Join grndslm [0] (n=grndslm@24-116-87-97.cpe.cableone.net) 02.32.48 Join RockRabbit [0] (n=3aac9a01@gateway/web/cgi-irc/labb.contactor.se/x-4a91097042010cb5) 02.32.50 Quit lymeca (Read error: 110 (Connection timed out)) 02.33.18 # Can anyone tell me what DBOP stands for and what it means? 02.34.03 # it's like DCOP only it's got that swing? 02.34.28 # As in DBOP-A-LULA? 02.35.07 # and a wham-bam-boom. 02.35.58 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 02.36.30 # Actually I first thought it was a song by Cyndi Lauper. 02.36.40 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 02.37.04 # please try to stay on topic 02.39.12 # please try to recognize the topic. 02.39.56 # Still no takers on DBOP? 02.40.19 # Its not in the rockbox glossary but its used often in conversations. 02.40.47 # according to the logs, it stands for "DBOP stands for "Data Block *Output* Port"" 02.41.03 # RockRabbit: it's the name of a bit of the AS3525 that does some I/O. No clue what it stands for though :) 02.41.06 # [15:30:22] -bertrik: DBOP is a highspeed output port designed for driving LCDs 02.41.09 *** Saving seen data "./dancer.seen" 02.41.25 Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) 02.41.37 # Looks like I need the as3525 datasheet more than ever. 02.42.05 Quit Makuseru (Read error: 104 (Connection reset by peer)) 02.42.19 # RockRabbit, http://www.rockbox.org/irc/rockbox-20081128.txt - at around 17:55, there's some discussion about it that may help 02.42.35 # thanks 02.44.56 # ANyone know how I can get hold of an as3525 datasheet? 02.45.34 # RockRabbit, talk to Bagder 02.50.04 Quit HellDragon (Client Quit) 02.53.36 # note that Bagder is in Europe and it's almost 3 AM here 02.55.59 Part grndslm ("Leaving") 02.56.52 Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-53799ce3f402ff5b) 02.58.07 Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) 03.00.29 Quit mcuelenaere () 03.13.43 Join kugel [0] (n=chatzill@unaffiliated/kugel) 03.14.10 # RockRabbit: hi 03.14.34 Join lymeca [0] (n=lymeca@dsl-74-220-76-75.cruzio.com) 03.14.50 Join Lss [0] (n=Lss@cm203.delta90.maxonline.com.sg) 03.17.53 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 03.19.39 # RockRabbit: I wonder if you have noticed http://www.rockbox.org/tracker/task/9679 03.27.33 Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.4/2008111318]") 03.27.47 Quit jhulst (Remote closed the connection) 03.27.56 Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) 03.28.35 Quit massiveH (Client Quit) 03.32.21 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 03.35.06 Quit faemir (Remote closed the connection) 03.36.05 Quit herrwaldo ("Konversation terminated!") 03.38.43 Quit lymeca (Read error: 110 (Connection timed out)) 03.47.39 Join lee321987 [0] (n=chatzill@node103.32.251.72.1dial.com) 03.49.23 # anyone here who's done work in the Sansa c200's USB "bytes inserted" bug? 03.50.15 # lee321987: probably the wrong time of night for any of those people 03.50.59 # hi kugel - yes i got your forum post - sorry i have been afk for a while 03.51.11 # Well maybe some one else can answer this question ---- I was just wondering if there is some information that some company won't give us that might make it easy to fix the bug...? 03.51.46 # lee321987: maybe. its thought to be a bug in the PP hardware, so maybe they know how to correct it 03.51.57 # lee321987, not so much "won't give" as "can't legally give" in many cases, as the licensing agreements forbid them from doing so 03.52.34 # lee321987: wait are you talking about the USB or SD bugs? 03.52.50 # is the PP still being used in _new_ hardware? 03.53.25 # saratoga: i've been looking at wma recently, trying to fix some of the tracker issues 03.53.37 # midgey: yes thank you 03.53.41 # i've already commited your fixes 03.53.44 # the bug that inserts 2 bytes (randomly -- I think) during USB data transfers through RB. 03.53.53 # i was very much hoping to get those fixed for 3.1 03.54.14 # lee321987: thats not a USB bug, see FS#8663 03.54.23 # krazykit - i sent a pm to bagder - but got no reply so far 03.54.26 Quit jhulst (Read error: 60 (Operation timed out)) 03.54.46 # sorry for the wrong terms. 03.54.51 # i had some other changes i was wondering about 03.55.05 # RockRabbit: as noted before, he's in europe, and is probably asleep at this hour. 03.55.08 # RockRabbit, well, seeing as he's probably asleep, you'll have to wait til (european) morning 03.55.49 # i sent him a private message two days ago 03.55.58 # what do you call it? An SD bug? 03.56.06 # midgey: what did you have in mind? 03.57.08 # Why is M_PI_F defined as 0x3243f? Isn't 0x3243d more accurate 03.57.15 # same with TWO_M_PI_F 03.57.39 # Does the SD driver not get used if you have no SD card in the player? 03.58.06 # the device has a built in SD card, so theres always one in the player 03.58.26 # ahhhhh 03.59.07 # how can i tell how much ram memory each rockbox supported player has? 04.00.24 # midgey: I don't believe so 04.00.29 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 04.00.45 # ah, nope. i divided wrong 04.00.49 # damn you fixed point 04.00.52 # saratoga: why didn't you commit your fixes to the 3.1 branch? 04.01.22 # also exponents[-1] doesn't really make sense (very high freq MDCT calc) 04.01.40 # rasher: I did 04.01.45 # i suppose I should just pastbin my diff, one sec 04.02.04 # you'd think that companies would be more forthcoming with RB devs. (Are they worried that other companies will steal their technology?) I _know_ my next DAP will be one that RB works on. 04.02.20 # saratoga: Ah. Didn't see the latest commit 04.03.20 # lee321987: companies that make DAPs often license much of the compenents, and library code for them, from other companies, which don't really care about how any one device based on their IP sells, and which license said IP under NDA. 04.05.06 # your name doesn't fit you. 04.06.29 # RockRabbit: DeviceChart 04.07.48 # saratoga: http://www.pastebin.ca/1289984 04.08.02 # includes some changes you've already committed 04.08.40 # scorche: thanks - just what i wanted 04.09.03 # midgey: looking through it now 04.09.08 # also includes some random debugf and spelling corrections :) 04.09.11 # does it fix any known problem samples? 04.09.31 Quit lee321987 ("ChatZilla 0.9.84 [Firefox 3.0.4/2008102920]") 04.11.25 # not really that i know of. some of the problem samples sound a bit better (glitches seem less noticeable) 04.11.39 # could be the placebo effect. i'd like to think i'm fixing things 04.12.10 # i'll revert to svn and check 04.12.11 # midgey: some of that looks a bit odd 04.12.30 # i recommend dumping the output to PCM and comparing it quantitatively using matlab or whatever 04.12.53 # i've long since learned to never trust my ears :) 04.13.03 # i'll do that 04.13.17 # im relatively certian while(len > 0) is wrong 04.13.56 # yes I think ffmpeg changed that recently 04.14.14 # i looked at it briefly but couldn't find any samples where it made a difference so i sat on the fix 04.14.25 # otherwise the next block of code is useless 04.14.28 # though maybe it should be fixed even if we can't test it 04.17.01 # seems to make sense logically 04.17.05 # the block below @@ -1253,11 +1254,11 @@ seems to do the same thing but less accurately I think? 04.18.02 # well e2 is a fixed32 and n is an int 04.18.37 # if you just divide fixed32/int will you get a fixed32 back? 04.19.07 # midgey: yes 04.19.28 # well then, scratch that, i thought you'd get an int casted to a fixed32 04.19.29 # an int is just a fixed variable with a PRECISION of 0 04.21.32 # can you cast a fixed32 to a fixed64? 04.22.19 Quit Nico_P (Remote closed the connection) 04.22.46 # midgey: i think you'll get the wrong half of it, if you do that... you want to >>32 it, i would expect, and possibly add shift if they fixed32/fixed64 you're using have different precision 04.23.06 # the, not they. 04.23.41 # the wma codec casts here and there and i didn't know if that caused any endian issues 04.23.53 # midgey: @@ -1307,21 +1307,23 @@ reverts some of r14134 04.24.18 # in general anytime you see shifts by anything other then 16 its because they absolutely have to be that value to avoid overflowing 04.25.01 # in these cases one can only rearrnage the algebra with great caution 04.25.13 # ah 04.25.20 # see this is helpful :) 04.26.02 # basically i wrote this by using 16 everywhere and then incrementing shifts until problem samples decoded right 04.26.15 # very scientific 04.26.20 # saratoga: does rockbox code as it stands generally assume a truly fixed precision? i've seen and written code before where the precision "floats" as appropriate at each stage 04.27.07 # Unhelpful: variables have to be rescaled from time to time 04.27.25 # fixed just means that the programmer is in charge of normalization, not the hardware 04.27.53 Join blkhawk- [0] (n=blkhawk@g226129030.adsl.alicedsl.de) 04.28.51 # in reality the codec is just doing cosine transforms, and those transforms have no native scale, so the definition of the number one is arbitrary anyway 04.28.59 # we reassign it as needed 04.29.43 Quit RockRabbit ("CGI:IRC (EOF)") 04.31.14 # i've found another problematic sample if you're interested 04.31.24 # http://wymette.home.att.net/files/wmatest.htm 04.31.44 # just sounds like a high pitched whine in rockbox 04.32.24 # shouldn't be hard, i'd suppose, to kludge up a plugin that loads a greyscale pixmap, and displays it with greylib? 04.32.49 # by the sound of it, most of my changes aren't correct and can probably be ignored 04.33.08 Quit linuxstb (Read error: 110 (Connection timed out)) 04.33.23 # midgey: yes that certainly fails quite badly 04.33.38 # i was quite surprised when i first listened 04.34.06 Join RockRabbit [0] (n=3aac9a01@gateway/web/cgi-irc/labb.contactor.se/x-60517774b98d073c) 04.34.38 # it reports an ASF parser error so that may have something to do with it 04.34.44 # though those seem quite common 04.34.53 # even on samples that decode more or less correctly 04.35.07 # i also have another track that gets a -5 return on wma_decode_block 04.35.21 # so the one on the tracker is not alone 04.35.34 # this track decodes correctly however 04.36.17 # if i detect a button press via an input pin on a GPIO port (in this case Sansa with AMS as3525 soc), how do I clear or reset the pin to detect the next button press? At present the button is continually being detected after being pressed only once. 04.37.16 # midgey: I've seen -5 errors before 04.37.31 # often they don't decode in ffmpeg either, so testing them there is a good first step 04.37.51 # i'll have to tell the track it's not as special as i thought 04.38.07 # the ffmpeg decoder is evidently still incomplete 04.38.30 # are they actively working on it? 04.38.51 # I don't believe so 04.39.07 # well damn 04.39.39 # are there other types of WMA that we don't handle other than lossless? 04.39.45 # yes, PRo and Voice 04.39.52 # we simply reject those 04.40.17 # is pro the same as wma v10? 04.40.45 # * midgey wanders off the wikipedia 04.41.07 # apparently to learn english as well.... 04.41.13 *** Saving seen data "./dancer.seen" 04.42.46 # i think the naming is inconsistent, I've heard v10 refer to both v2 files produced by the WMP10 encoder, and to other formats as well 04.43.25 # yep, seems that way 04.43.29 # WMAV2 is well standardized, but the Pro format seems more fluid with various versions and occasional research papers 04.43.32 # also, multichannel, lossless, and i think voice were introduced as part of the same "version", but are all essentially different codecs 04.43.44 Quit blkhawk (Connection timed out) 04.43.51 Nick blkhawk- is now known as blkhawk (n=blkhawk@g226129030.adsl.alicedsl.de) 04.44.02 # we just skip everything not tagged as V1 or V2 in the header 04.44.57 # the other variants seem like completely different beasts 04.46.45 Join lymeca [0] (n=lymeca@dsl-74-220-76-75.cruzio.com) 04.47.01 # midgey: that file you linked plays better in ffmpeg, but i wouldn't say it plays well :) 04.47.47 # yeah, i just tried it on vlc. it seems to jump and stutter 04.49.01 # is there a doc somewhere that explains the drawing modes? can't seem to find it (ex. DRMODE_SOLID vs DRMODE_FG, etc.) 04.49.13 # midgey: why the sudden interest in wma? 04.51.12 # to be honest, i was just looking to fix some bugs before 3.1 04.51.23 # and wma happened to be the most recent one 04.51.27 # ah ok 04.51.41 # and i'm working at microsoft next summer so that might have contributed 04.52.22 # well i've got a long list of codec chores if you're bored 04.52.44 # for wma specifically or all across the board? 04.52.55 # all across the board 04.52.57 # take your pick 04.53.23 # though I think you could commit that fix from ffmpeg that i couldn't find a problem sample for 04.53.44 # always have to worry about the commit count ;) 04.54.20 # did anything else in the pastebin look promising? 04.56.54 # the exponents[-1] thing is certainly wrong 04.57.04 # though i'm puzzeled how it doesn't seem to matter 04.57.15 # i'd expect it to cause more problems by now 04.57.50 # just getting lucky 04.57.50 # sorry I mean the SVN code is wrong, not your fix 04.57.57 # right 04.58.30 Quit miepchen^schla (Read error: 110 (Connection timed out)) 04.59.09 # i'm not sure the fix is right, that's what ffmpeg has at least 04.59.39 # i'm not even sure what it does 05.00.23 # i guess esize is bigger then bsize and it ends up being a small number? 05.00.50 # that's all i can come up with 05.03.17 # hmm no its often zero 05.03.33 # do you think the casts in wmadeci are fine or should they be changed? 05.04.25 Quit lymeca (Connection timed out) 05.06.24 # actually, i have no idea how it works 05.06.36 # -1 will be 0xFFFF etc correct? 05.06.50 # then shifted left with have low bits of 0 05.07.06 # if esize>size, you'll get -1 back? 05.07.13 Quit HellDragon (Client Quit) 05.07.38 Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) 05.08.45 # midgey: at least in the file i looked at the two were always equal, meaning its always -1 05.08.57 # regarding the casts, I don't think they change anything 05.09.12 # i'm surprised that works 05.09.20 # the one macro is just a cast, and the other macro zeros and then casts 05.09.47 # the macros were put in there by marsdaddy in his first codec, but i didn't use them much 05.11.30 # which macros? 05.11.51 # Fixed32From64, etc 05.11.57 # though iguess some are really functions 05.12.05 # ah, yes sorry 05.12.28 # aren't you still indexing an array with a negative index? 05.12.37 # yeah, but we do that a lot :) 05.12.57 # * midgey 's mind is blown 05.13.51 # you probably shouldn't look at wmadata.h then 05.14.01 # midgey: an array is a pointer. a[-1] is the same as *(a-1) 05.14.21 # i knew thta, i thought exponents was const 05.14.25 # hmm though i'm not sure if its correct here 05.15.35 # have you looked at how ffmpeg handles the exponents array 05.17.58 Quit jhulst (Remote closed the connection) 05.18.28 # unless i'm missing something i think they also allow negative 1 05.18.28 Quit RockRabbit ("CGI:IRC (EOF)") 05.19.20 # they do, they increment the array throughout wma_decode_block 05.19.25 # increment the pointer 05.23.29 # midgey: printing pointers makes me think we're probably grabbing exponents_bsize[1] as exponents[0][-1] 05.23.40 # i'll see about compiling ffmpeg to see what they're actually using 05.23.51 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 05.26.44 Join lymeca [0] (n=lymeca@dsl-74-220-76-56.cruzio.com) 05.26.55 Quit lymeca (Remote closed the connection) 05.27.06 Join lymeca [0] (n=lymeca@dsl-74-220-76-56.cruzio.com) 05.28.05 Quit Lss (Read error: 110 (Connection timed out)) 05.30.34 Quit MarcGuay ("ChatZilla 0.9.84 [Firefox 3.0.4/2008102920]") 05.40.04 # i think i'm losing my mind 05.40.09 # but ffmpeg looks broken too 05.40.45 # ffmpeg is always fun to look through... 05.42.49 # no wait we're just really wrong here 05.44.47 Quit jhulst (Read error: 60 (Operation timed out)) 05.45.11 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 05.45.38 # it seems i never properly implemented ffmpeg r8627 which fixed this issue 05.45.54 # which is why the esize/bsize logic makes no sense in rockbox 05.48.08 # that's what i was refering to with how they handle exponents 05.48.49 # it looks like i half implemented it 05.48.53 # but left out some lines 05.48.57 # amazing that it worked at all 05.49.26 # i was syncing up their changes from about 8143 yesterday and i saw they handled it a bit differently 05.50.08 # unfortunately i kept segfaulting in bitstream.h and i gave up for the time being 05.50.57 # the get_bit1 change in r9999 made sense as well 05.51.18 # r10004 seems correct as well 06.00.48 Quit jhulst (Read error: 60 (Operation timed out)) 06.01.14 Join pixelma_ [0] (n=pixelma@rockbox/staff/pixelma) 06.01.20 Quit lymeca (Read error: 113 (No route to host)) 06.01.47 # urgh... messy declaration issues :/ 06.01.57 Quit amiconn (Nick collision from services.) 06.01.59 Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) 06.02.32 Quit pixelma (Read error: 110 (Connection timed out)) 06.03.10 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 06.03.14 # resize.h has declarations that need things from bmp.h, and vice versa... and i'm a bit stuck figuring out where to declare the needed structs and functions to make it happy :/ 06.06.21 # there we go, a forward declaration for struct rowset and all is well 06.08.15 # midgey: alright properly synced it 06.08.27 # not noticing any changes with my files but i don't know which ones to test 06.08.57 # i've been stealing test files from random sites around the internet 06.09.05 # most seem to work in rockbox though 06.11.44 # saratoga: http://samples.mplayerhq.hu/A-codecs/WMA/wma-broken.asf is broken in rockbox as well 06.12.10 # vlc 0.9.8a handles it better than us, but not well 06.12.43 # i dont have the ffmpeg source on my computer so i've been testing in vlc 06.14.40 Join psycho_maniac [0] (i=psycho_m@ppp461.hk.centurytel.net) 06.15.12 # that asf doesn't even play in foobar 06.15.29 # flip4mac does fine 06.21.03 Quit jhulst (Read error: 131 (Connection reset by peer)) 06.25.47 Quit Aurix_Lexico (Remote closed the connection) 06.26.24 # i'm going to commit these changes to SVN, and if no one complains I may add them to 3.1 06.27.44 # i think unless they fix a noticeable bug, the changes don't need to go into 3.1 06.28.00 # i mean the code in svn is clearly wrong 06.28.07 # so maybe it does make sense 06.28.43 # i think the bug only affects a few frequency bands, so its probably not too noticable 06.29.16 # midgey: you mentioned some other ffmpeg svn numbers, are there other things you think we didn't sync right? 06.30.35 # well the get_bits1 change won't cause any functional differences 06.30.53 # are there more of those i didn't sync? 06.31.13 # r10004 might have slightly different behavior get_bits -> skip_bits 06.31.55 # r14171 and r15004 have changes we don't have 06.32.11 # supposedly fixes some WMV audio stutter 06.32.18 # have found a test case to confirm 06.32.22 # haven't* 06.32.35 # i put a lot of time into the get_bits1 thing 06.32.40 # i thought it was all commited 06.32.52 # i remember it not seeming to change anything 06.33.51 # i think in the long term i have to figure out how huffman coding is really implemented in our codecs and try to improve it 06.34.04 # i'm sure its much slower then it should be 06.35.15 # i highly doubt the get_bits1 change would make any difference, see r9999 06.36.50 Quit HellDragon (Read error: 104 (Connection reset by peer)) 06.37.05 # i'd be amazed if googling "optimized huffman decoder" did not find an OSS project with a compatible license from which you could borrow one, saratoga 06.37.20 Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) 06.38.40 # Unhelpful: I'm sure thats true 06.38.53 # but merging them is non-trivial without a good understanding of what they do 06.39.54 Quit HellDragon (Read error: 54 (Connection reset by peer)) 06.40.07 Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) 06.40.44 # i have been trying to merge in some Vorbis bitstream optimizations I found in one of the tremor brances with little success, and thats the same decoder but different brances 06.41.14 *** Saving seen data "./dancer.seen" 06.47.58 Join [1]psycho_maniac [0] (i=psycho_m@96.14.220.33) 06.49.48 # so, is it preferable to do some really ugly hacks to get things to work on more targets, or to be cleaner and more bug free but work on fewer targets? 06.49.59 # (for a plugin) 06.51.24 # there are plugins that go either way 06.51.53 # for example, no pictureflow on greyscale targets, but jpeg viewer even on mono targets 06.52.30 # my main concern is RAM...on the high ram targets everything will be easy, but i'm going to need some kind of insane caching scheme if i go to the 2 MB targets... 06.53.23 # what's the plugin do? 06.53.48 # * ameyer wonders if there are any 2MB targets with non-tiny screens 06.55.16 # ameyer: viewer for game records for go/weiqi/baduk. i'm rewriting it. basically i have to keep a tree structure in memory to traverse, and if i do it on the 2 MB targets, there's not enough RAM to keep the whole thing in even if i steal the audio buffer 06.55.28 Quit [1]psycho_maniac (Remote closed the connection) 06.55.51 # i thought up an algorithm to do it even on little memory, but it's going to be ugly and error prone 06.55.58 Quit psycho_maniac (Read error: 113 (No route to host)) 06.57.34 # yay, pluggable scaler output is "working", in that i have the framework for it in place, and regular bitmap loading without an output plugin works 06.57.53 # time to code a test case :/ 06.59.56 # oh well, the 2 MB targets all look like the screen is too small for much anyway. i'll just make it work for them but make it die if you try to load a file that's too large... 07.01.32 # saratoga: i was going to say that if we had one nice huffman decoder in core, corejpeg and codecs could all use it, but that's probably not feasible unless other codecs use the same methods for inserting markers in the huffman bitstream :/ 07.02.15 Join Minthe [0] (n=Minthe@gw13.ecc.u-tokyo.ac.jp) 07.06.44 # Unhelpful: i have no idea how huffman coding is actually implemented, is it generalizable between different codecs? 07.09.25 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 07.10.25 Join ball [0] (n=ball@adsl-99-152-241-9.dsl.emhril.sbcglobal.net) 07.12.21 # I'm listening to music on my iPod Mini, courtesy of RockBox 07.12.27 # ...so thanks for that. 07.19.34 # saratoga: it might be my ears, but i think the first wma in FS #7488 sounds better now 07.20.51 # baroque loop sounds good as well, but there's still a slight glitch in the middle of the song 07.23.54 # midgey: i diffed the two and theres 6 spots in the first file that are improved 07.23.58 # so i guess it does help 07.25.01 # i have some songs acting funny on track changes (slight audio glitch) so there still might be some things that aren't reset between tracks 07.26.10 # midgey: if you can reproduce them its usually not too hard to figure out what causes them 07.26.28 # i'll look into on the plane tomorrow 07.26.41 # saratoga: there's really only one "way", as far as i know, and all that differs is tables and how codecs store them if they don't use a fixed table... as far as huffman coding itself goes. :/ 07.26.44 # i started by zeroing the entire struct like you did, then did a binary search zeroing half as much each time 07.27.12 # Unhelpful: so it might be feasible to write an optimized one in assembly and have different codecs use it? 07.27.14 # wma_broken is handled a bit better now as well 07.27.28 # however, jpeg can insert marker codes into the huffman stream, and you have to catch that... and i'm sure there will be other codecs that do similar, but use different methods 07.27.47 # it goes negative time remaining from time to time... 07.27.57 # maybe, if the buffer is preprocessed by a codec function that removes and handles anything that's not huffman code data? 07.28.24 # why does jpeg do that? 07.28.58 Part ball ("bye!") 07.30.51 # error resilience, i believe. the codes can mark that you're in a new macroblock, etc, and the decoder can bail on the current one, and go about getting things back into a known state 07.31.31 # in any case, in jpeg the magic is a byte-aligned FF followed by a non-zero byte. an actual byte-aligned FF in the huffman codestream is just followed by a 00 07.31.40 # codeclib stuff isn't available to the core anyway, so even if we had seperate ones for jpeg and codecs that wouldn't be a huge deal 07.31.51 Quit XavierGr () 07.31.53 # so a preprocesser could easily strip out that 0, and move everything over one 07.32.42 # Unhelpful: are you interested in jpeg? 07.33.10 # right, but if we have one nice generic decoder, assuming that such a thing can be done, it could live in core and be used by jpeg and codecs 07.33.39 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 07.34.05 # it's something i'd like to see working. i'm not entirely sure i can tackle making an acceptable core jpeg decoder. i looked at the jpeg_decoder.o file from the plugin, and that's 13KB... i doubt that would get in. 07.40.47 # hrm, so if i want to just display an image until i get a button press, in a plugin, it looks from ppmviewer.c like i can just do rb->button_get(true), then return? 07.45.35 # Unhelpful: theres certainly targets were 13KB would be tolerable, and I'm sure it can be made smaller 07.48.33 # i'd actually expect it to end up going the other direction, if it's to interface with the scaler as it is now. :/ 07.50.17 # the *easiest* way to go would be to buffer the entire image in RGB, then feed it to the scaler exactly as BMP does. that would make it *much* heavier than BMP, which feeds the scaler in small pieces 07.51.35 # Unhelpful: jpeg blocks are stored in order right? 07.52.26 # saratoga: yes, but i believe it's the whole Y plane, then the whole U plane, then the whole V plane. so, we could track a seek offset that we read from in each plane, in that case, and decode 1-2 MB rows at a time 07.52.39 # but, again, that's getting toward larger, not smaller code 07.53.52 # hrm, a "for greylib" output plugin for the scaler should probably live in grey_draw.c? 07.56.59 # Unhelpful: doing one plane at a time is probably better, since you could resize each one and then accumulate the resized images 07.57.06 Quit jhulst (Remote closed the connection) 07.58.04 # yes, and no. the color-target scaler takes RGB pixels, the grey-target one takes greyscale pixels. 07.58.48 # Unhelpful: do 3 grayscale resizes then? 07.59.24 # ...there is no greyscale resizer on targets with a color screen. they're the same functions, with some #ifdefs that change key parts. 08.00.07 # yes i know, but its probably cheaper to have both resizers then to buffer the decoded image 08.01.57 # no, no, i definitely don't want to buffer the whole image... but i think that finding a way to decode chunks in finished RGB will cost less code than building greyscale scalers on color targets would. they smooth scalers cost ~1.5KB on greyscale targets 08.02.03 # s/they/the/ 08.03.17 # i wonder if theres any other projects or libraries we could look at to see what they do 08.03.50 # hard to say, if they're designed for a PC, i doubt they'll have the same design constraints as us :/ 08.06.37 Quit saratoga ("CGI:IRC (EOF)") 08.09.57 Quit bertrik (Remote closed the connection) 08.11.16 Join Rob2223 [0] (n=Miranda@p4FDCEE5B.dip.t-dialin.net) 08.12.07 Join lucent [0] (n=eshattow@75-174-180-52.chyn.qwest.net) 08.15.47 # Is there any hope to get png viewer? 08.16.08 # decoder code needs to be written 08.16.25 # I don't know of any technical reason it can't be done by a motivated coder 08.17.04 # it just hasn't been done yet AFAIK 08.17.16 # Is there any memory issues? 08.17.17 Quit mud-rb (Read error: 54 (Connection reset by peer)) 08.17.43 # png relies on zlib, I think 08.17.53 # I'm not much of a coder myself so I don't know the details 08.19.46 # Minthe: memory issues are very much something that can be dealt with. on targets where you get enough of it, you can use the plugin buffer. on others, you'll have to borrow it from the audio buffer. 08.28.40 Quit Rob2222 (Read error: 110 (Connection timed out)) 08.36.06 Quit midgey () 08.39.15 Join midgey [0] (n=tjross@c-71-205-31-207.hsd1.mi.comcast.net) 08.41.18 *** Saving seen data "./dancer.seen" 08.57.25 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 09.01.07 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 09.04.01 # midgey: Are all those wma fixes going into the 3.1 branch as well? 09.05.44 # r19503 doesn't really have any fixes 09.06.10 # saratoga already committed up to r19498 09.06.27 # r19000 and r19502 can probably go in 09.06.41 Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) 09.08.41 # amiconn: would you be able to give me a hand with a test plugin for 8-bit greyscale bitmaps loads? as far as i know, the loading works, but i seem to be stuck a little bit with greylib itself... 09.12.15 # * midgey sleeps 09.12.18 Quit midgey () 09.12.59 # ls 09.13.02 # * lucent fails 09.21.30 # nevermind... got it :D 09.21.45 Join Nibbler [0] (n=Nibbler@e181121173.adsl.alicedsl.de) 09.24.02 # Unhelpful: What was the problem? Perhaps the greylib and/or its documentation can be improved a bit? 09.24.45 # amiconn: trouble was my not understanding the buffered/unbuffered modes, and the business of different draw functions for each... unless i misunderstand how i fixed it. 09.27.16 # ah 09.27.48 Quit BHSPitLappy (Remote closed the connection) 09.28.32 # The 2 modes might need a bit more documentation. Basically unbuffered mode exists in order to save some ram if you only need bitmap drawing 09.28.38 # in any case, i added a scaler output plugin for greylib, and a test viewer plugin that loads and displays a bitmap scaled+centered 09.29.46 # i'll pop it onto FS in a minute, and try to ping some people with grayscale hardware, i suppose... but it does pretty much everything we'd talked about, i think :D 09.29.57 # It's also a bit faster since it avoid the extra copy 09.30.09 # *avoids 09.31.38 # amiconn: maybe we should have the buffered functions call the unbuffered ones if the buffer is NULL? 09.32.55 # That'd mean more of the code is linked to the plugin 09.36.10 # hrm, good point. probably no better way to do it than what we've got now, then. 09.36.47 # Imo there's no need, since a plugin will either use buffered mode or unbuffered mode, never both. What could be done though in order to help debugging is checking for NULL and printing a helpful DEBUGF() message if it is. Only in the sim of course 09.37.33 # hrm, yes, that would be good. do we have a doc for greylib, besides the sources? 09.39.47 # Source only atm; there are longish comments for most public functions. GraphicsAPI wiki page also applies, of course 09.41.19 Quit jhulst (Remote closed the connection) 09.42.28 # hrm, do i have to create a task before i can add dependencies on other tasks? 09.42.52 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 09.46.51 Quit jhulst (Read error: 60 (Operation timed out)) 09.50.25 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 09.56.42 # up as FS#9683, if somebody with greyscale targets wants to test it 10.04.20 Join n1s [0] (n=nils@rockbox/developer/n1s) 10.22.48 # jhMikeS: about to test the beast charging patch, anything in particular to look for? 10.24.25 Quit jhulst (Read error: 131 (Connection reset by peer)) 10.25.14 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 10.36.34 Join planetbeing [0] (n=planetbe@c-71-235-96-172.hsd1.ct.comcast.net) 10.41.20 *** Saving seen data "./dancer.seen" 10.44.00 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 10.45.58 Join fredddy [0] (n=freddy@p3E9E3319.dip0.t-ipconnect.de) 10.47.01 Join EspeonEefi [0] (i=eefi@SAFFRONCITY.MIT.EDU) 10.47.34 Quit bmbl (Client Quit) 10.51.30 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 10.58.36 Quit maddler ("Lost terminal") 11.01.28 Join _lifeless [0] (n=lifeless@90.151.222.100) 11.03.40 Quit Minthe ("Leaving...") 11.07.01 Join Acksaw [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com) 11.11.20 # n1s: I put instructions in the FS task . :) 11.15.16 # ok, already started charging with AC 11.18.11 Quit __lifeless (Read error: 110 (Connection timed out)) 11.23.34 Join {phoenix} [0] (n=dirk@p54B45D4C.dip.t-dialin.net) 11.33.30 Join miepchen^schlaf [0] (n=miepel@p579EC669.dip.t-dialin.net) 11.34.20 Join PaulJam [0] (n=pauljam@p54BED510.dip.t-dialin.net) 11.34.25 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 11.39.30 Join gregzx [0] (n=chatzill@dsk227.neoplus.adsl.tpnet.pl) 11.41.04 Quit alexbobp (Read error: 104 (Connection reset by peer)) 11.45.32 Quit JdGordon (Remote closed the connection) 11.45.52 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 11.58.00 Quit JdGordon (Remote closed the connection) 11.58.14 Join stoffel_ [0] (n=sfr@p57B4E146.dip.t-dialin.net) 11.58.21 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 11.58.57 Join Schmogel [0] (n=Miranda@p3EE21D48.dip0.t-ipconnect.de) 12.01.25 # amiconn: about buffered vs unbuffered greylib... is there any practical difference between using buffered mode, drawing, and calling update, and rendering into a greyscale bitmap buffer in the plugin, then using grey_ub_gray_bitmap to draw that to the screen? 12.02.00 # the practical difference, i'd think, would be mainly in availability of the other drawing functions for buffered updates? 12.03.39 Join Acky [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com) 12.03.46 Join faemir [0] (n=faemir@88-106-244-173.dynamic.dsl.as9105.com) 12.04.10 # trying to figure out how best to do greylib pictureflow :/ 12.09.29 Join Minthe [0] (n=Minthe@KD124214153219.ppp-bb.dion.ne.jp) 12.11.58 # If you need a fullscreen buffer anyway there shouldn't be a significant difference 12.12.00 Quit PaulJam (".") 12.13.51 Join ender` [0] (i=krneki@foo.eternallybored.org) 12.14.02 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 12.14.25 # There are some situations where using the unbuffered version is better, e.g. when just a partial buffer is used (mandelbrot) it saves ram 12.14.51 # mandelbrot wouldn't be possible in buffered mode on archos, at least not without stopping playback 12.15.43 # Unbuffered mode needs 14KB of buffers on archos (+some), buffered mode needs 21KB. The whole plugin buffer is 32KB, so go figure... 12.16.19 Quit Acksaw (Connection timed out) 12.17.51 Quit JdGordon (Remote closed the connection) 12.17.54 # ok, issues i see here is that it writes directly to an offscreen buffer to draw the covers, but uses the API functions to write text. greylib supports using only part of the screen, right? 12.18.12 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 12.19.13 # maybe best bet would be LCD drawing functions for text, offscreen buffer of its own for the PF rendering, and grey_ub_gray_bitmap to render that into the greylib buffer? 12.19.18 # yes, although the choice of bondaries is restricted 12.19.42 # hrm... how, specifically? 12.19.49 # It can only split at pixel packing boundaries 12.20.02 # (the lib rounds automatically) 12.20.32 Quit Minthe ("Leaving...") 12.20.47 # so, from 1px to 8px alignment vertically, depending on target, and from 1px to 4px alignment horizontally? 12.20.47 # Why does picureflow render to an offscreen buffer, btw? 12.20.59 # Imo it would be better to render directly to the framebuffer 12.21.09 Join Minthe [0] (n=Minthe@KD124214153219.ppp-bb.dion.ne.jp) 12.22.25 # ...i'm digging a bit further. its buffer is rb->lcd_framebuffer, actually 12.23.32 # is that an in-memory buffer for the data currently on-screen, or an offscreen buffer that's copied onscreen by lcd_update? 12.24.51 # The latter. 12.25.59 # The currently displayed image is stored in the lcd controller's internal memory, which isn't memory mapped hence can't be written directly 12.26.23 # This applies to any target I know 12.26.52 Quit Acky (Read error: 104 (Connection reset by peer)) 12.27.13 Join Acksaw [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com) 12.30.49 Join moos [0] (i=Mustapha@rockbox/staff/moos) 12.33.48 # it doesn't seem too easy to draw via direct writes to greylib's buffer, unless i'm misreading? i'm still thinking that grey_ub_gray_bitmap draws from an offscreen buffer where we do the rendering are probably the way to go for PF, along with setting aside some lines at the bottom for the album text, and switching to normal LCD mode for the menu and tracklist 12.34.36 Join Jaykay [0] (n=chatzill@p579E7EB7.dip.t-dialin.net) 12.34.46 Quit stoffel_ (Read error: 113 (No route to host)) 12.36.57 # because nobody of those evil developers cared about my nice reminder, ill suggest committing of http://www.rockbox.org/tracker/2533 here in irc 12.38.35 # That would work of course. Just take care to avoid all lcd functions which directly access the lcd while the greylib overlay is running. This includes lcd_update() - so in order to print the album text, you need to use grey_deferred_lcd_update() instead 12.40.37 # no problem. probably not going to get anywhere on this today, so for now the only thing using the new greylib scaling support is a crummy bmp viewer test app 12.40.41 # The horizontal alignment for 2bpp horizontally-packed lcds is 8px, btw. This is because those lcds use 16 bit transfers 12.41.01 # which, with the *third* patch, is actually there 12.41.21 *** Saving seen data "./dancer.seen" 12.43.45 Join mud-rb [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 12.44.50 Quit tvelocity (Remote closed the connection) 12.45.02 # i'm not worried about horizontal res, the pictureflow effect is edge-to-edge, and i'll just restrict album titles to a designated area at the screen bottom, and make it N*8px 12.46.04 # Rather make the upper (greylib) area N*8px 12.47.22 # that's fine too. i'm packing up for now, but if anything occurs to you that might be a good idea on how to handle some part of this, i'll check the logs whenever i get back. 12.47.34 # There are 2 targets where the lcd height isn't a multiple of 8. It wouldn't matter for those (mini G1 and G2 -> horizontal pixel packing), but I think it's better to stay safe 12.53.07 Join Darksair [0] (n=user@117.89.121.31) 12.56.25 Quit jhulst (Read error: 60 (Operation timed out)) 12.59.07 Join alexbobp [0] (n=alex@69.149.25.200) 12.59.57 Quit Nibbler ("Ex-Chat") 13.10.49 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 13.16.34 Join Rudy77 [0] (n=Rudy77@adsl-69-221-120-99.dsl.akrnoh.ameritech.net) 13.18.17 Join Lss [0] (n=Lss@cm203.delta90.maxonline.com.sg) 13.19.14 # jhMikeS: AC chargign worked nicely, stopped at 4.205V and had a peak temperature of 35C 13.19.42 # with a standard battery AFAIK 13.20.01 Join ito [0] (n=ito@adsl-68-248-72-20.dsl.sfldmi.ameritech.net) 13.21.16 Quit ito ("Ex-Chat") 13.23.25 Join AndyIL [0] (i=AndyI@212.14.205.32) 13.24.17 Join FOAD_ [0] (n=dok@dinah.blub.net) 13.29.11 Join herrwaldo [0] (n=waldo@ip-81-11-228-79.dsl.scarlet.be) 13.33.00 Quit FOAD (Read error: 145 (Connection timed out)) 13.33.00 Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) 13.34.43 Quit AndyI (Read error: 110 (Connection timed out)) 13.36.34 Part Rudy77 13.39.08 Join B4gder [241] (n=daniel@rockbox/developer/bagder) 13.46.32 Join gartral [0] (n=Gareth@75.33.70.77) 13.46.46 # i have a bug... 13.47.18 # * scorche looks over at the bug tracker 13.48.04 # go ahead and say what you have experienced, but i may just tell you to submit it tot he tracker =) 13.48.20 # * domonoky detects that the wheel on e200v2 really looks like it needs some enable pin set. (i can measure changing voltage at the output pin with the OF, but not with rockbox. ) 13.49.23 # well, i did some searching there, but i thought ide confirm it here, before going through all that, when you try to set a rating for any song, a single popup appears wit "" and disapears , returning you to the WPS screen 13.49.48 # ah...i dont think many of us here use ratings... 13.50.30 # and for those of us that do? 13.51.27 # if it isnt in the tracker, i would fiel a report if it isnt already in there...otherwise, i will fade into the background for someone else to speak up 13.53.12 # it does the same for me, but as i have never used that feature, i have no idea if that is an intended function because there is something to do, etc 13.54.55 # would that be user interface, or WPS? 13.56.43 # i would put it under Database 13.59.57 # oops 14.00.19 # how do i edit it? 14.01.50 Join BigBambi_ [0] (n=alex@72.198.66-86.rev.gaoland.net) 14.02.05 # gatral: done! 14.02.25 Quit BigBambi ("Please insert girder") 14.03.11 # thank you for repairing my itchy trigger fingers mistake 14.04.28 # don't worries; no problems 14.05.48 Quit jhMikeS (Nick collision from services.) 14.05.54 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 14.06.17 # and i see a typo now, i put "on" instead of "only" 14.08.02 # * scorche fixed 3 typos ;) 14.08.39 # thanks scorche, im sorry to have to create o much work for yoo 14.08.43 # you* 14.09.01 # gartral: is your bug different to http://www.rockbox.org/tracker/task/9654 ? 14.09.22 # n1s: looks the same to me 14.09.42 # nope, tat workaround doesnt work for me 14.09.56 # that* (smegging keyboard) 14.10.13 # other than that, no difference 14.10.20 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 14.10.33 # ok, and you have enabled "Gather runtime data" and initialized the database? 14.10.37 # however, the "bug" is the same...perhaps a comment would be better saying that you ahve the same bug, but the workaround does not work 14.10.57 # n1s: the option isnt even there if you have not enabled gather runtime data 14.11.03 # oh 14.11.15 # and also, i just tryed setting the rateing with winamp. that resulted in the player freezeing on that particular track 14.11.52 # er, after reloading it too the player, that is :) 14.12.55 Quit alexbobp (Read error: 104 (Connection reset by peer)) 14.12.57 # /me detects that with rockbox i can also measure voltage changeing on the wheel of e200v2, but its only 0V - 0.5V, while the OF has 0-3V ... 14.13.03 # gartral: that sounds like a separate bug, please file it and attach the file if it's reproducible 14.13.25 # i dont think our implementation of rating is consistent with the tags, but i am not too sure.. 14.13.41 # gartral: i get the same behaviour like you with setting song ratign if i have not initialized the database, have you initalized yours? 14.14.10 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 14.14.11 # scorche: afaik we never save/read rating from the actual file 14.14.20 # yes, and its set to auto update 14.14.30 # * scorche nods at n1s 14.15.04 # then why would it freeze after winamps rating tag was applied to it? 14.15.16 # bugs? 14.17.07 # humm, i cant find any indication that the database initilises at boot, even when set to auto update 14.17.24 # it only needs t be initialized once 14.17.27 # [i know, speeling is horrible today] 14.17.51 # * domonoky measures more: the OF also has 0-0.5V if the Display is off (same as rockbox). With display on, i get 0-3V in the OF and 0-1V in rockbox. 14.18.25 Quit B4gder ("It is time to say moo") 14.19.38 Quit BigBambi_ (Remote closed the connection) 14.20.08 # gartral: can you browse the database on the player? 14.21.09 # i have some file titles that only show up partially both from database and filesystem 14.21.13 # how can i fix it 14.21.45 # n1s: yea, its a tad jumbled, but thats par for my player 14.21.53 Join stoffel_ [0] (n=sfr@p57B4E146.dip.t-dialin.net) 14.22.02 # who's Display? :P 14.22.38 # gartral: if you can browse it, it must have initialized at some point so, your bug is different from another minor one i found regarding the rating... 14.23.31 # Lss: what do you mean by "file titles"? the only thing that will show up in the filebrowser is the file name. 14.23.38 # n1s: hmm, i wonder whats causeing this 14.24.36 # gartral: is rockbox consistently freezing when you try to play the file modified by winamp? 14.25.05 # it did it twice, then i deleted it 14.25.25 # that doesn't help in fixing the bug... 14.25.35 # want me to try again? 14.25.40 # please do 14.25.50 # lol, one step ahead 14.26.07 # oddly enough, this it plays 14.26.15 # this time* 14.26.24 # the tags are obtained from the filename 14.26.35 # n1s: was that reading after the charger stopped? 14.26.40 # and audiocis coheriant 14.27.04 # jhMikeS: i wasn't looking at the time but the highest value in the graph was 4.205V 14.27.15 Quit Schmogel (Read error: 104 (Connection reset by peer)) 14.27.15 # [please excuse my poor typing today] 14.28.11 Join alexbobp [0] (n=alex@69.149.25.200) 14.28.29 # n1s: then that would be with charger on which is expected. 14.28.37 Join BigBambi [0] (n=alex@72.198.66-86.rev.gaoland.net) 14.30.56 # just as a side note: would it be possible to add something to control the length of time the fade in/out function lasts? or is this here and im just blind and stupid? 14.31.09 # huh i thought its there 14.31.21 # gartral: which fade? 14.31.37 # jhMikeS: ok, will you commit soon then? :) 14.31.52 # backlight fadeing, on E250 V1, most recent build 14.32.42 # gartral: it's fixed duration because of the low number of possible levels so longer duration would flicker 14.33.11 # ahh hah, is this in the NO DO, or can I possibly add that one? 14.33.37 # n1s: soon, yes. I'm just looking it over some more to make sure. 14.34.06 # gartral: You can add it for yourself, but I would guess it is unlikely to get in 14.34.08 # sounds good, looks like we can call it "supported" soon then :) 14.35.27 # * jhMikeS is just wondering if some minor concessions in powermgmt.c violate feature feeziness 14.36.07 # * moos thnks we can change the topic, freeze is overv :) 14.36.13 # -v 14.36.14 # BigBambi: ok, logical question would be: is the limited number of "levels" a mendable problem, or is it a hardware restriction? 14.37.32 # often hardware 14.37.39 # but I think it depends on target 14.38.43 # hmm, wouldnt be too easy to determin that, would it? 14.38.56 # BgBambi: could you change the #rockbox topic, freeze is over...; hi btw 14.39.11 # * moos canot type neither today 14.39.22 # moos: I can't, no 14.39.33 # moos: but scorche can :) 14.39.48 Mode "#rockbox +o scorche " by ChanServ (ChanServ@services.) 14.39.50 Quit stoffel_ ("Lost terminal") 14.39.57 # ok :) 14.40.04 Topic "Please read before speaking: http://www.rockbox.org/wiki/IrcGuidelines | Please direct offtopic/social chat to #rockbox-community | 3.1 is branched!" by scorche (i=Blah@rockbox/administrator/scorche) 14.40.11 Mode "#rockbox -o scorche " by ChanServ (ChanServ@services.) 14.40.26 # gartral: You could have a look at the code to see I'd imagine 14.40.28 # * jhMikeS generally logs in automatically and so rarely sees the IRC topic...ever 14.40.43 # i would if i could understand it... 14.40.45 # /topic ! ;) 14.40.55 # gartral: hehe :) 14.41.14 # * jhMikeS should probably do /topic at least once a day 14.41.22 *** Saving seen data "./dancer.seen" 14.41.46 # plus my comp over heat if i try and compile anything more comples then and oga|mp3 file 14.42.06 # heats* 14.42.18 # complex* >.< 14.42.56 # * jhMikeS also knew about /topic btw :) simple laziness 14.44.07 # scorche: thanks, last freeze/release was indicated on rockbox.org, not this time 14.44.26 Nick gartral is now known as Gartral (n=Gareth@75.33.70.77) 14.47.15 Quit BigBambi (Remote closed the connection) 14.48.28 Join BigBambi [0] (n=alex@72.198.66-86.rev.gaoland.net) 14.51.23 Join Schmogel [0] (n=Miranda@p3EE21D48.dip0.t-ipconnect.de) 14.51.38 Join Horschti [0] (n=Horscht@p4FD4C8CF.dip.t-dialin.net) 14.51.52 # hmm, the "Anti skip buffer" description in the manual is both very long and confusing... 14.51.54 Quit Horscht (Nick collision from services.) 14.54.37 Quit fredddy (Read error: 110 (Connection timed out)) 14.54.51 Join fredddy [0] (n=freddy@p3E9E3008.dip0.t-ipconnect.de) 14.58.17 Quit miepchen^schlaf (Read error: 104 (Connection reset by peer)) 14.58.58 # where in the smegging source can i find the call to fade the backlight? 14.59.49 # Domonoky: I sent you the disassembly :) 14.59.55 # any opinions on replacing the current description with this http://pastebin.com/m6463db38 ? 15.00.09 # fdinel: thanks.. 15.00.50 Join miepchen^schlaf [0] (n=miepel@p579EC669.dip.t-dialin.net) 15.00.53 # n1s: Sounds fine 15.01.18 # BigBambi: cool :) 15.01.42 # Perhaps add a bit about keeping it as low as possible? 15.02.35 # "However a high value increases how often the buffer has to be refilled, and thus reduces battery life somewhat. It is therefore desirable to keep this setting as low as possible without skips occuring."? 15.02.45 # maybe something like that 15.02.45 # fdinel: and it would be very nice, if you could take a look at where the wheel is read. I hope to find some time to work on this over the next days. 15.04.38 # nvm, im totally efing retarded 15.06.34 # n1s: I take it you either didn't see or didn't agree with my last comment? :) 15.07.37 # BigBambi: ah, missed it, there is a note about the battery life but maybe your way is better... 15.07.47 # I'm not sure 15.07.54 # Let me have a look at what is there now 15.09.10 # n1s: Ah no, what is there is fine I think 15.09.20 # n1s: I just missed the note first time round 15.09.48 # ok, will commit to the branch too then, thanks for looking :) 15.10.59 # i cant even find the part where the backlight is defined... 15.12.19 Quit n1s () 15.13.37 # i see where its mentioned, and called, but not where its defined 15.19.11 # Gartral: you mean the actual functions to disable/enable the backligt ? take a look a the target tree.. 15.23.03 # hmm, i cant see a way to modify thecode to make a coherient fade timer, though i suspect it would be possible if you found a way to freeze the backlight switch as it steps down 15.27.34 # im not gonna bother butchering the code, especially when i cant compile it myself 15.30.00 Quit faemir (Remote closed the connection) 15.31.50 # Umm, there are still some craps in wma files, so I have to talk with saratoga... 15.34.34 Quit Minthe ("Leaving...") 15.34.47 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 15.36.34 # Gartral: if you dont want to "butcher" (what ever that is) the code, why are telling it to us ? And compiling isnt difficult... there are various Howtos in the wiki. 15.39.13 # its not that, its that by the time im done, it wouldnt work, anyway, and the compileing issue is not that its difficut, its that my comp overheats when it trys to compile anything 15.44.58 Quit courtc (Read error: 60 (Operation timed out)) 15.45.01 Join courtc [0] (n=court@unaffiliated/courtc) 15.57.16 Join frinkazoid [0] (n=waldo@ip-81-11-230-38.dsl.scarlet.be) 15.57.20 Join lasser [0] (n=chatzill@Wb869.w.pppool.de) 16.02.20 Join Aurix_Lexico [0] (n=comrade@c-68-56-205-239.hsd1.fl.comcast.net) 16.08.18 # that's an underlying issue which should be addressed independently of any desire to work with Rockbox 16.11.18 Quit herrwaldo (Connection timed out) 16.11.40 Quit Jaykay ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") 16.14.42 Part Gartral 16.23.07 Quit mud-rb (Read error: 113 (No route to host)) 16.39.13 Quit Darksair ("Do you hear that? This is the sound of inevitability. This is the sound of your death, Mr. Anderson.") 16.39.47 # hm, does Rockbox use anything like swapfile on targets with small RAM? 16.41.26 *** Saving seen data "./dancer.seen" 16.41.50 # swapping what? 16.43.20 Quit Llorean (Read error: 104 (Connection reset by peer)) 16.44.04 # J-23: We want to buffer audio in memory so that the disk doesn't have to be spun up - swapping to disk would defeat the point 16.45.12 Join saratoga [0] (n=41becb3b@gateway/web/cgi-irc/labb.contactor.se/x-05ae7e7a3b055ce4) 16.45.49 # example: Load encoded (MP3, etc) file into ram, decode PCM to disk, remove encoded file from RAM, load decoded PCM to RAM, lots of disk. Better to just work with smaller pieces of audio. 16.46.20 Join Llorean [0] (n=DarkkOne@adsl-65-68-72-166.dsl.hstntx.swbell.net) 16.46.27 Join kugel [0] (n=chatzill@unaffiliated/kugel) 16.47.09 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 16.48.51 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) 16.49.40 Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") 16.53.42 Quit vitja (Read error: 104 (Connection reset by peer)) 16.57.51 Join thresh [0] (n=popa3d@videolan/developer/thresh) 16.58.00 Part thresh 17.05.08 Join tvelocity [0] (n=tony@athedsl-413299.home.otenet.gr) 17.23.22 Nick JdGordon is now known as JdGordon|zzz (n=jonno@rockbox/developer/JdGordon) 17.30.58 Join n1s [0] (n=nils@rockbox/developer/n1s) 17.39.30 # XavierGr: interested in updating the greek rbutil translation? Would be nice to have it updated before creating new binaries 17.39.54 # sure, when are you going to build the binaries? 17.41.33 # most likely this evening -- not sure if I have access to my windows build box the next couple of days 17.41.57 # ok let me remember how to do it and will do it asap 17.41.59 # considered putting the machine on a usb stick but forgot that FAT32 can't handle 5GiB files :( 17.42.08 # do you know how many missing strings are there? 17.42.19 Part XavierGr 17.42.24 # just use linguist from the Qt installation ;-) 17.42.42 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) 17.42.53 # ok will do 17.43.11 # XavierGr: http://www.rockbox.org/twiki/bin/view/Main/RockboxUtilityDevelopment#Translation_status_updated_2008 17.43.32 # thanks 17.43.33 # according to the stats on RockboxUtilityDevelopment currently 102. But it might be possible to reuse old strings -- you should keep an eye on the "suggestions" pane on the bottom in linguist 17.44.40 Quit killan ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") 17.47.04 Join kushal_12_27_200 [0] (n=kushal@c-71-230-163-208.hsd1.pa.comcast.net) 17.49.47 Quit n1s () 17.57.32 Join ZincAlloy [0] (n=d9eec502@gateway/web/cgi-irc/labb.contactor.se/x-f2583d1bb8b191de) 17.57.33 # fdinel: hi :) 17.58.59 # hey kugel 18.00.37 # fdinel: thanks again for your disasm, I'm still in the process of understanding the code, but I got most ;) 18.01.23 # fdinel: What I'd find interesting would be if this func is called in an isr or in a tick task. I found only 1 reference to that function in objdump's disasm 18.02.19 # kugel: yeah well it's called in the "user interface" task (thread), which makes sense ;) 18.02.27 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 18.02.40 # fdinel: so in in an isr? 18.02.45 # (well not directly but still) 18.02.57 # I mean it can be both together 18.03.10 # not an ISR no, but a thread which is called once every x time 18.03.20 Join Acky [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com) 18.03.26 # that's a tick task ;) 18.04.01 # yep :P 18.07.11 # fdinel: the BOP_CTRL_REG - DBOP_CTRL_REG stuff is quite confusing 18.07.34 # I mean those "#(DBOP_CTRL_REG - DBOP_CTRL_REG)]" 18.07.37 # bluebrother: what's the string "progresswindow" under ProgressLoggerFrm? Am I supposed to conatenate these 2 words? 18.08.22 # I'd think that equals to #0, but it doesn't. the objdump disasm is clearer here 18.10.25 Join toffe82 [0] (n=chatzill@75.12.168.247) 18.11.51 Quit Acksaw (Read error: 145 (Connection timed out)) 18.11.52 # XavierGr: that's from an accessibility description. I think this needs to get cleaned up -- it isn't shown anywhere so you could simply ignore it 18.12.47 # bluebrother: it isnt shown, but it gets voiced :-) 18.14.03 Join killan [0] (n=nnscript@c-415472d5.06-397-67626721.cust.bredbandsbolaget.se) 18.16.08 # so should I keep it together or as saperate words? 18.16.13 # or ignore it? 18.16.57 # fdinel: bpl is branched if bit 31 is, right? 18.17.07 # bit 31 is 0 i mean 18.17.57 # well, if the N flag isn't set, so yes, 0 18.18.31 Quit killan (Client Quit) 18.18.43 Join killan [0] (n=nnscript@c-415472d5.06-397-67626721.cust.bredbandsbolaget.se) 18.24.02 Join karashata [0] (n=karashat@69.41.192.215) 18.24.16 Quit {phoenix} (Remote closed the connection) 18.32.27 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 18.33.10 Quit beta2k_ (Read error: 110 (Connection timed out)) 18.38.02 Quit saratoga ("CGI:IRC (EOF)") 18.41.30 *** Saving seen data "./dancer.seen" 18.42.20 Quit Schmogel (Read error: 110 (Connection timed out)) 18.51.33 Quit ZincAlloy ("CGI:IRC (Ping timeout)") 18.56.21 Quit karashata ("G'bye everyone!") 19.13.09 Join karashata [0] (n=karashat@69.41.192.215) 19.14.32 Join PaulJam [0] (n=pauljam@p54BED00D.dip.t-dialin.net) 19.21.19 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 19.21.23 Quit tvelocity (Remote closed the connection) 19.23.10 # bluebrother: how much time do I still have? I need to finish 22 strings. 19.37.56 Join Schmogel [0] (n=Miranda@p3EE21C0D.dip0.t-ipconnect.de) 19.40.53 Quit jhMikeS (Nick collision from services.) 19.40.59 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 19.41.53 Quit karashata ("G'bye everyone!") 19.44.23 Join karashata [0] (n=karashat@69.41.192.215) 19.47.06 # SUCCESS!!!!!!! 19.48.25 # kugel: buttons with dbop ? 19.48.25 # domonoky: ping 19.48.30 # heh 19.48.31 # yes 19.48.37 Quit gromit` (Read error: 60 (Operation timed out)) 19.48.49 # congratulations ! :-) 19.49.06 # http://pastebin.ca/1290294 19.49.44 Quit kushal_12_27_200 ("Leaving") 19.49.46 # purely based on disassembly 19.51.34 # now I need to find which bit is which button 19.56.30 Join gromit` [0] (n=gromit@ALagny-154-1-67-253.w86-203.abo.wanadoo.fr) 19.58.33 Quit PaulJam (".") 19.58.54 # kugel: with this code i can only detect power and down again. Can you read all buttons on fuze with this ? 20.00.07 # XavierGr: no hurry ... I guess I won't start building the next 3 hours. Maybe I can get it done tomorrow morning instead, need to check my timetable 20.00.32 # domonoky: I haven't yet looked at the return too much, but I can surely say hold button can be detected too 20.00.48 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 20.04.22 Join Acksaw [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com) 20.07.07 Join Strife89 [0] (n=michael@204.116.245.152) 20.08.46 # * lucent raises an eyebrow with interest 20.10.40 Quit Acky (Read error: 60 (Operation timed out)) 20.10.46 Join Acky [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com) 20.15.53 Quit Strife89 ("Bye people.") 20.15.59 # bluebrother: FS#9688, didn't manage to compile rbutil to be sure that it works though. I just run linguist and updated the missing strings. Will try again later this night 20.16.07 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 20.19.49 Join {phoenix} [0] (n=dirk@p54B45D4C.dip.t-dialin.net) 20.21.49 # kugel: at least on e200v2, i can only detect power and down. no other button seems to work :-/ 20.21.59 # domonoky: uhmm, I cannot seem to get only those 3 too 20.22.45 Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-25c7af85b4685f94) 20.23.30 Quit Acksaw (Connection timed out) 20.23.51 # maybe we need to reset the input before 20.25.42 # XavierGr: if linguist thinks the file is ok then there shouldn't be any issue. 20.29.32 Join stoffel_ [0] (n=sfr@p57B4F801.dip.t-dialin.net) 20.30.38 Quit {phoenix} (Remote closed the connection) 20.31.41 Quit toffe82 (Read error: 110 (Connection timed out)) 20.31.56 Part XavierGr 20.32.02 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) 20.40.22 # XavierGr: accepted and committed. Thanks for the fast update :) 20.41.33 *** Saving seen data "./dancer.seen" 20.46.31 # bluebrother: I should thank you, you are welcome too :) 21.07.55 Join alexbobp_ [0] (n=alex@69.149.25.200) 21.08.45 Join mc2739 [0] (n=mc2739@cpe-67-10-238-175.satx.res.rr.com) 21.10.37 Join Kitti [0] (n=himka_co@195.5.125.25) 21.10.57 Quit BHSPitLappy (Read error: 104 (Connection reset by peer)) 21.13.40 Quit gevaerts (Nick collision from services.) 21.13.49 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 21.18.38 # fdinel: hey, bad news 21.21.26 Part Kitti 21.24.08 Quit alexbobp (Connection timed out) 21.30.10 # bluebrother: when do you want to tag the new rbutil release ? (i can build the mac-binary either today, or tomorrow morning. After that, it gets difficult.) 21.36.17 Join Zagor [242] (n=bjst@rockbox/developer/Zagor) 21.43.39 # domonoky: it's a bit weird isn't it? we should get at least the buttons we get reading directly 21.45.59 Quit karashata ("G'bye everyone!") 21.53.56 Join {phoenix} [0] (n=dirk@p54B45D4C.dip.t-dialin.net) 21.55.01 Join ZincAlloy [0] (n=d9eec502@gateway/web/cgi-irc/labb.contactor.se/x-95cf6fd063dc2513) 21.57.49 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 22.05.34 Join Martyn [0] (n=martinb@adsl-70-231-242-168.dsl.snfc21.sbcglobal.net) 22.08.11 Join aneqrs [0] (n=andreas@c83-253-104-206.bredband.comhem.se) 22.14.55 # domonoky: soonish, at least until midnight. 22.15.13 # too bad the french translation hasn't been updated yet. 22.15.31 # domonoky: do you get int_btn == 0 regulary? 22.15.43 # I do, which shouldn't happen 22.16.19 # kugel: no, its always set to 843 if i dont press anything. 22.16.54 # same for me, but completely 0 every 5th read or so 22.20.05 Quit stoffel_ ("leaving") 22.21.29 Part Martyn 22.23.19 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 22.29.57 # domonoky: any idea why we cannot read the buttons we get with direct gpio reading? maybe lcd is set up wrongly? 22.34.44 # kugel: no idea at moment.. 22.39.13 Join MethoS- [0] (n=clemens@host-091-096-214-033.ewe-ip-backbone.de) 22.40.05 # amiconn: actually, i need to change my plan, the album art text *can* render over the images... it *looks* like the buffer for buffered greylib is still just W*H uint8, so i can probably draw to that, and then use greylib's puts, and then call grey_update()... this will also make pretty much everything the same as the color case, except for passing a plugin to the bitmap loader, the data type of the buffer, etc 22.41.35 *** Saving seen data "./dancer.seen" 22.47.49 # domonoky: have you put some delay between button_read_device? maybe it's just too fast so you don't se it returning 0 22.54.07 # can someone tell me what the difference is between the watermarks in buffering.c and plaback.c? 22.54.14 Quit Bensawsome (Nick collision from services.) 22.55.39 Join mcuelenaere [0] (i=mcuelena@rockbox/developer/mcuelenaere) 22.55.43 Quit BHSPitLappy (Remote closed the connection) 22.56.50 Join Bensawsoj [0] (n=Bensawso@server.lethaltechnology.net) 22.58.04 Quit Zagor ("Leaving") 23.00.00 Quit Horschti ("I am root. If you see me laughing, you better have a backup") 23.06.47 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 23.24.37 Quit fredddy (Read error: 110 (Connection timed out)) 23.25.26 Join fredddy [0] (n=freddy@p3E9E2148.dip0.t-ipconnect.de) 23.32.04 # * bluebrother prepares releasing rbutil 23.32.33 # or rather creating binaries to be released with Rockbox 3.1 23.32.52 # Great :) 23.35.19 Join freddy__ [0] (n=freddy@p3E9E1FCE.dip0.t-ipconnect.de) 23.38.50 Join hillshum [0] (n=hillshum@75-165-241-153.slkc.qwest.net) 23.39.35 # http://www.muppethouse.com/rockbox-i-hated-it-now-i-like-it/ 23.39.49 # a random friendly blog post 23.45.16 # <_Auron_> I can't wait until v2s are supported.. everytime I unplug my sansa it spends about 3-4 minutes 'refreshing' 23.45.20 # <_Auron_> even if I didn't change anything 23.45.31 Nick alexbobp_ is now known as alexbobp (n=alex@69.149.25.200) 23.45.57 # <_Auron_> that 10 seconds of boot time is nothing compared to that 23.49.19 Join QUICKSTART [0] (n=QUICKSTA@pool-72-88-166-100.nwrknj.east.verizon.net) 23.49.57 Quit fredddy (Read error: 110 (Connection timed out)) 23.50.23 Quit EspeonEefi ("さよăȘら") 23.53.06 Nick Bensawsoj is now known as Bensawsome (n=Bensawso@server.lethaltechnology.net) 23.55.26 # hrm, is calling grey_show() slow at all if the state is not changing? 23.55.30 # Unhelpful: I can think of several possible solutions for this. First, we can declare the greylib's internal buffer to be publicly accessible. There's a potential caveat though - the overlay width and height are aligned (as explained earlier) and hence are not necessary equivalent to what was passed to the lib 23.56.45 # Second, it would also be possible to write some more unbuffered drawing functions. So far there just was no need though, and these functions would be somewhat more complex than the buffered ones 23.56.46 # so the internal buffer *is* uint8, but the width and height may have been rounded from the requested ones 23.56.57 # yes 23.57.10 # ok, i can work with that. 23.57.25 # Third (easiest), you could just use buffered mode, and live with the extra copying 23.58.20 # i think first is actually easiest, in this case, since once i fix up the rounded width/height, the greylib buffer in buffered "works" the same way as lcd_buffer