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

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

#rockbox log for 2011-03-28

saratoga, for the ipods a student could work on accessory support for the nano2g and classic 6g. IAP is currently hooked directly into the PP serial interrupt, so it's not working yet on the nano2g/classic6g which are based on the s5l870x

JdGordon|: I've been thinking about hiding the "control panel" in the .sbs with a tab (as suggested), but iiuc this will run into the same problem my old personal theme had with UI viewports in that the lists aren't redrawn if the UI viewport changes.

So...regarding skin vars...my understanding is a little fragile. It needs to be set up (in my/our case) so that the popup viewport(s) increment "foo"+1, and the album info viewports check if "foo" is >0 and goes true then?

For the meantime, I've gone ahead and made sure that every function of the .wps can be reached without the popups...but it'd be very nice to get them working and remove some of the duplicated touch areas.

while I'd *like* to do all the images (so it doesn't end up like current cabbieV2 with 10 different shades/variations of the same theme slightly different), it's reasonably unrealistic in a reasonable timeframe and I wouldn't say no to an enthusiastic volunteer.

I guess the thing is that my 24px iconset hasn't gone in because it's different to the "standard" cabbie icons, and from what I was told the only way to get it in there is to adapt the other icons to match.

Maybe bring that up on -dev then. It's impossible to adapt the current iconset, is it okay to go with "thematically similar" or do we need to hunt down icons that look good both hi and low res (which can be quite difficult)

[Saint]: I noticed the different kinds of yellow too and there were also some source bitmaps unnecessarily using 32-bit depth at some point in time - so I think the reason is 'only' that different people worked on the ports using different editors

and I think it should be possible to have similar style icons for all ports which may need hand-editing to get the small ones recognisable. There's no need to have it right from the start but experience shows that 'do it later' sometimes gets forgotten (e.g. the greyscale menu icons are just scaled down and should be reworked which hasn't happened ever since...)

it's not impossible...it's just not very convenient to do it either way. A good percentage of the icons used in the current iconset are no longer available and/or make no sense in the way they are used....and the larger scale ones I substituted in my 24px set look shit scaled down to 12px

I don't think it would be a shame if the current iconset was dropped like a hot rock, and rethought from the beginning. I don't see the point in adapting the iconset to a flawed mechanism personally....a good ~30% of the icons in the iconset aren't ever used. And viewers are horribly borken.

but that's a huge amount of work, apparently...as shown by the fact that icons slipped from being used for their functions purpose, to being used for the icon that looks best in its place. making for some *really* weird/broken use of the icons in some places. But that pretty much had to happen, as as the iconset developed the icon function name and the actual icon apparently fell horribly out of sync somewhere.

i've noticed the fuss around the "various docks" gsoc project. there seems to be quite some interest (and competition :smirk:) regarding the matter, and the project specifications have evolved nicely (at least there's more flexibility now)

on the other hand, the usb stack can prove challenging from my experience. anyway, my question is: are we approaching a final form of the project or is it prone to substantial modifications? because i'd like to start documenting and writing some outlines and MO's

gevaerts: i was living under the impression that rockbox is quite time-dependant (from the top of my head: time quantum sharing between decoding and user commands?! human-insensible response times etc.). but then again i haven't had the chance to study the problem thoroughly. what do you mean it's not a "classic" rts?

Rockbox basically (warning: simplification ahead, and I'm not an expert!) increases the priority of the codec thread whenever the PCM buffer (which is the last stage before actual sound output) gets rather empty. On players that support it, the CPU frequency also gets boosted then

silbo: as a fellow student, not as a member of the dev team or anything else: i'd recommend getting a easily programmable core (my choice - cortex m0-m3) with a fast debugger(segger jlink /copy of) and (personal choice) IAR embedded workbenchbench

it's about the "various docks" project. i've had a chat with <saratoga> a couple of days ago, when the project had different specifications. the main problem was a logistic one (not too many sansa docks laying around). but now that's a little more relaxed, as far as resources are concerned

funm4n, odd. As far as I understand, variant 0 uses two CIUs (card interface units) with separate CMD lines for each slot, variant 1 uses only one CIU (ciu number 1) and uses only one CMD line that is switched between the internal and external "slot" using GPIO B5

rigoletto, correct, the patch disables switching the card into high speed mode. The code to set high-speed mode is less than half done (the sd controller itself is still running at normal speed); it's not actually getting slower now.