In preparation for the upcoming Steam Link app release, the Steam Beta Client has been updated with support for the Steam Controller using a Bluetooth Low Energy (BLE) mode.
Firstly, here's the changelog for the beta client:
Steam Input
- Enabled the Steam Controller BLE FW Update, for more information visit here.
- Added support for the NACON Revolution Pro 2 PS4 controller
- Added support for the PowerA Wired Controller Plus Nintendo Switch Pro Controller
- Improved software gyro drift correction
Diving into more detail in another post, Valve explained the new Steam Controller functionality. It's interesting, because it won't just enable the Steam Controller to link up with Android and iOS devices for the Steam Link app that's coming. It will also allow you to link it to say, a laptop, where perhaps you have no USB ports free for the wireless receiver or if you've broken/lost it.
It does require a firmware update for the Steam Controller, which is a simple process. When you load the Steam client from the latest Beta, it will come up with a prompt with a button to update when you turn your Steam Controller on. Warning: You will need to pair your Steam Controller again as this wipes it.
I tested it myself this afternoon and it will come up exactly like this:
It will then bring up a much bigger window, that will warn you about it needing to be done over a wired connection:
The process is a little dumb right now, as soon as I plugged the wire into my Steam Controller that window just vanished. Thankfully, Valve have thought about that and so there's this page which includes a link to force the update.
I had quite a lot of trouble getting my Steam Controller paired again after this, since it wipes it. If you also have the same issue, try unplugging the wireless dongle and then plugging it back in. Then re-try pairing, which made it work for me. And now here we are, all updated:
Once done, you can switch between the modes easily when turning the Steam Controller on. Simply hold down the Steam Button + A for the normal wireless mode and Steam Button + B for BLE mode.
Going a little further, I decided to test out this BLE mode on my laptop. Sure enough, it works! Paired okay after a few attempts of turning Bluetooth off/on:
It connects fine and with the Steam Client loaded and having the correct udev rules in place (see Valve's GitHub for them) it did seem to work:
Switching it between modes to test between my desktop and my laptop worked perfectly too. Connection on both was instant. Seems like this is going to make the Steam Controller quite a lot more useful. Good stuff from Valve here, really nice to see them continue to improve their hardware.
Thanks for the tip, pepster!
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Quoting: slaapliedjeQuoting: F.UltraQuoting: slaapliedjeQuoting: F.UltraStill sad that still in 2018 things get's completely wiped on firmware updates. Wouldn't it be nice if vendors of controllers, BIOS/UEFI, Smart TVs and so on would put the configuration on a separate memory location that didn't get wiped.
Speaking of wiping things...
I was all happy, booted into Linux, launched Steam, which I thought pulled in the new version, but it doesn't auto-restart itself, so when I turned on the Steam Controller, nothing. Restarted Steam, it then said there was a firmware. Started the firmware update, but it said I had to plug it in.
Plugged it in and... my hard drive went away. Now I'm creating a LiveCD to fix my Debian install.... looks like grub got completely borked!
Hopefully my drive still has data on it... it literally started popping up a bunch of ext4 errors.. :(
I think this is one of the "don't confuse correlation with causation" situations. Unless it required you to be root I have a hard time seeing Steam being able to overwrite the MBR of your drive. Most likely is that there is some kind of problem with your drive that happened to show itself at that particular moment (perhaps the download of the firmware was the first time there where a write done on this particular partition for some time).
My theory is that it tried to mount the Steam Controller as a drive, and for some weird reason my BIOS decided that drive should be /dev/sdb (my Linux drive) because it acted exactly as if /dev/sdb had been unplugged. I ended up updating my bios there was a fairly recent update) and then doing the update again and it worked fine.
The thing is, clearly Steam doesn't have to be root to write the firmware to Steam Controller, it also doesn't have to be root if you have Linux set up to be able to mount USB devices automatically, which almost all desktop OS's are set up that way.
To be fair, it never actually got to the 'update firmware' stage, it gave an error that I needed to plug it in, I plugged it in, the dialog disappeared as did my system.. .for a time. Besides having to run grub-install /dev/sda and update-grub (after I got back into Debian to add Windows back to the boot loader).
So your hard drive was connected over USB? Well that might explain it then.
0 Likes
slaapliedje May 19, 2018
Quoting: F.UltraQuoting: slaapliedjeQuoting: F.UltraQuoting: slaapliedjeQuoting: F.UltraStill sad that still in 2018 things get's completely wiped on firmware updates. Wouldn't it be nice if vendors of controllers, BIOS/UEFI, Smart TVs and so on would put the configuration on a separate memory location that didn't get wiped.
Speaking of wiping things...
I was all happy, booted into Linux, launched Steam, which I thought pulled in the new version, but it doesn't auto-restart itself, so when I turned on the Steam Controller, nothing. Restarted Steam, it then said there was a firmware. Started the firmware update, but it said I had to plug it in.
Plugged it in and... my hard drive went away. Now I'm creating a LiveCD to fix my Debian install.... looks like grub got completely borked!
Hopefully my drive still has data on it... it literally started popping up a bunch of ext4 errors.. :(
I think this is one of the "don't confuse correlation with causation" situations. Unless it required you to be root I have a hard time seeing Steam being able to overwrite the MBR of your drive. Most likely is that there is some kind of problem with your drive that happened to show itself at that particular moment (perhaps the download of the firmware was the first time there where a write done on this particular partition for some time).
My theory is that it tried to mount the Steam Controller as a drive, and for some weird reason my BIOS decided that drive should be /dev/sdb (my Linux drive) because it acted exactly as if /dev/sdb had been unplugged. I ended up updating my bios there was a fairly recent update) and then doing the update again and it worked fine.
The thing is, clearly Steam doesn't have to be root to write the firmware to Steam Controller, it also doesn't have to be root if you have Linux set up to be able to mount USB devices automatically, which almost all desktop OS's are set up that way.
To be fair, it never actually got to the 'update firmware' stage, it gave an error that I needed to plug it in, I plugged it in, the dialog disappeared as did my system.. .for a time. Besides having to run grub-install /dev/sda and update-grub (after I got back into Debian to add Windows back to the boot loader).
So your hard drive was connected over USB? Well that might explain it then.
No, it is over SATA. I do have to point out that these two SATA drives I have do have a weird issue with randomly disappearing off the bus, causing the OS to crash, but this is the first time it has happened to my Linux drive (the other one has Windows 10 on it and has done it a few times.)
I think it is time for a reinstall of Debian Sid anyhow, something funky is going on, since it won't read Audio CDs, yet my Arch Linux install on another drive woks perfectly fine.
0 Likes
Quoting: slaapliedjeQuoting: F.UltraQuoting: slaapliedjeQuoting: F.UltraQuoting: slaapliedjeQuoting: F.UltraStill sad that still in 2018 things get's completely wiped on firmware updates. Wouldn't it be nice if vendors of controllers, BIOS/UEFI, Smart TVs and so on would put the configuration on a separate memory location that didn't get wiped.
Speaking of wiping things...
I was all happy, booted into Linux, launched Steam, which I thought pulled in the new version, but it doesn't auto-restart itself, so when I turned on the Steam Controller, nothing. Restarted Steam, it then said there was a firmware. Started the firmware update, but it said I had to plug it in.
Plugged it in and... my hard drive went away. Now I'm creating a LiveCD to fix my Debian install.... looks like grub got completely borked!
Hopefully my drive still has data on it... it literally started popping up a bunch of ext4 errors.. :(
I think this is one of the "don't confuse correlation with causation" situations. Unless it required you to be root I have a hard time seeing Steam being able to overwrite the MBR of your drive. Most likely is that there is some kind of problem with your drive that happened to show itself at that particular moment (perhaps the download of the firmware was the first time there where a write done on this particular partition for some time).
My theory is that it tried to mount the Steam Controller as a drive, and for some weird reason my BIOS decided that drive should be /dev/sdb (my Linux drive) because it acted exactly as if /dev/sdb had been unplugged. I ended up updating my bios there was a fairly recent update) and then doing the update again and it worked fine.
The thing is, clearly Steam doesn't have to be root to write the firmware to Steam Controller, it also doesn't have to be root if you have Linux set up to be able to mount USB devices automatically, which almost all desktop OS's are set up that way.
To be fair, it never actually got to the 'update firmware' stage, it gave an error that I needed to plug it in, I plugged it in, the dialog disappeared as did my system.. .for a time. Besides having to run grub-install /dev/sda and update-grub (after I got back into Debian to add Windows back to the boot loader).
So your hard drive was connected over USB? Well that might explain it then.
No, it is over SATA. I do have to point out that these two SATA drives I have do have a weird issue with randomly disappearing off the bus, causing the OS to crash, but this is the first time it has happened to my Linux drive (the other one has Windows 10 on it and has done it a few times.)
I think it is time for a reinstall of Debian Sid anyhow, something funky is going on, since it won't read Audio CDs, yet my Arch Linux install on another drive woks perfectly fine.
Sounds like the issue is more likely connected to your "randomly disappearing off the bus" then. An application needs to be root in order to write to the block level of any device, that you can upgrade the firmware of the SC without beeing root is due to it performing firmware updates as either normal file transfer or with their own protocol on top of USB/BT.
0 Likes
slaapliedje May 23, 2018
Quoting: F.UltraQuoting: slaapliedjeQuoting: F.UltraQuoting: slaapliedjeQuoting: F.UltraQuoting: slaapliedjeQuoting: F.UltraStill sad that still in 2018 things get's completely wiped on firmware updates. Wouldn't it be nice if vendors of controllers, BIOS/UEFI, Smart TVs and so on would put the configuration on a separate memory location that didn't get wiped.
Speaking of wiping things...
I was all happy, booted into Linux, launched Steam, which I thought pulled in the new version, but it doesn't auto-restart itself, so when I turned on the Steam Controller, nothing. Restarted Steam, it then said there was a firmware. Started the firmware update, but it said I had to plug it in.
Plugged it in and... my hard drive went away. Now I'm creating a LiveCD to fix my Debian install.... looks like grub got completely borked!
Hopefully my drive still has data on it... it literally started popping up a bunch of ext4 errors.. :(
I think this is one of the "don't confuse correlation with causation" situations. Unless it required you to be root I have a hard time seeing Steam being able to overwrite the MBR of your drive. Most likely is that there is some kind of problem with your drive that happened to show itself at that particular moment (perhaps the download of the firmware was the first time there where a write done on this particular partition for some time).
My theory is that it tried to mount the Steam Controller as a drive, and for some weird reason my BIOS decided that drive should be /dev/sdb (my Linux drive) because it acted exactly as if /dev/sdb had been unplugged. I ended up updating my bios there was a fairly recent update) and then doing the update again and it worked fine.
The thing is, clearly Steam doesn't have to be root to write the firmware to Steam Controller, it also doesn't have to be root if you have Linux set up to be able to mount USB devices automatically, which almost all desktop OS's are set up that way.
To be fair, it never actually got to the 'update firmware' stage, it gave an error that I needed to plug it in, I plugged it in, the dialog disappeared as did my system.. .for a time. Besides having to run grub-install /dev/sda and update-grub (after I got back into Debian to add Windows back to the boot loader).
So your hard drive was connected over USB? Well that might explain it then.
No, it is over SATA. I do have to point out that these two SATA drives I have do have a weird issue with randomly disappearing off the bus, causing the OS to crash, but this is the first time it has happened to my Linux drive (the other one has Windows 10 on it and has done it a few times.)
I think it is time for a reinstall of Debian Sid anyhow, something funky is going on, since it won't read Audio CDs, yet my Arch Linux install on another drive woks perfectly fine.
Sounds like the issue is more likely connected to your "randomly disappearing off the bus" then. An application needs to be root in order to write to the block level of any device, that you can upgrade the firmware of the SC without beeing root is due to it performing firmware updates as either normal file transfer or with their own protocol on top of USB/BT.
Except that some auto-mounting stuff happens when you plug in a USB Stick. While yes, ultimately root access is required for all the udev bits and pieces for that to work, that means access is there for when installing a new USB device, because that can load new kernel modules.
It's not entirely a random thing if it happened the exact moment I plugged in the controller. Who knows. Every time something similar has happened to me, it's always been caused by these two Mushkin SSDs. Let's just say next time I get SSDs for my system, I won't be buying them from Mushkin.
Edit: Model number is MKNSSDCR480GB-7 in case anyone else wishes to avoid them.
Last edited by slaapliedje on 23 May 2018 at 3:26 am UTC
0 Likes
Quoting: slaapliedjeQuoting: F.UltraQuoting: slaapliedjeQuoting: F.UltraQuoting: slaapliedjeQuoting: F.UltraQuoting: slaapliedjeQuoting: F.UltraStill sad that still in 2018 things get's completely wiped on firmware updates. Wouldn't it be nice if vendors of controllers, BIOS/UEFI, Smart TVs and so on would put the configuration on a separate memory location that didn't get wiped.
Speaking of wiping things...
I was all happy, booted into Linux, launched Steam, which I thought pulled in the new version, but it doesn't auto-restart itself, so when I turned on the Steam Controller, nothing. Restarted Steam, it then said there was a firmware. Started the firmware update, but it said I had to plug it in.
Plugged it in and... my hard drive went away. Now I'm creating a LiveCD to fix my Debian install.... looks like grub got completely borked!
Hopefully my drive still has data on it... it literally started popping up a bunch of ext4 errors.. :(
I think this is one of the "don't confuse correlation with causation" situations. Unless it required you to be root I have a hard time seeing Steam being able to overwrite the MBR of your drive. Most likely is that there is some kind of problem with your drive that happened to show itself at that particular moment (perhaps the download of the firmware was the first time there where a write done on this particular partition for some time).
My theory is that it tried to mount the Steam Controller as a drive, and for some weird reason my BIOS decided that drive should be /dev/sdb (my Linux drive) because it acted exactly as if /dev/sdb had been unplugged. I ended up updating my bios there was a fairly recent update) and then doing the update again and it worked fine.
The thing is, clearly Steam doesn't have to be root to write the firmware to Steam Controller, it also doesn't have to be root if you have Linux set up to be able to mount USB devices automatically, which almost all desktop OS's are set up that way.
To be fair, it never actually got to the 'update firmware' stage, it gave an error that I needed to plug it in, I plugged it in, the dialog disappeared as did my system.. .for a time. Besides having to run grub-install /dev/sda and update-grub (after I got back into Debian to add Windows back to the boot loader).
So your hard drive was connected over USB? Well that might explain it then.
No, it is over SATA. I do have to point out that these two SATA drives I have do have a weird issue with randomly disappearing off the bus, causing the OS to crash, but this is the first time it has happened to my Linux drive (the other one has Windows 10 on it and has done it a few times.)
I think it is time for a reinstall of Debian Sid anyhow, something funky is going on, since it won't read Audio CDs, yet my Arch Linux install on another drive woks perfectly fine.
Sounds like the issue is more likely connected to your "randomly disappearing off the bus" then. An application needs to be root in order to write to the block level of any device, that you can upgrade the firmware of the SC without beeing root is due to it performing firmware updates as either normal file transfer or with their own protocol on top of USB/BT.
Except that some auto-mounting stuff happens when you plug in a USB Stick. While yes, ultimately root access is required for all the udev bits and pieces for that to work, that means access is there for when installing a new USB device, because that can load new kernel modules.
It's not entirely a random thing if it happened the exact moment I plugged in the controller. Who knows. Every time something similar has happened to me, it's always been caused by these two Mushkin SSDs. Let's just say next time I get SSDs for my system, I won't be buying them from Mushkin.
Edit: Model number is MKNSSDCR480GB-7 in case anyone else wishes to avoid them.
For mounting the drives yes, but that will still not give you the low-level access that an application needs in order to do block-level writes such as writing to the MBR. All a non root application can do with a mount is to transfer a file using the filesystem, and to be honest I don't believe that Steam have code in it to do low-level sector by sector writes either.
0 Likes
slaapliedje May 24, 2018
Quoting: F.UltraQuoting: slaapliedjeQuoting: F.UltraQuoting: slaapliedjeQuoting: F.UltraQuoting: slaapliedjeQuoting: F.UltraQuoting: slaapliedjeQuoting: F.UltraStill sad that still in 2018 things get's completely wiped on firmware updates. Wouldn't it be nice if vendors of controllers, BIOS/UEFI, Smart TVs and so on would put the configuration on a separate memory location that didn't get wiped.
Speaking of wiping things...
I was all happy, booted into Linux, launched Steam, which I thought pulled in the new version, but it doesn't auto-restart itself, so when I turned on the Steam Controller, nothing. Restarted Steam, it then said there was a firmware. Started the firmware update, but it said I had to plug it in.
Plugged it in and... my hard drive went away. Now I'm creating a LiveCD to fix my Debian install.... looks like grub got completely borked!
Hopefully my drive still has data on it... it literally started popping up a bunch of ext4 errors.. :(
I think this is one of the "don't confuse correlation with causation" situations. Unless it required you to be root I have a hard time seeing Steam being able to overwrite the MBR of your drive. Most likely is that there is some kind of problem with your drive that happened to show itself at that particular moment (perhaps the download of the firmware was the first time there where a write done on this particular partition for some time).
My theory is that it tried to mount the Steam Controller as a drive, and for some weird reason my BIOS decided that drive should be /dev/sdb (my Linux drive) because it acted exactly as if /dev/sdb had been unplugged. I ended up updating my bios there was a fairly recent update) and then doing the update again and it worked fine.
The thing is, clearly Steam doesn't have to be root to write the firmware to Steam Controller, it also doesn't have to be root if you have Linux set up to be able to mount USB devices automatically, which almost all desktop OS's are set up that way.
To be fair, it never actually got to the 'update firmware' stage, it gave an error that I needed to plug it in, I plugged it in, the dialog disappeared as did my system.. .for a time. Besides having to run grub-install /dev/sda and update-grub (after I got back into Debian to add Windows back to the boot loader).
So your hard drive was connected over USB? Well that might explain it then.
No, it is over SATA. I do have to point out that these two SATA drives I have do have a weird issue with randomly disappearing off the bus, causing the OS to crash, but this is the first time it has happened to my Linux drive (the other one has Windows 10 on it and has done it a few times.)
I think it is time for a reinstall of Debian Sid anyhow, something funky is going on, since it won't read Audio CDs, yet my Arch Linux install on another drive woks perfectly fine.
Sounds like the issue is more likely connected to your "randomly disappearing off the bus" then. An application needs to be root in order to write to the block level of any device, that you can upgrade the firmware of the SC without beeing root is due to it performing firmware updates as either normal file transfer or with their own protocol on top of USB/BT.
Except that some auto-mounting stuff happens when you plug in a USB Stick. While yes, ultimately root access is required for all the udev bits and pieces for that to work, that means access is there for when installing a new USB device, because that can load new kernel modules.
It's not entirely a random thing if it happened the exact moment I plugged in the controller. Who knows. Every time something similar has happened to me, it's always been caused by these two Mushkin SSDs. Let's just say next time I get SSDs for my system, I won't be buying them from Mushkin.
Edit: Model number is MKNSSDCR480GB-7 in case anyone else wishes to avoid them.
For mounting the drives yes, but that will still not give you the low-level access that an application needs in order to do block-level writes such as writing to the MBR. All a non root application can do with a mount is to transfer a file using the filesystem, and to be honest I don't believe that Steam have code in it to do low-level sector by sector writes either.
I'm not saying that's what happened. What I think happened is the bus did that weird thing where something was connected to it (that it was a Steam Controller I think was random and not the root cause) and it decided to remove the drive from the SATA bus. Causing Linux to just freak out as if someone had just unplugged the drive while it was running, which most likely corrupted the grub data on the EFI partition. GPT doesn't use MBR by the way.
This was/is a hardware issue, and didn't have much in the way of how root accesses things or not. I have literally had the Windows drive do this to me many times. I'd be playing a game and it'd just hard lock, I'd reboot and the BIOS wouldn't even see the drive. I would have to do a full power off (even sometimes as far as flipping the hard switch on the PSU) before it'll be detected again. This was just the first time it's done it to me on Linux.
I should just order some new SSDs and swap 'em out, they're 480GB ones and I got them for a good deal years ago. Then again, my motherboard now has a slot for an NVMe too... :P
0 Likes
Quoting: slaapliedjeThis was/is a hardware issue, and didn't have much in the way of how root accesses things or not. I have literally had the Windows drive do this to me many times. I'd be playing a game and it'd just hard lock, I'd reboot and the BIOS wouldn't even see the drive. I would have to do a full power off (even sometimes as far as flipping the hard switch on the PSU) before it'll be detected again. This was just the first time it's done it to me on Linux.Is it a Vortex?
I've thrown out all my vortex SSD's as no matter what system, they will crap themselves and then get disconnected from the bus.
I've had this issue with high end servers, and with my desktop ARM several times.
The only really reliable SSD's are from intel and samsung.
There are stats about that (an nntp server farm using SSD's), and the Samsung Pro seems to be the most reliable.
Taking a step back (half the price), the EVO's are rock solid too.
The only upside of the Vortex is that the firmware upgrade can be done from linux, and their SSD rescue CD was just a linux distro.
0 Likes
slaapliedje May 28, 2018
Quoting: ArdjeQuoting: slaapliedjeThis was/is a hardware issue, and didn't have much in the way of how root accesses things or not. I have literally had the Windows drive do this to me many times. I'd be playing a game and it'd just hard lock, I'd reboot and the BIOS wouldn't even see the drive. I would have to do a full power off (even sometimes as far as flipping the hard switch on the PSU) before it'll be detected again. This was just the first time it's done it to me on Linux.Is it a Vortex?
I've thrown out all my vortex SSD's as no matter what system, they will crap themselves and then get disconnected from the bus.
I've had this issue with high end servers, and with my desktop ARM several times.
The only really reliable SSD's are from intel and samsung.
There are stats about that (an nntp server farm using SSD's), and the Samsung Pro seems to be the most reliable.
Taking a step back (half the price), the EVO's are rock solid too.
The only upside of the Vortex is that the firmware upgrade can be done from linux, and their SSD rescue CD was just a linux distro.
These are Mushkin brand. I recall their memory was one everyone said was great. Not sure what happened, but it was the first dead memory stick I'd ever gotten was a Mushkin, and I only got these SSDs 'cause they were going for a good price. I've heard that though, that you go Intel or Samsung for SSDs.
1 Likes, Who?
Patreon
PayPal
See more from me