# Hardware support in FreeBSD is not so bad: over 90% of popular hardware is supported!



## aponomarenko (Aug 5, 2020)

On the Internet, in specialized communities and on forums, you can often find statements that hardware support in FreeBSD is poor. After six months of research, I was able to understand that the hardware support in FreeBSD is not so bad. I'll explain why next.

How to estimate state of hardware support in the operating system? It would seem that this is simply the ratio of the number of supported devices to the total number of devices on the market. But it's not that simple. First, both quantities are not known exactly or even approximately. Secondly, not all devices are equally popular. There are widely used devices, the support of which is necessary and there are rare ones, the users of which can be counted on one hand. In addition, new device models appear in the world every day as well as new drivers in the operating system, so any assessment quickly becomes outdated.

In order to estimate the number of supported devices in FreeBSD, I had to write a heuristic parser for the kernel sources, as a result of which I was able to get an approximate list of supported PCI and USB devices. The problem with compiling such a list is that not all devices are explicitly mentioned in the kernel code; sometimes a driver supports a whole class of devices without specifying particular model identifiers.

The popularity of devices in users' computers was assessed using the Linux-Hardware.org project, which has accumulated a fairly large user base over 5 years of its existence. A new repository was created specifically for the study, which presents the population of PCI devices on users' computers. Thus, we now know which devices are more important and require better support.

Left a little — to sum up all instances of supported devices and divide by the total number of supported and unsupported ones, and repeat all this for different categories of devices. I posted the results in this repository. The average support level for the most important device categories (Ethernet, WiFi, ATA/IDE/RAID, graphics card, and sound) is about 90% for FreeBSD, and this is the lower bound. The corresponding estimation for OpenBSD is 75%, and for NetBSD it is 60%. The weakest side of FreeBSD, as expected, was the WiFi-cards category, the share of compatible devices in which was just over 70%.

FreeBSD compatible hardware exists and there are many! The problem is rather in the choice of compatible configurations from the whole variety. These are guaranteed to be found in the iXsystems and pfSense stores. You can also find community tested configurations at BSD-Hardware.info, or estimate compatibility using the method described in the article How it fits BSD?.

Thank you all for your attention. Please add probes of any of your computers to the database — this will help a lot with finding BSD-compatible configurations!

*EDIT 1: *In this article, "90% of popular devices" == "90% of all devices taking into account number of their samples". Rare ones are also counted, but with a lower weight.


----------



## Deleted member 63539 (Aug 5, 2020)

Well. I would said FreeBSD's hardware support is only after Linux. It's very good except... anything about Wifi. I have to ditch my usb dongle and bought a very long cable when I switched to FreeBSD.


----------



## Mjölnir (Aug 5, 2020)

It's not to blame FreeBSD, but hardware vendors who do not provide enough info to develop _Open Source_ drivers.
Anyone is free to prefer hardware from vendors who do so.
Linux has a much broader user base, especially regarding consumer hardware, thus more contributors & opportunities to test new hardware.
The last topic underlines my efforts to convince others about the importance of a good user experience for desktop & laptop on standard FreeBSD out-of-the-box.  Enhancing this is a key to enlarge FreeBSD's user base, and will result in more contributors, more installations on servers once these users get responsible to manage projects in their professional career, and better hardware support.


----------



## drhowarddrfine (Aug 5, 2020)

gh_origin Instead of buying a cable, why didn't you just buy a wifi adapter that works with FreeBSD?


----------



## olli@ (Aug 5, 2020)

gh_origin said:


> Well. I would said FreeBSD's hardware support is only after Linux. It's very good except... anything about Wifi. I have to ditch my usb dongle and bought a very long cable when I switched to FreeBSD.


Maybe that was just bad luck. Both the Wifi chip on my PC’s mainboard and the one inside my laptop work fine with FreeBSD. Also, when I grabbed the Wifi USB dongle from my wife’s Windows PC for testing, it also worked out of the box with FreeBSD.


----------



## Alain De Vos (Aug 5, 2020)

For Wifi you just plug a very cheap USB stick in the laptop. And this works perfect.
It is however interesting to know which "categories" of hardware don't work.
Onboard Wifi, old laptops, USB music keyboards, USB audio can be problematic.
Very modern accelerated video cards can be problematic, but Linux has an identical problem.


----------



## kpedersen (Aug 5, 2020)

I for one am very happy that the main thing lacking is wifi adapters. Not only do I have a cupboard full of them (I seem to inherit them for some reason) but they are cheap and very easy to replace. Just grab some off Raspberry Pi centric stores and it is extremely likely they will work.
... *and* I use cabled ethernet anyway XD


----------



## olli@ (Aug 5, 2020)

Alain De Vos said:


> It is however interesting to know which "categories" of hardware don't work.


The LED controller of my mainboard is not supported by FreeBSD:

```
uhid0: <AsusTek Computer Inc. AURA LED Controller, class 0/0, rev 2.00/2.00, addr 1> on usbus0
```
It attaches to uhid(4) because it identifies itself as a HID class device, but there’s nothing I can do with it.

Also, I cannot read the onboard sensors (temperature and fan rotation) with FreeBSD. This is a _major_ problem that affects many popular mainboards. There are some tools in the ports collection that support certain chips (usually via SMB bus), but they don’t work with most of today’s mainboards.

Well, at least I can read the processor’s temperature thanks to amdtemp(4), and the storage devices with smartctl(8). But I would feel a lot better if I could check the CPU fan and the case fan, too.

```
> sysctl dev.cpu.0.temperature
dev.cpu.0.temperature: 35.5C
 > smartctl -A /dev/ada1 // temp
194 Temperature_Celsius     0x0002   139   139   000    Old_age   Always       -       43 (Min/Max 17/55)
 > smartctl -A /dev/nvme0 // sensor
Temperature Sensor 1:               41 Celsius
Temperature Sensor 2:               48 Celsius
```
(In case you wonder, I've configured my shell to use “//” as a global alias for “| egrep -i”.)


----------



## Deleted member 63539 (Aug 5, 2020)

drhowarddrfine said:


> gh_origin Instead of buying a cable, why didn't you just buy a wifi adapter that works with FreeBSD?


Because I'm sure FreeBSD supports my Ethernet Card and don't want to trial and error with these Wifi Adapters.


----------



## Mjölnir (Aug 5, 2020)

Worst problem I had with WiFi was an iwn(4) WLAN chip in an old laptop, until I found out I need to set s/th like `intel_iwn_license_ack="yes"` in loader.conf(5) (old driver, now this seems gone).  For the sensors: Some ACPI vendor-specific  kernel modules provide access to these. E.g `sysctl dev.acpi_ibm`

```
dev.acpi_ibm.0.handlerevents: NONE
dev.acpi_ibm.0.mic_led: 0
dev.acpi_ibm.0.fan: 1
dev.acpi_ibm.0.fan_level: 0
dev.acpi_ibm.0.fan_speed: 3054
dev.acpi_ibm.0.wlan: 1
dev.acpi_ibm.0.bluetooth: 1
dev.acpi_ibm.0.thinklight: 0
dev.acpi_ibm.0.mute: 0
dev.acpi_ibm.0.volume: 5
```


----------



## 20-100-2fe (Aug 5, 2020)

It would be interesting to precisely define the verb "to work" when referring to hardware support.
WiFi "works" under FreeBSD if one just means "provides network connectivity", but it takes its time to "work", to say the least.


----------



## Emrion (Aug 5, 2020)

Comparing to Windows and Linux, FreeBSD has a poor hardware support. We have to face this truth, haven't we?
Why is, without a doubt, interesting, but the fact is there.

Manifacturers of new devices always make a driver for the Microsoft OS and often for Linux. Some people convert Linux drivers to FreeBSD, but it can take a long time.


----------



## Mjölnir (Aug 5, 2020)

20-100-2fe said:


> It would be interesting to precisely define the verb "to work" when referring to hardware support.
> WiFi "works" under FreeBSD if one just means "provides network connectivity", but it takes its time to "work", to say the least.


Why not name what you mean  Many will know what you mean, but some do not...


----------



## drhowarddrfine (Aug 5, 2020)

gh_origin said:


> Because I'm sure FreeBSD supports my Ethernet Card and don't want to trial and error with these Wifi Adapters.


afaik, there's a reliable list of inexpensive wifi adapters used for quite a while on the wiki and probably findable on this forum with a quick search.


----------



## drhowarddrfine (Aug 5, 2020)

Emrion said:


> Comparing to Windows and Linux, FreeBSD has a poor hardware support. We have to face this truth, haven't we?


90% coverage is pretty good, not poor. My high end workstation I built, about six years ago, uses all off-the-shelf components from NewEgg and all of them worked on FreeBSD 7 (or was it 9? Don't recall).


----------



## kpedersen (Aug 5, 2020)

drhowarddrfine said:


> 90% coverage is pretty good, not poor.



Exactly. macOS would be ~3% and users don't moan about that.

Windows 10 would be ~30% (for example doesn't often run on laptops older than 6 years old. No drivers XD).

The only "competition" we have is Linux but frankly they are breaking stuff left right and center. They no longer support the Intel GMA 915 past OpenGL 1.5 anymore as one example.

Also, many of the popular distros don't support 32-bit so instantly FreeBSD wins here


----------



## rootbert (Aug 5, 2020)

well, my new desktop pc is working better under FreeBSD than Linux ... the USB-hardware just works in FreeBSD whereas in Linux I have to find the proper slot that is working


----------



## 20-100-2fe (Aug 5, 2020)

mjollnir said:


> Why not name what you mean  Many will know what you mean, but some do not...



It's no secret FreeBSD's WiFi is very slow. The first time I installed FreeBSD on bare metal, I thought there was a network failure and rebooted the router.... :/

Another example is Intel HDA support, for which a couple of PR are open since 2018 or 2019 and still affecting 13-CURRENT. When you run FreeBSD on a machine using an Intel chipset, sound may work, or it may not. A factor influencing your good fortune is having a display connected to the HDMI port. Frankly, it's not the first thing you'll think of trying when your machine is too busy filling your system logs with error messages to respond...

I give these examples to underline why a clear definition of "working" or "supported" is absolutely required.
And of course, this definition should be rigorously taken into account in the way any research on hardware support is conducted.
Moreover, doing a cross-OS research implies using the same definition with all OS for results to be meaningful.


----------



## kpedersen (Aug 5, 2020)

20-100-2fe said:


> It's no secret FreeBSD's WiFi is very slow..
> 
> Another example is Intel HDA support..



I certainly understand what you are saying and I do agree but Linux is no walk in the park here either. In the past I have had endless issues with alsa. For some reason it would disable my onboard sound and mic and default to some naff microphone and speaker in a cheap £5 usb webcam when it is plugged in.
No amount of fiddling in alsamixer could fix it.

This isn't an issue in itself (I am used to broken crap). However the worst part is that I am fairly sure the drivers were great, it was just the documentation that was lacking. The best I had was a bunch of random forums mostly discussing the Gnome sound GUI or pulseaudio failures. Neither of which I was using.

My experience with Linux wifi mostly revolves around Raspbian and Debian. For some bizarre reason the wpa_supplicant service is configured to interact with dbus rather than a unix descriptor or even read the wpa_supplicant.conf. This dbus daemon is completely machine driven and only useful for desktop environments. So not fit for purpose as a generic computing platform.

So yes, the drivers *are* likely better, but they are let down by an absolute mess of an OS.


----------



## 20-100-2fe (Aug 5, 2020)

kpedersen said:


> For some bizarre reason the wpa_supplicant service is configured to interact with dbus rather than a unix descriptor or even read the wpa_supplicant.conf.



An interesting post is pinned on top of the home page. The same still holds true if you replace the word "FreeBSD" with "Linux".

Each OS has its own way and this is very good. If there were only one OS, we'd have to endure it. As long as they keep being different, we have a choice.

And what's more, we can choose to use these differences as a source of inspiration, not to copy the others, but to nurture our creativity.
DragonFlyBSD, NetBSD and OpenBSD have all implemented interesting things that could inspire FreeBSD, so did Linux.

Hatred is a blindfold and as long as you wear it, you have no other choice than throwing the wheat with the chaff.
It's not a problem, though, it's just sad.


----------



## kpedersen (Aug 5, 2020)

20-100-2fe said:


> Each OS has its own way and this is very good. If there were only one OS, we'd have to endure it. As long as they keep being different, we have a choice.



Well that is kind of true, except many Linux distros do happen to have correct wpa_supplicant defaults (Alpine, Arch, etc). Completely inconsistent.


----------



## phalange (Aug 5, 2020)

aponomarenko said:


> Left a little — to sum up all instances of supported devices and divide by the total number of supported and unsupported ones, and repeat all this for different categories of devices. I posted the results in this repository. The average support level for the most important device categories (Ethernet, WiFi, ATA/IDE/RAID, graphics card, and sound) is about 90% for FreeBSD, and this is the lower bound. The corresponding estimation for OpenBSD is 75%, and for NetBSD it is 60%. The weakest side of FreeBSD, as expected, was the WiFi-cards category, the share of compatible devices in which was just over 70%.



This is very interesting and informative. Did you use R or a spreadsheet, and if so can you push that to git or share it?


----------



## aponomarenko (Aug 6, 2020)

phalange said:


> This is very interesting and informative. Did you use R or a spreadsheet, and if so can you push that to git or share it?



Already published:

Info on supported devices: https://github.com/bsdhw/Drivers/blob/master/freebsd/freebsd-current.list
Info on popularity of devices: https://github.com/linuxhw/DevicePopulation/blob/master/README.md


----------



## phalange (Aug 6, 2020)

aponomarenko said:


> Info on supported devices: https://github.com/bsdhw/Drivers/blob/master/freebsd/freebsd-current.list
> Info on popularity of devices: https://github.com/linuxhw/DevicePopulation/blob/master/README.md


Yes I saw these, I was wondering about the actual calculations. Using your formula I ran a quick pass on a spreadsheet just using the 12.1 hardware data and encryption controllers (since there are few) and found a different result than yours. I wasn't clear if you used only 12.1 or other versions, nor did I check if hardware support differed between them in any event.


----------



## Mjölnir (Aug 6, 2020)

Reminder: there's also BSD Hardware Info


----------



## aponomarenko (Aug 6, 2020)

phalange said:


> Yes I saw these, I was wondering about the actual calculations. Using your formula I ran a quick pass on a spreadsheet just using the 12.1 hardware data and encryption controllers (since there are few) and found a different result than yours. I wasn't clear if you used only 12.1 or other versions, nor did I check if hardware support differed between them in any event.



I forgot to note that I've also counted nvidia, kms-drm and drm-lagacy for FreeBSD. And I've made calculations for 13-CURRENT, not for 12.1.

The formula is the following:

Status = (S1*T1 + S2*T2 + ... + Sn*Tn) / (T1 + T2 + ... + Tn)

Sn — support status of the device (1 — supported, 0 — not supported) from https://github.com/bsdhw/Drivers/blob/master/freebsd/freebsd-current.list

Tn — total number of device samples from https://github.com/linuxhw/DevicePopulation/blob/master/README.md


----------



## baaz (Mar 14, 2022)

Suspend ? Resume?
even on intel hd graphics they dont work
None of the BSDs work
And hibernate is just a meme


----------



## grahamperrin@ (Mar 14, 2022)

aponomarenko said:


> … Thank you all for your attention. Please add probes …











						excessive probing and logging · Issue #123 · linuxhw/hw-probe
					

From hw-probe -help: -probe Probe for hardware. Collect only hardware related logs. Expected With general option -probe, logs not related to hardware must not be collected. Actual result Inappropri...




					github.com
				






baaz said:


> Suspend ? Resume?



FreeBSD bug 260994 – Sleep, wake: document the requirement for Kernel Mode Setting (KMS) drivers; include the console context



baaz said:


> even on intel hd graphics they dont work …



If this is reproducible with graphics/drm-devel-kmod on FreeBSD 13.1-BETA1-p0, please start a separate topic (and provide necessary details). Thanks.


----------



## kpedersen (Mar 14, 2022)

baaz said:


> Suspend ? Resume?
> even on intel hd graphics they dont work
> None of the BSDs work


You can find a number of confirmed machines here:
https://wiki.freebsd.org/SuspendResume

Weirdly, since OpenBSD's work here, I have found their suspend support (on ~1+ years old machines) to be very decent, possibly better than FreeBSD.

https://www.openbsd.org/papers/zzz.pdf

So since you mentioned BSDs in a generic way, you might want to try that out if you haven't already done so.


----------



## bsduck (Mar 14, 2022)

kpedersen said:


> Weirdly, since OpenBSD's work here, I have found their suspend support (on ~1+ years old machines) to be very decent, possibly better than FreeBSD.


Same on my older (~9 years old) Intel-powered machines: OpenBSD has both suspend to RAM and suspend to disk working out of the box. FreeBSD and NetBSD only offer suspend to RAM, and graphics/drm-fbsd13-kmod suffers from PR 253801 making it unreliable on 13.0-RELEASE.


----------



## baaz (Mar 15, 2022)

kpedersen said:


> You can find a number of confirmed machines here:
> https://wiki.freebsd.org/SuspendResume
> 
> Weirdly, since OpenBSD's work here, I have found their suspend support (on ~1+ years old machines) to be very decent, possibly better than FreeBSD.
> ...


I have read that page many times but as you can see there are too few machines confirmed
I also tried OpenBSD and DragonflyBSD From the forums and the documentation, it seems like OpenBSD suspend framework is more robust
But when I tested it didn't even get into the suspend state screen just went black and no response(FreeBSD did and resumed but afterward had problems) From what I saw DragonflyBSD didn't support suspend?! There isn't much decimation either but each suspends state I tested output that it was not supported maybe I did something wrong 
I didn't try NetBSD though because I didn't think its any better than OpenBSD in suspending
And about my point about intel HD graphics is that:
reading the forum posts, it seems like the only thing holding you back from suspending is Nvidia graphics cards I have a pc with Nvidia graphics and it resumes with a black screen as expected But in these two laptops that I tried, they had intel HD graphics and there was no problem with them the screen went black on suspend and woke up on resume as it should
But there where other stuff going wrong   there was no keyboard input
All programs exited with signal 11
And the system kinda froze Not responding to ANYTHING I throw at it
Maybe these two laptops are just really weird ‍♂
Dell latitude e6230
Dell latitude e6220


----------



## bsduck (Mar 15, 2022)

baaz said:


> From what I saw DragonflyBSD didn't support suspend?!


Not on my computers either. Hardware support on DragonFly is quite limited.


----------



## grahamperrin@ (Mar 15, 2022)

NVIDIA graphics



baaz said:


> … reading the forum posts, it seems like the only thing holding you back from suspending is Nvidia …



MarkLinimon/WorkAreaGraphics/NVidia - FreeBSD Wiki

Graphics - FreeBSD Wiki

no mention of NVIDIA
if I understand correctly, there's a plan to "consolidate Graphics and Desktop pages", if/when this happens I guess that it should include or link out to NVIDIA-related information.

My experience around seven months ago – HP ZBook 17 G2 with NVIDIA Quadro K1100M (GK107GLM):

<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257456#c32> after closure of the bug (driver update):



> …
> 
> still, there's failure to wake from sleep.
> 
> Not worth me reporting the bug, because I'll no longer use this computer.





grahamperrin said:


> Failure to wake from sleep is a show-stopper.





grahamperrin said:


> Today I stumbled across this, from around four months before I encountered the failures:
> 
> Experiments with suspend/resume (amd64; nvidia-driver)
> 
> ...


----------



## kpedersen (Mar 15, 2022)

baaz said:


> But when I tested it didn't even get into the suspend state screen just went black


Yeah, many people do experience very different results admittedly.

I can only say that mine have been pretty positive, but I do stick to a very narrow (possibly too narrow) selection of hardware involving different 5+ year old ThinkPads. And for servers, I don't suspend them.

The only different hardware I used did have some quirks:

With NVidia, in the past I have had to simulate the pressing of ctrl-F2, ctrl-F5 to switch to a different VT and back to X11. This seems to have corrected it. I can't remember the tool (in base) used. Does your screen come back if you switch back and forth between VTs?


I did have an old Dell laptop that I tried once. I had to disable the TPM in the BIOS before suspend / resume worked.
If you can, even though there isn't much hardware in that list, just pick up something that is (preferably cheap and second hand). At least then you know it is more guaranteed to work.


----------

