[systemsettings] [Bug 470470] New: Usage of setxkbmap on Wayland resets Keyboard-Layout to US (even if it is not configured)
https://bugs.kde.org/show_bug.cgi?id=470470 Bug ID: 470470 Summary: Usage of setxkbmap on Wayland resets Keyboard-Layout to US (even if it is not configured) Classification: Applications Product: systemsettings Version: 5.27.5 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_keyboard Assignee: plasma-b...@kde.org Reporter: k...@kostianix.de CC: butir...@gmail.com Target Milestone: --- SUMMARY *** While the title suggests, that a lot of random things need to happen at the same time, i don't think this situation is as uncommon as it first seems. I've had the following in my .bashrc: `setxkbmap -option ctrl:nocaps 2>/dev/null`. While I totally agree, that x-keyboard-options should be set via config file rather than invoking them by the bashrc, it is however a totally legit way to archieve the desired behaviour (remap capslock in this case). However, if you have only one keyboard layout configured (just `de` in my case, no modified layouts), any use of xkbmap seems to break the layout, and - at least for some apps - reverts it to the `us`-layout (even it is not in my list of configured layouts). Even more strange is, that this only seem to affect some applications. For me the effect was most noticeable in firefox and thunderbird. I think it is not that uncommon for people switching from xorg to wayland to have some kind of options like this in some scripts. Especially annoying here is, that this will never be reproducible on new installs with a fresh homedir. Even though this clearly qualifies as "user-error", the keyboard should never ever fall back to an unconfigured layout, and behaviour like this is not very obvious to track down, because if you stare at it, you won't be able to observe the error until you start a new shell. As already assumed, calling xmodmap without redirecting the output, says that it is running against Xwayland, which might explain different behaviours in different windows. However, while having an xorg-compatibility layer is awesome, having multiple keyboard layouts active at the same time depending on the window is certainly not. any "apply" action in the "settingsmenu/input/keyboard" subsection reverts this behaviour to the expected state. I'd assume, there are alot of universal apps (flatpak..) that will be affected by this, too. *** STEPS TO REPRODUCE 1. put some `xmodmap` command in your .bashrc and start a terminal under wayland. Alternatively execute manually. OBSERVED RESULT - some applications like firefox and thunderbird end up with a default, but unconfigured and unlisted (in terms of the plasma settingsmenu) keyboard-layout (us). EXPECTED RESULT - keyboard-settings should be applied uniformly between apps regardless of wayland, Xwayland, flatpak, fullscreen-games, etc.. SOFTWARE/OS VERSIONS - Linux/KDE Plasma: Linux/6.3.4-arch1-1 - KDE Plasma Version: 5.27.5 - KDE Frameworks Version: 5.106.0 - Qt Version: 5.15.9 All-AMD-System (Ryzen7xxx/Navi31), Single Monitor Setup. Initially i thought this might be related to https://bugs.kde.org/show_bug.cgi?id=433576, but it turns out unrelated, as my behaviour perists with more than one layout as well. However, they seem somewhat similar anyways. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 341314] Plasma 5 somehow falls back to US keyboard after startup
https://bugs.kde.org/show_bug.cgi?id=341314 zeus changed: What|Removed |Added CC||k...@kostianix.de --- Comment #8 from zeus --- sorry, did not see this issue beforehand, but it might be related to what i just filed: https://bugs.kde.org/show_bug.cgi?id=470470 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kholidays] [Bug 470492] New: German Holiday "Fronleichnam" missing for all regional calender-variants
https://bugs.kde.org/show_bug.cgi?id=470492 Bug ID: 470492 Summary: German Holiday "Fronleichnam" missing for all regional calender-variants Classification: Frameworks and Libraries Product: frameworks-kholidays Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: k...@kostianix.de Target Milestone: --- SUMMARY *** The German Holiday "Fronleichnam" is a religious christian holiday in June. It is only applicable in around a third of the German federal states, and the definition-files (e.g. https://invent.kde.org/frameworks/kholidays/-/blob/master/holidays/plan2/holiday_de-nw_de) list them, but they don't actually show up in my calendar (i have explicitly choosen de-nw_de as holiday-calendar for the "Northrhine-Westphalia" Region in Germany, but this also applies on other regions, where this is a valid holiday like bavaria). This year, in 2023, the holiday would be on june 8th. As far as I can tell, for at least the last year it also hasn't been in my calendar applet. Tested on Ubuntu 22.04 and Archlinux. *** OBSERVED RESULT German Holiday "Fronleichnam" missing EXPECTED RESULT Holiday available in the respective calendars. ADDITIONAL INFORMATION This Holiday is a legit holiday in the following german regions: BW (Baden-Würtemberg) BY (Bayern) HE (Hessen) NW (Nordrhein-Westfalen) RP (Rheinland-Pfalz) SL (Saarland) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kholidays] [Bug 470492] German Holiday "Fronleichnam" missing for all regional german calender-variants
https://bugs.kde.org/show_bug.cgi?id=470492 zeus changed: What|Removed |Added Summary|German Holiday |German Holiday |"Fronleichnam" missing for |"Fronleichnam" missing for |all regional|all regional german |calender-variants |calender-variants -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kholidays] [Bug 470492] German Holiday "Fronleichnam" missing for all regional german calender-variants
https://bugs.kde.org/show_bug.cgi?id=470492
--- Comment #1 from zeus ---
Edit: The second of the two holidays specific to northrhine-westfalia
("Allerheiligen", always on 1st November) also does not show up in my calendar.
Please note, that "Allerheiligen" is valid for a different subset of germanys
regions than "Fronleichnam". So I guess all regional holidays are like not
working?
--
You are receiving this mail because:
You are watching all bug changes.
[frameworks-kholidays] [Bug 470492] German Holiday "Fronleichnam" missing for all regional german calender-variants
https://bugs.kde.org/show_bug.cgi?id=470492 --- Comment #2 from zeus --- Nevermind, regional holidays do actually work. The problem is just, that changing the calender does not have any effect on the running kalender. So if you restart your Plasma-Session the Calendar is actually correct. However, the bug is then, that a change of the holiday-calender does not trigger a reload of calender-entries. Any other modification (like for example enabling astronimical events) triggers them to show up without the applet or plama having to be restarted, like expected. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461501] Glitchy flickering artifacts while rendering tooltips on system tray and certain applications when using Morphing Popups effect
https://bugs.kde.org/show_bug.cgi?id=461501 Zeus changed: What|Removed |Added CC||epluribusunum1776@hotmail.c ||om -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462282] Task switcher under Wayland: icons/previews are not clickable
https://bugs.kde.org/show_bug.cgi?id=462282 Zeus changed: What|Removed |Added CC||epluribusunum1776@hotmail.c ||om --- Comment #16 from Zeus --- (In reply to Nate Graham from comment #11) > I think that falls under the category of "well then don't do that." :) > Meta+dragging is a power user feature; it's up to you to use it responsibly. > > Also this is a new thing from what was originally reported; since the > originally reported issue is no longer reproducible, let's close it. i *think* i can shed some light on this: i use meta+tab/cmd+tab for task switcher, and i can only drag the task switcher, not click on any of the thumbnails. i'm using thumbnail grid, but this is the case for every visualisation (including cover switch, which is jarring) this did not cause issues in x11, so i would count this as a regression (meta didn't drag the task switcher, and clicking worked as expected) i presume the original reporter used alt for window dragging, and so was experiencing the same thing it works fine if i change the drag modifier key in Window Management -> Window Behaviour -> Window Actions to alt, but that causes other problems (forgive me, i don't know what the correct thing to do is - comment on a closed issue, or clone it and make a new one that is likely the same. i didn't want to summarily mark it as reopened for this reason) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 470470] Usage of setxkbmap on Wayland resets Keyboard-Layout to US (even if it is not configured)
https://bugs.kde.org/show_bug.cgi?id=470470 --- Comment #2 from zeus --- (In reply to Wismill from comment #1) > setxkbmap and xmodmap are X11-only tools and will not work with Wayland. So > e.g. `setxkbmap -query` will most probably not gives you any meaningful > information. In a Wayland session, the only way to check reliably your > keymap in X11 is to use `xkbcomp $DISPLAY -` . Yes, I know this. My point was, that this can be a very common configuration for anyone migrating from X11 to Wayland, and in this case, very unpredictable things do happen. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 498502] kwin-crash when alt-tabbing
https://bugs.kde.org/show_bug.cgi?id=498502 --- Comment #1 from zeus --- Created attachment 177270 --> https://bugs.kde.org/attachment.cgi?id=177270&action=edit New crash information added by DrKonqi DrKonqi auto-attaching complete backtrace. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 498502] New: kwin-crash when alt-tabbing
https://bugs.kde.org/show_bug.cgi?id=498502 Bug ID: 498502 Summary: kwin-crash when alt-tabbing Classification: Plasma Product: kwin Version: 6.2.5 Platform: Arch Linux OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: k...@kostianix.de Target Milestone: --- Application: kwin_wayland (6.2.5) ApplicationNotResponding [ANR]: false Qt Version: 6.8.1 Frameworks Version: 6.9.0 Operating System: Linux 6.6.69-1-lts x86_64 Windowing System: Wayland Distribution: "Arch Linux" DrKonqi: 6.2.5 [CoredumpBackend] -- Information about the crash: this only happens occasionally and I was not able to exactly pinpoint the circumstances when this happens, but when alt-tabbing (I have the feeling this only happens switching to non-wayland-native windows like firefox) suddenly kwin crashes and then reloads. KDE-applications like Konsole will survive this crash in their current state, but most other Applications don't. Running Arch with LTS-Kernel on current all-AMD hardware. The crash can be reproduced sometimes. -- Backtrace (Reduced): #5 0x7d41a0e1691c in simple_mtx_lock () at ../mesa-24.3.3/src/util/simple_mtx.h:106 #6 _mesa_lock_debug_state () at ../mesa-24.3.3/src/mesa/main/debug_output.c:770 #7 0x7d41a0e175c0 in _mesa_log_msg () at ../mesa-24.3.3/src/mesa/main/debug_output.c:948 #8 0x7d41a0e7bea4 in _mesa_gl_vdebugf () at ../mesa-24.3.3/src/mesa/main/errors.c:171 #9 0x7d41a0e16759 in _debug_message () at ../mesa-24.3.3/src/mesa/main/debug_output.c:739 Reported using DrKonqi -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kholidays] [Bug 470492] German Holiday "Fronleichnam" missing for all regional german calender-variants
https://bugs.kde.org/show_bug.cgi?id=470492 zeus changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |NOT A BUG --- Comment #3 from zeus --- Nevermind, regional holidays do actually work. The problem is just, that changing the calender does not have any effect on the running kalender. So if you restart your Plasma-Session the Calendar is actually correct. However, the bug is then, that a change of the holiday-calender does not trigger a reload of calender-entries. Any other modification (like for example enabling astronimical events) triggers them to show up without the applet or plama having to be restarted, like expected. -- You are receiving this mail because: You are watching all bug changes.
