Support and General Use > Hardware
Sansа Clip Zip - Improve battery life
Mihail Zenkov:
--- Quote from: saratoga on January 14, 2016, 06:10:57 PM ---I did notice that during frequent boosting some button inputs are skipped, although maybe that is unrelated.
--- End quote ---
For fuse v2 we disable irq when check hold/power buttons, probably we should do same for clip v2.
Mihail Zenkov:
--- Quote from: oid_maps on January 15, 2016, 07:52:00 AM ---So, I narrowed the things down to get to know the shortest possible delays where the hold-switch still works on my Sansa fuzev2.
Here are the results:
--- End quote ---
Ok, thanks!
--- Quote from: oid_maps on January 15, 2016, 07:52:00 AM ---@ Mihail Zenkov: Can you include that one in your patchset?
--- End quote ---
Yes, it should by included in next update.
--- Quote from: oid_maps on January 15, 2016, 07:52:00 AM ---And: Is there a way to make this patches upstream?
--- End quote ---
We should fix all know issues before.
--- Quote from: oid_maps on January 15, 2016, 07:52:00 AM --- If not, it would be nice to host it somewhere (that people do not have to dig through all the forum posts to find the correct versions), if hosting is not possible and we have to resort to the forum, then putting everything into one file (.tar-archive, or a single patch file) makes things still more easy.
--- End quote ---
Probably you right and we should provide single patch for user.
oid_maps:
--- Quote from: saratoga on January 14, 2016, 06:10:57 PM ---Edit: Both delays set to 10 works pretty well, will try other values:
--- End quote ---
OK, for me first delay set to 18 and second to 09, but also second to 40, didn't even work (as well as 10, 05 did not work, neither did 12, 06; 14, 07; 16, 08). So maybe either the individual devices differ, or 10, 10 is a combination which would work again? Strange.
Cannot test right now.
Mihail Zenkov:
--- Quote from: oid_maps on January 15, 2016, 07:54:31 AM ---Well, but I observe that also when compiling the bootloader, the file 'button-fuzev2.c' get's compiled:
So, what's the reason that the bootloader takes into account that file?
--- End quote ---
We check button state in bootloader - to boot in original firmware or boot recovery mode.
--- Quote from: oid_maps on January 15, 2016, 07:56:56 AM ---Why is it not sufficient to just have a small bootloader ("fuzpa.bin") without the original firmware?
--- End quote ---
We can't do separate update for bootloader and original firmware.
--- Quote from: oid_maps on January 15, 2016, 07:56:56 AM ---Does it fallback to the original firmware automagically if we don't have the .rockbox-tree on the device?
--- End quote ---
No, it fallback to recovery mode (usb flash drive).
[Saint]:
--- Quote from: oid_maps on January 15, 2016, 07:59:53 AM ---A user asked me if I can provide a working build. The forum does not allow to upload archive files. Is there a way I can upload it somewhere to a subpage of rockbox.org? I feel uncomfortable with hosting it by myself ... I did not dig into the legal issues yet (impressum of the website would be needed, warranty-disclaimer maybe, maybe some attribition to property rights I need to make).
Otherwise, I would email the .tar.xz-archive if people ask me directly (private message, and include your email address).
--- End quote ---
Why would you not simply host it on one of the many sites like Data File Host or so?
The only real requirement you _must_ undertake is that you need to be able to supply the full source code that generated that binary when asked to do so, as a requirement of the GPL license (note: technically speaking just supplying a patch file and pointing to the Rockbox sources and a given commit that the binary was built from is not actually good enough to satisfy this requirement).
[Saint]
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version