Platform: archlinux x86_64
kern: 4.16.8
GPU, drivers, and screen setup: i915 (intel i5-4210U CPU @ 1.70GHz)
modsettings
i3 on xorg(xorg-server 1.19.6+13+gd0d1a694f-2), mesa 18.0.3-1
Compton version: compton 0.1_beta2.5-11
Run compton with following
compton --backend glx --config /dev/null
[ 80.44 ] error 3 BadWindow request 2 minor 0 serial 65013: "BadWindow (invalid Window parameter)"
[ 80.44 ] error 3 BadWindow request 129 minor 6 serial 65014: "BadWindow (invalid Window parameter)"
[ 80.44 ] error 3 BadWindow request 2 minor 0 serial 65015: "BadWindow (invalid Window parameter)"
[ 80.44 ] error 3 BadWindow request 129 minor 5 serial 65017: "BadWindow (invalid Window parameter)"
[ 80.44 ] error 3 BadWindow request 20 minor 0 serial 65018: "BadWindow (invalid Window parameter)"
[ 2800.30 ] error 9 BadDrawable request 14 minor 0 serial 1180299: "BadDrawable (invalid Pixmap or Window parameter)"
glx_bind_pixmap(0x00c3e4b3): Failed to query Pixmap info.
win_paint_win(0x004000af): Failed to bind texture. Expect troubles.
win_paint_win(0x004000af): Missing painting data. This is a bad sign.
[ 2800.31 ] error 4 BadPixmap request 54 minor 0 serial 1180343: "BadPixmap (invalid Pixmap parameter)"
^C
Play video in mpv or google-chrome (with h/w decode or s/w decode) in fullscreen. After sometime videoframe freezes at a point ,but audio keeps continuing. Whole system doesn't freeze. Switch from fullscreen , video frame syncs to appropriate frame and continues.
Happens randomly. Without compositor video plays smoothly.
Play video smoothly without freezing video.
The problem happen also with video games.
But, the master version seems to already have resolved the problem.
The master version hasn't been updated in a year. This issue is newer than that and I can reproduce it on all my archlinux computers when building compton from git using the compton-git package in the aur.
Really strange, using the compton-git fix it for me.
This repo hasn't been updated over a year as you can see. Compton that archlinux packages(that I use) is from yshui. Since compton hasn't been updated for long time it's some dependency (update) that broke compton and compton isn't updated to reflect that change.
I _possibly_ don't have this freeze issue now. It's hard to know since it's random. @ekce Can you try compton with unredir i.e. compton --backend glx --config /dev/null --unredir-if-possible ?
Possibly related to #477 , #493
@BurhanDanger I'll try it when I get a chance.
A couple things I should have mentioned:
@mnivoliez , the game you mentioned , is it opengl accelerated ?
I've noticed the freezes affecting web browsers as well.
Face this as well. Thought it's chrome being chrome.
A bunch of games, all using opengl or used through wine.
Envoyé par BlueMail
Le 30 mai 2018 à 19:34, à 19:34, BurhanDanger notifications@github.com a écrit:
@mnivoliez , the game you mentioned , is it opengl accelerated ?
I've noticed the freezes affecting web browsers as well.
Face this as well. Thought it's chrome being chrome.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/chjj/compton/issues/494#issuecomment-393251124
Experiencing the same issue on my XPS 13 (9350, i7 6560U, Intel Iris Graphics 540), using i3wm. I noticed that displaying the i3bar (using the super key as) unfreezes the display. I can also provide some more details if you want (logs, etc.).
Same issue on XPS 9560 on both intel GPU and on NVIDIA gpu.
That started about half year - 8 month before.
unredir if possible is enabled.
This also happens to non full screen video playback, but super rare. For full screen it happens alot.
Could be that it happens alot for me since I have 4k display... but that's just a wild guess
This happens to me too. using i3-gaps, nvidia drivers. Same in games too (tried with stepmania and enter the gungeon primarily)
The same here. Switching backend to xrender helps, but it's a bit choppy experience compared to glx.
Same here!
The last commit is 1 y/o, 18 pull requests that will never be merged, Wayland is around the corner, I don't think Compton is going anywhere now, sadly...
@JPenuchot I'm maintaining a bug fix fork. But I can't seem to reproduce this bug...
same in games and video
OK, may I ask what window manager do you guys use? Sounds like you are all using i3?
Yep, i3 on my side
Yep, I am using i3-gaps
i3-gaps too
AwesomeWM
Confirming that it happens on openbox too, I was using i3-gaps before
-- att. Fernando Vasquez --
On Fri, Aug 17, 2018 at 9:10 PM, Alex Kir notifications@github.com wrote:
AwesomeWM
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/chjj/compton/issues/494#issuecomment-414028265, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKojScrxIcnWyRlMuHcq8CEhrv2zzI_Tks5uR4WggaJpZM4T939H
.
Xfwm4
Hmm, I was thinking this might be because compton doesn't interact well with i3. But no, it happens with other WM as well.
Now I'm lost, I'm using AwesomeWM, and this problem has never happened to me. I need a way to reproduce this before I can fix this.
Are there any logs to look for when it happens? Or maybe I can try to troubleshoot it locally, just tell me where to look :) I didn't find any messages in journal nor in .xsession-errors.
I doubt there are logs for that.
Also I think that might be caused by resolution, I have 2 machines one 1080p and the other one is 4k and freezes happen on 4k only.
They are quite heavy with YouTube 1080/60 fullscreen videos
I don't think it really has anything to do with resolution, it happens on both my monitor and my laptop screen 1080p and 720p respectively, anyway, here are my settings (which are pretty basic if I may add)
backend = "glx";
paint-on-overlay = true;
glx-no-stencil = true;
vsync = "opengl-swc";
shadow = false;
unredir-if-possible = true;
unredir-if-possible-exclude = "class_g = 'Chrome'";
shadow-exclude = [
"name = 'Notification'",
"_GTK_FRAME_EXTENTS@:c",
"class_g = 'i3-frame'",
"_NET_WM_STATE@:32a *= '_NET_WM_STATE_HIDDEN'",
"_NET_WM_STATE@:32a *= '_NET_WM_STATE_STICKY'",
"!I3_FLOATING_WINDOW@:c",
"g:si:VirtualBox"
];
I'm using an intel internal graphics card, if that works for anything
Oh btw that might be something meaningful, my 4k screen is on intel and the other is nvidia... Could be intel only issue?
intel too
I have the problem with my nvidia card using i3 as well, so probably not intel specific.
btw my i3bar is hidden by default and I can unfreeze the display by displaying it (by pressing Win, basically)
Mine unfreezes upon any mouse click or key press.
Hmm. I think I can somehow reproduce it now. So OpenGL windows can sometimes freeze for a couple of seconds before they continue normally.
I also noticed a jitter (feels like a fluctuation in frame rates) in some games.
Will look into it.
That is great, please do share if you achieve a relliable reproduction
method
El sáb., ago. 18, 2018 8:12 PM, yshui notifications@github.com escribió:
Hmm. I think I can somehow reproduce it now. So OpenGL windows can
sometimes freeze for a couple of seconds before they continue normally.I also noticed a jitter (feels like a fluctuation in frame rates) in some
games.Will look into it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/chjj/compton/issues/494#issuecomment-414098015, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKojSR8AdV88zS1YqZ1_jTMc-ZegxTPhks5uSMmhgaJpZM4T939H
.
Does this problem still happen if you disable vsync? (i.e. --vsync none)
Set vsync to none, been watching cat videos for half an hour right now, looks ok so far but I'll keep going to see if it happens again...
Will give it a spin as soon as I can, any bspwm users with this issue?
El ago. 19, 2018 4:13 PM, "Jules Pénuchot" notifications@github.com
escribió:
Set vsync to none, been watching cat videos for half an hour right now,
looks ok so far but I'll keep going to see if it happens again...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/chjj/compton/issues/494#issuecomment-414159684, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKojSRDGfQE32vWY8KiClKav5O8PnNkEks5uSeMCgaJpZM4T939H
.
Still freezes without vsync
Confirm freezing without vsync
I've moved to bspwm and still getting this issue, I can firmly say that this issue appears to be wm independant, I've reproduced with openbox, i3 and now bspwm.
@yshui, what is the default vsync that compton uses ?
@BurhanDanger it's none by default
My compton.conf , this is what I've been using since I posted this bug-report.
Anyway This is what happens in my freeze.
@BurhanDanger If you have time, could try isolate which config option eliminated the freeze? I would have guessed unredir-if-possible, but there are people who can reproduce this bug with that enable.....
unredir-if-possible is what I initially thought. That may not be the case. A while ago I changed vsync in config file to opengl and experienced issue.
BurhanDanger's config seems to work on my machine, so I tried to figure out which are the magic options. I used this video to test the config, downloaded it with youtube-dl and played it with mpv. Here are the steps I followed:
# name: value;sync && sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'mpv --fs --start=01:58 video.mkvThese are the options that seem to be essential:
backend = "glx";
vsync = "opengl-swc";
unredir-if-possible = true;
detect-rounded-corners = true;
And one of these options (not sure which one) seems to improve the performance a bit, but maybe it's just my imagination as I got tired of watching the same video again and again:
mark-wmwin-focused = true;
mark-ovredir-focused = true;
use-ewmh-active-win = true;
I know that unredir-if-possible is supposed to "maximize performance for full-screen windows", but I don't really understand why the video freezes without detect-rounded-corners (the manual even says that "the accuracy is not very high, unfortunately").
This bug is hard to reproduce and I use only one DE/WM so I'm not sure that this config fixes it, but for now it works for me. I'll tell you if I get another freeze.
I could try to reproduce on i3, bspwm and openbox
El mié., ago. 22, 2018 11:41 AM, nxnev notifications@github.com escribió:
BurhanDanger's config seems to work on my machine, so I tried to figure
out which are the magic options. I used this video
https://www.youtube.com/watch?v=-f4clXg9n-U to test the config,
downloaded it with youtube-dl and played it with mpv. Here are the steps I
followed:
- Comment out the current option: # name: value;
- Clear cache: sync && sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
- Play video: mpv --fs --start=01:58 video.mkv
- If it plays well, leave the option out; if it freezes, uncomment
the option. Then, repeat using the following option.These are the options that seem to be essential:
backend = "glx";
vsync = "opengl-swc";
unredir-if-possible = true;
detect-rounded-corners = true;And one of these options (not sure which one) seems to improve the
performance a bit, but maybe it's just my imagination as I got tired of
watching the same video again and again:mark-wmwin-focused = true;
mark-ovredir-focused = true;
use-ewmh-active-win = true;I know that unredir-if-possible is supposed to "maximize performance for
full-screen windows", but I don't really understand why the video freezes
without detect-rounded-corners (the manual even says that "the accuracy
is not very high, unfortunately").This bug is hard to reproduce and I use only one DE/WM so I'm not sure
that this config fixes it, but for now it works for me. I'll tell you if I
get another freeze.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/chjj/compton/issues/494#issuecomment-415117162, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKojSTFVwF36otAtedj9vaRdh8rGRjv4ks5uTZfKgaJpZM4T939H
.
I tried the exact options on i3-gaps and it didn't work. OpenGL window (dosbox) froze couple times.
I'm having the same problems. I'm using official ubuntu version of i3wm with this compton config.
I can verify that the screen freezes only when the media playing window is in fullscreen mode. When in normal tiling mode with i3blocks as i3bar, the screen doesn't freeze. So, I'm handling the situation by avoiding full screen video playback.
@enanajmain, could you please post a pastebin url or something on that line instead?
anyway I've been testing with bspwm the settings layed out by @nxnev and I'm still waiting for a freeze, it's worked good so far!
Well, I got a freeze. While I'm not able to reproduce it in fullscreen, in a normal-sized window it happens frequently. Using BurhanDanger's config instead of mine doesn't help either.
Using i3-gaps & compton, freeze only occurs in fullscreen video and unfreezes on any keypress.
Nxnev's config seems to be working for me, the only settings I changed were:
vsync = "opengl-swc";
unredir-if-possible = true;
Not entirely sure which one is helping the situation, will be testing each individually.
@RyanScottLewis I've both of these options set as you have from the beginning. But I still face the freezing. I don't think this is the solution. Also, my freezes doesn't unfreeze on any keypress. I have to log out and log back in.
I just changed unredir-if-possible from false to true, and now I haven't met this problem anymore.
this is my config file
btw, I am using i3-gaps
Ah, so this is what was wrong. I initially thought it was an X11 or even NVIDIA driver issue. I get the freezes after some random period of time without keyboard/mouse input unless I'm running something fullscreen. The screen unfreezes if I press a key or click the mouse. I'm on openbox btw.
my config
(I use a fork that adds kawase blur, since it looks better than the standard options)
In order to reproduce the freeze, just play any video(not from youtube, I used videos from this site http://fmovies.se) and repeatedly press f to go to and back from full screen mode. In my case, after a couple times of pressing f results in a freeze and doesn't unfreeze until I logout. But some people said they could unfreeze with a keypress or mouse click! I don't know why I can't do that.
Alright, can someone test this one thing for me? Can you run compton with --benchmark 100000, and see if the freeze still happens? (compton will automatically exit after ~30min when running with this options, which is normal).
I think I might have narrowed down the cause.
@yshui Not sure if you mean this, but after a while I got the following crash:
[ 4144.92 ] error 9 BadDrawable request 14 minor 0 serial 2127202: "BadDrawable (invalid Pixmap or Window parameter)"
glx_bind_pixmap(0x03472c16): Failed to query Pixmap info.
win_paint_win(0x01e00054): Failed to bind texture. Expect troubles.
win_paint_win(0x01e00054): Missing painting data. This is a bad sign.
[ 4144.92 ] error 9 BadDrawable request 14 minor 0 serial 2127209: "BadDrawable (invalid Pixmap or Window parameter)"
[ 4144.92 ] error 4 BadPixmap request 54 minor 0 serial 2127210: "BadPixmap (invalid Pixmap parameter)"
[ 4193.25 ] error 3 BadWindow request 20 minor 0 serial 2199137: "BadWindow (invalid Window parameter)"
[ 4193.25 ] error 3 BadWindow request 20 minor 0 serial 2199138: "BadWindow (invalid Window parameter)"
[ 4193.25 ] error 3 BadWindow request 20 minor 0 serial 2199139: "BadWindow (invalid Window parameter)"
[ 4193.25 ] error 3 BadWindow request 20 minor 0 serial 2199140: "BadWindow (invalid Window parameter)"
@jacksgt
Also with --benchmark 10000 I pretty much unable to watch any video due to extremely bad stuttering/lagging/low fps.
That is somewhat expected. The benchmark options will force compton to draw as much frames as possible, which would put heavy load on the system. Someone with better hardware might be able to get a reasonable frame rate, and confirm whether the freeze still happens or not.
@yshui Sorry, the stuttering issue was unrelated, that was due to watching a video in 4K.
I tried another video (1080p), but still got the same crash as shown above.
Maybe you can be more specific about what you think the cause is.
@yshui --benchmark 100000 seems to work, I haven't noticed any freeze. This is the command I used: compton --backend glx --benchmark 100000 --config /dev/null --vsync opengl-swc --unredir-if-possible. Would it be possible to set --benchmark to something like infinity to avoid compton to exit?
I confirm --benchmark 100000 worked for me or at least I haven't seen freeze happen for half an hour
The more I debug, the less sense this bug makes. This could be some race condition actually inside X server.
After adding a XFlush(), the freeze happens almost constantly. However, if I run the exact same code under strace (which only changes timing), everything would be just fine.
I don't think compton is using the API incorrectly, so this could very likely be a problem outside compton.
Alright, I made a terrible hack that seems to do the job for me. If you could give it a try a report back (does it work? does it cause more problems?), it would be great. Branch is yshui/compton#damaged.
I might find some X developers and annoy them with this problem and see what they would say.
Your branch works fine for me and I didn't notice anything wrong so far. Let me know if I can help with anything.
It works for me, no problems for now.
BTW, unredir-if-possible would have solved this problem for fullscreen window. But compton's fullscreen detection probably isn't stellar.
unredir-if-possible did prevent the freezes for me on fullscreen though.
I'm not seeing any more freezes with that branch now btw, but just to be sure I'm going to do some more testing.
Well, the freezes seem to still happen every now and then, but at least they only last a second or two.
@yshui your branch seems to have fixed the issue for me.
I have been running your fork since yesterday and it seems to work flawlessly.
unredir-if-possible did not prevent freezes on all windows and added tearing for me.
Running fork for last 3 days, no issue.
Does this come with any performance penalty ?
EDIT: I have not faced notable performance issue.
@BurhanDanger It could. Did you notice any performance changes?
# Unredirect all windows if a full-screen opaque window is detected, to maximize performance for full-screen windows, like games.
# Known to cause flickering when redirecting/unredirecting windows.
# paint-on-overlay may make the flickering less obvious.
This comes from the default compton.conf file. Performance should be better but it might not solve freeze issues while not in fullscreen. I'll run some tests to confirm that.
Confirmed, just had a freeze with unredir-if-possible enabled and Chrome not in fullscreen.
What is the condition now of this issue?
@enanajmain A workaround is in place (which might cause performance problems), and I'm looking into the real cause of the problem.
Thanks for still looking into it!
I think I fully understand it now. Turns out to be a Xlib bug.
Lesson learned: never use Xlib, always use xcb
Plan is to switch at least the event handling bit to xcb. Will definitely need some testers.
Very cool of you to take care of that issue, thanks a lot
Done. Can someone try this branch: yshui/compton@next ?
(Beware that branch has extra changes that contain bugs. If you encounter other problems unrelated to screen freeze, please open a issue on my repo mentioning the name of the branch.)
(This branch is known to crash due to some xlib/xcb interoperability issues)
@yshui I was using Ubuntu 17.10 with compton in their official repo. Yesterday I switched to Ubuntu 18.04. Now, before I went on to install your branch, I wanted to record and test if the problem still persists. I don't know why, but the problem has fixed itself. I've been watching videos on mpv and chromium-browser while constantly pressing f to go in and out of full screen, nothing, no freezing.
The current version on official Ubuntu repo is v0.1~beta2+20150922, which is the latest I think. I don't know what version I was using in Ubuntu 17.10, but I think it was the same.
N.B I think it's worth mentioning that the chromium browser has had a massive upgrade. Maybe that has something to do with it.
I am running your next branch, it seems to fix the issue as well.
I'm seeing regular crashes on the next branch. So test at will, but don't make the switch just yet.
Edit: I updated the next branch and the problem I was seeing should be fixed.
Been running on the next branch for a few hours, so far no crash (Arch Linux, i7 6560U, i3wm).
Have run the branch for a day. No crashes so far and the glx backend works fine.
I tried yshui/compton@next this solves the problem for me!
Video does not freeze in full screen anymore.
(Fedora 28, Intel Core i7-8550U, i3-gaps)
I still get these messages:
[ 587.82 ] error 3 BadWindow request 2 minor 0 serial 469375: "BadWindow (invalid Window parameter)"
Don't know whether that is important.
Thanks for making an effort! This was a very frustrating problem, I even switched to sway to try it out, it's great, but the stable branch does not have the features I want yet.
Same here, been using it daily for 2 days and got no problem so far. Good work ! Do you have a donation link or something ?
Making the switch to that branch on my setup, will see if things work alright.
@JPenuchot I would rather have helping hands than donations.
Haven't seen ANY freezes so far after a day of use. Thank you~
I'm closing this now since it looks like yshui 's next branch solved this(which also needs testing for regression). Test that and Feel free to comment here or open issue on yshui's fork mentioning which branch you used.
I would rather have helping hands than donations.
@yshui What can I help you with specifically? :-)
@psychon I composed a short list of things I can think of right now:
@yshui Okay, which branch do you want me to work against? "Move to XCB" sounds like something that I can easily do and I touched pixman's API once or twice and might be able to "do stuff with regions".
@psychon I'm currently doing the pixman conversion, so maybe you could pick up the xcb conversion?
You can base your work on the next branch.
I've decided to test the old version of compton one more time. Interestingly I wasn't able to reproduce the issue. It might have something to do with the updated kernel (currently 4.18.8-200.fc28.x86_64). I don't see anything else from graphics stack updated. Just wanted to let you know.
@valsoray17 The screen freeze is caused by an extremely timing dependent race condition. The bug can totally be there in the old version (BTW, it's a Xlib bug) but just doesn't manifest.
Thanks for the explanation, will monitor the old version more
@yshui, I was using next branch of your fork for a week. I just experienced two crashes today. Any idea?
@enanajmain please open a bug report
Most helpful comment
Plan is to switch at least the event handling bit to xcb. Will definitely need some testers.