There were a few improper uses of %ld for 64 bit numbers, as well as
some other 32 bit related warnings that I've fixed.
Signed-off-by: ktprograms <ktprograms@gmail.com>
Explicitly set `xinerama_scr_regs` to `NULL` after calling free() to
avoid freeing them again.
Under normal operation we free the old xinerama screen region list on
root screen changes and allocate a new one with the updated regions.
On rare occasions — mainly reproducable by changing monitors while DPMS
is in standby — updating the region list might fail as for whatever
reason the xinerama extension is marked as inactive. This would leave
us with an invalid pointer to the already freed region list we would
then attempt to free again on the next root screen change.
Added the new `clip-shadow-above` configuration and wintype option.
These allow the user to select windows to clip from the shadow region of
other windows, i.e. don't paint shadows on top of them.
This should provide a more useful and userfriendly alternative to the
deprecated `shadow-exclude-reg` option — especially for docks and bars.
If the user has no access to the GPU, initialization of the GLX context
fails. In the legacy backend, this occurs BEFORE the session has been
successfully initialized.
At this point we cannot meaningfully filter xerrors as the session
hasn't been initialized yet. So we don't try to.
Currently there is some inconsistency in how image_op is implemented
across backends. The glx backend applies some of the image operations
lazily, and not always in the order the operations were made; while the
xrender backend applies the operations eagerly. This can lead to
different render result in some cases.
Instead of trying to preserving the order of operations, which would be
unnecessary, we re-model the API to better reflect the implementation.
We make it clear that setting the property doesn't change the image
data, and properties are only applied during composition and in a
specific order.
This makes sure the render result looks consistent across backends.
Should also improve the performance of the xrender backend, even if only
slightly.
Also distill out the property management code so they can be shared.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Since commit 95a64acf5a, fill_win doesn't
set the window geometry anymore, so we can't use it in
handle_new_windows.
However, we don't need to add damage in handle_new_windows anyway,
damage will be added later when the MAPPED flag is handled.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Consider these 2 cases:
* A window is mapped while fading out
* A window is mapped and damaged while fading out
From the perspective of map_win_start, these 2 cases look the same. The
window will has ever_damage = true in both cases. However, map_win_start
has to distinguish between these 2 cases, because at the end of
map_win_start, window in the first case cannot have ever_damage = true,
while window in the second case should have ever_damage = true.
Currently, map_win_start always clears ever_damage in both cases
(indirectly through win_skip_fading), which causes windows in the second
case to not be rendered when they should be.
This commit move clearing of ever_damage from unmap_win_finish to
unmap_win_start, so when map_win_start sees ever_damage = true, it's
always to second case. And to make sure windows which are fading out are
still rendered, we relax the ever_damage check in paint_preprocess to
also accept windows that are fading out. (see code comment for
explanation why this is fine)
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Set WIN_FLAGS_MAPPED instead, it will be handled later. Previously, we
call map_win_start because we need the geometry of the window, which is
updated in map_win_start. Now, we get the geometry in fill_win, so
map_win_start is not needed anymore.
Eliminate a case where destroy_backend could see IMAGES_STALE flags set
on windows.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Make unmapped window events work mostly like a mapped window, except
flags set on unmapped windows aren't processed until the window is
mapped.
Hopefully this unifies some of the code paths and reduce corner cases.
Should fix#525
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
When the screen is unredirected, no window have a shadow image. So the
assertions in win_set_shadow don't hold. But in that case, we don't want
to add damages anyway. So we put them behind a check of whether the screen
is redirected.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
- Fix non-critical memory-leak in `picom.c` and `options.c` where we
don't free all allocated memory before dieing.
- Explicitly allocate new branch in `c2.c` to silence false-positive
memory-leak.
Of course, we still use GLX, so we can't completely remove Xlib yet. But
this removes all Xlib uses outside of the backends.
This drops support for COMPOUND_TEXT Xorg strings, so people how wants
multilingual support has to use UTF8, which should be fine since most of
the applications support that.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Partially revert 32754b0262.
We start with mapping the window (`win_process_update_flags()`). Then check
if focus has changed and process focus updates. Finally refresh stale images
(`win_process_image_flags`) because rules based on focus may have invalidated
them or require them to be created.
Fixes#465 with the following rule:
```
shadow-exclude = [
"focused" != 1"
]
```
**Work-in-Progress**
Add `dual_kawase` to configuration and argument parsing. Allow `kawase`
for backward compatibility. Add `--blur-strength` parameter for
blur-method `dual_kawase`.
Update documentation to reflect the new blur-method and parameters.
All names start with underscore are reserved in C.
Also just testing out the language server's renaming feature.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
This is a workaround for #301. This doesn't fix the bug, but by
allocating X resources much less frequently, this should make the
bug almost never happen.
Also, it might generally be a good idea to not create/destroy X
resources so often. (XFixes Region accounts for >99% of the resource
creations/destructions)
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
xrender-sync-fence might be enabled after init because of driver
detection. Instead of creating it on demand, just always create it as
this is simpler.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
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>
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>
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>
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>
