Solved Help with vidcontrol

This may not be the right place for this, so if not please some administrator move it to where it should be and let me know where that is ... thanks!!

I am using vidcontrol to change the text color of my console depending on a number of factors, eg. who I am logged in as, where I am logged in from, how I accessed the machine, and so on. As part of this effort I want to determine the present color setting for the text "programatically", specifically for use in a further script. Is there a way to read this? I am seeking some functionality to operate similarly to xtermcontrol --get-fg when running an xterm under Xorg, but for use on the console on a machine without Xorg installed, ie. running "pure console mode".

Thanks in advance for any and all constructive suggestions!!
 
With vt(4) mode, it is currently impossible.
The console info is gotten by vidcontrol's init() function by CONS_GETINFO ioctl in struct vid_info in /usr/include/sys/consio.h, and it has member of struct colors.
But in sys/dev/vt/vt_core.c, CONS_GETINFO is implemented as
Code:
        case CONS_GETINFO: {
                vid_info_t *vi = (vid_info_t *)data;
                if (vi->size != sizeof(struct vid_info))
                        return (EINVAL);

                vi->mv_rsz = tm->tm_winsize.ws_row;
                vi->mv_csz = tm->tm_winsize.ws_col;
                vtbuf_lock(&vw->vw_buf);
                vi->mv_hsz = vw->vw_buf.vb_history_size;
                vtbuf_unlock(&vw->vw_buf);

                if (vw == vd->vd_curwindow) {
                        mtx_lock(&Giant);
                        if ((kbd = vd->vd_keyboard) != NULL)
                                vt_save_kbd_state(vw, kbd);
                        mtx_unlock(&Giant);
                }

                vi->m_num = vd->vd_curwindow->vw_number + 1;
                vi->mk_keylock = vw->vw_kbdstate & LOCK_MASK;
                /* XXX: other fields! */
                return (0);
        }

As you see, the information of colors is not passed to userland.
 
Sorry, no constructive suggestion for how to make it work with vt or sc consoles and vidcontrol.

But here is a suggestion for a totally different approach: Instead of changing the terminal emulator itself (which is not standardized, you have to do it differently for xterm, FreeBSD consoler, Linux console, ...), use the ANSI escape sequences that de-facto every terminal emulator implements (including the consoles). For example, output the string "esc [ 3 1 m" (with no spaces and escape replaced by a real escape character), and everything printed from now on will be red. Try "esc [ 3 2 ; 4 3 m", and everything will be green on a yellow background (which looks awful). You get at least 8 foreground and background colors (some terminal emulators can do even more, with 256 or even 2^24 colors). And the best thing: the implementation works on every VTxxx-compatible terminal.

Caveats: (a) things that look good on a white background may look ugly on a black background. (b) Many combinations are nearly unreadable due to lack of contrast; which ones are good depends on display hardware and the individual person. (c) Colorized programs (such as editors in syntax coloring mode or colorized ls) will mess up the setting.

I use this technique to colorize my shell prompt, so I can see immediately what machine I'm on (green and black mean my normal production machines, other colors mean unusual locations), and whether I'm root (red background). By constraining it to the shell prompt, the problem (c) from above doesn't happen so badly.
 
I don’t think it’s very practical but could you use the dump screen option of vidcontrol and then read that back in and figure out the colours that way?

You might have to write a string of characters you can search for to be sure e.g. write out ~~~ or whatever, dump the screen, read it back in, find the ~s and figure out their colours from the attribute bytes?
 
With sc(4), it is possible, but sc(4) does not work with UEFI system. So, it is limited to the old system using BIOS. (I do not know about platforms other than amd64 and i386)
 
Thanks for some good replies ... unfortunately, they pretty much confirmed what I suspected, namely not too practical for shell scripting but suitable for full up program. The down side is this is indeed a UEFI system else sc(4) would have been very tempting. I can see some good benefits to the escape sequences and will look into using them in the future. Parsing a screen dump in any general sense seems a bit much for a script to handle, but may be useful later.

Appreciate the suggestions and we shall see what comes next. ;)
 
Parsing a screen dump in any general sense seems a bit much for a script to handle, but may be useful later.
As Hiroo Ono said, it's not going to work.

And if you try -p or -P you get an error message and a help display where those options are missing, so the man page seems to be out-of-sync with the program.

So it goes from "not very practical" to non-starter.
 
Back
Top