00:03:26 | | Quit CaptainKwel ("http://www.mibbit.com ajax IRC Client") |
00:03:46 | | Quit bluebrother ("leaving") |
00:15:54 | | Quit BlakeJohnson86 (Remote closed the connection) |
00:16:36 | | Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
00:17:53 | | Quit bertrik ("Leaving") |
00:19:42 | | Quit froggyman ("CGI:IRC") |
00:29:24 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
00:40:02 | | Nick rwcr_ is now known as rwcr (n=oremanj@xenon.get-linux.org) |
00:41:42 | *** | Saving seen data "./dancer.seen" |
00:45:12 | | Join CaptainKewl [0] (i=jds@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) |
00:46:02 | | Quit KBH (Read error: 110 (Connection timed out)) |
00:50:42 | | Join mt__ [0] (n=MTee@41.233.143.197) |
00:51:41 | | Quit Lynx_ (Read error: 104 (Connection reset by peer)) |
00:52:21 | | Nick mt__ is now known as mt- (n=MTee@41.233.143.197) |
00:53:58 | | Join _Auron|G1_ [0] (n=Auron@cpe-24-27-90-175.tx.res.rr.com) |
00:55:39 | | Quit kachna|lappy (No route to host) |
01:00 |
01:00:50 | | Quit advcomp2019 (Read error: 131 (Connection reset by peer)) |
01:01:11 | | Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) |
01:03:11 | | Quit jgarvey ("Leaving") |
01:05:59 | | Quit _Auron|G1_ (Remote closed the connection) |
01:06:38 | | Quit Thundercloud (Remote closed the connection) |
01:10:27 | saratoga | i just noticed the bootloader won't go into USB mode on plugin if the hold switch is on |
01:10:34 | saratoga | on the Sansa e200 |
01:10:49 | saratoga | is there a reason for this? |
01:15:26 | | Quit rwcr (Read error: 104 (Connection reset by peer)) |
01:16:17 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
01:16:25 | | Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-c3f1ed8460abe28c) |
01:16:45 | | Quit matsl (Read error: 110 (Connection timed out)) |
01:19:35 | saratoga | main-pp.c is the Sansa's and Gogear right? |
01:19:48 | saratoga | oh H10 |
01:20:41 | saratoga | is there a reason the H10 bootloader doesn't have USB enabled? |
01:21:07 | | Quit ender` (" The problem with political jokes is they get elected. -- Henry Cate, VII") |
01:21:28 | | Join kachna|lappy [0] (n=kachna@r4ax178.net.upc.cz) |
01:23:39 | | Join rwcr [0] (n=oremanj@xenon.get-linux.org) |
01:30:22 | | Quit JdGordon| ("http://www.mibbit.com ajax IRC Client") |
01:34:45 | | Join cmwslw [0] (n=cmwslw@98.249.113.152) |
01:34:55 | | Part cmwslw ("Ex-Chat") |
01:45:53 | | Join JdGordon| [0] (i=441bd770@gateway/web/ajax/mibbit.com/x-76b447b886503363) |
01:47:06 | | Part toffe82 |
01:47:25 | | Quit HellDragon (Read error: 60 (Operation timed out)) |
01:48:27 | | Quit JdGordon| (Client Quit) |
01:48:39 | | Join HellDragon [0] (n=jd@modemcable022.187-203-24.mc.videotron.ca) |
01:49:09 | | Join bubsy [0] (i=Bubsy@94.139.72.137) |
01:52:41 | | Join _Auron|G1_ [0] (n=Auron@m3f0436d0.tmodns.net) |
01:55:41 | | Join JdGordon| [0] (i=441bd770@gateway/web/ajax/mibbit.com/x-713e8856059d3853) |
01:56:18 | | Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) |
01:58:30 | | Quit JdGordon| (Client Quit) |
02:00 |
02:01:11 | | Join midijunkie [0] (n=Miranda@pD9547105.dip0.t-ipconnect.de) |
02:01:50 | | Quit midijunkie (Client Quit) |
02:03:33 | | Quit amiconn (Nick collision from services.) |
02:03:35 | | Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) |
02:03:39 | | Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) |
02:03:39 | | Quit pixelma (Nick collision from services.) |
02:03:57 | | Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) |
02:03:58 | | Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) |
02:08:24 | | Quit _Auron|G1_ (Remote closed the connection) |
02:12:19 | | Quit efyx_ (Remote closed the connection) |
02:17:31 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
02:17:57 | | Quit dfkt (Read error: 104 (Connection reset by peer)) |
02:26:47 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
02:27:00 | | Part robin0800 ("Ex-Chat") |
02:27:56 | | Join robin0800_ [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
02:35:53 | | Quit robin0800_ ("Ex-Chat") |
02:36:53 | | Quit soap () |
02:39:12 | | Join robin0800_ [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
02:41:45 | *** | Saving seen data "./dancer.seen" |
02:42:00 | | Quit robin0800_ (Client Quit) |
02:42:19 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
02:42:56 | | Join andy` [0] (i=andy@cassarossa.samfundet.no) |
02:50:12 | | Quit HellDragon (Read error: 104 (Connection reset by peer)) |
02:51:14 | | Join HellDragon [0] (n=jd@modemcable022.187-203-24.mc.videotron.ca) |
02:54:57 | | Join toffe82 [0] (n=chatzill@adsl-99-130-6-47.dsl.frs2ca.sbcglobal.net) |
02:57:24 | | Quit robin0800 ("Ex-Chat") |
02:57:58 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
02:59:19 | | Join robin0800_ [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
02:59:32 | | Quit robin0800 (Client Quit) |
03:00 |
03:08:54 | | Quit robin0800_ ("Ex-Chat") |
03:16:54 | | Join evilnick [0] (i=620ec27e@gateway/web/ajax/mibbit.com/x-5a442115accfe229) |
03:17:32 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
03:23:17 | CIA-38 | New commit by unhelpful (r20864): Build pictureflow using overlay on lowmem targets, support JPEG AA in PF on all targets. |
03:24:45 | | Join robin0800_ [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
03:25:17 | | Quit robin0800 ("Ex-Chat") |
03:26:02 | | Join KBH [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
03:33:30 | | Quit KBH ("ZNC") |
03:34:02 | | Quit robin0800_ ("Ex-Chat") |
03:39:24 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
03:40:28 | CIA-38 | New commit by unhelpful (r20865): Add missing PictureFlow overlay source, fix properties on new files. |
03:43:38 | toffe82 | I have a problem creating a playlist of all my songs on my gigabeat X, it insert 9 tracks and stops, if I try to see the list it says playlist buffer full and when I try to open it with windows explorer it says the file is corrupted |
03:43:53 | toffe82 | is it a problem of my HD ? |
03:44:06 | evilnick | Have you tried checkdisk? |
03:47:20 | toffe82 | found it, disk full :) |
03:47:32 | toffe82 | there should be a message for this |
03:48:10 | evilnick | The disk was *that* full that it couldn't create the playlist? |
03:50:26 | toffe82 | I m trying now |
03:51:06 | toffe82 | yes, it was full |
03:51:10 | toffe82 | working now |
03:52:12 | Unhelpful | i'm pretty sure that "that full" on FAT just means that all clusters have been allocated. it's not like FAT has tail packing. |
03:52:52 | evilnick | Ah, okay. I was imagining that toffe82 had managed to fill the entire drive to within 10s of KB! |
03:53:02 | | Join soap [50] (n=soap@rockbox/staff/soap) |
03:53:33 | toffe82 | strange 23000 tracks and it continue inserting ??? |
03:54:35 | * | toffe82 doing chekdisk |
04:00 |
04:01:24 | | Quit evilnick ("http://www.mibbit.com ajax IRC Client") |
04:01:36 | | Join KBH [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
04:13:55 | | Quit synergist (Remote closed the connection) |
04:16:51 | | Join synergist [0] (n=christof@cant.be-arsed.co.uk) |
04:18:10 | | Join fisxoj [0] (n=fisxoj@149.43.110.23) |
04:18:42 | fisxoj | Hello, the iAudio 7 info page seems a bit out of date, I was wondering how stable the port is now? |
04:21:55 | krazykit | it's not out of date. nothing has really happened with the port |
04:22:32 | fisxoj | that's too bad, I'd love to try it out, but, I don't want anything too experimental |
04:23:01 | Unhelpful | fisxoj: then you need to look at supported devices. |
04:24:17 | fisxoj | Unhelpful: I already own an iAudio 7, so, the device isn't the question |
04:29:26 | | Quit miepchen^schlaf (Read error: 60 (Operation timed out)) |
04:39:02 | scorche | and we are saying Rockbox doesnt run on that device, try another ;) |
04:41:48 | *** | Saving seen data "./dancer.seen" |
04:46:03 | Unhelpful | hrm, i'm seeing potential problems for embedded AA. and i don't really like the obvious solution. we can easily support id3 AA when not using the unsynchronization scheme. the only standard about for AA in vorbis seems to be base64 encoding. it *looks* like flac and mp4 can at least guaranteed that the stored image is contiuguous and unmodified. |
04:46:31 | Unhelpful | those are the requirements for "easy" AA support - the we be able to open the file, seek in it, and call read_jpeg_fd. |
04:48:26 | saratoga | if its not continuous can the metadata parser for a format make it continuous? |
04:48:53 | Unhelpful | the other way i imagine we could do this is rather icky... the caller can pass in a function pointer that will either preprocess the file data, or act as a replacement for calling read()... this seems very, very ugly to me, and means complicating read_jpeg_fd more than a little. |
04:50:42 | Unhelpful | ..or else duplicating it with another function, something like read_jpeg_getdata, that would use a function pointer. but i'd rather switch on whether or not the pointer was passed than do that, since that route means having two jpeg decoders, and adding another 11-14KiB of binary, for something that i personally don't think is a very important feature. |
04:51:26 | saratoga | when the file is buffered into memory and pass through the metadata parser, could it be descrambled and stored sequentially in memory? |
04:51:31 | Unhelpful | requiring that the data actually *be* contiguous and unaltered in the file strikes me as *very* user-unfriendly, and something that will lead to users asking us what we mean by unsynchronization, and how do they do that |
04:51:50 | Unhelpful | which i'm already worried about, given the many ways you can encode a jpeg that we can't decode ;) |
04:53:12 | Unhelpful | saratoga: the reader, as it is presently designed, reads the file sequentially as needed. i think that perhaps the most acceptable way to go would be to offer a post-processing hook. if one is passed, we call it after filling the read buffer, it adjusts the data and the bytes-in-buffer count, etc. |
04:55:01 | saratoga | Unhelpful: do we need a hook though? I thought the id3v2 tag is parsed on load, couldn't it be unsynced as its being parsed? |
04:55:47 | saratoga | i guess have get_mp3_metadata rewrite it |
04:55:57 | Unhelpful | saratoga: the problem there is that the decoder is not looking at in-memory data at all. it's passed a filename, and nothing else, at present. |
04:56:45 | saratoga | so decoding happens before the metadata is parsed? |
04:58:08 | Unhelpful | that's not the problem so much as the fact that the decoder is entirely independent of metadata parsing. if we wanted to provide a buffer for it to use, we could be loading jpeg backdrops, also. it doesn't know anything about metadata, you hand it a fd or filename, and it reads the data from the disk and decodes it. |
04:58:17 | | Quit petur ("Zzzzz") |
04:58:48 | Unhelpful | i think the post-process hook is probably the cleanest way to do it, without making things much uglier for external AA files. |
04:58:59 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
05:00 |
05:00:14 | Unhelpful | if we're worried about the hit of testing and calling that function hook over and over, we can rather easily make the read buffer larger |
05:11:32 | | Quit fisxoj ("Ex-Chat") |
05:17:45 | | Quit Horscht ("Verlassend") |
05:51:36 | JdGordon | what does car adaptor mode do when power is through usb? |
05:51:40 | JdGordon | i.e... the sansas... |
05:54:23 | JdGordon | am i going to need a custom bootloader and build to have it usable, so it doesnt try connecting to msc? |
05:58:42 | Unhelpful | "real" USB, or some power adapter that uses the same same jack? |
06:00 |
06:00:09 | JdGordon | the 2nd |
06:00:38 | Llorean | I think if you have an SVN bootloader, you don't need to worry |
06:00:48 | Llorean | I believe the SVN bootloaders now basically do nothing on USB for the e200 |
06:01:14 | JdGordon | trying to install a new bootloader now.... usb isnt connecting for some resadson |
06:01:25 | Llorean | But I think car adapter mode, in general, needs a lot of polish. At least from what I hear it's a bit unpredictable depending on how you're charging and what target you're using. |
06:01:51 | * | Llorean still thinks we need to do something about the USB charging button problem. |
06:02:01 | * | JdGordon still votes for hold |
06:02:11 | JdGordon | but the quickscreen button would work also |
06:02:12 | * | Llorean still also thinks the most user friendly solution is an option for whether the default behaviour is "Charge" or "Connect", and any button held down gets the other one. |
06:02:23 | JdGordon | or that |
06:02:37 | * | JdGordon starting to wish he hadnt lost his other e200 |
06:04:04 | JdGordon | although.. come to think of it.. it was a v2.. so wouldnt help me here anyway :/ |
06:06:21 | JdGordon | weee :) i found the bugger |
06:06:28 | JdGordon | no 6gb microSD with it though :'( |
06:41:51 | *** | Saving seen data "./dancer.seen" |
06:59:37 | | Join bagawk_ [0] (n=lee@c-98-232-168-140.hsd1.or.comcast.net) |
07:00 |
07:06:18 | | Join AndyIL [0] (i=AndyI@212.14.205.32) |
07:13:08 | | Quit bagawk (Read error: 110 (Connection timed out)) |
07:17:28 | | Quit AndyI (Read error: 110 (Connection timed out)) |
07:23:29 | | Quit tessarakt ("Client exiting") |
07:27:56 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
07:28:25 | | Join Mike_Flip [0] (n=chatzill@d235-170-198.home1.cgocable.net) |
07:31:39 | | Join JdGordon| [0] (i=836b0055@gateway/web/ajax/mibbit.com/x-fe1509414ba40cb5) |
07:32:15 | | Quit JdGordon| (Client Quit) |
07:35:07 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
07:35:09 | | Quit CaptainKewl (Read error: 110 (Connection timed out)) |
07:38:23 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
07:41:55 | | Join Makuseru [0] (n=max@163.106.40.24.aeneasdsl.com) |
07:43:03 | | Quit jmillikin (Read error: 110 (Connection timed out)) |
07:50:00 | | Join matsl [0] (n=matsl@dhcp100.contactor.se) |
07:54:49 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
08:00 |
08:02:04 | | Join Rob2223 [0] (n=Miranda@p4FDCE143.dip.t-dialin.net) |
08:07:51 | | Part toffe82 |
08:19:33 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
08:21:42 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
08:26:05 | | Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) |
08:41:54 | *** | Saving seen data "./dancer.seen" |
08:46:58 | | Quit Mike_Flip ("ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]") |
08:54:27 | | Join petur [50] (n=petur@rockbox/developer/petur) |
08:56:10 | | Quit faemir ("Leaving") |
08:59:45 | | Join Rob2222 [0] (n=Miranda@p4FDCD123.dip.t-dialin.net) |
09:00 |
09:02:17 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
09:06:40 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
09:09:31 | | Quit bertrik ("Leaving") |
09:14:18 | | Join flydutch [0] (n=flydutch@host219-166-dynamic.15-87-r.retail.telecomitalia.it) |
09:18:03 | | Join lymeca [0] (n=lymeca@student165-228.hampshire.edu) |
09:18:23 | | Quit Rob2223 (Read error: 110 (Connection timed out)) |
09:20:30 | | Join LinusN [0] (n=linus@rockbox/developer/LinusN) |
09:29:09 | pixelma | Unhelpful: for album art (in the core or pictureflow) I guess that if both filetypes are present, the bmp one will be "preferred"? |
09:29:29 | Unhelpful | pixelma: actually, it looks for jpeg first |
09:30:01 | pixelma | aha, so no removing or renaming needed if I want to test jpg |
09:31:07 | Unhelpful | nope... until that revision, there is no check for jpeg on archos - without overlay, the jpeg decoder made the PF binary too large for the plugin buffer. |
09:50:47 | | Quit Thundercloud (Read error: 104 (Connection reset by peer)) |
10:00 |
10:05:55 | | Quit kachna|lappy (Read error: 113 (No route to host)) |
10:08:52 | | Quit _lifeless (Read error: 110 (Connection timed out)) |
10:11:51 | | Join pyro_maniac [0] (i=foobar@p57BBA2A0.dip0.t-ipconnect.de) |
10:15:40 | | Quit linuxstb (Read error: 113 (No route to host)) |
10:17:55 | | Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) |
10:22:27 | | Quit BHSPitMonkey ("Ex-Chat") |
10:32:20 | CIA-38 | New commit by unhelpful (r20866): Never use upscaling IDCT for luma (to reduce blockiness), plus some small size optimizations by not calculating or storing scale factors or ... |
10:37:05 | | Join _lifeless [0] (n=lifeless@188.16.83.142) |
10:39:38 | | Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) |
10:41:55 | *** | Saving seen data "./dancer.seen" |
10:58:37 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
10:59:40 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
11:00 |
11:03:56 | | Quit robin0800 (Client Quit) |
11:11:16 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
11:12:29 | | Quit Lss (Read error: 104 (Connection reset by peer)) |
11:13:02 | | Join kachna|lappy [0] (n=kachna@r3g248.net.upc.cz) |
11:13:28 | | Join Lss [0] (n=Lss@cm107.delta141.maxonline.com.sg) |
11:17:11 | | Quit rvvs89 (Read error: 104 (Connection reset by peer)) |
11:20:27 | Llorean | Can anyone think of a better name for "Anti-skip buffer" that might suggest you want it as _low_ as possible, since people seem to just guess at it? |
11:20:57 | Llorean | Or maybe it's even just an unnecessary setting that could be replaced with "Extra Skip Protection" (on/off) where one's a value of 0, and the other's maybe 15 seconds of skip protection? |
11:27:22 | | Quit thegeek (Read error: 104 (Connection reset by peer)) |
11:27:22 | | Quit killan (Read error: 104 (Connection reset by peer)) |
11:27:22 | | Quit flydutch (lindbohm.freenode.net irc.freenode.net) |
11:27:22 | NSplit | lindbohm.freenode.net irc.freenode.net |
11:27:22 | | Quit happosade (lindbohm.freenode.net irc.freenode.net) |
11:27:22 | | Quit dionoea (lindbohm.freenode.net irc.freenode.net) |
11:27:22 | | Join killan [0] (n=nnscript@c-5ef170d5.06-397-67626721.cust.bredbandsbolaget.se) |
11:27:22 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
11:27:34 | | Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) |
11:28:02 | | Quit Zambezi (Read error: 104 (Connection reset by peer)) |
11:28:14 | | Join Zambezi [0] (i=Zulu@bnc.dotbnc.se) |
11:28:14 | Torne | Llorean: are there any devices with so little ram for buffering that it's a noticable increase in power use to set it to 30 seconds or similar time? |
11:28:32 | | Quit _lifeless (Remote closed the connection) |
11:28:35 | Torne | Llorean: i guess you could always call it "jogger mode" :) |
11:28:40 | | Join _lifeless [0] (n=lifeless@188.16.83.142) |
11:29:09 | NHeal | lindbohm.freenode.net irc.freenode.net |
11:29:09 | NJoin | flydutch [0] (n=flydutch@host219-166-dynamic.15-87-r.retail.telecomitalia.it) |
11:29:09 | NJoin | happosade [0] (i=happosad@xob.kapsi.fi) |
11:29:09 | NJoin | dionoea [0] (n=dionoea@videolan/developer/dionoea) |
11:29:24 | | Quit Zambezi (SendQ exceeded) |
11:29:42 | | Quit J-23 ("ZNC - http://znc.sourceforge.net") |
11:29:49 | | Join J-23 [0] (n=zelazko@unix.net.pl) |
11:29:56 | Llorean | Torne: Yes, there are. |
11:30:09 | Torne | hmm. |
11:30:34 | Torne | at least on the more recent devices i can't imagine it would make a noticable difference to just set it permanently to 30s or similar, though |
11:31:08 | Torne | my ipod has a 59.5mb playback buffer :) |
11:31:28 | | Join Zambezi [0] (i=Zulu@bnc.dotbnc.se) |
11:31:48 | Llorean | 30 seconds of PCM is 5 megabytes. |
11:32:15 | Llorean | That means you could be using as much as 1/12 of your buffer or so. |
11:32:17 | Torne | ...it's not pcm though, is it? |
11:32:21 | Llorean | Much more on the traditional 32MB targets. |
11:32:24 | Torne | or do i not understand it either |
11:32:26 | Torne | :) |
11:32:27 | Llorean | It's whatever format you're playing. |
11:32:38 | Llorean | It's a faulty assumption to make that everyone will be listening to 128kbps MP3. |
11:32:50 | Llorean | Quite a few people with larger disk players at least use FLAC. |
11:33:13 | Llorean | So you need to look at it in the worst-case light if you're considering removing it as an option entirely. |
11:33:14 | Torne | yah.. |
11:33:30 | Torne | ok, that's a very good point :) |
11:33:32 | kugel | Unhelpful: "fix" propoerties on new files? |
11:33:54 | Torne | i think the on/off setting is a good direction, though |
11:34:03 | Unhelpful | kugel: as in, i forgot to set svn properties before committing them. :P |
11:34:04 | kugel | it seems your fix reset the history of pictureflow.c :/ |
11:34:04 | markun | or add malloc to rockbox and just allocate the skip buffer dynamically :P |
11:34:40 | Llorean | markun: That wouldn't solve the issue. :-p |
11:34:53 | kugel | Unhelpful: do you see what I mean? |
11:34:54 | Llorean | The issue is that people think it's setting the size of the compressed buffer, and set it to large values that destroy their battery life. |
11:35:15 | Llorean | Even if it malloced, it'd still have the same problem of users not reading what it does, and just guessing. |
11:35:24 | Torne | is it already configured out on flash targets, incidentally? |
11:35:26 | Llorean | The manual even explicitly says "you should set this as low as you can" |
11:35:41 | Llorean | Torne: Dunno, but it wouldn't matter even if it was. |
11:35:44 | Llorean | Or rather, even if it wasn't. |
11:36:23 | Unhelpful | kugel: the "old" pictureflow.c was moved into apps/plugins/pictureflow - the history should continue there. the pictureflow.c now in apps/plugins is just the overlay loader for archos targets, it doesn't *have* any history. |
11:37:02 | Torne | Llorean: anyway i think an on/off setting to pick between "reasonably big buffer that should work for jogging/etc" and "very small buffer that should work for most people" is probably a good plan ;) |
11:37:16 | kugel | Unhelpful: surely it has a history |
11:37:30 | kugel | the history of the old pictureflow.c |
11:37:50 | Unhelpful | kugel: it *shouldn't*, the one in apps/plugins/pictureflow should have that history. |
11:38:56 | Torne | Llorean: i had the same misunderstanding when i first installed rockbox and tried to think of a better way to describe it, and couldn't. |
11:39:27 | kugel | ah, I see the old one is still there |
11:39:46 | Unhelpful | http://svn.rockbox.org/viewvc.cgi/trunk/apps/plugins/pictureflow/pictureflow.c?view=log |
11:40:03 | kugel | eh, I really should look at the files before complaining :p |
11:40:21 | kugel | confusing filenames ftw! ;) |
11:40:50 | Unhelpful | the "new" apps/plugins/pictureflow.c is only a wrapper to load the "old" one, which is still there and still has its history. i couldn't figure out exactly how one builds an overlay plugin without using SUBDIRS and a new makefile... i suspect one can't. |
11:40:52 | Llorean | Torne: I really can't either unless we simplify it down to "Shake Protection: On/Off" and a note in the manual that simply says "This will make it less likely your MP3 player will skip if shaken, but may reduce your battery life depending on listening habits and file format." |
11:41:25 | Unhelpful | ...this is how every other plugin that uses an overlay loader works, except that the rest have more than one source file for the "real" plugin. |
11:42:00 | kugel | I see now how it works |
11:42:30 | | Quit timc (Remote closed the connection) |
11:43:17 | Torne | Llorean: if it did become a binary option you might call it "optimise for: longest battery life, best skip protection" |
11:43:20 | Torne | or similar |
11:43:40 | Torne | which would probably avoid a need to consult the manual |
11:45:58 | Torne | hm, actually at that point you might reasonably have more than two options (though not too manY) |
11:46:20 | Unhelpful | kugel: the trouble is that git can't manage svn properties, so what i did was move the file in an svn checkout, patch all of the changes, and then commit (but i managed to forget to set properties, anyway) |
11:46:20 | Torne | then it just becomes a problem of picking appropriate buffer sizes.. |
11:46:53 | | Join timc [0] (n=aoeu@116.3.196.121) |
11:47:27 | Unhelpful | svn apparently got confused about the overlay loader, which had the same patch as a file that had just been renamed... probably if i'd done a svn add for the overlay loader it would all have been fine :/ |
11:48:29 | Llorean | Torne: The problem with that is that they might expect it to do a lot more than it's doing |
11:48:41 | Torne | hmm |
11:48:45 | Llorean | Optimizing for better battery life seems like an option you'd expect to cascade down through the rest of the options and tweak 'em or something |
11:49:29 | * | Torne wonders how long an option can reasonably be and fit on the screen. |
11:50:06 | Torne | "Skip buffer size: small (better battery life), large (better skip protection)" :) |
11:50:14 | Unhelpful | that sounds good :) |
11:50:54 | Torne | the manual can explain in more detail exactly what the impact is |
11:52:34 | Llorean | I don't really know why it needs to communicate about the fact that it's manipulating a buffer though. |
11:52:52 | Llorean | It's information that can be in the manual, but doesn't actually help a user use the feature better. |
11:53:15 | Unhelpful | Llorean: to prevent exactly the confusion you mentioned, i'd think... so they don't think that it's going to go flipping lots of other switches. |
11:53:30 | Torne | yeah |
11:53:49 | Torne | i dunno, i'm just brainstorming :) |
11:55:01 | Llorean | Unhelpful: But a simpler name like "Shake Protection" with options "on/off" communicates basically the same thing. |
11:55:42 | Llorean | Without long names, or terms that may confuse users. |
11:55:58 | Unhelpful | fair enough. :) |
11:56:13 | Torne | if it's that simple, though, then there's no obvious reason to turn it *off* |
11:56:32 | Torne | that might be ok, if "on" refers to a short enough buffer that it's unlikely to murder people's batteries unless they play a lot of wav files |
11:57:03 | Llorean | There are plenty of options where there's no obvious reason to turn them "off" other than better battery life. |
11:57:29 | Llorean | The fact that they default to "Off" is, more or less, assumed to convey the message "this should be off unless you need it" about plenty of stuff |
11:57:50 | * | Torne nods |
11:57:55 | Llorean | The problem is people turning options on for reasons other than what they're used for because of bad names. |
11:58:01 | Torne | yah. |
11:58:09 | Torne | that does sound reasonable. |
11:58:24 | Torne | so it then becomes "how long should the buffer be for "on" and "off" :) |
11:58:31 | Llorean | Off should be 0. |
11:58:41 | Llorean | Assuming the watermarks are working well now. |
11:58:42 | Torne | ..really? |
11:58:46 | Llorean | Yup |
11:58:54 | Torne | i've had mine skip while sitting on a table with the buffer on 0 |
11:59:00 | Torne | though this was some time ago |
11:59:08 | Llorean | Yes, but that's bad math. |
11:59:12 | Llorean | The skip buffer shouldn't fix bad math. |
11:59:21 | Llorean | It's basically covering up an actual bug |
11:59:37 | Torne | oh, codecs not properly accounting for stuff |
11:59:48 | Torne | it may well have been fixed since i tried that |
11:59:56 | Torne | i experimented when i found the setting originally :) |
12:00 |
12:00:08 | Llorean | I think it's more that VBR can trick it into thinking X amount of audio is more time than it actually represents |
12:00:12 | Llorean | But I'm nto sure. |
12:00:26 | Torne | hm |
12:00:40 | Torne | well, 0 then. |
12:00:45 | Torne | but what about "on"? :0 |
12:01:04 | | Quit kugel (Read error: 110 (Connection timed out)) |
12:01:13 | Unhelpful | Llorean: perhaps some very basic bitstream parsing to see how many frames you've actually got would help, there? |
12:01:15 | Llorean | As for "On", I don't know |
12:01:27 | Llorean | I don't know enough about HD operation to know how hard it is to prevent them from reading for 10 seconds straight |
12:01:42 | Llorean | Unhelpful: Well, there can be issues like it being 3 seconds of MP3 and 2 seconds of FLAC, etc. |
12:02:12 | Torne | well, when i experimented with my ipodvideo listening to regular mp3s i found that i could get it to skip with a 15s buffer occasionally |
12:02:20 | Llorean | Unhelpful: I really don't know, it might be better resolved now. I know there was something done about the watermark semi-recently |
12:02:20 | Torne | say, by cycling with it in my pocket |
12:02:26 | Torne | i have it set to 30s atm |
12:02:32 | Torne | no idea of the general applicability :) |
12:02:45 | Unhelpful | Llorean: mean with watermark calculations - it should be possible for most codecs to get a very accurate estimate on how much audio data you have without fully decoding. |
12:02:52 | Unhelpful | *i* mean. :) |
12:03:25 | Llorean | Unhelpful: Well, considering my long MP3s regularly end with a time remaining of -5 minutes or so, if not more, this isn't always the case. :-P |
12:03:43 | Llorean | But across such short periods, it shouldn't be too bad (and we can always err on the side of safety) |
12:03:55 | Torne | yay mp3s with broken vbr data |
12:04:37 | Unhelpful | Torne: i think part of it has to do with the length, and the fact that the VBR data has a fixed number of seekpoints. :) |
12:04:50 | Llorean | Unhelpful: There was some talk of actually tracking the disk spinup times and seek times to start rebuffering so that it could even be self-calibrating. |
12:05:00 | Torne | that would be kinda cool |
12:05:14 | Torne | i suspect it varies across players perhaps quite dramatically |
12:05:18 | Torne | depending what kind of disk they use, at least |
12:05:35 | Torne | the disk might be more or less agressive about locking the heads down while under acceleration |
12:05:48 | Llorean | And people replace the disks in their players with ones that may be faster, or slower. And some people may have unusually fragmented disks. |
12:06:07 | Unhelpful | i'd imagine seek times can be considered neglible for that usage. spinup time will bury any other factor if we've let the disk stop. |
12:06:43 | * | Llorean wonders what spinup time is like in the iPod Mini. |
12:07:01 | pixelma | very short |
12:07:31 | Unhelpful | low moment of inertia? ;) |
12:07:35 | Torne | heh |
12:07:47 | Torne | ipodvideo takes a second or so at least even sitting on a table |
12:08:16 | Torne | the gap between feeling the disk move in your hand and seeing the buffering bar move in debug is quite noticable :) |
12:10:10 | pixelma | and it looks quicker than on the small H10 which has usually a microdrive too (on the Mini browsing without dircache wasn't annoying for me) |
12:17:11 | | Quit amiconn ("No Ping reply in 90 seconds.") |
12:17:44 | | Join amiconn [50] (n=jens@rockbox/developer/amiconn) |
12:22:24 | | Join serenity [0] (n=serenity@p4FC6B96E.dip0.t-ipconnect.de) |
12:28:56 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
12:29:13 | | Quit robin0800 ("Ex-Chat") |
12:29:32 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
12:41:57 | *** | Saving seen data "./dancer.seen" |
12:54:52 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
13:00 |
13:03:41 | | Part serenity ("Konversation terminated!") |
13:04:55 | Bagder | http://daniel.haxx.se/blog/2009/05/07/video-how-to-build-rockbox/ |
13:08:50 | | Join midijunkie [0] (n=Miranda@eduroam-196-36.uni-paderborn.de) |
13:16:59 | | Quit kugel (Read error: 110 (Connection timed out)) |
13:32:56 | | Join Strife89 [0] (n=michael@204.116.244.200) |
13:46:03 | | Quit fyrestorm ("lamers envy me like they envy bill g -- main boot xp, just the way it should be!") |
13:52:10 | | Join evilnick [0] (i=ad348c4b@gateway/web/ajax/mibbit.com/x-c8c9bfffd7a21dc7) |
14:00 |
14:00:22 | | Quit midijunkie ("?(???~•~)?") |
14:02:17 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
14:05:53 | | Join midijunkie [0] (n=Miranda@eduroam-196-36.uni-paderborn.de) |
14:11:50 | | Join schrottplatz [0] (n=max@f053226099.adsl.alicedsl.de) |
14:14:43 | | Quit midijunkie ("?(???~•~)?") |
14:18:15 | | Join bob70 [0] (n=d8f6ed1f@gateway/web/cgi-irc/labb.contactor.se/x-55aa7b81d5f87e7f) |
14:20:06 | MarcGuay | mcuelenaere, anyone else: If I wanted to contribute to the Rockbox API documentation, how would I do so? http://mcuelenaere.alwaysdata.net/rockbox_api_example_3/ |
14:21:07 | MarcGuay | I've been figuring it out Mcguyver-style (creative searching, looking at other people's uses) but it would really be easier if it was documented better. |
14:21:08 | | Quit bob70 (Client Quit) |
14:21:24 | | Quit Strife89 ("Huzzah!") |
14:23:23 | | Quit evilnick ("http://www.mibbit.com ajax IRC Client") |
14:28:51 | | Join LambdaCalculus37 [0] (i=44a0430d@rockbox/staff/LambdaCalculus37) |
14:42:01 | *** | Saving seen data "./dancer.seen" |
14:45:30 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
14:50:12 | | Join midijunkie [0] (n=Miranda@eduroam-196-36.uni-paderborn.de) |
14:50:45 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
14:51:25 | | Join Rob2222 [0] (n=Miranda@p4FDCD123.dip.t-dialin.net) |
14:52:34 | | Quit _lifeless (Remote closed the connection) |
14:52:50 | | Join _lifeless [0] (n=lifeless@188.16.115.127) |
15:00 |
15:00:38 | amiconn | Llorean: Spinup time is about 500ms for the Mini's microdrive |
15:01:08 | amiconn | The small H10 has about 2.5sec spinup time - same as 1.8" hdd targets |
15:01:36 | amiconn | The fast one is made by Hitachi, the slow one is made by Seagate |
15:08:14 | | Quit Horscht ("Verlassend") |
15:09:53 | | Quit midijunkie (Read error: 104 (Connection reset by peer)) |
15:13:54 | | Join rvvs89 [0] (n=ivo@pdpc/supporter/base/rvvs89) |
15:14:52 | | Quit kachna|lappy (Read error: 110 (Connection timed out)) |
15:15:14 | | Quit schrottplatz (Remote closed the connection) |
15:15:28 | | Join schrottplatz [0] (n=max@f053226099.adsl.alicedsl.de) |
15:18:24 | | Join CaptainKewl [0] (i=jds@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) |
15:32:49 | | Quit martian67 (lindbohm.freenode.net irc.freenode.net) |
15:32:49 | NSplit | lindbohm.freenode.net irc.freenode.net |
15:32:49 | | Quit amiconn (lindbohm.freenode.net irc.freenode.net) |
15:32:49 | | Quit J-23 (lindbohm.freenode.net irc.freenode.net) |
15:32:49 | | Quit n1s (lindbohm.freenode.net irc.freenode.net) |
15:32:49 | | Quit KBH (lindbohm.freenode.net irc.freenode.net) |
15:32:49 | | Quit pixelma (lindbohm.freenode.net irc.freenode.net) |
15:32:49 | | Quit crashd (lindbohm.freenode.net irc.freenode.net) |
15:32:49 | | Quit webmind (lindbohm.freenode.net irc.freenode.net) |
15:32:49 | | Quit avacore (lindbohm.freenode.net irc.freenode.net) |
15:32:56 | NHeal | lindbohm.freenode.net irc.freenode.net |
15:32:56 | NJoin | amiconn [50] (n=jens@rockbox/developer/amiconn) |
15:32:56 | NJoin | J-23 [0] (n=zelazko@unix.net.pl) |
15:32:56 | NJoin | n1s [0] (n=n1s@rockbox/developer/n1s) |
15:32:56 | NJoin | KBH [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
15:32:56 | NJoin | pixelma [50] (n=pixelma@rockbox/staff/pixelma) |
15:32:56 | NJoin | martian67 [0] (n=martian6@about/linux/regular/martian67) |
15:32:56 | NJoin | avacore [0] (i=nobody@1008ds1-rdo.0.fullrate.dk) |
15:32:56 | NJoin | crashd [0] (i=foobar@lostnode.org) |
15:32:56 | NJoin | webmind [0] (n=webmind@shell.puscii.nl) |
15:33:41 | | Part LinusN |
15:34:06 | | Quit martian67 (SendQ exceeded) |
15:35:02 | | Join martian67 [0] (n=martian6@about/linux/regular/martian67) |
15:36:11 | | Quit bmbl (Connection timed out) |
15:43:15 | | Quit killan (Read error: 104 (Connection reset by peer)) |
15:43:16 | | Join killan_ [0] (n=nnscript@c-5ef170d5.06-397-67626721.cust.bredbandsbolaget.se) |
15:48:22 | | Join rastapizza [0] (n=c1335ac7@gateway/web/cgi-irc/labb.contactor.se/x-ca425ebe3b605f17) |
15:48:46 | | Quit thegeek (Read error: 104 (Connection reset by peer)) |
15:50:25 | rastapizza | Hi, im searching for informations about sansa v2 |
15:50:30 | rastapizza | Is it possible to use the sansapatcher to install a fresh svn compilation with rockbox and booloader ? |
15:50:50 | n1s | not sansapatcher, you need a different tool |
15:50:58 | n1s | and it's not ready for general use yet |
15:51:01 | rastapizza | wich one please ? |
15:51:03 | | Join {phoenix} [0] (n=dirk@p54B47B7F.dip.t-dialin.net) |
15:52:04 | | Join itcheg [0] (i=41d59de2@gateway/web/ajax/mibbit.com/x-5801bff4b24bc23d) |
15:52:42 | rastapizza | wich too do i have to use to proceed ? |
15:52:55 | rastapizza | too -> tool |
15:52:55 | n1s | i think this page has all the info on the various newer sansa ports http://www.rockbox.org/twiki/bin/view/Main/SansaAMS |
15:53:24 | n1s | you need to compile the tool yourself |
15:53:37 | rastapizza | Big thanks, i missed this part |
15:59:34 | | Join grdxyxy [0] (n=chen@119.123.212.200) |
16:00 |
16:00:22 | | Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) |
16:00:23 | | Quit rastapizza ("CGI:IRC (EOF)") |
16:05:46 | CIA-38 | New commit by mcuelenaere (r20867): Jz4732: add hack to fix stack overflow in the power thread (fixes USB on non-bootloader) |
16:08:49 | | Quit timc (Read error: 110 (Connection timed out)) |
16:10:34 | | Quit CaptainKewl (Read error: 110 (Connection timed out)) |
16:11:05 | | Quit Chex ("restart irssi, brb") |
16:11:19 | | Join Chex [0] (n=Stefan@bas1-montreal48-1176430935.dsl.bell.ca) |
16:12:30 | | Join timc [0] (n=aoeu@221.201.144.130) |
16:13:55 | | Quit Zagor ("Don't panic") |
16:16:24 | | Join jgarvey [0] (n=jgarvey@98.26.65.13) |
16:19:09 | | Join renke [0] (n=renke@p4FF17DC3.dip.t-dialin.net) |
16:19:09 | | Quit mcuelenaere (Read error: 104 (Connection reset by peer)) |
16:19:48 | | Quit grdxyxy ("Leaving.") |
16:21:27 | | Join mcuelenaere [0] (n=mcuelena@78-22-182-102.access.telenet.be) |
16:21:52 | mcuelenaere | MarcGuay: the tool to generate the API documentation needs to be rewritten |
16:22:22 | mcuelenaere | but basically, everything (currently) is in http://svn.rockbox.org/viewvc.cgi/trunk/docs/PLUGIN_API.new?view=markup |
16:26:34 | | Join fyrestorm [0] (n=nnscript@cpe-24-90-84-236.nyc.res.rr.com) |
16:32:30 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
16:33:11 | MarcGuay | mcuelenaere: thanks, i'll take a look.. |
16:34:07 | mcuelenaere | that link contains the actual documentation, the generator is in utils/plugin_api_somewhere |
16:34:28 | mcuelenaere | http://svn.rockbox.org/viewvc.cgi/trunk/utils/rockbox_api/ |
16:34:28 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
16:38:59 | | Join midijunkie [0] (n=Miranda@pD95472CD.dip0.t-ipconnect.de) |
16:42:03 | *** | Saving seen data "./dancer.seen" |
16:43:05 | | Quit ajb (Remote closed the connection) |
16:44:33 | | Join SirFunk__ [0] (n=Sir@208-15-25-145.netsync.net) |
16:45:46 | CIA-38 | New commit by MarcGuay (r20868): Documentation for pcm_play_data() API function. Info taken from http://www.rockbox.org/mail/archive/rockbox-dev-archive-2008-07/0059.shtml. |
16:46:32 | mcuelenaere | MarcGuay: currently the plugin documentation isn't generated |
16:46:37 | mcuelenaere | publicly |
16:47:04 | MarcGuay | It's unfortunate. I'm looking at your website... |
16:47:05 | evilnick_7 | That link doesn't work because of the period after shtml |
16:47:27 | MarcGuay | evilnick_7: Proper English loses again. |
16:47:49 | Llorean | evilnick_7: That's a bug in your IRC client. :-P |
16:48:01 | | Quit {phoenix} (Remote closed the connection) |
16:48:07 | * | evilnick_7 wouldn't be surprised if it were mibbit or IE |
16:49:05 | | Join toffe82 [0] (n=chatzill@74.0.180.178) |
16:57:43 | | Quit SirFunk_ (Connection timed out) |
17:00 |
17:01:21 | | Join killan [0] (n=nnscript@c-5ef170d5.06-397-67626721.cust.bredbandsbolaget.se) |
17:02:38 | | Quit killan_ (Read error: 104 (Connection reset by peer)) |
17:05:21 | | Join Zambezi_ [0] (i=Zulu@bnc.dotbnc.se) |
17:05:40 | | Quit Zambezi (Read error: 104 (Connection reset by peer)) |
17:10:38 | | Join jmillikin [0] (n=jmilliki@c-24-130-159-24.hsd1.ca.comcast.net) |
17:11:05 | | Quit gevaerts (Nick collision from services.) |
17:11:16 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
17:15:28 | | Quit SirFunk__ (Read error: 110 (Connection timed out)) |
17:15:32 | | Join udzguru [0] (n=udzguru@dslb-088-064-075-123.pools.arcor-ip.net) |
17:16:04 | | Join SirFunk__ [0] (n=Sir@208-15-25-145.netsync.net) |
17:16:10 | udzguru | i got a question regarding rockbox 3.2 on a sansa e200 series player |
17:16:17 | udzguru | anyone can help me? |
17:16:28 | n1s | ask away |
17:16:54 | udzguru | ok ... is there a possibility to include the tracks on a inserted micro sd card directly into the rockbox database |
17:16:56 | udzguru | ? |
17:17:26 | evilnick_7 | udzguru: Yes, you should be able to Update the database and it will scan the card |
17:19:18 | udzguru | i just did that and the tracks on the sd card don't show up in the database. i can only access those tracks via browsing the files and navigating to the micro sd. but then it only plays the files on the micro sd but not the ones on the internal memory |
17:19:33 | udzguru | i just updated to 3.2 and after the restart it did rebuild the database (booted with the micro sd inserted) |
17:22:53 | udzguru | ok ok .. i just rebuilt the database another time and now it seems to work :D |
17:23:45 | udzguru | thanks for your help folk |
17:24:02 | udzguru | gotta leave now and make something to eat. good bye and take care |
17:24:05 | | Quit udzguru () |
17:29:44 | mt- | When including headers from /usr/include/ , should I #include "/user/include/filename.h" or just #include <filename.h> ? |
17:31:36 | | Quit matsl (Read error: 110 (Connection timed out)) |
17:34:47 | mt- | saratoga : ^ |
17:36:16 | | Join wincent [0] (n=wincent@dyndsl-091-096-000-117.ewe-ip-backbone.de) |
17:37:16 | saratoga | mt: this is for your rmdec program? |
17:38:14 | mt- | saratoga : yes .. I'm trying to get librm compiled within a rockbox compilation |
17:39:42 | | Quit midijunkie (Read error: 104 (Connection reset by peer)) |
17:40:26 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
17:42:55 | saratoga | mt: in rockbox you don't have access to those include files |
17:43:16 | saratoga | you just have the stuff in codec.h, codeclib.h, etc |
17:45:20 | | Quit MarcGuay (Read error: 104 (Connection reset by peer)) |
17:45:38 | mt- | sorry, I meant firmware/include .. not usr/include. |
17:46:07 | saratoga | ah ok |
17:46:08 | mt- | saratoga : libffmpegFLAC's decoder.c includes <inttypes.h> for example. |
17:46:30 | mt- | I have access to those inside firmware/include, right ? |
17:46:34 | saratoga | i think you should be able to <> include them |
17:46:46 | saratoga | let me check what the make file thinks |
17:46:57 | n1s | several rockbox files do #include <inttypes.h> |
17:49:02 | saratoga | inttypes is quite useful since we have 64 bit sims and 32 bit targets |
17:50:50 | saratoga | hmm i'm not really sure where we set all the includes for the codecs |
17:50:56 | mt- | I think inttypes should be included instead of stdint.h , right ? (especially since there's no stdint.h in /include :) ) |
17:53:05 | saratoga | yes |
17:59:33 | linuxstb | mt-: What is the "patch" file in your latest patch? |
18:00 |
18:00:10 | mt- | linuxstb : a mistake (I was diffing inside librm directory) :/ |
18:00:25 | linuxstb | mt-: Also, you should create patches for Rockbox from the top-level directory - so files contain paths such as apps/codecs/librm/filename.c |
18:01:20 | mt- | ok |
18:02:15 | linuxstb | Also, I wouldn't commit it all as "librm" - I would have one lib for the parser (called librm), and one lib for each codec - libcook etc. i.e. the same way as the mp4 parser and ALAC/AAC codecs. |
18:03:25 | | Quit petur ("work->home") |
18:03:28 | linuxstb | I'm also a bit worried you're going too fast without having a patch committed - i.e. it would have been nice to have the history of your changes, starting with the original files from ffmpeg. |
18:04:50 | mt- | linuxstb : ok .. I will separate cook/rm .. I'll just try to get them compiled with rockbox headers first. |
18:05:44 | linuxstb | Final comment - you should add a "README.rockbox" file describing the code - see the other codecs for examples. |
18:06:15 | | Quit robin0800 ("Ex-Chat") |
18:07:26 | Torne | linuxstb: have uploaded a new version of my ipod bootloader patch which includes a large comment explaining the boot process ;) |
18:07:34 | Torne | still not sure if we would want to put it in the manual or not |
18:07:51 | mt- | linuxstb : I still have most of my old files .. a history of the changes is still possible. Though, if the patch is committed it will add thousands of unrelated lines of code to the history (this was saratoga's concern about committing the patc before cleaning the code) |
18:07:54 | Torne | well, not the same text because it's rather technical, but a more accessible description of the install method |
18:10:06 | | Quit flydutch ("/* empty */") |
18:10:24 | | Quit renke (Read error: 110 (Connection timed out)) |
18:11:24 | linuxstb | mt-: I don't see that as a problem - that's what SVN is for. But at least I think the first commit should be the original floating point code, not the fixed-point version. |
18:12:56 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
18:14:18 | linuxstb | Torne: My view is that we shouldn't document this in the manual - it's not significant enough to be worth the hassle of users trying to do it and breaking things. But maybe the IpodPatcher wiki page would be the place to do it. |
18:14:29 | mt- | linuxstb : ok, the floating point code is still available too. But just to make sure I'm following, do you mean making a dir. inside rockbox with the old floating-point program and then making a patch, similar to the one on FS now ? |
18:14:57 | Torne | linuxstb: *nod* |
18:15:15 | Torne | linuxstb: does the comment i added to ipod.c look reasonable, as technical docs for people actually loking in the bootloader code, anyway? |
18:15:51 | markun | mt-: you can also start using git and the commit in your local tree every time you have made some important changes |
18:16:00 | markun | the -> then |
18:16:16 | Torne | or bzr, if like me you find git incomprehensible ;) |
18:16:17 | | Quit parafin (Read error: 110 (Connection timed out)) |
18:17:26 | Torne | though i then ruin it by using bzr-loom on top to maintain stacked patch branches, which makes it all very bizarre again. but hey. i'm used to it ;) |
18:17:38 | mt- | markun : ok, I will try it . (never used git before ..) |
18:18:19 | markun | it's not the only option of course, but it works for me |
18:19:32 | markun | mt-: http://www.rockbox.org/twiki/bin/view/Main/GitVersionControl#The_public_Rockbox_git_repositor |
18:19:52 | Torne | that would be the big advantage of git over bzr here :) |
18:20:06 | Torne | since branching the rockbox svn into a bzr repo yourself takes like, several hours |
18:20:06 | linuxstb | mt-: Yes, I mean the first commit should be as close to ffmpeg as possible. Then another patch to convert to fixed point - so the history of your changes are in our SVN. |
18:20:30 | mt- | markun : thanks :) |
18:20:53 | saratoga | linuxstb: I didn't think we should commit unrelated ffmpeg files though, like dsputil for instance |
18:24:48 | | Join MarcGuay [0] (n=chatzill@ip216-239-81-20.vif.net) |
18:25:48 | mt- | linuxstb , saratoga : so the patches would be : 1. floating point rm-wav converter (first 'correct' program) , 2. fixed pointed converter , 3. cleaned up fixed point converter , 4. separate dirs for rm and cook ? |
18:25:52 | linuxstb | saratoga: I don't see the harm. The benefit is that we can all see the changes mt made compared to ffmpeg. |
18:27:36 | mt- | linuxstb : there would be some issues with ffmpeg files, most of the files will have (#if 0 .. #endif) .. i.e no deleted code, just disabled, would this be a problem ? |
18:27:54 | | Join faemir [0] (n=faemir@88-106-242-222.dynamic.dsl.as9105.com) |
18:31:42 | | Join parafin [0] (n=operator@paraf.in) |
18:33:51 | | Quit parafin (Client Quit) |
18:33:54 | | Join parafin [0] (i=parafin@paraf.in) |
18:38:03 | linuxstb | mt-: I think that's fine for now, but you may want to delete that code in the future, to make it easier to work with. |
18:38:26 | mt- | linuxstb : no I meant in the old patches |
18:38:52 | mt- | The current code contains no such switches. |
18:39:15 | linuxstb | So you mean patches 1 and 2 will use "#if 0" ? |
18:39:39 | mt- | yes |
18:39:56 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
18:41:07 | linuxstb | That sounds fine. |
18:41:50 | LambdaCalculus37 | saratoga: First test: sent a Gigabeat T firmware patched with the beast bootloader using sendfirm. The Beatt accepted it, but still goes into recovery mode. |
18:42:04 | *** | Saving seen data "./dancer.seen" |
18:42:23 | mt- | linuxstb : one final question : first 3 patches will all be a librm dir inside apps/codecs, ok ? |
18:42:32 | | Join miepchen^schlaf [0] (n=miepel@p579EC6CE.dip.t-dialin.net) |
18:43:16 | linuxstb | mt-: I would call it "libcook", as that's what most of the code is for. You can then move the rm parser somewhere else later. |
18:43:41 | | Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) |
18:44:26 | mt- | linuxstb : fine. When I'm done with the patches I'll add them to FS #10182. |
18:44:35 | mt- | unless a new task is preferable. |
18:45:04 | | Part pyro_maniac ("Leaving.") |
18:45:25 | LambdaCalculus37 | Going to try a vanilla S firmware now. |
18:46:12 | linuxstb | mt-: I don't know... Keeping them all in the same task is probably easiest though. |
18:46:18 | LambdaCalculus37 | Also accepted, but it does nothing but recovery mode again. |
18:46:58 | mt- | yes, they'll all be in FS #10182, or all 4 in a new task. That's what I meant :) |
18:50:00 | | Join JdGordon| [0] (i=836b0070@gateway/web/ajax/mibbit.com/x-5c5f2b6c461d02e7) |
18:52:13 | LambdaCalculus37 | Let's see what a patched S firmware does. |
18:53:54 | LambdaCalculus37 | Gah, recovery mode again. :/ |
18:56:59 | | Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) |
18:57:09 | | Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") |
18:57:55 | MarcGuay | Could someone advise me on how to pass a concatonated string to the rb->open() function. I have a predefined path (./rockbox/rocks/whatever) as a char *PATH variable and want to append various filenames to the end of it. I tried rb->strcat (PATH, "test1") with no success... |
18:58:25 | MarcGuay | Perhaps there's a better way to define my root dir? |
18:58:43 | | Join LambdaCalculus37 [0] (i=44a0430d@rockbox/staff/LambdaCalculus37) |
18:59:27 | MarcGuay | Ideally I'd like to opendir(), readdir(), and just open the files that have a particular file ext. |
18:59:41 | linuxstb | MarcGuay: You probably need to create a new string containing the full path - e.g. using snprintf() |
18:59:59 | MarcGuay | I see. |
19:00 |
19:00:51 | | Join SirFunk_ [0] (n=Sir@208.15.25.145) |
19:00:57 | MarcGuay | I think that strcat returns the same varialble type (char*) so I'm not sure if that would make a difference... |
19:01:39 | MarcGuay | I'll try again. |
19:01:57 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
19:02:06 | LambdaCalculus37 | Hmmm... |
19:03:07 | mcuelenaere | MarcGuay: is this PATH big enough to contain both ./rockbox/rocks/whatever and test1? |
19:04:10 | domonoky | MarcGuay: for strcat, destination needs to be a buffer, big enough for both strings. So it wont work if you define your base path as a constant. |
19:04:24 | linuxstb | MarcGuay: Also, Rockbox coding guidelines say that variables should be lower-case. Upper-case is reserved for pre-processor symbols (i.e. #defines) |
19:06:20 | MarcGuay | Thanks guys. |
19:10:14 | MarcGuay | Working nicely. Problem was somewhere else (naturally). char *filepath = strcat (rootpath, "test1.wav"); rb->open(filepath, etc) worked fine. |
19:13:50 | | Quit SirFunk__ (Read error: 110 (Connection timed out)) |
19:14:05 | | Quit schrottplatz ("o.O") |
19:14:58 | | Quit fyrestorm (Read error: 104 (Connection reset by peer)) |
19:17:53 | | Join SirFunk__ [0] (n=Sir@208-15-25-145.netsync.net) |
19:17:57 | linuxstb | MarcGuay: That will add "test1.wav" to the end of rootpath. filepath is simply set to point to rootpath. |
19:21:52 | | Quit SirFunk_ (Read error: 145 (Connection timed out)) |
19:23:28 | | Join amiconn_ [0] (n=jens@p54BD360D.dip.t-dialin.net) |
19:28:45 | MarcGuay | linuxstb: It seems to return the concatonated string. |
19:32:32 | MarcGuay | But it modifies my rootpath variable which isn't ideal.. |
19:32:49 | MarcGuay | Or maybe not? |
19:33:40 | mcuelenaere | MarcGuay: it does modify your rootpath variable |
19:33:45 | mcuelenaere | http://www.cplusplus.com/reference/clibrary/cstring/strcat/ |
19:34:43 | mcuelenaere | and like linuxstb recommended, try using snprintf(); that way you're sure you won't be overwriting any other data in memory |
19:35:22 | | Join grusl [0] (n=sssqdd@pD9E1B5EE.dip.t-dialin.net) |
19:35:30 | MarcGuay | Thanks again. |
19:35:47 | grusl | can i use rockbox with ainol V2000SE ? |
19:35:52 | BigBambi | no |
19:36:10 | BigBambi | The players that Rockbox works on are listed on www.rockbox.org |
19:36:20 | grusl | yeah |
19:36:32 | grusl | ok hanks |
19:36:34 | grusl | thanks |
19:36:37 | BigBambi | np |
19:36:41 | | Part grusl |
19:36:45 | mcuelenaere | grusl: the V2000SE has a Jz4740 chipset (which is .. bah |
19:36:46 | | Join midijunkie [0] (n=Miranda@pD95472CD.dip0.t-ipconnect.de) |
19:36:52 | * | mcuelenaere too slow |
19:41:33 | mt- | linuxstb : patches 1-3 are on FS #10182 now. |
19:43:34 | | Quit amiconn_ (" HydraIRC -> http://www.hydrairc.com <- Now with extra fish!") |
19:44:48 | | Join Zarggg_ [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
19:46:43 | mt- | linuxstb : as for the README , I didn't write it yet, but it should be included in patch4 when it's ready. |
19:48:55 | mt- | linuxstb : did FS not show the files in the patch because I added them all to one comment ? |
19:50:05 | BigBambi | mt-: I see them there |
19:50:28 | BigBambi | there is libcook.patch1 .patch2 and .patch3 right? |
19:50:38 | | Quit Zarggg_ () |
19:50:47 | BigBambi | mt-: er, ignore me - I see what you mean now :) |
19:54:08 | mt- | :) |
20:00 |
20:00:56 | | Join fyrestorm [0] (n=nnscript@cpe-24-90-84-236.nyc.res.rr.com) |
20:02:17 | | Quit Zarggg (Read error: 113 (No route to host)) |
20:03:14 | | Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
20:04:45 | | Quit midijunkie (Read error: 54 (Connection reset by peer)) |
20:06:14 | | Join petur [50] (n=petur@rockbox/developer/petur) |
20:06:56 | | Join Seed [0] (n=ben@84.108.232.45) |
20:11:40 | | Join midijunkie [0] (n=Miranda@pD95472CD.dip0.t-ipconnect.de) |
20:16:22 | | Quit fyrestorm (Read error: 104 (Connection reset by peer)) |
20:17:53 | | Quit midijunkie (Read error: 104 (Connection reset by peer)) |
20:20:15 | | Join midijunkie [0] (n=Miranda@pD95472CD.dip0.t-ipconnect.de) |
20:21:49 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
20:22:14 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
20:22:16 | | Quit mcuelenaere (Nick collision from services.) |
20:27:57 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
20:32:11 | | Join pyro_maniac [0] (n=jens@91-64-227-210-dynip.superkabel.de) |
20:41:35 | | Quit midijunkie ("?(???~•~)?") |
20:42:08 | *** | Saving seen data "./dancer.seen" |
20:42:14 | | Join midijunkie [0] (n=Miranda@pD95472CD.dip0.t-ipconnect.de) |
20:45:03 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
20:47:53 | | Quit Thundercloud (Remote closed the connection) |
20:52:07 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
20:57:18 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
21:00 |
21:05:36 | | Join renke [0] (n=renke@p4FF159C7.dip.t-dialin.net) |
21:13:15 | | Quit linuxstb (Read error: 113 (No route to host)) |
21:14:32 | | Quit Horscht ("Verlassend") |
21:14:32 | | Join fyrestorm [0] (n=nnscript@cpe-24-90-84-236.nyc.res.rr.com) |
21:22:00 | | Join {phoenix} [0] (n=dirk@p54B47B7F.dip.t-dialin.net) |
21:24:33 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
21:24:56 | | Join itcheg [0] (i=41d59de2@gateway/web/ajax/mibbit.com/x-c4abf3a0c8a53c42) |
21:37:26 | | Nick Zambezi_ is now known as Zambezi (i=Zulu@bnc.dotbnc.se) |
21:39:35 | | Quit intrados (Read error: 54 (Connection reset by peer)) |
21:40:53 | | Join intrados [0] (n=intrados@cpe-71-67-129-220.woh.res.rr.com) |
21:45:24 | | Join DarkWizdom [0] (n=t_chichu@93.188.9.34) |
21:46:01 | | Quit intrados (SendQ exceeded) |
21:49:01 | | Join intrados [0] (n=intrados@cpe-71-67-129-220.woh.res.rr.com) |
21:52:32 | | Quit fyrestorm (Read error: 104 (Connection reset by peer)) |
21:53:36 | | Join perrikwp [0] (i=18ac0c41@64.62.228.82) |
21:53:40 | | Join Jaykay [0] (n=chatzill@p579E7051.dip.t-dialin.net) |
21:57:58 | | Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
21:58:59 | | Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") |
22:00 |
22:05:48 | | Join froggyman [0] (n=47ba40e2@gateway/web/cgi-irc/labb.contactor.se/x-ff5792bbbd683fc4) |
22:06:16 | | Part DarkWizdom |
22:11:55 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
22:16:30 | | Quit Xerion (" ") |
22:24:45 | | Quit {phoenix} (Remote closed the connection) |
22:30:47 | | Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) |
22:39:35 | | Join taylor_ [0] (n=taylor@c-24-91-82-205.hsd1.ma.comcast.net) |
22:39:42 | taylor_ | Hello, Everyone. |
22:42:02 | LambdaCalculus37 | I just added the Sansa m200 to the list of players in tcctool. As the c100 option worked right off the bat for the m200, I just copied and changed the name. |
22:42:11 | *** | Saving seen data "./dancer.seen" |
22:44:28 | taylor_ | Any luck with the Sansa fuzes? Or are they still pretty unstable? |
22:44:29 | LambdaCalculus37 | Any objections to committing the change? |
22:45:14 | | Quit SirFunk__ (Read error: 110 (Connection timed out)) |
22:46:01 | | Join SirFunk__ [0] (n=Sir@208-15-25-145.netsync.net) |
22:46:03 | | Join schrottplatz [0] (n=max@f053226099.adsl.alicedsl.de) |
22:46:58 | | Join Jaykay_ [0] (n=chatzill@p579E6B86.dip.t-dialin.net) |
22:47:41 | LambdaCalculus37 | No objections? Going once... twice... |
22:47:58 | LambdaCalculus37 | In it goes. |
22:48:41 | JdGordon| | noooooooooooooooo! |
22:48:49 | taylor_ | haha |
22:49:06 | CIA-38 | New commit by rmenes (r20869): Add the Sansa m200 to tcctool. |
22:49:50 | LambdaCalculus37 | JdGordon| Too late! I hit the History Eraser Button! :) |
22:50:03 | * | LambdaCalculus37 blinks the SVN trunk out of existence :P |
22:50:37 | | Quit Makuseru (Read error: 104 (Connection reset by peer)) |
22:50:40 | | Part taylor_ ("Leaving") |
22:50:49 | | Join taylor_ [0] (n=taylor@c-24-91-82-205.hsd1.ma.comcast.net) |
22:51:24 | | Part taylor_ ("Leaving") |
22:53:44 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
22:54:23 | kugel | grrrrrrml, my custom list patch reveals so nasty assumptions/problems in rockbox :S |
22:56:40 | JdGordon| | good... go fix them :) |
22:56:58 | JdGordon| | we always knew about them though... |
22:57:54 | kugel | splash is pretty broken if you stop using fullscreen |
22:58:01 | JdGordon| | kugel: feel like working on something related, but different? Can you copy the statusbar setting to a new one for the remote so they can be disabled seperatly bu the user? |
22:58:21 | JdGordon| | splash should override custom viewport i think |
22:58:32 | kugel | I can fix those which call splash/f with non-zero ticks easily, but not those calls with 0 zicks |
22:59:21 | kugel | sure, that's what I'm doing. but the zero tick splashes expect to be shown, well, forever. And they of course leave dead parts on the screen |
23:00 |
23:00:13 | JdGordon| | thats not what 0 means :) |
23:00:21 | JdGordon| | but yeah, i can see your problem |
23:01:17 | | Quit petur (Remote closed the connection) |
23:03:23 | | Quit Zagor ("Clint excited") |
23:03:51 | | Quit wincent (Connection timed out) |
23:04:09 | | Quit Jaykay (Read error: 110 (Connection timed out)) |
23:05:22 | | Quit kugel (Nick collision from services.) |
23:05:26 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
23:06:10 | kugel | JdGordon|: 0 means don't sleep (i.e. don't yield() ), I know. But if I cleanup a |
23:06:12 | kugel | after 0 ticks, guess what happens :) |
23:06:35 | JdGordon| | right, I know... i was just saying 0 doesnt mean show forever... |
23:07:13 | kugel | that doesn't make it easier |
23:07:36 | kugel | JdGordon|: the statusbar think should be rather trivial I think. just c&p the setting and work a bit more on viewportifying |
23:07:46 | JdGordon| | *maybe* we could add a function clean_us_splashes() or something to be called when the loop doing the 0tick splashes finishes |
23:07:48 | kugel | I solved the set_int thing btw |
23:08:17 | JdGordon| | yeah, i know the stautsbar bit is trivial, its just I havnt got round to doing it so was hoping you might like to do it for us? :) |
23:08:22 | JdGordon| | the mr500 port needs it |
23:08:27 | kugel | JdGordon|: That's what I thought of too. However, that of course means remembering the viewport (I converted splashes to viewports), i.e. each for a screen and not on the stack anymore |
23:08:31 | amiconn | The assumptions aren't nasty, they are vaild for current rockbox |
23:09:10 | kugel | 1 for each screen* |
23:09:26 | JdGordon| | kugel: well no.. all thats needed is for the whole screen to be redrawn.. nothing needs to be remembered |
23:09:51 | JdGordon| | which is going to be just the backdrop, and then the current screen's viewport |
23:10:01 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
23:10:10 | kugel | I'd rather make a static viewport[NB_SCREENS] than clearing and updating the whole screen |
23:10:30 | JdGordon| | and how would that help? |
23:11:08 | kugel | it would be accessible in a cleanup_after_splash() or in the next splash()? |
23:11:52 | JdGordon| | which in effect you end up doing the same thing... clearing the viewport and then requiring the actual screen be redrawn |
23:12:16 | kugel | clearing the whole screen is broken anyway. You need to make sure the list or whatever is *immediately* redrawn after to avoid noticeable flickering |
23:12:18 | | Quit domonoky (Read error: 104 (Connection reset by peer)) |
23:12:40 | kugel | clearing viewport != clearing screen though |
23:12:59 | JdGordon| | clear the screen and not update it will be the same |
23:13:06 | kugel | particularly statusbar flickering |
23:13:13 | JdGordon| | it will be updated when the ui loop gets aroudn to it |
23:13:19 | | Join barrywardell [0] (n=barry@barry-workstation.ucd.ie) |
23:13:35 | kugel | lists only update the viewport they're drawn into |
23:13:54 | kugel | the whole screen is nearly never updated, which is sensible |
23:13:58 | | Join fyrestorm [0] (n=nnscript@cpe-24-90-84-236.nyc.res.rr.com) |
23:14:16 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
23:14:23 | kugel | just clearing the screen and wait for the lists leaves the same dead parts as doing nothing |
23:15:44 | | Quit fyrestorm (Read error: 104 (Connection reset by peer)) |
23:15:50 | JdGordon| | we can add stuff so the lcd knows to do a full update instead of a partial one next time any update funcion is called |
23:15:51 | amiconn | Your viewport array wouldn't solve that |
23:16:20 | kugel | it would. it would clear and update the viewport the previous splash was drawn into |
23:16:39 | amiconn | And btw, immediate redraw isn't necessary. What's necessary is redrawing before the (respective part of the) lcd is updated the next time |
23:17:15 | JdGordon| | kugel: amiconn is right.. it wont help... the 2nd last splash might be a bigger rect than the last one... |
23:17:16 | amiconn | How would it update the viewport? You'd need to call the owner of that viewport and cause it to redraw it |
23:18:01 | amiconn | Viewports are merely a rectangle definition and a set of parameters (colours etc) |
23:18:13 | kugel | well, in theory it won't help, yes. But practically lists are redrawn quickly enough. The statusbar is more problematic w.r.t to flickering |
23:18:29 | amiconn | and? |
23:18:46 | kugel | what and? |
23:18:54 | amiconn | How would your array solve that? |
23:19:08 | kugel | statusbar flickering? |
23:19:35 | kugel | the statusbar area isn't hit by splashes...normally |
23:20:15 | kugel | hm |
23:20:41 | JdGordon| | and it shouldnt... |
23:21:41 | JdGordon| | I'm starting to think that splashes should just be bound into the custom viewport... |
23:21:47 | JdGordon| | it makes things much eaiser |
23:22:36 | kugel | it would, surely, but I wouldn't want to do that |
23:23:02 | kugel | you have this sort of problems at several places. there should be a generic way to solve that |
23:23:26 | kugel | my local copy is broken!? |
23:23:43 | JdGordon| | then do a full screen clear and add a flag to the lcd stuff to do a full update next update call... |
23:24:40 | kugel | that's not very thread safe |
23:24:56 | amiconn | There's only ever one thread drawing to the framebuffer |
23:25:09 | kugel | ah yes |
23:25:45 | kugel | one could it put into the root_menu too though |
23:25:46 | amiconn | JdGordon|: Clearing the lcd will still not solve the problem |
23:26:17 | | Quit renke ("leaving") |
23:26:18 | n1s | that reminds me, splashes do a full screen lcd_update, they should be able to get away with only the rect covered by the actual splash, right? |
23:26:26 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
23:26:58 | amiconn | A splash may cover more than one viewport, hence all covered viewports need updating to get rid of the splash |
23:27:04 | kugel | n1s: I already have it converted to viewports (including only updating the rect) which can I commit right now |
23:27:13 | JdGordon| | amiconn: sure, but there is nothing that cna be done about that |
23:27:18 | amiconn | That means triggering a redraw |
23:27:32 | kugel | amiconn: why more than 1? |
23:27:36 | * | JdGordon| 's origional idea for viewports was to have a drawing function in the vp struct.... |
23:27:44 | n1s | kugel: ah |
23:27:51 | JdGordon| | kugel: quickscreen is a simple example of a screen with more than 1 vp |
23:28:11 | kugel | JdGordon|: that's not a splash |
23:28:35 | JdGordon| | thats not the point |
23:28:48 | JdGordon| | the screen BEHIND the splash is the difficulty |
23:29:04 | kugel | a splash is 1 viewport |
23:30:04 | kugel | reading amiconn statement again I think I got what he meant with cover :) |
23:31:17 | | Quit Jaykay_ (Read error: 110 (Connection timed out)) |
23:32:16 | kugel | amiconn: that would a current problem too though |
23:32:43 | amiconn | Yes, but so far it doesn't cause too many problems |
23:33:30 | amiconn | There is no easy solution, but it is something to consider when playing with list viewports |
23:33:35 | * | JdGordon| is confident his solution is good enough |
23:34:14 | amiconn | JdGordon|: Uh? Imagine a splash appearing in a tiny 8x8 pixel viewport... |
23:34:31 | | Quit tvelocity (Read error: 104 (Connection reset by peer)) |
23:35:17 | amiconn | Of course we could require that a sane viewport must be set before calling splash() |
23:35:46 | JdGordon| | 1) thats unrealistic... 2) thats not a problem, the whole screen gets cleared (but not updated), when the ui loop next calls any update function the whole screen then gets updated... typically the update is called ocne all the viewports have redrawn |
23:36:04 | JdGordon| | the downside here is the bloody statusbar could get updated without the rest of the screen |
23:36:38 | | Quit kugel (Nick collision from services.) |
23:36:40 | amiconn | Why do you think it's guaranteed that all viewports will be redrawn in time? |
23:36:43 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
23:36:59 | JdGordon| | im not guarenteeing anything... |
23:37:21 | JdGordon| | I'm just saying, usually screens ddraw all their viewports befor calling lcd_update* |
23:37:25 | kugel | clearing the whole screen is still unecessary |
23:37:35 | kugel | updating isn't too, but will simplify things |
23:37:46 | | Join tvelocity [0] (n=tony@adsl22-78.her.forthnet.gr) |
23:38:17 | amiconn | Yes, usually, atm. If I'm understanding the idea of custom lists properly then this will no longer be the case |
23:38:49 | JdGordon| | yes it will... |
23:39:15 | JdGordon| | unless im mistaken, custom viewport is just setting the rect where screens sit... |
23:39:22 | JdGordon| | the rest of the screen is dead space |
23:39:34 | | Quit n1s ("Lämnar") |
23:39:40 | amiconn | ...where a splash could extend into |
23:39:52 | amiconn | These parts won't be restored |
23:39:55 | JdGordon| | which is why im saying we clear the entire lcd but dont update |
23:40:13 | amiconn | Then you clear everything that might be outside the list |
23:40:28 | JdGordon| | which is only going to be the backdroip which gets redrawn by the lcd driver |
23:40:43 | amiconn | Custom lists on their own don't make much sense imo. They only make sense if you use them to place something outside them |
23:41:29 | kugel | what? |
23:41:39 | JdGordon| | its purpose right now is to just use less of the screen for the gui... just like everything else.. its for prettyness |
23:41:45 | kugel | "them"? |
23:42:00 | kugel | ah I understand |
23:42:55 | * | amiconn wouldn't want to waste screen real estate for nothing |
23:43:16 | kugel | We know you wouldn't :) |
23:44:07 | kugel | surely you would be able to place something outside the lists, like a imaginary global wps'ified statusbar |
23:44:14 | JdGordon| | amiconn: the end goal is still (hopefully) that you could have the list in one part of the screen, and the wps/statusbar in another being updated automatically |
23:45:06 | amiconn | That's what I thought... and it could be used for the trigger screen as well, and maybe recording, radio etc |
23:45:15 | JdGordon| | and if that were the case then there really is no problem here anyway |
23:45:42 | amiconn | But then you'll experience the problem of splashes covering more than one viewport |
23:46:08 | JdGordon| | but the background viewports have to be refreshed atuomatically... so they will get redone |
23:46:15 | kugel | the problem is already apparend with the statusbar |
23:46:22 | JdGordon| | its the forground vp which could have flicker/problems |
23:46:49 | kugel | the other way around I'd think |
23:47:15 | * | JdGordon| would so love to rip apps/ apart and start again :p |
23:47:29 | amiconn | Perhaps viewports shouldn't be updated individually, instead the main loop should do it |
23:47:30 | kugel | the foreground (as in the current screen) would always redraw immediately. The backgrounds one only once in a while, and those would be hit by clearing & updating the whole screen |
23:48:00 | amiconn | I'm referring to the actual lcd_update |
23:54:05 | | Quit schrottplatz ("o.O") |
23:54:20 | * | JdGordon| suggests kugel commit the splash in viewport change seperatly (and sooner better than later) and we decide what to do about this dead space later |
23:54:21 | amiconn | This way the main loop could signal all its background vp handlers that a full update is needed, and only send it to the lcd when all these handlers updated their viewports in the framebuffer |
23:54:52 | | Quit evilnick_7 ("http://www.mibbit.com ajax IRC Client") |
23:55:04 | JdGordon| | there are no vp handlers.... I origionally suggested this sort of thing and was turned down |
23:55:44 | JdGordon| | we could have a very simple vp manager (plugin proof of concept in the tracker still i tinhk) which does all the magic |
23:56:52 | amiconn | I'm not talking about vp handlers stored in the viewport, but rather the modules which are "plugged" in the currently running main ui loop |
23:57:10 | JdGordon| | thats what I mean |
23:58:45 | amiconn | Kind of deferred updates. It would also solve another potential problem with multiple viewports: On targets with packed pixels (mono/grey), an lcd_update_rect() may update more than what is specified |
23:58:46 | | Join cmwslw [0] (n=cmwslw@c-98-249-113-152.hsd1.tn.comcast.net) |