Jump to content
Flirc Forums

d23

Members
  • Posts

    6
  • Joined

  • Last visited

Posts posted by d23

  1. I have an update to this.  You might have noticed that the .kl file gets wiped every time there is a system update if it is put in /system/usr/keylayout/.  Since Ouya has had an update a week this is a problem.  Here's the solution for that...

     

    In the android dev site I found this information about the .kl files:

     

    Key layout files are located by USB vendor, product (and optionally version) id or by input device name.

    The following paths are consulted in order.

    • /system/usr/keylayout/Vendor_XXXX_Product_XXXX_Version_XXXX.kl
    • /system/usr/keylayout/Vendor_XXXX_Product_XXXX.kl
    • /system/usr/keylayout/DEVICE_NAME.kl
    • /data/system/devices/keylayout/Vendor_XXXX_Product_XXXX_Version_XXXX.kl
    • /data/system/devices/keylayout/Vendor_XXXX_Product_XXXX.kl
    • /data/system/devices/keylayout/DEVICE_NAME.kl
    • /system/usr/keylayout/Generic.kl
    • /data/system/devices/keylayout/Generic.kl

    When constructing a file path that contains the device name, all characters in the device name other than '0'-'9', 'a'-'z', 'A'-'Z', '-' or '' are replaced by ''.

     

    The major difference between /system and /data (not noted here) is that /system is what is wiped and replaced when the Android image is updated, so it is a bad spot to put user fixes.   /data is where all your user settings and packages go and they are left untouched on an Ouya system upgrade.

     

    So, to put it in a nutshell, but the Vendor_20a0_Product_0001.kl file in /data/system/devices/keylayout.  You will probably need to create these directores on your Ouya.  I did on mine and it works as this is a basic Android behavior for Android keylayout files.

     

    I held off on posting this to make sure that I was correct.  After the Ouya system upgrade from this week it still continues to work.

    • Like 1
  2. Hi, 

     

    I'm just working through the keymaps for my Flirc/Ouya/Harmony and came across your post. 

     

    Care to share your .kl file? I'm not sure I understand what you have changed in the files above to get the fix for enter and escape working on the remote. 

     

    Are you mapping the Ouya controller O and A buttons to act exclusively as enter and escape respectively on the Ouya itself? Does this affect the usability at all? I've noticed that I HAVE to use the O and A buttons on the controller some times so wouldn't removing the map for those also remove their ability to behave as intended and render the controller useless? 

     

    I have my Harmony setup well for navigating plex as plex interprets enter and escape correctly. It's just when I get back into the main menu's that I have to use the controller to navigate around/back into plex. 

     

    Thanks in advance. 

     

    Sorry that I don't check this thread too much.  I am going to attach my current .kl file for you to take a look at. I am not sure it's finished.  It isn't well commented, but I can tell you that my changes are "key 1" and "key 28".     Key 1 and Key 28 are what Android would see as "ESC" and as "Return" respectively.  Ouya doesn't map those correctly to their usual uses, or at least it

     

    It actually doesn't affect any Ouya usability at all because you are ONLY redefining keys in resepect to FLIRC itself.  It shouldn't affect anything else.

     

    I have to admit that I didn't understand the problem with the "HOME" key until just a few minutes ago, so I don't think the home key is mapped on my .kl file.  Maybe I can experiment with that this weekend and that working as well.

     

    One last thing: don't put the .kl file where it says above.  It will be erased every time there is a system update.  I was about to post on that when I saw your question to me.

     

    --dcl

    Vendor_20a0_Product_0001.kl.zip

    • Like 1
  3. Stacy, et. al.:

     

    Glad to say that after a console reflash I have everything working.  I used the kl file here but with some modifications.

     

    To answer my own earlier question, the OUYA buttons are mapped using the usual interal keycodes:

     

    BUTTON_A = the O button

    BUTTON_B = the A button

    BUTTON_X = the U button

    BUTTON_Y = the Y button

     

    Yeah, that's a bit confusing but that the usual button layout of a playstation controller, of course.

     

    So I changed the keymap around so that "return" key on the Harmony maps to the Ouya O button and and "back" maps to the Ouya A button.  This gets around the fact that the keyboard behavor is different on differenl Ouya launch screens.  If you plug in a USB keyboard, Enter and ESC do not work on all the screens.  Hopefully as the OUYA launcher matures this will be fixed.  At that point programming the Flirc (at least for my situation as I have no home key to use) will just be a matter of mapping the correct keyboard keys.

     

    Thanks for the info... hope this helps someone as well.

     

    --dcl

  4. I was actually writing my post at the exact same time you were writing your updated post, so I haven't tried the better procedure, no.  I am having some problems with su (the procedure for completly rooting ouya has some problems and caused my original su to go to zero bytes, so I have no su on my ouya currently) so I haven't tried the new keymap.  When I get the su problem figured out then I will put the new keymap in there as it's going to be the obvious solution to the problem.  Thanks for your help.

  5. Well, I have been dealing with setting up Flirc with an Ouya and a Harmony One today.  Part of the reason I bought the Ouya was promises it will work with XBMC.  It seems like it will work pretty well, especially when there is an Ouya optimized version.

     

    Anyway, I've got everything pretty much working in XBMC by remapping some keys in Keyboard.xml (such as mapping "b" to back and "c" for context menus) and then setting Flirc to emulate those keys.  Other mappings are quite easy, like mapping the Harmony's "ok" key to "return" on the keyboard.  This works nicely in XBMC.

     

    I'd like to get it to work fine with the OUYA interface as well.  I've tried some ways to do this, but the problem that OUYA UI hasn't quite standardized itself yet.  For instance in the "Make" menu, you can hit the return key and it selects, but in the other a keyboard return does nothing.  Android itself usually has trouble with the ESC key, but oddly in OUYA it works in some circumstances and doesn't work in others.

     

    So the next idea is to use an Android program like Exernal Keyboard Helper to do some internal Android remapping so that those Harmony keys emulate keys on the OUYA controller.  However I haven't been successful in that yet either.  Here is part of the generic.kl file.

     

    key 304   BUTTON_A
    key 305   BUTTON_B
    key 306   BUTTON_C
    key 307   BUTTON_X
    key 308   BUTTON_Y
    key 309   BUTTON_Z
     

    Do constants like BUTTON_O work in this file? Does anyone know?  They aren't present in External Keyboard Helper... has anyone tried to edit the generic.kl directly to emulate the controller buttons.

    • Like 1
×
×
  • Create New...