Here is a patch to add Appstream metainfo XML announcing the hardware
handled by this package.

Including this information in the package will ensure programs mapping
hardware to packages using Appstream information, like the isenkram
package, will know that this package is useful on machines where the
hardware is discovered.

The appstream metadata file can be checked using this command after
package build:

  appstreamcli validate-tree  --no-net --explain debian/mkgmap

diff --git a/debian/patches/1000-appstream-metainfo.patch b/debian/patches/1000-appstream-metainfo.patch
new file mode 100644
index 0000000..960abf2
--- /dev/null
+++ b/debian/patches/1000-appstream-metainfo.patch
@@ -0,0 +1,74 @@
+Description: List supported hardware in Appstream metadata provide block.
+ This ensure those with the relevant hardware presend on their
+ machine can get a proposal to install the steam installer.
+
+ The list of USB ids are extracted from the udev rules included in the
+ package.
+Author: Petter Reinholdtsen
+Forwarded: no
+Last-Update: 2024-08-15
+---
+Index: steam-installer-salsa/com.valvesoftware.Steam.metainfo.xml
+===================================================================
+--- steam-installer-salsa.orig/com.valvesoftware.Steam.metainfo.xml    2024-08-15 14:15:26.614876942 +0200
++++ steam-installer-salsa/com.valvesoftware.Steam.metainfo.xml 2024-08-15 14:23:04.379678720 +0200
+@@ -51,4 +51,59 @@
+     <release version="1.0.0.71" date="2021-07-23"/>
+     <release version="1.0.0.70" date="2021-04-07"/>
+   </releases>
++  <provides>
++    <modalias>usb:v044FpD00Ed*</modalias>
++    <modalias>usb:v054Cp0268d*</modalias>
++    <modalias>usb:v054Cp05C4d*</modalias>
++    <modalias>usb:v054Cp05C5d*</modalias>
++    <modalias>usb:v054Cp09CCd*</modalias>
++    <modalias>usb:v054Cp0BA0d*</modalias>
++    <modalias>usb:v054Cp0CE6d*</modalias>
++    <modalias>usb:v057Ep2009d*</modalias>
++    <modalias>usb:v0738p8250d*</modalias>
++    <modalias>usb:v0738p8384d*</modalias>
++    <modalias>usb:v0BB4p0306d*</modalias>
++    <modalias>usb:v0BB4p0309d*</modalias>
++    <modalias>usb:v0BB4p030Ad*</modalias>
++    <modalias>usb:v0BB4p030Bd*</modalias>
++    <modalias>usb:v0BB4p030Cd*</modalias>
++    <modalias>usb:v0BB4p030Ed*</modalias>
++    <modalias>usb:v0BB4p2C87d*</modalias>
++    <modalias>usb:v0C12p0C30d*</modalias>
++    <modalias>usb:v0C12p0E10d*</modalias>
++    <modalias>usb:v0C12p0EF6d*</modalias>
++    <modalias>usb:v0C12p1CF6d*</modalias>
++    <modalias>usb:v0E6Fp0180d*</modalias>
++    <modalias>usb:v0E6Fp0185d*</modalias>
++    <modalias>usb:v0E6Fp0188d*</modalias>
++    <modalias>usb:v0F0Dp0055d*</modalias>
++    <modalias>usb:v0F0Dp0066d*</modalias>
++    <modalias>usb:v0F0Dp008Ad*</modalias>
++    <modalias>usb:v0F0Dp00C1d*</modalias>
++    <modalias>usb:v0F0Dp00EEd*</modalias>
++    <modalias>usb:v114Dp8A12d*</modalias>
++    <modalias>usb:v146Bp0D01d*</modalias>
++    <modalias>usb:v1532p0401d*</modalias>
++    <modalias>usb:v1532p1000d*</modalias>
++    <modalias>usb:v1532p1004d*</modalias>
++    <modalias>usb:v1532p1007d*</modalias>
++    <modalias>usb:v1532p1008d*</modalias>
++    <modalias>usb:v20D6pA711d*</modalias>
++    <modalias>usb:v20D6pA713d*</modalias>
++    <modalias>usb:v28DEp1043d*</modalias>
++    <modalias>usb:v28DEp1142d*</modalias>
++    <modalias>usb:v28DEp2000d*</modalias>
++    <modalias>usb:v28DEp2010d*</modalias>
++    <modalias>usb:v28DEp2011d*</modalias>
++    <modalias>usb:v28DEp2012d*</modalias>
++    <modalias>usb:v28DEp2021d*</modalias>
++    <modalias>usb:v28DEp2022d*</modalias>
++    <modalias>usb:v28DEp2050d*</modalias>
++    <modalias>usb:v28DEp2101d*</modalias>
++    <modalias>usb:v28DEp2102d*</modalias>
++    <modalias>usb:v28DEp2150d*</modalias>
++    <modalias>usb:v28DEp2300d*</modalias>
++    <modalias>usb:v28DEp2301d*</modalias>
++    <modalias>usb:v9886p0025d*</modalias>
++  </provides>
+ </component>
diff --git a/debian/patches/series b/debian/patches/series
index 5a4a508..c032624 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 metainfo-Include-Debian-specific-advice.patch
+1000-appstream-metainfo.patch

Control: tags -1 = wontfix

I don't think this is appropriate in this case. steam-devices sets up udev
rules so that ordinary users can create emulated input devices and get
"raw HID" access to game controllers, each of which is needed by some
Steam features - but that does reduce the extent to which users of a
multi-user system are protected from each other, so I think it would be
inappropriate to suggest it for installation just because (for example)
a Playstation 4 controller happens to have been detected.

Also, steam-devices doesn't have Appstream metadata of its own (the fact
that it's separated from Steam at all is a Debianism). The Appstream
metadata for which you proposed a patch is for (an installer for) the
Steam client itself (the installer is contrib, the client itself is very
much non-free), and as much as I enjoy being able to play games via Steam,
I don't think it's an appropriate thing to be suggesting for installation
just because some gaming hardware is present.

    smcv

[Simon McVittie]
USB device in
/usr/share/metainfo/com.steampowered.steam-devices.metainfo.xml, at
least:

  <provides>
    <modalias>usb:v1130p0202d*</modalias>
  </provides>

My edition of /usr/share/misc/usb.ids do not list this ID:

1130  Tenx Technology, Inc.
        0001  BlyncLight
        0002  iBuddy
        0004  iBuddy Twins
        0202  Rocket Launcher
        6604  MCE IR-Receiver
        6606  U+P Mouse
        660c  Foot Pedal/Thermometer
        6626  Key
        6806  Keychain photo frame
        c301  Digital Photo viewer [Wallet Pix]
        f211  TP6911 Audio Headset

ID 0202 is not listed on <URL: https://usb-ids.gowdy.us/read/UD/1130 >
either, so I am not quite sure which device this is.  It is not
mentioned in /usr/lib/udev/rules.d/60-steam-input.rules or
/usr/lib/udev/rules.d/60-steam-vr.rules either.

Anyway, it is up to you and upstream if they want to announce supported
hardware using Appstream.

[Petter Reinholdtsen]

Sorry, my eyes are obviously blind:

As far as I can tell, this is the device supported by pymissile, which I
doubt is supported by steam.  Not quite sure where things went wrong
here.  I suspect a cut-n-paste error on my part somewhere.

<provides> for a shorter, more-curated list of devices that don't
(usually) work unless Steam is installed - notably Valve's Steam
Controller gamepad, and possibly some of their VR hardware.

The Steam Controller usually only works as a game controller while Steam
is running and its Steam Input feature is active, so that one would be
appropriate to attach to Steam's metainfo rather than steam-devices.
(Third-party open-source user-space drivers also exist, but are not
in Debian, and I'm not sure whether they got beyond a prototype stage.)
However, because the Steam Controller is no longer manufactured, I'm not
sure how practically useful it would be to put effort into announcing
support for it.

I'm unsure about the status of the VR devices: maybe they're similar,
but I'd want that information to come from someone who has access to them
and uses them.

This more-curated list certainly shouldn't include ordinary Xbox- and
Playstation-compatible gamepads, because in general those work
fine without Steam (games can't normally get raw HID access without
steam-devices, but even in the absence of that access, they're available
as evdev gamepads with a few standardized or de-facto-standard mappings).

Another thing that could potentially be appropriate would be to add
<supports> for the supported game controllers or some reasonable subset of
them, but I'm not sure what that information would be practically useful
for, and I think we shouldn't add it just for the sake of adding it.

    smcv

[Simon McVittie]

As long as such devices are available in the world for some Debian users
to connect to her machine, it is practically useful.  For example, while
the device controlled by pymissile is no longer being manufactured, I
still got mine in working order.  I got lots of hardware no longer being
manufactured (like LEGO minestorms units), and love that isenkram can
propose the relevant Debian packages for them, when I plug them in

I see you've committed "Converted steam-devices AppStream info to
upstreamable patch." to the steam-installer git repo. I'm going to
revert this because, just like the current metainfo (#1079356), it
seems incorrect: Steam does not actually have any support for 1130:0202,
a desk toy that fires small plastic missiles under USB control.

steam-devices' main function is to relax the default access control on raw
HID device nodes for several game controller types (various generations of
Steam Controller, Xbox, Playstation and Nintendo controllers, plus their
more common third-party clones), in ways that are a security reduction
on multi-user systems, but are necessary if you want to pass through raw
HID access to Proton, Steam Input or similar frameworks. It's packaged
separately because it's also useful for some non-Steam components like
sc-controller[1] or maybe Wine, but it's a security vs. functionality
trade-off, which as we've discussed previously, does not seem appropriate
to install automatically just because you plugged in a particular game
controller.

As Free Software advocates, I also think it would be inappropriate for
us to install Steam itself just because the user happens to plug in a
game controller while having non-free enabled. Obviously I wouldn't be
maintaining steam-installer if I didn't value the ability to install
Steam easily, but the decision to install it should be a decision,
not something that happens by mistake.

So I don't think it would be appropriate to add metainfo that says
either Steam or steam-devices <provides> those game controllers' device
IDs. The relevant device drivers variously live in the kernel (for
typical use-cases), or in SDL (for some optional lower-level access),
or in the proprietary part of Steam (for Steam Input's ability to make
a game controller emulate an Xbox 360 controller, a keyboard and/or a
mouse for compatibility with games that only support one of those).

If it would be useful for Steam to declare <supports> on particular
device IDs, we can discuss that, and I think that would likely be much
more appropriate than <provides>. But I don't think simply copying every
vendor/product pair from the udev rules would really be practically
useful, and I don't want to spend my limited upstream influence on trying
to upstream things that I cannot, personally, justify to them.

Thanks,
    smcv

[1] https://github.com/kozec/sc-controller, not currently in Debian

While I agree that 1130:0202 is a cut-n-paste error on my part, the
intention was to fetch the relevant IDs from the udev rules.  Among the
many BTS reports I have sent to try to get machine readable hardware
mappings into Debian, this one obvously included a mistake.  Sorry about
that.

I leave the decision on keeping or not keeping the hardware mapping in
your capable hands.  You know the package better than me.

I just want to note that at least some of your argument seem to revolve
around the idea that packages would be automatically installed based on
the mapping provided.  At least at the moment, this information is only
used by those installing isenkram to get a list of possible packages to
install.  It is up to the user if they want to install it or not.
Perhaps it will be more automatic in the future, perhaps also using
other tools, but at least today it is not.

As for the usefulness, I guess it both depend on the package and who
evaluate it.  I find it very useful to get information about packages
useful for my current set of hardware automatically, so I do not have to
sift through 50 000 packages to try to locate such packages manually.
Thanks to the hardware mapping in Isenkram, I discovered a tool to get
the battery status out of my wireless mouse the other day.  I would not
have discovered that this was possible without AppStream hardware
mappings and isenkram. :)