--- Log for 24.11.109 Server: lindbohm.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 22 days and 16 hours ago 00.00.30 # Only then I noticed the new vieport clipping. Why is this necessary? It is only enabled for mr500 atm 00.01.08 # You also went back to the old, less efficient bounds checking in lcd_bitmap_transparent_part when adding this. Why? 00.02.57 # amiconn: I enabled it and created it because I feel that if we expect clipping to be present it shouldn't be broken by viewports and the USB screen crashes the MR500 currently (and should crash the mr100 or at the least cause data corruption) 00.03.13 # I can't comment on the less efficient method, if I did that it was by accident 00.03.37 Part drf|laptop 00.03.37 # How is clipping broken by viewports? 00.04.27 Part CaptainKwel 00.05.27 # Afair viewports are required to stay inside the display area. 00.05.37 # If we want to protect things from crashing, it would probably be better to clip viewports when they're set up rather than doing twice the work in each and every drawing function 00.06.51 Join Jon [0] (n=jon@unaffiliated/jonsparks) 00.06.57 # Hi 00.07.13 Quit AEnima1577 ("Leaving.") 00.07.36 # Hey 00.07.43 # I have a question. 00.08.21 Quit matsl (Read error: 145 (Connection timed out)) 00.08.22 # I have several extra IPs and plenty of ram and such on one of my servers, and I'm wanting to know if RockBox wants its own IRC server. 00.08.45 # I can just give an admin a shell and IP address to use. 00.08.51 # Free 00.08.51 # * Hillshum thinks we've been happy with Freenode 00.08.55 # k 00.09.12 # I'm trying to find uses for my servers though lol 00.09.24 # Jon: You can provide a build server. 00.09.29 # * Hillshum lost 00.09.35 # For what kind of use? 00.09.39 # or a download mirrir 00.09.46 # I can do a mirror 00.09.48 # mirror too 00.09.50 # Jon: For building builds, of course. :) 00.09.54 # =P 00.10.00 # New commit by 03pamaury (r23728): Add myself to COMMITERS. 00.10.02 # what would it need? 00.10.09 # Jon: There's some info in the wiki. 00.10.11 # Ok 00.10.36 # http://www.rockbox.org/wiki/BuildServer 00.10.45 # No wait... 00.10.45 # http://www.rockbox.org/wiki/BuildClient 00.10.54 # pamaury: welcome! 00.10.55 # Jon: BuildClient, not BuildServer. 00.11.05 # ok 00.11.19 # gevaerts: thanks ! 00.11.21 # pamaury: one thing though, that file is expected to be in alphabetical order :) 00.11.44 # Yeah, I can provide that 00.11.51 # gevaerts: I'll modify that ;) I missed this point :) 00.11.52 # Do I get anything in return for donating? 00.12.01 # =P 00.12.47 # Hmm I don't usually setup stuff other than IRC-related things in ssh 00.13.00 # I could just give someone a shell to set it up if you want 00.13.14 Quit thegeek_ (Read error: 113 (No route to host)) 00.13.32 # How do I get a rockbox repo in the directory? 00.13.32 # It's not that hard 00.13.39 # just download the svn? 00.13.44 # svn 00.13.46 # Ok 00.13.49 # What link? 00.13.54 Join nickwb [0] (n=nickwb@ppp118-208-168-84.lns20.bne4.internode.on.net) 00.13.55 # Install subversion (svn), then repo it 00.14.11 # k 00.14.14 Join Rockbox [0] (n=alexthec@CPE-72-135-229-158.wi.res.rr.com) 00.14.30 # Jon: You get tons of free beer and your name in the credits. :) 00.14.42 # xD 00.14.46 # Cool 00.14.47 # LambdaCalculus37: do we put build client people in credits now? 00.15.00 # gevaerts: I dunno. 00.15.11 # New commit by 03pamaury (r23729): Move myself in alphabetical order in COMMITERS. 00.15.12 Part nickwb ("Cya") 00.15.36 # What packages need to be installed via yum for this to work? 00.15.47 # Hey I went to the Linux4nano Channel and No one was avalible soooo...Can i ask a quick question? 00.16.08 # Rockbox: If related to rockbox... 00.16.33 # Yeah. 00.16.47 # What Drivers are missing for the 2G nano? 00.16.58 # Rockbox: USB. 00.16.58 # Whats the command to get the repo copied (Sorry I never use svn for anything) 00.17.15 # LambdaCalculus37: USB is there... 00.17.26 Quit pamaury ("exit(*(int *)0 / 0);") 00.17.36 # gevaerts: I thought it was still booting into disk mode. 00.17.45 # Jon: 'svn co svn://svn.rockbox.org/rockbox/trunk /path/to/repo/on/local/disk 00.17.46 # ah, maybe. Not sure. 00.17.51 # ok 00.17.52 # No. 00.17.55 # Rockbox: it mostly needs to be debugged 00.17.56 # amiconn: the viewport offsets are added after the clipping takes place against the viewport definition 00.18.03 # The USB is off. 00.18.06 # Can I make up the /path/to/repo/on/local/disc/ par? 00.18.08 # *part 00.18.15 # Just make a dir for it? 00.18.19 # Yeah 00.18.21 # ok 00.18.22 # Your computer doesnt detect the Ipod correctly. 00.18.27 # amiconn, I agree for the most part, but people mess things up - and if you take that approach then clipping should not be done in the driver at all 00.18.33 # Via root or a user? 00.18.48 # root. 00.18.52 # k 00.19.00 # Jon: never root 00.19.08 # Do you guys need dev help on that at all? 00.19.15 # ok 00.19.22 # Rockbox: if you don't know what you're talking about, please don't reply... 00.19.22 # If you need help im up for it. 00.19.57 # kkurbjunW: Hence my suggestion to clip the viewport on setup. Smaller and faster... 00.20.11 # And it's messed up anyway 00.20.12 # Hmm 00.20.17 # root@s4 [~]# adduser rockbox 00.20.17 # adduser: cannot lock shadow password file 00.20.19 # amiconn, if we shouldn't do clipping at the viewport why are we doing clipping at all? 00.20.21 # D= 00.20.37 # So your suggesting that what Im saying is Incorrect? 00.20.51 Nick linuxstb_ is now known as linuxstb (n=linuxstb@rockbox/developer/linuxstb) 00.20.57 # Im not totally in knowledge of everything rockbox. 00.21.26 # how is it messed up? 00.21.31 # Ive been folowing Linux4nano-dev since it went up. 00.21.35 # umm.... 00.21.40 # Hard to explain. 00.22.02 # Something with the USB drivers and the computers. 00.22.33 # Its like the files will get detected and sometimes they wont. 00.22.38 # Rockbox: talk to TheSeven for nanog2 things, or possibly linuxstb 00.22.53 # amiconn, to clarify I'm asking why we even clip images in the driver 00.23.27 # Okay. 00.23.28 # I think if we are going to do clipping we should still check against the screen 00.23.43 # * linuxstb doesn't know the current state of the Nano2G 00.23.43 # Rockbox: You don't run need to run svn as root, so yes 00.24.03 # kkurbjunW: Elements are allowed to be positioned (partially) outside the viewport, hence we need clipping 00.24.27 # Viewports in turn are not allowed to be positioned (partially) outside the screen 00.24.41 # with lua the development bar is lower and you can cause all kinds of problems with memory overwritten - the clipping /was/ there to be against the screen, and with viewports that was broken 00.25.19 # Back when we had no clipping, things were very complex (all callers had to do bounds checking themselves) and error prone (back then viewports didn't exist yet) 00.25.26 # amiconn, there is no method to check/define viewprorts we just write direct to the structure 00.25.57 # agreed, it makes the callers complex 00.26.04 Quit liar (Read error: 113 (No route to host)) 00.26.13 # lcd_set_viewport() 00.27.03 # I was told set_viewport was called quite a bit- I originally had some bounds checking there, but it renders the screen wrong if the viewport is partially outside of the screen 00.27.20 # kkurbjunW: I agree lua is a special case, but maybe that should just give an error if a program tries to set a viewport out of the screen. 00.27.45 # linuxstb: but it gets messed up in other places, the usb screen is an example of that 00.27.57 # How so? 00.28.14 # That sounds simply like a bug in the usb screen. 00.28.26 # kkurbjunW: (no offense) the usb screen is a bad example... it needs to be fixed seperatly 00.28.41 # lua shuold call a viewport setter wrapper to maake sure the values are legal 00.29.01 # I agree it needs to be fixed, my point is that if a mistake was made there and you have to do checking there, there's no saying that it won't continue to become more complex 00.29.24 # kkurbjunW: But it's not "checking" as such, it's just calculating correct values to use. 00.29.54 # and mistakes will be made in the future, it's the exact point that amiconn just said was the reason that clipping was added in the first place 00.30.11 # lcd_set_viewport() is certainly called less often than all drawing functions together. And even in a pathological case where it is called before each drawing function, there would be the same amount of checks as if we're doing it in the drawing functions 00.30.33 # But doing it in the drawing functions means much more binsize than doing it in the single setup function 00.30.56 # New commit by 03rob (r23730): Fix FS#10362 (flickering backlight when removing hold) by preventing multiple SYS_TIMEOUT events being posted the backlight thread. 00.30.58 # kkurbjunW: You could say that about many functions in Rockbox - the principle (IIUC) has always been to rely on the calling code being correct, rather than having many checks "just in case". 00.31.01 # amiconn: if you clip it there the screen won't render properly, but it will at least prevent memory corruption 00.31.11 # yep 00.31.54 # if you did a check there I would be fine with that, I just don't like the idea of memory corruption 00.32.01 # I know it won't render properly (that only applies to left/top clipping btw - right/bottom won't matter), but then such viewports are broken anyway 00.32.01 Join Jake [0] (n=60185bdd@giant.haxx.se) 00.32.32 # I was just lucky that I was able to pin the source of the corruption down, it was actually crashing in the thread functions. 00.32.43 # boomshine is too easy :( 00.34.28 Part Rockbox 00.37.12 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 00.37.17 # amiconn, I agree, it would be fine to do it in set_viewport. At least it prevents the corruption. I could care less if the viewport is rendered wrong if the caller is expected to make sure it is setup properly. Like I said, that's what I originally had, but I decided to do a more complete clipping implementation - the actual impact of the viewport clipping is not noticeable on the mr500, but I can't speak for the slower targets. 00.37.51 # (I even emasured the current and it was too small for me to measure) :) 00.38.07 # measured that is 00.41.27 # kkurbjunW: Why not simply panicf() instead of clip, if the purpose is to catch errors in apps/ code? 00.43.43 Nick Jon is now known as Jon[Newnick] (n=jon@unaffiliated/jonsparks) 00.43.52 # NOW THEY WILL NEVER FIND ME 00.44.48 Quit Hillshum (Remote closed the connection) 00.44.51 # linuxstb: the reason I chose to implement full clipping is because I could see it being useful in the future if any additional features were added. I'm not saying that it should be done, but if you had the ability to clip viewports in the driver you could create things like screen/viewport transitions (for example the wps slides in while the menu slides out). 00.45.00 Mode "#rockbox +o JdGordon| " by ChanServ (ChanServ@services.) 00.45.05 # and I wanted to prevent memory corruption 00.45.37 Mode "#rockbox -o JdGordon| " by ChanServ (ChanServ@services.) 00.46.04 # and it made the screen render as (potentially) desired even though currently the expectation is that viewports are withing the screen. 00.46.22 # Adding things "just in case they're needed in the future" isn't what's generally done either... 00.46.39 Quit DerPapst ("Leaving.") 00.46.43 # linuxstb, I think clippins or bounds checking is better than a panicf in general too by the way 00.48.17 # But that means bugs in apps/ code will go unnoticed. 00.48.29 # I don't care how it is done, but a panicf doesn't seem necessary if you are doing the checks anyway. you can add a logf in the simulator 00.48.38 # so that when you run it gives a warning 00.48.54 Join liar [0] (n=liar@83.175.83.185) 00.49.12 # or a printf or a debugf or whatever you prefer, but I don't think a panic is necessary 00.50.22 # But the API for viewports is that the viewport passed to the function MUST be within the screen. apps/ code writers need to be responsible for that. 00.50.24 Join gTanzola [0] (n=me@c-98-235-156-243.hsd1.pa.comcast.net) 00.50.59 # HD parking is not very pleasant for a potential innocent mistake 00.51.25 # But it shouldn't happen in committed code. 00.51.59 # * linuxstb doesn't understand why it's hard to define/calculate correct viewports 00.52.25 # it did and still does :), and probably will again, not everyone has a mr500/100 remote 00.52.35 Join Hillshum [0] (n=ubuntu@75-165-228-164.slkc.qwest.net) 00.52.50 # so someone does a commit and starts causing panic's on a target they don't even own 00.52.53 Quit liar (Client Quit) 00.53.17 # doing a debug message in the simulator seems reasonable without causing a panic on the target 00.53.20 # Then that person will quickly get yelled at. 00.53.46 # if they dont own the target.. how cna they get yelled at? 00.53.52 # there are only 3 devs that I am aware of that have an mr500 to my knowledge so quick is a relative term 00.54.05 # JdGordon|: For writing buggy code... 00.54.15 # its not buggy... its broken on that target 00.54.17 # big difference 00.54.38 # Huh? 00.56.06 # linuxstb, I think I am the only dev that regularly uses the mr500, ( gevaerts correct me if I'm wrong) and I don't always run the latest svn builds. The commit was made a long time before I noticed the problem 00.56.25 # and I would not want to see a panic on the target 00.56.48 # What's special about the mr500/100 remote that means this particular bug is only there? 00.57.02 # linuxstb: The remote is 79x16 ... 00.57.06 # the usb logo is large and the screen is small 00.57.35 # * linuxstb still doesn't understand... 00.57.40 # So the logo is larger than the LCD? 00.58.02 # the logic wouldn't work on that screen at all with the statusbar enabled 00.58.30 # you would end up with viewports that are outside of the screen space even if the logo was 1 pixel high 00.59.04 # (and you had a 8 point font defined) 00.59.12 # which is unlikely on the mr500 00.59.15 # Imo the statusbar in its current form is essentially useless on the mrobe remote 00.59.45 # And with current form I mean anything that its only separated horizontally 00.59.58 # even without the statusbar you would likely end up with viewports that are outside of the screen depending on the ui font 01.00.20 Join cendres [0] (i=ashes@modemcable076.241-176-173.mc.videotron.ca) 01.00.20 # hello 01.00.27 # I agree though, the statusbar is pretty pointless on the mrobe remote 01.00.39 # i have an iriver h300. when creating a vfat filesystem, is it best to use a 32 bit FAT size? 01.01.41 # I agree with kkurbjunW that crashing on unusual parameter combinations is bad. I said that myself several times, regarding metadata reading in codecs 01.01.54 # But if we do a check, it should be done with minimal impact 01.02.37 # * amiconn will probably look into that and try to bring back the more efficient clipping order as well 01.03.17 # amiconn: That's different though - that's dealing with untrusted input. Unless we don't trust apps/ code ;) But yes, I can see how these problems can easily happen... 01.03.39 # The current inconsistency isn't nic eeither - it won't crash on mr500 but on all others 01.04.08 Quit robin0800 (Remote closed the connection) 01.04.12 # And enabling all the extra code isn't nice on lowmem targets 01.04.18 # amiconn: with an sbs you could even do a vertical statusbar but that's a different story 01.04.49 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 01.05.43 # Does that actually work? I mean, you can define one that way, but will the lists use it properly? 01.06.24 # linuxstb: Viewport sizes may come from user input (.wps, .sbs, ...) Safeguarding in the driver will then be more efficient than letting all callers do it 01.07.24 # it would be pretty silly if the lists didnt work like that 01.07.26 # JdGordon|: trying "pure" %Rf in a hwcodec sim gives me a bunch of numbers till the end of the viewport - which doesn't happen with the built-in bar, using it in a conditional seems to work but I can't tell if the correct branch is used 01.07.58 # read: the correct frequency is displayed 01.08.11 # so thats good? 01.08.22 # no 01.08.24 # IMO it *should* display 44.100 if thats what it is 01.09.04 # the built in bar is not an orcale for this 01.09.12 # but it's 45x5096... where x can't be read because the channels icon is displayed over it 01.09.32 # ok, thats fubar :) 01.10.01 # but, it shuold be used as a conditional to have it show 44 or 22 or whatever 01.10.09 # yeah 01.11.39 # I was surprised that the hwcodec statusbar is different to the swcodec one there - the former displays just the number (before comma) in sysfont and the latter uses icons, though it looks like both take the same space 01.12.06 # the icons show smaller numbers and a k there 01.12.18 # Back 01.12.23 # Hey, svn co svn://svn.rockbox.org/rockbox/trunk /home/rockbox/svn/repo isnt working 01.12.24 # * Unhelpful wonders how much reuse we could get out of something like a generic bitstream reader, a generic handler for bitstreams of canonical huffman codes, etc... 01.12.30 # rockbox@s4 [~]# svn co svn://svn.rockbox.org/rockbox/trunk /home/rockbox/svn/repo 01.12.30 # -bash: svn: command not found 01.12.30 # rockbox@s4 [~]# 01.13.12 # Do I need a certain package or something? 01.13.16 # JdGordon|: Imo there should be a way to use built-in bitmaps, the same way as there is a set of built-in list icons 01.13.45 Join CaptainKwel [0] (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 01.13.54 # JdGordon|: I could probably "unify" both, just don't know which is better (the icons make it more clear that it is the frequency) 01.14.39 Nick CaptainKwel is now known as CaptainKewl (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 01.14.40 # but are smaller and harder to distinguish and one additional bitmap (although *only* one) 01.14.49 # i know it would end up being a codeclib piece, and still end up duplicated in any codec that needs it, but perhaps it would be worth determining which methods are optimal for these tasks for various cores used on rockbox targets, and having one "best" function for doing them 01.15.32 # Jon[Newnick]: looks like you are missing subversion then 01.15.56 # How do I install it? 01.16.03 # amiconn: I'd agree if there was ever a request from the themer commuinty for this... but to my knowlegde there hasnt... and there is plenty of places in the WPS where those icons would be useful 01.16.18 # Jon[Newnick]: depends on which distribution you use 01.16.30 # CentOS 5.2 01.17.17 Quit CaptainKewl (Remote closed the connection) 01.18.30 Quit BHSPitMonkey (Remote closed the connection) 01.19.14 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 01.19.20 # Any help on installing subversion for this? 01.19.38 Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 01.19.57 *** Saving seen data "./dancer.seen" 01.20.39 # Unhelpful - (is that regarding the gsoc page?). i'd have thought the individual packing/framing formats make a generic bitstream/unpacker pretty difficult (e.g. ogg vorbis) 01.20.58 Join CaptainKewl [0] (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 01.21.12 Nick Jon[Newnick] is now known as Jon (n=jon@unaffiliated/jonsparks) 01.22.07 # stripwax: not regarding gsoc. i'm tuning compiler flags for codecs on arm, and just noticing how some codecs with similar methods of operation perform *very* differently. 01.23.08 # and i don't mean a generic unpacker-for-all-bitstreams, but a generic for handling a stream of bits - ie, open, fetch next n bits, peek at next n, discard next n, skip to next byte/word boundary etc. 01.23.10 # Unhelpful - are you profiling along the way also? that would be cool 01.23.13 # JdGordon: I am not the themer community, but I want my statusbar to continue working properly. The built-in one doesn't need everything (e.g. it doesn't need playback state or recording - obviously you can't play back or record without disk access), but it still needs some gfx (disk activity for soft-led, battery, charger icon etc) 01.24.29 # similarly, on top of that you could build a generic for extracting canonical-huffman-coded data from the top of the bitstream 01.25.23 # Ugh I friggin hate my server 01.25.23 # Unhelpful - yeah, but the vorbis code 'cleverly' (not actually sure how clever it really is) incorporates a bunch of that stuff inline for certain cases for performance (decode_packed_block); as well as handling another layer of indirection so that separate buffers are handled as if they are one long contiguous buffer w/o copying mem 01.25.31 # I'm gonna just install this to a vserver 01.26.18 # Hm - is it expected that pictureflow keeps the disk spinning down, spinning up, spinning down, .. constantly? 01.26.40 # stripwax: bit-string fetching etc could still be inlined... ie, #include 01.27.03 # That's on latest build (not sure if behaviour changed at all recently tho) 01.27.08 # pictureflow has to spin up the disk if it has to fetch uncached tiles 01.27.11 # Unhelpful - true 01.27.29 # amiconn - should it do that if I'm not scrolling the tiles? 01.27.42 # Probalby not 01.27.45 # stripwax: um, yes, the (memory) cache needs some optimization, it will presently update the memory cache on each slide change, as it rather stupidly forces loading as many tiles as possible in each direction from the current slide. 01.27.53 # Mm-hmmm.. 01.28.12 # Unhelpful - it's doing it without slide changes, I'm just looking at it 01.28.14 # if you have just stopped scrolling and the cache is not full, it will keep loading 01.28.45 # Unhelpful - loading's fine - but rather it was constantly spinning up, down, up, down, the disk .. 01.28.45 # if it's just sitting there loading slides over and over, congratulations, you've found a bug in my buggy cache code :) 01.29.27 # :) 01.29.29 Quit Hillshum (Remote closed the connection) 01.29.47 # I don't know what it's doing, to be honest. Doesn't seem to spend any time at all between spin up/downs doing any actual loading. 01.30.35 # what i'd like to do is only force centering the cache when you're scrolling at speed. if you're flipping a slide at a time, it ought to let you get up to where there's just one off-screen slide cached, and then recenter when you bring that one into view. 01.31.53 # Is there anything I can help with other than hosting? 01.32.02 # *other than svn repo 01.32.08 # I can provide hosting or something 01.32.15 # For a mirror, idk 01.33.21 # Unhelpful - that would be good. also, the maximum scrolling velocity seems too low (at least on ipod video) ; really not possible to just fling it way way forward, you end up seeing all covers at a fairly graceful speed - but could that be also because of caching/loading? 01.35.15 Quit Thundercloud (Remote closed the connection) 01.35.27 # Unhelpful - re bitstream - yeah, I think the really basic stuff (as you say, peek n bits from a contiguous bitstream, extract n bits from a contiguous bitstream) should be implemented once per platform. endianness (of the bitstream, rather than the target platform) gets messy unless most of the codecs actually pack in the same ways 01.37.58 # JdGordon: I think I have everything prepared now for all depths and the Archos one and all parse correctly - just want to test on my targets and can likely commit tomorrow (half past 1 AM here...) 01.38.18 # the current time that is ;) 01.39.38 # I wonder if the M:Robe remote should get a seperate one but that can be the next step because it is not better currently 01.45.18 Join Strife89 [0] (n=michael@adsl-146-208-69.mcn.bellsouth.net) 01.46.05 Join MethoS- [0] (n=clemens@134.102.106.250) 01.49.13 # it probably has to - otherwise there would be at least overlapping viewports if not ones outside the screen 01.49.52 Quit Jon ("IceFyre IRC Client v.2.1.2") 01.52.38 # 1am is a good time to commit! 01.53.10 Join Strife1989 [0] (n=michael@adsl-146-208-69.mcn.bellsouth.net) 01.53.17 Quit Strife1989 (Read error: 104 (Connection reset by peer)) 01.54.20 Part toffe82 01.55.54 # amiconn: no, there is a big difference between icons being needed, and icons being a nice addition, which is what they are... in fact I cant belive that you would prefer an imprecise icon instead of 55% for battery levels... 01.57.12 # The current icon has 16 levels, which is precise enough for battery display, and it has the advantage that it is immediately recognisable as being the battery status, unlike a simple number 01.58.05 Quit mt (Read error: 110 (Connection timed out)) 01.58.36 Join Hillshum [0] (n=ubuntu@75-165-228-164.slkc.qwest.net) 01.58.49 # And it can display the fact that the battery is being charged at the same time 01.59.36 # what more do you need to know, when the battery level is red and 2 pixels wide, it's time to plug the thing in 01.59.40 # I will dispute the 2nd bit 01.59.50 # you need to wait for the animation to change frames to know 02.00.05 # Even if you select numeric display, the statusbar will switch to graphical display when charging 02.00.15 # stripwax: the jpeg plugin doesn't need to worry about endianness, as it reads one byte at a time. finding a way 'round that would be nice-to-have also :) 02.00.49 # once again... you are free to make your sbs do whatever the heck you want it to do 02.00.56 # Only on monochrome. On greyscale and colour displays you can really see both things at the same time (because the charging part is grey and the level is black) 02.01.40 # 55%+ doesnt give the same info? 02.01.47 # lol 02.01.50 # It doesn't fit 02.01.58 # which is easier on the battery than redrawing the animation 02.02.21 # And it still doesn't convey that it's the battery status 02.02.45 # I was talking about the necessity to support built-in gfx. 02.02.49 # the battery's at 1/2 bar with a little power icon, it's the same information 02.03.37 Quit Hillshum (Remote closed the connection) 02.04.14 # Right, and I'm saying that if it was ever requested then it would have been added 02.04.22 # And I don't see why *I* should fix a feature which is currently working and you intend to *knowingly* break 02.04.30 # but you get 100x more flexibility by allowing loadable graphiocs 02.04.59 # there is exactly one time when you cant hit the disk... and for that one time its not worth the effort when you can live with 55%+ especially wqhen it DOES fit there 02.05.33 # Charger connection? USB power? Disk activity? 02.05.44 # It's not only the battery gfx... 02.06.10 Quit stripwax (Read error: 145 (Connection timed out)) 02.06.51 # the only info you need on early use is batt level, charing yes/no and disk access... and RTC is a nice bonus... all that DOES fit 02.09.21 # And will look unrecognisable without gfx... 02.09.59 # even text is just a series of graphics that need to be loaded and displayed 02.10.09 # you're smart.. you'll figure out what the numbers mean pretty quickly 02.10.46 # why are we arguing against having clear concise imagery that conveys it's meaning instantly? 02.15.58 Quit kkurbjunW (Remote closed the connection) 02.18.02 Join kkurbjunW [0] (n=karlk@12.41.166.9) 02.19.22 # hmm... maybe we can do this another way... but you have to accept the red delta for it 02.22.56 # *maybe* we can cut down alot of the current bar logic and keep it in the core as is.. and use it like a widget again 02.23.00 # seperate from themes 02.23.28 # that is a damn big waste though 02.24.58 # * JdGordon really cant tihnk of any screen except early usb which *really* needs the bar displayed agains tthe users wish 02.25.05 # or because it hasnt loaded yet 02.25.21 # It might be useful to have a generic method to cut parts from a bitmap which are proportional to some value 02.25.28 Join bzed_ [0] (n=bzed@devel.recluse.de) 02.26.17 # This would save quite a number of bitmaps in any theme that wants to display battery status or volume with high precision 02.27.20 # For a nice battery icon you would only need two bitmaps - the battery frame, and the inner part, which would be cut according to the level 02.27.43 # or just the battery full and the battery empty 02.27.53 # yes, and that I'd be happy for someone to add 02.28.09 Quit rasher (lindbohm.freenode.net irc.freenode.net) 02.28.09 NSplit lindbohm.freenode.net irc.freenode.net 02.28.09 Quit dionoea (lindbohm.freenode.net irc.freenode.net) 02.28.09 Quit FlynDice (lindbohm.freenode.net irc.freenode.net) 02.28.09 Quit Xerion (lindbohm.freenode.net irc.freenode.net) 02.28.09 Quit jordan` (lindbohm.freenode.net irc.freenode.net) 02.28.09 Quit shodanX (lindbohm.freenode.net irc.freenode.net) 02.28.41 Join rasher [50] (n=rasher@rockbox/developer/rasher) 02.28.41 NHeal lindbohm.freenode.net irc.freenode.net 02.28.41 NJoin dionoea [0] (n=dionoea@yop.chewa.net) 02.28.41 NJoin FlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 02.28.41 NJoin Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) 02.28.41 NJoin jordan` [0] (n=jordan@78.235.252.137) 02.28.41 NJoin shodanX [0] (n=shodanX@jazz.informatik.uni-erlangen.de) 02.28.44 # but this early usb bar is causing headaches... if it really is the only user of a forced internal bar then we should fix the problem a different way 02.28.44 # This cutting would probably need to work in various directions, l/r/u/d at least 02.29.13 # It's early usb and charging screen (the latter obviously not on Ondios) 02.29.26 # charging pre rockbox loaded? 02.29.38 # Yes, with the disk completely unpowered 02.29.50 # fine, is that the only two though? 02.29.57 # Or not - this *is* in rockbox 02.30.01 # both could draw the animations themselves 02.30.15 # if its in rockbox then we should be using the users theme 02.30.34 # It's rockbox running from rom (otherwise we would never get into this state - the archos firmware would handle it) 02.31.01 # No disk access at this point - the disk is completely unpowered 02.31.55 # This is for two reasons (a) fastest possible charging, (b) low-bat situation: the battery might be so low that starting the disk will crash/stop the cpu 02.32.18 # The latter is important on the v1 as charging is software controlled - no cpu, no charging... 02.32.55 # yes yes, fine... but if thats it then you can have your animations, and I can have my nice clean API and everyone is happy 02.33.16 # hmm? 02.33.27 # * amiconn doesn't seem to understand 02.34.08 # the current statusbar can be stripped to the essentials, and only called for those 2 early access screens 02.34.20 # otherwise it wont be shown because your theme will be used 02.34.47 # Yes, A few things can be stripped, like play status and probably volume 02.34.52 # that of course makes no sense either 02.35.10 # why isnt it a list with charge level, status, time, disk access all layed out nicely 02.35.21 # much more readable than a 8 pixel high animation 02.35.28 # and much smaller code 02.35.42 Quit Stephen_ ("Leaving") 02.36.05 # perhaps... 02.36.13 # even a fancy full width progressbar! 02.36.28 # But then the early usb screen and the in-rockbox usb screen will be fairly different 02.36.32 # so? 02.36.51 # Well, unless you want to change the main usb screen as well 02.37.07 # maybe 02.37.07 # Do you have an ipod? 02.37.12 # no reason why not 02.37.18 # neither of my ipods are functional atm 02.37.28 # my mini2g sort of is.. sometimes 02.37.39 # Did you compare the OF's USB screen and diskmode USB screen? 02.38.01 # They're not identical, but apple tried to make them as similar as possible 02.38.13 # thats nice.. but we arnt apple 02.38.28 # if you can make things nice, you should 02.38.38 # inside rockbox it should be as pretty as the user wants... early rockbox should be simple small code 02.38.41 # They're *very* similar on greyscale ipods; on colour targets they're a bit more different as the diskmode version is monochrome 02.38.43 Join Blue_Dude [0] (n=chatzill@rockbox/developer/Blue-Dude) 02.39.09 # Sure we're not apple, but *you* seem to be caring about looks (hmm, not always though) 02.39.29 # I really just want a clean API and small codebase 02.39.46 # have we swapped? :) 02.40.08 # * amiconn doesn't think so 02.40.34 # its usually me arguing for prettyness and you arguning for no wasted code :) 02.41.04 # I don't deem built-in gfx a waste - I'd use them for the main statusbar as well 02.41.09 Quit bzed (Read error: 111 (Connection refused)) 02.41.09 Nick bzed_ is now known as bzed (n=bzed@devel.recluse.de) 02.41.26 # * amiconn also uses the built-in list icons - on almost all of his targets... 02.42.11 # the waste was adding the code to the skin engine to display them.. when on most targets there is no point because those images are too crap and small 02.42.24 # but anyway.. we are sort of in agreement here 02.42.48 # Making the usb screen (and charging screen) display the status in an all-different way may be in fact a good idea - the question is how it should look, and how such a screen fits into theming 02.43.48 # JdGordon: I don't think it would need much code - built-in gfx are essentially bitmaps which don't need to be loaded because they're preloaded 02.44.22 # just a list.. or something.. I tihnk that info is more important than the usb plug bitmap 02.44.46 # Nobody else wants to weigh on on the direction of the main audio engine? I'm a little surprised.... 02.44.49 # not even a list.. maybe just a progress bar at the bottom under the image for charge state 02.45.01 # Blue_Dude: you didnt use the improtant key words 02.45.14 # Which are? 02.45.30 # settings, delta, break, etc... 02.45.35 # JdGordon: For USB there's also disk activity, plus the connected thingies 02.45.43 # sure 02.45.47 # Oops, OK. 02.46.20 # Blue_Dude: it usually comes down to people not replying because they trust you know what you're doing... or you know more than we/they do... 02.46.32 # unless its something pretty contentious, there is no argument 02.46.47 # In my opinion, the quality delta of the current pcmbuf scheme is negative, important features are broken, and settings are imperfectly supported... 02.47.32 # and seen as you are the only one to really look at it recently, we will accept that opinion 02.47.48 # Blue_Dude: Better means just better as long as all people involved have the same definition of better. 02.47.49 # The choice is patch it or rewrite it. Patching is quick, cheap and ugly. Rewriting is long, expensive and potentially really good. 02.47.51 # a software mixer has been on the wishlist for quite a while 02.50.15 # I've tried patching, but the choice is still there. Going any further means committing to one or the other. 02.50.44 # if you have the energy... and you tihnk its worth it.. go the rewrite 02.51.41 # * JdGordon fears charcell is going to get in the way of his clean API :< 02.52.30 # That's the problem. It's going to be expensive. Expensive enough that people are going to howl and want the old way back because it costs too much. 02.52.53 # how expensive? 02.53.10 # 64k at minimum and a boosted thread. 02.53.12 # will it be able to work on all swcodec targets? the clip has 384KB RAM iirc 02.53.28 # Only if I steal from its pcmbuffer first. 02.53.43 Part gTanzola 02.54.01 # It might end up with .6 seconds of buffer vs 1 second. 02.54.30 # 284 cant be right... 2MB maybe? 02.55.19 # I was thinking of just making the buffer smaller and sneaking it in that way. But that means a stealth penalty of more CPU boosting, more disk access and shorter run time. But it hides RAM usage. 02.55.48 # Or I could take it from buffering and make it suffer. 02.55.55 # wont just adding a new buffer do the same anyway? 02.56.14 # is 64K the absolute minimum? 02.56.18 # Not if it's taken from somewhere else. 02.56.29 # it wouldnt worry me at all for most targets.. just the clip 02.56.34 # 64k? Yeah, that's about right. Two chunks plus larger code. 02.57.37 # Or I can make the chunks smaller but that still means more frequent pcm interrupts and overhead. Not as expensive as a smaller buffer I don't think. 02.57.50 # I say go for it :) I'm sure if you fix it so we can pause and have voice then most others would agree 02.58.02 # get it working with a big ram usage and tweaklater? 02.58.16 # Maybe. 02.58.51 # The first commit will have a screamingly bad red delta. 02.59.07 # big deal 02.59.18 # And it won't ever get much better. 02.59.34 # hang on.. you cant steal from the 512KB pcmbuf thats already there? 03.00.07 # Yes of course. But that means more boosting, more disk access, less runtime, etc. Stealth RAM steal. 03.00.39 # The mixer needs to be able to run unboosted 03.00.40 # And IIRC the Clip only has a 176k buffer. 03.01.08 # The mixer probably can, but a smaller buffer means the watermark is hit more often, meaning more boosting. 03.01.27 # The pre-mixer buffer needs to keep its size 03.01.48 # Changing boost state too often is bad on a number of targets 03.01.49 # Then I need to take 64k from somewhere else... 03.02.25 # Or something smaller but put up with the increased callback overhead. 03.02.52 # is the mixing too slow to be done in the PCM interrupt? 03.03.44 # i.e. all where changing boost state involves relocking the pll. On such targets each switch costs a certain time (up to a few milliseconds), during which the cpu busy-waits, and is usually running *slower* than in unboosted state 03.03.53 # then there is no extra thread, or buffers... just mix at the lats possible moment before going out to the codec? 03.04.03 # Maybe. If it's actually mixing it means manipulating about 32k of data, and not just a copy, but combining two or more streams. 03.05.00 # I'd limit mixing to two streams, and do it in an isr, only a few samples at a time (depending on whether the target uses dma or not) 03.05.34 # Even a very short clip uses several thousand samples though. 03.05.45 # 10ms is 441 samples 03.06.06 # And I bet we could go lower than that 03.06.18 # And the pcm callback looks at 32k chunks at a time. 03.06.19 # On PP it may be possible to mix right in the fiq 03.06.42 # if you reuse the voice stream or beeps, they could be pre mixed... 03.06.58 # That's dependent on user cooperation. You can't assume that. 03.07.12 # sure you can... both are instantaneous events 03.07.17 # Pre-mixed is what we have now - it's bad for latency (and there is the pause issue) 03.07.17 # you wouldnt want to uncouple them 03.07.25 # Right. 03.07.50 # The problem is just-in-time mixing, but not too late... 03.07.57 # so the premix buffer there might be 1s worth.. which almost immediatly gets mixed with the audio.. most of the time you owuldnt be doing any mixing 03.08.10 # 1s is too much for voice 03.08.18 # these codecs where the gap between 4.0.3 performance and 4.4.2 performance widens as bitrate goes up make me wonder if the bitstream unpacking is where one compiler or the other ran into trouble optimizing... 03.08.34 Join done365 [0] (n=done365@75-107-207-224.cust.wildblue.net) 03.09.25 # Even the 64k I want is only two chunks of .18 seconds of audio. If I can't have *that* then 1s buffers are completely out of the question. 03.10.09 # n1s: things look a little bit worse for 4.4.2 after i apply your patch and benchmark each -O level with 4.0.3. mpc, vorbis, wma, ac3 all slower... wma by 4.4% 03.10.48 # Well, of course you need a second buffer for the second stream (i.e. voice). Post mix you shoulnd't need more than a few hundred samples 03.10.51 # That's where the 64k comes from: two premix buffers, one active and one mixing. That will minimize memory moves and interference with the DMA. 03.11.42 Join kugel [0] (n=kugel@rockbox/developer/kugel) 03.12.01 Join AEnima1577 [0] (n=clbarnob@nc652101a.cns.vt.edu) 03.12.25 # Maybe it's possible to use really small buffers only when mixing, only a few hundred samples as you say. But callbacks will happen *very* frequently while mixing is going on. 03.12.25 # Blue_Dude: why don't you rewrite/patch it so that the non-destructive thing can be added after the initial work? 03.12.50 # IIUC that's the only questionable bit, I don't see why it's so critical to add in the first run 03.13.27 # kugel: That's the problem. I can patch it but every patch is locking in the current scheme. It "fixes" problems without addressing basic functionality. 03.13.37 Quit Jake ("CGI:IRC") 03.13.42 # so rewrite 03.14.08 # Well yeah, that's where I'm going. I don't mind the rewrite but it's going to hurt. 03.14.10 # Blue_Dude: apart from crossfade mixing (and even then this might be valid)... actual mixing doesnt happen often (relatively speaking)... it woiuld spend a lot more time just dumping the one stream than mixing 03.14.41 # Blue_Dude: I'm really only skeptical about the potential bloat the non-destructive mixing gives 03.15.12 # JdGordon: Right. Even after the rewrite it will mostly do the same thing it's doing now. It's the mixing part that needs its guts ripped out for. 03.15.20 # * JdGordon also doesnt see the value in non destructive mixing... if you mix late enough 03.16.11 # JdGordon: same thing. Really late non-destructive mixing is no mixing at all until feeding the DMA. 03.16.25 # I'm sure you can make it all well while post-poning the decision about non-destructive 03.17.41 # * kugel votes for keeping it simple for the start 03.18.14 # a rewrite is painful, even more if you you plan to much for the initial work 03.18.20 # too* 03.18.28 # This is a classic case of processor time vs memory usage. The more memory you use the less processor time you need. But no matter what, at *some* point the two streams are going to be mixed. Right now they are mixed in as far as the voice codec is willing to feed, (or the voice buffer runs dry) 03.19.23 # JdGordon: merging this two function is a really stupid idea IMO 03.19.28 # with absolutely no gain 03.19.32 # not true 03.19.33 # the code inside is completely different 03.19.40 # yes 03.19.41 # But then it's mixed all the way in right away, and that causes problems. The pause problem is solvable, but without later mixing (which *will* require memory), the result will be unpretty. 03.19.42 Part done365 03.19.45 # merge the API... not the code 03.19.58 # calling the same function to get different results? 03.20.00 *** Saving seen data "./dancer.seen" 03.20.03 # if they ask for full screen, then if they didnt disable the theme there will be problems 03.20.22 # if they didnt disable the theme then they should expect to be using the theme viewport 03.20.46 # its a sanity check thing 03.20.58 # Blue_Dude: "unpretty" isn't an issue here 03.21.15 # what is the point of merging them? 03.21.23 # that's calling for confusion 03.21.56 # I thought it was *the* issue myself. 03.21.58 # a single function that yields different *logical* results based on magic is a bad functions 03.22.15 # its not magic at all.. and thats why I changed the name 03.22.29 # the usage is "I want to draw.. give me the area to draw in" 03.23.17 # there's no point, just don't do it 03.23.44 # * kugel is annoyed by some of JdGordon latest crazy ideas 03.24.41 # Blue_Dude: ? 03.25.32 # kugel: "unpretty" is choppy illegible audio. For a DAP firmware I'd put that pretty high on my list of undesirable attributes. 03.25.54 # I'm making it simpler to use... if you can see the logical flaw then fine.. but if there isnt one, then keeping the current API is bad because it causes problems and makes bad assumptions 03.26.02 # how do you know already it's going to be choppy? 03.26.12 # maybe it'll just be immediately slilent? 03.26.46 # JdGordon: that's not simplifying 03.27.02 # that's introducing bad practice imo 03.27.21 # not at all.. if forces you to be explicit 03.27.37 # it means you dont forget to disable the sbs after stealing the whole display 03.27.53 # how's that related to combining the two functions? 03.28.10 # kugel: I'm getting back to the pause/stop problem. Unless something changes, voice is dependent on main audio playback. Interrupt that, and the mix goes out the window. Resume and the obsolete mix is still going to be played. 03.28.45 # either way you need to be explicit, but for a) you call a different function to get a different result, for b) you call the same function which is now magically right for you 03.29.21 # either way you have to set the theme start first, that we agree on... then if you've done that, why should you need to know the difference between two functions? 03.29.25 # Blue_Dude: and we cannot talk about the non-destructive thing after the rewrite happend? 03.29.26 # And I've noticed that voice clips are not necessarily short. Some are several seconds long. Some are queued one behind the other. It's "not pretty". 03.29.35 # the flow is "Set the theme" then "give me the viewport i can draw in" 03.29.53 # The "non-destructive thing" *is* the rewrite. 03.30.06 # I thought mixing multiple sources was 03.31.02 # Nope. Each source needs its own (smallish) buffer, but that's not the problem. The problem is making the streams independent of each other. 03.31.36 # How many simultaneous sources do we need to accommodate anyway? 03.31.54 # depends how crossfade is done 03.31.59 # I'd say 2 or 3 03.32.22 # JdGordon: because it gives different results! 03.32.28 # no it doesnt 03.32.35 # I'm too tired now. I really dislike that bit 03.32.42 Quit kugel ("exit(0);") 03.33.00 # hrm, an interesting test_codec feature might be the ability to benchmark a directory of compiled .codec files against one audio file... 03.34.59 # JdGordon: crossfade only occurs on the primary channel. It does "mix" but I wouldn't consider it a second source. It's more of a really late DSP effect than a mix. 03.35.30 # then I'd start with voice/beeps as one, and audio as a second 03.36.10 # and the next step after that is acovea for optimizing codecs :) 03.36.51 Quit LambdaCalculus37 ("POOF") 03.37.02 # That's exactly what we have now, except that it's mixed in in 8k chunks. Well, no, since beep mixes as much as it wants. It's "not pretty" also. 03.40.27 # Pushing the mix later means mixing right at the bottleneck and *that* means more memory. It can be nearly instantaneous, but the input stream is diverted instead of mixed in place. The number of inputs isn't the issue; independent operation is. 03.40.52 Quit StealthyXIIGer (Read error: 54 (Connection reset by peer)) 03.41.02 Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) 03.52.47 Quit MethoS- (Remote closed the connection) 03.53.14 Quit hepub (Read error: 110 (Connection timed out)) 04.07.06 Quit TheSeven (Nick collision from services.) 04.07.24 Join The_Seven [0] (n=theseven@rockbox/developer/TheSeven) 04.07.36 Nick The_Seven is now known as TheSeven (n=theseven@rockbox/developer/TheSeven) 04.08.48 Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) 04.12.54 Part froggyman 04.17.23 Quit Rondom (Nick collision from services.) 04.17.34 Join Rondom [0] (n=Rondom@dslb-084-057-176-237.pools.arcor-ip.net) 04.23.41 Quit Lss (Read error: 104 (Connection reset by peer)) 04.41.09 # New commit by 03jdgordon (r23731): have buildzip copy the classic_statusbar.grey/mono correctly 04.43.04 Join Lss [0] (n=Lss@cm205.delta92.maxonline.com.sg) 04.50.12 Quit AEnima1577 ("Leaving.") 04.50.49 Join AEnima1577 [0] (n=clbarnob@nc652101a.cns.vt.edu) 04.51.54 Quit evilnick (Ping timeout: 180 seconds) 04.53.02 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 04.56.15 Quit Strife89 ("Bed.") 04.57.37 Quit AEnima1577 ("Leaving.") 05.04.38 Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.5.5/20091102152451]") 05.15.46 # kkurbjun: any thoughts on my most recent ml topic? 05.15.56 # specifically simplifying the api to make life much easier? 05.16.47 Quit StealthyXIIGer (Read error: 104 (Connection reset by peer)) 05.16.55 Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) 05.18.00 # JdGordon: do screens need to be aware of the amount of space they have? For plugins their menu's should be the same as the other lists, or were you thinking of other cases? 05.19.09 # the code snippet is how it would work.. so screens would try with the theme enabled, if its not enough then theyd get the ful screen on request 05.19.18 # plugin menus would instantly just work again 05.19.40 # do_menu() would always say "use the theme" 05.19.48 # unless told not to 05.20.01 *** Saving seen data "./dancer.seen" 05.23.23 # doing viewportmanager_theme_enable(i, true, NULL); would be the equivilant of enabling the theme and calling set_default in one call... 05.23.33 # NULL being a viewport pointer though... 05.24.17 # * JdGordon attempts to wiggle this in without removing the inbuilt bar 05.25.17 # sounds reasonable, I don't know the api enough to really say though, I'd need to look at it more 05.51.12 Quit alexbobp (Remote closed the connection) 05.51.30 Join alexbobp [0] (n=alex@66.112.249.238) 05.52.59 Quit StealthyXIIGer (Read error: 54 (Connection reset by peer)) 05.53.21 Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) 05.59.07 Quit StealthyXIIGer (Read error: 54 (Connection reset by peer)) 05.59.13 Join hd [0] (n=jd@modemcable207.134-202-24.mc.videotron.ca) 05.59.20 Join AEnima1577 [0] (n=clbarnob@c-98-249-3-190.hsd1.va.comcast.net) 05.59.26 Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) 06.02.37 Join AEnima15771 [0] (n=clbarnob@h80ad26c3.async.vt.edu) 06.05.44 Quit HellDragon_ (Read error: 60 (Operation timed out)) 06.12.49 Quit kkurbjunW (Remote closed the connection) 06.14.51 Join kkurbjunW [0] (n=karlk@12.41.166.9) 06.18.27 Quit AEnima1577 (Read error: 110 (Connection timed out)) 06.20.18 Join phanboy_iv [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net) 06.30.48 Join TaZzZ [0] (i=GamingEx@hidden.botpack.eu) 06.31.14 # having issues with rockbox install .. its stuck on the themes part of install 06.32.16 # the rockbox utility is locked up 06.33.41 Quit phanboy4 (Read error: 110 (Connection timed out)) 06.38.40 Join ecognito [0] (n=evan@ppp118-209-67-70.lns20.mel4.internode.on.net) 06.38.46 Quit panni_ (Read error: 104 (Connection reset by peer)) 06.42.26 # Hi. Is it possible to change the order that items appear in the main menu? 06.42.59 # Not without recompiling 06.43.13 # Bummer. Thanx. 06.45.56 # how do i get it to boot back to the ipod os if i wanted to 06.49.24 Quit ecognito ("So that's what an invisible barrier looks like!") 06.49.52 # TaZzZ: That differs from player to player, but is in the manual which we ask you to read before asking here. 06.54.55 Quit avacore (Read error: 60 (Operation timed out)) 06.56.11 Join avacore [0] (i=nobody@90.184.100.129) 06.58.33 Join bluebrother [0] (n=dom@f053155021.adsl.alicedsl.de) 06.59.36 # Llorean this rockbox rox 06.59.59 # what model ipod TaZzZ 07.00.21 # 5.5 07.00.27 Quit bluebroth3r (Read error: 60 (Operation timed out)) 07.00.59 # awesome 07.12.20 # New commit by 03FlynDice (r23732): AMS Sansa: Remove wait_for_state() following transfer in sd_select_bank() function. ... 07.15.31 # ok i have noticed it plays mpg vidoe files.. does it support mp4 videos? 07.15.48 Part kkurbjunW 07.20.03 *** Saving seen data "./dancer.seen" 07.21.35 # http://www.rockbox.org/wiki/PluginMpegplayer TaZzZ 07.22.24 Quit CaptainKewl (Remote closed the connection) 07.29.45 Quit StealthyXIIGer (Read error: 110 (Connection timed out)) 07.30.13 Join hepub [0] (n=hepub@CPE0002a5b23cad-CM001bd7ac3c2a.cpe.net.cable.rogers.com) 07.37.39 # New commit by 03FlynDice (r23733): AMS Sansa: Remove MCI_RX_ACTIVE FIFO check following SD transfers. ... 07.44.08 Join Horschti [0] (n=Horscht2@xbmc/user/horscht) 07.46.59 Join LinusN [0] (n=linus@rockbox/developer/LinusN) 07.58.43 Quit HBK (Read error: 104 (Connection reset by peer)) 08.00.10 Join Bagder [0] (n=dast@giant.haxx.se) 08.01.42 Quit xavieran (Read error: 104 (Connection reset by peer)) 08.02.53 Quit Horscht (Read error: 110 (Connection timed out)) 08.05.10 Nick Zarggg_ is now known as Zarggg (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 08.09.56 Join xavieran [0] (n=xavieran@ppp118-209-137-145.lns20.mel6.internode.on.net) 08.10.06 Quit hepub (Read error: 110 (Connection timed out)) 08.12.48 Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) 08.20.23 Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) 08.21.32 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 08.48.45 Join matsl [0] (n=matsl@dhcp126.contactor.se) 08.50.22 Join Rob2223 [0] (n=Miranda@p4FDCE2B4.dip.t-dialin.net) 08.58.09 Quit Rob2222 (Read error: 145 (Connection timed out)) 09.09.41 Join maruk [0] (n=papier@titanium.sdv.fr) 09.16.25 Join einhirn [0] (n=Miranda@139.174.4.164) 09.18.25 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 09.20.06 *** Saving seen data "./dancer.seen" 09.22.45 Join Jake [0] (n=60185bdd@83.168.254.42) 09.23.14 # So... what are the best setting to use for video on the Sansa c240? 09.23.58 # I tried some things, but all I've gotten are some pretty colors and odd sounds. 09.24.03 Join petur [50] (n=petur@rockbox/developer/petur) 09.27.18 # there's guidelines/suggestions on the MPEG Plugin page Jake http://www.rockbox.org/wiki/PluginMpegplayer 09.27.46 # I've been reading that, but I guess I missed something. 09.28.04 # search the page for sansa, you'll find it 09.29.16 # I need to find a micro SD card lol. 09.29.25 # 1gb just is not enough space... 09.36.04 # Yay got it to work 09.42.07 # Now if only this screen was bigger.. 09.44.20 Quit Thundercloud (Remote closed the connection) 09.47.56 # amiconn: (answering your reply from 8h 40m ago) - viewports read from user input (wps etc) are checked at parse time, and the wps rejected if the viewports are invalid. 09.50.26 Quit Grahack ("Leaving.") 09.55.35 Join MethoS- [0] (n=clemens@134.102.106.250) 09.58.43 Quit MethoS- (Remote closed the connection) 10.15.00 Join kugel [0] (n=kugel@rockbox/developer/kugel) 10.16.59 Quit KingJew (Read error: 110 (Connection timed out)) 10.34.26 Quit kugel (Read error: 104 (Connection reset by peer)) 10.36.12 # Utchybann: Argh. Now this is really ugly, but probably the only way that works properly... :-/ 10.37.43 # gevaerts, LambdaCalculus37: Rockbox USB works for me on nano2g, but there seem to be some (rather rare) devices where it fails in a weird way. 10.37.51 # liar is trying to track this down 10.40.52 # TheSeven: I know this is an ugly hack. Perhaps, a line of comment that explain why we need this would be nice and help us to remember. 10.42.10 # TheSeven: do you (or linuxstb) remember what was wrong with HAVE_WHEEL_ACCEL. I have activated it and it seems to work for me. 10.43.44 # I guess that the problem was related to the USEC_TIMER issue. 10.43.59 # I can't remember having touched that... so probably it is just nobody bothered defining it? or maybe disabling it was a workaround back when the wheel driver was all shaky? 10.44.38 # Utchybann: I think the proper way to fix this would be using a function to read the usec timer instead of a define 10.45.01 # you could still #define that function to just be a reg on other devices then 10.45.11 # but this of course involves touching a lot of code 10.45.50 Quit phanboy_iv (Read error: 104 (Connection reset by peer)) 10.46.01 # TheSeven: a function would have less chance to be optimize by gcc in newer version. 10.47.58 # Utchybann: When I enabled it, the wheel became very sluggish. So yes, very likely a timing issue, although the code shouldn't have been using USEC_TIMER (as it didn't exist). 10.49.18 # Utchybann: we must *PREVENT* this from getting optimized, so an (inline) function would probably be the best solution for this 10.55.00 # linuxstb: ok. On my nano2g with r23722 and USER_TIMER fixed, HAVE_WHEEL_ACCEL seems fine. 10.55.47 # TheSeven: let's go for a function. 10.56.19 Join Grahack [0] (n=chri@82.216.222.222) 11.20.07 *** Saving seen data "./dancer.seen" 11.54.11 Join DerPapst [0] (n=DerPapst@p4FE8F710.dip.t-dialin.net) 12.03.01 # Zagor: clip on current builds page is showing an old version (r22777) - can you look into this please? 12.06.18 # mc2739, Zagor: that's due to a clip vs sansaclip mismatch somewhere. The rest uses sansaclip 12.07.51 # gevaerts: would that be why the manual did not build also? 12.10.41 Join martian67 [0] (n=xD@about/linux/regular/martian67) 12.10.50 Quit martian67 (Remote closed the connection) 12.11.18 Quit TheSeven (Read error: 113 (No route to host)) 12.12.47 Join martian67 [0] (n=arkfar@about/linux/regular/martian67) 12.13.52 # mc2739: I suspect that both should be "sansaclip", i.e. r23724 was wrong for both files 12.17.20 Join kugel [0] (n=kugel@rockbox/developer/kugel) 12.17.20 # gevaerts: if r23724 was wrong then I guess r23727 is also wrong 12.20.53 Quit shodanX (lindbohm.freenode.net irc.freenode.net) 12.20.53 NSplit lindbohm.freenode.net irc.freenode.net 12.20.53 Quit FlynDice (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit rasher (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit dionoea (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit jordan` (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit Xerion (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit J-23 (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit Jake (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit einhirn (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit Tomis (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit lostlogic (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit solexx (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit gevaerts (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit shai (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit FOAD (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit Llorean (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit jon-kha (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit GodEater (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit Slasheri (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit yosafbridge (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit shaggy-h (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit jasio (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit ThomasAH (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit ChanServ (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit DerPapst (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit HBK (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit xavieran (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit antil33t (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit tha (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit goffa (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit AlexP (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit kadoban_ (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit sbhsu (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit BlakeJohnson86 (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit togetic (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit Zambezi (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit Dhraakellian (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit bzed (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit ps-auxw (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit Overand (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit markun (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit knittl (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit fxb__ (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit fish_ (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit rjg (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit hatseflats (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit kugel (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit maruk (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit pixelma (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit linuxguy3 (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit tmzt (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit Res1 (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit grndslm (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit petur (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit Rob2223 (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit Zagor (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit bluebrother (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit tarbo (lindbohm.freenode.net irc.freenode.net) 12.20.53 Quit droidcore (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit tchan (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit JdGordon (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit fyrestorm (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit Torne (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit YPSY (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit scorche|sh (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit jds2001 (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit chaos (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit Trista281 (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit CIA-80 (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit martian67 (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit Grahack (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit Horschti (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit avacore (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit alexbobp (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit Lss (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit BHSPitMonkey (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit linuxstb (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit amiconn (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit mikroflops (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit killan (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit T44 (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit Utchybann (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit dmb (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit niekie_ (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit scorche (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit jfc^3 (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit bughunter2 (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit rvvs89 (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit n17ikh (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit Tuplis (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit rphillips (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit advcomp2019 (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit crashd_ (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit maraz (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit preglow (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit blithe (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit ehntoo (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit z35 (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit krazykit (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit lyngaas (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit TaZzZ (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit cendres (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit crwl (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit Unhelpful (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit B4gder (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit jvd (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit matsl (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit AEnima15771 (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit hd (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit SIGSEGV (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit gtkspert_ (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit Zarggg (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit Kopfgeldjaeger (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit Bagder (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit mc2739 (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit Galois (lindbohm.freenode.net irc.freenode.net) 12.20.56 Quit kkurbjun (lindbohm.freenode.net irc.freenode.net) 12.20.57 Quit zu_ (lindbohm.freenode.net irc.freenode.net) 12.20.57 Quit topik (lindbohm.freenode.net irc.freenode.net) 12.20.57 Quit elcan (lindbohm.freenode.net irc.freenode.net) 12.20.57 Quit Kohlrabi (lindbohm.freenode.net irc.freenode.net) 12.25.12 NHeal lindbohm.freenode.net irc.freenode.net 12.25.12 NJoin ChanServ [0] (ChanServ@services.) 12.25.12 NJoin jasio [0] (n=yann@cpc2-rdng20-2-0-cust902.15-3.cable.virginmedia.com) 12.25.12 NJoin shaggy-h [0] (n=kiwi@host-87-74-127-193.dslgb.com) 12.25.12 NJoin kugel [0] (n=kugel@rockbox/developer/kugel) 12.25.12 NJoin martian67 [0] (n=arkfar@about/linux/regular/martian67) 12.25.12 NJoin DerPapst [0] (n=DerPapst@p4FE8F710.dip.t-dialin.net) 12.25.12 NJoin Grahack [0] (n=chri@82.216.222.222) 12.25.12 NJoin petur [50] (n=petur@rockbox/developer/petur) 12.25.12 NJoin Jake [0] (n=60185bdd@83.168.254.42) 12.25.12 NJoin einhirn [0] (n=Miranda@139.174.4.164) 12.25.12 NJoin maruk [0] (n=papier@titanium.sdv.fr) 12.25.12 NJoin Rob2223 [0] (n=Miranda@p4FDCE2B4.dip.t-dialin.net) 12.25.12 NJoin matsl [0] (n=matsl@dhcp126.contactor.se) 12.25.12 NJoin HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 12.25.12 NJoin Zagor [242] (n=bjorn@rockbox/developer/Zagor) 12.25.12 NJoin xavieran [0] (n=xavieran@ppp118-209-137-145.lns20.mel6.internode.on.net) 12.25.12 NJoin Bagder [0] (n=dast@giant.haxx.se) 12.25.12 NJoin Horschti [0] (n=Horscht2@xbmc/user/horscht) 12.25.12 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 12.25.12 NJoin avacore [0] (i=nobody@90.184.100.129) 12.25.12 NJoin TaZzZ [0] (i=GamingEx@hidden.botpack.eu) 12.25.12 NJoin AEnima15771 [0] (n=clbarnob@h80ad26c3.async.vt.edu) 12.25.12 Join hd [0] (n=jd@Wikipedia/HellDragon) 12.25.12 NJoin alexbobp [0] (n=alex@66.112.249.238) 12.25.12 NJoin Lss [0] (n=Lss@cm205.delta92.maxonline.com.sg) 12.25.12 NJoin shodanX [0] (n=shodanX@jazz.informatik.uni-erlangen.de) 12.25.12 NJoin jordan` [0] (n=jordan@78.235.252.137) 12.25.12 NJoin Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) 12.25.12 NJoin FlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 12.25.12 NJoin dionoea [0] (n=dionoea@yop.chewa.net) 12.25.12 NJoin rasher [50] (n=rasher@rockbox/developer/rasher) 12.25.12 NJoin bzed [0] (n=bzed@devel.recluse.de) 12.25.12 NJoin BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 12.25.12 NJoin cendres [0] (i=ashes@modemcable076.241-176-173.mc.videotron.ca) 12.25.12 NJoin Tomis [0] (n=Tomis@70.134.65.177) 12.25.12 NJoin antil33t [0] (n=Mudkips@203-184-54-232.callplus.net.nz) 12.25.12 NJoin linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 12.25.12 NJoin tarbo [0] (n=me@unaffiliated/tarbo) 12.25.12 NJoin pixelma [0] (i=quassel@rockbox/staff/pixelma) 12.25.12 NJoin amiconn [0] (i=quassel@rockbox/developer/amiconn) 12.25.12 NJoin lostlogic [50] (n=lostlogi@rockbox/developer/lostlogic) 12.25.12 NJoin mikroflops [0] (n=yogurt@217-208-157-242-no112.tbcn.telia.com) 12.25.12 NJoin solexx [0] (n=jrschulz@85.176.117.164) 12.25.12 NJoin killan [0] (n=nnscript@c-94fc70d5.06-397-67626721.cust.bredbandsbolaget.se) 12.25.12 NJoin droidcore [0] (n=mark@76-10-140-107.dsl.teksavvy.com) 12.25.12 NJoin J-23 [0] (n=zelazko@unix.net.pl) 12.25.12 NJoin tchan [0] (n=tchan@lunar-linux/developer/tchan) 12.25.12 NJoin T44 [0] (n=Topy44@78.48.214.100) 12.25.12 NJoin gevaerts [0] (n=fg@rockbox/developer/gevaerts) 12.25.12 NJoin shai [0] (n=Shai@192.117.110.233) 12.25.12 NJoin SIGSEGV [0] (n=user@61.250.113.98) 12.25.12 Mode "#rockbox +o ChanServ " by irc.freenode.net 12.25.12 NJoin Utchybann [0] (n=lolo@ede67-1-81-56-102-26.fbx.proxad.net) 12.25.12 NJoin gtkspert_ [0] (n=gtkspert@203-206-46-209.dyn.iinet.net.au) 12.25.12 NJoin Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 12.25.12 NJoin FOAD [0] (n=dok@82.93.10.238) 12.25.12 NJoin tha [0] (i=1038@ccc2.rbg.informatik.tu-darmstadt.de) 12.25.12 Join Llorean [0] (n=DarkkOne@rockbox/user/Llorean) 12.25.12 NJoin goffa [0] (n=goffa@70.33.8.114) 12.25.12 NJoin JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 12.25.12 NJoin dmb [0] (n=Dmb@unaffiliated/dmb) 12.25.12 NJoin AlexP [0] (n=alex@rockbox/staff/AlexP) 12.25.12 NJoin fyrestorm [0] (n=nnscript@cpe-69-203-150-85.si.res.rr.com) 12.25.12 NJoin jon-kha [0] (i=jon-kha@kahvi.eu.org) 12.25.12 Join GodEater [0] (n=bibble@rockbox/staff/GodEater) 12.25.12 NJoin niekie_ [0] (i=quasselc@dreamworld.bergnetworks.com) 12.25.12 NJoin Kopfgeldjaeger [0] (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) 12.25.12 NJoin Slasheri [0] (i=miipekk@rockbox/developer/Slasheri) 12.25.12 NJoin yosafbridge [0] (n=yosafbri@64.71.152.39) 12.25.12 NJoin kadoban_ [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 12.25.12 NJoin linuxguy3 [0] (n=timj@adsl-75-57-190-229.dsl.emhril.sbcglobal.net) 12.25.12 NJoin scorche [50] (n=scorche@rockbox/administrator/scorche) 12.25.12 Join Torne [0] (i=torne@rockbox/developer/Torne) 12.25.12 NJoin jfc^3 [0] (n=john@dpc6682208002.direcpc.com) 12.25.12 NJoin mc2739 [0] (n=mc2739@rockbox/developer/mc2739) 12.25.12 NJoin tmzt [0] (n=tmzt@adsl-76-244-155-63.dsl.akrnoh.sbcglobal.net) 12.25.12 NJoin Res1 [0] (n=Res@user-0c6s6gs.cable.mindspring.com) 12.25.12 NJoin sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw) 12.25.12 Join bughunter2 [0] (n=bughunte@unaffiliated/bughunter2) 12.25.12 NJoin ThomasAH [0] (n=thomas@aktaia.intevation.org) 12.25.12 NJoin grndslm [0] (n=grndslm@174-126-14-4.cpe.cableone.net) 12.25.12 NJoin BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 12.25.12 NJoin togetic [0] (n=togetic@unaffiliated/ibuffy) 12.25.12 NJoin YPSY [0] (n=ypsy@geekpadawan.de) 12.25.12 NJoin blithe [0] (n=blithe@blakesmith.me) 12.25.12 NJoin Zambezi [0] (i=Zulu@80.67.9.2) 12.25.12 NJoin ehntoo [0] (n=ehntoo@lug.mtu.edu) 12.25.12 Join rvvs89 [0] (n=ivo@pdpc/supporter/base/rvvs89) 12.25.12 NJoin n17ikh [0] (n=n17ikh@host-69-59-126-212.nctv.com) 12.25.12 NJoin Galois [0] (i=djao@efnet.math.uwaterloo.ca) 12.25.12 NJoin ps-auxw [0] (n=arneb@dyn37.ps-auxw.de) 12.25.12 NJoin scorche|sh [50] (n=scorche@rockbox/administrator/scorche) 12.25.12 NJoin z35 [0] (n=z35@ool-45714f83.dyn.optonline.net) 12.25.12 NJoin krazykit [0] (n=kkit@adsl-76-251-250-122.dsl.ipltin.sbcglobal.net) 12.25.12 NJoin Dhraakellian [0] (n=ntryon@cpe-72-226-197-191.rochester.res.rr.com) 12.25.12 NJoin jds2001 [0] (n=jds2001@fedora/jds2001) 12.25.12 Join kkurbjun [0] (n=kkurbjun@rockbox/developer/kkurbjun) 12.25.12 NJoin zu_ [0] (n=zu@bucketheaded.eu) 12.25.12 NJoin crashd_ [0] (i=foobar@lostnode.org) 12.25.12 NJoin maraz [0] (i=maraz@xob.kapsi.fi) 12.25.12 NJoin topik [0] (i=awesome@wtf.grmpf.org) 12.25.12 NJoin chaos [0] (n=chaos@gentoo/user/ch4os) 12.25.12 NJoin preglow [0] (i=thomj@tvilling2.pvv.ntnu.no) 12.25.12 NJoin lyngaas [0] (n=staale@19.81-167-149.customer.lyse.net) 12.25.12 NJoin Trista281 [0] (i=tristan@i.dont.want.to.die.virgin.net.in) 12.25.12 NJoin CIA-80 [0] (n=CIA@208.69.182.149) 12.25.12 NJoin rphillips [0] (n=rphillip@66-90-184-91.dyn.grandenetworks.net) 12.25.12 NJoin elcan [0] (i=user36@pr0.us) 12.25.12 NJoin hatseflats [0] (n=hatsefla@193.200.132.183) 12.25.12 NJoin crwl [0] (n=crwlll@a91-156-100-168.elisa-laajakaista.fi) 12.25.12 NJoin B4gder [241] (n=daniel@rockbox/developer/bagder) 12.25.12 NJoin Kohlrabi [0] (n=Kohlrabi@frustrum.nosebud.de) 12.25.12 NJoin advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) 12.25.12 NJoin jvd [0] (n=syscrash@poipu/developer/syscrash) 12.25.12 NJoin Unhelpful [0] (n=quassel@rockbox/developer/Unhelpful) 12.25.12 NJoin Tuplis [0] (n=jani@unaffiliated/tuplanolla) 12.25.12 NJoin markun [50] (n=markun@rockbox/developer/markun) 12.25.12 NJoin Overand [0] (i=overand@crappy.domain.name) 12.25.12 NJoin fish_ [0] (n=fish@freigeist.org) 12.25.12 NJoin fxb__ [0] (n=felixbru@h1252615.stratoserver.net) 12.25.12 NJoin knittl [0] (n=knittl@unaffiliated/knittl) 12.25.12 NJoin rjg [0] (i=rgordon@odie.tomelliott.net) 12.25.17 Nick Tuplis is now known as Tuplanolla (n=jani@unaffiliated/tuplanolla) 12.25.17 # mc2739: daily builds is yet another different system 12.26.09 # linuxstb: that's of course an option. We need to decide on this one of these days... 12.27.11 # IMO what is in tools/configure has always been _the_ target name - and other names shouldn't have been used elsewhere. 12.27.44 # (whether the current names in tools/configure are good or bad is another question). 12.29.07 # I agree, but we can't just change that without involving the rbutil people and the themes site people, and seeing what we have to do for backward compatibility 12.29.20 Ctcp Version from freenode-connect!freenode@freenode/bot/connect 12.29.34 # I know - but the clip is new, so we can at least be consistent for that. 12.29.49 # (consistent in all places, rather than consistent with other sansas) 12.30.22 # petur did a big list a while back 12.30.22 # ok, so we change the build system name? 12.30.28 # s/list/table/ 12.30.41 # it should be consistent with other targets IMO 12.30.47 # with other sansas, I mean 12.30.49 # Zagor: That wasn't bluebrother? 12.30.52 # I did what? 12.31.03 # * petur scrolls back 12.31.05 # kugel: Even though those other sansas are wrong? 12.31.15 # yea 12.31.22 # my memory is not known to be very good... I thought it was petur (doing a big table of target name schemes) 12.31.33 # nope, wasn't me 12.31.34 # it's not wrong, it's different 12.31.42 # kugel: No, it's wrong. 12.31.47 # Zagor: I think it was rasher 12.32.02 # kugel: ok 12.32.08 # well, rasher made proposals, but we also have a wiki page with the current names 12.32.32 # kugel: which page is that? 12.33.01 # linuxstb: unfortunately, configure isn't the ultimate source either. there are targets with the same configure name, but different builds 12.33.18 # kugel: really? 12.33.23 # kugel: Yes, I know. Which is why I said "as far as possible". 12.33.28 # gevaerts: Different RAM sizes. 12.33.43 # hm, indeed 12.33.55 # Zagor: http://www.rockbox.org/wiki/BuildNames 12.34.09 # kugel: thanks 12.34.13 # well, configure-name + suffix can work 12.35.23 # this was it: http://rasher.dk/rockbox/targetnames.php 12.35.36 # the page is a bit out of date though 12.35.49 # Yes. Fixing older targets is a fair amount of work, but I think that we should at least agree on a convention for new targets, and "configure name + suffix if more than 1 build" is a simple rule. 12.36.14 # is there a way to know which name is needed fro any given system? 12.37.58 # linuxstb: if only the configure names were consistent 12.38.21 Join MethoS- [0] (n=clemens@134.102.106.250) 12.38.25 # kugel: I don't see that as the most important point. It's more important for the same name to be used everywhere. 12.38.41 # as in, how would you determine if you need "clip" or "sansaclip" 12.39.04 # mc2739: not currently ;) that's why we're discussing it 12.39.09 # mc2739: look in all places (sorry, I don't have a list) 12.39.54 # linuxstb: if we rework it now, then we can take the opportunity to make it good everywhere 12.40.45 # kugel: Sure, I'm not against someone changing the tools/configure names. I was just saying that we should use whatever name is there for new targets, such as the clip. 12.41.34 # I think we should make up a scheme that makes naming new targets easy, too. 12.42.19 # * kugel still favors the company/linemodel scheme 12.42.19 # such as the "company/linemodel" column in rasher's graph 12.42.27 # :) 12.43.49 # company/line/model/variant :) 12.45.19 # and any new ports added to svn should follow that scheme 12.47.59 # does anyone oppose the company/linemodel names as written up by rasher? 12.48.24 # the only one that is a bit odd is cowond2, since it's the only cowon that's not an "iaudio" 12.48.40 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 12.49.27 # cowon's web site lists d2, d2+ and s9 as "cowon" products. the rest are iaudio. 12.49.50 # so it's correct 12.50.37 # Zagor: are you volunteriing to make a patch? :) 12.50.41 # yes 12.50.47 # \o/ 12.51.24 # * kugel wonders if that could a enforced by a script 12.51.41 # what, exactly? 12.52.03 # like, instead of hardcoding the complete name, we ask for company, line and model separately, and then combine them as per rule 12.52.18 # sounds like a lot more work and bother 12.52.28 # on most places we use a single word 12.52.33 # so it wouldn't work 12.54.46 # Zagor: do you write a script that translates the names? 12.55.10 # I figure a 50 lines sed or so could work 12.55.42 # I haven't looked at the specifics yet. but some sed fu is likely useful 12.56.27 # as we need to upgrade a bunch of scripts and stuff I think it'll be useful, and it can also be provided so people using scripts externally can "upgrade" using such a script 12.59.41 Quit BHSPitMonkey ("Ex-Chat") 13.05.58 # New commit by 03funman (r23734): Sansa AMS: VIC_INT_ENABLE register is not a mask ... 13.11.45 # * linuxstb is perfectly happy with the existing configure names - they're short, unique and we all know them (or can easily look them up in tools/configure if we don't). 13.12.35 # * kugel isnt 13.13.03 # we should leave the existing working and add the new consistent ones 13.13.24 # and the new ones would then be used elsewhere when referring to specific targets 13.13.37 # they're inconsistent (e200 and ondavx747 for example). and those which are short are likely to clash with other targets (the m3-problem for example) 13.14.06 # ideally we shouldn't even need look up the names, the current configure names don't allow that 13.15.02 Join funman [0] (n=fun@rockbox/developer/funman) 13.15.32 # kugel: That simply isn't important IMO. The "m3 problem" isn't a problem - the solution was obvious. It just seems a waste of effort to go through and change all the places where the tools/configure name has been used (which I think are more places than when another name has been invented) 13.20.08 # what would cause the games not to work .. none of them 13.20.10 *** Saving seen data "./dancer.seen" 13.20.31 # TaZzZ: a flawed install 13.21.26 # ya was thinking of reinstalling 13.22.53 # the other thing .. this file that says database.ignore . just a txt file .. or waht kinda file cause its scanning all the stuff i dont want to .. and i made a file called database.ignore.txt and took the txt part off and its still lookin in that directory 13.23.59 # The database still goes through directories which contain a database.ignore file, it just doesn't add any files found there to the db 13.24.08 # the number of found files will continue to go up while it's doing htat 13.24.50 # Torne it did add them 13.25.15 # then your file is probably called the wrong thing.. 13.25.16 # funman: hi. I finaly managed to write a proper memmove_wrap() :) 13.25.28 # rockbox doesn't read the file, so it doesn't matter what's in it 13.25.35 # it just has to exist. 13.25.47 # dionoea: hello, i just saw that, i hope it makes clip playback crashproof_ 13.25.51 # should i make it a txt and leave txt on it 13.25.59 # no, it has to be called database.ignore 13.26.00 # nothing else 13.26.53 # funman: the only issues is that copies of buffers bigger than half the ring buffer will probably be really slow 13.26.59 # *issue 13.27.25 # the code in SVN uses a simple loop anyway 13.28.20 # dionoea: I don't think that's a problem 13.28.55 # it could be optimised a bit with a local buffer (as mentioned in my last post) 13.29.17 # the situation where the moved size is bigger than half of the buffer exists only when the entire buffer is small anyway (therefore the moved buffer is even smaller) 13.30.02 # speed of buffering isn't going to be a problem on the clip as far as I can see 13.30.32 # you'll still be iterating a milion times if the buffer is 2MB big and you're moving 1MB of data :) 13.30.44 # with non linear data accesses 13.31.39 # we're really moving 30 or 40kB 13.32.04 # then why'd you have a problem with buffers bigger than half the ring buffer ? 13.32.07 # dionoea: the audio buffer isn't bigger than 400k actually 13.32.12 # ah ok 13.32.50 # hm i thought it was smaller but my clip reports 400kB 13.33.08 # * dionoea can't wait for the clip port to be in a usable state so he can convert his sister to rockbox 13.33.13 # I think moving 400k will be always fast enough on the clip, even if the algorithm is a bit slower than plain memmove 13.33.26 # also, working code is better than fast code :) 13.33.32 # :) 13.34.49 # "optimized crashes" 13.37.12 # I have another slightly modified version of the memmove checking code (which also makes sure that we don't overwrite data which shouldn't have been changed). I don't know if it's worth posting it on the tracker 13.37.46 # (not that I also only checked that it worked with 8 and 9 byte big ring buffers ... it should be enough but you never know) 13.37.57 # *note 13.39.01 # dionoea: you have a clip ? 13.39.11 # my sister does 13.39.41 Quit kugel (Read error: 60 (Operation timed out)) 13.39.53 # but she's kind of on the other side of earth than me for the time being ... so I don't feel confident testing stuff on her clip that far away. 13.43.39 Quit Grahack ("Leaving.") 13.46.46 Join kugel [0] (n=kugel@rockbox/developer/kugel) 14.02.56 # funman: did you see my sd patch? 14.03.23 # no 14.03.50 # fs#10805 14.08.41 Part Bagder 14.16.46 # dionoea: why do you call it perfect? 14.18.23 # kugel: because I was glad to finally get it to work :) 14.18.28 # I'm sure that it's far from perfect 14.18.44 # it does't optimize for aligned moves (src, dst word aligned, n an integer multiple of word size), I think in buffering we have only this kind of moves 14.19.27 # ah, well that wouldn't be too hard to change. Just change the pointer to type to short * or something and it should work 14.24.11 Quit Kopfgeldjaeger ("Serverwechsel") 14.25.38 Join Kopfgeldjaeger [0] (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) 14.26.36 Quit DerPapst ("Leaving.") 14.31.47 Quit Kopfgeldjaeger ("Serverwechsel") 14.40.52 Join adiroiban [0] (n=adiroiba@h194-54-129-79.teleson.ro) 14.42.32 Join FOAD_ [0] (n=dok@dinah.blub.net) 14.44.07 # sed script: http://rockbox.pastebin.com/m3cd9561 14.51.31 Quit FOAD (Read error: 145 (Connection timed out)) 14.51.31 Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) 15.01.49 Join thegeek [0] (n=nnscript@129.241.123.168) 15.18.15 # Zagor: lang files use things like "yh*" or "gigabeat*" to match target names. Also, there are a fair number of files with names that are based on the configure names - will you be renaming them? 15.18.51 # yes I will 15.20.12 *** Saving seen data "./dancer.seen" 15.22.12 # Zagor: There's a typo in the m5 line of your sed script 15.22.30 # yeah I saw that. thanks for checking! 15.22.50 # and yes, lang files will require different replace rules 15.25.21 # Zagor: line 34 also has an error - \bc200 should be \bc100 15.25.40 # If you change the Sansa names, then the bootloader files on the download server should be renamed, and mkamsboot needs changing to use them. Also, checkwps uses the configure names in its build script, and I'm guessing the theme site too.... 15.26.06 # * linuxstb _really_ doesn't see the point in all that work - just fix the far fewer places where the configure name isn't being used... 15.26.11 # yes, it's a big job 15.27.17 Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) 15.27.33 # some of the configure names simply suck. such as the x5, m5 and m3 ones 15.27.38 Quit antil33t (Read error: 101 (Network is unreachable)) 15.27.54 # consistency is a value in itself, in my opinion 15.32.24 Quit kugel (Read error: 110 (Connection timed out)) 15.33.11 Join Topy [0] (n=Topy44@f048059001.adsl.alicedsl.de) 15.36.42 Part adiroiban 15.39.03 # Zagor: "suck" seems a bit strong - they don't offend me. Consistency in all the places a specific name is used is the only thing I care about. But if you want to do all the extra work to change configure names, I wish you luck. 15.40.49 Join antil33t [0] (n=Mudkips@203-184-54-232.callplus.net.nz) 15.44.58 Join DerPapst [0] (n=DerPapst@p4FE8F710.dip.t-dialin.net) 15.50.45 Quit T44 (Read error: 110 (Connection timed out)) 16.00.27 # New commit by 03mc2739 (r23735): Correct r23724 and r23727 - clip -> sansaclip 16.05.29 # Zagor: At you convienience, would you do a web server update? 16.05.52 # s/you/your/ 16.06.00 # just don't do it again :) 16.10.39 # Zagor: Thanks. That fixed the daily and manual pages, but the current builds page has clip is missorted and has no link. Is that something I messed up, or is that something only you can fix? 16.11.25 # * linuxstb thought we had agreed configure names were definitive... 16.11.59 # mc2739: you forgot one line in rockbox.pm 16.12.06 # I fixed it 16.12.36 # New commit by 03zagor (r23736): clip => sansaclip 16.13.03 # linuxstb: they will be 16.15.08 Join pamaury [0] (n=pamaury@140.77.26.133) 16.16.27 # has there ever been another Tatung Elio than the tpj1022? their current product range doesn't use the elio name at all and all google hits I do just call it elio or "elio tpj1022" 16.17.05 Join panni_ [0] (i=hannes@95.222.21.143) 16.17.39 # so perhaps the name should be tatungtpj1022 rather than eliotpj1022. 16.17.45 # or even tatungelio 16.20.37 Join roolku [0] (n=roolku@77-99-223-115.cable.ubr16.sgyl.blueyonder.co.uk) 16.20.41 # Zagor: thanks again 16.20.42 Join Omlet [0] (i=omlet05@91.181.227.166) 16.21.36 # Zagor: there is the p810 http://www.wikio.co.uk/guide/tatung-elio-p810-4911.html 16.22.12 # yeah but tatung don't call that one elio: http://www.tatung.com/3codm/portable.asp 16.26.09 # Zagor: are there actually more than two in existence? ;) 16.26.14 # quite a few other sites do though... http://www.googlefight.com/index.php?lang=en_GB&word1=Tatung+Elio+P810&word2=Tatung+-Elio+P810 16.26.36 # gevaerts: I have two and linuxstb has one. :) 16.26.49 # ok, so there are three :) 16.27.27 Quit funman ("free(random());") 16.28.04 Quit matsl (Read error: 110 (Connection timed out)) 16.32.15 # roolku: amiconn now has my Elio 16.32.33 # (it's chasing Linus's ipod around the world...) 16.34.07 Join toffe82 [0] (n=chatzill@12.169.218.14) 16.34.54 Join evilnick [0] (i=4571af51@rockbox/staff/evilnick) 16.36.45 Join dfkt_ [0] (i=dfkt@unaffiliated/dfkt) 16.38.15 Quit dfkt (Nick collision from services.) 16.38.19 Nick dfkt_ is now known as dfkt (i=dfkt@unaffiliated/dfkt) 16.41.34 # linuxstb: cool. maybe time to share my measly findings... 16.42.56 # New commit by 03roolku (r23737): Tatung Elio: a few more buttons identified 16.43.55 Nick YPSY is now known as Ypsy (n=ypsy@geekpadawan.de) 16.51.04 Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) 16.54.32 Join cowgarden [0] (n=qgar10@94.221.250.163) 16.55.08 # wow, congratullations so the speed regulation, listening to voice at 250% still sounds very very good 16.55.31 # is that very recourcehungry? 17.03.06 Join kugel [0] (n=kugel@rockbox/developer/kugel) 17.03.21 Quit Zagor ("Don't panic") 17.03.25 Quit kugel (Read error: 104 (Connection reset by peer)) 17.07.39 Join kugel [0] (n=kugel@rockbox/developer/kugel) 17.10.27 Join Strife89 [0] (n=michael@168.16.239.253) 17.10.30 Join kugel__ [0] (n=kugel@e178111115.adsl.alicedsl.de) 17.10.59 Quit kugel__ (Client Quit) 17.14.34 Join kugel__ [0] (n=kugel@e178111115.adsl.alicedsl.de) 17.15.41 Quit kugel (Nick collision from services.) 17.15.45 Quit kugel__ (Client Quit) 17.15.55 Join kugel [0] (n=kugel@rockbox/developer/kugel) 17.20.13 *** Saving seen data "./dancer.seen" 17.26.16 Quit kugel (Read error: 104 (Connection reset by peer)) 17.26.28 Part toffe82 17.26.54 Join kugel [0] (n=kugel@rockbox/developer/kugel) 17.26.59 Join toffe82 [0] (n=chatzill@12.169.218.14) 17.27.20 Quit roolku () 17.30.54 Quit kugel (Read error: 54 (Connection reset by peer)) 17.31.51 Join kugel [0] (n=kugel@rockbox/developer/kugel) 17.34.49 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 17.38.35 Quit StealthyXIIGer (Read error: 104 (Connection reset by peer)) 17.38.44 Join StealthyXIIGer [0] (n=stealthy@68.62.19.6) 17.39.22 Join FOAD_ [0] (n=dok@dinah.blub.net) 17.39.51 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 17.42.10 Quit pamaury ("exit(*(int *)0 / 0);") 17.43.33 Join bimbel [0] (n=Miranda@unaffiliated/bmbl) 17.55.35 Quit FOAD (Read error: 110 (Connection timed out)) 17.55.35 Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) 18.00.00 Quit bmbl (Connection timed out) 18.01.30 Quit Strife89 ("Lunch.") 18.03.59 Join minus [0] (n=minus@p5DC7174D.dip0.t-ipconnect.de) 18.04.07 # hello :) 18.07.00 # * Torne pesters anyone with a hard-disk based player to try out FS#10798 18.07.20 # i installed rockbox on my sansa fuze v1 yesterday and i have to say: it rocks, works almost without errors 18.07.30 # glad to hear it 18.07.42 Join solexx_ [0] (n=jrschulz@e182094011.adsl.alicedsl.de) 18.07.47 Join Lear [0] (i=chatzill@rockbox/developer/lear) 18.08.59 # Torne: I need to find my samsung :( 18.09.06 # kugel: heh 18.09.11 Join hebz0rl [0] (n=hebz0rl@dslb-088-065-209-022.pools.arcor-ip.net) 18.09.18 # i've tried it on ipodvideo and beast 18.10.09 # which actually covers most of the configs, tbh 18.10.17 # beast has DMA, and ipodvideo has large sectors 18.11.34 # i guess i could commit it, but i doubt i'll be anyone's friend if it turns out that i've broken disk writes somehow :) 18.13.23 Join Coldarchon [0] (n=chatzill@p5B27CBBB.dip.t-dialin.net) 18.15.02 Quit solexx (Read error: 145 (Connection timed out)) 18.15.33 # anyone there? after the utility failed I tried the manual install on an ipod nano 1st generation, but ipodpatcher always craches. any ideas? 18.16.51 # what os, and at what point does it crash, and what happened when you used rbutil? 18.17.24 # * kugel doest have the slightest idea where his samsng is 18.17.36 # Coldarchon: can you copy/paste on http://pastebin.com/ the output of 'ipodpatcher -l' ? 18.18.07 # on win xp, rbutil couldnt install any files and the patcher errors reading from disk after trying to move images 18.18.41 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 18.19.10 Join funman [0] (n=fun@rockbox/developer/funman) 18.19.17 Quit petur ("work->home") 18.19.44 # http://pastebin.com/m5eeb23ea 18.19.46 # done 18.21.26 # I formated, put the patch onto the ipod, started via cmd from there, it all fails 18.21.52 # hm 18.22.02 # Torne: I found it, let me reboot 18.22.10 # (into linx to make a buil :) ) 18.22.20 Quit kugel ("exit(0);") 18.22.42 # Coldarchon: output seems good. Can you pastebin 'ipodpatcher --install' output ? 18.22.46 Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net) 18.23.53 # empty, it crashes 18.24.01 # I can make a screen if you want 18.26.00 # Coldarchon: my feeling is that you have some i/o error on your flash. 18.26.49 # hm, itunes works perfectly, it's just that the battery doesn't have energy for more than 1 hour 18.28.43 # itunes write to the second partition, ipodpatcher to the first one. 18.29.05 # makes sense in what I have read so far 18.30.19 # can you access the flash memory directly? 18.30.38 Join kugel [0] (n=kugel@e178111115.adsl.alicedsl.de) 18.30.51 # yepp, I can put files on it 18.31.05 # I even started that patcher from there 18.35.00 Quit maruk ("Leaving.") 18.35.37 Quit gevaerts (Nick collision from services.) 18.35.45 Join gevaerts_ [0] (n=fg@rockbox/developer/gevaerts) 18.36.11 # Coldarchon: Have you restored your ipod in itunes recently? That would access the same part of the flash that ipodpatcher does. 18.36.11 Nick gevaerts_ is now known as gevaerts (n=fg@rockbox/developer/gevaerts) 18.36.47 # I tried that after install failed and then formated again 18.37.24 Join freddyb [0] (n=fred@70.104.101.195) 18.37.55 # at first it was grey with a black font. is there something else than a format that I can do? 18.38.17 # What was grey with a black font? 18.38.33 # Torne: I'm confused. Isn't linking to the FS patches "providing the sources?" 18.38.39 # Coldarchon: why format after running itunes? 18.39.06 # freddyb: no. 18.39.08 # freddyb: No. _you_ have to provide the source. 18.39.28 # funman: I understand that in sd_wait_for_state() we want to include the time spent yielding in the timeout calculation is that correct? 18.39.36 # freddyb: i'm looking at your last patch, seeing if it works on the clip (works fine on fuze) 18.39.52 # Funman: thanks. 18.39.53 # I tried to install when it was blank, failed. format, failed. used itunes, then install, failed. formated and installed, failed. put the files manually on there, failed 18.40.02 # FlynDice: hm didn't you ask this some time ago ? 18.40.08 # any idea why dma doesn't work? 18.40.42 # FlynDice: looks incorrect, timeout should be total time, not total time spent in the sd thread 18.40.45 # kugel: 'dma' ? 18.41.13 # kugel: me, you mean? :) 18.41.13 # funman: for recording 18.41.24 # i didn't work on it further 18.41.46 # Torne: Then I guess I need them taken them down. I maxed my web space with just the binaries. Can you do that? 18.41.53 # funman: bertrik actually asked , but I remembered and noticed it wasn't done yet. I'm going to do it right now, just thought I'd make sure since you are around right now... 18.42.07 # last patch using DMA is 3 weeks old and causes error in recording code 18.42.45 # recording crashes on clip 18.42.46 # kugel: anyway can you try out various stuff involving writing? test_disk write verify possibly, or just usb? doesn't really matter where it comes from :) 18.42.59 # freddyb: you should be able to edit your own posts 18.43.06 # nope 18.43.55 # New commit by 03FlynDice (r23738): AMS Sansa: Include time spent yielding when figuring timeout in sd_wait_for_state(). 18.43.59 Quit AEnima15771 ("Leaving.") 18.44.10 # freddyb: what are you talking about with "providing the sources" ? can't find anything in the irc log 18.44.27 # freddyb: i posted on his forum threads, which is why you can't find it in the irc log 18.44.45 # he has three custom builds up for his alternative scrollwheel keyboard patch 18.44.49 # but no source 18.45.15 # music plays, so it can't be that bad :) 18.45.51 # GPL only requires you to provide the source when someone ask for it, not to distribute the sources with the binary 18.46.30 # funman: if you go with that option you have to be able to respond to requests for sources for three years 18.46.47 # so? 18.46.51 # so yes, you can do that, but there is some difficulty involved 18.46.56 # funman: It is less onerous to supply them along with IMO, but that is an option 18.47.01 # And provide a written offer, whatever that means 18.47.08 # it's simpler to just link to flyspray 18.47.21 # And then have to supply the source for three years 18.47.23 # that is *not* valid 18.47.24 # that's not sufficient for any of them. 18.47.34 # we're geeks, not lawyers! 18.47.45 # Torne: i emptied the bodies of the posts but I can't delete the posts "You cannot delete your own topics in this board." 18.47.55 # freddyb: I will delete them i fyou want them deleted.. 18.48.33 # * kugel edits apps/SOURCES and wonders why test_disk doesn't compile correctly 18.48.45 # kugel: works for me ;) 18.49.01 # funman: whether people respect the GPL is kinda important, though 18.49.06 # Thanks. Should FS#10763 be deleted/removed also? 18.49.33 # Torne: IMO the most important is to respect the spirit (make sure the sources are easily accessible) 18.49.34 # Torne: it was the wrong SOURCES :) 18.49.36 # er, why should the FS entry be deleted? 18.49.54 # Torne: same thing, right? 18.50.10 # freddyb: I see no binaryes on FS#10763 18.50.13 # freddyb: Sources must be available with binaries 18.50.20 # there are no binaries there 18.50.27 # Oh. 18.50.31 # if people couldn't post patches then the entire open source thing wouldn't really work :) 18.50.46 # IIRC you don't need to provide the sources until someone asks for them? 18.50.55 # is the file save "dialog" the same for all devices? 18.51.41 # kugel: you either need to make the sources available at the same time as the binaries, or you need to accompany them with a written offer to provide sources on request valid for at least three years 18.52.02 Join Sajber^ [0] (n=Sajber@c-5a3771d5.012-155-73746f22.cust.bredbandsbolaget.se) 18.52.12 # funman: what happened when clip crashed? 18.52.16 # freddyb: i've removed the thrads, anyay 18.52.16 # no idea 18.52.30 Join Tomis2 [0] (n=Tomis@70.134.82.83) 18.52.30 # argh, yh925 disk speed is soooooooo slow 18.52.31 # freddyb: and i'm not trying to stop you from demoing your patch :) 18.52.45 # <3MB/s I believe (the OF bootloader is way faster) 18.54.23 # Torne: test_disk passes on my gigabeat f 18.54.43 # good to hear 18.54.57 # i think this is several combinations.. the ata code is not *that* variable between targets 18.55.05 # * Torne waits for kugel :) 18.55.22 # * kugel waits for test disk to finish :) 18.57.12 # win! :) 18.57.40 # well that's several players it doesn't seem to have totally screwed 18.57.45 # shall i commit? :) 18.58.24 # Do you feel lucky? 18.58.29 # well, the better questoin is will waiting help it get tested any better. 18.58.47 # it gets tested a lot more if it's in the current build : 18.59.22 # i guess the alternative is "does anyone familiar with ATA want to have a read" 18.59.26 Quit Tomis (Read error: 145 (Connection timed out)) 18.59.27 # New commit by 03funman (r23739): Sansa AMS : fix recording ... 18.59.28 Nick Tomis2 is now known as Tomis (n=Tomis@70.134.82.83) 18.59.30 # because I have changed from doing WRITE SECTORS to doing WRITE MULTIPLE 18.59.37 # which is an actual semantic change to our interaction with the disk 18.59.48 # freddyb: thanks a lot :D 18.59.51 # (to better reuse the code for handling reads, and because it should be faster) 19.00.46 # funman, freddyb \0/ 19.01.16 # * kugel wonders if the clip recording crash is related to the clip radio freeze 19.01.27 # Torne: go for it already! :P 19.01.49 # kugel: hey i've yet to have broken anything, i'm trying to maintain a perfect score :) 19.01.59 # kugel: no, perhaps to fs#10605 though 19.02.31 # did the radio on the clip ever work? 19.03.03 # Torne: that's a hopeless goal unfortunately 19.03.06 # sure 19.03.22 # what broke it? mmu patch? 19.03.25 # i identified the lockup in the same location than previously 19.03.30 # which had been fixed somehow by bertrik 19.03.38 # no, something else 19.04.01 # New commit by 03torne (r23740): FS#10798 - unify ata_read_sectors and ata_write_sectors ... 19.04.04 # so, does anyone bother to bisect it? 19.04.06 # there were FM lockups on c200v2 IIRC 19.07.16 # does the Rockboy plugin work? 19.07.29 # they all work 19.08.27 # funman: kugel: thanks. I wish knew something about the Clip... 19.08.29 # but it's not included on the standard distribution 19.08.40 # minus: It is on the players it works on 19.08.53 # What do you have? 19.08.56 # freddyb: Clip has other problems so until they are solved, I wouldn't look at recording on the clip 19.09.23 # New commit by 03torne (r23741): FS#9721 - No error check after writes in ata.c ... 19.09.33 # might as well put that one in too, while i'm messing about with ata writes. :) 19.09.50 # sansa fuze, but didnt see that there's no coloumn for it on the PluginIndex wiki page 19.10.07 # Then I suspect it hasn't been adapted/enabled on the fuze 19.10.16 # the yh* have 8~k of unused iram :/ 19.10.18 # it worked last time i tried 19.10.19 # ~8k 19.10.29 # funman: rockboy? 19.10.47 # minus: How are you trying to run it? You should be clicking on a ROM 19.10.49 # minus: Are you just looking in the plugins menu (where it won't be)? Or have you tried opening a .gb file? 19.10.52 # minus: http://download.rockbox.org/daily/manual/rockbox-sansafuze/rockbox-buildch10.html#x13-22500010.3.9 19.11.56 # Torne: it looks like writing has gotten a lot faster! 19.12.00 # really? 19.12.10 # i mean, it shohld get faster 19.12.11 # reading is still painfully slow 19.12.26 # also the binsize delta is -500 or so on all the hd targets 19.12.29 # * Torne wags! :) 19.12.45 # write is 17MB/s, reading is 5.5MB/s (1MB aligned test) 19.13.19 # i didn't expect multisector PIO to help *that* much but i guess it probably does 19.13.23 Join liar [0] (n=liar@83.175.83.185) 19.14.24 # it seemed silly not to do it when we have the loop to do the multisector reads right there. 19.15.58 # dionoea: start and end in your memmove_wrap() prototype are start & end of ringbuffer ? 19.16.08 # c200v2 has impressively high binsize variations 19.16.21 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 19.16.21 Quit pixelma (Nick collision from services.) 19.16.41 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 19.16.56 # nobody with an ipod other than the video has answered my poll about that startup bug yet :( 19.17.07 # Torne: really? the maximum is 58 19.17.10 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 19.17.10 Quit amiconn (Nick collision from services.) 19.17.15 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 19.17.30 # funman: correct 19.17.30 # funman: i just mean, it varies a lot on seemingly irrelevant commits, when almost all other targets have 0 19.17.52 # funman: end is the first byte outside the ring buffer 19.17.53 Quit Jake ("CGI:IRC (EOF)") 19.18.05 # they could be hardcoded instead of given by arguments 19.18.15 # i'm trying to merge your code in buffering.c 19.18.21 # sure. I just wanted something generic 19.18.34 # gcd() involves division by the way (% operator) 19.18.55 # well if you know any other faster method of computing a gcd I'm all ears :) 19.19.22 # i know one but I use it in my proof of Riemann's hypothesis so I can't publish it 19.19.42 # :) 19.19.44 Quit grndslm (Read error: 60 (Operation timed out)) 19.20.14 *** Saving seen data "./dancer.seen" 19.20.38 # funman: btw, I was wondering why the int of the sd controller is used, instead of the dma callback to indicate finished transfer (samsa sd driver) 19.21.31 # funman: feel free to test the function with your own test code before using it. 2 validations are better than one 19.22.05 # kugel: I think i mentioned it in the log (because the end of transfer used to be notified by the dma callback) 19.22.21 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 19.23.12 # Torne: ok, I take it partly back. writing has gotten faster, but it was already way faster than reading in SVN (11MB/s) 19.23.21 # any idea why reading is so slow? 19.23.24 # no. 19.23.31 # iirc it's like that in test_disk on ipodvideo also 19.23.38 # i've not benched it via any other method 19.23.42 # kugel: r19714 19.24.18 # the log doesn't tell why i made that though 19.24.48 # Remove unneeded blocking API from DMA code 19.25.09 Join grndslm [0] (n=grndslm@174-126-14-4.cpe.cableone.net) 19.25.38 # * kugel goes trying #define ATA_OPTIMIZED_READING 19.25.51 # bertrik: hello, do you remember fixing a lockup in Sansa AMS FM ? (I think it was on a specific model, e200v2 perhaps) 19.26.14 # it was fixed at the devcon IIRC 19.27.26 # funman, yes, it was for e200v2 19.27.41 # I believe the Clip has the same problem 19.27.44 # I think there is still a similar problem for c200v2 19.28.17 # does the FM work sometiems on c200v2? 19.28.21 # the radio on my clip works fine, except for a bug where it won't tune properly to the last used frequency just after startup sometimes 19.28.29 # argh, of course the ATA stats patch massively conflicts with the ata unification i just committed 19.28.34 # i will have to rewrite the stats patch :) 19.28.46 # hm i should probably go home 19.28.47 # ata code is so much faster than sd even for single SECTOR_SIZE transfers :( 19.28.58 # funman, very rarely, it's an initialisation problem that causes a hang in the tune loop 19.29.25 # it doesnt work on mine 19.29.28 # entering the FM screen on my Clip just locks up in si4700_set_frequency 19.29.38 # ata code? 19.30.10 # kugel, funman, I did later make a change for c200v2 that didn't really work, can you revert that? (it's the latest change to si4700.c) 19.30.57 # * kugel gets his glass ball out 19.31.31 # the ams sansas use the 32 kHz oscillator (instead of using an external 32 kHz signal) and use of that is rather poorly described in the data sheets 19.31.55 # svn log is a nice glass ball ;) 19.32.59 # isn't the AMS a ARM processor? 19.33.27 # additionally... the c200v2 also seems to have problems with the current speed of the i2c clock towards the tuner (it needs a little slower bus speed it seems) 19.34.37 # bertrik: have you checked whether playback works better on c200v2 already? 19.35.06 # well playback is still buggy 19.35.23 Join saratoga [0] (i=9803c6dd@gateway/web/freenode/x-rltlqjhhzfqxwudm) 19.35.47 # minus: wiki page SansaAMS has all the details 19.35.54 # yes I checked, some mp3s wouldn't even start playing, oggs seemed to work and I also played m4a's, but skipping m4a's also stopped playback 19.35.56 # k 19.36.18 # on c200v2 it's worse because color lcd eats up more RAM 19.36.30 # how much memory does the c200v2 have for buffering? 19.36.34 # 350KB? 19.37.03 # Can I look that up for you somehow? 19.37.19 # debug menu -> buffering 19.37.35 # Rockbox info says Buffer: 259 KB 19.38.20 # bertrik: can you try last patch on FS#10605 ? 19.38.30 # debug menu -> buffering says pcm 0/176400 and alloc 0 / 48656 19.39.03 # 176400 is 1 second of PCM buffer 19.39.31 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 19.39.37 # funman, the memmove_wrap.diff patch? 19.39.43 # yes 19.40.10 # i'd test on Clip but it crashes less frequently 19.41.01 # just to be clear, should I test that patch on the clip or on the c200v2? 19.41.08 # c200v2 19.48.21 # funman, the first mp3 I tried wouldn't start ... 19.48.49 Join CaptainKwel [0] (i=2669ecc2@gateway/web/freenode/x-vhpnlkvdjpqgbtmm) 19.49.10 # can you mention that on FS please ? + :( 19.49.24 # http://www.daniweb.com/code/post969374.html# apparently has a way to do gcd without div 19.49.46 # kugel: the div comes from % 19.49.55 # i know 19.50.15 # the second function has only add/sub 19.50.45 # sorry, didn't read the second one 19.51.26 # dionoea: ^ 19.52.14 Quit droidcore (Read error: 113 (No route to host)) 19.53.01 Quit Coldarchon ("ChatZilla 0.9.85 [Firefox 3.5.5/20091102152451]") 19.55.05 Join JdGordon| [0] (n=Miranda@nat/microsoft/x-hpnermywythyxddi) 19.56.10 # kugel, funman: I'm not sure that it'd be faster. 19.56.54 # it probably is 19.57.14 # on targets without hardware div (arm) at least 19.57.20 Join torquel [0] (n=4dff77ac@giant.haxx.se) 19.57.27 # it'd depend the ratio between the 2 integers 19.58.10 # arm doesn't have hardware div ? 19.58.20 Join archibald [0] (n=4dff77ac@giant.haxx.se) 19.58.22 # no 19.58.26 # ah ... cool :) 19.58.50 Part LinusN 19.58.51 # I still guess that the first one would be faster. It has like exponential convergence speed while the other one looks more linear 19.59.01 # division is emulated by gcc 19.59.16 Join stripwax [0] (n=Miranda@87.194.34.169) 19.59.23 # why? 19.59.28 Quit stripwax (Client Quit) 19.59.55 # it can't be faster if you need to emulate div (which can only happen by add/sub too, because *1/x doesn't work either) 19.59.57 # 19:58 < dionoea> arm doesn't have hardware div ? 19.59.57 # 19:58 < funman> no 20.00.00 # minus: ^ 20.00.16 # eh 20.00.23 # well the second one basically implements modulo using: mod(a,b) = while (a > b) a -= b; 20.00.33 # I doubt that gcc's % implementation could be slower 20.00.44 # well, benchmark it 20.01.54 # I'd assume that gcc developpers are kind of smart :) 20.02.01 Quit StealthyXIIGer (Read error: 131 (Connection reset by peer)) 20.02.01 # dividing in a loop is even worse ;) 20.02.18 Join StealthyXIIGer [0] (n=stealthy@68.62.19.6) 20.02.19 # they can be smart but can't use the device beyond its capabilities 20.02.19 Quit torquel ("CGI:IRC (Ping timeout)") 20.03.05 # so what you're basically saying is that gcc has a / implementation which is slower than div(a,b) = result = 0; while (a>b) { a -= b; result++; } return result; 20.03.08 Join TheSeven [0] (n=theseven@rockbox/developer/TheSeven) 20.03.09 # if a == LOT*b + BIT then I believe using gcc's div would be faster 20.03.33 Quit Rondom ("leaving") 20.05.59 # http://pastie.org/713208 < gcc 4.0.3 mod function for arm9tdmi not including div0 20.06.16 # all I can say is there is many loops 20.07.29 # dionoea: what values is that gcd called with? total memory addresses? 20.07.29 # http://www.pubbs.net/gcc/200908/10727/ is this anything useful? 20.07.30 # That's the slower (but smaller implementation) 20.07.45 # but it looks like it's for the thumb instructionset 20.08.00 # It's not as slow as one might think when seeing those loops 20.08.17 # kugel: one is the ring buffer size, the other one depends on how much the dst and src buffers overlap 20.08.54 # There is another, unrolled implementation for armv5 and higher. I made an armv4 equivalent which is in the codeclib and is used by libdemac 20.10.17 # And btw, modulo is faster than a full-fledged div 20.11.07 # because you dont need to count 20.11.42 # i wish we could solder some 128MB SDRAM to Clip/c200v2 and mark them stable 20.13.02 # how much ram does it have normally? 2.5Mbit? 20.13.43 # 2MB + 384kB 20.13.44 Quit archibald ("CGI:IRC (EOF)") 20.14.15 # the 384kB are common to all AS3525, some models have an external 2MB (Clipv1, c200v2, m200v4), some 8MB (Fuze, e200v2) 20.14.37 # amiconn: looking at the gcc source div and mod seems to be done in the same function 20.14.57 # 8MB is already pretty much for embedded devices, isn't it? 20.16.20 # there are devices with 64MB 20.16.34 Join webguest22 [0] (n=4dff77ac@giant.haxx.se) 20.16.42 # (ipod video and gigabeat s) 20.16.56 Quit webguest22 (Client Quit) 20.17.29 # i think there 1 2 8 16 and 64 (with rockox code for them) 20.17.29 Join archibald [0] (n=4dff77ac@giant.haxx.se) 20.17.50 # 32 too, I don't know of a 1MB one 20.18.09 # iFP7xx has 1MB iirc 20.18.09 Join Omlet05 [0] (i=omlet05@48.7-65-87.adsl-dyn.isp.belgacom.be) 20.18.13 Quit Omlet05 (Remote closed the connection) 20.18.22 # amiconn: and m200 20.18.28 Join Omlet05 [0] (i=omlet05@48.7-65-87.adsl-dyn.isp.belgacom.be) 20.18.33 # and DAX 20.18.50 # DAX has 2 MB according to tools/configure 20.19.11 # 32 is the most common for Rockbox targets, no? 20.19.28 # HWCODEC are often 1 MB, but hte clip is the smallest target with mostly working SWCODEC 20.19.35 # probably yes, as all of the ipods (besides the 64mb one) have 32mb 20.19.46 # most swcodec target players are 32 20.19.46 # HWCODEC are *all* 2MB 20.19.53 # except the modded players ;-) 20.20.14 # AlexP: true, 25 targets, 14 for 16, 3 for 8, 7 for 64, 5 for 2 20.20.19 # the recorder was moddable, was it? 20.20.24 # i found out the hard way that we build for an 8MB HWCODEC a while back 20.20.24 # Yeah, except that of course 20.20.38 # funman: 7 for 64? 20.20.56 # TheSeven: you forgot mrobe500, creativezvm (30 & 60gb), creative zen vision, and lyreproto1 20.21.01 # bluebrother: All archoses are moddable the same way. The architecture is almost the same, only storage and peripherals differ 20.21.19 # amiconn: ah, ok. Interesting to know :) 20.22.13 # we shouldnt be building for 8mb rec 20.22.36 Quit funman ("free(random());") 20.22.43 Quit Omlet (Read error: 60 (Operation timed out)) 20.22.56 # * bluebrother would really like to see Rockbox autodetecting the RAM size for various targets. Like recorder8mb and ipodvideo64mb 20.23.34 # yeah, that's be funky 20.23.38 # *that'd 20.23.49 # is it that hard actually? 20.23.49 # Detection isn't the problem. The memory layout needs to be changed in order to accomodate the variable end address 20.24.18 # that's a problem or "just" work? 20.24.28 # shouldn't it be rather easy to move the audio buffer towards the end of memory and dynamically detect its size? 20.24.32 # wasnt it discussed in the 07 devcon? 20.24.46 # Right now plugin ram and codec ram are located at the end. Both codecs and plugins are linked to fixed addresses, so they can't go behind the core (which varies in size with build 20.24.50 # ) 20.25.08 # argh, yes 20.25.20 # so put them at the start? 20.25.25 # before the core binary? 20.25.51 # probably impossible for iram (which wouldn't hurt), and it would probably need quite some boot process changes on some devices 20.25.54 # I suggested putting plugin + codec ram in the beginning (or directly behind the vectors if they *have* to reside there), but then the binary will be loaded to a different address and needs to memmove itself 20.26.14 # amiconn: ...or we need the bootloader to do that 20.26.27 # or we use dynamic linking for them :) 20.26.36 # Forget dynamic linking 20.26.54 # TheSeven: There are several reasons why this won't work 20.26.55 # a more fancy rockbox. format that includes things like load address and entry point in the header would also be nice for this 20.27.03 # (1) Old bootloaders 20.27.11 # ...then fix them 20.27.14 # port the linux libc! and malloc! 20.27.17 # * bluebrother hides 20.27.42 # (2) On some targets we're loaded by the OF loader (by default, not even changeable on some of those devices) 20.27.44 # * JdGordon| chases half-heartedly with the pitchforks 20.27.50 # what's the problem with memmoving itself? 20.28.15 # why don't we just boot a bootloader through the of bootloader then that loads the rest to the proper address? 20.28.19 # moving code that's being executed 20.28.27 # kugel: It's not a problem as such, but it's kinda ugly. It takes time, and linker scripts will become even more complex than they already are 20.28.34 # (or just some stub that does the moving magic in front of the main binary) 20.29.10 # huh, interesting, sbs parsing did not fail with wrong parameters in the %Vi (on my Ondio and also in the sim) there are still the colour/shade parameters around in my sbs 20.29.18 # oh god, i have so no clue of processors 20.29.19 # wouldn't this only affect a handful of targets anyways? 20.29.48 # i.e. ipod video and some archoses? 20.29.50 # yeah - video, modded archos 20.30.01 # doing it for the ipod shouldn't be too hard 20.30.07 # h100 comes also as 16MB and 32MB 20.30.08 # how do the archoses boot? 20.30.16 # bluebrother: Is that the only difference? 20.30.19 # h115 vs. h120 / h140 to be exact 20.30.29 # bluebrother: h110 too :) 20.30.47 # * bluebrother facepalms 20.30.50 Join AEnima1577 [0] (n=clbarnob@nc652107a.cns.vt.edu) 20.31.08 # bluebrother: Those have more differences than just the ram size 20.31.18 # microphone IIRC 20.31.23 # Precisely they have opposite s/pdif led polarity 20.31.24 # and we only need that if we can't detect the mem size over usb, right? 20.31.27 # amiconn: releavant differences? 20.31.56 # hmm, ok. Could we detect that? 20.32.04 # bluebrother: Sure, by memory size 20.32.05 # So if you run a h120 build on an h100 or vice versa, the led would be on when it should be off and vice versa 20.32.11 # TheSeven: less builds 20.32.23 # AlexP: d'oh! Of course :) 20.32.31 # so, why do codec and plugins need to be at a static address? 20.33.08 # minus: Simplicity. A dynamic linker would be a lot of extra code 20.33.15 # do they actually really need this, or are most of them position independent anyways? 20.33.34 # probably not as soon as iram is involved though 20.33.41 # They're not position independent 20.34.06 # That doesn't depend on iram 20.34.28 # would a split audio buffer make sense? 20.34.37 # Maybe we could compile them as position independent code. 20.35.06 # position independent code would also open the door for loading multiple plugins at the same time at some point 20.35.09 # That might be a worthwile experiment - I have no idea how much code size would increase by this 20.35.10 # amiconn: I think it's quite likely that most of the code is only using PC-relative addressing for both branches and data access 20.35.27 # You're thinking arm only 20.35.32 # oh yea... 20.35.39 # Rockbox is running on 4 very different CPU architectures 20.35.46 # * JdGordon| guesses less code would be wasted for this, than keeping a pretty animation for the early usb screen :/ 20.36.06 Quit StealthyXIIGer (Read error: 131 (Connection reset by peer)) 20.36.11 # ...with one of them being exactly one target iirc? 20.36.17 # I'd also expect buffer addresses to be absolute 20.36.20 Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) 20.36.22 # no 20.36.56 # All of them cover several targets. SH1 is all old archoses (6 targets not counting mods), Coldfire is irivers and iaudios (5 targets) 20.37.07 # MIPS is the Ondas (3 targets atm iirc) 20.37.13 # The rest is ARM 20.38.55 Quit shai ("Leaving") 20.38.57 # so it's the low-mem targets again that would get the binsize/ramsize hit, which would of course suffer most from it 20.39.38 # so? 20.39.44 # The question is how much the code would enlarge (this would only apply to plugins and codecs, not the core) 20.40.34 Quit Omlet05 (Connection timed out) 20.41.46 # did anyone ever check if we actually need this? 20.42.01 # if we are lucky, we could just assume the bigger ramsize in the linker script 20.42.04 # "this" being? 20.42.12 # No, we can't 20.42.26 # and rely on address bus wrapping to make the codecs/plugins work 20.42.39 # the audiobuffer size would need to be autodetected of course 20.42.45 # at least on s5l870x this would work 20.42.54 # TheSeven: that may work on some systems, but I wouldn't rely on that for all of them 20.42.57 # ow 20.43.10 # we could check it nevertheless 20.43.25 # i actually saw apple doing this themselves on s5l8701 20.43.52 # * amiconn somehow doubts wrapping will work with the dram addressing scheme 20.44.33 # why? i would expect the higher bits to just be ignored by the memory controller or memory itself 20.45.18 # none of the targets that would need autodetection have an MMU, right? 20.45.45 Join n1s [0] (n=n1s@rockbox/developer/n1s) 20.46.05 # yes, but position independent code has advantages beyond that 20.46.27 # so I think it's worth investigating independently of the variable ram size anyway 20.46.42 # amiconn: it would help on numerous targets, so it seems to be worth it 20.47.20 # kugel, JdGordon|: %Vi|0|8|-|-|1|-|-| should fail on mom 20.47.27 # TheSeven: Correct (no mmu) 20.47.34 # err... monochrome but it doesn't 20.47.55 # yes it should :) 20.47.55 # maybe 20.47.57 # I would expect the memory controller to filter out out-of-range addresses on less primitive SoCs than arm 20.48.02 # bertrik: would you be able to test a fixed patch for the clip playback problem ? 20.48.40 # are the archoses really a "less primitive soc"? 20.49.07 # That is the question 20.49.18 # It's probably worth a test 20.49.57 # i would expect all targets to either have an mmu or to allow wrapping 20.50.42 # Still, position independent code would have other advantages as well (like making the dynamic plugin buffer size idea easier) 20.50.55 # does the 2mb/8mb recorder have a different plugin buffer size? 20.51.02 # that would be a major problem... 20.51.35 # no 20.51.47 # 32KB plugin buffer on all archoses 20.52.15 Quit HBK () 20.52.24 # so the only difference is the audio buffer size (and probably also audio buffer descriptor count)? 20.56.31 # There is no such thing 20.56.47 # The hwcodec playback engine is entirely different (still) 20.56.56 # ah yes, hwcodec of course :-/ 20.57.20 # what is the additional memory being used for then? 20.59.32 # pixelma: actually... is there really any reaosn why that shuoold fail... why cant we just ignore the last 2 params? 20.59.51 # TheSeven: All audio buffer 21.00.17 # ok, so you just meant that it doesn't have descriptors? 21.00.39 # I seem to remember it failing for other %V or %Vl (maybe I'm confusing it with grey shades and RGB definitions though 21.00.41 # why does rockboy need such a high framerate and than skips frames? is ist becaus eof the sound (and for less choppy sound tha targets are to weak?) 21.01.37 Join HBK [0] (n=hbk@97.77.51.170) 21.03.16 # JdGordon|: guess that ignoring would also work an be actually simpler (and you get a little more portability) 21.05.12 # by the way, you made .grey and .mono only work for classic_statusbar - shouldn't it work for any name? 21.05.32 Quit Lear ("ChatZilla 0.9.85 [Firefox 3.5.5/20091102152451]") 21.07.14 # it shuold.... but I only put it there (buildzip.pl) because I really dont want to mess with wpsbuild.pl 21.07.31 Join tomers [0] (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) 21.09.58 # kugel: ping 21.11.25 Quit archibald ("CGI:IRC (EOF)") 21.14.48 # tomers: pong 21.16.27 Quit J-23 (Read error: 104 (Connection reset by peer)) 21.19.27 Join J-23 [0] (n=zelazko@unix.net.pl) 21.20.15 *** Saving seen data "./dancer.seen" 21.21.37 # kugel: Hi (sorry for the late response). Do you think I can commit the diacritic patch as it is now? 21.22.13 # yea, go ahead 21.22.29 # thanks. I'll play with the lru later on... 21.22.53 # I'm available by email mostly. RL prevent me from IRCing too much 21.24.23 # kugel: Do you think this feature should be part of the major features list? 21.24.34 Quit Grahack ("Leaving.") 21.25.28 # general diacritics support? I'd think so, yes 21.26.48 # does it affect drawing speed for non-diacritc text (much)? 21.27.06 Quit Thundercloud (Remote closed the connection) 21.27.53 # tomers: you decide that :) 21.28.46 # I think diacritic support affect European languages, Indian, Arabic and Hebrew. It is a major change for users who use these languages 21.30.34 # pixelma: It doesn't affect the speed for non-diacritic text much, since the character ranges are cached, so the lookup for each char is very cheap in average. 21.32.51 Join kugel__ [0] (n=kugel@e178065193.adsl.alicedsl.de) 21.32.57 # hm, isn't there a test_text plugin for this yet? 21.33.03 Quit kugel (Nick collision from services.) 21.33.11 Nick kugel__ is now known as kugel (n=kugel@e178065193.adsl.alicedsl.de) 21.33.24 # maybe test_gfx will be good enough 21.37.34 Join jhggg2 [0] (n=4dfec8ce@giant.haxx.se) 21.37.43 # Unhelpful: aha, so the aliasing patch should probably go in regardless of gcc switching? 21.38.12 Join jh55 [0] (n=4dfec8ce@83.168.254.42) 21.38.36 Quit jhggg2 (Client Quit) 21.38.49 Join matsl [0] (n=matsl@82.182.85.76) 21.41.16 # if test_gfx is correct (and I have no reason to doubt that), on gigabeat f FS#10720 slows down putsxy by about 15% 21.41.46 # New commit by 03tomers (r23742): FS#10720 - Support for displaying diacritic characters ... 21.42.06 Quit freddyb ("Konversation terminated!") 21.42.19 Quit jh55 (Client Quit) 21.43.01 # whether this is actually noticeable is another question 21.47.50 Join Tomis2 [0] (n=Tomis@70.134.101.181) 21.49.11 # Oh, this is a *huge* bin size increase! 21.51.16 # thats not huge! 21.51.18 # someones sense of scale is off :) 21.51.42 # why is it so much bigger on a coupe le of targets? :) 21.51.59 # :-) gevaerts: How to test performance of it? What is test_gfx? Is it aplugin? 21.52.16 # 25kb on zen vision? 21.52.27 # tomers: it's a plugin, yes 21.52.33 # Torne: No idea. Maybe different compilers. Maybe alignment of the buffer? 21.52.51 # ugh 21.53.03 # gevaerts: So it can give me a good measure of how changes to the code affect performance? 21.53.20 # tomers: I'd expect so 21.53.48 Quit Tomis (Connection timed out) 21.53.49 Nick Tomis2 is now known as Tomis (n=Tomis@70.134.101.181) 21.54.20 # tomers: what are diacritic characters and what languages use them? 21.54.37 # And it slows down for everything? 21.54.54 # AlexP: http://en.wikipedia.org/wiki/Diacritic 21.54.57 # It wasn't me that asked that 21.55.14 # AlexP: sorry 21.55.50 # * gevaerts doesn't understand the delta 21.55.54 # n1s: Read the array in firmware/drivers/diacritic.c, you can see what language contains diacritic characters. 21.56.11 # According to bloat-o-meter it should be 2148 bytes for gigabeat f 21.56.45 # Binsize is 21.56.56 # But there's extra ram size increase 21.57.08 Join AaronM [0] (n=Aaron@adsl-4-241-124.mem.bellsouth.net) 21.57.11 # Hover over the delta to see the details 21.58.10 # 15% seems more than "not much" of a performance decrease 21.58.36 # But where is this? On all text? 21.58.48 # wtf happened? 21.58.59 # AlexP: it's a micro-benchmark. That doesn't necessarily mean a 15% slowdown for real text drawing operations 21.59.09 # OK 21.59.40 # it just draws "Rockbox!" a million times or so 21.59.51 # did someone test with a lot of text on an Ipod Video? 22.00.09 # where does that increase come from!? 22.00.23 # kugel: static struct lcd_bitmap_char chars[SCROLL_LINE_SIZE]; is my guess 22.00.54 # ah, that seems like a good guess 22.01.45 # it looks like the initial patch was less demanding 22.01.55 # I've just realized that is_diacritic() is called twice for each character. Once when the string width is calculated by font_getstringsize(), and second when it is being displayed, by putsxyofs(). Could this info somehow be saved between calls? Any ideas? 22.02.05 # looks like about 10K for an LCD width of 240 22.03.00 # We can decide which languages to remove using #if 0 22.03.31 # tomers: can't struct lcd_bitmap_char be made more efficient? 22.04.01 # Notice that in that array, we can use only 3 bytes per entry (Unicode is 0h-0xe01ef, and two more bits for flags). 22.04.22 # tomers: the ranges array is far from the big culprit 22.04.30 # oh wait 22.04.31 # tomers: the struct is already static, so it's saved between lcd_puts* calls 22.05.12 # kugel: But the lookup for each character is still done twice. Doesn't it? 22.05.56 # btw, why (i = 0; i < SCROLL_LINE_SIZE && ucs[i]; i++) instead of (i = 0; i < strlen(str) && ucs[i]; i++) ? 22.06.51 # kugel: you mean calculate strlen(str) every time? 22.07.14 # kugel: ucs[i] will be 0 on string end, so it acts like strlen 22.07.37 # the SCROLL_LINE_SIZE is just for buffer overflow protection 22.08.10 # gevaerts: it loops over SCROLL_LINE_SIZE several times. that seems like a hige waste 22.08.28 # ah, i see, alriht 22.09.24 # the bitmap char could probably be 4 bit using bitfields, instead of 12. 22.09.42 Join Stephen_ [0] (n=S@86-45-81-113-dynamic.b-ras2.srl.dublin.eircom.net) 22.09.54 # unless width and base width are able to exceed 35k (?) 22.11.40 Join Incognito-AWAY [0] (n=PSPdemon@c-66-177-37-36.hsd1.fl.comcast.net) 22.11.50 # why is it that here 22.11.55 # http://www.rockbox.org/wiki/CygwinInstallWithScreenShots 22.12.01 # why is what where? 22.12.15 # i see the "add url" and i added it and click next 22.12.21 # Incognito-AWAY: To show people how to install cygwin 22.12.22 # can themes from the gallery with the ccbysa license be edited and moved to the themes site ? 22.12.30 # but it says it cannot get the setup.ini" 22.13.04 # Stephen_: sure, as that is the licence the theme site uses it should be fine :) 22.13.10 # more or less... "Unable to get setupini from " 22.13.22 # err setup.ini* 22.13.26 # thanks again AlexP, just have to stay away from the graveyard right. 22.13.55 # Incognito-AWAY, you have to pass a switch using cygwin, to bypass that. 22.14.03 # Stephen_: You can check the graveyard, but I'm pretty sure that everything that is in there has already been checked and isn't permissivly licensed 22.14.04 # can't off the top of my head remember which. 22.14.14 # :/ 22.14.23 # Stephen_, Incognito-AWAY: -x 22.14.27 # did that 22.14.36 # yeah went through it myself as i know soap did too. 22.14.40 # as it said at the top 22.14.41 Join stripwax [0] (n=Miranda@87.194.34.169) 22.14.52 # ive updated some from the gallery just wasn't sure of the gallery 22.14.55 Quit bertrik ("De groeten") 22.15.03 # tomers: is there a reason the struct lcd_bitmap_char chars is static? 22.15.07 # kugel: Could you explain how the bitmap char could be 4 bit using bitfields, instead of 12 22.15.24 # bluebrother: you don't want that on the stack 22.15.29 # first, i meant byte :) 22.16.03 Quit stripwax (Client Quit) 22.16.04 # well, you need 1 bit each for the bools. then you have 30 bits left for width and base width 22.16.17 # kugel: I said that ten minutes ago. We can use 3-byte for each entry. 22.16.41 # tomers: are you sure we will *never* need more than 256 pixels width? 22.16.54 # gevaerts: hmm. Right. 22.17.36 # gevaerts: I think that's reasonable to assume ;) 22.17.49 Join petur [50] (n=petur@rockbox/developer/petur) 22.17.51 # kugel: really? 22.17.56 # yea 22.18.17 # gevaerts: I think I took this limit from other function that handles with text. (bidi?) 22.18.18 # 256pixels is per glypth or total? 22.18.26 # glyph 22.18.28 # New commit by 03gevaerts (r23743): make lcd_bitmap_char more space efficient. This doesn't seem to impact text drawing performance 22.18.41 # * gevaerts goes for smallish gains first 22.19.05 # if 128 is enough it could even be 2 bytes 22.19.49 # gevaerts: Notice bidi_l2v() in putsxyofs(). 22.19.49 # Stephen, i type setup.exe -X it brings up the box and everything 22.19.49 # kugel: some people have really bad eyes and use fonts that basically fit only one word on a screen. We have a 640x480 screen, so I'd say that 128 is *definitely* too small 22.19.55 # but it still gets me to the "Unable to get setup.ini from 22.20.08 # gevaerts: the max font we have is 40px I believe 22.20.19 # the max fond *we* have, yes 22.20.25 # and that's a really huge one even for 640x480 22.20.54 # nvm there we go 22.21.02 # kugel: yes, but you have good eyes 22.21.11 # gevaerts: sorry, ou're crazy... 128pixel width means about 4 chars on the screen even at 640x480... 22.21.56 # on 3 lines! 22.22.07 # JdGordon|: for the absolute widest character of the font 22.22.44 # I think 40 is a reasonable max.. even 64 to make it a round number 22.22.59 # yellow! red! 22.23.13 # tomers: I'm not sure what I'm looking at there 22.23.52 # ? 22.23.58 # * gevaerts did test compile. Why didn't he see that :\ 22.24.09 # tomers: "Notice bidi_l2v() in putsxyofs()" 22.24.30 # gevaerts: you call that a smallish gain? What have we to expect for the next changes? ;-) 22.24.55 # * gevaerts clearly did something wrong 22.25.40 # gevaerts: the bidi function has static buffers of a constant size. I guess it won't work for bigger strings? (actually I haven't read it at all - so maybe it does something smart with it) I used the same size. 22.27.00 # tomers: I never questioned that one. I said pixels, not characters :) 22.27.37 # oh... Actually I overlooked this consideration, so feel free to change 22.27.57 # gevaerts: BTW nice catch 22.28.16 Nick Horschti is now known as Horscht (n=Horscht2@xbmc/user/horscht) 22.28.59 # ok, if everyone feels 255 pixels is really enough... 22.29.15 Join LambdaCalculus37 [0] (n=LambdaCa@rockbox/staff/LambdaCalculus37) 22.29.34 # gevaerts: why the bool->char change, isn't a bool, just a char in disguise anyway? 22.29.52 # n1s: not necessarily 22.29.56 # * kugel is convinced 127 is enough too, but saving another byte (when each struct is already 3 bytes) doesn't make a huge difference 22.30.20 # A bool may be a char or an int, depending on architecture and optimisation level 22.30.27 # n1s: bool doesn't have a defined size. it can typedef'd to anything 22.30.37 # amiconn: ah, fun 22.30.51 # Similar fun as enums 22.31.03 # well, it's defined to be "sufficiently large to hold the values 0 and 1", but that's rather useless 22.32.19 Quit StealthyXIIGer (Read error: 110 (Connection timed out)) 22.32.25 # if only there was a proper 24bit type 22.33.32 # __attribute__((packed)) may give some savings too 22.34.27 # New commit by 03gevaerts (r23744): Limit character width to 255 pixels ... 22.34.55 # speed is still the same on gigabeat at least 22.35.11 # that two bool values can get combined as a bitmask or bitfield. 22.35.21 # no bitmap yet. Not awake enough for that :) 22.36.39 Quit evilnick (Ping timeout: 180 seconds) 22.37.00 # kugel: I actually would object to the 127 option on the grounds that adding a flag to each width value makes the code unreadable 22.37.37 # not the flag, but the sign. that should make it a bit better readable :) 22.38.18 # but I agree in general. I already said it's not so much worth it anyway (it would probably also add code complexity) 22.38.42 # gevaerts: still some yellow, and now some red too. 22.39.04 # The diacritics support code looks broken 22.39.04 # damn, committed too many files :\ 22.39.15 # hmm, in test_gfx ... 22.39.51 Join einhirn [0] (n=Miranda@p5DCC16BA.dip0.t-ipconnect.de) 22.39.58 # It will produce completely wrong results if the original drawmode is DRMODE_COMPLEMENT 22.39.58 Join mrtok1 [0] (n=dummy@p5B39C5E0.dip.t-dialin.net) 22.40.02 Join n00b81 [0] (n=n00b81@unaffiliated/n00b81) 22.41.17 # what's with the "Failed regex: line above the download table" (not the build table)? 22.41.25 # tomers ^^ 22.41.52 # hmm... the second " should be a few words earlier 22.42.15 # amiconn: I am sorry, bu t I don't understand what '^^' means :-) 22.42.28 # Reference two lines above 22.43.04 # New commit by 03gevaerts (r23745): revert accidental commit 22.43.40 Part n00b81 ("Leaving") 22.43.51 # * gevaerts hopes for all-green again and will leave further discussion to others 22.44.21 # Q: Does someone know if profiling with gprof is working on the targets ? Or how could I manage to measure code performance? 22.44.38 # amiconn: This is something I left from the original work done in the patch. I don't understand much vp flags which relate to draw modes... Can you manage to fix this yourself? 22.44.54 Quit bimbel ("Bye!") 22.45.09 # tomers: Afaics it is completely unfixable in current form 22.45.51 # You need to pre-render the current character with all its diacritics at least (in mono) and then finally draw that 22.46.48 # will avi files work on rockbox .. or only mpeg 22.46.54 # mpeg 1/2 22.47.06 # See www.rockbox.org/wiki/PluginMpegplayer 22.47.12 # mrtok1: profiling should work with the profiling functionality built into rockbox (see wiki or docs/TECH for an intro 22.47.42 # TaZzZ: Also, avi is a container that can contain many different codecs 22.47.58 # xvid ... is the file 22.48.01 # you cna also devise your own benchmarks of course, may or may not give usefull info of course 22.48.18 # TaZzZ: Anyway, my previous answer stands 22.49.28 # Hmm, actually it looks fixable, the inner loop needs to be done quitedifferently though 22.49.39 # amiconn: Should I open FS bug for that? 22.50.12 # I actually don't know how to fix it myself (unless I'll dive into that code, which takes time) 22.50.13 # And we'll need an extra buffer that can hold one char's bitmap 22.50.51 # n1s: ohh - thank you - do you have a pointer? okay - found http://www.rockbox.org/wiki/SourceProfiling will try that - thx! One other question: Do you know a _free_ tool to calculate mips of code sections ? 22.51.01 # Basically you can't just change the draw mode to something else irrespective of the original mode and expect the result to look as intended 22.51.51 # I mean: function x tooks 2 seconds with 80MHz core clock for example :o) 22.52.33 # And with DRMODE_COMPLEMENT (which means XORing pixels), overdrawing this way will cause odd results if the diacritics and the base char both have common pixels set 22.52.33 # There will be a hole 22.53.07 # mrtok1: yeah, that is the wiki page i meant, don't know of any such tool but doesn't sound too hard to calculate if you know the clock frequency and cycles spent in the function 22.53.16 # So you need to combine the char and its diacritics in a temp buffer using OR, and then draw the final bitmap instead of the chars, without touching the drawmode 22.54.39 Quit n1s ("Lämnar") 22.54.50 # n1s: hope that the profile.out will give me this informations... - thx + bye 22.55.05 Nick Topy is now known as Topy44 (n=Topy44@f048059001.adsl.alicedsl.de) 22.55.20 Quit mrtok1 () 22.57.50 Quit dmb (Read error: 104 (Connection reset by peer)) 22.59.19 Quit Horscht ("Verlassend") 22.59.22 # actually, I don't really see why it loops three times from 0 to len. Isn't it possible to combine those, and eliminate the huge chars[] in one go, since you'd only need to store one "real" character's worth of chars anymore (i.e. 5 or so. How many diacritics can be used in a row realistically?)? 23.02.32 Quit fyrestorm (Read error: 104 (Connection reset by peer)) 23.03.31 # gevaerts: I'll fix that, but not today (got to go). 23.03.40 # amiconn: Fixing this will take some more time... 23.04.25 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 23.04.39 # tomers: sure. It works now (except for the problem amiconn pointed out), saving RAM is good, but not don't-go-to-sleep critical 23.04.44 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 23.05.01 # gevaerts: :-) leaving now 23.05.09 Quit tomers ("ChatZilla 0.9.85 [Firefox 3.5.5/20091109125225]") 23.06.33 Join evilnick [0] (i=4571af51@rockbox/staff/evilnick) 23.08.55 # Is there some test text for this? 23.09.47 Quit einhirn (Read error: 104 (Connection reset by peer)) 23.10.11 Join n00b81 [0] (n=n00b81@unaffiliated/n00b81) 23.10.11 Join Strife89 [0] (n=michael@adsl-146-208-69.mcn.bellsouth.net) 23.10.25 # another svn commit? 23.10.33 # cause....it stopped....again 23.10.38 # gevaerts: are you saying ram waste is not worth overtime? :) 23.11.06 # kugel: only the day before a release :) 23.11.14 Join polobricolo [0] (n=polobric@AGrenoble-257-1-21-117.w86-194.abo.wanadoo.fr) 23.11.14 Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) 23.11.43 # amiconn: I believe that http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt has some combining characters in it 23.15.01 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 23.17.09 Quit LambdaCalculus37 ("Leaving") 23.18.47 Join fyrestorm [0] (n=nnscript@cpe-69-203-150-85.si.res.rr.com) 23.20.17 *** Saving seen data "./dancer.seen" 23.21.33 # is there an example sbs for the iPod video? 23.22.10 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 23.26.06 # can we stop people from uploading custom filetype colors with their themes? 23.26.07 Join efyx_ [0] (n=efyx@lap34-1-82-225-185-146.fbx.proxad.net) 23.27.19 # why? 23.27.26 # Aren't they part of a theme? 23.27.26 # it's a theme setting, I thought? 23.27.49 # I'd expect custom filetype colours to qualify as a part of a "theme" 23.28.00 Quit polobricolo (Remote closed the connection) 23.28.03 Part n00b81 ("Leaving") 23.29.09 # how do you clear that setting ? 23.29.58 # * bluebrother thinks that alternating row colors in lists would be a nice feature 23.30.28 # background color that is 23.30.32 Quit matsl (Read error: 145 (Connection timed out)) 23.30.36 # not text colour? :) 23.30.50 # no, text color is boring ;-) 23.30.59 # I don't see filetype colours as a part of a theme, but rather a usability improvment or accesibility feature 23.31.19 # I see it very much as a theme thing 23.31.46 # it uses colors, it must be part of a theme! 23.31.50 # Filetype colours is a theme thing that may be used as a usability improvement or accessibility feature, much like fonts are. 23.31.54 # or colours, if you like 23.31.56 # kugel: don't be silly 23.32.16 # n1s: i think so, and the bulk of codecs (for files in the test set) perform better under strict aliasing with -O3, also 23.32.29 # kugel: It primarily affects the visual or aesthetic appearance of the user interface without changing functionality - very much a theme value. 23.32.42 # well, filetype colors is somewhat similar to filetype icons. So ... 23.32.46 # anyone having problems with recording on e200v2 ? 23.33.13 Quit AEnima1577 ("Leaving.") 23.33.15 # so, how I can I clear that easily? Only per deleting the file? 23.33.24 # That is a different issue 23.33.28 Quit stripwax (Success) 23.33.36 # for 4.0.3 with -fstrict-aliasing -O3 is faster for ape, aac, flac, mpc, vorbis, and wma (on arm11) 23.33.44 # Doesn't it require a .cfg to *set* filetype colors? 23.33.49 # yes 23.33.59 # i would *expect* the arm9 targets to perform similarly, they did with -fstrict-aliasing 23.34.00 # So it seems perfectly reasonable it also requires one to clear it. 23.34.11 # without rather 23.34.13 # but if a theme sets it, it isn't easy to clear them but keep the rest of the theme 23.34.35 # or clearing that lin in your config.cfg 23.34.56 # But the lack of an easy way to clear filetype colours means that the lack of easy way to clear them should be fixed, not that we should stop people using the colours 23.34.57 # line too 23.34.58 # * kugel can't complain 23.35.05 Part CaptainKwel 23.35.11 # the UI vp works the same way (apparently) :) 23.36.01 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 23.36.32 # AlexP: That the very least the default theme should include clearing filetype colors. That would be the first obvious fix whether or not we're going to have a "Reset filetype colours" setting. 23.36.48 # yep 23.37.09 # it could be a reset_ft_colors.cfg in the theme dir if it's handled by a confi.cfg line 23.38.10 # kugel: That'd be a quick fix, but an actual menu entry would be nice. 23.38.32 # wait, did you just say that? :p 23.38.43 # I'm pretty sure just having a blank entry instead of a .colours filename is all it takes to reset it. 23.39.05 # Llorean: why a menu entry? You can't set it via a menu either. 23.39.21 # custom statusbar brought up some awesome themes already imo 23.39.31 # bluebrother: If you pick a theme and then don't like the font, you can change the font. If you pick a theme and don't like the filetype colors it brings with it, you can't reset them to default without never using that theme until you text-edit the file 23.39.50 # It'd be nice if you could pick a theme, then after choosing it, turn parts of it off and then "save theme settings" 23.39.58 # loading a theme could also implicitly reset the colors if they are not set by the theme 23.39.58 # So even if you can't turn filetype colors on by hand, turning them off by hand seems necessary 23.40.00 Quit petur ("Zzzzz") 23.40.11 # maybe a special dir for various reset_* files, then a menu entry for browing that dir 23.40.18 # well, most themes are pretty much bound to the font used. 23.40.33 Quit FlynDice (Remote closed the connection) 23.40.37 # Font size, but not necessarily font 23.40.48 # And viewports adds a great deal of flexibility in terms of choosing smaller fonts at least 23.41.01 # so for various settings it's questionable if it's a good idea to allow changing things separately. 23.41.24 # of course it's convenient to quickly change e.g. the font :) 23.41.37 # Well, filetype colors should be changeable separately if we allow them to change other color values (background color, foreground color, line highlight, backdrop image) 23.41.40 # Since they can conflict very easily 23.43.24 # we need to add the filetype color settings to THEME_SETTINGs in the code then, so that it creates the clearing entry when you select "Save theme Settings" 23.44.10 # Sounds like a good idea. 23.45.31 Join FlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 23.45.33 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 23.45.38 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 23.46.29 # "MediaFlo for E200v2" would probably look extremely awesome with anti-aliased fonts (hint hint Unhelpful ) 23.47.31 # why do targets without rsbs get that in the zip? 23.48.05 # and it still works differently than RWPSs (which is a nice way IMO) 23.48.40 # or at least it looks like it works differently seeing the result 23.48.55 # kugel, you have a e200v2 right 23.48.58 # no 23.49.31 # ah, recording i think has a bug but i want to check before posting to fs 23.49.38 # arg, people apparently don't use the "save theme settings" feature 23.49.59 # most themes don't reset the ui vp 23.50.18 # kugel: Maybe we could make the "save theme settings" feature export an additional line, and only accept themes with that line? 23.50.29 # kugel: Maybe most themes are from before that? 23.50.41 # I suspect most people who don't use about it simply don't know about it, so when their theme is rejected the site can simply say "Please use Save Theme Settings to export your theme, and upload that .cfg file" 23.50.47 # i wonder if you could possibly run gba roms on the fuze 23.50.47 # ui vp is older than the theme page IIRC 23.50.48 # AlexP: That feature predates the site, I think. 23.51.05 # Er, sorry 23.51.10 # Save theme settings, I mean. 23.51.11 # * Llorean doesn't know about the viewport 23.51.13 # ui vp? 23.51.39 # Llorean: I meant the ui vp 23.51.59 # Llorean: that sounds like a good idea 23.52.03 # AlexP: Yeah, I realized that after I said it. 23.52.11 # "MediaFlo"? 23.52.33 # yea 23.52.42 # go work on AAF, that theme badly needs it ) 23.52.47 # :)* 23.53.01 # kugel: It won't be perfect since people can still add the line by hand, but I think it'll improve things a lot just because people will become aware of the menu setting. Maybe even reject themes that don't include every exported estting explicitly, though I don't know how easy that would be. 23.53.33 # Llorean: maybe just check for the presence of certain line like backdrop, ui vp, foreground and background colour. No need to add something to the Rockbox binary IMO 23.53.42 # well, adding the line by hand could interpreted as "I intentionally leave some settings out" 23.53.49 # That is quite a good idea - it'll force reset settings that the theme authors don't know about/have forgotten about 23.54.32 # pixelma: That could work. Require lines that are necessary to reset things. 23.54.40 # or maybe for "all lines that have to be there if the creator used 'save theme settings'" 23.54.47 # If you wish to add something that would be reset later, load the theme, then load the other things. 23.55.49 Quit Strife89 (Read error: 110 (Connection timed out)) 23.57.36 # * kugel would favor the generated line 23.57.56 # adding it by hand can really mean "I leave the icon set out, my theme works with any"