"Reducing the compressed framebuffer size" is not an error message. I actually don't see an error condition related to modeset in the dmesg log. 
 
Could you try turning off frame buffer compression through the following kernel command line option.

i915.enable_fbc=0

Any change?

xf86-video-intel or modeseting?

Is it possible to reproduce with xrandr?

it's using -intel

I'll try to get the other answers..

I've set `i915.enable_fbc=0`, there's not video output signal at all.

And with `xrandr`, I can reproduce this issue.

It's expected that when you switch to multihead you may end up not having enough stolen memory for a 1:1 CFB and that may cause the code to reduce the CFB size. That's fine and expected. Due to that, I updated the bug title in order to avoid confusion. The "i915.enable_fbc=0" test should help finding out if this is indeed a problem related with FBC.

Given all the data presented so far, is this simply an issue where there is not enough stolen memory (as Paulo points out) for the multiheaded configuration?  Thus, not a bug?

Any upstream developer could reproduce this?

(In reply to Paulo Zanoni from comment #5)
> It's expected that when you switch to multihead you may end up not having
> enough stolen memory for a 1:1 CFB and that may cause the code to reduce the
> CFB size. That's fine and expected. Due to that, I updated the bug title in
> order to avoid confusion. The "i915.enable_fbc=0" test should help finding
> out if this is indeed a problem related with FBC.

Hi, Paulo Zanoni
Comment 4 has mentioned that, set i915.enable_fbc=0 doesn't work.

(In reply to dog from comment #6)
> Given all the data presented so far, is this simply an issue where there is
> not enough stolen memory (as Paulo points out) for the multiheaded
> configuration?  Thus, not a bug?

How to verify if it's caused by not enough stolen memory?

Additionally, we have tested this bug on many different monitors, with two different laptops, so it's less likely a hardware issue.

After working with Aaron, we have reproduced the issue and get the log. From the log we found:

Case: extend mode - > mirror mode

Bad machine (Raven-2) hdmi connector is unplugged after the change.
This is the key point. With this mode change, HDMI module is crashed, and unplugged. And after a while, HDMI is reconnected again with new plug event. We got all the hot-plug events. Also the log shows that process.

Raven-2 has a complete different HDMI hardware module design which uses TBT(thunderbolt) IC to control DP/HDMI/Type-C connector. With general process, Thai-2 (good machine) works normal with normal HDMI connector. But with same process on Raven-2,
The control signal and data from graphics kernel driver will be firstly directed to TBT IC and then to HDMI connector. The issue happens on TBT IC signal/data transfer. HDMI is lost when kernel driver send data to TBT IC.

Suggestion:
We need TBT IC designer to double confirm, what happens in IC? HDMI is unplugged under some case. We are doubt in some case, TBT IC doesn't follow interface defined in HDMI spec. Need hardware design engineer to track why this happens on Raven-2.

Created attachment 131395 [details]
raven-2 extend-> mirror mode change, dmesg log

HDMI is unplugged (I think TBT IC is crashed for HDMI)

4591  [drm:drm_atomic_commit] commiting ffff88043e4be400
4592  [drm:drm_atomic_state_default_clear] Clearing atomic state ffff88043e4be400
4593  [drm:drm_atomic_state_free] Freeing atomic state ffff88043e4be400
4594  [drm:intel_get_hpd_pins] hotplug event received, stat 0x00200000, dig 0x10101012, pins 0x00000020
4595  [drm:intel_hpd_irq_handler] digital hpd port B - long
4596  [drm:intel_hpd_irq_storm_detect] Received HPD interrupt on PIN 5 - cnt: 0
4597  [drm:intel_dp_hpd_pulse] got hpd irq on port B - long
4598  [drm:i915_hotplug_work_func] running encoder hotplug functions
4599  [drm:i915_hotplug_work_func] Connector DP-1 (pin 5) received hotplug event.
4600  [drm:intel_dp_detect] [CONNECTOR:45:DP-1]
4601  [drm:i915_hotplug_work_func] Connector HDMI-A-1 (pin 5) received hotplug event.
4602  [drm:intel_hdmi_detect] [CONNECTOR:49:HDMI-A-1]
4603  [drm:drm_atomic_state_init] Allocated atomic state ffff88048d580800
4604  [drm:drm_atomic_get_plane_state] Added [PLANE:25] ffff88048c647780 state to ffff88048d580800
4605  [drm:drm_atomic_get_crtc_state] Added [CRTC:26] ffff88048a4bf800 state to ffff88048d580800
4606  [drm:drm_atomic_set_crtc_for_plane] Link plane state ffff88048c647780 to [CRTC:26]
4607  [drm:drm_atomic_set_fb_for_plane] Set [FB:91] for plane state ffff88048c647780
4608  [drm:drm_atomic_check_only] checking ffff88048d580800
4609  [drm:intel_plane_atomic_calc_changes] [CRTC:26] has [PLANE:25] with fb 91
4610  [drm:intel_plane_atomic_calc_changes] [PLANE:25] visible 1 -> 1, off 0, on 0, ms 0
4611  [drm:drm_atomic_commit] commiting ffff88048d580800
4612  [drm:drm_atomic_state_default_clear] Clearing atomic state ffff88048d580800
4613  [drm:drm_atomic_state_free] Freeing atomic state ffff88048d580800
4614  [drm:drm_atomic_state_init] Allocated atomic state ffff88048d580800
4615  [drm:drm_atomic_get_plane_state] Added [PLANE:29] ffff88048c6476c0 state to ffff88048d580800
4616  [drm:drm_atomic_get_crtc_state] Added [CRTC:30] ffff88048a4bd800 state to ffff88048d580800
4617  [drm:drm_atomic_set_crtc_for_plane] Link plane state ffff88048c6476c0 to [CRTC:30]
4618  [drm:drm_atomic_set_fb_for_plane] Set [FB:319] for plane state ffff88048c6476c0
4619  [drm:drm_atomic_check_only] checking ffff88048d580800
4620  [drm:intel_plane_atomic_calc_changes] [CRTC:30] has [PLANE:29] with fb 319
4621  [drm:intel_plane_atomic_calc_changes] [PLANE:29] visible 1 -> 1, off 0, on 0, ms 0
4622  [drm:drm_atomic_commit] commiting ffff88048d580800
4623  [drm:drm_atomic_state_default_clear] Clearing atomic state ffff88048d580800
4624  [drm:drm_atomic_state_free] Freeing atomic state ffff88048d580800
4625  [drm:intel_hdmi_detect] HDMI live status down
4626  [drm:intel_hpd_irq_event] [CONNECTOR:49:HDMI-A-1] status updated from connected to disconnected

Created attachment 131396 [details]
hotplug event with udevadm tools.

raven-2 machine has hotplug events.

good machine (Thai-2) has nothing when mode change(not hotplug event)

Created attachment 131442 [details]
whole bootlog of drm.debug=0x7f with Dell u2414h monitor

This boot log include the action of changing extended to mirror mode by:
xrandr -d :0 --output eDP1 --same-as HDMI1

After this change, dell monitor show no signal input and goto sleep.

Created attachment 131443 [details]
log when change extended to mirror mode on dell u2414h

do
$ xrandr -d :0 --output eDP1 --same-as HDMI1

then dell monitor got no signal input and goto sleep.

Adding tag into "Whiteboard" field - ReadyForDev
*Status is correct
*Platform is included
*Feature is included
*Priority and Severity correctly set
*Logs included

Hello everybody, any update on this case? Thanks.

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.

Timo, is this issue still existing?

not sure, we added a workaround for this:

"Lenovo 20JEZ2ZLUS product series contains a Intel GEN9 display with
Parade DP->HDMI passive dongle, which is not being handled well in the
Linux driver or is not responding well. After some joint debug, based
on Parade's recommendation, the short term solution is not to write on
the TMDS_OE register (0x40, offset 0x20)."

apparently support for this was supposed to land late last year, but that's not at all certain..

I will close and you feel disagree or re-open if issue still existing.