In steam while using artix linux with the mate desktop my X and Y buttons are reversed.

[LizziAS]

Version of xpadneo

pkgname=xpadneo-dkms-git pkgver=0.9.r4.gbf8a3c3

i am using openrc version of artix. on arch using systemd i have not seen this problem before. very weird. took me a while to get it workig at all with steam which is usually not the case. clearly thios seems to be a compatibility issue with openrc but perhaps you can increase compatibility?

[kakra]

Is this a Nintendo style gamepad you're using?

[LizziAS]

No it’s an ipega 9023

On Wed, Dec 16, 2020 at 9:43 PM Kai Krakow notifications@github.com wrote:

Is this a Nintendo style gamepad you're using?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/atar-axis/xpadneo/issues/265#issuecomment-747167619, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJCUBTMW37ZFRLFV7AHR7TSVFV4DANCNFSM4U63TZZQ .

[kakra]

Please post your dmesg log of the controller connecting.

[LizziAS]

And like I said. It works correctly on arch systemd. Ie x is x and y is y on arch systemsd.

Artix is arch based but uses openrc. Or runit. Or another on. I use openrc

On Wed, Dec 16, 2020 at 11:51 PM Lizzi Swane lizzi.swane@gmail.com wrote:

No it’s an ipega 9023

On Wed, Dec 16, 2020 at 9:43 PM Kai Krakow notifications@github.com wrote:

Is this a Nintendo style gamepad you're using?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/atar-axis/xpadneo/issues/265#issuecomment-747167619, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJCUBTMW37ZFRLFV7AHR7TSVFV4DANCNFSM4U63TZZQ .

[kakra]

Try disabling Steam controller input support in big picture mode. OpenRC should make no difference. Also, dmesg logs would help seeing if the driver correctly initialized or is in use at all. If you don't feel like posting it, you could at least compare it between both systems.

[LizziAS]

Where do I find a dmesg log?

On Thu, Dec 17, 2020 at 12:00 AM Kai Krakow notifications@github.com wrote:

Try disabling Steam controller input support in big picture mode. OpenRC should make no difference. Also, dmesg logs would help seeing if the driver correctly initialized or is in use at all. If you don't feel like posting it, you could at least compare it between both systems.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/atar-axis/xpadneo/issues/265#issuecomment-747205917, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJCUBRQWWUF4RKXELMZHSTSVGF5FANCNFSM4U63TZZQ .

[kakra]

Type dmesg in a terminal, or follow the instructions shown in the new issue wizard here.

[LizziAS]

https://pastebin.com/jtEUKSTn

On Thu, Dec 17, 2020 at 7:18 AM Kai Krakow notifications@github.com wrote:

Type dmesg in a terminal, or follow the instructions shown in the new issue wizard here.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/atar-axis/xpadneo/issues/265#issuecomment-747405196, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJCUBV4D3QAR2KUWNW23F3SVHZIBANCNFSM4U63TZZQ .

[LizziAS]

I gave you dmesg. You saw the pastebin?

On Thu, Dec 17, 2020 at 7:48 AM Lizzi Swane lizzi.swane@gmail.com wrote:

httos://pastebin.com/jtEUKSTn

On Thu, Dec 17, 2020 at 7:18 AM Kai Krakow notifications@github.com wrote:

Type dmesg in a terminal, or follow the instructions shown in the new issue wizard here.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/atar-axis/xpadneo/issues/265#issuecomment-747405196, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJCUBV4D3QAR2KUWNW23F3SVHZIBANCNFSM4U63TZZQ .

[kakra]

Hold your horses ;-)

I had a busy 60 hour week. I'll look into it soonish.

[LizziAS]

Sorry!!! No rush here really. Sorry!!!

On Fri, Dec 18, 2020 at 4:28 PM Kai Krakow notifications@github.com wrote:

Hold your horses ;-)

I had a busy 60 hour week. I'll look into it soonish.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/atar-axis/xpadneo/issues/265#issuecomment-748328130, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJCUBUE75P7VUPK4BBRH4DSVPCQLANCNFSM4U63TZZQ .

[kakra]

The dmesg log you posted doesn't show xpadneo loaded at all. Try reinstalling it, I've seen similar reports lately, reason unknown. It's probably udev not reloaded properly, or the xpadneo rules file not being in place. If in doubt, just reboot after updating the driver (which you probably did). Maybe check xpadneo presence in /etc/udev/rules.d.

[kakra]

OTOH, since it's openrc based, it may not support /etc/modprobe.d - I've abandoned openrc a long time ago so I cannot check. That file defines some aliases to trigger loading xpadneo when the hardware is detected. You could just force-load xpadneo instead on every boot.

Also, this looks very foreign: 0005:1949:0402.0009

Is this controller really compatible to Xbox controllers? I'll probably have to add that to the database of supported devices then. But I'd need to have a HID descriptor then.

[kakra]

I'd even argue that the other distro won't use xpadneo, too, because 0005:1949:0402.0009 is not a device ID supported by xpadneo. Are you sure the other distro uses xpadneo for your gamepad? Compare dmesg. If it neither does, this is probably an issue with an outdated SDL2 lib.

[LizziAS]

I’m. I installed xpadneo-dkms-git from the aur. It builds great. Runs on my pure arch and arch alike both using systemd and mapping buttons correctly in steam. Only the openrc based artix seems to switch the position of X and Y buttons in steam. It’s very weird

On Fri, Dec 18, 2020 at 4:45 PM Kai Krakow notifications@github.com wrote:

I'd even argue that the other distro won't use xpadneo, too, because 0005:1949:0402.0009 is not a device ID supported by xpadneo. Are you sure the other distro uses xpadneo for your gamepad? Compare dmesg. If it neither does, this is probably an issue with an outdated SDL2 lib.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/atar-axis/xpadneo/issues/265#issuecomment-748334467, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJCUBXL37TOPMTVI2F6C43SVPEN3ANCNFSM4U63TZZQ .

[kakra]

I've watched a review video of this controller. Interesting controller but not supported by xpadneo. If buttons are swapped, that's a different issue, and probably results from using different versions of SDL2 in both distros.

[LizziAS]

But it does work with xpadneo. Perhaps just by chance but it does 😍👀😇

On Fri, Dec 18, 2020 at 6:22 PM Kai Krakow notifications@github.com wrote:

I've watched a review video of this controller. Interesting controller but not supported by xpadneo. If buttons are swapped, that's a different issue, and probably results from using different versions of SDL2 in both distros.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/atar-axis/xpadneo/issues/265#issuecomment-748369759, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJCUBSCHU2QMIZV5UIVMO3SVPP2RANCNFSM4U63TZZQ .

[LizziAS]

Thanks for the lead. I’ll check it out On Fri, Dec 18, 2020 at 6:22 PM Kai Krakow notifications@github.com wrote:

I've watched a review video of this controller. Interesting controller but not supported by xpadneo. If buttons are swapped, that's a different issue, and probably results from using different versions of SDL2 in both distros.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/atar-axis/xpadneo/issues/265#issuecomment-748369759, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJCUBSCHU2QMIZV5UIVMO3SVPP2RANCNFSM4U63TZZQ .

[LizziAS]

Ty for your professional help and kindness

On Fri, Dec 18, 2020 at 6:22 PM Kai Krakow notifications@github.com wrote:

I've watched a review video of this controller. Interesting controller but not supported by xpadneo. If buttons are swapped, that's a different issue, and probably results from using different versions of SDL2 in both distros.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/atar-axis/xpadneo/issues/265#issuecomment-748369759, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJCUBSCHU2QMIZV5UIVMO3SVPP2RANCNFSM4U63TZZQ .

[LizziAS]

they are all 3 using 2.0.12-3

On Fri, Dec 18, 2020 at 7:05 PM Lizzi Swane lizzi.swane@gmail.com wrote:

Ty for your professional help and kindness

On Fri, Dec 18, 2020 at 6:22 PM Kai Krakow notifications@github.com wrote:

I've watched a review video of this controller. Interesting controller but not supported by xpadneo. If buttons are swapped, that's a different issue, and probably results from using different versions of SDL2 in both distros.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/atar-axis/xpadneo/issues/265#issuecomment-748369759, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJCUBSCHU2QMIZV5UIVMO3SVPP2RANCNFSM4U63TZZQ .

[alium]

we provide same SDL2 as arch (same PKGBUILD, just we rebuild it ). we check this problem in artixlinux... can be udev or not loaded module at boot.

[kakra]

@alium To support your debugging efforts: xpadneo matches device IDs hard-coded into the module source code. To properly trigger auto-loading, we also provide a file with module aliases, but you could actually just force-load the module at boot, it should not hurt. Finally, there's a udev rule which unbinds the device from hid-generic or hid-microsoft, and binds it to xpadneo. This udev rule also needs to know the device IDs. None of those matches the iPega ID 1949:0402, so xpadneo isn't even involved here because none of the rules or aliases match.

OTOH, SDL2 and some software ships with a controller db which has all the hardware IDs and matching button/axis mapping, so SDL2 can use even the generic HID driver to use the device. SDL2 controller DBs can be overridden by software, I think anti-micro does it. If you used some of the third-party helper tools for SDL2 to remap the controller, you probably also have an overridden controller db. Steam ships one itself. So there are a lot of different locations where the local user SDL2 installation can differ even when using the same SDL2 version.

It is very likely that LizziAS has different SDL2 controller DBs on both systems, and SDL2 just uses plain hid-generic and not hid-xpadneo - and one of those systems has a wrong mapping or none at all. SDL2 constantly updates their controller databases, I think iPega is in there. My best bet is first figuring out which SDL2 mapping is actually used, and if comes delivered by some software or is a custom one (which can sit in various locations).

[alium]

@kakra thank you very much for explanation! I have no Xbox or another device with gamepad, i am no expert in this area. LizziAS's Steam package is provided by archlinux (we have compatible packages with Archlinux, just init is another) @LizziAS can maybe try use gamepad-tool for configure his pad (https://aur.archlinux.org/packages/gamepad-tool-bin/) or add new mapping (if missing in https://github.com/gabomdq/SDL_GameControllerDB). Maybe that can help too. @LizziAS Let's check this SDL2 controller DBs

[kakra]

Here's some of my (probably outdated) research documented: https://github.com/atar-axis/xpadneo/blob/master/docs/SDL.md

[alium]

ok, thanks. his gamepad is in database. @LizziAS can set his pad as udev rules - similar as here: https://gist.github.com/rdlu/707bbb0b7da3220bdc1eadceb4ef675f

according to me he has set his pad in ArchLinux, but not on the new OS (Artixlinux). thanks for help and time @kakra . let's try to see how he has the system set up @LizziAS

[LizziAS]

https://atar-axis.github.io/xpadneo/

SDL2 Breaking Changes

As of SDL 2.0.12, SDL introduced a new HIDAPI which can read HID devices in raw mode, bypassing the drivers. Due to the way SDL works, and because xpadneo exposes hidraw devices as user-readable, SDL may see wrong button mappings because it may make wrong assumptions about the protocol mode of Xbox and compatible controllers. If you see wrong button mappings / missing buttons in SDL applications, you may need to turn off this behavior by setting an environment variable in your profile: SDL_JOYSTICK_HIDAPI=0

where is this profile that i may edit it?

On Sat, Dec 19, 2020 at 6:10 AM alium notifications@github.com wrote:

ok, thanks. his gamepad is in database. @LizziAS https://github.com/LizziAS can set his pad as udev rules - similar as here: https://gist.github.com/rdlu/707bbb0b7da3220bdc1eadceb4ef675f

according to me he has set his pad in ArchLinux, but not on the new OS (Artilinux). thanks for help and time. @kakra https://github.com/kakra . let's try to see how he has the system set up @LizziAS https://github.com/LizziAS

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/atar-axis/xpadneo/issues/265#issuecomment-748459256, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJCUBUE7MW4VNTIPS52AULSVSC3NANCNFSM4U63TZZQ .

[LizziAS]

Perhaps try to make a file called say controlpad.sh in /etc/profile.d with these contents: Code: [Select] https://forum.artixlinux.org/index.php/topic,2090.new.html#

!/bin/sh

export SDL_JOYSTICK_HIDAPI=0

Then possibly make it executable (might not be required?) Code: [Select] https://forum.artixlinux.org/index.php/topic,2090.new.html#

chmod a+x /etc/profile.d/controlpad.sh

That should put it in your env, after rebooting if you try: Code: [Select] https://forum.artixlinux.org/index.php/topic,2090.new.html#

$ env

then hopefully you will see it somewhere.

did that but it doesnt qualify as the profile i guess?

• More... https://forum.artixlinux.org/index.php/topic,2090.new.html#
• 1 Likes
• Quote https://forum.artixlinux.org/index.php?action=post;quote=14018;topic=2090.15;last_msg=14020

On Sat, Dec 19, 2020 at 8:14 PM Lizzi Swane lizzi.swane@gmail.com wrote:

https://atar-axis.github.io/xpadneo/

SDL2 Breaking Changes

As of SDL 2.0.12, SDL introduced a new HIDAPI which can read HID devices in raw mode, bypassing the drivers. Due to the way SDL works, and because xpadneo exposes hidraw devices as user-readable, SDL may see wrong button mappings because it may make wrong assumptions about the protocol mode of Xbox and compatible controllers. If you see wrong button mappings / missing buttons in SDL applications, you may need to turn off this behavior by setting an environment variable in your profile: SDL_JOYSTICK_HIDAPI=0

where is this profile that i may edit it?

On Sat, Dec 19, 2020 at 6:10 AM alium notifications@github.com wrote:

ok, thanks. his gamepad is in database. @LizziAS https://github.com/LizziAS can set his pad as udev rules - similar as here: https://gist.github.com/rdlu/707bbb0b7da3220bdc1eadceb4ef675f

according to me he has set his pad in ArchLinux, but not on the new OS (Artilinux). thanks for help and time. @kakra https://github.com/kakra . let's try to see how he has the system set up @LizziAS https://github.com/LizziAS

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/atar-axis/xpadneo/issues/265#issuecomment-748459256, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJCUBUE7MW4VNTIPS52AULSVSC3NANCNFSM4U63TZZQ .

[kakra]

As far as I can tell, your gamepad isn't using xpadneo at all, so most of the information you'll find here is useless for your problem. The HID API thing may happen on your system but it's still irrelevant as SDL2 will see the same data for hid-generic using either hidraw or evdev - that may be different for xpadneo.

[kakra]

I think there is one misconception: xpadneo won't make any controller into an xbox compatible controller for games. It is a driver to make xbox controllers (and compatible imitations) work properly at all. Installing xpadneo for your iPega controller gains you nothing because the driver will do nothing for the device. Your problem is completely unrelated to xpadneo, the driver which is used for your gamepad is hid-generic. The thing that makes your gamepad work in games at all is SDL2. If buttons are swapped, that is either a hid-generic issue (and thus dependent on the kernel version), or it is an issue with your SDL2 configuration (as already pointed out you're using the same SDL2 version on both systems, so it's most likely a configuration issue).

I'm sorry but we cannot provide any help here through xpadneo even if we wanted to because xpadneo code isn't running at all for your controller.

[LizziAS]

https://atar-axis.github.io/xpadneo/

SDL2 Breaking Changes

As of SDL 2.0.12, SDL introduced a new HIDAPI which can read HID devices in raw mode, bypassing the drivers. Due to the way SDL works, and because xpadneo exposes hidraw devices as user-readable, SDL may see wrong button mappings because it may make wrong assumptions about the protocol mode of Xbox and compatible controllers. If you see wrong button mappings / missing buttons in SDL applications, you may need to turn off this behavior by setting an environment variable in your profile: SDL_JOYSTICK_HIDAPI=0

where is this profile that i may edit it?

On Sun, Dec 20, 2020 at 3:17 AM Kai Krakow notifications@github.com wrote:

Closed #265 https://github.com/atar-axis/xpadneo/issues/265.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/atar-axis/xpadneo/issues/265#event-4133105690, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJCUBSCYL2SPAZYXVFU6N3SVWXLLANCNFSM4U63TZZQ .

[kakra]

where is this profile that i may edit it?

It was already answered here: https://forum.artixlinux.org/index.php/topic,2090.msg14018.html#msg14018

After adding the files, you may need to reboot or run an environment update script from your distro. You could also add it it ~/.bashrc or ~/.profile and log out and in again. But it won't help your problem because you're not facing an issue with HID API itself. The buttons are swapped because you need to remap with some SDL gamepad tool, it was already pointed out here:

https://forum.artixlinux.org/index.php/topic,2090.msg14024.html#msg14024

As you already found out yourself, adding udev rules doesn't help your problem at all because your device is already detected as gaming input.

But I cannot follow your argument how adjusting the RetroArch mapping wouldn't describe your issue... Maybe RetroArch is not what you're looking for but you need to remap those buttons. You can do that in Steam Big Picture mode, or use some SDL2 gamepad tool. Having the X and Y button swapped is a common problem for gamepads in Linux because BTN_X has an alias of BTN_NORTH while BTN_Y has an alias of BTN_WEST while common sense is that Y is north, X is west. Actually, this assumption is from some very old Nintendo gamepad layouts. While the kernel claims to prefer cardinal directions, most game developers go with using the BTN_X and BTN_Y symbols. Thus your driver sends BTN_NORTH when you press the "northern button" which maps to BTN_X for a game. The driver would need to be fixed for that because your gamepad is a device that prefers symbols over cardinal directions, but that won't happen in the hid-generic driver - be sure.

Yes, hid-xpadneo has a fix for that and swaps those buttons (as we are not "hid-generic"). But it was made for different hardware than yours, with a different HID protocol and layout than yours. If you want to see the correct mapping, you'll have to do it at the SDL2 layer - or at whatever software provides that doesn't use SDL2. You can also try anti-micro, it may work.

I'd like to leave this as the last comment and close the issue. xpadneo cannot fix your problem and isn't responsible for it either. There's also a tendency of you denying proposed solutions and denying to supply full logs as "that isn't my issue / it works with the other system", or keep asking for solutions that won't fix your problem - which makes helping at least difficult - OTOH, it may just be the result of impatience 😉. Maybe add to the Artix thread a clear listing of which software you're using and which problems you're seeing, adding the hardware used with full logs as requested. To me it looks like very unclear if you're using Steam, RetroArch, or whatever game.

I hope you get your problem fixed soon, tho. Apparently, I cannot help here with xpadneo, that's completely out of the scope of what the driver does.

[LizziAS]

I have submitted all logs requested multiple times. I have stated plainly that I was using steam. I never once said I was using retro arch, I don’t even know what that is. The problem is specific to artix and artix only. Not arch or Manjaro or even endeavour os, all of which are using systemd. The problem seems specific to openrc as far as I can tell. And while you may feel that this is not a problem with xpadneo and not wish to discuss it further the folks at artix should at least provide some support or explanation as to why this works on systemd and no where else. But most of all I want you to understand that must of the things told me are way above my comprehension and just make my head spin. I’m not a programmer. I’m a Linux end user for 17 years. Installing arch and gentoo are simple enough to do as they have instructions to follow and I’m good with following instructions. But when it come to hexidecimal numbers and raw key mapping out of my league. From an end user experience there aught to be a correction artix could apply since it just works on systemd. I thank you for some of the last bits of explanation in your last couple replies but not the false claims I have been told this already or the attitude that I am somehow dismissive and not wanting a solution.

On Sun, Dec 20, 2020 at 8:56 AM Kai Krakow notifications@github.com wrote:

where is this profile that i may edit it?

It was already answered here: https://forum.artixlinux.org/index.php/topic,2090.msg14018.html#msg14018

After adding the files, you may need to reboot or run an environment update script from your distro. You could also add it it ~/.bashrc or ~/.profile and log out and in again. But it won't help your problem because you're not facing an issue with HID API itself. The buttons are swapped because you need to remap with some SDL gamepad tool, it was already pointed out here:

https://forum.artixlinux.org/index.php/topic,2090.msg14024.html#msg14024

As you already found out yourself, adding udev rules doesn't help your problem at all because your device is already detected as gaming input.

But I cannot follow your argument how adjusting the RetroArch mapping wouldn't describe your issue... Maybe RetroArch is not what you're looking for but you need to remap those buttons. You can do that in Steam Big Picture mode, or use some SDL2 gamepad tool. Having the X and Y button swapped is a common problem for gamepads in Linux because BTN_X has an alias of BTN_NORTH while BTN_Y has an alias of BTN_WEST while common sense is that Y is north, X is west. Actually, this assumption is from some very old Nintendo gamepad layouts. While the kernel claims to prefer cardinal directions, most game developers go with using the BTN_X and BTN_Y symbols. Thus your driver sends BTN_NORTH when you press the "northern button" which maps to BTN_X for a game. The driver would need to be fixed for that because your gamepad is a device that prefers symbols over cardinal directions, but that won't happen in the hid-generic driver - be sure.

Yes, hid-xpadneo has a fix for that and swaps those buttons (as we are not "hid-generic"). But it was made for different hardware than yours, with a different HID protocol and layout than yours. If you want to see the correct mapping, you'll have to do it at the SDL2 layer - or at whatever software provides that doesn't use SDL2. You can also try anti-micro, it may work.

I'd like to leave this as the last comment and close the issue. xpadneo cannot fix your problem and isn't responsible for it either. There's also a tendency of you denying proposed solutions and denying to supply full logs as "that isn't my issue / it works with the other system", or keep asking for solutions that won't fix your problem - which makes helping at least difficult. Maybe add to the Artix thread a clear listing of which software you're using and which problems you're seeing, adding the hardware used with full logs as requested. To me it looks like very unclear if you're using Steam, RetroArch, or whatever game.

I hope you get your problem fixed soon, tho. Apparently, I cannot help here with xpadneo, that's completely out of the scope of what the driver does.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/atar-axis/xpadneo/issues/265#issuecomment-748611054, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJCUBULZMVXNW4JF2ERHKLSVX7ANANCNFSM4U63TZZQ .

[LizziAS]

Also I tried repeatedly to remap them in steam big picture mode and they kept switching back.

On Sun, Dec 20, 2020 at 10:28 AM Lizzi Swane lizzi.swane@gmail.com wrote:

I have submitted all logs requested multiple times. I have stated plainly that I was using steam. I never once said I was using retro arch, I don’t even know what that is. The problem is specific to artix and artix only. Not arch or Manjaro or even endeavour os, all of which are using systemd. The problem seems specific to openrc as far as I can tell. And while you may feel that this is not a problem with xpadneo and not wish to discuss it further the folks at artix should at least provide some support or explanation as to why this works on systemd and no where else. But most of all I want you to understand that must of the things told me are way above my comprehension and just make my head spin. I’m not a programmer. I’m a Linux end user for 17 years. Installing arch and gentoo are simple enough to do as they have instructions to follow and I’m good with following instructions. But when it come to hexidecimal numbers and raw key mapping out of my league. From an end user experience there aught to be a correction artix could apply since it just works on systemd. I thank you for some of the last bits of explanation in your last couple replies but not the false claims I have been told this already or the attitude that I am somehow dismissive and not wanting a solution.

On Sun, Dec 20, 2020 at 8:56 AM Kai Krakow notifications@github.com wrote:

where is this profile that i may edit it?

It was already answered here: https://forum.artixlinux.org/index.php/topic,2090.msg14018.html#msg14018

After adding the files, you may need to reboot or run an environment update script from your distro. You could also add it it ~/.bashrc or ~/.profile and log out and in again. But it won't help your problem because you're not facing an issue with HID API itself. The buttons are swapped because you need to remap with some SDL gamepad tool, it was already pointed out here:

https://forum.artixlinux.org/index.php/topic,2090.msg14024.html#msg14024

As you already found out yourself, adding udev rules doesn't help your problem at all because your device is already detected as gaming input.

But I cannot follow your argument how adjusting the RetroArch mapping wouldn't describe your issue... Maybe RetroArch is not what you're looking for but you need to remap those buttons. You can do that in Steam Big Picture mode, or use some SDL2 gamepad tool. Having the X and Y button swapped is a common problem for gamepads in Linux because BTN_X has an alias of BTN_NORTH while BTN_Y has an alias of BTN_WEST while common sense is that Y is north, X is west. Actually, this assumption is from some very old Nintendo gamepad layouts. While the kernel claims to prefer cardinal directions, most game developers go with using the BTN_X and BTN_Y symbols. Thus your driver sends BTN_NORTH when you press the "northern button" which maps to BTN_X for a game. The driver would need to be fixed for that because your gamepad is a device that prefers symbols over cardinal directions, but that won't happen in the hid-generic driver - be sure.

Yes, hid-xpadneo has a fix for that and swaps those buttons (as we are not "hid-generic"). But it was made for different hardware than yours, with a different HID protocol and layout than yours. If you want to see the correct mapping, you'll have to do it at the SDL2 layer - or at whatever software provides that doesn't use SDL2. You can also try anti-micro, it may work.

I'd like to leave this as the last comment and close the issue. xpadneo cannot fix your problem and isn't responsible for it either. There's also a tendency of you denying proposed solutions and denying to supply full logs as "that isn't my issue / it works with the other system", or keep asking for solutions that won't fix your problem - which makes helping at least difficult. Maybe add to the Artix thread a clear listing of which software you're using and which problems you're seeing, adding the hardware used with full logs as requested. To me it looks like very unclear if you're using Steam, RetroArch, or whatever game.

I hope you get your problem fixed soon, tho. Apparently, I cannot help here with xpadneo, that's completely out of the scope of what the driver does.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/atar-axis/xpadneo/issues/265#issuecomment-748611054, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJCUBULZMVXNW4JF2ERHKLSVX7ANANCNFSM4U63TZZQ .

[kakra]

I think you're following a blind alley attributing the problem to OpenRC. The buttons should work the same no matter which init system you're using. Maybe you should start looking at a lower layer and check if the outputs of evtest are correct in both systems: If the button codes returned for each button in evtest are the same on both systems, then the problem is with your configuration.

I didn't mean to demean you, actually, I revised my comment above - realizing that just the timing of your answers may be a bit confusing. Apparently, since you're reading via email, you probably didn't see the revised comment. I can totally understand your frustration with the issue but I also want to make clear that xpadneo has no impact on that: It simply doesn't support your device and isn't used. That it somehow worked for you on the other distro is probably by coincidence while you tried some other stuff to get the device going. If you uninstalled xpadneo from both systems, it should still work the same. Your device is using hid-generic but not hid-xpadneo.

I cannot provide any more help here because I'm not running any arch-based distros. So even if I tried to help, I could only give you some vague technical clues because I'm missing the actual system to show you actual examples.

The nice folks over at the Atrix forum may be able to provide much better help. I can only suggest to test the lower layers first, and that would be evtest. Then try an SDL2-based gamepad tester. Only then try actual games. I'm pretty sure there's a difference between both system in your environment variables or there's a different SDL2 controller db somewhere.

[LizziAS]

Ty for that reply

With you attributing things to me that they said and them attributing to me things you said it leaves me confused and feeling lock in the middle of what would qualify as interpersonal abuse.

I think I have had my fill of xpadneo and artix Linux to last me for some time.

Good day.

On Sun, Dec 20, 2020 at 2:17 PM Kai Krakow notifications@github.com wrote:

I think you're following a blind alley attributing the problem to OpenRC. The buttons should work the same no matter which init system you're using. Maybe you should start looking at a lower layer and check if the outputs of evtest are correct in both systems: If the button codes returned for each button in evtest are the same on both systems, then the problem is with your configuration.

I didn't mean to demean you, actually, I revised my comment above - realizing that just the timing of your answers may be a bit confusing. Apparently, since you're reading via email, you probably didn't see the revised comment. I can totally understand your frustration with the issue but I also want to make clear that xpadneo has no impact on that: It simply doesn't support your device and isn't used. That it somehow worked for you on the other distro is probably by coincidence while you tried some other stuff to get the device going. If you uninstalled xpadneo from both systems, it should still work the same. Your device is using hid-generic but not hid-xpadneo.

I cannot provide any more help here because I'm not running any arch-based distros. So even if I tried to help, I could only give you some vague technical clues because I'm missing the actual system to show you actual examples.

The nice folks over at the Atrix forum may be able to provide much better help. I can only suggest to test the lower layers first, and that would be evtest. Then try an SDL2-based gamepad tester. Only then try actual games. I'm pretty sure there's a difference between both system in your environment variables or there's a different SDL2 controller db somewhere.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/atar-axis/xpadneo/issues/265#issuecomment-748648837, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJCUBQNP5XNX6552QRYQULSVZEWFANCNFSM4U63TZZQ .