Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2009-05-07

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:27saratogai just noticed the bootloader won't go into USB mode on plugin if the hold switch is on
01:10:34saratogaon the Sansa e200
01:10:49saratogais 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:35saratogamain-pp.c is the Sansa's and Gogear right?
01:19:48saratogaoh H10
01:20:41saratogais 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:17CIA-38New commit by 03unhelpful (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:28CIA-38New commit by 03unhelpful (r20865): Add missing PictureFlow overlay source, fix properties on new files.
03:43:38toffe82I 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:53toffe82is it a problem of my HD ?
03:44:06evilnickHave you tried checkdisk?
03:47:20toffe82found it, disk full :)
03:47:32toffe82there should be a message for this
03:48:10evilnickThe disk was *that* full that it couldn't create the playlist?
03:50:26toffe82I m trying now
03:51:06toffe82yes, it was full
03:51:10toffe82working now
03:52:12Unhelpfuli'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:52evilnickAh, 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:33toffe82strange 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:42fisxojHello, the iAudio 7 info page seems a bit out of date, I was wondering how stable the port is now?
04:21:55krazykitit's not out of date. nothing has really happened with the port
04:22:32fisxojthat's too bad, I'd love to try it out, but, I don't want anything too experimental
04:23:01Unhelpfulfisxoj: then you need to look at supported devices.
04:24:17fisxojUnhelpful: 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:02scorcheand we are saying Rockbox doesnt run on that device, try another ;)
04:41:48***Saving seen data "./dancer.seen"
04:46:03Unhelpfulhrm, 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:31Unhelpfulthose 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:26saratogaif its not continuous can the metadata parser for a format make it continuous?
04:48:53Unhelpfulthe 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:42Unhelpful..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:26saratogawhen the file is buffered into memory and pass through the metadata parser, could it be descrambled and stored sequentially in memory?
04:51:31Unhelpfulrequiring 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:50Unhelpfulwhich i'm already worried about, given the many ways you can encode a jpeg that we can't decode ;)
04:53:12Unhelpfulsaratoga: 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:01saratogaUnhelpful: 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:47saratogai guess have get_mp3_metadata rewrite it
04:55:57Unhelpfulsaratoga: 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:45saratogaso decoding happens before the metadata is parsed?
04:58:08Unhelpfulthat'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:48Unhelpfuli 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:14Unhelpfulif 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:36JdGordonwhat does car adaptor mode do when power is through usb?
05:51:40JdGordoni.e... the sansas...
05:54:23JdGordonam i going to need a custom bootloader and build to have it usable, so it doesnt try connecting to msc?
05:58:42Unhelpful"real" USB, or some power adapter that uses the same same jack?
06:00
06:00:09JdGordonthe 2nd
06:00:38LloreanI think if you have an SVN bootloader, you don't need to worry
06:00:48LloreanI believe the SVN bootloaders now basically do nothing on USB for the e200
06:01:14JdGordontrying to install a new bootloader now.... usb isnt connecting for some resadson
06:01:25LloreanBut 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:11JdGordonbut 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:23JdGordonor that
06:02:37*JdGordon starting to wish he hadnt lost his other e200
06:04:04JdGordonalthough.. come to think of it.. it was a v2.. so wouldnt help me here anyway :/
06:06:21JdGordonweee :) i found the bugger
06:06:28JdGordonno 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:09pixelmaUnhelpful: for album art (in the core or pictureflow) I guess that if both filetypes are present, the bmp one will be "preferred"?
09:29:29Unhelpfulpixelma: actually, it looks for jpeg first
09:30:01pixelmaaha, so no removing or renaming needed if I want to test jpg
09:31:07Unhelpfulnope... 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:20CIA-38New commit by 03unhelpful (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:27LloreanCan 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:57LloreanOr 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:22NSplitlindbohm.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:14TorneLlorean: 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:35TorneLlorean: i guess you could always call it "jogger mode" :)
11:28:40 Join _lifeless [0] (n=lifeless@188.16.83.142)
11:29:09NHeallindbohm.freenode.net irc.freenode.net
11:29:09NJoinflydutch [0] (n=flydutch@host219-166-dynamic.15-87-r.retail.telecomitalia.it)
11:29:09NJoinhapposade [0] (i=happosad@xob.kapsi.fi)
11:29:09NJoindionoea [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:56LloreanTorne: Yes, there are.
11:30:09Tornehmm.
11:30:34Torneat 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:08Tornemy ipod has a 59.5mb playback buffer :)
11:31:28 Join Zambezi [0] (i=Zulu@bnc.dotbnc.se)
11:31:48Llorean30 seconds of PCM is 5 megabytes.
11:32:15LloreanThat means you could be using as much as 1/12 of your buffer or so.
11:32:17Torne...it's not pcm though, is it?
11:32:21LloreanMuch more on the traditional 32MB targets.
11:32:24Torneor do i not understand it either
11:32:26Torne:)
11:32:27LloreanIt's whatever format you're playing.
11:32:38LloreanIt's a faulty assumption to make that everyone will be listening to 128kbps MP3.
11:32:50LloreanQuite a few people with larger disk players at least use FLAC.
11:33:13LloreanSo you need to look at it in the worst-case light if you're considering removing it as an option entirely.
11:33:14Torneyah..
11:33:30Torneok, that's a very good point :)
11:33:32kugelUnhelpful: "fix" propoerties on new files?
11:33:54Tornei think the on/off setting is a good direction, though
11:34:03Unhelpfulkugel: as in, i forgot to set svn properties before committing them. :P
11:34:04kugelit seems your fix reset the history of pictureflow.c :/
11:34:04markunor add malloc to rockbox and just allocate the skip buffer dynamically :P
11:34:40Lloreanmarkun: That wouldn't solve the issue. :-p
11:34:53kugelUnhelpful: do you see what I mean?
11:34:54LloreanThe 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:15LloreanEven if it malloced, it'd still have the same problem of users not reading what it does, and just guessing.
11:35:24Torneis it already configured out on flash targets, incidentally?
11:35:26LloreanThe manual even explicitly says "you should set this as low as you can"
11:35:41LloreanTorne: Dunno, but it wouldn't matter even if it was.
11:35:44LloreanOr rather, even if it wasn't.
11:36:23Unhelpfulkugel: 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:02TorneLlorean: 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:16kugelUnhelpful: surely it has a history
11:37:30kugelthe history of the old pictureflow.c
11:37:50Unhelpfulkugel: it *shouldn't*, the one in apps/plugins/pictureflow should have that history.
11:38:56TorneLlorean: 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:27kugelah, I see the old one is still there
11:39:46Unhelpfulhttp://svn.rockbox.org/viewvc.cgi/trunk/apps/plugins/pictureflow/pictureflow.c?view=log
11:40:03kugeleh, I really should look at the files before complaining :p
11:40:21kugelconfusing filenames ftw! ;)
11:40:50Unhelpfulthe "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:52LloreanTorne: 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:25Unhelpful...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:00kugelI see now how it works
11:42:30 Quit timc (Remote closed the connection)
11:43:17TorneLlorean: if it did become a binary option you might call it "optimise for: longest battery life, best skip protection"
11:43:20Torneor similar
11:43:40Tornewhich would probably avoid a need to consult the manual
11:45:58Tornehm, actually at that point you might reasonably have more than two options (though not too manY)
11:46:20Unhelpfulkugel: 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:20Tornethen it just becomes a problem of picking appropriate buffer sizes..
11:46:53 Join timc [0] (n=aoeu@116.3.196.121)
11:47:27Unhelpfulsvn 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:29LloreanTorne: The problem with that is that they might expect it to do a lot more than it's doing
11:48:41Tornehmm
11:48:45LloreanOptimizing 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:06Torne"Skip buffer size: small (better battery life), large (better skip protection)" :)
11:50:14Unhelpfulthat sounds good :)
11:50:54Tornethe manual can explain in more detail exactly what the impact is
11:52:34LloreanI don't really know why it needs to communicate about the fact that it's manipulating a buffer though.
11:52:52LloreanIt's information that can be in the manual, but doesn't actually help a user use the feature better.
11:53:15UnhelpfulLlorean: 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:30Torneyeah
11:53:49Tornei dunno, i'm just brainstorming :)
11:55:01LloreanUnhelpful: But a simpler name like "Shake Protection" with options "on/off" communicates basically the same thing.
11:55:42LloreanWithout long names, or terms that may confuse users.
11:55:58Unhelpfulfair enough. :)
11:56:13Torneif it's that simple, though, then there's no obvious reason to turn it *off*
11:56:32Tornethat 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:03LloreanThere are plenty of options where there's no obvious reason to turn them "off" other than better battery life.
11:57:29LloreanThe 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:55LloreanThe problem is people turning options on for reasons other than what they're used for because of bad names.
11:58:01Torneyah.
11:58:09Tornethat does sound reasonable.
11:58:24Torneso it then becomes "how long should the buffer be for "on" and "off" :)
11:58:31LloreanOff should be 0.
11:58:41LloreanAssuming the watermarks are working well now.
11:58:42Torne..really?
11:58:46LloreanYup
11:58:54Tornei've had mine skip while sitting on a table with the buffer on 0
11:59:00Tornethough this was some time ago
11:59:08LloreanYes, but that's bad math.
11:59:12LloreanThe skip buffer shouldn't fix bad math.
11:59:21LloreanIt's basically covering up an actual bug
11:59:37Torneoh, codecs not properly accounting for stuff
11:59:48Torneit may well have been fixed since i tried that
11:59:56Tornei experimented when i found the setting originally :)
12:00
12:00:08LloreanI think it's more that VBR can trick it into thinking X amount of audio is more time than it actually represents
12:00:12LloreanBut I'm nto sure.
12:00:26Tornehm
12:00:40Tornewell, 0 then.
12:00:45Tornebut what about "on"? :0
12:01:04 Quit kugel (Read error: 110 (Connection timed out))
12:01:13UnhelpfulLlorean: perhaps some very basic bitstream parsing to see how many frames you've actually got would help, there?
12:01:15LloreanAs for "On", I don't know
12:01:27LloreanI don't know enough about HD operation to know how hard it is to prevent them from reading for 10 seconds straight
12:01:42LloreanUnhelpful: Well, there can be issues like it being 3 seconds of MP3 and 2 seconds of FLAC, etc.
12:02:12Tornewell, 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:20LloreanUnhelpful: I really don't know, it might be better resolved now. I know there was something done about the watermark semi-recently
12:02:20Tornesay, by cycling with it in my pocket
12:02:26Tornei have it set to 30s atm
12:02:32Torneno idea of the general applicability :)
12:02:45UnhelpfulLlorean: 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:52Unhelpful*i* mean. :)
12:03:25LloreanUnhelpful: 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:43LloreanBut across such short periods, it shouldn't be too bad (and we can always err on the side of safety)
12:03:55Torneyay mp3s with broken vbr data
12:04:37UnhelpfulTorne: 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:50LloreanUnhelpful: 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:00Tornethat would be kinda cool
12:05:14Tornei suspect it varies across players perhaps quite dramatically
12:05:18Tornedepending what kind of disk they use, at least
12:05:35Tornethe disk might be more or less agressive about locking the heads down while under acceleration
12:05:48LloreanAnd 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:07Unhelpfuli'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:01pixelmavery short
12:07:31Unhelpfullow moment of inertia? ;)
12:07:35Torneheh
12:07:47Torneipodvideo takes a second or so at least even sitting on a table
12:08:16Tornethe gap between feeling the disk move in your hand and seeing the buffering bar move in debug is quite noticable :)
12:10:10pixelmaand 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:55Bagderhttp://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:06MarcGuaymcuelenaere, anyone else: If I wanted to contribute to the Rockbox API documentation, how would I do so? mcuelenaere.alwaysdata.net/rockbox_api_example_3/">http://mcuelenaere.alwaysdata.net/rockbox_api_example_3/
14:21:07MarcGuayI'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:38amiconnLlorean: Spinup time is about 500ms for the Mini's microdrive
15:01:08amiconnThe small H10 has about 2.5sec spinup time - same as 1.8" hdd targets
15:01:36amiconnThe 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:49NSplitlindbohm.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:56NHeallindbohm.freenode.net irc.freenode.net
15:32:56NJoinamiconn [50] (n=jens@rockbox/developer/amiconn)
15:32:56NJoinJ-23 [0] (n=zelazko@unix.net.pl)
15:32:56NJoinn1s [0] (n=n1s@rockbox/developer/n1s)
15:32:56NJoinKBH [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net)
15:32:56NJoinpixelma [50] (n=pixelma@rockbox/staff/pixelma)
15:32:56NJoinmartian67 [0] (n=martian6@about/linux/regular/martian67)
15:32:56NJoinavacore [0] (i=nobody@1008ds1-rdo.0.fullrate.dk)
15:32:56NJoincrashd [0] (i=foobar@lostnode.org)
15:32:56NJoinwebmind [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:25rastapizzaHi, im searching for informations about sansa v2
15:50:30rastapizzaIs it possible to use the sansapatcher to install a fresh svn compilation with rockbox and booloader ?
15:50:50n1snot sansapatcher, you need a different tool
15:50:58n1sand it's not ready for general use yet
15:51:01rastapizzawich 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:42rastapizzawich too do i have to use to proceed ?
15:52:55rastapizzatoo -> tool
15:52:55n1si think this page has all the info on the various newer sansa ports http://www.rockbox.org/twiki/bin/view/Main/SansaAMS
15:53:24n1syou need to compile the tool yourself
15:53:37rastapizzaBig 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:46CIA-38New commit by 03mcuelenaere (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:52mcuelenaereMarcGuay: the tool to generate the API documentation needs to be rewritten
16:22:22mcuelenaerebut 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:11MarcGuaymcuelenaere: thanks, i'll take a look..
16:34:07mcuelenaerethat link contains the actual documentation, the generator is in utils/plugin_api_somewhere
16:34:28mcuelenaerehttp://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:46CIA-38New commit by 03MarcGuay (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:32mcuelenaereMarcGuay: currently the plugin documentation isn't generated
16:46:37mcuelenaerepublicly
16:47:04MarcGuayIt's unfortunate. I'm looking at your website...
16:47:05evilnick_7That link doesn't work because of the period after shtml
16:47:27MarcGuayevilnick_7: Proper English loses again.
16:47:49Lloreanevilnick_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:10udzgurui got a question regarding rockbox 3.2 on a sansa e200 series player
17:16:17udzguruanyone can help me?
17:16:28n1sask away
17:16:54udzguruok ... is there a possibility to include the tracks on a inserted micro sd card directly into the rockbox database
17:16:56udzguru?
17:17:26evilnick_7udzguru: Yes, you should be able to Update the database and it will scan the card
17:19:18udzgurui 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:33udzgurui just updated to 3.2 and after the restart it did rebuild the database (booted with the micro sd inserted)
17:22:53udzguruok ok .. i just rebuilt the database another time and now it seems to work :D
17:23:45udzguruthanks for your help folk
17:24:02udzgurugotta leave now and make something to eat. good bye and take care
17:24:05 Quit udzguru ()
17:29:44mt-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:47mt-saratoga : ^
17:36:16 Join wincent [0] (n=wincent@dyndsl-091-096-000-117.ewe-ip-backbone.de)
17:37:16saratogamt: this is for your rmdec program?
17:38:14mt-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:55saratogamt: in rockbox you don't have access to those include files
17:43:16saratogayou just have the stuff in codec.h, codeclib.h, etc
17:45:20 Quit MarcGuay (Read error: 104 (Connection reset by peer))
17:45:38mt-sorry, I meant firmware/include .. not usr/include.
17:46:07saratogaah ok
17:46:08mt-saratoga : libffmpegFLAC's decoder.c includes <inttypes.h> for example.
17:46:30mt-I have access to those inside firmware/include, right ?
17:46:34saratogai think you should be able to <> include them
17:46:46saratogalet me check what the make file thinks
17:46:57n1sseveral rockbox files do #include <inttypes.h>
17:49:02saratogainttypes is quite useful since we have 64 bit sims and 32 bit targets
17:50:50saratogahmm i'm not really sure where we set all the includes for the codecs
17:50:56mt-I think inttypes should be included instead of stdint.h , right ? (especially since there's no stdint.h in /include :) )
17:53:05saratogayes
17:59:33linuxstbmt-: What is the "patch" file in your latest patch?
18:00
18:00:10mt-linuxstb : a mistake (I was diffing inside librm directory) :/
18:00:25linuxstbmt-: 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:20mt-ok
18:02:15linuxstbAlso, 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:28linuxstbI'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:50mt-linuxstb : ok .. I will separate cook/rm .. I'll just try to get them compiled with rockbox headers first.
18:05:44linuxstbFinal 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:26Tornelinuxstb: have uploaded a new version of my ipod bootloader patch which includes a large comment explaining the boot process ;)
18:07:34Tornestill not sure if we would want to put it in the manual or not
18:07:51mt-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:54Tornewell, 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:24linuxstbmt-: 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:18linuxstbTorne: 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:29mt-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:57Tornelinuxstb: *nod*
18:15:15Tornelinuxstb: does the comment i added to ipod.c look reasonable, as technical docs for people actually loking in the bootloader code, anyway?
18:15:51markunmt-: you can also start using git and the commit in your local tree every time you have made some important changes
18:16:00markunthe -> then
18:16:16Torneor bzr, if like me you find git incomprehensible ;)
18:16:17 Quit parafin (Read error: 110 (Connection timed out))
18:17:26Tornethough 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:38mt-markun : ok, I will try it . (never used git before ..)
18:18:19markunit's not the only option of course, but it works for me
18:19:32markunmt-: http://www.rockbox.org/twiki/bin/view/Main/GitVersionControl#The_public_Rockbox_git_repositor
18:19:52Tornethat would be the big advantage of git over bzr here :)
18:20:06Tornesince branching the rockbox svn into a bzr repo yourself takes like, several hours
18:20:06linuxstbmt-: 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:30mt-markun : thanks :)
18:20:53saratogalinuxstb: 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:48mt-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:52linuxstbsaratoga: I don't see the harm. The benefit is that we can all see the changes mt made compared to ffmpeg.
18:27:36mt-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:03linuxstbmt-: 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:26mt-linuxstb : no I meant in the old patches
18:38:52mt-The current code contains no such switches.
18:39:15linuxstbSo you mean patches 1 and 2 will use "#if 0" ?
18:39:39mt-yes
18:39:56 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky)
18:41:07linuxstbThat sounds fine.
18:41:50LambdaCalculus37saratoga: 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:23mt-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:16linuxstbmt-: 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:26mt-linuxstb : fine. When I'm done with the patches I'll add them to FS #10182.
18:44:35mt-unless a new task is preferable.
18:45:04 Part pyro_maniac ("Leaving.")
18:45:25LambdaCalculus37Going to try a vanilla S firmware now.
18:46:12linuxstbmt-: I don't know... Keeping them all in the same task is probably easiest though.
18:46:18LambdaCalculus37Also accepted, but it does nothing but recovery mode again.
18:46:58mt-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:13LambdaCalculus37Let's see what a patched S firmware does.
18:53:54LambdaCalculus37Gah, 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:55MarcGuayCould 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:25MarcGuayPerhaps there's a better way to define my root dir?
18:58:43 Join LambdaCalculus37 [0] (i=44a0430d@rockbox/staff/LambdaCalculus37)
18:59:27MarcGuayIdeally I'd like to opendir(), readdir(), and just open the files that have a particular file ext.
18:59:41linuxstbMarcGuay: You probably need to create a new string containing the full path - e.g. using snprintf()
18:59:59MarcGuayI see.
19:00
19:00:51 Join SirFunk_ [0] (n=Sir@208.15.25.145)
19:00:57MarcGuayI think that strcat returns the same varialble type (char*) so I'm not sure if that would make a difference...
19:01:39MarcGuayI'll try again.
19:01:57 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
19:02:06LambdaCalculus37Hmmm...
19:03:07mcuelenaereMarcGuay: is this PATH big enough to contain both ./rockbox/rocks/whatever and test1?
19:04:10domonokyMarcGuay: 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:24linuxstbMarcGuay: Also, Rockbox coding guidelines say that variables should be lower-case. Upper-case is reserved for pre-processor symbols (i.e. #defines)
19:06:20MarcGuayThanks guys.
19:10:14MarcGuayWorking 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:57linuxstbMarcGuay: 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:45MarcGuaylinuxstb: It seems to return the concatonated string.
19:32:32MarcGuayBut it modifies my rootpath variable which isn't ideal..
19:32:49MarcGuayOr maybe not?
19:33:40mcuelenaereMarcGuay: it does modify your rootpath variable
19:33:45mcuelenaerehttp://www.cplusplus.com/reference/clibrary/cstring/strcat/
19:34:43mcuelenaereand 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:30MarcGuayThanks again.
19:35:47gruslcan i use rockbox with ainol V2000SE ?
19:35:52BigBambino
19:36:10BigBambiThe players that Rockbox works on are listed on www.rockbox.org
19:36:20gruslyeah
19:36:32gruslok hanks
19:36:34gruslthanks
19:36:37BigBambinp
19:36:41 Part grusl
19:36:45mcuelenaeregrusl: 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:33mt-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:43mt-linuxstb : as for the README , I didn't write it yet, but it should be included in patch4 when it's ready.
19:48:55mt-linuxstb : did FS not show the files in the patch because I added them all to one comment ?
19:50:05BigBambimt-: I see them there
19:50:28BigBambithere is libcook.patch1 .patch2 and .patch3 right?
19:50:38 Quit Zarggg_ ()
19:50:47BigBambimt-: er, ignore me - I see what you mean now :)
19:54:08mt-:)
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:42taylor_Hello, Everyone.
22:42:02LambdaCalculus37I 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:28taylor_Any luck with the Sansa fuzes? Or are they still pretty unstable?
22:44:29LambdaCalculus37Any 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:41LambdaCalculus37No objections? Going once... twice...
22:47:58LambdaCalculus37In it goes.
22:48:41JdGordon|noooooooooooooooo!
22:48:49taylor_haha
22:49:06CIA-38New commit by 03rmenes (r20869): Add the Sansa m200 to tcctool.
22:49:50LambdaCalculus37JdGordon| 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:23kugelgrrrrrrml, my custom list patch reveals so nasty assumptions/problems in rockbox :S
22:56:40JdGordon|good... go fix them :)
22:56:58JdGordon|we always knew about them though...
22:57:54kugelsplash is pretty broken if you stop using fullscreen
22:58:01JdGordon|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:21JdGordon|splash should override custom viewport i think
22:58:32kugelI can fix those which call splash/f with non-zero ticks easily, but not those calls with 0 zicks
22:59:21kugelsure, 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:13JdGordon|thats not what 0 means :)
23:00:21JdGordon|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:10kugelJdGordon|: 0 means don't sleep (i.e. don't yield() ), I know. But if I cleanup a
23:06:12kugelafter 0 ticks, guess what happens :)
23:06:35JdGordon|right, I know... i was just saying 0 doesnt mean show forever...
23:07:13kugelthat doesn't make it easier
23:07:36kugelJdGordon|: the statusbar think should be rather trivial I think. just c&p the setting and work a bit more on viewportifying
23:07:46JdGordon|*maybe* we could add a function clean_us_splashes() or something to be called when the loop doing the 0tick splashes finishes
23:07:48kugelI solved the set_int thing btw
23:08:17JdGordon|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:22JdGordon|the mr500 port needs it
23:08:27kugelJdGordon|: 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:31amiconnThe assumptions aren't nasty, they are vaild for current rockbox
23:09:10kugel1 for each screen*
23:09:26JdGordon|kugel: well no.. all thats needed is for the whole screen to be redrawn.. nothing needs to be remembered
23:09:51JdGordon|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:10kugelI'd rather make a static viewport[NB_SCREENS] than clearing and updating the whole screen
23:10:30JdGordon|and how would that help?
23:11:08kugelit would be accessible in a cleanup_after_splash() or in the next splash()?
23:11:52JdGordon|which in effect you end up doing the same thing... clearing the viewport and then requiring the actual screen be redrawn
23:12:16kugelclearing 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:40kugelclearing viewport != clearing screen though
23:12:59JdGordon|clear the screen and not update it will be the same
23:13:06kugelparticularly statusbar flickering
23:13:13JdGordon|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:35kugellists only update the viewport they're drawn into
23:13:54kugelthe 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:23kugeljust 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:50JdGordon|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:51amiconnYour viewport array wouldn't solve that
23:16:20kugelit would. it would clear and update the viewport the previous splash was drawn into
23:16:39amiconnAnd 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:15JdGordon|kugel: amiconn is right.. it wont help... the 2nd last splash might be a bigger rect than the last one...
23:17:16amiconnHow would it update the viewport? You'd need to call the owner of that viewport and cause it to redraw it
23:18:01amiconnViewports are merely a rectangle definition and a set of parameters (colours etc)
23:18:13kugelwell, 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:29amiconnand?
23:18:46kugelwhat and?
23:18:54amiconnHow would your array solve that?
23:19:08kugelstatusbar flickering?
23:19:35kugelthe statusbar area isn't hit by splashes...normally
23:20:15kugelhm
23:20:41JdGordon|and it shouldnt...
23:21:41JdGordon|I'm starting to think that splashes should just be bound into the custom viewport...
23:21:47JdGordon|it makes things much eaiser
23:22:36kugelit would, surely, but I wouldn't want to do that
23:23:02kugelyou have this sort of problems at several places. there should be a generic way to solve that
23:23:26kugelmy local copy is broken!?
23:23:43JdGordon|then do a full screen clear and add a flag to the lcd stuff to do a full update next update call...
23:24:40kugelthat's not very thread safe
23:24:56amiconnThere's only ever one thread drawing to the framebuffer
23:25:09kugelah yes
23:25:45kugelone could it put into the root_menu too though
23:25:46amiconnJdGordon|: Clearing the lcd will still not solve the problem
23:26:17 Quit renke ("leaving")
23:26:18n1sthat 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:58amiconnA splash may cover more than one viewport, hence all covered viewports need updating to get rid of the splash
23:27:04kugeln1s: I already have it converted to viewports (including only updating the rect) which can I commit right now
23:27:13JdGordon|amiconn: sure, but there is nothing that cna be done about that
23:27:18amiconnThat means triggering a redraw
23:27:32kugelamiconn: 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:44n1skugel: ah
23:27:51JdGordon|kugel: quickscreen is a simple example of a screen with more than 1 vp
23:28:11kugelJdGordon|: that's not a splash
23:28:35JdGordon|thats not the point
23:28:48JdGordon|the screen BEHIND the splash is the difficulty
23:29:04kugela splash is 1 viewport
23:30:04kugelreading 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:16kugelamiconn: that would a current problem too though
23:32:43amiconnYes, but so far it doesn't cause too many problems
23:33:30amiconnThere 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:14amiconnJdGordon|: 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:17amiconnOf course we could require that a sane viewport must be set before calling splash()
23:35:46JdGordon|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:04JdGordon|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:40amiconnWhy 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:59JdGordon|im not guarenteeing anything...
23:37:21JdGordon|I'm just saying, usually screens ddraw all their viewports befor calling lcd_update*
23:37:25kugelclearing the whole screen is still unecessary
23:37:35kugelupdating isn't too, but will simplify things
23:37:46 Join tvelocity [0] (n=tony@adsl22-78.her.forthnet.gr)
23:38:17amiconnYes, usually, atm. If I'm understanding the idea of custom lists properly then this will no longer be the case
23:38:49JdGordon|yes it will...
23:39:15JdGordon|unless im mistaken, custom viewport is just setting the rect where screens sit...
23:39:22JdGordon|the rest of the screen is dead space
23:39:34 Quit n1s ("Lämnar")
23:39:40amiconn...where a splash could extend into
23:39:52amiconnThese parts won't be restored
23:39:55JdGordon|which is why im saying we clear the entire lcd but dont update
23:40:13amiconnThen you clear everything that might be outside the list
23:40:28JdGordon|which is only going to be the backdroip which gets redrawn by the lcd driver
23:40:43amiconnCustom 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:29kugelwhat?
23:41:39JdGordon|its purpose right now is to just use less of the screen for the gui... just like everything else.. its for prettyness
23:41:45kugel"them"?
23:42:00kugelah I understand
23:42:55*amiconn wouldn't want to waste screen real estate for nothing
23:43:16kugelWe know you wouldn't :)
23:44:07kugelsurely you would be able to place something outside the lists, like a imaginary global wps'ified statusbar
23:44:14JdGordon|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:06amiconnThat's what I thought... and it could be used for the trigger screen as well, and maybe recording, radio etc
23:45:15JdGordon|and if that were the case then there really is no problem here anyway
23:45:42amiconnBut then you'll experience the problem of splashes covering more than one viewport
23:46:08JdGordon|but the background viewports have to be refreshed atuomatically... so they will get redone
23:46:15kugelthe problem is already apparend with the statusbar
23:46:22JdGordon|its the forground vp which could have flicker/problems
23:46:49kugelthe other way around I'd think
23:47:15*JdGordon| would so love to rip apps/ apart and start again :p
23:47:29amiconnPerhaps viewports shouldn't be updated individually, instead the main loop should do it
23:47:30kugelthe 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:00amiconnI'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:21amiconnThis 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:04JdGordon|there are no vp handlers.... I origionally suggested this sort of thing and was turned down
23:55:44JdGordon|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:52amiconnI'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:10JdGordon|thats what I mean
23:58:45amiconnKind 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)

Previous day | Next day