On Thu, Apr 11, 2024 at 5:27 PM Ian Forbes <ian.forbes@xxxxxxxxxxxx> wrote: > > Fixes a bug where modes that are too large for the device are exposed > and set causing a black screen on boot. > > Resending as Patchwork did not like my last submission. > > Ian Forbes (4): > drm/vmwgfx: Filter modes which exceed graphics memory > drm/vmwgfx: 3D disabled should not effect STDU memory limits > drm/vmwgfx: Remove STDU logic from generic mode_valid function > drm/vmwgfx: Standardize use of kibibytes when logging > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 19 ++++------- > drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 3 -- > drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 4 +-- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 26 ++++++--------- > drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 32 ++++++++++++++++++- > 5 files changed, 48 insertions(+), 36 deletions(-) > In general that looks great! Two questions: - with stdu what happens when the mode selected is close to our limits, the guest is using a hardware cursor and we allocate cursor mobs? - with legacy du, is general mode selection with modes close to vram size working? And one comment: in series like those, be careful with fixes tags if the patches depend on each other, i.e. the third one depends on the first but they have different fixes tags so they're disconnected. It's a good idea to keep distro kernel maintainers in mind with those and try to organize the patches in a way that makes it a bit more clearer that #3 depends on #1. It should be fine in this case though. z
