Date: Wed, 06 Apr 2022 21:33:05 +0000 From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 263099] vidcontrol(1) -p and -P does not work Message-ID: <bug-263099-1689-xN6Qnf7ghC@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-263099-1689@https.bugs.freebsd.org/bugzilla/> References: <bug-263099-1689@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=3D263099 Tomoaki AOKI <junchoon@dec.sakura.ne.jp> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |junchoon@dec.sakura.ne.jp --- Comment #6 from Tomoaki AOKI <junchoon@dec.sakura.ne.jp> --- (In reply to Chris Hutchinson from comment #5) Are you 100% sure all your hardwares are legacy (non-UEFI) booted? On UEFI, efifb (only usable via vt) is forced and sc is not emulated (by firmware) at all. So nothing can detect legacy (character based) frame buffer on UEFI-booted environment. (For UEFI-capable hardwares with legacy boot ennbled, CSM of U= EFI firmware would take care of it, just stop hiding physical text frame buffer= or emulate actually-nonexistent hardware, which would be dependent on hardware= ). It's a limitation of UEFI, not of FreeBSD. So kern.vty=3Dsc on UEFI-booted environment would be ignored and forced vt. On vidcontrol side, discussions would be needed which to capture, graphical frame buffer or vt-internal text buffer. Someone would want images displayed to be captured, that means, texts are a= lso captured as image, not as characters. But OTOH, others would want only texts to be captured as characters. This is like the behaviour with mice driven by moused. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-263099-1689-xN6Qnf7ghC>