Keyboard issues - Printable Version

Keyboard issues - Printable Version

+- Forums (http://www.scratchpadgames.net/forums)
+-- Forum: Main Forums (http://www.scratchpadgames.net/forums/forumdisplay.php?fid=1)
+--- Forum: Raspberry Pi questions (http://www.scratchpadgames.net/forums/forumdisplay.php?fid=4)
+--- Thread: Keyboard issues (/showthread.php?tid=37)

Keyboard issues - Brian Beuken - 03-05-2018

The standard keyboard system I provide, is 99% effective, but I have discovered one or 2 wireless keyboards don't work. unrelated to the file lock some linux systems have, where a sudo chmod a+r /dev/input/* will make your event files accessible.

Usually the fix is to look at the AreYouMyKeyboard scanning method, whose job is to parse though the input systems to find the current active keyboard. Most Wired and WiFi keyboards will work perfectly with no issues, but sometimes wireless keyboards don't play nice. Usually though that can be fixed by changing the pattern to search for from event-kdb to event-mouse.

However.....Some BT keyboards won't even work with that fix, and I don't know the exact reasons why, Raspbian do state that not all BT keyboards are compatible, but its frustrating to see your BT keyboard working on your terminal and not in your project. However there is a "fix" but its very hacky will make your code work only on your system with your keyboard.

So if you are one of those poor people with a keyboard that refuses to register, you can hack the ProcessKeyboardThread to hard wire the event that controls your keyboard, like this:

//fp = fopen(((Input *)arg)->kbd.c_str(), "r"); // normal scanned keyboard

fp = fopen("/dev/input/event1", "r"); // hacked forced event0 or event1 or... (up to max events)

I'll work on a better solution, but for now this will fix most issues.

RE: Keyboard issues - Brian Beuken - 04-11-2018

More info on keyboard issues.

I was just doing the Magpi lesson on starting to move sprites around with keyboard, and since I am not using my own keyboard code I needed to use a standard system like this

Code:
//set up a raw keyboard read, save the old one and steal a lot of its info but set to no pause

    int fd = fileno(stdin);

    ioctl(fd, TCGETA, &original_termio);

    new_termio = original_termio;

    new_termio.c_cc[VMIN] = 0;

    new_termio.c_cc[VTIME] = 0;

    new_termio.c_lflag = 0;

    ioctl(fd, TCSETA, &new_termio);

and the actual read

Code:
        int fd = fileno(stdin);

        char c = '\0';

        int err = read(fd, &c, 1);

        if (err == 0) c = '\0';

        // returns err = 0 for no key, err = 1 for pressed, and char in c

But that simply wont' work if you are running your code in VisualGDB...its annoying as hell, The code will work perfectly if you fire it up from the target directly though so the system is viable, but I assume VisualGDB is redirecting the input somewhere preventing you from using it.... I have posted a note on sysprogs.

oh if you are going to use this code, be sure to switch the key input back to normal when done with this

Code:
int fd = fileno(stdin);

    ioctl(fd, TCSETA, &original_termio); // put the old one back

I don't really like this form of keyreader, it is quite laggy, and also buffers your keypresses, meaning it will still register them for a few frames after you remove your finger, I assume there is some way to flush the buffer once you do a read, but I've not found it yet. (anyone??)

My own input systems are far more precise and reliable, IF they are set up correctly.