Can recalibration help when the controller is connected to a Playstation? Does it store the calibration somehow in the controller? Or is this only useful on a PC?
I'd love to somehow restore my PS5 DualSense that's fallen victim to stick drift. I looked once in Steam's debug info and instead of the stick reading 0 at center it was reading about 20,000. Given the max is 32,767 I've lost 2/3 of the useful range, so maybe there's no fixing it with software.
Yes, that's the point! I suggest to try calibration in temporary mode (center calibration has a checkbox in the wizard). See with https://hardwaretester.com/gamepad if the controller is calibrated correctly, in that case redo calibration in permanent mode. That flashes the calibration in the controller.
DS4Windows is a decent tool for the dual sense, I think they have an offset you can configure while using it on PC but it wont store to the controller itself..
The CH Mach III looks tight!
I was messing around with a DOS game Sword of the Samurai and was wondering what types of sticks were being used by enthusiasts at the time since that game supported a joystick.
What kind of things were you playing with that when you purchased it new? I'm in this industry in no small part to watching my brother play Descent with a joystick in the 90s. I think his was made by the same company - F-16 Flightstick. I remember it having suction cups on the bottom though
New would have been Chuck Yeager's Advanced Flight Trainer various EPYX sports games (e.g. Winter Games & California Games) A bit later would be Wing Commander and Traffic Department 2192. Even later (besides several Wing Commander sequels and spinoffs) Tyrian, One Must Fall 2097, and Duke Nukem 3D (keyboard & joystick instead of keyboard & mouse).
That works quite well, but I had to repeat it a few months later. I recommend cleaning also the other stick as the plastic in the DS4 casing can break from opening it too often.
"I noticed that many repair technicians were using my scripts to recalibrate controllers, which significantly reduced repair times and costs. However, many of them were also having a tough time setting up the environment to run the scripts: Python, libusb, Windows drivers, and all that complicated stuff: the user experience was completely off.
This led me to the idea of creating a multiplatform web UI that could simplify everything. I developed a prototype and shared the link on a Facebook group for repair technicians, where it was warmly (..really warmly!) received."
That's so wholesome. Other people would have seen their software being used and decided they should be turning a profit from it.
I am guessing the author is an alien tapped into the Strategic Galactic Good Cheer & Chill Reserve. That explains being able to provide a free utility/online service to the audience of 'gamers, when their controller is effed up'.
it does ask for permission, but a malicious website could ask it for a valid reason and then brick it, yup.
On the other side, a controller should not be brickable via HID commands...
> It is available only for Google Chrome, Chromium or compatiable browsers (e.g. Edge) because it uses WebHID, a javascript extension that can be used to send commands to a HID device.
I didn’t know about WebHID, but it’s interesting Firefox doesn’t support it. According to Mozilla’s position[0]:
> This API, like WebUSB, provides access to generic devices. Though this API is limited to human interface devices (HID), the same concerns apply as WebUSB, namely that devices are generally not designed with access from arbitrary websites in their threat model.
>Here are some examples of features we have decided to not yet implement due to fingerprinting, security, and other concerns, and where we do not yet see a path to resolving those concerns:
Web Bluetooth
Web MIDI API
Magnetometer API
Web NFC API
Device Memory API
Network Information API
Battery Status API
Web Bluetooth Scanning
Ambient Light Sensor
HDCP Policy Check extension for EME
Proximity Sensor
WebHID
Serial API
Web USB
Geolocation Sensor (background geolocation)
User Idle Detection
They are OK with it because it's behind an explicit permission dialog and the user has to specifically choose a single device to grant access. I doubt there's been a single instance of a real world attack using this API. It's been enabled by default in Chrome for years, so it's not like there hasn't been an opportunity. This is just concern trolling by people who dislike the modern web for other reasons.
Moving goal posts. I guess all of this xz stuff is overblown because we do not have a documented case where it was used? Just research about something that might happen does not count, I guess.
I moved nothing. You didn't read my original comment that clearly specified "real world attack". Your second link doesn't qualify either. Besides, if you can connect a malicious USB device to the user's computer you've already won. There are a million ways to exploit that which have nothing to do with Chrome.
The xz thing was a big deal precisely because it was a real world attack. It wasn't something created by researchers as a proof of concept and disclosed to vendors. It was discovered in the wild, luckily before it caused any damage, but it was absolutely a real world attack.
Probably because it's listening to two general purpose input devices all the time at the very least? If you're that paranoid you probably shouldn't be using a non air-gapped machine in the first place.
JFC, is there any host functionality that Chrome will not try and implement in the browser. No wonder it is so bloated and leaks your fingerprint in a million different ways.
Apple says they will not implement WebHID and 15 other "features" in WebKit...
>Here are some examples of features we have decided to not yet implement due to fingerprinting, security, and other concerns, and where we do not yet see a path to resolving those concerns:
Web Bluetooth
Web MIDI API
Magnetometer API
Web NFC API
Device Memory API
Network Information API
Battery Status API
Web Bluetooth Scanning
Ambient Light Sensor
HDCP Policy Check extension for EME
Proximity Sensor
WebHID
Serial API
Web USB
Geolocation Sensor (background geolocation)
User Idle Detection
I completely understand the desire to not implement such things, but I also understand why they exist.
Unfortunately, perhaps due to a mixture of elitism, protectionism, and market dominance, writing cross-platform software in any capacity, let alone cross platform software that requires low-level hardware access, Bluetooth, video, geolocation, etc., is far harder than it deserves to be, and using the web as an abstraction layer makes these things a million times easier.
edit: It's also far easier to distribute this stuff. I just want my video game controller working in slightly better order - I don't want to have to install some bluetooth library and then choose between an x86 Mac, ARM Mac, x86 Windows, x64 Windows, AppImage, deb, flatpak, .tar.gz, snap, my package manager (if it's even there), try install it, shit, it doesn't run on my distro, patch it, use it once, then uninstall it.
Chrome is doing amazing work with these WebAPIs. Here's a quick list of things enabled by Chrome being open-minded and allowing WebHID and WebUSB APIs to exist:
The browser is a great for distribution (apps are just URLs) and security (web pages need to ask permission before accessing anything on your computer outside of their domain).
More people should question the common belief that desktop OSes (without enforced app sandboxing) do a proper job at being a platform for utilities like OP's. When you download and run an .exe on a normal Windows pc, you're giving it read and write access to everything on your user account. It's bad that you're required to put so much trust in developers to run programs on typical desktop systems; this either ends up causing people to be extremely picky about what they run or to give out trust too freely and get bitten by malware often. Platforms like the browser which sandbox (web) apps and enforce a granular permission system are terrific.
Web pages can't do anything that affects the rest of your system without going through a permission dialog, and the permissions are always very granular. A page can't trigger a yes/no permission dialog to get access to all of your files; it can only trigger a file-picker that gives it access to whatever the user picks in it. An .exe doesn't need to go through any permission dialog to upload/wipe/infect any file in your home directory.
Hey - total tangent, but... I'm playing through Horizon Forbidden West. It's the first game on PC I've played that supports the DualSense (PS5 controller)'s haptic motors and adaptive triggers. They are something else when integrated properly with game events and sounds. It would be cool if this were integrated into more games!
Funny, I wish most games gave more options to turn them down. Some newer games are REALLY excessive with it. I encountered one game recently that felt it was necessary (no way to disable) to make the controller vibrate every single time you used the d-pad in the UI.
You have to give it permissions to interface with the device, but also it sounds like a site wouldn't be able to so much "brick" it but rather miscalibrate it since it's not permanent. I assume it's just setting some offset values specific to the controller based on the stick's center point and whatnot. If a malicious site were to do that, you could just come back to this site and fix it.
Reading it more clearly the developer actually expresses concern about allowing the code to run on clones resulting in potentially bricking them due to not supporting the same operations. Perhaps its more accurately a possible deficiency in clone controllers that the developer supposes may be in danger.
Would be nice to see the same sort of aggressive policing in Brave posts, that are constantly rife with attacks and misinformation.
Aside from that, in this case its pretty obvious you're letting yourself be used as a suppression vehicle by FOSS crazies ramming the flag button. Would have been nice to see a more neutral action being taken instead of choosing a side.
Your comment was completely unrelated to the Show HN - a place for people to discuss and receive feedback on their work. No side-choosing needed here other than that of the original author and the people who want to talk about the thing being showhn.
WebHID is related, especially because usually on every single post involving WebHID you’ll have people bringing up how it’s not a real standard.
That also segues into something I’ve mentioned before: moderation needs to be consistent. Randomly picking when to pull the trigger and when not is a bunch of crap.
Everything is related to everything somehow. You can't start dumb flamewars on HN and it's especially bad form to start them in people's Show HN, that's all.
Sure. The flamewar is this thread. And it starts with things like "you’ll see Firefox diehards froth at the mouth" which is not an invitation to curious conversation (the aspirational goal of the site) but a call for other flamewarriors to come out and play. You can't talk to people or really about most people like that on HN, which I'm sure you've seen in the guidelines. Same goes for the grumpsneer edit you tacked on after getting downvoted and flagged.
As such I agree that Firefox refusing to implement things like WebSerial and WebHID is shooting themselves in the foot, and will only drive more users towards Blink.
You could have made your point in a less inflammatory way, though.
Allowing serial but not HID would be really strange. With HID you get standard identifiers that let you filter out devices that are too dangerous for the web. With serial you get nothing. Even if you know a device is dangerous, there's no way to protect users from it.
You could acquaint yourself with the timeline of WebHID.
Google presented a "spec" that wasn't even a spec. They were asked to create a better spec. Instead they just shipped WebHID, and several months later dumped several hundred pages of specifications saying "there".
Whatever your position on hardware standards are, this is not how standards are presented.
Edit: the status of WebHID is literally "not a W3C Standard nor is it on the W3C Standards Track." and it's current state is barely above "scratched on a napkin". But Google couldn't care less
WebHID is work done under Web Platform Incubator Community Group, wicg. http://wicg.io
There's tons of work done with this group, and it is very much a genuine, multi-party attempt to standardize out specs.
I have a hard time believing this is an innocent mistake you've made, portraying such a stark "Google couldn't care less" dark-world fantasy. Over something very normal very boring and very commonly done by everyone in the web community. Yes, the web is bigger than w3c today. It has been for a long long long time now. HTML5 isnt w3c either, but no one is saying the sky is falling because of that.
That's a great link. Even knowing Dmiitri as famously one of the most antagonistic negative people on the web, it's still a bad look. Someone jumping in to point out the team took >two years to do the work & turn it on also seems a lot less wild than much of the selectively portrayed versions.
As Google said in the comments there, they already knew there was strong opposition in principle to this spec, and that they wouldnt get cooperation advancing it, and hence didn't spend as much time doing spec work as they normally would have.
Chrome themselves seem very apologetic about it & to my knowledge this has not happened again.
The other huge missing piece of the picture here is that Chrome didn't write this spec de novo. A huge huge huge amount of the work in writing webhid is re exposing existing USB hid standards & data structures. There should still be a good web spec & this was a failure, but the team was wrapping something that's already very well defined & that they didn't have a ton of leeway to shape and change.
So no one was going to provide meaningful feedback (just, we won't work on this feedback), and the spec was already 3/4 set in stone before work started converting it to a web spec.
It's still a dark-world fantasy to me. And it's deceitful, brazenly incorrect, & full of slanted malice to say chrome isn't or even wasn't interested in standardizations. It's super dodgy quoting the spec saying this ain't a w3c spec as proof that the team doesn't care. That is, you citing, "not a W3C Standard nor is it on the W3C Standards Track." That's a epic & wild distortion, taking advantage of people's ignorance to make Chrome look bad when in fact using groups like https://wicg.io is how tons of amazing great work happens, is a place where all browsers have been bringing new work for a while. You'd have to say Safari and Mozilla don't care about the web too if you want to dump on Chrome here for using wicg to standardize.
There is probably a point of view in here where Google is being stupid, lazily pushing like WebHID without any kind of standards support - like they've done countless times before. But Mozilla is also being stupid about clutching impractically tight to their ideals in a way that harms their users.
Mozilla has done it many times in the past when they tried to only support open-source codecs or refused to implement the DRM black box. In practice, at the time that meant on Firefox you used Adobe Flash for any video playback, and Chrome had a native `<video>` implementation. Even now, due to DRM differences, Netflix maxes out at 720p in Firefox, but 1080p in Chrome, and 4K in Edge.
That's literally the W3C standards process!!! W3C standard are supposed to start with a single vendor implementation, then a draft spec, then collaboration and multiple implementation from other vendors, and THEN a final W3C Standard Specification. The very reason why this spec is not on the standard track is because Mozilla refuses to implement it in Firefox.
Yes, your supposed to have an implementation, but your not supposed to release it into the wild without a working spec and without working it the potential issues.
Did you just miss entire premise of the article, how WebHID made the lives of a bunch of working people much better? Would you rather make these people have a much more difficult time now so Firefox diehard can have a “proper” WebHID in 5 years..?
My phone app would work much better if Android would drop all of its security measures and just let my app access everything on the system. That would make the lives of the bunch of people who use my app much better.
There's nothing "die hard" about wanting to create a proper standard (and being aware of the trade offs) instead of just implementing whatever Google deigns worthy of throwing up.
Now Firefox cannot even implement the "proper HID" because Google has already shipped their version
I mean, its a pretty binary choice. You'd rather have these repairmen (who are laymen at tech) suffer a really crappy workflow just to have a more "pure" solution in an ephemeral point in the future.
However, if you believe that the choice is binary, how's this for a measure: world's largest advertising and tracking company with the world's most dominant browser should not be able to just shove whatever it wants into the browser with full disregard for any and all concerns.
Can recalibration help when the controller is connected to a Playstation? Does it store the calibration somehow in the controller? Or is this only useful on a PC?
I'd love to somehow restore my PS5 DualSense that's fallen victim to stick drift. I looked once in Steam's debug info and instead of the stick reading 0 at center it was reading about 20,000. Given the max is 32,767 I've lost 2/3 of the useful range, so maybe there's no fixing it with software.