[kde] [Bug 479891] Some text glyphs in QML software are mis-aligned or squished when using a fractional scale factor
https://bugs.kde.org/show_bug.cgi?id=479891 akb825 changed: What|Removed |Added CC||akb...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 415179] Touchpad disabled when detected as both mouse and touchpad
https://bugs.kde.org/show_bug.cgi?id=415179 --- Comment #13 from akb825 --- After updating to Plasma 6 and switching to a Wayland session and libinput, everything seems to be working as expected. IIRC I earlier opted to use Synaptics because the libinput driver didn't support drag-lock, but this is now supported under Plasma 6. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 475198] Links in markdown show raw markdown rather than a clickable link.
https://bugs.kde.org/show_bug.cgi?id=475198 --- Comment #4 from akb825 --- After further investigation, Arch does appear to have a proper dependency on the discount package, and the installed okularGenerator_md.so library is properly linking to libmarkdown.so. However, it looks like on August 27 the discount package was updated from version 2.2.7.d to 3.0.0.a. Okular does appear to have explicit checks for discount 3 to use the new API, but if the issue is limited to the newer version of discount that could explain the difference on your machine and mine. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 475198] Links in markdown show raw markdown rather than a clickable link.
https://bugs.kde.org/show_bug.cgi?id=475198 --- Comment #3 from akb825 --- > Can you test it with "discount-mkd2html test.md" in your system? After installing the discount package and running mkd2html, it displays the link correctly. Double checking the code for Okular, it appears to have Discount as a dependency in the CMakeLists.txt. Does it use some sort of fallback if Discount isn't found? It's possible that the Arch package is simply misconfigured. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 475198] Links in markdown show raw markdown rather than a clickable link.
https://bugs.kde.org/show_bug.cgi?id=475198 --- Comment #2 from akb825 --- Created attachment 162092 --> https://bugs.kde.org/attachment.cgi?id=162092=edit Screenshot of the test file The attached file does not appear correctly. I have attached a screenshot of how it looks for me in Okular. Browsing around the settings, I noticed the "Configure Backends" options, which has a section for Markdown. Apart from the default font, there's only an "Enable SmartyPants formatting" option, but toggling it doesn't appear to make any difference. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 473940] Markdown code block is rendered interpreted as Markdown
https://bugs.kde.org/show_bug.cgi?id=473940 akb825 changed: What|Removed |Added CC||akb...@gmail.com --- Comment #2 from akb825 --- Created attachment 162068 --> https://bugs.kde.org/attachment.cgi?id=162068=edit Example from report attached as a separate file An example is in the original reporter's summary. I have attached it as a separate file. Best I can tell is it's completely ignoring the code block, and in fact shows the raw ``` markers for the code block. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 475198] New: Links in markdown show raw markdown rather than a clickable link.
https://bugs.kde.org/show_bug.cgi?id=475198 Bug ID: 475198 Summary: Links in markdown show raw markdown rather than a clickable link. Classification: Applications Product: okular Version: 23.08.1 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: markdown backend Assignee: okular-de...@kde.org Reporter: akb...@gmail.com Target Milestone: --- SUMMARY Links that follow the standard Markdown syntax (e.g. [google](https://google.com)) show the raw markdown rather than a clickable link. STEPS TO REPRODUCE 1. Edit a Markdown file to add a link, such as [google](https://google.com). 2. Open the Markdown file in Okular. OBSERVED RESULT The raw markdown syntax is shown for the link and no part of it is clickable. EXPECTED RESULT Only the text within the [] brackets is shown and clicking it goes to the URL between (). SOFTWARE/OS VERSIONS Linux: Arch Linux KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION This is a recent regression. I'm not sure about the exact timing, but likely corresponds with the 23.08 release. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 473879] Preview when using the rectangular region tool is offset to the right.
https://bugs.kde.org/show_bug.cgi?id=473879 akb825 changed: What|Removed |Added CC||akb...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 465489] Can no longer unassign "space" from activating selection mode
https://bugs.kde.org/show_bug.cgi?id=465489 --- Comment #2 from akb825 --- > Space would select the first file, not toggle the selection. One couldn't > de-select a file with > Space, but only with Ctrl+Space. My mistake, other threads mentioned toggling, though I primarily use it for selection without needing to toggle so I wasn't sure about that distinction. > Do you think you could get used to pressing Ctrl+Space the same way you got > used to pressing > Space to select the first file in a file listing? Given enough time I probably could. I double checked that this also works in Windows, which is my primary concern: I often swap back and forth between Windows and KDE and it's disruptive to have that muscle memory disrupted. (similar to the recent issue where Shift + Delete defaulted to cancel) > I also think that selecting the first file in a folder isn't really a general > enough task to warrant > having the most easily triggerable keyboard shortcut. After all, if one > wants to act on any file > other than the first, the arrow keys to go there will already select the file > in the process. Does > this make sense to you? In my experience selecting the first file is quite common. For example, sometimes directory structures are mandated by tools and lead to a lot of directories with a single element. If you're iterating on a file it may often be first if you're sorting by modification time. Overall, when looking at the window, it's straight-forward to say "this is third to the right, so press right three times", but if it's first and there's no easy shortcut it gets very awkward. > Another question: A lot of users want to have a quick preview feature similar > to Apple's Mac's > Finder's QuickLook feature, that is also bound to Space there. Would you be > opposed to having > that on the Space key? I personally wouldn't use such a feature. However, I understand that others who use often switch between macOS and KDE would very much want to avoid interrupting their muscle memory the same way I'm more familiar with the Windows shortcuts. If this were configurable, perhaps even with a set of common defaults that are more Mac-like, Windows-like, or KDE-native then each group could be happy. > Well, the person who created that (Popov) disliked the selection mode in > every shape and marked > the selection mode feature with a dislike button even before it was assigned > to any keyboard > shortcut. He is now lobbying against this on reddit and writes passive > aggressive comments to me. > I don't really think that discussion points to many people having an issue > with the new behaviour. > Everyone I talked with about the Space shortcut so far didn't know that they > could simply use the > Ctrl+Space shortcut instead which is more generally useful anyway because it > also allows de-selecting. My intent here was more to show that there was interest apart from me in at least having a path to the old behavior. I saw the other ticket he created requesting a way to fully disable selection mode (I didn't realize when I posted the link that it was the same person), and explicitly decided against adding this to that ticket because the discussion devolved quite quickly. To give a constructive argument for my own thoughts on the matter, many have created muscle memory from using other systems over the course of decades. It may take days, weeks, or even longer to fully get used to a new routine, and causes a lot of friction if you need to switch between OSs for various tasks. In this specific case an alternative (Ctrl+Space) is available that works across both Dolphin and Windows, though obviously many aren't aware of this alternative. While you've been able to inform myself and some others about this alternative, it does demonstrate that it's a common issue. For those who have this muscle memory and aren't aware of the alternative, they will leave with the impression that Dolphin is clunky and awkward - not because it's a bad feature or not useful, but because it doesn't do what they expect based on years of using other systems. Only a few will generally speak out about it (even if some are a bit overly vocal...), though it may leave a bad impression nonetheless. For me personally, I don't see myself using the selection mode. I try to use the keyboard to navigate when possible, and when selecting arbitrary files with a mouse am used to the modifier keys. However, I do see that others may find it very useful and streamline their workflows, especially if they incorporate the mouse more in their file browsing, and it doesn't bother me having it be present so long as it doesn't get in the way. Configurability is one of the strong points of KDE, and one of the big reasons why I can't stand GNOME. While it may add some extra complexity, it may help offer a smoother experience overall to allow space
[dolphin] [Bug 465489] New: Can no longer unassign "space" from activating selection mode
https://bugs.kde.org/show_bug.cgi?id=465489 Bug ID: 465489 Summary: Can no longer unassign "space" from activating selection mode Classification: Applications Product: dolphin Version: 22.12.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Selection Mode Assignee: kfm-de...@kde.org Reporter: akb...@gmail.com CC: felixer...@kde.org Target Milestone: --- SUMMARY Prior to Dolphin 22.12 you could press space to toggle the selection, which was convenient as a quick way to select the first element in a file listing. This streamlined tasks such as navigating, renaming, or deleting items in a folder with a keyboard as using the arrow keys to select would move the cursor off of the first item. This is how I used the shortcut, though I'm sure others had different uses as well. With Dolphin 22.12, Selection Mode was assigned to "space" by default. However, it was possible to restore the previous behavior by unassigning space from activating selection mode. As of 22.12.2 this no longer works as the default keyboard assignments for "Select" and "Select Files and Folders" is unassigned and space will always enable selection mode. STEPS TO REPRODUCE 1. Open "Configure Keyboard Shortcuts" in Dolphin and verify that "Select" and "Select Files and Folders" are set to the default of "None". 2. Open a folder in Dolphin. 3. Press "space" with the intent to toggle the selection of the first element. OBSERVED RESULT Selection mode is activated with a prompt to click files to select them. EXPECTED RESULT The selection is toggled unless "space" is assigned as a keyboard shortcut to activate selection mode. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8 ADDITIONAL INFORMATION When searching if there was an existing bug, there appears to be others unhappy with the current situation, such as with this thread on Reddit: https://www.reddit.com/r/kde/comments/10tovgu/spacebar_behavior_in_dolphin/ While some pointed out the workaround of unassigning the key shortcut, that unfortunately appears to no longer be an option. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 463095] Copying a file from one Dolphin window to another doesn't update clipboard.
https://bugs.kde.org/show_bug.cgi?id=463095 --- Comment #1 from akb825 --- In case it makes a difference, I am running through an X11 session. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 463095] New: Copying a file from one Dolphin window to another doesn't update clipboard.
https://bugs.kde.org/show_bug.cgi?id=463095 Bug ID: 463095 Summary: Copying a file from one Dolphin window to another doesn't update clipboard. Classification: Applications Product: dolphin Version: 22.12.0 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: akb...@gmail.com CC: kfm-de...@kde.org Target Milestone: --- SUMMARY When copying files from window A to paste into window B, the clipboard isn't updated for subsequent pastes. For example, if you copy file Foo from window A, you can paste it into window B. However, if you then try to copy Bar from window A and paste into window B, file Foo (the first one copied) will be pasted instead. STEPS TO REPRODUCE 1. Open two windows in Dolphin. 2. Copy a file from the first window and paste into the second window. 3. Select a different file from the first window and paste into the second window. OBSERVED RESULT The file copied from step 2 is copied during step 3. EXPECTED RESULT The file copied from step 3 is copied during step 3. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 ADDITIONAL INFORMATION When copying and pasting within the same Dolphin window, the clipboard is updated as expected. However, when pasting any file that comes from a different window, it will only ever take the first file you pasted until you close and re-open the window. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 435561] Cannot specify usergroup for OpenConnect VPNs
https://bugs.kde.org/show_bug.cgi?id=435561 --- Comment #7 from akb825 --- I have submitted an MR here: https://invent.kde.org/plasma/plasma-nm/-/merge_requests/57 -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 435561] Cannot specify usergroup for OpenConnect VPNs
https://bugs.kde.org/show_bug.cgi?id=435561 --- Comment #4 from akb825 --- Further investigation confirms that the patch I posted should fix the issue on the plasma-nm side of not forwarding the usergroup, while separate issues in NetworkManager-openconnect (related to the split routing) are the cause of the timeout issue. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 435561] Cannot specify usergroup for OpenConnect VPNs
https://bugs.kde.org/show_bug.cgi?id=435561 --- Comment #3 from akb825 --- Created attachment 137574 --> https://bugs.kde.org/attachment.cgi?id=137574=edit usergroup.patch I went through the code and I believe the main problem is that only the host + port is passed to the NetworkManager-openconnect plugin that establishes the "real" connection to the VPN. I have attached a patch (usergroup.patch) that appends the urlpath (which is parsed as the usergroup) to the NM_OPENCONNECT_KEY_GATEWAY secrets parameter when it's provided. This allows the connection to be established with the pulse protocol (since it was using the incorrect URL for the cookie). However, similar to my previous results with the "Juniper Network Connect" protocol all network activity that's routed through the VPN times out. My guess is there's some additional issues in NetworkManager-openconnect that's preventing it from working properly. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 435561] Cannot specify usergroup for OpenConnect VPNs
https://bugs.kde.org/show_bug.cgi?id=435561 akb825 changed: What|Removed |Added CC||akb...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 435561] Cannot specify usergroup for OpenConnect VPNs
https://bugs.kde.org/show_bug.cgi?id=435561 --- Comment #2 from akb825 --- After some more experimentation, the behavior of whether the dialog disappears and openconnect writes the cookie error to the journal, or whether it has the "unknown code" error in the dialog, appears to be inconsistent. In other words, relying on parsing the group from the gateway and using the xmlconfig gives the same results. This behavior was using the "Pulse Connect Secure" protocol. When using the "Juniper Network Connect" protocol any connection over the VPN times out when providing the usergroup. (even ones that give a forbidden error when not connected to the VPN at all) -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 435561] Cannot specify usergroup for OpenConnect VPNs
https://bugs.kde.org/show_bug.cgi?id=435561 --- Comment #1 from akb825 --- After looking through the code, it looks like it *is* trying to parse the group from the gateway. However, attempting to do this fails to connect. No error is reported in the UI, it simply closes the dialog and isn't connected to the VPN. When viewing the log from journalctl, openconnect reported the error "Pulse authentication cookie not accepted". Using the exact same URL (copy/pasted to avoid typos) works with the openconnect command in a terminal. I additionally found that you can set an "xmlconfig" element in vpn-secrets section with a base64 XML configuration. When attempting to set the tag, I get the following error in the UI: "Pulse password request with unknown code 0x00. Please report." -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 421743] Realm option missing when connecting to Jumper/Pulse VPN via OpenConnect and NetworkManager.
https://bugs.kde.org/show_bug.cgi?id=421743 akb825 changed: What|Removed |Added Resolution|--- |NOT A BUG Status|REPORTED|RESOLVED --- Comment #1 from akb825 --- >From what I can tell, the method of specifying the connection has changed in the VPN itself. The realm was passed as a form parameter previously, which was able to be parsed to create a combo box in the UI. However, this is now provided with the usergroup parameter rather than the form. In other words, the information to display the UI is no longer being passed when connecting, and the usergroup parameter must be passed explicitly instead. Unfortunately there appears to be no way to actually set the usergroup, so I'm still stuck unable to choose the "tunnel-all" connection type. I have created a separate bug (https://bugs.kde.org/show_bug.cgi?id=435561) to capture this issue. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 435561] New: Cannot specify usergroup for OpenConnect VPNs
https://bugs.kde.org/show_bug.cgi?id=435561 Bug ID: 435561 Summary: Cannot specify usergroup for OpenConnect VPNs Product: plasma-nm Version: 5.21.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jgrul...@redhat.com Reporter: akb...@gmail.com Target Milestone: --- SUMMARY The usergroup cannot be specified for OpenConnect VPNs. For example, my company provides a "default" connection, which routes specific domains through the VPN, and a "tunnel-all" connection, which routes all traffic. Typically the usergroup would be specified by the URL. For example, https://vpn.mycompany.com/tunnel-all. When using the openconnect command-line, you can use the "--usergroup=tunnel-all" command-line option. Attempting to pass the usergroup to the gateway address (e.g. vpn.mycompany.com/tunnel-all) fails, since it expects it to only be a hostname. Ideally, either the usergroup would be parsed from the gateway address or a separate field would be available to specify it. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 5.21.4 KDE Frameworks Version: 5.80.0 Qt Version: 5.15.2 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 415179] Touchpad disabled when detected as both mouse and touchpad
https://bugs.kde.org/show_bug.cgi?id=415179 --- Comment #9 from akb825 --- Nevermind, it isn't consistent even with that change: XOrg will still sometimes keep the device enabled, even when verifying that the device name listed in xinput matches one of the ones I've disabled through an XOrg config. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 415179] Touchpad disabled when detected as both mouse and touchpad
https://bugs.kde.org/show_bug.cgi?id=415179 --- Comment #8 from akb825 --- This seems to be a constantly moving target. I additionally need to disable PS/2 Generic Mouse to have the touchpad reliably work: Section "InputClass" Identifier "Ignore synaptics mouse" MatchProduct "PS/2 Generic Mouse" MatchIsPointer "on" Option "Ignore" "on" EndSection -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 415179] Touchpad disabled when detected as both mouse and touchpad
https://bugs.kde.org/show_bug.cgi?id=415179 --- Comment #7 from akb825 --- After some investigation, it looks like the current issue is caused because there's a second touchpad device (PS/2 Synaptics TouchPad) that shows up in the xinput device list. The ordering of the list is inconsistent between boots, and it will incorrectly disable the touchpad when the PS/2 Synaptics TouchPad is on top. When I disable this extra touchpad device, it looks like it works around the issue. Therefore, the new workaround for the Xorg config is: Section "InputClass" Identifier "Ignore synaptics touchpad" MatchProduct "PS/2 Synaptics TouchPad" MatchIsTouchpad "on" Option "Ignore" "on" EndSection Just to note, I do not have the xf86-input-synaptics package installed, so the Synaptics device seems to be detected even with the default X11 packages. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 415179] Touchpad disabled when detected as both mouse and touchpad
https://bugs.kde.org/show_bug.cgi?id=415179 --- Comment #6 from akb825 --- >From what I can tell the workaround listed by Mads is no longer doing anything. Having the workaround or not has the same behavior: sometimes when I boot (maybe 25-50% of the time) it will disable the trackpad, other times it won't. Logging off and logging back on doesn't seem to change anything, a full reboot is required. (though there's probably some magic command that could fix it as well) Would it be possible to at least bring back the option to not disable the trackpad when it detects a mouse? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 415179] Touchpad disabled when detected as both mouse and touchpad
https://bugs.kde.org/show_bug.cgi?id=415179 --- Comment #5 from akb825 --- To provide an update for this issue, the X11 workaround Mads posted is inconsistent. Sometimes it still disables the touchpad on boot and requires one or two reboots before it works. I've kept up to date based on Arch's packages, so I'm currently on Plasma 5.19.3. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 423600] Desktop inherits DPI setting from login manager after first login
https://bugs.kde.org/show_bug.cgi?id=423600 --- Comment #18 from akb825 --- I've attached three screenshots: 1. The correct results shown with the first login after booting and after synchronizing the SDDM settings with KDE. 2. The desktop elements too small after logging in a second time with the default (unsynchronized) settings. 3. The desktop elements too large after setting the SDDM DPI to 384 and logging in a second time. This shows the desktop icons, panel text, and panel menu having the incorrect DPI. I could only show so much with a single screenshot, but the right-click contextual menu for the desktop has the same issues. Other programs display correctly. I believe this pretty conclusively demonstrates that Plasma is using the SDDM DPI after logging on a second time rather than using the KDE settings. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 423600] Desktop inherits DPI setting from login manager after first login
https://bugs.kde.org/show_bug.cgi?id=423600 --- Comment #17 from akb825 --- Created attachment 130024 --> https://bugs.kde.org/attachment.cgi?id=130024=edit The desktop elements being too large after setting a very high DPI for SDDM. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 423600] Desktop inherits DPI setting from login manager after first login
https://bugs.kde.org/show_bug.cgi?id=423600 --- Comment #16 from akb825 --- Created attachment 130023 --> https://bugs.kde.org/attachment.cgi?id=130023=edit The desktop elements being too small on the second login with the default (non-synchronized) settings. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 423600] Desktop inherits DPI setting from login manager after first login
https://bugs.kde.org/show_bug.cgi?id=423600 --- Comment #15 from akb825 --- Created attachment 130022 --> https://bugs.kde.org/attachment.cgi?id=130022=edit The correct result on the first login and when the KDE and SDDM settings are synchronized. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 423600] Desktop inherits DPI setting from login manager after first login
https://bugs.kde.org/show_bug.cgi?id=423600 --- Comment #13 from akb825 --- Yes, syncing the SDDM settings works around the problem. It basically hides the bug, but it took quite a bit of digging around to track down. Let's say I'm a normal user of KDE and just set up my machine. I have a high DPI display, so I set my global scale to 200%. The login screen is a bit small, but that's not a big deal. However, sometimes when I log in my desktop and panel menus are smaller than normal. Rebooting fixes the problem. Out of the box it's broken. Fixing it requires two things: 1. Deducing that the problem is related to the login screen DPI. Since it's inconsistent, that might be a little difficult to deduce. 2. Knowing that you can synchronize the login settings. That requires some spelunking through the settings. The fact that there is a workaround doesn't mean there is no problem. The fact that Plasma doesn't always respect the KDE settings is a bug. It results in strange behavior, and finding that workaround when you only see the problem takes quite a bit of effort. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 423600] Desktop inherits DPI setting from login manager after first login
https://bugs.kde.org/show_bug.cgi?id=423600 --- Comment #11 from akb825 --- The problem is Plasma desktop has the following behavior: * The first time logging on after booting, it correctly takes KDE's DPI. * The second time logging on (and each time following) it takes SDDM's DPI. All other applications take the KDE settings regardless of how many times you log out and log back in. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 423600] Desktop inherits DPI setting from login manager after first login
https://bugs.kde.org/show_bug.cgi?id=423600 --- Comment #9 from akb825 --- On my laptop I only adjusted the scaling by setting the global scale to 200% in the Display Configuration control panel. (which I'm assuming is the KScreen KCM you're referring to) However, this setting doesn't apply to SDDM unless you manually synchronize the settings in the Login Screen (SDDM) control panel. To summarize: * The DPI was only configured in a single place. (global scale in display settings) * By default, the DPI set in KDE may be mismatched with SDDM. * Manually synchronizing the settings in the SDDM control panel fixes the mismatch. I will note that this used to work, so it's a regression that was introduced in some recent version. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 423600] Desktop inherits DPI setting from login manager after first login
https://bugs.kde.org/show_bug.cgi?id=423600 --- Comment #7 from akb825 --- To provide a bit more info, the example numbers I used were for my laptop. I also have a desktop with 4k monitors, but the specific DPI settings are a bit different: I have the KDE set to use 120 DPI, but the default for XOrg (when not setting the -dpi option for ServerArguments in the SDDM config) appears to be 192. As a result, the Plasma desktop and panel items are actually *larger* on the second login, as opposed to smaller on the laptop. In both cases, the default XOrg DPI is different (96 for laptop, 192 for desktop) and on the second login Plasma's DPI scale appears to match XOrg's DPI. This is why I believe that Plasma is inheriting the XOrg DPI value on the second login rather than respecting the KDE setting. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 423600] Desktop inherits DPI setting from login manager after first login
https://bugs.kde.org/show_bug.cgi?id=423600 --- Comment #6 from akb825 --- > I'm not convinced that SDDM is involved at all, but your symptoms match a > description of not using Qt scaling. I believe that the SDDM settings are merely the trigger for the bug in Plasma. The DPI settings for XOrg being mismatched from KDE cause the scaling for Plasma to be incorrect on the second launch/login. > If you set PLASMA_USE_QT_SCALING=1 in the environment when plasma starts up, > does the problem disappear? No, the problem persists. I can tell that some of the scaling behavior is different because the panel height and context menu icons are doubled in size. The panel height and icon size remain consistent between logging out and logging back in, but the text is 1/2 the size after the second login. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 423600] Desktop inherits DPI setting from login manager after first login
https://bugs.kde.org/show_bug.cgi?id=423600 --- Comment #4 from akb825 --- In this case, the "-dpi 192" option was set after synchronizing with the KDE settings. However, if I remove this setting, based on the size of the UI elements I believe it was using a default of 96. When it was originally using this default of 96 for the login manager, the Plasma desktop would display correctly the first time I logged in after booting. (with the DPI of 192 from the KDE settings) However, if I logged out and logged back in it would inherit the DPI of 96 from the login manager. As a result, the desktop icons, desktop context menu, and panel menus all were very small. Other applications would display correctly. Once the settings were synchronized, which added the "-dpi 192" option to the sddm config, the desktop would display correctly regardless of how many times I log out and back on. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 423600] Desktop inherits DPI setting from login manager after first login
https://bugs.kde.org/show_bug.cgi?id=423600 --- Comment #2 from akb825 --- If the DPI scaling isn't 100%, it will be different for the login manager by default unless you manually synchronize the settings under the Advanced section of the "Login Screen (SDDM)" control panel. If you have synchronized the settings, it will have a section that looks like this in /etc/sddm.conf.d/kde_settings.conf: [X11] ServerArguments=-dpi 192 You can either change this section or modify the dpi argument value to force them to differ. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 423600] New: Desktop inherits DPI setting from login manager after first login
https://bugs.kde.org/show_bug.cgi?id=423600 Bug ID: 423600 Summary: Desktop inherits DPI setting from login manager after first login Product: plasmashell Version: 5.19.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Desktop Containment Assignee: notm...@gmail.com Reporter: akb...@gmail.com CC: plasma-b...@kde.org Target Milestone: 1.0 SUMMARY After logging off and logging back in, the Plasma Desktop (including desktop icons, context menu, panel, etc.) will use the DPI settings from the login manager. (e.g. SSDM) Other applications will properly use the KDE settings. STEPS TO REPRODUCE 1. Have the login manager use a different DPI setting from KDE. 2. Log into KDE. 3. Log out. 4. Log back into KDE. OBSERVED RESULT On the second login, the desktop will have the DPI scaling from the login manager. EXPECTED RESULT The desktop always respects the KDE settings. SOFTWARE/OS VERSIONS Linux: Arch Linux KDE Plasma Version: 5.19.2 KDE Frameworks Version: 5.71.0 Qt Version: 5.15.0 ADDITIONAL INFORMATION This can be worked around by synchronizing the login manager settings with KDE from the Login Screen control panel. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 421743] New: Realm option missing when connecting to Jumper/Pulse VPN via OpenConnect and NetworkManager.
https://bugs.kde.org/show_bug.cgi?id=421743 Bug ID: 421743 Summary: Realm option missing when connecting to Jumper/Pulse VPN via OpenConnect and NetworkManager. Product: systemsettings Version: 5.18.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_networkmanagement Assignee: jgrul...@redhat.com Reporter: akb...@gmail.com CC: plasma-b...@kde.org Target Milestone: --- SUMMARY Realm option missing when connecting to Juniper/Pulse VPN via OpenConnect and NetworkManager. For example, my company's VPN offers a "standard" connection that routes some traffic through the VPN and "tunnel-all" connection that routes all traffic. I am unable to select "tunnel-all" since the field is now missing. STEPS TO REPRODUCE 1. Add a Juniper/Pulse OpenConnect VPN connection. 2. Connect to the VPN. OBSERVED RESULT Realm combo box option is missing. EXPECTED RESULT Realm combo box option is present. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.70.0 Qt Version: 5.14.2 ADDITIONAL INFORMATION GNOME had the same issue as shown in this bug report: https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/issues/5. This may provide some insight on what may be causing the problem on KDE. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 415179] Touchpad disabled when detected as both mouse and touchpad
https://bugs.kde.org/show_bug.cgi?id=415179 --- Comment #4 from akb825 --- After updating today having xf86-input-synaptics installed no longer works around the bug. Applying the X11 config by Mads was able to restore the touchpad. -- You are receiving this mail because: You are watching all bug changes.
[Touchpad-KCM] [Bug 415179] Touchpad disabled when detected as both mouse and touchpad
https://bugs.kde.org/show_bug.cgi?id=415179 --- Comment #2 from akb825 --- > Can you see if installing the xf86-input-synaptics brings back the option to > disable touchpad while mouse is connected. Thank you, that did restore the ability to adjust when the touchpad is enabled. I was able to add the "mouse" entry for the touchpad to the ignore list without fully disabling the feature. I need to use an XOrg config to customize the settings, but this was the same as the previous behavior, so it's at least a usable workaround for now. -- You are receiving this mail because: You are watching all bug changes.
[Touchpad-KCM] [Bug 415179] New: Touchpad disabled when detected as both mouse and touchpad
https://bugs.kde.org/show_bug.cgi?id=415179 Bug ID: 415179 Summary: Touchpad disabled when detected as both mouse and touchpad Product: Touchpad-KCM Version: unspecified Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: major Priority: NOR Component: kcm Assignee: atulbish...@gmail.com Reporter: akb...@gmail.com Target Milestone: --- SUMMARY After updating to the latest version of Plasma/KDE, the touchpad on my laptop gets disabled automatically due to KDE detecting that a mouse is plugged in, despite the fact that there is no mouse present. Upon further investigation, my touchpad is being detected as both a touchpad and mouse with separate device entries. It appears that the KDE control panel for touchpad input was recently changed and no longer gives an option for whether or not to disable the touchpad when a mouse is connected: as a result my touchpad is *always* disabled with no option of re-enabling it. STEPS TO REPRODUCE 1. Boot to login screen with no mouse plugged in. Touchpad works. 2. Log in. Touch pad is disabled. OBSERVED RESULT A notification pops up saying that the trackpad was disabled because a mouse was plugged in. EXPECTED RESULT Touchpad continues to work unless a physical mouse is plugged in. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux, fully up to date KDE Plasma Version: 5.17.4 KDE Frameworks Version: 5.64.0 Qt Version: 5.13.2 ADDITIONAL INFORMATION The laptop I'm using is a Dell XPS 15 9570. The relative output from /proc/bus/input/devices is: I: Bus=0018 Vendor=06cb Product=7a13 Version=0100 N: Name="SYNA2393:00 06CB:7A13 Mouse" P: Phys=i2c-SYNA2393:00 S: Sysfs=/devices/pci:00/:00:15.1/i2c_designware.1/i2c-6/i2c-SYNA2393:00/0018:06CB:7A13.0002/input/input23 U: Uniq= H: Handlers=event17 mouse4 B: PROP=0 B: EV=17 B: KEY=3 0 0 0 0 B: REL=3 B: MSC=10 I: Bus=0018 Vendor=06cb Product=7a13 Version=0100 N: Name="SYNA2393:00 06CB:7A13 Touchpad" P: Phys=i2c-SYNA2393:00 S: Sysfs=/devices/pci:00/:00:15.1/i2c_designware.1/i2c-6/i2c-SYNA2393:00/0018:06CB:7A13.0002/input/input24 U: Uniq= H: Handlers=event18 mouse5 B: PROP=5 B: EV=1b B: KEY=e520 1 0 0 0 0 B: ABS=2e08003 B: MSC=20 The relative output from running the command libinput list-devices is: Device: SYNA2393:00 06CB:7A13 Mouse Kernel: /dev/input/event17 Group:9 Seat: seat0, default Capabilities: pointer Tap-to-click: n/a Tap-and-drag: n/a Tap drag lock:n/a Left-handed: disabled Nat.scrolling:disabled Middle emulation: n/a Calibration: n/a Scroll methods: button Click methods:none Disable-w-typing: n/a Accel profiles: flat *adaptive Rotation: n/a Device: SYNA2393:00 06CB:7A13 Touchpad Kernel: /dev/input/event18 Group:9 Seat: seat0, default Size: 102x77mm Capabilities: pointer gesture Tap-to-click: disabled Tap-and-drag: enabled Tap drag lock:disabled Left-handed: disabled Nat.scrolling:disabled Middle emulation: disabled Calibration: n/a Scroll methods: *two-finger edge Click methods:*button-areas clickfinger Disable-w-typing: enabled Accel profiles: none Rotation: n/a -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383723] SIGILL failure with ud2 opcode _dispatch_kq_init (in /usr/lib/system/libdispatch.dylib) (macOS)
https://bugs.kde.org/show_bug.cgi?id=383723 akb825 <akb...@gmail.com> changed: What|Removed |Added CC||akb...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
