How does one make console screenshots?

AllanTheBrummie · Mar 17, 2022

SirDice said:
Does the server have IPMI? Modern IPMI console access has a record/screenshot option. If it hasn't you could still make a screenshot of the console window. It's going to be a bitmapped screenshot but you can probably convert those to SVG using ImageMagick.

Thanks SirDice... Lovely idea but this is a low budget minimum hardware project.... I'm using a gaming motherboard/AMD 2500 cpu/lto7 drive to assemble a backup machine for all my other kit...

Cath O'Deray · Mar 18, 2022

scottro said:
I see that I use to do (but haven't tested in years) opening another terminal, for example, using alt+F3, I would then use

vidcontrol -p < /dev/ttyv0 > shot1.scr
…

Inappropriate ioctl for device – am I missing something?

Code:

root@mowa219-gjp4-8570p-freebsd:~ # cat typescript
Script started on Fri Mar 18 15:52:43 2022
root@mowa219-gjp4-8570p-freebsd:~ # vidcontrol -p < /dev/ttyv0 > shot.scr
0H7I7F0Gvidcontrol: dumping screen: Inappropriate ioctl for device
root@mowa219-gjp4-8570p-freebsd:~ # exit
exit

Script done on Fri Mar 18 15:53:03 2022
root@mowa219-gjp4-8570p-freebsd:~ #

blind0ne · Mar 18, 2022

Try camera or capture card.

ralphbsz · Mar 18, 2022

grahamperrin said:
Inappropriate ioctl for device – am I missing something?

In a nutshell, your console driver (vt or sc a.k.a. syscons) does not support the CONS_SCRSHOT ioctl. The error message "inappropriate ioctl" (which used to be called "not a typewriter" and still has the error code ENOTTY) simply means that a device has no entry for a handler function in the table of ioctls. It happens for example if you send the ioctl for "eject page" to a disk drive, or the ioctl for "turn caps lock light on" to a printer.

Now, which console driver are you running? Does it always, sometimes, or never support taking screenshots? If it is "sometimes", what do you need to do to make it happen? This is where a half hour long trip into the source code is probably required. But as a first attempt: You can switch between the vt and sc drivers (in the loader config), try that. It might have other side-effects that are much worse than not getting screen shots.

scottro · Mar 18, 2022

Possibly useful to mention that when I did this, it was on DragonFlyBSD and done around 2005 or so. Found this by checking my old notes, which I hadn't done previously.

astyle · Mar 18, 2022

schweikh said:
Should these options not exist, your xterm was not compiled with option SCRNDUMP enabled

This is one reason why I compile ports instead of using pkg. Oh, and if you use a VM, on your personal machine, the host should offer screenshot capabilities. Heck, if you SSH in, you can just take a dump of your PowerShell window

mark_j · Mar 18, 2022

Use screen then do a hardcopy? Couldn't be easier (or messier if there's a ton of ANSI

)

hardworkingnewbie · Mar 18, 2022

Use textproc/py-asciinema. This is an ASCII screen recorder.

When you need a screenshot: playback your recording, pause it where necessary and make a copy. Bam, job done.

Record and share your terminal sessions, the simple way - asciinema.org

asciinema.org

jb_fvwm2 · Mar 18, 2022

ralphbsz said:
In a nutshell, your console driver (vt or sc a.k.a. syscons) does not support the CONS_SCRSHOT ioctl. The error message "inappropriate ioctl" (which used to be called "not a typewriter" and still has the error code ENOTTY) simply means that a device has no entry for a handler function in the table of ioctls. It happens for example if you send the ioctl for "eject page" to a disk drive, or the ioctl for "turn caps lock light on" to a printer.

Now, which console driver are you running? Does it always, sometimes, or never support taking screenshots? If it is "sometimes", what do you need to do to make it happen? This is where a half hour long trip into the source code is probably required. But as a first attempt: You can switch between the vt and sc drivers (in the loader config), try that. It might have other side-effects that are much worse than not getting screen shots.

Just learned about "ioctl". Having received that error message many times with trying to fix wifi drivers, and probably elsewhere, I think it would be useful for the message to also print which ioctl was requested and what device lacked it within its table.

astyle · Mar 18, 2022

hardworkingnewbie said:
Use textproc/py-asciinema. This is an ASCII screen recorder.

When you need a screenshot: playback your recording, pause it where necessary and make a copy. Bam, job done.

Record and share your terminal sessions, the simple way - asciinema.org

asciinema.org

sounds like a pain in the ass to deal with

Just try pronouncing it yourself.

Cath O'Deray · Mar 19, 2022

ralphbsz said:
… as a first attempt: You can switch between the vt and sc drivers (in the loader config), try that. It might have other side-effects that are much worse …

sc was certainly a problem when I tried it with an HP ZBook 17 G2 in ~~July~~ March 2021. I kept a comment in the file:

Code:

% grep -B 4 -A 1 kern.vty /boot/loader.conf

# <https://old.reddit.com/r/freebsd/comments/m4w2fs/-/gr1c3ba/>
# <https://lists.freebsd.org/archives/freebsd-current/2021-July/000402.html>
# sc is no good with n248269-941650aae97 on an HP ZBook 17 G2
# kern.vty="sc"

%

Probably with the NVIDIA GPU alone at the time.

Cath O'Deray · Mar 20, 2022

As I suspected, kern.vty="sc" also causes a blackout with AMD Thames [Radeon HD 7550M/7570M/7650M] in an HP EliteBook 8570p.

I'm not concerned. For me it's easier to use VirtualBox, or a camera.

Hiroo Ono · Feb 12, 2024

Sorry to reply to an old thread.
I implemented CONS_SCRSHOT with vt ( https://reviews.freebsd.org/D40858 ), but could not convince that it is useful enough to create two new ioctls. Is there any reasoning that can convince the committers to adapt it?

Kai Burghardt · Feb 12, 2024

Hiroo Ono said:
[…] I implemented CONS_SCRSHOT with vt ( https://reviews.freebsd.org/D40858 ), […]

No, you have not. If I’m not mistaken, ioctl(STDIN_FILENO, CONS_SCRSHOT, …) will still fail with an inappropriate I/O control error if file STDIN_FILENO is connected to a video terminal (vt(4)).

Hiroo Ono said:
but could not convince that it is useful enough to create two new ioctls. Is there any reasoning that can convince the committers to adapt it?

Do any of the new I/O controls preserve the currently loaded font? Do the screenshots preserve screen information (e. g. the screen size)? Are screenshots machine‑readable (for instance, like DjVu text annotations)?

Hiroo Ono · Feb 12, 2024

Kai Burghardt said:
No, you have not. If I’m not mistaken, ioctl(STDIN_FILENO, CONS_SCRSHOT, …) will still fail with an inappropriate I/O control error if file STDIN_FILENO is connected to a video terminal (vt(4)).

In fact, the patch imprements two new ioctl so that we can dump from 1) vt text buffer or 2) vt image buffer. It is not CONS_SCRSHOT itself.

Kai Burghardt said:
Do any of the new I/O controls preserve the currently loaded font? Do the screenshots preserve screen information (e. g. the screen size)? Are screenshots machine‑readable (for instance, like DjVu text annotations)?

CONS_VTSCRSHOT_TEXT dumps from text buffer. The vt(4) fb's text buffers are per tty, so one can dump text connected to each tty. As it is from the text buffer, it does not preserve the font.
CONS_VTSCRSHOT_GRPH dumps from image buffer so one can get the 'image' shown on the monitor. But, there is only one vt(4) fb's image buffer, so one get what he is seeing on the monitor.
Example of CONS_VTSCRSHOT_GRPH is here: https://mastodon.social/@hiroo3/110654371649316225 (to take this picture, I needed to do the trick of sleep 3; vidcontrol ... and switch the window, so that bsdconfig is shown on the window at the time of grabbing).

Hiroo Ono · Feb 12, 2024

Forgot to write that, when one dumps the text, it is machine readable, but if one dumps the image, it is just an image.

astyle · Feb 12, 2024

Hiroo Ono said:
Forgot to write that, when one dumps the text, it is machine readable, but if one dumps the image, it is just an image.

And when one dumps a screen, that's hazardous chemicals leaking into the ground...

unitrunker · Feb 12, 2024

This looks very useful. How many times has someone posted camera-phone quality screenshots that we all must squint to read the text? This will be much, much better.

@hiroo-ono.57448 - I have no sway with the reviewers but I do have four suggestions.

1. In your test plan, describe in detail how the code was tested.
2. Include attachments of text and image screen shots.
3. Start a new thread here - something like a "call for testing" for your patch.
4. Add some "guard" code that refuses to return screen shots for untested types of frame buffers.

That should buy you some interest and attention.

I think you answered the "why" question in the patch review very well.

Alex Seitsinger · Feb 13, 2024

Code:

vidcontrol -P < /dev/ttyvX > shot.scr

See vidcontrol(1)

bgroper · Feb 15, 2024

If your server has ssh enabled, just connect to the server from another host which has a GUI interface (eg KDE plasma, and konsole) and capture the screen in the GUI (ksnapshot or spectacle, or other).
YMMV

Charlie_ · Feb 15, 2024

Alex Seitsinger said:
See vidcontrol(1)

Code:

-P Supported only with syscons(4).

Since 2014, vt(4) is the default.
See Comment #38 for vt(4).

Hiroo Ono said:
I implemented CONS_SCRSHOT with vt ( https://reviews.freebsd.org/D40858 )

Code:

Summary
Screenshot with vt(4) is implemented. Used like
vidcontrol -p text < /dev/ttyv0 > screenshot.txt