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.
Created attachment 195441 [details] FreeBSD Xorg log when using the intel graphics driver in base
Created attachment 195442 [details] FreeBSD kernel messages on loading the intel graphics driver installed by graphics/drm-stable-kmod port
Created attachment 195443 [details] Debian's Xorg log on the same hardware and setup
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...
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 #
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)
(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.
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
(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.
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.
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.