330794 2014-02-05 10:54:58 +0000 window movement lags with vsync and KWIN_USE_BUFFER_AGE=1 (and double buffering) on nvidia 334.x 2018-11-11 12:12:46 +0000 1 1 4 Plasma kwin compositing 4.11.6 Arch Linux Linux RESOLVED FIXED NOR normal --- 0 obuolis1 kwin-bugs-null michael razrfalcon 0 oldest_to_newest 1428849 0 obuolis1 2014-02-05 10:54:58 +0000 After the update i noticed that when you try to move window fast, it lags behind mouse cursor, and also the system becomes less responsible, the animations seems to have some miliseconds delay, it also seems the more i use the system the more laggy it becomes altough the lagging isn't very bad or critical, but it's still noticeable. This happens on latest Nvidia blob with having added these lines in /etc/profile (this is workaround, because vsync doesnt work without these lines added): export __GL_YIELD="USLEEP" if i disable vsync the problem goes away, or if i disable vsync and re enable it then vsync works fine and that problem goes away, until i logout, after new session it goes back and i have to repeat that procedure. Reproducible: Always Steps to Reproduce: 1.enable vsync 2.open few windows and try to move them 3. Actual Results: the window becomes "lazy" and it lags after mouse cursor, altough there is no fps loss Expected Results: it should follow mouse better like it did in 4.11.5 1428875 1 thomas.luebking 2014-02-05 14:07:43 +0000 also see bug #329821 copied from there: -- I just discovered a reliable way to reproduce the lag at any time. If I run an application that is playing a video or doing any kind of continuous animation, it makes all window dragging lag in exactly the same way I described with the circular dragging earlier. -- My monitor does run at 60Hz and I do have KWIN_TRIPLE_BUFFER=1 set, so that sounds right. And moving through jelly is a good description. It is still smooth, but just is smooth farther behind the mouse cursor than it was before buffer_age was introduced. ------ I guess it feels like moving through jelly, the window follows the mouse - it does not hang and then jump to the mouse position? Dev note: This would mean we load the swapbuffer with too many swaps what can basically have two reasons: 1. misdetection/overridden refreshrate/MaxFPS 2. triplebuffer misdetection (assumed to be NOT available, while it indeed is) According to the present debug output, the refreshrate is detected as 60Hz (what is supported by the nvidia-settings query) - so it had to be 3buf detection, just that comment #25 explicitly states that this occurred WITH KWIN_TRIPLE_BUFFER=1 ... So there must be a third reason to overcommit frames (could be broken paint time calculation) > export __GL_YIELD="USLEEP" You've no triple buffering enabled? Please attach the output of qdbus org.kde.kwin /KWin supportInformation 1428885 2 85005 michael 2014-02-05 14:55:52 +0000 Created attachment 85005 Output of "qdbus org.kde.kwin /KWin supportInformation" Here is my output from "qdbus org.kde.kwin /KWin supportInformation". I am still running the same configuration as I was for the last bug (triple buffering on, KWIN_TRIPLE_BUFFER=1, and vsync set to auto). One more possibly-relevant bit: If I have a 30fps video file playing in an mplayer window and put it directly behind a Firefox window, when I start scrolling in Firefox, the section of the Firefox window that covers up the mplayer window updates before the rest of the Firefox window, causing a rectangular box of "tearing". This "tearing" goes away after one or two frames of animation, but it is definitely there. 1428927 3 thomas.luebking 2014-02-05 18:27:38 +0000 thanks, but i mostly wonder about simonas' setup - if it's not triplebuffering, frame overcommit should be a red herring. the "tearing" would suggest that the occlusion check is broken (for buffer_age only?) - unless the FF window is translucent or at least argb. 1428928 4 michael 2014-02-05 18:31:09 +0000 It doesn't look like he is using triple buffering (he said that vsync would not work without __GL_YIELD="usleep". I can reproduce the "tearing" with applications other than Firefox too, so I guess I will file another bug about that. 1428935 5 85010 obuolis1 2014-02-05 18:54:53 +0000 Created attachment 85010 Qdbus output 1428939 6 obuolis1 2014-02-05 19:02:22 +0000 No, i'm not using triple buffering, but if i do now: export KWIN_TRIPLE_BUFFER=1 kwin --replace & Then the window lagging behind cursor is gone mostly, it still feels a little bit lagging behind mouse, but the difference is that window no longer jitters when moved, because there was very little jittering in 4.11.5 and earlier when i moved windows. But again that lagging is so little that its really hard to even notice that, and if we count that windows no longer have very little jitter like they used to, i guess its fine. And for me that window lagging behind cursor happens on every window for me, be it firefox, terminal or dolphin. 1428941 7 thomas.luebking 2014-02-05 19:22:10 +0000 (In reply to comment #6) > No, i'm not using triple buffering, but if i do now: > export KWIN_TRIPLE_BUFFER=1 it's not that simple. What does grep -i triple /var/log/Xorg.0.log say? Then unset KWIN_TRIPLE_BUFFER kwin --replace & # wait some time while the screen is updated qdbus org.kde.kwin /KWin supportInformation Those informations are crucial so that we're not blindly guessing around on causes here. 1428943 8 thomas.luebking 2014-02-05 19:25:18 +0000 Ok, sorry - this: > Painting blocks for vertical retrace: yes Means you had not exported that setting, but triple buffering is detected as unavailable. If it was indeed be enabled (Xorg.0.log grep) but misdetected, that would explain the lagging (since overcommit can be expected) 1428948 9 obuolis1 2014-02-05 19:49:53 +0000 Yes, I made the attached file when i didn't have triple buffering set with that command. For some reason when i do grep -i triple /var/log/Xorg.0.log, terminal outputs me nothing, but here is a full file: http://paste.kde.org/p0649650c Another interesting thing i noticed is that when i boot to my kde desktop and quickly open any window, the window movement is good for like first 5-7 seconds and after that time this problem occurs. 1428950 10 obuolis1 2014-02-05 19:54:24 +0000 And here is output of qdbus when i have triple buffering set with that command (if relevant): http://paste.kde.org/p05e840b0 and Xorg.0.log file with triple buffering set: http://paste.kde.org/p67ea1081 1428953 11 thomas.luebking 2014-02-05 20:01:16 +0000 (In reply to comment #9) > For some reason when i do grep -i triple /var/log/Xorg.0.log, terminal > outputs me nothing, but here is a full file: The reason is that triple buffering is actually not enabled (and that being correctly detected) In 4.11.5, the detection was broken (bug #329821) and .. > Another interesting thing i noticed is that when i boot to my kde desktop > and quickly open any window, the window movement is good for like first 5-7 > seconds and after that time this problem occurs. ... during the detection phase, triple buffering is assumed to be available. Now, this is really interesting, since w/o triple buffering, glSwap will block (and wait for the retrace - the reason why gl yielding needs to be usleep; otherwise it's expensive) what means, there's no chance for an overcommit. w/o actual triple buffering, exporting KWIN_TRIPLE_BUFFER is *clearly* wrong (it'll lead to jitter for missing retraces) Try instead: ------------------- unset KWIN_TRIPLE_BUFFER export KWIN_USE_BUFFER_AGE=0 kwin --replace & and report about the result. 1428958 12 obuolis1 2014-02-05 20:17:14 +0000 Well, then i start to see tearing, so I guess vsync is off. 1428961 13 thomas.luebking 2014-02-05 20:24:24 +0000 despite export __GL_YIELD="USLEEP" ? Is this then: qdbus org.kde.kwin /KWin supportInformation | grep glPreferBufferSwap > glPreferBufferSwap: 0 ? 1428963 14 obuolis1 2014-02-05 20:34:58 +0000 Yes in all my tests I had __GL_YIELD="USLEEP" enabled. This is what i get: glPreferBufferSwap: 99 1428966 15 thomas.luebking 2014-02-05 20:50:41 +0000 unless this is kwin_gles, that indicates a) swapInterval is "1" b) every frame is swapped -> no option for actual tearing (unless you had disabled flipping in nvidia-settings) What happens when setting the tearing prevention to "full repaints"? 1428973 16 obuolis1 2014-02-05 21:04:32 +0000 with full scene repaints set vsync starts to work fine, and i get no issue with window lagging behind mouse cursor, in other words it works exactly like it did with 4.11.5. Just in case that's the output now: glPreferBufferSwap: 112 1428976 17 thomas.luebking 2014-02-05 21:08:41 +0000 (In reply to comment #16) > in other words it works exactly like it did with 4.11.5. FTR: no, it doesn't - in 4.11.5 it was more like as if you had KWIN_TRIPLE_BUFFER=1 exported. This however implies the frontbuffer copying path had been broken, so to be absolutely sure: it's NOT kwin_gles, is it? (yes: nvidia meanwhile supports GLES, in case you wonder ;-) 1428977 18 michael 2014-02-05 21:10:02 +0000 Even if I put my vsync mode in full repaints, I still get the lag. 1428979 19 thomas.luebking 2014-02-05 21:12:08 +0000 Have "export KWIN_USE_BUFFER_AGE=0" ? (And please keep tearing prevention automatic or "copy frontbuffer" at first - to confirm or deny that the path is broken, thanks) 1428983 20 michael 2014-02-05 21:18:15 +0000 With buffer age disabled, I get a small bit of lag (not nearly as bad as with buffer age) when using full scene repaints and no lag (but tearing) in re-use screen content. 1428986 21 obuolis1 2014-02-05 21:26:19 +0000 well i meant that the performance is as good (or even better) as in 4.11.5. I'm using default archlinux kde packages and as far as i know they aren't using GLES, but i might be wrong, is there a way to check that? 1428990 22 thomas.luebking 2014-02-05 21:32:07 +0000 On arch, you'd have to do some extra in order to get kwin_gles running on nvidia (they don't ship the nvidia GLES/EGL libs atm., pakage conflict, I assume) - so this is kwin/glx. I'm compiling a debug output enabled kwin to see whether and what's wrong here (FB copying) 1428991 23 michael 2014-02-05 21:33:34 +0000 Have you been able to reproduce the issue then? 1428992 24 thomas.luebking 2014-02-05 21:33:56 +0000 (In reply to comment #20) > With buffer age disabled, I get a small bit of lag One frame lag is part of triple buffering (and the cursor is painted in HW directly into the framebuffer, thus not affected by "triple buffering", compositing or anything else) 1428994 25 michael 2014-02-05 21:36:13 +0000 I know. The small bit of lag without buffer_age doesn't really bother me. By the way, I have noticed that on Microsoft® Windows®, they seem to turn off the hardware cursor and paint the cursor image in the same way as the window. 1429010 26 thomas.luebking 2014-02-05 22:14:01 +0000 Copying Frontbuffer broke at some point. Replace: scene_opengl.cpp qint64 SceneOpenGL::paint(QRegion damage, ToplevelList toplevels) { .... validRegion != displayRegion) { glReadBuffer(GL_FRONT); copyPixels(displayRegion - validRegion); glReadBuffer(GL_BACK); - damage = displayRegion; + validRegion = displayRegion; } #endif .... 1429012 27 michael 2014-02-05 22:52:20 +0000 So that will fix the lag? 1429013 28 thomas.luebking 2014-02-05 22:56:09 +0000 No, only the frontbuffer copying path (which is not used if gl_buffer_age is supported, which is apparently the "lagging" path) Frontbuffer copying is (on nvidia, do not use it on MESA ever) however more performant than full scene repaints (notably with blurring enabled) 1429381 29 obuolis1 2014-02-07 22:03:48 +0000 I've manually replaced damage = displayRegion; line with validRegion = displayRegion;, compiled and installed everything, but the same problem still exists, that's my qdbus output now: http://pastebin.kde.org/pc08ef922 1429382 30 thomas.luebking 2014-02-07 22:12:14 +0000 This does _only_ fix tearing when disabling buffer_age support and using frontbuffer coyping. It has no other implications. 1429386 31 obuolis1 2014-02-07 23:28:14 +0000 Ah yes, if i set export KWIN_USE_BUFFER_AGE=0, then vsync works fine when i have it set to automatic. So yeah, it works then 1429489 32 michael 2014-02-08 16:07:37 +0000 Version 334.16 of the NVIDIA blob was just recently released, and I noticed something interesting and potentially relevant in the changelog: "Fixed a bug in the GLX_EXT_buffer_age extension where incorrect ages would be returned unless triple buffering was enabled." 1429496 33 obuolis1 2014-02-08 17:04:51 +0000 @Michael That looks interesting, but i'll wait until this version will hit repos 1429531 34 thomas.luebking 2014-02-08 19:35:23 +0000 (In reply to comment #32) > "Fixed a bug in the GLX_EXT_buffer_age extension where incorrect ages would > be returned unless triple buffering was enabled." But you've triple buffering enabled, don't you? Do you think the lag is more than two frames? (hint: if you can record it, that's easy to figure =) 1429534 35 michael 2014-02-08 19:43:17 +0000 Here is a crappy recording of the lag. Sorry about the video quality. I need to buy a better potato. I am pretty sure the lag is more than 2 frames, since I was using triple buffering without the lag before buffer_age was introduced. http://youtu.be/LgniWcZY190 1430030 36 michael 2014-02-11 01:06:38 +0000 Curiously, I cannot seem to reproduce the lag on a system with an older NVIDIA GPU (GeForce 8600m GT), but I can reproduce it on one system with a Quadro NVS 5400m and another with a GeForce GTX650. 1430042 37 thomas.luebking 2014-02-11 02:20:15 +0000 I don't get it on a GT520 - points a driver issue, but Simonas is on a GeForce 9500 (though he could simply suffer from the bug addressed in the latest driver, as he's triple buffering disabled) About the video - i rather meant a screencast (since this has also the issue to sync cam and screen) However, the lag does not seem too many frames (the window is indeed quite behind the cursor, but when you stop the movement they align very fast) Frame counting on a "cinerip" is however pointless =) 1430047 38 michael 2014-02-11 02:59:22 +0000 So should I go bug aaronp about it then? 1430048 39 thomas.luebking 2014-02-11 03:01:09 +0000 I'd first try the latest driver (nevertheless), but there might be another way to trigger the "wrong buffer age report", sure. 1430049 40 michael 2014-02-11 03:02:03 +0000 I am already running 334.16, which I believe is the latest version available. 1430050 41 thomas.luebking 2014-02-11 03:05:33 +0000 Then you would indeed have to ask (though report from Simonas could be very helpful here, since his GPU is older than mine and if 334.16 fixes it for him, that would stress buffer age report relevance) 1430977 42 obuolis1 2014-02-16 13:50:49 +0000 Ok, so I installed nvidia 334.16 driver, but the problem still exists. 1430978 43 obuolis1 2014-02-16 13:53:15 +0000 Here's my qdbus output btw: http://paste.ubuntu.com/6943236 1430979 44 thomas.luebking 2014-02-16 13:58:04 +0000 Can you please check whether this also occurs for your with triple buffering enabled? /etc/X11/xorg.conf.d/20-nvidia.conf Section "Device" Identifier "Default nvidia Device" Driver "nvidia" Option "NoLogo" "True" # no advertising ;-) Option "CoolBits" "1" # nice to have Option "TripleBuffer" "True" # that's the important one EndSection 1430983 45 obuolis1 2014-02-16 14:05:53 +0000 The problem still occurs, thats the qdbus output now: http://paste.ubuntu.com/6943297 I found another workaround, i open e.g. some game (like scummvm) go to full screen with alt + enter and then go back, and this jelly problem is gone until i restart kde. 1430985 46 thomas.luebking 2014-02-16 14:26:33 +0000 (In reply to comment #45) > The problem still occurs, thats the qdbus output now: > Painting blocks for vertical retrace: yes This does not suggest that TripleBuffering is enabled (you need to restart X11/KDM; "grep -i triple /var/log/Xorg.0.log" to ensure it's enabled) For triple buffering misdetection, frame overcommit (with at least one frame) can be expected (and will lead to jelly) > I found another workaround, i open e.g. some game (like scummvm) go to full > screen with alt + enter and then go back, and this jelly problem is gone > until i restart kde. This is however rather interesting. > unredirectFullscreen: true Does it also work when not "suspend compositing for fullscreen windows" in "kcmshell4 kwincompositing", 3rd tab? I assume simply triggering a fullscreen update (eg. activating the present windows or desktop grid effect) will not do? 1430989 47 obuolis1 2014-02-16 14:39:21 +0000 For some reason it ignored what i have set in /etc/X11/xorg.conf.d/20-nvidia.conf, but setting it in /etc/X11/xorg.conf works, and now as triple buffering is enabled the problem no longer occurs. Yes, this workaround works even when i have unchecked "suspend compositing for fullscreen windows". 1430990 48 michael 2014-02-16 14:41:26 +0000 For me, the jelly still occurs even with triplebuffering turned on. (I have had triplebuffering turned on the whole time.) 1430991 49 obuolis1 2014-02-16 14:43:35 +0000 Btw, activating present windows or desktop grid effect will not fix the problem. 1431058 50 thomas.luebking 2014-02-16 20:49:23 +0000 We've apparently two effects here. One affecting Fermi (only) even on triple buffering and Another one afffecting also "older" chips (at least GF9xxx) on double buffering only, that is affected by "starting a fullscreen game" Both are related to invocation of GL_BUFFER_AGE. @Simonas, does the trick also work with NON OpenGL fullscreen "games"/applications? Eg. playing a video on xv? Does eg. a fullscreen xcreensaver ahck have impact depending on whether its GL or not? I'll deactivate TB here and see what happens on next login. 1431063 51 michael 2014-02-16 20:58:16 +0000 I just tested my 8600m GT system and found that the lag is indeed gone if triple buffering is turned off. 1431064 52 michael 2014-02-16 20:58:48 +0000 Darn, I got that backwards. On the 8600m GT, the lag is there with triple buffering and gone with double buffering. 1431065 53 michael 2014-02-16 21:01:24 +0000 Sorry, I am a complete idiot. Disregard all my previous posts about the 8600m GT. On the 8600m GT, if I have triple buffering turned on, I get no lag. On the 8600m GT, if I have triple buffering turned off, I get lag. Sorry for the spam. 1431074 54 obuolis1 2014-02-16 22:04:21 +0000 Apparently this seems to happen only with resolution changers no matter if it's opengl app or not, but i'll investigate further to be 100% sure. 1431076 55 michael 2014-02-16 22:35:43 +0000 Resolution changing has nothing to do with it for me; I am always running 1920x1080. 1431077 56 thomas.luebking 2014-02-16 22:40:14 +0000 (In reply to comment #55) > Resolution changing has nothing to do with it for me; I am always running > 1920x1080. The idea is that the resolution change (by a fullscreen game at least) will "fix" it on double buffering. 1431078 57 michael 2014-02-16 22:54:48 +0000 I just tested changing resolutions while using double buffering on the NVS 5400m and it has no effect (still lags), so this must be one of the GPU-specific things. 1431081 58 thomas.luebking 2014-02-16 23:29:34 +0000 Ok, sth.'s fishy here. I'm still on 331.38 and with double buffering i see two things happen: 1. On fast window movement, there's a "ghost" frame, like the last frame blended into the current (but may be a lazy eye effect and it's because of frame swapping) I assume this to be the known nvidia bug and it happens regardless of the below. 2. When (re)starting kwin, it's initially snappy, then the swapping is detected to be blocking, enters the blocking path and starts to lag. After suspending and restarting the compositor (could be autosuspending rule for Simonas?) the availability of triple buffering is assumed and the lagging stops. -> That's probably a bug in kwin since iirc, the detection is not supposed to be run more than once, but the availability should certainly not be reset either. Disabling BUFFER_AGE still correctly detects triple buffering to be NOT available, but there's no whatsoever lag. I'll wait for 334.16 hitting arch repos and then measure frame comit & swap times on double buffering. 1432407 59 thomas.luebking 2014-02-24 19:38:31 +0000 Git commit b00cc9cda191795ceae874526c7bd57b2a832982 by Thomas Lübking. Committed on 05/02/2014 at 23:16. Pushed by luebking into branch 'KDE/4.11'. fix frontbuffer copying swap preference REVIEW: 115523 Related: bug 322060 M +1 -1 kwin/scene_opengl.cpp http://commits.kde.org/kde-workspace/b00cc9cda191795ceae874526c7bd57b2a832982 1446577 60 razrfalcon 2014-05-08 04:39:28 +0000 Hello. I just updated from KDE 4.11.5 to 4.12.5 (kwin 4.11.9) and faced this bug. I use only __GL_YIELD="USLEEP" to make VSync work (no KWIN_TRIPLE_BUFFER and other). Without VSync all works good and fast. With VSync I have lag while windows moving. Usually it small 2-3pix, some times even 10-15pix between start mouse postion and current. Also all animations looks lazy. Especially window resizing. NVidia GTX650Ti, driver 334.21. Gentoo. 1446738 61 thomas.luebking 2014-05-08 11:17:35 +0000 what's the output of: grep -i triple /var/log/Xorg.0.log qdbus org.kde.kwin /KWin supportInformation | grep -i block what happens on: export KWIN_USE_BUFFER_AGE=0 kwin --replace & 1446751 62 razrfalcon 2014-05-08 12:16:48 +0000 % grep -i triple /var/log/Xorg.0.log return nothing % qdbus org.kde.kwin /KWin supportInformation | grep -i block Painting blocks for vertical retrace: yes After disabling and reenabling VSync answer is "no". And everything work normal again. Sort of. So basically I need to reenable vsync manually after each reboot. Without it I have huge lags and slow animations. KWIN_USE_BUFFER_AGE do not change anything or I do not see the result. But I have warning: kwin: unable to claim manager selection, another wm running? (try using --replace) 1446761 63 thomas.luebking 2014-05-08 12:53:50 +0000 (In reply to comment #62) > % grep -i triple /var/log/Xorg.0.log > return nothing > > % qdbus org.kde.kwin /KWin supportInformation | grep -i block > Painting blocks for vertical retrace: yes That should be correct. > After disabling and reenabling VSync answer is "no". And everything work > normal again. Sort of. That is a (known) bug - it's not correctly redetectd. > So basically I need to reenable vsync manually after each reboot. Without it > I have huge lags and slow animations. This sounds as if triple buffering was enabled (though not configured), misdetected (thus "Painting blocks for vertical retrace: yes") and therefore frames would be overcomitted, what would be *extremely* strange (bug in driver and kwin driver state detection) -> Please check the impact of "export KWIN_USE_BUFFER_AGE=0" first. > kwin: unable to claim manager selection, another wm running? (try using > --replace) You apparently did not pass the parameter then? ("kwin --replace &") W/o there's no new process and KWIN_USE_BUFFER_AGE is not taken into account. 1446774 64 razrfalcon 2014-05-08 13:28:48 +0000 KWIN_USE_BUFFER_AGE=0 fix the lag. Thanks. Warning was shown because I start kwin via bash script: #!/bin/bash __GL_YIELD=USLEEP /usr/bin/kwin Because adding __GL_YIELD to /etc/profile does not work for me. And so I have actualy 2 kwin process, actual kwin, and script with same name. 1446795 65 thomas.luebking 2014-05-08 13:48:40 +0000 #!/bin/bash __GL_YIELD=USLEEP /usr/bin/kwin "$@" & there's been a bug in the nvidia driver about reporting the wrong buffer age unless triple buffering, but afaics that should have been fixed (and i can at hand not imagine how that would lead to laggy dragging, rather flicker) You could try whether activating triple buffering "fixes" the issue as well (w/ KWIN_USE_BUFFER_AGE=1) 1446803 66 razrfalcon 2014-05-08 13:58:40 +0000 KWIN_USE_BUFFER_AGE=1 does not fix it, all works like without it Also at startup all works good. Bug start to "work" after 10-20 second after system start. Like they need time to start up... 1446961 67 thomas.luebking 2014-05-08 17:40:13 +0000 It's the default value. What I wanted you to test is WITH enabled buffer_age support and WITH enabled triple buffering: /etc/X11/xorg.conf.d/20-nvidia.conf Section "Device" Identifier "Default nvidia Device" Driver "nvidia" Option "NoLogo" "True" Option "CoolBits" "1" Option "TripleBuffer" "True" # <- that's the relevant line EndSection 1446972 68 razrfalcon 2014-05-08 18:19:45 +0000 Option "TripleBuffer" makes lag smaller, but still much worse than KWIN_USE_BUFFER_AGE=0 1446983 69 thomas.luebking 2014-05-08 19:12:12 +0000 Thanks, ftr. i'm on 337.12 now - 334.x was only used during march on archlinux. I'll have to downgrade now ;-) 1446985 70 michael 2014-05-08 19:13:39 +0000 The lag happens with 337.xx and with triple buffering here. 1812100 71 andrew.crouthamel 2018-11-11 04:31:40 +0000 Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone! 1812338 72 michael 2018-11-11 12:12:46 +0000 This seems to have been fixed at some point, thanks! 85005 2014-02-05 14:55:52 +0000 2014-02-05 14:55:52 +0000 Output of "qdbus org.kde.kwin /KWin supportInformation" KWinsupportInformation.log text/plain 4293 michael S1dpbiBTdXBwb3J0IEluZm9ybWF0aW9uOgpUaGUgZm9sbG93aW5nIGluZm9ybWF0aW9uIHNob3Vs ZCBiZSB1c2VkIHdoZW4gcmVxdWVzdGluZyBzdXBwb3J0IG9uIGUuZy4gaHR0cDovL2ZvcnVtLmtk ZS5vcmcuCkl0IHByb3ZpZGVzIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjdXJyZW50bHkgcnVubmlu ZyBpbnN0YW5jZSwgd2hpY2ggb3B0aW9ucyBhcmUgdXNlZCwKd2hhdCBPcGVuR0wgZHJpdmVyIGFu ZCB3aGljaCBlZmZlY3RzIGFyZSBydW5uaW5nLgpQbGVhc2UgcG9zdCB0aGUgaW5mb3JtYXRpb24g cHJvdmlkZWQgdW5kZXJuZWF0aCB0aGlzIGludHJvZHVjdG9yeSB0ZXh0IHRvIGEgcGFzdGUgYmlu IHNlcnZpY2UKbGlrZSBodHRwOi8vcGFzdGUua2RlLm9yZyBpbnN0ZWFkIG9mIHBhc3RpbmcgaW50 byBzdXBwb3J0IHRocmVhZHMuCgo9PT09PT09PT09PT09PT09PT09PT09PT09PQoKVmVyc2lvbgo9 PT09PT09CktXaW4gdmVyc2lvbjogNC4xMS42CktERSBTQyB2ZXJzaW9uIChydW50aW1lKTogNC4x Mi4yCktERSBTQyB2ZXJzaW9uIChjb21waWxlKTogNC4xMi4yClF0IFZlcnNpb246IDQuOC42CgpP cHRpb25zCj09PT09PT0KZm9jdXNQb2xpY3k6IDAKbmV4dEZvY3VzUHJlZmVyc01vdXNlOiBmYWxz ZQpjbGlja1JhaXNlOiB0cnVlCmF1dG9SYWlzZTogZmFsc2UKYXV0b1JhaXNlSW50ZXJ2YWw6IDAK ZGVsYXlGb2N1c0ludGVydmFsOiAwCnNoYWRlSG92ZXI6IGZhbHNlCnNoYWRlSG92ZXJJbnRlcnZh bDogMjUwCnNlcGFyYXRlU2NyZWVuRm9jdXM6IGZhbHNlCnBsYWNlbWVudDogNApmb2N1c1BvbGlj eUlzUmVhc29uYWJsZTogdHJ1ZQpib3JkZXJTbmFwWm9uZTogMTAKd2luZG93U25hcFpvbmU6IDEw CmNlbnRlclNuYXBab25lOiAwCnNuYXBPbmx5V2hlbk92ZXJsYXBwaW5nOiBmYWxzZQpzaG93RGVz a3RvcElzTWluaW1pemVBbGw6IGZhbHNlCnJvbGxPdmVyRGVza3RvcHM6IHRydWUKZm9jdXNTdGVh bGluZ1ByZXZlbnRpb25MZXZlbDogMQpsZWdhY3lGdWxsc2NyZWVuU3VwcG9ydDogZmFsc2UKb3Bl cmF0aW9uVGl0bGViYXJEYmxDbGljazogCmNvbW1hbmRBY3RpdmVUaXRsZWJhcjE6IDAKY29tbWFu ZEFjdGl2ZVRpdGxlYmFyMjogMzAKY29tbWFuZEFjdGl2ZVRpdGxlYmFyMzogMgpjb21tYW5kSW5h Y3RpdmVUaXRsZWJhcjE6IDQKY29tbWFuZEluYWN0aXZlVGl0bGViYXIyOiAzMApjb21tYW5kSW5h Y3RpdmVUaXRsZWJhcjM6IDIKY29tbWFuZFdpbmRvdzE6IDcKY29tbWFuZFdpbmRvdzI6IDgKY29t bWFuZFdpbmRvdzM6IDgKY29tbWFuZFdpbmRvd1doZWVsOiAzMQpjb21tYW5kQWxsMTogMTAKY29t bWFuZEFsbDI6IDMKY29tbWFuZEFsbDM6IDE0CmtleUNtZEFsbE1vZEtleTogMTY3NzcyNTEKc2hv d0dlb21ldHJ5VGlwOiBmYWxzZQpjb25kZW5zZWRUaXRsZTogZmFsc2UKZWxlY3RyaWNCb3JkZXJN YXhpbWl6ZTogdHJ1ZQplbGVjdHJpY0JvcmRlclRpbGluZzogdHJ1ZQplbGVjdHJpY0JvcmRlckNv cm5lclJhdGlvOiAwLjI1CmJvcmRlcmxlc3NNYXhpbWl6ZWRXaW5kb3dzOiBmYWxzZQpraWxsUGlu Z1RpbWVvdXQ6IDUwMDAKaGlkZVV0aWxpdHlXaW5kb3dzRm9ySW5hY3RpdmU6IHRydWUKaW5hY3Rp dmVUYWJzU2tpcFRhc2tiYXI6IGZhbHNlCmF1dG9ncm91cFNpbWlsYXJXaW5kb3dzOiBmYWxzZQph dXRvZ3JvdXBJbkZvcmVncm91bmQ6IHRydWUKY29tcG9zaXRpbmdNb2RlOiAxCnVzZUNvbXBvc2l0 aW5nOiB0cnVlCmNvbXBvc2l0aW5nSW5pdGlhbGl6ZWQ6IHRydWUKaGlkZGVuUHJldmlld3M6IDEK dW5yZWRpcmVjdEZ1bGxzY3JlZW46IGZhbHNlCmdsU21vb3RoU2NhbGU6IDIKY29sb3JDb3JyZWN0 ZWQ6IGZhbHNlCnhyZW5kZXJTbW9vdGhTY2FsZTogZmFsc2UKbWF4RnBzSW50ZXJ2YWw6IDE2NjY2 NjY2CnJlZnJlc2hSYXRlOiAwCnZCbGFua1RpbWU6IDYwMDAwMDAKZ2xEaXJlY3Q6IHRydWUKZ2xT dHJpY3RCaW5kaW5nOiBmYWxzZQpnbFN0cmljdEJpbmRpbmdGb2xsb3dzRHJpdmVyOiB0cnVlCmds TGVnYWN5OiBmYWxzZQpnbENvcmVQcm9maWxlOiB0cnVlCmdsUHJlZmVyQnVmZmVyU3dhcDogOTkK ClNjcmVlbiBFZGdlcwo9PT09PT09PT09PT0KZGVza3RvcFN3aXRjaGluZzogZmFsc2UKZGVza3Rv cFN3aXRjaGluZ01vdmluZ0NsaWVudHM6IGZhbHNlCmN1cnNvclB1c2hCYWNrRGlzdGFuY2U6IAp0 aW1lVGhyZXNob2xkOiAxNTAKcmVBY3RpdmF0ZVRocmVzaG9sZDogMzUwCmFjdGlvblRvcExlZnQ6 IDAKYWN0aW9uVG9wOiAwCmFjdGlvblRvcFJpZ2h0OiAwCmFjdGlvblJpZ2h0OiAwCmFjdGlvbkJv dHRvbVJpZ2h0OiAwCmFjdGlvbkJvdHRvbTogMAphY3Rpb25Cb3R0b21MZWZ0OiAwCmFjdGlvbkxl ZnQ6IDAKClNjcmVlbnMKPT09PT09PQpNdWx0aS1IZWFkOiBubwpBY3RpdmUgc2NyZWVuIGZvbGxv d3MgbW91c2U6ICBubwpOdW1iZXIgb2YgU2NyZWVuczogMQpTY3JlZW4gMCBHZW9tZXRyeTogMCww LDE5MjB4MTA4MAoKRGVjb3JhdGlvbgo9PT09PT09PT09CkN1cnJlbnQgUGx1Z2luOiBrd2luM19v eHlnZW4KU2hhZG93czogeWVzCkFscGhhOiB5ZXMKQW5ub3VuY2VzIEFscGhhOiB5ZXMKVGFiYmlu ZzogeWVzCkZyYW1lIE92ZXJsYXA6IG5vCkJsdXIgQmVoaW5kOiBubwoKQ29tcG9zaXRpbmcKPT09 PT09PT09PT0KUXQgR3JhcGhpY3MgU3lzdGVtOiByYXN0ZXIKQ29tcG9zaXRpbmcgaXMgYWN0aXZl CkNvbXBvc2l0aW5nIFR5cGU6IE9wZW5HTApPcGVuR0wgdmVuZG9yIHN0cmluZzogTlZJRElBIENv cnBvcmF0aW9uCk9wZW5HTCByZW5kZXJlciBzdHJpbmc6IE5WUyA1NDAwTS9QQ0llL1NTRTIKT3Bl bkdMIHZlcnNpb24gc3RyaW5nOiA0LjQuMCBOVklESUEgMzMxLjM4Ck9wZW5HTCBzaGFkaW5nIGxh bmd1YWdlIHZlcnNpb24gc3RyaW5nOiA0LjQwIE5WSURJQSB2aWEgQ2cgY29tcGlsZXIKRHJpdmVy OiBOVklESUEKRHJpdmVyIHZlcnNpb246IDMzMS4zOApHUFUgY2xhc3M6IFVua25vd24KT3BlbkdM IHZlcnNpb246IDQuNApHTFNMIHZlcnNpb246IDQuNDAKWCBzZXJ2ZXIgdmVyc2lvbjogMS4xNQpM aW51eCBrZXJuZWwgdmVyc2lvbjogMy4xNApEaXJlY3QgcmVuZGVyaW5nOiB5ZXMKUmVxdWlyZXMg c3RyaWN0IGJpbmRpbmc6IG5vCkdMU0wgc2hhZGVyczogIHllcwpUZXh0dXJlIE5QT1Qgc3VwcG9y dDogIHllcwpWaXJ0dWFsIE1hY2hpbmU6ICBubwpPcGVuR0wgMiBTaGFkZXJzIGFyZSB1c2VkClBh aW50aW5nIGJsb2NrcyBmb3IgdmVydGljYWwgcmV0cmFjZTogIG5vCgpMb2FkZWQgRWZmZWN0czoK LS0tLS0tLS0tLS0tLS0tCmt3aW40X2VmZmVjdF9kaW1zY3JlZW4Ka3dpbjRfZWZmZWN0X3NsaWRp bmdwb3B1cHMKa3dpbjRfZWZmZWN0X2xvZ2luCmt3aW40X2VmZmVjdF9taW5pbWl6ZWFuaW1hdGlv bgprd2luNF9lZmZlY3RfY3ViZXNsaWRlCmt3aW40X2VmZmVjdF9zY3JlZW5zaG90Cmt3aW40X2Vm ZmVjdF9tYXhpbWl6ZQprd2luNF9lZmZlY3RfZmFkZQprd2luNF9lZmZlY3RfdGFza2JhcnRodW1i bmFpbAprd2luNF9lZmZlY3RfZGlhbG9ncGFyZW50Cmt3aW40X2VmZmVjdF9ibHVyCmt3aW40X2Vm ZmVjdF9sb2dvdXQKa3dpbjRfZWZmZWN0X2Rhc2hib2FyZAprd2luNF9lZmZlY3Rfa3NjcmVlbgoK Q3VycmVudGx5IEFjdGl2ZSBFZmZlY3RzOgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCmt3aW40 X2VmZmVjdF9ibHVyCgpFZmZlY3QgU2V0dGluZ3M6Ci0tLS0tLS0tLS0tLS0tLS0Ka3dpbjRfZWZm ZWN0X2RpbXNjcmVlbjoKCmt3aW40X2VmZmVjdF9zbGlkaW5ncG9wdXBzOgpmYWRlSW5UaW1lOiAy NTAKZmFkZU91dFRpbWU6IDI1MAoKa3dpbjRfZWZmZWN0X2xvZ2luOgoKa3dpbjRfZWZmZWN0X21p bmltaXplYW5pbWF0aW9uOgoKa3dpbjRfZWZmZWN0X2N1YmVzbGlkZToKcm90YXRpb25EdXJhdGlv bjogNTAwCmRvbnRTbGlkZVBhbmVsczogdHJ1ZQpkb250U2xpZGVTdGlja3lXaW5kb3dzOiBmYWxz ZQp1c2VQYWdlckxheW91dDogdHJ1ZQp1c2VXaW5kb3dNb3Zpbmc6IGZhbHNlCgprd2luNF9lZmZl Y3Rfc2NyZWVuc2hvdDoKCmt3aW40X2VmZmVjdF9tYXhpbWl6ZToKCmt3aW40X2VmZmVjdF9mYWRl OgoKa3dpbjRfZWZmZWN0X3Rhc2tiYXJ0aHVtYm5haWw6Cgprd2luNF9lZmZlY3RfZGlhbG9ncGFy ZW50OgoKa3dpbjRfZWZmZWN0X2JsdXI6CmJsdXJSYWRpdXM6IDcKY2FjaGVUZXh0dXJlOiBmYWxz ZQoKa3dpbjRfZWZmZWN0X2xvZ291dDoKdXNlQmx1cjogdHJ1ZQoKa3dpbjRfZWZmZWN0X2Rhc2hi b2FyZDoKYnJpZ2h0bmVzczogMC41CnNhdHVyYXRpb246IDAuNQpibHVyOiBmYWxzZQoKa3dpbjRf ZWZmZWN0X2tzY3JlZW46CgoK 85010 2014-02-05 18:54:53 +0000 2014-02-05 18:54:53 +0000 Qdbus output qdbus application/octet-stream 5506 obuolis1 S1dpbiBTdXBwb3J0IEluZm9ybWF0aW9uOgpUaGUgZm9sbG93aW5nIGluZm9ybWF0aW9uIHNob3Vs ZCBiZSB1c2VkIHdoZW4gcmVxdWVzdGluZyBzdXBwb3J0IG9uIGUuZy4gaHR0cDovL2ZvcnVtLmtk ZS5vcmcuCkl0IHByb3ZpZGVzIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjdXJyZW50bHkgcnVubmlu ZyBpbnN0YW5jZSwgd2hpY2ggb3B0aW9ucyBhcmUgdXNlZCwKd2hhdCBPcGVuR0wgZHJpdmVyIGFu ZCB3aGljaCBlZmZlY3RzIGFyZSBydW5uaW5nLgpQbGVhc2UgcG9zdCB0aGUgaW5mb3JtYXRpb24g cHJvdmlkZWQgdW5kZXJuZWF0aCB0aGlzIGludHJvZHVjdG9yeSB0ZXh0IHRvIGEgcGFzdGUgYmlu IHNlcnZpY2UKbGlrZSBodHRwOi8vcGFzdGUua2RlLm9yZyBpbnN0ZWFkIG9mIHBhc3RpbmcgaW50 byBzdXBwb3J0IHRocmVhZHMuCgo9PT09PT09PT09PT09PT09PT09PT09PT09PQoKVmVyc2lvbgo9 PT09PT09CktXaW4gdmVyc2lvbjogNC4xMS42CktERSBTQyB2ZXJzaW9uIChydW50aW1lKTogNC4x Mi4xCktERSBTQyB2ZXJzaW9uIChjb21waWxlKTogNC4xMi4xClF0IFZlcnNpb246IDQuOC41CgpP cHRpb25zCj09PT09PT0KZm9jdXNQb2xpY3k6IDAKbmV4dEZvY3VzUHJlZmVyc01vdXNlOiBmYWxz ZQpjbGlja1JhaXNlOiB0cnVlCmF1dG9SYWlzZTogZmFsc2UKYXV0b1JhaXNlSW50ZXJ2YWw6IDAK ZGVsYXlGb2N1c0ludGVydmFsOiAwCnNoYWRlSG92ZXI6IGZhbHNlCnNoYWRlSG92ZXJJbnRlcnZh bDogMjUwCnNlcGFyYXRlU2NyZWVuRm9jdXM6IGZhbHNlCnBsYWNlbWVudDogNApmb2N1c1BvbGlj eUlzUmVhc29uYWJsZTogdHJ1ZQpib3JkZXJTbmFwWm9uZTogMTAKd2luZG93U25hcFpvbmU6IDEw CmNlbnRlclNuYXBab25lOiAwCnNuYXBPbmx5V2hlbk92ZXJsYXBwaW5nOiBmYWxzZQpzaG93RGVz a3RvcElzTWluaW1pemVBbGw6IGZhbHNlCnJvbGxPdmVyRGVza3RvcHM6IHRydWUKZm9jdXNTdGVh bGluZ1ByZXZlbnRpb25MZXZlbDogMQpsZWdhY3lGdWxsc2NyZWVuU3VwcG9ydDogZmFsc2UKb3Bl cmF0aW9uVGl0bGViYXJEYmxDbGljazogCmNvbW1hbmRBY3RpdmVUaXRsZWJhcjE6IDAKY29tbWFu ZEFjdGl2ZVRpdGxlYmFyMjogMzAKY29tbWFuZEFjdGl2ZVRpdGxlYmFyMzogMgpjb21tYW5kSW5h Y3RpdmVUaXRsZWJhcjE6IDQKY29tbWFuZEluYWN0aXZlVGl0bGViYXIyOiAzMApjb21tYW5kSW5h Y3RpdmVUaXRsZWJhcjM6IDIKY29tbWFuZFdpbmRvdzE6IDcKY29tbWFuZFdpbmRvdzI6IDgKY29t bWFuZFdpbmRvdzM6IDgKY29tbWFuZFdpbmRvd1doZWVsOiAzMQpjb21tYW5kQWxsMTogMTAKY29t bWFuZEFsbDI6IDMKY29tbWFuZEFsbDM6IDE0CmtleUNtZEFsbE1vZEtleTogMTY3NzcyNTEKc2hv d0dlb21ldHJ5VGlwOiBmYWxzZQpjb25kZW5zZWRUaXRsZTogZmFsc2UKZWxlY3RyaWNCb3JkZXJN YXhpbWl6ZTogdHJ1ZQplbGVjdHJpY0JvcmRlclRpbGluZzogZmFsc2UKZWxlY3RyaWNCb3JkZXJD b3JuZXJSYXRpbzogMC4yNQpib3JkZXJsZXNzTWF4aW1pemVkV2luZG93czogZmFsc2UKa2lsbFBp bmdUaW1lb3V0OiA1MDAwCmhpZGVVdGlsaXR5V2luZG93c0ZvckluYWN0aXZlOiB0cnVlCmluYWN0 aXZlVGFic1NraXBUYXNrYmFyOiBmYWxzZQphdXRvZ3JvdXBTaW1pbGFyV2luZG93czogZmFsc2UK YXV0b2dyb3VwSW5Gb3JlZ3JvdW5kOiB0cnVlCmNvbXBvc2l0aW5nTW9kZTogMQp1c2VDb21wb3Np dGluZzogdHJ1ZQpjb21wb3NpdGluZ0luaXRpYWxpemVkOiB0cnVlCmhpZGRlblByZXZpZXdzOiAx CnVucmVkaXJlY3RGdWxsc2NyZWVuOiB0cnVlCmdsU21vb3RoU2NhbGU6IDIKY29sb3JDb3JyZWN0 ZWQ6IGZhbHNlCnhyZW5kZXJTbW9vdGhTY2FsZTogZmFsc2UKbWF4RnBzSW50ZXJ2YWw6IDE2NjY2 NjY2CnJlZnJlc2hSYXRlOiAwCnZCbGFua1RpbWU6IDYwMDAwMDAKZ2xEaXJlY3Q6IHRydWUKZ2xT dHJpY3RCaW5kaW5nOiBmYWxzZQpnbFN0cmljdEJpbmRpbmdGb2xsb3dzRHJpdmVyOiB0cnVlCmds TGVnYWN5OiBmYWxzZQpnbENvcmVQcm9maWxlOiBmYWxzZQpnbFByZWZlckJ1ZmZlclN3YXA6IDk5 CgpTY3JlZW4gRWRnZXMKPT09PT09PT09PT09CmRlc2t0b3BTd2l0Y2hpbmc6IGZhbHNlCmRlc2t0 b3BTd2l0Y2hpbmdNb3ZpbmdDbGllbnRzOiBmYWxzZQpjdXJzb3JQdXNoQmFja0Rpc3RhbmNlOiAK dGltZVRocmVzaG9sZDogMTUwCnJlQWN0aXZhdGVUaHJlc2hvbGQ6IDM1MAphY3Rpb25Ub3BMZWZ0 OiAwCmFjdGlvblRvcDogMAphY3Rpb25Ub3BSaWdodDogMAphY3Rpb25SaWdodDogMAphY3Rpb25C b3R0b21SaWdodDogMAphY3Rpb25Cb3R0b206IDAKYWN0aW9uQm90dG9tTGVmdDogMAphY3Rpb25M ZWZ0OiAwCgpTY3JlZW5zCj09PT09PT0KTXVsdGktSGVhZDogbm8KQWN0aXZlIHNjcmVlbiBmb2xs b3dzIG1vdXNlOiAgbm8KTnVtYmVyIG9mIFNjcmVlbnM6IDEKU2NyZWVuIDAgR2VvbWV0cnk6IDAs MCwxMjgweDEwMjQKCkRlY29yYXRpb24KPT09PT09PT09PQpDdXJyZW50IFBsdWdpbjoga3dpbjNf b3h5Z2VuClNoYWRvd3M6IHllcwpBbHBoYTogeWVzCkFubm91bmNlcyBBbHBoYTogeWVzClRhYmJp bmc6IHllcwpGcmFtZSBPdmVybGFwOiBubwpCbHVyIEJlaGluZDogbm8KCkNvbXBvc2l0aW5nCj09 PT09PT09PT09ClF0IEdyYXBoaWNzIFN5c3RlbTogcmFzdGVyCkNvbXBvc2l0aW5nIGlzIGFjdGl2 ZQpDb21wb3NpdGluZyBUeXBlOiBPcGVuR0wKT3BlbkdMIHZlbmRvciBzdHJpbmc6IE5WSURJQSBD b3Jwb3JhdGlvbgpPcGVuR0wgcmVuZGVyZXIgc3RyaW5nOiBHZUZvcmNlIDk1MDAgR1QvUENJZS9T U0UyLzNETk9XIQpPcGVuR0wgdmVyc2lvbiBzdHJpbmc6IDMuMy4wIE5WSURJQSAzMzEuMzgKT3Bl bkdMIHNoYWRpbmcgbGFuZ3VhZ2UgdmVyc2lvbiBzdHJpbmc6IDMuMzAgTlZJRElBIHZpYSBDZyBj b21waWxlcgpEcml2ZXI6IE5WSURJQQpEcml2ZXIgdmVyc2lvbjogMzMxLjM4CkdQVSBjbGFzczog RzgwL0c5MApPcGVuR0wgdmVyc2lvbjogMy4zCkdMU0wgdmVyc2lvbjogMy4zMApYIHNlcnZlciB2 ZXJzaW9uOiAxLjE1CkxpbnV4IGtlcm5lbCB2ZXJzaW9uOiAzLjEyLjkKRGlyZWN0IHJlbmRlcmlu ZzogeWVzClJlcXVpcmVzIHN0cmljdCBiaW5kaW5nOiBubwpHTFNMIHNoYWRlcnM6ICB5ZXMKVGV4 dHVyZSBOUE9UIHN1cHBvcnQ6ICB5ZXMKVmlydHVhbCBNYWNoaW5lOiAgbm8KT3BlbkdMIDIgU2hh ZGVycyBhcmUgdXNlZApQYWludGluZyBibG9ja3MgZm9yIHZlcnRpY2FsIHJldHJhY2U6ICB5ZXMK CkxvYWRlZCBFZmZlY3RzOgotLS0tLS0tLS0tLS0tLS0Ka3dpbjRfZWZmZWN0X3pvb20Ka3dpbjRf ZWZmZWN0X3NsaWRpbmdwb3B1cHMKa3dpbjRfZWZmZWN0X2xvZ2luCmt3aW40X2VmZmVjdF9jb3Zl cnN3aXRjaAprd2luNF9lZmZlY3RfY3ViZXNsaWRlCmt3aW40X2VmZmVjdF9zY3JlZW5zaG90Cmt3 aW40X2VmZmVjdF9kZXNrdG9wZ3JpZAprd2luNF9lZmZlY3RfZmxpcHN3aXRjaAprd2luNF9lZmZl Y3RfdHJhbnNsdWNlbmN5Cmt3aW40X2VmZmVjdF9tYWdpY2xhbXAKa3dpbjRfZWZmZWN0X21heGlt aXplCmt3aW40X2VmZmVjdF9mYWRlCmt3aW40X2VmZmVjdF9oaWdobGlnaHR3aW5kb3cKa3dpbjRf ZWZmZWN0X3Rhc2tiYXJ0aHVtYm5haWwKa3dpbjRfZWZmZWN0X2RpYWxvZ3BhcmVudAprd2luNF9l ZmZlY3RfcHJlc2VudHdpbmRvd3MKa3dpbjRfZWZmZWN0X2xvZ291dAprd2luNF9lZmZlY3RfZGFz aGJvYXJkCmt3aW40X2VmZmVjdF9zY3JlZW5lZGdlCmt3aW40X2VmZmVjdF9zdGFydHVwZmVlZGJh Y2sKa3dpbjRfZWZmZWN0X2tzY3JlZW4KCkN1cnJlbnRseSBBY3RpdmUgRWZmZWN0czoKLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQoKRWZmZWN0IFNldHRpbmdzOgotLS0tLS0tLS0tLS0tLS0tCmt3 aW40X2VmZmVjdF96b29tOgp6b29tRmFjdG9yOiAxLjIKbW91c2VQb2ludGVyOiAwCm1vdXNlVHJh Y2tpbmc6IDAKZW5hYmxlRm9jdXNUcmFja2luZzogZmFsc2UKZm9sbG93Rm9jdXM6IHRydWUKZm9j dXNEZWxheTogMzUwCm1vdmVGYWN0b3I6IDIwCnRhcmdldFpvb206IDEKCmt3aW40X2VmZmVjdF9z bGlkaW5ncG9wdXBzOgpmYWRlSW5UaW1lOiAxMjUKZmFkZU91dFRpbWU6IDEyNQoKa3dpbjRfZWZm ZWN0X2xvZ2luOgoKa3dpbjRfZWZmZWN0X2NvdmVyc3dpdGNoOgphbmltYXRpb25EdXJhdGlvbjog MTAwCmFuaW1hdGVTd2l0Y2g6IHRydWUKYW5pbWF0ZVN0YXJ0OiB0cnVlCmFuaW1hdGVTdG9wOiB0 cnVlCnJlZmxlY3Rpb246IHRydWUKd2luZG93VGl0bGU6IHRydWUKelBvc2l0aW9uOiA5MDAKcHJp bWFyeVRhYkJveDogZmFsc2UKc2Vjb25kYXJ5VGFiQm94OiBmYWxzZQoKa3dpbjRfZWZmZWN0X2N1 YmVzbGlkZToKcm90YXRpb25EdXJhdGlvbjogMjUwCmRvbnRTbGlkZVBhbmVsczogdHJ1ZQpkb250 U2xpZGVTdGlja3lXaW5kb3dzOiBmYWxzZQp1c2VQYWdlckxheW91dDogdHJ1ZQp1c2VXaW5kb3dN b3Zpbmc6IGZhbHNlCgprd2luNF9lZmZlY3Rfc2NyZWVuc2hvdDoKCmt3aW40X2VmZmVjdF9kZXNr dG9wZ3JpZDoKem9vbUR1cmF0aW9uOiAxNTAKYm9yZGVyOiAxMApkZXNrdG9wTmFtZUFsaWdubWVu dDogMApsYXlvdXRNb2RlOiAwCmN1c3RvbUxheW91dFJvd3M6IDIKdXNlUHJlc2VudFdpbmRvd3M6 IHRydWUKCmt3aW40X2VmZmVjdF9mbGlwc3dpdGNoOgp0YWJCb3g6IGZhbHNlCnRhYkJveEFsdGVy bmF0aXZlOiBmYWxzZQpkdXJhdGlvbjogMTAwCmFuZ2xlOiAzMAp4UG9zaXRpb246IDAuMzMwMDAw MDEzMTEzMDIyCnlQb3NpdGlvbjogMQp3aW5kb3dUaXRsZTogdHJ1ZQoKa3dpbjRfZWZmZWN0X3Ry YW5zbHVjZW5jeToKCmt3aW40X2VmZmVjdF9tYWdpY2xhbXA6CmFuaW1hdGlvbkR1cmF0aW9uOiAx MjUKCmt3aW40X2VmZmVjdF9tYXhpbWl6ZToKCmt3aW40X2VmZmVjdF9mYWRlOgoKa3dpbjRfZWZm ZWN0X2hpZ2hsaWdodHdpbmRvdzoKCmt3aW40X2VmZmVjdF90YXNrYmFydGh1bWJuYWlsOgoKa3dp bjRfZWZmZWN0X2RpYWxvZ3BhcmVudDoKCmt3aW40X2VmZmVjdF9wcmVzZW50d2luZG93czoKbGF5 b3V0TW9kZTogMApzaG93Q2FwdGlvbnM6IHRydWUKc2hvd0ljb25zOiB0cnVlCmRvTm90Q2xvc2VX aW5kb3dzOiBmYWxzZQppZ25vcmVNaW5pbWl6ZWQ6IGZhbHNlCmFjY3VyYWN5OiAyMApmaWxsR2Fw czogdHJ1ZQpmYWRlRHVyYXRpb246IDc1CnNob3dQYW5lbDogZmFsc2UKbGVmdEJ1dHRvbldpbmRv dzogMQpyaWdodEJ1dHRvbldpbmRvdzogMgptaWRkbGVCdXR0b25XaW5kb3c6IDAKbGVmdEJ1dHRv bkRlc2t0b3A6IDIKbWlkZGxlQnV0dG9uRGVza3RvcDogMApyaWdodEJ1dHRvbkRlc2t0b3A6IDAK ZHJhZ1RvQ2xvc2U6IGZhbHNlCgprd2luNF9lZmZlY3RfbG9nb3V0Ogp1c2VCbHVyOiB0cnVlCgpr d2luNF9lZmZlY3RfZGFzaGJvYXJkOgpicmlnaHRuZXNzOiAwLjUKc2F0dXJhdGlvbjogMC41CmJs dXI6IGZhbHNlCgprd2luNF9lZmZlY3Rfc2NyZWVuZWRnZToKCmt3aW40X2VmZmVjdF9zdGFydHVw ZmVlZGJhY2s6Cgprd2luNF9lZmZlY3Rfa3NjcmVlbjoKCg==