FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F14.3.0 2024-11-04T13:54:10Z 2024-11-04T13:54:10Z Ed Maste emaste@FreeBSD.org 2024-11-01T16:29:32Z urn:sha1:752c25c01c171811bab622b558e97d611c228c7d The KDMKTONE ioctl, introduced in commit 916347f77e6c, is used to beep the PC speaker. For historical reasons the frequency is specified as an 8254 PIT divisor for a 1.19MHz clock. Linux provides this same ioctl. Add a comment to vtterm_beep to avoid someone wanting to "fix" this in the future. Also add an XXX comment that the period unit is supposed to be "timer ticks." Note that nothing in the base system uses this ioctl. Reviewed by: imp Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D47395 (cherry picked from commit adba3c74209eb5d2197b9092002cc9d7505fd3c6) 2024-11-03T16:57:19Z Warner Losh imp@FreeBSD.org 2021-11-03T21:55:55Z urn:sha1:1c9f1cb4f0a71bef37796a8ba139b86cc716ee88 386BSD provided a MD function sysbeep. This took two arguments (pitch and period). Pitch was jammed into the PIT's divisor directly (which means the argument was expected to sound a tone at '1193182 / pitch' Hz). FreeBSD inherited this interface. In commit e46598588587 (svn 177642, Mar 26 2008), phk changed this function to take a tone to sound in hz. He converted all in-tree instances of 1193182 / hz to just hz (and kept the few misguided folks that passed hz directly unchanged -- this was part of what motivated the change). He converted the places where we pre-computed the 8254 divisor from being pitch to 1193182 / pitch (since that converts the divisor to the frequency and the interfaces that were exposed to userland exposed it in these units in places, continuing the tradition inherited from SCO System V/386 Unix in spots). In 2009, Ed Shouten was contracted by the FreeBSD Foundation to write / finish newcons. This work was done in perforce and was imported into subversion in user/ed/newcons in revision 199072 (https://svnweb.freebsd.org/base?view=revision&revision=199072) which was later imported into FreeBSD by ray@ (Aleksandr Rybalko). From that earliest import into svn import to this date, we ring the bell with: sysbeep(1193182 / VT_BELLPITCH, VT_BELLDURATION); where VT_BELLPITCH was defined to be 800. This results in a bell frequency of 1491Hz, more or less today. This is similar to the frequency that syscons and pcvt used (1493Hz and 1500Hz respectively). This in turn was inherited from 386BSD, it seems, which used the hard coded value 0x31b which is 795 -> 1500Hz. This '800' was intended to be the bell tone (eg 800Hz) and this interface was one that wasn't converted. The most common terminal prior to the rise of PCs was the VT100, which had an approximately 800Hz bell. Ed Shouten has confirmed that the original intent was 800Hz and changing this was overlooked after the change to -current was made. This restors that original intent and makes the bell less obnoxious in the process. Reviewed by: des, adrian Differential Revision: https://reviews.freebsd.org/D32594 Sponsored by: Netflix (cherry picked from commit ba48d52ca6c867559156dd916631f9ac47abe80f) This change was accidentally reverted in 80f21bb039ce. (cherry picked from commit 2416be588ea113cc06b924ed85861ed3bc391fe0) 2024-07-29T16:37:44Z Emmanuel Vadot manu@FreeBSD.org 2024-07-09T12:38:41Z urn:sha1:82829e49e627c17041c7c0dddde58f1f3481e982 If loader(8) gives use a splash screen to use using the MODINFOMD_SPLASH type, use it if RB_MUTE is set to "YES". By design only argb data will be displayed. Differential Revision: https://reviews.freebsd.org/D45931 Reviewed by: imp, tsoome Sponsored by: Beckhoff Automation GmbH & Co. KG (cherry picked from commit f6e8b0e85081681100bf9cd74423be02233204bc) 2024-07-29T16:37:12Z Emmanuel Vadot manu@FreeBSD.org 2024-07-09T12:35:12Z urn:sha1:01215ffec65ae607a0583c564158097b5d56e531 This blit an ARGB image on the dedicated vd. This also adds vt_fb_bitblt_argb which will works for most of the vt backends Differential Revision: https://reviews.freebsd.org/D45929 Reviewed by: tsoome Sponsored by: Beckhoff Automation GmbH & Co. KG (cherry picked from commit b93028d8cd3aafc883b5f0ecec65a8a2a30af7f3) 2024-02-17T20:58:35Z Jean-Sébastien Pédron dumbbell@FreeBSD.org 2023-11-29T18:34:48Z urn:sha1:a06b366322fe22b211c16c2b0977fac313dce4e7 [Why] For instance, it gives a chance to the new backend to refresh the screen. This is needed by the vt_drmfb backend and `drm_fb_helper`. This change was lost when I posted changes to reviews.freebsd.org and it broken the amdgpu driver... Thanks to manu@ for reporting the problem and wulf@ to find out the missing change! Tested by: manu Reviewed by: manu Approved by: manu Differential Revision: https://reviews.freebsd.org/D42834 (cherry picked from commit 40c20fc29cad4d38d9a565e9c7ba78612097308e) 2024-02-17T20:58:34Z Jean-Sébastien Pédron dumbbell@FreeBSD.org 2023-11-24T17:30:35Z urn:sha1:fc00c037797457c4bf7e06c207297bf06cc92f33 [Why] This ensures that vtterm_cnungrab() is the mirror of vtterm_cngrab(). And the latter always call vt_window_switch() and thus the backend's vd_postswitch(). This makes sure that whatever the backend did during vtterm_cngrab(), it can undo it during vtterm_cnungrab(). Reviewed by: manu Approved by: manu Differential Revision: https://reviews.freebsd.org/D42752 (cherry picked from commit f18b3ce0b7be0b24a743ec59077ca8e7929a353c) 2024-02-17T20:58:34Z Jean-Sébastien Pédron dumbbell@FreeBSD.org 2023-11-24T17:30:34Z urn:sha1:2567cf1925bdcde0230bddb8ed5ca75056d4afa7 [Why] We want the same behavior at the backend level, regardless if we need to switch the current window or not. Reviewed by: manu Approved by: manu Differential Revision: https://reviews.freebsd.org/D42751 (cherry picked from commit 16b13bd3fd63be56653296ba54956f5526918445) 2024-02-17T20:58:34Z Jean-Sébastien Pédron dumbbell@FreeBSD.org 2023-11-24T17:30:34Z urn:sha1:6b9da4e86ed961f297040bb9a5355e6c941f161b [Why] In the DRM drivers and the integration with vt(4), we need to execute DRM code outside of the vtbuf_lock. The reason is that this DRM code acquires locks which can't be acquired when vtbuf_lock, an MTX_SPIN mutex, is already held. [How] A vt(4) backend can now set the `vd_bitblt_after_vtbuf_unlock` flag to true if it wants to be called outside of vt_buf_lock. In this case, vt(4) uses an internal version of bitblt_text that uses the `vd_drawn` arrays, plus a new `vd_pos_to_flush` array, to track characters to draw/refresh. This internal version then uses the backend's bitblt_bmp callback to draw the characters after vt_buf has been unlocked. Drawing borders and CPU logos is also deferred after the vt_buf lock is released for the same reason. We introduce another lock (a default mutex), only used when the `vd_bitblt_after_vtbuf_unlock` flag is set, to replace part the role of the vt_buf lock and manage concurrent calls to vt_flush(). The `SC_NO_CONSDRAWN` define is dropped because we now always need the `vd_drawn` arrays. Reviewed by: manu Approved by: manu Differential Revision: https://reviews.freebsd.org/D42057 (cherry picked from commit 162a2b858854656ddd6b75d290be8a640ba8f324) 2024-02-17T20:58:34Z Jean-Sébastien Pédron dumbbell@FreeBSD.org 2023-11-24T17:30:33Z urn:sha1:95007bfd64c63f217c97210cd4cdf2d729f2f696 [Why] The same protection was added to vt_flush() in the previous commit. We want the same one in vt_window_switch(): if e.g. the DRM driver panics while handling a call to vt_window_switch(), we don't want to recursively call vt_window_switch() again and trigger another panic. Reviewed by: imp, manu Approved by: imp, manu Differential Revision: https://reviews.freebsd.org/D42750 (cherry picked from commit 24d6f256f825e5d7f8ca6b5d16499f13614f9cdd) 2024-02-17T20:58:34Z Jean-Sébastien Pédron dumbbell@FreeBSD.org 2023-11-24T17:30:33Z urn:sha1:608b1487601177817c27d9dbeec920cdb3a85fb7 [Why] If there is a problem with DRM drivers or in their integration with vt(4) and displaying something on the console triggers a panic, there is a high chance that displaying that panic will trigger another one, recursively. [How] If vt_flush() is called and it detects is is called resursively from another panic, it return immediately, doing nothing, to avoid the risk of triggering another panic. Reviewed by: manu Approved by: manu Differential Revision: https://reviews.freebsd.org/D42056 (cherry picked from commit 049e3fba04e82f840cc43080edade0ed415fee72)