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
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
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
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
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 5e251aec86 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: 5e251aec86 ("vt(4): Use default VGA palette")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34412
Previously when double-clicking on the last word on a line we would
select from the beginning of the word to the cursor position, because
we searched forward for a space character to find the end of a word.
Now, use the end of the line if we do not find a space.
PR: 261553
Reviewed by: markj
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34339
Previously when double-clicking on the first word on a line we would
select from the cursor position to the end of the word, not from the
beginning of the line. This is because we searched backward for a
space to mark the beginning of a word.
Now, use the beginning of the line if we do not find a space.
PR: 261553
Reported by: Stefan B.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
In the (extremely unlikely) case of vd->vd_height ==
vt_logo_sprite_height the vd_drawrect code would write outside of
frame-buffer memory.
MFC after: 1 week
Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D34220
vt_fini_logos() calls vtbuf_grow(), which reallocates the console
window's buffer using malloc(M_WAITOK). Because vt_fini_logos() is
called via a callout, we end up panicking if INVARIANTS is enabled.
Fix the problem simply by clearing the logos using a timed taskqueue.
taskqueue_thread is formally allowed to sleep; of course, if we actually
end up sleeping to satisfy the allocation, then we have bigger problems.
PR: 260896
Reviewed by: emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33932
Currently the type isn't set in the fbtype struct so any userland
program that call the FBIOGTYPE ioctl will think it's a FBTYPE_SUN1BW
which is far from the truth.
No app that I found find checks the type but at least now it's correct.
Reviewed by: emaste, tsoome
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33221
Add a new ioctl to vt to make it possible to export RGB offsets
set by vt drivers. This is needed to fix colors on X and Mesa
on some machines, especially on modern PowerPC64 BE ones.
With the appropriate changes in SCFB, to use this ioctl to find
out the correct RGB offsets, this fixes wrong colors on Talos II
and Blackbird, when used with their built-in video cards.
Reviewed by: alfredo
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D29000
I made a mistaking in merging the final commits for the devctl changes. This
adds the 'hushed' variable and has the correct dates for the manuals.
Pointy hat to: imp
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 e465985885 (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
Generate VT events when the bell beeps. When coupled with disabling the
bell,this allows custom bells to be rung when we'd otherwise beep.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D32656
Add the glue needed to listen to TP_SETBELLPD which teken uses to
inform its client drivers about the results of parsing
\e[=<pitch>;<duration>B. It converts these to a Hz value for the
tone/pitch of the bell and a duration in ms. There's some loss of
precision because <pitch> in the escape seuquence is defined to be
(1193182 / pitch) Hz and <duration> is in 10ms units. Also note that
kbdcontrol also parses 'off' but then doesn't send the proper escape
sequence, leading me to wonder if that's another bug since teken
appears to parse that sequence properly and I've added code here to
treat that as the same as quiet or disabled.
In general, Hz from 100 to 2000 is good. Outside that range is possible,
but even at 100Hz the square wave is starting to sound bad and above
2000Hz the speaker may not respond.
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D32620
Change the 'period' argument to 'duration' and change its type to
sbintime_t so we can more easily express different durations.
Reviewed by: tsoome, glebius
Differential Revision: https://reviews.freebsd.org/D32619
On recent OpenBMC firmware, the onboard ASMEDIA video card framebuffer
address was removed from device tree for security purposes (value is set
to zero to avoid leaking the address).
This patch works around the problem by taking framebuffer base address
from the "ranges" property of a parent node.
Reviewed by: luporl, jhibbits (on IRC)
MFC after: 2 weeks
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D30626
Bell is either useless if you're working on remote servers or really annoying
when you're working with a local machine that have a loud buzzer.
Switch the default to have it disable.
Reviewed by: imp, pstef, tsoome
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D32543
In vt_kms, the postswitch callback restores fbdev mode when
panicking or entering the debugger. This ensures that even when
a graphical applicatino was running on the first tty, simple framebuffer
mode would be restored and the panic would be visible instead
of the frozen GUI. But vt wouldn't call the postswitch callback
when we're already on the first tty, so running a GUI on it
would prevent you from reading any panics.
Reviewed by: tsoome
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D29961
These ones were unambiguous cases where the Foundation was the only
listed copyright holder (in the associated license block).
Sponsored by: The FreeBSD Foundation
Some framebuffer properties obtained from the device tree were not being
properly converted to host endian.
Replace OF_getprop calls by OF_getencprop where needed to fix this.
This fixes boot on PowerPC64 LE, when using ofwfb as the system console.
Reviewed by: bdragon
Sponsored by: Eldorado Research Institute (eldorado.org.br)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D27475
- Implements little-endian support (powerpc64le)
- Adds 'hw.ofwfb.physaddr' kernel parameter so user can manually
provide correct address if it's not detected correctly
- Adds 'hw.ofwfb.argb32_pixel' so user can set it manually if
colors are inverted due to incorrect pixel format (default = 1)
- Automatically selects RGBA32 pixel format if NVidia graphic adapter
is detected (sets hw.ofwfb.argb32_pixel=0)
Machines equipped with NVidia graphic adapters tend to use RGBA32
pixel format. By default ARGB32 pixel format is used, proved to work
on machines equipped with ATI graphic adapter and the onboard adapter
used on Talos II and Blackbird machines from Raptor Computing Systems.
Original patch developed by bdragon
Reviewed by: bdragon, luporl
MFC after: 3 days
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D28604
vt is using static buffers for on screen data, the buffer size is
calculated based on maximum supported screen size and 8x16 font.
When using hi-res graphics and very smaller than 8x16 font, we
need to be careful not to overflow static buffers in vt.
Testing: I did test by building smaller buffers than vt currently is using,
royger was testing on actual 4k capable hardware.
MFC after: 1 week
Tested by: royger
As we get started with no memory allocator, we set up static font data
for font passed by loader (if there is any). At this time, we also must
set refcount 1, and refcount will get incremented in cnprobe() callback.
At some point the memory allocator will be available, and we will set up
properly allocated font data, but we should not disturb the refcount.
PR: 253147
