[feature request] Linux support #537
Comments
|
One of the main obstacles is DS4Window's close dependency to Windows .NET and DirectX, which is not going to change in the successor. DS4Linux would need a complete rewrite of the interface for a different API, and I'm not sure how Ryochan feels about this. |
|
Besides the current software solutions listed, ds4drv and SC Controller support mapping the DS4. The need for DS4 mapping options should be handled between those options. .NET is not a good choice for supporting multiple operating systems so any alternative would probably have to be written using different tools. As it stands, I don't have a vested interest in seeing Linux gaming succeed anymore. SteamOS was a colossal flop. Linus Torvalds did a full heel turn and revealed his low power level last year. And SteamPlay really has killed the push for native Linux games at least in the short term; Witcher 3 will never get the promised native Linux port and the community does not seem to care. In some cases, Wine lauched from Lutris offers better support than SteamPlay (Warhammer 40K: Dawn of War 1 for example). |
|
I understand the points and I see things in a more positive way:
Playing games is what it really matters. Linux is my choice nowadays as Lutris, Wine and SteamPlay improve faster than I can finish games. And I don't find bad using Windows to play those that I can't on Linux. It's like playing PS4 because I don't have Horizon Zero Dawn on PC. A tool to match DS4Windows on Linux would be awesome! It don't need to be now. Just give time to time and you will see that Linux will gain ground little by little as it has in the last years. |
|
I was really on the Linux gaming hype bandwagon between around 2014 to 2016. Having access to more PC games that run natively on Linux had been something that I was interested in since I started using Linux around 2003. At this point, I don't see myself as a part of the Linux community although I still primarily use Linux on my machines; Xubuntu and Fedora are my current distro preferences. |
|
Go to /r/linux_gaming after a long time. Sees mostly Wine and Proton posts including asking about a game that has a good native port being played using Proton. |
|
https://www.reddit.com/r/linux_gaming/comments/aic8hx/star_wars_kotor_ii_over_steam_wont_start/ I guess /r/wine_gaming is deprecated. Reminder to not take anyone on reddit even remotely seriously. Also, Bugged keyboard mechanics dood. I didn't press comment yet. |
|
Users will aways be users I think... Every time I got into reddit to get help the only thing that I got was echoes. Except if some one post an OP with some tutorial about something usefull. In Linux there are so many things with incomplete solutions as there are dumbs on reddit telling you to conform with that. One of those things is mouse scroll speed. It is to slow or it is too fast. And it don't have acceleration. Trying to understand why it work that way to think how to fix... Strange enough, youtube can be more helpfull. |
|
I pay attention to the YouTube Linux front a bit but my main resource for help now is just random search results in DuckDuckGo. Maybe I should focus a little more on gaming on Linux in 2019. Even on the Linux front, a lot of time was spent in 2018 just tinkering with control schemes instead of actually playing games; emulating a decent mouse pointer has been a hard problem to try to solve. I believe I got my Steam Controller and Wiimote configurations working about as good as I can now so there should technically be more time available to play something. Besides that, I contributed some minor code to Lutris and posted a couple of installers in 2018 so I at least helped people out somewhat. |
|
This has gotten off topic anyway so I might as well spam this. I had made a couple of minor playthrough series of videos of playing games on Linux in 2018. The better but odder one was playing through Quake 4 on Linux using the Wiimote. Here are links to the playlists available on BitChute and SusanTube. https://www.bitchute.com/playlist/z7gPeEfw78st/ |
|
They could just improve wine and run ds4w that way (it was discussed a lot for Cemu since Cemuhook needs the motion server there). I did manage to do it for wiimotehook (another HID handler) but it was a pain in the butt, especially at the point of needing to read the bluetooth device as a HID (ds4w in itself may run eventually). PS. If you try it, avoid the .NET clones, install a Microsoft .NET. There is a chance their [wine's] HID support (for bluetooth luckily) has improved lately and is less flimsy. |
|
HID support is probably not the limiting factor. The major factor is requiring a driver to be installed for controller emulation. I don't know if it would be possible to detect the platform that the app is running on and attempt to use uinput if the app is run on Linux through Wine. Even if that were possible, this functionality really should be done with a native Linux app rather than trying to rely on Wine. My time spent playing Linux games has been limited to using the Steam Controller using SC Controller. I have had no gaming time over the past couple of months due to a hand injury. At this time, I don't think I would have an interest in attempting to make some software for controller mapping for Linux. |
|
It would be generally very helpful if they seamlessly supported XInput emulation because almost all games and emulators support it. I don't think it's such a bad idea to support windows controller software in that way, because they are generally very light programs; they have no great needs in CPU or RAM usage and if wine interprets them correctly they should be no burden at all. |
In my eyes WINE isn't a solution for this as it'll be a solution for games running inside WINE only. In Linux controller support mostly works through SDL2 and translate a XINPUT inside wine to the system would be very hard. The support inside the kernel for xbox and ds4 controllers are good enough so the DS4Linux would be just a UI to propper configure it as Linux don't have anything like that just to make life easy. The second feature would be a wrapper to xinput to make DS4 a bit more compatible in case things goes wrong. A config interface to disable the light bar as of one to config accelerometers and gyro would be great. Example: I was testing Metro 2033 on Linux because Windows was giving me a hard time with resolution. The Linux version is terrible! Trully terrible! So I tested the windows version using proton. And it is an effing lot faster than the native one (effing bad ports!). The native DS4 worked on both like a charm but the steam wrapper breaks and swap buttons around. In other words, it's borked. |
I doubt it's hard. Problem is, very few people care to code on those things. |
|
I have tested the kernel driver and ds4drv before and both worked okay. Dust: An Elysian Tail is a game that has native DS4 support on Linux; I am not sure why the Windows version does not seem to have DS4 support. The kernel driver exhibits more input delay when playing Dust than when using DS4Windows to emulate an Xbox 360 controller and playing the Windows version. I cannot remember the performance of ds4drv but I remember contributing some changes to the project.
Does Metro 2033 Redux have native support for the DS4 controller? If that is the case, maybe the game might see the DS4 and the emulated Xbox 360 controller and mix the inputs. I have run into edge cases in the past when configuring an exclusive mode workaround was required on Linux; it was mainly for my Wiimote configuration. |
|
I installed Metro 2033 Redux on Fedora and tried it out. The game kind of works with the DS4 but some of the mapping is wrong with my DS4 v.1. Dpad Up does not work and R2 is mapped to Start. Using Steam's mapper does not really help as the game still seems to use the original DS4 mapping in most cases. The way around that problem is to chmod the controller device after Steam has opened it. That way, the game will not detect the DS4 and it will only use the virtual Xbox 360 mapping from Steam's mapper. |
If the Fedora you use is a bit old, you will be locked to the old kernel configurations for the DS4. That could explain the diferences between my test and your test. My DS4 is a V2 and I tested over BT. Manjaro or POP!_OS should be better, more bleeding edge with the "almost latest tech", for games specific scenario. I would pick POP!_OS to test things around as it is a "ubuntu" system but more reliable. Manjaro can break a lot. This case scenario should be an example of what DS4Linux could help. But fundamentaly DS4Lin would be different from windows version. |
|
Those things are better off started with a cross-platform HID library. e.g. RPCS3 works seamlessly on Windows and Linux directly with the DS4 HID. |
|
I am running Fedora 29 using kernel 5.0.7 so I am not that far behind. I probably have not done a system update in a couple of months as I hardly run Linux on my gaming PC lately. It has been that way ever since I wiped SteamOS off my hard drive. Any other mapper program would run into a similar problem unless it attempts to automate hiding the original controller; that would require setting up special device permissions or just start running the program as root. At least the process of hiding a controller when needed is easier than it is on Windows. |
|
Finally got ds4drv installed and tested. The code has been a decent reference in the past but it performs much slower than Steam's mapper. It seems like the ds4drv project is defunct anyway; there have been no updates in over a year. |
I was warning you that but you already know. After kernel drivers ds4drv isn't needed anymore. |
|
I will try to perform some experiments sometime next weekend. This weekend will probably be spent finally backing up data, doing a fresh install of Xubuntu and getting some dev tools configured. I am still running Xubuntu 16.04 on my laptop. I should also get around to doing a fresh install of Windows eventually. |
|
A change of heart... Thank you for considering it. This has the potential to be the very best controller... controller support on linux. |
|
This first round will just be an exploratory test. I have only used the DS4 for testing on Linux a few times but it was not a great experience even just using it as a generic gamepad. The Steam Controller (using the Kozec SC Controller mapper) has been my main Linux game controller for a long time. I plan on making a simple console app with Qt since I am most familiar with making Linux apps using that toolkit. |
This is very nice and very much apreciated! I'll start testing as soon you release the code. |
|
This experiment got pushed back a few days. Last weekend ended up being consumed by getting the Android SDK working in Qt Creator and updating some old Qt Quick based Android apps. Only a minor amount of testing has been done so far. Testing so far does seem to show that interacting with the device using hidraw can result in a more responsive controller than what is offered using the hid-sony Linux driver. I have not tested what the input difference would be between the test app and what DS4Windows currently offers; it wouldn't be a fair test anyway. One big issue is that getting hidraw set up for normal users can be a bit of a pain. I ended up using the rules file provided by ds4drv to work around that. |
|
Dark timeline. My interest in Linux in general is at an all time low. It also does not help that the Linux gaming scene is now a joke. Many Linux native games that I bought don't even work in recent distros anymore even with the Steam Runtime. The biggest problem is the new community that is outright subverting FOSS and no amount of code can fix that. |
|
I agree... After DXVK dev stated that it is feature complete and no furter update will be made besides bug fixes, there is no hope for linux to run games as good as Windows. Community is just too focused on blabness instead of dealing with Linux's problems like the cursed Xorg server... This thing must die asap. |
|
I was willing to take a performance hit to play a Linux port of a game rather than running it on Windows. The few years that SteamOS was a thing was a good time. I have only played with Wayland a couple of times. It would be nice to finally deprecate the X server but Wayland does not seem to be nearly there yet. Today I have also heard about the news regarding Eric S. Raymond being kicked from the OSI mailing list. Another core contributor to the FOSS movement has been attacked and cancelled. The principles that have empowered the FOSS movement and helped build FOSS software have been under attack for a while now. |
|
I have not gotten back to this problem since my first round of exploratory testing. Anyway, I still have the source code I was writing before. I am probably going to remove my current Xubuntu installation fairly soon and use a different distro (haven't decided which one). I have uploaded what little I had written to a GitHub repo so it is not lost. Be wary, I did not clean up the code so it is messy and contains many expletives. https://github.com/Ryochan7/ds4linuxtest I remember testing the performance by playing Super Meat Boy. Not sure about any other games I tried at the time. There are some commented portions in the code from testing various ways to read the controller. Certain routines resulted in better input performance than others. I hope to actually get back to working on this kind of problem in the future. It would be a higher priority for me if I still used Linux for playing PC games. |
|
this has been an interesting read. I, for one, see non-native pc games working on linux better than games targeted at linux oses. lots of native ports run a lot worse than with proton. there's also the fact that porting requires a lot more effort than most devs are willing to have and sometimes the fact that you don't use any proprietary garbage that doesn't run on wine, having a good proton rating is more than enough. |
|
I think the last time I gave Wine an honest try was about 1 year ago. I tried to play Heroes of Might and Magic 3 and Warhammer 40K: Dawn of War 1. Performance with HoMM 3 was fine when it worked but the game kept crashing in the tutorial so I gave up on it. I own Dawn of War 2 and it was one of my favorite games in my Linux library. I wanted to give the first game a try. At least back then, the game was confirmed to not work with Proton and I don't remember it working in Wine either; got to the main menu in Wine but could not play any level without crashing. Anytime I have seen clickbait videos praising Proton (regarding Overwatch mainly), performance looks terrible and usually needs a good amount of work to get a game running at all; they shouldn't be playing Overwatch anyway. I am not convinced that Proton is worth the hassle and definitely not worth buying Windows games in the hopes that the game might be playable. Also, my weird use case is not being met by the current Linux community. SC Controller used to be my go to mapping application even though I had to keep patching it with my custom bits. Once the program introduced support for controllers other than the SC, input latency was more pronounced and I stopped porting over my patch; can't remember the exact version number when that happened. |
|
In case anyone was curious, here is a version of the most recent patch that I made for SC Controller. It looks like it was last updated on 2018/01/20. https://gist.github.com/Ryochan7/316a644935f33e4f51ee19058c79777c |
|
Linux is somewhat improving. There is this guy here measuring and comparing fps: https://www.youtube.com/channel/UCDmXLiZTBaFuCOXjy6mdw5w Windows vs some aplications of DXVK + Wine and VKD3D + wine. Sometimes proton. About latency, yes! In general nobudy cares about that in Linux and I actualy found some culprits: The kernel (yes... the Linux kernel focus on stability over speed), Xorg (yes, again... xorg actualy is the biggest crap in Linux... but still is there. Can't understand that at all...) and window compositors (this is the worst. No compositor can't detect and passthrough games to xorg like the exclusive fullscreen feature in windows. It aways reprocess everything adding 1 to 3 frames of latency... really awfull. The gnome compositor also isn't eficient and adds a lot of overhead with increase in resolution at a point where it'll just drop render speed to half. Why these people like to use opengl for window compositors?). Some time ago I tried to explain the problem on reddit and other locations but Linux lovers don't believe. They demand proof. But when it's a thing you feel, and actually don't have any mean or aparatus (like a faster than light cam) to measure in numbers, how to prove? Then I grow tired of it and am using windows to play games. Really, this blind love for Linux people have is the larger problem it'll ever have... |
|
Aside: Took a look at the latest Windows preview of SC Controller. It is coming along. I have made minor contributions to the project before and I would consider doing it again. My right hand is finally loose enough that I can handle the Steam Controller comfortably with minor complications; not being able to comfortably use the right grip button or right touchpad click were the big issues last time I tried. |
|
I think the fact that people are hyping proton and linux gaming nowadays is a double-edged sword. For one, it's really cool to see this community grow and get more visibility. But on the other hand, you get the people who will see Clickbait Youtube Video About Proton #21 and think linux is a completely mature desktop system and everything they ever want works perfectly fine there. That is a VERY common misconception. Usually these videos downplay the loss of performance, the lack of support for many DRM and Anti-Cheat Software (such as BattlEye and EAC) all while completely ignoring how wine doesn't run many professional programs that a lot of people use in their desktop (such as the Adobe Suite or MS Office). I honestly can see linux being a much bigger deal in at least 5 years, when wine can actually run professional software and not struggle with any form of strange DRM. |
|
In 2010 I remember thinking that wine actually would run everything in 10 years of dev. So no, wine will never do that because they are outsourced... Still, wine is pretty good right now for many softwares including games. Wine per se don't add overhead because there are little to no translation to be made. DXVK is another story. I was testing a game that is known for the single thread overhead with draw calls on windows that make it drop fps pretty hard even with lots of cpu and gpu available. Running on Linux worsened the problem. I think you can't just solve how the game do draw calls only translating it... I'll wait 2 or 3 years to see what'll be done to improve these things. About SC controller, it's a mistery how it uses DS4. Last time I tried it recognizes but don't do anything with it. There was no documentation or how I should use DS4 with it at all... For me it was a bit of a deception... |
|
SC Controller works much like a remapper, say something like x360ce but with more features. It and DS4Windows are alike in many forms, but afaik it lacks the specific configuration for ds4 controllers, such as changing the lightbar color or checking the battery state. It's actually pretty straightforward in what it can and can't do, I remember it working pretty much out of the box with my ds4. One of the features that I think I've used extensively was the sdl config variable generator. |
|
So much time has passed but no progress has been made on this. Tis Sad. 😢 Many intertwined projects One program that I would like to make on the Linux gaming front is a replacement for the SDL2 Gamepad Tool. Hopefully that would be a simple enough program to replicate. https://generalarcade.com/gamepadtool/ On the plus side, I am the current maintainer of the Python 3 port of SC Controller. I have only gamed on Linux a few times since working on the port though. Naturally too much time spent in Windows land working on DS4Windows and related tools. |
|
I ended up making a similar SDL2 mapper application using Qt Quick. It was mainly developed on Windows but I have tested it on Linux (Fedora 32) as well. It seems to work well enough. The last big step would be to package the app as an AppImage so that it can be more easily distributed. Re-learning Qt Quick yet again was a pain as it has been before. At least this time around, new techniques were used to make the process a bit easier. This is the most extensive application I have made using Qt Quick. With the current base, it probably wouldn't be that difficult to make a classic Widget based GUI as well. https://gitlab.com/ryochan7/sdl2-gamepad-mapper |
|
Got an AppImage working. It has been tested under Fedora 32, Ubuntu 20.04, and Xubuntu 19.10. The base used for the AppImage is Fedora 32 so compatibility might be a problem with older distros. If this app would get updated then maybe a different distro should be used as the base for obtaining libraries. SDL2_Gamepad_Mapper-0.0.1-x86_64.AppImage |
|
that's actually quite cool, I remember hating how the original was packaged when I needed to use it. but I wonder, what's the next step now? are you taking this software further or leaving it where it is? |
|
That's awesome! I'll test it at weekend (as midweek is somewhat no man's land for me haha) |
|
It would be nice to pick up the ds4linuxtest project again and build on that. I haven't played with my DS4 on Linux in a long time. The Steam Controller has been my main controller when playing games on Linux. I ended up making a new release of the SDL2 gamepad mapper. Version 0.0.2 was uploaded and then I immediately thought of a change that I wanted so 0.0.3 was created shortly afterwards. Now the program can download a base gamecontrollerdb.txt file from the SDL_GameControllerDB project. The old SDL2 Gamepad Tool attempts to perform that action but it does not seem to work. SDL2_Gamepad_Mapper-0.0.3-x86_64.AppImage Release page: |
|
Tested in Manjaro. It works. It complains about SDL_gamecontrollerconfig was not found. I'll tell this re-mapper is much easy to understand and to use than SC controller that I actually never understood how to use it with DS4. The only bug I found is that the R2 mapping isn't working when using a SN30+ from 8bitdo (yeah, I tested with that as I turn to be using it as main controller on linux as DS4 have much worser latency (who knows why). This is a surprise to me as SN30+ actualy don't work properly on windows. Some games algo give up on it after some minutes (yep, like 3 minutes). The most known example is trails in the sky games from falcom. |
|
The controller registration window in SC Controller never worked quite right with the DS4. Updating the application's copy of gamecontrollerdb.txt to the latest upstream version fixed the problem and most of the DS4 can be mapped fine. Stick mouse is fairly useless so that somewhat limits using a DS4 to play VN apps. The message regarding As for the DS4 latency under Linux, I have experienced somewhat similar latency issues. I find emulating an Xbox 360 controller using ds4linuxtest to be much more responsive. |
|
Too bad I hardly experimented with this. Been hardly updating the Python 3 fork of SC Controller either. Too many side projects and I feeling like I need to start more. Almost at the point where I want to make a new Podcast Client app. Getting aggravated with gPodder over the last few months. They apparently don't want help to fix problems either. |
|
(not) fun fact update: I found that the inputlag/latency problem with DS4 on Linux is bluetooth stack's fault... Even Linus Tolvard complain about it a lot. I also read that are people trying to rewrite it to make it actualy decent. Even google... Probably this is the final piece to make latency a problem of the past as Valve with Steam Deck using Arch and KDE with the newest KWIN rewrite focusing in low latency on both Xorg and Wayland are bringing game response time to be even with windows. I'll also find very interesting if Steam Deck isn't using BlueZ as bluetooth stack. LTT sayd that BT controllers worked fine under Steam Deck, |
|
The main reason for DS4win to be ported to linux was because there were no form of tweak DS4 easely in that system (still isn't). Steam seems to be in the same state in this regard related to last year. Now Fedora 36 was the first Linux to address the infamous input delay problem Linux had for a long time while trying to fix touchpad laggy behavior. The change was made to libinput (a friend of mine saw this update and lost the link haha). The side effect of this was that DS4 (and maybe other gamepads) now have parity with windows in terms of added input lag (finally!!!) As the state of games on Linux keeps improving I don't see a port to Linux being that relevant anymore. @Ryochan7, I'll leave the decision to close this to you as you may want to do something with the idea in the future. Also, thanks for returning. DS4win is awesome. Really! |
|
huh i was scrolling and found this issue that i thought that it was "dead" |
Pretty much. It's still open because I don't know what devs will do in the future as they didn't closed it either. |
|
Maybe someday but most likely not. At least some work is being done with other mapper experiments although almost all the work has been on the Windows side. My only relevant Linux work has been fixing BLE support in SC Controller and keeping the Python 3 branch going. I had a small direct DS4 to XInput mapper working on Linux but that is the extent to how far any DS4 experiments have gone in the Linux realm. The last experiments revolved around trying to hide the DS4 from other system processes thanks to SIAPI behavior with the DS4 and forcing a fake disconnect when it opens the DS4; I notice the behavior with the Linux port of Streets of Rage 4. Looks like libusb would likely have to be used to obtain exclusive access to the DS4 but I have not found a way to get it to work for Bluetooth devices. |
I see. Nothing on Linux is remotely as good as DS4win and porting it represent a lot of work indeed. After some research I found that kozec don't update sc controller for 2 years now and the actual latest is yours. So instead of porting DS4win to Linux maybe it'll be easier to implement the missing and more critical features to sc controller (like beying able to control the light bar color and tweak de touchpad and/or remap it. Mostly because it's already in use by a lot of folks for steam controllers outside steam. I'm saying this but I don't know the real state of sc controller and don't know if some of this is already possible as last time with it was a nightmare without any sign of it working at all) The fact is that DS4 state is far better now than it was in 2019. Mainly because Fedora 36 updated libinput to fix some delays in touchpads and fixed the chronic inputlag problem it had with Linux mainly over bt as a result of that. I don't know if this fix was general to all distros however. |
|
Hello, Any MacOS support planned? |
|
This project is dead. Just waiting for Microsoft to publish the official stable release of .NET 8 and then the last major work on this project will be finished. Even if that were not the case, MacOS support would likely never be a thing. I have no means to develop for MacOS nor would I want to. I am more anti-Apple than I am anti-Microsoft. Also, I have no idea if there is an gamepad emulation driver for MacOS similar to ViGEmBus. I had a vested interest in Linux but I never got around to writing a similar mapper for Linux in about 4 years; 2018 was the last year I was really invested in being a Linux and FOSS advocate. AFK issues and DS4Windows have kept me busy enough. I almost have no spare time to work on other projects. I had picked up development of SC Controller (Steam Controller focused mapper for Linux) and even that project has been mostly ignored by me. This issue can be closed at this point. |
In the rise of Linux as a real option to play games thanks to SteamPlay 2.0 and Lutris that allows Linux to run Windows games (plus the amazing number of ports in recent years that in my tests are running faster and in a more consistent way (frame cadence is very good with no sttuter) than windows version (that suffer from time to time stuttering) like Mad Max and Rise of the Tomb Raider), there is the need of a good software to control DS4 on Linux.
DS4Windows is the best on Windows so why not implementing it on Linux under the name DS4Linux?
Scenario: We have, I think, 2 diferent drivers for DS4 on Linux. 1 of these is in the Kernel. Besides that, it's a real pain to propper config the DS4. I don't know if games use a common API for gamepads on Linux but DS4 differs when using on USB from when using via BT. Also, feedback (vibration) works when it wants to. It's a bit of a mess... Steam offers support for DS4 on Linux but the reasons to not use it is somewhat the same as in Windows.
What to do: Adapt DS4Windows to use the kernel driver and wrap it to a x360 virtual controller or to use the x360 driver directly (it only needs to work with Ubuntu because it's also oficially supported by Valve. Other distros will adapt if the demand rises). If you want to support more than one distro, consider Linux Mint (Ubuntu support means Linux Mint support) and Manjaro as supporting it also means Arch Linux support.
Why do it: I could say that Windows is dangerous but this is a lie at some extent. The true is that Windows don't favor games as it have too many unecessary services running in the background. In this Linux is more straighfoward and do things in a more streamline way. And for those who wants to improve latency there are modified kernels that change the way the kernel scheduler works besides the fact you can use video driver in DRM mode (not the DRM you're thinking hehe. It stands for Direct Rendering Manager). Linux is faster, more reliable and stable than Windows in a similar way of those we see in consoles like PS4 (that actually is Unix based like Linux) making gaming on it more pleasant. Linux also have much much less things that runs side by side and this favors a lot high demanding processes like games. We only need to facilitate things for the average user to access it and DS4Linux would be an great step.
The text was updated successfully, but these errors were encountered: