After refactored drm-kmod + gpu-firmware-kmod, cursor is now invisible!

F

flist

Hello, I've already posted here about this problem, but I thought I'd make another post in a different category since I don't think it's a problem with peripherals; rather, it is a problem with the refactored drm-kmod-and-friends ports. I hope that's allright! ☺️

I am on a laptop, specifically, an Acer SF314-42-R7S8 (surprisingly, FreeBSD has been working better for me than some Linux distros). It's got an AMD processor with integrated Renoir series GPU. I'm using FreeBSD 13.1-RELEASE.

To sum it up, on KDE and XFCE, my mouse cursor is invisible (meaning I cannot see it, but I can still click buttons and such) until I switch to a TTY (with ctrl + alt + f[0-6]) and then back to the DE, after which everything works as it should. What's more, on a Wayland compositor (River), nothing renders at all until I switch to and from a TTY.

There are no notable errors in my Xorg logs, but every time I do a startx, this interesting error pops up in dmesg:
Code: 
drmn0: 0xfffff80263f7b800 pin failed
[drm ERROR :dm_plane_helper_prepare_fb] Failed to pin framebuffer with error -12
The hexadecimal number changes a little bit every time though.

I use packages as much as possible; however, drm-kmod/ drm-54-kmod, which are the only packaged DRM kernel modules, do not work for me, so I compile drm-510-kmod and gpu-firmware-amd-kmod-renoir from ports. I hope this isn't a problem with mixing ports and packages! 😖

I did not have this problem in FreeBSD 13.1-RC6 (before the drm-kmod-and-friends ports were refactored).

I do not have any Xorg configuration files. I even tried doing a fresh install of FreeBSD 13.1-RELEASE and installing only the necessary software to get a graphical environment running, and the problem still persists.
 
Hi,

as a workaround try: (as the graphicially logged-in user and DISPLAY environment variable correctly defined)
xrandr -x
xrandr -x
(yes, two times "xrandr -x")

That helps here on my laptop...
 
Nils Beyer said:
Hi,

as a workaround try: (as the graphicially logged-in user and DISPLAY environment variable correctly defined)
xrandr -x
xrandr -x
(yes, two times "xrandr -x")

That helps here on my laptop...
Click to expand...
Yup, that works too, and so does this workaround by another user with the same issue. Have you tried the workaround I described in the original post (switching to a TTY and back) Nils Beyer ?

I suppose we could do a xrandr -x x2 in a startup script or something until this issue is fixed 💩

Also, the solution in this post doesn't work for me. In fact, if I try to turn software cursor on and do a startx, I only get a black screen, just like what happens when I try to start a Wayland session! I have to perform one of these workarounds, after which everything seems to work like it should.

Another thing of note: if I kill the X or Wayland session, I get put back into the TTY that I launched the session from, but it's totally unresponsive, e.g. I can't type anything and no new text gets rendered. Again, I have to switch to a different TTY and back.

Still no errors in my Xorg logs under any of these workarounds. I just get a DRM error in dmesg every time I do a startx.
 
grahamperrin said:
gpu-firmware-amd-kmod-renoir is packaged, if you want it; <https://www.freshports.org/graphics/gpu-firmware-amd-kmod/#packages>

If you install graphics/gpu-firmware-kmod, is the issue reproducible?
Click to expand...
I know that all of the gpu-firmware-kmods are packaged, I was just thinking someone might ask me what happened if I tried to build it from ports instead of using the package 😌

Just installed gpu-firmware-kmod from packages, the problem persists and only the firmware modules for the Renoir series are loaded.

I've been using latest (not quarterly) packages btw.

Is this a bug then? Should I report it somewhere?
 
You must log in or register to reply here.
Back
Top