[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-bugs
Subject:    Re: Console resolution restricted to 848x400 on inteldrm
From:       Mark Kettenis <mark.kettenis () xs4all ! nl>
Date:       2018-04-27 20:27:27
Message-ID: 2459674b37e03ad9 () bloch ! sibelius ! xs4all ! nl
[Download RAW message or body]

> From: Thomas Sullivan <tom@msbit.com.au>
> Date: Sat, 28 Apr 2018 04:03:27 +1000
> 
> 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.

We don't really want to deviate too much from the "upstrean" Linux
code here.  We do backport fixes from more recent versions of this
code, but fixes we add independently from Linux are likely to get lost
whenever we update to a newer codebase.

[prev in list] [next in list] [prev in thread] [next in thread]