X5: Remote LCD Progress/Bugs

[Eriol]

Downloaded the CVS build for 2006-07-28 13:36 after the "remote LCD support".

Well it kinda works.  Interesting to see the rockbox logo come up on boot, etc.  Also interesting to see how much DOES work inside the player itself (basically all the menus and the "normal" display while playing works).

Now for what doesn't work:

• The entire background isn't blank, but rather in the lightest shade there.  That may be some type of translation of the "normal" display having a non-clear background (it's a light shade), but on the remote... well you can hardly see the actual text itself.  But I think that's a config problem.  When I went into the remote contrast setting, the value displayed was "42".  I reduced that, and the background went clear, but I couldn't raise it back up any higher than 29.  So I think that perhaps the max allowable is 29 on this remote, but the default (wherever that's set) is 42, which causes the problem.  So most likely a "#define" fix only is needed.
• Remote keys still don't work.  Probably an unrelated sub-system to the LCD display, but I think it's worth mentioning.
• On shutdown, I get a solid line 1-2 pixels wide across the top of the remote LCD screen itself after the main display has shut down, and the remote is otherwise blank as well.  Well, on the first time the line was across the top.  Second time it was in the middle, then changed to a large filled-in square, then that display inversed, and THEN the display blanked out.  I'm wondering if there's a problem with remote lcd shutdown when the rest of the player is shutting down.
• Kind of out-of-order, but before those other glitches in shutdown, when the "shutting down" message is displayed on the main screen, the same shape (the box surrounding "shutting down") is shown on the remote, though it is completely filled in, with no words visible

I'll list more bugs as I find them.  Great work so far though guys.  You've done a remarkable amount in a short amount of time.

[RaeNye]

Do remote buttons work in the debug->view IO thingy?

If so, please write down the byte value for every remote button press
(e.g., FF for nothing pressed) and I'll add these to the ADC button driver.

[RaeNye]

Another thing, might be related to the shutdown problem.

lcd_remote_powersave() in target/.../lcd-remote-x5.c does

Code: [Select]

    if(remote_initialized) {
        if (on)
            lcd_remote_write_command(LCD_SET_POWER_SAVE | 1);
        else
            lcd_remote_write_command(LCD_SET_POWER_SAVE | 1);
    }

 

[Eriol]

OK Rae.  Here's the codes.  These were all the ADC_REMOTE value on the IO menu.  For reference, some images of the remote can be found on the cowon site here.

Hold key enabled: 00 (and all keys did nothing when this was enabled as such)
Hold key disabled: FF (and no keys pressed)

Menu-wheel (bottom of the remote):
pressed-in: A5 (in X5 firmware, same as "select" key usually, short-press gets you to playlist/files, long-press to menu, same as pressing in the "knob" on the main device)
Vol - : DE (volume minus, menus up)
Vol + : C4 (volume down, menus down)
(note, menus up/down is OPPOSITE of what the volume +/- keys are on the knob on the main unit when using X5 firmware, as the knob volume + is up, but from the remote, volume + is down)

Mode Key: 6D (though went from D-E occasionally, switching during testing, though when "held" to the value constantly, the end value is 6D.  Probably due to A/D conversion.  This is an "extra" button that really isn't on the X5 base unit, and just goes direct to menu)
Rec A-B: 87

Rewind/FF Wheel ("top" of the remote, same side as mode and "Rec A-B" keys)
pressed in: Not on ADC_REMOTE, but rather the second hex value (from the left) on GPIO_READ which goes from "E" to "C" when hold on the main unit is NOT on, and from "6" to "4" when hold IS enabled (this means it's 2nd bit from the right in that... obviously).  Also note that the "hold" state on the remote doesn't affect this bit shift in any way at all (this is the "play/pause" key usually.  Also functions as the power key when held for the X5, hence why it's probably on GPIO, and not on the ADC_REMOTE)
rewind: 54 (also sometimes "twitches" to 53, again A/D problems)
FF: 2F (though also often twitches to 2E)
Rewind and FF are usually EXACTLY correlated to left (rewind) and right (FF) on the main X5 stick for everything in the unit's menus.

What may be expected behavior from the ADC driver is that certain keypresses "prioritize" over others, only displaying the code for the higher priority button, so there doesn't seem to be a way to detect more than one key down at once (unless it's with the play button, which is obviously different).

Also of note is that the debug screen didn't appear on the remote.  All the other menuing stuff appears to, but the debug screen itself didn't.  Display merely stayed on the last previous menu.

And that code snipped is rather... odd Rae.  I quite agree with you.

[LinusN]

Do remote buttons work in the debug->view IO thingy?

If so, please write down the byte value for every remote button press
(e.g., FF for nothing pressed) and I'll add these to the ADC button driver.

You might have noticed that the button driver has supported the remote control since march 9.

The reason that the remote buttons aren't working is that they haven't been mapped to any actions in the button definition tables. I have deliberately waited with this, since we are introducing a whole new concept for the button to action mapping.

[LinusN]

Also of note is that the debug screen didn't appear on the remote.  All the other menuing stuff appears to, but the debug screen itself didn't.  Display merely stayed on the last previous menu.

Of course. We don't want to spend work and add to the memory footprint by adding a remote display of a screen that is only meant foir debugging.

And that code snipped is rather... odd Rae.  I quite agree with you.

Yes it's a bug. That function isn't used, so nobody noticed.