[Feature Request] Steam Deck Support?

[ChrisRevocateur]

Any plans on adding a layout for the new Steam Deck inputs?

[kozec]

I'd like to, but it will take few months before I can even think about buying one from here.

[pattontim]

Most likely I will receive my deck in May-June. I'm not as experienced as the other devs here so I can test some stuff plus maybe write some code.

[ChrisRevocateur]

Just glad to hear it's on the radar.

[yoshimo]

Would you also look into pushing support for the kernel driver?
hid-steam was being worked on in 2018

[tjhorner]

Hello, Steam Deck owner here! Got mine last Friday.

The Steam Deck inputs are connected internally via USB, similar to how a wired Steam Controller works. Its vid:pid is 28de:1205, and even reports itself as "Valve Software Steam Controller".

@Jack-Sibley was doing some reverse engineering of the HID reports that it sends and at least got the gyro to work. It seems pretty similar to how the Steam Controller sends reports, so hopefully only the modifications that need to be made are minor.

I am not familiar with how this project actually obtains a handle for the USB HID, but according to Jack, Steam gets upset when other apps try to access it. As a sort of workaround we were using usbmon to get the raw HID events directly from the kernel (at /dev/usbmonX).

Anyway, my point is that it's basically a necessity for this to work while Steam is open and actively using the controller, otherwise games launched from the Deck's UI wouldn't be able to utilize this. (There are cases where you would want to use SC Controller instead of the native Steam Input bindings, for e.g. cemuhook. I detailed it more here)

@kozec If there is anything I can do to help out, by providing USB pcaps or otherwise, let me know! Would love to see this work with Steam Deck.

[offalynne]

@tjhorner does UINPUT do anything with it if Steam isn't running ? Does it show up as a DirectInput gamepad device when Windows is installed ?

[Jack-Sibley]

@offalynne I'm afraid not, without steam it's just a raw hid device.

[pattontim]

The official steam client now has support for Steam Deck trackpad typing. The keyboard works more similar to sc-controller where the input is stretched horizontally rather than completely square like with the SC via Steam
Here is my rendition of the input area and how it maps to the square trackpads on Steam with the Steam Deck.

This is the default keyboard in Steam with SC

[yoshimo]

Would a non-developer be able to supply any useful info from the deck to give the development for a driver a head start?

[pattontim]

An unofficial mod for adding plugins to the steam deck menu. If devs do make it work alongside steam, may consider a tool which can modify config.py integrated with steam

https://github.com/SteamDeckHomebrew/PluginLoader

example, calculator app:
https://github.com/SpyrexDE/SDH-Calculator

[cyrozap]

I got my Steam Deck yesterday, but it seemed that no one else had reverse engineered the HID data layout yet, so I decided to give it a try today. Here's what I have so far:

Digital inputs

A bit set in these locations indicates the following:

• 0x08, bit 0: Right trigger (virtual) button pressed
• 0x08, bit 1: Left trigger (virtual) button pressed
• 0x08, bit 2: Right bumper pressed
• 0x08, bit 3: Left bumper pressed
• 0x08, bit 4: "Y" button pressed
• 0x08, bit 5: "B" button pressed
• 0x08, bit 6: "X" button pressed
• 0x08, bit 7: "A" button pressed
• 0x09, bit 0: D-pad UP pressed
• 0x09, bit 1: D-pad RIGHT pressed
• 0x09, bit 2: D-pad LEFT pressed
• 0x09, bit 3: D-pad DOWN pressed
• 0x09, bit 4: "View" button (two rectangles, above left thumbstick) pressed
• 0x09, bit 5: "STEAM" button pressed
• 0x09, bit 6: "Options" ("≡", above right thumbstick) button pressed
• 0x09, bit 7: L5 pressed
• 0x0A, bit 0: R5 pressed
• 0x0A, bit 1: Left trackpad pressed (not possible for a "press" to be detected without the pad being touched--i.e., bit 3 also being set)
• 0x0A, bit 2: Right trackpad pressed (not possible for a "press" to be detected without the pad being touched--i.e., bit 4 also being set)
• 0x0A, bit 3: Left trackpad touched
• 0x0A, bit 4: Right trackpad touched
• 0x0A, bit 6: Left thumbstick pressed
• 0x0B, bit 2: Right thumbstick pressed
• 0x0D, bit 1: L4 pressed
• 0x0D, bit 2: R4 pressed
• 0x0D, bit 6: Left thumbstick capacitive pad touched
• 0x0D, bit 7: Right thumbstick capacitive pad touched
• 0x0E, bit 2: "Quick access" ("...") button pressed

Analog inputs

Notes

• All fields are 16-bit, signed, little-endian integers unless otherwise noted.
• Accelerometer axes are treated as follows:
  • With the screen as the "front" of the console, and the exhaust vent as the "top" of the console, and the screen facing the user:
    • Moving the console ventward will result in a positive acceleration in the X-direction.
    • Moving the console left will result in a positive acceleration in the Y-direction.
    • Moving the console toward the user will result in a positive acceleration in the Z-direction.
  • Basically, it's the right-hand rule. With the thumb pointing up and the index finger pointing forward:
    • Thumb is positive-Z.
    • Index finger is positive-X.
    • Middle finger is positive-Y.
• Gyroscope axes are treated as follows:
  • Pitch axis points out the right side of the console.
  • Yaw axis points out the exhaust vent side of the console.
  • Roll axis points out the screen side of the console.

Fields

• 0x10: Left trackpad X-axis, positive == East, negative == West
• 0x12: Left trackpad Y-axis, positive == North, negative == South
• 0x14: Right trackpad X-axis, positive == East, negative == West
• 0x16: Right trackpad Y-axis, positive == North, negative == South
• 0x18: Accelerometer X-axis
• 0x1A: Accelerometer Y-axis
• 0x1C: Accelerometer Z-axis
• 0x1E: Gyroscope pitch
• 0x20: Gyroscope yaw
• 0x22: Gyroscope roll
• 0x24: Q1?
• 0x26: Q2?
• 0x28: Q3?
• 0x2A: Q4?
• 0x2C: Left analog trigger pressure (never goes negative--bit 15 always zero), higher value == higher pressure
• 0x2E: Right analog trigger pressure (never goes negative--bit 15 always zero), higher value == higher pressure
• 0x30: Left thumbstick X-axis, positive == East, negative == West
• 0x32: Left thumbstick Y-axis, positive == North, negative == South
• 0x34: Right thumbstick X-axis, positive == East, negative == West
• 0x36: Right thumbstick Y-axis, positive == North, negative == South
• 0x38: Left trackpad pressure (never goes negative--bit 15 always zero), higher value == higher pressure
• 0x3A: Right trackpad pressure (never goes negative--bit 15 always zero), higher value == higher pressure
• 0x3C: ?
• 0x3E: ?

@kozec, does this help?

[tjhorner]

@cyrozap I believe 0x20 is yaw and 0x22 is roll

[cyrozap]

Here's the USB descriptor, in case anyone needs it:

Bus 003 Device 002: ID 28de:1205 Valve Software Steam Controller
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x28de Valve Software
  idProduct          0x1205 
  bcdDevice            1.00
  iManufacturer           1 Valve Software
  iProduct                2 Steam Controller
  iSerial                 3 123456789ABCDEF
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x005b
    bNumInterfaces          3
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 
      bInterfaceProtocol      2 Mouse
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode           33 US
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      50
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      1 Keyboard
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode           33 US
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      39
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode           33 US
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      53
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
Device Status:     0x0000
  (Bus Powered)

[cyrozap]

@tjhorner I did some more testing today, and you're correct--I didn't follow the right-hand rule when labeling the accelerometer and gyroscope axes, so I had X/Y and roll/yaw swapped. I've updated my earlier comment to reflect these changes, as well as to describe the gyroscope axes (since they're different from the accelerometer axes).

All this has really started to confuse me, so I'm tempted to mock up a diagram illustrating how the six axes are positioned relative to the controller and how they relate to the values in the HID report.

[cyrozap]

Behold--my extremely professional diagrams:

Axis names and positive directions correspond to the ones in my earlier post.

[mKenfenheuer]

@cyrozap have you had any other progress so far?
I might want to give implementing it a shot.

[Patola]

Just for the record, if it needs testing I also got a Steam Deck. I wonder if it would be easy to make a flatpak out of it, because that's the standard way to install stuff on the device.

[pattontim]

Is it possible to buy the left and right daughterboards and plug in touchpads and plug that into a generic system?

https://www.ifixit.com/Guide/Steam+Deck+Left+Button+Board+Replacement/148931

I think they refer to the cord which plugs into the mobo as a ZIF connector. Having an isolated board could help for development

[mKenfenheuer]

@Patola i think that should be possible, but first up is getting it to work ;)
@pattontim could be, but i dont know how to get the data out of it.

Right now im looking at the raw data output of the device. Here is what i've got so far:

https://github.com/mKenfenheuer/sc-controller/blob/v0.4.9.12-steamdeck-raw-data/steam_deck_dump/raw_data.md

If you can provide some data, please feel free. Binaries for windows are available here

[tjhorner]

Someone published source which utilizes gyro data on GitHub, but I couldn't get it working https://github.com/kmicki/SteamDeckGyroDSU

[cyrozap]

@mKenfenheuer I haven't done any more reverse engineering work on this after I figured out the gyroscope stuff, and haven't started adding support to SC-Controller either, so feel free to start on a driver. You might want to use the field definitions I posted earlier so you don't have to reverse engineer the protocol/report format from scratch. I think the only reverse engineering work that remains to be done is to find the commands that enable the gyroscope, switch the device out of lizard mode, etc.

@pattontim Rather than physically connecting the Deck's controller to a PC, I've been using USB/IP to present the controller's USB device as a virtual USB device on my laptop over the network. That way, I can do any reverse engineering and development work from the comfort of my laptop instead of directly on the Deck.

[mKenfenheuer]

@cyrozap i see, out of what ive got so far i think we are getting the same data format. Is your payload 64bytes too?

[cyrozap]

Yes, it's 64 bytes.

[mKenfenheuer]

So, good news: i've got the sticks, triggers and most of the buttons working (although they are wrongly mapped).
Bad news: the steam deck controller does not stop sending mouse and keyboard inputs.

Does anyone know using which HID Report we can disable that?

[mKenfenheuer]

Got it, hid request with first byte set to 0x81 disables the mouse and keyboard input temporarily. Needs to be repeated about every 1-2 secs to keep it that way.

Once i got all sticks, trackpads etc mapped i will publish another build.

[mKenfenheuer]

I couldnt get the mapping to work correctly here, so i decided to rewrite a separate driver specific for the steam deck.
See https://github.com/mKenfenheuer/steam-deck-windows-usermode-driver - it's windows only for now.

My attempt at implementing it with c is pushed to https://github.com/mKenfenheuer/sc-controller.

Regarding Lizard mode here is a short snippet on how to enable/disable it:

bool sdc_set_lizard_mode(bool enabled)
{
	if (!enabled)
	{

		//Disable mouse emulation
		uint8_t data[64] = { 0x87, 0x03, 0x08, 0x07 };

		if (hid_request(data, -64) == NULL) {
			return false;
		}



		//Disable keyboard/mouse button emulation
		uint8_t data2[64] = { 0x81, 0x00 };

		if (hid_request(data2, -64) == NULL) {
			return false;
		}
	}
	else 
	{
		//Enable keyboard/mouse button emulation
		uint8_t data[64] = { 0x85, 0x00 };

		if (hid_request(data, -64) == NULL) {
			return false;
		}

		//Enable mouse emulation
		data[0] = 0x8e;

		if (hid_request(data, -64) == NULL) {
			return false;
		}
	}
	return true;
}

[pattontim]

Progress. Using the above linked c project and a few edits I can type using both the trackpads. However non kb inputs are doubled

On the other hand, building the c branch GUI for windows is very hard because the python2 library is no longer offered. The py3 version doesn't build for windows AFAIK.

I'm going to reference steam-deck-windows-usermode-driver to add the correct SD timers and inputs and then perhaps try to backport the drivers to the py3 version

[Ryochan7]

You will likely have to use the HID Hide driver, at some point, to hide the Steam Deck HID device from Steam. I have to use that driver when using my own mapper for the Steam Controller.

https://vigem.org/projects/HidHide/

[kozec]

To answer original question, I've just merged basic support for Steam Deck both to master and c branch.

There are two-and-half remaining issues with it:

• support for gyro is not yet implemented, althought it seems like it uses same fields / values as SC does
• it works on regular Linux booted on Deck. It should run on SteamOS as well, but I have yet to find way how to run anything with dependencies there. Plus, I'm not entirelly sure whether such use case is even relevant.
• support in 'c' version is not yet tested on Windows

[pattontim]

Good work, I pushed some edits which allows it to partially build and run on windows, at least the OSD builds and runs and I can type. May simplify build process by removing GUI and its deps, just kbm to deal with gi not being distributed

https://github.com/pattontim/sc-controller-kbm/tree/origin/windows-osd-only

[parkerlreed]

Not compiling on latest master seemingly due to the Deck commit

(deck@steamdeck sc-controller)$ ./run.sh 
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/ctypes/__init__.py", line 366, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: ./libuinput.so: cannot open shared object file: No such file or directory
libuinput.so is outdated or missing, building one
Please wait, this should be done only once.

running build
running build_py
running build_ext
building 'libuinput' extension
gcc -pthread -fno-strict-aliasing -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DNDEBUG -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fPIC -I/usr/include/python2.7 -c scc/uinput.c -o build/temp.linux-x86_64-2.7/scc/uinput.o
gcc -pthread -shared -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now build/temp.linux-x86_64-2.7/scc/uinput.o -L/usr/lib -lpython2.7 -o build/lib.linux-x86_64-2.7/libuinput.so
building 'libcemuhook' extension
gcc -pthread -fno-strict-aliasing -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DNDEBUG -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fPIC -DPYTHON=1 -I/usr/include/python2.7 -c scc/cemuhook_server.c -o build/temp.linux-x86_64-2.7/scc/cemuhook_server.o
gcc -pthread -shared -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now build/temp.linux-x86_64-2.7/scc/cemuhook_server.o -L/usr/lib -lz -lpython2.7 -o build/lib.linux-x86_64-2.7/libcemuhook.so
building 'libhiddrv' extension
creating build/temp.linux-x86_64-2.7/scc/drivers
gcc -pthread -fno-strict-aliasing -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DNDEBUG -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fPIC -I/usr/include/python2.7 -c scc/drivers/hiddrv.c -o build/temp.linux-x86_64-2.7/scc/drivers/hiddrv.o
gcc -pthread -shared -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now build/temp.linux-x86_64-2.7/scc/drivers/hiddrv.o -L/usr/lib -lpython2.7 -o build/lib.linux-x86_64-2.7/libhiddrv.so
building 'libsc_by_bt' extension
gcc -pthread -fno-strict-aliasing -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DNDEBUG -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fPIC -I/usr/include/python2.7 -c scc/drivers/sc_by_bt.c -o build/temp.linux-x86_64-2.7/scc/drivers/sc_by_bt.o
gcc -pthread -shared -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now build/temp.linux-x86_64-2.7/scc/drivers/sc_by_bt.o -L/usr/lib -lpython2.7 -o build/lib.linux-x86_64-2.7/libsc_by_bt.so
building 'libremotepad' extension
gcc -pthread -fno-strict-aliasing -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DNDEBUG -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fPIC -I/usr/include/python2.7 -c scc/drivers/remotepad_controller.c -o build/temp.linux-x86_64-2.7/scc/drivers/remotepad_controller.o
In file included from scc/drivers/remotepad.h:8,
                 from scc/drivers/remotepad_controller.c:12:
scc/drivers/scc_future.h:69:41: error: field ‘gyro’ has incomplete type
   69 |         struct GyroInput                gyro;
      |                                         ^~~~
scc/drivers/remotepad_controller.c: In function ‘libretro_button_to_sc_button’:
scc/drivers/remotepad_controller.c:31:64: error: ‘B_RPAD’ undeclared (first use in this function)
   31 |         case RETRO_DEVICE_ID_JOYPAD_R3:                 return B_RPAD;
      |                                                                ^~~~~~
scc/drivers/remotepad_controller.c:31:64: note: each undeclared identifier is reported only once for each function it appears in
error: command 'gcc' failed with exit status 1

[blueapple128]

This pull request is what I used to fix the above build errors.

[blueapple128]

It should run on SteamOS as well, but I have yet to find way how to run anything with dependencies there. Plus, I'm not entirely sure whether such use case is even relevant.

For the record, this is my use case (I'm trying to use the Deck's SteamOS without Steam, by bypassing the initial welcome screen without an internet connection). I got it to build and install after manually wrangling with pacman and a truckload of Python2 dependencies.

[kozec]

I've set up pre-release with appimage of current git master attached here.

It may need SteamOS updated to very last version, but I'm still trying to figure out how to verify that theory.

[WildRikku]

I just stumbled upon this while trying to figure out how I could access the gyro from the unlocked SteamOS on my Deck to code an auto screen rotate script. I was confused that the Plasma settings show the Steam Deck as a gamepad with all the controls - except the gyro. Looks like sc-controller could be useful for me if it supported the Deck. Let me know if I can do something to support, I have a Steam Deck with an unlocked OS and do not fear to hack it, also I do usually code C# or PHP but I am not scared to look at C or Python.

[parkerlreed]

@WildRikku you should be able to download that AppImage that is mentioned and try running it.

[Dark3clipse]

Is there already support for the capacitive touch input of the two joysticks? I can't find how to map those yet. Also, is it possible to use both trackpads for typing on linux? (Not steamos)

[Konzertheld]

@WildRikku you should be able to download that AppImage that is mentioned and try running it.

I did so. The aforementioned pre-release v0.4.8.9 AppImage runs out of the box on my Steam Deck (SteamOS 3.4.4). It seems to work quite well. The gyro behaviour seems to be odd, though I don't know about calibration, so not sure if that's an issue in sc controller. I used the 6-way action assignment ("Tilt") and often triggered two actions of different axes at the same time, also apparently I always trigger the same direction for each of the three axes. Pretty close to what I was looking for though, so sc controller probably will be of help for me in the future. :)

I also somehow could not assign an action to pressing the right stick.

Traceback (most recent call last):
  File "/tmp/.mount_sc-conjGgrTN/usr/lib/python2.7/site-packages/scc/gui/action_editor.py", line 489, in on_btOK_clicked
    self.ac_callback(self.id, a)
  File "/tmp/.mount_sc-conjGgrTN/usr/lib/python2.7/site-packages/scc/gui/app.py", line 774, in on_action_chosen
    before = self.set_action(self.current, id, action)
  File "/tmp/.mount_sc-conjGgrTN/usr/lib/python2.7/site-packages/scc/gui/binding_editor.py", line 90, in set_action
    self.button_widgets[id].update()
KeyError: <SCButtons.RSTICKPRESS: 2147483648>

If you want me to report other things I encounter in new issues instead of here, let me know. Also if you want to have something specific tested feel free to ask. I'd be glad to help out.

Edit: Sorry, me and WildRikku is the same person, I forgot to change my account.

[DanielHerr]

Looks like Valve is adding the Deck controls to the hid-steam Linux driver.

https://www.phoronix.com/news/Steam-HID-Steam-Deck-Linux-6.3
ColinIanKing/linux-next@9ba9498

[Dark3clipse]

My steam deck analog sticks, dpad, triggers, 3 dots button, and left touchpad stopped working when updating my sd. I'm using sc-controller-git from AUR. I've tried out opensd and there it seems to be working. Could it be an issue with sc-controller in combination with newer kernels?

#uname -a
Linux deck 6.2.15-zen-00690-g09c4ace4dddd #1 ZEN SMP PREEMPT_DYNAMIC Fri Jun 30 13:25:21 CEST 2023 x86_64 GNU/Linux

[bluelightzero]

Sorry if this is off topic.

When on the Steam Deck, if you touch the joysticks (The capacitive parts) it disables the trackpad on that side.
This seems to be system wide, even in the input tester in settings.

What I want to know is: Is this a hardware limitation or is this restriction done entirely in software?
Is Steam OS doing something to filter out the trackpad input?

[mKenfenheuer]

Hi, Message ID: ***@***.***> as far as i can remember, thats done entirely in Software. However i cannot think of a way to disable it. Why would you try to disable it? I had a lot of unwanted inputs due to accidentally touching the trackpads while developing.

[bluelightzero]

Hi, Message ID: @.***> as far as i can remember, thats done entirely in Software. However i cannot think of a way to disable it. Why would you try to disable it? I had a lot of unwanted inputs due to accidentally touching the trackpads while developing.

I wanted to develop a game to use the deck as a split 2 player controller. With a trackpad and joystick for each player.
It's surprisingly comfortable to hold like this, but is completely impossible because it filters the touchpad input.

[polyzium]

Hello, it's been around half a year since this issue has been discussed. Recently got a Steam Deck OLED and I would like to see this software have Deck support implemented, especially with how lackluster the Steam onscreen keyboard actually is.

[Patola]

Steam Deck support is already working. Use the appimage (on releases) or compile it yourself and you'll see it recognizing the steam deck controls. It works so well that when I used some USB redirector (VirtualHere) on my Arch Linux to use my deck as a controller on my PC, and it did!