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

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
 
Suspend ? Resume?
even on intel hd graphics they dont work
None of the BSDs work
And hibernate is just a meme
 
… Thank you all for your attention. Please add probes


Suspend ? Resume?

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

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.
 
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.
 
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.
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
 
NVIDIA graphics

… 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.

Failure to wake from sleep is a show-stopper.

Today I stumbled across this, from around four months before I encountered the failures:

Experiments with suspend/resume (amd64; nvidia-driver)

Postscript (2021-11-28)

FreeBSD bug 253733 – vesa.ko: Invalid BIOS call when resuming from S3 suspend/sleep causes nvidia driver hang via <https://forums.freebsd.org/posts/504284> thanks Snurg
 
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.
 
Back
Top