Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
kugel.:
--- Quote from: kronflux on June 06, 2009, 11:14:14 PM ---
--- Quote from: sko on June 06, 2009, 07:11:45 PM ---I made a patch for e200v2 which makes the button driver more equal to the one of the fuze (which uses same repeat/acceleration logic since r21166):
* it renames the repeat variable to accel
* using same comments as on fuze (as they are describing the same)
* remove wait for fifo empty
* implement button_delay in the same way as on the fuzeHere is the patch: FS#10284
--- End quote ---
Just tested this! seems to work rather well, I definitely prefer it over the way it was.
Running this on my e280v2.
Edit: Also just made the hardware mod that gets rid of the "click" feel in the wheel, and tried it both with this patch and without, and both with the wheel mod and without, this patch is still preferable, to me anyway.
Nice work! thanks a lot!
--- End quote ---
Cool, so I guess it can be committed.
Also, if you don't have the hardware clicks, you can consider tweaking this line "if (++counter >= 2 && queue_empty(&button_queue))". That limits the wheel value posts to match the physical click to scroll 1 item per click in lists.
--- Quote ---Don't know if this has been addressed yet, but the player randomly likes to turn the wheel light on during playback, and sometimes when browsing, it flickers.
I think the issue was addressed, but was it ever fixed previously?
--- End quote ---
Yea, that's known, but for now it's rather useful. I'm eventually looking into making the buttonlight act as disk indicator on all targets (as an additional option of course).
kronflux:
--- Quote from: funman on June 07, 2009, 04:19:40 AM ---This is a known "problem" also happenning on fuze, and which will eventually be looked at in the future.
--- End quote ---
Must not be all Fuze models.. I've had my 4gig Fuze running rockbox for a while now, keeping it up to date with the latest svn and occasionally applying patches, and I've never encountered the wheel light flashing, and I used it every day.. any idea which models it applies to? or am I just a lucky one? :P
--- Quote from: kugel. on June 07, 2009, 02:30:22 PM ---Also, if you don't have the hardware clicks, you can consider tweaking this line "if (++counter >= 2 && queue_empty(&button_queue))". That limits the wheel value posts to match the physical click to scroll 1 item per click in lists.
--- End quote ---
any idea how what I'd tweak it to? I'm still very new to all this stuff :)
if this is the wrong place to ask, want to pm me if you don't mind making suggestions?
--- Quote ---Yea, that's known, but for now it's rather useful. I'm eventually looking into making the buttonlight act as disk indicator on all targets (as an additional option of course).
--- End quote ---
that's a cool idea, the only thing I don't like about it is that the wheel light is very bright, so its very distracting for everyday use, but as you said, optional, so still a good idea.
sko:
--- Quote from: kugel. on June 07, 2009, 02:30:22 PM ---Cool, so I guess it can be committed.
--- End quote ---
I posted a second patch to FS#10284, missed one button_delay, but if it's fine it can be commited (from my position so far).
FlynDice:
I did a couple of battery benches over the weekend and got some unexpected results. I thought I would go for the longest lasting first so I tried svn with FS#10048 applied and modified the clocking to fastbus only, 62 MHz boosted & 31 Mhz unboosted. I got 12:38 runtime. Then I tried svn with FS#10048 which is 248/62 synchronous expecting the time to be slightly less. No way Jose! 15:41 using the higher frequencies. I'm attaching the text files to this post as It would take me too long to actually learn how to make the graphs.... I guess after this I'm reconsidering my thoughts on the whole lower PCLK frequency issue. I see no advantage now.
Is there a good way to store a database or collect all the battery bench files in one location to get a better idea of what works best?
I was thinking of modifying clock-target.h to give a choice of pre-configured clocking schemes while also keeping the ability to use the present system if you need more options. Does this seem like a good idea or unneeded complication?
matsch:
--- Quote from: funman on June 05, 2009, 05:09:06 PM ---Yeah playback sometimes stops on the Clip.
The problem is known, and specific to the Clip, but no cause has been determined yet.
--- End quote ---
Stable MP3 playing would be fine. I am not experienced enough to find the root cause, but
I can help testing some ideas to get stable MP3 playing.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version