* Cygwin/X with Win10 display scaling corrupting font display of typed characters @ 2022-01-17 18:29 Ken Whitesell 2022-01-19 0:02 ` Cygwin/X with Win10 display scaling corrupting font display of typed characters - Issue identified Ken Whitesell 0 siblings, 1 reply; 10+ messages in thread From: Ken Whitesell @ 2022-01-17 18:29 UTC (permalink / raw) To: cygwin Problem: When moving an XTerm window from the primary display to the second monitor, characters typed into that window are "clipped" at the top. Only about the bottom 75% is drawn. No lower-case letters taller than the "half-height" letters render properly. (Letters such as "a", "c", "m", "n", etc are all rendered correctly. All capital letters and tall lower-case letters (e.g. "b" and "d") have the top quarter clipped off. Additionally the XTerm window shows thin black bars on the right side of the window and along the bottom of the window. The bash prompt and most all characters displayed as the result of the output of a command all display correctly - this is *primarily* affecting characters being typed, and before the "enter" key is pressed. (There is one special case regarding displayed characters. If a program is creating a full screen of output, such as "man", the top line of the screen is clipped.) If the window is in the primary display when the characters are typed, and then the window is moved to the second monitor, the previously-typed characters remain correctly formed, and only new characters typed while the window is in the second monitor are clipped. Environment: The primary display is the laptop's built-in display (1920x1080, 17"). The second monitor is a 27" also at 1920x1080. Operating system is Windows 10, with all current patches and updates. (Ver reports Microsoft Windows [Version 10.0.19044.1466]). XWin server is being started with this command line: E:\cygwin64\bin\run.exe --quote /usr/bin/bash.exe -l -c "cd; exec /usr/bin/startxwin -- -listen tcp" Additional info: This appears to be related to using the display "Scaling" option, where the laptop's display is set at 125% and the external monitor's display is set at 100%. If I set both displays the same - either both at 100% _or_ both at 125%, the problem does not appear. If I change the scaling from 125% to 100% on the laptop's display, the problem appears until I restart Cygwin/X. Restarting Cygwin/X shows it displaying properly, until I change the scaling again. Note: XTerm is _not_ the only program that exhibits this behavior. This is consistent among all applications tried, including geany, hexedit, mate-terminal, and lxterminal. (The visual behavior is slightly different for "full screen" application such as geany and hexedit, but it's still apparent that some clipping is occurring with characters being typed.) Other version information: Cygwin setup version 2.915, packages showing as up-to-date include xterm 370-1, xinit 1.4.1-1, xorg-server 21.1.3-1, xorg-x11-fonts-* 7.5-4. (Unsure what other information may be useful.) I've tried searching the message archives, going back through 2018 and have not seen anything that appears relevant. Other searches haven't proved useful, other than indicating that I should try applications other than XTerm. I have tried various settings in different locations, including specifying "-resize=none" and/or -screen options for both monitors. No changes have been made to system.XWinrc. /etc/X11/xinit/startxwinrc has the following lines added before the line "exec /usr/bin/xwin-xdg-menu" line at the bottom of the file: /bin/xterm -fa 'DejaVu Sans Mono' -fs 12 -geometry 100x33 & /bin/xterm -fa 'DejaVu Sans Mono' -fs 12 -geometry 100x33 & /bin/xterm -fa 'DejaVu Sans Mono' -fs 12 -geometry 100x33 & /bin/xterm -fa 'DejaVu Sans Mono' -fs 12 -geometry 100x33 & There is no .startxwinrc file in $HOME. I will gladly provide any additional information that may help. Is there a known solution for this? (Or is it known that there is no solution?) Any guidance, pointers, suggestions of avenues for further research, or other information, will all be greatly appreciated. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cygwin/X with Win10 display scaling corrupting font display of typed characters - Issue identified 2022-01-17 18:29 Cygwin/X with Win10 display scaling corrupting font display of typed characters Ken Whitesell @ 2022-01-19 0:02 ` Ken Whitesell 2022-01-19 19:28 ` Jon Turney 0 siblings, 1 reply; 10+ messages in thread From: Ken Whitesell @ 2022-01-19 0:02 UTC (permalink / raw) To: cygwin On 1/17/2022 1:29 PM, Ken Whitesell wrote: > Problem: When moving an XTerm window from the primary display to the > second monitor, characters typed into that window are "clipped" at the > top. Only about the bottom 75% is drawn. No lower-case letters taller > than the "half-height" letters render properly. (Letters such as "a", > "c", "m", "n", etc are all rendered correctly. All capital letters and > tall lower-case letters (e.g. "b" and "d") have the top quarter > clipped off. Additionally the XTerm window shows thin black bars on > the right side of the window and along the bottom of the window. > > The bash prompt and most all characters displayed as the result of the > output of a command all display correctly - this is *primarily* > affecting characters being typed, and before the "enter" key is > pressed. (There is one special case regarding displayed characters. If > a program is creating a full screen of output, such as "man", the top > line of the screen is clipped.) > > If the window is in the primary display when the characters are typed, > and then the window is moved to the second monitor, the > previously-typed characters remain correctly formed, and only new > characters typed while the window is in the second monitor are clipped. > > Environment: The primary display is the laptop's built-in display > (1920x1080, 17"). The second monitor is a 27" also at 1920x1080. > Operating system is Windows 10, with all current patches and updates. > (Ver reports Microsoft Windows [Version 10.0.19044.1466]). XWin server > is being started with this command line: > > E:\cygwin64\bin\run.exe --quote /usr/bin/bash.exe -l -c "cd; exec > /usr/bin/startxwin -- -listen tcp" > > Additional info: This appears to be related to using the display > "Scaling" option, where the laptop's display is set at 125% and the > external monitor's display is set at 100%. If I set both displays the > same - either both at 100% _or_ both at 125%, the problem does not > appear. > > If I change the scaling from 125% to 100% on the laptop's display, the > problem appears until I restart Cygwin/X. Restarting Cygwin/X shows it > displaying properly, until I change the scaling again. > > Note: XTerm is _not_ the only program that exhibits this behavior. > This is consistent among all applications tried, including geany, > hexedit, mate-terminal, and lxterminal. (The visual behavior is > slightly different for "full screen" application such as geany and > hexedit, but it's still apparent that some clipping is occurring with > characters being typed.) > > Other version information: Cygwin setup version 2.915, packages > showing as up-to-date include xterm 370-1, xinit 1.4.1-1, xorg-server > 21.1.3-1, xorg-x11-fonts-* 7.5-4. (Unsure what other information may > be useful.) > > I've tried searching the message archives, going back through 2018 and > have not seen anything that appears relevant. Other searches haven't > proved useful, other than indicating that I should try applications > other than XTerm. > > I have tried various settings in different locations, including > specifying "-resize=none" and/or -screen options for both monitors. > > No changes have been made to system.XWinrc. > > /etc/X11/xinit/startxwinrc has the following lines added before the > line "exec /usr/bin/xwin-xdg-menu" line at the bottom of the file: > > /bin/xterm -fa 'DejaVu Sans Mono' -fs 12 -geometry 100x33 & > /bin/xterm -fa 'DejaVu Sans Mono' -fs 12 -geometry 100x33 & > /bin/xterm -fa 'DejaVu Sans Mono' -fs 12 -geometry 100x33 & > /bin/xterm -fa 'DejaVu Sans Mono' -fs 12 -geometry 100x33 & > > There is no .startxwinrc file in $HOME. > > I will gladly provide any additional information that may help. > > Is there a known solution for this? (Or is it known that there is no > solution?) > > Any guidance, pointers, suggestions of avenues for further research, > or other information, will all be greatly appreciated. > After more research and experimentation, it appears to be related to one of xorg-server, xorg-server-common, or xorg-server-xorg. Installing the older version 1.20.12-1 of these packages allows the windows to be moved between monitors without any issues. Upgrading to the current version 21.1.3-1 creates the problems. I'm able to replicate this behavior on two different laptops with two different external monitors. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cygwin/X with Win10 display scaling corrupting font display of typed characters - Issue identified 2022-01-19 0:02 ` Cygwin/X with Win10 display scaling corrupting font display of typed characters - Issue identified Ken Whitesell @ 2022-01-19 19:28 ` Jon Turney 2022-01-20 1:01 ` Ken Whitesell 0 siblings, 1 reply; 10+ messages in thread From: Jon Turney @ 2022-01-19 19:28 UTC (permalink / raw) To: Ken Whitesell, The Cygwin Mailing List On 19/01/2022 00:02, Ken Whitesell wrote: > On 1/17/2022 1:29 PM, Ken Whitesell wrote: >> >> Is there a known solution for this? (Or is it known that there is no >> solution?) Thanks for reporting this. >> Any guidance, pointers, suggestions of avenues for further research, >> or other information, will all be greatly appreciated. >> > After more research and experimentation, it appears to be related to one > of xorg-server, xorg-server-common, or xorg-server-xorg. > > Installing the older version 1.20.12-1 of these packages allows the > windows to be moved between monitors without any issues. Upgrading to > the current version 21.1.3-1 creates the problems. I'm able to replicate > this behavior on two different laptops with two different external > monitors. It seems likely that this is an unintended effect of changes in xorg-server 21.1.0-1, trying to fix problems in this area (See [1]) You might find that starting the server and specifying a fixed dpi value with the '-dpi' option might workaround this. [1] https://cygwin.com/pipermail/cygwin-announce/2021-November/010286.html > If I change the scaling from 125% to 100% on the laptop's display, > the problem appears until I restart Cygwin/X. Restarting Cygwin/X > shows it displaying properly, until I change the scaling again. I could only reproduce this problem with mis-rendering when changing the scaling on the secondary monitor. (This is presumably somehow related to the fact that we now keep that window at the same pixel dimensions, rather than allowing Windows to scale it). ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cygwin/X with Win10 display scaling corrupting font display of typed characters - Issue identified 2022-01-19 19:28 ` Jon Turney @ 2022-01-20 1:01 ` Ken Whitesell 2022-01-21 18:26 ` Cygwin/X with Win[10]-^ display scaling corrupting font display of typed characters - Issue [identified]-???? L A Walsh 2022-01-24 15:02 ` Cygwin/X with Win10 display scaling corrupting font display of typed characters - Issue identified Jon Turney 0 siblings, 2 replies; 10+ messages in thread From: Ken Whitesell @ 2022-01-20 1:01 UTC (permalink / raw) To: The Cygwin Mailing List On 1/19/2022 2:28 PM, Jon Turney wrote: > On 19/01/2022 00:02, Ken Whitesell wrote: >> On 1/17/2022 1:29 PM, Ken Whitesell wrote: >>> >>> Is there a known solution for this? (Or is it known that there is no >>> solution?) > > Thanks for reporting this. > >>> Any guidance, pointers, suggestions of avenues for further research, >>> or other information, will all be greatly appreciated. >>> >> After more research and experimentation, it appears to be related to >> one of xorg-server, xorg-server-common, or xorg-server-xorg. >> >> Installing the older version 1.20.12-1 of these packages allows the >> windows to be moved between monitors without any issues. Upgrading to >> the current version 21.1.3-1 creates the problems. I'm able to >> replicate this behavior on two different laptops with two different >> external monitors. > > It seems likely that this is an unintended effect of changes in > xorg-server 21.1.0-1, trying to fix problems in this area (See [1]) Thanks for the references. I've read all the messages in the thread - I was particularly intrigued by this comment: wrt the font scaling issue, looking at the source, it seems that we don't re-consider the display dpi after a WM_DISPLAYCHANGE message, but keep on using the value determined at startup. This is probably a bug. I'm curious enough to want to take a look at the code, but I've got no belief that I'm going to be able to find an answer. (I'm *not* a C++ programmer. I can read it and write a little of it, but that's about it.) I was going to start by comparing the last known-working version to the first known-non-working version, but given that it's a major release change, that's not likely going to be a useful approach. (I'm way out of my league here. It's probably going to take me a long time just to get to the point where I can even begin to explore this.) > > You might find that starting the server and specifying a fixed dpi > value with the '-dpi' option might workaround this. > > [1] > https://cygwin.com/pipermail/cygwin-announce/2021-November/010286.html > I tried three different DPI settings, each one confirmed by verifying the setting as reported in the XWin.0.log file. Example: [252575.109] winUpdateDpi - Using fixed 96 DPI No setting prevented the issue from appearing. >> If I change the scaling from 125% to 100% on the laptop's display, >> the problem appears until I restart Cygwin/X. Restarting Cygwin/X >> shows it displaying properly, until I change the scaling again. > > I could only reproduce this problem with mis-rendering when changing > the scaling on the secondary monitor. Wow, I did a really poor job of writing that. I'm sorry. For clarity, just in case you were unable to interpret what I meant by what I wrote - At start: Laptop scaling set at 125%, second monitor at 100%. Mis-rendering occurs at start, on the second monitor only. If I change the scaling on the laptop, while the current instance of XWin is running - the same mis-rendering now occurs on the laptop. Interestingly enough, if I change the laptop from 125% to 100%, the tops are clipped as previously reported. But if I change the scaling from 125% to 150%, then the bottoms are clipped. (It kinda makes sense from what you've written.) If I then stop and restart XWin after having reset the scaling such that both monitors have the same setting, then the problem doesn't appear. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cygwin/X with Win[10]-^ display scaling corrupting font display of typed characters - Issue [identified]-???? 2022-01-20 1:01 ` Ken Whitesell @ 2022-01-21 18:26 ` L A Walsh 2022-01-23 20:25 ` Cygwin/X display scaling corrupting font display of typed characters; L A Walsh 2022-01-24 15:02 ` Cygwin/X with Win10 display scaling corrupting font display of typed characters - Issue identified Jon Turney 1 sibling, 1 reply; 10+ messages in thread From: L A Walsh @ 2022-01-21 18:26 UTC (permalink / raw) To: Ken Whitesell; +Cc: The Cygwin Mailing List [-- Attachment #1: Type: text/plain, Size: 2512 bytes --] On 2022/01/19 17:01, Ken Whitesell wrote: > On 1/19/2022 2:28 PM, Jon Turney wrote: > >> On 19/01/2022 00:02, Ken Whitesell wrote: >> >>> On 1/17/2022 1:29 PM, Ken Whitesell wrote: >>> >>> After more research and experimentation, it appears to be related to >>> one of xorg-server, xorg-server-common, or xorg-server-xorg. >>> >>> Installing the older version 1.20.12-1 of these packages allows the >>> windows to be moved between monitors without any issues. Upgrading to >>> the current version 21.1.3-1 creates the problems. I'm able to >>> replicate this behavior on two different laptops with two different >>> external monitors. >>> It seems likely that this is an unintended effect of changes in >> xorg-server 21.1.0-1, trying to fix problems in this area (See [1]) ---- I am seeing this issue or one very much like it on Win7x64 But I have 1.20.12-1 of xorg-server + xorg-server{,-common,-debuginfo}, but I do not have xorg-server-xorg installed *at all*. Mine has nothing to do with moving windows between monitors. I'm seeing truncated windows on my main monitor (2560x1440). My 2nd monitor is 1920x1080. ---- On boot, I start the Xserver by calling ~/bin/Xserver.sh I use a modified Xserver.sh script that was no longer being called due to a "Xserver.sh.lnk" being in ~/bin that pointed to the system script in /bin. Ooops. Upon fixing that problem, the problem of X-apps no longer updating correctly disappeared. My script has a few diffs and is missing the xauth stuff.. It's about 6 years old, and hasn't been cleaned up for public consumption, but it works. Point being, that for me, the problem seems to have been worked around in the startup script. Caveat -- my X-apps don't update in my 2nd window, so there's still some lemon in my setup, but I haven't taken the time to figure it out as my 2nd Screen is on the wall and used for video -- it's too far away for me to read text on it, so I haven't bothered to chase down the lack of updates (I can drag a window over to the 2nd screen and that displays fine, but Xupdates don't. Getting it to work properly might be a problem since the DPI on the 2nd monitor is different than on the 1st one. I hear Win10 has allowances for different DPI screens. Thw two Xwin.logs are from the cygwin startup script (.orig) and my startup script. The cygwin script seems end up sizing my 2560x1440 screen down to 1920x1080, which corresponds to the dead area in updating X-apps I was seeing. update [-- Attachment #2: XWin.0.log --] [-- Type: text/plain, Size: 4617 bytes --] Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.20.12.0 OS: CYGWIN_NT-6.1-7601 ATHENAE 3.2.0-340.x86_64 2021-03-29 08:42 UTC x86_64 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64) Package: version 1.20.12-1 built 2021-07-11 XWin was started with the following command line: /usr/bin/XWin -dpi 120 -listen tcp -nopn +iglx -wgl -compositealpha -compositewm -lesspointer -clipboard -ac -unixkill -nowinkill -multiwindow -wm -ardelay 150 -arinterval 30 +bs -nomultimonitors -hostintitle -noreset -logverbose 2 -fp /usr/share/fonts/TTF,/usr/share/fonts/Type1,/usr/share/fonts/misc,/usr/share/fonts/100dpi,built-ins,/windows/fonts ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 2560 h 1440 winInitializeScreenDefaults - native DPI x 120 y 120 [438305.291] (II) xorg.conf is not supported [438305.291] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [438305.291] (++) FontPath set to "/usr/share/fonts/TTF,/usr/share/fonts/Type1,/usr/share/fonts/misc,/usr/share/fonts/100dpi,built-ins,/windows/fonts" [438305.291] LoadPreferences: Loading /Users/law.Bliss/.XWinrc [438305.291] LoadPreferences: Done parsing the configuration file... [438305.291] winDetectSupportedEngines - RemoteSession: no [438305.369] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL [438305.385] winDetectSupportedEngines - Returning, supported engines 00000005 [438305.385] winSetEngine - Multi Window or Rootless => ShadowGDI [438305.385] winScreenInit - Using Windows display depth of 32 bits per pixel [438306.883] winAllocateFBShadowGDI - Creating DIB with width: 2560 height: 1440 depth: 32 [438306.883] winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff [438306.883] winInitVisualsShadowGDI - Masks 00ff0000 0000ff00 000000ff BPRGB 8 d 24 bpp 32 [438306.898] glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll' [438307.163] (II) AIGLX: Testing pixelFormatIndex 5 [438307.273] GL_VERSION: 4.6.0 NVIDIA 441.41 [438307.273] GL_VENDOR: NVIDIA Corporation [438307.273] GL_RENDERER: GeForce RTX 2080 Ti/PCIe/SSE2 [438307.273] (II) GLX: enabled GLX_SGI_make_current_read [438307.273] (II) GLX: enabled GLX_SGI_swap_control [438307.273] (II) GLX: enabled GLX_MESA_swap_control [438307.273] (II) GLX: enabled GLX_SGIX_pbuffer [438307.273] (II) GLX: enabled GLX_ARB_multisample [438307.273] (II) GLX: enabled GLX_SGIS_multisample [438307.273] (II) GLX: enabled GLX_ARB_fbconfig_float [438307.273] (II) GLX: enabled GLX_EXT_fbconfig_packed_float [438307.273] (II) GLX: enabled GLX_ARB_create_context [438307.273] (II) GLX: enabled GLX_ARB_create_context_profile [438307.273] (II) GLX: enabled GLX_ARB_create_context_robustness [438307.273] (II) GLX: enabled GLX_EXT_create_context_es2_profile [438307.273] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer [438307.273] (II) 670 pixel formats reported by wglGetPixelFormatAttribivARB [438307.288] (II) 634 fbConfigs [438307.288] (II) ignored pixel formats: 0 not OpenGL, 0 unknown pixel type, 36 unaccelerated [438307.288] (II) GLX: Initialized Win32 native WGL GL provider for screen 0 [438307.631] winPointerWarpCursor - Discarding first warp: 1280 720 [438307.631] (--) 5 mouse buttons found [438307.631] (--) Setting autorepeat to delay=500, rate=31 [438307.631] (--) Windows keyboard layout: "00000409" (00000409) "US", type 4 [438307.631] (--) Found matching XKB configuration "English (USA)" [438307.631] (--) Model = "pc105" Layout = "us" Variant = "none" Options = "none" [438307.631] Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options = "none" [438307.631] [438307.631] winMultiWindowXMsgProc - DISPLAY=:0.0 winInitMultiWindowWM - DISPLAY=:0.0 [438307.631] [438307.631] winProcEstablishConnection - winInitClipboard returned. winClipboardThreadProc - DISPLAY=:0.0 [438307.631] winMultiWindowXMsgProc - xcb_connect() returned and successfully opened the display. [438307.631] Using Composite redirection [438307.631] winInitMultiWindowWM - xcb_connect () returned and successfully opened the display. [438307.647] winClipboardProc - xcb_connect () returned and successfully opened the display. [438386.428] IsOverrideRedirect: Failed to get window attributes [438399.953] OS has icon alpha channel support: yes [438476.534] IsOverrideRedirect: Failed to get window attributes [524157.743] winWindowProc - WM_DISPLAYCHANGE - new width: 2560 new height: 1440 new bpp: 32 [524157.743] winWindowProc - RemoteSession: no [524157.743] winAllocateFBShadowGDI - Creating DIB with width: 1920 height: 1080 depth: 32 [-- Attachment #3: XWin.0.log.orig --] [-- Type: text/plain, Size: 4889 bytes --] Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.20.12.0 OS: CYGWIN_NT-6.1-7601 ATHENAE 3.2.0-340.x86_64 2021-03-29 08:42 UTC x86_64 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64) Package: version 1.20.12-1 built 2021-07-11 XWin was started with the following command line: /usr/bin/XWin -dpi 120 -listen tcp -nopn +iglx -wgl -compositealpha -compositewm -lesspointer -clipboard -ac -unixkill -nowinkill -multiwindow -wm -ardelay 150 -arinterval 30 +bs -nomultimonitors -hostintitle -noreset -logverbose 2 -fp /usr/share/fonts/TTF,/usr/share/fonts/Type1,/usr/share/fonts/misc,/usr/share/fonts/100dpi,built-ins,/windows/fonts ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 2560 h 1440 winInitializeScreenDefaults - native DPI x 120 y 120 [438305.291] (II) xorg.conf is not supported [438305.291] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [438305.291] (++) FontPath set to "/usr/share/fonts/TTF,/usr/share/fonts/Type1,/usr/share/fonts/misc,/usr/share/fonts/100dpi,built-ins,/windows/fonts" [438305.291] LoadPreferences: Loading /Users/law.Bliss/.XWinrc [438305.291] LoadPreferences: Done parsing the configuration file... [438305.291] winDetectSupportedEngines - RemoteSession: no [438305.369] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL [438305.385] winDetectSupportedEngines - Returning, supported engines 00000005 [438305.385] winSetEngine - Multi Window or Rootless => ShadowGDI [438305.385] winScreenInit - Using Windows display depth of 32 bits per pixel [438306.883] winAllocateFBShadowGDI - Creating DIB with width: 2560 height: 1440 depth: 32 [438306.883] winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff [438306.883] winInitVisualsShadowGDI - Masks 00ff0000 0000ff00 000000ff BPRGB 8 d 24 bpp 32 [438306.898] glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll' [438307.163] (II) AIGLX: Testing pixelFormatIndex 5 [438307.273] GL_VERSION: 4.6.0 NVIDIA 441.41 [438307.273] GL_VENDOR: NVIDIA Corporation [438307.273] GL_RENDERER: GeForce RTX 2080 Ti/PCIe/SSE2 [438307.273] (II) GLX: enabled GLX_SGI_make_current_read [438307.273] (II) GLX: enabled GLX_SGI_swap_control [438307.273] (II) GLX: enabled GLX_MESA_swap_control [438307.273] (II) GLX: enabled GLX_SGIX_pbuffer [438307.273] (II) GLX: enabled GLX_ARB_multisample [438307.273] (II) GLX: enabled GLX_SGIS_multisample [438307.273] (II) GLX: enabled GLX_ARB_fbconfig_float [438307.273] (II) GLX: enabled GLX_EXT_fbconfig_packed_float [438307.273] (II) GLX: enabled GLX_ARB_create_context [438307.273] (II) GLX: enabled GLX_ARB_create_context_profile [438307.273] (II) GLX: enabled GLX_ARB_create_context_robustness [438307.273] (II) GLX: enabled GLX_EXT_create_context_es2_profile [438307.273] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer [438307.273] (II) 670 pixel formats reported by wglGetPixelFormatAttribivARB [438307.288] (II) 634 fbConfigs [438307.288] (II) ignored pixel formats: 0 not OpenGL, 0 unknown pixel type, 36 unaccelerated [438307.288] (II) GLX: Initialized Win32 native WGL GL provider for screen 0 [438307.631] winPointerWarpCursor - Discarding first warp: 1280 720 [438307.631] (--) 5 mouse buttons found [438307.631] (--) Setting autorepeat to delay=500, rate=31 [438307.631] (--) Windows keyboard layout: "00000409" (00000409) "US", type 4 [438307.631] (--) Found matching XKB configuration "English (USA)" [438307.631] (--) Model = "pc105" Layout = "us" Variant = "none" Options = "none" [438307.631] Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options = "none" [438307.631] [438307.631] winMultiWindowXMsgProc - DISPLAY=:0.0 winInitMultiWindowWM - DISPLAY=:0.0 [438307.631] [438307.631] winProcEstablishConnection - winInitClipboard returned. winClipboardThreadProc - DISPLAY=:0.0 [438307.631] winMultiWindowXMsgProc - xcb_connect() returned and successfully opened the display. [438307.631] Using Composite redirection [438307.631] winInitMultiWindowWM - xcb_connect () returned and successfully opened the display. [438307.647] winClipboardProc - xcb_connect () returned and successfully opened the display. [438386.428] IsOverrideRedirect: Failed to get window attributes [438399.953] OS has icon alpha channel support: yes [438476.534] IsOverrideRedirect: Failed to get window attributes [524157.743] winWindowProc - WM_DISPLAYCHANGE - new width: 2560 new height: 1440 new bpp: 32 [524157.743] winWindowProc - RemoteSession: no [524157.743] winAllocateFBShadowGDI - Creating DIB with width: 1920 height: 1080 depth: 32 [733855.831] winDeinitMultiWindowWM - Noting shutdown in progress [733855.831] winMultiWindowWMProc - Fatal error 1 on xcb connection [733856.018] winDeinitMultiWindowWM - Noting shutdown in progress [733856.018] (II) Server terminated successfully (0). Closing log file. [-- Attachment #4: startxwin.sh --] [-- Type: application/x-sh, Size: 3632 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cygwin/X display scaling corrupting font display of typed characters; 2022-01-21 18:26 ` Cygwin/X with Win[10]-^ display scaling corrupting font display of typed characters - Issue [identified]-???? L A Walsh @ 2022-01-23 20:25 ` L A Walsh 0 siblings, 0 replies; 10+ messages in thread From: L A Walsh @ 2022-01-23 20:25 UTC (permalink / raw) To: Ken Whitesell; +Cc: The Cygwin Mailing List On 2022/01/21 10:26, L A Walsh wrote: ... To summarize, I am not sure that the original issue has anything to do with 2nd monitor, nor any changes in the Xorg-sources. In _my_ case it was a matter of how the Xserver was started, and what dpi settings it was started with. If server was started with incorrect dpi settings, it would cause problems with some Xclients having mangled or trunated characters at the bottom of their windows. For me, it was a matter of ensuring that my modified startX script was called instead of the stock script, as my modified script checks the windows DPI setting on startup. That said -- on Win10 it could be further complicated by having multiple monitors with different dpi settings. I seem to remember win10 having some provision for attaching a different DPI value to different monitors. That's likely to create a problem in 'X', since AFAIK, X hasn't been enhanced to allow different DPI values on different "screens". ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cygwin/X with Win10 display scaling corrupting font display of typed characters - Issue identified 2022-01-20 1:01 ` Ken Whitesell 2022-01-21 18:26 ` Cygwin/X with Win[10]-^ display scaling corrupting font display of typed characters - Issue [identified]-???? L A Walsh @ 2022-01-24 15:02 ` Jon Turney 2022-01-27 3:12 ` Cygwin/X with Win10 display scaling corrupting font display of typed characters - Issue identified - "Solution" found Ken Whitesell 1 sibling, 1 reply; 10+ messages in thread From: Jon Turney @ 2022-01-24 15:02 UTC (permalink / raw) To: Ken Whitesell, The Cygwin Mailing List On 20/01/2022 01:01, Ken Whitesell wrote: > On 1/19/2022 2:28 PM, Jon Turney wrote: >> On 19/01/2022 00:02, Ken Whitesell wrote: >>> On 1/17/2022 1:29 PM, Ken Whitesell wrote: >>>> >>>> Is there a known solution for this? (Or is it known that there is no >>>> solution?) >> >> Thanks for reporting this. >> >>>> Any guidance, pointers, suggestions of avenues for further research, >>>> or other information, will all be greatly appreciated. >>>> >>> After more research and experimentation, it appears to be related to >>> one of xorg-server, xorg-server-common, or xorg-server-xorg. >>> >>> Installing the older version 1.20.12-1 of these packages allows the >>> windows to be moved between monitors without any issues. Upgrading to >>> the current version 21.1.3-1 creates the problems. I'm able to >>> replicate this behavior on two different laptops with two different >>> external monitors. >> >> It seems likely that this is an unintended effect of changes in >> xorg-server 21.1.0-1, trying to fix problems in this area (See [1]) > > Thanks for the references. I've read all the messages in the thread - I > was particularly intrigued by this comment: > > wrt the font scaling issue, looking at the source, it seems that we > don't re-consider the display dpi after a WM_DISPLAYCHANGE message, but > keep on using the value determined at startup. This is probably a bug. > > I'm curious enough to want to take a look at the code, but I've got no > belief that I'm going to be able to find an answer. (I'm *not* a C++ > programmer. I can read it and write a little of it, but that's about > it.) I was going to start by comparing the last known-working version to > the first known-non-working version, but given that it's a major release > change, that's not likely going to be a useful approach. (I'm way out of > my league here. It's probably going to take me a long time just to get > to the point where I can even begin to explore this.) The relevant change, which tries to fix the issue identified in that comment, and probably introduces this issue is: https://gitlab.freedesktop.org/jturney/xserver/-/commit/b19b6266d33f2b911dc1826ad5c03da135a39957 [...] >>> If I change the scaling from 125% to 100% on the laptop's display, >>> the problem appears until I restart Cygwin/X. Restarting Cygwin/X >>> shows it displaying properly, until I change the scaling again. >> >> I could only reproduce this problem with mis-rendering when changing >> the scaling on the secondary monitor. > > Wow, I did a really poor job of writing that. I'm sorry. > > For clarity, just in case you were unable to interpret what I meant by > what I wrote - > > At start: Laptop scaling set at 125%, second monitor at 100%. > > Mis-rendering occurs at start, on the second monitor only. > > If I change the scaling on the laptop, while the current instance of > XWin is running - the same mis-rendering now occurs on the laptop. > > Interestingly enough, if I change the laptop from 125% to 100%, the tops > are clipped as previously reported. But if I change the scaling from > 125% to 150%, then the bottoms are clipped. (It kinda makes sense from > what you've written.) > > If I then stop and restart XWin after having reset the scaling such that > both monitors have the same setting, then the problem doesn't appear. Thanks for the clarification. The laptop display is the primary monitor in all cases, correct? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cygwin/X with Win10 display scaling corrupting font display of typed characters - Issue identified - "Solution" found 2022-01-24 15:02 ` Cygwin/X with Win10 display scaling corrupting font display of typed characters - Issue identified Jon Turney @ 2022-01-27 3:12 ` Ken Whitesell 2022-02-05 14:25 ` Jon Turney 0 siblings, 1 reply; 10+ messages in thread From: Ken Whitesell @ 2022-01-27 3:12 UTC (permalink / raw) To: The Cygwin Mailing List Thank You!!! On 1/24/2022 10:02 AM, Jon Turney wrote: > On 20/01/2022 01:01, Ken Whitesell wrote: >> On 1/19/2022 2:28 PM, Jon Turney wrote: >>> On 19/01/2022 00:02, Ken Whitesell wrote: >>>> On 1/17/2022 1:29 PM, Ken Whitesell wrote: >>>>> >>>>> Is there a known solution for this? (Or is it known that there is >>>>> no solution?) >>> >>> Thanks for reporting this. >>> >>>>> Any guidance, pointers, suggestions of avenues for further >>>>> research, or other information, will all be greatly appreciated. >>>>> >>>> After more research and experimentation, it appears to be related >>>> to one of xorg-server, xorg-server-common, or xorg-server-xorg. >>>> >>>> Installing the older version 1.20.12-1 of these packages allows the >>>> windows to be moved between monitors without any issues. Upgrading >>>> to the current version 21.1.3-1 creates the problems. I'm able to >>>> replicate this behavior on two different laptops with two different >>>> external monitors. >>> >>> It seems likely that this is an unintended effect of changes in >>> xorg-server 21.1.0-1, trying to fix problems in this area (See [1]) >> >> Thanks for the references. I've read all the messages in the thread - >> I was particularly intrigued by this comment: >> >> wrt the font scaling issue, looking at the source, it seems that we >> don't re-consider the display dpi after a WM_DISPLAYCHANGE message, but >> keep on using the value determined at startup. This is probably a bug. >> >> I'm curious enough to want to take a look at the code, but I've got >> no belief that I'm going to be able to find an answer. (I'm *not* a >> C++ programmer. I can read it and write a little of it, but that's >> about it.) I was going to start by comparing the last known-working >> version to the first known-non-working version, but given that it's a >> major release change, that's not likely going to be a useful >> approach. (I'm way out of my league here. It's probably going to take >> me a long time just to get to the point where I can even begin to >> explore this.) > > The relevant change, which tries to fix the issue identified in that > comment, and probably introduces this issue is: > > https://gitlab.freedesktop.org/jturney/xserver/-/commit/b19b6266d33f2b911dc1826ad5c03da135a39957 > > > [...] >>>> If I change the scaling from 125% to 100% on the laptop's display, >>>> the problem appears until I restart Cygwin/X. Restarting Cygwin/X >>>> shows it displaying properly, until I change the scaling again. >>> >>> I could only reproduce this problem with mis-rendering when changing >>> the scaling on the secondary monitor. >> >> Wow, I did a really poor job of writing that. I'm sorry. >> >> For clarity, just in case you were unable to interpret what I meant >> by what I wrote - >> >> At start: Laptop scaling set at 125%, second monitor at 100%. >> >> Mis-rendering occurs at start, on the second monitor only. >> >> If I change the scaling on the laptop, while the current instance of >> XWin is running - the same mis-rendering now occurs on the laptop. >> >> Interestingly enough, if I change the laptop from 125% to 100%, the >> tops are clipped as previously reported. But if I change the scaling >> from 125% to 150%, then the bottoms are clipped. (It kinda makes >> sense from what you've written.) >> >> If I then stop and restart XWin after having reset the scaling such >> that both monitors have the same setting, then the problem doesn't >> appear. > > Thanks for the clarification. > > The laptop display is the primary monitor in all cases, correct? Yes, the laptop display is the primary monitor in all cases. But, the real reason for my reply at this point is to report that I have found a solution for _my_ issue. I make no guarantees about any problems anyone else may be facing, nor can I make any statement about whether or not this causes other problems. Obligatory disclaimer: I don't really know what I'm doing here. I'm not a Windows developer, and I know just enough about cygwin to muddle my way through doing what I want to do with the help of the mailing lists and other resources. I'm not in a position to _explain_ anything. This works for me, but that's as far as I can go. First, the bottom line: XWin.exe.manifest, line 21 change: <dpiAwareness>PerMonitorV2,PerMonitor</dpiAwareness> to <dpiAwareness>PerMonitor</dpiAwareness> Some details: I managed to get to a point where I could build the packages from source and install them. I looked at the commit you referred me to, and started reverting changes, one-by-one - at least in so far as the change appeared to make sense to me. Anyway, I got to this change, and sure enough, it worked. Removing the "PerMonitorV2" solved the issue. Also, I confirmed that it's the "PerMonitorV2" that is causing the issue and not having both of them by running another test with just the "PerMonitorV2" - and that still shows the problem. References with further information if it's going to be helpful to anyone: https://docs.microsoft.com/en-us/windows/win32/hidpi/setting-the-default-dpi-awareness-for-a-process and https://docs.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cygwin/X with Win10 display scaling corrupting font display of typed characters - Issue identified - "Solution" found 2022-01-27 3:12 ` Cygwin/X with Win10 display scaling corrupting font display of typed characters - Issue identified - "Solution" found Ken Whitesell @ 2022-02-05 14:25 ` Jon Turney 2022-08-14 11:08 ` Jon Turney 0 siblings, 1 reply; 10+ messages in thread From: Jon Turney @ 2022-02-05 14:25 UTC (permalink / raw) To: Ken Whitesell, The Cygwin Mailing List On 27/01/2022 03:12, Ken Whitesell wrote: > On 1/24/2022 10:02 AM, Jon Turney wrote: >> On 20/01/2022 01:01, Ken Whitesell wrote: >>> On 1/19/2022 2:28 PM, Jon Turney wrote: >>>> On 19/01/2022 00:02, Ken Whitesell wrote: >>>>> On 1/17/2022 1:29 PM, Ken Whitesell wrote: >>>>>> >>>>>> Is there a known solution for this? (Or is it known that there is >>>>>> no solution?) >>>> >>>> Thanks for reporting this. >>>> >>>>>> Any guidance, pointers, suggestions of avenues for further >>>>>> research, or other information, will all be greatly appreciated. >>>>>> >>>>> After more research and experimentation, it appears to be related >>>>> to one of xorg-server, xorg-server-common, or xorg-server-xorg. >>>>> >>>>> Installing the older version 1.20.12-1 of these packages allows the >>>>> windows to be moved between monitors without any issues. Upgrading >>>>> to the current version 21.1.3-1 creates the problems. I'm able to >>>>> replicate this behavior on two different laptops with two different >>>>> external monitors. >>>> >>>> It seems likely that this is an unintended effect of changes in >>>> xorg-server 21.1.0-1, trying to fix problems in this area (See [1]) >>> >>> Thanks for the references. I've read all the messages in the thread - >>> I was particularly intrigued by this comment: >>> >>> wrt the font scaling issue, looking at the source, it seems that we >>> don't re-consider the display dpi after a WM_DISPLAYCHANGE message, but >>> keep on using the value determined at startup. This is probably a bug. >>> >>> I'm curious enough to want to take a look at the code, but I've got >>> no belief that I'm going to be able to find an answer. (I'm *not* a >>> C++ programmer. I can read it and write a little of it, but that's >>> about it.) I was going to start by comparing the last known-working >>> version to the first known-non-working version, but given that it's a >>> major release change, that's not likely going to be a useful >>> approach. (I'm way out of my league here. It's probably going to take >>> me a long time just to get to the point where I can even begin to >>> explore this.) >> >> The relevant change, which tries to fix the issue identified in that >> comment, and probably introduces this issue is: >> >> https://gitlab.freedesktop.org/jturney/xserver/-/commit/b19b6266d33f2b911dc1826ad5c03da135a39957 >> >> >> [...] [...] > > But, the real reason for my reply at this point is to report that I have > found a solution for _my_ issue. > > I make no guarantees about any problems anyone else may be facing, nor > can I make any statement about whether or not this causes other problems. > > Obligatory disclaimer: I don't really know what I'm doing here. I'm not > a Windows developer, and I know just enough about cygwin to muddle my > way through doing what I want to do with the help of the mailing lists > and other resources. I'm not in a position to _explain_ anything. This > works for me, but that's as far as I can go. > > First, the bottom line: > > XWin.exe.manifest, line 21 > > change: > <dpiAwareness>PerMonitorV2,PerMonitor</dpiAwareness> > to > <dpiAwareness>PerMonitor</dpiAwareness> > > Some details: > > I managed to get to a point where I could build the packages from source > and install them. I looked at the commit you referred me to, and started > reverting changes, one-by-one - at least in so far as the change > appeared to make sense to me. > > Anyway, I got to this change, and sure enough, it worked. Removing the > "PerMonitorV2" solved the issue. Also, I confirmed that it's the > "PerMonitorV2" that is causing the issue and not having both of them by > running another test with just the "PerMonitorV2" - and that still shows > the problem. Thanks for taking the time to narrow this down. It's been very helpful. Working through the documented effects of that [1], I was able to work out that this mis-rendering is due to the non-client area scaling. [1] See under DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 in https://docs.microsoft.com/en-us/windows/win32/hidpi/dpi-awareness-context If you turn off 'Hide Root Window' from the tray menu, you can kind of see what's going wrong: normally the client area of the X window is exactly aligned with that in the root window, but when the non-client area is rescaled by a DPI change (the title bar changes size significantly), it's misaligned so that part of the X window is outside the client area (and thus clipped in updates). I think this is due to the AdjustWindowsRectEx() function not being DPI aware (I guess it's always computing the non-client window rect based on the processes initial DPI) Unfortunately, from an initial look, rewriting things to use AdjustWindowRectExForDpi() isn't trivial (since we need to make 'DPI of the monitor this Window is going to end up on' available to it) So for the moment, I think I'll apply your reversion (although this probably comes at the cost of not scaling the window frame, the traymenu and About... dialog) ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Cygwin/X with Win10 display scaling corrupting font display of typed characters - Issue identified - "Solution" found 2022-02-05 14:25 ` Jon Turney @ 2022-08-14 11:08 ` Jon Turney 0 siblings, 0 replies; 10+ messages in thread From: Jon Turney @ 2022-08-14 11:08 UTC (permalink / raw) To: Ken Whitesell, The Cygwin Mailing List On 05/02/2022 14:25, Jon Turney wrote: > On 27/01/2022 03:12, Ken Whitesell wrote: >> First, the bottom line: >> >> XWin.exe.manifest, line 21 >> >> change: >> <dpiAwareness>PerMonitorV2,PerMonitor</dpiAwareness> >> to >> <dpiAwareness>PerMonitor</dpiAwareness> >> >> Some details: >> >> I managed to get to a point where I could build the packages from >> source and install them. I looked at the commit you referred me to, >> and started reverting changes, one-by-one - at least in so far as the >> change appeared to make sense to me. >> >> Anyway, I got to this change, and sure enough, it worked. Removing the >> "PerMonitorV2" solved the issue. Also, I confirmed that it's the >> "PerMonitorV2" that is causing the issue and not having both of them >> by running another test with just the "PerMonitorV2" - and that still >> shows the problem. > > Thanks for taking the time to narrow this down. It's been very helpful. > > Working through the documented effects of that [1], I was able to work > out that this mis-rendering is due to the non-client area scaling. > > [1] See under DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 in > https://docs.microsoft.com/en-us/windows/win32/hidpi/dpi-awareness-context > > If you turn off 'Hide Root Window' from the tray menu, you can kind of > see what's going wrong: normally the client area of the X window is > exactly aligned with that in the root window, but when the non-client > area is rescaled by a DPI change (the title bar changes size > significantly), it's misaligned so that part of the X window is outside > the client area (and thus clipped in updates). > > I think this is due to the AdjustWindowsRectEx() function not being DPI > aware (I guess it's always computing the non-client window rect based on > the processes initial DPI) > > Unfortunately, from an initial look, rewriting things to use > AdjustWindowRectExForDpi() isn't trivial (since we need to make 'DPI of > the monitor this Window is going to end up on' available to it) > > So for the moment, I think I'll apply your reversion (although this > probably comes at the cost of not scaling the window frame, the traymenu > and About... dialog) I made this change in xserver 21.1.4-1. Thanks again for tracking this down. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2022-08-14 11:08 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-01-17 18:29 Cygwin/X with Win10 display scaling corrupting font display of typed characters Ken Whitesell 2022-01-19 0:02 ` Cygwin/X with Win10 display scaling corrupting font display of typed characters - Issue identified Ken Whitesell 2022-01-19 19:28 ` Jon Turney 2022-01-20 1:01 ` Ken Whitesell 2022-01-21 18:26 ` Cygwin/X with Win[10]-^ display scaling corrupting font display of typed characters - Issue [identified]-???? L A Walsh 2022-01-23 20:25 ` Cygwin/X display scaling corrupting font display of typed characters; L A Walsh 2022-01-24 15:02 ` Cygwin/X with Win10 display scaling corrupting font display of typed characters - Issue identified Jon Turney 2022-01-27 3:12 ` Cygwin/X with Win10 display scaling corrupting font display of typed characters - Issue identified - "Solution" found Ken Whitesell 2022-02-05 14:25 ` Jon Turney 2022-08-14 11:08 ` Jon Turney
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).