search for: omap_fbdev_pan_display

...e: - get_fb() doesn't work. I don't understand the point of the function. It compares fbi->fix.id and MODULE_NAME, and the "fbi->fix.id" has changed along the years so the check no longer works. Afaik, the whole function is not needed, and we can just use fbi->par. - omap_fbdev_pan_display() doesn't seem to get called when the console scrolls. I can get it called with an userspace app that does some y panning. Maybe FBINFO_HWACCEL_YWRAP is not supported anymore? Tomi > diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h b/drivers/gpu/drm/omapdrm/omap_drv.h > index 4c7217b...

...elerated panning has been broken for some time, and no one has noticed. It does: strcmp(fbi->fix.id, MODULE_NAME), which is a comparison of omapdrmdrmfb == omapdrm and always fails. Fixing that, and applying this patch, things work fine (unaccelerated, of course). I did notice a single call to omap_fbdev_pan_display() when loading the drivers. This comes from fbcon_switch -> bit_update_start -> fb_pan_display. Maybe this is from the clearing you mention above? Reviewed-by: Tomi Valkeinen <tomi.valkeinen at ti.com> Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus...

So ever since syzbot discovered fbcon, we have solid proof that it's full of bugs. And often the solution is to just delete code and remove features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code"). Now the problem is that most modern-ish drivers really only treat fbcon as an dumb kernel console until userspace takes over, and Oops printer for some emergencies. Looking at