Didj and Explorer: boot pixel format - Revision history

Jsujjava: Remove Category Hardware Hacking

2011-05-10T17:57:06Z

Remove Category Hardware Hacking

Jsujjava: Add Category Didj, Hardware Hacking

2011-05-10T01:07:23Z

Add Category Didj, Hardware Hacking

Reggie at 13:57, 5 November 2010

2010-11-05T13:57:13Z

Reggie at 11:34, 28 September 2010

2010-09-28T11:34:25Z

Reggie at 00:41, 28 September 2010

2010-09-28T00:41:00Z

Reggie at 00:36, 28 September 2010

2010-09-28T00:36:20Z

Reggie at 00:35, 28 September 2010

2010-09-28T00:35:29Z

Reggie at 16:38, 27 September 2010

2010-09-27T16:38:20Z

Reggie at 16:18, 27 September 2010

2010-09-27T16:18:51Z

Reggie at 15:36, 27 September 2010

2010-09-27T15:36:16Z

Show changes

← Older revision		Revision as of 17:57, 10 May 2011
Line 269:		Line 269:
	I think we need a better method for doing things, changing the background colour via ioctl doesn't seem to do much, even though the background register displays the change when queried , it might be more useful if we use layer0 as a seperate background layer, and work with either layer 1 or layer 2 as our main layer, I wonder if it's possible to allow us to pass fb1 and fb2 to the driver and have it react accordingly? Or pass the driver an 'active layer' flag?		I think we need a better method for doing things, changing the background colour via ioctl doesn't seem to do much, even though the background register displays the change when queried , it might be more useful if we use layer0 as a seperate background layer, and work with either layer 1 or layer 2 as our main layer, I wonder if it's possible to allow us to pass fb1 and fb2 to the driver and have it react accordingly? Or pass the driver an 'active layer' flag?
	[[Category:Didj]]		[[Category:Didj]]
−	~~[[Category:Hardware Hacking]]~~

← Older revision		Revision as of 01:07, 10 May 2011
Line 268:		Line 268:

	I think we need a better method for doing things, changing the background colour via ioctl doesn't seem to do much, even though the background register displays the change when queried , it might be more useful if we use layer0 as a seperate background layer, and work with either layer 1 or layer 2 as our main layer, I wonder if it's possible to allow us to pass fb1 and fb2 to the driver and have it react accordingly? Or pass the driver an 'active layer' flag?		I think we need a better method for doing things, changing the background colour via ioctl doesn't seem to do much, even though the background register displays the change when queried , it might be more useful if we use layer0 as a seperate background layer, and work with either layer 1 or layer 2 as our main layer, I wonder if it's possible to allow us to pass fb1 and fb2 to the driver and have it react accordingly? Or pass the driver an 'active layer' flag?
		+	[[Category:Didj]]
		+	[[Category:Hardware Hacking]]

← Older revision		Revision as of 13:57, 5 November 2010
Line 2:		Line 2:

	The excellent work by nirvous has given us a frame buffer driver, this is a work in progress, it currently has some hard-coded settings to make it work primarily with the gpsp gba emulator, so things like the linux boot logo don't show up in the correct colours (my tux in 565 mode has a bit of a tint, and the background for the layer is red).		The excellent work by nirvous has given us a frame buffer driver, this is a work in progress, it currently has some hard-coded settings to make it work primarily with the gpsp gba emulator, so things like the linux boot logo don't show up in the correct colours (my tux in 565 mode has a bit of a tint, and the background for the layer is red).
		+
		+	I'd like to thank Nirvous, NullMoogleCable, PhillKll, Claude, JKent, Jburks, GrizzlyAdams and anyone I may have forgotten for their help :)

@@ Line 94: / Line 94: @@
   #define BITSPP				BYTESPP*8
   #define VISUALTYPE			FB_VISUAL_TRUECOLOR //FB_VISUAL_PSEUDOCOLOR, FB_VISUAL_TRUECOLOR
-−
   /* Formats:
   * 	RGB565		= 0x4432, // 16 bits per pixel mode 2 BYTESPP
@@ Line 110: / Line 110: @@
   	ARGB8332	= 0x1120,
   	ABGR8332	= 0x9120,
-  	RGB888		= 0x4653, // 24 bits per pixel mode 3 BYTESPP
+  	RGB888	= 0x4653, // 24 bits per pixel mode 3 BYTESPP
-  	BGR888		= 0xC653,
+  	BGR888	= 0xC653,
   	XRGB8888	= 0x4653,
   	XBGR8888	= 0xC653,
@@ Line 168: / Line 168: @@
+  	  }
    //capture original mlc settings, then change to RGB565
-	original_mlcformat = ioctl(fbdev, MLC_IOCQFORMAT, 0);
+ 	original_mlcformat = ioctl(fbdev, MLC_IOCQFORMAT, 0);
-	original_mlchstride = ioctl(fbdev, MLC_IOCQHSTRIDE, 0);
+ 	original_mlchstride = ioctl(fbdev, MLC_IOCQHSTRIDE, 0);
-	original_mlcvstride = ioctl(fbdev, MLC_IOCQVSTRIDE, 0);
+ 	original_mlcvstride = ioctl(fbdev, MLC_IOCQVSTRIDE, 0);
-	ioctl(fbdev, MLC_IOCTFORMAT, 0x4432);
+ 	ioctl(fbdev, MLC_IOCTFORMAT, 0x4432);
-	ioctl(fbdev, MLC_IOCTHSTRIDE, 2);
+ 	ioctl(fbdev, MLC_IOCTHSTRIDE, 2);
-	ioctl(fbdev, MLC_IOCTVSTRIDE, 320*2);
+ 	ioctl(fbdev, MLC_IOCTVSTRIDE, 320*2);
-	ioctl(fbdev, MLC_IOCTDIRTY, 0);
+ 	ioctl(fbdev, MLC_IOCTDIRTY, 0);
-	printf("mlc framebuffer: @ %08lx\n", fb_paddr[0]);
+ 	printf("mlc framebuffer: @ %08lx\n", fb_paddr[0]);
+   }
@@ Line 200: / Line 200: @@
 Simple to rectify in this instance, copy the mlc code for handling the mode and format settings, the else should now look like this:
     else
+  {
@@ Line 211: / Line 210: @@
   // copied and pasted by reggie
   //capture original mlc settings, then change to RGB565
-	ioctl(fbdev, MLC_IOCTENABLE, 1); // added by reggie
+ 	ioctl(fbdev, MLC_IOCTENABLE, 1); // added by reggie
   	original_mlcformat = ioctl(fbdev, MLC_IOCQFORMAT, 0);
   	original_mlchstride = ioctl(fbdev, MLC_IOCQHSTRIDE, 0);

@@ Line 80: / Line 80: @@
               fbi->fb.var.transp.length   = 0;
               fbi->pix_fmt                = 0x8653;
               break;
           default:
@@ Line 97: / Line 88: @@
-The important parts here are the offset, length and the pix_fmt variables. The there is a list of the possible pix_fmt values in lf1000fb.h, I have commented the ones we use above, you can also see where BYTESPP and how BITSPP are set:
+The important parts here are the offset, length and the pix_fmt variables. There is a list of the possible pix_fmt values in lf1000fb.h, I have commented the ones we use above, you can also see where BYTESPP and how BITSPP are set:
   #define BYTESPP				2

@@ Line 79: / Line 79: @@
               fbi->fb.var.transp.offset   = 0;
               fbi->fb.var.transp.length   = 0;
-              fbi->pix_fmt                = 0x8653;             fbi->fb.var.red.offset      = 0;//0 for bgr. 16 for rgb
+              fbi->pix_fmt                = 0x8653;
               fbi->fb.var.red.length      = 8;
               fbi->fb.var.green.offset    = 8;

@@ Line 13: / Line 13: @@
-The reason for the boot logo being dkewed is the default pixel format and some other non default settings, the available pixel formats are:
+The reason for the boot logo being skewed is the default pixel format and some other non default settings, the available pixel formats are:
 RGB565-8bit (not sure what this mode is exactly)
@@ Line 93: / Line 93: @@
+      }
-<code/>
+</code>

@@ Line 1: / Line 1: @@
 Tutorial to help the user set a framebuffer pixel format that will display the boot logo correctly.
-The excellent work by nirvous has given us a framebuffer driver, this is a work in progress, it current has some hardcoded settings to make it work primarily with the gpsp gba emulator, so things like the linux boot logo don't show up in the correct colours (my tux in 565 mode has a bit of a tint, and the background for the layer is red).
+The excellent work by nirvous has given us a frame buffer driver, this is a work in progress, it currently has some hard-coded settings to make it work primarily with the gpsp gba emulator, so things like the linux boot logo don't show up in the correct colours (my tux in 565 mode has a bit of a tint, and the background for the layer is red).
@@ Line 8: / Line 8: @@
   Explorer kernel Sources with lf1000fb drivers already patched in
   correctly set environment variables
-  lf1000 framebuffer drivers from nirvous github
+  lf1000 frame buffer drivers from nirvous github
   gpsp sources from nirvous github (optional)
-The reason for the boot logo being is the default pixel format, the available pixel formats are:
+The reason for the boot logo being dkewed is the default pixel format and some other non default settings, the available pixel formats are:
 RGB565-8bit (not sure what this mode is exactly)
 RGB565-16bit (Default)
 RGB888-24bit (this and 32bit are pretty much used universally for images like jpg,bmp,png etc.)
-ARGB888-32bit (like RGB888 24bit but with a transparency byte?)
+ABGR888-32bit (like BGR888 24bit but with a transparency byte?)
@@ Line 274: / Line 274: @@
 '''Notes'''
-I think we need a better method for doing things, changing the background colour doesn't seem to do much, it might be more useful if we use layer0 as a seperate background layer, and work with either layer 1 or layer 2 as our main layer, I wonder if its possible to allow us to pass fb1 and fb2 to the driver and have it react accordingly?  Or pass the driver an 'active layer' flag?
+I think we need a better method for doing things, changing the background colour via ioctl doesn't seem to do much, even though the background register displays the change when queried , it might be more useful if we use layer0 as a seperate background layer, and work with either layer 1 or layer 2 as our main layer, I wonder if it's possible to allow us to pass fb1 and fb2 to the driver and have it react accordingly?  Or pass the driver an 'active layer' flag?

← Older revision		Revision as of 16:18, 27 September 2010
Line 234:		Line 234:
	Testing it now shows that gpsp will work with 24 and 32bit modes, we get the added bonus that we've cleaned up another little gpsp quirk, quitting the app. no longer stops other apps and gpsp from displaying an image, before this (at least for me) gpsp would load fine the first time, then anything else I loaded after that wouldn't display anything on screen.		Testing it now shows that gpsp will work with 24 and 32bit modes, we get the added bonus that we've cleaned up another little gpsp quirk, quitting the app. no longer stops other apps and gpsp from displaying an image, before this (at least for me) gpsp would load fine the first time, then anything else I loaded after that wouldn't display anything on screen.

−	I've added the MLC_IOCTENABLE control to the routine as well, this is used because we are going to disable the layer on exit, this will tidy up the	+	I've added the MLC_IOCTENABLE control to the routine as well, this is used because we are going to disable the layer on exit, this will tidy up the screen when gpsp has finished but obviously breaks other apps that don't enable the layer when they open the framebuffer, we should really be doing this in the framebuffer driver I think.
		+
		+
		+	static void fb_video_exit()
		+	{
		+	int ret;
		+	/* switch to default fb mem, turn portrait off */
		+	//nirvous comments out support for layer1
		+	//gpsp_gp2x_memregl[0x406C>>2] = fb_paddr[0];
		+	//gpsp_gp2x_memregl[0x4058>>2] \|= 0x10;
		+	//nirvous adds support for layer0
		+	gpsp_gp2x_memregl[0x4038>>2] = fb_paddr[0];
		+	gpsp_gp2x_memregl[0x4024>>2] \|= 0x10;
		+	wiz_lcd_set_portrait(0);
		+	ret = ioctl(fbdev, MLC_IOCQADDRESS, 0);
		+	if (ret == -1)
		+	{
		+	//nirvous - restore original mlc settings
		+	ioctl(fbdev, MLC_IOCTFORMAT, original_mlcformat);
		+	ioctl(fbdev, MLC_IOCTHSTRIDE, original_mlchstride);
		+	ioctl(fbdev, MLC_IOCTVSTRIDE, original_mlcvstride);
		+	ioctl(fbdev, MLC_IOCTENABLE, 0); // added by reggie
		+	ioctl(fbdev, MLC_IOCTDIRTY, 0);
		+	close(fbdev);
		+	}
		+	else
		+	{
		+	//nirvous - restore original mlc settings
		+	ioctl(fbdev, MLC_IOCTFORMAT, original_mlcformat);
		+	ioctl(fbdev, MLC_IOCTHSTRIDE, original_mlchstride);
		+	ioctl(fbdev, MLC_IOCTVSTRIDE, original_mlcvstride);
		+	ioctl(fbdev, MLC_IOCTENABLE, 0); // added by reggie
		+	ioctl(fbdev, MLC_IOCTDIRTY, 0);
		+	close(fbdev);
		+	}
		+	}
		+
		+
		+	'''Notes'''
		+
		+	I think we need a better method for doing things, changing the background colour doesn't seem to do much, it might be more useful if we use layer0 as a seperate background layer, and work with either layer 1 or layer 2 as our main layer, I wonder if its possible to allow us to pass fb1 and fb2 to the driver and have it react accordingly? Or pass the driver an 'active layer' flag?