00:03:15 | | Quit domonoky (Read error: Connection reset by peer) |
00:06:33 | | Quit ender` (Quit: If at first you don't succeed, skydiving is not for you.) |
00:07:18 | | Quit krazykit (Ping timeout: 258 seconds) |
00:10:40 | | Join ender` [0] (krneki@foo.eternallybored.org) |
00:13:02 | | Quit alexbobp (Read error: Connection reset by peer) |
00:13:10 | Torne | woohoo. git repository containing absolutely everything in the svn repository, including ancient branches, themesite, etc: 137MB |
00:13:18 | Torne | Notably smaller than one copy of our source. :) |
00:13:56 | | Join alexbobp [0] (~alex@209.135.10.128) |
00:14:34 | AlexP | cool |
00:15:23 | Torne | it's not very friendly to look at at the moment though because that is 133 branch heads |
00:15:32 | Torne | since svn tags are also treated as branches |
00:15:45 | Torne | and, er, a bunch of virtual branches for where we have done weird shit with svn is also treated as branches. :) |
00:16:04 | AlexP | clean-upable? |
00:16:08 | Torne | Yes |
00:16:16 | Torne | those are all under refs/remotes |
00:16:27 | Torne | we will discard all those refs once we stop needing to update from svn |
00:16:37 | Torne | so now i need to make proper git branch heads and tags for the ones we care about |
00:16:39 | | Quit Rob2222 (Quit: Rob2222) |
00:16:51 | Torne | which I'm going to decide arbitrarily is "everything with any content in, even if it's ancient" |
00:16:54 | Torne | because it's *tiny* |
00:17:02 | Torne | but quite a lot of these branches have no content |
00:17:15 | Torne | and i can always put the old ones somewhere that clone won't bother cloning them by default |
00:20:29 | *** | Saving seen data "./dancer.seen" |
00:20:41 | | Quit robin0800 (Ping timeout: 240 seconds) |
00:21:44 | | Join krazykit [0] (~krazykit@206.183.185.8) |
00:25:41 | | Quit esperegu (Remote host closed the connection) |
00:25:49 | | Join robin0800 [0] (~robin0800@149.254.60.171) |
00:33:45 | | Quit sideral (Quit: Leaving.) |
00:37:30 | | Quit Stephen___ (Ping timeout: 240 seconds) |
00:40:25 | | Quit pamaury (Remote host closed the connection) |
00:41:34 | | Join Scromple [0] (~Simon@115-64-195-104.tpgi.com.au) |
00:44:43 | | Quit ender` (Quit: It always takes longer than you expect, even when you take Hofstadter's Law into account. -- Hofstadter's Law) |
00:46:17 | | Quit mudd1 (Quit: Ex-Chat) |
00:49:59 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
00:52:51 | | Quit dantje (Quit: Ex-Chat) |
00:54:34 | | Quit bertrik (Quit: :tiuQ) |
00:55:29 | | Nick kramer3d is now known as d3remark (~kramer@unaffiliated/kramer3d) |
01:00 |
01:00:15 | | Quit TheLemonMan (Quit: Ex-Chat) |
01:10:18 | | Quit hobby16 (Ping timeout: 240 seconds) |
01:10:30 | | Join Rob2222 [0] (~Miranda@p5DE4B0F9.dip.t-dialin.net) |
01:10:45 | | Join BHSPitMonkey_ [0] (~stephen@68-185-203-185.dhcp.dntn.tx.charter.com) |
01:11:06 | | Quit bzed (Remote host closed the connection) |
01:11:14 | | Join bzed [0] (~bzed@devel.recluse.de) |
01:19:45 | | Quit BHSPitMonkey_ (Remote host closed the connection) |
01:29:52 | | Quit Xerion (Ping timeout: 255 seconds) |
01:45:06 | | Quit powell14ski_ (Ping timeout: 264 seconds) |
01:46:45 | | Join powell14ski_ [0] (~powell14s@c-174-51-194-6.hsd1.co.comcast.net) |
01:53:30 | | Quit powell14ski_ (Ping timeout: 264 seconds) |
01:56:32 | | Join powell14ski_ [0] (~powell14s@c-174-51-194-6.hsd1.co.comcast.net) |
02:00 |
02:08:15 | | Join CaptainKewl [0] (captainkew@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
02:18:43 | | Quit mikroflops (Ping timeout: 260 seconds) |
02:19:39 | | Quit GeekShadow (Quit: The cake is a lie !) |
02:20:31 | *** | Saving seen data "./dancer.seen" |
02:23:54 | | Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) |
02:33:23 | | Join mikroflops [0] (~yogurt@h-34-156.A238.priv.bahnhof.se) |
02:36:13 | | Quit Thra11 (Ping timeout: 260 seconds) |
02:57:00 | | Join ReimuHakurei [0] (~reimu@74.112.212.15) |
03:00 |
03:03:16 | | Quit liar (Quit: hallowed are the ori!) |
03:07:41 | | Quit robin0800 (Read error: Connection timed out) |
03:08:39 | | Join robin0800 [0] (~robin0800@149.254.61.208) |
03:09:29 | | Join fdinel [0] (~Miranda@modemcable036.124-131-66.mc.videotron.ca) |
03:09:35 | | Quit Judas_PhD (Quit: This is a quitting message) |
03:15:23 | | Quit Rob2222 (Read error: Connection reset by peer) |
03:36:44 | | Quit Zarggg (Quit: Rebooting client...) |
03:44:12 | | Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) |
04:00 |
04:05:07 | | Quit [7] (Disconnected by services) |
04:05:18 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
04:20:32 | *** | Saving seen data "./dancer.seen" |
04:24:39 | | Quit evilnick (Read error: Connection reset by peer) |
04:44:19 | | Nick is now known as kramer3d (~kramer@unaffiliated/kramer3d) |
04:50:01 | | Quit amiconn (Disconnected by services) |
04:50:02 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
04:50:15 | | Quit pixelma (Disconnected by services) |
04:50:17 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
04:50:19 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
04:50:19 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
04:59:54 | | Join Strife89 [0] (~Strife89@207-144-19-39.cstel.net) |
05:00 |
05:21:20 | | Quit kramer3d (Ping timeout: 240 seconds) |
05:22:29 | | Quit patheticbliss (Ping timeout: 260 seconds) |
05:23:26 | | Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
05:34:47 | JdGordon | gevaerts: dammit... more thai spam not in that ip range |
05:38:46 | JdGordon | though... if all the bans between mum_maisusa and the ip ban on the 27th are from that one i say WIN |
05:42:32 | | Quit Horscht (Quit: Verlassend) |
05:46:20 | | Quit CaptainKewl (Ping timeout: 276 seconds) |
05:50:30 | | Quit Topy44 (Read error: Connection reset by peer) |
05:52:24 | | Quit Strife89 (Quit: Sleep) |
06:00 |
06:06:10 | | Join legendarymidget [0] (~7cb593dd@giant.haxx.se) |
06:09:13 | | Quit factor (Read error: Connection reset by peer) |
06:09:30 | | Quit legendarymidget (Client Quit) |
06:14:25 | | Quit Scromple (Ping timeout: 240 seconds) |
06:20:34 | *** | Saving seen data "./dancer.seen" |
06:25:14 | | Quit robin0800 (Read error: Connection timed out) |
06:26:21 | | Join robin0800 [0] (~robin0800@149.254.61.208) |
06:26:42 | | Join factor [0] (~factor@74.197.205.204) |
06:28:13 | | Join icarusfactor [0] (~factor@74.197.205.204) |
06:28:57 | | Quit factor (Disconnected by services) |
06:29:03 | | Nick icarusfactor is now known as factor (~factor@74.197.205.204) |
06:38:50 | | Quit robin0800 (Quit: Leaving) |
06:47:27 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
06:51:55 | | Join antil33t [0] (~antil33t@124-197-33-15.callplus.net.nz) |
06:54:36 | | Join Keripo [0] (~Keripo@c-76-28-198-27.hsd1.wa.comcast.net) |
06:55:33 | | Quit sideral (Quit: Leaving.) |
07:00 |
07:09:34 | | Quit CIA-27 (*.net *.split) |
07:10:26 | | Join CIA-14 [0] (~CIA@cia.atheme.org) |
07:28:03 | | Join Thra11 [0] (~thrall@220.171.pn.adsl.brightview.com) |
07:30:46 | | Join hobby16 [0] (~ubuntu@157.186.193.77.rev.sfr.net) |
07:48:48 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
07:51:44 | | Quit factor (Read error: Connection reset by peer) |
08:00 |
08:00:12 | | Join factor [0] (~factor@74.197.205.204) |
08:10:58 | | Join Scromple [0] (~Simon@115-64-195-104.tpgi.com.au) |
08:18:57 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
08:20:37 | *** | Saving seen data "./dancer.seen" |
08:21:27 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
08:37:07 | CIA-14 | New commit by jethead71 (r30097): Commit FS #12150 - Fully-functional audio mixer - and finally whip old limitations about playback of voice and other sounds when paused. Channels are ... |
08:38:37 | JdGordon | woohoo |
08:39:23 | jhMikeS | yeehaa |
08:41:20 | sideral | yippie |
08:41:56 | jhMikeS | ooh, 1 1/2 mins overdue, that's usually not a good sign for build errors :D |
08:42:06 | CIA-14 | r30097 build result: 82 errors, 5342 warnings (jethead71 committed) |
08:42:10 | JdGordon | nice call |
08:42:42 | JdGordon | uh oh |
08:42:46 | JdGordon | IRAM full |
08:43:05 | | Join ender` [0] (krneki@foo.eternallybored.org) |
08:43:19 | | Quit Scromple (Ping timeout: 264 seconds) |
08:43:20 | jhMikeS | also forgot to filter in some places for SWCODEC :\ |
08:43:21 | JdGordon | have fun with that :D |
08:43:59 | jhMikeS | by 24 bytes? |
08:51:42 | jhMikeS | one by one I suppose |
08:53:24 | | Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) |
08:54:15 | wodz | jhMikeS: Are there any constraints for the size param in pcm_play_dma_start()? |
08:54:52 | | Join pondlife [0] (~Steve@rockbox/developer/pondlife) |
08:55:36 | wodz | rk27xx hardware have 16bit reg for dma size expressed in transfer units (32bits) so I am wondering if I have to provide some logic to extend this to full 32bit size |
08:55:44 | * | pondlife pops in to thank/congratulate jhMikeS |
08:56:33 | wodz | and one more - do I assume correctly that size param in pcm_play_dma_start() is expressed in bytes? |
08:56:35 | jhMikeS | wodz: multiples of four bytes |
08:56:43 | jhMikeS | pondlife: thank you |
08:56:54 | jhMikeS | wodz: it is, yes |
08:57:19 | GodEater | hmm - the build has a broken in it? |
08:57:21 | jhMikeS | wodz: the layer above rounds it though |
08:57:31 | wodz | jhMikeS: what about size limit? |
08:57:45 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
08:58:06 | kugelp | jhMikeS: \o/ |
08:58:07 | jhMikeS | a 16-bit reg for word count should be enough |
08:59:40 | wodz | ams pcm driver has logic to split dma transaction but there the limit is much lower (10 or 11bits of word count) |
08:59:53 | | Join esperegu [0] (~quassel@145.116.15.244) |
09:00 |
09:01:26 | jhMikeS | android is giving trouble with including pcm-mixer-armv5.c |
09:03:15 | jhMikeS | hmmm...thing thing actually didn't add as much binsize as I seem to remember eariler on |
09:03:21 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
09:03:22 | | Quit bertrik (Changing host) |
09:03:22 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
09:05:27 | | Quit pondlife (Read error: Connection reset by peer) |
09:06:11 | CIA-14 | New commit by jethead71 (r30098): Knock out at least some red/yellow from r30097. |
09:09:38 | jhMikeS | wodz: imx31 has been getting away with a limit of 64KB just fine without resorting to splitting it up, though it easily could |
09:10:20 | CIA-14 | r30098 build result: 19 errors, 0 warnings (jethead71 committed) |
09:11:14 | wodz | jhMikeS: cool - this simplifies pcm driver :-) |
09:14:22 | wodz | hmm interesting that m5 has iram full while other coldfires not |
09:15:05 | jhMikeS | the other ones had some left over |
09:18:56 | wodz | Am I right that I can't use register values representation for SOUND_VOLUME and have to use tenth of dB? |
09:19:31 | jhMikeS | correct |
09:19:42 | wodz | shit |
09:20:26 | jhMikeS | dammnit, I have no andoid build stuff installed |
09:22:05 | wodz | I wonder who invented this #@%@# gain setup pattern in rk27xx codec. That is insane. |
09:23:51 | wodz | our code seems to assume that gain steps are distributed evenly |
09:24:02 | | Join Rob2222 [0] (~Miranda@p4FFF388B.dip.t-dialin.net) |
09:24:40 | | Join Topy44 [0] (~Topy44@f049108161.adsl.alicedsl.de) |
09:27:35 | kugelp | wodz: seems like a reasonable assumption to me :-) |
09:29:01 | | Quit utanapischti (Quit: WeeChat 0.3.2) |
09:29:04 | wodz | yeh - tell this to engineers from Dolphin :-) |
09:29:27 | | Join utanapischti [0] (~username@p4FF2D8E2.dip.t-dialin.net) |
09:29:55 | jhMikeS | it's craziness like that that made me an index-based advocate |
09:30:50 | | Join petur [0] (~petur@rockbox/developer/petur) |
09:31:54 | kugelp | jhMikeS: android uses the Target tree under hosted |
09:32:09 | kugelp | it cannot easily see stuff under ARM |
09:32:39 | jhMikeS | it will see it under /firmware? |
09:33:00 | kugelp | yes |
09:33:39 | kugelp | could also do an empty c in the android Target tree that includes via hardcoded path |
09:34:44 | [Saint] | Just, whatever you do...do it soon. I want to see if it magically fixes keyclick and track skip bep on my phone ;) |
09:34:48 | [Saint] | *beep too |
09:35:17 | kugelp | or have an extra dir for arch specific things that are native/hosted dependant |
09:35:19 | [Saint] | (audio playback cuts out something wicked during keyclick for some reason) |
09:35:40 | JdGordon | keyclick should be vibrate on android :) |
09:36:34 | jhMikeS | [Saint]: kugelp checked it afaik, don't know if he checked those other bits. I also don't know if it needs to be implemented like the SDL version to really work perfectly. |
09:36:34 | kugelp | are *not |
09:37:36 | jhMikeS | oh heck, what would that path be to include it properly? |
09:37:58 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
09:38:00 | [Saint] | JdGordon: I'd thought about adding a menu entry for keyclick for haptic feedback as well, so as to have one, the other, or both enabled...but I couldn't find out how to tie into haptic feedback properly. |
09:42:15 | jhMikeS | or...for now, I can skip the optimized include for non-native targets and let someone able to build that actually sort it out rather than maybe committing the wrong thing :) |
09:43:13 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
09:44:47 | [Saint] | Bah! Where's the sense of adventure in that? ;) |
09:45:01 | [Saint] | Build errors are part of learning! |
09:45:31 | jhMikeS | I've got other crap to sort out, like IRAM being ful on a few things, which is bad enough |
09:47:36 | CIA-14 | New commit by jethead71 (r30099): Get android to build. Forgo optimized mixing code for app builds for the moment; work it out later. |
09:51:17 | jhMikeS | what the heck is the IRAM suck on m5 that doesn't disturb h100 series? |
09:51:23 | CIA-14 | r30099 build result: 16 errors, 0 warnings (jethead71 committed) |
10:00 |
10:02:57 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
10:07:54 | | Quit boghog (Ping timeout: 260 seconds) |
10:09:43 | | Join n1s [0] (~quassel@rockbox/developer/n1s) |
10:10:35 | jhMikeS | I see. the remote stuff sucks up the IRAM on m5 but not on H100 |
10:10:52 | kugelp | how about an arch for in firmware as a place for arch-specific stuff that isn't native/hosted dependant? |
10:15:13 | kugelp | arch dir* |
10:15:13 | jhMikeS | could work. should it be limited to firmware? dsp has some optimized routines but they're all right in /apps along with dsp.c |
10:15:57 | | Quit Llorean (Read error: Connection reset by peer) |
10:17:07 | jhMikeS | do MIPS have good caches? |
10:18:50 | | Quit mc2739 (Read error: Connection reset by peer) |
10:20:09 | wodz | MIPS hasn't been profiled extensively I guess |
10:20:39 | *** | Saving seen data "./dancer.seen" |
10:21:42 | | Join TheLemonMan [0] (~lem0n@ppp-197-58.26-151.libero.it) |
10:22:35 | wodz | TheLemonMan: you seem to know something about MIPS archs |
10:23:23 | TheLemonMan | yep, but i know less than zero about ffts heh |
10:23:24 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
10:24:37 | | Quit Judas_PhD (Quit: This is a quitting message) |
10:24:43 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
10:24:50 | wodz | TheLemonMan: do you know how cache is performing on ingenics? |
10:25:50 | jhMikeS | IRAM is quite tight there. If I use it at all, what is more important, code or data? |
10:26:17 | jhMikeS | of course, data is big, code is small and loopy in this case |
10:26:34 | | Quit ack (Remote host closed the connection) |
10:26:36 | kugelp | jhMikeS: could have the same thing in apps |
10:27:58 | | Join ack [0] (~ack@mingbai.org) |
10:28:04 | kugelp | the pcm stuff is in firmware now |
10:28:07 | jhMikeS | On MIPS, it's 0x1f0 over the limit |
10:28:51 | pamaury | jhMikeS: congrat for your patch, hope it will work flawlessly :) |
10:29:31 | kugelp | I don't think it would be good to split dsp just to have optimization in firmware |
10:29:53 | jhMikeS | pamaury: thank you. and I share the latter sentiment as well :) |
10:30:13 | wodz | pamaury: can you point me out how usb drivers in rb works? |
10:30:40 | wodz | is there any documentation how to write usb driver? |
10:31:05 | kugelp | The Code |
10:31:11 | pamaury | wodz: sure, not really |
10:31:37 | pamaury | there are two different matters, both are very important: 1) usb detection 2) usb driver itself |
10:32:05 | wodz | usb detection is easy - the core sets the flag when usb connect occures |
10:33:12 | bertrik | I think there's also a separation in high-level more-or-less-generic "USB" code (e.g. the USB HID and MSC) and driver level USB code (to drive a specific USB controller) |
10:33:14 | TheLemonMan | wodz, what do you mean with how cache performs ? |
10:33:37 | wodz | see jhMikeS question |
10:34:04 | pamaury | of, the tricky part with usb detection is to make the whole machine work, it's a bit messy; for the usb driver |
10:34:12 | pamaury | you need to implement these functions: |
10:34:30 | pamaury | usb_drv_init -> one time init (once per connection); so basically enable the usb core |
10:34:45 | pamaury | (and boost if needed, very important on some !) |
10:34:53 | pamaury | usb_drv_exit -> the oppositze |
10:35:28 | pamaury | usb_drv_port_speed -> return the port speed, I don't remember the value but basically it's 0=full speed, 1=high speed or the converse |
10:35:42 | TheLemonMan | oh, usually the best combination is code in IRAM along with the most frequently used data |
10:36:20 | pamaury | usb_drv_request_endpoint -> reserve a endpoint; have a look at how other drivers to it; usually this is some administrative stuff + bit stuffing in the usb controller to set the type and max packet size |
10:36:24 | wodz | TheLemonMan: thats obvious the question is whats more important on ingenics as Iram is tight |
10:36:38 | pamaury | usb_drv_release_endpoint -> converse |
10:37:17 | wodz | pamaury: we reserve Control endpoint bulkin, bulkout |
10:37:23 | wodz | pamaury, something else? |
10:37:33 | pamaury | we don't reserve control |
10:37:35 | jhMikeS | I can get it to build if I take the mixer callback out of IRAM. all the loops are fairly small. there's probably junk in pcmbuf.c that is pointless to have in IRAM anyway as well. |
10:37:37 | pamaury | it's EP0, always |
10:37:57 | pamaury | it is never reserved, so don't alloc it to other drivers ;) |
10:38:09 | pamaury | we reserve bulk in/out, int in |
10:38:58 | pamaury | usb_drv_cancel_all_transfers -> kill all transfers; usually you need to set a bit for each endpoint and flush fifos. You should also call the completion handler with error status for everything |
10:39:17 | pamaury | usb_drv_recv -> setup a receive transfer; *non blocking* |
10:39:35 | pamaury | usb_drv_send setup a send transfer, *blocking* |
10:39:45 | pamaury | usb_drv_send_nonblocking -> "", *non blocking* |
10:40:12 | pamaury | usb_drv_set_test_mode -> set test mode, you can forget that for now, usually it's sufficient to bit copy the argument into some register of the controller |
10:41:41 | pamaury | usb_drv_set_address -> set the address (usually it's in a register); there is a problem here: some controller want the address to be set between control out and ack and some want to wait for the end of the transaction. In the first case, you need to write some code special code when getting setup packets and ignore this function (have a look at other drives) |
10:41:44 | | Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.) |
10:41:56 | pamaury | usb_drv_stall -> stall a endpoint; usually set a flag in the controller |
10:42:04 | pamaury | usb_drv_stalled -> ... |
10:42:12 | pamaury | and you are done ! |
10:42:14 | | Join max131 [0] (~c3cf0579@giant.haxx.se) |
10:42:14 | pamaury | :) |
10:42:17 | gevaerts | pamaury: does test mode actually work on any of our targets? |
10:42:25 | wodz | easy :-) |
10:42:59 | pamaury | gevaerts: it's implemented :) |
10:43:06 | gevaerts | Yes, I know that! :) |
10:43:08 | pamaury | I don't know if it actually works ;) |
10:43:21 | | Join [Saint] [0] (~Saint]@119.224.72.2) |
10:43:24 | gevaerts | I know I didn't get it to actually work on portalplayer |
10:43:24 | wodz | pamaury: which driver would you recommend as a support? |
10:43:28 | TheLemonMan | obiviously code would take more benefits by staying in iram |
10:45:26 | pamaury | wodz: target/arm/{usb-arc.c, usb-s3c6400x.c} and perhaps target/arm/as3525/usb-drv-as3525(v2).c |
10:45:38 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
10:46:31 | max131 | Has the AMSv2 USB code been merged in rockbox already? I've got a patched version running r29857 now on my FuzeV2, and i was wondering if i still need to do patching on the current code base. |
10:46:32 | jhMikeS | TheLemonMan: it has no I-cache? the code execution is far more coherent because of small loops than the data |
10:47:16 | wodz | jhMikeS: google says it has 16kB I-cache and 16kB d-cache |
10:47:29 | TheLemonMan | it has separate D/I-cache so coherency isn't assured |
10:47:37 | pamaury | the amsv2 code doesn't work reliably |
10:48:12 | pamaury | max131: which patch ? |
10:50:51 | max131 | if i remember well i applied both as3525v2-enable-usb.diff and as3525v2-usb.diff |
10:51:49 | max131 | never tried the usb-pio.diff though |
10:52:02 | jhMikeS | TheLemonMan: I meant that the cached code is used over and over in a loop while the data would miss more often since it's way larger than 16KB. The ARM targets with separate I/D cache don't need much or any IRAM assistance with mixing. |
10:53:37 | pamaury | the as3525v2-usb.diff is perhaps not necessary (it's a hacky workaround), the other one is needed to enable usb |
10:53:56 | | Quit wodz (Quit: Leaving) |
10:55:57 | TheLemonMan | if all the data is used into the looping code then it's a problem |
10:56:03 | max131 | @pamaury, when you say the amsv2 code doesn't work reliably, do you mean the stock rockbox code, without any patch applied? |
10:56:31 | n1s | max131: the patch just enables the usb code already in svn |
10:56:41 | pamaury | the stock have it disable but with the patches it's unreliable; it works for some, doesn't work for others |
10:56:44 | n1s | it doesn't work reliably on all players |
10:57:09 | max131 | ok, happy to hear that code is checked in in svn |
10:57:10 | TheLemonMan | but if just a small part is accessed really often it's better to cache that to avoid frequent misses |
10:57:13 | jhMikeS | meh, there's no room on MIPS to be picky anyway |
10:58:00 | max131 | and it seems i'm a lucky guy because USB is pretty stable on my FuzeV2 |
10:58:28 | jhMikeS | max131: me too :) |
10:59:17 | max131 | so is it in autoconf.h that i have to enable USB for the FuzeV2? |
11:00 |
11:00:00 | pamaury | no, the enable-usb.diff patch is the right way to enable usb |
11:00:21 | pamaury | sideral: ping |
11:02:45 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
11:03:17 | max131 | does enable-usb.diff apply cleanly onto r30099? I remember i had to try a couple of times when i did that on r29857, and still suffered from some failed hunks ... |
11:03:53 | | Quit einhirn (Client Quit) |
11:03:56 | pamaury | don't know, but it's a couple of lines so it's easy to apply it by hand |
11:04:21 | pamaury | (you only need to change the file related to your device) |
11:04:46 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
11:05:03 | max131 | alright, thanks for this info. If i find some time i'm gonna try that out this evening, as i'm not my dev-environment right now |
11:05:52 | TheLemonMan | pamaury, i wrote some code that hopefully will make the screen work, but when i send it the player discards the last packet |
11:06:05 | TheLemonMan | i tried padding the size to 0x40 and stuff like that but had no luck |
11:06:23 | TheLemonMan | is there something special i have to do with the elf ? |
11:07:47 | pamaury | not to my knowledge |
11:07:56 | pamaury | how to you it discards the last packet ? |
11:07:59 | pamaury | *do you |
11:10:23 | pamaury | *know |
11:12:50 | TheLemonMan | my tool hangs when sending the last one |
11:13:17 | TheLemonMan | but works well when sending the original nand loader |
11:15:32 | pamaury | if you don't find, try sending them to me, I'll have a look; I don't have an idea right now |
11:18:15 | | Quit max131 (Quit: CGI:IRC) |
11:20:43 | * | [Saint] declares that voice is *horrible* with svn head on Android... |
11:21:18 | TheLemonMan | libusb returns -7 :| |
11:21:40 | sideral | Hi pamaury! |
11:22:52 | jhMikeS | [Saint]: Meaning what exactly? |
11:24:30 | jhMikeS | I'd expect it could be acting much like the sim did initially |
11:24:37 | [Saint] | it's very choppy. |
11:24:50 | [Saint] | like it's cutting in/out many, many times a second |
11:25:25 | jhMikeS | sound like the same problem because it's not actually mixing at a steady rate |
11:25:31 | [Saint] | and that's not even with audio playing |
11:26:55 | jhMikeS | yep, that won't change it. it needs to be paced out in the main pcm callback |
11:29:00 | jhMikeS | voice decoding buffer latency is only about .06 seconds |
11:33:06 | jhMikeS | obviously whatever kugel uses has small buffers since he reported no negative issues to me with voice |
11:34:08 | pamaury | sideral: hi, are you still willing to send me your clip+ ? I forgot mine at my mother's home and won't have the opportunity to get it back before one month... |
11:34:24 | pamaury | that's now or never ! :) |
11:35:17 | pamaury | TheLemonMan: what is the error code associated with -7 ? |
11:37:46 | TheLemonMan | timeout error |
11:39:15 | CIA-14 | New commit by jethead71 (r30100): Do some adjustments to alleviate IRAM congestion on some targets from r30097. Include removing pointless IRAM declarations in pcmbuf.c because that ... |
11:39:49 | pamaury | TheLemonMan: did you try to send it with the windows tool ? |
11:40:12 | TheLemonMan | don't have a windows box |
11:40:31 | | Quit antil33t () |
11:42:52 | pamaury | and a VM ? |
11:43:29 | CIA-14 | r30100 build result: 3 errors, 0 warnings (jethead71 committed) |
11:43:43 | TheLemonMan | i havent had much luck with wms |
11:45:11 | jhMikeS | weird delta, like IRAM wasn't being measured right in the size table :\ |
11:45:51 | pamaury | TheLemonMan: so your code is never run ? |
11:46:01 | TheLemonMan | it doesnt even reach the player |
11:46:01 | sideral | pamaury: Yes, I'm still willing to do that. But will you be able to debug this with multiple hosts? |
11:46:36 | kugel | jhMikeS: why did you remove icode for so many targets? |
11:47:33 | pamaury | Yes, I will have the opportunity to temporary steal the computers of my housemate ;) |
11:47:50 | | Quit FOAD (Read error: Connection reset by peer) |
11:48:24 | | Join FOAD [0] (~dok@83.161.135.61) |
11:48:56 | jhMikeS | kugel: in pcmbuf.c I killed a bunch of it for everything. it's rather a waste. |
11:49:21 | | Quit FOAD (Read error: Connection reset by peer) |
11:49:31 | kugel | jhMikeS: I mean MIXER_CALLBACK_ICODE |
11:49:33 | | Join FOAD [0] (~dok@83.161.135.61) |
11:49:40 | sideral | pamaury: OK. I'll back it up hopefully tonight, so it could be in the mail tomorrow |
11:52:38 | jhMikeS | kugel: If the caching is good, I'd rather not waste it on that |
11:57:51 | jhMikeS | might have to take a hike from IRAM on m5 as well |
11:58:56 | pamaury | sideral: ok, thanks |
11:58:57 | jhMikeS | unless something else can get out of the way |
11:59:59 | amiconn | jhMikeS: IRAM is excluded from the delta table. It's only dram and code (with the latter contributing to the former, as we're not delta-ing rom builds) |
12:00 |
12:01:56 | pamaury | TheLemonMan: well, all your code except the last packet reaches the player :) |
12:02:56 | jhMikeS | amiconn: why is m5 so overfull? |
12:03:44 | | Quit bertrik (Read error: Connection timed out) |
12:03:58 | amiconn | Because you added too much? |
12:04:17 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
12:04:18 | | Quit bertrik (Changing host) |
12:04:18 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
12:04:34 | n1s | the greyscale cf's have (both) framebuffers in iram iirc |
12:05:03 | | Join mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de) |
12:05:56 | jhMikeS | n1s: well, so does H100, but apparently, it's much larger on iAudio models. |
12:05:56 | pamaury | TheLemonMan: how do you procude the sb file ? |
12:06:12 | TheLemonMan | i used the freescale tool |
12:06:16 | jhMikeS | had it to spare on H100 |
12:06:30 | amiconn | jhMikeS: M5 has greyscale main lcd (same resolution as H1x0) *and* greyscale remote (unlike the irivers) |
12:07:34 | pamaury | *produce |
12:08:21 | pamaury | TheLemonMan: perhaps try the one I wrote for rockbox ? It might be that the freescale one make some assumption... |
12:08:46 | TheLemonMan | does it take the same database format as the official one ? |
12:08:56 | pamaury | a subset of it |
12:09:03 | jhMikeS | and there's 2k of pcm frames now |
12:09:30 | pamaury | TheLemonMan: but you successfully sent custom code to your player, didn't you ? |
12:10:01 | TheLemonMan | not really, i never had working code on that |
12:10:58 | pamaury | and if you only send the init stage you extracted from the OF ? |
12:12:07 | TheLemonMan | nothing happens |
12:12:37 | pamaury | but it successfully send the code... |
12:13:16 | amiconn | jhMikeS: Btw, main lcd framebuffer is exactly the same size on both (0x140c bytes) |
12:16:00 | pamaury | TheLemonMan: does your custom code uses the ocram ? |
12:16:30 | TheLemonMan | yep |
12:16:42 | pamaury | I think the ROM has a limitation: it uses the upper part of the ocram for itself and leaves the lower part for the custom code |
12:17:30 | TheLemonMan | the official nand booter is rebased at 0 too so dont think it's a space limitation |
12:18:38 | pamaury | I mean, the ocram is 32kb (confirm ?), and the bootloader uses the higher 16kb so you shouldn't load more than 16kb to ocram at address 0 with the sb file |
12:18:56 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
12:19:06 | pamaury | just trying to help :) |
12:19:53 | TheLemonMan | yep, 32kb and mirrored at 0x8000 |
12:20:41 | *** | Saving seen data "./dancer.seen" |
12:23:11 | pamaury | I don't see what else could be wrong |
12:24:34 | jhMikeS | argh, where the heck could it come from. taking mixdown buffers out of IRAM would be about the worst thing to do there (shortening them is kinda bad too) |
12:30:43 | | Quit hobby16 (Ping timeout: 264 seconds) |
12:38:46 | | Quit Keripo (Quit: Leaving.) |
12:43:16 | n1s | jhMikeS: how much did your patch increase the iram usage? |
12:49:15 | n1s | amiconn: in lcd-m5.c:lcd_blit_mono is there a reason the buffers can't be on the stack? |
13:00 |
13:00:11 | jhMikeS | n1s: the principle increase is 2k for the mixdown double buffer, which can have a smaller size at the expense of more interrupts |
13:01:53 | n1s | there seems to be a *lot* of lcd code in iram i wonder how much that actually gains |
13:03:46 | n1s | looks like ~4.8k for all the lcd_* functions in icode |
13:12:24 | jhMikeS | test_fps ought to say |
13:13:18 | jhMikeS | data's definitely the killer there |
13:14:26 | * | Torne ponders what to actually do with this git repo with 7 roots and 134 heads now he's *got* it. :) |
13:15:11 | jhMikeS | I remember way back not gaining much with dsp code that just did small loops using icode |
13:16:33 | GodEater | 134 heads? |
13:16:53 | Torne | GodEater: Yup! Many of them are tags, though |
13:17:00 | GodEater | ah thank goodness |
13:17:15 | Torne | well okay there are still 33 non-tag heads. |
13:17:21 | Torne | the 7 roots is more interesting :) |
13:17:32 | | Join dfkt|n [0] (dfktn@unaffiliated/dfkt) |
13:18:03 | GodEater | what on earth have we done to manage that? |
13:18:13 | Torne | well, themes and translate are entirely seperate histories |
13:18:21 | Torne | so there's going to be at least three. |
13:18:27 | GodEater | www? |
13:18:33 | Torne | www is actually branched from inside trunk |
13:18:39 | Torne | since it used to be a subdirectory |
13:18:46 | n1s | jhMikeS: yeah, i think only pixelma has an m5 though |
13:18:48 | Torne | this means the root there is trunk/www, not www |
13:18:57 | Torne | and that history includes duplicate copies of all commits that touched trunk/www before the split. |
13:19:01 | Torne | which is fun. |
13:19:11 | Torne | as it means therea re multiple git commits with the same svn revision number :) |
13:19:24 | Torne | likewise for songdbj |
13:19:43 | Torne | and then the same thing happens a couple more times possibly by accident where people have sometimes branched only subtrees of trunk for rbutil/bootloaders/etc |
13:20:05 | Torne | some of this will go away when i push stuff to seperate repos, but the bootloaders/rbutil subtree branches are.. interesting. |
13:25:02 | jhMikeS | n1s: ok, then who cares if it works any more :P |
13:25:20 | n1s | i bet she does :) |
13:26:19 | jhMikeS | exactly |
13:29:44 | jhMikeS | of course I can only test what I have and infer from that if there's an impact |
13:32:35 | amiconn | n1s: If you can make sure that all plugins use it from the main thread *only*, they could be on stack. Otherwise they wouldn't be in iram |
13:33:17 | n1s | amiconn: ah, didn't think of plugins |
13:33:23 | amiconn | Oh, and you can't |
13:33:42 | amiconn | Greylib uses it, meaning that the isr uses whatever stack is currently active |
13:34:16 | amiconn | n1s: lcd_blit_* are specifically for plugin use. They're not used in the core at all |
13:34:41 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
13:34:55 | n1s | hmm |
13:35:05 | | Quit pamaury (Read error: Operation timed out) |
13:35:07 | amiconn | Hmm, actually greylib doesn't use it |
13:35:31 | amiconn | test_scanrate does though, also in an isr |
13:35:55 | | Join AlexandrosSchill [0] (~9bf52b4c@giant.haxx.se) |
13:36:12 | amiconn | chip8 and lua use it too (also video.rock but that's archos only) |
13:36:34 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
13:37:10 | n1s | amiconn: do you know what kind of impact moving some of the lcd code to dram would have? |
13:37:43 | AlexandrosSchill | Hi! I just registered in the wiki and I was wondering if I could be added to the WikiUsersGroup? |
13:43:11 | | Join max131 [0] (~c3cf0579@giant.haxx.se) |
13:43:25 | [Saint] | AlexandrosSchill: Assuming your real name is Alexandros Schill, it's done. |
13:43:35 | [Saint] | You can edit the wiki (don't break it) as you please. |
13:43:39 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
13:43:41 | [Saint] | ;) |
13:45:24 | | Quit n1s (Remote host closed the connection) |
13:46:24 | AlexandrosSchill | sorry, it is AlexandrosSchillings |
13:46:32 | AlexandrosSchill | irc truncated the name |
13:47:31 | kugel | Torne: I wonder why svn tags don't translate to git tags? |
13:47:42 | Torne | kugel: because svn tags are normal commits and thus can contain diffs |
13:47:52 | Torne | And quite a few of our old ones *do* contain diffs :) |
13:48:07 | AlexandrosSchill | Don't worry I won't mess around. I'll fix a few missing links that I found when I was researching putting rockbox on my fuzev2 |
13:48:22 | Torne | some because people were "naughty" and some because the git conversion handles tagging only a subdirectory interestingly |
13:48:27 | kugel | Torne: oh, that sucks balls |
13:48:36 | Torne | kugel: I'm going to do magic to fix it where possible. |
13:48:44 | Torne | The actual release tags for 3.0+ are fine |
13:48:46 | Torne | they can become real git tags. |
13:49:10 | | Quit max131 (Quit: CGI:IRC) |
13:49:20 | kugel | Torne: can we drop all tags except releases and bootloader tags? or do those contain tags too? |
13:49:23 | kugel | diffs* |
13:49:29 | Torne | Some of them |
13:49:35 | Torne | Different things were done differently. |
13:49:39 | Torne | it's not a problem, seriously. |
13:49:53 | Torne | The things that have diffs can also become git tags, the branch is not required |
13:50:03 | Torne | the existence of the tag keeps the commit reachable even if no branch head points to it |
13:50:16 | Torne | it just looks slightly odd in a history graph, but only if youa ctually bother to look back that far. |
13:51:12 | Torne | I'm probably going to keep all the old tags and branches just for historical reference but will put them in refs/oldheads or similar |
13:51:26 | Torne | which will mean git clone won't bother to fetch them by default and thus you won't see them unless you explicitly pull them |
13:51:47 | Torne | (like gerrit's review branches and so on) |
13:51:57 | [Saint] | AlexandrosSchill: Ok, AlexandrosSchillings added, sorry for the confusion. |
13:52:03 | Torne | even with all that history included the repo is only 140MB so screw it. |
13:52:10 | [Saint] | I was joking about breaking the wiki, by the way. Welcome aboard. |
13:52:12 | Torne | git delta compression is excellent ;) |
13:52:32 | kugel | I only worry about a too large git branch tab completion :) |
13:52:50 | Torne | kugel: Yeah, that's reasonable |
13:53:56 | Torne | the default refspec for a fresh clone fetches refs/heads/* to refs/remotes/origin/* so anything outside heads won't appear in your tab completion as your local repo won't know about it |
13:54:58 | AlexandrosSchill | Nah, my bad. I should have noticed |
13:55:29 | AlexandrosSchill | Works fine. Thanks! |
13:55:39 | [Saint] | No worries, happy to help. |
13:56:12 | kugel | Torne: can stuff be moved to oldrefs afterwads? |
13:56:23 | Torne | kugel: yup. |
13:56:26 | kugel | i.e. move v3_0 to oldrefs in a few years? |
13:56:48 | Torne | it won't actually disappear in people's existing copies unless they git fetch −−prune |
13:56:53 | Torne | but it won't appear in new copies |
13:57:01 | kugel | that's cool |
13:57:11 | kugel | git remote show shows prunable refs |
14:00 |
14:15:13 | | Quit knittl (Ping timeout: 240 seconds) |
14:15:33 | | Quit Farthen (Ping timeout: 250 seconds) |
14:16:11 | | Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) |
14:16:38 | | Join crwll [0] (~crwlll@dsl-jklbrasgw1-fe8edf00-29.dhcp.inet.fi) |
14:16:59 | jhMikeS | lol...I actually measure a small speed increase if I take bitmap routines out of iram on h120 |
14:17:27 | | Quit AlexandrosSchill (Quit: CGI:IRC) |
14:18:09 | | Quit crwl (Ping timeout: 250 seconds) |
14:20:41 | amiconn | jhMikeS, n1s: Since coldfire has icache, having code in iram isn't that important. It can still be useful for code that is used a lot |
14:20:46 | *** | Saving seen data "./dancer.seen" |
14:21:45 | amiconn | The icache is somewhat nasty. Because it's direct mapped,relative location of functions in dram matters. This is probably what you're seeing |
14:22:58 | jhMikeS | It's only about 11 fps (4621/4611), just substituting regular lcd_bitmap functions for the greylib calls |
14:23:46 | jhMikeS | s/4611/4610/ |
14:41:59 | jhMikeS | If those bmp functions are moved to dram, then there's some iram to spare without much to worry about for speed. I just wonder, is it really critical in that sense on any other target to have them as icode? |
14:46:17 | amiconn | Substituting what, where? |
14:47:41 | jhMikeS | calling rb->lcd_bitmap instead of grey_ub_gray_bitmap since test_fps doesn't do the framebuffer functions by default |
14:48:19 | amiconn | Use test_gfx |
14:49:10 | jhMikeS | heh...forgot about that one |
14:49:11 | amiconn | Hmm, that one doesn't do native bitmaps though |
14:49:25 | jhMikeS | oh |
14:49:27 | amiconn | But it does text, i.e. mono bitmaps |
14:50:52 | amiconn | test_fps() is probably a bad example, because it uses large bitmaps, where most time is spent in lowlevel stuff like memcpy() |
14:54:23 | jhMikeS | what do you mean? I just see small loops calling grey_ub_gray_bitmap |
15:00 |
15:00:04 | amiconn | The bitmaps are large though (fullscreen and 1/4 screen) |
15:02:39 | | Quit esperegu (Remote host closed the connection) |
15:04:51 | | Join Thra11_ [0] (~thrall@87.115.145.253) |
15:07:13 | | Quit Thra11 (Ping timeout: 240 seconds) |
15:11:17 | jhMikeS | I guess for the font rendering it does help |
15:11:38 | Torne | Do we want git tags to be v3_0 like the svn ones, or would it be nicer to call them v3.0 since git doesn't care what characters are in them? |
15:11:48 | Torne | using the dot would make git describe output look nicer ;) |
15:11:50 | | Quit krazykit (Ping timeout: 244 seconds) |
15:12:27 | kugel | jhMikeS: test_gfx checks font rendering |
15:12:33 | kugel | and other lcd_* functions |
15:13:49 | jhMikeS | that's why I was using it...to judge the impact, which on h100 is about -18% if moving to dram |
15:17:07 | | Quit bertrik (Read error: Connection timed out) |
15:17:36 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
15:17:36 | | Quit bertrik (Changing host) |
15:17:36 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
15:22:36 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
15:25:58 | | Quit Thra11_ (Ping timeout: 255 seconds) |
15:29:28 | jhMikeS | this went on longer than I though. I'll just get the red off the table for the moment. I've got a couple really important things to take care of in RL. |
15:32:10 | Torne | 97 branch heads, getting somewhere :) |
15:34:42 | kugel | Torne: what to do about the branches which are clearly not branches? dast,Rockbox, ...? |
15:34:49 | Torne | kugel: I've blown them away, they have no content |
15:35:07 | kugel | good :) |
15:35:15 | Torne | they are an artifact of cvs branching/tagging that was copied over by cvs2svn |
15:35:34 | Torne | i'm keeping anything with an actual diff in it, but not things which just have file removals because of partial tree cvs branch/tags |
15:42:20 | | Join Thra11_ [0] (~thrall@87.115.145.253) |
15:43:34 | | Join promyloph [0] (~foo@unaffiliated/promyloph) |
15:43:49 | CIA-14 | New commit by jethead71 (r30101): Get M5 building again by moving the downmix buffer out of IRAM for now. Everything should still work. It doesn't have any apparently measurable effect ... |
15:44:05 | amiconn | jhMikeS: What about changing the iram split for MCF5250 back to what it used to be? |
15:44:22 | amiconn | (provided codecs don't actually use up everything) |
15:46:36 | jhMikeS | I could explore that later. m5 is mc5249 though |
15:47:32 | jhMikeS | unless that's wrong with IRAM size only being 0xc000 |
15:47:52 | jhMikeS | wait, erm |
15:47:54 | CIA-14 | r30101 build result: All green |
15:48:06 | jhMikeS | x5 also lists as that |
15:48:35 | | Join MethoS- [0] (~clemens@134.102.106.250) |
15:48:58 | jhMikeS | ok, yeah, lcd_framebuffer is in COMMON |
15:51:51 | amiconn | Both X5 and M5 are MCF5250. M3 and the irivers are MCF5249 |
15:52:54 | amiconn | The former has 128KB IRAM, the latter only has 96KB. Atm we're splitting it 48/80 for MCF5250; it used to be 64/64 |
15:53:43 | amiconn | And of course the X5 framebuffer isn't in iram - it's way larger than the M5 (and H1x0) framebuffer |
15:54:30 | jhMikeS | the mixer buffer *must* be DMA compatible though and as I remember the second bank isn't |
15:55:53 | amiconn | Correct, but not a problem |
15:56:30 | amiconn | The first (== dma capable) block is 64KB for both MCF5249 and MCF5250 |
16:00 |
16:01:19 | | Quit Thra11_ (Ping timeout: 264 seconds) |
16:07:06 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
16:17:06 | | Quit Judas_PhD (Quit: This is a quitting message) |
16:20:49 | *** | Saving seen data "./dancer.seen" |
16:24:36 | | Join elcan [0] (user36@pr0.us) |
16:28:24 | jhMikeS | I had a couple minute to check it out while getting ready: if I move the boundary by 2k, all is well. If I move it by 4k, cook.codec fails. |
16:29:52 | Torne | 47 branch heads, and now i need to do some work :) |
16:36:11 | | Join krazykit [0] (~krazykit@206.183.182.189) |
16:36:54 | jhMikeS | too bad the remainder after the core build can't just get fed over to the codec/plugin portion :) |
16:38:05 | pamaury | what could cause a eMMC (or SD) card to NOT work at high speed ? (but the switch itself workà |
16:41:40 | Slasheri | kugel: what was the reason to use dot and dotdot instead of direct "." and ".."? |
16:42:28 | | Join evilnick [0] (~evilnick@ool-18bee3a9.dyn.optonline.net) |
16:42:28 | | Quit evilnick (Changing host) |
16:42:28 | | Join evilnick [0] (~evilnick@rockbox/staff/evilnick) |
16:43:57 | Slasheri | kugel: now you have to call everywhere generate_dot_d_names() and make code harder to read for no apparent reason |
16:43:59 | | Quit elcan (Quit: Changing server) |
16:45:36 | | Join patheticbliss [0] (~calvin@75-134-134-13.dhcp.roch.mn.charter.com) |
16:47:23 | pamaury | urg, that's weird, you can't change the timings without affecting the timeout on the imx ssp, that explains *lots* of things |
16:55:03 | kugel | Slasheri: "." and ".." are string literals and not in the dircache allocated memory |
16:55:42 | kugel | it's simpler to put them into the allocation than to add lots of complexity into the relocation code |
16:55:51 | kugel | I thought I added comments about this? |
17:00 |
17:02:28 | Slasheri | ah, yes. That's a problem when loading dircache dump indeed |
17:02:47 | Slasheri | i am just trying to fix the re-building issue with dircache |
17:03:39 | kugel | kugel: I can have a look later, but first I'm going to set up my new shiny ssd :) |
17:07:08 | | Quit factor (Ping timeout: 260 seconds) |
17:15:03 | pamaury | gevaerts: what might make the arc controller don't work with packets >32 bytes ? My fuze+ is already running at top speed (cpu + ahb) so I can't see anything |
17:17:04 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
17:22:37 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
17:31:06 | | Quit bertrik (Read error: Connection timed out) |
17:31:48 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
17:31:49 | | Quit bertrik (Changing host) |
17:31:49 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
17:32:53 | | Quit mikroflops (Ping timeout: 244 seconds) |
17:34:45 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
17:45:27 | | Quit [Saint] (Ping timeout: 252 seconds) |
17:55:12 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
17:56:33 | | Quit petur (Remote host closed the connection) |
17:59:23 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
18:00 |
18:13:12 | | Quit sideral (Quit: Leaving.) |
18:16:42 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
18:20:53 | *** | Saving seen data "./dancer.seen" |
18:28:01 | | Join [Saint] [0] (~st.lasciv@119.224.72.2) |
18:29:16 | | Quit [Saint] (Client Quit) |
18:30:25 | pamaury | "Writes must be DWORD writes" but the OF does BYTE writes... |
18:30:29 | | Join [Saint] [0] (~st.lasciv@119.224.72.2) |
18:30:59 | | Quit [Saint] (Disconnected by services) |
18:30:59 | | Join S_a_i_n_t [0] (~st.lasciv@119.224.72.2) |
18:31:02 | | Quit S_a_i_n_t (Remote host closed the connection) |
18:31:12 | | Join [Saint] [0] (~st.lasciv@119.224.72.2) |
18:31:23 | | Nick [Saint] is now known as S_a_i_n_t (~st.lasciv@119.224.72.2) |
18:31:28 | | Nick S_a_i_n_t is now known as [Saint] (~st.lasciv@119.224.72.2) |
18:31:46 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
18:31:49 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
18:53:39 | | Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) |
18:59:27 | | Quit bertrik (Read error: Connection timed out) |
18:59:54 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
18:59:55 | | Quit bertrik (Changing host) |
18:59:55 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
19:00 |
19:00:24 | | Quit TheLemonMan (Quit: Ex-Chat) |
19:01:42 | | Quit bluebrother (Disconnected by services) |
19:01:43 | | Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) |
19:04:08 | | Quit fs-bluebot (Ping timeout: 250 seconds) |
19:05:18 | | Join fs-bluebot [0] (~fs-bluebo@g224238179.adsl.alicedsl.de) |
19:06:12 | | Quit promyloph (Quit: WeeChat 0.3.5) |
19:06:55 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
19:10:47 | pamaury | what is the typical read speed of the internal flash in our various players ? |
19:21:08 | | Quit liar (Ping timeout: 258 seconds) |
19:22:39 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
19:23:24 | | Quit sideral (Remote host closed the connection) |
19:25:07 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
19:26:17 | | Join Thra11_ [0] (~thrall@87.115.145.253) |
19:28:10 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
19:31:33 | | Join Horscht [0] (~Horscht@p5DD5741B.dip.t-dialin.net) |
19:31:34 | | Quit Horscht (Changing host) |
19:31:34 | | Join Horscht [0] (~Horscht@xbmc/user/horscht) |
19:33:14 | | Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) |
19:33:39 | | Quit sideral (Remote host closed the connection) |
19:34:13 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
19:34:38 | wodz | pamaury: http://www.rockbox.org/wiki/DiskSpeed has a few entries for flash targets |
19:39:06 | | Quit bertrik (Read error: Connection timed out) |
19:39:47 | | Quit thomasjfox (Remote host closed the connection) |
19:39:59 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
19:39:59 | | Quit bertrik (Changing host) |
19:39:59 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
19:43:54 | | Quit sideral (Remote host closed the connection) |
19:44:07 | | Quit GeekShadow (Quit: The cake is a lie !) |
19:45:37 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
19:46:08 | | Join Transformer [0] (~Transform@ool-4a59e397.dyn.optonline.net) |
19:47:35 | bertrik | pamaury, AMSv2 (clip+) is quite slow, 3MB/s or so IIRC |
19:47:40 | | Part Transformer |
19:48:05 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
19:57:04 | | Join tchan1 [0] (~tchan@c-69-243-144-187.hsd1.il.comcast.net) |
19:57:27 | | Quit tchan (Disconnected by services) |
19:57:34 | | Nick tchan1 is now known as tchan (~tchan@c-69-243-144-187.hsd1.il.comcast.net) |
19:57:45 | | Quit tchan (Changing host) |
19:57:45 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
19:59:02 | pamaury | the fuze+ seems to sustain 21.5Mib/s through usb with custom code |
20:00 |
20:02:02 | | Join Jerom [0] (~jerome@79.132.36.219) |
20:20:55 | *** | Saving seen data "./dancer.seen" |
20:21:15 | | Quit Jerom (Quit: Leaving.) |
20:21:58 | | Join smk [0] (~smk@49.203.175.83) |
20:23:31 | | Part smk |
20:23:35 | | Join Jerom [0] (~jerome@79.132.36.219) |
20:23:49 | wodz | pamaury: I am trying to understand usb_drv_request_endpoint() and I can't. I mean does one setup particular endpoint to act as IN/OUT BULK/INT/CONTROL ? |
20:24:52 | pamaury | each driver calls usb_drv_requesr_endpoint to configure a endpoint; it is the driver responsability to try to find one free which can handle this particular type/direction |
20:25:57 | | Quit Jerom (Client Quit) |
20:26:04 | | Quit ReimuHakurei (Quit: If I use this, I will disappear, and Shana-tan will remain...) |
20:26:17 | | Join ReimuHakurei [0] (~reimu@74.112.212.15) |
20:27:10 | wodz | so basicaly I have to map requested type|dir to physical endpoint? |
20:28:09 | pamaury | there can be several request with the same parameters |
20:28:15 | pamaury | to request several endpoints |
20:31:01 | wodz | hmm I am slowly starting to understand |
20:31:37 | pamaury | let's take an example: you device has 3 endpoint, each endpoint can handle any type and is bidirectional |
20:31:58 | wodz | mine has 16 endpoints |
20:32:02 | pamaury | is someone request a bulk ep IN, you will configure EP1IN as bulk |
20:32:19 | pamaury | then if someone request a int ep OUT, you will configure EP2OUT as int |
20:32:38 | wodz | ha here is the trick - rk27xx has predefined endpoints |
20:32:42 | pamaury | finally, if someone request a bulk ep OUT, you can configure EP1OUT as bulk because EP1 is bidirectional |
20:33:06 | pamaury | wait, I'll have a look a the rk27xx datasheet |
20:33:12 | wodz | I can't switch BULK1 into something else |
20:34:29 | pamaury | indeed, in your case you have unidirectional endpoints |
20:36:47 | pamaury | EP1=bulk out,EP2=bulk in,EP3=int in, EP4=bulk out,EP5=bulk in,EP6=int in, ... |
20:37:46 | pamaury | so you only need to keep a map of boolean saying for each endpoint if it used or not. when requested for a endpoint, you look for the first endpoint of that type which is free and select it |
20:39:05 | * | amiconn should probably try to cut down the coldfire memcpy/memmove asm once more |
20:39:17 | amiconn | It's a monster... |
20:39:59 | amiconn | There is an idea that might work... just last time I tried to implement it I couldn't get my head around it |
20:41:05 | | Join mikroflops [0] (~yogurt@h-34-156.A238.priv.bahnhof.se) |
20:41:36 | wodz | amiconn: can't we use spare DMA channel for larger transfers? |
20:41:50 | amiconn | nope |
20:41:59 | wodz | why? |
20:42:15 | amiconn | DMA with auto-align is broken, and without it it's slower than using the cpu |
20:42:39 | wodz | broken i which way? |
20:43:06 | wodz | I recall we set aa mode in pcm driver |
20:43:29 | amiconn | It transfers garbage if enabled |
20:44:06 | wodz | so why we use this in pcm transfers? |
20:44:19 | amiconn | Auto-align? |
20:44:22 | amiconn | Afaik we don't |
20:44:32 | wodz | hmm pcm transfers are 4byte aligned I guess |
20:44:51 | wodz | DCR0 = DMA_INT | DMA_EEXT | DMA_CS | DMA_AA | DMA_SINC | DMA_SSIZE(DMA_SIZE_LINE) | DMA_START; |
20:44:58 | wodz | so I guess we use AA |
20:45:07 | amiconn | There are further restrictions. (1) memcpy/memmove might be called in an isr, potentially interrupting another memcpy/memmove. We'd have to protect from this and resort to using the cpu if it happens -> more complexity |
20:45:32 | rudi_s | Hi. http://www.rockbox.org/wiki/MajorChanges still lists changes since 3.8 (SVN), maybe this could get updated. Thanks for the new release. |
20:45:41 | amiconn | (2) Iirc DMA can only copy forward -> it can't be used for memove if the kind of overlap demands backwards copying |
20:45:59 | amiconn | (3) There are memory blocks (namely the second iram bank) which aren't dma capable |
20:46:53 | amiconn | wodz: It may be that auto-align works in (dma capable) iram, but when I tried it with dram (for H300 lcd) it didn't work |
20:48:12 | wodz | the fact that pcm samples are 4bytes alligned may be the reason it just work |
20:49:06 | amiconn | It would only be useful if dma would actually be faster, because we'd have to busy-poll for completion |
20:49:50 | amiconn | Usually we'd set up an isr for signalling completion and then yield(), but we can't do those things in stuff as low-level as memcpy |
20:50:10 | amiconn | It might be called before the threading system is set up, or with interrupts disabled etc... |
20:51:13 | wodz | At least in my tests on mpios dma was faster than somehow optimized writes to lcd. But other problems with DMA are predominant here |
20:51:41 | wodz | anyway memcpy/memmove *are* the monsters :-) |
20:51:44 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
20:53:47 | | Quit bertrik (Read error: Connection timed out) |
20:54:03 | amiconn | On H300 dma is also faster for the lcd, but the frramebuffer is suitably aligned |
20:54:13 | amiconn | memcpy has to cope with any alignment |
20:54:38 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
20:54:38 | | Quit bertrik (Changing host) |
20:54:38 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
20:56:24 | wodz | interrupt ep is always in? |
20:56:44 | gevaerts | no |
20:57:01 | gevaerts | Most uses probably are though |
20:57:15 | wodz | hmm so looks like rk27xx has no out interrupt endpoint |
20:58:05 | gevaerts | In fact, I can't really think of anything more or less common that actually uses interrupt out |
20:58:51 | | Join benedikt93_ [0] (~benedikt9@p5B0C524A.dip.t-dialin.net) |
20:59:47 | | Nick benedikt93_ is now known as benedikt93 (~benedikt9@p5B0C524A.dip.t-dialin.net) |
21:00 |
21:00:03 | | Quit benedikt93 (Changing host) |
21:00:03 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
21:02:41 | jhMikeS | Is there possibly an objection to IRAM splits between core and codec that are smaller grained than 0x1000? |
21:05:43 | amiconn | Not from me. Just keep in mind that you need to bum the codec and plugin api versions (including minimum version) when changing iram split |
21:06:19 | jhMikeS | oh, definitely. they won't link at the correct address. |
21:06:36 | jhMikeS | or currently be linked rather |
21:06:36 | amiconn | Actually this isn't necessary when moving the boundary down, but it definitely is when moving it up |
21:07:10 | jhMikeS | Well, I plan so far to move it up by 0x800 |
21:07:12 | amiconn | The codecs and plugins would load and run, but they would overwrite part of core iram |
21:07:25 | jhMikeS | which is bad? :) |
21:07:42 | amiconn | You might wait whether we can free some iram elsewhere |
21:07:49 | amiconn | *might want to |
21:08:37 | jhMikeS | Sure, np. It still works anyway for what it has to do right now. Though, from where would it come? |
21:08:55 | amiconn | icode, probably |
21:09:16 | amiconn | E.g. the monster I mentioned ~half an hour ago |
21:09:27 | jhMikeS | ah, the memcpy/move monster |
21:13:15 | jhMikeS | it'll sure get used alot now unless I implement a cut-down specialty version like I did for arm, but for arm it's simple |
21:26:25 | | Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) |
21:31:42 | | Quit dfkt|n () |
21:31:46 | pamaury | gevaerts: an interrupt out would be really similar to a control out no ? |
21:32:01 | pamaury | (class specific, interface) |
21:32:24 | * | jhMikeS wonders why some of his files are missing props when he has svn-auto-props on |
21:32:58 | gevaerts | pamaury: I can't remember the timing constraints for control right now |
21:33:29 | jhMikeS | it seems like they were files that were in one place but got "svn mv"ed before committing |
21:35:11 | | Join dfkt|n [0] (dfktn@chello062178002170.1.11.univie.teleweb.at) |
21:35:11 | | Quit dfkt|n (Changing host) |
21:35:12 | | Join dfkt|n [0] (dfktn@unaffiliated/dfkt) |
21:35:23 | Torne | jhMikeS: well fortunately props will go away soonish ;) |
21:37:44 | wodz | pamaury: should usb_drv_request_endpoint() enable interrupt from requested endpoint or such configuration is in other place? |
21:39:17 | pamaury | it should enable it |
21:39:20 | pamaury | iirc |
21:39:31 | jhMikeS | Torne: whee...props then! :) |
21:40:16 | Torne | jhMikeS: well technically git still tracks the executable bit, so people might screw that up |
21:40:23 | Torne | jhMikeS: but that's the only metadata you can break ;) |
21:41:19 | gevaerts | wodz: the important bit is that you get the interrupts :) I don't think it matters much whether you enable them from usb_drv_request_endpoint() or the controller init |
21:41:32 | jhMikeS | it's happened with SVN plenty of times already |
21:42:38 | | Quit bertrik (Read error: Connection timed out) |
21:43:12 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
21:43:13 | | Quit bertrik (Changing host) |
21:43:13 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
21:44:51 | Torne | jhMikeS: git also has the cunning trick of detecting when it's on a crappy filesystem that doesn't have that kind of thing and then ignoring changes to the bit, though |
21:45:11 | | Quit dfkt|n () |
21:45:28 | Torne | jhMikeS: people on unixlike systems rarely make things executable by accident :) |
21:47:05 | jhMikeS | Torne: I never did it, I don't know how they got that way, but I know some non-executables were set as such. There were commits fixing that here and there. |
21:47:15 | | Join dfkt|n [0] (dfktn@chello062178002170.1.11.univie.teleweb.at) |
21:47:15 | | Quit dfkt|n (Changing host) |
21:47:15 | | Join dfkt|n [0] (dfktn@unaffiliated/dfkt) |
21:48:39 | Torne | jhMikeS: I recently fixed them all in svn :) |
21:48:59 | Torne | and it generally happens because people use windows for some/all of their workflow. |
21:49:07 | wodz | hmm interesting - address bits are marked as read only in datasheet |
21:49:30 | jhMikeS | oh, recent ones? I'd seen it some time way back. |
21:50:13 | Torne | i was searching the repo for all our usage of svn properties, so i spotted all the svn:executables that didn't belong :) |
21:51:28 | pamaury | wodz: either it's wrong or the device automatically set it on set address |
21:57:12 | wodz | pamaury: looks like the letter - OF doesn't write to this bits |
21:58:54 | pamaury | you will soon see if it the case or not :) |
22:00 |
22:01:58 | | Quit dfkt|n () |
22:03:25 | | Join dfkt|n [0] (~dfkt@unaffiliated/dfkt) |
22:04:42 | | Quit evilnick (Quit: Leaving) |
22:05:21 | Slasheri | kugel: btw, i think i have locally fixed the dircache issue but now debugging a possible tagcache problem |
22:06:30 | kugel | did I introduce that also? |
22:06:38 | wodz | pamaury: how are control transfers treated? |
22:07:07 | Slasheri | kugel: i have no idea yet |
22:07:13 | | Join T44 [0] (Topy44@f049145005.adsl.alicedsl.de) |
22:07:19 | | Join factor [0] (~factor@74.197.205.204) |
22:07:33 | pamaury | wodz: just like other transfers |
22:07:35 | pamaury | with ep=0 |
22:07:43 | pamaury | (for both direction) |
22:08:51 | wodz | but _request_endpoint() is not called prior to this right? |
22:09:18 | pamaury | no |
22:09:29 | pamaury | EP0 is special and can't be requested |
22:10:57 | | Quit Topy44 (Ping timeout: 255 seconds) |
22:18:19 | | Join Thra11__ [0] (~thrall@87.112.167.192) |
22:20:56 | *** | Saving seen data "./dancer.seen" |
22:21:27 | | Quit Thra11_ (Ping timeout: 276 seconds) |
22:25:24 | | Quit dfkt|n () |
22:29:45 | | Join domonoky1 [0] (~Domonoky@agsb-5d871776.pool.mediaWays.net) |
22:30:00 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
22:31:12 | | Quit domonoky (Ping timeout: 255 seconds) |
22:48:36 | | Quit ender` (Quit: My computer NEVER cras) |
22:50:01 | jhMikeS | what's the most proper way to sleep a thread for a certain number of milliseconds on android that will always work? |
22:50:55 | jhMikeS | pthread_delay_np? |
22:52:55 | | Quit Thra11__ (Read error: Operation timed out) |
22:54:42 | jhMikeS | anything suffixed _np I'd guess means "nonportable" (if I get the pattern) |
22:54:57 | jhMikeS | hmm |
22:56:30 | | Join TheLemonMan [0] (~lem0n@ppp-197-58.26-151.libero.it) |
23:00 |
23:07:54 | | Join Thra11__ [0] (~thrall@46.208.29.214) |
23:12:25 | | Join Thra11_ [0] (~thrall@24.60.125.91.rb3.adsl.brightview.com) |
23:14:18 | pamaury | the partition tables in the fuze+ make no fucking sense :( |
23:14:41 | pamaury | it's just...wrong, nothing matches |
23:16:03 | | Quit Thra11__ (Ping timeout: 276 seconds) |
23:18:02 | pamaury | it seems the real fat partition uses 2048 sector size but how the hell can you figure that out before find it !! |
23:18:09 | pamaury | and 2048 sector size is a mess :( |
23:21:04 | pamaury | does our fat code handles physical sector size != logical size or not ? |
23:21:28 | gevaerts | good question |
23:21:30 | gevaerts | I suspect not |
23:22:01 | pamaury | I suspect the same |
23:22:23 | pamaury | but on the other hand, 2048 sector size is wrong on this device, mmc at high speed has 512 sector size |
23:22:46 | gevaerts | Maybe a pass-through translation storage driver? |
23:22:48 | pamaury | and 2048 sector size doesn't seem to match the main partition table |
23:23:31 | | Join Thra11__ [0] (~thrall@87.112.139.71) |
23:23:54 | | Nick Thra11__ is now known as Thra11 (~thrall@87.112.139.71) |
23:24:20 | pamaury | actual the situation is this: |
23:24:20 | pamaury | 1) main partition table has 4 entry: 2 are strange partition, 1 is a boot partition, 1 looks like an logical one (but not reported as this) => 2048 sector size don't match LBA !! |
23:24:20 | pamaury | 2) the logical one has one entry which point to this fat partition => 2048 sector size don't match LBA !! |
23:24:36 | | Quit Thra11_ (Disconnected by services) |
23:27:47 | wodz | Can you read real data from this eMMC? Maybe there is some other abstract layer - something like FTL? |
23:28:10 | wodz | ... or data are crypted |
23:28:20 | * | jhMikeS will just wait for someone more informed in android domain to come up with a way to clock the pcm callbacks at a steady pace :) |
23:28:47 | pamaury | no, it's eMMC so there is no FTL (it's hidden) and it's not crypted either and the ROM is able to boot from it through the MBR !! |
23:30:13 | wodz | that doesn't mean that this MBR is not mangled somehow |
23:30:42 | pamaury | it's fully documented in the imx doc :-/ |
23:31:36 | wodz | data layout is documented in imx doc? |
23:32:26 | pamaury | the mbr indeed contains a sigmatel boot entry but the lba doesn't point to the actually bootloader, there is a 0x880 offset ot it |
23:32:49 | pamaury | mostly zero except for last part which contains a few 0xff so it's unused |
23:33:19 | pamaury | I must be missing something :D |
23:33:36 | | Join evilnick [0] (~evilnick@ool-18bee3a9.dyn.optonline.net) |
23:33:36 | | Quit evilnick (Changing host) |
23:33:36 | | Join evilnick [0] (~evilnick@rockbox/staff/evilnick) |
23:34:17 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
23:37:52 | wodz | wow, if I turn off usb clock and read udc register I get Data abort |
23:39:54 | | Quit stripwax (Quit: http://miranda-im.org) |
23:40:33 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
23:44:51 | sideral | Which target's Rockbox keymap is considered the most generic one (with the fewest deviations from the "Rockbox standard")? |
23:45:21 | pamaury | hum, several READ_SINGLE_BLOCK doesn't yield the same result as READ_MULTIPLE_BLOCK |
23:45:56 | wodz | sideral: non |
23:46:55 | sideral | wodz: Interesting :) I remember people saying the intra-Rockbox keymap consistency is valued higher than adhering to any other standard, such as the OF's |
23:48:50 | wodz | sideral: Go figure yourself :-) Basic things are rather consistent but every keymap I studied had some quirks |
23:49:46 | sideral | :) That's what I'm running into right now, switching from a Clip+ to a Fuze. |
23:49:56 | | Quit domonoky1 (Read error: Connection reset by peer) |
23:50:10 | sideral | I guess I'll have to make them all adhere to the sideral standard |
23:50:35 | wodz | many targets have weird constraints which combos are allowed |
23:52:07 | wodz | and keymap syntax is not that easy to follow AND you cannot test it reliably in simulator |
23:53:54 | wodz | And the last - almost every plugin has its distinct keymap. This is real pain to get this all consistent. I failed with MPIOs. |
23:55:52 | | Quit Thra11 (Ping timeout: 240 seconds) |
23:55:59 | | Quit evilnick (Quit: Leaving) |
23:57:10 | sideral | thanks for your comments, wodz. Strangely, this eases my task at hand, allowing me to not care ;) |
23:58:33 | wodz | did I mentioned that keymap changes in more popular targets leads usually to hot discussions? :-) |