Hi,
I have a ThinkPad E490 laptop with an i5-8265U, which means UHD 620 intel graphics (it doesn't have a second GPU).

After installing, the graphics didn't really work, I had a lot of flickering. (I think 4.4 just doesn't support this GPU.)

1. I tried using the kernel from current and rebuilding X11 from the SlackBuild in slackware64-current/source/x/. This led to stable graphics, but with software rendering: X said something like 'the entry point into the 915 driver does not work'. (Maybe I should have recompiled more of the graphics stack, mesa/libdrm/libevdev/??)
   
2. I built a 4.14 kernel with the config from 14.2 and `yes ""|make oldconfig`, also recompiled X11, and this time also libevdev, libdrm, mesa.
   (I used the x11.SlackBuild from 14.2 with the UPGRADE_PACKAGES=always option. Before that I also restored all the /x/ packages from 14.2 in case the SlackBuild wouldn't create all of them. Is there something else from the graphics stack that I maybe need to recompile?)
   Now I'm getting another error preventing hardware rendering (attaching whole Xorg.0.log):
   Code:

   (EE) open /dev/dri/card0: No such file or directory

Thanks for reading this far. What do you think would be my next option?

Attached Files

Xorg.0.log.txt (43.9 KB, 51 views)

Ways forward I see are

1. Find some part of the graphics stack that I missed and recompile that too for the 4.14 kernel.
2. There is some option in the 4.14 config to enable 'experimental intel graphics support', it didn't really seem to apply to my case but I might try it.
3. Try what I did with 4.14 with a newer 4.x kernel.
4. Retry the current-kernel route, this time recompiling more of the graphics stack.
5. Go to current altogether.

1 members found this post helpful.

Are you in a situation where you can use current?
I have a similar GPU and current works well for me,
If I think back Kernel 4.9 and above seems to be a working Kernel / Intel 620.

-You can likely use the kernel config and version from current on 14.2.

I have the same hardware, and there have been long-standing issues with the UHD 620, e.g. see this thread: https://bbs.archlinux.org/viewtopic.php?id=250765

The kernel from -current is good now I think.
I would revert back to the stock packages for X and all the related bits (mesa, etc), then download and install (using `installpkg' not `upgradepkg') the huge kernel and modules from current and boot from that.

I think your best and easiest option would be to upgrade to -current.

However, if you really want to keep on 14.2, at a minimum I would upgrade to the latest 5.4.x kernel (personally, I would compile it on your system using the config from -current rather than install the packages from -current, just to make sure there's no issues). As for the rest of the software, you'd probably also need to upgrade mesa and all the required dependencies in addition to Xorg. I have tried this in the past. In the lead up to 14.2's release, I was able to upgrade 14.1 to modern packages (at the time) and add better support for my GPU at the time. I tried the same on 14.2 a few months ago, but ran into issues and ended up not having the time to diagnose it properly and reverted to stock 14.2 packages. With more time, I imagine the issues I ran into could be resolved (and if I end up getting quarantined, I might try it again).

Hey, just to give a heads up: after a lot of fruitless work, I just ran with -current. Not marking this as solved because I stated the problem as "under Slackware64 14.2".

And this will never be solved by Slackware itself, because it's about hardware too new for the graphics stack from Slackware 14.2 ...

So, makes no sense to leave unsolved this thread - I for one I will give you the solution: build your own kernel and update your Mesa and Xorg stack, including libdrm and vaapi. Believe or not, I did this in the past. Several times.

I known that's much simpler to just upgrade to Slackware -current, BUT you have a valid solution for Slackware 14.2

2 members found this post helpful.

I tried that, you didn't (on this machine and with the lib versions recent at this point).
Even if it would work, would it be a Slackware64 14.2 Linux?

I had to write this since LuckyCyborgs post did get a "helpful".

Well, I marked it because I've done it too, and can confirm it works exactly like that.
Take for example 14.0, still gets security patches but everything else that might need an upgrade, you're going to have to maintain yourself.
It was always like that, and maintaining your own base packages does not make it any less 14.0 than including a SBo package into it.

I actually successfully reattempted upgrading my graphics stack on 14.2 last summer (a few months after my post in this thread). Here's the packages and versions I used:

I was also running a 5.4.x kernel at the time with a recent kernel-firmware package.

When I did this, I had forgotten about the newer llvm being available in 14.2's extra/ directory. Maybe that would allow bumping the versions higher than I did.

It is not a super easy process since you'll need to go through Alien Bob's git repo of -current to find older SlackBuilds that would work with some of these versions. Then you'll need to go through and remove or comment out the code that removes .la files in those SlackBuilds.

No, it won't be a pure 14.2 install, but our systems never are. We always install things to the system that weren't included. Some will upgrade kernels or other core software they use that is included with the main distro. But, doing this doesn't stop it from having the quintessence of 14.2.

There is no way for Pat to solve this for 14.2 without changing how he manages stable releases. He will likely never provide big version bumps for mesa to add support for new hardware on a stable release. It opens up the possibility of instability, which he is unwilling to do for stable releases. (It's one of the things I love about Slackware!) However, Slackware also doesn't prevent me from upgrading those things. Then I can see if they're unstable on my system and either keep or revert.