[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OPENSTEP 4.2 vmware SVGA
Re: OPENSTEP 4.2 vmware SVGA
Thu, 24 Jan 2002 16:09:12 +0100
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7+) Gecko/20020116
I looked more closely to what happens, and things are not as simple as I
The clock and the caret works perfectly (ie: they update in real time,
without any phantom). But fast-moving the mouse or moving large chunk of
graphics (ie: opening/moving/closing a window or scrolling) let large
'bands' of the diplay untouched.
What I suspect is that vmware knows when the application touches the
framebuffer and blit it to the real screen a few milliseconds later. But
it looks like there is a race condition, and what is displayed during
the blit is not displayed onscreen. So parts of large transfers are
lost. I'll ask on the vmware newsgroups.
The MD5 trick (well, with a easier to compute CRC) could work. I could
take a look at what VNC does...
Pascal Bourguignon wrote:
Frederic Stark <address@hidden> wrote:
Boring weekend. I took my OS42 CDs, vmware, the diff to the vmware
module of XFree86, the drivers example from OS42, a dozen of cup of
coffee and started to hack an OPENSTEP42 vmware SVGA driver.
I am to the point where I get it running in 1024x768/24bits (yep, the
values are hard-coded for now). Code is _very_ ugly, as this is my first
OS42 driver (OS42 have no documentation on the DriverKit, and I can't
get my hands back on my 3.3 CDs). I can probably get something more
usable next week-end. I can release what I have for the impatient, of
The problem is that the DPS server never tell my driver when screen have
been written to, so vmware don't know when to update the real screen
(ie: there are 'phantoms' left in a lot of places). I don't think the
NeXT window server was ready to work with a 'buffered' device.
Any idea about how I can solve that ? I can think about several solutions:
1/ Don't care (by moving the vmware window, the 'phantoms' disapear
because vmware flushes the screen)
2/ Implement a /dev device and a user-land utility to tell the driver to
flush the screen (every one second, for instance).
3/ Get a PostSript master to try to hack WindowPackage.ps to know if the
server did something. Alternatively, I could try to patch the
4/ Play with mach memory to know if window server wrote to the
framebuffer. Issue a flush to vmware 1/10th of a second later. It must
be possible, but I have the slighest clue about how to do it.
Any other trick ?
The best solution would be something like 3/, to have a hook in the
low-level DPS raster routines. That would be in
/usr/lib/NextStep/WindowServer, but it's death-row software, not free
But it would be enough to have your driver flush automatically 10 or
20 times a second. Since flushing to the screen could be costly, it
may be interesting to divide the frame buffer of your driver in tiles
and compute a md5sum over each tile, and flush only the tiles that
Since there are the blinking carets, the clock, the cursor, the screen
will need updating continuously, in small parts of it at least.
The check sum computing frequency could be varied depending on whether
the tile or its neighbor changed recently or not.
- OPENSTEP 4.2 vmware SVGA, Frederic Stark, 2002/01/23
- Re: OPENSTEP 4.2 vmware SVGA, Pascal Bourguignon, 2002/01/23
- Re: OPENSTEP 4.2 vmware SVGA,
Frederic Stark <=
- Re: OPENSTEP 4.2 vmware SVGA, Pascal Bourguignon, 2002/01/24
- Re: OPENSTEP 4.2 vmware SVGA, Stefan Boehringer, 2002/01/24
- Re: OPENSTEP 4.2 vmware SVGA, Frederic Stark, 2002/01/24
- Re: OPENSTEP 4.2 vmware SVGA, Gregory Casamento, 2002/01/25
- OPENSTEP 4.2 vmware SVGA in better shape, Frederic Stark, 2002/01/28
- Re: OPENSTEP 4.2 vmware SVGA in better shape, Gregory Casamento, 2002/01/28
- Re: OPENSTEP 4.2 vmware SVGA in better shape, Frederic Stark, 2002/01/30