--- Log for 12.12.105  Server: kornbluth.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 1 month and 7 days ago

00.03.22 Join    Massa [0] (n=Massa1@p549E857C.dip0.t-ipconnect.de)
00.04.47 Join    JazzBone [0] (n=JB@cc829402-a.groni1.gr.home.nl)
00.05.11 #       <Massa> Hi everybody!
00.06.41 #       <idanm> good night everyone
00.09.40 #       <Massa> does someone know what happened to forums.rockbox.org?
00.10.23 #       <idanm> they are dead for now...
00.10.34 Quit    idanm ()
00.10.44 #       <Massa> what happened?
00.10.46 Quit    JazzBone ("Leaving")
00.11.04 #       <Massa> (and when will i be available again?
00.11.12 #       <Moos> the administarator isn't here
00.11.25 #       <Moos> you need to wait from MisticJeff
00.11.45 #       <Moos> we can't tell when the site will relive again
00.11.47 Join    einhirn [0] (i=Miranda@szgt-d9b8e8f8.pool.mediaWays.net)
00.11.50 Join    ts-x [0] (n=43823b46@labb.contactor.se)
00.12.07 #       <Massa> was it discussed already this day?
00.12.21 #       <Bagder> Massa: MisticJeff is not here very often
00.12.23 Quit    mirak (Remote closed the connection)
00.12.28 #       <Bagder> so mentioning it here doesn't do much good
00.12.39 #       <Moos> absolutly
00.12.41 #       <Massa> BTW, is MisticJeff also the admin of forums.rockbox.org?
00.12.47 #       <Bagder> yes
00.13.18 #       <ts-x> Hey for anyone working on the H3xx wps flickering issue, I think I found something that might help (and maybe you are already aware of?)
00.13.35 #       <Massa> I thought he's "only" responsible for www.misticiriver.net...
00.13.44 #       <Moos> both of them
00.13.54 #       <Massa> ts-x: Isn't the flickering already fixed in the latest CVS version?
00.14.09 #       <ts-x> Not entirely
00.14.24 #       <ts-x> But what I've found is that it's only the %x images that are flickering
00.14.51 #       <ts-x> Preloaded and conditionaly displayed bitmaps are not flickering
00.15.05 #       <ts-x> I tried the exact same image both ways and found this to be true
00.15.29 #       <Moos> good night @ all
00.15.37 Quit    Moos ("Glory to Rockbox")
00.15.56 #       <Massa> I'm not very experienced in WPS, but isn't %x for preloaded images?
00.16.25 #       <ts-x> %x loads and displays immediately
00.16.25 #       <Massa> Moos: good night!
00.18.33 #       <Massa> so only %xl preloads images?
00.18.55 #       <ts-x> Yes
00.19.17 #       <ts-x> I just loaded Rockbox for the first time on Friday and kind of stumbled upon this during the wps creation process
00.19.47 #       <Massa> Hmm, when you look e.g. in engineer2 wps, all images will be preloaded with %xl
00.19.49 Join    tarn [0] (n=irc@tor/session/x-3d6ef1891163788f)
00.20.08 #       <Massa> (at least in the version I use ;) - and it still flickers...
00.20.24 #       <ts-x> The background is %x
00.20.37 #       <ts-x> Image 'a'
00.21.24 #       <Massa> You're right - and you changed it so it's preloaded?
00.21.32 #       <Massa> And it did not flicker any more?
00.21.40 Quit    tarn ()
00.22.16 #       <ts-x> I just tested engineer as well, just the background is flickering.  Everything else is ok.
00.22.58 #       <ts-x> Let me change it and test...
00.23.17 #       <dropandho> that would be dope to fix that bug!
00.25.30 #       <Massa> I didn't test the latest CVS changes, is it still flickering?
00.26.54 Quit    Kohlriba ("Leaving")
00.27.12 Join    chiller_ [0] (i=staale@kristoffersen.ws)
00.27.19 Quit    chiller (Read error: 104 (Connection reset by peer))
00.27.28 Nick    chiller_ is now known as chiller (i=staale@kristoffersen.ws)
00.30.40 Quit    chiller (Read error: 104 (Connection reset by peer))
00.32.11 Join    chiller [0] (i=staale@kristoffersen.ws)
00.39.47 #       <ts-x> Not having much luck with engineer since not preloading the background seems to cause it to overlap everything else
00.40.16 #       <Massa> And removing it would help?
00.44.21 #       <ts-x> I just did that - it significantly reduces flickering but it still flickers when pausing and changing tracks
00.45.01 #       <ts-x> What's strange is that the wps I'm creating doesn't flicker on pausing or track changes
00.45.37 #       <Massa> Yeah, that's really strange...
00.46.09 #       <Massa> I'll leave now and go to bed...
00.46.12 #       <Massa> Good night!
00.46.22 #       <ts-x> Seems to indicate that multiple factors are contributing the flickering
00.46.25 #       <ts-x> Good night
00.46.37 #       <ts-x> Well if nothing else maybe this information will help one of the devs...
00.47.30 Quit    PaulJ (".")
00.52.55 Quit    Massa ("ChatZilla 0.9.61 [Mozilla rv:1.7.12/20050915]")
00.53.54 Join    Jungti1234 [0] (n=jungti12@58.77.81.144)
01.07.03 Quit    San||Away (Read error: 110 (Connection timed out))
01.10.25 Quit    saa[b_r]ider (Read error: 104 (Connection reset by peer))
01.10.55 Quit    ts-x ("CGI:IRC (EOF)")
01.11.17 Quit    ratpack91 ("Azureus 2.3.0.6")
01.13.23 ***     Saving seen data "./dancer.seen"
01.15.32 Quit    Bger ()
01.26.32 Quit    gromit` (Remote closed the connection)
01.29.15 Quit    Dima202 ("Leaving")
01.30.54 Quit    ender` (Read error: 113 (No route to host))
02.21.29 Quit    einhirn (Read error: 110 (Connection timed out))
02.26.53 Join    actionshrimp [0] (n=NNSCRIPT@host86-136-104-122.range86-136.btcentralplus.com)
02.46.50 Join    San [0] (n=sanitari@213-202-130-199.bas502.dsl.esat.net)
02.57.11 Quit    tvelocity ("Leaving")
03.09.18 Quit    Jungti1234 ("bye")
03.13.26 ***     Saving seen data "./dancer.seen"
03.37.53 Quit    San (Read error: 110 (Connection timed out))
03.43.08 Join    amiconn_ [0] (n=jens@p54BD45CD.dip.t-dialin.net)
04.01.16 Quit    amiconn (Read error: 110 (Connection timed out))
04.01.17 Nick    amiconn_ is now known as amiconn (n=jens@p54BD45CD.dip.t-dialin.net)
04.02.22 Quit    actionshrimp ("a bird in the bush is worth two in your house")
04.06.26 Quit    ehntoo ("Leaving")
04.06.47 Join    ehntoo [0] (n=ehntoo@24-177-166-0.dhcp.mrqt.mi.charter.com)
04.19.38 Quit    TCK (Read error: 104 (Connection reset by peer))
04.31.15 Join    Midgey34 [0] (n=Midgey34@c-24-11-55-125.hsd1.mi.comcast.net)
04.42.17 Join    Jungti1234 [0] (n=jungti12@58.77.81.144)
04.43.21 #       <Jungti1234> hi
04.48.49 #       <dropandho> hey man...what up?!
04.52.25 #       <Jungti1234> what up?
04.53.45 Quit    Jungti1234 ("bye")
05.04.01 Join    Rob2222_ [0] (n=Miranda@ACB60B8C.ipt.aol.com)
05.10.35 Join    Paul_The_Nerd [0] (n=paulthen@cpe-66-68-93-2.austin.res.rr.com)
05.13.14 Part    Midgey34
05.13.31 ***     Saving seen data "./dancer.seen"
05.14.45 Join    San [0] (n=sanitari@A-102-53.cust.iol.ie)
05.19.39 Quit    Rob2222 (Read error: 110 (Connection timed out))
05.28.00 Quit    ehntoo ("Leaving")
05.28.01 Quit    San (Read error: 104 (Connection reset by peer))
05.36.59 Join    gursikh [0] (n=gursikh@adsl-209-30-245-110.dsl.hstntx.swbell.net)
05.38.24 #       <gursikh> Hello
05.40.25 Quit    ReKleSS (kornbluth.freenode.net irc.freenode.net)
05.40.25 NSplit  kornbluth.freenode.net irc.freenode.net
05.40.30 NHeal   kornbluth.freenode.net irc.freenode.net
05.40.30 NJoin   ReKleSS [0] (n=ReKleSS@c220-237-136-11.mckinn1.vic.optusnet.com.au)
05.44.09 #       <Paul_The_Nerd> Hello
05.45.01 #       <gursikh> This forums have been down for some time, Is this intentional?
05.45.13 #       <dropandho> not that i am aware of
05.45.34 #       <dropandho> apparently Jeff, from misticriver, hosts the forums
05.45.54 #       <dropandho> i have reported it to him on IM today, but haven't received any word back from him
05.46.16 #       <dropandho> i hope someone else has some word on it
05.46.31 Join    webguest24 [0] (n=c87ec44a@labb.contactor.se)
05.46.48 #       <gursikh> This morning (14 hours ago)  before work it was down, so it's been quite some time 
05.47.10 #       <dropandho> yeah, it has been a while
05.47.15 Quit    webguest24 (Client Quit)
05.47.20 #       <dropandho> haven't caught Linus on here- to report it to him
05.47.37 #       <dropandho> any ideas what to do next?
05.47.59 #       <gursikh> Is there any other contact for Jeff?
05.48.44 Join    Midgey34 [0] (n=Midgey34@c-24-11-55-125.hsd1.mi.comcast.net)
05.49.16 #       <dropandho> jeff@misticriver.net
05.49.21 #       <dropandho> u wanna hit him up?
05.49.35 #       <gursikh> he has not responded via AIM ?
05.49.51 #       <dropandho> correct...he has not written back
05.50.17 #       <gursikh> via AIM or Y! messengers?
05.50.17 #       <dropandho> i cant ping the forum address either
05.50.20 #       <dropandho> AIM
05.50.37 #       <dropandho> it said he was "active" also
05.51.20 #       <gursikh> he has both, Let me attempt yahoo.
05.53.23 #       <gursikh> Is there additional contact Infomation for Linus?
05.54.17 #       <dropandho> linus@haxxNO.SPAM.se
05.54.33 #       <dropandho> off of the site
05.54.40 #       <gursikh> yeah, i got that one.
06.01.33 Quit    Paul_The_Nerd ("Chatzilla 0.9.68.5.1 [Firefox 1.5/undefined]")
06.03.59 #       <dropandho> any luck?
06.04.09 #       <gursikh> none
06.04.54 #       <dropandho> bummer
06.05.00 #       <gursikh> he just put on his away message on aim after i IMMED him.
06.05.00 #       <dropandho> i need to head out now for bed
06.05.16 #       <dropandho> darn
06.05.32 #       <dropandho> welp, im off now
06.05.38 #       <dropandho> hope something comes up
06.05.54 #       <gursikh> yes
06.05.54 #       <dropandho> u email linus and jeff?
06.06.12 #       <gursikh> Yup
06.06.29 #       <dropandho> great- we have it covered
06.06.31 #       <dropandho> thanks man
06.06.34 #       <dropandho> have a good night
06.07.28 Quit    dropandho ()
06.17.43 Quit    Nibbler (Read error: 110 (Connection timed out))
06.21.39 Quit    mikearthur (Connection timed out)
06.21.51 Join    mikearthur [0] (n=mike@82-41-227-152.cable.ubr11.edin.blueyonder.co.uk)
06.24.21 Join    Nibbler [0] (n=sven@e181087182.adsl.alicedsl.de)
06.36.48 Quit    mikearthur (Read error: 104 (Connection reset by peer))
06.40.44 Quit    gursikh (Remote closed the connection)
07.13.35 ***     Saving seen data "./dancer.seen"
07.17.22 Part    Midgey34
07.19.30 Quit    RotAtoR ()
07.27.21 Join    San [0] (n=sanitari@213-202-135-222.bas502.dsl.esat.net)
07.47.57 Join    Jungti1234 [0] (n=jungti12@58.77.81.144)
07.59.53 Join    saa[b_r]ider [0] (n=saab_rid@221.216.54.167)
08.04.23 #       <Jungti1234> hoo
08.17.48 Join    Bger [0] (n=Bager@83.222.160.88)
08.19.20 #       <Jungti1234> hi Bger
08.19.26 #       <Bger> hi, Jungti1234 :)
08.34.47 Quit    San (Read error: 104 (Connection reset by peer))
08.34.47 Quit    saa[b_r]ider (Read error: 104 (Connection reset by peer))
08.36.16 Join    ender` [0] (i=ychat@84.52.165.220)
08.50.07 Join    Acksaw [0] (i=Acksaw@spc1-stok5-4-0-cust5.bagu.broadband.ntl.com)
09.03.38 Join    einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de)
09.04.38 Quit    Acksaw ()
09.04.58 #       <Bger> wow, we have 3 independend buttons on h300 (main unit) : ON (aka play/pause), MODE (aka A-B) and REC 
09.05.21 #       <Bger> s/independend/independenT
09.09.34 Join    LinusN [0] (n=linus@labb.contactor.se)
09.10.01 #       <Jungti1234> hi Linus
09.11.11 Quit    Rob2222_ ()
09.12.37 #       <LinusN> hey ho
09.13.37 ***     Saving seen data "./dancer.seen"
09.15.43 #       <XavierGr> Hi LinusN!
09.16.37 #       <LinusN> hi
09.17.54 #       <XavierGr> LinusN: Theoritically, can I start a new thread within a plugin?
09.18.17 #       <XavierGr> (but current plugin continue to run)
09.18.37 #       <XavierGr> like having a sub thread at the time the current plugin runs.
09.20.00 #       <XavierGr> I know I can start a thread in a tsr plugin but then I exit the plugin (it runs in the background) so I am not sure if I can.
09.22.51 #       <LinusN> XavierGr: yes you can
09.23.01 #       <XavierGr> interesting.
09.23.20 #       <XavierGr> I quite finished the new version of the jpeg filescroller.
09.24.24 #       <XavierGr> In order to have as more entries as you can, I decided that filenames must be written in a file and a pointer array would hold their seek positions in the file.
09.24.49 #       <XavierGr> That is nice until sorting comes into play.
09.25.06 #       <LinusN> how do you create the file?
09.25.15 #       <XavierGr> To sort ~850 entries with qsort an interval of 6-7 seconds is needed.
09.25.54 #       <XavierGr> you mean how I write the entries in the file?
09.26.21 #       <XavierGr> (I create the file with rb->open) then I scan the folder and filter jpeg files
09.26.38 #       <XavierGr> for each entry I write down to the file the name of the jpg.
09.26.47 #       <LinusN> ah ok
09.26.57 Join    B4gder [0] (n=daniel@static-213-115-255-230.sme.bredbandsbolaget.se)
09.27.36 #       <XavierGr> thing is that when I try to sort the compare function must open read 2 position get the names close the file and then compare the 2 entries.
09.27.58 #       <XavierGr> for a small number of files this is quite easy and fast but if you have a big list then....
09.30.36 #       <XavierGr> so I had the idea of letting the user see the jpeg of his choice and then run a different transpaerent thread for sorting.
09.31.56 #       <preglow> w00t, my player locked up
09.31.57 #       <XavierGr> also for the iriver targets I made a small interface to check if playback occurs to try to fetch plugin memory instead of the audio buffer.
09.32.10 #       <XavierGr> your iPod nano?
09.32.35 #       <preglow> of course not
09.32.45 #       <XavierGr> iHP?
09.32.49 #       <preglow> that never locks up!!
09.32.52 #       <preglow> yeah, ihp
09.32.58 #       <preglow> when trying to start playback right after using usb
09.33.00 #       <preglow> plain locked
09.33.05 #       <preglow> wouldn't turn off no how
09.33.12 #       <XavierGr> reset :)
09.33.16 #       <preglow> yes, of course
09.33.16 Join    Zagor [0] (n=bjst@pdpc/supporter/sustaining/Zagor)
09.34.18 #       <XavierGr> Does anyone know if the grayscale needs the same memory on all targets? Eg. iriver needs ~86kB what about archos models?
09.34.40 #       <XavierGr> make that 8kB I think
09.34.58 #       <B4gder> it most definately is not the same amount
09.36.11 #       <XavierGr> we can easily determine that with a splash in th jpeg viewer. (at least the method I used) anyone willing to help me find it?
09.37.01 #       <amiconn> You can't splash() while grayscale is running
09.37.20 #       <XavierGr> well I splash right before.
09.37.26 #       <amiconn> However, the amount of mem is easy to calculate; the formula is given in the grayscale lib sources
09.37.41 #       <XavierGr> gray_init outputs the size needed with an argument
09.38.43 #       <amiconn> apps/plugins/lib/gray_core.c, line 106ff
09.41.02 #       <XavierGr> what's bitpatterns?
09.44.38 #       <XavierGr> anyway I am asking this to see if Archos targets are capable of viewing while playing (at least a very small pic < 5kB) but as I see it with current plugin memory on archos this is not possible, am I right on this?
09.45.30 #       <XavierGr> grayscale cannot fit in the archos plugin memory, I think.
09.45.33 #       <Bger> can someone help me in understanding the following
09.45.35 #       <Bger> @@ -166,9 +166,12 @@
09.45.43 #       <Bger> in a diff file ?
09.46.01 #       <XavierGr> lines and offsets to apply the patch
09.46.11 #       <Bger> yes, but...
09.46.34 #       <Bger> what does the ",9" and ",12" mean ?
09.46.51 #       <XavierGr> dunno :(
09.46.59 #       <B4gder> why does it matter?
09.47.09 #       <ze> Bger: count the lines
09.47.45 #       <Bger> B4gder: because i'm trying to edit a diff file
09.47.58 #       <B4gder> then that line won't matter much
09.48.02 #       <amiconn> XavierGr: Yes you're right. On Archos it's possible to fit unbuffered grayscale with <33 shades in plugin memory with small plugins (e.g. mandelbrot), but not with full depth and the jpeg plugin takling almost all plugin memory for itself
09.48.08 #       <B4gder> patch only uses that as a hint
09.48.17 #       <Bger> aha
09.48.33 #       <ze> Bger: i think the 1st is the number of lines that the specified chunk has before the patch, and the 2nd is the number of lines in that chunk after patching
09.48.46 #       <Bger> then what does the "unexpected end of patch" or simillar mean ?
09.49.03 #       <B4gder> it means patch didn't like the format of the patch
09.49.08 #       <ze> and i think patch does expect it to be right
09.49.35 #       <Bger> heh, B4gder ... 
09.49.45 #       <XavierGr> amiconn: Thanks then I will remove this option for archos with low plugin memory.
09.51.24 #       <Bger> so if i edit a diff file and remove a number of different lines, should i change these values as well ?
09.52.09 #       <B4gder> I would advice against hand editing a diff file
09.52.53 #       <XavierGr> except if it is rather small change (E.g on the same line)
09.54.05 #       <Bger> B4gder then what u do when u've changed many files but u want to make a diff of only 5-6 ? 
09.54.27 Join    b0br [0] (n=c15421fd@labb.contactor.se)
09.54.34 #       <ze> just diff those files?
09.54.36 #       <B4gder> then I diff only those
09.54.37 #       <Bger> also, there are some very little diffs (like whitespace) ?
09.54.47 #       <B4gder> then use an option that ignores whitespace
09.54.53 #       <Bger> heh
09.55.07 #       <Bger> which is ?
09.55.11 #       <B4gder> -b and -B
09.55.18 #       <Bger> 10x
09.55.25 #       <B4gder> or possibly -w ;-)
09.55.43 #       <Bger> does the cvs diff support these ?
09.55.44 #       <B4gder> and -E
09.55.46 #       * B4gder grins
09.55.57 #       <B4gder> it supports -B and -b at least
09.56.07 #       * Bger goes to RTFM
09.56.32 #       <B4gder> and to make a single patch, you can just concatenate any number of single-file diffs
09.57.02 #       <B4gder> diff files built this planet
09.57.06 #       <Bger> but cvs diff does it afaics ... or i'm wrong
09.57.47 #       <Bger> (concatenating)
09.58.06 #       <B4gder> yes it does, but I mean in case you use multiple command line invokes
09.58.18 #       <Bger> ahap... 10x :)
10.00.18 #       <XavierGr> I hate when I am diffing from CVS and I have a new file.
10.00.28 #       <XavierGr> I just can't make it to add it.
10.00.36 Join    Vlad0man [0] (n=Vladoman@p54A7FD0E.dip.t-dialin.net)
10.00.40 #       <Bger> someone told there is a command for doing it
10.00.48 #       <Bger> iirc markun
10.00.54 #       <XavierGr> Instead i do single diff of 2 identical cvs'es (the other has the changes)
10.01.43 Quit    _Vladoman (Read error: 110 (Connection timed out))
10.02.19 #       <markun> yes, install cvs tools. Then: cvsdo add 'file'
10.02.34 #       <markun> and make the patch with cvs diff -uN 'files'
10.03.52 #       <XavierGr> God I am an as*hole!!!!
10.04.37 #       <XavierGr> markun I suppose that I don't need cvs acces for this right?
10.04.48 #       <markun> not with cvsdo
10.04.48 #       <Bger> yep
10.05.14 #       <XavierGr> ok thanks.
10.06.22 #       <Bger> heh i don't see such ebuild ... (cvs tools or sth similar)
10.06.35 Part    b0br
10.07.20 #       <Bger> B4gder cvs diff supports all three -b -B -w
10.08.53 #       <linuxstb> preglow: When did you last compile and install the bootloader on your Nano?  The current CVS doesn't load the original firmware any more for me.
10.09.30 #       <preglow> linuxstb: aeons ago
10.09.48 #       <preglow> linuxstb: it doesn't here either
10.09.51 #       <preglow> linuxstb: it just hangs
10.10.23 #       <linuxstb> OK.  I'm thinking of changing it anyway, so instead of having the apple OS in the boot partition, it loads it from the disk.  This should speed up booting a little.
10.10.47 #       <preglow> oh, you mean dumping it to a file first?
10.11.03 #       <linuxstb> Yes - you have to do that as part of building the bootloader anyway.
10.12.35 #       <XavierGr> OMFG Sorting the list from the file will need 18 seconds.
10.12.59 #       <XavierGr> (for 850 files)
10.13.14 #       <B4gder> XavierGr: 18 seconds to sort 850 names?
10.13.19 #       <linuxstb> Wow, I've just tested it with a 512KB "dummy" firmware file, and the boot time on my iPod decreased by about 4 seconds.
10.13.31 #       <XavierGr> yes. but the names are sorted in a file
10.13.55 #       <B4gder> XavierGr: you mean you don't read the file, only move them around within the file?
10.15.02 #       <XavierGr> No, the file remains unchanged, I just move the pointers that hold the seek position of each name. The strings are never loaded into memory (except 2 strings each time in the comapre function)
10.15.22 #       <XavierGr> Maybe I can do that a little faster, but not much...
10.15.32 #       <B4gder> that's what the playlist code does
10.15.36 #       <B4gder> it is _waaaaay_ faster
10.15.43 #       <XavierGr> A different thread will make it run at least transparent.
10.16.02 #       <amiconn> XavierGr: Directly sorting a file will probably be way slower onm Ondio
10.16.19 #       <B4gder> oh well, it doesn't always sort them but anyway
10.16.38 #       <XavierGr> is it that I open and close the file inside the compare? I think i can just leave open the file and close it in the end of the sorting process.
10.16.39 #       <B4gder> I guess that's the reason
10.17.03 #       <B4gder> XavierGr: how do you do the sort in the first place? qsort() ?
10.17.05 #       <linuxstb> XavierGr: Why don't you store the list of files in memory, then sort, then write to disk - at least if it is possible to do so, which on the iriver I expect it would be 99% of the time.
10.17.09 #       <XavierGr> amiconn: we need to do some tests after I finish this.
10.17.36 #       <XavierGr> B4gder: yes I use qsort.
10.18.14 #       <XavierGr> linuxstb: Storing in memory 1000 * 20 names will eat all my plugin memory buffer, which I need to hold for the jpeg in order not to stop playback.
10.18.36 #       <linuxstb> Yes, but you can write them to disk _after_ sorting them.
10.18.58 #       <XavierGr> hmm and then flash that space eh?
10.19.01 #       <linuxstb> I'm assuming you load the file list before you load any images.
10.19.10 #       <XavierGr> yes
10.19.28 #       <linuxstb> Yes, and then you can free that space and use it for the images.
10.19.59 #       <XavierGr> sounds neat, I could try that.
10.20.12 Join    _FireFly_ [0] (n=icechat5@pd95b7c08.dip0.t-ipconnect.de)
10.20.28 #       <XavierGr> Hi _FireFly_.
10.20.44 #       <XavierGr> _FireFly_: and we were talking about sorting :)
10.24.52 #       <preglow> think i'll need to upgrade my bootloader soon
10.24.58 #       <preglow> now for finding a linux pc where i can do it
10.26.30 #       <linuxstb> preglow: If I remove the 5.5MB Apple firmware from my boot partition, then my Ipod will boot to the file browser in about 4 seconds.
10.26.42 #       <linuxstb> It was about 7-8 seconds with it.
10.26.48 #       <XavierGr> I will be damned. Moving the open, close file functions outside of compare functins dropped the sorting time from 18,5 seconds down to 3,5 seconds!!! Isn't this great? 
10.27.59 #       <_FireFly_> XavierGr ,9
10.28.01 #       <_FireFly_> ,9
10.28.04 #       <_FireFly_> ;)
10.28.17 #       <preglow> linuxstb: how the hell can it be so much faster
10.28.18 #       <preglow> ?
10.28.54 #       <linuxstb> The flash bootloader is obviously very slow at loading the boot partition.  It will also have to calculate and verify a checksum before executing it.
10.29.47 #       <linuxstb> But the good thing is that it doesn't do any check on the minimum size - I'm writing a 84KB boot partition and it's working perfectly.
10.31.08 #       <linuxstb> So I'm definitely in favour of putting the apple_os.bin file on the fat32 partition.  What do you think?
10.31.32 #       <linuxstb> It probably has less of an effect on your Nano, but I'm sure you will still notice a speed-up.
10.31.58 Join    San||Away [0] (n=sanitari@213-202-158-64.bas503.dsl.esat.net)
10.32.59 #       <linuxstb> You can test it by creating a dummy 512 byte file (e.g. dummy.bin), and then create a boot partition using "ipod_fw -g nano -o rockboot.bin -l dummy.bin bootloader.bin"
10.33.22 Join    saa[b_r]ider [0] (n=saab_rid@221.216.54.236)
10.44.08 #       <preglow> hrmph
10.44.08 #       <preglow> well
10.44.14 #       <preglow> i'm going to start working on a linux box soon
10.48.01 #       <linuxstb> Do you think we should try and fix loading the apple firmware via the boot partition, or just abandon that method and always load it from a file?
10.48.19 #       <preglow> loading from a file sounds just dandy to me
10.48.23 #       <preglow> if you need to make that file anyway
10.48.24 #       <preglow> which you do
10.48.39 #       <linuxstb> OK then.  I'm happy to to shave 4 seconds off my boot time to Rockbox.
10.49.34 #       <preglow> but okiedokie
10.49.42 #       <preglow> why the hell doesn't this work on your ipod
10.50.17 #       <linuxstb> I've tried the new button driver, and it's not as good as I would have hoped.  I added a loop in the bootloader that reads the key state and displays it, but it still doesn't always recognise a key that is pressed before the bootloader starts. 
10.50.41 #       <linuxstb> But I think it could be used to poll the button status if we wanted to write a polling button driver.  
10.51.18 #       <linuxstb> The code that's there only checks the 5 real buttons - it doesn't give a status for the scrollwheel.  But hopefully that can be added.
10.51.24 #       <preglow> hmm
10.51.30 #       <preglow> do we really want a polling driver?
10.51.39 #       <preglow> if you ask me, an interrupt driven one is better
10.51.48 #       <preglow> you only poll when you need to, and polling interval issues are gone
10.52.40 #       <linuxstb> Of course - an interrupt driven driver will be better. 
10.53.03 #       <preglow> hmm, i think i'll introduce the sleep loop again
10.53.10 #       <preglow> to see if the tick timer is really working
10.53.40 #       <linuxstb> OK.  Let me know if you want me to do any more tests.
10.54.22 #       <linuxstb> I'll try and make the bootloader changes later today.
10.55.58 #       <linuxstb> Anyone got any news about the forums?  I hope it's not a serious problem.
10.56.06 #       <XavierGr> what is working currently on rockbox for ipods?
10.56.22 #       <preglow> we'll see
10.56.26 #       <preglow> XavierGr: i am
10.56.31 #       <linuxstb> XavierGr: It boots up into the file browser, but there is currently no button driver.
10.56.34 #       <preglow> a lot of forums have been hacket lately
10.56.35 #       <preglow> hacked
10.56.45 #       <preglow> ahh, what, not who :-)
10.56.49 #       <linuxstb> :)
10.56.50 Join    tucoz [0] (n=martin@hornved.ii.uib.no)
10.56.58 #       <XavierGr> linuxstb: And how do you turn it off? :D
10.57.17 #       <linuxstb> You never turn the ipod off...
10.57.32 #       <linuxstb> But you press a key combination for a hardware-controlled reboot.
10.57.45 #       <linuxstb> This works even if Rockbox has crashed.
10.57.46 #       <preglow> woot, works even with that loop now
10.57.47 #       <XavierGr> also what do you think about audio on iPod. Will it be easy now that we have iriver targets working on that aspect?
10.58.05 #       <preglow> audio on ipod is going to need a lot of work
10.58.13 #       <preglow> to get it running on two cores, at least
10.58.32 #       <preglow> linuxstb: but okay, what's the status on ipod button mappings?
10.58.42 #       <XavierGr> it has a different DAC too, right?
10.58.48 #       <preglow> yes
11.00.02 #       <linuxstb> Those are pretty much finalised - see button.h.  In addition to the five buttons specific to the ipod, there is the generic BUTTON_LEFT and BUTTON_RIGHT
11.00.36 #       <tucoz> sorry for the off-topic, anyone familiar with dvd regions? I can play region 1 dvd's in linux, but when I try to play it in windows it tells me I only have 4 more region changes left. Is this shifting done in sw or the dvd-player hw?
11.00.51 #       <linuxstb> Both IIRC.
11.00.54 #       <tucoz> oh
11.01.07 #       <linuxstb> The DVD-ROM can have region settings, and so can the DVD playing software.
11.01.11 #       <tucoz> but linux doesn't care?
11.02.03 #       <linuxstb> I think it cares about the DVD-ROM settings (it can't affect them), so it sounds like it is just a software issue with your Windows player. 
11.02.26 #       <linuxstb> You can try a free Windows DVD player such as VLC - http://www.videolan.org/vlc
11.03.00 #       <tucoz> linuxstb, ok. good.  thanks. Then the dvd-rom is probably region free, but the player-sw is not.
11.03.06 #       <linuxstb> Yes, sounds that way.
11.03.15 #       <tucoz> thanks
11.03.40 #       <preglow> but ok, first, find out why it doesn't work with you
11.03.57 #       <preglow> what approach should we take to that? debug stuff before commit, or commit then debug? :)
11.04.24 #       <linuxstb> I would say commit then debug.  But commit in small stages if that's possible.
11.04.32 #       <preglow> sure
11.05.09 #       <tucoz> linuxstb, are you in london btw?
11.05.20 #       <linuxstb> tucoz: Yes.
11.05.23 Quit    San||Away (Read error: 110 (Connection timed out))
11.06.00 #       <tucoz> linuxstb, looks like the end of the world over there.
11.06.12 #       <Slasheri> Hmm, i think now the tagcache building should work on archos too :) And simple searches works now also
11.06.22 #       <tucoz> http://img.aftonbladet.se/nyheter/0512/12/londoncalling.jpg
11.07.42 #       <tucoz> Slasheri, cool. 
11.08.22 #       <Slasheri> It creates one temporary file when building the cache and then parses that file into 5 separate files with one master lookup table
11.08.48 #       <Slasheri> then it should be possible on some platforms load that structure into ram also
11.08.49 #       <tucoz> Slasheri, when adding or removing files to the player, will the tagcache rebuild the enitre db or just the add/remove the changes?
11.09.08 #       <Slasheri> tucoz: no, it can add files without completely rebuilding it
11.09.24 #       <tucoz> oh, that sounds good
11.09.34 #       <linuxstb> Is that part working yet?
11.09.53 #       <Slasheri> with dircache that rebuilding is automatic on boot, and without it manual start of database check is required
11.10.23 #       <Slasheri> linuxstb: building works and update worked too some time ago (but i just changed the structure a little), so it should be work quite well
11.11.24 #       <tucoz> I like the morse code input. Never thought that I would be able to learn morse, but it is actually a really good input method.
11.11.30 #       <preglow> tucoz: nice pic
11.11.41 #       <Slasheri> tucoz: hehe =)
11.12.01 #       <tucoz> preglow, it looks manipulated, but according to the news-article it is not.
11.12.08 #       <preglow> just what london needs, more smog
11.12.10 #       <amiconn> XavierGr: Building and sorting the list beforehand sounds good, however, the drawback is that you can't do it in the background (not a major concern imho)
11.12.13 #       <tucoz> hehe
11.13.40 ***     Saving seen data "./dancer.seen"
11.15.20 #       <tucoz> I think, if I would ever use the database is that it is built just the way Slasheri has done. I never get used to running a host-program to set up the database.
11.15.46 #       <tucoz> as I tend to remove and add stuff all the time, and do not have java on my computer :)
11.15.57 #       <B4gder> well, the java version is overbloated
11.16.04 #       <B4gder> imo
11.16.19 #       <XavierGr> amiconn: There are many things that I have to plan if I do that. 1) I must split the remaining plugin buffer into 2 parts. (fortunately I can predict where to split) 1 buffer for the pointer array and one for the filenames.
11.16.23 #       <tucoz> B4gder, well the perl script is probably nicer.
11.16.29 Join    Membrillo [0] (n=sam_kill@CPE-144-131-87-124.nsw.bigpond.net.au)
11.16.36 Join    Polo_o [0] (n=polo_o@82-69-160-166.dsl.in-addr.zen.co.uk)
11.16.39 #       <B4gder> I think this not only because I wrote the perl version
11.16.42 #       <preglow> the target way is nice in that it supports everything rockbox does
11.16.52 #       <XavierGr> amiconn: Then when the list is sorted into memory, I will have to change the pointer array values with the seek points of the file list.
11.17.00 #       <B4gder> "the proper way" would be to offer host host and target to do it
11.17.00 #       <preglow> and automatically
11.17.05 #       <preglow> yep
11.17.05 #       <B4gder> both
11.17.10 #       <XavierGr> then I can discard the data for the jpeg buffer.
11.17.12 #       <preglow> but in this case i'd really like to use the same code
11.17.17 #       <B4gder> preglow: indeed
11.17.21 #       <tucoz> B4gder, no. But the fact that I need a full JRE to build the database is not that nice.
11.17.24 #       <preglow> i wonder if it's possible to make get_metadata work for host as well
11.17.26 #       <B4gder> and that's why there's a start for db code in C in CVS
11.17.28 #       <preglow> that would be just dandy
11.17.38 #       <linuxstb> IIUC, Slasheri mentioned that it was faster to build the database on the iriver than on a PC.
11.17.40 #       <B4gder> preglow: that would be the best approach
11.17.54 #       <tucoz> really, hehe that is amazing
11.17.54 #       <B4gder> linuxstb: his code is faster than the current tools on PC, sure
11.18.02 #       <B4gder> blame the crc mania
11.18.08 #       <B4gder> which I doubt Slasheri uses
11.18.17 #       <B4gder> so his code can't do the runtimdb
11.18.17 #       <linuxstb> But I would expect the bottleneck to be the disk accesses, not the CPU.
11.18.28 #       <linuxstb> (apart from CRC of course)
11.19.09 #       <B4gder> well, I can't see how the target can be even close to host, speedwise, if they'd do the same thing
11.19.30 #       <B4gder> since both CPU and disk are waaay faster on host
11.19.33 #       <tucoz> I see, so title, album, artist is not good enough for the runtimedb?
11.19.35 #       <B4gder> and amounts of ram
11.19.41 #       <B4gder> tucoz: nopes
11.19.48 #       <tucoz> Why is that?
11.19.53 #       <B4gder> read up
11.19.56 #       <tucoz> sure
11.20.15 #       <B4gder> because HCl wanted it to survive changed tags
11.20.20 #       <B4gder> for example
11.20.45 #       <tucoz> I get it
11.21.02 #       <B4gder> personally I think it is overkill
11.21.10 #       <tucoz> It is the actual track that is the key here, not the meta-data.
11.21.14 #       <B4gder> yes
11.21.29 #       <B4gder> and that's why it does CRC on a chunk of the audio data
11.21.38 #       <B4gder> to use as key
11.21.45 #       <tucoz> I understand
11.22.24 #       <tucoz> Hmm, of course that has it's benefits but might be a little overkill yes.
11.22.56 #       <tucoz> I think the audioscrobbler way is good enough for me.
11.23.17 #       <Slasheri> in fact that crc code is not a solution for the runtimedb..
11.23.17 #       <XavierGr> what to choose for my big char array buffer, unsigned char, or simple char?
11.23.18 #       <preglow> which is?
11.23.28 #       <Slasheri> it only calculates the first 32 KiB of data or something like that
11.23.28 #       <B4gder> Slasheri: why not?
11.23.50 #       <B4gder> "only" 32kb
11.23.54 #       <Slasheri> so it's more than likely there will be more than one identical song the db sees
11.24.02 #       <B4gder> I doubt that
11.24.05 #       <Bger> ok, new version of the h300 lcd remote buttons patch is on the patchtracker
11.24.14 #       <B4gder> but I don't like that CRC approach anyway
11.24.38 #       <linuxstb> XavierGr: It depends what the functions using that buffer are expecting.  What are you storing in that buffer?
11.24.40 #       <tucoz> preglow, I believe audioscrobbler just records the artist-title, and adds to the db if the track has been played more than 50% or 2.5 minutes (whichever comes first)
11.24.53 #       <XavierGr> filenames
11.25.25 #       <Slasheri> B4gder: for example wav files without any tag entries and similar mixes at the beginning..
11.25.31 Join    mirak [0] (n=mirak@AAubervilliers-152-1-68-243.w86-198.abo.wanadoo.fr)
11.25.34 #       <linuxstb> Then you should use the same type as the string functions (strncmp, strlen etc) - i.e. char
11.25.34 #       <Slasheri> then db would see those as the same song
11.25.40 #       <B4gder> Slasheri: the db tools don't even work with wav files ;-)
11.25.46 #       <Slasheri> ah, hehe :D
11.25.54 #       <B4gder> tucoz: audioscrobbler is more naive than we can be
11.25.57 #       <XavierGr> linuxstb: ok thanks
11.27.09 #       <B4gder> Slasheri: still, using that lame CRC is more likely to find the song than you are without it
11.27.31 #       <tucoz> B4gder, ok
11.27.36 #       <B4gder> given the premises
11.27.42 #       <B4gder> but I think we should lower the goals
11.29.00 Join    yngwi [0] (n=chatzill@chello080109107064.1.15.vie.surfer.at)
11.29.04 #       <preglow> hmm
11.29.24 #       <linuxstb> B4gder: Are you suggesting we don't use a CRC at all?
11.29.25 Quit    yngwi (Client Quit)
11.29.55 #       <B4gder> I haven't fully thought about it properly to have a final suggestion, but I think I lean towards dropping the CRC yes
11.30.50 #       <linuxstb> The only alternatives I can think of is to use the path and filename (which can change) or the tags (which can be missing).
11.31.15 #       <B4gder> I know
11.31.22 #       <Slasheri> B4gder: Hmm, what will the current db do, if i move the song to another folder. Will it still keep the runtime data and find the song in future if the tagdb is rebuilt?
11.31.23 #       <linuxstb> It's not uncommon for someone to re-organise the files on their player.  So at least the paths will change.
11.31.39 #       <B4gder> Slasheri: yes, I think that's the plan
11.31.48 #       <Slasheri> It could be possible to add the crc or something similar identification to a separate tag index file
11.31.53 #       <Slasheri> ok
11.37.20 #       <tucoz> B4gder, did you have a look at the LaTeX stuff?
11.39.39 Join    DJDD_ [0] (n=DJDD@220-245-186-182.static.tpgi.com.au)
11.41.10 #       <preglow> linuxstb: btw, i don't remember if i disable the cop in my bootloader
11.41.24 #       <preglow> linuxstb: if that is so, it's a small wonder it doesn't work with you
11.43.05 Join    Delazon [0] (n=chatzill@h83n2fls34o981.telia.com)
11.44.54 Quit    Membrillo ()
11.45.50 #       <Delazon> Thanx boys for the release of rockbox for H3xx!!!
11.46.12 #       <_FireFly_> Delazon: there isn't yet an release for h1xx and h3xx yet
11.46.14 #       <Bger> Delazon there's no *release*
11.46.27 #       <_FireFly_> these are only testing builds :)
11.46.47 #       <_FireFly_> because not all functions are implemented or working correctly
11.48.02 #       <linuxstb> preglow: I'm running the CVS bootloader at the moment - I think it does wake up the cop
11.48.17 #       <preglow> try wrwapping the wakeup with an if 0
11.48.20 #       <preglow> that's what i have here
11.48.53 #       <preglow> i don't really know what we're waking it up to
11.48.56 #       <preglow> so i just let it sleep
11.49.10 #       * XavierGr *sighs* and imagines the day that he will see an iHP Icon on the Download Rockbox page....
11.49.12 #       <mirak> is it possible to put mp3 in an ogg container ?
11.49.31 #       <linuxstb> preglow: OK, trying now.
11.49.32 #       <amiconn> XavierGr: If you sort the file list in-memory, you can drop the pointer array too after writing the file. Just write the file sorted, then you can calculate the seek position
11.50.56 #       <Delazon> ok, i mean releasing a testbuild... i tested it and im elightend. It will be great when it?s finsished....
11.51.05 #       <Delazon> One question?
11.51.09 #       <linuxstb> preglow: Success :)
11.51.15 #       <Bger> Delazon just ask
11.51.18 #       <linuxstb> Backlight faded after about 3 seconds.
11.51.43 #       <Delazon> Will the user interface come in color or will it be in black and white all the time?
11.51.58 #       <mirak> anyone could send me a H300 V3 firmware ? I can't patch it on linux, I don't know what I am doing wrong
11.52.03 #       <linuxstb> Delazon: It is currently black and light-blue.
11.52.20 #       <LinusN> mirak: what happens?
11.52.30 #       <linuxstb> Delazon: But yes, Rockbox can be made in as many colours as you want - it just needs a developer to work on it.
11.52.38 #       <Delazon> Yes, you guy?s marks my words ;)
11.52.46 #       <Delazon> I mean monochrome then ;)
11.53.35 #       <tucoz> Delazon, it will be in color eventually
11.54.31 #       <Delazon> i switched back to iRiver fw for now... im a big radio listener, but when it?s released with full features i will swtich again. :D It was fun to test it.
11.54.59 #       <Delazon> And this function WPS... i like it alot... 
11.55.05 #       <Bger> LinusN what has to be done before having working radio on h300 ?
11.55.22 #       <LinusN> the i2c communication with the radio
11.55.25 #       <Delazon> Big chans to do your on stuff fairly easy.
11.55.34 #       <LinusN> i believe it uses different pins
11.55.44 #       <Bger> aha...
11.56.03 #       <Delazon> how manydevelopers are tou on this project?
11.57.38 #       <XavierGr> Reminds me that my radio patch stills sits idle that enables mutlipreset list handling...
11.58.24 Quit    DJDD__ (Read error: 110 (Connection timed out))
11.58.35 #       <tucoz> Delazon, I don't know how many active developers there are, but the credits list more than a hundred. (all of them are of course not active)
11.58.47 #       <XavierGr> amiconn: No, because if I don't hold the array with the seek possitions I will have to loop when I use a read_line(). (if I have the seek position I will just seek there first and read only 1 line)
11.59.09 #       <Delazon> cool many devs then :) many to thnx later on then i guess ;)
11.59.18 #       <amiconn> I thought you will use fixed field leghts...
11.59.47 #       <XavierGr> amiconn: I think it is better to avoid that for various reasons.
11.59.50 #       <preglow> linuxstb: i thought as much
11.59.50 #       <amiconn> Then seeking becomes icredibly simple.
12.00.01 #       <preglow> linuxstb: what's the default backlight time?
12.00.35 #       <Delazon> can i come with a suggestion?
12.00.42 #       <preglow> linuxstb: i'll let the if 0 stay in crt0.S when i commit
12.00.42 #       <XavierGr> amiconn: If I hold the seek positions it becomes simple too. I will just loose entries * sizeof(int) bytes from memory
12.00.50 #       <tucoz> Delazon, sure
12.01.25 #       <LinusN> the h300 lcd doesn't like dma...
12.01.32 #       <preglow> linuxstb: hooray
12.01.42 #       <amiconn> preglow: 4 seconds iirc
12.01.54 #       <preglow> ok, so the tick timer is probably off
12.02.01 #       <preglow> no surprise
12.02.13 #       <XavierGr> oh I have another problem: the range o an unsigned int is 0-65535 what if I need to go beyond that? Is it right to have longs?
12.02.27 #       <preglow> sure
12.02.40 #       <preglow> why shouldn't that be ok?
12.02.41 #       <Delazon> when i use the player and the display shuts down or going in to sleep. To wake it upp you have to push a button. I would be glad if this push would result in the display woke up without the button push would for an example paus the musik or go in to the browser mode or change the volume... as it is in the iRiver  FW.
12.02.51 #       <LinusN> XavierGr: int is 32-bit on all current rockbox platforms
12.03.05 #       <XavierGr> which means up to?
12.03.18 #       <preglow> 4 billion
12.03.19 #       <preglow> more than
12.03.31 #       <XavierGr> ~4 millions?
12.03.40 #       <amiconn> int *can* be 16bit, but we don't need to care
12.03.50 #       <XavierGr> oh isn't this great!
12.03.51 #       <LinusN> Delazon: you want the first push to only enable the lcd?
12.03.55 #       <amiconn> There can't be more than 65536 files in a FAT directory
12.04.00 #       <tucoz> Delazon, I like that idea as well. I normally use the record button for that, but I think it would be better if the first key press would wake up the lcd.
12.04.02 #       <Delazon> Yes exatly :D
12.04.02 #       <merbanan> 2raised by 32 for unsigned
12.04.18 #       <preglow> LinusN: can you imagine any reason why i wouldn not want to use interrupts when implementing button driver?
12.04.28 #       <LinusN> preglow: no
12.04.40 #       <amiconn> ...and even 65536 files are only possible if none of them has long names
12.05.47 #       <XavierGr> amiconn: seek position can be larger than 65535.
12.05.56 #       <amiconn> Ah, yes
12.06.06 #       <amiconn> Should be a long then
12.06.34 #       <XavierGr> but Linus said that an int is considered 32 bit
12.06.41 #       <XavierGr> no?
12.07.18 #       <preglow> int is sometimes considered 32 bits
12.07.20 #       <preglow> most often, perhaps
12.07.22 #       <preglow> but it can be 16
12.07.26 #       <preglow> if you need more than 16, use long
12.07.38 #       <XavierGr> so how would I know?
12.07.42 #       <preglow> you don't
12.07.45 #       <preglow> there are no guarantees
12.07.58 #       <preglow> you also have int32_t, of course
12.08.03 #       <preglow> which is always guaranteed to be 32 bits
12.08.12 #       <preglow> but those aren't recommended for use in rockbox, for some reason
12.08.14 Join    muesli- [0] (n=muesli_t@141.71.4.180)
12.08.31 #       <XavierGr> hmm long is double the bytes of  an int, yes?
12.08.35 #       <XavierGr> 8bytes?
12.08.37 #       <preglow> 4
12.08.42 #       <preglow> long == int for most pplatforms
12.08.54 Quit    muesli- (Client Quit)
12.09.16 #       <XavierGr> so I don't need to change sizeof(int) to sizeof (long int) right?
12.11.42 Join    Bger_ [0] (n=Bager@83.222.160.88)
12.12.13 Quit    Bger (Nick collision from services.)
12.12.20 Nick    Bger_ is now known as Bger (n=Bager@83.222.160.88)
12.12.59 Join    webguest54 [0] (n=5087d10e@labb.contactor.se)
12.13.07 #       <Bger> Delazon 
12.13.13 #       <Bger> use Rec button
12.13.21 #       <Bger> for only lighting the LCD
12.13.54 #       <webguest54> is the db scale (which I like), realtive to line out, and if so is line out taken before amplification or after ?
12.14.18 #       <Bger> while on this topic, is there any reason for the rec button doesn't have any function ?
12.14.39 #       <preglow> what's the declaration specs for a naked function, again
12.14.40 #       <preglow> ?
12.14.57 #       <LinusN> Bger: no
12.15.23 #       <preglow> webguest54: relative to line out? it is relative to max level, regardless of output
12.15.47 Join    webguest58 [0] (n=5087d10e@labb.contactor.se)
12.15.48 Quit    webguest54 (Client Quit)
12.15.53 #       <webguest58> ugghh
12.15.55 #       <Bger> XavierGr u should use sizeof(long int) if u use long int var ...
12.16.17 #       <linuxstb> preglow: What's a "naked function" ?
12.16.43 #       <preglow> linuxstb: a function without any wrapping code added by the compiler, afaik
12.16.55 #       <preglow> linuxstb: like implicit return instruction, i want to use my own return instruction
12.17.05 #       <Bger> hm, one more question
12.17.16 #       <preglow> arm gets pretty fancy with its exception handler return methods
12.17.36 #       <Bger> what about making some button (like ON/play) to light the screen even when the hold button is turned on ?
12.17.55 #       <webguest58> preglow:, thanks for the db info, now, is line out pre or post amplifier ?
12.18.01 #       <preglow> Bger: i wouldn't want to waste my battery for the backlight when my hold is on
12.18.07 #       <preglow> webguest58: post
12.18.17 #       <preglow> webguest58: only outputs that are pre-amp is optical out
12.18.17 #       <Bger> preglow even on nano ?
12.18.28 #       <preglow> Bger: why even on nano?
12.18.41 Nick    Lynx_awy is now known as Lynx_ (n=lynx@tina-10-4.genetik.uni-koeln.de)
12.18.42 #       <Bger> hm, i don't know whether nano has hold button
12.18.54 #       <preglow> it does
12.18.55 #       <Bger> but it has color LCD
12.19.01 #       <preglow> it does
12.19.06 #       <webguest58> so to achieve best line out output the volime should be set to max ?
12.19.15 #       <Bger> and u cant see the display with backlight off ...
12.19.16 #       <preglow> but if i enable hold, it is for a reason: i keep it in my pocket, and buttons might be pressed all the time
12.19.20 #       <preglow> which means the backlight might be constantly on
12.19.24 #       <preglow> i don't want that
12.20.11 #       <Bger> hm, my GSM brings the backlight on when i press the "call" button and i like this ...
12.21.16 #       <Bger> i mean even when the keypad is locked
12.21.59 #       * Bger whispers "new option" and goes to the corner
12.22.45 #       <Jungti1234> hey guys
12.23.31 #       <Bger> yes, Jungti1234 
12.23.35 #       <Jungti1234> Where is Rockbox option saved?
12.23.51 #       <Bger> on the hard disk
12.24.01 #       <Jungti1234> hmm..
12.24.03 #       <Bger> but in one sector out of the file system
12.24.17 #       <Jungti1234> where?
12.24.30 Part    webguest58
12.24.49 #       <LinusN> sector 62
12.25.30 #       <Jungti1234> How do I do to delete it?
12.25.42 #       <Delazon> ok thanx for your answers on the lcd matter...
12.25.49 #       <Bger> Jungti1234 : if you have problems with your settings, you can reset them with pressing "rec" key while booting rockbox
12.25.54 #       <Bger> or from the menu
12.26.22 #       <Bger> Manage settings->reset settings
12.26.33 #       <Jungti1234> ah thanks
12.28.42 #       * Bger remembers one of the first days of rb on h300, when he enabled the dircache and the unit self powered off right after booting because of the button driver problems...
12.29.13 Part    LinusN
12.32.35 #       <preglow> why would i get an interrupt from the ide controller?
12.34.29 #       <linuxstb> Mmm.  I guess they haven't been disabled.  I have no idea what the four cryptic lines in ata_init do.
12.35.15 Part    tucoz ("Leaving")
12.37.25 Join    webguest97 [0] (n=d5bd9d85@labb.contactor.se)
12.37.38 #       <preglow> no, but anyway
12.37.42 #       <preglow> why would i get it?
12.37.52 #       <preglow> if i'm expecting data, i guess i should know about it
12.37.54 #       <preglow> having requested it and all
12.38.04 #       <preglow> then again, there's the latency, of course
12.38.33 #       <webguest97> would it be possible to attach a different screen to the h-1x0 player via the remote output?
12.38.42 #       <linuxstb> preglow: So when are you getting the interrupt?
12.39.01 #       <webguest97> i mean is the resolution given by the player or by the remote itself?
12.40.16 #       <preglow> linuxstb: i don't know if i'm getting it
12.40.25 #       <preglow> linuxstb: i'm just wondering to what degree i'm going to bother with it it all
12.40.28 #       <preglow> it at all
12.42.17 Quit    DJDD_ ("Trillian (http://www.ceruleanstudios.com")
12.43.15 #       <linuxstb> Do you know what IPL does?
12.43.23 #       <preglow> not in the least
12.44.24 Join    San||Away [0] (n=sanitari@213-202-153-202.bas503.dsl.esat.net)
12.45.33 Quit    webguest97 ("CGI:IRC (EOF)")
12.46.50 #       <linuxstb> preglow: If we wanted to cheat with the timing of the ticker interrupt, we could update the current_tick variable by using the value in the RTC variable we are currently using to simulate the current_tick.
12.46.59 #       <linuxstb> I don't know how accurate the timer needs to be for other purposes.
12.48.04 #       <preglow> well, yeah, we could
12.48.10 #       <preglow> but i'd rather do it properly first
12.48.13 #       <preglow> then we'll see
12.48.16 #       <mirak> hem, how do I make the tools now ?
12.48.21 #       <mirak> something have changed ?
12.48.32 #       <preglow> you type 'make' in your build dir
12.48.48 #       <mirak> preglow: after running a full configure ?
12.49.05 #       <preglow> yea
12.49.24 #       <mirak> what devel option change ?
12.49.27 Part    Polo_o
12.49.28 #       <mirak> debuging ?
12.50.21 Join    Polo_o [0] (n=polo_o@82-69-160-166.dsl.in-addr.zen.co.uk)
12.51.51 #       <linuxstb> preglow: So you don't think it will be a problem to get the timer tick accurate?
12.52.41 #       <preglow> linuxstb: the answer to that question depends a lot on how tricky cpu freq change is
12.53.07 #       <preglow> but no, let's just try this approach first
12.53.11 #       <preglow> i'll see about doing some commiting now
12.54.59 #       <linuxstb> Do you update the current_tick variable yet, or have you left that the way it is?
12.59.42 #       <preglow> i update it
13.00.37 Join    Rob2222 [0] (n=Miranda@ACB60B8C.ipt.aol.com)
13.02.35 Quit    _FireFly_ ("IceChat - Its whips the llama's butt")
13.03.56 #       <XavierGr> in rockbox: char = 2bytes, long int = 4bytes.  Please correct me if I am wrong.
13.04.27 #       <B4gder> wrong
13.04.32 #       <B4gder> char = 1 byte
13.04.38 #       <mirak> how does the lcd screen is represented in memory ? is it just an offset that you set and wich is located into ram, or does it have it's own ram ?
13.04.57 #       <B4gder> mirak: we have a framebuffer that represents what the LCD looks like
13.05.06 #       <B4gder> mirak: lcd_update() writes that framebuffer to the actual hw
13.05.26 #       <mirak> B4gder: the buffer size depends of the device it's been compiled on
13.05.29 #       <mirak> ?
13.05.31 #       <B4gder> yes
13.05.53 #       <mirak> wich file is it defined ?
13.05.57 #       <B4gder> and even how the frame buffer is layed out
13.06.07 #       <B4gder> check firmware/drivers
13.06.11 #       <B4gder> and the lcd*.c files
13.06.12 #       <mirak> thanks
13.09.28 #       <XavierGr> B4gder: and what about char* and long int*?
13.09.36 #       <B4gder> 32 bits
13.09.59 #       <XavierGr> so 4bytes both.
13.10.06 #       <B4gder> yes
13.10.21 #       <B4gder> but you should use sizeof() of course, if your code relies on the size
13.10.32 #       <XavierGr> yes of course
13.10.37 #       <XavierGr> ^course
13.11.50 #       <XavierGr> I have a plugin memory orgie right now. I have to set 3 buffers, at least in the end only 1 will be left.
13.13.41 ***     Saving seen data "./dancer.seen"
13.14.52 Quit    Delazon ("Chatzilla 0.9.68.5.1 [Firefox 1.5/undefined]")
13.15.59 #       * B4gder debugs code booting from flash without any kind of hw attached... tedious and painful are words that pop up
13.16.11 #       <B4gder> debug-hw I mean
13.20.11 #       <mirak> what does it mean when there is only a line with  (void)data; 
13.20.12 #       <mirak> ?
13.20.24 #       <B4gder> that the variable isn't used
13.20.27 #       <linuxstb> It's used to stop the compiler complaining.
13.20.41 #       <mirak> so that's a dummy method
13.21.00 #       <mirak>  /* TODO: Implement lcd_blit() */
13.21.05 #       <mirak> I gues it is :)
13.21.18 #       <B4gder> its not a "method"
13.21.22 #       <B4gder> it is a variable
13.21.34 #       <linuxstb> That's probably misleading - I don't think that function is on the to-do list.  It probably won't be needed for colour LCDs.
13.23.43 #       <Bger> B4gder could you see patch No 1378064 ? i think it's ok ...
13.23.53 #       <Bger> (sokoban h300 updates)
13.24.08 #       <B4gder> no time atm
13.24.14 #       <Jungti1234> hmm
13.24.26 #       <Bger> okay :(
13.25.13 Join    webguest37 [0] (n=5087d10e@labb.contactor.se)
13.25.28 #       <webguest37> Febs: are you around ?
13.25.57 #       <Jungti1234> bad australian
13.25.59 #       <webguest37> uggh, should open my eyes and look right --->>
13.26.35 #       <webguest37> however
13.26.44 #       <Jungti1234> Do they do racism yet?
13.26.45 #       <mirak> B4gder: color is limited to 16bits ?
13.26.50 #       * webguest37 does magical dance to summon Febs
13.26.50 #       <B4gder> yes, atm
13.29.29 Part    webguest37
13.31.22 #       <saa[b_r]ider> custom H300 LCD colors :) http://www.misticriver.net/photos/albums/userpics/12162/Custom%20LCD%20colors.jpg
13.31.49 #       <saa[b_r]ider> (this is an actual screendump, not from a simulator)
13.32.57 #       <B4gder> I still wait for a background image and alfa blended text on top ;-)
13.33.38 #       <preglow> ugh
13.33.42 #       <preglow> crt0.S is becoming a royal mess
13.34.12 Join    mikearthur [0] (n=mike@82-41-227-152.cable.ubr11.edin.blueyonder.co.uk)
13.34.36 #       <B4gder> how come?
13.34.45 #       <mirak> B4gder: what is the reason to use 16bits instead of the 18 ?
13.34.48 #       <preglow> well
13.34.50 #       <preglow> some general arm code
13.34.53 #       <preglow> some PP specific code
13.34.57 #       <preglow> some code that only goes in the bootloader
13.35.12 #       <B4gder> mirak: why use 18bits when most of the UI only uses two colors?
13.35.42 #       <mirak> B4gder: why do you answer that ?
13.35.43 #       <B4gder> apart from the apparent reason that of course 16bits is much faster than 18
13.35.49 #       <mirak> I want to to know what are the technical reasons
13.35.51 #       <B4gder> mirak: ?
13.35.57 #       <B4gder> no there aren't
13.36.08 #       <mirak> ok
13.36.16 Quit    Bger ("Don't squeeze the BitchX")
13.36.23 #       <mirak> so just changing the lcd depth would make it ?
13.36.33 #       <B4gder> no
13.36.41 #       <B4gder> you need to fix the code too
13.37.04 Join    Bger [0] (n=Bager@83.222.160.88)
13.38.01 #       <B4gder> like most things in Rockbox it can be extended to become better if you just feel for it
13.38.12 #       <B4gder> and have the skill
13.44.14 #       <preglow> linuxstb: but ok, so far, i won't enable interrupts in bootloader
13.45.28 #       <amiconn> I don't think 18 bit support for H300 would be wise, as 16bit is kinda slow already...
13.45.34 #       <preglow> idneed
13.45.51 #       <B4gder> only for some special mode if so
13.45.59 #       <B4gder> like jpeg viewer mode or similar
13.46.19 #       <amiconn> I'd rather want to avoid LCD mode switching
13.46.24 #       <B4gder> if you happen to have a jpeg with only blue shades or something ;-)
13.47.03 #       <B4gder> we have different "modes"already with the greyscale lib
13.47.45 #       <B4gder> but I don't think of 18bit as particularly important
13.48.07 #       <amiconn> The grayscale lib doesn't switch the LCD mode, it works on top of that
13.48.25 #       <B4gder> yes, but it is a different graphic mode
13.49.12 #       <mirak> #define _RGBPACK(r, g, b) ( ((((r) * 31 + 127) / 255) << 11) \
13.49.23 #       <mirak> wouldn't it be faster to just use shifts ?
13.49.50 #       <mirak> plus mask and a or to mix all colors
13.49.53 #       <mirak> a mask
13.50.40 #       <amiconn> mirak: Shifts are imprecise
13.50.49 #       <mirak> amiconn: what do you mean ?
13.50.54 #       <amiconn> Plus, this #define is evaluated at build time
13.50.57 #       <preglow> hmmm
13.50.58 #       <preglow> what the hell
13.51.00 #       <preglow> how can this work
13.51.08 #       <preglow> ahh, right, forget me
13.51.41 #       <amiconn> mirak: I mean that the conversion between bit depths can't be done with shifts only. It wouldn't be precise
13.52.02 #       <mirak> amiconn: explain that
13.52.10 #       <mirak> please :)
13.52.13 #       <preglow> linuxstb: for consistency, we might want to have the bootloader remap memory as well, but i don't know how the apple firmware, or even linux, will take to suddenly run at address 0x0
13.52.49 #       <mirak> amiconn: the color passed to the argument are between 0 and 255 ?
13.52.55 #       <amiconn> yes
13.53.25 #       <mirak> ok te method try to rescale to a 5bits ?
13.53.27 #       <mirak> for exemple
13.53.59 #       <mirak> amiconn: ?
13.54.14 #       <mirak> a 5 bits intervals for red and blue
13.55.17 #       <mirak> chunking just the low bits should do it for me
13.55.35 #       <linuxstb> preglow: Are you saying you map the DRAM to address 0x0 ?
13.55.46 #       <preglow> yep
13.56.07 #       <linuxstb> Mmm.  That will make rolo-ing the Apple firmware or Linux tricky.
13.56.13 #       <preglow> why?
13.56.15 #       <linuxstb> Unless it's easy to map it back.
13.56.16 #       <preglow> ahh
13.56.18 #       <preglow> it is
13.56.22 #       <preglow> that is
13.56.24 #       <preglow> i have no idea how
13.56.27 #       <linuxstb> :)
13.56.33 #       <preglow> or rather, how, but not what to write
13.56.45 #       <linuxstb> I assume the IRAM stays where it is?
13.56.48 #       <preglow> it's just a couple of registers
13.56.50 #       <preglow> iram stays
13.56.52 #       <preglow> everything stays
13.56.58 #       <preglow> but sdram, and flash, obviously
13.57.01 #       <preglow> which we can't access after this
13.58.09 #       <linuxstb> But I assume that the rolo function (which is in iram already) can change it?
13.58.39 #       <linuxstb> Or the bootloader could change it back before executing Linux or the Apple firmware?
13.59.48 #       <preglow> sure, just need to find out how
14.00.09 #       <preglow> this is the same way of doing things ipl does
14.00.17 #       <preglow> there is another mecanism for pp5020, it seems
14.00.22 #       <preglow> but not for pp5002
14.00.31 #       <preglow> and this way is consistent with how other arms do it
14.00.36 #       <preglow> so we can share some code
14.00.59 #       <linuxstb> I am happy to  forget about the pp5002 for now - a lucky owner of such a device can solve those problems.
14.01.11 #       <mirak> amiconn: wouldn't this be enough ? (((r) >> 3 ) << 11 ) & (((g) >> 2 ) << 5 ) & ((b) >> 3 )  
14.01.38 #       <preglow> linuxstb: well, now at least this part is working
14.01.46 #       <preglow> linuxstb: and besides, i never could get the other method to work
14.01.57 #       <preglow> linuxstb: ipl people haven't researched it too much, since they don't use it
14.02.17 #       <mirak> I mean if the color is from 0 to 255 on 8 bits, if you want to reduce to 6 or 5 bits, you are forced to lose precision in the color.
14.02.22 #       <linuxstb> mirak: As amiconn said, the shifts are inprecise - they always round down
14.02.55 #       <mirak> linuxstb: ok I see
14.03.01 #       <preglow> arghhh
14.03.04 #       <preglow> now it doesn't work anymore :/(
14.03.09 #       <linuxstb> And it's a macro that's designed to be use at compile-time, so the speed doesn't matter.
14.03.17 #       <mirak> linuxstb: I wasn't figuring the rounding down
14.03.39 #       <Bger> hm, guys, anything other than unix2dos and dos2unix ?
14.03.51 #       <linuxstb> iconv or recode
14.04.03 #       <linuxstb> (I'm not sure about iconv....)
14.04.16 #       <linuxstb> (in fact, forget i mentioned it...)
14.05.07 #       <Bger> 10x :)
14.05.07 #       <B4gder> Bger: to do what?
14.05.15 #       <Bger> just to ask you about iconv ...
14.05.16 #       <preglow> ahah
14.05.25 #       <preglow> i just built a rockbox that rebooted on start
14.05.38 #       <Bger> B4gder i want to convert one patch from dos to unix eol format
14.07.15 #       * B4gder uses tr for that
14.09.00 #       <Bger> hm, good idea
14.09.41 #       <B4gder> I actually have a perl script too, but that's mostly for windows-versions of diff that produces the drive letter and backward slashes in the diff -u output
14.10.10 Join    linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net)
14.10.13 Join    muesli- [0] (n=muesli_t@141.71.4.218)
14.10.20 Quit    linuxstb (Nick collision from services.)
14.10.29 Nick    linuxstb_ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net)
14.10.34 #       <Bger> aha:)
14.10.34 #       <XavierGr> GOD!!!!! I am gonna rip my hairs out!!!!
14.10.56 #       <Bger> this snow.c patch is awful ...
14.11.02 #       <XavierGr> I can't make the pointers work
14.11.44 Join    dropandho [0] (n=dropandh@cpe-24-193-36-91.nyc.res.rr.com)
14.12.01 #       <dropandho> hey all
14.12.08 #       <dropandho> any news regarding the forums?
14.12.20 #       <B4gder> Jeff is not here
14.12.37 #       <dropandho> got it
14.12.46 #       <dropandho> there have been some attempts to reach out to him
14.12.53 #       <dropandho> so i was hoping something came of that
14.13.02 #       <XavierGr> I have 2 char* pointers how can the one pointer the other? Or one of 2 must be **pt?
14.13.04 #       <B4gder> not to my knowledge
14.13.32 #       <B4gder> XavierGr: I don't understand the question
14.13.32 #       <dropandho> darn
14.14.39 #       <Bger> XavierGr if you have char *pt1,*pt2;
14.14.53 #       <Bger> then u just make pt2=pt1; and it's done
14.16.25 #       <preglow> hahaha
14.16.39 #       <preglow> now, why did i disable backup files in vim...
14.16.41 #       <XavierGr> I will describe it better. I have 2 buffers. 1) The first holds all the strings (char *names) 2) (Let's name that str_pt) The second has the places where each string starts in "names". I want every time names get another element to be pointed by str_pt.
14.17.10 #       <XavierGr> preglow: dont tell me?
14.17.30 #       <XavierGr> you lost your work?
14.17.37 #       <preglow> nah
14.17.39 #       <preglow> just a tiny bit
14.17.44 #       <preglow> will be back in a jiffy
14.17.47 #       <Bger> XavierGr so you need an array of pointers to char iiuc
14.18.10 #       <XavierGr> yes
14.18.23 #       <Bger> like char *str_pt[MAX_NAMES];
14.18.40 #       <Bger> str_pt[i]=names[j] etc ...
14.19.01 #       <XavierGr> no because I can't be sure how many I will have
14.19.16 #       <XavierGr> so I use a buffer for that too
14.19.52 #       <B4gder> you need a max value anyway
14.19.52 Join    DjDeaf [0] (i=DjDeaf@87.68.156.125.cable.012.net.il)
14.20.24 #       <DjDeaf> hello
14.20.30 #       <Bger> XavierGr : as u already know, rb doesn't have dynamic memory allocation
14.20.40 #       <XavierGr> Bagder: Yes but at least I will get that value during runtime.
14.20.44 #       <Bger> so, whether u want or not, u must assume some limit
14.21.04 #       <XavierGr> The limit comes when the code is running
14.21.13 #       <DjDeaf> hi i have a problem can abyone help me?
14.21.22 #       <Bger> DjDeaf just ask
14.21.30 #       <DjDeaf> ive installed rockbox
14.21.36 #       <DjDeaf> on h340
14.21.41 #       <Bger> noone can help you if (s)he doesn't know what's the problem
14.21.42 #       <XavierGr> but let me think it over again.
14.21.55 #       <DjDeaf> and when im accessing the menu
14.22.08 #       <DjDeaf> i cant see it , the text is blank
14.22.09 #       <Bger> XavierGr if the limit comes runtime, then u want dynamic memory alloc. ..
14.22.24 #       <Bger> DjDeaf any language ?
14.22.26 #       <Bger> set
14.22.31 #       <Bger> different from english ?
14.22.36 #       <Bger> or any font set ?
14.22.40 #       <DjDeaf> maybe i didnt notice
14.22.45 #       <DjDeaf> its in the originalk theme
14.22.52 #       <Bger> hm
14.23.14 #       <preglow> ok, commited exceptions
14.23.16 #       <Bger> i suggest u to stop and start the unit and hold the "rec" button while it's booting
14.23.35 #       <Bger> but not too early, otherwise u'll start the iriver fw
14.23.40 Quit    dropandho ()
14.23.51 #       <DjDeaf> ok i did it
14.24.00 #       <Bger> B4gder am i right in using tr -d "\r" < dos_formatted_file > unix_formatted_file
14.24.07 #       <DjDeaf> oh here, it works
14.24.12 #       <DjDeaf> thanks :)
14.24.26 #       <Bger> DjDeaf np ... this resets all settings, it was added recently
14.24.36 #       <DjDeaf> and another tiny question, it there video on images option on rockbox?
14.24.42 #       <DjDeaf> or
14.24.50 #       <Bger> video : not
14.25.19 #       <Bger> images also, but they will come in a more short period
14.25.49 #       <XavierGr> Bger: Excuse me but when I run a plugin I have a big chunk of memory available to do anything I like. Maybe it is called dynamic memory allocation, but anyway rockbox lets me to do anything I like with that left memory in the end.
14.26.16 #       <Bger> XavierGr it has statical limit, so it's statical
14.26.40 Join    linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net)
14.26.45 Quit    linuxstb (Nick collision from services.)
14.26.48 Nick    linuxstb_ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net)
14.26.54 #       <XavierGr> statical?
14.26.59 #       <preglow> linuxstb: care to test what's in cvs now?
14.27.05 #       <linuxstb> XavierGr: you could store your strings starting from the start of the buffer, and the array can work back from the end.
14.27.11 #       <Bger> u can use all this memory to make an array and after that use this array in the way u want
14.27.22 #       <preglow> here filebrowser starts, but then just stands there looking silly
14.27.36 #       <Bger> yep, something like the linuxstb's note
14.27.43 #       <linuxstb> preglow: Hasn't it always done that? :)
14.27.44 #       <preglow> but then again, i've got some further changes
14.27.58 #       <preglow> linuxstb: perhaps, i've forgotten how it behaves in cvs, heh
14.28.32 #       <XavierGr> guys I think I fixed what I wanted, one of the char pointers had to be char **str_pt
14.28.35 #       <preglow> linuxstb: but anywho, as long as it doesn't lock up
14.28.48 #       <linuxstb> preglow: I'm testing now.
14.28.48 #       <Bger> XavierGr ... i don't think so
14.28.50 #       <XavierGr> It is just annoying that I haven;t clearly understand how pointers work.
14.28.55 #       <Bger> do u initialize the pointers ?
14.29.10 #       <Bger> see, before you use any pointer, u must initialize it
14.29.21 #       <XavierGr> yes
14.29.32 #       <Bger> so, how do u initialize it ?
14.29.54 #       <XavierGr> these pointers get always a start address from the end memory of plugin buffer.
14.30.06 #       <Bger> char **str_pt; means pointer to pointer to char
14.30.12 #       <XavierGr> (different according to my use)
14.30.22 #       <XavierGr> yes
14.30.26 #       <Bger> so u must assign something to str_pt
14.30.32 #       <XavierGr> that's what I wanted after all, it is just that I am not sure about it.
14.30.52 #       <mirak> linuxstb: ok, I will insist a bit ^^. For me the precision doesn't matter. What the actual thing is doing is considering that the colors below and above in fixed interval can be assimilated to that color. But in reality the colors truncated with a right shift are considered to be a subset of a base color. For exemple with what you are doing with 6 bits for a taint, the color 0 have a subset of colors of 2 colors {000 001
14.30.52 #       <mirak> } while the color 100 have a subset of {010,011,100,101}
14.30.56 #       <Bger> i mean, str_pt must point to free memory
14.31.00 #       <XavierGr> yes I assign a position from the other buffer
14.31.11 #       <Bger> ok
14.31.53 #       <XavierGr> I must read a very good tutorial about pointers which covers all strange situations.
14.31.54 #       <mirak> truncation is the way to go for colors
14.33.16 #       <mirak> imho. It was this approach wich was used on Atari ste when they extended the color range
14.33.17 #       <linuxstb> preglow: Your CVS changes make no difference to how Rockbox behaves :).  Which is a success I think.
14.33.36 #       <Bger> XavierGr : really, it's simple
14.33.37 #       <preglow> linuxstb: indeed, then i shall queue forth a new set of changes
14.33.48 #       <preglow> linuxstb: btw, what to do about the yield issue? :/
14.33.55 #       <mirak> linuxstb: very intersting ;D
14.34.05 #       <Bger> u just must know that the pointer is a var that points to other var
14.34.14 Join    amar [0] (n=502c706b@labb.contactor.se)
14.34.31 #       <Bger> and u must give the pointer a valid address
14.35.41 #       <XavierGr> Bger: I know that, but sometimes I get confused by the indirection.
14.36.28 #       <Bger> then u just need more practice
14.36.29 #       <Bger> ;)
14.36.41 #       <mirak> 0,8 should be considered as 0 and not 1 for the same reason that the color 255 will not be rounded up, because it's just impossible to go above 255.
14.36.43 #       <linuxstb> mirak: I don't really have any views about that macro - amiconn wrote it.  But I think it may have something to do with making the reverse operation possible (i.e. rgb565 to rgb888).  If you do the reverse operation by simply shifting, then you don't get pure white any more.
14.37.29 #       <linuxstb> But as I say, I'm not the person you should be talking to.
14.39.24 #       <mirak> linuxstb: that's the inevitable boundary effect
14.39.33 Join    Kohlrabi [0] (n=Kohlrabi@dslb-082-083-129-115.pools.arcor-ip.net)
14.40.02 Join    Mmmm [0] (n=54433cd7@labb.contactor.se)
14.40.05 #       <mirak> do you know how the screen manage colros internaly ?
14.40.20 #       <mirak> does it use one byte per colors, or is packed ?
14.40.38 #       <mirak> to save bits
14.41.07 Quit    Mmmm (Client Quit)
14.41.11 #       <B4gder> it is packed
14.41.19 #       <B4gder> the framebuffer uses lcd native format
14.41.48 Join    Mmmm [0] (n=54433cd7@labb.contactor.se)
14.41.51 #       <B4gder> afaik
14.42.02 #       <mirak> B4gder: ok so you can control the depth of the lcd screen ?
14.42.10 #       <B4gder> ?
14.42.25 Quit    Mmmm (Client Quit)
14.42.43 #       <mirak> the screen uses 18 bits colors, rockbox 16 bits, something doesn't match :)
14.42.55 #       <B4gder> the LCD is programmable
14.43.00 Part    Sando
14.43.02 #       <B4gder> rockbox sets it in 16bit mode
14.43.05 #       <B4gder> voila
14.43.09 Join    Sando [0] (n=lolsteam@techgaming.net)
14.43.12 #       <mirak> ok thank you
14.43.22 #       <mirak> B4gder: is there some docs about that ?
14.43.31 #       <B4gder> the source code and the lcd datasheet
14.44.52 #       <mirak> this reminds me my atari days, where programming was very close from the hardware
14.45.26 #       * B4gder never left that :-)
14.45.29 #       <linuxstb> mirak: I believe the LCD controller uses 18bpp internally, but it can work in a 16bpp where the missing two bits are just set to (I think) 1.
14.45.45 #       <linuxstb> (i.e. the least significant red and blue bits)
14.45.58 #       <linuxstb> As B4gder said, the lcd datasheet describes it.
14.46.13 #       <mirak> k
14.46.22 Quit    San||Away (Read error: 104 (Connection reset by peer))
14.47.09 #       <XavierGr> Are we sure that iriver uses 18 bit colors?
14.47.17 #       <XavierGr> maybe they use 16 too. :D
14.47.19 #       <mirak> how was it possible to find wich system adress were coresponding to this or that device ?
14.47.37 #       <XavierGr> Who can tell?
14.47.44 #       <B4gder> XavierGr: we're not sure no, I doubt anyone cares enough to figure it out
14.47.56 #       <B4gder> mirak: hard work
14.48.26 #       <XavierGr> Then they say that their product shows 18bit colours so.... it could get them into trouble if not.
14.48.28 #       <mirak> XavierGr: yep, anyway since the screen resolution is around 5 times less than traditional screens resolution with a 24 bits depth, I don't think that any image converted to that resolution can display that much color nuances
14.48.59 #       <mirak> so yes 16bits colors is not much of loss probably
14.49.12 #       <B4gder> I think you should be able to tell
14.49.17 #       <linuxstb> Anyone heard anything more from the person working on the iFP790 port?  He doesn't seem to have updated the wiki or his website since his initial announcement.
14.49.20 #       <B4gder> if you make a pic with a gradient blue only
14.50.37 #       <XavierGr> I will make the same discussion then: Does human eye has a measurable colour range?
14.51.09 #       <XavierGr> (The range is known, I think)
14.51.17 #       <XavierGr> but how manu increments?
14.51.26 #       <g33> i have a suggestion for filebrowsing... dunno how easy it is to implement though.. 
14.51.38 #       <mirak> XavierGr: that's subjective and depend of persons
14.52.02 #       <mirak> XavierGr: there is probably a physiological limit
14.52.05 #       <preglow> B4gder: just doing MY_ADDR; on a volatile address will read it, yes?
14.52.26 #       <XavierGr> mirak: yes that's what I am talking about.
14.52.50 #       <linuxstb> preglow: Yes - look at how current_tick is defined and used.
14.53.10 #       <mirak> XavierGr: I think 24 bits is below that limit, but enough
14.53.10 #       <XavierGr> Is there any plan to use 64bits for displays?
14.53.15 #       <mirak> lol
14.53.26 #       <preglow> ok, here comes timer
14.53.30 #       <g33> you know sometimes the idiot who ripped an album put the artist name and album name in the file name, so when you list the files in a folder all you see is 15 "eric clapton - from the cra.." and have to wait and scroll every file to find the right song
14.53.30 #       <preglow> linuxstb: please test
14.53.34 #       <linuxstb> Sure.
14.54.02 #       <mirak> g33: I have seen idiots that put album and artist into the artist id3 tag
14.54.45 #       <g33> man i should spend one day and just sort out all my mp3s
14.54.54 #       <mirak> g33: I have done that
14.55.16 #       <g33> maybe i can pay some polish kid to do it for me! :D
14.55.29 #       <mirak> at the begining I was puting  artist - album - track - title in the name, because it was easier for P2P
14.55.38 #       <linuxstb> g33: There are tools to have retag and rename MP3s
14.55.44 #       <linuxstb> s/have/help/
14.55.53 #       <g33> yeah but i dont always trust em automatic tools
14.55.54 #       <mirak> I use easytag on linux
14.56.00 #       <g33> im not on linux
14.56.04 #       <mirak> g33: that's semy manual
14.56.09 #       <g33> im l33t so i use xp home :)
14.56.30 #       <mirak> I have seen that some uses musical signatures to identify songs
14.57.00 #       <mirak> it means that two mp3 encoded with different bitrates by different persons can have the same signature
14.57.05 #       <linuxstb> preglow: That's perfect - the backlight now fades.
14.57.15 #       <mirak> even if they don't match bit for bit
14.57.20 #       <preglow> ok, button driver next!
14.58.51 #       <markun> g33: with 'mmv' you can rename files very easy under linux.
14.59.06 #       <g33> [13:56] <g33> im l33t so i use xp home :)
14.59.08 #       <markun> Ah, NOT on linux :)
15.00.02 #       <g33> im learning c++.. maybe one day ill write my own tool..
15.00.11 #       <g33> eta 2009 :P
15.00.42 Join    webguest11 [0] (n=5087d10e@labb.contactor.se)
15.06.10 Part    webguest11
15.06.28 #       <Cassandra> I had a look at the button code in ipodlinux.  It looked kind of scary.
15.06.35 #       <Cassandra> And interupt driven.
15.06.53 #       <preglow> yeah, it did
15.07.06 #       <preglow> but i'm going to have a crack at it now, or so help me god!
15.07.12 #       <preglow> i like being melodramatic
15.07.15 #       <Cassandra> Good luck with that.
15.07.28 #       <preglow> at least we have interrupts now
15.07.29 #       <Cassandra> I kind of got distracted by the Secret Project.
15.07.31 #       <preglow> which isn't a bad start
15.07.47 #       <preglow> the wha?
15.07.54 #       <Cassandra> The bear bones of which is now implemented.  It's looking good.  I may have a first release in a few days.
15.08.20 #       <Cassandra> It's a wxWidgets program.
15.08.26 #       <Cassandra> Erm, "bare" bones.
15.08.31 #       <preglow> hahaha
15.08.39 #       <preglow> it'd be cooler if it contained bear bones
15.09.02 #       <preglow> wasn't it you who was going to implement the sims with wxwidgets?
15.09.42 #       <Cassandra> Someone suggested it was, that, but no.
15.10.04 #       <Cassandra> Although that might be an interesting project at some point.
15.10.17 #       <Cassandra> However, I regard the sim as low priority.
15.10.27 #       <g33> hey how about making the iriver to a digital soundcard? you connect the iriver to computer with usb, and then it works as a usb soundcard and you can use the digital output from the computer? :D
15.10.38 #       <preglow> yup, but i think using something like sdl would be wiser for that
15.10.43 #       <preglow> we don't exactly need widgets for sims
15.11.22 #       <preglow> but that would be a cool project
15.11.22 #       <Cassandra> g33: Can't be done, I'm afraid.  All the computer sees is a disk.
15.11.34 #       <preglow> would eliminate the need for multiple targets, and would probably result in a better simulator
15.11.50 #       <Cassandra> preglow, on the other hand it would mean polluting the sim with C++.
15.11.55 #       <preglow> Cassandra: oh?
15.12.01 #       <preglow> sdl is c
15.12.10 #       <Cassandra> wxW is C++, sadly.
15.12.18 #       <preglow> ahh, yes
15.12.19 #       <preglow> that it is
15.12.21 #       <preglow> but again
15.12.24 #       <preglow> sdl would be better
15.12.25 #       <g33> ohwell.. usb sound card is only $20 anways
15.12.27 #       <preglow> since it's got sound drivers as well
15.12.32 #       <Cassandra> Part of whats been taking time on this project has been learning C++.
15.13.05 #       <Cassandra> Sounds like a more sensible choice, yes.
15.13.16 Join    PaulJ [0] (n=PaulJ@vpn-3177.gwdg.de)
15.13.45 ***     Saving seen data "./dancer.seen"
15.14.11 #       <mirak> amiconn: are you around ?
15.14.16 Quit    Jungti1234 ("bye")
15.16.12 Join    tucoz [0] (n=martin@hornved.ii.uib.no)
15.16.31 #       <tucoz> Cassandra, are you here?
15.17.04 Join    LinusN [0] (n=linus@labb.contactor.se)
15.17.57 #       <preglow> linuxstb: btw, did you try the new ipl bootloader?
15.18.08 #       <XavierGr> I will be damned now sorting 850 files droped to 68 ticks
15.18.10 Join    Febs [0] (i=Febs@dhcp64-134-210-83.hfwsf.sjc.wayport.net)
15.18.20 #       <XavierGr> Previous was 618 ticks for the same list!
15.18.24 #       <XavierGr> Incredible
15.18.56 #       <XavierGr> Now I have a killer jpeg viewer, optimised as hell.
15.19.02 #       <LinusN> nice
15.19.24 #       <XavierGr> I think 1 second for 850 files is a good deal.
15.19.35 #       * preglow points to the dct functions, which are surprisingly asm free, just to spoil the fun
15.19.49 #       <B4gder> XavierGr: and it does color on h3x0 ? B-]
15.19.50 #       <mirak> XavierGr: can we see that ?
15.20.31 #       <XavierGr> Bagder: Unfortunately I am too idiot to understand the jpeg code to do that.
15.20.44 #       * LinusN drops the dct functions in preglow's lap
15.20.51 #       <linuxstb> preglow: No, it needs yet another version of gcc installing.
15.21.01 #       <XavierGr> mirak: Of course I will put some more memory failsafe code and I will upload it to the tracker.
15.21.23 #       <preglow> linuxstb: eh?
15.21.24 #       <Cassandra> tucoz, hello, yes.
15.21.32 #       * preglow looks at the viper in his lap with disgust
15.21.52 #       <tucoz> Cassandra, if you find some time. Would you like to have a look at the latex docs? It is organized like the 2.4 docs atm.
15.22.35 #       <Cassandra> OK.
15.22.47 #       <Cassandra> Not sure when I'll have time though.
15.23.45 #       <tucoz> Cassandra, not that this is looking that good. It is only the writer2latex output, that I split into chapter files and made compilable :) http://www.student.uib.no/~st08541/rockbox/rockbox.pdf
15.24.35 #       <preglow> linuxstb: do you have any idea why the ipl button code for 4g and up seems to use both the mini and 4g interrupts?
15.25.09 #       * Bger spots an old code in playlist_viewer.c
15.25.14 #       <linuxstb> I think the "mini" interrupt is needed for the hold switch
15.25.58 #       <linuxstb> And forget what I said about needing a different compiler for the new ipl bootloader - I was thinking about podzilla2
15.26.24 #       <preglow> why the hell would one need a different compiler for compiling a program?
15.26.24 #       <linuxstb> That needs an arm-uclinux- toolchain and libraries
15.27.10 #       <tucoz> Cassandra, this zip includes the LaTex build system. It should be quite easy to make it look prettier from here. Make the chapters (parts) more organized. The file structure is what is important right now I think. http://www.student.uib.no/~st08541/rockbox/manual.zip
15.27.11 Quit    VikraMarkA_ ("Leaving")
15.27.31 #       <preglow> okiedoke
15.27.34 #       <preglow> time for food
15.27.34 #       <Cassandra> tucoz: I've had a quick look, and it looks like a very good start.  You seem to be missing the appendices and introductory blurb.
15.27.58 #       <tucoz> Cassandra, yes, but the files are there
15.28.29 #       <Cassandra> Cool.  Just having a peek inside the archive now.
15.28.37 #       <tucoz> I didn't bother to make the appendeces compile, but the text is there in appendix.tex
15.29.14 #       <tucoz> Cassandra, I think some of the text needs some attention as well, as some features have changed since 2.4.
15.29.23 #       <Cassandra> How clean is the generated code?
15.29.35 #       <tucoz> Cassandra, and of course the tables. The generated code looks like ****
15.29.48 #       <Cassandra> tucoz:  Yeah, it needs a lot of attention in fact.
15.29.57 #       <tucoz> And I generated it with the -clean flag
15.30.08 #       <Cassandra> *nod* very sensible.
15.30.09 #       <tucoz> the generated docs is here http://www.student.uib.no/~st08541/rockbox/rockbox-manual-2.4.zip
15.30.28 #       <Cassandra> For a first shot, I think it looks better than I'd have expected.
15.30.59 #       <tucoz> Yes, me too. But as you see, e.g. the tables need some major work.
15.31.28 #       <tucoz> But, it should serve as a starter at least.
15.32.52 #       <mirak> linuxstb: just a question, what would be the point of converting from 16 to 24 ?
15.32.52 #       <preglow> i think it should do nicely for a starter
15.33.22 #       <Cassandra> Code is nice and clean too.
15.33.30 Join    perplexity [0] (n=joust@217.165.110.88)
15.33.30 #       <tucoz> (and of course fix the references, as I didn't fix all of them)
15.33.31 #       <linuxstb> mirak: There probably isn't any point any more - but the first colour version of the Simulator worked in 24-bit
15.33.31 #       <B4gder> mirak: for screendumps for example
15.33.35 #       <Cassandra> I think that's a very good starting point, tucoz.
15.33.41 #       <tucoz> Cassandra, :) nice
15.33.44 #       <linuxstb> B4gder: The screendump also uses rgb565
15.33.44 #       <mirak> ok
15.33.55 #       <B4gder> bmps can do 565?
15.33.59 #       <linuxstb> Yep.
15.34.02 #       <B4gder> ok
15.34.06 #       <linuxstb> We write a 16-bit bitmap.
15.34.09 #       * B4gder learned something
15.34.31 #       <mirak> linuxstb: I was reading the datasheets and it seems you can pass directly 18bits and it does the conversion in hardware on the lcd side
15.34.46 #       <mirak> from 18 to 16 bits
15.34.53 #       <tucoz> Cassandra, ok, now you know where they are. I don't think I work on that before we could send changes as patches.
15.35.02 #       <Febs> tucoz, FYI, everything in the WikiManual (at least everything that I wrote) started from version 2.4 of the manual if it existed there in the first place.
15.35.10 #       <linuxstb> mirak: I thought it was the other way around - you write 16-bits and the hardware converts it to 18-bits.
15.35.12 #       <B4gder> mirak: why would you want to do that?
15.35.55 #       <mirak> linuxstb: it can do that too, wait a minute :)
15.35.58 #       <tucoz> Febs: good. I think the wiki will serve as a good source of copy and paste for now :)
15.36.26 #       <mirak> B4gder: to not to do the conversion in software mode
15.36.27 #       <Febs> Great.  That was always my intention as I updated the 2.4 sections and put them in the WikiManual.
15.36.42 #       <linuxstb> mirak: What are you trying to achieve?  Do you want to make the h300 lcd work in 18-bit mode?
15.36.44 #       <B4gder> mirak: you'd have to write a lot more data, which is bad
15.36.49 #       <Febs> I need to get LaTex installed on my computer so that I can see what you've done.
15.37.06 #       <tucoz> Febs, you could look at the pdf?
15.37.20 #       <Febs> Link?
15.37.27 #       <tucoz> http://www.student.uib.no/~st08541/rockbox/rockbox.pdf
15.38.06 #       <mirak> B4gder: yep
15.38.09 #       <tucoz> Febs, that is mostly generated code from the writer2latex command, which I have cleaned up and made to compile.
15.38.34 #       <mirak> linuxstb: no not really, I am figure out how it works globally, so sometime I fix on some details
15.39.18 #       <mirak> maybe there is some docs about rockbox interfaces ?
15.39.42 #       <B4gder> mirak: nope, none that are any recent
15.39.53 #       <linuxstb> There's a good "graphics API" wiki page that amiconn keeps up to date.
15.39.58 #       <B4gder> true
15.39.58 #       <tucoz> Febs, you can find the other sources in that directory. That is, the writer2latex output (which won't compile) and the latex sources.
15.40.04 #       <mirak> LinusN: ok I will read that
15.40.36 #       <Febs> tucoz, looks like a great start.
15.41.15 #       <tucoz> Febs, at least under the hood :)
15.41.58 #       <Febs> Hey, you must start somewhere!
15.42.47 #       <tucoz> yes, that is true. Now to agree on what to put in cvs, and start merging the docs from the wiki with this.
15.42.49 #       * Febs is now installing XEmTeX.
15.43.02 #       <tucoz> Febs, are you using windows?
15.43.06 #       <Febs> Yes.
15.43.24 #       <tucoz> Ok, is that a good LaTeX system?
15.43.29 Quit    muesli- ("ich will Kühe!!!")
15.43.36 #       <mirak> I guess it's possible to call the file browser from an application ?
15.43.50 #       <Lynx_> just got my h340!
15.43.56 #       <mirak> dman that's not easy
15.43.59 #       <mirak> damn
15.44.11 #       <tucoz> I have only used MiKTex under windows
15.44.15 #       <Febs> tucoz, having never used any LaTeX system, I have no basis for comparison.
15.44.27 #       <tucoz> Ok, probably good enough
15.47.15 Join    webguest27 [0] (n=c13354c1@labb.contactor.se)
15.47.19 #       <Lynx_> argh, why in the world would they put a paper sticker on the display that tears on removal
15.47.47 #       <saa[b_r]ider> Lynx: wow, the one with the pixeled dancers on it?
15.48.34 #       * webguest27 thanks every develloper here for all the Rockbox works !!!
15.48.36 #       <mirak> extensions are usable on the simulator ?
15.48.39 #       <Lynx_> saa[b_r]ider: yes
15.49.09 #       <saa[b_r]ider> you're a bit late to the party :D
15.49.29 #       <mirak> invalid ELF header
15.49.35 #       <mirak> when I try to run an extension
15.49.40 #       <webguest27> anyone here now if we can replace the doble plater 40go HD of h140 by a 80 go one?
15.49.42 #       <Lynx_> hmm, it seems i didn't get any remote with it :(
15.49.54 #       <saa[b_r]ider> lynx: is this your first DAP, or did you have another one before it?
15.50.05 #       <webguest27> seems Toshiba made 80 doble plater HD now
15.50.10 #       <Lynx_> saa[b_r]ider: had an archos until last week
15.50.27 #       <saa[b_r]ider> (the LCD remote is optional, only comes with the non-LCD one)
15.50.41 #       <webguest27> iHP- 180, that would be the best music device :
15.50.43 #       <Lynx_> saa[b_r]ider: it didn't come with any remote
15.50.52 #       <webguest27> :]
15.50.56 #       <Lynx_> saa[b_r]ider: unless i haven't found i yet. but it's not listed on the box
15.51.13 #       <webguest27> anyone know?, please
15.51.14 #       <saa[b_r]ider> webguest: they announced it a while ago, but afaik it's still not available
15.51.48 #       <webguest27> but when it will be possible to by, will it be compatible with h140 one?
15.52.15 #       <saa[b_r]ider> lynx: to be honest, I never used that remote. I only connected it cause the the standard headphones are short
15.52.15 #       <webguest27> I love my hp140 and don't want to change it
15.52.22 #       <linuxstb> mirak: Are you trying to use a plugin compiled for the target on the simulator?  You need to use the simulator versions - they are installed when you do a "make install" in your simulator build directory.
15.53.13 #       <Lynx_> saa[b_r]ider: a remote was the only thing i was missing on the archos. i thought there would be one with this iriver because you told me some time ago, but they seemed to have changed this.
15.53.22 Join    tvelocity [0] (n=tony@84.254.13.74)
15.53.27 #       <saa[b_r]ider> webguest: check the MR forums, or check the specs on toshiba's site. techincaly, it should fit if the dimentions in the specs are correct
15.53.56 #       <webguest27> but I heard 2 differents size for it
15.54.33 #       <webguest27> and don't know wich is a good one :(
15.55.16 #       <saa[b_r]ider> lynx: well my H340 came with it... but changes did happen. my H340 came with the non-windowed case. newer H340s came with the windowed case (which I had to buy my self, together with the LCD remote)
15.55.34 #       <Lynx_> saa[b_r]ider: ok, i have a newer one then
15.55.49 #       <linuxstb> webguest27: The h140 has a Toshiba MK4004GAH - I am sure you can find the dimensions of that drive on the web and compare it with the one you want to buy.
15.55.53 #       <saa[b_r]ider> webguest: beleive me, a lot of people are waiting for it... including me
15.56.31 #       <webguest27> linuxstb: afaike isn't the iriver size problem, but the 80go HD one
15.56.43 #       <mirak> linuxstb: yes I am dumb
15.56.45 #       <mirak> lol
15.56.50 #       <saa[b_r]ider> lynx: you got the windowed case?
15.56.52 #       <webguest27> :)
15.57.00 #       <Lynx_> saa[b_r]ider: yes
15.57.30 #       <Lynx_> saa[b_r]ider: maybe i can buy the non-lcd remote off someone who has it and does not need it like you
15.57.31 #       <Bger> saa[b_r]ider btw if you're using the h300 lcd remote, i've updated the button patch 
15.57.36 #       <webguest27> saa[b_r]ider: you want it too :), did you see if we can upgrade or no yet?
15.58.18 #       <saa[b_r]ider> I would suggest that you get a t-dimention skin, or rock.. I forget the name, always confused me with rockbox
15.58.37 #       <saa[b_r]ider> Bger: the button.diff patch?
15.58.42 #       <Bger> yes, the same
15.58.43 #       <mirak> saa[b_r]ider: I have the windowed case, it's a bit large
15.59.18 #       <Bger> now the remote behaves much more like the buttons on the main unit
15.59.30 #       <webguest27> saa[b_r]ider: but apparently Toshiba said 2 differents size for the same product, and I don't know which one is good :(
15.59.47 #       <saa[b_r]ider> webguest: it's not out yet, so I still don't know. we'll have to wait :)
16.00.36 #       <webguest27> ok thanks for help me a bit
16.00.42 #       <webguest27> I'll wait
16.00.49 #       <webguest27> in hoping it will fit
16.00.57 #       <webguest27> 80go O.O
16.01.06 #       <saa[b_r]ider> bger: yesterday I used the remote_type.patch, to scroll through menus you have to use right and left.
16.01.23 #       <Bger> saa[b_r]ider yes, i know
16.01.29 #       <saa[b_r]ider> when I tried to patch using button.diff I think nothing happened
16.01.47 #       <Bger> hm, see, u can't use the 2 patches at the same time
16.01.48 #       <saa[b_r]ider> so how does the new patch work?
16.01.51 #       <Bger> do u have 2 remotes ?
16.01.55 #       <webguest27> ciao everyone
16.02.02 Quit    webguest27 ("CGI:IRC")
16.02.07 #       <saa[b_r]ider> I didn't use them at the same time
16.02.11 #       <saa[b_r]ider> compiled twice
16.02.16 #       <Bger> i mean, h100's one and h300's one
16.02.24 #       <saa[b_r]ider> nope, only the H300
16.02.39 #       <Bger> then u don't need to change settings
16.03.30 #       <saa[b_r]ider> so if I patched a new build with button.diff, how are the buttons now?
16.03.34 #       <Bger> with the new version u scroll with up/down
16.03.38 #       <saa[b_r]ider> nice
16.03.45 #       <Bger> and enter with left/right
16.03.52 #       <Bger> in menus, in browser ...
16.03.55 #       <saa[b_r]ider> what about the +10 and -10?
16.04.02 #       <Bger> page up/page down
16.04.04 #       <mirak> is there a way to slow down the simulator ?
16.04.10 #       <mirak> plugins display nothing
16.04.10 #       <saa[b_r]ider> cooool!
16.04.13 #       <mirak> or to fast
16.04.26 #       <Bger> mirak put a sleep :)
16.04.43 #       <linuxstb> mirak: Which sim are you using?
16.04.56 #       <linuxstb> (i.e. x11 or win32)
16.05.00 #       <mirak> X
16.05.02 #       <mirak> 11
16.05.06 #       <Bger> *exit/enter with left/right*
16.05.07 #       <linuxstb> For the h300?
16.05.10 #       <mirak> yes
16.05.18 #       <linuxstb> That doesn't work...
16.05.25 #       <linuxstb> No-one has added colour support to the x11 sim yet.
16.05.35 #       <mirak> ok
16.05.46 #       <saa[b_r]ider> Bger: I think I'll have a go at it today. last night I changed the colors in lcd.h, but they still need tweaking
16.05.48 #       <mirak> the cube displays something
16.05.49 #       <mirak> but bad
16.05.56 #       <linuxstb> But if you have Wine installed and a windows cross-compiler, you can use the win32 sim.
16.06.15 #       <Bger> hehe
16.06.18 Part    tucoz ("Leaving")
16.06.18 #       <linuxstb> Which Linux distribution are you using?
16.06.19 #       <mirak> I don't have win32 cross compiler
16.06.23 #       <mirak> I use ubuntu
16.06.29 #       <B4gder> then you can have it
16.06.30 #       <mirak> on x86
16.06.42 #       <mirak> well I must built it 
16.06.50 #       <mirak> I don't want to do that no
16.06.51 #       <mirak> now
16.06.52 #       <linuxstb> Nope - there is a Debian package.
16.06.56 #       <B4gder> we use the debian package fine
16.07.00 #       <B4gder> mingw32
16.07.02 #       <mirak> ok great
16.07.17 #       <linuxstb> I use it as well to build the windows sim (and other things)
16.07.35 #       <B4gder> but of course we'd also appreciate a fix for the x11 sim!
16.07.44 #       <linuxstb> Maybe the fix is to port it to SDL
16.07.53 #       <B4gder> yes, I would agree to that
16.08.14 #       <linuxstb> Does the windows sim use cygwin or is it a native windows app?
16.08.48 #       <linuxstb> Obviously it doesn't use cygwin....
16.09.03 #       <linuxstb> Otherwise mingw32 wouldn't work.
16.09.05 #       <saa[b_r]ider> lynx: btw, the windowed case scratches your H300 after a while, that's why I suggested the skin
16.09.24 #       <saa[b_r]ider> plus it's bulky
16.09.54 #       <Lynx_> saa[b_r]ider: yes, i usually don't use those things
16.10.14 #       <Lynx_> saa[b_r]ider: how much is the lcd remote?
16.10.39 #       <Bger> Lynx_ i suggest u to contact someone in korea...
16.10.51 #       <Bger> or buy the h100 lcd remote
16.11.07 #       <Bger> i bought my this way: through Kylera @ MR
16.11.39 #       <saa[b_r]ider> I'm in china, and I asked a korean classmate to get it for me during our spring break :)
16.12.07 #       <amiconn> mirak: Now I'm here (sort of)
16.12.20 #       <Lynx_> Bger: is it cheaper in korea? its 20 euro at amazon
16.12.26 #       <saa[b_r]ider> I've gotten so used to it, I barely take out my H340 out of my bag. I just use the remote
16.12.40 #       <Bger> Lynx_ ? 20 eu for *h300* lcd remote ?
16.12.45 #       <Lynx_> ah, not that's the no lcd one
16.12.57 #       <saa[b_r]ider> no one wants that :)
16.13.09 #       <Lynx_> saa[b_r]ider: i don't really care, i just want any remote
16.13.22 #       <Bger> this is a robbery for non-lcd :)
16.13.24 #       <mirak> amiconn: it was about the precision thing
16.13.29 #       <amiconn> B4gder: Standard 16 bit BMP is actually 15 bit RGB555, but you can do all sorts of 16 bit RGB, i.e. RGB565, RGB664 etc. by using the bitfield feature of BMP
16.13.33 #       <saa[b_r]ider> lynx: did you check if they still have the LCD remote in MR's on-line shop?
16.13.44 #       <Lynx_> saa[b_r]ider: MR?
16.13.52 #       <Bger> misticriver
16.13.54 #       <saa[b_r]ider> misticriver.net
16.14.11 #       <saa[b_r]ider> your new friend for everything iRiver :D
16.14.14 #       <mirak> amiconn: what I was saying is the truncation was the way to go, because, the extra bits are just a subset of the base color
16.14.23 #       <amiconn> No, that's wrong
16.14.59 #       <amiconn> By having less bits per colour you're getting fewer levels, so you have to round.
16.15.06 #       <Lynx_> saa[b_r]ider: didn't know they have a shop... There's one for 50 euro currently at ebay. that's a lot of money for a remote
16.15.23 #       <Lynx_> saa[b_r]ider: i'll buy your non-lcd remote for 5 eur ;)
16.15.37 #       <amiconn> The rounding should happen towards the nearest destination level, and in addition, black always stays black and white always stays white
16.15.38 #       <mirak> amiconn: For me the precision doesn't matter. What the actual thing is doing is considering that the colors below and above in fixed interval can be assimilated to that color. But in reality the colors truncated with a right shift are considered to be a subset of a base color. For exemple with what you are doing with 6 bits for a taint, the color 0 have a subset of colors of 2 colors {000 001} while the color 100 have a 
16.15.38 #       <mirak> subset of {010,011,100,101}
16.15.46 Join    Hooligan [0] (i=Hooligan@Node111-61-52-66.1dial.com)
16.16.10 #       <saa[b_r]ider> lynx: sure, and i'll charge you 45 euros for shipping :)
16.16.32 #       <Lynx_> saa[b_r]ider: heh, do you live on the moon? ;)
16.16.45 #       <amiconn> mirak: Yes, and you can't achieve that with right shifting
16.17.06 #       <saa[b_r]ider> close, china :D
16.17.24 #       <amiconn> The point is that the lowest and the highest interval have half the width of all others
16.17.27 #       <mirak> amiconn: what I am saying is that 0 should also have a 4 colors subset
16.17.39 #       <amiconn> That would be plain wrong
16.18.20 #       <saa[b_r]ider> lynx: US$ 61 at misticaudio, and backordered! don't know how much that is in euro
16.18.40 Join    muesli- [0] (n=muesli_t@141.71.4.188)
16.18.46 #       <mirak> amiconn: this doesn't matter, because no matter what, 4 taint of green in 8 bit per taint mode will be assimilated to the same color in 6 bit mode.
16.18.50 #       <Lynx_> saa[b_r]ider: yes, i saw that. i don't think i will buy one for that price
16.19.14 Join    b0br [0] (n=3ef54246@labb.contactor.se)
16.19.33 #       <mirak> with what you are doing the color 0 will have 2 and the highest will have 6. Well whatever, but that's not even
16.19.44 #       <amiconn> No.
16.20.03 #       * saa[b_r]ider checking iriver china online shop
16.20.09 #       <amiconn> I spread evenly, the bottom and top intervals both have half the width of the rest
16.20.21 #       <mirak> what I am saying is that if you go  from 4 nuances ---> the same nuance, truncating the lowest bytes is enough and not less accurate than doing a rounding
16.20.24 #       <amiconn> That's why I calculate /255, not /256
16.20.41 #       <amiconn> It is less accurate
16.21.36 #       <mirak> since colors are linear it's not
16.21.53 #       <amiconn> The error is bigger
16.22.15 #       <amiconn> If you always round down, the change in brightness can be 0, -1, -2 or -3
16.22.22 #       <saa[b_r]ider> lynx: not available... I'm hoping one day I can use my non-LCD remote as a modded car remote or something (over ambitios)
16.22.42 #       <mirak> amiconn: explain the numbers
16.22.59 #       <linuxstb> mirak: You are dividing by four and trucating.
16.23.23 #       <amiconn> However, if you *round* the change is +1, 0, -1, -2  (or +2, +1 ,0, -1 depending how you treat the "border values")
16.23.52 Quit    B4gder ("time to say moo")
16.24.05 #       <amiconn> The number mean the error when representing the old values (full scale) with the new ones (reduced scale)
16.24.09 #       <mirak> for me the reason it doesnt matter is that the difference between 0,5 and 1,5 is still one
16.24.34 #       <mirak> the error is still 4 no matter what you do
16.24.40 #       <amiconn> It's not only the difference that matters, but also the absolute value
16.24.45 #       <mirak> hem not 4 , 1
16.24.50 #       <amiconn> Nope
16.25.10 #       <mirak> well I don't think that we can perceive a visual difference
16.25.44 #       <amiconn> If you just truncate, the pictures will end up too dark in the dark parts, and too bright in the bright parts
16.26.22 #       <amiconn> If you make a simple drawing on a paper (with few levels) or a spreadsheet, you'll see what I mean
16.26.22 #       <preglow> linuxstb: just tested with the yield uncommented again, works just dandy
16.26.41 Quit    muesli- ("ich will Kühe!!!")
16.26.45 #       <linuxstb> So what changed?
16.27.11 #       <preglow> the fun thing about not understanding the error in the first place, is that i don't care :)
16.27.16 #       <amiconn> It took me quite a while to figure this out, we implementing the conversion functions in the grayscale lib´rary
16.27.27 #       <mirak> amiconn: I agree with darkness thing, but not with brightness :)
16.27.27 #       <amiconn> s/we/when/
16.27.32 #       <linuxstb> preglow: hehe.  Let's just hope it doesn't return.
16.27.32 #       <preglow> i'd appreciate it if you tried it too
16.27.40 #       <linuxstb> OK.
16.28.34 #       <amiconn> mirak: The difference is that with truncation, you map 256->64, with rounding down. The correct mapping is 255->63, with proper rounding and half-sized upper and lower interval
16.29.04 #       <mirak> why 256 ? 
16.29.11 #       <linuxstb> preglow: Yes, it seems happy.
16.29.38 #       <amiconn> If you put together a spreadsheet, you'll also see that *not* all intermediate intervals contain 4 source values, some will contain 5
16.29.50 Join    adiamas [0] (n=adiamas@12.109.187.2)
16.30.09 #       <amiconn> mirak: Because that's how truncation works. Just that you'll hever see the topmost value
16.30.36 #       <mirak> amiconn: you can't have a value of 256
16.30.39 #       <mirak> what do you mean
16.30.47 #       <mirak> it's between 0 and 255
16.31.06 #       <amiconn> [16:30:09] <amiconn> mirak: Because that's how truncation works. Just that you'll hever see the topmost value <==
16.31.53 #       <mirak> with truncation 0, 1, 2, 3, gives 0 and 251 253 254 255 gives 63 with 63 that should be the same than the 251
16.32.25 #       <mirak> 251 color, though there is some weird thing in 16bit mode in the datasheet of the lcd screen
16.32.29 #       <linuxstb> preglow: I don't know if you've tested, but the line scrolling works fine in the file browser - I have a test directory starting with A with a very long name that scrolls nicely.
16.32.41 #       <saa[b_r]ider> bger: any known bugs with the H300 remote patch?
16.32.47 #       <mirak> remove "251 color,"  
16.33.09 #       <preglow> linuxstb: cool, will test
16.33.22 #       <mirak> amiconn: from what I understand, colors 253 254 and 255 are lost and can't be obtained in 16bit mode
16.33.43 #       <mirak> well not exactly but well ..
16.33.56 #       <amar> silly question, is there anywhare specidic you have to go to decaler a global variable/setting
16.34.01 #       <linuxstb> preglow: I wish you hadn't made the backlight timeout work...
16.34.17 #       <preglow> linuxstb: i find the lcd pretty readable even without it
16.35.14 #       <linuxstb> Mine needs a light shining directly onto it, and I haven't got one.
16.35.19 #       <mirak> amiconn: well nevermind, that's not that much of a problem anyway exept it needs a bit more computation
16.35.25 #       <linuxstb> I've just changed the default setting in settings.c though.
16.35.36 #       <preglow> mine is completely readable without light
16.35.53 #       <preglow> hmm
16.35.56 #       <preglow> scrolling doesn't work here
16.36.00 #       <preglow> ahh, right
16.36.03 #       <preglow> it needs to be selected...
16.36.09 #       <linuxstb> Yep.
16.36.10 #       <preglow> better make it a dir, then
16.36.50 #       <preglow> colour lcds where you can't see without backlight seems really annoying...
16.37.15 #       <linuxstb> I have trouble reading the h140's screen without a light as well.  Maybe it's just me.
16.37.23 #       <preglow> no, that's not just you
16.37.25 #       <linuxstb> Or my dark house.
16.37.25 #       <preglow> it sucks
16.37.45 #       <preglow> hah
16.37.47 #       <preglow> works just dandy
16.37.48 #       <mirak> preglow: I can't see anything without backlight on the H300
16.38.00 #       <preglow> mirak: the h300 has a very sucky lcd in that regard
16.38.19 #       <mirak> don't know why it's sucky
16.38.27 #       <preglow> but okies
16.38.30 #       <preglow> now for buttons
16.38.34 #       <mirak> preglow: that's the only way to have black black
16.38.35 #       <amiconn> Most colour LCDs are like that
16.39.48 #       <saa[b_r]ider> the H300 LCD shows pretty well without backlight in direct sunlight
16.40.22 #       <saa[b_r]ider> so if you're outdoors, you could save some battery power if you kept the LCD off...
16.40.57 #       <mirak> yes it would be better to put the lcd off
16.41.12 #       <mirak> that's not what you meant I think
16.41.16 #       <saa[b_r]ider> I think the reason the H300 LCD doesn't show well without back light because there's a thick piece of glass
16.41.32 #       <saa[b_r]ider> I ment the back light
16.42.01 #       <mirak> actually, for me it would be the same to have the screen turned off than having just the backlight off
16.42.14 Join    San||Away [0] (n=sanitari@213-202-144-96.bas502.dsl.esat.net)
16.42.19 #       <mirak> I wouldn't have noticed it was on if you didn't told it to me
16.42.52 #       <saa[b_r]ider> unless you were under sulight :)
16.43.21 #       <mirak> iriver firmware turn it off isn't it ?
16.43.37 #       <saa[b_r]ider> I've always wanted the LCD to stay on with the backlight off, thinking that it would be as clear as with color-screen mobile phones
16.43.43 #       <saa[b_r]ider> yeah
16.45.04 #       <mirak> I still have a nokia 3310
16.45.33 #       <saa[b_r]ider> :)
16.45.40 #       <mirak> the battery is dead
16.45.43 #       <saa[b_r]ider> did the model numbers go that low :D
16.46.50 #       <saa[b_r]ider> I have my faithful SE T68i as my backup phone... had to use it a few days ago when i dropped my current phone in a glass of water by accident :|
16.47.35 #       <mirak> admit it was a beer
16.47.38 #       <mirak> just admit it
16.47.39 #       <mirak> :)
16.48.37 Quit    adiamas ("Chatzilla 0.9.69 [Firefox 1.5/2005111116]")
16.48.43 #       <saa[b_r]ider> hahaha.... actually, it was the iron refiller, with water and toothpaste inside it (from when I opened my H340 to insert an inSkin)
16.49.09 #       <saa[b_r]ider> :D
16.49.27 #       <saa[b_r]ider> I bet you could never have guessed ;)
16.49.49 #       <preglow> linuxstb: does the ipod control pads differ between generations? i thought they all had the same basic functionalty
16.50.35 #       <preglow> hah, rockbox.ipod is 300k, rockbox.iriver is 250k
16.50.42 #       <preglow> we really should play around with using thumb code
16.51.08 #       <linuxstb> Yes - especially for code in iram.
16.51.17 #       <preglow> hmm
16.51.25 #       <preglow> it's usually the other way around
16.51.27 #       <preglow> especially for code in ra
16.51.28 #       <preglow> m
16.51.35 #       <linuxstb> I know - but I mean to save space in iram.
16.51.48 #       <preglow> well, we wont use too much iram for code, hopefully
16.52.01 #       <preglow> though the ipod code cache is just as bad as motorolas
16.52.27 #       <preglow> i wonder if we can configure it to never cache data
16.52.37 #       <preglow> we'll need to do some tests, obviously
16.52.38 #       <mirak> what exactly is ffmpeg ? Is it an interface or codecs etcetera ?
16.52.43 #       <preglow> mirak: it's a codec library
16.52.55 #       <mirak> you used that for ogg mp3 etcetera ?
16.52.57 #       <linuxstb> The ipod control pads are (I think) the same for all the PP5020 models - apart from the mini.
16.53.20 #       <linuxstb> mirak: No.  But we use the ffmpeg and shorten decoders from it.
16.53.22 #       <preglow> what's different for the mini?
16.53.29 #       <preglow> flac and shorten decoders
16.53.44 #       <linuxstb> Yes, that.
16.54.30 #       <linuxstb> preglow: All I know is what's in the kernel's keyboard.c file
16.54.46 #       <mirak> linuxstb: hem ffmpeg is a codec in itself ?
16.55.10 #       <linuxstb> mirak: ffmpeg is a high level library for decoding and encoding audio and video.  It consists of libavcodec (the codecs themselves) and libavformat (for the container formats)
16.55.11 Join    hshah [0] (n=hshah@shahassociates.plus.com)
16.55.31 #       <preglow> linuxstb: i was just thinking about the need for several IPOD_*_PAD defines
16.55.37 #       <preglow> linuxstb: when they're all basically the same
16.55.38 #       <linuxstb> mirak: It does far too much for it to be of general use in Rockbox.
16.55.54 #       <linuxstb> preglow: Yes, I've thought about that.  An IPOD_4G_PAD is probably enough.
16.56.06 #       <preglow> linuxstb: what about IPOD_PAD ?
16.56.36 #       <linuxstb> The earlier PP5002-based models are possibly different - I haven't looked at the code for those.
16.56.39 #       <preglow> they alle have the same buttons, don't they?
16.56.52 #       <linuxstb> Yes, but at least the drivers will be different.
16.56.57 #       <preglow> yes they will
16.57.15 #       <preglow> but this way all plugins and such don't have to do the full string off checks for IPOD_*_PAD
16.57.33 #       <preglow> but okies, we'll see
16.57.36 #       <linuxstb> The H100/H300 is the same - they look the same to the application, but have different drivers.
16.58.03 #       <preglow> hmm, true
16.58.09 #       <linuxstb> So it could be worth having something like IPOD_PAD and CONFIG_IPOD_PAD
16.58.27 #       <linuxstb> Or in fact, just have IPOD_PAD contain different (non-zero) values
16.58.45 #       <preglow> and btw, we should probably drop all the PP5020 prefixes we use now
16.58.53 #       <preglow> it's kind of redundant in rockbox
16.59.14 #       <preglow> at least for the ones in pp5020.h
16.59.49 #       <linuxstb> Yep, that would make sense.
16.59.53 #       <preglow> should i stuff opto_i2c_init in i2c-pp5020.c as well?
17.00.27 #       <preglow> i don't really know what it does, so i have no idea, i just see 'i2c' in its name
17.00.27 #       <linuxstb> No, I think that code belongs in button_init()
17.00.33 #       <preglow> okay
17.00.54 #       <linuxstb> But I guess it doesn't really matter.
17.01.03 Quit    Zagor ("Client exiting")
17.01.41 Join    muesli- [0] (n=muesli_t@141.71.4.220)
17.05.23 #       <mirak> hem what does it mean when it's said that rockbox doesn't do dynamic memory allocation ?
17.05.44 #       <linuxstb> There is no malloc() 
17.06.03 #       <linuxstb> (apart from a very restricted implementation used by some of the codecs - but that's an exception)
17.06.17 Quit    muesli- ("ich will Kühe!!!")
17.06.55 #       <mirak> so how can you know what memory you can use ?
17.07.11 #       <preglow> man, how i hate ifdefs
17.07.20 #       <preglow> you take whatever you need
17.07.21 #       <preglow> then use it
17.07.26 Join    muesli- [0] (n=muesli_t@141.71.4.220)
17.07.34 #       <preglow> if you need 256 bytes, you just do char buf[256]; then use that
17.07.57 #       <mirak> ok
17.08.27 #       <mirak> what's the difference with the malloc then ?
17.08.34 #       <XavierGr> Question: What #if would you recommend for the file scroller plugin? It is based on plugin memory needs.
17.08.34 #       <preglow> linuxstb: btw, you changed the backlight timer, yes? does it seem accurate on longer times?
17.08.44 #       <mirak> (I am mostly do java actually, so that's a bit far for me now)
17.09.00 #       <preglow> mirak: the difference is that we don't need to keep a lot of memory free so you can use malloc
17.09.36 #       <mirak> ok, don't know what malloc is doing exactly
17.09.36 Quit    edx (Read error: 104 (Connection reset by peer))
17.09.49 #       <preglow> mirak: malloc finds a large enough space of free memory, then lets you use that
17.10.03 #       <preglow> mirak: that memory can't be used any place else in rockbox, so we need a large free pool of memory
17.10.23 #       <preglow> mirak: wasting space like that is bad in rockbox, since we need all the memory we can get for the file buffer
17.10.25 #       <linuxstb> preglow: No, changing the default in settings.c doesn't work unless I reset the settings...
17.10.26 #       <mirak> but malloc doesn't take what you say him to take only ?
17.10.43 #       <mirak> ok nevermind
17.10.44 #       <mirak> lol
17.10.46 Quit    hshah ("Leaving")
17.11.05 #       <preglow> mirak: yes, but since we never know how much memory people are going to need, we have to reserve rather a lot of space
17.11.17 #       <linuxstb> mirak: malloc() also has a corresponding free() function - it's the free() function that's the main troublemaker.
17.11.47 #       <preglow> bah, i should get keys working
17.11.47 #       <linuxstb> So it's probably more informative to say that Rockbox doesn't have free().
17.12.00 Quit    San||Away (Read error: 110 (Connection timed out))
17.12.05 #       <preglow> we should write a faq entry on this
17.12.23 #       <mirak> linuxstb: so how the space allocated is given back ?
17.12.33 #       <linuxstb> It never is.  That's the point.
17.12.46 #       <mirak> mmm
17.13.07 #       <amiconn> malloc() on a platform like rockbox has some drawbacks: (1) it needs a memory pool for allocation, which can't be used otherwise. We want to use most RAM for buffering, so that would be a waste.
17.13.47 ***     Saving seen data "./dancer.seen"
17.14.08 #       <PaulJ> can someone explain to me what exactly the crossfadeoptions "fade in delay" and "fade out delay" mean? (this is missing in the wikimanual)
17.14.09 #       <amiconn> (2) error handling would become more complex, because a malloc() can fail. It would also be more confusing for the user, why a feature works one time, but not the other, even with proper error messages
17.14.29 #       <mirak> when you declare a new variable, a char  buf[256]; how can you know it will not give the memory adress of an existing programm ?
17.14.30 #       <XavierGr> plugin_get_buffer is a nice example of "like" memory allocation in rockbox.
17.14.43 #       <XavierGr> as linuxstb taught me.
17.14.53 #       <amiconn> (3) On platforms without a MMU, we would also run into memory fragmentation problems with a true malloc() implementation
17.14.56 #       <mirak> ok
17.14.58 #       <linuxstb> mirak: Rockbox is just a single program - the compiler takes care of allocating the static buffers.
17.15.05 #       <Slasheri> in fact it could be possible to do malloc quite working but then we would need to implement a function like p = refresh(p); that would memmove and relocate the allocated memory
17.15.35 #       <mirak> ok so that's still less confusing than assembler then ^^
17.15.40 #       <linuxstb> That sounds like memory handles which need to be de-referenced before accessing.  OSes like Symbian use those IIRC
17.15.51 #       * amiconn really likes assembler
17.16.31 #       <amiconn> mirak: Have a look at memcpy_a.S ;)
17.16.34 #       <preglow> assembler is nice
17.16.53 #       <linuxstb> amiconn: I'm sure you would love the ARM...
17.16.57 #       <mirak> ok, so when you exit a plugin, what happens ?
17.17.20 #       <preglow> amiconn: nice, shiny risc assembler
17.17.34 #       <amiconn> linuxstb: I'm not so sure...
17.17.37 #       <amiconn> I'm biased
17.17.43 #       <preglow> arm is lovely for assembler
17.17.47 #       <preglow> there can be no doubt about it
17.17.54 #       <preglow> one of the nicer asm variants i have seen
17.18.09 #       <linuxstb> mirak: There is a fixed block of memory (32KB for Archos, 768KB for iriver) assigned for plugins - all the code and data go in there. 
17.19.01 Join    hshah [0] (n=hshah@shahassociates.plus.com)
17.19.03 #       <amiconn> Slasheri: Hmm, the memory handle idea could actually work - if the overhead isn't too big
17.19.14 #       <preglow> btw, can't we decrease the 768kb a bit?
17.19.20 #       <preglow> 512kb sounds like it should be enough
17.19.20 #       <amiconn> I think so
17.19.25 #       <amiconn> Yes
17.19.25 #       <Slasheri> amiconn: true, especially if the allocated memory chunks are small
17.19.35 #       <linuxstb> That would ruin XavierGr's changes to the JPEG viewer though...
17.19.52 #       <preglow> does that use plugin space?
17.20.02 #       <amiconn> preglow: 512KB/32MB == 32KB/2MB, just by coincidence...
17.20.05 #       <preglow> jpeg has heaps of memory left even then
17.20.22 #       <preglow> jpeg is only 26kb big, tons and tons of memory left
17.20.23 #       <preglow> besides
17.20.42 #       <linuxstb> The jpeg viewer currently uses the audio buffer for the actual image buffer - XavierGr is changing it to use the plugin buffer if there is enough room.
17.20.48 #       <preglow> yup
17.21.04 #       <linuxstb> Plus adding a slideshow type feature IIUC.
17.21.15 #       <amiconn> You can get quite far with 512KB (minus 26KB for the plugin)
17.21.18 #       <preglow> but i think reserving plugin space just because of features like that is a bit... wrong
17.21.44 #       * amiconn would like to get down codec ram size as well
17.21.56 #       <preglow> i think 512kb sounds nice
17.22.01 #       <amiconn> Bad aac ;)
17.22.06 #       <preglow> hmm
17.22.09 #       <preglow> aac needs work
17.22.22 #       <linuxstb> Yes, the codecs also have a huge 512KB malloc buffer which should be reduced or even removed.
17.22.28 #       <XavierGr> Even if you change the plugin memory to 512 my change still work
17.22.48 #       <XavierGr> It is just that it would fit smaller pictures.
17.22.48 #       <linuxstb> Is it still as useful?
17.23.03 #       <amiconn> The biggest plugin is rockboy, and even that needs a little less than 400 KB
17.23.16 #       <preglow> it would still be useful, but yes
17.23.31 #       <preglow> i'd probably love the feature, but i still don't think the needs of just one plugin merits keeping the plugin buffer huge
17.23.45 #       <XavierGr> what feature?
17.23.52 #       <linuxstb> Your feature.
17.23.54 #       <preglow> your jpeg plugin extensions
17.23.55 #       <XavierGr> ah
17.24.08 #       <XavierGr> it will be still usable if set to 512
17.24.27 #       <preglow> yup
17.25.00 #       <XavierGr> 29 kb for plugin + 86kb (I think) for grayscale + (number of entries) * 1 byte
17.25.05 #       <XavierGr> the reset for the picture
17.25.15 #       <XavierGr> ^rest
17.26.35 #       <mirak> so if I declare many times a variable in a block ( a loop for exemple) will it take all the space in ram ?
17.27.09 #       <preglow> aac.codec is actually smaller for ipod
17.27.24 #       <preglow> mirak: no
17.27.31 #       <preglow> mirak: it will just stay one variable
17.28.01 Quit    b0br ("CGI:IRC")
17.28.27 #       <preglow> linuxstb: what to do about the udelay() calls? use something else or just include that as well?
17.28.36 #       <preglow> what does other driver code use for delays?
17.29.26 #       <linuxstb> I don't think anything else has delays yet.
17.29.36 #       <Slasheri> mirak: you can think that everything inside { } makes the stack one step deeper and variables inside that block are allocated from the stack. However, at the end of }, one level of stack is freed. So for(..) { .. } would increase and decrease the stack on every loop
17.30.10 #       <linuxstb> preglow: There are loops for things like "wait_not_busy" which use current_tick to implement a timeout whilst waiting for a hardware register to change.
17.30.22 #       <preglow> i need 5 musecs of delay, hehe
17.30.52 #       <preglow> thin i'll just stuff udelay in for now
17.30.56 #       <mirak> Slasheri: ok
17.31.43 #       <linuxstb> preglow: Yes, put udelay somewhere central - maybe an inline function in system.h
17.32.56 #       <preglow> ok
17.32.59 #       <preglow> i wont yield inside it
17.33.07 #       <preglow> so it's just for driver use
17.36.31 Quit    Febs ()
17.39.13 Join    Moos [0] (i=DrMoos@m196.net81-66-159.noos.fr)
17.39.23 #       <Lynx_> so, does the iaudio x5 play all xvid files, or do they have to be of a special size and such?
17.40.09 #       <preglow> hahah
17.40.22 #       <mirak> damn i am reading xvid decoder
17.40.23 #       <preglow> you think it'll full size 640x480 xvids at 25fps? :P
17.40.45 #       <preglow> insert 'play'
17.40.54 #       <mirak> the H300 ?
17.40.56 #       <mirak> :D
17.41.17 #       <mirak> 220*174 25fps would be fine yes
17.41.34 #       <mirak> though after seeing the cube running, I am wondering if the screen doesn't have to much latency
17.41.41 #       <linuxstb> mirak: Which xvid decoder are you looking at?
17.41.45 #       <mirak> to use above 10 fps
17.41.53 #       <XavierGr> mirak: no kidding. you have an xvid video in rockbox playing?
17.42.04 #       <mirak> linuxstb: I apt-get source xvidcore
17.42.10 #       <mirak> XavierGr: rofl
17.42.13 #       <linuxstb> Does it use floats?
17.42.21 #       <mirak> it seems it doesn't
17.42.26 #       <mirak> I have seen only int
17.42.28 #       <mirak> uint
17.42.55 #       <mirak> for interpolation I don't know yet
17.43.03 #       <mirak> it's in other files I haven't checked
17.43.10 #       <linuxstb> Do you know what license it is released under?
17.43.28 #       <mirak> that's on debian so it should be ok
17.43.43 Join    lush [0] (n=42993aea@labb.contactor.se)
17.43.47 #       <lush> hola guys
17.43.53 #       <mirak> This program is free software ; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by
17.43.54 #       <mirak> blabla
17.44.29 #       <mirak> there is assembly optimisations
17.44.35 #       <mirak> not for coldfire ;)
17.44.40 Quit    lush (Client Quit)
17.44.55 #       <linuxstb> What about ARM?
17.46.24 #       <mirak> nope
17.46.54 #       <mirak> anyway I don't see why they would use float, most of the time everything is converted to discret stuffs, even for fourier computations
17.47.02 #       <linuxstb> Get porting then :)
17.47.22 #       <mirak> that's my main motivation
17.47.23 #       <mirak> but well
17.47.28 #       <mirak> you know :)
17.48.09 #       <mirak> I am interested in knowing how mpeg compression works.
17.48.25 #       <mirak> that's not from that code that I will learn that I think
17.48.32 #       <preglow> haha
17.48.37 #       <preglow> i wouldn't want to learn that from the code
17.48.41 #       <preglow> mpeg4 isn't that complex
17.48.42 #       <mirak> nope
17.48.50 #       <preglow> still builds on good old mpeg1/2 methods
17.48.59 #       <mirak> I don't know them
17.49.12 #       <preglow> a good first step is finding out how jpeg works
17.49.17 #       <mirak> I have studied some things related to that in univ though
17.49.21 #       <preglow> then after that learning about motion estimation
17.49.29 #       <preglow> and entropy coding
17.49.44 #       <mirak> that's what I learned. motion estimation for tracking etecetera
17.49.56 #       <mirak> c'etait imbaisable
17.50.01 #       <mirak> like we say here
17.50.15 #       <mirak> (traduction : it was unfuckable)
17.50.25 #       <preglow> would most definitely be hard
17.51.00 #       <mirak> I got 10 at this exam. it was about fourier transformation and stuffs
17.51.15 #       <mirak> my god
17.51.47 #       <preglow> ten being how good?
17.51.55 Quit    hshah ("Leaving")
17.53.20 #       <mirak> 10/20
17.53.24 #       <mirak> not less not more
17.54.15 #       <mirak> it could have been worse, I didn't do pure mathematics for 2 years before doing that.
17.58.23 #       <preglow> haha
17.58.29 #       <mirak> preglow: ! ok I have studied that but we didn't seen how to use that for compression
17.58.37 #       <preglow> use what?
17.58.50 #       <mirak> hem discret fourier transformation
17.59.11 #       <preglow> it's just a matter of removing coefficients that aren't imptant
17.59.15 #       <preglow> important!
17.59.21 #       <preglow> and coding the result
17.59.24 #       <mirak> right !
17.59.29 #       <mirak> I remember
17.59.35 #       <mirak> we cut the frequencies
18.00.00 #       <mirak> however for me it would have been better to study that for sound
18.00.20 #       <mirak> because in 2 dimension that's not very clear what happens
18.00.47 #       <mirak> a spectral representation of a sound wave is interpretable
18.01.09 #       <mirak> and understandable, while for an image that's really not the case
18.01.28 #       <mirak> so you studied that ?
18.02.10 #       <preglow> studied and studied
18.02.14 #       <preglow> it's more a hobby thing
18.03.12 #       <mirak> lol, fourier transform as a hobbi
18.03.14 #       <mirak> why not :)
18.04.34 #       <preglow> haha
18.04.35 #       <preglow> well
18.04.36 #       <preglow> a part of it
18.04.43 #       <preglow> fourier transform isn't exactly my main area of expertise
18.07.27 #       <mirak> what's your dada ?
18.07.57 #       <preglow> dada?
18.08.16 #       <mirak> your passion
18.08.28 #       <mirak> your main domain of expertise
18.09.18 #       <preglow> right
18.09.21 #       <preglow> god known
18.09.25 #       <preglow> sound synthesis, i'd guess
18.09.31 #       <preglow> which includes quite a few areas again
18.09.48 #       <preglow> more or less anything that has to do with sound
18.09.57 #       <mirak> you did the vocal stuff for archos ?
18.10.02 #       <preglow> nono
18.10.07 #       <mirak> like fart sound ?
18.10.07 #       <preglow> that was [idc]dragon
18.10.26 #       <mirak> sorry ... :)
18.13.30 #       <mirak> I had a module of vocal recognition
18.13.43 #       <mirak> I got 17/20 but it was a bit sucky
18.17.50 Join    lush [0] (n=42993aea@labb.contactor.se)
18.17.55 #       <lush> ello?
18.18.04 #       <lush> anybody home/
18.18.06 #       <lush> ?
18.18.10 #       <muesli-> nope
18.18.27 #       <lush> hey just started using the rockbox fw on my iriver h120 and i frekking love it
18.18.32 #       <lush> but it wont play back my wma files
18.18.37 Join    NicoFR [0] (n=nico404@rob92-6-82-231-243-63.fbx.proxad.net)
18.18.44 #       <lush> it just skips em, and then says codec error
18.18.56 #       <lush> any idea as to why?
18.19.00 #       <muesli-> it wont in near future..mayb sometime
18.19.14 #       <lush> huh?
18.19.32 #       <linuxstb> Rockbox doesn't have a WMA decoder.
18.19.45 #       <linuxstb> So it can't play wma decoders until someone decides to write one.
18.20.00 #       <linuxstb> I mean it can't play wma files...
18.20.06 #       <lush> ok i got ya
18.20.09 #       <lush> thanks,
18.20.30 #       <lush> hey one other question,
18.20.40 #       <lush> how do you add plugins to the player?
18.20.58 #       <lush> do i dl em and then just, copy them over to the rockbox dir?
18.21.29 Quit    XavierGr (Read error: 110 (Connection timed out))
18.21.41 #       <muesli-> copy them where you want
18.21.47 #       <muesli-> it doesnt matter
18.21.51 #       <lush> nice
18.22.02 #       <lush> same for those wps things that are the skins?
18.22.15 #       <muesli-> see .rockbox/wps
18.22.23 #       <lush> nice
18.22.27 #       <lush> thanks for the help
18.22.34 #       <muesli-> no worries
18.22.49 #       <lush> this stuff is soo much better than default crap
18.23.07 #       <muesli-> 100% agree ;)
18.23.08 Quit    lush ("CGI:IRC (EOF)")
18.23.23 Join    webguest34 [0] (n=52e30123@labb.contactor.se)
18.23.36 Quit    webguest34 (Client Quit)
18.23.51 Join    dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU)
18.29.19 #       <mirak> exept for video ...
18.29.21 #       <mirak> ;D
18.29.37 #       <muesli-> time will tell ;)
18.29.41 Join    DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se)
18.31.41 #       <preglow> man, button drivers are not my favourite
18.34.48 Join    paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822)
18.37.12 #       <preglow> linuxstb: are there any ipod special cases hanging around that you know about?
18.39.12 #       <linuxstb> No, I think the current_tick was the last one.
18.39.29 #       <linuxstb> What's the problem?
18.39.36 #       <preglow> just wondering
18.39.43 #       <preglow> i've implemented a small keyboard driver now
18.39.45 #       <preglow> and it hangs rockbox
18.40.54 #       <linuxstb> Does it crash immediately, or when you press a button?
18.41.18 #       <preglow> hangs at logo
18.41.19 Join    DrMoos [0] (i=DrMoos@m196.net81-66-159.noos.fr)
18.41.35 #       <preglow> got it
18.41.40 #       <preglow> was a dead giveaway
18.41.43 #       <preglow> i didn't ack the interrupt
18.42.10 #       <preglow> now it hangs when i press a button :-)
18.42.41 #       <linuxstb> That's progress...
18.42.55 Quit    Moos (Read error: 104 (Connection reset by peer))
18.43.11 #       <preglow> yes
18.44.11 Nick    DrMoos is now known as Moos (i=DrMoos@m196.net81-66-159.noos.fr)
18.44.14 Join    Mmmm [0] (n=3efc4010@labb.contactor.se)
18.44.27 #       <preglow> hmm, no
18.44.32 #       <preglow> it seems i'm still not acking the interrupt
18.44.41 #       <preglow> i must have touched the clickwheel the first time
18.44.44 #       <preglow> it behaves just the same
18.46.12 #       <amar> whare its the global_settings structure diffined?
18.46.26 Join    jlo [0] (n=jl@atm91-1-82-227-1-35.fbx.proxad.net)
18.46.37 #       <jlo> hi
18.46.43 #       <preglow> hi
18.48.11 Quit    muesli- ("ich will Kühe!!!")
18.50.15 #       <jlo> preglow : I did some test with Reaktor (I used soft this weekend because I have only harware at the office !), simulating crossfeed, now can you and markun tell me which music you'd like to test so I can do some recordings with/without
18.53.39 #       * preglow kicks markun
18.53.42 Join    San [0] (n=sanitari@A-72-3.cust.iol.ie)
18.55.17 #       <jlo> I'll come back later
18.55.20 Quit    jlo ()
18.57.25 Quit    Rick (Read error: 104 (Connection reset by peer))
19.00.23 Join    Mmmm_ [0] (n=3efc4010@labb.contactor.se)
19.00.38 #       <mirak> preglow: a keyboard driver on usb host ?
19.00.38 Quit    Mmmm ("CGI:IRC (EOF)")
19.00.59 Quit    NicoFR ()
19.02.03 #       <preglow> mirak: eh?
19.02.17 Join    akaidiot [0] (n=nope@c-ad45e255.363-1-64736c11.cust.bredbandsbolaget.se)
19.02.44 Join    Mmmm [0] (n=3efc4010@labb.contactor.se)
19.04.10 #       <preglow> i would kill for a data sheet
19.04.24 #       <preglow> http://www.portalplayer.com/company/info-form.htm
19.04.27 #       <preglow> someone try that :-)
19.07.01 #       <mirak> <preglow> i've implemented a small keyboard driver now
19.07.03 Join    XavierGr [0] (n=XavierGr@ppp13-adsl-1.ath.forthnet.gr)
19.07.11 #       <mirak> ?
19.07.32 Join    ender1 [0] (i=ychat@84.52.165.220)
19.07.47 #       <mirak> rockbox is better than ipod linux ?
19.07.55 #       <XavierGr> which is faster: memmove or memcpy?
19.08.20 #       <preglow> mirak: i'm talking about ipod
19.08.27 #       <preglow> mirak: depends what you want
19.08.32 #       <preglow> XavierGr: memcpy for now
19.08.41 #       <preglow> if you don't need memmoves functionality, use memcpy
19.08.50 #       <XavierGr> okay then it should be my preffered choice.
19.09.11 Join    edx [0] (i=edx@p54A861F0.dip.t-dialin.net)
19.09.23 #       <XavierGr> also on the jpeg viewer I saw that: #define MEMCPY(d,s,c) rb->memcpy(d,s,c)
19.09.41 #       <XavierGr> is that an optimization, should I use it that way or call with the rb api pointer?
19.10.02 #       <XavierGr> or it is just an alias?
19.10.07 #       <mirak> preglow: don't probably ipodlinux is less cryptic
19.10.17 #       <mirak> since we are maybe more used to linux
19.10.19 #       <mirak> don't know
19.10.46 #       <mirak> but well if rockbox is faster anyway
19.11.00 #       <preglow> nothing says it is
19.11.08 #       <preglow> rockbox and linux are two different approaches
19.11.11 #       <preglow> it depends what you want
19.11.18 #       <mirak> Rockbox's version is a lot smaller and faster, while IpodLinux's is bigger and slower but very well known, very well tested and offers a multitude of more services and features.
19.11.24 #       <mirak> http://www.rockbox.org/twiki/bin/view/Main/IpodLinux
19.12.57 #       <mirak> well actually for me the main difficulty with rockbox is that it's not clear what are syscalls usable from user programs, what is not etecetera
19.13.26 #       <mirak> but that just me, and I am starting
19.13.50 ***     Saving seen data "./dancer.seen"
19.15.04 Quit    ender` (Read error: 110 (Connection timed out))
19.16.38 Quit    einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
19.17.08 Join    Rick [0] (i=rick@pool-71-108-9-40.lsanca.dsl-w.verizon.net)
19.17.25 #       <preglow> most things are usuable from user programs in rockbox?
19.17.30 #       <preglow> s/?/./
19.19.58 #       <preglow> hah!
19.20.02 #       <preglow> it no longer hangs!
19.20.31 #       <preglow> i can activate backlight by keypress
19.20.36 Quit    akaidiota (Read error: 110 (Connection timed out))
19.20.59 #       <amiconn> XavierGr: (1) We don't have memmove() in rockbox yet. (2) The MEMCPY() macro is just for portability
19.21.33 #       <San> hey
19.21.47 Nick    San is now known as San||Halo (n=sanitari@A-72-3.cust.iol.ie)
19.22.00 Quit    Mmmm_ ("CGI:IRC (EOF)")
19.22.06 Quit    Mmmm ("CGI:IRC (EOF)")
19.22.41 Part    Polo_o
19.22.55 Join    Mmmm [0] (n=mscarrat@cpc3-hem13-3-1-cust169.lutn.cable.ntl.com)
19.26.04 #       <preglow> linuxstb: you there?
19.27.20 Join    petur [0] (i=petur@d54C1B62E.access.telenet.be)
19.28.18 #       <preglow> linuxstb: if you are, check out www.pvv.org/~thomj/rockbox/rockbox.ipod, please
19.28.27 #       <preglow> seems the hold switch functionality is done in hardware on the ipod
19.29.45 Join    yngwi [0] (n=chatzill@chello080109107064.1.15.vie.surfer.at)
19.34.14 #       <XavierGr> f*cking iriver fw.
19.35.00 #       <XavierGr> I try to debug, when my unti hungs and reset it then if I press play iriver fw starts instead of Rockbox, why?
19.35.21 #       <XavierGr> It takes ages to reboot when iriver fw starts... grrrr
19.35.24 #       <amiconn> preglow: detectable?
19.36.14 #       <preglow> amiconn: yes
19.36.20 #       <preglow> amiconn: that is, i think so
19.36.31 #       <preglow> amiconn: it's a bit strange, switching hold off seems to generate an interrupt
19.36.36 #       <preglow> amiconn: but switching on doesn't seem to
19.37.04 #       <preglow> i was wrong
19.37.05 #       <preglow> both do
19.38.11 #       <preglow> strange
19.38.24 #       <preglow> ipl installs two keyboard related interrupts, i only use one, and i seem to get all the interrupts i need
19.38.29 #       <mirak> preglow: that's what I don't know, I guess documentation will come with time
19.41.21 Join    jlo [0] (n=jl@atm91-1-82-227-1-35.fbx.proxad.net)
19.42.22 Join    webguest34 [0] (n=415ce17e@labb.contactor.se)
19.42.48 Join    xmixahlx [0] (n=xmixahlx@64.122.111.98)
19.44.24 #       <preglow> jlo: so, have you modelled your new crossfeed proposal yet?
19.45.29 Quit    edx (Read error: 110 (Connection timed out))
19.45.50 #       <jlo> preglow : yes, if you have reaktor, I can send you the modelling file
19.47.04 Join    _FireFly_ [0] (n=FireFly@p54A460EE.dip.t-dialin.net)
19.47.11 #       <jlo> I'll put wav files with/without correction on ftp
19.48.35 #       <preglow> haven't got reaktor here, i'm afraid
19.51.07 #       <jlo> preglow : so I put the schematics (in png) on http://www.ohl.to/iriver/  in the reaktor directory, have a look
19.53.13 Quit    webguest34 ("CGI:IRC")
19.53.32 #       <preglow> hmm
19.53.37 #       <preglow> those filters are second order
19.53.42 #       <preglow> i wish you wouldn't use them ;)
19.54.41 #       <jlo> preglow : the pb for you is that the filters are shelving , no?
19.55.13 #       <preglow> well, yeah, but i was hoping we'd be using first order filters
19.55.24 #       <preglow> and using second order filters instead of first order might give different results
19.55.36 #       <preglow> i think reaktor has got first order shelving filters as well
19.55.39 #       <preglow> in the core modules somewhere
19.55.47 #       <preglow> static eq filters or something
19.55.52 #       <jlo> preglow : it's first order (6dB/oct) but shelving
19.55.58 #       <preglow> oh, they are?
19.56.01 #       <preglow> then it's fine
19.56.07 Quit    Hooligan ()
19.59.47 #       <jlo> preglow : I first tested with correlated pink noise to check that no major tonal unbalance occurs, and after with different music tracks, but now I'd like to check also with your files
20.02.50 #       <preglow> gimme a sec and i'll se if i've got what markun gave me
20.02.51 Join    edx [0] (i=edx@p54A84D09.dip.t-dialin.net)
20.04.27 Join    _DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se)
20.05.10 #       <jlo> preglow : see http://www.stereo-balance.net/index.php?mod=wiki&w=headplug, he's giving the source of his winamp crossfeed plugin, have you allready looked that one ?
20.06.04 Quit    ender1 (Read error: 104 (Connection reset by peer))
20.07.14 #       <preglow> jlo: no i havenæt
20.07.15 Join    JazzBone [0] (n=JB@cc829402-a.groni1.gr.home.nl)
20.07.27 Join    Lear [0] (n=chatzill@h73n11c1o285.bredband.skanova.com)
20.07.52 Join    zeero [0] (n=nick@fw.cerisent.com)
20.08.13 #       <XavierGr> OK The new JPEG plugin viewer is ready. Any testers? (Especially arhos users) I will upload it to the patch tracker soon.
20.08.23 Join    ender` [0] (n=ender@84.52.165.220)
20.09.13 #       <XavierGr> I manged to do quite well to my tests. 1074 files 75 characters each. (path doesn't matter, only filename)
20.09.20 #       <XavierGr> ^It
20.09.25 #       <zeero> so, maybe i'm a idiot to not be able to work this out, but i'd like to start helping out with the h300 effort now that i can get it on my player, but in building the sim, when i run ./rockboxui i get something that looks not at all like what i see on my player.  also, i can't work out what the keys for a-b and so on are, only up/down/left/right seem to work.  am i missing something obvious?
20.10.04 #       <XavierGr> Maybe you biuld a simulator for another target.
20.10.22 #       <XavierGr> Did you choose your model in coniguration?
20.10.26 #       <zeero> XavierGr: i selected the h300 in config
20.10.51 #       <XavierGr> what do you use: cygwin, devkit, linux?
20.11.00 #       <zeero> linux
20.14.38 #       <XavierGr> I can't help you. I use the devkit
20.15.13 #       <petur> zeero: do you use w32 (wine) or x11?
20.18.33 #       <jlo> preglow : I'll put on the web three anonymous files (original, rb crossfeed, my version, winamp plugin) so you can try with abc/hr soft (http://ff123.net/abchr/abchr.html) the one you prefer. if you and others can use it, I can do it for other tracks
20.19.09 #       <preglow> ok
20.19.48 Quit    tvelocity ("Leaving")
20.19.58 #       <jlo> preglow :  I think In
20.20.00 #       <petur> Slasheri, are you around?
20.20.12 #       <jlo> I think I need an hour or so
20.20.14 Quit    DangerousDan (Read error: 110 (Connection timed out))
20.20.21 #       <preglow> jlo: that's ok, i'll still be here then
20.22.00 #       <Slasheri> petur: yes, hi
20.22.19 #       <petur> got a quick Q about the H1xx backlight dimming
20.22.24 #       <petur> yours?
20.22.34 #       <Slasheri> hmm, original code yes
20.23.01 #       <petur> is that dimming through a timer routine switching on/off?
20.24.04 #       <Slasheri> yes, with cpu timer interrupt. So we have a fixed cycle time and then the on and off pulse times are being modified
20.24.31 #       <petur> software PWM then... the H1xx has only on/oof, no PWM?
20.24.33 #       <zeero> x11
20.24.44 #       <petur> zeero: x11 sim seems broken
20.24.46 #       <Slasheri> yep, pure software pwm :)
20.24.53 #       <petur> ok thanks.
20.25.06 #       <petur> wanted to be sure I understood what I saw
20.25.06 #       <Slasheri> it might have pwm on some outputs, but not on that backlight output at least
20.25.11 #       <zeero> petur: hrmm, does the wine one work?
20.25.19 #       <petur> yes
20.25.30 #       <zeero> petur: k, thanks, i'll try building that
20.25.37 #       <linuxstb> preglow: I've just tried your build - I can turn the backlight back on...
20.25.51 #       <petur> can't help with wine, using W2K here ;)
20.26.02 #       <petur> (that's windows2000)
20.26.12 #       <petur> but it should work
20.26.24 #       <zeero> petur: nod, dang, so i need a cross compiler to do that though huh?
20.26.46 #       <linuxstb> Yes - which linux distro are you using?
20.27.03 #       <Slasheri> linuxstb: btw, now the tag cache has a stable building routine that should most definately work on archos too and simple artist listing. Seems to work pretty well :) But still many things left to be done..
20.27.04 #       <zeero> linuxstb: redhat el4
20.27.21 #       <zeero> linuxstb: i have a debian box i can use too, but i'd prefer to do it on this one
20.27.47 #       <linuxstb> zeero: On Debian, you can just do "apt-get install mingw32" to install the Windows cross-compiler.  I've no idea about RH.
20.28.04 #       <petur> LinusN: have you tried different backlight PWM values on the pcf50606? Is there a safe range or do they all work?
20.28.11 #       <linuxstb> Slasheri: Nice.  Are you far away from having something others can try?
20.28.37 #       <LinusN> petur: most values flicker
20.28.39 Quit    jlo (Read error: 104 (Connection reset by peer))
20.28.44 #       <Slasheri> linuxstb: not very far, but still that code is not very usable. Maybe in one or two weeks :)
20.28.55 #       <zeero> linuxstb: k, thanks, i'll poke around a bit and see if there's an rpm somewhere (how i wish apt worked as well for redhat as it did for debian)
20.28.55 #       <petur> I wonder how iRiver does it then
20.29.24 #       <petur> no harm to try them all? I mean: over-volting the backlight or something?
20.30.20 #       <preglow> linuxstb: backlight turns on when you press something, yes=
20.30.25 #       <Slasheri> linuxstb: at least the api to the tag cache is now quite simple. For example listing all artists: struct tagcache_search tcs; tcs.type = tag_artist; tagcache_search(&tcs); while (tagcache_get_next(&tcs)) { do_something(tcs.result, tcs.result_len) } tagcache_search_finish();
20.30.32 #       <petur> LinusN: did you play with the frequency as well?
20.30.39 #       <linuxstb> preglow: Yes.  For the hold switch as well.
20.30.44 #       <preglow> linuxstb: excellent
20.31.01 #       <petur> reason: want to have a go at configurable backlight
20.31.07 #       <linuxstb> So it looks like the hold switch is hardware?
20.31.12 #       <preglow> linuxstb: indeed
20.31.20 #       <preglow> linuxstb: all i do currently is register and handle the interrupt
20.31.32 #       <preglow> linuxstb: no other handling is done by me, and the keys are ignored when hold is on
20.31.45 #       <LinusN> petur: yes
20.32.08 #       <petur> is 512Hz what iRiver uses or your best pick?
20.32.18 #       <LinusN> petur: feel free to experiment
20.32.18 #       <linuxstb> preglow: Have you looked at this code? http://opensvn.csie.org/courtc/tools/ipodloader2/keypad.c
20.32.25 #       <petur> willco
20.32.26 #       <preglow> linuxstb: somewhat
20.32.29 #       <LinusN> petur: that's whet the original uses
20.34.18 #       <petur> LinusN: you didn't find out how they set the different levels...
20.34.54 #       <XavierGr> ok here is the patch for the viewer. Please test or give me your opinion. Thanks.
20.34.55 #       <XavierGr> https://sourceforge.net/tracker/?func=detail&aid=1266294&group_id=44306&atid=439120
20.35.08 #       * preglow looks forward to getting multicore support going......
20.35.12 #       <LinusN> petur: no
20.35.22 #       <petur> ok, thanks
20.35.23 #       <preglow> i'm going to need divine intervention or a lot of help
20.35.58 #       <Slasheri> linuxstb: i think that in future even an integrated tag editor to the tag cache browser would be really nice :)
20.36.06 #       <Cassandra> preglow, scary stuff.
20.36.19 #       <preglow> Cassandra: got a bootloader stuffed in your ipod yet, btw?
20.36.45 #       <Cassandra> Yep.  For some reason it won't boot the original firmware when the Rockbox loader is on.
20.36.57 #       <preglow> mine can't boot it any longer either
20.37.05 #       <Cassandra> (Oh, and as I minor point, I think we should remove the penguin.)
20.37.14 #       <petur> :D
20.37.26 #       <preglow> doesn't seem much point in keeping it anymore, no, unless we want it as some absurd "thank you" to the ipl people
20.37.51 Quit    Mmmm ()
20.37.55 #       <Cassandra> Well, I think that it says "Rockbox/iPod Linux bootloader is enough of a nod.
20.38.06 #       <amiconn> preglow: I think multicore support is the most interesting part of the ipod port...
20.38.49 #       <zeero> petur: so, any idea if/when the x11 version will be fixed, and what's wrong with it?
20.38.52 #       <preglow> amiconn: it'll need some thinking
20.39.07 #       <petur> zeero: no idea, never used it...
20.39.13 #       <preglow> amiconn: i think we will want to dedicate the second core to codecs, but again, there will be nuances that will need resolving
20.39.20 #       <preglow> amiconn: i think you should get one to help me along :)
20.39.24 #       <Cassandra> Multiprocessor Rockbox. Scary.
20.39.24 #       <zeero> petur: okay, thanks
20.39.34 #       <petur> you could always fix it ;)
20.39.42 #       <Cassandra> I suspect Rockboy is going to need both processors.
20.39.50 #       <Cassandra> But we can always not bother with that.
20.39.53 #       <amiconn> Nah, no ipod for me, that's for sure
20.40.35 #       <preglow> think of all the glorious asm!
20.40.40 #       <Cassandra> Why not amiconn?
20.41.11 #       <preglow> leaving the n00bs to it is irresponsible :P
20.41.19 #       <mirak> preglow: I shoudln't have erased Matlab
20.41.29 #       <mirak> (to test compression)
20.41.33 #       <mirak> :D
20.41.34 #       <preglow> matlab's nice
20.41.52 #       <mirak> yes to have a math approach
20.42.00 #       <mirak> matrix computing is easy and handy
20.42.01 #       <Moos> amiconn: apple allergy like here? :D
20.42.29 #       * Cassandra thinks the Nano is very pretty.
20.42.33 #       <petur> LinusN: sorry to irq again: do you think there would be a problem setting the prescaler to something like 7kHz?
20.42.40 #       <preglow> the nano is the prettiest one
20.42.42 #       <Cassandra> (Although obviously way too small.)
20.42.43 #       <preglow> the rest look worse
20.42.46 #       <amiconn> I don't like the design, and many details distract me as well
20.43.10 #       <amiconn> ...like the docking connector instead of a standard USB socket, and the worst thing - the touch wheel
20.43.31 #       <Cassandra> I quite like the touch wheel.
20.43.34 #       <preglow> me too
20.45.35 #       <LinusN> petur: try it
20.45.38 #       <LinusN> i gotta go
20.45.42 Part    LinusN
20.45.43 #       <amiconn> The only pro of the Nano is that it's really thin, but that's about it
20.46.35 #       <Cassandra> The Nano gives me tech lust.
20.46.46 #       <Cassandra> Apple make a 60gb version and I'm so there. ;)
20.47.41 #       <preglow> haha
20.47.46 #       <preglow> four gig is enough for anyone!
20.47.59 #       <amiconn> haha
20.48.09 #       <preglow> Cassandra: how many gigs is yours?
20.48.18 #       * amiconn prefers the expandable storage of the Ondio
20.48.23 #       <Cassandra> 2.
20.48.27 #       <preglow> mine too
20.48.32 #       <preglow> i can't be bothered with memory cards
20.48.43 #       <Moos> amiconn: me too, it's why I bought one
20.48.53 Join    webguest25 [0] (n=415ce17e@labb.contactor.se)
20.49.13 #       <Cassandra> I never know what kind of mood I'm going to be in.  I like to have all my music with me.
20.49.23 #       <preglow> good point
20.49.33 #       <Moos> indeed
20.49.41 #       <preglow> but i plan on using my h120 for my main player anyway
20.49.47 #       <preglow> and the nano more for small trips and the like
20.49.50 #       <zeero> so, what's the right way to create the .rockbox dir for the sim?  (make zip and then unzip in the archos dir?)
20.49.52 #       <preglow> where the size is nice
20.49.56 #       <Cassandra> Also random shuffle is better with your whole collection.  Means you listen to stuff you've forgotten about.
20.50.06 #       * Moos waiting for 80 GO Toshiba HD
20.50.07 #       <linuxstb> zerro: "make install" - which I think is just a zip and unzip
20.50.14 #       <linuxstb> (sorry, zeero)
20.50.15 #       <amiconn> Moos: One day I'll write a file management plugin if no-one does it before. Then there are many new possibilities, like updating rockbox from a memory card, without the computer around...
20.50.26 #       <amiconn> ...or copying files from one Ondio to another
20.50.29 #       <Moos> O.O
20.50.38 #       <zeero> linuxstb: so that puts everything in the archos dir?
20.50.44 #       <linuxstb> Yes.
20.50.49 #       <Cassandra> What I want is something that will store about 500 albums lossless.
20.50.50 #       <zeero> cool, thanks
20.50.52 #       <Moos> amiconn: that sounds good
20.51.01 #       <Cassandra> (I only own 250 or so, but room to expand is good.)
20.51.05 #       <amiconn> An unzip plugin would do for a start
20.51.21 #       <zeero> ahh, the wine version seems to work quite nicely :)
20.51.37 #       <preglow> someone start porting sims to sdl!
20.51.56 #       <Cassandra> Huh?
20.52.00 #       <petur> does wine support sound as well?
20.52.17 #       <Moos> amiconn: be sure anyone will work on it until you, not a lot of ondio dev :(
20.52.22 #       <zeero> petur: checking :)
20.53.07 #       <zeero> petur: hrmm, seems like no :( i get a unhandled div by zero
20.53.14 #       <Moos> amiconn: is you and [IDC]Dragon, ported Rockbox on Ondios, right?
20.53.14 #       <petur> the current w32 sim isn't OK, I wrote a patch (1375787) that fixes this
20.53.20 #       <amiconn> petur: It does, at least for me
20.53.24 #       <linuxstb> zeero: I think you have to manually enable it by setting ROCKBOX_HAS_SIMSOUND in the autoconf.h
20.53.28 #       <amiconn> Moos: yes
20.53.29 #       <petur> And that is fixed as well in another patch
20.53.43 #       <zeero> linuxstb: ahh, okay, let's try that
20.54.12 #       <amar> can anyone tell me where is the global_settings structure is deffined?
20.54.38 #       <zeero> linuxstb: do i define it as 1?
20.54.39 #       <amar> or is that a very stupid question
20.54.53 #       <linuxstb> zeero: Yes, define it as anything.
20.55.00 #       <zeero> okay, cool
20.55.05 #       <linuxstb> It's just checked using #ifdef
20.55.08 #       <amiconn> Moos: [IDC]Dragon figured out most hardware tidbits and added FAT16 support, I wrote the MMC driver and helped debugging FAT16
20.55.12 #       <zeero> ahh, nod
20.55.43 #       <linuxstb> amar: apps/settings.h
20.55.51 #       <petur> amiconn: the cvs implementation either doesn't play or gives 100% cpu load (Sleep(0) or Sleep(1))
20.55.51 #       <amar> thanks
20.55.51 #       <XavierGr> don't try to delete a folder with 2000+ files using rockbox.....
20.55.53 #       <amiconn> Many small contributions from other authors of course, like the soft button definitions etc
20.56.02 #       <Moos> ok
20.56.52 #       <amiconn> Oh, and since it was me who bought the Ondio SP, I had to adjust rockbox to the differences between MAS3587 and MAS3539
20.57.06 #       <amiconn> Now I have both an FM and the SP ...
20.57.07 #       <zeero> petur/linuxstd: sound works fine with that def :)
20.57.44 #       <preglow> haha
20.57.50 #       <preglow> sell one and get a nano!
20.58.15 #       <HCl> hows rockbox with the nano?
20.58.23 #       <preglow> HCl: it responds to keypresses now...
20.59.14 #       <HCl> k
20.59.51 Join    mojo [0] (n=mojoski@170.252.248.207)
21.00.14 #       <mojo> hey everyone.. Anyone alive?
21.00.15 #       <amiconn> preglow: The nano flash access is boooring, as it just uses the standard ata driver ;)
21.00.28 #       <mojo> oops, sorry
21.01.09 #       <preglow> amiconn: lucky for me, i don't think i enjoy that kind of programming
21.01.23 #       <amiconn> Oh, forgot that [IDC]Dragon added philips tuner support, which was then helpful on iriver too
21.01.42 #       <preglow> my, i'd love some datasheets about now
21.02.20 #       <Moos> amiconn: is there one hardware limitation of MMC capacity? I mean in the future is there one size limit max?
21.03.24 #       <Moos> 4go, no?
21.03.28 #       <amiconn> Yes
21.03.43 #       <Moos> ok
21.03.46 #       <amiconn> The current MMC protocol uses byte addressing with a 32 bit address
21.03.58 Quit    solexx (Read error: 104 (Connection reset by peer))
21.04.25 #       <Moos> 10 little cards equivalent of my iriver :)
21.04.33 #       <amiconn> Afaik, even MMC4.0 doesn't raise the limit, it only defines faster transfer modes (with additional contacts)
21.04.38 Join    solexx__ [0] (n=jrschulz@c187206.adsl.hansenet.de)
21.05.18 #       <Moos> thanks for he infos
21.05.31 #       * Moos going to do some food
21.06.06 #       <amiconn> In case some future standard allows more than 4GB, and this standard would still support SPI mode, rockbox could be adapted to support it
21.06.20 #       <Moos> Cool !
21.06.47 #       <amiconn> The USB->MMC brigde wouldn't understand it, but that's not a big problem on the Ondio. You would just need a card reader to fill the card
21.07.10 Quit    San||Halo (Read error: 110 (Connection timed out))
21.07.36 #       <_FireFly_> amiconn: about unzip i have some functions which can read uncompressed zip-file
21.08.06 #       <linuxstb> We definitely need to speed up wps loading somehow.
21.08.19 #       <_FireFly_> linuxstb: ??
21.08.47 #       <_FireFly_> amiconn: with crc
21.08.50 #       <preglow> i thought bmp loading was what took time
21.08.53 #       <linuxstb> Loading the 500 tiny bitmaps...
21.08.58 #       <linuxstb> That's what I mean.
21.09.03 #       <_FireFly_> linuxstb: ah yes
21.09.15 #       <_FireFly_> mine combined-bitmap support could help
21.09.17 #       <_FireFly_> a bit
21.09.32 #       <_FireFly_> but it isn't very userfriendly :)
21.09.59 #       <_FireFly_> because they need to merge the images together yourself 
21.10.21 #       <preglow> still
21.10.26 #       <preglow> i think that approach is definitely best
21.10.34 #       <Slasheri> Hmm, just combine the bitmaps runtime and create a fast binary version of the current wps?
21.10.49 #       <preglow> combine bitmaps runtime?
21.10.52 #       <preglow> then you need to load them anyway
21.10.58 #       <Slasheri> when loading the wps first time
21.10.59 #       <linuxstb> The build script could combine the bitmaps into a single file.
21.11.07 #       <Slasheri> that's true
21.11.29 #       <_FireFly_> linuxstb: but how to discover the position of the images in the image
21.11.43 #       <linuxstb> The build script knows them (it put them there)
21.11.53 #       <linuxstb> So the build script would have to modify the wps.
21.11.58 #       <_FireFly_> yepp
21.12.06 #       <amiconn> I don't see a problem with all gfx in one image
21.12.08 #       <linuxstb> Maybe not a 5 minute job though...  
21.12.37 #       <linuxstb> amiconn: I agree, but it's more awkward for users to produce them like that.
21.12.46 #       <amiconn> In fact, I think editing wps graphics is easier this way, instead of dealing with dozens of tiny bitmaps
21.13.51 ***     Saving seen data "./dancer.seen"
21.14.37 #       <_FireFly_> my wps for example has fit all used images in an the image which was the background-image 
21.16.07 #       <_FireFly_> the size is 160x25 pixel
21.16.50 #       <preglow> linuxstb: i wonder how to handle repeat with an interrupt based driver
21.16.57 #       <preglow> linuxstb: i hope the hardware deals with it...
21.17.14 Quit    perplexity (Read error: 113 (No route to host))
21.17.43 #       <preglow> might not be that hard anyway, of course, we'll see
21.19.11 #       <amiconn> Depending on whether you get an interrupt both for press and release, it might be simple
21.20.13 Quit    joshn_454 ("KVIrc 3.2.0 'Realia'")
21.20.20 #       <preglow> seems like i only get interrupts for press
21.20.32 #       <preglow> lemme check
21.20.53 #       <preglow> nope
21.20.54 #       <preglow> for release as well
21.21.10 #       <preglow> so i could just schedule a tick task to deal with it for me while a key is pressed
21.21.15 #       <amiconn> yup
21.22.01 #       <amiconn> The button handling wouldn't be all that different from the other platforms, just the button_status variable won't be updated by polling, but by the button interrupt(s) instead
21.22.21 #       <amiconn> The button tick could work the same way, just without the button_read() call
21.22.35 #       <_FireFly_> amiconn: the patch for combined bmp support is already on tracker but i must update it do the cvs-change which my wps-image-flicker fix had produced :)
21.25.11 #       <_FireFly_> amiconn: do you want my fns for reading uncompressed zip-files ??
21.25.51 #       <amiconn> No time for zip atm :/
21.26.52 #       <_FireFly_> hmm ok the only thing which would be hard to implement due the small amount on resources is an uncompression algo
21.27.17 #       <preglow> i don't believe that'd take much time
21.27.23 #       <preglow> depends on the files we're talking about
21.27.31 #       <amiconn> zip
21.27.34 #       <preglow> well, yeah
21.27.36 #       <preglow> but contents
21.27.40 #       <preglow> are we talking about zipping wpses here?
21.27.45 #       <amiconn> E.g.
21.27.52 #       <amiconn> rockbox.zip
21.27.56 #       <preglow> that would be a pretty nice application, actually
21.27.59 #       <preglow> having wps contained in one file
21.28.20 #       <amiconn> I would like to be able to unzip a rockbox build on target
21.28.23 #       <_FireFly_> i have already an function set which work with uncompressed zip-files
21.28.31 #       <preglow> well
21.28.38 #       <preglow> there is an unzip library hanging around
21.28.39 #       <amiconn> Nothing that needs to be especially fast
21.28.42 #       <preglow> which uses zlib
21.28.47 #       <preglow> should be very portable
21.29.02 #       <amiconn> It should just fit in the archos plugin ram
21.29.05 #       <_FireFly_> preglow: afaik malloc might be needed
21.29.10 #       <preglow> _FireFly_: good point
21.29.29 #       <_FireFly_> because you need an bigger buffer for the uncompressed data 
21.29.34 #       <_FireFly_> as the compressed one
21.29.46 #       <amiconn> I think it should work as a viewer for .zip files, asking for the destination dir to unzip it to
21.29.56 #       <_FireFly_> and my short overlook on zlib it uses malloc
21.30.22 #       <_FireFly_> so only the file-list could be in ram
21.31.01 #       <_FireFly_> and then a spezified amount of compressed data is read from file ,uncompressed and written to the destionation file
21.31.10 #       <preglow> amiconn: so, use of mp3 buffer is banished?
21.31.27 #       <_FireFly_> my fn's it reads into an array all files in the zip-file whith the seek-points to the start of the data
21.31.28 #       <amiconn> preglow: No, it could be used for data
21.31.34 #       <linuxstb> What's "human68k" ?  (it's a target for unzip)
21.31.34 #       <preglow> then you'll be alright
21.31.48 #       <mirak> _FireFly_: what do you do to convert the malloc ?
21.31.54 #       <_FireFly_> only an uncompressen algo is missing
21.32.07 #       <_FireFly_> mirak: i*m doing nothing 
21.32.29 #       <preglow> linuxstb: i think it's the same as x68000, and old kind of computer from asian country
21.32.29 #       <mirak> _FireFly_: ok so if an app uses malloc, how can I adapt it ?
21.32.42 #       <preglow> 68k based
21.32.50 #       <mirak> atari and amiga
21.33.12 #       <preglow> yes, but this was something different
21.33.21 #       <mirak> my god there is was only 1 mega of ram
21.33.25 #       <mirak> -is
21.33.26 #       <preglow> i can't quite remember, it's been yonks since i've even heard the name mentioned
21.33.31 Quit    webguest25 ("CGI:IRC")
21.33.48 Join    Mmmm [0] (n=mscarrat@cpc3-hem13-3-1-cust169.lutn.cable.ntl.com)
21.34.41 #       <linuxstb> unzip has m68k assembler optimisations courtesy of that machine.
21.34.59 #       <preglow> linuxstb: too bad we can't use them
21.35.06 #       <linuxstb> No use at all?
21.35.08 #       <preglow> coldfire is a subset of m68k
21.35.12 #       <preglow> depends on how it's written
21.35.58 Quit    xmixahlx ("blah blah blah")
21.36.52 #       <_FireFly_> if someone have interrest about my read-zip-fns (with crc-check) then the sources can be found here: http://home.arcor.de/s.wezel/read-zip.zip
21.37.21 #       <linuxstb> The unzip source code has even more #ifdefs than Rockbox
21.37.22 #       <_FireFly_> it was written to work in rockbox -> only functions used, which are present in rockbox
21.37.30 #       <_FireFly_> linuxstb: yeag
21.37.34 #       <_FireFly_> -g -h
21.37.57 #       <_FireFly_> but i havn't yet written an plugin or such
21.38.32 Part    Mmmm
21.39.20 Join    Mmmm [0] (n=mscarrat@cpc3-hem13-3-1-cust169.lutn.cable.ntl.com)
21.40.17 #       <linuxstb> mirak: You have two options for porting an app that uses malloc - either replace all the mallocs by static buffers, or implement your own malloc that allocates from a large static buffer.  Either way, remember that you don't have unlimited RAM available - unlike a PC.
21.40.59 #       <_FireFly_> RAM on PC isn't unlimited either but much more then on the targets
21.41.23 #       <ze> people oughtta use ram on a PC like they're forced to on small devices :p
21.41.53 #       <preglow> indeed
21.41.57 #       <preglow> god, i'm tired of bloat
21.42.01 Part    mojo
21.42.20 #       <_FireFly_> i think you should only use as much as ram as really needed
21.43.08 #       <preglow> now, how to set last_btn properly for an interrupt driven button driver?
21.43.17 #       <amiconn> 'small' devices are dependent on the point of view. The ZX81 had 1KB of RAM - including the framebuffer (!)
21.43.33 #       <_FireFly_> wow
21.43.33 #       <linuxstb> And I remember a chess game being available for it...
21.44.17 #       <preglow> you probably couldn't castle in it, due to memory constraints
21.44.45 #       <linuxstb> hehe
21.46.46 #       <amiconn> Chess was available for the ZX Spectrum, which had either 16KB or 48KB of RAM
21.46.56 #       <amiconn> The even was VoiceChess...
21.46.59 #       <amiconn> *There
21.48.08 #       <linuxstb> RockChess - where is it?
21.48.16 #       <Mmmm> Has anyone noticed an increased ticking noise with the remote possibly since the flicker improvements?
21.48.56 #       <preglow> linuxstb: ipl has chess...
21.49.20 #       <preglow> it's called (surprise) tuxchess
21.49.28 #       <linuxstb> Not iChess?
21.49.49 #       <preglow> hehe
21.50.04 #       <preglow> how do they choose?
21.50.15 #       <preglow> must be half of the development process alone
21.50.27 #       <amiconn> ?
21.50.52 Quit    JazzBone ("Leaving")
21.51.26 #       <linuxstb> Mmm.  Seems tuxchess is not GPL - but the author's own "do whatever, as long as you don't make money from it" kind of license.
21.51.57 #       <preglow> linuxstb: btw, slowcoder says the new button driver isn't perfect either
21.52.29 #       <preglow> how the hell do they survive all these numerical addresses?
21.53.38 Join    ender1 [0] (i=ychat@84.52.165.220)
21.54.40 #       <linuxstb> Any ideas about how games like Sudoku and Bejewelled could work with the ipod's scrollwheel?
21.54.42 #       <mirak> linuxstb: ok. I have read that http://en.wikipedia.org/wiki/Data_compression/JPEG . I am not sure about quantization
21.54.55 #       <mirak> I don't understand the equation
21.55.15 #       <preglow> linuxstb: plain horizontal scroll with wraparound?
21.55.21 #       <preglow> god known
21.55.27 #       <preglow> i think i'd like to use button action for bejeweled
21.57.59 #       <preglow> hmm
21.58.05 #       * preglow gets bitten by the strange musepack buzzing
21.58.12 #       <linuxstb> Yep, I was thinking of just horizontal scroll with wraparound.  It's going to take a lot of work to get all the plugins working.
21.58.25 #       <preglow> well, perhaps
21.58.31 #       <preglow> with the scroll wheel, yes
21.58.40 #       <preglow> but we'll have ordinary up/down/left/right as well
22.00.55 Join    [1]ender [0] (i=ychat@84.52.165.220)
22.02.06 Join    qwisp11 [0] (n=arnott_c@cpc1-oxfd4-4-0-cust172.oxfd.cable.ntl.com)
22.02.48 #       <preglow> linuxstb: so, are we to call it the MENU or UP button?
22.03.17 #       <qwisp11> hi
22.03.23 #       <linuxstb> I'm happy with what they are called now - MENU and PLAY
22.03.27 #       * preglow has a sneaking feeling we'll be struggling with the amount of buttons...
22.03.45 #       <linuxstb> It's no worse than the ondio I think.
22.04.08 #       <preglow> linuxstb: so you're thinking that the only way of generating UP and DOWN would be with the click wheel?
22.04.36 Join    webguest02 [0] (n=3efc4010@labb.contactor.se)
22.04.42 #       <linuxstb> I'm thinking we don't have UP and DOWN - we have SCROLL_FWD and SCROLL_BACK
22.04.56 #       <linuxstb> Which is left/right or up/down depending on the context
22.05.17 #       <Cassandra> Makes life interesting, doesn't it?
22.05.23 Quit    ender` (Read error: 110 (Connection timed out))
22.06.01 Join    muesli_- [0] (i=muesli_t@Bc0ae.b.pppool.de)
22.06.07 #       <qwisp11> Could anyone tell me the extension rockboy reads?
22.06.16 #       <linuxstb> .gb or .gbc
22.06.21 #       <qwisp11> ok thanks
22.06.24 Quit    webguest02 (Client Quit)
22.06.24 #       <muesli_-> hi
22.06.34 #       <muesli_-> what does rockbox.iriver btw?
22.06.43 #       <_FireFly_> ??
22.06.49 Join    webguest86 [0] (n=45dda986@labb.contactor.se)
22.06.57 #       <_FireFly_> it's the firmware file for the iriver ;)
22.06.59 #       <_FireFly_> of rockbox
22.07.28 #       <muesli_-> i mean..does the bootloader access on it to start rockbox?
22.08.03 #       <linuxstb> Yes, the bootloader reads that file into memory and then runs it.
22.08.20 #       <muesli_-> cheers linuxstb
22.11.04 Quit    webguest86 (Client Quit)
22.11.12 #       <mirak> in the codecs, is there a distinction from rockbox of the container and the codec itself or is it all handled by the codec ?
22.11.32 #       <mirak> the codec programm in rockbox I mean
22.11.37 #       <linuxstb> It's all handled by the codec.
22.11.38 #       <mirak> I can't be less clear
22.11.40 #       <mirak> ok
22.11.44 #       <linuxstb> I knew what you meant :)
22.12.07 #       <preglow> my, it'll be fun to see if this works
22.12.11 #       <preglow> the odds are slim, slim, slim
22.12.12 #       <mirak> so in the case there is two channels in a container
22.12.26 #       <mirak> preglow: xvid ?
22.12.33 #       <preglow> no, ipod button driver
22.12.37 #       <preglow> i don't care about video on portables
22.12.38 #       <mirak> oh 
22.12.46 #       <mirak> don't be negative
22.12.52 #       <mirak> :)
22.12.55 #       <preglow> towards portable video i am negative
22.12.55 #       <preglow> haha
22.12.57 #       <preglow> it's a waste of time
22.13.10 #       <preglow> imho, of course
22.13.22 #       <mirak> I used it on various ocasion
22.13.30 #       <preglow> but the scary part is i'll probably end up helping if you get some code going
22.13.31 #       <mirak> I used it in the train
22.13.50 #       <mirak> I am not there yet
22.14.05 #       <linuxstb> I'm sure lots of people will help - it's the first step that no-one's taken yet.
22.14.24 #       <mirak> for me that's less useless than playing PSP in the metro
22.14.29 #       <mirak> I have seen guys doing that
22.14.38 #       <mirak> I would puke my breakfast for sure
22.14.38 #       <Mmmm> So then...about this ticking... could the flickering improvements have worsened the ticking noise? Does that sound likely?
22.14.39 #       <preglow> i'm more keen on reading on the train
22.14.43 #       <preglow> and listening to music, of course
22.14.58 #       <mirak> sleeping also is nice
22.14.59 #       <preglow> but yes, i would of course help optimising it
22.15.12 #       <preglow> it's always fun to see what one can get out of limited hardware
22.15.47 #       <mirak> I am sure somebody wil have done it before I even start to code 
22.16.30 #       <mirak> but well anyway I am understanding mpeg compression, I wanted to study that since a long time
22.17.04 #       * preglow tries out his cowboy style button driver
22.17.08 #       <linuxstb> I wonder if Apple will launch a video Nano before we get Rockbox working.
22.17.20 Quit    ender1 (Read error: 110 (Connection timed out))
22.17.41 #       <preglow> AHAHAHHA
22.17.43 #       <preglow> IT BLOODY WORKS
22.17.53 #       <linuxstb> hehe
22.18.02 #       <linuxstb> Has it crashed yet?
22.18.05 #       <preglow> yes
22.18.06 #       <preglow> profusely
22.18.09 #       <linuxstb> lol
22.18.12 #       <mirak> :)
22.18.18 #       <preglow> but this was way, way more than i expected
22.18.38 #       * petur crosses his fingers as he tries his backlight pwm code
22.18.45 #       <linuxstb> So did the file browser actually browse?
22.18.45 #       <preglow> rockbox keeps assuring me there's nothing to resume
22.18.58 #       <mirak> preglow: you try to run rockbox on ipod ?
22.19.01 #       <preglow> i have no up and down
22.19.03 #       <preglow> i'll try it now
22.19.10 #       <petur> LinusN is right - it flickers :( but it works!
22.19.35 #       <mirak> have though of giving max priority to the music thread ?
22.19.45 #       <mirak> I have ogg pausing sometime when scrolling
22.19.48 #       <preglow> linuxstb: well, i need to redefine some code to make it work first, there is no UP and DOWN for ipod
22.19.53 #       <mirak> or pushing a button too long
22.19.58 #       <preglow> or have you fixed that in the file browser already?
22.20.18 #       <preglow> i have not attempted to make 
22.20.23 #       <preglow> cliock wheel work
22.20.32 Quit    qwisp11 ()
22.20.50 #       <linuxstb> up/down are mapped to the scroll wheel in the file browser - see apps/tree.h
22.21.07 #       <preglow> i haven't got scrool wheel working
22.21.13 #       <preglow> hmm
22.21.36 #       <preglow> it's a bit flakey as of yet
22.22.18 #       <preglow> haha
22.22.19 #       <preglow> menu works
22.22.46 #       <petur> is it OK to add a setting for LCD backlight for the H300 target?
22.22.53 #       <Cassandra> Does sprintf(string, "a%s", string) work OK?
22.23.08 #       <linuxstb> Yes - but use snprintf
22.23.10 #       <preglow> bookmarks empty
22.23.22 Quit    [1]ender (Read error: 104 (Connection reset by peer))
22.23.51 Quit    Mmmm ()
22.24.01 #       <preglow> context menu works
22.24.18 Join    ender` [0] (i=ychat@84.52.165.220)
22.25.51 #       <linuxstb> petur: Is that a setting to adjust the brightness? 
22.26.31 #       <petur> yes
22.27.08 #       <linuxstb> Does the contrast setting do anything?
22.27.15 #       <petur> not that I know
22.27.22 #       <petur> 9TO DO) :)
22.27.33 #       <petur> 9 = (
22.28.02 #       <petur> iRiver FW can set the contrast
22.28.16 #       <petur> maybe they play with the LCD signal timings
22.30.06 #       <petur> linuxstb: contrast for h300 is dummy
22.30.09 Quit    akaidiot ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )")
22.30.40 Quit    ze (Read error: 110 (Connection timed out))
22.31.16 #       <Cassandra> preglow, doesn't work in wxWidgets.  Bleh to them.
22.31.47 #       <_FireFly_> Cassandra: is string an wxString ??
22.31.55 #       <Cassandra> Yep.
22.32.15 #       <_FireFly_> why not use the .Format instance-methode of the class
22.32.19 #       <_FireFly_> or similar
22.32.34 #       <Cassandra> And I'm using wxString->Printf, of course (which is equivalent to a vsnprintf, whatever that might be.)
22.32.39 #       <petur> would we need backlight fade in/out on the H300 as well? 
22.32.51 #       <petur> (while I'm at the settings stuff)
22.33.22 #       <Lear> cassandra: sounds like you want wxString::Format...
22.33.37 #       <_FireFly_> Cassandra: http://www.wxwidgets.org/manuals/2.4.2/wx368.htm#topic923
22.33.50 #       <muesli_-> petur sure! its fantastic on h100
22.34.11 #       <Cassandra> I just copied to a temp buffer.  It's all good.
22.34.25 #       <petur> but the PWM only has 16 levels :( unless I also do the Slasheri trick
22.34.39 #       <linuxstb> I think Linus said that backlight fading didn't work very well on the h300 when he played with it.
22.34.43 #       <_FireFly_> Cassandra: you should also do following string = "a"+string
22.35.00 #       <petur> so hardware PWM for continuous setting and software PWM for fading
22.35.58 #       <petur> I think I know what Linus saw: with lower PWM values, you get a bit of flickering if the drive is being accessed. The original FW has this as well
22.36.15 #       <petur> if the drive spins down - steady light ;)
22.36.43 #       <linuxstb> A nice way to indicate disk activity...
22.36.52 #       <_FireFly_> yeah
22.36.57 #       <petur> I would also make this setting available to plugins - flashlight anyone?
22.37.34 #       <petur> btw, I already used my H340 as a flashlight once!
22.37.41 #       <linuxstb> That's the main use for my ipod at the moment - I find my way to bed with it instead of turning the light on.
22.38.03 #       <preglow> ajajahaha
22.38.06 #       <Cassandra> Some bugger has been stealing my brackets.
22.38.07 #       <preglow> this is just too funny
22.38.28 #       <preglow> i've got a feeling we're not clocked too high as of yet
22.38.39 #       <linuxstb> No, I don't think so.
22.38.53 #       <preglow> i've got click wheel working
22.38.57 #       <preglow> but damn, it handles like a dog
22.39.06 Quit    paugh ("Leaving")
22.39.33 #       <preglow> and a small, small, teensy stroke just keeps it going for seconds
22.41.21 #       <preglow> it's a wee bit flakey as of yet too
22.41.23 #       <preglow> wanna try it out?
22.42.20 #       <preglow> if so: www.pvv.org/~thomj/rockbox/rockbox.ipod
22.42.52 Quit    mikearthur (Read error: 104 (Connection reset by peer))
22.43.03 #       <preglow> that's for 4g
22.43.48 Join    mikearthur [0] (n=mike@82-41-227-152.cable.ubr11.edin.blueyonder.co.uk)
22.44.56 Join    Jungti1234 [0] (n=jungti12@58.77.81.144)
22.45.05 #       <Jungti1234> hi
22.45.44 Join    actionshrimp [0] (n=NNSCRIPT@host86-136-20-96.range86-136.btcentralplus.com)
22.48.44 Join    San [0] (n=sanitari@A-79-176.cust.iol.ie)
22.49.08 #       <linuxstb> preglow: It works, but the scrollwheel doesn't seem quite right....
22.49.44 #       <preglow> linuxstb: no, it's completely off the bat
22.49.50 #       <preglow> linuxstb: setting time works just nice
22.50.00 #       <preglow> so kudos on that driver
22.50.16 #       <preglow> scroll wheel works here, but it's hypersensitive
22.50.18 #       <preglow> and lagged
22.50.50 #       <linuxstb> At last, I've managed to change the font...
22.51.03 #       <preglow> to what? :P
22.51.05 Join    guillaumh [0] (n=guillaum@4va54-1-81-56-99-20.fbx.proxad.net)
22.51.13 #       <preglow> the default is fine like wine here
22.51.28 #       <linuxstb> To chicago12
22.51.29 Part    guillaumh ("bye")
22.52.00 #       <preglow> my, this things is lagged
22.52.17 #       <linuxstb> Is it right that the backlight only comes on when you press action?
22.52.26 #       <preglow> it should come on for all buttons
22.52.28 #       <preglow> not click wheel
22.52.31 #       <preglow> i just hacked that in right now
22.52.50 #       <preglow> i can't browse fonts
22.52.52 #       <preglow> just doesn't work
22.53.26 #       <preglow> but ok
22.53.32 #       <preglow> this things seems really, really slow at the moment
22.53.39 #       <preglow> perhaps i should try clocking it up a notch
22.54.08 #       <linuxstb> It's gone crazy now - moving up and down randomly...
22.54.20 #       <linuxstb> Ah, finally it's stopped...
22.54.30 #       <preglow> yeah, it can queue a bunch of event
22.54.31 #       <preglow> s
22.54.35 #       <preglow> and they take aeons to complete
22.55.13 #       <petur> must new settings be added at the back? Or keep them where it's logical
22.55.34 Join    Mmmm [0] (n=mscarrat@cpc3-hem13-3-1-cust169.lutn.cable.ntl.com)
22.56.41 #       <preglow> hahaha
22.56.49 #       <preglow> clocking the cpu up gives results that are completely nuts
22.56.59 #       <preglow> it behaves just like before, just faster
22.58.17 #       <petur> echoing... must new settings be added at the back? Or keep them where it's logical
22.58.38 #       <preglow> linuxstb: it might seem your fat driver is somewhat off here
22.58.48 #       <preglow> it uses lagea mounts of time to find out bookmarks don't exist
23.00.09 #       <preglow> lARGE
23.00.12 Part    Mmmm
23.01.46 Join    akaidiot [0] (n=nope@c-ad45e255.363-1-64736c11.cust.bredbandsbolaget.se)
23.03.38 Join    jlo [0] (n=jl@atm91-1-82-227-1-35.fbx.proxad.net)
23.03.46 #       <jlo> hi
23.04.05 #       <preglow> hi
23.04.09 #       <preglow> you got some tests for me now?
23.04.11 #       <preglow> i've gotta go soon
23.06.47 Quit    jlo (Read error: 104 (Connection reset by peer))
23.08.18 Join    jlo [0] (n=jl@atm91-1-82-227-1-35.fbx.proxad.net)
23.08.51 Quit    amar ("CGI:IRC")
23.09.04 #       <jlo> preglow : I'm uploading now, in some minutes it's ok
23.12.42 #       <Lear> petur: preferably add at the back, that way you don't need to bump the config version.
23.12.54 #       <linuxstb> preglow: I hope it isn't a problem with the fat driver...
23.13.04 #       <petur> OK
23.13.08 #       <preglow> well, i'm way out of my league no matter what it is
23.13.12 #       <linuxstb> Anyway, it's nice to see that most of Rockbox is working nicely.
23.13.17 #       <preglow> indeed
23.13.23 #       <preglow> soon only playback remains...
23.13.32 Join    muesli- [0] (i=muesli_t@Bc1e2.b.pppool.de)
23.13.54 ***     Saving seen data "./dancer.seen"
23.13.55 #       <linuxstb> Yep, once we get a reliable button driver, we can look at playback.
23.14.03 #       <preglow> i don't want to :////
23.14.05 #       <petur> if I enable backlight fading for H300 as well, I do have a problem (config files of H300 no longer compatible)
23.14.16 #       <petur> best to kick out fading at the moment?
23.14.46 #       <jlo> preglow : so it's 4 times "starwberry fields" (original, winamp, rb, reaktor anonymously numbered). it's not the best song to do it (quality is not so good) but it's just a trial
23.15.10 #       <preglow> don't i need a txt file for the abchr prog?
23.15.33 #       <preglow> no idea have i make it 
23.16.34 #       <preglow> riight
23.16.59 #       <jlo> preglow : no, do it yourself, just choose in setup the 4 files, the first will be reference (easy to recognize the original !)
23.18.08 #       <jlo> preglow : and after you can compare two by two to gives quality notes
23.18.19 Quit    Lear ("Chatzilla 0.9.68.5.1 [Firefox 1.5/undefined]")
23.18.22 Quit    San (Read error: 110 (Connection timed out))
23.19.39 #       <preglow> i didn't get this
23.19.42 #       <preglow> i only get three slider groups
23.20.28 #       <jlo> preglow : after your trials, you save the results and then it will create the text file
23.21.18 #       <jlo> you have 3 sliders : 1 compared to 2, 1 to 3, 1 to 4 
23.22.02 #       <jlo> 1 is the one called orig wav
23.22.44 #       <preglow> btw, is this really the best example track?
23.22.46 #       <preglow> sounds pretty mono to me
23.23.26 #       <Jungti1234> http://news.bbc.co.uk/2/hi/in_pictures/4520286.stm
23.23.50 #       <Jungti1234> http://news.bbc.co.uk/2/hi/asia-pacific/4519818.stm
23.24.35 #       <jlo> preglow : the beginning is very unbalanced to left so it's very happy with crossfeed (60's songs !)
23.25.30 #       <preglow> jlo: there's something wrong withg my rig here, i get mono from everything...
23.25.33 #       <Moos> Jungti1234: we fucks him ;)
23.25.37 #       <preglow> agaghaga
23.25.44 #       <preglow> preglow's special mixer setup
23.26.29 Quit    zeero ("Leaving")
23.26.42 #       <jlo> preglow : it should be very un-mono !
23.27.11 #       <Moos> Jungti1234: since 11 september lot of arabic and muslim racism
23.27.28 #       <preglow> jlo: yes, i fucked up in the mixer matrix here, i've got it correct now
23.27.38 #       <preglow> 48 channels get confusing at times
23.27.56 Quit    muesli_- (Read error: 110 (Connection timed out))
23.29.16 #       <Jungti1234> Moos: Isn't the good event.
23.31.03 #       <jlo> so preglow, can you hear something now 
23.31.15 #       <preglow> yes, it's fixed now, but i gotta catch a bus now
23.31.24 #       <preglow> so i've got to do the test tomorrow
23.31.32 #       <preglow> later, all
23.31.53 #       <Moos> we are trust to be arabic and/or muslims, and we fucked all those stupid people, the violence didn't solve any problem
23.31.57 #       <Moos> night preglow
23.32.21 #       <jlo> ok, take your time, and if you have some ideas about other songs...
23.32.33 #       <Jungti1234> Does Australian hate Korean?
23.32.36 #       <jlo> bye
23.32.40 #       <preglow> i'd love lucy in the sky with diamonds
23.32.49 #       <preglow> jlo: just post links here or sokmething, i'll read the log tomorrow
23.32.51 #       * preglow runs awayt
23.32.59 #       <jlo> ok , 
23.33.24 #       <Moos> Jungti1234: fortunatly not all australian people are racist ;)
23.33.47 #       <Jungti1234> hmm..
23.34.06 #       <jlo> fine, I'do "lucy" tomorrow, goodbye
23.34.07 #       <Jungti1234> Don't look like so to me.
23.34.12 Part    jlo
23.34.21 #       <Moos> Jungti1234: ?
23.34.32 #       <Jungti1234> They look like 'A mad dog'.
23.35.25 #       <Moos> this kind of people is international, you can found they around the worls, fortunatly just a minority of people
23.35.31 #       <Moos> *world
23.36.00 #       <Jungti1234> They spoke 'Disappear in this land if is not Australian'.
23.36.26 Join    ze [0] (i=ze@ca-dstreet-cuda1-c6a-130.snbrca.adelphia.net)
23.36.50 #       <Moos> yes for exemple we had those kind of vocabulary in France too, around the world, but they are minoritary
23.37.34 Quit    muesli- (Read error: 110 (Connection timed out))
23.37.44 #       <Jungti1234> I can't understand it.
23.37.50 #       <Moos> the stupidity don't have color or nationality
23.38.14 #       <Moos> sounds like you are'nt stupid so ;)
23.38.28 #       <Jungti1234> All humans are equal.
23.38.36 #       <Moos> yes they are
23.38.48 #       <Bagder> but some are more equal!
23.38.58 #       * Bagder animal farms
23.39.03 #       <Jungti1234> hahaha..
23.39.04 #       <Moos> :)
23.39.19 #       <Jungti1234> I go to have breakfast.
23.39.47 #       <Moos> have a good breakfast, and don't hold your heart about this
23.39.58 Join    webguest15 [0] (n=52e30123@labb.contactor.se)
23.40.01 #       <Moos> those behaviours are antiguos
23.40.23 #       <Moos> and they will be again for long time unfortunatly
23.40.51 Quit    webguest15 (Client Quit)
23.41.29 #       <_FireFly_> someone on this channel as mentioned that the image-flicker fix had the ticking getting louder
23.41.37 #       <_FireFly_> he was right
23.42.01 #       <Moos> oops :)
23.42.02 #       <_FireFly_> i have a little patch which will reduce the ticking again
23.42.11 #       <Moos> it was your fix, no?
23.42.14 #       <Moos> :)
23.42.34 #       <_FireFly_> and with the reduce-ticking fix the ticking is gone (at least on my device)
23.42.38 #       <_FireFly_> Moos: yepp :)
23.43.40 #       <Moos> here I noticed since I use rockbox the remote tick is gone without the Slasheri's option
23.43.42 #       <_FireFly_> my new patch uses only one place where the framebuffer gets putted to the lcd
23.44.40 #       <_FireFly_> Moos: sometimes i didn't hear it also but if a play a bit with the remote-buttons the ticking went back
23.44.48 #       * Moos didn't use his remote, he is use it since TiMiD works and no tick :)
23.45.02 #       <_FireFly_> ??
23.45.18 #       <_FireFly_> do you use the remote or not ??
23.45.37 #       <Moos> I use Rockbox since few month now, but I use remote just in those cold times
23.46.04 #       <_FireFly_> maybe you are a lucky guy with an device without the problem
23.46.07 #       <Moos> but 1 year ago I remenber I heared the tick with remote
23.46.17 #       <Moos> yes maybe :)
23.47.36 #       <Moos> At start I thought it was one intentionel behaviour from iriver for mimick the beep mode, but...
23.47.38 #       <_FireFly_> LinuxN: btw, have you any success about this ticking through an check of an "infected" device 
23.48.01 #       <Moos> Linus isn't here
23.48.05 #       <_FireFly_> LinusN: which you got send by someone
23.48.21 #       <_FireFly_> Moos: yes i know but i gess he will read the logs ;)
23.48.41 #       <Moos> yes true :)
23.49.43 Quit    t0mas (Read error: 104 (Connection reset by peer))
23.51.25 #       <Moos> Bagder: I just checked the Webstatistics, hehe more pages read, Rockbox will become one big "communauty" :)
23.51.39 #       <Moos> with a lot of devices
23.51.58 #       <Bagder> the more the merrier!
23.52.14 #       <Moos> :)
23.52.36 #       * Bagder discovered that his 'virus' mailbox is now almost 1GB
23.52.37 #       <Jungti1234> ah...
23.52.47 #       <Jungti1234> I'm full. :)
23.53.05 #       <Moos> Bagder: ugh :(
23.53.37 #       <Moos> Jungti1234: you are fast :)
23.53.42 #       <Jungti1234> hehe..
23.53.51 #       <Bagder> spams and virus like me a lot
23.53.52 #       <Jungti1234> Virus mail is very many.
23.54.33 #       <Jungti1234> Gmail isolates all it.
23.55.17 #       * Moos is looking in one debate on TV about the colonization
23.55.18 #       <Jungti1234> G-Mail is safe. :)
23.58.03 #       <Jungti1234> hahaha
23.58.04 #       <Jungti1234> http://imgnews.naver.com/image/020/2005/12/13/200512130111.jpg
23.58.12 #       <Jungti1234> Is he master?
23.58.54 #       <Moos> look like one animal