Thank you to all, My solution was only pass from netbsd-8.0 to current of 2018092400Z I don't need install wip xf86-video-intel and I don't need configure any thing of xorg.conf iwm0 works and hdmi works.
I can use my laptop again with my favourite OS :) Cayo El dom., 23 sept. 2018 a las 19:15, Robert Nestor (<rnes...@mac.com>) escribió: > 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.
