From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11809 invoked by alias); 6 Jul 2014 16:27:20 -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 11759 invoked by uid 89); 6 Jul 2014 16:27:16 -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: smtpout07.bt.lon5.cpcloud.co.uk Received: from smtpout07.bt.lon5.cpcloud.co.uk (HELO smtpout07.bt.lon5.cpcloud.co.uk) (65.20.0.127) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 06 Jul 2014 16:27:13 +0000 X-CTCH-RefID: str=0001.0A090206.53B978DD.00D9,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.7.6.111819: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, __IN_REP_TO, __CT, __CT_TEXT_PLAIN, __CTE, __STOCK_PHRASE_7, __INT_PROD_COMP, __SUBJ_ALPHA_NEGATE, __FORWARDED_MSG, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, REPLYTO_FROM_DIFF_ADDY, BODY_SIZE_7000_LESS, NO_URI_FOUND X-CTCH-Spam: Unknown Received: from [192.168.1.93] (86.179.19.103) by smtpout07.bt.lon5.cpcloud.co.uk (8.6.100.99.10223) (authenticated as jonturney@btinternet.com) id 53B85BEE0005114A; Sun, 6 Jul 2014 17:27:09 +0100 Message-ID: <53B978DA.3040305@dronecode.org.uk> Date: Sun, 06 Jul 2014 16:27: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.6.0 MIME-Version: 1.0 To: cygwin-xfree@cygwin.com CC: matt@codespunk.com Subject: Re: Wine creating windows offscreen when "multiwindow" is used? References: <53B5DD59.5020302@codespunk.com> In-Reply-To: <53B5DD59.5020302@codespunk.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-07/txt/msg00005.txt.bz2 On 03/07/2014 23:46, Matt D. wrote: > I have a monitor configuration with three 1920x1080 monitors aligned > side-by-side horizontally with a fourth above the center. The primary > monitor is the center one at the bottom. xinit generates a single screen > 5760x2160 to cover the area. The root window is hidden and all windows > in the buffer are drawn with native Windows decorations. > > When an X window is created at 0,0, it is visible on the primary > monitor, despite 0,0 in the buffer being offscreen. This is great. > However, when Wine creates a window at 0,0, it is aligned to 0,0 in the > buffer (-1920x-1080 screen coordinates on Windows) and is not visible. > > Is there a solution for this? This is a discrepancy between what regular > X windows do and where Wine positions its windows. > > I also noticed that when creating a window with XCreateSimpleWindow, the > x and y coordinates are ignored. For example, I would expect a window > created at 0,0 in the X buffer to be visible at 0,0 screen coordinates; > but instead it's just somewhere offset slightly from the top left of the > primary monitor. Any x/y coordinates specified do not seem to affect > where it goes. Normally, an X window manager ignores the x,y position specified for the window when it's created, and places the window according to some heuristic (for example, try to ensure that windows don't completely overlap) The -multiwindow mode window manager defers to Windows native window placement (which appears to be something like placing the ith window created at x=y=30+26*(i%9)) But, if the PPosition or USPosition flags in WM_NORMAL_HINTS are set, the -multiwindow mode window manager places the window as requested. (Most toolkits will set USPosition if you explicitly specify a window position e.g. using a -geometry option) I guess that Wine is setting one of these flags so it can emulate Windows window placement. > The behavior I would expect is for 0,0 in the buffer to be mapped to 0,0 > in screen coordinates, 1920x, 1080y in my configuration. Unfortunately, X window coordinates are defined to be positive, with 0,0 being the top-left of the desktop. So, while you could do this with the -screen option (e.g -screen 0 @1), to move the origin to your primary monitor, windows which are moved to the left or above of that probably won't render correctly. If you can't turn off the placement behaviour in Wine, perhaps the best compromise might be to use something like '-screen 0 5760x1080+0+1080' so you have an X desktop which covers the bottom 3 screens, and avoid moving X windows into the 4th screen? > To clarify my use of Wine, I connected to a remote CentOS 6.5 machine > via ssh with x forwarding for testing. > > Can anyone provide some insight on this? There is some code in XWin which attempts to ensure that the window is placed somewhere visible, but that assumes that the Window virtual desktop is a rectangle of size GetSystemMetrics(SM_CXVIRTUALSCREEN) x GetSystemMetrics(SM_CYVIRTUALSCREEN). I think it should be pretty straightforward to change this, perhaps to use MonitorFromPoint() to determine if the window will be visible on a non-rectangular virtual desktop. -- 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/