Implementing RandR

[George Wright-10]

Hello,

I'm currently working on implementing RandR support in the Xvnc server along
with an extension protocol for the client to request that Xvnc changes its
framebuffer size on demand.

I seem to have most things working, and Xvnc can resize itself without any
trouble. Running RandR-aware applications inside Xvnc even adjust themselves
properly when the screen resolution is changed.

However, the xrandr command still reports the old screen resolution after the
change, but the new resolution is present on the list of available ones.

So for example, if I start Xvnc with a 1600x1200 framebuffer, then resize it
to 1280x960, it resizes fine, and apps inside it adjust themselves properly.
xrandr before the adjust shows only 1600x1200 as the available screen
geometry, and afterwards shows 1280x960 as a possibility. However, it still
lists 1600x1200 as the "current" screen resolution.

Is there any way of fixing this?

Regards,

George

--
George Wright, http://www.gwright.org.uk


_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Rémi Cardona-3]

George Wright a écrit :
> Hello,
>
> I'm currently working on implementing RandR support in the Xvnc server along
> with an extension protocol for the client to request that Xvnc changes its
> framebuffer size on demand.

Hi George,

I'd be interested in doing the same thing for Xmetisse, which is based
on the old Xvnc code. Do you have a git tree somewhere with your patches?

I was also actually planning on adding RandR support to Xvfb for Gentoo
as an easier project to start with.

Cheers

--
Rémi Cardona
LRI, INRIA
remi.cardona@...
remi@...
_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[George Wright-10]

On Wednesday 17 September 2008 09:06:52 Rémi Cardona wrote:
> I'd be interested in doing the same thing for Xmetisse, which is based
> on the old Xvnc code. Do you have a git tree somewhere with your patches?

Unfortunately not yet. I don't think my work is currently in a 'release-ready'
state, even for development. I'm currently working against the Xvnc
1.5-xserver branch, which is rebased to current Xorg 7.4 release candidate
(and so I'm using Xserver version 1.5.0 snapshot).

> I was also actually planning on adding RandR support to Xvfb for Gentoo
> as an easier project to start with.

I started out by finding that someone had already implemented RandR in an
earlier version of Xvnc then I forward ported it to the current branch. I've
now implemented an RFB extension protocol that allows the client to request a
resolution change on the fly, which seems to work fine but results in the
problem I originally posted about in this thread.

The patch for Xvnc 4 is available from
http://yoush.homelinux.org:8079/nikita/vnc-xrandr/xvnc4-randr-patch-20060603

Regards,

George

--
George Wright, http://www.gwright.org.uk


_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[Jacob Welsh]

George Wright wrote:
> Hello,
>
> I'm currently working on implementing RandR support in the Xvnc server along
> with an extension protocol for the client to request that Xvnc changes its
> framebuffer size on demand.

What version of RandR are you aiming to support? I don't know if you
know enough about X and VNC -- I certainly don't -- to implement RandR
1.2 support, but that would be really nifty.

I'm imagining that multiple rfb clients connecting to a single Xvnc
could be registered as separate monitors, with their own modes as
determined by the client. Monitors and modes can be added and removed
dynamically via the existing XRandR 1.2 extension. And you could switch
between traditional "clone" mode and Xinerama-style with "xrandr" or a
1.2-capable GUI. So basically you could turn two neighboring thin
clients into a "dual-head" setup effortlessly. Also it would presumably
solve your present mode weirdness problem.

I'm sure that's a lot more work than you set out to do... and even RandR
1.1 support in tightvnc will be much appreciated :)

--Jacob
_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg

[George Wright-10]

On Thursday 18 September 2008 06:41:51 Jacob Welsh wrote:
> > I'm currently working on implementing RandR support in the Xvnc server
> > along with an extension protocol for the client to request that Xvnc
> > changes its framebuffer size on demand.
>
> What version of RandR are you aiming to support? I don't know if you
> know enough about X and VNC -- I certainly don't -- to implement RandR
> 1.2 support, but that would be really nifty.

I'm only working on having VNC sessions that can be resized for the moment. I
don't know enough about RandR to implement anything else. Rotations are all
hardcoded at the moment to use a 0 degree rotation (ie - normal) as we don't
see much point in implementing rotations. Depth switching can already be done
as part of the RFB protocol, so the only other thing in RandR that seems to
make sense is multi-head support.

> I'm imagining that multiple rfb clients connecting to a single Xvnc
> could be registered as separate monitors, with their own modes as
> determined by the client. Monitors and modes can be added and removed
> dynamically via the existing XRandR 1.2 extension. And you could switch
> between traditional "clone" mode and Xinerama-style with "xrandr" or a
> 1.2-capable GUI. So basically you could turn two neighboring thin
> clients into a "dual-head" setup effortlessly. Also it would presumably
> solve your present mode weirdness problem.

That sounds like an incredibly complex and insane project. I pity anyone who
tries to implement that ;)

> I'm sure that's a lot more work than you set out to do... and even RandR
> 1.1 support in tightvnc will be much appreciated :)

Thanks. I'm most of the way there now. The only problems I've got now are the
one I detailed at the start of this thread, and that resizing to a desktop
larger than the initial VNC desktop results in a segfault. I'm pretty sure
it's because of a memory allocation problem (I don't think the framebuffer is
reallocated when it's resized).

Today I'm working on getting vncviewer's window to be resizable and to send a
RFB request to the server to resize the framebuffer when it does so. I've
implemented a new extension to the RFB protocol to allow the client to
request desktop resizes.

I hope to release my initial patches early next week, so I'll keep you in the
loop if you want.

Regards,

George

--
George Wright, http://www.gwright.org.uk


_______________________________________________
xorg mailing list
xorg@...
http://lists.freedesktop.org/mailman/listinfo/xorg