Windows has the SetThreadExecutionState method that enables you to prevent monitor standby during program execution.
I'm searching for a Linux equivalent, but I can't find anything useful.
I don't want to disable the screensaver by calling a command, because if the program crashes after that, the screensaver will stay disabled until the user re-enables it.
The program is written in Qt, so a Qt friendly solution would be great.
Ideas anyone?
I was looking for this and couldn't find a solution, but instead a workaround. Launching at the same time as the application (a video player) a little script to periodically check if the application process is alive, and if it isn't, re-enable the screensaver. In my case using xset s on and xset s off, then end the checker process itself. You can probably fork a process to the background so it stays alive and does its re-enable job reliably.
Related
I am using Linux platform (CentOS 7). sometimes i get my system just hang and then i need to do restart my system directly from power so anyone know how to rectify this issue without restart my system.I am fed up with every time restart my system. so please help me out.
I know here i will get my answer that's why i posted my question here.
Thanks in advance!!!
You can goto text mode and kill the process which process are running in your system,
Press CTRL+ALT+F2 and goto textmode.
Type your username and password
Write command ps -eaf|grep chrome (you can see here which process is
running and take that process number just like task manager in
windows)
Now need to kill that process so Write command kill -9 [process#]
once process will kill you can comeback again in graphics mode with
CTRL+ALT+F1
I hope this this answer will helpful for you beacuse this process is work fine for me when my any application stuck. :)
This one is a pretty strange question of mine so I'll try to explain the best I can.
On a DOS Linux distribution, without having installed any graphical environment, if I start an application which is supposed to have a GUI, will I be able to interact with that window via code?
What I thought is that if KDE/GNOME's role is to graphically represent an existing GUI, I should be able to interact with it but if these graphical environments have an active role in the window creation there is nothing I can do.
You won't be able to run a graphical program without a window manager.
The reason is that the window manager is doing a lot more than just allowing the window to be shown to the user. It comes with libraries and services for constructing windows and components and interacting with them. Without these libraries and services, the program won't be able to start.
The only exception would be if a program contained all the graphical code built into it, and didn't rely on a window manager. Realistically this would only happen for a fairly simple program and in special cases; for instance, Raspbian includes OMXPlayer, which shows full screen video without relying on any window manager.
Quoting (with some adaptation) from https://raspberrypi.stackexchange.com/a/3974 which answers how to start mplayer in X11 without a window manager:
The X server is really usually called X and you can just start it. You can set the DISPLAY number as an argument along with some other things.
You might want to have some sort of session, though, and still go through xinit or such and start X with startx. You can use .xinitrc or such as a script and simply not start a window manager there. You will need a "magic client" as the last command that stays running so X doesn't terminate immediately. In a traditional "failsafe" session, that was an xterm. If you know what to launch and launch once only, it could be that program or any UI/wrapper that does the launching for you. When the last ("magic") client in the init script terminates, X terminates.
If all you want to do is play video, you might see if you can run mplayer with directfb instead and skip using X11 entirely.
I'm writing a set of Linux framebuffer applications for embedded hardware. The main application runs on tty1 from /etc/inittab (for now it's just a touchscreen test) and is supposed to run permanently. The second application is executed from acpid when the power button is pressed, and it's supposed to ask user if he really want to shut the device down, and read user answer from a touchscreen. What I want is that the second application would takeover framebuffer while it runs, and then release it and restore the state of screen, so the main application can continue without restart.
Is this scenario possible with 2 different applications, and how should they interact ? Now the second application just can't draw anything while the main application is running.
I know I can kill and restart main application, or move poweroff notification to the main application and have acpid just sending a signal to it, but those solutions don't seem to be optimal.
One solution would of course be to have THREE applications, one that does the actual framebuffer interaction, and the other two just sends messages (in some form, e.g. through a pipe, socket or similar). This is how "window managers" and similar usually works (but much more complicated, of course)
We have about 40 computers running identical hardware and software. They all run Ubuntu 11.10. They all have just one user account to log in. The .profile file is set up to launch a daemon process. The code for the daemon is written in C.
Once in a few weeks, we get a report that the daemon is no longer running. This does not happen on all computers but just one or two. We cannot reproduce the problem consistently.
Looking at the code, the application quits when it receives either SIGHUP or SIGTERM.
As I understand, SIGHUP is generated when a user logs off. In our case, the user never logs off. I am wondering if it is possible that SIGHUP could have been generated for some other reason. Any other thought would be appreciated.
Well, there are a couple of things to note about SIGHUP. Firstly, its origin is from the concept of a hang-up, i.e. loss of connection to a console over something like a modem. In modern parlance this generally means it has lost its controlling tty. Unless you've taken care to detach from your tty, any program started in a given terminal will receive a SIGHUP when the terminal is closed. See here for details on how to do this in your program. Other options include:
running your program inside screen or tmux
run your program with nohup or some other daemonising framework
The other possibility is something is deliberately sending your process a SIGHUP which by "tradition" is often used to signal a process that it should re-read its configuration.
Signals can be sent using kill utility or kill syscall.
Of course, you can try and find out who is sending that signal or disconnecting your terminals or network connections, but there is simpler practical way to fix your problem.
When code is supposed to run as a daemon, but really isn't (just like yours), there is a wrapper that can turn any program into daemon. Surprise - this wrapper is called daemon! It has lots of options, probably most importantly for you, option to automatically restart your utility should it ever die for any reason.
If this command is not installed on your Ubuntu, just sudo apt-get install daemon, and man daemon to get started.
I am using Eclipse CDT with Qt plugin. Working on Debian without X, running the GUI with Qt's QWS server.
Simply, I am starting a regular cpp thread doing the logical work and then starting a standart QApplication execution. Works fine on the target machine locally. But when I start the program remotely from Eclipse's Remote System Explorer service or start to debug with gdbserver, the keyboard input is not handled correctly, randomly picks up some of the keyboard events ie, it is in a racing condition. However, the mouse input works just fine.
I am aware the question is not clear enough but I couldn't figure how to focus on the problem. I can provide additional feedback on demand.
Thanks in advance.
Generally when you get odd behavior with QT and input handling, you've somehow mucked up QT's finite state processing loop. You're running in a debug environment, which always tends to mess things up just enough to make them more trouble than they're worth. Can you move to trying to test it on a remote X display?