fblog/0008-fblog-react-on-framebuffer-events.patch

   1 From b74b9f619f1c43d75ed7f6637ef2e9d39799e3a1 Mon Sep 17 00:00:00 2001
   2 From: David Herrmann <dh.herrmann@googlemail.com>
   3 Date: Sat, 16 Jun 2012 23:24:00 +0200
   4 Subject: [PATCH 08/10] fblog: react on framebuffer events
   5
   6 This provides an fb-notifier object that can be registered with the
   7 framebuffer subsystem. We are then notified about events on all
   8 framebuffers.
   9 Most of the events are only of interest for fbcon so we can safely ignore
  10 them. However, we need to handle REGISTERED/UNBIND to add new framebbufers
  11 and we need to react on mode-changes (probably triggered by user-space).
  12
  13 Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
  14 ---
  15  drivers/video/console/fblog.c |  113 +++++++++++++++++++++++++++++++++++++++++
  16  1 file changed, 113 insertions(+)
  17
  18 diff --git a/drivers/video/console/fblog.c b/drivers/video/console/fblog.c
  19 index 5297eca..79bfbcc 100644
  20 --- a/drivers/video/console/fblog.c
  21 +++ b/drivers/video/console/fblog.c
  22 @@ -449,6 +449,119 @@ static void fblog_deactivate(void)
  23         fblog_unregister_all();
  24  }
  25
  26 +static int fblog_event(struct notifier_block *self, unsigned long action,
  27 +                      void *data)
  28 +{
  29 +       struct fb_event *event = data;
  30 +       struct fb_info *info = event->info;
  31 +       struct fblog_fb *fb = fblog_info2fb(info);
  32 +       int *blank;
  33 +
  34 +       if (action == FB_EVENT_FB_REGISTERED) {
  35 +               /* This is called when a low-level system driver registers a new
  36 +                * framebuffer. The registration lock is held but the console
  37 +                * lock might not be held when this is called (really?). */
  38 +               fblog_register(info);
  39 +               return 0;
  40 +       }
  41 +
  42 +       if (!fb)
  43 +               return 0;
  44 +
  45 +       switch(action) {
  46 +       case FB_EVENT_FB_UNREGISTERED:
  47 +               /* This is called when a low-level system driver unregisters a
  48 +                * framebuffer. The registration lock is held but the console
  49 +                * lock might not be held (really?). */
  50 +               /* ignore; see UNBIND */
  51 +               break;
  52 +       case FB_EVENT_FB_UNBIND:
  53 +               /* Called directly before unregistering an FB. The FB is still
  54 +                * valid here and the registration lock is held but the console
  55 +                * lock might not be held (really?). */
  56 +               fblog_unregister(fb);
  57 +               break;
  58 +       case FB_EVENT_SUSPEND:
  59 +               /* This is called when the low-level display driver suspends the
  60 +                * video system. We should not access the video system while it
  61 +                * is suspended. This is called with the console lock held. */
  62 +               set_bit(FBLOG_SUSPENDED, &fb->flags);
  63 +               break;
  64 +       case FB_EVENT_RESUME:
  65 +               /* This is called when the low-level display driver resumes
  66 +                * operating. It is called with the console lock held. */
  67 +               clear_bit(FBLOG_SUSPENDED, &fb->flags);
  68 +               break;
  69 +       case FB_EVENT_MODE_DELETE:
  70 +               /* This is sent when a video mode is removed. The current video
  71 +                * mode is never removed! The console lock is held while this is
  72 +                * called. */
  73 +               /* fallthrough */
  74 +       case FB_EVENT_NEW_MODELIST:
  75 +               /* This is sent when the modelist got changed. The console-lock
  76 +                * is held and we should reset the mode. */
  77 +               /* fallthrough */
  78 +       case FB_EVENT_MODE_CHANGE_ALL:
  79 +               /* This is the same as below but notifies us that the user used
  80 +                * the FB_ACTIVATE_ALL flag when setting the video mode. */
  81 +               /* fallthrough */
  82 +       case FB_EVENT_MODE_CHANGE:
  83 +               /* This is called when the _user_ changes the video mode via
  84 +                * ioctls. It is not sent, when the kernel changes the mode
  85 +                * internally. This callback is called inside fb_set_var() so
  86 +                * the console lock is held. */
  87 +               fblog_refresh(fb);
  88 +               break;
  89 +       case FB_EVENT_BLANK:
  90 +               /* This gets called _after_ the framebuffer was successfully
  91 +                * blanked. The console-lock is always held while fb_blank is
  92 +                * called and during this callback. */
  93 +               blank = (int*)event->data;
  94 +               if (*blank == FB_BLANK_UNBLANK)
  95 +                       clear_bit(FBLOG_BLANKED, &fb->flags);
  96 +               else
  97 +                       set_bit(FBLOG_BLANKED, &fb->flags);
  98 +               break;
  99 +       case FB_EVENT_GET_REQ:
 100 +               /* When fb_set_var() is called, this callback is called to get
 101 +                * our display requirements. They are then compared with the
 102 +                * display properties and only if they fulfill the requirements,
 103 +                * the new mode is activated. The console-lock should be held
 104 +                * while calling fb_set_var() so we can assume it is locked
 105 +                * here. */
 106 +               /* ignore */
 107 +               break;
 108 +       case FB_EVENT_CONBLANK:
 109 +               /* This is sent by fbcon when doing a fake blank. That
 110 +                * is, blanking the screen when the fb driver failed to perform
 111 +                * an fb_blank(). It simply writes empty lines to the screen.
 112 +                * We are not interested in this signal. We should also never
 113 +                * run together with fbcon so this should never be caught. */
 114 +               /* ignore */
 115 +               break;
 116 +       case FB_EVENT_GET_CONSOLE_MAP:
 117 +               /* fallthrough */
 118 +       case FB_EVENT_SET_CONSOLE_MAP:
 119 +               /* Is there any reason why we should support this? We
 120 +                * ignore it as we consider ourself not to be the classic linux
 121 +                * console. Hence, this request is not targeted at us. */
 122 +               /* ignore */
 123 +               break;
 124 +       case FB_EVENT_REMAP_ALL_CONSOLE:
 125 +               /* What are we supposed to do here? Do we have to remap
 126 +                * the primary device to the framebuffer given by \info? Like
 127 +                * above we currently ignore it for the same reasons. */
 128 +               /* ignore */
 129 +               break;
 130 +       }
 131 +
 132 +       return 0;
 133 +}
 134 +
 135 +static struct notifier_block fblog_notifier = {
 136 +       .notifier_call = fblog_event,
 137 +};
 138 +
 139  static void fblog_con_write(struct console *con, const char *buf,
 140                             unsigned int len)
 141  {
 142 --
 143 1.7.10.4
 144