Even Rouault a écrit :
TODO list :
- implement correctly full OpenGL API
Did you consider taking a look at how Wine wraps OpenGL and/or
how Mesa makes its dispatchers? I think they may be of use,
and their license should be compatible :)
Laurent
2006/11/16, Even Rouault <[EMAIL PROTECTED]>:
Here's an attempt of providing accelerated OpenGL for QEMU.
I must underline first that it should really really be considered as
experimental or a proof-of-concept. There's
still a lot of work to do to make it reliable and releasable.
So what is it e
On Mon, Nov 13, 2006 at 02:30:27PM -0500, Daniel Jacobowitz wrote:
> I was trying to run GDB remote debug tests through a -redir socket
> today. It crawled unbelievably. Paul guessed that slirp wasn't using
> TCP_NODELAY, and Nagle was to blame.
>
> He was even righter than usual. Adding TCP_NO
> My main remark is that the host/guest communication system must be
> changed and I can help you to implement it. I would prefer to use a PCI
> device and to avoid any i386 dependent code. For the PCI device, using
> the Bochs VGA adapter could be a possible idea. All the parameters and
> data sho
On Fri, Nov 17, 2006 at 11:29:45AM +1100, herbert wrote:
>
> Since I haven't heard any objections, here is a patch to do just that.
In the interest of diffing things twice, here is a more complete
patch.
[QEMU] rtl8139: Disallow chaining above 64K
As it stands the 8139C+ TX chaining is only bou
On Wed, Nov 15, 2006 at 03:38:27PM +1100, herbert wrote:
>
> CP_TX_BUFFER_SIZE is already 64K. So it seems to me that we don't need
> the while loop to extend the buffer at all since no transmitted packet
> should be anywhere near this size.
>
> Are there any objections to getting rid of the fol
Hi,
I find your patch interesting and I'll try to include it in QEMU ASAP.
My main remark is that the host/guest communication system must be
changed and I can help you to implement it. I would prefer to use a PCI
device and to avoid any i386 dependent code. For the PCI device, using
the Boch
Follow this link to unsubscribe:
http://lists.nongnu.org/mailman/listinfo/qemu-devel
On 11/17/06, Djamé <[EMAIL PROTECTED]> wrote:
pleaaase
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-deve
pleaaase
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Hi,
If your patch is big, bzip2 or gzip are good tools for compression and
sending the files on the mailing list.
Alternativly, we have the QEMU Forum which you can post a message and
attach a file up to 256 Kbyte size (and I'm sure Pablo could expand it
a bit if necessary).
Here's your patch,
I've found some free storage online site... If someone knows some other
alternatives, I'll be interested in.
Here's a link to download the patch :
http://www.4shared.com/file/6018776/13812e35/qemu_opengl.html
If it doesn't work, go to http://www.4shared.com/, and log as
[EMAIL PROTECTED], pass
Here's an attempt of providing accelerated OpenGL for QEMU.
I must underline first that it should really really be considered as
experimental or a proof-of-concept. There's
still a lot of work to do to make it reliable and releasable.
So what is it exactly ?
- a patch for QEMU itself that intercep
On Thu, Nov 16, 2006 at 07:52:45AM +, Keir Fraser wrote:
>
> Each qemu 'stub domain' will be dedicated to a single guest. Adding a
You're right of course. Somehow I was thinking of having the physical
NIC in the qemu domain which obviously isn't the case.
> recursion counter to the memory a
13 matches
Mail list logo
