Running a system with LOTS of resources (64 GB of ram for one). Complicating things is that I run 4 - 1920x1080 and 1 - 4k monitor. I've found that using virtual desktops is a great way of separating projects and functions. Have slowly worked my way up to a total of 46 virtual desktops (Easy to find space when the panel at the bottom of the desktop is on a 4k monitor!) Finding that when I use more graphically intense packages - - - FreeCAD being one, that my system uptime disintegrates. I find the problem when I return to my system and activate the monitors (from a sleep mode). When all my pages are piled on top of each other and the panel at the bottom of the monitor (desktopswitcher from lxqt-panel) has disappeared well then I need to go to another system, ssh into my main box and reboot. (After reboot it takes about 1/2 hour to setup all the packages that I have running on my system when I want them to be.) In digging into the source code there is a hard limit listed - - - lines 49 to 52 in workspace_wrapper.h . I have been looking to find where that limit is actually programmed in but I can't find it. Apologies to the developers but I don't see where this is a 'useful' limit. I suppose if one insists on using function keys then the limit makes sense but when one is using a desktop switching panel an arbitrary limit seems quite - - - unnecessary - - - at least in my opinion. If someone were to point out where that hard coding actually resides I would like to try changing that upper limit to something like 50 -- - - for my system here - - - and would be very interested in reporting any resultants from such change. Please and TIA STEPS TO REPRODUCE 1. system with lxqt and using desktop switcher from lxqt-panel 2. set up 40 desktops 3. run with packages and stuff on most of the desktops 4. I get perhaps 10 days before the graphics system barfs. OBSERVED RESULT lxqt-panel no longer works all packages and windows are piled on one virtual desktop reboot clears the mess EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Devuan daedalus (sp??) (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: 5.15 ADDITIONAL INFORMATION Information is found in kwin /src/scripting/workspace_wrapper.h
>If someone were to point out where that hard coding actually resides virtualdesktops.h inline uint VirtualDesktopManager::maximum() { return 20; }
> set up 40 desktops Where exactly did you set your 46 virtual desktops from? Some UI in LXQt? 20 Virtual Desktops are all that KWin supports; if LXQt doesn't honor this limit, it's kind of a problem.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Hmmmmmmm - - - - interesting - - - - get a notice that this is in "need more information' status. Can't see where more information has been asked for - - - - only where I'm being chided for doing 'something so vile'. Seems that this is supposed to be considered a feature - - - - you know - - - - limit things to keep things 'whatever'. I was given information - - - yes - - - - changing that limit is not quite just changing a number in one line of code. It would appear that support from the dev community is quite lacking for this problem. Pity - - - - its imo a valuable tool for keeping a complicated work environment a little cleaner.
please provide a backtrace (with debug symbols) Reset the bug report status back to REPORTED after providing the requested information
(In reply to Vlad Zahorodnii from comment #6) > please provide a backtrace (with debug symbols) > > Reset the bug report status back to REPORTED after providing the requested > information If you would delineate 'exactly' how one does a backtrace with debug symbols I would be happy to try such. Until then - - - you're speaking a language I know nothing about. Regards
The question that needs answering was "Where exactly did you set your 46 virtual desktops from? Some UI in LXQt?"
Nope - - - set the number of desktops in 'Openbox'
If other systems can set higher numbers than what we allow in KWin, I think it might make sense to remove the limit in KWin.
>If you would delineate 'exactly' how one does a backtrace with debug symbols I would be happy to https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl We have also moved to a new crash reporting mechanism that should catch any issues moving forwards.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
It is fascinating how the AI determines that there is no longer a bug. The AI says - - - - you don't give me what I want - - - you no longer have a bug to report. (I.e. go away sucker - - - - which is what I've been hearing for a while. Somehow I'm supposed to become a system expert to report a bug and as I'm not able to run the software suggested (I'm running a non-systemd setup) and I cannot find the correlational software , i.e. corredump for the kernel I'm running - - - - well I must not have a bug - - - - except I get 14 days (+/-) and the graphics subsection hangs. Oh well - - - I guess I'm supposed to be running M$ products.)
There's no AI here, just a simple dumb bot that asks you provide information. Vlad asked you to get a backtrace and David provided you with instructions how. If those instructions don't apply to you because you're deliberately running a non-systemd setup, then yes, you pretty much are expected to be a system expert, because you're intentionally diverging from what 95% of your peers are running these days. As such, it's up to you to know or figure out how to get a backtrace using whatever system tools your distro does make available. If this is something you're not interested in doing, I might gently suggest that running a non-systemd distro wasn't the right choice to make. You might be better served by a distro that does use systemd, which will help your setup align with what most other people are using and hence make use of better-exercised code, documentation, etc.
Hmmmmmmmmmm - - - so there is now the suggestion that if I were running a systemd distro I just might not be having the problem. Sorry - - - I've been having these issues from before I switched from a systemd distro (then I got to avoid a bunch of the systemd 'joys' by having switched. Somehow I thought open source was supposed to be about something called choice - - - not railroading. If a systemd solution is your only alternative - - - why then - - - go ahead mark the bug report as having been fixed - - - except do note that the 'new and improved idea of microsystems that I was reading about in the last few weeks is quite reminiscent of the idea of 'do one thing and do it well' kind of thinking that is NOT part of systemd so the bug has been fixed - - - by forcing the installation of a larger bug conglomerate. This kind of interchange is only helping to convince me that the kde emporium really isn't about working with its users. Oh well - - - I tried to work with this system - - - - dunno how it much has tried to work with me (besides demanding things that 99.9% of the users have no idea how to obtain).
I'm not saying the bug is or might be fixed if you were using systemd. I'm saying systemd would make it easier for you to get the backtrace of the crash that was requested earlier. If you don't want to use systemd, that's fine, but then it's up to you to have the technical chops to know your way around the alternative system you've chosen instead.
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.