Bug 230032 - Intel graphics driver fails to detect DVI output
Summary: Intel graphics driver fails to detect DVI output
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.2-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-x11 (Nobody)
URL: https://forums.freebsd.org/threads/xo...
Keywords: i915, regression
Depends on:
Blocks:
 
Reported: 2018-07-25 07:51 UTC by FStl
Modified: 2020-09-17 10:05 UTC (History)
7 users (show)

See Also:
des.gaufres: maintainer-feedback?


Attachments
FreeBSD kernel messages on loading the intel graphics driver in base (1.87 KB, text/plain)
2018-07-25 07:51 UTC, FStl
no flags Details
FreeBSD Xorg log when using the intel graphics driver in base (11.87 KB, text/plain)
2018-07-25 07:52 UTC, FStl
no flags Details
FreeBSD kernel messages on loading the intel graphics driver installed by graphics/drm-stable-kmod port (961 bytes, text/plain)
2018-07-25 07:54 UTC, FStl
no flags Details
Debian's Xorg log on the same hardware and setup (16.77 KB, text/plain)
2018-07-25 07:55 UTC, FStl
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description FStl 2018-07-25 07:51:44 UTC
Created attachment 195440 [details]
FreeBSD kernel messages on loading the intel graphics driver in base

I have an Intel 945G graphics card that has two outputs - one is the analog VGA output and the other is the digital DVI output. I have connected my sole digital monitor to the DVI output. This setup worked without any problems on FreeBSD 10.3. It also continues to work without problems on Debian 9.

On FreeBSD 11.2, the intel graphics driver fails to detect the DVI output of the graphics card, and consequently, I get a blank screen after the driver is loaded, either manually through the kldload command or by starting Xorg.

This behavior also occurs if I try to use the graphics/drm-stable-kmod port, leading me to believe that it is a fundamental kernel/driver regression.

I have attached the relevant FreeBSD kernel messages and Xorg logs, and also the Debian Xorg log for reference.
Comment 1 FStl 2018-07-25 07:52:57 UTC
Created attachment 195441 [details]
FreeBSD Xorg log when using the intel graphics driver in base
Comment 2 FStl 2018-07-25 07:54:14 UTC
Created attachment 195442 [details]
FreeBSD kernel messages on loading the intel graphics driver installed by graphics/drm-stable-kmod port
Comment 3 FStl 2018-07-25 07:55:09 UTC
Created attachment 195443 [details]
Debian's Xorg log on the same hardware and setup
Comment 4 FStl 2018-07-27 12:39:48 UTC
I have found two bugs (so far) in the code of the intel driver.

In /sys/dev/drm2/i915/intel_sdvo.c, in function intel_sdvo_write_cmd:


Line 458:
	msgs = malloc(args_len + 3 * sizeof(*msgs), DRM_MEM_KMS, M_NOWAIT | M_ZERO);

This line is allocating "args_len" bytes plus "3 * sizeof(*msgs)" bytes of memory, which is not as intended and actually leads to memory corruption. The correct code should be:

	msgs = malloc((args_len + 3) * sizeof(*msgs), DRM_MEM_KMS, M_NOWAIT | M_ZERO);


Lines 493-503:
	ret = -iicbus_transfer(intel_sdvo->i2c, msgs, i+3);
	if (ret < 0) {
		DRM_DEBUG_KMS("I2c transfer returned %d\n", ret);
		ret = false;
		goto out;
	}

out:
	free(msgs, DRM_MEM_KMS);
	free(buf, DRM_MEM_KMS);
	return ret;

The function iicbus_transfer returns 0 on success, and in that case, ret = -0 = 0 = false and so the function intel_sdvo_write_cmd ends up returning false even when it has actually succeeded. The correct code should be:

	ret = iicbus_transfer(intel_sdvo->i2c, msgs, i+3);
	if (ret != 0) {
		DRM_DEBUG_KMS("I2c transfer returned %d\n", ret);
		ret = false;
	}
	else
		ret = true;

	free(msgs, DRM_MEM_KMS);
	free(buf, DRM_MEM_KMS);
	return ret;


Correcting these two bugs makes the intel_sdvo_get_capabilities call successful, but the intel_sdvo_set_target_input call is still unsuccessful (this call is successful on FreeBSD 10). So there are still some bugs left...
Comment 5 P Kern 2018-10-25 17:22:16 UTC
This appears to be the problem I'm also having with FreeBSD 11.2 on my MacMini
( https://everymac.com/systems/apple/mac_mini/specs/mac_mini_cd_1.66.html )
-- a DVI monitor is connected but DVI is not detected. See xrandr output below.

This MacMini/monitor combination is verified to work properly:
it boots as expected to its original OS X with full graphics resolution.

This combination also worked under FreeBSD 10.3.

 = = = = = = = = 

# xrandr --verbose  -q
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
VGA1 disconnected (normal left inverted right x axis y axis)
        Identifier: 0x41
        Timestamp:  280998
        Subpixel:   unknown
        Clones:    
        CRTCs:      0 1
        Transform:  1.000000 0.000000 0.000000
                    0.000000 1.000000 0.000000
                    0.000000 0.000000 1.000000
                   filter: 
TV1 disconnected (normal left inverted right x axis y axis)
        Identifier: 0x42
        Timestamp:  280998
        Subpixel:   unknown
        Clones:    
        CRTCs:      0 1
        Transform:  1.000000 0.000000 0.000000
                    0.000000 1.000000 0.000000
                    0.000000 0.000000 1.000000
                   filter: 
        bottom margin: 37 
                range: (0, 100)
        right margin: 46 
                range: (0, 100)
        top margin: 36 
                range: (0, 100)
        left margin: 54 
                range: (0, 100)
        mode: NTSC-M 
                supported: NTSC-M, NTSC-443, NTSC-J, PAL-M, PAL-N, PAL, 480p, 576p, 720p@60Hz, 720p@50Hz, 1080i@50Hz, 1080i@60Hz
#
Comment 6 j 2018-10-28 10:09:16 UTC
Hi.
I have same troubles on EeePC box with an intel 945GSE.
Xorg with x86-video-intel didn't see connection on DVI.

  41.486] (==) intel(0): Depth 24, (--) framebuffer bpp 32
[    41.486] (==) intel(0): RGB weight 888
[    41.486] (==) intel(0): Default visual is TrueColor
[    41.486] (--) intel(0): Integrated Graphics Chipset: Intel(R) 945GME
[    41.487] (**) intel(0): Relaxed fencing disabled
[    41.487] (**) intel(0): Wait on SwapBuffers? enabled
[    41.487] (**) intel(0): Triple buffering? enabled
[    41.487] (**) intel(0): Framebuffer tiled
[    41.487] (**) intel(0): Pixmaps tiled
[    41.487] (**) intel(0): 3D buffers tiled
[    41.487] (**) intel(0): SwapBuffers wait enabled
[    41.487] (==) intel(0): video overlay key set to 0x101fe
[    41.536] (II) intel(0): Output VGA1 has no monitor section
[    41.585] (II) intel(0): EDID for output VGA1
[    41.588] (II) intel(0): Output VGA1 disconnected
[    41.588] (WW) intel(0): No outputs definitely connected, trying again...
[    41.588] (II) intel(0): Output VGA1 disconnected
[    41.588] (WW) intel(0): Unable to find connected outputs - setting 1024x768 initial framebuffer
[    41.588] (II) intel(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
[    41.588] (II) intel(0): Kernel page flipping support detected, enabling
[    41.589] (==) intel(0): DPI set to (96, 96)
Comment 7 j 2018-10-28 11:14:07 UTC
(In reply to j from comment #6)

Also when I using VGA port I can get 1920x1080 but picture isn't clear, it looks like soap window.
Comment 8 andywhite 2020-01-17 15:22:24 UTC
Just experienced this when install 12.1 on my mac mini 2,1

a workaround for anyone else that has this and comes here;

installing port graphics/drm-fbsd12.0-kmod  and adding 

kld_list="/boot/modules/drm.ko /boot/modules/i915kms.ko"

to the top of rc.conf, gets it working for me
Comment 9 P Kern 2020-04-19 06:31:15 UTC
(In reply to andywhite from comment #8)
Thanks andywhite. Just now migrating from FreeBSD 11 to 12.1.
Your workaround also seems to do the trick with a macmini1,1.
Comment 10 Niclas Zeising freebsd_committer freebsd_triage 2020-06-17 08:27:28 UTC
Since this seem to work (accordning to reporters) when using drm-fbsd12.0-kmod on FreeBSD 12, I believe this can be closed.

For those of you on FreeBSD 11, what happens if you install drm-fbsd11.2-kmod and add kld_list="/boot/modules/drm.ko /boot/modules/i915kms.ko" to /etc/rc.conf, does that work?

The base driver in FreeBSD 10 and FreeBSD 11 are virtually the same, it's only been updated to take into account changes in FreeBSD 11 VM subsystem and the like.
Comment 11 Niclas Zeising freebsd_committer freebsd_triage 2020-09-17 10:05:39 UTC
I believe the issue is fixed in later versions of the graphics drivers.  I have not gotten any confirmation despite asking of it.  Closing this as a combination of OBE and feedback timeout.