Re: USER/GDI Objects leak with (XWin.exe) Cygwin/X X Server Verion 1.7.6, Build Date 2010-03-18
On 06/04/2010 20:05, Amal Khailtash wrote: Click on Session menu and while the menu is open, move to Edit, then View, Bookmarks, Settings and Help and click outside to withdraw menu: Image NameUser ObjectsGDI Objects XWin.exe39 79 Click on any menu item and while the menu is open and move cursor to other menu items a number of (20) times: Image NameUser ObjectsGDI Objects XWin.exe241 483 Keep doing this and you will see the allocated objects keeps increasing and increasing and they are never released even if I close my Konsole window! Thanks for the clear reproduction steps. With these, I can reproduce this problem. According to the GdiUsage tool this seems to be a GDI bitmap handle being leaked. Unfortunately GdiUsage seems to have rusted a bit and doesn't produce useful backtraces (and may well not be able to backtrace a cygwin executable, anyhow) so locating exactly where the leak is coming from is going to be a bit tricky... The one thing I notice is that other applications with menus don't seem to show this problem. The konsole I was testing with is relatively recent and has menus with rounded corners, I wonder if that is somehow related to the problem? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Multimedia keys interpreted as alphabetic keys
On 14/04/2010 15:37, Chris Bird wrote:
I wonder if anyone could shed some light on this minor problem I have:
I'm using Cygwin/X as my X client for several linux boxes at work.
Everything's working fine (after some tweaking), but there is one small
thing I find very annoying:
The multimedia keys on my keyboard generate keypresses as though they
were normal keys. Specifically, Play/Pause generates a 'g', volume up
generates 'c', volume down generates 'b', and mute generates 'd'. The
keyboard is a logitech Internet 350. As I listen to music all day to
keep my sanity, and occasionally need to alter the volume or stop or
mute the track to join in a conversation in the office (or stop driving
other people mad with my relentless beats!), I often find these
keypresses being entered into whatever program I'm working on. Not ideal.
I used xev to find out what keycodes were being generated by these keys,
and by the keys the output would suggest is being pressed, ie. g, c, b,
and d, expecting to find different keycodes perhaps being mapped to the
same keysyms, so I could alter .Xmodmap to assign them to XF86Play, etc.
But I found that they were exactly the same, as if Cygwin was
interpreting them as the same keys at some very basic level, whereas
Windows can tell the difference between pressing g (outputs a 'g') and
pressing Play/Pause (it plays or pauses the current track in my media
player). Here is the output from xev when pressing Play/Pause, then g:
[snip]
They both output 'keycode 42 (keysym 0x67, g)'. I tried various settings
in the arguments to XWin, to try to enable multimedia keys, and set the
model of my keyboard and layout correctly:
%RUN% XWin -multiwindow -clipboard -silent-dup-error -xkbmodel
logitech_base
REM -xkbvariant extd
REM -xkbmodel logii350
REM -xkblayout gb
but none of these made any positive difference, in fact one of them (I
can't remember which), actually disabled some other keys (e.g. the arrow
keys).
This behaviour doesn't happen in non-X Cygwin. I tried using Xming get
some ideas as suggested in this similar-looking post
http://sourceware.org/ml/cygwin-xfree/2004-12/msg00249.html
('Xming.exe :1 -multiwindow -logverbose 10'), and got no useful messages
about the keyboard.
Has anyone got a clue what's going on? Hope someone can help.
Thanks for the clear problem report.
After doing a bit of testing, the issue here seems to be that XWin doesn't
know to generate the correct X keycodes for these multimedia keys, so this is
a bug in XWin, not a problem with the XKB layout selected.
I've added some some entries to the table which translates Windows Virtual
Keycodes into X keycodes which hopefully fixes this.
Perhaps you could try out the test build I have uploaded at [1] and see if
that resolves this problem for you?
I've also turned on a bit more debug, so even if this doesn't work correctly,
-logverbose should indicate a bit more clearly what's going on...
[1] ftp://cygwin.com/pub/cygwinx/XWin.20100418-git-9594fb420a063608.exe.bz2
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
[PATCH 1/3] Cygwin/X: Generate X keycodes for multimedia keys
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
hw/xwin/winkeybd.h| 14 +++---
hw/xwin/winkeynames.h | 13 +
2 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/hw/xwin/winkeybd.h b/hw/xwin/winkeybd.h
index 5b2a589..662392b 100644
--- a/hw/xwin/winkeybd.h
+++ b/hw/xwin/winkeybd.h
@@ -216,13 +216,13 @@ g_iKeyMap [] = {
/* 170 */0, 0, 0,
/* 171 */0, 0, 0,
/* 172 */0, 0, 0,
- /* 173 */0, 0, 0,
- /* 174 */0, 0, 0,
- /* 175 */0, 0, 0,
- /* 176 */0, 0, 0,
- /* 177 */0, 0, 0,
- /* 178 */0, 0, 0,
- /* 179 */0, 0, 0,
+ /* 173 */VK_VOLUME_MUTE, 0, KEY_Mute,
+ /* 174 */VK_VOLUME_DOWN, 0, KEY_AudioLower,
+ /* 175 */VK_VOLUME_UP, 0, KEY_AudioRaise,
+ /* 176 */VK_MEDIA_NEXT_TRACK,0, KEY_NEXTSONG,
+ /* 177 */VK_MEDIA_PREV_TRACK,0, KEY_PREVIOUSSONG,
+ /* 178 */VK_MEDIA_STOP, 0, KEY_STOPCD,
+ /* 179 */VK_MEDIA_PLAY_PAUSE,0, KEY_PLAYPAUSE,
/* 180 */0, 0, 0,
/* 181 */0, 0, 0,
/* 182 */0, 0, 0,
diff --git a/hw/xwin/winkeynames.h b/hw/xwin/winkeynames.h
index 7c16337..5a3129f 100644
--- a/hw/xwin/winkeynames.h
+++ b/hw/xwin/winkeynames.h
@@ -23,10 +23,6 @@
*
*/
-#define XK_TECHNICAL
-#defineXK_KATAKANA
-#include X11/keysym.h
-
#define GLYPHS_PER_KEY 4
#define NUM_KEYCODES 248
#define MIN_KEYCODE 8
@@ -195,6 +191,15 @@
#define KEY_HKTG /* Hirugana/Katakana tog 0xc8 */ 200
#define KEY_BSlash2 /* \ _ 0xcb */ 203
+#define KEY_Mute /* Audio Mute */ 152
+#define KEY_AudioLower /* Audio Lower */ 168
+#define KEY_AudioRaise /* Audio Raise */ 166
+
+#define KEY_NEXTSONG /* Media next */ 145
+#define KEY_PLAYPAUSE/* Media play/pause toggle */ 154
+#define KEY_PREVIOUSSONG /* Media previous */ 136
+#define KEY_STOPCD /* Media stop */ 156
+
/* These are for notused and unknown entries in translation maps. */
#define KEY_NOTUSED 0
#define KEY_UNKNOWN255
--
1.7.0.4
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
[PATCH 2/3] Cygwin/X: Generate X keycodes for a few 'internet' keys
Add a few more special keys I have on my keyboard: mail, search, browser
These are normally trapped by Windows, so -keyhook needs to be taught
how to catch them as well
---
hw/xwin/winkeybd.h|6 +++---
hw/xwin/winkeyhook.c | 12 +++-
hw/xwin/winkeynames.h |4
3 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/hw/xwin/winkeybd.h b/hw/xwin/winkeybd.h
index 662392b..2784673 100644
--- a/hw/xwin/winkeybd.h
+++ b/hw/xwin/winkeybd.h
@@ -213,9 +213,9 @@ g_iKeyMap [] = {
/* 167 */0, 0, 0,
/* 168 */0, 0, 0,
/* 169 */0, 0, 0,
- /* 170 */0, 0, 0,
+ /* 170 */VK_BROWSER_SEARCH,KEY_SEARCH, 0,
/* 171 */0, 0, 0,
- /* 172 */0, 0, 0,
+ /* 172 */VK_BROWSER_HOME,KEY_BROWSER,0,
/* 173 */VK_VOLUME_MUTE, 0, KEY_Mute,
/* 174 */VK_VOLUME_DOWN, 0, KEY_AudioLower,
/* 175 */VK_VOLUME_UP, 0, KEY_AudioRaise,
@@ -223,7 +223,7 @@ g_iKeyMap [] = {
/* 177 */VK_MEDIA_PREV_TRACK,0, KEY_PREVIOUSSONG,
/* 178 */VK_MEDIA_STOP, 0, KEY_STOPCD,
/* 179 */VK_MEDIA_PLAY_PAUSE,0, KEY_PLAYPAUSE,
- /* 180 */0, 0, 0,
+ /* 180 */VK_LAUNCH_MAIL, KEY_MAIL, 0,
/* 181 */0, 0, 0,
/* 182 */0, 0, 0,
/* 183 */0, 0, 0,
diff --git a/hw/xwin/winkeyhook.c b/hw/xwin/winkeyhook.c
index 2d6ed18..0c2e65b 100755
--- a/hw/xwin/winkeyhook.c
+++ b/hw/xwin/winkeyhook.c
@@ -101,11 +101,13 @@ winKeyboardMessageHookLL (int iCode, WPARAM wParam,
LPARAM lParam)
switch (wParam)
{
case WM_KEYDOWN: case WM_SYSKEYDOWN:
- case WM_KEYUP:case WM_SYSKEYUP:
- fPassKeystroke =
- (fPassAltTab
-(p-vkCode == VK_TAB) ((p-flags LLKHF_ALTDOWN) != 0))
- || (p-vkCode == VK_LWIN) || (p-vkCode == VK_RWIN)
+ case WM_KEYUP:case WM_SYSKEYUP:
+ fPassKeystroke =
+ (fPassAltTab
+ (p-vkCode == VK_TAB) ((p-flags LLKHF_ALTDOWN) != 0))
+|| (p-vkCode == VK_LWIN) || (p-vkCode == VK_RWIN)
+|| (p-vkCode == VK_BROWSER_SEARCH) || (p-vkCode ==
VK_BROWSER_HOME)
+|| (p-vkCode == VK_LAUNCH_MAIL)
;
break;
}
diff --git a/hw/xwin/winkeynames.h b/hw/xwin/winkeynames.h
index 5a3129f..2f45ce6 100644
--- a/hw/xwin/winkeynames.h
+++ b/hw/xwin/winkeynames.h
@@ -200,6 +200,10 @@
#define KEY_PREVIOUSSONG /* Media previous */ 136
#define KEY_STOPCD /* Media stop */ 156
+#define KEY_SEARCH /* Search */ 221
+#define KEY_MAIL /* Mail*/ 228
+#define KEY_BROWSER /* Browser */ 170
+
/* These are for notused and unknown entries in translation maps. */
#define KEY_NOTUSED 0
#define KEY_UNKNOWN255
--
1.7.0.4
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
[PATCH 3/3] Cygwin/X: Better keyboard debugging output
---
hw/xwin/winkeybd.c |8
hw/xwin/winkeyhook.c |4 +---
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/hw/xwin/winkeybd.c b/hw/xwin/winkeybd.c
index ad9e66a..860e356 100644
--- a/hw/xwin/winkeybd.c
+++ b/hw/xwin/winkeybd.c
@@ -73,6 +73,8 @@ winTranslateKey (WPARAM wParam, LPARAM lParam, int
*piScanCode)
int iParam = HIWORD (lParam);
int iParamScanCode = LOBYTE (iParam);
+ winDebug(winTranslateKey: wParam %08x lParam %08x\n, wParam, lParam);
+
/* WM_ key messages faked by Vista speech recognition (WSR) don't have a
* scan code.
*
@@ -488,10 +490,8 @@ winSendKeyEvent (DWORD dwKey, Bool fDown)
for (i = 0; i nevents; i++)
mieqEnqueue(g_pwinKeyboard, events[i].event);
-#if CYGDEBUG
- ErrorF(winSendKeyEvent: dwKey: %d, fDown: %d, nEvents %d\n,
- dwKey, fDown, nevents);
-#endif
+ winDebug(winSendKeyEvent: dwKey: %d, fDown: %d, nEvents %d\n,
+ dwKey, fDown, nevents);
}
BOOL winCheckKeyPressed(WPARAM wParam, LPARAM lParam)
diff --git a/hw/xwin/winkeyhook.c b/hw/xwin/winkeyhook.c
index 0c2e65b..5314684 100755
--- a/hw/xwin/winkeyhook.c
+++ b/hw/xwin/winkeyhook.c
@@ -94,9 +94,7 @@ winKeyboardMessageHookLL (int iCode, WPARAM wParam, LPARAM
lParam)
/* Pass keystrokes on to our main message loop */
if (iCode == HC_ACTION)
{
-#if 0
- ErrorF (vkCode: %08x\tscanCode: %08x\n, p-vkCode, p-scanCode);
-#endif
+ winDebug(winKeyboardMessageHook: vkCode: %08x scanCode: %08x\n,
p-vkCode, p-scanCode);
switch (wParam)
{
--
1.7.0.4
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: Multimedia keys interpreted as alphabetic keys
On 20/04/2010 12:21, Chris Bird wrote: Thanks very much for getting back to me so soon. That seems to have fixed the problem, and I will use this version until it's in the main build, thanks. Thanks very much for testing the fix. There are a couple of side effects: 1) XWin dies immediately after outputting a message on startup if I pass it both -multiwindow and -logverbose - either in combination with other parameters seems to be fine. I have included output into XWin.0.log in this instance below. A numeric verbosity level is mandatory after -logverbose, as the usage info should make clear, so the command line below is invalid. -logverbose verbosity Set the verbosity of log messages. [NOTE: Only a few messages respect the settings yet] 0 - only print fatal error. 1 - print additional configuration information. 2 - print additional runtime information [default]. 3 - print debugging and tracing information. If you can construct a command line using -logverbose without a numeric verbosity level which is accepted, this is another bug in XWin. 2) When I ssh to another machine and start the Kate text editor, the fonts of the menus and the file being edited are larger than usual (ie. larger than when I use it with my old version of XWin). I restarted the old XWin and did the same and they were back to normal size. I'm not sure where to look for useful logging information on this. This is expected, as the build I provided is based on the xorg-server 1.8.0-1 test release [1], which includes a change for the default DPI value used by the X server from 75 to the value reported by Windows (usually 96) You can override the dpi value using the '-dpi' command line option. [1] http://cygwin.com/ml/cygwin-xfree-announce/2010-04/msg0.html XWin.0.log starting with with %RUN% XWin.20100418-git-9594fb420a063608.exe -multiwindow -clipboard -silent-dup-error -xkblayout gb -logverbose--- Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.8.0.0 (1080) Snapshot: 20100418-git-9594fb420a063608 Contact: cygwin-xfree@cygwin.com XWin was started with the following command line: /usr/bin/XWin.20100418-git-9594fb420a063608 -multiwindow -clipboard -silent-dup-error -xkblayout gb -logverbose ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - primary monitor w 2560 h 1024 winInitializeDefaultScreens - native DPI x 96 y 96 winInitializeDefaultScreens - Returning use: X [:display] [option] [displays usage info] -- -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Updated: xorg-server-1.8.0-1 (TEST)
On 28/04/2010 00:57, Jim Reisert AD1C wrote: It has been over three weeks. What is the status of this release? There's been no feedback, good or bad. This probably means no-one has tried it :-) Anyhow, thanks for the reminder, and since no major regressions have been reported, I've promoted 1.8.0-1 from test to latest. Thanks - Jim On Fri, Apr 2, 2010 at 2:25 PM, Yaakov (Cygwin/X) yselkow...@users.sourceforge.net wrote: The following package has been updated for Cygwin 1.7: * xorg-server-1.8.0-1 (TEST) This package contains XWin and the other X.Org X11 servers. This is the first official release of the xserver 1.8 series. It is currently available as a test release, and will be made stable in approximately 10 days if no major regressions are reported. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Font change in Gnu emacs/X11 following upgrade
On 29/04/2010 19:05, Ken Brown wrote: [This should have gone to the cygwin-xfree list. I've set the reply-to accordingly.] On 4/29/2010 1:55 PM, Marc Girod wrote: Hello, I just upgraded for the first time for a few months. Starting my Gnu emacs under X11, I notice that my font (and frames) is larger than previously, by a factor ~1.5. http://old.nabble.com/file/p28403800/cygcheck.100429 cygcheck.100429 This is a result of the change in the default server DPI announced in http://cygwin.com/ml/cygwin-xfree-announce/2010-04/msg0.html You can set the X server dpi back to 75 dpi by adding the option '-dpi 75' to the command used to start the X server. Or since the the default value is now inherited from Windows, you can use the Windows control panel display applet to set the system dpi to 75, if you want consistently tiny fonts on across all applications :-) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Slow response to keypresses in xorg-server-1.8.0-1
On 02/05/2010 21:52, Ken Brown wrote: On 5/1/2010 9:49 AM, Ken Brown wrote: I'm often seeing a very slow response to keypresses under xorg-server-1.8.0-1. The problem is intermittent, but it always happens within a few minutes after starting the server (via the start menu shortcut or a slight variant). Here are some examples: 1. Switching windows with Alt-Tab sometimes takes up to 15 seconds or doesn't work at all (i.e., I get tired of waiting to see if the focus is ever going to switch). 2. When using 'less' to view a file in an xterm window, there is sometimes a delayed response to 'space' or 'q'. 3. When viewing a directory in emacs-X11, pressing 'v' to start viewing a file can sometimes result in a long delay, pressing 'space' to scroll in view mode can be slow, and pressing 'q' to exit view mode can be slow. In some of these cases, I sometimes don't get a response to the first keypress until I press a second key. For example, if I'm viewing a file with 'less', I may press 'q' and get no response. Then pressing 'q' a second time exits 'less' and also produces an echoed 'q' in xterm. Similarly, I'll sometimes press a key, see no echo, and then get two characters echoed at once after pressing a second key. Reverting to xorg-server-1.7.6-2 solves the problem. I'm attaching cygcheck output and an XWin log. I found a test case that I can reproduce reliably on my system. 1. With no .Xdefaults or .startxwinrc, start the X server via the start menu shortcut. 2. Start xfig (with 'xfig ' in the xterm window). 3. Repeatedly press Alt-Tab to switch between the xterm and xfig windows. At some point the focus fails to switch. When this happens, press Alt and the focus switches. Thanks for the clear reproduction steps. And thanks to the other reporters of this problem :-) This is fallout from a change [1] to the way we process Windows messages to handle large bursts of them overflowing the Xserver's internal event queue. It seems that sometimes /dev/windows doesn't seem ready to select() even when there is still Windows messages to process. I can't quite understand how this happens. I don't think this is a bug in cygwin, but probably something subtle to do with message ordering and nonqueued messages (like WM_ACTIVATE). Anyhow, I've cooked up a small additional change which should prevent this blocking behaviour and uploaded a build [2]. It seems to resolve the problem in this specific case. Perhaps you could try it out and see if it helps? [1] http://cygwin.com/ml/cygwin-xfree/2010-02/msg00124.html [2] ftp://cygwin.com/pub/cygwinx/XWin.20100630-git-bc2f74e105146c36.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Problem when trying to use -nolock Option
On 29/06/2010 17:13, Mathias Friesenbichler wrote: Hi, I posted this Problem 2 Weeks ago and no one answered yet. Is there anyone who can help me? Yourself, first of all. Try reading the 'Xserver' man page. Thanks, Mathias Original-Nachricht Datum: Thu, 17 Jun 2010 08:24:03 +0200 Von: Mathias Friesenbichlerhia...@gmx.at An: cygwin-xfree@cygwin.com Betreff: Problem when trying to use -nolock Option Hi, My CygwinX is installed on a server. Several users are accessing this installation and therefore i want to use the -nolock option. No. If several users are running X servers on the same computer at the same time, they need to each use a unique display number. '-nolock' is only useful if /tmp resides on a FAT filesystem, which doesn't support the semantics needed by lockfiles, or if a stale lockfile has been left behind by a crashed XWin which you don't have rights to remove. Although i have added this option, cygwinx creates the X1 File in tmp/.X11-unix. So no other user can access cygwin while it is open. The logbook output is then: Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.8.0.0 (1080) Build Date: 2010-04-02 Contact: cygwin-xfree@cygwin.com XWin was started with the following command line: /usr/bin/Xwin :1 -ac -query 10.8.248.101 -clipboard -logfile C:\DOKUME~1\fltplehr\LOKALE~1\Temp\xwin.fltplehr.1.log -nolock -dpi 75 ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - primary monitor w 1280 h 1024 winInitializeDefaultScreens - native DPI x 96 y 96 winInitializeDefaultScreens - Returning [1061722.984] _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 [1061722.984] _XSERVTransOpen: transport open failed for inet6/pc08309:1 [1061722.984] _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 [1061723.015] _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed [1061723.015] _XSERVTransMakeAllCOTSServerListeners: server already running [1061723.015] Fatal server error: [1061723.015] Cannot establish any listening sockets - Make sure an X server isn't already running I am starting the program with the following code: start O:\PLS_Faser\Cygwin_PLSStarter\cygwin_installed\bin\Xwin.exe :1 -ac -query IP -clipboard -logfile %TEMP%\xwin.%USERNAME%.1.log -nolock -dpi 75 Can you help me? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[PATCH] Update mapping for Canadian keyboard layouts
0x0c0c Canadian French (legacy) = layout ca variant fr-legacy
0x1009 Canadian French = layout ca variant fr
0x00011009 Canadian Multilingual Standard = layout ca variant multix
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
hw/xwin/winlayouts.h | 192 ++
1 files changed, 6 insertions(+), 186 deletions(-)
diff --git a/hw/xwin/winlayouts.h b/hw/xwin/winlayouts.h
index d1d21a1..724465f 100644
--- a/hw/xwin/winlayouts.h
+++ b/hw/xwin/winlayouts.h
@@ -55,13 +55,15 @@ WinKBLayoutRec winKBLayouts[] =
{0x10409, -1, pc105, dvorak, NULL, NULL, English (USA, Dvorak)},
{0x20409, -1, pc105, us_intl, NULL, NULL, English (USA,
International)},
{ 0x809, -1, pc105, gb, NULL, NULL, English (United Kingdom)},
+{ 0x1009, -1, pc105, ca, fr, NULL, French (Canada)},
+{0x11009, -1, pc105, ca, multix, NULL, Candian Multilingual
Standard},
{ 0x1809, -1, pc105, ie, NULL, NULL, Irish},
{ 0x40a, -1, pc105, es, NULL, NULL, Spanish (Spain, Traditional
Sort)},
{ 0x80a, -1, pc105, latam, NULL, NULL, Latin American},
{ 0x40b, -1, pc105, fi, NULL, NULL, Finnish},
{ 0x40c, -1, pc105, fr, NULL, NULL, French (Standard)},
{ 0x80c, -1, pc105, be, NULL, NULL, French (Belgian)},
-{ 0xc0c, -1, pc105, ca, fr, NULL, French (Canada)},
+{ 0xc0c, -1, pc105, ca, fr-legacy, NULL, French (Canada)
(Legacy)},
{ 0x100c, -1, pc105, ch, fr, NULL, French (Switzerland)},
{ 0x40d, -1, pc105, il, NULL, NULL, Hebrew},
{ 0x40e, -1, pc105, hu, NULL, NULL, Hungarian},
@@ -85,189 +87,7 @@ WinKBLayoutRec winKBLayouts[] =
{ -1, -1, NULL,NULL, NULL, NULL, NULL}
};
-/* Listing of language codes from MSDN */
/*
-Support ID XKBLanguage
-
- ?0x Language Neutral
- ?0x0400 Process or User Default Language
- ?0x0800 System Default Language
-0x0401 Arabic (Saudi Arabia)
-0x0801 Arabic (Iraq)
-0x0c01 Arabic (Egypt)
-0x1001 Arabic (Libya)
-0x1401 Arabic (Algeria)
-0x1801 Arabic (Morocco)
-0x1c01 Arabic (Tunisia)
-0x2001 Arabic (Oman)
-0x2401 Arabic (Yemen)
-0x2801 Arabic (Syria)
-0x2c01 Arabic (Jordan)
-0x3001 Arabic (Lebanon)
-0x3401 Arabic (Kuwait)
-0x3801 Arabic (U.A.E.)
-0x3c01 Arabic (Bahrain)
-0x4001 Arabic (Qatar)
-Arabic (102) AZERTY
-0x0402 Bulgarian
-0x0403 Catalan
-0x0404 Chinese (Taiwan)
-0x0804 Chinese (PRC)
-0x0c04 Chinese (Hong Kong SAR, PRC)
-0x1004 Chinese (Singapore)
-0x1404 Chinese (Macao SAR) (98/ME,2K/XP)
- X0x0405 cz Czech
- Xcz_qwerty Czech (QWERTY)
-Czech (Programmers)
- X0x0406 dk Danish
- X0x0407 de German (Standard)
- X0x0807 de_CH German (Switzerland)
-0x0c07 German (Austria)
-0x1007 German (Luxembourg)
-0x1407 German (Liechtenstein)
-0x0408 Greek
- X0x0409 us English (United States)
- X0x0809 gb English (United Kingdom)
-0x0c09 English (Australian)
-0x1009 English (Canadian)
-0x1409 English (New Zealand)
- X0x1809 ie English (Ireland)
-0x1c09 English (South Africa)
-0x2009 English (Jamaica)
-0x2409 English (Caribbean)
-0x2809 English (Belize)
-0x2c09 English (Trinidad)
-0x3009 English (Zimbabwe) (98/ME,2K/XP)
-0x3409 English (Philippines) (98/ME,2K/XP)
- X0x040a es Spanish (Spain, Traditional Sort)
-0x080a Spanish (Mexican)
-0x0c0a Spanish (Spain, Modern Sort)
-0x100a Spanish (Guatemala)
-0x140a Spanish (Costa Rica)
-0x180a Spanish (Panama)
-0x1c0a Spanish (Dominican Republic)
-0x200a Spanish (Venezuela)
-0x240a Spanish (Colombia)
-0x280a Spanish (Peru)
-0x2c0a Spanish (Argentina)
-0x300a Spanish (Ecuador)
-0x340a Spanish
Re: Problem when trying to use -nolock Option
On 01/07/2010 06:53, Mathias Friesenbichler wrote: Hi, Thanks for the reply. But you didn’t get my problem. We are several users running X servers over several computers, but starting the X from the same Installation on the network. I see. You didn't mention this before. I don't think that's a supported way of running cygwin. Things would probably work better if you set the mount table for each computer so it had /tmp mounted on a local disk, rather than having them all share one. So the local Computer doesn’t know anything about the other users and therefore we have written a program that manages this problem for us. This program gives each user a unique display number. The problem now is that if I use the “-nolock” option it does the same as if I don’t use it. It also creates those lockfiles. So what can I do to fix this? The /tmp/.X11-unix/Xn files are not lock files. They are unix domain sockets. You could avoid them being created by using '-nolisten unix', which probably avoids this specific problem. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Using the Canadian Multilingual Standard keyboard with Windows XP
On 03/06/2010 21:17, Young, George wrote: Using Windows XP and cygwin started with the command %RUN% XWin -multiwindow -clipboard -silent-dup-error -xkblayout ca -xkbvariant multix -xkbmodel pc104 If the Windows keyboard is set to US, cygwin works fine. If the Windows keyboard is set to Canadian Multilingual Standard, cygwin doesn't get the RightAlt and RightControl inputs. I couldn't reproduce this. Checking with xev, the right alt and right control keys generate key events when the Windows keyboard layout is Canadian Multilingual Standard, although it seems that right control generates the same X keysym as left control with that layout for some reason. Can you clarify how you are checking for the keypresses? Please attach your /var/log/XWin.0.log as well. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: fatal error
On 25/06/2010 10:12, Miroslav Iliaš wrote: /var/log/XWin.0.log attached [ 2936.391] (EE) XKB: Could not invoke xkbcomp [ 2936.391] (EE) XKB: Couldn't compile keymap [ 2936.391] XKB: Failed to compile keymap [ 2936.391] Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config. [ 2936.391] Fatal server error: [ 2936.391] Failed to activate core devices. Can you run /usr/bin/xkbcomp from bash? If no, your installation of xkbcomp is broken somehow. Try 'cycheck /usr/bin/xkbcomp'. If yes, you probably have some kind of BLODA [1] problem. [1] http://cygwin.com/faq/faq.using.html#faq.using.bloda -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Bug: XTerm scrollbar issue
On 12/07/2010 16:02, webmaster wrote: --enable-narrowproto That turns on a #define for NARROWPROTO which may be missing Changing subject to reflect that this is a bug with the Cygwin XTerm package. I confirmed that --enable-narrowproto resolves the issue by compiling the xterm-260-1 source package. My configure options were: configure --disable-imake --disable-narrowproto --prefix=/usr --target=i686-pc-cygwin --host=i686-pc-cygwin --build=i686-pc-cygwin Thanks for the clear problem report. For the avoidance of doubt, since you mention both alternatives in your email, we need to add --disable-narrowproto to build xterm with correctly working scrollbars on cygwin. I note that the list of platforms for which --enable-narrowproto is the default in xterm's aclocal.m4 CF_ENABLE_NARROWPROTO macro (which includes cygwin) doesn't match the list of platforms which default to narrow prototypes in xproto (which doesn't include cygwin). This makes me wonder if the cygwin platform default managed to get changed during modularization... I'm afraid I didn't quite understand the explanation as to why Xfuncproto.h might be wrong, so I'm wondering if any other X applications might also show this problem... In any case, I'll see if I can get xterm rebuilt with this configuration change. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Using the Canadian Multilingual Standard keyboard with WindowsXP
On 02/07/2010 14:27, Young, George wrote: With WIN XP keyboard set to Canadian Multilingual Standard: Run xev, press Right Alt [xev output snipped] Thanks. This helps a lot in understanding the problem. There seem to be two things going on here: 1) In the Canadian Multilingual Standard layout, Ctrl-R is VK_OEM_8 (rather than the more normal VK_CONTROL) which isn't in the mapping table to ignore the VK code and use the scan code. 2) Windows generates an additional Ctrl-L key event before AltGr key event for international keyboard layouts. There is code in the X server to try to identify and discard these extra events, but this doesn't seem to be working in your case (and there have been other reports of that) I don't see why we can't just always load the US keyboard layout as all we care about are scan codes: Patch to follow which adds a flag to do that and turn it on for Japanese (which already does that) and Canadian Multilingual Standard. I've also added a keycode mapping for VK_OEM_8 in case that ever fails, and improved some logging related to the keyboard layout detection. I've also added the multix layout to the list of autodetected layouts. I've uploaded a build with this patch applied [1]. This seems to correctly generate ISO_Level3_Shift for AltGr and ISO_Level5_Shift for Ctrl-R in the multix layout. Perhaps you could try it out and see if it works for you? Although I am still a bit unclear as to what exactly doesn't work for you. Originally you said If the Windows keyboard is set to Canadian Multilingual Standard, cygwin doesn't get the RightAlt and RightControl inputs, whereas this xev output seems to demonstrate that the X server gets events, just not the right ones :-) [1] ftp://cygwin.com/pub/cygwinx/XWin.20100713-git-c54fb06114a2c0f1.exe.bz2 -Original Message- On 03/06/2010 21:17, Young, George wrote: Using Windows XP and cygwin started with the command %RUN% XWin -multiwindow -clipboard -silent-dup-error -xkblayout ca -xkbvariant multix -xkbmodel pc104 If the Windows keyboard is set to US, cygwin works fine. If the Windows keyboard is set to Canadian Multilingual Standard, cygwin doesn't get the RightAlt and RightControl inputs. I couldn't reproduce this. Checking with xev, the right alt and right control keys generate key events when the Windows keyboard layout is Canadian Multilingual Standard, although it seems that right control generates the same X keysym as left control with that layout for some reason. Can you clarify how you are checking for the keypresses? Please attach your /var/log/XWin.0.log as well. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[PATCH] Fixes for Canadian Multilingual Standard keyboard layout handling
Try to make the keyboard detection logging a bit clearer
I don't see why we don't just always load the US keyboard layout as all we
care about are scan codes: So add a flag to do that and turn it on for
Japanese (which already does that) and new layouts...
Add a keycode mapping for VK_OEM_8 which can be issued by Canadian Multilingual
Standard layout
Reformat the keyboard layout mapping table
Clarify XKB options in XWin man page
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
hw/xwin/XWin.man.pre |8 ++--
hw/xwin/winconfig.c | 108 ++---
hw/xwin/winkeybd.c |4 ++
hw/xwin/winkeybd.h |2 +-
hw/xwin/winlayouts.h | 83 +++---
5 files changed, 117 insertions(+), 88 deletions(-)
diff --git a/hw/xwin/XWin.man.pre b/hw/xwin/XWin.man.pre
index 6b28b51..51268f6 100644
--- a/hw/xwin/XWin.man.pre
+++ b/hw/xwin/XWin.man.pre
@@ -251,7 +251,7 @@ exit silently and don't display any error message.
.B \-xkbrules \fIrule\fP
.TP 8
.B \-xkbvariant \fIvariant\fp
-These options implement the xkeyboard extension for loading
+These options configure the xkeyboard extension to load
a particular keyboard map as the X server starts. The behavior is similar
to the \fIsetxkbmap\fP program. The layout data is located at \fI
__datadir__/X11/xkb/\fP. Additional information is found in the
@@ -264,9 +264,9 @@ the options:
Alternatively one may use the \fIsetxkbmap\fP program after \fIXWin\fP is
running.
-The default is to select a layout matching your current layout as
-reported by \fIWindows\fP if known, or the default X server layout
-if no matching keyboard layout was found.
+The default is to select a configuration matching your current layout as
+reported by \fIWindows\fP, if known, or the default X server configuration
+if no matching keyboard configuration was found.
.SH UNDOCUMENTED OPTIONS
These options are undocumented. Do not use them.
diff --git a/hw/xwin/winconfig.c b/hw/xwin/winconfig.c
index b05867b..3dc8ac4 100644
--- a/hw/xwin/winconfig.c
+++ b/hw/xwin/winconfig.c
@@ -240,6 +240,7 @@ Bool
winConfigKeyboard (DeviceIntPtr pDevice)
{
char layoutName[KL_NAMELENGTH];
+ unsigned char layoutFriendlyName[256];
static unsigned int layoutNum = 0;
int keyboardType;
#ifdef XWIN_XF86CONFIG
@@ -291,19 +292,30 @@ winConfigKeyboard (DeviceIntPtr pDevice)
Same might apply for chinese, korean and other symbol languages
too */
layoutNum = (layoutNum 0x);
- if (keyboardType == 7)
- {
- /* Japanese layouts have problems with key event messages
- such as the lack of WM_KEYUP for Caps Lock key.
- Loading US layout fixes this problem. */
- if (LoadKeyboardLayout(0409, KLF_ACTIVATE) != NULL)
- winMsg (X_INFO, Loading US keyboard layout.\n);
- else
- winMsg (X_ERROR, LoadKeyboardLaout failed.\n);
- }
}
-winMsg (X_PROBED, winConfigKeyboard - Layout: \%s\ (%08x) \n,
-layoutName, layoutNum);
+
+/* Discover the friendly name of the current layout */
+{
+ HKEYregkey = NULL;
+ const char regtempl[] =
SYSTEM\\CurrentControlSet\\Control\\Keyboard Layouts\\;
+ char*regpath;
+ DWORD namesize = sizeof(layoutFriendlyName);
+
+ regpath = malloc(sizeof(regtempl) + KL_NAMELENGTH + 1);
+ strcpy(regpath, regtempl);
+ strcat(regpath, layoutName);
+
+ if (!RegOpenKey(HKEY_LOCAL_MACHINE, regpath, regkey))
+ RegQueryValueEx(regkey, Layout Text, 0, NULL, layoutFriendlyName,
namesize);
+
+ /* Close registry key */
+ if (regkey)
+RegCloseKey (regkey);
+ free(regpath);
+}
+
+winMsg (X_PROBED, Windows keyboard layout: \%s\ (%08x) \%s\, type
%d\n,
+layoutName, layoutNum, layoutFriendlyName, keyboardType);
for (pLayout = winKBLayouts; pLayout-winlayout != -1; pLayout++)
{
@@ -311,46 +323,58 @@ winConfigKeyboard (DeviceIntPtr pDevice)
continue;
if (pLayout-winkbtype 0 pLayout-winkbtype != keyboardType)
continue;
-
+
bfound = TRUE;
winMsg (X_PROBED,
- Using preset keyboard for \%s\ (%x), type \%d\\n,
- pLayout-layoutname, pLayout-winlayout, keyboardType);
-
+ Found matching XKB configuration \%s\\n,
+ pLayout-layoutname);
+
+winMsg(X_PROBED,
+ Model = \%s\ Layout = \%s\
+Variant = \%s\ Options = \%s\\n,
+ pLayout-xkbmodel ? pLayout-xkbmodel : none,
+ pLayout-xkblayout ? pLayout-xkblayout : none,
+ pLayout-xkbvariant ? pLayout-xkbvariant : none,
+ pLayout-xkboptions ? pLayout-xkboptions : none
Re: Bug or WAD? Midnight Commander F10 different in xterm than native or rxvt
On 09/07/2010 07:58, Marco Atzeri wrote: --- Ven 9/7/10, Larry Hall ha scritto: On 7/8/2010 10:35 PM, Peter Farley wrote: I don't know if this is the right place to ask this question, but if it is not please advise me where to send it. Midnight Commander exits with F10, and in a native bash window or rxvt F10 exits to the last directory viewed. In an xterm though, it exits to the original directory from which MC was started. on my Win-XP SP2 under cygwin/X MC with F10 exits in the current directory Peter, as mc is an alias alias mc='. /usr/share/mc/bin/mc-wrapper.sh' I guess that under X this wrapper is working differently than under console Perhaps more likely, the alias isn't setup by the shell init scripts under xterm because of the way the xterm was started (which the OP hasn't said) (but is being setup for cmd.exe or rxvt) Note that it's impossible for mc to change the current directory of the parent shell without this alias. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Resizing problem
On 15/07/2010 18:02, Olwe Melwasul wrote: I installed cygwin/xcygwin 1.7.5 with KDE. I don't know where you got KDE from, but it's not in the standard cygwin distribution. If you have problems with KDE, perhaps you should try the place you got it from. I tried clicking on XWin Server from the Start menue, but nothing happened. I tried startx from the cygwin basic terminal. Nothing. After some Google archaeology, I found someone that had done this: cd \cygwin\bin ash PATH=. rebaseall -v at the DOS command. Good. It worked. Running startx at the cygwin command did start a twm session. But how the KDE would run, I couldn't figure out from any amount of documentation or Googling. Given the rest of this email, I find it hard to believe that the documentation you read included 'man Xwin' or the Cygwin/X User Guide [1] If you did, and you found it unclear, I'd welcome your suggestions as to how to improve that documentation. After some more Googling, I saw a reference to an Openbox. Guessing along, I got startx /usr/bin/openbox to give me Openbox. My problem is that I cannot minimize anything because it goes down below and out of sight. Nope. What's happening here is that you have no panel/taskbar running, so there is nothing to show minimized applications. Openbox is just a Window Manager. The XWin container window is sized on start up to my right computer screen, but when I drag it over to my larger left screen, it can't be resized. from 'man XWin': The display mode can not be changed once the X server has started. We do not currently support resizing the X screen of a running X server. I suspect Openbox has a default size larger (lower?) and down in the hidden part is no doubt either a task bar with the minimized apps or the minimized apps themselves, right? Wrong, as explained above. Alt-Tab only cycles the Win7 apps, not the XWin session apps, BTW. This behaviour is by design. [2] If you want to allow the X server to capture alt-tab key presses, you should read about the -keyhook option in 'man XWin': -[no]keyhook: Enable [disable] a low-level keyboard hook for catching special keypresses like Menu and Alt+Tab and passing them to the X Server instead of letting Windows handle them. And indeed 'startx /usr/bin/openbox-session -- -keyhook' gives you an openbox session where you can switch windows using alt-tab. It's kind of unfortunate that the default configuration of openbox and the X server interact in this way to make it difficult to work out how to get your minimized applications back, and we could certainly do with some words in the User's Guide about using the WMs we provide, but that would best be written by someone who actually uses them, which isn't me :-) Actually, I don't need the startx version, I could very well use the startxwin multi-windows version IF I could get Emacs in shell mode to do cygwin bash. Starting the X server and then Emacs multi-windows style gets a shell mode that apparently doesn't see cygwin. I'm guessing it's using the DOS command. How can I a) get at the minimized apps? or b) how can I get a stand-alone X server-run Emacs to see cygwin bash? [1] http://x.cygwin.com/docs/ug/cygwin-x-ug.html [2] http://x.cygwin.com/docs/ug/using-switching.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Using the Canadian Multilingual Standard keyboard with WindowsXP
On 13/07/2010 20:30, Young, George wrote: I tried the patch and am very impressed. My WinXP was set up with English-Canada and 2 keyboards, Canadian Multilingual Standard and US. When I ran the cygwin patch, it added English-US with a US Keyboard, and switched to that. Thanks for trying it out. Hmm... this is a rather unfortunate side-effect of loading the US keyboard layout, and there doesn't seem to be a good way of preventing it appearing in the language bar. I think maybe I should try the alternate approach of handling VK_OEM_8 correctly and trying to work out why the code to discard the spurious Ctrl-L key events isn't always working (it works fine for me) I've uploaded another build at [1] which tries that, with lots of extra debugging built in. I wonder if you could check if Ctrl-R deadkeys work correctly with that, and also if you could provide me with the output of 'tail -f /var/log/XWin.0.log' and xev from pressing AltGr. In cygwin, the RightAlt and RightControl do what they're supposed to do (almost). There still seems to be a small problem with dead key stuff. When I first run the cygwin server, and press the keys for dead-cedilla (RtCtrl and =) then c, it just gives c. If I then run xev and stop it, the dead keys start to work and it gives ç. I'm afraid I can't reproduce this, I always get a ç, but I may not be doing the right thing. Can you give me some more detailed steps about how you are starting the Xserver, and the application you are typing into? [1] ftp://cygwin.com/pub/cygwinx/XWin.20100716-git-26e4d8f804b5cfdc.exe.bz2 Good stuff, George R. Young -Original Message- From: Jon TURNEY [mailto:jon.tur...@dronecode.org.uk] Sent: July 13, 2010 2:41 PM To: cygwin-xfree@cygwin.com Cc: Young, George Subject: Re: Using the Canadian Multilingual Standard keyboard with WindowsXP On 02/07/2010 14:27, Young, George wrote: With WIN XP keyboard set to Canadian Multilingual Standard: Run xev, press Right Alt [xev output snipped] Thanks. This helps a lot in understanding the problem. There seem to be two things going on here: 1) In the Canadian Multilingual Standard layout, Ctrl-R is VK_OEM_8 (rather than the more normal VK_CONTROL) which isn't in the mapping table to ignore the VK code and use the scan code. 2) Windows generates an additional Ctrl-L key event before AltGr key event for international keyboard layouts. There is code in the X server to try to identify and discard these extra events, but this doesn't seem to be working in your case (and there have been other reports of that) I don't see why we can't just always load the US keyboard layout as all we care about are scan codes: Patch to follow which adds a flag to do that and turn it on for Japanese (which already does that) and Canadian Multilingual Standard. I've also added a keycode mapping for VK_OEM_8 in case that ever fails, and improved some logging related to the keyboard layout detection. I've also added the multix layout to the list of autodetected layouts. I've uploaded a build with this patch applied [1]. This seems to correctly generate ISO_Level3_Shift for AltGr and ISO_Level5_Shift for Ctrl-R in the multix layout. Perhaps you could try it out and see if it works for you? Although I am still a bit unclear as to what exactly doesn't work for you. Originally you said If the Windows keyboard is set to Canadian Multilingual Standard, cygwin doesn't get the RightAlt and RightControl inputs, whereas this xev output seems to demonstrate that the X server gets events, just not the right ones :-) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: empty x windows
On 14/06/2010 20:37, J. Bruce Dean wrote: When running dual displays, using cygwin/x, the external monitor frames are 'invisible'. The window moves from the (laptop) display, working, on the external monitor they have a border, but the background is a snapshot of the app running on the external monitor. If I type, it works, but nothing displays. Moving the window moves the snapshot of the background. Moving back to the primary display I can see whatever I typed on the external monitor. Searching provided some things to try, such as the 'screens' and 'mulitplemonitors', neither worked. Another other thing I've recently come across which might cause this behaviour is if the 2 monitors have different colour depths. In that case, something does get written to XWin.0.log indicating that we will use the primary display only (effectively turning off -multiplemonitors), but I guess it could be clearer. Perhaps we should arrange to constrain the X windows to stay in the area of the virtual desktop for which the shadow framebuffer covers, to avoid windows which don't get their contents drawn like that. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Problems with display resize over RDP connections
On 29/04/2010 03:49, Raul Acevedo wrote: Didn't X figure out how to dynamically change its display resolution long time ago? (I remember the good old days when this really was fixed on server start up, and the only way to change it was to restart X.) Isn't there some way to tell the X server, even if it's via a command line utility, that the display has been reconfigured? Modern Linux desktops certainly let me do this. It's true that X can handle display resolution changes with the RANDR extension, but support needs to be present in the DDX layer as well, and currently the XWin DDX doesn't have this. I've been working on some changes to add this support, which seem to work ok and could use some wider testing. * Add RANDR extension support to XWin DDX. * In multiwindow or rootless mode handle the WM_DISPLAYCHANGE message sent when monitor resolution or number changes. Use RANDR to update the X screen size to the virtual desktop size (if -multiplemonitors was used) or to the monitor size (if -screen @monitor was used) * In rooted mode, a new option -resize is added to control resizing mode. When -resize=randr mode is selected, the native window containing the root window has a resizing frame and resizing the frame will use RANDR to change the size of the X screen. Likewise, RANDR changes of X screen size will update the size of the native window containing the root window. I've uploaded a build including these changes at [1]. Perhaps you could try it out and see if it works for you? Patches are rather large so they can be found at [2] [1] ftp://cygwin.com/pub/cygwinx/XWin.20100718-git-c8262c6457efa195.exe.bz2 [2] http://cgit.freedesktop.org/~jturney/xserver/log/?h=jturney-framebuffer-resize This is definitely over a secure link. I'm not 100% sure what protocol is used; I go through a web portal interface, so it's not like I'm running a VNC/RDP client directly. Thanks, Raul On Apr 28, 2010, at 7:16 PM, Jim Reisert AD1C wrote: My understanding is that the X server inherits the properties of the screen it's started on. For example, if you normally have 2 monitors, and for some reason only 1 monitor is active, and you start Xwin there, if you then active the 2nd monitor, you can't move your Xterm window over there (or you can, but you can't do anything with it). What is RDP? I like LogMeIn for this sort of thing, as long as you're not on a secure (ie. VPN) connection. I really HATE when you log into a remote system and it changes those screen properties. Then when you come into work, it's all messed up. On 4/28/2010 12:38 PM, Raul Acevedo wrote: At work, my display is at 1280x1024. When I RDP from home, I have a bigger screen so my work computer's desktop is resized to 1920x1200. When this happens, X applications cannot display anything below 1024 pixels; below 1024 pixels nothing is displayed, and you can see the other application windows underneath the current X window below 1024 pixels. Is this a known issue? It's a pain to restart X and my apps just to get X to properly adjust its display size. This is mentioned in the XWin manpage as a bug. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Mouse offset when using java swing based gui applications
On 15/07/2010 15:38, Richard Evans wrote: There's a bug reported against Java relating to this, with some more details. It claims to be fixed, but it still occurs. There's a small test case in the bug report. It makes many Java UI applications unusable with Cygwin/X. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6434227 Thanks very much for the link. That bug report and related ones makes interesting reading: I can see now that Swing/AWT problems are probably behind a few problem reports of this kind we've had. I tried out the test case in that particular bug, and it does seem to be fixed in the JRE is claims to be fixed in. But looking at the horror-show that is XWM.java [1], I can believe there are other problems, and the behaviour will be different with different JRE versions. There's certainly scope for adding fixes/workarounds to the multiwindow mode internal window manager so that AWT does the correct thing, but I guess what I need to progress this is a test case I can easily run, and 'java -version' for the platform the test case should be run on [1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/d58354a69011/src/solaris/classes/sun/awt/X11/XWM.java -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Mouse offset when using java swing based gui applications
On 19/07/2010 17:27, Richard Evans wrote:
I've attached a small test case which shows the menu problems.
Thanks very much, that was very helpful in investigating this problem.
This menu behaviour has been seen for all versions of JDK 1.6 as far as
I remember; it certainly happens with 1.6u3 and 1.6u4.
Yes, I wasn't testing what I thought I was testing, and was completely wrong
when I said sun bug #6434227 was fixed in the JRE that it claims it's fixed in.
It's fixed in JDK1.7 and OpenJDK, but that bug lies when it says the fix is in
1.6 as well.
However, it does identify what's going wrong. The significant difference in
XDecoratedPeer.java between 1.6u21 and a fixed version is:
---
/opt/wip/jdk-1_6_0/j2se/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java
2010-07-21 15:46:33.28125 +0100
+++ /opt/wip/openjdk/jdk/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java
2010-06-21 22:15:43.0 +0100
@@ -752,79 +748,69 @@
Point newLocation = targetBounds.getLocation();
-if (xe.get_send_event()) {
+if (xe.get_send_event() || runningWM == XWM.NO_WM ||
XWM.isNonReparentingWM()) {
// Location, Client size + insets
newLocation = new Point(xe.get_x() - currentInsets.left,
xe.get_y() - currentInsets.top);
} else {
// CDE/MWM/Metacity/Sawfish bug: if shell is resized using
// top or left border, we don't receive synthetic
// ConfigureNotify, only the one from X with zero
// coordinates. This is the workaround to get real
// location, 6261336
-// Do the same for non-reparenting WMs (Compiz, Looking Glass)
switch (XWM.getWMID()) {
case XWM.CDE_WM:
case XWM.MOTIF_WM:
case XWM.METACITY_WM:
case XWM.SAWFISH_WM:
- case XWM.COMPIZ_WM:
- case XWM.LG3D_WM:
{
Point xlocation = queryXLocation();
if (log.isLoggable(Level.FINE)) {
log.log(Level.FINE, New X location: {0},
new Object[]{String.valueOf(xlocation)});
}
if (xlocation != null) {
newLocation = xlocation;
}
break;
}
default:
break;
}
}
Location updates from ConfigureNotify are not processed in the NO_WM case,
presumably causing the menus behave as if the window was still located where
it was created.
There are 2 possible workarounds which occur to me:
(i) Lie and pretend we are a non-reparenting WM on the list that AWT knows
about, like LG3D. This one of the workarounds suggested in the manpage for
dwm (a non-reparenting, tiling WM)
Unfortunately, we have to tell a more lies to get AWT to accept this lie, and
in particular, we have to claim to support EWMH, which the internal WM doesn't
really (although it should), so I'm not too keen on this approach.
(ii) Alternatively, it's a straightforward workaround to add to the internal
WM to cause it to send synthetic ConfigureNotify for these windows when a
non-synthetic ConfigureNotify occurs.
From a quick test, this approach seems to work ok. But the Java window still
appears with the frame off the top-left, rather than getting nudged away from
the origin so the frame is visible, which is rather mysterious.
I've uploaded a build with this change at [1], patch to follow. Perhaps you
could try it out and see if it works for you?
[1] ftp://cygwin.com/pub/cygwinx/XWin.20100721-git-2704058015f198ce.exe.bz2
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
[PATCH] Cygwin/X: Internal WM workaround for Java AWT bug
Java applications using AWT on JRE 1.6.0 break with non-reparenting WMs AWT
doesn't explicitly know about (See sun bug #6434227)
XDecoratedPeer.handleConfigureNotifyEvent() only processes non-synthetic
ConfigureNotify events to update window location if it's identified the
WM as a non-reparenting WM it knows about (compiz or lookingglass)
Rather than tell all sorts of lies to get XWM to recognize us as one of
those, simply send a synthetic ConfigureNotify for every non-synthetic one
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
hw/xwin/winmultiwindowwm.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/hw/xwin/winmultiwindowwm.c b/hw/xwin/winmultiwindowwm.c
index 52921f3..9edde6e 100644
--- a/hw/xwin/winmultiwindowwm.c
+++ b/hw/xwin/winmultiwindowwm.c
@@ -1127,6 +1127,30 @@ winMultiWindowXMsgProc (void *pArg)
}
}
}
+ else if (event.type == ConfigureNotify)
+{
+ if (!event.xconfigure.send_event)
+{
+ /*
+Java applications using AWT on JRE 1.6.0 break with
non-reparenting WMs AWT
+doesn't explicitly know about (See sun bug #6434227)
+
+XDecoratedPeer.handleConfigureNotifyEvent() only processes
non-synthetic
+ConfigureNotify events to update window location if it's
identified the
+WM as a non-reparenting WM it knows about (compiz or
lookingglass)
+
+Rather than tell all sorts of lies to get XWM to recognize us
as one of
+those, simply send a synthetic ConfigureNotify for every
non-synthetic one
+ */
+ XEvent event_send = event;
+ event_send.xconfigure.send_event = TRUE;
+ event_send.xconfigure.event = event.xconfigure.window;
+ XSendEvent(event.xconfigure.display,
+ event.xconfigure.window,
+ True, StructureNotifyMask,
+ event_send);
+}
+}
else if (event.type == PropertyNotify
event.xproperty.atom == atmWmName)
{
--
1.7.1
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
[PATCH] Cygwin/X: Fix a GDI bitmap resource leak of window icons
Ensure any icon created specially for a window is destroyed when
the window is destroyed
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
hw/xwin/winmultiwindowicons.c |3 ++-
hw/xwin/winmultiwindowwindow.c | 13 -
hw/xwin/winwin32rootless.c | 20 ++--
3 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/hw/xwin/winmultiwindowicons.c b/hw/xwin/winmultiwindowicons.c
index cb27d2f..86ad51e 100644
--- a/hw/xwin/winmultiwindowicons.c
+++ b/hw/xwin/winmultiwindowicons.c
@@ -631,6 +631,7 @@ void winSelectIcons(WindowPtr pWin, HICON *pIcon, HICON
*pSmallIcon)
*pIcon = hIcon;
else
winDestroyIcon(hIcon);
+
if (pSmallIcon)
*pSmallIcon = hSmallIcon;
else
@@ -639,7 +640,7 @@ void winSelectIcons(WindowPtr pWin, HICON *pIcon, HICON
*pSmallIcon)
void winDestroyIcon(HICON hIcon)
{
- /* Delete the icon if its not the default */
+ /* Delete the icon if its not one of the application defaults or an override
*/
if (hIcon
hIcon != g_hIconX
hIcon != g_hSmallIconX
diff --git a/hw/xwin/winmultiwindowwindow.c b/hw/xwin/winmultiwindowwindow.c
index fd87c66..d9bec35 100644
--- a/hw/xwin/winmultiwindowwindow.c
+++ b/hw/xwin/winmultiwindowwindow.c
@@ -602,7 +602,9 @@ winDestroyWindowsWindow (WindowPtr pWin)
MSG msg;
winWindowPriv(pWin);
BOOL oldstate = winInDestroyWindowsWindow;
-
+ HICON hIcon;
+ HICON hIconSm;
+
#if CYGMULTIWINDOW_DEBUG
ErrorF (winDestroyWindowsWindow\n);
#endif
@@ -613,13 +615,22 @@ winDestroyWindowsWindow (WindowPtr pWin)
winInDestroyWindowsWindow = TRUE;
+ /* Store the info we need to destroy after this window is gone */
+ hIcon = (HICON)SendMessage(pWinPriv-hWnd, WM_GETICON, ICON_BIG, 0);
+ hIconSm = (HICON)SendMessage(pWinPriv-hWnd, WM_GETICON, ICON_SMALL, 0);
+
SetProp (pWinPriv-hWnd, WIN_WINDOW_PROP, NULL);
+
/* Destroy the Windows window */
DestroyWindow (pWinPriv-hWnd);
/* Null our handle to the Window so referencing it will cause an error */
pWinPriv-hWnd = NULL;
+ /* Destroy any icons we created for this window */
+ winDestroyIcon(hIcon);
+ winDestroyIcon(hIconSm);
+
/* Process all messages on our queue */
while (PeekMessage (msg, NULL, 0, 0, PM_REMOVE))
{
diff --git a/hw/xwin/winwin32rootless.c b/hw/xwin/winwin32rootless.c
index c225a44..0e2f979 100755
--- a/hw/xwin/winwin32rootless.c
+++ b/hw/xwin/winwin32rootless.c
@@ -367,8 +367,8 @@ void
winMWExtWMDestroyFrame (RootlessFrameID wid)
{
win32RootlessWindowPtr pRLWinPriv = (win32RootlessWindowPtr) wid;
- HICONhiconClass;
- HICONhiconSmClass;
+ HICONhIcon;
+ HICONhIconSm;
HMODULE hInstance;
int iReturn;
char pszClass[CLASS_NAME_LENGTH];
@@ -399,8 +399,8 @@ winMWExtWMDestroyFrame (RootlessFrameID wid)
/* Store the info we need to destroy after this window is gone */
hInstance = (HINSTANCE) GetClassLongPtr (pRLWinPriv-hWnd, GCLP_HMODULE);
- hiconClass = (HICON) GetClassLongPtr (pRLWinPriv-hWnd, GCLP_HICON);
- hiconSmClass = (HICON) GetClassLongPtr (pRLWinPriv-hWnd, GCLP_HICONSM);
+ hIcon = (HICON)SendMessage(pRLWinPriv-hWnd, WM_GETICON, ICON_BIG, 0);
+ hIconSm = (HICON)SendMessage(pRLWinPriv-hWnd, WM_GETICON, ICON_SMALL, 0);
iReturn = GetClassName (pRLWinPriv-hWnd, pszClass, CLASS_NAME_LENGTH);
pRLWinPriv-fClose = TRUE;
@@ -416,14 +416,14 @@ winMWExtWMDestroyFrame (RootlessFrameID wid)
winDebug (winMWExtWMDestroyFrame - Unregistering %s: , pszClass);
#endif
iReturn = UnregisterClass (pszClass, hInstance);
-
+}
+
#if CYGMULTIWINDOW_DEBUG
- winDebug (winMWExtWMDestroyFramew - %d Deleting Icon: , iReturn);
+ winDebug (winMWExtWMDestroyFramew - Deleting Icon\n);
#endif
-
- winDestroyIcon(hiconClass);
- winDestroyIcon(hiconSmClass);
-}
+
+ winDestroyIcon(hIcon);
+ winDestroyIcon(hIconSm);
#if CYGMULTIWINDOW_DEBUG
winDebug (winMWExtWMDestroyFrame - done\n);
--
1.7.1
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: unable to start X server after upgrading cygwin from 1.5 to 1.7.5
On 23/07/2010 10:31, philippe wrote: I use cygwin and Cygwin/X on a windows XP SP3 latop from a long time. I've recently upgraded cygwin, from 1.5 to 1.7.5, and now it's impossible to start an X server! Reinstalling cygwin (after a complete You probably want to read the FAQ section on upgrading [1] [1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#modular uninstall) doesn't change any things. When i launch startx from de command line (I use mintty as default terminal, and some times rxvt) an X window briefly opens but close rapidly. I've copy/paste the message from the terminal at the end of this message*. Thank's for your help! Philippe. ** from the terminal ** [phili...@port78]~ $ startx xauth: creating new authority file /home/philippe/.serverauth.1270964 Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.8.0.0 (1080) Build Date: 2010-04-02 Contact: cygwin-xfree@cygwin.com XWin was started with the following command line: /usr/bin/X :0 -auth /home/philippe/.serverauth.1270964 _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/port78:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 (II) xorg.conf is not supported (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information LoadPreferences: /home/philippe/.XWinrc not found LoadPreferences: /etc/X11/system.XWinrc not found H... this file should have been created by the xorg-server postinstall script. LoadPreferences: See man XWinrc to customize the XWin menu. LoadPreferences: Loading built-in default winGetDisplay: DISPLAY=:0.0 winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0007 winSetEngine - Using Shadow DirectDraw NonLocking winAdjustVideoModeShadowDDNL - Using Windows display depth of 32 bits per pixel winFinishScreenInitFB - Masks: 00ff ff00 00ff Screen 0 added at virtual desktop coordinate (0,0). MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so (II) GLX: Initialized DRISWRAST GL provider for screen 0 [dix] Could not init font path element /usr/share/fonts/TTF/, removing from list! [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! [dix] Could not init font path element /usr/share/fonts/Type1/, removing from list! winPointerWarpCursor - Discarding first warp: 837 487 (--) 3 mouse buttons found (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: 040C (040c) (--) Using preset keyboard for French (Standard) (40c), type 4 Rules = base Model = pc105 Layout = fr Variant = none Options = none The XKEYBOARD keymap compiler (xkbcomp) reports: Warning: Type ONE_LEVEL has 1 levels, butRALT has 2 symbols Ignoring extra symbols Errors from xkbcomp are not fatal to the X server winProcEstablishConnection - Hello winInitClipboard () winClipboardProc - Hello winProcEstablishConnection - winInitClipboard returned. DetectUnicodeSupport - Windows NT/2000/XP winGetDisplay: DISPLAY=:0.0 winClipboardProc - DISPLAY=:0.0 winClipboardProc - XOpenDisplay () returned and successfully opened the display. Warning: Unable to load any usable ISO8859 font Warning: Cannot convert string -adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-* to type FontStruct Warning: Unable to load any usable ISO8859 font Warning: Unable to load any usable ISO8859 font Error: Aborting: no font found Warning: Cannot convert string -adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-* to type FontStruct Warning: Cannot convert string -adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-* to type Warning: FontStruct Unable to load any usable ISO8859 font Warning: Unable to load any usable ISO8859 font Warning: Unable to load any usable ISO8859 font Warning: Unable to load any usable ISO8859 font Error: Aborting: no font found You need to install 'font-adobe-dpi75'. However, this should have been installed automatically as a dependency of xterm. I wish you'd attached your cygcheck output. You could try reinstalling that package, although I'd guess something went wrong with installing package. You should check /var/log/setup.log for clues. waiting for X server to shut down winClipboardProc - winClipboardFlushWindowsMessageQueue trapped WM_QUIT message, exiting main loop. winClipboardProc - XDestroyWindow succeeded. winDeinitMultiWindowWM - Noting shutdown in progress -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: unable to start X server after upgrading cygwin from 1.5 to 1.7.5
On 23/07/2010 13:42, philippe wrote: Jon TURNEY a écrit : [...] You need to install 'font-adobe-dpi75'. from the cygwin setup.exe or manually? Using setup. But your setup needs to be running without errors first. However, this should have been installed automatically as a dependency of xterm. I wish you'd attached your cygcheck output. is this you need? [phili...@port78]/ $ cygcheck startx Found: C:\cygwin\bin\startx C:\cygwin\bin\startxcygcheck: C:\cygwin\bin\startx is not a DLL: magic number 2123 (8483) '#!' No Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html ^^^ Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ You could try reinstalling that package, although I'd guess something went wrong with installing package. You should check /var/log/setup.log for clues. I've several warning like abnormal exit: exit code=128 in setup.log, the first one is : 2010/07/06 20:26:45 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/xorg-server.sh 2010/07/06 20:27:07 abnormal exit: exit code=128 This is the problem. Reinstalling won't fix anything until you find out why this is happening and fix it. I reinstall X11 package now and tell you what's new before. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Missing charsets in String to FontSet conversion
On 03/08/2010 10:00, Thomas Dickey wrote: On Tue, 3 Aug 2010, Ryan Johnson wrote: At some point an annoyance appeared with my xterm windows: The first time I use [ctrl]+mouse click in any window, that xterm becomes unresponsive for about 5 seconds with the CPU pegged to 100%. After the five seconds is up, whatever shell spawned the xterm receives the following message: Warning: Missing charsets in String to FontSet conversion After that all works normally (until I open the next xterm window). Is there a way to diagnose what the problem is? I don't know what FontSet string the error even refers to, let alone which parts of that string were invalid. In any case, it really shouldn't take five seconds of hard CPU crunching to detect and report an invalid input string. There's some more discussion at http://sourceware.org/bugzilla/show_bug.cgi?id=10948 Installing the fonts font-isas-misc, font-jis-misc and font-daewoo-misc should also work around the problem, which can also be seen with other applications, as that ensures that at least one font exists for every charset. I agree that the error message sucks and should tell you the charsets which are missing and what string it was attempting to convert. This topic came up last year, iirc the issue was this: http://invisible-island.net/xterm/xterm.faq.html#slow_menus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Can't Paste into Xwindow application from Winows7
On 02/08/2010 20:50, Scott Bushnell wrote: I running Windows 7 the latest version of Cygwin/X. I can paste from my X windows application to any Windows application but can't paste to X windows from Windows7. It works fine using Windows XP. P.S. How can I debug/troubleshoot this. [1] suggests some steps which you might take. You should also mention if you are using a Windows 'clipboard manager' application. [1] http://sourceware.org/ml/cygwin-xfree/2009-10/msg00129.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Updated xorg-server-1.8.2-1
On 06/08/2010 10:21, Yaakov (Cygwin/X) wrote: The following package has been updated in the Cygwin distribution: *** xorg-server-1.8.2-1 *** xorg-server-dmx-1.8.2-1 This is an update to the latest upstream release of the X servers. Support for RANDR display resizing was added. In windowed mode, this requires the XWin -resize option; in multiwindow mode, the display will automatically resize to match a change in Windows display resolution. See XWin(1) for details. I'm afraid I made a mistake when updating the XWin(1) man page when adding the description of '-resize'. '-resize' is also required in multiwindow mode to activate resize support. Also, something like the following needs to be added: In -multwindow or -rootless mode, if the X screen is of the same dimensions as a Windows monitor or the virtual desktop, the X server will respond to the WM_DISPLAYCHANGED sent when those dimensions change by resizing the X screen. Changing the size of the X screen using the RANDR extension is not permitted. We'll probably make -resize on by default in -multiwindow mode in the future, after more testing and feedback. Additional patches: - Generate X keycodes for multimedia keys. - Update mapping for Canadian keyboard layouts. - Add -resize command line option. - Internal WM workaround for Java AWT bug. - Fix a GDI bitmap resource leak of window icons. - Store pthread_ids and chain IOError handlers to avoid longjmp across threads. Just to clarify, this should fix the problem of X crashing during shutdown, leaving behind a stale lock file. Which should in turn fix the problem of not being able to start X if it was previously run by an Administrator if you aren't an Administrator. If there are still problems with multiple users of X on the same computer, either sequentially or in parallel, we'd like to hear about them. - Make select() poll and not block if there are unprocessed Windows messages. - Better keyboard debugging output. - Show any fatal error message. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Slow response to keypresses in xorg-server-1.8.0-1
On 07/08/2010 16:39, Reini Urban wrote: 2010/8/5 Laurent Montaronl...@pobox.com: The workaround in XWin.20100630-git-bc2f74e105146c36.exe definitely fixes the problem. I have been running with it for two days now. Did anyone find out if root cause is a bug in /dev/windows implementation or something else? It just smells like so, because my perl-tk patches to use /dev/windows as messageloop fail, while the windows loop works fine. That's interesting. Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? But I could easily be missing something... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X hardware acceleration still flaky?
On 08/08/2010 10:18, l.w...@surrey.ac.uk wrote: Well, it's been eighteen months since I last asked: http://www.cygwin.com/ml/cygwin-xfree/2009-02/msg00259.html so I attempted to use opengl hardware acceleration with Cygwin and XFree 7.4, using Geomview (www.geomview.org) as the test application on an uptodate Cygwin 1.7 install. Lots of flickering for about thirty seconds (of correct output), but then the X server crashes. So, no visible change over previous. It's still a regression on pre-7.4. I'm not sure what you were testing here, but I can't see how it could be hardware AIGLX. xwin-gl is obsolete, an empty package since R7.4 [1], so if you are running that somehow, it must be an old version, which I am surprised works at all. Alternatively, you are using xwin with software rendering, and your application exposes some bug in the Xserver which makes it crash. I am happy to work with you to resolve these issues. Has any work been attempted on improving hardware acceleration in xwin-gl? Yes, this is something I have been working on in my copious free time(TM): http://cygwin.com/ml/cygwin-xfree/2009-06/msg00088.html http://sourceware.org/ml/cygwin-xfree/2009-08/msg00021.html http://x.cygwin.com/devel/todo.html I hope you'll note that savi is one of the applications I've been testing with. However, given the lack of response so far, it seems that you and me are the only 2 people interested in working AIGLX for XWin :-) I wouldn't suggest testing with those binaries at this stage, as I've moved on a bit. I hope to shortly make another test release containing AIGLX based on the upcoming Xserver 1.9, and I would very much appreciate some testing of the AIGLX functionality in that, when it is available. [1] http://cygwin.com/cgi-bin2/package-grep.cgi?grep=xwin-gl -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin crash after the launch of startkde on a remote Red Hat 5 machine
/InitOutput.c. That what is doing the patch Attached to this email. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X hardware acceleration still flaky?
On 08/08/2010 15:57, l.w...@surrey.ac.uk wrote: Hi Jon, I just downloaded the current X server and its libraries in the Cygwin distro; the xwin-gl allusion came from the previous thread I mentioned. So, the current problem is with OpenGL on X. OpenGL and hardware acceleration are not synonyms. Testing with the experimental AIGLX code is moot if it doesn't work with the current X server. Compiling geomview 1.9.4 --with-opengl is straightforward (that's one improvement on pre-7.4 X; configure doesn't get confused about X library locations and building is easier). I then tried running savi with geomview: - using OpenGL. 30 seconds of slow flickering (slow enough to be the software rendering that you alluded to?), then the X server consistently crashes, even before I've had a chance to turn on texturemapping... I've built savi and geomview, and I'm afraid I can't reproduce this crash. There's no flickering unless I use the mouse to rotate the planet, which almost looks like it's not using double-buffering for some reason, as the whole frame looks like it's being drawn into the front buffer... I've rebuilt X server 1.8.2-1 with debugging symbols and uploaded it at [1], can you run that under gdb and reproduce your crash and post a backtrace, please. [1] ftp://cygwin.com/pub/cygwinx/XWin.20100808-git-66f3680cb47fbd09.exe.bz2 - forcing internal geomview software rendering using geomview -noopengl -run ../savi1.4.3/savi $* . Works, but is rather stately. No texturemapping support, obviously. Less slow than the brief opengl attempt, though, which figures given that doing OpenGL in software imposes more layers of overhead? That's the status from testing with what cygwin ships at the moment. I haven't tried your older binaries. Please let me know when you get to another test release, and I'll try it out. thanks, L. SaVi satellite constellation visualization http://savi.sf.net/ On 8 Aug 2010, at 13:57, Jon TURNEY wrote: On 08/08/2010 10:18, l.w...@surrey.ac.uk wrote: Well, it's been eighteen months since I last asked: http://www.cygwin.com/ml/cygwin-xfree/2009-02/msg00259.html so I attempted to use opengl hardware acceleration with Cygwin and XFree 7.4, using Geomview (www.geomview.org) as the test application on an uptodate Cygwin 1.7 install. Lots of flickering for about thirty seconds (of correct output), but then the X server crashes. So, no visible change over previous. It's still a regression on pre-7.4. I'm not sure what you were testing here, but I can't see how it could be hardware AIGLX. xwin-gl is obsolete, an empty package since R7.4 [1], so if you are running that somehow, it must be an old version, which I am surprised works at all. Alternatively, you are using xwin with software rendering, and your application exposes some bug in the Xserver which makes it crash. I am happy to work with you to resolve these issues. Has any work been attempted on improving hardware acceleration in xwin-gl? Yes, this is something I have been working on in my copious free time(TM): http://cygwin.com/ml/cygwin-xfree/2009-06/msg00088.html http://sourceware.org/ml/cygwin-xfree/2009-08/msg00021.html http://x.cygwin.com/devel/todo.html I hope you'll note that savi is one of the applications I've been testing with. However, given the lack of response so far, it seems that you and me are the only 2 people interested in working AIGLX for XWin :-) I wouldn't suggest testing with those binaries at this stage, as I've moved on a bit. I hope to shortly make another test release containing AIGLX based on the upcoming Xserver 1.9, and I would very much appreciate some testing of the AIGLX functionality in that, when it is available. [1] http://cygwin.com/cgi-bin2/package-grep.cgi?grep=xwin-gl -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Xorg/CDE bug, fixed in the last Xorg version 1.8.99.905
On 09/08/2010 14:57, Michel Hummel wrote: 2010/8/9 Michel Hummelhummel.mic...@gmail.com Hello I working on an bug With Xwin/Xorg and Solaris CDE WM which leads to the freeze of the X server. My research shows that this bug seems to be fixed in Xorg 1.8.99.905 (1.9 RC 5) http://sourceware.org/bugzilla/show_bug.cgi?id=11301 [snip] Fatal server error: could not open default font 'fixed' winDeinitMultiWindowWM - Noting shutdown in progress I 've tried to follow the FAQ : http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-error-font-eof but it didn't change anything * The directories exist * The fonts are at the good place (it's working with the Release: 1.8.2.0 (10802000)) perhaps i need to modify the fonts as I use a new version of the libXfont package ? Is someone can help me ? Thanks, Michel Hummel http://cgit.freedesktop.org/xorg/lib/libXfont/commit/?id=c482a2c104aa5cd1a265c2ca310a308dcc418fe7 Is the response to my question Thanks See also the section libXfont linkage issue in [1]. That documentation needs to be updated to reflect the new reality once a libXfont is released containing that change. [1] http://x.cygwin.com/docs/cg/prog-build-prerequisites.html#prog-compiling-environment-setup -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X hardware acceleration still flaky?
On 09/08/2010 15:08, l.w...@surrey.ac.uk wrote: Hi Jon, the lack of flickering and lack of double-buffering you describe sounds like geomview being run without opengl, either because it has been compiled without opengl (still the default if you just type ./configure, I believe), or because geomview -noopengl was issued. Did you build Geomview with --with-opengl, and have you turned on a texturemapped Earth showing coloured continents? (If geomview issues a 'Shared memory unavailable, using fallback display method' to stderr at launch, it's not using OpenGL.) Yes, I have configured geomview with --with-opengl. No, I didn't turn on texturemapped earth, because your report didn't mention that. Does this mean turn on Texture mapping in Savi's rendering menu (which appears to be on by default) or Use simple/detailed earth map? If I run geomview -noppengl I get no flickering even when rotating the planet. When geomview is run with opengl, I see consistent flickering at every single animation stage, not just when dragging with the mouse. -noopengl is much smoother. (I'm using a fairly high-end Core2Duo with graphic card.) Do you have something to make an animation start automatically when savi opens? I just get a static planet and z,y,x axes unless I drag it around with the mouse. I've now realised that my crashes only occur when I use the second screen attached to my machine. (Mea culpa - I take multiple screens for granted.) When geomview's camera is on the root (laptop) screen, X doesn't crash, even when texturemapping, and I get slow but flickery animations of texturemapped Earths. Move it over to the second screen and do something that invokes texturemapping like turning on a detailed Earth - goodbye, Mr X. I am also using multiple monitors. It's a little odd that XWin.0.log doesn't explicitly call out the two screens as such - it knows the primary (laptop) monitor is 1280 by 800, and that DIB has a height of 1824 because there's a 1280x1024 screen positioned above it. Although the logging could perhaps be clearer, -multiwindow implies -multimonitors by default which gives a single X screen the size of the Windows virtual desktop. Is it still useful to give you a bt from gdb? Yes, please. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Missing charsets in String to FontSet conversion
On 03/08/2010 16:21, Ryan Johnson wrote: As I mentioned before, I'd seen references to those fonts but wasn't sure it would actually help me. I just installed them and, sure enough, there's still some (fewer?) missing charsets. The delay dropped to only 2-3 seconds now though, so I guess that helps. Is there a way to diagnose which fonts/charsets are still missing? Hmm. You could write a small test application which calls XCreateFontSet() with the base font of * and reports the list of missing charsets returned. It also seems that twm reports these problems in a slightly more useful fashion than libXt (saying font for charset charset is lacking), so running that (against an X server not started in multiwindow mode) might serve just as well. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 09/08/2010 22:14, Ryan Johnson wrote: I was overjoyed to see that the release notes for the new X server release mention support for resizing the X desktop with the windows desktop. Unfortunately, it didn't work :( I modified the xwin windows shortcut to run as follows: C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe -- -resize You need to quote the entire command you are passing to bash after -c i.e, try C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe -- -resize Then started the server at 1920x1200x32bpp while my ThinkPad was attached to an external LCD. When I detached the monitor to leave the office, X disappeared with signal 11 (log attached). Oddly, the log file didn't mention -resize as an argument to XWin, but it did attempt to resize so I assume the feature was active. There have been some reports of the X server segfaulting when the resolution changed, prior the addition of -resize support. This is something which also needs to be fixed. Note that, for reasons I've never understood, ThinkPad's resolution switching utility always switches through 3-4 resolutions on its way to a new setting; that might have something to do with the problem. The final resolution should have been 1400x1050x16bpp. I'm also attaching cygcheck's output and the .stackdump file in case they are helpful. Thoughts? Never assume! :-) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Xorg/CDE bug, fixed in the last Xorg version 1.8.99.905
On 10/08/2010 09:26, Michel Hummel wrote: Thank you for your help. Once this problem resolved, the server crashes with another message (something like) : -- assert failed (key-initialized); in privates.h -- Then the server seems to start and work correctly without any device problem. Do you have an idea about this new and last issues ? You need the patch from [1] [1] http://lists.x.org/archives/xorg-devel/2010-August/011683.html 1.8.99.905 is a release candidate for the upcoming 1.9 release, you should expect minor issues like this if you choose to use it. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Unable to install X on 64-bit Windows 7 Premium
On 10/08/2010 00:19, Bob Kline wrote: I finally had to replace my ancient Windows XP box, and ended up with a Windows 7 Home Premium 64-bit system. If I run setup.exe to install a fresh cygwin, it succeeds as long as I don't touch the X11 set, leaving it at Default (which is to say, don't install anything in the set). If I change Default to Install for X11, I get a dialog box which says: Cygwin Setup - Running postinstall scripts Postinstall script errors The following errors occured executing postinstall scripts Package: gcc4-core gcc4-core.sh exit code 126 This one is already reported at [1], and the workaround given there,i.e. chmod 755 /usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh and then run /etc/postinstall/gcc4-core.sh manually should work. I'm a bit surprised that gcc4 is a dependency of X. Package: libglade2.0_0 libglade2.0.sh exit code 2 Package: xinit xinit.sh exit code 8 Package: No package gcc4-core.sh exit code 126 libglade2.0.sh exit code 2 xinit.sh exit code 8 When I click Next, I get an error message saying the installation won't work properly unless I correct the failures which occurred, and tells me to look in the log file. The log file doesn't have anything beyond what appears in the dialog box as far as the errors are concerned, and there's no clue anywhere telling me how I'm supposed to go about correcting the errors. [snip] Could I please have some assistance figuring out how to correct the errors? What other information do I need to supply? Thanks for reporting these problems. Setup has only recently started recording problems with postinstall scripts, previously it would silently ignore failures. Hmm... it seems that the output from these failing commands is only captured in setup.log.full, not setup.log, so I think that messagebox needs fixing. You can look there, or run these scripts manually (they can be found in /etc/postinstall) and post the errors reported by those scripts so we can fix the problems. [1] http://sourceware.org/ml/cygwin/2010-08/msg00158.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Unable to install X on 64-bit Windows 7 Premium
On 10/08/2010 13:12, Jon TURNEY wrote: On 10/08/2010 00:19, Bob Kline wrote: I finally had to replace my ancient Windows XP box, and ended up with a Windows 7 Home Premium 64-bit system. If I run setup.exe to install a fresh cygwin, it succeeds as long as I don't touch the X11 set, leaving it at Default (which is to say, don't install anything in the set). If I change Default to Install for X11, I get a dialog box which says: Cygwin Setup - Running postinstall scripts Postinstall script errors The following errors occured executing postinstall scripts Package: gcc4-core gcc4-core.sh exit code 126 This one is already reported at [1], and the workaround given there,i.e. chmod 755 /usr/sbin/fix-libtool-scripts-for-latest-gcc-runtimes.sh and then run /etc/postinstall/gcc4-core.sh manually should work. I'm a bit surprised that gcc4 is a dependency of X. Package: libglade2.0_0 libglade2.0.sh exit code 2 Package: xinit xinit.sh exit code 8 and since all xinit.sh does is run mkshortcut to create a start menu shortcut, I'd guess this is the same issue as [1], assuming we don't have a cygutils release with that fixed yet. [1] http://sourceware.org/ml/cygwin/2010-03/msg00357.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 10/08/2010 06:48, Ryan Johnson wrote: On 8/10/2010 12:02 AM, Jon TURNEY wrote: On 09/08/2010 22:14, Ryan Johnson wrote: I was overjoyed to see that the release notes for the new X server release mention support for resizing the X desktop with the windows desktop. Unfortunately, it didn't work :( I modified the xwin windows shortcut to run as follows: C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe -- -resize You need to quote the entire command you are passing to bash after -c i.e, try C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe -- -resize Then started the server at 1920x1200x32bpp while my ThinkPad was attached to an external LCD. When I detached the monitor to leave the office, X disappeared with signal 11 (log attached). Oddly, the log file didn't mention -resize as an argument to XWin, but it did attempt to resize so I assume the feature was active. Oh dear. Well it seems I only thought I added code to only enable resize support in multiwindow mode when requested, so it's always on for multiwindow mode at the moment. That wouldn't be so bad, but it also seems that the -resize code completely fails to correctly handle a change of colour depth (e.g. from 32 bits to 16 bits or vice versa) leading to this segfault. Unfortunately, fixing this looks to be quite complex :-( Thanks for testing, anyhow :-) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: CygwinX at MS Terminalserver?
On 12/08/2010 08:31, Steffen Sledz wrote: Does anyone has experiences running CygwinX at an MS Terminalserver? We like to use it at one based on Windows Server 2003 with NTFS. Is it possible to run multiple XWin instances for multiple user sessions in parallel? Any suggestions how to setup the rights in /tmp, /var/log, /var/run, etc.? You shouldn't change the rights on any of these, as this could affect the security or functioning of other cygwin apps. Fortunately, you shouldn't need to, as, provided each X server instance has a unique display number, everything should work :-) Where you may experience problems is if the X server crashes whilst being run by an Administrator, and then a non-Adminstrator user tries to run X server using the same display number, which will fail due being unable to remove the stale lock file and unix socket. Unfortunately, there is no obvious way to fix that without introducing a security hole (not that it is known to be secure anyhow) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 12/08/2010 16:49, Ryan Johnson wrote: On 8/12/2010 5:46 PM, Jon TURNEY wrote: On 10/08/2010 06:48, Ryan Johnson wrote: On 8/10/2010 12:02 AM, Jon TURNEY wrote: On 09/08/2010 22:14, Ryan Johnson wrote: When I detached the monitor to leave the office, X disappeared with signal 11 (log attached). Oddly, the log file didn't mention -resize as an argument to XWin, but it did attempt to resize so I assume the feature was active. Oh dear. Well it seems I only thought I added code to only enable resize support in multiwindow mode when requested, so it's always on for multiwindow mode at the moment. That wouldn't be so bad, but it also seems that the -resize code completely fails to correctly handle a change of colour depth (e.g. from 32 bits to 16 bits or vice versa) leading to this segfault. Unfortunately, fixing this looks to be quite complex :-( Thanks for testing, anyhow :-) So... does that mean I have to roll back or face a seg fault after every commute? Or is there a way to explicitly disable it? I'm afraid so. As I say, I meant to add a means to disable -resize in -multiwindow mode to avoid exactly this kind of situation. Since it's the transition from 32bpp to 16bpp which breaks this, one possible workaround would be to run your large monitor at 16bpp, which might also give you working resize. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X hardware acceleration still flaky?
On 10/08/2010 12:00, l.w...@surrey.ac.uk wrote: Program received signal SIGSEGV, Segmentation fault. [Switching to thread 5736.0x16c4] 0x6fb96c8d in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll (gdb) bt #0 0x6fb96c8d in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll #1 0x6fb97205 in pixman_fill_sse2 () from /usr/bin/cygpixman-1-0.dll #2 0x6fb77245 in pixman_fill () from /usr/bin/cygpixman-1-0.dll #3 0x0044924b in fbFill (pDrawable=0x109306f8, pGC=0x10936530, x=657, y=367, width=450, height=450) at fbfill.c:48 #4 0x0044746f in fbPolyFillRect (pDrawable=0x109306f8, pGC=0x10936530, nrect=0, prect=0x1096791c) at fbfillrect.c:77 #5 0x0052728f in damagePolyFillRect (pDrawable=0x109306f8, pGC=0x10936530, nRects=1, pRects=0x10967914) at damage.c:1404 #6 0x005504c3 in ProcPolyFillRectangle (client=0x106bd4f0) at dispatch.c:1939 #7 0x0054c56e in Dispatch () at dispatch.c:439 #8 0x005465af in main (argc=3, argv=0x61227b64, envp=0x104300f8) at main.c:286 Thanks. With the details provided in the last couple of emails, I have managed to reproduce what I think is the same problem as you are seeing. 1) Start geomview 2) Cause the geomview camera window to start animating, e.g. by loading one of the demo scenes and making the camera rotate, or by opening SaVi and starting simulated time running 3) Move the camera window away from it's original position up or to the left (observe if you move it a small amount to the right or down, the area of scene being drawn in it which is updated is constrained to the original window position) This has nothing to do with 'hardware acceleration' or OpenGL, it seems that the particular way this application draws it's output (into a same-size child window of the camera window) interacts with the composite extension to expose a bug in the XWin code. You should be able to workaround the crash by starting the X server with '-extension Composite' to disable the composite extension. I've uploaded a build with an attempt at fixing this at [1]. Perhaps you could try it out and see if it works for you? I'm not sure why the image flickers so badly, a double buffered OpenGL visual seems to be being used, so only a complete frame should be transferred to the display, but I can see elements of the scene being drawn. [1] ftp://cygwin.com/pub/cygwinx/XWin.20100812-git-7180c693de178032.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: CygwinX at MS Terminalserver?
On 13/08/2010 08:13, Steffen Sledz wrote: Am 12.08.2010 18:04, schrieb Jon TURNEY: On 12/08/2010 08:31, Steffen Sledz wrote: Does anyone has experiences running CygwinX at an MS Terminalserver? We like to use it at one based on Windows Server 2003 with NTFS. Is it possible to run multiple XWin instances for multiple user sessions in parallel? Any suggestions how to setup the rights in /tmp, /var/log, /var/run, etc.? You shouldn't change the rights on any of these, as this could affect the security or functioning of other cygwin apps. Fortunately, you shouldn't need to, as, provided each X server instance has a unique display number, everything should work :-) This seems not to be right. :( Here are the results of my tests: [snip] Now testuser0002 tries to start another server in parallel. This gives this error: /usr/bin/startxwin: Resource temporarily unavailable (errno 11): Another X server instance is running on DISPLAY :0 This is expected. As I said, each X server instance must have a unique display number. This can't possibly work any other way. If two users both have an X server with display number 0, to which server should a client started with DISPLAY=:0.0 connect? Now testuser0001 stops his server by using the Exit item from the server menu. After this the files/dirs look like this. [snip] /var/log: total 2316 drwxrwxrwt+ 1 Administrator Administrators 0 Aug 13 08:54 . drwxr-xr-x+ 1 Administrator Administrators 0 May 17 16:21 .. -rw-r--r-- 1 Administrator Administrators 139786 Aug 13 08:48 setup.log -rw-r--r-- 1 Administrator Administrators 2219958 Aug 13 08:48 setup.log.full -rw-r--r-- 1 testuser0001 Domain Users 4871 Aug 13 08:58 XWin.0.log snap Now testuser0002 tries to start a server. This results in an error popup: snip A fatal error has occured and Cygwin/X will now exit. Cannot open log file /var/log/XWin.0.log This is interesting. On my systems, /var/log has mode 777, rather than 1777. Having the restricted deletion flag set on /var/log prevents other users from deleting the logfile from a previous run. However, checking the source for setup.exe, I see that it does create /var/log with 1777 permissions, so how I got into this state I don't know... I'm not sure that is right, but assuming it is intentional, I guess we need to create a /var/log/xwin with mode 777 and arrange for that to be the default logfile location mkdir /var/log/xwin chmod 777 /var/log/xwin adding '-logfile /var/log/xwin/XWin.%s.log' to your xwin command line. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X hardware acceleration still flaky?
On 12/08/2010 19:20, l.w...@surrey.ac.uk wrote: I can confirm that under the current Cygwin release, with your original XWin debug code and geomview running with opengl support enabled and SaVi animating the Geomview window and forcing camera updates: moving the geomview window up and/or to the left causes the crash, while moving it down and/or to the left constrains the updated area to the overlap of the current window position with the original viewport (if that's the right term) - hard to spot amongst the flickering, and I missed that. Apologies. So, yes, it's not related to use of a second monitor; I was moving the geomview camera up to that monitor to get the crash. I can confirm that your replacement code drop (url below) appears to fix this crash problem. Thanks for testing. However, I have a question about your conclusion that this has nothing to do with opengl. If you start geomview under a buggy crashing XWin server with: geomview -noopengl (one dash, note spelling) there's no flickering or crashing; drawing is always slow and reliable, even under a buggy XWin. From that, it's a pretty easy conclusion to presume that OpenGL is somehow involved? Or is only one of the geomview drawing methods (the one that just happens to use OpenGL) at fault with the composite extension? Whilst this is the obvious conclusion to reach, it doesn't seem to be correct. Supplying -noopengl to geomview causes it to do different things, and in particular, it creates a different window hierarchy inside the camera window (which you can observe using xwininfo -tree on that camera window). It seems that the window hierarchy used when opengl is selected, happens to expose a bug in XWin, which causes composite to handle the window's position incorrectly. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Postinstall script error
On 25/08/2010 03:46, noggin wrote: Here is a slice from setup.log 2010/08/23 23:47:07 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/fltk.sh 2010/08/23 23:48:01 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/libglade2.0.sh 2010/08/23 23:48:03 abnormal exit: exit code=2 2010/08/23 23:48:03 running: C:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/obconf.sh A workaround for this problem is reported at [1] mkdir -p /etc/xml edit /etc/postinstall/libglade2.0.sh to add --create /etc/postinstall/libglade2.0.sh [1] http://sourceware.org/ml/cygwin-xfree/2010-08/msg00074.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Unable to start XWin with --nolock
On 26/08/2010 18:18, Richard Gitschlag wrote: I am having trouble starting XWin on my system. It complains about being unable to read lock the file -- okay, so it resides on a FAT32 drive, no big. Just add --nolock to my command line and move on. But it doesn't work. But it does. But doesn't. I AM able to run XWin from inside cygwin's bash prompt: $ xinit -- -nolock -multiwindow $ startxwin -- -nolock But I can NOT run Xwin from a Windows command prompt or a Start Menu shortcut: /cygwin/bin/run.exe /usr/bin/bash.exe -l -c /usr/bin/xinit -- -nolock -multiwindow /cygwin/bin/run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin -- -nolock In these cases I am given the read-lock error, and: XWin was started with the following command line: X :0 In other words, I am unable to pass my command-line options to XWin, so I cannot work around the error. Did I overlook something? What do I do next? You need to quote the command after -c to prevent bash assuming those options are meant for itself. This has been answered a few times before, e.g. at [1] I'm not sure if you arrived at using -nolock from reading FAQ 3.4 [2], perhaps I need to improve that FAQ to give more guidance. [1] http://sourceware.org/ml/cygwin-xfree/2010-04/msg00026.html [2] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-cant-read-lock-file -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: CygwinX Users Guide
On 20/08/2010 01:21, noggin wrote: Tried to print the PDF version of the guide, August 19 1700h. All screenshots are displaced off the right-hand side. Change magnification and they are still displaced. Thanks for reporting this issue. This document seems to have been this way forever. I've tweaked the docbook source so these images should be scaled to fit in the PDF output, and rebuilt and uploaded the documentation. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: CygwinX at MS Terminalserver?
On 16/08/2010 07:35, Steffen Sledz wrote: Am 13.08.2010 13:09, schrieb Jon TURNEY: Now testuser0002 tries to start another server in parallel. This gives this error: /usr/bin/startxwin: Resource temporarily unavailable (errno 11): Another X server instance is running on DISPLAY :0 This is expected. As I said, each X server instance must have a unique display number. This can't possibly work any other way. If two users both have an X server with display number 0, to which server should a client started with DISPLAY=:0.0 connect? That's clear. I thought (or hoped) that starting X server using the XWin Server menu item automatically searches for an unused display number and uses it. I think that would be a good default behaviour. I agree it would be useful, and it is on the todo list [1], but there's a non-trivial problem to solve first: How is the display number which the server has allocated communicated to other processes, so that the users clients appear on the right display? If you start the X server first and then launch everything from the traymenu, everything would works fine, as the X server places a correct DISPLAY variable into the environment inherited by the child process. But if you start the X server via xinit/startx/startxwin, the display number needs to be communicated back to xinit, so that the correct display number is used for clients which are subsequently started by xinit. Fedora ships with a patch [2] which adds the -displayfd option, which allocates a display number and writes it to the specified fd. But to be useful to us, xinit would needs some code to use that flag (under some circumstances) and read that display number and use it for the clients it creates. There's also the case where the user explicitly sets DISPLAY programmatically or manually before starting clients. I think with some suitable shell scripting, -displayfd probably can be used for that also. [1] http://x.cygwin.com/devel/todo.html [2] http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-server/xserver-1.6.0-displayfd.patch A fatal error has occured and Cygwin/X will now exit. Cannot open log file /var/log/XWin.0.log This is interesting. On my systems, /var/log has mode 777, rather than 1777. Having the restricted deletion flag set on /var/log prevents other users from deleting the logfile from a previous run. However, checking the source for setup.exe, I see that it does create /var/log with 1777 permissions, so how I got into this state I don't know... I'm not sure that is right, but assuming it is intentional, I guess we need to create a /var/log/xwin with mode 777 and arrange for that to be the default logfile location mkdir /var/log/xwin chmod 777 /var/log/xwin adding '-logfile /var/log/xwin/XWin.%s.log' to your xwin command line. I tested this with success. :) It would be very helpfully too if this can become the default behaviour of the XWin Server menu item (or XWin). Well, it's not clear here how this should be fixed. I *think* that this is just a setup bug, and we can simply create /var/log with mode 777. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 1.7.6: Install error said postinstall error
On 25/08/2010 10:24, Lucas wrote: When I was installing Cygwin downloaded using the newest setup.exe yesterday, lots of error happend and the install GUI said postinstall error. This doesn't seem to be an X problem, so should have been sent to the main cygwin list. Packages: No Package boxes.sh: exit code : 2 http://sourceware.org/ml/cygwin/2010-08/msg00199.html Add the missing : to /etc/postinstall/boxes.sh and all should be well. libglade2.0.sh: exit code : 2 http://cygwin.com/ml/cygwin-xfree/2010-08/msg00120.html fontconfig.sh: exit code : 14 Not sure what's causing this one. Can you post the output from trying to run /etc/postinstall/fontconfig.sh and/or /var/log/setup.log.full ? I have searched the maillist and found many people asked about this error but the error code are not like mine, so I turn for help here, thinking that maybe somebody here knows about it. Besides, the error report mails seem to not have got any solution so for, so is this a bug of the bash scripts in the new version? I have attached the setup.log. THANKS a lot, everybody! -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
/dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On 08/08/2010 12:04, Andy Koppe wrote:
On 7 August 2010 23:07, Jon TURNEY wrote:
Hmmm, looking again at the implementation of select(), I don't immediately
see that when waiting on /dev/windows, it checks that the message queue has
old messages on it before waiting. The MSDN documentation for
MsgWaitForMultipleObjects() seems to says that messages which had arrived
before the last PeekMessage() etc. aren't considered new and so don't end
the wait?
I think you're right, a call to PeekMessage is needed for proper
select() semantics: it shouldn't block if data is available for
reading.
Attached is a small test-case which seems to demonstrate this problem.
Run ./dev-windows-select-test and observe select() blocks for the full
timeout, despite the fact that the /dev/windows fd is ready for reading (and
it reported as such as the end of the timeout)
If you run './dev-windows-select-test -skip' to skip the PeekMessage(),
select() returns immediately, indicating the /dev/windows fd is ready for reading.
#include stdio.h
#include fcntl.h
#include sys/select.h
#include errno.h
#include windows.h
// gcc -o dev-windows-select-test.exe dev-windows-select-test.c -Wall -mwindows
int main(int argc, char *argv[])
{
int fd = open(/dev/windows, O_RDONLY);
if (PostMessage(NULL, WM_USER, 0, 0) != 0)
printf(PostMessage succeeded\n);
else
printf(PostMessage failed\n);
if (argc = 1)
{
MSG msg;
if (PeekMessage(msg, NULL, 0, 0, PM_NOREMOVE))
printf(PeekMessage reports a message available\n);
}
struct timeval timeout;
timeout.tv_sec = 5;
timeout.tv_usec = 0;
fd_set readfds;
FD_ZERO(readfds);
FD_SET(fd, readfds);
int rc = select(fd+1, readfds, NULL, NULL, timeout);
printf(select returned %d %s\n, rc, strerror(errno));
return 0;
}
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On 30/08/2010 12:23, Corinna Vinschen wrote: On Aug 29 14:39, Jon TURNEY wrote: On 08/08/2010 12:04, Andy Koppe wrote: On 7 August 2010 23:07, Jon TURNEY wrote: Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? I think you're right, a call to PeekMessage is needed for proper select() semantics: it shouldn't block if data is available for reading. Attached is a small test-case which seems to demonstrate this problem. Run ./dev-windows-select-test and observe select() blocks for the full timeout, despite the fact that the /dev/windows fd is ready for reading (and it reported as such as the end of the timeout) If you run './dev-windows-select-test -skip' to skip the PeekMessage(), select() returns immediately, indicating the /dev/windows fd is ready for reading. Again, thanks for the testcase. I applied a patch to Cygwin which should make select on /dev/windows fully functional. The blessed solution is to replace the call to MsgWaitForMultipleObjects with a call to MsgWaitForMultipleObjectsEx with the MWMO_INPUTAVAILABLE flag set. This flag is defined to do exactly what we need. The only downside is that this flag does not exist on NT4 and its usage results in an invalid argument error. So, for NT4, I added the workaround I described in my yesterday's soliloquy. I'm planning to release Cygwin 1.7.7 tomorrow at the latest, so please give it a test as soon as possible. Here's a binary DLL for testing (build w/o optimization, so it's probably a bit slow): http://cygwin.de/cygwin-177/new-cygwin1.dll.bz2 (md5sum: 7e07fd9eafd021697a0861c1ae4fa94e) Thanks Corinna :-) I tried that cygwin DLL with my test case, and with an X server with what I now realize is the workaround I'd applied reverted [1] and it seems to work fine. [1] http://cgit.freedesktop.org/~yselkowitz/xserver/commit/?h=cygwin-release-1.8id=6da3190eacae2c2b021060f8fd9427816ac06f21 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 12/08/2010 17:07, Jon TURNEY wrote: On 12/08/2010 16:49, Ryan Johnson wrote: On 8/12/2010 5:46 PM, Jon TURNEY wrote: On 10/08/2010 06:48, Ryan Johnson wrote: On 8/10/2010 12:02 AM, Jon TURNEY wrote: On 09/08/2010 22:14, Ryan Johnson wrote: When I detached the monitor to leave the office, X disappeared with signal 11 (log attached). Oddly, the log file didn't mention -resize as an argument to XWin, but it did attempt to resize so I assume the feature was active. Oh dear. Well it seems I only thought I added code to only enable resize support in multiwindow mode when requested, so it's always on for multiwindow mode at the moment. That wouldn't be so bad, but it also seems that the -resize code completely fails to correctly handle a change of colour depth (e.g. from 32 bits to 16 bits or vice versa) leading to this segfault. Unfortunately, fixing this looks to be quite complex :-( Thanks for testing, anyhow :-) So... does that mean I have to roll back or face a seg fault after every commute? Or is there a way to explicitly disable it? I'm afraid so. As I say, I meant to add a means to disable -resize in -multiwindow mode to avoid exactly this kind of situation. Since it's the transition from 32bpp to 16bpp which breaks this, one possible workaround would be to run your large monitor at 16bpp, which might also give you working resize. Okay, I think I have worked out the correct thing to do do to handle bpp changes in the RANDR code, and I've uploaded a test build at [1]. Perhaps you could try it and see if it works for you? Note that you will need to use -resize with this build to turn on RANDR in any mode. If you can make this crash, with or without -resize, a backtrace would be very helpful. [1] ftp://cygwin.com/pub/cygwinx/XWin.20100831-git-5fa9c90425fb1d68.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xwin -multiwindow puts glass pane over windows taskbar
On 16/08/2010 11:57, Ryan Johnson wrote: The latest versions of the X server put a glass pane over the windows taskbar -- you have to click on it and then wait several seconds before it responds and gets out of the way. This seems related to the previous problem of generally slow response to key presses... Has anyone else run into this? I don't see any behaviour like that, and I can't really visualize what you are describing. Can you upload some screenshots somewhere? Facts which might be relevant: - do you have the taskbar set to autohide? - what version of Windows are you using? - is this the same problem as you mentioned at [1]? [1] http://cygwin.com/ml/cygwin-xfree/2010-08/msg00011.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 01/09/2010 11:14, Ryan Johnson wrote: On 8/31/2010 7:00 PM, Jon TURNEY wrote: Okay, I think I have worked out the correct thing to do do to handle bpp changes in the RANDR code, and I've uploaded a test build at [1]. Perhaps you could try it and see if it works for you? Note that you will need to use -resize with this build to turn on RANDR in any mode. If you can make this crash, with or without -resize, a backtrace would be very helpful. [1] ftp://cygwin.com/pub/cygwinx/XWin.20100831-git-5fa9c90425fb1d68.exe.bz2 I'll give that a try in the next couple of days. Meanwhile, what kind of backtrace did you mean? Is the .exe.stackdump actually helpful? In theory I believe it's possible to get something from a .stackdump file using addr2line, but a backtrace from gdb is much better. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: No xauth program
On 01/09/2010 20:29, Scott T. Marshall wrote: when I connect using ssh -Yv localhost the last few lines of output are: debug1: Entering interactive session. debug1: No xauth program. Warning: No xauth data; using fake authentication data for X11 forwarding. debug1: Requesting X11 forwarding with authentication spoofing. debug1: Remote: No xauth program; cannot forward with spoofing. Last login: Wed Sep 1 15:03:40 2010 from ::1 I don't understand the No xauth program part. I have xauth in /bin which xauth returns /usr/bin/xauth and when I check the permissions on xauth, I see that they are 755 and I am the owner. You might like to try if xauth can actually run successfully? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: No xauth program
On 9/2/2010 11:11 AM, Jon TURNEY wrote: On 01/09/2010 20:29, Scott T. Marshall wrote: when I connect using ssh -Yv localhost the last few lines of output are: debug1: Entering interactive session. debug1: No xauth program. Warning: No xauth data; using fake authentication data for X11 forwarding. debug1: Requesting X11 forwarding with authentication spoofing. debug1: Remote: No xauth program; cannot forward with spoofing. Last login: Wed Sep 1 15:03:40 2010 from ::1 I don't understand the No xauth program part. I have xauth in /bin which xauth returns /usr/bin/xauth and when I check the permissions on xauth, I see that they are 755 and I am the owner. You might like to try if xauth can actually run successfully? On 02/09/2010 18:56, Scott T. Marshall wrote: Thanks for the suggestion Jon. I don't know exactly what I should ask xauth to do or what syntax is requires (the man page was not completely clear to me), but what I can say is that if I try to execute xauth in an xterm, it gives no errors. I can also say that when I ssh to other linux machines, I can open X applications, but my cygwin/windows 7 x64 box will not forward x windows when someone log onto it. Hmm... it looks like the latest openssh package has the wrong default path to xauth for some reason. As a workaround, you might try adding XAuthLocation=/usr/bin/xauth to /etc/sshd_config and restarting sshd. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XServer draws to incorrect window when using VirtuaWin
On 03/09/2010 10:01, Pete wrote: On 13 August 2010 11:38, Petesneakypet...@gmail.com wrote: VirtuaWin (http://virtuawin.sourceforge.net/) is a virtual desktop manager for Windows that lets you switch between several virtual desktops, similar to those provided in KDE Gnome. When switching between desktops that have CygwinX windows open, occasionally the Xserver draws to the wrong window. This is difficult to describe, so will continue with an example: I'm afraid I think this falls into the category of known problems, see [1]. The tricks that XWin uses to implement multiwindow mode don't seem to be compatible with the tricks that VirtuaWin uses to implement multiple desktops. [1] https://bugs.freedesktop.org/show_bug.cgi?id=21540 Using Windows 7, Cygwin/X v1.8.0 Steps to reproduce: 1) Install VirtuaWin from http://virtuawin.sourceforge.net/ 2) Start the CygwinX server 3) Open a (DOS) cygwin window 4) Type xterm twice, to open two xterm windows. Maximise these two windows to full screen. 5) Move one of these windows to desktop2 6) Type ping google.com -n 1000 to get a stream of data appearing in the xterm window on desktop2 7) Go back to desktop1, and make sure the DOS cygwin window is selected 8) Switch back to desktop2. The ping xterm window should be selected. 9) Switch back to desktop1. The cygwin window should be selected. What should happen: The empty xterm session on desktop1 should be displayed in the window behind the cygwin window What happens: The ping data stream appears in the xterm window on desktop1, and continues receiving updates every second. Selecting the xterm window causes the ping data to disappear and the empty xterm session to be displayed correctly. This is reproducible every time. The critical thing is that if the xterm window on desktop1 is not selected after a desktop switch, it shows the data from the xterm window on desktop 2. FWIW, this problem doesn't exist with xming, and I haven't seen the issue with any other applications. Xming version number, please? Is there anything else I can do to help debug this? Unfortunately it is necessary to install VirtuaWin to reproduce the issue, but it's very reproducible. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 04/09/2010 00:10, Ryan Johnson wrote: On 8/31/2010 7:00 PM, Jon TURNEY wrote: Okay, I think I have worked out the correct thing to do do to handle bpp changes in the RANDR code, and I've uploaded a test build at [1]. Perhaps you could try it and see if it works for you? Note that you will need to use -resize with this build to turn on RANDR in any mode. If you can make this crash, with or without -resize, a backtrace would be very helpful. [1] ftp://cygwin.com/pub/cygwinx/XWin.20100831-git-5fa9c90425fb1d68.exe.bz2 So far so good... I've switched monitors several times without problems (both with -resize and without). Good news, thanks for testing! :-) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Keyboard layout is not automatically detected.
On 14/09/2010 09:15, Ozgur Murat Homurlu wrote: My keyboard layout is not automatically detected. Relevant info according to your FAQ is below: /var/log/XWin.0.log : [ 4704.046] (--) Windows keyboard layout: 041F (041f) Turkish Q, type 4 [ 4704.046] (EE) Keyboardlayout Turkish Q (041F) is unknown, using X server default layout setxkbmap tr command fixes layout problem. Thanks for reporting this, and the information necessary to fix it Patch to follow to add automatic detection for Turkish Q and Turkish F keyboard layouts Hopefully, this should get added to the next X server release -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[PATCH] Cygwin/X: Add turkish keyboard layouts to keyboard layout mapping table
0x041f Turkish Q = layout tr
0x0001041f Turkish F = layout tr variant f
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
hw/xwin/winlayouts.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/hw/xwin/winlayouts.h b/hw/xwin/winlayouts.h
index f5397e3..d7a9f27 100644
--- a/hw/xwin/winlayouts.h
+++ b/hw/xwin/winlayouts.h
@@ -81,6 +81,8 @@ WinKBLayoutRec winKBLayouts[] =
{ 0x816, -1, pc105, pt, NULL, NULL, Portuguese (Portugal)},
{ 0x41a, -1, pc105, hr, NULL, NULL, Croatian},
{ 0x41d, -1, pc105, se, NULL, NULL, Swedish (Sweden)},
+{ 0x41f, -1, pc105, tr, NULL, NULL, Turkish (Q)},
+{0x1041f, -1, pc105, tr, f, NULL, Turkish (F)},
{ 0x424, -1, pc105, si, NULL, NULL, Slovenian},
{ 0x425, -1, pc105, ee, NULL, NULL, Estonian},
{ 0x452, -1, pc105, gb, intl, NULL, United Kingdom
(Extended)},
--
1.7.1
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: Latest Cygwin X hangs when mouse is used to highlight text
On 14/09/2010 18:51, Brian Kelly wrote: I've been using Cygwin X trouble-free for years, and am running the latest distribution of X and the Cygwin1.dll for at least two weeks (since the Cygwin 1.7.7.1 release). It's been fine until this morning when it started locking on me whenever I used the mouse to highlight text. I have NO IDEA what changed on my system to now cause this behavior. **ANY** help you can give to assist me would be most appreciated since I use it for all my development efforts. This is very likely to be some sort of problem with the clipboard integration code. You might find that using the '-noclipboard' option works around the problem (at the cost of not being able to cut/paste between Windows and X apps). An xserver log with '-logverbose 3' might shed a bit more light on what's going on. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Latest Cygwin X hangs when mouse is used to highlight text
On 14/09/2010 20:52, Brian Kelly wrote: Thanks Jon for the quick reply. I attached a new log file generated with an attempt to highlight - followed by the hang. Can you please attach an X server log generated with the additional server option '-logverbose 3' Can you be more detailed about what you mean by a 'hang'? Does just the X server application become unresponsive? or your whole system? Again, this worked PERFECTLY just yesterday. I understood the first time. I would suggest that something has changed on your system to cause this change in behaviour, but you are best placed to find out what that is. -Original Message- From: Jon TURNEY Sent: Sep 14, 2010 1:47 PM Subject: Re: Latest Cygwin X hangs when mouse is used to highlight text On 14/09/2010 18:51, Brian Kelly wrote: I've been using Cygwin X trouble-free for years, and am running the latest distribution of X and the Cygwin1.dll for at least two weeks (since the Cygwin 1.7.7.1 release). It's been fine until this morning when it started locking on me whenever I used the mouse to highlight text. I have NO IDEA what changed on my system to now cause this behavior. **ANY** help you can give to assist me would be most appreciated since I use it for all my development efforts. This is very likely to be some sort of problem with the clipboard integration code. You might find that using the '-noclipboard' option works around the problem (at the cost of not being able to cut/paste between Windows and X apps). An xserver log with '-logverbose 3' might shed a bit more light on what's going on. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin crash after the launch of startkde on a remote Red Hat 5 machine
On 18/09/2010 19:44, michel hummel wrote: I have checked the code of the clipboard thread and the race condition you talk about should not be a problem. Before to start a new clipboard thread, the code waits for the end of the first thread (pthread_join) then fixe the variable g_fClipboardLaunched = FALSE; g_fClipboardStarted = FALSE; So the new thread will never be launched before the old one has terminated. I have a proposition of modification to make the clipboard thread more robust. 1/ Adding a cleanup function which will be automaticaly called at the end of the thread. I purpose the use of the macro pthread_cleanup_push() pthread_cleanup_pop() 2/ You said that having a long-lived thread will be a good solution to simplify the code. I have an other proposition which needs less modification and can simplify the code : By using also here the macro pthread_cleanup_push() we can automaticaly restart the thread on every unexpected exit. We just have to delete this restart when the exit is expected (ie. End of the function) With this solution we don't have to take care about the thread being killed by anyone, it will be restarted. You will need to have some kind of back-off mechanism (i.e. a delay before retrying to connect) so that that this doesn't constantly try to connect if the server gets into a state where it can't accept the connection or the connection is constantly getting closed. 3/ An other thing I saw is that when the Xwindow part of the clipboard is killed by an other application, the thread will still be alive but the clipboard doesn't work anymore. A solution can be : when an winClipboardErrorHandler() is catched, check for this Xwindow window and whenever this window doesn't exist anymore, create a new one. Would it not be simpler to restart the clipboard thread in this situation as well, rather than having code to recrate the window? What do you think about my suggestions ? I tested them and they seem to work as expected. For example, I skipped the wrapper of XQueryTree (actualy needed for xdmcp) and the clipboard is now working with xdmcp/gdm, etc. If you don't like something in my propositions, please tell me what and I will try to adapt it. If you are interested in a patch doing this, I will be happy to give it after a quick review and a clean That would be great, thank you. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: CygwinX at MS Terminalserver?
On 27/08/2010 16:52, Jon TURNEY wrote: On 16/08/2010 07:35, Steffen Sledz wrote: Am 13.08.2010 13:09, schrieb Jon TURNEY: Now testuser0002 tries to start another server in parallel. This gives this error: /usr/bin/startxwin: Resource temporarily unavailable (errno 11): Another X server instance is running on DISPLAY :0 This is expected. As I said, each X server instance must have a unique display number. This can't possibly work any other way. If two users both have an X server with display number 0, to which server should a client started with DISPLAY=:0.0 connect? That's clear. I thought (or hoped) that starting X server using the XWin Server menu item automatically searches for an unused display number and uses it. I think that would be a good default behaviour. I agree it would be useful, and it is on the todo list [1], but there's a non-trivial problem to solve first: How is the display number which the server has allocated communicated to other processes, so that the users clients appear on the right display? The fedora -displayfd patch seems to have moved and now lives at [1] I've built an Xserver including an updated and modified version of this patch and uploaded it at [2]. Perhaps you could give that a try and see if it works for your purposes? -displayfd fd specifies a file descriptor in the launching process. Rather than specify a display number, the X server will attempt to listen on successively higher display numbers, and upon finding a free one, will write the display number back on this file descriptor as a newline-terminated string. The -pn option is ignored when using -displayfd. If you start the X server first and then launch everything from the traymenu, everything would works fine, as the X server places a correct DISPLAY variable into the environment inherited by the child process. But if you start the X server via xinit/startx/startxwin, the display number needs to be communicated back to xinit, so that the correct display number is used for clients which are subsequently started by xinit. I've also patched xinit/startxwin so they transparently handle the -displayfd X server option, uploaded at [3],[4]. They handle the -displayfd option specially to modify the fd number passed to the Xserver so they can read it's output and set the display number correctly for clients which xinit/startxwin starts, then write that display number to the originally specified fd. (Patch to follow. Note that this patch probably won't apply to a stock xinit-1.2.1 as it's based on top of the patch which adds startxwin) Fedora ships with a patch [2] which adds the -displayfd option, which allocates a display number and writes it to the specified fd. But to be useful to us, xinit would needs some code to use that flag (under some circumstances) and read that display number and use it for the clients it creates. There's also the case where the user explicitly sets DISPLAY programmatically or manually before starting clients. I think with some suitable shell scripting, -displayfd probably can be used for that also. Something along the lines of adding '-displayfd 3 3~/.display' to the Xserver invocation, and then 'export DISPLAY=:`cat ~/.display`' to ~/.bashrc might be sufficient. [1] http://x.cygwin.com/devel/todo.html [2] http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-server/xserver-1.6.0-displayfd.patch [1] http://pkgs.fedoraproject.org/gitweb/?p=xorg-x11-server.git;a=tree [2] ftp://cygwin.com/pub/cygwinx/XWin.20100916-git-df5773ea3927d9c1.exe.bz2 [3] ftp://cygwin.com/pub/cygwinx/startxwin.exe [4] ftp://cygwin.com/pub/cygwinx/xinit.exe -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[PATCH] os: Add -displayfd option.
This option specifies a file descriptor in the launching process. X
will scan for an available display number and write that number back to
the launching process, at the same time as SIGUSR1 generation. This
means display managers don't need to guess at available display numbers.
As a consequence, if X fails to start when using -displayfd, it's not
because the display was in use, so there's no point in retrying the X
launch on a higher display number.
Signed-off-by: Adam Jackson a...@redhat.com
Update for current X server
Fix null DISPLAY crash when stderr is closed
Rearrange init order to avoid null DISPLAY crash and correctly use
DISPLAY in default logfile name when logfile isn't specified on command line
Don't put '\'n on end of DISPLAY so internal XWin uses work correctly
Do a bit more logging about what we are trying to do
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
dix/globals.c|1 +
dix/main.c |7 +++-
doc/Xserver.man.pre |7
hw/xwin/InitOutput.c | 10 +++---
include/opaque.h |1 +
os/connection.c | 75 ++---
os/osinit.c |4 +-
os/utils.c | 11 +++
8 files changed, 84 insertions(+), 32 deletions(-)
diff --git a/dix/globals.c b/dix/globals.c
index c24a94f..19168f4 100644
--- a/dix/globals.c
+++ b/dix/globals.c
@@ -134,6 +134,7 @@ int defaultColorVisualClass = -1;
int monitorResolution = 0;
char *display;
+int displayfd;
char *ConnectionInfo;
CARD32 TimeOutValue = DEFAULT_TIMEOUT * MILLI_PER_SECOND;
diff --git a/dix/main.c b/dix/main.c
index f023536..4e0ec93 100644
--- a/dix/main.c
+++ b/dix/main.c
@@ -168,8 +168,7 @@ int main(int argc, char *argv[], char *envp[])
DPMSPowerLevel = 0;
#endif
InitBlockAndWakeupHandlers();
- /* Perform any operating system dependent initializations you'd like */
- OsInit();
+
if(serverGeneration == 1)
{
CreateWellKnownSockets();
@@ -183,6 +182,10 @@ int main(int argc, char *argv[], char *envp[])
}
else
ResetWellKnownSockets ();
+
+ /* Perform any operating system dependent initializations you'd like */
+ OsInit();
+
clients[0] = serverClient;
currentMaxClients = 1;
diff --git a/doc/Xserver.man.pre b/doc/Xserver.man.pre
index ce3b3a1..a6bd906 100644
--- a/doc/Xserver.man.pre
+++ b/doc/Xserver.man.pre
@@ -121,6 +121,13 @@ Not obeyed by all servers.
.B \-core
causes the server to generate a core dump on fatal errors.
.TP 8
+.B \-displayfd \fIfd\fP
+specifies a file descriptor in the launching process. Rather than specify
+a display number, the X server will attempt to listen on successively higher
+display numbers, and upon finding a free one, will write the display number
back
+on this file descriptor as a newline-terminated string. The \-pn option is
+ignored when using \-displayfd.
+.TP 8
.B \-deferglyphs \fIwhichfonts\fP
specifies the types of fonts for which the server should attempt to use
deferred glyph loading. \fIwhichfonts\fP can be all (all fonts),
diff --git a/hw/xwin/InitOutput.c b/hw/xwin/InitOutput.c
index b144136..295c010 100644
--- a/hw/xwin/InitOutput.c
+++ b/hw/xwin/InitOutput.c
@@ -700,13 +700,13 @@ OsVendorInit (void)
if (!g_fLogInited) {
/* keep this order. If LogInit fails it calls Abort which then calls
- * ddxGiveUp where LogInit is called again and creates an infinite
- * recursion. If we set g_fLogInited to TRUE before the init we
- * avoid the second call
- */
+ * ddxGiveUp where LogInit is called again and creates an infinite
+ * recursion. If we set g_fLogInited to TRUE before the init we
+ * avoid the second call
+ */
g_fLogInited = TRUE;
g_pszLogFile = LogInit (g_pszLogFile, NULL);
- }
+ }
LogSetParameter (XLOG_FLUSH, 1);
LogSetParameter (XLOG_VERBOSITY, g_iLogVerbose);
LogSetParameter (XLOG_FILE_VERBOSITY, g_iLogVerbose);
diff --git a/include/opaque.h b/include/opaque.h
index b3c7c70..ea0ac13 100644
--- a/include/opaque.h
+++ b/include/opaque.h
@@ -50,6 +50,7 @@ extern _X_EXPORT int ScreenSaverAllowExposures;
extern _X_EXPORT int defaultScreenSaverBlanking;
extern _X_EXPORT int defaultScreenSaverAllowExposures;
extern _X_EXPORT char *display;
+extern _X_EXPORT int displayfd;
extern _X_EXPORT int defaultBackingStore;
extern _X_EXPORT Bool disableBackingStore;
diff --git a/os/connection.c b/os/connection.c
index 85d0d10..9712729 100644
--- a/os/connection.c
+++ b/os/connection.c
@@ -146,6 +146,7 @@ Bool NewOutputPending; /* not yet attempted to
write some new output */
Bool AnyClientsWriteBlocked; /* true if some client blocked on write */
static Bool RunFromSmartParent;/* send SIGUSR1 to parent process */
+static char dynamic_display[7];
Bool PartialNetwork; /* continue even if unable to bind all addrs */
static Pid_t ParentProcess;
@@ -374,9 +375,25
[PATCH] Handle X server -displayfd option transparently
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
xinit.c | 68 +++---
1 files changed, 60 insertions(+), 8 deletions(-)
diff --git a/xinit.c b/xinit.c
index 918f83e..95ba13c 100644
--- a/xinit.c
+++ b/xinit.c
@@ -168,6 +168,11 @@ int serverpid = -1;
int clientpid = -1;
volatile int gotSignal = 0;
+static int original_displayfd = -1;
+static int server_displayfd_read = -1;
+static char server_displayfd_write[256];
+static char displayfd_buf[256];
+
static void Execute ( char **vec, char **envp );
static Bool waitforserver ( void );
static Bool processTimeout ( int timeout, char *string );
@@ -319,14 +324,40 @@ main(int argc, char *argv[], char *envp[])
}
if (argc 0 (argv[0][0] == ':' isdigit(argv[0][1])))
displayNum = *argv;
- else
- displayNum = *sptr++ = default_display;
start_of_server_args = (sptr - server);
while (--argc = 0) {
+ /* Handle the -displayfd server argument transparently */
+ if ((argc 0) (strcmp(argv[0],-displayfd) == 0))
+ {
+int filedes[2];
+
+original_displayfd = atoi(argv[1]);
+
+if (pipe(filedes) == 0)
+ {
+server_displayfd_read = filedes[0];
+sprintf(server_displayfd_write, %d, filedes[1]);
+argv[1] = server_displayfd_write;
+ }
+else
+ {
+Fatal(pipe() for -displayfd failed);
+ }
+ }
+
server_args_given++;
*sptr++ = *argv++;
}
+
+/*
+ if there was neither an explicit displayNum nor a
+ -displayfd option, add the default display number
+ to server arguments
+*/
+if ((displayNum == NULL) (original_displayfd == -1))
+ displayNum = *sptr++ = default_display;
+
#ifdef STARTXWIN
*sptr++ = -multiwindow;
#endif
@@ -391,11 +422,6 @@ main(int argc, char *argv[], char *envp[])
#endif
/*
-* put the display name into the environment
-*/
- set_environment ();
-
- /*
* Start the server and client.
*/
#ifdef SIGCHLD
@@ -423,7 +449,7 @@ main(int argc, char *argv[], char *envp[])
#endif
#endif
- if (XOpenDisplay(displayNum)) {
+ if (displayNum XOpenDisplay(displayNum)) {
Error(Another X server instance is running on DISPLAY %s\r\n,
displayNum);
exit(ERR_EXIT);
}
@@ -487,6 +513,32 @@ waitforserver(void)
sleep(2);
#endif
+if (server_displayfd_read != -1)
+ {
+/* wait for the server to write the DISPLAY number to the
displayfd pipe */
+int length;
+
+displayfd_buf[0] = ':';
+length = read(server_displayfd_read, displayfd_buf+1, 255);
+
+if (length 0)
+ Fatal(reading displayfd pipe failed);
+displayfd_buf[length] = '\0';
+
+printf(read display number '%s' from X server\n, displayfd_buf);
+displayNum = displayfd_buf;
+
+/* write the DISPLAY received from the server to the original
displayfd */
+/* XXX: this should happen after connections are being accepted */
+write(original_displayfd, displayfd_buf+1, length);
+write(original_displayfd, \n, 1);
+ }
+
+ /*
+* put the display name into the environment
+*/
+ set_environment ();
+
for (cycles = 0; cycles ncycles; cycles++) {
if ((xd = XOpenDisplay(displayNum))) {
return(TRUE);
--
1.7.1
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: Problems using XWin with remote desktop with latest version
On 20/09/2010 19:52, Jay Goldman wrote: I have the following batch file to start xwin: @echo off SET CYGWIN_ROOT= SET RUN=%CYGWIN_ROOT%\bin\run -p /usr/bin SET PATH=.;%CYGWIN_ROOT%\bin;%PATH% SET XAPPLRESDIR= SET XCMSDB= SET XKEYSYMDB= SET XNLSPATH= %RUN% XWin -multiwindow -clipboard -silent-dup-error IF EXIST %CYGWIN_ROOT%\bin\urxvtd-X.exe %RUN% %CYGWIN_ROOT%\bin\urxvtd-X.exe This works fine (and has been for a whileyear). Occasionally, I have to connect to my machine via windows remote desktop. I've also been doing this for a while. With the latest version of x-windows; however, when I do so XWin.exe seg faults. I then kill the urxvtd-X.exe process, re-run my batch script, and all is well within the remote desktop session. Then I close the remote desktop session, and when I get back to my machine the x-windows-based command windows are no longer functional. I close down Xwin.exe (and urxvtd-X.exe), restart them, and I'm ok again. Any ideas as to what has changed to cause these new issues, (a) XWin.exe seg fault due to remote desktop connection (sorry, I don't have the seg fault info) (b) X-windows based command windows, (i.e., windows started with: urxvtc -g 80x42 -e /bin/bash -l -i) no longer display correctly when I disconnect the remote desktop session - I have to 're-start' xwin.exe (and urxvtd-X.exe) processes. This is pretty likely to be a known problem with the resize support added in Xserver 1.8.2-1, see [1] Unfortunately, due to a mistake on my part, there is no way to disable resize support in multiwindow mode in that version, so your options for a workaround are limited to: a) Downgrade to the previous Xserver version b) Use the test build provided by me in that thread c) Avoid RDP sessions which change the colour depth of your display (e.g by setting your display to use 16-bit colour, assuming the RDP sessions choose 16-bit for some reason) If your problems persist with the that test build, I'd very much like to hear about it. [1] http://cygwin.com/ml/cygwin-xfree/2010-08/msg00080.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin crash after the launch of startkde on a remote Red Hat 5 machine
On 22/09/2010 10:03, Michel Hummel wrote: Hello, I've modified my patch, to change the restart process. It does not use anymore the winProcEstablishConnection wrapper to restart the clipboard but directly the winInitClipboard function. This allows to restart the clipboard more quickly and if the clipboard thread cannot connects to the server (there is a loop on connection with a delai between retries), it will die. One question : I have written my patch for the git version of the X server and the patch is not working as it on the 1.8.0-1 version. Which version would you like, perhaps the two ? A patch against current git master is fine, although I don't think there have been significant changes in this area recently, so why it doesn't work for 1.8.0-1 as well is mysterious. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin.exe parms wrapped by startwin.exe
On 22/09/2010 18:11, Fouts, Christopher wrote: I want to run XWin much like startwin does, but with extra parameters (-logfile). What is the exact command+parms line that startwin executes to run XWin? So... Startwin.exe = Xwin.exe parm1 parm2 parm3 etc What are parm1, parm2, parm3, etc...? Hmm... It's a bit of an omission from the startxwin man page [1], that it doesn't actually tell you it's adding '-multiwindow' However, reading that man page does tell you the syntax for adding extra server arguments (e.g. -- -logfile file) to your startxwin invokation. Note that invoking the server directly will not do the other things that startxwin does (i.e. waiting until the server is started and then executing ~/.startxwinrc) In future, please start a new email thread, rather than replying to an existing one and changing the subject. [1] http://x.cygwin.com/docs/man1/startxwin.1.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 21/09/2010 23:06, Eliot Moss wrote: Dear John -- Using the .bz2 you posted to this thread on Sept 7th or so, I consistently get SIGSEGV on my Windows-7 box whenever I Sleep or Hibernate the system. I include the .log file for your Thanks for reporting this issue. Does the crash also occur if you don't use -resize? consideration, and the stderr output. Earlier versions seemed to do ok. Is there a simple procedure for winding back? If you've installed my snapshot as XWin.exe, the easiest way to get the 1.8.2-1 version back is to reinstall it using setup. [snip] [332511.061] winClipboardFlushXEvents - unexpected event type 34 [332532.557] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332533.556] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332534.554] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332535.553] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332536.551] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332537.550] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332538.564] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332539.578] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332547.237] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332549.343] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332549.343] winShadowUpdateDDNL - IDirectDrawSurface4_Blt failure message maximum (10) reached. No more failure messages will be printed. [332550.700] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [332550.700] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [332550.700] winCreatePrimarySurfaceShadowDDNL - Could not create primary surface: 8876024e [332550.700] Segmentation fault at address 0x0 [332550.700] Fatal server error: [332550.700] Caught signal 11 (Segmentation fault). Server aborting [332550.700] Unfortunately, I can't reproduce this on my Win7 system, although it is quite possible that this is specific to the display driver or hardware. If you can use gdb to generate a backtrace for this segfault, that would be most helpful. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Cygwin/X bug? suspend-resume issues
On 22/09/2010 02:27, Henry Tung wrote: I've encountered an unusual behavior of Cygwin/X on suspend/resume of Windows. The server is working fine before suspend, but after the first suspend-resume cycle, the characters become single pixels. I have screenshots depicting the effects on an rxvt-unicode window, and an fwbuilder window forwarded over ssh from an Ubuntu VM (though it seems the mailing list rejected the attachments, so please let me know if there's a way I can send them). Windows in existence before the first suspend remain fine after resume, but only as long as they are open; closing and reopening them produces the broken state. The attached XWin.0.log is after two suspend/resume cycles; the two line blocks from each resume seem anomalous (bpp: 0? width: 0? height: 0?). Thanks for reporting this issue. Would you mind trying the test snapshot [1] to see if this improves matters? You'll need to add the '-resize' option to the X server to reproduce your current behaviour (it is erroneously on all the time in multiwindow mode with 1.8.2-1) If that doesn't help, would you mind uploading a screenshot to your favourite image hosting service? I saw the stuff about the SIGSEGV, that's quite interesting. My X server hasn't segfaulted yet, but considering the usability, it might as well have. Since this seems to be related to the resize support added in 1.8.2-1, using setup.exe to revert to 1.8.0-1 should avoid these problems for the moment. [1] ftp://cygwin.com/pub/cygwinx/XWin.20100916-git-df5773ea3927d9c1.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 23/09/2010 14:29, Eliot Moss wrote: On 9/23/2010 9:10 AM, Jon TURNEY wrote: On 21/09/2010 23:06, Eliot Moss wrote: [I reported crash on resume after Suspend or Hibernate.] Does the crash also occur if you don't use -resize? Yes. Is there a simple procedure for winding back? If you've installed my snapshot as XWin.exe, the easiest way to get the 1.8.2-1 version back is to reinstall it using setup. Right; sorry I wasn't clear. I was trying the snapshot because 1.8.2-1 fails in the same way. What I meant was: Can I easily go back to a consistent set of X.org files some time *before* that .. I see, thanks for the clarification. You should use setup to revert to Xserver 1.8.0-1, then :-) Unfortunately, I can't reproduce this on my Win7 system, although it is quite possible that this is specific to the display driver or hardware. I have a Toshiba Portege M750. It has Intel Display drivers. But you know what, that got me thinking: I believe those drivers were updated recently and maybe I should try winding *them* back. If you can use gdb to generate a backtrace for this segfault, that would be most helpful. I understand gdb generally and all. Can you give a bit of guidance about how to start things (edits to startxwn.bat?) with gdb, to get you that back trace? You may find it easiest and most reliable to start XWin normally, and then (in a separate terminal window), use ps to identify the XWin processes PID, then use gdb --pid=pid to attach to the running XWin process, 'c' at the (gdb) prompt and then reproduce your crash... -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 23/09/2010 15:54, Eliot Moss wrote: So, some (good? but at least interesting) news: The version of the Intel GMA Drivers affects whether the bad behavior happens. These are GMA (Graphics Media Accelerator) drivers for Windows 7 / Vista x64 for the Intel 4 Series Express chipset. The releases are numbers 8.15.10., where is what I will use to distinguish each one. 2202 (most recent) fails 2189 (latest send around by Windows Update) fails 2182 I have not yet tested 2104 works! 2021 probably also works (did before), but not explicitly tested The good thing is that I can now work with less annoyance. The bad thing is that I can't use the latest drivers. Let me know if there is anything I can do to help push XWin forward in handling whatever new it is that the Intel drivers are doing. I've uploaded a new test build at [1] Hopefully this handles this error condition a bit more gracefully. Perhaps you could try it out? [1] ftp://cygwin.com/pub/cygwinx/XWin.20100923-git-2172af4d1ea713f1.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 23/09/2010 20:34, Eliot Moss wrote: On 9/23/2010 11:56 AM, Jon TURNEY wrote: I've uploaded a new test build at [1] Hopefully this handles this error condition a bit more gracefully. Perhaps you could try it out? [1] ftp://cygwin.com/pub/cygwinx/XWin.20100923-git-2172af4d1ea713f1.exe.bz2 Thank you, yes, that no longer causes a SIGSEGV. Thanks! Thanks for testing. There is a remaining issue -- which was there before but which I had not posted about. If I Suspend/Resume, then on resumption the driver disables the Aero theme and points its finger at XWin.exe as the culprit, saying it did something incompatible with Aero. You probably know about this stuff, but here's the overall blurb anyway: I can't reproduce this, so again, it seems to be driver-specific. I presume some DirectDraw errors are still emitted over a suspend/resume cycle? Can you attach an XWin.0.log showing them? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Failed to write cache during install
On 24/09/2010 01:50, Richard Gitschlag wrote: I recently set up Cygwin and XWin on my XP system, but need help with error messages that occured during post-install scripts. My setup log file shows: 2010/08/26 10:17:04 running: F:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/font-adobe-dpi75.sh 2010/08/26 10:17:18 abnormal exit: exit code=1 2010/08/26 10:17:18 running: F:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/font-alias.sh 2010/08/26 10:17:44 abnormal exit: exit code=1 2010/08/26 10:17:44 running: F:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/font-misc-misc.sh 2010/08/26 10:17:52 abnormal exit: exit code=1 2010/08/26 10:17:52 running: F:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/fontconfig.sh 2010/08/26 10:18:18 abnormal exit: exit code=8 Checking the verbose log shows a common theme of failed to write cache, e.g: 2010/08/26 10:17:04 running: F:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/font-adobe-dpi75.sh /usr/share/fonts/75dpi: failed to write cache My local cygwin directory resides on a FAT32 drive, if that is related. Made copies of my setup logs and can supply further information if needed. The command which is failing is 'fc-cache -f', and the cache files in question live in /var/cache/fontconfig. You might try running 'strace fc-cache -f' from a shell to see if that sheds any light on why these cache files apparently can't be written. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: gvim tiny font in 1.7.7
On 22/09/2010 16:34, David T-G wrote: Hi, all -- [Let's see if I can provide all of the details the first time instead of having to go back and forth just for foundation... :-] Can you attach your /var/log/XWin.0.log, please? I have used Cygwin for years and have been using the cygwin gvim (versus the Windows-native vim + gvim) for some time now. I had occasion to do a fresh install of 1.7.7 on a freshly-rebuilt laptop after a hard drive crash and so I don't think that I have any of the upgrade gotchas biting me, but stranger things have happened :-) When I first started gvim after my install, the font was invisibly tiny both for the content and for the menus. [Note that both xterm and rxvt-X are fine.] Using another computer to see where I was going and matching the keystrokes I attempted to set the font to Lucida Console 12 but found no change. I have manually (a bummer, but I gather from the FAQs that the lack of dependency linking is temporary) added the font-bh-dpi75 and font-bh-lucidatypewriter-dpi75 packages with no effect. I have set the guifont variable in my .vimrc file, and the tiny window was somewhat differently sized but still tiny. Finally, I have of course googled for cygwin +gvim +font (size or tiny) and similar to see what others have found, but I haven't matched anything more useful than the guifont setting. What do I need to fix and where to make my gvim readable? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Running Java application with drag and drop support in cygwin
On 20/09/2010 11:31, Dees wrote: Any update? On Wed, Dec 23, 2009 at 6:26 PM, Deesdeepali.shef...@gmail.com wrote: People, any clue? Struggling really hard. On Fri, Dec 18, 2009 at 11:23 AM, Deesdeepali.shef...@gmail.com wrote: Hi Jon, Did you get a chance to look at this? From whatever posts available online, I could not get a clue what is going wrong. Please respond. Thanks, Shefali On Mon, Dec 14, 2009 at 12:12 PM, Deesdeepali.shef...@gmail.com wrote: On Fri, Nov 13, 2009 at 8:26 PM, Jon TURNEYjon.tur...@dronecode.org.uk wrote: On 30/10/2009 09:06, Dees wrote: Your reply is much appreciated Jon. I will try to be more specific about the problem in further mails. On Thu, Oct 29, 2009 at 8:11 PM, Jon TURNEYjon.tur...@dronecode.org.uk wrote: On 28/10/2009 05:57, Dees wrote: I have developed a Java application involving jTree with extensive drag and drop support, which runs correctly in my Linux box. However, when I switch to a windows box and access the same Linux box using cygwin x-server, the drag and drop in jTree stops working. Interestingly, rest of the application still works fine. After analyzing a bit I found that x-server is able to recognize the drag event but fails to recognize a drop event. Details? OS : Suse Linux Enterprise Server 10 (i586) Version : 10 Patch level : 3 Other version information: Java : JDK 5 Cygwin setup-version: 2.573.2.3 Also tried using Xming 6.9.0.31 ssh same Linux setup from Windows, but that also doesn't solve the problem. Is there any setting, which should be done prior to running the Java swing applications? Here is a sample code which behaves in exactly same way. http://www.java2s.com/Code/Java/Swing-JFC/TreeDragandDrop.htm I have no idea how to use that java code to reproduce the problem you are seeing. Using the above java code in Linux: 1. Download and Install Java Development Toolkit on your Linux box (Java sun download site: http://java.sun.com/javase/downloads/index.jsp), if you do not have it already. 2. Save the sample code in the above link with the file name TreeTester.java, say in /home/user/ 3. Navigate to TreeTester.java from shell, and compile the java code: # cd /home/user/ # /usr/java/jdk1.5.0_14/bin/javac TreeTester.java Ignore any warnings of deprecated APIs. 4. This will create a few .class files in /home/user/ directory. Final step is to run the Java code, using: # /usr/java/jdk1.5.0_14/bin/java -classpath . TreeTester This will open up a GUI, with a jTree each on left and right pane. You can drag and drop any of the leaf nodes from one jTree to the root node of the other jTree and this should add a new node in the other jTree. You will get messages on console for the operations being performed. Now ssh the same box using cygwin/xming from any other windows box, and run the application using command in step 4. You should be able to drag (a small icon will come under cursor indicating that something is being dragged) but when you will drop it, the new node would not be added to the tree. Thats where lies my problem!!! Thanks for the test case and instructions, this makes it much easier for me to try it out. However, this testcase and your jar archive both work fine for me (using Xserver 1.7.1-3)! Given that the test case works for me, but not for you, I suspect this going to be another Java bug (e.g. [1],[2]), which is fixed in the JDK I am using. If this isn't fixed with the latest Xserver, I guess it might be possible to put another workaround into the Xserver, if I knew what the problem was, but since JDK 5 was EOL November 2009 [3], I'm not sure if it's worth the effort. Looking at that, you don't seem to be using the last update (update 22), either. [1] http://cygwin.com/ml/cygwin-xfree/2010-07/msg00034.html [2] http://sourceware.org/bugzilla/show_bug.cgi?id=9848 [3] http://www.oracle.com/technetwork/java/javase/downloads/index-jdk5-jsp-142662.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: fvwm ignores clickToFocus for function keys
On 26/09/2010 12:28, Charles Smith wrote: This conversation was transferred from the cygwin main list because Larry Hall said it was xfree-specific... From: Morgan Gangwere0 dot fractalus at gmail dot com Sounds like something is trashing a buffer... however I'm not entirely sure. ... Sounds oddly configuration related... then again, i don't use fvwm on windows. My suspicion is that it has to do with the cut-buffers/clip-board-mechanism, somehow. I'd said previously that what gets sent (when a function key is pressed but the mouse cursor isn't over the in-focus window) is the unmapped version of the function key. It might also be some earlier contents of the cut-buffer, or something like that. I'm still trying to track it down. Being able to cut-and-paste between windows and cygwin is important, and I'm glad that this evolving capability is so far along... but is it possible to disable it, at least for debugging purposes? 'man XWin' [1] documents the -noclipboard option. [1] http://x.cygwin.com/docs/man1/XWin.1.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Git version, XWin dies in cygwin but not in Windows
On 27/09/2010 16:43, Michel Hummel wrote: I am testing the git version of the XWin server (I don't know if it is the good place to talk about this version) This is absolutely the right place :-) I presume by 'git version' you mean the X.Org master tree. and I am experiencing a problem (May be it is also a problem on the official Xwin). Sometime ( I can not make a reproducible test case) when the server stops, the Xwin process disappears from Cygwin (as expected) but the Windows process XWin.exe still be alive. There are currently quite a few patches applied on top of the X.Org releases to make the cygwin released version (cygwin releases are tagged in [1]), at least one of which is related to stability during shutdown [5]. If you want a tree with those patches forward ported to xserver 1.9, take a look at [2] Sorry that the contributors guide documentation is somewhat out of date and doesn't contain this information. After some investigations (I'm not a good Windows hacker) it seems that the process hangs on the call to PostQuitMessage (0); of the function ddxGiveUp of the file InitOutput.c I can't tell why (Like I said, I'm not a good Windows hacker) but my tests seems to show that delete this call fixes the bug (may be there is no link ). Is it possible that this problem lies to the fact that the main window is destroyed before the call to PostQuitMessage (So the WM_QUIT message can't be treated isn't it ?) That shouldn't be the case, PostMessage() [3] functions are supposed to by asynchronous (unlike SendMessage() [4] which is synchronous, waiting for the message to be processed before returning) [1] http://cgit.freedesktop.org/~yselkowitz/xserver/ [2] http://cgit.freedesktop.org/~jturney/xserver/log/?h=cygwin-1.9-testing [3] http://msdn.microsoft.com/en-us/library/ms644945%28VS.85%29.aspx [4] http://msdn.microsoft.com/en-us/library/ms644950%28VS.85%29.aspx [5] http://cgit.freedesktop.org/~yselkowitz/xserver/commit/?h=cygwin-release-1.8id=9cbbc1e8aefc6111f6ccdc73c061337508061996 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin crashes with DirectX apps
-engine 2 (Shadow DirectDraw locking). At this point, I should mention yet another case: -engine 1 (Shadow GDI) has also been crashing all along with a backtrace that is somewhat similar to the ones seen with the patched DirectDraw engines. Here's that backtrace: (gdb) run -engine 1 The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/src/xorg-server-1.8.2-1/build/xwin-ddx/hw/xwin/XWin.exe -engine 1 [New thread 2920.0xb04] [New thread 2920.0xce4] warning: Lowest section in /cygdrive/c/WINDOWS/system32/wmi.dll is .text at 76d31000 [New thread 2920.0xf40] [New thread 2920.0x654] Program received signal SIGSEGV, Segmentation fault. 0x6fc4d707 in pixman_fill_sse2 (bits=0x2b9, stride=1280, bpp=32, x=0, y=0, width=640, height=0, data=0) at /usr/lib/gcc/i686-pc-cygwin/4.3.4/include/emmintrin.h:699 699 *__P = __B; (gdb) bt #0 0x6fc4d707 in pixman_fill_sse2 (bits=0x2b9, stride=1280, bpp=32, x=0, y=0, width=640, height=0, data=0) at /usr/lib/gcc/i686-pc-cygwin/4.3.4/include/emmintrin.h:699 #1 0x6fc651c5 in sse2_fill (imp=0x10087b78, bits=0x2b9, stride=320, bpp=32, x=0, y=0, width=640, height=480, xor=0) at /usr/src/pixman-0.18.2-1/src/pixman-0.18.2/pixman/pixman-sse2.c:5888 #2 0x6fb57724 in _pixman_implementation_fill (imp=0x10087b78, bits=0x2b9, stride=320, bpp=32, x=0, y=0, width=640, height=480, xor=0) at /usr/src/pixman-0.18.2-1/src/pixman-0.18.2/pixman/pixman-implementation.c:225 #3 0x6fb7cab5 in pixman_fill (bits=0x2b9, stride=320, bpp=32, x=0, y=0, width=640, height=480, xor=0) at /usr/src/pixman-0.18.2-1/src/pixman-0.18.2/pixman/pixman.c:864 #4 0x004492c7 in fbFill (pDrawable=0x10087f80, pGC=0x10086f80, x=0, y=0, width=640, height=480) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/fb/fbfill.c:48 #5 0x004474eb in fbPolyFillRect (pDrawable=0x10087f80, pGC=0x10086f80, nrect=0, prect=0x1011a8f0) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/fb/fbfillrect.c:77 #6 0x0052730b in damagePolyFillRect (pDrawable=0x10087f80, pGC=0x10086f80, nRects=1, pRects=0x1011a8e8) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/miext/damage/damage.c:1404 #7 0x005b1f44 in miPaintWindow (pWin=0x10087f80, prgn=0x10291c30, what=0) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/mi/miexpose.c:673 #8 0x005b1a5c in miWindowExposures (pWin=0x10087f80, prgn=0x10291c30, other_exposed=0x0) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/mi/miexpose.c:504 #9 0x005b76fd in miHandleValidateExposures (pWin=0x10087f80) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/mi/miwindow.c:246 #10 0x0042f874 in xf86SetRootClip (pScreen=0x1008c1c0, enable=1) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winrandr.c:164 #11 0x0042f9a9 in winDoRandRScreenSetSize (pScreen=0x1008c1c0, width=640, height=480, mmWidth=3435973836, mmHeight=1080233164) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winrandr.c:212 #12 0x0041a375 in winWindowProc (hwnd=0x1b02a0, message=126, wParam=16, lParam=31457920) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winwndproc.c:344 #13 0x7e418734 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll #14 0x001b02a0 in ?? () #15 0x007e in ?? () #16 0x0010 in ?? () #17 0x01e00280 in ?? () #18 0x00419bd8 in winReshapeRootless () #19 0x7e418816 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll #20 0x00419bd8 in winReshapeRootless () #21 0x7e428ea0 in USER32!DefWindowProcW () from /cygdrive/c/WINDOWS/system32/user32.dll #22 0x in ?? () (gdb) At this point I'm a bit stuck. It looks like fbFill might be passing an invalid pointer to pixman_fill, but the code is hard to follow due to macros and unfamiliar APIs so I don't know where the root problem is. I may continue to investigate. By the way, another backtrace similar to this one showed up in the mailing list archives from last month: http://cygwin.com/ml/cygwin-xfree/2010-08/msg00068.html These pixman crashes are possibly the result of trying to draw outside the screen pixmap. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.9.0-1 (TEST)
The following packages have been updated in the Cygwin distribution: *** xorg-server-1.9.0-1 *** xorg-server-dmx-1.9.0-1 This package contains XWin and the other X.Org X11 servers. This is the first official release of the xserver 1.9 series. It is currently available as a test release, and will be made stable in approximately one week if no major regressions are reported. In addition to the usual upstream fixes and improvements, this contains the following cygwin-specific changes: * fix a drawing crash, which could occur after moving a window in multiwindow mode, caused by incorrect initialization of composite position data * fix a clipboard-related crash which could occur during XDMCP session startup (thanks to Michel Hummel for the patch) * added Turkish keyboard layout detection * add -displayfd option (experimental), which may be useful in Terminal Server environments, see [1] for a discussion of how and why you might want to use this * various crash fixes for -resize. Also fix -resize from turning itself on in multiwindow mode even when not asked for. -resize will be enabled by default in multiwindow mode after more testing. * enable WGL AIGLX code and -wgl option which has been merged upstream, and various GLX fixes Server-side Hardware Accelerated OpenGL (AIGLX) === This release adds experimental support for hardware accelerated OpenGL rendering in the X server using the native WGL interface. * You need to provide the command line option '-wgl' to the X server to turn on the use of native Windows OpenGL to implement GLX. If you don't use this option, the server will carry on using software rendering. * The currently shipped cygwin mesa libGL is built in such a way that it does not support indirect rendering (rendering takes place on the server), only client-side rendering. ONLY REMOTE CLIENTS FROM UNIX SYSTEMS WILL WORK CURRENTLY. An updated libGL will be made available at some point in the future. * mesa's libGL prefers to use client-side rendering and transfer the image to the server using xlib. To force the use of GLX, so rendering is indirect (takes place on the server), and thus can be accelerated, you must export the environment variable LIBGL_ALWAYS_INDIRECT with a non-zero value before starting the client application. * If you have set things up successfully, 'glxinfo | grep OpenGL' should return something mentioning your graphics card vendor. If it mentions Mesa, you still have software rendering * As before, only multiwindow/mwextwm modes are supported. Software rendering is always used on screens which do not have 1 native window per X window. Removing this restriction requires a way to tell the native OpenGL to transform/clip to the portion of the native window occupied by the X window in the single native window modes. [1] http://cygwin.com/ml/cygwin-xfree/2010-09/msg00040.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Updated: xorg-server-1.9.0-1 (TEST)
On 30/09/2010 20:03, michel hummel wrote: Hi jon, I was surprised to see in the Changelog of this test release : * fix a clipboard-related crash which could occur during XDMCP session startup (thanks to Michel Hummel for the patch) It would be very cool if this version included my patch about xdmcp and clipboard auto-restart but I don't think so, isn't it ? I think this version only includes the patch about : clipboard crash on server reset isn't it ? Just the first patch, I'm afraid. The second one needs a bit more looking at, I think. Thanks for your work, Michel Hummel Thanks for the patch! :-) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.9.0-2 (TEST)
The following packages have been updated in the Cygwin distribution: *** xorg-server-1.9.0-2 *** xorg-server-dmx-1.9.0-2 This package contains XWin and the other X.Org X11 servers. A new 1.9 release candidate has also been made available as a test release. This will be made stable in approximately one week if no major regressions are reported. This contains the following cygwin-specific changes: - Fix a regression with window placement: Windows which remember their position were drifting towards the bottom-right with each appearance - Move log files from /var/log to /var/log/xwin, which is created mode 0777, to avoid logging failures in multiuser setups Mentions of /var/log/XWin.0.log in the documentation will be updated to say /var/log/xwin/XWin.0.log after this release is made stable. Additional documentation for the experimental WGL mode: * OpenGL drawing to an X window which is not a top-level window is not yet implemented. * Please ensure you are using the latest display drivers for your hardware before reporting any visual issues with WGL. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Windows are openings on the second monitor
On 07/10/2010 02:10, baykus derki wrote: I am having an annoyance regarding dual monitors use. All my X apps open on the secondary monitor. Is there a solution to this issue? I move them to 1st monitor and close them there but they do not seem to remember the window positions. I can't reproduce this problem. X windows which aren't explicitly placed appear on the primary monitor for me. Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Perhaps you should read the link above and try again including enough information for someone to try reproducing your problem. Facts which might be interesting include (but are not limited to): Your /var/log/Xwin.0.log The size and arrangement of your monitors, and which one is configured as the primary monitor for windows An example of an application you are using which shows the problem Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Updated: xorg-server-1.9.0-2 (TEST)
On 13/10/2010 12:44, Jon TURNEY wrote: The following packages have been updated in the Cygwin distribution: *** xorg-server-1.9.0-2 *** xorg-server-dmx-1.9.0-2 This package contains XWin and the other X.Org X11 servers. A new 1.9 release candidate has also been made available as a test release. This will be made stable in approximately one week if no major regressions are reported. These packages have been promoted from test to current. This contains the following cygwin-specific changes: - Fix a regression with window placement: Windows which remember their position were drifting towards the bottom-right with each appearance - Move log files from /var/log to /var/log/xwin, which is created mode 0777, to avoid logging failures in multiuser setups Mentions of /var/log/XWin.0.log in the documentation will be updated to say /var/log/xwin/XWin.0.log after this release is made stable. ... and I am in the process of updating the documentation. Additional documentation for the experimental WGL mode: * OpenGL drawing to an X window which is not a top-level window is not yet implemented. * Please ensure you are using the latest display drivers for your hardware before reporting any visual issues with WGL. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Paste from clipboard can failed (XWin bug)
On 30/09/2010 15:28, rolandc wrote: From X application, I select some text. I switch on Windows application and I try to paste the text. I do Ctrl-V = nothing happens I do a second Ctrl-V = the text is pasted This problem depends on the X application For testing purposes, do you have an example of an application which only offers XA_STRING? When a paste occurs, XWin receives a WM_RENDERFORMAT message : (cf. winClipboardWindowProc()) step 1/ XWin try to get the selection in COMPOUND_TEXT format (cf. winProcessXEventsTimeout() calls XConvertSelection(COMPOUND_TEXT )) step 2/ If the owner of the selection (the X app) can't handle COMPOUND_TEXT format, XWin try to get the selection in UTF8_STRING format (cf. winClipboardFlushXEvents(), on receive an SelectionNotify event with event.xselection.property == None, XWin calls XConvertSelection(UTF8_STRING)) step 3/ If the owner of the selection (the X app) can't handle UTF8_STRING format, XWin try to get the selection in XA_STRING format (cf. winClipboardFlushXEvents(), on receive an SelectionNotify event with event.xselection.property == None, XWin calls XConvertSelection(XA_STRING)) But there is a bug in XWin : XWin calls winProcessXEventsTimeout() only twice. If the X app handles only handles XA_STRING format, the step 3 is never invoked ! As the result, XWin can't get paste data and log the message: winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY Thanks very much for investigating this problem. Solution 1 : Call a third time the function winProcessXEventsTimeout() (see paste_bug_solution1.patch file attached) but this is not a very elegant solution ... Solution 2 : call winProcessXEventsTimeout() only one time winProcessXEventsTimeout() must process all notification until * time out expired * getting the paste data * error occurred (see paste_bug_solution2.patch file attached) note: the actual timeout is set to 1 second. Thanks very much for the patch. I agree that (2) is the more elegant solution. I am actually a bit concerned about the size of the timeout, it's conceivable a remote X application could take longer than that to respond. However, since we are trying to do this conversion synchronously in the clipboard thread's message pump, I'm not sure we want to block longer. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Updated: xorg-server-1.9.0-2 (TEST)
On 26/10/2010 00:53, Yaakov (Cygwin/X) wrote: On Mon, 2010-10-25 at 16:21 -0700, J. Offerman wrote: Please advise on this error. = CCLD XWin.exe /usr/lib/libXfont.a(miscutil.o):miscutil.c:(.data+0x0): multiple definition of ` _serverGeneration' ../../dix/.libs/libdix.a(globals.o):globals.c:(.bss+0x4): first defined here collect2: ld returned 1 exit status Building xserver 1.9 requires a version of libXfont which will be uploaded shortly together with the rest of X11R7.6. Specifically, as /usr/share/doc/Cygwin/xorg-server.README says, you need libXfont-devel-1.4.2-2, which hasn't been uploaded yet :-) If you want to build libXfont yourself, the needed patch is [1] [1] http://cgit.freedesktop.org/xorg/lib/libXfont/commit/?id=8f75706901da0141590d46f0f898e5678feac953 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: gvim tiny font in 1.7.7 (back again)
On 25/10/2010 11:25, David T-G wrote: Hi again, folks -- ...and then David T-G said... % ... % I hate these kinds of errors because it's so incredibly hard to get a % real resolution to the problem, but I'll not turn down having my gvim % work again :-) Even that is taken from me now. I had gvim happily open on a file, closed it, opened another file, and we're tiny. When I have set guifont=Courier\ Bold\ 10 in my .vimrc it is at least visible, although still small, and doesn't change with the font size, but it does change size if I specify different fonts (ie Lucida at any size is wider than Courier or Courier Bold at any size, while Times New Roman is very small); when I comment it out I'm back to the crazy tiny that I had before. Any more ideas? :-( More questions, certainly. From the examples you have given (xterm works, gvim doesn't), I was assuming that this meant that core (server-side) fonts are correctly sized, Xft (client-side) fonts aren't. But perhaps you mean that gvim is the only application which shows this problem? You might compare the appearance of the fonts shown by 'xfd -fa Courier' and 'xfd -fn -*-courier-medium-r-*-*-*-120-*-*-*-*-*-*' to test that. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Windows 7 Aero mode issue again
On 24/10/2010 00:00, Eliot Moss wrote: Dear Jon -- The latest xorg and dlls, posted in the last day, consistently cause my Window 7 64-bit laptop to drop out of Aero mode if I put it in sleep mode and then wake it up. Here are the .log file and the stderr output. Sorry, I'm not quite sure what you are telling me here. It is that you still have the same problem with 1.9.0-2 as with 1.8.2-1? (which is unfortunately unsurprising, as I haven't done anything to fix it) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Windows 7 Aero mode issue again
On 26/10/2010 14:55, Eliot Moss wrote: On 10/26/2010 9:09 AM, Jon TURNEY wrote: On 24/10/2010 00:00, Eliot Moss wrote: Dear Jon -- The latest xorg and dlls, posted in the last day, consistently cause my Window 7 64-bit laptop to drop out of Aero mode if I put it in sleep mode and then wake it up. Here are the .log file and the stderr output. Sorry, I'm not quite sure what you are telling me here. It is that you still have the same problem with 1.9.0-2 as with 1.8.2-1? (which is unfortunately unsurprising, as I haven't done anything to fix it) Yes ... but it seems that the problem *had* gone away for a while, with a version I directly downloaded that you had pointed me to ... Hmm, confused. [1] seems to say that the 20100923-git-2172af4d1ea713f1 snapshot still has that issue, although your later emails suggest it goes away if you don't use -resize (which is expected) You might like to try if adding '-engine 1' to the Xserver options works around the problem. Anyhow, I've fixed a logic error which meant we were doing rather more stuff than we needed to for WM_DISPLAYCHANGE in windowed mode (and perhaps the intel driver is being a bit hypersensitive about that, causing it to shut down DWM), and added a bit more debug logging. Could you try the snapshot at [2] with '-logverbose 3', please. [1] http://cygwin.com/ml/cygwin-xfree/2010-09/msg00065.html [2] ftp://cygwin.com/pub/cygwinx/XWin.20101026-git-6105a1d4e1e137f0.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: gvim tiny font in 1.7.7 (back again)
On 28/10/2010 01:53, Frédéric Bron wrote: But perhaps you mean that gvim is the only application which shows this problem? When I have the problem, it is not only gvim but also gv for example. It seems it has to do with screen resolution change (see my previous email). Frédéric Aha. It seems we have a bug causing the DPI to be set to random values after a resize. $ xdpyinfo.exe | grep -A2 'screen #0' screen #0: dimensions:2560x1600 pixels (13107x41779 millimeters) resolution:5x1 dots per inch I've uploaded a snapshot with a fix at [1], perhaps you can test that? [1] ftp://cygwin.com/pub/cygwinx/XWin.20101028-git-edd6452650ede026.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: gvim tiny font in 1.7.7 (back again)
On 28/10/2010 02:41, David T-G wrote: Jon, et al -- ...and then Jon TURNEY said... % % On 25/10/2010 11:25, David T-G wrote: % ... %Any more ideas? :-( % ... % But perhaps you mean that gvim is the only application which shows this % problem? Yup -- so far, anyway. % % You might compare the appearance of the fonts shown by 'xfd -fa Courier' % and 'xfd -fn -*-courier-medium-r-*-*-*-120-*-*-*-*-*-*' to test that. I'm back with xfd loaded now. Sure enough, the two are distinctly different; the former is smaller than the latter, although not so tiny as to be invisible as in gvim. This sure sounds like a lead, though! I am leery of posting attachments to the mailing list, so I haven't attached screen shots of the xfd layouts. In addition, I ran xlsfonts and it generated 2582 lines; that's probably more than I should paste here. Let me know what information I can provide, however. S... What do I do to make my fonts all be happy? The fonts aren't supposed to be visually identical, as they are potentially different fonts being draw by different renderers. But the sizes should be approximately the same. Let me try asking the question a different way: Does 'xfd -fa Courier-10:style=Bold' show a reasonably sized font at the same time as gvim, with that font set, doesn't? (In which case one might conclude this is probably a gvim bug) I don't think this is quite the same problem as reported by Frédéric Bron, as you don't seem to be using -resize. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Windows 7 Aero mode issue again
On 26/10/2010 23:58, Eliot Moss wrote: Ok, here's a first email about *some* symptoms ... If I run the latest installed XWin, or this one: ftp://cygwin.com/pub/cygwinx/XWin.20101026-git-6105a1d4e1e137f0.exe.bz2 without -resize and then sleep and unsleep the laptop, X does not paint anything but the cursor and keyboard events do not seem to go to the (invisible) windows. I have to kill the server and all the X jobs. I will now proceed to the other tests you suggested ... Hmmm... I don't think you've mentioned this before. I assume this is a regression from 1.8.0 (before -resize was added), as we used to survive a hibernate cycle? You're probably right about earlier version being sensitive to whether -resize was given. I had forgotten about that dependency of behavior. On 27/10/2010 00:15, Eliot Moss wrote: Ok ... the 20101026 snapshot works properly with -resize and -engine 1 set: DWM does not go away or get complained about if I sleep then unsleep. Yay! Good. Just to point out this isn't specific to the snapshot, though, -engine 1 should workaround the problem in all cases. I guess this confirms that it is a problem with our use of directdraw and a hibernate cycle. (as the workaround forces XWin to use the shadow GDI drawing engine rather than the shadow directdraw drawing engine) However, I can't see what is wrong with XWin's use of ddraw. We never try to draw directly to the primary surface (which is what causes DWM to be shut down), so why it thinks we are during a hibernate or resume is obscure. It would probably be a good idea to test with some other ddraw application over a hibernate, to confirm this is a problem with XWin and not with the intel video drivers, but I'm not sure what other ddraw application is similar enough to make this a valid test (The simple tests in dxdiag probably wouldn't prove anything) I did notice one little thing: its log file seems to go to /var/log/XWin.0.log rather than /var/log/xwin/XWin.0.log. I hadn't updated the script I use to build snapshots. Thanks for pointing this out, I've now corrected that. I include the -logverbose 3 output for you, and the stderr. Sorry, I was a little unclear. If you are still interested in pursing this, a log without -engine 1 and with -logverbose 3 would be most helpful. If you could annotate it to show at approximately what timestamp the suspend and resume occurred, that would be even better. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin crash after the launch of startkde on a remote Red Hat 5 machine
On 29/09/2010 15:05, Michel Hummel wrote:
You will find attached to this Email the modifications you asked.
The X server doesn't freeze anymore when clipboard restarts on xdmcp,
certainly fixed by the cygwin patches.
I added a rate-limit of clipboard_generation which disables restart after
XWIN_CLIPBOARD_RETRIES retries (defined to 40 in winclipboard.h)
and a sleep(XWIN_CLIPBOARD_DELAY) before retries (defined to 1 in
winclipboard.h)
I hope you will like this new version
I really appreciate your work on this set of patches, and I'm sorry it's taken
me so long to get around to looking at them.
I must confess that the size of each patch didn't help. You can never make
patches too small :-). 'git gui' and 'git rebase --interactive' are excellent
tools for splitting, merging and reordering patches.
I've merged most of it, with some tweaks and rearrangement into my latest
snapshot (code is at [1]), and it should be included in a 1.9.1-1 release I'll
be making shortly.
A few detailed comments:
I really want to keep fdMessageQueue under HAS_DEVWINDOWS for clarity and for
ease of sharing patches with XMing, so I had to rearrange things a bit to
permit that.
diff --git a/hw/xwin/winclipboardthread.c b/hw/xwin/winclipboardthread.c
index f85d8cf..5c8d0be 100644
--- a/hw/xwin/winclipboardthread.c
+++ b/hw/xwin/winclipboardthread.c
@@ -119,7 +119,7 @@ winClipboardProc (void *pvNotUsed)
if (XInitThreads () == 0)
{
ErrorF (winClipboardProc - XInitThreads failed.\n);
- pthread_exit (NULL);
+ goto winClipboardProc_Done;
}
/* See if X supports the current locale */
@@ -143,7 +143,7 @@ winClipboardProc (void *pvNotUsed)
/* setjmp returned an unknown value, exit */
ErrorF (winClipboardProc - setjmp returned: %d exiting\n,
iReturn);
- pthread_exit (NULL);
+ goto winClipboardProc_Done;
}
else if (iReturn == WIN_JMP_ERROR_IO)
{
These two failure modes are unlikely to get better when we restart the thread,
so I've tweaked these so they will be handled as a critical problem, causing
the X server to exit.
+ /* global clipboard variable reset */
+ g_fClipboardLaunched = FALSE;
+ g_fClipboardStarted = FALSE;
+ g_iClipboardWindow = None;
+ g_hwndClipboard = NULL;
+ g_fUnicodeClipboard = FALSE;
+ g_pClipboardDisplay = NULL;
Resetting g_fUnicodeClipboard seems unlikely to be right, as that will always
turn off unicode clipboard handling for all but the first invocation of the
thread.
diff --git a/hw/xwin/winclipboardthread.c b/hw/xwin/winclipboardthread.c
index 2d1ecf9..437f0fa 100644
--- a/hw/xwin/winclipboardthread.c
+++ b/hw/xwin/winclipboardthread.c
@@ -503,6 +503,16 @@ winClipboardErrorHandler (Display *pDisplay, XErrorEvent
*pErr)
pErr-serial,
pErr-request_code,
pErr-minor_code);
+ if (pthread_equal(pthread_self(),g_winClipboardProcThread)
(pErr-request_code == 24))
+{
+ /* We are in the clipboard thread and a bad window is detected.
+ * This means the Xwindow part of the clipboard doesn't exist anymore
+ * The call to pthread_exit(NULL) will restart the thread
+ */
+ ErrorF(winClipboardErrorHandler - Badwindow detected, restarting
clipboard thread\n);
+ pthread_exit(NULL);
+}
+
return 0;
}
I left this bit out for the moment. This code doesn't seem to do what it says
it does. Checking for a BadWindow would be pErr-error_code == BadWindow (3).
I think checking pErr-request_code == 24 is checking the operation is
X_ConvertSelection (see /usr/include/X11/Xproto.h)
I'm not sure currently works correctly at all in multiwindow mode, as
XSetErrorHandler() also gets called by the internal WM thread, so this error
handler may not be the one installed.
Is there a reason why we can't work out which Xlib function is actually
failing BadWindow and handle it there?
Can you explain a bit more about the case which this helps with. Are you
xkill-ing the clipboard X window?
On another topic, I am still a bit concerned we have a potential race
condition with the two uses of winInitClipboard() during a server
regeneration. g_fClipboardLaunched is FALSE before it's called, and set
afterwards, but since these two calls happen in different threads, there's
nothing I can see preventing the thread getting started twice.
It might be that having the clipboard thread to exit after setting
g_fClipboardLaunched to FALSE if the server generation has changed creates the
needed ordering of events (if it doesn't already exist), but it would take
some staring at the code to be sure...
[1] http://cgit.freedesktop.org/~jturney/xserver/log/?h=snapshot
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.9.2-1
The following packages have been updated in the Cygwin distribution: *** xorg-server-1.9.2-1 *** xorg-server-dmx-1.9.2-1 These packages contain XWin and the other X.Org X11 servers. In addition to upstream fixes, this contains the following cygwin-specific changes since 1.9.0-2: * Rewrite of the way clipboard thread is started, which should improve clipboard robustness in XDMCP session (thanks to Michel Hummel) * Fix clipboard interaction with nxproxy (and possibly other X clients) (thanks to Roland Cassard) * Fix WM_DISPLAYCHANGE handling in windowed mode to not resize the X screen * Don't write list email address into log * Fix random DPI after resize * Implement WGL AIGLX for non-toplevel X windows WGL AIGLX = The experimental WGL AIGLX mode (activated by the XWin command line option '-wgl') which enables hardware accelerated OpenGL rendering in the X server using the native WGL OpenGL interface, should now be working well enough to be useful. I'd very much like to hear reports of success or failure with specific OpenGL applications. For remote clients, you must 'export LIBGL_ALWAYS_INDIRECT=1' before starting the client application to force indirect rendering. For local clients, the recent update of libGL1 to 7.8.2-1 makes indirect rendering the default, so no special steps are needed. Please ensure you are using the latest display drivers for your graphics hardware before reporting any visual issues with WGL. Known problems: - OpenGL windows with static contents aren't re-drawn when occluded by a native Window and then exposed. Workaround: force the window to redraw, e.g. by resizing it. - When an OpenGL window is behind a native application window which uses layered windows for translucency e.g mintty, the OpenGL rendering is drawn over the top, flickering. Apparently, if we want to avoid this, we need to do the OpenGL rendering offscreen, then transfer it our window, so this becomes most of the 'use native compositing in multiwindow mode' todo list item. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 1.9.2.0: Xwin SIGSEGV when font server should be queried
Thanks for reporting this issue. On 04/11/2010 14:49, Weeber, Burkhard wrote: I updated my Cygwin with the latest available from the setup.exe. Do you know which version of Xserver that worked you updated from? Examining /var/log/setup.log and/or using setup to revert to the previous version should tell you. Now XWin.exe gets a Signal 11 (Segmentation violation) when a font switch (-fn) is on the command line. Command: $ ssh -Y myaix aixterm -fullcursor -geometry 81x30-125+93 -e /usr/local/bin/max.pl Is OK. $ ssh -Y myaix aixterm -fullcursor -geometry 81x30-125+93 -fn 6x10 -e /usr/local/bin/max.pl Fails. I have a font server running on AIX6.1 and before the start this font server is added by xset command. This worked well until the update. Also the xlsfonts command of cygwin distribution causes XWin to SIGSEGV. Also when specifying -fp tcp/myfontserver:7100 on the XWin start line any X-Program will cause a SIGSEGV. I'm afraid I'm not able to reproduce this (testing using an xfs running on Solaris, I don't have access to AIX). Can you please obtain a backtrace as follows: 1) Install gdb (for gdb) and sysvinit (for pidof) packages 2) Start XWin using your normal method 3) In a non-X terminal window, run gdb --pid=`pidof /usr/bin/XWin` 4) Type 'c' at the '(gdb)' prompt 5) Reproduce your crash 6) Type 'bt full' at the '(gdb)' prompt. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
