SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

[kugel.]

The Hold button seems to be recognized, but isn't working as expected: if hold is on the lock-icon on the status bar is flashing (together with the backlight) sometimes if I press a key / scroll the wheel.

Ah so it's at least recognized. That's different from what domonoky reported when he tried this code first.

[sko]

Ah so it's at least recognized. That's different from what domonoky reported when he tried this code first.

I also changed the line

Code: [Select]

if (queue_empty(&button_queue) && ++counter >= 4)to

Code: [Select]

if (queue_empty(&button_queue) && ++counter >= 8)but now I tried with the old line too and it is the same behavior (just a bit faster if using the wheel).

Edit: but how can I test the REC button? What should happen if I press it?

[kugel.]

Try printing/logging the values DBOP_DIN gives.

[FlynDice]

Maybe someone more familiar can make use of this quicker than I can.  Thanks to the diff that sko posted I was able to get into the plugins and games.  I found in the Blackjack game that I was able to reliably and precisely use the scrollwheel to control my bet increment (by 10's).  I had to use the >> button to increment by 1 first but after that I could increment up, down and stop where I wanted.  I also found that it seems with this patch the scrollwheel is more of an enabler.  What I mean by that is that in trying to navigate the menus both the >> and << buttons seem to do the moving if you start the scrollwheel first and then press one of those buttons.  I've seen the small lock icon flip open and closed with the hold switch also but cannot reliably duplicate the behavior.  The REC button has eluded any noticeable effects in my playing around.

I've also found that in rockpaint, oscilloscope, mandelbrot, bubbles, sudoku, and plasma  that putting the hold switch on turns the backlight off while switching it off turns the backlight back on(the screen is still displaying...).

Also in the sudoku game I can use the scrollwheel to scroll numbers into the boxes under complete control.

[sko]

I've also found that in rockpaint, oscilloscope, mandelbrot, and plasma  that putting the hold switch on turns the screen off while switching it off turns the screen back on.

Same in the time & date screen (System > Time & Date).

Try printing/logging the values DBOP_DIN gives.

How can I do this? I tried printf and DEBUGF, but both didn't compile. Is there a missing include? I'm not very familar with C, usually I write applications in Delphi.

Edit: I tested blackjack now, and it is working as FlynDice wrote: the wheel is reliable there.

[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]

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.

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]

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]).

Well I counted the wheelclicks, and it clicks just 24 times, I thought the Fuze has maybe more wheelclicks.

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.

Oops... this is a mistake, I was looking for all references to BUTTON_HOME, I must have accidently changed this.

[kugel.]

Well I counted the wheelclicks, and it clicks just 24 times, I thought the Fuze has maybe more wheelclicks.

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.

[sko]

I removed the mistake in get_button_from_dbob, but the behavior of the Hold switch hasn't changed.

Don't confuse wheel clicks with the physical clicks the wheel appears to do (the symbol should probably renamed, it confused me too).

Ok, good to know, really confusing . I changed it back to 48.

[Domonoky]

I did some more experimentation, and i can confirm, that it somehow works when you press and hold "<<" or ">>" while using the wheel. Unfortunatly i have no idea why.
Also those readings with the pressed buttons are not reliable, it sometimes finds scrollwheel and hold/rec and sometimes not. This is why we see the hold button flickering on and off.

I also did take a look a the datasheet, and noted that the wheel and other missing buttons are on dbop bit12 and upwards. Interestingly these dbop bits map not to a gpio port, but to some dedicated dbop pins. Which means we have to use dbop for this for sure.

Also the bits i can reliable read from the dbop are all below bit12, all higher bits are nearly always 0, so there must be something wrong with our dbop setup ? *speculating*

happy hacking.

[kugel.]

Also those readings with the pressed buttons are not reliable, it sometimes finds scrollwheel and hold/rec and sometimes not. This is why we see the hold button flickering on and off.

You're able to read REC (sometimes)?

Also the bits i can reliable read from the dbop are all below bit12, all higher bits are nearly always 0, so there must be something wrong with our dbop setup ? *speculating*

I don't think so. It's basically exactly what the OF does. Interesting that you found something in the datasheet. I didn't. Can you point me to the page?

Well, reading the wheel is pretty reliable on the Fuze. I was suprised if the e200v2 needs some special handling, but it's possible. I think a look in the OF can't hurt.

[Mikerman]

1-13-09:  1gb refurbished Clips for $9.99 + $5 shipping at woot.com; good until sold out or 24 hours, whichever is first ...

In case experimental units are needed.

[sko]

Hi kugel, your buttonlight-patch (http://www.rockbox.org/tracker/task/9663#comment27741) seems to do nothing on the e200v2, I tried on clean svn and with the modified fuze button-driver.

EDIT: hmm... commited patch works really good (running r19795), good work!