Sony publishes an official Linux driver for Playstation 5 DualSense controllers | Hacker News Reader

Sony publishes an official Linux driver for Playstation 5 DualSense controllers

phoronix.com

438 pointsthg122 comments

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.

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! :)

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.

There are some issues with vanilla USB around supporting large devices.

Unlikely to be an issue with a stick, but very possible with an external drive.

So searching for a device specfic driver is a very sane default here.

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.

How is an approach that results in a working device "crazy", where one that will sometimes NOT "not crazy".

The user does not give a flying fig about your "moral high ground".

They just want their drive to work.

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

You can add non-Steam games to Steam and get the full benefit of Steam Input as well.

Now this surprises me because I bought mine in the MS Store. Thanks, I'll look into that.

It even works on non-Steam games running through Wine/Proton on Linux. All other features work as well, like In Home Streaming and Big Picture

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.

How's the latency on BT?

I've always avoided using it because of the horror story from early models, but I might pick up a used PS4 controller for PC gaming if BT works well.

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.

The OG Xbox One controllers didn’t support Bluetooth, but the newer ones (Xbox One S and Xbox One X) do. These don’t work natively in Linux?

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".

8.x was the atrocious tablet UI mashup. They are doing everyone a favor.

I do like Windows 8 on tablets and very small laptops. It certainly has issues but I appreciate what Microsoft was going for.

(I'm less of a fan of Windows 8.1. They made it more desktop-like but it lost its uniqueness.)

I don't think bsd and linux have anything in common other than posix api, which the drivers don't use.

Building a corporate product like PlayStation is nothing like using FreeBSD in a "freedesktop community" way.

i.e. Sony has custom everything, including input stack.

So is this particular device driver already available for FreeBSD?

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.

Steam does this all for you now anyway.

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)

Does PS5 support remote play? Hope I can get verizon 5G home soon to support the upstream requirements

Yeah. The apps have been updated, and I believe there's even a remote play app for the PS4 to stream from a PS5.

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.

Porting the code? The PS5 runs FreeBSD no? I can’t imagine this was a big lift.

Linux and FreeBSD are different systems; closer than ex. porting NT drivers to Linux, but still some distance apart.

The patches to the Kernel are in review and can be seen here: https://patchwork.kernel.org/project/linux-input/patch/20201...

Good to see they are still using GOTO. Straight-forward and performant.

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.

Goto doesn't have a performance benefit over other control flow structures with a modern compiler.

In C GOTO is often by far the cleanest solution for error handling.

Everything else turns into an ugly, unreadable mess in functions that need to free resources or do some kind of cleanup.

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!

My comment has nothing to do with error handling. I was addressing a false claim about performance.

Yes, but it does reduce the level of indentation required in most functions that use it. That consideration is part of the kernel style guidelines.

In system C code its usually used for error and retry logic to make the code more readable. It's rarely ever used for performance.

that's definitely not categorically true

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.

The question was about performance, not necessarily other aspects.

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.

You built a strawman and burnt it down!

Yes, you're right.

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.

People who want to use these controllers when emulating games on rpis will be grateful

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.

Doesn't appear to support the special hardware features of the controller, but we can hope in time.

> 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.

Does anyone know if the PS5 still runs on a variant of FreeBSD like the PS4? Just curious...

Considering that the ps5 can play all PS4 games it seems highly likely.

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.)

Rumours say FreeBSD 12. PS4 used 9.

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!

Er. Good thing for the published driver though.

It does look like a cross between the PS4 and Xbox controller but it feels much more like the former. And it is really good :)

Have you tried it? Almost all reviews have praised the controller and called it a better than the previous iteratios.

I haven't tried it. To be honest, I don't trust console reviews :)

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.

I wonder if this has something to do with the recently-released Atari VCS (which runs Linux).

When was this vaporware released. Even if this was released it wouldn't have any bearing on Sony's decision not release a Linux driver?

We can assume, then, that linux will be a viable place for gaming in the near future.

Linux, since the inception of Proton is a viable place for gaming. Go ahead and try it out, I promise you will be pleasantly surprised ;)

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 ;)

I mean, we kinda already have plug and play, just mostly for older, popular games.

New issues always crop up whenever there's a new AAA title with the latest tech. It's inevitable.

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.

That's it.

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.

https://www.phoronix.com/scan.php?page=news_item&px=Proton-5... looks like it's a new thing, my bad then.

Two years ago, I deleted my Windows partition, because I never used it.

I'm the kind of person that has spent over 10,000 hours on video games... maybe 20k or more.

I don't think it's fair to deride Linux in this way. Thank Gaben for that.

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.

Dota works perfectly on Linux. It's not even through proton. It always worked natively on Linux.

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.

Dota works well on Linux nowadays. Better than on Windows even.

Funny how my most played games are WZ and Dota as well

I do use Mac instead of Linux for development but I did use Debian/Ubuntu as my main partition for a few years.

Dota works great on Linux and it's native.

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)

1. The games I play, which are rather limited.

2. https://www.pcgamer.com/heres-how-stadias-input-lag-compares...

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.

Also, any jitter will be awful too.

If you don't mind the 1000ms input lag.

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

As someone who plays on Linux, I'd bet it's safe to assume exactly that.

I'm ignore all Sony products since PS3 bullshit: https://arstechnica.com/tech-policy/2016/06/if-you-used-to-r...

Did you actually run Linux on a PS3?

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.

My brother did, and he used it daily until Sony took it away.

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'm sticking with 8bitdo for a while.

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 360 controllers also work with generic knockoff wireless adapters off ebay

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.

I'm curious what you do to your controllers. My family of six has so far only done minor cosmetic damage to our controllers.

Well aside from use them like normal, set them down like normal, and connect to bluetooth, nothing out of the ordinary.

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:

Back when I was a kid, the Atari 2600 joystick:

https://www.digitalgamemuseum.org/consolecontrollerevolution...

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...)

I remember throwing nes controllers. Mega man was particularly good at upsetting me.

I also remember taking it as a challenge if we could break a controller. Took a fair bit of effort, all told.

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.

Reply on news.ycombinator.com