FIX quicktile thinks my screen is much smaller than it is
allanlaal opened this issue · comments
when I tile, it only happens on the top left 25% of my 3K screen
using Ubuntu 20.04 with Mate Desktop, which now has HiDPI support, so my DPI is the normal 90
previously used Ubuntu Mate 16.04, which has no HiDPI support, so I set my DPI at 200+ (quicktile worked great then)
lemme know if I can gather some debug information :)
Hopefully, the only debug information I'll need is for you to run QuickTile with --debug
, trigger the problem, and then attach the resulting log.
(And thanks for reminding me that I need to add a proper "how to report a bug" section to the manual next time I work on it.)
[2020-03-01.15:24:32] allan@L4:~$ quicktile --debug
DEBUG: Loaded monitor geometry: [Rectangle(x=0, y=0, width=1440, height=810)]
DEBUG: Gathered _NET_WM_STRUT_PARTIAL value: [StrutPartial(left=0, right=0, top=48, bottom=0, left_start_y=0, left_end_y=0, right_start_y=0, right_end_y=0, top_start_x=0, top_end_x=2878, bottom_start_x=0, bottom_end_x=0)]
DEBUG: Gathered _NET_WM_STRUT_PARTIAL value: [StrutPartial(left=0, right=0, top=48, bottom=0, left_start_y=0, left_end_y=0, right_start_y=0, right_end_y=0, top_start_x=0, top_end_x=2878, bottom_start_x=0, bottom_end_x=0), StrutPartial(left=0, right=0, top=0, bottom=106, left_start_y=0, left_end_y=0, right_start_y=0, right_end_y=0, top_start_x=0, top_end_x=0, bottom_start_x=0, bottom_end_x=2878)]
DEBUG: Usable desktop region calculated as: Region(<Monitors=[Rectangle(x=0, y=0, width=1440, height=810)], Struts=[StrutPartial(left=0, right=0, top=48, bottom=0, left_start_y=0, left_end_y=0, right_start_y=0, right_end_y=0, top_start_x=0, top_end_x=2878, bottom_start_x=0, bottom_end_x=0), StrutPartial(left=0, right=0, top=0, bottom=106, left_start_y=0, left_end_y=0, right_start_y=0, right_end_y=0, top_start_x=0, top_end_x=0, bottom_start_x=0, bottom_end_x=2878)]>)
[2020-03-01.15:24:58] allan@L4:~$ xrandr -q
Screen 0: minimum 8 x 8, current 2880 x 1620, maximum 16384 x 16384
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
eDP-1-1 connected 2880x1620+0+0 (normal left inverted right x axis y axis) 340mm x 190mm
2880x1620 59.96*+ 47.97
2560x1600 59.97
2560x1440 59.95
2048x1536 60.00
1920x1440 60.00
1856x1392 60.01
1792x1344 60.01
2048x1152 59.98 59.90 59.91
1920x1200 59.88 59.95
1920x1080 59.97 59.96 59.93
1600x1200 60.00
1680x1050 59.95 59.88
1600x1024 60.17
1400x1050 59.98
1600x900 59.99 59.94 59.95 59.82
1280x1024 60.02
1440x900 59.89
1400x900 59.96 59.88
1280x960 60.00
1440x810 60.00 59.97
1368x768 59.88 59.85
1360x768 59.80 59.96
1280x800 59.99 59.97 59.81 59.91
1152x864 60.00
1280x720 60.00 59.99 59.86 59.74
1024x768 60.04 60.00
960x720 60.00
928x696 60.05
896x672 60.01
1024x576 59.95 59.96 59.90 59.82
960x600 59.93 60.00
960x540 59.96 59.99 59.63 59.82
800x600 60.00 60.32 56.25
840x525 60.01 59.88
864x486 59.92 59.57
800x512 60.17
700x525 59.98
800x450 59.95 59.82
640x512 60.02
720x450 59.89
700x450 59.96 59.88
640x480 60.00 59.94
720x405 59.51 58.99
684x384 59.88 59.85
680x384 59.80 59.96
640x400 59.88 59.98
576x432 60.06
640x360 59.86 59.83 59.84 59.32
512x384 60.00
512x288 60.00 59.92
480x270 59.63 59.82
400x300 60.32 56.34
432x243 59.92 59.57
320x240 60.05
360x202 59.51 59.13
320x180 59.84 59.32
VGA-1-1 disconnected (normal left inverted right x axis y axis)
DP-1-1 disconnected (normal left inverted right x axis y axis)
HDMI-1-1 disconnected (normal left inverted right x axis y axis)
DP-1-2 disconnected (normal left inverted right x axis y axis)
HDMI-1-2 disconnected (normal left inverted right x axis y axis)
That DEBUG: Loaded monitor geometry: [Rectangle(x=0, y=0, width=1440, height=810)]
suggests that the root problem is:
- libwnck doesn't have functions to get screen rectangles, so I call into GDK for it.
- GDK returns dimensions in "application pixels"
- Judging by the results you're getting, libwnck expects dimensions in "device pixels"
If so, multiplying the retrieved rectangle by the output of get_monitor_scale_factor
before using it should fix the problem. I'll try to find time either today or tomorrow to put together a patch for you to test.
(I need to audit how my Wnck, GDK, and Xlib APIs interact so I know what to ask you to test, design an API for scaling rectangles and write some unit tests for it, re-test basic functionality that doesn't yet have automated tests to make sure I didn't break anything on displays with a 1:1 scaling factor, update the developer documentation to warn about the mismatch between GDK and Wnck handling of device scaling, and identify whether Xlib APIs follow the GDK or Wnck approach... I suspect they match GDK since that's what'd make sense for compatibility with HiDPI-unaware applications.)
Sorry. Monday was a big mess, so I don't have a patch for you yet.
On the plus side, it looks like there are only three Gdk.Screen.get_monitor_geometry
calls that need to be fixed up to get things working.
As for testing changes locally, I'll have to whip up a quick test script to run under Xvfb and Xephyr to see what combination of -dpi
to the X server binary and --scale
to xrandr
are needed to get GTK+ reporting a scale other than 1
from get_monitor_scale_factor
.
We'll see how much progress I can make on Tuesday.
EDIT: The biggest thing I need to figure out is how scaling works in multi-monitor scenarios. Am I supposed to scale the (x, y)
coordinates of the top-left corner of the monitor rectangle too, or just the (width, height)
? (Intuition would suggest just the width and height, since different monitors could have different scales.)
If I were superstitious, I'd think something doesn't want this bug fixed. The power went out about 15 minutes after I woke up and stayed off all afternoon.
@ssokolow in my case I have a 3K screen on my laptop, which is not scaled + 2 extra shitty K monitors, which scaled to match the 3K screen:
xrandr \
--output eDP-1 \
--mode 2880x1620 \
--scale 1x1 \
--pos 0x0 \
--rotate normal \
--primary \
--output DP-1-1-2 \
--mode 1920x1080 \
--scale 1.67x1.67 \
--pos -3207x0 \
--rotate normal \
--output DP-1-1-1 \
--mode 1920x1200 \
--scale 1.695x1.695 \
--pos 2881x0 \
--rotate normal \
--verbose
does this help?
note that quicktile used to work 100% before I upgraded from ubuntu 16.04 LTS to 20.04 LTS (nightly)
even Mate Desktops native Marco sometimes tiles windows ignoring panel bars (although they are not autohidden)
does this help?
Yes. That means I can slap together a test script for you to run and paste the output of, then try to configure my Xvfb or Xephyr test environments so the script produces the same output. (I also like to use real-world examples in my functional tests, so it's good for that too.)
note that quicktile used to work 100% before I upgraded from ubuntu 16.04 LTS to 20.04 LTS (nightly)
Sounds like, between 16.04 LTS (which I'm on at the moment) and 20.04 nightly, something in the stack changed to lie to GTK+ applications which aren't HiDPI aware for better backwards compatibility... of course, QuickTile got tripped up because it made the assumption that GDK and Wnck would use the same units.
As for getting work done, I spent more of today catching up on the time lost yesterday than I expected, so I don't have anything yet... but I suppose that's a good thing, given that it hadn't occurred to me to send you a diagnostic script and, now that I've thought of it, I want to do that before writing a patch anyway.
Sounds like, between 16.04 LTS (which I'm on at the moment) and 20.04 nightly, something in the stack changed to lie to GTK+ applications which aren't HiDPI aware for better backwards compatibility...
ironically 20.04 boasts with better HiDPI awareness 😆
Not really ironic at all. If QuickTile were a more normal application which used only GTK and GDK APIs, the change would have Just Worked™ as a way to get better HiDPI support for applications that aren't HiDPI aware.
can I help somehow?
I really miss QuickTiles ability to resize windows that have static sizes
Sorry for going silent. COVID wasn't the only thing that's made things messy and distracting for me over the last almost-a-month.
I'm about to go to bed, but I'll try to see what I can fit in tomorrow.
EDIT: A cleanup task took hours longer than expected. Give me another day.
Today also turned out to be much busier than expected so I think, tomorrow, rather than working on that extension to the automated test suite, I'll just slap together a candidate fix in a separate branch and ask you to tell me if it fixes the problem.
No need to let the perfect become the enemy of the good.
EDIT: Reminder to self: Don't tempt Murphy. Rather than having a big goal and little time, I had a small goal and no time. Tomorrow, I guess. At least I got the biggest pending obligation out of the way.
OK. It's untested aside from "It doesn't appear to break top-left
, move-to-top-left
, or monitor-next
with a scale factor of 1
", and it doesn't have any automated testing, but there's a potential fix for you to test in the hidpi_fix
branch.
hidpi_fix tip works flawlessly! tested all on my multimonitor setup:
KP_1 = bottom-left
KP_2 = bottom
KP_3 = bottom-right
KP_4 = left
KP_5 = center
KP_6 = right
KP_7 = top-left
KP_8 = top
KP_9 = top-right
KP_0 = monitor-switch
OK. I'll get it merged into master soon then.
Sorry for letting this fall behind my digital desk for a month when I intended "soon" to mean a few days. It's merged into master now.