XNextEvent does not work when program isn't ran from terminal - c

I'm trying to create a program which reacts to user key presses to display information over the screen.
I was able to create a window to display the information onto, but I have trouble grabbing the key presses - or more specifically, grabbing the key presses when running the program not directly from my terminal.
If I just run it as ./program, key presses are registered as expected, but if I run it from an sxhkd mapping, it does not work.
I put together a stripped down version of the program without the information displaying to illustrate the issue:
#include <X11/Xlib.h>
#include <stdlib.h>
#include <stdio.h>
int main()
{
Display *display;
Window window, rootwindow;
XEvent event;
KeySym escape;
display = XOpenDisplay(NULL);
rootwindow = DefaultRootWindow(display);
window = XCreateWindow(display, rootwindow,
-99, -99, 1, 1,
0, 0, InputOnly,
CopyFromParent,
0, NULL);
XSetWindowAttributes winattr;
winattr.override_redirect = 1;
XChangeWindowAttributes(display, window, CWOverrideRedirect, &winattr);
XGrabKeyboard(display, rootwindow, False, GrabModeAsync, GrabModeAsync, CurrentTime);
XMapWindow(display, window);
XSelectInput(display, rootwindow, KeyPressMask | KeyReleaseMask );
while (1)
{
XNextEvent(display, &event);
/* keyboard events */
if (event.type == KeyPress)
{
printf( "KeyPress: %x\n", event.xkey.keycode );
system("echo test >> ~/output");
/* exit on ESC key press */
if ( event.xkey.keycode == 0x09 )
break;
}
else if (event.type == KeyRelease)
{
printf( "KeyRelease: %x\n", event.xkey.keycode );
}
}
XUngrabKeyboard(display, CurrentTime);
XUnmapWindow(display, window);
XCloseDisplay(display);
return 0;
}
You can build it with gcc main.c -o program -lX11 -lXfixes -lXtst.
If you run ./program in your terminal, you should see KeyPress and KeyRelease info being printed out and be able to stop the program with ESC.
But if you map it to a keyboard shortcut somewhere, so it is not run this way, the program won't react to the key presses and won't exit on ESC (you'll need to kill it manually).
I think the culprit is setting override_redirect to the created window, but I need to do that since I don't want the program to open a new managed window but rather an overlay.
I'm not quite sure what the issue is, so the title of this question might need correcting.
Is what I'm trying to achieve possible? And if so, what am I doing wrong?
lsof output:
0r CHR 1,3 0t0 2051 /dev/null
1w CHR 1,3 0t0 2051 /dev/null
2w REG 8,3 3590712 524358 /home/eyfl/.xsession-errors
3u unix 0x00000000648e641e 0t0 4028921 type=STREAM
4u unix 0x00000000f842df04 0t0 24192 /tmp/bspwm_0_0-socket type=STREAM

Related

Capturing Mouse in Virtual Terminal with ANSI Escape

I've started to learn about ANSI escape sequences online through the magic of Google. It is neat being able to position the cursor \e[row;colH on the screen and set the colors of the outputs (ie: \e[31m).
Next I would like try and see how the mouse able to be captured in a virtual terminal. I realize this code is not portable, and I know I can use ncurses or some other curses library, but the goal here is to learn how it works, not write production code with it.
I have tried \e[?1003h and it starts to fill the screen with mouse events. (Pretty cool!) However, how do I capture these in a C or C++ program?
I saw an example of what I would like to do in PHP: https://stackoverflow.com/a/58390575/1770034
However, when I try to port the code over to something in C it just locks up in the while loop. (Tested with GDB to find that out.)
#include <stdio.h> //bring in printf and fread
int main()
{
system("stty -echo"); //make the terminal not output mouse events
system("stty -icanon"); //put stdin in raw mode
printf("\e[?1003h\e[?1015h\e[?1006h"); //start getting mouse events
char* buffer[255];
while(fread(buffer, 16, 1, stdin)) // <-- suppose to read in the mouse events
{
printf("here"); //Did you actually work?!
}
printf("\e[?1000l"); //Turn off mouse events
system("stty echo"); //Turn echoing of the display back on
return 0; //end the program in a successful state
}
I have also tried scanf and it just locks up until I hit enter, and I'm not convinced it is seeing the mouse events.
Edit
I now have some working code that spits out the mouse events.
Here is the updated code from applying the accepted answer to this question:
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <string.h>
int main()
{
system("stty -echo"); //don't show mouse events on screen
system("stty -icanon");
fprintf(stderr, "\e[?1003h\e[?1015h\e[?1006h"); //use stderr since not buffered turn on mouse event capture
char buffer[16] = " ";
char previousBuffer[16] = " ";
//Make standard in not be blocking
int flags = fcntl(stdin->_fileno, F_GETFL, 0);
fcntl(stdin->_fileno, F_SETFL, flags | O_NONBLOCK);
for (int hunSeconds = 0; hunSeconds < 500; hunSeconds++) //Run for 50 seconds
{
read(fileno(stdin), buffer, 16); //read mouse input
if (strcmp(buffer, previousBuffer) != 0) //only show event if it is different
{
fprintf(stderr, "%s", buffer);
strncpy(previousBuffer, buffer, 16);
}
usleep(100); // sleep for .1 seconds
}
printf("\e[?1000l"); //turn off mouse events
system("stty echo"); //turn on screen echo again
return 0;
}
Two problems:
printf is (using stdout) buffered, so there's no guarantee that the escape sequences got to the terminal before attempting to read.
stdin isn't necessarily the terminal (though it might be). Again, fread is buffered (and you may not get the result as promptly as you wish).
Since stderr is not buffered, it would help to send the escape sequences with that stream. Rather than using fread, it can help to use read, e.g.,
read(fileno(stdin), buffer, 16)

ncurses only reporting mouse movement when bstate is non-zero

I'm following along with the code from
https://gist.github.com/sylt/93d3f7b77e7f3a881603
Here it is, in case of 404
#include <curses.h>
#include <stdio.h>
int main()
{
initscr();
cbreak();
noecho();
// Enables keypad mode. This makes (at least for me) mouse events getting
// reported as KEY_MOUSE, instead as of random letters.
keypad(stdscr, TRUE);
// Don't mask any mouse events
mousemask(ALL_MOUSE_EVENTS | REPORT_MOUSE_POSITION, NULL);
printf("\033[?1003h\n"); // Makes the terminal report mouse movement events
fflush(stdout);
for (;;) {
int c = wgetch(stdscr);
// Exit the program on new line fed
if (c == '\n')
break;
char buffer[512];
size_t max_size = sizeof(buffer);
if (c == ERR) {
snprintf(buffer, max_size, "Nothing happened.");
}
else if (c == KEY_MOUSE) {
MEVENT event;
if (getmouse(&event) == OK) {
snprintf(buffer, max_size, "Mouse at row=%d, column=%d bstate=0x%08lx",
event.y, event.x, event.bstate);
}
else {
snprintf(buffer, max_size, "Got bad mouse event.");
}
}
else {
snprintf(buffer, max_size, "Pressed key %d (%s)", c, keyname(c));
}
move(0, 0);
insertln();
addstr(buffer);
clrtoeol();
move(0, 0);
}
printf("\033[?1003l\n"); // Disable mouse movement events, as l = low
endwin();
return 0;
}
When I put that into a file and compile it (gcc -o test test.c -lncurses), in xterm, mouse movements are reported without a button press. In gnome-terminal and Konsole, the movement events are only reported if a button on my mouse is pressed!
I would usually say it's just a compatibility/ standards thing BUT when I execute:
printf '\033[?1003h' on gnome-terminal or konsole, I can see all the mouse movements reported without any buttons pressed!
So what's going on here? How do I persuade gnome-terminal and konsole to behave like xterm? Or even to behave like themselves when they are in bash mode?
EDIT: Additional clues:
It appears this code works on all terminals if I scroll my mouse wheel. It's more than likely that this is what happened when I originally tested in xterm, as even xterm requires either a button pressed or the mouse to be scrolled for this to work.
Therefore: my question becomes why does the terminal only report mouse movement after the bstate has been modified in some way, even when the terminal reports escape sequences in bash mode?

SDL 2 hangs when polling for events

I'm working on a simple GUI, and i'm trying to use the SDL library with little success. I'm developing in C language, and i can't switch to C++.
I'm using SDL 2.0.5 on a Linux workstation (Red Hat Enterprise Server 5 (Tikanga)).
The problem is that when i try to catch events, the window hangs. No response, 100% CPU usage, and i've to kill the process. Clicking on the "x" have no effect.
I wrote a simple test code to figure out the problem, but i really don't know what to do. It looks like the inner "printf" it's never reached.
Also, if i remove the event loop, SDL_Quit() is reached (no need to kill the process) and it gives me a "Segmentation fault".
#include <SDL.h>
#include <SDL_events.h>
SDL_Window *mainWin;
SDL_Event mainEv;
int quit = 0;
if(SDL_Init(SDL_INIT_VIDEO) != 0)
{
printf("Init error.\n");
return(1);
}
mainWin = SDL_CreateWindow("Title", 0, 0, 640, 480, 0);
while(!quit)
{
while(SDL_PollEvent(&mainEv))
{
printf("Event!\n");
switch(mainEv.type)
{
case SDL_KEYDOWN:
quit=1;
}
}
}
SDL_Quit();
Try:
#include <SDL2/SDL.h>
//#include <SDL_events.h>
int main(void)
{ SDL_Window *mainWin;
...
... // same up to:
...
case SDL_KEYDOWN:
quit = 1;
...
SDL_Quit();
}
I pasted your code into "sdl_t.c", so compiled it with:
gcc sdl_t.c `sdl2-config --libs --cflags` -o sdl_t
I get a window that pops up and goes away when you press a key. There's obviously more to do ...
Have you seen this good tutorial?
http://www.willusher.io/pages/sdl2/

Why does `ioctl(fd, EVIOCGRAB, 1)` cause key spam sometimes?

I'm trying to write my own "keyboard driver" (without actually writing a kernel module),
by grabbing the keyboard at what I assume is the lowest level of abstraction in userland: /dev/input/event*.
The following code does the grabbing, provided you change the first ocurrence of ioctl(fd, EVIOCGRAB, UNGRAB)
to ioctl(fd, EVIOCGRAB, GRAB).
// gcc main.c -o main
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <linux/input.h>
#include <fcntl.h>
#include <errno.h>
#define EXIT_KEY KEY_ESC
#define UNGRAB 0
#define GRAB 1
const char* kbd_device = "/dev/input/event4";
// ------------------------------------------------------------------------------------------------
int main(void){
int fd = open(kbd_device, O_RDONLY);
if(fd == -1){
printf("Cannot open %s. %s.\n", kbd_device, strerror(errno));
return -1;
}
if(ioctl(fd, EVIOCGRAB, UNGRAB))
printf("Couldn't grab %s. %s.\n", kbd_device, strerror(errno));
else
printf("Grabbed %s!\n", kbd_device);
while(1){
struct input_event event;
read(fd, &event, sizeof(event));
if (event.type == EV_KEY && event.value >= 0 && event.value <= 2){
printf("%d %3d\n", event.value, event.code);
if(event.code == EXIT_KEY){
ioctl(fd, EVIOCGRAB, UNGRAB);
close(fd);
return 0;
}
}
}
}
Problem
If I run gcc main.c -o main && sudo ./main, everything works as expected.
If first compile and then I run sudo ./main, however, the terminal scrolls down nonstop, as if the RETURN key was held down.
Why does happen?
Notes
I'm running Ubuntu 14.04
On my platform, /dev/input/event4 happens to be the keyboard
Motivation
I'm trying to write a keyboard "driver" that works both on X and not on X (eg. a TTY).
I understand X11's keyboard library/extension is XKB. I think the TTY's keyboard library is linux/divers/tty/vt/keyboard.c (source),
the initial keyboard map it uses is in linux/drivers/tty/vt/defkeymap.map (source), and it can be modified by using loadkeys (source here). Do correct me if I'm wrong.
When you type
gcc main.c -o main && sudo ./main ↵
GCC takes some time, so the ↵ key has been released by the time ./main runs.
When you type
sudo ./main ↵
the terminal sends the shell a newline as soon as you push down ↵, and starts executing ./main. Then the ↵ released event is seen by your program, but not by your terminal, because your program has grabbed the input device. Thus, to the terminal it looks like ↵ is stuck down, so it continues to produce newlines.
This question has been answered already, but it still lacks an elegant solution to the problem.
I had the same issue with a driver I implemented some time ago that also required capturing the keyboard.
I could not find a way to force the the kernel to recognize a key release in the device before capturing it, so the solution consists in not grabbing the device until you detect that all keys have actually been released. This can be accomplished by monitoring the device with the EVIOCGKEY ioctl AFTER opening it and BEFORE grabbing it.
OBS: Please observe that the apparently dummy read function within the while loop is necessary in order to avoid a busy wait and so that the loop will iterate after each event from the input device. Also note that the file descriptor must be configured for blocking I/O (the default).
void waitReleaseAll(int fd) {
struct input_event evt;
unsigned char key_b[KEY_MAX/8 + 1];
int i, nothing;
while ( 1 ) {
memset(key_b, 0, sizeof(key_b));
ioctl(fd, EVIOCGKEY(sizeof(key_b)), key_b);
for ( nothing = 1 , i = 0 ; i < KEY_MAX/8 + 1 ; i++ ) {
if ( key_b[i] != 0 ) { nothing = 0; break; }
}
if ( nothing ) break;
read(fd, &evt, sizeof(evt));
}
printf("All keys are now released\n");
}
To fix your problem, you should use SIGINT in your code to identify Ctrl-C keystroke from the user.
Implement SIGNAL in your code:
static volatile sig_atomic_t stop = 0;
static void interrupt_handler(int sig)
{
stop = 1;
} // Outside of the main function.
int main(int argc, char *argv[])
{
signal(SIGINT, interrupt_handler);
while (!stop) {
//your code
}
exit(0);
}

Trying to get a process running running without an SDL (percieved) crash C

Okay so I'm pretty new to programming, so I thought as my first real programming challenge I would make a chess program to teach openings. Inside my game game loop I have everything I need, except at some point in the game loop I want to stop for input from the user, and wait to process that information before drawing the screen and continuing the loop. However when I do that, if the user waits to long to input(~8 seconds)(btw the input in console input for now, that will change later) then the game just crashes and I get the standard ubuntu "do you want to force quit or wait" message. I would like to keep this message from popping up, but I don’t know how.
Here's my code btw:
#include <stdio.h>
#include <string.h>
#include <time.h>
#include "SDL2/SDL.h"
void drawBoard(SDL_Renderer *renderer)
{}
void drawPieces(char fen[100])
{}
int processEvents(SDL_Window *window)
{}
I'm leaving these functions out because the are long and not super important(if you want me to I’ll put them up later)
void next_move(char firstmove[10], char response[10])
{
int cont = 0;
char move[6];
printf("%s\n>>", firstmove);
while(cont == 0)
{
scanf("%s", move);
if(strcmp(move, response) == 0)
cont = 1;
else
printf("Incorrect.\n%s\n>>", firstmove);
}
}
void caro_kann()
{
printf("YOU HAVE SELECTED The Caro Kann Opening ( main line )\n");
next_move("1. e4", "c6");
next_move("2. d4", "d5");
next_move("3. Nc6", "dxe4");
next_move("4. Nxe4", "Bf5");
next_move("5. Ng3", "Bg6");
next_move("6. h4", "h6");
next_move("7. Nf3", "Nd7");
printf("success\n");
}
int main()
{
int done = 0;
SDL_Event event;
SDL_Window *window;
SDL_Renderer *renderer;
//initialize everything
SDL_Init(SDL_INIT_VIDEO);
//setting up the window
window = SDL_CreateWindow("PlatoChess ALPHA 1.0",
SDL_WINDOWPOS_UNDEFINED,
SDL_WINDOWPOS_UNDEFINED,
800,
800,
0);
//Setting up the renderer
renderer = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED);
//setting up the program loop
while(!done)
{
if(processEvents(window) == 1)
done = 1;
caro_kann();
drawBoard(renderer);
SDL_Delay(10); //to cap the FPS
}
SDL_DestroyWindow(window);
SDL_DestroyRenderer(renderer);
SDL_Quit();
return 0;
}
Any help would be much appreciated!
First of all, "do you want to force quit or wait" is not a crash. All it means is that your program isn't processing events (which is true - you're in a blocking scanf and doing nothing). Even if you're waiting for something to happen, you still should process window events and update display if necessary, otherwise user can't close your program and if it gets overshadowed by another program (or just minimised) its display will be completely wrong.
Basically you shouldn't block in wait for input. Your options are (sorted by ascending difficulty, based entirely on my opinion):
change input scheme (e.g. use keyboard events that SDL gives you instead of stdin)
perform nonblocking read from stdin when input is available
use separate input thread (requires sync)

Resources