The screen auto-configure algorithm in X seems to change a bit with every new update which, on my system, introduces this particular problem. What I’ve noticed is that the algorithm tries to determine what graphics cards are present, what resolutions are supported, etc then sometimes gets confused about which port the monitor is attached to. Usually happens with a monitor that doesn’t do a good job of supporting DPMS. On my system when it gets into this confused state it usually tries to attach the monitor onto the VGA1 port rather than the VGA0 port. (I’m using a VGA monitor and graphics cards that only have a single VGA port.)
A similar issue occurs with screen resolution. I’ve seen it determine which resolutions it thinks it can support based on what assumptions it made about the graphics card and/or what it thinks it got for a DPMS response. And in doing so drops a lot of valid resolutions, usually the higher ones, from the list of what it can support. Just adding the modelines to an xorg.conf file doesn’t always work unless they reference the correct port to which the monitor will attach to. The solution is to build your own xorg.conf file to specify which port to use by putting an “Option Monitor…” directive into the Device Section. It used to be pretty easy to discover where the auto-configue was trying to attach the monitor by just scanning the /var/log/Xorg.0.log file, but more recent versions of X no longer emit that bit of useful information no matter how verbose you force X into. So now it just takes a lot of fiddling around and playing with options until you find the right magic. These same problems come up on Linux too, so it isn’t a NetBSD issue. It is, I believe, an auto-configure problem in X itself which is common to both systems. I think it’s mainly the result of trying to make X smarter during startup by utilizing the DPMS info. But when the monitor doesn’t support DPMS or doesn’t get it right X gets itself confused. There is a way to encode and provide your own DPMS file for X to use instead of relying on the monitor to supply one, but I’ve never been able to get that to work correctly on either Linux or NetBSD.
