SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I don't think so. I had an issue with qt5-5.9.6 so I went back to qt5-5.9.5. Is it this past update or all updates for you?
This issue manifests since at least several versions, I do not remember right when it appeared first.
In fact, there are two issue. The KWin crashes its effects with no aparent reason and that icons getting lost. Roughly similar with what Darth Vader describe.
That happens in the system with Radeon video, within the Intel one Plasma5 works fine.
Last edited by ZhaoLin1457; 06-22-2018 at 04:38 AM.
I tried that, with the effect turned off there is no KWin effects crashing, but still appears the icons issue.
However, without the effects, I feel that the deskop behave very bad and with a lot of tears.
So I keep them on, with OpenGL 2.0, because with the 3.1 the issues appears often and XRender is really slow.
Maybe try
Quote:
XV_VSYNC is used to control whether textured adapter synchronizes the screen update to the monitor vertical refresh to eliminate tearing. It has two values: 'off'(0) and 'on'(1). The default is 'on'(1).
XV_VSYNC is used to control whether textured adapter synchronizes the screen update to the monitor vertical refresh to eliminate tearing. It has two values: 'off'(0) and 'on'(1). The default is 'on'(1).
This one is for textured video, then has effects only while using Xv as output driver on MPlayer, as example.
NVIDIA provides compositing. I don't know about the Radeon driver. Before people rage at me I'm going to stop derailing this thread. I don't like the KDE compositor myself. Maybe look for a different one like this one if the Radeon driver can't do it: https://slackbuilds.org/repository/1.../compton-conf/
By default the $XDG_RUNTIME_DIR environment variable is not set in Slackware, nor is /var/run sym linked to /run.
With many other distros the $XDG_RUNTIME_DIR defaults to /run/user/$UID. In many distros, /var/run is a sym link to /run. Both Slackware and most other distros mount /run to tmpfs, but Slackware does not create the /var/run sym link or create a default $XDG_RUNTIME_DIR variable. Using a sym link and tmpfs creates a nice way to clean the directory on reboot.
The sym link could be created in rc.S. The variable could be set in /etc/profile.d with:
Code:
if [ ! -d /run/user/$UID ]; then
mkdir -p /run/user/$UID
fi
export XDG_RUNTIME_DIR=/run/user/$UID
Possibly some people would want /var/run fixed rather than use tmpfs. Perhaps rc.S could source /etc/default/var_run to determine whether to create the sym link.
With many other distros the $XDG_RUNTIME_DIR defaults to /run/user/$UID. In many distros, /var/run is a sym link to /run. Both Slackware and most other distros mount /run to tmpfs, but Slackware does not create the /var/run sym link or create a default $XDG_RUNTIME_DIR variable. Using a sym link and tmpfs creates a nice way to clean the directory on reboot.
There are several packages with subdirectories in /var/run. Those directories would be lost with tmpfs, so all of these packages would need to be adapted so that their start script recreates the directories with the necessary access rights.
It defaults to /tmp/runtime-user if not set, no idea why would one write it somewhere other than /tmp.
I usually mount tmpfs as /tmp, and TBH I'd prefer not to write and re-write runtime on ssd.
There are several packages with subdirectories in /var/run. Those directories would be lost with tmpfs, so all of these packages would need to be adapted so that their start script recreates the directories with the necessary access rights.
I have been using /var/run sym-linked to /run for a couple of years or more. While possible, I have not encountered such issues. On my Slackware systems, everything is repopulated with each boot. Unlike /var/tmp, I don't believe /var/run is intended to be a persistent storage location. Additionally, rc.S scrubs /var/run: rm -f /var/run/* /var/run/*/* /var/run/*/*/*.
By default the $XDG_RUNTIME_DIR environment variable is not set in Slackware
XDG_RUNTIME_DIR is usually set by your desktop environment. If you don't have it add it to your X startup file, or something. It should not be set in profile.d.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
