Rockbox

I see this happen in general with other plugins on my e200 from within a list view. This bug should be looked into more thoroughly. Try seeing what queue_count(&button_queue) returns before trying any button_get. The wheel only posts messages on an empty queue.

I'm not sure how to do that. Can you explain?

Something simple like this in plugin.c at the right place after plugin exit?

int count = queue_count(&button_queue);
splashf(HZ, "%d", count);

Though somehow I suspect the action code or the buffon driver to be at fault since get_action should return from its own wait call if there are in fact any messages.

I modified plugin.c with the above lines - it displayed "0". I checked the return of the rb->get_action in my patch, and it was "0". Next I tried bypassing the rb->kbd_input api call and manually set the search_string. This allowed the buttons and wheel to work properly on plugin exit. I'm looking at other plugins that use rb->kbd_input, but so far the plugins I have checked all seem to perform other button input after the rb->kbd_input call.

I edited the title to be more general.

I have the same symptoms but with a different cause.

When a playlist ends naturally (not by pressing stop, etc) and the last input while playing was to change the volume with the scrollwheel in the WPS, the same 'wheel lock' problem occurs.

When automatically returned to the menu or file list, moving the wheel causes the backlight to illuminate, but is otherwise ignored, however many times you move it. The first button press is also ignored, after which everything works normally.

This is on the e200v1 running r21884, and older versions dating back to at least the time this bug was first submitted.

I write a bug report about a similiar bug, which occurs after you exit the new game boomshine. ( FS#10787 )
I can't reproduce your bug on my e200, does the bug still exist?

Yea, it still happens sometimes. On the fuze too.

Yes, this still fails on my e200 and e200v2.

I have also reproduced the problem reported above by Linton Dawe. This tends to rule out that this is strictly a plugin problem.

I noticed another similiar bug, which occurs if you use the scrollwheel in the plugin clock. After I return to main menu, I can't use the scrollwheel and I have to press another button, so that it works again.
Bizarrely the bug doesn't occurs in game menu. e200, Fuze

This patch fixes the search plugin symptom, the volume change at the end of playlist symptom and the clock plugin symptom. I do not see any ill effects from this patch, but I have not done exhaustive testing either.

Please test and report any results here.

The above patch causes problems with the quickscreen, so it is not quite ready yet.

Here is a new patch that does not cause a button repeat problem on entering the quickscreen.

Well, special casing the quickscreen seems like a hack that's going to break in the future.

http://www.rockbox.org/tracker/task/10883 has a patch as well, can someone have a look at/test that one?

Another update that no longer special cases the quickscreen.

I have tested http://www.rockbox.org/tracker/task/10883. Although it does allow the scrollwheel to function, there is still a lost scrollwheel transition and a lost keypress.

Have you understood the root problem? The patch doesn't look bad but I'm curious about the cause of the problems.

What I know is that scrollwheels don't generate BUTTON_REL when they're untouched because they post to the button queue out of the normal control flow (the button tick task handles OR'ing with BUTTON_REL, but the button tick doesn't mess with the wheels).

The problem is not strictly a scrollwheel issue. When the problem happens, the scrollwheel does work - the wheel light turns on and you can see results in the "button" variable. The code does not take action on scrollwheel events until after a button press.

That's not surprising, the drivers itself turn the buttonlight on for scrollwheel presses (because the button tick task doesn't manage them, it only turns the buttonlight on for normal button presses). And the drivers post to the button_queue which directly translates into setting the button variable.

I haven't noticed that this bug appears on a non-scrollwheel target too, so I connect this somehow.

Maybe the problem is that BUTTON_SCROLL_* isn't cleared properly from the button variable after the wheel is untouched, and the action code is confused if this happens during a context switch.

I can reproduce this with the dict plugin (tried it on the clip sim):
* start dict plugin, this shows a keyboard input prompt
* exit the plugin by a short press of the POWER button
* first key after this is ignored in the plugin menu

I looked at this problem last night in the sim, checking what goes into the button queue and what is pulled out again. Here's my conclusion about what happens:
* the dict plugin causes both a POWER key *press* and a POWER key *release* event to be submitted to the button queue
* when exiting, the plugin exits on the *press* of the power button. After plugin exit, button_clear_queue() is called in plugin.c, clearing the key *release* event.
* in action.c function get_action_worker, a key context change is detected (line 207) which causes it to ignore all further key events until a key release is seen (I think this includes scrollwheel events!).
* since the key release event was cleared just after the plugin exit, *another* key press/release is needed to continue key event processing.

Attached patch seems to fix it for me for the dice plugin. Other plugins still seem to work fine with this too.

I somewhere mentioned that this happens in the core in some places too. This would maybe work around for plugins (otoh it might cause new problems, I guess that call is there for a reason) but not for the core.

Committed the plugin_button_clear.patch as SVN r28232. Let's keep this task open for a while to see if anything bad happens (I don't expect so).