Hardware support syntax is unintuitive

[bertob]

The current way to specify hardware support is not very intuitive from an app developer PoV. As an app dev I know what kinds of controls and screen sizes I've tested and work, which ones I've tested and don't work, and which ones I haven't tested.

The current syntax uses recommends and requires. The latter makes sense to me as-is, but recommends is basically used to mean tested and works. There's no concept of tested and doesn't work or not tested.

I wonder if we could rename recommends to verified or something similar and have an additional group called unsupported for things we know don't work (e.g. if I know the app currently isn't keyboard accessible). Anything not included would then automatically count towards not tested, so all groups would be covered.

Whether or not apps should/could additionally recommend an ideal setup (e.g. Blender could recommend a mouse and keyboard with numpad) even though the app is usable with different setups is a separate question, but I think that's a much more niche use case than defining what hardware the developer knows works/doesn't work.

cc @Exalm

[ximion]

Just keep in mind, recommends/requires is not just about hardware support - you can require/recommend just about anything, including other software components. So we will 100% not rename anything (especially not because that would break the world by now, this feature is used quite a lot).

At the moment, you could mark an application as not supporting keyboard input via something like this:

<recommends>
  <control>pointing</control>
  <control>touch</control>
</recommends>

If some input control isn't in a recommends block, it's not supported. A recommendation in AppStream basically means "you should have this stuff, but the application will still be installable if the requirements aren't met (possibly with a warning). While a requirement means that you can't even install the app without the prerequisite being fulfilled.

So, for an app that is keyboard-accessible but doesn't support touch, that needs at least 1GB of RAM but ideally 2GB, requires a Linux kernel 4.14 or greater to work and that requires a display size of at least 600 logical pixels but the display shouldn't be larger than 2000px (but could be), you would have this metadata:

<requires>
   <display_length>600</display_length>
   <memory>1024</memory>
   <kernel version="4.14" compare="ge">Linux</kernel>
</requires>
<recommends>
  <control>pointing</control>
  <control>keyboard</control>

  <display_length compare="lt">2000</display_length>
  <memory>2048</memory>
</recommends>

It is admittedly a bit odd to have "recommended input controls" basically mean "supported input controls", for example if voice input is "recommended" it may not mean that this is actually the recommended form of input, but simply that the software supports this. Same for modalias recommendations: It may not be the case that the hardware is recommended, it may just be that it is supported and may or may not be available.
To make this clearer, we could either open up AppStream's suggests block for controls/modaliases etc., so apps can logically suggest certain stuff to be there. Or add a new supported tag, which I am not totally against, but which would mean yet another tag that software centers need to pay attention to, making the whole specification that much more complicated: Having requires/recommends/suggests/extends/supported as relations is quite a lot to pay attention to.
I am slightly against adding negative relations, like "not required", "not suggested" etc. - that may get out of hand, I'd rather like to see the metadata describe what the software can do that having a huge table of the things that have been tested and that don't work (if a certain spec doesn't work, requirements should simply be modified accordingly). Especially in the light that AppStream will soon contain a per-release block of hardware testing results (that's primarily useful for components that are very close to the hardware though, like firmware components handled by fwupd).