Intel builtin graphics, wsfb, gop - uses EDID?

[Greg Troxel <gdt%lexort.com@localhost>]

I have a Dell Optiplex 3070 SFF from 2019, with UHD 630, from grazing
refurb sales.  It is currently running NetBSD 9.  (I know I'd be better
off with 10; that's in my future.  I do see

        kernel: Merge DRM/KMS GPU drivers from Linux 5.6. [riastradh 20211219]

which I gather advances support for the Intel driver forward.)

Things are mostly working well with this box.  I'm using a VGA monitor,
because the box has VGA/HDMI/DisplayPort and monitors on hand are
VGA/DVI.  I'm getting a better monitor, but I suspect that's orthogonal
to my issue.

xinit runs, but the screen is 1024x768.  I wondered why EDID was not
working and swapped cables without any change.  After investigating, I
found out that the intel driver declined to accept the UHD 630 and thus
it ends up with wsfb.  I then found:

  https://wiki.netbsd.org/tutorials/x11/how_to_use_wsfb_uefi_bios_framebuffer/

which talks about "gop" in the bootloader (very helpfully!).  I have an
HP w2207 hooked up via VGA, max resolution 1680x1050 (I know that's
odd).  "gop list" shows:

     UHD 630.  Booting with HP w2207:
       0: 1680x1050 BGRR pitch 1680 bpp 32
       1: 640x480 BGRR pitch 640 bpp 32
      *2: 800x600 BGRR pitch 800 bpp 32
       3: 1024x768 BGRR pitch 1024 bpp 32
       4: 1280x1024 BGRR pitch 1280 bpp 32

After "gop 0" and booting, xinit starts to 1680x1050 per xdpyinfo.
dmesg shows:

  genfb0 at pci0 dev 2 function 0: vendor 8086 product 3e98 (rev. 0x02)
  genfb0: framebuffer at 0xc0000000, size 1680x1050, depth 32, stride 6720
  genfb0: shadow framebuffer enabled, size 6890 KB
  wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 emulation)

I know the 630 will do much higher resolution; Intel claims
4096 x 2304@60Hz via displayport:
  https://ark.intel.com/content/www/us/en/ark/products/191792/intel-core-i79700-processor-12m-cache-up-to-4-70-ghz.html

I am wondering if the builtin graphics is polling the monitor EDID and
this list is derived from the set of builtin modes that are within or
match the monitor.  Otherwise it would be bizarre to have 1680x1050 show
up.  On a 2007 Dell with a 2010ish Radeon HD 5450, with a 1600x1200 LCD:

  radeondrmkmsfb0 at radeon0
  radeondrmkmsfb0: framebuffer at 0xffffc100af336000, size 1600x1200, depth 32, stride 6400
  wsdisplay0 at radeondrmkmsfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0

Should I expect that if I hook it up to a 1600x1200 monitor, or via
displayport to a 2560x1440 monitor, that gop 0 will then refer to that
native resolution?

Is there a reason why "gop 0" is not chosen automatically?  I'm guessing
it is because it may not always go well, and thus it's best to have to
opt in.

I'm also guessing that this does not work with xrandr because of lack of
plumbing and maybe because the wsfb driver is not mode-agile once the
system is booted.