[android] Add buttonmap for back button in Android TV Remote Control

[garbear]

Motivation and Context

Report: https://forum.kodi.tv/showthread.php?tid=308480

How Has This Been Tested?

Tested on Shield TV.

Screenshots (if appropriate):

Android TV Remote Control:

[CiNcH83]

BACK button is again non-functional after installing a nightly build. After disabling the Joystick add-on, the BACK button starts to work again.

[garbear]

Thanks for reporting, I found the issue. Will fix this week.

[garbear]

Issue is fixed, we just need a new buttonmap for Android TV Remote Control. Can you make one?

[CiNcH83]

Sure. Never done one and no clue what is wrong with the one in this PR, but I am sure I can figure this out :) .

[garbear]

Ha, forgot I did this last time. Go to controller configuration utility in settings and map the back button to back on the Kodi and remote profile (from Get More link). The resulting XML should look like this PR with some numbers being different.

[CiNcH83]

This is what came out:

<buttonmap>
    <device name="virtual-remote" provider="android" buttoncount="18">
        <controller id="game.controller.default">
            <feature name="back" button="6" />
        </controller>
        <controller id="game.controller.remote">
            <feature name="back" button="6" />
        </controller>
    </device>
</buttonmap>

However, Back again isn't the Back I am expecting. In fullscreen video it seems to bring up player controls. That whole stuff is just beyond me... Guess this mapping has to do with joystick.xml? Back button should do the equivalent to keyboard backspace IMHO.

[garbear]

You're right, the system is confusing. There are actually three buttonmaps:

• This one
• The kodi keymap
• The game add-on buttonmap

The issue is the libretro input API is so limited. It uses the "retropad" abstraction, but translating between retro controllers is a foreign concept for some of our users. The retropad introduces technological overhead that makes emulation inaccessible.

So what I've done is create a massive system of different controller "representations". That way, we can represent controllers however we need to:

• The libretro controller
• The user's physical controller
• The limited driver info
• GUI input

Here's an overview of the different representations:

Driver representation

This is how the OS sees the controller. We know very little about the controller, and all buttons/axes are anonymous. E.g.:

Name: "virtual-remote"
Button ID: 6

Topological representation

"Topology" is the way in which things are connected. You can visualize this: imagine a SNES controller next to a 360 controller, with lines drawn from each button on the SNES controller to a button on the 360 controller.

The topology uses a controller ID and strings for button names. E.g.:

Controller ID: game.controller.default
Button name: "b"

Libretro representation

This is how libretro cores see input. It is defined by libretro.h. It identifies controllers by type and buttons by an ID. E.g.:

Controller type: RETRO_DEVICE_JOYPAD
Button ID: RETRO_DEVICE_ID_JOYPAD_B

GUI representation

This is how Kodi receives input. You define a topological profile, and map the button to a GUI action. E.g.:

Controller profile: game.controller.default
Action: XBMC.Back

Do you see now why we map the back button to "b"? joystick.xml maps this button to XBMC.Back. You can see that the "back" button (Select on the SNES) has no global GUI action. So mapping driver button with ID 6 to "back" has no effect in Kodi, whereas "b" executes the back action.