You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of #4435 , the behavior when trezor is running without display is unified to just ignore rendering and otherwise continue with its function.
This might not be always desirable, but what to do instead?
I.e. should we start firmware when kernel can't initialized display? or should we try to signal this somehow to user? via flags in get-features, or maybe we could introduce get-errors or something. On some models we have LED so we might use that for signaling such errors.
In bootloader the desirable behavior could be different. In some situations (like in manufacturing), we need to allow running without display, but we might want to condition this on some OTP flag. But we should probably define what happens when there is some user action awaited, like confirming firmware installation - that should probably be auto rejected, but we need to think through and handle each case.
Prodtest and boardloader might need their own logic too.
The text was updated successfully, but these errors were encountered:
As of #4435 , the behavior when trezor is running without display is unified to just ignore rendering and otherwise continue with its function.
This might not be always desirable, but what to do instead?
I.e. should we start firmware when kernel can't initialized display? or should we try to signal this somehow to user? via flags in get-features, or maybe we could introduce get-errors or something. On some models we have LED so we might use that for signaling such errors.
In bootloader the desirable behavior could be different. In some situations (like in manufacturing), we need to allow running without display, but we might want to condition this on some OTP flag. But we should probably define what happens when there is some user action awaited, like confirming firmware installation - that should probably be auto rejected, but we need to think through and handle each case.
Prodtest and boardloader might need their own logic too.
The text was updated successfully, but these errors were encountered: