Posts by escalade

    ellis

    They are compressed with texturepacker, inside the .xbt files. Have a look around in the skin folder on xbmc github to see the names.

    MoHawka

    I see what you mean now, that is very weird and doesn't happen for me. I got a white box with drop down menu next to "Profile" and I can select DS4 Bluetooth P1/P2 there which are the default profiles I have created (you can see them in /storage/.config/dolphin-emu/Profiles/GCPad). Confirmed this on a second box where I haven't run Dolphin before, it displays correctly. Check if it's happening for you on a clean image, boot a USB or something.

    20170108:

    Code
    - Fixed incompatibility with the Steam Controller driver addon
    - Changed ES theme to simple-dark for a more fresh look

    Aha, I do include enum 0.4.6 from pypi.org as a dependency to cryptography and the OP is using my build. Do you know if enum34 is compatible and could be used as a replacement?

    EDIT: It seems like it is compatible, I will use it instead.

    RShT

    For now you can use this hack as a workaround:

    Code
    # cp -a /usr/lib/python2.7/site-packages /storage/.site-packages ; rm -rf /storage/.site-packages/enum* ; mount --bind /storage/.site-packages /usr/lib/python2.7/site-packages


    With this the steamcontroller service is starting correctly:

    Code
    Jan 08 12:14:28 Tronsmart systemd[1]: Starting a standalone userland driver for the steam controller...
    Jan 08 12:14:29 Tronsmart sc-xbox.py[3223]: sc-xbox.py: started
    Jan 08 12:14:29 Tronsmart kernel: input: Microsoft X-Box 360 pad as /devices/virtual/input/input7
    Jan 08 12:14:29 Tronsmart kernel: input: Steam Controller Keyboard as /devices/virtual/input/input8
    Jan 08 12:14:29 Tronsmart kernel: input: Steam Controller Mouse as /devices/virtual/input/input9
    Jan 08 12:14:29 Tronsmart systemd[1]: driver.steamcontroller.service: Supervising process 3223 which is not our child. We'll most likely not notice when it exits.
    Jan 08 12:14:29 Tronsmart systemd[1]: Started a standalone userland driver for the steam controller.

    You can put the commands in /storage/.config/autostart.sh to have them executed on startup.

    RShT

    Sure, I figured if the upgrade worked then it was an issue with the .img after all as my disk was full when the image got created.

    MoHawka

    That's odd, the controller config looks normal here. Can you upload a photo? You can use ALT + right mouse click to start resizing a window. ALT + F10 will unmaximize a window, as they are maximized by default and ALT + TAB to switch windows.

    Blackhazard

    You could edit es_systems.cfg and add a system with name "kodi", extension ".sh" and then put a shell script named kodi.sh in the rom dir. The shellscript could just do a "killall emulationstation" and you would return to Kodi.

    Although I don't have the controller itself, I installed the Steam Controller service addon to see if there's anything obvious and there is:

    Python
    # python /storage/.kodi/addons/driver.steamcontroller/bin/sc-xbox.py start
    Traceback (most recent call last):
      File "/storage/.kodi/addons/driver.steamcontroller/bin/sc-xbox.py", line 31, in <module>
        from steamcontroller import \
      File "build.LibreELEC-Generic.x86_64-8.0.0/addons/steamcontroller/driver.steamcontroller/lib/steamcontroller/__init__.py", line 24, in <module>
    ImportError: cannot import name IntEnum

    Goga777

    You can't, as I don't keep archives. As LE uses 340.x for xf86-video-nvidia-legacy now, you'll need to build yourself for support. Just set the version you want in package.mk.

    RShT

    Actually, now you told me more. The "just enough OS for Kodi" screen is not a part of Kodi, it's a splash screen that is started very early in the boot process. So in being more descriptive I will know more about your situation. It would also help if you could tell me whether or not the latest LE alpha works as a reference point, and if you can upgrade from that.

    As for the addon, if I included the driver in my build there would still be no manual other than the information you can find on it's github page. You should start a separate thread in the addon section, as I can't tell you how the addon is supposed to work.

    RShT

    What do you mean? There's an official LibreELEC addon that should include the driver and any necessary dependency. Install it directly from Kodi. What do you mean stuck on Kodi start screen, can you see the Kodi main menu? Is it reachable by network? Any logs? Please guys, try to include as much info as possible. I can't do anything about "it doesn't work".

    FoxXav

    Have you tried adding the option back again? I'm not convinced that was the problem, as it just enables the serial console. The previous working build had that option too and it worked fine for others.

    20170105:

    Code
    - Updated Mesa brings OpenGL 4.0 for Haswell (not needed for anything in this build but might be useful for some through Docker)
    - Updated Freetype to 2.7.1 to get the new subpixel hinting
    - Fixed init install routine for zlib, parted, btrfs-progs-system, xfsprogs and f2fs-tools (this fixed booting on RPi, but Generic users should upgrade to get this fix as well)
    - CEC fixes from upstream
    - Updated packages: glupen64-libretro, mgba-libretro, libretro-database, mupen64plus-libretro, retroarch-joypad-autoconfig, mame2014-libretro, core-info, genesis-plus-gx-libretro, retroarch, dolphin, fs-uae, tyrquake-libretro

    jayfkay

    I noticed in the initramfs that /lib contained a "lib" symlink to /usr/lib, then I remembered that the RPi builds stopped working soon after the /usr merge. I had changed all my packages to install to /usr, except for the init routine which is separate. Since I had a /lib directory already, the symlink was created inside there instead of /lib itself being a symlink. When the kernel tries to start init, I think the default LD_LIBRARY_PATH only includes /lib, so the needed libraries in /usr/lib was not found when init called /bin/sh. I modified my packages to use /usr so that the /lib symlink was correctly created and pointed to /usr/lib and that was it.

    I would have seen this earlier if it wasn't for the x86_64 build having pretty much the same "incorrect" structure and it worked. Knowing the problem, I can see now that it had a proper /lib64 symlink which is probably sufficient.

    Just in time for the LE8 betas. Good thing is it made me examine pretty much every commit twice which can never hurt.