On Mon, Apr 12, 2021 at 12:15 AM Linus Torvalds torvalds@linux-foundation.org wrote:
On Sun, Apr 11, 2021 at 2:43 PM Maciej W. Rozycki macro@orcam.me.uk wrote:
So it does trigger with vgacon and my old server, which I have started experimenting with and for a start I have switched to a new kernel for an unrelated purpose (now that I have relieved it from all its usual tasks except for the last remaining one for which I haven't got the required user software ported to the new system yet):
"struct vt_consize"->v_vlin is ignored. Please report if you need this. "struct vt_consize"->v_clin is ignored. Please report if you need this.
Note that it's entirely possible that things continue to work well despite this warning. It's unclear to me from your email if you actually see any difference (and apparently you're not able to see it right now due to not being close to the machine).
Original search didn't turn up any users of VT_RESIZEX, this is the first. And looking at the source code I think we could outright remove support for VT_RESIZEX (but make it silent) and everything should keep working:
/* * ALWAYS do a VT_RESIZE, even if we already did a VT_RESIZEX on a 1.3.3 or higher kernel, * until those kernel programmers make this unambiguous */
if (do_VT_RESIZE(curr_textmode->cols, curr_textmode->rows, resize1x1)) sresize=TRUE;
if (check_kernel_version(1,3,3, "VT_RESIZEX")) { /* * VDisplay must de divided by 2 for DoubleScan modes, * or VT_RESIZEX will fail -- until someone fixes the kernel * so it understands about doublescan modes. */ if (do_VT_RESIZEX(curr_textmode->cols, curr_textmode->rows, curr_textmode->VDisplay / (MOFLG_ISSET(curr_textmode, ATTR_DOUBLESCAN) ? 2 : 1), curr_textmode->FontHeight, curr_textmode->HDisplay/8*curr_textmode->FontWidth, curr_textmode->FontWidth, resize1x1)) sresize=TRUE; }
The functions are just straightforward wrappers. There's also no cvs repo, changelog or old releases before 2000 that would shed some light on why this code even exists.
I think we can just tune down the pr_info_once to pr_debug and done. Maybe a comment about where the single user we're aware of is. -Daniel
The fact that v_vlin/v_clin are ignored doesn't necessarily mean that they are different from what they were before, so the warning may be a non-issue.
It continues using svgatextmode with its glass (CRT) VT to set my usual 80x37 text mode (720x576 pixel resolution) by manipulating the VGA clock chip and the CRT controller appropriately for a nice refresh rate of 85Hz:
Chipset = `TVGA8900', Textmode clock = 44.90 MHz, 80x37 chars, CharCell = 9x16. Refresh = 52.51kHz/84.7Hz.
That doesn't seem necessarily wrong to me.
So what's the supposed impact of this change that prompted the inclusion of the messages?
There _may_ be no impact at all apart from the messages.
The code _used_ to set the scan lines (v_vlin) and font height (v_clin) from those numbers if they were non-zero, and now it just ignores them and warns instead.
The code now just sets the font height from the actual font size when the font is set. Which is honestly the only thing that ever made sense. Trying to set it with v_clin is ignored, but it's entirely possible - maybe even likely - that your user of VT_RESIZEX sets it to the same values it already has.
Exactly because setting a font line number to anything else than the font size isn't exactly sensible.
But if your screen looks different than it used to, that is obviously interesting and says something actually changed (outside of the message itself).
Linus
dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel