0

I've already posted this to the Super User exchange, but was told I may find an answer faster here.

I'm attempting to add a feature to an application to keep the screen awake while the user is logged in. The reason for this is that I recently implemented touchscreen functionality to allow the user to control the UI through a touchscreen. However, because we have an out-of-date Linux kernel, we have limited touchscreen functionality -- meaning that although the kernel has multitouch events defined, Xorg doesn't respond to touch at all. So I wrote a driver in the background of our Qt4 application to read touch events directly from /dev/input and to generate mouse events in the application.

However, because these mouse events are not on a system-level and are contained within the Qt application, they do not keep the screen awake or wake it once the screensaver starts. The goal of the touchscreen is to remove the need of the keyboard and mouse for the user on our product, and not being able to wake the screensaver would kind of make it difficult to use it.

The application already has a QTimer setup that fires every 60 seconds (in case some system process changes these settings while the application is being run) to "prevent the screensaver", but after looking at the command it was issuing, it's obvious why it doesn't work, because the command it's using is:

xset s on

So I changed the timer to instead issue the following commands:

xset s off
xset s noblank
xset -dpms

I also tried executing this command to attempt to prevent xdg-screensaver from launching:

xwininfo -name "plasma-desktop" | grep "plasma" | cut -d' ' -f4 | xdg-screensaver suspend

However, even with these changes, the screensaver eventually appears.

Are there other settings I need to disable to prevent this? Assuming the screensaver that's appearing is the result of the OS launching xdg-screensaver, is there a way I could prevent the launching of that application while our application is logged in? Or is there some other way I should go about this?

If it matters, we are running Scientific Linux 6.4 (kernel 2.6.32-754).

EDIT: Forgot to mention, the desktop environment is KDE4.

EDIT: I found a KSS file matching the screensaver that shows up. I tried renaming it, but that just resulting in a blank screensaver showing up in its place. I need to know how to disable the service that is launching it.

  • Is this in GNOME? – Wildcard Oct 3 '19 at 16:29
  • @Wildcard Probably should have mentioned in my post, but no, it's KDE. – Darin Beaudreau Oct 3 '19 at 17:00
0

So this probably isn't the best way, but I figured out one method of getting the screensaver / lock to stop appearing. I found the binary for kscreenlocker under /usr/libexec/kde4, and renaming the file seems to prevent the screen lock by ensuring it can't be executed.

0

You could still read from /dev/input but, instead of sending the resulting mouse events to the application (thus hidden from the system), you send them via a userspace driver to the system.

The events will then follow the same path normal mouse events would follow, allowing you to deactivate the screensaver.

Before:

/dev/input -> your_driver -> application

After:

/dev/input -> your_driver -> uinput -> X -> application

An you even get to completely decouple the application from the driver.

This question has some answers on how to do it.

  • Generating raw events in /dev is likely an option, but is there a way to generate system-wide mouse events via Qt? The application is C++, so uinput isn't an option. I would also not want to involve external libraries beyond Qt if possible. – Darin Beaudreau Oct 11 '19 at 19:29
  • That's what I mean by decoupling. Your application doesn't need to know about the python script it will receive the events as if the Xorg had been able to read the touchscreen directly. Anyway, you can use the driver with raw input/output from the application if you so wish. Check this that should get you started. – Eduardo Trápani Oct 14 '19 at 14:15
  • @Eduardo_Trapani I can't just generate the mouse events and receive them in the application because the events being fired when I generate the Qt mouse events are what I'm using to handle the touch controls. The application needs to be doing the parsing because it needs to keep track of the touch positions and number of touch points. – Darin Beaudreau Oct 15 '19 at 13:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.