--- Log for 12.11.108  Server: zelazny.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 10 days and 8 hours ago

00.00.11 #       <preglow> doesn't help to have a nice, shiny standards document if you don't read it
00.00.18 #       <preglow> or just blatantly disregard it
00.01.57 #       <gevaerts> Isn't that standard behaviour in computers?
00.02.00 Join    HBK- [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net)
00.03.03 Join    saratoga [0] (i=9803c6dd@gateway/web/ajax/mibbit.com/x-f54436b2c2d9fe09)
00.03.27 #       <saratoga> preglow:  yeah, he didn't know anything about programming and pestered me to port it for him to some random device i've never heard of
00.03.34 #       <preglow> hahah
00.03.36 #       <preglow> excellence
00.03.45 #       <preglow> i assume you're hard at work, then? :P
00.03.50 Quit    HBK (Read error: 104 (Connection reset by peer))
00.04.45 #       <saratoga> eventually he seemed to have got that hit and took off, after i told him no about 5 times
00.05.13 Quit    Thundercloud (Remote closed the connection)
00.05.39 #       <Zagor> ehhhee. do you want to know why my build is so fast? it doesn't build all plugins... :-)
00.05.45 #       <BigBambi> haha :)
00.05.52 #       <preglow> i just disabled doom myself :V
00.07.48 #       <Llorean> preglow: You left pacbox and rockboy in?
00.08.00 #       <gevaerts> Zagor: I was going to mention that we should do a thotough comparison before committing :)
00.08.00 #       <preglow> just disabled them as well, heh
00.08.32 #       <Zagor> someone might want to actually install a build and see if it works too :)
00.09.19 #       <saratoga> i'm afraid to do stuff like that because I'll almost certainly forget and end up commiting the changed SOURCES file
00.10.15 Quit    bluebrother ("leaving")
00.10.52 Quit    jgarvey ("Leaving")
00.11.25 #       <preglow> i always check the diff so goddamn carefully i pick it up anyway
00.11.34 #       <preglow> i have to, or i'd start commiting all kinds of shit
00.12.11 Quit    saratoga3 ("CGI:IRC (EOF)")
00.14.53 Quit    kronflux ("Leaving")
00.15.20 Join    SUSaiyan [0] (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl)
00.16.27 Quit    tyfoo2 (Read error: 60 (Operation timed out))
00.18.07 Quit    kugel ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]")
00.19.38 Join    tyfoo [0] (n=tyfoo@dyndsl-095-033-085-046.ewe-ip-backbone.de)
00.19.40 Quit    bertrik ("Leaving")
00.23.23 Join    LambdaCalculus37 [0] (n=LambdaCa@c-68-83-177-181.hsd1.nj.comcast.net)
00.26.40 Quit    bodymind_ (Read error: 110 (Connection timed out))
00.27.18 Join    bodymind_ [0] (n=bodymind@bl6-240-80.dsl.telepac.pt)
00.27.34 Join    DerDome [0] (n=DerDome@dslb-082-083-223-207.pools.arcor-ip.net)
00.28.48 Quit    DerDome (Client Quit)
00.29.45 Join    DerDome [0] (n=DerDome@dslb-082-083-223-207.pools.arcor-ip.net)
00.31.29 Join    stripwax__ [0] (n=Miranda@87-194-34-169.bethere.co.uk)
00.35.21 #       <Zagor> we have four different sound.h ...
00.35.57 Join    bodymind [0] (n=bodymind@bl6-241-214.dsl.telepac.pt)
00.37.02 Quit    robin0800 (Connection timed out)
00.37.04 #       <Zagor> three of which are included in the sim builds
00.37.06 Quit    faemir (Read error: 104 (Connection reset by peer))
00.37.32 #       <Zagor> yay, ordered include paths!
00.37.49 Quit    tyfoo (Connection timed out)
00.37.57 Quit    bodymind (Client Quit)
00.38.49 Join    skipper [0] (n=skipper@78-1-137-220.adsl.net.t-com.hr)
00.39.22 Quit    DerDome ("Leaving.")
00.40.23 #       <preglow> oh lord
00.40.25 #       <preglow> twice an idiot
00.40.34 #       <preglow> apparently i'm not capable of even writing out correct bitmasks now
00.41.38 Join    faemir [0] (n=quassel@88-106-238-33.dynamic.dsl.as9105.com)
00.42.57 Nick    JdGordon|zzz is now known as JdGordon (n=jonno@rockbox/developer/JdGordon)
00.44.43 Quit    faemir (Remote closed the connection)
00.44.49 Quit    l403 (Read error: 113 (No route to host))
00.45.40 Quit    massiveH ("Leaving")
00.47.52 Join    l403 [0] (n=l@85.132.159.239)
00.48.17 Quit    ender` (" If the art world was ran by the RIAA, you would have to lease special glasses if you wanted to see a painting. -- Rodney Ca")
00.52.11 Quit    culture (Read error: 110 (Connection timed out))
00.54.51 Quit    bodymind_ (Read error: 110 (Connection timed out))
00.54.56 Join    DerDome [0] (n=DerDome@dslb-082-083-223-207.pools.arcor-ip.net)
00.55.55 Quit    DerDome (Client Quit)
00.56.11 Join    DerDome [0] (n=DerDome@dslb-082-083-223-207.pools.arcor-ip.net)
00.56.16 Quit    DerDome (Remote closed the connection)
00.57.05 Join    DerDome [0] (n=DerDome@dslb-082-083-223-207.pools.arcor-ip.net)
00.57.26 Quit    DerDome (Client Quit)
00.57.26 Quit    Zagor ("Client exiting")
00.57.48 Join    DerDome [0] (n=DerDome@dslb-082-083-223-207.pools.arcor-ip.net)
00.57.52 Quit    DerDome (Remote closed the connection)
01.00.17 Quit    stripwax__ ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
01.00.38 Quit    Nico_P (Remote closed the connection)
01.00.46 Quit    l403 ("Leaving")
01.04.01 Quit    eflavoie (Remote closed the connection)
01.05.31 Join    DerDome [0] (n=DerDome@dslb-082-083-223-207.pools.arcor-ip.net)
01.05.37 Quit    DerDome (Remote closed the connection)
01.08.27 Join    Strife89 [0] (n=michael@204.116.245.152)
01.10.02 Join    Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com)
01.11.19 Join    mofux [0] (n=quassel@dslb-088-075-002-201.pools.arcor-ip.net)
01.15.02 Join    jhulst [0] (n=jhulst@unaffiliated/jhulst)
01.16.53 Quit    lasser (Read error: 110 (Connection timed out))
01.18.24 Quit    Thundercloud (Remote closed the connection)
01.23.31 Quit    MethoS-- (Read error: 104 (Connection reset by peer))
01.25.32 Quit    skipper (Remote closed the connection)
01.30.07 Quit    moos ("Rockbox rules the DAP world")
01.38.34 Quit    Strife89 ("Bye all. :)")
01.43.49 ***     Saving seen data "./dancer.seen"
01.48.03 Quit    mofux (Remote closed the connection)
01.49.24 Part    pixelma
01.49.41 Join    pixelma2 [0] (n=marianne@rockbox/staff/pixelma)
02.03.22 Quit    gevaerts (Nick collision from services.)
02.03.31 Join    gevaerts [0] (n=fg@rockbox/developer/gevaerts)
02.07.59 Join    DerDome [0] (n=DerDome@dslb-082-083-223-207.pools.arcor-ip.net)
02.12.10 Quit    saratoga ("http://www.mibbit.com ajax IRC Client")
02.20.33 Quit    |AhIoRoS| ("Abandonando, see you http://ahioros.vidao2.com")
02.28.35 Quit    jhulst (Remote closed the connection)
02.33.16 Join    Notlistening [0] (n=tom@host81-151-159-249.range81-151.btcentralplus.com)
02.37.14 Quit    knnylftn (Remote closed the connection)
02.37.48 Quit    obo (Read error: 110 (Connection timed out))
02.38.26 #       <Notlistening> Hi can any tell me if the rockbox libraries support printf and before you all do duh you never want to use printf there is a valid reason
02.38.30 #       * jhMikeS screams at this PMIC charging contraption
02.52.23 Quit    tessarakt (Read error: 110 (Connection timed out))
02.58.55 #       <Llorean> Notlistening: I'm curious about your valid reason
03.00.24 #       <jhMikeS> There's one in the bootloaders that's hacked together
03.01.56 #       <jhMikeS> bootloader/common.c starting at line 60
03.01.58 #       <Notlistening> ok I have got a arm based development board that i am working on getting rockbox working on and it has a serial output for debugging and that uses a printf to output debug info
03.04.05 #       <jhMikeS> messing with logf could get you somewhere as well (it can do serial)
03.04.18 Nick    fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net)
03.04.51 #       <Notlistening> jhMikeS: Thanks will give that a go and see what we get :)
03.05.37 Join    Darksair [0] (n=user@123.112.115.229)
03.05.56 #       <jhMikeS> firmware/logf.c, probably need serial_tx implemented for your hardware
03.08.04 #       <Notlistening> I will try the printf code first and then look further into different ways if we get nothing cheers
03.09.10 Quit    Notlistening ()
03.10.32 Quit    DerDome ("Leaving.")
03.14.29 Join    super_ [0] (i=1000@c80-217-96-124.bredband.comhem.se)
03.15.28 Quit    super (Read error: 104 (Connection reset by peer))
03.32.52 Join    AndyIL [0] (i=AndyI@212.14.205.32)
03.43.53 ***     Saving seen data "./dancer.seen"
03.45.11 Quit    AndyI (Read error: 110 (Connection timed out))
03.49.09 Join    cg [0] (n=cromos@cable-kmi-fefff900-32.dhcp.inet.fi)
03.53.08 Quit    LambdaCalculus37 ("Ka-chunka")
03.55.03 Join    nuonguy [0] (n=john@c-71-198-1-139.hsd1.ca.comcast.net)
04.02.27 Join    metal_falsetto [0] (n=48e68c64@gateway/web/cgi-irc/labb.contactor.se/x-8b38882abd57fbb9)
04.07.32 #       <metal_falsetto> Hey all -- I'm trying to install Rockbox on my Sansa e260 (using Ubuntu Hardy 64) and am experiencing some crashing when trying to install via the Rockbox Utility.
04.07.34 Join    jhulst [0] (n=jhulst@unaffiliated/jhulst)
04.17.13 Quit    Bensawsome ("The awsome is gone :(")
04.17.16 Quit    metal_falsetto ("CGI:IRC (EOF)")
04.30.45 Join    miepchen^schlaf_ [0] (n=miepchen@p579ECC73.dip.t-dialin.net)
04.35.14 Quit    ap0 (Read error: 104 (Connection reset by peer))
04.37.34 Quit    miepchen^schlaf (Read error: 110 (Connection timed out))
04.40.50 Quit    fdinel (Read error: 110 (Connection timed out))
04.49.32 Join    blkhawk- [0] (n=blkhawk@e179201195.adsl.alicedsl.de)
04.57.49 Join    kkurbjun [0] (n=kkurbjun@c-24-9-80-197.hsd1.co.comcast.net)
04.58.46 #       <kkurbjun> how do I revert the last commit I made?
04.59.52 Join    BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey)
05.06.40 Quit    blkhawk (Read error: 110 (Connection timed out))
05.07.29 Nick    blkhawk- is now known as blkhawk (n=blkhawk@e179201195.adsl.alicedsl.de)
05.14.43 Quit    _lifeless (Remote closed the connection)
05.15.04 Join    _lifeless [0] (n=lifeless@90.151.219.113)
05.19.17 Quit    XavierGr ()
05.22.11 #       <JdGordon> kkurbjun: get a svn diff of the commit, apply the patch (it will say its applied already and do you want to revert the patch) then commit again
05.22.28 #       <JdGordon> which apparently you worked out :D
05.23.02 Quit    Seed (Read error: 60 (Operation timed out))
05.24.41 Join    midkay [0] (n=midkay@rockbox/developer/midkay)
05.24.43 Join    midkay_ [0] (n=midkay@75-172-109-206.tukw.qwest.net)
05.24.44 Join    midkay__ [0] (n=midkay@75-172-109-206.tukw.qwest.net)
05.25.12 #       <kkurbjun> :), yep, thanks for that
05.25.25 #       <kkurbjun> I just added it to the wiki for future reference :D
05.25.34 #       <JdGordon> :) hows things?
05.25.54 #       <JdGordon> cant get you to have a crack at the mr500 can i? :D
05.26.44 #       <kkurbjun> it's going well.  :), not yet, it's on the todo list eventually.  Good news is that I think this flashwriter is pretty much done
05.27.05 #       <kkurbjun> so I can move on to something else eventually (like the mr500)
05.27.08 #       <JdGordon> cool, so work can start on a real bootloader?
05.27.13 #       <kkurbjun> how's it on your end
05.27.22 #       <JdGordon> all good.. finshed uni so have plenty of time
05.27.41 Quit    midkay (Client Quit)
05.27.41 Quit    midkay__ (Client Quit)
05.27.42 Quit    midkay_ (Client Quit)
05.28.06 #       <kkurbjun> the bootloader is pretty much done for the gigabeat, I run my player with the bootloader flashed now.  Nice, it's got to feel good to be done with classes
05.28.22 Join    midkay [0] (n=midkay@rockbox/developer/midkay)
05.28.57 #       <kkurbjun> Although with the economic mess everyone is in school looks appealing :)
05.28.58 #       <JdGordon> yep, better than that though... finshed forever... :D
05.30.06 #       <kkurbjun> yeah, school was good, but it is nice to not have any more homework
05.30.36 #       <JdGordon> haha yeah
05.36.30 Quit    JdGordon ("Konversation terminated!")
05.43.55 ***     Saving seen data "./dancer.seen"
05.45.34 Join    JdGordon [0] (n=jonno@rockbox/developer/JdGordon)
05.48.59 Quit    Horscht ("electromagnetic radiation from satellite debris")
06.40.40 Join    __lifeless [0] (n=lifeless@90.151.213.163)
06.45.49 Quit    _lifeless (Read error: 145 (Connection timed out))
06.57.30 Part    kkurbjun
07.04.35 Join    _lifeless [0] (n=lifeless@90.151.213.163)
07.20.03 Quit    __lifeless (Read error: 110 (Connection timed out))
07.22.41 Quit    reacocard (".")
07.23.05 Join    reacocard [0] (n=reacocar@134.173.63.19)
07.39.58 Nick    fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net)
07.41.16 Join    LinusN [0] (n=linus@rockbox/developer/LinusN)
07.43.56 ***     Saving seen data "./dancer.seen"
07.45.49 Nick    fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net)
07.46.36 Quit    jhulst (Read error: 60 (Operation timed out))
08.06.12 Join    kugel [0] (n=chatzill@unaffiliated/kugel)
08.13.10 Nick    super_ is now known as super (i=1000@c80-217-96-124.bredband.comhem.se)
08.20.13 Join    tessarakt [0] (n=jens@e180071194.adsl.alicedsl.de)
08.20.17 Quit    tessarakt (Read error: 104 (Connection reset by peer))
08.21.42 Join    gromit`` [0] (n=gromit@ALagny-154-1-82-176.w81-48.abo.wanadoo.fr)
08.27.03 Quit    BigBambi (Read error: 104 (Connection reset by peer))
08.28.16 Join    draft [0] (n=draft@a91-155-202-119.elisa-laajakaista.fi)
08.28.19 #       <draft> howdy
08.30.02 Quit    miepchen^schlaf_ ()
08.30.45 Quit    gromit` (Read error: 110 (Connection timed out))
08.33.07 Quit    draft (Client Quit)
08.33.22 Join    Zagor [0] (n=bjorn@rockbox/developer/Zagor)
08.37.40 Quit    GodEater ("http://www.mibbit.com ajax IRC Client")
08.39.24 Join    GodEater [0] (i=c2cbc962@gateway/web/ajax/mibbit.com/x-3cce57dcac821325)
08.47.23 Quit    nuonguy ("This computer has gone to sleep")
08.51.22 Join    ender` [0] (i=krneki@foo.eternallybored.org)
08.53.08 Quit    Llorean (Read error: 113 (No route to host))
08.59.14 Join    Bagderr [0] (n=daniel@gateway/web/cgi-irc/labb.contactor.se/x-4c88274428b8f135)
09.00.00 Join    Rob2222 [0] (n=Miranda@p4FDCC412.dip.t-dialin.net)
09.08.23 Quit    amiconn (Nick collision from services.)
09.08.29 Join    amiconn [50] (n=jens@rockbox/developer/amiconn)
09.10.40 Join    petur [50] (n=petur@rockbox/developer/petur)
09.12.52 Join    culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com)
09.16.05 Quit    _Andrew_ (Read error: 110 (Connection timed out))
09.17.00 Quit    Rob2223 (Read error: 110 (Connection timed out))
09.20.36 Join    CaptainSquid [0] (n=Miranda@proxy13.netz.sbs.de)
09.24.28 Quit    pixelma2 (Nick collision from services.)
09.24.35 Join    pixelma2_ [0] (n=marianne@rockbox/staff/pixelma)
09.24.39 Nick    pixelma2_ is now known as pixelma2 (n=marianne@rockbox/staff/pixelma)
09.27.03 Quit    Chronon (Remote closed the connection)
09.27.32 Quit    Acky (Read error: 104 (Connection reset by peer))
09.27.53 Join    Acksaw [0] (n=omgwtfbb@cpc2-stok5-0-0-cust754.bagu.cable.ntl.com)
09.28.41 Nick    Bagderr is now known as B4gder (n=daniel@gateway/web/cgi-irc/labb.contactor.se/x-4c88274428b8f135)
09.33.15 Quit    kugel (Remote closed the connection)
09.34.30 Quit    culture (Read error: 110 (Connection timed out))
09.35.27 #       <amiconn> Hmpf. Codec dependencies are still borked
09.36.17 #       * amiconn would also like to know what's up with the Player build
09.40.51 Join    einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de)
09.43.58 ***     Saving seen data "./dancer.seen"
09.47.08 Join    ap0 [0] (n=kvirc@mer90-1-88-166-249-88.fbx.proxad.net)
09.52.13 Join    Nibbler [0] (n=Nibbler@mx00.linkprotect.de)
09.53.38 #       <GodEater> wow - now there's a bit of Rockbox history I didn't know
09.54.12 #       * JdGordon wonders what history GodEater found in the past hours of silence :p
09.55.09 Quit    MrDuck (Read error: 113 (No route to host))
09.55.37 #       <GodEater> about the Neo car player that ran rockbox
09.55.44 #       <GodEater> LinusN's post in the forums
09.55.58 #       <JdGordon> ah
09.56.48 #       <B4gder> 'openneo' even has a wiki page in our wiki
09.57.08 #       <B4gder> there's a "beta" for download from sourceforge dated 2003
09.57.48 #       <LinusN> and i refrained from telling the real story of the fork
09.58.44 #       <LinusN> they took the code and stripped all the copyright headers
09.59.03 #       <B4gder> and removed "rockbox" from it everywhere
09.59.03 #       <GodEater> the swine
09.59.24 #       <LinusN> they eventually did the right thing when we told them about the gpl
09.59.38 #       <GodEater> you didn't have to threaten legal action ?
09.59.42 #       <LinusN> no
10.00.12 #       <LinusN> i like to think it was classic gpl ignorance
10.00.34 #       <GodEater> that's a very generous thing to think ;)
10.01.08 #       <LinusN> :-)
10.01.28 #       <Zagor> they also claimed they wrote it themselves
10.01.28 #       <amiconn> linuxstb: around?
10.01.53 #       * amiconn found something suspicious in libdemac's filter.c
10.02.36 #       <LinusN> in this case, it seems SSI hired some guys to write the software, and it loks like they didn't tell SSI that they stole it
10.03.16 #       <LinusN> but that's history
10.05.33 Join    Acky [0] (n=omgwtfbb@cpc2-stok5-0-0-cust754.bagu.cable.ntl.com)
10.10.30 #       <B4gder> and they claimed they "had" to fork it since they had so different requirements
10.11.06 #       <B4gder> as in the hard drive always spinning, lba48, low mem situation
10.11.10 #       <scorche> like requiring their own branded version without mention of rockbox? ;)
10.11.20 #       <B4gder> it was more like that yes
10.11.36 #       <B4gder> but they did a whole lot of weird changes
10.11.45 #       <B4gder> I subscribed to their commit lists while it existed
10.11.51 #       <B4gder> s/lists/list
10.12.04 #       <scorche> they had a public commit list?
10.12.10 #       <B4gder> yes, but a delayed one
10.12.23 #       <B4gder> they had some internal cvs and synced with the external every once in a while
10.14.00 Join    kugel [0] (n=chatzill@unaffiliated/kugel)
10.14.30 #       <B4gder> for example, they ripped out our playlist handling
10.14.42 #       <JdGordon> did they put something better in?
10.14.49 #       <B4gder> better in their view I guess
10.14.59 #       <B4gder> not in mine
10.15.04 #       <Zagor> and, as I recall it, our painstakingly perfected shuffle, instead replacing it with a shoddy random
10.15.15 #       <B4gder> yeah, that was an effect of that
10.15.31 #       <JdGordon> some people actually prefer random over shuffle...
10.15.54 #       <B4gder> I think it was mostly because they didn't understand our way
10.16.12 #       <scorche> why?...just for the ability to play songs twice?...besides that, i dont see any sort of reason why random might be better
10.17.18 #       <JdGordon> because it keeps the playlist in order, so if you decide you'd like to listen to a song which is "close" to the current track, you dont have to go searching the playlist for it
10.17.32 #       <JdGordon> you know where it should be in relattion to the current track
10.18.43 #       <Zagor> JdGordon: we can do that with shuffle too. but you can't do shuffle with random.
10.19.06 #       <Zagor> wonderful sentence...
10.19.58 #       <JdGordon> no we cant... our shuffle mangles the playlist
10.20.06 #       <JdGordon> we have to find the file in the browser to do it
10.20.33 #       <Zagor> just unshuffle, move to wherever, and reshuffle. our playlist is not mangled, just reordered in a controlled fashion
10.20.49 #       <JdGordon> not as easy to do
10.21.04 #       <Zagor> no it's three button presses instead of one
10.21.37 #       <JdGordon> not if you removed shuffle from the quickscreen
10.22.35 Quit    Acksaw (Connection timed out)
10.22.57 #       <GodEater> who'd be silly enough to do that ? ;)
10.23.02 #       * scorche wonders if JdGordon ever tried the random implementation in the archos's OF
10.23.06 #       <Zagor> my point is we can do whatever random-lovers want, but the opposite is not true
10.23.17 #       <Zagor> we have not chosen to do it, but we have the option
10.23.54 #       <JdGordon> scorche: I've only ever touched a archos during our tower building.. never used rockbox or its of on it
10.24.11 #       <B4gder> its a fine brick for towers!
10.24.29 #       <JdGordon> although, if its like the iriver of its pretty bad, randomness wasnt so good iirc
10.24.39 #       <Zagor> B4gder: how does buildzip collect files? will it be terribly confused if, for example, some .rocks are in their subdirs?
10.25.18 #       <Zagor> or rather, how do I adapt it so it doesn't get confused?
10.25.36 #       <JdGordon> please dont leave plugins in subdirs... buildzip might handle it but sometimes its easier to manually copy the rocks and trying to remember which go in a subdir and which dont...
10.25.45 #       <linuxstb> amiconn: I'm around now
10.25.48 Quit    BHSPitMonkey (Remote closed the connection)
10.25.52 #       <B4gder> it scans for them in the subfolders and put them in .rockbox/rocks so I figure it should be rather easy to make work
10.27.22 #       <amiconn> linuxstb: I probably misread something, need to double check
10.28.01 #       <linuxstb> amiconn: OK, I'll be around (more or less) all day, so just ping me...
10.29.21 #       <JdGordon> so, what was the final verdict on the wps view mode patch? OK to commit without the silly setting to allow it?
10.29.53 Quit    voltagex (Remote closed the connection)
10.37.22 #       <JdGordon> does anyone have a good name for the define the ams sansas need to skip the OF on the disk? HAVE_SUPERFLOPPYMODE_OFFSET is a bit longwinded
10.39.14 Join    tvelocity [0] (n=tony@195.167.65.111)
10.39.21 #       <GodEater> HV_SPRFLPYMD_OFFST ?
10.39.31 #       <linuxstb> Why do you need the HAVE_* define at all?  You could do "#ifndef XXX ; #define XXX 0 ; #endif" in config.h, and then check for #if XXX > 0 (if needed at all)
10.39.44 #       * GodEater follows the unix tradition of regarding vowels as something other people need
10.40.10 #       * linuxstb still wants to know why the unmount command is called umount, but is straying off-topic
10.40.14 #       <JdGordon> thats what I had to start with, gevaerts rekons having a function return the value is better, and I changed my mind because a #defined number wont work for multivolume targets
10.41.35 #       <linuxstb> But isn't it only needed for the first disk?  That method doesn't stop a function being used on some targets.
10.42.24 #       <JdGordon> yes
10.42.50 #       <gevaerts> JdGordon: I would drop the superfloppy bit in the name. If a player appears that has a partition table at that offset, this still applies
10.48.02 Join    what [0] (n=79b45a2d@gateway/web/cgi-irc/labb.contactor.se/x-6913cc045007a080)
10.52.41 #       <JdGordon> gevaerts: http://pastebin.ca/1254182 sort of thing?
10.53.55 #       <JdGordon> Is having the function prototype at the top of disk.c be worse than having to add a new header for the one line?
10.54.22 Join    robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com)
10.55.11 #       <gevaerts> JdGordon: something like that, yes. Why not just add the prototype to storage.h?
10.56.11 #       <linuxstb> Wouldn't it be better as a macro, and not use HAVE_STORAGE_OFFSET at all ?  i.e. just have the line "const int offset = STORAGE_OFFSET(IF_MV(drive));", which would evaluate to 0 for most targets.
10.56.16 #       <robin0800> Commit 19097 Power off bug could this effect other arm targets?
10.57.14 #       <linuxstb> robin0800: No - the only file that was changed was one only used by the Gigabeat F/X
10.57.38 #       <JdGordon> linuxstb: but if it is a function wont that cause warnings with function not being eclared?
10.57.55 Join    lasser [0] (n=chatzill@W858b.w.pppool.de)
10.58.09 #       <linuxstb> You declare it in something like storage-target.h - but you don't have to worry about that yet.
10.59.22 #       <robin0800> linuxstb: is the bug present in other targets?
11.00.21 #       <linuxstb> robin0800: The fix was in a target-specific file, so I would guess it was a target-specific bug.  But of course that doesn't mean other targets don't have similar issues - I've no idea.
11.00.39 #       <JdGordon> Is there any difference really between the two?
11.01.49 #       <linuxstb> It removes a #if from disk.c, and allows things to be done at compile-time when the offset is a known constant.
11.03.25 #       <amiconn> linuxstb: Seems I was wrong regarding my suspicion, but I found something else instead:
11.03.41 #       <amiconn> HISTORY_SIZE is 512, independent of the filter order
11.04.12 #       <amiconn> That means excessive memmoving for the longer-order filters, and unnecessary memmoving if the buffer would allow for a longer history
11.04.34 #       <amiconn> There are 5 different filter orders, but only 3 buffers, used as necessary
11.05.19 #       <JdGordon> "#define STORAGE_OFFSET(IF_MV(drive)) IF_MV(drive==1:0?)61440" ?
11.05.28 #       <amiconn> I think the filters should use the *longest* available buffer instead of the shortest, and use the extra space for less history moving
11.06.18 #       <amiconn> The only exception to this rule is if the longest available buffer is not in IRAM, then it shouldn't be used unless required
11.06.22 #       <linuxstb> amiconn: Yes, that sounds sensible.
11.07.44 #       <Zagor> JdGordon: a macro looks sensible, imho
11.07.45 #       * amiconn thinks it would be best to pass the buffer size to init_filter_*(), then it can figure out the history size
11.08.14 Join    Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net)
11.08.51 #       <JdGordon> lame, apparently you cant put IF_MV(drive) insiode the macro definition
11.10.17 #       <kugel> JdGordon: why don't we just do something like : if (0==drive) "use offset"; else "dont use offset"
11.10.35 #       <JdGordon> in the sd driver you mean?
11.10.43 #       <kugel> yea
11.10.53 #       <JdGordon> because thats baaaadd mmkay
11.11.05 #       <JdGordon> the SD driver should not be fiddling with the sector being ascked for
11.11.14 #       <kugel> in the card initialization. That worked for me when I tried to load from the microsd and internal depending on the microsd inserted
11.11.20 #       <kugel> hm ok
11.12.52 #       <JdGordon> lol @ the comment in mv.h about getting rid of the IF_MV macros "once decided on how to proceed with multivolume" which is now how many years old? :D
11.12.56 #       <kugel> though I think it's fine in the target-specific driver
11.13.32 #       <kugel> JdGordon: I think that should be done similar to multiscreen (e.g. FOR_NB_VOLUMES, etc)
11.13.43 #       <amiconn> JdGordon: mv.h is less than a month old afaik
11.13.50 #       <JdGordon> copied from old code
11.13.57 #       <JdGordon> kugel: serves different purposes
11.14.29 Quit    kugel ("ChatZilla 0.9.83 [Firefox 3.0.3/2008101315]")
11.14.30 #       <amiconn> That comment is certainly not copied
11.14.43 #       <JdGordon> oh really.. /me shuts up then :p
11.17.37 #       <_lifeless> hello, how i can get write acces for twiki?
11.19.02 Quit    what ("CGI:IRC (EOF)")
11.20.35 #       <gevaerts> _lifeless: what's your wiki username? And out of curiosity, what sort of changes are you planning?
11.21.09 Quit    larstobi (Read error: 60 (Operation timed out))
11.21.27 Join    larstobi [0] (n=larstobi@195.139.173.50)
11.21.50 #       <_lifeless> it's AntonVeretenenko, i want to upload pcb pictures for gogear hdd1620/30
11.22.05 #       <_lifeless> an then commit some code
11.22.27 #       <JdGordon> linuxstb: http://pastebin.ca/1254199 ?
11.23.06 #       <JdGordon> the macros arn't exactly pretty...
11.23.43 #       <gevaerts> _lifeless: done. Welcome :)
11.23.55 Join    MrDuck [0] (n=kachna@r3g248.net.upc.cz)
11.24.04 #       <GodEater> _lifeless: any code you've written should go in the patch tracker
11.24.16 Quit    n17ikh|Lappy ()
11.25.03 Join    n1s [0] (n=nils@rockbox/developer/n1s)
11.25.16 #       <_lifeless> great, thx
11.25.29 #       <_lifeless> GodEater, ok got it
11.34.22 Nick    Darksair is now known as Darksair{away} (n=user@123.112.115.229)
11.38.22 #       * JdGordon wonders where funman disappeared to
11.41.11 Join    mrkiko [0] (n=IRCExplo@151.80.79.132)
11.44.00 Join    bodymind [0] (n=bodymind@193.136.218.60)
11.44.01 ***     Saving seen data "./dancer.seen"
11.44.30 Join    dany_21a_ [0] (n=dan@84-119-26-57.dynamic.xdsl-line.inode.at)
11.45.51 Nick    fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net)
11.47.10 #       <JdGordon> arg, ok maybe this would be easier just leaving it in the sd driver :(
11.48.43 #       <mrkiko> Hi all guys! W rockbox...
11.48.52 #       <mrkiko> I would like remembering you I hate gprs :D bye!
11.48.53 Part    mrkiko
11.50.45 Join    kugel [0] (n=chatzill@unaffiliated/kugel)
11.50.51 #       <linuxstb> JdGordon: I wouldn't put the macros in config-target.h, but in a target-specific .h file, but I'm not sure what possibilities there are with the new storage code.  "Someone" also needs to clean up the target/arm/ tree to create a PP subdir (or two)...  I would also write the macro using #ifdef HAVE_MULTIVOLUME, rather than the less obvious IF_MV...
11.51.10 #       <linuxstb> But my attempt is here - http://pastebin.ca/1254210  (not a real patch, I just edited your patch to show what I'm thinking)
11.52.14 #       <linuxstb> I think this is just something that can be done many different ways, so just pick one...
11.53.21 Quit    reacocard (".")
11.53.25 #       <kugel> JdGordon: the fuze's offset should be the same as e200 offset (not clip,... offset)
11.54.19 #       <amiconn> hmmm
11.55.04 #       <amiconn> Combining the filter buffers would be even better. Then single filter compression levels could make even better use of the available ram
11.57.46 #       <linuxstb> JdGordon: Thinking about the offset, I think we're probably trying to think too far ahead.  So maybe just add a #define to config-$target.h and keep it in the driver as funman has it now.  There's no real reason to change it at the moment.
11.57.56 Join    reacocard [0] (n=reacocar@WL-112.CINE.HMC.Edu)
11.58.12 #       <kugel> which is what I proposed :)
11.58.52 #       <linuxstb> kugel: Yes, but it's always worth considering other methods...  I still think we may want to change it in the future, but it can wait until we actually need to.
11.58.56 #       <amiconn> The offset is only needed in disk.c iiuc
12.06.33 #       <JdGordon> yes, its only needed there
12.06.38 Nick    Darksair{away} is now known as Darksair (n=user@123.112.115.229)
12.06.57 #       <JdGordon> seems its not actually getting mounted as a superfloppy so my change breaks it :(
12.07.08 Join    Nico_P [50] (n=nicolas@rockbox/developer/NicoP)
12.18.44 #       <linuxstb> Won't it also be need for a usb_storage driver?
12.20.22 #       <JdGordon> depends how usb access the disk?
12.21.01 Join    moos [0] (i=moos@81-66-141-133.rev.numericable.fr)
12.21.14 #       <linuxstb> usb storage just exposes the raw sectors
12.25.04 Join    Zambezi [0] (i=stolgfor@bnc.fran.dotbnc.se)
12.33.16 #       <JdGordon> linuxstb: how does the needing a pp folder fit into our message before?
12.33.17 Quit    kugel (Remote closed the connection)
12.35.30 #       <linuxstb> It doesn't specifically, it's just that the more I look at that tree, the more PP-specific things I notice in the top-level generic target/arm/ directory.
12.36.24 #       <JdGordon> ok
12.37.34 #       <JdGordon> how should it be done though? we dont want to make pp at the same level as arm... and putting ipod/sansa under it would go one too many levels
12.38.37 Join    jhulst [0] (n=jhulst@unaffiliated/jhulst)
12.44.59 Quit    tvelocity (Read error: 110 (Connection timed out))
12.47.38 #       <linuxstb> JdGordon: I'm not sure.   The problem is that some things are target-specific based on CPU, and others are target-specific based on manufacturer/model.  It just happens that the vast majority of targets are now ARM-based, so lots of things are thrown in there when arm isn't the real common denominator (e.g. lcd-ssd1815.c, usb-drv-arc.c)
12.51.46 #       <JdGordon> maybe the really target specific bits in them go where they should, and the rest moves up to drivers?
13.06.43 Join    Linton [0] (n=irc_twin@user-5445df2b.lns3-c13.telh.dsl.pol.co.uk)
13.09.14 #       <Linton> Hi, I have a WPS design question: is there a way to make part of the background transparent, so the users bg colour is used?
13.09.33 Join    Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com)
13.11.49 #       <Linton> I tried using always-dispayed images for the non-transparent part of the background, but are shown in front of text and progress-bar elements - can this be avoided?
13.12.04 #       <linuxstb> Linton: No, either the backdrop is used, or the background colour, not a combination of the two.
13.13.25 #       <Linton> Am I likely to find a work-around of any kind, or should I just give up on the idea?
13.14.02 Quit    Thundercloud (Remote closed the connection)
13.14.25 #       <linuxstb> Give up on the idea.  You (the theme designer), not the user gets to choose the colours...
13.15.48 #       <Linton> OK, thanks for the info.
13.19.01 #       <robin0800> Linton: Can you not use a background where some of it is transparent?
13.20.31 Quit    Nibbler (Read error: 110 (Connection timed out))
13.21.53 #       <Zagor> with full builds, the speed difference is more reasonable: 2:50 vs 3:14 for -j1 and nearly identical 1:25 vs 1:26 for -j4
13.23.20 #       <Linton> robin0800: Unfortunately magenta (FF00FF - magic transparent colour most bitmaps) is just shown as magenta when used on the background
13.24.06 #       <robin0800> Linton: even on the player?
13.24.46 Join    fredddy [0] (n=freddy@p3E9E1DE8.dip0.t-ipconnect.de)
13.24.51 #       <Linton> Ah, interesting question - I may be putting too much faith in testing on the sim.  You think there is likely to be a difference?
13.27.01 #       <robin0800> Linton: I know you can see background of icons in paint programs but this disapears on the unit don't know about the sim try an icon
13.27.54 #       <n1s> if that differs between sim and target it's a bug and AFAIK transparency doesn't work for backdrops, like linuxstbalready said...
13.29.26 #       <robin0800> n1s: is icons the only place transparency works?
13.29.48 #       <Linton> It seems the sim is accurate - just done a little test on my gigabeat and am looking at a nice pink rectange.
13.29.51 #       <linuxstb> robin0800: Rockbox has diifferent functions for dealing with transparent bitmaps and normal bitmaps.  Only the specific transparent bitmap functions look for magenta and replace it.  The backdrop code doesn't.
13.30.08 #       <moos> n1s: congrates for your FM works
13.30.31 #       <n1s> moos: thanks :) now to integrate it nicely :)
13.30.48 #       <moos> hehe ;)
13.31.20 Quit    robin0800 (Remote closed the connection)
13.31.55 Join    Bensawsome [0] (n=Bensawso@unaffiliated/bensawsome)
13.35.12 Join    Nibbler [0] (n=Nibbler@mx00.linkprotect.de)
13.39.50 Join    kugel [0] (n=chatzill@unaffiliated/kugel)
13.41.49 Join    _Andrew_ [0] (n=on@m83-188-214-39.cust.tele2.se)
13.42.04 Part    Linton
13.44.03 ***     Saving seen data "./dancer.seen"
13.45.19 #       <Nico_P> Zagor: still, it's quite a speedup. also there seem to be plenty of other advantages
13.45.39 #       <Nico_P> I haven't tried, but I assume recompiling a single plugin is much faster now?
13.45.47 #       <Zagor> yes. speed was never the goal
13.46.06 #       <Zagor> make `pwd`/apps/plugins/jpeg/jpeg.rock
13.46.28 #       <Nico_P> nice :)
13.46.47 #       <Nico_P> what about "make" when only one plugin has been modified?
13.47.25 #       <Zagor> since this is a single huge dependency tree (the dep file is > 1MB) you just run 'make' and it will build what needs building
13.47.35 #       <Zagor> and nothing else
13.52.29 #       <Nico_P> awesome :)
13.54.28 Quit    Nibbler ("Ex-Chat")
13.57.48 Quit    kugel (Remote closed the connection)
13.58.36 Join    kugel [0] (n=chatzill@unaffiliated/kugel)
14.12.26 #       <Zagor> "124 files changed"
14.12.33 #       <Zagor> it
14.12.40 #       <Zagor> it's growing into a whopper
14.20.10 #       <dany_21a_> hi all... is the current SVN trunk supposed to work (iie. load the rb-fw from the flash) on a fuze?
14.20.35 #       <dany_21a_> I get a *PANIC* disk_init failed!
14.21.04 #       <dany_21a_> (its a 8GiB fuze)
14.21.10 #       <JdGordon> no
14.21.54 #       <dany_21a_> ah - okay... than its "okay" :) i thought i read something on the irc
14.21.56 #       <linuxstb> Zagor: Why do you need a new "BMP2RB_FORMAT" variable, and why is there only one?  There are potentially 4 different bmp formats (mono, native, remote_mono, remote_native).
14.22.28 #       <kugel> dany_21a_: it's possible though with a few modifications, I've done it
14.22.29 #       <Zagor> potentially, yes. only one target uses more than one.
14.23.09 #       <linuxstb> I thought all (or at least, most) of the remote targets have different displays to the main LCD?
14.23.11 #       <Zagor> but yes, I need to revise that portion since it obviously does not work on that target
14.23.13 #       <dany_21a_> kugel: any change that this will be in svn soon?
14.23.23 #       <Zagor> linuxstb: yes but the same display format
14.23.51 #       <dany_21a_> *chance
14.24.01 #       <kugel> dany_21a_: I'd think so. it's just that someone needs to create a patch and someone who committs it
14.24.14 #       <kugel> maybe I'll put up the patch later today
14.24.32 #       <fredddy> how can I disassemble the Fuze firmware ?
14.24.59 #       <linuxstb> Zagor: What do you mean?  e.g. H300 has 16-bit colour main LCD, and mono remote.  X5 has 16-bit main, 2-bit remote, H100 has 2-bit main, 1-bit remote...
14.25.32 #       <dany_21a_> kugel: large changes? if not, could you shortly describe it/pastbin it?
14.25.34 #       <GodEater> fredddy: objdump is a freebie (but not fantastic) dissassembler ?
14.26.21 Join    fyre^OS [0] (n=nnscript@cpe-68-173-233-71.nyc.res.rr.com)
14.26.32 #       <Zagor> linuxstb: ah. looks like I hastily misinterpreted the options in tools/configure.
14.27.02 #       <fredddy> GodEater, if have it installed but it always says "File format not recognized"
14.27.04 #       <kugel> dany_21a_: should be a one liner, wait a second
14.28.02 #       <linuxstb> fredddy: You need something like "arm-elf-objdump -b binary -m arm -D file.bin > file.txt" - where file.bin is about 128KB starting from 1024 bvtes (I think) into the firmware image file.
14.28.40 #       <linuxstb> fredddy: But it's a mixture of ARM and thumb code, so you also need to do a thumb version (add something like -M force-thumb to the options)
14.29.08 #       <fredddy> could [--start-address=address] from the man page help ?
14.29.46 #       <linuxstb> I never use it.  But I think that defaults to zero anyway, which is where the firmware is executed from.
14.30.20 #       <JdGordon> kugel: can you test that patch i put in the forum thread?
14.31.03 #       <amiconn> Zagor: There'll be more than the 4 current formats...
14.33.32 #       <kugel> dany_21a_: try  http://pastebin.ca/1254297a and build a new bootloader
14.33.38 #       <linuxstb> fredddy: Sorry, I misunderstood your question.  I've never tried that option, so I'm not sure what it's doing.
14.35.58 #       <kugel> JdGordon: sure, later
14.37.02 #       <kugel> JdGordon: looking at it you check for multivolume twice? first time at the creation of the STORAGE_OFFSET macro, the second time when using it
14.37.27 #       <fredddy> thx for your help linuxstb  I´ll try my best in looking for the Fuze buttons
14.38.41 Join    Strife89 [0] (i=a810eba1@gateway/web/ajax/mibbit.com/x-818be5d1bc6482be)
14.39.25 #       <kugel> JdGordon: STORAGE_OFFSET is already dependant on multivolume so the additional IF_MV_NONVOID looks reduntant to me
14.39.35 #       <kugel> redundant*
14.39.58 Join    bmbl [0] (n=Miranda@unaffiliated/bmbl)
14.40.16 #       <kugel> fredddy: would be awesome if you find them
14.40.40 #       <JdGordon> its not dependant
14.42.13 Quit    fyrestorm (Read error: 110 (Connection timed out))
14.42.29 #       <kugel> JdGordon: that part looks very dependent to me http://pastebin.ca/1254303
14.42.31 #       <linuxstb> JdGordon: I was also wondering why IF_MV_NONVOID is needed - I didn't use it in my patch.
14.42.49 #       * JdGordon double checks and realises it was a copy/paste error
14.42.54 #       <JdGordon> its not needed but does no harm
14.43.37 #       <linuxstb> I also wouldn't use a temporary variable, even though gcc would hopefully optimise it away
14.44.02 #       <Strife89> gevaerts: Hmmm, "Maxtor drives are known for their firmware problems." That I was unaware of.......
14.44.03 #       * linuxstb still thinks it's best to just leave it as it is for now though...
14.44.04 #       <kugel> the const int offset would also not be needed
14.44.14 #       <kugel> argh, linuxstb beat me :S
14.44.19 Quit    moos (Read error: 104 (Connection reset by peer))
14.44.55 Join    moos [0] (i=moos@81-66-141-133.rev.numericable.fr)
14.45.15 Join    faemir [0] (n=quassel@88-106-238-33.dynamic.dsl.as9105.com)
14.45.39 Part    B4gder
14.45.39 #       <JdGordon> yes its probably not needed just yet, but that means it wont be done until later when someone tries to figure out why the hell the sd driver is returning nonesense sectores
14.46.53 #       <kugel> I thought SanDisk did some fat hacks and put their firmware "partition" into that part
14.47.35 #       <JdGordon> whats to say someone wont want to try reading/writing to that OF "partition"?
14.48.00 #       <kugel> afair that was exactly the way to recover the e200v2
14.48.23 #       <kugel> writing a dump of that part into that part if the OF wasn't functional anymore
14.50.34 #       <Zagor> BMP2RB_FORMAT removed
14.50.36 Join    J-23 [0] (n=kvirc@a105.net128.okay.pl)
14.51.44 #       <kugel> so, writing to that part would render the player into a brick (as long as rockbox isn't installed)
14.52.41 Quit    fyre^OS (Read error: 110 (Connection timed out))
14.55.39 Join    nplus [0] (n=nplus@141.25.Globcom.Net)
14.56.36 #       <Zagor> hmm jpeg.rock becomes 0x114 bytes too large :-(
14.56.47 #       <Zagor> on archos recorder, that is
14.57.27 #       <n1s> is it using -Os like the core does on archos?
14.57.32 #       <Zagor> yes
14.58.05 #       <J-23> hmm, strange - after booting current Rockbox SVN code on my e280v2 (patched with JdGordon's patch) I see grey screen and grey (little darker than background) "Connected" text
14.58.16 #       <Zagor> I'll build it in svn and compare the maps
14.58.31 #       <JdGordon> the connected is probably from the OF after usb?
14.58.39 #       <J-23> yes
14.58.57 #       <J-23> it's in same place as on screen when player's connected to computer
15.00.50 #       <J-23> hm, it disappeared after some time
15.02.29 #       <Zagor> ahh, pluginlib is added wrong, so it ends up completely in jpeg.rock
15.03.39 Join    LambdaCalculus37 [0] (i=44a04303@gateway/web/ajax/mibbit.com/x-352268621cb663f2)
15.04.19 Join    TheSphinX^ [0] (n=cold@p54A5DC14.dip.t-dialin.net)
15.06.15 Join    robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com)
15.07.42 #       <bodymind> where is that patch for e200v2?
15.08.11 #       <J-23> bodymind: http://forums.rockbox.org/index.php?topic=14064.new;topicseen#new
15.09.34 #       <linuxstb> JdGordon: Your patch looks wrong if the disk has a partition table...
15.10.12 #       <JdGordon> thats what I thought... but then if the disk does it wouldnt be using this?
15.10.29 #       <JdGordon> the disk has a mbr apparently starting at that offset
15.10.49 Quit    Strife89 ("mibbit.com: Ay, more Trig......")
15.12.24 #       <linuxstb> The point is that the first N sectors of the disk aren't exposed via USB, so aren't part of the "real" disk.  There is no MBR at the real sector 0 on the disk - it's just the firmware image.  In effect, the NAND is split into two logical disks.
15.12.38 #       * linuxstb doesn't know how the OF would react to a partition table though...
15.13.41 #       <JdGordon> which part of the patch looks wrong?
15.13.47 #       <JdGordon> unless i upped the wrong version
15.14.16 #       <JdGordon> no, thats the right one
15.15.04 #       <linuxstb> The patch simply doesn't deal with the potential situation of a partition table being there.
15.16.31 Quit    kugel (Read error: 113 (No route to host))
15.16.45 Quit    TheSphinX^ ("XChat@Linux")
15.17.35 #       <bodymind> ah tkx 8)
15.23.06 Nick    JdGordon is now known as JdGordon|zzz (n=jonno@rockbox/developer/JdGordon)
15.26.00 #       <Zagor> ah, I was missing -ffunction-sections in the pluginlib build
15.28.06 #       <linuxstb> Zagor: I assume your patch also gets rid of all the (almost identical) Makefiles in the individual SUBDIR plugin directories?  Unifying those was something I've been meaning to do...
15.28.47 #       <Zagor> well it replaces them with minimal <dir>.make files, with typically 10 lines each
15.29.13 #       <Zagor> compile and link rules are inherited from upstream files
15.29.35 #       <linuxstb> That sounds like what I had in mind.
15.34.18 #       <linuxstb> Zagor: I don't want to distract you from the main build system, but if you have a chance, could you look at the Makefile in rbutil/mkamsboot/ and see if you can suggest any improvements?  It currently has lots of copy/pasted rules (building multiple binaries from the same dualboot.S source file, using different #defines for different builds) and I'm sure there must be a cleaner way...
15.35.42 #       <Zagor> simply using $< and $@ would clean it up a little bit
15.36.23 #       <Zagor> also that will allow you to use a single link rule, since those are the same
15.36.52 #       <Zagor> i.e: dualboot-clip.elf: dualboot-clip.o
15.37.02 #       <Zagor> arm-elf-ld -e 0 -Ttext=0 -o $@ $<
15.37.30 #       <Zagor> I'll mock something up and paste it for you
15.37.53 Part    LinusN
15.39.40 #       <n1s> should tracker tasks marked as "Due in version 3.0" that are still open be marked as "Due in version 3.1"?
15.43.58 Join    XavierGr [0] (n=xavier@rockbox/staff/XavierGr)
15.44.04 ***     Saving seen data "./dancer.seen"
15.44.30 #       <linuxstb> n1s: Sounds sensible - assuming we can ever agree on when 3.1 should be...
15.45.47 #       <n1s> I'll do it then, I think we should decide as soon as possible so people know a while before the freeze happens.
15.46.37 #       <linuxstb> OK, let's decide then.  When do you want to release 3.1? ;)
15.47.15 #       <n1s> I still like your suggestion of 23rd Dec
15.48.32 Join    m0f0x [0] (n=m0f0x@189-47-58-6.dsl.telesp.net.br)
15.48.33 #       <linuxstb> It seems a few people would prefer a 4-month cycle, and amiconn has said he would prefer a January freeze/release, rather than releasing before Christmas, so that would suit him...
15.49.00 #       <n1s> perhaps it's time to try out the RSB for this one?
15.49.03 #       <linuxstb> I think 3 months is enough, but there's not much difference between 3 and 4, so am happy to go with 4 for the sake of getting an agreement.
15.49.44 #       <n1s> I don't feel strongly either but the difference between 4 and 5 is even smaller and so on ;)
15.53.42 #       <Zagor> linuxstb: http://www.nopaste.com/p/arJBipSrD
15.54.20 #       <n1s> btw, any h10 users who can comment on FS#7672 around?
15.54.27 #       <preglow> i think i'd prefer 4 months
15.54.46 #       <preglow> three releases a year sounds much better than four
15.57.01 Quit    ap0 (Read error: 104 (Connection reset by peer))
15.58.00 #       <LambdaCalculus37> As long as it's three stable releases a year. ;)
15.58.11 #       <Zagor> I'm getting assembler errors in libffmpegFLAC on m68k
15.58.20 #       <Zagor> "Error: symbol `l1_shift' is already defined"
15.58.30 #       <Zagor> does this ring a bell with anyone?
15.59.06 #       <preglow> no...
15.59.07 #       <n1s> linuxstb: is FS#8391 still useful to keep open?
15.59.15 #       <preglow> i'll check it out
15.59.22 Quit    MrDuck (Read error: 110 (Connection timed out))
16.00.04 #       <linuxstb> Zagor: Thanks.  There's still too much duplication for my liking, but it shows me the way forward.
16.00.18 #       <preglow> shndec.c
16.00.32 #       <preglow> symbol used properly as far as i can see
16.00.33 #       <Zagor> linuxstb: it's difficult to remove more duplication and still keep it semi-readable
16.00.48 #       <Zagor> preglow: it goes away when compiled with -O2...
16.00.52 #       <preglow> wtf
16.01.27 #       <Zagor> -O3 gives the error, -O2 doesn't
16.01.54 #       <preglow> well
16.01.58 #       <preglow> that turns on inlining
16.02.08 #       <Zagor> this is one of the trickier things with single make: every directory wants different -O flags
16.02.09 #       <preglow> that function is used several times in the same place
16.02.18 #       <preglow> but gcc can't be THAT stupid
16.02.57 #       <linuxstb> Zagor: I was thinking of using something like ".arm.o" for arm binaries, and ".o" for native binaries.  And maybe renaming the bootimg files to have the same name as the dualboot - i.e. having one set of rules to go from "dualboot-target.elf" to "dualboot-target.o" (the file currently called bootimg_target.o)
16.03.29 #       <preglow> Zagor: hack shndec.c, find that label, make it local and see if it vanishes
16.03.35 #       <Zagor> linuxstb: ok, sounds fine
16.03.47 #       <preglow> just prefix it with . or something
16.03.52 Join    tvelocity [0] (n=tony@195.167.65.109)
16.04.04 #       <n1s> Zagor: i got that same failure when testing gcc 4.3 for coldfire, removing 'volatile' from that asm block "fixed" it but that seems very fishy
16.04.34 #       <Zagor> preglow: nope. Error: symbol `.l1_shift' is already defined
16.04.50 #       <preglow> Zagor: well, numberic labels? :>
16.05.02 #       <preglow> those should never yield that error
16.05.32 #       <preglow> n1s: if removing the volatile fixed it, it sounds like gcc just ditched that block of code altogether
16.05.54 #       <preglow> thought it really shouldn't, given those constraints
16.06.06 #       <preglow> amiconn: what were the rules gcc uses to see if it can ditch an asm block again?
16.06.11 #       <Zagor> numeric labels fixed it. is that a proper solution? my asm is ... rusty.
16.06.28 #       <preglow> Zagor: nothing wrong with it, the labels don't seem descriptive to me anyway
16.06.39 #       <n1s> I think i tested shn decodign after that and it worked but i have no idea why that change should make sense
16.06.56 #       <preglow> i'd rather see functions like that implemented naked to not rely on gcc like this
16.07.01 #       <preglow> it breaks so badly between versions
16.07.45 #       <preglow> i had problems with libdemac when trying gcc 4.3 for arm
16.07.52 #       <preglow> the only goddamn gcc i got to work on os x
16.07.54 #       <n1s> yes, inline asm is the biggest source of breakage when "upgrading"
16.08.04 #       <linuxstb> n1s: I'm not sure - that comment from October 2008 seems like a different issue.  There was an old problem with some ipod bootloaders not dual-booting, but that mysteriously went away (IIRC).
16.08.16 Quit    CaptainSquid ("Miranda IM!")
16.09.43 #       <Zagor> oops
16.09.50 #       <Zagor> shndec.c:(.icode+0x1a): relocation truncated to fit: R_68K_PC16 against `*UND*'
16.11.00 #       <preglow> Zagor: what are you trying to do, btw?
16.11.10 #       <Zagor> build :-)
16.11.14 #       <preglow> Zagor: that looks like another inline asm bug
16.11.25 #       <amiconn> preglow: Gcc tries to optimise asm blocks similar to function calls. If none of the block's output values are ever used, it'll drop the block, *unless* the block is marked volatile
16.11.30 #       <Zagor> I'm going through the different targets to make sure they build with my new makefiles
16.11.46 Join    tyfoo [0] (n=tyfoo@dyndsl-095-033-109-006.ewe-ip-backbone.de)
16.11.47 #       <amiconn> Obviously it won't drop a block with no outputs (works the same way as a volatile block)
16.11.49 #       <preglow> Zagor: oh, and changing the makefiles alone provoke these errors?
16.12.37 #       <amiconn> Zagor: Do you have an explanation for the weird Player build behaviour? It still happens, even with after your rombox fix
16.12.38 #       <Zagor> preglow: yes. since I'm using the same flags for all files (unless I add exception rules) some files get other -O flags than in the "old" build
16.13.15 #       <preglow> Zagor: you're going to put them back, i assume? if a codec has different O flags, it's usually for good reasons
16.13.39 #       <amiconn> Zagor: The -O options in the current build system are fine tuned in several cases. If you change them, you'll lose performance in several cases
16.14.04 Quit    jhulst (Read error: 148 (No route to host))
16.14.09 #       * linuxstb deletes the same sentence...
16.14.26 #       <Zagor> of course
16.14.40 #       <preglow> any reason to care about these small build errors then? :P
16.15.22 #       <Zagor> amiconn: I haven't looked into that problem.
16.15.37 #       <Zagor> preglow: I guess not
16.15.48 #       * Zagor crawls back under his rock :)
16.16.33 Join    Llorean [0] (n=DarkkOne@ppp-70-242-15-169.dsl.hstntx.swbell.net)
16.16.48 #       * preglow is thankful he doesn't have to look at makefiles
16.19.38 Join    Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com)
16.19.57 Quit    einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
16.23.10 #       <preglow> anyone know if there's a reason not to go with 2.19 binutils and 4.0.3 gcc? i'm starting to think binutils is my os x problem
16.24.53 #       <LambdaCalculus37> preglow: I should check my binutils as well to see what version I have.
16.25.41 #       <n1s> preglow: will not work for coldfire, but afaik other targets should be no problem
16.26.08 #       <n1s> (unless there's a way to override ld's compatible ISA check)
16.27.01 #       <LambdaCalculus37> preglow: Do you have sh-elf-ld in your /usr/local/sh-elf/bin folder?
16.27.20 #       <LambdaCalculus37> For some reason, I don't have that file, and I can't build any Archos builds because of that.
16.28.57 #       <preglow> n1s: arm is my immediate concern
16.29.08 #       <preglow> LambdaCalculus37: haven't even tried building for sh
16.29.13 #       <preglow> like i said, arm is my immediate concern
16.29.52 #       <LambdaCalculus37> Can you try to set up for sh and see if you can the sh-elf-ld binary?
16.32.10 #       <preglow> well, i can't even get the arm-elf-ld binary
16.32.23 #       <preglow> so it would not surprise me if i coudn't get the sh one either
16.37.42 #       <preglow> configure: error: installation or configuration problem: C compiler cannot create executables.
16.37.48 #       <preglow> isn't that just the cutest error?
16.38.52 #       <linuxstb> Which native gcc version do you have?  Does OS X have multiple versions installed that you can choose from?
16.39.06 #       <preglow> oh, great
16.39.09 #       <preglow> an autotools bug
16.39.26 #       <preglow> ld: can't open output file for writing: conftest.dSYM, errno=21
16.39.36 #       <preglow> this is why it fails, gcc gets passed some shit from autotools
16.39.56 #       <preglow> have i mentioned i hate autotools?
16.40.04 #       <linuxstb> Not this afternoon.
16.40.26 Join    TheSphinX^ [0] (n=cold@p54A5DC14.dip.t-dialin.net)
16.40.37 #       <preglow> well, let's try new binutils, then
16.41.13 #       <preglow> since fighting autotools sounds about as appealing as suicide by drytumbling right now
16.42.49 #       <preglow> perhaps i could just regen configure
16.42.59 Join    kugel [0] (n=chatzill@unaffiliated/kugel)
16.43.48 Quit    Bensawsome (Read error: 54 (Connection reset by peer))
16.45.15 #       <preglow> 2.19 did build
16.45.21 #       <preglow> but i knew that already
16.45.31 Quit    faemir (Read error: 110 (Connection timed out))
16.45.35 Join    Bensawsome [0] (n=Bensawso@unaffiliated/bensawsome)
16.46.27 #       <preglow> anyone know if there's a stock routine to regen autotools in gnu packages?
16.46.41 #       <preglow> autoreconf didn't seem to do all that was needed
16.46.43 Join    kkurbjun [0] (n=kkurbjun@c-24-9-80-197.hsd1.co.comcast.net)
16.47.14 Quit    kkurbjun (Client Quit)
16.48.56 Join    Schmogel [0] (n=Miranda@p3EE2177A.dip0.t-ipconnect.de)
16.49.17 #       * amiconn figured out the optimisation formula for the filter buffer sizes
16.50.18 #       <n1s> ooh, even faster ape?
16.50.43 #       <amiconn> I hope so (for -c2000 and up). It's building right now
16.51.33 #       <n1s> btw, re the midi plugin, is the gain from that early termination in the arm multiplier significant?
16.51.46 #       <amiconn> Whether the effect is visible or not depends on how much overhead the memmove()s actually add to the filters
16.52.20 #       <preglow> n1s: depends how much it multiplies and how the operands look
16.52.30 #       <amiconn> I optimised the sizes so the amount of copied bytes per sample becomes minimal
16.52.34 #       <preglow> never did look much at midiplayer
16.52.47 Quit    lasser ("ChatZilla 0.9.83 [Iceweasel 3.0.3/2008092816]")
16.53.45 #       <amiconn> The single-filter cases are simple - simply use the whole (IRAM) buffer. The 2-filter and 3-filter cases are a bit more complex
16.53.49 #       <n1s> preglow: one of the multiplies that is done once for each voice for each sample has one operand that is always between 0-127 the other is signed 16 bit iirc
16.54.31 #       <amiconn> The amount of copying becomes minimal if the history size's ratio is that of the square root of the orders
16.54.41 #       <preglow> n1s: then yes, significant
16.54.48 #       <preglow> n1s: make sure that operand is always the last one
16.55.25 Join    jgarvey [0] (n=jgarvey@cpe-098-026-069-229.nc.res.rr.com)
16.55.30 #       <n1s> preglow: and there is no way to do this in c right? (or will gcc do it if one has char type)?
16.55.30 #       <amiconn> E.g. -c4000 filter orders are 256 and 32 (1:8), hence the history sizes should be as close as possible to 1:2.828..
16.55.38 #       <preglow> n1s: no way, no
16.55.43 #       <preglow> bloody overkill ape format...
16.56.03 #       <preglow> n1s: no idea if gcc will be clever enough to do it properly with char, doubt it
16.56.51 #       <n1s> preglow: haha, yes doubtful. I'll try to make some asm macro or something when i get LambdaCalculus37's sansa then
16.57.35 #       <preglow> oh sweet lord, it installed the bins, but called them ar, not arm-elf-ar, etc....
16.57.38 #       <preglow> how i hate autotools
16.58.14 #       <LambdaCalculus37> Getting a complete, proper environment set up under OS X is proving to be a bitch, indeed. :/
16.58.58 #       <preglow> how hard can it bloody well be?
16.59.11 #       <preglow> these guys are used to old rotten vax and crays and whatnot, and autotools works there
16.59.46 #       <preglow> great! gcc build gives same error
16.59.52 Quit    Acky (Connection timed out)
16.59.57 #       <preglow> now, if i wasn't so goddamn tired of having to use vmware to develop, i'd stop right here
17.00.07 #       <n1s> preglow: my toolchains has them prefixed in for example /usr/local/m68k-elf/bin/ but with no prefixes in /usr/local/m68k-elf/m68k-elf/bin/
17.00.14 Quit    J-23 ("Flying cow pressed ^D on my keyboard.")
17.00.36 Quit    XavierGr ()
17.00.39 #       <preglow> n1s: other way around here :-)
17.01.09 #       <preglow> n1s: what's the arm-elf dir for?
17.01.15 #       <n1s> can't you just "fix" your PATH then? :)
17.01.41 #       <preglow> well, it has fewer tools, and why the hell same tools in several dirs?
17.01.53 Join    J-23 [0] (n=kvirc@a105.net128.okay.pl)
17.02.55 #       <n1s> i don't know why they do that.
17.03.12 Join    MrDuck [0] (n=kachna@r4ax178.net.upc.cz)
17.06.20 #       <preglow> they're the same files.........
17.06.40 Join    ap0 [0] (n=kvirc@mer90-1-88-166-249-88.fbx.proxad.net)
17.06.43 Join    XavierGr [0] (n=xavier@rockbox/staff/XavierGr)
17.07.15 Quit    Thundercloud (Remote closed the connection)
17.07.17 #       <preglow> well, it's either back to vmware with me
17.07.23 #       <preglow> or i learn to live with the 4.3.2 install i have that works
17.07.32 #       <preglow> and i don't relish the thought of using another compiler than other devs do
17.07.55 Quit    Zagor ("Client exiting")
17.19.29 #       <amiconn> Whoa
17.20.01 Join    PaulJam [0] (i=PaulJam_@vpn-3057.gwdg.de)
17.26.27 #       <bodymind> JdGordon|zzz: i get a ATA Error: -1 on my e260v2 how can i debug this?
17.28.06 Join    miepchen^schlaf [0] (n=miepchen@p579ECC73.dip.t-dialin.net)
17.29.01 #       * amiconn didn't expect the result he got
17.29.11 #       <linuxstb> amiconn: APE?
17.29.16 #       <amiconn> yes
17.29.57 #       <amiconn> Adding an extra element to struct filter_t (for storing the history size) costs more performance than the bigger buffers gain
17.30.29 #       <linuxstb> :(  I was expecting good news...
17.30.51 #       <amiconn> I have an idea how to fix this though (needing no extra element), and perhaps even get rid of another one
17.32.00 Join    domonoky [0] (n=Domonoky@rockbox/developer/domonoky)
17.32.59 #       <amiconn> Basically, struct filter_t has some redundant pointers
17.34.10 #       <amiconn> historybuffer and coeffs are redundant (their difference is always == ORDER)
17.35.35 #       <amiconn> So I could replace historybuffer with an end-of-filter pointer. Checking that in the if() is even better, since it requires no added offset
17.38.52 Join    Necromas [0] (n=chatzill@141.224.236.113)
17.39.40 #       <preglow> amiconn: i use that optimization to free a register in the flac routines
17.40.19 #       <preglow> which i guess are the same as the ape ones, only with sane filter orders
17.41.55 Join    {phoenix} [0] (n=dirk@p54B4771E.dip.t-dialin.net)
17.42.11 Quit    Schmogel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
17.42.17 #       * linuxstb wonders if he'll live to see the TAK source code published
17.42.25 #       <Necromas> can anyone confirm if the 120gb ipod classic is rockboxable? what "gen" is it?
17.42.44 #       <linuxstb> Necromas: It's a "Classic" - 6th gen - not rockboxable
17.44.08 ***     Saving seen data "./dancer.seen"
17.45.16 Quit    TheSphinX^ ("XChat@Linux")
17.46.05 #       <Necromas> oh and kudos to anyone working on rockbox for the sansa view
17.46.45 #       <linuxstb> No-one is (afaik)
17.48.00 #       <kugel> LambdaCalculus37: Would you be available for a backlight fading test?
17.49.02 #       <Necromas> lies, there is a forum thread for it
17.49.15 #       <Necromas> that's not dead
17.49.24 #       <LambdaCalculus37> That doesn't mean that that someone is working on it right now.
17.49.34 #       <LambdaCalculus37> That forum thread is just for research right now.
17.49.42 #       <Necromas> research = work
17.49.48 #       <LambdaCalculus37> kugel: A little busy right now, but I'll try my best.
17.50.59 #       <kugel> I think I got a nicer way now, let's see if it works
17.52.53 Quit    reacocard (".")
17.55.29 Quit    robin0800 (Remote closed the connection)
17.58.32 Quit    kugel ("ChatZilla 0.9.83 [Firefox 3.0.3/2008101315]")
18.00.11 Join    Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com)
18.00.21 Join    kugel [0] (n=chatzill@e178104042.adsl.alicedsl.de)
18.03.50 #       <kugel> hm
18.04.01 Quit    J-23 (Read error: 104 (Connection reset by peer))
18.04.07 #       <kugel> LambdaCalculus37: no, it doesn't work :( I don't even get behind the bootloader
18.05.12 Quit    ap0 ("Ba�")
18.05.30 Join    J-23 [0] (n=kvirc@a105.net128.okay.pl)
18.08.51 Join    Sjano [0] (n=sjano@216-65-134.211310.adsl.tele2.no)
18.08.57 #       <Sjano> hello
18.09.26 #       <advcomp2019> hello
18.09.55 Join    ap0 [0] (n=kvirc@mer90-1-88-166-249-88.fbx.proxad.net)
18.10.03 #       <Sjano> I'm having trouble with my ipod video, it doesn't seem to recharge when i hook it up with a computer unless i boot up in the original firmware.
18.10.32 #       <Sjano> and i also can't enter the ipod unless i boot it up in the original firmware
18.10.55 #       <linuxstb> What do you mean by "enter the ipod" ?
18.11.16 #       <Sjano> like go in to   F:    <- ipod
18.11.24 #       <Sjano> in explorer (on windows)
18.11.59 #       <linuxstb> Rockbox doesn't have usb support on the ipods - it should reboot into the original firmware's emergency disk mode when you attach it to a computer (but that may be unreliable...).  Same with charging - I don't know the exact status, but am not surprised that it doesn't charge in Rockbox.
18.12.47 Quit    bmbl ("Woah!")
18.13.13 #       <Sjano> maybe because i use the current build or something then.... (used to atleast charge on build 18xxx
18.13.24 Quit    ap0 (Client Quit)
18.13.43 Quit    J-23 (Read error: 104 (Connection reset by peer))
18.14.39 Quit    petur ("work->...")
18.14.58 #       <kugel> iirc charging should work, but don't quote me on that
18.15.12 #       <Sjano> also the rockbox utility can't innstall a new bootloader and autodetect detects ipod video 30gb insted of 60gb (are there any diffrence on that?)
18.15.54 #       <Sjano> (installing the firmware on it works, though)
18.16.13 Join    MethoS [0] (n=clemens@host-091-097-240-074.ewe-ip-backbone.de)
18.16.48 #       <kugel> Sjano: rbutil can't distinguish between the 30 and 60 gb version
18.17.18 Join    bmbl [0] (n=Miranda@unaffiliated/bmbl)
18.18.14 #       <Sjano> kugel: yeah, i just choosed the 60gb. guessed it would be something like that.
18.18.40 Quit    kugel ("ChatZilla 0.9.83 [Firefox 3.0.3/2008101315]")
18.19.27 #       <linuxstb> Sjano: The real difference is RAM - 30GB players should have 32MB RAM, and 60GB/80GB should have 64MB RAM.  So it's safe to use the "30GB" version of Rockbox on both, but you can't use the "60/80GB" version on a 30GB - so rbutil defaults to the safe option.
18.19.40 #       <domonoky> rbutil can not distinguish the 30 and 60gb versions, but it is save to install a 30gb version on a 60 (not the other way round) ...
18.19.55 #       * domonoky is too slow... 
18.20.34 Join    J-23 [0] (n=kvirc@a105.net128.okay.pl)
18.21.27 #       <Sjano> if i manually install the firmware, is the bootloader included?
18.22.22 #       <linuxstb> domonoky: rbutil should be able to if Mr Someone implements this - http://ipodlinux.org/wiki/Device_Information (there's a RAM field)
18.22.57 #       <linuxstb> Sjano: What does rbutil say when you try to install the bootloader?  The common problem is that you're not running rbutil as the Adminstrator/root user.
18.23.34 #       <domonoky> linuxstb: mr. Someone seem to have too much todo.. :-)
18.24.00 #       <n1s> linuxstb: it could also be solved by runtime ram size detection
18.24.18 #       <linuxstb> n1s: Indeed - something else on Mr Somone's list.
18.25.04 Join    kugel [0] (n=chatzill@unaffiliated/kugel)
18.25.38 #       <kugel> so can anyone tell me how to debug rockbox build where I cannot even get to the main menu?
18.26.39 #       <n1s> printing stuff as early as possible and continuing further into the satrtup to see where it fails
18.26.58 #       <amiconn> linuxstb: Speedup for -c2000 and -c3000 is ~0.1% realtime on PP5002, -c4000 speedup is immeasurable
18.27.55 #       <domonoky> kugel: put some outputs/panicfs into apps/main.c ..
18.28.08 #       <LambdaCalculus37> amiconn: Still very slow on PP5002.
18.28.10 #       <amiconn> So it looks like the memmove() is neglectible, but the filter wrap condition simplification could probably be committed (it's basically independent)
18.29.27 Quit    linuxstb (Remote closed the connection)
18.31.43 Join    Schmogel [0] (n=Miranda@p3EE2177A.dip0.t-ipconnect.de)
18.32.00 Join    bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
18.32.43 #       * kugel still waits for 1 of the 2 ape user to thank amiconn for his recent optimizations :p
18.33.20 #       <gevaerts> I believe one of them also has backlight fading enabled ;)
18.33.24 Join    ap0 [0] (n=kvirc@mer90-1-88-166-249-88.fbx.proxad.net)
18.33.33 #       <kugel> lol...
18.33.36 #       <kugel> probably :p
18.33.37 Quit    bodymind ("Ex-Chat")
18.34.14 #       <kugel> given that I expect over 50% of the people to want this backlight fading :)
18.39.36 Quit    Darksair ("Everything that has a beginning has an end.")
18.40.00 Join    linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb)
18.42.24 #       <kugel> domonoky: uh
18.42.35 Join    aarcane [0] (n=aarcane@c-67-187-242-146.hsd1.ca.comcast.net)
18.42.39 #       <kugel> domonoky: the panicf didn't happen.
18.42.47 #       <kugel> But I'm in the main menu now :?
18.43.02 #       <domonoky> kugel: and where did you put it ? before the init() ?
18.43.26 #       <kugel> before backlight_init() in init()
18.43.36 #       <domonoky> be carefull if you put it into the init function itself.. there are two init functions..
18.43.46 #       <domonoky> one for the sim, and one for target...
18.44.22 #       <domonoky> and for me the init just takes very long, so be sure to wait a good bit after bootup...
18.44.28 #       <kugel> ah right
18.44.34 #       <kugel> I put it in the wrong one
18.44.42 #       <amiconn> linuxstb: Am I right in thinking that the 'adaptcoeffs' are always a power of 2 ?
18.44.48 Part    Sjano
18.44.50 #       * domonoky did the same yersterday.. :-) 
18.45.11 #       <amiconn> (either positive or negative of that)
18.45.35 #       <kugel> domonoky: haha :p
18.50.06 Quit    PaulJam (".")
18.52.00 #       <kugel> evil typos :S
18.52.26 #       <kugel> btw: can codec building be disabled like plugins?
18.52.52 Join    kronflux [0] (n=kronflux@blk-138-78-15.eastlink.ca)
18.55.16 #       <amiconn> That wouldn't make sense....
18.55.43 #       <amiconn> Rockbox without codecs is worth nothing on an swcodec target
18.55.57 #       <kugel> for testing only of course
18.56.03 #       <amiconn> Testing what?
18.56.38 #       <kugel> hm, make bin should do the job
18.56.52 #       <amiconn> For plugins, it makes sense, because adapting plugins to a new target needs considerable work (different buttons, screen resolution...)
18.57.03 Quit    pixelma2 ("-")
18.57.27 #       <amiconn> Codecs don't need that. Optimisation is another matter, of course
18.57.32 Join    pixelma [50] (i=pixelma@rockbox/staff/pixelma)
18.58.13 Join    jhulst [0] (n=jhulst@unaffiliated/jhulst)
18.59.34 Quit    neddy ("Leaving.")
19.01.10 Join    mofux [0] (n=quassel@dslb-092-078-069-086.pools.arcor-ip.net)
19.05.12 #       <kugel> domonoky: do I need to include something for panicf?
19.06.04 #       <domonoky> kugel: no, panicf should work as is in main.c, maybe make a test with a panicf before the init()
19.06.30 #       <kugel> domonoky: I'm not in main.c anymore. The issue must be in backlight code.
19.07.40 #       * domonoky thinks you need to include panic.h :-) 
19.07.48 #       <kugel> ok
19.07.57 #       <kugel> I did that and I don't get any panic
19.09.00 #       <domonoky> and you are sure that this code is really called ?
19.09.16 #       <kugel> not anymore
19.10.16 Quit    Shiny (Read error: 104 (Connection reset by peer))
19.10.22 Join    Shiny [0] (n=brenda@209-20-76-6.slicehost.net)
19.16.52 Quit    Thundercloud (Remote closed the connection)
19.18.24 #       <kugel> LOL
19.18.31 #       <kugel> I'm so stupid
19.20.10 #       <kugel> domonoky: yep the code wasn't called :S
19.21.22 #       <domonoky> :-)
19.22.27 Quit    m0f0x (Read error: 110 (Connection timed out))
19.25.35 Join    Horscht [0] (n=Horscht@xbmc/user/horscht)
19.26.24 #       <kugel> domonoky: believe it or not, I've never been that happy about a panic
19.26.47 Quit    tvelocity ("Αποχώρησε")
19.31.13 Quit    J-23 (Remote closed the connection)
19.36.06 Join    J-23 [0] (n=kvirc@a105.net128.okay.pl)
19.37.28 #       <kugel> nice to see that the code that I wrote while not having access to my target actually worked, although a missing #define in my target config prevented it from actually workin
19.37.38 Join    Horschti [0] (n=Horscht@p4FD4E740.dip.t-dialin.net)
19.38.24 Quit    Horscht (Nick collision from services.)
19.44.14 ***     Saving seen data "./dancer.seen"
19.50.53 Join    bluebrother [0] (n=dom@rockbox/staff/bluebrother)
20.02.10 Quit    ap0 ("Ba�")
20.02.19 Join    ap0 [0] (n=kvirc@mer90-1-88-166-249-88.fbx.proxad.net)
20.06.51 #       <preglow> anyone know if sd cards should switch to data state at once when receiving a read command?
20.16.09 Part    fredddy ("Verlassend")
20.16.55 #       <gevaerts> How should multi-driver storage handle errors in *_init()? Continue with the next driver or give up? If the former, what should it return?
20.17.24 Join    Strife89 [0] (n=michael@204.116.245.152)
20.18.05 #       * linuxstb waits for someone to ask an easy question
20.18.25 #       <gevaerts> What is your favourite colour?
20.18.56 #       * linuxstb doesn't even know that
20.20.51 #       * LambdaCalculus37 throws linuxstb into the Gorge of Eternal Peril :)
20.21.17 Join    TheSphinX^ [0] (n=cold@p54A5DC14.dip.t-dialin.net)
20.23.27 #       <nanok> is charging of the x5 target supposed to work while running rockbox (that is: work reliably, and to an actual full charge)?
20.25.08 #       <rasher> nanok: TargetStatus lists charging as "Partial" for the X5
20.25.28 #       <LambdaCalculus37> nanok: Try charging with the device off instead.
20.25.30 #       <rasher> I don't know what that means though
20.25.40 #       <rasher> Maybe someone with a clue should add a footnote
20.25.53 #       <nanok> LambdaCalculus37: thanks, i thought so..
20.26.18 #       <nanok> so the 5h or so i got today should not scare me too much. maybe there is still hope for this old battery :)
20.27.17 #       <nanok> LambdaCalculus37: (i am currently charging with the player off, btw, i was asking to know if i should still hope or just order a new battery :) )
20.30.46 Quit    Horschti ("I got raided by the FBI and all i got is this lousy quit message")
20.31.42 #       <LambdaCalculus37> nanok: If you wish to, order a new battery for it. It never hurts to have a spare, anyway. :)
20.32.20 #       <preglow> gevaerts: well, what makes sense? is an _init failure something we can recover from, or even something to be expected from time to time?
20.33.01 #       <gevaerts> I assume we can't recover, but failing to init one storage device doesn't mean anything about the others
20.33.26 #       <preglow> we might want to let the individual driver decide, really. perhaps let it return several values, one meaning "failed, but go on", one meaning "failed, panic"
20.33.37 #       <pixelma> LambdaCalculus37: but no sense in keeping a battery in the drawer and let it deep discharge...
20.33.37 #       <preglow> but again, an ata driver might not always be primary storage
20.33.56 #       <preglow> so that decision should probably not be in the driver
20.34.28 #       <LambdaCalculus37> pixelma: True...
20.34.33 #       <gevaerts> I'm going to do "first init failure stops init" now. We can always change it later
20.34.47 #       <preglow> yeah
20.35.01 Join    Acksaw [0] (n=omgwtfbb@cpc2-stok5-0-0-cust754.bagu.cable.ntl.com)
20.35.29 #       * preglow wonder why his card refuses to switch to data state :/
20.37.11 Join    Horscht [0] (n=Horscht@xbmc/user/horscht)
20.41.53 Quit    J-23 (Read error: 104 (Connection reset by peer))
20.43.10 Join    Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net)
20.43.11 Quit    MethoS (Remote closed the connection)
20.43.31 #       <gevaerts> So what should storage_spinup_time() return? I guess the most sensible is the maximum of all drive(r)s
20.43.50 Join    J-23 [0] (n=kvirc@a105.net128.okay.pl)
20.43.55 #       <gevaerts> And what about storage_last_disk_activity()?
20.44.08 Quit    AndyIL (Read error: 60 (Operation timed out))
20.44.29 #       * gevaerts wants to have a CF+Ramdisk ipod running today
20.47.24 #       <gevaerts> storage_last_disk_activity() is only used by powermgmt.c to decide on idle poweroff, so I guess it needs "most recent of all"
20.47.38 Join    AndyI [0] (i=AndyI@212.14.205.32)
20.50.24 #       <kugel> can anyone give me a short introduction to logf? I made a logf("..") in my file and built a logf build
20.50.49 #       <preglow> gevaerts: shouldn't that be renamed to storage_last_activity, then? :/
20.50.49 #       <kugel> the logf screen is empty though, and I can't find any file that seems to be created by logfdump
20.50.53 #       <preglow> :/ -> :>
20.51.16 #       <gevaerts> preglow: good point. I think that's for a separate commit though :)
20.51.48 #       <gevaerts> kugel: you also need to #define LOGF_ENABLE in the files where you want it
20.52.21 #       <kugel> ok, lets try that
20.52.22 Quit    _Andrew_ (Read error: 104 (Connection reset by peer))
20.54.58 #       <kugel> gevaerts: still no luck
20.55.18 #       <linuxstb> kugel: Which target?
20.55.26 #       <kugel> e200
20.56.00 #       <linuxstb> You need to define LOGF_ENABLE before the #include "logf.h" I think.
20.57.20 #       <kugel> linuxstb: thanks
20.57.33 #       <kugel> although, the messages are cut. is there limited space?
20.57.34 Join    MethoS [0] (n=clemens@host-091-097-240-074.ewe-ip-backbone.de)
20.58.25 Join    `Zee [0] (n=chatzill@41.247.137.65)
20.58.35 #       <`Zee> hi guys
20.58.47 #       <gevaerts> kugel: yes. 32 character IIRC
20.59.03 #       <`Zee> i just wanted to say you guy rock
20.59.17 #       <`Zee> the developers of rockbox that is
20.59.46 #       <gevaerts> Thanks :)
21.01.39 Join    Chronon [0] (n=chronon@c-24-20-245-208.hsd1.or.comcast.net)
21.02.44 Quit    kronflux (Read error: 104 (Connection reset by peer))
21.03.05 Join    kronflux [0] (n=kronflux@blk-138-78-15.eastlink.ca)
21.03.07 #       <Chronon> Does anyone know if line out works properly on the c200s?  There's a person on the forums using a dock that works with OF and apparently with Rockboxed e200, but not with a Rockboxed c200.
21.03.21 Quit    `Zee ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]")
21.03.36 Join    `Zee [0] (n=chatzill@41.247.137.65)
21.06.41 #       <Chronon> If you can shed any light on that, the topic is here: http://forums.rockbox.org/index.php?topic=19352.0
21.07.23 #       <Zagor> I don't know if any dev has a dock
21.07.30 #       <kugel> I think I found out why one should always make { } after an if ()
21.07.50 #       <rasher> My father has one, but no c200
21.08.10 #       <Chronon> Zagor: the set of people with both seems very small. . .
21.08.11 #       <rasher> And I don't know if I qualify as a dev, in that respect
21.08.29 #       <Zagor> rasher: but does your father? :)
21.08.35 #       <gevaerts> I once saw a dock in a shop. I should have bought it
21.09.08 #       <Zagor> Chronon: I see no reason to doubt the person saying it works on e200 but not on c200
21.09.44 #       <Chronon> I don't doubt them.
21.09.57 #       <gevaerts> Can I assume that any storage driver knows at boot time how many drives it handles?
21.10.10 Part    dany_21a_
21.10.29 #       <rasher> gevaerts: not usb host :)
21.10.50 #       <gevaerts> rasher: that one can have a hardcoded maximum instead :)
21.12.18 Join    tessarakt [0] (n=jens@e180080119.adsl.alicedsl.de)
21.13.03 #       <gevaerts> All I need is that it can tell me a number after _init()
21.13.21 #       <nanok> is the pinout of the plug known already? maybe a plug from a standard c/e200 could be "hacked" to test the functionality of available connections?..
21.13.55 #       <nanok> wouldn't be extremelly fun for a diy project, i must admit, but it should be a start, for testing
21.13.56 #       <bertrik> a printf in the clip bootloader should show immediately (without any calls to lcd_update), right?
21.14.51 #       <linuxstb> bertrik: It depends on the value of "verbose"
21.16.06 #       <bertrik> ah thanks
21.16.59 #       * linuxstb wonders why the AMS bootloaders set verbose to false
21.18.12 #       <preglow> and now i discover i can't input curly braces into vmware
21.18.16 #       <preglow> boy, do i need a drink
21.18.24 #       * LambdaCalculus37 hands preglow a beer
21.19.12 #       <preglow> already got one, but two at a time sounds good now :P
21.19.47 Quit    TMM (Read error: 104 (Connection reset by peer))
21.20.11 #       <preglow> haha, and gnome pukes when i try to change the layout
21.20.22 #       <preglow> i so goddamn hate computers sometimes
21.20.36 #       <preglow> with so many fine hobbies in the world, i'm doing this
21.21.28 Join    Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com)
21.24.59 Join    kachna|lappy [0] (n=kachna@r4ax178.net.upc.cz)
21.25.50 #       <kugel> linuxstb: JdGordon made a commit to the bootloader recently
21.26.04 Quit    MrDuck (Read error: 104 (Connection reset by peer))
21.26.13 #       <kugel> linuxstb: r19085
21.27.57 Join    miepchen^schlaf_ [0] (n=miepchen@p579EC3B8.dip.t-dialin.net)
21.28.35 Join    TMM [0] (n=hp@5ED10264.cable.ziggo.nl)
21.31.42 Quit    J-23 (Remote closed the connection)
21.32.06 #       <kugel> LambdaCalculus37: I think I got it nicely done now
21.32.20 Quit    Schmogel (Read error: 104 (Connection reset by peer))
21.33.32 #       <LambdaCalculus37> kugel: Post a patch at Flyspray, and I'll try it out later today.
21.33.52 #       * gevaerts spots a mess
21.33.53 Join    faemir [0] (n=quassel@88-106-238-33.dynamic.dsl.as9105.com)
21.35.09 Join    petur [50] (n=petur@rockbox/developer/petur)
21.36.50 Quit    kronflux (Read error: 104 (Connection reset by peer))
21.37.26 Join    kronflux [0] (n=kronflux@blk-138-78-15.eastlink.ca)
21.37.36 #       <bertrik> gevaerts, where?
21.38.30 Quit    tyfoo (Read error: 54 (Connection reset by peer))
21.38.40 #       <gevaerts> By some accident, all HAVE_MULTIVOLUME targets up to now have had exactly two volumes, so (a) the number isn't set in config-*.h, and (b) some places may assume 2
21.39.44 Quit    miepchen^schlaf (Read error: 110 (Connection timed out))
21.40.10 Join    sarixe [0] (n=sarixe@203.160.1.71)
21.40.11 Quit    Bensawsome ("The awsome is gone :(")
21.40.46 #       <gevaerts> This is in addition to NUM_VOLUMES being taken to mean number of drives in some parts of the code and number of FAT filesystems in other parts
21.41.31 Join    tyfoo [0] (n=tyfoo@dyndsl-095-033-084-029.ewe-ip-backbone.de)
21.43.40 #       <`Zee> whats the best way to go about installing rockbox on my e260 got it today
21.43.48 #       <`Zee> i think i did it right
21.43.52 #       <`Zee> used the installer app
21.44.16 ***     Saving seen data "./dancer.seen"
21.45.19 #       <kugel> meh
21.45.27 #       <kugel> lcd_enable is buggy (on e200 at least)
21.45.44 #       <gevaerts> `Zee: that should be the best way
21.45.50 Join    _Andrew_ [0] (n=on@m83-188-220-205.cust.tele2.se)
21.46.01 #       <`Zee> yeah only problem is the themes
21.46.11 #       <`Zee> because it rockbox 3
21.47.19 #       <LambdaCalculus37> `Zee: Rockbox Utility current can't install themes. You'll have to do that yourself.
21.47.35 #       <`Zee> yeah tried a feew but they never worked
21.47.37 Join    tvelocity [0] (n=tony@gw1.mycosmos.gr)
21.47.54 #       <linuxstb> `Zee: Themes from where?
21.48.47 #       <`Zee> i grabbed a few from this sitehttp://rbthemes.com/
21.48.48 #       <kugel> linuxstb: in lcd-e200.c, shouldn't the display_on variable set to true (false) just before lcd_enable is finished and not within?
21.48.52 #       <`Zee> oops
21.48.58 #       <`Zee> i grabbed a few from this site http://rbthemes.com/
21.49.19 #       <kugel> the way it's now, there's a chance that lcd_enabled returns true even if lcd_enable isn't done yet
21.49.25 Quit    Shiny (Read error: 104 (Connection reset by peer))
21.49.38 Join    Shiny [0] (n=brenda@209-20-76-6.slicehost.net)
21.49.42 #       <linuxstb> `Zee: Try these - http://www.rockbox.org/twiki/bin/view/Main/WpsGallery
21.50.39 #       <kugel> I assume this is the reason my while(!(lcd_enabled)); loop can create a infinite loop under certain conditions
21.51.01 #       <`Zee> the rockbox font pack on that site is it the same as the one in the installer
21.51.22 #       <kugel> could've another reason though too
21.52.47 #       <kugel> also, I spot many udelays and sleeps in the driver, is that realy required?
21.52.59 Join    culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com)
21.53.08 #       <gevaerts> `Zee: which one? rbthemes.com or www.rockbox.org/twiki/bin/view/Main/WpsGallery?
21.53.26 #       <gevaerts> `Zee: http://rbthemes.com/  site has never been official, and it looks horribly outdated. You're better of ignoring it
21.53.37 #       <`Zee> this http://www.rockbox.org/twiki/bin/view/Main/WpsSansaE200
21.54.11 #       <linuxstb> `Zee: Yes, that's the standard fonts that the installer downloads.
21.54.11 #       <gevaerts> That's the same font pack as the one from the installer, yes
21.54.15 #       <kugel> also I would assume e200 doesn't need lcd_sleep since it uses lcd enable all the time
21.54.38 #       * bertrik checks if there's something more on the i2c buses in his clip
21.54.40 #       <`Zee> als is the firware the latest in the installer or do i have to update it after with the other install?
21.54.45 Quit    parafin (Nick collision from services.)
21.54.50 Join    parafin|away [0] (i=parafin@parafin.dialup.corbina.ru)
21.55.05 #       * gevaerts decides that he can't do multi-driver properly without cleaning up HAVE_MULTIVOLUME
21.55.34 #       <kugel> gevaerts: you know it, /someone/ has to do it ;)
21.55.57 #       <gevaerts> How do we handle this? Max. partitions per drive, and max. nr of drives, and the NUM_VOLUMES for fat.c being the product of both?
21.56.24 #       <`Zee> also how much space should i have available before i install the full version?
21.58.13 #       <LambdaCalculus37> Mr. Someone has a *lot* of work to do now. :)
21.58.36 #       <kugel> gevaerts: sounds good. max nr. of drives can be two
21.58.38 Quit    sarixe ("Ex-Chat")
21.59.11 Nick    parafin|away is now known as parafin (i=parafin@parafin.dialup.corbina.ru)
21.59.33 Quit    LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client")
22.00.15 #       <gevaerts> kugel: no assumptions of that sort this time :)
22.00.49 #       <kugel> well, I doubt you will ever have the possiblity to have more than your microsd+internal memory at the same time
22.01.00 #       <kugel> except in rockbox as an app maybe
22.01.09 #       <linuxstb> usb host?
22.01.27 #       <kugel> uhm, yea, forgot about that
22.01.33 #       <gevaerts> People swapping in a two-CF card ATA adapter?
22.01.57 #       <kugel> so, really, what's the need to have (a configurable) lcd sleep if lcd_enable is always done before?
22.01.58 #       <gevaerts> rockbox as an app won't use this code anyway
22.02.35 Quit    jhulst (Read error: 110 (Connection timed out))
22.04.02 #       <`Zee> also how much space should i have available before i install the full version?
22.06.52 #       <gevaerts> `Zee: hard to say exactly. How much do you have?
22.07.07 #       <`Zee> about 1.1gb
22.07.18 #       <gevaerts> That's plenty
22.07.49 #       <gevaerts> Depending on what exactly you install you need somewhere between 5 and 50MB I guess
22.08.34 #       <`Zee> kewl
22.08.40 #       <bertrik> no luck finding any other devices on i2c so far, I was hoping to find the fm chip
22.09.17 Quit    Shiny (Read error: 54 (Connection reset by peer))
22.09.30 #       <kugel> bertrik: also no trace of buttons?
22.09.38 #       <kugel> ar wrong target
22.09.43 #       <kugel> nevermind :p
22.11.53 Join    Bensawsome [0] (n=Bensawso@unaffiliated/bensawsome)
22.12.30 #       <kugel> bertrik: remember that issue with backlight fading when you went from off to on in the settings (the screen would turn white)
22.12.42 Quit    {phoenix} (Read error: 104 (Connection reset by peer))
22.13.15 #       <bertrik> yes, I remember
22.13.20 #       * gevaerts wonders if rockbox will ever support things like that sansa slotmusic player, i.e. a single drive with hotswap
22.14.04 #       <`Zee> gevaerts i installed a full install from the installer thats all
22.14.07 #       <kugel> I can't find a solution for that. It's not reliably reproducible at all, and it only seems to happen in this particular setting
22.14.26 Join    lasser [0] (n=chatzill@W858b.w.pppool.de)
22.14.47 #       <kugel> bertrik: i.e. it doesn't happen in lists etc no matter at which point you let it fade up again
22.17.26 Quit    Zagor ("Client exiting")
22.17.54 #       <kugel> bertrik: any ideas?
22.18.11 #       <bertrik> last patch I tried didn't seem to have the problem anymore
22.20.49 Quit    Strife89 ("Ah, work to do.....")
22.21.57 #       <kugel> I have my doubts, we just might have tried it often enough
22.23.57 #       <kugel> my while loop seems to fix this particular is for just about every screen except this option screen
22.24.58 Join    HBK1 [0] (i=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net)
22.25.05 #       <kugel> bertrik: it only happens if you change from on to off and on again very quickly
22.25.20 #       <kugel> and then not even always
22.25.37 Quit    GodEater ("http://www.mibbit.com ajax IRC Client")
22.27.09 Quit    ap0 (zelazny.freenode.net irc.freenode.net)
22.27.09 NSplit  zelazny.freenode.net irc.freenode.net
22.27.09 Quit    bertrik (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    bmbl (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    ender` (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    _lifeless (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    denes_ (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    tchan (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    nanok (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    puzzles (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    blithe (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    Slack (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    thegeek (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    Gareth (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    tim__b (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    Galois (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    crashd (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    Bensawsome (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    tvelocity (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    TMM (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    pixelma (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    Nico_P (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    synergist (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    Tuplanolla (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    stu8ball (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    Kohlrabi_ (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    plus_M (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    havien (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    Bjoern-Erik (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    basti (zelazny.freenode.net irc.freenode.net)
22.27.09 Quit    ChanServ (zelazny.freenode.net irc.freenode.net)
22.28.48 NHeal   zelazny.freenode.net irc.freenode.net
22.28.48 NJoin   blithe [0] (n=blithe@li35-144.members.linode.com)
22.30.14 Join    PaulJam [0] (i=PaulJam_@vpn-3057.gwdg.de)
22.36.50 Quit    kachna|lappy (No route to host)
22.42.10 Quit    HBK- (Read error: 110 (Connection timed out))
22.43.10 #       <kugel> lcd_enabled isn't reliable at all
22.43.53 Join    GodEater [0] (i=c2cbc962@gateway/web/ajax/mibbit.com/x-b21e7d7b9b781c4b)
22.43.57 #       <gevaerts> preglow: (and others) You may want to have a look at FS#9545. It's not entirely done yet, but it compiles at least for some targets. No other tests have been done
22.45.33 NJoin   ap0 [0] (n=kvirc@mer90-1-88-166-249-88.fbx.proxad.net)
22.45.33 NJoin   bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
22.45.33 NJoin   bmbl [0] (n=Miranda@unaffiliated/bmbl)
22.45.33 NJoin   ender` [0] (i=krneki@foo.eternallybored.org)
22.45.33 NJoin   _lifeless [0] (n=lifeless@90.151.213.163)
22.45.33 NJoin   denes_ [0] (n=denes@pool-4394.adsl.interware.hu)
22.45.33 NJoin   nanok [0] (n=nanok@194.145.183.75)
22.45.33 Join    puzzles [0] (n=dan@xmms2/developer/puzzles)
22.45.33 NJoin   Slack [0] (n=brett@12-218-63-169.client.mchsi.com)
22.45.33 NJoin   thegeek [0] (n=nnscript@s243b.studby.ntnu.no)
22.45.33 NJoin   Gareth [0] (i=gareth@www.wiked.org)
22.45.33 NJoin   tim__b [0] (i=tim__b@the-ascii-scene.doesntexist.org)
22.45.33 NJoin   Galois [0] (i=djao@efnet-math.org)
22.45.33 NJoin   crashd [0] (i=foobar@lostnode.org)
22.46.00 NJoin   ChanServ [0] (ChanServ@services.)
22.46.00 Mode    "#rockbox +o ChanServ " by irc.freenode.net
22.46.39 #       <gevaerts> I'll concentrate on testing the IF_MV/IF_MD split during the next few days, as that touches all targets. I think multi-driver is a bit less critical right now
22.47.50 NJoin   tchan [0] (n=tchan@c-24-12-190-140.hsd1.il.comcast.net)
22.47.50 NJoin   Bensawsome [0] (n=Bensawso@unaffiliated/bensawsome)
22.47.50 NJoin   TMM [0] (n=hp@5ED10264.cable.ziggo.nl)
22.47.50 NJoin   pixelma [50] (i=pixelma@rockbox/staff/pixelma)
22.47.50 NJoin   Nico_P [50] (n=nicolas@rockbox/developer/NicoP)
22.47.50 NJoin   synergist [0] (i=christop@cant.be-arsed.co.uk)
22.47.50 NJoin   stu8ball [0] (n=stuart@aurora.ossified.net)
22.47.50 NJoin   Tuplanolla [0] (n=jani@unaffiliated/tuplanolla)
22.47.50 NJoin   Kohlrabi_ [0] (n=Kohlrabi@frustrum.nosebud.de)
22.47.50 NJoin   plus_M [0] (n=plus@li26-205.members.linode.com)
22.47.50 NJoin   havien [0] (n=none@68-189-143-101.dhcp.wlwl.wa.charter.com)
22.47.50 NJoin   Bjoern-Erik [0] (n=Bjoern@173.80-202-110.nextgentel.com)
22.47.50 NJoin   basti [0] (n=basti@85.214.109.173)
22.48.45 Quit    bmbl ("Woah!")
22.49.12 Quit    TMM (Connection reset by peer)
22.49.18 #       <gevaerts> preglow: I've used the original switch approach for now. I'm not convinced that function pointers are better, but feel free to propose better ideas
22.49.53 Join    jhulst [0] (n=jhulst@unaffiliated/jhulst)
22.49.54 Join    TMM [0] (n=hp@5ED10264.cable.ziggo.nl)
22.49.55 #       <preglow> gevaerts: can't think of anything better than just having an array of structs (of function pointers), where the array will contain structs per ifdef
22.50.12 #       <preglow> gevaerts: that solution means hacking just one ifdef instead of several, but i guess it's not something you do often
22.50.13 Join    LambdaCalculus37 [0] (n=LambdaCa@mb40736d0.tmodns.net)
22.50.16 #       <preglow> so anything goes
22.50.54 #       <preglow> speedwise both approaches mean jump table, so i guess they'll be about equally fast
22.51.07 #       <preglow> one less function call in pointer approach :>
22.51.40 Join    n17ikh|Lappy [0] (n=n17ikh@130-127-73-84.lightsey.resnet.clemson.edu)
22.53.00 #       <`Zee> does rockbox have an alarm clock
22.53.03 #       <gevaerts> The problem I see with function pointers is that I don't think they can be used for all functions, so you'll end up with a mix
22.53.08 #       <`Zee> say i plug this into its dock
22.53.09 Quit    nplus (Remote closed the connection)
22.53.17 #       <`Zee> will it wake me up?
22.53.31 #       <`Zee> for the sansa e260
22.53.40 #       <preglow> gevaerts: nah, they won't work if not all functions have an equivalent in each driver
22.54.47 #       <gevaerts> They do have an equivalent, but for some functions you need to call the one corresponding to the drive while for others you need to call them all once (i.e. just looping won't work, as there may be drivers that handle more than one drive)
22.55.25 #       <preglow> yeah, true
22.55.26 #       <preglow> go switch
22.55.56 #       <preglow> well, woot
22.56.03 #       <preglow> at least not sd controller claims it's getting data
22.56.09 #       <preglow> i wonder why the fifo never claims to fill, then
22.56.21 #       <gevaerts> `Zee: have you looked in the manual?
22.56.41 #       <`Zee> yeah i see a clock
22.56.48 #       <`Zee> not an alarm
22.57.00 #       <`Zee> thinking i missed it
22.57.31 #       <`Zee> damn earphones for 3k
22.57.39 #       <`Zee> small compact ones
22.57.40 #       <`Zee> wow
22.57.44 #       <kugel> bertrik: Ok, I could now reproduce this with the current build. It's not my code which causes this
23.00.29 #       <LambdaCalculus37> kugel: Got a patch posted for me to try?
23.04.22 Quit    `Zee ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]")
23.07.29 Join    m0f0x [0] (i=m0f0x@gateway/tor/x-d12175fbe3c191e9)
23.12.57 Quit    domonoky (Read error: 104 (Connection reset by peer))
23.15.01 #       <preglow> argh
23.15.07 #       <preglow> receiving data, but fifo never gets anything at all
23.17.52 Nick    HBK1 is now known as HBK (i=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net)
23.18.25 Quit    ap0 (Read error: 104 (Connection reset by peer))
23.25.22 Quit    TheSphinX^ ("XChat@Linux")
23.30.37 #       <kugel> LambdaCalculus37: buh
23.30.59 #       <kugel> LambdaCalculus37: one second, need to messure bin size
23.32.21 Quit    petur ("plop")
23.35.09 Quit    tyfoo ("Carpe diem")
23.35.22 Quit    n1s ()
23.35.25 #       <kugel> LambdaCalculus37: if I saw this correcly my new patch adds more than 2K binsize
23.35.33 #       <kugel> which can't be right
23.36.51 #       <LambdaCalculus37> kugel: That's not good. Better see what's wrong.
23.37.03 #       <LambdaCalculus37> jhMikeS: Ping
23.37.51 #       <kugel> LambdaCalculus37: the previous patch only added very few 100 bytes
23.39.00 #       <kugel> LambdaCalculus37: ok, calm down. my "svn build" alone is already 1500bytes bigger than the one shown in the build table
23.39.45 #       * LambdaCalculus37 is calm... he only had 5 cups of coffee :P
23.40.35 #       <LambdaCalculus37> And no beer. ;)
23.40.57 #       <kugel> but I wasn't ;)
23.41.44 Quit    kronflux ("Leaving")
23.44.19 ***     Saving seen data "./dancer.seen"
23.47.20 Nick    JdGordon|zzz is now known as JdGordon (n=jonno@rockbox/developer/JdGordon)
23.56.30 Join    pie [0] (i=pixelflu@4serious.net)
23.57.44 Quit    m0f0x ()
23.58.57 Nick    pie is now known as razym (i=pixelflu@4serious.net)