The commit
aef7db4bd5a3b6068dfa05919a3d685199eed116 fixed the problem with
recursive locking in fb blanking code if blank is caused by user setting
the /sys/class/graphics/fb*/blank. However this broke the fbcon timeout
blanking.
If you use a driver that defines ->fb_blank operation and at the same time
that driver relies on other driver (e.g. backlight or lcd class) to blank
the screen, when the fbcon times out and tries to blank the fb, it will
call only fb driver blanker and won't notify the other driver. Thus FB
output is disabled, but the screen isn't blanked.
Restore fbcon blanking and at the same time apply the proper fix for the
above problem: if fbcon_blank is called with FBINFO_FLAG_USEREVENT, we are
already called through notification from fb_blank, thus we don't have to
blank the fb again.
Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
if (!fbcon_is_inactive(vc, info)) {
if (ops->blank_state != blank) {
if (!fbcon_is_inactive(vc, info)) {
if (ops->blank_state != blank) {
ops->blank_state = blank;
fbcon_cursor(vc, blank ? CM_ERASE : CM_DRAW);
ops->cursor_flash = (!blank);
ops->blank_state = blank;
fbcon_cursor(vc, blank ? CM_ERASE : CM_DRAW);
ops->cursor_flash = (!blank);
- if (info->fbops->fb_blank)
- ret = info->fbops->fb_blank(blank, info);
- if (ret)
- fbcon_generic_blank(vc, info, blank);
+ if (!(info->flags & FBINFO_MISC_USEREVENT))
+ if (fb_blank(info, blank))
+ fbcon_generic_blank(vc, info, blank);