Troy Benjegerdes wrote:
The VNC protocol says the server is is supposed to send the data in the
format the client wants, however the current implementation sends vnc
data in the server native format.
What is the best way to fix this? Using -bgr is not right since that
will mess up same-endian cl
Ben Taylor wrote:
Troy Benjegerdes <[EMAIL PROTECTED]> wrote:
On Fri, May 05, 2006 at 09:06:20AM -0500, Anthony Liguori wrote:
Ben Taylor wrote:
I'm seeing quite a few bugs on Qemu 0.8.1 with the vnc feature
1) Sparc based system comes up in distored colors (foreground of
This patch is to allow the onboard samba configuration in qemu to correctly
start
the samba server on Solaris (It's in a different location than a normal linux
system).
Bendiff -ruN qemu-orig/vl.c qemu/vl.c
--- qemu-orig/vl.c 2006-05-03 18:02:44.0 -0400
+++ qemu/vl.c 2006-05-12 20:48:32
Troy Benjegerdes <[EMAIL PROTECTED]> wrote:
> Much better.
>
> I did have one bogon after running xvncview on a big-endian host,
> closing it, then starting it on a little-endian host that resulted in
> this from realvnc:
>
> Rect too big: 24832x33024 at 8448,16640 exceeds 640x480
> main:
On Fri, May 12, 2006 at 07:08:31PM -0500, Troy Benjegerdes wrote:
> Much better.
>
> I did have one bogon after running xvncview on a big-endian host,
> closing it, then starting it on a little-endian host that resulted in
> this from realvnc:
>
> Rect too big: 24832x33024 at 8448,16640 exceeds 6
Much better.
I did have one bogon after running xvncview on a big-endian host,
closing it, then starting it on a little-endian host that resulted in
this from realvnc:
Rect too big: 24832x33024 at 8448,16640 exceeds 640x480
main:Rect too big
On Sat, May 13, 2006 at 01:02:47AM +0200,
Troy Benjegerdes wrote:
The VNC protocol says the server is is supposed to send the data in the
format the client wants, however the current implementation sends vnc
data in the server native format.
What is the best way to fix this? Using -bgr is not right since that
will mess up same-endian cl
Troy Benjegerdes wrote:
The VNC protocol says the server is is supposed to send the data in the
format the client wants, however the current implementation sends vnc
data in the server native format.
What is the best way to fix this? Using -bgr is not right since that
will mess up same-endian cl
On Fri, 2006-12-05 at 22:21 +0200, Flavio Visentin wrote:
> OT for qemu, but if you use *rsync*, then only the changed part of the
> file are copied, not all the file. Rsync was written just for this
> reason, to avoid copying unneccessary unchanged data.
But as soon as the modification stamp chan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ryan Lortie wrote:
> I use rsync to backup my home directory. The act of starting up QEMU
> changes a 20GB file on my drive. This causes 20GB of extra copying next
> time I do backups.
OT for qemu, but if you use *rsync*, then only the changed part
The VNC protocol says the server is is supposed to send the data in the
format the client wants, however the current implementation sends vnc
data in the server native format.
What is the best way to fix this? Using -bgr is not right since that
will mess up same-endian clients.
_
> Anyway, many people think of OpenGL as just 3D, but it is extremely
> competent for 2D (given a good driver).
That's where your argument falls down.
I wouldn't be surprised if even a crappy OpenGL implementation could beat
plain GDI. However I'd guess most OpenGL drivers are optimised for commo
Jamie Lokier wrote:
Dan Sandberg wrote:
When the screen is "painted" the DAC's read from the host video buffer
(1600x1200) and interpret it as RGB. Somewhere they "hit" the left
boundary of the separate viewport that you have set up and bang, on the
fly they switch to reading 800x600-organ
Hi there,
> o If the files comprising the device are deleted (for example) while
>QEMU is running then this is quite bad. Currently this will result
>in read/write requests returning -1. Maybe it makes sense to panic
>and cause QEMU to exit.
>
at the very least, the console shoul
On Fri, 2006-12-05 at 09:35 -0500, Troy Benjegerdes wrote:
> Have you tried making a read-only 'base' image and using qcow images
> instead? I'm not convinced that splitting things up is going to help a
> lot. You might end up writing 1 512 byte block each to 500 files.. in
> the qcow image case,
Dan Sandberg wrote:
> When the screen is "painted" the DAC's read from the host video buffer
> (1600x1200) and interpret it as RGB. Somewhere they "hit" the left
> boundary of the separate viewport that you have set up and bang, on the
> fly they switch to reading 800x600-organized data from the
Jamie Lokier wrote:
Dan Sandberg wrote:
Creating a rectangular direct output area in OpenGL is actually like
vitualizing a graphics card.
That is what X's XF86DGA ("Direct Graphics Adapter") feature does.
And I believe SDL already supports XF86DGA when in full screen mode.
It is
On Thu, May 11, 2006 at 02:30:45AM -0400, Ryan Lortie wrote:
> Hello.
>
> Attached is a C file (and small patch) to add support for multi-file raw
> images to QEMU. The rationale (for me at least) is as follows:
>
> I use rsync to backup my home directory. The act of starting up QEMU
> changes
"Fabrice Bellard" <[EMAIL PROTECTED]> wrote:
I just commited a fix.
Qemu/MIPS does not initialize an ISA memory region when issued
without -kernel option. (I've added some debug output).
Thank you! The new version runs 'mmon' as BIOS successfully.
If someone has an intersest, it is possible t
Dan Sandberg wrote:
> Creating a rectangular direct output area in OpenGL is actually like
> vitualizing a graphics card.
That is what X's XF86DGA ("Direct Graphics Adapter") feature does.
And I believe SDL already supports XF86DGA when in full screen mode.
> It is updated at native speed
Not n
Ishwar Rattan <[EMAIL PROTECTED]> wrote:
> I was able to compile the qemu-cvs code with Taylor's
> patches applied. I did not see a qemu executable? Is it
> the same as qemu/aprc-softmmu/qemu-system-sparc? When
> I try to use it it keeps complaining that it can't
> load::
>
> /usr/local/sh
Troy Benjegerdes <[EMAIL PROTECTED]> wrote:
> On Fri, May 05, 2006 at 09:06:20AM -0500, Anthony Liguori wrote:
> > Ben Taylor wrote:
> > >I'm seeing quite a few bugs on Qemu 0.8.1 with the vnc feature
> > >
> > >1) Sparc based system comes up in distored colors (foreground of a Damn
> > >Sm
Hi,
On 12/05/06, Troy Benjegerdes <[EMAIL PROTECTED]> wrote:
On Fri, May 05, 2006 at 09:06:20AM -0500, Anthony Liguori wrote:
> Ben Taylor wrote:
> >I'm seeing quite a few bugs on Qemu 0.8.1 with the vnc feature
> >
> >1) Sparc based system comes up in distored colors (foreground of a Damn
> >Sm
Fabrice Bellard wrote:
Dan Sandberg wrote:
Just curious...
Are you using an OpenGL directdraw surface for the graphics emulation
in Qemu?
If not, then consider the benefits:
1. It is much faster than any native graphics 2D/3D primitives like
Windows GDI
2: It gives full control over things
24 matches
Mail list logo
