[PATCH] modesetting: Update fb_id from shadow allocate and destroy if not set
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