Key reads on Linux (Raspbian)

Sysprogs forums Forums VisualGDB Key reads on Linux (Raspbian)

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #20678
    Brian Beuken
    Participant

    I’m having some issues reading keys again while running a project under VisualGDB on a Raspberry.

    I find that creating a new termio like so
    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);

    to create a raw input works ok

    but when it comes to reading it with

    int fd = fileno(stdin);
    char c = ‘\0’;
    int e = read(fd, &c, 1);
    if (e == 0) c = ‘\0’;
    // returns e = 0 for no key, e = 1 for pressed, and char in c
    if(e != 0)
    {printf(“got something %c\n”, c);
    }

    It will not work when using VisualGDB, though works fine when running on the Raspberry directly, I assume stdin is being redirected somehow by VisualGDB, is there some way to overcome this?

     

    #20684
    support
    Keymaster

    Hi,

    VisualGDB normally should not override the default behavior for key handling, so most likely this is caused by something else. We can help you narrow it down though.

    First of all, are you using a cross-compiler (with gdbserver) or is gdb running directly on Raspberry Pi? Does selecting Debug->Run Without Debugging result in the same behavior as under VisualGDB? If yes, does running the program from SmarTTY also reproduce the problem?

    #20690
    Brian Beuken
    Participant

    Hi

    No its building on the target and GDB on the Raspberry

    Running without debug produces some odd results (I’ve never used that option before) Graphics don’t appear, and errors get reported but the project does its best to run, but even so keys still do not register in the Stdin

    I find the new smartty to be unreliable, constantly popping up windows and warning of errors I don’t understand… but I can use a standard smarttty. Running from the standard smart terminal, navigating to the debug folder and ./ starting it, the project fires up, all graphics and other info in place, but again reports no keys.

    Going to the Raspberry itself, in the GUI opening the Debug folder and executing in terminal. I get my project up and running with graphics as expected, and the terminal output on the Raspberry reports the stdin keys are being read and reporting presses….kinda odd?

    And repeating the process in a terminal window on the Raspberry, navigating to the debug folder and ./ running the project, fires it up and again keys work and output is reported in the terminal window

    any ideas?

    #20693
    support
    Keymaster

    Hi,

    Thanks for checking this. It could be then a limitation of the SSH server. Please try reducing the program to a version that doesn’t depend on graphics (i.e. only uses the terminal API) and check if the problem could be reproduced with SmarTTY. If yes, please also check if any other SSH client (e.g. PuTTY) shows the same behavior.

    If this is the case, the issue is on the SSH server side and installing a newer version might help.

    #20695
    Brian Beuken
    Participant

    its a graphics based program, so I can’t really reduce it. I will make a small text test program though and see what happens.

     

    The version of Raspbian is the latest Stretch version,and Visual GDB is uptodate,   I’d rather not use other ssh clients, since I am attempting to use VisualGDB and dont’ want to be switching things around.

     

    #20698
    support
    Keymaster

    Hi,

    We understand this issue involves many different components, however separating them and running tests on several different configurations is the only way to narrow down the root cause. Without trying another SSH client it would not be possible to know whether the problem is related to the way VisualGDB handles SSH requests, or a general limitation of the SSH server.

Viewing 6 posts - 1 through 6 (of 6 total)
  • You must be logged in to reply to this topic.