[2.5.21] CyberPro 32bit support and other fixes

- * Integraphics CyberPro 2000, 2010 and 5000 frame buffer device
+ * Intergraphics CyberPro 2000, 2010 and 5000 frame buffer device

Quoted 2 lines · Denis Oliver Kropp

- * Integraphics CyberPro 2000, 2010 and 5000 frame buffer device
+ * Intergraphics CyberPro 2000, 2010 and 5000 frame buffer device

This isn't actually a spelling mistake. The chips I have are quite clearly marked "Integraphics" not "Intergraphics".

drivers/video/cyber2000fb.c line 375

Quoted 11 lines

drivers/video/cyber2000fb.c +3 -1

@@ -355,7 +367,9 @@
 
 			if (regno < 16)
 				((u16 *)cfb->fb.pseudo_palette)[regno] =
-					regno | regno << 5 | regno << 11;
+					((red   << 8) & 0xf800) |
+					((green << 3) & 0x07e0) |
+					((blue  >> 3));
 			break;
 		}
 #endif

This seems wrong. We're setting up the DAC palette to map pixel color component 'regno' to 'read', 'green' and 'blue' respectively.

This means that the pseudopalette should be a 1:1 mapping of desired colour value (ie, the 16 VGA colors) to the DAC palette entries - the pseudopalette contains the pixel values to insert into the frame buffer for each of the 16 VGA colors.

Why is the pseudo palette used anyway?

There's no speed benefit and
applications running in true/direct color would look wrong.

Quoted 2 lines

Why is the pseudo palette used anyway?

Its a fast way for the console to grab the proper console index color to draw to the framebuffer. Otherwise we have to regenerate the color all the time. Plus it is always endian code for us :-)

Quoted 2 lines

There's no speed benefit and
applications running in true/direct color would look wrong.

For userland no but for the kernel we do have a benifiet.

Quoted 6 lines · James Simmons

Quoted 2 lines

Why is the pseudo palette used anyway?

Its a fast way for the console to grab the proper console index color to draw to the framebuffer. Otherwise we have to regenerate the color all the time. Plus it is always endian code for us :-)

I didn't mean the array of colors for the console, but the usage of the hardware palette for modes != 8 bit.

Quoted 4 lines

Quoted 2 lines

There's no speed benefit and
applications running in true/direct color would look wrong.

For userland no but for the kernel we do have a benifiet.

There's no speed benefit if you write "index|index|index" into the framebuffer instead of "red|green|blue".

Quoted 4 lines

Quoted 2 lines

There's no speed benefit and
applications running in true/direct color would look wrong.

For userland no but for the kernel we do have a benifiet.

There's no speed benefit if you write "index|index|index" into the framebuffer instead of "red|green|blue".

Quoted 7 lines · Denis Oliver Kropp

Quoted 4 lines

Quoted 2 lines

There's no speed benefit and
applications running in true/direct color would look wrong.

For userland no but for the kernel we do have a benifiet.

There's no speed benefit if you write "index|index|index" into the framebuffer instead of "red|green|blue".

You're actually asking the wrong question. "Why is there such a thing as directcolor" would be a better question. After all, if there's no "speed benefit" when why do manufacturers bother implementing it?

Could it be because it allows colours to be dynamically allocated? Given a "good enough" allocator which looks over your complete colour usage, you could probably make better use of the available colours than truecolor allows.