Don't clip the damage rectangle against the viewport. This only works if the viewport is located at the beginning of the video memory and the video memory doesn't extend the screen (i.e., if there's no overallocation).
Fbdev emulation transfers data from write operations into a possible shadow buffer, then into a GEM buffer object, and finally via graphics driver onto the screen.
If callers write outside the currently visible area, clipping the damage rectangle against the viewport will loose these updates in the shadow buffer and the fbdev's buffer object will contain stale data. Panning the viewport to the stale area of the buffer will display obsolete data.
Instead, mark all written areas as damaged, so that the damage handler updates the buffer object from the shadow buffer for all such areas. The graphics driver's later has the option of clipping the damaged area against the viewport when updating the screen from the buffer object.
Signed-off-by: Thomas Zimmermann tzimmermann@suse.de Reviewed-by: Javier Martinez Canillas javierm@redhat.com --- drivers/gpu/drm/drm_fb_helper.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index a37fb4a980c8..87c47093c3a2 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -706,8 +706,7 @@ void drm_fb_helper_deferred_io(struct fb_info *info,
if (min < max) { y1 = min / info->fix.line_length; - y2 = min_t(u32, DIV_ROUND_UP(max, info->fix.line_length), - info->var.yres); + y2 = DIV_ROUND_UP(max, info->fix.line_length); drm_fb_helper_damage(info, 0, y1, info->var.xres, y2 - y1); } }