Rockbox

Tasklist

FS#10097 - Sometimes keys do not work after exiting plugins

Attached to Project: Rockbox
Opened by Michael Chicoine (mc2739) - Sunday, 05 April 2009, 04:37 GMT
Last edited by Bertrik Sikken (bertrik) - Sunday, 10 October 2010, 14:14 GMT
Task Type Bugs
Category User Interface
Status Closed
Assigned To No-one
Operating System Sansa e200
Severity Low
Priority Normal
Reported Version Version 3.2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

svn = r20619 and prior

fails on device and sim

1. press long select on playlist
2. scroll to open with
3. select search
4. enter search string (if you like - not really needed to see failure)
5. press play to leave virtual keyboard screen

The search plugin performs the search, displays a "Done" splash and exits.

If you try to use the wheel, there is no response. If you press any button, the first press is ignored. The next button press or wheel movement will work normally.

In the sim, after running the search plugin, the first button pressed or the first press of the simulated wheel buttons will not work. After the first press, all buttons work normally.

The attached patch adds a 'rb->get_action' before exiting which allows normal button and wheel response after the plugin exits.
This task depends upon

Closed by  Bertrik Sikken (bertrik)
Sunday, 10 October 2010, 14:14 GMT
Reason for closing:  Fixed
Additional comments about closing:  Committed plugin_button_clear.patch as SVN r28232
Comment by Michael Sevakis (MikeS) - Sunday, 05 April 2009, 08:24 GMT
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.
Comment by Michael Chicoine (mc2739) - Tuesday, 07 April 2009, 23:02 GMT
I'm not sure how to do that. Can you explain?
Comment by Michael Sevakis (MikeS) - Friday, 10 April 2009, 03:17 GMT
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.
Comment by Michael Chicoine (mc2739) - Friday, 10 April 2009, 23:41 GMT
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.
Comment by Thomas Martitz (kugel.) - Friday, 19 June 2009, 21:23 GMT
I edited the title to be more general.
Comment by Linton Dawe (Linton) - Saturday, 18 July 2009, 09:40 GMT
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.
Comment by Johannes Schwarz (Ubuntuxer) - Monday, 16 November 2009, 20:07 GMT
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?
Comment by Thomas Martitz (kugel.) - Monday, 16 November 2009, 20:33 GMT
Yea, it still happens sometimes. On the fuze too.
Comment by Michael Chicoine (mc2739) - Monday, 16 November 2009, 22:06 GMT
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.
Comment by Johannes Schwarz (Ubuntuxer) - Thursday, 19 November 2009, 06:51 GMT
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
Comment by Michael Chicoine (mc2739) - Monday, 04 January 2010, 06:50 GMT
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.
Comment by Michael Chicoine (mc2739) - Monday, 04 January 2010, 07:14 GMT
The above patch causes problems with the quickscreen, so it is not quite ready yet.
Comment by Michael Chicoine (mc2739) - Monday, 04 January 2010, 08:23 GMT
Here is a new patch that does not cause a button repeat problem on entering the quickscreen.
Comment by Thomas Martitz (kugel.) - Monday, 04 January 2010, 12:52 GMT
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?
Comment by Michael Chicoine (mc2739) - Monday, 04 January 2010, 13:55 GMT
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.
Comment by Thomas Martitz (kugel.) - Monday, 04 January 2010, 15:07 GMT
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).
Comment by Michael Chicoine (mc2739) - Monday, 04 January 2010, 15:16 GMT
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.
Comment by Thomas Martitz (kugel.) - Monday, 04 January 2010, 15:27 GMT
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.
Comment by Thomas Martitz (kugel.) - Monday, 04 January 2010, 15:37 GMT
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.
Comment by Bertrik Sikken (bertrik) - Tuesday, 06 July 2010, 09:10 GMT
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.
Comment by Bertrik Sikken (bertrik) - Friday, 16 July 2010, 09:32 GMT
Attached patch seems to fix it for me for the dice plugin. Other plugins still seem to work fine with this too.
Comment by Thomas Martitz (kugel.) - Friday, 16 July 2010, 11:23 GMT
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.
Comment by Bertrik Sikken (bertrik) - Sunday, 10 October 2010, 14:10 GMT
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).

Loading...