Monitor complains with message: "Input Not Supported" with an Intel i965Q

[CodeforEvolution]

Hello! I am having a problem where my monitor will complain with a message saying "Input Not Supported" even though Haiku still runs like normal behind the hovering message. I am running hrev 51185 and unfortunately, I can't remember in which hrev the problem started. I'm running an Intel i965Q which makes use of the intel_extreme driver. Something to point out is that all the modes to use in the Screen prefs does not work, except the default configuration on boot.

[CodeforEvolution]

Haiku hrev51185 syslog

[CodeforEvolution]

Don't know why it says "patch set".

[pulkomandy]

A syslog from alpha4.1 (if you can't find anything more recent that still doesn't show the bug) and/or the output from "intel_reg dump" on Linux could help seeing what changed.

As for the "patch set" thing, it is a bug in Trac since the latest update.

[CodeforEvolution]

Haiku Alpha 4.1 Syslog

[CodeforEvolution]

Here is the log for Haiku Alpha 4.1 ^{Interesting enough, it works without showing the "Input Not Supported" Message, and all the proposed dispaly modes, frequencies, and Color amount options work. (Except two very low resolution options at the 640x* range)}

[pulkomandy]

Alpha4.1:

1896	KERN: intel_extreme : hardware mode will actually be 1024x768
1897	KERN: PLL limits, min: p 5 (p1 1, p2 10), n 5, m 70 (m1 12, m2 7)
1898	KERN: PLL limits, max: p 80 (p1 8, p2 5), n 10, m 120 (m1 22, m2 11)
1899	KERN: required MHz: 65
1900	KERN: found: 65.1429 MHz, p = 28 (p1 = 2, p2 = 14), n = 6, m = 114 (m1 = 21, m2 = 9)
1901	KERN: PLL limits, min: p 5 (p1 1, p2 10), n 5, m 70 (m1 12, m2 7)
1902	KERN: PLL limits, max: p 80 (p1 8, p2 5), n 10, m 120 (m1 22, m2 11)
1903	KERN: required MHz: 65
1904	KERN: found: 65.28 MHz, p = 30 (p1 = 3, p2 = 10), n = 5, m = 102 (m1 = 19, m2 = 7)

Strange thing: why does it perform the search twice, and why does it not find the same result for the same input?

Nightly:

KERN: intel_extreme: SetDisplayMode: Analog A 1024x768
174	KERN: intel_extreme: compute_dpll_9xx: required MHz: 65
175	KERN: intel_extreme: PLL limits, min: p 5 (p1 1, p2 10), n 5, m 70 (m1 12, m2 7)
176	KERN: intel_extreme: PLL limits, max: p 80 (p1 8, p2 5), n 10, m 120 (m1 22, m2 11)
177	KERN: intel_extreme: compute_dpll_9xx: best MHz: 65.28 (error: 0.28)
178	KERN: intel_extreme: compute_pll_divisors: found: p = 30 (p1 = 3, p2 = 10), n = 5, m = 102 (m1 = 16, m2 = 10)

It finds the same timing as alpha4 second try, but with a different setting for the M1/M2 values. Maybe it results in a less stable clock, which your monitor then complains about? And why does it not pick the better solution at 65.1429MHz?

[CodeforEvolution]

One thing I noticed when searching through the source code was that in the alpha, the pll calculation was done in the same source code file as the mode switcher, while in the nightlies, a whole separate source code file houses the pll calculation.

[pulkomandy]

In the current driver, the PLL calculation handles several more generations of intel devices, each having different constraints on acceptable PLL values. This makes the PLL code somewhat more complex and this is why it was moved to a different file to keep things clear.

[waddlesplash]

Please retest after hrev53040.

[CodeforEvolution]

Well, the boot splash is showing again. However, after the boot splash completes, the screen remains black. I believe Haiku is still running in the background as the shutdown button still seems to work, with a little delay (while Haiku closes all applications assumably) and disk activity occurring before the computer completely turns off.

[CodeforEvolution]

I can confirm that Haiku works as normal after blacklisting the intel_extreme driver. I still need to find a way to get a syslog to see what the intel_extreme driver was trying todo. The issue is I'm currently only using Haiku on a usb flash drive with the "livecd" image.

[CodeforEvolution]

Update: The intel_extreme driver at least works now...though still shows the “Input Not Supported” message on the monitor. I have been very busy unfortunately and have not had the time to grab a syslog, though hopefully this weekend I’ll finally get around to doing that.

[pulkomandy]

I found various issues in the PLL computations. It would be great if you could try ​https://review.haiku-os.org/c/haiku/+/1898 and ​https://review.haiku-os.org/c/haiku/+/1902 (ideally, try each separately, then both patches applied together, with syslogs in each case)

[CodeforEvolution]

Hey, sorry for the delay on the feedback, my desktop I'm trying to test is only booting from minimal images on a CD (not even from a USB 2.0 flash drive) which doesn't include the intel_extreme driver. Is there a way to add extra files to a minimal image?

[pulkomandy]

Use the nightly image instead of the minimal one? It already includes the driver.

[CodeforEvolution]

Well, that was the issue, I can't get the nightly image to run on my computer. My computer's CD-ROM drive has a tendency to rapidly and randomly open and close its disc tray (this also occurs when the computer is running Linux). I do have a USB CD-ROM drive, and that was able to do a successful start up for the minimal image only for some reason. (For a nightly image, the drive spins down after the 4th icon on the boot screen and then the syslog is spammed with failed usb_disk driver semaphore acquirings). USB flash drives don't even reach the Haiku boot up screen (this is with USB 2.0 and EHCI).

[pulkomandy]

Well then, maybe you can build your own customized profile with just the drivers you need.

[CodeforEvolution]

Confirmed that this message no longer occurs on hrev53790 running on a 32 bit machine. There are some other issues I'm noticing with workspace switching, different colorspaces, and GLTeapot. Should I open separate issues for these or post them here?

[pulkomandy]

For the workspace switching problem, delete the workspaces settings file, or make sure to set a working resolution for "all workspaces" in screen preferences (if the file ended up with broken resolution from previous tests with older revisions, this is needed).

Please open separate issues for the two other problems, I think it will be easier to track.

[CodeforEvolution]

Workspace switching was fine, but having a separate color space for each workspace and then switching was partially broken. And will do!

[pulkomandy]

I think we can close this ticket and handle the remaining issues separately.