The second bisect identifies 5099114ba3b2e5ae9fb487aeb3ae0434f=
e38a7da as the
oldest commit showing the problem, which does not show in adjacent  commit
b646c1dc835b6b73884a88643c2534f1a4a1928f.
In order to see either of these commits in git list, one first needs to git
checkout 2bfb0b678e48dee76543bfa2079b7e42609332fb.
(In reply to Duncan Roe from commen=
t #0)
> Created attachment 142239 [details]
> Git diff specifying 2 commits (GD is aliased to git diff)
>=20
> (High severity because laptop is useless when travelling)
> With HDMI unplugged, X laptop screen is black with only a cursor. Curs=
or
> changes shape as it moves over xterm windows put there by xinitrc.
> Bisecting in git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git =
finds
> 2bfb0b678e48dee76543bfa2079b7e42609332fb has the problem but adjacent =
commit
> 9c24c10a2c1e1bb478b6bb70612d9e885aee044f does not.
> There is an oddity with git diff between these two: git diff <commi=
t1>
> <commit2> produces copious output and a git warning (see attachm=
ent), but
> git checkout <commit2>; git diff <commit1> only shows one =
patched file (next
> attachment). You might want to try this - I re-cloned the repo in case=
 the
> old one was corrupted but it made no difference.

Please ignore the git diff stuff above. After checking out
2bfb0b678e48dee76543bfa2079b7e42609332fb, I diffed the second commit in git
list not realising that this was no longer
9c24c10a2c1e1bb478b6bb70612d9e885aee044f.
The new bisect is the valid one