core: use ButtonRequestType.PinEntry for PIN entry

core/src/apps/common/request_pin.py

@@ -30,7 +30,7 @@ async def request_pin(
     attempts_remaining: int = None,
     allow_cancel: bool = True,
 ) -> str:
-    await ctx.call(ButtonRequest(code=ButtonRequestType.Other), ButtonAck)
+    await ctx.call(ButtonRequest(code=ButtonRequestType.PinEntry), ButtonAck)
 
     if attempts_remaining is None:
         subprompt = None

python/src/trezorlib/debuglink.py

@@ -208,28 +208,7 @@ class DebugUI:
 
     def button_request(self, code):
         if self.input_flow is None:
-            # XXX
+            if code == messages.ButtonRequestType.PinEntry:
-            # On Trezor T, in some rare cases, two layouts may be queuing for events at
-            # the same time.  A new workflow will first send out a ButtonRequest, wait
-            # for a ButtonAck, and only then display a layout (closing the old one).
-            # That means that if a layout that accepts debuglink decisions is currently
-            # on screen, it has a good chance of accepting the following `press_yes`
-            # before it can be closed by the newly open layout from the new workflow.
-            #
-            # This happens in particular when the recovery homescreen is on, because
-            # it is a homescreen that accepts debuglink decisions.
-            #
-            # To prevent the issue, we insert a `wait_layout`, which on TT will only
-            # return after the screen is refreshed, so we are certain that the new
-            # layout is on. On T1 it is a no-op.
-            #
-            # This could run into trouble if some workflow asks for a ButtonRequest
-            # without refreshing the screen.
-            # This will also freeze on old bridges, where Read and Write are not
-            # separate operations, because it relies on ButtonAck being sent without
-            # waiting for a response.
-            layout = self.debuglink.wait_layout()
-            if layout.text == "PinDialog":
                 self.debuglink.input(self.get_pin())
             else:
                 self.debuglink.press_yes()
@@ -354,7 +333,7 @@ class TrezorClientDebugLink(TrezorClient):
         if not hasattr(input_flow, "send"):
             raise RuntimeError("input_flow should be a generator function")
         self.ui.input_flow = input_flow
-        next(input_flow)  # can't send before first yield
+        input_flow.send(None)  # start the generator
 
     def __enter__(self):
         # For usage in with/expected_responses

tests/device_tests/test_msg_resetdevice_bip39_t2.py

@@ -175,8 +175,8 @@ class TestMsgResetDeviceT2:
             client.set_expected_responses(
                 [
                     proto.ButtonRequest(code=B.ResetDevice),
-                    proto.ButtonRequest(code=B.Other),
+                    proto.ButtonRequest(code=B.PinEntry),
-                    proto.ButtonRequest(code=B.Other),
+                    proto.ButtonRequest(code=B.PinEntry),
                     proto.ButtonRequest(code=B.ResetDevice),
                     proto.EntropyRequest(),
                     proto.ButtonRequest(code=B.ResetDevice),

tests/persistence_tests/test_wipe_code.py

@@ -62,7 +62,7 @@ def test_wipe_code_activate_core():
         ret = emu.client.call_raw(messages.ButtonAck())
 
         # Enter the wipe code instead of the current PIN
-        assert ret == messages.ButtonRequest(code=messages.ButtonRequestType.Other)
+        assert ret == messages.ButtonRequest(code=messages.ButtonRequestType.PinEntry)
         emu.client._raw_write(messages.ButtonAck())
         emu.client.debug.input(WIPE_CODE)