Re: XWin ignores all parameters related to multiple monitors

[Lukas Haase <lukashaase@gmx.at>]

Hi Jon,

First of all, thank you so much for your effort!
I am struggling for so long with the issue and I am so happy to see your
encouragement here.

On 2014-05-08 5:15, Jon TURNEY wrote:
> On 06/05/2014 22:54, Lukas Haase wrote:
>> On 2014-05-05 13:03, Jon TURNEY wrote:
>>> [...]
>>> 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.

Thank you! I think I understand it (I am no X expert).

> (Just ignoring "program specified location" is tempting, but there are
> legitimate uses, for example a toolbar window which should be placed at
> the side)

Sounds legitimate.

Aside: Maybe it's possible to make this configurable via config or
environment variable? (but I guess the X server does not see environment
variables etc.)

> 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 am not sure if I get the question.

What I could do is to login via VNC and see how the windows are placed
are if they are placed the correct way?

Is this what you mean?

Unfortunately I have no chance to install Cadence locally and run it
from a local, dual monitor setup from Linux because Cadence is a
proprietary, expensive tool.

> 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

Thanks so much for that!

I have just the issue that the exe does not seem to work for me. Is
there anything special I need to consider?

I tried copying both, 63 and 32 bit versions to c:\cygwin\bin:

32 bit version gives:

c:\cygwin\bin>XWin.new.32
XWin.new.32:./.libs/lt-XWin.c:233: FATAL: couldn't find XWin.new.32.


And 64 bit gives: "The application was unable to start correctly
(0xc000007b). Click OK to close the application".

What bothers me is that my original XWin.exe has 2363943 Bytes (and the
X icon) whereas your new versions are just 26624 and 27150 Byes (and no
icon).

c:\cygwin\bin>uname -a
CYGWIN_NT-6.2-WOW64 think 1.7.29(0.272/5/3) 2014-04-07 13:44 i686 Cygwin

>> [...]
>> 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.

Thanks but I think I have tried that already.
It may be hard to believe but:

c:\cygwin\var\log\xwin>del XWin.0.log

c:\cygwin\var\log\xwin>C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c
"/usr/bin/startxwin.exe -- -nomultimonitors -foobar"

c:\cygwin\var\log\xwin>c:\cygwin\bin\head -n 10 XWin.0.log
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.15.1.0
OS: CYGWIN_NT-6.2-WOW64 think 1.7.29(0.272/5/3) 2014-04-07 13:44 i686
OS: Windows 8  [Windows NT 6.2 build 9200] (WoW64)
Package: version 1.15.1-1 built 2014-04-16

XWin was started with the following command line:

X :0 -multiwindow

c:\cygwin\var\log\xwin>

I made sure that XWin was not running before and waited after the call
until I saw the tray icon.

>> [...]
>> 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.

I mean something different here: Even when I just start the local
xterm.exe the problem appears. And it's reproduceable:

XWin was started with the following command line:
XWin -screen 0 @1 -multiwindow -nomultimonitors

When, if I start xterm.exe, it is not rendered on the *primary* monitor
at all (only the window frame is and whichever content was previously
displayed in the window).

Only if I drag the xterm window to the secondary display (which is not
even supposed to exist now), the content is updated/rendered.

> 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?)

I am not sure if I understand the question but in my humble
understanding this can't just happen: it would behave the same as if you
moved the window out of the monitor. The part moved out is just not
displayed.

> 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.

I understand. I have no idea about the implications and the
implementation details; in my humble understanding it would just work as
described above ;-) But that's probably too simplified ...


Thanks,
Luke




--
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/