[Qemu-devel] Current state of RFB patch

[Qemu-devel] Current state of RFB patch

[Andreas Bollhalder]

Hello all

What is the current state of the RFB aka VNC patch ?

I tried to apply the RFB9 to the QEMU daily set from 15.3.2005. I did
this on a Mandrake 10.0 installation with SDL 1.2.7 and the current
libvncserver library. I got some hunk errors and applying it by hand
didn't let me compile it at the end.

There is the confusing thing, that the keyboard support from it got
included into the current CVS but the VNC part not.

After all, I applied the RFB9 patch to the QEMU 0.6.1 source
distribution. I can compile it and it installs fine. Now my idea is to
use the VNC part without an X server output on that machine. I can
start a TightVNC server and connect with a client to it. Starting QEMU
with "-nographic" gives me the prompt "(QEMU)", but can't enter any
thing, only use the CTRL-a commands. When I use "-k de-ch" or any
other keyboard layout, I get an error that it could not find the
keymapping and that it will use the default ones. Without
"-nographic", it reports an "SDL error".

My questions are:

1. Is the VNC option still supported in one way on the current CVS of
QEMU ?

2. Can I use the VNC option on a machine without running X ? (My
servers never have an X...)

3. Does the VNC option require only the libvncserver library or also
the ThightVNC server ?

4. Does I need to use the NOSDL patch ?

I got stuck with my testings, because I don't know what all kind is
supposed to work.

Thanks in advance

Andreas

Re: [Qemu-devel] Current state of RFB patch

[Johannes Schindelin]

Hi,

On Sun, 20 Mar 2005, Andreas Bollhalder wrote:

> What is the current state of the RFB aka VNC patch ?

I wanted to make a new patch this year with an updated mouse handling, but
I didn't come around to do it yet. I'm not at my development machine ATM,
but tomorrow I will create an RFB10 patch, promise!

Ciao,
Dscho

Re: [Qemu-devel] Current state of RFB patch

[zitu]

Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> I wanted to make a new patch this year with an updated mouse handling, but
> I didn't come around to do it yet. I'm not at my development machine ATM,
> but tomorrow I will create an RFB10 patch, promise!

looking forward to it :)
Zitu

PS: it could be interesting then to have qemu+vnc running on colinux, and
get a bit more performance than the std qemu on windows hosts.

Re: [Qemu-devel] Current state of RFB patch

[Johannes Schindelin]

Hi,

On Mon, 21 Mar 2005, zitu wrote:

> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > I wanted to make a new patch this year with an updated mouse handling, but
> > I didn't come around to do it yet. I'm not at my development machine ATM,
> > but tomorrow I will create an RFB10 patch, promise!
>
> looking forward to it :)

Well, here you are:

http://libvncserver.sf.net/qemu/qemu-rfb10.patch.gz

Have fun!

One remark, though: it is a quick hack to make it apply to the current
CVS, so to use your mouse, you have to make sure that the guest OS does
not accelerate your pointer. In Windows: in Settings, look for Mouse and
set it to "slowest". With x11: "xset m 1".

> PS: it could be interesting then to have qemu+vnc running on colinux, and
> get a bit more performance than the std qemu on windows hosts.

I am doubtful if that is so much faster, but would appreciate if you
provided me with hard numbers...

Ciao,
Dscho

Re: [Qemu-devel] Current state of RFB patch

[use.reply-to.address]

>Well, here you are:
>
>http://libvncserver.sf.net/qemu/qemu-rfb10.patch.gz
>
>Have fun!
>
>One remark, though: it is a quick hack to make it apply to the current
>CVS, so to use your mouse, you have to make sure that the guest OS does
>not accelerate your pointer. In Windows: in Settings, look for Mouse and
>set it to "slowest". With x11: "xset m 1".
>  
>
is it possible to have qemu disable host mouse acceleration while it has 
focus ? some guest os do not allow disabling of acceleration

for example in dos , some games have their own builtin mouse driver , 
and you can't control acceleration on those
off course a generic vnc client can't do that , so maybe then there 
could be a de-acceleration routine in the qemu-vnc interface code ?

Re: [Qemu-devel] Current state of RFB patch

[Jim C. Brown]

On Mon, Mar 21, 2005 at 03:14:05PM -0500, use.reply-to.address@domn.net wrote:
> >
> is it possible to have qemu disable host mouse acceleration while it has 
> focus ? some guest os do not allow disabling of acceleration
> 

I suppose, but I do not understand how this could help you.

> for example in dos , some games have their own builtin mouse driver , 
> and you can't control acceleration on those
> off course a generic vnc client can't do that , so maybe then there 
> could be a de-acceleration routine in the qemu-vnc interface code ?
> 

That is not really possible. There can be no generic de-acceleration
routine, tho you might be able to hack it for one particular OS/DOS game if
you knew by what factor it accelerated.

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

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

Re: [Qemu-devel] Current state of RFB patch

[Struan Bartlett]

Johannes Schindelin wrote:

>On Mon, 21 Mar 2005, zitu wrote:
>  
>
>>Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>    
>>
>>>I wanted to make a new patch this year with an updated mouse handling, but
>>>I didn't come around to do it yet. I'm not at my development machine ATM,
>>>but tomorrow I will create an RFB10 patch, promise!
>>>      
>>>
>Well, here you are:
>
>http://libvncserver.sf.net/qemu/qemu-rfb10.patch.gz
>  
>
This patches, but compile breaks:

gcc-3.3 -march=pentium -DQEMU_TOOL -Wall -O2 -g -fno-strict-aliasing -g 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o qemu-img 
qemu-img.c block.c block-cow.c block-qcow.c aes.c block-vmdk.c 
block-cloop.c block-dmg.c -lz
sh create_keysym_header.sh vnc ""
Usage: create_keysym_header.sh vnc|sdl cflags
make: *** [keysym_adapter_vnc.h] Error 1

Looks like create_keysym_header.sh isn't being called with a second 
argument that gets past it's argument checking. Strange because my 
config-host.mak has CFLAGS=-O2 in it. Anyway, hacking 
create_keysym_header.sh to hardcode cflags=-O2 allowed my compile to 
continue. But now I'm having a problem launching QEMU with -vnc.

$ qemu -hda win2k.qcow -m 64  -monitor stdio -k en-gb -vnc
<snip>
Warning: could not read keymap - falling back native keycodes!
Could not initialize keyboard

The keymap files are there alright in /usr/local/share/qemu/keymaps/ and 
the same command, minus the -vnc, starts QEMU just fine.

Any suggestions?

Struan

Re: [Qemu-devel] Current state of RFB patch

[Johannes Schindelin]

Hi,

On Mon, 21 Mar 2005, Struan Bartlett wrote:

> This patches, but compile breaks:
>
> gcc-3.3 -march=pentium -DQEMU_TOOL -Wall -O2 -g -fno-strict-aliasing -g
> -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o qemu-img
> qemu-img.c block.c block-cow.c block-qcow.c aes.c block-vmdk.c
> block-cloop.c block-dmg.c -lz
> sh create_keysym_header.sh vnc ""

The cflags are assumed to be the include path to rfb.h. Probably you did
not use a current LibVNCServer, or you have an old libvncserver-config in
your path.

> But now I'm having a problem launching QEMU with -vnc.
>
> $ qemu -hda win2k.qcow -m 64  -monitor stdio -k en-gb -vnc
> <snip>
> Warning: could not read keymap - falling back native keycodes!
> Could not initialize keyboard

Beware! RFB support is not yet for the faint-hearted! ATM if you don't
have the keymaps/ directory in your current working path, you don't get
support from RFB.

Yes, yes, I know. keymaps should be taken from qemu's default path, the
mouse should be calibrated automatically, and all the rest. If somebody
wants to see about that, well, go ahead. ATM I unfortunately don't have
time to spare.

Ciao,
Dscho

RE: [Qemu-devel] Current state of RFB patch

[Andreas Bollhalder]

Hola

I have successfully testet the rfb10 patch on Mandrake 10.0 with the
current build of QEMU. It's that great, to start any guest OS using a
GUI on a Linux with only a CLI ;-) That's a big thing. As known, the
mouse behavior is a little bit odd. I use the de-ch keymap, it needs
some research for having the whole swiss german keyboard function
correctly.

Many thanks to all helping on this project.

Andreas

> -----Original Message-----
> From: qemu-devel-bounces+bolle=geodb.org@nongnu.org 
> [mailto:qemu-devel-bounces+bolle=geodb.org@nongnu.org] On 
> Behalf Of Johannes Schindelin
> Sent: Tuesday, March 22, 2005 2:13 AM
> To: qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] Current state of RFB patch
> 
> 
> *This message was transferred with a trial version of 
> CommuniGate(tm) Pro*
> Hi,
> 
> On Mon, 21 Mar 2005, Struan Bartlett wrote:
> 
> > This patches, but compile breaks:
> >
> > gcc-3.3 -march=pentium -DQEMU_TOOL -Wall -O2 -g 
> -fno-strict-aliasing -g
> > -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -o
qemu-img
> > qemu-img.c block.c block-cow.c block-qcow.c aes.c block-vmdk.c
> > block-cloop.c block-dmg.c -lz
> > sh create_keysym_header.sh vnc ""
> 
> The cflags are assumed to be the include path to rfb.h. 
> Probably you did
> not use a current LibVNCServer, or you have an old 
> libvncserver-config in
> your path.
> 
> > But now I'm having a problem launching QEMU with -vnc.
> >
> > $ qemu -hda win2k.qcow -m 64  -monitor stdio -k en-gb -vnc
> > <snip>
> > Warning: could not read keymap - falling back native keycodes!
> > Could not initialize keyboard
> 
> Beware! RFB support is not yet for the faint-hearted! ATM if you
don't
> have the keymaps/ directory in your current working path, you 
> don't get
> support from RFB.
> 
> Yes, yes, I know. keymaps should be taken from qemu's default 
> path, the
> mouse should be calibrated automatically, and all the rest. 
> If somebody
> wants to see about that, well, go ahead. ATM I unfortunately 
> don't have
> time to spare.
> 
> Ciao,
> Dscho
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

Re: [Qemu-devel] Current state of RFB patch

[Brad Campbell]

Johannes Schindelin wrote:
> Well, here you are:
> 
> http://libvncserver.sf.net/qemu/qemu-rfb10.patch.gz
> 
> Have fun!
> 
> One remark, though: it is a quick hack to make it apply to the current
> CVS, so to use your mouse, you have to make sure that the guest OS does
> not accelerate your pointer. In Windows: in Settings, look for Mouse and
> set it to "slowest". With x11: "xset m 1".
> 

Wow. Mouse accuracy is rock solid, although it takes forever for the pointer to reach its 
destination and the overshoot and overcorrection is good for a laugh!

Linux host and XP guest.
Neato!

Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

RE: [Qemu-devel] Current state of RFB patch

[Andreas Bollhalder]

Hallo Johannes

Thousend thanks for your work !!! I hope that I didn't hurt you ;-) I
can try it out the patch next week when I'm at my machine.

Andreas

> -----Original Message-----
> From: qemu-devel-bounces+bolle=geodb.org@nongnu.org 
> [mailto:qemu-devel-bounces+bolle=geodb.org@nongnu.org] On 
> Behalf Of Johannes Schindelin
> Sent: Monday, March 21, 2005 8:51 PM
> To: qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] Current state of RFB patch
> 
> 
> *This message was transferred with a trial version of 
> CommuniGate(tm) Pro*
> Hi,
> 
> On Mon, 21 Mar 2005, zitu wrote:
> 
> > Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > > I wanted to make a new patch this year with an updated 
> mouse handling, but
> > > I didn't come around to do it yet. I'm not at my 
> development machine ATM,
> > > but tomorrow I will create an RFB10 patch, promise!
> >
> > looking forward to it :)
> 
> Well, here you are:
> 
> http://libvncserver.sf.net/qemu/qemu-rfb10.patch.gz
> 
> Have fun!
> 
> One remark, though: it is a quick hack to make it apply to the
current
> CVS, so to use your mouse, you have to make sure that the 
> guest OS does
> not accelerate your pointer. In Windows: in Settings, look 
> for Mouse and
> set it to "slowest". With x11: "xset m 1".
> 
> > PS: it could be interesting then to have qemu+vnc running 
> on colinux, and
> > get a bit more performance than the std qemu on windows hosts.
> 
> I am doubtful if that is so much faster, but would appreciate if you
> provided me with hard numbers...
> 
> Ciao,
> Dscho
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

Re: [Qemu-devel] Current state of RFB patch

[zitu]

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

Thanks Johannes

> PS: it could be interesting then to have qemu+vnc running on colinux, and
> get a bit more performance than the std qemu on windows hosts.

sorry for the confusion. What I meant was to get qemu+vnc+kqemu running on
a colinux process, on a Windows host. As you know, kqemu is not yet
available on windows host. That's what I meant as a speed improvement.
I'm hoping that the mouse issues might be linked to a speed bottleneck
between the slowness of qemu without kqemu and the VNC protocol.

Regarding your latest patch, it does not work straight out of the box
on windows hosts. Even with mouse acceleration removed, the calibration is
not there: there's a huge difference between the true location of the mouse
and the one inside vnc... I can still see lots of latency between the slow
move I do and the moment the mouse reacts inside qemu. :(

The mouse calibration which I could call before is not working CTRL-ALT-M :(

To compile successfully, I had to modify for mingw32 the file
"keysym_adapter_vnc.h". rfb9 also needed this. I attached the
file to this email. Maybe this is what is causing some of my keyboards
problem, especially when I switch to the qemu console mode (CTRL-ALT-2).
I've difficulties to come back to the std qemu window inside VNC.

Overall, the mouse looks more responsive than last time. It's still positive!
I'll do some more checks. But no time yet for a colinux check.

Thanks again.
Zitu


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


--


[-- Attachment #2: keysym_adapter_vnc.h.gz --]
[-- Type: application/x-gzip, Size: 4374 bytes --]