--- Log for 30.12.111  Server: zelazny.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 1 day and 15 hours ago

00.00.08 #       <jlbiasini> ok my mistake 67 does work after a 'make clean'
00.00.50 #       <funman> great
00.01.48 Join    xmikex_ [0] (~xmikex@217.118.81.29)
00.02.47 Quit    Topy44 (Ping timeout: 240 seconds)
00.04.52 #       <jlbiasini> does anybody know where quickscreen action get configured? On fuze+ the quickscreen provide only left and right and I saw other plyer have also fonction for up and down...
00.05.59 Join    xmikex__ [0] (~xmikex@217.118.81.27)
00.06.22 Quit    xmikex_ (Ping timeout: 252 seconds)
00.09.27 Quit    xmikex__ (Remote host closed the connection)
00.11.02 #       <dfkt> jlbiasini, usually you hold the select button longer on the item you want to set in the quickscreen. default only shows left/right, but you can add up/down
00.11.30 #       <jlbiasini> ok
00.11.44 #       <jlbiasini> thx
00.19.59 Join    Scr0mple [0] (~Simon@119.225.209.134)
00.22.28 Quit    Scromple (Ping timeout: 248 seconds)
00.24.08 Quit    amarc (Ping timeout: 240 seconds)
00.28.49 Quit    jlbiasini (Remote host closed the connection)
00.29.44 Join    JdGordon| [0] (~jonno@rockbox/developer/JdGordon)
00.38.26 Quit    einhirn (Ping timeout: 252 seconds)
00.55.13 ***     Saving seen data "./dancer.seen"
01.08.44 Quit    n1s (Quit: Ex-Chat)
01.09.21 Quit    dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.)
01.11.03 #       <bertrik> funman, at some point we disabled 4-bit support for AMSv1, I'm thinking of re-enabling it.
01.11.15 #       <funman> what was the problem with it?
01.11.39 #       <bertrik> using 4-bit instead of 1-bit should give us a 4x speedup for sd access, vs a 2x speed-up through high-speed mode that is only possible on certain cards
01.11.44 #       <bertrik> funman, I don't know
01.11.54 #       <funman> bertrik: btw on my clip zip the lcd performance is good. i dont' think removing your fix in the lcd driver will gain something, but it would surely take time
01.12.11 #       <funman> iirc some cards failed to work
01.12.42 #       <funman> or the VERIFY_ functions showed some bugs
01.12.58 #       <funman> the work was made by ranmachan and flyndice iirc
01.15.27 #       <bertrik> the svn log mentions some write corruptions in june 2010 and read corruption in july 2010
01.15.43 #       <bertrik> I tried 4-bit mode on my clipv1 and didn't run into any problem
01.16.45 #       <funman> r28834 / r28925 also
01.17.55 #       <funman> perhaps irc logs around the commits can give some logs / tests about what/how it failed
01.19.34 #       <funman> or fly to the past and tell me to add details to my commit logs
01.20.13 #       <bertrik> I can only test on my clipv2, which has no uSD, I wonder if the original problems got fixed by later bugfixes
01.20.58 #       <bertrik> bah, the AMSv1 sd driver is a bit of a mess because of the dual use of some pin for button light and sd
01.22.03 #       <funman> bertrik: hm aer you talking about amsv1 or v2 ?
01.22.07 #       <funman> clipv2 is amsv2
01.22.23 #       <bertrik> arg, I meant clipv1
01.29.53 #       <marcol07> is there any chance to display emulator in 2x zoom? :D
01.31.09 #       <funman> there's the -zoom option i think
01.32.44 Join    Horscht [0] (~Horscht@xbmc/user/horscht)
01.33.13 #       <marcol07> ok thanks :D thats what i wanted :P --zoom [val] :)
01.34.52 Join    NatasLived666 [0] (~NatasLive@168.177.176.93)
01.36.58 Quit    NatasLived666 (Client Quit)
01.38.06 Quit    efyx (Remote host closed the connection)
01.38.14 Join    NatasLived666 [0] (~NatasLive@168.177.176.93)
01.38.21 Quit    NatasLived666 (Client Quit)
01.42.37 Quit    marcol07 (Quit: CGI:IRC (Ping timeout))
01.48.59 #       <WilliamC> It's neat that you can play Doom using Rockbox but it's awkward as heck
01.49.49 #       <Torne> Yes.
01.49.52 #       <Torne> We are aware of this :)
01.50.13 #       <WilliamC> Nothing you can really do about it as these are music players not Gameboys
01.51.05 #       <Torne> other things which are really awkward include playing text adventures :)
01.51.13 #       <WilliamC> Has anyone done battery benchmarks on the Sansa Clip Zip? 
01.52.26 #       <bertrik> WilliamC, I think so, but I don't see any results yet on the SansaRuntime wiki page. So you're welcome to add some.
01.52.44 #       <WilliamC> k
01.52.50 #       <WilliamC> Just wondering
01.53.06 #       <WilliamC> I chose the theme with the least white in it in hopes it'll lessen the drain
01.53.28 #       <bertrik> the display turns off after 30s or so anyway
01.53.48 #       <WilliamC> yeah
01.55.44 Quit    bertrik (Quit: And That, My Liege, Is How We Know the Earth to Be Banana Shaped)
02.01.13 Join    xmikex [0] (~xmikex@217.118.81.17)
02.14.11 Quit    mystica555_ (Quit: Ekkusu Chatto)
02.14.34 Join    mystica555_ [0] (~Mike@71-211-210-11.hlrn.qwest.net)
02.23.02 Quit    lebellium (Quit: ChatZilla 0.9.88 [Firefox 10.0/20111221135037])
02.24.16 Quit    Strife89 (Quit: Heading out)
02.30.19 #       <bluebrother> ze, gevaerts: Rockbox Utilizy not detecting the mountpoint on a Clip+ is actually to be expected and not a bug
02.30.44 #       <ze> bluebrother: oh, ok
02.30.50 #       <bluebrother> and not detecting the mountpoint doesn't mean nothing could be detected
02.32.16 #       <bluebrother> in some cases we can recognize the player (via usb ids) but not the mountpoinz (since there is no way to retrieve the mountpoint for a given usb id)
02.43.41 #       <funman> bluebrother: can't you find the devnode for a given usb id ?
02.48.12 Join    [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940)
02.49.46 Quit    [Saint] (Ping timeout: 240 seconds)
02.55.16 ***     Saving seen data "./dancer.seen"
03.01.02 Quit    perrikwp (Ping timeout: 268 seconds)
03.01.10 Join    captainkwel [0] (~jason@207-237-110-248.c3-0.nyr-ubr2.nyr.ny.cable.rcn.com)
03.01.28 Join    user622 [0] (~user@65.29.251.49)
03.02.38 Quit    user622 (Client Quit)
03.05.35 Join    deameyes [0] (~deameyes@65.29.251.49)
03.06.41 #       <deameyes> is there a way to obtain the path of the file used when opening a viewer?
03.08.14 #       <funman> deameyes: the entry point of each plugin has a char * parameter
03.13.39 Join    Xerion [0] (~xerion@5419A30B.cm-5-2c.dynamic.ziggo.nl)
03.19.31 Quit    remlap (Quit: Leaving.)
03.20.17 Part    deameyes
03.35.36 Join    remlap [0] (~Patrick@190.28.169.217.in-addr.arpa)
03.36.10 Join    jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at)
03.36.38 Part    jlbiasini
03.37.14 Join    jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at)
03.38.05 Part    jlbiasini
03.44.04 Quit    [Saint_] (Ping timeout: 248 seconds)
03.48.46 Join    [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940)
03.56.00 Quit    anewuser ()
04.08.08 #       <captainkwel> there's no 4:3 landscape theme for raaa?
04.09.12 Join    anewuser [0] (~anewuser@186.93.131.58)
04.09.12 Quit    anewuser (Changing host)
04.09.12 Join    anewuser [0] (~anewuser@unaffiliated/anewuser)
04.11.37 #       <[Saint]> captainkwel: there's an 800x480 theme...but its not my work so I have no idea what state its in.
04.12.40 #       <captainkwel> it's also not 4:3 (hooray for letterboxing)
04.13.58 #       <[Saint]> Application builds are for a specific resolution. A build smaller than the device res will align top left iirc.
04.15.42 #       <[Saint]> I wasn't going to bother with landscape themes until there's sensor rotation.
04.24.38 #       <JdGordon|> landscape does give more room to play with
04.24.50 #       <JdGordon|> especially at res like 1024x768 :)
04.25.12 Quit    amiconn (Disconnected by services)
04.25.13 Join    amiconn_ [0] (quassel@rockbox/developer/amiconn)
04.25.34 Nick    amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn)
04.26.11 Quit    pixelma (Disconnected by services)
04.26.13 Join    pixelma_ [0] (quassel@rockbox/staff/pixelma)
04.26.15 Nick    pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma)
04.27.23 Quit    [7] (Disconnected by services)
04.27.33 Join    TheSeven [0] (~TheSeven@rockbox/developer/TheSeven)
04.38.51 #       <[Saint]> Yeah...but portrait is easier to use one handed.
04.39.39 #       <[Saint]> I definitely think portrait is the sane default, but I'm all for having sensor rotation or a "flip" setting.
04.50.59 #       <mystica555_> im rather enjoying my boogieboard of a tablet.. 
04.51.12 #       <mystica555_> next on the list: rooting, and enabling usb HID
04.51.25 #       <mystica555_> then i can finally sit in bed with my full sized keyboard and hack away
04.52.08 #       <mystica555_> disappointed to find there is a lacking of terminal/shell applications that know anything about xterm style (anything that works with curses at least) mouse control/movements
04.52.30 #       <mystica555_> tmux... tapping on a pane to select it.. win
04.52.44 #       <mystica555_> multitouch ... sending tmux commands to resize based on 2 finger dragging etc
04.52.52 #       <mystica555_> i need to learn java.
04.55.18 ***     Saving seen data "./dancer.seen"
04.59.50 #       * [Saint] boots mystica555_ into #rockbox-community
04.59.56 #       <[Saint]> :)
05.06.59 Quit    thegeek (Read error: Connection reset by peer)
05.07.13 Join    thegeek [0] (~thegeek@87.37.34.95.customer.cdi.no)
05.08.43 Join    nosa [0] (~m00k@adsl-74-235-26-132.clt.bellsouth.net)
05.10.57 Quit    nosa-j (Ping timeout: 244 seconds)
05.10.58 Nick    nosa is now known as nosa-j (~m00k@adsl-74-235-26-132.clt.bellsouth.net)
05.16.19 Join    perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com)
05.27.30 Join    Rob2223 [0] (~Miranda@p4FFF2563.dip.t-dialin.net)
05.30.38 Part    WilliamC ("Leaving")
05.31.52 Quit    Rob2222 (Ping timeout: 276 seconds)
05.46.51 Quit    xmikex (Ping timeout: 248 seconds)
06.33.59 Quit    captainkwel (Quit: Ex-Chat)
06.34.33 Quit    factor (Read error: Connection reset by peer)
06.41.39 Join    Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com)
06.45.38 Quit    Keripo (Client Quit)
06.46.15 Quit    davo (Ping timeout: 240 seconds)
06.48.12 Join    davo [0] (~davo@adsl-75-56-194-65.dsl.lsan03.sbcglobal.net)
06.51.58 Join    factor [0] (~factor@74.197.205.204)
06.55.22 ***     Saving seen data "./dancer.seen"
06.56.21 Quit    davo (Ping timeout: 276 seconds)
06.57.40 Join    davo [0] (~davo@ppp-68-120-83-185.dsl.irvnca.pacbell.net)
07.04.25 Nick    amithkk is now known as arduino-amithd (u4289@2buntu/writers/amithkk)
07.04.35 Nick    arduino-amithd is now known as amithkk (u4289@2buntu/writers/amithkk)
07.30.44 Nick    kugelp is now known as kugel (~kugel@rockbox/developer/kugel)
07.40.57 Join    Scromple_ [0] (~Simon@119.225.209.134)
07.44.06 Quit    Scr0mple (Ping timeout: 268 seconds)
07.56.46 Nick    kugel is now known as kugelp (~kugel@rockbox/developer/kugel)
07.56.47 Nick    kugelp is now known as kugel (~kugel@rockbox/developer/kugel)
08.11.31 Join    ender` [0] (~ender@foo.eternallybored.org)
08.12.35 Join    amarc [0] (~amar@cm-static-13-180.telekabel.ba)
08.23.08 Quit    T44 (Ping timeout: 240 seconds)
08.42.17 Quit    Scromple_ (Quit: Leaving)
08.55.25 ***     Saving seen data "./dancer.seen"
09.03.52 Join    Horschti [0] (~Horscht@xbmc/user/horscht)
09.05.03 Part    amarc ("Leaving")
09.06.56 Quit    Horscht (Ping timeout: 252 seconds)
09.08.02 Join    curtism [0] (~curtis@bas11-montreal02-1128531121.dsl.bell.ca)
09.08.07 #       <curtism> hello
09.08.15 #       <curtism> is anyone alive in here?
09.14.16 #       <[Saint]> Yes, lots of people are here.
09.14.44 #       <[Saint]> Please just ask your (rockbox related) question, and, welcome.
09.14.58 #       <curtism> my question went away :P
09.15.03 #       <curtism> thanks though
09.15.48 #       <curtism> seems like there are a lot of bad theme for sansa fuze D:
09.18.41 Join    pamaury [0] (~quassel@rockbox/developer/pamaury)
09.19.13 Join    stoffel [0] (~quassel@pD9E425E0.dip.t-dialin.net)
09.19.30 #       <[Saint]> Feel free to make your own...
09.19.44 #       <curtism> i'd probably make a worse one :P
09.19.55 #       <[Saint]> Or take in from the theme site, and bend it to your will.
09.20.46 #       <[Saint]> We have pretty extensive docs on theme creation in the wiki (and to a lesser extent the manuals).
09.35.13 #       <curtism> [Saint]: rockbox supports FLAC, right?
09.37.05 #       <curtism> ah, nvm, found the wiki page
09.39.52 #       <[Saint]> Yes, yes it does.
09.40.56 #       <[Saint]> You can *almost* say: "If Rockbox doesn't play <audio file>, then <audio file> is probably broken".
09.46.55 Quit    perrikwp (Remote host closed the connection)
09.50.00 Join    perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com)
09.57.43 Quit    davo (Quit: Lost terminal)
10.37.22 Join    lebellium [0] (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr)
10.39.17 #       <pamaury> is there a complete hynix datasheet for nand flash ? on google one can find a few datasheets for a few nands but I would expect some kind of generic one
10.40.29 #       <pamaury> there is the onfi one of course but it doesn't give info like timing, just the commands
10.42.08 Quit    remlap (Ping timeout: 244 seconds)
10.46.32 Join    bertrik [0] (~bertrik@rockbox/developer/bertrik)
10.48.21 Join    marcol07 [0] (~4e628860@www.haxx.se)
10.55.29 ***     Saving seen data "./dancer.seen"
10.57.33 Join    bmbl [0] (~bmbl@unaffiliated/bmbl)
11.14.54 Quit    marcol07 (Quit: CGI:IRC (EOF))
11.23.19 Join    n1s [0] (~n1s@90-224-187-190-no134.tbcn.telia.com)
11.23.19 Quit    n1s (Changing host)
11.23.19 Join    n1s [0] (~n1s@rockbox/developer/n1s)
11.23.59 Join    marcol07 [0] (~4e628860@www.haxx.se)
12.01.08 Join    [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940)
12.04.27 Quit    [Saint] (Ping timeout: 276 seconds)
12.04.45 Join    efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net)
12.09.40 Join    [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940)
12.13.39 Quit    [Saint_] (Ping timeout: 252 seconds)
12.14.35 Join    [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940)
12.17.42 Join    liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
12.18.25 Quit    [Saint] (Ping timeout: 252 seconds)
12.18.38 Quit    stoffel (Read error: Operation timed out)
12.25.15 Join    [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940)
12.28.19 Quit    [Saint_] (Ping timeout: 252 seconds)
12.36.45 Join    bimbel [0] (~bmbl@dsl50-46.pool.bitel.net)
12.36.56 Quit    bimbel (Changing host)
12.36.56 Join    bimbel [0] (~bmbl@unaffiliated/bmbl)
12.39.41 Quit    bmbl (Ping timeout: 240 seconds)
12.55.33 ***     Saving seen data "./dancer.seen"
13.03.06 Join    benedikt93 [0] (~benedikt9@unaffiliated/benedikt93)
13.11.16 Quit    JdGordon| (Remote host closed the connection)
13.45.07 Quit    [Saint] (Read error: Connection reset by peer)
13.46.00 Join    [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940)
14.07.51 Quit    benedikt93 (Quit: Bye ;))
14.17.18 Quit    liar (Read error: Connection timed out)
14.18.04 Join    liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
14.27.26 Join    lorenzo92 [0] (~chatzilla@host16-105-dynamic.24-79-r.retail.telecomitalia.it)
14.29.08 #       <lorenzo92> kugel: any idea why the benchmark plugin doesn't work? I note only a USING_STORAGE_CALLBACK....what's that?
14.29.28 #       <kugel> lorenzo92: yes :)
14.29.47 #       <kugel> there's an error in my patch
14.29.53 #       <lorenzo92> ah! :)
14.30.02 #       <kugel> it doesnt flush the buffer on exit (because of the #ifdef I added)
14.30.25 #       <kugel> the buffer is quite big so it can lack several hours
14.30.46 #       <lorenzo92> it can lack? and why?
14.31.00 #       <lorenzo92> doesn't it flush when necessary?
14.31.21 #       <kugel> the call to unregister_idle_callback() doesnt happen. that calls flush_buffer() indirecty
14.31.47 Join    remlap [0] (~Patrick@190.28.169.217.in-addr.arpa)
14.31.55 #       <kugel> lorenzo92: it does when it's full, but not on exit (with my patch)
14.31.56 #       <lorenzo92> kugel: this why we don't have a "storage" driver built in rb right?
14.32.12 #       <lorenzo92> kugel: ah! now it's clear why 16 hours were written
14.32.23 #       <kugel> what's needed is to add a #else \n flush_buffer() \n #endif to the second USING_STORAGE_CALLBACK
14.32.25 Join    einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
14.32.59 #       <lorenzo92> okay...added ;)
14.33.05 #       <lorenzo92> I'll test it!
14.33.34 #       <kugel> can you show me the .c file (via pastie), just to make sure :)
14.34.10 #       <lorenzo92> http://pastebin.com/ir9TXgyx
14.34.15 Join    Misan [0] (~Misanthro@adsl-89-217-195-136.adslplus.ch)
14.35.25 #       <kugel> lorenzo92: right. except it needs to be flush_buffer(NULL) (my bad)
14.35.50 #       <lorenzo92> ops :)
14.36.04 #       <lorenzo92> okay
14.37.29 #       <lorenzo92> arggg I don't know why but the safe mode isn't working fine since yesterday...
14.37.48 #       <lorenzo92> I guess that the cable checking thing interferes...
14.38.41 #       <lorenzo92> it unmounts randomly
14.39.00 #       <kugel> bad cable perhaps?
14.39.35 #       <lorenzo92> kugel: well not sure because lebellium told me it happened him too once + OF thing works perfectly....
14.40.55 #       <lorenzo92> later I will do a rom without the cable checking...let's see
14.42.18 #       <lorenzo92> kugel: charging seems working fine, but we should give an eye to the ascodec charging-related registers too to be sure ;)
14.42.56 #       <lorenzo92> btw testing bench
14.43.23 #       <lorenzo92> if it works, I could begin the backlight on test (since I have no time to care R0 tomorrow :D)
14.43.40 #       <lorenzo92> ...with bl on it lasts something like 6-7 hrs
14.46.01 #       <lorenzo92> kugel: okay ;) this time is the right one hehe the bench works
14.48.21 #       <kugel> lorenzo92: okay
14.49.40 #       <lorenzo92> bench started...now I have other things to do...I will send you results asap ;)
14.51.17 #       <lorenzo92> kugel: btw, did you test headphone sense? or discovered something about gpio ioctls?
14.51.37 #       <kugel> no, had no time
14.51.49 #       <lorenzo92> ;)
14.52.23 #       <lorenzo92> kugel: for the bench I leave it on the wps screen.....
14.52.34 #       <kugel> lorenzo92: main menu please
14.52.38 #       <lorenzo92> ok
14.52.50 #       <kugel> the wps screen consumes a lot more cpu
14.52.57 #       <lorenzo92> kugel: yeah guessed that
14.53.11 #       <kugel> so the the backlight has a little less influence
14.53.15 #       <lorenzo92> kugel: BUT when backlight is gone (in normal usage) is the fresh paused?
14.53.32 #       <lorenzo92> *refresh rate
14.53.45 #       <kugel> yes
14.53.59 #       <lorenzo92> indeed, stupid question :D
14.54.05 #       <kugel> I doubt it's already implemented on the ypr0 though
14.54.11 #       <lorenzo92> ah!
14.54.20 #       <kugel> you need HAVE_LCD_ENABLE or HAVE_LCD_SLEEP for that
14.54.44 #       <lorenzo92> uhm I do the lcd sleep in the backlight off function, well that's why we need to revise that
14.55.01 #       <lorenzo92> perhaps it could last longer than 25 hours so :)
14.55.35 ***     Saving seen data "./dancer.seen"
14.56.04 #       <kugel> there's probably some room for improvements left, but usually saving cpu time doesnt yield as much runtime as turning hw units off
14.56.21 #       <kugel> perhaps an extra hour, I doubt more
14.57.28 #       <lorenzo92> yeah indeed nothing serious ;)...and also about arm optimizations. Do you think we can enable them later or what?
14.57.38 #       <kugel> definitely
14.57.46 #       <lorenzo92> keeping in mind that 25 hours are a lot
14.57.48 #       <kugel> later :)
14.57.53 #       <lorenzo92> yeah ;)
15.00.50 #       <amiconn> On colour targets which disable the LCD (and hence stop updating it) when backlight is off the screen it stays in shouldn't have any effect on runtime
15.03.20 #       <marcol07> do somebody know how long does sansa clip plus battery last with rockbox?
15.04.02 #       <[Saint]> The wiki probably does...
15.04.09 Join    lovasoa [0] (~olojkine@78.251.21.108)
15.04.46 Quit    marcol07 (Quit: CGI:IRC (EOF))
15.05.05 Join    marcol07 [0] (~4e628860@www.haxx.se)
15.05.11 #       <[Saint]> I can't remember what the page is called off the top of my head, searching "runtime" in the wiki should find it.
15.05.28 Quit    marcol07 (Client Quit)
15.05.32 Join    marcol07 [0] (~4e628860@www.haxx.se)
15.07.07 #       <amiconn> Actually the wps might even have a slight advantage in this case, because (iirc) the wps also stops redrawing when the lcd is shut down, while other screens don't do that
15.09.42 #       <amiconn> In other cases (targets without lcd shutdown because the lcd stays readable) staying in the main menu probably means slightly longer runtime
15.12.57 #       <lorenzo92> amiconn: thanks for exlpaination ;) but since we draw on the linux framebuffer, disabling also the lcd fresh could help a little too :)
15.16.26 #       <amiconn> Does this port use the linux framebuffer as the rockbox framebuffer, or are there two buffers?
15.21.13 #       <kugel> two of course
15.22.00 #       <amiconn> Why "of course"? This sounds like a possibility for optimisation to me?
15.22.33 #       <kugel> because you might end up with partiallly displayed stuff
15.23.03 #       <kugel> stuff relies on data _not_ beign actually displayed until the lcd_update/_rect calls
15.23.23 Join    jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at)
15.24.31 #       <amiconn> Of course. So you don't have control over the lcd refresh?
15.24.40 #       <kugel> no
15.24.48 #       <amiconn> From lorenzo92's statement I thought you do
15.25.15 #       <kugel> lcd_update() is a memcpy() to the mmap()'ed linux framebuffer
15.26.25 #       <kugel> although I think memcpy to it will cause an immediate update too, however I don't know the details of the linux framebuffer
15.30.14 Join    y4n [0] (y4n@unaffiliated/y4ndexx)
15.33.45 #       <plush> i am trying to debug usb mass storage on an ipod4g
15.33.57 #       <plush> anyone here with some knowledge of that code?
15.34.13 #       <plush> i have done a lot of tracing and debugging, now i need some rockbox insight to make further progress
15.37.00 #       <lorenzo92> kugel: I wanted to say the lcd refresh done by rb ;) We can disable the lcd (already implemented in rb) and I guess there are also some available ioctls for the framebuffer but don't know more than that
15.38.48 Join    mortalis [0] (~mortalis@77.108.98.177)
15.38.58 Join    James_Hunt [0] (2ea48860@gateway/web/freenode/ip.46.164.136.96)
15.41.36 Join    B4gder [0] (~daniel@81-235-141-52-no63.tbcn.telia.com)
15.41.36 Quit    B4gder (Changing host)
15.41.36 Join    B4gder [241] (~daniel@rockbox/developer/bagder)
15.42.13 #       <James_Hunt> Hello and happy holidays to all. I want again remind about full translated Russian language. Went 1 month and I'm worry. http://rockbox.org/tracker/task/12420 I suspect no one approve my translations because I have not Russan name. Want to explain: I'm immigrant and changed name. My native language is Russian.
15.43.38 Quit    liar (Read error: Connection timed out)
15.46.20 #       <y4n> James_Hunt: greets from Saint Petersburg \o
15.49.39 #       <James_Hunt> y4n: :3
15.51.20 #       <gevaerts> James_Hunt: thanks for the information. Yes, that was a concern
15.52.51 Quit    lorenzo92 (Quit: ChatZilla 0.9.88 [Firefox 8.0/20111115183813])
15.53.48 #       <gevaerts> hm, we seem to have a bunch of translations waiting on the tracker...
15.57.41 #       <James_Hunt> gevaerts: oh, that's good. I can vouch for the my translation. --- You mean conflict with other unapproved Russian tarnsltations? I've didn't find other.
15.57.58 #       <gevaerts> No, I mean in general, for other languages
15.58.57 Join    lasser [0] (~f@p57B590A3.dip0.t-ipconnect.de)
15.59.11 Part    lasser
15.59.13 #       <jlbiasini> pamaury: there is going to be again some little improvement on the new new keymaps patch for fuze+ so I guess you can wait this evening before commiting it
15.59.23 #       <pamaury> ok
16.08.06 Join    Topy44 [0] (~Topy44@f049002126.adsl.alicedsl.de)
16.20.51 Quit    James_Hunt (Ping timeout: 258 seconds)
16.26.35 #       <plush> anyone with some rockbox usb code knowledge around?
16.30.16 Quit    B4gder (Quit: It is time to say moo)
16.30.24 #       <funman> plush: just ask your question
16.30.38 #       <funman> people with knowledge of usb code read the irc logs
16.30.43 #       <plush> sure
16.30.58 #       <plush> it's not a simple question, it will require some discussion
16.31.02 #       <plush> but it's worth trying i guess
16.32.41 #       <plush> on an ipod4g, the rockbox usb stack offers mass storage mode
16.32.55 #       <plush> unfortunately, this has been broken for a very long time (it used to work)
16.33.00 #       <plush> my analysis is as follows:
16.33.09 #       <plush> * initially, the mass storage driver is disabled
16.33.39 #       <[Saint]> IPod 4G, the Color/Photo?
16.33.53 #       <[Saint]> USB works fine for me on svn head...
16.34.21 #       <plush> [Saint]: grayscale
16.34.30 #       <plush> i can't tell whether that makes any difference
16.34.35 #       <plush> both are PortalPlayer devices
16.34.46 #       <plush> i actually think it has to do with tue OS you are using
16.34.53 #       <plush> there is a race condition in the rockbox code
16.34.59 #       <plush> and my OS happens to trigger that
16.36.00 #       <plush> with my OS, the following happens:
16.36.21 #       <plush> or let me try it a different way:
16.36.30 #       <[Saint]> I have the Color 4G, and mine works fine...but its fairly non-standard. Its got a 64GB CF card, and Bluetooth & micro-USB :)
16.36.37 #       <plush> after plugging in, rockbox needs to tell whether it's dealing with a dumb charger or with a real host
16.36.56 #       <plush> there are different ways of detecting this
16.37.11 #       <funman> plush: what is your OS?
16.37.16 #       <plush> if you plug your device into a real host, rockbox will take the first hint it can get to recognize the host
16.37.18 #       <plush> funman: freebsd
16.37.31 #       <plush> in my case, that happens to be a request for the device descriptor
16.37.48 #       <funman> you tried on another OS (windows/osx/linux)?
16.37.50 #       <plush> (HEAD usb_core.c lines 563-565)
16.38.03 #       <plush> funman: i have a lot of different boxen. all run freebsd.
16.38.25 #       <funman> get a ubuntu livecd or live usbkey
16.38.43 #       <plush> not possible. ubuntu live usb keys can only be made under windows :(
16.38.49 #       <plush> i always found that incredibly annoying
16.38.50 #       <funman> no
16.38.54 #       <plush> you need to use this unetbootin thing
16.38.58 #       <plush> and that runs under windows only :(
16.39.05 #       <plush> i never understood why they do this either...
16.39.34 #       <funman> https://help.ubuntu.com/community/Installation/FromUSBStick#From_Ubuntu_Linux you can do that from linux / osx and probably unix but that's not the point
16.39.57 #       <plush> only from within windows/osx/linux, none of which i have
16.39.59 #       <funman> just try on linux/osx/windows because rockbox usb code is known to work on them
16.40.07 #       <plush> sure
16.40.12 #       <plush> but the code has a race condition
16.40.15 #       <plush> and freebsd uncovers it
16.40.28 #       <plush> i'm not blaming anyone for not noticing earlier
16.40.33 #       <plush> but it would be nice to fix it
16.40.48 #       <plush> ah, i have an old kubuntu install on one of my boxen :)
16.40.51 #       <funman> i think tis part was added recently
16.41.02 #       <plush> it used to work
16.41.06 #       <pamaury> plush: why do you call that a race condition ?
16.41.10 #       <plush> (i meant usb disk mode)
16.41.18 #       <plush> pamaury: here is why...
16.41.31 #       <plush> ... the code i quoted above enables the usb mass storage driver
16.42.14 #       <plush> but allocate_interfaces_and_endpoints() has run already
16.42.24 #       <plush> and it's this function that allocates endpoints for all enabled drivers
16.42.39 #       <plush> so the mass storage driver is started but the endpoints it needs are missing
16.42.49 #       <plush> hence, its descriptor contains all-zero endpoints
16.42.58 Join    dfkt [0] (dfkt@unaffiliated/dfkt)
16.43.04 #       <plush> that's an invalid descriptor that leads to a non-working usb mass storage device
16.43.34 #       <funman> usb_drv_usb_detect_event() ?
16.44.07 #       <funman> this call was added by jhMikeS in usb detect rework
16.44.15 #       <plush> funman: yes, usb_drv_usb_detect_event() comes after allocate_interfaces_and_endpoints() - that's the problem
16.44.50 #       <plush> ok, i tried it with linux now
16.44.54 #       <plush> as expected, everything worked
16.45.01 #       <plush> linux does not trigger the race
16.45.02 #       <pamaury> funman: that a call to the underlyin usb driver which forwards to usb_core again, that's was present before the rework but jhMikeS might have modified it, although I don't see what is freebsd specific in the reasoning
16.45.32 #       <funman> plush: you want to talk with jhMikeS and perhaps open a FS# bug
16.45.51 #       <plush> pamaury: the freebsd-specific thing is the very early request for the device descriptor
16.45.59 #       <funman> pamaury: i dont see it before r29068
16.46.12 #       <plush> this usb_drv_usb_detect_event() call happens before rockbox is actually prepared to handle it
16.46.28 #       <plush> i tried to compile versions < 30000 to see when exactly it broke... but configure failed with perl errors
16.46.35 #       <plush> i can't go back that far in the code :(
16.46.47 #       <pamaury> funman: it must have changed somehow but we already supported detect by core I'm pretty sure
16.47.48 #       <funman> plush: try before the rev i gave
16.47.55 #       <funman> see the log at that time perhaps
16.48.00 #       <funman> around*
16.48.10 #       <plush> funman: i did try. it just won't compile :(
16.48.14 #       <plush> or rather, won't even configure
16.49.12 #       <gevaerts> hm
16.49.28 #       <gevaerts> This sounds like what TheSeven has been talking about recently
16.49.29 #       <funman> plush: hm what is the problem exactly? i don't know perl but we can surely figure something
16.49.44 #       <plush> ok, downgrading to 29000 now
16.50.01 #       <plush> it was something about Switch.pm i think
16.50.25 #       <plush> "Can't locate Switch.pm in @INC"
16.50.33 #       <plush> it's some deprecated package that no longer exists
16.52.19 #       <plush> my bad
16.52.27 #       <plush> CGI/Switch.pm is old and unsupported
16.52.37 #       <plush> plain Switch.pm i simply didn't have installed
16.52.39 #       <plush> installing now
16.53.17 #       * gevaerts looks at the usb code
16.53.58 #       <plush> gevaerts: i can go into more detail about what calls what in what order
16.54.06 #       <plush> i have been tracing through this for the past 5 hours
16.55.37 ***     Saving seen data "./dancer.seen"
16.57.15 #       <plush> oh by the way, is it possible to compile the core firmware without all games and other plug-ins somehow?
16.57.23 #       <pamaury> plush: make bin
16.57.27 #       <plush> handy
16.57.32 #       <gevaerts> The flow is a bit messy unfortunately
16.57.35 #       <pamaury> plush: can you go into a bit more details ? That would avoid running the code, perhaps we can see how to fix that
16.57.57 #       <plush> pamaury: i will, in a moment though... my code is at rev 29000, not HEAD at the moment :)
16.58.23 Join    James [0] (2ea48860@gateway/web/freenode/ip.46.164.136.96)
16.58.36 Quit    James (Client Quit)
16.59.11 #       <plush> booting firmware 29000 now
16.59.22 #       <plush> yep, usb mass storage works
16.59.26 #       <plush> (under freebsd)
16.59.42 #       <plush> shout i try 29068?
17.00.21 #       <gevaerts> plush: "Enable for SA9200 only at this time" says no I think :)
17.00.37 #       <plush> gevaerts: yes, i just looked at the commit message :)
17.03.21 #       <plush> how about 29156?
17.03.29 #       <plush> would that apply to an ipod4g?
17.03.46 #       <funman> 29068 is a commit frm jethead for me
17.04.03 #       <gevaerts> The way I read things, PP (and thus ipod4g) only got converted in r30546
17.04.26 #       <gevaerts> I could be wrong though
17.05.05 #       <gevaerts> Still, I'm not sure if we care when exactly this happened. Changing the detection mode *was* the right thing to do, we just have to make the new one work right
17.05.21 #       <pamaury> I will try to run it on my device, I don't remember the expected flow, I need to remember
17.05.47 #       * gevaerts didn't remember the expected flow back when he was implementing it the first time :)
17.06.25 #       <plush> gevaerts: yes, 30546 is what i suspect as well
17.06.46 #       <plush> i won't be trying that one for the moment. i will return to HEAD instead and give you more details of what's failing where
17.07.25 #       <pamaury> r30546 cannot be the only culprit, arc driver works very well, so it's related on the detection change
17.07.39 #       <plush> yes, absolutely
17.07.57 #       <plush> the detection kicks in at a moment when the rest of the driver isn't expecting it
17.08.12 #       <plush> i hope i can describe it well enough to make it obvious:
17.08.21 #       <plush> usb_thread() from usb.c is in charge
17.08.28 #       <gevaerts> Am I right in suspecting that allocate_interfaces_and_endpoints() and friends run more than once?
17.08.37 #       <plush> gevaerts: no, only once
17.08.39 #       <plush> but too early
17.08.48 #       <plush> this function runs *before* any drivers are enabled
17.08.56 #       <plush> hence, it fails to allocate any endpoints at all
17.09.33 #       <gevaerts> Oh, I see...
17.09.44 #       <plush> gevaerts: look at usb_core_control_request_handler() in usb_core.c
17.09.55 #       <plush> a control request comes in
17.10.02 #       <gevaerts> Basically usb_configure_drivers() (in usb.c) should run on plug in, not on detect
17.10.06 #       <gevaerts> I think
17.10.06 #       <plush> allocate_interfaces_and_endpoints() is called in line 839
17.10.23 #       <plush> the driver gets enabled by the call in line 844
17.10.27 #       <plush> and so the order ends up wrong
17.10.55 #       * gevaerts nods
17.11.05 #       <plush> the thing with usb_configure_drivers() is that it does different things for USB_POWERED and USB_INSERTED
17.11.16 #       <plush> if you want to preserve that, you need to wait until you know whether you have a host
17.11.28 #       <plush> so it's not trivial to fix while preserving this functionalitx
17.11.30 #       <gevaerts> Well, hm, not sure actually. The device descriptor doesn't need enabled drivers yet
17.11.31 #       <plush> *functionality
17.11.37 #       <plush> it does
17.11.51 #       <plush> because the device descriptor refers to the drivers
17.11.56 #       <pamaury> the code works on the fuze+ which has the same driver, so it's not so trivial
17.12.04 #       <plush> e.g. the serial number contains a bitmask of enabled drivers
17.12.16 #       <plush> the code works on ipod4g as well
17.12.33 #       <plush> it's just that allocate_interfaces_and_endpoints() can be triggered earlier than it is e.g. by linux/win
17.13.08 #       <gevaerts> I don't think changing the serial number should break enumeration though
17.13.29 #       <gevaerts> So I still don't see the entire picture
17.13.57 #       <plush> gevaerts: it probably won't break anything in an awful way but it will take away something that exists now
17.14.08 #       <plush> right now, if you look at the serial number, you can see what devices are enabled
17.14.26 #       <gevaerts> Oh, sure, it's a bug all right. 
17.14.29 #       <plush> which means that before rockbox can send you a device descriptor, it must figure out which devices to enable
17.14.33 Join    dreamlayers [0] (~bgjenero@bas4-windsor12-1279287645.dsl.bell.ca)
17.14.33 Quit    dreamlayers (Changing host)
17.14.33 Join    dreamlayers [0] (~bgjenero@rockbox/developer/dreamlayers)
17.15.01 #       <plush> if you want the information to remain in there, devices must be enabled before a descriptor is sent
17.15.03 #       <gevaerts> The serial number variation was added because some systems don't handle same serial number and different configuration well
17.15.15 #       <plush> i was thinking the following may work:
17.15.20 #       <gevaerts> I just don't see how this explains what you're seeing
17.15.36 #       <plush> ah, ok, i will explain further
17.15.46 #       <plush> forget the serial number. this one is unrelated to the bug i am seeing
17.15.51 Join    kevku [0] (x@2001:470:28:773::)
17.16.04 #       <plush> i was just giving reasons for why a trivial fix may not be the right thing
17.16.20 #       <plush> what i am seeing is entirely due to the detection code running things in the wrong order
17.16.39 #       <plush> allocate_interfaces_and_endpoints() should run only after the list of required drivers is known, never before
17.16.44 #       <plush> if run before, it can't do its job
17.17.34 #       <plush> so i think a fix could be this: run a version of allocate_interfaces_and_endpoints() on plug-in that enables whatever is needed for charging; run a second version when a host is detected that adds any additional endpoints needed by actual usb drivers
17.18.08 #       <plush> in both cases, allocate_interfaces_and_endpoints() could be called from usb_configure_drivers()
17.18.12 #       <pamaury> it's not that simple, the allocate_interfaces_and_endpoints is called several times, because the normal usb workflow is: reset, get desc (8 bytes), reset, get full desc
17.18.21 #       <gevaerts> The way I read things allocate_interfaces_and_endpoints() is called when a control request comes in and we're not in ADDRESSED yet
17.18.41 #       <plush> my logf traces show this order of commands received:
17.18.48 #       <plush> usb_core: SET_ADR 6
17.18.54 #       <plush> usb_core: GET_DESC 1
17.18.58 #       <plush> usb_core: GET_DESC 3
17.19.09 #       <gevaerts> It does a SET_ADDRESS as the very first call?
17.19.09 #       <plush> and it's the second call that triggers allocate_interfaces_and_endpoints()
17.19.14 #       <plush> yes, it does
17.19.22 #       <pamaury> that's not a very standard usb host
17.19.28 #       <gevaerts> ok, right, that's unusual
17.19.32 #       <plush> this is the freebsd usb stack
17.19.37 #       <gevaerts> Still allowed though as far as I can tell
17.20.08 #       <gevaerts> But yes, then I see what's going on
17.20.10 #       <plush> this is why i am seeing the bug and others are not... the freebsd usb stack does its own thing :)
17.20.15 #       <pamaury> what is unexpected is that it never resets
17.20.24 #       <pamaury> that's why it doesn't work
17.20.31 #       <plush> it may reset. i may not have added the right logf()
17.20.45 #       <pamaury> no, it would SET_ADR again then
17.21.20 #       <plush> ok, so then i guess it does not reset
17.21.30 #       <plush> i asked about the whole problem on freebsd's usb mailing list first
17.21.36 #       <plush> the usb stack maintainer is very responsive
17.21.42 #       <gevaerts> pamaury: do you see a rason (apart from the work involved of course) not to call allocate_interfaces_and_endpoints() on plugin (i.e. electrical connection detected)?
17.21.49 #       <plush> if the freebsd stack is doing something invalid, i am sure he'll be happy to fix it
17.22.06 #       <plush> but if the behavior is allowed by the standard, the bug is in rockbox
17.22.11 #       <gevaerts> I'm pretty sure it is valid. It's just not what the others are doing
17.23.09 #       <plush> yeah, i fully expected something like that
17.23.21 #       <plush> there must be a reason i am seeing this and others are not
17.23.40 #       <plush> gevaerts: as for your idea to run allocate_interfaces_and_endpoints() early - how will that help if drivers are not enabled yet()
17.23.46 #       <plush> s/yet()/yet?/
17.23.55 #       <plush> without drivers enabled, allocate_interfaces_and_endpoints() is a no-op
17.23.57 #       <pamaury> the expected workflow is the following: configure_driver(USB_INSERTED), GET_DESC, configure_driver(USB_HOSTED), reset, GET_DESC
17.24.12 #       <gevaerts> Oh, wait. I was confused. The driver enable function has to be called, not allocate_interfaces_and_endpoints()...
17.24.32 #       <dreamlayers> In Windows and Linux, I have problems if the hard drive on my 5G iPod is spun up when connecting USB.  Is that related?
17.25.13 #       <plush> gevaerts: yes, *that* one i agree with
17.25.36 #       <plush> if you enable the mass storage driver early, allocate_interfaces_and_endpoints() will do the right thing when it's called later
17.25.56 #       <plush> the only thing is that if you just plugged into a charger, you now needlessly enabled the mass storage driver
17.26.08 #       <plush> so the question is whether that may have negative consequences
17.26.38 #       <gevaerts> You don't, really. It just sets a flag
17.26.54 #       <gevaerts> That flag is rather important, but on its own it doesn't do much
17.27.14 #       <plush> yep, i saw that the function call does nothing but set a flag
17.27.32 #       <plush> if the flag on its own doesn't do anything much, maybe enabling it is the right thing to do
17.29.42 #       * pamaury would advise extra care because of the multitude of usb variants that we have
17.30.31 #       * jhMikeS 's been lurking. the driver enabling could be synchronous with the setup packet event
17.31.10 #       <plush> jhMikeS: but then a fresh run of allocate_interfaces_and_endpoints() would have to be forced right after enabling the driver
17.31.26 #       <plush> without a reset, it would never be run after enabling the driver otherwise
17.31.44 #       * gevaerts test-compiles
17.31.49 #       <plush> gevaerts: so am i
17.32.02 #       <plush> i added a usb_core_enable_driver(USB_DRIVER_MASS_STORAGE, true); right after usb_stack_enable(true); on plug-in
17.32.24 #       <gevaerts> http://paste.debian.net/150552/
17.32.49 #       <pamaury> a first more correct step would be to call usb_drv_usb_detect on any setup packet the first time, even before doing anything else, and propagate changes in the stack synchronously, so that everything is ready when allocating the endpoints but that will require significant work I'm afraid
17.32.54 #       <jhMikeS> plush: I still might not be 100% clear on the happenings.
17.34.11 #       <gevaerts> jhMikeS: I'm pretty sure we currently rely on SET_ADDRESS not being the first call, which mean allocate_interfaces_and_endpoints() is run a second time *after* everything has been set up, so the right thing ends up happening
17.35.38 Join    MethoS- [0] (~clemens@134.102.106.250)
17.35.51 #       <gevaerts> And freebsd apparently breaks that assumption
17.36.26 #       <plush> gevaerts: rockbox is actually the first one of two usb mass storage devices that fail for me under bsd
17.36.30 #       <plush> the second one is closed source
17.36.35 #       <gevaerts> I'm reasonably sure that my patch doesn't break things
17.36.36 #       <plush> *that* one will be fun to work around :(
17.37.06 #       <pamaury> what was the initial reason of making configure_drivers depend on the usb status ?
17.37.43 #       <gevaerts> pamaury: it doesn't really have to depend on the usb status. It just has to be run at connect time because of the button check
17.38.30 #       <jhMikeS> gevaerts: so it's a problem of host being detected later rather than sooner, after actual communication has taken place from a host, but not via the descriptor?
17.38.53 #       <jhMikeS> * to get the descriptor
17.39.04 #       <gevaerts> basically, yes
17.39.17 #       <pamaury> I don't agree, it's because our stack relies on a reset
17.40.11 #       <gevaerts> Another fix (but a horrible one) could be to change usb_core_control_request_handler() to keep a counter so it always calls allocate_interfaces_and_endpoints() and friends at least twice
17.40.16 #       <gevaerts> pamaury: do we?
17.40.48 #       <jhMikeS> posting several USB_HOSTED events in a row if any sort of host-like activity takes place shouldn't bother it, but if there are other assumptions that could break things...
17.41.06 #       <pamaury> if you look at the code, usb_status is DEFAULT initially, on the very first setup packet, it allocates endpoints, then detect hosts takes place, that's complete independent of the content of the first packet at this point
17.41.40 #       <plush> gevaerts: your patch doesn't work for me
17.41.42 #       <plush> no idea why
17.41.48 #       <plush> my simpler hack *did* work
17.41.55 #       * jhMikeS did ask gevaerts before if the setup packet request was to be the first packet and he affirmed that :)
17.41.59 #       <plush> with your patch, when i plug in the usb cable, nothing happens :(
17.42.03 #       <dreamlayers> I can't get a USB connection after applying http://paste.debian.net/150552/ .  There is a bit of disk activity, but the USB screen doesn't appear.
17.42.18 #       <pamaury> hmm wait, stricly speaking that's not true, it relies on the fact that the host will read the descriptor twice perhaps
17.42.46 #       <gevaerts> jhMikeS: the setup packet is first, it just doesn't have to be GET_DESCRIPTOR
17.42.54 #       <plush> pamaury: i think it depends on detecting the host before GET_DESCRIPTOR happens
17.44.00 #       <plush> actually, no - it depends on detecting that a host is present before allocate_interfaces_and_endpoints() is run
17.44.03 #       <pamaury> plush: that's impossible, we detect the host on the first packet, allocate_interfaces_and_endpoints needs to be called twice for the stack to work, anyway
17.44.21 #       <plush> making yourself known as a host, then *resetting* works - it causes allocate_interfaces_and_endpoints() to run with existing knowledge of a host
17.44.42 #       <gevaerts> plush: your change was basically in the same place as my new usb_configure_drivers() call, right?
17.44.44 #       <plush> with my hack, i think allocate_interfaces_and_endpoints() runs only once
17.44.53 #       <plush> gevaerts: yes, hold on, i will make a patch
17.45.51 #       <plush> gevaerts: http://pastebin.ws/4jxj4x
17.45.55 #       <plush> that's all i changed
17.46.09 #       <plush> it's a hack - but it makes the device work for me
17.47.06 #       <gevaerts> plush: I'm not sure charge-only will still work for you then :)
17.47.18 #       <plush> i don't have any chargers around :(
17.47.25 #       <plush> i'd try otherwise, of couse
17.47.38 #       <plush> and yes, i am sure it's a nasty hack
17.47.44 #       <gevaerts> I mean by holding a button
17.47.45 #       <plush> i don't understand why your patch doesn't work
17.47.51 #       <plush> ah, like that
17.47.59 #       <plush> yeah, that's probably broken, true
17.48.04 #       <funman> i need to send plush a amsv2 device
17.48.15 #       <gevaerts> hmm
17.48.16 #       <funman> and tell him that HID works everywhere except on freebsd ;)
17.48.49 #       <gevaerts> plush: can you replace the call to usb_exclusive_storage() in my patch to just checking the exclusive_storage_access variable?
17.48.57 #       <plush> gevaerts: oddly enough... charge-only works?!?
17.49.06 #       <plush> i just tried. holding a button does the right things
17.49.29 #       <plush> gevaerts: will do. but dinner is ready. my girlfriend won't let me continue hacking without a 15 minute food break
17.49.30 #       <plush> brb
17.49.36 Quit    dreamlayers (Quit: Leaving)
17.49.50 #       <gevaerts> So http://paste.debian.net/150558/
17.50.02 #       * gevaerts will also try it
17.57.39 Quit    bluefoxx (Quit: brb rebooting)
18.00.58 #       <jhMikeS> that will cause a SYS_USB_DISCONNECTED broadcast when none should have occurred
18.01.42 #       <gevaerts> hmm
18.02.55 #       <gevaerts> jhMikeS: maybe test for USB_INSERTED there as well, i.e. what the usb_exclusive_storage() function does?
18.03.33 #       <gevaerts> for the broadcast anyway. We obviously should reset the flag
18.03.55 #       * plush is back
18.04.34 #       <jhMikeS> gevaerts: test where?
18.05.14 #       <gevaerts> jhMikeS: in usb_release_exclusive_storage()
18.08.12 Join    remlap1 [0] (~Patrick@190.28.169.217.in-addr.arpa)
18.08.17 #       <jhMikeS> I thought about just detecting any communication whatsoever as a host, ie. tranfer completion since it reaches that code through there
18.08.22 Quit    remlap1 (Client Quit)
18.09.41 Quit    remlap (Ping timeout: 240 seconds)
18.11.10 #       <gevaerts> jhMikeS: What exactly would you do then?
18.12.02 #       <gevaerts> Apart from the SYS_USB_DISCONNECTED thing the second version of my patch seems to work fine
18.13.56 #       <jhMikeS> set up the drivers in USB_TRANSFER_COMPLETION, just before telling the driver? maybe even simplify as a result
18.14.39 #       <gevaerts> Ah, yes. That could work
18.14.59 #       <plush> jhMikeS: i am trying to do just that
18.15.11 #       <plush> thing is, i can't find a flag to test for so that it's not done twice
18.15.12 Quit    bimbel (Quit: Verlassend)
18.15.21 #       <plush> maybe a new int flag will have to be added
18.15.27 #       <jhMikeS> some finesse is needed
18.15.35 #       <plush> i was going to add it to the top of usb_core_control_request_handler()
18.15.44 #       <jhMikeS> but, it could get rid of the need for the event handler and message too
18.16.10 #       <gevaerts> plush: usb.c seems cleaner, because it actually knows which drivers are needed
18.18.41 #       <plush> i have no idea where the boundary between usb.c and usb_core.c should be. the two seem to call each other a lot
18.19.07 #       <gevaerts> True. We'd like to clean this up :)
18.20.29 #       <plush> i wrote the freebsd driver for wacom tablets
18.20.37 #       <plush> the linux driver has two files, similar to usb.c and usb_core.c
18.20.46 #       <plush> i never understood the distinction between their two files
18.20.50 #       <plush> so my driver has just one :)
18.22.37 #       <gevaerts> Basically usb.c handles connection state. It's also used for devices that have a hardware USB-ATA bridge. usb_core.c handles the actual usb protocol
18.22.39 Join    Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com)
18.22.56 #       <gevaerts> It (ab)uses the usb.c thread because it seems silly to add another thread
18.23.12 #       <plush> are there any devices without USB_DETECT_BY_CORE?
18.23.21 Join    Buschel [0] (~chatzilla@p54A3B788.dip.t-dialin.net)
18.24.18 #       <Torne> there were.. did we fix them all? :)
18.24.31 Quit    lebellium (Quit: ChatZilla 0.9.88 [Firefox 10.0/20111221135037])
18.25.06 #       <gevaerts> Not yet
18.26.15 #       <gevaerts> USB_DETECT_BY_CORE is used by USBOTG_ARC, USBOTG_AS3525, USBOTG_AS3525v2, and USBOTG_RK27XX. That leaves USBOTG_ISP1362 and USBOTG_ISP1583 (which I think aren't actually implemented), USBOTG_JZ4740, USBOTG_M5636, USBOTG_M66591 and USBOTG_S3C6400X
18.27.29 #       <gevaerts> i.e. nano2g, classic, mr500, onda, zvm
18.32.20 Join    lorenzo92 [0] (~chatzilla@host16-108-dynamic.245-95-r.retail.telecomitalia.it)
18.32.32 Quit    efyx (Remote host closed the connection)
18.32.51 #       <jhMikeS> it might just evaporate anyway :)
18.33.28 #       <lorenzo92> kugel: was studying the si470x module...it's very interesting and I found 2 interesting gpio pins for the radio. But there is something curious: an internal struct that *could* be used directly in a ioctl call!
18.33.49 #       <lorenzo92> kugel: directly, I mean with the same parameters sizes etc
18.34.51 Join    remlap [0] (~Patrick@190.28.169.217.in-addr.arpa)
18.35.04 Quit    Buschel (Quit: ChatZilla 0.9.87 [Firefox 9.0.1/20111220165912])
18.43.16 #       <gevaerts> Torne: are there status updates for git, or are we just waiting for everyone involved to be available at the same time?
18.43.19 Quit    [Saint] (Ping timeout: 268 seconds)
18.43.53 #       <Torne> uhm, yeah. nothing has happened; i've been at my parents for christmas and/or drunk/high for the holidays
18.44.24 #       <Torne> we'll sort stuff real soon :)
18.48.43 Join    Jiri [0] (~5c3ee015@www.haxx.se)
18.49.08 #       <jlbiasini> Hello all:
18.49.34 Quit    Jiri (Client Quit)
18.50.02 #       <jlbiasini> what should I do for stuff that are not implemented for fuze+ yet? Should I let and clean section for future implementation or cut those section out?
18.50.18 #       <jlbiasini> I meant in the manual
18.50.23 #       <jlbiasini> :)
18.50.48 #       <jlbiasini> concerned recording, radio...
18.54.02 #       <funman> jlbiasini: is there something special about recording and radio with the fuze+ ?
18.54.16 #       <funman> i'd have thought those sections are shared across models when recording/fm features are defined
18.54.59 #       <jlbiasini> funman: yes there is something very special: not implemented yet :D
18.55.25 #       <jlbiasini> I would be in the future I guess but for the moment that doesn't work
18.55.30 #       <jhMikeS> disgustingly crude but worth checking: http://jhmikes.cleansoap.org/usbstack-early-driver-setup.patch
18.55.41 ***     Saving seen data "./dancer.seen"
18.56.09 #       <curtism> you know rockbox's last.fm scrobbler? what software can i use to upload that information to last.fm?
18.57.16 #       <jlbiasini> So am I suppose to mention it in the manual? Or cut out section or just do as if it was working?
18.57.29 #       <funman> jlbiasini: that's not special. just don't declare teh features
18.59.03 #       <jlbiasini> funman: ok but this means changing export/config/sansafuzeplus.h ? This is not done in the manual I think, is it,
18.59.06 #       <funman> jlbiasini: i think the manual features are generated from config/sansafuzeplus.h so if HAVE_TUNER is not defined, the radio sections won't appear. did you try to build the manual already?
18.59.25 #       <jlbiasini> yes
18.59.30 #       <funman> curtism: it should be explained in the wiki and the manual
18.59.37 #       <jlbiasini> right I think that it is so
19.00.00 #       <curtism> funman: "RTFM"? thanks
19.00.01 #       <funman> jlbiasini: right fix would be to undef HAVE_RECORDING and CONFIG_TUNER from config
19.00.10 #       <funman> curtism: yeah :)
19.00.15 #       <jlbiasini> ok thx
19.00.28 #       <funman> curtism: i think there's multiple software you can use btw
19.06.02 Quit    marcol07 (Quit: CGI:IRC (Ping timeout))
19.08.03 #       <kugel> lorenzo92: what do yyou mean?
19.08.18 #       <kugel> sure the kernel module uses the same struct as the ioctl() caller
19.08.27 Join    Strife89 [0] (~Strife89@207.144.201.128)
19.08.29 #       <funman> kugel: ping
19.08.36 #       <kugel> funman: pong
19.08.43 #       <funman> kugel: can you take a look at FS#12475 ?
19.08.44 #       <fs-bluebot> http://www.rockbox.org/tracker/task/12475 3Crash while playing audio (bugs, unconfirmed)
19.09.02 #       <lorenzo92> kugel: I was disassembling the radio module, interesting, but difficult to understand how it works. The only thing I know is that there is a 54 byte sized internal struct for various parameters
19.11.41 #       <lorenzo92> kugel: BUT it should be quite easy (maybe for you) to rewrite a similar module with just register read/write.....
19.12.00 Quit    Keripo (Quit: Leaving.)
19.12.03 #       <lorenzo92> initialization code seems to be pretty easy
19.12.26 #       <kugel> it would be nice if we can do it without extra kernel modules
19.14.16 #       <lorenzo92> indeed
19.15.50 Quit    Strife89 (Ping timeout: 248 seconds)
19.17.58 Quit    ze (Ping timeout: 248 seconds)
19.18.31 #       <jlbiasini> pamaury: did you see that there is a #define HAVE_TUNER_PWR_CTRL in export/config?
19.19.04 Join    dreamlayers [0] (~bgjenero@rockbox/developer/dreamlayers)
19.19.23 #       <jlbiasini> could it be the reason it doesn't work on fuze+ (it's not enable on the fuze+
19.19.27 #       <jlbiasini> )
19.21.42 #       <pamaury> jlbiasini: nice catch, can you #define it and see ?
19.23.06 Join    ze [0] (ze@ze.yi.org)
19.24.31 #       <lorenzo92> kugel: the strange thing is that I cannot find a copy_from_user call in the ioctl section uhm uhm
19.25.32 #       <pamaury> jlbiasini: otherwise I'll try later
19.25.52 #       <kugel> lorenzo92: oh hmm
19.28.28 Join    Strife89 [0] (~Strife89@207.144.201.128)
19.29.46 #       <jlbiasini> pamaury: yeah I will try
19.29.50 #       <lorenzo92> kugel: ah btw, I know why (probably) we have more than a simple integer as ioctl parameter for gpio: in the iomux call, there is a second parameter that sets some options (see kernel's source)
19.31.44 #       <kugel> lorenzo92: intersting
19.32.34 #       <funman> kugel: or is there a way to debug malloc failures?
19.33.55 Join    JesusFreak316 [0] (~JesusFrea@pool-173-65-88-178.tampfl.fios.verizon.net)
19.36.05 Quit    bluebrother (Disconnected by services)
19.36.06 Join    bluebrother^ [0] (~dom@rockbox/developer/bluebrother)
19.36.09 #       <kugel> funman: what do you mean by "malloc failure"?
19.38.28 Quit    fs-bluebot (Ping timeout: 240 seconds)
19.39.09 Nick    eintopf|28c3 is now known as eintopf (~eintopf@zzz.strace.org)
19.39.20 Quit    mortalis (Quit: KVIrc 4.1.1 Equilibrium http://www.kvirc.net/)
19.40.02 Join    fs-bluebot [0] (~fs-bluebo@g226069126.adsl.alicedsl.de)
19.41.00 #       <funman> kugel: FS#12475 ...
19.41.00 #       <fs-bluebot> http://www.rockbox.org/tracker/task/12475 3Crash while playing audio (bugs, unconfirmed)
19.41.47 #       <kugel> funman: I saw that
19.42.09 #       <funman> i think it's a malloc problem
19.42.16 #       <funman> jdgordon does too
19.42.22 #       <kugel> doesnt tell me what you mean by "malloc failure"
19.42.51 #       <kugel> besides we still have no "malloc", even with buflib. and I prefer to not call it malloc
19.44.13 #       <funman> i've seen the string "malloc" on panic/data abort screen on clipv1
19.44.22 #       <funman> when testing usb
19.45.04 #       <kugel> okay, right, that's a very old panicf in playback.c
19.45.10 Join    liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
19.45.20 #       <kugel> it said malloc even before buflib
19.45.33 #       <funman> what i called 'malloc failure' was allocation of a buffer which would be too big where skins code would write
19.45.41 #       <funman> and overwrite other memory
19.45.55 #       <funman> well i just want a hand to lead me in the right direction to debug this
19.47.27 #       <kugel> funman: you're saying the skin is too big and makes allocating the audio buffer go wrong?
19.48.46 Join    JesusFreak316_ [0] (~JesusFrea@pool-173-65-65-136.tampfl.fios.verizon.net)
19.49.08 Quit    JesusFreak316 (Ping timeout: 240 seconds)
19.49.37 #       <funman> i'm not saying i'm making random guesses but yeah
19.50.51 #       <kugel> okay
19.51.03 #       <kugel> I thought I prevented that in the shrink_callback
19.51.23 #       <kugel> perhaps the skin is loaded before the audio buffer is allocated for the first time?
19.51.37 #       <kugel> funman: is this reproducable in the sim?
19.53.37 #       <jlbiasini> pamaury: no change
19.53.43 #       <funman> kugel: i didnt try
19.53.54 #       <jlbiasini> I will try with updated bootloaderthen
19.53.57 #       <funman> the sim doens't have usb plug, does it?
19.54.50 #       <pamaury> jlbiasini: it won't change anything, I'll see that later, thanks
19.55.01 #       <kugel> funman: press the u key
19.55.58 #       <funman> ok
20.02.08 Quit    Topy44 (Ping timeout: 240 seconds)
20.03.13 Join    Topy44 [0] (~Topy44@f049002126.adsl.alicedsl.de)
20.04.03 #       <jlbiasini> pamaury: anyway sansa c200v2 seens to use the same define TUNER_CONFIG device S4700 and explicitly comment out HAVE_TUNER_PWR_CTRL
20.04.27 #       <pamaury> strangely enough, I seem to remember that tuner_power is actually called, so that's strange
20.05.59 Quit    fyrestorm (Read error: Connection reset by peer)
20.06.10 Join    fyrestorm [0] (~nnscript@cpe-24-90-84-81.nyc.res.rr.com)
20.08.14 Join    saratoga [0] (9803ec71@gateway/web/freenode/ip.152.3.236.113)
20.08.38 #       <saratoga> does anyone know more about the problems with the m200v4?
20.08.39 Quit    pamaury (*.net *.split)
20.08.40 Quit    ender` (*.net *.split)
20.08.40 Quit    Galois (*.net *.split)
20.08.40 Quit    bieber (*.net *.split)
20.08.40 Quit    bzed (*.net *.split)
20.08.40 Quit    Rondom (*.net *.split)
20.08.40 Quit    kkit (*.net *.split)
20.08.40 Quit    pjm0616 (*.net *.split)
20.08.40 Quit    ack (*.net *.split)
20.16.43 Quit    dreamlayers (*.net *.split)
20.16.43 Quit    Xerion (*.net *.split)
20.16.43 Quit    amithkk (*.net *.split)
20.16.43 Quit    jae (*.net *.split)
20.16.43 Quit    Utchybann (*.net *.split)
20.19.19 Quit    y4n (*.net *.split)
20.22.37 Quit    Sundiver (Ping timeout: 240 seconds)
20.23.13 Quit    Misan (*.net *.split)
20.23.13 Quit    plush (*.net *.split)
20.23.13 Quit    parafin (*.net *.split)
20.23.13 Quit    MethoS- (*.net *.split)
20.23.13 Quit    factor (*.net *.split)
20.23.13 Quit    pixelma (*.net *.split)
20.23.13 Quit    amiconn (*.net *.split)
20.23.14 Quit    mikroflops (*.net *.split)
20.23.14 Quit    zu_ (*.net *.split)
20.23.14 Quit    yosafbridge (*.net *.split)
20.23.14 Quit    trompette (*.net *.split)
20.23.14 Quit    knittl (*.net *.split)
20.23.14 Quit    liar (*.net *.split)
20.23.15 Quit    adnap (*.net *.split)
20.23.15 Quit    Torne (*.net *.split)
20.23.15 Quit    markun (*.net *.split)
20.23.15 Quit    beta2k (*.net *.split)
20.23.15 Quit    guymann (*.net *.split)
20.23.15 Quit    tmzt (*.net *.split)
20.23.15 Quit    Bawitdaba (*.net *.split)
20.23.15 Quit    alexbobp (*.net *.split)
20.23.15 Quit    linuxguy3 (*.net *.split)
20.23.15 Quit    dionoea (*.net *.split)
20.23.15 Quit    dfkt (*.net *.split)
20.23.15 Quit    TheSeven (*.net *.split)
20.23.15 Quit    dv_ (*.net *.split)
20.23.15 Quit    tah (*.net *.split)
20.23.15 Quit    froggyman (*.net *.split)
20.23.15 Quit    Bagder (*.net *.split)
20.23.15 Quit    preglow (*.net *.split)
20.23.15 Quit    lmh (*.net *.split)
20.23.15 Quit    topik (*.net *.split)
20.23.16 Quit    nsx (*.net *.split)
20.23.16 Quit    ze (*.net *.split)
20.23.16 Quit    n1s (*.net *.split)
20.23.16 Quit    nosa-j (*.net *.split)
20.23.17 Quit    Zambezi (*.net *.split)
20.23.17 Quit    rasher (*.net *.split)
20.23.17 Quit    GodEater (*.net *.split)
20.23.17 Quit    nomada (*.net *.split)
20.23.17 Quit    ruskie (*.net *.split)
20.23.17 Quit    desowin (*.net *.split)
20.23.17 Quit    gevaerts (*.net *.split)
20.23.17 Quit    simabeis (*.net *.split)
20.23.17 Quit    ukleinek (*.net *.split)
20.23.17 Quit    kevku (*.net *.split)
20.23.17 Quit    Rob2223 (*.net *.split)
20.23.17 Quit    user890104 (*.net *.split)
20.23.17 Quit    kugel (*.net *.split)
20.23.17 Quit    soap (*.net *.split)
20.23.17 Quit    TBCOOL (*.net *.split)
20.23.17 Quit    ps-auxw (*.net *.split)
20.23.18 Quit    funman (*.net *.split)
20.23.18 Quit    qnm (*.net *.split)
20.23.18 Quit    jordan`` (*.net *.split)
20.23.18 Quit    Misanthropos (*.net *.split)
20.23.18 Quit    tmr (*.net *.split)
20.23.18 Quit    Farthen (*.net *.split)
20.23.18 Quit    rjg (*.net *.split)
20.23.18 Quit    mystica555 (*.net *.split)
20.23.18 Quit    Elfish (*.net *.split)
20.23.18 Quit    ranmachan (*.net *.split)
20.23.18 Quit    Naked (*.net *.split)
20.23.18 Quit    ved (*.net *.split)
20.23.18 Quit    freqmod (*.net *.split)
20.23.18 Quit    Topy44 (*.net *.split)
20.23.18 Quit    JesusFreak316_ (*.net *.split)
20.23.18 Quit    fs-bluebot (*.net *.split)
20.23.18 Quit    Strife89 (*.net *.split)
20.23.18 Quit    remlap (*.net *.split)
20.23.18 Quit    lovasoa (*.net *.split)
20.23.18 Quit    einhirn (*.net *.split)
20.23.18 Quit    bertrik (*.net *.split)
20.23.19 Quit    mystica555_ (*.net *.split)
20.23.19 Quit    sinthetek (*.net *.split)
20.23.19 Quit    curtism (*.net *.split)
20.23.19 Quit    advcomp2019 (*.net *.split)
20.23.19 Quit    Guinness` (*.net *.split)
20.23.19 Quit    mc2739 (*.net *.split)
20.23.19 Quit    jhMikeS (*.net *.split)
20.23.19 Quit    tchan (*.net *.split)
20.23.19 Quit    Slasheri (*.net *.split)
20.23.19 Quit    Unhelpful (*.net *.split)
20.23.19 Quit    polemon (*.net *.split)
20.23.19 Quit    lembas (*.net *.split)
20.23.20 Quit    aevin (*.net *.split)
20.23.20 Quit    martii (*.net *.split)
20.23.21 Quit    jlbiasini (*.net *.split)
20.23.21 Quit    n17ikh (*.net *.split)
20.23.21 Quit    FOAD (*.net *.split)
20.23.21 Quit    orzo (*.net *.split)
20.23.21 Quit    Staphylo (*.net *.split)
20.23.21 Quit    perrikwp (*.net *.split)
20.23.21 Quit    thegeek (*.net *.split)
20.23.21 Quit    scorche (*.net *.split)
20.23.21 Quit    bug2000 (*.net *.split)
20.23.21 Quit    Poodlemastah (*.net *.split)
20.23.21 Quit    antil33t| (*.net *.split)
20.23.21 Quit    Sleepy_Coder (*.net *.split)
20.23.21 Quit    scorche|sh (*.net *.split)
20.24.25 Join    Sundiver [0] (~angel@174-124-6-86.dyn.centurytel.net)
20.24.25 Join    y4n [0] (y4n@unaffiliated/y4ndexx)
20.24.25 Join    Utchybann [0] (~Utchy@rps6752.ovh.net)
20.24.25 Join    jae [0] (~jae@dedicated.jaerhard.com)
20.24.25 Join    amithkk [0] (u4289@2buntu/writers/amithkk)
20.24.25 Join    Xerion [0] (~xerion@5419A30B.cm-5-2c.dynamic.ziggo.nl)
20.24.25 Join    ack [0] (~ack@mingbai.org)
20.24.25 Join    pjm0616 [0] (~user@114.200.203.101)
20.24.25 Join    kkit [0] (~quassel@li135-248.members.linode.com)
20.24.25 Join    Rondom [0] (~rondom@2a01:488:66:1000:b24d:4f2f:0:1)
20.24.25 Join    bzed [0] (~bzed@devel.recluse.de)
20.24.25 Join    bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com)
20.24.25 Join    Galois [0] (djao@efnet-math.org)
20.24.25 Join    ender` [0] (~ender@foo.eternallybored.org)
20.24.25 Join    pamaury [0] (~quassel@rockbox/developer/pamaury)
20.24.25 Join    Topy44 [0] (~Topy44@f049002126.adsl.alicedsl.de)
20.24.25 Join    JesusFreak316_ [0] (~JesusFrea@pool-173-65-65-136.tampfl.fios.verizon.net)
20.24.25 Join    liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
20.24.25 Join    fs-bluebot [0] (~fs-bluebo@g226069126.adsl.alicedsl.de)
20.24.25 Join    Strife89 [0] (~Strife89@207.144.201.128)
20.24.25 Join    ze [0] (ze@ze.yi.org)
20.24.25 Join    remlap [0] (~Patrick@190.28.169.217.in-addr.arpa)
20.24.25 Join    MethoS- [0] (~clemens@134.102.106.250)
20.24.25 Join    kevku [0] (x@2001:470:28:773::)
20.24.25 Join    dfkt [0] (dfkt@unaffiliated/dfkt)
20.24.25 Join    jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at)
20.24.25 Join    lovasoa [0] (~olojkine@78.251.21.108)
20.24.25 Join    Misan [0] (~Misanthro@adsl-89-217-195-136.adslplus.ch)
20.24.25 Join    einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
20.24.25 Join    n1s [0] (~n1s@rockbox/developer/n1s)
20.24.25 Join    bertrik [0] (~bertrik@rockbox/developer/bertrik)
20.24.25 Join    perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com)
20.24.25 Join    curtism [0] (~curtis@bas11-montreal02-1128531121.dsl.bell.ca)
20.24.25 Join    factor [0] (~factor@74.197.205.204)
20.24.25 Join    Rob2223 [0] (~Miranda@p4FFF2563.dip.t-dialin.net)
20.24.25 Join    nosa-j [0] (~m00k@adsl-74-235-26-132.clt.bellsouth.net)
20.24.25 Join    thegeek [0] (~thegeek@87.37.34.95.customer.cdi.no)
20.24.25 Join    TheSeven [0] (~TheSeven@rockbox/developer/TheSeven)
20.24.25 Join    pixelma [0] (quassel@rockbox/staff/pixelma)
20.24.25 Join    amiconn [0] (quassel@rockbox/developer/amiconn)
20.24.25 Join    mystica555_ [0] (~Mike@71-211-210-11.hlrn.qwest.net)
20.24.25 Join    adnap [0] (~adnap@rrcs-71-42-140-57.sw.biz.rr.com)
20.24.25 Join    user890104 [0] (~Venci@Addicted.to.Minecraft.ipv6.6bez10.info)
20.24.25 Join    mikroflops [0] (~yogurt@h-34-156.a238.priv.bahnhof.se)
20.24.25 Join    n17ikh [0] (~peter@c-174-56-150-44.hsd1.sc.comcast.net)
20.24.25 Join    kugel [0] (~kugel@rockbox/developer/kugel)
20.24.25 Join    scorche [0] (~scorche@rockbox/administrator/scorche)
20.24.25 Join    Torne [0] (~torne@rockbox/developer/Torne)
20.24.25 Join    sinthetek [0] (~sinthetek@unaffiliated/sinthetek)
20.24.25 Join    soap [0] (~soap@rockbox/staff/soap)
20.24.25 Join    markun [0] (~markun@rockbox/developer/markun)
20.24.25 Join    Zambezi [0] (~Zulu@bnc.fran.dotbnc.se)
20.24.25 Join    bug2000 [0] (~bug@unaffiliated/bug2000)
20.24.25 Join    Sleepy_Coder [0] (majic@unaffiliated/sleepycoder/x-938672)
20.24.25 Join    dv_ [0] (~quassel@chello080108009040.14.11.vie.surfer.at)
20.24.25 Join    advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
20.24.25 Join    plush [0] (~quassel@82.131.56.111.cable.starman.ee)
20.24.25 Join    parafin [0] (parafin@paraf.in)
20.24.25 Join    rasher [0] (~rasher@rockbox/developer/rasher)
20.24.25 Join    FOAD [0] (~foad@unaffiliated/foad)
20.24.25 Join    tah [0] (~thomas@aktaia.intevation.org)
20.24.25 Join    TBCOOL [0] (~tb@c-c63471d5.09-42-73746f22.cust.bredbandsbolaget.se)
20.24.25 Join    ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123)
20.24.25 Join    beta2k [0] (~Beta2K@d24-36-128-84.home1.cgocable.net)
20.24.25 Join    tmr [0] (jake@irc.turha.org)
20.24.25 Join    Guinness` [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net)
20.24.25 Join    mc2739 [0] (~mc2739@rockbox/developer/mc2739)
20.24.25 Join    Poodlemastah [0] (~Poodlemas@h-241-205.a218.priv.bahnhof.se)
20.24.25 Join    funman [0] (~fun@rockbox/developer/funman)
20.24.25 Join    jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS)
20.24.25 Join    antil33t| [0] (~Ahurhurr@101.98.150.103)
20.24.25 Join    froggyman [0] (~froggyman@unaffiliated/froggyman)
20.24.25 Join    tchan [0] (~tchan@lunar-linux/developer/tchan)
20.24.25 Join    zu_ [0] (~zu@ks387228.kimsufi.com)
20.24.25 Join    GodEater [0] (~bibble@rockbox/staff/GodEater)
20.24.25 Join    Bagder [241] (~daniel@rockbox/developer/bagder)
20.24.25 Join    preglow [0] (thomj@tvilling2.pvv.ntnu.no)
20.24.27 Join    guymann [0] (~charles@69.182.30.160)
20.24.27 Join    nomada [0] (~nomada@irc.consciente.de)
20.24.27 Join    lembas [0] (toastin@inafire.com)
20.24.27 Join    tmzt [0] (~tmzt@76.244.152.58)
20.24.27 Join    Slasheri [0] (miipekk@rockbox/developer/Slasheri)
20.24.27 Join    qnm [0] (~qnm@2001:44b8:3110:f300:208:9bff:fec0:179a)
20.24.27 Join    ruskie [0] (ruskie@sourcemage/mage/ruskie)
20.24.27 Join    jordan`` [0] (~gromit@2001:660:3302:2826:225:90ff:fe20:d9a8)
20.24.27 Join    Misanthropos [0] (~Misanthro@testomat.ee.ethz.ch)
20.24.27 Join    Unhelpful [0] (~quassel@rockbox/developer/Unhelpful)
20.24.27 Join    lmh [0] (lmh@nat/redhat/x-akwpetrhgkztlaee)
20.24.27 Join    topik [0] (awesome@wtf.grmpf.org)
20.24.27 Join    Farthen [0] (~Farthen@2a01:4f8:101:2a4:0:bc28:b2e1:9)
20.24.27 Join    polemon [0] (mcp@polemon.org)
20.24.27 Join    orzo [0] (~joe@ps38852.dreamhost.com)
20.24.27 Join    Bawitdaba [0] (~Sphinx@cpe-184-153-55-166.nycap.res.rr.com)
20.24.27 Join    yosafbridge [0] (~yosafbrid@li125-242.members.linode.com)
20.24.27 Join    knittl [0] (~knittl@unaffiliated/knittl)
20.24.27 Join    trompette [0] (~bob@punch.chezmerlet.net)
20.24.27 Join    dionoea [0] (~dionoea@videolan/developer/dionoea)
20.24.27 Join    linuxguy3 [0] (~timj@24-148-61-208.c3-0.lem-ubr1.chi-lem.il.cable.rcn.com)
20.24.27 Join    alexbobp [0] (~alex@108.60.198.57)
20.24.27 Join    nsx [0] (jm@epicsol.org)
20.24.27 Join    ukleinek [0] (~ukl@2001:6f8:1178:2:21e:67ff:fe11:9c5c)
20.24.27 Join    simabeis [0] (~simabeis@lobmenschen.de)
20.24.27 Join    gevaerts [0] (~fg@rockbox/developer/gevaerts)
20.24.27 Join    desowin [0] (~desowin@ip-69-162-133-251.static.chi2.systeminplace.net)
20.24.27 Join    freqmod [0] (~quassel@2001:700:300:1430:226:18ff:fe82:1a24)
20.24.27 Join    ved [0] (~ved@2001:41d0:1:5914::2)
20.24.27 Join    Naked [0] (~naked@naked.iki.fi)
20.24.27 Join    ranmachan [0] (~ranma@2a01:4f8:130:9321::2)
20.24.27 Join    Elfish [0] (amba@2a01:4f8:100:90a1:abc:abc:abc:abc)
20.24.27 Join    mystica555 [0] (~mystica@mystica.mobi)
20.24.27 Join    rjg [0] (~robert@odie.tomelliott.net)
20.24.27 Join    martii [0] (martii@sokrates.zagrodzki.net)
20.24.27 Join    aevin [0] (eivindsy@unaffiliated/aevin)
20.24.27 Join    scorche|sh [0] (~scorche@squisch.net)
20.24.27 Join    Staphylo [0] (~Staphylo@mareo.fr)
20.24.38 #       <plush> works with linux as well
20.30.50 #       <gevaerts> A trivial comment to start with. I don't think usb_set_host_present() should be marked inline
20.31.17 #       <plush> i couldn't figure out why the other functions were
20.31.19 #       <plush> to save space?
20.31.23 #       <plush> to reduce call stack size?
20.31.31 #       <plush> either way, i just stupidly replicated it :)
20.31.38 #       <plush> removed already
20.31.38 #       <gevaerts> I guessed that :)
20.32.03 #       <gevaerts> The others are only called from one place, so it saves a bit of space (just the call itself, really)
20.32.13 #       <plush> true
20.32.18 #       <plush> and here, it would be inlined twice
20.32.23 #       <plush> hence, achieving the opposite effect
20.32.24 #       <plush> noted
20.32.31 #       * gevaerts nods
20.33.02 #       <gevaerts> I'm not really convinced we want the inline on the others here anyway. The compiler should be smart enough to do the right thing I think (but I may be wrong)
20.33.33 #       <plush> inline is only a hint anyway
20.33.45 #       <gevaerts> true
20.33.47 #       <plush> so with a stupid compiler, no matter how much you do or do not inline, there is not much you can do
20.36.08 Join    B4gder [241] (~daniel@rockbox/developer/bagder)
20.39.22 Quit    liar (Remote host closed the connection)
20.41.21 #       <gevaerts> plush: at first sight that looks good to me. I think jhMikeS and pamaury should have a look too though :)
20.41.51 #       <plush> my main concern is that some of the drivers were doing additional checking in usb_drv_usb_detect_event()
20.42.02 #       <plush> if any of this is actually necessary, it should be preserved somehow
20.42.17 #       <plush> much of it looked like it was the same thing, differently implemented and redundant though
20.42.28 #       <gevaerts> I think that those were remnants from the old mechanism
20.45.14 #       <pamaury> at first sight it looks good to me, it removes some complexity I wanted to removed so I'm more than happy with it :) As for the checks by the drivers, I would be tempted to say from my implementer point of view that no one really knows what the function was exactly supposed to do :-/
20.45.54 #       <gevaerts> at least the pp502x one was clearly for the bus reset based detection
20.45.59 #       <pamaury> the check for the reset is obsolete (reset was the old mechanism)
20.46.20 #       <gevaerts> The others look like different ways to check the same thing to me
20.46.43 #       <pamaury> the as3525 seems to prevent calling it if not necessary
20.47.58 #       <gevaerts> It also has nice obsolete comments about implementing USB
20.48.12 #       <gevaerts> So I'm not sure how relevant that has been recently
20.54.13 #       <gevaerts> OK, it works for me on e200v1, fuzev2, and gigabeat F, on linux. I'll test on windows in a minute. I'd still like to see testing on a non-DETECT_BY_REQUEST device such as a nano2
20.54.18 #       <gevaerts> *nano2g
20.55.41 #       <gevaerts> Or rather, I'd like someone to move over all remaining drivers ;)
20.55.45 ***     Saving seen data "./dancer.seen"
20.59.15 Join    dreamlayers [0] (~bgjenero@bas4-windsor12-1279287645.dsl.bell.ca)
20.59.15 Quit    dreamlayers (Changing host)
20.59.15 Join    dreamlayers [0] (~bgjenero@rockbox/developer/dreamlayers)
21.00.18 Quit    Zambezi (Changing host)
21.00.18 Join    Zambezi [0] (~Zulu@unaffiliated/zambezi)
21.00.46 #       <jlbiasini> Does anybody know where plugins keymaps are sets?
21.02.06 #       <pamaury> in the plugins
21.02.39 #       <gevaerts> Windows (7) seems OK too
21.11.49 Join    Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com)
21.13.27 #       <gevaerts> pamaury, jhMikeS do we actually need to do anything more than define USB_DETECT_BY_REQUEST to move drivers over after this patch?
21.14.14 #       <pamaury> implement usb_drv_usb_detect I think, I can't remember exactly why it wasn't trivial for some others too
21.15.57 #       <gevaerts> USB_STATUS_BY_EVENT still exists. That's the one where usb_detect() is involved
21.16.48 #       <plush> there is some difference between status and state that i do not understand and did not touch
21.17.30 #       <gevaerts> I think someone with a nano2g or an onda should just try
21.17.41 #       <gevaerts> Or a classic
21.18.07 #       <gevaerts> USB on mr500 didn't work last week when I tried it, so that's not too useful right now
21.18.32 #       <gevaerts> And zvm never got to an actually usable state I think, so I'm not sure if I'm too worried
21.22.44 #       * kugel has some powermgmt rewrite going
21.23.09 #       <saratoga> does anyone actually own an m200v4?
21.23.28 #       <gevaerts> saratoga: I think scorche may have a few
21.23.55 #       <saratoga> i'm curious about the volume related shutdown, probably something with the voltage regulators that could be fixed
21.24.00 #       <lovasoa> kugel: Did you post your power management patch somewhere? 
21.24.23 #       <gevaerts> saratoga: actually, RockboxTesting says domonoky, jhMikeS and Llorean
21.24.41 #       <saratoga> if one of those people could comment, i'm curious if it always shuts down, sometimes shuts down, etc
21.24.49 #       <saratoga> i'll see if i can find one on ebay
21.25.03 #       <kugel> lovasoa: not yet
21.25.15 #       <kugel> lovasoa: or do you mean the one for the ypr0?
21.25.36 #       <lovasoa> kugel: I mean for the ypr0, yes
21.26.24 #       <kugel> lovasoa: http://pastie.org/3097807 if you like
21.26.49 #       <kugel> just waiting for some battery benches before committing
21.26.55 #       <lorenzo92> kugel: I have a bench finally :)
21.27.03 #       <kugel> \o/
21.28.19 #       <lorenzo92> kugel: http://pastie.org/3097818
21.28.31 #       <lorenzo92> this is battery discharge while backlight always on!
21.29.00 #       <kugel> lorenzo92: 4200mV is the max voltage?
21.29.16 #       <lorenzo92> yep
21.29.17 #       <kugel> 6:33 is quite poor even for backlight 
21.29.26 #       <lorenzo92> sure?
21.29.31 #       <lovasoa> kugel: Merci
21.29.39 #       <lovasoa> *Thanks
21.29.44 #       <kugel> lorenzo92: I'd say so, not sure actually
21.30.09 #       <lorenzo92> kugel: well it was quite bright the default level, I keep always the first :)
21.30.19 #       <kugel> what current does that correspond to?
21.31.38 #       <lorenzo92> uhm in the ascodec you mean? it's the very first step
21.31.42 #       <lorenzo92> guess
21.31.45 #       <lorenzo92> 1,.... ma
21.32.20 #       <lorenzo92> kugel: yeah 1,2 mA
21.32.31 #       <lorenzo92> but uhm I guess it uses more anyway
21.32.41 #       <lorenzo92> ah no srry
21.32.46 #       <lorenzo92> this is the first step
21.32.52 #       <lorenzo92> so default is 4
21.33.02 #       <lorenzo92> so 4,8 mA
21.34.51 #       <plush> http://www.rockbox.org/tracker/task/12497
21.34.54 #       <lorenzo92> kugel: it would be very interesting to get the actual amperage from the battery using a multimeter...
21.34.56 #       <plush> i made a task for the patch
21.35.01 #       <lorenzo92> kugel: my R0 is still unopened :D
21.35.28 Quit    JesusFreak316_ (Ping timeout: 240 seconds)
21.36.45 #       <gevaerts> plush: did anything change from the pastebin version (apart from the inline)?
21.36.57 #       <plush> gevaerts: nome, that's the only change
21.37.11 #       <plush> i spent half an hour trying to explain what the damn thing does though
21.37.13 #       <lorenzo92> kugel: definitely, R0 won't turn off when discharged (< 3,450...)
21.37.24 #       <plush> it's not always trivial to describe a code change in words :)
21.37.24 #       <gevaerts> Always useful :)
21.37.36 #       <kugel> 92mA, no?
21.38.50 #       <lorenzo92> ah you mean the average, not only backlight -.-
21.38.53 #       <lorenzo92> well yeah
21.39.01 #       <lorenzo92> 600/6,5....
21.39.37 #       <kugel> ~68mA for backlight
21.40.12 #       <lorenzo92> indeed, the backlight has a great impact
21.41.28 #       <dfkt> is it a known issue that some items can be added to the shortcuts list, but don't work? eg. i put the pictureflow demo into shortcuts, but it displays there with the full folder structure as name (/.rockbox/rocks/...), and can't be opened
21.42.06 #       <lorenzo92> dfkt: I was also wondering how to delete them without messing with the file....
21.42.30 #       <dfkt> lorenzo92, right, that's the other issue - it can't be deleted
21.42.47 #       <lorenzo92> dfkt: okay I'm not the only one hihi
21.43.37 #       <lorenzo92> kugel: I cannot do further benchs, well uhm I can do the recharge one if you want!
21.44.07 #       <lorenzo92> I'll do it...
21.45.21 #       <lorenzo92> kugel: this time while charging...backlight off or what?
21.45.31 #       <lorenzo92> kugel: playing music or?
21.47.21 #       <jlbiasini> pamaury: the patch is now ready http://www.rockbox.org/tracker/task/12405
21.48.28 #       <gevaerts> mr500 really needs someone who cares about it
21.49.44 Quit    lovasoa (Read error: Connection reset by peer)
21.51.05 #       <kugel> lorenzo92: a recharge one would be fine
21.51.28 #       <lorenzo92> kugel: no matter the test conditions?
21.51.32 #       <kugel> music or not doesnt matter
21.51.35 #       <lorenzo92> okay
21.55.27 #       <kugel> lorenzo92: keep backlight on
21.55.46 #       <lorenzo92> okay ;)
21.56.18 Quit    Strife89 (Quit: Away!)
21.57.01 #       <pamaury> jlbiasini: ok thansk, I'm busy right now but I'll commit it soon
21.57.22 #       <lorenzo92> then after plotting the graph, and finding the slope of the median line, you need to?
21.59.57 #       <jlbiasini> pamaury: regarding the manual we'll have to undef radio and recording as long as they don't work because else the manual compiler print those section too...
22.00.21 #       <nosa-j> which one should i get for rockbox the new of old sansa fuze? consitering the new one isn't as suported?
22.00.40 #       <nosa-j> im worried about the thouch controls
22.00.41 #       <kugel> lorenzo92: graphs are nice but not needed
22.00.55 #       <jlbiasini> nosa-j: depend what you use
22.01.27 #       <kugel> lorenzo92: needed are the voltage numbers to map 10%, 20% etc, and the max and min voltage
22.01.31 #       <jlbiasini> nosa-j: we only have radio and recording missing in the fuze+
22.01.43 #       <kugel> and the discharge time the milliamps
22.01.47 #       <kugel> +for
22.02.32 #       <jlbiasini> nosa-j: we have a stable touchpad implementation for now: a 3x3 grid
22.03.13 #       <nosa-j> ahh
22.03.19 #       <lorenzo92> kugel: ah ok ;) anyway I did the graph...but I guess I did a mistake, it's time in X axis and voltage in Y right?
22.03.27 #       <nosa-j> im just makeing sure thanks for the help
22.04.22 #       <jlbiasini> pamaury: regarding the bootloader you should probably upload the tagged file(s?) somewhere And I will try to find someone to upload it in the meantime...
22.04.44 #       <nosa-j> jlbiasini: so 6 buttons eah i might like the tatical buttons on the original i supose but a micro usb card on the fuze+ o_o
22.04.46 #       <lorenzo92> kugel: ah scaling issue :D
22.05.03 #       <nosa-j> usb port * woww
22.05.10 #       <nosa-j> no clue why i even typed card
22.05.14 #       <gevaerts> nosa-j: "old fuze or new fuze" are rather confusing terms if you mean "fuze or fuze plus"
22.05.29 #       <nosa-j> ha ture
22.05.53 #       <nosa-j> theres a v2 of the original fuze
22.05.59 #       <nosa-j> forgot about that one
22.06.08 #       <jlbiasini> nosa-j: fuze+ had 9 virtual keys (3x3) + 3 solid key (volumes and power)
22.06.36 #       <jlbiasini> nosa-j: oups I was talking about fuze+ forget everything I wrote
22.06.41 #       <curtism> hey so i have a few songs (pirated, i admit) that rockbox will not read the tags on, and if i try to play them rockbox freezes
22.06.51 #       <curtism> same thing with the stock firmware
22.06.59 #       <nosa-j> jlbiasini: i did mean fuze+ i just said the wrong thing so your fine
22.07.11 #       <jlbiasini> :D
22.07.17 #       <gevaerts> curtism: which codec?
22.07.21 #       <curtism> i have a sansa fuze v2... i can't figure out what's wonky about these files. banshee will play them fine
22.07.27 #       <nosa-j> my bad for that i really didn't explain good
22.07.44 #       <curtism> Audio file with ID3 version 2.3.0, unsynchronized frames, contains: MPEG ADTS, layer III, v1, 320 kbps, 44.1 kHz, JntStereo
22.08.12 #       <gevaerts> Anything special in them like e.g. APE tags?
22.08.36 #       <nosa-j> i kinda want to get the radio though hmm
22.08.50 #       <curtism> gevaerts: how would i find that out?
22.08.58 #       <curtism> gevaerts: that output above was from `file` btw
22.09.03 #       <nosa-j> jlbiasini: im sure it will be suported in time but i can't decied
22.09.09 #       <pamaury> jlbiasini: http://www.mediafire.com/?pjpwe8pi8hdah3n
22.09.35 #       <jlbiasini> nosa-j: radio is nearly all implemented but for some reason still doesn't work... It might take a few more month
22.09.46 #       <nosa-j> ahh hmm
22.09.50 #       <jlbiasini> recording should be faster
22.09.50 #       <gevaerts> curtism: good question... I'm not really a codec specialist (well, I'm not a codec specialist at all...), just asking the common first questions here. maybe saratoga can help more
22.09.51 #       <pamaury> hopefully less than that !
22.09.58 #       <jlbiasini> pamaury: thx
22.10.11 #       <nosa-j> the touch buttons worrie me though 
22.10.12 #       <jlbiasini> lol
22.10.15 #       <pamaury> recording should be easy to implement, the audio parameters could get some more tweaking
22.10.31 #       <pamaury> there is room for improvement for the battery life too
22.10.42 #       <curtism> gevaerts: it's weird because the files work fine in all the players i have on my desktop, but they freeze the stock and rockbox firmwares :\
22.10.58 #       <jlbiasini> nosa-j: why?
22.11.09 #       <gevaerts> curtism: maybe filesystem corruption?
22.11.15 #       <nosa-j> seams like it would be hard to get them to respond
22.11.25 #       <nosa-j> i have never used them so im worried
22.11.43 #       <curtism> gevaerts: i've removed the files and put them back several times (not always in the same place)
22.11.51 #       <dreamlayers> curtism: maybe "unsynchronized frames" in ID3? What about if you write a tag without that or just strip the tag?
22.11.59 #       <nosa-j> jlbiasini: i did have a ipod nano chronomatic which volume button was touch sensitive
22.12.55 #       <jlbiasini> nosa-j: fuze+ has solid volume keys
22.13.18 #       <nosa-j> hm right but i was just compairing the feature 
22.13.49 #       <nosa-j> i could always try it for a week or so and send it back if i don't like it
22.14.07 #       <gevaerts> nosa-j: in the end *you* will have to decide. Informing us of every doubt you have isn't going to help with that
22.14.19 #       <curtism> dreamlayers: i rewrote the tags using banshee and that's still there, not sure if that's what you meant
22.15.18 #       <nosa-j> gevaerts: yes i agree i just really hate inpulse buying. sorry for any trubble :D
22.16.09 #       <nosa-j> i'll try to keep my questions to rockbox spicific questions
22.16.18 #       <curtism> dreamlayers: but yes, the "synchronized frames" part seems to be the only difference from other audio
22.16.30 #       <dreamlayers> curtism: can you just remove the id3v2 tag?
22.16.40 #       <curtism> dreamlayers: how should i do that?
22.16.55 #       <curtism> dreamlayers: (running arch linux)
22.19.03 #       <dreamlayers> curtism: EasyTAG is a nice graphical tagger program that can strip tags.
22.19.26 #       <curtism> dreamlayers: thanks
22.22.00 #       <jlbiasini> so apart from badger who seems to be away who can also put file on the server?
22.22.18 Join    [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940)
22.23.49 #       <gevaerts> [Saint]: do you still have a working nano2g?
22.24.37 #       <[Saint]> I do, yep. Howcome?
22.24.47 #       <curtism> dreamlayers: looks like just re-saving the tags from easytags gets rid of the unsynchronized frames stuff, thanks
22.25.04 #       <gevaerts> [Saint]: any chance of testing FS#12497?
22.25.04 #       <fs-bluebot> http://www.rockbox.org/tracker/task/12497 3Reorganize USB initialization to make it work with FreeBSD (patches, unconfirmed)
22.25.20 #       <dreamlayers> curtism: do the files play properly in Rockbox after that?
22.25.29 #       <curtism> dreamlayers: i'll check in a second
22.26.38 #       <[Saint]> gevaerts: what're the test conditions? I mean, with which os should I be testing? U should be able to test this this evening, I can't presently, sorry.
22.27.26 #       <gevaerts> [Saint]: test both normal connection and chare-only connection, on any OS you have handy
22.30.28 #       <curtism> dreamlayers: they play now :D thanks a lot
22.31.22 #       <funman> jlbiasini: perhaps his brother
22.31.23 #       <dreamlayers> curtism: you're welcome!
22.32.40 Quit    y4n (Quit: HOLY SHIT!  WE'RE ALL JUST LIVING ON A GINORMOUS FUCKING SPINNING ROCK FLOATING THROUGH SPACE CIRCLING A BIG FUCKING BALL OF FIRE!!!)
22.38.15 #       <jlbiasini> funman: who is he?
22.38.48 #       <funman> zagor
22.39.15 Quit    dreamlayers (Quit: Leaving)
22.39.32 #       <jlbiasini> I yeah right. But they must be in holydays then
22.40.34 #       <funman> by the way, what happens if the swedes are hit by a bus ?
22.45.48 #       <curtism> can i get rockbox to treat whatever image is in the same folder as the song as the album art?
22.46.16 Quit    B4gder (Quit: It is time to say moo)
22.46.16 #       <[Saint]> funman: I'd thought about that too...
22.48.07 #       <[Saint]> curtism: yes, sure. the manual covers art naming/placement
22.48.52 #       <curtism> [Saint]: what heading is it under, i can't find it
22.49.35 #       <[Saint]> Isn't there a search function in the manual now?
22.50.46 #       <dfkt> curtism, FS#10201 has info about priorities in naming
22.50.46 #       <fs-bluebot> http://www.rockbox.org/tracker/task/10201 3Fix album art file search priority (patches, closed)
22.51.09 Quit    yosafbridge (Read error: Operation timed out)
22.51.41 #       <curtism> dfkt: thanks
22.51.53 #       <[Saint]> It should be in the manual...
22.52.15 #       <dfkt> i knew there was a wiki site about that, but i couldn't find it... doesn't seem to be in the manual as well
22.52.27 #       <[Saint]> Hum.
22.52.55 #       <curtism> hm... these anamanaguchi albums have animated covers... i doubt rockbox supports that
22.53.48 #       <funman> curtism: gif?
22.53.53 #       <curtism> yeah
22.54.26 #       <funman> rockbox has neither gif neither animated images support (except mpeg2video)
22.55.03 #       <dfkt> no gif support? didn't know that - due to the patent issue?
22.55.40 #       <funman> the patent has expired i think so even if it did apply to us we wouldn't care
22.55.45 #       <gevaerts> No (well at least not these days)
22.55.48 ***     Saving seen data "./dancer.seen"
22.55.50 #       <funman> more like nobody use gif anymore except for animated pics
22.56.36 #       <curtism> animated covers aren't the most common thing anyway...
22.56.43 Join    yosafbridge [0] (~yosafbrid@li125-242.members.linode.com)
22.58.41 #       <CIA-88> New commit by 03funman (r31468): typo
22.59.57 Quit    plush (Remote host closed the connection)
23.02.05 Join    plush [0] (~quassel@82.131.56.111.cable.starman.ee)
23.14.48 Quit    kevku (Ping timeout: 252 seconds)
23.14.56 #       <lorenzo92> kugel: in some minutes also the charging bench with bl on + music will be ready ;)
23.20.46 #       <saratoga> scorche:  ban arcteryxfz
23.23.01 #       <saratoga> gevaerts, JdGordon:  either of you too
23.23.30 Quit    [Saint] (Read error: Connection reset by peer)
23.23.33 Join    [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940)
23.23.52 Nick    kugel is now known as kugelp (~kugel@rockbox/developer/kugel)
23.23.59 #       <saratoga> adattyhalge as well
23.24.28 Quit    [Saint_] (Read error: Connection reset by peer)
23.24.30 #       <gevaerts> done
23.24.31 Join    [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940)
23.25.38 Join    CaptainKewl [0] (captainkew@207-237-110-248.c3-0.nyr-ubr2.nyr.ny.cable.rcn.com)
23.28.49 Quit    Zambezi (Ping timeout: 268 seconds)
23.29.40 #       <lorenzo92> kugel:ready
23.29.48 Join    Zambezi [0] (Zulu@bnc.fran.dotbnc.se)
23.31.49 #       <lorenzo92> kugel: here it is ;)
23.31.51 #       <lorenzo92> kugel: http://pastie.org/3098520
23.32.02 #       <lorenzo92> kugelp: ops you changed nick :)
23.37.35 Join    bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net)
23.37.48 #       <lorenzo92> kugelp: in the next days I could do some other bench...now I go ;)
23.38.42 Quit    lorenzo92 (Remote host closed the connection)
23.40.36 Join    davo [0] (~davo@ppp-68-120-83-185.dsl.irvnca.pacbell.net)