Jump to content

d23

Members
  • Posts

    6
  • Joined

  • Last visited

Everything 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: 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.
  2. 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
  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. Thanks stacy... yeah, I can not su when I use adb. I might have to do a reflash, though I have a suggestion from another forum to try out first. That helps because I hadn't see reflash though, so this helps a lot.
  5. 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.
  6. 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.
×
×
  • Create New...