Announcement

Collapse
No announcement yet.

Announcement

Collapse
No announcement yet.

Prometheus Universal Remote Setup (For any Amlogic board with IR)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Prometheus Universal Remote Setup (For any Amlogic board with IR)

    This is a guide on how to set it up.

    First, the Tronsmart Prometheus (or clone or g18ref or whatever) normally comes with a 38khz Vishay IR receiver (TSOP34838 marked VS838, fairly common cheap sensor ~$1.50). The Amlogic SOC has a hardware NEC Remote protocol decoder. The Amlogic Remote software can also support RC5 and RC6 remote protocols in software, but I have not figured that out yet. So you need a remote with NEC remote protocol support. More on this in a minute.

    In my case, I use a Comcast/Xfinity Remote control, which is really a UEI JP1.x Universal Remote Control. It has a ton of different device profiles, and can add and remove buttons, add secondary functions, or even macros, for a fully customized layout, manually. If you use the JP1.x port and some software, you can add so much more to it. Hifi-remote.com and getzweb.net/jp1 are great sources of information for them.

    The reason I mention that is because I used a random NEC device code to program my Prometheus. It can be any with the NEC protocol, but try to find one which has most of the buttons pre-programmed. Mine was cable box code 899 added to the Cable button. Each device code can send up to 255 scan codes. (0x00 - 0xff).

    There are four files/programs you will use:
    Code:
    * dmesg :     Where you will get your information
    * Remotecfg :     Used to load new Remote.conf files and checking for errors in them
    * /system/etc/Remote.conf :     File which maps your remote scan codes to linux key codes
    * /system/usr/keylayout/Vendor_0001_Product_0001.kl :     File which turns Linux Key codes to Android Key codes for the Amlogic IR device
    By default, the original Remote.conf should have debugging enabled and be set to a factory code of 0xff000001.

    If you aim your NEC control at the Prometheus and press a few buttons, run "busybox dmesg", you should see something similar to:
    Code:
    [ 5094.377000] Wrong custom code is 0x[B][COLOR=#0000FF]XX[/COLOR][COLOR=#FF0000]YY[/COLOR][COLOR=#008000]ZZZZ[/COLOR][/B]
    [ 5095.872000] Wrong custom code is 0xef109c21
    [ 5097.694000] Wrong custom code is 0xee119c21
    If you don't see something similar, that remote does not have a NEC protocol. Find another one (or program a different device code). If you do, the code breaks down to 0x (Hex), XX (Checksum?), YY (scancode), ZZZZ (Device code). This means you will use a factorycode of 0xZZZZ0001 or 0x9c210001 in the remote.conf file. You will need this.

    Before we edit the remote.conf file, we can pull all the scancodes from here.
    1: Run "dmesg -c" to read then clear the dmesg log.
    2: Press every button on your remote Once (Keep track of the order)
    3: Run "dmesg | grep "code is 0x" | rev | cut -c 5-6 -c 9-10 | rev | uniq >> /IRDump.log"
    This will create /IRDump.log with a list of scan codes, one for each button you pressed, in 0xYY format. These will be used in your Remote.conf file. They should match the order you pressed them in, if not, you will get mixed up buttons later.

    Next is the Remote.conf file. The default is in (/system)/etc/Remote.conf. This is where the Android Init file for the Prometheus loads it from. Since System is mounted Read Only at start, you will need to be Root. Run "mount -o remount,rw /system" then make a backup just in case "cp /etc/Remote.conf /etc/Remote.conf.bk". Now we can edit the file. The first edit is the factorycode. You should change it like above (For me "factorycode = 0x9c210001")

    The second is everything between key_begin and key_end. Delete it, and copy your IRDump.log into it. Now comes the annoying part. Mapping each line to a keycode. The format will be scancode, space, keycode (in 0xYY hex, or decimal with no leading zero). It can only be space, not a tab or anything else or Remotecfg will segfault. The default keycodes for the Amlogic IR Device are in /system/usr/Vendor_0001_Product_0001.kl. Format is "key Linux-Keycode Android-Keycode". The LinuxKeycode is what will be produced when your scancode is seen. Then the linux subsystem will send the AndroidKey to the Android system. (you might see FUNCTION, WAKE, WAKE_DROPPED, those parts can be left) The Keycode is fairly arbitrary, but must match between Remote.conf and Vendor_0001_Product_0001.kl

    Code:
    Remote.conf           | Vendor_0001_Product_0001.kl
    0xff 242    ;Help     | key 242   APPSETTING    # SettingsMBox
    In that case, Scancode 0xff (The Help Button on the remote) produces linux-keycode 242, which produces the "APPSETTING" Android-Keycode. That launches the SettingsMbox app btw. There is no reason that keycode 242 produces appsetting, it could be 1, its arbitrary, just has to match between the two files.

    Notes. Multiple scancodes in the remote.conf can produce the same keycode. So the "Last" and "Exit" buttons can both produce keycode 158 which is the Android Back key. And multiple keycodes in the .kl can produce the same Android codes. But the same scancode can only produce the last keycode listed. And the same keycode will only produce the last android code listed (if it passes validation at all).
    Code:
    Remote.conf
    0xff 241    ;Help
    0xff 242    ;Help
    Vendor_0001_Product_0001.kl
    key 242   APPSETTING    # SettingsMBox
    key 242   APPCAMERA    # SCREENSHOT
    In this case, the Help button scancode 0xff will only produce 242, which will only produce APPCAMERA (Takes screenshots, surprise ).

    You can edit the Vendor_0001_Product_0001.kl file as well, but the only way to test it is reboot. If the KeylayoutMap library sees an error, it won't load it ("dmesg | grep KeylayoutMap" to check for errors). I pulled every valid Android code from the prometheus framework to the included AMLogic_Keycodes.txt to avoid those errors (just remove the "KEYCODE_" part). Not all will do something, depends on the app really.

    Remote.conf can be tested right away. Run "remotecfg /path/to/remote.conf" and you will see it read everything, and you can start pressing buttons.

    Included is my remote.conf and modified Vendor_0001_Product_0001.kl with comments and expanded settings, an annotated Amlogic remote setup guide (google translate + adjustments) and the AMLogic_Keycodes.txt.

    Useful notes. The POWER and ENDCALL android keycodes will turn off the Prometheus, but since power is cut to the usb hub or usb system or the 5v regulating ic section, and the IR stops responding afaik, the only way to turn it back on is flipping the power switch . The APPSETTING brings up the SettingsMbox, APPCAMERA takes a screenshot, DPAD_CENTER is the left mouse click (acts like the trackball click, very important), and APP_SWITCH brings up recent tasks! Unfortunately the Notifications keycode doesn't do anything?? Ugh.pro_remote.zip

    The dpad directions and volume keys, Home, Menu, Back, Search (or Assist for direct to google search) are all important. As is Enter and Escape, which act differently from DPAD_Center and Back btw.

    UPDATE: Special Function Mouse settings
    Just figured out the mouse feature. Adding an IRcode to "fn_key_scancode" will make it work like a toggle for the mouse. The rest act like the directions, left mouse click/finger press (with long press support), and the mouse forward/back buttons (Used to scroll up or down a screen!). These can be unique buttons, or they can be the same buttons, using the same method to find the scancodes as before. My setup turns 2, 4, 6, 8 into the mouse directions, 5 as the mouse click. The function key has to be pressed once to turn it on, again to turn it off. This should go between the factory code and the key_begin code.
    Code:
    fn_key_scancode    = 0x78
    left_key_scancode  = 0x16
    right_key_scancode = 0x17
    up_key_scancode    = 0x13
    down_key_scancode  = 0x0d
    ok_key_scancode    = 0x14
    pageup_key_scancode = 0x18
    pagedown_key_scancode = 0x19

    pro_remote.zip
    Attached Files
    Last edited by cde; 02-07-2018, 02:30.

    #2


    VERY NICE info!

    Thanks for sharing.

    Bob
    "Pzebacz im, bo nie wiedzą, co czynią"
    "Прости им, они не ведают, что творят"
    "Perdona loro perché non sanno quello che fanno"
    "Vergib ihnen, denn sie wissen nicht, was sie tun"
    "Vergeef hen want ze weten niet wat ze doen"
    "Pardonne-leur car ils ne savent pas ce qu'ils font"
    "Perdónalos porque no saben que lo que hacen"
    "Oprosti im, jer ne znaju što čine"
    "Forgive them as they know not what they do"





    Comment


      #3
      Originally posted by Finless View Post

      VERY NICE info!

      Thanks for sharing.

      Bob
      Thank you for your roms (not just for the Prometheus, but an old polaroid Tablet you provided for a year or two back).

      In any case, next time you open the prometheus up, could you note the IR sensor model number? Should be on the top, VS 38 or similar. Some nice high res pics of the top and bottom of the whole board would help too :P. Right off the bat, I'm thinking maybe adding in the second root usb port. Too bad it seems the usb-otg detection pin isn't broken out, so host only.

      Comment


        #4
        VS838 is what mine says.
        I will take pics later when I have a chance but there are pics of this board n the unbrick thread.

        Bob
        "Pzebacz im, bo nie wiedzą, co czynią"
        "Прости им, они не ведают, что творят"
        "Perdona loro perché non sanno quello che fanno"
        "Vergib ihnen, denn sie wissen nicht, was sie tun"
        "Vergeef hen want ze weten niet wat ze doen"
        "Pardonne-leur car ils ne savent pas ce qu'ils font"
        "Perdónalos porque no saben que lo que hacen"
        "Oprosti im, jer ne znaju što čine"
        "Forgive them as they know not what they do"





        Comment


          #5
          UPDATE: Special Function Mouse settings

          Comment


            #6
            SUCCESS! My hard headedness pays off. I have found how to bring the device back out of standby, by going through the 255 EFC button codes, one by one.

            A button mapped to the Android Power will put the Prometheus in a standby mode (Literally "Screen_Off"). Drives safely unmounted, HDMI powered down, USB devices deenumerated, etc. Blue led will be off. In this state, most of the android system is off, including the mapping of IR codes to Scancodes to Android Keycodes, so the normal power button you used will not work...

            Except if it's the apparently hardcoded internal IR code 0x0A. The remote button that sends a 0x0A code will turn the system back on. This works great if you have a USB drive that won't mount because of a timeout, since USB data is completely turned off then turned back on, like plugging in a cable.
            If you have a reprogrammable control like mine, it's simple enough to change the power button to send that code (EFC 55 on the Cable 00899 profile). If not, well, your sol.

            The default remote.conf has 0x0A as the power button. The first gen midnight g2 box remotes have 0x0A as the tab keycode, but it's the music button on the remote.

            I still have 189 very tedious button codes to go through in standby mode, to see what happens. And then do all 255 in power on mode to see what happens. Maybe there is a reboot ir code.

            Comment


              #7
              Excellent topic!!
              You guys rock!
              Gotta find some time to read everything and give a couple of my remotes and see if it works.
              Thanks a bunch.
              Cheers
              Tronsmart "Prometheus" VS-ATV-106
              Dualcore 8726-M6 @ 1.5GHz - 1GB RAM 8GB iSD
              Finless ROM 1.3 - Android 4.2.2
              XBMC v13 RC1

              Comment


                #8
                Thanks cde. I just asked a question http://www.freaktab.com/showthread.p...ontrol-trouble... but now feel dumb that I didn't see yours first.

                Hopefully your thread will lead me to the promised land.

                Comment


                  #9
                  Update:

                  XBMC Linux firmwares for AMlogic boards can also use the information in the main post. The remote.conf that is used is not in the regular place (/etc/remote.conf). Instead, the init file will try to load /root/.xbmc/remote.conf if it exists, or else it loads the default file at/etc/xbmc/remote.conf

                  Additionally, the program that reads the config file is called amremote_config

                  New post since I can't edit the main post anymore.

                  Comment


                    #10
                    If I understand this correctly... I could put a custom remote.conf into /system/etc for navigating around Android and another into /etc/xbmc for XBMC. Does that sound right?

                    Comment


                      #11
                      Originally posted by superfreak79 View Post
                      If I understand this correctly... I could put a custom remote.conf into /system/etc for navigating around Android and another into /etc/xbmc for XBMC. Does that sound right?
                      No. The default init loads /etc/remote.conf. Then the added xbmc init files try to load /root/.xbmc/remote.conf. If that doesn't exists, it loads /etc/xbmc/remote.conf. Like before, only the last loaded file actually matters. And it's for everything, not just xbmc.

                      Comment


                        #12
                        Originally posted by cde View Post
                        No. The default init loads /etc/remote.conf. Then the added xbmc init files try to load /root/.xbmc/remote.conf. If that doesn't exists, it loads /etc/xbmc/remote.conf. Like before, only the last loaded file actually matters. And it's for everything, not just xbmc.
                        Oh shiiiiiiiiiiiiiiiiit. I just had custom remote.conf in /system/etc and had been using remotecfg to trigger it. Duh, that's why on reboot it didn't work until I remotecfg again! Sound right?

                        Back to my previous question, is it possible to have a remote.config for Android actions and then another for within XBMC?

                        Comment


                          #13
                          mele f10 pro

                          Hello, I have a Gbox Mx2 clone (g18ref) and I would like to turn on/off the device using Mele f10 pro. Is there a possibility?

                          Comment


                            #14
                            Originally posted by meriox View Post
                            Hello, I have a Gbox Mx2 clone (g18ref) and I would like to turn on/off the device using Mele f10 pro. Is there a possibility?
                            I don't know 100%... but you can try dmesg approach described in OP.t If it worked for me, it could work for you

                            Comment


                              #15
                              Originally posted by meriox View Post
                              Hello, I have a Gbox Mx2 clone (g18ref) and I would like to turn on/off the device using Mele f10 pro. Is there a possibility?
                              The Mele f10 Pro is a remote with a 2.4ghz usb receiver. It does not use the IR sensor on AMLOGIC boards. The Mele f10 Pro does have an IR part to it, but unless you can program it to send IR code 0x0A, it will not turn the box back on.

                              Comment

                              Working...
                              X