Bug#1034583: kodi-game-libretro: Joystick input doesn't work in games

2023-04-18 Thread Hugh Cole-Baker
Package: kodi-game-libretro
Version: 20.2.2-2
Severity: normal

Dear Maintainer,

In Kodi 20 in Debian testing, game addons don't seem to receive any input from
a USB game controller.

I have an attached USB game controller (VID 2dc8, PID 9001, 8Bitdo NES30 Pro)
which is working OK to control the user interface in Kodi to navigate menus,
etc, but when I launch a game in Kodi, the game doesn't receive any input from
the controller. The Kodi UI still seems to receive game controller input while
the game is running, for example I can press Select+Start to exit the game,
or hold Start to bring up the Kodi game settings menu, but the actual game
can't be controlled at all.

This is a regression from the previous version, since I had the same game
controller working with the libretro-based game addons in Kodi 19 on Bullseye.

I have mapped the buttons in Kodi's settings for both the default type of
controller (named "Kodi" in the UI) and the "Super Nintendo" control scheme,
and have tested and found this problem with the libretro
"kodi-game-libretro-bsnes-mercury-performance" Debian package, but also with
other libretro addons I've built locally, so I don't think it's specific to
any single libretro game addon, and the controller works fine in other Kodi
UI, so kodi-game-libretro seemed like the most appropriate package to report
the bug against.

Some things I've noticed that could be useful info:
- if I hold Start while a game is running in the BSNES emulator, and go into
  Settings->Controls, the Kodi UI shows "Super Nintendo" under the controller
  profile, and a picture of a SNES gamepad, but under the list of "Buttons"
  it says "Nothing to map". I'd sorta expect the SNES gamepad buttons to be
  listed there.
- If I turn on debug logging in Kodi, for every button press while a game is
  running, I can see 2 log messages about the button being ignored and one
  about it being handled, e.g.:
  debug : BUTTON [ 11 ] on "8Bitdo NES30 Pro   8Bitdo NES30 Pro" 
pressed
  debug : FEATURE [ start ] on game.controller.default pressed 
(ignored)
  debug : FEATURE [ start ] on game.controller.snes pressed (ignored)
  debug : FEATURE [ start ] on game.controller.default pressed 
(handled)
- I'm using Kodi GBM 'windowing', i.e. running it without X or Wayland.
- Other maybe-relevant package versions: kodi-peripheral-joystick 20.1.3+ds-1,
  kodi-game-libretro-bsnes-mercury-performance 094+git20220807-6

I'm happy to test patches or recompile Kodi/addons to help debugging.
Regards, Hugh

-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 6.0.3-g54e50e1b1-sigmaris (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kodi-game-libretro depends on:
ii  kodi [kodi-api-main]  2:20.1+dfsg-1
pn  kodi-api-filesystem   
pn  kodi-api-game 
pn  kodi-api-general  
ii  libc6 2.36-8
ii  libgcc-s1 12.2.0-14
ii  libstdc++612.2.0-14
ii  libtinyxml2.6.2v5 2.6.2-6

kodi-game-libretro recommends no packages.

kodi-game-libretro suggests no packages.

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LC_TERMINAL = "iTerm2",
LANG = "en_GB.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory



Bug#999482: architecture-independent package contains arch-specific lib path

2021-11-11 Thread Hugh Cole-Baker
Package: kodi-addons-dev-common
Version: 2:19.3+dfsg1-1

In this package with Architecture: all, there is a file,
/usr/share/kodi/cmake/KodiConfig.cmake
containing:

...cut...
if(NOT KODI_LIB_DIR)
  set(KODI_LIB_DIR /usr/lib/x86_64-linux-gnu/kodi)
endif()
if(NOT KODI_DATA_DIR)
  set(KODI_DATA_DIR /usr/share/kodi)
endif()
set(APP_RENDER_SYSTEM gl)
list(APPEND CMAKE_MODULE_PATH /usr/lib/x86_64-linux-gnu/kodi 
/usr/share/kodi/cmake)
...cut...

The paths containing /usr/lib/x86_64-linux-gnu here later cause problems when
building addons on other architectures, as it overrides the addon install
path - a warning is logged:

CMake Warning at /usr/share/kodi/cmake/AddonHelpers.cmake:332 (message):
  CMAKE_INSTALL_LIBDIR lib/arm-linux-gnueabihf differs from Kodi libdir,
  changing to /usr/lib/x86_64-linux-gnu/kodi.  Please pass -DOVERRIDE_PATHS=1
  to skip this check
Call Stack (most recent call first):
  CMakeLists.txt:36 (build_addon)

and the addon libraries end up installed in the wrong location. It seems that
this file should be part of an architecture-specific package, with the correct
paths for the architecture in the file.

BR,
Hugh Cole-Baker


Bug#964926: systemd: systemctl show prints "Failed to parse bus message: Invalid argument" before output

2020-07-14 Thread Hugh Cole-Baker
It turns out this is just caused by running a 5.8-rc kernel with systemd
compiled against linux-libc-dev 5.7, there's a new capability cap_bpf
that systemctl fails to display since it's not in linux/capability.h.

The same issue is described here, with a link to the upstream fix:

https://bugzilla.redhat.com/show_bug.cgi?id=1853736



Bug#964926: systemd: systemctl show prints "Failed to parse bus message: Invalid argument" before output

2020-07-12 Thread Hugh Cole-Baker
I just realised after doing some further testing that this report may
not be very useful, since the bug doesn't occur on the standard bullseye
linux-image-arm64 kernel - only on a kernel I compiled with customised
options. I will do some more debugging to provide more information on
the relation of this bug to the kernel options.



Bug#716879: uwsgi: Gevent plugin/capability is missing

2014-05-13 Thread Hugh Cole-Baker
There is now a package for gevent 1.0 
(https://packages.debian.org/sid/python-gevent),
will this allow the gevent plugin for uWSGI to be packaged?

Thanks,
Hugh

--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org