Xorg and KDE does not work on FreeBSD 13, but GhostBSD works. So, what are the relevant config files?

ikevin8me said:
… install GhostBSD again and examine why it works so well.
Click to expand...

You can, although (when attempting to compare) please be aware of the differences arising from OpenRC.

Have you considered reinstalling FreeBSD then following just the Quick start for KDE? It's fairly well tested.

Also/alternatively the KDE-on-FreeBSD disk image that's offered at <https://forums.FreeBSD.org/threads/freebsd-kommunity-edition.78594/post-513391>; preconfigured to use SCFB (non-accelerated; <https://man.freebsd.org/scfb(4x)>). If you can get the desktop environment with this image, then you should be able to reconfigure things to use a more suitable driver although …

… honestly, I'd go for a clean installation of FreeBSD + the Quick start.
 
grahamperrin said:
You can, although (when attempting to compare) please be aware of the differences arising from OpenRC.

Have you considered reinstalling FreeBSD then following just the Quick start for KDE? It's fairly well tested.

Also/alternatively the KDE-on-FreeBSD disk image that's offered at <https://forums.FreeBSD.org/threads/freebsd-kommunity-edition.78594/post-513391>; preconfigured to use SCFB (non-accelerated; <https://man.freebsd.org/scfb(4x)>). If you can get the desktop environment with this image, then you should be able to reconfigure things to use a more suitable driver although …

… honestly, I'd go for a clean installation of FreeBSD + the Quick start.
Click to expand...
Yup. I did a re-installation and followed the FreeBSD/Setup - the same that you gave earlier. I just did "Quick Start" (and also putting "kld_list="i915kms"" as instructed from the "drm-kmod" installation) and "KDE and the rest". It just worked! KDE got started. Beautiful. Thanks!
 
Thanks for the follow-up!

Not everyone can so easily perform a clean installation. So, for future cases, it would be smart to know what exactly went wrong in a case such as yours. I found the same key symptoms (X.Org working – Plasma not working (blank screen, movable pointer) a few times, long ago, however I would not have expected this with FreeBSD 13.0-RELEASE. Guesses, retrospective:
  • something unnecessary (and problematic) was installed; and/or
  • a requirement was not met.
I wonder: did you previously, at any point, install x11/xorg-minimal instead of x11/xorg?

If ever you need a reminder of the package message for drm-fbsd13-kmod, which was installed by drm-kmod: <https://www.freshports.org/graphics/drm-fbsd13-kmod/#message>
 
grahamperrin said:
Thanks for the follow-up!

Not everyone can so easily perform a clean installation. So, for future cases, it would be smart to know what exactly went wrong in a case such as yours. I found the same key symptoms (X.Org working – Plasma not working (blank screen, movable pointer) a few times, long ago, however I would not have expected this with FreeBSD 13.0-RELEASE. Guesses, retrospective:
  • something unnecessary (and problematic) was installed; and/or
  • a requirement was not met.
I wonder: did you previously, at any point, install x11/xorg-minimal instead of x11/xorg?

If ever you need a reminder of the package message for drm-fbsd13-kmod, which was installed by drm-kmod: <https://www.freshports.org/graphics/drm-fbsd13-kmod/#message>
Click to expand...
Yes, I did install x11/xorg previously, and this time as well.

What I installed last time, but not this time was "xf86-video-intel".
 
Thanks,

ikevin8me said:
… x11/xorg previously, and this time as well.
Click to expand...

That's good.

I asked about the other, because currently at <https://community.kde.org/FreeBSD/S..._X.Org_by_using_the_Binary_Package_Management> we see:

… the (recommended) binary package x11/xorg-minimal …
Click to expand...
Click to expand...

– which a casual reader might misinterpret as a recommendation to install x11/xorg-minimal. This is not the recommendation (as far as I recall, it does not fulfil the requirements of e.g. Plasma). I do have edit privileges for the wiki, but I'd like to discuss with other editors before clarifying areas such as this.

What I installed last time, but not this time was "xf86-video-intel".
Click to expand...

Interesting.

Intel aside, for a few minutes …


… if I recall correctly, my long ago experience with things such as x11-drivers/xf86-video-ati-legacy was that they were:
  • sometimes, seemingly required
  • other times, seemingly not required.
Inconsistent behaviours. Impossible to reach a conclusion. At one time (September 2020) with x11-drivers/xf86-video-ati on what was then FreeBSD 13.0-CURRENT, <https://gitter.im/FreeBSDDesktop/Lobby/archives/2020/09/21?at=5f690c83d993b837e07ae450> it seemed that presence was required – plus a requirement for /etc/rc.conf to not specify the kernel module that normally is specified.

Back to Intel …


… more recently, it seemed that not specifying the normally-specified module solved a problem for a user of Intel graphics who did use xf86-video-intel: <https://lists.freebsd.org/pipermail/freebsd-questions/2021-May/294002.html>.


Generally

I sense that in edge cases such as mine, a recommended configuration might work for days or weeks, then:
  • fail after gracefully upgrading packages then restarting the system
– even when what was upgraded has no (or no obvious) relationship to graphics. Then again the recommended configuration might work, then again fail, and so on.

So I stick with an anti-recommended approach that works consistently with no sense of randomness.

Note to self, at the time of writing:

Code: 
% date ; uptime ; freebsd-version ; uname -KU
Sun 23 May 2021 10:19:05 BST
10:19a.m.  up 18:36, 6 users, load averages: 0.55, 0.71, 0.77
14.0-CURRENT
1400013 1400013
% pkg info -x xf86-video kmod
xf86-video-ati-19.1.0_3,1
xf86-video-scfb-0.0.5_2
xf86-video-vesa-2.5.0
drm-devel-kmod-5.4.92.g20210419
gpu-firmware-kmod-g20210330
openzfs-kmod-2021030100
sysctlbyname-improved-kmod-20210223
sysctlinfo-kmod-20210222
virtualbox-ose-kmod-6.1.22
% sysrc -f /etc/rc.conf kld_list sddm_enable always_force_depends kldxref_enable kldxref_clobber
kld_list: fusefs usbhid drm
sddm_enable: YES
always_force_depends: NO
kldxref_enable: NO
kldxref_clobber: NO
%
 
You must log in or register to reply here.
Back
Top