On Raspian Jessie mouse and keyboard clicks passed to background desktop screen

[ozc]

On Raspberry Pi 2 Raspian Jessie, mouse and keyboard works but on fullscreen app (could not found a way to run in a windows btw) mouse and keyboard clicks are passed to desktop screen. No problem with binding keys on keyboard, or mouse working, eg/ on settings screen, but those mouse clicks cause running some applications on the background.

[schitzN]

Thumbs up for this issue!

I'm also working with Kivy on Raspian Jessie for some time now and as far as i can say, it only works really well when you are in cli and start the app in fullscreen.

When i start an app in x-session, i can't even close the application (no esc, no ctrl-c,...) - the input in textfields is working though.

What i found out about that issue is, that Kivy is rendered on top of your x-session - and your mouse seems also to be still active behind your app. This also seems to be the reason, why you don't see your mouse-cursor, when you don't enable the workaround with "touchring = show_cursor=true" in your config.ini. (The thing here is, that i only see the touchring when i press my mousebutton - probably should further look into kivy's touchring module docs)

Therefore, the only real way to run kivy on raspbian atm is to reboot into cli and start your app there.

[ozc]

If I start the application from terminal application in x-session, ctrl-c works. But if the application is started by autorun after login, ctrl modifier does not work.

Mouse-cursor is visible always and working good (except click is done on upper left corner of the touchring icon).

The only solution is running in cli mode, as you have mentioned.

[JohnPersano]

Confirming this issue as well. I have opened a StackOverflow question regarding this.
Starting in CLI alleviates the touch issue (obviously) however physical keyboard input is still passed through.

[ghost]

same problem here. still no soution? :/

[kived]

RPi Kivy apps don't run within X. In order to utilize the hardware acceleration on the RPi we have to write directly to a framebuffer, which renders over whatever would otherwise be on the screen (X11 or a VT). As such, we don't do anything with X Input, so input events are still passed to X if it's running, and all RPi Kivy apps are fullscreen.

[Hayatomon]

FYI: I made a workaround.
The X11-app grabbing the fullscreen behind the kivy-app on the desktop can catch the all events passed from kivy-app to desktop.

sample code:

// gcc -Wall -L/usr/X11R6/lib -lX11 kivyrun.c -o kivyrun
#include <X11/Xlib.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

unsigned long RGB(Display *disp,
        unsigned char r,
        unsigned char g,
        unsigned char b)
{
    XColor xc;
    Colormap cm = DefaultColormap(disp, DefaultScreen(disp));

    xc.red = 257 * r;
    xc.green = 257 * g;
    xc.blue = 257 * b;

    XAllocColor(disp, cm, &xc);
    return xc.pixel;
}

int main(int argc, char *argv[])
{
        char cmdStr[1024];
        Display *disp;
        XWindowAttributes attr;
        XSetWindowAttributes myAttr;
        Window myWin, rootWin;
        int screen;
        GC gc;

        if (argc != 2) {
                fprintf(stderr, "Usage: %s SCRIPT_FILE_NAME\n", argv[0]);
                exit(1);
        }

        disp = XOpenDisplay(":0.0");
        if (disp == NULL) {
                fprintf(stderr, "Cannot open display\n");
                exit(1);
        }

        rootWin = DefaultRootWindow(disp);
        screen = DefaultScreen(disp);

        XGetWindowAttributes(disp, rootWin, &attr);

        myAttr.override_redirect = True;

        myWin = XCreateWindow(disp, RootWindow(disp, screen),
                0, 0, attr.width, attr.height, 0,
                CopyFromParent, CopyFromParent, CopyFromParent,
                CWOverrideRedirect, &myAttr);
        XMapWindow(disp, myWin);

        gc = XCreateGC(disp, myWin, 0, 0);
        XSetForeground(disp, gc, RGB(disp, 0, 0, 0));

        XFillRectangle(disp, myWin, gc, 0, 0, attr.width, attr.height);
        XFlush(disp);

        snprintf(cmdStr, 1024, "python %s", argv[1]);

        printf("%s\n", cmdStr);
        system(cmdStr);

        XCloseDisplay(disp);
        return 0;
}

Please type:

kivyrun SCRIPTNAME

instead of

python SCRIPTNAME

[dirkjan237]

Thanks for posting that workaround!

I've tried it out on my RPi but it throws the "Cannot open display" error, so I'm assuming something goes wrong in the XOpenDisplay.

I'm new to Kivy and Python in general, and have zero experience with C so I'm at a loss as to what I'm doing wrong.

Do you have any suggestions for troubleshooting steps I could take to help fix this?

If it helps, I'm running Raspbian Jessie and Kivy 1.9.2.

Any help would be greatly appreciated!

[Hayatomon]

dirkjan237,

I think you didn't have an authorization of X-window at that time.
For example, don't running X11-desktop or another user is running X11-desktop.

At first, you should login to X11-desktop.
Start a LXTerminal by launch menu on the desktop then execute the such command.

If you found the error again, type 'echo $DISPLAY' on LXTerminal and compare with the parameter of XOpenDisplay(":0.0") in the source code.
If $DISPLAY was empty, you don't run the X11-desktop.
If it is different from the parameter, change the parameter in source code to the value or NULL.
When you set the parameter to NULL, environment variable (DISPLAY) will be used.

example1:

$ echo $DISPLAY
:0.1
$ 

You have to change the parameter below:

• option1:

disp = XOpenDisplay(":0.1");

• option2:

disp = XOpenDisplay(NULL);

example2:

$ echo $DISPLAY

$ 

You have to run the X11-desktop first.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[dlparker]

Seeing the same thing on Raspbian stretch. That would be expected from the comment by kivyd above, but I wanted to remind the developers about it so that the stale bot won't close the issue.

Kivy and the official touchscreen are a killer match for a lot of uses, so a fix would be nice.

[YaarPatandarAA]

@Hayatomon 's C file helped in running the Kivy app with the X11 still open in the back. Thank You @Hayatomon

[te-bachi]

I found a better solution if you use Xorg (= desktop screen, x-session) on HDMI-1 and a Kivy app on DSI-1. As @kived explains, a Kivy app draws directly to a framebuffer bypassing the X server. But the touchscreen itself is listed as an X input in the X server:

$ xinput
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ Logitech MX Anywhere 2S                 	id=6	[slave  pointer  (2)]
⎜   ↳ FT5406 memory based driver              	id=9	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ DELL DELL USB Keyboard                  	id=7	[slave  keyboard (3)]
    ↳ DELL DELL USB Keyboard                  	id=8	[slave  keyboard (3)]
    ↳ Logitech MX Anywhere 2S                 	id=10	[slave  keyboard (3)]

From Disable mouse (not touchpad!) in Xorg while idle I could disable temporarily the touchscreen in Xorg but not in the Kivy app as following:

$ xinput list-props "FT5406 memory based driver"
Device 'FT5406 memory based driver':
	Device Enabled (114):	1
	Device Node (263):	"/dev/input/event2"
        [...]

$ xinput set-prop "FT5406 memory based driver" "Device Enabled" 0

I will check if there is something that is more persistent like How to disable touchpad completely on boot?

[fsinisi90]

I'm having the same issue with this configuration:

• Python: 3.6.0
• OS: Raspbian GNU/Linux 9 (stretch)
• Kivy: 1.10.1

A fix would be nice.

[LeLieuMultiple]

@Hayatomon 's solution still working so far, using Raspbian 9 (stretch).
I had 3 problems:

• due to changes inside the /usr folder, I think the new compile command should be:
  gcc -Wall -L/usr/include/ -lX11 kivyrun.c -o kivyrun
• use ./ before the kivyrun command to run the file :
  ./kivyrun /path/to/my/file.py
• when the kivy application has started, you need to click at least once inside your program window (which is in fullscreen) to get it focused. Everything you type before clicking will be typed inside X11 instead.

[asim-abbas]

In my application I am popping up the terminal window in front, but its popping up the window but in background. I tried using sdl2, its so slow. If anyone has found any other solution?

Or if any body has tried the kivypie distribution?

[wolfmanjm]

This is an issue not only with X. I am running a Kivy app using egl_rpi and No X windows, and using hidinput. All the keys are going to the shell in the backround potentially causing havoc as they run commands in that shell. The keys are also seen by Kivy of course. The X solution above won't work in this case as there is no X. I am actually quite surprised this is still an issue.

[wolfmanjm]

FYI my current solution to this when running in egl_rpi (no X) is to run my kivy app in the following shell script...

stty -echo
python3 main.py
while read -r -t 0; do read -r; done
stty echo

This stops the echoing of the characters to the background shell, then eats up the characters before the shell can get them.

[clickworkorange]

I am actually quite surprised this is still an issue.

+1, though a few years have now passed - maybe there's a proper solution? I use a barcode reader which acts as a USB HID keyboard; each scan prints the barcode's content + CR to the console even when the Kivy app is running. This leads to repeated failed logins on the terminal:

Raspbian GNU/Linux 9 station tty1
station login: 82947682
Password: 
85404526
70198164

Login incorrect
station login: 72998502
Password: 
81799152
48270571
52904783

Login incorrect
...

[tshirtman]

can't you just configure the default tty to have no console on, just like the one for X on most distribution, so the touches/keyboard events are not received by anything? (and you can still use alt-fN to switch to a different tty), this is system configuration, not something kivy can really solve in a general case.

[clickworkorange]

can't you just configure the default tty to have no console on

Absolutely, in fact I was going to do that before deployment anyway, to get a completely blank boot-screen. I just thought there might be some way in Python/Kivy to capture a particular USB device and gobble up everything it produces.

[Kuldeepwadaskar]

do
export DISPLAY=:0.0

[dsz-dsz-k]

do
export DISPLAY=:0.0

Doing this prevents the application from using the OpenGL ES broadcom driver on my raspberry pi 3.
It uses the Open GL software emulation instead, having very poor performance and CPU used at almost 100%.

Only way to use hardware acceleration is to set the DIPLAY environment variable to nothing.

Maybe I'm doing something wrong and there's another way to force SDL2 to use the hardware chip...

[dsz-dsz-k]

I worked around my problem by disabling the xinput device at lauch in my kivy app and enabling it again just before exiting.

Not a nice solution though...

[Julian-O]

Closing as this isn't a bug in Kivy; it is a configuration issue with several workarounds given above.