You are not logged in.
Hi
originally I was using i3, xorg and an older nvidia gpu with tesla 470 driver.
Two monitors, different resolutions:
xrandr --listmonitors
Monitors: 2
0: +HDMI-0 2560/597x1440/336+1920+0 HDMI-0
1: +DVI-D-0 1920/480x1080/270+0+0 DVI-D-0
Fullscreen *global* worked just great for citrix wfica so I could work from home across two monitors.
No issues with the different resolution, the config was pretty intuitive to toggle the screen to the scratchpad to get to my "real" desktop.
However unfortunately i3 has some issue where when launching a window that isn't taking up the whole of one monitor, sometimes xorg will rise to 100%. The only way to restore usability was to exit i3, effectively restarting xorg.
This became very annoying, I suspect it could be the older nvidia driver or the funky different resolution setup I have, I don't have the time to fix it.
I tried awesomewm and dwm, however I could not figure out how to get fullscreen for wfica across both monitors.
Any tips anyone has on this will be very welcome, I'm willing to learn either WM, I just want tiling and not to have to restart xorg every few hours!
tl;dr how do i configure dwm (or awesomewm) to put a window fullscreen span across two monitors without xinerama?
Offline
when launching a window that isn't taking up the whole of one monitor, sometimes xorg will rise to 100%
Sounds like WM and an aspect-restricted client enter a war about the window size?
https://wiki.archlinux.org/title/I3#Fau … _terminals
Do you have "xprop" for such window? (You don't have to wait for the cpu overload)
Does floating such window then immediately help?
Offline
Honestly it's happened so many times in different ways. Typically it's something like opening zoom when the popup dialog for the login doesn't fill the whole screen, or calibre. Or something else too!
So hard to nail down to any given easy to reproduce situation to then get the xprop on.
I think floating windows are the problem, not fullscreen ones, but that's just my impression.
Offline
There's a good chance not only X11 has higher CPU load but also the WM and the client at war.
Try to set dialogs to floating?
(You could also compile i3 yourself and undo that patch)
Offline
I'm going to try to figure it out. Running compiled i3 now, not had the issue yet as not used the PC much.
It's worth a bit of time invested as i3 is absolutely fantastic, just what I need.
Offline
couple of runs of strace during higher cpu:
strace: Process 1487913 attached
^Cstrace: Process 1487913 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
0.00 0.000000 0 257 read
0.00 0.000000 0 2743 rt_sigreturn
0.00 0.000000 0 209 ioctl
0.00 0.000000 0 2742 writev
0.00 0.000000 0 663 setitimer
0.00 0.000000 0 2336 520 recvmsg
0.00 0.000000 0 6 clock_nanosleep
0.00 0.000000 0 836 epoll_wait
0.00 0.000000 0 208 epoll_ctl
------ ----------- ----------- --------- --------- ----------------
100.00 0.000000 0 10000 520 total
strace: Process 1487913 attached
^Cstrace: Process 1487913 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
0.00 0.000000 0 1098 read
0.00 0.000000 0 143 write
0.00 0.000000 0 4210 4 rt_sigreturn
0.00 0.000000 0 646 ioctl
0.00 0.000000 0 22567 writev
0.00 0.000000 0 3742 sched_yield
0.00 0.000000 0 2 shmat
0.00 0.000000 0 2 shmctl
0.00 0.000000 0 7320 setitimer
0.00 0.000000 0 1 1 recvfrom
0.00 0.000000 0 20625 4433 recvmsg
0.00 0.000000 0 2 getsockopt
0.00 0.000000 0 2 shmdt
0.00 0.000000 0 6 1 futex
0.00 0.000000 0 22 clock_nanosleep
0.00 0.000000 0 6021 epoll_wait
0.00 0.000000 0 1144 epoll_ctl
------ ----------- ----------- --------- --------- ----------------
100.00 0.000000 0 67553 4439 total
Offline
strace is probably less helpful than top in this case - also what's that strace for and use [code][/code] tags.
Offline
What would you recommend? It's of xorg pid. Noted on code vs em.
Offline
You check top for the processes consuming the most cpu time when you run into this.
It's likely Xorg, i3 and something else™. Something else™ triggers this. Then inspect its windows.
Offline
right I already used top to know it's xorg, no other processes are anywhere near 80%+ at the time of the xorg slowdown.
So there are no other candidates.
If there were another candidate can you elaborate on "inspect its windows"?
Offline
You're not looking for 80%+ but the next most active things.
The X11 server will take the brunt by having to respond and act upon the contradicting claims.
You might be able to lower this when injecting a compositor to eg. avoid exposure events.
By "inspect its windows" I mostly mean "xprop"
Offline