"freeze" terminal output (/dev/tty1) - linux

I'm writing an application (in java) that directly operates on the framebuffer (/dev/fb0).
When I start my app, the cursor of the currently active console still blinks and if i use keyboard-keys like up/down the console will display the recently used commands and overwrite the framebuffer's content.
I was only able to stop the cursor from blinking:
setterm -cursor off > /dev/tty1
Is there a way to totally freeze (and later unfreeze) the console?
It seems like an X-Server does the same thing. If the boot-process runs on GraphicsCard-1 and the X-Server on GraphicsCard-2, the output on GraphicsCard-1 will stop (no blinking cursor) immediately when X starts. I guess mplayer does this, too if setting video-out to the framebuffer.
thanks for any ideas :)

Strictly speaking, the behaviour that you've observed is more of a bug than a feature. It's down to the fact that Linux isn't properly multi-head. What you're seeing is an effect of the X server switching its own, allocated, virtual terminal onto the console. This of course — because only one virtual terminal can be active at a time system-wide — switches out the virtual terminal that was being displayed, even though it was being displayed on another display adapter entirely.
You have to do some of what the X server is doing, and switch your own virtual terminal onto the console.

openvt(1) allows you to open a program in a new virtual terminal, and chvt(1) allows you to switch to another virtual terminal.

it was a little bit more tricky to get what i exactly wanted:
I have to execute (from shell) 2 commands to get the terminal quiet:
chvt 9
setterm -cursor > /dev/tty9
later one can switch back to terminal 1:
setterm cursor > /dev/tty9
chvt 1
I choose terminal number 9 but any number above 7 should be fine. These calls also work if they are executed from within the java application (as JdeBP said, only one virtual terminal system-wide). Only the setterm command requires some additional steps to pipe the output to /dev/tty9:
Runtime.getRuntime().exec("chvt 9");
pipe("setterm -cursor off", "/dev/tty9");
private static void pipe(String cmd, String file) {
FileOutputStream fos = new FileOutputStream(file);
Process p = Runtime.getRuntime().exec(cmd);
InputStream is = p.getInputStream();
int i;
while ( (i = is.read()) != -1 ) {fos.write(i);}
p.waitFor();
fos.close();
is.close();
}
maybe the pipe() method is not optimal, but it worked for me the way it is.

Related

Linux / X11: disable screen saver programmatically [duplicate]

The question
Is there a method to prevent an X session from starting the screensaver, going into power save mode, or performing a screen blank from code?
What I'm working with
Language: C/C++
GUI framework: GTK3
Hardware: Raspberry Pi 3B
Software: Raspbian 10 - Buster
My program needs to run on screen for long periods (up to 12 hours) with the GUI running without user interaction. The GUI acts as a status monitor for systems in field (if the screen goes black, something went wrong).
What I know
GTK3 can determine if the screensaver is active
GTK3 has a boolean property to report if the screensaver of the system is active (see here), but no other references are made in the documentation.
Raspbian uses screen blanking
Raspbian does not come installed with xscreensaver or other package to control the screen off time. Instead, it relies mostly on X to "blank screen". This can be managed with the xset command as a superuser. The canonical way to do this is reported in the hardware-specific Stack Exchange (here).
End-users cannot be trusted
In my case, the program will be used by folks who are barely computer literate. The result must be user-friendly and not expect the user to ever touch a terminal, let alone to make permanent changes to the startup config of X. While one option would be to distribute the program as a customized Raspbian disk image, I would like to explore other options.
I need to see an example
While there were some places to start using this question, implementing them is problematic. When I attempt to use the following MWE with and without the commented line, nothing happens. I cannot simulate the screen blanking function.
#include <X11/extensions/scrnsaver.h>
int main() {
// XScreenSaverSuspend;
XForceScreenSaver;
usleep(1000000);
return 0;
}
You have to pass parameters to the function:
void XScreenSaverSuspend(Display *dpy, Bool suspend);
#include <X11/extensions/scrnsaver.h>
int main() {
XScreenSaverSuspend (display, True);
usleep(1000000);
return 0;
}
But I don't think you have time to see the result with this program and when program ends the screensaver goes back to its previous state.
For your GTK framework, you can obtain the Display use:
Display *
gdk_x11_display_get_xdisplay (GdkDisplay *display);
Docs here.
For X:
/* use the information from the environment variable DISPLAY
to create the X connection:
*/
Display * dis = XOpenDisplay((char *)0); // or ":0.0"
A hacky, OS-specific solution:
Raspbian does not appear to require super user elevation to modify the xset. Adding the line to the code:
system("xset -dpms");
system("xset s off");
is sufficient to turn off the power management settings and the screensaver.
This is obviously sloppy, and it potentially leaves the OS in an undesirable state if the program breaks before these have a chance to be reset to default values. More elegant answers are encouraged.

'input' function in python script shows carriage return character (^M) in terminal when user presses enter

The script should treat 'enter' as sending the users string but instead it just prints '^M' to the terminal.
I'm not sure why this is happening suddenly, it wasn't happening yesterday. Something has changed about this particular terminal session because if I open a new terminal window it works as expected in that.
Any ideas?
I'm using iterm on Mac (xterm?)
TL;DR: just type the reset command on the OS shell whenever the terminal starts acting funny.
Terminal emulator programs (as iterm) feature complicated internal states in order to provide literally decades of features to allow prettier programs on the terminal.
Terminals started as keyboards that would physically print the typed text into paper, back in mainframe era - and "stdin" and "stdout" concepts: a single stream going forward with all data that is typed and another with all data that is printed out, are up to today, more than 50 years later, the default way to interact with the text terminal.
Internal state changes by programs that deal with the terminal in different ways (like being able to read a keypress without waiting for "enter"), should be reverted when the programs terminate. But due to errors and bugs that is not always the case.
I don't know which possible state would change "ˆM" to be displayed instead of a CR code being applied to the terminal. There are tens or hundreds of other possible misbehaviors, including completely messing up all characters. The reset command in modern *nixes (MacOS, Linux, BSDs) will fix everything.
Although, of course, if "enter" is not being applied, it won't be possible to issue the command at all from the os shell. You will have to start a new terminal session then. From within a Python program, if you happen to make a call to some code that will always break the terminal, you might run "reset" as a subprocess by calling os.system('reset').
In particular, "ˆM" represents "ctrl + M", which is a control character with value "13" (0x0d in hex). It is the value for the "Carriage Return" control code (AKA. "return", "enter", "CR"). If you never did this: try pressing "ctrl+M", and see that it behaves the same as "enter". It is being displayed in "human readable form" instead of acting as a control character in your case.
(regarding xterm and iterm: all they have in common is that they are both "terminal emulator" programs, xterm being one of the oldest existing such programs, which probably pioneered a lot of adaptations from text-only video modes to a graphic environment. "iterm" is just a normal modern app which implements terminal functionality)

How to disable a Virtual Terminal in Yocto Linux

Would anyone know how to disable the virtual terminals in linux? I am using Yocto, Morty version on an i.MX6 processor. Even though our base distribution is Yocto, unfortunately we have diverged from building it with recipes, so this is more of a straight linux question than Yocto…
To give some detail as to my problem: It is for an embedded device that has an HDMI port - when I attach a terminal to the HDMI port it shows the Linux Penguin logo, a getty service and blanks out after 600 seconds. I just want to use the hdmi port as an output with nothing displayed on the output and I want it to stay on all the time.
I have found that the hdmi port maps to /dev/tty1 – when I type: echo “asdfasdf” > /dev/tty1 I see the characters output to the monitor.
Here are a few things I have tried to no avail – a lot of these are not needed if I can figure out how to disable it as a virtual terminal…
• I figured out how to disable the getty service but a cursor still blinks. I don’t even want a cursor to show
• I have tried to disable the display of the penguins by disabling the LOGO in the kernel config parameters - I commented anything with LOGO out:
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
To no avail. The logo still shows : .
• The fact that it blanks after 600 seconds is console blanking – I can see it set to 600 in the file: /sys/module/kernel/parameters/consoleblank. When I issue the command: echo -e '\033[9;0]'>/dev/tty1
It sets the console blanking to 0 and wakes the terminal. Being able to wake the console up is limited success but I would like to disable the virtual terminal altogether…
• I tried commenting out any virtual terminal defines in the config file to no avail:
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
Everything I have read suggests that /dev/tty1 is a virtual terminal or console. From what I read about the VT option, disabling the CONFIG_VT should do it:
VT — Virtual terminal Say yes here to get support for terminal devices
with display and keyboard devices. These are called "virtual" because
you can run several virtual terminals (also called virtual consoles)
on one physical terminal. You need at least one virtual terminal
device in order to make use of your keyboard and monitor. Therefore,
only people configuring an embedded system would want to say no here
in order to save some memory; the only way to log into such a system
is then via a serial or network connection. Virtual terminals are
useful because, for example, one virtual terminal can display system
messages and warnings, another one can be used for a text-mode user
session, and a third could run an X session, all in parallel.
Switching between virtual terminals is done with certain key
combinations, usually Alt-function key. If you are unsure, say yes, or
else you won't be able to do much with your Linux system.
But for some reason it doesn’t do anything!
• I found this thread; https://askubuntu.com/questions/357039/how-do-i-disable-virtual-consoles-tty1-6 among others, but none are much help since my distribution does not have any of the directories in the solutions offered in this thread or any others I have found. For instance I do not have a /etc/events.d nor do I have a /etc/default/console-setup file nor do I have a /etc/init directory… I imagine the reason for this is that my distribution uses systemd and the solutions are SysV based init maybe?
Disabling the logo or console blanking would not be necessary if I could just figure out how to disable that port as a terminal…
So does anyone have pointers or things I could try? I am relatively new (returning after 10 years - I worked with DNX 10 years ago v2.6 and it seems everything I knew about init is fairly obsolete lol) to linux so I am sure I am missing a lot…
Thanks,
- Chuck
I think I found the answer to my question. This is actually a frame buffer console documented here: Documentation/fb/fbcon.txt. From the documentation:
The framebuffer console (fbcon), as its name implies, is a text
console running on top of the framebuffer device. It has the
functionality of any standard text console driver, such as the VGA
console, with the added features that can be attributed to the
graphical nature of the framebuffer.
Commenting out the line
CONFIG_FRAMEBUFFER_CONSOLE=y
In the configuration file located in /arch/arm/configs will disable it.
Also this part of the documentation shows you how to disable it at runtime:
So, how do we unbind fbcon from the console? Part of the answer is in
Documentation/console/console.txt. To summarize:
Echo a value to the bind file that represents the framebuffer console
driver. So assuming vtcon1 represents fbcon, then:
echo 1 > sys/class/vtconsole/vtcon1/bind - attach framebuffer console
to
console layer echo 0 > sys/class/vtconsole/vtcon1/bind - detach framebuffer console from
console layer
When I issue the echo 0 command, the cursor stops blinking and starts blinking again when I issue the echo 1 command.
I think there is another way of doing it as well by modifying the Yocto build environment by putting the USE_VT="0" in the OpenEmbedded machine config file. The "USE_VT" variable is referenced by the sysvinit-inittab recipe. This answer was given to me from the Yocto Linux mailing list - but I have not tested it since we have diverged from Yocto...

How to start new gnome-terminal with blocking call?

I need to open a new terminal from my script but I want to wait for that terminal to exit before continuing with the rest of the script. I know that
gnome-terminal -e 'nano test.txt'
opens a new terminal window with "test.txt" opened in nano, but the calling script does not get blocked. Is there a way to wait for the new terminal to exit, before continuing the original script?
For the benefit of the reader: The answer from #Feiteira used to be the correct answer, but is no more supported by gnome-terminal. Option --disable-factory got removed from gnome-terminal.
To explain the different observation of several people here:
gnome-terminal only blocks, if it is the first instance of it. This single instance then acts as a server for all future invocations of gnome-terminal. Those other gnome-terminal calls then hand everything over to this server and immediately terminate. So you can observe both behavior: "blocking" (when it is the one-and-only single instance) and "nonblocking" (when another instance is already running).
There is a wrapper, for example used by Ubuntu 16.04, which emulates this missing option. However this wrapper is complex. This is done by starting another server (with another service name). And for this server, the same assumption holds (you can attach other gnome-terminals to this server, and those others then come back immediately as well).
My suggestion is to stop using gnome-terminal and to switch to something, which works right out of the box. For example xfce4-terminal officially supports all those little absolutely necessary options for a mature terminal window:
xfce4-terminal --disable-server -x nano test.txt
Also xfce4-terminal introduces --hold which allows you to see the output of a command. Sadly --hold has a bug (at least under Ubuntu 16.04), which causes it to (often) truncate the output (the terminal is closed too early if a command terminates, so all still buffered output of the PTY does not make it to the window. This is a very well known common bug if you are not careful enough with PTYs).
The option you want is: --disable-factory
gnome-terminal --disable-factory ...
You could use && for instance (also see What is the purpose of "&&" in a shell command?):
gnome-terminal -e 'nano test.txt' && sleep 5 && echo "Done"

Characters written in R become invisible after suspending and resuming job

I have a recurrent problem when using R with a Linux console. I sometimes suspend it with [Ctrl+Z], then put it to the background with bg, (execute some other commands), then put it to the foreground again with fg.
R resumes correctly with all the workspace intact, but when I type, the characters are invisible (just like when we type passwords).
I still can execute commands though, and I see the response. Moreover, when I type [enter], the prompt doesn't go to the next line, but does something like this: > > >.
Then I need to quit R using q(), in order that everything returns to normal. I didn't manage to find any reference to this problem on internet.
Would you have an idea? Thanks a lot for your help.
No direct answer but via
"Doctor, doctor, it hurts when I do this."
"Then just don't do this."
I would suggest that if you must have an R console open, place it inside screen --- or if you have it, byobu a fancier extensions, or even tmux.
Or even inside the One True Editor (TM) using ESS. For what it is worth, I always run emacs --daemon and then connect to the same R session either via emacsclient -nw on the terminal or under X11 via emacsclient -c (both of which I aliased to emt and emx). I also run byobu sessions for command-line work where I often use littler for command-line tasks and tests.
Unix is a multitasking system. There is no need to limit yourself to one prompt, especially if you suffer side-effects as a consequence.

Resources