How come? Ever since controllers used Bluetooth they would need to use some sort of programmable microcontroller or cpu. Both of these things need to 'boot' at some point. And yes even microcontrollers have bootloaders.
A traditional videogame controller is not much more than a few switches and perhaps a few potentiometers, see for instance the pinout for the Master System: https://www.smspower.org/Development/ControllerPort
That is, someone who started playing videogames in the SMS/NES days might have formed a mental model of the controller being mostly a passive device, with at most a few active chips to multiplex the pins in the interface, to allow for more buttons than there are pins.
Sure (I was there) but the same can kind of be said about mice and keyboards, too.
Ever since USB took off ~30 years ago and basically killed off raw I/O pins on the front of computers, human interface devices have required microcontrollers on board.
> but the same can kind of be said about mice and keyboards, too.
AFAIK, even old keyboards (AT and PS/2 connectors) already had a microcontroller, and the same was true of mice. The communication between the keyboard or mouse and the computer was through a serial protocol, instead of the computer directly reading the keyboard matrix or the mouse buttons and wheels. The exception might have been computers with built-in keyboards. But the joystick port (https://en.wikipedia.org/wiki/Game_port) directly exposed the buttons and potentiometers from the joystick, instead of talking to a microcontroller on it.
I just read all 4 parts and I have thoroughly enjoyed them. I am curious to hear if the debug console (TEPPOU, or gun in Japanese) works. Please keep us posted!
That's what i don't get with linux...having all drivers inside the kernel is madness, no wait...it's pure stupidity. No other Universal OS makes that...crash my system with a USB-Controller...that's some Windows 98 reliability(-issues) right there.
Try searching for "$operating-system crash when connect usb" for various OSes and distributions and you'll see it's a problem everywhere, not just Linux.
Yeah, crashes from hardware driver are fairly common on Windows. And without any surprise, USB is the most common one (I'd say network devices (Ethernet, Wifi, or BT) are a close second).
Ah nice do we try to find excuses that monolithic kernel's are not so bad at all right?
And it's totally ok that those (any) "high-quality" driver can crash the system?
>Linux uses modules, some other BSD not.
Has nothing todo with modules, if it's loaded it's in kernel-space. Not others...OpenBSD is the ONE.
BTW: For those butt-hurt ones (that i blatantly attacked poor linux), it not just about linux but should we no create operating-systems where this is not possible? Just asking...
While I've never tried it in that way, I understand it should function as a standard USB game controller when wired, but its real gem would be fully leveraging its wireless support.
The problem is that Stadia controllers use wireless in the sense of WIFI, not bluetooth. This means that in order to make them work not only is the RE work even harder, but you'd probably have to create a completely new driver since I'm unaware of any other device that can input commands from the internet; whereas with bluetooth we already have extensive tools to deal with it
Neat find. What could cause the calibration offset to be zero? Certainly it did not come this way from the factory. Any abuse/misuse of the controller would not cause it either.
Ah, I suspect this was a firmware update that got borked somehow. Maybe the cable was disconnected before the update could complete.
> What could cause the calibration offset to be zero?
A possible explanation can be found on part 4 of this post:
> [...] if the checksum is not valid, there is a loop that clears out the flash [...] I suspect (but haven’t tried yet) that if the battery of the controller dies while it’s writing on the flash, at the next startup the checksum does not match and the DS4 gets totally messed up like this one.
That is, according to that theory, it was trying to write something to the flash (perhaps while pairing?), and part of the write failed because the battery died. On the next boot, it detected a wrong checksum, and erased everything.
I'd wager a bad/worn NAND block, 'cosmic ray' or other electrical glitch was more likely to cause a checksum issue than anything else. It might be sudden battery disconnect caused due to the controller being dropped (per the first page), but there should be local capacitance on the NAND supply voltage size to last a page write cycle as sudden power loss is going to happen in a lot of situations.
I would generally critique the use of a checksum on this config data without a backup or ping-pong writing system specifically because in the case of a 1 bit failure on something critical like cal or configuration data, really you want the data anyway and just hope that the 1 bit wasn't that important and also be ok if the bit flips back again on the next go around.
Thanks for that, I missed it in TFA. But ouch, that feels like an extreme design choice. What's the logic here to erasing the flash on a failed checksum, or requiring a checksum in the first place? Is there a non-obvious security threat?
The issue is probably a missing A/B firmware update for the config section.
If a firmware update needs to alter the calibration data or other rather static config, and that update process is interrupted by an empty battery then it can't recover. It should of course be more conservative in killing all of the config section... Or could reset to some sane default. Or have a copy of the old known good data around and restart the procedure
A properly made device would at least keep a spare copy just in case, there's more than enough space in flash for that, but no, Sony wants to sell more controllers.
> I wrote a fix for this bug in the linux driver and sent to the linux-kernel mailing list (linux-input), so that a DS4 with a broken calibration does not cause a kernel panic.
I really admire people, who contribute their random findings to improve an open source software on their own time and resources. This is so wholesome.
Yeah, it would be the hardware's fault if it delivered 1000 volts. Delivering any sequence of 1s and 0s should maybe cause the driver to give up, but not to panic the kernel.
USB sucks everywhere. OpenBSD can panic over USB too. It happened to me. Hubs, faulty USB drives, Chinese gamepads, noname ElCheapo USB Ralink WiFi dongles with dubious designs...
I think the only truly secure OS for this would be Hurd or SeL4+Genode.
I don't get the analogy. Why is the dog supposed to be lazy? A dog turding on the street is by design. Maybe blaming the lazy dogs owner would be more appropriate.
It's not a good analogy but at the end of the day it's a bad Linux issue. Sony has no obligation to make sure it's driver will never halt a system. Linux does.
Can we not critique pet peeves and nitpick style? This is how I interpret the guideline, "avoid generic tangents"; if critiquing the style of a piece doesn't help us to understand it better (as is sometimes the case, but isn't here), I don't think it's worth discussing on this forum (as it promotes snide conversation rather than curious conversation).
In my experience working remotely, using lots of emoji is a professional expectation. Kind of like how ASL speakers are more expressive with their faces and bodies than English speakers, because they aren't employing vocal tone. Using lots of emoji prevents misunderstandings of tone (a frequent and avoidable source of bad feelings) and promotes camaraderie. Nothing unprofessional about that, but it may be from a different professional culture than you're familiar with.
If you feel I've decreased the SNR of the thread than I apologize, but when I have a good way to express the issue I have with something, I prefer to express it, for the benefit of the commenter & anyone else reading. I think that's more likely to reduce the rate of comments of this type.
I think that's more likely to reduce the rate of comments of this type.
The unfortunate thing is, it doesn't reduce the rate. The downvotes and flags do, though - most people are pretty responsive to their comments getting nuked.
It won't happen to this emoji-comment but one of their extra-crappy side-effects is that sometimes they end up on the top of the thread and then all the explanations and exhortations to cut the crap end up eating up the page. This happens pretty regularly and then has to be cleaned up. It can't happen if the comment is sensibly flagged.
Well, we can't really know if it does or doesn't reduce the rate (at least without more research than I am aware having been performed, and more than I'm willing to do), but I can only report that my own experience is that reading stuff like this as a lurker has been helpful for me. Given the choice and without the ability to know what is in people's hearts and whether or not I have moved them, I prefer optimism.
I'd propose these ideas are in tension but not contradiction, and that with you walking your path and me walking mine, the community as a whole benefits.
I don't know about research but we certainly have a lot of evidence - people rarely have to explain to other users not to be rude jerks in comments, mainly because people know to flag them and the people who write them learn not to write them. This isn't really about optimism or pessimism but a critical component of the basic social immune system of the forum. You can see this expressed in an infinite stream of guideline-thumping mod comments:
To clarify, I didn't mean to say you were a pessimist, or even that I'm an optimist, just that I prefer optimism in this scenario.
I actually do regularly see rude comments, for what it's worth. We may have different thresholds for what we consider rude. I glanced through the comments in that search, they seemed to be responding to a much higher level of toxicity than what we're discussing, and they're escalating the situation. I don't think nitpickers are trolling or flamebaiting. And to be clear, I'm not suggesting we don't flag comments, I agree that's a critical function to the community.
I think the crux of it is this; if explaining to people the problem we have with their behavior and asking that they change it never worked - why would we be having this conversation? Surely when you asked me disengage in this type of response, you thought there was a reasonable possibility of convincing me?
The main thing I want to convince you of is to flag this type of comment - a thing everyone should do! The engaging (or not) is more practical thing - avoiding the risk of a giant thread of meta sitting at the top of a submission to the detriment of actually interesting discussion. Since everyone loves meta and bickering, this happens quite a bit. If the comment is safely at the bottom of the thread, engage away. I sure can't seem to help it. It just does a lot less good than flagging (which is not just for trolls and flamewarriors).
Completely agree. Specifically (emoji fans take note) it attempts to force a certain mood, when your writing should do that for you. Emojis are fine for adding some visual associaton at the end of text blocks or descriptive paragraphs, or used for a pictographic demonstration of something (even humour). Just gormless facial expressions at the end of everything is just simperingly weak communication.
I hate the use of face/body emoji, but my anecdotal experience is that the biggest users are age 40+, and younger people at least tend to be more creative with emoji.
