| Age | Commit message (Collapse) | Author |
|---|
|
VT_SETMODE ioctl currently checks the provided signal numbers with its
own ISSIGVALID macro that uses NSIG (32) as a maximum, although the code
that will actually send the signal in sys/kern/kern_sig.c uses
_SIG_VALID which allows up to _SIG_MAXSIG (128).
This change aligns the vt code with the kernel internals and enables the
use of higher signal numbers so that applications are not limited to
SIGUSR1 and SIGUSR2 for vt release and acquire signals.
Signed-off-by: Quentin Thébault <quentin.thebault@defenso.fr>
Reviewed by: emaste, imp, kevans
Differential Revision: https://reviews.freebsd.org/D53615
|
|
Linux does not check that any of the signals in vt_mode VT_SETMODE ioctl
(relsig, acqsig, frsig) are valid, but FreeBSD required that all three
are valid. frsig is unusued in both Linux and FreeBSD, and software
typically leaves it unset. To improve portability, allow frsig to be
set to zero.
PR: 289812
Reported by: Dušan Gvozdenović
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D52835
|
|
Reviewed by: jmg
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D53390
|
|
Add enum sleep_type stype parameter in power_suspend/resume event
handlers, as with the introduction of s2idle there are more than one
type of suspend.
Reviewed by: bz
Approved by: bz
Sponsored by: The FreeBSD Foundation
|
|
Signed-off-by: Matteo Riondato <matteo@FreeBSD.org>
Reviewed by: imp,emaste
Pull Request: https://github.com/freebsd/freebsd-src/pull/1781
|
|
Account for endianness when writing to 24bpp framebuffers. Also create a
vt_fb_mem_wr3 function to avoid code duplication.
Reviewed by: manu, imp
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D50843
|
|
Make sure there is enough room to write more than one byte.
Reviewed by: manu, imp
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D50842
|
|
Neither the ums(4) nor psm(4) reporting can be used by the wsp(4)
driver, as they rely on static-length movements, while wsp(4) may need
to scroll in large amounts per evdev event push.
This style uses a false button-5 press as an indicator that the z-axis
movement is a horizontal scroll, otherwise a vertical scroll.
Signed-off-by: Joshua Rogers <Joshua@Joshua.Hu>
|
|
Pass framebuffer information from loader(8) to the kernel via the
MODINFOMD_EFI_FB metadata field.
Enable the vt_efifb driver. A small tweak is required to work around the
lack of VM_MEMATTR_WRITE_COMBINING on this platform; we use
VM_MEMATTR_UNCACHEABLE instead.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48884
|
|
The way we got the kernel metadata pointer was by calling
preload_search_by_type with one of the following three: "elf kernel",
"elf32 kernel" and "elf64 kernel". Which one(s) we used wasn't
consistent though. Sometimes we would only try "elf kernel", and other
times we would try one of the latter two if the first failed. However,
the loader only ever sets "elf kernel" as the kernel type.
Now, the kmdp is a global, preload_kmdp, and it's initialized using
preload_initkmdp in machdep.c (or machdep_boot.c on arm/64).
preload_initkmdp takes a single boolean argument that tells us whether
not finding the kmdp is fatal or not.
Reviewed by: imp, kib
Pull Request: https://github.com/freebsd/freebsd-src/pull/1394
|
|
On a laptop with no other console devices than the screen, things
scroll of the screen faster than eye or camera can capture it.
This tunable slows the console down and makes it update synchronously,
so console output continues when timers or interrupts do not.
Differential Revision: https://reviews.freebsd.org/D47710
|
|
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
|
|
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.
|
|
Sponsored by: Beckhoff Automation GmbH & Co. KG
|
|
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
|
|
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
|
|
[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
|
|
Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.
Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/
Sponsored by: Netflix
|
|
[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
|
|
[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
|
|
[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
|
|
[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
|
|
[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
|
|
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
|
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
|
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
|
|
This allows us to support this hardware and, in the future, use clocks
so they are enabled past the initial kernel boot process.
Reviewed by: ray
Differential Revision: https://reviews.freebsd.org/D30103
|
|
Mapping the framebuffer with WC (Write Combined) memory type can, in
practice, cause some memory transactions to be rate-limited at a
fraction of the fb write rate. WC allows one core to queue up many
globally visible write transactions, and in the process some unrelated
transactions may end up having to wait for all of the queued up PCI
writes to be flushed.
Add an hw.efifb.cache_attr tunable to allow mapping the framebuffer as
uncacheable instead. We should likely be taking a more careful approach
of checking the memory map to determine which cacheability attributes
are feasible, but the knob lets us use our historically functional
behavior while offering a convenient way to switch on a stock kernel.
The only valid values for hw.efifb.cache_attr at this time are "uc" and
"wc".
Original patch by Marc De La Gueronniere <mdelagueronniere@verisign.com>
along with previous testing.
Reviewed by: imp
MFC after: 1 week
Sponsored by: Verisign, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D17884
|
|
FreeBSD-9 had introduced support for the full set of Unicode
characters to the parsing and processing of keymap character tables.
This support has been extended to cover the table for accented
characters that are reached via dead key combinations in FreeBSD-13.2.
New ioctls have been introduced to support both the pre-Unicode and
the Unicode formats and keyboard drivers have been extended to support
those ioctls.
This commit makes the ABI compatibility functions in the kernel
optional and dependent on COMPAT_FREEBSD13 in -CURRENT.
The kbdcontrol command in -CURRENT and 13-STABLE (before 13.2) has
been made ABI compatible with old kernels to allow a new world to be
run on an old kernel (that does not have full Unicode support for
keymaps).
This commit is not to merged back to 12-STABLE or 13-STABLE. It is
part of review D38465, which has been split into 3 separate commits
due to different MFC and life-time requirements of either commit.
Approved by: imp
Differential Revision: https://reviews.freebsd.org/D38465
|
|
Support for Unicode characters had been added to the keyboard code,
but there are keymaps that have accented characters accessed via dead
key combinations, and those were still restricted to 8 bit codes.
This update to kbd.c adds support for Unicode characters and
compatibility code that allows a kbdcontrol command built from kbio.h
without these patches to work on a new kernel.
Compatibility code that allows a new kbdcontrol binary running on an
old kernel to load and display the dead key map will be committed in a
separate commit.
Reviewed by: imp, brooks
Approved by: brooks
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D38381
|
|
This is useful to the DRM drivers to let them know if a device is
effectively used by the console.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D38089
|
|
of psm(4), ums(4) and sysmouse(4) drivers.
EVIOCGRAB ioctl execution on /dev/input/event# device node gains
exclusive access to this device to caller. It is used mostly for
development purposes and remote control software. See e.g.
https://reviews.freebsd.org/D30020 which is the reason of creation
of this change.
MFC after: 2 weeks
Tested by: corvink
Differential revision: https://reviews.freebsd.org/D30542
|
|
MFC after: 1 week
Sponsored by: NVIDIA Networking
Differential Revision: https://reviews.freebsd.org/D36042
|
|
While at it optimise "case 3" into a default.
This way there is no need to initialize the "mark" variable in the beginning,
because all cases set it.
MFC after: 1 week
Sponsored by: NVIDIA Networking
Differential Revision: https://reviews.freebsd.org/D36042
|
|
No functional change intended.
MFC after: 1 week
Sponsored by: NVIDIA Networking
|
|
MFC after: 1 week
Sponsored by: NVIDIA Networking
|
|
Fixes the following panic backtrace:
panic()
usbhid_sync_xfer()
usbhid_set_report()
hid_set_report()
hidbus_write()
hid_write()
hkbd_set_leds()
hkbd_ioctl_locked()
hkbd_ioctl_locked()
hkbd_ioctl()
kbdmux_ioctl()
vt_window_switch()
vt_switch_timer()
Differential Revision: https://reviews.freebsd.org/D36715
MFC after: 1 week
Sponsored by: NVIDIA Networking
|
|
This matches the return type of pmap_mapdev/bios.
Reviewed by: kib, markj
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D36548
|
|
With clang 15, the following -Werror warning is produced:
sys/dev/vt/vt_core.c:2129:15: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
vt_mouse_paste()
^
void
This is because vt_mouse_paste() is declared with a (void) argument
list, but defined with an empty argument list. Make the definition match
the declaration.
MFC after: 3 days
|
|
U+276E Heavy Left-Pointing Angle Quotation Mark Ornament
U+276F Heavy Right-Pointing Angle Quotation Mark Ornament
U+276F is used by zprezto (zsh config package).
For the normal font I used the bold font glyphs for U+003C < and
U+003E >. The bold font glyphs are new.
PR: 232494
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
|
|
As in the past Dimitar Zhekov provided a copy of Terminus under a BSD
license for use by our console.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
|
|
Suggested by: Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
Differential Revision: https://reviews.freebsd.org/D35552
PR: 263084
MFC after: 1 week
Sponsored by: NVIDIA Networking
|
|
Trim all word separators from end of line, except for last line and
only use '\r' to terminate the pasted lines as expected by TTY.
Submitted by: Ivan Quitschal <tezeka@hotmail.com>
Differential Revision: https://reviews.freebsd.org/D35552
PR: 263084
MFC after: 1 week
Sponsored by: NVIDIA Networking
|
|
This is slightly more optimized than checking panicstr directly. For
most of these instances performance doesn't matter, but let's make
KERNEL_PANICKED() the common idiom.
Reviewed by: mjg
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D35373
|
|
|
|
It simplifies the declaration of the driver structures a little. There
are no current consumers of this macro, in fact it looks like it was
added for exactly this purpose.
This decreases the scope of some variables, so rework the initialization
in vt_init_logos() such that it doesn't require them.
No functional change intended.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D34820
|
|
There's too many broken hardware out there that wrongly has the
ACPI_FADT_NO_VGA bit set. Ignore it unless running as a virtualized
guest, as then the expectation would be that the hypervisor does
provide correct ACPI tables.
Reviewed by: emaste, 0mp, eugen
MFC: 3 days
Sponsored by: Citrix Systems R&D
PR: 230172
Differential revision: https://reviews.freebsd.org/D34392
|
|
PR: 247498
|
|
VGA hardware provides many different graphics and data access modes,
each with different capabilities and limitations.
VGA vt(4) graphics mode operates on blocks of pixels at a time. When a
given pixel block contains only two colours the vt_vga driver uses write
mode 3. When the block contains more than two colours it uses write
mode 0. This is done because two-colour write mode 3 is much more
efficient.
In practice write mode 3 is used most of the time, as there is often a
single foreground colour and single background colour across the entire
console. One common exception requiring the use of mode 0 is when the
mouse cursor is drawn over a background other than black, as we need
black and white for the cursor in addition to the background colour.
VGA's default 16-colour palette provides the same set of colours as the
system console, but in a different order. Previously we configured a
non-default VGA palette that had the same colours at the same indexes.
However, this caused anything drawn before the kernel started (drawn by
the loader, for instance) to change colours once the kernel configured
the new, non-default palette.
In 5e251aec8636 we switched to leaving the default VGA palette in place,
translating console colour indexes to VGA colour indexes as necessary.
This translation was missed for the write mode 0 case for pixel blocks
with more than two colours.
PR: 261751
Reviewed by: adrian
MFC after: 1 week
Fixes: 5e251aec8636 ("vt(4): Use default VGA palette")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34412
|
|
I suspect the variable names and comments were accidentally French.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
|
