| 00:00:56 | kugel | amiconn: the debug code would exit/scroll if an action comes in, therefore (if not all buttons are known) only known buttons could change the menu. without buttons it would be plain "view only", not different from what we have now |
| 00:01:49 | amiconn | Sometimes the keymap exists before the target code to read the buttons |
| 00:02:38 | kugel | that doesn't lead to button presses |
| 00:03:35 | kugel | apps code can only react on actions if the button code is able to read buttons (i.e. able to send the actions in the first place) |
| 00:04:27 | amiconn | Yes, but you may have half-working code, and want to monitor ports while mashing random buttons |
| 00:05:10 | * | kugel doesn't see how that makes a difference |
| 00:05:22 | kugel | only known buttons can ever result in something |
| 00:06:08 | amiconn | Sure. Some buttons may already be known, and you want to figure out interdsependencies? |
| 00:06:25 | kugel | on the other hands, targets like the clip would take advantage; we know have a home-brewed scrolling like mechanism in the target debug function |
| 00:06:43 | kugel | that also requires pressing a button |
| 00:06:57 | amiconn | Really, this discussion is not new |
| 00:07:13 | amiconn | Believe me - using standard UI mechanisms for ports debug is highly annoying |
| 00:07:41 | | Join bubsy_ [0] (n=bubsy@94.139.72.137) |
| 00:07:44 | | Quit bubsy_ (Read error: 54 (Connection reset by peer)) |
| 00:07:46 | kugel | it was just an idea, my patch isn't about that |
| 00:09:37 | | Quit bmbl ("Bye!") |
| 00:09:38 | | Nick |D|Strife89 is now known as |H|Strife89 (n=michael@adsl-154-13-227.mcn.bellsouth.net) |
| 00:11:48 | | Join kyle6513 [0] (n=kyle6513@58.174.128.189) |
| 00:12:20 | | Quit kugel ("Ex-Chat") |
| 00:19:41 | | Join shotofadds [0] (i=rob@rockbox/developer/shotofadds) |
| 00:23:38 | *** | Saving seen data "./dancer.seen" |
| 00:23:49 | | Join shot0fadds [0] (n=rob@80-44-101-32.dynamic.dsl.as9105.com) |
| 00:24:19 | | Quit shot0fadds (Read error: 104 (Connection reset by peer)) |
| 00:24:40 | | Join shot0fadds [0] (n=rob@80-44-101-32.dynamic.dsl.as9105.com) |
| 00:26:05 | | Quit shot0fadds (Client Quit) |
| 00:28:39 | TheSeven | linuxstb: i think i know what's going in with the wheel |
| 00:29:08 | linuxstb | TheSeven: Nice. Does that mean you know how to fix it? |
| 00:29:21 | TheSeven | possibly, still need to try around |
| 00:29:52 | TheSeven | in fact, the wheel seems to be working, it's rather the SoC's SPI controller that's going nuts when the wheel is powering up |
| 00:30:15 | TheSeven | i just dumped what's going on there, and am seeing bit-shifted valid clickwheel packets |
| 00:30:30 | TheSeven | so let's see how to reset that beast |
| 00:32:11 | | Quit shotofadds (Read error: 145 (Connection timed out)) |
| 00:32:36 | TheSeven | bah. the datasheet doesn't match |
| 00:34:25 | linuxstb | Nothing new then... |
| 00:34:32 | saratoga | linuxstb: for what its worth I don't see much difference between "Unusable" and "early development" |
| 00:34:42 | saratoga | if a target doesn't have playback I'd say its both |
| 00:35:03 | saratoga | but I do like the idea of moving some of our targets around (ipods without charging for instance) |
| 00:35:34 | linuxstb | saratoga: "Unusable" would mean that Rockbox builds and runs but has problems. "early development" are things that might not even build any more. |
| 00:35:52 | linuxstb | The idea is basically to spread out the targets in more categories. |
| 00:36:15 | saratoga | is it really useful to do that though? either way such targets are developers only, and developers should know that already |
| 00:36:46 | linuxstb | I just don't think that a target like the beast deserves to be in the same category as something like the Elio |
| 00:37:10 | saratoga | the beast is just waiting for someone to clean up the install directions |
| 00:37:49 | saratoga | aside from the fact that its nearly impossible to install without asking on IRC, the beast would be in the middle teer already |
| 00:38:25 | linuxstb | Yes, the beast is probably a bad example, as the port itself is so far more advanced than the install procedure/instructions. |
| 00:39:04 | linuxstb | But what about something like the clip? IIUC, Rockbox runs OK on it, but buggy. That's better than the targets where Rockbox doesn't even build. |
| 00:39:26 | saratoga | the clip really isn't useful to users at this point though given that it crashes so much |
| 00:39:40 | saratoga | imo they shouldn't worry about the clip except if they want to watch its development status |
| 00:40:23 | saratoga | basically I dislike the idea of catagorizing ports that users shouldn't be looking at . . . |
| 00:40:49 | saratoga | both because I think its misleading and because I think most developers won't bother to properly promote their ports |
| 00:40:54 | linuxstb | I see your point, but I don't think that list has to be just for users though. As a developer, I would like to know the status of all those targets a little more - I haven't a clue about them... |
| 00:41:15 | saratoga | we have the targetstatus wiki page |
| 00:41:31 | saratoga | IMO its worked extremely well |
| 00:41:34 | linuxstb | Why is it misleading? They're called "unusable". I guess I'm just adding a new category underneath there. |
| 00:41:59 | saratoga | i suppose |
| 00:42:18 | linuxstb | But forgetting that for the moment, you agree with renaming "Unstable" to "Usable", and shuffling some devices around? |
| 00:42:36 | saratoga | yes that seems sensible |
| 00:42:45 | saratoga | what is the top teer called? |
| 00:42:47 | | Quit ender` (" Washing your car to make it rain doesn't work.") |
| 00:43:11 | linuxstb | In my email I kept it as "Stable". But we could choose something else - I had considered "Mature" |
| 00:43:56 | saratoga | something to suggest that usable ports are potientially a lot less friendly to use |
| 00:44:45 | saratoga | actually I rather liked unstable just because it discouraged people who were likely to screw up with the command line installer from even trying |
| 00:45:24 | linuxstb | Ports like that should be in "Unusable". |
| 00:45:42 | linuxstb | So I guess I may be suggesting that some current "Unstable" ports go down a category. |
| 00:45:47 | linuxstb | (and hence my fourth category) |
| 00:46:25 | saratoga | linuxstb: rockbox on the fuze is quite usuable, you just need to be able to copy and paste and a single command from a web page into a command line window |
| 00:46:31 | saratoga | some people have a lot of trouble with that |
| 00:46:32 | linuxstb | i.e. "Stable" and "Usable" should be more or less what the current "Stable" catgeory is. Then "Unstable" becomes "Unusable" and then early development undernearth. |
| 00:47:05 | linuxstb | saratoga: As long as it's documented, I don't see a problem with that. But doesn't rbutil handle it now? |
| 00:48:06 | | Quit robin0800 (Remote closed the connection) |
| 00:48:07 | saratoga | it does but lots of middle teer targets may not have rbutil support |
| 00:48:46 | saratoga | i recall one person sending me about 5 angry PMs because he couldn't figure out how to copy and paste that one line into a windows command line |
| 00:48:59 | saratoga | and was furious that we expected him to be able to do that |
| 00:49:04 | linuxstb | Yes, but I would still call them "usable". Some users will of course struggle with any command-line install procedure though, and we should aim to get things in rbutil (or an easy-to-use command-line util like sansapatcher or ipodpatcher) asap. |
| 00:49:10 | saratoga | clearly he needed to be encouraged to wait for top teer support |
| 00:49:54 | linuxstb | Don't let one person cloud your view of our users - most people can handle it, it's just the vocal idiots that cause problems. |
| 00:50:13 | kyle6513 | if i may butt in here, i believe all they need is a simple batch file download, that should fix the problem for copying the line. |
| 00:50:44 | kyle6513 | batch files even have input if you really need it |
| 00:50:55 | saratoga | the whole point of the catagory system is to discourage users who are simply too stupid to read what they are installing |
| 00:51:10 | ShapeShifter499 | on r23121M the database hasn't been working |
| 00:51:12 | saratoga | if we assume users are intelligent and can become informed then we should just link the device status port and let them decide |
| 00:51:52 | saratoga | "device status page" rather then "port" |
| 00:52:17 | | Quit pamaury ("exit(*(int *)0 / 0);") |
| 00:53:09 | linuxstb | saratoga: I disagree. I would say the point is to have a clear central place where the status of ports is clearly shown. If an install procedure is too hard for end-users, then the port shouldn't go into "Usable". |
| 00:53:25 | | Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) |
| 00:54:10 | ShapeShifter499 | how do I get a svn of a earlier build? |
| 00:54:17 | saratoga | we do have a clear central place for status, its the DeviceStatus wiki page |
| 00:54:55 | saratoga | its color coded and everything |
| 00:55:12 | ShapeShifter499 | I want 23088 |
| 00:55:13 | linuxstb | saratoga: Yes, but that's just an expanded version (or at least should be) of what's on the home page. |
| 00:55:49 | linuxstb | saratoga: Although I've lost track of what we're arguing about - are you now saying you're happy with how the front page is now? |
| 00:55:59 | saratoga | but its really not since on the front page we're not actually saying anything about what a port can do, only about how useful we think it is to some average user |
| 00:56:10 | saratoga | i like the idea of moving things around on the front page |
| 00:56:23 | saratoga | i just don't see much sense in putting information about targets that aren't useful to developers |
| 00:56:37 | saratoga | originally i didn't even put the unusable targets on the front page, but instead a link to the wiki |
| 00:56:38 | kyle6513 | it says in giant bold letters PORT STATUS |
| 00:56:41 | saratoga | but someone else changed that |
| 00:56:45 | kyle6513 | dont understand how it would be hard to find that |
| 00:57:45 | saratoga | i dont really disagree with mentioning that they exist on the front page, as its a good way to interest people in development, but I do think we should say as little as possible beyond "its in progress and you're welcome to help" |
| 00:57:50 | TheSeven | linuxstb: which interrupt was the lock switch one? |
| 00:58:06 | saratoga | "go look at the device status wiki page and see for yourself" |
| 00:58:15 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 00:58:35 | linuxstb | TheSeven: I can't remember... |
| 00:59:35 | saratoga | huh the linux development guide doesn't say to checkout the source code, but goes straight to running rockboxdev.sh |
| 00:59:42 | ShapeShifter499 | well? |
| 00:59:50 | linuxstb | ShapeShifter499: See the UsingSVN wiki page |
| 01:00 |
| 01:00:09 | ShapeShifter499 | ok |
| 01:00:45 | linuxstb | saratoga: Which one? This one does - http://www.rockbox.org/wiki/LinuxSimpleGuideToCompiling |
| 01:01:04 | saratoga | linuxstb: ah that one is better, the one on the development guide does not |
| 01:01:10 | saratoga | linked from the front page |
| 01:01:27 | ShapeShifter499 | found it |
| 01:01:29 | ShapeShifter499 | tnx |
| 01:01:45 | saratoga | http://www.rockbox.org/wiki/DevelopmentGuide |
| 01:02:50 | saratoga | fixed |
| 01:03:09 | kyle6513 | linuxstb, has there been any progress on the ftl bug? |
| 01:03:09 | saratoga | although that simple guide is fucking awful |
| 01:03:42 | kyle6513 | saratoga, i followed it and it worked fine for me and i have never used SVN in linux before |
| 01:03:45 | linuxstb | kyle6513: Read the Rockbox commit messages - see the front page of the site, and the "last four weeks" link underneath. |
| 01:04:14 | kyle6513 | linuxstb, thanks |
| 01:04:45 | saratoga | yes but its a wall of text and pointless smile gifs |
| 01:04:49 | | Quit tmzt (Read error: 104 (Connection reset by peer)) |
| 01:06:23 | kyle6513 | saratoga, that is true |
| 01:08:54 | saratoga | its only simple in that it talks down to you, not in that its actually simple to read |
| 01:09:36 | | Quit GeekShadow ("The cake is a lie !") |
| 01:14:53 | | Nick |H|Strife89 is now known as |W|Strife89 (n=michael@adsl-154-13-227.mcn.bellsouth.net) |
| 01:17:03 | saratoga | i wonder why running rockboxdev.sh seems to use only a single processor for compiling |
| 01:21:12 | | Quit DerPapst ("Leaving.") |
| 01:22:06 | | Nick fxb is now known as fxb__ (n=felixbru@85.214.97.64) |
| 01:23:25 | ShapeShifter499 | I 2g2 |
| 01:24:19 | ShapeShifter499 | *g2g |
| 01:24:19 | ShapeShifter499 | bye |
| 01:24:19 | | Part ShapeShifter499 |
| 01:27:09 | TheSeven | linuxstb: IIRC you said that the hold switch is connected to an IRQ. However I can't find it? |
| 01:27:35 | linuxstb | TheSeven: I sort of remember saying that... Let me grep my own logs... |
| 01:27:50 | TheSeven | i already greped mine and didn't find it |
| 01:28:06 | TheSeven | i can only find you saying which GPIO it is |
| 01:28:20 | linuxstb | "interrupt 4 seems to fire when the hold switch is turned on" |
| 01:28:48 | linuxstb | July 18th, 14:10 in #linux4nano-dev |
| 01:32:13 | | Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) |
| 01:33:06 | | Join Lynx [0] (n=Lynx@xdsl-87-78-37-224.netcologne.de) |
| 01:33:33 | | Nick Lynx is now known as Guest19873 (n=Lynx@xdsl-87-78-37-224.netcologne.de) |
| 01:33:45 | TheSeven | ah, you spelled it out... |
| 01:34:09 | TheSeven | with int 4 you mean 0x10? |
| 01:34:18 | linuxstb | I would imagine so |
| 01:37:07 | TheSeven | that bit doesn't seem to ever turn up in SRCPND |
| 01:37:33 | linuxstb | This was from loader.htm - so maybe the OF enabled it somehow. |
| 01:39:49 | | Join Capt_Blackwood1 [0] (n=alexande@ip68-104-118-78.lv.lv.cox.net) |
| 01:40:38 | | Quit MethoS- (Remote closed the connection) |
| 01:41:15 | | Join Eragon55 [0] (n=chatzill@d24-57-166-201.home.cgocable.net) |
| 01:41:27 | Capt_Blackwood1 | hello |
| 01:42:37 | | Join intrados1 [0] (n=intrados@cpe-75-187-57-252.columbus.res.rr.com) |
| 01:43:22 | | Quit intrados (Read error: 110 (Connection timed out)) |
| 01:43:47 | TheSeven | shit |
| 01:43:58 | TheSeven | diagmode doesn't reinit the clickwheel either - it has the same bug as rockbox |
| 01:44:07 | TheSeven | so no use poking around in there |
| 01:45:48 | Capt_Blackwood1 | how's the work on the iPod 6th Gen Classic going? |
| 01:46:14 | kyle6513 | didnt he already ask that in #linux4nano? |
| 01:46:25 | TheSeven | he did. |
| 01:46:33 | * | linuxstb considers it answered |
| 01:46:36 | kyle6513 | -.- |
| 01:46:58 | kugel | saratoga: you need to hack -j in, or use MAKE_FLAGS (or whatever than env var was called) |
| 01:47:14 | Capt_Blackwood1 | i was askin about the "Rockbox" i know about "iPodLinux" |
| 01:47:39 | linuxstb | Capt_Blackwood1: The answer is the same. |
| 01:47:46 | Capt_Blackwood1 | oh |
| 01:47:51 | TheSeven | ...and linux4nano isn't ipodlinux either |
| 01:47:58 | | Part Capt_Blackwood1 |
| 01:47:59 | | Quit Lynx_ (Read error: 110 (Connection timed out)) |
| 01:47:59 | | Nick Guest19873 is now known as Lynx_ (n=Lynx@xdsl-87-78-37-224.netcologne.de) |
| 01:54:38 | | Quit Thundercloud (Remote closed the connection) |
| 01:57:05 | rasher | saratoga: yeah, set MAKEFLAGS="-jX" before running rockboxdev.sh |
| 01:57:23 | | Join webguest56 [0] (n=5b03d6f9@giant.haxx.se) |
| 01:57:41 | rasher | Better yet, set a reasonable default value in your login script |
| 01:57:54 | saratoga | how would i do that? |
| 01:58:04 | TheSeven | linuxstb: I have a working, but very ugly, fix for that wheel issue now |
| 01:59:06 | rasher | saratoga: add export MAKEFLAGS="-j 4" to ~/.bashrc (or your shell's login script) |
| 01:59:25 | linuxstb | TheSeven: Do you have a patch? |
| 01:59:28 | | Join JackWinter3 [0] (n=jack@vodsl-10804.vo.lu) |
| 02:00 |
| 02:00:30 | TheSeven | linuxstb: http://pastie.org/650914 |
| 02:01:02 | TheSeven | i really need a better trigger for that |
| 02:01:39 | | Quit Eragon55 ("ChatZilla 0.9.85 [Firefox 3.0.14/2009082707]") |
| 02:02:40 | | Quit Rob2223 (Read error: 110 (Connection timed out)) |
| 02:03:25 | | Quit JdGordon ("Leaving.") |
| 02:04:17 | linuxstb | TheSeven: Isn't there already code for that in that file? |
| 02:04:39 | linuxstb | (search for calls to opto_i2c_init) |
| 02:04:54 | TheSeven | no, that's something different |
| 02:05:02 | TheSeven | and it isn't called for nano2g |
| 02:05:48 | TheSeven | oh, you mean the one at the end of the file |
| 02:05:57 | linuxstb | Yes. |
| 02:06:38 | linuxstb | Maybe those could be functions (static inline?) defined in the target-specific parts of the file - e.g. disable_wheel and enable_wheel |
| 02:07:26 | TheSeven | for now I'll just add an else to that ifdef |
| 02:08:19 | | Nick Naked is now known as Hadaka (n=naked@naked.iki.fi) |
| 02:11:35 | * | TheSeven just tried powering down the clickwheel SPI controller while hold is on, but then it breaks again |
| 02:12:05 | CIA-85 | New commit by theseven (r23122): Fix the iPod Nano 2G clickwheel when releasing the hold switch |
| 02:12:08 | | Quit JackWinter2 (Read error: 110 (Connection timed out)) |
| 02:14:14 | * | TheSeven wonders why one first needs to call make before doing a make fullzip |
| 02:15:14 | | Join AndyIL [0] (n=pasha_in@212.14.205.32) |
| 02:17:48 | | Join Plouj- [0] (n=Plouj@69-165-151-12.dsl.teksavvy.com) |
| 02:17:50 | Plouj- | hi |
| 02:18:03 | | Quit intrados1 (Read error: 110 (Connection timed out)) |
| 02:18:04 | Plouj- | my rockbox 3.4 h300 prints *PANIC* storage: -71 |
| 02:18:32 | TheSeven | linuxstb: this was my last fix for today. I need to go to bed now |
| 02:19:41 | linuxstb | TheSeven: So you can make a zip, even when the build failed. |
| 02:20:50 | Plouj- | good thing it has a reset button |
| 02:22:50 | linuxstb | Plouj-: Were you running an earlier version of Rockbox before 3.4? |
| 02:23:40 | *** | Saving seen data "./dancer.seen" |
| 02:23:43 | | Quit amiconn (Nick collision from services.) |
| 02:23:46 | | Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) |
| 02:23:54 | | Quit pixelma (Nick collision from services.) |
| 02:23:55 | | Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) |
| 02:24:06 | | Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) |
| 02:24:15 | | Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) |
| 02:26:30 | TheSeven | linuxstb: so what's left? booting the apple firmware from the rockbox bootloader? (did you have a try at this again?) usb? what else? |
| 02:26:43 | | Quit AndyI (Read error: 110 (Connection timed out)) |
| 02:27:08 | linuxstb | TheSeven: So is charging working? |
| 02:27:33 | linuxstb | TheSeven: Useful if you could update the wiki page with progress - I haven't been following all your changes today... |
| 02:27:38 | TheSeven | it's not properly controlled yet, but yes, we can switch between off/100mA/500mA |
| 02:28:07 | * | linuxstb also mentions an accidental revert... |
| 02:28:25 | TheSeven | oh yes, this also needs to be sorted out |
| 02:28:40 | TheSeven | (and merged with the charging code) |
| 02:28:50 | linuxstb | No, the bootloader isn't booting the Apple firmware yet, but I haven't tried any more this evening. I can give you my current patch if you want to work on that. |
| 02:29:14 | linuxstb | Or I could probably just commit it... |
| 02:32:07 | | Join tmzt [0] (n=tmzt@adsl-99-51-211-69.dsl.akrnoh.sbcglobal.net) |
| 02:33:16 | TheSeven | I'll go to bed now anyways, and I'll be busy tomorrow |
| 02:35:24 | linuxstb | OK, goodnight. |
| 02:39:53 | Plouj- | linuxstb: yeah, I updated to 3.4 recently |
| 02:40:31 | linuxstb | Plouj-: And you get that panic every time you try to start Rockbox? |
| 02:41:21 | kyle6513 | plouj- do you see the menu of rockbox for a few seconds? |
| 02:45:38 | | Join Rob2222 [0] (n=Miranda@p4FDCD96E.dip.t-dialin.net) |
| 02:51:59 | Plouj- | linuxstb: no, I got the panic only this one time (after many successfull boots) and can't reproduce it |
| 02:52:21 | Plouj- | linuxstb: I had the device charging over USB while this happened |
| 02:53:04 | linuxstb | Plouj-: OK, so it's working fine now? |
| 02:53:21 | Plouj- | yeah... |
| 02:53:35 | Plouj- | sucks, eh? |
| 02:57:09 | CIA-85 | New commit by dave (r23123): Nano2G: Initial (non-working) attempt to load an encrypted copy of the original firmware from the "osbk" image in the firmware partition. Code based ... |
| 02:57:15 | | Quit amiconn (Nick collision from services.) |
| 02:57:17 | | Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) |
| 02:57:37 | | Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) |
| 02:57:42 | | Quit pixelma (Read error: 110 (Connection timed out)) |
| 02:57:50 | | Join pixelma [0] (i=quassel@rockbox/staff/pixelma) |
| 03:00 |
| 03:03:02 | | Quit Lynx_ (" HydraIRC -> http://www.hydrairc.com <- The professional IRC Client :D") |
| 03:03:18 | saratoga | linuxstb: can you run test_codec yet on the nano2g? |
| 03:05:09 | linuxstb | Yes, it should work. |
| 03:05:51 | saratoga | well if you get bored, we now have all the test_codec files on the download server |
| 03:08:43 | linuxstb | That collection is looking a bit sparse - e.g. no ALAC, AC3, any of the RM codecs... Maybe mt can encoded some Real test files - he has realproducer I think. |
| 03:09:45 | saratoga | linuxstb: yes that would be nice |
| 03:10:13 | saratoga | i'm running it now on the e200v1 |
| 03:10:22 | saratoga | eventually i need to fix the AMS players so they can run test_codec |
| 03:10:38 | saratoga | i bet the Nano2G will be among the fastest per clock targets |
| 03:10:58 | saratoga | updated the clip logging thread if anyone wants to try |
| 03:11:20 | linuxstb | Do you have an he-aac encoder? |
| 03:11:53 | linuxstb | I guess "nero" just means lc-aac? |
| 03:14:32 | | Quit BHSPitLappy (Remote closed the connection) |
| 03:16:02 | kugel | saratoga: they can*t? |
| 03:16:31 | saratoga | kugel: well they can do any file smaller then the audio buffer |
| 03:18:34 | linuxstb | So how can you fix the AMS players to solve that? Do you mean fix test_codec to support files larger than the buffer? |
| 03:18:42 | saratoga | linuxstb: yes |
| 03:18:46 | saratoga | should be fairly simple |
| 03:19:04 | saratoga | just pause the timer, rebuffer, restart the timer |
| 03:20:20 | saratoga | i have an AAC-HE version of the sample track right here, but its 180kbps so i don't know what use it is to benchmark |
| 03:21:42 | | Quit evilnick (Read error: 60 (Operation timed out)) |
| 03:21:55 | | Join Horschti [0] (n=Horscht2@xbmc/user/horscht) |
| 03:22:34 | | Join Valued_Customer [0] (n=chatzill@d24-57-166-201.home.cgocable.net) |
| 03:22:52 | | Nick Valued_Customer is now known as Eragon55 (n=chatzill@d24-57-166-201.home.cgocable.net) |
| 03:23:22 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 03:24:08 | saratoga | linuxstb: http://duke.edu/~mgg6/rockbox/64kaache.m4a |
| 03:28:20 | saratoga | http://duke.edu/~mgg6/rockbox/sansae200r23123.txt |
| 03:28:50 | saratoga | hopefully AAC/Ogg/WMA will all be improved with a newer mdct real soon |
| 03:29:16 | saratoga | ATRAC/AC3/Cook as well but i don't have test samples for them to benchmark |
| 03:32:26 | | Quit dmb ("Leaving") |
| 03:33:34 | | Join dmb [0] (n=Dmb@unaffiliated/dmb) |
| 03:37:41 | linuxstb | saratoga: I'm trying that AAC-HE file now - it seems only just realtime... |
| 03:37:58 | saratoga | at what clock? |
| 03:38:05 | linuxstb | 200MHz I think |
| 03:38:12 | saratoga | wow |
| 03:38:24 | saratoga | how fast is MP3? |
| 03:38:45 | linuxstb | I'll try one now. Any preference for bitrate? |
| 03:38:51 | | Quit Horscht (Read error: 110 (Connection timed out)) |
| 03:38:55 | saratoga | 192k is what i always use |
| 03:39:17 | linuxstb | OK. The AAC is still running... |
| 03:39:25 | saratoga | i need to ask stripwax to profile AAC-He again |
| 03:39:41 | saratoga | but i'm sure its the same problem early ATRAC3 had, slow QMFs |
| 03:40:21 | linuxstb | 105.73% realtime - 181.59MHz |
| 03:40:33 | saratoga | i'm running it now on my e200 |
| 03:40:40 | saratoga | but mp3 will be telling |
| 03:41:02 | saratoga | if everything is working right and you have 0 latency IRAM like PP, I would expect about 38MHz |
| 03:42:08 | | Nick |W|Strife89 is now known as Strife89 (n=michael@adsl-154-13-227.mcn.bellsouth.net) |
| 03:42:49 | linuxstb | I don't think it is zero latency. But TheSeven should know |
| 03:43:09 | saratoga | linuxstb: 134.72 MHz on PP |
| 03:43:21 | saratoga | makes me think the MP3 results won't be pretty . . . |
| 03:43:32 | linuxstb | Yes, mp3 seems slow as well... Maybe we're not actually running at 200MHz... |
| 03:43:52 | linuxstb | 50.60Mhz - 379.38% realtime |
| 03:44:15 | saratoga | yeah something isn't right |
| 03:44:59 | linuxstb | Seems like it may be running at around 100MHz. IIRC, the CPU should be comparable to the Gigabeat F |
| 03:44:59 | saratoga | thats much slower then the Gigabeat, so its not just IRAM |
| 03:45:18 | saratoga | that would mean 25MHz decode, which is too fast |
| 03:46:07 | | Quit Eragon55 ("ChatZilla 0.9.84 [Firefox 3.5.3/20090824101458]") |
| 03:46:25 | saratoga | you've got the same slow multiplier as PP, but a slightly faster load/store unit, so if everything else is equal you should be very slightly faster |
| 03:46:38 | saratoga | (compared to 1 core MP3 on PP) |
| 03:47:06 | | Join Eragon55 [0] (n=chatzill@d24-57-166-201.home.cgocable.net) |
| 03:47:22 | kugel | saratoga: though it has only small caches |
| 03:47:37 | kugel | FX make up their lack of iram with a bunch of cache |
| 03:47:51 | saratoga | same total cache as PP |
| 03:47:58 | saratoga | and anyway for mp3 you should be entirely in IRAM |
| 03:50:39 | | Quit efyx (Remote closed the connection) |
| 04:00 |
| 04:00:00 | | Quit webguest56 ("CGI:IRC (Ping timeout)") |
| 04:01:42 | | Quit kyle6513 (Read error: 60 (Operation timed out)) |
| 04:03:32 | | Join Lss [0] (n=Lss@cm46.delta91.maxonline.com.sg) |
| 04:05:48 | | Quit TheSeven (Nick collision from services.) |
| 04:06:06 | | Join The_Seven [0] (n=theseven@rockbox/developer/TheSeven) |
| 04:06:18 | | Nick The_Seven is now known as TheSeven (n=theseven@rockbox/developer/TheSeven) |
| 04:06:40 | | Quit kugel (Remote closed the connection) |
| 04:08:15 | | Join Kajarii [0] (n=foo@S0106001310789daf.ok.shawcable.net) |
| 04:17:00 | | Quit funman ("leaving") |
| 04:19:14 | | Quit dmb (Read error: 104 (Connection reset by peer)) |
| 04:23:02 | | Quit Eragon55 ("ChatZilla 0.9.84 [Firefox 3.5.3/20090824101458]") |
| 04:23:41 | *** | Saving seen data "./dancer.seen" |
| 04:32:18 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 04:36:43 | | Join intrados1 [0] (n=intrados@cpe-75-187-57-252.columbus.res.rr.com) |
| 04:36:44 | | Quit nosa- (Read error: 54 (Connection reset by peer)) |
| 04:36:45 | | Join nosa-j [0] (n=k@adsl-235-42-106.clt.bellsouth.net) |
| 04:38:00 | | Quit Rondom (Nick collision from services.) |
| 04:38:10 | | Join Rondom [0] (n=Rondom@dslb-084-057-152-153.pools.arcor-ip.net) |
| 04:40:04 | | Quit nosa-j (Read error: 104 (Connection reset by peer)) |
| 04:40:07 | | Join nosa- [0] (n=k@adsl-235-42-106.clt.bellsouth.net) |
| 04:41:12 | | Quit saratoga ("Page closed") |
| 05:00 |
| 05:06:27 | | Join ShapeShifter499 [0] (n=chatzill@adsl-69-105-84-31.dsl.scrm01.pacbell.net) |
| 05:25:41 | | Part toffe82 |
| 05:31:35 | | Join lifeless_ [0] (n=lifeless@188.18.75.234) |
| 05:33:56 | | Quit panni_ (Read error: 104 (Connection reset by peer)) |
| 05:45:40 | | Quit lifeless_ ("Ex-Chat") |
| 05:46:02 | | Quit rvvs89 (Read error: 54 (Connection reset by peer)) |
| 05:48:26 | | Join lifeless_ [0] (n=lifeless@188.18.75.234) |
| 05:51:19 | | Quit Horschti ("Verlassend") |
| 05:51:23 | | Quit funman ("free(random());") |
| 06:00 |
| 06:11:45 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 06:14:26 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
| 06:17:28 | | Quit fdinel (Client Quit) |
| 06:19:05 | | Quit gevaerts (Nick collision from services.) |
| 06:19:17 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 06:23:43 | *** | Saving seen data "./dancer.seen" |
| 06:24:35 | | Quit elinenbe (Read error: 113 (No route to host)) |
| 06:28:58 | CIA-85 | New commit by tomers (r23124): LCD scrolling - fix a typo |
| 06:29:48 | CIA-85 | New commit by tomers (r23125): LCD scrolling - reduce one 'if' nesting level |
| 06:30:30 | | Join tomers [0] (n=chatzill@84.109.85.100) |
| 06:51:35 | | Quit tomers (Read error: 148 (No route to host)) |
| 06:57:06 | | Quit liar|netbook ("Verlassend") |
| 07:00 |
| 07:04:41 | | Quit HBK (Read error: 131 (Connection reset by peer)) |
| 07:05:48 | | Join HBK [0] (i=hbk@rrcs-97-77-51-170.sw.biz.rr.com) |
| 07:09:42 | | Quit ShapeShifter499 (Read error: 60 (Operation timed out)) |
| 07:12:07 | | Join stoffel [0] (n=quassel@p57B4D1E2.dip.t-dialin.net) |
| 07:15:12 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
| 07:15:53 | | Join Rob2222 [0] (n=Miranda@p4FDCD96E.dip.t-dialin.net) |
| 07:28:21 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 07:30:20 | | Part Kajarii |
| 07:35:47 | | Join Riku [0] (n=Lss@cm46.delta91.maxonline.com.sg) |
| 07:48:38 | | Quit intrados1 (Read error: 110 (Connection timed out)) |
| 07:54:00 | | Quit Lss (Read error: 110 (Connection timed out)) |
| 07:58:29 | | Join locutox [0] (n=ltx@124-170-47-206.dyn.iinet.net.au) |
| 07:58:47 | locutox | you glorious mofos, you've finally got rockbox working on 2g nano:D |
| 08:00 |
| 08:05:36 | | Quit Strife89 ("Alvin, it's 2:00 in the morning. Go to bed!") |
| 08:23:44 | *** | Saving seen data "./dancer.seen" |
| 08:25:04 | | Quit stoffel (Remote closed the connection) |
| 08:27:45 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
| 08:32:04 | | Join Rob2223 [0] (n=Miranda@p4FDCD647.dip.t-dialin.net) |
| 08:33:40 | funman | is it possible to browse rockbox menus / use plugins while recording? |
| 08:34:49 | funman | it looks like i'm not able to do this on my fuze but i'm not sure if it's a limitation of rockbox or of the fuze keymap |
| 08:38:07 | | Join ruj1 [0] (n=ruj1@PPPoE-78-29-125-152.san.ru) |
| 08:38:42 | funman | for instance, i would like to open the debug menu while recording is on, to check clock frequencies and ascodec registers |
| 08:39:50 | | Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) |
| 08:42:13 | funman | Zagor: can you do some chmod o+r http://download.rockbox.org/bootloader/sandisk-sansa/mkamsboot-1.1/ and ln -s mkamsboot-1.1 mkamsboot please ? |
| 08:44:09 | Zagor | sure. but what is the symlink for? |
| 08:44:36 | funman | we can refer to it in the wiki / manual and not have to correct for each new version |
| 08:44:44 | Zagor | good point |
| 08:45:03 | funman | or perhaps mkamsboot-latest |
| 08:45:38 | funman | i think sansapatcher/ is a symlink as well ? |
| 08:45:44 | Zagor | yes |
| 08:46:12 | pixelma | funman: for some reason I think browsing the menus while recording is not possible (I seem to remember that the action to leave the recording screen is the same as the stop recording action which I stumbled upon for the c200 keymap), not a 100% sure though |
| 08:46:21 | Zagor | or actually, no. sansapatcher is a dir and sansapatcher-0.8 is a symlink pointing to it... it's a bit of a mess, this directory :-( |
| 08:47:08 | | Join petur [50] (n=petur@rockbox/developer/petur) |
| 08:50:08 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
| 08:55:13 | funman | sometimes I reload the page and see the mkamsboot-1.1RC directory, how are the 2 servers synced ? |
| 08:55:49 | funman | the mirror is hosted by videolan, i should ask them |
| 08:57:01 | topik | is there a reason why test_codec is not built by default? |
| 08:57:16 | funman | topik: it's useless to most users |
| 08:57:30 | topik | many things are |
| 08:57:53 | topik | it wouldn't hurt to have it, would it? |
| 08:57:59 | funman | right, but i think the point is people needing to use test_codec know how to build it |
| 08:58:13 | topik | that's true |
| 09:00 |
| 09:03:01 | topik | as written on the forum it is more useful to have coders than benchmarkers, but for unstable builds it could be useful/convenient to have test_codec included. then again, compiling your own is not _that_ hard |
| 09:05:05 | funman | Zagor: what is the new rsync url ? giant.haxx.se/rockbox-download doesn't work anymore |
| 09:07:33 | Zagor | funman: umm, I'm not sure. haxx.rockbox.org? I haven't changed anything rsync related lately. |
| 09:08:59 | funman | Zagor: hum it works in fact, i'll check why the videolan server isn't up to date |
| 09:13:04 | | Join flydutch [0] (n=flydutch@host77-167-dynamic.15-87-r.retail.telecomitalia.it) |
| 09:16:18 | funman | works now, perhaps related to permissions of mkamsboot-1.1 |
| 09:26:39 | | Join LinusN [0] (n=linus@gateway/web/cgi-irc/labb.contactor.se/x-ftppxdvjcjvykrbq) |
| 09:28:17 | | Join Thundercloud [0] (i=thunderc@81.187.69.84) |
| 09:29:35 | | Join JackWinter4 [0] (n=jack@vodsl-10804.vo.lu) |
| 09:30:09 | | Quit lifeless_ (Remote closed the connection) |
| 09:30:40 | | Join lifeless_ [0] (n=lifeless@188.18.75.234) |
| 09:36:10 | | Quit ruj1 () |
| 09:37:38 | | Join MethoS- [0] (n=clemens@134.102.106.250) |
| 09:41:51 | | Quit JackWinter3 (Read error: 110 (Connection timed out)) |
| 09:46:13 | | Quit Thundercloud (Remote closed the connection) |
| 09:52:09 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 09:56:29 | | Join nls_web [0] (n=5ae64f66@giant.haxx.se) |
| 09:57:10 | | Join DerPapst [0] (n=DerPapst@p4FE8F166.dip.t-dialin.net) |
| 10:00 |
| 10:02:33 | funman | I wonder how FM radio can be heard on sansa e200/c200 v1 since all line inputs are muted by audiohw_set_monitor(false) in audio_input_mux() |
| 10:18:30 | TheSeven | saratoga, linuxstb: I don't know about IRAM latencies either, I just know that IRAM also runs through the cache, probably for a reason. And SDRAM is running at something ridiculous like 32MHz. |
| 10:21:56 | | Quit Riku (Read error: 104 (Connection reset by peer)) |
| 10:23:35 | linuxstb | TheSeven: BTW, I think the NAND/FTL still isn't perfect. It seems to shutdown cleanly, but more often than not the NOR bootloader seems to be doing something - i.e. booting is delayed by a few seconds. |
| 10:23:38 | TheSeven | linuxstb: I just looked at r23123... Do you actually need interrupts in the bootloader? |
| 10:23:48 | *** | Saving seen data "./dancer.seen" |
| 10:24:11 | linuxstb | TheSeven: Also, I tried reinstating my USB changes, and get a "panic: could not unmount nand" error every time I inserted USB. |
| 10:25:06 | TheSeven | If not (which I would hope) you could just leave the bootrom mapped to zero like iloader does, and just change IRAMORIG to 0x22000000 |
| 10:26:01 | * | TheSeven can't think of a reason why unmounting panicing on USB connect, but not shutdown, should be coming from the FTL |
| 10:26:05 | linuxstb | TheSeven: I guess it depends on whether any of the drivers used by bootload use interrupts - do they? e.g. if they sleep(), then we need the tick timer (unless we fake the sleep for bootloader builds -other targets do that). |
| 10:26:28 | TheSeven | can't remember any of the interesting drivers doing that |
| 10:26:32 | TheSeven | AFAIK they all just yield |
| 10:26:59 | | Join antil33t1 [0] (n=Mudkips@119.224.12.185) |
| 10:27:02 | | Quit antil33t1 (Remote closed the connection) |
| 10:27:02 | linuxstb | TheSeven: Is the system_reboot() in system-s5l8700.c still correct - I think that's where the panic is coming from. |
| 10:27:09 | | Join antil33t1 [0] (n=Mudkips@119.224.12.185) |
| 10:27:10 | | Quit antil33t () |
| 10:27:11 | TheSeven | not having the tick timer will just mean infinite timeouts (and thus probably a lockup while scanning nand banks on 2GB ipods) |
| 10:27:15 | | Join antil33t [0] (n=Mudkips@119.224.12.185) |
| 10:27:17 | | Quit antil33t (Nick collision from services.) |
| 10:27:23 | | Join antil33t [0] (n=Mudkips@119.224.12.185) |
| 10:27:29 | TheSeven | so faking the tick timer from the usec one like on PP could be an idea |
| 10:27:42 | linuxstb | We have a usec timer? |
| 10:28:23 | | Quit antil33t1 (Client Quit) |
| 10:28:32 | | Join antil33t1 [0] (n=Mudkips@119.224.12.185) |
| 10:28:38 | | Quit antil33t (Nick collision from services.) |
| 10:28:43 | | Join antil33t [0] (n=Mudkips@119.224.12.185) |
| 10:28:45 | | Part antil33t1 |
| 10:29:07 | | Join antil33t1 [0] (n=Mudkips@119.224.12.185) |
| 10:29:13 | | Quit antil33t (Nick collision from services.) |
| 10:29:41 | TheSeven | linuxstb: The datasheet doesn't have one, but apple seems to be accessing one |
| 10:29:50 | TheSeven | it's somewhere after the timer D regs |
| 10:29:51 | | Join antil33t [0] (n=Mudkips@119.224.12.185) |
| 10:30:03 | TheSeven | still needs investigation |
| 10:30:15 | TheSeven | and i found the reason for the weird FTL/rebooting behavior |
| 10:30:40 | TheSeven | since we moved that to powermgmt.c errors while shutting down are just ignored and not paniced on any more |
| 10:31:50 | TheSeven | i think we should remove that panic in system_reboot, and add one in nand_flush to catch all cases |
| 10:32:45 | | Join daurn [0] (i=daurnima@freenode/staff/daurnimator) |
| 10:39:18 | | Quit nls_web ("CGI:IRC") |
| 10:39:30 | | Join maruk [0] (n=papier@titanium.sdv.fr) |
| 10:41:27 | | Join daurn| [0] (n=daurnima@freenode/staff/daurnimator) |
| 10:46:21 | linuxstb | TheSeven: Do you mean your fix to the shutdown panics was not to panic any more? Or am I misunderstanding? |
| 10:48:02 | | Quit daurn (Read error: 60 (Operation timed out)) |
| 10:48:43 | | Join daurn [0] (i=daurnima@freenode/staff/daurnimator) |
| 10:48:59 | TheSeven | there are 2 types of shutdown panics: one, where the FTL code itself panics, because we're entering untested and potentially destructive code (i.e. remapping - the ones we've been seeing recently), and the other kind is where something just goes wrong, the ftl returns a bad rc, and the caller paniced on that. the latter were only visible on reboots, but not on shutdowns any more, since 23057 |
| 10:50:05 | | Join Contos [0] (n=Kyse@75-172-24-150.tukw.qwest.net) |
| 10:50:28 | Contos | hey i had a question, whats on the sansa rockbox? |
| 10:50:40 | scorche | "whats on"? |
| 10:50:41 | Contos | like games and whatnaught? |
| 10:51:09 | linuxstb | See the "manual" link on the left of every page of the Rockbox website. |
| 10:51:28 | Contos | okay... rephrase, features |
| 10:51:35 | linuxstb | See the "manual" link on the left of every page of the Rockbox website. |
| 10:52:03 | Contos | kay thx |
| 10:52:29 | | Quit Contos (Client Quit) |
| 10:53:13 | * | TheSeven can't reproduce FTL fails, even with re-enabled panics |
| 10:54:53 | CIA-85 | New commit by theseven (r23126): Bring the iPod Nano 2G shutdown FTL panics back. |
| 10:57:47 | TheSeven | linuxstb: do you get any shutdown panics with that revision? I don't get any |
| 10:57:57 | linuxstb | Let me try... |
| 10:59:48 | | Quit daurnimator (Read error: 110 (Connection timed out)) |
| 11:00 |
| 11:00:03 | TheSeven | and my norboot ("apple-logo") time is at the usual 2 seconds, so it seems to be just working |
| 11:00:21 | TheSeven | but there could be some weird conditions on your FTL that make it choke |
| 11:00:48 | linuxstb | I just turned my ipod on, and the NOR spent about 10 seconds doing something... |
| 11:01:37 | linuxstb | Hmm, and now I get a "can't load rockbox.ipod - bad checksum..." |
| 11:01:42 | linuxstb | (from the RB bootloader) |
| 11:01:50 | linuxstb | Seems like my Nano isn't happy still |
| 11:02:55 | TheSeven | is the bootloader using an FTL_READONLY build? |
| 11:03:00 | linuxstb | Yes |
| 11:03:32 | TheSeven | ok, so that one can't be at fault |
| 11:04:34 | | Join Omlet [0] (n=omlet05@57.105-244-81.adsl-dyn.isp.belgacom.be) |
| 11:04:42 | | Join Omlet05 [0] (n=omlet05@81.244.105.57) |
| 11:04:55 | * | linuxstb tries again, and this time does an "eject" as well as unmount. |
| 11:05:17 | | Quit Omlet05 (Client Quit) |
| 11:05:50 | linuxstb | OK, it booted now. The "eject" didn't return instantly, so maybe I should always be doing that... (although I've never needed in the past) |
| 11:06:18 | gevaerts | strange |
| 11:06:55 | linuxstb | TheSeven: OK, it seems happy at the moment. Reboot to USB also works without panic. (I have my usb changes re-applied) |
| 11:07:16 | linuxstb | So maybe the disk mode only does its own flush on "eject". |
| 11:08:36 | gevaerts | looks like it, but why wouldn't it do that on disconnect? |
| 11:09:11 | | Join rvvs89 [0] (n=ivo@pdpc/supporter/base/rvvs89) |
| 11:09:13 | linuxstb | "eject" == "disconnect" I think. |
| 11:09:43 | linuxstb | i.e. if I just unmount, then the ipod just says "do not disconnect", but after eject it says "OK to disconnect" |
| 11:10:05 | linuxstb | gevaerts: Ah you mean a physical disconnect? |
| 11:10:07 | gevaerts | yes |
| 11:10:17 | | Quit daurn| (Read error: 110 (Connection timed out)) |
| 11:10:19 | linuxstb | Yes, you would think it would do that... |
| 11:10:22 | gevaerts | unless it's a host-sode issue |
| 11:11:42 | linuxstb | What could that be? I always unmount before unplugging - could that not be flushing things to the disk? |
| 11:12:23 | gevaerts | it should, unless I'm seriously misunderstanding things. I just don't like eliminating possibilities too soon |
| 11:12:52 | TheSeven | linuxstb: so you just unmounted and reset it? |
| 11:13:02 | linuxstb | I unmounted then unplugged. |
| 11:13:32 | gevaerts | linuxstb: maybe run "vmstat 1" and see if there's bo activity during eject? |
| 11:13:40 | TheSeven | and before you were resetting it from disk mode? or what were you doing? |
| 11:13:41 | linuxstb | Ah no, I didn't... When I force it into disk mode (holding select+play), it doesn't automatically leave disk mode, so I would have needed to reset. |
| 11:13:49 | gevaerts | or iotop, or... |
| 11:14:13 | TheSeven | linuxstb: heh, that's the advantage of not manually booting it to disk mode :-) |
| 11:14:16 | linuxstb | So yes, perhaps the "reset from disk mode without eject" was upsettig it. |
| 11:14:21 | TheSeven | it automatically shuts down cleanly and reboots |
| 11:14:33 | linuxstb | TheSeven: Yes, that's what happens when Rockbox reboots. |
| 11:14:35 | TheSeven | linuxstb: that's what i was expecting |
| 11:14:54 | linuxstb | (I only had to enter manually because someone reverted that feature....) |
| 11:15:00 | linuxstb | ;) |
| 11:15:54 | TheSeven | ok, at least you spotted that "no panic on unclean shutdown" bug :-) |
| 11:16:13 | linuxstb | I'm here to help. |
| 11:19:18 | | Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) |
| 11:25:12 | linuxstb | TheSeven: Have you implemented backlight brightness on the Nano2G? |
| 11:25:58 | * | linuxstb sees he did - nice... |
| 11:27:19 | linuxstb | gevaerts: Adding HAVE_USB_POWER wasn't enough to stop my Nano2G rebooting on usb when holding menu |
| 11:29:42 | | Quit daurn (Read error: 110 (Connection timed out)) |
| 11:30:01 | | Join daurn| [0] (n=daurnima@freenode/staff/daurnimator) |
| 11:34:06 | maruk | linuxstb: mine does not reboot when plugging an usb cable (even if I don't hold the menu button). |
| 11:34:22 | linuxstb | maruk: Yes, that was reverted from svn. I'm testing it again now... |
| 11:34:48 | maruk | linuxstb: ok. |
| 11:41:37 | TheSeven | linuxstb: you didn't notice the backlight wasn't as bright as usual by default, did you? |
| 11:42:13 | linuxstb | TheSeven: No, although I did just notice that it was brighter in my bootloader... |
| 11:42:18 | TheSeven | i set the default brightness to half the current apple uses! |
| 11:42:54 | TheSeven | in fact we could double what apple uses (from the PMU side) but i doubt the LEDs would survive that for long - so i set the max value to what apple did |
| 11:43:00 | | Join nls_web [0] (n=5ae64f66@giant.haxx.se) |
| 11:44:26 | TheSeven | (the brightness setting is using a logarithmic scale) |
| 11:50:02 | linuxstb | The default seems fine to me, and I think I normally like things brighter than average. |
| 11:50:36 | TheSeven | yes, that's what I thought, too |
| 11:52:14 | maruk | TheSeven: for me, the default is also fine. I reduce the default by 1 or 2 (can remenber). |
| 11:52:33 | TheSeven | it looks a little like a printout at that brightness. not really luminous, but perfectly clear |
| 11:53:00 | TheSeven | the default value seems to be bright enough to reduce contrast again |
| 11:53:14 | TheSeven | the apple value* |
| 11:54:14 | TheSeven | and of course it's a huge power saving... backlight off: 22mA, backlight at the default value: 34mA, backlight at the apple value: 46mA |
| 12:00 |
| 12:02:24 | | Join KBH [0] (i=hbk@rrcs-97-77-51-170.sw.biz.rr.com) |
| 12:04:25 | linuxstb | TheSeven: Have you started looking at USB? |
| 12:04:36 | TheSeven | well yes, *looking* at it |
| 12:16:04 | TheSeven | I might have another go at that tonight |
| 12:16:24 | TheSeven | at least if there is nothing more important to do, but I think we've caught all the other major things now |
| 12:16:41 | linuxstb | You could look at the bootloader if you want - I'm probably not going to get time today. |
| 12:17:05 | TheSeven | FYI, the USB controller seems to match the one in the S3C6400X datasheet |
| 12:17:28 | linuxstb | As well as booting the OF, it would be nice to have button detection - currently the dual-boot only happens if the hold switch is on, but it would be better if you could hold a button instead. |
| 12:18:00 | linuxstb | But I remember that on earlier ipods, I struggled to detect very early button presses. |
| 12:19:15 | * | linuxstb wonders how controversial a "check for .rockbox/bootloader.bmp file and if it exists show that as a boot menu" feature would be.... ;) |
| 12:19:27 | | Quit HBK (Read error: 110 (Connection timed out)) |
| 12:19:31 | TheSeven | yes, the wheel won't send anything if a button is just held |
| 12:19:40 | TheSeven | only if you press it while monitoring it |
| 12:19:53 | gevaerts | linuxstb: you mean as some sort of illustrated help file? |
| 12:20:51 | | Quit funman ("free(random());") |
| 12:21:19 | linuxstb | gevaerts: Yes. I quite like iloader - it shows a clickwheel image with various logos in the button locations for the different options - Rockbox, AppleOS, disk mode, iBugger (TheSeven's debugger). You then press the relevant button to start that option. |
| 12:22:03 | linuxstb | But boot menus have long been a "no-do", so I guess I'm wondering if people have mellowed... |
| 12:22:11 | TheSeven | linuxstb: not to forget the pear for "whatever you would like to have here" :-) |
| 12:23:02 | gevaerts | I think it would be a good idea, although I wonder if having just a marker file and the bitmap file compiled in wouldn't be easier/less code. Do we want a bmp reader in the bootloader? |
| 12:23:33 | linuxstb | Maybe s/bmp/raw/ |
| 12:23:49 | TheSeven | linuxstb: I would go for the way i did it in iloader |
| 12:23:51 | linuxstb | i.e. just load it directly to the framebuffer. But yes, compiling it in could work, but you know what users will want... |
| 12:23:52 | *** | Saving seen data "./dancer.seen" |
| 12:23:57 | TheSeven | i.e. native-lcd BMPs |
| 12:24:27 | TheSeven | yes, users like the easy themability of iloader :-) |
| 12:24:56 | gevaerts | maybe I'm overestimating the cost of having the bmp reader |
| 12:25:07 | TheSeven | depends on its features |
| 12:25:28 | linuxstb | I don't think speed is an issue - if the user is going to use a boot menu, they can wait a fraction of a second for it to be loaded. |
| 12:25:51 | TheSeven | i think gevaerts was rather thinking of bin/ramsize |
| 12:25:58 | TheSeven | but i think a trivial BMP reader in the bootloader should be possible |
| 12:26:07 | TheSeven | the one iloader uses is 15 lines of code |
| 12:26:08 | linuxstb | Embedding the bmp would be more binsize... |
| 12:26:29 | TheSeven | (but of course it only supports native bitmaps) |
| 12:26:30 | gevaerts | I was mostly thinking about complexity actually |
| 12:26:59 | gevaerts | if we do loadable files, I think it should be normal bmp |
| 12:27:14 | TheSeven | gevaerts: what I'm doing is basically get height and width out of the BMP header, set up the LCD, and blit the rest of the BMP directly to the LCD |
| 12:27:38 | linuxstb | TheSeven: That's not very portable... If we do this for the Nano2G, it would make sense to do it on the older ipods. |
| 12:28:00 | linuxstb | (some older ipods have a byte-swapped lcd buffer, I guess that could just be a #ifdef...) |
| 12:28:52 | TheSeven | yes, not very portable, but it was the easiest to implement - i didn't want to waste time on that, but rather get that thing finished |
| 12:29:03 | linuxstb | But anyway, the main question is whether "we" (as Rockbox) want it... |
| 12:29:15 | TheSeven | most of the iloader code is pretty crappy, but at least it was done in about a day |
| 12:30:41 | gevaerts | linuxstb: I think it would be fine, except of course that people will always want more |
| 12:31:11 | linuxstb | When do we give people what they want? ;) |
| 12:31:19 | gevaerts | when it suits us :) |
| 12:31:22 | linuxstb | Exactly. |
| 12:31:38 | gevaerts | Maybe actually implementing a graphical configurable bootloader will reduce support issues due to people using untested bootloaders? |
| 12:33:17 | linuxstb | Yes, although iloader is likely to be well-tested with Rockbox (as TheSeven is using it I assume), it would be nice to not fork users into two groups based on their bootloader. |
| 12:35:00 | TheSeven | the RB bootloader has the same issues as GRUB legacy, I think ;-) |
| 12:35:07 | TheSeven | Time for a 2.0 :-D |
| 12:35:21 | linuxstb | Well, we don't have a 1.0 yet (for the Nano2G)... |
| 12:35:33 | | Quit Omlet ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") |
| 12:35:43 | TheSeven | grub also never had a 1.0 |
| 12:37:29 | TheSeven | linuxstb: btw, i found another issue in your code: we're probably running into caching trouble again... |
| 12:37:55 | TheSeven | i would suggest using 0x0A000000 or 0x48000000 as the load buffer |
| 12:38:18 | | Join intrados1 [0] (n=intrados@cpe-75-187-57-252.columbus.res.rr.com) |
| 12:38:23 | TheSeven | and then of course disable the protection unit before jumping to 0x08000000 |
| 12:39:53 | TheSeven | address bus wrapping to circumvent caches is the best trick ever I ever spotted :-D |
| 12:41:51 | linuxstb | TheSeven: I thought the NAND driver did that? Ah, but the decryption doesn't... |
| 12:42:17 | linuxstb | So would just passing 0x48000000 to aes_decrypt() be enough? |
| 12:42:28 | TheSeven | no, i would use that address all the time |
| 12:42:46 | TheSeven | else things might still be stuck in the write buffer when aes_decrypt tries to access them |
| 12:43:03 | TheSeven | hey, can anybody tell my why this yellow hasn't been there all the time? |
| 12:43:46 | TheSeven | ah, someone had removed these buggers already. why didn't svn update catch that? |
| 12:43:47 | linuxstb | TheSeven: I fixed that... |
| 12:44:06 | TheSeven | but for some reason it neither made its way into my tree nor conflicted... |
| 12:44:49 | CIA-85 | New commit by theseven (r23127): Fix the yellow again |
| 12:45:09 | linuxstb | TheSeven: Yes, you re-committed them with r23126... |
| 12:46:28 | * | linuxstb likes to do an "svn diff" before committing, just to double-check what he's actually going to commit |
| 12:48:27 | * | TheSeven usually does that, but didn't expect that file to be out of sync before committing that one-line patch |
| 12:52:46 | | Join daurn [0] (i=daurnima@freenode/staff/daurnimator) |
| 12:55:10 | TheSeven | is there currently a known bug with text scrolling? |
| 12:55:28 | TheSeven | i'm right now seeing a very weird thing |
| 12:57:36 | TheSeven | if text starts scrolling, it will first scroll from the left to the right end correctly. |
| 12:57:52 | | Quit daurn| (Read error: 110 (Connection timed out)) |
| 12:58:28 | TheSeven | then it will scroll back from the right to tle left end again, but twice as much as expected, i.e. beyond the left end |
| 12:59:05 | TheSeven | and it shows very interesting vertically-wrapped characters beneath the left end of the text |
| 12:59:27 | TheSeven | then it will jump to the right end again, and again scroll beyond the left end |
| 12:59:37 | TheSeven | any idea what's causing this? |
| 12:59:56 | TheSeven | something related to RTL or that centered patch yesterday? |
| 13:00 |
| 13:00:11 | linuxstb | Maybe... |
| 13:00:51 | linuxstb | TheSeven: I've just tried disabling IRQs in the bootloader, and it feezes some time after turning the backlight on... |
| 13:01:23 | TheSeven | you have a 2gb/4gb ipod? |
| 13:01:43 | linuxstb | 2GB |
| 13:02:13 | TheSeven | yes, then it's probably locking up while scanning the NAND banks |
| 13:02:27 | TheSeven | (the timeout for detecting the chips needs the tick timer) |
| 13:03:25 | linuxstb | Although it doesn't seem to update the LCD either, so I'm not sure it's getting that far. |
| 13:03:56 | * | TheSeven suggests faking a tick timer |
| 13:04:29 | linuxstb | I'm calling backlight_init() - maybe that's doing too much... |
| 13:05:05 | TheSeven | no, it should only do some i2c stuff |
| 13:05:23 | TheSeven | (i2c timeouts won't work either, but shouldn't happen in the first place) |
| 13:05:38 | TheSeven | see sub_22001208 and it's xrefs for how to access the usec timer or whatever it is |
| 13:06:20 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 13:07:11 | kugel | TheSeven: don't forget to handle usb connection in the nand thread |
| 13:07:31 | TheSeven | huh? how's that related? |
| 13:07:53 | kugel | each thread must respond on SYS_USB_[DIS]CONNECT |
| 13:08:36 | kugel | (that was regarding what you said earler today) |
| 13:13:00 | amiconn | The rockbox bootloader doesn't have a boot menu on purpose. It should boot as quick as possible, and be self contained |
| 13:13:16 | amiconn | A boot menu is a big nodo, imo |
| 13:13:44 | TheSeven | amiconn: would you also object splitting/ifdefing it into a fast and a fancy one? |
| 13:13:52 | amiconn | yes |
| 13:13:59 | TheSeven | kugel: I can't see how a thread itself would get such an event |
| 13:14:13 | TheSeven | aren't it rather the queues that get it? |
| 13:14:56 | kugel | not sure :p |
| 13:15:20 | TheSeven | can't see why threads should be interested in such events in general |
| 13:15:49 | TheSeven | and i can't see how a thread should get an event at all, besides using a queue, which the nand thread doesn't have |
| 13:16:03 | amiconn | It's also a question of reliability. On some targets a non-working bootloader would mean it's bricked |
| 13:16:48 | amiconn | (not even considering the space constraints on a few targets) |
| 13:17:25 | kugel | TheSeven: could be that only queues get it, maybe I'm confused since every other thread has a queue |
| 13:17:27 | TheSeven | amiconn: that's why ifdefing it would make sense |
| 13:17:54 | TheSeven | on nano2g, it can be up to 16MB in size, and a bad one is very easy to replace |
| 13:18:09 | | Quit kugel (Nick collision from services.) |
| 13:18:15 | amiconn | More ifdefs == mor epotential bugs |
| 13:18:17 | | Join kugel [0] (n=kugel@e178070119.adsl.alicedsl.de) |
| 13:19:01 | * | TheSeven would pretty much like to get rid of that thread altogether, but can't make the spindown timeout work without it |
| 13:19:07 | * | kugel wouldn't like a boot menu as well |
| 13:19:33 | kugel | TheSeven: you can add a timeout |
| 13:20:14 | TheSeven | how? i.e. using which api? |
| 13:20:33 | kugel | timeout_register(power_off_func, data, HZ/5); see kernel.h (HAVE_TIMEOUT_API) |
| 13:22:06 | kugel | the function will run in a tick task, which may (or may not) cause some problems |
| 13:22:25 | kugel | in a tick interrupt* |
| 13:22:48 | TheSeven | hmm, yielding from an interrupt is probably not the best thing to do |
| 13:23:01 | kugel | you wouldn't need to yield |
| 13:23:25 | kugel | the function runs only once, when the timeout wears off |
| 13:23:45 | TheSeven | but trying to lock a mutex will either lock up entirely or need to yield if it's done in an IRQ |
| 13:24:14 | TheSeven | (in case the mutex is already locked) |
| 13:24:26 | amiconn | yield() must not be called in interrupt context |
| 13:24:32 | kugel | that's why mutex aren't interrupt safe :) |
| 13:24:55 | TheSeven | and that's why mutexes aren't timeout-safe either |
| 13:25:22 | amiconn | If you need to call a function at a certain timeout, and that function needs to access mutexes or similar, you pretty much need a thread |
| 13:25:22 | TheSeven | so I'll need to keep that thread around |
| 13:25:43 | amiconn | Afaik all storage driver use a thread for oe thing or another, so I don't see a problem with that |
| 13:26:09 | LinusN | "apps/plugins/crypt_firmware.c: Copyright 2009 TheSeven" - don't we want real names there? |
| 13:26:29 | kugel | I think we do |
| 13:26:43 | TheSeven | i think linuxstb just copy-pasted that |
| 13:27:11 | TheSeven | i'm fine with removing it altogether, or rather replacing it with a rockbox header |
| 13:27:19 | linuxstb | LinusN: Well, it was a verbatim quote from the other source file... |
| 13:27:45 | linuxstb | LinusN: The (C) at the top has TheSeven's real name. |
| 13:28:13 | linuxstb | (but yes, there's nothing explicitly linking the two, although that's implied) |
| 13:30:51 | linuxstb | amiconn: I'm only suggesting an optional boot menu on targets where it's safe, such as ipods. |
| 13:32:31 | CIA-85 | New commit by theseven (r23128): Ditch additional copyright notice quoted from iBugger. |
| 13:34:59 | nls_web | i don't see the problem with loading an optional bmp in the bootloader but of course i wouldn't use it |
| 13:35:06 | TheSeven | amiconn: it's more or less the question if rockbox will do it and keep it based on the same, known-to-work, drivers and source code, or if a third party will do it with possibly more compatibility issues. |
| 13:35:24 | * | linuxstb wouldn't use it either... |
| 13:36:05 | TheSeven | now that iLoader is around, I don't think people will stop using it, even if i would explicitly drop support for it |
| 13:36:48 | TheSeven | (of course, I'll try to keep it as compatible as possible, but there are already some FTL fixes that haven't been backported to it yet) |
| 13:36:56 | | Quit antil33t () |
| 13:37:48 | kugel | a boot menu will just get us annoying people asking for it on other targets |
| 13:38:28 | linuxstb | kugel: So? We're not obliged to do what users want... |
| 13:38:46 | kugel | it's annoying |
| 13:38:49 | linuxstb | But if that's the case, it shows it's a wanted feature. |
| 13:39:01 | linuxstb | kugel: Then just ignore such people... |
| 13:39:15 | * | TheSeven wonders if #if (CONFIG_CODEC == SWCODEC) || !defined(SIMULATOR) for the metronome plugin does make any sense |
| 13:39:53 | TheSeven | shouldn't it rather be ... || defined(SIMULATOR) instead? |
| 13:41:12 | linuxstb | No, I think that means that it's always compiled for swcodec (real and sim), and only real hwcodec. |
| 13:41:47 | linuxstb | (hwcodec are the Archos targets that have a hardware mp3 decoder which isn't simulated) |
| 13:41:49 | TheSeven | why should it work on real hwcodec and not on hwcodec sim (which is probably internally swcodec?) |
| 13:42:30 | linuxstb | That's the problem - hwcodec sim is not internally swcodec. |
| 13:43:16 | nls_web | yeah, that pp codition is in a few places and always takes me a few seconds untill i get it :) |
| 13:44:20 | nls_web | #if (CONFIG_CODEC == SWCODEC) || (CONFIG_CODEC != SWCODEC && !defined(SIMULATOR)) would be slightly clearer imo |
| 13:44:54 | linuxstb | nls_web: Or a short comment... |
| 13:45:01 | nls_web | or that :) |
| 13:47:36 | TheSeven | are the oscilloscope and vu meters designed to work for line in and/or playback? |
| 13:47:51 | linuxstb | Just for playback I think |
| 13:48:07 | linuxstb | (maybe the function isn't implemented in our pcm driver if they don't work) |
| 13:48:09 | TheSeven | so there's still a missing api... they just show zero |
| 13:48:25 | TheSeven | oscilloscope for recording would be really nice :-) |
| 13:48:25 | linuxstb | Yes, search for "peak" in pcm-s5l8700.c |
| 13:48:35 | | Part LinusN |
| 13:48:45 | * | TheSeven wonders why that's target specific |
| 13:49:12 | linuxstb | I think it's to get access to the data as close as possible to when it enters the DAC |
| 13:49:33 | TheSeven | well, shouldn't every PCM api just be passing it around? |
| 13:51:01 | linuxstb | Yes, perhaps it could be.. |
| 13:52:15 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
| 13:53:57 | TheSeven | ah, it's latencies that are tried to avoid there |
| 13:57:14 | TheSeven | ok, the scope works now |
| 13:57:47 | * | TheSeven wonders why someone bothered writing a stub for that one that's longer than an actually working one |
| 13:58:38 | CIA-85 | New commit by theseven (r23129): S5L870x: Implement pcm_play_dma_get_peak_buffer |
| 14:00 |
| 14:01:21 | | Join elinenbe [0] (n=elinenbe@207-237-212-81.c3-0.80w-ubr4.nyr-80w.ny.cable.rcn.com) |
| 14:03:36 | | Quit locutox (Read error: 101 (Network is unreachable)) |
| 14:03:39 | linuxstb | TheSeven: BTW, I think we should keep interrupts in the bootloader - in the future I think we would want a USB driver there, which I'm assuming will need to be interrupt-driven? |
| 14:04:19 | linuxstb | When IRAM is remapped, I'm assuming it's also still available at 0x22000000 ? |
| 14:04:52 | linuxstb | (plus a button driver if a boot menu is accepted...) |
| 14:06:35 | TheSeven | USB can be done without interrupts (iBugger Loader is doing it that way), but I'm not sure if that would work with rockbox's USB stack |
| 14:06:57 | | Join TheSeven|Mobile [0] (n=TheSeven@92.117.59.40) |
| 14:07:02 | TheSeven | yes, it's still available |
| 14:07:32 | TheSeven | but the int handlers will be called from 0, which may upset them, depending on how they work |
| 14:07:40 | TheSeven | an app build had issues with this at least |
| 14:08:38 | | Quit DerPapst ("Leaving.") |
| 14:09:16 | linuxstb | It should be fine I think - I'll simply specify IRAM as being at 0x22000000 in boot.lds, but remap IRAM. |
| 14:09:52 | linuxstb | The vectors themselves are simply "ldr pc, [pc, #20]" - and those memory locations contain the 0x22xxxxxx address. |
| 14:23:55 | *** | Saving seen data "./dancer.seen" |
| 14:25:51 | | Quit TheSeven (Read error: 113 (No route to host)) |
| 14:47:04 | | Join ruj1 [0] (n=ruj1@PPPoE-78-29-120-117.san.ru) |
| 14:49:51 | | Quit Zarggg (Read error: 110 (Connection timed out)) |
| 14:50:15 | | Join kyle6513 [0] (n=kyle6513@58.174.128.189) |
| 14:50:54 | | Quit robin0800 (Read error: 110 (Connection timed out)) |
| 15:00 |
| 15:00:05 | | Join TheSeven [0] (n=theseven@rockbox/developer/TheSeven) |
| 15:00:25 | | Quit kyle6513 ("Leaving") |
| 15:01:23 | TheSeven | i just listened to my nano during a bus ride, and noticed 3 issues: |
| 15:01:25 | TheSeven | - the scrolling problem (does this also happen on other targets?) |
| 15:01:44 | TheSeven | - the "external power" backlight timer is always used, even if it's running on batteries |
| 15:02:31 | TheSeven | - pause when headphones removed doesn't work |
| 15:02:46 | linuxstb | The third requires you to enable it in the settings - did you do that? |
| 15:03:10 | | Join teru [0] (n=teru@KD059133112132.ppp.dion.ne.jp) |
| 15:03:20 | TheSeven | i did, but it might have been reset by me installing a new build tonight |
| 15:03:23 | TheSeven | let's have a look |
| 15:04:13 | linuxstb | If you just unzip over the top of an existing build, then it shouldn't change your settings. |
| 15:04:27 | linuxstb | (they are in config.cfg, which isn't in rockbox.zip) |
| 15:05:38 | TheSeven | yes, but there was some FS corruption caused by that NAND bug, so it might have it hit |
| 15:05:41 | TheSeven | ok, works again |
| 15:05:52 | TheSeven | s/it hit/hit it/ |
| 15:06:44 | TheSeven | can anybody have a quick check (on any target) if that scrolling issue turns up? |
| 15:08:55 | * | TheSeven wonders where to find the sim current builds |
| 15:10:28 | maruk | TheSeven: what scrolling issue ? |
| 15:10:33 | | Quit antil33t1 (Read error: 104 (Connection reset by peer)) |
| 15:10:40 | | Join antil33t [0] (n=Mudkips@119.224.12.185) |
| 15:11:37 | TheSeven | [12:56]<TheSeven>if text starts scrolling, it will first scroll from the left to the right end correctly. |
| 15:11:39 | TheSeven | [12:56]<TheSeven>then it will scroll back from the right to tle left end again, but twice as much as expected, i.e. beyond the left end |
| 15:11:40 | TheSeven | [12:57]<TheSeven>and it shows very interesting vertically-wrapped characters beneath the left end of the text |
| 15:11:42 | TheSeven | [12:57]<TheSeven>then it will jump to the right end again, and again scroll beyond the left end |
| 15:11:58 | | Part Plouj- ("oh well") |
| 15:13:14 | maruk | TheSeven: nano2g specific issue ? |
| 15:13:28 | TheSeven | that's what I'm trying to find out |
| 15:13:54 | TheSeven | i've only seen it since yesterday, and there was some patch committed that I suspect to cause that on all targets |
| 15:14:09 | maruk | TheSeven: do you know if r22977 is affected ? |
| 15:14:21 | TheSeven | that's probably before it |
| 15:14:23 | linuxstb | TheSeven: You could try a UI simulator for a different target (I'm busy with real work atm...) |
| 15:14:26 | | Join faemir [0] (n=faemir@78.33.109.163) |
| 15:14:45 | TheSeven | I suspect r23105 |
| 15:14:55 | TheSeven | linuxstb: if you tell me where i find the current builds of them? |
| 15:15:21 | mc2739 | TheSeven: I am seeing this scrolling problem on e200v2 with r23123 |
| 15:15:50 | TheSeven | ok, so that's not a target specific issue at least. fine. |
| 15:15:51 | linuxstb | TheSeven: See http://www.rockbox.org/wiki/UiSimulator (for both win32 downloads and instructions for building the sim yourself) |
| 15:15:52 | TheSeven | kugel? |
| 15:16:13 | maruk | TheSeven: no issue on my mini with r22977. |
| 15:16:47 | teru | TheSeven: I think the issue is related to FS #10670. |
| 15:16:50 | TheSeven | linuxstb: these are way too old to contain the issue and I don't have access to my build machine right now |
| 15:17:00 | TheSeven | aren't there build system builds of them to be downloaded somewhere? |
| 15:17:21 | linuxstb | TheSeven: No |
| 15:17:22 | kugel | TheSeven: yes? |
| 15:17:36 | linuxstb | rasher: Is there something wrong with your uisim builds? |
| 15:18:18 | TheSeven | kugel: could it be possible that your patch caused that? |
| 15:18:27 | kugel | which patch? |
| 15:18:38 | TheSeven | r23105 |
| 15:19:01 | kugel | I don't think so, but everything is possible |
| 15:20:25 | mc2739 | linuxstb: I think they are broken from the server move - I believe it was around that date |
| 15:20:36 | TheSeven | kugel: nvm, it's in fact FS #10670 |
| 15:20:51 | kugel | my patch just added center drawing, which is probably as broken as RTL in regards to scrolling. but normal drawing shouldn't be affected any more than it is by rtl |
| 15:21:33 | TheSeven | kugel: the issue only turns up when scrolling |
| 15:21:56 | mc2739 | Zagor: ping |
| 15:22:02 | Zagor | yes? |
| 15:22:10 | * | TheSeven will try http://www.rockbox.org/tracker/task/10670?getfile=20674 as a possible fix when he gets home |
| 15:22:14 | mc2739 | Zagor: when was the server move? |
| 15:23:28 | Zagor | mc2739: sep 16 |
| 15:23:30 | linuxstb | mc2739: 16th September - it's on the news page |
| 15:23:40 | | Quit lifeless_ (Remote closed the connection) |
| 15:23:53 | mc2739 | sorry, should have looked there first |
| 15:24:49 | mc2739 | Zagor: rasher's sim builds page has not had updated sims since the 17th. Could that be related to the move? |
| 15:24:58 | gevaerts | no |
| 15:25:09 | gevaerts | rasher updates his sim builds when he feels like it |
| 15:25:40 | mc2739 | gevaerts: ok, I thought it was automated |
| 15:27:42 | kugel | mc2739: the page says so too |
| 15:27:48 | kugel | "updated daily" |
| 15:28:35 | gevaerts | hm, I might misremember of course |
| 15:29:52 | | Join evilnick [0] (i=0c140464@rockbox/staff/evilnick) |
| 15:30:34 | mc2739 | I am not seeing "updated daily" on that page |
| 15:34:31 | | Quit TheSeven (Nick collision from services.) |
| 15:34:52 | | Join The_Seven [0] (n=theseven@rockbox/developer/TheSeven) |
| 15:35:04 | | Nick The_Seven is now known as TheSeven (n=theseven@rockbox/developer/TheSeven) |
| 15:41:42 | | Join stoffel [0] (n=quassel@p57B4CE05.dip.t-dialin.net) |
| 15:47:19 | | Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) |
| 15:48:07 | kugel | mc2739: rasher.dk/rockbox/">http://rasher.dk/rockbox/ |
| 15:48:25 | kugel | it says "built daily", sorry |
| 15:49:11 | mc2739 | kugel: thanks, I was looking on rasher.dk/rockbox/simulator/">http://rasher.dk/rockbox/simulator/ |
| 15:56:01 | CIA-85 | New commit by teru (r23130): New plugin theme_remove which offers a way to remove specified theme. ... |
| 15:57:42 | | Quit MethoS- (Remote closed the connection) |
| 16:00 |
| 16:00:21 | | Join lifeless_ [0] (n=lifeless@188.18.75.234) |
| 16:09:54 | kugel | \0/ |
| 16:22:49 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 16:23:57 | *** | Saving seen data "./dancer.seen" |
| 16:30:14 | | Quit TheSeven (Read error: 110 (Connection timed out)) |
| 16:33:49 | | Quit lifeless_ (Remote closed the connection) |
| 16:34:06 | | Join lifeless_ [0] (n=lifeless@90.151.210.76) |
| 16:56:15 | | Quit nls_web ("CGI:IRC (EOF)") |
| 16:56:24 | | Join mc2739_ [0] (n=mc2739@rockbox/developer/mc2739) |
| 16:56:38 | | Quit mc2739 (Nick collision from services.) |
| 16:56:40 | | Nick mc2739_ is now known as mc2739 (n=mc2739@rockbox/developer/mc2739) |
| 17:00 |
| 17:01:28 | | Join toffe82 [0] (n=chatzill@12.169.218.14) |
| 17:01:30 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 17:01:38 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 17:02:54 | | Quit Zagor ("Don't panic") |
| 17:03:31 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
| 17:09:39 | | Nick fxb__ is now known as fxb (n=felixbru@85.214.97.64) |
| 17:10:46 | kugel | wooow |
| 17:10:55 | kugel | tiny albumart in my custom statusbar! :D |
| 17:11:01 | gevaerts | \☺/ |
| 17:11:30 | kugel | next to the normal big one that is! |
| 17:12:40 | kugel | http://imagebin.org/67503 at the upper left |
| 17:14:01 | gevaerts | that's reasonably tiny :) |
| 17:14:17 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 17:15:17 | n1s | if you didn't know it's albumart it'd be quite hard to tell :) |
| 17:16:49 | kugel | I need to decouple albumart loading from buffering, and rework the mechanism in playback.c completely |
| 17:18:18 | kugel | that was the last item on my custom statusbar block list |
| 17:18:21 | n1s | how do you mean "decouple albumart loading from buffering" isn't it a good thing they are done at the same time? |
| 17:20:13 | kugel | n1s: the albumart is still buffered |
| 17:20:36 | kugel | but now buffering doesn't know anymore that it's doing albumart, but rather "just a generic image" |
| 17:21:20 | | Quit mt (Read error: 101 (Network is unreachable)) |
| 17:21:38 | kugel | the problem is that buffering calls get_albumart_size directly, that doesn't quite work with multiple sizes (and is unclean anyway) |
| 17:24:57 | n1s | does it scale on load currently? and are you changing that to load the original image and scale later? |
| 17:25:16 | kugel | it scales on load yes, and I don't change it |
| 17:25:37 | n1s | so you will buffer the image several times? |
| 17:26:13 | kugel | in fact, it scales the same image twice now, and buffers the scaled version, which may or may not result in a noticeable delay |
| 17:26:30 | kugel | but I don't see a way around, scaling on display is worse |
| 17:26:38 | n1s | yes |
| 17:27:50 | n1s | does it not get loaded into the wps image buffer? if so it could get scaled on that copy, would of course waste a lot of buffer for people with unreasonable aa sizes |
| 17:27:52 | kugel | also, with my current way of doing this, it will even buffer images of the same size twice, I'm not sure how to fix that best |
| 17:28:32 | kugel | no, it's in the audio buffer and remains there |
| 17:28:41 | | Quit teru ("Quit") |
| 17:30:02 | rasher | Is anyone strongly opposed to me removing the marquee theme and putting an AUTHORS and COPYING file in the wps dir? |
| 17:31:37 | linuxstb | rasher: Are they two independent things? |
| 17:31:57 | rasher | copying is just a copy of the cc-by-sa 3.0 |
| 17:32:03 | kugel | n1s: there's no "wps image buffer" :p |
| 17:32:16 | kugel | did you miss the grand rework? |
| 17:32:35 | rasher | linuxstb: marquee is the only one I haven't gotten permission to (re)license |
| 17:32:45 | linuxstb | rasher: Wasn't there talk of removing all themes from SVN once the theme site was up and running? |
| 17:33:14 | n1s | kugel: eh ok, s/wps image buffer/buffer where wps images are/ |
| 17:33:15 | rasher | linuxstb: yeah.. but so far that's not happening |
| 17:33:37 | kugel | but still, albumart is in the audio buffer, and that makes sense imo |
| 17:33:43 | linuxstb | rasher: Yes, I guess it means someone (or some script) packaging them all and uploading to the site... |
| 17:34:00 | rasher | linuxstb: pretty much, yes |
| 17:34:18 | linuxstb | rasher: But if there are licensing issues which would make things simpler to remove one old WPS, I say go for it. |
| 17:34:39 | gevaerts | rasher: speaking of licensing, the Mountain Fog theme (176x220) seems to use GPL art |
| 17:34:40 | rasher | We'll also still have cabbiev2 in SVN even after that happens though, so we'll need the license and authors anyway, in my opinion |
| 17:35:31 | | Join TheSeven [0] (n=theseven@rockbox/developer/TheSeven) |
| 17:35:42 | n1s | kugel: sure it makes sense i'm just interested in how it works and how you will change it :) |
| 17:36:16 | | Quit amiconn (Remote closed the connection) |
| 17:36:16 | | Quit pixelma (Read error: 54 (Connection reset by peer)) |
| 17:36:44 | | Join dfkt_ [0] (i=dfkt@unaffiliated/dfkt) |
| 17:37:10 | kugel | n1s: buffering isn't changed much (just multiple versions of the albumart per track), the bigger change is in playback.c |
| 17:37:26 | | Join amiconn [0] (i=quassel@rockbox/developer/amiconn) |
| 17:37:27 | | Join pixelma [0] (i=quassel@rockbox/staff/pixelma) |
| 17:37:44 | | Join mcuelenaere [0] (n=mcuelena@78-22-177-194.access.telenet.be) |
| 17:38:15 | kugel | there's now a struct holding various function pointers. each skin (or anyone who wants albumart buffered), adds his struct to the linked list, on buffering playback iterates through that list handling each skin's albumart |
| 17:38:26 | mcuelenaere | amiconn, kugel, linuxstb, TheSeven: the Onda's already have a boot menu in the boot loader |
| 17:38:40 | kugel | mcuelenaere: argg! |
| 17:38:44 | mcuelenaere | but that's mostly because the VX777 doesn't have any physical buttons so it needs to use the screen for dual boot |
| 17:38:53 | mcuelenaere | to select the OF* |
| 17:39:06 | mcuelenaere | kugel: I don't see what the problem is? |
| 17:39:12 | kugel | we can have an exception for that I think |
| 17:39:41 | mcuelenaere | currently it has 4 options: boot Rockbox, boot OF, USB mode & reset Rockbox configuration |
| 17:39:50 | kugel | I just don't like the idea, in a year someone comes up with the idea to port grub/lilo because the rockbox bootloader menu is too crappy |
| 17:40:11 | linuxstb | kugel: Then say yes/no to that, not something else... |
| 17:40:20 | CIA-85 | New commit by rasher (r23131): Clear up theme licensing: ... |
| 17:40:23 | mcuelenaere | so what? let them do that, that doesn't mean it should get included in our tree.. |
| 17:40:33 | * | linuxstb doesn't buy into the "don't do X because then people will want Y" argument |
| 17:40:44 | n1s | kugel: playback dealing with the aa feels very wrong to me; although i'm not familiar with how the playback/buffering works |
| 17:41:49 | kugel | n1s: there's no way around, only playback knows which track is currently played and which are buffered, and what cleanup is needed, etc |
| 17:42:07 | mcuelenaere | TheSeven: FYI, there are several USB implementations of the S3C64xx OTG/device controller in Linux |
| 17:42:48 | n1s | kugel: that sounds to me like something that buffering shoudl deal with |
| 17:43:10 | kugel | hell no |
| 17:43:16 | amiconn | ugh |
| 17:43:55 | rasher | linuxstb: my sims were built on soap's box, and he's vanished. |
| 17:44:08 | kugel | buffering is a module alone, just doing what it is told: buffering stuff, and removing stuff from the buffer, and the memory management. it shouldn't know what it buffers, or when to buffer |
| 17:44:42 | linuxstb | rasher: Yes, I saw you say that.... I just wanted to check if you knew. |
| 17:45:15 | kugel | albumart is tied to the currently playing, and upcoming, songs. that's a job for playback |
| 17:45:25 | | Quit dfkt (Read error: 145 (Connection timed out)) |
| 17:45:45 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 17:46:12 | n1s | kugel: thei i suppose i think there should be a layer between the current buffering and playback that knows what is buffered and deals with the details of that and to which playback gives events |
| 17:46:19 | n1s | s/thei/then |
| 17:46:43 | kugel | playback does that |
| 17:47:05 | n1s | yes and to me it seems like playback is soing too much |
| 17:47:10 | n1s | doing |
| 17:47:14 | kugel | it's the glue between buffering, codecs and audio thread. another layer doesn't make much sense |
| 17:47:33 | | Quit dfkt_ (Nick collision from services.) |
| 17:49:27 | n1s | since it is preforming such a complex task, further division of labour seems logical to me |
| 17:51:19 | | Join kkurbjunW [0] (n=karlk@12.41.166.9) |
| 17:51:22 | kugel | it could need a bit of cleanup yes (like moving some parts to playlist, or splitting playback.c into more source files), but I think the general layout is fine |
| 17:51:32 | kugel | i.e. I don't see a use for another layout |
| 17:51:35 | kugel | layer* |
| 17:51:45 | kkurbjunW | gevaerts: Is there a wiki page on using USB serial? |
| 17:52:11 | gevaerts | kkurbjunW: PortalPlayerUsb |
| 17:53:12 | kkurbjunW | haha, I wish I found that before, I got it working on my own, but only after hours of messing with it |
| 17:53:19 | kkurbjunW | thanks |
| 17:54:48 | | Quit petur ("work->home") |
| 17:55:09 | kkurbjunW | can wiki topic title's be changed? Since this is no longer specific to the portal player it seems a different title might be helpful |
| 17:55:39 | toffe82 | interesting for the sigmatel chips : http://www.machspeed.com/onyx2g4gupdate.htm : SigmaTel 35XX SDK Device Updater |
| 17:57:14 | kkurbjunW | gevaerts: USB high speed works fine on the m66591 - is the fullspeed/highspeed note still pertinent for the portal players? |
| 17:57:46 | toffe82 | I think it can be used with all the sigmatel chips.. |
| 17:57:55 | kkurbjunW | I mean, specifically for USB serial that is |
| 17:58:24 | | Join tomers [0] (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) |
| 17:58:34 | gevaerts | kkurbjunW: ah, no. The usb_serial was fixed to work around the issues |
| 17:59:18 | | Join uflops [0] (n=yogurt@90-231-195-226-no112.tbcn.telia.com) |
| 17:59:35 | gevaerts | The problem was that packet sizes larger than 96 bytes don't work properly on PP without boosting. Serial now uses 32 or 64 byte packets (can't remember which) |
| 17:59:37 | | Quit polobricolo () |
| 18:00 |
| 18:02:02 | kkurbjunW | gevaerts: I see that we have a UsbSoftwareStack page - it looks like it is there for historical reasons, but would it make sense to have the USB serial on it's own "driver" page? I found some other information online that seems to indicate that some people have made it work in windows too by writing an INF |
| 18:02:48 | kkurbjunW | gevaerts: the PP connect at high speed correct? |
| 18:03:19 | gevaerts | if the host does, yes |
| 18:03:55 | | Join liar|netbook [0] (n=liar@83.175.83.185) |
| 18:04:21 | kugel | kkurbjunW: why don't you ask earler then? :) |
| 18:04:29 | | Quit TheSeven|Mobile (Read error: 104 (Connection reset by peer)) |
| 18:04:30 | kkurbjunW | do you know if the serial driver takes the speed into account? packet sizes are limited to 64 bytes in full speed right? |
| 18:04:39 | kkurbjunW | kugel: I assumed no one was awake |
| 18:05:17 | kkurbjunW | it was in the evening yesterday that I was messing around with it |
| 18:05:30 | kkurbjunW | I guess it doesn't have to |
| 18:06:21 | kkurbjunW | but I was wondering if the problems were showing on systems that only connected at fullspeed, or if it was having trouble at high speed. |
| 18:06:22 | gevaerts | kkurbjunW: it does, yes |
| 18:10:21 | kkurbjunW | gevaerts: the other thing I was running into is that the start of some of the packets coming from the serial driver were not word aligned which was causing data aborts on the M:Robe 500. I can fix that in the driver for the m66591, but I was wondering if you know offhand whether the other USB drivers can handle packets that do not have a starting point that is word aligned? I was thinking about forcing the serial driver to align the start of all of it's p |
| 18:12:01 | kkurbjunW | the m66591 driver usually works with shorts, and switches to byte mode when it gets to the end of a packet and it is not half-word aligned. In doing so it assumes that the start of the packets are word aligned, which works on the storage driver, but fails when I enable logging for buffering |
| 18:13:47 | kkurbjunW | sorry, this: "end of a packet and it is not half-word aligned" should read: "end of a packet and it's length is odd" |
| 18:14:36 | | Quit mikroflops (Read error: 110 (Connection timed out)) |
| 18:16:11 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 18:16:48 | | Join bertrik_ [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 18:18:21 | | Quit bluebrother (Nick collision from services.) |
| 18:18:23 | | Join bluebroth3r [0] (n=dom@rockbox/developer/bluebrother) |
| 18:20:08 | | Quit tomers (Read error: 113 (No route to host)) |
| 18:23:56 | | Join polobricolo [0] (n=paul@AGrenoble-257-1-6-12.w86-193.abo.wanadoo.fr) |
| 18:24:00 | *** | Saving seen data "./dancer.seen" |
| 18:27:25 | | Join tomers [0] (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) |
| 18:28:13 | tomers | I am about to commit the patch in "FS #10670 - The first letter of a scrolling line starts to appear at the end of the line" which finally seems to solve the scrolling issue. I've tested it on both RTL and LTR languages. Any objections? |
| 18:28:21 | linuxstb | rasher: So themes in SVN are now dual-licensed? |
| 18:29:38 | rasher | linuxstb: They'd have to be, considering they've been implicitly gplv2 or later up until now |
| 18:31:47 | CIA-85 | New commit by tomers (r23132): Fix FS #10670 - The first letter of a scrolling line starts to appear at the end ... |
| 18:32:25 | linuxstb | rasher: Yes, I understand that. But what about future modifications? |
| 18:33:17 | rasher | linuxstb: I guess we have free hands there. Maybe we should just switch completely |
| 18:34:46 | | Quit maruk ("Leaving.") |
| 18:36:12 | linuxstb | rasher: Yes, I think so - just to keep things simple. |
| 18:37:47 | linuxstb | rasher: BTW, how did you determine the authors list? I recall making some changes to some themes... |
| 18:39:20 | rasher | linuxstb: I'm not entirely sure.. this was a while ago, but I think I looked mainly in the theme files themselves, and commit messages |
| 18:39:36 | kugel | tomers: I'm not sure if that fix is correct |
| 18:39:45 | linuxstb | You're probably right - looking back at the changelog, my changes were all relatively minor... |
| 18:39:56 | kugel | the "ofs" is a bad variable name. |
| 18:40:02 | tomers | kugel: It worked both for English and Hebrew scrolling |
| 18:40:36 | tomers | Both in RTL mode (Hebrew interface) and LTR mode (English interface) |
| 18:40:56 | kugel | have you tried if it breaks holding left/right in the main menu? this moves the entire menu to the left/right (that's what ofs is for) |
| 18:42:46 | kugel | if ofs is > 0, it actualy draws the text (for ltr) with the first few pixels cut away ( "File Browser" gets "le Browser". all other items too) |
| 18:42:59 | kugel | I'll just try |
| 18:43:28 | CIA-85 | New commit by rasher (r23133): Move to only CC-BY-SA 3.0 for future changes. |
| 18:45:40 | | Quit polobricolo (Remote closed the connection) |
| 18:46:23 | | Join polobricolo [0] (n=paul@AGrenoble-257-1-6-12.w86-193.abo.wanadoo.fr) |
| 18:46:31 | tomers | rasher: It works just fine, when scrollbar is in either one of the side |
| 18:46:44 | * | tomers away |
| 18:49:33 | kugel | tomers: seems to work, although setting ofs to 0 seems wrong to me at a quick glance |
| 18:49:44 | | Quit robin0800 (Remote closed the connection) |
| 18:51:31 | | Quit intrados1 (Read error: 60 (Operation timed out)) |
| 18:51:59 | gevaerts | kkurbjunW: at least the ARC controller doesn't care about alignment |
| 18:53:18 | gevaerts | I think it would be reasonable to say that you need alignment if you want decent performance, and use slower byte-oriented methods if the buffer isn't aligned |
| 18:56:41 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 19:00 |
| 19:03:18 | * | kugel questions the use of tiny albumart now that he sees it on target :P |
| 19:03:44 | gevaerts | kugel: you need a bigger status bar of course :) |
| 19:04:18 | | Nick uflops is now known as mikroflops (n=yogurt@90-231-195-226-no112.tbcn.telia.com) |
| 19:06:37 | | Quit robin0800 (Remote closed the connection) |
| 19:06:40 | kugel | gevaerts: and a bigger screen ;) |
| 19:11:36 | | Quit liar|netbook (Read error: 148 (No route to host)) |
| 19:14:23 | | Quit kkurbjunW (Remote closed the connection) |
| 19:15:19 | | Join codearn [0] (n=18adac9e@giant.haxx.se) |
| 19:15:30 | | Join kkurbjunW [0] (n=karlk@12.41.166.8) |
| 19:19:07 | amiconn | rasher: Imo building win32 sims should be turned into a configure option. Actually adding them to the build system will require a workaround for the dreaded sectioned compilation warning though :\ |
| 19:20:43 | rasher | It will also be complicated by having to have a different PATH set |
| 19:21:01 | rasher | or some other way to let it know where the proper sdl-config lives |
| 19:21:01 | | Quit antil33t (Read error: 104 (Connection reset by peer)) |
| 19:21:15 | | Join antil33t [0] (n=Mudkips@119.224.12.185) |
| 19:24:01 | amiconn | It would need to interate through all sdl-config binaries it can find, and check which is which |
| 19:24:20 | | Quit Rob2223 (Remote closed the connection) |
| 19:24:22 | amiconn | That's a comparably small problem... |
| 19:25:00 | | Join Rob2222 [0] (n=Miranda@p4FDCD647.dip.t-dialin.net) |
| 19:25:43 | codearn | Hi everyone. I just put the latest build on my sansa e200v2 and the "limiter preamp" doesn't show up on the sound settings menu. I couldn't find anything on google other than a mention that pitch control has to be off, but I can't find a way to disable it... I'm sure I'm missing something... |
| 19:25:50 | | Quit Rob2222 (Client Quit) |
| 19:26:06 | | Join Rob2222 [0] (n=Miranda@p4FDCD647.dip.t-dialin.net) |
| 19:27:01 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 19:30:11 | | Join saratoga [0] (i=98039f25@gateway/web/freenode/x-qaalunyzcusrmzpa) |
| 19:30:32 | saratoga | according to the changelog: "DSP limiter replaced by a dynamic range compressor" |
| 19:31:01 | | Join tomers_ [0] (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) |
| 19:31:31 | | Quit tomers (Read error: 113 (No route to host)) |
| 19:31:42 | | Nick tomers_ is now known as tomers (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) |
| 19:31:46 | tomers | kugel: Let me know if there is something more to do with regards to this issue |
| 19:32:45 | codearn | oh i see. thanks a bunch. i had a feeling that might be it. |
| 19:32:47 | | Join Strife89 [0] (n=michael@168.16.237.214) |
| 19:32:59 | rasher | amiconn: Do you think crosscompiling should be an advanced option? |
| 19:33:40 | amiconn | perhaps |
| 19:33:53 | codearn | do you know if there is documentation available on the compressor? the sansa manual doesn't have it yet |
| 19:34:20 | amiconn | Doesn't really matter, as long as there is no solution for that warning. It's one of the few warnings which cannot be disabled individually |
| 19:34:37 | amiconn | And in fact the warning doesn't even make sense |
| 19:35:43 | kugel | could the build system whilelist that warning so that it doesn't case a yellow? |
| 19:36:31 | kugel | cause* |
| 19:36:33 | | Join merbanan [0] (n=banan@c-83-233-172-245.cust.bredband2.com) |
| 19:36:44 | | Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) |
| 19:38:08 | | Quit stoffel (Remote closed the connection) |
| 19:42:05 | rasher | I wouldn't say it's completely useless. The current way to do crosscompiling is pretty gross |
| 19:42:12 | rasher | I'm switching it to an advanced option now |
| 19:43:58 | amiconn | It warns that sectioned compilation may affect debugging. But that simply doesn't apply to the win32 obect and binary formats |
| 19:45:05 | | Quit evilnick (Ping timeout: 180 seconds) |
| 19:48:11 | GodEater | my rsync-fu is broken :( |
| 19:51:12 | | Join midgey [0] (n=tjross@rockbox/developer/midgey) |
| 19:51:46 | midgey | amiconn: is the warning something similar to "-ffunction-sections may affect debugging on some targets"? |
| 19:52:02 | amiconn | yes |
| 19:55:01 | | Join petur [0] (n=peter@d54C6F49C.access.telenet.be) |
| 19:55:01 | midgey | the same warning shows up on OS X 10.5 when compiling the sim. it appears to be gone on 10.6 |
| 19:56:54 | | Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
| 20:00 |
| 20:00:35 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
| 20:00:35 | | Join bughunter2 [0] (n=bughunte@unaffiliated/bughunter2) |
| 20:01:27 | | Join Eragon55 [0] (i=chatzill@dyn216-8-173-180.ADSL.mnsi.net) |
| 20:01:28 | | Quit codearn ("CGI:IRC (EOF)") |
| 20:04:19 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
| 20:04:27 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 20:08:47 | | Join liar|netbook [0] (n=liar@83.175.83.185) |
| 20:09:34 | kugel | hmm, I'm having a problem |
| 20:09:43 | | Join panni_ [0] (i=hannes@ip-95-222-21-143.unitymediagroup.de) |
| 20:09:55 | kugel | I post something to the audio thread with queue_send/_post, but it doesn't come through |
| 20:10:30 | | Join T44 [0] (n=Topy44@f049029014.adsl.alicedsl.de) |
| 20:11:40 | CIA-85 | New commit by nls (r23134): Fix typo from r19579 that prevented this code from building, avoid copying lang strings |
| 20:12:20 | * | TheSeven just found a tricky ibugger bug by accident while porting the USB code to rockbox |
| 20:13:05 | kugel | oh, my queue_send comes before audio_init() |
| 20:13:05 | * | n1s wonders if anyone uses that charging screen on their recorders, the text drawing has been broken since late 2008 |
| 20:14:03 | kugel | argh |
| 20:14:18 | kugel | audio_init comes after wps_init, I'm not sure if I can swap them easily |
| 20:14:29 | rasher | amiconn: is it "warning: -ffunction-sections may affect debugging on some targets" you were talking about? |
| 20:14:36 | rasher | oh ah |
| 20:14:41 | rasher | You just answered that, I see |
| 20:14:49 | rasher | anyway, I think I have it working now as a configure option |
| 20:15:39 | kugel | amiconn: can I shuffle a bit in init()? I need settings_apply after audio_init() |
| 20:16:36 | | Quit Topy44 (Read error: 60 (Operation timed out)) |
| 20:16:55 | | Quit FOAD (Read error: 110 (Connection timed out)) |
| 20:16:55 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 20:20:39 | | Join Jaykay [0] (n=chatzill@p5DDC7B8B.dip.t-dialin.net) |
| 20:21:30 | amiconn | Init order is quite important for certain things. I don't remember whether this is the case for these two things |
| 20:22:19 | Jaykay | hi, I'm getting only seven columns from dev.cgi |
| 20:22:29 | Jaykay | from the first table |
| 20:23:20 | bertrik_ | kugel, I've been thinking a bit about your idea for doing the DBOP reads |
| 20:23:40 | bertrik_ | if we make sure to wait for the FIFO to be empty in the interrupt routine, we might not need the dbop locks at all |
| 20:24:01 | *** | Saving seen data "./dancer.seen" |
| 20:24:45 | amiconn | kugel: Idk which one you intended to move, but moving settings_apply past audio_init is a very bad idea and must not be done |
| 20:24:45 | bertrik_ | this wasn't possibly previously because we communicated directly with the LCD, but now we're just communicating with the buttons on the DBOP data bus |
| 20:25:40 | linuxstb | Jaykay: That's normal now - only columns with yellow or red are shown. |
| 20:25:40 | TheSeven | Jaykay: you shouldn't get any :-) |
| 20:25:53 | amiconn | Many modules inited after the current settings_apply() call need the settings already applied (that's why it's done that way) |
| 20:26:54 | Jaykay | ok, thanks :) |
| 20:26:58 | bertrik_ | kugel, there may be some time wasted in the read button interrupt waiting for the FIFO to drain, but it's probably not *that* bad in practice |
| 20:27:18 | rasher | Is anyone - anyone at all - interested in checking out the patch I have for making simulator crosscompiling a configure option? |
| 20:27:34 | linuxstb | rasher: I'll give it a shot... |
| 20:28:18 | rasher | linuxstb: rasher.dk/rockbox/configure_crosscompiling_v1.diff">http://rasher.dk/rockbox/configure_crosscompiling_v1.diff |
| 20:28:32 | kugel | amiconn: why? |
| 20:29:11 | amiconn | Several modules need the values in order to know how much buffer they need to allocate |
| 20:29:16 | rasher | linuxstb: you should have a crosscompiled SDL in your PATH (preferably last, or you won't be able to compile regular sims...) |
| 20:29:32 | kugel | I mean you didn't say why audio_init() must not be done after settings_apply() |
| 20:29:54 | kugel | s/not// |
| 20:30:02 | amiconn | I did not say that |
| 20:30:07 | FlynDice | n1s: Are you working on that unused variable warning for r23134 or is it ok? |
| 20:30:58 | kugel | ok, I missread then, can I move audio_init() up? there's mp3_init() for hwcodec which looks suspicous in that regard |
| 20:31:02 | amiconn | I said that moving settings_apply after audio_init would be a bad idea. |
| 20:31:12 | amiconn | There are dozens of inits happening inbetween |
| 20:31:58 | amiconn | It *might* be possible to move audio_init() up, but I wouldn't dare to without testing *all* targets |
| 20:31:59 | kugel | none of them looks like they depend on the audio thread doing nothing in their init, I haven't looked at them though |
| 20:32:13 | | Quit n1s (Read error: 110 (Connection timed out)) |
| 20:32:46 | | Quit Jaykay ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]") |
| 20:32:52 | kugel | hm, there a few inits which do grab the audio buffer, that won't work |
| 20:33:01 | linuxstb | rasher: I don't think it feels right to have it as an advanced option - I would expect to at least choose "S" in the first menu. "W" is also free in the first menu, even though that's getting very busy... |
| 20:33:01 | amiconn | yep |
| 20:33:39 | amiconn | And I also think hwcodec audio_init() needs mp3_init() to be done already |
| 20:33:58 | linuxstb | rasher: Also, if I selected "w" first, then "s" in advanced options, it didn't work. I needed "s" then "w"... |
| 20:33:59 | kugel | a) I do settings_apply() again after audio_init(), or b) I don't know how to do it :/ |
| 20:34:11 | rasher | linuxstb: but that would add another question each time you build a regular sim |
| 20:34:16 | * | amiconn wonders why kugel suddenly wants to shuffle inits |
| 20:34:35 | linuxstb | rasher: I'm not suggesting that. |
| 20:34:53 | rasher | linuxstb: what then? Another top-level entry? |
| 20:36:21 | kugel | amiconn: in my multiple album art work, skins send something to the audio thread (in order to be thread safe). the skins are already parsed in settings_apply(). their post goes into the dark at the boot |
| 20:36:35 | kugel | i.e. it doesn't work unless the skin is reloaded manually |
| 20:37:20 | linuxstb | rasher: I'm not sure.... I guess what's there now is as good as anything. |
| 20:37:40 | rasher | I guess there's no need for crosscompiling to depend on simulator. With any luck the database and checkwps tool could work as well |
| 20:38:14 | rasher | except you can't enable those through the advanced menu |
| 20:38:48 | * | amiconn doesn't seem to understand without additional context information |
| 20:39:20 | linuxstb | rasher: But it seemed to correctly detect that I don't have a cross-compiled sdl installed... |
| 20:39:47 | kugel | amiconn: the skins attach a struct of callbacks to a linked list in playback.c. the callbacks are only called in the audio thread, so it would be safe to attach them in the audio thread only too |
| 20:40:04 | rasher | linuxstb: Great |
| 20:40:21 | linuxstb | rasher: (and I do have a native sdl-config) |
| 20:40:52 | rasher | I've removed the dependency on simulator being set. |
| 20:41:46 | kugel | I could use an event, so that the skins send it again after the audio thread inited |
| 20:41:50 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 20:42:16 | amiconn | How do skins "send" something? Aren't they simply loaded in the main thread? |
| 20:42:19 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 20:42:37 | kugel | yes they are |
| 20:43:00 | kugel | they call playback_add_aa_cb(), which adds the parameter to a linked list |
| 20:45:12 | * | amiconn still doesn't see the problem |
| 20:46:20 | kugel | the linked list is accessed for doing the actual albumart work in the audio thread only, while the adding to the linked list is (currently) done in the main thread |
| 20:46:37 | kugel | removing can also happen |
| 20:47:27 | kugel | the main thread may remove a struct from the linked list, while the audio thread is accessing it |
| 20:47:35 | CIA-85 | New commit by nls (r23135): fix yellow |
| 20:47:53 | amiconn | And? |
| 20:47:57 | amiconn | No it may not. Remember, rockbox does cooperative threading |
| 20:48:03 | domonoky | if the audio thread does not yield when looping over the linked-list, it should be pretty safe to do it from the mainthread. we have cooperative multitsaking :-) |
| 20:48:20 | domonoky | s/multisaking/multitasking :-) |
| 20:48:42 | kugel | it does |
| 20:48:51 | kugel | the scaler yields while scaling |
| 20:49:01 | linuxstb | rasher: I can confirm that a normal sim still builds OK. |
| 20:49:31 | CIA-85 | New commit by rasher (r23136): Change the Windows crosscompiling logic: ... |
| 20:49:32 | rasher | BAM! |
| 20:51:05 | | Quit midgey () |
| 20:51:51 | | Join midgey [0] (n=tjross@67-194-72-117.wireless.umnet.umich.edu) |
| 20:52:01 | amiconn | The scaler is only called when loading album art though, not for loading skins |
| 20:52:39 | * | amiconn is slightly confused |
| 20:53:26 | kugel | if the albumart size in the wps changed (after loading a skin), then audio is restart to pick the new sizes up. I happen to send the stuff after that |
| 20:53:48 | | Join DataGhost [0] (n=dataghos@ip3e832ea5.speed.planet.nl) |
| 20:53:50 | kugel | but while writing it, I notice should probably change that anyway |
| 20:54:40 | kugel | what if someone changes his theme/skin while rebuffering when the scaler is active? |
| 20:55:13 | CIA-85 | New commit by FlynDice (r23137): AMS Sansa: Remove BUSWIDTH and BLOCKLEN commands and revise strategy for High Speed SD Card. ... |
| 20:55:40 | amiconn | Hmm. You could protect skin access with a mutex |
| 20:55:51 | rasher | tomers: There seems to be an issue with the bar line-selector when using RTL menus |
| 20:56:02 | rasher | tomers: it doesn't cover the entire width of the screen (viewport?) |
| 20:56:03 | amiconn | But the scaler puts the loaded album art into the audio buffer, not into the skin |
| 20:56:36 | kugel | one of the callbacks in the struct is called just before the scaler gets active to get the albumart dimensions |
| 20:56:41 | amiconn | Only if that track starts playing, the audio thread copies the bitmap for display (certainly without yielding) |
| 20:57:18 | kugel | the bitmap isn't copied |
| 20:57:44 | amiconn | Then a pointer is changed somewhere... doesn't really matter |
| 20:59:30 | kugel | it seems possible to me that the linked list is changed while the scaler is doing his work |
| 21:00 |
| 21:00:18 | amiconn | If you really want to deal with complex signalling and load skins from the audio thread (btw, you'd then also need to do an implementation for hwcodec, which still doesn't use the same thread), it would still not require shuffling inits |
| 21:00:21 | kugel | in the next look it even may result in a null-pointer access if a struct was removed |
| 21:00:35 | amiconn | [20:55:45] <amiconn> Hmm. You could protect skin access with a mutex |
| 21:00:54 | kugel | s/loop/loop/ |
| 21:00:58 | kugel | I'm gonna think about it more |
| 21:01:07 | CIA-85 | New commit by rob (r23138): Replace a couple of magic numbers with the appropriate constants. |
| 21:02:25 | kugel | Maybe I'm just gonna use a one-shot event at the end of audio_init(), as it's only an issue at booting |
| 21:02:54 | amiconn | You could also check if audio is already inited, and if not, just call the function |
| 21:03:07 | amiconn | There will be no race at boot because the audio thread doesn' |
| 21:03:12 | amiconn | t exist yet |
| 21:03:56 | amiconn | But don't forget KISS (and that there are two places you need to hook your code if you're going for the complex solution) |
| 21:04:05 | kugel | then I'd have to expose both, the function that does queue_send(), and the one that does the actual work. but that would work too |
| 21:04:31 | amiconn | Even that isn't necessarily the case |
| 21:04:47 | kugel | ah yea, you're right |
| 21:04:52 | amiconn | The function that normally does queue_send is probably part of audio, right? |
| 21:04:57 | kugel | I think in playback.c there's already a way to detect that |
| 21:05:07 | amiconn | And if it is, it should know whether audio is already inited |
| 21:05:22 | kugel | that seems like the way to go, thanks! |
| 21:05:24 | amiconn | It could decide itself |
| 21:05:35 | | Quit avacore^ (Read error: 60 (Operation timed out)) |
| 21:05:36 | | Join pegwole [0] (n=tj@c-98-220-152-190.hsd1.in.comcast.net) |
| 21:05:46 | * | amiconn mentions mpeg.c once more, just in case |
| 21:06:00 | | Join avacore [0] (i=nobody@1008ds1-rdo.0.fullrate.dk) |
| 21:06:07 | kugel | I'll have a look, maybe :p |
| 21:06:28 | pegwole | i'm pretty sure i'm retarded, but can you put rockbox on the RCA M4303? |
| 21:06:39 | * | TheSeven wonders if this TCC usb driver can actually work |
| 21:06:47 | kugel | there isn't a hwcodec that does albumart, and since everythign is #ifdef HAVE_ALBUMART I see only a little point (i.e. just for completeness) |
| 21:07:22 | TheSeven | (for more than control transfers) |
| 21:07:29 | kugel | amiconn: does the current hwcodec audio handle albumart in any way? |
| 21:07:43 | amiconn | No, but it does load skins |
| 21:08:12 | kugel | alright, a stub should do it then |
| 21:08:34 | amiconn | In theory all bitmap targets could do album art though, just that 1-bit album art isn't really recognisable in most cases |
| 21:09:30 | kugel | and even the stub would be within #ifdef HAVE_ALBUMART |
| 21:10:12 | | Join intrados1 [0] (n=intrados@d149-67-101-219.col.wideopenwest.com) |
| 21:10:56 | | Quit intrados1 (SendQ exceeded) |
| 21:11:48 | krazykit | pegwole, supported targets are listed on the front page |
| 21:12:53 | | Join intrados1 [0] (n=intrados@d149-67-101-219.col.wideopenwest.com) |
| 21:16:28 | pegwole | i'm not seeing it...shit |
| 21:16:58 | pegwole | welp looks like i have to hate freedom using this thing :( |
| 21:25:40 | TheSeven | gevaerts: what the hell is usb_drv_set_test_mode? |
| 21:26:13 | | Quit ruj1 () |
| 21:27:41 | | Join shotofadds [0] (n=rob@rockbox/developer/shotofadds) |
| 21:27:44 | | Join barrywardell [0] (n=barrywar@rockbox/developer/barrywardell) |
| 21:27:59 | linuxstb | TheSeven: AppleOS now loads if I don't enable the cache... |
| 21:28:16 | TheSeven | do you disable the cache before firing it up? |
| 21:28:20 | shotofadds | TheSeven: the tcc usb driver has worked in the past, I've used it to transfer several hundred megs of raw NAND data once |
| 21:28:38 | shotofadds | USB serial works too, but it's rather unreliable all round |
| 21:29:11 | | Quit midgey () |
| 21:29:15 | TheSeven | shotofadds: I just keep seeing things like "if (endpoint != 0) panicf_my(..." which should pretty much block all non-control traffic |
| 21:29:19 | linuxstb | TheSeven: No, I haven't tried that. Would the four lines of code in crt0.S with the comment "// disable caches and protection unit" be enough? |
| 21:29:33 | TheSeven | should work |
| 21:29:41 | shotofadds | TheSeven: er yes, I remember, I had to comment a few bits out ;-) |
| 21:30:00 | TheSeven | conventions for switching to the next stage of code is irq/fiq disabled, ROM mapped to zero, protection unit off |
| 21:30:19 | shotofadds | unfortunately I know nothing about USB and never got around to learning enough to try and fix it |
| 21:32:40 | | Part pegwole |
| 21:34:44 | linuxstb | TheSeven: Yes, that seems to work ;) |
| 21:34:45 | gevaerts | TheSeven: see usb 2.0 7.1.20. It's to put the device in special modes that allow electrical measurements (things like waveform) |
| 21:35:06 | TheSeven | what the hell do we need this for? |
| 21:36:19 | gevaerts | only for strict spec compliance |
| 21:36:33 | TheSeven | i.e. this will never be called anyways? |
| 21:37:35 | gevaerts | I'd at least make sure not to crash if it is |
| 21:39:20 | TheSeven | gevaerts: does the core expect endpoint states to be cleared or retained on bus resets? |
| 21:39:51 | gevaerts | hm, good question |
| 21:40:27 | gevaerts | which endpoint states do you meant? Things like stall, or allocations? |
| 21:41:22 | TheSeven | both |
| 21:41:52 | TheSeven | and will the core change the address to zero again, or does the driver do that? (well, I'll just do it, can't hurt) |
| 21:42:12 | | Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) |
| 21:42:28 | gevaerts | endpoing allocations are kept, transfers in progress and stalls are not |
| 21:43:32 | | Quit n1s (Read error: 60 (Operation timed out)) |
| 21:44:26 | gevaerts | although clearing endpoint allocations won't hurt either |
| 21:44:39 | | Join stoffel [0] (n=quassel@p57B4CE05.dip.t-dialin.net) |
| 21:45:49 | gevaerts | basically you're allowed to reset everything |
| 21:46:15 | | Quit Eragon55 ("ChatZilla 0.9.85 [Firefox 3.5.4/20091007001339]") |
| 21:46:46 | CIA-85 | New commit by dave (r23139): Nano2G bootloader - fix dual-booting the Apple firmware. |
| 21:47:18 | | Join Sajber^ [0] (n=Sajber@h-142-150.A213.priv.bahnhof.se) |
| 21:51:30 | TheSeven | oh, that USB driver is getting funny |
| 21:51:40 | TheSeven | DMA vs. cache again... |
| 21:53:52 | TheSeven | what a waste of space and time... |
| 21:54:03 | TheSeven | I'll need to copy over every single buffer used for USB |
| 21:59:21 | amiconn | Why copy? |
| 22:00 |
| 22:01:17 | TheSeven | for some weird unknown reason flushing the caches doesn't work properly |
| 22:01:38 | TheSeven | so we usually just circumvent them, but we don't have control about the location of the buffers here. |
| 22:02:04 | TheSeven | so I'll need to copy everything from a cached to an uncached buffer and back |
| 22:02:47 | linuxstb | bluebroth3r: What would be needed to add Nano2G support to rbutil? I now have a working patch for ipodpatcher, which I should commit later tonight (after double-checking it doesn't affect earlier ipods) |
| 22:02:56 | amiconn | eeek |
| 22:03:27 | linuxstb | TheSeven: Have you given up trying to get cache flushing working? |
| 22:03:34 | amiconn | Sounds like investigating cache flush/invalidations would be a good idea |
| 22:05:04 | TheSeven | I'm doing it like it's described in the datasheet, but it doesn't work |
| 22:05:17 | TheSeven | I was told the samsas have the same problem |
| 22:05:25 | TheSeven | or were it the old sansas? |
| 22:05:26 | | Join notlistening [0] (n=tom@94-195-105-95.zone9.bethere.co.uk) |
| 22:05:39 | kugel | we had the problem, but not anymore |
| 22:06:10 | TheSeven | yes, but you also circumvented it by just circumventing the cache at all, right? |
| 22:06:31 | TheSeven | i.e. the flushing itself is still broken? |
| 22:06:46 | kugel | but "DMA vs cache" sounds awfully known to me |
| 22:08:29 | notlistening | FlynDice, just be testing the latest cpu boost patch that you posted, it not reads the SD card after startup at 1.05v but after exactly 60 seconds of run time i am getting unreferences instruction error even without the SD card inserted |
| 22:09:06 | | Quit stoffel (Remote closed the connection) |
| 22:09:53 | FlynDice | notlistening: Can you try with 1.10 volts and see if that works? |
| 22:09:53 | notlistening | *now reads |
| 22:10:12 | notlistening | FlynDice, yeah that works nicely |
| 22:10:13 | kugel | I don't know too much about that stuff, but the cpu doesn't have much control about DMA, right (other than starting the transfer)? that somehow sounds to me as DMA with cached buffer can't work reliably. but feel free to ignore me |
| 22:11:20 | notlistening | FlynDice, o just wanted to try on the lower setting as it is not fair my player doesn't like it |
| 22:11:24 | amiconn | TheSeven: PP is even more fun, as it has two cores with independent caches, yet we managed it without resorting to copying everything |
| 22:11:44 | linuxstb | Don't we just used the uncached memory aliases? |
| 22:11:45 | | Quit Grahack ("Leaving.") |
| 22:11:52 | | Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) |
| 22:12:22 | TheSeven | yes, that works fine, but not for USB, as the sources of all these buffers are scattered all over the place |
| 22:12:39 | amiconn | We do in several places, yes, but now everywhere |
| 22:13:18 | JdGordon | someone fix tuner.c already! its painful to work in |
| 22:13:30 | FlynDice | notlistening: I think the low voltage is the culprit. It seems when players have problems and we raise the voltage back to 1.10 the problems go away. Some players do ok, others can't habdle it. |
| 22:14:00 | kugel | FlynDice: I'm not surprised, wasn't 1.10V already a questionable setting? |
| 22:14:03 | amiconn | Basic operation is obvious: flush cache before transferring something from a buffer to a peripheral via dma, and invalidate the cache before transferring something from a peripheral to a memory buffer via dma |
| 22:14:07 | * | linuxstb wonders where the platform numbers in rbutil.ini come from |
| 22:14:32 | FlynDice | notlistening: Not really, the OF uses 1.10 |
| 22:14:34 | amiconn | Then there are the little nasty things one needs to observe, e.g. cache line boundaries |
| 22:14:36 | TheSeven | amiconn: exactly what we did, and what didn't work |
| 22:15:14 | amiconn | These impose additional requirements for buffer alignment |
| 22:15:15 | | Join Djeepp [0] (n=smiller@12.163.98.18) |
| 22:15:33 | kugel | FlynDice: questionable as in the datasheet recommends to not use it, IIRC we do use it just becuase the OF does |
| 22:15:46 | TheSeven | amiconn: you should be able to get rid of that by just cleaning/invalidating too much |
| 22:16:10 | amiconn | Not in all cases |
| 22:16:22 | TheSeven | why? |
| 22:16:38 | linuxstb | domonoky, bluebroth3r: ping |
| 22:17:08 | amiconn | E.g. if you're going to transfer something from a peripheral to a buffer, you invalidate the cache, then kick off dma |
| 22:17:08 | domonoky | pong |
| 22:17:25 | Horscht | fault |
| 22:17:32 | amiconn | While dma is running, you calculate something in an adjacent buffer, with the cachelines overlapping -> BAM |
| 22:17:34 | linuxstb | domonoky: Do you know what's needed for ipodnano2g support in rbutil? I'm loooking at rbutil.ini first... |
| 22:17:51 | linuxstb | domonoky: Why do only some targets have USB IDs? |
| 22:18:05 | amiconn | The cpu will cache the whole line, possibly before the dma transfer changed the in-memory data |
| 22:18:15 | Djeepp | The scroll down key on my Gigabeat F40 doesn't work at all unless I turn the touchpad sensitivity to high. I'm guessing I need a new touchpad. Is there a place I can get this part? |
| 22:19:24 | domonoky | linuxstb: the usb-ids are the way they are, because of the current autodetection. (there is a patch in the tracker witch tries to improve it, and use all usb-ids) |
| 22:19:25 | amiconn | After the dma finished, the contents of the transfer buffer is invalid as seen by the cpu, because it re-cached too early |
| 22:19:37 | linuxstb | domonoky: Ah, I'm just looking at the "how to add a new target" in the wiki page.... Given that's it is supported by ipodpatcher, I guess I just need to edit rbutil.ini and recompile with my new ipodpatcher code... |
| 22:19:45 | amiconn | You can construct such an example for the other dma direction as well |
| 22:19:51 | domonoky | linuxstb: for ipodnano2g you shouldnt enter a usb-id at moment. |
| 22:20:20 | bluebroth3r | linuxstb: pong |
| 22:20:33 | domonoky | linuxstb: yes, add a entry to rbutil.ini similar to the other ipod entrys, recompile and it should work . |
| 22:20:35 | linuxstb | domonoky: Yes, I won't. But I've deleted the USB ID from the list later on - I assume those are "unsupported" ? |
| 22:21:07 | linuxstb | Also, is there any significance to the platform numbers? I see they're similar to the configure menu... |
| 22:21:15 | domonoky | ah, yes the list with only usb-ids is for targets we dont support. |
| 22:21:51 | bluebroth3r | no, the platform numbers are only used for sorting (btw, are they used anymore?) |
| 22:21:54 | domonoky | linuxstb: they should be the number from configure, its used for voicefiles (if i didnt fixed that) |
| 22:22:18 | amiconn | The menu numbers from configure shouldn't be used elsewhere |
| 22:22:19 | bluebroth3r | domonoky: really? |
| 22:22:51 | CIA-85 | New commit by jdgordon (r23140): fix a redraw bug when a static token (like %C) is the only token on a sub/line.. hopefully no bad sideeffects... |
| 22:22:53 | | Nick bluebroth3r is now known as bluebrother (n=dom@rockbox/developer/bluebrother) |
| 22:22:57 | domonoky | at least i introduced them, to use it in voicefiles (its in the header). |
| 22:23:12 | domonoky | oh, its not the menu-number, but the target-id from configure. |
| 22:23:34 | linuxstb | Also, how should out-of-tree building work? I create a "build-rbutil" and then run "qmake ../rbutil/rbutil.pro" ? |
| 22:23:40 | bluebrother | hmm. Is that used in Rockbox anywhere? It would be much better to get rid of those numbers completely |
| 22:23:42 | domonoky | jup |
| 22:23:43 | bluebrother | linuxstb: yes |
| 22:23:56 | linuxstb | bluebrother: I tried that, and got a load of errors at the start about lang files |
| 22:24:03 | *** | Saving seen data "./dancer.seen" |
| 22:24:20 | linuxstb | Hmm, strange, it working a second time... |
| 22:24:21 | bluebrother | linuxstb: that's normal if you are building a release (which is the default) |
| 22:24:29 | domonoky | we shouldnt need the target-id in rbutil.ini anymore, because its also in the rockbox-info.txt file. |
| 22:24:49 | domonoky | linuxstb: you can ignore the lang file errors :-) |
| 22:24:50 | bluebrother | it's simply rcc complaining that it can't find the *.qm files, which get generated later. |
| 22:25:19 | bluebrother | to be exact, it's even qmake that is complaining. rcc isn't running that moment. |
| 22:25:37 | linuxstb | Do you have a new rbutil release planned for the near future? |
| 22:25:48 | bluebrother | btw, you can also build using deploy-release.py -d -p path/to/rbutilqt.pro |
| 22:26:13 | * | bluebrother hasn't planned a release |
| 22:26:26 | domonoky | linuxstb: my rbutil.ini file doesnt contain any target-id anymore. |
| 22:28:15 | * | bluebrother started working on a new install UI, but that will take some time until ready |
| 22:30:05 | domonoky | when ipod2g gets unstable status, it might be a good time to make a new rbutil release. :-) |
| 22:30:38 | amiconn | linuxstb: I don't think too much differentiation between targets would be good |
| 22:31:56 | bluebrother | domonoky: btw, there's a bug with languages: the tts window saves the language string (like "english") while the system language uses two-letter abbreviations (like "en") as in the ts filenames. Though I'm wondering why those two values are using the same setting at all |
| 22:32:03 | amiconn | And as another contradiction to your list - rockbox on the H300 isn't fully functional compared to the OF. A major feature is missing - USB host. |
| 22:32:39 | TheSeven | wow - there are DAPs that support USB host out of the box? |
| 22:32:45 | | Join Stephen__ [0] (n=S@86-45-101-88-dynamic.b-ras2.srl.dublin.eircom.net) |
| 22:33:18 | linuxstb | amiconn: So you don't want a "top-tier" category of targets? I'm aware of missing USB host on the h300 (and X5?), that's why my description includes "possible minor exceptions". |
| 22:33:28 | bluebrother | TheSeven: the beast also claims host support. Never tried it, though. |
| 22:33:40 | domonoky | bluebrother: i dont really understand. can you point me to the code doing it ? |
| 22:33:49 | amiconn | On the H300, usb host should be doable as the chip is documented. The one in the X5 is not. |
| 22:33:52 | toffe82 | Djeepp: I have a lot of them in stock |
| 22:34:11 | amiconn | It's "just" a lot of work... |
| 22:35:14 | Djeepp | toffe82: Do you have a website? |
| 22:35:46 | bluebrother | domonoky: createvoicewindow.cpp:53: RbSettings::setValue(RbSettings::Language, lang); |
| 22:36:17 | linuxstb | domonoky: "Unstable" Nano2g should be quite soon... I think the port itself is there, I just need to release a bootloader and new ipodpatccher. |
| 22:36:31 | bluebrother | probably something I broke when reworking the settings −− no idea if that was separated from the application language before. |
| 22:36:52 | bluebrother | but how should it work? I'd say it should be a setting different from the application language. |
| 22:37:01 | | Quit Thundercloud (Remote closed the connection) |
| 22:37:11 | bluebrother | linuxstb: impressive how fast that was done. |
| 22:37:34 | domonoky | bluebrother: true, that looks wrong. |
| 22:37:35 | domonoky | it should use VoiceLanguage |
| 22:38:06 | domonoky | line 79 tries to use this, and Language as a fallback, but it stores it to the wrong setting. |
| 22:38:13 | linuxstb | Hmm, my rbutil compiled with speex errors |
| 22:38:35 | | Join ysae [0] (n=ysae@77.47.97.171) |
| 22:38:36 | linuxstb | rbspeex.c:(.text+0x59d): undefined reference to `speex_resampler_destroy' |
| 22:38:37 | linuxstb | etc |
| 22:38:43 | JdGordon | kugel: how did you end up doing multi-aa? |
| 22:38:47 | kugel | my attemps to store the handle ids for the albumarts on the skin buffer all failed |
| 22:39:11 | kugel | JdGordon: don't ask :D |
| 22:39:39 | toffe82 | Djeepp: no, just rockbox ;) http://www.rockbox.org/wiki/SpareParts I didn't mentionned them here but I have them... |
| 22:39:40 | JdGordon | too late |
| 22:40:07 | kugel | well, some struct and a linked list |
| 22:40:44 | CIA-85 | New commit by Domonoky (r23141): rbutil: store the voice language in the correct setting. |
| 22:40:51 | JdGordon | show us a patch? |
| 22:41:00 | * | JdGordon is bored and curious |
| 22:41:09 | kugel | it's a really complicated area, keeping all stuff local to playback nor keeping it all local to the skins doesn't work, |
| 22:41:35 | kugel | meh, it just doesn't work easily |
| 22:41:37 | linuxstb | bluebrother, domonoky: Any thoughts about my speex problem? |
| 22:42:00 | JdGordon | I thjought you said you got it going ok? or just "good enough"? |
| 22:42:01 | bluebrother | linuxstb: I've heard of that before but can't reproduce. |
| 22:42:02 | Djeepp | toffe82: Are they new or recycled from old ones? |
| 22:42:14 | linuxstb | bluebrother: I can! ;) |
| 22:42:31 | toffe82 | Djeepp: recycled |
| 22:42:33 | bluebrother | linuxstb: then fix it! ;-) |
| 22:42:39 | linuxstb | Hmm... |
| 22:42:43 | * | bluebrother checks if he has that VM still around |
| 22:42:55 | kugel | JdGordon: kugel-rb.git?a=commitdiff;h=e1482953a0892db9c59fc1d0e412c14468586e38;hp=288363b2389d5d965700a7018661605367c346db">http://repo.or.cz/w/kugel-rb.git?a=commitdiff;h=e1482953a0892db9c59fc1d0e412c14468586e38;hp=288363b2389d5d965700a7018661605367c346db |
| 22:42:58 | bluebrother | my guess is that it's related to the version of speex. Mine is rather old |
| 22:43:55 | kugel | JdGordon: I thought it worked ok, but then I noticed heavy instability :p |
| 22:43:55 | linuxstb | Yes, I recall recent API changes to speex (well, around the time we switched to speex for voice files) |
| 22:43:55 | toffe82 | Djeepp: I don't think you will find new ones |
| 22:43:55 | JdGordon | :) |
| 22:44:03 | domonoky | dont we use the speex copy in rockbox svn for rbutil ? |
| 22:44:03 | linuxstb | bluebrother: I seem to have 1.5.0 |
| 22:44:22 | amiconn | bluebrother: Wasn't there a change to use the system's libspeex recently? Maybe that was a bad idea... |
| 22:44:45 | JdGordon | kugel: I really think the best thing right now is to not allow %C in the statusbar skin |
| 22:44:52 | JdGordon | and ignore all the complication |
| 22:45:01 | bluebrother | amiconn: yes, and that's the cause. That was based on an old task that introduced that. Though I'm starting to wonder if it was a bad idea, indeed. |
| 22:45:17 | kugel | nah, you gotta love the tiny albumart, have you seen my screendump from earlier today? |
| 22:46:26 | gevaerts | JdGordon: I want album art in my status bar! |
| 22:46:27 | Djeepp | toffe82: I guess my question is, will I have the same problem as I have now? The buttons often stick and sometimes don't work at all. |
| 22:46:35 | JdGordon | no |
| 22:46:56 | JdGordon | multi-aa should be a seperate beast commit anyway |
| 22:47:08 | TheSeven | linuxstb, amiconn: major problem. |
| 22:47:11 | kugel | it will be, don't worry |
| 22:47:12 | JdGordon | there is already a "wtf do we do about remote aa's?" comment... |
| 22:47:23 | linuxstb | TheSeven: With what? |
| 22:47:24 | TheSeven | the 940T can only flush cache *indices*, not cache *addresses* |
| 22:47:33 | TheSeven | so we'll probably need to wipe the whole cache? |
| 22:47:42 | | Quit JdGordon ("Leaving.") |
| 22:47:55 | TheSeven | but that will have trouble with yielding |
| 22:48:16 | amiconn | On most (all?) other targets we just flush or invalidate the whole cache, not individual cache lines |
| 22:48:43 | amiconn | Targets which have a cache of some sort, obviously |
| 22:49:13 | kugel | I think the beast has a function to do it for single lines, no idea if it's used |
| 22:49:48 | TheSeven | amiconn: we can't just *drop* the cache after the operation then |
| 22:50:41 | amiconn | No, you always need to flush before invalidating |
| 22:51:26 | bluebrother | linuxstb: a quick fix is to comment out the lines calling pkg-config in rbutilqt.pro and the librbspeex Makefile |
| 22:51:33 | amiconn | Iirc our cache_invalidate() function in fact does both (on targets with a data cache or unified cache) |
| 22:55:24 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 22:56:37 | | Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) |
| 22:59:08 | linuxstb | bluebrother: Yes, I've reverted 23016 for now... |
| 22:59:14 | notlistening | Is there something that runs 60 seconds after boot on rockbox? |
| 22:59:56 | gevaerts | I hope so |
| 23:00 |
| 23:00:44 | notlistening | domonoky, I found a few issues with rgutil on openpsapi but but the in task |
| 23:00:51 | bluebrother | linuxstb: hopefully I'll be able to reproduce that once my VM setup is finished ... |
| 23:01:05 | * | TheSeven wonders why we aren't having any issues with audio DMA |
| 23:01:28 | domonoky | notlistening: i saw it, but didnt find time to work on this. thanks for testing. |
| 23:02:20 | notlistening | ok, they are little things really, it work really well under linux but no mac to test on :( |
| 23:06:19 | linuxstb | bluebrother: Seems to work nicely ;) Should I commit my rbutil.ini changes, or wait until everything else is in place/ |
| 23:08:21 | bluebrother | linuxstb: I don't see a problem with committing it now. |
| 23:09:08 | linuxstb | bluebrother: OK. I think I'll wait and commit with my ipodpatcher changes though. |
| 23:10:54 | kugel | argh |
| 23:11:03 | kugel | I'll do another approach |
| 23:11:48 | notlistening | kugel, thanks for sorting the scroll wheel for me and everyone ;) |
| 23:12:02 | kugel | well, I caused the problems :p |
| 23:13:18 | TheSeven | yay! |
| 23:13:34 | TheSeven | managed to do NAND transfers without cache spoiler bits :-) |
| 23:14:21 | | Quit kkurbjunW (Remote closed the connection) |
| 23:14:26 | TheSeven | however, I'll still need to copy everything to prevent alignment problems |
| 23:14:40 | | Quit JdGordon ("Leaving.") |
| 23:15:21 | | Join kkurbjunW [0] (n=karlk@12.41.166.9) |
| 23:15:29 | TheSeven | forcing the alignment upwards on everything won't be possible, huh? |
| 23:16:07 | | Quit kkurbjunW (Remote closed the connection) |
| 23:17:00 | saratoga | can't you just copy the start of the buffer's unaligned bytes, then DMA the remainder |
| 23:17:09 | | Join kkurbjunW [0] (n=karlk@12.41.166.8) |
| 23:17:42 | TheSeven | saratoga: DMA will need things to be continuous |
| 23:18:27 | saratoga | you can't copy via load/store instruction? |
| 23:18:35 | saratoga | for the first couple bytes |
| 23:18:47 | amiconn | Nothing prevents you from setting up multiple dma transfers either |
| 23:19:26 | amiconn | I.e. copy & dma the first block, then transfer the main block (and copy the remainder in paralle), then transfer the remainder |
| 23:19:36 | TheSeven | amiconn: We can maybe do this with things like UART, but not with AHB masters like NAND, ECC, Crypto, USB, ... |
| 23:20:32 | saratoga | then copy the start to an aligned buffer, DMA 3 bytes or whatever, and then DMA the remainder of the original buffer |
| 23:20:51 | saratoga | and end I guess |
| 23:20:57 | TheSeven | saratoga: I can't split the transfer |
| 23:21:11 | saratoga | what is this for? |
| 23:21:11 | | Join JdGordon| [0] (n=Miranda@rockbox/developer/JdGordon) |
| 23:21:29 | | Quit petur (Remote closed the connection) |
| 23:22:00 | | Quit merbanan (Read error: 110 (Connection timed out)) |
| 23:22:05 | TheSeven | these are peripherals that are bus masters, which will organize the transfers themselves. i can't even influence it. |
| 23:22:25 | TheSeven | i just write the address of the data to one reg, a start command to another one, and they do the rest |
| 23:23:16 | amiconn | And what stops you to do this more than once, using an isr that's called when each partial transfer ends? |
| 23:23:46 | * | amiconn thinks that you have to specify the length of the transfer as well somewhere |
| 23:24:40 | TheSeven | yes, but this will end up influence the actual length of packets on the e.g. USB bus |
| 23:24:49 | TheSeven | and with ECC, that can't work at all, as I'm not even specifying a length |
| 23:25:00 | amiconn | ECC? |
| 23:25:30 | * | amiconn wonders whether this newer SoC is really that unflexible |
| 23:25:49 | TheSeven | hey, bus master DMA transfers are a great thing! |
| 23:26:23 | TheSeven | the problem is just that we don't manage to enforce some alignment constraints |
| 23:27:34 | TheSeven | in fact, it will probably always work nevertheless |
| 23:27:46 | amiconn | DMA can be very useful, yes. But I fail to see why the peripheral transfer sizes need to be linked to the dma block size |
| 23:28:51 | TheSeven | because the peripherals are organizing all that crap themselves and fetch the data when they need them automatically instead of having the CPU telling them about each and every bit to transfer |
| 23:29:02 | | Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 23:29:17 | | Quit Strife89 ("My number of files is OVER 9000!") |
| 23:29:34 | TheSeven | are there realistic cases where stuff immediately beneath (within 12 bytes) of a DMA buffer will be touched during the transfer? |
| 23:29:43 | amiconn | They don't do this in a magical way, but they talk to the built-in dma controller. This is basically just a speed control |
| 23:30:18 | TheSeven | they are DMA controllers itself |
| 23:30:52 | saratoga | someday i figure out how to use our mailing list without getting my posts garbled |
| 23:30:55 | saratoga | but that day is not today |
| 23:33:36 | kkurbjunW | TheSeven: They are just bus masters correct? A bus master does not necessarily have to be linked to a DMA block size or bus burst size - they could do single transfers if they were intelligent enough. At least with the systems we create. |
| 23:34:13 | | Join DerPapst [0] (n=DerPapst@p4FE8F166.dip.t-dialin.net) |
| 23:34:37 | TheSeven | yes, they are just AHB masters, and I think they can do that. |
| 23:35:06 | TheSeven | the problem is just that the CPU caches may trash some things if we touch data immediately beneath unaligned DMA buffers during the transfer |
| 23:38:04 | | Quit bmbl ("Bye!") |
| 23:39:20 | tomers | rasher: Does the bar line selector should cover the entire screen? Including the icon? |
| 23:39:50 | kugel | wps_reset() is highly annoying |
| 23:40:02 | rasher | tomers: It does when using ltr. Also, it seems to just randomly extend past "some amount" of the screen |
| 23:40:39 | * | TheSeven will just forget about alignment and have a look if all kind of weird worms will start creeping around |
| 23:41:03 | kkurbjunW | ahh, interesting,I guess even if you did a flush and something in the cache line changes and the line is flushed later it would cause problems - I guess the cache doesn't keep track of what is dirty and write just what has changed |
| 23:41:22 | TheSeven | kkurbjunW: that's what i suspect |
| 23:42:06 | | Quit Djeepp ("Konversation terminated!") |
| 23:42:12 | tomers | rasher: Can you please clarify? I can't reproduce on e200. Seems ok both RTL and LTR |
| 23:43:41 | rasher | tomers: rasher.dk/rockbox/rtl-bar.png">http://rasher.dk/rockbox/rtl-bar.png |
| 23:43:53 | rasher | Taken with an e200 sim |
| 23:44:56 | rasher | it should extend all the way to the left |
| 23:46:10 | tomers | rasher: I can't reproduce. What is the theme/font? Is it a clean build (just in case)? |
| 23:46:23 | rasher | tomers: Unicatcher theme, clean build |
| 23:47:00 | | Join Lss [0] (n=Lss@cm46.delta91.maxonline.com.sg) |
| 23:47:23 | tomers | rasher: Font? |
| 23:47:38 | rasher | unifont - the one selected by UniCatcher |
| 23:48:56 | tomers | /me Compiling clean build and testing on e200 target |
| 23:49:58 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
icon identifies that the person is a core developer (has commit access).