--- Log for 29.08.109 Server: orwell.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 2 days and 1 hour ago 00.00.37 Quit explore ("Lost terminal") 00.00.53 Quit snuupy ("CGI:IRC") 00.01.10 # Buschel_: woot, nice works on ATRAC, congrates. 00.01.21 Join killan [0] (n=nnscript@c-0efa70d5.06-397-67626721.cust.bredbandsbolaget.se) 00.02.30 # moos: performance is affected (but not really noticeably). The skin engine isn't exactly little code. I'm currently limiting the updates a bit so that the statusbar doesn't redraw at each item selection in the list 00.03.26 # sounds nice, and looks sexy :) 00.04.09 # and it doesn't really have any cost if it's unused (except binsize and ramusage of course) 00.05.08 # *and* it allows AA on the menu screen (if you're careful) 00.05.19 # moos: thanks :) 00.05.22 # kugel: We are closer to see custumizable skin for recording and radio it seems with all your reworks (you and Jd), right? 00.05.22 # but it's probably all imagination. My targets don't really allow to even get a feeling if the statusbar affects anything 00.05.28 # Buschel_: I am now. I have seen the patch, but haven't tried it yet. But definitely great work ! :) 00.05.40 # Buschel_: merci to you :) 00.06.06 # moos: I'll leave the radio and recording somebody else :p 00.06.22 # hehe, already nice :) 00.06.44 # the problem with those screens is that actual information is different 00.07.17 # the sb is just a wps within the UI, the information (i.e. metadata and stuff) is all shared with the wps 00.08.11 # mt: perfect :) From what I understand from the code the dewindow-coefs are s0.31 format. Reducing it to s0.16 should be no real problem... The output must be compared of course. 00.08.33 # moos: scrolling through a giant list doesn't seem to be slower 00.08.49 # kugel: your works (with Jd) could make things a bit easier for futur adventureres :) 00.09.03 # meh, the fuze's scrollwheel isn't responsive enough in general 00.10.32 # AAF will be nice also :) 00.11.19 # but yea, the sb is awesome :) I really like it 00.11.35 # * moos likes too a bit of eyes candy when possible 00.11.47 # kugel: it does point to some missing features elsewhere :) 00.12.03 # * moos hides from amiconn :) 00.12.04 # * gevaerts wants multiple-sized AA 00.12.07 # gevaerts: how did the album art adventure turn out? 00.12.13 # (joke here of course :) 00.12.15 # that's a job for Unhelpful :) 00.12.41 # kugel: it seems to be mostly working, provided you only have one %Cl, in the wps file 00.12.42 # moos: he's already bitter about the AAF, the sb might get unnoticed :p 00.13.01 # sorta what I expected 00.13.12 Part iamben 00.13.23 # kugel: how about bin/RAM cost? He surely will see the reds ;P 00.13.32 # I think it can be considered as working by accident. Maybe it's best to disable it in the sb (if possible) 00.13.33 # it's not much 00.14.05 # not exactly working by accident, I always had it in my mind, but ignored it for now :p 00.14.08 # * gevaerts imagines that the custom status bar could be really fun on the mr500 00.14.23 # Buschel_: I'll take a quick look at the dewindow coefficients now. I also thought about making use of the symmetry in the mdct window but didn't think it was going to make a noticeable difference ? 00.14.43 # I wouldn't even disable it. Saying only "%C" is allowed in the seems OK to me 00.15.04 # conditional seems to work as well 00.15.13 # gevaerts: yea, the touchregion stuff doesn't work though 00.15.20 # Buschel_: But surely I should've avoided the mutiplies where the window coefs were unity. 00.15.40 # I meant the tag, which includes the conditional version of it :) 00.15.49 # Buschel_: back 00.15.53 *** Saving seen data "./dancer.seen" 00.20.00 # mt/saratoga: I am still not sure about the precision of the dewindowing. e.g. mpc/mp3 use s1.16 but do only have 1 iqmf stage. atrac3 uses 2 stages and may therefore be more sensitive to rounding errors. 00.20.08 # moos: what target(s) do you have? Are you testing/running the custom sb patch already? 00.20.21 # mt/saratoga: but 8MHz sound interesting ;-) 00.21.06 # Buschel_: Definitely ! 00.21.32 # * mt has to go for a while .. bbl 00.21.37 # Buschel_: I saw your ASM'ifying patch, and thought "the C versions already don't look really optimized" 00.22.10 # kugel: which parts of it? 00.22.37 # fixmul* 00.23.07 # kugel: you are talking of the macros themselves? 00.23.24 # the C versions (the ones you replace by asm for arm) 00.23.44 # I have no idea if that asm can be done better or worse :p 00.24.23 # those asm versions are more or less standard in our other codecs. so, I am pretty sure they are efficient enough ;-) 00.24.42 # kugel: I always use plain SVN build but for testing purpose. I use my beast those last weeks (have few others targets for test too). I I have chance, I'll have a go later tonight (have to go in a few...) 00.25.25 # 453 open patches is a sad amount 00.25.27 # kugel: the 32.0 one evaluates to a single instruction, so its as fast as you can do 00.25.50 # the others use 2 or 3 ops, which is also about as fast as possible without hardware support for fixed point math 00.25.56 # the C code? 00.29.23 # no the asm versions 00.29.43 # I'm talking about the C code all the time :/ 00.29.52 # oh they're quite slow 00.30.06 # I think you save 30 or 40MHz getting rid of them 00.30.45 # yea, I'm thinking the C code doesn't look very effective. maybe those can be done a little faster without asm 00.30.53 # there is also fast asm available for coldfire. someone should adapt an test it. 00.31.15 # hmm i wonder if the D2 cache on codec load is the same as the one on AMS due to lack of cache coherency 00.35.33 # :? 00.35.37 # D2 cache? 00.36.11 # sorry crash 00.36.46 # possibly 00.37.32 # ok guys, I need some sleep now... keep me updated about the precision and symmetry stuff :o) good night! 00.37.33 # anyone with a D2 want to try something 00.37.41 # thanks for your help 00.37.51 Quit Buschel_ () 00.48.10 Join Hillshum [0] (n=hillshum@75-165-247-150.slkc.qwest.net) 00.52.32 # * Unhelpful really thinks that pretty much anybody could handle loading an AA multiple times with different sizes. :P 00.53.16 # is buffering prepared for that? 00.53.21 Quit FOAD ("I'll be back") 00.53.39 Join FOAD [0] (n=dok@dinah.blub.net) 00.53.46 # I think only you can do it :p 00.55.09 Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 00.58.25 Quit stoffel (Remote closed the connection) 01.01.24 # i think that there are already quite enough things in RB that only one person knows enough about to modify. :/ 01.01.47 # haha 01.02.14 # well, I'll have a look...later 01.02.15 Quit jgarvey ("Leaving") 01.02.21 # in a month or so :) 01.03.32 # Unhelpful: bus factor =/ 01.03.41 # if you don't care for the maximum efficiency, you can really just do it now by bufopen-ing the image file a few more times... and making the size passed to bufopen instead of grabbed from the WPS. 01.04.50 # * kugel still dreams of tiny album art pics all around the place 01.07.03 Join JdGordon_ [0] (i=483e79d3@gateway/web/freenode/x-zkmgnnjaafiqhiyz) 01.10.06 # kugel: RAM usage increas on gigabeat F is 4208 bytes 01.10.23 # that's all? 01.10.36 # apparently 01.10.40 # remembers something about 6k on his sansa 01.11.52 Quit Hillshum ("Ex-Chat") 01.12.02 # lame, freeze time next week? 01.12.53 # 3.5 will be an awesome release :D 01.13.03 # theme wise yes 01.13.10 # especially if wfm gets in for that also 01.13.54 # by the way... the filenames should be sbs and fms.... statusbar skin and fm skin... 01.13.59 # kugel: not specifying a standard works fine. -std=gnu89 also works fine, perhaps we should be explicit in case defaults change at some point? 01.14.16 Quit faemir (Read error: 54 (Connection reset by peer)) 01.14.27 Join faemir [0] (n=faemir@78.33.109.163) 01.15.23 # Unhelpful: is it even a good idea to autobuild convttf? it has external dependencies 01.16.24 # also, could it be used for monofonts? It's way more convenient than the ttf2bdf + convbdf combo 01.17.04 Join unfair83 [0] (n=opera@CPE0013108b928e-CM000f9fa81f60.cpe.net.cable.rogers.com) 01.17.08 # i think we should at least have rules in the build system to allow us to build it easily. maybe it shouldn't be auto-built until we start shipping some ttf fonts. :) 01.19.08 # hey, does rockbox support m4b files well? i tried playing some and it didn't work 01.19.31 # m4b?! 01.21.43 Quit bertrik (Read error: 113 (No route to host)) 01.24.24 # m4b is m4a for audiobooks 01.27.13 # did you try renaming it? if it's *really* an mpeg-4 container with AAC audio, it *should* play, but RB probably doesn't know what it is with a funny extension like that. 01.29.24 Quit unfair83 (Remote closed the connection) 01.29.58 # I thought the m4b extension was added ages ago 01.30.09 # as far as I can see, rockbox should support m4b. Of course, there's the usual DRM caveat 01.30.18 # That seems more likely 01.30.55 # don't we also have some issues with mp4 containers having unusual ordering of atoms? 01.34.17 Quit JdGordon_ (Ping timeout: 180 seconds) 01.44.21 # fyi look what I found: http://shop.froobi.com/SanDisk-Sansa-e280-MP3Media-Player-Factory-Recertified-Rockbox-Ready_p_78-32283.html=DEALNEWS081003 01.44.32 # "Using the code ROCKBOX10 it brings the price down to 49.99" 01.44.35 # :) 01.47.13 # JT|work: they have them in stock again? ;) 01.49.35 # kugel: i don't think that adding mono rendering of vector fonts would be a huge problem. handling bitmap fonts might be troublesome, or at least messy, as their metrics are handled differently. 01.50.36 # * kugel sees that wikipedia lists "a simple markup language can be used to create themes for the menu and while-playing screens" 01.50.53 # for *menus* also? 01.52.15 Join Thundercloud_ [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 01.53.12 Quit Thundercloud (Read error: 60 (Operation timed out)) 01.55.51 # New commit by 03kkurbjun (r22523): Brickmania: Try to clean up some of the paddle collision code and add comments. Gameplay should be the same. 01.57.38 # * kugel slaps kkurbjun 01.57.48 # ouch 01.57.49 # enum members in UPPER CASE please :) 02.00.30 # as per docs/CONTRIBUTING 02.00.39 # aye aye, I'm changing it 02.02.07 # New commit by 03kkurbjun (r22524): Brickmania: Capitalize the enum. 02.03.33 # kkurbjun, JdGordon: Anyone keen on looking into touchregions for the custom statusbar (maybe after it's in). They're unhandled right now, since all the handlers are in the wps and I haven't really focused on that 02.04.07 # we need to think about if it even makes sense to have them 02.04.56 # I'd definitely want that if I had such a target 02.04.58 # I think it could be useful - it could add all of the functionality other targets have when you're viewing a list 02.05.09 # or menu 02.05.19 Quit GeekShadow (Read error: 104 (Connection reset by peer)) 02.05.21 # even more 02.06.04 Quit ender` (" The reason they call it the American Dream is because you have to be asleep to believe it. -- George Carlin") 02.09.06 # kugel: doing the math, word-at-a-time reads from glyph data cost an extra instruction per pixel, because (++x) %y can be done as a single instruction if y=2, but takes a second instruction otherwise. so, for each 8 pixels read, that's 8 extra instructions, and 3 reads saved. if cache works well, it's pretty easy to see how this could be a loser. :/ 02.10.20 # indeed, but it could still be worthwhile on cf 02.10.43 # and that's why i've got that revision stashed. does CF have no cache? :/ 02.10.49 # not all ARMs have cache either, IIRC 02.11.21 # no idea actually 02.11.59 # if the 3 saved reads are from DRAM without cache, this sounds much more winning :) 02.12.36 Join Sajber^ [0] (n=Sajber@c-923571d5.012-155-73746f22.cust.bredbandsbolaget.se) 02.14.22 Join saratoga_home [0] (i=463f90ed@gateway/web/freenode/x-qwkcrhokioljclvz) 02.15.04 # so it costs 8 pipelined instructions to save 3 loads? 02.15.55 *** Saving seen data "./dancer.seen" 02.16.14 Quit lyngaas (Remote closed the connection) 02.18.25 # saratoga: yes, because with byte-at-a-time reads the counter for the pixel within the current data is either 0 or 1, and can be updated with subcol ^= 1, a single instruction that can also set the flag for the condition test to read a new byte or shift the current one over. 02.19.08 # Unhelpful: on armv4, a load takes 2 clock cycles if theres a cache hit or IRAM, more if theres a miss 02.19.27 # so you have a best case of 6 clocks and a worst case of much more 02.19.59 Quit domonoky1 (Read error: 104 (Connection reset by peer)) 02.21.10 # saratoga: good to know the numbers. since the reads are sequential, i'm mostly expecting cache hits... so the 3 reads save 6 cycles per 8 pixels, while the extra bookkeeping costs 8. and that's just in the inner loop, there's a little bit of per-bitmap work extra as well. 02.21.19 # for sequential reads with cache i'd say this is a pretty clear loser 02.21.54 # unless there's some bounded increment instruction for ARM that i don't know about, or something like that? 02.23.24 # saratoga: iram is as fast as cache? 02.23.49 # if i invert the sense of subcol, so that it's counting pixels remaining, rather than the index within the current byte or word, i think i could reduce the per-pixel cost to 1/8 cycle 02.24.46 Join mark_____ [0] (n=mark@c-71-235-215-123.hsd1.ct.comcast.net) 02.25.46 Join langzeitstudent_ [0] (n=langzeit@p5B17D2F0.dip.t-dialin.net) 02.29.43 # kugel: they're very very close but not exactly the same under all conditions 02.29.55 # since disabling cache and running out of IRAM is a bit slower then running with cache and IRAM 02.30.32 # on PP 02.30.41 # AMS IRAM doesn't seem much different then DRAM 02.31.04 # soem other ARMs don't even use their IRAM 02.31.26 # kkurbjun: yeah, it would be great, but there is a fair bit of complexity we need to think about... like somehow we need to link a viewport with a touch handler... 02.32.06 # the skin_engine could handle touchregiouns on its own 02.32.16 Join Hillshum [0] (n=hillshum@75-165-247-150.slkc.qwest.net) 02.32.16 # according to the datasheet, the DRAM on the e200v2 can be clocked at 2x the speed of the IRAM, so that might have something to do with it 02.32.26 Quit Lss (Read error: 131 (Connection reset by peer)) 02.35.04 # how stable is rockbox for a clip v1? 02.35.58 # not very stable at all 02.36.22 # thanks 02.38.06 # I use it on a regular basis with a c200 and a e280 and love it. 02.38.15 Quit jfc (Read error: 54 (Connection reset by peer)) 02.41.49 Quit jboy_ (Read error: 110 (Connection timed out)) 02.43.55 # mark_____: I disagree, if you use if for low bitrate mp3s (podcasts etc.) like I do, you might have to tolerate a few crashes, but it's not too bad 02.45.27 # I was thinking og trying it with audiobooks and podcasts. 02.46.29 # mark_____: You'll have to compile it yourself of course 02.48.39 # I have never done that before but I do have the development environment on my linux system. 02.52.43 # The hardest part is getting a Unix system 02.53.04 # mark_____: There's docs in the wiki 02.53.50 Join jfc [0] (n=john@66.82.208.2) 02.54.40 # I have read them and I do not think I will have much of a problem. They also discuss it over at ABI. 02.59.40 # Building a linux system is not that big of a problem. Any older hardware will work fine. 03.02.34 # having a reasonably fast machine is nice though given the amount of files to be compiled 03.06.36 # True. My linux system is built on mini itx format running at 800mzh. Will eventually build a faster system. 03.11.12 # did anyone ever try to reproduce teh clip deadlocks in the Sim by reducing its compressed audio buffer? 03.14.42 # saratoga: hrm, what's the cost of skipped conditional instructions on ARM? 1 cycle? 03.15.04 # Unhelpful: I'm not sure 03.15.23 # i think on ARMv4 there would be no cost at all 03.15.43 # since the PC is unchanged and no stall should be needed 03.16.14 # none? surely some time is spent reading all of these instructions and deciding not to execute them? 03.19.34 # per arm7tdmi docs: "Any instruction whose condition code is not met does not execute and adds one cycle to the execution time of the code segment in which it is embedded" 03.19.59 # that's the flavor of quite a few of our armv4 devices, right? 03.20.12 # its all ARMv4 03.20.18 Join kamlurker [0] (n=chatzill@24.144.116.47) 03.20.31 # odd though, i'd expect it to just not write out the results at the end of the cycle if the code isn't true 03.20.49 # perhaps the lack of a write back stage prevents that 03.21.23 # i think it's saying that the time to (not) execute the instruction is 1 cycle... not 1 cycle + whatever execution would've cost. 03.24.15 # sorry i meant no additional cost 03.24.18 # this explains why i'm *still* not seeing an improvement by counting down instead of up. the reset of the counter to its maximum value is still costing a cycle each pixel, even though it's only executed when the counter hits zero. :/ 03.26.25 # gcc must have decided that the body of the two branches of the if() was too small to use a branch instruction... instead it's just subs and then a bunch of instructions with eq or ne conditions 03.28.19 Quit saratoga_home ("Page closed") 03.31.00 Quit mark_____ ("leaving") 03.31.35 Part JT|work ("bought what I *think* is a sansa e280 v1 off tigerdirect. cross your fingers!") 03.31.44 # Unhelpful: I had a quick look, playback/buffering is badly prepared for multiple AA sizes 03.32.59 Quit Thundercloud_ (Remote closed the connection) 03.36.07 Quit kugel (Remote closed the connection) 03.36.36 # kugel: ideally, we want a nicer way to load the same file at multiple sizes, too. 03.37.24 Quit togetic ("WeeChat 0.3.0-rc2") 03.51.16 Quit chandoo ("Leaving") 03.52.29 Join togetic [0] (n=togetic@unaffiliated/ibuffy) 03.53.04 Quit mt (Read error: 104 (Connection reset by peer)) 03.54.45 Quit Dhraakellian ("Kernel patch in a recent batch of updates... rebooting") 04.01.23 Quit togetic ("WeeChat 0.3.0-rc2") 04.05.48 Quit TheSeven (Nick collision from services.) 04.06.05 Join The_Seven [0] (n=theseven@dslb-084-056-146-066.pools.arcor-ip.net) 04.06.09 Nick The_Seven is now known as TheSeven (n=theseven@dslb-084-056-146-066.pools.arcor-ip.net) 04.16.00 *** Saving seen data "./dancer.seen" 04.27.07 Nick intrados_ is now known as intrados (n=intrados@cpe-71-67-138-190.woh.res.rr.com) 04.33.09 Join MG_Man [0] (n=MGMan@11.208.101.97.cfl.res.rr.com) 04.33.27 Join togetic [0] (n=togetic@unaffiliated/ibuffy) 04.37.24 # well, my theme didnt get taken off, so I guess it's all good 04.38.50 Join dys` [0] (n=andreas@95.115.76.241) 04.43.27 Quit Rondom (Nick collision from services.) 04.43.37 Join Rondom [0] (n=Rondom@dslb-084-057-184-198.pools.arcor-ip.net) 04.54.19 Quit dys (Connection timed out) 04.55.36 Quit panni_ ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 05.07.37 Quit Llorean ("Leaving.") 05.08.55 Join decayedcell [0] (n=decayed_@60-241-92-53.static.tpgi.com.au) 05.09.24 Join Dhraakellian [0] (n=ntryon@cpe-72-226-197-191.rochester.res.rr.com) 05.13.42 Quit Rob2222 () 05.14.00 Join Rob2222 [0] (n=Miranda@p4FDCD446.dip.t-dialin.net) 05.20.35 Quit MG_Man (Read error: 110 (Connection timed out)) 05.32.06 Join __lifeless [0] (n=lifeless@188.17.70.71) 05.32.37 Quit kamlurker ("ChatZilla 0.9.85 [Firefox 3.0.13/2009080315]") 05.42.11 Quit Hillshum (Read error: 110 (Connection timed out)) 05.47.28 Join Llorean [0] (n=DarkkOne@99-32-77-163.lightspeed.hstntx.sbcglobal.net) 05.49.06 Quit _lifeless (Read error: 113 (No route to host)) 06.16.03 *** Saving seen data "./dancer.seen" 06.20.54 Join MoD2 [0] (n=anonym@ppp-93-104-182-201.dynamic.mnet-online.de) 06.22.25 Quit MoD2 (Client Quit) 06.33.31 Join Hillshum [0] (n=hillshum@75-165-247-150.slkc.qwest.net) 06.36.39 Quit Hillshum (Read error: 104 (Connection reset by peer)) 07.06.20 Join MoD2 [0] (n=mod@ppp-93-104-182-201.dynamic.mnet-online.de) 07.07.26 Join Horschti [0] (n=Horscht2@xbmc/user/horscht) 07.09.08 Part MoD2 07.25.40 Quit Horscht (Read error: 110 (Connection timed out)) 07.26.30 Join NooB23 [0] (n=noob23@ppp-93-104-182-201.dynamic.mnet-online.de) 07.28.54 Quit jfc (Read error: 131 (Connection reset by peer)) 07.47.15 # any thoughts on having the depth field in the font struct / header be an enum for formats instead? i don't see us supporting a huge range of depths, anyway, and we might want to later have special formats that differ in ways other than pixel depth... such as fonts for subpixel AA and the like. 07.48.45 # also, i'm pretty sure i know how to generate glyphs for those, and have them done more nicely than just making them 3x too wide or too tall. 08.03.03 # Unhelpful: unless you already figured it out, no the cf's we use have no dcache at all 08.03.57 # n1s: ouch. so reading four bytes on one of them instead of a word would hurt pretty hard, then? 08.05.23 # think so 08.05.57 # also, as near as i can tell, CF doesn't have any conditional execution, which means it'll have to branch in UPDATE_SOURCE anyway, which means i can completely hide the extra bookeeping cost, except for every 8th pixel. 08.11.03 Join Windeh [0] (n=Windlord@cm66.sigma104.maxonline.com.sg) 08.16.04 *** Saving seen data "./dancer.seen" 08.17.13 Quit Windlord (Nick collision from services.) 08.17.17 Nick Windeh is now known as Windlord (n=Windlord@cm66.sigma104.maxonline.com.sg) 08.25.12 Quit BlakeJohnson86 (Remote closed the connection) 08.40.21 Join Rob2223 [0] (n=Miranda@p4FDCFC24.dip.t-dialin.net) 08.57.27 Quit Rob2222 (Read error: 110 (Connection timed out)) 09.03.54 # amiconn, I started writing a new pixel format driver for the screen orientation of the M:Robe. I have everything working more or less except the native bitmap drawing. Right now everything calls that function with a stride that's equal to the image width which makes sense if the pixels are horizontally sequential. 09.05.27 # Unfortunately that stride value doesn't work if the pixels are vertically sequential. Right now the change I had in mind was to make it so that lcd_bitmap_part is always passed the full image height/width so that the driver can make the call on what should be the stride, but that is going to take alot of changes to the code 09.05.48 # I was wondering if you had any other thoughts on a way to handle the stride for the native drawing 09.07.54 # As a note, I originally implemented it so that it just translated the bitmaps when you call that function, but it won't work for the backdrop since it has to be re-oriented at least the way that I setup the new driver. I hacked in a re-orientation operation within backdrop.c, and that works, but it's not exactly clean.. 09.13.24 Join stoffel [0] (n=quassel@p57B4F124.dip.t-dialin.net) 09.20.22 Join flydutch [0] (n=flydutch@host214-146-dynamic.15-87-r.retail.telecomitalia.it) 09.34.01 # [03:20:12] its all ARMv4 <== Not true. The ARM920T (gigabeat F/X) is ARMv4 too, as are the AS3525 targets 09.34.50 # But to answer the original question, all conditional instructions with unmet condition take 1 cycle on all our arm targets 09.36.04 # where is ACTION_STD_ defined? 09.36.12 # kkurbjun: Hmm, that's indeed a problem I didn't foresee 09.36.59 # You pretty much need the height as a stride if the pixels are ordered vertically. Passing both width and height on all targets would be a waste though 09.38.20 # The only solution I can think of right now is to make lcd_bitmap_part a macro which gets passed both width and height, and translates that to a stride of either width or height depending on target (i.e. simply drops the unnecessary parameter) 09.38.52 # That wouldn't change binsize at all for the other targets, but will need a lot of rework 09.39.33 # amiconn, can't you specify that a parameter is not used in a function? I thought kugel or someone was looking at that for some other functions that had unused parameters on some targets 09.39.53 # it was something more than just a (void) 09.39.59 # Hmm, a better idea would be to introduce a STRIDE() macro, which is used in the parameter list of all lcd_bitmap_part() calls 09.40.51 # Afaik that's not possible 09.41.14 # hmm, I guess the stride macro could take both the height and width and pass what's needed on to the function call 09.41.22 # yep 09.41.45 # Same idea as making the function call a macro, but less hiding of what's really happening 09.43.54 # yeah, I like that better than making it a full macro 09.44.27 # the only thing that's unfortunate is it makes the function more complex in that it depends on a macro to use it properly 09.44.53 # I guess gcc isn't smart enough to fully optimize out unused parameters? 09.44.59 # The resulting macro is in fact trivial. #define STRIDE(w, h) (w) or #define STRIDE(w, h) (h) depending on target 09.45.22 # amiconn: it seems that the arm1136 manual indicates otherwise, with a rather complicated formula applying for instructions that would normally take >2 cycles if executed :/ 09.45.34 # How could it? The parameters need to be passed in some way. The caller cannot know that the parameter is unused in the callee 09.45.41 # yeah, the macro is easy, but for someone new coming in looking at the function it might not occur to them that they need to use a macro for it to work right on all screens 09.46.20 # So the passed parameter list needs to follow a well defined convention 09.47.15 # kkurbjun: that's no worse than various IF_* macros we have elsewhere... and once you hit the range where paramaters start to be passed on the stack, the extra paramaters can get expensive 09.47.57 # yeah, I guess with the way that gcc compiles it wouldn't be able to.. I'm too used to RTL synthesizes diving through hierarchy :) 09.48.43 # kkurbjun: The caller and callee might reside in different .o files, in fact they might even be written in different languages 09.49.05 # yeah that makes sense 09.49.35 # Sure gcc will optimise away any unused parameters for static functions which are inlined, but that's about the only case where it's possible 09.50.41 # yeah, agreed, the macro definitely seems like it's the cleanest way to go 09.55.31 Quit flydutch ("/* empty */") 09.58.35 Join flydutch [0] (n=flydutch@host214-146-dynamic.15-87-r.retail.telecomitalia.it) 10.07.29 # hmm, turns out more rtc chips than i realized use bcd natively, handeling the tm in the driver directly is still nicer though 10.11.53 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 10.15.47 Join dg1 [0] (n=dg@adsl-71-215-103.jax.bellsouth.net) 10.16.05 *** Saving seen data "./dancer.seen" 10.17.10 # rockbox sounds really good on my cowon d2, thanks 10.17.20 Quit dg1 (Client Quit) 10.19.36 Join dg1 [0] (n=dg@adsl-71-215-103.jax.bellsouth.net) 10.20.08 Quit BHSPitMonkey (Remote closed the connection) 10.29.16 Join einhirn [0] (n=Miranda@p5DCC0F69.dip0.t-ipconnect.de) 10.29.52 Quit dg1 (Read error: 60 (Operation timed out)) 10.35.57 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 10.57.05 Join ender` [0] (i=krneki@foo.eternallybored.org) 11.11.51 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 11.15.02 # where is 'rb->kbd_input' defined? searched for 30 minutes but not found anywhere -.- 11.15.06 Join einhirn [0] (n=Miranda@p5DCC0F69.dip0.t-ipconnect.de) 11.17.07 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 11.19.19 # NooB23: start by looking in plugin.c and plugin.h, which is where the plugin API structure is defined and filled in with functions. it's essentially a list of pointers to functions in the rockbox core. 11.28.37 # thx so far 11.30.18 # kbd_input itself is almost certainly defined somewhere else... try using grep or similar tools to search the source. :) 11.35.30 Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) 11.40.32 # found it in keyboard.c, nice tool :) 11.41.50 Quit NooB23 ("Nettalk6 - www.ntalk.de") 11.42.45 Nick YpsyZNC is now known as Ypsy (n=ypsy@geekpadawan.de) 11.48.44 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 11.49.35 Join stripwax_ [0] (n=Miranda@87-194-34-169.bethere.co.uk) 11.53.54 Join funman [0] (n=fun@rockbox/developer/funman) 11.54.56 # funman, if I figure out the buttons on the c200v2, can you test it? 11.56.16 # sure 11.56.27 # * bertrik wonders if domonoky had any luck with the power management chip settings on his m200v4 11.56.42 # missing buttons are rec/hold vol -/+ 11.57.28 # i have a suspicion that these buttons are read asynchronously to the function which reads the center+directional cross (through DBOP) 11.57.45 # aaaargh, the c200v2 also seems to share buttons with dbop pins 11.57.46 Join TheSphinX^ [0] (n=cold@84.165.213.2) 11.58.06 # these are known: there are 5 bits on dbop din 11.58.27 # and btw reading them by DBOP is better than reading them on the GPIOC pins 11.59.36 # oh? I can't imagine how 12.00.02 # i had false reads with the GPIOC pins, perhaps the DBOP controller manages the delays 12.00.04 # I think it's always easier if pins have just one function 12.00.26 # yes perhaps the problem comes from the switch between DBOP/GPIO 12.01.42 # I think so 12.02.04 # you can't just switch the pins to GPIO when DBOP is busy with it 12.03.42 Quit funman ("leaving") 12.04.02 # when trying to enable the DBOP FIFO on the fuze/e200v2 (to speed up the lcd update) the display shows blue bars, I think those are caused by GPIO button reads 12.06.05 Quit stripwax (Read error: 110 (Connection timed out)) 12.06.37 Join funman [0] (n=fun@rockbox/developer/funman) 12.07.16 Join Ubuntuxer [0] (n=johannes@dslb-094-221-090-173.pools.arcor-ip.net) 12.15.48 Join kugel [0] (n=kugel@rockbox/developer/kugel) 12.16.06 *** Saving seen data "./dancer.seen" 12.16.10 # Unhelpful: as if those IF_* macros aren't already bad enough 12.16.26 # :( 12.17.17 Nick Ypsy is now known as YpsyZNC (n=ypsy@geekpadawan.de) 12.17.29 # kugel: they serve a useful purpose, and they're clear enough... and you should be able to use convttf now, i found a bug related to the change of depth from a numeric value to a flag... i must have somehow not managed to actually install the fonts i made with it, but i have it working now :) 12.18.28 # i'd like to rename depth to format and make it an enum... maybe at some point we'll have more formats :) 12.19.04 # changed opinion? 12.19.38 Quit scorche (Remote closed the connection) 12.20.44 Join scorche [50] (n=scorche@rockbox/administrator/scorche) 12.20.54 # i don't know for sure. the 4-bit fonts are already no good on non-color targets, so in a way they're already target-specific... so why not have 2-bit ones for greyscale, and/or subpixel-rendered ones, etc. 12.22.11 Nick YpsyZNC is now known as Ypsy (n=ypsy@geekpadawan.de) 12.27.24 Join daurn [0] (i=daurnima@freenode/staff/daurnimator) 12.27.27 Join einhirn [0] (n=Miranda@p5DCC0F69.dip0.t-ipconnect.de) 12.27.49 Quit Ubuntuxer ("Leaving.") 12.29.45 Quit stoffel (Remote closed the connection) 12.36.51 Join stoffel [0] (n=quassel@p57B4F124.dip.t-dialin.net) 12.38.01 Quit TheSphinX^ (Remote closed the connection) 12.38.35 Quit kugel (Read error: 110 (Connection timed out)) 12.39.37 Join kugel [0] (n=kugel@rockbox/developer/kugel) 12.40.11 # Unhelpful: that's what I was thinking too 12.40.39 # greylib even could try to load the 4bit variant if it's available (by simple filename search) 12.41.13 # i think the biggest problem though is that right now we have one pack of fonts to download, and all of them work on all targets that can load fonts... 12.41.16 Quit __lifeless (Remote closed the connection) 12.41.33 Join __lifeless [0] (n=lifeless@90.151.222.130) 12.42.10 # I guess we would want a separate package for aaf 12.42.16 # if at all, that is 12.43.04 # fonts on greyscale aren't drawn with greylib 12.43.15 Join _zic [0] (n=user@91-165-248-215.rev.libertysurf.net) 12.43.29 # that could be changed :) 12.43.34 # that would be too slow I guess 12.43.53 # overkill 12.44.10 # that never stopped us 12.44.29 # I don't think it would be *too* slow 12.44.42 Quit daurnimator (Read error: 110 (Connection timed out)) 12.45.10 # it's always nice how you say "I don't think so", adds much too the conversation 12.45.17 # to the 12.47.06 # what do you want to hear? benchmark numbers? I can't tell it for sure, I have no greyscale target at all (plus, as if "that would be too slow I guess" added more) 12.47.11 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 12.47.28 # and fonts look blurry enough on most greyscale displays when lines need to scroll you wouldn't even notice anti-aliasing, ask some H100 owners 12.48.03 # * scorche nods in agreement 12.48.27 # that's no reason to not try it at least 12.50.21 # well, I prefer a readable and snappy UI 12.50.30 # also, the idea was to load the 4bit font only if a 2bit font was already chosen anyway, it would be anti-aliased in any event (unless you use a mono font, then greylib shouldn't try to load a AA font at all) 12.51.55 Join petur [50] (n=petur@rockbox/developer/petur) 12.52.52 Quit _zic (Remote closed the connection) 12.53.36 # I'm questioning the sense of font-aliasing on greyscale in gnerel (I even do for colour with current display sizes and the font size I typically use) 12.53.46 # general too 12.54.13 # I noticed that 13.02.03 # Using the greylib in the core is out of question 13.02.07 # There would be no point whatsoever for the H100, the display is so crap :) For the others, who knows 13.02.28 Join einhirn [0] (n=Miranda@p5DCC0F69.dip0.t-ipconnect.de) 13.02.31 # It draws too much cpu power 13.02.41 # handling 4 times the data and changing the drawing to a much more complicated system must be slower 13.03.15 # a lot 13.03.16 Nick Ypsy is now known as YpsyZNC (n=ypsy@geekpadawan.de) 13.03.50 Quit einhirn (Read error: 104 (Connection reset by peer)) 13.05.24 # amiconn: I didn't talk about core 13.05.36 # or didn't mean to... 13.06.12 # AlexP: the M5 display is a bit better but still looks blurry when things scroll, the greylib looks grainy on the Mini (forgot the technical explanation for this) 13.06.36 # kugel: I thought you talked about font aliasing, wouldn't that be for the core? 13.07.02 # 2bit fonts for the core, which can be done without anti-aliasing 13.07.10 # anti-aliasing I meant 13.07.22 # when if you load a greylib enabled plugin, it could try to load the 4bit pendant 13.07.37 # * kugel adds a slash 13.08.25 # A slow lcd is actually good for the greylib 13.11.11 # I meant withou without greylib to sentences ago, of course 13.11.17 # s/withou// 13.11.33 # s/to/two/ ............... 13.13.35 # :) 13.16.08 # Unhelpful: still no success 13.17.48 Join Buschel [0] (n=AndreeBu@p54A3FD21.dip.t-dialin.net) 13.23.23 # kugel: i just did a clean build of simulator, and generated some fresh fonts. they work. and they've been working on my targets. you're using the three new patches? 13.24.11 # do the greyscale targets let the user select text and background grey levels? that alone would be enough to kill our ability to do any antialiasing. :) 13.24.40 # you can use a backdrop 13.25.09 # Unhelpful: not the one for plugins but it shouldn't matter 13.25.28 # I explicitely deleted convttf.c before (git actually wanted that :p) 13.25.31 # The text and background greylevels are selectable in the driver, it's just a matter of adding settings 13.25.48 # and in the WPS you can use all 4 shades of grey for fore- and background per viewport 13.26.10 # my M5 WPS uses that 13.26.13 # * amiconn still thinks that ordinary pixel-based font aa is worthless and a huge slowdown at the same time 13.26.59 Join merbanan [0] (n=banan@c-83-233-172-245.cust.bredband2.com) 13.27.33 Quit Rob2223 () 13.27.38 # kugel: maybe a pluginlib loader and renderer. rockpaint wouldn't be hurt (on color targets) by having the ability to do its own font loading and caching. 13.27.52 Quit merbanan (Client Quit) 13.28.05 Join Rob2222 [0] (n=Miranda@p4FDCFC24.dip.t-dialin.net) 13.29.21 # Rockpaint hasn't been ported to greyscale yet 13.29.31 # for core, keep in mind that we're talking about 2-bit fonts that you already decided look awful, and they'd be displayed with rather large pixels besides (on greyscale targets). 13.29.57 # pixelma: i'm aware, but i was testing its AA font support and had a lovely experience with the font selection menu. :/ 13.30.42 # just don't do it :P 13.31.33 Join panni_ [0] (i=hannes@ip-95-222-19-21.unitymediagroup.de) 13.32.44 # well, actually it would be fairly usable if it cached the rendered names, and draw ahead, so that it wasn't redrawing each font when you got to the bottom and it started scrolling 13.33.13 # Unhelpful: they look awful on color yes, no idea how they'd look on greyscale 13.34.12 # what does rockpaint do with the fonts? I've never used it 13.34.47 # use the text tool, and pick select font from the menu. and have fun. :) 13.36.22 # kugel: i doubt they'll look much better with grey levels that are not evenly spaced in brightness, and huge fonts. 13.37.31 # also, subpixel AA would cost one more multiply, and a few more add, shift, and other one-cycle instructions. plus the cost of the extra font data. 2-bit might be passable for that, since we'd also be tripling the effective resolution. 13.37.39 # s/huge fonts/huge pixels/ 13.38.07 # lol nice 13.38.52 # Subpixel aa is the only acceptable font aa for me. Unfortunately it isn't possible using precomputed fonts on some targets 13.38.56 Join Buschel_ [0] (n=AndreeBu@p54A3FD21.dip.t-dialin.net) 13.40.30 # Unhelpful: why don't fonts work me :( 13.41.00 # they have a reasonable size now (200k for monofur, 450-500k for dejavu) 13.41.22 # amiconn: because of vertical vs horizontal pixel layout? 13.42.02 # yes 13.42.10 Quit Buschel (Read error: 104 (Connection reset by peer)) 13.44.39 # that part's actually easy, we'd store both versions of the glyph on disk, and load the desired one into cache. they should even be drawable with the same routine without extra conditions, so we wouldn't have to deal with additional slowdown or extra code. 13.48.51 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 13.50.21 # New commit by 03stripwax (r22525): Rerrange some registers in butterfly_generic to combine some 2-word stores into 4-word stores and remove some redundant mov instructions. Shave off ... 13.51.48 Join Buschel [0] (n=AndreeBu@p54A3FD21.dip.t-dialin.net) 13.51.52 # it could be either four copies if we want to support each combination of rgb vs bgr plus vertical vs horizontal... do we have targets where RGB vs BGR is an issue? i recall you mentioning that some had either vertical or horizontal pixel layouts for the same target. :/ 13.51.58 # Unhelpful: Now imagine the file size with an unifont-like font... and there's also the problem that you cannot detect automatically which version to use 13.52.24 # yeah, a single font at 20MB would be icky. 13.53.00 Quit Buschel_ (Read error: 54 (Connection reset by peer)) 13.53.35 # kugel: i just converted monofur. perhaps you should check out an entirely fresh branch to apply the patch to? and you're not testing on a coldfire target, are you? i obviously can't have tested the coldfire version of the blend function. :/ 13.54.00 Join darkham [0] (n=darkham@host5-155-dynamic.6-87-r.retail.telecomitalia.it) 13.54.29 # I did git reset --hard HEAD^^ so that it's at SVN, and deleted convttf.c 13.55.17 Join _lifeless [0] (n=lifeless@90.151.222.130) 13.55.17 # if it's at svn, how do you have a convttf.c? :/ 13.55.47 # it wasn't deleted, I apparently didn't add it previously 13.56.08 # git ci -va doesn't work for added files :/ 13.56.42 # (which is good) 13.58.38 # hrm, you're not using a 64-bit or big-endian system, are you? 13.58.56 # amd64 13.59.11 # i.e, x86_64 13.59.29 # kugel: you can use origin to revert your commits, or git checkout origin to have SVN state in a separate branch 14.00.28 # origin doesn't work so well, because that's the git mirror which isn't always up-to-date 14.00.47 # that's why I use git svn rebase, and don't fetch regularly 14.00.50 # kugel: do you have a 32-bit freetype? you could try building with -m32 14.00.55 # when i use git svn rebase && git pull --rebase it's always up to date 14.01.16 # ...and you should fetch to a branch you never work on, except when staging something for commit. :) 14.01.32 # which would be master... 14.02.12 # Unhelpful: I don't have 32bit support 14.02.23 # I deactivated that in the kernel 14.02.25 # kugel: i'd bet that's where things are going wrong 14.02.48 # well, the fonts work on the pc 14.03.07 # I'll try on my lappy 14.04.21 # of course they work on your PC. it's the converted font that's bad 14.05.19 # i see some problems already, struct font_header_struct in convttf uses unsigned long for 32-bit values. start by replacing all of the types there with uint16_t for unsigned shorts and uint32_t for unsigned longs. 14.06.09 # do uint32_t for the two members that are FT_Long, too. there's no reason to use freetype types in that struct, anyway. 14.10.03 # stripwax_: any benchmark numbers? 14.10.30 # Unhelpful: indeed, it's a 64bit problem 14.11.04 Quit bmbl (Read error: 104 (Connection reset by peer)) 14.11.05 # n1s sorry, nope. 14.11.20 Quit __lifeless (Read error: 113 (No route to host)) 14.12.11 # hm, only one message from CIA-43? I'd have thought there would be two 14.12.21 # the gigabeat-F build just broke 14.12.30 # New commit by 03stripwax (r22526): Fix condition code clobbers (and one TAB) for inline arm code in lib and libtremor 14.12.32 # I broker it? 14.12.34 # ^broke 14.12.44 # kugel: i've just put up a patch to fix the font header struct. you may need to do more. i'm going to bed. :) 14.12.59 # Unhelpful: You will need to replace that with endian agnostic read/write functions anyway 14.13.50 # Unhelpful: some 14px don't work 14.13.52 # agh, right, yes I did. I'll fix 14.16.07 *** Saving seen data "./dancer.seen" 14.16.40 # Unhelpful: hrm, there're a few more problems :/ 14.17.11 Join Lear [0] (i=chatzill@rockbox/developer/lear) 14.19.37 Join PaulJam [0] (n=Paule@p54BEE873.dip.t-dialin.net) 14.20.06 # New commit by 03stripwax (r22527): Removed remaining MB usage 14.20.12 # What cpu is Gigabeat F? 14.21.06 Nick stripwax_ is now known as stripwax (n=Miranda@87-194-34-169.bethere.co.uk) 14.21.56 # It's obviously the only platform that uses the non-assembly mdct butterfly code 14.23.38 Quit darkham (Client Quit) 14.23.42 # New commit by 03learman (r22528): FS#10466: Introduce a real malloc for tremor. 14.24.06 # stripwax: http://www.rockbox.org/twiki/bin/view/Main/GigabeatInfo 14.24.43 # AlexP - right but why doesn't it use the ARM optimised code in rockbox? why is it use the regular C? 14.24.55 # heh, don't ask me :) 14.25.44 # There is something odd about it though - no iram? 14.26.04 # I don't know what arm version the ARM920T core is - but I'd have thought the asm would be (at-least) as fast as the gcc c 14.26.09 # * AlexP is guessing now 14.26.34 # Although if you're running at 300MHz, maybe it doesn't matter so much :-p 14.27.26 # Argh, don't know why SVN decided to delete tlsf/src rather than add... 14.28.02 # stripwax: ARM9 I think 14.28.04 # ARM920T is v4t 14.28.07 # d'oh 14.28.12 # * AlexP shuts up :) 14.28.20 # It's also ARM9 14.28.39 # ARM versions and generations are a real mess 14.28.43 # yeah 14.28.50 # OK, I feel slightly better now :) 14.28.53 # v4t is same as ARM7TDMI? 14.28.58 # ARM7 is always v4, ARM9 exists as v4 and v5 14.29.20 # The 'T' means thumb support 14.29.35 # Ok, what do you do if svn cleanup errors out? 14.29.47 Quit petur (Read error: 113 (No route to host)) 14.30.04 # so the same code on pp502x should work on gigabeatF I would have thought. Odd that codeclib isn't using the arm code in that case. 14.30.28 # maybe it's just mdct2.c actually, not sure. 14.31.15 # Either it's an oversight, or the C code is faster on the F 14.31.30 # Oh! hah, the S3C2440 is explicitly compiled from C, from a #if right at the top of mdct2.c 14.31.38 # While ARM7TDMI and ARM920T are both ARMv4, instruction timing is different 14.32.03 # ARM9 has better pipelining 14.32.58 # Oh, I thought the pipeline was part of the 'v' version - v4 with 3 stage and v5 with 5 stage - but if that's ARM7 vs ARM9 rather than v4 vs v5 then that makes sense 14.33.15 # But is that the only ARM9 cpu in rockbox? 14.33.32 # no 14.33.39 # so it's still odd then .. 14.33.47 # The AMS targets are all ARM9 (v4) as well 14.34.04 # There are a few ARM9 (v5) targets, e.g. the Cowon D2 iirc 14.34.29 # Clipv2/Fuzev2 are armv5 14.35.05 # Unhelpful - in fact, didn't you reorder some instructions in mdct_arm.S to try to reduce stalls on ARM9 targets? 14.35.19 # probably would be good if someone with a gigabeatF can confirm if C is still faster than asm 14.35.23 # btw i'll mail the AMS guy next week if i have no news from him about the Clipv2/Fuzev2 datasheet 14.35.39 # stripwax: If you do me a patch (or tell me what to do) I can test 14.37.10 # funman: Eh, are there actually two versions of the AS3525 with different arm core version? 14.37.11 # AlexP - one line change :) change the "#if defined(CPU_ARM) blah" line at the top of mdct2.c to be "#if 1" 14.37.21 # and then what am I testing for? 14.38.07 # amiconn: no the Clipv2 & Fuzev2 have an AS3531 (newer core for which we don't have the datasheet -yet-), or at least we are sure they use a ARM926-EJS 14.38.17 # oh, right :) test_codec runs on any of the mdct codecs (e.g. mp3, vorbis). see if the existing code gives faster decoding speed than the modified code 14.38.25 # righto :) 14.38.36 # many thanks! 14.38.38 # funman: Hmm, but then they should have a different manufacturer sub-dir in target tree... 14.39.08 # amiconn: they are not yet in the target tree ^^ 14.39.21 # They are in 'configure'.... 14.39.36 # there is some code for clipv2 on flyspray but i must check how much similarities there is with as3525 before adding them 14.39.55 # configure just errors out if you select them, I needed to reserve a target number for mkamsboot 14.40.41 # AlexP - actually, mp3 is a funny one .. so maybe vorbis and wma? or maybe just vorbis? :) 14.41.05 # vorbis is fine, I might have a wma somewhere :) 14.42.49 # New commit by 03learman (r22529): Don't know why svn decided to delete tlsf/src... Maybe due to some aborted tests I did to see where it would be best to place TLSF. 14.44.20 # ffmpeg -i file.ogg file.wma 14.45.38 Quit fyre^OS (Read error: 113 (No route to host)) 14.48.45 Join chandoo [0] (n=chandoo@67.83.185.120) 14.53.16 Quit Llorean ("Leaving.") 14.54.42 # stripwax: the mp3 codec doesn't use the mdct in the lib 14.56.24 # hm, my rtc cleanup seems to be done, just need to testbuild a bit and read through the patch a final time (and then posting it on the tracker and nagging people as i have only one target to test on currently) 14.57.15 # which target did you test on? 14.57.24 # gigabeast 14.58.06 # so there are 11 other drivers to test 14.58.26 # if we are going to do them all 14.59.20 # n1s - yep, I realised after I posted that 14.59.23 # stripwax: As is: Ogg 534.76% 55.41 MHz needed wma 624.70% 47.43 MHz with change: ogg 568.08% 52.16 MHz wma 648.85% 45.67 MHz 14.59.59 # stripwax: This was just "speed test" on a single file (for each) in test_codec 15.00.01 # Seems pretty clear to me. So that #if should be changed to just #if defined(CPU_ARM) without the S3C2440 bit 15.00.17 # AlexP - yep, perfect. 15.01.44 # AlexP - oh, that's off which build revision by the way? r22527 or something earlier? 15.02.11 # stripwax: 22529 15.02.22 # for both runs? 15.02.25 # yep 15.02.49 # fab. many thanks! I'll commit the change 15.02.57 # cool, no worries 15.03.43 # New commit by 03stripwax (r22530): C code is NOT faster on S3C2440 - tested by AlexP on r22529 15.03.52 # :) 15.03.59 # coolio :) 15.06.37 # Lear - does the tremor malloc affect decoding speed much/at all ? 15.06.59 # * n1s would probably hava edded a "anymore" to that committ message 15.07.12 # s/a e/e a/ 15.09.16 # Lear: floor 0 files requireing too much memory should no longer crash, right? 15.09.27 # n1s - I thought about it, but to be honest it may have been like that for quite some time 15.09.59 # well, the opposite was true at one point 15.12.24 # true - but we don't know when. I thought if I put 'any more' then people might assume my change has improved GigabeatF, which is (very likely) not the case 15.19.07 # stripwax: No. Only affects things when starting a new file. 15.19.46 # n1s: I don't think I tested that... 15.24.58 # Anyone know why viewport->fg_pattern and viewport->bg_pattern etc are unsigned ints rather than of type fb_data ? 15.25.41 # gcc seems to need to emit instructions to cast from int to fb_data (e.g. lsl 16, lsr 16) in lcd functions such as mono_bitmap_part 15.29.15 Join Buschel_ [0] (n=AndreeBu@p54A3FD21.dip.t-dialin.net) 15.29.49 Quit Buschel (Read error: 104 (Connection reset by peer)) 15.30.13 Part decayedcell 15.36.23 Quit bluebrother (Nick collision from services.) 15.36.28 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 15.46.48 Join teru [0] (n=teru@59.133.112.132) 15.49.02 Quit moos ("Rockbox rules the DAP world") 15.49.17 Join moos [0] (i=mostafa@rockbox/staff/moos) 15.51.58 Join kushalone [0] (n=kushal@12.169.180.178) 15.52.17 Join Windeh [0] (n=Windlord@cm66.sigma104.maxonline.com.sg) 15.55.49 Part Buschel_ 16.04.04 Quit Windlord (Read error: 110 (Connection timed out)) 16.05.02 # Lear: do we have tlsf malloc duplicated now? 16.05.48 # * n1s is confused by one thing in the h100rtc mod rtc driver, a comment says "chip wants century (always 20xx)" and it bitwise OR's the month value with 0x80... 16.05.52 Quit Windeh ("http://windlord.co.cc/") 16.06.28 # kugel: At the moment, yes. I plan to make pdbox use the codec copy. Didn't want to include it in this commit though. 16.06.34 # stripwax: probably because we also accapt RGB888 as input on color (settings, viewport definitions in wps/ui viewport, color picker) 16.06.55 # Lear: alright, duplication sucks a bit :) 16.08.05 # kugel - yep, that's probably it. plus it turns out the gcc code is actually quite clever even though I personally disagree with it :) 16.11.50 # no, color picker is actually using RGB565 16.16.09 *** Saving seen data "./dancer.seen" 16.18.19 Quit moos (Read error: 131 (Connection reset by peer)) 16.18.28 Join moos [0] (i=mostafa@rockbox/staff/moos) 16.21.11 # kugel - hrm. must be some other reason then 16.21.28 # well, settings and viewports still accept rgb888 16.22.20 Join Strife89 [0] (n=michael@adsl-220-104-59.mcn.bellsouth.net) 16.22.40 # gotcha 16.24.07 # although assumption is that current_vp->fg_pattern is always RGB565 anyway (=or at least, assumption in lcd-16bit.c is that it is in same format as framebuffer). so we must be converting before we store it in current_vp anyway. must be some other reason why it's an int in current_vp ... 16.26.10 # amiconn or linuxstb (he committed the driver level viewports) probably now 16.26.55 # could the shades in greyscale viewports have anything to do with it? 16.27.19 # native data type is generally faster, but that might outweight if exessive casting to fb_data is needed 16.28.37 # stripwax: I was wondering the same about the coordinates, many other places are using shorts for those also 16.31.25 Quit flydutch ("/* empty */") 16.33.28 Join dmb [0] (n=Dmb@unaffiliated/dmb) 16.33.42 # New commit by 03teru (r22531): Clear screen when leave usb screen so that usblogo doesn't remain on the screen. 16.35.44 # teru: the GUI_EVENT_REFRESH should be used for those cases 16.36.37 # because a) it's only active if ui vp is actually used and b) it redraws the statusbar 16.39.52 Quit kushalone (Client Quit) 16.42.04 # kugel: clear_display and update are used when displaying usblog. i don't think it cause problem. 16.42.07 # New commit by 03kugel (r22532): Quickscreen: 4th item ... 16.42.47 # teru: this event is specifically made for those cases in conjunction with the ui vp 16.45.23 # especially due to the statusbar thing. just clearing and updating will make it disappear 16.49.49 # kugel: nice work on the custom statusbar patch! i'm going to test this out later. i was wondering, is the patch you posted on the tracker the latest version? (i can't acess the link to the git repo you posted.) 16.50.33 # repo.or.cz seems down 16.51.04 # PaulJam: looking at git log, yes it is the latest version :) 16.52.23 # thanks 16.54.57 Join kushalone [0] (n=kushal@12.169.180.178) 16.56.18 Quit panni_ (Read error: 113 (No route to host)) 16.57.25 # New commit by 03teru (r22533): keybox: fix issue when deleted all items. 16.58.00 Quit dmb (Read error: 113 (No route to host)) 17.04.27 # hmm, what's the policy on which targets we provide current builds for? mrobe500 has a link on the current build page but the gigabeast doesn't, both are unsupported and built by the buildsystem 17.08.51 Join MG_Man [0] (n=MGMan@97.101.208.11) 17.09.01 Join saratogahome [0] (n=463f90ed@gateway/web/cgi-irc/labb.contactor.se/x-cpjbjikmsdgdfohw) 17.09.26 # great to see that the F can now use the ASM code for IMDCT 17.11.04 Nick TheSeven is now known as Nanotron-TheSeve (n=theseven@dslb-084-056-146-066.pools.arcor-ip.net) 17.11.23 Nick Nanotron-TheSeve is now known as TheSeven (n=theseven@dslb-084-056-146-066.pools.arcor-ip.net) 17.12.05 Nick TheSeven is now known as TheSevenTron (n=theseven@dslb-084-056-146-066.pools.arcor-ip.net) 17.12.17 Nick TheSevenTron is now known as TheSeven (n=theseven@dslb-084-056-146-066.pools.arcor-ip.net) 17.17.18 # New commit by 03kugel (r22534): More fixes for the usb screen: Use send_event(GUI_EVENT_REFRESH, NULL) to get rid of dead parts if the custom ui viewport is used as intended (it also ... 17.18.25 # Oh damn, I knew I forgot something 17.18.57 # 1. I was going to add a border to my backdrop for use with a custom ui viewport 17.19.28 # And 2. I forgot to add conditionals for track/alubm/artists names to say something else if it was unknown 17.21.03 # MG_Man: fix it and tell us when you're done so we can delete your theme to enable you to re-upload 17.21.08 # Ok 17.21.12 # It shouldnt take long 17.21.48 Join biengo [0] (n=quassel@xdsl-213-196-250-156.netcologne.de) 17.22.17 # New commit by 03kugel (r22535): Move a line up into the existing FOR_NB_SCREENS loop and add a comment. 17.22.17 # stripwax: how much of an improvement did your changes make? 17.23.05 Join _zic [0] (n=user@91.165.248.215) 17.24.45 Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 17.31.44 # saratogahome: The mdct asm/c change? 17.31.51 # saratogahome: If so, [14:59:23] stripwax: As is: Ogg 534.76% 55.41 MHz needed wma 624.70% 47.43 MHz with change: ogg 568.08% 52.16 MHz wma 648.85% 45.67 MHz 17.32.33 # weird. it seems gui_wps_show in apps/gui/wps.c is expected to return GO_TO_* but it returns SYS_USB_CONNECTED under particular circumstances. 17.34.55 Join panni_ [0] (i=hannes@ip-95-222-19-21.unitymediagroup.de) 17.38.10 # New commit by 03teru (r22536): Calendar: change directory to store .memo file from /.rockbox/ to /.rockbox/rocks/apps/ for the consistency with other plugins. move the file manually ... 17.40.17 # Okay, conditionals fixed, now just gotta get the new backdrop and ui viewport 17.42.10 Quit kushalone (Client Quit) 17.43.59 # saratoga - AlexP's numbers are for enabling the asm mdct on gigabeat F. I didn't (don't) have numbers for the asm changes I made. Probably small, but I figure removing instructions from mdct is always good 17.44.16 # i.e. can't slow anything down 17.46.34 # New commit by 03kugel (r22537): Make UI viewport handling more multiscreen aware and bring a break; accidentally back lost in a previous commit (r22485). 17.46.54 # * kugel swaps accidentally and back :S 17.48.35 Join fml [0] (n=4fd3dc7a@gateway/web/cgi-irc/labb.contactor.se/x-myigfprcvlmlplbj) 17.48.39 # stripwax: have you ever profiled AAC-HE? 17.49.18 # I think it can be made a lot faster 17.50.18 # AlexP: hello! I can't build the RB manual. Can you? I have r22537. 17.52.03 # saratoga - no, but I can add it to the queue :) mt asked for atrac profiling first :) 17.52.34 # fml: Which target? I just tried the beast and it seems fine 17.52.39 # stripwax: i have a very good idea how much most of the ATRAC functions used 17.52.53 # saratoga - would you say you have a feel for why wma is somewhat significantly faster than vorbis, by the way? 17.52.55 # i commented most of them out while testing and recorded the run time 17.53.05 # stripwax: its a much simplier codec 17.53.06 # oh ok 17.53.06 # AlexP: H120 17.53.41 # although commenting them out isn't a very good way of profiling, since you have a processing pipeline that will change when you comment stuff out :) 17.54.05 # fml: The pdf builds fine here, just trying html 17.54.32 # WMA is the fast ffmpeg huffman decoder, maybe 4 multiplies per sample for requantization and stereo decoding, then the MCDCT library, then the ASM dewindowing code 17.55.04 # its a transform codec stripped to its core 17.55.23 # fml: html fine too 17.55.23 Join TopyMobile [0] (n=topy@g228140131.adsl.alicedsl.de) 17.55.26 # fml: What is the error? 17.56.17 # AlexP: I'll make clean first, then try and then tell you 17.56.36 # OK 17.57.02 # ATRAC non-QMF is something like 30 MHZ total BTW 17.57.10 # and it could be made much faster 17.57.16 # but the QMF is always going to be slow 17.57.24 # its a good canidate for the COP on PP though 17.57.33 # anyway have to run 17.57.45 # ok 17.57.45 Quit saratogahome ("CGI:IRC (EOF)") 17.58.51 # AlexP: no luck after clean. ! Misplaced \noalign. l.453 \end{btnmap}. I think it's in iriver_istall.tex 17.59.09 # weird, I wonder why I don't get it 18.00.33 # I think I'll just go without a viewport ui 18.00.39 # AlexP: same for e200 18.00.51 # fml: In a new build directory too? 18.00.54 # It looks wrong when used in say 3.2 and such where it isn't supported, and some people may not have the latest build 18.01.02 # Plud it doesnt really look any different/better 18.01.15 # Not for my theme, at least 18.02.01 # fml: e200 manual builds fine here.... Very odd 18.02.58 # AlexP: same (can't build) for the recorder in a fresh new build dir. Really weird! 18.04.18 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 18.04.39 # fml: The pdf seems not to have built on the server last night 18.05.05 # fml: I suspect my \ifpdfoutput changes in r22522 18.05.19 # fml: But I'm a bit stuck trying to fix it as it works here 18.06.09 Quit AndyIL (Read error: 60 (Operation timed out)) 18.06.28 # fml: Could you revert that and try again? The trouble is that without those changes, the html doesn't build :/ 18.07.17 Join AndyI [0] (i=AndyI@212.14.205.32) 18.07.38 # AlexP: how do I revert? svn up -rnnnnnn? 18.08.12 # yes, I think so 18.08.36 # AlexP: why did you put the ifpdf's where they are used and not in the definitions of rbxxxrule? Didn't it work that way? 18.08.56 # fml: er, a good point :) 18.09.16 # fml: That sounds like the better way of doing it 18.09.55 # fml: Perhaps see if that works properly? 18.10.28 # AlexP: r22521 (PDF manual) builds fine here 18.10.33 # Alright, all fixed 18.10.37 # fml: OK, so it must be that 18.10.48 # I'll need the old one (BoxAmp in H300/iPod Color) 18.10.54 # need the old one deleted first* 18.11.28 # fml: Could you try changing the \ifpdfoutput to the definitions and see if it works? I could do, but it builds for me at present :/ 18.11.42 # MG_Man: One moment 18.11.50 # Thank you 18.12.26 # MG_Man: OK, deleted it 18.12.31 # Thank you 18.12.35 # Re uploading it now 18.13.15 # AlexP: I tried and doesn't work for me. Tex is tricky! I think \opt and\nopt get in the way. 18.14.48 # I tried just to change \rbtoprule (added ifpdfoutput with just \hline in the else case) and it doesn't biuld 18.15.56 # huh 18.16.03 Quit faemir ("Leaving") 18.16.11 *** Saving seen data "./dancer.seen" 18.16.21 # It is very odd that it builds fine here though - I wonder what the difference is 18.16.22 # AlexP: agreed! :-) 18.17.24 # fml: The curious thing is that the html output seems to be building fine on the server with current svn - does it work for you? 18.17.25 # tex and latex are so highly standardized that it can't be the reason (the program itself) 18.17.42 # AlexP: how do I build html? 18.19.56 # make manual-html 18.21.29 # AlexP: I use ubuntu. What package do I need to get htlatex? 18.22.05 # tex4ht 18.22.09 # I think :) 18.25.06 # New commit by 03teru (r22538): fix FS#10465 and return GO_TO_ROOT instead of SYS_USB_CONNECTED in gui_wps_show. 18.25.11 # AlexP: HTML works. But PDF still does not. 18.26.13 # I can confirm this (except the html part) 18.26.53 # the PDF doesn't build for me either 18.26.59 # fml: OK, so we need to think of a better way to do r22522 - as without those changes, html doesn't build 18.27.15 # pixelma: Really oddly, it does here 18.29.20 # well, I'll have a play but it is a bit difficult for me as it already works, so if I change stuff I don't know whether it'll have fixed it or not 18.31.24 Join daurn| [0] (n=daurnima@ppp118-208-191-102.lns10.mel4.internode.on.net) 18.31.38 # Sorry, I have to leave 18.31.40 Quit fml ("CGI:IRC 0.5.9 (2006/06/06)") 18.34.53 Quit daurn (Read error: 60 (Operation timed out)) 18.36.43 # New commit by 03kugel (r22539): Respect UI viewport per screen in viewport_set_defaults() also. 18.39.29 Join domonoky1 [0] (n=Domonoky@g229116098.adsl.alicedsl.de) 18.40.56 # AlexP: I can't even build a PDF from r22521 (cygwin) 18.42.20 # pixelma: I wonder if that is due to fml's changes to the mid,top,bottom rules in r22516 18.42.28 # Could you try 22515? 18.43.55 # sure 18.47.54 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 18.49.30 Quit teru ("Quit") 18.50.19 Quit funman ("free(random());") 18.53.12 Quit Strife89 ("Leaving") 18.54.56 Quit domonoky (Read error: 110 (Connection timed out)) 18.58.43 # AlexP: yes 22516 breaks it for me (tested both revisions) 18.58.51 # pixelma: OK 19.00.04 # pixelma: 22516 makes the header "box" a bit bigger - seeing as it seems to break pdf (and probably html) on cygwin and html on linux, maybe it is worth reverting that and trying to find a different way 19.01.12 # I agree 19.02.24 # OK, I'll revert it for now and fml can try and weave some slightly different magic :) 19.02.45 # There, theme reuploaded 19.04.12 Quit biengo (Remote closed the connection) 19.04.14 # ok, rtc cleanup now posted in FS#10569, test! 19.05.38 # apparently WMA Lossless reverse engineering has begun over at ffmpeg 19.05.49 # we just need that and WMA pro and we can can complete our codecs I think 19.08.45 Join Tsumugi [0] (n=Mugi@216.218.195.106) 19.10.10 # * stripwax mumbles something sarcastic about DRM .. ;) 19.11.19 # Would it make sense to make some of that asm volatile in the codeclib to be just 'asm' and encourage gcc to do the optimal reordering for the platform? 19.11.27 # n1s, I'll test on ams sansa and sansa v1 19.13.18 # pixelma: Could you test http://pastebin.com/m574eff4 please? 19.14.06 # bertrik: great! 19.15.07 # is it appropriate to ask a user interface question here, or should i poke the community channel? 19.16.17 # Tsumugi: If it about the Rockbox UI, then here :) 19.16.22 # *is about 19.17.09 # i'm wondering if there is a way to go from the "now playing" view to the "playlist" view directly? (on an ipod running rockbox, of course) 19.17.34 # fucking "nothing to resume" splash :S 19.17.47 # Hold select to get the context menu, then select playlist, then view playlist 19.18.13 # There isn't a one click way of getting there that I know of 19.18.30 # (although I think there is a patch for this) 19.18.40 # yeah, i knew that way -- oh? 19.18.55 # Have a look on flyspray (I might be misremembering) 19.19.13 # Although even if there is that means you will need to patch the source code then compile your own build 19.19.30 # i probably should rtfc, but are those connections "hard coded" or are they in the UI config files? 19.19.45 # You would need to change the source code 19.19.49 # okay 19.20.19 # i'm guessing there's a nice section on setting up a cross compiler on the web, so i'll head there =) thanks! 19.20.28 # Tsumugi: Are you on linux? 19.20.40 # i can be! 19.20.50 # It is easier of you are :) 19.21.28 # Check the source out of svn, then run tools/rockboxdev.sh 19.21.41 # It'll patch and build the cross compilers for you 19.21.48 # wow, awesome 19.22.32 # svn co svn://svn.rockbox.org/rockbox/trunk rockbox 19.23.05 # That command is an exercise into how to fit the most mentions of "rockbox" into one line :) 19.23.27 # haha 19.23.37 # * Tsumugi adds && cd rockbox for one more ;) 19.23.42 # good work :) 19.24.23 Quit Lear ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]") 19.25.41 Quit TopyMobile (Remote closed the connection) 19.27.14 # n1s, on my e200(v1) the time is still correct with the patch, also the day-of-week in calender is correct 19.41.03 # New commit by 03kugel (r22540): Fix up statusbar handling in the usb screen a bit more, using the GUI_EVENT_ACTIONUPDATE event instead of direct draw (with the custom statusbar patch ... 19.42.48 Join Ubuntuxer [0] (n=johannes@dslb-094-220-225-034.pools.arcor-ip.net) 19.44.50 Nick Horschti is now known as Horscht (n=Horscht2@xbmc/user/horscht) 19.54.49 Join Buschel [0] (n=AndreeBu@p54A3D493.dip.t-dialin.net) 20.02.58 # AlexP, pixelma (and other manual guys): does that look fine to you http://pastie.org/598925 ? 20.04.19 # kugel: is party mode in playback settings so it can be referenced like the other settings? 20.04.19 # amiconn: i know. the offsets table needs fixing, too. i could just go through the whole lot with htole* before writing it out, that seems easiest... 20.04.31 # I didn't find a reference 20.04.45 # OK 20.05.11 # I find the second paragraph rather confusing - I'll try and propose an alteration :) 20.05.32 # maybe s/"Please note that each opposite direction inverts the direction the setting is toggled through."/"Please note that each item inverts the direction the setting is toggled through compared to its opposite item"/? 20.06.05 # modify as you like and re-paste :) 20.06.11 # Buchel: you're concerned that accumulating into a 32 bit buffer in the IQMF isn't accuarate enough? 20.07.03 # kugel: "Unhelpful: some 14px don't work" <- does this mean that at least *some* fonts work now? :D 20.07.22 # party mode as default in the quickscreen? Bad idea. 20.07.24 # type, apparently 20.07.27 # typo 20.07.41 # why not make the quickscreen behave as now and make the "up" item the opposite of "down"? 20.07.53 # Unhelpful: what are you referring to? 20.08.21 Quit Ubuntuxer (Read error: 110 (Connection timed out)) 20.08.25 # ...to what you said about 6hr or so ago? 20.08.34 # saratoga: no, the accumulation is fine but only for the asm'ed part. The C-code does accumulate into 16 bit. 20.08.51 # Unhelpful: ah I thought it was about my qs commit 20.08.57 # yea, some fonts work 20.09.05 # although scrolling is buggy 20.09.06 # saratoga: And the iqmf is 2-staged. So, the (16 bit precision) results of the first stage are the input for the second stage. 20.09.13 # kugel, not to take you too far off topic - but what ever happened to FS#10156? 20.09.28 # the glyph that enters the scrolling margin is a bit corrupted 20.09.39 # how do you figure its 16 bit? 20.09.45 # kugel: Something like "Please note that the settings at opposite sides of the screen cycle through the available options in opposite directions. Therefore if you have the same setting at the top and bottom of the quickscreen, then pressing up and down will cycle through this setting in opposite directions." maybe? 20.10.09 # soap: no idea, I never understood entirely what the problem was about 20.10.40 # most of what the task is about is in SVN, but the initial problem (which is apparently ultra unlikely to ever happen) appears to be still there 20.10.47 # it looks to me like fixmul31 returns the top 32 bits and those are accumulated into a 32 bit buffer 20.11.30 # saratoga: 1st -> there is no scaling when truncating to int16_t. 20.11.50 # bluebrother: Weirdly my fix for the html last night breaks the pdf for everyone except me 20.12.03 # I was just going through my old FS watch list and that one seemed to die off unexpectedly. 20.12.04 # saratoga: 2nd -> change in decoing speed when making the samples the second operand in smull/smlal 20.12.21 # bluebrother: Given that the original commit that this is trying to fix also breaks cygwin I think I'll just revert that for now 20.12.24 # saratoga: the samples are int32_t but the upper 16 bits are not significant 20.12.46 # saratoga: btw, just reached 69 MHz :o) 20.12.51 Quit PaulJam (Read error: 113 (No route to host)) 20.12.57 # kugel: on what target are you testing? 20.13.00 # Buschel: which code are you refering to? i can't find any int16_t 20.13.02 # e200 and fuze 20.13.08 # which codec? 20.13.17 # atrac3 20.13.54 # bluebrother: The original commit was to make the top and mid rules leave a bit more room for the header so it wasn't so cramped, but that broke cygwin, and html on linux. I fixed the html on linux with the \ifpdfoutput we talked about last night, but in doing so broke pdf on linux (except for me, which is weird). 20.14.10 # saratoga: search for calls of av_clip_in16 in atrac.c 20.14.24 # hrm. e200 works fine for me :/ 20.14.59 # Buschel: its only called after the IQMF unless I am missing something? 20.15.03 # av_clip_int16 should use CLIP_TO_15 from lib 20.16.12 *** Saving seen data "./dancer.seen" 20.17.04 # saratoga: yes, but the 2nd reason is still valid. and also there is no shifting within the iqmf which would eliminate any exisiting fract part 20.17.38 # also atrac3 fixp_math doesn't use the lib for fixmul31? 20.17.59 # stripwax: see FS#10565 20.17.59 Quit Buschel (Read error: 104 (Connection reset by peer)) 20.18.03 Join Buschel [0] (n=AndreeBu@p54A3D493.dip.t-dialin.net) 20.18.05 # AlexP: that works also 20.18.21 # * Buschel slaps his wlan stick.... 20.18.36 # ah! :) 20.18.50 # stripwax: the clip16 stuff should not be used in libatrac at all. this should only be handled by the dsp-rotuines 20.18.55 # *routines 20.19.03 # kugel: I'll just commit something here to make the manuals actually build again 20.19.15 # Buschel: you're talking about the "s1 += fixmul31(p1[i], qmf_window[i]);" lines in iqmf() right? 20.19.27 # oh, because we output signed 32bit rather than signed 16bit from codec? 20.19.37 # AlexP: I was refering to your suggestion about the text 20.19.48 # yes ideally each codec should output 32 bit samples but some don't and that should be fixed 20.19.57 # kugel: I know, but until I commit this you can't build the manual to test it :) 20.20.00 # stripwax: yes. and the codec tells the dsp-routines what exact format is used 20.20.00 # I'm pretty sure cook does clip16 also 20.20.01 # cook does the same thing but when i changed it the codec would crash for reasons I don't understand 20.20.13 # jinx 20.20.34 # indeed 20.20.36 # saratoga: the same happened to me. something to fix in future... 20.21.00 # in cook? theres probably some underlying problem we're missing then 20.22.34 # saratoga: example for the missing fract part: samples use int32_t with al value range of +/-32767. win-coefs use +/-2^31. now they are multiplied and the result is shifted by >>31. the reuslt is a int32_t with a value range of +/-32767. -> 16bit precision. 20.22.58 # why are the input values restricted to 16 bits? 20.23.00 # saratoga: so, each results of a multiplication is truncated. 20.23.28 # AlexP: "Please note that opposite items invert the direction a 20.23.28 # setting is toggled through. Therefore if you have the same setting at the top 20.23.28 # and bottom for example, then pressing up and down will cycle through 20.23.28 DBUG Enqueued KICK kugel 20.23.28 # this setting in opposite directions."? 20.23.33 # gah 20.23.52 Join petur [50] (n=petur@rockbox/developer/petur) 20.23.57 # kugel: Sounds a little stilted, one mo 20.24.29 # most if it are your words! 20.25.04 # AlexP: that's strange. 20.25.22 # saratoga: is there any reason that the sign of the window_lookup table is inverted? 20.25.26 # bluebrother: indeed it is 20.25.55 # Buschel: you'd have to ask MT about that, he computed the table 20.26.00 # but my guess is thats just how ffmpeg did it 20.26.15 # saratoga: ok, I'll invert them again 20.28.43 # kugel: toggle suggests only two options, which isn't true for most settings 20.28.53 # New commit by 03alex (r22541): Revert r22516 and r22522 - the former breaks html on linux and evrything on cygwin, the latter fixes html but breaks pdf on linux. Revert and find a ... 20.28.56 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 20.29.36 Quit togetic ("WeeChat 0.3.0-rc2") 20.29.54 # kugel: "Please note that the settings at opposite sides of the screen cycle through the available options in opposite directions. Therefore if you select the same setting at e.g. the top and bottom of the quickscreen, then pressing up and down will cycle through this setting in opposite directions." ? 20.30.20 # that seems nice 20.30.54 # although I'm not sure as to the usage of abbreviations like e.g. in the manual 20.32.44 # Why? 20.32.48 # It is standard english 20.34.26 # alright 20.34.41 Quit Thundercloud (Read error: 60 (Operation timed out)) 20.36.14 # e.g. is a latin abbreviation btw. 20.36.30 # yes, but still standard english :) 20.36.40 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 20.36.45 # f.e. which people sometimes use to mean e.g. isn't English 20.36.53 # yes, but you wouldn't want to write the latin words. That was my point :) 20.36.58 # indeed so :) 20.37.10 # same as i.e. :) 20.37.14 # yep :) 20.37.19 # AlexP: alert me once the manual builds again 20.37.31 # kugel: It should do now 20.37.41 # oh there was a commit! 20.38.03 # I hope it works :) 20.38.55 Quit petur (Remote closed the connection) 20.39.14 Join petur [50] (n=petur@rockbox/developer/petur) 20.39.30 # works 20.39.33 # cool 20.39.36 # New commit by 03kugel (r22542): Update the manual to reflect the recent addition of the 4th item to the quickscreen.. 20.40.27 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 20.40.27 # * bluebrother still thinks that having party mode in the quick screen is a bad idea 20.40.54 # party mode caused quite some confusion in the past, having it more present is calling for problems. 20.40.57 # * goffa__ agrees 20.41.10 # I never quite got the point of party mode at all :) 20.41.26 # kugel: What about the default mirroring the bottom setting? 20.41.42 # furthermore, I'd *really* appreciate not changing the old behaviour, i.e. making the "up" button the same as it did before: the same as "down" but inversed 20.41.58 # Then it acts like it does now for those that want that, and provides a nice example of how to do the mirroring 20.42.09 # I don't object anything in that regard 20.42.13 # * bluebrother points out that he said that earlier 20.42.15 # more ways to set your file view to playlists? 20.42.17 # I don't use the defaults whatsoever anyway 20.42.27 # bluebrother: Ah, well in that case - great minds etc. :) 20.42.57 # AlexP: or simply people who did manual work -- and noticed at least some of the usual user gotchas :) 20.43.11 # hehe :) 20.43.32 # the old behavior often led to accidentally changing the file filter, that's why I changed it. But now that the top item (and the manual) actually indicates what it does, the problem is probably disappeared anyway 20.44.07 # I only used the quickscreen for changing the file view setting ... 20.44.23 # you can still do that 20.45.09 # well, the point was simply that it was the only use the quickscreen had for me, so I never accidentially changed that setting using the quickscreen ... 20.45.30 # New commit by 03kugel (r22543): Add the select button as exit button for the e200's quickscreen, and update the manual (fuze entry was not wrong also). 20.45.51 # * bluebrother looks at the average build speeds and is impressed -- looks pretty much unpredictable :o 20.46.26 # so if everyone wants file view as default top item, go for it, I really don't object 20.47.49 Join togetic [0] (n=togetic@unaffiliated/ibuffy) 20.52.44 # nobody wants to do it, apparently? 20.52.56 # I'm about to change it. 20.52.59 Join faemir [0] (n=faemir@78.33.109.163) 20.53.02 # ah fine 20.53.20 # else I would've changed in a few mins 20.53.30 # bluebrother, AlexP: btw. r22516 broke PDF building on cygwin in a very weird way. Usually compiling stops at a line with an error and I'm asked what to do, with this the process just hung in /rockbox_interface/main.tex (I guess at the first table) running the CPU at full power, pressing Ctrl-C gave me the question what to do, pressing q - "ok, entering batch mode" and another hang there 20.53.48 # AlexP: it's really fixed now :) 20.53.54 # I'm just waiting for my box to finish that build to ensure there's no typo or similar. Takes a bit on this machine. 20.54.08 # pixelma: It was very odd all round 20.54.34 # bluebrother: What is really weird is that 22522 built absolutely fine for me, but broke for everyone else 20.54.41 # * bluebrother wonders if the manual build hangs he experienced yesterday are related to that issue -- or to his gpp experiments 20.55.04 # AlexP: did the gigabeat manual build for you too while it was broken? 20.55.05 # I'll just wait until bluebrother finishes rewriting the manual in ASM :) 20.55.20 # pixelma: not the F, but that was a different issue 20.55.39 # pixelma: I only tested the S, assuming it would be the same 20.55.43 # * bluebrother remembers to change the manual too 20.55.44 # I know, just thought there might be something weird about your setup 20.55.55 # New commit by 03Domonoky (r22544): rbutil: dont write logfile if user aborts filename selection. 20.56.08 # pixelma: The difference is texlive vs tetex I guess, but why, I don't know 20.56.18 # AlexP: does the S already support the remote/and or is this enabled in the manual? 20.56.25 # pixelma: yes and yes 20.57.42 # which of the two packages do you use? 20.57.56 # texlive, tetex isn't available anymore for Arch 20.58.28 # hmm 21.03.19 Nick dys` is now known as dys (n=andreas@95.115.76.241) 21.03.30 # New commit by 03bluebrother (r22545): Replace "Party Mode" as Quickscreen top item with "Show Files" to get the old behaviour as default and prevent accidential enabling of party mode. 21.10.29 Quit T44 (Read error: 104 (Connection reset by peer)) 21.10.43 Join Topy [0] (i=Topy44@f049085172.adsl.alicedsl.de) 21.11.04 Join mrkiko [0] (n=mrkiko@host113-30-dynamic.0-87-r.retail.telecomitalia.it) 21.17.33 # AlexP: why do you want the manual in asm? 21.17.48 # bluebrother: I don't, it was just a joke :) 21.18.19 # hehe ... but seriously, I might get this gpp thing running. 21.18.49 # That'd be cool (and would hopefully lead to me learning something new) 21.22.05 # bluebrother: do you have a link to their site? I googled and all I got was the wikipedia article, which is about preprocessing in general (the rest was useless stuff like Government Purchasing Project) 21.22.22 # oh I think I found it 21.31.31 # New commit by 03kkurbjun (r22546): Add stride defines to support vertical strides 21.31.36 Quit BHSPitMonkey (Remote closed the connection) 21.33.29 # One thing I wondered about the H300 21.33.35 # Video playback is 10FPS on the original firmware 21.33.39 # Is it the same for Rockbox? 21.33.55 # saratoga: anything speaking against submitting the current state of atrac optimization? 21.34.18 # MG_Man: http://www.rockbox.org/twiki/bin/view/Main/PluginMpegplayer#Performance 21.34.40 # although that is quite out of date 21.36.31 # Gee 21.36.42 # How ironic that the iPod COlor does videos better than the Video :P 21.36.47 # I assume it's the resolution 21.37.10 # yes, but it only does as we don't use the dedicated video processor in the video 21.38.05 # I guessthe only way to tell for sure is to try it 21.38.19 # I don't know if the simulator emulates the DAP's CPU though 21.38.44 # no, it is a simulator not emulator 21.38.50 # and try what? 21.39.49 # New commit by 03kkurbjun (r22547): Correct superdom conflict 21.44.30 # New commit by 03Buschel (r22548): Submit interim version of FS#10565. Performance optimization of atrac3 decoder for ARM. Introduce ASM routines for multiplications and two synthesis ... 21.45.53 Quit Res1 (Read error: 54 (Connection reset by peer)) 21.50.22 Join Res1 [0] (n=Res@user-0c6s6hp.cable.mindspring.com) 21.51.00 # * bluebrother hands Buschel 1560 points :) 21.51.45 # always the sim... 21.52.11 # what, you only test on target????? :D 21.53.50 # * Buschel is bad bad guy :) 21.57.23 # New commit by 03Buschel (r22549): fix red 21.58.20 Join GeekShado_ [0] (n=Antoine@138.228.192-77.rev.gaoland.net) 21.58.20 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 21.59.58 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 22.05.25 # looks like the gpp stuff is actually working. At least it doesn't seem to scramble the manual anymore :) 22.06.05 Quit amiconn (Nick collision from services.) 22.06.07 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 22.06.15 Quit pixelma (Nick collision from services.) 22.06.17 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 22.06.29 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 22.06.35 # awesome 22.06.36 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 22.06.47 # it is compatible to config*.h also? 22.08.15 # not yet. The first goal was to get the files preprocessed at all. Now to do something useful during preprocessor run ... 22.08.56 Quit kugel (Remote closed the connection) 22.10.07 # bertrik: thanks for testing :) 22.10.48 # n1s, just 11 more drivers to test ... :P 22.11.53 # yes :) 22.12.12 # n1s: that RTC thing? Is it on FS? 22.12.30 # well, i tested the mc13783 driver 22.12.33 # bluebrother: yes 22.15.32 Quit GeekShadow (Read error: 110 (Connection timed out)) 22.16.16 *** Saving seen data "./dancer.seen" 22.19.28 # bluebrother: excellent :) 22.21.24 # bluebrother: fs#10569 if you haven't found it yet :) 22.21.53 Join kugel [0] (n=kugel@rockbox/developer/kugel) 22.33.50 Join funman [0] (n=fun@rockbox/developer/funman) 22.35.27 Nick TheSeven is now known as SevenTron (n=theseven@dslb-084-056-146-066.pools.arcor-ip.net) 22.35.33 Nick SevenTron is now known as TheSeven (n=theseven@dslb-084-056-146-066.pools.arcor-ip.net) 22.38.55 # n1s: 3 additional targets tested, h100 is broken. I've commented on FS. 22.39.06 # bluebrother: thanks 22.40.19 # bluebrother: does the rtc modded h100 work with a recent clean revision? 22.40.23 # n1s: I'll test the samsung one 22.40.52 # bluebrother: alarms should be unaffected, i thik 22.42.16 # I'll test on M5 22.43.04 # great 22.44.00 # bluebrother: i have no idea why it should hang, the only weird thing in that driver is that |0x80, maybe you could try removing it? 22.45.19 # n1s: maybe it's an effect of the calendar plugin not getting a useable value? Though I haven't looked into the code at all. 22.47.27 # samsung's have RTC_E8564, same as h10 and hdd1630 22.49.23 # bluebrother: thing is that that driver didn't change much at all and should essentially behave the same as it did... 22.49.45 # did you test with a recent svn version? 22.51.38 # n1s: yes, with current svn 22.51.58 # ok, thanks 22.53.46 # i wonder if it could have something to do with the special bcd decoding done in get_time previously 22.54.02 # n1s: broken here 22.54.14 # I got 2 warnings though, let's see if fixing these helps 22.55.36 # kugel: were there a "statement witholut effect warning" ? 22.56.09 # no, apparently just signedness warning in the for-loops (int i is compared with sizeof() ) 22.58.29 # it appears to use BCD? 22.58.39 # maybe only BCD ones are broken 23.00.25 Quit _zic (Remote closed the connection) 23.00.49 # kugel: very possible 23.00.53 Quit mrkiko ("Lost terminal") 23.07.09 # bluebrother: could you please test the new patch i tested, i used the "special" bcd decoding from svn get_time 23.07.12 # ? 23.07.27 # s/tested/posted/ 23.09.12 # would the Iaudio driver need this version too= 23.09.18 # ? 23.11.10 # n1s: doesn't fix it here. I have the same symptoms 23.11.30 # pixelma: it doesn't change anything for the iaudio driver, does it not work with the original patch? 23.12.01 # kugel: doesn't change anything for the ams driver either 23.12.13 # can't tell as I'm just compiling (and then my only USB cable for it is taken for a while still 23.12.16 # ) 23.12.17 # I'm testing on samsung yh925 23.13.38 # ah you just hacked the h100 one, gonna adapt and test again 23.14.32 # n1s: reading looks good now, but setting the time doesn't work -- it always falls back to --:--:-- 23.14.52 # yep, that did it for reading here too 23.15.10 # bluebrother: ok, thanks, that confirms the problem (only changed the rtc_read_datetime so that's expected) 23.15.49 # so the generic bcd conversion doesn't work, more work for tomorrow then 23.15.55 # our rtcs apparently have an additional bit in the buf which messes it up 23.16.15 # yeah, would seem so 23.16.47 # I have no desire to read a whole bunch of datasheets though :) 23.17.15 # I think such target specific code doesn't necessarily need generic macros 23.17.19 # i guess the hard part is doing this in a nice way 23.17.30 # if they don't work that is, I'd just keep the old conversion 23.17.33 # interestingly the date read out in the set screen is correct while the date in the time / date screen shows only "unknown" 23.17.46 # kugel: no, but this way was so nice! :) 23.17.52 # :) 23.18.30 # bluebrother: the patch doesn't swap wday and mday as SVN does, that's probably the reason (at least here) 23.18.49 # it is interestig that several chips have thae same quirk 23.19.24 # at least they do have things in common :) 23.20.09 # rtc_read_datetime and rtc_write_datetime are entirely the same on our both rtcs, except for RTC_ADDR symbol 23.20.44 # yeah, might be the same chip design :) 23.21.41 # so at least the ds1339 and e8564 driver broken... 23.23.21 Join fml [0] (n=4fd3dc7a@gateway/web/cgi-irc/labb.contactor.se/x-jvismssnbdzrgqfi) 23.24.32 # AlexP, pixelma: hey, wanna try a patch that fixes vspace in table headers? http://pastebin.ca/1547630 23.24.35 Quit petur ("Zzzzz") 23.25.22 # vspace in the first row still needs fixing 23.28.47 # fml: Did you see my revert earlier? 23.29.19 # AlexP: yes, and applied 23.29.35 # ok, cool :) 23.29.44 # I'll try now with this one :) 23.30.37 # With this patch, heads should look like the original booktabs (but without the thin white lines!) 23.30.51 # It builds as PDF and as HTML for me 23.36.39 # Yes, bith build here :) 23.36.42 # *both 23.37.15 # Looks good 23.37.36 # AlexP: commit? 23.37.49 # Is it possible to adjust the position of the lower line at all? It looks a little too close to the text in the first row to me (being very nit-picky here) 23.38.08 # AlexP: this will be another patch 23.38.15 # OK, sounds good 23.38.49 # can I please test on cygwin first? 23.38.52 # New commit by 03alle (r22550): Make table headers look like the original booktabs 23.39.03 # seems I can't 23.39.04 # pixelma: er, no :) 23.39.05 # pixelma: too late :-) 23.39.08 # pixelma: too slow :) 23.39.24 # bluebrother: what else did you expect from cygwin? :) 23.39.27 # sorry, can't divide myself or this laptop 23.39.32 # I wonder why there are differences in tex at all 23.39.50 # pixelma: Just shout if and when :) 23.40.01 # though my build batch (pdf only) is still running. Need to have a closer look at the h100 manual 23.40.13 # What is up with it? 23.40.30 # I wouldn't expect the speed difference that extreme for the manual 23.40.49 # Oh, it takes ages to build? 23.40.55 # speed difference? 23.41.14 # * bluebrother grumbles 23.41.52 # why on earth was svnversion.sh renamed? It still only grabs the svn version information. 23.42.11 # 0m24.218s 23.42.14 # er, oops 23.42.26 # but now all my set up manual builds which I haven't used for a while can't find it anymore. 23.43.12 # version.sh handles git-svn repos also 23.43.28 # that's probably why it was renamed 23.43.33 # so? It still retrieves the *svn* version number. So calling it svnversion is *still* correct. 23.44.27 # handling of git-svn was added before it got renamed. 23.46.06 # n1s: everything seems to work correctly with your patch (time display in statusbar and WPS, clock plugin, calendar plugin) 23.46.12 # on M5 that is 23.46.29 # I tested the first version in the tracker 23.46.58 # fml, AlexP: cygwin manual PDFs still build too 23.47.10 # pixelma: good news 23.54.24 # AlexP, pixelma: please try another patch that fixes the space in the last rows: http://pastebin.ca/1547654 23.54.57 # I produced PDF and HTML with it 23.55.15 # ok, will do 23.58.15 Quit ender` (" Going to church does not make a person religious, nor does going to school make a person educated, any more than going to a")