Does anyone have KDE on FreeBSD working with multiple monitors?

I'm thinking of migrating this PC (detailed specs at link) with onboard Intel Core 2nd Gen HDMI and VGA out from GhostBSD to FreeBSD with KDE, using the Instant Workstation script. GhostBSD currently just runs just fine with multiple monitors.
Any foreseen problems there? Am I likely to get up and running easily with multiple monitors, or have a bad time?
 
Welp, I couldn't get Instant Workstation to work at all. That just left me with a flashing display at the command prompt where KDE should have started and then a mangled display when I tried to fix that.

Thankfully FuryBSD has a "Configure Xorg" option in the LiveUSB that I was able to use to get up and running. I documented the details of my travails here if anyone else wants to go through the same anachronistic hell I did.

It took me no less than probably 6 hours to figure out all of the above. FreeBSD GPU/display support is still an awful mess. It's really disappointing I had to jump through so many hoops and roadblocks to get something most other projects accomplish quite easily in 2020.
 
Meh. The kms-drm port is mostly for Haswell+, nobody really tests it with i3-2100. Contrary to popular opinion, support for obsolete hardware does not tend to improve with the time.
 
Works just fine in Debian and even OpenIndiana. No reason for FreeBSD to be below par here.
 
It actually didn't. That just mangled my display. Read the link I posted as to how I got it to work in the end.
 
There is: https://github.com/jdrch/Hardware/w...up-multiple-monitors-on-dell-optiplex-390-sff

Says which driver package to pick in FuryBSD. That driver package is not in the Instant Workstation setup, but it shouldn't have to be, either. The OS installer should do all of this automatically like OpenIndiana manages to do.

I should also add that none of this is in FreeBSD's documentation, which not treats the drm-kmod as being the only Intel driver available but doesn't specify what else to use based on hardware. It's all left for the unfortunate user to painfully muddle through. That's sadistic.
 
The last time I installed FreeBSD on my desktop was 2015 (I just keep updating it and that's it). There is no way for me to guess what a third option from the top in the FuryBSD installer dialog means. In any case, xf86-video-intel (?) is an Xorg driver and not a kernel module.
 
> xf86-video-intel

I think that's the one, thanks

🤷‍♂️🤷‍♂️🤷‍♂️ the fact that we're having this conversation at all just to get a DE to show up properly on a display in 2020 is the problem. The OS installer should at least offer the user the option to pull in non-free drivers so that it can then signal to any DE which one to use during setup in the same way NIC drivers work out of the box. Possible wrong terminology or process there (I'm not a developer), but as I said, even the much less supported OpenIndiana gets this correct for integrated GPUs right off the bat.

Given the fact that other projects have long solved this problem, the FreeBSD status quo seems like a deliberate attempt to make DE setup as painful as literally possible for end users, for its own sake. I don't get understand how things are this bad.
 
No, FreeBSD intentionally doesn't have any DE setup. We don't even want those users. Either you have basic debugging and C coding skills, or you will have a very bad experience with the system.

We only having this conversation because you keep wrongly insisting that FreeBSD is in competition with Ubuntu, Fedora and other supposedly user-friendly Linux distributions.
 
No, FreeBSD intentionally doesn't have any DE setup. We don't even want those users. Either you have basic debugging and C coding skills, or you will have a very bad time with the system.

Appreciate the honesty. However, this attitude presents a serious risk to the future of the OS, especially because it's open source. The first project that makes a true FreeBSD (not an OpenRC amalgam like GhostBSD) desktop distribution that works out of the box will effectively control the direction of the project in the long term, by the sheer eventual size of its userbase. This will occur regardless of whether the core FreeBSD dev team wants it to happen, whether next year or decades from now.

As an example, that's what occurred with Debian and Ubuntu. Ubuntu made things easier, people flocked to it, and now the long term direction of Linux as end users experience it is determined to a far greater extent on what Canonical and Red Hat (via systemd) do than what more "foundational" distributions with stronger philosophical principles like Debian do.

In other words, it may be better for the FreeBSD devs to support desktop users on their own terms than have another group of people dictate those terms to them down the road.
 
Ever heard of ArchLinux :) ? It's one of the most popular Linux distributions and it doesn't have a graphical installer. If (while?) FreeBSD in its current state isn't interesting even to this audience, there is no point in going after Ubuntu users.
 
Ever heard of ArchLinux :) ? It's one of the most popular Linux distributions and it doesn't have a graphical installer. If (while?) FreeBSD in its current state isn't interesting even to this audience, there is no point in going after Ubuntu users.

You may be (pleasantly?) surprised. From my observation of the Linux community there's a growing dissatisfaction with how things are proceeding with systemd. More specifically, folks are concerned that systemd by virtue of its userbase is more or less forcing everything else to support it with little input or control from those other things. As with Ubuntu, systemd grew out of incumbent init system( dev)s adopting an attitude similar to FreeBSD's current one towards DEs.

Anyway, if those people start eyeing FreeBSD as a solution and bring their manpower to bear, watch out. You're correct that it's not currently an issue. My advice is to merely head off a possible revolution by implementing a few basic reforms. I'm not suggesting that FreeBSD ship a DE by default; just that it makes setting one up more frictionless. If that happens, potential "renegades" may figure it's "good enough" and use it. That way, an eventual desktop FreeBSD OS would still be true to FreeBSD's principles, even without direct DE dev support from the FreeBSD core dev team.
 
That "frictionless" part depends on the linuxkpi-based port of the Linux graphics stack, which is developed by volunteers. Said volunteers barely have time to test their own hardware and keep this whole thing from actively regressing. (You are definitely not helping by complaining on forum instead of writing a bug report.)

if those people start eyeing FreeBSD as a solution and bring their manpower to bear, watch out.

Graphical installers do not bring kernel developers. Money, on the other hand… I don't see anyone willing to pay for that, though.
 
That "frictionless" part depends on the linuxkpi-based port of the Linux graphics stack, which is developed by volunteers. Said volunteers barely have time to test their own hardware and keep this whole thing from actively regressing. (You are definitely not helping by complaining on forum instead of writing a bug report.)


Patience, my friend. Filing a bug report is my next step. Discussing the issue 1st in an open forum is a good low cost way to discover how to properly describe, present, and contextualize the bug. Now that I know from your own statement that DE support is something FreeBSD devs might be actively opposed to, I know what direction my arguments in the bug report should take. Thanks for your input :)
 
Appreciate the honesty. However, this attitude presents a serious risk to the future of the OS, especially because it's open source. The first project that makes a true FreeBSD (not an OpenRC amalgam like GhostBSD) desktop distribution that works out of the box will effectively control the direction of the project in the long term, by the sheer eventual size of its userbase. This will occur regardless of whether the core FreeBSD dev team wants it to happen, whether next year or decades from now.

As an example, that's what occurred with Debian and Ubuntu. Ubuntu made things easier, people flocked to it, and now the long term direction of Linux as end users experience it is determined to a far greater extent on what Canonical and Red Hat (via systemd) do than what more "foundational" distributions with stronger philosophical principles like Debian do.

In other words, it may be better for the FreeBSD devs to support desktop users on their own terms than have another group of people dictate those terms to them down the road.

Freebsd has always been beholden to outside influences for an X and desktop environment. It's a matter of design ethos and, i expect, manpower. Servers, by and large, don't require graphics. Perhaps you need a spin-off FreeBSD-workstation to be formed? Oh wait, isn't that GhostBSD?

Can you not just replace whatever desktop is used by GhostBSD with KDE and make your life do much simpler? ;)
 
Can you not just replace whatever desktop is used by GhostBSD with KDE and make your life do much simpler? ;)

That's a good question. Perhaps ironically, I'm coming from GhostBSD. The problem with GhostBSD, and Project Trident which I used before it, is it uses OpenRC instead of rc.d, while just about everything in the FreeBSD packaged ports repo is developed for rc.d. The result is that many 3rd party packages simply don't work on such OSes, and the sparse (and written for Gentoo) OpenRC documentation doesn't help, either. Also, FreeBSD's documentation quite rightly assumes rc.d. This leaves GhostBSD in a kind of no man's land where it installs just fine out of the box but isn't really supported by anything. I know this by having run Trident and/or GhostBSD since December 2018.

So I've been trying to get closer (in terms of codebase) to FreeBSD proper while still getting a DE. Adriaan de Groot's Instant Workstation script may have worked if I were using newer hardware (which, again, ironically I'm not because I didn't want to use anything too new for FreeBSD support, among other reasons), but it didn't.

FuryBSD gets me where I want to be for now: FreeBSD(including rc.d) + KDE. Perhaps when I'm able to upgrade to a newer machine (this one cost me 5 USD as a castoff from work) I can use the FreeBSD installer and try Instant Workstation again with better results.

In the meantime, I'm excited to customize KDE - my 2nd favorite DE - and continue my FreeBSD(ish) journey.
 
For what it's worth (and this isn't KDE) but with an NVidia card, I just used the GUI nvidia-settings program which saw all 4 monitors and configured them. But I wasn't using a script to go from a desktop oriented BSD either, this was on a fresh install. Just sort of throwing this out there, in case you decide it's worth it to get an NVidia card and do a fresh install. (During installation, it's just in one monitor. After installation, I install xorg-server, NVidia drivers, etc.)
 
That's a good question. Perhaps ironically, I'm coming from GhostBSD. The problem with GhostBSD, and Project Trident which I used before it, is it uses OpenRC instead of rc.d, while just about everything in the FreeBSD packaged ports repo is developed for rc.d. The result is that many 3rd party packages simply don't work on such OSes, and the sparse (and written for Gentoo) OpenRC documentation doesn't help, either. Also, FreeBSD's documentation quite rightly assumes rc.d. This leaves GhostBSD in a kind of no man's land where it installs just fine out of the box but isn't really supported by anything. I know this by having run Trident and/or GhostBSD since December 2018.

Ok, that makes it clearer why you seem to be butting heads for no good reason.

I dare say you'll have more chance persuading GhostBSD maintainers to change their init system than you will convincing FreeBSD core to incorporate X and a DE into a FreeBSD OS... ;)

So I've been trying to get closer (in terms of codebase) to FreeBSD proper while still getting a DE. Adriaan de Groot's Instant Workstation script may have worked if I were using newer hardware (which, again, ironically I'm not because I didn't want to use anything too new for FreeBSD support, among other reasons), but it didn't.

FuryBSD gets me where I want to be for now: FreeBSD(including rc.d) + KDE. Perhaps when I'm able to upgrade to a newer machine (this one cost me 5 USD as a castoff from work) I can use the FreeBSD installer and try Instant Workstation again with better results.

In the meantime, I'm excited to customize KDE - my 2nd favorite DE - and continue my FreeBSD(ish) journey.


Back to your original 'gripe' about FreeBSD and X/GUI, I think what's needed is a major re-write of the documentation by people(s) that use a desktop environment within FreeBSD. I am not a DE user myself of FreeBSD but on the odd occasions I've tinkered, it is a nightmare and it shouldn't be.

Bringing together such information into one coherent document would make people like yourself's job a tad easier. (IMHO)
 
For what it's worth (and this isn't KDE) but with an NVidia card, I just used the GUI nvidia-settings program which saw all 4 monitors and configured them. But I wasn't using a script to go from a desktop oriented BSD either, this was on a fresh install. Just sort of throwing this out there, in case you decide it's worth it to get an NVidia card and do a fresh install. (During installation, it's just in one monitor. After installation, I install xorg-server, NVidia drivers, etc.)

Appreciate the data point :)
 
I dare say you'll have more chance persuading GhostBSD maintainers to change their init system than you will convincing FreeBSD core to incorporate X and a DE into a FreeBSD OS... ;)

Perhaps on the former. However, the latter is not what I'm trying to attempt. Ideally, I'd like FreeBSD to be able to automatically select and configure the appropriate driver (perhaps after the user has enabled prompted access to non-free binaries?) for the GPU in the same way it automatically loads proper NIC drivers, for example. If the OS covers the driver scripts like Adriaan's Instant Workstation would be pretty much guaranteed to work.

As I said, minor reform ... ;)

Back to your original 'gripe' about FreeBSD and X/GUI, I think what's needed is a major re-write of the documentation by people(s) that use a desktop environment within FreeBSD. I am not a DE user myself of FreeBSD but on the odd occasions I've tinkered, it is a nightmare and it shouldn't be.

Bringing together such information into one coherent document would make people like yourself's job a tad easier. (IMHO)

Amen to that.
 
Back
Top