Looking up who Roderick Colenbrander is (person who submitted the patch over at https://patchwork.kernel.org/project/linux-input/patch/20201...), it seems they are the "Director of Hardware & Systems Engineering" over at Sony. I'd expect them to spend time on more higher-level things, but seems here they either was involved with actually writing the driver, and/or are just the public face for the patch. Seems unusual though. Kudos if directors at Sony still get to write code, especially low-level code like this.
> Roderick Colenbrander of Sony who serves as their Directory of Hardware & Systems Engineering, chimed in on the matter of adding this Gasia controller support (And, yes, this is the same Roderick Colenbrander who in his spare time serves as a Wine developer and if going back to the early 2000's was the NVClock NVIDIA overclocking tool developer as opposed to being some eager Sony employee):
So seems Roderick is a true hacker! I've used both Wine and NVClock in the past so if you're around here, thanks for your work on all these things and upstreaming them as well! :)
I still remember that I connected a PS4 controller a few years ago to test a unity game that I was making. I typed apt search ps4 but could not find something so I pressed some buttons and magicly the UI changed. It all just worked no setup no nothing. I also used the controller on windows 10 but you had to use the xbox driver with special software to map the controls to that driver. The fact that everything just worked on linux amazes me to this day.
Yes! Also the touchpad in the controller also maps to the mouse and if you plug a headset on the controller it is detected by the system as a proper audio driver. For some time my p2 input was messed up on my PC so I used the controller as a improvised USB to Audio input adapter and it worked flawless
Semi unrelated, but I recently used a windows 7 computer and was astonished that upon plugging in a usb stick, it popped up a notice telling me it was installing a driver for it, rather than just immediately working. I'm sure this is fixed in the newer versions, but I always assumed this would have been fixed in vista at the latest for standard devices (I jumped ship to linux during the XP era)
The drivers it installs is often a built-in Windows/Microsoft driver. It's easy to see in the Device Manager. It's just windows works differently. Every device that's connected first registers as am unknown device and then Windows searches all currently installed drivers for one that matches and configures the system to use that driver for the device. It's not "installing" a driver as much as "assigning" a driver.
What happens is essentially Windows registering the device instance in the configuration - the driver etc is already there, it just follows "new device attached -> discover applicable driver from known installed set -> attach the driver to this instance of device". Newer Windows versions simply hid the behaviour, while windows 7 is the last one to not hide it.
No, it's just bad policy. The correct design on modern "intelligent" buses is very simple. You standardize a class of device, and then you implement that class, OS vendors supply a class driver that works, out of the box, with every device in the class.
USB Mass Storage is the worst case of that approach (vendors with different ideas of how to solve it just agreed to differ and the standard offers all combinations of their preferred methods) but it's still better than the alternative.
Other approaches are crazy, they produce a worse user experience and usually introduce perverse incentives that make life worse for everybody.
If there are in fact "issues" with "vanilla USB" you don't fix those by having every single vendor hand roll their own attempted workaround and ship each of them.
Your approach doesn't result in "a working device" for most users, it results in the situation where you need to buy a new device, to get a new driver, to fix a purely software bug that could have been fixed in the class driver covering your old device instead but that was less profitable and priority #1 is always to bow before the almighty dollar.
Every time Windows ships a new version, users with hardware that worked fine but alas, wasn't shifting too many new units through retail, find now it doesn't work. "Buy a new one, then you'll get updated drivers" people like you cry. More landfill, for no reason.
Real users hate this experience and are relieved when you tell them that some device they're getting doesn't "need drivers". Of course it does actually need drivers, it just uses the OS vendor's class drivers, which work out of the box and are properly maintained, but the user experience is of relief.
Yeah about the xbox thing. I recently got into gaming at the tender age of 36 and bought my first joystick for MSFS, Gamepad with two little joysticks for playing platform games and a steering wheel with gear shift for car games.
So during this whole process I realized that most gear has two versions, a PC/PS4 version and a PC/Xbox version.
The PC/PS4 version doesn't actually work in Windows. I had to get the PC/Xbox version to work in games like Forza Horizon. Even though their website lists the same brand and model, but they don't say which version.
I figured that obviously Microsoft will have the best support for the Xbox version of the gear.
I also use a cheap Logitech F310 gamepad in Linux for games like Dead Cells, Hollow Knight, Streets of Rogue and Unto the end. Worked with no setup, out of box.
while non-steam games on windows don't quite support ps4 controllers out of the box, for games on steam (except for a few old titles that don't play well with steam input) you can simply enable ps4 controller configuration support on steam input, and they will work seamlessly, no workarounds required, with many newer games even showing proper ps4 button prompts
Reminds me of when I set up kodi on a raspberry pi and plugged it into my TV. I was busy setting it up and all of a sudden realised I was controlling it with the TV remote. It took me a few seconds to convince myself this was actually happening before going away and learning that HDMI is two-way and CEC is a thing.
Open standards are absolutely awesome and even though I've been hooked and using Linux and other free software exclusively for more than a decade now it continues to make me happy.
I wonder if it has anything to do with the fact that PlayStation runs FreeBSD. Maybe the source was close enough that porting to Linux wasn't a major effort?
Xbox One controllers also work flawlessly in Linux. I find it interesting I've not had any luck getting my xb1 controller to work in Windows 8.1 though.
>> Xbox One controllers also work flawlessly in Linux
It doesn’t, actually. It works out of the box if wired through USB, or when using the expensive wireless dongle, but it doesn’t work out of the box over Bluetooth. You have to apply nasty hacks to the BT stack to make it work. PS4 controller is just pair & go.
Latency is fine, I don’t use the Xbox controllers with Linux for the reasons I mentioned but I do use them in BT mode with the Steam Link. Never had any problems with input lag. PS4 controllers are BT only and absolutely no problems with those with either PS4 or Linux. In terms of versatility and support the PS4 controllers are my favorite, but I slightly prefer the ergonomics of the Xbox One S controller.
Yes I was referring to the updated controller they started shipping when the Xbox One S was released, I'm pretty sure that's the only one they have been making afterwards until the Series X was introduced?
These controllers use some kind of DRM that requires disabling a feature of the BT stack (ertm) using a non-persistent kernel parameter that breaks other BT devices. I
The fact that they mentions doing nasty hacks to the BT stack implies that it's BT they are using and hence the S controller because you yourself stated it's the one that supports it.
> I've not had any luck getting my xb1 controller to work in Windows 8.1 though
Could this be another intended incompatibility that Microsoft
introduced to push Windows 10? They did it with CPU support
limitations and the newest DirectX version if I remember
correctly, so maybe they decided to give gamers another
"incentive".
The DS4 worked on Windows at launch through DirectInput I believe. You only needed a driver for games which didn't support DirectInput (most games use XInput) so that's where you used something to map to Xbox controls.
Oh yeah, I was floored when I plugged a DS3 into my Linux laptop and the KDE UI came up prompting me to pair the device over Bluetooth. Sure enough, I unplugged it and it seamlessly switched to Bluetooth. That was a level of integration I wasn't expecting, and without ever installing any DualShock-specific package.
Unfortunately, one of the reasons I bought the controller was to try out the pressure sensitive face buttons, and PCSX2 on Linux didn't seem to support that? On Windows, PCSX2 can do this with ScpToolkit, but that seems to be abandoned. Still, for the 99% of games that don't need pressure sensitive face buttons, the DS3 integration in Linux was literally perfect.
Sony support PS4 and PS5 remote play on Android, so having Linux support for their controllers makes sense (the PS4 controller driver is in Android 10, but DualSense controllers aren't supported there yet)
Okay, I'll bite: Why would Sony want Linux support for their controllers? Like, it's great, but what possible benefit do they get? It's unlikely to sell more PS5s, it... might sell more controllers but I'd be shocked if the profit from that is enough to justify porting the code unless it's really trivial, and the "best" use that I can imagine is supporting emulation which I rather doubt Sony wants to support. So what gives?
Android (linux) support for their Remote Play and cloud streaming services. It's a lot easier to get users to try when you can say "Use your existing controller and a phone you already have!"
Steam Controller added Bluetooth support for their release of the similar Steam Link app.
I think it’s to sell more controllers. Being a good generic PC controller is a small but not insignificant market. And it costs basically nothing since Sony likely already needs the drivers for their own internal use. I use my Xbox 360 controller for lots of games on my PC.
My guess - The controller has lots of new features around the adaptive triggers, haptic feedback, etc. If only PS5 had these, third parties will.have little motivation to add these features to their games. If PC (I hear Steam is doing something about it as well) - Windows and Linux - games can have the support as well, third parties have a bigger base for these features. Likewise for Android use for remote play.
Also, yeah, it sells more of these controllers which are considered by many as THE defining next gen feature.
If you already bought the controller and like it you might be more likely to choose their console if you later choose one. Linux is desktop gaming is niche, but Android isn't and it could get incorporated there.
> to justify porting the code unless it's really trivial,
I'm not sure about the reasons, but the porting shouldn't be a huge issue. The patches are pretty small and very readable. It's 99% state management (device added / initialised / removed) and unpacking the message fields into system events. If they have anyone familiar with that event/device system, it would be pretty easy to achieve.
I spent to some time to check and analyze the code.
The author uses it in a clear pattern, specifically, as a sibiling post mentions, in order to achieve error handling (additionally, with fall-through); the labels are indeed neatly placed at the end of the function, after the `ret` exit.
The problem is consistency - the upper half of that function performs error handling without goto, and the lower half with it.
I personally prefer all-or-none solutions, since I highly value consistency, but on the other hand, I do consider this solution acceptable, since it still has a tidy (enough) structure.
I've seen the goto error-handling approach used now in SDKs written by developers from companies like Microsoft, Nvidia, and Nordic Semiconductor. It really does seem to be the best way to do it. And it's simple. Mess something up... goto cleanup... Seems fine to me!
Can you think of a counterexample? I wouldn't be surprised if you could trick a compiler with a goto but optimizing control flow is very much the type of optimization that Knuth was referring to. Now that almost all compilers use SSA I'd be surprised if it was the case outside of fairly deep control flow
Error handling was already mentioned ITT. Goto use seems like a litmus test for bad programming. The presence of it doesn't prove bad programmings but lots of goto statements could be reasonably be expected to be replaced with safer switch statements. Extremely nested functions are another area that is best served with a goto. Breaking out of many functions has performance implications I believe.
If you’re criticizing goto in kernel source, you don’t know what you’re talking about. It’s incredible how many people just regurgitate this anti-goto meme without any experience writing system C code. There are various highly structured uses of goto used for systems programming in C, most prominently for error handling but also for things like retry logic.
I checked (just for you). All four gotos are reasonable forward gotos and not what the article "goto considered harmful" was referring to. As an aside, why did you write goto in all caps in your comment? While your comment was quite basic, it wasn't BASIC, so no such caps are required. Please don't shout.
Unfortunately as blog post says, the unique features introduced with DualSense (e.g. Adaptive Triggers, VCM based Haptics) are not yet supported.
I was wondering has anybody hacked/reverse engineered them? Wanted to play a bit with the haptic feedback over the years and see the responsiveness and expressiveness of the feedback.
It's plug + play with Windows as well, at least with Steam. Like in the article, the adaptive triggers don't work, but the rest of the functionality does. I'm curious if it worked on Linux on steam before this driver.
> Not yet supported are new unique features introduced by the DualSense such as Adaptive Triggers and the VCM based Haptics. These features require a large amount of data and complex data structures. It is not clear how to expose these. The current Evdev and FF frameworks are too limiting. We hope to have a dialog on how to expose these over time in a generic way.
It looks like the Sony devs want to support the new vibration features, but don't want to abuse the existing hid/input layer for the amounts of data it apparently requires. It is good they're looking for feedback (I assume via the kernel development mailing lists) on the right route to implement them.
It'd be neat if we started to see a lot of open source projects that used this controller in the same way Kinect projects took off.
That doesn't necessarily require that the base system be the same system; for an extreme case, there's no reason they couldn't just stick the PS4 OS in a VM. (I mean, I tend to agree and I think it's most likely that the new OS is just an enhanced version of the old one. I just want to point out that mere compatibility is only weak evidence.)
This is the first time I see the Playstation 5 controller and I want to cry. What did they do to the controller? It looks like an Xbox controller. Is there an alternative controller? Can you use DS4 with Playstation 5? This is awful!
Let's hope that macOS will soon support DualSense controllers too. Was a little disappointing to find out that Google Stadia on Mac does not work with these controllers.
Just to temper expectations, gaming on Linux is still not a plug and play type experience (although it is a LOT closer than it was 5 years ago).
Even games that have reasonable performance on Linux may require custom builds of Proton, winetrick startup modifications, etc. I love Proton and the work Valve has been doing, but I certainly feel the friction when gaming on Linux still.
Considering it's not native I would say it is still pretty impressive. And hopefully at the speed these developments are being made right now it is just a matter of time until we get that plug and play experience we are all hoping for ;)
Eh, I feel like I have a 50% chance of a game working in proton. Age of Empires II works, but has multiplayer issues (which, while it "works" in GloriusEggroll's 5.21 build, that's about all it is since I get frame stutter / 13 FPS which I do not see in single player). Warframe is another game which kinda works, but can have some visual/audio quirks (audio issue being listed as fixed in GE 5.21 proton as well but I haven't tested it yet). On the more positive side, Witcher III works well enough for me to consider it "no tinkering needed"...so there are definitely success stories out there. I just wouldn't expect the majority of titles to "just work" at this point in time.
All in all, I stand by what I said in that Proton is great, but expectations should be tempered since it definitely has some rough edges still.
It's beyond amazing technically, but unusable for a lot of (I'd like to say "most" but I don't want to argue) gamers, since DRMed games mostly won't work, that include most new games.
Even the most aggressive DRM like Denuvo absolutely does work. You might be thinking of Anticheat, which tends to not work. So multiplayer is currently pretty limited, everything else tends to work.
I spend 99% of my time on Ubuntu, but still keep a stray Windows OS around for Dota/Warzone. This last year I've only clocked 4 hours granted... but It'd be nice to actually not care anymore.
It's really weird, one of the things as a kid I remember losing my main WIndows install being a big deal.. days or recovery. Now I just sit down at a Windows machine and it I don't care what's on it. I don't use windows for anything but the odd game.
Probably the orders of magnitude more internet bandwidth. My current internet connection is about 20,000 times faster than the one I had as a kid. And I'm only a little bit old.
That all depends upon a given person's definition of viable.
Personally, I have more games that I know what to do with. Most of them are Linux native and the vast majority of those that aren't Linux native work under Proton/Wine. Performance or stability is almost never a problem.
The few games that I have encountered problems with under Linux use a custom engine and I have heard that anti-cheat software tends to break compatibility. I periodically boot into Windows to play games that don't run under Linux. That does not happen often since it is an awful lot of trouble when there are many excellent options that do work under Linux.
I don't use it much, but I have heard from others that do that Proton is good and continually getting better. While things like drivers are still hard problems, distros like Ubuntu have made them easier for users that aren't super technical. Linux is a much better place for gaming than it was just a few years ago.
I have mixed feelings about the emulating-Windows approaches. They've let some people run some games, without running Windows, for whatever reason they want to do that, but...
Another way to look at it is that this has been going on for 20+ years, and it's kept relieving whatever pressure exists to get games then on Windows to be on something more open.
(Yes, I built a SteamOS box a few years ago, but that turned out to look mostly like a negotiation tactic, for Valve's continued coexistence with Microsoft. Maybe there will be another attempt someday, supported by Vulkan.)
Microsoft has fired the testing team that makes backwards compatibility so reliable. Having a separate open source implementation will be the only way to run many of those games 10 years from now.
They keep making revenue from the Windows workstation business even though they've clearly telegraphed that none of the stuff people are paying for and expecting to work will do so in a decade... it's ridiculous
Proton is based on WINE. WINE stands for WINE Is Not an Emulator. It's a compatibility layer, and why shouldn't Linux have a Windows compatibility layer? The more you can do on Linux, the better.
I am just using Linux for gaming these days with Stadia. I don't see any reason that cloud gaming won't become more popular in the near future, in which case Linux is perfectly fine for gaming
It's probably OK if you play big games like RPGs with open worlds that tend to be already slow, but the input lag is just too high to play competitively - obviously most people don't but we should aim for better.
> ...the input lag is just too high to play competitively
Do you have any numbers to support that? I have seen your argument before, but I'm yet to see it quantified. I don't see how Stadia would be slower than any other games whose ground-truth 'state' lives on a server somewhere, which I think is the majority of games these days[1]; trusting the client to faithfully maintain state is a no-no because of cheating. If anything, I would expect Stadia servers' ping-times to be better than most.
I don't expect Stadia to work very well with Super Smash Bros were frame-perfect parries/combos are expected (at he highest level) - but for the rest of us who do not qualify for a spot on an e-sports team, it works well enough.
edit: So I went and looked for the numbers - PCGamer[2] says that Stadia is about 60-80ms slower than PC for Tomb Raider and Destiny 2 (eg. 63ms PC / 125ms Stadia @1080 Stadia gets worse at higher resolutions and on TVs, obviously)
I don't have any data for a modern FPS, but Arma 3 used to have about 120ms of input lag - that's a little bit worse than what you've suggested, and it was almost unplayable.
I don't mind I guess because I've never noticed the input lag at all. Also as cloud gaming gets bigger the machines will be in more places and thus closer to the clients
There was a lot of enthusiasm for Linux on the PS3 around release due to the Cell processor. While I doubt that many people who exploited this feature for research purposes were bitten by Sony's reversal, I would imagine that a handful of home users were (since they would have updated the firmware to play games).
That said, 10 years is an awful long time to hold a grudge.
Not really. It's taking a feature that he paid for, and it was really cool to have access to that processor. At least it would have been. I wasn't really into machines at that point, but it would have been cool.
I installed the yellow dog build, it was terrible because there was only 256mb of ram available for general use, and no low-level hardware access to video acceleration.
People complain about this like it was so awful they removed this feature, but TBH it was terrible and only designed so they could get around tariffs in some countries by calling it a computer rather than a videogame console.
actually YellowDog shipped a kernel build later that would map the 256MB of the GPU to be used as system memory (so 512 MB in total). Whether or not the whole system was "usable" depended on your need. Since yellow dog shipped with enlightenment, it was pretty usable. Of course, the whole system was only interesting to people interested in the Cell processor and wanted to code for it.
It'd be pretty cool if I could buy a Linux controller that didn't cost $70 and break so easily. We have yet to see how this new gen holds up but last gen was trash. I had 2 ps4 controllers just stop working via bluetooth and 1 even had a bad usb port so it couldn't even hold a charge/maintain a connection.
I don't know if it's worthwhile anymore, but playstation 2 -> usb HID adaptors work pretty well. Modern Windows doesn't seem to care for them very much anymore though (they still work, but very little UI support).
XBox One controllers are built like bricks, and have the advantage of being natively supported down to the controller button prompts in many more games on Windows because they’re either forward or backported to the actual Xbox.
My kids under ten do all of those things with way more violence than makes sense. I can't let them use them plugged in, for somewhat obvious reasons. They've still done so, of course. Ripped off the connector of three usb cables. So far, still going strong. :Shrug:
was known to be tough. Over engineered, which makes sense in a new market.
I had a friend, who would get annoyed/frustrated, and literally THROW the joystick against the wall. The floor. Your head. :P Tantrum kid.
Anyhow, other than the rubber top coming off of the stick, it just worked forever. I remember when I moved to the Vic20, then the C64 and eventually the Amiga, I still had those Atari joysticks in use with each newer machine.
Incredible joystick. I can't imagine a modern console controller standing up to Tantrum Kid.
(Not saying your kids are throwing controllers at walls, floors, people's heads, etc...)
IMO the controller is built as a brick. I still have the release day controllers and the only thing that has happened is that the sticker have become white. Not a scratch otherwise and I am one of those that take the PlayStation out to friends to game pretty often. Out of these friends I have only seen one controller damaged, by a kid who destroyed an analog stick.
Of course I can't prove it but I bet that close to all damaged PS4 controllers are "it just broke! I totally never threw it or hit it against the wall in a fury because I died...." damage.
Edit: Seems there is more details in a almost year old article on phoronix (https://www.phoronix.com/scan.php?page=news_item&px=Sony-HID...):
> Roderick Colenbrander of Sony who serves as their Directory of Hardware & Systems Engineering, chimed in on the matter of adding this Gasia controller support (And, yes, this is the same Roderick Colenbrander who in his spare time serves as a Wine developer and if going back to the early 2000's was the NVClock NVIDIA overclocking tool developer as opposed to being some eager Sony employee):
So seems Roderick is a true hacker! I've used both Wine and NVClock in the past so if you're around here, thanks for your work on all these things and upstreaming them as well! :)