Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Drivers
  • Assigned To No-one
  • Operating System Another
  • Severity Low
  • Priority Very Low
  • Reported Version Version 3.2
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by bertrik - 2009-06-06
Last edited by bertrik - 2009-06-11

FS#10285 - Sansa clip alternative button driver

Attached is an alternative driver for the Sansa Clip. This driver uses a kernel tick task to scan the button matrix.

Features:
+ fixes sansa clip button issues from  FS#10048  + no more explicit delays needed that need to be tuned so they work for all processor speeds.
+ the mechanism used may be suitable for other ams targets that use a button matrix too
- it can take up to three kernel tick (30 ms) for a button to be detected, so please test if you notice any latency issues
- buttons are scanned even when no application is asking for buttons to be read
- not tested in the bootloader yet

Closed by  bertrik
2009-06-11 22:18
Reason for closing:  Accepted
Additional comments about closing:  

Committed as svn revision 21253

very responsive : i played a bit chopper and snake2 at maximal speed without problems

Tested in bootloader: I had to enable interrupts before button driver is used, and also to sleep for 3 ticks.

Since the driver is responsive (just try snake at maximum level), the only problem remaining is that buttons are scanned even when not requested.

Can this draw more power from the battery ?

Don’t use an extra kernel tick since button_read_device() is already called from a tick.

Could be done for m200v4 also but needs a tester

Attached patch is very similar to funman’s, but scans all three rows at button initialisation to get an initial button state, instead of enabling irqs and doing a sleep(3) in the bootloader.

have you tested it in the bootloader ? (press any button to get verbose rockbox loading)

Some buttons could not be read if the delay between row setting and column reading is not important enough.

Yes, I tested it in the bootloader. I see the bootloader text (”Loading firmware..”) when pressing a button during boot (any button except left or down, those cause the OF to boot).

The down button causing OF boot is a bug in mkamsboot’ dualboot.S - not related to this task.

So is there anything left or the patch can be committed?

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing