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)
Related
I have a separate process and GUI for my application. Details below. Now I am ready to bring the application "in production". Although there are likely only 2 users on this planet I want to handle the startup of the application correctly. That is, adhering to the correct Unix philosophy. Although the application might be able to run in Windows, I am not interested.
I think I have 2 options:
Starting both the player process and the GUI from their own init.d scripts. And have a third script to call both. Usually placed in an autostart directory. Or just have both the process and the gui startup script in the correct rcX.d
Start the player process from an init.d script and fork the GUI from within the process. I could pass parameters to the process to tell whether or not it should start the GUI. This does not preclude starting a GUI process manually elsewhere.
Both options have variations, but the difference between the two is fundamental.
More info on the application
The application is an internet radio player. But with the special feature it can play back previously recorded streams, introducing a time shift to compensate for time differences if the player and transmitter are in different time zones.
The recorder is part of the same project, but not part of the application.
The application consists of the player which is able to play headless, and fully controlled through configuration files. The player can also be controlled by a GUI which communicates with the player through TCP/IP. The application gracefully handles if the player runs without GUI a single GUI, or with multiple GUI's. The GUI gracefully handles the absence or re-connection of the player.
If the player runs headless I want to connect from any PC with a GUI. In some situations I want to use the application and GUI on the same laptop or PC. The main application is a dedicated RasPI player with touch screen. This RasPI should launch both the player and GUI simultaneously when I start the application. Optionally I can start another GUI from another PC to control settings I cannot access thru the touch screen.
I don't think it is relevant, but both parts are written in Tcl/Tk. The player has an extension which interfaces to the libmpv API, part of the mpv media player.
So the player and the GUI are so far independent nothing breaks if one runs without the other, and recover gracefully when they both run. The question is how to start both processes. Independent init.d scripts or forking.
Assuming both the player and the GUI are implemented as Tcl scripts, you can use the source command to load one from the other. For example, when starting the GUI, it can detect that the player is not running (because the socket connection fails). In that case it can do source player.tcl. To avoid name conflicts you can use different namespaces, or load the player in a separate interpreter. I don't expect either of the components to do any blocking actions. But if they do, you can even load the player in an interpreter in another thread.
set dir [file dirname [file normalize [info script]]]
interp create player
player eval [list source [file join $dir player.tcl]]
There are other possibilities for deciding between starting one or both components, like passing a command line option to either of the components to also load the other component.
Since you are specifically interested in linux, another strategy would be to make use of dbus. Your player could publish a dbus interface (using dbif). The GUI can then call a method of that interface, with the "-autostart" option on (the default). When set up correctly, that would cause the player to start, if it isn't already running.
In player.tcl:
package require dbif
dbif connect tk.tcl.mpvplayer
dbif method / Version {} version {return $::version}
You can add more methods, and signals and properties. But since you already have a TCP/IP interface, you don't need to implement a full API via dbus.
In your GUI application:
package require dbus
dbus connect
# Auto-start the player, if necessary
dbus call -dest tk.tcl.mpvplayer / tk.tcl.mpvplayer Version
To enable auto-starting the player, create a file ~/.local/share/dbus-1/services/tk.tcl.mpvplayer.service:
[D-BUS Service]
Name=tk.tcl.mpvplayer
Exec=/home/pi/mpvplayer/player.tcl
The examples above use the session bus, which is normally associated with the display (:0). To make it work when the player runs headless, you may need to set the DISPLAY variable for it to connect to the correct session bus. Alternatively you can use the system bus. But that will require some adjustments.
I saw that Windows/Linux has the ability to suspend a process.
It is wired for me why background applications are not suspended automatically.
For example, lots of resources are used by Chrome when it is in the background. Easily it can be suspended. So it will stay in RAM and it can unsuspend quickly but it will not use CPU and GPU.
My question contains two parts:
Why Windows/Linux (or applications) don't use suspend feature? (sth similar to pause in Android but in the different way)
Is there any way to suspend a background task and unsuspend it when it gets focus (when it goes to foreground)?
A process like Chrome might not have input focus on the user interface but still be "running." (Chrome consists of a set of related processes and threads.)
Yes, Linux does have the ability to actually "suspend" a process using the STOP/CONT signals, but this would be disruptive to the user interface because Chrome, now being literally frozen, could no longer respond to messages sent to it by the user interface.
Processes and threads only consume CPU resources when they actually need to (they are "runnable"), and then only when the operating system gives them a time-slice. If a thread or process is, say, "waiting for the user interface to send it a message," it's not considered to be "runnable" until a message arrives.
It's also typical that, when a process doesn't have input focus, its priority is slightly reduced so that it always gives-way to the process that does. In some systems, the priority is even more reduced when you minimize the window. (When several processes are "runnable," the operating system uses "priority" to help it to decide which one to run next.)
When the Centos will Shutdwon, reboot or logoff , I want to pop a Message Window.
I made the window by gtk, then how can i do?
Please forgive me my lousy English. :-(
You will need to write your program as a daemon, and use DBus to monitor signals from logind. Take a look at the PrepareForShutdown and PrepareForSleep signals; probably also one or more of the UserRemoved, SessionRemoved, SeatRemoved signals.
In order to pop up your dialog you will also need to set an inhibitor so that the system cannot shut down until your dialog box has been dismissed.
If you want to interrupt logging off or switching users, you will also need to set an inhibitor on org.gnome.SessionManager.
'Behind the scenes', in modern Linuxes, is a system which sends notifications to applications interested in them. Though I haven't used shutdown and similar events, I'm quite certain they are available too. This notification service is Window-manager independent, and works in both Gtk+ and Qt.
Even though CentOS isn't mentioned in this list, there should be ample information in the links provided. Lower down the page is a reference to libnotify, which is the toolbox for C. Many others are mentioned.
I have two applications running on an embedded linux platform. I want to have the main application have focus with the keypad but I want another application in the background that can monitor key presses for the KEY_POWER to signal the system to shutdown.
We want to make this separate from the main app because turning the system off is important if the main app has crashed or hung.
Capturing Keystrokes in GNU/Linux in C This doesn't seem to nicley if there are two apps reading from it. I think, i know evtest won't work with our main app up.
We do not have a window manager. Our only graphical app is Qt5, the other one is a background daemon.
I'm a student on a hogeschool in the Netherlands. We're working with the LEGO Mindstorms NXT for a project.
However, I'm using my phone (minddroid and other applications) to drive the NXT, but I don't know how to simultaneously run a program.
For example, I drive it over a black line with the remote, and because the program is running, the sensor sees in the program that if it drives over a black line, it has to stop.
Is your question how to get the NXT to both communicate on bluetooth and monitor the line at the same time? If so:
Then there are two general solutions:
Main Loop
In your main loop, first check for communications from the bluetooth system, and then check the sensor to see if the black line is detected. Then repeat.
Interrupt
In this solution, the main process would handle communications with the Android phone. The line sensor would be setup to cause a program interrupt when it detects the black line.
The interrupt service routine (ISR) would either set a flag to indicate that the robot should stop or would directly stop the robot.
Choosing which of the above solutions you choose is often dependent on the features of your operating system.
PS It could also be that I'm not understanding your question correctly. In that case, never mind...
No I meant that I wanted to run a program simultaneously with the bluetooth remote.
But I solved it, I connected the nxt with a mobile app, so I could only send direct commands. I solved it by connecting with the program, not the nxt robot.
Thanks anyway!