Re: inteldrm(4) regression from 6.1 to 6.2: wrong console resolution

Philippe Meunier wrote:
>I just upgraded a Thinkpad T43 from OpenBSD 6.1 release to 6.2 release and
>now the console resolution is not computed correctly anymore so only the
>upper left part of the screen is actually used (very similar to what is
>described here: https://marc.info/?l=openbsd-misc&m=150825563609653). X11
>works fine.

Here's a summary regarding this wrong console resolution problem, which is
still present in 6.4-current:

1) I think I've come pretty close to the root cause of the bug. Basically,
it's because the drm_wait_one_vblank function in
src/sys/dev/pci/drm/drm_irq.c does nothing when the "cold" variable is
1. In turn that makes the intel_tv_detect function in
src/sys/dev/pci/drm/i915/intel_tv.c not wait long enough on old
computers like mine when querying the S-VIDEO DAC, which results in an
S-VIDEO connection being wrongly detected, which results in the
console's resolution being wrong.

2) For the other people who have the same problem (some are in copy of this
email), you can test the following patch to see whether your problem is
the same as mine or not (this patch is *not* a permanent solution, just
a quick and dirty way to check whether your problem is the same or not):

########
Index: sys/dev/pci/drm/i915/intel_tv.c
===================================================================
RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_tv.c,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 intel_tv.c
--- sys/dev/pci/drm/i915/intel_tv.c 1 Jul 2017 16:14:10 -0000 1.11
+++ sys/dev/pci/drm/i915/intel_tv.c 14 Aug 2018 02:31:55 -0000
@@ -37,6 +37,7 @@
#include "intel_drv.h"
#include <dev/pci/drm/i915_drm.h>
#include "i915_drv.h"
+#include <sys/param.h>

enum tv_margin {
TV_MARGIN_LEFT, TV_MARGIN_TOP,
@@ -1220,6 +1221,7 @@ intel_tv_detect_type(struct intel_tv *in

intel_wait_for_vblank(intel_tv->base.base.dev,
to_intel_crtc(intel_tv->base.base.crtc)->pipe);
+ delay(5);

type = -1;
tv_dac = I915_READ(TV_DAC);
########

3) There are various ways of fixing the problem (see the end of this email
for details) but I'm not knowledgeable enough about the DRM code and
kernel internals to do it or even to know which way really is the best.

4) On a somewhat related note, I also propose the following patch. I don't
know enough about kernel internals to know whether this patch is
actually safe in general, or even desirable; the best I can say for it
is that it seems to work fine on my one machine and that it makes it
easier to debug timing problems in the early parts of the DRM code (see
the middle of this email if you want to know exactly how this patch came
up).

########
Index: sys/kern/init_main.c
===================================================================
RCS file: /cvs/src/sys/kern/init_main.c,v
retrieving revision 1.280
diff -u -p -u -p -r1.280 init_main.c
--- sys/kern/init_main.c 13 Aug 2018 15:26:17 -0000 1.280
+++ sys/kern/init_main.c 14 Aug 2018 02:41:21 -0000
@@ -361,6 +361,9 @@ main(void *framep)
config_rootfound("mpath", NULL);