Re: framebuffer refresh rate and geometry

2022-04-13 Thread Emmanuel Dreyfus
On Wed, Apr 13, 2022 at 12:31:30PM +, Emmanuel Dreyfus wrote:
> 1200x1920 @ 55Hz (145600 1286 1290 1350 1955 1958 1961 -H -V)
> Preferred mode: 1200x1920 @ 55Hz

I got it: this is a laptop with built-in eDP1 ouput. My problams are
with HDMI1 output, because the kernel only considers EDID from eDP1.

-- 
Emmanuel Dreyfus
m...@netbsd.org


Re: framebuffer refresh rate and geometry

2022-04-13 Thread Emmanuel Dreyfus
On Tue, Apr 12, 2022 at 08:03:43AM +0200, Michael van Elst wrote:
> > wsconsctl: edid: not found
> -current only :-/

edid=
Vendor: [MS_] 
Product: [9001] BW8
Serial number: 0100
Manufactured 2002 Week 0
EDID Version 1.3
EDID Comment: 
Video Input: 80
Digital
Gamma: 2.20
Max Size: 9 cm x 15 cm
Features: 2f
DPMS active-off
RGB
Standard color space
Preferred timing
Default GTF supported
Chroma Info:
Red X: 0.625
Red Y: 0.625
Grn X: 0.285
Grn Y: 0.605
Blu X: 0.148
Blu Y: 0.062
Wht X: 0.281
Wht Y: 0.308
Range:
Horizontal: 125 - 125 kHz
Vertical: 60 - 60 Hz
Max Dot Clock: 160 MHz
Video modes:
1200x1920 @ 55Hz (145600 1286 1290 1350 1955 1958 1961 -H -V)
Preferred mode: 1200x1920 @ 55Hz
Number of extension blocks: 0

-- 
Emmanuel Dreyfus
m...@netbsd.org


Re: framebuffer refresh rate and geometry

2022-04-12 Thread RVP

On Mon, 11 Apr 2022, Emmanuel Dreyfus wrote:


When the kernel initialize a framebuffer, the signal ouput changes a bit
fro mwhat is inherited from the BIOS. I face the situation where the
display looses the signal, and I suspect this is related to the refresh
rate.



OK, I'm able to get a usable UEFI console (intelfb) with the hack below
(starting X, however, immediately locks up the system):

```
diff -urN a/sys/external/bsd/drm2/dist/drm/i915/display/intel_lvds.c 
b/sys/external/bsd/drm2/dist/drm/i915/display/intel_lvds.c
--- a/sys/external/bsd/drm2/dist/drm/i915/display/intel_lvds.c  2021-12-18 
23:45:30.0 +
+++ b/sys/external/bsd/drm2/dist/drm/i915/display/intel_lvds.c  2022-04-12 
10:28:48.162488466 +
@@ -962,11 +962,6 @@
if (fixed_mode)
goto out;

-   /* Failed to get EDID, what about VBT? */
-   fixed_mode = intel_panel_vbt_fixed_mode(intel_connector);
-   if (fixed_mode)
-   goto out;
-
/*
 * If we didn't get EDID, try checking if the panel is already turned
 * on.  If so, assume that whatever is currently programmed is the
@@ -977,8 +972,12 @@
DRM_DEBUG_KMS("using current (BIOS) mode: ");
drm_mode_debug_printmodeline(fixed_mode);
fixed_mode->type |= DRM_MODE_TYPE_PREFERRED;
+   goto out;
}

+   /* Failed to get current mode, what about VBT? */
+   fixed_mode = intel_panel_vbt_fixed_mode(intel_connector);
+
/* If we still don't have a mode after all that, give up. */
if (!fixed_mode)
goto failed;
```

Going by the kernel messages, on 9.2, the old DRM fails to find a VBT:

```
kern info: [drm] failed to find VBIOS tables
i915drmkms0: interrupting at ioapic0 pin 16 (i915drmkms0)
intelfb0 at i915drmkms0
intelfb0: framebuffer at 0xd700687fb000, size 1366x768, depth 32, 
stride 5504

kern error: 
[drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_fifo_underrun.c:230)cpt_set_fifo_underrun_reporting]
 *ERROR* uncleared pch fifo underrun on pch transcoder A
kern error: 
[drm:(/usr/src/sys/external/bsd/drm2/dist/drm/i915/intel_fifo_underrun.c:381)intel_pch_fifo_underrun_irq_handler]
 *ERROR* PCH transcoder A FIFO underrun
wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100 emulation), using 
wskbd0
```

but, somehow still picks the correct native mode (1366x768) and everything 
is fine. The new DRM code, _does_ seem to find a VBT, but picks a 
non-native resolution (1024x768) in UEFI mode and the display gets messed 
up. In CSM mode, 1366x768 is correctly picked from the VBT.


I'll try to chase this down further when I have the time, but, somebody who
_knows_ this stuff would obviously make quicker progress.

-RVP


Re: framebuffer refresh rate and geometry

2022-04-12 Thread RVP

On Tue, 12 Apr 2022, Michael van Elst wrote:



wsconsctl learned about the edid attribute in -current.

Either a pullup is necessary, or you can try with the -current binary.



Yah--this is with a recent -HEAD. On older versions I used the ioctl
directly. No joy even in CSM mode, which is the only way DRM runs
properly on my HW.

-RVP



Re: framebuffer refresh rate and geometry

2022-04-12 Thread Michael van Elst
On Mon, Apr 11, 2022 at 04:23:04PM -0700, Paul Goyette wrote:
> On Mon, 11 Apr 2022, RVP wrote:
> 
> > On Mon, 11 Apr 2022, Michael van Elst wrote:
> > 
> > > N.B. if the display driver provides EDID data to wscons it can be
> > > queried with
> > > 
> > > wsconsctl -d edid
> > > 
> > 
> > newdrm seems to have lost this ability (since, at least, Oct '21). The old
> > DRM in 9.2_STABLE still fetches an EDID on the same HW (IvyBridge mobile
> > IGPU).
> 
> Works for me on -current as of 9.99.93 with nouveau and reredrm

wsconsctl learned about the edid attribute in -current.

Either a pullup is necessary, or you can try with the -current binary.


-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."


Re: framebuffer refresh rate and geometry

2022-04-12 Thread Michael van Elst
On Tue, Apr 12, 2022 at 12:52:36AM +, Emmanuel Dreyfus wrote:
> On Mon, Apr 11, 2022 at 11:37:29AM -, Michael van Elst wrote:
> > I rather doubt that a black display comes from the refresh rate.
> 
> In X11, I get it working at 50 Hz, but I get a black display at 60 Hz.
> 
> > N.B. if the display driver provides EDID data to wscons it can be
> > queried with
> > 
> > wsconsctl -d edid
> 
> # wsconsctl -d edid
> wsconsctl: edid: not found

-current only :-/



-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."


Re: framebuffer refresh rate and geometry

2022-04-11 Thread Emmanuel Dreyfus
On Mon, Apr 11, 2022 at 11:37:29AM -, Michael van Elst wrote:
> I rather doubt that a black display comes from the refresh rate.

In X11, I get it working at 50 Hz, but I get a black display at 60 Hz.

> N.B. if the display driver provides EDID data to wscons it can be
> queried with
> 
> wsconsctl -d edid

# wsconsctl -d edid
wsconsctl: edid: not found


-- 
Emmanuel Dreyfus
m...@netbsd.org


Re: framebuffer refresh rate and geometry

2022-04-11 Thread RVP

On Mon, 11 Apr 2022, Paul Goyette wrote:


On Mon, 11 Apr 2022, RVP wrote:


On Mon, 11 Apr 2022, Michael van Elst wrote:


N.B. if the display driver provides EDID data to wscons it can be
queried with

wsconsctl -d edid



newdrm seems to have lost this ability (since, at least, Oct '21). The old
DRM in 9.2_STABLE still fetches an EDID on the same HW (IvyBridge mobile
IGPU).


Works for me on -current as of 9.99.93 with nouveau and reredrm



Thanks. Looks like an i915drm issue then.

-RVP



Re: framebuffer refresh rate and geometry

2022-04-11 Thread Paul Goyette

On Mon, 11 Apr 2022, RVP wrote:


On Mon, 11 Apr 2022, Michael van Elst wrote:


N.B. if the display driver provides EDID data to wscons it can be
queried with

wsconsctl -d edid



newdrm seems to have lost this ability (since, at least, Oct '21). The old
DRM in 9.2_STABLE still fetches an EDID on the same HW (IvyBridge mobile
IGPU).


Works for me on -current as of 9.99.93 with nouveau and reredrm


++--+--+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses:|
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org  |
| & Network Engineer |  | pgoyett...@gmail.com |
++--+--+


Re: framebuffer refresh rate and geometry

2022-04-11 Thread RVP

On Mon, 11 Apr 2022, Michael van Elst wrote:


N.B. if the display driver provides EDID data to wscons it can be
queried with

wsconsctl -d edid



newdrm seems to have lost this ability (since, at least, Oct '21). The old
DRM in 9.2_STABLE still fetches an EDID on the same HW (IvyBridge mobile
IGPU).

-RVP



Re: framebuffer refresh rate and geometry

2022-04-11 Thread Michael van Elst
m...@netbsd.org (Emmanuel Dreyfus) writes:

>When the kernel initialize a framebuffer, the signal ouput changes a bit 
>fro mwhat is inherited from the BIOS. I face the situation where the 
>display looses the signal, and I suspect this is related to the refresh
>rate.

BIOS usually sets fixed VESA modes.
The DRM code usually sets a mode derived from EDID data sent by the monitor.

With X11 you can use xrandr to select modes provided by the driver
(usally derived from EDID data) and also add custom modes if the
driver supports these.

I rather doubt that a black display comes from the refresh rate.

N.B. if the display driver provides EDID data to wscons it can be
queried with

wsconsctl -d edid