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.

I also have a patch there. It accesses an unknown PP5020 register. Based on what I saw in the OF, 0x70000088 may be an input for GPO32 bits. The OF first writes a zero word and then reads the word to test the bit.

From the point of view of USB power hardware, it doesn't matter whether there is a USB connection or whether it's a USB charger or a USB port. Software has to see what's connected and respond accordingly.

Okay, I'll bring this up another time when more people are around. (Rockbox already requests 500 mA, but a request doesn't change how much current the device uses. It just makes sure that the requested current is available.)

dreamlayers: Question about your work on FS #9787 and FS #9890... since you seem to have an idea of how to talk to the BCM chip in the iPod video, do you believe that we may be able to utilize it at some point in the future?

Rockbox as an app should, where possible ,strive to us the UI widgets appropriate to the OS it's running on. That means, for example, file browsing should not use our list. It should use a more "standard" file browser widget for the OS it's on

Preserving "the list" for menus and files just makes the UI less appropriate for normal use. It's used now because it's the best we can do where we are, and not something we should force on users when a better option can be made available

kugel: RaaP's point is to make it easier to use native UI widgets. Separate the code out, and compile with them, so that it's easier to make targets use them. So that, for example, on smartphones where more of our UI needs to be preserved for usability it's easier to adapt

Llorean: I wonder where you got that idea for rockbox-as-an-app... using the OS widgets is almost impossible in its current state.... that might be a very long term goal... but for now its just being able to use the native drawing code instead of sdl...

n1s: only Rec for me... and I guess that's a part of FS #8824 (IIRC) I would be willing to commit, not sure about the others. It changed a bit since then (mainly enabling line edit mode additionally) and needs a patch for the manual

rockbox is a great thing. one of the greatest things. it would be a shame if there was another program on a completely different product (for example, phone) that could potentially ruin the potential of rockbox. what would the estimated threat of that be, do you reckon?

nthe other part of that patch I still use is resume but since it "disables" the possibility to adjust volume in the lists I'm not sure how other see it (to me a one button resume is much more important)

*I* could also imagine to use short Select for resuming and having Select and context menu on Right/long Right only. But that's because it's similar on Ondio... (Right and Select are redundant on other targets though)

next after lunch project - I'll try to get the virtual keyboard part commitable and try to post a patch for resume and the other thing that I use which deviates from SVN (long Select for the WPS context menu)

For example, we support a few players using PP5020 SoCs, but there are others that use it we don't support. There's no requirement that firmware be encrypted or stored the same way for a given SoC, often, so even if we did support some players with it, that's not really indicative of the potential for supporting others.

Can anyone help me understand the gigabeat flashwriter? can i use this plugin, only if i have a jtag interface? because in the wiki it says you only "should" do it, when you have one, so i understand it's not a must...

hm, but there are many major rockbox hackers who are interested in this task (kkurbjun, saratoga, chronon and bigbambi) who are quite often online in this channel, so i thought chances be good to get a helpful answer here.

BdN3504: Generally speaking, flyspray tasks are like unsupported builds. You should ask support questions in the task entry. They do get discussed in here, but it should generally be in a development context, not a support one.

kugel: It is indeed a timing issue. The hwcodec playback engine doesn't have the id3 info ready immediately after starting playback. I can fix it (for testing) by inserting a sleep(HZ/2); directly before the wile loop in gui_wps_show()

not sure if morse mode makes much sense on the c200 - the table with the code doesn't fit completely on the screen and I'm not sure I'm doing something wrong in defining the actual morse button but I can't figure out how to use it (never used it as my other targets don't have it either, will look at a sim now)

pixelma: not sure if you saw, the reason i used long off for quit on ondio was due to short off being mapped to cancel in CONTEXT_STD. i guess the real problem is knowing how many users actually use these alternate cancel mappings - quite a few other targets use this same one, even though the power button isn't very convenient while operating the directional controls

Unhelpful: I guess that on the Ondio no one really uses this - the Off button is quite a bit away from the main button pad but maybe it was done this way to stay consistent with the short/long Off for Pause/Stop?

hrm, perhaps at least *some* of the targets with that mapping should just use short off for quit? cancel in the album list is a quit, anyway, so the real question is "will the user expect this button to take them back to the album list from the track list?"

pixelma: sorry... i guess so, i don't have a large number of ondio users to poll. the question is whether masking the default mapping of short power by using it as quit would be likely to confuse "most" users. i realize there probably aren't very many users for this target. :)

ufoman: dunno, perhaps faster disk access? The Nano is flash-based, though, it should've been faster. Fragmentation is another possibility but then again - NAND flash, shouldn't have been an issue. Could be that the coldfire port is better optimized.. Might be pure luck, too:)

Anyone willing to help me with this : http://pastebin.ca/1375789 - I need to convert the original into a fixed-point version, using rockbox routines. I've basically carved a hole in my desk from banging my head. Both fixed-point versions do not come even close to the original floating point version. Also, "phase" is a double - I'll convert it as soon as I get this part of the code working..

n1s: I don't know where to put ACTION_KBD_MORSE_SELECT without interfering with the rest. What I think could work nicely is using Left or Right but then they are used as alternative left/right on the input line (which I wouldn't need because I have VolUp/Down for it everywhere), I saw related things in keyboard.c but couldn't figure out yet how to disable it

i guess the question now is, "when should i mask a normal core mapping with a new action?". there are a number of targets where i've done basically the same thing as ondio, and assigned long power as quit because CONTEXT_STD maps short power to cancel

Unhelpful: technically, we don't have it anymore :) Also, libspeex has that same library (kiss fft) but it's been converted to use libspeex datatypes and it'd be harder to port it back to "normal" datatypes..

saratoga: Am I right to assume that there isn't a way to give it real input and I'd have to do the real->complex conversion myself? Not that it's that hard, it's just one more thing I might screw up :)

saratoga: What I'm doing is, I get N samples from the stream, pass them over to KISS FFT (as real values), it gives me back N/2 complex numbers, I take the magnitude, discarding the phase and plot it on the screen...

saratoga: I've only compared the final output and the only change between my fixed-point implementation and the original fixed-point mode lies in that macro - the original fixed-point code actually uses the sin() and cos() standard library functions, I am trying to replace them..

Uhm, not a fractional one - just degrees - from 0 to 360 IIRC. Then it just returns the appropriate precompiled value in 18.14. I don't have the code with me right now, so I might be off on the details..

the id3 part of gui_wps is duplicated anyway. I'd propose to convert update (and maybe display too) to do for both screens, and change the struct gui_wps to have two wps states and displays (for each screen), but only 1 id3

hang on... the id3 struct has the track path which is the very least the WPS needs.. so hwcodec should behave the same as swcodec untill the real info is avilable (i.e return a blank mp3entry sturct with just the path filled in)

amiconn: no, the hwcodec problem was unrelated.. turns out I had the send_event() call 1 line too early, its fixed now... currently it looks like it brings up issues which are in svn but not so obvious

back to the targetname problem: renaming some names (ie sansa prefix, ipodmini(1g) ) is a first step, but the hard thing still remains, what todo with binarys configure doesnt know. Or targets with different bootloader, but same main binary?

this is basically a linked list, with the last one marked by a "1" value. Apparently that gets transformed to a 0 by hardware (or maybe I didn't look carefully), so I ended up dereferencing a null pointer

saratoga - (if you're reading) - I just tried slapping in the ARM bitwise optimisations from Tremolo (and the naive way of doing that requires taking out the rockbox(tm) optimisations for huffman decode from FS #6848) - decode speed is down. I expect a non-naive integration would have better results but not clear if it would be a big improvement

coffeetime: people work on rockbox in their spare time. for a new device to be supported, somebody who has one has to figure out how. that's pretty much the only way devices get support. there is no "plan" to support any specific device at any specific future date.

Curious. What are the usual files involved with the secondary (post-bootloader) boot logo? Tried to do some patching for my target but now I have a garbled screen for that logo I need to fix and can't recall exactly -which- files and where...

how do people feel about what 9886 is trying to do? i.e rework how the wps uses its ram so that people who dont want fancy WPS' can reclaim some, and those that want crazy fancy WPS can steal more than allowed currently