[PATCH] Framebuffer ieee1275 support & test commands

[PATCH] Framebuffer ieee1275 support & test commands

[Vincent Pelletier]

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

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

Here is my patch to add support for framebuffer on IEEE1275 machines, a
fractal drawing test program, and a mouse test program.

Framebuffer support includes :
 -setting the palette colours
 -drawing a rectangle filled with a colour
 -drawing a rectangular image (may have some width & height limitations,
I had some glitches when I used a non-power-of-2 width)
 -grabbing a rectangular image from screen (not tested)
 -getting the framebuffer address (the function I provide doesn't work
for some strange reason... Should be a cast problem somewhere.
Mandelbrot command uses a workaround until I find the problem).

Mandelbrot draws directly in the framebuffer memory. It returns, but
doesn't restore the colours. It calculates the fractal, so it uses fixed
point operations (double).

As I said in a previous mail, mouse support is very limited - but it
just works :). Mouse support is actualy 100% handled by mousetest.c.
It understands Microsoft 2 buttons mouse protocol. Once started, the
mousetest command doesn't exits (except if there is an init error). The
rectangle on the top left corner of the screen shows the data received
(3 bytes, first top, msb on the left). The format is described in
mouse(4), coloured for better readability :
 red : left mouse button
 green : right moue button
 yellow : y axis
 blue : x axis
That command uses the (draw,fill)-rectangle functions, so the
framebuffer must have them (my Creator3D doesn't).
Usage :
 mousetest [screen_device mouse_device]
 default : mousetest screen mouse

Please tell me if it doesn't build on PPC as modules (Marco : It's not
the patch I sent you, I improved it a bit.) and if it doesn't work.
Marco told me he was only getting a grey image with Mandelbrot.

2005-08-25  Vincent Pelletier  <subdino2004@yahoo.fr>

	* commands/ieee1275/mandelbrot.c: New file.
	* commands/ieee1275/mousetest.c: Likewise.
	* include/grub/ieee1275/fb.h: Likewise.
	* include/grub/ieee1275/fbprops.h: Likewise.
	* video/ieee1275/fb.c: Likewise.
	* video/ieee1275/fbprops.c: Likewise.
	* conf/powerpc-ieee1275.rmk (pkgdata_MODULES): Add
	mandelbrot.mod, mousetest.mod and fb.mod.
	(mandelbrot.mod): New module.
	(mousetest.mod): Likewise.
	(fb.mod): Likewise.
	* conf/sparc64-ieee1275.rmk: Likewise.
	(grubof_HEADERS, grubof_SOURCES): Add needed files to statically
	link the commands.
	(grubof_CFLAGS): Add -DGRUB_EMBED to make commands build as
	embedded and rescue commands.
	* kern/sparc64/ieee1275/init.c: Handle the commands
	initialisation and finish when embedded.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDDZsxFEQoKRQyjtURAgtTAJ9qclafmsNNvgVkC1r8jvhP7kDZYQCffffX
koq32EYbF4X0teVkqhCQmg0=
=TF0X
-----END PGP SIGNATURE-----

[-- Attachment #2: mandel_mouse.diff --]
[-- Type: audio/x-mp3, Size: 33125 bytes --]

Re: [PATCH] Framebuffer ieee1275 support & test commands

[Hollis Blanchard]

On Aug 25, 2005, at 5:19 AM, Vincent Pelletier wrote:
>
> Here is my patch to add support for framebuffer on IEEE1275 machines, a
> fractal drawing test program, and a mouse test program.

No time for real review at the moment, but:
- you spelled "Manldebrot" wrong in the first comment
- you have lots of commented-out code present
- what is this "GRUB_EMBED" stuff?
- mouse support should be a separate patch from framebuffer support
- the "XXX Test me!" code should either be tested or removed
- I'm unclear on your distinction between "fb" and "fbprops" in file 
names.

In general I'd say this patch is not yet ready for merging.

What is your model for framebuffer drivers in general (including across 
architectures)? For example, every fb driver will provide what API, and 
should that be used by common code?

-Hollis

Re: [PATCH] Framebuffer ieee1275 support & test commands

[Vincent Pelletier]

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

Hollis Blanchard wrote:
> - you have lots of commented-out code present

Patch lines :
68 : waiting for me to fix the grub_ieee1275_fb_addr stuff.
597..600 & 949..961 : I don't know how widely these functions are
implemented in framebuffers, so I disabled them.
921 & 927 : Forgot those.

> - what is this "GRUB_EMBED" stuff?

It's to work around the fact that sparc64 doesn't support modules. So I
have to embed them inside grubof, and make them debug commands. I
thought it was obvious...
What may not be is that it has only a meaning for sparc64, and won't
have any once module support will be added.

> - I'm unclear on your distinction between "fb" and "fbprops" in file names.

fb contains needed functions to make framebuffer work. fbprops only
contains functions that make it easier (and less verbose) to get
properties of the framebuffer devices. May be merged with fb.c, may not
exist at all... I'm not sure.

> In general I'd say this patch is not yet ready for merging.

It's not ready for merging, as I don't even know if it builds on ppc as
I said in the first mail.
Moreover, I'm not sure I'll have much time to work on those next days,
so I prefer posting the patch as soon as possible in case someone want
to work on it. It could also help finding a common framebuffer API.
I should remember to tag such mails as RFC, not as PATCH...

> What is your model for framebuffer drivers in general (including across
> architectures)? For example, every fb driver will provide what API, and
> should that be used by common code?

That common API still has to be defined...
I sent some ideas in a mail some days ago.

Vincent Pelletier

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]