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.
my pc is a Intel G-33/31 with a quad core and 8GB ram yet can not run KDE5. What a laugh since
it ran Windows 10 no problems.
This is exactly the hardware case that LuckyCyborg talked about in various threads. A relatively modern computer, which is stuck in OpenGL 1.4, which is not supported by Plasma 5.
Probably the best solution is to build the i915g driver in Mesa, which offers OpenGL 2.1 for your hardware, but it presents some problems, so if you opt for this solution, you will have to contact the Mesa developers, for bug-reports and ask them to fix this driver.
Another solution is to use a /etc/drirc config file with instructions to enable OpenGL 2.1 for the i915 driver. This solution has some drawbacks, among which it is relatively slow and some desktop effects do not work or are very slow.
Finally, another solution is to use KDE4 or a minimal desktop shell based on KDE4. from which you can use Plasma 5 applications.
From what I've seen, that's what LuckyCyborg is experimenting with now, with the Slackware 15.0 porting of Katana Desktop, which is a small DE based in KDE4. There are various caveats here too, because it is a DE made for BSD, and certain facilities have been removed, so they must be put back by someone with experience in C/C+ programming.
A personal suggestion is that if your computer allows the installation of a discrete graphics card, add one. Almost any of them, for example an old Radeon HD6450 will be more than enough to run Plasma 5 very well and even Windows 10 will be very happy.
Last edited by ZhaoLin1457; 01-31-2023 at 02:15 AM.
so if you opt for this solution, you will have to contact the Mesa developers, for bug-reports and ask them to fix this driver.
Not sure they are very cooperative...
Code:
Back in 2013 was this change to Mesa for always enabling at least OpenGL 2.0 when using the i915 driver.
The argument for it was "There's no point in shipping a non-GL2 driver today."
Back in 2013 was this change to Mesa for always enabling at least OpenGL 2.0 when using the i915 driver.
The argument for it was "There's no point in shipping a non-GL2 driver today."
I didn't talk here about the legacy i915 driver, which is now part of Mesa Amber, but about the Gallium i915g driver, which is even now part of Mesa 22.3.4
This i915g is not enabled in Mesa builds from Slackware 15.0 or -current, probably because it presents bigger problems than i915 and only supports the 4th generation, such as GMA3000.
But this i915g driver (that supports OpenGL 2.1 natively) is still supported by Mesa developers, and I'm sure they can improve it if they see there is interest and bug-reports.
Last edited by ZhaoLin1457; 01-31-2023 at 02:45 AM.
This a bit OT, but KWin sholud be able to run on OpenGL ES 2.0 (note the "ES" part) that is supported by i915.
I don't have the hardware to test it here, but you need this env variable set before starting kde:
This a bit OT, but KWin sholud be able to run on OpenGL ES 2.0 (note the "ES" part) that is supported by i915.
I don't have the hardware to test it here, but you need this env variable set before starting kde:
Code:
export KWIN_COMPOSE=O2ES
Hope it works for you
Nope, this does not gives functional desktop effects on Plasma5's KWin.
I have hardware to test, I tested this already and it does not work.
From my own experience, the single ways to have functional desktop effects on Plasma5 running on hardware like this is either /etc/drirc tuning for enabling OpenGL 2.1 , either building a Mesa package with i915g enabled and i915 disabled.
The best performance is given by Gallium i915g driver, but it has more artifacts than the classic i915 driver. And by "best performance" I mean a behavior almost just like in the better graphics hardware.
On the attached screenshot you can see how behaves Plasma5 running on top of i915g. Please take attention to artifacts on System Settings (hard the miss that red thing) and the background noise on the taskbar's thumbnail (BTW, this thing is animated). Also the notification popups flickers like hell (and same do on classic i915) and sometimes the taskbar flickers - sometimes also flickers the entire desktop (and same do on classic i915).
In other hand, the classic i915 with drirc workaround is more stable, but it's slower, yet still flickers and the taskbar thumbnails are so slow that better to be disabled entirely.
The moral of this story is that Plasma5 behaves like a crap on rather modern computers even with Intel Core2 Quad CPUs and even with 32GB RAM DDR3 at 1333MHz, which are locked on OpenGL 1.4 graphics, thanks to Intel Corp. genius.
From my own experience, as I experiment since several years with this kind of hardware, the best way is to fix Gallium i915g driver. This means people to go on Mesa's bug-tracker and make requests and to make bug reports.
So, people... go ahead and report the issues to Mesa guys and inform them that you want a fully working i915g !
I for one, I would not go there because I am aware of my limitations of handling English language. Apparently, some people feels insulted even if I'll say that "now is evening".
PS. What I find quite strange is that on the Mesa bug-taker are NO bug-reports or feature requests made for i915g by the Slackware Team? I understand the other distributions who already look for x86_64 v3 - then this kind of hardware is obsolete for them, BUT for Slackware, which still ships a 32bits release for the foreseeable future?
Last edited by LuckyCyborg; 01-31-2023 at 07:09 AM.
Also maybe Intel graphics might be better as another thread on here. I won't post anymore on this one about opengl.
Will look at the other ones on here about it.
On your screenshot @LuckyCyborg, Is there any advantage on a 6 series kernel vs. a 5 series on these cpu/chipsets?
Last edited by linuxdaddy; 01-31-2023 at 03:49 PM.
Reason: added a ?
Integrated Graphics Subsystem
6.1 Introduction
This chapter describes graphics subsystem that is integrated into the Q35 GMCH component.
This graphics subsystem employs the use of system memory to provide efficient, economical 2D
and 3D performance.
* Various HTTP/2 Fixes: [Carlos Garcia Campos]
* Fix `content-sniffed` not being emitted for resources without content
* Fix leak of SoupServerConnection when stolen
Changes in libsoup from 3.2.0 to 3.2.1:
* When built against nghttp2 1.50.0+ be relaxed about header whitespace [Carlos Garcia Campos]
* Fix possible crash when cancelling an HTTP/2 message [Carlos Garcia Campos]
* Fix regresion where soup_server_message_get_socket() could return NULL [Carlos Garcia Campos]
* Fix minor memory leak [Milan Crha]
I believe that would be very useful if the Mesa package will be built with both the classic (Amber) and Gallium i915 drivers, because i915g may offer a better performance in particular setups - and some users may prefer it, while the classic i915 may be more stable in another particular setups.
How those two drivers have a naming conflict - both should have the name /usr/lib64/dri/i915_dri.so for a proper working they could be renamed appropriately and added a symlink for the active one.
Here is a patch of Mesa SlackBuild for building and shipping both i915 drivers.
Code:
diff -urN mesa.orig/mesa-amber.build mesa/mesa-amber.build
--- mesa.orig/mesa-amber.build 2022-08-09 00:46:48.013005690 +0300
+++ mesa/mesa-amber.build 2023-02-01 17:01:41.375592083 +0200
@@ -81,9 +81,14 @@
# We will install only the DRI drivers:
mkdir -p $PKG/usr/lib${LIBDIRSUFFIX}/dri
-rsync -lprvt $PKG/cruft/usr/lib${LIBDIRSUFFIX}/dri/ $PKG/usr/lib${LIBDIRSUFFIX}/dri/
+rsync -lprvt --hard-links $PKG/cruft/usr/lib${LIBDIRSUFFIX}/dri/ $PKG/usr/lib${LIBDIRSUFFIX}/dri/
rm -rf $PKG/cruft
+# Rename the classic i915 driver:
+( cd $PKG/usr/lib${LIBDIRSUFFIX}/dri
+ mv i915_dri.so i915_dri.so-classic
+)
+
rm -rf $PKG/usr/doc/$PKGNAM-$AMBERVERS
mkdir -p $PKG/usr/doc/$PKGNAM-amber-$AMBERVERS
cp -a \
diff -urN mesa.orig/mesa.SlackBuild mesa/mesa.SlackBuild
--- mesa.orig/mesa.SlackBuild 2022-12-07 20:37:26.799032342 +0200
+++ mesa/mesa.SlackBuild 2023-02-01 17:01:59.777362030 +0200
@@ -34,7 +34,7 @@
NUMJOBS=${NUMJOBS:-" -j$(expr $(nproc) + 1) "}
# Be sure this list is up-to-date:
-GALLIUM_DRIVERS="nouveau,r300,r600,svga,radeonsi,swrast,virgl,iris,crocus,zink"
+GALLIUM_DRIVERS="nouveau,r300,r600,svga,radeonsi,swrast,virgl,iris,crocus,i915,zink"
if [ -z "$ARCH" ]; then
case "$( uname -m )" in
@@ -157,6 +157,11 @@
mv $PKG/etc/drirc $PKG/etc/drirc.new
fi
+# Rename the Gallium i915 driver:
+( cd $PKG/usr/lib${LIBDIRSUFFIX}/dri
+ mv i915_dri.so i915_dri.so-gallium
+)
+
# Add a default provider for glvnd when the vendor cannot be determined:
( cd $PKG/usr/lib${LIBDIRSUFFIX}
if [ ! -r libGLX_system.so.0 ]; then
@@ -172,6 +177,11 @@
. $CWD/mesa-demos.build
fi
+# Use the classic i915 driver by default:
+( cd $PKG/usr/lib${LIBDIRSUFFIX}/dri
+ ln -sf i915_dri.so-classic i915_dri.so
+)
+
# Strip binaries:
find $PKG | xargs file | grep -e "executable" -e "shared object" | grep ELF \
| cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null
The idea behind this renaming of the i915 drivers is an easy identification of the currently used driver in an eventual script in the nvidia-switch style for switching them or even for handling them manually, giving something like while is used i915g driver:
Please note that with those changes, the classic i915 driver is still used by default, then no behavior changes of Mesa package is expected, only that i915g is available too and it's possible to be enabled by changing a symmlink target.
Last edited by LuckyCyborg; 02-01-2023 at 09:44 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
