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 2008-12-20

00:01:57 Join herrwaldo [0] (n=waldo@ip-81-11-202-191.dsl.scarlet.be)
00:02:18 Quit Nibbler (Read error: 148 (No route to host))
00:02:28 Join t0mas [0] (n=tomas@rockbox/developer/t0mas)
00:03:08 Join jhulst_ [0] (n=jhulst@unaffiliated/jhulst)
00:04:16 Quit jhulst (Read error: 60 (Operation timed out))
00:06:08 Quit ender` (" It's bad luck to be superstititious. -- Law of Superstition")
00:07:42 Nick jhulst_ is now known as jhulst (n=jhulst@unaffiliated/jhulst)
00:13:22 Join Nibbler [0] (n=Nibbler@e181121173.adsl.alicedsl.de)
00:13:59 Quit bertrik (Remote closed the connection)
00:17:56 Join tvelocity [0] (n=tony@adsl18-206.her.forthnet.gr)
00:18:01 Quit Nibbler (Client Quit)
00:18:08 Quit jhulst (Remote closed the connection)
00:18:15 Quit t0mas ("Leaving")
00:20:38 Join BigBambi [0] (n=alex@72.198.66-86.rev.gaoland.net)
00:20:58 Quit BigBambi (Remote closed the connection)
00:21:13 Join BigBambi [0] (n=Alex@rockbox/staff/BigBambi)
00:21:21 Quit BigBambi__ ("Leaving")
00:22:49 Quit domonoky (Read error: 54 (Connection reset by peer))
00:24:48 Join jhulst [0] (n=jhulst@unaffiliated/jhulst)
00:24:48 Quit bluebrother ("leaving")
00:25:13 Quit lasser ("ChatZilla 0.9.84 [Iceweasel 3.0.4/2008112309]")
00:26:27hobbsFor the tracks on just one album that I have, %in is displaying "5/17" etc. instead of just a single number. 1) what tag is it pulling that info from, and 2) is there any way I can make it not happen?
00:27:14krazykithobbs, change that tag on your file
00:27:26hobbslike I just asked, what tag?
00:27:29hobbsthe track tag is set to 5.
00:27:32hobbs(or whatever)
00:27:33 Join |mr [0] (n=lymeca@dsl-74-220-76-75.cruzio.com)
00:28:21Hillshumthe id3 tag
00:28:49 Join n1s [0] (n=nils@rockbox/developer/n1s)
00:29:01hobbsplease tell me you're just _pretending_ to be clueless.
00:29:23krazykithobbs, what file type? you may have two different tag types on the file (that is, both id3 and ape, or something like that)
00:29:45hobbskrazykit: MP3; ID3v2 is the only tag I'm aware of.
00:30:58hobbsbut now that I look at it, the tags are responsible, it's just that the "id3v2" util was hiding the info from me
00:31:17 Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net)
00:31:35 Quit massiveH (Client Quit)
00:35:18 Quit Aurix_Lexico (Remote closed the connection)
00:36:28 Join Aurix_Lexico [0] (n=comrade@c-68-56-205-239.hsd1.fl.comcast.net)
00:37:22 Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere)
00:37:39mcuelenaereAurix_Lexico: the PIC code is in the EXT0 block
00:38:12mcuelenaereI think IDA is able to disassemble it (I tried it several times, but as I didn't understand the PIC architecture nor it's instructions it didn't really make sense to me)
00:38:50mcuelenaerebut it did look like legitimate code
00:40:05 Quit lymeca (Read error: 110 (Connection timed out))
00:41:05***Saving seen data "./dancer.seen"
00:41:45 Quit n1s (Remote closed the connection)
00:42:20Aurix_Lexicoyeah, I was able to extract it, and disassemble it with IDA
00:42:54 Join lymeca [0] (n=lymeca@dsl-74-220-76-61.cruzio.com)
00:43:23Aurix_LexicoI found a some college's course notes on PIC assembly, and have the PIC datasheet
00:43:55Aurix_Lexicoit still looks pretty confusing though :/
00:45:57mcuelenaereyeah I think the PIC datasheet isn't hard to find
00:46:19mcuelenaerebut still, it's way more embedded then the ARM processor
00:46:57 Quit DataGhost (Read error: 104 (Connection reset by peer))
00:46:59Zagorha, with proper watermarks even a 67KB buffer is not too small
00:47:24mcuelenaerewill the scroll thread do its own lcd_update() or is this the responsibility of the main thread?
00:48:03 Quit Hillshum ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]")
00:49:02 Join mud-rb [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com)
00:49:04Zagorwav is rather busy with such a small buffer though...
00:49:47gevaertsNow go for a 67B buffer :)
00:50:37 Quit jhulst (Read error: 113 (No route to host))
00:51:00Zagorgevaerts: :)
00:51:17MarcGuayHmm utf8.def not found building the manual..
00:51:37 Quit |mr (Read error: 110 (Connection timed out))
00:52:29mcuelenaerehmm seems like it does do its own lcd_update()'s..
00:54:01mcuelenaerewhen I have a scrolling line and the main LCD thread only does lcd_update() every sleep(50); I see that the scrolling line also updates about every 50 ticks. is this normal behaviour?
00:55:11 Part toffe82
00:55:56 Quit Zagor ("Leaving")
00:56:09mcuelenaerehmm never mind, it seems like the lcd driver doesn't support partial lcd drawing
00:56:15 Join admin1lbo [0] (n=admin1lb@pool-72-88-166-100.nwrknj.east.verizon.net)
00:56:21 Nick admin1lbo is now known as QUICKSTART (n=admin1lb@pool-72-88-166-100.nwrknj.east.verizon.net)
01:00
01:00:16 Join jhulst [0] (n=jhulst@unaffiliated/jhulst)
01:00:32 Join Bensawsome [0] (n=Bensawso@unaffiliated/bensawsome)
01:01:58Unhelpfulmcuelenaere: thanks, i didn't know we *had* dependencies in FS
01:02:18mcuelenaerenp :)
01:02:19Unhelpfulalso, i have another nail in the vc-dither's coffin. we can make bayer a *lot* cheaper than it is now.
01:03:17Unhelpfulit's currently a lookup in a 16x16 table. we can replace that with lookups in two 16-byte tables, and an xor, or even one table, if we throw in a shift-by-one and another bitwise logical op.
01:04:42 Join lasser [0] (n=chatzill@W8610.w.pppool.de)
01:04:52 Quit DerDome ("Leaving.")
01:04:57 Quit lymeca (Read error: 110 (Connection timed out))
01:07:56Unhelpful...actually, i can get rid of the shift. the whole thing can be done with one table lookup and one bitwise and per row, and one table lookup and one bitwise xor per pixel
01:08:01 Join lymeca [0] (n=lymeca@dsl-74-220-76-75.cruzio.com)
01:15:42 Quit jhMikeS (Nick collision from services.)
01:15:48 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS)
01:17:57MarcGuayLooks like utf8.def has been renamed utf8x.def in the new Latex package.
01:19:47MarcGuayit snowboards with umlauts
01:25:05 Quit lymeca (Connection timed out)
01:27:40 Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]")
01:28:07 Join hd [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca)
01:28:37 Quit HellDragon (Read error: 104 (Connection reset by peer))
01:28:37 Quit hd (Read error: 104 (Connection reset by peer))
01:28:45 Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca)
01:38:58Unhelpfulit works, with one bitwise and, one 1D array lookup and one bitwise xor in the inside loop. should that be of comparable speed to two bitwise and + a 2D array lookup?
01:40:18Unhelpfulbinsize diff is -216B on arm
01:45:09 Quit HellDragon (Connection reset by peer)
01:46:33 Quit wpyh (Read error: 110 (Connection timed out))
01:47:42Unhelpfulthat's on ipod4g... m5/x5 will probably improve slightly less as they have one more place that looks up dither values
01:48:56 Join midkay [0] (n=midkay@rockbox/developer/midkay)
01:49:22amiconnUnhelpful: I didn't read up everything yet, but regarding to your last question I think it should be even faster
01:49:36amiconn1D array lookup requires less address calculation
01:50:30Unhelpfulit also saves ~200B, give or take a bit depending on arch whether or not there's a remote
01:52:13 Quit _Auron_ (Read error: 104 (Connection reset by peer))
01:52:18Unhelpfuli was thinking of committing my current batch of scaler improvements, if there are no objections. should be binsize and speed improvements everywhere but greyscale, but those get a HQ scaler to replace the nearest-neighbor one, so it's not too bad a deal, i'd say
01:52:19 Join _Auron_ [0] (n=DarkAuro@ppp-70-244-161-118.dsl.rcsntx.swbell.net)
01:53:44 Quit lasser (Remote closed the connection)
01:57:08 Join wpyh [0] (n=william@125.163.88.253)
02:00
02:01:56 Quit Schmogel (Read error: 104 (Connection reset by peer))
02:04:09 Quit QUICKSTART (Remote closed the connection)
02:06:52 Join lymeca [0] (n=lymeca@dsl-74-220-76-61.cruzio.com)
02:10:03 Quit aneqrs ()
02:17:09 Join Makuseru [0] (n=max@163.106.40.24.aeneasdsl.com)
02:24:12 Join grndslm [0] (n=grndslm@24-116-87-97.cpe.cableone.net)
02:25:32 Quit grndslm (SendQ exceeded)
02:26:27 Join grndslm [0] (n=grndslm@24-116-87-97.cpe.cableone.net)
02:32:48 Join RockRabbit [0] (n=3aac9a01@gateway/web/cgi-irc/labb.contactor.se/x-4a91097042010cb5)
02:32:50 Quit lymeca (Read error: 110 (Connection timed out))
02:33:18RockRabbitCan anyone tell me what DBOP stands for and what it means?
02:34:03hobbsit's like DCOP only it's got that swing?
02:34:28RockRabbitAs in DBOP-A-LULA?
02:35:07hobbsand a wham-bam-boom.
02:35:58 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net)
02:36:30RockRabbitActually I first thought it was a song by Cyndi Lauper.
02:36:40 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net)
02:37:04krazykitplease try to stay on topic
02:39:12hobbsplease try to recognize the topic.
02:39:56RockRabbitStill no takers on DBOP?
02:40:19RockRabbitIts not in the rockbox glossary but its used often in conversations.
02:40:47krazykitaccording to the logs, it stands for "DBOP stands for "Data Block *Output* Port""
02:41:03hobbsRockRabbit: it's the name of a bit of the AS3525 that does some I/O. No clue what it stands for though :)
02:41:06Unhelpful<saratoga> [15:30:22] -bertrik: DBOP is a highspeed output port designed for driving LCDs
02:41:09***Saving seen data "./dancer.seen"
02:41:25 Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca)
02:41:37RockRabbitLooks like I need the as3525 datasheet more than ever.
02:42:05 Quit Makuseru (Read error: 104 (Connection reset by peer))
02:42:19krazykitRockRabbit, http://www.rockbox.org/irc/rockbox-20081128.txt - at around 17:55, there's some discussion about it that may help
02:42:35RockRabbitthanks
02:44:56RockRabbitANyone know how I can get hold of an as3525 datasheet?
02:45:34krazykitRockRabbit, talk to Bagder
02:50:04 Quit HellDragon (Client Quit)
02:53:36pixelmanote that Bagder is in Europe and it's almost 3 AM here
02:55:59 Part grndslm ("Leaving")
02:56:52 Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-53799ce3f402ff5b)
02:58:07 Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca)
03:00
03:00:29 Quit mcuelenaere ()
03:13:43 Join kugel [0] (n=chatzill@unaffiliated/kugel)
03:14:10kugelRockRabbit: hi
03:14:34 Join lymeca [0] (n=lymeca@dsl-74-220-76-75.cruzio.com)
03:14:50 Join Lss [0] (n=Lss@cm203.delta90.maxonline.com.sg)
03:17:53 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.")
03:19:39kugelRockRabbit: I wonder if you have noticed http://www.rockbox.org/tracker/task/9679
03:27:33 Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.4/2008111318]")
03:27:47 Quit jhulst (Remote closed the connection)
03:27:56 Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net)
03:28:35 Quit massiveH (Client Quit)
03:32:21 Join jhulst [0] (n=jhulst@unaffiliated/jhulst)
03:35:06 Quit faemir (Remote closed the connection)
03:36:05 Quit herrwaldo ("Konversation terminated!")
03:38:43 Quit lymeca (Read error: 110 (Connection timed out))
03:47:39 Join lee321987 [0] (n=chatzill@node103.32.251.72.1dial.com)
03:49:23lee321987anyone here who's done work in the Sansa c200's USB "bytes inserted" bug?
03:50:15saratogalee321987: probably the wrong time of night for any of those people
03:50:59RockRabbithi kugel - yes i got your forum post - sorry i have been afk for a while
03:51:11lee321987Well maybe some one else can answer this question −−−− I was just wondering if there is some information that some company won't give us that might make it easy to fix the bug...?
03:51:46saratogalee321987: maybe. its thought to be a bug in the PP hardware, so maybe they know how to correct it
03:51:57krazykitlee321987, not so much "won't give" as "can't legally give" in many cases, as the licensing agreements forbid them from doing so
03:52:34saratogalee321987: wait are you talking about the USB or SD bugs?
03:52:50lee321987is the PP still being used in _new_ hardware?
03:53:25midgeysaratoga: i've been looking at wma recently, trying to fix some of the tracker issues
03:53:37saratogamidgey: yes thank you
03:53:41saratogai've already commited your fixes
03:53:44lee321987the bug that inserts 2 bytes (randomly −− I think) during USB data transfers through RB.
03:53:53saratogai was very much hoping to get those fixed for 3.1
03:54:14saratogalee321987: thats not a USB bug, see FS #8663
03:54:23RockRabbitkrazykit - i sent a pm to bagder - but got no reply so far
03:54:26 Quit jhulst (Read error: 60 (Operation timed out))
03:54:46lee321987sorry for the wrong terms.
03:54:51midgeyi had some other changes i was wondering about
03:55:05UnhelpfulRockRabbit: as noted before, he's in europe, and is probably asleep at this hour.
03:55:08krazykitRockRabbit, well, seeing as he's probably asleep, you'll have to wait til (european) morning
03:55:49RockRabbiti sent him a private message two days ago
03:55:58lee321987what do you call it? An SD bug?
03:56:06saratogamidgey: what did you have in mind?
03:57:08midgeyWhy is M_PI_F defined as 0x3243f? Isn't 0x3243d more accurate
03:57:15midgeysame with TWO_M_PI_F
03:57:39lee321987Does the SD driver not get used if you have no SD card in the player?
03:58:06saratogathe device has a built in SD card, so theres always one in the player
03:58:26lee321987ahhhhh
03:59:07RockRabbithow can i tell how much ram memory each rockbox supported player has?
04:00
04:00:24saratogamidgey: I don't believe so
04:00:29 Join jhulst [0] (n=jhulst@unaffiliated/jhulst)
04:00:45midgeyah, nope. i divided wrong
04:00:49midgeydamn you fixed point
04:00:52rashersaratoga: why didn't you commit your fixes to the 3.1 branch?
04:01:22midgeyalso exponents[-1] doesn't really make sense (very high freq MDCT calc)
04:01:40saratogarasher: I did
04:01:45midgeyi suppose I should just pastbin my diff, one sec
04:02:04lee321987you'd think that companies would be more forthcoming with RB devs. (Are they worried that other companies will steal their technology?) I _know_ my next DAP will be one that RB works on.
04:02:20rashersaratoga: Ah. Didn't see the latest commit
04:03:20Unhelpfullee321987: companies that make DAPs often license much of the compenents, and library code for them, from other companies, which don't really care about how any one device based on their IP sells, and which license said IP under NDA.
04:05:06lee321987your name doesn't fit you.
04:06:29scorcheRockRabbit: DeviceChart
04:07:48midgeysaratoga: http://www.pastebin.ca/1289984
04:08:02midgeyincludes some changes you've already committed
04:08:40RockRabbitscorche: thanks - just what i wanted
04:09:03saratogamidgey: looking through it now
04:09:08midgeyalso includes some random debugf and spelling corrections :)
04:09:11saratogadoes it fix any known problem samples?
04:09:31 Quit lee321987 ("ChatZilla 0.9.84 [Firefox 3.0.4/2008102920]")
04:11:25midgeynot really that i know of. some of the problem samples sound a bit better (glitches seem less noticeable)
04:11:39midgeycould be the placebo effect. i'd like to think i'm fixing things
04:12:10midgeyi'll revert to svn and check
04:12:11saratogamidgey: some of that looks a bit odd
04:12:30saratogai recommend dumping the output to PCM and comparing it quantitatively using matlab or whatever
04:12:53saratogai've long since learned to never trust my ears :)
04:13:03midgeyi'll do that
04:13:17midgeyim relatively certian while(len > 0) is wrong
04:13:56saratogayes I think ffmpeg changed that recently
04:14:14saratogai looked at it briefly but couldn't find any samples where it made a difference so i sat on the fix
04:14:25midgeyotherwise the next block of code is useless
04:14:28saratogathough maybe it should be fixed even if we can't test it
04:17:01midgeyseems to make sense logically
04:17:05saratogathe block below @@ -1253,11 +1254,11 @@ seems to do the same thing but less accurately I think?
04:18:02midgeywell e2 is a fixed32 and n is an int
04:18:37midgeyif you just divide fixed32/int will you get a fixed32 back?
04:19:07saratogamidgey: yes
04:19:28midgeywell then, scratch that, i thought you'd get an int casted to a fixed32
04:19:29saratogaan int is just a fixed variable with a PRECISION of 0
04:21:32midgeycan you cast a fixed32 to a fixed64?
04:22:19 Quit Nico_P (Remote closed the connection)
04:22:46Unhelpfulmidgey: i think you'll get the wrong half of it, if you do that... you want to >>32 it, i would expect, and possibly add shift if they fixed32/fixed64 you're using have different precision
04:23:06Unhelpfulthe, not they.
04:23:41midgeythe wma codec casts here and there and i didn't know if that caused any endian issues
04:23:53saratogamidgey: @@ -1307,21 +1307,23 @@ reverts some of r14134
04:24:18saratogain general anytime you see shifts by anything other then 16 its because they absolutely have to be that value to avoid overflowing
04:25:01saratogain these cases one can only rearrnage the algebra with great caution
04:25:13midgeyah
04:25:20midgeysee this is helpful :)
04:26:02saratogabasically i wrote this by using 16 everywhere and then incrementing shifts until problem samples decoded right
04:26:15midgeyvery scientific
04:26:20Unhelpfulsaratoga: does rockbox code as it stands generally assume a truly fixed precision? i've seen and written code before where the precision "floats" as appropriate at each stage
04:27:07saratogaUnhelpful: variables have to be rescaled from time to time
04:27:25saratogafixed just means that the programmer is in charge of normalization, not the hardware
04:27:53 Join blkhawk- [0] (n=blkhawk@g226129030.adsl.alicedsl.de)
04:28:51saratogain reality the codec is just doing cosine transforms, and those transforms have no native scale, so the definition of the number one is arbitrary anyway
04:28:59saratogawe reassign it as needed
04:29:43 Quit RockRabbit ("CGI:IRC (EOF)")
04:31:14midgeyi've found another problematic sample if you're interested
04:31:24midgeyhttp://wymette.home.att.net/files/wmatest.htm
04:31:44midgeyjust sounds like a high pitched whine in rockbox
04:32:24Unhelpfulshouldn't be hard, i'd suppose, to kludge up a plugin that loads a greyscale pixmap, and displays it with greylib?
04:32:49midgeyby the sound of it, most of my changes aren't correct and can probably be ignored
04:33:08 Quit linuxstb (Read error: 110 (Connection timed out))
04:33:23saratogamidgey: yes that certainly fails quite badly
04:33:38midgeyi was quite surprised when i first listened
04:34:06 Join RockRabbit [0] (n=3aac9a01@gateway/web/cgi-irc/labb.contactor.se/x-60517774b98d073c)
04:34:38saratogait reports an ASF parser error so that may have something to do with it
04:34:44saratogathough those seem quite common
04:34:53saratogaeven on samples that decode more or less correctly
04:35:07midgeyi also have another track that gets a -5 return on wma_decode_block
04:35:21midgeyso the one on the tracker is not alone
04:35:34midgeythis track decodes correctly however
04:36:17RockRabbitif i detect a button press via an input pin on a GPIO port (in this case Sansa with AMS as3525 soc), how do I clear or reset the pin to detect the next button press? At present the button is continually being detected after being pressed only once.
04:37:16saratogamidgey: I've seen -5 errors before
04:37:31saratogaoften they don't decode in ffmpeg either, so testing them there is a good first step
04:37:51midgeyi'll have to tell the track it's not as special as i thought
04:38:07saratogathe ffmpeg decoder is evidently still incomplete
04:38:30midgeyare they actively working on it?
04:38:51saratogaI don't believe so
04:39:07midgeywell damn
04:39:39midgeyare there other types of WMA that we don't handle other than lossless?
04:39:45saratogayes, PRo and Voice
04:39:52saratogawe simply reject those
04:40:17midgeyis pro the same as wma v10?
04:40:45*midgey wanders off the wikipedia
04:41:07midgeyapparently to learn english as well....
04:41:13***Saving seen data "./dancer.seen"
04:42:46saratogai think the naming is inconsistent, I've heard v10 refer to both v2 files produced by the WMP10 encoder, and to other formats as well
04:43:25midgeyyep, seems that way
04:43:29saratogaWMAV2 is well standardized, but the Pro format seems more fluid with various versions and occasional research papers
04:43:32Unhelpfulalso, multichannel, lossless, and i think voice were introduced as part of the same "version", but are all essentially different codecs
04:43:44 Quit blkhawk (Connection timed out)
04:43:51 Nick blkhawk- is now known as blkhawk (n=blkhawk@g226129030.adsl.alicedsl.de)
04:44:02saratogawe just skip everything not tagged as V1 or V2 in the header
04:44:57midgeythe other variants seem like completely different beasts
04:46:45 Join lymeca [0] (n=lymeca@dsl-74-220-76-75.cruzio.com)
04:47:01saratogamidgey: that file you linked plays better in ffmpeg, but i wouldn't say it plays well :)
04:47:47midgeyyeah, i just tried it on vlc. it seems to jump and stutter
04:49:01mud-rbis there a doc somewhere that explains the drawing modes? can't seem to find it (ex. DRMODE_SOLID vs DRMODE_FG, etc.)
04:49:13saratogamidgey: why the sudden interest in wma?
04:51:12midgeyto be honest, i was just looking to fix some bugs before 3.1
04:51:23midgeyand wma happened to be the most recent one
04:51:27saratogaah ok
04:51:41midgeyand i'm working at microsoft next summer so that might have contributed
04:52:22saratogawell i've got a long list of codec chores if you're bored
04:52:44midgeyfor wma specifically or all across the board?
04:52:55saratogaall across the board
04:52:57saratogatake your pick
04:53:23saratogathough I think you could commit that fix from ffmpeg that i couldn't find a problem sample for
04:53:44midgeyalways have to worry about the commit count ;)
04:54:20midgeydid anything else in the pastebin look promising?
04:56:54saratogathe exponents[-1] thing is certainly wrong
04:57:04saratogathough i'm puzzeled how it doesn't seem to matter
04:57:15saratogai'd expect it to cause more problems by now
04:57:50midgeyjust getting lucky
04:57:50saratogasorry I mean the SVN code is wrong, not your fix
04:57:57midgeyright
04:58:30 Quit miepchen^schla (Read error: 110 (Connection timed out))
04:59:09midgeyi'm not sure the fix is right, that's what ffmpeg has at least
04:59:39saratogai'm not even sure what it does
05:00
05:00:23saratogai guess esize is bigger then bsize and it ends up being a small number?
05:00:50midgeythat's all i can come up with
05:03:17saratogahmm no its often zero
05:03:33midgeydo you think the casts in wmadeci are fine or should they be changed?
05:04:25 Quit lymeca (Connection timed out)
05:06:24midgeyactually, i have no idea how it works
05:06:36midgey-1 will be 0xFFFF etc correct?
05:06:50midgeythen shifted left with have low bits of 0
05:07:06midgeyif esize>size, you'll get -1 back?
05:07:13 Quit HellDragon (Client Quit)
05:07:38 Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca)
05:08:45saratogamidgey: at least in the file i looked at the two were always equal, meaning its always -1
05:08:57saratogaregarding the casts, I don't think they change anything
05:09:12midgeyi'm surprised that works
05:09:20saratogathe one macro is just a cast, and the other macro zeros and then casts
05:09:47saratogathe macros were put in there by marsdaddy in his first codec, but i didn't use them much
05:11:30midgeywhich macros?
05:11:51saratogaFixed32From64, etc
05:11:57saratogathough iguess some are really functions
05:12:05midgeyah, yes sorry
05:12:28midgeyaren't you still indexing an array with a negative index?
05:12:37saratogayeah, but we do that a lot :)
05:12:57*midgey 's mind is blown
05:13:51saratogayou probably shouldn't look at wmadata.h then
05:14:01Unhelpfulmidgey: an array is a pointer. a[-1] is the same as *(a-1)
05:14:21midgeyi knew thta, i thought exponents was const
05:14:25saratogahmm though i'm not sure if its correct here
05:15:35midgeyhave you looked at how ffmpeg handles the exponents array
05:17:58 Quit jhulst (Remote closed the connection)
05:18:28saratogaunless i'm missing something i think they also allow negative 1
05:18:28 Quit RockRabbit ("CGI:IRC (EOF)")
05:19:20midgeythey do, they increment the array throughout wma_decode_block
05:19:25midgeyincrement the pointer
05:23:29saratogamidgey: printing pointers makes me think we're probably grabbing exponents_bsize[1] as exponents[0][-1]
05:23:40saratogai'll see about compiling ffmpeg to see what they're actually using
05:23:51 Join jhulst [0] (n=jhulst@unaffiliated/jhulst)
05:26:44 Join lymeca [0] (n=lymeca@dsl-74-220-76-56.cruzio.com)
05:26:55 Quit lymeca (Remote closed the connection)
05:27:06 Join lymeca [0] (n=lymeca@dsl-74-220-76-56.cruzio.com)
05:28:05 Quit Lss (Read error: 110 (Connection timed out))
05:30:34 Quit MarcGuay ("ChatZilla 0.9.84 [Firefox 3.0.4/2008102920]")
05:40:04saratogai think i'm losing my mind
05:40:09saratogabut ffmpeg looks broken too
05:40:45midgeyffmpeg is always fun to look through...
05:42:49saratogano wait we're just really wrong here
05:44:47 Quit jhulst (Read error: 60 (Operation timed out))
05:45:11 Join jhulst [0] (n=jhulst@unaffiliated/jhulst)
05:45:38saratogait seems i never properly implemented ffmpeg r8627 which fixed this issue
05:45:54saratogawhich is why the esize/bsize logic makes no sense in rockbox
05:48:08midgeythat's what i was refering to with how they handle exponents
05:48:49saratogait looks like i half implemented it
05:48:53saratogabut left out some lines
05:48:57saratogaamazing that it worked at all
05:49:26midgeyi was syncing up their changes from about 8143 yesterday and i saw they handled it a bit differently
05:50:08midgeyunfortunately i kept segfaulting in bitstream.h and i gave up for the time being
05:50:57midgeythe get_bit1 change in r9999 made sense as well
05:51:18midgeyr10004 seems correct as well
06:00
06:00:48 Quit jhulst (Read error: 60 (Operation timed out))
06:01:14 Join pixelma_ [0] (n=pixelma@rockbox/staff/pixelma)
06:01:20 Quit lymeca (Read error: 113 (No route to host))
06:01:47Unhelpfulurgh... messy declaration issues :/
06:01:57 Quit amiconn (Nick collision from services.)
06:01:59 Join amiconn_ [50] (n=jens@rockbox/developer/amiconn)
06:02:32 Quit pixelma (Read error: 110 (Connection timed out))
06:03:10 Join jhulst [0] (n=jhulst@unaffiliated/jhulst)
06:03:14Unhelpfulresize.h has declarations that need things from bmp.h, and vice versa... and i'm a bit stuck figuring out where to declare the needed structs and functions to make it happy :/
06:06:21Unhelpfulthere we go, a forward declaration for struct rowset and all is well
06:08:15saratogamidgey: alright properly synced it
06:08:27saratoganot noticing any changes with my files but i don't know which ones to test
06:08:57midgeyi've been stealing test files from random sites around the internet
06:09:05midgeymost seem to work in rockbox though
06:11:44midgeysaratoga: http://samples.mplayerhq.hu/A-codecs/WMA/wma-broken.asf is broken in rockbox as well
06:12:10midgeyvlc 0.9.8a handles it better than us, but not well
06:12:43midgeyi dont have the ffmpeg source on my computer so i've been testing in vlc
06:14:40 Join psycho_maniac [0] (i=psycho_m@ppp461.hk.centurytel.net)
06:15:12saratogathat asf doesn't even play in foobar
06:15:29midgeyflip4mac does fine
06:21:03 Quit jhulst (Read error: 131 (Connection reset by peer))
06:25:47 Quit Aurix_Lexico (Remote closed the connection)
06:26:24saratogai'm going to commit these changes to SVN, and if no one complains I may add them to 3.1
06:27:44midgeyi think unless they fix a noticeable bug, the changes don't need to go into 3.1
06:28:00midgeyi mean the code in svn is clearly wrong
06:28:07midgeyso maybe it does make sense
06:28:43saratogai think the bug only affects a few frequency bands, so its probably not too noticable
06:29:16saratogamidgey: you mentioned some other ffmpeg svn numbers, are there other things you think we didn't sync right?
06:30:35midgeywell the get_bits1 change won't cause any functional differences
06:30:53saratogaare there more of those i didn't sync?
06:31:13midgeyr10004 might have slightly different behavior get_bits -> skip_bits
06:31:55midgeyr14171 and r15004 have changes we don't have
06:32:11midgeysupposedly fixes some WMV audio stutter
06:32:18midgeyhave found a test case to confirm
06:32:22midgeyhaven't*
06:32:35saratogai put a lot of time into the get_bits1 thing
06:32:40saratogai thought it was all commited
06:32:52saratogai remember it not seeming to change anything
06:33:51saratogai think in the long term i have to figure out how huffman coding is really implemented in our codecs and try to improve it
06:34:04saratogai'm sure its much slower then it should be
06:35:15midgeyi highly doubt the get_bits1 change would make any difference, see r9999
06:36:50 Quit HellDragon (Read error: 104 (Connection reset by peer))
06:37:05Unhelpfuli'd be amazed if googling "optimized huffman decoder" did not find an OSS project with a compatible license from which you could borrow one, saratoga
06:37:20 Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca)
06:38:40saratogaUnhelpful: I'm sure thats true
06:38:53saratogabut merging them is non-trivial without a good understanding of what they do
06:39:54 Quit HellDragon (Read error: 54 (Connection reset by peer))
06:40:07 Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca)
06:40:44saratogai have been trying to merge in some Vorbis bitstream optimizations I found in one of the tremor brances with little success, and thats the same decoder but different brances
06:41:14***Saving seen data "./dancer.seen"
06:47:58 Join [1]psycho_maniac [0] (i=psycho_m@96.14.220.33)
06:49:48mud-rbso, is it preferable to do some really ugly hacks to get things to work on more targets, or to be cleaner and more bug free but work on fewer targets?
06:49:59mud-rb(for a plugin)
06:51:24Unhelpfulthere are plugins that go either way
06:51:53Unhelpfulfor example, no pictureflow on greyscale targets, but jpeg viewer even on mono targets
06:52:30mud-rbmy main concern is RAM...on the high ram targets everything will be easy, but i'm going to need some kind of insane caching scheme if i go to the 2 MB targets...
06:53:23ameyerwhat's the plugin do?
06:53:48*ameyer wonders if there are any 2MB targets with non-tiny screens
06:55:16mud-rbameyer: viewer for game records for go/weiqi/baduk. i'm rewriting it. basically i have to keep a tree structure in memory to traverse, and if i do it on the 2 MB targets, there's not enough RAM to keep the whole thing in even if i steal the audio buffer
06:55:28 Quit [1]psycho_maniac (Remote closed the connection)
06:55:51mud-rbi thought up an algorithm to do it even on little memory, but it's going to be ugly and error prone
06:55:58 Quit psycho_maniac (Read error: 113 (No route to host))
06:57:34Unhelpfulyay, pluggable scaler output is "working", in that i have the framework for it in place, and regular bitmap loading without an output plugin works
06:57:53Unhelpfultime to code a test case :/
06:59:56mud-rboh well, the 2 MB targets all look like the screen is too small for much anyway. i'll just make it work for them but make it die if you try to load a file that's too large...
07:00
07:01:32Unhelpfulsaratoga: i was going to say that if we had one nice huffman decoder in core, corejpeg and codecs could all use it, but that's probably not feasible unless other codecs use the same methods for inserting markers in the huffman bitstream :/
07:02:15 Join Minthe [0] (n=Minthe@gw13.ecc.u-tokyo.ac.jp)
07:06:44saratogaUnhelpful: i have no idea how huffman coding is actually implemented, is it generalizable between different codecs?
07:09:25 Join jhulst [0] (n=jhulst@unaffiliated/jhulst)
07:10:25 Join ball [0] (n=ball@adsl-99-152-241-9.dsl.emhril.sbcglobal.net)
07:12:21ballI'm listening to music on my iPod Mini, courtesy of RockBox
07:12:27ball...so thanks for that.
07:19:34midgeysaratoga: it might be my ears, but i think the first wma in FS #7488 sounds better now
07:20:51midgeybaroque loop sounds good as well, but there's still a slight glitch in the middle of the song
07:23:54saratogamidgey: i diffed the two and theres 6 spots in the first file that are improved
07:23:58saratogaso i guess it does help
07:25:01midgeyi have some songs acting funny on track changes (slight audio glitch) so there still might be some things that aren't reset between tracks
07:26:10saratogamidgey: if you can reproduce them its usually not too hard to figure out what causes them
07:26:28midgeyi'll look into on the plane tomorrow
07:26:41Unhelpfulsaratoga: there's really only one "way", as far as i know, and all that differs is tables and how codecs store them if they don't use a fixed table... as far as huffman coding itself goes. :/
07:26:44saratogai started by zeroing the entire struct like you did, then did a binary search zeroing half as much each time
07:27:12saratogaUnhelpful: so it might be feasible to write an optimized one in assembly and have different codecs use it?
07:27:14midgeywma_broken is handled a bit better now as well
07:27:28Unhelpfulhowever, jpeg can insert marker codes into the huffman stream, and you have to catch that... and i'm sure there will be other codecs that do similar, but use different methods
07:27:47midgeyit goes negative time remaining from time to time...
07:27:57Unhelpfulmaybe, if the buffer is preprocessed by a codec function that removes and handles anything that's not huffman code data?
07:28:24saratogawhy does jpeg do that?
07:28:58 Part ball ("bye!")
07:30:51Unhelpfulerror resilience, i believe. the codes can mark that you're in a new macroblock, etc, and the decoder can bail on the current one, and go about getting things back into a known state
07:31:31Unhelpfulin any case, in jpeg the magic is a byte-aligned FF followed by a non-zero byte. an actual byte-aligned FF in the huffman codestream is just followed by a 00
07:31:40saratogacodeclib stuff isn't available to the core anyway, so even if we had seperate ones for jpeg and codecs that wouldn't be a huge deal
07:31:51 Quit XavierGr ()
07:31:53Unhelpfulso a preprocesser could easily strip out that 0, and move everything over one
07:32:42saratogaUnhelpful: are you interested in jpeg?
07:33:10Unhelpfulright, but if we have one nice generic decoder, assuming that such a thing can be done, it could live in core and be used by jpeg and codecs
07:33:39 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
07:34:05Unhelpfulit's something i'd like to see working. i'm not entirely sure i can tackle making an acceptable core jpeg decoder. i looked at the jpeg_decoder.o file from the plugin, and that's 13KB... i doubt that would get in.
07:40:47Unhelpfulhrm, so if i want to just display an image until i get a button press, in a plugin, it looks from ppmviewer.c like i can just do rb->button_get(true), then return?
07:45:35saratogaUnhelpful: theres certainly targets were 13KB would be tolerable, and I'm sure it can be made smaller
07:48:33Unhelpfuli'd actually expect it to end up going the other direction, if it's to interface with the scaler as it is now. :/
07:50:17Unhelpfulthe *easiest* way to go would be to buffer the entire image in RGB, then feed it to the scaler exactly as BMP does. that would make it *much* heavier than BMP, which feeds the scaler in small pieces
07:51:35saratogaUnhelpful: jpeg blocks are stored in order right?
07:52:26Unhelpfulsaratoga: yes, but i believe it's the whole Y plane, then the whole U plane, then the whole V plane. so, we could track a seek offset that we read from in each plane, in that case, and decode 1-2 MB rows at a time
07:52:39Unhelpfulbut, again, that's getting toward larger, not smaller code
07:53:52Unhelpfulhrm, a "for greylib" output plugin for the scaler should probably live in grey_draw.c?
07:56:59saratogaUnhelpful: doing one plane at a time is probably better, since you could resize each one and then accumulate the resized images
07:57:06 Quit jhulst (Remote closed the connection)
07:58:04Unhelpfulyes, and no. the color-target scaler takes RGB pixels, the grey-target one takes greyscale pixels.
07:58:48saratogaUnhelpful: do 3 grayscale resizes then?
07:59:24Unhelpful...there is no greyscale resizer on targets with a color screen. they're the same functions, with some #ifdefs that change key parts.
08:00
08:00:07saratogayes i know, but its probably cheaper to have both resizers then to buffer the decoded image
08:01:57Unhelpfulno, no, i definitely don't want to buffer the whole image... but i think that finding a way to decode chunks in finished RGB will cost less code than building greyscale scalers on color targets would. they smooth scalers cost ~1.5KB on greyscale targets
08:02:03Unhelpfuls/they/the/
08:03:17saratogai wonder if theres any other projects or libraries we could look at to see what they do
08:03:50Unhelpfulhard to say, if they're designed for a PC, i doubt they'll have the same design constraints as us :/
08:06:37 Quit saratoga ("CGI:IRC (EOF)")
08:09:57 Quit bertrik (Remote closed the connection)
08:11:16 Join Rob2223 [0] (n=Miranda@p4FDCEE5B.dip.t-dialin.net)
08:12:07 Join lucent [0] (n=eshattow@75-174-180-52.chyn.qwest.net)
08:15:47MintheIs there any hope to get png viewer?
08:16:08lucentdecoder code needs to be written
08:16:25lucentI don't know of any technical reason it can't be done by a motivated coder
08:17:04lucentit just hasn't been done yet AFAIK
08:17:16MintheIs there any memory issues?
08:17:17 Quit mud-rb (Read error: 54 (Connection reset by peer))
08:17:43lucentpng relies on zlib, I think
08:17:53lucentI'm not much of a coder myself so I don't know the details
08:19:46UnhelpfulMinthe: memory issues are very much something that can be dealt with. on targets where you get enough of it, you can use the plugin buffer. on others, you'll have to borrow it from the audio buffer.
08:28:40 Quit Rob2222 (Read error: 110 (Connection timed out))
08:36:06 Quit midgey ()
08:39:15 Join midgey [0] (n=tjross@c-71-205-31-207.hsd1.mi.comcast.net)
08:41:18***Saving seen data "./dancer.seen"
08:57:25 Join jhulst [0] (n=jhulst@unaffiliated/jhulst)
09:00
09:01:07 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn)
09:04:01amiconnmidgey: Are all those wma fixes going into the 3.1 branch as well?
09:05:44midgeyr19503 doesn't really have any fixes
09:06:10midgeysaratoga already committed up to r19498
09:06:27midgeyr19000 and r19502 can probably go in
09:06:41 Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma)
09:08:41Unhelpfulamiconn: would you be able to give me a hand with a test plugin for 8-bit greyscale bitmaps loads? as far as i know, the loading works, but i seem to be stuck a little bit with greylib itself...
09:12:15*midgey sleeps
09:12:18 Quit midgey ()
09:12:59lucentls
09:13:02*lucent fails
09:21:30Unhelpfulnevermind... got it :D
09:21:45 Join Nibbler [0] (n=Nibbler@e181121173.adsl.alicedsl.de)
09:24:02amiconnUnhelpful: What was the problem? Perhaps the greylib and/or its documentation can be improved a bit?
09:24:45Unhelpfulamiconn: trouble was my not understanding the buffered/unbuffered modes, and the business of different draw functions for each... unless i misunderstand how i fixed it.
09:27:16amiconnah
09:27:48 Quit BHSPitLappy (Remote closed the connection)
09:28:32amiconnThe 2 modes might need a bit more documentation. Basically unbuffered mode exists in order to save some ram if you only need bitmap drawing
09:28:38Unhelpfulin any case, i added a scaler output plugin for greylib, and a test viewer plugin that loads and displays a bitmap scaled+centered
09:29:46Unhelpfuli'll pop it onto FS in a minute, and try to ping some people with grayscale hardware, i suppose... but it does pretty much everything we'd talked about, i think :D
09:29:57amiconnIt's also a bit faster since it avoid the extra copy
09:30:09amiconn*avoids
09:31:38Unhelpfulamiconn: maybe we should have the buffered functions call the unbuffered ones if the buffer is NULL?
09:32:55amiconnThat'd mean more of the code is linked to the plugin
09:36:10Unhelpfulhrm, good point. probably no better way to do it than what we've got now, then.
09:36:47amiconnImo there's no need, since a plugin will either use buffered mode or unbuffered mode, never both. What could be done though in order to help debugging is checking for NULL and printing a helpful DEBUGF() message if it is. Only in the sim of course
09:37:33Unhelpfulhrm, yes, that would be good. do we have a doc for greylib, besides the sources?
09:39:47amiconnSource only atm; there are longish comments for most public functions. GraphicsAPI wiki page also applies, of course
09:41:19 Quit jhulst (Remote closed the connection)
09:42:28Unhelpfulhrm, do i have to create a task before i can add dependencies on other tasks?
09:42:52 Join jhulst [0] (n=jhulst@unaffiliated/jhulst)
09:46:51 Quit jhulst (Read error: 60 (Operation timed out))
09:50:25 Join jhulst [0] (n=jhulst@unaffiliated/jhulst)
09:56:42Unhelpfulup as FS #9683, if somebody with greyscale targets wants to test it
10:00
10:04:20 Join n1s [0] (n=nils@rockbox/developer/n1s)
10:22:48n1sjhMikeS: about to test the beast charging patch, anything in particular to look for?
10:24:25 Quit jhulst (Read error: 131 (Connection reset by peer))
10:25:14 Join jhulst [0] (n=jhulst@unaffiliated/jhulst)
10:36:34 Join planetbeing [0] (n=planetbe@c-71-235-96-172.hsd1.ct.comcast.net)
10:41:20***Saving seen data "./dancer.seen"
10:44:00 Join bmbl [0] (n=Miranda@unaffiliated/bmbl)
10:45:58 Join fredddy [0] (n=freddy@p3E9E3319.dip0.t-ipconnect.de)
10:47:01 Join EspeonEefi [0] (i=eefi@SAFFRONCITY.MIT.EDU)
10:47:34 Quit bmbl (Client Quit)
10:51:30 Join bmbl [0] (n=Miranda@unaffiliated/bmbl)
10:58:36 Quit maddler ("Lost terminal")
11:00
11:01:28 Join _lifeless [0] (n=lifeless@90.151.222.100)
11:03:40 Quit Minthe ("Leaving...")
11:07:01 Join Acksaw [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com)
11:11:20jhMikeSn1s: I put instructions in the FS task . :)
11:15:16n1sok, already started charging with AC
11:18:11 Quit __lifeless (Read error: 110 (Connection timed out))
11:23:34 Join {phoenix} [0] (n=dirk@p54B45D4C.dip.t-dialin.net)
11:33:30 Join miepchen^schlaf [0] (n=miepel@p579EC669.dip.t-dialin.net)
11:34:20 Join PaulJam [0] (n=pauljam@p54BED510.dip.t-dialin.net)
11:34:25 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon)
11:39:30 Join gregzx [0] (n=chatzill@dsk227.neoplus.adsl.tpnet.pl)
11:41:04 Quit alexbobp (Read error: 104 (Connection reset by peer))
11:45:32 Quit JdGordon (Remote closed the connection)
11:45:52 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon)
11:58:00 Quit JdGordon (Remote closed the connection)
11:58:14 Join stoffel_ [0] (n=sfr@p57B4E146.dip.t-dialin.net)
11:58:21 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon)
11:58:57 Join Schmogel [0] (n=Miranda@p3EE21D48.dip0.t-ipconnect.de)
12:00
12:01:25Unhelpfulamiconn: about buffered vs unbuffered greylib... is there any practical difference between using buffered mode, drawing, and calling update, and rendering into a greyscale bitmap buffer in the plugin, then using grey_ub_gray_bitmap to draw that to the screen?
12:02:00Unhelpfulthe practical difference, i'd think, would be mainly in availability of the other drawing functions for buffered updates?
12:03:39 Join Acky [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com)
12:03:46 Join faemir [0] (n=faemir@88-106-244-173.dynamic.dsl.as9105.com)
12:04:10Unhelpfultrying to figure out how best to do greylib pictureflow :/
12:09:29 Join Minthe [0] (n=Minthe@KD124214153219.ppp-bb.dion.ne.jp)
12:11:58amiconnIf you need a fullscreen buffer anyway there shouldn't be a significant difference
12:12:00 Quit PaulJam (".")
12:13:51 Join ender` [0] (i=krneki@foo.eternallybored.org)
12:14:02 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky)
12:14:25amiconnThere are some situations where using the unbuffered version is better, e.g. when just a partial buffer is used (mandelbrot) it saves ram
12:14:51amiconnmandelbrot wouldn't be possible in buffered mode on archos, at least not without stopping playback
12:15:43amiconnUnbuffered mode needs 14KB of buffers on archos (+some), buffered mode needs 21KB. The whole plugin buffer is 32KB, so go figure...
12:16:19 Quit Acksaw (Connection timed out)
12:17:51 Quit JdGordon (Remote closed the connection)
12:17:54Unhelpfulok, issues i see here is that it writes directly to an offscreen buffer to draw the covers, but uses the API functions to write text. greylib supports using only part of the screen, right?
12:18:12 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon)
12:19:13Unhelpfulmaybe best bet would be LCD drawing functions for text, offscreen buffer of its own for the PF rendering, and grey_ub_gray_bitmap to render that into the greylib buffer?
12:19:18amiconnyes, although the choice of bondaries is restricted
12:19:42Unhelpfulhrm... how, specifically?
12:19:49amiconnIt can only split at pixel packing boundaries
12:20:02amiconn(the lib rounds automatically)
12:20:32 Quit Minthe ("Leaving...")
12:20:47Unhelpfulso, from 1px to 8px alignment vertically, depending on target, and from 1px to 4px alignment horizontally?
12:20:47amiconnWhy does picureflow render to an offscreen buffer, btw?
12:20:59amiconnImo it would be better to render directly to the framebuffer
12:21:09 Join Minthe [0] (n=Minthe@KD124214153219.ppp-bb.dion.ne.jp)
12:22:25Unhelpful...i'm digging a bit further. its buffer is rb->lcd_framebuffer, actually
12:23:32Unhelpfulis that an in-memory buffer for the data currently on-screen, or an offscreen buffer that's copied onscreen by lcd_update?
12:24:51amiconnThe latter.
12:25:59amiconnThe currently displayed image is stored in the lcd controller's internal memory, which isn't memory mapped hence can't be written directly
12:26:23amiconnThis applies to any target I know
12:26:52 Quit Acky (Read error: 104 (Connection reset by peer))
12:27:13 Join Acksaw [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com)
12:30:49 Join moos [0] (i=Mustapha@rockbox/staff/moos)
12:33:48Unhelpfulit doesn't seem too easy to draw via direct writes to greylib's buffer, unless i'm misreading? i'm still thinking that grey_ub_gray_bitmap draws from an offscreen buffer where we do the rendering are probably the way to go for PF, along with setting aside some lines at the bottom for the album text, and switching to normal LCD mode for the menu and tracklist
12:34:36 Join Jaykay [0] (n=chatzill@p579E7EB7.dip.t-dialin.net)
12:34:46 Quit stoffel_ (Read error: 113 (No route to host))
12:36:57Jaykaybecause nobody of those evil developers cared about my nice reminder, ill suggest committing of http://www.rockbox.org/tracker/2533 here in irc
12:38:35amiconnThat would work of course. Just take care to avoid all lcd functions which directly access the lcd while the greylib overlay is running. This includes lcd_update() - so in order to print the album text, you need to use grey_deferred_lcd_update() instead
12:40:37Unhelpfulno problem. probably not going to get anywhere on this today, so for now the only thing using the new greylib scaling support is a crummy bmp viewer test app
12:40:41amiconnThe horizontal alignment for 2bpp horizontally-packed lcds is 8px, btw. This is because those lcds use 16 bit transfers
12:41:01Unhelpfulwhich, with the *third* patch, is actually there
12:41:21***Saving seen data "./dancer.seen"
12:43:45 Join mud-rb [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com)
12:44:50 Quit tvelocity (Remote closed the connection)
12:45:02Unhelpfuli'm not worried about horizontal res, the pictureflow effect is edge-to-edge, and i'll just restrict album titles to a designated area at the screen bottom, and make it N*8px
12:46:04amiconnRather make the upper (greylib) area N*8px
12:47:22Unhelpfulthat's fine too. i'm packing up for now, but if anything occurs to you that might be a good idea on how to handle some part of this, i'll check the logs whenever i get back.
12:47:34amiconnThere are 2 targets where the lcd height isn't a multiple of 8. It wouldn't matter for those (mini G1 and G2 -> horizontal pixel packing), but I think it's better to stay safe
12:53:07 Join Darksair [0] (n=user@117.89.121.31)
12:56:25 Quit jhulst (Read error: 60 (Operation timed out))
12:59:07 Join alexbobp [0] (n=alex@69.149.25.200)
12:59:57 Quit Nibbler ("Ex-Chat")
13:00
13:10:49 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net)
13:16:34 Join Rudy77 [0] (n=Rudy77@adsl-69-221-120-99.dsl.akrnoh.ameritech.net)
13:18:17 Join Lss [0] (n=Lss@cm203.delta90.maxonline.com.sg)
13:19:14n1sjhMikeS: AC chargign worked nicely, stopped at 4.205V and had a peak temperature of 35C
13:19:42n1swith a standard battery AFAIK
13:20:01 Join ito [0] (n=ito@adsl-68-248-72-20.dsl.sfldmi.ameritech.net)
13:21:16 Quit ito ("Ex-Chat")
13:23:25 Join AndyIL [0] (i=AndyI@212.14.205.32)
13:24:17 Join FOAD_ [0] (n=dok@dinah.blub.net)
13:29:11 Join herrwaldo [0] (n=waldo@ip-81-11-228-79.dsl.scarlet.be)
13:33:00 Quit FOAD (Read error: 145 (Connection timed out))
13:33:00 Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net)
13:34:43 Quit AndyI (Read error: 110 (Connection timed out))
13:36:34 Part Rudy77
13:39:08 Join B4gder [241] (n=daniel@rockbox/developer/bagder)
13:46:32 Join gartral [0] (n=Gareth@75.33.70.77)
13:46:46gartrali have a bug...
13:47:18*scorche looks over at the bug tracker
13:48:04scorchego ahead and say what you have experienced, but i may just tell you to submit it tot he tracker =)
13:48:20*domonoky detects that the wheel on e200v2 really looks like it needs some enable pin set. (i can measure changing voltage at the output pin with the OF, but not with rockbox. )
13:49:23gartralwell, i did some searching there, but i thought ide confirm it here, before going through all that, when you try to set a rating for any song, a single popup appears wit "<No info>" and disapears , returning you to the WPS screen
13:49:48scorcheah...i dont think many of us here use ratings...
13:50:30gartraland for those of us that do?
13:51:27scorcheif it isnt in the tracker, i would fiel a report if it isnt already in there...otherwise, i will fade into the background for someone else to speak up
13:53:12scorcheit does the same for me, but as i have never used that feature, i have no idea if that is an intended function because there is something to do, etc
13:54:55gartralwould that be user interface, or WPS?
13:56:43scorchei would put it under Database
13:59:57gartraloops
14:00
14:00:19gartralhow do i edit it?
14:01:50 Join BigBambi_ [0] (n=alex@72.198.66-86.rev.gaoland.net)
14:02:05moosgatral: done!
14:02:25 Quit BigBambi ("Please insert girder")
14:03:11gartralthank you for repairing my itchy trigger fingers mistake
14:04:28moosdon't worries; no problems
14:05:48 Quit jhMikeS (Nick collision from services.)
14:05:54 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS)
14:06:17gartraland i see a typo now, i put "on" instead of "only"
14:08:02*scorche fixed 3 typos ;)
14:08:39gartralthanks scorche, im sorry to have to create o much work for yoo
14:08:43gartralyou*
14:09:01n1sgartral: is your bug different to http://www.rockbox.org/tracker/task/9654 ?
14:09:22scorchen1s: looks the same to me
14:09:42gartralnope, tat workaround doesnt work for me
14:09:56gartralthat* (smegging keyboard)
14:10:13gartralother than that, no difference
14:10:20 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca)
14:10:33n1sok, and you have enabled "Gather runtime data" and initialized the database?
14:10:37scorchehowever, the "bug" is the same...perhaps a comment would be better saying that you ahve the same bug, but the workaround does not work
14:10:57scorchen1s: the option isnt even there if you have not enabled gather runtime data
14:11:03n1soh
14:11:15gartraland also, i just tryed setting the rateing with winamp. that resulted in the player freezeing on that particular track
14:11:52gartraler, after reloading it too the player, that is :)
14:12:55 Quit alexbobp (Read error: 104 (Connection reset by peer))
14:12:57domonoky /me detects that with rockbox i can also measure voltage changeing on the wheel of e200v2, but its only 0V - 0.5V, while the OF has 0-3V ...
14:13:03n1sgartral: that sounds like a separate bug, please file it and attach the file if it's reproducible
14:13:25scorchei dont think our implementation of rating is consistent with the tags, but i am not too sure..
14:13:41n1sgartral: i get the same behaviour like you with setting song ratign if i have not initialized the database, have you initalized yours?
14:14:10 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net)
14:14:11n1sscorche: afaik we never save/read rating from the actual file
14:14:20gartralyes, and its set to auto update
14:14:30*scorche nods at n1s
14:15:04gartralthen why would it freeze after winamps rating tag was applied to it?
14:15:16n1sbugs?
14:17:07gartralhumm, i cant find any indication that the database initilises at boot, even when set to auto update
14:17:24scorcheit only needs t be initialized once
14:17:27gartral[i know, speeling is horrible today]
14:17:51*domonoky measures more: the OF also has 0-0.5V if the Display is off (same as rockbox). With display on, i get 0-3V in the OF and 0-1V in rockbox.
14:18:25 Quit B4gder ("It is time to say moo")
14:19:38 Quit BigBambi_ (Remote closed the connection)
14:20:08n1sgartral: can you browse the database on the player?
14:21:09Lssi have some file titles that only show up partially both from database and filesystem
14:21:13Lsshow can i fix it
14:21:45gartraln1s: yea, its a tad jumbled, but thats par for my player
14:21:53 Join stoffel_ [0] (n=sfr@p57B4E146.dip.t-dialin.net)
14:22:02J-23who's Display? :P
14:22:38n1sgartral: if you can browse it, it must have initialized at some point so, your bug is different from another minor one i found regarding the rating...
14:23:31n1sLss: what do you mean by "file titles"? the only thing that will show up in the filebrowser is the file name.
14:23:38gartraln1s: hmm, i wonder whats causeing this
14:24:36n1sgartral: is rockbox consistently freezing when you try to play the file modified by winamp?
14:25:05gartralit did it twice, then i deleted it
14:25:25n1sthat doesn't help in fixing the bug...
14:25:35gartralwant me to try again?
14:25:40n1splease do
14:25:50gartrallol, one step ahead
14:26:07gartraloddly enough, this it plays
14:26:15gartralthis time*
14:26:24Lssthe tags are obtained from the filename
14:26:35jhMikeSn1s: was that reading after the charger stopped?
14:26:40gartraland audiocis coheriant
14:27:04n1sjhMikeS: i wasn't looking at the time but the highest value in the graph was 4.205V
14:27:15 Quit Schmogel (Read error: 104 (Connection reset by peer))
14:27:15gartral[please excuse my poor typing today]
14:28:11 Join alexbobp [0] (n=alex@69.149.25.200)
14:28:29jhMikeSn1s: then that would be with charger on which is expected.
14:28:37 Join BigBambi [0] (n=alex@72.198.66-86.rev.gaoland.net)
14:30:56gartraljust as a side note: would it be possible to add something to control the length of time the fade in/out function lasts? or is this here and im just blind and stupid?
14:31:09Lsshuh i thought its there
14:31:21n1sgartral: which fade?
14:31:37n1sjhMikeS: ok, will you commit soon then? :)
14:31:52gartralbacklight fadeing, on E250 V1, most recent build
14:32:42n1sgartral: it's fixed duration because of the low number of possible levels so longer duration would flicker
14:33:11gartralahh hah, is this in the NO DO, or can I possibly add that one?
14:33:37jhMikeSn1s: soon, yes. I'm just looking it over some more to make sure.
14:34:06BigBambigartral: You can add it for yourself, but I would guess it is unlikely to get in
14:34:08n1ssounds good, looks like we can call it "supported" soon then :)
14:35:27*jhMikeS is just wondering if some minor concessions in powermgmt.c violate feature feeziness
14:36:07*moos thnks we can change the topic, freeze is overv :)
14:36:13moos-v
14:36:14gartralBigBambi: ok, logical question would be: is the limited number of "levels" a mendable problem, or is it a hardware restriction?
14:37:32BigBambioften hardware
14:37:39BigBambibut I think it depends on target
14:38:43gartralhmm, wouldnt be too easy to determin that, would it?
14:38:56moosBgBambi: could you change the #rockbox topic, freeze is over...; hi btw
14:39:11*moos canot type neither today
14:39:22BigBambimoos: I can't, no
14:39:33BigBambimoos: but scorche can :)
14:39:48Mode"#rockbox +o scorche " by ChanServ (ChanServ@services.)
14:39:50 Quit stoffel_ ("Lost terminal")
14:39:57moosok :)
14:40:04Topic"Please read before speaking: http://www.rockbox.org/wiki/IrcGuidelines | Please direct offtopic/social chat to #rockbox-community | 3.1 is branched!" by scorche (i=Blah@rockbox/administrator/scorche)
14:40:11Mode"#rockbox -o scorche " by ChanServ (ChanServ@services.)
14:40:26BigBambigartral: You could have a look at the code to see I'd imagine
14:40:28*jhMikeS generally logs in automatically and so rarely sees the IRC topic...ever
14:40:43gartrali would if i could understand it...
14:40:45scorche/topic ! ;)
14:40:55BigBambigartral: hehe :)
14:41:14*jhMikeS should probably do /topic at least once a day
14:41:22***Saving seen data "./dancer.seen"
14:41:46gartralplus my comp over heat if i try and compile anything more comples then and oga|mp3 file
14:42:06gartralheats*
14:42:18gartralcomplex* >.<
14:42:56*jhMikeS also knew about /topic btw :) simple laziness
14:44:07moosscorche: thanks, last freeze/release was indicated on rockbox.org, not this time
14:44:26 Nick gartral is now known as Gartral (n=Gareth@75.33.70.77)
14:47:15 Quit BigBambi (Remote closed the connection)
14:48:28 Join BigBambi [0] (n=alex@72.198.66-86.rev.gaoland.net)
14:51:23 Join Schmogel [0] (n=Miranda@p3EE21D48.dip0.t-ipconnect.de)
14:51:38 Join Horschti [0] (n=Horscht@p4FD4C8CF.dip.t-dialin.net)
14:51:52n1shmm, the "Anti skip buffer" description in the manual is both very long and confusing...
14:51:54 Quit Horscht (Nick collision from services.)
14:54:37 Quit fredddy (Read error: 110 (Connection timed out))
14:54:51 Join fredddy [0] (n=freddy@p3E9E3008.dip0.t-ipconnect.de)
14:58:17 Quit miepchen^schlaf (Read error: 104 (Connection reset by peer))
14:58:58Gartralwhere in the smegging source can i find the call to fade the backlight?
14:59:49fdinelDomonoky: I sent you the disassembly :)
14:59:55n1sany opinions on replacing the current description with this http://pastebin.com/m6463db38 ?
15:00
15:00:09domonokyfdinel: thanks..
15:00:50 Join miepchen^schlaf [0] (n=miepel@p579EC669.dip.t-dialin.net)
15:00:53BigBambin1s: Sounds fine
15:01:18n1sBigBambi: cool :)
15:01:42BigBambiPerhaps add a bit about keeping it as low as possible?
15:02:35BigBambi"However a high value increases how often the buffer has to be refilled, and thus reduces battery life somewhat. It is therefore desirable to keep this setting as low as possible without skips occuring."?
15:02:45BigBambimaybe something like that
15:02:45domonokyfdinel: and it would be very nice, if you could take a look at where the wheel is read. I hope to find some time to work on this over the next days.
15:04:38Gartralnvm, im totally efing retarded
15:06:34BigBambin1s: I take it you either didn't see or didn't agree with my last comment? :)
15:07:37n1sBigBambi: ah, missed it, there is a note about the battery life but maybe your way is better...
15:07:47BigBambiI'm not sure
15:07:54BigBambiLet me have a look at what is there now
15:09:10BigBambin1s: Ah no, what is there is fine I think
15:09:20BigBambin1s: I just missed the note first time round
15:09:48n1sok, will commit to the branch too then, thanks for looking :)
15:10:59Gartrali cant even find the part where the backlight is defined...
15:12:19 Quit n1s ()
15:13:37Gartrali see where its mentioned, and called, but not where its defined
15:19:11domonokyGartral: you mean the actual functions to disable/enable the backligt ? take a look a the target tree..
15:23:03Gartralhmm, i cant see a way to modify thecode to make a coherient fade timer, though i suspect it would be possible if you found a way to freeze the backlight switch as it steps down
15:27:34Gartralim not gonna bother butchering the code, especially when i cant compile it myself
15:30:00 Quit faemir (Remote closed the connection)
15:31:50MintheUmm, there are still some craps in wma files, so I have to talk with saratoga...
15:34:34 Quit Minthe ("Leaving...")
15:34:47 Join dfkt [0] (i=dfkt@unaffiliated/dfkt)
15:36:34domonokyGartral: if you dont want to "butcher" (what ever that is) the code, why are telling it to us ? And compiling isnt difficult... there are various Howtos in the wiki.
15:39:13Gartralits not that, its that by the time im done, it wouldnt work, anyway, and the compileing issue is not that its difficut, its that my comp overheats when it trys to compile anything
15:44:58 Quit courtc (Read error: 60 (Operation timed out))
15:45:01 Join courtc [0] (n=court@unaffiliated/courtc)
15:57:16 Join frinkazoid [0] (n=waldo@ip-81-11-230-38.dsl.scarlet.be)
15:57:20 Join lasser [0] (n=chatzill@Wb869.w.pppool.de)
16:00
16:02:20 Join Aurix_Lexico [0] (n=comrade@c-68-56-205-239.hsd1.fl.comcast.net)
16:08:18soapthat's an underlying issue which should be addressed independently of any desire to work with Rockbox
16:11:18 Quit herrwaldo (Connection timed out)
16:11:40 Quit Jaykay ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]")
16:14:42 Part Gartral
16:23:07 Quit mud-rb (Read error: 113 (No route to host))
16:39:13 Quit Darksair ("Do you hear that? This is the sound of inevitability. This is the sound of your death, Mr. Anderson.")
16:39:47J-23hm, does Rockbox use anything like swapfile on targets with small RAM?
16:41:26***Saving seen data "./dancer.seen"
16:41:50soapswapping what?
16:43:20 Quit Llorean (Read error: 104 (Connection reset by peer))
16:44:04BigBambiJ-23: We want to buffer audio in memory so that the disk doesn't have to be spun up - swapping to disk would defeat the point
16:45:12 Join saratoga [0] (n=41becb3b@gateway/web/cgi-irc/labb.contactor.se/x-05ae7e7a3b055ce4)
16:45:49soapexample: Load encoded (MP3, etc) file into ram, decode PCM to disk, remove encoded file from RAM, load decoded PCM to RAM, lots of disk. Better to just work with smaller pieces of audio.
16:46:20 Join Llorean [0] (n=DarkkOne@adsl-65-68-72-166.dsl.hstntx.swbell.net)
16:46:27 Join kugel [0] (n=chatzill@unaffiliated/kugel)
16:47:09 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother)
16:48:51 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr)
16:49:40 Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]")
16:53:42 Quit vitja (Read error: 104 (Connection reset by peer))
16:57:51 Join thresh [0] (n=popa3d@videolan/developer/thresh)
16:58:00 Part thresh
17:00
17:05:08 Join tvelocity [0] (n=tony@athedsl-413299.home.otenet.gr)
17:23:22 Nick JdGordon is now known as JdGordon|zzz (n=jonno@rockbox/developer/JdGordon)
17:30:58 Join n1s [0] (n=nils@rockbox/developer/n1s)
17:39:30bluebrotherXavierGr: interested in updating the greek rbutil translation? Would be nice to have it updated before creating new binaries
17:39:54XavierGrsure, when are you going to build the binaries?
17:41:33bluebrothermost likely this evening −− not sure if I have access to my windows build box the next couple of days
17:41:57XavierGrok let me remember how to do it and will do it asap
17:41:59bluebrotherconsidered putting the machine on a usb stick but forgot that FAT32 can't handle 5GiB files :(
17:42:08XavierGrdo you know how many missing strings are there?
17:42:19 Part XavierGr
17:42:24bluebrotherjust use linguist from the Qt installation ;-)
17:42:42 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr)
17:42:53XavierGrok will do
17:43:11moosXavierGr: http://www.rockbox.org/twiki/bin/view/Main/RockboxUtilityDevelopment#Translation_status_updated_2008
17:43:32XavierGrthanks
17:43:33bluebrotheraccording to the stats on RockboxUtilityDevelopment currently 102. But it might be possible to reuse old strings −− you should keep an eye on the "suggestions" pane on the bottom in linguist
17:44:40 Quit killan ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )")
17:47:04 Join kushal_12_27_200 [0] (n=kushal@c-71-230-163-208.hsd1.pa.comcast.net)
17:49:47 Quit n1s ()
17:57:32 Join ZincAlloy [0] (n=d9eec502@gateway/web/cgi-irc/labb.contactor.se/x-f2583d1bb8b191de)
17:57:33kugelfdinel: hi :)
17:58:59fdinelhey kugel
18:00
18:00:37kugelfdinel: thanks again for your disasm, I'm still in the process of understanding the code, but I got most ;)
18:01:23kugelfdinel: What I'd find interesting would be if this func is called in an isr or in a tick task. I found only 1 reference to that function in objdump's disasm
18:02:19fdinelkugel: yeah well it's called in the "user interface" task (thread), which makes sense ;)
18:02:27 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb)
18:02:40kugelfdinel: so in in an isr?
18:02:45fdinel(well not directly but still)
18:02:57kugelI mean it can be both together
18:03:10fdinelnot an ISR no, but a thread which is called once every x time
18:03:20 Join Acky [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com)
18:03:26kugelthat's a tick task ;)
18:04:01fdinelyep :P
18:07:11kugelfdinel: the BOP_CTRL_REG- DBOP_CTRL_REG stuff is quite confusing
18:07:34kugelI mean those "#(DBOP_CTRL_REG - DBOP_CTRL_REG)]"
18:07:37XavierGrbluebrother: what's the string "progresswindow" under ProgressLoggerFrm? Am I supposed to conatenate these 2 words?
18:08:22kugelI'd think that equals to #0, but it doesn't. the objdump disasm is clearer here
18:10:25 Join toffe82 [0] (n=chatzill@75.12.168.247)
18:11:51 Quit Acksaw (Read error: 145 (Connection timed out))
18:11:52bluebrotherXavierGr: that's from an accessibility description. I think this needs to get cleaned up −− it isn't shown anywhere so you could simply ignore it
18:12:47domonokybluebrother: it isnt shown, but it gets voiced :-)
18:14:03 Join killan [0] (n=nnscript@c-415472d5.06-397-67626721.cust.bredbandsbolaget.se)
18:16:08XavierGrso should I keep it together or as saperate words?
18:16:13XavierGror ignore it?
18:16:57kugelfdinel: bpl is branched if bit 31 is, right?
18:17:07kugelbit 31 is 0 i mean
18:17:57kugelwell, if the N flag isn't set, so yes, 0
18:18:31 Quit killan (Client Quit)
18:18:43 Join killan [0] (n=nnscript@c-415472d5.06-397-67626721.cust.bredbandsbolaget.se)
18:24:02 Join karashata [0] (n=karashat@69.41.192.215)
18:24:16 Quit {phoenix} (Remote closed the connection)
18:32:27 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
18:33:10 Quit beta2k_ (Read error: 110 (Connection timed out))
18:38:02 Quit saratoga ("CGI:IRC (EOF)")
18:41:30***Saving seen data "./dancer.seen"
18:42:20 Quit Schmogel (Read error: 110 (Connection timed out))
18:51:33 Quit ZincAlloy ("CGI:IRC (Ping timeout)")
18:56:21 Quit karashata ("G'bye everyone!")
19:00
19:13:09 Join karashata [0] (n=karashat@69.41.192.215)
19:14:32 Join PaulJam [0] (n=pauljam@p54BED00D.dip.t-dialin.net)
19:21:19 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
19:21:23 Quit tvelocity (Remote closed the connection)
19:23:10XavierGrbluebrother: how much time do I still have? I need to finish 22 strings.
19:37:56 Join Schmogel [0] (n=Miranda@p3EE21C0D.dip0.t-ipconnect.de)
19:40:53 Quit jhMikeS (Nick collision from services.)
19:40:59 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS)
19:41:53 Quit karashata ("G'bye everyone!")
19:44:23 Join karashata [0] (n=karashat@69.41.192.215)
19:47:06kugelSUCCESS!!!!!!!
19:48:25domonokykugel: buttons with dbop ?
19:48:25kugeldomonoky: ping
19:48:30kugelheh
19:48:31kugelyes
19:48:37 Quit gromit` (Read error: 60 (Operation timed out))
19:48:49domonokycongratulations ! :-)
19:49:06kugelhttp://pastebin.ca/1290294
19:49:44 Quit kushal_12_27_200 ("Leaving")
19:49:46kugelpurely based on disassembly
19:51:34kugelnow I need to find which bit is which button
19:56:30 Join gromit` [0] (n=gromit@ALagny-154-1-67-253.w86-203.abo.wanadoo.fr)
19:58:33 Quit PaulJam (".")
19:58:54domonokykugel: with this code i can only detect power and down again. Can you read all buttons on fuze with this ?
20:00
20:00:07bluebrotherXavierGr: no hurry ... I guess I won't start building the next 3 hours. Maybe I can get it done tomorrow morning instead, need to check my timetable
20:00:32kugeldomonoky: I haven't yet looked at the return too much, but I can surely say hold button can be detected too
20:00:48 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey)
20:04:22 Join Acksaw [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com)
20:07:07 Join Strife89 [0] (n=michael@204.116.245.152)
20:08:46*lucent raises an eyebrow with interest
20:10:40 Quit Acky (Read error: 60 (Operation timed out))
20:10:46 Join Acky [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com)
20:15:53 Quit Strife89 ("Bye people.")
20:15:59XavierGrbluebrother: FS #9688, didn't manage to compile rbutil to be sure that it works though. I just run linguist and updated the missing strings. Will try again later this night
20:16:07 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca)
20:19:49 Join {phoenix} [0] (n=dirk@p54B45D4C.dip.t-dialin.net)
20:21:49domonokykugel: at least on e200v2, i can only detect power and down. no other button seems to work :-/
20:21:59kugeldomonoky: uhmm, I cannot seem to get only those 3 too
20:22:45 Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-25c7af85b4685f94)
20:23:30 Quit Acksaw (Connection timed out)
20:23:51kugelmaybe we need to reset the input before
20:25:42bluebrotherXavierGr: if linguist thinks the file is ok then there shouldn't be any issue.
20:29:32 Join stoffel_ [0] (n=sfr@p57B4F801.dip.t-dialin.net)
20:30:38 Quit {phoenix} (Remote closed the connection)
20:31:41 Quit toffe82 (Read error: 110 (Connection timed out))
20:31:56 Part XavierGr
20:32:02 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr)
20:40:22bluebrotherXavierGr: accepted and committed. Thanks for the fast update :)
20:41:33***Saving seen data "./dancer.seen"
20:46:31XavierGrbluebrother: I should thank you, you are welcome too :)
21:00
21:07:55 Join alexbobp_ [0] (n=alex@69.149.25.200)
21:08:45 Join mc2739 [0] (n=mc2739@cpe-67-10-238-175.satx.res.rr.com)
21:10:37 Join Kitti [0] (n=himka_co@195.5.125.25)
21:10:57 Quit BHSPitLappy (Read error: 104 (Connection reset by peer))
21:13:40 Quit gevaerts (Nick collision from services.)
21:13:49 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts)
21:18:38kugelfdinel: hey, bad news
21:21:26 Part Kitti
21:24:08 Quit alexbobp (Connection timed out)
21:30:10domonokybluebrother: when do you want to tag the new rbutil release ? (i can build the mac-binary either today, or tomorrow morning. After that, it gets difficult.)
21:36:17 Join Zagor [242] (n=bjst@rockbox/developer/Zagor)
21:43:39kugeldomonoky: it's a bit weird isn't it? we should get at least the buttons we get reading directly
21:45:59 Quit karashata ("G'bye everyone!")
21:53:56 Join {phoenix} [0] (n=dirk@p54B45D4C.dip.t-dialin.net)
21:55:01 Join ZincAlloy [0] (n=d9eec502@gateway/web/cgi-irc/labb.contactor.se/x-95cf6fd063dc2513)
21:57:49 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com)
22:00
22:05:34 Join Martyn [0] (n=martinb@adsl-70-231-242-168.dsl.snfc21.sbcglobal.net)
22:08:11 Join aneqrs [0] (n=andreas@c83-253-104-206.bredband.comhem.se)
22:14:55bluebrotherdomonoky: soonish, at least until midnight.
22:15:13bluebrothertoo bad the french translation hasn't been updated yet.
22:15:31kugeldomonoky: do you get int_btn == 0 regulary?
22:15:43kugelI do, which shouldn't happen
22:16:19domonokykugel: no, its always set to 843 if i dont press anything.
22:16:54kugelsame for me, but completely 0 every 5th read or so
22:20:05 Quit stoffel_ ("leaving")
22:21:29 Part Martyn
22:23:19 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey)
22:29:57kugeldomonoky: any idea why we cannot read the buttons we get with direct gpio reading? maybe lcd is set up wrongly?
22:34:44domonokykugel: no idea at moment..
22:39:13 Join MethoS- [0] (n=clemens@host-091-096-214-033.ewe-ip-backbone.de)
22:40:05Unhelpfulamiconn: actually, i need to change my plan, the album art text *can* render over the images... it *looks* like the buffer for buffered greylib is still just W*H uint8, so i can probably draw to that, and then use greylib's puts, and then call grey_update()... this will also make pretty much everything the same as the color case, except for passing a plugin to the bitmap loader, the data type of the buffer, etc
22:41:35***Saving seen data "./dancer.seen"
22:47:49kugeldomonoky: have you put some delay between button_read_device? maybe it's just too fast so you don't se it returning 0
22:54:07Zagorcan someone tell me what the difference is between the watermarks in buffering.c and plaback.c?
22:54:14 Quit Bensawsome (Nick collision from services.)
22:55:39 Join mcuelenaere [0] (i=mcuelena@rockbox/developer/mcuelenaere)
22:55:43 Quit BHSPitLappy (Remote closed the connection)
22:56:50 Join Bensawsoj [0] (n=Bensawso@server.lethaltechnology.net)
22:58:04 Quit Zagor ("Leaving")
23:00
23:00:00 Quit Horschti ("I am root. If you see me laughing, you better have a backup")
23:06:47 Join Horscht [0] (n=Horscht@xbmc/user/horscht)
23:24:37 Quit fredddy (Read error: 110 (Connection timed out))
23:25:26 Join fredddy [0] (n=freddy@p3E9E2148.dip0.t-ipconnect.de)
23:32:04*bluebrother prepares releasing rbutil
23:32:33bluebrotheror rather creating binaries to be released with Rockbox 3.1
23:32:52gevaertsGreat :)
23:35:19 Join freddy__ [0] (n=freddy@p3E9E1FCE.dip0.t-ipconnect.de)
23:38:50 Join hillshum [0] (n=hillshum@75-165-241-153.slkc.qwest.net)
23:39:35Bagderhttp://www.muppethouse.com/rockbox-i-hated-it-now-i-like-it/
23:39:49Bagdera random friendly blog post
23:45:16_Auron_I can't wait until v2s are supported.. everytime I unplug my sansa it spends about 3-4 minutes 'refreshing'
23:45:20_Auron_even if I didn't change anything
23:45:31 Nick alexbobp_ is now known as alexbobp (n=alex@69.149.25.200)
23:45:57_Auron_that 10 seconds of boot time is nothing compared to that
23:49:19 Join QUICKSTART [0] (n=QUICKSTA@pool-72-88-166-100.nwrknj.east.verizon.net)
23:49:57 Quit fredddy (Read error: 110 (Connection timed out))
23:50:23 Quit EspeonEefi ("さよăȘら")
23:53:06 Nick Bensawsoj is now known as Bensawsome (n=Bensawso@server.lethaltechnology.net)
23:55:26Unhelpfulhrm, is calling grey_show() slow at all if the state is not changing?
23:55:30amiconnUnhelpful: I can think of several possible solutions for this. First, we can declare the greylib's internal buffer to be publicly accessible. There's a potential caveat though - the overlay width and height are aligned (as explained earlier) and hence are not necessary equivalent to what was passed to the lib
23:56:45amiconnSecond, it would also be possible to write some more unbuffered drawing functions. So far there just was no need though, and these functions would be somewhat more complex than the buffered ones
23:56:46Unhelpfulso the internal buffer *is* uint8, but the width and height may have been rounded from the requested ones
23:56:57amiconnyes
23:57:10Unhelpfulok, i can work with that.
23:57:25amiconnThird (easiest), you could just use buffered mode, and live with the extra copying
23:58:20Unhelpfuli think first is actually easiest, in this case, since once i fix up the rounded width/height, the greylib buffer in buffered "works" the same way as lcd_buffer

Previous day | Next day