[Qemu-devel] QEMU Video Driver for Win NT-based systems

[Qemu-devel] QEMU Video Driver for Win NT-based systems

[Filip Navara]

Hi,

if anyone is interested I have created open source QEMU/Bochs video 
driver for Windows NT/2K/XP/2003.

Binaries - www.volny.cz/xnavara/qemuvid_bin.zip
Sources - www.volny.cz/xnavara/qemuvid_src.zip

- Filip.

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Jean-Michel POURE]

> if anyone is interested I have created open source QEMU/Bochs video
> driver for Windows NT/2K/XP/2003.
> Binaries - www.volny.cz/xnavara/qemuvid_bin.zip
> Sources - www.volny.cz/xnavara/qemuvid_src.zip

Are these VBE drivers?
Can you describe the drivers and its capabilities in more details?

Best regards,
Jean-Michel

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Filip Navara]

Jean-Michel POURE wrote:

>>if anyone is interested I have created open source QEMU/Bochs video
>>driver for Windows NT/2K/XP/2003.
>>Binaries - www.volny.cz/xnavara/qemuvid_bin.zip
>>Sources - www.volny.cz/xnavara/qemuvid_src.zip
>>    
>>
>
>Are these VBE drivers?
>  
>
Not in the sense of VBE 3.0 specification. I have such driver too, but 
it propably works only on ReactOS because of using undocumented API.

>Can you describe the drivers and its capabilities in more details?
>  
>
The driver uses the Bochs/QEMU VBE I/O port, the same method as used by 
BXVGA. My implementation is a bit simplier, but still with the same 
features. It also uses the Linear FrameBuffer feature of the Bochs/QEMU 
interface that wasn't available at the time when BXVGA was written.

Regards,
Filip

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Grzegorz Kulewski]

On Wed, 12 May 2004, Filip Navara wrote:
> Jean-Michel POURE wrote:
> >>if anyone is interested I have created open source QEMU/Bochs video
> >>driver for Windows NT/2K/XP/2003.
> >>Binaries - www.volny.cz/xnavara/qemuvid_bin.zip
> >>Sources - www.volny.cz/xnavara/qemuvid_src.zip
> >
> >Are these VBE drivers?
> >  
> Not in the sense of VBE 3.0 specification. I have such driver too, but 
> it propably works only on ReactOS because of using undocumented API.
> 
> >Can you describe the drivers and its capabilities in more details?
>  
> The driver uses the Bochs/QEMU VBE I/O port, the same method as used by 
> BXVGA. My implementation is a bit simplier, but still with the same 
> features. It also uses the Linear FrameBuffer feature of the Bochs/QEMU 
> interface that wasn't available at the time when BXVGA was written.

Are there any driver that works with win9x? Can you port your (or write 
it from scratch)?

Will your driver work in Bochs?

Is it possible to create driver that emulates DirectX and OpenGL by 
sending the OpenGL commands to the host OpenGL libs. DirectX commands 
should probably be converted before into OpenGL.


Thanks for your work,

Grzegorz Kulewski

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Jamie Burns]

Wouldn't a 2D accelerator be a good idea first? ;o)

If Windows asks for a "line" to be drawn, or a "blit-op" then could that be
passed through to the QEMU emulated video hardware, which in turn could
simply get SDL or whatever to do the required operation. Then 2D graphics
would speed up immensly.

Are there any documents giving an overview of how the QEUM architecture
works in this respect? I would work on a driver in my spare time but really
do not know where to start.

J.

----- Original Message ----- 
From: "Grzegorz Kulewski" <kangur@polcom.net>
To: <qemu-devel@nongnu.org>
Sent: Wednesday, May 12, 2004 11:20 AM
Subject: Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems


> On Wed, 12 May 2004, Filip Navara wrote:
> > Jean-Michel POURE wrote:
> > >>if anyone is interested I have created open source QEMU/Bochs video
> > >>driver for Windows NT/2K/XP/2003.
> > >>Binaries - www.volny.cz/xnavara/qemuvid_bin.zip
> > >>Sources - www.volny.cz/xnavara/qemuvid_src.zip
> > >
> > >Are these VBE drivers?
> > >
> > Not in the sense of VBE 3.0 specification. I have such driver too, but
> > it propably works only on ReactOS because of using undocumented API.
> >
> > >Can you describe the drivers and its capabilities in more details?
> >
> > The driver uses the Bochs/QEMU VBE I/O port, the same method as used by
> > BXVGA. My implementation is a bit simplier, but still with the same
> > features. It also uses the Linear FrameBuffer feature of the Bochs/QEMU
> > interface that wasn't available at the time when BXVGA was written.
>
> Are there any driver that works with win9x? Can you port your (or write
> it from scratch)?
>
> Will your driver work in Bochs?
>
> Is it possible to create driver that emulates DirectX and OpenGL by
> sending the OpenGL commands to the host OpenGL libs. DirectX commands
> should probably be converted before into OpenGL.
>
>
> Thanks for your work,
>
> Grzegorz Kulewski
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Filip Navara]

Grzegorz Kulewski wrote:

>Are there any driver that works with win9x? Can you port your (or write 
>it from scratch)?
>  
>
There isn't such driver and I don't plan to port the mine. The reason is 
that the Win 9x driver architecture is completely different from the NT 
one (well, except some driver kinds covered by the Windows Driver Model, 
but that's not the case of graphics drivers).

>Will your driver work in Bochs?
>  
>
Propably yes, but I haven't tried that yet.

>Is it possible to create driver that emulates DirectX and OpenGL by 
>sending the OpenGL commands to the host OpenGL libs. DirectX commands 
>should probably be converted before into OpenGL.
>  
>
I was just think about something like that. If there would be a QEMU 
support for receiving OpenGL commands using some easy protocol and 
passing them on the underlying host OpenGL implementation (should be 
possible with some SDL support), then it will not be hard to make an 
OpenGL driver for Win NT+ using it. Making a DirectX (here I refer to 
Direct3D mainly) driver would possible using such interface, but it 
would be major pain. It would be propably easier to use Wine DirectX 
implementation that converts the requests to OpenGL...

Maybe I'm just dreaming with opened eyes....

Regards,
Filip

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Grzegorz Kulewski]

On Wed, 12 May 2004, Filip Navara wrote:
> I was just think about something like that. If there would be a QEMU 
> support for receiving OpenGL commands using some easy protocol and 
> passing them on the underlying host OpenGL implementation (should be 
> possible with some SDL support), then it will not be hard to make an 
> OpenGL driver for Win NT+ using it. Making a DirectX (here I refer to 
> Direct3D mainly) driver would possible using such interface, but it 
> would be major pain. It would be propably easier to use Wine DirectX 
> implementation that converts the requests to OpenGL...

I was thinking about using some DirectX to OpenGL emulator too (maybe from 
wine but this is probably not complete and, as I know wine, will never 
be). I heard that Direct3D was cleaned up somewhere about 8-9 version so 
that is can be converted to OpenGL so maybe somebody already did this?


Grzegorz Kulewski

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Martin Garton]

On Wed, 12 May 2004, Grzegorz Kulewski wrote:

> I was thinking about using some DirectX to OpenGL emulator too (maybe from 
> wine but this is probably not complete and, as I know wine, will never 
> be). I heard that Direct3D was cleaned up somewhere about 8-9 version so 
> that is can be converted to OpenGL so maybe somebody already did this?

Would it be feasable to emulate a 3d capable graphics card instead and 
implement that using opengl on the host? That way it doesn't matter 
whether the guest is using directx version n, or opengl. It will all be 
supported.

-- 
Martin.

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Natalia Portillo]

This is the same as making a DirectDraw (2D part of DirectX) driver.

A full DirectX package of drivers will be great: DirectDraw (for 2D), Direct3D (converting calls to OpenGL in host), DirectSound/DirectSound3D and DirectMusic (for the sound card), and DirectInput (keyboards, mice, joysticks)...

On Wed, 12 May 2004 12:30:08 +0100
"Jamie Burns" <jamie.burns@dynamicexpression.co.uk> wrote:

> Wouldn't a 2D accelerator be a good idea first? ;o)
> 
> If Windows asks for a "line" to be drawn, or a "blit-op" then could that be
> passed through to the QEMU emulated video hardware, which in turn could
> simply get SDL or whatever to do the required operation. Then 2D graphics
> would speed up immensly.
> 
> Are there any documents giving an overview of how the QEUM architecture
> works in this respect? I would work on a driver in my spare time but really
> do not know where to start.
> 
> J.
> 
> ----- Original Message ----- 
> From: "Grzegorz Kulewski" <kangur@polcom.net>
> To: <qemu-devel@nongnu.org>
> Sent: Wednesday, May 12, 2004 11:20 AM
> Subject: Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems
> 
> 
> > On Wed, 12 May 2004, Filip Navara wrote:
> > > Jean-Michel POURE wrote:
> > > >>if anyone is interested I have created open source QEMU/Bochs video
> > > >>driver for Windows NT/2K/XP/2003.
> > > >>Binaries - www.volny.cz/xnavara/qemuvid_bin.zip
> > > >>Sources - www.volny.cz/xnavara/qemuvid_src.zip
> > > >
> > > >Are these VBE drivers?
> > > >
> > > Not in the sense of VBE 3.0 specification. I have such driver too, but
> > > it propably works only on ReactOS because of using undocumented API.
> > >
> > > >Can you describe the drivers and its capabilities in more details?
> > >
> > > The driver uses the Bochs/QEMU VBE I/O port, the same method as used by
> > > BXVGA. My implementation is a bit simplier, but still with the same
> > > features. It also uses the Linear FrameBuffer feature of the Bochs/QEMU
> > > interface that wasn't available at the time when BXVGA was written.
> >
> > Are there any driver that works with win9x? Can you port your (or write
> > it from scratch)?
> >
> > Will your driver work in Bochs?
> >
> > Is it possible to create driver that emulates DirectX and OpenGL by
> > sending the OpenGL commands to the host OpenGL libs. DirectX commands
> > should probably be converted before into OpenGL.
> >
> >
> > Thanks for your work,
> >
> > Grzegorz Kulewski
> >
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://mail.nongnu.org/mailman/listinfo/qemu-devel
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Grzegorz Kulewski]

Another idea is to allow qemu use second graphic card in your pc (not used 
by the host). I have one spare GeForce 2 @ PCI so I will be glad to see 
this implemented. Before that we will probably need working PCI layer in 
qemu. And I we can track the area in graphic memory used by current screen 
maybe it is possible to write driver that will copy screen from second 
card to a window on first (this could be implemented on guest or on host).


Grzegorz Kulewski


On Wed, 12 May 2004, Natalia Portillo wrote:

> This is the same as making a DirectDraw (2D part of DirectX) driver.
> 
> A full DirectX package of drivers will be great: DirectDraw (for 2D), Direct3D (converting calls to OpenGL in host), DirectSound/DirectSound3D and DirectMusic (for the sound card), and DirectInput (keyboards, mice, joysticks)...
> 
> On Wed, 12 May 2004 12:30:08 +0100
> "Jamie Burns" <jamie.burns@dynamicexpression.co.uk> wrote:
> 
> > Wouldn't a 2D accelerator be a good idea first? ;o)
> > 
> > If Windows asks for a "line" to be drawn, or a "blit-op" then could that be
> > passed through to the QEMU emulated video hardware, which in turn could
> > simply get SDL or whatever to do the required operation. Then 2D graphics
> > would speed up immensly.
> > 
> > Are there any documents giving an overview of how the QEUM architecture
> > works in this respect? I would work on a driver in my spare time but really
> > do not know where to start.
> > 
> > J.
> > 
> > ----- Original Message ----- 
> > From: "Grzegorz Kulewski" <kangur@polcom.net>
> > To: <qemu-devel@nongnu.org>
> > Sent: Wednesday, May 12, 2004 11:20 AM
> > Subject: Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems
> > 
> > 
> > > On Wed, 12 May 2004, Filip Navara wrote:
> > > > Jean-Michel POURE wrote:
> > > > >>if anyone is interested I have created open source QEMU/Bochs video
> > > > >>driver for Windows NT/2K/XP/2003.
> > > > >>Binaries - www.volny.cz/xnavara/qemuvid_bin.zip
> > > > >>Sources - www.volny.cz/xnavara/qemuvid_src.zip
> > > > >
> > > > >Are these VBE drivers?
> > > > >
> > > > Not in the sense of VBE 3.0 specification. I have such driver too, but
> > > > it propably works only on ReactOS because of using undocumented API.
> > > >
> > > > >Can you describe the drivers and its capabilities in more details?
> > > >
> > > > The driver uses the Bochs/QEMU VBE I/O port, the same method as used by
> > > > BXVGA. My implementation is a bit simplier, but still with the same
> > > > features. It also uses the Linear FrameBuffer feature of the Bochs/QEMU
> > > > interface that wasn't available at the time when BXVGA was written.
> > >
> > > Are there any driver that works with win9x? Can you port your (or write
> > > it from scratch)?
> > >
> > > Will your driver work in Bochs?
> > >
> > > Is it possible to create driver that emulates DirectX and OpenGL by
> > > sending the OpenGL commands to the host OpenGL libs. DirectX commands
> > > should probably be converted before into OpenGL.
> > >
> > >
> > > Thanks for your work,
> > >
> > > Grzegorz Kulewski
> > >
> > >
> > >
> > > _______________________________________________
> > > Qemu-devel mailing list
> > > Qemu-devel@nongnu.org
> > > http://mail.nongnu.org/mailman/listinfo/qemu-devel
> > 
> > 
> > 
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://mail.nongnu.org/mailman/listinfo/qemu-devel
> 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
> 

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Natalia Portillo]

And then you will get between 1 and 10 fps depending on what kind of 3D card you try to emulate.

On Wed, 12 May 2004 16:40:45 +0100 (BST)
Martin Garton <martin@wrasse.demon.co.uk> wrote:

> On Wed, 12 May 2004, Grzegorz Kulewski wrote:
> 
> > I was thinking about using some DirectX to OpenGL emulator too (maybe from 
> > wine but this is probably not complete and, as I know wine, will never 
> > be). I heard that Direct3D was cleaned up somewhere about 8-9 version so 
> > that is can be converted to OpenGL so maybe somebody already did this?
> 
> Would it be feasable to emulate a 3d capable graphics card instead and 
> implement that using opengl on the host? That way it doesn't matter 
> whether the guest is using directx version n, or opengl. It will all be 
> supported.
> 
> -- 
> Martin.
> 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Fabrice Bellard]

Martin Garton wrote:
> On Wed, 12 May 2004, Grzegorz Kulewski wrote:
> 
> 
>>I was thinking about using some DirectX to OpenGL emulator too (maybe from 
>>wine but this is probably not complete and, as I know wine, will never 
>>be). I heard that Direct3D was cleaned up somewhere about 8-9 version so 
>>that is can be converted to OpenGL so maybe somebody already did this?
> 
> 
> Would it be feasable to emulate a 3d capable graphics card instead and 
> implement that using opengl on the host? That way it doesn't matter 
> whether the guest is using directx version n, or opengl. It will all be 
> supported.

QEMU will integrate a full SiS 6326 PCI VGA card emulation. This card 
has accelerated 2D and 3D support. The priority will be 2D support 
first, but 3D support with OpenGL will be possible in the future.

Fabrice.

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Jamie Burns]

Will windows GDI calls use DirectDraw if implemented? Or is there still a
need to accelerate GDI seperately?

----- Original Message ----- 
From: "Natalia Portillo" <iosglpgc@teleline.es>
To: <qemu-devel@nongnu.org>
Sent: Wednesday, May 12, 2004 5:49 PM
Subject: Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems


> This is the same as making a DirectDraw (2D part of DirectX) driver.
>
> A full DirectX package of drivers will be great: DirectDraw (for 2D),
Direct3D (converting calls to OpenGL in host), DirectSound/DirectSound3D and
DirectMusic (for the sound card), and DirectInput (keyboards, mice,
joysticks)...
>
> On Wed, 12 May 2004 12:30:08 +0100
> "Jamie Burns" <jamie.burns@dynamicexpression.co.uk> wrote:
>
> > Wouldn't a 2D accelerator be a good idea first? ;o)
> >
> > If Windows asks for a "line" to be drawn, or a "blit-op" then could that
be
> > passed through to the QEMU emulated video hardware, which in turn could
> > simply get SDL or whatever to do the required operation. Then 2D
graphics
> > would speed up immensly.
> >
> > Are there any documents giving an overview of how the QEUM architecture
> > works in this respect? I would work on a driver in my spare time but
really
> > do not know where to start.
> >
> > J.
> >
> > ----- Original Message ----- 
> > From: "Grzegorz Kulewski" <kangur@polcom.net>
> > To: <qemu-devel@nongnu.org>
> > Sent: Wednesday, May 12, 2004 11:20 AM
> > Subject: Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems
> >
> >
> > > On Wed, 12 May 2004, Filip Navara wrote:
> > > > Jean-Michel POURE wrote:
> > > > >>if anyone is interested I have created open source QEMU/Bochs
video
> > > > >>driver for Windows NT/2K/XP/2003.
> > > > >>Binaries - www.volny.cz/xnavara/qemuvid_bin.zip
> > > > >>Sources - www.volny.cz/xnavara/qemuvid_src.zip
> > > > >
> > > > >Are these VBE drivers?
> > > > >
> > > > Not in the sense of VBE 3.0 specification. I have such driver too,
but
> > > > it propably works only on ReactOS because of using undocumented API.
> > > >
> > > > >Can you describe the drivers and its capabilities in more details?
> > > >
> > > > The driver uses the Bochs/QEMU VBE I/O port, the same method as used
by
> > > > BXVGA. My implementation is a bit simplier, but still with the same
> > > > features. It also uses the Linear FrameBuffer feature of the
Bochs/QEMU
> > > > interface that wasn't available at the time when BXVGA was written.
> > >
> > > Are there any driver that works with win9x? Can you port your (or
write
> > > it from scratch)?
> > >
> > > Will your driver work in Bochs?
> > >
> > > Is it possible to create driver that emulates DirectX and OpenGL by
> > > sending the OpenGL commands to the host OpenGL libs. DirectX commands
> > > should probably be converted before into OpenGL.
> > >
> > >
> > > Thanks for your work,
> > >
> > > Grzegorz Kulewski
> > >
> > >
> > >
> > > _______________________________________________
> > > Qemu-devel mailing list
> > > Qemu-devel@nongnu.org
> > > http://mail.nongnu.org/mailman/listinfo/qemu-devel
> >
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://mail.nongnu.org/mailman/listinfo/qemu-devel
>
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Fabrice Bellard]

What not using the main graphic card ? dosemu does it... All you need is 
"just" to be able to switch the rendering contexts. So it is a host VGA 
card dependent code, but it can be rather small.

Fabrice.

Grzegorz Kulewski wrote:
> Another idea is to allow qemu use second graphic card in your pc (not used 
> by the host). I have one spare GeForce 2 @ PCI so I will be glad to see 
> this implemented. Before that we will probably need working PCI layer in 
> qemu. And I we can track the area in graphic memory used by current screen 
> maybe it is possible to write driver that will copy screen from second 
> card to a window on first (this could be implemented on guest or on host).
> 
> 
> Grzegorz Kulewski
> 
> 
> On Wed, 12 May 2004, Natalia Portillo wrote:
> 
> 
>>This is the same as making a DirectDraw (2D part of DirectX) driver.
>>
>>A full DirectX package of drivers will be great: DirectDraw (for 2D), Direct3D (converting calls to OpenGL in host), DirectSound/DirectSound3D and DirectMusic (for the sound card), and DirectInput (keyboards, mice, joysticks)...
>>
>>On Wed, 12 May 2004 12:30:08 +0100
>>"Jamie Burns" <jamie.burns@dynamicexpression.co.uk> wrote:
>>
>>
>>>Wouldn't a 2D accelerator be a good idea first? ;o)
>>>
>>>If Windows asks for a "line" to be drawn, or a "blit-op" then could that be
>>>passed through to the QEMU emulated video hardware, which in turn could
>>>simply get SDL or whatever to do the required operation. Then 2D graphics
>>>would speed up immensly.
>>>
>>>Are there any documents giving an overview of how the QEUM architecture
>>>works in this respect? I would work on a driver in my spare time but really
>>>do not know where to start.
>>>
>>>J.
>>>
>>>----- Original Message ----- 
>>>From: "Grzegorz Kulewski" <kangur@polcom.net>
>>>To: <qemu-devel@nongnu.org>
>>>Sent: Wednesday, May 12, 2004 11:20 AM
>>>Subject: Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems
>>>
>>>
>>>
>>>>On Wed, 12 May 2004, Filip Navara wrote:
>>>>
>>>>>Jean-Michel POURE wrote:
>>>>>
>>>>>>>if anyone is interested I have created open source QEMU/Bochs video
>>>>>>>driver for Windows NT/2K/XP/2003.
>>>>>>>Binaries - www.volny.cz/xnavara/qemuvid_bin.zip
>>>>>>>Sources - www.volny.cz/xnavara/qemuvid_src.zip
>>>>>>
>>>>>>Are these VBE drivers?
>>>>>>
>>>>>
>>>>>Not in the sense of VBE 3.0 specification. I have such driver too, but
>>>>>it propably works only on ReactOS because of using undocumented API.
>>>>>
>>>>>
>>>>>>Can you describe the drivers and its capabilities in more details?
>>>>>
>>>>>The driver uses the Bochs/QEMU VBE I/O port, the same method as used by
>>>>>BXVGA. My implementation is a bit simplier, but still with the same
>>>>>features. It also uses the Linear FrameBuffer feature of the Bochs/QEMU
>>>>>interface that wasn't available at the time when BXVGA was written.
>>>>
>>>>Are there any driver that works with win9x? Can you port your (or write
>>>>it from scratch)?
>>>>
>>>>Will your driver work in Bochs?
>>>>
>>>>Is it possible to create driver that emulates DirectX and OpenGL by
>>>>sending the OpenGL commands to the host OpenGL libs. DirectX commands
>>>>should probably be converted before into OpenGL.
>>>>
>>>>
>>>>Thanks for your work,
>>>>
>>>>Grzegorz Kulewski
>>>>
>>>>
>>>>
>>>>_______________________________________________
>>>>Qemu-devel mailing list
>>>>Qemu-devel@nongnu.org
>>>>http://mail.nongnu.org/mailman/listinfo/qemu-devel
>>>
>>>
>>>
>>>_______________________________________________
>>>Qemu-devel mailing list
>>>Qemu-devel@nongnu.org
>>>http://mail.nongnu.org/mailman/listinfo/qemu-devel
>>
>>
>>
>>
>>_______________________________________________
>>Qemu-devel mailing list
>>Qemu-devel@nongnu.org
>>http://mail.nongnu.org/mailman/listinfo/qemu-devel
>>
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
> 

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Lionel Ulmer]

> I was thinking about using some DirectX to OpenGL emulator too (maybe from 
> wine but this is probably not complete and, as I know wine, will never 
> be). I heard that Direct3D was cleaned up somewhere about 8-9 version so 
> that is can be converted to OpenGL so maybe somebody already did this?

Well, we just need some more developpers for it to be complete :-)

Anyway, the day QEMU supports OpenGL, it would be fun to take Wine's
Direct3D code and try to get it running on real Windows instead of having it
run in Wine.

      Lionel (who should not start with such crazy ideas as he does already
              have not enough time to do the 'normal' ideas :-) )

-- 
		 Lionel Ulmer - http://www.bbrox.org/

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Grzegorz Kulewski]

On Wed, 12 May 2004, Fabrice Bellard wrote:
> Why not using the main graphic card ? dosemu does it... All you need is 
> "just" to be able to switch the rendering contexts. So it is a host VGA 
> card dependent code, but it can be rather small.

I want to be able to play games in it!!! ;-)
That means: I am thinking about using as a second card some really good 3d 
accelerator on pci bus (or on agp if first card is on pci). And that card 
can not be used by two operating systems at the same time because of some 
uninterruptable mutualy exclusive operations such as transferring big 
texture from system memory to video card memory. It can take very long and 
graphic card can not do anything other until it finishes. So host will not 
be able to display anything in that time! And we have no method to tell 
host system: stop using that card for 10ms. And there will be problems 
with irq routing probably. Think that this card is driven by some closed 
source binary drivers and you have no specs available. When using second 
card host system kernel does not touch it at all. But we will need 
"screenshot" of it from time to time. This can be achieved in two ways:

1. Use guest program that will make screenshot and tell qemu where in 
memmory it resides or will send it in any other way.

2. qemu will wait until card is free (it can be probably easily checked by 
some io port sequence) then will stop emulation and will copy screenshot.

I hope it all can be done! :-)
And hope somebody else will do it! :-)


Grzegorz Kulewski


> Grzegorz Kulewski wrote:
> > Another idea is to allow qemu use second graphic card in your pc (not used 
> > by the host). I have one spare GeForce 2 @ PCI so I will be glad to see 
> > this implemented. Before that we will probably need working PCI layer in 
> > qemu. And I we can track the area in graphic memory used by current screen 
> > maybe it is possible to write driver that will copy screen from second 
> > card to a window on first (this could be implemented on guest or on host).
> > 
> > 
> > Grzegorz Kulewski
> > 
> > 
> > On Wed, 12 May 2004, Natalia Portillo wrote:
> > 
> > 
> >>This is the same as making a DirectDraw (2D part of DirectX) driver.
> >>
> >>A full DirectX package of drivers will be great: DirectDraw (for 2D), Direct3D (converting calls to OpenGL in host), DirectSound/DirectSound3D and DirectMusic (for the sound card), and DirectInput (keyboards, mice, joysticks)...
> >>
> >>On Wed, 12 May 2004 12:30:08 +0100
> >>"Jamie Burns" <jamie.burns@dynamicexpression.co.uk> wrote:
> >>
> >>
> >>>Wouldn't a 2D accelerator be a good idea first? ;o)
> >>>
> >>>If Windows asks for a "line" to be drawn, or a "blit-op" then could that be
> >>>passed through to the QEMU emulated video hardware, which in turn could
> >>>simply get SDL or whatever to do the required operation. Then 2D graphics
> >>>would speed up immensly.
> >>>
> >>>Are there any documents giving an overview of how the QEUM architecture
> >>>works in this respect? I would work on a driver in my spare time but really
> >>>do not know where to start.
> >>>
> >>>J.
> >>>
> >>>----- Original Message ----- 
> >>>From: "Grzegorz Kulewski" <kangur@polcom.net>
> >>>To: <qemu-devel@nongnu.org>
> >>>Sent: Wednesday, May 12, 2004 11:20 AM
> >>>Subject: Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems
> >>>
> >>>
> >>>
> >>>>On Wed, 12 May 2004, Filip Navara wrote:
> >>>>
> >>>>>Jean-Michel POURE wrote:
> >>>>>
> >>>>>>>if anyone is interested I have created open source QEMU/Bochs video
> >>>>>>>driver for Windows NT/2K/XP/2003.
> >>>>>>>Binaries - www.volny.cz/xnavara/qemuvid_bin.zip
> >>>>>>>Sources - www.volny.cz/xnavara/qemuvid_src.zip
> >>>>>>
> >>>>>>Are these VBE drivers?
> >>>>>>
> >>>>>
> >>>>>Not in the sense of VBE 3.0 specification. I have such driver too, but
> >>>>>it propably works only on ReactOS because of using undocumented API.
> >>>>>
> >>>>>
> >>>>>>Can you describe the drivers and its capabilities in more details?
> >>>>>
> >>>>>The driver uses the Bochs/QEMU VBE I/O port, the same method as used by
> >>>>>BXVGA. My implementation is a bit simplier, but still with the same
> >>>>>features. It also uses the Linear FrameBuffer feature of the Bochs/QEMU
> >>>>>interface that wasn't available at the time when BXVGA was written.
> >>>>
> >>>>Are there any driver that works with win9x? Can you port your (or write
> >>>>it from scratch)?
> >>>>
> >>>>Will your driver work in Bochs?
> >>>>
> >>>>Is it possible to create driver that emulates DirectX and OpenGL by
> >>>>sending the OpenGL commands to the host OpenGL libs. DirectX commands
> >>>>should probably be converted before into OpenGL.
> >>>>
> >>>>
> >>>>Thanks for your work,
> >>>>
> >>>>Grzegorz Kulewski
> >>>>
> >>>>
> >>>>
> >>>>_______________________________________________
> >>>>Qemu-devel mailing list
> >>>>Qemu-devel@nongnu.org
> >>>>http://mail.nongnu.org/mailman/listinfo/qemu-devel
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>Qemu-devel mailing list
> >>>Qemu-devel@nongnu.org
> >>>http://mail.nongnu.org/mailman/listinfo/qemu-devel
> >>
> >>
> >>
> >>
> >>_______________________________________________
> >>Qemu-devel mailing list
> >>Qemu-devel@nongnu.org
> >>http://mail.nongnu.org/mailman/listinfo/qemu-devel
> >>
> > 
> > 
> > 
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://mail.nongnu.org/mailman/listinfo/qemu-devel
> > 
> 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
> 

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Natalia Portillo]

DirectDraw is the accelerator for GDI.

On Wed, 12 May 2004 19:52:14 +0100
Jamie Burns <jamie.burns@dynamicexpression.co.uk> wrote:

> Will windows GDI calls use DirectDraw if implemented? Or is there still a
> need to accelerate GDI seperately?
> 
> ----- Original Message ----- 
> From: "Natalia Portillo" <iosglpgc@teleline.es>
> To: <qemu-devel@nongnu.org>
> Sent: Wednesday, May 12, 2004 5:49 PM
> Subject: Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems
> 
> 
> > This is the same as making a DirectDraw (2D part of DirectX) driver.
> >
> > A full DirectX package of drivers will be great: DirectDraw (for 2D),
> Direct3D (converting calls to OpenGL in host), DirectSound/DirectSound3D and
> DirectMusic (for the sound card), and DirectInput (keyboards, mice,
> joysticks)...
> >
> > On Wed, 12 May 2004 12:30:08 +0100
> > "Jamie Burns" <jamie.burns@dynamicexpression.co.uk> wrote:
> >
> > > Wouldn't a 2D accelerator be a good idea first? ;o)
> > >
> > > If Windows asks for a "line" to be drawn, or a "blit-op" then could that
> be
> > > passed through to the QEMU emulated video hardware, which in turn could
> > > simply get SDL or whatever to do the required operation. Then 2D
> graphics
> > > would speed up immensly.
> > >
> > > Are there any documents giving an overview of how the QEUM architecture
> > > works in this respect? I would work on a driver in my spare time but
> really
> > > do not know where to start.
> > >
> > > J.
> > >
> > > ----- Original Message ----- 
> > > From: "Grzegorz Kulewski" <kangur@polcom.net>
> > > To: <qemu-devel@nongnu.org>
> > > Sent: Wednesday, May 12, 2004 11:20 AM
> > > Subject: Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems
> > >
> > >
> > > > On Wed, 12 May 2004, Filip Navara wrote:
> > > > > Jean-Michel POURE wrote:
> > > > > >>if anyone is interested I have created open source QEMU/Bochs
> video
> > > > > >>driver for Windows NT/2K/XP/2003.
> > > > > >>Binaries - www.volny.cz/xnavara/qemuvid_bin.zip
> > > > > >>Sources - www.volny.cz/xnavara/qemuvid_src.zip
> > > > > >
> > > > > >Are these VBE drivers?
> > > > > >
> > > > > Not in the sense of VBE 3.0 specification. I have such driver too,
> but
> > > > > it propably works only on ReactOS because of using undocumented API.
> > > > >
> > > > > >Can you describe the drivers and its capabilities in more details?
> > > > >
> > > > > The driver uses the Bochs/QEMU VBE I/O port, the same method as used
> by
> > > > > BXVGA. My implementation is a bit simplier, but still with the same
> > > > > features. It also uses the Linear FrameBuffer feature of the
> Bochs/QEMU
> > > > > interface that wasn't available at the time when BXVGA was written.
> > > >
> > > > Are there any driver that works with win9x? Can you port your (or
> write
> > > > it from scratch)?
> > > >
> > > > Will your driver work in Bochs?
> > > >
> > > > Is it possible to create driver that emulates DirectX and OpenGL by
> > > > sending the OpenGL commands to the host OpenGL libs. DirectX commands
> > > > should probably be converted before into OpenGL.
> > > >
> > > >
> > > > Thanks for your work,
> > > >
> > > > Grzegorz Kulewski
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Qemu-devel mailing list
> > > > Qemu-devel@nongnu.org
> > > > http://mail.nongnu.org/mailman/listinfo/qemu-devel
> > >
> > >
> > >
> > > _______________________________________________
> > > Qemu-devel mailing list
> > > Qemu-devel@nongnu.org
> > > http://mail.nongnu.org/mailman/listinfo/qemu-devel
> >
> >
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://mail.nongnu.org/mailman/listinfo/qemu-devel
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[vaise]

Does it mean that it WOULD be possible to desactivate a PCI card in Linux, and 
activate it under Qemu, whatever the OS on it ? ?
it would us to use the card with native windows drivers...

On Wednesday 12 May 2004 18:51, Grzegorz Kulewski wrote:
> Another idea is to allow qemu use second graphic card in your pc (not used
> by the host). I have one spare GeForce 2 @ PCI so I will be glad to see
> this implemented. Before that we will probably need working PCI layer in
> qemu. And I we can track the area in graphic memory used by current screen
> maybe it is possible to write driver that will copy screen from second
> card to a window on first (this could be implemented on guest or on host).
>
>

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[vaise]

Well, qemu does not need to be DirectX compatible, but the Windows driver 
inside Qemu has to be, if we want to use 3D acceleration.

Windows can totally change from A to Z, qemu will remain the same ! Write 
once, run always (except for Palladium maybe)
but the drivers will have to be re-written.

Neither VMware or Win4lin have inplemented Direct3D. We can do best work than 
them ! ?

> Would it be feasable to emulate a 3d capable graphics card instead and
> implement that using opengl on the host? That way it doesn't matter
> whether the guest is using directx version n, or opengl. It will all be
> supported.

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Filip Navara]

Natalia Portillo wrote:

>DirectDraw is the accelerator for GDI.
>  
>
This is not correct. At the driver level GDI calls and DirectDraw calls 
are completly separate interfaces implemented different way.

- Filip

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Grzegorz Kulewski]

On Wed, 12 May 2004, Filip Navara wrote:
> Natalia Portillo wrote:
> >DirectDraw is the accelerator for GDI.
>
> This is not correct. At the driver level GDI calls and DirectDraw calls 
> are completly separate interfaces implemented different way.

You are unfortunatelly right. GDI was introduced a lot ealier than 
DirectX (I think before win95). But GDI can be not accelerated by graphic 
card but by qemu (using sdl or something like that) because today apps are 
using GDI mainly for user interface and not for advanced drawing I think. 
Right?


Grzegorz Kulewski

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Jamie Burns]

GDI can indeed be accelerated, and this was the first type of graphics card
acceleration back in the day. Accelerating the user interface (ie. most
applications that are not games!) is fairly important when emulating
Windows. I am pretty sure that no graphics card has had unaccelerated GDI
since Windows 95. QEMU/BOCHS could certainly do with a GDI accelerated
driver to have a reasonable speed display. Also, if GDI is accelerated, then
this reduces the emulated CPU time spent processing GDI calls, speeding up
QEMU in general.

:o)

----- Original Message ----- 
From: "Grzegorz Kulewski" <kangur@polcom.net>
To: <qemu-devel@nongnu.org>
Sent: Wednesday, May 12, 2004 10:52 PM
Subject: Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems


> On Wed, 12 May 2004, Filip Navara wrote:
> > Natalia Portillo wrote:
> > >DirectDraw is the accelerator for GDI.
> >
> > This is not correct. At the driver level GDI calls and DirectDraw calls
> > are completly separate interfaces implemented different way.
>
> You are unfortunatelly right. GDI was introduced a lot ealier than
> DirectX (I think before win95). But GDI can be not accelerated by graphic
> card but by qemu (using sdl or something like that) because today apps are
> using GDI mainly for user interface and not for advanced drawing I think.
> Right?
>
>
> Grzegorz Kulewski
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Filip Navara]

Grzegorz Kulewski wrote:

>On Wed, 12 May 2004, Filip Navara wrote:
>  
>
>>Natalia Portillo wrote:
>>    
>>
>>>DirectDraw is the accelerator for GDI.
>>>      
>>>
>>This is not correct. At the driver level GDI calls and DirectDraw calls 
>>are completly separate interfaces implemented different way.
>>    
>>
>
>You are unfortunatelly right. GDI was introduced a lot ealier than 
>DirectX (I think before win95).
>
Right, it was there since Windows 1.0.

> But GDI can be not accelerated by graphic 
>card but by qemu (using sdl or something like that) because today apps are 
>using GDI mainly for user interface and not for advanced drawing I think. 
>Right?
>  
>
Right, GDI is used mainly for UI drawing. It can be accelerated a bit. 
These GDI things can be *theoretically* optimized on the driver/HW level:
Alpha Blending, Gradient Fills, BitBlts/StretchBlts/TransparentBlts, 
Paths/Lines and HW Cursor. This is kind of what VMware does, their 
drivers pass some of the requests throught I/O ports (partially 
documented) to the emulator which executes the most common operations in 
the non-emulated host environment.

- Filip

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Natalia Portillo]

Seems easir to implement DirectX (full or partial) emulation.

On Wed, 12 May 2004 22:10:57 +0200 (CEST)
Grzegorz Kulewski <kangur@polcom.net> wrote:

> On Wed, 12 May 2004, Fabrice Bellard wrote:
> > Why not using the main graphic card ? dosemu does it... All you need is 
> > "just" to be able to switch the rendering contexts. So it is a host VGA 
> > card dependent code, but it can be rather small.
> 
> I want to be able to play games in it!!! ;-)
> That means: I am thinking about using as a second card some really good 3d 
> accelerator on pci bus (or on agp if first card is on pci). And that card 
> can not be used by two operating systems at the same time because of some 
> uninterruptable mutualy exclusive operations such as transferring big 
> texture from system memory to video card memory. It can take very long and 
> graphic card can not do anything other until it finishes. So host will not 
> be able to display anything in that time! And we have no method to tell 
> host system: stop using that card for 10ms. And there will be problems 
> with irq routing probably. Think that this card is driven by some closed 
> source binary drivers and you have no specs available. When using second 
> card host system kernel does not touch it at all. But we will need 
> "screenshot" of it from time to time. This can be achieved in two ways:
> 
> 1. Use guest program that will make screenshot and tell qemu where in 
> memmory it resides or will send it in any other way.
> 
> 2. qemu will wait until card is free (it can be probably easily checked by 
> some io port sequence) then will stop emulation and will copy screenshot.
> 
> I hope it all can be done! :-)
> And hope somebody else will do it! :-)
> 
> 
> Grzegorz Kulewski
> 
> 
> > Grzegorz Kulewski wrote:
> > > Another idea is to allow qemu use second graphic card in your pc (not used 
> > > by the host). I have one spare GeForce 2 @ PCI so I will be glad to see 
> > > this implemented. Before that we will probably need working PCI layer in 
> > > qemu. And I we can track the area in graphic memory used by current screen 
> > > maybe it is possible to write driver that will copy screen from second 
> > > card to a window on first (this could be implemented on guest or on host).
> > > 
> > > 
> > > Grzegorz Kulewski
> > > 
> > > 
> > > On Wed, 12 May 2004, Natalia Portillo wrote:
> > > 
> > > 
> > >>This is the same as making a DirectDraw (2D part of DirectX) driver.
> > >>
> > >>A full DirectX package of drivers will be great: DirectDraw (for 2D), Direct3D (converting calls to OpenGL in host), DirectSound/DirectSound3D and DirectMusic (for the sound card), and DirectInput (keyboards, mice, joysticks)...
> > >>
> > >>On Wed, 12 May 2004 12:30:08 +0100
> > >>"Jamie Burns" <jamie.burns@dynamicexpression.co.uk> wrote:
> > >>
> > >>
> > >>>Wouldn't a 2D accelerator be a good idea first? ;o)
> > >>>
> > >>>If Windows asks for a "line" to be drawn, or a "blit-op" then could that be
> > >>>passed through to the QEMU emulated video hardware, which in turn could
> > >>>simply get SDL or whatever to do the required operation. Then 2D graphics
> > >>>would speed up immensly.
> > >>>
> > >>>Are there any documents giving an overview of how the QEUM architecture
> > >>>works in this respect? I would work on a driver in my spare time but really
> > >>>do not know where to start.
> > >>>
> > >>>J.
> > >>>
> > >>>----- Original Message ----- 
> > >>>From: "Grzegorz Kulewski" <kangur@polcom.net>
> > >>>To: <qemu-devel@nongnu.org>
> > >>>Sent: Wednesday, May 12, 2004 11:20 AM
> > >>>Subject: Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems
> > >>>
> > >>>
> > >>>
> > >>>>On Wed, 12 May 2004, Filip Navara wrote:
> > >>>>
> > >>>>>Jean-Michel POURE wrote:
> > >>>>>
> > >>>>>>>if anyone is interested I have created open source QEMU/Bochs video
> > >>>>>>>driver for Windows NT/2K/XP/2003.
> > >>>>>>>Binaries - www.volny.cz/xnavara/qemuvid_bin.zip
> > >>>>>>>Sources - www.volny.cz/xnavara/qemuvid_src.zip
> > >>>>>>
> > >>>>>>Are these VBE drivers?
> > >>>>>>
> > >>>>>
> > >>>>>Not in the sense of VBE 3.0 specification. I have such driver too, but
> > >>>>>it propably works only on ReactOS because of using undocumented API.
> > >>>>>
> > >>>>>
> > >>>>>>Can you describe the drivers and its capabilities in more details?
> > >>>>>
> > >>>>>The driver uses the Bochs/QEMU VBE I/O port, the same method as used by
> > >>>>>BXVGA. My implementation is a bit simplier, but still with the same
> > >>>>>features. It also uses the Linear FrameBuffer feature of the Bochs/QEMU
> > >>>>>interface that wasn't available at the time when BXVGA was written.
> > >>>>
> > >>>>Are there any driver that works with win9x? Can you port your (or write
> > >>>>it from scratch)?
> > >>>>
> > >>>>Will your driver work in Bochs?
> > >>>>
> > >>>>Is it possible to create driver that emulates DirectX and OpenGL by
> > >>>>sending the OpenGL commands to the host OpenGL libs. DirectX commands
> > >>>>should probably be converted before into OpenGL.
> > >>>>
> > >>>>
> > >>>>Thanks for your work,
> > >>>>
> > >>>>Grzegorz Kulewski
> > >>>>
> > >>>>
> > >>>>
> > >>>>_______________________________________________
> > >>>>Qemu-devel mailing list
> > >>>>Qemu-devel@nongnu.org
> > >>>>http://mail.nongnu.org/mailman/listinfo/qemu-devel
> > >>>
> > >>>
> > >>>
> > >>>_______________________________________________
> > >>>Qemu-devel mailing list
> > >>>Qemu-devel@nongnu.org
> > >>>http://mail.nongnu.org/mailman/listinfo/qemu-devel
> > >>
> > >>
> > >>
> > >>
> > >>_______________________________________________
> > >>Qemu-devel mailing list
> > >>Qemu-devel@nongnu.org
> > >>http://mail.nongnu.org/mailman/listinfo/qemu-devel
> > >>
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Qemu-devel mailing list
> > > Qemu-devel@nongnu.org
> > > http://mail.nongnu.org/mailman/listinfo/qemu-devel
> > > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://mail.nongnu.org/mailman/listinfo/qemu-devel
> > 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Natalia Portillo]

Then, why do you require DirectDraw support for activating acceleration?
Is simply.

When no acceleration is, the GDI calls are rendered manually, when it is activated, they are rendered through DirectDraw.

On Wed, 12 May 2004 23:52:18 +0200 (CEST)
Grzegorz Kulewski <kangur@polcom.net> wrote:

> On Wed, 12 May 2004, Filip Navara wrote:
> > Natalia Portillo wrote:
> > >DirectDraw is the accelerator for GDI.
> >
> > This is not correct. At the driver level GDI calls and DirectDraw calls 
> > are completly separate interfaces implemented different way.
> 
> You are unfortunatelly right. GDI was introduced a lot ealier than 
> DirectX (I think before win95). But GDI can be not accelerated by graphic 
> card but by qemu (using sdl or something like that) because today apps are 
> using GDI mainly for user interface and not for advanced drawing I think. 
> Right?
> 
> 
> Grzegorz Kulewski
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Filip Navara]

Natalia Portillo wrote:

>Then, why do you require DirectDraw support for activating acceleration?
>Is simply.
>
>When no acceleration is, the GDI calls are rendered manually, when it is activated, they are rendered through DirectDraw.
>  
>
No they aren't. Please trust me on this, I know quite a bit of details 
of the Windows NT (and 9x also) architecture and this is just not true.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/graphics/hh/graphics/dispvid_2003_7z53.asp

- Filip

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[David Holm <dholm@gentoo.org>]

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

On Thursday 13 May 2004 05.52, Natalia Portillo wrote:
> Seems easir to implement DirectX (full or partial) emulation.

Wouldn't it just be easier to use qemu-fast with Wine(X)?

> On Wed, 12 May 2004 22:10:57 +0200 (CEST)
>
> Grzegorz Kulewski <kangur@polcom.net> wrote:
> > On Wed, 12 May 2004, Fabrice Bellard wrote:
> > > Why not using the main graphic card ? dosemu does it... All you need is
> > > "just" to be able to switch the rendering contexts. So it is a host VGA
> > > card dependent code, but it can be rather small.
> >
> > I want to be able to play games in it!!! ;-)
> > That means: I am thinking about using as a second card some really good
> > 3d accelerator on pci bus (or on agp if first card is on pci). And that
> > card can not be used by two operating systems at the same time because of
> > some uninterruptable mutualy exclusive operations such as transferring
> > big texture from system memory to video card memory. It can take very
> > long and graphic card can not do anything other until it finishes. So
> > host will not be able to display anything in that time! And we have no
> > method to tell host system: stop using that card for 10ms. And there will
> > be problems with irq routing probably. Think that this card is driven by
> > some closed source binary drivers and you have no specs available. When
> > using second card host system kernel does not touch it at all. But we
> > will need "screenshot" of it from time to time. This can be achieved in
> > two ways:
> >
> > 1. Use guest program that will make screenshot and tell qemu where in
> > memmory it resides or will send it in any other way.
> >
> > 2. qemu will wait until card is free (it can be probably easily checked
> > by some io port sequence) then will stop emulation and will copy
> > screenshot.
> >
> > I hope it all can be done! :-)
> > And hope somebody else will do it! :-)
> >
> >
> > Grzegorz Kulewski
> >
> > > Grzegorz Kulewski wrote:
> > > > Another idea is to allow qemu use second graphic card in your pc (not
> > > > used by the host). I have one spare GeForce 2 @ PCI so I will be glad
> > > > to see this implemented. Before that we will probably need working
> > > > PCI layer in qemu. And I we can track the area in graphic memory used
> > > > by current screen maybe it is possible to write driver that will copy
> > > > screen from second card to a window on first (this could be
> > > > implemented on guest or on host).
> > > >
> > > >
> > > > Grzegorz Kulewski
> > > >
> > > > On Wed, 12 May 2004, Natalia Portillo wrote:
> > > >>This is the same as making a DirectDraw (2D part of DirectX) driver.
> > > >>
> > > >>A full DirectX package of drivers will be great: DirectDraw (for 2D),
> > > >> Direct3D (converting calls to OpenGL in host),
> > > >> DirectSound/DirectSound3D and DirectMusic (for the sound card), and
> > > >> DirectInput (keyboards, mice, joysticks)...
> > > >>
> > > >>On Wed, 12 May 2004 12:30:08 +0100
> > > >>
> > > >>"Jamie Burns" <jamie.burns@dynamicexpression.co.uk> wrote:
> > > >>>Wouldn't a 2D accelerator be a good idea first? ;o)
> > > >>>
> > > >>>If Windows asks for a "line" to be drawn, or a "blit-op" then could
> > > >>> that be passed through to the QEMU emulated video hardware, which
> > > >>> in turn could simply get SDL or whatever to do the required
> > > >>> operation. Then 2D graphics would speed up immensly.
> > > >>>
> > > >>>Are there any documents giving an overview of how the QEUM
> > > >>> architecture works in this respect? I would work on a driver in my
> > > >>> spare time but really do not know where to start.
> > > >>>
> > > >>>J.
> > > >>>
> > > >>>----- Original Message -----
> > > >>>From: "Grzegorz Kulewski" <kangur@polcom.net>
> > > >>>To: <qemu-devel@nongnu.org>
> > > >>>Sent: Wednesday, May 12, 2004 11:20 AM
> > > >>>Subject: Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems
> > > >>>
> > > >>>>On Wed, 12 May 2004, Filip Navara wrote:
> > > >>>>>Jean-Michel POURE wrote:
> > > >>>>>>>if anyone is interested I have created open source QEMU/Bochs
> > > >>>>>>> video driver for Windows NT/2K/XP/2003.
> > > >>>>>>>Binaries - www.volny.cz/xnavara/qemuvid_bin.zip
> > > >>>>>>>Sources - www.volny.cz/xnavara/qemuvid_src.zip
> > > >>>>>>
> > > >>>>>>Are these VBE drivers?
> > > >>>>>
> > > >>>>>Not in the sense of VBE 3.0 specification. I have such driver too,
> > > >>>>> but it propably works only on ReactOS because of using
> > > >>>>> undocumented API.
> > > >>>>>
> > > >>>>>>Can you describe the drivers and its capabilities in more
> > > >>>>>> details?
> > > >>>>>
> > > >>>>>The driver uses the Bochs/QEMU VBE I/O port, the same method as
> > > >>>>> used by BXVGA. My implementation is a bit simplier, but still
> > > >>>>> with the same features. It also uses the Linear FrameBuffer
> > > >>>>> feature of the Bochs/QEMU interface that wasn't available at the
> > > >>>>> time when BXVGA was written.
> > > >>>>
> > > >>>>Are there any driver that works with win9x? Can you port your (or
> > > >>>> write it from scratch)?
> > > >>>>
> > > >>>>Will your driver work in Bochs?
> > > >>>>
> > > >>>>Is it possible to create driver that emulates DirectX and OpenGL by
> > > >>>>sending the OpenGL commands to the host OpenGL libs. DirectX
> > > >>>> commands should probably be converted before into OpenGL.
> > > >>>>
> > > >>>>
> > > >>>>Thanks for your work,
> > > >>>>
> > > >>>>Grzegorz Kulewski
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>_______________________________________________
> > > >>>>Qemu-devel mailing list
> > > >>>>Qemu-devel@nongnu.org
> > > >>>>http://mail.nongnu.org/mailman/listinfo/qemu-devel
> > > >>>
> > > >>>_______________________________________________
> > > >>>Qemu-devel mailing list
> > > >>>Qemu-devel@nongnu.org
> > > >>>http://mail.nongnu.org/mailman/listinfo/qemu-devel
> > > >>
> > > >>_______________________________________________
> > > >>Qemu-devel mailing list
> > > >>Qemu-devel@nongnu.org
> > > >>http://mail.nongnu.org/mailman/listinfo/qemu-devel
> > > >
> > > > _______________________________________________
> > > > Qemu-devel mailing list
> > > > Qemu-devel@nongnu.org
> > > > http://mail.nongnu.org/mailman/listinfo/qemu-devel
> > >
> > > _______________________________________________
> > > Qemu-devel mailing list
> > > Qemu-devel@nongnu.org
> > > http://mail.nongnu.org/mailman/listinfo/qemu-devel
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://mail.nongnu.org/mailman/listinfo/qemu-devel
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAozBwxVDe1wIoqX0RAs/qAJwK2GnXP9KlNw7/JtmaRL+7KZgwBgCgovEW
ge3v9/a/4G+1GX+qciM9Qa0=
=pIb8
-----END PGP SIGNATURE-----

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Jamie Burns]

I double that. GDI and DirectDraw are different things.

Nearly all cards have for some years supported *both* GDI acceleration (from
Windows 3.1 days...) and DirectDraw acceleration (from Windows 95 days...).
Although they support both, they are different sets of code for different
purposes.

----- Original Message ----- 
From: "Filip Navara" <xnavara@volny.cz>
To: <qemu-devel@nongnu.org>
Sent: Thursday, May 13, 2004 8:53 AM
Subject: Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems


> Natalia Portillo wrote:
>
> >Then, why do you require DirectDraw support for activating acceleration?
> >Is simply.
> >
> >When no acceleration is, the GDI calls are rendered manually, when it is
activated, they are rendered through DirectDraw.
> >
> >
> No they aren't. Please trust me on this, I know quite a bit of details
> of the Windows NT (and 9x also) architecture and this is just not true.
>
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/graphics/hh/graphics/dispvid_2003_7z53.asp
>
> - Filip
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Natalia Portillo]

I don't think the nVidia GeForce FX has GDI acceleration.

So how is it accelereting 2D applications (not games, so GDI not DirectDraw) in Windows 95?

On Thu, 13 May 2004 10:56:30 +0100
Jamie Burns <jamie.burns@dynamicexpression.co.uk> wrote:

> I double that. GDI and DirectDraw are different things.
> 
> Nearly all cards have for some years supported *both* GDI acceleration (from
> Windows 3.1 days...) and DirectDraw acceleration (from Windows 95 days...).
> Although they support both, they are different sets of code for different
> purposes.
> 
> ----- Original Message ----- 
> From: "Filip Navara" <xnavara@volny.cz>
> To: <qemu-devel@nongnu.org>
> Sent: Thursday, May 13, 2004 8:53 AM
> Subject: Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems
> 
> 
> > Natalia Portillo wrote:
> >
> > >Then, why do you require DirectDraw support for activating acceleration?
> > >Is simply.
> > >
> > >When no acceleration is, the GDI calls are rendered manually, when it is
> activated, they are rendered through DirectDraw.
> > >
> > >
> > No they aren't. Please trust me on this, I know quite a bit of details
> > of the Windows NT (and 9x also) architecture and this is just not true.
> >
> >
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/graphics/hh/graphics/dispvid_2003_7z53.asp
> >
> > - Filip
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://mail.nongnu.org/mailman/listinfo/qemu-devel
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems

[Filip Navara]

That's matter of the drivers. The nVidia Detonator drivers have the GDI 
accelerated functions of course.

- Filip

Natalia Portillo wrote:

>I don't think the nVidia GeForce FX has GDI acceleration.
>
>So how is it accelereting 2D applications (not games, so GDI not DirectDraw) in Windows 95?
>
>On Thu, 13 May 2004 10:56:30 +0100
>Jamie Burns <jamie.burns@dynamicexpression.co.uk> wrote:
>
>  
>
>>I double that. GDI and DirectDraw are different things.
>>
>>Nearly all cards have for some years supported *both* GDI acceleration (from
>>Windows 3.1 days...) and DirectDraw acceleration (from Windows 95 days...).
>>Although they support both, they are different sets of code for different
>>purposes.
>>
>>----- Original Message ----- 
>>From: "Filip Navara" <xnavara@volny.cz>
>>To: <qemu-devel@nongnu.org>
>>Sent: Thursday, May 13, 2004 8:53 AM
>>Subject: Re: [Qemu-devel] QEMU Video Driver for Win NT-based systems
>>
>>
>>    
>>
>>>Natalia Portillo wrote:
>>>
>>>      
>>>
>>>>Then, why do you require DirectDraw support for activating acceleration?
>>>>Is simply.
>>>>
>>>>When no acceleration is, the GDI calls are rendered manually, when it is
>>>>        
>>>>
>>activated, they are rendered through DirectDraw.
>>    
>>
>>>>        
>>>>
>>>No they aren't. Please trust me on this, I know quite a bit of details
>>>of the Windows NT (and 9x also) architecture and this is just not true.
>>>
>>>
>>>      
>>>
>>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/graphics/hh/graphics/dispvid_2003_7z53.asp
>>    
>>
>>>- Filip
>>>
>>>
>>>_______________________________________________
>>>Qemu-devel mailing list
>>>Qemu-devel@nongnu.org
>>>http://mail.nongnu.org/mailman/listinfo/qemu-devel
>>>      
>>>
>>
>>_______________________________________________
>>Qemu-devel mailing list
>>Qemu-devel@nongnu.org
>>http://mail.nongnu.org/mailman/listinfo/qemu-devel
>>    
>>
>
>
>
>
>_______________________________________________
>Qemu-devel mailing list
>Qemu-devel@nongnu.org
>http://mail.nongnu.org/mailman/listinfo/qemu-devel
>
>
>  
>

[Qemu-devel] Again..

[Ishwar Rattan]

I tried a boot of msdos50.img (floppy disk image) as

	qemu -fda msdos50.img -boot a

and was placed in qemu-monitor?? So, how make it boot?

-ishwar

Re: [Qemu-devel] Again..

[Pavel Janík]

   From: Ishwar Rattan <ishwar@pali.cps.cmich.edu>
   Date: Thu, 20 May 2004 11:43:40 -0400 (EDT)

   > I tried a boot of msdos50.img (floppy disk image) as
   > 
   > 	qemu -fda msdos50.img -boot a
   > 
   > and was placed in qemu-monitor?? So, how make it boot?

How was qemu compiled? Do you have SDL support? Which operating system do
you use?
-- 
Pavel Janík

/* Sun, you just can't beat me, you just can't.  Stop trying, give up.  I'm
serious, I am going to kick the living shit out of you, game over, lights out.
*/                -- Linux kernel: arch/sparc/lib/checksum.S

Re: [Qemu-devel] Again..

[vaise]

On Thursday 20 May 2004 16:43, Ishwar Rattan wrote:
> I tried a boot of msdos50.img (floppy disk image) as
> 	qemu -fda msdos50.img -boot a
> and was placed in qemu-monitor?? So, how make it boot?
Try ?
qemu -fda /dev/fd0 -boot a

This is quite difficult to prepare a bootable .img file.
I gave up, and I have done a non-bootable img file. Then the OS made the boot 
sector during install.

Re: [Qemu-devel] Again..

[Ishwar Rattan]

Is the image file different from a complete image of a
disk/floppy using dd utility?

If so can one use freedos.img.bz2 (expands to 10Mb)? I had
the similar problem with that.

-ishwar

On Thu, 20 May 2004 vaise@votreservice.com wrote:

> On Thursday 20 May 2004 16:43, Ishwar Rattan wrote:
> > I tried a boot of msdos50.img (floppy disk image) as
> > 	qemu -fda msdos50.img -boot a
> > and was placed in qemu-monitor?? So, how make it boot?
> Try ?
> qemu -fda /dev/fd0 -boot a
>
> This is quite difficult to prepare a bootable .img file.
> I gave up, and I have done a non-bootable img file. Then the OS made the boot
> sector during install.
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
>

Re: [Qemu-devel] Again..

[Ishwar Rattan]

I downloaded the sources and it compiled right away (I assume that
it is qemu-0.5.3). System is Linux Mandrake-9.1 Maybe, I should
tried the precompiled binaries.

-ishwar

On Thu, 20 May 2004, [iso-8859-2] Pavel Janík wrote:

>    From: Ishwar Rattan <ishwar@pali.cps.cmich.edu>
>    Date: Thu, 20 May 2004 11:43:40 -0400 (EDT)
>
>    > I tried a boot of msdos50.img (floppy disk image) as
>    >
>    > 	qemu -fda msdos50.img -boot a
>    >
>    > and was placed in qemu-monitor?? So, how make it boot?
>
> How was qemu compiled? Do you have SDL support? Which operating system do
> you use?
> --
> Pavel Janík
>
> /* Sun, you just can't beat me, you just can't.  Stop trying, give up.  I'm
> serious, I am going to kick the living shit out of you, game over, lights out.
> */                -- Linux kernel: arch/sparc/lib/checksum.S
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
>

Re: [Qemu-devel] Again..

[Ishwar Rattan]

System is linux Mandrake-9.1

I dwnloaded the qemu-0.5.5 binaries and installed.
Now, I can boot Freedos disk and see the prompt C:\>
but what can be done with it? As,

C:\> dir
 Volume in drive C has no label
File not found.

C:\>

Any ideas?
-ishwar


On Thu, 20 May 2004, Ishwar Rattan wrote:

> I downloaded the sources and it compiled right away (I assume that
> it is qemu-0.5.3). System is Linux Mandrake-9.1 Maybe, I should
> tried the precompiled binaries.
>
> -ishwar
>
> On Thu, 20 May 2004, [iso-8859-2] Pavel Janík wrote:
>
> >    From: Ishwar Rattan <ishwar@pali.cps.cmich.edu>
> >    Date: Thu, 20 May 2004 11:43:40 -0400 (EDT)
> >
> >    > I tried a boot of msdos50.img (floppy disk image) as
> >    >
> >    > 	qemu -fda msdos50.img -boot a
> >    >
> >    > and was placed in qemu-monitor?? So, how make it boot?
> >
> > How was qemu compiled? Do you have SDL support? Which operating system do
> > you use?
> > --
> > Pavel Janík
> >
> > /* Sun, you just can't beat me, you just can't.  Stop trying, give up.  I'm
> > serious, I am going to kick the living shit out of you, game over, lights out.
> > */                -- Linux kernel: arch/sparc/lib/checksum.S
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://mail.nongnu.org/mailman/listinfo/qemu-devel
> >
>

[Qemu-devel] Minix-2.0.4 boot??

[Ishwar Rattan]

The home page lists that minix boots correctly in qemu.

1. Where can I find the disk image?
2. Procedure to boot the image?

Thanks in advance,
-ishwar

Re: [Qemu-devel] Again..

[Pavel Janík]

   From: Ishwar Rattan <ishwar@pali.cps.cmich.edu>
   Date: Fri, 21 May 2004 09:02:50 -0400 (EDT)

   > I dwnloaded the qemu-0.5.5 binaries and installed.
   > Now, I can boot Freedos disk and see the prompt C:\>
   > but what can be done with it? As,
   > 
   > C:\> dir
   >  Volume in drive C has no label
   > File not found.
   > 
   > C:\>

Command line you used is? What was used as -hda?
-- 
Pavel Janík

panic("mother...");
                  -- 2.2.16 drivers/block/cpqarray.c

Re: [Qemu-devel] Again..

[Ishwar Rattan]

Command used was

	qemu -hda Freedos.img -boot c

-ishwar


On Fri, 21 May 2004, [iso-8859-2] Pavel Janík wrote:

>    From: Ishwar Rattan <ishwar@pali.cps.cmich.edu>
>    Date: Fri, 21 May 2004 09:02:50 -0400 (EDT)
>
>    > I dwnloaded the qemu-0.5.5 binaries and installed.
>    > Now, I can boot Freedos disk and see the prompt C:\>
>    > but what can be done with it? As,
>    >
>    > C:\> dir
>    >  Volume in drive C has no label
>    > File not found.
>    >
>    > C:\>
>
> Command line you used is? What was used as -hda?
> --
> Pavel Janík
>
> panic("mother...");
>                   -- 2.2.16 drivers/block/cpqarray.c
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
>

Re: [Qemu-devel] Again..

[Pavel Janík]

   From: Ishwar Rattan <ishwar@pali.cps.cmich.edu>
   Date: Fri, 21 May 2004 17:40:45 -0400 (EDT)

Hi,

   > 	qemu -hda Freedos.img -boot c

[...]

   > >    > C:\> dir
   > >    >  Volume in drive C has no label
   > >    > File not found.
   > >    >
   > >    > C:\>

when booting, skip AUTOEXEC.BAT execution and you can then even play
Mario ;-)
-- 
Pavel Janík

/* ...zzzzzz */
                  -- An unknown author in drivers/sound/via82cxxx_audio.c

Re: [Qemu-devel] Minix-2.0.4 boot??

[Jim C. Brown]

On Fri, May 21, 2004 at 11:39:30AM -0400, Ishwar Rattan wrote:
> 
> The home page lists that minix boots correctly in qemu.
> 
> 1. Where can I find the disk image?
> 2. Procedure to boot the image?
> 
> Thanks in advance,
> -ishwar
> 
> 

The URL is:

http://minix1.bio.umass.edu/pub/contrib/mx204bx01.zip

if that site is down you can also try this one:

http://minix1.hampshire.edu/pub/contrib/mx204bx01.zip

Note that for this image to work you need to pass the "-hdachs 200,16,63"
option to qemu or else the minix bootloader will not work.

Also note that, due to a bug in Minix, you will not be able to use the ethernet
card. I have not figured out how to fix Minix yet, but I do have a patch that
adds a workaround to qemu itself, so that the emulation will work with Minix's
broken driver. If you want it, I can send it to you, but be aware that its against
qemu 0.5.5, not qemu CVS.

> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.