Unify touch and button handling, enable usage of both in one model

[TychoVrahe]

We will need this in a future model. Only layout for TT is modifed to be able to serve both, with hope that we will unify the layout API soon.

[matejcik]

why not keep the button and touch interfaces separate and just allow both to be available at the same time?

---

in general we don't really want to keep the button code active in TT and vice-versa for TR. to facilitate that, we should do to USE_BUTTON and USE_TOUCH the same thing we do to BITCOIN_ONLY, namely:
(a) always use util.USE_XYZ instead of from util import USE_XYZ
(b) in site_tools/micropython/__init__.py, statically replace util.USE_XYZ with True / False as appropriate

[TychoVrahe]

why not keep the button and touch interfaces separate and just allow both to be available at the same time?

not sure how to do that actually, could that be done with loop.race? as loop.wait() only accepts a single interface. and if using loop.race is possible for this, i kinda don't like doing the added complexity of polling in parallel

[TychoVrahe]

added the replacement: 5925829

[matejcik]

not sure how to do that actually, could that be done with loop.race? as loop.wait() only accepts a single interface. and if using loop.race is possible for this, i kinda don't like doing the added complexity of polling in parallel

loop.race would work, yes, but the way you'd do it is define handle_touch and handle_button and specify both in create_tasks() (conditional on whether you're on touch- or button-enabled model of course)

[TychoVrahe]

ok trying it that way here: 72b816a

a bit annoying is needing to add the variants in several layout subclasses (for debug)

But mainly i am realizing here that this PR does not yet handle debug both interfaces properly, will need some more work. I don't like how button debug signal is implemented too: the middle button synthesis in TR layout seems wrong there, shouldn't it be synthesized rather in concrete tests? although it would probably require of sending PRESS and RELEASE separately, or maybe allow sending arbitrary button sequence. I would say that in this layout class we shouldn't care much about concrete buttons and their names (LEFT, RIGHT, etc), just receive a button code and send it to rust for interpretation. Thinking how to make the layout compatible with future models, where we won't have a LEFT and RIGHT button, but for example POWER button. Also not sure what 'swipe' is for in TR/button based model, seems odd.

[Hannsek]

What is the state of this one?

[matejcik]

it's in progress as part of #2299

[matejcik]

closing in favor of #2335