313061 2013-01-11 10:00:46 +0000 "Login" effect does not fade in on secondary monitor(s) with a multi screen setup 2013-03-04 09:31:20 +0000 1 1 4 Plasma kwin effects-various 4.9.4 Ubuntu Linux RESOLVED FIXED https://git.reviewboard.kde.org/r/108362/ NOR normal 4.11 1 corrado.mella kwin-bugs-null http://commits.kde.org/kde-workspace/118b841835cdc5c60686abc3766a432323440266 4.11 0 oldest_to_newest 1330980 0 corrado.mella 2013-01-11 10:00:46 +0000 The "Login" fade-in effect works only on primary monitor. All other monitors switch instantly. Setting the effect to "fade through black" makes secondary screens briefly flicker to black (fractions of a second). Reproducible: Always Steps to Reproduce: 1. Enable "Login" effect 2. Next login, watch screens behave differently... Actual Results: The secondary screen snaps to the desktop, while the primary screen nicely fades in (or fades through black). Expected Results: All screens should fade [to desktop|through black]. Latest stable NVidia closed source drivers, but used "noveau" with same result. Kubuntu 12.10 fully updated. Happens on another machine with Kubuntu 12.04 LTS, latest nVidia closed source drivers. Can't say what KDE SC version runs on that machine at the moment, but it's the most up to date for the distro. 1330992 1 mgraesslin 2013-01-11 10:38:53 +0000 please clarify what "multihead" setup means to you. One X Server per screen? 1331007 2 corrado.mella 2013-01-11 11:37:04 +0000 Multihead, as NOT Xinerama but TwinView. No, one single X server, stretched onto two screens. "NVIDIA X Server Settings" reports this: System Information Operating System: Linux-x86 NVIDIA Driver Version: 304.51 X Server Information Display Name: Atlantis:0 Server Version Number: 11.0 Server Version String: The X.Org Foundation Server Vendor Version: 1.13.0 (11300000) NV-CONTROL Version: 1.28 Screens: 1 X Screen Information Screen Number: 0 Display Name: Atlantis:0.0 Dimensions: 1440x1669 pixels (420x487 millimeters) Resolution: 87x87 dots per inch Depth: 24 GPUs: GeForce 8400GS (GPU0) Displays: LG Electronics L194WT (DFP-0), Acer P195HQL (CRT-1) Recovered GPU Errors: 0 Stereo Mode: Unknown 1331008 3 mgraesslin 2013-01-11 11:41:41 +0000 this is called "multi screen". So I have to answer: works on my system, though I use XRandR. 1331016 4 corrado.mella 2013-01-11 12:02:53 +0000 The keyword "multihead" is from the list of keywords in the "components" selection for the bug. I've used it to widen the remit of the bug and seek a wider audience. I'm glad it works for you, although it is totally irrelevant. It doesn't work on THREE systems here: - one Intel Centrino laptop using XRandR on 12.04 - a desktop using XRandR and an nVidia card - another desktop NOT using XRandR and an nVidia card. The "logout" plugin works, fading and blurring both screens on all three. Different setups, different KDE versions, different OS distros, different video drivers / versions, different use of XRandR, same result from the plugin. What does this tell us? 1331018 5 corrado.mella 2013-01-11 12:05:50 +0000 Sorry, forgot: Desktop #1 is on Kubuntu 12.04 LTS, desktop #2 is on Kubuntu 12.10. All them up to date with all repos enabled (up to -proposed). 1331056 6 thomas.luebking 2013-01-11 13:23:39 +0000 (In reply to comment #4) > What does this tell us? Insufficient data input :-P How many screens are active during the login screen? (If the screen size is adjusted during the login, that'd be a problem) Also please attach the output of "qdbus org.kde.KWin /KWin supportInformation" 1331144 7 76394 corrado.mella 2013-01-11 17:09:05 +0000 Created attachment 76394 qdbus output As requested 1331151 8 corrado.mella 2013-01-11 17:48:06 +0000 Login screen spans both monitors. A bit of background: My dual monitor setup is "vertical", as in: monitors are one on top of the other, primary on bottom, secondary on top. Primary is a DVI, secondary is a VGA. Resolution on primary is 1440x900, on secondary is 1366x768. Secondary screen is at Absolute 37,0 and primary is at Absolute 0,769. This makes the top screen centred over the bottom. Primary output is the DVI monitor at the bottom. These are the settings from the "Size and Orientation" section of the "Display and Monitor" app on "System Settings". Apparently the KDM login screen is in "horizontal" instead, because: - the login interface appears on the bottom screen; - the mouse cursor sits at the far right of the bottom screen; - if I move the mouse cursor on the far right of the bottom screen, it pops up at the far left of the top screen and the login interface moves to the top screen; - if I move it back to the left on the top screen, it reappears on the far right of the bottom screen and the login interface moves to the bottom screen. I suppose KDM is assuming that the two monitors are one beside each other, and doesn't read the system settings. BUT. The same problem with the login plugin happens even if I set the monitors on the System Settings to be identical to those that KDM erroneously uses, side-by-side / horizontal. The primary monitor correctly and beautifully fades between the splash screen and the desktop (in my case transitioning through black), the secondary flicks instantly from the splash screen to the desktop (with a brief, almost imperceptible black flick between the two if the "fade to black" is enabled). I'm using the standard stock KDM login screen and the standard splash screen. You are focussing on this specific machine setup, but - as I already said - I can see the same behaviour on two other different systems. My closing question was rhetorical, pointing out that the only commonality between the three systems was the "login" desktop effects plugin... o_O And that's where the bug lies, to the best of my logical analytical skills. Look, I'm 49. I don't code anymore, but have been coding since I was 15. I coded in Fortran, Pascal, COBOL, Basic, Visual Basic, C, C++ C#, ASM86, Java, JavaScript, Perl, PHP, Python... better stop there before it get ridiculous. Focus. How can I help? I'll try to login without a splash screen, and to log in to a KWin desktop with the same geometry as the kdm login screen, but I suspect it won't make a difference. However - as I didn't do anything to "break" the system rather than setting up the screens to my requirements, and everything else is as out of the box - changing screen / resolution after login is not an unexpected or uncommon condition, and if this is a problem for the plugin this is a bug that must be addressed. Happy to help. 1331242 9 thomas.luebking 2013-01-11 22:04:43 +0000 (In reply to comment #8) > I suppose KDM is assuming that the two monitors are one beside each other, and doesn't read the system settings. Whatever you setup inside the session in krandr is actually part of the session (otherwise you'd have to pass a root password in order to change anything) You can either control the initial screen layout via xorg.conf or by the init scripts interpreted by KDM, eg. /usr/share/config/kdm/Xsetup > The same problem with the login plugin happens even if I set the monitors on > the System Settings to be identical to those that KDM erroneously uses, > side-by-side / horizontal. ACK. > I'm using the standard stock KDM login screen and the standard splash screen. Does the splash screen cover both screens? > You are focussing on this specific machine setup No, i'm focussing on "what is it where you observe this", because that is the relevant aspect. > I can see the same behaviour on two other different systems. You didn't say *anything* about the multiscreen setup. Whether the bug happens on kubuntu 12.10 or 12.04 is actually less relevant than that it's ubuntu (which has special xrandr problems anyway, see https://bugs.kde.org/show_bug.cgi?id=xrr-ubuntu) and > - another desktop NOT using XRandR and an nVidia card. is extra-special because it's either TwinView (equals xrandr since the 300.xxx drivers), Xinerama (kinda unsupported but interesting detail if it happened on xinerama as well as on xrandr multiscreen setups) or an actual dualhead (which would actually open a can of worms, several issues with mutihead setups are known) > My closing question was ... not providing any further information. > And that's where the bug lies, to the best of my logical analytical skills. - Is any of the three systems *not* ubuntu? - does the intel system run OpenGL 2 as well? - is is always the same panels (important mostly if one's actually a Tv) I tested - Backends: * xrender * opengl 1 * opengl 2 - On an nvidia system, archlinux, kwin is current git master - Common Dualscreen on DVI/VGA combo - regular side-by-side - centered on top (vga above dvi) KDM is only on the primary screen, but krandr kicks in before ksplash, so the splash screen already occurs on the adjusted setup, there're no further changes, esp. not after kwin starts. I can confirm Martins observation that the effect operates exactly as expected on both panels. Now let's see about your actual logical skills: a) you lie b) martin & me both lie c) it's a local problem d) it's a local solution I can scratch second half of (b) (and don't believe in the first at all, but that does no more matter) so if you can scratch (a) we remain with (c) and (d) Last notable change to the effect has been Thu Jul 12 17:20:17 This should be enough information for you to figure the next test to narrow the problem. If not, feel free to call back. 1331299 10 corrado.mella 2013-01-12 01:19:19 +0000 > > The same problem with the login plugin happens even if I set the monitors on > > the System Settings to be identical to those that KDM erroneously uses, > > side-by-side / horizontal. > ACK. Just a dry ACK? What a way to investigate there... > > I'm using the standard stock KDM login screen and the standard splash screen. > Does the splash screen cover both screens? Two independent splash screens on the monitors, going in perfect sync (the motif does not span or stretch, it repeats). > > You are focussing on this specific machine setup > No, i'm focussing on "what is it where you observe this", because that is > the relevant aspect. No, THE SAME BEHAVIOUR happens on three different machines, with different hardware, different Kubuntu Distro, but similar or identical set-up. > > I can see the same behaviour on two other different systems. > You didn't say *anything* about the multiscreen setup. Yes I did. Read again all my posts. - 1 Desktop PC, nVidia with closed source drivers on Kubuntu 12.10, 1 x DVI + 1 x VGA, top/bottom setup through System Settings - not the NVIDIA Control Panel; - 1 Desktop PC, Nvidia with closed source drivers on Kubuntu 12.04 LTS, 2x DVI, side-by-side / horizontal setup, no special setup on System Settings, as per stock install / standard detection; - 1 Laptop PC, Intel with stock drivers on Kubuntu 12.04 LTS, 1 x DVI (inbuilt screen) + 1 x VGA, special handcrafted xrandr call on Xinit to get the two screens working in vertical setup - System settings couldn't do it for the grace of God. *SAME* behaviour from the plugin - on very different systems and setups. > > My closing question was > ... not providing any further information. And here you start getting cheeky. Young man, I'm not a kid, show respect. > > And that's where the bug lies, to the best of my logical analytical skills. > - Is any of the three systems *not* ubuntu? No > - does the intel system run OpenGL 2 as well? No, the OpenGL2 shaders are broken on Intel GPUs - you should know that. > - is is always the same panels (important mostly if one's actually a Tv) Yes, always the secondary, and NO, they're either true VGA or DVI screens. > I tested > - Backends: > * xrender > * opengl 1 > * opengl 2 > - On an nvidia system, archlinux, kwin is current git master > - Common Dualscreen on DVI/VGA combo > - regular side-by-side > - centered on top (vga above dvi) And here is the difference: your test system is using a marginal minimalistic distro, KDE SC from github, while all three my systems use the massively deployed (k)ubuntu, with latest stable KDE from the -proposed repo. It really does not matter if your plugin works for you on your system, it must work on all distros to be ready for prime time. If you want Linux to be a system that can be deployed on everybody's desktops you need to change attitude, not calling bug reporters liars or incompetent, get your head out of the sand and test, test, test. > KDM is only on the primary screen, but krandr kicks in before ksplash, so > the splash screen already occurs on the adjusted setup, there're no further > changes, esp. not after kwin starts. If k/xrandr kicks in before ksplash, why the splash screen is not stretched all along the full X screen (1440x1669), but repeated on both monitors? > I can confirm Martins observation that the effect operates exactly as > expected on both panels. And you accept his report without asking anything about HIS system, but you question mine? What an attitude, lad. > Now let's see about your actual logical skills: > > a) you lie Don't you even dare repeating this. Ever. > b) martin & me both lie Not a lie, but a refusal of the inconvenient truth. > c) it's a local problem > d) it's a local solution None of the four, it's POSSIBLY a downstream problem, specific to (k)ubuntu, but being that distro the largest deployed linux distro using KDE, it's the reference point for mass production, and you need to ensure your app works there. > I can scratch second half of (b) (and don't believe in the first at all, but > that does no more matter) so if you can scratch (a) we remain with (c) and > (d) Your analytical skills still stop between the boundary of your little walled garden. "Can't reproduce here, bug does not exist, it's a local problem." Test on a stock Kubuntu 12.10 and then come back here and say "works as intended". It's a minor, non-blocking cosmetic bug, and I've lost hours of my very expensive time trying to help you solve it with all the input you requested. If you still maintain the problem does not exist, it's fine by me. I can live with that. But don't pretend OSS can be taken seriously. Mass deployment of an app requires an effort three orders of magnitude larger that those you invested here. > This should be enough information for you to figure the next test to narrow > the problem. Idem for you to fix the problem or to find a workaround. Close the bug report, I'm not going further. You know what? I'm disabling the plugin... Over and out. 1331329 11 mgraesslin 2013-01-12 07:47:22 +0000 (In reply to comment #10) > It really does not matter if your plugin works for you on your system, it > must work on all distros to be ready for prime time. If you want Linux to be > a system that can be deployed on everybody's desktops you need to change > attitude, not calling bug reporters liars or incompetent, get your head out > of the sand and test, test, test. Actually it does matter. If it works on my and Thomas's system we have a hard time investigating the issue and by that a problem with fixing the issue. Also at the current point in time we don't care anymore for what is shipped in the distros. It's outdated from our point of view. There won't be another 4.9 version, so it only matters how the code in master looks like. Btw. attitude on the user's side doesn't help. @Thomas: I just had a look into the effect and it assumes there is only one login_window. That probably doesn't work if there is more than one login splash window. @Corrado: which login splash are you using? 1331331 12 mgraesslin 2013-01-12 07:58:31 +0000 ok, with ksplashqml there is one window per screen and that doesn't work. for testing: ksplashqml Minimalistic --test 1347525 13 mgraesslin 2013-03-04 09:31:20 +0000 Git commit 118b841835cdc5c60686abc3766a432323440266 by Martin Gräßlin. Committed on 14/01/2013 at 08:38. Pushed by graesslin into branch 'master'. Rewrite of Login effect to JavaScript Main motivation for this rewrite is the fact that the login effect had been designed under the assumption that there is only one login splash window. This assumption does no longer hold with the QML based splash, which creates a window per screen. By using a JavaScript based effect, the animation effect is implicityly used which supports animating multiple windows at the same time in a better and safer way. FIXED-IN: 4.11 REVIEW: 108403 M +1 -1 kwin/effects/CMakeLists.txt M +0 -2 kwin/effects/configs_builtins.cpp M +1 -30 kwin/effects/login/CMakeLists.txt D +0 -129 kwin/effects/login/login.cpp D +0 -60 kwin/effects/login/login.h D +0 -64 kwin/effects/login/login_config.cpp D +0 -94 kwin/effects/login/login_config.desktop D +0 -55 kwin/effects/login/login_config.h D +0 -5 kwin/effects/login/loginconfig.kcfgc A +6 -0 kwin/effects/login/package/CMakeLists.txt A +94 -0 kwin/effects/login/package/contents/code/main.js R +2 -2 kwin/effects/login/package/contents/config/main.xml [from: kwin/effects/login/login.kcfg - 086% similarity] R +0 -0 kwin/effects/login/package/contents/ui/config.ui [from: kwin/effects/login/login_config.ui - 100% similarity] R +10 -6 kwin/effects/login/package/metadata.desktop [from: kwin/effects/login/login.desktop - 094% similarity] http://commits.kde.org/kde-workspace/118b841835cdc5c60686abc3766a432323440266 76394 2013-01-11 17:09:05 +0000 2013-01-11 17:09:05 +0000 qdbus output qdbus output.txt text/plain 4486 corrado.mella Y29ycmFkb0BBdGxhbnRpczp+JCBxZGJ1cyBvcmcua2RlLmt3aW4gL0tXaW4gc3VwcG9ydEluZm9y bWF0aW9uCktXaW4gU3VwcG9ydCBJbmZvcm1hdGlvbjoKVGhlIGZvbGxvd2luZyBpbmZvcm1hdGlv biBzaG91bGQgYmUgdXNlZCB3aGVuIHJlcXVlc3Rpbmcgc3VwcG9ydCBvbiBlLmcuIGh0dHA6Ly9m b3J1bS5rZGUub3JnLgpJdCBwcm92aWRlcyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY3VycmVudGx5 IHJ1bm5pbmcgaW5zdGFuY2UsIHdoaWNoIG9wdGlvbnMgYXJlIHVzZWQsCndoYXQgT3BlbkdMIGRy aXZlciBhbmQgd2hpY2ggZWZmZWN0cyBhcmUgcnVubmluZy4KUGxlYXNlIHBvc3QgdGhlIGluZm9y bWF0aW9uIHByb3ZpZGVkIHVuZGVybmVhdGggdGhpcyBpbnRyb2R1Y3RvcnkgdGV4dCB0byBhIHBh c3RlIGJpbiBzZXJ2aWNlCmxpa2UgaHR0cDovL3Bhc3RlLmtkZS5vcmcgaW5zdGVhZCBvZiBwYXN0 aW5nIGludG8gc3VwcG9ydCB0aHJlYWRzLgoKPT09PT09PT09PT09PT09PT09PT09PT09PT0KCk9w dGlvbnMKPT09PT09PQpmb2N1c1BvbGljeTogMApuZXh0Rm9jdXNQcmVmZXJzTW91c2U6IGZhbHNl CmNsaWNrUmFpc2U6IHRydWUKYXV0b1JhaXNlOiBmYWxzZQphdXRvUmFpc2VJbnRlcnZhbDogMApk ZWxheUZvY3VzSW50ZXJ2YWw6IDAKc2hhZGVIb3ZlcjogZmFsc2UKc2hhZGVIb3ZlckludGVydmFs OiAyNTAKdGlsaW5nOiBmYWxzZQp0aWxpbmdMYXlvdXQ6IDAKdGlsaW5nUmFpc2VQb2xpY3k6IDAK c2VwYXJhdGVTY3JlZW5Gb2N1czogZmFsc2UKYWN0aXZlTW91c2VTY3JlZW46IGZhbHNlCnBsYWNl bWVudDogNApmb2N1c1BvbGljeUlzUmVhc29uYWJsZTogdHJ1ZQpib3JkZXJTbmFwWm9uZTogMTAK d2luZG93U25hcFpvbmU6IDEwCmNlbnRlclNuYXBab25lOiAwCnNuYXBPbmx5V2hlbk92ZXJsYXBw aW5nOiBmYWxzZQpzaG93RGVza3RvcElzTWluaW1pemVBbGw6IGZhbHNlCnJvbGxPdmVyRGVza3Rv cHM6IGZhbHNlCmZvY3VzU3RlYWxpbmdQcmV2ZW50aW9uTGV2ZWw6IDEKbGVnYWN5RnVsbHNjcmVl blN1cHBvcnQ6IGZhbHNlCm9wZXJhdGlvblRpdGxlYmFyRGJsQ2xpY2s6IApjb21tYW5kQWN0aXZl VGl0bGViYXIxOiAwCmNvbW1hbmRBY3RpdmVUaXRsZWJhcjI6IDMwCmNvbW1hbmRBY3RpdmVUaXRs ZWJhcjM6IDIKY29tbWFuZEluYWN0aXZlVGl0bGViYXIxOiA0CmNvbW1hbmRJbmFjdGl2ZVRpdGxl YmFyMjogMzAKY29tbWFuZEluYWN0aXZlVGl0bGViYXIzOiAyCmNvbW1hbmRXaW5kb3cxOiA3CmNv bW1hbmRXaW5kb3cyOiA4CmNvbW1hbmRXaW5kb3czOiA4CmNvbW1hbmRXaW5kb3dXaGVlbDogMzEK Y29tbWFuZEFsbDE6IDEwCmNvbW1hbmRBbGwyOiAzCmNvbW1hbmRBbGwzOiAxNAprZXlDbWRBbGxN b2RLZXk6IDE2Nzc3MjUxCnNob3dHZW9tZXRyeVRpcDogZmFsc2UKZWxlY3RyaWNCb3JkZXJzOiBm YWxzZQplbGVjdHJpY0JvcmRlckRlbGF5OiAxNTAKZWxlY3RyaWNCb3JkZXJDb29sZG93bjogMzUw CmVsZWN0cmljQm9yZGVyUHVzaGJhY2tQaXhlbHM6IDEKZWxlY3RyaWNCb3JkZXJNYXhpbWl6ZTog dHJ1ZQplbGVjdHJpY0JvcmRlclRpbGluZzogdHJ1ZQpib3JkZXJsZXNzTWF4aW1pemVkV2luZG93 czogZmFsc2UKa2lsbFBpbmdUaW1lb3V0OiA1MDAwCmhpZGVVdGlsaXR5V2luZG93c0ZvckluYWN0 aXZlOiB0cnVlCmluYWN0aXZlVGFic1NraXBUYXNrYmFyOiBmYWxzZQphdXRvZ3JvdXBTaW1pbGFy V2luZG93czogZmFsc2UKYXV0b2dyb3VwSW5Gb3JlZ3JvdW5kOiB0cnVlCmNvbXBvc2l0aW5nTW9k ZTogMQp1c2VDb21wb3NpdGluZzogdHJ1ZQpjb21wb3NpdGluZ0luaXRpYWxpemVkOiB0cnVlCmhp ZGRlblByZXZpZXdzOiAxCnVucmVkaXJlY3RGdWxsc2NyZWVuOiBmYWxzZQpnbFNtb290aFNjYWxl OiAxCmdsVlN5bmM6IGZhbHNlCnhyZW5kZXJTbW9vdGhTY2FsZTogZmFsc2UKbWF4RnBzSW50ZXJ2 YWw6IDE3CnJlZnJlc2hSYXRlOiAwCnZCbGFua1RpbWU6IDYxNDQKZ2xEaXJlY3Q6IHRydWUKZ2xT dHJpY3RCaW5kaW5nOiBmYWxzZQpnbFN0cmljdEJpbmRpbmdGb2xsb3dzRHJpdmVyOiB0cnVlCgpD b21wb3NpdGluZwo9PT09PT09PT09PQpRdCBHcmFwaGljcyBTeXN0ZW06IHJhc3RlcgpDb21wb3Np dGluZyBpcyBhY3RpdmUKQ29tcG9zaXRpbmcgVHlwZTogT3BlbkdMCk9wZW5HTCB2ZW5kb3Igc3Ry aW5nOiBOVklESUEgQ29ycG9yYXRpb24KT3BlbkdMIHJlbmRlcmVyIHN0cmluZzogR2VGb3JjZSA4 NDAwR1MvUENJZS9TU0UyCk9wZW5HTCB2ZXJzaW9uIHN0cmluZzogMy4zLjAgTlZJRElBIDMwNC41 MQpEcml2ZXI6IE5WSURJQQpEcml2ZXIgdmVyc2lvbjogMzA0LjUxCkdQVSBjbGFzczogVW5rbm93 bgpPcGVuR0wgdmVyc2lvbjogMy4zClggc2VydmVyIHZlcnNpb246IDEuMTMKTGludXgga2VybmVs IHZlcnNpb246IDMuNQpEaXJlY3QgcmVuZGVyaW5nOiB5ZXMKUmVxdWlyZXMgc3RyaWN0IGJpbmRp bmc6IG5vCkdMU0wgc2hhZGVyczogIHllcwpUZXh0dXJlIE5QT1Qgc3VwcG9ydDogIHllcwpPcGVu R0wgMiBTaGFkZXJzIGFyZSB1c2VkCgpMb2FkZWQgRWZmZWN0czoKLS0tLS0tLS0tLS0tLS0tCmt3 aW40X2VmZmVjdF96b29tCmt3aW40X2VmZmVjdF9kaW1zY3JlZW4Ka3dpbjRfZWZmZWN0X2xvZ2lu Cmt3aW40X2VmZmVjdF9zbGlkaW5ncG9wdXBzCmt3aW40X2VmZmVjdF93b2JibHl3aW5kb3dzCmt3 aW40X2VmZmVjdF9jb3ZlcnN3aXRjaAprd2luNF9lZmZlY3RfbWluaW1pemVhbmltYXRpb24Ka3dp bjRfZWZmZWN0X3NjcmVlbnNob3QKa3dpbjRfZWZmZWN0X3NsaWRlCmt3aW40X2VmZmVjdF9zbGlk ZWJhY2sKa3dpbjRfZWZmZWN0X2ZsaXBzd2l0Y2gKa3dpbjRfZWZmZWN0X2dsaWRlCmt3aW40X2Vm ZmVjdF9mYWRlCmt3aW40X2VmZmVjdF9kaWFsb2dwYXJlbnQKa3dpbjRfZWZmZWN0X2hpZ2hsaWdo dHdpbmRvdwprd2luNF9lZmZlY3RfdGFza2JhcnRodW1ibmFpbAprd2luNF9lZmZlY3RfbG9nb3V0 Cmt3aW40X2VmZmVjdF9vdXRsaW5lCmt3aW40X2VmZmVjdF9zdGFydHVwZmVlZGJhY2sKCkN1cnJl bnRseSBBY3RpdmUgRWZmZWN0czoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKRWZmZWN0IFNl dHRpbmdzOgotLS0tLS0tLS0tLS0tLS0tCmt3aW40X2VmZmVjdF96b29tOgp6b29tRmFjdG9yOiAx LjI1Cm1vdXNlUG9pbnRlcjogMAptb3VzZVRyYWNraW5nOiAwCmVuYWJsZUZvY3VzVHJhY2tpbmc6 IGZhbHNlCmZvbGxvd0ZvY3VzOiB0cnVlCmZvY3VzRGVsYXk6IDM1MAptb3ZlRmFjdG9yOiAyMAp0 YXJnZXRab29tOiAxCgprd2luNF9lZmZlY3RfZGltc2NyZWVuOgoKa3dpbjRfZWZmZWN0X2xvZ2lu OgpmYWRlVG9CbGFjazogdHJ1ZQoKa3dpbjRfZWZmZWN0X3NsaWRpbmdwb3B1cHM6CmZhZGVJblRp bWU6IDUwMApmYWRlT3V0VGltZTogNTAwCgprd2luNF9lZmZlY3Rfd29iYmx5d2luZG93czoKc3Rp ZmZuZXNzOiAwLjA2CmRyYWc6IDAuOQptb3ZlRmFjdG9yOiAwLjEKeFRlc3NlbGF0aW9uOiAyMAp5 VGVzc2VsYXRpb246IDIwCm1pblZlbG9jaXR5OiAwCm1heFZlbG9jaXR5OiAxMDAwCnN0b3BWZWxv Y2l0eTogMC41Cm1pbkFjY2VsZXJhdGlvbjogMAptYXhBY2NlbGVyYXRpb246IDEwMDAKc3RvcEFj Y2VsZXJhdGlvbjogMC41Cm1vdmVFZmZlY3RFbmFibGVkOiB0cnVlCm9wZW5FZmZlY3RFbmFibGVk OiBmYWxzZQpjbG9zZUVmZmVjdEVuYWJsZWQ6IGZhbHNlCm1vdmVXb2JibGU6IHRydWUKcmVzaXpl V29iYmxlOiB0cnVlCgprd2luNF9lZmZlY3RfY292ZXJzd2l0Y2g6CmFuaW1hdGlvbkR1cmF0aW9u OiA0MDAKYW5pbWF0ZVN3aXRjaDogdHJ1ZQphbmltYXRlU3RhcnQ6IHRydWUKYW5pbWF0ZVN0b3A6 IHRydWUKcmVmbGVjdGlvbjogdHJ1ZQp3aW5kb3dUaXRsZTogdHJ1ZQp6UG9zaXRpb246IDkwMApk eW5hbWljVGh1bWJuYWlsczogdHJ1ZQp0aHVtYm5haWxXaW5kb3dzOiA4CnByaW1hcnlUYWJCb3g6 IHRydWUKc2Vjb25kYXJ5VGFiQm94OiBmYWxzZQoKa3dpbjRfZWZmZWN0X21pbmltaXplYW5pbWF0 aW9uOgoKa3dpbjRfZWZmZWN0X3NjcmVlbnNob3Q6Cgprd2luNF9lZmZlY3Rfc2xpZGU6Cgprd2lu NF9lZmZlY3Rfc2xpZGViYWNrOgoKa3dpbjRfZWZmZWN0X2ZsaXBzd2l0Y2g6CnRhYkJveDogZmFs c2UKdGFiQm94QWx0ZXJuYXRpdmU6IHRydWUKZHVyYXRpb246IDQwMAphbmdsZTogMzAKeFBvc2l0 aW9uOiAwLjMzMDAwMDAxMzExMzAyMgp5UG9zaXRpb246IDEKd2luZG93VGl0bGU6IHRydWUKCmt3 aW40X2VmZmVjdF9nbGlkZToKZHVyYXRpb246IDcwMAplZmZlY3Q6IDEKYW5nbGU6IDAKCmt3aW40 X2VmZmVjdF9mYWRlOgoKa3dpbjRfZWZmZWN0X2RpYWxvZ3BhcmVudDoKY2hhbmdlVGltZTogNjAw Cgprd2luNF9lZmZlY3RfaGlnaGxpZ2h0d2luZG93OgoKa3dpbjRfZWZmZWN0X3Rhc2tiYXJ0aHVt Ym5haWw6Cgprd2luNF9lZmZlY3RfbG9nb3V0Ogp1c2VCbHVyOiB0cnVlCgprd2luNF9lZmZlY3Rf b3V0bGluZToKCmt3aW40X2VmZmVjdF9zdGFydHVwZmVlZGJhY2s6Cg==