| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] RE: [PATCH][1/10] Device model cleanup.
> > * I presume that the vncviewer is being forked from xm, but
> that the
> > vncconect is being issued from xend, which is why it needs
> the $DISPLAY
> > ?
>
> Rolf applied a patch sometime back that has two separate ways
> of connect a vncviewer to device models:
>
> a) vncviewer -listen (port communicated to xend and then to
> qemu via -vncconnect). This is forked from xm.
> b) libvncserver within qemu-dm (-vncport). This is forked from xend.
>
> And then
>
> c) the user may choose vnc=0 sdl=1.
Just to check I understand:
In (a), xm forks off vncviewer, qemu-dm runs libvncserver and then
connects back to the viewer. I presume we can still fix the local port
with -vncport?
In (b), what is actually forking the vncviewer, and when does it know
that the libvncserver is up and running?
For (c), we just pop up an Xwindow on the Display.
> > * we still need some tests when building to ensure libvncserver and
> > libsvg are installed. As the current behaviour when they're not is
> > confusing -- I think its better to refuse to build ioemu if they're
> > not installed.
>
> Not all distributions are shipping libvncserver (for eg: FC4 didn't).
> Once we resolve that I think it's a reasonable thing to do.
Can we fail to support vnc gracefully at run time if the library isn't
present?
I'd rather still ensure that support was always built into the qemu-dm
binary by ensuring the header files are present.
Best,
Ian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home