vesafb terminal for testing.

vesafb terminal for testing.

[Vesa Jääskeläinen]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

Hi,

I have attached patch here that adds simple terminal that uses VESA BIOS
Extension 2.0+ for rendering terminal. It is not meant to be included as
is in GRUB 2, but I would hope that people would test it, so I could try
to improve it for greater compatibility (even though I have tried to
follow the standards, there might be some glitches between implementations).

This terminal driver is based on vga terminal module and contains some
common code from there, though many parts has been rewritten. When
testing this patch, make sure that you have latest CVS version of GRUB 2.

There are couple of things that I do not like in this patch.

First one is that there should be common virtual terminal for all arch's
and then separate graphics drivers that will do the actual drawing. In
this patch this is all implemented in one module and it is not as pretty
as it could be.

Second one is that this patch uses VGA BIOS fonts to draw characters and
it might cause some problems in some cards.

Third one is that there are some testing functionality (vbe_test,
vbe_list_modes) in same module, what would be best place to move those?

Now how to get started on testing:
- insmod vesafb
- Use vbe_list_modes to find mode number (eg. 0x111) that you want to use.
- set vbe_mode varible ('set vbe_mode=0x111')

To test mode:
- vbe_test

To use it in terminal:
- insmod terminal
- terminal vesafb

Thanks,
Vesa Jääskeläinen

[-- Attachment #2: grub2-term-vesafb.diff --]
[-- Type: text/plain, Size: 31187 bytes --]

Index: ChangeLog
===================================================================
RCS file: /cvsroot/grub/grub2/ChangeLog,v
retrieving revision 1.149
diff -u -r1.149 ChangeLog
--- ChangeLog	14 Aug 2005 11:04:12 -0000	1.149
+++ ChangeLog	14 Aug 2005 11:31:51 -0000
@@ -1,5 +1,13 @@
 2005-08-14  Vesa Jaaskelainen  <chaac@nic.fi>
 
+	* DISTLIST: Added term/i386/pc/vesafb.c
+	* term/i386/pc/vesafb: New file.
+	* conf/i386-pc.rmk (pkgdata_MODULES): Added vesafb.mod.
+	(vesafb_mod_SOURCES): Added.
+	(vesafb_mod_CFLAGS): Likewise.
+
+2005-08-14  Vesa Jaaskelainen  <chaac@nic.fi>
+
 	* DISTLIST: Added include/grub/i386/pc/vbe.h.
 
 2005-08-13  Yoshinori K. Okuji  <okuji@enbug.org>
Index: DISTLIST
===================================================================
RCS file: /cvsroot/grub/grub2/DISTLIST,v
retrieving revision 1.9
diff -u -r1.9 DISTLIST
--- DISTLIST	14 Aug 2005 11:04:12 -0000	1.9
+++ DISTLIST	14 Aug 2005 11:31:51 -0000
@@ -163,6 +163,7 @@
 partmap/pc.c
 partmap/sun.c
 term/i386/pc/console.c
+term/i386/pc/vesafb.c
 term/i386/pc/vga.c
 term/ieee1275/ofconsole.c
 util/i386/pc/biosdisk.c
Index: conf/i386-pc.rmk
===================================================================
RCS file: /cvsroot/grub/grub2/conf/i386-pc.rmk,v
retrieving revision 1.39
diff -u -r1.39 i386-pc.rmk
--- conf/i386-pc.rmk	12 Aug 2005 19:53:32 -0000	1.39
+++ conf/i386-pc.rmk	14 Aug 2005 11:31:56 -0000
@@ -111,7 +111,7 @@
 	font.mod _multiboot.mod ls.mod boot.mod cmp.mod cat.mod		\
 	terminal.mod fshelp.mod chain.mod multiboot.mod amiga.mod	\
 	apple.mod pc.mod sun.mod loopback.mod reboot.mod halt.mod	\
-	help.mod default.mod timeout.mod configfile.mod
+	help.mod default.mod timeout.mod configfile.mod vesafb.mod
 
 # For _chain.mod.
 _chain_mod_SOURCES = loader/i386/pc/chainloader.c
@@ -251,3 +251,7 @@
 # For configfile.mod
 configfile_mod_SOURCES = commands/configfile.c
 configfile_mod_CFLAGS = $(COMMON_CFLAGS)
+
+# For vesafb.mod.
+vesafb_mod_SOURCES = term/i386/pc/vesafb.c
+vesafb_mod_CFLAGS = $(COMMON_CFLAGS)
Index: term/i386/pc/vesafb.c
===================================================================
RCS file: term/i386/pc/vesafb.c
diff -N term/i386/pc/vesafb.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ term/i386/pc/vesafb.c	14 Aug 2005 11:31:56 -0000
@@ -0,0 +1,1169 @@
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2005  Free Software Foundation, Inc.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <grub/machine/memory.h>
+#include <grub/machine/vga.h>
+#include <grub/machine/vbe.h>
+#include <grub/machine/console.h>
+#include <grub/term.h>
+#include <grub/types.h>
+#include <grub/dl.h>
+#include <grub/misc.h>
+#include <grub/normal.h>
+#include <grub/font.h>
+#include <grub/arg.h>
+#include <grub/mm.h>
+#include <grub/env.h>
+
+#define DEFAULT_VBE_MODE    0x101
+#define DEFAULT_CHAR_WIDTH  8
+#define DEFAULT_CHAR_HEIGHT 16
+
+#define DEFAULT_FG_COLOR    0xa
+#define DEFAULT_BG_COLOR    0x0
+
+struct grub_colored_char
+{
+  /* An Unicode codepoint.  */
+  grub_uint32_t code;
+
+  /* Color indexes.  */
+  unsigned char fg_color;
+  unsigned char bg_color;
+
+  /* The width of this character minus one.  */
+  unsigned char width;
+
+  /* The column index of this character.  */
+  unsigned char index;
+};
+
+struct grub_virtual_screen
+{
+  /* Dimensions of the virual screen.  */
+  grub_uint32_t width;
+  grub_uint32_t height;
+
+  /* Offset in the display.  */
+  grub_uint32_t offset_x;
+  grub_uint32_t offset_y;
+
+  /* TTY Character sizes.  */
+  grub_uint32_t char_width;
+  grub_uint32_t char_height;
+
+  /* Virtual screen TTY size.  */
+  grub_uint32_t columns;
+  grub_uint32_t rows;
+
+  /* Current cursor details.  */
+  grub_uint32_t cursor_x;
+  grub_uint32_t cursor_y;
+  grub_uint8_t cursor_state;
+  grub_uint8_t fg_color;
+  grub_uint8_t bg_color;
+
+  /* Text buffer for virual screen. Contains (columns * rows) number
+     of entries.  */
+  struct grub_colored_char *text_buffer;
+};
+
+/* Specify "standard" VGA palette, some video cards may
+   need this and this will also be used when using RGB modes.  */
+static struct grub_vbe_palette_data vga_colors[16] =
+  {
+    // {B, G, R, A}
+    {0x00, 0x00, 0x00, 0x00}, // 0 = black
+    {0xA8, 0x00, 0x00, 0x00}, // 1 = blue
+    {0x00, 0xA8, 0x00, 0x00}, // 2 = green
+    {0xA8, 0xA8, 0x00, 0x00}, // 3 = cyan
+    {0x00, 0x00, 0xA8, 0x00}, // 4 = red
+    {0xA8, 0x00, 0xA8, 0x00}, // 5 = magenta
+    {0x00, 0x54, 0xA8, 0x00}, // 6 = brown
+    {0xA8, 0xA8, 0xA8, 0x00}, // 7 = ligth gray
+
+    {0x54, 0x54, 0x54, 0x00}, // 8 = dark gray
+    {0xFE, 0x54, 0x54, 0x00}, // 9 = bright blue
+    {0x54, 0xFE, 0x54, 0x00}, // 10 = bright green
+    {0xFE, 0xFE, 0x54, 0x00}, // 11 = bright cyan
+    {0x54, 0x54, 0xFE, 0x00}, // 12 = bright red
+    {0xFE, 0x54, 0xFE, 0x00}, // 13 = bright magenta
+    {0x54, 0xFE, 0xFE, 0x00}, // 14 = yellow
+    {0xFE, 0xFE, 0xFE, 0x00}  // 15 = white
+  };
+
+/* Make seure text buffer is not marked as allocated.  */
+static struct grub_virtual_screen virtual_screen =
+  {
+    .text_buffer = 0
+  };
+
+static grub_dl_t my_mod;
+static unsigned char *vga_font = 0;
+
+static int vbe_detected = 0;
+static int index_color_mode = 0;
+
+static struct grub_vbe_info_block controller_info;
+static struct grub_vbe_mode_info_block active_mode_info;
+
+static grub_uint32_t old_mode = 0;
+static grub_uint32_t active_mode = 0;
+
+static grub_uint8_t *framebuffer = 0;
+static grub_uint32_t bytes_per_scan_line = 0;
+
+// prototypes for helper functions
+static grub_err_t grub_vesafb_probe (void);
+static grub_err_t grub_vesafb_set_mode (grub_uint32_t mode);
+static grub_err_t grub_vesafb_get_mode (grub_uint32_t *mode);
+static grub_err_t grub_vesafb_get_mode_info (grub_uint32_t mode, struct grub_vbe_mode_info_block *mode_info);
+
+static grub_err_t
+grub_vesafb_probe (void)
+{
+  struct grub_vbe_info_block *vbe_ib;
+  grub_uint32_t rc;
+
+  /* Do not probe more than one time.  */
+  if (vbe_detected != 0)
+    {
+      return GRUB_ERR_NONE;
+    }
+
+  /* Clear old copy of controller info block.  */
+  grub_memset (&controller_info, 0, sizeof(struct grub_vbe_info_block));
+
+  /* Mark VESA BIOS extension as undetected.  */
+  vbe_detected = 0;
+
+  /* Use low memory scratch area as temporary storage for VESA BIOS call.  */
+  vbe_ib = (struct grub_vbe_info_block *) GRUB_MEMORY_MACHINE_SCRATCH_ADDR;
+
+  /* Prepare info block.  */
+  grub_memset (vbe_ib, 0, sizeof(struct grub_vbe_info_block));
+
+  vbe_ib->signature[0] = 'V';
+  vbe_ib->signature[1] = 'B';
+  vbe_ib->signature[2] = 'E';
+  vbe_ib->signature[3] = '2';
+
+  /* Try to get controller info block.  */
+  rc = grub_vbe_get_controller_info (vbe_ib);
+  if (rc != 0x004F)
+    {
+      return GRUB_ERR_BAD_DEVICE;
+    }
+
+  /* Copy it for later usage.  */
+  grub_memcpy (&controller_info,
+	       vbe_ib,
+	       sizeof(struct grub_vbe_info_block));
+
+  /* Mark VESA BIOS extension as detected.  */
+  vbe_detected = 1;
+
+  return GRUB_ERR_NONE;
+}
+
+static grub_err_t
+grub_vesafb_set_mode (grub_uint32_t mode)
+{
+  grub_uint32_t rc;
+
+  /* If grub_vesafb_probe has not been called or no VBE, abort.  */
+  if (vbe_detected == 0)
+    {
+      return GRUB_ERR_BAD_DEVICE;
+    }
+
+  /* Try to get mode info.  */
+  rc = grub_vesafb_get_mode_info (mode, &active_mode_info);
+  if (rc != GRUB_ERR_NONE)
+    {
+      return rc;
+    }
+
+  /* For all VESA BIOS modes, force linear frame buffer.  */
+  if (mode >= 0x100)
+    {
+      /* We only want linear frame buffer modes.  */
+      mode |= 1 << 14;
+
+      /* Determine frame buffer pixel format.  */
+      switch(active_mode_info.memory_model)
+	{
+	case 0x04:
+	  index_color_mode = 1;
+	  break;
+
+	case 0x06:
+	  index_color_mode = 0;
+	  break;
+
+	default:
+	  return GRUB_ERR_BAD_DEVICE;
+	}
+    }
+
+  /* Try to set video mode.  */
+  rc = grub_vbe_set_mode (mode, 0);
+  if (rc != 0x004F)
+    {
+      return GRUB_ERR_BAD_DEVICE;
+    }
+
+  /* Save information for later usage.  */
+  active_mode = mode;
+
+  if (mode < 0x100)
+    {
+      /* If this is not a VESA mode, guess address.  */
+      framebuffer = (grub_uint8_t *)0xA0000;
+      index_color_mode = 1;
+    }
+  else
+    {
+      framebuffer = (grub_uint8_t *)active_mode_info.phys_base_addr;
+
+      if (controller_info.version >= 0x300)
+	{
+	  bytes_per_scan_line = active_mode_info.lin_bytes_per_scan_line;
+	}
+      else
+	{
+	  bytes_per_scan_line = active_mode_info.bytes_per_scan_line;
+	}
+    }
+
+  return GRUB_ERR_NONE;
+}
+
+static grub_err_t
+grub_vesafb_get_mode (grub_uint32_t *mode)
+{
+  grub_uint32_t rc;
+
+  /* If grub_vesafb_probe has not been called or no VBE, abort.  */
+  if (vbe_detected == 0)
+    {
+      return GRUB_ERR_BAD_DEVICE;
+    }
+
+  /* Try to query current mode from VESA BIOS.  */
+  rc = grub_vbe_get_mode (mode);
+  if (rc != 0x004F)
+    {
+      return GRUB_ERR_BAD_DEVICE;
+    }
+
+  return GRUB_ERR_NONE;
+}
+
+static grub_err_t
+grub_vesafb_get_mode_info (grub_uint32_t mode, struct grub_vbe_mode_info_block *mode_info)
+{
+  struct grub_vbe_mode_info_block *mi_tmp = (struct grub_vbe_mode_info_block *) GRUB_MEMORY_MACHINE_SCRATCH_ADDR;
+  grub_uint32_t rc;
+
+  /* If grub_vesafb_probe has not been called or no VBE, abort.  */
+  if (vbe_detected == 0)
+    {
+      return GRUB_ERR_BAD_DEVICE;
+    }
+
+  /* If mode is not VESA mode, skip mode info query.  */
+  if (mode >= 0x100)
+    {
+      /* Try to get mode info from VESA BIOS.  */
+      rc = grub_vbe_get_mode_info (mode, mi_tmp);
+      if (rc != 0x004F)
+	{
+	  return GRUB_ERR_BAD_DEVICE;
+	}
+
+      /* Make copy of mode info block.  */
+      grub_memcpy (mode_info,
+		   mi_tmp,
+		   sizeof(struct grub_vbe_mode_info_block));
+    }
+  else
+    {
+      /* Just clear mode info block if it isn't a VESA mode.  */
+      grub_memset (mode_info,
+		   0,
+		   sizeof(struct grub_vbe_mode_info_block));
+    }
+
+  return GRUB_ERR_NONE;
+}
+
+static void
+grub_vesafb_set_pixel_rgb (grub_uint32_t x, grub_uint32_t y, grub_uint8_t red, grub_uint8_t green, grub_uint8_t blue)
+{
+  grub_uint32_t value;
+
+  if (x >= active_mode_info.x_resolution)
+    return;
+
+  if (y >= active_mode_info.y_resolution)
+    return;
+
+  if (controller_info.version >= 0x300)
+    {
+      red >>= 8 - active_mode_info.lin_red_mask_size;
+      green >>= 8 - active_mode_info.lin_green_mask_size;
+      blue >>= 8 - active_mode_info.lin_blue_mask_size;
+
+      value = red << active_mode_info.lin_red_field_position;
+      value |= green << active_mode_info.lin_green_field_position;
+      value |= blue << active_mode_info.lin_blue_field_position;
+    }
+  else
+    {
+      red >>= 8 - active_mode_info.red_mask_size;
+      green >>= 8 - active_mode_info.green_mask_size;
+      blue >>= 8 - active_mode_info.blue_mask_size;
+
+      value = red << active_mode_info.red_field_position;
+      value |= green << active_mode_info.green_field_position;
+      value |= blue << active_mode_info.blue_field_position;
+    }
+
+  if (active_mode_info.bits_per_pixel == 32)
+    {
+      grub_uint32_t *ptr = (grub_uint32_t *)(framebuffer + y * bytes_per_scan_line + x * 4);
+
+      *ptr = value;
+    }
+  else if (active_mode_info.bits_per_pixel == 24)
+    {
+      grub_uint8_t *ptr = (grub_uint8_t *)(framebuffer + y * bytes_per_scan_line + x * 3);
+      grub_uint8_t *ptr2 = (grub_uint8_t *)&value;
+
+      ptr[0] = ptr2[0];
+      ptr[1] = ptr2[1];
+      ptr[2] = ptr2[2];
+    }
+  else if ((active_mode_info.bits_per_pixel == 16) ||
+	   (active_mode_info.bits_per_pixel == 15))
+    {
+      grub_uint16_t *ptr = (grub_uint16_t *)(framebuffer + y * bytes_per_scan_line + x * 2);
+
+      *ptr = (grub_uint16_t)(value & 0xFFFF);
+    }
+}
+
+static void
+grub_vesafb_set_pixel_index(grub_uint32_t x, grub_uint32_t y, grub_uint8_t color)
+{
+  if (x >= active_mode_info.x_resolution)
+    return;
+
+  if (y >= active_mode_info.y_resolution)
+    return;
+
+  if (index_color_mode == 1)
+    {
+      grub_uint8_t *ptr = (grub_uint8_t *)(framebuffer + y * bytes_per_scan_line + x);
+
+      *ptr = color;
+    }
+  else
+    {
+      color &= 0x0F;
+
+      if (color < 16)
+	{
+	  grub_vesafb_set_pixel_rgb (x,
+				     y,
+				     vga_colors[color].red,
+				     vga_colors[color].green,
+				     vga_colors[color].blue);
+	}
+      else
+	{
+	  grub_vesafb_set_pixel_rgb (x,
+				     y,
+				     0,
+				     0,
+				     0xFF);
+	}
+  }
+}
+
+static void
+grub_virtual_screen_free (void)
+{
+  /* If virtual screen has been allocated, free it.  */
+  if (virtual_screen.text_buffer != 0)
+    {
+      grub_free (virtual_screen.text_buffer);
+    }
+
+  /* Reset virtual screen data.  */
+  grub_memset (&virtual_screen, 0, sizeof(virtual_screen));
+}
+
+static grub_err_t
+grub_virtual_screen_setup (grub_uint32_t width,
+			   grub_uint32_t height)
+{
+  /* Free old virtual screen.  */
+  grub_virtual_screen_free ();
+
+  /* Initialize with default data.  */
+  virtual_screen.width = width;
+  virtual_screen.height = height;
+  virtual_screen.offset_x = 0;
+  virtual_screen.offset_y = 0;
+  virtual_screen.char_width = DEFAULT_CHAR_WIDTH;
+  virtual_screen.char_height = DEFAULT_CHAR_HEIGHT;
+  virtual_screen.cursor_x = 0;
+  virtual_screen.cursor_y = 0;
+  virtual_screen.cursor_state = 1;
+  virtual_screen.fg_color = DEFAULT_FG_COLOR;
+  virtual_screen.bg_color = DEFAULT_BG_COLOR;
+
+  /* Calculate size of text buffer.  */
+  virtual_screen.columns = virtual_screen.width / virtual_screen.char_width;
+  virtual_screen.rows = virtual_screen.height / virtual_screen.char_height;
+
+  /* Allocate memory for text buffer.  */
+  virtual_screen.text_buffer =
+    (struct grub_colored_char *)grub_malloc (virtual_screen.columns *
+					     virtual_screen.rows *
+					     sizeof(struct grub_colored_char));
+  if (virtual_screen.text_buffer == 0)
+    {
+      return GRUB_ERR_OUT_OF_MEMORY;
+    }
+
+  return GRUB_ERR_NONE;
+}
+
+static grub_err_t
+grub_vesafb_init (void)
+{
+  grub_uint32_t rc;
+  grub_uint32_t use_mode = DEFAULT_VBE_MODE;
+  char *modevar;
+
+  /* Use fonts from VGA bios.  */
+  vga_font = grub_vga_get_font ();
+
+  /* Check if we have VESA BIOS installed.  */
+  rc = grub_vesafb_probe ();
+  if (rc != GRUB_ERR_NONE)
+    {
+      return rc;
+    }
+
+  /* Check existence of vbe_mode environment variable.  */
+  modevar = grub_env_get ("vbe_mode");
+
+  if (modevar != 0)
+    {
+      unsigned long value = 0;
+
+      if ((grub_strncmp (modevar, "0x", 2) == 0) ||
+	  (grub_strncmp (modevar, "0X", 2) == 0))
+	{
+	  /* Convert HEX mode number.  */
+	  value = grub_strtoul (modevar + 2, 0, 16);
+	}
+      else
+	{
+	  /* Convert DEC mode number.  */
+	  value = grub_strtoul (modevar, 0, 10);
+	}
+
+      if (value != 0)
+	{
+	  use_mode = value;
+	}
+    }
+
+  /* Store initial video mode.  */
+  rc = grub_vesafb_get_mode (&old_mode);
+
+  /* Setup desired graphics mode.  */
+  rc = grub_vesafb_set_mode (use_mode);
+  if (rc != GRUB_ERR_NONE)
+    {
+      return rc;
+    }
+
+  /* Create virtual screen.  */
+  rc = grub_virtual_screen_setup (active_mode_info.x_resolution,
+				  active_mode_info.y_resolution);
+  if (rc != GRUB_ERR_NONE)
+    {
+      grub_vesafb_set_mode (old_mode);
+      return rc;
+    }
+
+  /* Make sure frame buffer is black.  */
+  grub_memset (framebuffer,
+	       0,
+	       bytes_per_scan_line * active_mode_info.y_resolution);
+
+  return GRUB_ERR_NONE;
+}
+
+static grub_err_t
+grub_vesafb_fini (void)
+{
+  grub_virtual_screen_free ();
+
+  grub_vesafb_set_mode (old_mode);
+
+  return GRUB_ERR_NONE;
+}
+
+static int
+grub_virtual_screen_get_glyph (grub_uint32_t code,
+			       unsigned char bitmap[32],
+			       unsigned *width)
+{
+  if (code > 0x7f)
+    {
+      /* Map some unicode characters to the VGA font, if possible.  */
+      switch (code)
+	{
+	case 0x2190:	/* left arrow */
+	  code = 0x1b;
+	  break;
+	case 0x2191:	/* up arrow */
+	  code = 0x18;
+	  break;
+	case 0x2192:	/* right arrow */
+	  code = 0x1a;
+	  break;
+	case 0x2193:	/* down arrow */
+	  code = 0x19;
+	  break;
+	case 0x2501:	/* horizontal line */
+	  code = 0xc4;
+	  break;
+	case 0x2503:	/* vertical line */
+	  code = 0xb3;
+	  break;
+	case 0x250F:	/* upper-left corner */
+	  code = 0xda;
+	  break;
+	case 0x2513:	/* upper-right corner */
+	  code = 0xbf;
+	  break;
+	case 0x2517:	/* lower-left corner */
+	  code = 0xc0;
+	  break;
+	case 0x251B:	/* lower-right corner */
+	  code = 0xd9;
+	  break;
+
+	default:
+	  return grub_font_get_glyph (code, bitmap, width);
+	}
+    }
+
+  if (bitmap)
+    grub_memcpy (bitmap,
+		 vga_font + code * virtual_screen.char_height,
+		 virtual_screen.char_height);
+  *width = 1;
+  return 1;
+}
+
+static void
+grub_virtual_screen_invalidate_char (struct grub_colored_char *p)
+{
+  p->code = 0xFFFF;
+  
+  if (p->width)
+    {
+      struct grub_colored_char *q;
+
+      for (q = p + 1; q <= p + p->width; q++)
+	{
+	  q->code = 0xFFFF;
+	  q->width = 0;
+	  q->index = 0;
+	}
+    }
+
+  p->width = 0;
+}
+
+static void
+write_char (void)
+{
+  struct grub_colored_char *p;
+  unsigned char bitmap[32];
+  unsigned width;
+
+  p = (virtual_screen.text_buffer +
+       virtual_screen.cursor_x +
+       (virtual_screen.cursor_y * virtual_screen.columns));
+
+  p -= p->index;
+
+  if (! grub_virtual_screen_get_glyph (p->code, bitmap, &width))
+    {
+      grub_virtual_screen_invalidate_char (p);
+      width = 0;
+    }
+
+  unsigned y;
+  unsigned offset;
+
+  for (y = 0, offset = 0;
+       y < virtual_screen.char_height;
+       y++, offset++)
+    {
+      unsigned i;
+
+      for (i = 0;
+	   (i < width * virtual_screen.char_width) && (offset < 32);
+	   i++)
+	{
+	  unsigned char color;
+
+	  if (bitmap[offset] & (1<<(8-i)))
+	    {
+	      color = p->fg_color;
+	    }
+	  else
+	    {
+	      color = p->bg_color;
+	    }
+
+	  grub_vesafb_set_pixel_index(i + (virtual_screen.cursor_x * virtual_screen.char_width),
+				      y + (virtual_screen.cursor_y * virtual_screen.char_height),
+				      color);
+	}
+    }
+}
+
+static void
+write_cursor (void)
+{
+  grub_uint32_t x;
+  grub_uint32_t y;
+
+  for (y = ((virtual_screen.cursor_y + 1) * virtual_screen.char_height) - 3;
+       y < ((virtual_screen.cursor_y + 1) * virtual_screen.char_height) - 1;
+       y++)
+    {
+      for (x = virtual_screen.cursor_x * virtual_screen.char_width;
+	   x < (virtual_screen.cursor_x + 1) * virtual_screen.char_width;
+	   x++)
+	{
+	  grub_vesafb_set_pixel_index(x, y, 10);
+	}
+    }
+}
+
+static void
+scroll_up (void)
+{
+  grub_uint32_t i;
+
+  /* Scroll text buffer with one line to up.  */
+  grub_memmove (virtual_screen.text_buffer,
+		virtual_screen.text_buffer + virtual_screen.columns,
+		sizeof (struct grub_colored_char) *
+		virtual_screen.columns *
+		(virtual_screen.rows - 1));
+
+  /* Clear last line in text buffer.  */
+  for (i = virtual_screen.columns * (virtual_screen.rows - 1);
+       i < virtual_screen.columns * virtual_screen.rows;
+       i++)
+    {
+      virtual_screen.text_buffer[i].code = ' ';
+      virtual_screen.text_buffer[i].fg_color = 0;
+      virtual_screen.text_buffer[i].bg_color = 0;
+      virtual_screen.text_buffer[i].width = 0;
+      virtual_screen.text_buffer[i].index = 0;
+    }
+
+  /* Scroll frambuffer with one line to up.  */
+  grub_memmove (framebuffer,
+		framebuffer + bytes_per_scan_line * virtual_screen.char_height,
+		bytes_per_scan_line *
+		(active_mode_info.y_resolution - virtual_screen.char_height));
+
+  /* Clear last line in framebuffer.  */
+  grub_memset (framebuffer +
+	       (bytes_per_scan_line *
+		(active_mode_info.y_resolution - virtual_screen.char_height)),
+	       0,
+	       bytes_per_scan_line * virtual_screen.char_height);
+}
+
+static void
+grub_vesafb_putchar (grub_uint32_t c)
+{
+  if (c == '\a')
+    /* FIXME */
+    return;
+
+  if (c == '\b' || c == '\n' || c == '\r')
+    {
+      /* Erase current cursor, if any.  */
+      if (virtual_screen.cursor_state)
+	write_char ();
+  
+      switch (c)
+	{
+	case '\b':
+	  if (virtual_screen.cursor_x > 0)
+	    virtual_screen.cursor_x--;
+	  break;
+	  
+	case '\n':
+	  if (virtual_screen.cursor_y >= virtual_screen.rows - 1)
+	    scroll_up ();
+	  else
+	    virtual_screen.cursor_y++;
+	  break;
+	  
+	case '\r':
+	  virtual_screen.cursor_x = 0;
+	  break;
+	}
+
+      if (virtual_screen.cursor_state)
+	write_cursor ();
+    }
+  else
+    {
+      unsigned width;
+      struct grub_colored_char *p;
+      
+      grub_virtual_screen_get_glyph (c, 0, &width);
+
+      if (virtual_screen.cursor_x + width > virtual_screen.columns)
+	grub_putchar ('\n');
+
+      p = virtual_screen.text_buffer +
+	virtual_screen.cursor_x +
+	virtual_screen.cursor_y * virtual_screen.columns;
+      p->code = c;
+      p->fg_color = virtual_screen.fg_color;
+      p->bg_color = virtual_screen.bg_color;
+      p->width = width - 1;
+      p->index = 0;
+
+      if (width > 1)
+	{
+	  unsigned i;
+
+	  for (i = 1; i < width; i++)
+	    {
+	      p[i].code = ' ';
+	      p[i].width = width - 1;
+	      p[i].index = i;
+	    }
+	}
+	  
+      write_char ();
+  
+      virtual_screen.cursor_x += width;
+      if (virtual_screen.cursor_x >= virtual_screen.columns)
+	{
+	  virtual_screen.cursor_x = 0;
+	  
+	  if (virtual_screen.cursor_y >= virtual_screen.rows - 1)
+	    scroll_up ();
+	  else
+	    virtual_screen.cursor_y++;
+	}
+
+      if (virtual_screen.cursor_state)
+	write_cursor ();
+    }
+}
+
+static grub_uint16_t
+grub_virtual_screen_getwh (void)
+{
+  return (virtual_screen.columns << 8) | virtual_screen.rows;
+}
+
+static grub_uint16_t
+grub_virtual_screen_getxy (void)
+{
+  return ((virtual_screen.cursor_x << 8) | virtual_screen.cursor_y);
+}
+
+static void
+grub_vesafb_gotoxy (grub_uint8_t x, grub_uint8_t y)
+{
+  if (x >= virtual_screen.columns || y >= virtual_screen.rows)
+    {
+      grub_error (GRUB_ERR_OUT_OF_RANGE, "invalid point (%u,%u)",
+		  (unsigned) x, (unsigned) y);
+      return;
+    }
+
+  if (virtual_screen.cursor_state)
+    write_char ();
+
+  virtual_screen.cursor_x = x;
+  virtual_screen.cursor_y = y;
+
+  if (virtual_screen.cursor_state)
+    write_cursor ();
+}
+
+static void
+grub_virtual_screen_cls (void)
+{
+  grub_uint32_t i;
+
+  for (i = 0; i < virtual_screen.columns * virtual_screen.rows; i++)
+    {
+      virtual_screen.text_buffer[i].code = ' ';
+      virtual_screen.text_buffer[i].fg_color = 0;
+      virtual_screen.text_buffer[i].bg_color = 0;
+      virtual_screen.text_buffer[i].width = 0;
+      virtual_screen.text_buffer[i].index = 0;
+    }
+
+  virtual_screen.cursor_x = virtual_screen.cursor_y = 0;
+}
+
+static void
+grub_vesafb_cls (void)
+{
+  grub_virtual_screen_cls ();
+
+  grub_memset (framebuffer,
+               0, 
+	       active_mode_info.y_resolution * bytes_per_scan_line);
+}
+
+static void
+grub_virtual_screen_setcolorstate (grub_term_color_state state)
+{
+  switch (state)
+    {
+    case GRUB_TERM_COLOR_STANDARD:
+    case GRUB_TERM_COLOR_NORMAL:
+      virtual_screen.fg_color = DEFAULT_FG_COLOR;
+      virtual_screen.bg_color = DEFAULT_BG_COLOR;
+      break;
+    case GRUB_TERM_COLOR_HIGHLIGHT:
+      virtual_screen.fg_color = DEFAULT_BG_COLOR;
+      virtual_screen.bg_color = DEFAULT_FG_COLOR;
+      break;
+    default:
+      break;
+    }
+}
+
+static void
+grub_virtual_screen_setcolor (grub_uint8_t normal_color __attribute__ ((unused)),
+			      grub_uint8_t highlight_color __attribute__ ((unused)))
+{
+  /* FIXME */
+}
+
+static void
+grub_vesafb_setcursor (int on)
+{
+  if (virtual_screen.cursor_state != on)
+    {
+      if (virtual_screen.cursor_state)
+	write_char ();
+      else
+	write_cursor ();
+
+      virtual_screen.cursor_state = on;
+    }
+}
+
+static void
+*real2pm(grub_vbe_farptr_t ptr)
+{
+  return (void *)((((unsigned long)ptr & 0xFFFF0000) >> 12UL) +
+		  ((unsigned long)ptr & 0x0000FFFF));
+}
+
+static grub_err_t
+grub_cmd_vbe_list_modes(struct grub_arg_list *state __attribute__ ((unused)),
+			int argc __attribute__ ((unused)),
+			char **args __attribute__ ((unused)))
+{
+  grub_uint32_t rc;
+  grub_uint16_t *sptr;
+
+  grub_printf ("List of compatible video modes:\n");
+
+  rc = grub_vesafb_probe ();
+
+  if (rc != GRUB_ERR_NONE)
+    {
+      grub_printf ("VESA BIOS Extension not detected!\n");
+      return rc;
+    }
+
+  sptr = real2pm (controller_info.video_mode_ptr);
+
+  struct grub_vbe_mode_info_block mode_info;
+
+  for (;*sptr != 0xFFFF; sptr++)
+    {
+      int valid_mode = 1;
+
+      rc = grub_vesafb_get_mode_info (*sptr, &mode_info);
+      if (rc != GRUB_ERR_NONE) continue;
+
+      if ((mode_info.mode_attributes & 0x080) == 0)
+	{
+	  // we support only linear frame buffer modes
+	  continue;
+	}
+
+      if ((mode_info.mode_attributes & 0x010) == 0)
+	{
+	  // we allow only graphic modes
+	  continue;
+	}
+
+      switch(mode_info.memory_model)
+	{
+	case 0x04:
+	case 0x06:
+	  break;
+
+	default:
+	  valid_mode = 0;
+	  break;
+	}
+
+      if (valid_mode == 0) continue;
+
+      grub_printf ("0x%03x: %d x %d x %d bpp\n",
+                   *sptr,
+                   mode_info.x_resolution,
+                   mode_info.y_resolution,
+                   mode_info.bits_per_pixel);
+    }
+
+  char *modevar;
+
+  // Check existence of vbe_mode environment variable
+  modevar = grub_env_get ("vbe_mode");
+
+  grub_uint32_t use_mode = DEFAULT_VBE_MODE;
+
+  if (modevar != 0)
+    {
+      unsigned long value = 0;
+
+      if ((grub_strncmp (modevar, "0x", 2) == 0) ||
+	  (grub_strncmp (modevar, "0X", 2) == 0))
+	{
+	  // hex version
+	  value = grub_strtoul (modevar+2, 0, 16);
+	}
+      else
+	{
+	  // dec version
+	  value = grub_strtoul (modevar, 0, 10);
+	}
+
+      if (value != 0)
+	{
+	  use_mode = value;
+	}
+    }
+
+  grub_printf ("Configured VBE mode (vbe_mode) = 0x%03x\n", use_mode);
+
+  return 0;
+}
+
+static grub_err_t
+grub_cmd_vbe_test(struct grub_arg_list *state __attribute__ ((unused)),
+		  int argc __attribute__ ((unused)),
+		  char **args __attribute__ ((unused)))
+{
+  grub_uint32_t rc;
+  grub_uint16_t *sptr;
+  char *modevar;
+  struct grub_vbe_mode_info_block mode_info;
+  grub_uint32_t use_mode = DEFAULT_VBE_MODE;
+  unsigned char *ptr;
+  int i;
+
+  grub_printf ("Probing for VESA BIOS Extension ... ");
+
+  // Check if VESA BIOS exists
+  rc = grub_vesafb_probe();
+  if (rc != GRUB_ERR_NONE)
+    {
+      grub_printf ("not found!\n");
+      return rc;
+    }
+  grub_printf ("found!\n");
+
+  // dump out controller information
+  grub_printf ("vbe signature = %c%c%c%c\n",
+	       controller_info.signature[0],
+	       controller_info.signature[1],
+	       controller_info.signature[2],
+	       controller_info.signature[3]);
+
+  grub_printf ("vbe ver = %d.%d\n",
+	       controller_info.version >> 8,
+	       controller_info.version & 0xFF);
+  grub_printf ("oem string ptr = %08x\n",
+	       controller_info.oem_string_ptr);
+  grub_printf ("total memory = %d\n",
+	       controller_info.total_memory);
+
+  sptr = real2pm(controller_info.video_mode_ptr);
+
+  rc = grub_vesafb_get_mode(&old_mode);
+  grub_printf ("get mode rc = %04x\n", rc);
+
+  if (rc == GRUB_ERR_NONE)
+    {
+      grub_printf ("old mode = %04x\n", old_mode);
+    }
+
+  // Check existence of vbe_mode environment variable
+  modevar = grub_env_get ("vbe_mode");
+  if (modevar != 0)
+    {
+      unsigned long value = 0;
+
+      if ((grub_strncmp (modevar, "0x", 2) == 0) ||
+	  (grub_strncmp (modevar, "0X", 2) == 0))
+	{
+	  // hex version
+	  value = grub_strtoul (modevar+2, 0, 16);
+	}
+      else
+	{
+	  // dec version
+	  value = grub_strtoul (modevar, 0, 10);
+	}
+
+      if (value != 0)
+	{
+	  use_mode = value;
+	}
+    }
+
+  rc = grub_vesafb_get_mode_info (use_mode, &mode_info);
+
+  grub_printf ("mode: 0x%03x\n",
+               use_mode);
+  grub_printf ("width : %d\n",
+               mode_info.x_resolution);
+  grub_printf ("height: %d\n",
+               mode_info.y_resolution);
+  grub_printf ("memory model: %02x\n",
+               mode_info.memory_model);
+  grub_printf ("bytes/scanline: %d\n",
+               mode_info.bytes_per_scan_line);
+  grub_printf ("bytes/scanline (lin): %d\n",
+               mode_info.lin_bytes_per_scan_line);
+  grub_printf ("base address: %08x\n",
+               mode_info.phys_base_addr);
+  grub_printf ("red mask/pos: %d/%d\n",
+               mode_info.red_mask_size,
+               mode_info.red_field_position);
+  grub_printf ("green mask/pos: %d/%d\n",
+               mode_info.green_mask_size,
+               mode_info.green_field_position);
+  grub_printf ("blue mask/pos: %d/%d\n",
+               mode_info.blue_mask_size,
+               mode_info.blue_field_position);
+
+  grub_getkey ();
+
+  // setup gfx mode
+  rc = grub_vesafb_set_mode (use_mode);
+
+  rc = grub_vbe_set_palette_data (16, 0, vga_colors);
+
+  ptr = framebuffer;
+
+  for (i = 0; i < 256 * 256; i++)
+    {
+      ptr[i] = i & 0x0F;
+    }
+
+  for (i = 0; i < 100; i++)
+    {
+      ptr[active_mode_info.bytes_per_scan_line * 50 + i] = 0x0F;
+    }
+
+  grub_memset (ptr + bytes_per_scan_line * 51, 0xff, bytes_per_scan_line);
+
+  grub_getkey ();
+
+  grub_vesafb_set_mode (old_mode);
+
+  return 0;
+}
+
+static struct grub_term grub_vesafb_term =
+  {
+    .name = "vesafb",
+    .init = grub_vesafb_init,
+    .fini = grub_vesafb_fini,
+    .putchar = grub_vesafb_putchar,
+    .checkkey = grub_console_checkkey,
+    .getkey = grub_console_getkey,
+    .getwh = grub_virtual_screen_getwh,
+    .getxy = grub_virtual_screen_getxy,
+    .gotoxy = grub_vesafb_gotoxy,
+    .cls = grub_vesafb_cls,
+    .setcolorstate = grub_virtual_screen_setcolorstate,
+    .setcolor = grub_virtual_screen_setcolor,
+    .setcursor = grub_vesafb_setcursor,
+    .flags = 0,
+    .next = 0
+  };
+
+GRUB_MOD_INIT
+{
+  my_mod = mod;
+  grub_term_register (&grub_vesafb_term);
+  
+  grub_register_command ("vbe_list_modes", grub_cmd_vbe_list_modes, GRUB_COMMAND_FLAG_BOTH,
+                         "vbe_list_modes", "List's compatible VESA BIOS extension modes.", 0);
+                         
+  grub_register_command ("vbe_test", grub_cmd_vbe_test, GRUB_COMMAND_FLAG_BOTH,
+                         "vbe_test", "Test VBE", 0);  
+}
+
+GRUB_MOD_FINI
+{
+  grub_unregister_command ("vbe_test");
+  grub_unregister_command ("vbe_list_modes");
+  grub_term_unregister (&grub_vesafb_term);
+}

Re: vesafb terminal for testing.

[Yoshinori K. Okuji]

On Sunday 14 August 2005 13:52, Vesa Jääskeläinen wrote:
> I have attached patch here that adds simple terminal that uses VESA BIOS
> Extension 2.0+ for rendering terminal. It is not meant to be included as
> is in GRUB 2, but I would hope that people would test it, so I could try
> to improve it for greater compatibility (even though I have tried to
> follow the standards, there might be some glitches between
> implementations).

That's great. I will try once I finish my current task.

> First one is that there should be common virtual terminal for all arch's
> and then separate graphics drivers that will do the actual drawing. In
> this patch this is all implemented in one module and it is not as pretty
> as it could be.

Another way is to emulate VBE on other architectures... Actually, some 
firmware (such as CFE) follows this way (e.g. CFE emulates PC's VGA BIOS).

> Second one is that this patch uses VGA BIOS fonts to draw characters and
> it might cause some problems in some cards.

You should use the font manager to render characters, like the VGA terminal. 
Getting fonts from the BIOS is the last resort.

> Third one is that there are some testing functionality (vbe_test,
> vbe_list_modes) in same module, what would be best place to move those?

I think they should be in the directory commands. These may be useful even 
when the user does not use a framebuffer terminal, because Multiboot 
Specification also requires VBE support.

> Now how to get started on testing:
> - insmod vesafb
> - Use vbe_list_modes to find mode number (eg. 0x111) that you want to use.
> - set vbe_mode varible ('set vbe_mode=0x111')
>
> To test mode:
> - vbe_test
>
> To use it in terminal:
> - insmod terminal
> - terminal vesafb

Thank you for your description. Can we have your code in the CVS? It's easier 
to test, once it is merged, because we do not have to care about conflicts.

Okuji

Re: vesafb terminal for testing.

[Vesa Jääskeläinen]

Yoshinori K. Okuji wrote:
>> First one is that there should be common virtual terminal for all arch's
>> and then separate graphics drivers that will do the actual drawing. In
>> this patch this is all implemented in one module and it is not as pretty
>> as it could be.
> 
> Another way is to emulate VBE on other architectures... Actually, some 
> firmware (such as CFE) follows this way (e.g. CFE emulates PC's VGA BIOS).

I think that we still need to make modifications to interfaces, so we
have easy to use functions for "visual effects", like different blitting
operators. If these interface functions are good enough, there should
not be any need to emulate anything. Of course one can use VBE video
driver as basis for other video drivers.

I can try to draft out features that I think is needed and then we can
see what is still missing and when it is good enough then implement it.

>> Second one is that this patch uses VGA BIOS fonts to draw characters and
>> it might cause some problems in some cards.
> 
> You should use the font manager to render characters, like the VGA terminal. 
> Getting fonts from the BIOS is the last resort.

It's identical on that aspect to VGA module. But VBE 3.0 standard allows
to have modes without text output support, so this could indicate that
font's are not available in ROM for every implementation. Even though we
are using our own drawing functions there might be some cases where that
font data is invalid.

VGA module uses Unicode values above 128 from font manager and below
that it uses BIOS fonts. If our font manager provides always USASCII
fonts, then we might drop whole VGA font support.

>> Third one is that there are some testing functionality (vbe_test,
>> vbe_list_modes) in same module, what would be best place to move those?
> 
> I think they should be in the directory commands. These may be useful even 
> when the user does not use a framebuffer terminal, because Multiboot 
> Specification also requires VBE support.

Hmm... For me this indeed looks like that there has to be different vbe
module to be loaded that provides auto probing of controller data.
Perhaps some of this should even reside in the kernel for the i386?

What do you think if I create kern/i386/pc/vbe.c that contains following
from the patch:

// functions
grub_vbe_probe
grub_vbe_set_mode
grub_vbe_get_mode
grub_vbe_get_mode_info

// global variables
struct grub_vbe_info_block grub_vbe_controller_info;
struct grub_vbe_mode_info_block grub_vbe_active_mode_info;

And perhaps some others if there is a need.

Rest of the functionality could probably should be in terminal or to
separate video driver.

>> Now how to get started on testing:
>> - insmod vesafb
>> - Use vbe_list_modes to find mode number (eg. 0x111) that you want to use.
>> - set vbe_mode varible ('set vbe_mode=0x111')
>>
>> To test mode:
>> - vbe_test
>>
>> To use it in terminal:
>> - insmod terminal
>> - terminal vesafb
> 
> Thank you for your description. Can we have your code in the CVS? It's easier 
> to test, once it is merged, because we do not have to care about conflicts.

Once those couple of changes are done, I can commit it to CVS.

Thanks,
Vesa Jääskeläinen

Re: vesafb terminal for testing.

[Vladimir Serbinenko]

Vesa Jääskeläinen wrote:

>I can try to draft out features that I think is needed and then we can
>  
>
>see what is still missing and when it is good enough then implement it.
>
>  
>
But we need to let the room for the future growth. One of far-looking
plans is
"eye-candy" menu interface and we don't know yet what we will put there.
Then
if somebody wants to implement icon-based menu (icon+label for each menu
entry,
choosing with mouse and so on) he should be able to do so without
changing the
video interface function. Perhaps we should make abstract drawing interface?
If so IMHO we should take one of existing drawing interfaces like the base
(but of course it's not necessary to implement all features of the base
interfaces,
just the basic ones)

>// functions
>grub_vbe_probe
>grub_vbe_set_mode
>grub_vbe_get_mode
>grub_vbe_get_mode_info
>
>// global variables
>struct grub_vbe_info_block grub_vbe_controller_info;
>struct grub_vbe_mode_info_block grub_vbe_active_mode_info;
>
>And perhaps some others if there is a need.
>
>  
>
I'm very opposite because it's not critical for booting and it will take
place and place in kernel is critical (at least for i386). It could be
separate
modules (e.g. vesafb and vesainfo) but it must be a module. If multiboot
needs
it. It can just reference it like a dependency

                                                                        
   Vladimir

Re: vesafb terminal for testing.

[Yoshinori K. Okuji]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

On Sunday 14 August 2005 18:47, Vladimir Serbinenko wrote:
> But we need to let the room for the future growth. One of far-looking
> plans is
> "eye-candy" menu interface and we don't know yet what we will put there.

Good point. Just to give you some ideas, I attach an imaginary screenshot of a 
fancy menu interface. Please don't mind my poor sense of art. I can think of 
these effects:

- 3D background under each entry

- Animation, such as a moving rainbow on a selected title

- Fading background as the timeout count decreases.

Okuji

[-- Attachment #2: menu.jpg --]
[-- Type: image/jpeg, Size: 25389 bytes --]

Re: vesafb terminal for testing.

[Vesa Jääskeläinen]

Vladimir Serbinenko wrote:
> Vesa Jääskeläinen wrote:
> 
>> I can try to draft out features that I think is needed and then we can
>> see what is still missing and when it is good enough then implement it.
>>
> But we need to let the room for the future growth. One of far-looking
> plans is
> "eye-candy" menu interface and we don't know yet what we will put there.

Perhaps someone likes to have all features Okuji wrote in his message...
 But my idea was to make list of generic operators that will be needed
on most cases. Basic operations has been quite stable for many years.
Only thing "new" is that there are hardware acceleration for some of
them. If something tradically different comes up, then we have to think
again. But let's see what I come up.

> Then
> if somebody wants to implement icon-based menu (icon+label for each menu
> entry,
> choosing with mouse and so on) he should be able to do so without
> changing the
> video interface function. Perhaps we should make abstract drawing interface?
> If so IMHO we should take one of existing drawing interfaces like the base
> (but of course it's not necessary to implement all features of the base
> interfaces,
> just the basic ones)

Absolutely, I was thinking about generic interface. It will make it much
easier and less bug prone as everything is done using generic interface.
It eases porting to other systems too.

Remember that you have to separate behavior of the menu from the
graphics driver. Menu can be changed anyway implementors sees best fit,
but the graphics driver doesn't change that much (or at least it shouldn't).

>> // functions
>> grub_vbe_probe
>> grub_vbe_set_mode
>> grub_vbe_get_mode
>> grub_vbe_get_mode_info
>>
>> // global variables
>> struct grub_vbe_info_block grub_vbe_controller_info;
>> struct grub_vbe_mode_info_block grub_vbe_active_mode_info;
>>
>> And perhaps some others if there is a need.
>>
> I'm very opposite because it's not critical for booting and it will take
> place and place in kernel is critical (at least for i386). It could be
> separate
> modules (e.g. vesafb and vesainfo) but it must be a module. If multiboot
> needs
> it. It can just reference it like a dependency

Perhaps. Currently there is some thunks that call real mode VBE
functions in kernel. And those functions I listed are more easier to use
interfaces for some of those functions.

As far I know, GRUB 2 doesn't support dynamic loading of function entry
points, instead there are only two predefined entry points that can be
called from modules so there has to be some interface for those if they
are not implemented in kernel level. And it would be bad to duplicate
that code in several places.

I see four options here:

1) design graphics drivers interface and register it when loading
module. Pros is that it is easy to write new graphics drivers. Cons is
that we need to have then virtual screen support (not hard to make).

2) improve terminal interface. Cons for this are that terminal interface
can grow quite large and not all functions are relevant to terminal.

3) implement some generic code in kernel level. Pros is that it is
easier to interface with it. Cons are that kernel size increases.

4) design some helper function interface that could be used to make
dynamic function calls to module code. Cons are 'What happens then when
module is unloaded?'.

Perhaps there are other options ?

Thanks,
Vesa Jääskeläinen

Re: vesafb terminal for testing.

[Yoshinori K. Okuji]

On Sunday 14 August 2005 23:48, Vesa Jääskeläinen wrote:
> As far I know, GRUB 2 doesn't support dynamic loading of function entry
> points, instead there are only two predefined entry points that can be
> called from modules so there has to be some interface for those if they
> are not implemented in kernel level. And it would be bad to duplicate
> that code in several places.

Nope. GRUB 2 supports real dynamic loading. Entry points are used only when we 
want to allow symbols to be missing. So you need to implement code in the 
kernel only if it requires real mode or it is a critical function.

Okuji

Re: vesafb terminal for testing.

[Vincent Pelletier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yoshinori K. Okuji wrote:
> Just to give you some ideas,

Same here :) (from simple to ambitious) :
- -Pictures corresponding to entries (set a background/in front
of/near/instead of)
- -customisable positions for menu entries (ubuntu could out them in
circle over their logo as background, things like that)
- -Subentries (under debian, the script used to update menu.lst creates
alternative entries for linux kernel with the "single" parameter, maybe
could we allow to set different independent options.
- -some generic & skinable widgets (?)
- -mouse handling (??)

Vincent Pelletier
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDALNrFEQoKRQyjtURAuZBAKCE+qbijUbXY4ZEKvp481EQNj4/nQCgpP0A
udxXsu1nbqCpkvi0FTSUVRw=
=Xwej
-----END PGP SIGNATURE-----

	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

Re: vesafb terminal for testing.

[Vladimir Serbinenko]

>I see four options here:
>
>1) design graphics drivers interface and register it when loading
>module. Pros is that it is easy to write new graphics drivers. Cons is
>that we need to have then virtual screen support (not hard to make).
>
>  
>
Perhaps the best way

>2) improve terminal interface. Cons for this are that terminal interface
>can grow quite large 
>
>and not all functions are relevant to terminal.
>  
>
Ir would be possible to add the terminal flag TERM_VIDEO_CAPABLE and
also write video part of module between #ifdef WITH_VIDEO and so compile
twice:
with video and without. Cons: last control for terminal rendering is on the
terminal driver, so even if they use some common functions like font
rendering there is
a risk that the terminals will be different with different video driver -
bad thing and in this way we must also have virtual screen support

>3) implement some generic code in kernel level. Pros is that it is
>easier to interface with it. 
>
Why?

>Cons are that kernel size increases.
>
>4) design some helper function interface that could be used to make
>dynamic function calls to module code. Cons are 'What happens then when
>module is unloaded?'.
>
>Perhaps there are other options ?
>
>  
>
We could do like terminal support, but separate

>Thanks,
>Vesa Jääskeläinen
>
>
>  
>
                                                                        
                                       Vladimir

Re: vesafb terminal for testing.

[Vesa Jääskeläinen]

Yoshinori K. Okuji wrote:
> On Sunday 14 August 2005 23:48, Vesa Jääskeläinen wrote:
>> As far I know, GRUB 2 doesn't support dynamic loading of function entry
>> points, instead there are only two predefined entry points that can be
>> called from modules so there has to be some interface for those if they
>> are not implemented in kernel level. And it would be bad to duplicate
>> that code in several places.
> 
> Nope. GRUB 2 supports real dynamic loading. Entry points are used only when we 
> want to allow symbols to be missing. So you need to implement code in the 
> kernel only if it requires real mode or it is a critical function.

Impressive I must say :)

It was even transparent.

Now only problem is what is the best location for vbe.c that would
contain helper functions for modules that needs VBE. Currently I have it
in term/i386/pc/vbe.c but is there better location for this? And is
GRUB_MOD_INIT and GRUB_MOD_FINI mandory as I do not have need for those
in this module? Seems to work without them.

Is the file include/grub/i386/pc/vbe.h correct place to put function
prototypes?

Is directory commands/i386/pc/ correct place for commands vbe_list_modes
and vbe_test?

Thanks,
Vesa Jääskeläinen

Re: vesafb terminal for testing.

[Vladimir Serbinenko]

Vincent Pelletier wrote:

> Yoshinori K. Okuji wrote:
>
> >Just to give you some ideas,
>
>
> Same here :) (from simple to ambitious) :
> -Pictures corresponding to entries (set a background/in front
> of/near/instead of)
> -customisable positions for menu entries (ubuntu could out them in
> circle over their logo as background, things like that)
> -Subentries

Exactly the thing that I planned to do the next (it's a part of
scripting support)

> -some generic & skinable widgets (?)

We don't need to make the whole thing absolutely skinnable (just the
basic skins)
if we make like I proposed (menus like terminals, in modules) because if
someone wants to
change completely the look he can just write a new menu module.

> -mouse handling (??)
>
It must not be difficult: we can just port mouse.com from FreeDos or use
any other
mouse implementation. But here we also need the general interface because
there are different mouse types: PS/2, USB, serial (old PC), perhaps
something else
exotical. It could be something like
register_mouse_click_callback (void (*mouse_callback) (int x, int y, int
flags));
remove_mouse_click_callback (void (*mouse_callback) (int x, int y, int
flags));
and flags are like GRUB_MOUSE_LEFT, GRUB_MOUSE_RIGHT,
GRUB_MOUSE_DOUBLE,... and callback checks itself we it has to react to
this click
but mouse support can be added at any moment. Now the most important
questions is how
to make the *general/basic* things to ensure the maximum flexibility in
the future as
Yoshinori K. Okuji said in about 6 months we have to block them: don't
change them anymore.
The mouse support and fancy menu interface can be written even after but
now we must decide
what's the best way to write basic things, so we don't have to create
any incompatibility and
in preference without touching kernel code at all: just write the module
to add fancy
menu or mouse support or anything else. 

> Vincent Pelletier

                                                                        
                       Vladimir

Re: vesafb terminal for testing.

[Yoshinori K. Okuji]

On Monday 15 August 2005 17:52, Vesa Jääskeläinen wrote:
> Now only problem is what is the best location for vbe.c that would
> contain helper functions for modules that needs VBE. Currently I have it
> in term/i386/pc/vbe.c but is there better location for this?

It would be better to create a new directory. video/i386/pc/vbe.c?

> And is 
> GRUB_MOD_INIT and GRUB_MOD_FINI mandory as I do not have need for those
> in this module? Seems to work without them.

No. If you don't need to use them, you do not need to define them.

> Is the file include/grub/i386/pc/vbe.h correct place to put function
> prototypes?

Yes.

> Is directory commands/i386/pc/ correct place for commands vbe_list_modes
> and vbe_test?

Yes.

Okuji

Re: vesafb terminal for testing.

[Marco Gerards]

Vladimir Serbinenko <phcoder@gmail.com> writes:

>> -mouse handling (??)
>>
> It must not be difficult: we can just port mouse.com from FreeDos or use
> any other
> mouse implementation. But here we also need the general interface because
> there are different mouse types: PS/2, USB, serial (old PC), perhaps
> something else
> exotical. It could be something like
> register_mouse_click_callback (void (*mouse_callback) (int x, int y, int
> flags));
> remove_mouse_click_callback (void (*mouse_callback) (int x, int y, int
> flags));

In that case you expect interrupts.  The best interfaces is a function
to get X, Y and the pressed mousebuttons, AFAIK.

--
Marco

Re: vesafb terminal for testing.

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> On Sunday 14 August 2005 18:47, Vladimir Serbinenko wrote:
>> But we need to let the room for the future growth. One of far-looking
>> plans is
>> "eye-candy" menu interface and we don't know yet what we will put there.
>
> Good point. Just to give you some ideas, I attach an imaginary screenshot of a 
> fancy menu interface. Please don't mind my poor sense of art. I can think of 
> these effects:

It looks really nice.

> - 3D background under each entry
>
> - Animation, such as a moving rainbow on a selected title
>
> - Fading background as the timeout count decreases.

Perhaps we can get help and suggestions from designers instead of
programmers.  Perhaps we can contact Ubuntu, they have designers.
Perhaps a KDE or gnome team?

--
Marco

Re: vesafb terminal for testing.

[Yoshinori K. Okuji]

On Monday 15 August 2005 18:06, Vladimir Serbinenko wrote:
> We don't need to make the whole thing absolutely skinnable (just the
> basic skins)
> if we make like I proposed (menus like terminals, in modules) because if
> someone wants to
> change completely the look he can just write a new menu module.

A pluggable menu might sound good, but it's not so easy to maintain multiple 
menu interfaces. Ideally, we want to have a single implementation which 
accepts many parameters. I think it would end up with a kind of stylesheet 
like CSS in HTML.

> > -mouse handling (??)
>
> It must not be difficult: we can just port mouse.com from FreeDos or use
> any other
> mouse implementation.

It is actually difficult, because USB mouse support requires interferences 
with other USB devices. Most modern BIOSes support USB legacy interfaces, 
such as USB disks and keyboards. It is not easy not to affect them.

> Now the most important
> questions is how
> to make the *general/basic* things to ensure the maximum flexibility in
> the future as
> Yoshinori K. Okuji said in about 6 months we have to block them: don't
> change them anymore.

Don't take my argument too strictly. It can be in 6 months, in 3 months or in 
12 months. In principle, I do not want to feature-freeze GRUB 2 until we are 
satisfied enough with the design. This opportunity -- redesigning everything 
-- is really hard to obtain. Note that I had to wait for 3 years to start 
GRUB 2. So I wouldn't stop thinking how to improve GRUB very soon.

Also, as long as changes do not affect compatibility, we can add more features 
later. Indeed, I have implemented a number of new features even in GRUB 
Legacy without losing any bit of compatibility (Do you know that 0.97 is 
completely backward-compatible with 0.4?). It was quite hard sometimes but 
feasible.

Anyway, I expect that we will not have to wait too long to see what we want to 
do with a fancy menu, since Vesa is very fast to implement the code. 
Hopefully, we will see the first working version in this month or next month. 
Once it starts working, the discussion will be much easier.

Okuji

Re: vesafb terminal for testing.

[Marco Gerards]

Vesa Jääskeläinen <chaac@nic.fi> writes:

Hi Vesa,

> I have attached patch here that adds simple terminal that uses VESA BIOS
> Extension 2.0+ for rendering terminal. It is not meant to be included as
> is in GRUB 2, but I would hope that people would test it, so I could try
> to improve it for greater compatibility (even though I have tried to
> follow the standards, there might be some glitches between implementations).

Nice!  In this email I will propose some suggestions and comments on
the patch itself.

> There are couple of things that I do not like in this patch.
>
> First one is that there should be common virtual terminal for all arch's
> and then separate graphics drivers that will do the actual drawing. In
> this patch this is all implemented in one module and it is not as pretty
> as it could be.

Right, the video driver should be a new kind of interface.  It should
have functions to get/put pixels, boxes, whatever to the screen.  I am
not sure about video interfaces, but they should be simple and
generic.  In that case I can easily write a framebuffer for the PPC,
for example.

You should keep in mind that there are many depths (1, 4, 8, 16, 24 and
32 bits) that should be supported.  They all work differently.

> Second one is that this patch uses VGA BIOS fonts to draw characters and
> it might cause some problems in some cards.

We should use the font manager and nothing else IMO.

> Now how to get started on testing:
> - insmod vesafb
> - Use vbe_list_modes to find mode number (eg. 0x111) that you want to use.
> - set vbe_mode varible ('set vbe_mode=0x111')

I will test it soon.


Some comments on the patch:

>  2005-08-14  Vesa Jaaskelainen  <chaac@nic.fi>
>  
> +	* DISTLIST: Added term/i386/pc/vesafb.c
> +	* term/i386/pc/vesafb: New file.

Can you please split this up to the generic framebuffer terminal?  The
terminal for framebuffers should be generic and the videodrivers
should be arch specific.  Or do you want to do that later?

You forgot the ".c" on the last line.

> +
> +2005-08-14  Vesa Jaaskelainen  <chaac@nic.fi>
> +
>  	* DISTLIST: Added include/grub/i386/pc/vbe.h.

Why two changelog entries?  I do not see this change anywhere in the
patch.
  
> +static void
> +*real2pm(grub_vbe_farptr_t ptr)

The * is a part of the type, can you put it on the previous line?


There are some long lines, can you please make them shorter so
the maximal line length is 78 characters?

You sometimes use C++ style comments.  Can you change your comments so
they match the style described in the GCS:
http://www.gnu.org/prep/standards/html_node/Comments.html#Comments

Thanks,
Marco

Re: vesafb terminal for testing.

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> On Monday 15 August 2005 18:06, Vladimir Serbinenko wrote:
>> We don't need to make the whole thing absolutely skinnable (just the
>> basic skins)
>> if we make like I proposed (menus like terminals, in modules) because if
>> someone wants to
>> change completely the look he can just write a new menu module.
>
> A pluggable menu might sound good, but it's not so easy to maintain multiple 
> menu interfaces. Ideally, we want to have a single implementation which 
> accepts many parameters. I think it would end up with a kind of stylesheet 
> like CSS in HTML.

It would be nice if GUI's can be distributed as plugins...

Isn't XML often used to describe interfaces?  Perhaps we can use a
structured form of storing data like XML...  But that is just a random
thought. :-)

>> > -mouse handling (??)
>>
>> It must not be difficult: we can just port mouse.com from FreeDos or use
>> any other
>> mouse implementation.
>
> It is actually difficult, because USB mouse support requires interferences 
> with other USB devices. Most modern BIOSes support USB legacy interfaces, 
> such as USB disks and keyboards. It is not easy not to affect them.

It's not easy on the PC.  But AFAIK it should be easy with EFI and
IEEE 1275, but I have not taken a close look yet.

>> Now the most important
>> questions is how
>> to make the *general/basic* things to ensure the maximum flexibility in
>> the future as
>> Yoshinori K. Okuji said in about 6 months we have to block them: don't
>> change them anymore.
>
> Don't take my argument too strictly. It can be in 6 months, in 3 months or in 
> 12 months. In principle, I do not want to feature-freeze GRUB 2 until we are 
> satisfied enough with the design. This opportunity -- redesigning everything 
> -- is really hard to obtain. Note that I had to wait for 3 years to start 
> GRUB 2. So I wouldn't stop thinking how to improve GRUB very soon.

Right.

> Also, as long as changes do not affect compatibility, we can add more features 
> later. Indeed, I have implemented a number of new features even in GRUB 
> Legacy without losing any bit of compatibility (Do you know that 0.97 is 
> completely backward-compatible with 0.4?). It was quite hard sometimes but 
> feasible.

Right, but it would be the best if we think now and design the
interfaces.  We don't need to implement it all and it does not have to
be perfect, it is important to have a good foundation we can build on.

> Anyway, I expect that we will not have to wait too long to see what we want to 
> do with a fancy menu, since Vesa is very fast to implement the code. 
> Hopefully, we will see the first working version in this month or next month. 
> Once it starts working, the discussion will be much easier.

Agreed.

Thanks,
Marco

Re: vesafb terminal for testing.

[Yoshinori K. Okuji]

On Monday 15 August 2005 19:41, Marco Gerards wrote:
> It would be nice if GUI's can be distributed as plugins...

Maybe. This kind of change is easy to make later, so I'd like to stick to a 
hardcoded menu interface for now. First of all, I must make it perfectly 
working with internationalized text.

> Isn't XML often used to describe interfaces?  Perhaps we can use a
> structured form of storing data like XML...  But that is just a random
> thought. :-)

No XML, please!

XML is a holy sh*t. Do you know how many pages you must read to understand it 
completely? XML is widely used only because it is a standard, so many 
utilities are provided. XML is bloated, ugly, and space-inefficient. It would 
be interesting to think why CSS2 is not based on XML, even though nearly all 
technologies related to WWW are based on XML nowadays. The designer of CSS2 
must be a sane person.

Okuji

Re: vesafb terminal for testing.

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> On Monday 15 August 2005 19:41, Marco Gerards wrote:
>> It would be nice if GUI's can be distributed as plugins...
>
> Maybe. This kind of change is easy to make later, so I'd like to stick to a 
> hardcoded menu interface for now. First of all, I must make it perfectly 
> working with internationalized text.

Right.  But it is not a bad thing to think of it now.  Like what kind
of code can we share, etc.

>> Isn't XML often used to describe interfaces?  Perhaps we can use a
>> structured form of storing data like XML...  But that is just a random
>> thought. :-)
>
> No XML, please!

I did not say XML, what I said is some form of structure like XML.  We
can simplify it, or use something completely different.

--
Marco

Re: vesafb terminal for testing.

[Vesa Jääskeläinen]

Marco Gerards wrote:
> Some comments on the patch:
> 
>>  2005-08-14  Vesa Jaaskelainen  <chaac@nic.fi>
>>  
>> +	* DISTLIST: Added term/i386/pc/vesafb.c
>> +	* term/i386/pc/vesafb: New file.
> 
> Can you please split this up to the generic framebuffer terminal?  The
> terminal for framebuffers should be generic and the videodrivers
> should be arch specific.  Or do you want to do that later?

I'll do that later. Let's first test this beast out and when it works
then design the actual video driver. I have tried to make framebuffer
code as separate as I could have in this point.

> You forgot the ".c" on the last line.

Already fixed. Actually I noticed that typo when I first sent the patch.

>> +
>> +2005-08-14  Vesa Jaaskelainen  <chaac@nic.fi>
>> +
>>  	* DISTLIST: Added include/grub/i386/pc/vbe.h.
> 
> Why two changelog entries?  I do not see this change anywhere in the
> patch.

Before making that patch I committed some fixes to DISTLIST and that was
last entry in Changelog before starting to migrate my patch to newest
GRUB. Date on those two patches were identical so diff got "confused"
about those.

>> +static void
>> +*real2pm(grub_vbe_farptr_t ptr)
> 
> The * is a part of the type, can you put it on the previous line?

Sure. It seems that I already spotted that one :)

> There are some long lines, can you please make them shorter so
> the maximal line length is 78 characters?

Hmm... I made another scan for those. Still I left some of those there
because in my opinion it is much more readable in that way. But splitted
some lines.

> You sometimes use C++ style comments.  Can you change your comments so
> they match the style described in the GCS:
> http://www.gnu.org/prep/standards/html_node/Comments.html#Comments

I think there should not be anymore C++ style comments. It's hard to
stay away from ooooold habits :)

Fortunely I found GNU indentation mode from my editor :)... It makes
this a bit easier.

I will scan the code once more and then commit a bit different version
to CVS as Okuji asked to commit it to there for easier testing.

Re: vesafb terminal for testing.

[Marco Gerards]

Vesa Jääskeläinen <chaac@nic.fi> writes:

>> There are some long lines, can you please make them shorter so
>> the maximal line length is 78 characters?
>
> Hmm... I made another scan for those. Still I left some of those there
> because in my opinion it is much more readable in that way. But splitted
> some lines.

Can you should me which so I can come up with a suggestion?

>> You sometimes use C++ style comments.  Can you change your comments so
>> they match the style described in the GCS:
>> http://www.gnu.org/prep/standards/html_node/Comments.html#Comments
>
> I think there should not be anymore C++ style comments. It's hard to
> stay away from ooooold habits :)
>
> Fortunely I found GNU indentation mode from my editor :)... It makes
> this a bit easier.
>
> I will scan the code once more and then commit a bit different version
> to CVS as Okuji asked to commit it to there for easier testing.

Cool, fine for me. :)

Thanks,
Marco

Re: vesafb terminal for testing.

[Vesa Jääskeläinen]

Marco Gerards wrote:
> Vesa Jääskeläinen <chaac@nic.fi> writes:
> 
>>> There are some long lines, can you please make them shorter so
>>> the maximal line length is 78 characters?
>> Hmm... I made another scan for those. Still I left some of those there
>> because in my opinion it is much more readable in that way. But splitted
>> some lines.
> 
> Can you should me which so I can come up with a suggestion?

video/i386/pc/vbe.c:
- setpixel functions. There are couple of "too" long lines.
- grub_vbe_get_video_mode_info first variable definition is a bit long.

term/i386/pc/vesafb.c:
- grub_virtual_screen_setup, grub_malloc line.
- write_char, set pixel line at end.
- scroll_up, last memmove line.
- grub_virtual_screen_setcolor, function definition.
- GRUB_MOD_INIT.

commands/i386/pc/vbe_test.c:
- GRUB_MOD_INIT.

commands/i386/pc/vbe_list_modes.c:
- GRUB_MOD_INIT.

include/grub/i386/pc/vbe.h:
- several function prototypes.

>> I will scan the code once more and then commit a bit different version
>> to CVS as Okuji asked to commit it to there for easier testing.

Just a note until admins fix those commit messages, first version of vbe
terminal support is now committed. It still needs more work, but it is a
starting point.

Re: vesafb terminal for testing.

[Vesa Jääskeläinen]

Yoshinori K. Okuji wrote:

> Anyway, I expect that we will not have to wait too long to see what we want to 
> do with a fancy menu, since Vesa is very fast to implement the code. 
> Hopefully, we will see the first working version in this month or next month. 
> Once it starts working, the discussion will be much easier.

Actually, on beginning of the next week I am going for two week vacation
so it doesn't get so quickly done, but we'll see :)

Re: vesafb terminal for testing.

[Vincent Pelletier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yoshinori K. Okuji wrote:
> A pluggable menu might sound good, but it's not so easy to maintain multiple 
> menu interfaces.

I think we should only maintain some kind of API interface with an
example module, and let the community develop on it if it finds it
interesting.

> like CSS in HTML.

I like the CSS idea.
From-menu edition of the CSS sound to me as a requirement, to avoid
rebooting each time a change is made. It could be at first with
read-only from device, and maybe a hard-copy print function.

The "HTML" would be grub.cfg, but the "CSS" ?
Another file ? In the same ?
We might need to improve the grub.cfg format to handle something like
css classes. Even if we don't implement class support in our graphic
menu, I bet users will be happy to find it supported when writing their
module.
On the other hand, the "worse is better" rule would say that if the
grub.cfg format is too bad, the users will write another that would best
fit their needs.
It might be good to separate menu definition from environment
initialisation, in case the first gets redesigned they wouldn't have to
care about the second.

> USB mouse support
[...]
> Vesa

On the IEEE1275 point of view, I saw framebuffer graphic primitives in
the standard, so it *should* be easy too. And on my sun, there is a
mouse device in the OB tree.

Marco Gerards wrote:
> Right, but it would be the best if we think now and design the
> interfaces.

Maybe should we design a test-case. I'm thinking of 2~3 buttons bouncing
around the screen, with selection & click events handled (including
<tab>, <return>, <space>). That would test :
- -drawing
- -timer events (I think it's worth the implementation)
 and their regularity among different systems
- -user interaction

Vincent Pelletier
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDAYwDFEQoKRQyjtURAi83AJ99xcSmesFJL9zdC5jwiH+Pc8SiEACfeDyd
96z51HGlPugXg65G1aPhMoI=
=6hcN
-----END PGP SIGNATURE-----

	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

Re: vesafb terminal for testing.

[Vincent Pelletier]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 773 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marco Gerards wrote:
> Perhaps we can get help and suggestions from designers instead of
> programmers.  Perhaps we can contact Ubuntu, they have designers.
> Perhaps a KDE or gnome team?

Gnoppix has a really nice - Grub legacy - graphic menu, so I think it is
a good idea to contact Ubuntu.

Vincent Pelletier
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDAY2zFEQoKRQyjtURAks9AKCShtAFEucHj+7pmRgGfWovid18DgCgojWL
okb6IjD7sSMqdf2vMI5s2Rc=
=13m2
-----END PGP SIGNATURE-----

	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

Re: vesafb terminal for testing.

[Marco Gerards]

Vesa Jääskeläinen <chaac@nic.fi> writes:

> Marco Gerards wrote:
>> Vesa Jääskeläinen <chaac@nic.fi> writes:
>> 
>>>> There are some long lines, can you please make them shorter so
>>>> the maximal line length is 78 characters?
>>> Hmm... I made another scan for those. Still I left some of those there
>>> because in my opinion it is much more readable in that way. But splitted
>>> some lines.
>> 
>> Can you should me which so I can come up with a suggestion?
>
> video/i386/pc/vbe.c:
> - setpixel functions. There are couple of "too" long lines.
> - grub_vbe_get_video_mode_info first variable definition is a bit long.

      grub_uint32_t *ptr = (grub_uint32_t *)(framebuffer + y * bytes_per_scan_line + x * 4);

This can be changed in:

      grub_uint32_t *ptr;
      ptr = (grub_uint32_t *)(framebuffer + y * bytes_per_scan_line + x * 4);

or:

      grub_uint32_t *ptr = (grub_uint32_t *)(framebuffer + y *
                                             bytes_per_scan_line
                                             + x * 4);


> term/i386/pc/vesafb.c:
> - grub_virtual_screen_setup, grub_malloc line.

You fixed this already.  Please put operators on the beginning of the
next line instead of the end of the line.

> - write_char, set pixel line at end.

How about:

          grub_vbe_set_pixel_index(i + (virtual_screen.cursor_x
                                        * virtual_screen.char_width),
                                   y + (virtual_screen.cursor_y
                                        * virtual_screen.char_height),
                                   color);


> - grub_virtual_screen_setcolor, function definition.

This is a tough one, but not important I guess. :)


> commands/i386/pc/vbe_test.c:
> - GRUB_MOD_INIT.

You can split the line after the commas.

> commands/i386/pc/vbe_list_modes.c:
> - GRUB_MOD_INIT.

Same here.

> include/grub/i386/pc/vbe.h:
> - several function prototypes.

You could try to split the line after the commas for the arguments.
Sometimes it is not possible to create a shorter line and in that case
it is not important.

>>> I will scan the code once more and then commit a bit different version
>>> to CVS as Okuji asked to commit it to there for easier testing.
>
> Just a note until admins fix those commit messages, first version of vbe
> terminal support is now committed. It still needs more work, but it is a
> starting point.

Cool!  If you do receive the commit messages, can you forward them so
we could see them as well?

Thanks,
Marco

Re: vesafb terminal for testing.

[Marco Gerards]

Vincent Pelletier <subdino2004@yahoo.fr> writes:

> On the IEEE1275 point of view, I saw framebuffer graphic primitives in
> the standard, so it *should* be easy too. And on my sun, there is a
> mouse device in the OB tree.

Right, same for EFI.

> Marco Gerards wrote:
>> Right, but it would be the best if we think now and design the
>> interfaces.
>
> Maybe should we design a test-case. I'm thinking of 2~3 buttons bouncing
> around the screen, with selection & click events handled (including
> <tab>, <return>, <space>). That would test :
> -drawing
> -timer events (I think it's worth the implementation)
>  and their regularity among different systems
> -user interaction

It would be nice to have something to test the fb drivers with.

Thanks,
Marco

Re: vesafb terminal for testing.

[Vesa Jääskeläinen]

Marco Gerards wrote:
>> Just a note until admins fix those commit messages, first version of vbe
>> terminal support is now committed. It still needs more work, but it is a
>> starting point.
> 
> Cool!  If you do receive the commit messages, can you forward them so
> we could see them as well?

I did the formatting changes and committed them.

I will reformat those error messages I received and resent them to
commit-grub mailing list.

Thanks,
Vesa Jääskeläinen

Re: vesafb terminal for testing.

[Yoshinori K. Okuji]

On Sunday 14 August 2005 16:48, Yoshinori K. Okuji wrote:
> On Sunday 14 August 2005 13:52, Vesa Jääskeläinen wrote:
> > I have attached patch here that adds simple terminal that uses VESA BIOS
> > Extension 2.0+ for rendering terminal. It is not meant to be included as
> > is in GRUB 2, but I would hope that people would test it, so I could try
> > to improve it for greater compatibility (even though I have tried to
> > follow the standards, there might be some glitches between
> > implementations).
>
> That's great. I will try once I finish my current task.

So I tested it and fixed/modified many things.

I changed the command names to vbeinfo and vbetest. More compatible with the 
traditional GRUB's naming scheme.

There were issues about the coding style. For example, a function definition 
must not be like this:

int
foo(int x)

but:

int
foo (int x)

Note the space character. This is the same for casts.

Also, you needed to use GRUB's error handling. In GRUB 2, the error is not 
only a constant value, but also a message. So, whenever appropriate, you 
should use the function grub_error. (This is a big improvement from GRUB 
Legacy, really.)

Please compare the files after my changes with yours for more details.

For now, I tested it only with qemu, and haven't tested the vesafb terminal 
yet.

Okuji

Re: vesafb terminal for testing.

[Vesa Jääskeläinen]

Yoshinori K. Okuji wrote:
> On Sunday 14 August 2005 16:48, Yoshinori K. Okuji wrote:
>> On Sunday 14 August 2005 13:52, Vesa Jääskeläinen wrote:
>>> I have attached patch here that adds simple terminal that uses VESA BIOS
>>> Extension 2.0+ for rendering terminal. It is not meant to be included as
>>> is in GRUB 2, but I would hope that people would test it, so I could try
>>> to improve it for greater compatibility (even though I have tried to
>>> follow the standards, there might be some glitches between
>>> implementations).
>> That's great. I will try once I finish my current task.
> 
> So I tested it and fixed/modified many things.

Sorry it took a bit longer to check those out, but after returning from
my vacation it took some time to get back to normal day life.

Most of the changes were good ones.

I would like to know why did you add checking for reserved bit (D1) in
grub2/commands/i386/pc/vbeinfo.c around line 88. There is some notes
about this bit in standard (VBE 3.0, page 33, top of page) that tells
that after VBE 1.2 this field has always contained value 1. In light of
this I do not see need to verify for this?

Also there was small semantic change in grub_vbe_probe, now if user
provides info_block parameter, it will always call VESA BIOS to get
information even though this would be cached in second run. I have no
problem with this, but out of curiosity, was there some reason for this
change?

> I changed the command names to vbeinfo and vbetest. More compatible with the 
> traditional GRUB's naming scheme.

Ok.

> Also, you needed to use GRUB's error handling. In GRUB 2, the error is not 
> only a constant value, but also a message. So, whenever appropriate, you 
> should use the function grub_error. (This is a big improvement from GRUB 
> Legacy, really.)

Thanks for informing me about that.

Thanks,
Vesa Jääskeläinen

Re: vesafb terminal for testing.

[Yoshinori K. Okuji]

On Sunday 18 September 2005 11:03 pm, Vesa Jääskeläinen wrote:
> Sorry it took a bit longer to check those out, but after returning from
> my vacation it took some time to get back to normal day life.

Presumably you didn't sleep enough in your airplain...

> I would like to know why did you add checking for reserved bit (D1) in
> grub2/commands/i386/pc/vbeinfo.c around line 88. There is some notes
> about this bit in standard (VBE 3.0, page 33, top of page) that tells
> that after VBE 1.2 this field has always contained value 1. In light of
> this I do not see need to verify for this?

This is two different views for the same thing. :)

Since it says that D1 is always 1, I want to make sure that it is really 1. 
That's it.

> Also there was small semantic change in grub_vbe_probe, now if user
> provides info_block parameter, it will always call VESA BIOS to get
> information even though this would be cached in second run. I have no
> problem with this, but out of curiosity, was there some reason for this
> change?

As I wrote in ChangeLog, you cannot reuse the information block over multiple 
BIOS calls, because that region resides at a BIOS data area, and it is 
overwritten in next call. In fact, vbeinfo didn't show correct modes, until I 
fixed it.

But, according to Subdino, vbetest does not run twice correctly. So there must 
be still something I looked over.

Okuji

Re: vesafb terminal for testing.

[Vesa Jääskeläinen]

Yoshinori K. Okuji wrote:
> On Sunday 18 September 2005 11:03 pm, Vesa Jääskeläinen wrote:
>> Sorry it took a bit longer to check those out, but after returning from
>> my vacation it took some time to get back to normal day life.
> 
> Presumably you didn't sleep enough in your airplain...

For the first flight I tried... and for the returning flight I didn't
even try :|... A bit too small space for me :( Total travel time for a
day was something like 23 hours. But that was compensated in a couple of
days, it was the other stuff that has been keeping me away.

>> Also there was small semantic change in grub_vbe_probe, now if user
>> provides info_block parameter, it will always call VESA BIOS to get
>> information even though this would be cached in second run. I have no
>> problem with this, but out of curiosity, was there some reason for this
>> change?
> 
> As I wrote in ChangeLog, you cannot reuse the information block over multiple 
> BIOS calls, because that region resides at a BIOS data area, and it is 
> overwritten in next call. In fact, vbeinfo didn't show correct modes, until I 
> fixed it.

Perhaps you mixed this with vbeinfo code itself? Because in
grub_vbe_probe (in video/i386/pc/vbe.c) there has been grub_memcpy to
copy this information from scratch to local static variable
(controller_info) and then if caller provided non NULL pointer, it would
also be copied to caller's variable. And as this information is now
copied in static variable controller_info it can be used and cached for
later usage.

For me vbeinfo has always showed correct information, but if something
uses scratch area while walking that mode list it could give some nice
side effects. So making copy of those modes doesn't hurt. Perhaps this
should be hidden and be generalized a bit.

Let me think this a day or two (hopely not weeks) and I try to make a
some kind of draft how to implement this gfx stuff more nicely. I'll try
to take account ideas that have been posted to this list while making
that draft.

> But, according to Subdino, vbetest does not run twice correctly. So there must 
> be still something I looked over.

That is a bit odd I might say. Do you have any more details about this
problem? What exactly is wrong? Is there any way to reproduce this?

I will look at the code later on and see if I could spot something that
could be related to this.

Thanks,
Vesa Jääskeläinen

Re: vesafb terminal for testing.

[Yoshinori K. Okuji]

On Tuesday 20 September 2005 01:11 am, Vesa Jääskeläinen wrote:
> Perhaps you mixed this with vbeinfo code itself? Because in
> grub_vbe_probe (in video/i386/pc/vbe.c) there has been grub_memcpy to
> copy this information from scratch to local static variable
> (controller_info) and then if caller provided non NULL pointer, it would
> also be copied to caller's variable. And as this information is now
> copied in static variable controller_info it can be used and cached for
> later usage.

No. It copies only the *pointers* but not the data.

> That is a bit odd I might say. Do you have any more details about this
> problem? What exactly is wrong? Is there any way to reproduce this?

I don't know. I hope he can comment on this.

Okuji