Games in dolphin emulator run slow if controller is connected via bluetooth

Yes I tried different ports (usb 2 and 3). Also the ones on the front, to test if it has something to do with the distance between the adapter and controller.

You are right. When I created the initial post, I used an usb bluetooth adapter.
But since yesterday I have an Intel AX200, connected via PCI-E.

I was really hoping this would also solve this problem. But no, it doesn’t.
At least I know now that this is not a hardware defect of the bluetooth adapter.

1 Like

Can you post the logs?
systemctl stop bluetooth.service

then start it with

/usr/lib/bluetooth/bluetoothd -n -d

and also

journalctl --unit=bluetooth

Sure :wink:

This didn’t work, bluetooth always auto restarted, so I had to disable that service first (thats why there are multiple started/stopping bluetooth messages in the logs).


Output (since last boot):

While the logs were taken I connected the controller and started the dolphin emu. No new messages were logged while in game.

Try to install bluez-hid2hci and add to GRUB_CMDLINE_LINUX_DEFAULT the parameter btusb.enable_autosuspend=n then regenerate the config file of grub and reboot

Did this, but does not make a difference.

I’m out of ideas, last thing that you can try is this

I made a video comparing Arch based systems to Fedora on the exact same hardware in Rocket League. On Arch there are also freezes when using the mouse while the controller is connected via bluetooth. This doesn’t happen on Fedora, as you can see in the video:

I saw that both systems where it works (Fedora, Kubuntu) apply some patches to bluez, for example fedora:
While arch does not apply any patch to bluez currently:

So I’m experimenting with bluez patches and build options now. Nothing works so far.

It’s just frustrating. I was really happy I don’t have to dual boot for gaming anymore. Did this some years ago with Windows, now I have to dual boot multiple Linux distros because one doesn’t like my hardware xD
I really try to solve this, so anyone can keep posting ideas what to try next.
Everything seems the same. Same kernel version, same bluez version, same video driver version, …
but still problem is only on arch based systems, so hardware is fine.
Also I didn’t have this problem some months ago (at least in dolphin, haven’t played other games in that time) on my eos install, so it came with an update since december last year but idk. which package to downgrade.

Edit: Noticed now that Fedora uses a slightly older version of xorg (1.20.11) vs arch (1.20.12). Next thing to try :slight_smile:
Edit 2: No need to try, xorg was just updated to 1.20.12 on arch 9 days ago, but I have this problem since more than 9 days, so the xorg update can’t be the cause.

Edit 3:

on the project page it says it is an xbox gamepad driver, but I’m using a playstation controller. Don’t think this would make much sense to install.

1 Like

Maybe he meant like emulate xbox controller.

Although it still doesn’t make any sense, to me that looks like some bug which needs to be determined and fixed…


I tried that. Installed xboxdrv from aur, started the service and run this command (same as from link you posted, but only with device path changed to point to the wireless controller):

xboxdrv \
  --evdev /dev/input/js2 \
  --evdev-absmap ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y,ABS_X=X1,ABS_Y=Y1,ABS_RX=X2,ABS_RY=Y2,ABS_Z=LT,ABS_RZ=RT \
  --axismap -y1=y1,-y2=y2                          \
  --mimic-xpad                                     \

however output is:

xboxdrv 0.8.8 - 
Copyright © 2008-2011 Ingo Ruhnke <> 
Licensed under GNU GPL version 3 or later <> 
This program comes with ABSOLUTELY NO WARRANTY. 
This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for 

-- [ ERROR ] ------------------------------------------------------
Invalid argument

Sure, would like to inform some arch maintainer at some point so they can fix it. But currently still don’t know which package is causing this, so don’t know whom to contact.

@jonathon is probably not somebody who is into bluetooth / PS5 controllers (i assume), but he’s deeply into Arch and hopefully could help to take a guess at debug / contact :slight_smile:


This kind of sounds like a kernel regression, e.g. having the Bluetooth controller connected is creating some sort of interrupt storm.

Could you try linux-lts54 and see if that works? If so, it might narrow the regression window somewhat.

There’s also 5.13.1 in testing, though that still has issues (and 5.13.3 was just released upstream).


I have tested kernel 5.4, but on Manjaro, because they provide older kernels with the nvidia module and I don’t have to compile from source and mess with dkms drivers.

Kernel 5.4 is a little different. The problem is still there.
But while on newer kernels I get performance problems only while the controller is connected and they instantly go away when I disconnect the controller, on 5.4 the problems stay until I reboot.
So if the controller was once connected, on 5.4 even after disconnect, moving the mouse freezes Rocket League and dolphin emu still runs slow.

Don’t want to switch to testing on my main system, but tried kernel 5.13 also on Manjaro. There is no difference compared to 5.12.
Can try again on eos when 5.13 hits stable.

Just for reference, Unofficial repo for older LTS kernels

Hm. Do you have game-devices-udev installed on either distro?

1 Like

So I just made a fresh eos install for testing. Also installed the kernel 5.4 from your repo that you linked here:

Kernel 5.4 acts the same on eos as on manjaro.

However while reinstalling, I found out something new by accident. To make the controller fully work, the driver (hid-playstation) is required.
This is included since kernel 5.12, but for older kernels I always installed this aur package:

This time I forgot to install it. Started the dolphin emu on the new system, connected the controller… and it stayed smooth. No lags.
Of course, some controller features do not work, but without that hid-playstation driver I can play in the dolphin emu just fine, without lags, even with the controller connected via bluetooth.

So to confirm I installed the driver afterwards. Let dolphin run while doing that. It run smooth, until I loaded the driver:

modprobe hid-playstation

The second I executed that command, dolphin started to lag.
So it is the new hid-playstation driver causing this all.

On EOS no, on Manjaro yes. Both show same behaviour, so this does not make a difference.


Tested again on kernel 5.10 (official linux-lts package). Same here. Dolphin runs smooth until I install and load the hid-playstation driver.

Now question is why does only Arch suffer from this, while Fedora which is also using kernel 5.12 with this driver included is fine?

My guess is that it has to be reported to whoever deals with hid-playstation, probably Arch is just faster and Fedora haven’t catched up to it…or it’s exclusive Arch bug, which i don’t know really…Could be, wonder what @jonathon would advise in terms of who to contact, since you’ve detemined the cause

Both use kernel version 5.12.5 currently. Only differences could be the patches they apply and different build options I guess.

Also a possibility I think about is what if hid-playstation itself is fine but only acts as a trigger for buggy code that could be in another system component.


So today I applied system updates as usual and also went through my package list and compared it to my Fedora system. I uninstalled some packages that sounded useless / I don’t need anymore to keep my system clean.

After this (and a reboot), THE PROBLEMS ARE GONE!

So I tried to replicate what I did on my second eos test install. I updated the packages one by one. No update made a difference. Then I went through the packages again and removed them one by one.

Turned out:
After removing tlp the lags are gone. No problems anymore with connecting the controller via bluetooth!

Now I know why this worked on Fedora. It does not come with tlp preinstalled, but both EOS and Manjaro do.

Btw., just as a side note, I usually had lagging problems also on the desktop. Lately it felt like KDE Plasma was dropping frames every now and than. I just got used to it because I don’t need the smoothest desktop, so I ignored it.
After uninstalling tlp, the desktop and animations in general also feel a little smoother :slight_smile:

Also this is not the first time I had problems with tlp. Already had them on my old machine. It caused lags and wifi problems.

Maybe this buggy thing shouldn’t be preinstalled by default. It is nice to save a little battery, but this is not needed on non-mobile devices and only causes problems, so users should be aware of it. Having this preinstalled causes users to experience some weirdness in some cases without knowing why. Possibly make it clear in the installer that tlp will be installed. Could be a checkbox in the what packages to install page in Calamares (where one can select which desktop to install).


Oh man!
How the hell we missed tlp!! :man_facepalming:

Usually simple rule for device exclusion is enough, but since it’s desktop anyway… :upside_down_face:

Generally it’s not buggy at all, but for some devices you just need to exclude some things, and it really saves a lot of battery for laptops, so it’s good idea to pre-install by default still…

Problem is not many people are aware of it’s existence and that some tweaks might be needed :laughing:

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.