00:00:11 | | Quit rasher ("leaving") |
00:00:26 | saratoga | plus 80MHz for GUI seems excessive |
00:00:30 | | Nick rasher_ is now known as rasher (n=rasher@rockbox/developer/rasher) |
00:00:45 | saratoga | 45MHz would do just as well but use 11mA less current |
00:00:46 | amiconn | Not if we unboost very quickly again |
00:01:05 | amiconn | But there's another important point to consider: the i.MX 31 |
00:01:22 | Zagor | saratoga: I think using button timin feels a bit backwards. with "free" boosting, simply boost heavy things. 9 times out of 10, the idle state simply doesn't do many heavy things |
00:02:12 | saratoga | Zagor: if the buttons are pressed then someone is probably looking at the screen though, so things like WPS updates should happen as fast as possible too |
00:02:51 | saratoga | i was thinking change the normal CPU clock to maybe 40 or 45MHz and leave it there for 5-10 seconds |
00:02:53 | amiconn | Hmm, in fact there's another thing: I don't know whether we need to do the core sync magic when using the divider for boosting. Then it won't be all that free... |
00:02:57 | Zagor | yeah but we already have the backligt/display timeout for that. idle = turned off display = much less heavy work |
00:03:23 | saratoga | Zagor: its been discussed using that logic too |
00:03:24 | amiconn | _jhMikeS_ might know... |
00:03:48 | saratoga | I orginally proposed tieing clock speed to the LCD time out, but people thought that was clumsy as well |
00:03:54 | Zagor | saratoga: leaving it at heightened speed for several seconds doesn't sound very economic |
00:04:17 | toffe82 | amiconn: I am testing the HD and it seems that changing the parameter to 4096 is twice as fast as if I comment the line |
00:04:36 | saratoga | Zagor: properly implemented it can actually save power |
00:04:41 | Zagor | I don't want clock speed tied to backlight. I'm just saying we can skip updating the screen when backlight is off, hence not having to boost. |
00:04:43 | amiconn | Really? Did you run test_disk? |
00:04:48 | saratoga | because the normal clock speed can be reduced, and the average clock made lower overall |
00:04:54 | toffe82 | yes , it is running now |
00:05:26 | Zagor | saratoga: reduce average clockspeed and boost heavy code instead. then we're boosting for fractions of seconds instead of 5-10. |
00:05:32 | toffe82 | I will post the result in a moment, I still have to do it at 80Mhz |
00:05:37 | amiconn | I'd expect the version with 4096 byte sectors handled in rockbox to be considerably slower on 512-byte writes than the other |
00:05:38 | saratoga | i mean we waste more power every second right now by having a 30MHz normal clock then I'm proposing to waste for 5 or 10 seconds at a time |
00:05:58 | | Quit parafin (niven.freenode.net irc.freenode.net) |
00:05:58 | NSplit | niven.freenode.net irc.freenode.net |
00:05:58 | | Quit lucent (niven.freenode.net irc.freenode.net) |
00:05:58 | | Quit perrikwp (niven.freenode.net irc.freenode.net) |
00:05:58 | | Quit TMM (niven.freenode.net irc.freenode.net) |
00:05:58 | | Quit daurnimator (niven.freenode.net irc.freenode.net) |
00:05:58 | | Quit shodanX (niven.freenode.net irc.freenode.net) |
00:05:58 | | Quit preglow (niven.freenode.net irc.freenode.net) |
00:05:58 | | Quit killan (niven.freenode.net irc.freenode.net) |
00:05:58 | | Quit DaCapn (niven.freenode.net irc.freenode.net) |
00:05:58 | | Quit Zambezi (niven.freenode.net irc.freenode.net) |
00:05:58 | | Quit tim__b (niven.freenode.net irc.freenode.net) |
00:05:58 | | Quit balou (niven.freenode.net irc.freenode.net) |
00:05:59 | | Quit lostlogic (niven.freenode.net irc.freenode.net) |
00:05:59 | | Quit maraz (niven.freenode.net irc.freenode.net) |
00:05:59 | | Quit liiwi (niven.freenode.net irc.freenode.net) |
00:05:59 | | Quit blippe (niven.freenode.net irc.freenode.net) |
00:05:59 | | Quit BlakeJohnson86 (niven.freenode.net irc.freenode.net) |
00:06:08 | NHeal | niven.freenode.net irc.freenode.net |
00:06:08 | NJoin | lucent [0] (n=eshattow@75-174-180-52.chyn.qwest.net) |
00:06:08 | NJoin | perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-70fa3a5bea504b72) |
00:06:08 | NJoin | TMM [0] (n=hp@5ED10264.cable.ziggo.nl) |
00:06:08 | NJoin | daurnimator [0] (n=daurn@ppp118-208-145-18.lns10.mel4.internode.on.net) |
00:06:08 | NJoin | killan [0] (n=nnscript@c-415472d5.06-397-67626721.cust.bredbandsbolaget.se) |
00:06:08 | NJoin | parafin [0] (i=parafin@paraf.in) |
00:06:08 | NJoin | preglow [0] (i=thomj@tvilling2.pvv.ntnu.no) |
00:06:08 | NJoin | DaCapn [0] (i=dacapn@using.your.wireless-inter.net) |
00:06:08 | NJoin | shodanX [0] (n=shodanX@jazz.informatik.uni-erlangen.de) |
00:06:08 | NJoin | Zambezi [0] (i=stolgfor@bnc.fran.dotbnc.se) |
00:06:08 | NJoin | tim__b [0] (i=tim__b@the-ascii-scene.doesntexist.org) |
00:06:22 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
00:07:04 | saratoga | Zagor: Buschel, Toni and I proposed that, but people said we can't do that right now because the GUI and plugins become ugly |
00:07:43 | Zagor | saratoga: I can't find the "starve" boosting in playback.c. do you have a pointer to that? |
00:07:47 | amiconn | I'd rather stay KISS |
00:07:55 | NJoin | blippe [0] (n=none_of_@213.136.34.23) |
00:07:55 | NJoin | BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
00:07:55 | NJoin | balou [0] (i=balou@cl-1844.ham-01.de.sixxs.net) |
00:07:55 | NJoin | liiwi [0] (i=liiwi@idle.fi) |
00:07:55 | NJoin | maraz [0] (i=maraz@xob.kapsi.fi) |
00:07:55 | NJoin | lostlogic [50] (n=lostlogi@rockbox/developer/lostlogic) |
00:08:08 | saratoga | Zagor: I've never looked at playback.c |
00:08:17 | saratoga | i just know that if the PCM buffer gets low, the CPU boosts |
00:08:49 | Zagor | amiconn: I agree that tagging code for boosting doesn't feel terribly simple/elegant either |
00:09:08 | saratoga | i think a pretty simple solution is to just make CPU_NORMAL depend on if the buttons have been touched recently |
00:09:18 | saratoga | and have two possible speeds for it |
00:09:23 | Zagor | saratoga: ah, but that it does no matter how much other cpu use there is |
00:09:25 | saratoga | so we'd have a 3 step boost |
00:09:49 | amiconn | Too complicated, imo |
00:09:56 | Zagor | saratoga: that would give strange variations in scroll speeds or updates of complex wps etc. not pretty. |
00:09:57 | saratoga | Normal and GUI not in use | Normal and GUI in use | and Boosted |
00:10:08 | saratoga | Zagor: I don't think it could |
00:10:27 | saratoga | if the timeout on GUI in use is fairly long at least |
00:10:31 | amiconn | I'd keep the simple 2-freq scheme on all targets with fixed core voltage. The i.MX31 is a different matter, as already mentioned |
00:10:54 | saratoga | unfortunatel the simple scheme wastes a lot of power on PP because of the GUI responisveness issue |
00:11:10 | amiconn | huh? |
00:11:12 | saratoga | and argueable we're already staving the GUI a little, I've seen people complain that my MP3 optimizations actually made the GUI worse |
00:11:35 | saratoga | amiconn: we could save 2 mA right now just by dropping the normal clock to 24MHz |
00:11:44 | saratoga | but we don't |
00:11:52 | * | amiconn wouldn't call 2mA a lot. |
00:12:04 | saratoga | almost 10% |
00:12:09 | amiconn | It's surely noticeable, but calling it a lot is exaggerating |
00:12:09 | Zagor | saratoga: the only way to avoid that is to tie "timeout gui not in use" to backlight timeout |
00:12:24 | saratoga | and once I finish with MP3 it'll be more like 15% |
00:12:31 | Zagor | which means running at high speed for maybe 30 seconds |
00:12:43 | amiconn | But *if* we can do boosting almost for free, why even bother with timeouts? |
00:12:57 | Zagor | amiconn: I agree completely |
00:13:06 | amiconn | Zagor: It would potentially mean running boosted forever |
00:13:07 | saratoga | Zagor: that would be acceptable I think, the cost is probably only 3-4mA, IE we'd still waste less on average then we do right now |
00:13:23 | saratoga | amiconn: if that can be made to work I'd be ok with it |
00:13:27 | * | amiconn uses backlight always-on in the car on most targets |
00:13:31 | saratoga | though I wonder how well it would work in practice |
00:13:34 | Zagor | saratoga: |
00:13:47 | | Quit {phoenix} (Remote closed the connection) |
00:13:53 | saratoga | i'm skeptical that it would tolerate a very low normal clock without nasty effects during scrolling |
00:13:56 | Zagor | saratoga: well, we simply disagree :) |
00:13:57 | | Quit HellDragon (Read error: 104 (Connection reset by peer)) |
00:14:16 | amiconn | saratoga: Not if we boost just for lcd updates... |
00:14:17 | Zagor | saratoga: in my version, scrolling would be boosted |
00:14:22 | saratoga | I.E. how is scrolling going to look if we ping pong between 16 or 24MHz and 80MHz |
00:14:37 | kugel | probably funny |
00:14:45 | saratoga | i think some timeout might be needed to make tha tlook smooth but I don't know how the code works |
00:14:47 | | Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) |
00:14:52 | Zagor | no, because scrolling always runs at the same speed |
00:15:06 | amiconn | saratoga: cpu_boost(true); lcd_update(); cpu_boost(false); |
00:15:10 | Zagor | we ping pong back and forth but each section of code always runs at the same speed every time |
00:15:29 | kugel | might be my imagination, or it might have other causes, but I'm fairly sure I already experience different scrolling speeds as of now |
00:15:29 | | Quit ZincAlloy ("CGI:IRC (EOF)") |
00:15:37 | Zagor | so the use doesn't notice which code runs boosted and which doesn't |
00:15:51 | saratoga | yes but the time for each thread to be serviced wouldn't be constant right? since if you're at 24 MHz in an unboosted thread you still have to wait |
00:16:37 | saratoga | i mean i realize we can make LCD updates always be fast by boosting, but they still have to wait there turn in the scheduler right |
00:16:51 | kugel | rasher: did you notice the patch I put up? my fix from yesterday wasn't actually a fix |
00:17:00 | | Join hd [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) |
00:17:22 | saratoga | though maybe not if the code is interrupt based liek buttons |
00:17:53 | Zagor | also but the waiting time is short because all heavy work is boosted. plus the schedule looks rather similar loop after loop |
00:18:03 | | Quit HellDragon (Read error: 104 (Connection reset by peer)) |
00:18:19 | | Quit hd (Read error: 104 (Connection reset by peer)) |
00:18:55 | kugel | pixelma: can you try that patch, to make sure it's really fixed now? |
00:19:40 | saratoga | i don't really know enough to have an opinion on how well that would work, but assuming it does work well, it would seem like the best solution, at least for PP |
00:19:50 | * | kugel agrees |
00:19:53 | rasher | kugel: ah, last-second changes to patches. My mortal enemy |
00:20:12 | | Join mofux_ [0] (n=quassel@dslb-092-078-048-103.pools.arcor-ip.net) |
00:20:13 | Zagor | yeah the messy part is having to do it two ways since coldfire boosting is so expensive :-( |
00:20:41 | | Quit mofux (Read error: 60 (Operation timed out)) |
00:20:43 | saratoga | whats the normal clock on Coldfire? |
00:21:01 | amiconn | 45MHz |
00:21:19 | | Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) |
00:21:24 | saratoga | wow thats quite high given how fast CF compared to PP |
00:21:32 | amiconn | (actually 4*11.289.600Hz == 45.158.400Hz) |
00:21:40 | saratoga | i imagine that must waste a good bit of power when decoding MP3s |
00:22:22 | amiconn | It's roughly the same ratio for boosted vs. unboosted as on PP (actually that's how the unboosted PP speed was chosed) |
00:22:23 | kugel | Zagor: given that most targets are arm, and it's unlikely (imo) that this situation is gonna change (it's gonna get worse rather), optimizations for arm might be worthwhile |
00:22:45 | amiconn | The next-lower possible speed would be too low for decent UI speed on H300 |
00:22:49 | amiconn | *chosen |
00:23:07 | Zagor | kugel: yes, but not at the cost of coldfire performance. which means we'd have to implement both the new and keep the current (or another) system |
00:23:19 | amiconn | kugel: This doesn't depend on architecture, but rather on the SoC in use |
00:23:30 | amiconn | i.MX31 has to be handled *very* different |
00:23:46 | kugel | oh, I got it slightly wrong then |
00:23:50 | saratoga | the wiki says CF needs 30MHz for MP3, so there 15MHz reserved for GUI |
00:24:07 | saratoga | verses PP where, even with COP, we reserve maybe 5 |
00:24:26 | saratoga | on vorbis we reserve -10MHz! |
00:24:33 | * | amiconn wonders what saratoga is trying to say |
00:25:01 | saratoga | Vorbis needs 40MHz, 10 more then the normal clock on PP |
00:25:08 | amiconn | We cannot go 34MHz on colour coldfire because the UI would be too sluggish. And we don't have zero-cost boost on coldfire |
00:25:35 | saratoga | amiconn: a better boosting scheme might be useful . . . |
00:26:03 | saratoga | though i have no idea what the cost per MHz is like on CF |
00:26:15 | * | amiconn can't think of a better scheme that is simple enough to handle for a rather universal firmware like rockbox |
00:26:59 | | Quit midgey () |
00:27:15 | saratoga | amiconn: well back to the button boosting idea |
00:27:16 | amiconn | Some OFs use large tables of necessary cpu power for the various codecs, plus corrections for dsp etc. Good enough for a limited frmware, not feasible in rockbox |
00:27:32 | saratoga | make 45MHz normal clock for 30 seconds after the buttons are pressed |
00:27:33 | amiconn | And in spite of our simple scheme, we beat of runtimes on many targets... |
00:27:36 | saratoga | otherwise 34MHz |
00:27:52 | Zagor | saratoga: I really dislike that solution :-( |
00:27:57 | saratoga | you'll do no worse for GUI responsiveness, and save power |
00:28:19 | saratoga | i think its better then just wasting power |
00:28:19 | amiconn | saratoga: Even without button activity, 34MHz will be visible. Even the 45MHz are visibly different from 124MHz on H300 |
00:28:23 | | Quit advcomp2019 (Read error: 104 (Connection reset by peer)) |
00:28:40 | | Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) |
00:28:46 | saratoga | sure it'll be visable but if no one has input anything in 30 seconds, the most they could be doing is probably looking at the WPS |
00:28:49 | amiconn | Scrolling *looks* different, even though it isn't slower. This is just die to the lower lcd update speed |
00:28:58 | amiconn | s/die/due/ |
00:29:07 | Zagor | I'd much rather do more active power saving when the backlight goes out |
00:29:31 | saratoga | don't some of the CF targets have screens you can read without backlight? |
00:29:39 | saratoga | i thought the h100 could, though i don't have one |
00:29:40 | Zagor | it's almost the same, but much less visible |
00:29:40 | amiconn | Zagor: Tieing it to the backlight would be even worse, imo |
00:30:31 | saratoga | for CF you could set the time out really long, like 5+ minutes, just to get the case where someone starts a long playlist and then goes running or whatever |
00:30:33 | amiconn | It's not the same. If you have backlight always-on, you'd waste the whole lot of power... |
00:31:38 | Zagor | amiconn: I am not advocating raising the current speed. only to stop doing things we don't need to do. such as updating the wps on a black display. |
00:31:59 | kugel | then cap the gui boosted time, and still tie it to backlight |
00:32:00 | | Quit jrsharp () |
00:32:28 | Zagor | I could never accept multi-second boosting. it's just wrong. |
00:32:34 | kugel | you have backlight always on in your car, but you're hardly looking at it all the time. And especially not close enough to care about slightly different scrolling speeds |
00:32:56 | saratoga | Zagor: on CF you wouldn't need to boost, but rather reduce the clock I think |
00:33:00 | kugel | care and/or notice |
00:33:12 | amiconn | kugel: That's not my point |
00:33:55 | saratoga | i'd consider 45MHz on CF already boosted, hell its probably 2/3 as fast as PP is fully boosted I think |
00:34:09 | saratoga | no sense going higher for GUI |
00:34:39 | kugel | what's the point? If you cap the the boost for gui to a timeout, you're not gonna waste power all the time with backlight on |
00:34:51 | Zagor | saratoga: I don't care about coldfire. I care about the system design. |
00:35:38 | kugel | Zagor: a system where gui updates when the the screen is unreadable is crealy flawed, yes |
00:36:01 | kugel | clearly* |
00:36:01 | saratoga | regarding system design, we currently lose system responsiveness when codecs are optimized so I'd say we're not doing too hot in that area |
00:36:37 | saratoga | i'd tolerate some more complexity if we could have some consistency here |
00:37:01 | Zagor | saratoga: do you have some information about that, other than "someone said"? |
00:37:40 | *** | Saving seen data "./dancer.seen" |
00:37:49 | | Join soap_ [0] (n=463c10f5@gateway/web/cgi-irc/labb.contactor.se/x-5166ef289ec1eff1) |
00:37:54 | scorche | Zagor: were you notified about the issues with registering on the wiki here? http://www.rockbox.org/irc/log-20081213#03:43:17 |
00:37:55 | * | gevaerts remembers seeing non-insignificant differences between WPS and main menu in runtime tests on c200 with the old default theme |
00:37:55 | amiconn | Unhelpful: Did you check the math that gcc is actually doing for (modified) brightness() on SH1? Gcc *is* weird... |
00:38:15 | saratoga | Zagor: sure, MP3 optimizations dropped the average clock speed from ~40MHz to 30MHz, so the GUI responsiveness changed too |
00:38:20 | kugel | Zagor: well, it seems logical then if codecs to less boosts, the gui doesn't benefit from those less |
00:38:35 | Zagor | scorche: no. |
00:38:46 | Zagor | saratoga: ah, of course. |
00:38:50 | kugel | s/doesn't/do/ |
00:39:13 | Unhelpful | amiconn: my only assembly, really, is MMX/SSE2 and M65XX... but i can take a look. |
00:39:27 | scorche | Zagor: well, there ya go =) |
00:39:51 | Zagor | scorche: thanks :-) |
00:39:52 | kugel | Unhelpful: so, this bitmap is read on the target, but not in the sim. what to do about that? |
00:40:49 | kugel | and it crashes upon clicking it in pf |
00:41:04 | kugel | the image is clearly bugged or something, but yet your loader seems to read it |
00:41:15 | kugel | on target |
00:41:45 | scorche | Zagor: there is this too: http://www.rockbox.org/twiki/bin/view/Main/UserListByDateJoined |
00:42:25 | Unhelpful | kugel: is that image on FS? |
00:42:27 | Zagor | saratoga: actually, umm, not of course. as far as I can understand codec boost should not affect gui performance. only the codec code runs boosted. |
00:42:35 | | Quit domonoky (Read error: 104 (Connection reset by peer)) |
00:42:38 | Unhelpful | also, which target, so i can sim the same on my end |
00:42:46 | Zagor | more boosted codec code does not mean faster gui |
00:42:58 | kugel | Unhelpful: no, should I make a new task or append it to FS #9631 |
00:43:09 | Unhelpful | that's the PF bugs task? |
00:43:15 | kugel | no |
00:43:16 | scorche | Zagor: same with this: http://www.rockbox.org/twiki/bin/view/Main/UserListByLocation |
00:43:17 | saratoga | Zagor: boost effects everything |
00:43:27 | kugel | the "since resize added themes crash" one |
00:43:37 | saratoga | the codec initiates the boost, but other threads still experience it |
00:43:39 | Unhelpful | i didn't know there was one! |
00:43:55 | Zagor | saratoga: only if the boost remains on over yield, which I certainly hope we don't do |
00:44:11 | saratoga | Zagor: we boost until the PCM buffer is refilled, and that takes seconds |
00:44:48 | Zagor | that is ... bad |
00:44:49 | saratoga | 3 seconds of PCM is probably dozens of yeilds |
00:44:57 | amiconn | Unhelpful: The >>4 version might be good enough, and it saves some size on all architectures |
00:45:03 | saratoga | Zagor: yes :) |
00:45:36 | saratoga | in fact, the slower the codec, the more clock cycles are allocated to the GUI! |
00:45:58 | Unhelpful | amiconn: that was mean squared error ~5 grey levels, i believe |
00:45:59 | Zagor | saratoga: how is that? |
00:46:02 | amiconn | Zagor: Why is that bad? It's very good for coldfire. And you can lower the pcm buffer size on quick-boost targets |
00:46:09 | gevaerts | That's good! That way you have something to look at while waiting for this skip to end |
00:46:24 | amiconn | Unhelpful: The SVN version also has some error, I believe around the same overall |
00:46:40 | Zagor | amiconn: because it's wasteful, and it causes difference in gui speed ("user experience") |
00:46:47 | | Quit rasher ("leaving") |
00:46:59 | | Join rasher [0] (n=rasher@0x5550f5a3.adsl.cybercity.dk) |
00:47:04 | saratoga | Zagor: because the higher the boost percentage, the more clock cycles are in each second, and a larger absolute number are available to non-codec threads |
00:47:13 | Unhelpful | the >>8 version is ~.3 grey levels, the /10 version is ~2 |
00:47:14 | | Quit jhulst (Remote closed the connection) |
00:47:42 | saratoga | ironically as the codecs get faster less cycles become available to the GUI |
00:48:20 | Unhelpful | because they finish quickly and drop the boost? that's counter-intuitive and logical at the same time |
00:48:40 | kugel | the main irony is |
00:48:56 | saratoga | codecs yeild according to how many samples they've decoded, so the faster they're decoding the more often they yeild |
00:49:09 | kugel | the faster the codecs gets, the slower the user experience gets |
00:49:17 | amiconn | saratoga: That's only a reason not to lower the unboosted frequency too much. Otherwise it's a little weird, but not a problem at all imo |
00:49:18 | saratoga | and since theres more cycles to go around, more are available to other threads when they do yeild |
00:49:24 | kugel | as in "they said they optimized mp3, but rockbox is much slower now!" |
00:50:28 | saratoga | amiconn: well its a problem in that battery life is reduced verses more efficient allocation systems |
00:50:34 | Zagor | a better solution than boosting is to remake the yield criteria |
00:50:36 | saratoga | though it obviously has the advantage of being very simple |
00:50:50 | saratoga | Zagor: rewriting codecs . . . |
00:51:06 | amiconn | Zagor: You need to boost no matter what. |
00:51:09 | saratoga | most just yeild when they finsh decoding a frame |
00:51:12 | saratoga | which is sensible |
00:51:13 | Unhelpful | Zagor: by time spent? that's what was recommended to me for the scaler |
00:51:17 | Zagor | saratoga: so? we change code all the time. and this is a very small change |
00:51:21 | * | amiconn thinks that saratoga has a typo lock |
00:51:37 | Zagor | Unhelpful: yes |
00:51:47 | saratoga | as in I keep misspelling something? |
00:51:58 | Zagor | amiconn: yeah I meant saratogas "GUI boost" |
00:52:47 | saratoga | Zagor: the problem is more fundimental then when codecs choose to yeild |
00:52:53 | amiconn | Unhelpful: If you think the error for >>4 is too much, then I'd say go >>8 |
00:53:06 | Unhelpful | amiconn: i'd want the >>8 if we're going to get 7-8 real bits of greyscale |
00:53:11 | saratoga | as long as boosting depends on the codecs state alone, the allocation cycles will not be optimal between the GUI and codecs |
00:53:12 | amiconn | Still faster than /10, and only a very little bit larger |
00:53:23 | saratoga | "allocation of cycles" |
00:53:44 | Zagor | saratoga: if codecs can be made to yield the same amount of time, GUI will get the same amount of cycles no matter how fast the codec is |
00:53:47 | Unhelpful | >>4 is the last one where any of the multiplies convert to shifts, at least up to the overflow limit for 32-bit values |
00:53:47 | saratoga | since optimal allocation necessarily involves asking the GUI code how many cycles it needs rather then just telling it how many it gets . . . |
00:54:25 | Zagor | optimal allocation is not interesting. consistent allocation is. |
00:54:39 | saratoga | presumably consistent allocation is optimal :) |
00:55:05 | saratoga | anyway is the problem really codecs not boosting enough? i doubt its that simple |
00:55:19 | saratoga | though I guess I could rig one to yield more often |
00:55:23 | Zagor | consistent allocation definitely does not require asking the GUI code what it needs. 100 cycles/sec is completely consistent, |
00:55:28 | saratoga | then lower the core clock and see what happens |
00:55:49 | saratoga | i was actually refering to cpu clock cycles, not scheduler ticks |
00:55:56 | Zagor | not boosting enough? who said that? |
00:56:03 | Zagor | so was I |
00:56:28 | saratoga | oh I thought you mean 100 cycles /sec as in 100 ticks |
00:56:36 | Zagor | 100 cycles is perfectly consistent, but very far from what the GUI "needs" |
00:57:27 | Zagor | the problem you describe is that the GUI gets inconsistent amounts of cpu time for different codecs. the solution is to make codecs more deterministic. |
01:00 |
01:00:00 | | Quit kugel (Remote closed the connection) |
01:00:11 | * | amiconn wonders how that would work |
01:00:22 | | Join kugel [0] (n=chatzill@e179081072.adsl.alicedsl.de) |
01:00:40 | amiconn | Without either introducing preemption or rewriting many decoder libs, I mean |
01:00:48 | Zagor | decode for X ms instead of X frames? |
01:01:00 | Zagor | of course rounded up to whole frames |
01:01:38 | amiconn | Afaik many codecs yield once per frame. You cannot yield more often without hacking the libs |
01:02:19 | Zagor | well the question is should they really yield that often? |
01:03:03 | amiconn | With libdemac you actually decode a configurable block of samples instead of a frame, so it would be possible. But then you either need a monitoring method, or a very complex precalculation of block size |
01:03:26 | saratoga | sorry, had to run for a second, so basicall Zagor's idea is to yield more often to force more time in the GUI threads? |
01:03:28 | amiconn | ...because decoding time depends on compression level, number of channels, sample rate, sample depth, ... |
01:03:38 | Zagor | saratoga: no, more seldom |
01:03:56 | saratoga | less time in GUI threads? |
01:03:59 | amiconn | Yielding once per frame isn't very otfen |
01:04:14 | saratoga | maybe we're talking about different things |
01:04:30 | Zagor | apparently |
01:04:32 | saratoga | i want a way to reduce the normal clock speed without screwing up the GUI |
01:04:36 | saratoga | so I can save more power |
01:05:19 | Zagor | amiconn: that naturally differs per codec |
01:05:23 | bertrik | sorry, I'm not familiar with this part, but why would codecs yield at all? Shouldn't the part that calls the codec do the yielding/waiting instead of the codec? |
01:05:44 | Zagor | bertrik: I was thinking the same thing |
01:05:54 | saratoga | bertrik: i assume different codecs give very different numbers of samples at a time |
01:07:18 | saratoga | for example, mp3 frames are 1152 samples, but a pure transform codec like wma or vorbis will produce 2048 or 4096 samples per frame |
01:07:27 | Zagor | 128kbit mp3 is 38 frames per second, if I recall correctly. yielding 38 times per second during boosted decoding is definitely a lot |
01:08:10 | saratoga | that does seem like a lot, but the GUI still gets starved at low clock speeds |
01:08:32 | soap_ | what is the general opinion of the "Boost on UI" patch? |
01:08:49 | Zagor | soap_: which patch is that? |
01:08:52 | soap_ | (not how well is it implemented, but the general idea of it) |
01:08:59 | amiconn | Zagor: That's a rather small number of yields. Don't forget that scrolling needs frequent yields in order to not look jumpy |
01:09:19 | amiconn | Imo any thread should yield *at least* once per tick |
01:09:20 | Zagor | amiconn: scrolling needs § |
01:09:21 | soap_ | one sec Zagor |
01:09:33 | Zagor | 5-10 yields/sec to look good. not 40. |
01:09:47 | amiconn | uh? Ever set a higher scrolling speed? |
01:10:17 | soap_ | http://www.rockbox.org/tracker/task/8668 |
01:10:57 | | Quit bertrik ("ZZZ") |
01:11:02 | _jhMikeS_ | I wouldn't be shy with yields, they aren't expensive calls. |
01:11:09 | | Nick _jhMikeS_ is now known as jhMikeS (n=jethead7@rockbox/developer/jhMikeS) |
01:11:24 | amiconn | A speed of 15 updates every 3 ticks. That means it needs at least 33 yields per seconds to work, and then an uncertainty of 1 tick will already cause visible jumpiness |
01:12:14 | amiconn | I don't think that the highest speed is used by many people, but it may be in use |
01:12:19 | saratoga | amiconn: is there code somewhere that will drop the normal CPU speed to 16 MHz? I want to test this on my Sansa but 30MHz will be too fast |
01:12:30 | Zagor | soap_: I'm not so fond of the idea |
01:12:31 | saratoga | i can change mad to yield more easily enough |
01:12:33 | * | amiconn usually uses 10 or 11, meaning updates every 10 or 8 ticks |
01:13:08 | soap_ | Zagor: avoiding the issue? |
01:13:16 | Zagor | soap_: ? |
01:13:43 | soap_ | are you not so fond of the idea because you feel it is avoiding the issue, or is there a more complex reason? |
01:13:51 | amiconn | saratoga: I don't think so, but it should be easy to make such a patch |
01:14:27 | saratoga | amiconn: I have no idea how, could you make me one? |
01:14:40 | Zagor | soap_: I think it is the wrong solution. |
01:14:43 | saratoga | or I guess I could give you the mad changes if you have an ipod video handy |
01:16:26 | | Quit bluebrother ("leaving") |
01:16:34 | kugel | amiconn: I use the highest scrolling speed, together with 1px scrolling step. That's how I like scrolling |
01:17:35 | Zagor | jhMikeS: the idea wasn't to lower the yield count per se, but to attempt to make all codecs use similar amount of cycles/sec and thereby reduce GUI speed differences between codecs |
01:19:01 | Zagor | I don't think it's a terribly attractive idea myself though :) I'm a fan of zero-cost boosting. |
01:19:08 | saratoga | i don't think making them all similar will be realistic, since the placement of yields would have to change as codecs are optimized, but if yeilding is the problem we could certainly just yield more often |
01:19:57 | Zagor | saratoga: more often could have a similar effect, but would make overall boost times longer |
01:21:14 | saratoga | Zagor: yeah but we could then lower the normal clock speed and still come out ahead |
01:22:08 | Zagor | only if we also implement your gui boost which I don't like one bit |
01:22:27 | Zagor | uh, didn't mean to sound rude |
01:23:07 | saratoga | Zagor: if codec yeilding is the problem, then gui boosting isn't even needed |
01:23:25 | saratoga | we could just yield more and the problem would go away |
01:24:47 | Zagor | codec yielding would only affect the issue of having different codecs affect gui speed differently. lowering the overall gui clock speed would hurt the gui experience, as reported earlier |
01:25:08 | soap_ | unboosted the 5G scrolls slow in the file browser. |
01:25:54 | saratoga | Zagor: if the codecs yield enough, the GUI gets enough clock cycles no matter then normal clock speed |
01:26:03 | saratoga | at least thats what I thought you were saying |
01:26:25 | Zagor | saratoga: no. if the clock speed is too low, the gui will be sluggish even without any codec running |
01:26:42 | Zagor | the yield idea was to improve _consistency_, not speed |
01:27:43 | Zagor | soap_: yes. I propose to boost heavy functions such as lcd_update. |
01:28:07 | | Nick JdGordon|zzz is now known as JdGordon (n=jonno@rockbox/developer/JdGordon) |
01:28:32 | saratoga | Zagor: yes but its not that simple |
01:28:44 | saratoga | the codecs always get enough clock cycles because they control boosting |
01:28:58 | saratoga | so if they yeild so often that the GUI always gets enough clock cycles . . . |
01:29:03 | amiconn | saratoga: Made that patch, just testing whether it works. On PP5020 it does, but 5022 is a bit different |
01:29:25 | saratoga | amiconn: i've only got PP5024 but I'll give it a shot |
01:29:29 | amiconn | UI is kinda sluggishg on ipod color at 16MHz |
01:29:40 | saratoga | oh then you can just test this idea |
01:29:42 | amiconn | 5024 is 5022 as far as pll setup is concerned |
01:30:12 | saratoga | put a yield on line 458 of mpa.c |
01:30:40 | kugel | rasher: are you going to commit http://www.rockbox.org/tracker/task/9634 ? Not that it gets forgotten before the release |
01:30:41 | saratoga | not even close to ideal, but probably good enough just to test |
01:31:00 | saratoga | wait sorry |
01:31:08 | saratoga | 442 of that file |
01:31:28 | kugel | saratoga: but that only helps in the boosting state. But codecs tend to best less |
01:31:50 | saratoga | so bitstream parsing and huffman will go, then yield, then pass off to the COP and yeild again |
01:32:04 | amiconn | Nah, you wanted a clock patch, you get one ;) |
01:32:10 | saratoga | :) |
01:32:12 | Zagor | I have to go to bed. See you all later! |
01:32:14 | | Quit Zagor ("Leaving") |
01:32:27 | kugel | s/best/boost |
01:32:31 | amiconn | Works on PP5022 too (tried c200) |
01:32:33 | saratoga | actually been meaning to ask you for one anyway so I could test power consumption |
01:32:39 | saratoga | can you pastebin it? |
01:33:42 | amiconn | amiconn.dyndns.org/~jens/pp502x_16mhz.diff">http://amiconn.dyndns.org/~jens/pp502x_16mhz.diff |
01:34:22 | | Quit soap_ ("CGI:IRC (Ping timeout)") |
01:35:15 | amiconn | Eh, wait |
01:35:20 | amiconn | That patch isn't complete |
01:36:18 | amiconn | Now it is :) |
01:37:39 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
01:42:45 | | Quit faemir (Remote closed the connection) |
01:44:14 | saratoga | ha the sansa is only slightly different even without mad changes at 16MHz |
01:44:20 | saratoga | i have to really scroll to see any difference at all |
01:44:46 | saratoga | although shutting down does take longer |
01:46:20 | toffe82 | amiconn: I post the result, if you want to have a look |
01:47:36 | | Part jeffdameth1 |
01:48:37 | kugel | rasher: thanks! now lets quickly forget my fail |
01:49:16 | | Quit lasser (Read error: 110 (Connection timed out)) |
01:50:10 | saratoga | I'm not certain adding more yields made things any better, though its possible I've not placed them well enough to really help |
01:55:35 | saratoga | where is ci defined? including codeclib.h doesn't seem to give me it inside a codec library file |
02:00 |
02:02:15 | | Quit jhMikeS (Read error: 60 (Operation timed out)) |
02:04:20 | saratoga | i simply do not seem to be able to call yield inside a codec and I can't figure out why its not working |
02:04:30 | saratoga | not even including kernel.h works |
02:10:43 | | Quit HellDragon (Remote closed the connection) |
02:11:09 | | Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) |
02:13:45 | | Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) |
02:17:35 | | Quit culture (Read error: 110 (Connection timed out)) |
02:20:39 | | Quit mofux_ (Read error: 110 (Connection timed out)) |
02:20:41 | | Join mofux [0] (n=quassel@dslb-088-075-026-166.pools.arcor-ip.net) |
02:20:48 | Unhelpful | saratoga: i know it's a couple hours later, but yielding per N cycles... do any targets have a TSC or similar? |
02:22:00 | toffe82 | is the transfer of files on the ipod fast or really slow ? mine take forever to transfer |
02:24:33 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
02:29:13 | | Quit einhirn (Read error: 110 (Connection timed out)) |
02:30:15 | | Join webguest82 [0] (n=43534488@gateway/web/cgi-irc/labb.contactor.se/x-f3ada7c8e9054741) |
02:31:28 | webguest82 | how to copy database to mac? what folder where is it cannot find original backup would you know where it would be on mac, is there a simpler manual for rockbox |
02:34:43 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
02:35:41 | webguest82 | where can I ask questions at, i don't mean to offend you guys, would like to know the backup location for rockbox database and extract the music rockbox took. |
02:35:52 | webguest82 | on mac |
02:35:54 | | Quit Schmogel (Read error: 104 (Connection reset by peer)) |
02:37:24 | n1s | webguest82: this is the place for questions, what do you mean by "the backup location for rockbox database" ? |
02:37:44 | *** | Saving seen data "./dancer.seen" |
02:41:33 | Unhelpful | webguest82: rockbox does not store the music in a database, only some information about it, and only if you choose to enable the database, and that database is not usable for much besides rockbox. |
02:41:44 | Unhelpful | the music is wherever you put the files on your device. |
02:42:15 | | Quit n1s () |
02:42:18 | | Quit herrwaldo ("Konversation terminated!") |
02:42:27 | | Quit jhulst (Remote closed the connection) |
02:42:38 | saratoga | Unhelpful: we have timers and such, but rockbox is cooperatively multithreaded so we don't use them like that |
02:43:37 | webguest82 | I had a lot of music on my ipod before i installed rockbox, it made a .backup (it was a folder) anyway I want to know if I can extract that database, there are a lot of repeats and its really messy I want to organize it and drag it to the music section |
02:44:06 | Unhelpful | saratoga: well, i ask about something like a TSC in particular, because if you want to yield every N CPU clocks, that's a way to do it. on x86, where i know how to do so. :/ |
02:44:25 | webguest82 | I tried floola but it has a limited amount of songs wierd because some of the database music was on floola. |
02:44:46 | Unhelpful | webguest82: unless your target does something funny, i don't think rockbox made that .backup... |
02:45:32 | saratoga | Unhelpful: i don't know what would be involved with making the codecs preemptable |
02:45:40 | saratoga | though i think people would generally oppose going in that direction |
02:46:25 | webguest82 | i remember during the initial installation it asked if i wanted to make a backup folder and I did, the music in the files folder( the first option) I'm not to good with directory names, doesn't have all my music the database does. |
02:46:37 | | Quit bmbl ("Woah!") |
02:47:26 | JdGordon | saratoga: also, maybe playback preemptable would be a biggish job (iirc) |
02:49:22 | Unhelpful | saratoga: i'm not talking about forced preemption... but i had thought it had been you who had sad, a bit ago, that we might try to make the ratio of yield calls to clock cycles be roughly similar across codecs, to improve consistency. of course, i can't find it now. :/ |
02:49:57 | saratoga | Unhelpful: if you're not going to have preemption, then you have to check the timer, in which case you might as well yeild I think |
02:50:24 | Unhelpful | it's that cheap, eh? :) |
02:50:30 | saratoga | i think so |
02:50:52 | | Quit maddler (Read error: 110 (Connection timed out)) |
02:50:55 | saratoga | it should just push the registers on the stack, jump into the scheduler and then bounce back if theres nothing else to run |
02:51:52 | Unhelpful | ok, i was thinking along the lines of timing sources you could use, but if it's better to yield without testing, then it turns into a matter of deciding where to place yields to even out the scheduling of other tasks |
02:53:02 | webguest82 | How can I access database from my computer through my I-Pod, if its a database and stores the majority of my music i should be able to access it? |
02:54:39 | kugel | webguest82: the database does _not_ store your music anywhere |
02:55:21 | webguest82 | I have over a 1000 songs in my database it takes a while to load i backed up into my ram |
02:55:27 | Unhelpful | not the rockbox one, anyway. |
02:55:40 | webguest82 | than where can i go to access it? |
02:55:53 | Unhelpful | your music files are wherever you put them. |
02:56:38 | | Join cozo [0] (n=c9d6dd78@gateway/web/cgi-irc/labb.contactor.se/x-ad78ada646da2c8b) |
02:56:41 | webguest82 | can i boot up to i-tunes |
02:56:54 | cozo | hello everyone! |
02:57:00 | cozo | first time here |
02:57:28 | | Quit ender` (" The problem with political jokes is they get elected. -- Henry Cate, VII") |
02:57:35 | | Quit mofux (Remote closed the connection) |
02:58:57 | cozo | i really would like to contribute to rockbox, but i dont know C. though i know how to write metacode, php, some java, some php and action script |
02:58:58 | webguest82 | so my database was in i-tunes thanx you guys are so helpful |
02:59:07 | | Join mud-rb [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) |
02:59:08 | saratoga | calling yield inside a codec lib freezes rockbox |
02:59:11 | cozo | can you recommend how i can get started on C |
02:59:39 | cozo | so i can start writing code for rockbox? |
02:59:59 | saratoga | cozo: get a book and start studying I guess? |
03:00 |
03:00:00 | Aurix_Lexico | http://www.cprogramming.com/tutorial.html#ctutorial is a decent start |
03:00:31 | cozo | yeh, i dont have anu money for books |
03:00:49 | Unhelpful | saratoga: then i *really* didn't understand the conversation. sorry about my noise. :) |
03:01:08 | saratoga | does calling yield change the state of a thread somehow? I can't see how this would crash |
03:01:26 | saratoga | oh wait nevermind |
03:01:34 | cozo | Aurix_Lexico: thnx i will check that out |
03:01:49 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
03:02:56 | Unhelpful | cozo: knowing java will help a bit with C. much of the syntax is similar, but C lacks classes, and Java lacks pointers, among other differences |
03:05:03 | saratoga | i always forget that mad has two copies of each header file and I always only edit one of them |
03:05:27 | | Quit webguest82 ("CGI:IRC") |
03:05:36 | mud-rb | is there a summary of architectures for rockbox somewhere (like byte/word sizes, alignment constraints, that kind of stuff)? |
03:07:22 | cozo | oh yeah i also wanted to ask this; would it be better to code with Cygwin or install a linux distro |
03:07:31 | Unhelpful | mud-rb: there's a wiki page with links to programmer references, those should have a lot of what you want... |
03:07:56 | Unhelpful | cozo: that's a matter of preference. i've heard that cygwin builds pretty slowly, compared to some of the alternatives. |
03:08:35 | rasher | cozo: Depends. Cygwin is amazingly slow, but Linux is a completely different environment if you're used to Windows. If you're ready for some experimenting, I'd go with Linux |
03:08:48 | mud-rb | Unhelpful: which one do you mean? i think i'm missing it somehow. there's the developer part of the docs index, is it in here somewhere? |
03:08:54 | hobbs | cozo: cygwin is not worth much. You're better off working with mingw32 on windows (Dev-C++ is quite nice, really). But Linux is where it's at. ;) |
03:09:38 | rasher | Unhelpful: Shouldn't pictureflow resize albumart to a smaller-than-display-size size? |
03:09:41 | hobbs | cygwin's API is just enough like unix that you screw yourself every time you assume it really _is_ like unix ;) |
03:10:25 | rasher | hobbs: cygwin is needed to compile Rockbox though |
03:11:11 | hobbs | okay. point. (You can tell I've never tried to build rockbox on windows...) |
03:11:18 | Unhelpful | rasher: doesn't it? i've only looked at it a little bit, but it uses the pluginlib scaler. it requests unscaled loads, i believe into a buf_alloc buffer, and has them scaled into another buffer, then it saves raw LCD pixels to the cache. i think. |
03:11:25 | cozo | i´ve used linux before, but if im installing linux i would like to use it on a old notebook (166mhz, 80ram) would there be a problem?? |
03:11:50 | saratoga | it'd take all day to compile |
03:11:56 | rasher | cozo: that would be painful to compile on |
03:12:12 | saratoga | mud-rb: we support ARM, Coldfire, and SH1 |
03:12:16 | rasher | Unhelpful: Maybe I'm silly for having exactly-display-sized AA, but it does in fact fill my entire display |
03:12:16 | Unhelpful | i'd suggest the vmware images that are ready-built for the purpose |
03:12:36 | mud-rb | saratoga: thanks. i can probably look it up from those |
03:12:39 | rasher | Rather ruining the pictureflow effect |
03:12:44 | cozo | so i guess im better off using mingw32 or VMware |
03:13:01 | Unhelpful | rasher: i do the same, i've a custom WPS for showing it that way, it's rather nice on a portrait LCD |
03:13:33 | Unhelpful | i think full-size AA would leave too little space on landscape... 80px on ipod video |
03:14:04 | Unhelpful | there's a zoom size option in PF |
03:14:44 | Unhelpful | it apears to work by changing parameters of the projection, though, so it's not too pretty, really |
03:14:47 | saratoga | I've added a lot of additional yields to MAD but the GUI is still extremely sluggish when unboosted at 16MHz and I can clearly see when it does boost |
03:14:57 | rasher | Unhelpful: Ah, I guess that will do |
03:14:59 | saratoga | either i'm doing something wrong or yielding doesn't help |
03:15:34 | * | Unhelpful is just going to state again, he has changed nothing in PF |
03:15:48 | cozo | Unhelpful: can you recommend a VMware image? |
03:17:07 | saratoga | cozo: the one we provide |
03:17:07 | mud-rb | cozo: the guide is here, see the 'Quick start guide' for the actual VMware image links http://www.rockbox.org/twiki/bin/view/Main/VMwareDevelopmentPlatform |
03:17:31 | cozo | thanx! |
03:22:37 | saratoga | amiconn: playing with this some more, I'm not sure the GUI really lags anymore with music playing then it does without it playing, so maybe 16MHz is just too slow |
03:24:03 | * | jhMikeS wouldn't mind a guide to setting up a new vmware image for rockbox (the 2GB one is too cramped) |
03:25:23 | Unhelpful | jhMikeS: couldn't you just add another disk image with the desired amount of space, and put the actual builds there? |
03:26:24 | Unhelpful | kugel: did you ever determine if the problem you had in PF was the loader, or not? also, was that on color? the unscaled color case *should* be fairly robust... :/ |
03:27:29 | jhMikeS | Unhelpful: I don't know. I haven't tried anything but the player so far. I see the image contents are on the wiki. I suppose I'd better poke around. |
03:27:39 | kugel | Unhelpful: the loader is probably fine. On the target, pf shows that image too (like the wps), but when I click it it starts zooming in, and data aborts as soon as it's done with zooming in |
03:27:41 | rasher | jhMikeS: My buildserver vm has a larger disc iirc.. but then that's set up to be a buildserver only. |
03:27:48 | kugel | my target & sim is e200 |
03:28:54 | kugel | rasher: pictureflow doesn't resize at all as of now |
03:28:57 | Unhelpful | i suspec that's a Not My Bug, then... if i get a chance before i get details on 9631, i'll still try to take a look. i can think of at least one way color upscaling might crash, and a ludicrous case in which either might crash :/ |
03:29:32 | jhMikeS | I see ide0:.... stuff in there I wonder about ide1:.... |
03:29:42 | kugel | it implemented a call to the resize function, but it only resizes the "?" graphic, not your album art |
03:31:18 | | Quit soap (Remote closed the connection) |
03:31:21 | Unhelpful | kugel: ... i see that you're right about that. create_bmp has a resize flag, it's false for AA cache loads,and only set true for the ? |
03:31:34 | kugel | yep |
03:31:41 | kugel | FS #8335 changes that |
03:32:18 | kugel | Unhelpful: I've messed a bit with pf, so..:) |
03:33:22 | Unhelpful | "fixing" it for on-load resize is a pretty small job, except for the darn "?" |
03:34:37 | kugel | Unhelpful: smooth_resize is pretty decent, in terms of speed and image quality. It doesn't resize on load, that's the only problem |
03:34:51 | kugel | (and it's only for color afaik) |
03:35:26 | kugel | but unless smooth_resize is removed altogether, changing pf for resize on load is arguable imho |
03:35:27 | Unhelpful | it uses exactly the same algorithms as resize-on-load, it should produce the same output, aside from rounding errors. |
03:35:42 | * | jhMikeS points the author of the scaler to add similar functionality to the YUV thumbnailer in mpegplayer |
03:36:48 | Unhelpful | i went a bit out of my way to avoid rounding *anything* except the final pixel values... that may be the only place where quality would differ at all. |
03:36:54 | kugel | Unhelpful: afaik smooth_resize does area for both up and downscaling. Yours does it only for upscaling, or did I get something wrong? |
03:37:54 | Unhelpful | kugel: i've not read smooth_resize, but i've read the old-resize-on-load algos that are supposed to have come from it. those were bilinear-on-up, area-on-down, bilinear-on-down if the line cache size was exceeded |
03:38:12 | kugel | Unhelpful: I don't know what idak based his resize off, sorry |
03:38:28 | kugel | but I think he commented on that pretty well |
03:38:40 | Unhelpful | let me look in pluginlib, it should be pretty clear if it's the same as what i replaced |
03:38:41 | saratoga | are there WPSes out there that are complicated enough to be impacted by CPU boost? |
03:39:09 | kugel | Unhelpful: well, the comments for smooth_resize claim it's always area sampling, optimized for speed |
03:39:48 | kugel | saratoga: just imagine mass scrolling, alternating sublines, loads of conditional viewports ... |
03:40:06 | saratoga | kugel: could you recommend one? i want to test something |
03:40:42 | | Quit cozo ("CGI:IRC") |
03:41:27 | Unhelpful | kugel: this is not quite the same... things are obscured a bit by the fact that idak's patch took rgb24, and this is meant to scale color FORMAT_NATIVE, which is rgb16 |
03:42:01 | Unhelpful | a *lot* of variable names in common, and the general method by which coordinate transformation is done is the same. |
03:42:43 | kugel | saratoga: blacknblue glass in the e200 wps gallery is a rather complex one, but freestate (the one above) looks quite complex too |
03:43:04 | saratoga | kugel: do they look bad unboosted though? |
03:43:25 | saratoga | basically i need a way to make the GUI slow so I can easily look for unresponsiveness |
03:43:30 | kugel | I don't think so |
03:44:12 | kugel | but "unresponsive UI" mainly affects the interaction (i.e. scrolling through lists), not viewing |
03:44:17 | Unhelpful | if there's anything i would say slows mine down vs this, it's the 32-bit intermediates i use |
03:44:32 | saratoga | kugel: yeah I've been doing scrolling tests, but they're somewhat subjective |
03:44:40 | saratoga | and you can't see the boost status while you do it |
03:45:10 | saratoga | still i think yielding probably isn't that important |
03:45:13 | kugel | I suppose you can switch to songs which have album art from one who doesn't have album art |
03:45:13 | Unhelpful | on the other hand, the 32-bit intermediates mean that not very much multiplying is done |
03:45:25 | kugel | and messure the transition time between the conditional viewport setting |
03:46:01 | saratoga | at least i'm not noticing any real slow down with music playing then with it paused |
03:46:29 | kugel | Unhelpful: I have no problem with dropping smooth_resize (if you thought that), but until a decision is made, the "better looking" one should be used for plugins IMHO |
03:46:32 | saratoga | but i do notice a difference between paused and boosted and paused and unboosted at 24MHz |
03:46:54 | saratoga | so it may just be that 30MHz is quite enough for smooth scrolling on targets with more to draw then my sansa |
03:47:19 | kugel | yep |
03:47:41 | kugel | the only people reporting sluggish ui are ipod video user iiuc |
03:47:48 | | Quit jhulst (Remote closed the connection) |
03:48:55 | saratoga | i guess we need some sort of GUI boosting then, either amiconns way or mine |
03:49:36 | saratoga | interestingly, if I scroll a lot it seems to get faster |
03:49:56 | * | kugel would prefer the very short boost with keeping the reasonable normal boost |
03:50:14 | Unhelpful | kugel: amiconn's set me onto porting the new scaler to greyscale... i realized that taking out 2/3 of the in-loop math would probably make it nearly as small as the NN scaler, anyway, and it would be far less difficult for me to debug one scaler than two. |
03:50:16 | saratoga | perhaps i have to drain the PCM buffer a bit before the codec and GUI threads come to equilibrium |
03:50:18 | kugel | else you're just gonna be dependent on how long users look on there screen |
03:50:59 | kugel | Unhelpful: go ahead then :) |
03:51:23 | kugel | but I doubt smooth_scale was to be ported to greylib ever |
03:51:29 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-0a4168835c86d41a) |
03:51:33 | jhMikeS | saratoga: something like that, as the buffer drains, the priority is gradually brought up and so codec gets more chances to run |
03:52:05 | jhMikeS | of that's only when it is really low, otherwise codec is normal priority |
03:52:26 | Unhelpful | kugel: my other project for that is to make the line output pluggable. that will add very little to the cost, and will let greylib-using plugins slot in an 8bpp greyscale output |
04:00 |
04:00:47 | | Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.4/2008111319]") |
04:03:17 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
04:03:54 | | Join soap [50] (n=soap@rockbox/staff/soap) |
04:13:30 | | Join countrymonkey [0] (n=4b05639a@gateway/web/cgi-irc/labb.contactor.se/x-a5338c977c99710f) |
04:14:06 | | Quit countrymonkey (Client Quit) |
04:21:03 | | Quit agaffney (Read error: 104 (Connection reset by peer)) |
04:25:41 | | Join agaffney [0] (n=agaffney@gentoo/developer/agaffney) |
04:30:18 | | Quit Aurix_Lexico (Read error: 110 (Connection timed out)) |
04:31:58 | | Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) |
04:37:46 | *** | Saving seen data "./dancer.seen" |
04:45:35 | | Quit _Tristan (Read error: 113 (No route to host)) |
04:53:27 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
04:57:21 | | Quit Thundercloud (Remote closed the connection) |
05:00 |
05:04:41 | | Join _lifeless [0] (n=lifeless@90.151.32.228) |
05:06:20 | | Quit miepchen^schlaf (Read error: 110 (Connection timed out)) |
05:08:55 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-f8c151c605bf2654) |
05:12:03 | | Quit _lifeless (Remote closed the connection) |
05:12:04 | | Join __lifeless [0] (n=lifeless@90.151.43.130) |
05:24:21 | | Join midgey [0] (n=tjross@71.238.148.140) |
05:31:42 | | Join _lifeless [0] (n=lifeless@90.151.213.206) |
05:34:54 | | Quit __lifeless (Read error: 60 (Operation timed out)) |
05:35:14 | | Quit saratoga ("CGI:IRC (EOF)") |
05:37:21 | | Quit esthar (Read error: 60 (Operation timed out)) |
05:50:47 | | Quit _lifeless (Remote closed the connection) |
05:51:07 | | Join _lifeless [0] (n=lifeless@90.151.37.52) |
05:53:48 | | Join __lifeless [0] (n=lifeless@90.151.47.169) |
05:54:16 | | Quit _lifeless (Remote closed the connection) |
05:57:09 | | Join pixelma_ [0] (n=pixelma@rockbox/staff/pixelma) |
05:57:51 | | Quit pixelma (Read error: 110 (Connection timed out)) |
05:57:51 | | Quit amiconn (Read error: 110 (Connection timed out)) |
05:58:00 | | Join amiconn [50] (n=jens@rockbox/developer/amiconn) |
06:00 |
06:04:59 | | Join esthar [0] (n=esthar@student164-247.hampshire.edu) |
06:18:19 | | Join thegeek_ [0] (n=nnscript@s243b.studby.ntnu.no) |
06:21:35 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
06:24:26 | | Quit thegeek (Read error: 60 (Operation timed out)) |
06:27:37 | | Join brodymcd1 [0] (n=brodymcd@cpe-24-29-168-22.woh.res.rr.com) |
06:28:25 | brodymcd1 | can someone please help me? My sansa e270 won't connect to the computer... it was fine yesterday - now when I connect the USB, it just reboots OVER AND OVER... help? |
06:31:04 | advcomp2019 | brodymcd1, are you booting into the sansa firmware like the manual says |
06:32:03 | brodymcd1 | advcomp2019: no... I never had to before... although I did recently try that, and when I connected the usb, it just rebooted, then the cycle started over. |
06:33:15 | advcomp2019 | brodymcd1, try booting into the sansa firmware manually |
06:33:24 | brodymcd1 | wow - now it is frozen on the splash, then the screen took on a purple tint, and is now frozen and fading. |
06:34:03 | brodymcd1 | advcom: how do I boot into the sansa firmware? |
06:34:22 | mud-rb | brodymcdi: hold left as it boots |
06:34:31 | advcomp2019 | << while booting it up |
06:35:23 | brodymcd1 | can't do it... although I could about 15 minutes ago... I can only turn it on and let it go to Rockbox OR it just reboots over and over and over... did that when I held left just now |
06:36:11 | advcomp2019 | does recovery mode work? |
06:36:35 | brodymcd1 | adv: how do I do that? sorry - I'm new to rockboxing. |
06:37:45 | advcomp2019 | brodymcd1, look for the unbricking e200 wiki |
06:37:50 | *** | Saving seen data "./dancer.seen" |
06:39:57 | brodymcd1 | I just entered recovery mode |
06:40:05 | brodymcd1 | found the unbricking guide... |
06:42:14 | advcomp2019 | you can reinstall the sansa firmware then see if it will boot up.. do not weird about the sansa.fmt file yet |
06:45:15 | advcomp2019 | oops.. worry not weird lol |
06:45:56 | | Quit kharo (Read error: 60 (Operation timed out)) |
06:46:34 | | Join kharo [0] (n=teemu@a88-114-255-186.elisa-laajakaista.fi) |
06:46:53 | | Join BigE[ssh] [0] (n=eric@adsl-75-45-24-251.dsl.scrm01.sbcglobal.net) |
06:48:12 | brodymcd1 | followed guide... ended up having to use sansa.fmt... back to original now - many thanks! |
06:49:01 | advcomp2019 | brodymcd1, you are welcome.. you can just put rockbox back on if you need to |
06:53:39 | BigE[ssh] | hello advcomp2019 ;) |
06:54:41 | | Join saratoga [0] (n=41becb3b@gateway/web/cgi-irc/labb.contactor.se/x-f052855492708c8f) |
06:55:50 | brodymcd1 | adv: last time I installed rb, I did so from windows... I'm trying to do it from 64-bit linux now... messing something up... dl'ed the auto installer, extracted... double-clicked and nothing - thoughts/help? |
06:56:16 | hobbs | brodymcd1: run it from shell so you can find out what kind of not-working it's doing. |
06:57:01 | | Join jrsharp [0] (n=jrsharp@c-98-193-244-253.hsd1.tn.comcast.net) |
06:57:38 | | Quit JdGordon (Read error: 60 (Operation timed out)) |
06:58:05 | advcomp2019 | brodymcd1, i have not used the rockbox utility myself but do you might have to use it by the terminal to you can get admin rights |
06:58:11 | | Join JdGordon [0] (n=jonno@c211-28-145-137.smelb2.vic.optusnet.com.au) |
07:00 |
07:00:09 | | Quit brodymcd1 (Remote closed the connection) |
07:07:37 | | Quit kharo (Read error: 60 (Operation timed out)) |
07:09:00 | | Join Tristan [0] (i=tristan@i.dont.want.to.die.virgin.net.in) |
07:10:17 | | Join kharo [0] (n=teemu@a88-114-255-186.elisa-laajakaista.fi) |
07:14:09 | | Quit jrsharp (Read error: 113 (No route to host)) |
07:24:43 | | Join jrsharp [0] (n=jrsharp@c-98-193-244-253.hsd1.tn.comcast.net) |
07:36:37 | | Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) |
07:36:54 | | Join brodymcd1 [0] (n=brodymcd@cpe-24-29-168-22.woh.res.rr.com) |
07:38:18 | brodymcd1 | theme question - I LOVE this theme "Cabbie" which I just reinstalled after unbricking my Sansa... but it doesn't have the same playback screen it had before, which is shown on the website. The playback screen is that crappy one that is in many themes with just the horizontal bars badly formatted... anyone know where to get the "correct" theme or how to fix this? |
07:39:24 | Llorean | That means the theme contains outdated tags. |
07:39:30 | Llorean | Or some other problem. |
07:39:45 | Llorean | The solution is basically to read the CustomWPS page, and read the theme and fix it. |
07:41:09 | | Quit saratoga ("CGI:IRC (EOF)") |
07:42:32 | hobbs | or maybe just download a new version of CabbieV2 or something, if it's similar enough for your taste (go to WPSGallery and then click on your player) |
07:43:22 | Llorean | hobbs: Rockbox's default theme is CabbieV2 |
07:43:28 | Llorean | You shouldn't need to download it. |
07:44:32 | brodymcd1 | Cabbie V2 is ok... I like Cabbie better... but there is some weirdness about legality of it now? |
07:45:17 | | Quit jhulst (Read error: 113 (No route to host)) |
07:45:58 | | Quit JdGordon (Remote closed the connection) |
07:48:04 | | Join JdGordon [0] (n=Miranda@c211-28-145-137.smelb2.vic.optusnet.com.au) |
07:48:47 | Llorean | brodymcd1: It was being distributed with at least one image that the author didn't actually have a license to reuse, so we couldn't continue distributing it. |
07:48:54 | | Quit Rob2223 (Read error: 104 (Connection reset by peer)) |
07:49:27 | | Quit jrsharp () |
07:49:55 | | Join Rob2222 [0] (n=Miranda@p4FDCDBBA.dip.t-dialin.net) |
07:57:10 | | Join sm0ken [0] (n=44230e98@gateway/web/cgi-irc/labb.contactor.se/x-21fec146bf0ec735) |
07:57:46 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
07:58:35 | sm0ken | Linux? I just got my sansa e250 in todays mail.. it was refurb and did n't come with CD with Sansa media Converter. I have Linux here.. how to load mp3'2 with Linux?? |
07:59:22 | Llorean | sm0ken: That really doesn't have anything to do with Rockbox. |
08:00 |
08:01:26 | sm0ken | OK, lets try this: AFTER I load rockbox, can I load mp3's with Linux? |
08:01:54 | scorche | of course |
08:02:02 | Llorean | Same way you do before you load Rockbox. :) |
08:02:29 | sm0ken | where in the 179 page PDF for sansa rockbox is mention of using Linux? Not apparent in TOC |
08:02:34 | Llorean | Rockbox doesn't have a USB mode for the e200 series yet, so you're still in the original firmawre when connected. |
08:02:52 | Llorean | sm0ken: Why would the PDF explain how to use your computer's OS? It's about Rockbox... |
08:03:21 | sm0ken | how does one introduce mp3s into e250? |
08:03:28 | scorche | however one wishes |
08:04:05 | mud-rb | sm0ken: you load them the same way you loaded them before rockbox (using the original sansa firmware). it has almost nothing to do with rockbox |
08:04:25 | Llorean | mud-rb: Not "almost nothing." Literally nothing, since Rockbox doesn't change the OF's behaviour. |
08:05:37 | sm0ken | OK, if I have this e250 and I have winXP but to CD with Sansa Media Converter s/w, how does one substitute Linux to accomplish loading. Linux is NOT mentioned in SanDisk docs, nor Rockbox |
08:05:52 | sm0ken | no CD with Media Converter |
08:05:58 | Llorean | sm0ken: Please, understand, this channel is for questions about Rockbox. |
08:06:06 | | Join Rob2222 [0] (n=Miranda@p4FDCDBBA.dip.t-dialin.net) |
08:06:18 | Llorean | sm0ken: You're asking how to use its original firmware. |
08:06:51 | scorche | sm0ken: we told you before...any way you want... |
08:06:59 | | Quit JdGordon (Read error: 54 (Connection reset by peer)) |
08:07:16 | Llorean | sm0ken: Read the channel topic perhaps. It might give you a couple clues. Then maybe if you feel a bit more like following the guidelines, people might be more helpful. |
08:07:37 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
08:07:43 | sm0ken | right, I may be. However the SanDisk manual I found on the web, has no mention of Linux, and without the CD with Windoze s/w, I was asking how does one use Linux to accomplish loading of mp3's |
08:07:58 | scorche | sm0ken: what about "any way you want" is unclear/ |
08:08:01 | Llorean | sm0ken: This isn't making anyone want to help you more. |
08:08:10 | Llorean | sm0ken: This is NOT a channel for the questions you're asking. Please, take them someplace else. |
08:08:11 | lucent | sm0ken: There's two methods with the Sansa players, "MTP" and "MSC" |
08:08:27 | advcomp2019 | sm0ken, just throw that sansa manual out the door |
08:11:24 | brodymcd1 | llorean: is there a version of cabbie around without that image? I just loved that theme... so clear to see. |
08:11:45 | Llorean | brodymcd1: There's not one in the wiki, so I don't know. As I said before, you could just fix your copy of it. |
08:12:05 | brodymcd1 | llorean: that wps code makes my head want to pop off! ;) |
08:12:51 | Llorean | brodymcd1: Well, that's pretty much your only choice. |
08:14:10 | brodymcd1 | Llorean: is it possible to cut-and-paste from another wps that has a layout I like? |
08:15:13 | Llorean | Why not just use the WPS you like the layout of? |
08:15:35 | Llorean | Cutting and pasting effectively will still require you learning some of the WPS code |
08:15:46 | | Quit Gareth ("Terminated with extreme prejudice - dircproxy 1.0.5") |
08:16:23 | scorche | it really is not that hard to learn...there are guides and such in the wiki that you can use as references |
08:16:50 | | Join Rob2222 [0] (n=Miranda@p4FDCF96F.dip.t-dialin.net) |
08:18:00 | | Quit sm0ken ("CGI:IRC (EOF)") |
08:19:14 | brodymcd1 | cool - thanks, guys. I guess I will use Cabbie v. 2 until I have more time to hack through the wps learning curve. |
08:36:47 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
08:37:54 | *** | Saving seen data "./dancer.seen" |
08:41:12 | | Join JdGordon [0] (n=Miranda@c211-28-145-137.smelb2.vic.optusnet.com.au) |
08:42:09 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
08:47:03 | | Join Rob2222 [0] (n=Miranda@p4FDCF96F.dip.t-dialin.net) |
08:47:05 | | Quit massiveH ("Leaving") |
08:49:01 | | Join midgey_ [0] (n=tjross@71.238.148.140) |
08:51:17 | | Part toffe82 |
08:52:53 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
08:55:13 | | Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) |
08:56:33 | | Quit gevaerts (Remote closed the connection) |
08:56:45 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
08:57:30 | | Quit Seed ("cu, Andre") |
08:58:19 | | Quit jhulst (Remote closed the connection) |
09:00 |
09:03:53 | | Quit midgey (Read error: 110 (Connection timed out)) |
09:04:36 | | Quit agaffney (Read error: 104 (Connection reset by peer)) |
09:04:46 | brodymcd1 | I just realized I have my wife's sansa... so I copied the Cabbie.wps file from there to my newly-restored Sansa and it still has the crappy bars on the playback screen. How can there be the same cabbie.wps file on 2 identical sansas giving different results? |
09:04:50 | | Join agaffney [0] (n=agaffney@gentoo/developer/agaffney) |
09:05:14 | brodymcd1 | yes, I know I am obsessed. |
09:06:15 | lucent | brodymcd1: that's fairly interesting to me |
09:06:15 | lucent | :) |
09:06:15 | lucent | I don't know about the technical parts yet of WPS or the code |
09:06:19 | pixelma | I guess on one of them the Rockbox version that's installed is a lot older |
09:06:26 | | Quit midgey_ () |
09:10:35 | brodymcd1 | so is it then possible that my newly-restored sansa is not reading things the same because it is newer? Shouldn't that make it BETTER?? |
09:11:33 | Llorean | brodymcd1: As I said the very first time you asked. |
09:11:38 | Llorean | The theme is _outdated_ |
09:11:42 | Llorean | It needs to be updated to be fixed. |
09:12:14 | hobbs | brodymcd1: your _new_ version of the rockbox software can't read the _old_ file because the format changed. |
09:13:09 | brodymcd1 | ah... ok, then. Thanks all! |
09:13:14 | | Part brodymcd1 |
09:20:56 | | Join webguest55 [0] (n=414448a6@gateway/web/cgi-irc/labb.contactor.se/x-1816dbd2ab18b4e7) |
09:21:02 | | Quit webguest55 (Client Quit) |
09:29:40 | amiconn | Gah! Why does twiki not use width and height parameters in img tags? |
09:42:54 | | Quit BHSPitLappy (Read error: 110 (Connection timed out)) |
09:43:13 | | Quit JdGordon (niven.freenode.net irc.freenode.net) |
09:43:13 | NSplit | niven.freenode.net irc.freenode.net |
09:43:13 | | Quit kachna (niven.freenode.net irc.freenode.net) |
09:43:13 | | Quit BigE[ssh] (niven.freenode.net irc.freenode.net) |
09:43:13 | | Quit tchan (niven.freenode.net irc.freenode.net) |
09:43:13 | | Quit plus_M (niven.freenode.net irc.freenode.net) |
09:43:13 | | Quit pabs (niven.freenode.net irc.freenode.net) |
09:43:13 | | Quit amigan (niven.freenode.net irc.freenode.net) |
09:43:13 | | Quit Galois (niven.freenode.net irc.freenode.net) |
09:43:13 | | Quit crashd (niven.freenode.net irc.freenode.net) |
09:43:13 | | Quit esthar (niven.freenode.net irc.freenode.net) |
09:43:13 | | Quit Bensawsome (niven.freenode.net irc.freenode.net) |
09:43:13 | | Quit linuxstb (niven.freenode.net irc.freenode.net) |
09:43:13 | | Quit bapdog (niven.freenode.net irc.freenode.net) |
09:43:13 | | Quit blithe (niven.freenode.net irc.freenode.net) |
09:43:13 | | Quit shadearg (niven.freenode.net irc.freenode.net) |
09:43:13 | | Quit Xerion (niven.freenode.net irc.freenode.net) |
09:43:13 | | Quit ChanServ (niven.freenode.net irc.freenode.net) |
09:44:29 | NHeal | niven.freenode.net irc.freenode.net |
09:44:29 | NJoin | ChanServ [0] (ChanServ@services.) |
09:44:29 | NJoin | Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) |
09:44:29 | NJoin | shadearg [0] (i=arg@panoptix.net) |
09:44:29 | NJoin | blithe [0] (n=blithe@li35-144.members.linode.com) |
09:44:29 | NJoin | bapdog [0] (n=pt@78-86-201-141.zone2.bethere.co.uk) |
09:44:29 | NJoin | linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
09:44:29 | | Join Bensawsome [0] (n=Bensawso@unaffiliated/bensawsome) |
09:44:29 | NJoin | esthar [0] (n=esthar@student164-247.hampshire.edu) |
09:44:29 | Mode | "#rockbox +o ChanServ " by irc.freenode.net |
09:44:55 | | Join amigan [0] (i=dcp1990@ip68-226-92-253.ri.ri.cox.net) |
09:45:18 | NJoin | crashd [0] (i=foobar@lostnode.org) |
09:45:22 | NJoin | pabs [0] (n=pabs@xor.pablotron.org) |
09:45:22 | NJoin | plus_M [0] (i=plus@li26-205.members.linode.com) |
09:45:41 | | Join BigE[ssh] [0] (n=eric@75.45.24.251) |
09:49:38 | | Join tchan [0] (n=tchan@lunar-linux/developer/tchan) |
09:51:19 | | Quit amigan (Killed by ballard.freenode.net (Nick collision)) |
09:51:21 | | Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) |
09:51:21 | | Quit JdGordon (Killed by ballard.freenode.net (Nick collision)) |
09:51:22 | | Quit BigE[ssh] (Killed by ballard.freenode.net (Nick collision)) |
09:51:22 | | Join JdGordon [0] (n=Miranda@rockbox/developer/JdGordon) |
09:51:22 | NJoin | BigE[ssh] [0] (n=eric@adsl-75-45-24-251.dsl.scrm01.sbcglobal.net) |
09:51:22 | NJoin | kachna [0] (n=kachna@r4ax178.net.upc.cz) |
09:51:22 | NJoin | amigan [0] (i=dcp1990@unaffiliated/amigan) |
09:51:22 | NJoin | Galois [0] (i=djao@efnet-math.org) |
09:51:35 | | Join BigE[ssh1 [0] (n=eric@75.45.24.251) |
09:51:36 | | Join amigan_ [0] (i=dcp1990@ip68-226-92-253.ri.ri.cox.net) |
09:51:41 | | Join JdGordon_ [0] (n=jonno@c211-28-145-137.smelb2.vic.optusnet.com.au) |
09:51:57 | | Quit amigan (Connection reset by peer) |
09:52:05 | | Quit kachna (Connection reset by peer) |
09:54:17 | | Quit ameyer (Read error: 131 (Connection reset by peer)) |
09:59:14 | | Quit JdGordon (Read error: 110 (Connection timed out)) |
10:00 |
10:02:31 | | Quit BigE[ssh] (Connection timed out) |
10:02:56 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
10:08:03 | | Join lasser [0] (n=chatzill@W997f.w.pppool.de) |
10:11:05 | | Join kachna [0] (n=kachna@r4ax178.net.upc.cz) |
10:16:16 | | Join Kitti [0] (n=himka_co@195.5.125.25) |
10:16:22 | | Part Kitti |
10:19:33 | | Nick JdGordon_ is now known as JdGordon (n=jonno@rockbox/developer/JdGordon) |
10:27:46 | | Join n1s [0] (n=nils@rockbox/developer/n1s) |
10:37:59 | *** | Saving seen data "./dancer.seen" |
10:50:35 | | Join Schmogel [0] (n=Miranda@p3EE209E6.dip0.t-ipconnect.de) |
10:53:26 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
11:00 |
11:02:54 | JdGordon | grrrrrrr.... stupid code freezes my sansa |
11:09:36 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-05867d9acf7c715e) |
11:10:40 | JdGordon | does it take longer than 1 tick to set the tuner's freq and check if its tuned? |
11:11:21 | | Join miepchen^schlaf [0] (n=miepel@p579EC63D.dip.t-dialin.net) |
11:11:44 | | Join {phoenix} [0] (n=dirk@p54B44DE2.dip.t-dialin.net) |
11:12:54 | bertrik | probably |
11:13:30 | | Quit bapdog (Read error: 60 (Operation timed out)) |
11:14:14 | JdGordon | slowed it down to once per 10 ticks but still the same freeze |
11:14:52 | JdGordon | I'm trying to get auto scanning working in a tick task, works fine in the sim but fails on the target |
11:18:32 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
11:21:32 | | Quit freqmod_qu (Remote closed the connection) |
11:24:26 | JdGordon | n1s: hey, can you see anything odd in http://pastebin.com/d711098bc ? my sansa locks up after the first callback to scan_cb() |
11:25:55 | | Join freqmod_qu [0] (i=quassel@2001:700:300:1430:213:d3ff:fee9:5ed0) |
11:26:13 | n1s | JdGordon: how long can a tick task take? also is it allowed to yield? |
11:26:53 | JdGordon | less than a tick, and I doubt it |
11:27:00 | JdGordon | do the tuner functions yield? |
11:28:44 | n1s | depends on the tuner driver, tuner_set(RADIO_FREQUENCY, curr_freq); would sleep in the si4700 driver at least, and a sleep will switch threads just like yield |
11:29:13 | JdGordon | hmm... there goes that idea :( |
11:30:03 | n1s | well, short sleeps could be replaced with busy loops but its' not so nice |
11:30:20 | bertrik | jhMikeS, you are familiar with as3514 and routing of audio within rockbox, right? |
11:30:30 | JdGordon | and just as bad if the task needs to finish quickly |
11:31:04 | * | JdGordon will change it to stay in the main thread |
11:31:45 | | Quit Schmogel (Read error: 104 (Connection reset by peer)) |
11:32:03 | bertrik | jhMikeS, currently the as3514 driver can enable LINE1 for radio, the clip re-uses the as3514 driver but uses LINE2 for radio instead of LINE1. |
11:36:52 | bertrik | I'm looking for cleanest way to make radio work on LINE2 for the sansa clip and other ams sansas |
11:45:50 | JdGordon | got it working.... but its very very slow... |
11:45:54 | * | JdGordon bbl |
11:46:05 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
12:00 |
12:01:30 | | Join herrwaldo [0] (n=waldo@ip-81-11-194-9.dsl.scarlet.be) |
12:12:47 | | Join faemir [0] (n=faemir@88-106-244-173.dynamic.dsl.as9105.com) |
12:14:44 | bertrik | I think we should remove the SansaV2FWHacks wiki page. This page refers to a git repository, but is no longer relevant as all development is done in SVN now. |
12:21:18 | n1s | yeah, that can be deleted :) |
12:21:42 | n1s | only The Swedes (tm) can do that though |
12:25:54 | jhMikeS | bertrik: Does use both LINEs (one for FM other for LINE in)? You could just #define AS3514_LINE_IN_R/L to the appropriate reg for the target. |
12:27:26 | bertrik | jhMikeS, as far as I know, the v1 sansas only uses LINE1 and no LINE2, the ams sansas use only LINE2 and no LINE1 |
12:30:21 | jhMikeS | The bit defs are overly-specific too (mia culpa). LINE_IN1/2_R/L_LI1/2R/L_MUTE_off could just be LINE_IN_LI_MUTE_off or something for all LI registers |
12:34:48 | | Join Lear [0] (i=chatzill@rockbox/developer/lear) |
12:37:22 | | Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) |
12:38:00 | *** | Saving seen data "./dancer.seen" |
12:44:48 | | Join MethoS- [0] (n=clemens@host-091-096-211-160.ewe-ip-backbone.de) |
12:45:28 | hobbs | hmm, cute. Apparently registering to the wiki requires human intervention. Who can hook me up? |
12:46:44 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
12:48:42 | | Quit faemir (Remote closed the connection) |
12:49:27 | | Join faemir [0] (n=faemir@88-106-244-173.dynamic.dsl.as9105.com) |
12:50:51 | | Join moos [0] (i=moos@81-66-158-133.rev.numericable.fr) |
12:52:11 | | Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) |
12:55:14 | | Join maddler [0] (n=maddler@static-217-133-171-24.clienti.tiscali.it) |
12:59:20 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
13:00 |
13:08:43 | | Join tessarakt [0] (n=jens@e180071080.adsl.alicedsl.de) |
13:08:56 | | Quit tessarakt (Read error: 104 (Connection reset by peer)) |
13:09:06 | | Join tessarakt [0] (n=jens@e180071080.adsl.alicedsl.de) |
13:17:22 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
13:23:33 | | Join AndyI [0] (i=AndyI@212.14.205.32) |
13:35:33 | | Quit AndyIL (Read error: 110 (Connection timed out)) |
13:43:42 | | Quit Seed ("cu, Andre") |
13:53:47 | * | domonoky plays with the buttons on e200v2. Ii can read Power and down-button. But all other buttons seems to be stuck, with no changes on the gpio pins :-/ |
13:53:56 | | Join kharo1 [0] (n=teemu@a88-114-255-186.elisa-laajakaista.fi) |
13:55:16 | | Quit kharo (Read error: 110 (Connection timed out)) |
13:55:59 | | Join Xerion_ [0] (i=xerion@82-170-197-160.ip.telfort.nl) |
13:56:02 | rasher | hobbs: what's your wikiname? |
13:58:23 | | Quit kachna ("Konversation terminated!") |
14:00 |
14:00:04 | | Quit Xerion (Read error: 60 (Operation timed out)) |
14:00:04 | | Nick Xerion_ is now known as Xerion (i=xerion@82-170-197-160.ip.telfort.nl) |
14:01:04 | | Join kachna [0] (n=kachna@r4ax178.net.upc.cz) |
14:05:10 | | Join tvelocity [0] (n=tony@adsl16-57.her.forthnet.gr) |
14:14:53 | Unhelpful | re: the supposedly-settled debate over how to handle WPS AA size change... i think i need to reconsider #3, in light of the fact that it looks like much of what it needs is already there? |
14:17:04 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
14:27:40 | | Quit write_erase (Remote closed the connection) |
14:29:15 | | Nick JdGordon is now known as JdGordon|zzz (n=jonno@rockbox/developer/JdGordon) |
14:38:01 | *** | Saving seen data "./dancer.seen" |
14:41:42 | | Join einhirn [0] (i=Miranda@p5B03335F.dip0.t-ipconnect.de) |
14:42:41 | | Join Rob2222 [0] (n=Miranda@p4FDCE0B1.dip.t-dialin.net) |
14:46:44 | | Join casainho [0] (n=chatzill@89.180.152.130) |
14:49:01 | casainho | hello :-) |
14:49:53 | casainho | I am looking for help, ideas, on a debug code, that seems not returning and I can't understand why... - here is one image of the code, showing a return; and PC counter: |
14:49:56 | casainho | http://farm4.static.flickr.com/3074/3106646697_c86b8e7cbc_o.png |
14:50:22 | | Join Aurix_Lexico [0] (n=comrade@c-68-56-205-239.hsd1.fl.comcast.net) |
14:50:41 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
14:51:27 | casainho | I am doing running step by step until that return; (blue line on the image) but it do not returns and even continue the code.... |
14:51:46 | casainho | I can see the PC going ahead... :-( |
14:52:06 | casainho | can anyone guess why is that hapenning? |
14:55:10 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
14:57:20 | casainho | bluebrother: are you there? |
14:59:26 | kugel | domonoky: yea, I got that far too |
15:00 |
15:00:21 | bluebrother | casainho: yep, sometimes :) |
15:01:10 | casainho | bluebrother: can you please help me? |
15:01:31 | bluebrother | those lines 1264 and 1265 don't have any effect. I guess you're aware of that? |
15:02:29 | bluebrother | also, is l actually NULL in your case? |
15:03:09 | casainho | I added them to see if PC counter passes there... and do not pass... why? GCC don't build that lines? why? |
15:03:26 | kugel | casainho: they're after return :S |
15:03:27 | bluebrother | which lines does it not build? |
15:03:36 | casainho | hmmm... I should declare them as static ?? |
15:03:58 | casainho | kugel: the question is that it do not returns :-( |
15:04:04 | bluebrother | casainho: no. Lines 1264 and 1265 are unreachable code, so it's kinda fine if the compiler optimizes it away |
15:04:35 | bluebrother | but I still don't get your problem. What exactly do you want to do? What value is l? |
15:04:38 | casainho | bluebrother: okok. But why the return; is not done?? |
15:04:53 | casainho | bluebrother: that is code from Rockbox source.... |
15:04:54 | bluebrother | well, asking a 3rd time: what value is l? |
15:05:15 | casainho | bluebrother: I don't know, I don't understand it... |
15:05:44 | bluebrother | the pc only displays where the program is currently executing. It does not display if you actually ran into that if() part |
15:06:00 | bluebrother | it only shows that you're after it. Well, that would mean l != NULL |
15:06:17 | bluebrother | thus it won't return in line 1262 |
15:06:38 | casainho | no... I saw code running inside that if( |
15:06:42 | domonoky | casainho: step thorugh you code, till before the if(..) the check (watch) the value of l with the debugger.. |
15:07:10 | bluebrother | well, are optimizations active? If yes this might just be a visual effect |
15:07:26 | bluebrother | you should check against the asm-interleaved sources to be sure |
15:08:10 | casainho | domonoky: l is > 1.. is a big value... |
15:08:49 | casainho | I checked as you siad |
15:08:49 | casainho | optimizations are off... |
15:08:49 | bluebrother | casainho: well, then (of course!) the if() part won't get executed |
15:09:09 | * | bluebrother wonders if eclipse can display the sources interleaved |
15:09:31 | casainho | hmmmm... I will make some more tests. Thanks :-) |
15:14:05 | casainho | here is another image, showing the value of "l": |
15:14:07 | casainho | http://www.flickr.com/photos/43558168@N00/3106694061/sizes/o/ |
15:14:57 | casainho | we can see the step inside the if( |
15:15:02 | bluebrother | well, check against the asm. That's possibly a visual thing only due to compiler resorting |
15:15:32 | bluebrother | eclipse is _displaying_ it stepping in the if() part. |
15:15:43 | casainho | but when on retruns, it do not returns and executes the next code after if(.. and then system looks like is doing a reset, jumping to 0x00 |
15:15:51 | bluebrother | and I wouldn't trust eclipse on that too much :P |
15:17:07 | | Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) |
15:17:09 | casainho | hmm.... okok −− I will investigate then ;-) thanks |
15:18:16 | bluebrother | back the time I tried using eclipse with gdb I had the impression the support being somewhat unreliable at times. Could have been my impression only though, haven't investigated it −− went to plain gdb :) |
15:24:01 | casainho | eheh - maybe someday I will also do the same ;-) |
15:24:42 | kugel | domonoky: do you have a e200v2 now? |
15:25:01 | domonoky | kugel: yes, and i jsut got something about those damn buttons :-) |
15:25:30 | kugel | nice, at least I'm not the only one caring about e200v2&fuze buttons anymore :) |
15:25:43 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
15:25:52 | domonoky | yeah, seems i got those buttons running ! :-) now to think about how to integrate it.. |
15:26:34 | kugel | domonoky: how? |
15:26:55 | domonoky | there are two problems with the buttons: the button_read is running in a interrupt, so we interrupt the lcd, which is bad. The other thing is clearing the lcd_data before reading buttons... |
15:26:59 | casainho | unfortunaly, looks like return; is not building :-( −− here is the disassembled view of the step by step code: |
15:27:01 | casainho | http://farm4.static.flickr.com/3283/3107550952_4ac6065446_o.png |
15:27:39 | domonoky | to clear the lcd-data. switch GPIO_AFSEL, set GPIOC to output, set all pins, then switch gpioc back to input, and read the buttons. |
15:27:46 | kugel | domonoky: yes, I thought about clearin lcd data yesterday. The button code in SVN is doing it wrong, isn't it? |
15:28:16 | casainho | bluebrother: do you think the return; can't be inside the if( ? |
15:28:48 | domonoky | kugel: yes, current svn code does it wrong. the sequence is important. |
15:29:03 | casainho | I am using the gcc version installed by the rockboxdev.sh script... |
15:29:13 | kugel | well, I came just yesterday to the idea that it's done wrong. |
15:29:40 | kugel | domonoky: button_read isn't a interrupt. It's running in a tick task |
15:30:20 | domonoky | kugel: yes, and the tick_task is called from interrupt context, at least on AS3525, so its also in interrupt_context |
15:30:31 | kugel | it is? |
15:30:44 | casainho | domonoky: can you please look at that image? http://farm4.static.flickr.com/3283/3107550952_4ac6065446_o.png |
15:30:55 | domonoky | kugel: take look at kernel_as3525.c |
15:32:51 | kugel | hm, I see |
15:33:14 | domonoky | casainho: sorry, i dont even know what you are trying to debug, so i dont know what todo with this screenshot. (Guis for gdb are mostly not really reliable.) |
15:34:30 | casainho | domonoky: okok. thanks. |
15:35:16 | bertrik | IIRC, redhat made a much simpler gdb ui |
15:36:50 | * | domonoky also uses a gdb gui at work (windriver workbench, a eclipse derivate) and its also not very reliable.. |
15:37:05 | bluebrother | casainho: well, there is no return opcode in the disassembly. At least none that I recognize as such and that is shown in the snippet |
15:37:40 | bertrik | it's http://sources.redhat.com/insight/ . At least it removes one layer of complexity in the stack of components involved in debugging. |
15:38:08 | bluebrother | seeing more of the source / disassembly would be really useful. Your window size definitely is quite small |
15:39:52 | | Quit Lear ("ChatZilla 0.9.84 [Firefox 3.0.4/2008102920]") |
15:40:08 | | Join mofux [0] (n=quassel@dslb-092-078-093-017.pools.arcor-ip.net) |
15:40:35 | casainho | bluebrother: it put the return; now: http://www.flickr.com/photos/43558168@N00/3107580098/sizes/o/ |
15:41:04 | | Quit Horscht (Read error: 110 (Connection timed out)) |
15:41:11 | casainho | bluebrother: I am using a very cheap netbook.. it's my portable where I work while on train (going to work).... |
15:41:27 | casainho | my display is just 1024X600... |
15:42:01 | | Join goffa_ [0] (n=goffa@216.220.23.105) |
15:42:30 | casainho | as you can see, I did put that code of that a and b variables(as static) and now the return; have code!! :-) however, now it do not enter on the if( ....... |
15:44:06 | | Join Horscht [0] (n=Horscht@p4FD4D212.dip.t-dialin.net) |
15:46:53 | bluebrother | well, wasn't l != NULL before? Is that still true? |
15:48:05 | bluebrother | on such a small display I'd recommend to at least hide all unused stuff. I bet you don't use the "Console" window at the bottom ... |
15:48:38 | | Join MethoS-- [0] (n=clemens@host-091-097-240-238.ewe-ip-backbone.de) |
15:49:12 | casainho | bluebrother: I didn't change nothing unless adding that 2 variables.... |
15:49:55 | casainho | so, I don't really understand that "l" having different values... nor the gcc build or not the return; |
15:50:15 | casainho | well, about "l", can I have problems with memory, SDRAM? |
15:50:51 | Llorean | casainho: Does l have different values? |
15:50:57 | Llorean | I thought both times it was not equal to NULL |
15:51:19 | Llorean | Was it ever NULL? |
15:51:41 | casainho | no, looks not is never NULL... |
15:52:12 | Llorean | So, it's not supposed to enter the if, is it? |
15:52:15 | casainho | so, I am assuming now that piece of code is ok |
15:52:59 | casainho | yes, not supossed, but before was entering!!! as the same as the return; not having code for it (can be seen on disassembled window) |
15:53:03 | * | domonoky has now working buttons on e200v2 ! but they are a bit ugly (need to disable ints while writing to the lcd) and it looks like the lcd-driver is not completly working.. |
15:53:03 | | Quit goffa (Read error: 110 (Connection timed out)) |
15:55:14 | bertrik | domonoky, nice to hear. BTW did your shutdown problems on the m200v4 get resolved? |
15:55:56 | bluebrother | casainho: you sure it wasn't just a visual issue? It's perfectly possible there is some asm that is in fact used from outside the if(), but as the debugger doesn't know about this it might display running into the if part |
15:56:13 | domonoky | bertrik: no i still have those shutdown problems, but i now know, that they are clearly related to the volume. (if i limit the volume to -6DB, not shutdowns oocur) |
15:56:28 | | Quit MethoS- (Read error: 145 (Connection timed out)) |
15:56:38 | bluebrother | you should check the code when the issue appears, and try to get a longer asm display from that point. Especially what happened before. |
15:57:27 | * | domonoky confirms that the lcd_update_rect for e200v2 is buggy. if i replace it with a lcd_update, all is fine :-) |
15:57:39 | casainho | bluebrother: I am almost sure, since I am testing and doing a few times the same thing. Anyway, I am having strange problems on this piece of code... like after that if, PC goes to 0x10... looks like some interrupt but I don't know what is... |
15:58:06 | | Join mc2739 [0] (n=mc2739@cpe-67-10-238-175.satx.res.rr.com) |
15:58:14 | kugel | domonoky: look at my lcd driver for fuze cleanup / fixup, some of it may apply to e200v2 lcd driver too |
15:58:26 | bertrik | domonoky, there is a FS patch for e200v2 display |
15:58:50 | bertrik | FS #9569 |
15:58:56 | domonoky | kugel: i want to first solve the button problem completly then lcd improvements can come. |
15:58:58 | kugel | FS #9623 |
15:59:15 | casainho | bluebrother: do you know what is address 0x10? what inetrreput? |
15:59:16 | kugel | domonoky: you said lcd_update_rect is buggy... |
15:59:31 | kugel | domonoky: would be nice if you could hand me a diff, so I can try on my fuze |
16:00 |
16:00:16 | bluebrother | casainho: no idea what's at 0x10. Anyway, I'm a bit surprised you have issues with kernel code. If that happens I'd rather suspect the hardware setup than the kernel |
16:00:53 | | Quit {phoenix} (Remote closed the connection) |
16:01:04 | casainho | bluebrother: yes, maybe I am having problems with memory... like bad configurations of stack or something like that |
16:02:12 | bluebrother | I don't think recent ports were required to change anything with that part of the code. |
16:02:17 | casainho | now I will try to find if some interrupt did happen, reading the "Advanced Interrupt Controller" registers :-) |
16:02:19 | | Quit mc2739 (Client Quit) |
16:06:41 | domonoky | kugel: FS #9639 |
16:12:29 | | Quit tessarakt ("Client exiting") |
16:14:54 | moos | woot, nice works domonoky! |
16:15:22 | | Quit einhirn (Read error: 110 (Connection timed out)) |
16:17:25 | | Join Jaykay [0] (n=chatzill@p579E7209.dip.t-dialin.net) |
16:24:27 | | Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) |
16:25:28 | kugel | domonoky: indeed, no wonder that the reset of buttons didn't work. Unfortunately I didn't know myself that you need to (1<<X) to set the pins a few days ago |
16:25:39 | | Join tessarakt [0] (n=jens@e180071080.adsl.alicedsl.de) |
16:26:09 | kugel | domonoky: do you have the rec button? |
16:26:36 | J-23 | what about wheel? |
16:26:36 | domonoky | kugel: no, on which pin is the rec button ? |
16:26:52 | * | domonoky leaves the wheel for J-23 :-) |
16:27:00 | kugel | I don't know. I just know that the home button is unknown on the fuze |
16:27:28 | casainho | bluebrother: I found that my code is interrupting... with "Data Abort".... something about MMU.... |
16:27:53 | kugel | I assume the home is also on GPIO B or C (rather B, since power button is also on b, and both home and power are directly attached to the main board) |
16:28:18 | kugel | and I assume, given the existing parallels, that REC isn't too different from home |
16:29:16 | domonoky | yes, rec and home a probably similar connected. |
16:29:26 | | Quit FOAD (Read error: 104 (Connection reset by peer)) |
16:29:49 | | Join FOAD [0] (n=dok@dinah.blub.net) |
16:30:33 | J-23 | What about scrollwheel? Still nothing? |
16:30:49 | kugel | J-23: tell us how to read the wheel, then we can do something :) |
16:31:12 | domonoky | J-23: if you want progess on the wheel, wok on it. Asking about status is useless ! |
16:31:20 | kugel | exactly |
16:31:56 | | Quit EspeonEefi ("ã•ã‚ˆãªã‚‰") |
16:35:00 | | Join ZincAlloy [0] (n=d9eef7e0@gateway/web/cgi-irc/labb.contactor.se/x-742c0ce90081e852) |
16:38:03 | *** | Saving seen data "./dancer.seen" |
16:51:13 | | Quit mofux (Remote closed the connection) |
16:51:26 | | Join soap_ [0] (n=David_Ha@rockbox/staff/soap) |
16:51:57 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
16:54:27 | domonoky | kugel: did you have any luck reading from the i2c on fuze ? |
17:00 |
17:00:51 | | Join gregzx [0] (n=chatzill@dsd166.neoplus.adsl.tpnet.pl) |
17:02:18 | | Quit Thundercloud (Read error: 54 (Connection reset by peer)) |
17:06:54 | | Quit moos ("Rockbox rules the DAP world") |
17:07:31 | | Join moos [0] (i=moos@rockbox/staff/moos) |
17:08:28 | | Quit moos (Client Quit) |
17:08:30 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
17:08:39 | | Join moos [0] (i=moos@rockbox/staff/moos) |
17:09:04 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
17:13:15 | kugel | domonoky: not at allö |
17:14:21 | kugel | domonoky: what's more likely? a button (given that it's a tick task) operation or a lcd operation? |
17:14:51 | | Quit culture (Read error: 104 (Connection reset by peer)) |
17:14:58 | kugel | I think button, so it'd be better to set the afsels in the lcd driver when it needs them, and not in the button dirver |
17:15:50 | Unhelpful | kugel: #9631 is looking pretty ugly :/ i can duplicate on e200, but not sim, same as the others... so we only have an address somewhere in the line scaler. |
17:16:02 | domonoky | i am not sure. But it shouldnt matter if we make sure we are not interrupted while writing to the lcd. |
17:17:15 | kugel | domonoky: I also think the disable/enable irq should guard the exported funcs (update(_rect), lcd enable), and not the write_reg/_cmd funcs |
17:17:33 | kugel | I'm gonna just try, but first I'll adapt yours to fuze |
17:17:57 | domonoky | kugel: the dis/enabling of the interrupts is a bad hack. We probably delay the tick too much then. |
17:18:26 | kugel | it's not a bad hack if it's required imho. I've seen several places where interrupts are enabled/disabled in drivers |
17:19:11 | domonoky | but i am not sure how to solve this correctly. if we disable the interrupts too long, timing goes bad. and on the other side, we cant block/wait in the button code, as this is interrupt_context... |
17:19:14 | kugel | domonoky: if we skip a button tick, it doesn't hurt, as long as int_btn isn't reset in-between |
17:20:06 | domonoky | kugel: very shortly disabling interrupts is ok, but a full lcd_update probably takes too long. |
17:20:14 | | Quit tvelocity (Read error: 113 (No route to host)) |
17:20:45 | kugel | well, the lcd driver could set a flag if it's running, and the button driver returns without doing anything if the flag is set. This way timings shouldn't get confused and the buttons don't disturb the lcd |
17:20:47 | | Join tvelocity [0] (n=tony@adsl6-151.her.forthnet.gr) |
17:21:45 | kugel | domonoky: it's 1 slightly larger interrupt instead of massive very short ones. |
17:22:06 | kugel | interrupt disable* |
17:22:29 | domonoky | kugel: yes, and then you delay/miss other interrupts.. |
17:22:33 | kugel | I'm not sure if a lcd_update should be allowed to be interrupted by the buttons, especially since the buttons clear lcd data |
17:22:48 | domonoky | but just not doing anything while lcd_ is activ could be working.. |
17:23:35 | domonoky | but needs some tests, to see if we then dont miss buttons.. (i dont know how long a ful lcd_update() runs) .. |
17:24:06 | kugel | domonoky: do you think with a flag (bool lcd_is_doing_something) we can avoid disabling interrupts? |
17:24:22 | domonoky | kugel: it works, and we dont clear lcd data. we clear left over signals on the gpio_pins. |
17:24:50 | kugel | and that doesn't hurt the lcd if it's cleared within a lcd operation? |
17:25:02 | domonoky | the "flag" should be working. but the flag should probably be a mutex or alike.. |
17:25:17 | | Join {phoenix} [0] (n=dirk@p54B44DE2.dip.t-dialin.net) |
17:25:38 | domonoky | kugel: no. we clear it between operations... not while a transfer is running. |
17:25:40 | kugel | yea, I tried mutexing too. I'm not sure if it works, since I was always clearing the gpio pins wrongly |
17:26:04 | | Quit Jaykay (Read error: 104 (Connection reset by peer)) |
17:26:23 | domonoky | be carefull, that such a lcd_mutex should only be checked in the button_int() and not locked (mutex_lock) |
17:27:04 | domonoky | if you block in a interrupt context. bad things can happen :-) |
17:28:44 | kugel | so, we could mutex lcd_update etc, and let button_int return if the mutex is locked? |
17:29:26 | domonoky | yes, should work.. |
17:29:33 | | Join Jaykay [0] (n=chatzill@p579E7209.dip.t-dialin.net) |
17:30:19 | domonoky | but perhaps its better to only protect the actual register write functions, as the its less likely to miss buttons. |
17:31:05 | n1s | yes, interrupts should be disabled for as short time as possible |
17:31:08 | kugel | I doubt missing buttons will be a problem, but we'll see |
17:35:38 | | Quit Jaykay (Read error: 104 (Connection reset by peer)) |
17:39:40 | n1s | Unhelpful: couldn't (unsigned int)src->width lead to an unaligned access if width is a short? or does it only cast the short to an uint(?) |
17:40:36 | Unhelpful | hrm, i honestly don't know much about alignment needs. x86 doesn't care. :/ |
17:40:59 | n1s | which is probably why it works in the sim :) |
17:41:35 | Unhelpful | yes, that occurs to me as well. the cast is there to clear up a signed/unsigned comparison warning. and also, that's not where it happens. |
17:42:28 | Unhelpful | the h_scaler functions calculate a scaled output line from an input line, and optionally replace what's in the output buffer or add to it |
17:42:43 | Unhelpful | and it's the conditional load for the add that is causing the abort. |
17:43:15 | n1s | but is there any reason for the struct dim members to not be unsigned ints? |
17:44:12 | Unhelpful | no. other than they already weren't, when i came in... also, i think that the bitmap file dimensions are at some point stored in a struct dim, and they're signed (-height means something) |
17:44:22 | Unhelpful | i think i might see the problem, though. |
17:45:01 | Unhelpful | if somebody can say what alignment requirements are, anyway |
17:45:33 | n1s | on arm and sh a var needs to be aligned ot its size |
17:45:33 | Unhelpful | the scratch buffer of uint32 is taken from the end of the output buffer, which is uint16 on color |
17:45:38 | Unhelpful | right. |
17:46:04 | Unhelpful | ...oh, it's happening at the read because it's the first access, not because the write is OK. duh. |
17:46:37 | | Join webguest48 [0] (n=d0bd77d7@gateway/web/cgi-irc/labb.contactor.se/x-5b70fcb277924725) |
17:46:48 | Unhelpful | ok, what i need to do is calculate the needed buffer w/ enough pad to be able to align it, and then align the buffer on a 4-byte boundary before the scaler uses it |
17:48:21 | webguest48 | l have a problem with my ipod nano |
17:48:25 | n1s | many places that allocate buffers already does this but it's usually just a (size+3)&~3 |
17:49:26 | Unhelpful | n1s: but, if the buffer start is 4-byte aligned, and then we put <oddnr>*<oddnr> uint16 after it, we guarantee that the scratch buffer is unaligned ;) |
17:49:32 | Unhelpful | hence the "fails on odd sizes" |
17:49:44 | n1s | Unhelpful: btw, if the loop in scale_h_area is ever time critical, 2 conditionals can be saved. |
17:49:51 | kugel | domonoky: does the sequence with which you read the pins matter? |
17:49:54 | gevaerts | webguest48: you need to tell us what sort of problem it is :) |
17:50:19 | Unhelpful | n1s: enclose the accumulate-or-store in a single conditional, you mean? |
17:50:25 | domonoky | kugel: not after i added a delay before reading the buttons :-) |
17:50:30 | n1s | Unhelpful: yes |
17:50:32 | webguest48 | well it was working fine but then it refuses to turn on |
17:50:54 | Unhelpful | it's on my list of things to try, but it runs many kpix/sec on 80MHz ARM already ;) |
17:50:58 | kugel | domonoky: yay, buttons work! |
17:51:00 | webguest48 | i have tried plugging it in, and holding menu and select for 10 sec. |
17:51:04 | kugel | lcd is acting weird though |
17:51:24 | n1s | Unhelpful: if you are using the buffer in seperate chunks you obviously need to align the pointer to the start of each :) |
17:51:39 | domonoky | kugel: nice. what does the lcd do ? |
17:52:03 | kugel | hard to describe :/ |
17:52:34 | n1s | webguest48: try holdign menu+select for a longer time, up to a minute |
17:52:45 | webguest48 | nls: ok |
17:52:58 | n1s | If that doesn't help leav it plugged in to the charger for a couple of hours and then try again |
17:53:08 | | Quit Llorean (Read error: 104 (Connection reset by peer)) |
17:53:11 | domonoky | kugel: try with lcd_update_rect() just doing a full lcd_update() |
17:53:25 | gevaerts | webguest48: there is a known problem with ipods where they sometimes refuse to start up when the battery is low. In those cases, letting it charge for a long time (like an entire day) usually helps |
17:53:31 | kugel | you added a lcd_update() in update_rect()? |
17:53:51 | webguest48 | thank you i will try it |
17:53:54 | | Join Llorean [0] (n=DarkkOne@adsl-65-68-72-166.dsl.hstntx.swbell.net) |
17:54:10 | domonoky | kugel: yes, just a lcd_update(); return; at the beginning of lcd_update_rect() |
17:54:11 | kugel | domonoky: you made it return before the framebuffer is written, so it's not doing anything |
17:54:51 | kugel | iiuc |
17:55:30 | domonoky | kugel: i dont understand. lcd_update writes the full frambuffer to the lcd. |
17:56:27 | kugel | eh |
17:56:30 | kugel | yea, sorry |
17:56:38 | kugel | it doesn't really help anyway |
17:57:09 | domonoky | then there may be other problems. on e200v2 the lcd works fine this way. |
17:58:39 | | Join PaulJam [0] (n=PaulJam_@vpn-3088.gwdg.de) |
18:00 |
18:00:19 | | Quit soap_ (Read error: 110 (Connection timed out)) |
18:00:21 | kugel | domonoky: hm, disable_irq doesn't seem to work |
18:00:50 | kugel | if I don't include system.h, I get undefined reference (I should only get a warning, but it should compile) |
18:01:22 | domonoky | kugel: strange. maybe pastebin the code in question, so i can take a look ? |
18:01:35 | kugel | the lcd driver |
18:01:43 | kugel | I did the same as you did |
18:01:50 | bertrik | maybe disable_irq is a macro that gets redefined to something that does get linked in system.h |
18:03:06 | | Join stoffel_ [0] (n=sfr@p57B4E3F4.dip.t-dialin.net) |
18:03:17 | | Join Jaykay [0] (n=chatzill@p579E7209.dip.t-dialin.net) |
18:03:18 | | Join blkhawk [0] (n=blkhawk@e179201105.adsl.alicedsl.de) |
18:03:56 | Unhelpful | n1s: not "obvious" to me, at least before now. x86 doesn't care about alignment, nor MMX... only SSE, and there's a special (slower) op for unaligned |
18:04:12 | domonoky | kugel: if you would pastebin the code, i could take a look to see if you missed something, also its better to know about what we are taking... |
18:04:32 | domonoky | and did you check, that the disable_irq really doesnt work ? |
18:04:48 | Jaykay | what does http://www.rockbox.org/tracker/5627 do, is this still neeeded and what is the replacement for lcd-100.c? |
18:05:10 | Jaykay | right i didnt understand the description |
18:05:34 | | Quit kugel (Remote closed the connection) |
18:06:21 | webguest48 | i have already tried holding the menu and select buttions on my ipod for one minute but still no response. |
18:07:14 | webguest48 | this problem has happened before. after a couple of days my ipod somehow gets better by itself. lately it has been happened more often. |
18:07:24 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
18:07:45 | kugel | domonoky: http://pastebin.com/m726d4c6a |
18:08:08 | webguest48 | oh and srry if im butting into anyones conversations ;) |
18:09:21 | kugel | is pastebin.ca broken? |
18:09:44 | martian67 | kugel, use .com |
18:09:47 | martian67 | ca breaks on and off |
18:09:58 | martian67 | some people cant reach it for some reason |
18:10:12 | kugel | lcd_enable is obviously causing crashes |
18:10:32 | domonoky | kugel: code looks ok, are you sure that the disable_irq isnt working ? how did you test it ? |
18:10:45 | kugel | how should I test it= |
18:10:53 | kugel | it doesn't compile without system.h |
18:11:07 | kugel | and system.h *should* only give the prototype, not the function |
18:11:44 | kugel | and since it doesn't compile w/o system.h, I assume system.h gives me a prototype, but the function doesn't work/exist |
18:12:19 | domonoky | kugel: lcd_e200v2.c already did include system.h. it its a macro, so you really need the header.. |
18:12:26 | | Join saratoga [0] (n=41becb3b@gateway/web/cgi-irc/labb.contactor.se/x-6d0d1900c502e4e8) |
18:12:27 | domonoky | see system-arm.h |
18:13:19 | kugel | ok |
18:13:25 | kugel | it's a not-caps macro |
18:13:37 | kugel | good that our code is consistent and reliable :) |
18:14:27 | domonoky | :-) thats probably because of different architectures. On other archs it maybe a function. |
18:15:28 | domonoky | jup. coldfire\system-target has it as a function. |
18:16:42 | | Quit fdinel (Read error: 110 (Connection timed out)) |
18:18:02 | | Quit kharo1 (Read error: 110 (Connection timed out)) |
18:18:54 | kugel | domonoky: it reduces to a function on arm too |
18:18:59 | kugel | anyway |
18:19:15 | kugel | there's code in a header file |
18:19:38 | domonoky | yes, but it has a different name, thats why you get the undefined instruction. |
18:20:03 | | Join kharo [0] (n=teemu@a88-114-255-186.elisa-laajakaista.fi) |
18:20:07 | domonoky | kugel: where ? and its not "inline" code ? |
18:20:26 | kugel | oh, inline |
18:20:32 | kugel | it's inline |
18:20:35 | kugel | but still ;) |
18:20:59 | kugel | Soo |
18:21:03 | kugel | let's see if I have sound |
18:21:07 | * | domonoky sends kugel to some C course :-) |
18:21:47 | kugel | eh |
18:21:50 | kugel | "some sound" |
18:22:08 | * | domonoky cant try sound on e200v2, as i still need the scrollwheel to get to a sound file. |
18:22:16 | | Join Kitti [0] (n=himka_co@195.5.125.25) |
18:22:21 | | Part Kitti |
18:22:53 | kugel | domonoky: you can a) take nvram.bin together with start screen: wps or b) change the keymap file temporary |
18:24:01 | | Quit webguest48 ("CGI:IRC") |
18:24:08 | Unhelpful | n1s: i've a macro in my post-freeze-work branch that calculates "just enough" space for the scaler - i suppose i'd best have that add 3 bytes? |
18:25:00 | kugel | but hey |
18:25:02 | kugel | sound on the fuze |
18:25:08 | kugel | isn't that a great news? |
18:25:25 | kugel | and it even rhymes! |
18:25:26 | * | gevaerts doesn't know. Is it? ;) |
18:25:54 | * | kugel does the "sound on the fuze, a great news, blues" |
18:27:03 | | Join lazka [0] (n=lazka@84-119-69-135.dynamic.xdsl-line.inode.at) |
18:27:23 | lazka | FS #9558, can someone reproduce this? |
18:27:42 | lazka | happens to me quite often. |
18:27:46 | bertrik | kugel, do you get a nice stereo signal, or does it sound a bit echo-y and mono? |
18:28:19 | kugel | bertrik: the sound is gone after 2 seconds (wps shows paused), if I unpause I get "undefined instruction" |
18:29:33 | domonoky | kugel: thats probably the buffering problem. try the flash buffering code |
18:30:26 | kugel | domonoky: maybe, but fuze has 5.5MB of audio buffer |
18:30:39 | kugel | I don't run out of buffer as m200v4 or clip do |
18:31:16 | domonoky | kugel: yes, but we get result.. it maybe worth a try. |
18:31:19 | domonoky | +same |
18:31:37 | kugel | maybe |
18:32:13 | domonoky | or try other formats. perhaps wav works better ? |
18:33:56 | | Quit casainho ("ChatZilla 0.9.84 [Firefox 3.0.4/2008111318]") |
18:34:55 | | Quit agaffney ("reboot") |
18:35:21 | kugel | how do I check if a mutex is locked? |
18:37:13 | kugel | i think I got it |
18:38:04 | *** | Saving seen data "./dancer.seen" |
18:38:20 | kugel | domonoky: hmm, fifo full sounds like your issues |
18:45:50 | | Join agaffney [0] (n=agaffney@gentoo/developer/agaffney) |
18:47:07 | Unhelpful | n1s: that fixed it. thanks, i'd not have found that on my own. :) |
18:55:45 | n1s | happy to help :) |
18:56:33 | Unhelpful | hrm, i missed something with my pure-git svnversion.sh... i don't think there's any "nice" way for a pure-git repo to commit to svn :/ |
18:57:23 | kugel | er |
18:57:39 | kugel | can someone tell me what to do to have up/down go up/down in lists? |
18:57:56 | n1s | hack the keymap |
18:57:57 | kugel | I changed the keymap, but somehow I miss something, since it doesn't work |
18:59:21 | * | domonoky finds this keymap thing very difficult. since you never know which context is used, and the context are chained. if you have a dublicate key use, they wont work. |
19:00 |
19:00:20 | | Quit stoffel_ (Read error: 113 (No route to host)) |
19:00:55 | bertrik | hm, can we maybe add some kind of assertion check for this (only compiled in the sim for example)? |
19:02:12 | bluebrother | ok ... now rbutil translations could get updated. Anyone interested? |
19:03:27 | * | kugel decides to look at other keymaps |
19:06:59 | kugel | ondio keymap seems suitable :) |
19:11:22 | Jaykay | ive got a question to http://www.rockbox.org/tracker/task/5886 : isnt this already implemented (showing current plalist when pressing rec) |
19:12:10 | Jaykay | bluebrother: if you mean add translations, i could help with the german one...... |
19:12:58 | kugel | Jaykay: not that I know |
19:13:20 | Jaykay | kugel: was that in your build? |
19:13:26 | kugel | y.. |
19:13:34 | Jaykay | ah ok.... |
19:13:54 | Jaykay | you see your build was so good i thought it was the normal rockbox ;) |
19:17:39 | | Join Schmogel [0] (n=Miranda@p3EE209E6.dip0.t-ipconnect.de) |
19:18:19 | bluebrother | Jaykay: I just updated that myself ;-) |
19:19:01 | Jaykay | ok^^ |
19:19:12 | bluebrother | but if you want to give it a look and suggest improvements please do so. My translation might be not too user-compatible. |
19:21:41 | Jaykay | bluebrother: since i dont know how to get/compile the current version i can hardly do that^^ |
19:23:46 | kugel | domonoky: any progress on scroll wheel? |
19:24:13 | domonoky | kugel: no, i dont really know where to start with the wheel.. |
19:24:19 | * | kugel fails to edit the keymap probably |
19:24:22 | | Join Lear [0] (i=chatzill@rockbox/developer/lear) |
19:25:58 | kugel | Lear: hey |
19:26:32 | Lear | kugel: Hi. |
19:26:50 | kugel | Lear: there was some talk about http://www.rockbox.org/tracker/task/8523 yesterday and we where wondering about the battery runtime gains of it |
19:31:41 | Lear | kugel: Wasn't much, but there was a difference when someone (perhaps Buschel) compared runtime between WPS screen and a menu. |
19:32:06 | kugel | Lear: it was gevaerts and he reported 15% ;) |
19:33:15 | gevaerts | Was it that much? |
19:33:33 | kugel | according to your comment, yes |
19:34:14 | * | gevaerts finds it again :) |
19:34:26 | kugel | wow |
19:34:38 | * | kugel just can't manage to make up/down do up/down in lists |
19:34:39 | n1s | I like the idea too |
19:34:40 | gevaerts | Anyway that's with the old wps that had peakmeters, so maybe cabbiev2 is better |
19:35:07 | kugel | gevaerts: do you think it's better with album art, conditional viewports and stuff? |
19:35:14 | | Join write_erase [0] (n=Olivier@royale.aixmarseille.com) |
19:35:38 | n1s | kugel: peakmeters take a lot of cpu |
19:35:42 | gevaerts | kugel: I don't think those should make a difference, as they don't change a lot |
19:35:47 | kugel | anyway, it just seems logical that the gui doesn't update if it's not visible, no matter of the difference |
19:36:05 | kugel | by definition |
19:36:36 | write_erase | Hi... I'm new to rockbox, but I could download SVN, compile both toolchain and firmware under FreeBSD in 1 hour without any error... Great job ! a pleasure to work with your source code . |
19:37:55 | | Quit Jaykay (Read error: 104 (Connection reset by peer)) |
19:39:26 | write_erase | Where is the code that handle serial remote control please? |
19:39:43 | rasher | write_erase: We don't often hear from people who get it all right - happy to hear from one |
19:40:23 | write_erase | I was really surprised too ! |
19:40:40 | rasher | write_erase: Do you mean for the iPod |
19:40:45 | kugel | Unhelpful: your "remove unneeded check" diff looks a bit weird to me |
19:41:03 | kugel | where did you remove a check at all? |
19:41:33 | write_erase | rasher, I'll add serial support for Ipod as low level driver is missing IIRC?, but is there some generic serial support for rockbox ? |
19:41:44 | Unhelpful | kugel: that's because git-svn was committing two local diffs, and just took the message from the second :/ |
19:42:08 | kugel | git :S |
19:42:22 | kugel | it's apparently causing much trouble lately |
19:42:25 | rasher | write_erase: You might want to have a look at http://www.rockbox.org/tracker/task/8624 |
19:42:32 | | Join Jaykay [0] (n=chatzill@p579E7209.dip.t-dialin.net) |
19:43:08 | * | bluebrother has git working fine |
19:43:23 | kugel | it's so rigged. I copy from ondio, and it just doesn't go down when I press down |
19:43:51 | write_erase | rasher, ok that's a good starting point. thx |
19:44:43 | Unhelpful | kugel: the first commit introduced the buffer_align, the second moved the test into the #if block... probably i should just always make it unconditional, it's less code anyway. |
19:46:17 | write_erase | rasher, I was looking for a generic serial protocol working on all targets that allow things like (listing files, play,stop, next, show time, next track.... etc) |
19:47:19 | rasher | write_erase: No idea. |
19:48:19 | write_erase | Thx rasher |
19:48:35 | | Quit Aurix_Lexico (Read error: 110 (Connection timed out)) |
19:49:02 | Llorean | write_erase: There couldn't really be a generic one, since the remotes only respond to the protocol they know. |
19:49:09 | Llorean | Different hardware will need differences. |
19:49:22 | Unhelpful | bluebrother: it works better if you dcommit, apparently. |
19:49:48 | Unhelpful | i just don't really want to pollute svn with a million microcommits, some of which i *know* to be broken. |
19:49:55 | | Quit ZincAlloy ("CGI:IRC (Ping timeout)") |
19:49:56 | | Join mc2739 [0] (n=mc2739@cpe-67-10-238-175.satx.res.rr.com) |
19:50:56 | mc2739 | domonoky: \o/ - Great work on e200v2 buttons!! |
19:51:49 | bluebrother | Unhelpful: I usually cherry-pick -n the commits I want to commit to master, then git reset and create a new commit on top of that |
19:52:12 | write_erase | Llorean, i don't plan to use a IPod remote control... In fact I'll be a uControler that will decode wheel buttons of my car, and translate them to rockbox serial orders. |
19:52:31 | | Quit Jaykay (Remote closed the connection) |
19:53:13 | Unhelpful | bluebrother: ah... i sync master to svn, and use commit-diff master <branch> for my work branch... |
19:53:18 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
19:53:28 | rasher | write_erase: I'm not sure there *is* a serial protocol |
19:53:33 | rasher | But I could be wrong |
19:53:48 | bluebrother | hehe ... I never understood the docs for commit-diff completely, so I kept hands of it ;-) |
19:53:54 | write_erase | rasher, maybe it's time to add one . |
19:54:38 | Unhelpful | bluebrother: it commits the diff between two branches as a revision, pretty much exactly the thing that i have needed *so far*, but i'm probably going to have a few chunks to submit after freeze |
19:55:34 | kugel | mc2739: would you volunteer to create a keymap which only uses the buttons which work now? I fail hard |
19:56:06 | kugel | to at least enable us to browse, e.g. to the debug screen |
19:57:29 | mc2739 | kugel: I can try, although I am not to familiar with the keymaps |
20:00 |
20:01:05 | kugel | mc2739: I have tried to copy from c200 keymap (which is similar and uses up/down to go up/down in list) and ondio (which has similar little buttons) |
20:01:19 | kugel | it just doesn't work, I cannot figure out why |
20:02:26 | | Quit saratoga ("CGI:IRC (EOF)") |
20:02:55 | | Join EspeonEefi [0] (i=eefi@SAFFRONCITY.MIT.EDU) |
20:06:04 | | Quit killan ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") |
20:08:06 | | Quit XavierGr (Nick collision from services.) |
20:08:17 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
20:09:57 | mc2739 | kugel: did you have patch to fix the button light? |
20:10:30 | kugel | mc2739: not a patch, but I can make one |
20:10:45 | kugel | but it's probably a wrong fix |
20:11:03 | kugel | but I would rather get buttons working completely before buttonlight, really |
20:11:46 | mc2739 | it's not really important, I just remember you mentioning it |
20:12:52 | mc2739 | btw, posted a patch for e200 radio - FS #9641 |
20:15:14 | | Join killan [0] (n=nnscript@c-415472d5.06-397-67626721.cust.bredbandsbolaget.se) |
20:17:09 | | Quit jhulst (Remote closed the connection) |
20:17:10 | | Join karashata [0] (n=karashat@69.41.192.215) |
20:18:09 | | Quit write_erase (Read error: 113 (No route to host)) |
20:18:23 | | Quit martian67 ("gone") |
20:19:45 | | Join martian67 [0] (i=lol3izer@about/linux/regular/martian67) |
20:37:16 | | Quit EspeonEefi ("ã•ã‚ˆãªã‚‰") |
20:38:05 | *** | Saving seen data "./dancer.seen" |
20:42:46 | | Quit moos ("Allez l' OM") |
20:46:55 | | Join Jaykay [0] (n=chatzill@p579E7209.dip.t-dialin.net) |
20:50:44 | | Quit Lear ("ChatZilla 0.9.84 [Firefox 3.0.4/2008102920]") |
20:56:52 | * | Jaykay is breaking the silence another time |
20:57:06 | Jaykay | ive got some new patches to close (surely i only suggest closing them) |
20:57:56 | Jaykay | http://www.rockbox.org/tracker/5134 - multiplayer tetris. this is IMHO out-dated and looks like.... well, it looks worst. |
20:58:33 | Jaykay | http://www.rockbox.org/tracker/5192, qoute from first and last comment: "well i was going to do this, but got bored... attached is a start if anyone wants to finish it" |
20:59:30 | Jaykay | http://www.rockbox.org/tracker/5448 as the author says there is something unstable in it, and IMHO the radios are working fine |
21:00 |
21:00:14 | Jaykay | http://www.rockbox.org/tracker/5627 a question, not a suggestion: what does it do? but the second file the patch modifies does not exist. |
21:00:55 | Jaykay | the last one:http://www.rockbox.org/tracker/5641 costom keyboard: IMHO the keyboard is really good, and each hunk failes when patching. |
21:01:01 | Jaykay | http://www.rockbox.org/tracker/5641 |
21:01:11 | Jaykay | this was it |
21:02:06 | | Join jrsharp [0] (n=jrsharp@c-98-193-244-253.hsd1.tn.comcast.net) |
21:02:10 | jrsharp | hey all |
21:02:47 | jrsharp | anyone know the current status of the TTS project? the wiki page seems a bit stale |
21:03:11 | jrsharp | (http://www.rockbox.org/twiki/bin/view/Main/TextToSpeech) |
21:03:19 | kugel | mc2739: any success with the button keymap? |
21:03:46 | kugel | getting in the debug screen would really be helpful to watch gpio ports |
21:04:13 | kugel | unless it's not implemented yet |
21:04:16 | rasher | jrsharp: the student basically vanished, afaik |
21:05:15 | rasher | jrsharp: nothing much came from it - FS #7660 might interest you |
21:05:19 | jrsharp | rasher: ok, well, that's too bad |
21:06:12 | jrsharp | ah, 7660 is interesting |
21:06:12 | | Quit gevaerts (Nick collision from services.) |
21:06:21 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
21:07:12 | jrsharp | I'm exploring whether rockbox would be a good potential platform for an audio game I'm interested in developing |
21:07:14 | Llorean | Jaykay: As I've suggested before, you're much, much better off suggesting them to the -dev mailing list. |
21:07:24 | jrsharp | and the speech piece is interesting to me |
21:07:44 | Jaykay | llorean: did you? im sorry |
21:08:32 | mc2739 | kugel: not yet, still working on it |
21:09:31 | Jaykay | Llorean: so i should write to rockbox-dev@cool.haxx.se? |
21:09:59 | | Join petur [50] (n=petur@rockbox/developer/petur) |
21:12:16 | jrsharp | is the current use of the precompiled voice files in the firmware well documented from a developer standpoint? |
21:12:40 | jrsharp | could I use precompiled voice files in a plugin? |
21:12:54 | rasher | jrsharp: not currently, but it's planned |
21:12:55 | jrsharp | in lieu of actual TTS on the device |
21:13:05 | rasher | I think someone was/is even working on it |
21:13:25 | jrsharp | rasher: the docs? or using files in a plugin? |
21:13:27 | Unhelpful | try searching flyspray, there may be a patch there already, if somebody's working on it. |
21:13:44 | rasher | jrsharp: Using voiceui from a plugin |
21:13:48 | jrsharp | ok |
21:14:05 | rasher | FS #9067 |
21:14:07 | Unhelpful | rasher: i take it there's more to it than *just* putting it in the API? |
21:14:42 | rasher | Unhelpful: Yeah, we also don't want to load voiceclips for all plugins unconditionally |
21:15:51 | Unhelpful | it's never simple :/ |
21:16:00 | jrsharp | heh |
21:16:54 | Unhelpful | i've got some bitmap manipulation macros that i think might be useful in plugins... i guess i need to find the right place under firmware/export to put them in a header? |
21:16:59 | jrsharp | ok, so speech in plugins would be great for my audio game idea, but not necessarily critical, if I have access to some other audio api that does the trick (plays pcm audio, etc.) |
21:17:07 | jrsharp | is such an audio api available in plugins? |
21:17:58 | rasher | jrsharp: You can play pcm sound afaik |
21:18:00 | jrsharp | I haven't been able to find much on that yet |
21:18:16 | rasher | Developer docs is not really Rockbox' strongest side |
21:18:17 | Unhelpful | jrsharp: yes, it's already possible to stop playback and play your own sounds from plugins - the doom port at least does this, i can't say which other games have sound. |
21:18:44 | rasher | The midi plugin |
21:18:45 | kugel | Unhelpful: firmware/* is unlikely the correct place for apps/plugin code |
21:18:54 | jrsharp | rasher: as a friend of mine would say, the source is the *ultimate* documentation ;) |
21:19:18 | rasher | Unhelpful: apps/plugins/lib/? |
21:19:37 | jrsharp | thanks, so perhaps I should check the doom code and midi plugin out |
21:20:24 | Unhelpful | rasher: it's not exactly library stuff... it's general-purpose macros for calculating information about native bitmaps, things like padded width or height, total size, etc, based on format and dimensions |
21:20:36 | domonoky | jrsharp: also take a look a plugin.h to see which functions are available to plugins. |
21:20:40 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
21:21:01 | jrsharp | domonoky: yeah, good call |
21:21:01 | rasher | Don't we have plugin-api docs now? |
21:21:09 | rasher | Or is that not set up yet |
21:21:47 | Unhelpful | ie, they're already used in core, they may find uses in plugins, and i suspect wrapping them in actual functions may be wasteful... and also defeat the purpose of having them be compile-time constant if their inputs are. |
21:22:27 | jrsharp | btw, I'm developing this using a 1g ipod nano... is that going to limit me in this area? (I don't see that the midi plugin is installed by default on the nano build... is it because it won't work?) |
21:22:55 | rasher | jrsharp: the midi plugin doesn't show up in the plugin list because it's a "viewer", but the nano is one of the slower targets |
21:23:14 | Unhelpful | they live in apps/recorder/bmp.h now, but i wasn't sure if it would be bad form to have a plugin include that, even after i've macro'd all of its functions. |
21:23:18 | rasher | jrsharp: Probably not important if you get to use the voiceui |
21:23:23 | jrsharp | ah, ok |
21:23:26 | jrsharp | yeah |
21:23:42 | jrsharp | and playing pcm sounds should be fine, if I can figure out the api |
21:24:16 | | Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) |
21:24:40 | Unhelpful | rasher: the last time i looked, the plugin-api docs were not always helpful, especially without prior knowledge of how the exported functions work inside rockbox. |
21:24:43 | domonoky | metronome.c also plays pcm, altough very short ones :-) |
21:25:02 | Unhelpful | but, i've brushed a lot of dust off of my C since i tried to port sbagen, maybe it'd make more sense now |
21:25:32 | jrsharp | domonoky: yeah, thanks |
21:25:53 | | Join toffe82 [0] (n=chatzill@adsl-99-146-80-191.dsl.frs2ca.sbcglobal.net) |
21:26:24 | rasher | Bagder / Zagor: would it be possible to hook up utils/rockbox_api/ to the website? |
21:28:22 | | Join ZincAlloy [0] (n=d9eef7e0@gateway/web/cgi-irc/labb.contactor.se/x-12e13e1814dc24f7) |
21:28:31 | jrsharp | also, does anyone know if I can play multiple sounds at once in a plugin? (background music + sound effects?) |
21:29:00 | Unhelpful | you're going to need to mix them yourself, i'd think |
21:29:40 | rasher | Yup, quite sure this is the case |
21:29:46 | domonoky | rockbox has a mixer (to mix voice and playback) but its probably not exported to plugin. |
21:29:55 | n1s | yes, rockbox does no mixing (except for voice) |
21:30:04 | jrsharp | domonoky: yeah, that's what I was just going to ask |
21:30:58 | jrsharp | so is that mixing feature something that could be extended to support mixing of playback with something other than the voice? |
21:31:12 | jrsharp | or is there something special about the way the voice works |
21:31:51 | n1s | Unhelpful: headers needed by plugins that are not in the plugin lib (or the plugin itself should be included in plugin.h several headers from apps already are |
21:32:27 | n1s | jrsharp: sure it could and may even be a wanted core feature |
21:32:53 | Unhelpful | n1s: and that gets back to the work i was talking about of splitting everything that's just for the loader out - right now, bmp.h also declares functions that plugins can't see. |
21:33:32 | n1s | Unhelpful: i don't think that's a problem as plugins shouldn't call core functions directly |
21:33:56 | | Quit massiveH ("Leaving") |
21:34:08 | jrsharp | n1s: ok, cool... so really, two things would need to happen with the mixer code... 1) support other non-voice data, 2) be exposed through the plugin api... is that right? |
21:35:13 | n1s | jrsharp: i'm not really sure about the details but it sounds about right, jhMikeS is probably the one that knows the pcm code the best |
21:36:05 | Unhelpful | do any of our targets support 24-bit PCM output? 8 bits of overhead can make mixing fairly trivial, just lock the buffer, sum the samples, unlock. |
21:37:11 | n1s | I'm pretty sure we would want something that works on all targets and i think at least some are limited to 16bits |
21:37:12 | * | domonoky thinks that some targets could do 24bit PCM, but rockbox doesnt use it. (too much trouble for too less gain).. |
21:37:15 | Unhelpful | or remove the locks, if adds to memory are atomic? |
21:39:35 | Unhelpful | n1s: i know, it just gets to be nastier if you don't have the overhead. really, a couple of extra bits are enough to let us mix four streams without overflow, but *then* we'd have to scale samples down to 16bit. |
21:40:19 | n1s | i didn't say it was easy :) |
21:42:58 | | Quit bertrik (Read error: 113 (No route to host)) |
21:43:49 | jrsharp | well, it seems to me that from both a hardware and software point-of-view, rockbox would be a reasonable potential platform for deploying pure audio games for visually impaired users |
21:44:27 | jrsharp | you see, I've had this idea for a while, but have been trying to find a device/platform most suitable |
21:44:34 | kugel | domonoky, mc2739: I've been watching all GPIO ports together now, no trace of HOME/REC nor the wheel, nor hold button |
21:45:10 | kugel | I see a trace of our known buttons though |
21:45:20 | jrsharp | now, I understand rockbox isn't trying to be a gaming platform at all, but with the existing support for visually impaired users, I think the potential is there |
21:46:10 | domonoky | kugel: jup, i have done the same on e200v2.. no trace of wheel and rec. |
21:46:15 | jrsharp | can anyone comment on how many rockbox users are blind? |
21:46:43 | gevaerts | I think that's a very hard question to answer |
21:47:40 | kugel | domonoky: that could either mean they're not purely accessible through GPIO (maybe i2c?), or we need to change some pins before (kinda keyscan matrix) |
21:47:41 | jrsharp | yeah, I would imagine... but is it something that is sought after by the blind community? any gauge at all of interest? |
21:47:48 | | Join akur [0] (n=akur@bl7-118-244.dsl.telepac.pt) |
21:47:52 | * | domonoky thinks thats impossible to say. but they are very loud, when we break voice :-) |
21:48:04 | jrsharp | hehe, I bet |
21:48:26 | rasher | Maybe Bagder could tell us how many prebuilt voice files are downloaded, but that's hardly in any way accurate, since many build their own |
21:48:32 | Unhelpful | n1s: your suggestien re: conditionals in resize.c saves binsize too, it looks like. |
21:49:04 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
21:49:16 | domonoky | rasher: and also non-blind users use voice-files ( car usage) |
21:49:28 | jrsharp | right |
21:50:05 | jrsharp | and to that point, I think an audio-only game might be of interest to those users, as well |
21:50:25 | n1s | jrsharp: our blind and visually impaired users seem to prefer the mailing list for communication so maybe you should ask about interest there? |
21:50:39 | domonoky | yes, we even got requests for that.. :-) |
21:50:41 | jrsharp | yeah, that's a good idea |
21:50:45 | Unhelpful | jrsharp: port "be the wumpus", perhaps... we have a "hunt the wumpus" port in-progress from somebody else |
21:50:52 | n1s | Unhelpful: ah, not a big diff i assume |
21:51:04 | domonoky | i once even tried to port such a audio-only game.. but lost interesst. |
21:51:10 | gevaerts | As far as I understand the pre-built voices are not considered to be very good, so I guess that while they may be likely to be used to try rockbox out, people probably only download them once |
21:51:43 | Unhelpful | n1s: 56B on arm, in my postfreeze branch. i've substantially reduced the amount of other calculation on those lines, on my end. |
21:51:54 | Unhelpful | removed entirely, really |
21:52:07 | | Part akur |
21:52:20 | jrsharp | Unhelpful: yeah, I was thinking about the wumpus, actually |
21:52:23 | jrsharp | as a starting point |
21:52:39 | kugel | Jaykay: have you subscribed to the -dev list? Else you won't receive feedback on your mail |
21:53:10 | Jaykay | yes |
21:53:22 | Jaykay | if i did everything right^^ |
21:53:38 | kugel | have you received your own mail? |
21:54:03 | Jaykay | no :) yeah |
21:54:15 | kugel | what? |
21:54:39 | Jaykay | no i didnt recieve my own mail |
21:54:42 | kugel | I got the mail, so if you didn't you apparently did something wrong |
21:55:10 | * | domonoky never gets his own mails when he writes to the rockbox lists.. |
21:55:19 | gevaerts | Isn't that a setting? |
21:55:44 | kugel | if it is, then it defaults to "yes get your own mail", since I never changed it and I get my mails |
21:56:24 | kugel | Jaykay: also, make sure you change the digest mode, so you can each mail seperately, and not some kind of all mails in one |
21:56:31 | rasher | Could depend on when you signed up |
21:56:45 | rasher | (if the defaults changed) |
21:57:31 | Jaykay | i didnt change anything, except the digest mode ( i enabled it since i didnt know what it is and i wanted to receive everything) |
21:57:39 | Jaykay | so should digest mode be enabled? |
21:57:50 | kugel | disabled |
21:58:16 | Jaykay | and the "receive own emails"-setting is enabled, so something is going wrong |
21:58:18 | Jaykay | ok |
21:58:25 | gevaerts | digest means you get one mail every day with everything in it for that day |
21:58:34 | kugel | you receive everything no matter of the digest mode. But if you enabled it you get 1 mail regulary which contains all mails sent in the meantime |
21:58:41 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
21:58:43 | Jaykay | done |
21:58:47 | kugel | and that one is very problematic for answering mails |
21:58:49 | gevaerts | So that would explain not receiving your own mail |
21:58:53 | kugel | and you don't instantly get the mails |
21:58:56 | rasher | I thought you'd only receive the digest? |
21:59:28 | Jaykay | i disabled it and will look on the rockbox-site for the first day ok?^^ |
21:59:45 | gevaerts | That should work :) |
22:00 |
22:00:21 | Jaykay | im back in a minute |
22:00:23 | | Part Jaykay |
22:01:08 | | Quit PaulJam (".") |
22:02:28 | | Join Jaykay [0] (n=chatzill@p579E7209.dip.t-dialin.net) |
22:02:44 | kugel | domonoky: if you're bit familiar with i2c you might try funmans patch |
22:03:12 | kugel | I haven't any luck at all reading buttons with that patch, but it may need some changes |
22:03:26 | * | n1s gets suspicious by finding two newer revisions of the wm8978 datasheet with no version history and the last one is a page shorter than the one i had... |
22:03:37 | domonoky | kugel: where is this patch ? |
22:04:10 | kugel | domonoky: http://paste.ubuntu.com/83975/ |
22:04:59 | kugel | main.c is hacked a bit to show returns of the button driver code |
22:06:39 | | Quit kharo (Read error: 110 (Connection timed out)) |
22:07:15 | | Join Aurix_Lexico [0] (n=comrade@c-68-56-205-239.hsd1.fl.comcast.net) |
22:08:11 | | Nick __lifeless is now known as _lifeless (n=lifeless@90.151.47.169) |
22:08:26 | | Join kharo [0] (n=teemu@a88-114-255-186.elisa-laajakaista.fi) |
22:09:30 | | Part lazka ("cya") |
22:19:27 | | Quit Nico_P (Remote closed the connection) |
22:20:24 | mc2739 | kugel: I think I have a mostly working keymap now |
22:22:24 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
22:25:36 | | Quit Jaykay ("ChatZilla 0.9.84 [Firefox 3.0.4/2008102920]") |
22:25:57 | mc2739 | kugel: seems a little weird compared to what I am used to on the e200, but most functions work |
22:26:48 | | Quit XavierGr (Nick collision from services.) |
22:26:59 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
22:27:19 | kugel | mc2739: Yes? Cool. I still don't get why I couldn't get it to work |
22:27:47 | lucent | Different device, the Sansa Clip (v1), when Rockbox fw asked to initialize the Database, it said "press Play" and then pressing play did not work, but pressing "select" button did work, is the keymap needing an update? |
22:28:10 | | Quit {phoenix} (Remote closed the connection) |
22:28:14 | kugel | probably |
22:28:15 | mc2739 | kugel: http://pastebin.com/m7b4c14d3 - you will need to change some of the keys for the fuze (e200 has no home key) |
22:28:28 | kugel | it's not meant for everyday use. But feel free to contribute patches |
22:28:44 | kugel | mc2739: well, it's the same buttons which work |
22:29:28 | mc2739 | and I also had to comment #define HAVE_SCROLLWHEEL in config-e200v2.h |
22:29:30 | lucent | err, you outright removed someone else's copyright? |
22:30:10 | mc2739 | and the two wheel accel defines |
22:30:12 | kugel | mc2739: really? that could be the cause for my problems |
22:30:32 | mc2739 | possibly so |
22:30:52 | | Nick JdGordon|zzz is now known as JdGordon (n=jonno@rockbox/developer/JdGordon) |
22:31:00 | kugel | lucent: mc2739 seems to do that from time to time (also look at his radio patch) ;) |
22:31:39 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
22:32:35 | kugel | mc2739: the patch is garbage.. |
22:33:07 | kugel | do "svn diff apps/keymaps/keymap-e200.c > file.diff" |
22:34:08 | mc2739 | that's what I did, and then copy/paste to pastebin |
22:34:38 | bertrik | lucent, you're right, that's still a minor bug. It could be fixed, that would require all language files to be updated though |
22:35:22 | lucent | bertrik: language files depend on keymap? |
22:35:52 | rasher | lucent: the language files include the string "Press play" |
22:36:01 | bertrik | IMO, the text should be fixed, not the keymap :) |
22:36:12 | lucent | oh, hah |
22:36:33 | kugel | mc2739: hmm, then pastebin.com sucks |
22:36:57 | kugel | mc2739: but indeed, the SCROLLWHEEL defines are the cause. I got it to work too now |
22:37:09 | mc2739 | ok |
22:38:10 | *** | Saving seen data "./dancer.seen" |
22:39:59 | kugel | hm |
22:40:06 | kugel | music playback doesn't work at all |
22:40:52 | domonoky | kugel: where do we got this i2c address of the mysterious device ? form the OF ? |
22:41:02 | kugel | most likely |
22:41:11 | kugel | funman did some disassembly in the fuze of |
22:43:58 | mc2739 | kugel: what format audio are you testing? |
22:44:04 | kugel | ogg so far |
22:44:41 | mc2739 | I had problems with mp3 and ogg, but flac and wav work reasonbly well |
22:45:11 | mc2739 | s/reasonbly/reasonably/ |
22:45:59 | | Join EspeonEefi [0] (i=eefi@SAFFRONCITY.MIT.EDU) |
22:46:14 | kugel | I regulary get panics |
22:46:38 | lucent | panics I think (guessing here) were due to the SD driver, no? |
22:46:39 | | Quit esthar (Read error: 60 (Operation timed out)) |
22:47:05 | kugel | ohh |
22:47:06 | lucent | at least on my Clip that I've tried with Rockbox, it never worked when accessing data from above 1GB |
22:47:09 | kugel | it works a bit now |
22:47:28 | lucent | that's also a guess |
22:47:40 | kugel | hm |
22:47:42 | lucent | I don't have a solid idea of what is actually happening |
22:47:51 | kugel | I play johnny cash since 1 min now :D |
22:47:58 | lucent | the SD driver needed to be updated to interact with more than 1 bank |
22:48:02 | lucent | :) |
22:49:22 | kugel | domonoky, bertrik: Fuze needs r19407 too |
22:50:37 | | Quit karashata ("G'bye everyone!") |
22:50:46 | bertrik | kugel, ok, so that means it's needed for all known as3525 targets |
22:51:15 | kugel | yep, I claim it's very unlikely to be wrong for c200v2 |
22:51:34 | rasher | lucent: none of the language strings have been modified for the clip, so your issue is pretty expected |
22:51:54 | lucent | rasher: thanks for the detail, it helps :) |
22:52:13 | rasher | PLAY = Yes happens to be the default string used for that if no string specific to that target exists |
22:53:00 | bertrik | we should change that, but maybe wait just a little and then update it for all new targets |
22:53:21 | | Quit jhulst (Remote closed the connection) |
22:53:25 | rasher | and do it in all langfiles... |
22:53:53 | lucent | how are all these little issues tracked for new targets? I didn't see like a wiki page with a list of TODO's for the Clip |
22:54:32 | bertrik | lucent, I think they're not explicitly tracked right, we should probably do so... |
22:55:01 | kugel | So, the panic is "SD: Internal storage: RX OVERRUN, RXR FIFO FULL" |
22:55:16 | kugel | is that the same you get with your clips and m200v4? |
22:55:20 | lucent | kugel: yes! I had that same panic on the Clip :P |
22:55:47 | lucent | kugel: I forgot who said it, but yesterday someone in-channel said that it was due to the SD driver only reading a single bank (whatever that means) |
22:56:02 | | Quit bmbl ("Woah!") |
22:56:04 | lucent | they wanted to look at the issue and maybe fix it, but first needed working buttons on their fuze |
22:56:32 | kugel | lucent: yes, I know what that means |
22:56:41 | kugel | I was the one who said that |
22:56:44 | domonoky | lucent: you speak to the same people as yesterday :-) |
22:56:47 | * | lucent grins |
22:57:20 | lucent | well I put my ski gloves on top of the heater the other night and the melted plastic fumes affect my mind, what can I say about that, oops |
22:57:27 | * | domonoky made the buttons working, so its now kugels turn for the sd-bank switching :-) |
22:57:52 | kugel | domonoky: now the question is why I can't stay in the wps (the button that leads to the menu seems to be triggered somehow) |
22:58:05 | kugel | and why the lcd still does weird things |
22:58:20 | kugel | but with some buttons I can surely work on it |
22:58:33 | | Join Chesteta [0] (n=Chesteta@dyn59-068.res-hall.ndsu.NoDak.edu) |
22:58:43 | kugel | domonoky: you didn't get all buttons, so I wont make all banks! :D |
22:58:48 | domonoky | kugel: do you have still the interrupts disabled while doing lcd, or do already use the mutex ? |
22:58:53 | kugel | mutex |
22:58:53 | mc2739 | does the e200v2 need its own sim, or can the v1 sim be used? |
22:59:16 | Unhelpful | any opinions on which might be more maintainable, for porting the HQ scalers to greyscale? i can clone-n-hack all 4 relevant functions, and ifdef around grey vs color versions, or ifdef around the inner-loop math... :/ |
22:59:17 | gevaerts | mc2739: depends. Will the v2 have the same keymap? |
22:59:18 | kugel | mc2739: the same. the sim doesn't take hardware differences into account |
22:59:44 | kugel | gevaerts: yes, the e200v1 and e200v2 have the same keymap (is that suprising)? |
22:59:44 | rasher | kugel: there's still a separate sim though |
22:59:54 | mc2739 | gevaerts: yes |
23:00 |
23:00:20 | domonoky | kugel: maybe the mutex is not working correctly ? you get strange lcd-things and spurious buttons if you interrupt the lcd with buttons. |
23:00:24 | hobbs | is someone here who can give me wiki access? |
23:00:28 | gevaerts | kugel: Not really, but since it's different hardware I wouldn't be surprised by some v1 button combinations not working on the v2 |
23:00:30 | kugel | rasher: seperate by the means of seperate files or that you can configure the same sim by chosing either e200 in configure? |
23:00:50 | kugel | gevaerts: the sim doesn't take such things into account anyway |
23:00:51 | gevaerts | hobbs: sure. What's your wiki account name? |
23:01:00 | hobbs | AndrewRodland |
23:01:06 | gevaerts | kugel: the sim may not, but that may force a different keymap |
23:02:10 | * | kugel learns to appreciate the "now playing"/"resume playback" item in the main menu |
23:02:21 | gevaerts | hobbs: done. Now promise not to spam! :) |
23:02:27 | rasher | Or there could be other hardware differences that leads to different interface. Might as well use the e200v2 sim |
23:02:40 | kugel | and I like the mirrored display in particular |
23:02:41 | | Join mokkurkalve [0] (n=eivind@084202223086.customer.alfanett.no) |
23:02:43 | hobbs | gevaerts: beautiful spam, lovely spam! |
23:03:00 | hobbs | gevaerts: thank you. |
23:03:02 | gevaerts | hobbs: don't push it :) |
23:04:25 | kugel | domonoky: I check mutex.locked before reading buttons |
23:04:42 | kugel | maybe it's not working correctly, but I haven't really had other results with irq disabling |
23:04:56 | | Quit petur ("Zzzz") |
23:05:46 | | Part mokkurkalve |
23:07:47 | domonoky | you also got strange lcd, with interrupts disabled while lcd-transfers ? |
23:08:07 | kugel | yep |
23:09:15 | domonoky | so there maybe something else with your lcd-driver.. |
23:09:40 | | Join Thundercloud [0] (n=thunderc@cpc3-hem18-0-0-cust53.lutn.cable.ntl.com) |
23:10:13 | kugel | probably |
23:11:25 | * | Unhelpful would kill for operator overloading in C, or at least being able to manipulate aggregates all of one type as vectors :/ |
23:11:50 | kugel | Unhelpful: me too |
23:11:51 | Unhelpful | i could then just typedef or define types for the color variables in the scaler |
23:12:36 | * | gevaerts would kill to keep operator overloading out of C :) |
23:13:22 | Unhelpful | kugel: if you're blitting YUV to an RGB surface, you will probably need to scale the U/V channels, which may be 1/2 the dimension of the Y in one or both directions, depending on format |
23:13:42 | * | rasher thinks http://www.rockbox.org/twiki/bin/view/Main/DeviceChart needs updating with some of the new targets |
23:13:56 | Unhelpful | gevaerts: doing that has been bad for Java, i'd say, but then, C isn't OO. |
23:13:58 | kugel | Unhelpful: Ok, I see, I'll come back to you once it's relevant :) |
23:14:25 | Unhelpful | but really, being able to define +, -, * and / for structs or whatnot would be a bad thing? |
23:14:35 | | Quit domonoky (Read error: 104 (Connection reset by peer)) |
23:15:00 | gevaerts | Unhelpful: yes |
23:15:11 | gevaerts | OT though :) |
23:15:20 | * | kugel expected no-one else to disagree first |
23:15:46 | hobbs | voila. Thank you gevaerts. If anyone has a gigabeat and some ambition, kindly test, comment on, or improve http://www.rockbox.org/twiki/bin/view/Main/WpsGigabeatF#Breeze :) |
23:16:10 | Unhelpful | gevaerts: only slightly. it would save the scaler from becoming #ifdef hell to support color-or-grey per target |
23:16:38 | kugel | Unhelpful: some times it's better to split files instead of creating #ifdef hell |
23:17:54 | Unhelpful | kugel: i can #ifdef the whole inner loop body instead of each manipulation - it just seems like there's a *lot* of common code, to talk about forking it. |
23:18:16 | kugel | forking is an evil word :) |
23:18:47 | | Quit Chesteta (Read error: 110 (Connection timed out)) |
23:19:06 | Unhelpful | yes, but it's what's being done, and the further apart the color and grey versions are, the more likely somebody updates one, and not the other. |
23:20:31 | rasher | hobbs: I don't own a gigabeat, so I haven't seen it on target, but maybe a slightly more obvious gradient for the background would make it seem less flat. And perhaps a larger progressbar |
23:21:12 | hobbs | rasher: I had a bit more of a gradient, but the LCD seems to exaggerate the colors a little bit. The bright part looks brighter on the real deal. |
23:22:19 | hobbs | that and I don't mind flat, but I shall keep it in mind :) |
23:22:38 | | Quit kharo ("Leaving.") |
23:23:09 | | Join moos [0] (i=moos@rockbox/staff/moos) |
23:25:19 | * | Unhelpful thinks that #ifdef-cloning the inner-loop body is probably the right way to go |
23:26:27 | Unhelpful | i'd like doing that better if the whole thing fit on one screen, though, so that it was blatant that edits ought to be duplicated in both versions |
23:26:50 | kugel | ehh |
23:27:04 | kugel | domonoky gone? |
23:28:49 | kugel | mc2739: I get a much more reliable lcd with only setting afsel & dir for the buttons we need, not the entire port |
23:29:29 | mc2739 | kugel: thanks, I'll try that here |
23:31:40 | kugel | hm |
23:31:43 | kugel | pretty nice now |
23:31:49 | kugel | I think I can upload that |
23:32:03 | | Join gregzx_ [0] (n=chatzill@aaul252.neoplus.adsl.tpnet.pl) |
23:32:33 | | Quit gregzx (Nick collision from services.) |
23:32:37 | | Nick gregzx_ is now known as gregzx (n=chatzill@aaul252.neoplus.adsl.tpnet.pl) |
23:34:45 | lucent | rasher: I could try updating that Wiki page, is the information gathered just from official product manuals? |
23:35:53 | n1s | lucent: more like information gathered from reality :) (by lookign at the actual players, it's mainly about hw capabilities anyway) |
23:36:09 | rasher | lucent: mostly, I think. And common knowledge. Don't be afraid of getting hit with [citation needed] |
23:36:20 | rasher | As long as the information is true, it's cool |
23:37:05 | * | n1s spots errors in that page |
23:39:42 | n1s | is the m3 considered "supported" ? |
23:40:10 | Bagder | I think so |
23:40:11 | kugel | hmmm |
23:40:19 | kugel | rockbox doesn't see my microsd :( |
23:40:44 | n1s | Bagder: ah, no 3.0 on the download page for m3 so i guess "no" :) |
23:40:51 | pixelma | not sure about the M3 as it needs this nasty trick for charging |
23:41:02 | Bagder | hm, well that's because we have no manual and that charging thing |
23:41:05 | pixelma | and no manual |
23:41:24 | | Join Davide-NYC [0] (n=chatzill@68.161.224.151) |
23:41:57 | * | pixelma actually started that but hit some problems with listing the remote and main target keymapping |
23:42:22 | Davide-NYC | hello all, what exactly does this error mean while I try to compile a sansa clip simulator under cygwin |
23:42:32 | Davide-NYC | CC apps/keymaps/keymap-clip.c |
23:42:34 | Davide-NYC | make: *** No rule to make target `/home/Administrator/rockbox/sim.olip/uisimulator/sdl/button.o', needed by `/home/Administrator/rockbox/sim.clip/uisimulator/libuisimulator.a'. Stop. |
23:43:02 | | Join gromit` [0] (n=gromit@ALagny-154-1-50-16.w81-249.abo.wanadoo.fr) |
23:43:09 | Davide-NYC | is the problem in button.o or libuisimulator.a? |
23:43:36 | lucent | it means button.o doesn't exist or is not linkable, and there's no Makefile target that would produce it |
23:44:06 | lucent | ;away |
23:44:21 | lucent | my mistake, mischat I meant to type an IRC command /away |
23:44:28 | pixelma | Davide-NYC: did you try make clean and run configure again? |
23:44:59 | Davide-NYC | pixelma: I did but in the opposite order |
23:45:01 | kugel | bertrik: do you have a copy of the flash buffer patch which produces less warnings? |
23:45:18 | bertrik | no |
23:46:29 | lucent | gevaerts: I'd like to contribute to the Wiki as mentioned, my username is EricShattow |
23:46:51 | lucent | kugel: FS9332 |
23:46:58 | lucent | that's the flash buffer patch FYI in case anyone needs it |
23:47:16 | kugel | the flash buffer patch doesn't work better at all on my fuze |
23:47:20 | kugel | worse rather |
23:48:37 | pixelma | Davide-NYC: going to try too |
23:49:38 | | Quit GodEater (Remote closed the connection) |
23:49:38 | | Quit perrikwp (Remote closed the connection) |
23:50:04 | | Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-68daf57eab7060e3) |
23:50:05 | | Quit perrikwp (Remote closed the connection) |
23:51:29 | | Join kompulsa_dot_com [0] (n=nicholas@72.252.29.2) |
23:52:03 | | Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-f8b1a1e4006be43e) |
23:52:03 | | Nick kompulsa_dot_com is now known as Tetracomm (n=nicholas@72.252.29.2) |
23:52:10 | mcuelenaere | rasher: shouldn't if [ "wiki" == "$1" ] in tools/langstatus be if [ "wiki" = "$1" ] ? |
23:52:25 | | Quit markun (Connection reset by peer) |
23:52:27 | Davide-NYC | pixelma: there's a typo somewhere |
23:52:40 | | Join markun [50] (n=markun@rockbox/developer/markun) |
23:52:46 | rasher | mcuelenaere: right, bashism :( |
23:52:52 | mcuelenaere | :) |
23:52:55 | mcuelenaere | shall I commit the fix? |
23:53:01 | rasher | Feel free |
23:53:05 | mcuelenaere | ok |
23:54:41 | | Join GodEater [0] (i=c2cbc962@gateway/web/ajax/mibbit.com/x-a9b5544770d64000) |
23:55:07 | lucent | mcuelenaere: IMO the style I like to use is 'if [ "zwiki" = "z$1" ]' |
23:55:27 | Davide-NYC | pixelma: /home/Administrator/rockbox/sim.olip/uisimulator/sdl/button.o should be sim.clip, but I created the folder sim.clip so I'm confused as to where to find this error. |
23:55:31 | mcuelenaere | lucent: why would you wann do that? |
23:55:36 | mcuelenaere | want to* |
23:55:49 | lucent | I've seen empty strings do funny things in bash |
23:56:07 | bertrik | lucent, I can probably add you too, Eric Shattow is your real name, right? |
23:56:13 | lucent | your version should work as well |
23:56:18 | lucent | bertrik: Yes mate, I'm Eric Shattow |
23:56:23 | mcuelenaere | hmm could be, I'm not that familiar with bash |
23:56:23 | n1s | Davide-NYC: you didn't rename the dir after configuring? |
23:56:28 | Davide-NYC | nop |
23:56:34 | n1s | then i would drop the . |
23:56:39 | kugel | mc2739: how many audio buffer does the debug screen show for you? |
23:56:41 | Davide-NYC | will do |
23:56:58 | bertrik | lucent, did you already register at the wiki? |
23:57:09 | lucent | bertrik: I tried to, there was an error |
23:57:17 | hobbs | mcuelenaere: bash doesn't mind it, but I recall hearing of _some_ shell / version of test that does. |
23:57:18 | rasher | lucent: I've seen that style in Debian scripts. I'm not aware of the arguments for it. Perhaps it's for other crazy shells |
23:57:23 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
23:57:36 | kugel | it shows 1MB less for me then rockbox.map |
23:57:41 | hobbs | mcuelenaere: autoconf uses [ "x$var" = "xtestvalue" ] exclusively |
23:57:46 | n1s | Davide-NYC: possibly some buggy code replaces _every_ instance of ".c" with ".o" :) |
23:57:51 | pixelma | compiling a clip sim works here although I get a few warnings |
23:58:07 | Davide-NYC | n1s: that would be disastrous, no? |
23:58:08 | mcuelenaere | hobbs: ah, didn't know that |
23:58:36 | n1s | Davide-NYC: that's what's happend to your path at least so it won't find the files |
23:59:00 | n1s | i meant every instance in the path not just at the end |