| 00:00:30 | amiconn | Only then I noticed the new vieport clipping. Why is this necessary? It is only enabled for mr500 atm |
| 00:01:08 | amiconn | You also went back to the old, less efficient bounds checking in lcd_bitmap_transparent_part when adding this. Why? |
| 00:02:57 | kkurbjunW | amiconn: I enabled it and created it because I feel that if we expect clipping to be present it shouldn't be broken by viewports and the USB screen crashes the MR500 currently (and should crash the mr100 or at the least cause data corruption) |
| 00:03:13 | kkurbjunW | I can't comment on the less efficient method, if I did that it was by accident |
| 00:03:37 | | Part drf|laptop |
| 00:03:37 | amiconn | How is clipping broken by viewports? |
| 00:04:27 | | Part CaptainKwel |
| 00:05:27 | amiconn | Afair viewports are required to stay inside the display area. |
| 00:05:37 | amiconn | If we want to protect things from crashing, it would probably be better to clip viewports when they're set up rather than doing twice the work in each and every drawing function |
| 00:06:51 | | Join Jon [0] (n=jon@unaffiliated/jonsparks) |
| 00:06:57 | Jon | Hi |
| 00:07:13 | | Quit AEnima1577 ("Leaving.") |
| 00:07:36 | Jon | Hey |
| 00:07:43 | Jon | I have a question. |
| 00:08:21 | | Quit matsl (Read error: 145 (Connection timed out)) |
| 00:08:22 | Jon | I have several extra IPs and plenty of ram and such on one of my servers, and I'm wanting to know if RockBox wants its own IRC server. |
| 00:08:45 | Jon | I can just give an admin a shell and IP address to use. |
| 00:08:51 | Jon | Free |
| 00:08:51 | * | Hillshum thinks we've been happy with Freenode |
| 00:08:55 | Jon | k |
| 00:09:12 | Jon | I'm trying to find uses for my servers though lol |
| 00:09:24 | LambdaCalculus37 | Jon: You can provide a build server. |
| 00:09:29 | * | Hillshum lost |
| 00:09:35 | Jon | For what kind of use? |
| 00:09:39 | pixelma | or a download mirrir |
| 00:09:46 | Jon | I can do a mirror |
| 00:09:48 | pixelma | mirror too |
| 00:09:50 | LambdaCalculus37 | Jon: For building builds, of course. :) |
| 00:09:54 | Jon | =P |
| 00:10:00 | CIA-80 | New commit by pamaury (r23728): Add myself to COMMITERS. |
| 00:10:02 | Jon | what would it need? |
| 00:10:09 | LambdaCalculus37 | Jon: There's some info in the wiki. |
| 00:10:11 | Jon | Ok |
| 00:10:36 | LambdaCalculus37 | http://www.rockbox.org/wiki/BuildServer |
| 00:10:45 | LambdaCalculus37 | No wait... |
| 00:10:45 | LambdaCalculus37 | http://www.rockbox.org/wiki/BuildClient |
| 00:10:54 | gevaerts | pamaury: welcome! |
| 00:10:55 | LambdaCalculus37 | Jon: BuildClient, not BuildServer. |
| 00:11:05 | Jon | ok |
| 00:11:19 | pamaury | gevaerts: thanks ! |
| 00:11:21 | gevaerts | pamaury: one thing though, that file is expected to be in alphabetical order :) |
| 00:11:44 | Jon | Yeah, I can provide that |
| 00:11:51 | pamaury | gevaerts: I'll modify that ;) I missed this point :) |
| 00:11:52 | Jon | Do I get anything in return for donating? |
| 00:12:01 | Jon | =P |
| 00:12:47 | Jon | Hmm I don't usually setup stuff other than IRC-related things in ssh |
| 00:13:00 | Jon | I could just give someone a shell to set it up if you want |
| 00:13:14 | | Quit thegeek_ (Read error: 113 (No route to host)) |
| 00:13:32 | Jon | How do I get a rockbox repo in the directory? |
| 00:13:32 | Hillshum | It's not that hard |
| 00:13:39 | Jon | just download the svn? |
| 00:13:44 | Hillshum | svn |
| 00:13:46 | Jon | Ok |
| 00:13:49 | Jon | What link? |
| 00:13:54 | | Join nickwb [0] (n=nickwb@ppp118-208-168-84.lns20.bne4.internode.on.net) |
| 00:13:55 | Hillshum | Install subversion (svn), then repo it |
| 00:14:11 | Jon | k |
| 00:14:14 | | Join Rockbox [0] (n=alexthec@CPE-72-135-229-158.wi.res.rr.com) |
| 00:14:30 | LambdaCalculus37 | Jon: You get tons of free beer and your name in the credits. :) |
| 00:14:42 | Jon | xD |
| 00:14:46 | Jon | Cool |
| 00:14:47 | gevaerts | LambdaCalculus37: do we put build client people in credits now? |
| 00:15:00 | LambdaCalculus37 | gevaerts: I dunno. |
| 00:15:11 | CIA-80 | New commit by pamaury (r23729): Move myself in alphabetical order in COMMITERS. |
| 00:15:12 | | Part nickwb ("Cya") |
| 00:15:36 | Jon | What packages need to be installed via yum for this to work? |
| 00:15:47 | Rockbox | Hey I went to the Linux4nano Channel and No one was avalible soooo...Can i ask a quick question? |
| 00:16:08 | Hillshum | Rockbox: If related to rockbox... |
| 00:16:33 | Rockbox | Yeah. |
| 00:16:47 | Rockbox | What Drivers are missing for the 2G nano? |
| 00:16:58 | LambdaCalculus37 | Rockbox: USB. |
| 00:16:58 | Jon | Whats the command to get the repo copied (Sorry I never use svn for anything) |
| 00:17:15 | gevaerts | LambdaCalculus37: USB is there... |
| 00:17:26 | | Quit pamaury ("exit(*(int *)0 / 0);") |
| 00:17:36 | LambdaCalculus37 | gevaerts: I thought it was still booting into disk mode. |
| 00:17:45 | Hillshum | Jon: 'svn co svn://svn.rockbox.org/rockbox/trunk /path/to/repo/on/local/disk |
| 00:17:46 | gevaerts | ah, maybe. Not sure. |
| 00:17:51 | Jon | ok |
| 00:17:52 | Rockbox | No. |
| 00:17:55 | gevaerts | Rockbox: it mostly needs to be debugged |
| 00:17:56 | kkurbjunW | amiconn: the viewport offsets are added after the clipping takes place against the viewport definition |
| 00:18:03 | Rockbox | The USB is off. |
| 00:18:06 | Jon | Can I make up the /path/to/repo/on/local/disc/ par? |
| 00:18:08 | Jon | *part |
| 00:18:15 | Jon | Just make a dir for it? |
| 00:18:19 | Hillshum | Yeah |
| 00:18:21 | Jon | ok |
| 00:18:22 | Rockbox | Your computer doesnt detect the Ipod correctly. |
| 00:18:27 | kkurbjunW | amiconn, I agree for the most part, but people mess things up - and if you take that approach then clipping should not be done in the driver at all |
| 00:18:33 | Jon | Via root or a user? |
| 00:18:48 | Rockbox | root. |
| 00:18:52 | Jon | k |
| 00:19:00 | gevaerts | Jon: never root |
| 00:19:08 | Rockbox | Do you guys need dev help on that at all? |
| 00:19:15 | Jon | ok |
| 00:19:22 | gevaerts | Rockbox: if you don't know what you're talking about, please don't reply... |
| 00:19:22 | Rockbox | If you need help im up for it. |
| 00:19:57 | amiconn | kkurbjunW: Hence my suggestion to clip the viewport on setup. Smaller and faster... |
| 00:20:11 | amiconn | And it's messed up anyway |
| 00:20:12 | Jon | Hmm |
| 00:20:17 | Jon | root@s4 [~]# adduser rockbox |
| 00:20:17 | Jon | adduser: cannot lock shadow password file |
| 00:20:19 | kkurbjunW | amiconn, if we shouldn't do clipping at the viewport why are we doing clipping at all? |
| 00:20:21 | Jon | D= |
| 00:20:37 | Rockbox | So your suggesting that what Im saying is Incorrect? |
| 00:20:51 | | Nick linuxstb_ is now known as linuxstb (n=linuxstb@rockbox/developer/linuxstb) |
| 00:20:57 | Rockbox | Im not totally in knowledge of everything rockbox. |
| 00:21:26 | kkurbjunW | how is it messed up? |
| 00:21:31 | Rockbox | Ive been folowing Linux4nano-dev since it went up. |
| 00:21:35 | Rockbox | umm.... |
| 00:21:40 | Rockbox | Hard to explain. |
| 00:22:02 | Rockbox | Something with the USB drivers and the computers. |
| 00:22:33 | Rockbox | Its like the files will get detected and sometimes they wont. |
| 00:22:38 | gevaerts | Rockbox: talk to TheSeven for nanog2 things, or possibly linuxstb |
| 00:22:53 | kkurbjunW | amiconn, to clarify I'm asking why we even clip images in the driver |
| 00:23:27 | Rockbox | Okay. |
| 00:23:28 | kkurbjunW | I think if we are going to do clipping we should still check against the screen |
| 00:23:43 | * | linuxstb doesn't know the current state of the Nano2G |
| 00:23:43 | Hillshum | Rockbox: You don't run need to run svn as root, so yes |
| 00:24:03 | amiconn | kkurbjunW: Elements are allowed to be positioned (partially) outside the viewport, hence we need clipping |
| 00:24:27 | amiconn | Viewports in turn are not allowed to be positioned (partially) outside the screen |
| 00:24:41 | kkurbjunW | with lua the development bar is lower and you can cause all kinds of problems with memory overwritten - the clipping /was/ there to be against the screen, and with viewports that was broken |
| 00:25:19 | amiconn | Back when we had no clipping, things were very complex (all callers had to do bounds checking themselves) and error prone (back then viewports didn't exist yet) |
| 00:25:26 | kkurbjunW | amiconn, there is no method to check/define viewprorts we just write direct to the structure |
| 00:25:57 | kkurbjunW | agreed, it makes the callers complex |
| 00:26:04 | | Quit liar (Read error: 113 (No route to host)) |
| 00:26:13 | amiconn | lcd_set_viewport() |
| 00:27:03 | kkurbjunW | I was told set_viewport was called quite a bit- I originally had some bounds checking there, but it renders the screen wrong if the viewport is partially outside of the screen |
| 00:27:20 | linuxstb | kkurbjunW: I agree lua is a special case, but maybe that should just give an error if a program tries to set a viewport out of the screen. |
| 00:27:45 | kkurbjunW | linuxstb: but it gets messed up in other places, the usb screen is an example of that |
| 00:27:57 | linuxstb | How so? |
| 00:28:14 | linuxstb | That sounds simply like a bug in the usb screen. |
| 00:28:26 | JdGordon| | kkurbjunW: (no offense) the usb screen is a bad example... it needs to be fixed seperatly |
| 00:28:41 | JdGordon| | lua shuold call a viewport setter wrapper to maake sure the values are legal |
| 00:29:01 | kkurbjunW | I agree it needs to be fixed, my point is that if a mistake was made there and you have to do checking there, there's no saying that it won't continue to become more complex |
| 00:29:24 | linuxstb | kkurbjunW: But it's not "checking" as such, it's just calculating correct values to use. |
| 00:29:54 | kkurbjunW | and mistakes will be made in the future, it's the exact point that amiconn just said was the reason that clipping was added in the first place |
| 00:30:11 | amiconn | lcd_set_viewport() is certainly called less often than all drawing functions together. And even in a pathological case where it is called before each drawing function, there would be the same amount of checks as if we're doing it in the drawing functions |
| 00:30:33 | amiconn | But doing it in the drawing functions means much more binsize than doing it in the single setup function |
| 00:30:56 | CIA-80 | New commit by rob (r23730): Fix FS #10362 (flickering backlight when removing hold) by preventing multiple SYS_TIMEOUT events being posted the backlight thread. |
| 00:30:58 | linuxstb | kkurbjunW: You could say that about many functions in Rockbox - the principle (IIUC) has always been to rely on the calling code being correct, rather than having many checks "just in case". |
| 00:31:01 | kkurbjunW | amiconn: if you clip it there the screen won't render properly, but it will at least prevent memory corruption |
| 00:31:11 | amiconn | yep |
| 00:31:54 | kkurbjunW | if you did a check there I would be fine with that, I just don't like the idea of memory corruption |
| 00:32:01 | amiconn | I know it won't render properly (that only applies to left/top clipping btw - right/bottom won't matter), but then such viewports are broken anyway |
| 00:32:01 | | Join Jake [0] (n=60185bdd@giant.haxx.se) |
| 00:32:32 | kkurbjunW | I was just lucky that I was able to pin the source of the corruption down, it was actually crashing in the thread functions. |
| 00:32:43 | JdGordon| | boomshine is too easy :( |
| 00:34:28 | | Part Rockbox |
| 00:37:12 | | Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) |
| 00:37:17 | kkurbjunW | amiconn, I agree, it would be fine to do it in set_viewport. At least it prevents the corruption. I could care less if the viewport is rendered wrong if the caller is expected to make sure it is setup properly. Like I said, that's what I originally had, but I decided to do a more complete clipping implementation - the actual impact of the viewport clipping is not noticeable on the mr500, but I can't speak for the slower targets. |
| 00:37:51 | kkurbjunW | (I even emasured the current and it was too small for me to measure) :) |
| 00:38:07 | kkurbjunW | measured that is |
| 00:41:27 | linuxstb | kkurbjunW: Why not simply panicf() instead of clip, if the purpose is to catch errors in apps/ code? |
| 00:43:43 | | Nick Jon is now known as Jon[Newnick] (n=jon@unaffiliated/jonsparks) |
| 00:43:52 | Jon[Newnick] | NOW THEY WILL NEVER FIND ME |
| 00:44:48 | | Quit Hillshum (Remote closed the connection) |
| 00:44:51 | kkurbjunW | linuxstb: the reason I chose to implement full clipping is because I could see it being useful in the future if any additional features were added. I'm not saying that it should be done, but if you had the ability to clip viewports in the driver you could create things like screen/viewport transitions (for example the wps slides in while the menu slides out). |
| 00:45:00 | Mode | "#rockbox +o JdGordon| " by ChanServ (ChanServ@services.) |
| 00:45:05 | kkurbjunW | and I wanted to prevent memory corruption |
| 00:45:37 | Mode | "#rockbox -o JdGordon| " by ChanServ (ChanServ@services.) |
| 00:46:04 | kkurbjunW | and it made the screen render as (potentially) desired even though currently the expectation is that viewports are withing the screen. |
| 00:46:22 | linuxstb | Adding things "just in case they're needed in the future" isn't what's generally done either... |
| 00:46:39 | | Quit DerPapst ("Leaving.") |
| 00:46:43 | kkurbjunW | linuxstb, I think clippins or bounds checking is better than a panicf in general too by the way |
| 00:48:17 | linuxstb | But that means bugs in apps/ code will go unnoticed. |
| 00:48:29 | kkurbjunW | I don't care how it is done, but a panicf doesn't seem necessary if you are doing the checks anyway. you can add a logf in the simulator |
| 00:48:38 | kkurbjunW | so that when you run it gives a warning |
| 00:48:54 | | Join liar [0] (n=liar@83.175.83.185) |
| 00:49:12 | kkurbjunW | or a printf or a debugf or whatever you prefer, but I don't think a panic is necessary |
| 00:50:22 | linuxstb | But the API for viewports is that the viewport passed to the function MUST be within the screen. apps/ code writers need to be responsible for that. |
| 00:50:24 | | Join gTanzola [0] (n=me@c-98-235-156-243.hsd1.pa.comcast.net) |
| 00:50:59 | kkurbjunW | HD parking is not very pleasant for a potential innocent mistake |
| 00:51:25 | linuxstb | But it shouldn't happen in committed code. |
| 00:51:59 | * | linuxstb doesn't understand why it's hard to define/calculate correct viewports |
| 00:52:25 | kkurbjunW | it did and still does :), and probably will again, not everyone has a mr500/100 remote |
| 00:52:35 | | Join Hillshum [0] (n=ubuntu@75-165-228-164.slkc.qwest.net) |
| 00:52:50 | kkurbjunW | so someone does a commit and starts causing panic's on a target they don't even own |
| 00:52:53 | | Quit liar (Client Quit) |
| 00:53:17 | kkurbjunW | doing a debug message in the simulator seems reasonable without causing a panic on the target |
| 00:53:20 | linuxstb | Then that person will quickly get yelled at. |
| 00:53:46 | JdGordon| | if they dont own the target.. how cna they get yelled at? |
| 00:53:52 | kkurbjunW | there are only 3 devs that I am aware of that have an mr500 to my knowledge so quick is a relative term |
| 00:54:05 | linuxstb | JdGordon|: For writing buggy code... |
| 00:54:15 | JdGordon| | its not buggy... its broken on that target |
| 00:54:17 | JdGordon| | big difference |
| 00:54:38 | linuxstb | Huh? |
| 00:56:06 | kkurbjunW | linuxstb, I think I am the only dev that regularly uses the mr500, ( gevaerts correct me if I'm wrong) and I don't always run the latest svn builds. The commit was made a long time before I noticed the problem |
| 00:56:25 | kkurbjunW | and I would not want to see a panic on the target |
| 00:56:48 | linuxstb | What's special about the mr500/100 remote that means this particular bug is only there? |
| 00:57:02 | amiconn | linuxstb: The remote is 79x16 ... |
| 00:57:06 | kkurbjunW | the usb logo is large and the screen is small |
| 00:57:35 | * | linuxstb still doesn't understand... |
| 00:57:40 | linuxstb | So the logo is larger than the LCD? |
| 00:58:02 | kkurbjunW | the logic wouldn't work on that screen at all with the statusbar enabled |
| 00:58:30 | kkurbjunW | you would end up with viewports that are outside of the screen space even if the logo was 1 pixel high |
| 00:59:04 | kkurbjunW | (and you had a 8 point font defined) |
| 00:59:12 | kkurbjunW | which is unlikely on the mr500 |
| 00:59:15 | amiconn | Imo the statusbar in its current form is essentially useless on the mrobe remote |
| 00:59:45 | amiconn | And with current form I mean anything that its only separated horizontally |
| 00:59:58 | kkurbjunW | even 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:20 | cendres | hello |
| 01:00:27 | kkurbjunW | I agree though, the statusbar is pretty pointless on the mrobe remote |
| 01:00:39 | cendres | i have an iriver h300. when creating a vfat filesystem, is it best to use a 32 bit FAT size? |
| 01:01:41 | amiconn | I agree with kkurbjunW that crashing on unusual parameter combinations is bad. I said that myself several times, regarding metadata reading in codecs |
| 01:01:54 | amiconn | But if we do a check, it should be done with minimal impact |
| 01:02:37 | * | amiconn will probably look into that and try to bring back the more efficient clipping order as well |
| 01:03:17 | linuxstb | amiconn: That's different though - that's dealing with untrusted input. Unless we don't trust apps/ code ;) But yes, I can see how these problems can easily happen... |
| 01:03:39 | amiconn | The current inconsistency isn't nic eeither - it won't crash on mr500 but on all others |
| 01:04:08 | | Quit robin0800 (Remote closed the connection) |
| 01:04:12 | amiconn | And enabling all the extra code isn't nice on lowmem targets |
| 01:04:18 | pixelma | amiconn: with an sbs you could even do a vertical statusbar but that's a different story |
| 01:04:49 | | Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
| 01:05:43 | amiconn | Does that actually work? I mean, you can define one that way, but will the lists use it properly? |
| 01:06:24 | amiconn | linuxstb: Viewport sizes may come from user input (.wps, .sbs, ...) Safeguarding in the driver will then be more efficient than letting all callers do it |
| 01:07:24 | JdGordon| | it would be pretty silly if the lists didnt work like that |
| 01:07:26 | pixelma | JdGordon|: trying "pure" %Rf in a hwcodec sim gives me a bunch of numbers till the end of the viewport - which doesn't happen with the built-in bar, using it in a conditional seems to work but I can't tell if the correct branch is used |
| 01:07:58 | pixelma | read: the correct frequency is displayed |
| 01:08:11 | JdGordon| | so thats good? |
| 01:08:22 | pixelma | no |
| 01:08:24 | JdGordon| | IMO it *should* display 44.100 if thats what it is |
| 01:09:04 | JdGordon| | the built in bar is not an orcale for this |
| 01:09:12 | pixelma | but it's 45x5096... where x can't be read because the channels icon is displayed over it |
| 01:09:32 | JdGordon| | ok, thats fubar :) |
| 01:10:01 | JdGordon| | but, it shuold be used as a conditional to have it show 44 or 22 or whatever |
| 01:10:09 | pixelma | yeah |
| 01:11:39 | pixelma | I was surprised that the hwcodec statusbar is different to the swcodec one there - the former displays just the number (before comma) in sysfont and the latter uses icons, though it looks like both take the same space |
| 01:12:06 | pixelma | the icons show smaller numbers and a k there |
| 01:12:18 | Jon[Newnick] | Back |
| 01:12:23 | Jon[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:30 | Jon[Newnick] | rockbox@s4 [~]# svn co svn://svn.rockbox.org/rockbox/trunk /home/rockbox/svn/repo |
| 01:12:30 | Jon[Newnick] | -bash: svn: command not found |
| 01:12:30 | Jon[Newnick] | rockbox@s4 [~]# |
| 01:13:12 | Jon[Newnick] | Do I need a certain package or something? |
| 01:13:16 | amiconn | JdGordon|: Imo there should be a way to use built-in bitmaps, the same way as there is a set of built-in list icons |
| 01:13:45 | | Join CaptainKwel [0] (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) |
| 01:13:54 | pixelma | JdGordon|: I could probably "unify" both, just don't know which is better (the icons make it more clear that it is the frequency) |
| 01:14:39 | | Nick CaptainKwel is now known as CaptainKewl (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) |
| 01:14:40 | pixelma | but are smaller and harder to distinguish and one additional bitmap (although *only* one) |
| 01:14:49 | Unhelpful | i know it would end up being a codeclib piece, and still end up duplicated in any codec that needs it, but perhaps it would be worth determining which methods are optimal for these tasks for various cores used on rockbox targets, and having one "best" function for doing them |
| 01:15:32 | pixelma | Jon[Newnick]: looks like you are missing subversion then |
| 01:15:56 | Jon[Newnick] | How do I install it? |
| 01:16:03 | JdGordon| | amiconn: I'd agree if there was ever a request from the themer commuinty for this... but to my knowlegde there hasnt... and there is plenty of places in the WPS where those icons would be useful |
| 01:16:18 | Unhelpful | Jon[Newnick]: depends on which distribution you use |
| 01:16:30 | Jon[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:20 | Jon[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:39 | stripwax | Unhelpful - (is that regarding the gsoc page?). i'd have thought the individual packing/framing formats make a generic bitstream/unpacker pretty difficult (e.g. ogg vorbis) |
| 01:20:58 | | Join CaptainKewl [0] (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) |
| 01:21:12 | | Nick Jon[Newnick] is now known as Jon (n=jon@unaffiliated/jonsparks) |
| 01:22:07 | Unhelpful | stripwax: not regarding gsoc. i'm tuning compiler flags for codecs on arm, and just noticing how some codecs with similar methods of operation perform *very* differently. |
| 01:23:08 | Unhelpful | and i don't mean a generic unpacker-for-all-bitstreams, but a generic for handling a stream of bits - ie, open, fetch next n bits, peek at next n, discard next n, skip to next byte/word boundary etc. |
| 01:23:10 | stripwax | Unhelpful - are you profiling along the way also? that would be cool |
| 01:23:13 | amiconn | JdGordon: I am not the themer community, but I want my statusbar to continue working properly. The built-in one doesn't need everything (e.g. it doesn't need playback state or recording - obviously you can't play back or record without disk access), but it still needs some gfx (disk activity for soft-led, battery, charger icon etc) |
| 01:24:29 | Unhelpful | similarly, on top of that you could build a generic for extracting canonical-huffman-coded data from the top of the bitstream |
| 01:25:23 | Jon | Ugh I friggin hate my server |
| 01:25:23 | stripwax | Unhelpful - yeah, but the vorbis code 'cleverly' (not actually sure how clever it really is) incorporates a bunch of that stuff inline for certain cases for performance (decode_packed_block); as well as handling another layer of indirection so that separate buffers are handled as if they are one long contiguous buffer w/o copying mem |
| 01:25:31 | Jon | I'm gonna just install this to a vserver |
| 01:26:18 | stripwax | Hm - is it expected that pictureflow keeps the disk spinning down, spinning up, spinning down, .. constantly? |
| 01:26:40 | Unhelpful | stripwax: bit-string fetching etc could still be inlined... ie, #include <generic_bitstream.h> |
| 01:27:03 | stripwax | That's on latest build (not sure if behaviour changed at all recently tho) |
| 01:27:08 | amiconn | pictureflow has to spin up the disk if it has to fetch uncached tiles |
| 01:27:11 | stripwax | Unhelpful - true |
| 01:27:29 | stripwax | amiconn - should it do that if I'm not scrolling the tiles? |
| 01:27:42 | amiconn | Probalby not |
| 01:27:45 | Unhelpful | stripwax: um, yes, the (memory) cache needs some optimization, it will presently update the memory cache on each slide change, as it rather stupidly forces loading as many tiles as possible in each direction from the current slide. |
| 01:27:53 | stripwax | Mm-hmmm.. |
| 01:28:12 | stripwax | Unhelpful - it's doing it without slide changes, I'm just looking at it |
| 01:28:14 | Unhelpful | if you have just stopped scrolling and the cache is not full, it will keep loading |
| 01:28:45 | stripwax | Unhelpful - loading's fine - but rather it was constantly spinning up, down, up, down, the disk .. |
| 01:28:45 | Unhelpful | if it's just sitting there loading slides over and over, congratulations, you've found a bug in my buggy cache code :) |
| 01:29:27 | stripwax | :) |
| 01:29:29 | | Quit Hillshum (Remote closed the connection) |
| 01:29:47 | stripwax | I don't know what it's doing, to be honest. Doesn't seem to spend any time at all between spin up/downs doing any actual loading. |
| 01:30:35 | Unhelpful | what i'd like to do is only force centering the cache when you're scrolling at speed. if you're flipping a slide at a time, it ought to let you get up to where there's just one off-screen slide cached, and then recenter when you bring that one into view. |
| 01:31:53 | Jon | Is there anything I can help with other than hosting? |
| 01:32:02 | Jon | *other than svn repo |
| 01:32:08 | Jon | I can provide hosting or something |
| 01:32:15 | Jon | For a mirror, idk |
| 01:33:21 | stripwax | Unhelpful - that would be good. also, the maximum scrolling velocity seems too low (at least on ipod video) ; really not possible to just fling it way way forward, you end up seeing all covers at a fairly graceful speed - but could that be also because of caching/loading? |
| 01:35:15 | | Quit Thundercloud (Remote closed the connection) |
| 01:35:27 | stripwax | Unhelpful - re bitstream - yeah, I think the really basic stuff (as you say, peek n bits from a contiguous bitstream, extract n bits from a contiguous bitstream) should be implemented once per platform. endianness (of the bitstream, rather than the target platform) gets messy unless most of the codecs actually pack in the same ways |
| 01:37:58 | pixelma | JdGordon: I think I have everything prepared now for all depths and the Archos one and all parse correctly - just want to test on my targets and can likely commit tomorrow (half past 1 AM here...) |
| 01:38:18 | pixelma | the current time that is ;) |
| 01:39:38 | pixelma | I wonder if the M:Robe remote should get a seperate one but that can be the next step because it is not better currently |
| 01:45:18 | | Join Strife89 [0] (n=michael@adsl-146-208-69.mcn.bellsouth.net) |
| 01:46:05 | | Join MethoS- [0] (n=clemens@134.102.106.250) |
| 01:49:13 | pixelma | it probably has to - otherwise there would be at least overlapping viewports if not ones outside the screen |
| 01:49:52 | | Quit Jon ("IceFyre IRC Client v.2.1.2") |
| 01:52:38 | JdGordon | 1am is a good time to commit! |
| 01:53:10 | | Join Strife1989 [0] (n=michael@adsl-146-208-69.mcn.bellsouth.net) |
| 01:53:17 | | Quit Strife1989 (Read error: 104 (Connection reset by peer)) |
| 01:54:20 | | Part toffe82 |
| 01:55:54 | JdGordon | amiconn: no, there is a big difference between icons being needed, and icons being a nice addition, which is what they are... in fact I cant belive that you would prefer an imprecise icon instead of 55% for battery levels... |
| 01:57:12 | amiconn | The current icon has 16 levels, which is precise enough for battery display, and it has the advantage that it is immediately recognisable as being the battery status, unlike a simple number |
| 01:58:05 | | Quit mt (Read error: 110 (Connection timed out)) |
| 01:58:36 | | Join Hillshum [0] (n=ubuntu@75-165-228-164.slkc.qwest.net) |
| 01:58:49 | amiconn | And it can display the fact that the battery is being charged at the same time |
| 01:59:36 | Tomis | what more do you need to know, when the battery level is red and 2 pixels wide, it's time to plug the thing in |
| 01:59:40 | JdGordon | I will dispute the 2nd bit |
| 01:59:50 | JdGordon | you need to wait for the animation to change frames to know |
| 02:00 |
| 02:00:05 | amiconn | Even if you select numeric display, the statusbar will switch to graphical display when charging |
| 02:00:15 | Unhelpful | stripwax: the jpeg plugin doesn't need to worry about endianness, as it reads one byte at a time. finding a way 'round that would be nice-to-have also :) |
| 02:00:49 | JdGordon | once again... you are free to make your sbs do whatever the heck you want it to do |
| 02:00:56 | amiconn | Only on monochrome. On greyscale and colour displays you can really see both things at the same time (because the charging part is grey and the level is black) |
| 02:01:40 | JdGordon | 55%+ doesnt give the same info? |
| 02:01:47 | Tomis | lol |
| 02:01:50 | amiconn | It doesn't fit |
| 02:01:58 | JdGordon | which is easier on the battery than redrawing the animation |
| 02:02:21 | amiconn | And it still doesn't convey that it's the battery status |
| 02:02:45 | amiconn | I was talking about the necessity to support built-in gfx. |
| 02:02:49 | Tomis | the battery's at 1/2 bar with a little power icon, it's the same information |
| 02:03:37 | | Quit Hillshum (Remote closed the connection) |
| 02:04:14 | JdGordon | Right, and I'm saying that if it was ever requested then it would have been added |
| 02:04:22 | amiconn | And I don't see why *I* should fix a feature which is currently working and you intend to *knowingly* break |
| 02:04:30 | JdGordon | but you get 100x more flexibility by allowing loadable graphiocs |
| 02:04:59 | JdGordon | there is exactly one time when you cant hit the disk... and for that one time its not worth the effort when you can live with 55%+ especially wqhen it DOES fit there |
| 02:05:33 | amiconn | Charger connection? USB power? Disk activity? |
| 02:05:44 | amiconn | It's not only the battery gfx... |
| 02:06:10 | | Quit stripwax (Read error: 145 (Connection timed out)) |
| 02:06:51 | JdGordon | the only info you need on early use is batt level, charing yes/no and disk access... and RTC is a nice bonus... all that DOES fit |
| 02:09:21 | amiconn | And will look unrecognisable without gfx... |
| 02:09:59 | Tomis | even text is just a series of graphics that need to be loaded and displayed |
| 02:10:09 | JdGordon | you're smart.. you'll figure out what the numbers mean pretty quickly |
| 02:10:46 | Tomis | why are we arguing against having clear concise imagery that conveys it's meaning instantly? |
| 02:15:58 | | Quit kkurbjunW (Remote closed the connection) |
| 02:18:02 | | Join kkurbjunW [0] (n=karlk@12.41.166.9) |
| 02:19:22 | JdGordon | hmm... maybe we can do this another way... but you have to accept the red delta for it |
| 02:22:56 | JdGordon | *maybe* we can cut down alot of the current bar logic and keep it in the core as is.. and use it like a widget again |
| 02:23:00 | JdGordon | seperate from themes |
| 02:23:28 | JdGordon | that is a damn big waste though |
| 02:24:58 | * | JdGordon really cant tihnk of any screen except early usb which *really* needs the bar displayed agains tthe users wish |
| 02:25:05 | JdGordon | or because it hasnt loaded yet |
| 02:25:21 | amiconn | It might be useful to have a generic method to cut parts from a bitmap which are proportional to some value |
| 02:25:28 | | Join bzed_ [0] (n=bzed@devel.recluse.de) |
| 02:26:17 | amiconn | This would save quite a number of bitmaps in any theme that wants to display battery status or volume with high precision |
| 02:27:20 | amiconn | For a nice battery icon you would only need two bitmaps - the battery frame, and the inner part, which would be cut according to the level |
| 02:27:43 | Tomis | or just the battery full and the battery empty |
| 02:27:53 | JdGordon | yes, and that I'd be happy for someone to add |
| 02:28:09 | | Quit rasher (lindbohm.freenode.net irc.freenode.net) |
| 02:28:09 | NSplit | lindbohm.freenode.net irc.freenode.net |
| 02:28:09 | | Quit dionoea (lindbohm.freenode.net irc.freenode.net) |
| 02:28:09 | | Quit FlynDice (lindbohm.freenode.net irc.freenode.net) |
| 02:28:09 | | Quit Xerion (lindbohm.freenode.net irc.freenode.net) |
| 02:28:09 | | Quit jordan` (lindbohm.freenode.net irc.freenode.net) |
| 02:28:09 | | Quit shodanX (lindbohm.freenode.net irc.freenode.net) |
| 02:28:41 | | Join rasher [50] (n=rasher@rockbox/developer/rasher) |
| 02:28:41 | NHeal | lindbohm.freenode.net irc.freenode.net |
| 02:28:41 | NJoin | dionoea [0] (n=dionoea@yop.chewa.net) |
| 02:28:41 | NJoin | FlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) |
| 02:28:41 | NJoin | Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) |
| 02:28:41 | NJoin | jordan` [0] (n=jordan@78.235.252.137) |
| 02:28:41 | NJoin | shodanX [0] (n=shodanX@jazz.informatik.uni-erlangen.de) |
| 02:28:44 | JdGordon | but this early usb bar is causing headaches... if it really is the only user of a forced internal bar then we should fix the problem a different way |
| 02:28:44 | amiconn | This cutting would probably need to work in various directions, l/r/u/d at least |
| 02:29:13 | amiconn | It's early usb and charging screen (the latter obviously not on Ondios) |
| 02:29:26 | JdGordon | charging pre rockbox loaded? |
| 02:29:38 | amiconn | Yes, with the disk completely unpowered |
| 02:29:50 | JdGordon | fine, is that the only two though? |
| 02:29:57 | amiconn | Or not - this *is* in rockbox |
| 02:30:01 | JdGordon | both could draw the animations themselves |
| 02:30:15 | JdGordon | if its in rockbox then we should be using the users theme |
| 02:30:34 | amiconn | It's rockbox running from rom (otherwise we would never get into this state - the archos firmware would handle it) |
| 02:31:01 | amiconn | No disk access at this point - the disk is completely unpowered |
| 02:31:55 | amiconn | This is for two reasons (a) fastest possible charging, (b) low-bat situation: the battery might be so low that starting the disk will crash/stop the cpu |
| 02:32:18 | amiconn | The latter is important on the v1 as charging is software controlled - no cpu, no charging... |
| 02:32:55 | JdGordon | yes yes, fine... but if thats it then you can have your animations, and I can have my nice clean API and everyone is happy |
| 02:33:16 | amiconn | hmm? |
| 02:33:27 | * | amiconn doesn't seem to understand |
| 02:34:08 | JdGordon | the current statusbar can be stripped to the essentials, and only called for those 2 early access screens |
| 02:34:20 | JdGordon | otherwise it wont be shown because your theme will be used |
| 02:34:47 | amiconn | Yes, A few things can be stripped, like play status and probably volume |
| 02:34:52 | JdGordon | that of course makes no sense either |
| 02:35:10 | JdGordon | why isnt it a list with charge level, status, time, disk access all layed out nicely |
| 02:35:21 | JdGordon | much more readable than a 8 pixel high animation |
| 02:35:28 | JdGordon | and much smaller code |
| 02:35:42 | | Quit Stephen_ ("Leaving") |
| 02:36:05 | amiconn | perhaps... |
| 02:36:13 | JdGordon | even a fancy full width progressbar! |
| 02:36:28 | amiconn | But then the early usb screen and the in-rockbox usb screen will be fairly different |
| 02:36:32 | JdGordon | so? |
| 02:36:51 | amiconn | Well, unless you want to change the main usb screen as well |
| 02:37:07 | JdGordon | maybe |
| 02:37:07 | amiconn | Do you have an ipod? |
| 02:37:12 | JdGordon | no reason why not |
| 02:37:18 | JdGordon | neither of my ipods are functional atm |
| 02:37:28 | JdGordon | my mini2g sort of is.. sometimes |
| 02:37:39 | amiconn | Did you compare the OF's USB screen and diskmode USB screen? |
| 02:38:01 | amiconn | They're not identical, but apple tried to make them as similar as possible |
| 02:38:13 | JdGordon | thats nice.. but we arnt apple |
| 02:38:28 | Tomis | if you can make things nice, you should |
| 02:38:38 | JdGordon | inside rockbox it should be as pretty as the user wants... early rockbox should be simple small code |
| 02:38:41 | amiconn | They're *very* similar on greyscale ipods; on colour targets they're a bit more different as the diskmode version is monochrome |
| 02:38:43 | | Join Blue_Dude [0] (n=chatzill@rockbox/developer/Blue-Dude) |
| 02:39:09 | amiconn | Sure we're not apple, but *you* seem to be caring about looks (hmm, not always though) |
| 02:39:29 | JdGordon | I really just want a clean API and small codebase |
| 02:39:46 | JdGordon | have we swapped? :) |
| 02:40:08 | * | amiconn doesn't think so |
| 02:40:34 | JdGordon | its usually me arguing for prettyness and you arguning for no wasted code :) |
| 02:41:04 | amiconn | I don't deem built-in gfx a waste - I'd use them for the main statusbar as well |
| 02:41:09 | | Quit bzed (Read error: 111 (Connection refused)) |
| 02:41:09 | | Nick bzed_ is now known as bzed (n=bzed@devel.recluse.de) |
| 02:41:26 | * | amiconn also uses the built-in list icons - on almost all of his targets... |
| 02:42:11 | JdGordon | the waste was adding the code to the skin engine to display them.. when on most targets there is no point because those images are too crap and small |
| 02:42:24 | JdGordon | but anyway.. we are sort of in agreement here |
| 02:42:48 | amiconn | Making the usb screen (and charging screen) display the status in an all-different way may be in fact a good idea - the question is how it should look, and how such a screen fits into theming |
| 02:43:48 | amiconn | JdGordon: I don't think it would need much code - built-in gfx are essentially bitmaps which don't need to be loaded because they're preloaded |
| 02:44:22 | JdGordon | just a list.. or something.. I tihnk that info is more important than the usb plug bitmap |
| 02:44:46 | Blue_Dude | Nobody else wants to weigh on on the direction of the main audio engine? I'm a little surprised.... |
| 02:44:49 | JdGordon | not even a list.. maybe just a progress bar at the bottom under the image for charge state |
| 02:45:01 | JdGordon | Blue_Dude: you didnt use the improtant key words |
| 02:45:14 | Blue_Dude | Which are? |
| 02:45:30 | JdGordon | settings, delta, break, etc... |
| 02:45:35 | amiconn | JdGordon: For USB there's also disk activity, plus the connected thingies |
| 02:45:43 | JdGordon | sure |
| 02:45:47 | Blue_Dude | Oops, OK. |
| 02:46:20 | JdGordon | Blue_Dude: it usually comes down to people not replying because they trust you know what you're doing... or you know more than we/they do... |
| 02:46:32 | JdGordon | unless its something pretty contentious, there is no argument |
| 02:46:47 | Blue_Dude | In my opinion, the quality delta of the current pcmbuf scheme is negative, important features are broken, and settings are imperfectly supported... |
| 02:47:32 | JdGordon | and seen as you are the only one to really look at it recently, we will accept that opinion |
| 02:47:48 | amiconn | Blue_Dude: Better means just better as long as all people involved have the same definition of better. |
| 02:47:49 | Blue_Dude | The choice is patch it or rewrite it. Patching is quick, cheap and ugly. Rewriting is long, expensive and potentially really good. |
| 02:47:51 | JdGordon | a software mixer has been on the wishlist for quite a while |
| 02:50:15 | Blue_Dude | I've tried patching, but the choice is still there. Going any further means committing to one or the other. |
| 02:50:44 | JdGordon | if you have the energy... and you tihnk its worth it.. go the rewrite |
| 02:51:41 | * | JdGordon fears charcell is going to get in the way of his clean API :< |
| 02:52:30 | Blue_Dude | That's the problem. It's going to be expensive. Expensive enough that people are going to howl and want the old way back because it costs too much. |
| 02:52:53 | JdGordon | how expensive? |
| 02:53:10 | Blue_Dude | 64k at minimum and a boosted thread. |
| 02:53:12 | JdGordon | will it be able to work on all swcodec targets? the clip has 384KB RAM iirc |
| 02:53:28 | Blue_Dude | Only if I steal from its pcmbuffer first. |
| 02:53:43 | | Part gTanzola |
| 02:54:01 | Blue_Dude | It might end up with .6 seconds of buffer vs 1 second. |
| 02:54:30 | JdGordon | 284 cant be right... 2MB maybe? |
| 02:55:19 | Blue_Dude | I was thinking of just making the buffer smaller and sneaking it in that way. But that means a stealth penalty of more CPU boosting, more disk access and shorter run time. But it hides RAM usage. |
| 02:55:48 | Blue_Dude | Or I could take it from buffering and make it suffer. |
| 02:55:55 | JdGordon | wont just adding a new buffer do the same anyway? |
| 02:56:14 | JdGordon | is 64K the absolute minimum? |
| 02:56:18 | Blue_Dude | Not if it's taken from somewhere else. |
| 02:56:29 | JdGordon | it wouldnt worry me at all for most targets.. just the clip |
| 02:56:34 | Blue_Dude | 64k? Yeah, that's about right. Two chunks plus larger code. |
| 02:57:37 | Blue_Dude | Or I can make the chunks smaller but that still means more frequent pcm interrupts and overhead. Not as expensive as a smaller buffer I don't think. |
| 02:57:50 | JdGordon | I say go for it :) I'm sure if you fix it so we can pause and have voice then most others would agree |
| 02:58:02 | JdGordon | get it working with a big ram usage and tweaklater? |
| 02:58:16 | Blue_Dude | Maybe. |
| 02:58:51 | Blue_Dude | The first commit will have a screamingly bad red delta. |
| 02:59:07 | JdGordon | big deal |
| 02:59:18 | Blue_Dude | And it won't ever get much better. |
| 02:59:34 | JdGordon | hang on.. you cant steal from the 512KB pcmbuf thats already there? |
| 03:00 |
| 03:00:07 | Blue_Dude | Yes of course. But that means more boosting, more disk access, less runtime, etc. Stealth RAM steal. |
| 03:00:39 | amiconn | The mixer needs to be able to run unboosted |
| 03:00:40 | Blue_Dude | And IIRC the Clip only has a 176k buffer. |
| 03:01:08 | Blue_Dude | The mixer probably can, but a smaller buffer means the watermark is hit more often, meaning more boosting. |
| 03:01:27 | amiconn | The pre-mixer buffer needs to keep its size |
| 03:01:48 | amiconn | Changing boost state too often is bad on a number of targets |
| 03:01:49 | Blue_Dude | Then I need to take 64k from somewhere else... |
| 03:02:25 | Blue_Dude | Or something smaller but put up with the increased callback overhead. |
| 03:02:52 | JdGordon | is the mixing too slow to be done in the PCM interrupt? |
| 03:03:44 | amiconn | i.e. all where changing boost state involves relocking the pll. On such targets each switch costs a certain time (up to a few milliseconds), during which the cpu busy-waits, and is usually running *slower* than in unboosted state |
| 03:03:53 | JdGordon | then there is no extra thread, or buffers... just mix at the lats possible moment before going out to the codec? |
| 03:04:03 | Blue_Dude | Maybe. If it's actually mixing it means manipulating about 32k of data, and not just a copy, but combining two or more streams. |
| 03:05:00 | amiconn | I'd limit mixing to two streams, and do it in an isr, only a few samples at a time (depending on whether the target uses dma or not) |
| 03:05:34 | Blue_Dude | Even a very short clip uses several thousand samples though. |
| 03:05:45 | amiconn | 10ms is 441 samples |
| 03:06:06 | amiconn | And I bet we could go lower than that |
| 03:06:18 | Blue_Dude | And the pcm callback looks at 32k chunks at a time. |
| 03:06:19 | amiconn | On PP it may be possible to mix right in the fiq |
| 03:06:42 | JdGordon | if you reuse the voice stream or beeps, they could be pre mixed... |
| 03:06:58 | Blue_Dude | That's dependent on user cooperation. You can't assume that. |
| 03:07:12 | JdGordon | sure you can... both are instantaneous events |
| 03:07:17 | amiconn | Pre-mixed is what we have now - it's bad for latency (and there is the pause issue) |
| 03:07:17 | JdGordon | you wouldnt want to uncouple them |
| 03:07:25 | Blue_Dude | Right. |
| 03:07:50 | Blue_Dude | The problem is just-in-time mixing, but not too late... |
| 03:07:57 | JdGordon | so the premix buffer there might be 1s worth.. which almost immediatly gets mixed with the audio.. most of the time you owuldnt be doing any mixing |
| 03:08:10 | amiconn | 1s is too much for voice |
| 03:08:18 | Unhelpful | these codecs where the gap between 4.0.3 performance and 4.4.2 performance widens as bitrate goes up make me wonder if the bitstream unpacking is where one compiler or the other ran into trouble optimizing... |
| 03:08:34 | | Join done365 [0] (n=done365@75-107-207-224.cust.wildblue.net) |
| 03:09:25 | Blue_Dude | Even the 64k I want is only two chunks of .18 seconds of audio. If I can't have *that* then 1s buffers are completely out of the question. |
| 03:10:09 | Unhelpful | n1s: things look a little bit worse for 4.4.2 after i apply your patch and benchmark each -O level with 4.0.3. mpc, vorbis, wma, ac3 all slower... wma by 4.4% |
| 03:10:48 | amiconn | Well, of course you need a second buffer for the second stream (i.e. voice). Post mix you shoulnd't need more than a few hundred samples |
| 03:10:51 | Blue_Dude | That's where the 64k comes from: two premix buffers, one active and one mixing. That will minimize memory moves and interference with the DMA. |
| 03:11:42 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 03:12:01 | | Join AEnima1577 [0] (n=clbarnob@nc652101a.cns.vt.edu) |
| 03:12:25 | Blue_Dude | Maybe it's possible to use really small buffers only when mixing, only a few hundred samples as you say. But callbacks will happen *very* frequently while mixing is going on. |
| 03:12:25 | kugel | Blue_Dude: why don't you rewrite/patch it so that the non-destructive thing can be added after the initial work? |
| 03:12:50 | kugel | IIUC that's the only questionable bit, I don't see why it's so critical to add in the first run |
| 03:13:27 | Blue_Dude | kugel: That's the problem. I can patch it but every patch is locking in the current scheme. It "fixes" problems without addressing basic functionality. |
| 03:13:37 | | Quit Jake ("CGI:IRC") |
| 03:13:42 | kugel | so rewrite |
| 03:14:08 | Blue_Dude | Well yeah, that's where I'm going. I don't mind the rewrite but it's going to hurt. |
| 03:14:10 | JdGordon | Blue_Dude: apart from crossfade mixing (and even then this might be valid)... actual mixing doesnt happen often (relatively speaking)... it woiuld spend a lot more time just dumping the one stream than mixing |
| 03:14:41 | kugel | Blue_Dude: I'm really only skeptical about the potential bloat the non-destructive mixing gives |
| 03:15:12 | Blue_Dude | JdGordon: Right. Even after the rewrite it will mostly do the same thing it's doing now. It's the mixing part that needs its guts ripped out for. |
| 03:15:20 | * | JdGordon also doesnt see the value in non destructive mixing... if you mix late enough |
| 03:16:11 | Blue_Dude | JdGordon: same thing. Really late non-destructive mixing is no mixing at all until feeding the DMA. |
| 03:16:25 | kugel | I'm sure you can make it all well while post-poning the decision about non-destructive |
| 03:17:41 | * | kugel votes for keeping it simple for the start |
| 03:18:14 | kugel | a rewrite is painful, even more if you you plan to much for the initial work |
| 03:18:20 | kugel | too* |
| 03:18:28 | Blue_Dude | This is a classic case of processor time vs memory usage. The more memory you use the less processor time you need. But no matter what, at *some* point the two streams are going to be mixed. Right now they are mixed in as far as the voice codec is willing to feed, (or the voice buffer runs dry) |
| 03:19:23 | kugel | JdGordon: merging this two function is a really stupid idea IMO |
| 03:19:28 | kugel | with absolutely no gain |
| 03:19:32 | JdGordon | not true |
| 03:19:33 | kugel | the code inside is completely different |
| 03:19:40 | JdGordon | yes |
| 03:19:41 | Blue_Dude | But then it's mixed all the way in right away, and that causes problems. The pause problem is solvable, but without later mixing (which *will* require memory), the result will be unpretty. |
| 03:19:42 | | Part done365 |
| 03:19:45 | JdGordon | merge the API... not the code |
| 03:19:58 | kugel | calling the same function to get different results? |
| 03:20:00 | *** | Saving seen data "./dancer.seen" |
| 03:20:03 | JdGordon | if they ask for full screen, then if they didnt disable the theme there will be problems |
| 03:20:22 | JdGordon | if they didnt disable the theme then they should expect to be using the theme viewport |
| 03:20:46 | JdGordon | its a sanity check thing |
| 03:20:58 | kugel | Blue_Dude: "unpretty" isn't an issue here |
| 03:21:15 | kugel | what is the point of merging them? |
| 03:21:23 | kugel | that's calling for confusion |
| 03:21:56 | Blue_Dude | I thought it was *the* issue myself. |
| 03:21:58 | kugel | a single function that yields different *logical* results based on magic is a bad functions |
| 03:22:15 | JdGordon | its not magic at all.. and thats why I changed the name |
| 03:22:29 | JdGordon | the usage is "I want to draw.. give me the area to draw in" |
| 03:23:17 | kugel | there's no point, just don't do it |
| 03:23:44 | * | kugel is annoyed by some of JdGordon latest crazy ideas |
| 03:24:41 | kugel | Blue_Dude: ? |
| 03:25:32 | Blue_Dude | kugel: "unpretty" is choppy illegible audio. For a DAP firmware I'd put that pretty high on my list of undesirable attributes. |
| 03:25:54 | JdGordon | I'm making it simpler to use... if you can see the logical flaw then fine.. but if there isnt one, then keeping the current API is bad because it causes problems and makes bad assumptions |
| 03:26:02 | kugel | how do you know already it's going to be choppy? |
| 03:26:12 | kugel | maybe it'll just be immediately slilent? |
| 03:26:46 | kugel | JdGordon: that's not simplifying |
| 03:27:02 | kugel | that's introducing bad practice imo |
| 03:27:21 | JdGordon | not at all.. if forces you to be explicit |
| 03:27:37 | JdGordon | it means you dont forget to disable the sbs after stealing the whole display |
| 03:27:53 | kugel | how's that related to combining the two functions? |
| 03:28:10 | Blue_Dude | kugel: I'm getting back to the pause/stop problem. Unless something changes, voice is dependent on main audio playback. Interrupt that, and the mix goes out the window. Resume and the obsolete mix is still going to be played. |
| 03:28:45 | kugel | either way you need to be explicit, but for a) you call a different function to get a different result, for b) you call the same function which is now magically right for you |
| 03:29:21 | JdGordon | either way you have to set the theme start first, that we agree on... then if you've done that, why should you need to know the difference between two functions? |
| 03:29:25 | kugel | Blue_Dude: and we cannot talk about the non-destructive thing after the rewrite happend? |
| 03:29:26 | Blue_Dude | And I've noticed that voice clips are not necessarily short. Some are several seconds long. Some are queued one behind the other. It's "not pretty". |
| 03:29:35 | JdGordon | the flow is "Set the theme" then "give me the viewport i can draw in" |
| 03:29:53 | Blue_Dude | The "non-destructive thing" *is* the rewrite. |
| 03:30:06 | kugel | I thought mixing multiple sources was |
| 03:31:02 | Blue_Dude | Nope. Each source needs its own (smallish) buffer, but that's not the problem. The problem is making the streams independent of each other. |
| 03:31:36 | Blue_Dude | How many simultaneous sources do we need to accommodate anyway? |
| 03:31:54 | JdGordon | depends how crossfade is done |
| 03:31:59 | JdGordon | I'd say 2 or 3 |
| 03:32:22 | kugel | JdGordon: because it gives different results! |
| 03:32:28 | JdGordon | no it doesnt |
| 03:32:35 | kugel | I'm too tired now. I really dislike that bit |
| 03:32:42 | | Quit kugel ("exit(0);") |
| 03:33:00 | Unhelpful | hrm, an interesting test_codec feature might be the ability to benchmark a directory of compiled .codec files against one audio file... |
| 03:34:59 | Blue_Dude | JdGordon: crossfade only occurs on the primary channel. It does "mix" but I wouldn't consider it a second source. It's more of a really late DSP effect than a mix. |
| 03:35:30 | JdGordon | then I'd start with voice/beeps as one, and audio as a second |
| 03:36:10 | Unhelpful | and the next step after that is acovea for optimizing codecs :) |
| 03:36:51 | | Quit LambdaCalculus37 ("POOF") |
| 03:37:02 | Blue_Dude | That's exactly what we have now, except that it's mixed in in 8k chunks. Well, no, since beep mixes as much as it wants. It's "not pretty" also. |
| 03:40:27 | Blue_Dude | Pushing the mix later means mixing right at the bottleneck and *that* means more memory. It can be nearly instantaneous, but the input stream is diverted instead of mixed in place. The number of inputs isn't the issue; independent operation is. |
| 03:40:52 | | Quit StealthyXIIGer (Read error: 54 (Connection reset by peer)) |
| 03:41:02 | | Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) |
| 03:52:47 | | Quit MethoS- (Remote closed the connection) |
| 03:53:14 | | Quit hepub (Read error: 110 (Connection timed out)) |
| 04: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:09 | CIA-80 | New commit by jdgordon (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:46 | JdGordon | kkurbjun: any thoughts on my most recent ml topic? |
| 05:15:56 | JdGordon | specifically simplifying the api to make life much easier? |
| 05:16:47 | | Quit StealthyXIIGer (Read error: 104 (Connection reset by peer)) |
| 05:16:55 | | Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) |
| 05:18:00 | kkurbjun | JdGordon: do screens need to be aware of the amount of space they have? For plugins their menu's should be the same as the other lists, or were you thinking of other cases? |
| 05:19:09 | JdGordon | the code snippet is how it would work.. so screens would try with the theme enabled, if its not enough then theyd get the ful screen on request |
| 05:19:18 | JdGordon | plugin menus would instantly just work again |
| 05:19:40 | JdGordon | do_menu() would always say "use the theme" |
| 05:19:48 | JdGordon | unless told not to |
| 05:20:01 | *** | Saving seen data "./dancer.seen" |
| 05:23:23 | JdGordon | doing viewportmanager_theme_enable(i, true, NULL); would be the equivilant of enabling the theme and calling set_default in one call... |
| 05:23:33 | JdGordon | NULL being a viewport pointer though... |
| 05:24:17 | * | JdGordon attempts to wiggle this in without removing the inbuilt bar |
| 05:25:17 | kkurbjun | sounds reasonable, I don't know the api enough to really say though, I'd need to look at it more |
| 05:51:12 | | Quit alexbobp (Remote closed the connection) |
| 05:51:30 | | Join alexbobp [0] (n=alex@66.112.249.238) |
| 05:52:59 | | Quit StealthyXIIGer (Read error: 54 (Connection reset by peer)) |
| 05:53:21 | | Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) |
| 05:59:07 | | Quit StealthyXIIGer (Read error: 54 (Connection reset by peer)) |
| 05:59:13 | | Join hd [0] (n=jd@modemcable207.134-202-24.mc.videotron.ca) |
| 05:59:20 | | Join AEnima1577 [0] (n=clbarnob@c-98-249-3-190.hsd1.va.comcast.net) |
| 05:59:26 | | Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) |
| 06: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:14 | TaZzZ | having issues with rockbox install .. its stuck on the themes part of install |
| 06:32:16 | TaZzZ | the rockbox utility is locked up |
| 06:33:41 | | Quit phanboy4 (Read error: 110 (Connection timed out)) |
| 06:38:40 | | Join ecognito [0] (n=evan@ppp118-209-67-70.lns20.mel4.internode.on.net) |
| 06:38:46 | | Quit panni_ (Read error: 104 (Connection reset by peer)) |
| 06:42:26 | ecognito | Hi. Is it possible to change the order that items appear in the main menu? |
| 06:42:59 | Llorean | Not without recompiling |
| 06:43:13 | ecognito | Bummer. Thanx. |
| 06:45:56 | TaZzZ | how do i get it to boot back to the ipod os if i wanted to |
| 06:49:24 | | Quit ecognito ("So that's what an invisible barrier looks like!") |
| 06:49:52 | Llorean | TaZzZ: That differs from player to player, but is in the manual which we ask you to read before asking here. |
| 06:54:55 | | Quit avacore (Read error: 60 (Operation timed out)) |
| 06:56:11 | | Join avacore [0] (i=nobody@90.184.100.129) |
| 06:58:33 | | Join bluebrother [0] (n=dom@f053155021.adsl.alicedsl.de) |
| 06:59:36 | TaZzZ | Llorean this rockbox rox |
| 06:59:59 | Tomis | what model ipod TaZzZ |
| 07:00 |
| 07:00:21 | TaZzZ | 5.5 |
| 07:00:27 | | Quit bluebroth3r (Read error: 60 (Operation timed out)) |
| 07:00:59 | Tomis | awesome |
| 07:12:20 | CIA-80 | New commit by FlynDice (r23732): AMS Sansa: Remove wait_for_state() following transfer in sd_select_bank() function. ... |
| 07:15:31 | TaZzZ | ok i have noticed it plays mpg vidoe files.. does it support mp4 videos? |
| 07:15:48 | | Part kkurbjunW |
| 07:20:03 | *** | Saving seen data "./dancer.seen" |
| 07:21:35 | Tomis | http://www.rockbox.org/wiki/PluginMpegplayer TaZzZ |
| 07:22:24 | | Quit CaptainKewl (Remote closed the connection) |
| 07:29:45 | | Quit StealthyXIIGer (Read error: 110 (Connection timed out)) |
| 07:30:13 | | Join hepub [0] (n=hepub@CPE0002a5b23cad-CM001bd7ac3c2a.cpe.net.cable.rogers.com) |
| 07:37:39 | CIA-80 | New commit by FlynDice (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:14 | Jake | So... what are the best setting to use for video on the Sansa c240? |
| 09:23:58 | Jake | I tried some things, but all I've gotten are some pretty colors and odd sounds. |
| 09:24:03 | | Join petur [50] (n=petur@rockbox/developer/petur) |
| 09:27:18 | Tomis | there's guidelines/suggestions on the MPEG Plugin page Jake http://www.rockbox.org/wiki/PluginMpegplayer |
| 09:27:46 | Jake | I've been reading that, but I guess I missed something. |
| 09:28:04 | Tomis | search the page for sansa, you'll find it |
| 09:29:16 | Jake | I need to find a micro SD card lol. |
| 09:29:25 | Jake | 1gb just is not enough space... |
| 09:36:04 | Jake | Yay got it to work |
| 09:42:07 | Jake | Now if only this screen was bigger.. |
| 09:44:20 | | Quit Thundercloud (Remote closed the connection) |
| 09:47:56 | linuxstb | amiconn: (answering your reply from 8h 40m ago) - viewports read from user input (wps etc) are checked at parse time, and the wps rejected if the viewports are invalid. |
| 09:50:26 | | Quit Grahack ("Leaving.") |
| 09:55:35 | | Join MethoS- [0] (n=clemens@134.102.106.250) |
| 09:58:43 | | Quit MethoS- (Remote closed the connection) |
| 10: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:12 | TheSeven | Utchybann: Argh. Now this is really ugly, but probably the only way that works properly... :-/ |
| 10:37:43 | TheSeven | gevaerts, LambdaCalculus37: Rockbox USB works for me on nano2g, but there seem to be some (rather rare) devices where it fails in a weird way. |
| 10:37:51 | TheSeven | liar is trying to track this down |
| 10:40:52 | Utchybann | TheSeven: I know this is an ugly hack. Perhaps, a line of comment that explain why we need this would be nice and help us to remember. |
| 10:42:10 | Utchybann | TheSeven: do you (or linuxstb) remember what was wrong with HAVE_WHEEL_ACCEL. I have activated it and it seems to work for me. |
| 10:43:44 | Utchybann | I guess that the problem was related to the USEC_TIMER issue. |
| 10:43:59 | TheSeven | I can't remember having touched that... so probably it is just nobody bothered defining it? or maybe disabling it was a workaround back when the wheel driver was all shaky? |
| 10:44:38 | TheSeven | Utchybann: I think the proper way to fix this would be using a function to read the usec timer instead of a define |
| 10:45:01 | TheSeven | you could still #define that function to just be a reg on other devices then |
| 10:45:11 | TheSeven | but this of course involves touching a lot of code |
| 10:45:50 | | Quit phanboy_iv (Read error: 104 (Connection reset by peer)) |
| 10:46:01 | Utchybann | TheSeven: a function would have less chance to be optimize by gcc in newer version. |
| 10:47:58 | linuxstb | Utchybann: When I enabled it, the wheel became very sluggish. So yes, very likely a timing issue, although the code shouldn't have been using USEC_TIMER (as it didn't exist). |
| 10:49:18 | TheSeven | Utchybann: we must *PREVENT* this from getting optimized, so an (inline) function would probably be the best solution for this |
| 10:55:00 | Utchybann | linuxstb: ok. On my nano2g with r23722 and USER_TIMER fixed, HAVE_WHEEL_ACCEL seems fine. |
| 10:55:47 | Utchybann | TheSeven: 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:01 | mc2739 | Zagor: clip on current builds page is showing an old version (r22777) - can you look into this please? |
| 12:06:18 | gevaerts | mc2739, Zagor: that's due to a clip vs sansaclip mismatch somewhere. The rest uses sansaclip |
| 12:07:51 | mc2739 | gevaerts: would that be why the manual did not build also? |
| 12:10:41 | | Join martian67 [0] (n=xD@about/linux/regular/martian67) |
| 12:10:50 | | Quit martian67 (Remote closed the connection) |
| 12:11:18 | | Quit TheSeven (Read error: 113 (No route to host)) |
| 12:12:47 | | Join martian67 [0] (n=arkfar@about/linux/regular/martian67) |
| 12:13:52 | gevaerts | mc2739: I suspect that both should be "sansaclip", i.e. r23724 was wrong for both files |
| 12:17:20 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 12:17:20 | mc2739 | gevaerts: if r23724 was wrong then I guess r23727 is also wrong |
| 12:20:53 | | Quit shodanX (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | NSplit | lindbohm.freenode.net irc.freenode.net |
| 12:20:53 | | Quit FlynDice (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit rasher (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit dionoea (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit jordan` (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit Xerion (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit J-23 (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit Jake (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit einhirn (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit Tomis (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit lostlogic (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit solexx (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit gevaerts (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit shai (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit FOAD (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit Llorean (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit jon-kha (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit GodEater (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit Slasheri (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit yosafbridge (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit shaggy-h (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit jasio (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit ThomasAH (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit ChanServ (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit DerPapst (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit HBK (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit xavieran (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit antil33t (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit tha (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit goffa (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit AlexP (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit kadoban_ (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit sbhsu (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit BlakeJohnson86 (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit togetic (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit Zambezi (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit Dhraakellian (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit bzed (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit ps-auxw (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit Overand (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit markun (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit knittl (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit fxb__ (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit fish_ (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit rjg (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit hatseflats (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit kugel (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit maruk (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit pixelma (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit linuxguy3 (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit tmzt (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit Res1 (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit grndslm (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit petur (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit Rob2223 (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit Zagor (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit bluebrother (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit tarbo (lindbohm.freenode.net irc.freenode.net) |
| 12:20:53 | | Quit droidcore (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit tchan (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit JdGordon (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit fyrestorm (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit Torne (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit YPSY (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit scorche|sh (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit jds2001 (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit chaos (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit Trista281 (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit CIA-80 (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit martian67 (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit Grahack (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit Horschti (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit avacore (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit alexbobp (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit Lss (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit BHSPitMonkey (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit linuxstb (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit amiconn (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit mikroflops (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit killan (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit T44 (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit Utchybann (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit dmb (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit niekie_ (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit scorche (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit jfc^3 (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit bughunter2 (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit rvvs89 (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit n17ikh (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit Tuplis (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit rphillips (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit advcomp2019 (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit crashd_ (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit maraz (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit preglow (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit blithe (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit ehntoo (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit z35 (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit krazykit (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit lyngaas (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit TaZzZ (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit cendres (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit crwl (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit Unhelpful (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit B4gder (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit jvd (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit matsl (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit AEnima15771 (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit hd (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit SIGSEGV (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit gtkspert_ (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit Zarggg (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit Kopfgeldjaeger (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit Bagder (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit mc2739 (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit Galois (lindbohm.freenode.net irc.freenode.net) |
| 12:20:56 | | Quit kkurbjun (lindbohm.freenode.net irc.freenode.net) |
| 12:20:57 | | Quit zu_ (lindbohm.freenode.net irc.freenode.net) |
| 12:20:57 | | Quit topik (lindbohm.freenode.net irc.freenode.net) |
| 12:20:57 | | Quit elcan (lindbohm.freenode.net irc.freenode.net) |
| 12:20:57 | | Quit Kohlrabi (lindbohm.freenode.net irc.freenode.net) |
| 12:25:12 | NHeal | lindbohm.freenode.net irc.freenode.net |
| 12:25:12 | NJoin | ChanServ [0] (ChanServ@services.) |
| 12:25:12 | NJoin | jasio [0] (n=yann@cpc2-rdng20-2-0-cust902.15-3.cable.virginmedia.com) |
| 12:25:12 | NJoin | shaggy-h [0] (n=kiwi@host-87-74-127-193.dslgb.com) |
| 12:25:12 | NJoin | kugel [0] (n=kugel@rockbox/developer/kugel) |
| 12:25:12 | NJoin | martian67 [0] (n=arkfar@about/linux/regular/martian67) |
| 12:25:12 | NJoin | DerPapst [0] (n=DerPapst@p4FE8F710.dip.t-dialin.net) |
| 12:25:12 | NJoin | Grahack [0] (n=chri@82.216.222.222) |
| 12:25:12 | NJoin | petur [50] (n=petur@rockbox/developer/petur) |
| 12:25:12 | NJoin | Jake [0] (n=60185bdd@83.168.254.42) |
| 12:25:12 | NJoin | einhirn [0] (n=Miranda@139.174.4.164) |
| 12:25:12 | NJoin | maruk [0] (n=papier@titanium.sdv.fr) |
| 12:25:12 | NJoin | Rob2223 [0] (n=Miranda@p4FDCE2B4.dip.t-dialin.net) |
| 12:25:12 | NJoin | matsl [0] (n=matsl@dhcp126.contactor.se) |
| 12:25:12 | NJoin | HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) |
| 12:25:12 | NJoin | Zagor [242] (n=bjorn@rockbox/developer/Zagor) |
| 12:25:12 | NJoin | xavieran [0] (n=xavieran@ppp118-209-137-145.lns20.mel6.internode.on.net) |
| 12:25:12 | NJoin | Bagder [0] (n=dast@giant.haxx.se) |
| 12:25:12 | NJoin | Horschti [0] (n=Horscht2@xbmc/user/horscht) |
| 12:25:12 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
| 12:25:12 | NJoin | avacore [0] (i=nobody@90.184.100.129) |
| 12:25:12 | NJoin | TaZzZ [0] (i=GamingEx@hidden.botpack.eu) |
| 12:25:12 | NJoin | AEnima15771 [0] (n=clbarnob@h80ad26c3.async.vt.edu) |
| 12:25:12 | | Join hd [0] (n=jd@Wikipedia/HellDragon) |
| 12:25:12 | NJoin | alexbobp [0] (n=alex@66.112.249.238) |
| 12:25:12 | NJoin | Lss [0] (n=Lss@cm205.delta92.maxonline.com.sg) |
| 12:25:12 | NJoin | shodanX [0] (n=shodanX@jazz.informatik.uni-erlangen.de) |
| 12:25:12 | NJoin | jordan` [0] (n=jordan@78.235.252.137) |
| 12:25:12 | NJoin | Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) |
| 12:25:12 | NJoin | FlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) |
| 12:25:12 | NJoin | dionoea [0] (n=dionoea@yop.chewa.net) |
| 12:25:12 | NJoin | rasher [50] (n=rasher@rockbox/developer/rasher) |
| 12:25:12 | NJoin | bzed [0] (n=bzed@devel.recluse.de) |
| 12:25:12 | NJoin | BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) |
| 12:25:12 | NJoin | cendres [0] (i=ashes@modemcable076.241-176-173.mc.videotron.ca) |
| 12:25:12 | NJoin | Tomis [0] (n=Tomis@70.134.65.177) |
| 12:25:12 | NJoin | antil33t [0] (n=Mudkips@203-184-54-232.callplus.net.nz) |
| 12:25:12 | NJoin | linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 12:25:12 | NJoin | tarbo [0] (n=me@unaffiliated/tarbo) |
| 12:25:12 | NJoin | pixelma [0] (i=quassel@rockbox/staff/pixelma) |
| 12:25:12 | NJoin | amiconn [0] (i=quassel@rockbox/developer/amiconn) |
| 12:25:12 | NJoin | lostlogic [50] (n=lostlogi@rockbox/developer/lostlogic) |
| 12:25:12 | NJoin | mikroflops [0] (n=yogurt@217-208-157-242-no112.tbcn.telia.com) |
| 12:25:12 | NJoin | solexx [0] (n=jrschulz@85.176.117.164) |
| 12:25:12 | NJoin | killan [0] (n=nnscript@c-94fc70d5.06-397-67626721.cust.bredbandsbolaget.se) |
| 12:25:12 | NJoin | droidcore [0] (n=mark@76-10-140-107.dsl.teksavvy.com) |
| 12:25:12 | NJoin | J-23 [0] (n=zelazko@unix.net.pl) |
| 12:25:12 | NJoin | tchan [0] (n=tchan@lunar-linux/developer/tchan) |
| 12:25:12 | NJoin | T44 [0] (n=Topy44@78.48.214.100) |
| 12:25:12 | NJoin | gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 12:25:12 | NJoin | shai [0] (n=Shai@192.117.110.233) |
| 12:25:12 | NJoin | SIGSEGV [0] (n=user@61.250.113.98) |
| 12:25:12 | Mode | "#rockbox +o ChanServ " by irc.freenode.net |
| 12:25:12 | NJoin | Utchybann [0] (n=lolo@ede67-1-81-56-102-26.fbx.proxad.net) |
| 12:25:12 | NJoin | gtkspert_ [0] (n=gtkspert@203-206-46-209.dyn.iinet.net.au) |
| 12:25:12 | NJoin | Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
| 12:25:12 | NJoin | FOAD [0] (n=dok@82.93.10.238) |
| 12:25:12 | NJoin | tha [0] (i=1038@ccc2.rbg.informatik.tu-darmstadt.de) |
| 12:25:12 | | Join Llorean [0] (n=DarkkOne@rockbox/user/Llorean) |
| 12:25:12 | NJoin | goffa [0] (n=goffa@70.33.8.114) |
| 12:25:12 | NJoin | JdGordon [0] (n=jonno@rockbox/developer/JdGordon) |
| 12:25:12 | NJoin | dmb [0] (n=Dmb@unaffiliated/dmb) |
| 12:25:12 | NJoin | AlexP [0] (n=alex@rockbox/staff/AlexP) |
| 12:25:12 | NJoin | fyrestorm [0] (n=nnscript@cpe-69-203-150-85.si.res.rr.com) |
| 12:25:12 | NJoin | jon-kha [0] (i=jon-kha@kahvi.eu.org) |
| 12:25:12 | | Join GodEater [0] (n=bibble@rockbox/staff/GodEater) |
| 12:25:12 | NJoin | niekie_ [0] (i=quasselc@dreamworld.bergnetworks.com) |
| 12:25:12 | NJoin | Kopfgeldjaeger [0] (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) |
| 12:25:12 | NJoin | Slasheri [0] (i=miipekk@rockbox/developer/Slasheri) |
| 12:25:12 | NJoin | yosafbridge [0] (n=yosafbri@64.71.152.39) |
| 12:25:12 | NJoin | kadoban_ [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) |
| 12:25:12 | NJoin | linuxguy3 [0] (n=timj@adsl-75-57-190-229.dsl.emhril.sbcglobal.net) |
| 12:25:12 | NJoin | scorche [50] (n=scorche@rockbox/administrator/scorche) |
| 12:25:12 | | Join Torne [0] (i=torne@rockbox/developer/Torne) |
| 12:25:12 | NJoin | jfc^3 [0] (n=john@dpc6682208002.direcpc.com) |
| 12:25:12 | NJoin | mc2739 [0] (n=mc2739@rockbox/developer/mc2739) |
| 12:25:12 | NJoin | tmzt [0] (n=tmzt@adsl-76-244-155-63.dsl.akrnoh.sbcglobal.net) |
| 12:25:12 | NJoin | Res1 [0] (n=Res@user-0c6s6gs.cable.mindspring.com) |
| 12:25:12 | NJoin | sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw) |
| 12:25:12 | | Join bughunter2 [0] (n=bughunte@unaffiliated/bughunter2) |
| 12:25:12 | NJoin | ThomasAH [0] (n=thomas@aktaia.intevation.org) |
| 12:25:12 | NJoin | grndslm [0] (n=grndslm@174-126-14-4.cpe.cableone.net) |
| 12:25:12 | NJoin | BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 12:25:12 | NJoin | togetic [0] (n=togetic@unaffiliated/ibuffy) |
| 12:25:12 | NJoin | YPSY [0] (n=ypsy@geekpadawan.de) |
| 12:25:12 | NJoin | blithe [0] (n=blithe@blakesmith.me) |
| 12:25:12 | NJoin | Zambezi [0] (i=Zulu@80.67.9.2) |
| 12:25:12 | NJoin | ehntoo [0] (n=ehntoo@lug.mtu.edu) |
| 12:25:12 | | Join rvvs89 [0] (n=ivo@pdpc/supporter/base/rvvs89) |
| 12:25:12 | NJoin | n17ikh [0] (n=n17ikh@host-69-59-126-212.nctv.com) |
| 12:25:12 | NJoin | Galois [0] (i=djao@efnet.math.uwaterloo.ca) |
| 12:25:12 | NJoin | ps-auxw [0] (n=arneb@dyn37.ps-auxw.de) |
| 12:25:12 | NJoin | scorche|sh [50] (n=scorche@rockbox/administrator/scorche) |
| 12:25:12 | NJoin | z35 [0] (n=z35@ool-45714f83.dyn.optonline.net) |
| 12:25:12 | NJoin | krazykit [0] (n=kkit@adsl-76-251-250-122.dsl.ipltin.sbcglobal.net) |
| 12:25:12 | NJoin | Dhraakellian [0] (n=ntryon@cpe-72-226-197-191.rochester.res.rr.com) |
| 12:25:12 | NJoin | jds2001 [0] (n=jds2001@fedora/jds2001) |
| 12:25:12 | | Join kkurbjun [0] (n=kkurbjun@rockbox/developer/kkurbjun) |
| 12:25:12 | NJoin | zu_ [0] (n=zu@bucketheaded.eu) |
| 12:25:12 | NJoin | crashd_ [0] (i=foobar@lostnode.org) |
| 12:25:12 | NJoin | maraz [0] (i=maraz@xob.kapsi.fi) |
| 12:25:12 | NJoin | topik [0] (i=awesome@wtf.grmpf.org) |
| 12:25:12 | NJoin | chaos [0] (n=chaos@gentoo/user/ch4os) |
| 12:25:12 | NJoin | preglow [0] (i=thomj@tvilling2.pvv.ntnu.no) |
| 12:25:12 | NJoin | lyngaas [0] (n=staale@19.81-167-149.customer.lyse.net) |
| 12:25:12 | NJoin | Trista281 [0] (i=tristan@i.dont.want.to.die.virgin.net.in) |
| 12:25:12 | NJoin | CIA-80 [0] (n=CIA@208.69.182.149) |
| 12:25:12 | NJoin | rphillips [0] (n=rphillip@66-90-184-91.dyn.grandenetworks.net) |
| 12:25:12 | NJoin | elcan [0] (i=user36@pr0.us) |
| 12:25:12 | NJoin | hatseflats [0] (n=hatsefla@193.200.132.183) |
| 12:25:12 | NJoin | crwl [0] (n=crwlll@a91-156-100-168.elisa-laajakaista.fi) |
| 12:25:12 | NJoin | B4gder [241] (n=daniel@rockbox/developer/bagder) |
| 12:25:12 | NJoin | Kohlrabi [0] (n=Kohlrabi@frustrum.nosebud.de) |
| 12:25:12 | NJoin | advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) |
| 12:25:12 | NJoin | jvd [0] (n=syscrash@poipu/developer/syscrash) |
| 12:25:12 | NJoin | Unhelpful [0] (n=quassel@rockbox/developer/Unhelpful) |
| 12:25:12 | NJoin | Tuplis [0] (n=jani@unaffiliated/tuplanolla) |
| 12:25:12 | NJoin | markun [50] (n=markun@rockbox/developer/markun) |
| 12:25:12 | NJoin | Overand [0] (i=overand@crappy.domain.name) |
| 12:25:12 | NJoin | fish_ [0] (n=fish@freigeist.org) |
| 12:25:12 | NJoin | fxb__ [0] (n=felixbru@h1252615.stratoserver.net) |
| 12:25:12 | NJoin | knittl [0] (n=knittl@unaffiliated/knittl) |
| 12:25:12 | NJoin | rjg [0] (i=rgordon@odie.tomelliott.net) |
| 12:25:17 | | Nick Tuplis is now known as Tuplanolla (n=jani@unaffiliated/tuplanolla) |
| 12:25:17 | gevaerts | mc2739: daily builds is yet another different system |
| 12:26:09 | gevaerts | linuxstb: that's of course an option. We need to decide on this one of these days... |
| 12:27:11 | linuxstb | IMO what is in tools/configure has always been _the_ target name - and other names shouldn't have been used elsewhere. |
| 12:27:44 | linuxstb | (whether the current names in tools/configure are good or bad is another question). |
| 12:29:07 | gevaerts | I agree, but we can't just change that without involving the rbutil people and the themes site people, and seeing what we have to do for backward compatibility |
| 12:29:20 | Ctcp | Version from freenode-connect!freenode@freenode/bot/connect |
| 12:29:34 | linuxstb | I know - but the clip is new, so we can at least be consistent for that. |
| 12:29:49 | linuxstb | (consistent in all places, rather than consistent with other sansas) |
| 12:30:22 | Zagor | petur did a big list a while back |
| 12:30:22 | gevaerts | ok, so we change the build system name? |
| 12:30:28 | Zagor | s/list/table/ |
| 12:30:41 | kugel | it should be consistent with other targets IMO |
| 12:30:47 | kugel | with other sansas, I mean |
| 12:30:49 | linuxstb | Zagor: That wasn't bluebrother? |
| 12:30:52 | petur | I did what? |
| 12:31:03 | * | petur scrolls back |
| 12:31:05 | linuxstb | kugel: Even though those other sansas are wrong? |
| 12:31:15 | kugel | yea |
| 12:31:22 | Zagor | my memory is not known to be very good... I thought it was petur (doing a big table of target name schemes) |
| 12:31:33 | petur | nope, wasn't me |
| 12:31:34 | kugel | it's not wrong, it's different |
| 12:31:42 | linuxstb | kugel: No, it's wrong. |
| 12:31:47 | kugel | Zagor: I think it was rasher |
| 12:32:02 | Zagor | kugel: ok |
| 12:32:08 | kugel | well, rasher made proposals, but we also have a wiki page with the current names |
| 12:32:32 | Zagor | kugel: which page is that? |
| 12:33:01 | kugel | linuxstb: unfortunately, configure isn't the ultimate source either. there are targets with the same configure name, but different builds |
| 12:33:18 | gevaerts | kugel: really? |
| 12:33:23 | linuxstb | kugel: Yes, I know. Which is why I said "as far as possible". |
| 12:33:28 | linuxstb | gevaerts: Different RAM sizes. |
| 12:33:43 | gevaerts | hm, indeed |
| 12:33:55 | kugel | Zagor: http://www.rockbox.org/wiki/BuildNames |
| 12:34:09 | Zagor | kugel: thanks |
| 12:34:13 | gevaerts | well, configure-name + suffix can work |
| 12:35:23 | Zagor | this was it: http://rasher.dk/rockbox/targetnames.php |
| 12:35:36 | kugel | the page is a bit out of date though |
| 12:35:49 | linuxstb | Yes. Fixing older targets is a fair amount of work, but I think that we should at least agree on a convention for new targets, and "configure name + suffix if more than 1 build" is a simple rule. |
| 12:36:14 | mc2739 | is there a way to know which name is needed fro any given system? |
| 12:37:58 | kugel | linuxstb: if only the configure names were consistent |
| 12:38:21 | | Join MethoS- [0] (n=clemens@134.102.106.250) |
| 12:38:25 | linuxstb | kugel: I don't see that as the most important point. It's more important for the same name to be used everywhere. |
| 12:38:41 | mc2739 | as in, how would you determine if you need "clip" or "sansaclip" |
| 12:39:04 | kugel | mc2739: not currently ;) that's why we're discussing it |
| 12:39:09 | gevaerts | mc2739: look in all places (sorry, I don't have a list) |
| 12:39:54 | kugel | linuxstb: if we rework it now, then we can take the opportunity to make it good everywhere |
| 12:40:45 | linuxstb | kugel: Sure, I'm not against someone changing the tools/configure names. I was just saying that we should use whatever name is there for new targets, such as the clip. |
| 12:41:34 | Zagor | I think we should make up a scheme that makes naming new targets easy, too. |
| 12:42:19 | * | kugel still favors the company/linemodel scheme |
| 12:42:19 | Zagor | such as the "company/linemodel" column in rasher's graph |
| 12:42:27 | Zagor | :) |
| 12:43:49 | gevaerts | company/line/model/variant :) |
| 12:45:19 | mc2739 | and any new ports added to svn should follow that scheme |
| 12:47:59 | Zagor | does anyone oppose the company/linemodel names as written up by rasher? |
| 12:48:24 | Zagor | the only one that is a bit odd is cowond2, since it's the only cowon that's not an "iaudio" |
| 12:48:40 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 12:49:27 | Zagor | cowon's web site lists d2, d2+ and s9 as "cowon" products. the rest are iaudio. |
| 12:49:50 | Zagor | so it's correct |
| 12:50:37 | kugel | Zagor: are you volunteriing to make a patch? :) |
| 12:50:41 | Zagor | yes |
| 12:50:47 | kugel | \o/ |
| 12:51:24 | * | kugel wonders if that could a enforced by a script |
| 12:51:41 | Zagor | what, exactly? |
| 12:52:03 | kugel | like, instead of hardcoding the complete name, we ask for company, line and model separately, and then combine them as per rule |
| 12:52:18 | Zagor | sounds like a lot more work and bother |
| 12:52:28 | Bagder | on most places we use a single word |
| 12:52:33 | Bagder | so it wouldn't work |
| 12:54:46 | Bagder | Zagor: do you write a script that translates the names? |
| 12:55:10 | Bagder | I figure a 50 lines sed or so could work |
| 12:55:42 | Zagor | I haven't looked at the specifics yet. but some sed fu is likely useful |
| 12:56:27 | Bagder | as we need to upgrade a bunch of scripts and stuff I think it'll be useful, and it can also be provided so people using scripts externally can "upgrade" using such a script |
| 12:59:41 | | Quit BHSPitMonkey ("Ex-Chat") |
| 13:00 |
| 13:05:58 | CIA-80 | New commit by funman (r23734): Sansa AMS: VIC_INT_ENABLE register is not a mask ... |
| 13:11:45 | * | linuxstb is perfectly happy with the existing configure names - they're short, unique and we all know them (or can easily look them up in tools/configure if we don't). |
| 13:12:35 | * | kugel isnt |
| 13:13:03 | Bagder | we should leave the existing working and add the new consistent ones |
| 13:13:24 | Bagder | and the new ones would then be used elsewhere when referring to specific targets |
| 13:13:37 | kugel | they're inconsistent (e200 and ondavx747 for example). and those which are short are likely to clash with other targets (the m3-problem for example) |
| 13:14:06 | kugel | ideally we shouldn't even need look up the names, the current configure names don't allow that |
| 13:15:02 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 13:15:32 | linuxstb | kugel: That simply isn't important IMO. The "m3 problem" isn't a problem - the solution was obvious. It just seems a waste of effort to go through and change all the places where the tools/configure name has been used (which I think are more places than when another name has been invented) |
| 13:20:08 | TaZzZ | what would cause the games not to work .. none of them |
| 13:20:10 | *** | Saving seen data "./dancer.seen" |
| 13:20:31 | Bagder | TaZzZ: a flawed install |
| 13:21:26 | TaZzZ | ya was thinking of reinstalling |
| 13:22:53 | TaZzZ | the other thing .. this file that says database.ignore . just a txt file .. or waht kinda file cause its scanning all the stuff i dont want to .. and i made a file called database.ignore.txt and took the txt part off and its still lookin in that directory |
| 13:23:59 | Torne | The database still goes through directories which contain a database.ignore file, it just doesn't add any files found there to the db |
| 13:24:08 | Torne | the number of found files will continue to go up while it's doing htat |
| 13:24:50 | TaZzZ | Torne it did add them |
| 13:25:15 | Torne | then your file is probably called the wrong thing.. |
| 13:25:16 | dionoea | funman: hi. I finaly managed to write a proper memmove_wrap() :) |
| 13:25:28 | Torne | rockbox doesn't read the file, so it doesn't matter what's in it |
| 13:25:35 | Torne | it just has to exist. |
| 13:25:47 | funman | dionoea: hello, i just saw that, i hope it makes clip playback crashproof_ |
| 13:25:51 | TaZzZ | should i make it a txt and leave txt on it |
| 13:25:59 | Torne | no, it has to be called database.ignore |
| 13:26:00 | Torne | nothing else |
| 13:26:53 | dionoea | funman: the only issues is that copies of buffers bigger than half the ring buffer will probably be really slow |
| 13:26:59 | dionoea | *issue |
| 13:27:25 | funman | the code in SVN uses a simple loop anyway |
| 13:28:20 | kugel | dionoea: I don't think that's a problem |
| 13:28:55 | dionoea | it could be optimised a bit with a local buffer (as mentioned in my last post) |
| 13:29:17 | kugel | the situation where the moved size is bigger than half of the buffer exists only when the entire buffer is small anyway (therefore the moved buffer is even smaller) |
| 13:30:02 | kugel | speed of buffering isn't going to be a problem on the clip as far as I can see |
| 13:30:32 | dionoea | you'll still be iterating a milion times if the buffer is 2MB big and you're moving 1MB of data :) |
| 13:30:44 | dionoea | with non linear data accesses |
| 13:31:39 | funman | we're really moving 30 or 40kB |
| 13:32:04 | dionoea | then why'd you have a problem with buffers bigger than half the ring buffer ? |
| 13:32:07 | kugel | dionoea: the audio buffer isn't bigger than 400k actually |
| 13:32:12 | dionoea | ah ok |
| 13:32:50 | funman | hm i thought it was smaller but my clip reports 400kB |
| 13:33:08 | * | dionoea can't wait for the clip port to be in a usable state so he can convert his sister to rockbox |
| 13:33:13 | kugel | I think moving 400k will be always fast enough on the clip, even if the algorithm is a bit slower than plain memmove |
| 13:33:26 | kugel | also, working code is better than fast code :) |
| 13:33:32 | dionoea | :) |
| 13:34:49 | funman | "optimized crashes" |
| 13:37:12 | dionoea | I have another slightly modified version of the memmove checking code (which also makes sure that we don't overwrite data which shouldn't have been changed). I don't know if it's worth posting it on the tracker |
| 13:37:46 | dionoea | (not that I also only checked that it worked with 8 and 9 byte big ring buffers ... it should be enough but you never know) |
| 13:37:57 | dionoea | *note |
| 13:39:01 | funman | dionoea: you have a clip ? |
| 13:39:11 | dionoea | my sister does |
| 13:39:41 | | Quit kugel (Read error: 60 (Operation timed out)) |
| 13:39:53 | dionoea | but she's kind of on the other side of earth than me for the time being ... so I don't feel confident testing stuff on her clip that far away. |
| 13:43:39 | | Quit Grahack ("Leaving.") |
| 13:46:46 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 14:00 |
| 14:02:56 | kugel | funman: did you see my sd patch? |
| 14:03:23 | funman | no |
| 14:03:50 | kugel | fs#10805 |
| 14:08:41 | | Part Bagder |
| 14:16:46 | kugel | dionoea: why do you call it perfect? |
| 14:18:23 | dionoea | kugel: because I was glad to finally get it to work :) |
| 14:18:28 | dionoea | I'm sure that it's far from perfect |
| 14:18:44 | kugel | it does't optimize for aligned moves (src, dst word aligned, n an integer multiple of word size), I think in buffering we have only this kind of moves |
| 14:19:27 | dionoea | ah, well that wouldn't be too hard to change. Just change the pointer to type to short * or something and it should work |
| 14:24:11 | | Quit Kopfgeldjaeger ("Serverwechsel") |
| 14:25:38 | | Join Kopfgeldjaeger [0] (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) |
| 14:26:36 | | Quit DerPapst ("Leaving.") |
| 14:31:47 | | Quit Kopfgeldjaeger ("Serverwechsel") |
| 14:40:52 | | Join adiroiban [0] (n=adiroiba@h194-54-129-79.teleson.ro) |
| 14:42:32 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 14:44:07 | Zagor | sed script: http://rockbox.pastebin.com/m3cd9561 |
| 14:51:31 | | Quit FOAD (Read error: 145 (Connection timed out)) |
| 14:51:31 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 15:00 |
| 15:01:49 | | Join thegeek [0] (n=nnscript@129.241.123.168) |
| 15:18:15 | linuxstb | Zagor: lang files use things like "yh*" or "gigabeat*" to match target names. Also, there are a fair number of files with names that are based on the configure names - will you be renaming them? |
| 15:18:51 | Zagor | yes I will |
| 15:20:12 | *** | Saving seen data "./dancer.seen" |
| 15:22:12 | linuxstb | Zagor: There's a typo in the m5 line of your sed script |
| 15:22:30 | Zagor | yeah I saw that. thanks for checking! |
| 15:22:50 | Zagor | and yes, lang files will require different replace rules |
| 15:25:21 | mc2739 | Zagor: line 34 also has an error - \bc200 should be \bc100 |
| 15:25:40 | linuxstb | If you change the Sansa names, then the bootloader files on the download server should be renamed, and mkamsboot needs changing to use them. Also, checkwps uses the configure names in its build script, and I'm guessing the theme site too.... |
| 15:26:06 | * | linuxstb _really_ doesn't see the point in all that work - just fix the far fewer places where the configure name isn't being used... |
| 15:26:11 | Zagor | yes, it's a big job |
| 15:27:17 | | Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) |
| 15:27:33 | Zagor | some of the configure names simply suck. such as the x5, m5 and m3 ones |
| 15:27:38 | | Quit antil33t (Read error: 101 (Network is unreachable)) |
| 15:27:54 | Zagor | consistency is a value in itself, in my opinion |
| 15:32:24 | | Quit kugel (Read error: 110 (Connection timed out)) |
| 15:33:11 | | Join Topy [0] (n=Topy44@f048059001.adsl.alicedsl.de) |
| 15:36:42 | | Part adiroiban |
| 15:39:03 | linuxstb | Zagor: "suck" seems a bit strong - they don't offend me. Consistency in all the places a specific name is used is the only thing I care about. But if you want to do all the extra work to change configure names, I wish you luck. |
| 15:40:49 | | Join antil33t [0] (n=Mudkips@203-184-54-232.callplus.net.nz) |
| 15:44:58 | | Join DerPapst [0] (n=DerPapst@p4FE8F710.dip.t-dialin.net) |
| 15:50:45 | | Quit T44 (Read error: 110 (Connection timed out)) |
| 16:00 |
| 16:00:27 | CIA-80 | New commit by mc2739 (r23735): Correct r23724 and r23727 - clip -> sansaclip |
| 16:05:29 | mc2739 | Zagor: At you convienience, would you do a web server update? |
| 16:05:52 | mc2739 | s/you/your/ |
| 16:06:00 | Zagor | just don't do it again :) |
| 16:10:39 | mc2739 | Zagor: Thanks. That fixed the daily and manual pages, but the current builds page has clip is missorted and has no link. Is that something I messed up, or is that something only you can fix? |
| 16:11:25 | * | linuxstb thought we had agreed configure names were definitive... |
| 16:11:59 | Zagor | mc2739: you forgot one line in rockbox.pm |
| 16:12:06 | Zagor | I fixed it |
| 16:12:36 | CIA-80 | New commit by zagor (r23736): clip => sansaclip |
| 16:13:03 | Zagor | linuxstb: they will be |
| 16:15:08 | | Join pamaury [0] (n=pamaury@140.77.26.133) |
| 16:16:27 | Zagor | has there ever been another Tatung Elio than the tpj1022? their current product range doesn't use the elio name at all and all google hits I do just call it elio or "elio tpj1022" |
| 16:17:05 | | Join panni_ [0] (i=hannes@95.222.21.143) |
| 16:17:39 | Zagor | so perhaps the name should be tatungtpj1022 rather than eliotpj1022. |
| 16:17:45 | Zagor | or even tatungelio |
| 16:20:37 | | Join roolku [0] (n=roolku@77-99-223-115.cable.ubr16.sgyl.blueyonder.co.uk) |
| 16:20:41 | mc2739 | Zagor: thanks again |
| 16:20:42 | | Join Omlet [0] (i=omlet05@91.181.227.166) |
| 16:21:36 | roolku | Zagor: there is the p810 http://www.wikio.co.uk/guide/tatung-elio-p810-4911.html |
| 16:22:12 | Zagor | yeah but tatung don't call that one elio: http://www.tatung.com/3codm/portable.asp |
| 16:26:09 | gevaerts | Zagor: are there actually more than two in existence? ;) |
| 16:26:14 | roolku | quite a few other sites do though... http://www.googlefight.com/index.php?lang=en_GB&word1=Tatung+Elio+P810&word2=Tatung+-Elio+P810 |
| 16:26:36 | roolku | gevaerts: I have two and linuxstb has one. :) |
| 16:26:49 | gevaerts | ok, so there are three :) |
| 16:27:27 | | Quit funman ("free(random());") |
| 16:28:04 | | Quit matsl (Read error: 110 (Connection timed out)) |
| 16:32:15 | linuxstb | roolku: amiconn now has my Elio |
| 16:32:33 | linuxstb | (it's chasing Linus's ipod around the world...) |
| 16:34:07 | | Join toffe82 [0] (n=chatzill@12.169.218.14) |
| 16:34:54 | | Join evilnick [0] (i=4571af51@rockbox/staff/evilnick) |
| 16:36:45 | | Join dfkt_ [0] (i=dfkt@unaffiliated/dfkt) |
| 16:38:15 | | Quit dfkt (Nick collision from services.) |
| 16:38:19 | | Nick dfkt_ is now known as dfkt (i=dfkt@unaffiliated/dfkt) |
| 16:41:34 | roolku | linuxstb: cool. maybe time to share my measly findings... |
| 16:42:56 | CIA-80 | New commit by roolku (r23737): Tatung Elio: a few more buttons identified |
| 16:43:55 | | Nick YPSY is now known as Ypsy (n=ypsy@geekpadawan.de) |
| 16:51:04 | | Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) |
| 16:54:32 | | Join cowgarden [0] (n=qgar10@94.221.250.163) |
| 16:55:08 | cowgarden | wow, congratullations so the speed regulation, listening to voice at 250% still sounds very very good |
| 16:55:31 | cowgarden | is 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:07 | minus | hello :) |
| 18:07:00 | * | Torne pesters anyone with a hard-disk based player to try out FS #10798 |
| 18:07:20 | minus | i installed rockbox on my sansa fuze v1 yesterday and i have to say: it rocks, works almost without errors |
| 18:07:30 | Torne | glad to hear it |
| 18:07:42 | | Join solexx_ [0] (n=jrschulz@e182094011.adsl.alicedsl.de) |
| 18:07:47 | | Join Lear [0] (i=chatzill@rockbox/developer/lear) |
| 18:08:59 | kugel | Torne: I need to find my samsung :( |
| 18:09:06 | Torne | kugel: heh |
| 18:09:11 | | Join hebz0rl [0] (n=hebz0rl@dslb-088-065-209-022.pools.arcor-ip.net) |
| 18:09:18 | Torne | i've tried it on ipodvideo and beast |
| 18:10:09 | Torne | which actually covers most of the configs, tbh |
| 18:10:17 | Torne | beast has DMA, and ipodvideo has large sectors |
| 18:11:34 | Torne | i guess i could commit it, but i doubt i'll be anyone's friend if it turns out that i've broken disk writes somehow :) |
| 18:13:23 | | Join Coldarchon [0] (n=chatzill@p5B27CBBB.dip.t-dialin.net) |
| 18:15:02 | | Quit solexx (Read error: 145 (Connection timed out)) |
| 18:15:33 | Coldarchon | anyone there? after the utility failed I tried the manual install on an ipod nano 1st generation, but ipodpatcher always craches. any ideas? |
| 18:16:51 | Torne | what os, and at what point does it crash, and what happened when you used rbutil? |
| 18:17:24 | * | kugel doest have the slightest idea where his samsng is |
| 18:17:36 | maruk | Coldarchon: can you copy/paste on http://pastebin.com/ the output of 'ipodpatcher -l' ? |
| 18:18:07 | Coldarchon | on win xp, rbutil couldnt install any files and the patcher errors reading from disk after trying to move images |
| 18:18:41 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 18:19:10 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 18:19:17 | | Quit petur ("work->home") |
| 18:19:44 | Coldarchon | http://pastebin.com/m5eeb23ea |
| 18:19:46 | Coldarchon | done |
| 18:21:26 | Coldarchon | I formated, put the patch onto the ipod, started via cmd from there, it all fails |
| 18:21:52 | kugel | hm |
| 18:22:02 | kugel | Torne: I found it, let me reboot |
| 18:22:10 | kugel | (into linx to make a buil :) ) |
| 18:22:20 | | Quit kugel ("exit(0);") |
| 18:22:42 | maruk | Coldarchon: output seems good. Can you pastebin 'ipodpatcher −−install' output ? |
| 18:22:46 | | Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net) |
| 18:23:53 | Coldarchon | empty, it crashes |
| 18:24:01 | Coldarchon | I can make a screen if you want |
| 18:26:00 | maruk | Coldarchon: my feeling is that you have some i/o error on your flash. |
| 18:26:49 | Coldarchon | hm, itunes works perfectly, it's just that the battery doesn't have energy for more than 1 hour |
| 18:28:43 | maruk | itunes write to the second partition, ipodpatcher to the first one. |
| 18:29:05 | Coldarchon | makes sense in what I have read so far |
| 18:30:19 | minus | can you access the flash memory directly? |
| 18:30:38 | | Join kugel [0] (n=kugel@e178111115.adsl.alicedsl.de) |
| 18:30:51 | Coldarchon | yepp, I can put files on it |
| 18:31:05 | Coldarchon | I even started that patcher from there |
| 18:35:00 | | Quit maruk ("Leaving.") |
| 18:35:37 | | Quit gevaerts (Nick collision from services.) |
| 18:35:45 | | Join gevaerts_ [0] (n=fg@rockbox/developer/gevaerts) |
| 18:36:11 | linuxstb | Coldarchon: Have you restored your ipod in itunes recently? That would access the same part of the flash that ipodpatcher does. |
| 18:36:11 | | Nick gevaerts_ is now known as gevaerts (n=fg@rockbox/developer/gevaerts) |
| 18:36:47 | Coldarchon | I tried that after install failed and then formated again |
| 18:37:24 | | Join freddyb [0] (n=fred@70.104.101.195) |
| 18:37:55 | Coldarchon | at first it was grey with a black font. is there something else than a format that I can do? |
| 18:38:17 | linuxstb | What was grey with a black font? |
| 18:38:33 | freddyb | Torne: I'm confused. Isn't linking to the FS patches "providing the sources?" |
| 18:38:39 | gevaerts | Coldarchon: why format after running itunes? |
| 18:39:06 | Torne | freddyb: no. |
| 18:39:08 | linuxstb | freddyb: No. _you_ have to provide the source. |
| 18:39:28 | FlynDice | funman: I understand that in sd_wait_for_state() we want to include the time spent yielding in the timeout calculation is that correct? |
| 18:39:36 | funman | freddyb: i'm looking at your last patch, seeing if it works on the clip (works fine on fuze) |
| 18:39:52 | freddyb | Funman: thanks. |
| 18:39:53 | Coldarchon | I tried to install when it was blank, failed. format, failed. used itunes, then install, failed. formated and installed, failed. put the files manually on there, failed |
| 18:40:02 | funman | FlynDice: hm didn't you ask this some time ago ? |
| 18:40:08 | kugel | any idea why dma doesn't work? |
| 18:40:42 | funman | FlynDice: looks incorrect, timeout should be total time, not total time spent in the sd thread |
| 18:40:45 | funman | kugel: 'dma' ? |
| 18:41:13 | Torne | kugel: me, you mean? :) |
| 18:41:13 | kugel | funman: for recording |
| 18:41:24 | funman | i didn't work on it further |
| 18:41:46 | freddyb | Torne: Then I guess I need them taken them down. I maxed my web space with just the binaries. Can you do that? |
| 18:41:53 | FlynDice | funman: bertrik actually asked , but I remembered and noticed it wasn't done yet. I'm going to do it right now, just thought I'd make sure since you are around right now... |
| 18:42:07 | funman | last patch using DMA is 3 weeks old and causes error in recording code |
| 18:42:45 | funman | recording crashes on clip |
| 18:42:46 | Torne | kugel: anyway can you try out various stuff involving writing? test_disk write verify possibly, or just usb? doesn't really matter where it comes from :) |
| 18:42:59 | Torne | freddyb: you should be able to edit your own posts |
| 18:43:06 | kugel | nope |
| 18:43:55 | CIA-80 | New commit by FlynDice (r23738): AMS Sansa: Include time spent yielding when figuring timeout in sd_wait_for_state(). |
| 18:43:59 | | Quit AEnima15771 ("Leaving.") |
| 18:44:10 | funman | freddyb: what are you talking about with "providing the sources" ? can't find anything in the irc log |
| 18:44:27 | Torne | freddyb: i posted on his forum threads, which is why you can't find it in the irc log |
| 18:44:45 | Torne | he has three custom builds up for his alternative scrollwheel keyboard patch |
| 18:44:49 | Torne | but no source |
| 18:45:15 | kugel | music plays, so it can't be that bad :) |
| 18:45:51 | funman | GPL only requires you to provide the source when someone ask for it, not to distribute the sources with the binary |
| 18:46:30 | Torne | funman: if you go with that option you have to be able to respond to requests for sources for three years |
| 18:46:47 | funman | so? |
| 18:46:51 | Torne | so yes, you can do that, but there is some difficulty involved |
| 18:46:56 | AlexP | funman: It is less onerous to supply them along with IMO, but that is an option |
| 18:47:01 | gevaerts | And provide a written offer, whatever that means |
| 18:47:08 | funman | it's simpler to just link to flyspray |
| 18:47:21 | AlexP | And then have to supply the source for three years |
| 18:47:23 | gevaerts | that is *not* valid |
| 18:47:24 | Torne | that's not sufficient for any of them. |
| 18:47:34 | funman | we're geeks, not lawyers! |
| 18:47:45 | freddyb | Torne: i emptied the bodies of the posts but I can't delete the posts "You cannot delete your own topics in this board." |
| 18:47:55 | Torne | freddyb: I will delete them i fyou want them deleted.. |
| 18:48:33 | * | kugel edits apps/SOURCES and wonders why test_disk doesn't compile correctly |
| 18:48:45 | Torne | kugel: works for me ;) |
| 18:49:01 | Torne | funman: whether people respect the GPL is kinda important, though |
| 18:49:06 | freddyb | Thanks. Should FS #10763 be deleted/removed also? |
| 18:49:33 | funman | Torne: IMO the most important is to respect the spirit (make sure the sources are easily accessible) |
| 18:49:34 | kugel | Torne: it was the wrong SOURCES :) |
| 18:49:36 | Torne | er, why should the FS entry be deleted? |
| 18:49:54 | freddyb | Torne: same thing, right? |
| 18:50:10 | gevaerts | freddyb: I see no binaryes on FS #10763 |
| 18:50:13 | Torne | freddyb: Sources must be available with binaries |
| 18:50:20 | Torne | there are no binaries there |
| 18:50:27 | freddyb | Oh. |
| 18:50:31 | Torne | if people couldn't post patches then the entire open source thing wouldn't really work :) |
| 18:50:46 | kugel | IIRC you don't need to provide the sources until someone asks for them? |
| 18:50:55 | minus | is the file save "dialog" the same for all devices? |
| 18:51:41 | Torne | kugel: you either need to make the sources available at the same time as the binaries, or you need to accompany them with a written offer to provide sources on request valid for at least three years |
| 18:52:02 | | Join Sajber^ [0] (n=Sajber@c-5a3771d5.012-155-73746f22.cust.bredbandsbolaget.se) |
| 18:52:12 | freddyb | funman: what happened when clip crashed? |
| 18:52:16 | Torne | freddyb: i've removed the thrads, anyay |
| 18:52:16 | funman | no idea |
| 18:52:30 | | Join Tomis2 [0] (n=Tomis@70.134.82.83) |
| 18:52:30 | kugel | argh, yh925 disk speed is soooooooo slow |
| 18:52:31 | Torne | freddyb: and i'm not trying to stop you from demoing your patch :) |
| 18:52:45 | kugel | <3MB/s I believe (the OF bootloader is way faster) |
| 18:54:23 | gevaerts | Torne: test_disk passes on my gigabeat f |
| 18:54:43 | Torne | good to hear |
| 18:54:57 | Torne | i think this is several combinations.. the ata code is not *that* variable between targets |
| 18:55:05 | * | Torne waits for kugel :) |
| 18:55:22 | * | kugel waits for test disk to finish :) |
| 18:57:12 | kugel | win! :) |
| 18:57:40 | Torne | well that's several players it doesn't seem to have totally screwed |
| 18:57:45 | Torne | shall i commit? :) |
| 18:58:24 | AlexP | Do you feel lucky? |
| 18:58:29 | Torne | well, the better questoin is will waiting help it get tested any better. |
| 18:58:47 | Torne | it gets tested a lot more if it's in the current build : |
| 18:59:22 | Torne | i guess the alternative is "does anyone familiar with ATA want to have a read" |
| 18:59:26 | | Quit Tomis (Read error: 145 (Connection timed out)) |
| 18:59:27 | CIA-80 | New commit by funman (r23739): Sansa AMS : fix recording ... |
| 18:59:28 | | Nick Tomis2 is now known as Tomis (n=Tomis@70.134.82.83) |
| 18:59:30 | Torne | because I have changed from doing WRITE SECTORS to doing WRITE MULTIPLE |
| 18:59:37 | Torne | which is an actual semantic change to our interaction with the disk |
| 18:59:48 | funman | freddyb: thanks a lot :D |
| 18:59:51 | Torne | (to better reuse the code for handling reads, and because it should be faster) |
| 19:00 |
| 19:00:46 | kugel | funman, freddyb \0/ |
| 19:01:16 | * | kugel wonders if the clip recording crash is related to the clip radio freeze |
| 19:01:27 | kugel | Torne: go for it already! :P |
| 19:01:49 | Torne | kugel: hey i've yet to have broken anything, i'm trying to maintain a perfect score :) |
| 19:01:59 | funman | kugel: no, perhaps to fs#10605 though |
| 19:02:31 | kugel | did the radio on the clip ever work? |
| 19:03:03 | kugel | Torne: that's a hopeless goal unfortunately |
| 19:03:06 | funman | sure |
| 19:03:22 | kugel | what broke it? mmu patch? |
| 19:03:25 | funman | i identified the lockup in the same location than previously |
| 19:03:30 | funman | which had been fixed somehow by bertrik |
| 19:03:38 | funman | no, something else |
| 19:04:01 | CIA-80 | New commit by torne (r23740): FS #10798 - unify ata_read_sectors and ata_write_sectors ... |
| 19:04:04 | kugel | so, does anyone bother to bisect it? |
| 19:04:06 | funman | there were FM lockups on c200v2 IIRC |
| 19:07:16 | minus | does the Rockboy plugin work? |
| 19:07:29 | funman | they all work |
| 19:08:27 | freddyb | funman: kugel: thanks. I wish knew something about the Clip... |
| 19:08:29 | minus | but it's not included on the standard distribution |
| 19:08:40 | AlexP | minus: It is on the players it works on |
| 19:08:53 | AlexP | What do you have? |
| 19:08:56 | funman | freddyb: Clip has other problems so until they are solved, I wouldn't look at recording on the clip |
| 19:09:23 | CIA-80 | New commit by torne (r23741): FS #9721 - No error check after writes in ata.c ... |
| 19:09:33 | Torne | might as well put that one in too, while i'm messing about with ata writes. :) |
| 19:09:50 | minus | sansa fuze, but didnt see that there's no coloumn for it on the PluginIndex wiki page |
| 19:10:07 | AlexP | Then I suspect it hasn't been adapted/enabled on the fuze |
| 19:10:16 | kugel | the yh* have 8~k of unused iram :/ |
| 19:10:18 | funman | it worked last time i tried |
| 19:10:19 | kugel | ~8k |
| 19:10:29 | AlexP | funman: rockboy? |
| 19:10:47 | AlexP | minus: How are you trying to run it? You should be clicking on a ROM |
| 19:10:49 | linuxstb | minus: Are you just looking in the plugins menu (where it won't be)? Or have you tried opening a .gb file? |
| 19:10:52 | funman | minus: http://download.rockbox.org/daily/manual/rockbox-sansafuze/rockbox-buildch10.html#x13-22500010.3.9 |
| 19:11:56 | kugel | Torne: it looks like writing has gotten a lot faster! |
| 19:12:00 | Torne | really? |
| 19:12:10 | Torne | i mean, it shohld get faster |
| 19:12:11 | kugel | reading is still painfully slow |
| 19:12:26 | Torne | also the binsize delta is -500 or so on all the hd targets |
| 19:12:29 | * | Torne wags! :) |
| 19:12:45 | kugel | write is 17MB/s, reading is 5.5MB/s (1MB aligned test) |
| 19:13:19 | Torne | i didn't expect multisector PIO to help *that* much but i guess it probably does |
| 19:13:23 | | Join liar [0] (n=liar@83.175.83.185) |
| 19:14:24 | Torne | it seemed silly not to do it when we have the loop to do the multisector reads right there. |
| 19:15:58 | funman | dionoea: start and end in your memmove_wrap() prototype are start & end of ringbuffer ? |
| 19:16:08 | Torne | c200v2 has impressively high binsize variations |
| 19:16:21 | | Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) |
| 19:16:21 | | Quit pixelma (Nick collision from services.) |
| 19:16:41 | | Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) |
| 19:16:56 | Torne | nobody with an ipod other than the video has answered my poll about that startup bug yet :( |
| 19:17:07 | funman | Torne: really? the maximum is 58 |
| 19:17:10 | | Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) |
| 19:17:10 | | Quit amiconn (Nick collision from services.) |
| 19:17:15 | | Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) |
| 19:17:30 | dionoea | funman: correct |
| 19:17:30 | Torne | funman: i just mean, it varies a lot on seemingly irrelevant commits, when almost all other targets have 0 |
| 19:17:52 | dionoea | funman: end is the first byte outside the ring buffer |
| 19:17:53 | | Quit Jake ("CGI:IRC (EOF)") |
| 19:18:05 | funman | they could be hardcoded instead of given by arguments |
| 19:18:15 | funman | i'm trying to merge your code in buffering.c |
| 19:18:21 | dionoea | sure. I just wanted something generic |
| 19:18:34 | funman | gcd() involves division by the way (% operator) |
| 19:18:55 | dionoea | well if you know any other faster method of computing a gcd I'm all ears :) |
| 19:19:22 | funman | i know one but I use it in my proof of Riemann's hypothesis so I can't publish it |
| 19:19:42 | dionoea | :) |
| 19:19:44 | | Quit grndslm (Read error: 60 (Operation timed out)) |
| 19:20:14 | *** | Saving seen data "./dancer.seen" |
| 19:20:38 | kugel | funman: btw, I was wondering why the int of the sd controller is used, instead of the dma callback to indicate finished transfer (samsa sd driver) |
| 19:21:31 | dionoea | funman: feel free to test the function with your own test code before using it. 2 validations are better than one |
| 19:22:05 | funman | kugel: I think i mentioned it in the log (because the end of transfer used to be notified by the dma callback) |
| 19:22:21 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 19:23:12 | kugel | Torne: ok, I take it partly back. writing has gotten faster, but it was already way faster than reading in SVN (11MB/s) |
| 19:23:21 | kugel | any idea why reading is so slow? |
| 19:23:24 | Torne | no. |
| 19:23:31 | Torne | iirc it's like that in test_disk on ipodvideo also |
| 19:23:38 | Torne | i've not benched it via any other method |
| 19:23:42 | funman | kugel: r19714 |
| 19:24:18 | funman | the log doesn't tell why i made that though |
| 19:24:48 | funman | Remove unneeded blocking API from DMA code |
| 19:25:09 | | Join grndslm [0] (n=grndslm@174-126-14-4.cpe.cableone.net) |
| 19:25:38 | * | kugel goes trying #define ATA_OPTIMIZED_READING |
| 19:25:51 | funman | bertrik: hello, do you remember fixing a lockup in Sansa AMS FM ? (I think it was on a specific model, e200v2 perhaps) |
| 19:26:14 | kugel | it was fixed at the devcon IIRC |
| 19:27:26 | bertrik | funman, yes, it was for e200v2 |
| 19:27:41 | funman | I believe the Clip has the same problem |
| 19:27:44 | bertrik | I think there is still a similar problem for c200v2 |
| 19:28:17 | funman | does the FM work sometiems on c200v2? |
| 19:28:21 | bertrik | the radio on my clip works fine, except for a bug where it won't tune properly to the last used frequency just after startup sometimes |
| 19:28:29 | Torne | argh, of course the ATA stats patch massively conflicts with the ata unification i just committed |
| 19:28:34 | Torne | i will have to rewrite the stats patch :) |
| 19:28:46 | Torne | hm i should probably go home |
| 19:28:47 | kugel | ata code is so much faster than sd even for single SECTOR_SIZE transfers :( |
| 19:28:58 | bertrik | funman, very rarely, it's an initialisation problem that causes a hang in the tune loop |
| 19:29:25 | kugel | it doesnt work on mine |
| 19:29:28 | funman | entering the FM screen on my Clip just locks up in si4700_set_frequency |
| 19:29:38 | minus | ata code? |
| 19:30:10 | bertrik | kugel, funman, I did later make a change for c200v2 that didn't really work, can you revert that? (it's the latest change to si4700.c) |
| 19:30:57 | * | kugel gets his glass ball out |
| 19:31:31 | bertrik | the ams sansas use the 32 kHz oscillator (instead of using an external 32 kHz signal) and use of that is rather poorly described in the data sheets |
| 19:31:55 | kugel | svn log is a nice glass ball ;) |
| 19:32:59 | minus | isn't the AMS a ARM processor? |
| 19:33:27 | bertrik | additionally... the c200v2 also seems to have problems with the current speed of the i2c clock towards the tuner (it needs a little slower bus speed it seems) |
| 19:34:37 | kugel | bertrik: have you checked whether playback works better on c200v2 already? |
| 19:35:06 | funman | well playback is still buggy |
| 19:35:23 | | Join saratoga [0] (i=9803c6dd@gateway/web/freenode/x-rltlqjhhzfqxwudm) |
| 19:35:47 | funman | minus: wiki page SansaAMS has all the details |
| 19:35:54 | bertrik | yes I checked, some mp3s wouldn't even start playing, oggs seemed to work and I also played m4a's, but skipping m4a's also stopped playback |
| 19:35:56 | minus | k |
| 19:36:18 | funman | on c200v2 it's worse because color lcd eats up more RAM |
| 19:36:30 | saratoga | how much memory does the c200v2 have for buffering? |
| 19:36:34 | saratoga | 350KB? |
| 19:37:03 | bertrik | Can I look that up for you somehow? |
| 19:37:19 | funman | debug menu -> buffering |
| 19:37:35 | bertrik | Rockbox info says Buffer: 259 KB |
| 19:38:20 | funman | bertrik: can you try last patch on FS #10605 ? |
| 19:38:30 | bertrik | debug menu -> buffering says pcm 0/176400 and alloc 0 / 48656 |
| 19:39:03 | funman | 176400 is 1 second of PCM buffer |
| 19:39:31 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
| 19:39:37 | bertrik | funman, the memmove_wrap.diff patch? |
| 19:39:43 | funman | yes |
| 19:40:10 | funman | i'd test on Clip but it crashes less frequently |
| 19:41:01 | bertrik | just to be clear, should I test that patch on the clip or on the c200v2? |
| 19:41:08 | funman | c200v2 |
| 19:48:21 | bertrik | funman, the first mp3 I tried wouldn't start ... |
| 19:48:49 | | Join CaptainKwel [0] (i=2669ecc2@gateway/web/freenode/x-vhpnlkvdjpqgbtmm) |
| 19:49:10 | funman | can you mention that on FS please ? + :( |
| 19:49:24 | kugel | http://www.daniweb.com/code/post969374.html# apparently has a way to do gcd without div |
| 19:49:46 | funman | kugel: the div comes from % |
| 19:49:55 | kugel | i know |
| 19:50:15 | kugel | the second function has only add/sub |
| 19:50:45 | funman | sorry, didn't read the second one |
| 19:51:26 | kugel | dionoea: ^ |
| 19:52:14 | | Quit droidcore (Read error: 113 (No route to host)) |
| 19:53:01 | | Quit Coldarchon ("ChatZilla 0.9.85 [Firefox 3.5.5/20091102152451]") |
| 19:55:05 | | Join JdGordon| [0] (n=Miranda@nat/microsoft/x-hpnermywythyxddi) |
| 19:56:10 | dionoea | kugel, funman: I'm not sure that it'd be faster. |
| 19:56:54 | kugel | it probably is |
| 19:57:14 | kugel | on targets without hardware div (arm) at least |
| 19:57:20 | | Join torquel [0] (n=4dff77ac@giant.haxx.se) |
| 19:57:27 | funman | it'd depend the ratio between the 2 integers |
| 19:58:10 | dionoea | arm doesn't have hardware div ? |
| 19:58:20 | | Join archibald [0] (n=4dff77ac@giant.haxx.se) |
| 19:58:22 | funman | no |
| 19:58:26 | dionoea | ah ... cool :) |
| 19:58:50 | | Part LinusN |
| 19:58:51 | dionoea | I still guess that the first one would be faster. It has like exponential convergence speed while the other one looks more linear |
| 19:59:01 | funman | division is emulated by gcc |
| 19:59:16 | | Join stripwax [0] (n=Miranda@87.194.34.169) |
| 19:59:23 | minus | why? |
| 19:59:28 | | Quit stripwax (Client Quit) |
| 19:59:55 | kugel | it can't be faster if you need to emulate div (which can only happen by add/sub too, because *1/x doesn't work either) |
| 19:59:57 | funman | 19:58 < dionoea> arm doesn't have hardware div ? |
| 19:59:57 | funman | 19:58 < funman> no |
| 20:00 |
| 20:00:00 | funman | minus: ^ |
| 20:00:16 | minus | eh |
| 20:00:23 | dionoea | well the second one basically implements modulo using: mod(a,b) = while (a > b) a -= b; |
| 20:00:33 | dionoea | I doubt that gcc's % implementation could be slower |
| 20:00:44 | minus | well, benchmark it |
| 20:01:54 | dionoea | I'd assume that gcc developpers are kind of smart :) |
| 20:02:01 | | Quit StealthyXIIGer (Read error: 131 (Connection reset by peer)) |
| 20:02:01 | kugel | dividing in a loop is even worse ;) |
| 20:02:18 | | Join StealthyXIIGer [0] (n=stealthy@68.62.19.6) |
| 20:02:19 | funman | they can be smart but can't use the device beyond its capabilities |
| 20:02:19 | | Quit torquel ("CGI:IRC (Ping timeout)") |
| 20:03:05 | dionoea | so what you're basically saying is that gcc has a / implementation which is slower than div(a,b) = result = 0; while (a>b) { a -= b; result++; } return result; |
| 20:03:08 | | Join TheSeven [0] (n=theseven@rockbox/developer/TheSeven) |
| 20:03:09 | funman | if a == LOT*b + BIT then I believe using gcc's div would be faster |
| 20:03:33 | | Quit Rondom ("leaving") |
| 20:05:59 | funman | http://pastie.org/713208 < gcc 4.0.3 mod function for arm9tdmi not including div0 |
| 20:06:16 | funman | all I can say is there is many loops |
| 20:07:29 | kugel | dionoea: what values is that gcd called with? total memory addresses? |
| 20:07:29 | minus | http://www.pubbs.net/gcc/200908/10727/ is this anything useful? |
| 20:07:30 | amiconn | That's the slower (but smaller implementation) |
| 20:07:45 | minus | but it looks like it's for the thumb instructionset |
| 20:08:00 | amiconn | It's not as slow as one might think when seeing those loops |
| 20:08:17 | dionoea | kugel: one is the ring buffer size, the other one depends on how much the dst and src buffers overlap |
| 20:08:54 | amiconn | There is another, unrolled implementation for armv5 and higher. I made an armv4 equivalent which is in the codeclib and is used by libdemac |
| 20:10:17 | amiconn | And btw, modulo is faster than a full-fledged div |
| 20:11:07 | minus | because you dont need to count |
| 20:11:42 | funman | i wish we could solder some 128MB SDRAM to Clip/c200v2 and mark them stable |
| 20:13:02 | minus | how much ram does it have normally? 2.5Mbit? |
| 20:13:43 | funman | 2MB + 384kB |
| 20:13:44 | | Quit archibald ("CGI:IRC (EOF)") |
| 20:14:15 | funman | the 384kB are common to all AS3525, some models have an external 2MB (Clipv1, c200v2, m200v4), some 8MB (Fuze, e200v2) |
| 20:14:37 | kugel | amiconn: looking at the gcc source div and mod seems to be done in the same function |
| 20:14:57 | minus | 8MB is already pretty much for embedded devices, isn't it? |
| 20:16:20 | TheSeven | there are devices with 64MB |
| 20:16:34 | | Join webguest22 [0] (n=4dff77ac@giant.haxx.se) |
| 20:16:42 | TheSeven | (ipod video and gigabeat s) |
| 20:16:56 | | Quit webguest22 (Client Quit) |
| 20:17:29 | funman | i think there 1 2 8 16 and 64 (with rockox code for them) |
| 20:17:29 | | Join archibald [0] (n=4dff77ac@giant.haxx.se) |
| 20:17:50 | kugel | 32 too, I don't know of a 1MB one |
| 20:18:09 | amiconn | iFP7xx has 1MB iirc |
| 20:18:09 | | Join Omlet05 [0] (i=omlet05@48.7-65-87.adsl-dyn.isp.belgacom.be) |
| 20:18:13 | | Quit Omlet05 (Remote closed the connection) |
| 20:18:22 | funman | amiconn: and m200 |
| 20:18:28 | | Join Omlet05 [0] (i=omlet05@48.7-65-87.adsl-dyn.isp.belgacom.be) |
| 20:18:33 | gevaerts | and DAX |
| 20:18:50 | funman | DAX has 2 MB according to tools/configure |
| 20:19:11 | AlexP | 32 is the most common for Rockbox targets, no? |
| 20:19:28 | saratoga | HWCODEC are often 1 MB, but hte clip is the smallest target with mostly working SWCODEC |
| 20:19:35 | TheSeven | probably yes, as all of the ipods (besides the 64mb one) have 32mb |
| 20:19:46 | bluebrother | most swcodec target players are 32 |
| 20:19:46 | amiconn | HWCODEC are *all* 2MB |
| 20:19:53 | bluebrother | except the modded players ;-) |
| 20:20:14 | funman | AlexP: true, 25 targets, 14 for 16, 3 for 8, 7 for 64, 5 for 2 |
| 20:20:19 | bluebrother | the recorder was moddable, was it? |
| 20:20:24 | saratoga | i found out the hard way that we build for an 8MB HWCODEC a while back |
| 20:20:24 | amiconn | Yeah, except that of course |
| 20:20:38 | TheSeven | funman: 7 for 64? |
| 20:20:56 | funman | TheSeven: you forgot mrobe500, creativezvm (30 & 60gb), creative zen vision, and lyreproto1 |
| 20:21:01 | amiconn | bluebrother: All archoses are moddable the same way. The architecture is almost the same, only storage and peripherals differ |
| 20:21:19 | bluebrother | amiconn: ah, ok. Interesting to know :) |
| 20:22:13 | JdGordon| | we shouldnt be building for 8mb rec |
| 20:22:36 | | Quit funman ("free(random());") |
| 20:22:43 | | Quit Omlet (Read error: 60 (Operation timed out)) |
| 20:22:56 | * | bluebrother would really like to see Rockbox autodetecting the RAM size for various targets. Like recorder8mb and ipodvideo64mb |
| 20:23:34 | AlexP | yeah, that's be funky |
| 20:23:38 | AlexP | *that'd |
| 20:23:49 | TheSeven | is it that hard actually? |
| 20:23:49 | amiconn | Detection isn't the problem. The memory layout needs to be changed in order to accomodate the variable end address |
| 20:24:18 | bluebrother | that's a problem or "just" work? |
| 20:24:28 | TheSeven | shouldn't it be rather easy to move the audio buffer towards the end of memory and dynamically detect its size? |
| 20:24:32 | JdGordon| | wasnt it discussed in the 07 devcon? |
| 20:24:46 | amiconn | Right now plugin ram and codec ram are located at the end. Both codecs and plugins are linked to fixed addresses, so they can't go behind the core (which varies in size with build |
| 20:24:50 | amiconn | ) |
| 20:25:08 | TheSeven | argh, yes |
| 20:25:20 | JdGordon| | so put them at the start? |
| 20:25:25 | JdGordon| | before the core binary? |
| 20:25:51 | TheSeven | probably impossible for iram (which wouldn't hurt), and it would probably need quite some boot process changes on some devices |
| 20:25:54 | amiconn | I suggested putting plugin + codec ram in the beginning (or directly behind the vectors if they *have* to reside there), but then the binary will be loaded to a different address and needs to memmove itself |
| 20:26:14 | TheSeven | amiconn: ...or we need the bootloader to do that |
| 20:26:27 | JdGordon| | or we use dynamic linking for them :) |
| 20:26:36 | amiconn | Forget dynamic linking |
| 20:26:54 | amiconn | TheSeven: There are several reasons why this won't work |
| 20:26:55 | TheSeven | a 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:03 | amiconn | (1) Old bootloaders |
| 20:27:11 | TheSeven | ...then fix them |
| 20:27:14 | bluebrother | port the linux libc! and malloc! |
| 20:27:17 | * | bluebrother hides |
| 20:27:42 | amiconn | (2) On some targets we're loaded by the OF loader (by default, not even changeable on some of those devices) |
| 20:27:44 | * | JdGordon| chases half-heartedly with the pitchforks |
| 20:27:50 | kugel | what's the problem with memmoving itself? |
| 20:28:15 | TheSeven | why don't we just boot a bootloader through the of bootloader then that loads the rest to the proper address? |
| 20:28:19 | minus | moving code that's being executed |
| 20:28:27 | amiconn | kugel: It's not a problem as such, but it's kinda ugly. It takes time, and linker scripts will become even more complex than they already are |
| 20:28:34 | TheSeven | (or just some stub that does the moving magic in front of the main binary) |
| 20:29:10 | pixelma | huh, interesting, sbs parsing did not fail with wrong parameters in the %Vi (on my Ondio and also in the sim) there are still the colour/shade parameters around in my sbs |
| 20:29:18 | minus | oh god, i have so no clue of processors |
| 20:29:19 | TheSeven | wouldn't this only affect a handful of targets anyways? |
| 20:29:48 | TheSeven | i.e. ipod video and some archoses? |
| 20:29:50 | AlexP | yeah - video, modded archos |
| 20:30:01 | TheSeven | doing it for the ipod shouldn't be too hard |
| 20:30:07 | bluebrother | h100 comes also as 16MB and 32MB |
| 20:30:08 | TheSeven | how do the archoses boot? |
| 20:30:16 | AlexP | bluebrother: Is that the only difference? |
| 20:30:19 | bluebrother | h115 vs. h120 / h140 to be exact |
| 20:30:29 | AlexP | bluebrother: h110 too :) |
| 20:30:47 | * | bluebrother facepalms |
| 20:30:50 | | Join AEnima1577 [0] (n=clbarnob@nc652107a.cns.vt.edu) |
| 20:31:08 | amiconn | bluebrother: Those have more differences than just the ram size |
| 20:31:18 | AlexP | microphone IIRC |
| 20:31:23 | amiconn | Precisely they have opposite s/pdif led polarity |
| 20:31:24 | TheSeven | and we only need that if we can't detect the mem size over usb, right? |
| 20:31:27 | bluebrother | amiconn: releavant differences? |
| 20:31:56 | bluebrother | hmm, ok. Could we detect that? |
| 20:32:04 | AlexP | bluebrother: Sure, by memory size |
| 20:32:05 | amiconn | So if you run a h120 build on an h100 or vice versa, the led would be on when it should be off and vice versa |
| 20:32:11 | gevaerts | TheSeven: less builds |
| 20:32:23 | bluebrother | AlexP: d'oh! Of course :) |
| 20:32:31 | minus | so, why do codec and plugins need to be at a static address? |
| 20:33:08 | amiconn | minus: Simplicity. A dynamic linker would be a lot of extra code |
| 20:33:15 | TheSeven | do they actually really need this, or are most of them position independent anyways? |
| 20:33:34 | TheSeven | probably not as soon as iram is involved though |
| 20:33:41 | amiconn | They're not position independent |
| 20:34:06 | amiconn | That doesn't depend on iram |
| 20:34:28 | bluebrother | would a split audio buffer make sense? |
| 20:34:37 | amiconn | Maybe we could compile them as position independent code. |
| 20:35:06 | gevaerts | position independent code would also open the door for loading multiple plugins at the same time at some point |
| 20:35:09 | amiconn | That might be a worthwile experiment - I have no idea how much code size would increase by this |
| 20:35:10 | TheSeven | amiconn: I think it's quite likely that most of the code is only using PC-relative addressing for both branches and data access |
| 20:35:27 | amiconn | You're thinking arm only |
| 20:35:32 | TheSeven | oh yea... |
| 20:35:39 | amiconn | Rockbox is running on 4 very different CPU architectures |
| 20:35:46 | * | JdGordon| guesses less code would be wasted for this, than keeping a pretty animation for the early usb screen :/ |
| 20:36:06 | | Quit StealthyXIIGer (Read error: 131 (Connection reset by peer)) |
| 20:36:11 | TheSeven | ...with one of them being exactly one target iirc? |
| 20:36:17 | amiconn | I'd also expect buffer addresses to be absolute |
| 20:36:20 | | Join StealthyXIIGer [0] (n=stealthy@c-68-62-19-6.hsd1.mi.comcast.net) |
| 20:36:22 | amiconn | no |
| 20:36:56 | amiconn | All of them cover several targets. SH1 is all old archoses (6 targets not counting mods), Coldfire is irivers and iaudios (5 targets) |
| 20:37:07 | amiconn | MIPS is the Ondas (3 targets atm iirc) |
| 20:37:13 | amiconn | The rest is ARM |
| 20:38:55 | | Quit shai ("Leaving") |
| 20:38:57 | TheSeven | so it's the low-mem targets again that would get the binsize/ramsize hit, which would of course suffer most from it |
| 20:39:38 | JdGordon| | so? |
| 20:39:44 | amiconn | The question is how much the code would enlarge (this would only apply to plugins and codecs, not the core) |
| 20:40:34 | | Quit Omlet05 (Connection timed out) |
| 20:41:46 | TheSeven | did anyone ever check if we actually need this? |
| 20:42:01 | TheSeven | if we are lucky, we could just assume the bigger ramsize in the linker script |
| 20:42:04 | amiconn | "this" being? |
| 20:42:12 | amiconn | No, we can't |
| 20:42:26 | TheSeven | and rely on address bus wrapping to make the codecs/plugins work |
| 20:42:39 | TheSeven | the audiobuffer size would need to be autodetected of course |
| 20:42:45 | TheSeven | at least on s5l870x this would work |
| 20:42:54 | gevaerts | TheSeven: that may work on some systems, but I wouldn't rely on that for all of them |
| 20:42:57 | amiconn | ow |
| 20:43:10 | TheSeven | we could check it nevertheless |
| 20:43:25 | TheSeven | i actually saw apple doing this themselves on s5l8701 |
| 20:43:52 | * | amiconn somehow doubts wrapping will work with the dram addressing scheme |
| 20:44:33 | TheSeven | why? i would expect the higher bits to just be ignored by the memory controller or memory itself |
| 20:45:18 | TheSeven | none of the targets that would need autodetection have an MMU, right? |
| 20:45:45 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 20:46:05 | gevaerts | yes, but position independent code has advantages beyond that |
| 20:46:27 | gevaerts | so I think it's worth investigating independently of the variable ram size anyway |
| 20:46:42 | kugel | amiconn: it would help on numerous targets, so it seems to be worth it |
| 20:47:20 | pixelma | kugel, JdGordon|: %Vi|0|8|-|-|1|-|-| should fail on mom |
| 20:47:27 | amiconn | TheSeven: Correct (no mmu) |
| 20:47:34 | pixelma | err... monochrome but it doesn't |
| 20:47:55 | JdGordon| | yes it should :) |
| 20:47:55 | kugel | maybe |
| 20:47:57 | amiconn | I would expect the memory controller to filter out out-of-range addresses on less primitive SoCs than arm |
| 20:48:02 | dionoea | bertrik: would you be able to test a fixed patch for the clip playback problem ? |
| 20:48:40 | TheSeven | are the archoses really a "less primitive soc"? |
| 20:49:07 | amiconn | That is the question |
| 20:49:18 | amiconn | It's probably worth a test |
| 20:49:57 | TheSeven | i would expect all targets to either have an mmu or to allow wrapping |
| 20:50:42 | amiconn | Still, position independent code would have other advantages as well (like making the dynamic plugin buffer size idea easier) |
| 20:50:55 | TheSeven | does the 2mb/8mb recorder have a different plugin buffer size? |
| 20:51:02 | TheSeven | that would be a major problem... |
| 20:51:35 | amiconn | no |
| 20:51:47 | amiconn | 32KB plugin buffer on all archoses |
| 20:52:15 | | Quit HBK () |
| 20:52:24 | TheSeven | so the only difference is the audio buffer size (and probably also audio buffer descriptor count)? |
| 20:56:31 | amiconn | There is no such thing |
| 20:56:47 | amiconn | The hwcodec playback engine is entirely different (still) |
| 20:56:56 | TheSeven | ah yes, hwcodec of course :-/ |
| 20:57:20 | TheSeven | what is the additional memory being used for then? |
| 20:59:32 | JdGordon| | pixelma: actually... is there really any reaosn why that shuoold fail... why cant we just ignore the last 2 params? |
| 20:59:51 | amiconn | TheSeven: All audio buffer |
| 21:00 |
| 21:00:17 | TheSeven | ok, so you just meant that it doesn't have descriptors? |
| 21:00:39 | pixelma | I seem to remember it failing for other %V or %Vl (maybe I'm confusing it with grey shades and RGB definitions though |
| 21:00:41 | cowgarden | why does rockboy need such a high framerate and than skips frames? is ist becaus eof the sound (and for less choppy sound tha targets are to weak?) |
| 21:01:37 | | Join HBK [0] (n=hbk@97.77.51.170) |
| 21:03:16 | pixelma | JdGordon|: guess that ignoring would also work an be actually simpler (and you get a little more portability) |
| 21:05:12 | pixelma | by the way, you made .grey and .mono only work for classic_statusbar - shouldn't it work for any name? |
| 21:05:32 | | Quit Lear ("ChatZilla 0.9.85 [Firefox 3.5.5/20091102152451]") |
| 21:07:14 | JdGordon| | it shuold.... but I only put it there (buildzip.pl) because I really dont want to mess with wpsbuild.pl |
| 21:07:31 | | Join tomers [0] (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) |
| 21:09:58 | tomers | kugel: ping |
| 21:11:25 | | Quit archibald ("CGI:IRC (EOF)") |
| 21:14:48 | kugel | tomers: pong |
| 21:16:27 | | Quit J-23 (Read error: 104 (Connection reset by peer)) |
| 21:19:27 | | Join J-23 [0] (n=zelazko@unix.net.pl) |
| 21:20:15 | *** | Saving seen data "./dancer.seen" |
| 21:21:37 | tomers | kugel: Hi (sorry for the late response). Do you think I can commit the diacritic patch as it is now? |
| 21:22:13 | kugel | yea, go ahead |
| 21:22:29 | tomers | thanks. I'll play with the lru later on... |
| 21:22:53 | tomers | I'm available by email mostly. RL prevent me from IRCing too much |
| 21:24:23 | tomers | kugel: Do you think this feature should be part of the major features list? |
| 21:24:34 | | Quit Grahack ("Leaving.") |
| 21:25:28 | gevaerts | general diacritics support? I'd think so, yes |
| 21:26:48 | pixelma | does it affect drawing speed for non-diacritc text (much)? |
| 21:27:06 | | Quit Thundercloud (Remote closed the connection) |
| 21:27:53 | kugel | tomers: you decide that :) |
| 21:28:46 | tomers | I think diacritic support affect European languages, Indian, Arabic and Hebrew. It is a major change for users who use these languages |
| 21:30:34 | tomers | pixelma: It doesn't affect the speed for non-diacritic text much, since the character ranges are cached, so the lookup for each char is very cheap in average. |
| 21:32:51 | | Join kugel__ [0] (n=kugel@e178065193.adsl.alicedsl.de) |
| 21:32:57 | gevaerts | hm, isn't there a test_text plugin for this yet? |
| 21:33:03 | | Quit kugel (Nick collision from services.) |
| 21:33:11 | | Nick kugel__ is now known as kugel (n=kugel@e178065193.adsl.alicedsl.de) |
| 21:33:24 | gevaerts | maybe test_gfx will be good enough |
| 21:37:34 | | Join jhggg2 [0] (n=4dfec8ce@giant.haxx.se) |
| 21:37:43 | n1s | Unhelpful: aha, so the aliasing patch should probably go in regardless of gcc switching? |
| 21:38:12 | | Join jh55 [0] (n=4dfec8ce@83.168.254.42) |
| 21:38:36 | | Quit jhggg2 (Client Quit) |
| 21:38:49 | | Join matsl [0] (n=matsl@82.182.85.76) |
| 21:41:16 | gevaerts | if test_gfx is correct (and I have no reason to doubt that), on gigabeat f FS #10720 slows down putsxy by about 15% |
| 21:41:46 | CIA-80 | New commit by tomers (r23742): FS #10720 - Support for displaying diacritic characters ... |
| 21:42:06 | | Quit freddyb ("Konversation terminated!") |
| 21:42:19 | | Quit jh55 (Client Quit) |
| 21:43:01 | gevaerts | whether this is actually noticeable is another question |
| 21:47:50 | | Join Tomis2 [0] (n=Tomis@70.134.101.181) |
| 21:49:11 | tomers | Oh, this is a *huge* bin size increase! |
| 21:51:16 | JdGordon| | thats not huge! |
| 21:51:18 | JdGordon| | someones sense of scale is off :) |
| 21:51:42 | Torne | why is it so much bigger on a coupe le of targets? :) |
| 21:51:59 | tomers | :-) gevaerts: How to test performance of it? What is test_gfx? Is it aplugin? |
| 21:52:16 | Torne | 25kb on zen vision? |
| 21:52:27 | gevaerts | tomers: it's a plugin, yes |
| 21:52:33 | tomers | Torne: No idea. Maybe different compilers. Maybe alignment of the buffer? |
| 21:52:51 | amiconn | ugh |
| 21:53:03 | tomers | gevaerts: So it can give me a good measure of how changes to the code affect performance? |
| 21:53:20 | gevaerts | tomers: I'd expect so |
| 21:53:48 | | Quit Tomis (Connection timed out) |
| 21:53:49 | | Nick Tomis2 is now known as Tomis (n=Tomis@70.134.101.181) |
| 21:54:20 | n1s | tomers: what are diacritic characters and what languages use them? |
| 21:54:37 | AlexP | And it slows down for everything? |
| 21:54:54 | tomers | AlexP: http://en.wikipedia.org/wiki/Diacritic |
| 21:54:57 | AlexP | It wasn't me that asked that |
| 21:55:14 | tomers | AlexP: sorry |
| 21:55:50 | * | gevaerts doesn't understand the delta |
| 21:55:54 | tomers | n1s: Read the array in firmware/drivers/diacritic.c, you can see what language contains diacritic characters. |
| 21:56:11 | gevaerts | According to bloat-o-meter it should be 2148 bytes for gigabeat f |
| 21:56:45 | amiconn | Binsize is |
| 21:56:56 | amiconn | But there's extra ram size increase |
| 21:57:08 | | Join AaronM [0] (n=Aaron@adsl-4-241-124.mem.bellsouth.net) |
| 21:57:11 | amiconn | Hover over the delta to see the details |
| 21:58:10 | AlexP | 15% seems more than "not much" of a performance decrease |
| 21:58:36 | AlexP | But where is this? On all text? |
| 21:58:48 | kugel | wtf happened? |
| 21:58:59 | gevaerts | AlexP: it's a micro-benchmark. That doesn't necessarily mean a 15% slowdown for real text drawing operations |
| 21:59:09 | AlexP | OK |
| 21:59:40 | kugel | it just draws "Rockbox!" a million times or so |
| 21:59:51 | pixelma | did someone test with a lot of text on an Ipod Video? |
| 22:00 |
| 22:00:09 | kugel | where does that increase come from!? |
| 22:00:23 | gevaerts | kugel: static struct lcd_bitmap_char chars[SCROLL_LINE_SIZE]; is my guess |
| 22:00:54 | kugel | ah, that seems like a good guess |
| 22:01:45 | kugel | it looks like the initial patch was less demanding |
| 22:01:55 | tomers | I've just realized that is_diacritic() is called twice for each character. Once when the string width is calculated by font_getstringsize(), and second when it is being displayed, by putsxyofs(). Could this info somehow be saved between calls? Any ideas? |
| 22:02:05 | gevaerts | looks like about 10K for an LCD width of 240 |
| 22:03:00 | tomers | We can decide which languages to remove using #if 0 |
| 22:03:31 | gevaerts | tomers: can't struct lcd_bitmap_char be made more efficient? |
| 22:04:01 | tomers | Notice that in that array, we can use only 3 bytes per entry (Unicode is 0h-0xe01ef, and two more bits for flags). |
| 22:04:22 | gevaerts | tomers: the ranges array is far from the big culprit |
| 22:04:30 | gevaerts | oh wait |
| 22:04:31 | kugel | tomers: the struct is already static, so it's saved between lcd_puts* calls |
| 22:05:12 | tomers | kugel: But the lookup for each character is still done twice. Doesn't it? |
| 22:05:56 | kugel | btw, why (i = 0; i < SCROLL_LINE_SIZE && ucs[i]; i++) instead of (i = 0; i < strlen(str) && ucs[i]; i++) ? |
| 22:06:51 | gevaerts | kugel: you mean calculate strlen(str) every time? |
| 22:07:14 | tomers | kugel: ucs[i] will be 0 on string end, so it acts like strlen |
| 22:07:37 | tomers | the SCROLL_LINE_SIZE is just for buffer overflow protection |
| 22:08:10 | kugel | gevaerts: it loops over SCROLL_LINE_SIZE several times. that seems like a hige waste |
| 22:08:28 | kugel | ah, i see, alriht |
| 22:09:24 | kugel | the bitmap char could probably be 4 bit using bitfields, instead of 12. |
| 22:09:42 | | Join Stephen_ [0] (n=S@86-45-81-113-dynamic.b-ras2.srl.dublin.eircom.net) |
| 22:09:54 | kugel | unless width and base width are able to exceed 35k (?) |
| 22:11:40 | | Join Incognito-AWAY [0] (n=PSPdemon@c-66-177-37-36.hsd1.fl.comcast.net) |
| 22:11:50 | Incognito-AWAY | why is it that here |
| 22:11:55 | Incognito-AWAY | http://www.rockbox.org/wiki/CygwinInstallWithScreenShots |
| 22:12:01 | bluebrother | why is what where? |
| 22:12:15 | Incognito-AWAY | i see the "add url" and i added it and click next |
| 22:12:21 | AlexP | Incognito-AWAY: To show people how to install cygwin |
| 22:12:22 | Stephen_ | can themes from the gallery with the ccbysa license be edited and moved to the themes site ? |
| 22:12:30 | Incognito-AWAY | but it says it cannot get the setup.ini" |
| 22:13:04 | AlexP | Stephen_: sure, as that is the licence the theme site uses it should be fine :) |
| 22:13:10 | Incognito-AWAY | more or less... "Unable to get setupini from <http://download.rockbox.org>" |
| 22:13:22 | Incognito-AWAY | err setup.ini* |
| 22:13:26 | Stephen_ | thanks again AlexP, just have to stay away from the graveyard right. |
| 22:13:55 | Stephen_ | Incognito-AWAY, you have to pass a switch using cygwin, to bypass that. |
| 22:14:03 | AlexP | Stephen_: You can check the graveyard, but I'm pretty sure that everything that is in there has already been checked and isn't permissivly licensed |
| 22:14:04 | Stephen_ | can't off the top of my head remember which. |
| 22:14:14 | Incognito-AWAY | :/ |
| 22:14:23 | AlexP | Stephen_, Incognito-AWAY: -x |
| 22:14:27 | Incognito-AWAY | did that |
| 22:14:36 | Stephen_ | yeah went through it myself as i know soap did too. |
| 22:14:40 | Incognito-AWAY | as it said at the top |
| 22:14:41 | | Join stripwax [0] (n=Miranda@87.194.34.169) |
| 22:14:52 | Stephen_ | ive updated some from the gallery just wasn't sure of the gallery |
| 22:14:55 | | Quit bertrik ("De groeten") |
| 22:15:03 | bluebrother | tomers: is there a reason the struct lcd_bitmap_char chars is static? |
| 22:15:07 | tomers | kugel: Could you explain how the bitmap char could be 4 bit using bitfields, instead of 12 |
| 22:15:24 | gevaerts | bluebrother: you don't want that on the stack |
| 22:15:29 | kugel | first, i meant byte :) |
| 22:16:03 | | Quit stripwax (Client Quit) |
| 22:16:04 | kugel | well, you need 1 bit each for the bools. then you have 30 bits left for width and base width |
| 22:16:17 | tomers | kugel: I said that ten minutes ago. We can use 3-byte for each entry. |
| 22:16:41 | gevaerts | tomers: are you sure we will *never* need more than 256 pixels width? |
| 22:16:54 | bluebrother | gevaerts: hmm. Right. |
| 22:17:36 | kugel | gevaerts: I think that's reasonable to assume ;) |
| 22:17:49 | | Join petur [50] (n=petur@rockbox/developer/petur) |
| 22:17:51 | gevaerts | kugel: really? |
| 22:17:56 | kugel | yea |
| 22:18:17 | tomers | gevaerts: I think I took this limit from other function that handles with text. (bidi?) |
| 22:18:18 | JdGordon| | 256pixels is per glypth or total? |
| 22:18:26 | kugel | glyph |
| 22:18:28 | CIA-80 | New commit by gevaerts (r23743): make lcd_bitmap_char more space efficient. This doesn't seem to impact text drawing performance |
| 22:18:41 | * | gevaerts goes for smallish gains first |
| 22:19:05 | kugel | if 128 is enough it could even be 2 bytes |
| 22:19:49 | tomers | gevaerts: Notice bidi_l2v() in putsxyofs(). |
| 22:19:49 | Incognito-AWAY | Stephen, i type setup.exe -X it brings up the box and everything |
| 22:19:49 | gevaerts | kugel: some people have really bad eyes and use fonts that basically fit only one word on a screen. We have a 640x480 screen, so I'd say that 128 is *definitely* too small |
| 22:19:55 | Incognito-AWAY | but it still gets me to the "Unable to get setup.ini from <http://download.rockbox.org> |
| 22:20:08 | kugel | gevaerts: the max font we have is 40px I believe |
| 22:20:19 | gevaerts | the max fond *we* have, yes |
| 22:20:25 | kugel | and that's a really huge one even for 640x480 |
| 22:20:54 | Incognito-AWAY | nvm there we go |
| 22:21:02 | gevaerts | kugel: yes, but you have good eyes |
| 22:21:11 | JdGordon| | gevaerts: sorry, ou're crazy... 128pixel width means about 4 chars on the screen even at 640x480... |
| 22:21:56 | kugel | on 3 lines! |
| 22:22:07 | gevaerts | JdGordon|: for the absolute widest character of the font |
| 22:22:44 | JdGordon| | I think 40 is a reasonable max.. even 64 to make it a round number |
| 22:22:59 | petur | yellow! red! |
| 22:23:13 | gevaerts | tomers: I'm not sure what I'm looking at there |
| 22:23:52 | tomers | ? |
| 22:23:58 | * | gevaerts did test compile. Why didn't he see that :\ |
| 22:24:09 | gevaerts | tomers: "Notice bidi_l2v() in putsxyofs()" |
| 22:24:30 | bluebrother | gevaerts: you call that a smallish gain? What have we to expect for the next changes? ;-) |
| 22:24:55 | * | gevaerts clearly did something wrong |
| 22:25:40 | tomers | gevaerts: the bidi function has static buffers of a constant size. I guess it won't work for bigger strings? (actually I haven't read it at all - so maybe it does something smart with it) I used the same size. |
| 22:27:00 | gevaerts | tomers: I never questioned that one. I said pixels, not characters :) |
| 22:27:37 | tomers | oh... Actually I overlooked this consideration, so feel free to change |
| 22:27:57 | tomers | gevaerts: BTW nice catch |
| 22:28:16 | | Nick Horschti is now known as Horscht (n=Horscht2@xbmc/user/horscht) |
| 22:28:59 | gevaerts | ok, if everyone feels 255 pixels is really enough... |
| 22:29:15 | | Join LambdaCalculus37 [0] (n=LambdaCa@rockbox/staff/LambdaCalculus37) |
| 22:29:34 | n1s | gevaerts: why the bool->char change, isn't a bool, just a char in disguise anyway? |
| 22:29:52 | gevaerts | n1s: not necessarily |
| 22:29:56 | * | kugel is convinced 127 is enough too, but saving another byte (when each struct is already 3 bytes) doesn't make a huge difference |
| 22:30:20 | amiconn | A bool may be a char or an int, depending on architecture and optimisation level |
| 22:30:27 | kugel | n1s: bool doesn't have a defined size. it can typedef'd to anything |
| 22:30:37 | n1s | amiconn: ah, fun |
| 22:30:51 | amiconn | Similar fun as enums |
| 22:31:03 | kugel | well, it's defined to be "sufficiently large to hold the values 0 and 1", but that's rather useless |
| 22:32:19 | | Quit StealthyXIIGer (Read error: 110 (Connection timed out)) |
| 22:32:25 | kugel | if only there was a proper 24bit type |
| 22:33:32 | kugel | __attribute__((packed)) may give some savings too |
| 22:34:27 | CIA-80 | New commit by gevaerts (r23744): Limit character width to 255 pixels ... |
| 22:34:55 | gevaerts | speed is still the same on gigabeat at least |
| 22:35:11 | bluebrother | that two bool values can get combined as a bitmask or bitfield. |
| 22:35:21 | gevaerts | no bitmap yet. Not awake enough for that :) |
| 22:36:39 | | Quit evilnick (Ping timeout: 180 seconds) |
| 22:37:00 | gevaerts | kugel: I actually would object to the 127 option on the grounds that adding a flag to each width value makes the code unreadable |
| 22:37:37 | kugel | not the flag, but the sign. that should make it a bit better readable :) |
| 22:38:18 | kugel | but I agree in general. I already said it's not so much worth it anyway (it would probably also add code complexity) |
| 22:38:42 | bluebrother | gevaerts: still some yellow, and now some red too. |
| 22:39:04 | amiconn | The diacritics support code looks broken |
| 22:39:04 | gevaerts | damn, committed too many files :\ |
| 22:39:15 | bluebrother | hmm, in test_gfx ... |
| 22:39:51 | | Join einhirn [0] (n=Miranda@p5DCC16BA.dip0.t-ipconnect.de) |
| 22:39:58 | amiconn | It will produce completely wrong results if the original drawmode is DRMODE_COMPLEMENT |
| 22:39:58 | | Join mrtok1 [0] (n=dummy@p5B39C5E0.dip.t-dialin.net) |
| 22:40:02 | | Join n00b81 [0] (n=n00b81@unaffiliated/n00b81) |
| 22:41:17 | pixelma | what's with the "Failed regex: line above the download table" (not the build table)? |
| 22:41:25 | amiconn | tomers ^^ |
| 22:41:52 | pixelma | hmm... the second " should be a few words earlier |
| 22:42:15 | tomers | amiconn: I am sorry, bu t I don't understand what '^^' means :-) |
| 22:42:28 | amiconn | Reference two lines above |
| 22:43:04 | CIA-80 | New commit by gevaerts (r23745): revert accidental commit |
| 22:43:40 | | Part n00b81 ("Leaving") |
| 22:43:51 | * | gevaerts hopes for all-green again and will leave further discussion to others |
| 22:44:21 | mrtok1 | Q: Does someone know if profiling with gprof is working on the targets ? Or how could I manage to measure code performance? |
| 22:44:38 | tomers | amiconn: This is something I left from the original work done in the patch. I don't understand much vp flags which relate to draw modes... Can you manage to fix this yourself? |
| 22:44:54 | | Quit bimbel ("Bye!") |
| 22:45:09 | amiconn | tomers: Afaics it is completely unfixable in current form |
| 22:45:51 | amiconn | You need to pre-render the current character with all its diacritics at least (in mono) and then finally draw that |
| 22:46:48 | TaZzZ | will avi files work on rockbox .. or only mpeg |
| 22:46:54 | AlexP | mpeg 1/2 |
| 22:47:06 | AlexP | See www.rockbox.org/wiki/PluginMpegplayer |
| 22:47:12 | n1s | mrtok1: profiling should work with the profiling functionality built into rockbox (see wiki or docs/TECH for an intro |
| 22:47:42 | AlexP | TaZzZ: Also, avi is a container that can contain many different codecs |
| 22:47:58 | TaZzZ | xvid ... is the file |
| 22:48:01 | n1s | you cna also devise your own benchmarks of course, may or may not give usefull info of course |
| 22:48:18 | AlexP | TaZzZ: Anyway, my previous answer stands |
| 22:49:28 | amiconn | Hmm, actually it looks fixable, the inner loop needs to be done quitedifferently though |
| 22:49:39 | tomers | amiconn: Should I open FS bug for that? |
| 22:50:12 | tomers | I actually don't know how to fix it myself (unless I'll dive into that code, which takes time) |
| 22:50:13 | amiconn | And we'll need an extra buffer that can hold one char's bitmap |
| 22:50:51 | mrtok1 | n1s: ohh - thank you - do you have a pointer? okay - found http://www.rockbox.org/wiki/SourceProfiling will try that - thx! One other question: Do you know a _free_ tool to calculate mips of code sections ? |
| 22:51:01 | amiconn | Basically you can't just change the draw mode to something else irrespective of the original mode and expect the result to look as intended |
| 22:51:51 | mrtok1 | I mean: function x tooks 2 seconds with 80MHz core clock for example :o) |
| 22:52:33 | amiconn | And with DRMODE_COMPLEMENT (which means XORing pixels), overdrawing this way will cause odd results if the diacritics and the base char both have common pixels set |
| 22:52:33 | amiconn | There will be a hole |
| 22:53:07 | n1s | mrtok1: yeah, that is the wiki page i meant, don't know of any such tool but doesn't sound too hard to calculate if you know the clock frequency and cycles spent in the function |
| 22:53:16 | amiconn | So you need to combine the char and its diacritics in a temp buffer using OR, and then draw the final bitmap instead of the chars, without touching the drawmode |
| 22:54:39 | | Quit n1s ("Lämnar") |
| 22:54:50 | mrtok1 | n1s: hope that the profile.out will give me this informations... - thx + bye |
| 22:55:05 | | Nick Topy is now known as Topy44 (n=Topy44@f048059001.adsl.alicedsl.de) |
| 22:55:20 | | Quit mrtok1 () |
| 22:57:50 | | Quit dmb (Read error: 104 (Connection reset by peer)) |
| 22:59:19 | | Quit Horscht ("Verlassend") |
| 22:59:22 | gevaerts | actually, I don't really see why it loops three times from 0 to len. Isn't it possible to combine those, and eliminate the huge chars[] in one go, since you'd only need to store one "real" character's worth of chars anymore (i.e. 5 or so. How many diacritics can be used in a row realistically?)? |
| 23:00 |
| 23:02:32 | | Quit fyrestorm (Read error: 104 (Connection reset by peer)) |
| 23:03:31 | tomers | gevaerts: I'll fix that, but not today (got to go). |
| 23:03:40 | tomers | amiconn: Fixing this will take some more time... |
| 23:04:25 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 23:04:39 | gevaerts | tomers: sure. It works now (except for the problem amiconn pointed out), saving RAM is good, but not don't-go-to-sleep critical |
| 23:04:44 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
| 23:05:01 | tomers | gevaerts: :-) leaving now |
| 23:05:09 | | Quit tomers ("ChatZilla 0.9.85 [Firefox 3.5.5/20091109125225]") |
| 23:06:33 | | Join evilnick [0] (i=4571af51@rockbox/staff/evilnick) |
| 23:08:55 | amiconn | Is there some test text for this? |
| 23:09:47 | | Quit einhirn (Read error: 104 (Connection reset by peer)) |
| 23:10:11 | | Join n00b81 [0] (n=n00b81@unaffiliated/n00b81) |
| 23:10:11 | | Join Strife89 [0] (n=michael@adsl-146-208-69.mcn.bellsouth.net) |
| 23:10:25 | Incognito-AWAY | another svn commit? |
| 23:10:33 | Incognito-AWAY | cause....it stopped....again |
| 23:10:38 | kugel | gevaerts: are you saying ram waste is not worth overtime? :) |
| 23:11:06 | gevaerts | kugel: only the day before a release :) |
| 23:11:14 | | Join polobricolo [0] (n=polobric@AGrenoble-257-1-21-117.w86-194.abo.wanadoo.fr) |
| 23:11:14 | | Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) |
| 23:11:43 | gevaerts | amiconn: I believe that http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt has some combining characters in it |
| 23:15:01 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
| 23:17:09 | | Quit LambdaCalculus37 ("Leaving") |
| 23:18:47 | | Join fyrestorm [0] (n=nnscript@cpe-69-203-150-85.si.res.rr.com) |
| 23:20:17 | *** | Saving seen data "./dancer.seen" |
| 23:21:33 | froggyman | is there an example sbs for the iPod video? |
| 23:22:10 | | Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
| 23:26:06 | kugel | can we stop people from uploading custom filetype colors with their themes? |
| 23:26:07 | | Join efyx_ [0] (n=efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 23:27:19 | AlexP | why? |
| 23:27:26 | AlexP | Aren't they part of a theme? |
| 23:27:26 | pixelma | it's a theme setting, I thought? |
| 23:27:49 | Llorean | I'd expect custom filetype colours to qualify as a part of a "theme" |
| 23:28:00 | | Quit polobricolo (Remote closed the connection) |
| 23:28:03 | | Part n00b81 ("Leaving") |
| 23:29:09 | Stephen_ | how do you clear that setting ? |
| 23:29:58 | * | bluebrother thinks that alternating row colors in lists would be a nice feature |
| 23:30:28 | bluebrother | background color that is |
| 23:30:32 | | Quit matsl (Read error: 145 (Connection timed out)) |
| 23:30:36 | AlexP | not text colour? :) |
| 23:30:50 | bluebrother | no, text color is boring ;-) |
| 23:30:59 | kugel | I don't see filetype colours as a part of a theme, but rather a usability improvment or accesibility feature |
| 23:31:19 | AlexP | I see it very much as a theme thing |
| 23:31:46 | kugel | it uses colors, it must be part of a theme! |
| 23:31:50 | Llorean | Filetype colours is a theme thing that may be used as a usability improvement or accessibility feature, much like fonts are. |
| 23:31:54 | kugel | or colours, if you like |
| 23:31:56 | AlexP | kugel: don't be silly |
| 23:32:16 | Unhelpful | n1s: i think so, and the bulk of codecs (for files in the test set) perform better under strict aliasing with -O3, also |
| 23:32:29 | Llorean | kugel: It primarily affects the visual or aesthetic appearance of the user interface without changing functionality - very much a theme value. |
| 23:32:42 | bluebrother | well, filetype colors is somewhat similar to filetype icons. So ... |
| 23:32:46 | Stephen_ | anyone having problems with recording on e200v2 ? |
| 23:33:13 | | Quit AEnima1577 ("Leaving.") |
| 23:33:15 | kugel | so, how I can I clear that easily? Only per deleting the file? |
| 23:33:24 | AlexP | That is a different issue |
| 23:33:28 | | Quit stripwax (Success) |
| 23:33:36 | Unhelpful | for 4.0.3 with -fstrict-aliasing -O3 is faster for ape, aac, flac, mpc, vorbis, and wma (on arm11) |
| 23:33:44 | Llorean | Doesn't it require a .cfg to *set* filetype colors? |
| 23:33:49 | AlexP | yes |
| 23:33:59 | Unhelpful | i would *expect* the arm9 targets to perform similarly, they did with -fstrict-aliasing |
| 23:34:00 | Llorean | So it seems perfectly reasonable it also requires one to clear it. |
| 23:34:11 | Unhelpful | without rather |
| 23:34:13 | AlexP | but if a theme sets it, it isn't easy to clear them but keep the rest of the theme |
| 23:34:35 | pixelma | or clearing that lin in your config.cfg |
| 23:34:56 | AlexP | But the lack of an easy way to clear filetype colours means that the lack of easy way to clear them should be fixed, not that we should stop people using the colours |
| 23:34:57 | pixelma | line too |
| 23:34:58 | * | kugel can't complain |
| 23:35:05 | | Part CaptainKwel |
| 23:35:11 | kugel | the UI vp works the same way (apparently) :) |
| 23:36:01 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 23:36:32 | Llorean | AlexP: That the very least the default theme should include clearing filetype colors. That would be the first obvious fix whether or not we're going to have a "Reset filetype colours" setting. |
| 23:36:48 | AlexP | yep |
| 23:37:09 | kugel | it could be a reset_ft_colors.cfg in the theme dir if it's handled by a confi.cfg line |
| 23:38:10 | Llorean | kugel: That'd be a quick fix, but an actual menu entry would be nice. |
| 23:38:32 | kugel | wait, did you just say that? :p |
| 23:38:43 | Llorean | I'm pretty sure just having a blank entry instead of a .colours filename is all it takes to reset it. |
| 23:39:05 | bluebrother | Llorean: why a menu entry? You can't set it via a menu either. |
| 23:39:21 | kugel | custom statusbar brought up some awesome themes already imo |
| 23:39:31 | Llorean | bluebrother: If you pick a theme and then don't like the font, you can change the font. If you pick a theme and don't like the filetype colors it brings with it, you can't reset them to default without never using that theme until you text-edit the file |
| 23:39:50 | Llorean | It'd be nice if you could pick a theme, then after choosing it, turn parts of it off and then "save theme settings" |
| 23:39:58 | bluebrother | loading a theme could also implicitly reset the colors if they are not set by the theme |
| 23:39:58 | Llorean | So even if you can't turn filetype colors on by hand, turning them off by hand seems necessary |
| 23:40:00 | | Quit petur ("Zzzzz") |
| 23:40:11 | kugel | maybe a special dir for various reset_* files, then a menu entry for browing that dir |
| 23:40:18 | bluebrother | well, most themes are pretty much bound to the font used. |
| 23:40:33 | | Quit FlynDice (Remote closed the connection) |
| 23:40:37 | Llorean | Font size, but not necessarily font |
| 23:40:48 | Llorean | And viewports adds a great deal of flexibility in terms of choosing smaller fonts at least |
| 23:41:01 | bluebrother | so for various settings it's questionable if it's a good idea to allow changing things separately. |
| 23:41:24 | bluebrother | of course it's convenient to quickly change e.g. the font :) |
| 23:41:37 | Llorean | Well, filetype colors should be changeable separately if we allow them to change other color values (background color, foreground color, line highlight, backdrop image) |
| 23:41:40 | Llorean | Since they can conflict very easily |
| 23:43:24 | kugel | we need to add the filetype color settings to THEME_SETTINGs in the code then, so that it creates the clearing entry when you select "Save theme Settings" |
| 23:44:10 | Llorean | Sounds like a good idea. |
| 23:45:31 | | Join FlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) |
| 23:45:33 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 23:45:38 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 23:46:29 | kugel | "MediaFlo for E200v2" would probably look extremely awesome with anti-aliased fonts (hint hint Unhelpful ) |
| 23:47:31 | pixelma | why do targets without rsbs get that in the zip? |
| 23:48:05 | pixelma | and it still works differently than RWPSs (which is a nice way IMO) |
| 23:48:40 | pixelma | or at least it looks like it works differently seeing the result |
| 23:48:55 | Stephen_ | kugel, you have a e200v2 right |
| 23:48:58 | kugel | no |
| 23:49:31 | Stephen_ | ah, recording i think has a bug but i want to check before posting to fs |
| 23:49:38 | kugel | arg, people apparently don't use the "save theme settings" feature |
| 23:49:59 | kugel | most themes don't reset the ui vp |
| 23:50:18 | Llorean | kugel: Maybe we could make the "save theme settings" feature export an additional line, and only accept themes with that line? |
| 23:50:29 | AlexP | kugel: Maybe most themes are from before that? |
| 23:50:41 | Llorean | I suspect most people who don't use about it simply don't know about it, so when their theme is rejected the site can simply say "Please use Save Theme Settings to export your theme, and upload that .cfg file" |
| 23:50:47 | minus | i wonder if you could possibly run gba roms on the fuze |
| 23:50:47 | kugel | ui vp is older than the theme page IIRC |
| 23:50:48 | Llorean | AlexP: That feature predates the site, I think. |
| 23:51:05 | Llorean | Er, sorry |
| 23:51:10 | Llorean | Save theme settings, I mean. |
| 23:51:11 | * | Llorean doesn't know about the viewport |
| 23:51:13 | pixelma | ui vp? |
| 23:51:39 | AlexP | Llorean: I meant the ui vp |
| 23:51:59 | kugel | Llorean: that sounds like a good idea |
| 23:52:03 | Llorean | AlexP: Yeah, I realized that after I said it. |
| 23:52:11 | Unhelpful | "MediaFlo"? |
| 23:52:33 | kugel | yea |
| 23:52:42 | kugel | go work on AAF, that theme badly needs it ) |
| 23:52:47 | kugel | :)* |
| 23:53:01 | Llorean | kugel: It won't be perfect since people can still add the line by hand, but I think it'll improve things a lot just because people will become aware of the menu setting. Maybe even reject themes that don't include every exported estting explicitly, though I don't know how easy that would be. |
| 23:53:33 | pixelma | Llorean: maybe just check for the presence of certain line like backdrop, ui vp, foreground and background colour. No need to add something to the Rockbox binary IMO |
| 23:53:42 | kugel | well, adding the line by hand could interpreted as "I intentionally leave some settings out" |
| 23:53:49 | AlexP | That is quite a good idea - it'll force reset settings that the theme authors don't know about/have forgotten about |
| 23:54:32 | Llorean | pixelma: That could work. Require lines that are necessary to reset things. |
| 23:54:40 | pixelma | or maybe for "all lines that have to be there if the creator used 'save theme settings'" |
| 23:54:47 | Llorean | If you wish to add something that would be reset later, load the theme, then load the other things. |
| 23:55:49 | | Quit Strife89 (Read error: 110 (Connection timed out)) |
| 23:57:36 | * | kugel would favor the generated line |
| 23:57:56 | kugel | adding it by hand can really mean "I leave the icon set out, my theme works with any" |
icon identifies that the person is a core developer (has commit access).