It is mapped with the keyboard mapping to the resulting character so
the key 'A' is DIK_A nomatter what its scancode or vkey would be. This
is relevant to Japanese keymapping where the '@' key is in the '['
location the scancode for both is 0x22 but dinput generates DIK_AT in
japanese and DIK_LBRACKET in us_qwerty.

There are also overlay backbuffers, which aren't render targets. The
primarysurface and d3ddevice cap flags should be enough here.