From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7507 invoked by alias); 8 May 2014 12:15:32 -0000 Mailing-List: contact cygwin-xfree-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner@cygwin.com Reply-To: cygwin-xfree@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com Received: (qmail 7485 invoked by uid 89); 8 May 2014 12:15:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: smtpout04.bt.lon5.cpcloud.co.uk Received: from smtpout04.bt.lon5.cpcloud.co.uk (HELO smtpout04.bt.lon5.cpcloud.co.uk) (65.20.0.124) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 May 2014 12:15:29 +0000 X-CTCH-RefID: str=0001.0A090201.536B755E.007E,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 X-Junkmail-Premium-Raw: score=8/97,refid=2.7.2:2014.5.6.170619:17:8.317,ip=,rules=__MOZILLA_MSGID, __HAS_MSGID, __SANE_MSGID, __HAS_FROM, __HAS_REPLYTO, __USER_AGENT, __MOZILLA_USER_AGENT, __MIME_VERSION, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __IN_REP_TO, __CT, __CT_TEXT_PLAIN, __CTE, __ANY_URI, __URI_NO_MAILTO, __URI_NO_WWW, __CP_URI_IN_BODY, __SUBJ_ALPHA_NEGATE, __FORWARDED_MSG, BODY_SIZE_4000_4999, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, REPLYTO_FROM_DIFF_ADDY, BODY_SIZE_7000_LESS X-CTCH-Spam: Unknown Received: from [192.168.1.93] (86.174.34.48) by smtpout04.bt.lon5.cpcloud.co.uk (8.6.100.99.10223) (authenticated as jonturney@btinternet.com) id 535F74FB009472A4; Thu, 8 May 2014 13:15:25 +0100 Message-ID: <536B755C.2040602@dronecode.org.uk> Date: Thu, 08 May 2014 12:15:00 -0000 From: Jon TURNEY Reply-To: cygwin-xfree@cygwin.com User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: cygwin-xfree@cygwin.com CC: lukashaase@gmx.at Subject: Re: XWin ignores all parameters related to multiple monitors References: <5367EE90.4000205@dronecode.org.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-05/txt/msg00005.txt.bz2 On 06/05/2014 22:54, Lukas Haase wrote: > On 2014-05-05 13:03, Jon TURNEY wrote: >> On 04/05/2014 06:56, Lukas Haase wrote: >>> I use Cygwin/X to display a CAD application on my Windows cient. For >>> some reason new windows always open on the secondary display and I >>> always need to manually drag them to my primary display. That's sooo >>> annoying (since UNIX applications tend to open new windows on every >>> action). > >> I think that it's a bug that these windows are appearing at the >> top-left, rather than on the primary display, in that we don't >> distinguish well enough between "the application asked us to place the >> window at 0x0" and "the application didn't specify where to put the window" >> >> It would help if you could give the name of this application, and can >> you install 'xprop', and show the output you get from running that, then >> clicking on one of the window which gets placed incorrectly. > > Sure. > > It's Cadence Virtuoso/ADE. > > The xprop output is: [...] > WM_NORMAL_HINTS(WM_SIZE_HINTS): > program specified location: 0, 0 > program specified minimum size: 100 by 100 > program specified maximum size: 3820 by 2500 Hmmm... There are 2 possible flags here: "program specified location" and "user specified location" (e.g. by using -geometry on the command line), and at the moment we honour them both. Now, it might be that the client expects to see some EWMH capabilities advertised by the multiwindow mode WM, the absence of which causes it to set this, or it only sets this after the window is placed, but if it always creates the window with that property, it's not clear how to fix this. (Just ignoring "program specified location" is tempting, but there are legitimate uses, for example a toolbar window which should be placed at the side) So, do you have an example of this working as you would like on a unix system, and what is the window manager is that case? I've built a snapshot [1], which adds a heuristic which ignores a 'program specified location' hint if the location is the origin, which you might like to try and see if that fixes your problem, but I'm not sure if that is the correct solution. (I also found a bug with how this hint is handled in 64-bit builds, but I don't think that affects you) [1] ftp://cygwin.com/pub/cygwinx/x86/XWin.20140508-git-c4a16a6606868d3e.exe.bz2 >> This is not how it behaves for me. Using -nomultiplemontiors, or an >> explicit -screen setting shows an appropriately sized root window when >> turning off "Hide Root Window". (Although this is not terribly useful as >> you can move the Windows windows out of this area, which causes their >> contents to not be drawn) > > You are right. Further research shows me that my arguments never showed > up in XWin.0.log. Maybe I there's a different bug here? > > I call XWin like this: > > C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe -- > -nomultimonitors > > And this appears in XWin.0.log: > > XWin was started with the following command line: > > X :0 -multiwindow You need to quote the whole command after bash's -c flag, otherwise they are interpreted as additional flags to bash. See http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-command-line-args for an example. > However, unfortunately this does not change anything: You are right that > when I uncheck "Hide Root window", the black root window *only* covers > the primary monitor. That's good. > > But windows are *still* opened at the second monitor! > > What's even worse (and pretty astonishing to me): All X windows are > *only* displayed correctly on the *secondary* display with the command > line above. On the primary display, the window frames are shown but the > windows are not drawn (they are transparent) and they do not accept > mouse/keyboard input. > > So it's completely the opposite as it is intended ... Yes, it seems there is also something wrong with the translation between Windows (which has 0,0 at the top-left of the primary monitor) and X (which has 0,0 at the top-left of the virtual screen) coordinate spaces here. But even if that was fixed, there is still the problem of how X windows are supposed to behave when moved off the virtual screen (not allowed to move? empty?) Because of that, assuming that I can fix your problem with correct window placement, I am inclined to just disable the combination of -multiwindow and -screen. -- 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/