Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#9957 - USB connection not made when action_userabort() is used

Attached to Project: Rockbox
Opened by Jonas Häggqvist (rasher) - Thursday, 26 February 2009, 17:07 GMT+2
Last edited by Frank Gevaerts (fg) - Friday, 22 May 2009, 00:10 GMT+2
Task Type Bugs
Category User Interface
Status New   Reopened
Assigned To No-one
Player Type All players
Severity Low
Priority Normal
Reported Version Version 3.1
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Private No

Details

Using a bootloader from  FS#9955 , a USB connection is not made if Start Screen is set to WPS, and the user boots Rockbox by inserting a USB cable.

This is possibly also true for other values of Start Screen.

Tested on e280, but I expect it'll likely be the case on other PP targets with USB
This task depends upon

View Dependency Graph

This task blocks these from closing
FS#10315 - ipod doesn't show connecting to PC
Comment by Jonas Häggqvist (rasher) - Friday, 27 February 2009, 00:13 GMT+2
A few more details:
When booting, the sansa would either get to the WPS and freeze at 0:00 (before seeking), or show the USB screen, but not actually establish a connection. Unplugging the cable would make playback resume as expected.

I got these messages on the host:
[272219.306337] hub 6-0:1.0: unable to enumerate USB device on port 1
Comment by Phil Light (phillight) - Friday, 27 February 2009, 07:35 GMT+2
I also have this problem on my e270 when the start screen is set to resume playback, with slighty different symptoms:

For me, a splash screen 'Error accessing playlist control file' appears very briefly before the USB screen is shown. Vista does not see the device and no errors are reported in the event log.

On removal of the USB cable, either:
1) The main menu appears with a 'Scanning disk...' splash, but the sansa is frozen requiring a hard reset
2) The screen becomes corrupted with shimmering diagonal lines on a solid-ish background, and again a hard reset is required
Comment by Steve Bavin (pondlife) - Wednesday, 18 March 2009, 17:42 GMT+2
According to  FS#9955 , this is also true if the start screen is set to Database. I have not verified this personally though.
Comment by Frank Gevaerts (fg) - Thursday, 21 May 2009, 16:28 GMT+2
This patch unifies rockbox usb and hardware bridge init order. It seems to fix the issue on my e200.
   usb_init_order.diff (0.7 KiB) 
 apps/main.c |    6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

Comment by Frank Gevaerts (fg) - Thursday, 21 May 2009, 21:10 GMT+2
ok, this doesn't fix the issue after all...
Comment by Frank Gevaerts (fg) - Thursday, 21 May 2009, 23:34 GMT+2
The problem seems to be in apps/action.c, in action_userabort(). This function throws away system events.

This actually makes usb connections not work in more circumstances than just booting with specific start screens. Any long-running task that uses action_userabort() is vulnerable, like e.g. inserting lots of tracks in a playlist.

Also, this isn't specific to software usb.
Comment by Frank Gevaerts (fg) - Thursday, 11 June 2009, 22:43 GMT+2
There's more than this unfortunately. The recording screen and WPS still don't work, and sometimes even freeze
Comment by Frank Gevaerts (fg) - Tuesday, 16 June 2009, 21:12 GMT+2
This is *not* caused by USB grabbing the audio buffer. A special build with a statically allocated buffer behaves exactly the same
Comment by Michael Chicoine (mc2739) - Tuesday, 27 October 2009, 15:44 GMT+2
It looks to me like root_menu.c switches to the start_in_screen before the USB detection has fully kicked in. This patch does not load the start_in_screen if USB_INSERTED. I'm not sure if it is the correct fix, but it does allow USB mode to work properly on bootup.
   usb_start_in_screen.patch (0.8 KiB) 
 apps/root_menu.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

Comment by Frank Gevaerts (fg) - Tuesday, 27 October 2009, 15:49 GMT+2
That patch only makes the window for things to go wrong a bit shorter. It will still fail if you plug in at the wrong time.
Comment by Michael Chicoine (mc2739) - Tuesday, 27 October 2009, 16:39 GMT+2
>It will still fail if you plug in at the wrong time.

Can usb connections be prevented or delayed during these tasks that use action_userabort()?

Loading...