Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Domonoky:
I also just tried this patch again.
For me the wheel reading is very unreliable, you have to be very lucky that rockbox recognises a wheel event. strangely, as others noted, it seems to work better in the time & date screen.
I also tried to print out the dbop_in value (with snprintf and lcd_puts), but then i can not see any reaction to the wheel or buttons in the dbop_in value. I suspect there is some timing problem in this, maybe it depends on if and where we interrupt the lcd ?
sko:
--- Quote from: Domonoky on January 11, 2009, 07:02:53 AM ---I also just tried this patch again.
For me the wheel reading is very unreliable, you have to be very lucky that rockbox recognises a wheel event. strangely, as others noted, it seems to work better in the time & date screen.
--- End quote ---
Well... I just press and hold ">>|" and then turn the wheel and it works for me.
Edit: without pressing ">>|" it recognises the wheel just one or two times.
kugel.:
Quite weird.
I've looked a bit at the patch.
Sko:
I noticed you changed the WHEELCLICKS_PER_ROTATION #define. Be careful with that define. It's directly connected to scrollwheel acceleration. And scrollwheel acceleration is problematic with the Fuze, possibly with the e200v2 too (as we're not using an interrupt handler [yet]).
int_btn &= ~(BUTTON_REC|BUTTON_POWER); in get_button_from_dbob??
You changed BUTTON_HOLD to BUTTON_REC, why that?
Resetting the hold button is vital for it to work properly. It might be that this change causes your weirdness.
Other than that, I can't explain that pressing >>| after the wheel causes scrolling etc.
sko:
--- Quote from: kugel. on January 11, 2009, 07:27:28 AM ---Quite weird.
I've looked a bit at the patch.
Sko:
I noticed you changed the WHEELCLICKS_PER_ROTATION #define. Be careful with that define. It's directly connected to scrollwheel acceleration. And scrollwheel acceleration is problematic with the Fuze, possibly with the e200v2 too (as we're not using an interrupt handler [yet]).
--- End quote ---
Well I counted the wheelclicks, and it clicks just 24 times, I thought the Fuze has maybe more wheelclicks.
--- Quote from: kugel. on January 11, 2009, 07:27:28 AM ---int_btn &= ~(BUTTON_REC|BUTTON_POWER); in get_button_from_dbob??
You changed BUTTON_HOLD to BUTTON_REC, why that?
Resetting the hold button is vital for it to work properly. It might be that this change causes your weirdness.
Other than that, I can't explain that pressing >>| after the wheel causes scrolling etc.
--- End quote ---
Oops... this is a mistake, I was looking for all references to BUTTON_HOME, I must have accidently changed this.
kugel.:
--- Quote from: sko on January 11, 2009, 07:41:09 AM ---Well I counted the wheelclicks, and it clicks just 24 times, I thought the Fuze has maybe more wheelclicks.
--- End quote ---
Don't confuse wheel clicks with the physical clicks the wheel appears to do (the symbol should probably renamed, it confused me too).
It should hold the value of their respective DBOP_DIN changes per rotation. And that changes several times per physical clicks.
I counted 4-5 for each physical "click" on my fuze (hence only post if the counter is >= 4, so each post is equivalent to 1 item in the list). And I counted ~14 physical clicks per rotation.
I know this should give 70 wheelclicks per rotation, but honestly didn't pay to much attention into this as well, as 48 "just works" on the fuze.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version