bbidulock / icewm

A window manager designed for speed, usability, and consistency
Other
596 stars 99 forks source link

IceWM does not really use full UHD screen and messes mouse pointer up #517

Closed hharders closed 3 years ago

hharders commented 3 years ago

I am using IceWM 1.9.2 (same issue with 1.4.2 and 1.6.5) on a Thinkpad T440p with a Philips UHD monitor with native resolution of 3840x2160 pixels.

IceWM, however, believes the resolution was HD (1920x1080 pixels) and places the task bar for the upper left quarter (on the bottom of a virtual 1920x1080 pixel screen). See screenshot below.

For the rest, the behaviour is a bit inconsistent:

Side remark: My OpenSUSE Leap 15.1 system does not recognize the full resolution automatically but needs to set this resolution by xrandr in the .xinitrc. I have taken care that the resolution is adapted before starting the window manager. May the issue be related to that topic?

Please let me know if you need more information.

screenshot-icewm_1 9 2-4k-skaliert

Code7R commented 3 years ago

Creepy. Please tell us more about your environment.

I have seen a similar issue recently when I was playing around with XWayland and a WQHD monitor but didn't have time to investigate it. So, is there Wayland involved?

If not, please send output of xrandr command.

gijsbers commented 3 years ago

Do xdpyinfo and xwininfo -root report the correct 3840x2160 dimension? xdpyinfo should show something like:

number of screens:    1

screen #0:
  dimensions: 3840x2160 ...

Please post the output of xwininfo -root.

Does it help if you hide and show the taskbar by hitting Ctrl+Alt+h twice? Otherwise try icewm -r for a restart.

hharders commented 3 years ago

I don't know what Xwayland exactly is but it appears to be running: harders@lose:~> ps ax | grep wayl 2435 tty7 Ssl+ 0:00 /usr/lib/gdm/gdm-wayland-session gnome-session --autostart /usr/share/gdm/greeter/autostart 2500 tty7 Sl+ 0:00 /usr/bin/Xwayland :1024 -rootless -terminate -core -auth /run/user/462/mutter/Xauthority -listen 4 -listen 5 -displayfd 6 4719 pts/2 S+ 0:00 grep --color=auto wayl

xdpyinfo and xwininfo do report the 3840x2160 dimension. xrandr.log xdpyinfo.log xwininfo.log

Both Ctrl+Alt+h twice and icewm -rdo not help

Do you know how I can switch off Xwayland in order to try whether it affects this behaviour? I have read a couple of articles about Xwayland but haven't understood what it really does and what might not run anymore if I switch it off. As a first attempt, I have killed all Xwayland tasks and restarted icewm. This did not help.

What should I try out next?

gijsbers commented 3 years ago

Maybe at your login manager you can choose to avoid Wayland and go for a classic X11?

What I find curious in your xdpyinfo.log is that it first says: eDP-1 connected primary 1920x1080+0+0

and then later it says: HDMI-1 connected 3840x2160+0+0

Maybe you can correct this with xrandr --output?

Another option you can try is to set in icewm preferences XRRPrimaryScreenName="HDMI-1"

hharders commented 3 years ago

My login manager provides a couple of options (for example Gnome with or without Wayland, but for IceWM there's only one option so that I cannot easily switch of Wayland.

XRRPrimaryScreenName="HDMI-1"does not help.

eDP-1 is the built-in laptop screen. Why it's active and the primary screen in spite the laptop is closed isn't clear to me.

Running xrandr --output HDMI-1 --primary and icewm -r resolves the problem! Thank you!

I just don't know what happens if I add this xrandr statement ~/.xinitrc and run the laptop without external monitor. However, that's seldom...

I'll close this issue as soon as I have tested whether it works after next login.

hharders commented 3 years ago

Having following statements in .xinitrc works fine for me: xrandr --output HDMI-1 --mode 3840x2160 xrandr --output HDMI-1 --primary No idea whether I could combine it into one statement. I don't care because it is fairly quick.

Thank you guys for your help!

Code7R commented 3 years ago

It should be noted that this is a workaround but the issue is not gone. I remember having seen a similar misbehavior in the past on WQHD&FHD monitor combo, but it was hard to reproduce.