I've tried reinstalling `amd64` and booting `bsd.sp` but I'm seeing the same thing.
Manually resetting `force` to false inside `intel_tv_detect` causes it to return the current connector status (presumably `connector_status_disconnected` but I haven't checked explicitly) and the console now fills the panel. Looking into this a bit more, it seems like the return from `intel_tv_detect_type` is initially `DRM_MODE_CONNECTOR_SVIDEO` but on subsequent detections is `-1`, which causes `intel_tv_detect` to return `connector_status_connected` and `connector_status_disconnected` respectively: ``` $ grep '^\[drm:pid\d\+:intel_tv_detect' dmesg.1524564020 [drm:pid0:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=1 [drm:pid0:intel_tv_detect_type] TV detected: c00c7, cf0000aa [drm:pid0:intel_tv_detect_type] Detected S-Video TV connection [drm:pid85561:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=1 [drm:pid85561:intel_tv_detect_type] TV detected: 500c00c7, 7f0000aa [drm:pid85561:intel_tv_detect_type] Unrecognised TV connection [drm:pid85561:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=0 [drm:pid85561:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=1 [drm:pid85561:intel_tv_detect_type] TV detected: 500c00c7, 7f0000aa [drm:pid85561:intel_tv_detect_type] Unrecognised TV connection [drm:pid85561:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=0 [drm:pid85561:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=0 [drm:pid85561:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=0 ``` Based on the dmesg, the incorrect detection seems to occur during the initial driver init, whereas subsequent during the hotplug: ``` $ grep -B1 '^\[drm:pid\d\+:drm_helper_probe_single_connector_modes_merge_bits\] \[CONNECTOR:\d\+:LVDS-\]$' dmesg.1524564020 [drm:pid0:intel_fbdev_init_bios] no active fbs found, not using BIOS config [drm:pid0:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:25:LVDS-] -- [drm:pid85561:drm_fb_helper_hotplug_event] [drm:pid85561:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:25:LVDS-] -- [drm:pid85561:drm_fb_helper_hotplug_event] [drm:pid85561:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:25:LVDS-] ``` Part of me feels that if `intel_tv_detect` returns `connector_status_disconnected` on later calls, then it would make sense to redo the logic relating to connector setup etc from `drm_fb_helper_initial_config` in `drm_fb_helper_hotplug_event`, but I'm not sure how far that deviates from what's expected, nor how much this eats into existing kernel structures. Regards, Tom Sullivan Head Developer *Most Significant Bit Software* *e:* [email protected] *p:* +61 407 890 821 <+61407890821> On Wed, Apr 25, 2018 at 12:46 AM, Thomas Sullivan <[email protected]> wrote: > > > On Tue, 24 Apr 2018 at 11:37 pm, Thomas Sullivan <[email protected]> wrote: > >> Thanks Mark, >> >> That was my thought too, but it’s not hooked up to anything except power >> and ethernet. >> >> On Tue, 24 Apr 2018 at 11:24 pm, Mark Kettenis <[email protected]> >> wrote: >> >>> > From: Thomas Sullivan <[email protected]> >>> > >>> > HI all, >>> > >>> > I've just installed 6.3 on my Early 2008 MacBook, with `inteldrm` >>> graphics >>> > and the console resolution seems misconfigured such that the screen >>> > resolution is the full panel resolution at 1280x800 but the console >>> itself >>> > much smaller, and restricted to the top left corner. Since then I've >>> > upgraded to the latest snapshot (22-Apr-2018) to no avail. >>> > >>> > `wsconsctl` shows: >>> > >>> > ``` >>> > # wsconsctl display >>> > display.type=inteldrm >>> > display.width=848 >>> > display.height=480 >>> > display.depth=32 >>> > display.emulations=vt100 >>> > display.screentypes=std >>> > display.focus=0 >>> > display.brightness=97.97% >>> > display.screen_on=250 >>> > display.screen_off=0 >>> > display.vblank=off >>> > display.kbdact=on >>> > display.msact=on >>> > display.outact=on >>> > ``` >>> > >>> > Attached is `dmesg` from a kernel built with: >>> > >>> > ``` >>> > option DRMDEBUG >>> > option MSGBUFSIZE=65536 >>> > ``` >>> > >>> > and a picture of the console (spewing data to fill the available >>> space). >>> > >>> > Regards, >>> > >>> > Tom Sullivan >>> >>> Hi Tom, >>> >>> Thanks for providing the DRMDEBUG dmesg. For some reason the >>> inteldrm(4) code detects a connection on the S-Video connector. Since >>> the default is to mirror the console framebuffer on all connected >>> outputs, the framebuffer is configured as 848x480 such that the full >>> contents are visible on both outputs. >>> >>> It seems this model does indeed have a S-Video output. Do you have >>> that hooked up to something? >>> >>> Cheers, >>> >>> Mark >>> >>> -- > Regards, > > Tom Sullivan > > Head Developer > *Most Significant Bit Software* > > *e:* [email protected] > *p:* +61 407 890 821 >
