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.

Reply via email to