Keyboard entry is a separate client mode, not an HTML text field. A page link or control can open it, and a subsequent request submits the entered text. The original V2 keyboard worker places text in an X-Email-Addr header and sends an empty POST body; its update path removes line feeds before submission. [1][2]
Continuation
The receiving page may provide a forward destination that the client uses after submission. The original code limits the forward destination's length and uses a history sentinel in the keyboard flow. If text entry returns to the wrong page, inspect both the submission response and the client's history state. [1][2]
Command input is different
Community documentation also describes a button-code command screen that sends a code in a query string. It has its own internal entry action and character set, rather than reusing a text keyboard POST. Treat the command and keyboard flows as separate features even if both appear as “input” to a user. [2]
Bounds and encoding
Character limits, encoding and header buffer sizes are part of compatibility. The examined worker formats text into a fixed-size temporary buffer; accepting an arbitrarily long Unicode string on a modern server will not make the original client capable of sending it. Test the exact DSi output for empty input, a short non-ASCII string and a long value. [1]
Two entry routes
A link ending in .kbd opens the text keyboard and submits to that URL. The wiki's preset-input form puts ?s=| before the initial text. An internal ugomemo://keyboard/ URL can name a destination too, although the historical test did not see the client navigate to the resulting page. An ordinary .kbd POST response can instead use X-DSi-Forwarder to choose the next page. Test both submission and navigation: receiving text in X-Email-Addr does not by itself show that the next page opened. [3]
Command search uses ugomemo://command and a GET with a command query value. Its input alphabet is A, B, X, Y, L, R and N/S/W/E for the four directions. The wiki reports that the response needs an X-DSi-Dialog-Type header: documented values are 0 for a UTF-8 destination URL and 1 for a UTF-16LE error message. This is a different continuation protocol from the keyboard's empty-body POST. [3]