Thread (16 messages) 16 messages, 3 authors, 2012-06-18

Re: [PATCH 05/10] fblog: add framebuffer helpers

From: David Herrmann <hidden>
Date: 2012-06-18 18:50:16
Also in: linux-serial, lkml

Hi Bruno

On Sun, Jun 17, 2012 at 12:33 AM, Bruno Prémont
[off-list ref] wrote:
On Sun, 17 June 2012 David Herrmann [off-list ref] wrote:
quoted
These helpers scan the system for all available framebuffers and register
or unregister them. This is needed during startup and stopping fblog so we
are aware of all connected displays.

The third helper handles mode changes by rescanning the mode and adjusting
the buffer size.

Signed-off-by: David Herrmann <redacted>
---
 drivers/video/console/fblog.c |   29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
index e790971..7d4032e 100644
--- a/drivers/video/console/fblog.c
+++ b/drivers/video/console/fblog.c
@@ -399,6 +399,35 @@ static void fblog_unregister(struct fblog_fb *fb)
      kfree(fb);
 }

+static void fblog_register_all(void)
+{
+     int i;
+
+     for (i = 0; i < FB_MAX; ++i)
+             fblog_register(registered_fb[i]);
You should take registration_lock mutex for accessing registered_fb[],
even better would be to make use of get_fb_info() and put_fb_info()
Indeed, I will change it to use get_fb_info()/put_fb_info().

Btw., is it safe to call console_lock() during
FB_EVENT_FB_(UN)REGISTERED? I definitely need the console lock when
calling fblog_register() but I am not sure whether all fb-drivers lock
the console during "(un)register_framebuffer()". Otherwise, I would
have to avoid redrawing the console inside of fblog_register().
quoted
+}
+
+static void fblog_unregister_all(void)
+{
+     int i;
+
+     for (i = 0; i < FB_MAX; ++i)
+             fblog_unregister(fblog_info2fb(registered_fb[i]));
Same here.

Though for unregistering I'm wondering why you still scan through
registered_fb[], you should just scan your fblog_fbs[] array!
Oops, you're right. I will change it.
But here again, make sure to have proper locking to not get races with
registration of new framebuffers or removal of existing ones via
notifications.
quoted
+}
+
+static void fblog_refresh(struct fblog_fb *fb)
+{
+     unsigned int width, height;
+
+     if (!fb || !fb->font)
+             return;
+
+     width = fb->info->var.xres / fb->font->width;
+     height = fb->info->var.yres / fb->font->height;
+     fblog_buf_resize(&fb->buf, width, height);
+     fblog_redraw(fb);
+}
+
All these new functions are still unused, for easier following of your
patch series it would be nice to have them connected when they are
introduced as otherwise on has to search all following patches for
finding possible users.
I have to admit the split was crap. I am sorry. I will recreate the
patchset with a proper split. Thanks!
quoted
 static int __init fblog_init(void)
 {
      return 0;
Bruno
Thanks for reviewing, regards
David
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help