There is a Linux RealVNC client. But glad you found a viewer that works for
you anyhow!
-- Keir
On 16/11/07 11:01, "Christoph Egger" <Christoph.Egger@xxxxxxx> wrote:
>
> Yes, I did. Now I am happily using the svn version of ggivnc.
> RealVNC is windows-only, but my development & testing network
> is heterogen.
>
> Christoph
>
> On Thursday 15 November 2007 16:08:09 Keir Fraser wrote:
>> Yes, I guess you're using TightVNC? I always have much better experience
>> with RealVNC.
>>
>> -- Keir
>>
>> On 15/11/07 14:58, "Christoph Egger" <Christoph.Egger@xxxxxxx> wrote:
>>> The HVM guest window resizing problem via VNC is NOT a Xen/Qemu bug.
>>> The actual problem is the vncviewer client lacking support for the
>>> DesktopSize VNC pseudo-encoding. Clients missing this feature don't
>>> get notified from the server.
>>>
>>> Looking a little around, I found two VNC clients which support this:
>>> RealVNC and ggivnc (SVN(!) version,
>>> http://www.lysator.liu.se/~peda/ggivnc/).
>>>
>>> Christoph
>>>
>>> On Thursday 08 November 2007 13:49:47 Christoph Egger wrote:
>>>> My OpenSuSE 10.2 HVM guest is 64bit.
>>>>
>>>> I just found a workaround:
>>>> Close the vnc client and re-connect. Then the vnc client uses
>>>> a larger window and I can actually see the cursor line.
>>>>
>>>> This behaviour looks very much to me that the vnc server code
>>>> does not notify the client about graphic mode changes.
>>>>
>>>> Christoph
>>>>
>>>> On Tuesday 06 November 2007 17:26:45 Dave Lively wrote:
>>>>> Hi Christoph -
>>>>> I'm trying to reproduce the behavior you're seeing. Is your guest
>>>>> 32- or 64-bit?
>>>>>
>>>>> Dave
>>>>>
>>>>> On 11/5/07, Christoph Egger <Christoph.Egger@xxxxxxx> wrote:
>>>>>> An obvious bug I am seeing (but is not indicated by this certain
>>>>>> diagnostic message) is a scrolling bug. It appears when I boot a HVM
>>>>>> guest that uses a graphic mode (e.g. OpenSuSE 10.2). I am connected
>>>>>> via VNC to it. I don't see the line where the cursor is. I have to
>>>>>> blindely guess when the guest expects me to log in. After a (blind)
>>>>>> successful login, I have to type something like 'ls' several times,
>>>>>> until I see what I actually typed and the output of what I typed.
>>>>>> The latest changeset I tried is 16317 and the bug is reproducable.
>>>>>> The oldest changeset I tried so far is 16281 and this issue was
>>>>>> reproducable there, too. I hope, that helps.
>>>>>>
>>>>>> Christoph
>>>>>>
>>>>>> On Monday 05 November 2007 17:38:24 Robert Phillips wrote:
>>>>>>> Hi Christoph,
>>>>>>>
>>>>>>> What you are seeing is (I hope) just an annoying diagnostic. If you
>>>>>>> reduce your guest log level or eliminate the gdprintk() the problem
>>>>>>> should go away.
>>>>>>>
>>>>>>> The diagnostic is warning that the ioreq could not be placed in the
>>>>>>> buffered iopage so it is being sent synchronously to qemu.
>>>>>>> The ioreq could not be placed in the buffered iopage because it
>>>>>>> couldn't be condensed into the (new) format.
>>>>>>> The new format has no room to store 'count' so ioreqs with count != 1
>>>>>>> take the slow route.
>>>>>>>
>>>>>>> Our experience is that the few ioreqs handled this way are far out
>>>>>>> numbered by the condensable ioreqs
>>>>>>> and since far more condensable ioreqs now fit in the buffered iopage
>>>>>>> (than would fit with the old format)
>>>>>>> the performance improvement is substantial.
>>>>>>>
>>>>>>> If the diagnostic is pointless and annoying, it should be eliminated.
>>>>>>>
>>>>>>> -- Robert Phillips
>>>>>>>
>>>>>>> On 11/5/07, Christoph Egger <Christoph.Egger@xxxxxxx> wrote:
>>>>>>>> Hello Ropert!
>>>>>>>>
>>>>>>>> Since changeset 16285 (xen-staging), I get the following output
>>>>>>>> when I launch
>>>>>>>> a HVM guest and VGABios is running:
>>>>>>>>
>>>>>>>>
>>>>>>>> -------------------------------------------------------------------
>>>>>>>> -- ---- -------------- (XEN) intercept.c:172:d1 slow ioreq. type:1
>>>>>>>> size:1 addr:0xa0000 dir:0 ptr:1
>>>>>>>> df:0 count:16
>>>>>>>> (XEN) intercept.c:172:d1 slow ioreq. type:1 size:1 addr:0xa0020
>>>>>>>> dir:0 ptr:1
>>>>>>>> df:0 count:16
>>>>>>>> (XEN) intercept.c:172:d1 slow ioreq. type:1 size:1 addr:0xa0040
>>>>>>>> dir:0 ptr:1
>>>>>>>> df:0 count:16
>>>>>>>> (XEN) intercept.c:172:d1 slow ioreq. type:1 size:1 addr:0xa0060
>>>>>>>> dir:0 ptr:1
>>>>>>>> df:0 count:16
>>>>>>>> (XEN) intercept.c:172:d1 slow ioreq. type:1 size:1 addr:0xa0080
>>>>>>>> dir:0 ptr:1
>>>>>>>> df:0 count:16
>>>>>>>> (XEN) intercept.c:172:d1 slow ioreq. type:1 size:1 addr:0xa00a0
>>>>>>>> dir:0 ptr:1
>>>>>>>> df:0 count:16
>>>>>>>> [...]
>>>>>>>> (XEN) intercept.c:172:d1 slow ioreq. type:1 size:1 addr:0xa1fe0
>>>>>>>> dir:0 ptr:1
>>>>>>>> df:0 count:16
>>>>>>>>
>>>>>>>> -------------------------------------------------------------------
>>>>>>>> -- ---- -----------------
>>>>>>>>
>>>>>>>> This is not the full output (to keep this mail readable). The
>>>>>>>> address output
>>>>>>>> starts from 0xa0000 and goes to 0xa1fe0 and it always increases by
>>>>>>>> 0x20. (So you can generate the full output yourself :)
>>>>>>>>
>>>>>>>> The output comes from xen/arch/x86/intercept.c, function
>>>>>>>> hvm_buffered_io_send().
>>>>>>>> It is this code snippet:
>>>>>>>>
>>>>>>>> /* Return 0 for the cases we can't deal with. */
>>>>>>>> if ( (p->addr > 0xffffful) || p->data_is_ptr || p->df ||
>>>>>>>> (p->count != 1) )
>>>>>>>> {
>>>>>>>> gdprintk(XENLOG_DEBUG, "slow ioreq. type:%d size:%"PRIu64"
>>>>>>>> addr:0x%"
>>>>>>>> PRIx64" dir:%d ptr:%d df:%d count:%"PRIu64"\n",
>>>>>>>> p->type, p->size, p->addr, !!p->dir,
>>>>>>>> !!p->data_is_ptr, !!p->df, p->count);
>>>>>>>> return 0;
>>>>>>>> }
>>>>>>>>
>>>>>>>> It looks like the problem was there before changeset 16285 but got
>>>>>>>> uncovered
>>>>>>>> with the addition of the debug output.
>>>>>>>>
>>>>>>>> Christoph
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home