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 2009-03-08

okay so i have a question here. i won a cheepo mp3 player from one of the sponsors at a competition i took part in. i have no (official) manufacturer or model number. the only items i could find are as foolowed, Leeds' ASI/66887 Item 1660-30BK PO 108761. any chance i may be able to hack/edit the firmware or change it?

hrm...that brings up a question...what should we be doing when a patch changing the WPS syntax goes through?...should we be keeping the themes for the site compatible with the release, SVN, or find a way to do both?

Unhelpful actually thinks that PF only needs custom contexts at all for non-scrollwheel targets - the scrollwheel ones can also use the list context for the albums, with "down" as right and "up" as left

But, this is very unlikely to be directly a Rockbox issue. If I Had To Guess I'd say the issue is your Play button is failing and that you only see the issue in Rockbox because Apple firmware does not make use of a long press of Play anywhere in the UI.

ok, pictureflow input rework is FS #9992. i'd appreciate a look from any of the people who had keymap problems in it... it works on my two targets and on the sims i've tried so far, except the M3, which doesn't sim remote buttons

mollybee: first off, we ask people to speak real english in here due to machine translators, logging, etc...secondly, what happens when you try to run it?...and i assume that you downloaded the one from download.rockbox.org?

Hello everyone, i read that funman needs a >2gb v1 clip and that he cant find one in EU. i have one 4GB V1 clip but i i am not wiling to donate it because it's the only player that i have, although i can sell it cheaply if you the developer really need it

hrm... it looks as if a plugin calling get_custom_action can define a context that defines only a few buttons, and chains to a core context, but this can fail in several ways due to different meanings of CONTEXT_CUSTOM

core contexts use CONTEXT_CUSTOM, but it's also the flag used by callers of get_custom_action to indicate that the custom button map function be called to get the next context. i think that the latter case needs a new flag, so that chains to arbitrary core contexts won't have unexpected side effects

the very-few-buttons devices are going to be a bit tricky, because horizontal scrolling isn't like any core contexts, and they don't have so many buttons that there are five or six that all mean "select"

i'm *trying* to chain to a core context, but very strange things happen, like the next call to get_custom_action somehow processing the same button again, and falling through to the core context, where (on my beast) it finds BUTTON_LEFT mapped to ACTION_STD_CANCEL, and then pf exits. :/

I don't understand why this is :/ . IMO if you have something non-standard, do your own thing and be done with it. Of course it's harder in the beginning and won't work well on some targets but at least people who know a target better have an easier way to fix

i'm inclined to think, though, that if chaining can work properly, it makes more sense on *most* targets to only define the left/right scroll, and define a complete, unchained context in the plugin only for targets where chaining can't work neatly... for example, if left/right buttons are the *only* ok/cancel.

Unhelpful: testing your patch on my Ondio (changed button actions for "selecting" the album to a short press of menu and calling the menu with a long press of menu) I get the following weird thing (IMO): trying to back out of the tracklist with "left" puts me into the menu and doesn't exit to the album view as I expected

bertrik: on some targets it's possible to set the A and the B marker directly and seperately with an own button. On others you cycle through set A marker, set B marker (and reset?) with the same button in some "setting" mode

OK. It's pretty clear now why safely remove hardware doesn't properly go back to "normal" mode. The going back is triggered on eject instead of on allow medium removal. This shouldn't be too hard to fix

Unfortunately, unless we drop windows support, this won't work on the beast. Windows (or any other OS) won't send either eject or allow medium removal commands to non-removable devices, *and* it doesn't support two partitions on removable devices

gevaerts: bootloader-in-flash would apparently be the only way to do that on beast... hrm, does windows behave differently if only one of the partitions is visible? or does having two partition table entries do it?

ahHAH... chaining to "CONTEXT_TREE" doesn't get me the context_tree table on beast... that needs to be CONTEXT_TREE|CONTEXT_CUSTOM, another reason that CONTEXT_CUSTOM should not be the flag used by get_custom_action

yes. I think we need a way in both the bootloader and rockbox to allow plain no-changes access. In rockbox I think the debug menu is good enough, and I guess a button press is the only way that works in the bootloader

Actually, I'm not sure if this safely remove fix will work well. It would mean that just unmounting a device will leave MSC mode. That's not really nice for people like me who like to unmount and remount now and then.

For Windows, it is currently working using the external MTP_DLL.dll, but it would be much nicer to compile it as a single .exe. It could also benefit from implementing the same API in MTP_DLL.dll that is used by beastpatcher with libmtp - i.e. an Init() function, then a scan() function, then an upload() function, then a close() function. Currently MTP_DLL.dll just has a single "upload" function.

I think we need to agree on the bootloader functionality as well. i.e. how it reacts when it's booted with a usb cable (or usb charger) attached. Currently booting with a usb charger will cause it to wait indefinitely for a usb connection...

kugel: Well, to tell the truth I haven't followed the latest changes all that closely. One comment from a quick look though: I never saw a need to quickly force an update when the LCD was enabled again. The normal update was quick enough, I thought.

hi, i try to use some parts of the ipodmini 1g for my own mp3 player. At the moment i'm trying to find out how the touchwheel and the lcd are attached to the core. Are there any hardware docs, where i can find protocols, pining ...?

gevaerts: Would some sort of timeout (if it's not accessed again in 1 second, or whatever) make sense, or is this something that's really a "we have to either screw over fsck, or not have this feature in 3.2" situation?

gevaerts: Maybe just allow a press of the "Select" button on the USB screen to disconnect independently of what's going on. Basically, it's the same as unplugging the cable anyway, which a user can also do to unsafely remove, and it allows a solution for all targets without dealing with the cable

Attempting to move or copy files to the internal or microSD card (at least in windows and OS X) seems to cause the device to be connected and disconnected from the USB bus. I wish I knew how to capture the equivalent of the dmesg log in Windows

gevaerts: You could skip the UI work and just have the button functionality in. Detect "medium safe" and allow "select" to disconnect, then let someone add in the UI bits later if someone felt like it, otherwise we just leave it as "nothing changed" for now.

kugel: I wonder if they changed when I wasn't looking, or if I just didn't understand at all how they were supposed to work. But that doesn't make much sense, it basically makes *all* of them less useful because they don't interact.

amiconn: I mean, for example, lcd_update_viewport() would handle the clipping, then pass the clipped x/y/width/height to lcd_update_rect. This would get rid of dozens of different clippings and duplicated code, in favor for 1

the cache was being underrun because the cache load thread was lower priority than the gui thread, and pretty much never run while scrolling. of course, if another thread is running more than it used to, the fps pretty much has to go down :)

building on CONTEXT_TREE was entirely the wrong place to go, instead it's now a context that chains to ACTION_STD and adds the menu/quit/cancel buttons, used by tracklist, and another that adds left/right scroll, and could potentially define inputs for other actions if something needs remapping due to being covered by left/right scroll

I have another idea which I had to back out for now, as it would probably not be wise to push it just before the freeze: the ability for a viewport to override the backdrop with a plain background colour

That is without removing the backdrop entirely. It will be another drawmode modifer bit. I'm not sure which way round it should operate, but I now tend to think that bit set == override backdrop is better

Unhelpful: forcing horizontal scrolling in the tracklist? That's something that could get problematic on the Ondio once you could select tracks to play from it (and in this case I rather do without the scrolling than anything else)

pixelma: it's not done yet, but there are two contexts defined in pictureflow in my working branch for this. pf_context_buttons adds a dedicated quit button, and possibly others if PF will need them anywhere, and chains to CONTEXT_STD. pf_context_album_scroll adds the left/right scroll buttons, and chains to pf_context_buttons.

gevaerts: Reading your manual addition, it comes across as a bit over-technical to me - e.g. "operating system of your computer", could simply be "your computer". Also "host operating" seems incomplete.

i'm still inclined to think that chaining is not evil in and of itself... i'm pretty well convinced that chaining contexts that are very generally defined, and without any per-target thought as to how they will chain, is bad, though. this already works better than PLA. ;)

yes, it lacks power button for one of my targets, or at least i don't know what that is, it can't always simulate button hardware quirks properly... but i don't see how one can give unchained contexts more than a best-effort attempt, either, for targets one doesn't have

Unhelpful: "buyable" means I want to buy a new player in a retail store. "modern" means a player that was produced within last 2 years. "full" means that every feature of out-of-the-box firmware is present in Rockbox firmware.