If you have several windows open and you start moving a window with mouse that is not front/active, it sometimes does move behind the currently "active" window, although I would assume that you moving a window would have made it active and brought foreground. More often happens when the currently active window is (borderless)fullscreen window, like mpv player (or some wine application), and you start dragging some other window from other display to the display where the mpv is/was active and the other window just disappears behind it.
workaround I have been using is that you just first click the other window you want to move and make it active and then with second click-hold start dragging it.
currently xfdesktop 4.18.1
; xfwm4 4.18.0
, but the problems have been around forever as long as I can remember.
did read it, probably didn't understand fully. now re-reading it though, I can only comment:
The panels are placed above all other windows, and th WM tries to avoid other (lower) window to fall behind the panels. The "struts" are the way for the panel to specify the areas where those other windows should not be placed.
And that's exactly that isn't happening. The window is placed where it falls behind the panel and is placed where it should not be placed.
but still. did you watch the video I made (panel there is places on bottom right screen left edge)? it surely does look like it struts it the wrong way. wrong edge of the window to the wrong edge of the panel?
can you split them up please to 2 different settings? this snapping for unmaximized windows just moving around the screen surely should not be part of this setting in the first place? more like some kind of bad side effect?
Ah now I see. it does indeed "fix" the unmaximized windows not snapping anymore, but then it gives me another problem that when I maximize window in that screen with the panel, it does go below it, which is also undesired. So currently I can choose between 2 different undesired options.
a) [v] keep panel above windows -- windows don't snap in the middle of the screen to panel = GOOD; maximizing window goes below panel = BAD
b) [ ] keep panel above windows -- windows DO snap in the middle of the screen to panel = BAD; maximizing window goes to the space between screen edges and up until panel. = GOOD.
Wait what? Please look the video I attached in my first post. it's perfectly UNnormal and undesired behavior. Why the eff would I (or anyone else for that matter) want any window to snap in weird places in the middle of the screen UNDER the panel while panel is still covering half of the window? On top of that I don't want any windows to snap to anything at all ever! And I made that perfectly clear in my settings:
which for some reason is ignored and still snapping to panels on weird conditions.
If for some weird reason you desire such behavior then please at least give us some option or setting to turn this off. In my eyes it's just so unnormal and unnatural behavior that "bug" was the only way to describe it.
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 0
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_STICK
WM_STATE(WM_STATE):
window state: Normal
icon window: 0xd6c37300
_NET_WM_DESKTOP(CARDINAL) = 4294967295
_NET_WM_STATE(ATOM) = _NET_WM_STATE_STICKY, _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_FOCUSED
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
window id # of group leader: 0x1200001
_GTK_THEME_VARIANT(UTF8_STRING) = "dark"
XdndAware(ATOM) = BITMAP
_NET_WM_STRUT_PARTIAL(CARDINAL) = 2720, 0, 0, 0, 1080, 2279, 0, 0, 0, 0, 0, 0
_NET_WM_OPAQUE_REGION(CARDINAL) =
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0
WM_WINDOW_ROLE(STRING) = "Panel"
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 18874373, 18874374
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x1200004
WM_CLIENT_LEADER(WINDOW): window id # 0x1200001
_NET_WM_PID(CARDINAL) = 1641
WM_LOCALE_NAME(STRING) = "en_US.utf8"
WM_CLIENT_MACHINE(STRING) = "Zen"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified minimum size: 160 by 1200
program specified maximum size: 160 by 1200
program specified base size: 0 by 0
window gravity: Static
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "xfce4-panel", "Xfce4-panel"
WM_ICON_NAME(STRING) = "xfce4-panel"
_NET_WM_ICON_NAME(UTF8_STRING) = "xfce4-panel"
WM_NAME(STRING) = "xfce4-panel"
_NET_WM_NAME(UTF8_STRING) = "xfce4-panel"
xfce4-panel 4.18.2
No idea what "strut" even is or how to set it.
How do I give you property dump?
( Why would I move it to the left monitor? I don't want any panels on my primary monitor, because there I use my fullscreen apps / movies / games whatever. I don't want panels to be covered or overlaying fullscreen stuff. )
But alright. For answering your question, I did try it. Then the snapping happens also, but exactly mirrored way. The window left edge is snapping to the panels left edge -1cm to the left.
However right now my suboptimal (because I need to turn my head way too much, because the left monitors are in front and right monitors are ... on the right, so the right edge of the right monitor is like way out of sight) workaround was to move it to the right edge of the right monitor and then there is no snapping. Also the snapping seems to go away when I move the panel just minimally, like half cm or something) off the right monitor left edge (where the panel itself snapped into) -- but the problem with that is that when I fullscreen anything on right monitor, the window fullscreens entirely and the panel is covering the window.
So the snapping only happens, when the panel itself is snapped into the screen edge between displays / monitors. When panel itself is snapped to the outer edge of the entire thing, there is no snapping windows to it.
Since upgrade to xfce 4.18 I have this (improved*) snapping issue that I can't turn off. It seems to snap windows to vertical panel right edge some weird way. Can't really describe, so I screen recorded. Did turn off screen edge and window snapping, but this panel snapping still occurs.
or for simplicity sake first 18 bytes... (as I don't know why I can't use -s and -n with the hexdump at the same time
$ find /sys/ | grep -i edid
find: ‘/sys/kernel/tracing’: Permission denied
find: ‘/sys/kernel/debug’: Permission denied
/sys/devices/pci0000:00/0000:00:03.1/0000:2d:00.0/0000:2e:00.0/0000:2f:00.0/drm/card0/card0-HDMI-A-1/edid
/sys/devices/pci0000:00/0000:00:03.1/0000:2d:00.0/0000:2e:00.0/0000:2f:00.0/drm/card0/card0-DP-2/edid
/sys/devices/pci0000:00/0000:00:03.1/0000:2d:00.0/0000:2e:00.0/0000:2f:00.0/drm/card0/card0-DP-3/edid
/sys/devices/pci0000:00/0000:00:03.1/0000:2d:00.0/0000:2e:00.0/0000:2f:00.0/drm/card0/card0-DP-1/edid
find: ‘/sys/fs/pstore’: Permission denied
find: ‘/sys/fs/bpf’: Permission denied
/sys/module/drm_kms_helper/parameters/edid_firmware
/sys/module/drm/parameters/edid_firmware
/sys/module/drm/parameters/edid_fixup
$ cat /sys/devices/pci0000:00/0000:00:03.1/0000:2d:00.0/0000:2e:00.0/0000:2f:00.0/drm/card0/card0-DP-1/edid | hexdump -n 18 -v -e '/1 "%02X"'
00FFFFFFFFFFFF0005E37932xxxxxxxx111C
# actually better command to find all display EDIDs:
$ ls -1 /sys/class/drm/*/edid
/sys/class/drm/card0-DP-1/edid
/sys/class/drm/card0-DP-2/edid
/sys/class/drm/card0-DP-3/edid
/sys/class/drm/card0-HDMI-A-1/edid
$ cat /sys/class/drm/card0-DP-1/edid | hexdump -n 18 -v -e '/1 "%02X"'
00FFFFFFFFFFFF0005E37932xxxxxxxx111C
(replaced serial bytes with x'es)
Frankly, for unique identification purpose, you don't need to parse the edid at all, just read it and use 9th to 18th byte (or entire edid), without decoding them, and use it as identifier string.
if it would get "truly disconnected", then moving mouse and waking computer up, should not turn such display on, but it does wake up.
Also why does turning a display on/off from button or come out of sleep even trigger new monitor detection actions in the first place? It should not. Monitor going to sleep or waking up should never ever trigger display arrangement and layout change events.
Only hard power off/on or (dis)connecting cable should trigger display arrangement change event.
ofc there needs to be different EDID decoder for the AOC display, because the EDID code is somehow 2 times bigger than described in this picture is possible...
edit: or not... from the same page Extension Flag – EDID versions 1.3 and higher allow for additional 128-byte blocks of data to describe increased capabilities.
... so probably AOC has this going on for it's EDID.
Yes, I have 2 seemingly identical displays (on first picture 2 and 4), DP/N: 0J8J31, Rev A00, Aug 2013. However their EDID's are different (as EDID code includes also the monitor serial number; also for some reason their product ID 9940 vs 9840 + EDID revision numbers are different 03 vs 04. and obviously checksum in the end). Maybe you can use this to identify displays, when it stays constant forever for one display? Or just extract the serial number and manufacturer info from EDID somehow and use this, if the EDID can change in operation, as those should remain same still)?
(source: https://www.extron.com/article/uedid ) I would say EDID code positions 8-17 would make a good identifier (if the entire EDID code is unusable for some reason (I do not know if it is or is not, if you lets say, play around with monitor settings in monitor own in-built control panel and change things, will this alter EDID)).
Have 4 displays -- 3 Dell, 1 AOC (Q3279VWFD8). Have learned to live with the reality that the layout and icons gets changed up every time displays resume from sleep (or is turned back on from power button), so had/have implemented xrandr script to fix this.
#!/bin/sh
xrandr --output DisplayPort-0 --primary --mode 2560x1440 --refresh 74.97 --pos 0x1080 --rotate normal\
--output DisplayPort-1 --mode 1920x1080 --pos 640x0 --rotate normal\
--output DisplayPort-2 --mode 1920x1200 --pos 2560x1080 --rotate normal\
--output HDMI-A-0 --mode 1920x1080 --pos 2560x0 --rotate normal
Default and wanted layout is this:
However with the update to Manjaro that updated the Xfce from 4.16 directly to 4.18, it got different and slightly more painful to restore. Now the script simply fixes the layout (if it got mixed up at all, sometimes it doesn't anymore), but all the icons remain scrambled -- well, moved and piled up to display 3+4 and displays 1+2 are left with 0 icons. Also there is this new/old popup every time when the AOC display comes online (previously only saw it once and never again, now I see it after every suspend).
Almost like it always detects this AOC display as "new monitor" that it has never seen before???
(So for a workaround have to run 2 scripts now, one that messes layout slightly more up, and the current one, so swapping between them couple of times the icons also shake to place).
And it only happens when AOC display (sadly main) is turned back on. Changing the primary display to any of the other displays didn't change the result/behavior. Don't understand how one monitor sleep / wake-up (from display power management xfce4-power-manager
) or power off-on (from button on display) acts so differently from other displays. And/or why xfdesktop doesn't change the display layout back, when all 4 are back "on". Is it fixable from your end or any suggestions what I could do here?
Not quite sure how linux and/or xfce detects if the display is "NEW". And why AOC display turning off or going to sleep kind of removes the display from "OLD KNOWN" displays list, so when it comes back online, it's always detected as "NEW". How does the display remembering even work for xfce? what id or number it stores and compares to when some display is (re-)connected? Only visible "ID" difference I see from xrandr --verbose is that Dell displays EDID's are 8 lines, while AOC EDID is 16 lines (unexpected size for xfce, so it doesn't bother remembering it?).
EDIT: just now found another quality-of-life workaround: in xfce4-settings
=> Advanced => When new displays are connected : Show dialog > Do nothing.
Seems to fix the new display popup from appearing AND doesn't seem to scramble the icons that much (they twitch, but then jerk back to the old position almost...? not perfectly, but at least to some rather recent "save point", couple of icons have only moved.)
This was unchecked. Checked it, didn't see any difference whatsoever. So unchecked again. If there is supposed to be differences, can you share screenshots with comments, where I should see any difference?
Yes it is. There must be clear distiction between just-click and click-hold-release action. Currently it's hit and miss most of the time.