Hi Esaki-san, On Tue, 30 Nov 2021 at 08:44, Esaki Tomohito <etom@xxxxxxxxxx> wrote: > On 2021/11/18 23:05, Laurent Pinchart wrote: > > On Thu, Nov 18, 2021 at 01:02:11PM +0000, Daniel Stone wrote: > >> Laurent's concern is that the DRM core should handle this rather than > >> open-coding in every driver, which I agree with. Some drivers (e.g. > >> radeon, maybe legacy NV?) do not support modifiers, and _also_ do > >> magic inference of the actual layout of the underlying buffer. > >> However, these drivers are legacy and we do not accept any new > >> addition of inferring layout without modifiers. > >> > >> I think the best way forward here is: > >> - add a new mode_config.cannot_support_modifiers flag, and enable > >> this in radeon (plus any other drivers in the same boat) > > > > Is there an easy way to identify the drivers that need this ? > > Should I find a driver that has not use drm_plane_funcs? I don't think there's a good way to systematically audit it. The only two I know are radeon (i.e. pre-amdgpu) and nouveau (pre-nv50), both of which pass no modifiers to drm_universal_plane_init(), but do have magic back channels to communicate tiling information. If anyone knows of any others, well, I guess we'll find out. :) > >> - change drm_universal_plane_init() to advertise the LINEAR modifier > >> when NULL is passed as the modifier list (including installing a > >> default .format_mod_supported hook) ... except when cannot_support_modifiers is set. > >> - remove the mode_config.allow_fb_modifiers hook and always > >> advertise modifier support, unless > >> mode_config.cannot_support_modifiers is set > > > > Looks good to me. > > I agree with this way, I'll try to create a patches. Thanks a lot! :) Cheers, Daniel
