Bug 43167

Created attachment 53772 [details]
Typical Xorg log with vesa driver

Created attachment 53773 [details]
xorg.conf for intel driver

Created attachment 53774 [details]
evdev configuration

The complaint appears to be that after replacing vgacon with fbcon on a different mode (hopefully the native mode) the console has understandably a different ncolumns x nrows and this change is not being propagated to userspace. This is a side-effect of X using KMS and the DRM console taking over and even an Intel specific kernel bug.

Hi Chris,

Thank you for your insightful comments.

I've made some tests with some interesting results you might want to take a 
look at.
I ran the tests on a "clone" (back-up) of my main, problem drive/system
 (about 2 weeks behind).

For reference:
 Problem system, as reported:
  kernel-3.1.1
  xorg-server-1.11.2
  xf86-video-intel-2.17.0
  xf86-input-evdev-2.6.0
  xterm-276

 Baseline test system (the "clone"):
  kernel-3.0.4
  xorg-server-1.11.1
  xf86-video-intel-2.16.0
  xf86-input-evdev-2.6.0
  xterm-276
 (NOTE:  works OK as far as the subject bug is concerned)

Below, each basic test/step is numbered in chronological sequence.
Legend:
 OK = console text line wraps around normally (correctly - to next row)
 PROBLEM = console text line wraps around incorrectly to same row
           (i.e., the subject of this bug submission)

To me, as a layman, the culprit is solely the >3.0.4 kernel (surprise?).

1.  Upgraded to (installed) 3.1.0 -> PROBLEM
2.  Changed back to 3.0.4 (moved the symlinks in '/boot') -> OK (of course)
3.  Installed xorg-server-1.11.2 -> OK
4.  Reinstalled xf86-input-evdev-2.6.0 -> OK
5.  Reinstalled xf86-video-intel-2.16.0 -> OK !
6.  Installed xf86-video-intel-2.17.0 -> OK !
7.  Switched to 3.1.0 -> PROBLEM

COMMENTS
 Please note I'm just reporting what I see.  I have no idea what changes
 to the kernel were made between 3.0.4 and 3.1.0, if they have been
 necessary and I'm just a collateral damage to the inexorable progress of
 technology, if they can be reverted (i.e., recognized as bugs), etc., etc.
 I cannot do anything at this point (like submitting a _kernel_ bug, etc.).
 I'm just one of the 99% :(

Regards,
-- Alex

Created attachment 53823 [details]
Xorg log with intel 2.16.0 on 3.0.4

Created attachment 53824 [details]
Xorg log with intel 2.17.0 on 3.0.4

Can you grab a photograph of the wraparound? I'm thought you meant line wrapping (because of the suggestion of NCOLUMNS) however, I wonder if you mean something else as I can't think off-hand what may have changed between 3.0.4 and 3.1 other than a more severe modesetting regression.

I'll publish the pictures shortly.
Meanwhile, maybe I've been using the wrong terminology or just plain silly
description, but here I go again:

Assume my case where the no of columns are 80 (and rows 25) on the text/command
screen (like in the good ole days, ~ >=1980).
When you type something and you reach the end of screen (what vi calls col 80, the chars you continue to type are echoed on the NEXT line (row).
Then the NEXT line if you type beyond 160 chars overall and so on.
I've been calling that correct "wraparound".

For the PROBLEM bug reported, after I reach col 80 and continue to type, the
following chars start "wrapping around" on the SAME line, starting at col 1,
thus starting to overwrite (as if erase) the original text.

BTW, in both cases the "max. 80" includes the "prompt" or whatever existed on
the original first line).

The way I interpret the phrase "to wrap around text", there's wraparound in both
cases except that the text go to next line in the first case (the correct, expected behavior) while in the second the text just stays on the same line forever.
True, in real life when you say "she came out wrapped (around) in a towel"
people assume (and the lady most likely intends) the towel to be wrapped on the _same_ horizontal plane (unfortunately:).

Created attachment 53825 [details]
Correct wraparound:  just after boot to console/text mode

Created attachment 53826 [details]
PROBLEM:  after going to X and back to console

Chris,

Two pictures, one without the PROBLEM, the other with.
Don't expect Michelangelo but at least you can see that where the PROBLEM
is active,
- there's overlap (overwriting)
- missing characters (at least as echo of them)
- COLUMNS is messed up

Please note, on my test system discussed above (3.0.4) you NEVER have these anomalies, before and/or after going to X.
The text (command) line just wraps around CLEANLY to NEXT row at all times.

Thanks,
-- Alex

Wow, you were correct in your original description. That is bizarre and as far as I know not caused by i915.ko. If you can bisect the kernel to identify the regression that would be extremely useful.

Created attachment 53854 [details]
Kernel 3.0.4 (good)

Created attachment 53855 [details]
Kernel 3.1.0

This comment is intended as a final, concise pictorial description of the
console text mode BUG introduced by a linux kernel change somewhere between
3.0.4 and 3.1.0.
In retrospect, the bug appears to be caused by the kernel code and not
by the intel driver as originally implied by me.

The problem is evident on kernel 3.1.0 in console text mode after returning
from graphics (X) mode.  On 3.0.4, everything is normal (i.e. correct).

The two pictures attached show a text mode screen of a "baseline" system,
with the following constant features (the only changed parameter was the
kernel version, first 3.0.4 then 3.1.0),

HARDWARE
 Board: "ASUS P5E-VM HDMI" with Intel G35/ICH9R
 Monitor: Samsung SM2494, Wide (16:9), DVI input (HDMI->DVI cable)

SOFTWARE
 (B)LFS i686-pc-linux-gnu, Udev-173, Xorg-7.6 with
  xorg-server-1.11.2        (latest, as of this writing)
  xf86-video-intel-2.17.0   (latest, as of this writing)
  xf86-input-evdev-2.6.0    (latest, as of this writing)

Created attachment 53868 [details]
Problem shows up on 3.1.2 as well

Problem (bug) is unchanged on kernel 3.1.2 (latest) :(

Created attachment 53873 [details]
3.0.9, the last kernel version without the Bug

On a look this seems to be a funky bug in the linux vt system (or maybe fbcon). Please report this issue with the vt kernel subsystem, preferably with a bisect of the kernel to the offending commit (should be simple, but time-consuming to dig out).

Pardon for not being able to help for this one, closing this as notourbug.

Hi Daniel:

Seems Chris Wilson had a point when he made these changes
(on 2012-02-08 07:12:55 PST):

Assignee: Chris -> Daniel
Product: xorg -> DRI
Component:  Driver/Intel -> DRM/Intel

------
I have no idea what "NOT OUR BUG" means as far as your responsibilities
are concerned (and who "OUR" folks are) but
after bisecting the kernel to death, I see there's a lot of talk about
DRM (and only about DRM) all the way to the bitter end.
So, please try to make some more meaningful comments before you'd
quickly dismiss the problem by throwing it back into my innocent hands.
-- Alex

To summarize the whole situation:

GOOD wraparound = on a 80-column screen, if overall text (prompt + command)
 exceeds 80 characters, the line wraps around to NEXT row.
 Normal/expected behavior, on ANY Linux from v2.4 to v3.0.20 and on any
 X11 (XFree86-4.5 to Xorg-7.6)

BAD wraparound = on a 80-column screen, if overall text (prompt + command)
 exceeds 80 characters, the line wraps around to SAME row.  The object of
 this bug submission (43167).

v3.0.20 last 3.0.x version before v3.1

v3.0.20 - last GOOD wraparound (as I said, since v2.4 or so)
v3.1 - first BAD wraparound (continues the same up to current v3.2.5)
===============================================================================
BISECT excerpts (as of today, 2/9/2011)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git \
 linux-git
alex[~]% cd linux-git
alex[~/linux-git]% git bisect start
alex[~/linux-git]% git bisect bad v3.1
alex[~/linux-git]% git bisect good v3.0.20
fatal: Needed a single revision
Bad rev input: v3.0.20
alex[~/linux-git]% git bisect good v3.0
Bisecting: 4334 revisions left to test after this (roughly 12 steps)
[138051659902da7e6a09d379fee5dade2a80fcfd] Merge branch 'staging-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6

...

After about 8 iterations (git bisect good/bad; recompile):

[/home/alex/linux-git]$ git bisect bad
Bisecting: 37 revisions left to test after this (roughly 5 steps)
[bcff25fc8aa47a13faff8b4b992589813f7b450a] mm: properly reflect task dirty
limits
in dirty_exceeded logic
--------------------------------------------------------------------------------
[/home/alex/linux-git]$ git bisect good
Bisecting: 18 revisions left to test after this (roughly 4 steps)
[250bae8be0177fcc1435cb46d1aba7e40a0366b2] ktest: Fix bug when ADD_CONFIG is
set but MIN_CONFIG is not
-------------------------------------------------------------------------------
[/home/alex/linux-git]$ git bisect good
Bisecting: 9 revisions left to test after this (roughly 3 steps)

[edc02bffbdcd92086f5cc9d715143e51acfa90ee] drm/radeon: Fix the definition of
RADEON_BUF_SWAP_32BIT
-------------------------------------------------------------------------------
[/home/alex/linux-git]$ git bisect bad
Bisecting: 4 revisions left to test after this (roughly 2 steps)
[04fee895ef98ffbb91a941b53a92d6949bb6d1c4] DRM: clean up and document parsing
of video= parameter
-------------------------------------------------------------------------------
[/home/alex/linux-git]$ git bisect bad
Bisecting: 1 revision left to test after this (roughly 1 step)
[0aff47f29337d1c23060eb1cea7801dfee0e0e4a] drm: really make debug levels match
in edid failure code
-------------------------------------------------------------------------------
[/home/alex/linux-git]$ git bisect good
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[ee2762916f5594e60d8789593f149ed83b560cf7] DRM: Radeon: Fix section mismatch.

Note: I am at "v3.0.0-rc7+" at this point

Thanks again for your consideration,
-- Alex

Hm, looks like I'm blind because I can't find the result of your bisect (i.e. the first bad commit). Also please double-check whether this is indeed the culprit by reverting that commit on top of the version you've originally noticed the issue, i.e.

$ git checkout v3.1

$ git revert <sha1-of-first-bad-commit>

The compile and test.

Hi Daniel,

Please give me more details about where you start to differ
from my results, etc.
(after all, as you said, this is "time-consuming to dig out")

Let's see where we lose our sync:

1.  Do you agree with my first step?
(git clone git://git.kernel.org/ ...

2.  If you do (I can repeat it - although it's really time consuming)
what's the iteration you start differing from mine?

If its before the first step I started showing in detail,
"Bisecting: 37 revisions left to test after this (roughly 5 steps)
[bcff25fc8aa47a13faff8b4b992589813f7b450a] ..."
I'll be in trouble because I really have to repeat and detail
the whole procedure

3.  I'm a little confused about your "the first bad commit" statement.

There were quite a few "bad" commits (from my stand point - as exemplified
by the last steps, fully shown).  I may be wrong, but IMHO that's the whole
point of the "dissection":  to see on which side of the "cut" the 
"bad" lies.

Maybe I'm missing something, but one allows the bisect procedure to run it's
course (like I did) where, at the end, it converges completely,
i.e. "0 revisions left to test after this (roughly 0 steps)".

4.  So I don't miss the forest from the trees, in my particular kernel problem
the kernel is always "good" in the sense that it doesn't crashes or such,
but it exhibits _or not_ the "wraparound" bug.
So, put it another way, to my way of thinking, "bisect good" vs. "bisect bad"
means current "good-wraparound" kernel vs. current "bad-wraparound" kernel
respectively.

Thanks,
-- Alex

Well from the bisect log you've posted everything looked good, safe that you've left out the last step. You need to also compile and check the last kernel (when it says "0 revisions left to test after this (roughly 0 steps)") and tell git with git bisect good/bad whether it works.

Git bisect will then spit out the first bad commit. Note the sha1 and do the double-checking as I've described in my previous commmit.

Afaics everything else sounds correct.

Daniel, now we're talking!

Yesterday, I forgot to include what you call the "result".  Sorry.

[/home/alex/linux-git]$ git bisect good

04fee895ef98ffbb91a941b53a92d6949bb6d1c4 is the first bad commit
commit 04fee895ef98ffbb91a941b53a92d6949bb6d1c4
Author: Rolf Eike Beer <eike-kernel@sf-tec.de>
Date:   Wed Jun 15 11:27:02 2011 +0200

    DRM: clean up and document parsing of video= parameter

    The video= parameter of the DRM drivers supports some additional flags that
    the normal fb drivers do not have. They also allow to limit these flags to
    specific outputs. Both things were previously undocumented.

    Also the parsing of the line had some oddities:
    -A lot of misplaced options were silently ignored or partly rejected
     instead of stopping the parsing immediately
    -The 'R' option is documented to follow the 'M' option if specified.
     It is not documented that 'M' is needed to specify 'R' (also this is the
     case for normal fb drivers).
     In fact the code is correct for normal fb drivers but wrong for DRM ones.

     The old code allowed 'R' only _before_ 'M' (since it parses backwards)
     and only if 'M' is given at all which is not needed for the DRM drivers.
    -the margins option ('m') was parsed but later ignored even if the later
     functions support it.
    -specifying multiple enable options at the same time did not lead to an
     error.
    -specifying something bogus for horizontal resolution (i.e. other things
     as digits) did not lead to an error but an invalid resolution was used.

    If any errors are encountered the position of the faulting string is now
    printed to the user and the complete mode is ignored. This gives much
    more consistent error behaviour.

    I also removed some useless assignments and changed the local flag
    variables to be bool.

    Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

:040000 040000 98d77a7d3c99497465df6f5c33bd1e302b961ddd 70ab4faf3d7dafc0abe2dcb1907083c50c3c5624 M      Documentation
:040000 040000 d2a5596a7d99b224c58d386c90fe98357b1df0c6 6ae1f7198a7b6e2ab95992ddfccb332244a18230 M      drivers


Thanks for your help and patience,
-- Alex

Ok, just to confrim: Have you tried to revert this commit on top of 3.1 like I've described?

And please attach your complete dmesg after bootup has completed.

> Have you tried to revert this commit on top of 3.1 like I've described?

No.  What you see in "alupu 2012-02-09 18:50:17 PST" comment,
From the line
"git clone git://git.kernel.org/pub/scm/... "
to the line
"[ee2762916f5594e60d8789593f149ed83b560cf7] DRM: Radeon: Fix section mismatch."

then

in "alupu 2012-02-10 14:47:47 PST" comment,
From the lines
"[/home/alex/linux-git]$ git bisect good
04fee895ef98ffbb91a941b53a92d6949bb6d1c4 is the first bad commit"
to the line
":040000 040000 d2a5596a7d99b224c58d386c90fe98357b1df0c6 6ae1f7198a7b6e2ab95992ddfccb332244a18230 M      drivers",

is the complete, one-shot sequence of git=bisect trouble-shoot.

Note:  As I said, I did not publish the eight or so iterations
"After about 8 iterations (git bisect good/bad; recompile)"
as just being repetitive and a clutter to the whole log out.

To put it yet another way, I did NOT tried to
"revert this commit on top of 3.1" because I have not feel a need to.
Like I said, the bisect procedure I described completed fully, in one single
shot with the happy ending
"04fee895ef98ffbb91a941b53a92d6949bb6d1c4" text.

------

> please attach your complete dmesg after bootup has completed.

Of this GOOD (from my stand point) release?:

uname -a
Linux AlexLFS 3.0.0-rc7+ #1 SMP Thu Feb 9 20:46:31 EST 2012 i686 i686 i386
GNU/Linux

or
of the 3.0.20 release, the last GOOD that a regular user (like me) can see when they use the official, point releases?

Created attachment 56937 [details]
The "official" git bisect log

Created attachment 56938 [details]
The boot-up log on the first "bad" (Bug 43167) kernel

Hi Daniel,

I ran your request,
git checkout v3.1
git revert 04fee895ef98ffbb91a941b53a92d6949bb6d1c4

The resulting kernel, identified as "3.1.0+" has the BAD wraparound
(i.e., contains the "43167" bug.)

The previous kernel, on which I was left at the end of the bisect
procedure, identified as "3.0.0-rc7+", has the GOOD wraparound,
as I mentioned in previous posts.

I'm attaching the '.git/BISECT_LOG' for complete reference of my original
tests (contains the missing ~8 iterations:).

I do have a question of my own, if I may.
Which kernel version was the above commit (04f ... 1c4) included in?
I searched up and down (_not_ exhaustively) in some 'ChangeLog's at kernel.org
and I failed to find it mentioned.
Is there a quick "git" search on a particular SHA1 tag?

-- Alex

> --- Comment #27 from alupu@verizon.net 2012-02-12 17:00:49 PST ---
> Created attachment 56938 [details]
>   --> https://bugs.freedesktop.org/attachment.cgi?id=56938
> The boot-up log on the first "bad" (Bug 43167) kernel
> I ran your request,
> git checkout v3.1
> git revert 04fee895ef98ffbb91a941b53a92d6949bb6d1c4
> 
> The resulting kernel, identified as "3.1.0+" has the BAD wraparound
> (i.e., contains the "43167" bug.)
> 
> The previous kernel, on which I was left at the end of the bisect
> procedure, identified as "3.0.0-rc7+", has the GOOD wraparound,
> as I mentioned in previous posts.

Well, that means that the bad commit isn't actually causing your issues.
This means that either
a) something in your bisect went wrong (very likely and also happens to
experienced bisecters like me).
b) there's another bad commit

Now I've noticed that you've added video=640x400M@70m Can you explain why
you've added this and what happens if you just drop this?

I did another BISECT from scratch.
I started with a brand new "clean" clone.

For some reason (probably inexperience), I got the same result as before:

 commit 04fee895ef98ffbb91a941b53a92d6949bb6d1c4 is BAD

I'm attaching two files,
'my_bisect_log.txt' - a detailed log (by hand) of what I did)
 
'BISECT_LOG' - the automatic GIT log (for reference)

If you still have doubts about what I did,
1.  Please express them clearly and precisely.
2.  You can reproduce my steps (to see where we lose "sync")
    by cloning the repo like I did (as detailed in 'my_bisect_log.txt')
    and then artificially do the "good"s and "bad"s at the points I did.
    That way, you can tell me _exactly_ where and if I went wrong.

Thanking you in advance,
-- Alex

Created attachment 57001 [details]
Display log of bisect procedure

Created attachment 57002 [details]
Git log of bisect procedure

Created attachment 57005 [details]
Amended file

"Improved" file, added missing last section:

Bisecting: 0 revisions left to test after this (roughly 0 steps)
[ee2762916f5594e60d8789593f149ed83b560cf7] DRM: Radeon: Fix section mismatch.
 ...

Issues like you've describing and as shown in the screenshots are problem of the fb kernel console. As long as the pixel show up on screen, drm/i915 does what it should do. The fb console provided by drm/i915 is not hw accelarated at all, so any issues you're seeing are not our bug. Please file this one against the kernel fb driver at bugzilla.kernel.org

Daniel:

I've been having a problem with you in discussing any "issues"
in a logical manner.
Please, for once, try to go over my comments slowly and respond logically,
clearly and directly to the numbered items below.
It took you 3 (three) months to respond to my last comment, so, please take
your time to understand the issues, my questions and statements.
If you have difficulties with the English language, you can ask for help, or
switch to another one (like French or German - ".ch"?), _we_ can
accommodate you, no problem.  You _don't_ have to speak English.

1.  I did _exactly_ what you asked me to do.  Twice.  The hard way.
To BISECT so one can find out where/when exactly this problem happened.

The bisection requested by _you_, shows clearly and unequivocally
that the Bug occurred on this change:

04fee895ef98ffbb91a941b53a92d6949bb6d1c4 is the first bad commit
commit 04fee895ef98ffbb91a941b53a92d6949bb6d1c4
Author: Rolf Eike Beer <eike-kernel@sf-tec.de>
Date:   Wed Jun 15 11:27:02 2011 +0200

    DRM: clean up and document parsing of video= parameter

That means that just BEFORE (i.e. any kernel release) there was no problem
(drm, fb or _otherwise_) and AT THE TIME of this commit (04fee...6d1c4)
and THEREAFTER this particular Bug showed up and persists to this day.

2.  What do you mean by "any issues you're seeing are not OUR bug"?

2.1.  Who is/are "our"?
Is it hard to understand that I can be a simple user reporting a bug
and there's a possibility that I might _not_ be aware of any of the persons behind the "our" word?
It is just simple and basic politeness to let the other person in on who you're talking about.

2.2.  All I know that once a person named "Rolf Eike Beer" made a change to
the kernel, SOMETHING (i.e., this bug, 43167) changed in the behavior of
my system and created this problem ("issue", as you call it).
The "fb driver" existed BEFORE, DURING and AFTER this change.
_This_ change affected the behavior of my system, it's as simple as that.

2.3. It is not my responsibility (nor necessarily my capability) to chase
this problem around and have it fixed.
A user submitting an acknowledged Bug report is supposed to only TECHNICALLY _help_ those responsible in the process of troubleshooting it.

You, Rolf Eike Beer or whoever else (the "our"s) must fix this problem
any way you see fit.  Uncomit, have the "fb driver" changed to _accommodate_
this obviously bad commit, report the "fb" bug the proper authorities, whatever.

2.4.  How busy are you, anyway?  Do you always need three months (remember
Comment 18?) to come up with "It's not our problem" accompanied by an absurd
explanation ("vt kernel subsystem") and a heavy-handed RESOLVED decision?

-- Alex

Bisect result points at core drm, moving bug from driver component to general.

Looks like a vt bug to me as well. As if something is changing the end of line behaviour flag and not restoring it. As and when Alex files it against the vt layer in the kernel bugzilla I'll take a look

Thanks, Alan.
As mentioned, I'm a simple user, never filed a kernel bug
so I need a little help, please.

Is there an easy way (workaround?) to file a kernel bugzilla
whereby I'd just basically point to this submission (43167) here.
There's a lot of stuff accumulated during a 6-month flailing around;
which is still of value, which is redundant (to put it mildly)?

1.  If the "pointer" is allowed, hopefully new analysts can find their way.

2.  If I have to start from scratch, which part(s) of this submission
can be retained?

-- Alex

Just include the URL of this bug in the kernel bug as a reference and that will be fine.

amd if you you can atdd a comment for the kernel bug URL here as well that also helps.

I just submitted
 Bug 43239  at <bugzilla.kernel.org>

Thank you all for the help,
-- Alex

Thanks

(For reference the reason I want to take a look to see where the problem is likely to be is that when we switch
 to the fbcon the shell should be getting SIGWINCH and the tty bits updated)

(In reply to comment #39)
> I just submitted

URL for convenience: http://bugzilla.kernel.org/show_bug.cgi?id=43239

(In reply to comment #34)
> 1.  I did _exactly_ what you asked me to do.  Twice.  The hard way.
> To BISECT so one can find out where/when exactly this problem happened.
> 
> The bisection requested by _you_, shows clearly and unequivocally
> that the Bug occurred on this change:
> 
> 04fee895ef98ffbb91a941b53a92d6949bb6d1c4 is the first bad commit
> commit 04fee895ef98ffbb91a941b53a92d6949bb6d1c4
> Author: Rolf Eike Beer <eike-kernel@sf-tec.de>
> Date:   Wed Jun 15 11:27:02 2011 +0200
> 
>     DRM: clean up and document parsing of video= parameter
> 
> That means that just BEFORE (i.e. any kernel release) there was no problem
> (drm, fb or _otherwise_) and AT THE TIME of this commit (04fee...6d1c4)
> and THEREAFTER this particular Bug showed up and persists to this day.

For completeness, the bisect result points at the first commit that actually starts using the margins ('m') option of the mode. Before the commit, it was silently ignored and unused. After the commit, the margins option is used and clearly does not work for you.

Does dropping 'm' from the modeline solve your problem?

(In reply to comment #42)

> Does dropping 'm' from the modeline solve your problem?

Hi Jani,

I cannot believe this !!!

# The "old", subject machine:
#  "ASUS P5E-VM HDMI" with Intel G35/ICH9R, Intel Core 2 Duo E8400, 3.0 GHz
#  kernel-3.7.1

[]$ cat /boot/grub/menu.lst
 ...
 kernel /boot/LFSkernel root=/dev/sda3 video=640x400M@70        # without 'm'!

[]$ startx ...
# After exiting from Xorg (runlevel 5) to this console text, runlevel 3:

[]$ stty -a
speed 38400 baud; rows 25; columns 80; line = 0;
 ...
[]$ 123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-
-bash: 123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-: command not found

(Note:  the Comments limited window does not give proper justice to the actual command line, '123456789-123456789- ...'.
In real life, on the screen, the command text DOES wrap-around correctly to the next row after the 80th column.)

THANK YOU VERY MUCH !

Unless you come up with other questions/suggestions/comments, etc., I think(?) you can close this (I'm still in shock!)

Best Wishes,
-- Alex

PS  We'll never know why 640x400 works.  Could it be the "M" which moves us to
a different look-up table (than what xrandr shows as "natural" resolutions)?