PS4 controller not working after latest system updates

Support Gaming
1

I’ve been using Manjaro for about 10 months. I’ve been solving all my problems on my own, but I just can’t figure this one out. After about 604 package updates today, my PS4 controller stopped working

it shows up under lsusb

udevadm monitor --environment --udev
does show activity when I plug in the controller

Steam can’t find the controller. other programs can’t find the controller.

I can get the analog sticks to respond only in wine control joy.cpl

jstest-gtk shows nothing

I tried another usb cable, but no change

the controller works on my Playstation 4.

I won’t be surprised if I’m missing something simple, but any ideas what’s going on? How do I fix this?

EDIT: Somehow, Wine is causing this?! The controller seems to work fine after boot. It stops working when i open something with Wine. :frowning_face: Any ideas?

It’s working fine with games in Lutris with Wine and Steam with Proton. but ChatLoggerJS somehow kills the controller input. opening notepad does the same thing.

I tried uninstalling and reinstalling wine, winetricks, and protontricks. No luck. Controller input is still stolen by the default wine prefix. I tried wiping the prefix. No luck.

3

Did you try to use special software to plug-in your controller? If no, try to use ds4drv. It can probably help you.

https://aur.archlinux.org/packages/ds4drv

1 Like
4

I don’t think it’s doing anything…

I was getting evdev and pyudev modulenotfound errors, so i installed them with pip. I don’t know if it was a good idea, but it worked. And now…


ds4drv --hidraw 

Traceback (most recent call last):
  File "/home/grayfox/anaconda3/bin/ds4drv", line 33, in <module>
    sys.exit(load_entry_point('ds4drv==0.5.1', 'console_scripts', 'ds4drv')())
  File "/home/grayfox/anaconda3/lib/python3.9/site-packages/ds4drv/__main__.py", line 132, in main
    options = load_options()
  File "/home/grayfox/anaconda3/lib/python3.9/site-packages/ds4drv/config.py", line 199, in load_options
    config.load(path)
  File "/home/grayfox/anaconda3/lib/python3.9/site-packages/ds4drv/config.py", line 74, in load
    self.read([filename])
  File "/home/grayfox/anaconda3/lib/python3.9/configparser.py", line 697, in read
    self._read(fp, filename)
  File "/home/grayfox/anaconda3/lib/python3.9/configparser.py", line 1096, in _read
    raise DuplicateOptionError(sectname, optname,
configparser.DuplicateOptionError: While reading from '/etc/ds4drv.conf' [line 118]: option 'rel_wheelup' in section 'mapping:keyboard' already exists

(also I can’t get rid of anaconda. I need it for python programming. I cant get spyder working without it)

Topic title should be something more like… “Wine breaks DS4 controller input” or something like that. but only when running Wine stuff from terminal. problem caused by the default prefix? Might Bottles help with my problem? I have not used it before. I might try it to see what happens. though that would not technically fix the actual problem.

5

I also experienced weird DS4 problems after updates using old prefix. ds4drv could help only if you want to map your DS4 to xinput, though it’s quite limited (e.g. rumbling is not supported).

Also take a look at wine control → Game Controllers first. It should be recognized and be connected if you want to use a Wine-provided driver or disabled if you are going to use it directly as HID (the latter is needed for games that have a native PS controller support). Try different states to check if it changes something for you.

1 Like
6

It doesn’t seem to matter how I set the controller in wine control. Only Wine can control it when Wine is running. “connected”, “xinput”, “disabled”… it doesn’t make any difference. I run “wine notepad” or wine anything & the controller dies until I close the wine program and disconnect/reconnect the controller usb cable. I tried using a new wine prefix. It still steals the controller input.

7

can’t edit my last post anymore

I decided to try this

firejail wine notepad

…And that worked. My PS4 controller was fine. But it’s still not a reliable solution. Some programs give DLL errors that don’t happen otherwise. It’s probably because the program is sandboxed away from necessary files. So the problem still isn’t solved.