Dear NeXT community!
I just want to tell you that i am in contact with david from "atomic object". They have developed the VMWareFB display driver for NeXTStep, OPENSTEP and Rhapsody. As there are some issues with the driver, i asked about the actual state of development. Thanks to david for allowing me to share the mail with the NeXT community:
Q:
Dear Atomic Object team!
I want to thank you for writing the display driver for NeXTStep/OPENSTEP under VMWare! I am using NeXTStep 3.3 unter VMWare Fusion v2.0.6 on Mac OS X v10.6. It works great for a resolution of 1024 x 768 with millions of colours.
But i am having some trouble with the driver. Resolutions greater than 1024 x 768 do not work and crash the virtual machine. I think this is a common issue also for other versions of VMWare.
I know this driver might not be for great interest for you but anyway i want to ask if there is any chance to see an updated driver some time?
Also support for widescreen resolutions (as 1440 x 900 or 1680 x 1050) would be a great feature. As VMWare seems to have trouble with the gamma of the NeXT operating systems (too dark) it would be also great if gamma was adjustable.
... these are just some mad wishes!
sincerely
Andreas G.
Austria
A:
Hi Andreas,
We've heard complaints about resolutions higher than 1024 recently... you're not alone.
Unfortunately at the moment, there is no active development underway to address this problem, nor any near-term plans to release an update to the driver.
The source code is freely available and we encourage anyone with an interest to modify, repair or extend it, and hopefully to submit a patch so the base code can be updated.
We are currently transitioning the source code for the driver into Github in order to make it much easier for others to contribute to the project. This project will likely appear under the "atomicobject" on github.com.
Thank you for your interest in the the OpenStep display driver!
I will try to remember to notify you once the project has moved.
Regards,
/David
Maybe someone in here has got the knowledge and the time to look into the code and do some improvements.
I think VMWare users would greatly appreciate it!
sincerely
Andreas
very cool, well done for getting in touch! :)
This is good news that the code will at least be available for people to look at (and maybe improve).
In the meantime, if you don't mind using "thousands of colors" instead of millions, I have found that if OS X is set to Thousands instead of before booting Fusion (and the VM) the VMWareFB driver will work up to 1280x1024.
Quote from: "andreas_g"Dear NeXT community!
I just want to tell you that i am in contact with david from "atomic object". They have developed the VMWareFB display driver for NeXTStep, OPENSTEP and Rhapsody. As there are some issues with the driver, i asked about the actual state of development. Thanks to david for allowing me to share the mail with the NeXT community:
I actually have a version locally that works with all kinds of different resolutions (5:4, 16:9, 16:10, etc), but what makes it work for sizes > 1024x768 (occasionally 1280x1024) is something that you can change in Configure already: changing the starting address of the frame buffer from 0x7EBC0000 to 0xD0000000.
The long and short of it is that 0xd0000000 gives you enough video memory to display the full range.
Thank you very much! It works just great! I have customized the driver to support my native resolution (1680 x 1050) and now i am able to use NeXTStep fullscreen without any scaling!
Awesome!
As for the gamma problem, there doesn't appear to be any reasonable way to make it work other than using a shadow framebuffer and copying it to the real one (which doubles the amount of memory needed, and slows down updates).
The emulated VMware hardware doesn't seem to provide any sort of gamma ramp. It has 768 color palette registers that could be used to implement a 24-bit gamma ramp, but according to the VMware documentation they only work in 8-bit mode.
The problem is that the driver maps the guest video memory as a 24-bit linear frame buffer, and at least on Linux what's drawn on the virtual FB goes almost directly to video memory when you're running full-screen.
As far as I can tell, there's no way to get NeXTStep/OPENSTEP to do software gamma correction on a 24-bit linear framebuffer. It'll do it for a 15-bit FB (using a 4-4-4->5-5-5 color lookup table built into the window server), but not 24-bit -- and switching to 15bpp on the host doesn't seem to help.
The only way I can think of to get proper gamma control is the hard, nasty way: doing it in the driver itself, by modifying the values we write to the display, and that usually means a shadow buffer.
Quote from: "andreas_g"Thank you very much! It works just great! I have customized the driver to support my native resolution (1680 x 1050) and now i am able to use NeXTStep fullscreen without any scaling!
Awesome!
It is indeed great to see someone having made progress on the resolution issue. It's by far the most asked for feature since we originally wrote this back in 2002.
Atomic Object (
http://atomicobject.com/) plans to move the source code to a location more easily accessed. Hopefully this will encourage further development. It would be great to see a community take over what we started so long ago.
Carl (President, Atomic Object)
Quote from: "andreas_g"...I have customized the driver to support my native resolution (1680 x 1050) and now i am able to use NeXTStep fullscreen without any scaling!
Do you know if it support 1440 x 900 in full screen ?
Hi guys,
VMWareFB 1.1.0 is released!
http://spin.atomicobject.com/2009/12/23/openstep-display-driver-for-vmware-on-githubThe updated code is thanks to andreas_g supplying a patch that he built up from the advice on this thread.
For nicely increased list of video modes, see the project page at
http://github.com/atomicobject/VMWareFB_OpenStep.Not ready to run ProjectBuilder yourself? An updated compressed config is available in the download section (
http://github.com/atomicobject/VMWareFB_OpenStep/downloads).
The move to Github is an effort to put this driver project in the hands of the community. It is our hope to that anyone with inclination to hack this driver any further will be inspired to fork the code and push changes back in for all to share.
Thanks for you interest and advice, all!
/Dave
Thank you for hosting the updated driver. Now i hope it helps some people in here!
@oneNeXT:
Try the updated driver (1.1.0). It should work well at 1440 x 900. Please give us some feedback about your experiences with the updated driver.
Quote from: "david_crosby"Hi guys,
VMWareFB 1.1.0 is released!
http://spin.atomicobject.com/2009/12/23/openstep-display-driver-for-vmware-on-github
The updated code is thanks to andreas_g supplying a patch that he built up from the advice on this thread.
Changing SVGA_FB_LEGACY_START to 0xD000000 is wrong, it can't be moved from 0x7EFC0000 (the legacy 0710 device can't move its framebuffer like the 0405 one can).
What effect will my mistake have on the functionality/performance of the driver?
For now it seems to work perfectly, at least for me.
The driver will crash on old versions of VMware.
Thanks! I corrected the problem! Version 1.1.1 was compiled from the fixed source code.
Just a quick question -- has the version number been rev'ed in Default.table? This could help people keep them straight...
Many thanks for this great driver! Now running at 1152x864 :)
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!
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.
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
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/downloadsPlease give me a short feedback if it works for you.
Edit: Updated link to download page.
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 ?
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.
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
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
}
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
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)
Thanks for the explanation, NeXT FREAK! :)