OpenMods/OpenPeripheral-Addons

Wireless keyboard mishandles non-printable keys

Closed this issue · 7 comments

erjo1776 commented

Using the latest git code as of today 2016-12-26, the wireless keyboard adds garbage text for all non-printable keys (running on Mac at least). I fixed the problem locally by adding a switch statement to GuiCapture:handleKeyboardInput(). The switch catches these keys and sets ch to zero which appears to work . This was just the first thing I tried, I don't know if there is a better way to fix it.

Let me know if I should submit a CL (haven't done that before for external projects).

Thanks,
Erik.

boq commented

What characters(codes) exactly? Can you post contents of few glasses_key_down events?

That sounds like lwjgl/keyboard issue and I don't want to block valid data on all configurations.

erjo1776 commented

Here is my proposed fix (git diff):
http://pastebin.com/7fw660TG

Here is the CC program I used to collect key and char codes (run using multiglass):
http://pastebin.com/Hg8vCQKk

The follow is results from hitting the keys: left down del backspace right_shift
Here is the output using current shipping OpenPeripheral:
http://pastebin.com/csUQFQae

Here is the output using my proposed fix (also includes 'a' to show that char message still work):
http://pastebin.com/yQ8acYdt

Let me know if I can do anything else useful.
Erik.

boq commented

Since it's (probably) not possible to open both CC computer and keyboard GUIs, I'm guessing you are using some extra code that translates glasses events to standard key and char events? If so, can you post it?

Also, contents of char event are bit jumbled, but my best guess is that contents of ch are -1 == 0xFFFF, which encodes in UTF-8 to '0xEF 0xBF 0xBF', which, when encoded in ISO-8859-1, gives us ï¿¿. Best guess since last two chars are 'replacement characters' �.

But quick look into LWJGL shows that 0xFFFF (KeyEvent.CHAR_UNDEFINED) is replaced with 0x00, so I'm not sure if I'm guessing correctly.

Anyway, without rambling, can you print contents of 'ch' instead of already converted value on Lua side? Or print contents of char event after converting with string.byte?

erjo1776 commented

The chars (16-bit values) all appear to start with $f7, such as the arrow keys:
$f700 up
$f701 down
$f702 left
$f703 right
$f704 F1
... and so on

A quick Google search found these values mapping to the same keys (in a Python project mind you), and it shows different values for different platforms (Linux different from Mac).

The bottom line, is that these keys are being assigned char values, but ComputerCraft does not want char values for these non-printable keys. My change is tied to the keycode value and clears out the char value, so it sounds safe to me.

boq commented

Found doc about Mac behaviour.

Since all Mac chars are from private use area, I will just block that block. It will still be less restrictive than CC char event (if ((ch >= ' ') && (ch <= '~'))), but compatible with OC unicode capabilities.

On Linux side it seems to use XLookupString and Xutf8LookupString which seem safe, i.e. don't return anything for arrow keys (verified with xev).

erjo1776 commented
boq commented

Blocked private use block. Leaving control block as-is for now, since it's mostly consistent between platforms (though Windows does not return any char for 'delete', while Linux does). So for full compatibility with char event from CC values < 0x20 still have to be filtered on Lua side.