[PATCH] modesetting: Update fb_id from shadow allocate and destroy if not set

Tony Lindgren tony at atomide.com
Sat Feb 3 22:14:15 UTC 2018


* Keith Packard <keithp at keithp.com> [180203 20:33]:
> Tony Lindgren <tony at atomide.com> writes:
> > Looks like drmModeDirtyFB() stopped working at some point and we now
> > call it with fb_id of zero for rotated displays. This will stop displays
> > relying on DRM_IOCTL_MODE_DIRTYFB ioctl to display anything.
> This bug just breaks rotated displays, right?

Yes it only happens after rotating the LCD.

> > This regression probably with commit 3dcd591fa9b7 ("modesetting: Add
> > support for using RandR shadow buffers") that inroduced rotate_fb_id.
> >
> > Let's fix this issue by copying rotate_fb_id to fb_id if zero and then
> > reset it back to zero after we're done with the rotation.
> I think this fix assumes that there is only one CRTC running; if you've
> got two, one scanning from the regular fb_id and the other from a
> rotated fb_id, then you want to dirty each separately.

Hmm yes I noticed we're doing dirtyfb flushes also on the HDMI
on the same device in addition to the LCD, which seems unnecessary.

> I think the right place to fix this is in dispatch_dirty_regions, which
> should be walking the set of active CTRCs and damaging the appropriate
> fb_id for each one?

OK, Jason, any comments on this?



More information about the xorg-devel mailing list