Thread (3 messages) 3 messages, 2 authors, 2017-06-07
STALE3402d

[PATCH] video: fbdev: udlfb: drop log level for blanking

From: Mike Gerow <hidden>
Date: 2017-06-01 20:25:59
Subsystem: displaylink usb 2.0 framebuffer driver (udlfb), framebuffer layer, the rest · Maintainers: Bernie Thompson, Helge Deller, Linus Torvalds

Log blanking that goes from FB_BLANK_UNBLANK to itself at debug. It turns
out Xorg likes to habitually unblank when already unblanked and this can
fill up logs over a long period of time.

Signed-off-by: Mike Gerow <redacted>
---
 drivers/video/fbdev/udlfb.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index 6a3c353de7c3..611de916abcf 100644
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1105,8 +1105,17 @@ static int dlfb_ops_blank(int blank_mode, struct fb_info *info)
 	char *bufptr;
 	struct urb *urb;
 
-	pr_info("/dev/fb%d FB_BLANK mode %d --> %d\n",
-		info->node, dev->blank_mode, blank_mode);
+	/*
+	 * Xorg likes to habitually unblank when already unblanked so log these
+	 * kinds of events at debug.
+	 */
+	if (dev->blank_mode == FB_BLANK_UNBLANK &&
+	    blank_mode == FB_BLANK_UNBLANK)
+		pr_debug("/dev/fb%d FB_BLANK mode %d --> %d (FB_BLANK_UNBLANK --> FB_BLANK_UNBLANK)\n",
+			 info->node, FB_BLANK_UNBLANK, FB_BLANK_UNBLANK);
+	else
+		pr_info("/dev/fb%d FB_BLANK mode %d --> %d\n",
+			info->node, dev->blank_mode, blank_mode);
 
 	if ((dev->blank_mode == FB_BLANK_POWERDOWN) &&
 	    (blank_mode != FB_BLANK_POWERDOWN)) {
-- 
2.13.0.219.gdb65acc882-goog


-- 
Mike Gerow
gerow@google.com

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help