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.
Ya I got a AMD Radeon RX 5500 (navi14, LLVM 13.0.0, DRM 3.46, 5.18.7)
I needed to update my Mesa to atleast Mesa 22.1.2 or Mesa 22.2.0-devel as well as libdrm-2.4.110 and this is on Slackware 15.0
All of that was just to play a DirectX12 game called Halo Infinite, Having the new Mesa 22 version at least in extra or testing would be a good thing to do, doesn't mean Mesa Amber has to be deprecated just give us the option thats all.
Again, the Mesa Amber is not fully maintained as LTS until 2026, BUT only the legacy non-Gallium drivers, which was removed since Mesa 22.0.x.
What is the sense to keep in the /extra folder the main developed Mesa, while keeping in the main tree a legacy Mesa Amber?
In fact, I started to believe that we do not need Mesa Amber at all in the Slackware-current. For what that?
I have a box which has a Intel GMA3150 graphics, capable only of OpenGL 1.4 and not supported by the Crocus which replaced the i965 driver since Mesa 22.0.x .
I've tested the Mesa 22.1.2 on this particular box, and obviously I've got the usage of LLVMpipe as Mesa driver.
Believe or not, this LLVMpipe driver of Mesa gives subjectively better performance than the original OpenGL 1.4 capable driver. Plasma5 is not hardly more sluggish than with i965 usage, and the box doesn't even have a powerful CPU, but a Core 2 Duo E4500.
So, from my practical experience, I think that the LLVMpipe is enough until the user discover that he wants the hardware barely-accelerated driver from Mesa Amber. Then, this particular user may find a Mesa Amber package on slackbuilds.org
Long story short, I believe that all we need is to resume the updates of Mesa on -current and call a day. Mesa Amber is a false problem for us.
Last edited by LuckyCyborg; 06-29-2022 at 10:44 AM.
I don't have a dog in this fight, as it were, since I've got an nvidia card, but I brought it up because it's going to be an issue for people with newer AMD video cards (I'm assuming) and those who game with proton. Maybe newer mesa in extra? That way it's there for those who need it, and people with older cards will still have support.
I don't have a dog in this fight, as it were, since I've got an nvidia card, but I brought it up because it's going to be an issue for people with newer AMD video cards (I'm assuming) and those who game with proton. Maybe newer mesa in extra? That way it's there for those who need it, and people with older cards will still have support.
By older cards you probably mean "really older cards" because the current Mesa support anything which has at least OpenGL 2.0 support, as usual.
And the newer Mesa is also important for people who have Intel graphics or relative old AMD graphics. Crocus has better support for OpenGL on the devices which support this, and Radeon HD5000 series got NIR.
the recent update to Texlive 2022 removed many Latex packages such as "subfigure" and others.
Comparing texlive-2021 on Slackware-15.0 w.r.t. texlive-2022 on Slackware-current there
are about 517 missing Latex packages (under usr/share/texmf-dist/tex/latex).
the recent update to Texlive 2022 removed many Latex packages such as "subfigure" and others.
Subfigure is depricated, "subfig" and "caption" as recommended alternatives are provided in the recent update.
Quote:
Comparing texlive-2021 on Slackware-15.0 w.r.t. texlive-2022 on Slackware-current there
are about 517 missing Latex packages (under usr/share/texmf-dist/tex/latex).
Please, restore the missing packages. Thank you.
There were a lot of useless packages included sneaked in as dependencies for other packages where other dependecies were not.
The list of packages to be included in the texmf-tree is now way more maintainable, before it wasn't that obvious what
would land in there.
Instead of bloating texlive again, requests for named single packages are more helpful IMHO.
Instead of bloating texlive again, requests for named single packages are more helpful IMHO.
It might also be worth saying that some of the "bloat" can be installed as the texlive-extra package from slackbuilds.org. However, packages from slackbuilds.org might work best if you run a stable version of Slackware. IMHO it is a good thing that Slackware does its best to fit the installation media on a DVD. At the time of this writing the source directory has been removed from the installation isos to make them fit on a DVD.
Subfigure is depricated, "subfig" and "caption" as recommended alternatives are provided in the recent update.
There were a lot of useless packages included sneaked in as dependencies for other packages where other dependecies were not.
The list of packages to be included in the texmf-tree is now way more maintainable, before it wasn't that obvious what
would land in there.
Instead of bloating texlive again, requests for named single packages are more helpful IMHO.
The removal of some of those packages (e.g. mdframed, comment, ...) broke many
latex documents compilation on my machine.
I don't think that all of those packages are deprecated and I think that the the removal
should be motivated/reported somewhere (I don't find it on Slackware-current changelog)
or at least they should be moved in texlive-extra IMHO.
@eming, the list is not that useful, please just send package names(e.g. mdframed, comment, ...) that are really in use by you.
If these aren't that big, there's a good chance to add them back.
Quote:
I don't think that all of those packages are deprecated and I think that the the removal
should be motivated/reported somewhere (I don't find it on Slackware-current changelog)
or at least they should be moved in texlive-extra IMHO.
These are not all deprecated for sure(and some where renamed btw.), and removals/additions should surely be not that much
in the future.
Every package that is not in texlive is in texlive-extra, but -current has no own texlive-extra on SBo.
You could build a corresponding texlive-extra with the texmf-tree from here
Another option is to build texlive with your own texmf-tree.
@eming, the list is not that useful, please just send package names(e.g. mdframed, comment, ...) that are really in use by you.
If these aren't that big, there's a good chance to add them back.
These are not all deprecated for sure(and some where renamed btw.), and removals/additions should surely be not that much
in the future.
Every package that is not in texlive is in texlive-extra, but -current has no own texlive-extra on SBo.
You could build a corresponding texlive-extra with the texmf-tree from here
Another option is to build texlive with your own texmf-tree.
I'll try to report all the missing packages I need.
Anyway I'm okay with the removal of deprecated packages but I think that the others should be
removed more gradually, if needed, and with a clear motivation in the changelog.
I have a box which has a Intel GMA3150 graphics, capable only of OpenGL 1.4 and not supported by the Crocus which replaced the i965 driver since Mesa 22.0.x .
I've tested the Mesa 22.1.2 on this particular box, and obviously I've got the usage of LLVMpipe as Mesa driver.
Believe or not, this LLVMpipe driver of Mesa gives subjectively better performance than the original OpenGL 1.4 capable driver. Plasma5 is not hardly more sluggish than with i965 usage, and the box doesn't even have a powerful CPU, but a Core 2 Duo E4500.
But from what I know the last KDE desktop supporting OpenGL 1.4 was KDE4 and Plasma5 will fallback to swrast when there is not available at least OpenGL 2.0
How did you instructed Plasma5 to use OpenGL 1.4, offered by Intel GMA3150, when there is no support for it?
Last edited by ZhaoLin1457; 07-01-2022 at 03:00 AM.
But from what I know the last KDE desktop supporting OpenGL 1.4 was KDE4 and Plasma5 will fallback to swrast when there is not available at least OpenGL 2.0
How did you instructed Plasma5 to use OpenGL 1.4, offered by Intel GMA3150, when there is no support for it?
Yeah, it's true that Intel GMA3150 gives only OpenGL 1.4 and that Plasma5 requires at least OpenGL 2.0 ...
BUT, there is a trick to make Mesa i915 driver to give OpenGL 2.1 on Intel GMA3150 by instructing it to emulate in software some missing features.
Long story short, bellow is the content of file /etc/drirc (or ~/.drirc) to make this setup.
However, you should do not expect spectacular performances.
In practice, the Plasma5 works with its KWin effects functional, BUT you should disable the taskbar thumbnails, and the effects: Blur and Background Contrast, because those things are painfully sluggish. But in the end you get a bit sluggish but usable desktop.
And please note that this is just a particular case, because if you are lucky owner of OpenGL 1.4 hardware of another type or vendor, you are stuck with LLVMpipe on Plasma5.
Just like you will be with Mesa 22.1.x and later, anyway.
Last edited by LuckyCyborg; 07-01-2022 at 03:41 AM.
This new release adds a new wl_pointer high-resolution scroll event,
adds a few new convenience functions, and contains a collection of
bug fixes.
This is the first release to use GitLab releases instead of the usual
wayland.freedesktop.org website. The new links are available at the
end of this email, or in the GitLab UI.
In practice, the Plasma5 works with its KWin effects functional, BUT you should disable the taskbar thumbnails, and the effects: Blur and Background Contrast, because those things are painfully sluggish. But in the end you get a bit sluggish but usable desktop.
And please note that this is just a particular case, because if you are lucky owner of OpenGL 1.4 hardware of another type or vendor, you are stuck with LLVMpipe on Plasma5.
Just like you will be with Mesa 22.1.x and later, anyway.
I understand. I have only one another curiosity: with this drirc workaround will work also the Wayland sessions of Plasma5?
I ask because I've heard that OpenGL 2.1 is enough for having functional Wayland sessions on Plasma5.
Last edited by ZhaoLin1457; 07-01-2022 at 11:28 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.
