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

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

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

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

#rockbox log for 2009-11-24

00:00:30amiconnOnly then I noticed the new vieport clipping. Why is this necessary? It is only enabled for mr500 atm
00:01:08amiconnYou also went back to the old, less efficient bounds checking in lcd_bitmap_transparent_part when adding this. Why?
00:02:57kkurbjunWamiconn: 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:13kkurbjunWI can't comment on the less efficient method, if I did that it was by accident
00:03:37 Part drf|laptop
00:03:37amiconnHow is clipping broken by viewports?
00:04:27 Part CaptainKwel
00:05:27amiconnAfair viewports are required to stay inside the display area.
00:05:37amiconnIf 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:57JonHi
00:07:13 Quit AEnima1577 ("Leaving.")
00:07:36JonHey
00:07:43JonI have a question.
00:08:21 Quit matsl (Read error: 145 (Connection timed out))
00:08:22JonI 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:45JonI can just give an admin a shell and IP address to use.
00:08:51JonFree
00:08:51*Hillshum thinks we've been happy with Freenode
00:08:55Jonk
00:09:12JonI'm trying to find uses for my servers though lol
00:09:24LambdaCalculus37Jon: You can provide a build server.
00:09:29*Hillshum lost
00:09:35JonFor what kind of use?
00:09:39pixelmaor a download mirrir
00:09:46JonI can do a mirror
00:09:48pixelmamirror too
00:09:50LambdaCalculus37Jon: For building builds, of course. :)
00:09:54Jon=P
00:10:00CIA-80New commit by 03pamaury (r23728): Add myself to COMMITERS.
00:10:02Jonwhat would it need?
00:10:09LambdaCalculus37Jon: There's some info in the wiki.
00:10:11JonOk
00:10:36LambdaCalculus37http://www.rockbox.org/wiki/BuildServer
00:10:45LambdaCalculus37No wait...
00:10:45LambdaCalculus37http://www.rockbox.org/wiki/BuildClient
00:10:54gevaertspamaury: welcome!
00:10:55LambdaCalculus37Jon: BuildClient, not BuildServer.
00:11:05Jonok
00:11:19pamaurygevaerts: thanks !
00:11:21gevaertspamaury: one thing though, that file is expected to be in alphabetical order :)
00:11:44JonYeah, I can provide that
00:11:51pamaurygevaerts: I'll modify that ;) I missed this point :)
00:11:52JonDo I get anything in return for donating?
00:12:01Jon=P
00:12:47JonHmm I don't usually setup stuff other than IRC-related things in ssh
00:13:00JonI 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:32JonHow do I get a rockbox repo in the directory?
00:13:32HillshumIt's not that hard
00:13:39Jonjust download the svn?
00:13:44Hillshumsvn
00:13:46JonOk
00:13:49JonWhat link?
00:13:54 Join nickwb [0] (n=nickwb@ppp118-208-168-84.lns20.bne4.internode.on.net)
00:13:55HillshumInstall subversion (svn), then repo it
00:14:11Jonk
00:14:14 Join Rockbox [0] (n=alexthec@CPE-72-135-229-158.wi.res.rr.com)
00:14:30LambdaCalculus37Jon: You get tons of free beer and your name in the credits. :)
00:14:42JonxD
00:14:46JonCool
00:14:47gevaertsLambdaCalculus37: do we put build client people in credits now?
00:15:00LambdaCalculus37gevaerts: I dunno.
00:15:11CIA-80New commit by 03pamaury (r23729): Move myself in alphabetical order in COMMITERS.
00:15:12 Part nickwb ("Cya")
00:15:36JonWhat packages need to be installed via yum for this to work?
00:15:47RockboxHey I went to the Linux4nano Channel and No one was avalible soooo...Can i ask a quick question?
00:16:08HillshumRockbox: If related to rockbox...
00:16:33RockboxYeah.
00:16:47RockboxWhat Drivers are missing for the 2G nano?
00:16:58LambdaCalculus37Rockbox: USB.
00:16:58JonWhats the command to get the repo copied (Sorry I never use svn for anything)
00:17:15gevaertsLambdaCalculus37: USB is there...
00:17:26 Quit pamaury ("exit(*(int *)0 / 0);")
00:17:36LambdaCalculus37gevaerts: I thought it was still booting into disk mode.
00:17:45HillshumJon: 'svn co svn://svn.rockbox.org/rockbox/trunk /path/to/repo/on/local/disk
00:17:46gevaertsah, maybe. Not sure.
00:17:51Jonok
00:17:52RockboxNo.
00:17:55gevaertsRockbox: it mostly needs to be debugged
00:17:56kkurbjunWamiconn: the viewport offsets are added after the clipping takes place against the viewport definition
00:18:03RockboxThe USB is off.
00:18:06JonCan I make up the /path/to/repo/on/local/disc/ par?
00:18:08Jon*part
00:18:15JonJust make a dir for it?
00:18:19HillshumYeah
00:18:21Jonok
00:18:22RockboxYour computer doesnt detect the Ipod correctly.
00:18:27kkurbjunWamiconn, 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:33JonVia root or a user?
00:18:48Rockboxroot.
00:18:52Jonk
00:19:00gevaertsJon: never root
00:19:08RockboxDo you guys need dev help on that at all?
00:19:15Jonok
00:19:22gevaertsRockbox: if you don't know what you're talking about, please don't reply...
00:19:22RockboxIf you need help im up for it.
00:19:57amiconnkkurbjunW: Hence my suggestion to clip the viewport on setup. Smaller and faster...
00:20:11amiconnAnd it's messed up anyway
00:20:12JonHmm
00:20:17Jonroot@s4 [~]# adduser rockbox
00:20:17Jonadduser: cannot lock shadow password file
00:20:19kkurbjunWamiconn, if we shouldn't do clipping at the viewport why are we doing clipping at all?
00:20:21JonD=
00:20:37RockboxSo 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:57RockboxIm not totally in knowledge of everything rockbox.
00:21:26kkurbjunWhow is it messed up?
00:21:31RockboxIve been folowing Linux4nano-dev since it went up.
00:21:35Rockboxumm....
00:21:40RockboxHard to explain.
00:22:02RockboxSomething with the USB drivers and the computers.
00:22:33RockboxIts like the files will get detected and sometimes they wont.
00:22:38gevaertsRockbox: talk to TheSeven for nanog2 things, or possibly linuxstb
00:22:53kkurbjunWamiconn, to clarify I'm asking why we even clip images in the driver
00:23:27RockboxOkay.
00:23:28kkurbjunWI 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:43HillshumRockbox: You don't run need to run svn as root, so yes
00:24:03amiconnkkurbjunW: Elements are allowed to be positioned (partially) outside the viewport, hence we need clipping
00:24:27amiconnViewports in turn are not allowed to be positioned (partially) outside the screen
00:24:41kkurbjunWwith 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:19amiconnBack 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:26kkurbjunWamiconn, there is no method to check/define viewprorts we just write direct to the structure
00:25:57kkurbjunWagreed, it makes the callers complex
00:26:04 Quit liar (Read error: 113 (No route to host))
00:26:13amiconnlcd_set_viewport()
00:27:03kkurbjunWI 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:20linuxstbkkurbjunW: 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:45kkurbjunWlinuxstb: but it gets messed up in other places, the usb screen is an example of that
00:27:57linuxstbHow so?
00:28:14linuxstbThat sounds simply like a bug in the usb screen.
00:28:26JdGordon|kkurbjunW: (no offense) the usb screen is a bad example... it needs to be fixed seperatly
00:28:41JdGordon|lua shuold call a viewport setter wrapper to maake sure the values are legal
00:29:01kkurbjunWI 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:24linuxstbkkurbjunW: But it's not "checking" as such, it's just calculating correct values to use.
00:29:54kkurbjunWand 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:11amiconnlcd_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:33amiconnBut doing it in the drawing functions means much more binsize than doing it in the single setup function
00:30:56CIA-80New 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:58linuxstbkkurbjunW: 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:01kkurbjunWamiconn: if you clip it there the screen won't render properly, but it will at least prevent memory corruption
00:31:11amiconnyep
00:31:54kkurbjunWif you did a check there I would be fine with that, I just don't like the idea of memory corruption
00:32:01amiconnI 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:32kkurbjunWI 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:43JdGordon|boomshine is too easy :(
00:34:28 Part Rockbox
00:37:12 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey)
00:37:17kkurbjunWamiconn, 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:51kkurbjunW(I even emasured the current and it was too small for me to measure) :)
00:38:07kkurbjunWmeasured that is
00:41:27linuxstbkkurbjunW: 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:52Jon[Newnick]NOW THEY WILL NEVER FIND ME
00:44:48 Quit Hillshum (Remote closed the connection)
00:44:51kkurbjunWlinuxstb: 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:00Mode"#rockbox +o JdGordon| " by ChanServ (ChanServ@services.)
00:45:05kkurbjunWand I wanted to prevent memory corruption
00:45:37Mode"#rockbox -o JdGordon| " by ChanServ (ChanServ@services.)
00:46:04kkurbjunWand it made the screen render as (potentially) desired even though currently the expectation is that viewports are withing the screen.
00:46:22linuxstbAdding 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:43kkurbjunWlinuxstb, I think clippins or bounds checking is better than a panicf in general too by the way
00:48:17linuxstbBut that means bugs in apps/ code will go unnoticed.
00:48:29kkurbjunWI 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:38kkurbjunWso that when you run it gives a warning
00:48:54 Join liar [0] (n=liar@83.175.83.185)
00:49:12kkurbjunWor a printf or a debugf or whatever you prefer, but I don't think a panic is necessary
00:50:22linuxstbBut 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:59kkurbjunWHD parking is not very pleasant for a potential innocent mistake
00:51:25linuxstbBut 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:25kkurbjunWit 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:50kkurbjunWso 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:17kkurbjunWdoing a debug message in the simulator seems reasonable without causing a panic on the target
00:53:20linuxstbThen that person will quickly get yelled at.
00:53:46JdGordon|if they dont own the target.. how cna they get yelled at?
00:53:52kkurbjunWthere are only 3 devs that I am aware of that have an mr500 to my knowledge so quick is a relative term
00:54:05linuxstbJdGordon|: For writing buggy code...
00:54:15JdGordon|its not buggy... its broken on that target
00:54:17JdGordon|big difference
00:54:38linuxstbHuh?
00:56:06kkurbjunWlinuxstb, 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:25kkurbjunWand I would not want to see a panic on the target
00:56:48linuxstbWhat's special about the mr500/100 remote that means this particular bug is only there?
00:57:02amiconnlinuxstb: The remote is 79x16 ...
00:57:06kkurbjunWthe usb logo is large and the screen is small
00:57:35*linuxstb still doesn't understand...
00:57:40linuxstbSo the logo is larger than the LCD?
00:58:02kkurbjunWthe logic wouldn't work on that screen at all with the statusbar enabled
00:58:30kkurbjunWyou would end up with viewports that are outside of the screen space even if the logo was 1 pixel high
00:59:04kkurbjunW(and you had a 8 point font defined)
00:59:12kkurbjunWwhich is unlikely on the mr500
00:59:15amiconnImo the statusbar in its current form is essentially useless on the mrobe remote
00:59:45amiconnAnd with current form I mean anything that its only separated horizontally
00:59:58kkurbjunWeven without the statusbar you would likely end up with viewports that are outside of the screen depending on the ui font
01:00
01:00:20 Join cendres [0] (i=ashes@modemcable076.241-176-173.mc.videotron.ca)
01:00:20cendreshello
01:00:27kkurbjunWI agree though, the statusbar is pretty pointless on the mrobe remote
01:00:39cendresi have an iriver h300. when creating a vfat filesystem, is it best to use a 32 bit FAT size?
01:01:41amiconnI agree with kkurbjunW that crashing on unusual parameter combinations is bad. I said that myself several times, regarding metadata reading in codecs
01:01:54amiconnBut 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:17linuxstbamiconn: 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:39amiconnThe 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:12amiconnAnd enabling all the extra code isn't nice on lowmem targets
01:04:18pixelmaamiconn: 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:43amiconnDoes that actually work? I mean, you can define one that way, but will the lists use it properly?
01:06:24amiconnlinuxstb: 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:24JdGordon|it would be pretty silly if the lists didnt work like that
01:07:26pixelmaJdGordon|: 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:58pixelmaread: the correct frequency is displayed
01:08:11JdGordon|so thats good?
01:08:22pixelmano
01:08:24JdGordon|IMO it *should* display 44.100 if thats what it is
01:09:04JdGordon|the built in bar is not an orcale for this
01:09:12pixelmabut it's 45x5096... where x can't be read because the channels icon is displayed over it
01:09:32JdGordon|ok, thats fubar :)
01:10:01JdGordon|but, it shuold be used as a conditional to have it show 44 or 22 or whatever
01:10:09pixelmayeah
01:11:39pixelmaI 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:06pixelmathe icons show smaller numbers and a k there
01:12:18Jon[Newnick]Back
01:12:23Jon[Newnick]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:30Jon[Newnick]rockbox@s4 [~]# svn co svn://svn.rockbox.org/rockbox/trunk /home/rockbox/svn/repo
01:12:30Jon[Newnick]-bash: svn: command not found
01:12:30Jon[Newnick]rockbox@s4 [~]#
01:13:12Jon[Newnick]Do I need a certain package or something?
01:13:16amiconnJdGordon|: 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:54pixelmaJdGordon|: 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:40pixelmabut are smaller and harder to distinguish and one additional bitmap (although *only* one)
01:14:49Unhelpfuli 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:32pixelmaJon[Newnick]: looks like you are missing subversion then
01:15:56Jon[Newnick]How do I install it?
01:16:03JdGordon|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:18UnhelpfulJon[Newnick]: depends on which distribution you use
01:16:30Jon[Newnick]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:20Jon[Newnick]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:39stripwaxUnhelpful - (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:07Unhelpfulstripwax: 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:08Unhelpfuland 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:10stripwaxUnhelpful - are you profiling along the way also? that would be cool
01:23:13amiconnJdGordon: 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:29Unhelpfulsimilarly, on top of that you could build a generic for extracting canonical-huffman-coded data from the top of the bitstream
01:25:23JonUgh I friggin hate my server
01:25:23stripwaxUnhelpful - 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:31JonI'm gonna just install this to a vserver
01:26:18stripwaxHm - is it expected that pictureflow keeps the disk spinning down, spinning up, spinning down, .. constantly?
01:26:40Unhelpfulstripwax: bit-string fetching etc could still be inlined... ie, #include <generic_bitstream.h>
01:27:03stripwaxThat's on latest build (not sure if behaviour changed at all recently tho)
01:27:08amiconnpictureflow has to spin up the disk if it has to fetch uncached tiles
01:27:11stripwaxUnhelpful - true
01:27:29stripwaxamiconn - should it do that if I'm not scrolling the tiles?
01:27:42amiconnProbalby not
01:27:45Unhelpfulstripwax: 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:53stripwaxMm-hmmm..
01:28:12stripwaxUnhelpful - it's doing it without slide changes, I'm just looking at it
01:28:14Unhelpfulif you have just stopped scrolling and the cache is not full, it will keep loading
01:28:45stripwaxUnhelpful - loading's fine - but rather it was constantly spinning up, down, up, down, the disk ..
01:28:45Unhelpfulif it's just sitting there loading slides over and over, congratulations, you've found a bug in my buggy cache code :)
01:29:27stripwax:)
01:29:29 Quit Hillshum (Remote closed the connection)
01:29:47stripwaxI 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:35Unhelpfulwhat 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:53JonIs there anything I can help with other than hosting?
01:32:02Jon*other than svn repo
01:32:08JonI can provide hosting or something
01:32:15JonFor a mirror, idk
01:33:21stripwaxUnhelpful - 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:27stripwaxUnhelpful - 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:58pixelmaJdGordon: 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:18pixelmathe current time that is ;)
01:39:38pixelmaI 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:13pixelmait 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:38JdGordon1am 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:54JdGordonamiconn: 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:12amiconnThe 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:49amiconnAnd it can display the fact that the battery is being charged at the same time
01:59:36Tomiswhat 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:40JdGordonI will dispute the 2nd bit
01:59:50JdGordonyou need to wait for the animation to change frames to know
02:00
02:00:05amiconnEven if you select numeric display, the statusbar will switch to graphical display when charging
02:00:15Unhelpfulstripwax: 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:49JdGordononce again... you are free to make your sbs do whatever the heck you want it to do
02:00:56amiconnOnly 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:40JdGordon55%+ doesnt give the same info?
02:01:47Tomislol
02:01:50amiconnIt doesn't fit
02:01:58JdGordonwhich is easier on the battery than redrawing the animation
02:02:21amiconnAnd it still doesn't convey that it's the battery status
02:02:45amiconnI was talking about the necessity to support built-in gfx.
02:02:49Tomisthe 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:14JdGordonRight, and I'm saying that if it was ever requested then it would have been added
02:04:22amiconnAnd I don't see why *I* should fix a feature which is currently working and you intend to *knowingly* break
02:04:30JdGordonbut you get 100x more flexibility by allowing loadable graphiocs
02:04:59JdGordonthere 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:33amiconnCharger connection? USB power? Disk activity?
02:05:44amiconnIt's not only the battery gfx...
02:06:10 Quit stripwax (Read error: 145 (Connection timed out))
02:06:51JdGordonthe 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:21amiconnAnd will look unrecognisable without gfx...
02:09:59Tomiseven text is just a series of graphics that need to be loaded and displayed
02:10:09JdGordonyou're smart.. you'll figure out what the numbers mean pretty quickly
02:10:46Tomiswhy 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:22JdGordonhmm... maybe we can do this another way... but you have to accept the red delta for it
02:22:56JdGordon*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:00JdGordonseperate from themes
02:23:28JdGordonthat 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:05JdGordonor because it hasnt loaded yet
02:25:21amiconnIt 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:17amiconnThis would save quite a number of bitmaps in any theme that wants to display battery status or volume with high precision
02:27:20amiconnFor 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:43Tomisor just the battery full and the battery empty
02:27:53JdGordonyes, and that I'd be happy for someone to add
02:28:09 Quit rasher (lindbohm.freenode.net irc.freenode.net)
02:28:09NSplitlindbohm.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:41NHeallindbohm.freenode.net irc.freenode.net
02:28:41NJoindionoea [0] (n=dionoea@yop.chewa.net)
02:28:41NJoinFlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net)
02:28:41NJoinXerion [0] (i=xerion@82-170-197-160.ip.telfort.nl)
02:28:41NJoinjordan` [0] (n=jordan@78.235.252.137)
02:28:41NJoinshodanX [0] (n=shodanX@jazz.informatik.uni-erlangen.de)
02:28:44JdGordonbut 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:44amiconnThis cutting would probably need to work in various directions, l/r/u/d at least
02:29:13amiconnIt's early usb and charging screen (the latter obviously not on Ondios)
02:29:26JdGordoncharging pre rockbox loaded?
02:29:38amiconnYes, with the disk completely unpowered
02:29:50JdGordonfine, is that the only two though?
02:29:57amiconnOr not - this *is* in rockbox
02:30:01JdGordonboth could draw the animations themselves
02:30:15JdGordonif its in rockbox then we should be using the users theme
02:30:34amiconnIt's rockbox running from rom (otherwise we would never get into this state - the archos firmware would handle it)
02:31:01amiconnNo disk access at this point - the disk is completely unpowered
02:31:55amiconnThis 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:18amiconnThe latter is important on the v1 as charging is software controlled - no cpu, no charging...
02:32:55JdGordonyes 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:16amiconnhmm?
02:33:27*amiconn doesn't seem to understand
02:34:08JdGordonthe current statusbar can be stripped to the essentials, and only called for those 2 early access screens
02:34:20JdGordonotherwise it wont be shown because your theme will be used
02:34:47amiconnYes, A few things can be stripped, like play status and probably volume
02:34:52JdGordonthat of course makes no sense either
02:35:10JdGordonwhy isnt it a list with charge level, status, time, disk access all layed out nicely
02:35:21JdGordonmuch more readable than a 8 pixel high animation
02:35:28JdGordonand much smaller code
02:35:42 Quit Stephen_ ("Leaving")
02:36:05amiconnperhaps...
02:36:13JdGordoneven a fancy full width progressbar!
02:36:28amiconnBut then the early usb screen and the in-rockbox usb screen will be fairly different
02:36:32JdGordonso?
02:36:51amiconnWell, unless you want to change the main usb screen as well
02:37:07JdGordonmaybe
02:37:07amiconnDo you have an ipod?
02:37:12JdGordonno reason why not
02:37:18JdGordonneither of my ipods are functional atm
02:37:28JdGordonmy mini2g sort of is.. sometimes
02:37:39amiconnDid you compare the OF's USB screen and diskmode USB screen?
02:38:01amiconnThey're not identical, but apple tried to make them as similar as possible
02:38:13JdGordonthats nice.. but we arnt apple
02:38:28Tomisif you can make things nice, you should
02:38:38JdGordoninside rockbox it should be as pretty as the user wants... early rockbox should be simple small code
02:38:41amiconnThey'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:09amiconnSure we're not apple, but *you* seem to be caring about looks (hmm, not always though)
02:39:29JdGordonI really just want a clean API and small codebase
02:39:46JdGordonhave we swapped? :)
02:40:08*amiconn doesn't think so
02:40:34JdGordonits usually me arguing for prettyness and you arguning for no wasted code :)
02:41:04amiconnI 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:11JdGordonthe 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:24JdGordonbut anyway.. we are sort of in agreement here
02:42:48amiconnMaking 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:48amiconnJdGordon: 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:22JdGordonjust a list.. or something.. I tihnk that info is more important than the usb plug bitmap
02:44:46Blue_DudeNobody else wants to weigh on on the direction of the main audio engine? I'm a little surprised....
02:44:49JdGordonnot even a list.. maybe just a progress bar at the bottom under the image for charge state
02:45:01JdGordonBlue_Dude: you didnt use the improtant key words
02:45:14Blue_DudeWhich are?
02:45:30JdGordonsettings, delta, break, etc...
02:45:35amiconnJdGordon: For USB there's also disk activity, plus the connected thingies
02:45:43JdGordonsure
02:45:47Blue_DudeOops, OK.
02:46:20JdGordonBlue_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:32JdGordonunless its something pretty contentious, there is no argument
02:46:47Blue_DudeIn my opinion, the quality delta of the current pcmbuf scheme is negative, important features are broken, and settings are imperfectly supported...
02:47:32JdGordonand seen as you are the only one to really look at it recently, we will accept that opinion
02:47:48amiconnBlue_Dude: Better means just better as long as all people involved have the same definition of better.
02:47:49Blue_DudeThe choice is patch it or rewrite it. Patching is quick, cheap and ugly. Rewriting is long, expensive and potentially really good.
02:47:51JdGordona software mixer has been on the wishlist for quite a while
02:50:15Blue_DudeI've tried patching, but the choice is still there. Going any further means committing to one or the other.
02:50:44JdGordonif 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:30Blue_DudeThat'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:53JdGordonhow expensive?
02:53:10Blue_Dude64k at minimum and a boosted thread.
02:53:12JdGordonwill it be able to work on all swcodec targets? the clip has 384KB RAM iirc
02:53:28Blue_DudeOnly if I steal from its pcmbuffer first.
02:53:43 Part gTanzola
02:54:01Blue_DudeIt might end up with .6 seconds of buffer vs 1 second.
02:54:30JdGordon284 cant be right... 2MB maybe?
02:55:19Blue_DudeI 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:48Blue_DudeOr I could take it from buffering and make it suffer.
02:55:55JdGordonwont just adding a new buffer do the same anyway?
02:56:14JdGordonis 64K the absolute minimum?
02:56:18Blue_DudeNot if it's taken from somewhere else.
02:56:29JdGordonit wouldnt worry me at all for most targets.. just the clip
02:56:34Blue_Dude64k? Yeah, that's about right. Two chunks plus larger code.
02:57:37Blue_DudeOr 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:50JdGordonI 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:02JdGordonget it working with a big ram usage and tweaklater?
02:58:16Blue_DudeMaybe.
02:58:51Blue_DudeThe first commit will have a screamingly bad red delta.
02:59:07JdGordonbig deal
02:59:18Blue_DudeAnd it won't ever get much better.
02:59:34JdGordonhang on.. you cant steal from the 512KB pcmbuf thats already there?
03:00
03:00:07Blue_DudeYes of course. But that means more boosting, more disk access, less runtime, etc. Stealth RAM steal.
03:00:39amiconnThe mixer needs to be able to run unboosted
03:00:40Blue_DudeAnd IIRC the Clip only has a 176k buffer.
03:01:08Blue_DudeThe mixer probably can, but a smaller buffer means the watermark is hit more often, meaning more boosting.
03:01:27amiconnThe pre-mixer buffer needs to keep its size
03:01:48amiconnChanging boost state too often is bad on a number of targets
03:01:49Blue_DudeThen I need to take 64k from somewhere else...
03:02:25Blue_DudeOr something smaller but put up with the increased callback overhead.
03:02:52JdGordonis the mixing too slow to be done in the PCM interrupt?
03:03:44amiconni.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:53JdGordonthen there is no extra thread, or buffers... just mix at the lats possible moment before going out to the codec?
03:04:03Blue_DudeMaybe. 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:00amiconnI'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:34Blue_DudeEven a very short clip uses several thousand samples though.
03:05:45amiconn10ms is 441 samples
03:06:06amiconnAnd I bet we could go lower than that
03:06:18Blue_DudeAnd the pcm callback looks at 32k chunks at a time.
03:06:19amiconnOn PP it may be possible to mix right in the fiq
03:06:42JdGordonif you reuse the voice stream or beeps, they could be pre mixed...
03:06:58Blue_DudeThat's dependent on user cooperation. You can't assume that.
03:07:12JdGordonsure you can... both are instantaneous events
03:07:17amiconnPre-mixed is what we have now - it's bad for latency (and there is the pause issue)
03:07:17JdGordonyou wouldnt want to uncouple them
03:07:25Blue_DudeRight.
03:07:50Blue_DudeThe problem is just-in-time mixing, but not too late...
03:07:57JdGordonso 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:10amiconn1s is too much for voice
03:08:18Unhelpfulthese 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:25Blue_DudeEven 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:09Unhelpfuln1s: 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:48amiconnWell, 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:51Blue_DudeThat'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:25Blue_DudeMaybe 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:25kugelBlue_Dude: why don't you rewrite/patch it so that the non-destructive thing can be added after the initial work?
03:12:50kugelIIUC that's the only questionable bit, I don't see why it's so critical to add in the first run
03:13:27Blue_Dudekugel: 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:42kugelso rewrite
03:14:08Blue_DudeWell yeah, that's where I'm going. I don't mind the rewrite but it's going to hurt.
03:14:10JdGordonBlue_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:41kugelBlue_Dude: I'm really only skeptical about the potential bloat the non-destructive mixing gives
03:15:12Blue_DudeJdGordon: 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:11Blue_DudeJdGordon: same thing. Really late non-destructive mixing is no mixing at all until feeding the DMA.
03:16:25kugelI'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:14kugela rewrite is painful, even more if you you plan to much for the initial work
03:18:20kugeltoo*
03:18:28Blue_DudeThis 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:23kugelJdGordon: merging this two function is a really stupid idea IMO
03:19:28kugelwith absolutely no gain
03:19:32JdGordonnot true
03:19:33kugelthe code inside is completely different
03:19:40JdGordonyes
03:19:41Blue_DudeBut 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:45JdGordonmerge the API... not the code
03:19:58kugelcalling the same function to get different results?
03:20:00***Saving seen data "./dancer.seen"
03:20:03JdGordonif they ask for full screen, then if they didnt disable the theme there will be problems
03:20:22JdGordonif they didnt disable the theme then they should expect to be using the theme viewport
03:20:46JdGordonits a sanity check thing
03:20:58kugelBlue_Dude: "unpretty" isn't an issue here
03:21:15kugelwhat is the point of merging them?
03:21:23kugelthat's calling for confusion
03:21:56Blue_DudeI thought it was *the* issue myself.
03:21:58kugela single function that yields different *logical* results based on magic is a bad functions
03:22:15JdGordonits not magic at all.. and thats why I changed the name
03:22:29JdGordonthe usage is "I want to draw.. give me the area to draw in"
03:23:17kugelthere's no point, just don't do it
03:23:44*kugel is annoyed by some of JdGordon latest crazy ideas
03:24:41kugelBlue_Dude: ?
03:25:32Blue_Dudekugel: "unpretty" is choppy illegible audio. For a DAP firmware I'd put that pretty high on my list of undesirable attributes.
03:25:54JdGordonI'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:02kugelhow do you know already it's going to be choppy?
03:26:12kugelmaybe it'll just be immediately slilent?
03:26:46kugelJdGordon: that's not simplifying
03:27:02kugelthat's introducing bad practice imo
03:27:21JdGordonnot at all.. if forces you to be explicit
03:27:37JdGordonit means you dont forget to disable the sbs after stealing the whole display
03:27:53kugelhow's that related to combining the two functions?
03:28:10Blue_Dudekugel: 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:45kugeleither 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:21JdGordoneither 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:25kugelBlue_Dude: and we cannot talk about the non-destructive thing after the rewrite happend?
03:29:26Blue_DudeAnd 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:35JdGordonthe flow is "Set the theme" then "give me the viewport i can draw in"
03:29:53Blue_DudeThe "non-destructive thing" *is* the rewrite.
03:30:06kugelI thought mixing multiple sources was
03:31:02Blue_DudeNope. 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:36Blue_DudeHow many simultaneous sources do we need to accommodate anyway?
03:31:54JdGordondepends how crossfade is done
03:31:59JdGordonI'd say 2 or 3
03:32:22kugelJdGordon: because it gives different results!
03:32:28JdGordonno it doesnt
03:32:35kugelI'm too tired now. I really dislike that bit
03:32:42 Quit kugel ("exit(0);")
03:33:00Unhelpfulhrm, an interesting test_codec feature might be the ability to benchmark a directory of compiled .codec files against one audio file...
03:34:59Blue_DudeJdGordon: 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:30JdGordonthen I'd start with voice/beeps as one, and audio as a second
03:36:10Unhelpfuland the next step after that is acovea for optimizing codecs :)
03:36:51 Quit LambdaCalculus37 ("POOF")
03:37:02Blue_DudeThat'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:27Blue_DudePushing 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:00
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:09CIA-80New 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:00
05:04:38 Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.5.5/20091102152451]")
05:15:46JdGordonkkurbjun: any thoughts on my most recent ml topic?
05:15:56JdGordonspecifically 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:00kkurbjunJdGordon: 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:09JdGordonthe 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:18JdGordonplugin menus would instantly just work again
05:19:40JdGordondo_menu() would always say "use the theme"
05:19:48JdGordonunless told not to
05:20:01***Saving seen data "./dancer.seen"
05:23:23JdGordondoing viewportmanager_theme_enable(i, true, NULL); would be the equivilant of enabling the theme and calling set_default in one call...
05:23:33JdGordonNULL being a viewport pointer though...
05:24:17*JdGordon attempts to wiggle this in without removing the inbuilt bar
05:25:17kkurbjunsounds 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:00
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:14TaZzZhaving issues with rockbox install .. its stuck on the themes part of install
06:32:16TaZzZthe 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:26ecognitoHi. Is it possible to change the order that items appear in the main menu?
06:42:59LloreanNot without recompiling
06:43:13ecognitoBummer. Thanx.
06:45:56TaZzZhow 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:52LloreanTaZzZ: 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:36TaZzZLlorean this rockbox rox
06:59:59Tomiswhat model ipod TaZzZ
07:00
07:00:21TaZzZ5.5
07:00:27 Quit bluebroth3r (Read error: 60 (Operation timed out))
07:00:59Tomisawesome
07:12:20CIA-80New commit by 03FlynDice (r23732): AMS Sansa: Remove wait_for_state() following transfer in sd_select_bank() function. ...
07:15:31TaZzZok 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:35Tomishttp://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:39CIA-80New 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
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:00
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:14JakeSo... what are the best setting to use for video on the Sansa c240?
09:23:58JakeI 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:18Tomisthere's guidelines/suggestions on the MPEG Plugin page Jake http://www.rockbox.org/wiki/PluginMpegplayer
09:27:46JakeI've been reading that, but I guess I missed something.
09:28:04Tomissearch the page for sansa, you'll find it
09:29:16JakeI need to find a micro SD card lol.
09:29:25Jake1gb just is not enough space...
09:36:04JakeYay got it to work
09:42:07JakeNow if only this screen was bigger..
09:44:20 Quit Thundercloud (Remote closed the connection)
09:47:56linuxstbamiconn: (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:00
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:12TheSevenUtchybann: Argh. Now this is really ugly, but probably the only way that works properly... :-/
10:37:43TheSevengevaerts, 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:51TheSevenliar is trying to track this down
10:40:52UtchybannTheSeven: 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:10UtchybannTheSeven: 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:44UtchybannI guess that the problem was related to the USEC_TIMER issue.
10:43:59TheSevenI 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:38TheSevenUtchybann: I think the proper way to fix this would be using a function to read the usec timer instead of a define
10:45:01TheSevenyou could still #define that function to just be a reg on other devices then
10:45:11TheSevenbut this of course involves touching a lot of code
10:45:50 Quit phanboy_iv (Read error: 104 (Connection reset by peer))
10:46:01UtchybannTheSeven: a function would have less chance to be optimize by gcc in newer version.
10:47:58linuxstbUtchybann: 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:18TheSevenUtchybann: we must *PREVENT* this from getting optimized, so an (inline) function would probably be the best solution for this
10:55:00Utchybannlinuxstb: ok. On my nano2g with r23722 and USER_TIMER fixed, HAVE_WHEEL_ACCEL seems fine.
10:55:47UtchybannTheSeven: let's go for a function.
10:56:19 Join Grahack [0] (n=chri@82.216.222.222)
11:00
11:20:07***Saving seen data "./dancer.seen"
11:54:11 Join DerPapst [0] (n=DerPapst@p4FE8F710.dip.t-dialin.net)
12:00
12:03:01mc2739Zagor: clip on current builds page is showing an old version (r22777) - can you look into this please?
12:06:18gevaertsmc2739, Zagor: that's due to a clip vs sansaclip mismatch somewhere. The rest uses sansaclip
12:07:51mc2739gevaerts: 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:52gevaertsmc2739: 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:20mc2739gevaerts: if r23724 was wrong then I guess r23727 is also wrong
12:20:53 Quit shodanX (lindbohm.freenode.net irc.freenode.net)
12:20:53NSplitlindbohm.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:12NHeallindbohm.freenode.net irc.freenode.net
12:25:12NJoinChanServ [0] (ChanServ@services.)
12:25:12NJoinjasio [0] (n=yann@cpc2-rdng20-2-0-cust902.15-3.cable.virginmedia.com)
12:25:12NJoinshaggy-h [0] (n=kiwi@host-87-74-127-193.dslgb.com)
12:25:12NJoinkugel [0] (n=kugel@rockbox/developer/kugel)
12:25:12NJoinmartian67 [0] (n=arkfar@about/linux/regular/martian67)
12:25:12NJoinDerPapst [0] (n=DerPapst@p4FE8F710.dip.t-dialin.net)
12:25:12NJoinGrahack [0] (n=chri@82.216.222.222)
12:25:12NJoinpetur [50] (n=petur@rockbox/developer/petur)
12:25:12NJoinJake [0] (n=60185bdd@83.168.254.42)
12:25:12NJoineinhirn [0] (n=Miranda@139.174.4.164)
12:25:12NJoinmaruk [0] (n=papier@titanium.sdv.fr)
12:25:12NJoinRob2223 [0] (n=Miranda@p4FDCE2B4.dip.t-dialin.net)
12:25:12NJoinmatsl [0] (n=matsl@dhcp126.contactor.se)
12:25:12NJoinHBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com)
12:25:12NJoinZagor [242] (n=bjorn@rockbox/developer/Zagor)
12:25:12NJoinxavieran [0] (n=xavieran@ppp118-209-137-145.lns20.mel6.internode.on.net)
12:25:12NJoinBagder [0] (n=dast@giant.haxx.se)
12:25:12NJoinHorschti [0] (n=Horscht2@xbmc/user/horscht)
12:25:12 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother)
12:25:12NJoinavacore [0] (i=nobody@90.184.100.129)
12:25:12NJoinTaZzZ [0] (i=GamingEx@hidden.botpack.eu)
12:25:12NJoinAEnima15771 [0] (n=clbarnob@h80ad26c3.async.vt.edu)
12:25:12 Join hd [0] (n=jd@Wikipedia/HellDragon)
12:25:12NJoinalexbobp [0] (n=alex@66.112.249.238)
12:25:12NJoinLss [0] (n=Lss@cm205.delta92.maxonline.com.sg)
12:25:12NJoinshodanX [0] (n=shodanX@jazz.informatik.uni-erlangen.de)
12:25:12NJoinjordan` [0] (n=jordan@78.235.252.137)
12:25:12NJoinXerion [0] (i=xerion@82-170-197-160.ip.telfort.nl)
12:25:12NJoinFlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net)
12:25:12NJoindionoea [0] (n=dionoea@yop.chewa.net)
12:25:12NJoinrasher [50] (n=rasher@rockbox/developer/rasher)
12:25:12NJoinbzed [0] (n=bzed@devel.recluse.de)
12:25:12NJoinBHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey)
12:25:12NJoincendres [0] (i=ashes@modemcable076.241-176-173.mc.videotron.ca)
12:25:12NJoinTomis [0] (n=Tomis@70.134.65.177)
12:25:12NJoinantil33t [0] (n=Mudkips@203-184-54-232.callplus.net.nz)
12:25:12NJoinlinuxstb [0] (n=linuxstb@rockbox/developer/linuxstb)
12:25:12NJointarbo [0] (n=me@unaffiliated/tarbo)
12:25:12NJoinpixelma [0] (i=quassel@rockbox/staff/pixelma)
12:25:12NJoinamiconn [0] (i=quassel@rockbox/developer/amiconn)
12:25:12NJoinlostlogic [50] (n=lostlogi@rockbox/developer/lostlogic)
12:25:12NJoinmikroflops [0] (n=yogurt@217-208-157-242-no112.tbcn.telia.com)
12:25:12NJoinsolexx [0] (n=jrschulz@85.176.117.164)
12:25:12NJoinkillan [0] (n=nnscript@c-94fc70d5.06-397-67626721.cust.bredbandsbolaget.se)
12:25:12NJoindroidcore [0] (n=mark@76-10-140-107.dsl.teksavvy.com)
12:25:12NJoinJ-23 [0] (n=zelazko@unix.net.pl)
12:25:12NJointchan [0] (n=tchan@lunar-linux/developer/tchan)
12:25:12NJoinT44 [0] (n=Topy44@78.48.214.100)
12:25:12NJoingevaerts [0] (n=fg@rockbox/developer/gevaerts)
12:25:12NJoinshai [0] (n=Shai@192.117.110.233)
12:25:12NJoinSIGSEGV [0] (n=user@61.250.113.98)
12:25:12Mode"#rockbox +o ChanServ " by irc.freenode.net
12:25:12NJoinUtchybann [0] (n=lolo@ede67-1-81-56-102-26.fbx.proxad.net)
12:25:12NJoingtkspert_ [0] (n=gtkspert@203-206-46-209.dyn.iinet.net.au)
12:25:12NJoinZarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com)
12:25:12NJoinFOAD [0] (n=dok@82.93.10.238)
12:25:12NJointha [0] (i=1038@ccc2.rbg.informatik.tu-darmstadt.de)
12:25:12 Join Llorean [0] (n=DarkkOne@rockbox/user/Llorean)
12:25:12NJoingoffa [0] (n=goffa@70.33.8.114)
12:25:12NJoinJdGordon [0] (n=jonno@rockbox/developer/JdGordon)
12:25:12NJoindmb [0] (n=Dmb@unaffiliated/dmb)
12:25:12NJoinAlexP [0] (n=alex@rockbox/staff/AlexP)
12:25:12NJoinfyrestorm [0] (n=nnscript@cpe-69-203-150-85.si.res.rr.com)
12:25:12NJoinjon-kha [0] (i=jon-kha@kahvi.eu.org)
12:25:12 Join GodEater [0] (n=bibble@rockbox/staff/GodEater)
12:25:12NJoinniekie_ [0] (i=quasselc@dreamworld.bergnetworks.com)
12:25:12NJoinKopfgeldjaeger [0] (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de)
12:25:12NJoinSlasheri [0] (i=miipekk@rockbox/developer/Slasheri)
12:25:12NJoinyosafbridge [0] (n=yosafbri@64.71.152.39)
12:25:12NJoinkadoban_ [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com)
12:25:12NJoinlinuxguy3 [0] (n=timj@adsl-75-57-190-229.dsl.emhril.sbcglobal.net)
12:25:12NJoinscorche [50] (n=scorche@rockbox/administrator/scorche)
12:25:12 Join Torne [0] (i=torne@rockbox/developer/Torne)
12:25:12NJoinjfc^3 [0] (n=john@dpc6682208002.direcpc.com)
12:25:12NJoinmc2739 [0] (n=mc2739@rockbox/developer/mc2739)
12:25:12NJointmzt [0] (n=tmzt@adsl-76-244-155-63.dsl.akrnoh.sbcglobal.net)
12:25:12NJoinRes1 [0] (n=Res@user-0c6s6gs.cable.mindspring.com)
12:25:12NJoinsbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw)
12:25:12 Join bughunter2 [0] (n=bughunte@unaffiliated/bughunter2)
12:25:12NJoinThomasAH [0] (n=thomas@aktaia.intevation.org)
12:25:12NJoingrndslm [0] (n=grndslm@174-126-14-4.cpe.cableone.net)
12:25:12NJoinBlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net)
12:25:12NJointogetic [0] (n=togetic@unaffiliated/ibuffy)
12:25:12NJoinYPSY [0] (n=ypsy@geekpadawan.de)
12:25:12NJoinblithe [0] (n=blithe@blakesmith.me)
12:25:12NJoinZambezi [0] (i=Zulu@80.67.9.2)
12:25:12NJoinehntoo [0] (n=ehntoo@lug.mtu.edu)
12:25:12 Join rvvs89 [0] (n=ivo@pdpc/supporter/base/rvvs89)
12:25:12NJoinn17ikh [0] (n=n17ikh@host-69-59-126-212.nctv.com)
12:25:12NJoinGalois [0] (i=djao@efnet.math.uwaterloo.ca)
12:25:12NJoinps-auxw [0] (n=arneb@dyn37.ps-auxw.de)
12:25:12NJoinscorche|sh [50] (n=scorche@rockbox/administrator/scorche)
12:25:12NJoinz35 [0] (n=z35@ool-45714f83.dyn.optonline.net)
12:25:12NJoinkrazykit [0] (n=kkit@adsl-76-251-250-122.dsl.ipltin.sbcglobal.net)
12:25:12NJoinDhraakellian [0] (n=ntryon@cpe-72-226-197-191.rochester.res.rr.com)
12:25:12NJoinjds2001 [0] (n=jds2001@fedora/jds2001)
12:25:12 Join kkurbjun [0] (n=kkurbjun@rockbox/developer/kkurbjun)
12:25:12NJoinzu_ [0] (n=zu@bucketheaded.eu)
12:25:12NJoincrashd_ [0] (i=foobar@lostnode.org)
12:25:12NJoinmaraz [0] (i=maraz@xob.kapsi.fi)
12:25:12NJointopik [0] (i=awesome@wtf.grmpf.org)
12:25:12NJoinchaos [0] (n=chaos@gentoo/user/ch4os)
12:25:12NJoinpreglow [0] (i=thomj@tvilling2.pvv.ntnu.no)
12:25:12NJoinlyngaas [0] (n=staale@19.81-167-149.customer.lyse.net)
12:25:12NJoinTrista281 [0] (i=tristan@i.dont.want.to.die.virgin.net.in)
12:25:12NJoinCIA-80 [0] (n=CIA@208.69.182.149)
12:25:12NJoinrphillips [0] (n=rphillip@66-90-184-91.dyn.grandenetworks.net)
12:25:12NJoinelcan [0] (i=user36@pr0.us)
12:25:12NJoinhatseflats [0] (n=hatsefla@193.200.132.183)
12:25:12NJoincrwl [0] (n=crwlll@a91-156-100-168.elisa-laajakaista.fi)
12:25:12NJoinB4gder [241] (n=daniel@rockbox/developer/bagder)
12:25:12NJoinKohlrabi [0] (n=Kohlrabi@frustrum.nosebud.de)
12:25:12NJoinadvcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019)
12:25:12NJoinjvd [0] (n=syscrash@poipu/developer/syscrash)
12:25:12NJoinUnhelpful [0] (n=quassel@rockbox/developer/Unhelpful)
12:25:12NJoinTuplis [0] (n=jani@unaffiliated/tuplanolla)
12:25:12NJoinmarkun [50] (n=markun@rockbox/developer/markun)
12:25:12NJoinOverand [0] (i=overand@crappy.domain.name)
12:25:12NJoinfish_ [0] (n=fish@freigeist.org)
12:25:12NJoinfxb__ [0] (n=felixbru@h1252615.stratoserver.net)
12:25:12NJoinknittl [0] (n=knittl@unaffiliated/knittl)
12:25:12NJoinrjg [0] (i=rgordon@odie.tomelliott.net)
12:25:17 Nick Tuplis is now known as Tuplanolla (n=jani@unaffiliated/tuplanolla)
12:25:17gevaertsmc2739: daily builds is yet another different system
12:26:09gevaertslinuxstb: that's of course an option. We need to decide on this one of these days...
12:27:11linuxstbIMO what is in tools/configure has always been _the_ target name - and other names shouldn't have been used elsewhere.
12:27:44linuxstb(whether the current names in tools/configure are good or bad is another question).
12:29:07gevaertsI 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:20CtcpVersion from freenode-connect!freenode@freenode/bot/connect
12:29:34linuxstbI know - but the clip is new, so we can at least be consistent for that.
12:29:49linuxstb(consistent in all places, rather than consistent with other sansas)
12:30:22Zagorpetur did a big list a while back
12:30:22gevaertsok, so we change the build system name?
12:30:28Zagors/list/table/
12:30:41kugelit should be consistent with other targets IMO
12:30:47kugelwith other sansas, I mean
12:30:49linuxstbZagor: That wasn't bluebrother?
12:30:52peturI did what?
12:31:03*petur scrolls back
12:31:05linuxstbkugel: Even though those other sansas are wrong?
12:31:15kugelyea
12:31:22Zagormy memory is not known to be very good... I thought it was petur (doing a big table of target name schemes)
12:31:33peturnope, wasn't me
12:31:34kugelit's not wrong, it's different
12:31:42linuxstbkugel: No, it's wrong.
12:31:47kugelZagor: I think it was rasher
12:32:02Zagorkugel: ok
12:32:08kugelwell, rasher made proposals, but we also have a wiki page with the current names
12:32:32Zagorkugel: which page is that?
12:33:01kugellinuxstb: unfortunately, configure isn't the ultimate source either. there are targets with the same configure name, but different builds
12:33:18gevaertskugel: really?
12:33:23linuxstbkugel: Yes, I know. Which is why I said "as far as possible".
12:33:28linuxstbgevaerts: Different RAM sizes.
12:33:43gevaertshm, indeed
12:33:55kugelZagor: http://www.rockbox.org/wiki/BuildNames
12:34:09Zagorkugel: thanks
12:34:13gevaertswell, configure-name + suffix can work
12:35:23Zagorthis was it: rasher.dk/rockbox/targetnames.php">http://rasher.dk/rockbox/targetnames.php
12:35:36kugelthe page is a bit out of date though
12:35:49linuxstbYes. 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:14mc2739is there a way to know which name is needed fro any given system?
12:37:58kugellinuxstb: if only the configure names were consistent
12:38:21 Join MethoS- [0] (n=clemens@134.102.106.250)
12:38:25linuxstbkugel: I don't see that as the most important point. It's more important for the same name to be used everywhere.
12:38:41mc2739as in, how would you determine if you need "clip" or "sansaclip"
12:39:04kugelmc2739: not currently ;) that's why we're discussing it
12:39:09gevaertsmc2739: look in all places (sorry, I don't have a list)
12:39:54kugellinuxstb: if we rework it now, then we can take the opportunity to make it good everywhere
12:40:45linuxstbkugel: 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:34ZagorI 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:19Zagorsuch as the "company/linemodel" column in rasher's graph
12:42:27Zagor:)
12:43:49gevaertscompany/line/model/variant :)
12:45:19mc2739and any new ports added to svn should follow that scheme
12:47:59Zagordoes anyone oppose the company/linemodel names as written up by rasher?
12:48:24Zagorthe 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:27Zagorcowon's web site lists d2, d2+ and s9 as "cowon" products. the rest are iaudio.
12:49:50Zagorso it's correct
12:50:37kugelZagor: are you volunteriing to make a patch? :)
12:50:41Zagoryes
12:50:47kugel\o/
12:51:24*kugel wonders if that could a enforced by a script
12:51:41Zagorwhat, exactly?
12:52:03kugellike, instead of hardcoding the complete name, we ask for company, line and model separately, and then combine them as per rule
12:52:18Zagorsounds like a lot more work and bother
12:52:28Bagderon most places we use a single word
12:52:33Bagderso it wouldn't work
12:54:46BagderZagor: do you write a script that translates the names?
12:55:10BagderI figure a 50 lines sed or so could work
12:55:42ZagorI haven't looked at the specifics yet. but some sed fu is likely useful
12:56:27Bagderas 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:00
13:05:58CIA-80New 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:03Bagderwe should leave the existing working and add the new consistent ones
13:13:24Bagderand the new ones would then be used elsewhere when referring to specific targets
13:13:37kugelthey'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:06kugelideally 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:32linuxstbkugel: 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:08TaZzZwhat would cause the games not to work .. none of them
13:20:10***Saving seen data "./dancer.seen"
13:20:31BagderTaZzZ: a flawed install
13:21:26TaZzZya was thinking of reinstalling
13:22:53TaZzZthe 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:59TorneThe 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:08Tornethe number of found files will continue to go up while it's doing htat
13:24:50TaZzZTorne it did add them
13:25:15Tornethen your file is probably called the wrong thing..
13:25:16dionoeafunman: hi. I finaly managed to write a proper memmove_wrap() :)
13:25:28Tornerockbox doesn't read the file, so it doesn't matter what's in it
13:25:35Torneit just has to exist.
13:25:47funmandionoea: hello, i just saw that, i hope it makes clip playback crashproof_
13:25:51TaZzZshould i make it a txt and leave txt on it
13:25:59Torneno, it has to be called database.ignore
13:26:00Tornenothing else
13:26:53dionoeafunman: the only issues is that copies of buffers bigger than half the ring buffer will probably be really slow
13:26:59dionoea*issue
13:27:25funmanthe code in SVN uses a simple loop anyway
13:28:20kugeldionoea: I don't think that's a problem
13:28:55dionoeait could be optimised a bit with a local buffer (as mentioned in my last post)
13:29:17kugelthe 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:02kugelspeed of buffering isn't going to be a problem on the clip as far as I can see
13:30:32dionoeayou'll still be iterating a milion times if the buffer is 2MB big and you're moving 1MB of data :)
13:30:44dionoeawith non linear data accesses
13:31:39funmanwe're really moving 30 or 40kB
13:32:04dionoeathen why'd you have a problem with buffers bigger than half the ring buffer ?
13:32:07kugeldionoea: the audio buffer isn't bigger than 400k actually
13:32:12dionoeaah ok
13:32:50funmanhm 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:13kugelI think moving 400k will be always fast enough on the clip, even if the algorithm is a bit slower than plain memmove
13:33:26kugelalso, working code is better than fast code :)
13:33:32dionoea:)
13:34:49funman"optimized crashes"
13:37:12dionoeaI 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:46dionoea(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:57dionoea*note
13:39:01funmandionoea: you have a clip ?
13:39:11dionoeamy sister does
13:39:41 Quit kugel (Read error: 60 (Operation timed out))
13:39:53dionoeabut 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:00
14:02:56kugelfunman: did you see my sd patch?
14:03:23funmanno
14:03:50kugelfs#10805
14:08:41 Part Bagder
14:16:46kugeldionoea: why do you call it perfect?
14:18:23dionoeakugel: because I was glad to finally get it to work :)
14:18:28dionoeaI'm sure that it's far from perfect
14:18:44kugelit 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:27dionoeaah, 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:07Zagorsed 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:00
15:01:49 Join thegeek [0] (n=nnscript@129.241.123.168)
15:18:15linuxstbZagor: 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:51Zagoryes I will
15:20:12***Saving seen data "./dancer.seen"
15:22:12linuxstbZagor: There's a typo in the m5 line of your sed script
15:22:30Zagoryeah I saw that. thanks for checking!
15:22:50Zagorand yes, lang files will require different replace rules
15:25:21mc2739Zagor: line 34 also has an error - \bc200 should be \bc100
15:25:40linuxstbIf 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:11Zagoryes, it's a big job
15:27:17 Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr)
15:27:33Zagorsome 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:54Zagorconsistency 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:03linuxstbZagor: "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
16:00:27CIA-80New commit by 03mc2739 (r23735): Correct r23724 and r23727 - clip -> sansaclip
16:05:29mc2739Zagor: At you convienience, would you do a web server update?
16:05:52mc2739s/you/your/
16:06:00Zagorjust don't do it again :)
16:10:39mc2739Zagor: 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:59Zagormc2739: you forgot one line in rockbox.pm
16:12:06ZagorI fixed it
16:12:36CIA-80New commit by 03zagor (r23736): clip => sansaclip
16:13:03Zagorlinuxstb: they will be
16:15:08 Join pamaury [0] (n=pamaury@140.77.26.133)
16:16:27Zagorhas 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:39Zagorso perhaps the name should be tatungtpj1022 rather than eliotpj1022.
16:17:45Zagoror even tatungelio
16:20:37 Join roolku [0] (n=roolku@77-99-223-115.cable.ubr16.sgyl.blueyonder.co.uk)
16:20:41mc2739Zagor: thanks again
16:20:42 Join Omlet [0] (i=omlet05@91.181.227.166)
16:21:36roolkuZagor: there is the p810 http://www.wikio.co.uk/guide/tatung-elio-p810-4911.html
16:22:12Zagoryeah but tatung don't call that one elio: http://www.tatung.com/3codm/portable.asp
16:26:09gevaertsZagor: are there actually more than two in existence? ;)
16:26:14roolkuquite 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:36roolkugevaerts: I have two and linuxstb has one. :)
16:26:49gevaertsok, so there are three :)
16:27:27 Quit funman ("free(random());")
16:28:04 Quit matsl (Read error: 110 (Connection timed out))
16:32:15linuxstbroolku: amiconn now has my Elio
16:32:33linuxstb(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:34roolkulinuxstb: cool. maybe time to share my measly findings...
16:42:56CIA-80New 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:08cowgardenwow, congratullations so the speed regulation, listening to voice at 250% still sounds very very good
16:55:31cowgardenis that very recourcehungry?
17:00
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
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:07minushello :)
18:07:00*Torne pesters anyone with a hard-disk based player to try out FS #10798
18:07:20minusi installed rockbox on my sansa fuze v1 yesterday and i have to say: it rocks, works almost without errors
18:07:30Torneglad 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:59kugelTorne: I need to find my samsung :(
18:09:06Tornekugel: heh
18:09:11 Join hebz0rl [0] (n=hebz0rl@dslb-088-065-209-022.pools.arcor-ip.net)
18:09:18Tornei've tried it on ipodvideo and beast
18:10:09Tornewhich actually covers most of the configs, tbh
18:10:17Tornebeast has DMA, and ipodvideo has large sectors
18:11:34Tornei 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:33Coldarchonanyone there? after the utility failed I tried the manual install on an ipod nano 1st generation, but ipodpatcher always craches. any ideas?
18:16:51Tornewhat 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:36marukColdarchon: can you copy/paste on http://pastebin.com/ the output of 'ipodpatcher -l' ?
18:18:07Coldarchonon 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:44Coldarchonhttp://pastebin.com/m5eeb23ea
18:19:46Coldarchondone
18:21:26ColdarchonI formated, put the patch onto the ipod, started via cmd from there, it all fails
18:21:52kugelhm
18:22:02kugelTorne: I found it, let me reboot
18:22:10kugel(into linx to make a buil :) )
18:22:20 Quit kugel ("exit(0);")
18:22:42marukColdarchon: output seems good. Can you pastebin 'ipodpatcher &minus;&minus;install' output ?
18:22:46 Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net)
18:23:53Coldarchonempty, it crashes
18:24:01ColdarchonI can make a screen if you want
18:26:00marukColdarchon: my feeling is that you have some i/o error on your flash.
18:26:49Coldarchonhm, itunes works perfectly, it's just that the battery doesn't have energy for more than 1 hour
18:28:43marukitunes write to the second partition, ipodpatcher to the first one.
18:29:05Coldarchonmakes sense in what I have read so far
18:30:19minuscan you access the flash memory directly?
18:30:38 Join kugel [0] (n=kugel@e178111115.adsl.alicedsl.de)
18:30:51Coldarchonyepp, I can put files on it
18:31:05ColdarchonI 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:11linuxstbColdarchon: 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:47ColdarchonI tried that after install failed and then formated again
18:37:24 Join freddyb [0] (n=fred@70.104.101.195)
18:37:55Coldarchonat first it was grey with a black font. is there something else than a format that I can do?
18:38:17linuxstbWhat was grey with a black font?
18:38:33freddybTorne: I'm confused. Isn't linking to the FS patches "providing the sources?"
18:38:39gevaertsColdarchon: why format after running itunes?
18:39:06Tornefreddyb: no.
18:39:08linuxstbfreddyb: No. _you_ have to provide the source.
18:39:28FlynDicefunman: 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:36funmanfreddyb: i'm looking at your last patch, seeing if it works on the clip (works fine on fuze)
18:39:52freddybFunman: thanks.
18:39:53ColdarchonI 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:02funmanFlynDice: hm didn't you ask this some time ago ?
18:40:08kugelany idea why dma doesn't work?
18:40:42funmanFlynDice: looks incorrect, timeout should be total time, not total time spent in the sd thread
18:40:45funmankugel: 'dma' ?
18:41:13Tornekugel: me, you mean? :)
18:41:13kugelfunman: for recording
18:41:24funmani didn't work on it further
18:41:46freddybTorne: Then I guess I need them taken them down. I maxed my web space with just the binaries. Can you do that?
18:41:53FlynDicefunman: 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:07funmanlast patch using DMA is 3 weeks old and causes error in recording code
18:42:45funmanrecording crashes on clip
18:42:46Tornekugel: 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:59Tornefreddyb: you should be able to edit your own posts
18:43:06kugelnope
18:43:55CIA-80New 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:10funmanfreddyb: what are you talking about with "providing the sources" ? can't find anything in the irc log
18:44:27Tornefreddyb: i posted on his forum threads, which is why you can't find it in the irc log
18:44:45Tornehe has three custom builds up for his alternative scrollwheel keyboard patch
18:44:49Tornebut no source
18:45:15kugelmusic plays, so it can't be that bad :)
18:45:51funmanGPL only requires you to provide the source when someone ask for it, not to distribute the sources with the binary
18:46:30Tornefunman: if you go with that option you have to be able to respond to requests for sources for three years
18:46:47funmanso?
18:46:51Torneso yes, you can do that, but there is some difficulty involved
18:46:56AlexPfunman: It is less onerous to supply them along with IMO, but that is an option
18:47:01gevaertsAnd provide a written offer, whatever that means
18:47:08funmanit's simpler to just link to flyspray
18:47:21AlexPAnd then have to supply the source for three years
18:47:23gevaertsthat is *not* valid
18:47:24Tornethat's not sufficient for any of them.
18:47:34funmanwe're geeks, not lawyers!
18:47:45freddybTorne: 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:55Tornefreddyb: 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:45Tornekugel: works for me ;)
18:49:01Tornefunman: whether people respect the GPL is kinda important, though
18:49:06freddybThanks. Should FS #10763 be deleted/removed also?
18:49:33funmanTorne: IMO the most important is to respect the spirit (make sure the sources are easily accessible)
18:49:34kugelTorne: it was the wrong SOURCES :)
18:49:36Torneer, why should the FS entry be deleted?
18:49:54freddybTorne: same thing, right?
18:50:10gevaertsfreddyb: I see no binaryes on FS #10763
18:50:13Tornefreddyb: Sources must be available with binaries
18:50:20Tornethere are no binaries there
18:50:27freddybOh.
18:50:31Torneif people couldn't post patches then the entire open source thing wouldn't really work :)
18:50:46kugelIIRC you don't need to provide the sources until someone asks for them?
18:50:55minusis the file save "dialog" the same for all devices?
18:51:41Tornekugel: 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:12freddybfunman: what happened when clip crashed?
18:52:16Tornefreddyb: i've removed the thrads, anyay
18:52:16funmanno idea
18:52:30 Join Tomis2 [0] (n=Tomis@70.134.82.83)
18:52:30kugelargh, yh925 disk speed is soooooooo slow
18:52:31Tornefreddyb: and i'm not trying to stop you from demoing your patch :)
18:52:45kugel<3MB/s I believe (the OF bootloader is way faster)
18:54:23gevaertsTorne: test_disk passes on my gigabeat f
18:54:43Tornegood to hear
18:54:57Tornei 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:12kugelwin! :)
18:57:40Tornewell that's several players it doesn't seem to have totally screwed
18:57:45Torneshall i commit? :)
18:58:24AlexPDo you feel lucky?
18:58:29Tornewell, the better questoin is will waiting help it get tested any better.
18:58:47Torneit gets tested a lot more if it's in the current build :
18:59:22Tornei 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:27CIA-80New 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:30Tornebecause I have changed from doing WRITE SECTORS to doing WRITE MULTIPLE
18:59:37Tornewhich is an actual semantic change to our interaction with the disk
18:59:48funmanfreddyb: thanks a lot :D
18:59:51Torne(to better reuse the code for handling reads, and because it should be faster)
19:00
19:00:46kugelfunman, freddyb \0/
19:01:16*kugel wonders if the clip recording crash is related to the clip radio freeze
19:01:27kugelTorne: go for it already! :P
19:01:49Tornekugel: hey i've yet to have broken anything, i'm trying to maintain a perfect score :)
19:01:59funmankugel: no, perhaps to fs#10605 though
19:02:31kugeldid the radio on the clip ever work?
19:03:03kugelTorne: that's a hopeless goal unfortunately
19:03:06funmansure
19:03:22kugelwhat broke it? mmu patch?
19:03:25funmani identified the lockup in the same location than previously
19:03:30funmanwhich had been fixed somehow by bertrik
19:03:38funmanno, something else
19:04:01CIA-80New commit by 03torne (r23740): FS #10798 - unify ata_read_sectors and ata_write_sectors ...
19:04:04kugelso, does anyone bother to bisect it?
19:04:06funmanthere were FM lockups on c200v2 IIRC
19:07:16minusdoes the Rockboy plugin work?
19:07:29funmanthey all work
19:08:27freddybfunman: kugel: thanks. I wish knew something about the Clip...
19:08:29minusbut it's not included on the standard distribution
19:08:40AlexPminus: It is on the players it works on
19:08:53AlexPWhat do you have?
19:08:56funmanfreddyb: Clip has other problems so until they are solved, I wouldn't look at recording on the clip
19:09:23CIA-80New commit by 03torne (r23741): FS #9721 - No error check after writes in ata.c ...
19:09:33Tornemight as well put that one in too, while i'm messing about with ata writes. :)
19:09:50minussansa fuze, but didnt see that there's no coloumn for it on the PluginIndex wiki page
19:10:07AlexPThen I suspect it hasn't been adapted/enabled on the fuze
19:10:16kugelthe yh* have 8~k of unused iram :/
19:10:18funmanit worked last time i tried
19:10:19kugel~8k
19:10:29AlexPfunman: rockboy?
19:10:47AlexPminus: How are you trying to run it? You should be clicking on a ROM
19:10:49linuxstbminus: Are you just looking in the plugins menu (where it won't be)? Or have you tried opening a .gb file?
19:10:52funmanminus: http://download.rockbox.org/daily/manual/rockbox-sansafuze/rockbox-buildch10.html#x13-22500010.3.9
19:11:56kugelTorne: it looks like writing has gotten a lot faster!
19:12:00Tornereally?
19:12:10Tornei mean, it shohld get faster
19:12:11kugelreading is still painfully slow
19:12:26Tornealso the binsize delta is -500 or so on all the hd targets
19:12:29*Torne wags! :)
19:12:45kugelwrite is 17MB/s, reading is 5.5MB/s (1MB aligned test)
19:13:19Tornei 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:24Torneit seemed silly not to do it when we have the loop to do the multisector reads right there.
19:15:58funmandionoea: start and end in your memmove_wrap() prototype are start & end of ringbuffer ?
19:16:08Tornec200v2 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:56Tornenobody with an ipod other than the video has answered my poll about that startup bug yet :(
19:17:07funmanTorne: 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:30dionoeafunman: correct
19:17:30Tornefunman: i just mean, it varies a lot on seemingly irrelevant commits, when almost all other targets have 0
19:17:52dionoeafunman: end is the first byte outside the ring buffer
19:17:53 Quit Jake ("CGI:IRC (EOF)")
19:18:05funmanthey could be hardcoded instead of given by arguments
19:18:15funmani'm trying to merge your code in buffering.c
19:18:21dionoeasure. I just wanted something generic
19:18:34funmangcd() involves division by the way (% operator)
19:18:55dionoeawell if you know any other faster method of computing a gcd I'm all ears :)
19:19:22funmani know one but I use it in my proof of Riemann's hypothesis so I can't publish it
19:19:42dionoea:)
19:19:44 Quit grndslm (Read error: 60 (Operation timed out))
19:20:14***Saving seen data "./dancer.seen"
19:20:38kugelfunman: 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:31dionoeafunman: feel free to test the function with your own test code before using it. 2 validations are better than one
19:22:05funmankugel: 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:12kugelTorne: ok, I take it partly back. writing has gotten faster, but it was already way faster than reading in SVN (11MB/s)
19:23:21kugelany idea why reading is so slow?
19:23:24Torneno.
19:23:31Torneiirc it's like that in test_disk on ipodvideo also
19:23:38Tornei've not benched it via any other method
19:23:42funmankugel: r19714
19:24:18funmanthe log doesn't tell why i made that though
19:24:48funman 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:51funmanbertrik: hello, do you remember fixing a lockup in Sansa AMS FM ? (I think it was on a specific model, e200v2 perhaps)
19:26:14kugelit was fixed at the devcon IIRC
19:27:26bertrikfunman, yes, it was for e200v2
19:27:41funmanI believe the Clip has the same problem
19:27:44bertrikI think there is still a similar problem for c200v2
19:28:17funmandoes the FM work sometiems on c200v2?
19:28:21bertrikthe 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:29Torneargh, of course the ATA stats patch massively conflicts with the ata unification i just committed
19:28:34Tornei will have to rewrite the stats patch :)
19:28:46Tornehm i should probably go home
19:28:47kugelata code is so much faster than sd even for single SECTOR_SIZE transfers :(
19:28:58bertrikfunman, very rarely, it's an initialisation problem that causes a hang in the tune loop
19:29:25kugelit doesnt work on mine
19:29:28funmanentering the FM screen on my Clip just locks up in si4700_set_frequency
19:29:38minusata code?
19:30:10bertrikkugel, 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:31bertrikthe 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:55kugelsvn log is a nice glass ball ;)
19:32:59minusisn't the AMS a ARM processor?
19:33:27bertrikadditionally... 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:37kugelbertrik: have you checked whether playback works better on c200v2 already?
19:35:06funmanwell playback is still buggy
19:35:23 Join saratoga [0] (i=9803c6dd@gateway/web/freenode/x-rltlqjhhzfqxwudm)
19:35:47funmanminus: wiki page SansaAMS has all the details
19:35:54bertrikyes 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:56minusk
19:36:18funmanon c200v2 it's worse because color lcd eats up more RAM
19:36:30saratogahow much memory does the c200v2 have for buffering?
19:36:34saratoga350KB?
19:37:03bertrikCan I look that up for you somehow?
19:37:19funmandebug menu -> buffering
19:37:35bertrikRockbox info says Buffer: 259 KB
19:38:20funmanbertrik: can you try last patch on FS #10605 ?
19:38:30bertrikdebug menu -> buffering says pcm 0/176400 and alloc 0 / 48656
19:39:03funman176400 is 1 second of PCM buffer
19:39:31 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk)
19:39:37bertrikfunman, the memmove_wrap.diff patch?
19:39:43funmanyes
19:40:10funmani'd test on Clip but it crashes less frequently
19:41:01bertrikjust to be clear, should I test that patch on the clip or on the c200v2?
19:41:08funmanc200v2
19:48:21bertrikfunman, the first mp3 I tried wouldn't start ...
19:48:49 Join CaptainKwel [0] (i=2669ecc2@gateway/web/freenode/x-vhpnlkvdjpqgbtmm)
19:49:10funmancan you mention that on FS please ? + :(
19:49:24kugelhttp://www.daniweb.com/code/post969374.html# apparently has a way to do gcd without div
19:49:46funmankugel: the div comes from %
19:49:55kugeli know
19:50:15kugelthe second function has only add/sub
19:50:45funmansorry, didn't read the second one
19:51:26kugeldionoea: ^
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:10dionoeakugel, funman: I'm not sure that it'd be faster.
19:56:54kugelit probably is
19:57:14kugelon targets without hardware div (arm) at least
19:57:20 Join torquel [0] (n=4dff77ac@giant.haxx.se)
19:57:27funmanit'd depend the ratio between the 2 integers
19:58:10dionoeaarm doesn't have hardware div ?
19:58:20 Join archibald [0] (n=4dff77ac@giant.haxx.se)
19:58:22funmanno
19:58:26dionoeaah ... cool :)
19:58:50 Part LinusN
19:58:51dionoeaI still guess that the first one would be faster. It has like exponential convergence speed while the other one looks more linear
19:59:01funmandivision is emulated by gcc
19:59:16 Join stripwax [0] (n=Miranda@87.194.34.169)
19:59:23minuswhy?
19:59:28 Quit stripwax (Client Quit)
19:59:55kugelit 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:57funman19:58 < dionoea> arm doesn't have hardware div ?
19:59:57funman19:58 < funman> no
20:00
20:00:00funmanminus: ^
20:00:16minuseh
20:00:23dionoeawell the second one basically implements modulo using: mod(a,b) = while (a > b) a -= b;
20:00:33dionoeaI doubt that gcc's % implementation could be slower
20:00:44minuswell, benchmark it
20:01:54dionoeaI'd assume that gcc developpers are kind of smart :)
20:02:01 Quit StealthyXIIGer (Read error: 131 (Connection reset by peer))
20:02:01kugeldividing in a loop is even worse ;)
20:02:18 Join StealthyXIIGer [0] (n=stealthy@68.62.19.6)
20:02:19funmanthey can be smart but can't use the device beyond its capabilities
20:02:19 Quit torquel ("CGI:IRC (Ping timeout)")
20:03:05dionoeaso 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:09funmanif a == LOT*b + BIT then I believe using gcc's div would be faster
20:03:33 Quit Rondom ("leaving")
20:05:59funmanhttp://pastie.org/713208 < gcc 4.0.3 mod function for arm9tdmi not including div0
20:06:16funmanall I can say is there is many loops
20:07:29kugeldionoea: what values is that gcd called with? total memory addresses?
20:07:29minushttp://www.pubbs.net/gcc/200908/10727/ is this anything useful?
20:07:30amiconnThat's the slower (but smaller implementation)
20:07:45minusbut it looks like it's for the thumb instructionset
20:08:00amiconnIt's not as slow as one might think when seeing those loops
20:08:17dionoeakugel: one is the ring buffer size, the other one depends on how much the dst and src buffers overlap
20:08:54amiconnThere 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:17amiconnAnd btw, modulo is faster than a full-fledged div
20:11:07minusbecause you dont need to count
20:11:42funmani wish we could solder some 128MB SDRAM to Clip/c200v2 and mark them stable
20:13:02minushow much ram does it have normally? 2.5Mbit?
20:13:43funman2MB + 384kB
20:13:44 Quit archibald ("CGI:IRC (EOF)")
20:14:15funmanthe 384kB are common to all AS3525, some models have an external 2MB (Clipv1, c200v2, m200v4), some 8MB (Fuze, e200v2)
20:14:37kugelamiconn: looking at the gcc source div and mod seems to be done in the same function
20:14:57minus8MB is already pretty much for embedded devices, isn't it?
20:16:20TheSeventhere are devices with 64MB
20:16:34 Join webguest22 [0] (n=4dff77ac@giant.haxx.se)
20:16:42TheSeven(ipod video and gigabeat s)
20:16:56 Quit webguest22 (Client Quit)
20:17:29funmani 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:50kugel32 too, I don't know of a 1MB one
20:18:09amiconniFP7xx 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:22funmanamiconn: and m200
20:18:28 Join Omlet05 [0] (i=omlet05@48.7-65-87.adsl-dyn.isp.belgacom.be)
20:18:33gevaertsand DAX
20:18:50funmanDAX has 2 MB according to tools/configure
20:19:11AlexP32 is the most common for Rockbox targets, no?
20:19:28saratogaHWCODEC are often 1 MB, but hte clip is the smallest target with mostly working SWCODEC
20:19:35TheSevenprobably yes, as all of the ipods (besides the 64mb one) have 32mb
20:19:46bluebrothermost swcodec target players are 32
20:19:46amiconnHWCODEC are *all* 2MB
20:19:53bluebrotherexcept the modded players ;-)
20:20:14funmanAlexP: true, 25 targets, 14 for 16, 3 for 8, 7 for 64, 5 for 2
20:20:19bluebrotherthe recorder was moddable, was it?
20:20:24saratogai found out the hard way that we build for an 8MB HWCODEC a while back
20:20:24amiconnYeah, except that of course
20:20:38TheSevenfunman: 7 for 64?
20:20:56funmanTheSeven: you forgot mrobe500, creativezvm (30 & 60gb), creative zen vision, and lyreproto1
20:21:01amiconnbluebrother: All archoses are moddable the same way. The architecture is almost the same, only storage and peripherals differ
20:21:19bluebrotheramiconn: ah, ok. Interesting to know :)
20:22:13JdGordon|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:34AlexPyeah, that's be funky
20:23:38AlexP*that'd
20:23:49TheSevenis it that hard actually?
20:23:49amiconnDetection isn't the problem. The memory layout needs to be changed in order to accomodate the variable end address
20:24:18bluebrotherthat's a problem or "just" work?
20:24:28TheSevenshouldn't it be rather easy to move the audio buffer towards the end of memory and dynamically detect its size?
20:24:32JdGordon|wasnt it discussed in the 07 devcon?
20:24:46amiconnRight 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:50amiconn)
20:25:08TheSevenargh, yes
20:25:20JdGordon|so put them at the start?
20:25:25JdGordon|before the core binary?
20:25:51TheSevenprobably impossible for iram (which wouldn't hurt), and it would probably need quite some boot process changes on some devices
20:25:54amiconnI 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:14TheSevenamiconn: ...or we need the bootloader to do that
20:26:27JdGordon|or we use dynamic linking for them :)
20:26:36amiconnForget dynamic linking
20:26:54amiconnTheSeven: There are several reasons why this won't work
20:26:55TheSevena more fancy rockbox.<whatever> format that includes things like load address and entry point in the header would also be nice for this
20:27:03amiconn(1) Old bootloaders
20:27:11TheSeven...then fix them
20:27:14bluebrotherport the linux libc! and malloc!
20:27:17*bluebrother hides
20:27:42amiconn(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:50kugelwhat's the problem with memmoving itself?
20:28:15TheSevenwhy don't we just boot a bootloader through the of bootloader then that loads the rest to the proper address?
20:28:19minusmoving code that's being executed
20:28:27amiconnkugel: 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:34TheSeven(or just some stub that does the moving magic in front of the main binary)
20:29:10pixelmahuh, 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:18minusoh god, i have so no clue of processors
20:29:19TheSevenwouldn't this only affect a handful of targets anyways?
20:29:48TheSeveni.e. ipod video and some archoses?
20:29:50AlexPyeah - video, modded archos
20:30:01TheSevendoing it for the ipod shouldn't be too hard
20:30:07bluebrotherh100 comes also as 16MB and 32MB
20:30:08TheSevenhow do the archoses boot?
20:30:16AlexPbluebrother: Is that the only difference?
20:30:19bluebrotherh115 vs. h120 / h140 to be exact
20:30:29AlexPbluebrother: h110 too :)
20:30:47*bluebrother facepalms
20:30:50 Join AEnima1577 [0] (n=clbarnob@nc652107a.cns.vt.edu)
20:31:08amiconnbluebrother: Those have more differences than just the ram size
20:31:18AlexPmicrophone IIRC
20:31:23amiconnPrecisely they have opposite s/pdif led polarity
20:31:24TheSevenand we only need that if we can't detect the mem size over usb, right?
20:31:27bluebrotheramiconn: releavant differences?
20:31:56bluebrotherhmm, ok. Could we detect that?
20:32:04AlexPbluebrother: Sure, by memory size
20:32:05amiconnSo 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:11gevaertsTheSeven: less builds
20:32:23bluebrotherAlexP: d'oh! Of course :)
20:32:31minusso, why do codec and plugins need to be at a static address?
20:33:08amiconnminus: Simplicity. A dynamic linker would be a lot of extra code
20:33:15TheSevendo they actually really need this, or are most of them position independent anyways?
20:33:34TheSevenprobably not as soon as iram is involved though
20:33:41amiconnThey're not position independent
20:34:06amiconnThat doesn't depend on iram
20:34:28bluebrotherwould a split audio buffer make sense?
20:34:37amiconnMaybe we could compile them as position independent code.
20:35:06gevaertsposition independent code would also open the door for loading multiple plugins at the same time at some point
20:35:09amiconnThat might be a worthwile experiment - I have no idea how much code size would increase by this
20:35:10TheSevenamiconn: 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:27amiconnYou're thinking arm only
20:35:32TheSevenoh yea...
20:35:39amiconnRockbox 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:11TheSeven...with one of them being exactly one target iirc?
20:36:17amiconnI'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:22amiconnno
20:36:56amiconnAll of them cover several targets. SH1 is all old archoses (6 targets not counting mods), Coldfire is irivers and iaudios (5 targets)
20:37:07amiconnMIPS is the Ondas (3 targets atm iirc)
20:37:13amiconnThe rest is ARM
20:38:55 Quit shai ("Leaving")
20:38:57TheSevenso it's the low-mem targets again that would get the binsize/ramsize hit, which would of course suffer most from it
20:39:38JdGordon|so?
20:39:44amiconnThe 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:46TheSevendid anyone ever check if we actually need this?
20:42:01TheSevenif we are lucky, we could just assume the bigger ramsize in the linker script
20:42:04amiconn"this" being?
20:42:12amiconnNo, we can't
20:42:26TheSevenand rely on address bus wrapping to make the codecs/plugins work
20:42:39TheSeventhe audiobuffer size would need to be autodetected of course
20:42:45TheSevenat least on s5l870x this would work
20:42:54gevaertsTheSeven: that may work on some systems, but I wouldn't rely on that for all of them
20:42:57amiconnow
20:43:10TheSevenwe could check it nevertheless
20:43:25TheSeveni actually saw apple doing this themselves on s5l8701
20:43:52*amiconn somehow doubts wrapping will work with the dram addressing scheme
20:44:33TheSevenwhy? i would expect the higher bits to just be ignored by the memory controller or memory itself
20:45:18TheSevennone of the targets that would need autodetection have an MMU, right?
20:45:45 Join n1s [0] (n=n1s@rockbox/developer/n1s)
20:46:05gevaertsyes, but position independent code has advantages beyond that
20:46:27gevaertsso I think it's worth investigating independently of the variable ram size anyway
20:46:42kugelamiconn: it would help on numerous targets, so it seems to be worth it
20:47:20pixelmakugel, JdGordon|: %Vi|0|8|-|-|1|-|-| should fail on mom
20:47:27amiconnTheSeven: Correct (no mmu)
20:47:34pixelmaerr... monochrome but it doesn't
20:47:55JdGordon|yes it should :)
20:47:55kugelmaybe
20:47:57amiconnI would expect the memory controller to filter out out-of-range addresses on less primitive SoCs than arm
20:48:02dionoeabertrik: would you be able to test a fixed patch for the clip playback problem ?
20:48:40TheSevenare the archoses really a "less primitive soc"?
20:49:07amiconnThat is the question
20:49:18amiconnIt's probably worth a test
20:49:57TheSeveni would expect all targets to either have an mmu or to allow wrapping
20:50:42amiconnStill, position independent code would have other advantages as well (like making the dynamic plugin buffer size idea easier)
20:50:55TheSevendoes the 2mb/8mb recorder have a different plugin buffer size?
20:51:02TheSeventhat would be a major problem...
20:51:35amiconnno
20:51:47amiconn32KB plugin buffer on all archoses
20:52:15 Quit HBK ()
20:52:24TheSevenso the only difference is the audio buffer size (and probably also audio buffer descriptor count)?
20:56:31amiconnThere is no such thing
20:56:47amiconnThe hwcodec playback engine is entirely different (still)
20:56:56TheSevenah yes, hwcodec of course :-/
20:57:20TheSevenwhat is the additional memory being used for then?
20:59:32JdGordon|pixelma: actually... is there really any reaosn why that shuoold fail... why cant we just ignore the last 2 params?
20:59:51amiconnTheSeven: All audio buffer
21:00
21:00:17TheSevenok, so you just meant that it doesn't have descriptors?
21:00:39pixelmaI seem to remember it failing for other %V or %Vl (maybe I'm confusing it with grey shades and RGB definitions though
21:00:41cowgardenwhy 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:16pixelmaJdGordon|: guess that ignoring would also work an be actually simpler (and you get a little more portability)
21:05:12pixelmaby 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:14JdGordon|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:58tomerskugel: ping
21:11:25 Quit archibald ("CGI:IRC (EOF)")
21:14:48kugeltomers: 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:37tomerskugel: Hi (sorry for the late response). Do you think I can commit the diacritic patch as it is now?
21:22:13kugelyea, go ahead
21:22:29tomersthanks. I'll play with the lru later on...
21:22:53tomersI'm available by email mostly. RL prevent me from IRCing too much
21:24:23tomerskugel: Do you think this feature should be part of the major features list?
21:24:34 Quit Grahack ("Leaving.")
21:25:28gevaertsgeneral diacritics support? I'd think so, yes
21:26:48pixelmadoes it affect drawing speed for non-diacritc text (much)?
21:27:06 Quit Thundercloud (Remote closed the connection)
21:27:53kugeltomers: you decide that :)
21:28:46tomersI think diacritic support affect European languages, Indian, Arabic and Hebrew. It is a major change for users who use these languages
21:30:34tomerspixelma: 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:57gevaertshm, 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:24gevaertsmaybe test_gfx will be good enough
21:37:34 Join jhggg2 [0] (n=4dfec8ce@giant.haxx.se)
21:37:43n1sUnhelpful: 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:16gevaertsif 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:46CIA-80New 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:01gevaertswhether this is actually noticeable is another question
21:47:50 Join Tomis2 [0] (n=Tomis@70.134.101.181)
21:49:11tomersOh, this is a *huge* bin size increase!
21:51:16JdGordon|thats not huge!
21:51:18JdGordon|someones sense of scale is off :)
21:51:42Tornewhy is it so much bigger on a coupe le of targets? :)
21:51:59tomers:-) gevaerts: How to test performance of it? What is test_gfx? Is it aplugin?
21:52:16Torne25kb on zen vision?
21:52:27gevaertstomers: it's a plugin, yes
21:52:33tomersTorne: No idea. Maybe different compilers. Maybe alignment of the buffer?
21:52:51amiconnugh
21:53:03tomersgevaerts: So it can give me a good measure of how changes to the code affect performance?
21:53:20gevaertstomers: 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:20n1stomers: what are diacritic characters and what languages use them?
21:54:37AlexPAnd it slows down for everything?
21:54:54tomersAlexP: http://en.wikipedia.org/wiki/Diacritic
21:54:57AlexPIt wasn't me that asked that
21:55:14tomersAlexP: sorry
21:55:50*gevaerts doesn't understand the delta
21:55:54tomersn1s: Read the array in firmware/drivers/diacritic.c, you can see what language contains diacritic characters.
21:56:11gevaertsAccording to bloat-o-meter it should be 2148 bytes for gigabeat f
21:56:45amiconnBinsize is
21:56:56amiconnBut there's extra ram size increase
21:57:08 Join AaronM [0] (n=Aaron@adsl-4-241-124.mem.bellsouth.net)
21:57:11amiconnHover over the delta to see the details
21:58:10AlexP15% seems more than "not much" of a performance decrease
21:58:36AlexPBut where is this? On all text?
21:58:48kugelwtf happened?
21:58:59gevaertsAlexP: it's a micro-benchmark. That doesn't necessarily mean a 15% slowdown for real text drawing operations
21:59:09AlexPOK
21:59:40kugelit just draws "Rockbox!" a million times or so
21:59:51pixelmadid someone test with a lot of text on an Ipod Video?
22:00
22:00:09kugelwhere does that increase come from!?
22:00:23gevaertskugel: static struct lcd_bitmap_char chars[SCROLL_LINE_SIZE]; is my guess
22:00:54kugelah, that seems like a good guess
22:01:45kugelit looks like the initial patch was less demanding
22:01:55tomersI'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:05gevaertslooks like about 10K for an LCD width of 240
22:03:00tomersWe can decide which languages to remove using #if 0
22:03:31gevaertstomers: can't struct lcd_bitmap_char be made more efficient?
22:04:01tomersNotice that in that array, we can use only 3 bytes per entry (Unicode is 0h-0xe01ef, and two more bits for flags).
22:04:22gevaertstomers: the ranges array is far from the big culprit
22:04:30gevaertsoh wait
22:04:31kugeltomers: the struct is already static, so it's saved between lcd_puts* calls
22:05:12tomerskugel: But the lookup for each character is still done twice. Doesn't it?
22:05:56kugelbtw, why (i = 0; i < SCROLL_LINE_SIZE && ucs[i]; i++) instead of (i = 0; i < strlen(str) && ucs[i]; i++) ?
22:06:51gevaertskugel: you mean calculate strlen(str) every time?
22:07:14tomerskugel: ucs[i] will be 0 on string end, so it acts like strlen
22:07:37tomersthe SCROLL_LINE_SIZE is just for buffer overflow protection
22:08:10kugelgevaerts: it loops over SCROLL_LINE_SIZE several times. that seems like a hige waste
22:08:28kugelah, i see, alriht
22:09:24kugelthe 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:54kugelunless 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:50Incognito-AWAYwhy is it that here
22:11:55Incognito-AWAYhttp://www.rockbox.org/wiki/CygwinInstallWithScreenShots
22:12:01bluebrotherwhy is what where?
22:12:15Incognito-AWAYi see the "add url" and i added it and click next
22:12:21AlexPIncognito-AWAY: To show people how to install cygwin
22:12:22Stephen_can themes from the gallery with the ccbysa license be edited and moved to the themes site ?
22:12:30Incognito-AWAYbut it says it cannot get the setup.ini"
22:13:04AlexPStephen_: sure, as that is the licence the theme site uses it should be fine :)
22:13:10Incognito-AWAYmore or less... "Unable to get setupini from <http://download.rockbox.org>"
22:13:22Incognito-AWAYerr setup.ini*
22:13:26Stephen_thanks again AlexP, just have to stay away from the graveyard right.
22:13:55Stephen_Incognito-AWAY, you have to pass a switch using cygwin, to bypass that.
22:14:03AlexPStephen_: 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:04Stephen_can't off the top of my head remember which.
22:14:14Incognito-AWAY:/
22:14:23AlexPStephen_, Incognito-AWAY: -x
22:14:27Incognito-AWAYdid that
22:14:36Stephen_yeah went through it myself as i know soap did too.
22:14:40Incognito-AWAYas it said at the top
22:14:41 Join stripwax [0] (n=Miranda@87.194.34.169)
22:14:52Stephen_ive updated some from the gallery just wasn't sure of the gallery
22:14:55 Quit bertrik ("De groeten")
22:15:03bluebrothertomers: is there a reason the struct lcd_bitmap_char chars is static?
22:15:07tomerskugel: Could you explain how the bitmap char could be 4 bit using bitfields, instead of 12
22:15:24gevaertsbluebrother: you don't want that on the stack
22:15:29kugelfirst, i meant byte :)
22:16:03 Quit stripwax (Client Quit)
22:16:04kugelwell, you need 1 bit each for the bools. then you have 30 bits left for width and base width
22:16:17tomerskugel: I said that ten minutes ago. We can use 3-byte for each entry.
22:16:41gevaertstomers: are you sure we will *never* need more than 256 pixels width?
22:16:54bluebrothergevaerts: hmm. Right.
22:17:36kugelgevaerts: I think that's reasonable to assume ;)
22:17:49 Join petur [50] (n=petur@rockbox/developer/petur)
22:17:51gevaertskugel: really?
22:17:56kugelyea
22:18:17tomersgevaerts: I think I took this limit from other function that handles with text. (bidi?)
22:18:18JdGordon|256pixels is per glypth or total?
22:18:26kugelglyph
22:18:28CIA-80New 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:05kugelif 128 is enough it could even be 2 bytes
22:19:49tomersgevaerts: Notice bidi_l2v() in putsxyofs().
22:19:49Incognito-AWAYStephen, i type setup.exe -X it brings up the box and everything
22:19:49gevaertskugel: 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:55Incognito-AWAYbut it still gets me to the "Unable to get setup.ini from <http://download.rockbox.org>
22:20:08kugelgevaerts: the max font we have is 40px I believe
22:20:19gevaertsthe max fond *we* have, yes
22:20:25kugeland that's a really huge one even for 640x480
22:20:54Incognito-AWAYnvm there we go
22:21:02gevaertskugel: yes, but you have good eyes
22:21:11JdGordon|gevaerts: sorry, ou're crazy... 128pixel width means about 4 chars on the screen even at 640x480...
22:21:56kugelon 3 lines!
22:22:07gevaertsJdGordon|: for the absolute widest character of the font
22:22:44JdGordon|I think 40 is a reasonable max.. even 64 to make it a round number
22:22:59peturyellow! red!
22:23:13gevaertstomers: I'm not sure what I'm looking at there
22:23:52tomers?
22:23:58*gevaerts did test compile. Why didn't he see that :\
22:24:09gevaertstomers: "Notice bidi_l2v() in putsxyofs()"
22:24:30bluebrothergevaerts: 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:40tomersgevaerts: 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:00gevaertstomers: I never questioned that one. I said pixels, not characters :)
22:27:37tomersoh... Actually I overlooked this consideration, so feel free to change
22:27:57tomersgevaerts: BTW nice catch
22:28:16 Nick Horschti is now known as Horscht (n=Horscht2@xbmc/user/horscht)
22:28:59gevaertsok, if everyone feels 255 pixels is really enough...
22:29:15 Join LambdaCalculus37 [0] (n=LambdaCa@rockbox/staff/LambdaCalculus37)
22:29:34n1sgevaerts: why the bool->char change, isn't a bool, just a char in disguise anyway?
22:29:52gevaertsn1s: 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:20amiconnA bool may be a char or an int, depending on architecture and optimisation level
22:30:27kugeln1s: bool doesn't have a defined size. it can typedef'd to anything
22:30:37n1samiconn: ah, fun
22:30:51amiconnSimilar fun as enums
22:31:03kugelwell, 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:25kugelif only there was a proper 24bit type
22:33:32kugel __attribute__((packed)) may give some savings too
22:34:27CIA-80New commit by 03gevaerts (r23744): Limit character width to 255 pixels ...
22:34:55gevaertsspeed is still the same on gigabeat at least
22:35:11bluebrotherthat two bool values can get combined as a bitmask or bitfield.
22:35:21gevaertsno bitmap yet. Not awake enough for that :)
22:36:39 Quit evilnick (Ping timeout: 180 seconds)
22:37:00gevaertskugel: 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:37kugelnot the flag, but the sign. that should make it a bit better readable :)
22:38:18kugelbut I agree in general. I already said it's not so much worth it anyway (it would probably also add code complexity)
22:38:42bluebrothergevaerts: still some yellow, and now some red too.
22:39:04amiconnThe diacritics support code looks broken
22:39:04gevaertsdamn, committed too many files :\
22:39:15bluebrotherhmm, in test_gfx ...
22:39:51 Join einhirn [0] (n=Miranda@p5DCC16BA.dip0.t-ipconnect.de)
22:39:58amiconnIt 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:17pixelmawhat's with the "Failed regex: line above the download table" (not the build table)?
22:41:25amiconntomers ^^
22:41:52pixelmahmm... the second " should be a few words earlier
22:42:15tomersamiconn: I am sorry, bu t I don't understand what '^^' means :-)
22:42:28amiconnReference two lines above
22:43:04CIA-80New 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:21mrtok1Q: Does someone know if profiling with gprof is working on the targets ? Or how could I manage to measure code performance?
22:44:38tomersamiconn: 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:09amiconntomers: Afaics it is completely unfixable in current form
22:45:51amiconnYou need to pre-render the current character with all its diacritics at least (in mono) and then finally draw that
22:46:48TaZzZwill avi files work on rockbox .. or only mpeg
22:46:54AlexPmpeg 1/2
22:47:06AlexPSee www.rockbox.org/wiki/PluginMpegplayer
22:47:12n1smrtok1: profiling should work with the profiling functionality built into rockbox (see wiki or docs/TECH for an intro
22:47:42AlexPTaZzZ: Also, avi is a container that can contain many different codecs
22:47:58TaZzZxvid ... is the file
22:48:01n1syou cna also devise your own benchmarks of course, may or may not give usefull info of course
22:48:18AlexPTaZzZ: Anyway, my previous answer stands
22:49:28amiconnHmm, actually it looks fixable, the inner loop needs to be done quitedifferently though
22:49:39tomersamiconn: Should I open FS bug for that?
22:50:12tomersI actually don't know how to fix it myself (unless I'll dive into that code, which takes time)
22:50:13amiconnAnd we'll need an extra buffer that can hold one char's bitmap
22:50:51mrtok1n1s: 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:01amiconnBasically 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:51mrtok1I mean: function x tooks 2 seconds with 80MHz core clock for example :o)
22:52:33amiconnAnd 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:33amiconnThere will be a hole
22:53:07n1smrtok1: 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:16amiconnSo 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:50mrtok1n1s: 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:22gevaertsactually, 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:00
23:02:32 Quit fyrestorm (Read error: 104 (Connection reset by peer))
23:03:31tomersgevaerts: I'll fix that, but not today (got to go).
23:03:40tomersamiconn: Fixing this will take some more time...
23:04:25 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk)
23:04:39gevaertstomers: 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:01tomersgevaerts: :-) 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:55amiconnIs 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:25Incognito-AWAYanother svn commit?
23:10:33Incognito-AWAYcause....it stopped....again
23:10:38kugelgevaerts: are you saying ram waste is not worth overtime? :)
23:11:06gevaertskugel: 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:43gevaertsamiconn: 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:33froggymanis 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:06kugelcan 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:19AlexPwhy?
23:27:26AlexPAren't they part of a theme?
23:27:26pixelmait's a theme setting, I thought?
23:27:49LloreanI'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:09Stephen_how do you clear that setting ?
23:29:58*bluebrother thinks that alternating row colors in lists would be a nice feature
23:30:28bluebrotherbackground color that is
23:30:32 Quit matsl (Read error: 145 (Connection timed out))
23:30:36AlexPnot text colour? :)
23:30:50bluebrotherno, text color is boring ;-)
23:30:59kugelI don't see filetype colours as a part of a theme, but rather a usability improvment or accesibility feature
23:31:19AlexPI see it very much as a theme thing
23:31:46kugelit uses colors, it must be part of a theme!
23:31:50LloreanFiletype colours is a theme thing that may be used as a usability improvement or accessibility feature, much like fonts are.
23:31:54kugelor colours, if you like
23:31:56AlexPkugel: don't be silly
23:32:16Unhelpfuln1s: i think so, and the bulk of codecs (for files in the test set) perform better under strict aliasing with -O3, also
23:32:29Lloreankugel: It primarily affects the visual or aesthetic appearance of the user interface without changing functionality - very much a theme value.
23:32:42bluebrotherwell, filetype colors is somewhat similar to filetype icons. So ...
23:32:46Stephen_anyone having problems with recording on e200v2 ?
23:33:13 Quit AEnima1577 ("Leaving.")
23:33:15kugelso, how I can I clear that easily? Only per deleting the file?
23:33:24AlexPThat is a different issue
23:33:28 Quit stripwax (Success)
23:33:36Unhelpfulfor 4.0.3 with -fstrict-aliasing -O3 is faster for ape, aac, flac, mpc, vorbis, and wma (on arm11)
23:33:44LloreanDoesn't it require a .cfg to *set* filetype colors?
23:33:49AlexPyes
23:33:59Unhelpfuli would *expect* the arm9 targets to perform similarly, they did with -fstrict-aliasing
23:34:00LloreanSo it seems perfectly reasonable it also requires one to clear it.
23:34:11Unhelpfulwithout rather
23:34:13AlexPbut if a theme sets it, it isn't easy to clear them but keep the rest of the theme
23:34:35pixelmaor clearing that lin in your config.cfg
23:34:56AlexPBut 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:57pixelmaline too
23:34:58*kugel can't complain
23:35:05 Part CaptainKwel
23:35:11kugelthe UI vp works the same way (apparently) :)
23:36:01 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk)
23:36:32LloreanAlexP: 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:48AlexPyep
23:37:09kugelit could be a reset_ft_colors.cfg in the theme dir if it's handled by a confi.cfg line
23:38:10Lloreankugel: That'd be a quick fix, but an actual menu entry would be nice.
23:38:32kugelwait, did you just say that? :p
23:38:43LloreanI'm pretty sure just having a blank entry instead of a .colours filename is all it takes to reset it.
23:39:05bluebrotherLlorean: why a menu entry? You can't set it via a menu either.
23:39:21kugelcustom statusbar brought up some awesome themes already imo
23:39:31Lloreanbluebrother: 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:50LloreanIt'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:58bluebrotherloading a theme could also implicitly reset the colors if they are not set by the theme
23:39:58LloreanSo 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:11kugelmaybe a special dir for various reset_* files, then a menu entry for browing that dir
23:40:18bluebrotherwell, most themes are pretty much bound to the font used.
23:40:33 Quit FlynDice (Remote closed the connection)
23:40:37LloreanFont size, but not necessarily font
23:40:48LloreanAnd viewports adds a great deal of flexibility in terms of choosing smaller fonts at least
23:41:01bluebrotherso for various settings it's questionable if it's a good idea to allow changing things separately.
23:41:24bluebrotherof course it's convenient to quickly change e.g. the font :)
23:41:37LloreanWell, 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:40LloreanSince they can conflict very easily
23:43:24kugelwe 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:10LloreanSounds 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:29kugel"MediaFlo for E200v2" would probably look extremely awesome with anti-aliased fonts (hint hint Unhelpful )
23:47:31pixelmawhy do targets without rsbs get that in the zip?
23:48:05pixelmaand it still works differently than RWPSs (which is a nice way IMO)
23:48:40pixelmaor at least it looks like it works differently seeing the result
23:48:55Stephen_kugel, you have a e200v2 right
23:48:58kugelno
23:49:31Stephen_ah, recording i think has a bug but i want to check before posting to fs
23:49:38kugelarg, people apparently don't use the "save theme settings" feature
23:49:59kugelmost themes don't reset the ui vp
23:50:18Lloreankugel: Maybe we could make the "save theme settings" feature export an additional line, and only accept themes with that line?
23:50:29AlexPkugel: Maybe most themes are from before that?
23:50:41LloreanI 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:47minusi wonder if you could possibly run gba roms on the fuze
23:50:47kugelui vp is older than the theme page IIRC
23:50:48LloreanAlexP: That feature predates the site, I think.
23:51:05LloreanEr, sorry
23:51:10LloreanSave theme settings, I mean.
23:51:11*Llorean doesn't know about the viewport
23:51:13pixelmaui vp?
23:51:39AlexPLlorean: I meant the ui vp
23:51:59kugelLlorean: that sounds like a good idea
23:52:03LloreanAlexP: Yeah, I realized that after I said it.
23:52:11Unhelpful"MediaFlo"?
23:52:33kugelyea
23:52:42kugelgo work on AAF, that theme badly needs it )
23:52:47kugel:)*
23:53:01Lloreankugel: 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:33pixelmaLlorean: 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:42kugelwell, adding the line by hand could interpreted as "I intentionally leave some settings out"
23:53:49AlexPThat is quite a good idea - it'll force reset settings that the theme authors don't know about/have forgotten about
23:54:32Lloreanpixelma: That could work. Require lines that are necessary to reset things.
23:54:40pixelmaor maybe for "all lines that have to be there if the creator used 'save theme settings'"
23:54:47LloreanIf 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:56kugeladding it by hand can really mean "I leave the icon set out, my theme works with any"

Previous day | Next day