Hi Sebastian, On Tue, Jan 12, 2021 at 05:24:54PM +0100, Sebastian Reichel wrote: > [dropped linux-next from Cc] > > Hi, > > On Tue, Jan 12, 2021 at 03:10:56PM +0200, Tomi Valkeinen wrote: > > >> But why is it it we need omapfb at all when we have omapdrm? > > > > > > I think there are two reasons omapfb has not been killed yet. One > > > reason was missing support for manually updated DSI panels, which > > > have been working since 1 or 2 kernel releases now. The other reason > > > is some people using it in combination with an out-of-tree PowerVR > > > kernel driver. There is currently work going on to use a more recent > > > PowerVR driver based on omapdrm driven by Maemo Leste people. > > > > omapfb also has a custom sysfs API, so applications that depend on it > > would not work anymore. I don't know if there are such applications, though. > > > > >> Can we sunset all or some parts of omap support in video/? > > >> If not, what is missing to do so. > > > > > > IDK the exact status of the PowerVR work and have not been using > > > omapfb myself for years. I don't think there is a reason to rush > > > this, so my suggestion is removing it in 3 steps giving people > > > the chance to complain: > > > > > > 1. Add 'depends on EXPERT' to 'FB_OMAP2' and add deprecation notice > > > referencing omapdrm in help text in 5.12 > > > 2. Add 'depends on BROKEN' in 5.13 > > > 3. Drop drivers/video/fbdev/omap2 afterwards > > > > I'd love to remove omapfb, but I also fear that there are still people > > using it. We can try the above sequence, but it's probably better to go > > slower, as people may not be using the latest kernels. > > I thought about this again and I think the best option is to rename > CONFIG_FB_OMAP2 to something like CONFIG_FB_OMAP2_DEPRECATED and > update the help text. That way anyone with CONFIG_FB_OMAP2 in > their .config will definitely notice the change when upgrading to > a newer kernel, but can easily fix it temporarily. Help text could > be > > "This driver will be removed in 2022, please switch to omapdrm." > > and no other intermediate steps are required that way :) The plan looks good to me. > But while looking through CONFIG_FB_OMAP2 references I noticed there > is also a V4L2 driver (CONFIG_VIDEO_OMAP2_VOUT), which seems to > only work with omapfb. IIUIC that driver provides display overlays > to V4L. I guess on omapdrm V4L can use DRM planes instead and no > driver is needed (i.e. this driver could just go away with omapfb)? One feature that the omapfb2 and the omap-vout drivers provide is rotation support with VRFB on OMAP3. I haven't moved to omapdrm on an old project for this reason. It should be possible to implement rotation support in omapdrm, but I'm not aware of any effort in that direction. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
