From jon.turney@dronecode.org.uk Sat Sep 3 19:02:00 2011 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Sat, 03 Sep 2011 19:02:00 -0000 Subject: XRaiseWindow for activating windows in multiwindow mode In-Reply-To: <4E46C4CE.6000206@gmx.de> References: <4E46C4CE.6000206@gmx.de> Message-ID: <4E62799E.2090204@dronecode.org.uk> On 13/08/2011 19:39, Oliver Schmidt wrote: > as reported in > > http://www.cygwin.com/ml/cygwin-xfree/2005-06/msg00072.html > > windows are not raised from the Cygwin X Server in multiwindow > mode, if a program wants to programmatically activate a window. > > I played around and figured out that the problem can be solved by > invoking the windows function SetForegroundWindow if a top level > window is to be restacked and has no previous sibling. > > I enclose the patch in this email. It works fine for me, but > I'm not sure if it has any side effects for other configurations > or usage patterns. Thanks for looking into this, and for the patch. There definitely are some problems in this area, but I'm not sure this is the 'correct' fix, though. The code as it stands is the product of some ... erm ... historical compromises. If I am reading the code correctly, it looks like currently no attempt is made to synchronize changes in the X window Z-order (e.g. made by XRaiseWindow()) to the native Windows window Z-order, and the comment in [1] seems to bear this out. The code which perhaps would do this is in the disabled branch of the #if/#else/#endif in winRestackWindowMultiWindow() The relevant thread seems to be [2] and the relevant change seems to be [3], but I can't reconstruct the reasoning behind it. As discussed in the thread [2] various scenarios, e.g. AOT windows, native windows interleaved with X windows in the native Z order, Windows with focus-follows-mouse enabled via TweakUI all need testing after trying to fix this, to ensure you haven't regressed them. [1] http://sourceware.org/ml/cygwin-xfree/2004-12/msg00074.html [2] http://sourceware.org/ml/cygwin-xfree/2004-03/msg00540.html [3] http://cgit.freedesktop.org/xorg/xserver/commit/?h=CYGWIN&id=40bb4441ac7c87cfa0c62e8553c7e53b9fe4d765 > It would be nice if this feature could be integrated into future > versions of the Cygwin X Server. > > Best regards, > Oliver > > > diff --git a/hw/xwin/winmultiwindowwindow.c b/hw/xwin/winmultiwindowwindow.c > index 956a9a5..22390b3 100644 > --- a/hw/xwin/winmultiwindowwindow.c > +++ b/hw/xwin/winmultiwindowwindow.c > @@ -465,6 +465,7 @@ winRestackWindowMultiWindow (WindowPtr pWin, WindowPtr pOldNextSib) > HWND hInsertAfter; > HWND hWnd = NULL; > #endif > + static Bool fRestacking = FALSE; /* Avoid recusive calls to this function */ I'd like this patch more if you said why recursive calls can occur, and why they must be avoided. > ScreenPtr pScreen = pWin->drawable.pScreen; > winScreenPriv(pScreen); > > @@ -472,10 +473,27 @@ winRestackWindowMultiWindow (WindowPtr pWin, WindowPtr pOldNextSib) > winTrace ("winRestackMultiWindow - %08x\n", pWin); > #endif > > + if (fRestacking) > + { > + /* It is a recusive call so immediately exit */ > +#if CYGWINDOWING_DEBUG > + ErrorF ("winRestackWindowMultiWindow - " > + "exit because fRestacking == TRUE\n"); > +#endif > + return; > + } > + fRestacking = TRUE; > + > WIN_UNWRAP(RestackWindow); > if (pScreen->RestackWindow) > (*pScreen->RestackWindow)(pWin, pOldNextSib); > WIN_WRAP(RestackWindow, winRestackWindowMultiWindow); > + > + if (isToplevelWindow(pWin)&& pWin->prevSib == NULL) > + { > + winWindowPriv(pWin); > + SetForegroundWindow(pWinPriv->hWnd); > + } > > #if 1 > /* > @@ -538,6 +556,8 @@ winRestackWindowMultiWindow (WindowPtr pWin, WindowPtr pOldNextSib) > 0, 0, > uFlags); > #endif > + > + fRestacking = FALSE; > } > > static void -- 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/ From oschmidt-mailinglists@gmx.de Sun Sep 4 08:52:00 2011 From: oschmidt-mailinglists@gmx.de (Oliver Schmidt) Date: Sun, 04 Sep 2011 08:52:00 -0000 Subject: XRaiseWindow for activating windows in multiwindow mode In-Reply-To: <4E62799E.2090204@dronecode.org.uk> References: <4E46C4CE.6000206@gmx.de> <4E62799E.2090204@dronecode.org.uk> Message-ID: <4E633C53.4040906@gmx.de> Hi Jon, On 03/09/11 21:01, Jon TURNEY wrote: > There definitely are some problems in this area, but I'm not sure this is the > 'correct' fix, though. yes, it's some kind of workaround, but it works and is very useful for may daily work. At least the patch is very defensive, it just raises top level windows that should be on top over all other top level windows (i.e. have no previous sibling). Some programs become unusable if programmatically raised windows are not raised. Of course it would be better if the cygwin multiwindow mode would react on window manager messages, i.e. atom "_NET_ACTIVE_WINDOW" for raising windows. > The code as it stands is the product of some ... erm ... historical compromises. I tried to left it mostly at it is, but yes, one can see that the coding at this point is a little bit "historic", especially the #if 1...#else block later on in the function winRestackWindowMultiWindow.... > this out. The code which perhaps would do this is in the disabled branch of > the #if/#else/#endif in winRestackWindowMultiWindow() yes, I had the same thoughts about it, but I didn't get it to work with this uncommented code. At least this uncommented code does not invoke SetForegroundWindow, so I doubt that it would raise windows under all conditions. > The relevant thread seems to be [2] and the relevant change seems to be [3], > but I can't reconstruct the reasoning behind it. > > As discussed in the thread [2] various scenarios, e.g. AOT windows, native > windows interleaved with X windows in the native Z order, Windows with > focus-follows-mouse enabled via TweakUI all need testing after trying to fix > this, to ensure you haven't regressed them. yes, is there any one here on this thread that uses these features and can confirm that they are still working with the patch? > I'd like this patch more if you said why recursive calls can occur, > and why they must be avoided. This was not my idea: it's just copied code from the function winReorderWindowsMultiWindow, so the reasons for avoiding the recursive behaviour are the same reasons that apply to existing code. The patched function winRestackWindowMultiWindow invokes the function winReorderWindowsMultiWindow in the #if 1 code block. So my idea was to move this lock a little bit higher, because with this patch critical work is done in the invoking fucunction winRestackWindowMultiWindow now. The recursive behaviour did occur in my testing, so this condition testing for avoiding recursive behaviour was necessary in the existing code and is also necessary for the patch. I think that the recursice behaviour occurs because changes on the top level windows with native Windows-API-Calls are leading to native Windows messages that again are fed into the x server and are leading to the funcion winRestackWindowMultiWindow. But this is only a theory, it is very difficult to find theses things out under cygwin, because stack traces via function "backtrace" from and "addr2line" are unfortunately not possible with cygwin :-( At least I'm happy now with my patched cygwin x server and I'm using it every day now ;-) Best regards, Oliver -- 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/ From oschmidt-mailinglists@gmx.de Sun Sep 4 09:09:00 2011 From: oschmidt-mailinglists@gmx.de (Oliver Schmidt) Date: Sun, 04 Sep 2011 09:09:00 -0000 Subject: XRaiseWindow for activating windows in multiwindow mode In-Reply-To: <4E633C53.4040906@gmx.de> References: <4E46C4CE.6000206@gmx.de> <4E62799E.2090204@dronecode.org.uk> <4E633C53.4040906@gmx.de> Message-ID: <4E63401D.9080107@gmx.de> some additions to my last mail: On 04/09/11 10:52, Oliver Schmidt wrote: > code and is also necessary for the patch. I think that the recursice > behaviour occurs because changes on the top level windows with native > Windows-API-Calls are leading to native Windows messages that again are > fed into the x server and are leading to the funcion > winRestackWindowMultiWindow. But this is only a theory, After looking again at the code, I must correct my above statements: now I think, that it's not the native Windows function SetForegroundWindow that is calling the recursive behaviour. It's still the already existing code in the function winReorderWindowsMultiWindow that is causing recursive behaviour: in this existing code the function ConfigureWindow is invoked (this is not a native Windows function, it seems to be some x server function). So the invocation of this function is triggering the x server to invoke winRestackWindowMultiWindow recursively. But these are still theories. At least the recursive behaviour is not introduced by the patch, it was already there in the existing coding ;-) Best regards, Oliver -- 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/ From oschmidt-mailinglists@gmx.de Sun Sep 4 11:18:00 2011 From: oschmidt-mailinglists@gmx.de (Oliver Schmidt) Date: Sun, 04 Sep 2011 11:18:00 -0000 Subject: XRaiseWindow for activating windows in multiwindow mode In-Reply-To: <4E62799E.2090204@dronecode.org.uk> References: <4E46C4CE.6000206@gmx.de> <4E62799E.2090204@dronecode.org.uk> Message-ID: <4E635E65.9080209@gmx.de> It's me again ;-) On 9/3/2011 9:01 PM, Jon TURNEY wrote: > As discussed in the thread [2] various scenarios, e.g. AOT windows, > native windows interleaved with X windows in the native Z order, Windows > with focus-follows-mouse enabled via TweakUI all need testing after > trying to fix this, to ensure you haven't regressed them. > > [2] http://sourceware.org/ml/cygwin-xfree/2004-03/msg00540.html I'm not sure if I'm correctly reproducing the above usage scenario "always on top", but I did the following under Windows 7 and XP: 1) downloaded and installed http://www.abstractpath.com/powermenu/ 2) launched a xclock or a native Windows program (e.g. Internet Explorer) and select "Always on top" with right mouse click on the window's titel bar 3) programmatically launched and raised other x top level windows 4) Everything works: the checked windows stay top level, the programmatically raised windows became top level amongst all other "non always top level" windows and get keyboard focus and activated window frame. I was also able to minimize and restore the "always on top window" without any problems. Moreover the "redraw windows while moving and sizing" hack http://www.cygwin.com/ml/cygwin-xfree/2011-08/msg00049.html does also work with the "always on top" feature enabled for the foreground and background window. Also mixtures of cygwin x server windows with native Windows applications all with "always on top" feature enabled are working. What is not working: Clicking on "minimize to tray" on a cygwin x server window that has also the "always on top feature": this causes the window frame to vanish, but the window content is still redrawn by the xserver on the underlaying x11 window. This is difficult to describe, but this does also not work with the official unpatched cygwin x server 1.10.3-1. This "minimize-to-tray" effect for "always on top windows" is also described here: http://sourceware.org/ml/cygwin-xfree/2004-03/msg00540.html So according to my tests the patch does not introduce new misbehaviour regarding powermenu's "always on top" window feature. I could provide a patched binary XWin.exe, if someone wants to do more testing... Best regards, Oliver -- 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/ From jon.turney@dronecode.org.uk Mon Sep 5 13:35:00 2011 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Mon, 05 Sep 2011 13:35:00 -0000 Subject: AltGr key mostly fires an additional CONTROL key In-Reply-To: <4E4916B6.9030602@gmx.de> References: <4E4916B6.9030602@gmx.de> Message-ID: <4E64D020.7000201@dronecode.org.uk> On 15/08/2011 13:53, Oliver Schmidt wrote: > I also had problems with the AltGr key. These could reliably > be reproduced by holding the AltGr for some seconds (causing > Windows generating auto repeat events). > > Unfortunately the test version at > > ftp://cygwin.com/pub/cygwinx/XWin.20110801-git-2d9f9305cb559907.exe.bz2 > > doesn't fix this problem for me. > > I discovered that the mechanism in winkeybd.c function > winIsFakeCtrl_L had a problem if PeekMessage cannot obtain > the next Alt_R message because it is not there. > > I prepared a patch that remembers the last Ctrl_L event and > reacts on a later following Alt_R. It was also necessary to > alter the order in winWindowProc in winwndproc.c: the invocation > of winIsFakeCtrl_L had to be done before discarding auto-repeated > key presses. > > The attached patch is against the sources of xserver-cygwin-1.10.3-1. Thanks for the patch. The approach of remembering if the last keyevent was a Ctrl-L and reversing it if it was fake because it's followed by a AltGr is a good one, which hadn't occurred to me, and it clearly better than assuming the AltGr keyevent message will be available some fixed time after the Ctrl-L one. (I had considered buffering the Ctrl-L keyevent until we could determine a AltGr wasn't going to be coming after it, but that would be more complex to implement) A few comments on the patch follow. It could also do with some better comments, as what this code is trying to do is slightly obscure, and I assume that the old comments about TweakUI being the cause of this are just wrong (as you don't mention that you have it installed) > diff --git a/hw/xwin/winkeybd.c b/hw/xwin/winkeybd.c > index e807fc5..460c9d6 100644 > --- a/hw/xwin/winkeybd.c > +++ b/hw/xwin/winkeybd.c > @@ -356,6 +356,12 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam) > MSG msgNext; > LONG lTime; > Bool fReturn; > + > + static Bool hasLastControlL = FALSE; > + static UINT lastMessage; > + static WPARAM lastWparam; > + static LPARAM lastLparam; > + static LONG lastTime; I was going to suggest using static MSG lastMsg, but then I noticed that lastWparam, lastLparam are completely unused... > /* > * Fake Ctrl_L presses will be followed by an Alt_R keypress > @@ -389,9 +395,22 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam) > WM_KEYDOWN, WM_SYSKEYDOWN, > PM_NOREMOVE); > } > - if (msgNext.message != WM_KEYDOWN && msgNext.message != WM_SYSKEYDOWN) > + if (fReturn && msgNext.message != WM_KEYDOWN && msgNext.message != WM_SYSKEYDOWN) > fReturn = 0; > + if (!fReturn) > + { > + hasLastControlL = TRUE; > + lastMessage = message; > + lastWparam = wParam; > + lastLparam = lParam; > + lastTime = lTime; > + } > + else > + { > + hasLastControlL = FALSE; > + } > + > /* Is next press an Alt_R with the same timestamp? */ > if (fReturn && msgNext.wParam == VK_MENU > && msgNext.time == lTime > @@ -406,11 +425,33 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam) > } > } > > + /* > + * Check for Alt_R keypress, that was not ready when the > + * last Ctrl_L appeared. > + */ > + else if ((message == WM_KEYDOWN || message == WM_SYSKEYDOWN) > + && wParam == VK_MENU > + && (HIWORD (lParam) & KF_EXTENDED)) > + { > + if (hasLastControlL) > + { > + lTime = GetMessageTime (); > + > + if ((lastMessage == WM_KEYDOWN || lastMessage == WM_SYSKEYDOWN) > + && lastTime == lTime) Why is it necessary to check that the last message was WM_(SYS)KEYDOWN here? hasLastControlL can't get set unless it was? > + { > + /* take back the fake ctrl_L key */ > + winSendKeyEvent (KEY_LCtrl, FALSE); > + } > + hasLastControlL = FALSE; > + } > + } > + > /* > * Fake Ctrl_L releases will be followed by an Alt_R release > * with the same timestamp as the Ctrl_L release. > */ > - if ((message == WM_KEYUP || message == WM_SYSKEYUP) > + else if ((message == WM_KEYUP || message == WM_SYSKEYUP) > && wParam == VK_CONTROL > && (HIWORD (lParam) & KF_EXTENDED) == 0) > { > @@ -439,9 +480,11 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam) > PM_NOREMOVE); > } > > - if (msgNext.message != WM_KEYUP && msgNext.message != WM_SYSKEYUP) > + if (fReturn && msgNext.message != WM_KEYUP && msgNext.message != WM_SYSKEYUP) > fReturn = 0; > > + hasLastControlL = FALSE; > + > /* Is next press an Alt_R with the same timestamp? */ > if (fReturn > && (msgNext.message == WM_KEYUP > @@ -458,6 +501,10 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM lParam) > return TRUE; > } > } > + else > + { > + hasLastControlL = FALSE; > + } > > /* Not a fake control left press/release */ > return FALSE; > diff --git a/hw/xwin/winwndproc.c b/hw/xwin/winwndproc.c > index 316cf08..7de5a5d 100644 > --- a/hw/xwin/winwndproc.c > +++ b/hw/xwin/winwndproc.c > @@ -1060,6 +1060,10 @@ winWindowProc (HWND hwnd, UINT message, > if ((wParam == VK_LWIN || wParam == VK_RWIN) && !g_fKeyboardHookLL) > break; > > + /* Discard fake Ctrl_L presses that precede AltGR on non-US keyboards */ > + if (winIsFakeCtrl_L (message, wParam, lParam)) > + return 0; > + > /* > * Discard presses generated from Windows auto-repeat > */ > @@ -1080,10 +1084,6 @@ winWindowProc (HWND hwnd, UINT message, > } > } > > - /* Discard fake Ctrl_L presses that precede AltGR on non-US keyboards */ > - if (winIsFakeCtrl_L (message, wParam, lParam)) > - return 0; > - Can you say why it's necessary to change the order here and why this is the correct ordering? A comment here might be a good idea :-) > /* Translate Windows key code to X scan code */ > winTranslateKey (wParam, lParam, &iScanCode); > > -- 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/ From oschmidt-mailinglists@gmx.de Tue Sep 6 07:45:00 2011 From: oschmidt-mailinglists@gmx.de (Oliver Schmidt) Date: Tue, 06 Sep 2011 07:45:00 -0000 Subject: AltGr key mostly fires an additional CONTROL key In-Reply-To: <4E64D020.7000201@dronecode.org.uk> References: <4E4916B6.9030602@gmx.de> <4E64D020.7000201@dronecode.org.uk> Message-ID: <4E65CF75.8050304@gmx.de> Hi Jon, On 9/5/2011 3:35 PM, Jon TURNEY wrote: > comments, as what this code is trying to do is slightly obscure, and I > assume that the old comments about TweakUI being the cause of this are > just wrong (as you don't mention that you have it installed) Yes I didn't test it with Tweak UI and I ignored the comments on Tweak UI. I also think that the old "sleep(0)" workaround for Tweak UI is now not necessary with the new patch. But I kept the changes as minimal as possible and tried to keep existing code as much as it is. >> diff --git a/hw/xwin/winkeybd.c b/hw/xwin/winkeybd.c >> + static Bool hasLastControlL = FALSE; >> + static UINT lastMessage; >> + static WPARAM lastWparam; >> + static LPARAM lastLparam; >> + static LONG lastTime; > > I was going to suggest using static MSG lastMsg, but then I noticed > that lastWparam, lastLparam are completely unused... yes, they are now unused editing relicts from my testing phase... >> + >> + if ((lastMessage == WM_KEYDOWN || lastMessage == >> WM_SYSKEYDOWN) >> + && lastTime == lTime) > > Why is it necessary to check that the last message was WM_(SYS)KEYDOWN > here? hasLastControlL can't get set unless it was? yes you are right: the if condition here is a little over-determined ;-) >> diff --git a/hw/xwin/winwndproc.c b/hw/xwin/winwndproc.c >> + /* Discard fake Ctrl_L presses that precede AltGR on non-US >> keyboards */ >> + if (winIsFakeCtrl_L (message, wParam, lParam)) >> + return 0; >> + >> - /* Discard fake Ctrl_L presses that precede AltGR on non-US >> keyboards */ >> - if (winIsFakeCtrl_L (message, wParam, lParam)) >> - return 0; >> - > > Can you say why it's necessary to change the order here and why this is > the correct ordering? A comment here might be a good idea :-) in the old coding there is this check for generated Windows auto-repeat key events and this check can cause the function to exit: /* * Discard presses generated from Windows auto-repeat */ if (lParam & (1<<30)) { switch (wParam) { /* ago: Pressing LControl while RControl is pressed is * Indicated as repeat. Fix this! */ case VK_CONTROL: case VK_SHIFT: if (winCheckKeyPressed(wParam, lParam)) return 0; break; default: return 0; } } I didn't change this coding and I'm not sure what the funtion winCheckKeyPressed exactly does. However the check winIsFakeCtrl_L must be done before leaving the function because of auto-repeated key events. Otherwise there will be problems with autorepeated AltGr-Keys. These must also be tracked with winIsFakeCtrl_L otherwise autorepeated AltGr keys could produce a "hanging" Control_L key (I had this effect when I tested the patch). So the order has to be changed, because the function winIsFakeCtrl_L now has an internal state due to it's static variables and this state has to be synchronized with the actuel key events. Best regards, Oliver -- 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/ From sdamian@rs10.webd.pl Wed Sep 7 04:31:00 2011 From: sdamian@rs10.webd.pl (sdamian@rs10.webd.pl) Date: Wed, 07 Sep 2011 04:31:00 -0000 Subject: Prezent od Damiana Message-ID: <20110907042753.E547DE509C@rs10.webd.pl> Cze????, Mam dla Ciebie dobr?? wiadomo????. Pomy??la??em sobie dzisiaj, ??e sprawi?? Ci mi???? niespodziank??. Dlaczego? Mam dzisiaj ??wietny humor i od samego rana bu??ka mi si?? u??miecha :) http://tnij.org/damiansak Jak wiesz jeste?? zapisany/a na moj?? list?? dlatego, ??e chc?? si?? z Tob?? dzieli?? wszystkim co sam wiem i co b??d?? jeszcze wiedzia??. Dlatego postanowi??em udost??pni?? Ci pond 290 E-book??w dzi??ki kt??rym Twoja wiedza z miesi??ca na miesi??c b??dzie si?? pog????bia??. Tw??j rozw??j jest w zasi??gu tego konkretnego linka: http://tnij.org/damiansak My??l??, ??e prezent Ci si?? spodoba oraz ciesz?? si??, ??e b??d?? m??g?? pom??c Tobie w ten szczeg??lny spos??b. http://tnij.org/damiansak Pozdrawiam Ciep??o Damian Sak www.damiansak.pl Ps. Ju?? nied??ugo ruszam z kursem 3 MEGA RYNKI, dowiesz si?? o 3 najwa??niejszych rynkach, kt??re poznasz i je??li zastosujesz konkretne strategie to zaczniesz zarabia?? dobre pieni??dze. PP.s. Nie zapomnij tutaj zajrze??: http://tnij.org/damiansak -- 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/ From jon.turney@dronecode.org.uk Wed Sep 7 12:25:00 2011 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Wed, 07 Sep 2011 12:25:00 -0000 Subject: Can't paste text or type blind keys when mouse is out of the window In-Reply-To: <000901cc54e1$1dca8c50$595fa4f0$@de> References: <000901cc54e1$1dca8c50$595fa4f0$@de> Message-ID: <4E6762AA.6020802@dronecode.org.uk> On 07/08/2011 10:05, Paul Maier wrote: > when xterm has keyboard focus, but mouse pointer is outside of the window (or > even on Window's blue title bar): > > > - all blind keys are ignored: > > o instead of '??' (key '`' then 'a') you get just a normal 'a' > > o can't type '^' character (on a German keyboard done with blind '^' key then space) > -> you will just get the space instead > > o same with '`' or '??': all blind keys are affected > > - can't paste text with the mouse > > - all other keys work as expected Thanks for reporting this issue and the clear reproduction step. I can reproduce this problem. I can also reproduce it under XWin in windowed mode with twm, but not on Xorg on Linux, so this seems to be XWin specific, but not related to multiwindow mode WM, which is a real puzzler. I assume that you see the same behavior with other X applications, i.e. it's not xterm-specific? > The XWin.logs are the same regardless if mouse is inside or outside, > but I notice a small difference in xev's output. Yes, it looks like the events are delivered to the top window of xterm's hierarchy when the mouse is on the non-client area of the window or the desktop, but to the bottom window of the xterm hierarchy when the mouse is over the xterm window. I also note that if you type a deadkey with the mouse in the client area, then move the mouse over the frame, type a key, it is passed straight though, then move the mouse back over the client area, and type a key, it is modified by the previous deadkey. -- 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/ From jon.turney@dronecode.org.uk Wed Sep 7 13:16:00 2011 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Wed, 07 Sep 2011 13:16:00 -0000 Subject: minimize redraw events after resizing/moving windows in multiwindow mode In-Reply-To: <4E503106.9060605@gmx.de> References: <4E503106.9060605@gmx.de> Message-ID: <4E676E7F.3010901@dronecode.org.uk> On 20/08/2011 23:11, Oliver Schmidt wrote: > in multiwindow mode the modal moving/resizing of windows causes a lot of > redraw events send to the X clients after the userse releases the mouse > button. During the moving/resizing client windows are not redrawn as long as > the mouse button is pressed. But all redraw/resizing events are queued and > executed step after step after moving/resizing ends. > > Some clients collect and combine multiple redraw or resizing events, other > clients (e.g. xterm) simply execute each redraw or sizing event. > > The enclosed patch minimizes the events for clients to only one event after > the user releases the mouse button to end the moving/resizing. This improves > the user experience and reduces strange screen flickerings especially on slow > platforms. Thanks for the patch. I've applied it to my git tree [1], so it will appear in the next cygwin X server release (probably 1.11.0-1) [1] http://cgit.freedesktop.org/~jturney/xserver/commit/?h=cygwin-release-1.11&id=784ef7472904cbac6ea49d8cf0e489820372a90d -- 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/ From jon.turney@dronecode.org.uk Wed Sep 7 15:06:00 2011 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Wed, 07 Sep 2011 15:06:00 -0000 Subject: redraw windows while resizing/moving windows in multiwindow mode In-Reply-To: <4E50380A.6070101@gmx.de> References: <4E50380A.6070101@gmx.de> Message-ID: <4E67884E.2020900@dronecode.org.uk> On 20/08/2011 23:41, Oliver Schmidt wrote: > the following patch is a quick & dirty hack to enable redrawing of windows > while the user moves or resizes the window. > > This patch should be seen as experimental proof that this can be done with > only small changes in the source code. This is fine as a proof of concept, and it would be nice to handle this better and do X window updates during the Windows modal resizing loop, but I don't think I can apply this patch. > The main problem with window resizing/moving under Windows is, that in the > function invocation stack dix/Dispatch -> os/WaitForSomething -> WakeupHandler > -> hw/xwin/winWakeupHandler -> Windows/DispatchMessage -> > hw/xwin/winTopLevelWindowProc the Windows function DispatchMessage does not > return while the user resizes/moves a window. This function only returns after > the user releases the mouse button. However the dix/Dispatch functions must be > run to allow the clients to process the queued redraw/resizing events. Well, in fact, no X events are processed while in the modal resizing loop, so for e.g. if you have ico running in another X window, it stops updating while an xterm window is being resized. Note that there are other modal loops in Windows message handling, I think moving the scrollbar also involves one (which can happen in windowed mode with the -scrollbar option) > The enclosed hack simply moves the invocation of DispatchMessage in > winWakeupHandler outside WaitForSomething into Dispatch and breaks up the > Dispatch function into a loop and inner dispatch handling that can be called > from the winTopLevelWindowProc while WM_SIZE/WM_MOVE events are processed. > This could further be improved by setting a windows timer while resizing > moving to process clients messages even if the mouse is not moved while > resizing (and therefore WM_SIZE/WM_MOVE events are not send). > > What do you think about this idea? One problem here is, that the dix package > is also affected. Of course some work must be done to cleanly integrate this > into the existing dix/hw architecture. I'm not sure how to structure the change to Dispatch() in a way which would be acceptable upstream. An additional point to consider is that you may have introduced the possibility of re-entrancy into either the X window message dispatcher, or the Windows message dispatcher, which may not be safe. (e.g. winTopLevelProc -> DispatchOneStep -> (some X event processing calls a DDX function which calls SendMessage) -> winTopLevelProc ...) An alternative approach would be to move the Windows message pump into a separate thread from the X server message dispatch. Unfortunately, this would probably involve rather major changes, and careful examination of all the places where the window drawing code accesses internal server state to see if locking was needed. (I think Xquartz is structured more like that) Alternatively, it might be worth investigating to see if it is possible to use a message filter set with SetWindowsHookEx(WH_MSGFILTER) to run the X window dispatch while Windows is in a modal loop? -- 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/ From oschmidt-mailinglists@gmx.de Thu Sep 8 13:09:00 2011 From: oschmidt-mailinglists@gmx.de (Oliver Schmidt) Date: Thu, 08 Sep 2011 13:09:00 -0000 Subject: redraw windows while resizing/moving windows in multiwindow mode In-Reply-To: <4E67884E.2020900@dronecode.org.uk> References: <4E50380A.6070101@gmx.de> <4E67884E.2020900@dronecode.org.uk> Message-ID: <4E68BE79.1030604@gmx.de> Hi Jon, On 9/7/2011 5:05 PM, Jon TURNEY wrote: > This is fine as a proof of concept, and it would be nice to handle this did you try the patch? It looks & feels very smooth if you resize a xlock and the xclock and all x11 background windows are redrawn while resizing ;-) > better and do X window updates during the Windows modal resizing loop, > but I don't think I can apply this patch. but I hope this patch can be used as a starting point. > Well, in fact, no X events are processed while in the modal resizing > loop, so for e.g. if you have ico running in another X window, it stops > updating while an xterm window is being resized. with the patch X events are processed. With the patch, ico redraws also while windows are moved or resized, as long as the mouse is moved. For display updating without moving the mouse while modal resizing/moving is in progress, I already mentioned the timer event that is possible to improve the patch. Thanks for mentioning "ico", I didn't know this program, it is an interesting experimental tool: it shows that the patch is too aggressive, i.e. the ui interface is not responsive, perhaps due to my "critical" code fragment: while (DispatchOneStep(FALSE) > 0) {} So I will try now to improve the patch for better responsiveness. > Note that there are other modal loops in Windows message handling, I > think moving the scrollbar also involves one (which can happen in > windowed mode with the -scrollbar option) One could introduce a similar patch there too ;-) However a patch for scrollbar option in windowed mode is not as reasonable as in multiwindow mode, because the static redrawing of the x server makes sense in windowed mode. Only in multiwindow mode the redrawing is strange, e.g. if you applied my patch "minimize redraw events after resizing/moving windows in multiwindow mode", you will see other X11 background windows while "resizing" a x11 foreground window in the window that is resized, because actually the x11 window is not resized due to missing x11 event processing, but the xserver simply redraws all x11 windows in the current size. In windowed mode, no x11 window is resized. > I'm not sure how to structure the change to Dispatch() in a way which > would be acceptable upstream. I hoped, you had an idea. What are the criteria to be accepted upstream? At least the patch introduces only a "bypass", i.e. existing code/usage is not affected. It would be discouraging if no upstream changes are possible to improve the cygwin x server's multi window mode, since this is the mode that allows the highest integration of x11 applications with native windows programs. If no upstream changes are possible one fallback could be to have a local patch (or #ifdef switch) for the cygwin x server. > An additional point to consider is that you may have introduced the > possibility of re-entrancy into either the X window message dispatcher, > or the Windows message dispatcher, which may not be safe. (e.g. > winTopLevelProc -> DispatchOneStep -> (some X event processing calls a > DDX function which calls SendMessage) -> winTopLevelProc ...) Could you explaind this more explicitly? How can this be tested? As I understood the code, the function "Dispatch" is only called once per x server invocation. And the new function "DispatchOneStep" is meant to be processed re-entrant. This is why the boolean parameter handleWindowMessage is introduced and why I had to remove the invocation of DispatchMessage out of the winWakeupHandler which is called in WaitForSomething. > An alternative approach would be to move the Windows message pump into a > separate thread from the X server message dispatch. Unfortunately, this > would probably involve rather major changes, and careful examination of I agree that this would cause a lot of more work than the approach of my patch. I'm not sure if moving the Windows message handling into a different thread will solve the problem totally: there still is the problem, that in the modal windows event loop the x11 event processing must be invoked. At least one has to totally decouple the x11 and Windows event processing, but then still in the modal event loop the now decoupled x11 processing must be triggered. So it seems to me, that decoupling the x11 and Windows processing does only prevent upstream changes but does not solve the problem, that in the modal Windows event loop small progressing parts for X11 (coupled or decoupled) have to be done. > Alternatively, it might be worth investigating to see if it is possible > to use a message filter set with SetWindowsHookEx(WH_MSGFILTER) to run > the X window dispatch while Windows is in a modal loop? I'm not sure if I'm understanding this approach correctly, but I think even with SetWindowsHookEx we still have the problem, that the main loop in Dispatch has to be broken into smaller parts that can be invoked from inside the modal Windows event loop (or hook). Best regards, Oliver -- 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/ From svn-user@web.de Thu Sep 8 20:53:00 2011 From: svn-user@web.de (Paul Maier) Date: Thu, 08 Sep 2011 20:53:00 -0000 Subject: AW: Can't paste text or type blind keys when mouse is out of the window In-Reply-To: <4E6762AA.6020802@dronecode.org.uk> References: <000901cc54e1$1dca8c50$595fa4f0$@de> <4E6762AA.6020802@dronecode.org.uk> Message-ID: <002401cc6e69$3431eb90$9c95c2b0$@de> > -----Urspr?ngliche Nachricht----- > On 07/08/2011 10:05, Paul Maier wrote: > > when xterm has keyboard focus, but mouse pointer is outside of the window (or > > even on Window's blue title bar): > > > > > > - all blind keys are ignored: > > > > o instead of '?' (key '`' then 'a') you get just a normal 'a' > > > > o can't type '^' character (on a German keyboard done with blind '^' key then space) > > -> you will just get the space instead > > > > o same with '`' or '?': all blind keys are affected > > > > - can't paste text with the mouse > > > > - all other keys work as expected > > Thanks for reporting this issue and the clear reproduction step. > > I can reproduce this problem. I can also reproduce it under XWin in windowed > mode with twm, but not on Xorg on Linux, so this seems to be XWin specific, > but not related to multiwindow mode WM, which is a real puzzler. > > I assume that you see the same behavior with other X applications, i.e. it's > not xterm-specific? > > > The XWin.logs are the same regardless if mouse is inside or outside, > > but I notice a small difference in xev's output. > > Yes, it looks like the events are delivered to the top window of xterm's > hierarchy when the mouse is on the non-client area of the window or the > desktop, but to the bottom window of the xterm hierarchy when the mouse is > over the xterm window. > > I also note that if you type a deadkey with the mouse in the client area, then > move the mouse over the frame, type a key, it is passed straight though, then > move the mouse back over the client area, and type a key, it is modified by > the previous deadkey. Hi Jon, welcome back from your holiday. > I assume that you see the same behavior with other X applications, i.e. it's > not xterm-specific? No, at least xedit works fine on my PC, with blind keys and with mouse text pasting, no matter if the mouse pointer is really inside or on blue window frame or (for blind keys:) really outside. Mouse pointer on blue window frame comes from a typical use case: when clicking focus to the window. Then the mouse pointer stays there. The window has the focus but you can't paste inside xterm before moving the mouse really inside. With xedit that works. Paul. -- 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/ From jon.turney@dronecode.org.uk Fri Sep 9 11:42:00 2011 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Fri, 09 Sep 2011 11:42:00 -0000 Subject: AW: Can't paste text or type blind keys when mouse is out of the window In-Reply-To: <002401cc6e69$3431eb90$9c95c2b0$@de> References: <000901cc54e1$1dca8c50$595fa4f0$@de> <4E6762AA.6020802@dronecode.org.uk> <002401cc6e69$3431eb90$9c95c2b0$@de> Message-ID: <4E69FB99.1000608@dronecode.org.uk> >> I assume that you see the same behavior with other X applications, i.e. it's >> not xterm-specific? > > No, at least xedit works fine on my PC, with blind keys and with mouse text pasting, > no matter if the mouse pointer is really inside or on blue window frame or > (for blind keys:) really outside. > > Mouse pointer on blue window frame comes from a typical use case: when clicking focus to the window. > Then the mouse pointer stays there. The window has the focus but you can't paste inside xterm before > moving the mouse really inside. With xedit that works. Actually, maybe this is an xterm problem? It seems to be somehow related to the xterm's --enable-toolbar configuration (which is turned on in the cygwin package). If I rebuild xterm with that disabled, the problem goes away, and I can also reproduce the problem on F15 under twm if I build xterm with --enable-toolbar there (which is not enabled in the distro supplied package) -- 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/ From dan@spicetrader.net Mon Sep 12 14:25:00 2011 From: dan@spicetrader.net (Daniel Brockman) Date: Mon, 12 Sep 2011 14:25:00 -0000 Subject: frequently getting a =?utf-8?b?U1RBVFVTX0FDQ0VTU19WSU9MQVRJT04=?= exception under win7 References: Message-ID: Tonight (Sep 10, 2011), I encounter same problem for the first time. Windows 7, Avast free antivirus. Never saw this before altho I installed this cygwin fresh in Jun-2011 and I've used it fairly often since.. What is rebaseall? -- 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/ From svn-user@web.de Mon Sep 12 18:54:00 2011 From: svn-user@web.de (Paul Maier) Date: Mon, 12 Sep 2011 18:54:00 -0000 Subject: xterm: scrollbar bug Message-ID: <000f01cc717d$3edad040$bc9070c0$@de> Hi everybody, xterm doesn't show the scroll bar properly; the jpegs in this link show the problem as it still exists: http://www.cygwin.com/ml/cygwin-xfree/2010-06/msg00071.html I also found some emails from 2010 towards a solution: http://www.cygwin.com/ml/cygwin-xfree/2010-07/msg00028.html http://www.cygwin.com/ml/cygwin-xfree/2010-06/msg00077.html http://www.cygwin.com/ml/cygwin-xfree/2010-08/msg00061.html Above mails indicate, that the solution is already (almost) found. Will a fix be available in some of the next releases? Thanks & Regards Paul -- 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/ From reply-to-list-only-lh@cygwin.com Mon Sep 12 22:10:00 2011 From: reply-to-list-only-lh@cygwin.com (Larry Hall (Cygwin-X)) Date: Mon, 12 Sep 2011 22:10:00 -0000 Subject: frequently getting a STATUS_ACCESS_VIOLATION exception under win7 In-Reply-To: References: Message-ID: <4E6E831D.6050108@cygwin.com> On 9/10/2011 11:14 PM, Daniel Brockman wrote: > > > Tonight (Sep 10, 2011), I encounter same problem for the first time. > Windows 7, Avast free antivirus. Never saw this before altho I installed this > cygwin fresh in Jun-2011 and I've used it fairly often since.. > > What is rebaseall? It is a script from the rebase package used to rebase the Cygwin DLLs on your system to try to avoid overlap in the memory space. -- Larry _____________________________________________________________________ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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/ From Tom_Roche@pobox.com Sun Sep 18 21:14:00 2011 From: Tom_Roche@pobox.com (Tom Roche) Date: Sun, 18 Sep 2011 21:14:00 -0000 Subject: how to set X resources in Cygwin? Message-ID: summary: I'm running an up-to-date cygwin X on wxpsp3. I get both xterm and urxvt-X to start, but cannot get either to pickup settings from .Xdefaults or .Xresources. What am I doing wrong? details: I'm a former longtime cygwin user, since my former workplaces required windows. For the past few years, I've been able to run linux as my primary work desktop, so have been doing that. Now I'm starting at another place that requires windows (they literally will not allow my linux laptop on the network), so I'm desperately trying to revive my cygwin configuration chops. I used latest setup.exe to install latest packages onto a fresh install of ... windows xp sp3. (A blast from the past :-) Packages included X, xinit, xterm, rxvt-unicode, and emacs-X11. I then edited startxwin.bat to get a multiwindow X to start xterm and urxvt, and .Xresources to start them with desired options. The terminals are indeed starting, but not as desired, and they just don't seem to respond to changes to .Xresources, even if I * `xrdb ~/.Xresources` * shutdown/restart X (rclick on tray icon>Exit>Exit, then run startxwin.bat) * shutdown/restart windows, then shutdown/restart X (I also tried briefly to make the terminals load changes from ~/.Xdefaults, but I believe that is deprecated, so I didn't try too hard.) Some things that *are* happening in accord with my .Xresources (attached) include: + red keyboard cursor in xterm (BTW: how to set _mouse_ cursor color?) + scrollbar to right in xterm + S-PgUp, S-PgDn scrolls xterm + xterm foreground=black, background=white + xterm font-size ~= 8 (looks right, anyway) + urxvt font == "Bitstream Vera Sans Mono" (which is in my fc-list) Some things that *aren't* happening, that I believe my .Xresources should invoke, include - xterm font != "Bitstream Vera Sans Mono" - urxvt font size != 8 (it's huge, like 14 or 16) - urxvt foreground != black && background != white (more like cream on dark blue) - no tabs in urxvt (which I dearly want, but I really should learn to use `screen` anyway) So now I'm trying to make this happen on my old wxp laptop, but am getting identical results. What am I doing wrong? Or are only commandline options supported? Please find attached startxwin.bat (attached as startxwin.txt) ~/.xinitrc (untouched by me) ~/.Xresources XWin.0.log cygcheck.out If there's anything else I should do to further debug (or to actually fix :-) this, please let me know. If I should be RTFMing, please pass pointer(s). TIA, Tom Roche -------------- next part -------------- @echo off rem Adapted from /bin/startxwin.bat installed from Cygwin package=xinit 15 Sep 11 SET DISPLAY=127.0.0.1:0.0 REM REM The path in the CYGWIN_ROOT environment variable assignment assume REM that Cygwin is installed in a directory called 'cygwin' in the root REM directory of the current drive. You will only need to modify REM CYGWIN_ROOT if you have installed Cygwin in another directory. For REM example, if you installed Cygwin in \foo\bar\baz\cygwin, you will need REM to change \cygwin to \foo\bar\baz\cygwin. REM REM This batch file will almost always be run from the same drive (and REM directory) as the drive that contains Cygwin/X, therefore you will REM not need to add a drive letter to CYGWIN_ROOT. For example, you do REM not need to change \cygwin to c:\cygwin if you are running this REM batch file from the C drive. REM rem Note this assumes that we're running Cygwin on the same drive as the .bat REM SET CYGWIN_ROOT=\ProgramFiles\Cygwin\20090525 SET CYGWIN_ROOT=\ProgramFiles\Cygwin\20091226new rem %RUN% used below rem SET RUN=%CYGWIN_ROOT%\usr\X11R6\bin\run.exe SET RUN=%CYGWIN_ROOT%\bin\run.exe rem path rem mount rem echo HOME=%HOME% rem pause REM REM Cleanup after last run. REM if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0 del %CYGWIN_ROOT%\tmp\.X11-unix\X0 :CLEANUP-FINISH if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix REM REM The error "Fatal server error: could not open default font 'fixed'" is REM caused by using a DOS mode mount for the mount that the Cygwin/X REM fonts are accessed through. See the Cygwin/X FAQ for more REM information: REM http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-error-font-eof REM if "%OS%" == "Windows_NT" goto OS_NT REM Windows 95/98/Me echo startxwin.bat - Starting on Windows 95/98/Me goto STARTUP :OS_NT REM Windows NT/2000/XP/2003 echo startxwin.bat - Starting on Windows NT/2000/XP/2003 :STARTUP REM REM Brief descriptions of XWin-specific options: see XWin(1) manpage for details. REM REM -screen scr_num [width height] REM Enable screen scr_num and optionally specify a width and REM height for that screen. REM Most importantly, any parameters specified before the first -screen REM parameter apply to all screens. Any options after the first -screen REM parameter apply only to the screen that precedes the parameter. REM Example: REM XWin -fullscreen -screen 0 -screen 1 -depth 8 -screen 2 REM All screens will be fullscreen, but screen 2 will be depth 8, while REM screens 0 and 1 will be the default depth (whatever depth Windows REM is currently running at). REM -multiwindow REM Start an integrated Windows-based window manager. Not to be used REM with -rootless nor -fullscreen. REM -rootless REM Use a transparent root window with an external window manager REM (such as twm). Not to be used with -multiwindow nor REM with -fullscreen. REM -fullscreen REM Use a window as large as possible on the primary monitor. REM -multiplemonitors REM Create a root window that covers all monitors on a REM system with multiple monitors. REM -clipboard REM Enable the integrated version of xwinclip. Do not use in REM conjunction with the xwinclip program. REM -depth bits_per_pixel REM Specify the screen depth to run at (in bits per pixel) using a REM DirectDraw-based engine in conjunction with the -fullscreen REM option, ignored if the -fullscreen option is not specified. REM By default, you will be using a DirectDraw based engine on any REM system that supports it. REM -unixkill REM Trap Ctrl+Alt+Backspace as a server shutdown key combination. REM -nounixkill REM Disable Ctrl+Alt+Backspace as a server shutdown key combination (default). REM Example: REM XWin -unixkill -screen 0 -screen 1 -screen 2 -nounixkill REM Screens 0 and 1 will allow Ctrl+Alt+Backspace, but screen 2 will not. REM -winkill REM Trap Alt+F4 as a server shutdown key combination (default). REM -nowinkill REM Disable Alt+F4 as a server shutdown key combination. REM -scrollbars REM Enable resizing of the server display window. Do not use in conjunction REM with -multiwindow nor with -rootless. REM -nodecoration REM Draw the server root window without a title bar or border. REM Do not use with -mutliwindow nor with -rootless. REM -lesspointer REM Hide the Windows mouse cursor anytime it is over any part of the REM window, even if Cygwin/X is not the window with the focus. REM -refresh rate_in_Hz REM Specify a refresh rate to use when used with the -fullscreen option. REM -trayicon REM Enable the tray icon (default). REM -notrayicon REM Disable the tray icon. REM Example: REM XWin -notrayicon -screen 0 -screen 1 -screen 2 -trayicon REM Screens 0 and 1 will not have tray icons, but screen 2 will. REM -emulate3buttons [timeout] REM Emulate 3 button mouse with an optional timeout in milliseconds. REM -xf86config REM Specify an XF86Config-style configuration file. REM -keyboard REM Specify a keyboard device from the configuration file. REM Startup the X Server with the integrated Windows-based window manager. REM WARNING: Do not use 'xwinclip' in conjunction with the ``-clipboard'' REM command-line parameter for XWin. Doing so would start two clipboard REM managers, which is never supposed to happen. rem start XWin -multiwindow -clipboard -emulate3buttons -silent-dup-error rem %RUN% XWin -multiwindow -clipboard -silent-dup-error rem This worked but was harmonized with later code from epaDell install rem %RUN% XWin -multiwindow -clipboard -emulate3buttons -silent-dup-error %RUN% XWin -multiwindow -clipboard -emulate3buttons -silent-dup-error -xkblayout us :START-XTERM REM Startup an xterm, using bash as the shell. REM -l==logging, must be @ end of line! else causes xterm cwd==/usr/bin REM -sl==buffer lines to save REM +tb==xterm should not start with a toolbar rem This runs, but was harmonized with epaDell rem %RUN% xterm +tb -sl 1000 -sb -rightbar -ms red -fg black -bg white -e /usr/bin/bash --login rem Start moving args to .Xdefaults %RUN% xterm -tb -sl 9999 -sb -rightbar -e /usr/bin/bash --login -l REM Startup rxvt rem WORKS run urxvt-X -e /usr/bin/bash rem WORKS run urxvt-X -bg white -fg black -e /usr/bin/bash AND COMES UP WITH SCROLLBAR TO RIGHT rem MOVE OPTIONS TO ~/.Xdefaults rem This works (though starts in /usr/bin) but does not use %RUN% rem run urxvt-X -e /usr/bin/bash rem This fails if -r ~/.Xdefaults rem %RUN% urxvt-X -bg white -fg black -ms red -e /usr/bin/bash -l %RUN% urxvt-X -e /usr/bin/bash -l -------------- next part -------------- A non-text attachment was scrubbed... Name: .xinitrc Type: application/octet-stream Size: 762 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: .Xresources Type: application/octet-stream Size: 1104 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: XWin.0.log Type: application/octet-stream Size: 976 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cygcheck.out Type: application/octet-stream Size: 155816 bytes Desc: not available URL: -------------- next part -------------- -- 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/ From nyc4bos@aol.com Mon Sep 19 01:35:00 2011 From: nyc4bos@aol.com (nyc4bos@aol.com) Date: Mon, 19 Sep 2011 01:35:00 -0000 Subject: XWin 1.10.3-12 wont start Message-ID: <84sjo1gtvz.fsf@aol.com> Hi, I reinstalled xinit and xorg-server (Cygwin) because it wont start. I posted this on the Cygwin Ports newsgroup but think this is a general problem that I could received debugging information/steps from the Xfree group. When I start up X via: # startx -- :0 -clipboard -nolock& The window comes up blank and then closed (exits). I see on the terminal: # xinit: XFree86_VT property unexpectedly has 0 items instead of 1 /etc/X11/xinit/xinitrc: line 53: xclock: command not found/etc/X11/xinit/xinitrc : line 52: twm: command not found xinit: connection to X server lost waiting for X server to shut down [1]+ Done startx -- :0 -clipboard -nolock I expected to see 3 xterms. (I know about xclock and twm not starting because I did not and do not want to install these programs.) How does one debug this? The /var/log/xwin/XWin.0.log log file has: Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.10.3.0 OS: Windows XP Service Pack 3 [Windows NT 5.1 build 2600] (Win32) Package: version 1.10.3-12 built 2011-08-22 XWin was started with the following command line: /usr/bin/X :0 -clipboard -nolock -auth /home/Owner/.serverauth.500 ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1680 h 1050 winInitializeDefaultScreens - native DPI x 96 y 96 _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/station04:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 [ 33155.468] (II) xorg.conf is not supported [ 33155.468] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [ 33155.468] LoadPreferences: /home/Owner/.XWinrc not found [ 33155.468] LoadPreferences: Loading /etc/X11/system.XWinrc [ 33155.468] LoadPreferences: Done parsing the configuration file... [ 33155.468] winDetectSupportedEngines - DirectDraw installed, allowing ShadowDD [ 33155.468] winDetectSupportedEngines - Windows NT, allowing PrimaryDD [ 33155.468] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL [ 33155.468] winDetectSupportedEngines - Returning, supported engines 0000001f [ 33155.468] winTaskbarInit - Could not get SHGetPropertyStoreForWindow address [ 33155.468] winSetEngine - Using Shadow DirectDraw NonLocking [ 33155.468] winScreenInit - Using Windows display depth of 32 bits per pixel [ 33155.515] winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff [ 33155.515] Screen 0 added at virtual desktop coordinate (0,0). [ 33155.531] MIT-SHM extension disabled due to lack of kernel support [ 33155.546] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel [ 33155.968] (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so [ 33155.968] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 33155.968] [dix] Could not init font path element /usr/share/fonts/TTF/, removing from list! [ 33155.984] [dix] Could not init font path element /usr/share/fonts/Type1/, removing from list! [ 33156.828] winPointerWarpCursor - Discarding first warp: 837 492 [ 33156.828] (--) 3 mouse buttons found [ 33156.828] (--) Setting autorepeat to delay=500, rate=31 [ 33156.828] (--) Windows keyboard layout: "00000409" (00000409) "US", type 4 [ 33156.828] (--) Found matching XKB configuration "English (USA)" [ 33156.828] (--) Model = "pc105" Layout = "us" Variant = "none" Options = "none" [ 33156.828] Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options = "none" [ 33156.828] winBlockHandler - pthread_mutex_unlock() [ 33157.562] winClipboardProc - DISPLAY=:0.0 [ 33157.562] winProcEstablishConnection - winInitClipboard returned. [ 33157.562] winClipboardProc - XOpenDisplay () returned and successfully opened the display. [ 33158.046] winClipboardProc - winClipboardFlushWindowsMessageQueue trapped WM_QUIT message, exiting main loop. [ 33158.046] winClipboardProc - XDestroyWindow succeeded. [ 33158.046] winClipboardProc - Clipboard disabled - Exit from server [ 33158.140] winDeinitMultiWindowWM - Noting shutdown in progress Thanks. -- 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/ From Tom_Roche@pobox.com Sun Sep 25 04:03:00 2011 From: Tom_Roche@pobox.com (Tom Roche) Date: Sun, 25 Sep 2011 04:03:00 -0000 Subject: how to set X resources in Cygwin? In-Reply-To: References: Message-ID: <87wrcxmfon.fsf@pobox.com> bumpity-bump: http://cygwin.com/ml/cygwin-xfree/2011-09/msg00016.html ... > Date: Sun, 18 Sep 2011 22:14:23 +0100 ... > summary: I'm running an up-to-date cygwin X on wxpsp3. I get both > xterm and urxvt-X to start, but cannot get either to pickup settings > from .Xdefaults or .Xresources. What am I doing wrong? > details: ... Assistance would be sincerely appreciated! -- 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/ From Andrew.DeFaria@tellabs.com Mon Sep 26 17:16:00 2011 From: Andrew.DeFaria@tellabs.com (Andrew DeFaria) Date: Mon, 26 Sep 2011 17:16:00 -0000 Subject: how to set X resources in Cygwin? In-Reply-To: <87wrcxmfon.fsf@pobox.com> References: <87wrcxmfon.fsf@pobox.com> Message-ID: On 9/24/2011 9:03 PM, Tom Roche wrote: > bumpity-bump: > http://cygwin.com/ml/cygwin-xfree/2011-09/msg00016.html > ... >> Date: Sun, 18 Sep 2011 22:14:23 +0100 > ... > >> summary: I'm running an up-to-date cygwin X on wxpsp3. I get both >> xterm and urxvt-X to start, but cannot get either to pickup settings >> from .Xdefaults or .Xresources. What am I doing wrong? >> details: > ... > > Assistance would be sincerely appreciated! BTW, instead of Xterm and Rxvt you might look into using mintty from Cygwin itself. It's a quite nice terminal emulator. I use ~/.Xdefaults a lot (well less now...). My thought is: Is $HOME set correctly for X? I would have thought an xrdb -load ~/.Xdefaults would be a cure all (provided you xrdb'ed it to the proper X server!). Out of curiosity, what does ax xrdb -query reveal? -- Andrew DeFaria Anyone who has the power to make you believe absurdities has the power to make you commit injustices. -- 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/ From Tom_Roche@pobox.com Tue Sep 27 16:58:00 2011 From: Tom_Roche@pobox.com (Tom Roche) Date: Tue, 27 Sep 2011 16:58:00 -0000 Subject: how to set X resources in Cygwin? In-Reply-To: <87wrcxmfon.fsf@pobox.com> References: <87wrcxmfon.fsf@pobox.com> <1317057402.14012.ezmlm@cygwin.com> Message-ID: <87wrctdira.fsf@pobox.com> Tom Roche Sun, 18 Sep 2011 22:14:23 +0100 > summary: I'm running an up-to-date cygwin X on wxpsp3. I get both > xterm and urxvt-X to start, but cannot get either to pickup settings > from .Xdefaults or .Xresources. What am I doing wrong? Andrew DeFaria Mon, 26 Sep 2011 10:15:48 -0700 (rearranged) > Is $HOME set correctly for X? Dunno what you mean by "for X." $HOME looks correct to me: # after starting X, in xterm tlroche@tlrZ61t ~$ echo -e "${HOME}" /home/tlroche > I would have thought an xrdb -load ~/.Xdefaults would be a cure all > (provided you xrdb'ed it to the proper X server!). > Out of curiosity, what does ax xrdb -query reveal? tlroche@tlrZ61t ~$ xrdb -query tlroche@tlrZ61t ~$ xrdb -query | wc -l 0 tlroche@tlrZ61t ~$ xrdb -all -query | wc -l 0 tlroche@tlrZ61t ~$ cat .Xdefaults ! copy/mod from ! http://www.saltycrane.com/blog/2007/09/cygwin-x-ratposoin-screen-rxvt-setup/ ! https://wiki.archlinux.org/index.php/X_resources#Xterm_resources ! Note: ! * need to capitalize first letter (or 2) of application? see ! http://xwinman.org/resource.php XTerm*background: white ! XTerm*foreground: black XTerm*cursorColor: red XTerm*font: xft:Bitstream Vera Sans Mono:size=8 XTerm*boldFont: xft:Bitstream Vera Sans Mono:size=8:style=Bold XTerm*scrollBar: True XTerm*rightScrollBar: True XTerm*scrollKey: True XTerm*saveLines: 9999 XTerm*toolBar: True !! see https://wiki.archlinux.org/index.php/Urxvt Urxvt*background: white Urxvt*foreground: black ! run "fc-list" for a list of available fonts Urxvt*font: xft:Bitstream Vera Sans Mono:size=8 Urxvt*boldFont: xft:Bitstream Vera Sans Mono:size=8:style=Bold URxvt*scrollBar: False URxvt*scrollTtyOutput: False URxvt*scrollTtyKeypress: True URxvt*secondaryScroll: True URxvt*saveLines: 9999 URxvt.perl-ext-common: default,tabbed tlroche@tlrZ61t ~$ xrdb -load ~/.Xdefaults tlroche@tlrZ61t ~$ xrdb -query XTerm*background: white XTerm*cursorColor: red XTerm*font: xft:Bitstream Vera Sans Mono:size=8 XTerm*boldFont: xft:Bitstream Vera Sans Mono:size=8:style=Bold XTerm*scrollBar: True XTerm*rightScrollBar: True XTerm*scrollKey: True XTerm*saveLines: 9999 XTerm*toolBar: True Urxvt*background: white Urxvt*foreground: black Urxvt*font: xft:Bitstream Vera Sans Mono:size=8 Urxvt*boldFont: xft:Bitstream Vera Sans Mono:size=8:style=Bold URxvt*scrollBar: False URxvt*scrollTtyOutput: False URxvt*scrollTtyKeypress: True URxvt*secondaryScroll: True URxvt*saveLines: 9999 URxvt.perl-ext-common: default,tabbed But if I restart X: no change in display of xterm or urxvt-X And if I restart wXP: no change. > BTW, instead of Xterm and Rxvt you might look into using mintty from > Cygwin itself. It's a quite nice terminal emulator. I'll give that a try, except that I think I should solve this first: not using .Xdefaults seems like a prior issue. Or should I instead just invoke my X apps with ginormous command lines? TIA, Tom Roche -- 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/ From Andrew.DeFaria@tellabs.com Tue Sep 27 21:28:00 2011 From: Andrew.DeFaria@tellabs.com (Andrew DeFaria) Date: Tue, 27 Sep 2011 21:28:00 -0000 Subject: how to set X resources in Cygwin? In-Reply-To: <87wrctdira.fsf@pobox.com> References: <87wrcxmfon.fsf@pobox.com> <1317057402.14012.ezmlm@cygwin.com> <87wrctdira.fsf@pobox.com> Message-ID: On 9/27/2011 9:58 AM, Tom Roche wrote: > Tom Roche Sun, 18 Sep 2011 22:14:23 +0100 >> summary: I'm running an up-to-date cygwin X on wxpsp3. I get both >> xterm and urxvt-X to start, but cannot get either to pickup settings >> from .Xdefaults or .Xresources. What am I doing wrong? > Andrew DeFaria Mon, 26 Sep 2011 10:15:48 -0700 (rearranged) >> Is $HOME set correctly for X? > Dunno what you mean by "for X." $HOME looks correct to me: I merely mean that ~/.Xdefaults is the same file for both bash and X (sometimes the setting of the HOME environment is incorrect set to something like C:\Users\ or some other Windows path). > # after starting X, in xterm > tlroche@tlrZ61t ~$ echo -e "${HOME}" Hmm... No need for all that syntactic sugar "echo $HOME" would have achieve the necessary effect. > /home/tlroche > >> I would have thought an xrdb -load ~/.Xdefaults would be a cure all >> (provided you xrdb'ed it to the proper X server!). >> Out of curiosity, what does ax xrdb -query reveal? > tlroche@tlrZ61t ~$ xrdb -query > tlroche@tlrZ61t ~$ xrdb -query | wc -l > 0 > tlroche@tlrZ61t ~$ xrdb -all -query | wc -l > 0 I would not expect the X Resource DataBase to have anything in it before you -load it > tlroche@tlrZ61t ~$ cat .Xdefaults > ! copy/mod from > ! http://www.saltycrane.com/blog/2007/09/cygwin-x-ratposoin-screen-rxvt-setup/ > ! https://wiki.archlinux.org/index.php/X_resources#Xterm_resources > ! Note: > ! * need to capitalize first letter (or 2) of application? see > ! http://xwinman.org/resource.php > > XTerm*background: white > ! XTerm*foreground: black > XTerm*cursorColor: red > XTerm*font: xft:Bitstream Vera Sans Mono:size=8 > XTerm*boldFont: xft:Bitstream Vera Sans Mono:size=8:style=Bold > XTerm*scrollBar: True > XTerm*rightScrollBar: True > XTerm*scrollKey: True > XTerm*saveLines: 9999 > XTerm*toolBar: True > > !! see https://wiki.archlinux.org/index.php/Urxvt > Urxvt*background: white > Urxvt*foreground: black > ! run "fc-list" for a list of available fonts > Urxvt*font: xft:Bitstream Vera Sans Mono:size=8 > Urxvt*boldFont: xft:Bitstream Vera Sans Mono:size=8:style=Bold > URxvt*scrollBar: False > URxvt*scrollTtyOutput: False > URxvt*scrollTtyKeypress: True > URxvt*secondaryScroll: True > URxvt*saveLines: 9999 > URxvt.perl-ext-common: default,tabbed > > tlroche@tlrZ61t ~$ xrdb -load ~/.Xdefaults > > tlroche@tlrZ61t ~$ xrdb -query > XTerm*background: white > XTerm*cursorColor: red > XTerm*font: xft:Bitstream Vera Sans Mono:size=8 > XTerm*boldFont: xft:Bitstream Vera Sans Mono:size=8:style=Bold > XTerm*scrollBar: True > XTerm*rightScrollBar: True > XTerm*scrollKey: True > XTerm*saveLines: 9999 > XTerm*toolBar: True > Urxvt*background: white > Urxvt*foreground: black > Urxvt*font: xft:Bitstream Vera Sans Mono:size=8 > Urxvt*boldFont: xft:Bitstream Vera Sans Mono:size=8:style=Bold > URxvt*scrollBar: False > URxvt*scrollTtyOutput: False > URxvt*scrollTtyKeypress: True > URxvt*secondaryScroll: True > URxvt*saveLines: 9999 > URxvt.perl-ext-common: default,tabbed OK, so your resources are set. > But if I restart X: no change in display of xterm or urxvt-X Why restart X? I bet restarting X will start with a fresh, empty resource database. Note that I agree with you - X should just be reading your ~/.Xdefaults properly without the need to xrdb -load. What I'm trying to see is if xrdb -load fixes the problem. IOW does X now see the resources. It should. Then we can look at why it's not reading them from ~/.Xdefaults automagically. Here's some more research material: http://www.google.com/search?gcx=c&sourceid=chrome&ie=UTF-8&q=Xdefaults+cygwin+xorg+not+reading > And if I restart wXP: no change. What's "wXP"? Windows XP? >> BTW, instead of Xterm and Rxvt you might look into using mintty from >> Cygwin itself. It's a quite nice terminal emulator. > I'll give that a try, except that I think I should solve this first: not using .Xdefaults seems like a prior issue. Yes, while this may solve your term needs, it solves no other X application need so yes you should solve the problem. > Or should I instead just invoke my X apps with ginormous command lines? Lot's of people do but I'm not a big fan of that. I believe having control in a conf file a much better way. Sorta like the difference between embedding CSS