[opensuse-factory] Steam Controller as desktop input device?
I was curious whether anyone managed to get the Steam Controller working as an input device in openSUSE? The latest SteamOS update allows the controller to control the mouse in desktop mode. I can picture using it as a slideshow controller if it is able to directly function as a mouse as well.
On 28.12.2015 08:51, Chan Ju Ping wrote:
I was curious whether anyone managed to get the Steam Controller working as an input device in openSUSE?
The latest SteamOS update allows the controller to control the mouse in desktop mode. I can picture using it as a slideshow controller if it is able to directly function as a mouse as well.
Hello. I use the program called AntiMicro (https://build.opensuse.org/package/show?project=hardware&package=AntiMicro) to use Sony DualShock 3 as remote control. Pretty sure it should work with anything as long as it has a kernel driver. I have it in my SUSE build (https://github.com/v-fox/live_opensuse_hsf) but I didn't make the TW-based 0.9.0 release yet. Was planning today but found an issue with networking.
On Monday, December 28, 2015 09:01:51 AM Sergey Kondakov wrote:
On 28.12.2015 08:51, Chan Ju Ping wrote:
I was curious whether anyone managed to get the Steam Controller working as an input device in openSUSE?
The latest SteamOS update allows the controller to control the mouse in desktop mode. I can picture using it as a slideshow controller if it is able to directly function as a mouse as well.
Hello. I use the program called AntiMicro (https://build.opensuse.org/package/show?project=hardware&package=AntiMicro) to use Sony DualShock 3 as remote control. Pretty sure it should work with anything as long as it has a kernel driver. I have it in my SUSE build (https://github.com/v-fox/live_opensuse_hsf) but I didn't make the TW-based 0.9.0 release yet. Was planning today but found an issue with networking.
Very neat! Looks like a Steam Controller setting issue though. I was a bit premature in asking for mailing list input. Steam has to be running for the controller to be detected by the desktop. https://github.com/ValveSoftware/steam-for-linux/issues/4083#issuecomment-15... Previously, I was hoping it would just work out of the box. I presume your Sony controller doesn't need an actual game running to be usable.
On 28.12.2015 09:33, Chan Ju Ping wrote:
Very neat! Looks like a Steam Controller setting issue though. I was a bit premature in asking for mailing list input.
Steam has to be running for the controller to be detected by the desktop.
https://github.com/ValveSoftware/steam-for-linux/issues/4083#issuecomment-15...
Previously, I was hoping it would just work out of the box. I presume your Sony controller doesn't need an actual game running to be usable.
Ha ! I actually implemented uinput auto-loading and permission setup (https://github.com/v-fox/live_opensuse_hsf/blob/master/source/root/etc/udev/...) for my build without even having Steam Controller in mind but because AntiMicro author said that uinput is the future. Can't guarantee that it's all that needed though. DS3 has its own issues, mainly it requires special bluez plugin for its ass-backwards (literally) pairing _which openSUSE officials refuse to package for no reason_ (but guess who does ;) ! Also, many games and input subsystems lose their shit then they see that every button has an axis (for pressure) along to its boolean state. My point is that I trying to make sure that gaming works out of the box in my builds (along with other multimedia activities) because officials have troubles with everything that is not centered around servers and workstations. For example, I've made some more crutches for steam-launching script (https://github.com/v-fox/live_opensuse_hsf/blob/273fcda4e9dbd4a1f9bbc0c1e4cb...) that started to fail recently on openSUSE.
Am 28.12.2015 um 07:47 schrieb Sergey Kondakov:
DS3 has its own issues, mainly it requires special bluez plugin for its ass-backwards (literally) pairing _which openSUSE officials refuse to package for no reason_
That's a bold statement to make given that I as the "official bluez maintainer" of openSUSE (well, as official as it gets in such a doocraty :-) have never heard of any request to package such a plugin. Besides: everyone can become maintainer of packages, so you could just step up and package it. (It is of course entirely possible that it has an incompatible license or such, but then the "for no reason" above is again a bold statement) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 28.12.2015 13:25, Stefan Seyfried wrote:
That's a bold statement to make given that I as the "official bluez maintainer" of openSUSE (well, as official as it gets in such a doocraty :-) have never heard of any request to package such a plugin.
Besides: everyone can become maintainer of packages, so you could just step up and package it.
(It is of course entirely possible that it has an incompatible license or such, but then the "for no reason" above is again a bold statement)
Well, technically, you're right. I was too lazy to make proper OBS request or even to complain in bugzilla. There are quite a lot of instances of that. With bluez I figured that if the people making the package did see what their package's configure script has to offer and didn't enable something like this then they have some kind of strong irrational opposition to it, which sometimes happen and, weirdly, DS support never gets love it deserves anywhere. The more weird part of DS situation is that bluez creators themselves disabled it by default and didn't want to accept ready patches for it from the beginning. Instead they seem to have reimplemented them without noticeable difference, even with the same shortcomings. To enable it you need to pass '--enable-sixaxis' configure option and add <libdir>/bluetooth/plugins/sixaxis.so file. Everyone can become a maintainer. But something as critical as the free Bluetooth implementation really should get attention from all the important-looking people. But then again, we're talking about the "product" where GRUB may suddenly fail to chainload (meaning, everything other than Linux fails) because of bad official patches (starting from 44:efidisk-move-device-path-helpers-in-core-for-efinet)... I should not forget to raise a stink about that where it's appropriate -_- I also should make a request for blueman-2.0.3, the only non-DE-locked bluez GUI... someday.
Hi Sergey, Am 28.12.2015 um 12:01 schrieb Sergey Kondakov:
On 28.12.2015 13:25, Stefan Seyfried wrote:
That's a bold statement to make given that I as the "official bluez maintainer" of openSUSE (well, as official as it gets in such a doocraty :-) have never heard of any request to package such a plugin.
Besides: everyone can become maintainer of packages, so you could just step up and package it.
(It is of course entirely possible that it has an incompatible license or such, but then the "for no reason" above is again a bold statement)
Well, technically, you're right. I was too lazy to make proper OBS request or even to complain in bugzilla. There are quite a lot of instances of that. With bluez I figured that if the people making the package did see what their package's configure script has to offer and didn't enable something like this then they have some kind of strong irrational opposition to it,
No, but I certainly won't enable stuff that upstream disabled by default *and where I don't have hardware to even test*. Because if something does not work, I'm going to get the bug reports.
which sometimes happen and, weirdly, DS support never gets love it deserves anywhere. The more weird part of DS situation is that bluez creators themselves disabled it by default and didn't want to accept ready patches for it from the beginning. Instead they seem to have reimplemented them without noticeable difference, even with the same shortcomings.
To enable it you need to pass '--enable-sixaxis' configure option and add <libdir>/bluetooth/plugins/sixaxis.so file.
Ah ok. I thought it was just an addon package that just needed to be built in addition to main bluez package. Feel free to send a submitrequest against Base:System/bluez adding the enable switch. If I know that there are users and testers, I'm certainly not against enabling stuff.
Everyone can become a maintainer. But something as critical as the free Bluetooth implementation really should get attention from all the important-looking people. But then again, we're talking about the "product" where GRUB may suddenly fail to chainload (meaning, everything other than Linux fails) because of bad official patches (starting from 44:efidisk-move-device-path-helpers-in-core-for-efinet)... I should not forget to raise a stink about that where it's appropriate
Well yes, but not in this thread :-)
-_- I also should make a request for blueman-2.0.3, the only non-DE-locked bluez GUI... someday.
Well, that would be nice. I'm personally just using bluetoothctl but that's certainly not for everyone :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
Chan Ju Ping -
Sergey Kondakov -
Stefan Seyfried