[Bug]: Vertical DPI change when triggering soft keyboard

[knyipab]

Problem description

Both the mouse position and vertical resolution (DPI?) change (see the attached video below) when software keyboard is triggered.

The vertical resolution issue seems to happen to foldable device (tested on my Samsung Fold Z5) but not in the folded screen (portrait screen).

https://github.com/termux/termux-x11/assets/46513942/7eb33b51-4e36-4f34-80e2-6fa6f35447df

What steps will reproduce the bug?

Using a tablet or foldable device or perhaps emulator may reproduce the issue as shown in the video.

What is the expected behavior?

Mouse position stay and vertical resolution (DPI?) does not change.

[twaik]

Uncheck "Reseed screen while soft keyboard is open".

[knyipab]

Sorry I should be more accurate, it's indeed "vertical DPI" (you can see that the word "Google" is more stretched vertically).

Or is this sudden DPI change an expected behavior when "Reseed screen while soft keyboard is open" is checked?

Thanks for your answer.

[twaik]

Can you please post the whole xev log while toggling keyboard? Not screenshots, post a file.

[knyipab]

I ain't so sure which part of xev log corresponds to keyboard toggling so I attached the whole log (~580 lines). Hope it won't be too long for you.

vert_dpi.log

Happy to do anything that I can help.

[twaik]

When you hide keyboard. DPI = (800 / 211) * 25.4 = 96.3033175355 ≈ 96.

RRScreenChangeNotify event, serial 52, synthetic NO, window 0x1e00001,
    root 0x511, timestamp 44559953, config_timestamp 46373042
    size_index 0, subpixel_order SubPixelUnknown
    rotation RR_Rotate_0
    width 1200, height 800, mwidth 317, mheight 211

When you show keyboard. DPI = (1400 / 370) * 25.4 = 96.1081081081 ≈ 96.

RRScreenChangeNotify event, serial 49, synthetic NO, window 0x1e00001,
    root 0x511, timestamp 44559953, config_timestamp 46372342
    size_index 0, subpixel_order SubPixelUnknown
    rotation RR_Rotate_0
    width 1200, height 1400, mwidth 317, mheight 370

Conclusion: DPI remains unchanged, probably there is some other reason for this.

[twaik]

Does this happen when you choose native "Display resolution mode"?

[knyipab]

No, it does not happen when it is set to native.

[twaik]

What about scaled and some custom scale?

[knyipab]

That was 140%. I found that 170% also sees visually significant difference while 150% and 120% has DPI visually similar toggling keyboard (still no same). Only native has no visible change at all in DPI.

Even scaled 100% exhibits very subtle difference, unlike native. So I compared their logs as below.

native

RRScreenChangeNotify event, serial 34, synthetic NO, window 0x1e00001,
    root 0x511, timestamp 44559953, config_timestamp 49346063
    size_index 0, subpixel_order SubPixelUnknown
    rotation RR_Rotate_0
    width 1808, height 1970, mwidth 478, mheight 521

RRScreenChangeNotify event, serial 40, synthetic NO, window 0x1e00001,
    root 0x511, timestamp 44559953, config_timestamp 49346712
    size_index 0, subpixel_order SubPixelUnknown
    rotation RR_Rotate_0
    width 1808, height 1255, mwidth 478, mheight 332

100%

RRScreenChangeNotify event, serial 34, synthetic NO, window 0x1e00001,
    root 0x511, timestamp 44559953, config_timestamp 49426455
    size_index 0, subpixel_order SubPixelUnknown
    rotation RR_Rotate_0
    width 1800, height 1900, mwidth 476, mheight 502

RRScreenChangeNotify event, serial 40, synthetic NO, window 0x1e00001,
    root 0x511, timestamp 44559953, config_timestamp 49427276
    size_index 0, subpixel_order SubPixelUnknown
    rotation RR_Rotate_0
    width 1800, height 1200, mwidth 476, mheight 317

native_display.log scale_100_display.log

[twaik]

Probably that happens because onMeasure method fails to calculate measurements. I'll try to fix it later.

[knyipab]

I guess it is rounded down in scaled. Based on the above logs:

• When there is no keyboard: 1970/1.4 = 1407.143 is rounded down to 1400
• When Keyboard is on: 1255/1.4 = 896.429 is rounded down to 800 which incurs big difference (10.8% loss) May consider to round it to the nearest integer if no performance concern.

[twaik]

In my case onMeasure does not use rounding. But maybe the problem in using setMeasuredDimension and not setMeasuredDimensionRaw. I'll check it later.