XWin ignores all parameters related to multiple monitors

XWin ignores all parameters related to multiple monitors

[Lukas Haase]

Hi,

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

To avoid this, I want to disable the second monitor (and *only* use the
primary). But whatever I do, XWin seems to ignore whatever I supply. For
example, I start

/usr/bin/startxwin.exe -- -nomultiplemonitors
/usr/bin/startxwin.exe -- -screen 0 @1 -nomultiplemonitors
/usr/bin/startxwin.exe -- -screen 0 @1
/usr/bin/startxwin.exe -- -mwextwm -screen 0 @1 -nomultiplemonitors

and so on.
Nothing works - everything as before. When I select "Hide Root Window"
from the tray icon I see that the root window indeed covers both monitors.

Any suggestions?

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/

Re: XWin ignores all parameters related to multiple monitors

[Jon TURNEY]

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'm assuming that your secondary display is to the left of your primary 
display.

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.

> To avoid this, I want to disable the second monitor (and *only* use the
> primary). But whatever I do, XWin seems to ignore whatever I supply. For
> example, I start
>
> /usr/bin/startxwin.exe -- -nomultiplemonitors
> /usr/bin/startxwin.exe -- -screen 0 @1 -nomultiplemonitors
> /usr/bin/startxwin.exe -- -screen 0 @1
> /usr/bin/startxwin.exe -- -mwextwm -screen 0 @1 -nomultiplemonitors
>
> and so on.
> Nothing works - everything as before. When I select "Hide Root Window"
> from the tray icon I see that the root window indeed covers both monitors.

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)

Can you check if the screen dimensions reported by xdpyinfo match those 
you are requesting, and attach your /var/log/xwin/XWin.0.log?

Separately, it's possible that we should do something better with the 
combination of -nomultiplemontors and -multiwindow, but it's not quite 
clear to me what.  (See discussion [1])

[1] https://sourceware.org/ml/cygwin-xfree/2011-07/msg00007.html

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

Re: XWin ignores all parameters related to multiple monitors

[Lukas Haase]

[-- Attachment #1: Type: text/plain, Size: 6441 bytes --]

Hi Jon,

Thanks for helping!

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'm assuming that your secondary display is to the left of your primary
> display.

Yes.
Secondary: builtin laptop display (on left)
Primary: main monitor (on right)

If I do "Identify", the laptop display is identified as "1" and the main
monitor as "2".

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

_WINDOWSWM_NATIVE_HWND(INTEGER) = 77728452
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
		bitmap id # to use for icon: 0x200178
		bitmap id # of mask for icon: 0x200179
		window id # of group leader: 0x200001
_NET_WM_ICON(CARDINAL) = 	Icon (50 x 50):
[...]


_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 2097527
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_USER_TIME(CARDINAL) = 744838078
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x200176
WM_CLIENT_LEADER(WINDOW): window id # 0x200001
_NET_WM_PID(CARDINAL) = 24636
WM_LOCALE_NAME(STRING) = "C"
WM_CLIENT_MACHINE(STRING) = "corn"
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
		window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS,
_NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "Qt-subapplication", "Virtuoso"
WM_ICON_NAME(STRING) = "Virtuoso® Schematic Editor L Editing: project
sch1 schematic on corn"
_NET_WM_ICON_NAME(UTF8_STRING) = "Virtuoso® Schematic Editor L Editing:
project sch1 schematic on corn"
WM_NAME(STRING) = "Virtuoso® Schematic Editor L Editing: project sch1
schematic on corn"
_NET_WM_NAME(UTF8_STRING) = "Virtuoso® Schematic Editor L Editing:
project sch1 schematic on corn"

>> To avoid this, I want to disable the second monitor (and *only* use the
>> primary). But whatever I do, XWin seems to ignore whatever I supply. For
>> example, I start
>>
>> /usr/bin/startxwin.exe -- -nomultiplemonitors
>> /usr/bin/startxwin.exe -- -screen 0 @1 -nomultiplemonitors
>> /usr/bin/startxwin.exe -- -screen 0 @1
>> /usr/bin/startxwin.exe -- -mwextwm -screen 0 @1 -nomultiplemonitors
>>
>> and so on.
>> Nothing works - everything as before. When I select "Hide Root Window"
>> from the tray icon I see that the root window indeed covers both
>> monitors.
> 
> 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


However, if I directly start the XServer,
  XWin.exe -screen 0 @1 -multiwindow -nomultimonitors
it works:

XWin was started with the following command line:

XWin -screen 0 @1 -multiwindow -nomultimonitors

Why does startxwin.exe does not pass the parameters to the XServer.


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 oppisite as it is intended ...

> Can you check if the screen dimensions reported by xdpyinfo match those
> you are requesting, and attach your /var/log/xwin/XWin.0.log?

Hmm, I have here:
[...]
default screen number:    0
number of screens:    1

screen #0:
  dimensions:    1920x1080 pixels (508x286 millimeters)
  resolution:    96x96 dots per inch
  depths (7):    24, 1, 4, 8, 15, 16, 32
  root window id:    0x6b
  depth of root window:    24 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x20
  default number of colormap cells:    256
  preallocated pixels:    black 0, white 16777215
  options:    backing-store WHEN MAPPED, save-unders NO
  largest cursor:    32x32
  current input event mask:    0x4a0007
    KeyPressMask             KeyReleaseMask           ButtonPressMask

    StructureNotifyMask      SubstructureNotifyMask   PropertyChangeMask

  number of visuals:    21
  default visual id:  0x21
  visual:
    visual id:    0x21
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits
[...]

I think that's fine.

XWin.0.log with the command line from above is attached.

> Separately, it's possible that we should do something better with the
> combination of -nomultiplemontors and -multiwindow, but it's not quite
> clear to me what.  (See discussion [1])

I would reaaaally appreciate that.
Unfortunately I am not really an X expert.

What bothers me a little bit is that windows are displayed on a screen
which should not even exist. (besides the problem reported above that
the windows are not even drawn on the intended screen).

Thanks
Luke




[-- Attachment #2: XWin.0.log --]
[-- Type: text/plain, Size: 5626 bytes --]

Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.15.1.0
OS: CYGWIN_NT-6.2-WOW64 thinktank 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:

XWin -screen 0 @1 -multiwindow -nomultimonitors 

ddxProcessArgument - Initializing default screens
winInitializeScreenDefaults - primary monitor w 1920 h 1080
winInitializeScreenDefaults - native DPI x 96 y 96
winInitializeScreens - 1
winInitializeScreen - 0
ddxProcessArgument - screen - Found Valid ``@Monitor'' = 1 arg
_XSERVTransmkdir: Mode of /tmp/.X11-unix should be set to 1777
_XSERVTransmkdir: this may cause subsequent errors
[745929.703] Initializing built-in extension Generic Event Extension
[745929.703] Initializing built-in extension SHAPE
[745929.703] Initializing built-in extension MIT-SHM
[745929.703] Initializing built-in extension XInputExtension
[745929.703] Initializing built-in extension XTEST
[745929.703] Initializing built-in extension BIG-REQUESTS
[745929.703] Initializing built-in extension SYNC
[745929.703] Initializing built-in extension XKEYBOARD
[745929.703] Initializing built-in extension XC-MISC
[745929.703] Initializing built-in extension XINERAMA
[745929.703] Initializing built-in extension XFIXES
[745929.703] Initializing built-in extension XFree86-Bigfont
[745929.703] Initializing built-in extension RENDER
[745929.703] Initializing built-in extension RANDR
[745929.703] Initializing built-in extension COMPOSITE
[745929.703] Initializing built-in extension DAMAGE
[745929.703] Initializing built-in extension MIT-SCREEN-SAVER
[745929.703] Initializing built-in extension DOUBLE-BUFFER
[745929.703] Initializing built-in extension RECORD
[745929.703] Initializing built-in extension DPMS
[745929.703] Initializing built-in extension Present
[745929.703] Initializing built-in extension X-Resource
[745929.703] Initializing built-in extension GLX
[745929.703] (II) xorg.conf is not supported
[745929.703] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information
[745929.703] LoadPreferences: /home/niki/.XWinrc not found
[745929.703] LoadPreferences: Loading /etc/X11/system.XWinrc
[745929.703] LoadPreferences: Done parsing the configuration file...
[745929.718] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL
[745929.718] winDetectSupportedEngines - Returning, supported engines 00000015
[745929.718] winSetEngine - Multi Window or Rootless => ShadowGDI
[745929.718] winScreenInit - Using Windows display depth of 32 bits per pixel
[745929.812] winAllocateFBShadowGDI - Creating DIB with width: 1920 height: 1080 depth: 32
[745929.812] winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff
[745929.812] winInitVisualsShadowGDI - Masks 00ff0000 0000ff00 000000ff BPRGB 8 d 24 bpp 32
[745929.812] winInitMultiWindowWM - Calling pthread_mutex_lock ()
[745929.812] winMultiWindowXMsgProc - Calling pthread_mutex_lock ()
[745929.812] MIT-SHM extension disabled due to lack of kernel support
[745929.812] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel
[745929.828] glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll'
[745929.968] GL_VERSION:     4.0.0 - Build 9.17.10.2875
[745929.968] GL_VENDOR:      Intel
[745929.968] GL_RENDERER:    Intel(R) HD Graphics 4000
[745929.968] (II) AIGLX: enabled GLX_SGI_make_current_read
[745929.968] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[745929.968] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[745929.968] (II) AIGLX: enabled GLX_SGIX_pbuffer
[745929.968] (II) AIGLX: enabled GLX_ARB_multisample and GLX_SGIS_multisample
[745929.968] (II) 66 pixel formats reported by wglGetPixelFormatAttribivARB
[745929.968] (II) AIGLX: Set GLX version to 1.4
[745929.984] (II) 21 fbConfigs
[745929.984] (II) GLX: Initialized Win32 native WGL GL provider for screen 0
[745930.109] winPointerWarpCursor - Discarding first warp: 960 540
[745930.109] (--) 5 mouse buttons found
[745930.109] (--) Setting autorepeat to delay=500, rate=31
[745930.109] (--) Windows keyboard layout: "00000409" (00000409) "US", type 4
[745930.109] (--) Found matching XKB configuration "English (USA)"
[745930.109] (--) Model = "pc105" Layout = "us" Variant = "none" Options = "none"
[745930.109] Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options = "none"
[745930.109] winBlockHandler - pthread_mutex_unlock()
[745930.109] winInitMultiWindowWM - pthread_mutex_lock () returned.
[745930.109] winInitMultiWindowWM - pthread_mutex_unlock () returned.
[745930.109] winInitMultiWindowWM - DISPLAY=:0.0
[745930.109] winMultiWindowXMsgProc - pthread_mutex_lock () returned.
[745930.109] winMultiWindowXMsgProc - pthread_mutex_unlock () returned.
[745930.109] winMultiWindowXMsgProc - DISPLAY=:0.0
[745930.109] winProcEstablishConnection - winInitClipboard returned.
[745930.109] winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display.
[745930.109] winClipboardThreadProc - DISPLAY=:0.0
[745930.109] winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened the display.
[745930.109] winClipboardProc - XOpenDisplay () returned and successfully opened the display.
[745938.484] OS has icon alpha channel support: yes
[745948.156] executing 'xterm', pid 7992
[745948.250] (pid 7992 stderr) Warning: Missing charsets in String to FontSet conversion
[745980.343] executing 'xterm', pid 13548
[745980.453] (pid 13548 stderr) Warning: Missing charsets in String to FontSet conversion

[-- Attachment #3: Type: text/plain, Size: 223 bytes --]

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

Re: XWin ignores all parameters related to multiple monitors

[Jon TURNEY]

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/

Re: XWin ignores all parameters related to multiple monitors

[Lukas Haase]

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/

Re: XWin ignores all parameters related to multiple monitors

[Jon TURNEY]

On 09/05/2014 00:27, Lukas Haase wrote:
> On 2014-05-08 5:15, Jon TURNEY wrote:
>
>> 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 understand that.

I am just looking for some evidence that it isn't a bug in the 
application, i.e. that it works correctly for *anyone* :D

Knowing a window manager which places these windows correctly would also 
give me some source code to look at to work out what I need to change.

>> 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 have just the issue that the exe does not seem to work for me. Is
> there anything special I need to consider?

Sorry, my snapshot building script went wrong and the snapshot was 
broken.  Try this one instead.

ftp://cygwin.com/pub/cygwinx/x86/XWin.20140509-git-c4a16a6606868d3e.exe.bz2

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

Re: XWin ignores all parameters related to multiple monitors

[Lukas Haase]

On 2014-05-09 3:15, Jon TURNEY wrote:
> On 09/05/2014 00:27, Lukas Haase wrote:
>> On 2014-05-08 5:15, Jon TURNEY wrote:
>>
>>> 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 understand that.
> 
> I am just looking for some evidence that it isn't a bug in the
> application, i.e. that it works correctly for *anyone* :D
> 
> Knowing a window manager which places these windows correctly would also
> give me some source code to look at to work out what I need to change.

Hmm, what I just did is that I started a VNC session and used VNC.
Everything seems to work as expected, new windows are /not/ placed at (0,0).

Window manager is Gnome.

However, as mentioned, this is clearly not a local multi-monitor X
session :(

>>> 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 have just the issue that the exe does not seem to work for me. Is
>> there anything special I need to consider?
> 
> Sorry, my snapshot building script went wrong and the snapshot was
> broken.  Try this one instead.
> 
> ftp://cygwin.com/pub/cygwinx/x86/XWin.20140509-git-c4a16a6606868d3e.exe.bz2

Can't believe it, great! Works exactly as it should (just with the
standard configuration, "X :0 -multiwindow")!!

Now I just hope that this 'patch' somehow finds its way into the trunk ;-)


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/

Re: XWin ignores all parameters related to multiple monitors

[Jon TURNEY]

On 09/05/2014 21:25, Lukas Haase wrote:
> On 2014-05-09 3:15, Jon TURNEY wrote:
>> On 09/05/2014 00:27, Lukas Haase wrote:
>>> On 2014-05-08 5:15, Jon TURNEY wrote:
>>>> 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 have just the issue that the exe does not seem to work for me. Is
>>> there anything special I need to consider?
>>
>> Sorry, my snapshot building script went wrong and the snapshot was
>> broken.  Try this one instead.
>>
>> ftp://cygwin.com/pub/cygwinx/x86/XWin.20140509-git-c4a16a6606868d3e.exe.bz2
>
> Can't believe it, great! Works exactly as it should (just with the
> standard configuration, "X :0 -multiwindow")!!
>
> Now I just hope that this 'patch' somehow finds its way into the trunk ;-)

This fix is included is 1.15.1-3.

On reflection, I think a better approach would be to look at 
_NET_WM_WINDOW_TYPE and if it's _NET_WM_TYPE_NORMAL or absent, ignore 
PPosition and place the window as we like, but that is not quite as 
straightforward to implement.

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