Check for truecolor in a more direct way

diff --git a/src/libply/ply-frame-buffer.c b/src/libply/ply-frame-buffer.c
index beb802128830d6453213054901ea2bccf821c80c..50bb70b65310ba1724daba265fcaeab6c9c44d85 100644 (file)
--- a/src/libply/ply-frame-buffer.c
+++ b/src/libply/ply-frame-buffer.c
@@ -233,12 +233,6 @@ ply_frame_buffer_query_device (ply_frame_buffer_t *buffer)
   buffer->alpha_bit_position = variable_screen_info.transp.offset;
   buffer->bits_for_alpha = variable_screen_info.transp.length;
 
-  /* Normally the pixel is divided between the color components.
-   * If we have less bits per pixel than bits per color component,
-   * then we know we aren't using a direct color mapping.  Instead
-   * we must be using an indexed palette and a pseudocolor mode, which
-   * we don't support.
-   */
   if (variable_screen_info.bits_per_pixel <
       buffer->bits_for_red + buffer->bits_for_green + buffer->bits_for_blue)
     {
@@ -251,6 +245,20 @@ ply_frame_buffer_query_device (ply_frame_buffer_t *buffer)
       return false;
     }
 
+  /* Normally the pixel is divided into channels between the color components.
+   * Each channel directly maps to a color channel on the hardware.
+   *
+   * There are some odd ball modes that use an indexed palette instead.  In
+   * those cases (pseudocolor, direct color, etc), the pixel value is just an
+   * index into a lookup table of the real color values.
+   *
+   * We don't support that.
+   */
+  if (fixed_screen_info.visual != FB_VISUAL_TRUECOLOR)
+    {
+      return false;
+    }
+
   buffer->bytes_per_pixel = variable_screen_info.bits_per_pixel >> 3;
   buffer->row_stride = fixed_screen_info.line_length / buffer->bytes_per_pixel;
   buffer->size = buffer->area.height * buffer->row_stride * buffer->bytes_per_pixel;