Hi @Jani Nikula <[email protected]> Thank you for the clarifications. I've investigated the issue and determined the source of the discrepancy between the driver and firmware set display state. Firstly, it appears userspace issued a commit that completely cleared the screen. This explains why we saw all 0s without my changes. I have fixed that on our side, so I shouldn't have to worry about that when debugging.
You can do a lot of debugging based on just looking at the debug output > for the state comparison where we decide a fastset (and in this case > fastboot) is not possible. Where does the differing info come from? Is > there a readout in place? Is something completely zero in the readout, > or are there minor differences? Do you get fastsets on the second and > subsequent regular modesets? Etc. Etc. We can commit the state that's originally read from the hardware. When userspace attempts its first commit, the PLL state and clock that the driver calculates differ slightly from what the BIOS has set. This is causing us to modeset. I slightly modified how the pll state was calculated and added a small tolerance to the clock comparison; this fixes the issue, making the state seamless, but I'm not sure exactly how this should be solved. In order to avoid publishing any potentially secure information, I have created an internal bug where we can discuss exactly how to resolve this. On Tue, Mar 3, 2026 at 1:44 AM Jani Nikula <[email protected]> wrote: > On Mon, 02 Mar 2026, Manasi Navare <[email protected]> wrote: > > Hi @Jani Nikula <[email protected]> : > > > > Before we file a fdo issue with complete debug logs to understand what > the > > FW is setting up the HW at, I wanted to understand a few more things in > > terms of the final solution: > > > > - Ideally if the FW is setting up the initial state or programming the > HW > > registers for the initial splashscreen, for the initial commit when we do > > the HW state readout, it should have the HW values programmed to some > mode > > parameters > > - Then like you suggested, we would need to read out the HW state > > - Could you elaborate on "1) reading out the hw state to sw > > state? - Does that mean do the HW state readout and compute > > pipe_config/crtc_state for that? > > > > - Then add some sanitization to have this computed pipe_config that will > be > > programmed to the HW > > - Then ensure that both are same so that the intel fastset logic can > apply > > fastset? > > Let's start with the regular modesets, ignoring the probe for a bit. > > For every modeset, we have the old (current) state and the new > state. These are both software states. We compare the states to > determine whether a full modeset is required or not. This is mostly > dependent on what the hardware can change on the fly. If we can bypass a > full modeset, we call it a fastset. > > We write either the full new state (modeset) or just the changes > (fastset) to the hardware, and the new state becomes the old (current) > state. > > After that, we read back the hardware state to verify we did everything > right. This is the state checker. The comparison is done using the same > functions as for determining whether a full modeset is required. > > Rinse and repeat. > > At probe, we obviously don't have the old (current) software state. We > create it by reading out the hardware state, using the same mechanisms > as in the state checker. We call it the inherited state. We do the > initial commit with that. > > Then we arrive at the first userspace/client initiated modeset. It goes > through the same paths as the regular modeset. If we can get away with a > fastset, we call it fastboot i.e. no full modeset at boot. > > That's the basic idea, anyway. Now the caveats. > > Sometimes GOP (or whatever pre-os) ends up using slightly different > parameters for the same mode than the driver. Or we might not be able to > read out everything. Or we lose accuracy in the sw->hw->sw changes. Or > the pre-os enables stuff that it doesn't even use or care about. We > wiggle around those issues using sanitization or ignoring small > differences or simply bypassing some parts on the first modeset. > > Obviously, if there are gaps in the state readout in the first place, > the inherited state will be incomplete, and likely leads to a full > modeset. (And we also miss out on the state verification of those > parts.) > > If the GOP (or pre-os) sets a mode, and the first modeset requests a > completely different mode, you can't have fastboot either. > > The thing we absolutely can't do is what patch 2 here does. We can't > simply copy over stuff from one state to another, and hope it works. It > might appear to work by coincidence in some cases, but it is all > wrong. It ignores the computed modeset parameters for the new state, > even if userspace tries a completely different mode. It bypasses the > comparison for whether a full modeset is needed or not. It's not > discretional, it depends on what the hardware can change on the fly, and > it's undocumented at best what happens when you try to change such > things without a modeset. > > You can do a lot of debugging based on just looking at the debug output > for the state comparison where we decide a fastset (and in this case > fastboot) is not possible. Where does the differing info come from? Is > there a readout in place? Is something completely zero in the readout, > or are there minor differences? Do you get fastsets on the second and > subsequent regular modesets? Etc. Etc. > > > HTH, > Jani. > > > -- > Jani Nikula, Intel >
