[KScreen] [Bug 360058] Kscreen should check screen at wakeup from suspend
https://bugs.kde.org/show_bug.cgi?id=360058 --- Comment #13 from Sergio --- @Simone > can you please verify if you have a similar situation, where two screens in > different location are named the same way? This is obscure to me. They have obviously the same "name" like DP1-1, HDMI2, etc. This "name" depends on the /connection/ of the monitor. E.g. on my system anything that is connected to the hdmi port gets named HDMI2! It does not matter if I connect to the hdmi port the monitor that I have at home or the monitor that I have at work. The point is that this is not the sole information that kscreen gets. If you go to the screen setup in KDE, you'll notice that kscreen can read the /brand/ and /model/ of the screens attached to it. In fact, it can read an identifier for each external monitor (I think via edid). This is the item used to store/recover the screen setup for every possible monitor combination. And in fact, when you do not put a suspend/resume cycle in between, it works just fine: e.g. This works fine At home -> detach monitor -> suspend -> go to work -> resume -> attach monitor This does not work At home -> suspend -> detach monitor -> go to work -> attach monitor -> resume -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 343803] Konsole keeps running in background after closing window with nvidia drivers
https://bugs.kde.org/show_bug.cgi?id=343803 --- Comment #87 from Sergio --- Reported to the Qt bug tracker https://bugreports.qt.io/browse/QTBUG-56766 -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 360058] Kscreen should check screen at wakeup from suspend
https://bugs.kde.org/show_bug.cgi?id=360058 --- Comment #15 from Sergio --- What I see does in fact seem consistent with your last comment. As soon as I am in a place where I have external screens to swap, I'll collect the logs and send them to you. My feeling is that what is going on is something following these lines: * The kscreen db has 3 "configurations" stored: - Laptop screen only: connector eDP1 edid "foo" - Laptop screen with Samsung full HD monitor: eDP1 + "foo" and HDMI2 + "bar" - Laptop screen with DELL monitor (lower res): eDP1 + "foo" and HDMI2 + "baz" Suppose that I am working with the setup with the external Samsung monitor. If I: - detach the monitor, kscreen correctly moves to the configuration with the laptop screen only. - then suspend and restore the laptop, the laptop resumes with the laptop screen configuration. - now attach the dell monitor, kscreen correctly sees the new monitor and reads its edid, understands it needs to move to the config for the dell monitor. So far so good. Conversely if I: suspend the laptop, detach the external samsung monitor, attach the dell monitor, resume, then kscreen sees that I still have an external monitor attached, but keeps seeing the edid from the Samsung monitor and so does not see a new coniguration hash and does not understand that it needs to switch to the "dell" config. This seems confirmed by the fact that the kde setup screen dialog shows the Samsung model number for the external monitor. At this point, even if I detach and reattach the external monitor, kscreen seems to not re-querying the edid. The only way to have it understand that I have the dell monitor is killing kscreen_backend_launcher, that gets immediately respawn. Unfortunately, if I do so, at this point kscreen updates its database, writing in it that the default resolution to use with the dell monitor is the current one, that unfortunately is still the resolution of the Samsung monitor (too high). -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 450371] New: Notifications about video/audio being played on computer keep appearing when computer sleeps or becomes unreachable
https://bugs.kde.org/show_bug.cgi?id=450371 Bug ID: 450371 Summary: Notifications about video/audio being played on computer keep appearing when computer sleeps or becomes unreachable Product: kdeconnect Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: android-application Assignee: albertv...@gmail.com Reporter: sergio.calleg...@gmail.com Target Milestone: --- SUMMARY When the computer is playing a video or some audio (e.g. in a browser), a notification appears on the connected android phone enabling its usage as a remote. Unfortunately, if the computer is put to sleep or becomes unreachable (e.g., because one pauses the playing, locks the computer and walks out with the phone), the notification on the android phone becomes impossible to silence. You cancel it and it keeps appearing forever. The android application should watch when a connected computer becomes unavailable and if there are notifications about it, accept that someone swipes them away and stop visualizing them over and over. STEPS TO REPRODUCE 1. Connect android phone and a computer 2. Play video on firefox on the computer 3. Pause the video on firefox 4. Walk away with the phone OBSERVED RESULT You get a notification on the phone about the video being played. If you swipe it away it reappears. And reappears. And so on over and over until you kill kde connect on the phone and restart it. EXPECTED RESULT The phone application should be happy when you swipe away the notification the first time. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Manjaro / up to date (available in About System) KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90 Qt Version: 5.15.2 ADDITIONAL INFORMATION Android app 1.19 -- You are receiving this mail because: You are watching all bug changes.
[Skanlite] [Bug 454772] New: Wishlist: Remember the setup when switching from ADF to flatbed and viceversa
https://bugs.kde.org/show_bug.cgi?id=454772 Bug ID: 454772 Summary: Wishlist: Remember the setup when switching from ADF to flatbed and viceversa Product: Skanlite Version: 22.04.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kare.s...@iki.fi Reporter: sergio.calleg...@gmail.com Target Milestone: --- SUMMARY Currently Skanlite does not remember its setup when switching from flatbed to ADF mode and viceversa. For instance on my scanner (a multifunction HP device) when switching from flatbed to ADF the scan area size always switches to "custom" and the maximum available size. This is uncomfortable because often one finds him/her-self setting up everything to realize only at the last minute that the source was wrong and then fixing the ADF/flatbed source makes it necessary to re-enter the scan area. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 -- You are receiving this mail because: You are watching all bug changes.
[Skanlite] [Bug 454772] Wishlist: Remember the setup when switching from ADF to flatbed and viceversa
https://bugs.kde.org/show_bug.cgi?id=454772 Sergio changed: What|Removed |Added CC||sergio.calleg...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[Skanlite] [Bug 454776] New: Wishlist: let one control the file index start value and increment
https://bugs.kde.org/show_bug.cgi?id=454776 Bug ID: 454776 Summary: Wishlist: let one control the file index start value and increment Product: Skanlite Version: 22.04.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kare.s...@iki.fi Reporter: sergio.calleg...@gmail.com Target Milestone: --- SUMMARY Skanlite offers the possibility to name files automatically, including an index as in scan_.png where is a number. With the first save, it is possible to select the initial value. This is good, but IMHO it could be improved. Scenario: you have a non-duplex scanner and you want to scan multipage documents printed on both sides of the paper. Suppose you have 4 pages printed on both sides. You would like to set the initial index to something (say 0101) for the first scan, with a +2 increment, to scan all the odd pages, then you would like to turn the pages, re-feed then in the ADF, set the initial index to the correct value (0108) and the increment to -2, so that you can now scan the even pages and have the resulting files nicely ordered. The venerable `xsane` lets you do this, so skanlite should be no less ;-) What do you think? -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 454867] New: Cannot find cpu package temperature among monitored quantities
https://bugs.kde.org/show_bug.cgi?id=454867 Bug ID: 454867 Summary: Cannot find cpu package temperature among monitored quantities Product: plasma-systemmonitor Version: 5.24.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: ksysguard-b...@kde.org Reporter: sergio.calleg...@gmail.com CC: ahiems...@heimr.nl, plasma-b...@kde.org Target Milestone: --- SUMMARY Hi, from the sensors command I see that coretemp reports the temperature of the individual cores, plus the cpu package temperature. However it seems impossible to find the latter reported by ksystemstats. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 434922] plasma system-monitor not working properly on RPI4 and possibly other ARM systems
https://bugs.kde.org/show_bug.cgi?id=434922 Sergio changed: What|Removed |Added Summary|cpu load plasmoid remain|plasma system-monitor not |blank and cannot find |working properly on RPI4 |sensors |and possibly other ARM ||systems -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 454868] New: Wishlist: provide averaged values across cores for CPU temperatures and clock speeds
https://bugs.kde.org/show_bug.cgi?id=454868 Bug ID: 454868 Summary: Wishlist: provide averaged values across cores for CPU temperatures and clock speeds Product: plasma-systemmonitor Version: 5.24.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: ksysguard-b...@kde.org Reporter: sergio.calleg...@gmail.com CC: ahiems...@heimr.nl, plasma-b...@kde.org Target Milestone: --- SUMMARY With respect to CPU information, the system monitor can provide a lot of data on individual cpu cores. However, when you have many cores, seeing the per-core information is cumbersome and it would be nice to be able to see values averaged across cores. For instance, it would be nice to have an average core temperature or an average clock frequency as the older "system load" plasmoid based on ksysguard used to provide. Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.94.0 -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 454868] Provide averaged values across cores for CPU temperatures and clock speeds
https://bugs.kde.org/show_bug.cgi?id=454868 --- Comment #2 from Sergio --- Nice to hear that you can! It is just not obvious to me how to get a widget in the bottom panel showing me the average of the temperatures across the cores or the average clock speed. I am totally fine configuring it manually, but I'd be grateful if you could provide some hints. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 454868] Provide averaged values across cores for CPU temperatures and clock speeds
https://bugs.kde.org/show_bug.cgi?id=454868 --- Comment #4 from Sergio --- Sorry, I may be missing something. I have no Processes page or History Page. I would like to have a tiny widget in the bottom panel showing me the CPU temperature and clock frequency. Because these are per-core and because I do not want to have 8 indicators, I would like to have just a couple of little pie diagrams showing the core-averaged clock frequency and core-averaged cpu temp. -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 454868] Provide averaged values across cores for CPU temperatures and clock speeds
https://bugs.kde.org/show_bug.cgi?id=454868 --- Comment #5 from Sergio --- Created attachment 149536 --> https://bugs.kde.org/attachment.cgi?id=149536&action=edit Config window (what should I put here?) Here is the configuration window that I have. If I introduce the "group" information, then I get all the core temperature, but the text in the widget reports only the temperature of the first core. -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 454868] Provide averaged values across cores for CPU temperatures and clock speeds
https://bugs.kde.org/show_bug.cgi?id=454868 --- Comment #7 from Sergio --- Do not forget the "averaged" clock speed... thanks! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 454988] New: (Older?) widgets in the panel make plasmashell misbehave
https://bugs.kde.org/show_bug.cgi?id=454988 Bug ID: 454988 Summary: (Older?) widgets in the panel make plasmashell misbehave Product: plasmashell Version: 5.24.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: sergio.calleg...@gmail.com CC: niccolo.venera...@gmail.com Target Milestone: 1.0 SUMMARY I am trying to use the system load viewer widget (https://store.kde.org/p/1474921). This is indicated as usable in plasma <=5.20 because it relies on ksysguard that is phased out. However, arch and manjaro provide ksysguard with plasma 5.24.5 and the widget seems to actually work. What is strange is that the widget causes weird issues with the rest of plasma: - Often at startup the system does not load the background image if the widget is on the panel. Restarting the plasmashell causes the background image to load correctly; - The "add widget" action stops working if the widget is in the panel. No left area with the available widgets is shown. All this is not nice. Either, plasmashell should refuse to install code for a widget that is not supported or, if it allows installing a widget then it should not misbehave in these weird ways. STEPS TO REPRODUCE 1. Add widget 2. Download and install widget "System load viewer" 3. Add widget to the bottom panel 4. log out and log in again 5. Try "add widget"... It does not work. OBSERVED RESULT Adding the widget to the panel causes weird and apparently unrelated faults in plasma. EXPECTED RESULT Plasma should either refuse to install a widget or provide some error info if a widget misbehaves, but should not behave itself erratically because of a widget that may be coded according to older standards. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 454868] Provide averaged values across cores for CPU temperatures and clock speeds
https://bugs.kde.org/show_bug.cgi?id=454868 --- Comment #8 from Sergio --- To give you some more context: I am trying to use the widgets working with the new framework to provide the same kind of info that I was getting with the older "system load view" widget plus the older "thermal monitor" widgets. - bar or pie diagram with User/Iowait/System/Nice Cpu usage - bar or pie diagram with application and buffer memory usage - bar or pie diagram with Swap memory usage - bar or pie diagram with dirty cache and writeback memory usage - Indicator of the CPU temperature In this regards note that the "System load view" also gives the averaged clock frequency when hovering on it with the mouse and that the thermal monitor provides more thermal sensors than the new framework (e.g. CPU package temp). -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 367959] Okular mangles some characters (non embedded fonts)
https://bugs.kde.org/show_bug.cgi?id=367959 --- Comment #18 from Sergio --- OK also here: Linux with okular 22.04.1 and poppler 22.05.0 (from Manjaro packages). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 454988] (Older?) widgets in the panel make plasmashell misbehave
https://bugs.kde.org/show_bug.cgi?id=454988 --- Comment #2 from Sergio --- I understand (correct me if I am wrong) that widgets are run in the same process as plasmashell for efficiency reason and that this requires a good behavior on the widget side as in any form of cooperative multitasking. Widgets that hang result in the shell hanging and widgets that crash result in the shell crashing. This is all fine as long as you are dealing with widgets that are developed together with the shell, but may become critical for third party widgets because the shell has, as you say, no possibility to do anything if the widget misbehaves. For this reason, maybe it would be preferable/safer to pay an efficiency price for the third party widgets and have them run in their own process with just a proxy in the plasma shell process. As a minor safeguard, it would be good to at least ask to the widget developers to include a "manifest" indicating the versions of plasma the widget has been tested on, in order to make running untested widgets a bit more difficult (e.g. for cases with a version mismatch, one needs to explicitly opt in to test the widget, that is run it until the next login, or forever). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463088] [Wayland] Pointer confinement not working with subsurfaces
https://bugs.kde.org/show_bug.cgi?id=463088 Sergio changed: What|Removed |Added CC||sergio.g.delr...@gmail.com --- Comment #2 from Sergio --- Still an issue in 5.26.90. It might be easier to reproduce using the following sample client in the Weston project: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1164 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 467328] New: Okular mismanages fonts embedded in PDF document when printing
https://bugs.kde.org/show_bug.cgi?id=467328 Bug ID: 467328 Summary: Okular mismanages fonts embedded in PDF document when printing Classification: Applications Product: okular Version: 22.12.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: PDF backend Assignee: okular-de...@kde.org Reporter: sergio.calleg...@gmail.com Target Milestone: --- I am encountering issues trying to use Okular because it visualizes documents correctly, but it corrupts them when printing. This happens only with certain PDF documents that embed fonts. A typical case is represented by documents generated by Libreoffice using the Source Sans 3 OTF font from Adobe. When I open these PDF files in okular they display correctly. However, when I try to print them the font becomes unreadable. If I send the same file directly to the printer using the `lp` command, then it prints just fine. Interestingly, also the *print preview* produced by Okular shows the font breakage. I am attaching a test document to be used with the following steps to reproduce. STEPS TO REPRODUCE 1. Open the test document, see it is shown correctly on screen 2. File->Print preview, in the preview the font is unreadable 3. File->Print, in the printout the font is unreadable OBSERVED RESULT In the print preview and in the printout the font is unreadable EXPECTED RESULT The print out should match what is displayed on screen SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.12-1-MANJARO (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-4750HQ CPU @ 2.00GHz Memory: 15.5 GiB of RAM Graphics Processor: Mesa Intel® Iris® Pro Graphics P5200 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 467328] Okular mismanages fonts embedded in PDF document when printing
https://bugs.kde.org/show_bug.cgi?id=467328 --- Comment #1 from Sergio --- Created attachment 157270 --> https://bugs.kde.org/attachment.cgi?id=157270&action=edit Test document -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 467328] Okular mismanages fonts embedded in PDF document when printing
https://bugs.kde.org/show_bug.cgi?id=467328 --- Comment #2 from Sergio --- Created attachment 157271 --> https://bugs.kde.org/attachment.cgi?id=157271&action=edit Screenshot of print preview >From the screenshot it is quite evident that the document displays correctly (bottom window), but is not previewed correctly (window on top, where the text is unreadable). Printing the document produces what is shown in the preview window. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 467328] Okular mismanages fonts embedded in PDF document when printing
https://bugs.kde.org/show_bug.cgi?id=467328 --- Comment #3 from Sergio --- Qpdfview can print the PDF document just fine. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 467328] Okular mismanages fonts embedded in PDF document when printing
https://bugs.kde.org/show_bug.cgi?id=467328 --- Comment #5 from Sergio --- @Oliver Sanders > (In reply to Oliver Sander from comment #4) > Printing in Okular is a bit special. > > I conjecture that you can print your document if you select the 'force > rasterization' option in the print dialog. Your conjecture is correct. Even if this workaround is effective, I think that this issue deserves attention: - first, forcing rasterization does not fix the wrong preview; - secondly, one typically works with force rasterization off (also because it can slow things down in some cases and I am not sure whether it can affect the printout quality in some cases). It is not nice when you discover that you have printed 200 bad pages that you should have forced rasterization; - thirdly, in some occasions the issue is subtle. Here, I have managed crafting a PDF where all the characters get substituted by little squares when printing, which make the bug quite detectable. However, in some cases out of a multipage document you end up only missing a word on a single page or a few characters here and there. It is very easy to miss the issue and pass around an unprofessionally looking document or even signing an incomplete document; - finally, due to the complexity of the PDF standard issues like this one tend to make one doubt the correctness of the original PDF. Is it OK or slightly out of specs, so that some viewer can print it and some other cannot? Unfortunately, this issue has already prompted the opening of inquires on the Libreoffice tracker and the Source Sans 3 font tracker. Out of curiosity, in what sense printing in Okular is a bit special? In cases where rasterization is not explicitly required, cannot the PDF be passed to the printing subsystem more or less as is? -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 467328] Okular mismanages fonts embedded in PDF document when printing
https://bugs.kde.org/show_bug.cgi?id=467328 --- Comment #7 from Sergio --- (In reply to Oliver Sander from comment #6) > I fully agree that `force rasterization` is only a workaround. > > Okular currently converts pdf files to postscript and sends that to the > printer (I forgot why exactly). Presumably it is the conversion step that > goes wrong in your case. Most likely the issue is indeed in this conversion. Noticed that if you pre-process the PDF via a pdf-to-pdf conversion via Ghostscript (which most likely results in a simpler PDF) then the PDF prints fine. For sure the PDF to PDF conversion via ghostscript changes the way in which the fonts are embedded because the `pdffonts` utility returns different results. I wonder if the conversion is related to the need to select page ranges or to do page scaling, but both things should be manageable at the PDF level. Or if it is needed by non-CUPS platforms (windows) where PDF might not be the "standard" way of describing the page for printing. If you want to have a look at the code: That's at > `generator_pdf.cpp:1366`. > There used to be a patch that made Okular send the pdf file straight to the > printer, but I can't seem to find it right now. Resurrecting this patch might have good potential! > And then there's the official Qt way of printing: Render everything to a > `QPrinter` object. Code for that is at > https://invent.kde.org/graphics/okular/-/merge_requests/411 , but that has > its own set of problems. I had a look at it, but I am not sure I fully understand. If I get it correctly, the QPrinter object is an object you paint onto (sort of QPainter?). So if you have an application that wants to draw something meant to be printed you do that on the QPrinter object and in this way you get something that is printable. However, in case of a PDF document this seems a bit redundant and prone to be lossy: first you paint the PDF on the QPrinter object and then the QPrinter object converts its content back to PDF for printing (at least on CUPS platforms). I understand that the set of problems you mention are indeed a consequence of the first conversion. Maybe if Qtpdfium grows a PDF->Qpainter rendering path that might overcome some of the limitations of the poppler rendering path, but still the QPrinter route appears to me as not the most efficient one. For complex PDFs it could also slow things down a bit. Is my understanding correct? -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 467328] Okular mismanages fonts embedded in PDF document when printing
https://bugs.kde.org/show_bug.cgi?id=467328 --- Comment #8 from Sergio --- A few more questions: 1) Is the conversion to ps currently done by poppler? I see a Poppler::PSConverter object being used. If so, regardless of the conveniency of practicing the intermediate postscript conversion is there a poppler bug ultimately? Should an issue be opened with them? 2) when you ask for the rasterization, is the rasterization always happening at 300x300 dpi in unix regardless of the printer resolution? I see mention to a discussion at https://git.reviewboard.kde.org/r/130218/, but that site is dead. Thanks again! -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 467328] Okular mismanages fonts embedded in PDF document when printing
https://bugs.kde.org/show_bug.cgi?id=467328 --- Comment #9 from Sergio --- I have opened a request for feedback or for participation in the discussion on the poppler tracker: https://gitlab.freedesktop.org/poppler/poppler/-/issues/1377 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 467328] Okular mismanages fonts embedded in PDF document when printing
https://bugs.kde.org/show_bug.cgi?id=467328 --- Comment #11 from Sergio --- (In reply to Albert Astals Cid from comment #10) > > Okular currently converts pdf files to postscript and sends that to the > > printer (I forgot why exactly). > > Because thousands of years ago printing PDF files directly was not something > that worked. So, would resurrecting the patch mentioned by Oliver be the best option as of today? As long as there is the intermediate postscript conversion, do you thing that the observed behavior is indeed a poppler bug (i.e., that https://gitlab.freedesktop.org/poppler/poppler/-/issues/1377 is a bug?) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 459107] New: Applications closed in maximized state are then opened as small as possible
https://bugs.kde.org/show_bug.cgi?id=459107 Bug ID: 459107 Summary: Applications closed in maximized state are then opened as small as possible Product: kwin Version: 5.24.6 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: core Assignee: kwin-bugs-n...@kde.org Reporter: sergio.calleg...@gmail.com Target Milestone: --- SUMMARY The issue is quite visible with libreoffice, but also happens with other applications. If you open a libreoffice application (say calc), then maximize it, then close it, when you open the same application again the application window is made as small as possible. For libreoffice, this means an almost invisible window. You need to go to the application in the taskbar, right click, click "more" and from there resize or maximize again the window to make it visible. Conversely, if you open a libreoffice app (again, say calc), then resize it to some size (not the maximum one!), close the application and launch it again, then the window is reopened at the same size it had when it was closed, that seems totally reasonable. STEPS TO REPRODUCE Follow the instructions in the summary. OBSERVED RESULT In many cases, application windows are opened at the smallest possible size, that is often so small that you cannot even see the window. This is quite confusing to inexperienced users and hinders usability. EXPECTED RESULT All applications should open at reasonable window sizes, typically as they were closed. SOFTWARE/OS VERSIONS Operating System: Kubuntu 22.04 KDE Plasma Version: 5.24.6 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.3 Kernel Version: 5.15.0-47-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-10510U CPU @ 1.80GHz Memory: 15,3 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 459107] Applications closed in maximized state are then opened as small as possible
https://bugs.kde.org/show_bug.cgi?id=459107 --- Comment #3 from Sergio --- Weird, seems to happen with Libreoffice 7.4 but not with 7.3.x... but how can this be a bug in the application? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 459107] Applications closed in maximized state are then opened as small as possible
https://bugs.kde.org/show_bug.cgi?id=459107 --- Comment #5 from Sergio --- I have never touched this: how do you change the decoration border settings? For what concerns the window rules: - I have one assuring that firefox and thunderbird always open in virtual desktop 4; - I used to have nothing else, but now I am setting a minimum size for LibO, to avoid getting windows that are so small that they are invisible in the top left corner. Any clue about the fact that I see this issue with LibO 7.3 but not LibO 7.4? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 459107] Applications closed in maximized state are then opened as small as possible
https://bugs.kde.org/show_bug.cgi?id=459107 --- Comment #9 from Sergio --- Here is the file: [$Version] update_info=kwinrules.upd:replace-placement-string-to-enum,kwinrules.upd:use-virtual-desktop-ids [1] Description=Application settings for libreoffice-calc clientmachine=localhost clientmachinematch=0 desktop=4 desktoprule=3 desktops=1975fa63-fe75-4993-9881-a378c12b056c minsize=800,600 minsizerule=2 wmclass=libreoffice libreoffice-calc wmclasscomplete=true wmclassmatch=1 [2] Description=Application settings for libreoffice-startcenter clientmachine=localhost clientmachinematch=0 desktop=4 desktoprule=3 desktops=1975fa63-fe75-4993-9881-a378c12b056c minsize=800,600 minsizerule=2 wmclass=libreoffice libreoffice-startcenter wmclasscomplete=true wmclassmatch=1 [3] Description=Application settings for thunderbird clientmachine=localhost desktops=1975fa63-fe75-4993-9881-a378c12b056c desktopsrule=2 wmclass=mail thunderbird wmclasscomplete=true wmclassmatch=1 [319f7847-e3a0-4190-a1ad-d705a3a025d9] Description=Application settings for libreoffice-startcenter clientmachine=localhost minsize=800,600 minsizerule=2 wmclass=libreoffice libreoffice-startcenter wmclasscomplete=true wmclassmatch=1 [384731b6-981a-4110-8dae-c2bbf8e1aa65] Description=Application settings for libreoffice-calc clientmachine=localhost minsize=800,600 minsizerule=2 wmclass=libreoffice libreoffice-calc wmclasscomplete=true wmclassmatch=1 [4] Description=Application settings for firefox clientmachine=localhost desktops=1975fa63-fe75-4993-9881-a378c12b056c desktopsrule=2 wmclass=navigator firefox wmclasscomplete=true wmclassmatch=1 [5ebfc235-f760-45f2-ae41-0c9b79f3ef5c] Description=Application settings for thunderbird clientmachine=localhost desktops=1975fa63-fe75-4993-9881-a378c12b056c desktopsrule=2 wmclass=mail thunderbird wmclasscomplete=true wmclassmatch=1 [83c87e6b-35b3-4ff5-b5f7-9ca7529e8b3f] Description=Application settings for firefox clientmachine=localhost desktops=1975fa63-fe75-4993-9881-a378c12b056c desktopsrule=2 wmclass=navigator firefox wmclasscomplete=true wmclassmatch=1 [General] count=4 rules=1,2,3,4 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 469192] Plasmashell frequently starts up with no background image or desktop icons until plasmashell is restarted.
https://bugs.kde.org/show_bug.cgi?id=469192 --- Comment #6 from Sergio --- Not a bad cable. As a matter of fact, I perfectly see the sddm screen on the monitor and logging in I see the plasma screen. Simply, when the issue occurs, I see the plasma screen with no "desktop" (no wallpaper image, no desktop folder view, only a large black region). This happens more frequently when — with one user logged in — I switch to another user. Pressing ALT-F2 to get the krunner and entering `plasmashell --replace` plasma restarts just fine. All this makes me thing of a 'race' or a timing issue wrt the startup phase of plasma. I see the issue: - on a laptop machine that is not so recent by today's standard, with haswell i7-4750HQ and a graphics unit that is not a workhorse (Intel Crystal Well Integrated Graphics Controller, rev 08); - using an attached monitor, so that the attached screen is primary and the laptop screen is disabled. Wonder if this specific configuration may have a relation with the issue. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 469192] Plasmashell frequently starts up with no wallpaper (black background) nor desktop folder view until plasmashell is restarted.
https://bugs.kde.org/show_bug.cgi?id=469192 Sergio changed: What|Removed |Added Summary|Plasmashell frequently |Plasmashell frequently |starts up with no |starts up with no wallpaper |background image or desktop |(black background) nor |icons until plasmashell is |desktop folder view until |restarted. |plasmashell is restarted. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 469192] Plasmashell frequently starts up with no wallpaper (black background) nor desktop folder view until plasmashell is restarted.
https://bugs.kde.org/show_bug.cgi?id=469192 Sergio changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 469192] New: Plasmashell frequently starts up with no background image, no desktop icons
https://bugs.kde.org/show_bug.cgi?id=469192 Bug ID: 469192 Summary: Plasmashell frequently starts up with no background image, no desktop icons Classification: Plasma Product: plasmashell Version: 5.27.4 Platform: Manjaro OS: Linux Status: REPORTED Severity: major Priority: NOR Component: Startup process Assignee: plasma-b...@kde.org Reporter: sergio.calleg...@gmail.com CC: k...@davidedmundson.co.uk Target Milestone: 1.0 SUMMARY On a system with the following setup - Intel haswell laptop with integrated graphics - Using X11 - External monitor attached and set as primary monitor - Built in screen set as not enabled I frequently have the following issue. When a user logs in at the sddm screen, plasma starts. However, it fails to set the background image (I get a black background) and to load the desktop icons. The bottom panel is displayed, though. As a workaround I can press ALT-F2 get the runner, type `plasmashell --replace` and with this plasma always restarts correctly. The issue is frequently seen (much more frequently, I would say) when switching to a second user. I have been seeing this issue since Manjaro switched to plasma 5.27 or possibly even earlier. This issue is just a minor nuisance to expert users who know how to restart plasma, but a total showstopper for users without this knowledge. STEPS TO REPRODUCE 1. log in at sddm OBSERVED RESULT Plasma frequently starts failing to load the desktop barground and the desktop icons EXPECTED RESULT Plasma should start correctly. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.12-1-MANJARO (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-4750HQ CPU @ 2.00GHz Memory: 15.5 GiB of RAM Graphics Processor: Mesa Intel® Iris® Pro Graphics P5200 Manufacturer: Notebook Product Name: W740SU System Version: Not Applicable -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 469192] Plasmashell frequently starts up with no background image, no desktop icons
https://bugs.kde.org/show_bug.cgi?id=469192 --- Comment #3 from Sergio --- I do not think that my issue is related to the migration of old desktop settings. Actually, I am seeing this issue way more frequently with a new user that I have created on my system, that should have everything set up via the new defaults. If I open the "Manage Desktops and Panels" configuration utility, everything is correct. And in fact, when I get the "black screen" doing ALT-F2 and then `plasmashell --replace` in the runner fixes everything. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 460584] New: Cannot explore smb shares with dolphin unless default username and passwords are set
https://bugs.kde.org/show_bug.cgi?id=460584 Bug ID: 460584 Summary: Cannot explore smb shares with dolphin unless default username and passwords are set Classification: Applications Product: dolphin Version: 22.04.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: sergio.calleg...@gmail.com CC: kfm-de...@kde.org Target Milestone: --- SUMMARY Trying to explore smb shares with dolphin (and kio) invariably results in a message that the folder does not exist, unless you had previously set a default user and password from the settings in Settings->Network->Window shares. This is not sensible and represents a regression with respect to previous times when dolphin was asking for a username and password when needed to open smb shares. Even worse, this makes no sense when the URL passed to dolphin *contains* the username. Even even worse, when you have a desktop link for the share and you click on it, if the default username/password is not set in settings for the Window shares, nothing happens and you get zero feedback on what had gone wrong. I have managed finding my way in this issue thanks to https://www.reddit.com/r/kde/comments/tz3ysq/dolphin_cant_resolve_samba_shares/ that documents the problem. SOFTWARE/OS VERSIONS Operating System: Kubuntu 22.04 KDE Plasma Version: 5.24.7 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.3 Kernel Version: 5.15.0-50-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-10510U CPU @ 1.80GHz Memory: 15,3 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 464659] New: Screen does not lock automatically when certain chrome/chromium tabs are open
https://bugs.kde.org/show_bug.cgi?id=464659 Bug ID: 464659 Summary: Screen does not lock automatically when certain chrome/chromium tabs are open Classification: Plasma Product: kscreenlocker Version: 5.26.4 Platform: Manjaro OS: Linux Status: REPORTED Severity: major Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: sergio.calleg...@gmail.com Target Milestone: --- SUMMARY Screen does not lock automatically when certain chrome/chromium tabs are open (e.g. when playing media). This may represent a security issue. For some this may be a feature (e.g. if you are playing a video, you may not want your machine to lock). However, in many cases it is a serious security issue. For example: you are listening to music, you must leave the machine for a moment, something ends up preventing you from going back to the machine for a longer time than expected, you feel safe supposing that your machine will anyway be autolocked and the machine may remain with your session open and usable by anyone (to read your data including sensitive info or to do something malicious) forever. This is something that should most definitely made at least configurable. Furthermore, there is really no reason why merely listening to audio should prevent the machine from autolocking, since screen locking does not prevent audio from being heard. STEPS TO REPRODUCE 1. Open your email client, start reading email 2. Open chromium 3. Go to spotify and start playing a song 4. Leave the machine alone for 2 hours OBSERVED RESULT After two hours anyone passing by will be able to read your email or to send email under your name. EXPECTED RESULT The machine should autolock, you are merely playing audio. If there are technical difficulties in distinguishing whether the machine that is playing media is playing just audio or also video, it should be possible to configure it so that media playing cannot inhibit screen auto lock. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Kernel Version: 6.1.1-arch1-1.2 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 464659] Screen does not lock automatically when certain chrome/chromium tabs are open
https://bugs.kde.org/show_bug.cgi?id=464659 --- Comment #1 from Sergio --- This has also been reported to arch: https://bbs.archlinux.org/viewtopic.php?id=234007 And to ubuntu https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1600622 (not specific to plasma) -- You are receiving this mail because: You are watching all bug changes.
[Skanlite] [Bug 488716] New: Wishlist: configurable incrementor for file naming
https://bugs.kde.org/show_bug.cgi?id=488716 Bug ID: 488716 Summary: Wishlist: configurable incrementor for file naming Classification: Applications Product: Skanlite Version: 24.05.0 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: kare.s...@iki.fi Reporter: sergio.calleg...@gmail.com Target Milestone: --- SUMMARY Skanlite is capable of auto-naming files resulting from scanning multiple pages by adding a numeric suffix to a file-name prefix (e.g. `scan_page-.png`). Would be great if the numeric suffix could be updated based on a user-specified increment and a user specified start value rather than using "+1" and the current value only. Rationale: 1) Most home users can only afford non-duplex automatic document feeders in their scanners. With these you need to first scan the odd pages, then turn around the page-pack and scan the even ones. If you want to have the files corresponding to the pages correctly numbered and you have *n* pieces of paper, corresponding to 2n pages, then you should first do the odd sides using increment +2 and start value m, then the even ones using increment -2 and start value m+2n-1. 2) Most home users can only afford cheap automatic document feeders that often pick up two pages at once. When you realize it and you scan again the missing page, you would like the corresponding file to be sorted correctly with the others. In order to be able to do so, you need to do the initial scan with an increment that "leaves space" to insert missing pages (e.g., +10). The venerable "xsane" supports these usage cases, but being basically unmaintained it feels more and more out of place in a modern desktop. Having skanlite on feature parity with it is important to provide a full replacement. -- You are receiving this mail because: You are watching all bug changes.
[okteta] [Bug 336936] Okteta's window is too tall in windowed mode
https://bugs.kde.org/show_bug.cgi?id=336936 Sergio changed: What|Removed |Added CC||sergio.calleg...@gmail.com --- Comment #8 from Sergio --- This still happens with Okteta 0.26.13 almost 10 years after the original bug report. There are also many similar issues in the tracker closed as "resolved worksforme" or similar. Guess it is a feature. Still makes the app feel completely out of place in plasma. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 478643] New: Disk and Devices applet shows encrypted volumes even if they are marked for being ignored
https://bugs.kde.org/show_bug.cgi?id=478643
Bug ID: 478643
Summary: Disk and Devices applet shows encrypted volumes even
if they are marked for being ignored
Classification: Plasma
Product: plasmashell
Version: 5.27.10
Platform: Manjaro
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Disks & Devices
Assignee: plasma-b...@kde.org
Reporter: sergio.calleg...@gmail.com
Target Milestone: 1.0
SUMMARY
Volumes marked for being ignored by udev/udisks2 (i.e., with the HintIgnore
attribute set) should not be shown/managed by the Disks and Devices applet.
However, in some cases this does not happen and the volumes are improperly
shown (even when dolphin does not show them).
Setup in which this occurs is related to the use of LUKS disk encryption and is
probably not extra frequent, but can be increasingly important given that the
usage of disk encryption is on the rise.
I have a laptop (in fact a 2-in-1) with a very small internal NVME used to
store the main OS, while all the rest (and particularly the home dir(s) ) go on
a large SD card. For safety, the SD card is encrypted. At boot the OS learns
about it via `crypttab` , asks for a password to decrypt it and mounts it. So
far so good.
The issue is that in plasma the Disks and Devices applet keeps showing it as a
removable device (reported as "Encrypted Drive" rather than by the volume
label), providing just the option to "safely remove" it, which obviously can
only fail since the device is in use.
This happens even if the volume is marked for being ignored via a udev rule. In
fact, it does not matter whether the upper (crypted) device is marked, the
lower (decrypted) device is or both. The fact that the udev rule works
correctly can be checked with the udisks2 dbus interface and also via
`solid-hardware5 list details` that reports for both the block devices that the
`StorageAccess.ignored` and `StorageVolume.ignored` properties are true.
Interestingly, these properties correctly prevent the block device from being
shown in a "Removable devices" section in dolphin, though.
STEPS TO REPRODUCE
1. Have an external drive (usb, sd, etc.) encrypted with LUKS
2. Set an appropriate `crypttab` to decrypt it at boot and an `fstab` to mount
the decrypted volume
3. Write in `\etc\udev\rules.d` some rules to assure that
`ENV{UDISKS_IGNORE}="1"` for the upper and lower devices
4. Login in plasma
OBSERVED RESULT
The Disks and Devices icon is shown in the system tray. Clicking on it shows an
"Encrypted Drive" as a removable device and offers the option to "Safely
remove" it.
EXPECTED RESULT
No "Encrypted Drive" is shown because udisks2 has the Ignore Hint set for it.
SOFTWARE/OS VERSIONS
Operating System: Manjaro Linux
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.112.0
Qt Version: 5.15.11
Kernel Version: 6.6.7-1-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-4750HQ CPU @ 2.00GHz
Memory: 15.5 GiB of RAM
Graphics Processor: Mesa Intel® Iris® Pro Graphics P5200
Manufacturer: Notebook
Product Name: W740SU
System Version: Not Applicable
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 478643] Respect HintIgnore udev flag to hide disks that the user wants to be hidden
https://bugs.kde.org/show_bug.cgi?id=478643 --- Comment #1 from Sergio --- Noticed the title change. I'm under the impression that my volume used to be correctly ignored before I encrypted it, i.e., that there is a problem specifically with encrypted volumes. Maybe wrong. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 482452] New: Wallpaper all of a sudden becomes incorrectly sized
https://bugs.kde.org/show_bug.cgi?id=482452 Bug ID: 482452 Summary: Wallpaper all of a sudden becomes incorrectly sized Classification: Plasma Product: kwin Version: 5.27.10 Platform: Manjaro OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: sergio.calleg...@gmail.com Target Milestone: --- SUMMARY While one works, all of a sudden the display wallpaper become incorrectly sized and too small, occupying only the top left corner of the screen, leaving a black area to the right and to the bottom. I am experiencing this on an arch derivative (Manjaro) that being a rolling distro should be completely up to date wrt Plasma components. The setup uses Wayland. The problem occurs using 2 screens (laptop screen + external monitor), using the external monitor as primary, when the external monitor has a very high resolution (4k). Both screens use scaling for HiDPI (the external monitor, being very large, employs a more moderate scaling), but I do not know how relevant this may be. I have been unable to understand what triggers the problem. When you connect the monitor, everything is fine. As you work all of a sudden the background flashes and becomes too small. Disconnecting and reconnecting the monitor or changing its resolution from the control panel to then revert it back fixes the issue. Don't know how important this issue is as of today, since I cannot test on plasma 6 yet. STEPS TO REPRODUCE Unfortunately the issue is erratic and a proper way to reproduce has not been identified. OBSERVED RESULT All of a sudden the wallpaper becomes smaller than the screen estate and top left aligned, leaving a black area to the right and to the bottom. EXPECTED RESULT The wall paper remains OK. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.12 Kernel Version: 6.7.4-2-MANJARO (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 9 6900HS with Radeon Graphics Memory: 30.6 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: ASUSTeK COMPUTER INC. Product Name: ROG Zephyrus G14 GA402RK_GA402RK System Version: 1.0 -- You are receiving this mail because: You are watching all bug changes.
[kdiff3] [Bug 487338] Floating point exception: 8
https://bugs.kde.org/show_bug.cgi?id=487338 Sergio changed: What|Removed |Added CC||sergio.calleg...@gmail.com --- Comment #1 from Sergio --- This is not just MacOS. Same issue on Manjaro Linux. Most likely a regression, since I think that kdiff3 was working fine until not long ago. Seen with Operating System: Manjaro Linux KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 Kernel Version: 6.9.2-1-MANJARO (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 9 6900HS with Radeon Graphics Memory: 30.6 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: ASUSTeK COMPUTER INC. Product Name: ROG Zephyrus G14 GA402RK_GA402RK System Version: 1.0 Application reports org.kde.kdiff3: Diff: A <-> B org.kde.kdiff3: Linediff: A <-> B org.kde.kdiff3: Enter: calcDiff3LineListUsingAB org.kde.kdiff3: Leave: calcDiff3LineListUsingAB Floating point exception (core dumped) -- You are receiving this mail because: You are watching all bug changes.
[kdiff3] [Bug 487338] Possible regression: Floating point exception
https://bugs.kde.org/show_bug.cgi?id=487338 Sergio changed: What|Removed |Added Summary|Floating point exception: 8 |Possible regression: ||Floating point exception -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kxmlgui] [Bug 482240] "Launch Bug Report Wizard" does nothing
https://bugs.kde.org/show_bug.cgi?id=482240 Sergio changed: What|Removed |Added CC||sergio.calleg...@gmail.com --- Comment #4 from Sergio --- Still an issue on current Manjaro: Operating System: Manjaro Linux KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 Kernel Version: 6.9.2-1-MANJARO (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 9 6900HS with Radeon Graphics Memory: 30.6 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: ASUSTeK COMPUTER INC. Product Name: ROG Zephyrus G14 GA402RK_GA402RK System Version: 1.0 The issue is present in all KDE applications. Seems a regression to me since the Launch Bug Report Wizard was correctly starting the browser with a partially prefilled bug report until recent. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 487916] New: Regressions in baloo in kf6 cause it to hog the machine
https://bugs.kde.org/show_bug.cgi?id=487916 Bug ID: 487916 Summary: Regressions in baloo in kf6 cause it to hog the machine Classification: Frameworks and Libraries Product: frameworks-baloo Version: 6.0.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Baloo File Daemon Assignee: baloo-bugs-n...@kde.org Reporter: sergio.calleg...@gmail.com Target Milestone: --- SUMMARY Baloo appears to be in very bad shape in KF6. It was working oK until I updated to plasma 6. I am encountering the following issues: - Machine at startup is completely unresponsive: baloo_file is saturating the I/O bandwidth, top reports that the machine is fundamentally just waiting for I/O. - Running `balooctl6` shows baloo "Checking for unindexed files" - Trying `balooctl6 suspend` does nothing - Trying `balooctl6 disable` causes `balooctl6 status` to show baloo as not running, but the `baloo_file` process remains around hogging the machine. STEPS TO REPRODUCE 1. Reboot and login OBSERVED RESULT The machine hardly crawls. Getting a cursor on the terminal takes a long time. System load shows huge "wait time" and no system/user time. `balooctl6 disable` leaves resource hogging baloo_file process around. EXPECTED RESULT Baloo makes a limited and fair use of the machine resources, balooctl6 can actually suspend, resume and disable baloo. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 Kernel Version: 6.6.32-1-MANJARO (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-4750HQ CPU @ 2.00GHz Memory: 15.5 GiB of RAM Graphics Processor: Mesa Intel® Iris® Pro Graphics P5200 Manufacturer: Notebook Product Name: W740SU -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 487916] Regressions in baloo in kf6 cause it to hog the machine
https://bugs.kde.org/show_bug.cgi?id=487916 Sergio changed: What|Removed |Added Version|6.0.0 |6.2.0 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 487916] Regressions in baloo in kf6 cause it to hog the machine
https://bugs.kde.org/show_bug.cgi?id=487916 Sergio changed: What|Removed |Added Platform|Other |Manjaro -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 487916] Regressions in baloo in kf6 cause it to hog the machine
https://bugs.kde.org/show_bug.cgi?id=487916 --- Comment #2 from Sergio --- Reeboted to make sure everything is clear. Before the reboot baloo was using 0% I/O. Then tried ``` systemctl --user status kde-baloo ● kde-baloo.service - Baloo File Indexer Daemon Loaded: loaded (/usr/lib/systemd/user/kde-baloo.service; disabled; preset: enabled) Active: active (running) since Mon 2024-06-03 09:09:49 CEST; 1min 7s ago Process: 1618 ExecCondition=/usr/bin/kde-systemd-start-condition --condition baloofilerc:Basic Settings:Indexing-Enabled:true (code=exited, status=0/SUCCE> Main PID: 1629 (baloo_file) Tasks: 3 (limit: 19061) Memory: 249.1M (high: 512.0M available: 262.8M peak: 249.2M) CPU: 2.458s CGroup: /user.slice/user-1000.slice/user@1000.service/background.slice/kde-baloo.service └─1629 /usr/lib/kf6/baloo_file Jun 03 09:09:49 zagar systemd[1468]: Starting Baloo File Indexer Daemon... Jun 03 09:09:49 zagar systemd[1468]: Started Baloo File Indexer Daemon. ``` Indeed it is limited to 512MB. Why does it say "disabled", though? If it is disabled why is it starting and how? At this point I am over 5 minutes after the boot. `baloo_file` is still hogging the I/O. Now about 10 minutes after the boot. `baloo_file` has finally calmed down. In many occasions it took much more. For these first 10' the machine has been hardly usable. This was not happening before my distro updated to plasma 6 (maybe bringing many other changes together with that, which may be the actual cause of what I am observing). Index file is very small: ``` Total files indexed: 382,267 Files waiting for content indexing: 0 Files failed to index: 0 Current size of index is 238.11 MiB ``` Home is on rotating HD and btrfs. Probably no one is anymore testing on rotating HDs, but they are still around. >From a usability point of view, two aspects are IMHO of concern: 1. `balooctl6 suspend` seems to do nothing at all. 2. `balooctl6 disable` sets baloo to be disabled, but does not stop `baloo_file` at all. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 487916] Regressions in baloo in kf6 cause it to hog the machine
https://bugs.kde.org/show_bug.cgi?id=487916 --- Comment #4 from Sergio --- > If you reboot now, has baloo_file done its work or does it still take time? I see the issue every time I restart the system. For sure when I reboot, most likely (I'll check again) even when I logout and login again. Baloo_file hogs the machine for some time. The first time it was huge, after that first time it is about 5-10'. > You can adjust the amount of RAM with >systemctl --user edit kde-baloo > and you can change the "MemoryHigh=512M" to something like "MemoryHigh=25%", > that will give Baloo more breathing room but not allow it to starve other > processes of memory. The 512MB might be too tight. I can try that, but baloo does not seem to be under memory pressure. My set of indexed files is actually not that big. Furthermore, systemd always reports a memory usage well below the limit (`Memory: 249.1M (high: 512.0M available: 262.8M peak: 249.2M)`). > These work "by asking" Baloo to stop rather than killing it. If Baloo is busy > it does not always listen :-/ Even when busy, baloo should probably try to be a better listener ;-). The issue is that right after boot things like giving a presentation are sort of impossible unless you kill `baloo_file` the hard way, which is not really nice. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 487916] Regressions in baloo in kf6 cause it to hog the machine
https://bugs.kde.org/show_bug.cgi?id=487916 --- Comment #7 from Sergio --- Is there a way to force baloo_file to show what it is actually doing at some given time? E.g., by some option, via dbus, or sending a user signal? -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 421186] Android and Plasma is not communicating on phone's portable WiFi HOTSPOT
https://bugs.kde.org/show_bug.cgi?id=421186 Sergio changed: What|Removed |Added CC||sergio.calleg...@gmail.com --- Comment #8 from Sergio --- Seems the same issue as in bug 450101 -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 421186] Android and Plasma is not communicating on phone's portable WiFi HOTSPOT
https://bugs.kde.org/show_bug.cgi?id=421186 --- Comment #9 from Sergio --- And also seems the same issue as in 451154 -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 421186] Android and Plasma is not communicating on phone's portable WiFi HOTSPOT
https://bugs.kde.org/show_bug.cgi?id=421186 --- Comment #10 from Sergio --- Now, really, this is a major usability impairment, since it makes it impossible to make the PC and mobile phone communicate when your only option to connect the PC to the internet is the mobile phone! In this context, KDE connect would also be useful to display the quality of the mobile phone connection to the network. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488208] New: Xpra breaks under kwin: context menus of remote applications disappear istantaneously
https://bugs.kde.org/show_bug.cgi?id=488208 Bug ID: 488208 Summary: Xpra breaks under kwin: context menus of remote applications disappear istantaneously Classification: Plasma Product: kwin Version: 6.0.5 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: core Assignee: kwin-bugs-n...@kde.org Reporter: sergio.calleg...@gmail.com Target Milestone: --- SUMMARY Kwin appears to behave differently wrt other window managers with the result of breaking xpra (https://github.com/Xpra-org/xpra), an application for using X11 applications from remote. I have the following configuration: Server: Manjaro linux, KDE plasma 6 with wayland session Client: same Running xpra 6.0.1 (latest) on both machines. On the server I start xpra as a server managing the "virtual" display :101. Then I start applications in X11 mode using DISPLAY=:101. On the client I start xpra to attach to the server. The xpra client works as a GTK3 application in the wayland session. Now, I start VirtualBox on the server on the :101 display. The Virtualbox window is correctly shown in the client. However, if I right click to open a contextual menu, the menu opens and disappears immediately, without letting me use it. I am being told from the xpra developer that this behavior is not experienced on other desktops. See https://github.com/Xpra-org/xpra/issues/4246 STEPS TO REPRODUCE 1. Have 2 hosts 2. Assure that they both run a plasma 6 wayland session 3. Assure that xpra is installed on both 4. Assure that Virtualbox is installed on one of them that will be the server 5. On the server run `xpra start :101` 6. On the client run `xpra attach ssh://server/101 --start konsole` 7. On the client see a remote konsole from the server appear 8. In the remote konsole type `VirtualBox` to start virtualbox on the server 9. See the Virtualbox window appear on the client 10. Right click on some object in the Virtualbox window to make a context menu appear OBSERVED RESULT See the context menu appear and immediately disappear EXPECTED RESULT The context menu should remain visible until it is used or erased. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 Kernel Version: 6.9.2-1-MANJARO (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Celeron® N4120 CPU @ 1.10GHz Memory: 5.6 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 600 Manufacturer: CHUWI Innovation And Technology(ShenZhen)co.,Ltd Product Name: Hi10 X ADDITIONAL INFORMATION Tested with a server that is the same configuration but Intel haswell hardware Also seen with a client that is the same configuration but Zephyrus Rog 14 AMD Ryzen + rembrandt graphics. Xpra is 6.0.1 Virtualbox is 7.0.18 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 488422] New: Gap in screens when attaching external monitor
https://bugs.kde.org/show_bug.cgi?id=488422 Bug ID: 488422 Summary: Gap in screens when attaching external monitor Classification: Applications Product: systemsettings Version: 6.0.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_kscreen Assignee: kscreen-bugs-n...@kde.org Reporter: sergio.calleg...@gmail.com CC: plasma-b...@kde.org Target Milestone: --- Created attachment 170424 --> https://bugs.kde.org/attachment.cgi?id=170424&action=edit Screenshot of monitor setup SUMMARY When attaching an external HDMI monitor (in fact via USB-C) the monitor is often mis-recognized, so that its actual resolution is not read and the resolution is set to 1024x768 even if the monitor is a 4k one. Even worse than that, when this happens, the internal and the external screen get auto-layed-out with a huge gap in between, so that it is not even possible to pass the mouse cursor from one to the other. STEPS TO REPRODUCE 1. Attach external monitor 2. Configure it for the appropriate 4k resolution 3. Detach external monitor 4. Reattach it OBSERVED RESULT Occasionally the external monitor resolution gets set up in a wrong way (1024x768) and a gap is created between the screens. EXPECTED RESULT The external monitor resoution should be set up correctly and, most important, in the layout there should be no gaps. Operating System: Manjaro Linux KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 Kernel Version: 6.9.3-3-MANJARO (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 9 6900HS with Radeon Graphics Memory: 30.6 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: ASUSTeK COMPUTER INC. Product Name: ROG Zephyrus G14 GA402RK_GA402RK System Version: 1.0 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 488422] Gap in screens when attaching external monitor
https://bugs.kde.org/show_bug.cgi?id=488422 --- Comment #2 from Sergio --- What is a bit weird is that in my case the scale factor of the laptop internal monitor was not touched at all. It is at 150% and it has always been so. Hence the ultimate reason for my problem is most likely not bug 479952 even if the cure might end up being similar. Another reason for saying that the issue might be different is that I do not see it happening every time but only occasionally (I would say between 10 and 20% of the times when I attach the external monitor). I have a suspect. I think this may happen because of the time when I attach the external monitor. If I attach it while my laptop is getting out of sleep, then, occasionally, the issue. If this is the case, then there might be some sort of race. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 488422] Gap in screens when attaching external monitor
https://bugs.kde.org/show_bug.cgi?id=488422 --- Comment #4 from Sergio --- > Changing the scale and resolution of one of the monitors will both have the > same effect of introducing a gap in monitors; it's got the same underlying > root cause. Understandable, so I guess the gap issue will be fixed also for me with plasma 6.1 thanks! What remains weird is why the 4k external monitor is "transiently" seen as a 1024x768 one at connection. If I later go to the display settings, I see that its resolutions are actually read out correctly. -- You are receiving this mail because: You are watching all bug changes.
[kdiff3] [Bug 487338] Possible regression: Floating point exception
https://bugs.kde.org/show_bug.cgi?id=487338 --- Comment #7 from Sergio --- Providing a test case might not be easy, since code might not be publishable. In any case, if you use the tool yourself, it might be only a matter of time until you get what you need to reproduce the issue. Here, a stack trace might be easier. Can you pls summarize how to get one in Linux? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 488611] New: Please remove config options depending on mozilla location services that are being switched off
https://bugs.kde.org/show_bug.cgi?id=488611 Bug ID: 488611 Summary: Please remove config options depending on mozilla location services that are being switched off Classification: Applications Product: systemsettings Version: 6.0.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_nightcolor Assignee: plasma-b...@kde.org Reporter: sergio.calleg...@gmail.com CC: kwin-bugs-n...@kde.org Target Milestone: --- SUMMARY Mozilla location services are being switched off. This causes the night light mode to remain on. Operating System: Manjaro Linux KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 Kernel Version: 6.9.3-3-MANJARO (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 9 6900HS with Radeon Graphics Memory: 30.6 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: ASUSTeK COMPUTER INC. Product Name: ROG Zephyrus G14 GA402RK_GA402RK System Version: 1.0 -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 434038] Please provide an updated version of Maliit that is usable
https://bugs.kde.org/show_bug.cgi?id=434038 --- Comment #11 from Sergio --- Let's see if this helps testing and as a consequence the consolidation of the development of Maliit. Currently there are many issues, that I would like to summarize as follows: 1. Maliit looks like a keyboard for a mobile phone or tablet. It has alphanumeric characters, and it lets you write texts, with localization. As is it appears in no way ready for "convergent" devices, such as powerful tablets or dual in ones laptops where you may or may not be using a detachable keyboard. On these devices the expectation is that in lack of a physical keyboard you should be able to carry out most activities (though with limited ergonomics) on the virtual one. Unfortunately, with Maliit you cannot use accelerators, terminals, nor most KDE applications that depend on keys such as CTRL, ALT, ESC, TAB, etc. I personally have a dual in one laptop, and it is totally useless in KDE without its physical keyboard attached. It is not even possible to deliver a presentation from a projector attached tablet, since you do not have ESC to exit full screen. Other DEs have OSKs that seem to be in better shape for these tasks. 2. Maliit does not make clear its goals: does it want to remain a phone-like keyboard or does it want to support terminal layouts? This is fundamental to know, because if Maliit is unwilling to support "terminal" layouts, then either: (i) another solution is needed; or (ii) each individual application will need to provide its own keyboard overlay with the keys it needs. This is what applications designed for mobile phones regularly do. For instance Termux adds a bar over the Android alphanumeric keyboard and emacs is going to do the same. I do not think that this approach is the best one for devices where you could have a proper "terminal" OSK, since it leads to a wild inconsistency among the different applications, but it would still be better than nothing. 3. Maliit documentation is missing or very much out of date. If you go to https://maliit.github.io/documentation/ most links are missing or point to information that is explicitly declared as old. So even if the Maliit framework could enable developing a terminal layout, the *how* is going to remain totally unknown to most. Point 3 is probably where NEON could help most, by packaging the pieces of documentation that are available and still relevant. In perspective, KDE should probably have its own, internally developed OSK, being this a key functionality of the desktop with today's emergence of many dual mode devices sitting midway between tablets and laptops. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 485077] New: Discover opens full screen, covers the bottom bar, there is no button or menu to minimize or change window size.
https://bugs.kde.org/show_bug.cgi?id=485077 Bug ID: 485077 Summary: Discover opens full screen, covers the bottom bar, there is no button or menu to minimize or change window size. Classification: Applications Product: Discover Version: unspecified Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: discover Assignee: plasma-b...@kde.org Reporter: mrc...@gmail.com CC: aleix...@kde.org Target Milestone: --- *** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** SUMMARY STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT Discover opens full screen, covers the bottom bar, there is no button or menu to minimize or change window size. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Nobara KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 485103] New: Discover 5.27.11 full screen whitout the possibily of minimizing and/or closing
https://bugs.kde.org/show_bug.cgi?id=485103 Bug ID: 485103 Summary: Discover 5.27.11 full screen whitout the possibily of minimizing and/or closing Classification: Applications Product: Discover Version: git-stable-Plasma/5.27 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: discover Assignee: plasma-b...@kde.org Reporter: mrc...@gmail.com CC: aleix...@kde.org Target Milestone: --- Created attachment 168197 --> https://bugs.kde.org/attachment.cgi?id=168197&action=edit my system *** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** SUMMARY STEPS TO REPRODUCE 1. launch of the application Discover 2. Discover opens full screen 3. There is no exit button, to close the app Discover OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 6.7.6.201 (available in About System) KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.0.0.2 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 434038] Please provide an updated version of Maliit that is usable
https://bugs.kde.org/show_bug.cgi?id=434038 Sergio changed: What|Removed |Added CC||sergio.calleg...@gmail.com --- Comment #7 from Sergio --- I see many (open) issues about Maliit, but I cannot understand if Maliit is the single on screen keyboard that works on plasma or if there are other ones to test... -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 434038] Please provide an updated version of Maliit that is usable
https://bugs.kde.org/show_bug.cgi?id=434038 --- Comment #8 from Sergio --- To better frame my question: The development of Malitt seems to be halted 2 years ago (at least referring to github and the "framework" component. A tiny bunch of more recent commits exists for the "keyboard" component). The recent commits seems to be related mostly to the removal of older features. The status of the documentation pages is at best mixed (roadmap page is 404, older roadmap still indicates Qt5 as a work in progress and catch up of Qt4), developers page declares itself outdated and most entries that should be links are not. Main issue is that there is no indication at whether and how the OSK can be extended with special keys that are indispensable for using many applications (CTRL, ESC, ALT). Without such extendibility, using the kosole, but also other less text oriented applications is impossible. Specifically, it is unclear if there should be a "terminal" layout with these keys or if the OSK is meant to remain purely alphabetic with an overlay bar with the extra chars appearing only when needed. To the best of my understanding the situation on gnome with the OSK is much better, but it is unclear to me if there is a freedesktop standard making the gnome keyboard usable on KDE or not. There should also be a Qt native OSK, but again it is unclear to me if this has been integrated in some way in a framework making it usable at the DE level. -- You are receiving this mail because: You are watching all bug changes.
[Skanlite] [Bug 485320] New: Wishlist: remember scanning resolution between invokation
https://bugs.kde.org/show_bug.cgi?id=485320 Bug ID: 485320 Summary: Wishlist: remember scanning resolution between invokation Classification: Applications Product: Skanlite Version: 23.08.5 Platform: Other OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: kare.s...@iki.fi Reporter: sergio.calleg...@gmail.com Target Milestone: --- *** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** SUMMARY Every time you start skanlite, the scan resolution gets reset to a default value that is typically inappropriate. For instance, with my HP scanner, every time you start skanlite the resolution is set at 75dpi, which is not something you generally want to use. STEPS TO REPRODUCE 1. Start skanlite 2. Set resolution to 300dpi, work 3. Exit 4. Start skanlite OBSERVED RESULT Resolution is not what you had previously set EXPECTED RESULT Skanlite should preserve, across invokations and on a pre-scanner basis, some common settings such as the resolution and possibly the scan area. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 5.27.11 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.12 Kernel Version: 6.6.25-1-MANJARO (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-4750HQ CPU @ 2.00GHz Memory: 15.5 GiB of RAM Graphics Processor: Mesa Intel® Iris® Pro Graphics P5200 Manufacturer: Notebook Product Name: W740SU System Version: Not Applicable ADDITIONAL INFORMATION N/A -- You are receiving this mail because: You are watching all bug changes.
[Skanlite] [Bug 485320] Wishlist: remember scanning resolution between invocation
https://bugs.kde.org/show_bug.cgi?id=485320 Sergio changed: What|Removed |Added Summary|Wishlist: remember scanning |Wishlist: remember scanning |resolution between |resolution between |invokation |invocation -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 469192] On X11 with multiple screens, Plasma frequently starts up with no containment (AKA black background with cursor, no context menu possible) on one of the screens until plasma
https://bugs.kde.org/show_bug.cgi?id=469192 --- Comment #19 from Sergio --- I understand your point. I have also started using the Wayland session that does not show this specific issue. Unfortunately, we are still in a trade-off phase, where one needs to decide whether the Wayland troubles are better than the X11 troubles or the other way round. ... and there seems little that can be done on the KDE side. In fact, most of the trouble I am experiencing with wayland seems to come from: - the total lack of standardization of common things in Wayland - why cannot there be a standard way to do session restore so plasma cannot do it? - why cannot there be a cross-toolkit env variable to decide if applications should use X11 or Wayland and every toolkit has its own way, so launching applications via `ssh -X` which should work just fine using Xwayland does never work? - why isn't there a single cross-toolkit env variable to control scaling? - why Java applications won't obey scaling anyway so big commercial applications (MATLAB to mention one) are now almost unusable unless you use weird hacks like passing them through Xpra? - rather strange policy decisions - why can we have scaling only by 75-100-125-150 etc., what was the issue with specifying DPIs that enabled a much finer tuning; - why scaling is managed in a so weird way that most application developers cannot deal with it, so that even a healthy and rapidly developed project like libreoffice still has broken scaling on multi monitor with the QT VCLs? - why cannot applications decide their own icon, so a lot of stuff remains with the generic "W" icon and Qt's `setWindowIcon` has been broken *by policy*? - why is there no standard way to deal with the system tray, so those developing for flatpack have such a hard time making icons appear there? To mention a few, `sleek`, `spotube`, many other flatpacks applications cannot show the tray icon on Wayland/KDE and some of these applications had to go back to using X11 to be usable on plasma (spotube). Getting somehow resigned... -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 469192] On X11 with multiple screens, Plasma frequently starts up with no containment (AKA black background with cursor, no context menu possible) on one of the screens until plasma
https://bugs.kde.org/show_bug.cgi?id=469192 --- Comment #23 from Sergio --- Thanks Nate for the extended answer! >> and there seems little that can be done on the KDE side. > On the contrary, Plasma's wayland session is improving rapidly, while its X11 > session is frozen in stone, > never to get any better ever again. The same is true of the X server upstream. In fact, I think that we meant the same thing. When I say that there is little that can be done on the KDE side, I mean that Plasma progressed vigorously on all it could do alone, but that there are remaining issues (often annoying ones) coming from things that are not in control of the KDE developers. From a total outsider, the impression is that: (i) those who decide on the protocols tend to prevent the introduction of some mechanisms because they have some strong views on the policies that should be adopted and not having a mechanism appears as a powerful way to prevent some policies (`setWindowIcon` is an excellent example); and (ii) coordination with toolkit developers is too loose, maybe because of imbalance on how the toolkits are considered. >> - why cannot there be a standard way to do session restore so plasma cannot >> do it? > It's still a work in progress; see > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18. > Once that's accepted, > we'll add support for it. Excellent news, particularly for systems that cannot sleep. Yet, again for an outsider, it seems amazing that 15 years after the initial release of the wayland protocols, the ability to save-restore a session in a standard way is still on the drawing board. >> - why cannot there be a cross-toolkit env variable to decide if >> applications should use X11 or Wayland and every toolkit has its own way, >> so launching applications via `ssh -X` which should work just fine using >> Xwayland does never work? > Because there are multiple toolkits and they never came to an agreement about > a common environment variable to use. This sounds like > it could be a good candidate for a new Wayland protocol. This is particularly nasty. One does ssh -X from host A to host B and launches an application on B. Because the application does not know it should run on X11, since there is no standard way to tell it to run on X11, it may end up believing it should use wayland. If the user has a wayland session on B, the application opens on the screen of B with no error reported on the ssh terminal session. That may get unnoticed and the application may stay there even for days, using resources, amplifying the attack surface of B, whatever. When the user unlocks B not remembering that there is such application, that application window may get unexpectedly exposing to others in the room. >> - why can we have scaling only by 75-100-125-150 etc., what was the issue >> with specifying DPIs that enabled a much finer tuning; > You can set any scale value you want in the relevant KDE system settings > page, not just multiples of 25%. Particularly interested in this. In the KDE system settings -> display configuration, I can move the scale slider only by multiples of 25%, how do I unlock that? >> - why isn't there a single cross-toolkit env variable to control scaling? > See above. But why is this needed? Because in principle everything should, as you say, just work. But if adjustments are required having to remember "GDK_SCALE" "GDK_DPI_SCALE", "QT_SCALE_FACTOR" or whatever other variable is a mess. > LibreOffice with the QT VCL works just fine for me with a multi-monitor > system where one monitor has 225% scale and another > has 110% scale; I was using it this way just today. If it's not working for > you, it sounds like your system is misconfigured. No, unfortunately there is a confirmed bug about this setup. See: https://bugs.documentfoundation.org/show_bug.cgi?id=141578 >> - why Java applications won't obey scaling anyway so big commercial >> applications (MATLAB to mention one) are now almost unusable >> unless you use weird hacks like passing them through Xpra? > Without knowing which apps, I can't answer that question, but I suspect based > on other scaling-related questions that your system is > misconfigured based on old habits from X11 that aren't translating to a > Wayland world. Unfortunately, many large cross-platform scientific applications use java front-ends (MATLAB, SCILAB to mention two that almost everybody knows) and all AWT/Swing applications cannot do scaling properly on Wayland (while it was obeying the DPI setup in X11). AWT/Swing can do scaling but only at integer factors which almost invariably makes things either too big or too small. The only reasonable way to use these applications is via `xpra
[ksplash] [Bug 487153] New: Spinner is corrupted in ksplash with breath theme on AMD hardware
https://bugs.kde.org/show_bug.cgi?id=487153 Bug ID: 487153 Summary: Spinner is corrupted in ksplash with breath theme on AMD hardware Classification: Plasma Product: ksplash Version: 6.0.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: sergio.calleg...@gmail.com Target Milestone: --- SUMMARY Ksplash should show a screen with a spinner with the breath theme. In place of the screen I see a blocky square box turning around. I see this on a laptop with AMD GPU. On an older Intel haswell laptop the spinner is fine. With other themes (e.g. breeze), the spinner is fine. STEPS TO REPRODUCE Login OBSERVED RESULT Corrupted spinner appears before plasma launch is completed EXPECTED RESULT Nice looking spinner is shown and animated. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.9-3-MANJARO (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 9 6900HS with Radeon Graphics Memory: 30.6 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: ASUSTeK COMPUTER INC. Product Name: ROG Zephyrus G14 GA402RK_GA402RK System Version: 1.0 -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 487271] New: Please, provide option to remove sleep/hibernate buttons from screen locker
https://bugs.kde.org/show_bug.cgi?id=487271 Bug ID: 487271 Summary: Please, provide option to remove sleep/hibernate buttons from screen locker Classification: Plasma Product: kscreenlocker Version: 6.0.4 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: sergio.calleg...@gmail.com Target Milestone: --- SUMMARY The Plasma screen locker includes a sleep (and possibly a hibernate button). I think that should be possible to configure it not to show these buttons, because of the following reasons: - You do not want a casual user passing in front of your (locked) PC or laptop to be able to put it in hibernation or sleep; - When you have the computer locked, after a short time the screen will go in stand by and turn black. To turn it on, it is common to move the mouse and press its buttons. But if the mouse buttons get pressed when the cursor is on the hibernate button, the computer will hibernate. STEPS TO REPRODUCE Go in the system-settings klockscreen setup OBSERVED RESULT See that there is no configuration option to prevent the sleep/hibernate buttons from showing in the lock screen. EXPECTED RESULT Would be nice to have an option to prevent the sleep/hibernate buttons from showing in the lock screen. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.6.30-2-MANJARO (64-bit) Graphics Platform: Wayland -- You are receiving this mail because: You are watching all bug changes.
[plasma-pa] [Bug 487323] New: "balance" button in "sound" systems settings results in a single volume cursor, but does not balance volume on the two channels
https://bugs.kde.org/show_bug.cgi?id=487323 Bug ID: 487323 Summary: "balance" button in "sound" systems settings results in a single volume cursor, but does not balance volume on the two channels Classification: Plasma Product: plasma-pa Version: 6.0.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: sergio.calleg...@gmail.com CC: isma...@gmail.com, m...@ratijas.tk Target Milestone: --- SUMMARY Suppose that you have the volumes on the left and right channels unbalanced (e.g. you see two cursor bars one at 10% on left, one 50% on right). You press the balance button. Those two bars turn into one. You expect the volumes for both channels to be the same now, but they remain unbalanced. STEPS TO REPRODUCE 1. Open the sound system settings 2. Adjust volume for the two channels so that they are unbalanced 3. Press balance OBSERVED RESULT You see the two controls for the left and right channel turning into one, but the unbalance remains (check with sound reproduction). EXPECTED RESULT The two channels should be set at the same volume. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.9-3-MANJARO (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 9 6900HS with Radeon Graphics Memory: 30.6 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: ASUSTeK COMPUTER INC. Product Name: ROG Zephyrus G14 GA402RK_GA402RK System Version: 1.0 ADDITIONAL INFORMATION This might be a regression in plasma 6 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 487323] "balance" button in "sound" systems settings results in a single volume cursor, but does not balance volume on the two channels
https://bugs.kde.org/show_bug.cgi?id=487323 --- Comment #2 from Sergio --- That clarifies, however I still think that the UI (and its discoverability) could be improved. If for some reason you get with the volumes unbalanced (not necessarily because you messed with them, in some occasions I had the hardware coming up with this after a boot), you do not see that. Probably, the channels should always be shown independently when they are not equalized. In addition to that, even if I am not a native speaker, I get the impression that the word "balance" is perceived as implying an even distribution and might get interpreted as a verb "do achieve an even distribution". May I suggest renaming "balance" as "show channels" and possibly when the individual channels are shown add an equalize button under the mute one? and you see a "balance" button you might interpret it as a verb (do balance the buttons). I am not a native speaker, so I may be wrong, though. May I suggest that the "balance" button is renamed "show channels" or just channels and that possibly a "balance channels" button is added? -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 445553] New: OSD calls action "Switch to laptop screen", despite device not being a laptop
https://bugs.kde.org/show_bug.cgi?id=445553 Bug ID: 445553 Summary: OSD calls action "Switch to laptop screen", despite device not being a laptop Product: KScreen Version: 5.22.5 Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: kded Assignee: kscreen-bugs-n...@kde.org Reporter: sergiovargas1...@gmail.com Target Milestone: --- Pressing Super+P brings up the OSD with several options, including "Switch to laptop screen". I'm using a standard desktop though, and I don't see much reason that the option shouldn't be called "Switch to main screen" or "Switch to primary screen" instead. My use case is to manage the connection to a TV. -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 453510] New: SWITCH USER is dangerous and can lock users out of their account
https://bugs.kde.org/show_bug.cgi?id=453510 Bug ID: 453510 Summary: SWITCH USER is dangerous and can lock users out of their account Product: ksmserver Version: 5.24.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: sergio.calleg...@gmail.com CC: plasma-b...@kde.org Target Milestone: --- Unclear to me if `ksmserver` is the actual component to report this issue against or if the issue is elsewhere. The plasma desktop provides a Switch User option that is quite dangerous. If you select that functionality and you do not have another user to log in as, then you are locked out of your machine. In fact: - I you select `switch user`, you are presented with a login screen and *there is no way* to go back. - If you have a single user or you do not know the credentials of other users, the only thing you can do at this point is to try to log in with your credentials - If you do so, a new session is opened with the same username as one that was already open and this locks up plasma. This should not happen. a) If you select `switch user`, there should always be a cancel button. b) If you try to log in again as the same user and the same session type, this should be recognized and the existing session should be used, rather than trying to start a new session for the same user and the same desktop type, which cannot work. STEPS TO REPRODUCE 1. Login to plasma 2. Select Switch User from the menu 3. Try to get back to work by entering your credentials OBSERVED RESULT KDE locks up EXPECTED RESULT KDE should never lock up and prevent situations causing it to lock up. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro Linux KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 453968] New: Baloo should watch thermal data
https://bugs.kde.org/show_bug.cgi?id=453968 Bug ID: 453968 Summary: Baloo should watch thermal data Product: frameworks-baloo Version: 5.93.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Baloo File Daemon Assignee: baloo-bugs-n...@kde.org Reporter: sergio.calleg...@gmail.com Target Milestone: --- SUMMARY Baloo currently does a decent job at not hindering the machine ability to quickly perform other tasks by running when other tasks don't need resources. Still this could be very much improved by also looking at the thermal situation of the machine. Baloo should avoid making the machine temperature rise high enough to make the fans spin loudly (let the laptop remain silent, please) and, even worse get the cpu in thermal throttling. -- You are receiving this mail because: You are watching all bug changes.
[Skanlite] [Bug 453063] New: Batch mode with time delay should not be used for preview scans
https://bugs.kde.org/show_bug.cgi?id=453063 Bug ID: 453063 Summary: Batch mode with time delay should not be used for preview scans Product: Skanlite Version: 21.12.3 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kare.s...@iki.fi Reporter: sergio.calleg...@gmail.com Target Milestone: --- Seems that if you have the `batch mode with time delay` option activated this is incorrectly used also when you ask for a preview scan. STEPS TO REPRODUCE 1. tick batch mode with time delay 2. press preview OBSERVED RESULT The preview operation does not end as it should EXPECTED RESULT A single preview is taken and then the operation of skanlite should go back to normal SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 455704] New: Wishlist: add command line options to force file opening in tab or in new window
https://bugs.kde.org/show_bug.cgi?id=455704 Bug ID: 455704 Summary: Wishlist: add command line options to force file opening in tab or in new window Product: okular Version: 22.04.2 Platform: unspecified OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: okular-de...@kde.org Reporter: sergio.calleg...@gmail.com Target Milestone: --- SUMMARY Please consider adding a command line option to force the opening of the document(s) passed on the command line in a tab of an existing okular instance or in a new window. E.g. `okular --new-tab file.pdf` or `okular --new-window file.pdf`. Rationale: This eases opening 2 documents in separated windows that can be placed side to side for comparing them, even if as a general setting one prefers having the "open new files in tabs" option set. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 456077] New: Severe rendering artifacts in okular after update to ubuntu 22.04 from 20.04
https://bugs.kde.org/show_bug.cgi?id=456077 Bug ID: 456077 Summary: Severe rendering artifacts in okular after update to ubuntu 22.04 from 20.04 Product: okular Version: 22.04.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: PDF backend Assignee: okular-de...@kde.org Reporter: sergio.calleg...@gmail.com Target Milestone: --- Created attachment 150224 --> https://bugs.kde.org/attachment.cgi?id=150224&action=edit Screenshot with the rendering issue: figure is completely missing, part of the text is covered by an artifact SUMMARY The version of okular shipped with ubuntu 22.04 produces severe rendering artifacts on a laptop with intel graphics (CometLake-U GT2 [UHD Graphics]). Seen using an X11 session. It is unclear to me if the issue is with okular itself or with some libraries used by okular or in the graphics stack provided by ubuntu 22.04. Other applications do not have similar issues, though. STEPS TO REPRODUCE 1. Open a PDF file 2. Repeatedly press F5 (Reload). OBSERVED RESULT Note that the PDF is not always rendered in the same way. In multiple occasions parts of the page are missing, while other are covered in dark artifacts. EXPECTED RESULT The PDF is always rendered correctly and in the same way. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.3 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 456344] New: Driverless printers do not appear in the Qt print dialog
https://bugs.kde.org/show_bug.cgi?id=456344 Bug ID: 456344 Summary: Driverless printers do not appear in the Qt print dialog Product: okular Version: 22.04.2 Platform: Manjaro OS: Linux Status: REPORTED Severity: major Priority: NOR Component: printing Assignee: okular-de...@kde.org Reporter: sergio.calleg...@gmail.com Target Milestone: --- SUMMARY The cups spooler offers the possibility to use *driverless* network printers as long as the `cups-browsed` service is active. With KDE, these printers correctly appear in the *Printers* section of the *System Settings*. Unfortunately, while these printers can be used just fine with non Qt applications, it is impossible to use them in KDE applications like okular, because they do not get listed in the Qt print dialog, so they cannot be picked as destinations. I am observing this problem with Manjaro linux that uses the latest plasma 5.24.5 and framework 5.95.0, together with Qt 5.15.5. The problem is not there with Ubuntu 22.04, though, that uses the same plasma and framework versions and a slightly different Qt 5.15.3. So this issue is to ask to check if wrt driverless printers and the print dialog: - something has changed recently preventing the driverless printers from being shown up in the print dialogs used by Qt applications; - there is something wrong in the flags used for compiling the code that Ubuntu may change and Manjaro/Arch tend not to change. - Qt needs some patches that manjaro is missing. Note that driverless printing is now becoming indispensable in office environments where many large printers can only be used via driverless printing (at least in linux). I do not think that this bug is the same as #326432 that refers to some very old problems that should have been resolved long ago. STEPS TO REPRODUCE 1. Open okular 2. Select Print from the menu OBSERVED RESULT Driverless printers are not available in the list of printers. It is impossible to use them from KDE applications; EXPECTED RESULT Driverless printers should be listed in the list of printers and usable. SOFTWARE/OS VERSIONS Linux/KDE Plasma KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.5 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 456344] Driverless printers do not appear in the Qt print dialog
https://bugs.kde.org/show_bug.cgi?id=456344 --- Comment #2 from Sergio --- I was expecting it not to be directly related to okular as it appears in all Qt/KDE apps, just okular seemed a prominent example, sorry for the noise. Now I wonder if KDE apps use a standard functionality of Qt or modify the Qt print dialog in some way, that is if this issue is purely inherited from Qt or may be in some KDE framework (I expect the first). -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 442948] New: Keyboard layout priority is ignored
https://bugs.kde.org/show_bug.cgi?id=442948 Bug ID: 442948 Summary: Keyboard layout priority is ignored Product: systemsettings Version: 5.22.4 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_keyboard Assignee: plasma-b...@kde.org Reporter: sergio.calleg...@gmail.com CC: butir...@gmail.com Target Milestone: --- SUMMARY When using multiple keyboard layouts, it is possible to "move up" or "move down" them, establishing a priority. Unfortunately at plasma startup this priority is ignored. STEPS TO REPRODUCE 1. Configure an Italian and an English (US) layout 2. Set the English layout on top 3. Start plasma OBSERVED RESULT Plasma starts with the Italian layout. There is no way to make plasma start with the English US layout EXPECTED RESULT Plasma should start with whatever layout has priority. There should be a way to have the system start with the English US layout even if an Italian layout is also configured. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro Linux KDE edition (available in About System) KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.85.0 Qt Version: 5.12.2 Working with X11 ADDITIONAL INFORMATION The issue does not appear to be present in Kubuntu 20.04. However the latter uses a much older software stack: Plamsa 5.18.7, framework 5.68. There is a newer Qt though (5.12.8). Another thing that may be worth mentioning is that Manjaro introduces its own keyboard setup module that may have some interference with the KDE one. Hence, we may be facing either a regression or a manjaro specific bug. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 442948] Keyboard layout priority is ignored
https://bugs.kde.org/show_bug.cgi?id=442948 --- Comment #2 from Sergio --- > For X11, last used layout is always restored now Unfortunately on my system even logging out with one keyboard layout, at the following login you get the wrong one. This is particularly visible for this RPI system that has no suspend/restore and consequently gets switched off. > For Wayland, that depends on whether "Restore previous session" setting is > set. > If it's not set, layout priority is honored. > Note that functionality was not ported to X11, and it's unclear if it ever be. Reduced efforts on X11 are understandable, ... But out of curiosity is the "restore previous session" management now functioning in wayland? I knew there was an issue with it for the lack of a standardized protocol in wayland for session management and that each DE was expected to implement its own solution unless the gnome solution is general enough to become a de facto standard. Has anything changed? Lack of session management is one of the things that keeps me on X11. In any case, the behavior I am experiencing seems different from the "intended" one you describe above. Should a different bug be posted (or maybe should this one be reopened and retitled?). Furthermore, given that the priority is never enforced in X11, the "up" and "down" buttons for layouts on X11 come out as a bit misleading. Could a tooltip be added to them indicating that ordering is not used on X11? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 434922] cpu load plasmoid remain blank and cannot find sensors
https://bugs.kde.org/show_bug.cgi?id=434922 --- Comment #13 from Sergio --- Issue is still present as of plasma 5.22.5, frameworks 5.87.0 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 434922] cpu load plasmoid remain blank and cannot find sensors
https://bugs.kde.org/show_bug.cgi?id=434922 --- Comment #15 from Sergio --- As mentioned above, ksystemstats is installed. > As mentioned, ksystemstats appears to be active and jumps to 100% CPU usage > by adding the > plasmoids. So it seems to get started appropriately, but then something goes > wrong. ps shows /usr/bin/ksystemstats getting autostartd when the plasmoid is added, but then ksystemstats goes in active wait for something using 100% CPU. My feeling is that it may try to parse data from some interface remaining in active wait because it is not getting something that is expected (most likely because it waits for something that is X86 specific and not present on ARM systems). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 434922] cpu load plasmoid remain blank and cannot find sensors
https://bugs.kde.org/show_bug.cgi?id=434922 --- Comment #16 from Sergio --- stracing ksystemstats shows it opening /proc/cpuinfo, reading from it some text (the last string I see on the trace is about some bogomips value, but this may be due to strace string truncation). Then ksystemstats keeps repeating read attempts from that file always getting nothing. To me this is ksystemstats trying to read the file seeking for something, not finding it (because the virtual file misses some fields on ARM wrt X86 and has a slightly different format) arriving at the end of the file and stubbornly keeping to attempt reads. -- You are receiving this mail because: You are watching all bug changes.
[Falkon] [Bug 393742] Wishlist: --app mode
https://bugs.kde.org/show_bug.cgi?id=393742 --- Comment #3 from Sergio --- Would be particularly timely to get this now that firefox is dropping this feature. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 359601] "Windows can cover" does not seem to work for me
https://bugs.kde.org/show_bug.cgi?id=359601 Sergio changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 CC||sergio.calleg...@gmail.com --- Comment #16 from Sergio --- Reproducing it with: Operating System: Kubuntu 20.04 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 Kernel Version: 5.4.0-48-generic OS Type: 64-bit very nasty, because together with bug 351175 this basically means that having more than the bottom panel on dynamic multi screen configurations is looking for trouble, because you will almost invariably getting panels that cover useful windows in critical bits like scrollbars, etc. Moving the bug to "confirmed state" as multiple users appear to be experiencing it. If no resources can be available for fixing this, please consider removing/disabling/hiding functionalities that have anyway been broken for many years as they just confuse the user. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 351175] Panel on screen edge between two monitors does not auto hide
https://bugs.kde.org/show_bug.cgi?id=351175 --- Comment #31 from Sergio --- @Duncan, your scripting solution is admirable! However, it makes one wonder once more at: > We can't have hidden panels in the middle of two screens. > It's a known limitation, that under X can't really be fixed. Sorry. Let's hope that it challenges the developers to provide the correct behavior in plasma rather than assuming it is not needed because there is a scripting workaround. (Side) panels in plasma 5 are indeed broken in many other ways too (e.g, if you have a bottom panel and a side panel, you cannot properly configure the latter, because the bottom configuration button of the side panel may get covered by the side panel, Bug 417523; the "windows can cover" option does not work, Bug 359601, etc.). In fact, I think that Plasma 5 should warn the average user against trying to use more than the default bottom panel in the current state. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 359601] "Windows can cover" does not seem to work for me
https://bugs.kde.org/show_bug.cgi?id=359601 --- Comment #17 from Sergio --- Wonder if this may have to do with panels added with "old" versions of plasma 5. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 417523] "More options..." button of vertical Panel is hidden if I also have an always visible horizontal Panel on bottom of the screen
https://bugs.kde.org/show_bug.cgi?id=417523 --- Comment #5 from Sergio --- Also impossible to resize the panel because the "Margin" arrows used to shift the panel border also get hidden... -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 434922] cpu load plasmoid remain blank and cannot find sensors
https://bugs.kde.org/show_bug.cgi?id=434922 --- Comment #7 from Sergio --- @Nate Graham sorry I missed your previous question. Catching up... >From the document you linked, I believe that this is the needed info: ''' systemctl --user status plasma-plasmashell.service ○ plasma-plasmashell.service - KDE Plasma Workspace Loaded: loaded (/usr/lib/systemd/user/plasma-plasmashell.service; disabled; vendor preset: enabled) Active: inactive (dead) ''' -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 434922] cpu load plasmoid remain blank and cannot find sensors
https://bugs.kde.org/show_bug.cgi?id=434922 --- Comment #8 from Sergio --- Possibly not relevant. However, if you try to activate the service manually you get ''' systemctl --user start plasma-plasmashell.service systemctl --user status plasma-plasmashell.service ○ plasma-plasmashell.service - KDE Plasma Workspace Loaded: loaded (/usr/lib/systemd/user/plasma-plasmashell.service; disabled; vendor preset: enabled) Active: inactive (dead) Apr 28 09:14:16 systemd[694]: Starting KDE Plasma Workspace... Apr 28 09:14:17 systemd[694]: plasma-plasmashell.service: Deactivated successfully. Apr 28 09:14:17 systemd[694]: Started KDE Plasma Workspace. ``` ... after which the behavior of the widgets and the systemstat daemon does not change (widgets not working, daemon using 100% of one core). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 434922] cpu load plasmoid remain blank and cannot find sensors
https://bugs.kde.org/show_bug.cgi?id=434922 --- Comment #9 from Sergio --- KDE Frameworks update to 5.81 has not fixed the issue. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 434922] cpu load plasmoid remain blank and cannot find sensors
https://bugs.kde.org/show_bug.cgi?id=434922 --- Comment #11 from Sergio --- Tried to launch ksystemstats manually, from the command line (incidentally, not so nice that there is no documentation at all, nor response to invoking with --help. Unclear to me if there is any way to make it print some debug info). Also in this case, ksystemstats gets in an "active wait" mode, using up 100% cpu. Trying to debug using strace, you can see that after some initial steps it enters in a situation where it keeps trying to read from file descriptor 8, but reads nothing. The latest openat returning file descriptor 8 seems to be /proc/cpuinfo. So my impression is that ksystemstats does not know how to parse the cpuinfo for ARM (or at least for the RPI4 Broadcom BCM2711 cpu) and remains confused. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 434922] cpu load plasmoid remain blank and cannot find sensors
https://bugs.kde.org/show_bug.cgi?id=434922 --- Comment #12 from Sergio --- A few additional notes: * just observed that ksystemstats belong to a ksysguard package on my distro. Wonder if the "product" field should be changed to ksysguard. * ksysguard package on my system comes with plasma 5.21.5 * just learned about the kstatsviewer command. It also hangs on my system when launched as ksytatsviewer --list -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 434922] cpu load plasmoid remain blank and cannot find sensors
https://bugs.kde.org/show_bug.cgi?id=434922 --- Comment #2 from Sergio --- As mentioned, ksystemstats appears to be active and jumps to 100% CPU usage by adding the plasmoids. So it seems to get started appropriately, but then something goes wrong. The issue is immediately present after adding the plasmoid, not just a login. I have noticed that other cpu-load related plasmoids that can be downloaded rather than being readily available appear to work, though partially. However, with them, ksystemstats does not seem to run (e.g., I see that the "system load viewer" plasmoid version 0.8 by Martin Yrjölä works, even if the "show CPUs separately" option does not). Is it based on a different approach? Also running ksysguard works (as mentioned) and does not start ksystemstats. Hence, my impression is that some plasmoid rely on a "new" framework using the ksystemstats daemon, that the daemon gets started properly when needed, but does not work. It fails to provide data to the plasmoids and it enters some state where it uses all the available resources of the core it runs on. I wonder if this is ARM specific or RPI4 specific or is due to a packaging or permission problem specific to arch/manjaro. -- You are receiving this mail because: You are watching all bug changes.
