When a signing device is presented a tx to sign, unfortunately it requires much more than the tx itself to give the end user an indication of how much is being proposed to send. Only the outputs are known with 100% certainty. The device must also know with 100% confidence the value of the inputs so the fees can be calculated. This in turn creates way more dependencies and code paths for a HW signing device.
Anyway, I'm now genuinely curious on how the Trezor is solving this problem. Etothepi, you mentioned they ran into it, and I presume they have attempted to solve it. Assuming that the software driving the HW wallet is not trusted (which is the cornerstone assumption of a good offline HW wallet design), I don't see how the device can pull this off without having a good deal of the blockchain present including some of it pre-programmed in the device at manufacturing. Maybe I'm missing some technique here, I'm all ears.
Yes you are missing something.
The way Trezor works is that the
untrusted host computer provides the Trezor wallet with every transaction that the to-be-signed transaction's inputs spend. All transactions refer to transaction inputs by a secure cryptographic hash, the transaction id. Thus it is impossible for the host computer to hide what transaction inputs are in fact being signed by the wallet - the worst the host computer could do is have the wallet harmlessly sign a completely invalid transaction.