We use the __GL_YIELD=usleep workaround when we detect the NVIDIA
driver, so we could use glFinish without the NVIDIA driver taking all
the CPU.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Because it needs to be cleared when we reset, so we don't use a freed
fbconfig across reset.
Related: #381
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
GLX context is not destroyed immediately after calling
glXDestroyContext. It is only destroyed when it's no longer
being used. So make sure to release the context
Fixes#381
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Flags might be cleared on a destroyed window, if it's set because of an
event received before the window is destroyed.
Eventually we want to delay the handling of destroy notify as well.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Mark it CLIENT_STALE and clear the client instead of recheck it
immediately. It's better to recheck when we have the server grabbed.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Make sure the window struct is indeed destroyed and freed when a window
is reparented away from root. So we won't find it later and get
confused.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Don't just mark it as CLIENT_STALE. To make sure we don't later find the
old frame window as the frame of the client.
Fix assertion failure in ev_destroy_notify.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
win_on_factor_change is called when client window changed for a frame,
in that case, the mode of the window could change.
Related: #299
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
This reverts commit 04fe4a76b2.
This brings back the previous incomplete fix attempt for #299. See the
commit message of the revert for why it's incomplete.
A different fix is then attempted, see commit xxxxxxx for how that fix
works.
However, the second fix is incomplete by itself as well. The reason is
that i3 reparent the real window to the frame first, before destroying
the placeholder client of that frame. So briefly, that frame would have
2 client windows. And the frame is mapped before the placeholder is
destroyed. So even though we only call win_recheck_client when/if the
frame window is mapped, it can still be called when there are 2 client
windows, it would pick up the wrong client window in that case.
So what we need is to combine both fixes.
The second fix makes sure we are up to date on the client window
information when we starts to listen for events on the frame window;
while the first fix would keep us up to date afterwards.
This revert also includes a fix for assertion failure raised in #371
See #299 for root cause of the bug.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Instead of handling reparent notify on the spot by updating the client
windows, setup a flag on the window and call win_recheck_client later.
This makes handling of complex scenarios easier. As example, see the
case in issue #299.
Note this is not a complete fix for #299
These two flags are intended for subtly different things. I can probably
justify the distinction, but it's definitely difficult to explain. And
there is no obvious benefits to keep them separate.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Commits reverted:
b652e8b58dbdf809d039e9ab970989481ac54f67
While those commits themselves could be useful even if they don't
completely fix#299, they come with the risks of introduce more
unforeseen bugs, which outweigh their benefit, so revert them.
A brief explanation of their problem:
The fix hinges on the destroy event of the client window to work.
However, the client window could be destroyed so fast, before we even
handle the map, or even the create, event of the frame. And we won't be
listening for substructure events on the frame at the point the client
window is destroyed. Thus completely miss the client window destroy
event.
Because of the inherent racy nature of Xorg, this approach is really
difficult to make work.
Fixes#371
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
So we can pick up destroy notify of the client windows. Because we need
the destroy notify of the client window to trigger a client window
recheck on the frame window. This is to handle the case where a frame
window is later reused, and the case where multiple client windows are
momentarily attached to the same frame[1].
This will also cause events previously unseen to be generated. Most of
the events would be ignored, because they don't have a corresponding
managed window. Change has been made to ev_reparent_notify, so it would
handle the case where a client window is reparented from one frame to
another[2]. Previously such events are not received by picom.
Related[1]: e9ab970989
Related[2]: 481ac54f67
Related: #299
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
We detach the client window from its frame when it's destroyed, so later
a new window can be attached to that frame. But turns out that's not
enough.
When i3 restarts, it attaches a placeholder window to the frame, then
the real window, and only after that, it will destroy the placeholder.
The real window will fail to attach as the frame already has a client.
When the placeholder is destroyed, we have to call recheck client to
pick up the real window that failed to attach previously.
Related: #299
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Basically, don't ignore the reparent notify if the window is already a
client window. We already unmark it from its previous frame, so this
commit make sure it gets marked with its new frame.
Related: #299
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
We do nothing when a non-wm-frame window is destroyed. This will cause
trouble if a wm-frame window is reused (i.e. its child is destroyed then
a new child is reparented to it), because we didn't clear client_win.
So this commit adds a call to win_unmark_client for that case.
Related: #299
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Previously, root ConfigureNotify is handled immediately, by resetting
the backend, which in turn releases all the window images. This puts all
the windows into a state where they don't have images attached, which
they really should be in when the screen is redirected.
(To expand a little, a window without images should only exist if:
* It's an unmanaged window.
* Screen is unredirected.)
Normally, this kind of window could be fine, as the next render phase
will re-acquire images for them. However, if a window in this state is
destroyed with fading enabled, then the render phase won't try to
acquire images for it, causing it to go into the main rendering function
without images attached, and trigger an assertion.
This commit delays the handling of root ConfigureNotify until the render
phase. This way, the images will be immediately re-acquired after they
are released, thus prevent this problem from happening.
Also adds a testcase for this.
Fixes#357
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
x_print_error aborts the program when it sees a redirect_subwindow
failure. A function called x_print_error really shouldn't cause the
program to terminate.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
In configure_root, the root pixmap is freed by destroy_backend, and is
never acquired again.
Usually this doesn't seem to cause any problems, maybe because we
immediately receives a root damage notification. But under rare
circumstances we ended up not showing the wallpaper.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Frame extents are only updated when the window has frame_opacity < 1.
However, window frames can have inherent transparency, and not having
the frame extents information for those windows breaks blur-background-frame.
Fixes#345
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
The focused state is a derivative state of the raw focused state (i.e.
whether the window is actually focused), with focus rules applied.
Here, we consolidate the calculation of the focused state into the
win_on_factor_change function, and replaced all calls to
win_update_focused with win_on_factor_change.
Also, the opacity update in win_update_focused is moved to
win_on_factor_change, as there could be opacity rules depending on the
focused state, so opacity must only be updated after
win_update_opacity_rule is called.
Related: #266#317
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Always refresh derivative window states in win_on_factor_change, without
checking if there are rules set.
c2_match is a no-op when there is no rules set. And we want to
consolidate derivative window state updates to one place,
win_on_factor_change is a good choice for that.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
The geometry returned by xcb_get_geometry doesn't include the window
border, so we have to include that when calculating the frame.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
In gl_image_apply_alpha, the call to _gl_fill uses 0 as the target
framebuffer, so the alpha is not applied to the target texture.
Fix that by using the correct framebuffer.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Previously some fiedls of gl_texture allocated in gl_image_decouple are
not initialized.
This commit replaces cmalloc with ccalloc to make sure the allocated
gl_texture is zero initialized.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Don't set win::flags to 0 in paint_preprocess, as that can break
assertions in other places. And there is also no need to do so as
win::flags are properly tracked regardless of the backend used.
Fixes#270
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Previously, when frame_opacity is < 1, we consider windows with frames to be
WIN_FRAME_TRANS immediately, without even checking if the body of the window
is transparent. The result is a transparent window is seen as a opaque window
with only a transparent frame, causing its background to not be blurred.
Fixes#211
Currently picom fails at register_cm(), which is before
print_diagnostics(), so we don't see anything.
This commit makes sure we keep going when there is another compositor
already running. However, in this case we need to be careful to not take
the overlay window, otherwise a poorly implemented compositor (for
example, picom) will stop working.
Also restructured the target window initialization logic and added some
comments explaining the logic.
Fixes#333
GLX context is released when it's no longer current in any threads, so
we have to release the context before destroy it.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Prevent a useless error message from glGetUniformLocationChecked, as
"opacity" is not used by the dummy shader, we will fail to get its
location.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
If the user is using custom shaders, picom will naturally fail to get
some uniform locations if the given uniform is not used in the shader.
So we really shouldn't report error for it.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
"notify" is the only wintype that has a name inconsistent with its Xorg
name. So fix that.
Compatibility code is added as well, so the old "notify" wintype name
still works.
Fixes#323
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
xdgh in xdg_config_home is not always allocated. This commit makes sure
it's always a valid pointer to free by strdup it.
With helps from @dtzWill
Fixes#326Closes#327
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
According to the XDG Base Directory Specification, relative paths in
XDG_CONFIG_DIRS are invalid, so eliminate them if found.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Fixed 2 problems:
1. Made sure the returned list is NULL terminated.
2. Allocate the duplicated string and the return list together, so the
duplicated string will be freed as we free the list. Fixed a memory
leak.
Fixes#324
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
While /dev/null is always empty, it still generates inotify events. So
using /dev/null as config file will cause the compositor to reset itself
frequently.
Not entire sure if only allowing regular files is sufficient, but we
will be doing this until an issue comes up.
Fixes#320
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Yuxuan Shui