public inbox for cygwin-xfree@sourceware.org
help / color / mirror / Atom feed
From: Jon TURNEY <jon.turney@dronecode.org.uk>
To: cygwin-xfree@cygwin.com
Cc: lukashaase@gmx.at
Subject: Re: XWin ignores all parameters related to multiple monitors
Date: Thu, 08 May 2014 12:15:00 -0000	[thread overview]
Message-ID: <536B755C.2040602@dronecode.org.uk> (raw)
In-Reply-To: <lkblmh$fui$1@ger.gmane.org>

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/


  reply	other threads:[~2014-05-08 12:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-04  6:06 Lukas Haase
2014-05-05 20:03 ` Jon TURNEY
2014-05-06 21:54   ` Lukas Haase
2014-05-08 12:15     ` Jon TURNEY [this message]
2014-05-08 23:28       ` Lukas Haase
2014-05-09 10:15         ` Jon TURNEY
2014-05-09 20:26           ` Lukas Haase
2014-06-19 21:38             ` Jon TURNEY

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=536B755C.2040602@dronecode.org.uk \
    --to=jon.turney@dronecode.org.uk \
    --cc=cygwin-xfree@cygwin.com \
    --cc=lukashaase@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).