ssokolow / quicktile

Adds window-tiling hotkeys to any X11 desktop. (An analogue to WinSplit Revolution for people who don't want to use Compiz Grid)
https://ssokolow.com/quicktile/
GNU General Public License v2.0
860 stars 78 forks source link

FIX quicktile thinks my screen is much smaller than it is #113

Closed allanlaal closed 4 years ago

allanlaal commented 4 years ago

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

ssokolow commented 4 years ago

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

allanlaal commented 4 years ago

@ssokolow:

[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)
ssokolow commented 4 years ago

That DEBUG: Loaded monitor geometry: [Rectangle(x=0, y=0, width=1440, height=810)] suggests that the root problem is:

  1. libwnck doesn't have functions to get screen rectangles, so I call into GDK for it.
  2. GDK returns dimensions in "application pixels"
  3. 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.)

ssokolow commented 4 years ago

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

ssokolow commented 4 years ago

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.

allanlaal commented 4 years ago

@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?

allanlaal commented 4 years ago

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)

ssokolow commented 4 years ago

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.

allanlaal commented 4 years ago

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

ssokolow commented 4 years ago

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.

allanlaal commented 4 years ago

can I help somehow? I really miss QuickTiles ability to resize windows that have static sizes

ssokolow commented 4 years ago

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.

ssokolow commented 4 years ago

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.

ssokolow commented 4 years ago

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.

allanlaal commented 4 years ago

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
ssokolow commented 4 years ago

OK. I'll get it merged into master soon then.

ssokolow commented 4 years ago

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.