VMWareFB display driver development

Started by andreas_g, December 09, 2009, 11:30:10 AM

Previous topic - Next topic

andreas_g

Is anyone in here able to do a shadow framebuffer for gamma correction as described by Deek in one the previous posts?
This would be a great thing to try, at least for fast host computers.

@pl212:

I did forget about that! The version number in Default.table still says 1.00.

I will try to remember it for the next revision!
I'm glad the driver works for you!

Deek

It's actually not that difficult.

Essentially, what you do is let the window server write to the shadow FB, then whenever you're told to update the screen you copy the changed area to the real framebuffer, in the process applying your gamma ramp.

This has to be done one pixel/byte at a time, so it needs to be done as fast as possible, but the process is simple, something like this (pseudocode):

pixel = (pixel_t) shadowFB[location];

pixel.red = gamma[pixel.red];
pixel.green = gamma[pixel.green];
pixel.blue = gamma[pixel.blue];

realFB[location] = pixel;

where 'gamma' is a 256-wide array of bytes containing the pre-computed results of the power function (that is, what was passed in from setGammaRamp:), and 'pixel_t' is a packed structure with exactly the same memory layout as a framebuffer pixel. It gets more complicated if you can't create a structure that exactly matches a FB pixel (bit shifts, etc.), but it's still manageable.

Carbamide

Any chance of getting the driver to do 1024x600, like most netbooks?  I like to run OPENSTEP under VMware on my HP mini, but it only does 1024x600, so I have to run OPENSTEP at 800x600.

Appreciate any reply! :-)

Josh

andreas_g

As i don't have the skills to do the shadow framebuffer myself, i hope someone in here helps writing the code. Any help is greatly appreciated!

@carbamide:
I have updated the driver with the new display resolution (1024 x 600).
You can find it here: http://github.com/andreas-g/VMwareFB/downloads

Please give me a short feedback if it works for you.


Edit: Updated link to download page.

oneNeXT

Quote from: "andreas_g"i hope someone in here helps writing the code. Any help is greatly appreciated!

I've started writing a VMWGammaLUT object to handle gamma table,
how can I send you files, please ?

andreas_g

Very nice! You can apply it to the project using github (http://github.com/andreas-g/VMwareFB).

Or you can send me the file(s) via e-mail. I've sent you a PM with my e-mail address.


Edit: Updated link to project page.

Uli

Hi,

I just wanted to say a big thank you to everybody involved here in getting this driver to finally work with today's screen resolutions. This is really great!  :D

I remember very well how the old version of the driver worked just fine in Fusion 1 beta 1 & 2. This was enough to convince me to trust Fusion; I bought it and transferred all my data from my almost broken NeXT-Intel computer to a virtual machine. Then came beta 3 and nothing worked anymore in a reasonable screen resolution (and beta 2, of course, was time-limited).  :evil:

I contacted VMWare as well as Atomic Object several times during 2007, but I had worse luck than Andreas, and nothing came ever out of it. I also lurked in this forum regularly, but no solution was available here, either, so I basically had given up any hope when I looked again today, only to find that in the last 3 months, when I didn't look, everything changed. :D  :D

I can confirm the new driver version runs perfectly in 1600 x 1200 / 32 bit (window mode) in Fusion 3.02, Mac OS X 10.6.3.  :D

Again, a big thanks to everyone involved!

Bye

Uli

NeXT FREAK

Hi,
Thank you for a cool driver. I am pleased that a wide screen is usable very much.

Because I found tips, I report.

i)  I do not understand it somehow, but in my environment,
   NEXTSTEP3.3J and vmplayer 3.0.1,
   I had to change MemoryMaps to 0xf0000000-0xf0ffffff.
   Without this change, kernel is reboot.

ii) At "1366x768" mode, mouse cursour is drawn incorrect.
   I was able to revise it by changing the value of "modeTable".
   "rowBytes" and "totalWidth" seem to have to be eight multiples.


This is a patch
"VMWareFB.m.diff"

---------  

--- VMWareFB.m.org   Wed Mar 17 02:58:16 2010
+++ VMWareFB.m   Wed Mar 17 02:58:42 2010
@@ -99,7 +99,7 @@
   ,
   {
      /* 1366 x 768, RGB:888/32 */
-      1366, 768, 1366, 5464, 60, 0,
+      1366, 768, 1368, 5472, 60, 0,
      IO_24BitsPerPixel, IO_RGBColorSpace, "--------RRRRRRRRGGGGGGGGBBBBBBBB",
      0, 0
   }

Uli

Quote from: "NeXT FREAK"I had to change MemoryMaps to 0xf0000000-0xf0ffff.
Interesting.

Can anyone here (NeXT FREAK, Deek, ?) comment on how you actually determine these addresses?

Back in 2007, when I ran into this driver issue, I also felt that it's most probably simply an issue of too little address space. However, I knew of no rationale how to determine which numbers to enter in the driver configuration, so I could only guess and, of course, never came up with numbers that worked.

So I would be really interested how you arrived at 0xd0000000, 0xf0000000 etc.

Bye

Uli

NeXT FREAK

Quote from: "Uli"Can anyone here (NeXT FREAK, Deek, ?) comment on how you actually determine these addresses?
Hi,

- In the boot console, I found this message.
 "...Can't memory range..."..

- I searched this message in the drivers source code then
 I guessed that changing memory range was fail.

From the log file of vmplayer,
at least, in my vmplayer3.0.1 environment,
default SVGA PCI physical address is 0xf0000000.
So I have changed "MemoryMaps" to the same address for trial.

I do not understand whether it is a right method,
but the driver works well by performing this revision.


from my vmplayer's log
------------------------------------------------------------------------------------------
vcpu-0| SVGA: Registering MemSpace at 0xf0000000(0x0) and 0xe8000000(0x0)
vcpu-0| SVGA: Unregistering MemSpace at 0xf0000000(0xf0000000) and 0xe8000000(0xe8000000)
vcpu-0| SVGA: Registering MemSpace at 0xf0000000(0xf0000000) and 0xe8000000(0xe8000000)
vcpu-0| SVGA: Unregistering MemSpace at 0xf0000000(0xf0000000) and 0xe8000000(0xe8000000)
vcpu-0| SVGA: Registering IOSpace at 0x1410
vcpu-0| SVGA: Registering MemSpace at 0xf0000000(0xf0000000) and 0xe8000000(0xe8000000)

Uli

Thanks for the explanation, NeXT FREAK!  :)