Bug#366493: RandR support for vnc

2007-10-26 Thread Ola Lundqvist 
Thanks a lot!

Best regards,

// Ola

On Tue, Oct 23, 2007 at 12:09:05AM +0400, Nikita V. Youshchenko wrote:
 
  Hi,
 
  Unless I've missed something, the patch for bug 366493 has
  disappeared from the internet. It's not attached to the bug report,
  and I can't find evidence of it in the vnc-list mail archives. Could
  someone please post the patch to this bug report?
 
 I'm afraid that it never was on the internet - although I've sent it to 
 several interested people by request.
 
 Old version is attached.
 
 A few week ago, I fixed one more bug there (bad things hhappened if maximum 
 width was in one -geometry, and maximum height n another (e.g. -geometry 
 1280x1024 -geometry 1400x900). But it is difficult to me to create a patch 
 against debian xfree4-based vnc, since I've switched to xorg-based vnc 
 (manually built using hints from fedora package) to get RENDER support.
 So I'm attaching updated Xserver/hw/vnc/xvnc.cc file from my current 
 instead. To get patched xfree4-based xvnc tree, first apply attached patch 
 and then take InitInput() routine and #ifdef RANDR ... #endif block at the 
 bottom of vfbScreenInit() routine from attached file and put into 
 corresponding file of your tree.
 
 I've recently thought that I should package for debian what I'm currently 
 using as Xvnc server (it has several other patches as well). I started 
 with looking at current situation with upstread, and found sad situation 
 that both realvnc and tightvnc don't care much about their free versions. 
 The only open/free Xvnc implementation that has already switched to xorg 
 is xf4vnc project. So likely xf4vnc is *the* point where futher vnc 
 activity should happen. If I will ever get some time (which is next to 
 impossible), I will try to port all patches and switch to xf4vnc. And 
 maybe package it for Debian - if nobody will do that before me.
 
 Nikita






-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Annebergsslingan 37  \
|  [EMAIL PROTECTED] 654 65 KARLSTAD  |
|  http://opalsys.net/ +46 (0)70-332 1551   |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#366493: RandR support for vnc

2007-10-22 Thread Ola Lundqvist 
Hi

You are right. Luckily I have the patch from some other mail thread.

Attached.

Best regards,

// Ola

On Sun, Oct 21, 2007 at 08:12:38PM -0700, Duncan Findlay wrote:
 Hi,
 
 Unless I've missed something, the patch for bug   366493 has  
 disappeared from the internet. It's not attached to the bug report,  
 and I can't find evidence of it in the vnc-list mail archives. Could  
 someone please post the patch to this bug report?
 
 Thanks,
 Duncan
 
 
 
 

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Annebergsslingan 37  \
|  [EMAIL PROTECTED] 654 65 KARLSTAD  |
|  http://opalsys.net/ +46 (0)70-332 1551   |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---
diff -urN vnc4-4.1.1+X4.3.0/unix/xc/programs/Xserver/randr/randr.c vnc4-4.1.1+X4.3.0+RANDR/unix/xc/programs/Xserver/randr/randr.c
--- vnc4-4.1.1+X4.3.0/unix/xc/programs/Xserver/randr/randr.c	2003-02-08 06:52:30.0 +0300
+++ vnc4-4.1.1+X4.3.0+RANDR/unix/xc/programs/Xserver/randr/randr.c	2006-06-03 16:34:48.0 +0400
@@ -726,10 +726,31 @@
  * timestamp, then the config information isn't up-to-date and
  * can't even be validated
  */
+/* A DIRTY WORKAROUND.
+ * Looks like under some reasons, this test fails, although 32bit timestamp
+ * passed in stuff-configTimestamp is exactly the same as was returned
+ * in RRGetScreenInfo just before. So 'months' parts differ. Maybe
+ * some bug elsewhere, causing 'months' jump? Or maybe it could happen
+ * if enough time passed since previous configuration? I'm afraid that
+ * both have happened here ...
+ * Since I have no time to investigate details, I'm just replacing this
+ * with 32bit compare. Probability of config times that differ only
+ * in months is extremely low ... */
 if (CompareTimeStamps (configTime, pScrPriv-lastConfigTime) != 0)
 {
-	rep.status = RRSetConfigInvalidConfigTime;
-	goto sendReply;
+	if (pScrPriv-lastConfigTime.milliseconds == stuff-configTimestamp)
+	{
+	ErrorF(Point X: last: %lu %lu, new: %lu %lu\n,
+			pScrPriv-lastConfigTime.months,
+			pScrPriv-lastConfigTime.milliseconds,
+			configTime.months,
+			configTime.milliseconds);
+	}
+	else
+	{
+	rep.status = RRSetConfigInvalidConfigTime;
+	goto sendReply;
+	}
 }
 
 /*
diff -urN vnc4-4.1.1+X4.3.0/unix/xc/programs/Xserver/vnc/vncHooks.cc vnc4-4.1.1+X4.3.0+RANDR/unix/xc/programs/Xserver/vnc/vncHooks.cc
--- vnc4-4.1.1+X4.3.0/unix/xc/programs/Xserver/vnc/vncHooks.cc	2006-06-03 16:14:57.0 +0400
+++ vnc4-4.1.1+X4.3.0+RANDR/unix/xc/programs/Xserver/vnc/vncHooks.cc	2006-06-03 16:14:30.0 +0400
@@ -1530,3 +1530,11 @@
 
   vncHooksScreen-desktop-add_changed(changed.reg);
 }
+
+void vncHooksResizeScreen(ScreenPtr pScreen)
+{
+  vncHooksScreenPtr vncHooksScreen
+= ((vncHooksScreenPtr)pScreen-devPrivates[vncHooksScreenIndex].ptr);
+
+  vncHooksScreen-desktop-setSize(pScreen-width, pScreen-height);
+}
diff -urN vnc4-4.1.1+X4.3.0/unix/xc/programs/Xserver/vnc/XserverDesktop.cc vnc4-4.1.1+X4.3.0+RANDR/unix/xc/programs/Xserver/vnc/XserverDesktop.cc
--- vnc4-4.1.1+X4.3.0/unix/xc/programs/Xserver/vnc/XserverDesktop.cc	2005-03-11 18:08:41.0 +0300
+++ vnc4-4.1.1+X4.3.0+RANDR/unix/xc/programs/Xserver/vnc/XserverDesktop.cc	2006-06-03 16:14:30.0 +0400
@@ -193,6 +193,9 @@
   else
 data = new rdr::U8[pScreen-width * pScreen-height * (format.bpp/8)];
   colourmap = this;
+#ifdef RANDR
+  initialWidth = width_;
+#endif
 
   serverReset(pScreen);
 
@@ -714,7 +717,11 @@
   grabbing = true;
 
   int bytesPerPixel = format.bpp/8;
+#ifdef RANDR
+  int bytesPerRow = initialWidth * bytesPerPixel;
+#else
   int bytesPerRow = pScreen-width * bytesPerPixel;
+#endif
 
   std::vectorrfb::Rect rects;
   std::vectorrfb::Rect::iterator i;
diff -urN vnc4-4.1.1+X4.3.0/unix/xc/programs/Xserver/vnc/XserverDesktop.h vnc4-4.1.1+X4.3.0+RANDR/unix/xc/programs/Xserver/vnc/XserverDesktop.h
--- vnc4-4.1.1+X4.3.0/unix/xc/programs/Xserver/vnc/XserverDesktop.h	2005-03-11 18:08:41.0 +0300
+++ vnc4-4.1.1+X4.3.0+RANDR/unix/xc/programs/Xserver/vnc/XserverDesktop.h	2006-06-03 16:14:30.0 +0400
@@ -68,6 +68,12 @@
   void addClient(network::Socket* sock, bool reverse);
   void disconnectClients();
 
+#ifdef RANDR
+  void setSize(int w, int h) {
+width_ = w; height_ = h; server-setPixelBuffer(this);
+  }
+#endif
+  
   // QueryConnect methods called from X server code
   // getQueryTimeout()
   //   Returns the timeout associated with a particular
@@ -126,5 +132,9 @@
   void* queryConnectId;
   rfb::CharArray queryConnectAddress;
   rfb::CharArray queryConnectUsername;
+#ifdef RANDR
+  int initialWidth;
+  int getStride() const { return initialWidth; }
+#endif
 };
 #endif
diff -urN

Bug#366493: RandR support for vnc

2007-10-22 Thread Nikita V. Youshchenko 

 Hi,

 Unless I've missed something, the patch for bug   366493 has
 disappeared from the internet. It's not attached to the bug report,
 and I can't find evidence of it in the vnc-list mail archives. Could
 someone please post the patch to this bug report?

I'm afraid that it never was on the internet - although I've sent it to 
several interested people by request.

Old version is attached.

A few week ago, I fixed one more bug there (bad things hhappened if maximum 
width was in one -geometry, and maximum height n another (e.g. -geometry 
1280x1024 -geometry 1400x900). But it is difficult to me to create a patch 
against debian xfree4-based vnc, since I've switched to xorg-based vnc 
(manually built using hints from fedora package) to get RENDER support.
So I'm attaching updated Xserver/hw/vnc/xvnc.cc file from my current 
instead. To get patched xfree4-based xvnc tree, first apply attached patch 
and then take InitInput() routine and #ifdef RANDR ... #endif block at the 
bottom of vfbScreenInit() routine from attached file and put into 
corresponding file of your tree.

I've recently thought that I should package for debian what I'm currently 
using as Xvnc server (it has several other patches as well). I started 
with looking at current situation with upstread, and found sad situation 
that both realvnc and tightvnc don't care much about their free versions. 
The only open/free Xvnc implementation that has already switched to xorg 
is xf4vnc project. So likely xf4vnc is *the* point where futher vnc 
activity should happen. If I will ever get some time (which is next to 
impossible), I will try to port all patches and switch to xf4vnc. And 
maybe package it for Debian - if nobody will do that before me.

Nikita
diff -urN vnc4-4.1.1+X4.3.0/unix/xc/programs/Xserver/randr/randr.c vnc4-4.1.1+X4.3.0+RANDR/unix/xc/programs/Xserver/randr/randr.c
--- vnc4-4.1.1+X4.3.0/unix/xc/programs/Xserver/randr/randr.c	2003-02-08 06:52:30.0 +0300
+++ vnc4-4.1.1+X4.3.0+RANDR/unix/xc/programs/Xserver/randr/randr.c	2006-06-03 16:34:48.0 +0400
@@ -726,10 +726,31 @@
  * timestamp, then the config information isn't up-to-date and
  * can't even be validated
  */
+/* A DIRTY WORKAROUND.
+ * Looks like under some reasons, this test fails, although 32bit timestamp
+ * passed in stuff-configTimestamp is exactly the same as was returned
+ * in RRGetScreenInfo just before. So 'months' parts differ. Maybe
+ * some bug elsewhere, causing 'months' jump? Or maybe it could happen
+ * if enough time passed since previous configuration? I'm afraid that
+ * both have happened here ...
+ * Since I have no time to investigate details, I'm just replacing this
+ * with 32bit compare. Probability of config times that differ only
+ * in months is extremely low ... */
 if (CompareTimeStamps (configTime, pScrPriv-lastConfigTime) != 0)
 {
-	rep.status = RRSetConfigInvalidConfigTime;
-	goto sendReply;
+	if (pScrPriv-lastConfigTime.milliseconds == stuff-configTimestamp)
+	{
+	ErrorF(Point X: last: %lu %lu, new: %lu %lu\n,
+			pScrPriv-lastConfigTime.months,
+			pScrPriv-lastConfigTime.milliseconds,
+			configTime.months,
+			configTime.milliseconds);
+	}
+	else
+	{
+	rep.status = RRSetConfigInvalidConfigTime;
+	goto sendReply;
+	}
 }
 
 /*
diff -urN vnc4-4.1.1+X4.3.0/unix/xc/programs/Xserver/vnc/vncHooks.cc vnc4-4.1.1+X4.3.0+RANDR/unix/xc/programs/Xserver/vnc/vncHooks.cc
--- vnc4-4.1.1+X4.3.0/unix/xc/programs/Xserver/vnc/vncHooks.cc	2006-06-03 16:14:57.0 +0400
+++ vnc4-4.1.1+X4.3.0+RANDR/unix/xc/programs/Xserver/vnc/vncHooks.cc	2006-06-03 16:14:30.0 +0400
@@ -1530,3 +1530,11 @@
 
   vncHooksScreen-desktop-add_changed(changed.reg);
 }
+
+void vncHooksResizeScreen(ScreenPtr pScreen)
+{
+  vncHooksScreenPtr vncHooksScreen
+= ((vncHooksScreenPtr)pScreen-devPrivates[vncHooksScreenIndex].ptr);
+
+  vncHooksScreen-desktop-setSize(pScreen-width, pScreen-height);
+}
diff -urN vnc4-4.1.1+X4.3.0/unix/xc/programs/Xserver/vnc/XserverDesktop.cc vnc4-4.1.1+X4.3.0+RANDR/unix/xc/programs/Xserver/vnc/XserverDesktop.cc
--- vnc4-4.1.1+X4.3.0/unix/xc/programs/Xserver/vnc/XserverDesktop.cc	2005-03-11 18:08:41.0 +0300
+++ vnc4-4.1.1+X4.3.0+RANDR/unix/xc/programs/Xserver/vnc/XserverDesktop.cc	2006-06-03 16:14:30.0 +0400
@@ -193,6 +193,9 @@
   else
 data = new rdr::U8[pScreen-width * pScreen-height * (format.bpp/8)];
   colourmap = this;
+#ifdef RANDR
+  initialWidth = width_;
+#endif
 
   serverReset(pScreen);
 
@@ -714,7 +717,11 @@
   grabbing = true;
 
   int bytesPerPixel = format.bpp/8;
+#ifdef RANDR
+  int bytesPerRow = initialWidth * bytesPerPixel;
+#else
   int bytesPerRow = pScreen-width * bytesPerPixel;
+#endif
 
   std::vectorrfb::Rect rects;
   std::vectorrfb::Rect::iterator i;
diff -urN vnc4-4.1.1+X4.3.0/unix/xc/programs/Xserver/vnc/XserverDesktop.h

Bug#366493: RandR support for vnc

2007-10-21 Thread Duncan Findlay 

Hi,

Unless I've missed something, the patch for bug 	366493 has  
disappeared from the internet. It's not attached to the bug report,  
and I can't find evidence of it in the vnc-list mail archives. Could  
someone please post the patch to this bug report?


Thanks,
Duncan




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]