public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* 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).