Date: Mon, 25 Nov 2024 17:02:10 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 282964] efifb does not reactivate the screen after resuming from S3 Message-ID: <bug-282964-227-ddviD0cTHl@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-282964-227@https.bugs.freebsd.org/bugzilla/> References: <bug-282964-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D282964 --- Comment #2 from keivan@motavalli.me --- (In reply to Ed Maste from comment #1) yes, that would help! I used to test release out of the box from the instal= ler image to see if acpi was working and got the wrong impression. But on some headless systems it might be desirable to be capable of suspend= ing and resuming while still having the opportunity of using the system locally (i.e. not only via ssh) while only using drivers from the base system. I poked briefly into the freebsd nvidia-drm driver and it looks like it's calling functions from their binary object file when responding to suspend = and resume events, but on the other hand, nvidia's new open source kernel driver for linux does not rely on functions of the proprietary blob for this job, only calling standard drm helpers from the kernel (and works): if (suspend) { drm_kms_helper_poll_disable(dev); drm_fb_helper_set_suspend_unlocked(dev->fb_helper, 1); drm_mode_config_reset(dev); } else { #resuming drm_fb_helper_set_suspend_unlocked(dev->fb_helper, 0); drm_kms_helper_poll_enable(dev); } } maybe their behaviour could be in part emulated for efifb/vt while not rely= ing on the full drm stuff? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-282964-227-ddviD0cTHl>