Add missing capabilities

[komret]

I miss some properties among the device capabilities when working on Suite, which leads to hard-coding device models accross the code base and worse maintainability. I would appreciate adding the following flags among device capabilities. @trezor/connect will handle backwards compatibility. The names are just my suggestions, the list might not be exhaustive.

Capability_SecureElement: device has a secure element and an ability to check device authenticity; hardcoded e.g. here
Capability_Tutorial: device has controls tutorials; hardcoded here
Capability_TouchScreen: device has a touchscreen as opposed to buttons, hardcoded e.g. here
Capability_DisplayRotation: device supports display rotation, hardcoded here

[matejcik]

Capability_SecureElement: device has a secure element and an ability to check device authenticity; hardcoded e.g. here
Capability_Tutorial: device has controls tutorials; hardcoded here

presumably all future devices will support these two. we could even do a tutorial for TT, fwiw :)

Capability_TouchScreen: device has a touchscreen as opposed to buttons, hardcoded e.g. here

this is not a capability and in this particular place it just might happen that T3W1 will need different string.
(i'm afraid this needs a per-model entry, where some texts happen to be identical. or, you know, you can switch on internal_model[2] where T is "touch" and B is "button" :)) )

Capability_DisplayRotation: device supports display rotation, hardcoded here

this is plausibly a capability

[komret]

Capability_SecureElement: device has a secure element and an ability to check device authenticity; hardcoded e.g. here
Capability_Tutorial: device has controls tutorials; hardcoded here

presumably all future devices will support these two. we could even do a tutorial for TT, fwiw :)

So in cases like this you're not adding a capability flag and we catch it in Suite? Acceptable.

Capability_TouchScreen: device has a touchscreen as opposed to buttons, hardcoded e.g. here

this is not a capability and in this particular place it just might happen that T3W1 will need different string. (i'm afraid this needs a per-model entry, where some texts happen to be identical. or, you know, you can switch on internal_model[2] where T is "touch" and B is "button" :)) )

Good idea.

[komret]

Are you sure TS5 has a tutorial? If it does, Suite skips it.

[matejcik]

Are you sure TS5 has a tutorial?

#3829
i assumed that it is already done, but it's not.
it is planned for the TS5 public release though

[komret]

😬 This complicates the condition needed in Suite. A flag for Capability_Tutorial would be helpful if a situation like this arises in the future.

[Hannsek]

@komret can this be closed?

[komret]

@Hannsek No, Capability_DisplayRotation should be added. I'd like to see Capability_Tutorial (to avoid code like this) and Capability_SecureElement as well.

[matejcik]

let's not add Tutorial capability and instead assume that it's there. it seems wasteful to do conditional code for a single version of firmware that the vast majority of TS5 owners won't ever install

i was thinking about the Rotation capability and it's actually not good as a single-bit capability. All trezor-core models support display orientation, it's just that TS3 only has North and South while TT/TS5 has all four cardinal directions (because square display)
(a hypothetical circular Trezor Safe 11 could have 360 degrees of display rotation :) )

If we really want to report this from firmware, we could make:
(a) an enum: None, Vertical, Full
(b) bit field representing 0, 90, 180, 270
(c) list of allowable values

[komret]

let's not add Tutorial capability and instead assume that it's there. it seems wasteful to do conditional code for a single version of firmware that the vast majority of TS5 owners won't ever install

It is still and official firmware users can download, and although it is an edge case, I want to avoid a possibility of a user ending up with a blank screen in Suite if they do onboarding on 2.7.2.

Another argument for having these capabilities reported by firmware is that we need to maintain inclusive lists in Suite/Connect for features like tutorial. If those lists were exclusive, (e.g. model not in [T1B1, T2T1]), any prototypes of new models would expect the tutorial feature, hence trezor/trezor-suite#9889.

I don't see the full picture, so If this doesn't justify adding the capability flags, let's keep status quo.

If we really want to report this from firmware, we could make: (a) an enum: None, Vertical, Full (b) bit field representing 0, 90, 180, 270 (c) list of allowable values

Either solution is fine, I prefer C.

[Hannsek]

I agree with matejcik. Let's assume that all TS5s have tutorial. Not many users will do the onboarding on 2.7.2.

[Hannsek]

Also, why do you want to have the capability of the screen rotation in features?🤔 This can be done based on the model, not the fw version.

[komret]

Also, why do you want to have the capability of the screen rotation in features?🤔 This can be done based on the model, not the fw version.

I thought firmware would be the best place to set this Maybe Connect is better. Currently, this logic exists in Suite so it cannot be shared with other frontends.

[Hannsek]

Which other frontends? You mean different 3rd party apps?

[komret]

Yes, or connect-popup.

[Hannsek]

Isn't then Connect a better place for this? cc @mroz22