Skip to content

Conversation

@xz-dev
Copy link

@xz-dev xz-dev commented Dec 27, 2025

Add resolution validation in IsSupportedVidPn to prevent switching to resolutions that exceed the framebuffer segment size. This fixes an issue where dynamically resizing to a large resolution (e.g., via virt-manager window resize) would fail in CreateFrameBufferObj, leaving the display in an unrecoverable state.

Previously, when the requested resolution required more memory than the pre-allocated framebuffer segment, the driver would:

  1. Destroy the existing working framebuffer
  2. Fail to create the new larger framebuffer
  3. Leave the display inactive with no way to recover

Now the driver checks the required framebuffer size against the segment capacity in IsSupportedVidPn and rejects unsupported resolutions early, allowing Windows to gracefully handle the situation.

@gemini-code-assist
Copy link

Summary of Changes

Hello @xz-dev, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a critical validation step within the viogpu driver to prevent display instability. By checking if a desired resolution's framebuffer requirements exceed the pre-allocated segment size early in the IsSupportedVidPn function, the driver can now gracefully reject unsupported resolutions. This avoids scenarios where attempting to switch to an overly large resolution would previously lead to a destroyed display state and an unrecoverable system, significantly enhancing the robustness of dynamic display resizing.

Highlights

  • Resolution Validation: Implemented a new check within the IsSupportedVidPn function to validate if a requested display resolution's framebuffer requirements exceed the pre-allocated framebuffer segment capacity.
  • Enhanced Stability: Prevents the display from entering an unrecoverable state by rejecting resolutions that would otherwise lead to a failure in framebuffer creation after destroying the existing display configuration.
  • Graceful Error Handling: Allows Windows to gracefully handle unsupported resolutions by rejecting them early in the driver's IsSupportedVidPn call, rather than failing catastrophically during the mode switch.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@YanVugenfirer
Copy link
Collaborator

[Jenkins CI]: Can one of the admins verify this patch?

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request correctly addresses a potential crash by adding validation to reject resolutions that exceed the framebuffer's capacity. The logic to check the required size against the segment size in IsSupportedVidPn is sound and prevents the driver from entering an unrecoverable state. I've included one suggestion to refactor the new code block for improved readability and robustness by consolidating resource cleanup and removing a hardcoded value.

@xz-dev xz-dev force-pushed the viogpu-check-resolution-capacity branch 2 times, most recently from e45db2b to ffa0fc8 Compare December 27, 2025 09:17
Copy link
Collaborator

@YanVugenfirer YanVugenfirer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@xz-dev Sorry, I missed that the "Signed-off-by: Name " line is missing. Please add in all commits. It can be automated by git when you do "git commit" add "-s" command line parameter.

Thanks,
Yan

@xz-dev
Copy link
Author

xz-dev commented Jan 4, 2026

Code formatted

Add resolution validation in IsSupportedVidPn to prevent switching to
resolutions that exceed the framebuffer segment size. This fixes an issue
where dynamically resizing to a large resolution (e.g., via virt-manager
window resize) would fail in CreateFrameBufferObj, leaving the display
in an unrecoverable state.

Previously, when the requested resolution required more memory than
the pre-allocated framebuffer segment, the driver would:
1. Destroy the existing working framebuffer
2. Fail to create the new larger framebuffer
3. Leave the display inactive with no way to recover

Now the driver checks the required framebuffer size against the segment
capacity in IsSupportedVidPn and rejects unsupported resolutions early,
allowing Windows to gracefully handle the situation.

Signed-off-by: xiangzhe <[email protected]>
@xz-dev xz-dev force-pushed the viogpu-check-resolution-capacity branch from 52c0734 to ea5e808 Compare January 5, 2026 14:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants