Created attachment 127603 [details] dmesg on my system i915 only enables modelines below 165MHz, allthough every between 165MHz and 300MHz actually works on that port. attached is the dmesg 0xe debug dump while plugging in the display, i2cdump 0x40 i and i915_opregion
Created attachment 127604 [details] i2cdump
Comment on attachment 127604 [details] i2cdump 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 44 50 2d 48 44 4d 49 20 41 44 41 50 54 4f 52 04 DP-HDMI ADAPTOR? 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 20: 44 50 2d 48 44 4d 49 20 41 44 41 50 54 4f 52 04 DP-HDMI ADAPTOR? 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 40: 44 50 2d 48 44 4d 49 20 41 44 41 50 54 4f 52 04 DP-HDMI ADAPTOR? 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 60: 44 50 2d 48 44 4d 49 20 41 44 41 50 54 4f 52 04 DP-HDMI ADAPTOR? 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 80: 44 50 2d 48 44 4d 49 20 41 44 41 50 54 4f 52 04 DP-HDMI ADAPTOR? 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ a0: 44 50 2d 48 44 4d 49 20 41 44 41 50 54 4f 52 04 DP-HDMI ADAPTOR? b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ c0: 44 50 2d 48 44 4d 49 20 41 44 41 50 54 4f 52 04 DP-HDMI ADAPTOR? d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ e0: 44 50 2d 48 44 4d 49 20 41 44 41 50 54 4f 52 04 DP-HDMI ADAPTOR? f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
Created attachment 127605 [details] i2cdump
Created attachment 127606 [details] i915_opregion
Please add drm.debug=14 module parameter and attach dmesg all the way from boot to the problem. That'll tell us the kernel version and platform etc. Might already be fixed upstream.
(In reply to Jani Nikula from comment #5) > Please add drm.debug=14 module parameter and attach dmesg all the way from > boot to the problem. That'll tell us the kernel version and platform etc. > > Might already be fixed upstream. kernel is 4.8.5 GPU is Intel HD 4600 Will add a full dmesg whenever I find some
Created attachment 127671 [details] dmesg with drm.debug=0xe
I was able to enable a 540MHz modeline with an active DP1.2 -> HDMI 2.0 adapter, so I am quite sure that driving 300MHz modelines should also work with the laptop embedded hdmi port.
(Presumably you're supposed to change the status from NEEDINFO->REOPENED when you provide the needed info)
(In reply to Karol Herbst from comment #8) > I was able to enable a 540MHz modeline with an active DP1.2 -> HDMI 2.0 > adapter, so I am quite sure that driving 300MHz modelines should also work > with the laptop embedded hdmi port. You shouldn't make any conclusions about what you can output from a (native) HDMI connector based on what you can output from the DP connector.
(In reply to Jani Nikula from comment #10) > (In reply to Karol Herbst from comment #8) > > I was able to enable a 540MHz modeline with an active DP1.2 -> HDMI 2.0 > > adapter, so I am quite sure that driving 300MHz modelines should also work > > with the laptop embedded hdmi port. > > You shouldn't make any conclusions about what you can output from a (native) > HDMI connector based on what you can output from the DP connector. I didn't. I added modelines for the HDMI output and was able to get 540MHz modelines working through the HDMI port to my HDMI TV. It's just that the HDMI port seems to be a DP -> HDMI connecter, but I don't for sure. I just see a HDMI port and think it is an HDMI port.
Karol - is there still a problem? Based on your last comment I'm not sure :) If you got system working, please mark bug status=resolved. If not then change status=reopened with additional info like the output from xrandr --query.
(In reply to Jari Tahvanainen from comment #12) > Karol - is there still a problem? Based on your last comment I'm not sure :) > If you got system working, please mark bug status=resolved. If not then > change status=reopened with additional info like the output from xrandr > --query. there still is. The isssue is, that the kernel module can't detect that the internal HDMI port can do higher Modes above 165MHz what works is: 1. If I connect the Display to my HDMI port and add modelines manually, which are dropped by the kernel module in the boot process. Those need a clock above 165MHz, but below 540MHz. They also work without issues. 2. my active HDMI -> miniDP Adapter, which gets also Modelines above 540MHz, which also work.
I also tried my laptop on a 2560x1440 Display and had the exactly same problem, but I don't have access to that one anymore, so I can't provide more details.
The original problem is that we detect your adapter as type 1 DP dual mode adapter, which are notoriously bad about reporting their max clock. Trying to read it from the adapter would result in more failures and black screens than what it would solve. Thus we limit to 165 MHz on type 1 adapters. Bit 11 of the VBT device class does seem to indicate HDMI rather than DVI output, but I am really not sure if that can be universally trusted. Something to think about though. Have you tried kernel v4.10 or later? It does have some fixes for certain types of adapters.
(In reply to Jani Nikula from comment #15) > The original problem is that we detect your adapter as type 1 DP dual mode > adapter, which are notoriously bad about reporting their max clock. Trying > to read it from the adapter would result in more failures and black screens > than what it would solve. Thus we limit to 165 MHz on type 1 adapters. > > Bit 11 of the VBT device class does seem to indicate HDMI rather than DVI > output, but I am really not sure if that can be universally trusted. > Something to think about though. > > Have you tried kernel v4.10 or later? It does have some fixes for certain > types of adapters. not yet, will do when I can access the display again, which is at eastern the latest.
(In reply to Karol Herbst from comment #16) > (In reply to Jani Nikula from comment #15) > > ... > > Have you tried kernel v4.10 or later? It does have some fixes for certain > > types of adapters. > > not yet, will do when I can access the display again, which is at eastern > the latest. Hello Karon, Is there any update on this one? Thank you.
(In reply to Elizabeth from comment #17) > (In reply to Karol Herbst from comment #16) > > (In reply to Jani Nikula from comment #15) > > > ... > > > Have you tried kernel v4.10 or later? It does have some fixes for certain > > > types of adapters. > > > > not yet, will do when I can access the display again, which is at eastern > > the latest. > Hello Karon, > Is there any update on this one? > Thank you. thanks for reminding me, I totally forgot about trying this out. Will do so over the next days.
Hello Karol, sorry for pestering, but is there any update on this? Thank you.
(In reply to Elizabeth from comment #19) > Hello Karol, sorry for pestering, but is there any update on this? Thank you. if I don't forget, then you get your update tomorrow
(In reply to Elizabeth from comment #19) > Hello Karol, sorry for pestering, but is there any update on this? Thank you. so I've tried again today. with kernel 4.12.8 there seems to be no change and I don't get any >165MHz Modelines added automatically. Rarely I also get this in dmesg: [ 462.503734] [drm:drm_scdc_set_high_tmds_clock_ratio] *ERROR* Failed to read tmds config, err=-6 [ 462.503739] [drm:intel_hdmi_handle_sink_scrambling] *ERROR* Set TMDS ratio failed The display provided 300MHz Modelines can be used over HDMI if added manually with xrandr. All <=540 MHz modelines can be used with my active HDMI to DP adapter.
I'm inclined to go with WONTFIX. The reasoning is that while this is annoying to you, you do get something on screen. Erring on the side of allowing >165 MHz modes when the display or link is not capable, one gets a black screen, which is arguably a worse outcome. Additionally, you have the workaround of adding the modes yourself. Ville, anything you want to add?
(In reply to Jani Nikula from comment #22) > I'm inclined to go with WONTFIX. The reasoning is that while this is > annoying to you, you do get something on screen. Erring on the side of > allowing >165 MHz modes when the display or link is not capable, one gets a > black screen, which is arguably a worse outcome. Additionally, you have the > workaround of adding the modes yourself. > > Ville, anything you want to add? Would it be possible to add a module parameter to overwrite the detected limit? this way the user has an easier way to get those modelines, because the alternative would be to enable drm debugging and fetch those modelines and adjust the output so that xrandr accepts it.
(In reply to Karol Herbst from comment #23) > (In reply to Jani Nikula from comment #22) > > I'm inclined to go with WONTFIX. The reasoning is that while this is > > annoying to you, you do get something on screen. Erring on the side of > > allowing >165 MHz modes when the display or link is not capable, one gets a > > black screen, which is arguably a worse outcome. Additionally, you have the > > workaround of adding the modes yourself. > > > > Ville, anything you want to add? > > Would it be possible to add a module parameter to overwrite the detected > limit? this way the user has an easier way to get those modelines, because > the alternative would be to enable drm debugging and fetch those modelines > and adjust the output so that xrandr accepts it. something like "i915.dspclkovwr=HDMI2=300" I don't know if those xrandr port names are already known in the driver at that time or not.
(In reply to Karol Herbst from comment #23) > Would it be possible to add a module parameter to overwrite the detected > limit? We already have too many and the direction is to remove, not add module parameters.
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Karol, is this still issue? If so please re-open. Closing, please re-open if still occurs.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.