309193 2012-10-29 12:05:48 +0000 Keyboard shortcuts doesn't work if non-english keyboard layout is set before english one 2022-08-11 19:51:42 +0000 1 1 2 Applications systemsettings kcm_keyboard 5.24.4 unspecified Linux CLOSED FIXED https://bugs.kde.org/show_bug.cgi?id=375518 https://bugs.kde.org/show_bug.cgi?id=453461 https://bugs.kde.org/show_bug.cgi?id=454511 NOR normal --- 0 dmitry.ashkadov plasma-bugs-null adaptee akimkin.denis alon.barlev arthur aspotashev avm-xandry b7.10110111 bharadwaj.raju777 butirsky caslav.ilic cfeck chalkerx chem_tomcat egdfree empyreal finomeno hexawolf holyfoek hsantanna ian itumaykin+kde ivan.kolmycheck josh+tech jules konsole-bugs-null mo78 morden2k m_louis30 najera.oscar nate oleg.sev oxdef+kde paul_arts pavlo.s.verba regboxemg regtothismail ro.ggi schwarzer shafff simonandric5 starw1nd stupor_scurvy343 sunwebrw timhilt travneff vova7890 w01dnick wolfgang.brehm yevhen.kemet zeroadhesion Qt 5.something 0 oldest_to_newest 1310551 0 dmitry.ashkadov 2012-10-29 12:05:48 +0000 If in systemsettings english keyboard layout isn't set first (for example, I can move russian keyboard layout before english) then hotkeys doesn't work (: Ctrl+Shift+T doesn't open new tab, it isn't possible to copy/paste with Ctrl+Shift+C/V. Reproducible: Always Steps to Reproduce: 1. Open keyboard settings and put non-english layout before english 2. Open konsole, try Ctrl+Shift+T Actual Results: Nothing Expected Results: Hotkeys should have effect 1310697 1 adaptee 2012-10-29 23:04:38 +0000 Just to be clear, when you say "try Ctrl+Shift+T", is it per the physical keyboard layout, or the logical keyboard layout ? Although I have limited knowledge about those layout issues(because I never need/use it), I guess the problem is not specific to konsole. It should be a KDE/Qt wide problem. Please also try other KDE applications where you have defined "Ctrl+Shift+...." shortcuts. 1310727 2 dmitry.ashkadov 2012-10-30 06:22:34 +0000 Thank you! Ctrl+Shift+T => T is latin symbol More shortcuts don't work: Ctrl+Shift+C and etc. I've found that some shortcuts of another applications don't work. For example, krunner search panel doesn't appear if I set its shortcut to Win+R. So, this bug should be moved to upstream. 1310731 3 dmitry.ashkadov 2012-10-30 06:25:17 +0000 But I don't know what product should I set to this bug. 1316515 4 ro.ggi 2012-11-18 18:09:47 +0000 I can confirm that with Russian keyboard, you can not copy/paste in dolphin and kate, the combination of "Alt+." didn't show hidden files, etc. I also noticed that this problem only applies to some KDE Apps. LibreOffice, Rekonq, Kontakt works well with shortcuts. You can also move Russian to the second language in settings and select it later over control bar, than all shortcuts works too. There is older duplicate of this bug: https://bugs.kde.org/show_bug.cgi?id=272259 1323635 5 adaptee 2012-12-14 05:38:31 +0000 *** Bug 272259 has been marked as a duplicate of this bug. *** 1337689 6 regboxemg 2013-02-04 07:01:58 +0000 I can confirm this bug. It happens when you set russian (doesn't matter which one) as a default layout. I got this bug since 2009 (KDE 4.2) until KDE 4.8.5 (didn't try with KDE 4.9) Distributions: archlinux i686, gentoo i686, kubuntu i686 / amd64. So I guess it is not a packaging problem. Back in 2009 I switched layouts and set english as first layout and forgot about it. Thought this bug was fixed but found it in Kubuntu 12.04 few days ago. 1338465 7 regboxemg 2013-02-06 21:31:55 +0000 (In reply to comment #6) Just tried with Gentoo i686 & KDE 4.9.5. Bug still exists. Once you set english layout as second - hotkeys do not work at all. When you get it back at 1st place - everything is fine. It doesn't depend on gcc / glibc / xorg / etc version, distro and all that stuff as far as I can tell. 1381731 8 w01dnick 2013-07-06 09:23:21 +0000 openSUSE x86_64, KDE SC 4.10.5 — looks like hotkeys use keysym, not a keycode, so when I use ukrainian or russian shortcuts don't work (or may work unexpectedly). PS. When I've used 4.10.4 all was fine. 1382160 9 ivan.kolmycheck 2013-07-08 10:00:21 +0000 I'm having this bug too, in 4.10.5. In 4.10.4 everything worked just fine. With latin layout everything is working fine, but not with russian or ukrainian. Offtopic: it reminds me good'n'old bug in Firefox with same effect. 1383089 10 yevhen.kemet 2013-07-13 05:52:20 +0000 I can confirm this bug. Shortcuts (Ctrl+C Ctrl+V Ctrl+Z Ctrl+P Ctrl+Q Ctrl+W Ctrl+T) do not work in such applications as dolphin, krusader, konsole etc. in case when russian/ukrainian keyboard layout is activated. But shortcuts work fine in such applications as firefox and thunderbird (and maybe in other applications which built on GTK) regardless of the chosen keyboard layout. $uname -a Linux Arch64 3.9.9-1-ARCH #1 SMP PREEMPT Wed Jul 3 22:45:16 CEST 2013 x86_64 GNU/Linux $kde4-config --version Qt: 4.8.5 KDE: 4.10.5 kde4-config: 1.0 1383403 11 w01dnick 2013-07-15 04:48:04 +0000 By the way, this may be a Qt 4.8.5 problem, not KDE SC. I've created test Qt application, added action with Ctrl+A shortcut. This shortcut works with english layout, but does not with ukrainian/russian ones. 1383654 12 mo78 2013-07-15 23:51:39 +0000 Hello, I can confirm that Qt 4.8.5 is the culprit. I've been lucky enough having image (backup) before it's upgrade went out, which helps me to investigate the problem. I've installed a group of available updates and seek for the problem. When it finally appeared I've remember from which group it came and I've just begun to close circle by installing less and less packages from this group and finaly found it. It's definitely Qt 4.8.5. For now I hold it via editing pacman.conf at v. 4.8.4 and haven't problems at all. In case of upgrade to version 4.8.5, the problem appears after reboot. Hope the fix it soon. $ uname -a Linux mozo 3.9.9-1-ARCH #1 SMP PREEMPT Wed Jul 3 22:45:16 CEST 2013 x86_64 GNU/Linux $ kde4-config --version Qt: 4.8.4 KDE Development Platform: 4.10.5 kde4-config: 1.0 1383656 13 mo78 2013-07-15 23:53:51 +0000 Typo: Hope they fix it soon.* 1383691 14 ivan.kolmycheck 2013-07-16 07:02:27 +0000 I hope too. Sent link to other affected users I know with proposal to register, comment and vote. 1383701 15 w01dnick 2013-07-16 08:22:24 +0000 I've found only Qt 5.1 bug https://bugreports.qt-project.org/browse/QTBUG-32274 but 4.8.5 mentiod there. 1383758 16 zeroadhesion 2013-07-16 12:59:51 +0000 *** This bug has been confirmed by popular vote. *** 1383857 17 wolfgang.brehm 2013-07-16 20:07:16 +0000 for me it seems this bug, which also seems to be the same as 274820 and 320423 Is fixed with Qt: 4.8.5 KDE: 4.10.5 "release 4" 1383863 18 wolfgang.brehm 2013-07-16 20:25:18 +0000 KDE apps behave now as expected but, only if the first keyboard is standard. So I am sorry I mislead you. This bug exactly is not fixed but the situation has improved. 1383921 19 adaptee 2013-07-17 02:43:17 +0000 *** Bug 322454 has been marked as a duplicate of this bug. *** 1384931 20 adaptee 2013-07-21 03:32:01 +0000 *** Bug 320008 has been marked as a duplicate of this bug. *** 1385261 21 vova7890 2013-07-22 14:14:32 +0000 On archlinux and kubuntu similar problem have. 1385524 22 paul_arts 2013-07-23 18:59:50 +0000 Fedora 19 with KDE 4.10.5 and Qt 4.8.4, similar problem. 1385538 23 mo78 2013-07-23 20:30:19 +0000 @paul_arts, what happens if you upgrade to Qt 4.8.5? 1386281 24 dglent 2013-07-27 14:03:57 +0000 I have the same problem since i installed kde 4.10.4 For example, before, i could open the search dialogue in konqueror with ctrl+f even when i had the Greek keyboard layout enabled 1388740 25 chalkerx 2013-08-09 14:13:20 +0000 Now the keyboard shortcuts do not work at all, if the current keyboard layout is non-latin. It does not depend on the keyboard layout order. Using KDE SC 4.10.97. 1388743 26 w01dnick 2013-08-09 14:37:21 +0000 Nikita, this is Qt 4.8.5 bug, not KDE. I'm using Qt 4.8.4 and KDE SC 4.10.97 — hot keys work. 1388745 27 w01dnick 2013-08-09 14:40:46 +0000 (In reply to comment #26) > — hot keys work. If first layout is latin. 1388856 28 mo78 2013-08-10 10:17:13 +0000 Here I post report: https://bugreports.qt-project.org/browse/QTBUG-32908 Please comment. 1393247 29 adaptee 2013-08-28 13:57:29 +0000 *** Bug 322027 has been marked as a duplicate of this bug. *** 1399027 30 stupor_scurvy343 2013-09-23 14:37:37 +0000 The change was reverted upstream: http://qt.gitorious.org/qt/qt/commit/1f76ee2c4615907033f670fb61ea2eff515d72e9/diffs/0c03af0d4d928bdbb32b09eedb1dba3ce59e5278 1399358 31 dglent 2013-09-25 04:45:51 +0000 It has to be Linus Torvalds who did it. He is the only guy who returns on his decisions. Or, he did his effective gesture again... 1428094 32 anakin.cs 2014-01-31 21:03:32 +0000 I'm having the same issue, and it's quite annoying. I need the layout to be ordered in a specific way to work around a bug in Wine with some games, but the shortcuts are always the ones of the first layout, even when I switch. There seem to be many duplicates of this bug: https://bugs.kde.org/show_bug.cgi?id=306374 https://bugs.kde.org/show_bug.cgi?id=316909 https://bugs.kde.org/show_bug.cgi?id=209699 1434029 33 finomeno 2014-03-05 22:40:07 +0000 Hello everyone! After months of switching layouts and banging my head against this bug, I thought I should check LibreOffice settings (I'm using 4.1.5.3 now). What figures? I did find something. And in just a few clicks. This is not a bug! It's simply a matter of configuration. For the regular keyboard shortcuts (like Ctrl+C, Ctrl+V, etc.) to remain operational in LibreOffice applications while using a non-latin keyboard layout (like Greek or Russian), go to Tools -> Options -> Language Settings -> Languages, check the Ignore system input language option, save, and Bob's your uncle. Hope this helps. Cheers! PS Technically, though, shortcuts still remain language-dependent. This means if you enable this option, you will have to set your document languages manually. 1434073 34 dglent 2014-03-06 05:17:22 +0000 For me in LibreOffice the shortcuts ctrl+c ctr+v ctr+z ctr+x work without the above setting But in KDE they work too. But the shortcuts like ctrl+O ctrl+T don't work I use a Greek layout and the keys 'T' and 'O' remain at the same position on the keyboard EG: in kmail the ctrl+. (collapse messages view) works in Greek too and the '.' is at a different position than the physical position of the '.' key on the keyboard (i use a French keyboard with French/Greek layouts) Same for the Ctrl+, it works for the both layouts So the problem is only with letters and not with symbols and not with the standard combinations copy paste cut cancel 1434114 35 anakin.cs 2014-03-06 11:07:49 +0000 I'm not sure if we're all having the same problem or a different issue. Anyway I think mine is the same as the original post: only the keyboard layout you set first is used in KDE applications such as Dolphin. I have the English one first and French 2nd. My keyboard layout is set to the 2nd. CTRL+A should select all files in Dolphin, but instead is closes Dolphin (because A on a Azerty keyboard is at the same place as Q, so it does CTRL+Q = Quit). 1465673 36 sunwebrw 2014-08-14 07:27:23 +0000 Yes, this exactly what happens to me and seeing this is a bug from 2012 doesn't make we cheerfull in the slightest. They didn't fix it back then they won't fix it now =( If i choose first layout as English everything works even if i change language but if choose non English layout first KDE programs won't recognize most useful shortcuts even when i change language to English. Kubuntu 14.04, latest updates till date. KDE is really nice envornment but such extremely stupid bugs are really downing in 2014. 1465724 37 mo78 2014-08-14 11:00:24 +0000 This bug has been solved a long time ago. Just don't use shity *buntu, with 100 years old packages. In Arch we already forget about this bug. It has been sooo time long ago. 1465726 38 anakin.cs 2014-08-14 11:03:26 +0000 Wrong, it's not fixed, I have the same bug in Arch. 1465727 39 mo78 2014-08-14 11:07:38 +0000 I don't have it anymore since I have reported it. $ uname -a Linux mozo 3.16.0-2-ARCH #1 SMP PREEMPT Mon Aug 4 19:04:45 CEST 2014 x86_64 GNU/Linux $ kde4-config --version Qt: 4.8.6 KDE Development Platform: 4.13.3 kde4-config: 1.0 I use bulgarian layout and all is working fine. 1465728 40 anakin.cs 2014-08-14 11:10:01 +0000 We're probably talking of different issues then. The original issue only happens when you use multiple keyboard layouts, not just one. 1465747 41 mo78 2014-08-14 12:46:33 +0000 No, it is not a different issue. I use En(US) and Bulgarian layouts. When I use Bg layout, all hotkeys works without any problem. 1487327 42 morden2k 2014-12-23 13:38:46 +0000 Any news about this issue? Laout config: us - English (US) - us ru - Russian - ru $ uname -a Linux xxx 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ kde4-config --version Qt: 4.8.6 KDE Development Platform: 4.13.3 kde4-config: 1.0 I need to logoff for make hotkays working in application's (e.g. Ctrl+Shift+T in Konsole, Ctrl+X in Dolphin etc.). But after some time hotkeys stop working again. So I need to logoff/loggin each time (( Is there any other workarounds? P.S. I do not specialist in Linux, but how I how hotkeys must be processed in application directly without any other hidden ways/services. Like processing keys/virtual keys in WindowProc through message queue in windows application. But in kde some strange delirium with this ((( 1487337 43 morden2k 2014-12-23 14:50:26 +0000 Also "Alt-Shift" for switch language keyboard stops working permanently. But workaround works: Open language settings/Layouts, move some layout to up, push apply, back layout to down, push apply & close. But will be nice without this workarround. 1496643 44 cfeck 2015-02-02 23:21:20 +0000 I have selected this bug as the "Bug of the Month". See https://community.kde.org/Gardening If you are able to fix it, you will receive a honorable mention in the next issue of my blog post "The Bug of the Month" on Planet KDE. Not all developers that would be able to fix it are subscribed to this bug. If you know someone, feel free to point them here. 1496973 45 shafff 2015-02-04 00:21:16 +0000 can somebody explain me why anybody would need to have non-English layout first in the list? 1496980 46 chalkerx 2015-02-04 01:37:28 +0000 Can anyone reproduce this in kf5/qt5-based apps? 1496981 47 chalkerx 2015-02-04 01:53:38 +0000 My observations: 1) Reproducible in kde4 and pure qt4-based apps. Qt4 version: 4.8.6 2) Not reproducible in kf5 and pure qt5-based apps. Qt5 version: 5.4.0 For me, it looks like a Qt4 bug which is already fixed in Qt5. 1496982 48 chalkerx 2015-02-04 02:06:17 +0000 Upstream bugreport: https://bugreports.qt.io/browse/QTBUG-15319 1496988 49 dglent 2015-02-04 05:19:07 +0000 (In reply to Dimitrios Glentadakis from comment #24) > I have the same problem since i installed kde 4.10.4 > For example, before, i could open the search dialogue in konqueror with > ctrl+f even when i had the Greek keyboard layout enabled It works now with KDE 4.14.3 1497214 50 chalkerx 2015-02-05 00:06:33 +0000 https://codereview.qt-project.org/#/c/96993/ — this looks to be the proper fix (and explanation) in Qt5. +147, -48, and those changes were done in the xcb QPA backend. The main file is https://qt.gitorious.org/qt/qtbase/source/5.4:src/plugins/platforms/xcb/qxcbkeyboard.cpp Qt4 has different architecture, the files in question are something around https://qt.gitorious.org/qt/qt/source/4.8:src/gui/kernel/qkeymapper_x11.cpp 1497324 51 shafff 2015-02-05 13:16:17 +0000 ok to close as FIXED UPSTREAM? 1497401 52 aacid 2015-02-05 19:08:21 +0000 Please leave it open until we have confirmed it's fixed for all our users in all the software versions we maintain. 1503098 53 m_louis30 2015-03-02 14:18:29 +0000 I can reproduce this bug (both Qt 4.8.6 and 5.4.1) using Belgian and French (Bépo) layouts, in this order. Some shortcuts work as expected (in rekonq: Ctrl+T), some others don't (Ctrl+W). I think it works when the first layout has a letter, and doesn't when it's a symbol (dot, comma, …). 1533376 54 najera.oscar 2015-07-26 14:36:28 +0000 I have this same problem. I use kde 5 with plasma 5 in arch linux. The shortcut match the physical layout of the keyboard and not the Dvorak layout I have on top. 1543955 55 jules 2015-09-14 12:30:38 +0000 I have the same problem, with French (AZERTY) keyboard as first keyboard, and using english keyboard. (so Ctrl+A quit and Ctrl+Q select All, confusing...) using: Ubuntu 14.04, kde 4.13.3, Qt 4.8.6 1565858 56 holyfoek 2015-12-25 23:37:18 +0000 This used to work with KDE 4 but is broken with Arch and Plasma 5.5.2. 1565859 57 holyfoek 2015-12-26 00:22:26 +0000 This fixed the problem for me (from https://forum.kde.org/viewtopic.php?f=289&t=130179&p=348185#p348027 ): pkill kglobalaccel5 kglobalaccel5 & 1587906 58 schwarzer 2016-04-11 19:41:50 +0000 I have this problem for a long time now. Shortcuts like Ctrl+S for Saving do work in Kate but not in KDevelop for instance. My intuition told me that the KF5 versions work but the KDE4 versions don't, but I did not check this properly. Qt 4.8.7 and 5.5.1 installed. My keyboard layout is US with some custom mappings with xmodmap. 1587908 59 schwarzer 2016-04-11 19:47:00 +0000 ... Forgot to mention that those shortcuts in KDevelop actually do work once every few weeks but the next reboot they are gone again. 1595443 60 99068 b7.10110111 2016-05-19 07:20:36 +0000 Created attachment 99068 Attempt to fix in Qt I'm not sure whether this patch for Qt4 even goes in the right direction, but it does appear to fix this problem for me with US+Russian layouts, regardless of which layout is primary. I guess it might break with e.g. US+AZERTY or other cases when all layouts are Latin, I didn't check this yet. Maybe someone could constructively criticize my approach so that I could do it in a better way. Didn't try to submit it to Qt, since 1) not sure if it's the right approach and 2) Qt bug 15319 is closed. 1601975 61 pavlo.s.verba 2016-06-17 22:45:06 +0000 I would like to note that this bug is still alive and doing well. I am on openSUSE Tumbleweed with KDE Plasma 5.5.3, KDE Frameworks 5.22.0 and Qt 5.6.0, and it sure does not look fixed from here. :) 1602043 62 mo78 2016-06-18 09:11:29 +0000 Same here with Arch and Plasma 5.5.3. 4 years... 1613047 63 ian 2016-08-10 08:14:54 +0000 just adding my 2c worth ... I also have this problem. am experimenting with different layouts, all variants of US English. Hotkey behaviour seems to vary by program--- some work fine, others work if you hit where the key is supposed to be on US QWERTY layout. It SEEMED to me as if the program was reading the scancode rather than the letter it was mapped to .... My layouts in order are: EurKey standard US QWERTY Custom layout Thanks, Ian 1723877 64 hexawolf 2018-01-20 21:21:45 +0000 Can be reproduced on Arch Linux, KDE on Wayland, seems to work with Firefox but doesn't works with Kate, Telegram, Konsole and probably any other Qt application. Seems to work on Gnome. Doesn't works if layout is non-latin. Haven't tested on X session. KDE Plasma Version: 5.11.5 KDE Frameworks Version: 5.42.0 Qt Version: 5.10.0 It's 2018, can this finally receive some attention or KDE developers really care about bugs less than those fancy "vaults" that nobody actually cares about? 1723900 65 cfeck 2018-01-21 02:22:28 +0000 Probably needs a Qt patch similar to comment #60. We didn't find a developer yet who is able to fix it. 1723986 66 aacid 2018-01-21 19:05:20 +0000 (In reply to Hexawolf from comment #64) > It's 2018, can this finally receive some attention or KDE developers really > care about bugs less than those fancy "vaults" that nobody actually cares > about? I like how you know what every single person in the world cares about. Maybe if you really care about this bug you should hire someone to fix it. Stop bitching about things you're given for free, it doesn't make you look nice. 1946297 67 nate 2020-07-26 02:20:28 +0000 Ruslan, if this is a Qt issue, would you be interested in submitting a patch for Qt 5? That said, all of the Qt bug reports listed in the comment thread here have been closed upstream. Apparently the Qt developers think it's fixed. If it's not fixed, can somebody file a new one? 1946309 68 b7.10110111 2020-07-26 05:04:35 +0000 (In reply to Nate Graham from comment #67) > Ruslan, if this is a Qt issue, would you be interested in submitting a patch > for Qt 5? I don't reproduce this problem with Qt5, at least in Kubuntu 18.04, so I suppose it's fixed there. 1946431 69 nate 2020-07-26 13:31:15 +0000 Phew! Thanks for the confirmation. 1988753 70 chem_tomcat 2020-12-28 23:52:46 +0000 Kubuntu 20.10, bug still exist. If I set Russian layout to Top in list, shortcuts stops working (Ctrl+Atl+T, Win+E and other). 1988757 71 b7.10110111 2020-12-29 00:00:03 +0000 (In reply to Egor T from comment #70) > Kubuntu 20.10, bug still exist. If I set Russian layout to Top in list, > shortcuts stops working (Ctrl+Atl+T, Win+E and other). Looks like you're mentioning some _global_ shortcuts (similar to Alt+F2). These are likely implemented in a very different way than application-local ones (like Ctrl+S). If I'm right that your shortcuts are global, then this should go into a different bug report. 2026261 72 bharadwaj.raju777 2021-04-20 09:30:51 +0000 *** This bug has been marked as a duplicate of bug 375518 *** 2027210 73 butirsky 2021-04-23 13:08:44 +0000 I'm sorry but seems bug 375518 fixes the problem for Wayland only. I'll see if similar approach can be reused to fix it on X11 2027364 74 butirsky 2021-04-23 22:32:43 +0000 (In reply to Andrey from comment #73) > I'll see if similar approach can be reused to fix it on X11 Well, it can. But need to link KKeyServer with xkbcommon library first and add some glue init code there, pretty much the same as it's done in https://code.woboq.org/qt5/qtbase/src/plugins/platforms/xcb/qxcbkeyboard.cpp.html. Also it might be worth to think about reusing that whole Qt's xcbkeyboard plugin as from what I can see KKeyServer mostly just duplicates functionality there. 2113956 75 butirsky 2022-03-28 11:27:13 +0000 *** Bug 451821 has been marked as a duplicate of this bug. *** 2122727 76 butirsky 2022-05-11 11:33:40 +0000 Assuming this bug is opened for local shortcuts, closing as fixed in Qt. For global shortcuts, it was fixed in KWin for Wayland, for X11 see my notes above. 2145228 77 empyreal 2022-08-11 19:40:40 +0000 Global actions/shortcuts do not work after language change. Global actions/shortcuts in System Settings - Shortcuts - Media Controller work only when EN language is selected. Operating System: Kubuntu 22.10 KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.4 Kernel Version: 5.15.0-46-generic (64-bit) Graphics Platform: X11 2145229 78 nate 2022-08-11 19:51:33 +0000 That sounds like a different issue. Please file a new bug report. 99068 2016-05-19 07:20:36 +0000 2016-05-19 07:20:36 +0000 Attempt to fix in Qt qt-non-latin-default-layout-shortcuts-fix.patch text/plain 1962 b7.10110111 ZGlmZiAtdXIgcXQtZXZlcnl3aGVyZS1vcGVuc291cmNlLXNyYy00LjguNi5vbGQvc3JjL2d1aS9r ZXJuZWwvcWtleW1hcHBlcl9wLmggcXQtZXZlcnl3aGVyZS1vcGVuc291cmNlLXNyYy00LjguNi9z cmMvZ3VpL2tlcm5lbC9xa2V5bWFwcGVyX3AuaAotLS0gcXQtZXZlcnl3aGVyZS1vcGVuc291cmNl LXNyYy00LjguNi5vbGQvc3JjL2d1aS9rZXJuZWwvcWtleW1hcHBlcl9wLmgJMjAxNC0wNC0xMCAy MjozNzoxMi4wMDAwMDAwMDAgKzA0MDAKKysrIHF0LWV2ZXJ5d2hlcmUtb3BlbnNvdXJjZS1zcmMt NC44LjYvc3JjL2d1aS9rZXJuZWwvcWtleW1hcHBlcl9wLmgJMjAxNi0wNS0xNyAxOTowMTo1OS4w MjU2MzM2MTggKzAzMDAKQEAgLTE2Nyw3ICsxNjcsNyBAQAogCiAjZWxpZiBkZWZpbmVkKFFfV1Nf WDExKQogCi0gICAgUUxpc3Q8aW50PiBwb3NzaWJsZUtleXNYS0IoUUtleUV2ZW50ICpldmVudCk7 CisgICAgUUxpc3Q8aW50PiBwb3NzaWJsZUtleXNYS0IoUUtleUV2ZW50ICpldmVudCxib29sIHVz ZVZpcnR1YWxLZXkpOwogICAgIFFMaXN0PGludD4gcG9zc2libGVLZXlzQ29yZShRS2V5RXZlbnQg KmV2ZW50KTsKIAogICAgIGJvb2wgdHJhbnNsYXRlS2V5RXZlbnRJbnRlcm5hbChRV2lkZ2V0ICpr ZXl3aWRnZXQsCmRpZmYgLXVyIHF0LWV2ZXJ5d2hlcmUtb3BlbnNvdXJjZS1zcmMtNC44LjYub2xk L3NyYy9ndWkva2VybmVsL3FrZXltYXBwZXJfeDExLmNwcCBxdC1ldmVyeXdoZXJlLW9wZW5zb3Vy Y2Utc3JjLTQuOC42L3NyYy9ndWkva2VybmVsL3FrZXltYXBwZXJfeDExLmNwcAotLS0gcXQtZXZl cnl3aGVyZS1vcGVuc291cmNlLXNyYy00LjguNi5vbGQvc3JjL2d1aS9rZXJuZWwvcWtleW1hcHBl cl94MTEuY3BwCTIwMTQtMDQtMTAgMjI6Mzc6MTIuMDAwMDAwMDAwICswNDAwCisrKyBxdC1ldmVy eXdoZXJlLW9wZW5zb3VyY2Utc3JjLTQuOC42L3NyYy9ndWkva2VybmVsL3FrZXltYXBwZXJfeDEx LmNwcAkyMDE2LTA1LTE3IDE5OjI1OjE5LjI5OTYwNjAxNyArMDMwMApAQCAtMjY0LDcgKzI2NCwx MCBAQAogewogI2lmbmRlZiBRVF9OT19YS0IKICAgICBpZiAoWDExLT51c2VfeGtiKQotICAgICAg ICByZXR1cm4gcG9zc2libGVLZXlzWEtCKGV2ZW50KTsKKyAgICB7CisgICAgICAgIC8vIHJldHVy biBib3RoIExhdGluIGFuZCBub24tbGF0aW4gdmFyaWFudHMsIGF2b2lkaW5nIGR1cGxpY2F0ZXMK KyAgICAgICAgcmV0dXJuIChwb3NzaWJsZUtleXNYS0IoZXZlbnQsdHJ1ZSkrcG9zc2libGVLZXlz WEtCKGV2ZW50LGZhbHNlKSkudG9TZXQoKS50b0xpc3QoKTsKKyAgICB9CiAjZW5kaWYKICAgICBy ZXR1cm4gcG9zc2libGVLZXlzQ29yZShldmVudCk7CiB9CkBAIC0yNzQsNyArMjc3LDcgQEAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQgJmNvZGUsIFF0OjpLZXlib2FyZE1vZGlm aWVycyAmbW9kaWZpZXJzLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFFCeXRlQXJy YXkgJmNoYXJzLCBpbnQgJmNvdW50KTsKIAotUUxpc3Q8aW50PiBRS2V5TWFwcGVyUHJpdmF0ZTo6 cG9zc2libGVLZXlzWEtCKFFLZXlFdmVudCAqZXZlbnQpCitRTGlzdDxpbnQ+IFFLZXlNYXBwZXJQ cml2YXRlOjpwb3NzaWJsZUtleXNYS0IoUUtleUV2ZW50ICpldmVudCwgYm9vbCB1c2VWaXJ0dWFs S2V5KQogewogI2lmbmRlZiBRVF9OT19YS0IKICAgICBjb25zdCBpbnQgeGtleWNvZGUgPSBldmVu dC0+bmF0aXZlU2NhbkNvZGUoKTsKQEAgLTI4OCw2ICsyOTEsOCBAQAogICAgICAgICAgICAgICAg ICAgICAgICAgICZjb25zdW1lZE1vZGlmaWVycywgJmJhc2VLZXlTeW0pKQogICAgICAgICByZXR1 cm4gUUxpc3Q8aW50PigpOwogCisgICAgaWYodXNlVmlydHVhbEtleSkgYmFzZUtleVN5bT1ldmVu dC0+bmF0aXZlVmlydHVhbEtleSgpOworCiAgICAgUUxpc3Q8aW50PiByZXN1bHQ7CiAKICAgICAv LyB0cmFuc2xhdGUgc3ltIC0+IGNvZGUK