Testing procedure:
==================

1) You need a joystick
2) Install qjoypad, run it (either from the desktop entry, alt+f2 or a terminal; the program is loaded in the systray, so the terminal won't return.
3) Create a new layout, map some joystick buttons to keys, and test them anywhere (e.g. if you map one joystick key to the "A" keyboard key, you should be able to write "A" in any X window with your joystick).

Whiteboard: (none) => has_procedure

Testing qjoypad-4.2.0-1.mga5.x86_64.rpm.

Tested that all the gamepad buttons are recognised.
Created a custom mapping, and saved it. Was able to use the newly mapped gamepad buttons e.g. in konsole.


Two things I noticed:

- it doesn't show the name of my gamepad, it only shows "Joysticks: 1".
E.g. systemsettings shows "Logitech Logitech RumblePad 2 USB (/dev/input/js0)"

- when loading my saved keymap, there are two errors shown, which might be i18n issues in that the translated names of the buttons/axis are saved in the keymap.
I'll try to translate both error dialogs directly as qjoypad like many other Qt applications seems to ignore LC_ALL=C


1. /dev/input: keybinding file failure
Error while reading layout. Unrecognized word: achse
(achse is the german word for axis)


2. 1. /dev/input: loading failure
Error reading definition for joystick 0.


And because I can't load my keybinding, I can't also delete or edit it again via the GUI, which doesn't seem good. Takign a look at the mapping itself confirms the suspected i18n issue:


$ cat ~/.qjoypad3/test.lyt

# QJoyPad 4.2 Layout File

Joystick 1 {
        Achse 1: +key 0, -key 0
        Achse 2: +key 0, -key 0
        Achse 3: +key 0, -key 0
        Achse 4: +key 0, -key 0
        Achse 5: +key 0, -key 0
        Achse 6: +key 0, -key 0
        Taste 1: key 38
        Taste 2: key 53
        Taste 3: key 0
        Taste 4: key 0
        Taste 5: key 0
        Taste 6: key 0
        Taste 7: key 0
        Taste 8: key 0
        Taste 9: key 0
        Taste 10: key 0
        Taste 11: key 0
        Taste 12: key 0
}

After "urpmi --downgrade qjoypad-4.1.0" and deleting ~/.qjoypad3/test.lyt
tested the same with the older version, it does not show this problem. But the older version also doesn't appear to be translated. So seems like a clear regression to me.

Apart from that, qjoypad 4.1.0 only seems to save the buttons in a keybinding that were actually changed away from the empty default, 4.2.0 saves everything.
This is what the same keybinding looks in the older version:

$ cat ~/.qjoypad3/test.lyt 
# QJoyPad 4.1 Layout File

Joystick 1 {
        Button 1: key 38
        Button 2: key 53
}


Yeah I was lazy and only assigned two buttons, same as before. :p

Reassigning back to packager.

CC: (none) => doktor5000
Assignee: qa-bugs => rverschelde

(In reply to Florian Hubold from comment #2)
> Testing qjoypad-4.2.0-1.mga5.x86_64.rpm.
> 
> Tested that all the gamepad buttons are recognised.
> Created a custom mapping, and saved it. Was able to use the newly mapped
> gamepad buttons e.g. in konsole.

Thanks for the thorough testing Florian.
> 
> Two things I noticed:
> 
> - it doesn't show the name of my gamepad, it only shows "Joysticks: 1".
> E.g. systemsettings shows "Logitech Logitech RumblePad 2 USB
> (/dev/input/js0)"

For my own gamepad it works fine in the new version, while it did not work in the old. Is it the same for you with both versions? If so, could you file a ticket upstream? https://github.com/panzi/qjoypad/issues
> 
> - when loading my saved keymap, there are two errors shown, which might be
> i18n issues in that the translated names of the buttons/axis are saved in
> the keymap.
> I'll try to translate both error dialogs directly as qjoypad like many other
> Qt applications seems to ignore LC_ALL=C

I think Qt applications might answer to LANG=en or LANGUAGE=en.

> 
> 1. /dev/input: keybinding file failure
> Error while reading layout. Unrecognized word: achse
> (achse is the german word for axis)
> 
> 
> 2. 1. /dev/input: loading failure
> Error reading definition for joystick 0.

For this second error, I think I might have seen something similar after upgrading from 4.1.0 to 4.2.0, maybe 4.1.0 used "0" for the 1st joystick while 4.2.0 uses "1"? I'll have a look too.

[...]
> After "urpmi --downgrade qjoypad-4.1.0" and deleting ~/.qjoypad3/test.lyt
> tested the same with the older version, it does not show this problem. But
> the older version also doesn't appear to be translated. So seems like a
> clear regression to me.

I opened a ticket for this: https://github.com/panzi/qjoypad/issues/8

> Apart from that, qjoypad 4.1.0 only seems to save the buttons in a
> keybinding that were actually changed away from the empty default, 4.2.0
> saves everything.
> This is what the same keybinding looks in the older version:

and also mentioned this in the same ticket (I know, it's bad to mention too issues in one report, but since this one is mostly a cosmetic one... ;)).

Upstream has released a new bugfix version to address most of Florian's feedback, so here it is:

Advisory:
=========

Updated qjoypad provides many enhancements

  QJoyPad has a new maintainer since 2014 who published a new release with many
  bugfixes (memory leaks, packaging) and feature improvements (joystick name
  recognition, display of saved key bindings, etc.).

  Due to the age of the previous release in Mageia 5, we provide the new 4.2.1
  version as an update.

References:
 - https://github.com/panzi/qjoypad


SRPM:
=====
 - qjoypad-4.2.1-1.mga5

RPM:
====
qjoypad-4.2.1-1.mga5

Assignee: rverschelde => qa-bugs

Tested qjoypad-4.2.1-1.mga5.x86_64.rpm

All mentioned issues have been fixed, it also displays the gamepad name correctly now and it brings translation support. Go from me for 4.2.1, and thanks to Remi for packaging it and to Mathias for fixing the reported issues on the same day ( even when he didn't have time :) )

Status: NEW => ASSIGNED
Whiteboard: has_procedure advisory => has_procedure advisory MGA5-64-OK

Validating. Advisory updated.

Please push to 5 updates

Thanks

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGAA-2015-0210.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED