wireguard-openbsd/sys/dev/rasops, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/dev/rasops?h=jd%2Fqueueboosts2020-06-16T21:49:30ZRemove old commented out line and fix indent.2020-06-16T21:49:30Zmortimermortimer@openbsd.org2020-06-16T21:49:30Zurn:sha1:2a4ed8c44ad5033858e3f2e05083491115547e7c
clang-10 complains about the misleading indentation.
ok patrick@
change wsdisplay attribute type from long to uint32_t2020-05-25T09:55:47Zjsgjsg@openbsd.org2020-05-25T09:55:47Zurn:sha1:e0c3e5595cd64cda848d09b1c753f51bcbadd436
miod explained it was initially a long as it was thought drivers may
need to allocate storage but in practice they don't need more than
32 bits for an attribute.
suggested and reviewed by miod@
rename wsdisplay alloc_attr() to pack_attr()2020-05-25T06:45:25Zjsgjsg@openbsd.org2020-05-25T06:45:25Zurn:sha1:fc223b232cff7e51a9474209d53006b4ae5898e7
Suggested by John Carmack. miod agrees a rename would make sense and
explained it was initially thought drivers may need to allocate storage
but in practice they don't need more than 32 bits for an attribute.
ok mpi@
Revert rasops32_putchar() changes introduced in revision 1.8.2019-03-24T14:15:00Zfcambusfcambus@openbsd.org2019-03-24T14:15:00Zurn:sha1:c98568574912b9e470b9fef223d9d89f4d5bdb7e
This significantly speeds up character plotting on inteldrm and
radeondrm, and also on efifb(4) since the driver now remaps the
framebuffer in write combining mode.
OK kettenis@, jcs@
Modify rasops_list_font_cb() to not filter out fonts with different2019-03-18T16:10:39Zfcambusfcambus@openbsd.org2019-03-18T16:10:39Zurn:sha1:6db384e5ca9825d1e10127c915cc688edadfbac9
sizes than the currently used one. This allows getting a list of all
loaded fonts when using the WSDISPLAYIO_LSFONT ioctl.
On top of allowing to see all fonts which are currently loaded when
invoking the -l option of wsfontload(8), it also removes the confusion
as to why we might reach the WSDISPLAY_MAXFONTCOUNT limit faster than
expected when loading more fonts.
OK sthen@
Enable Spleen in wsfont and modify the font selection logic at runtime2019-01-09T11:23:32Zfcambusfcambus@openbsd.org2019-01-09T11:23:32Zurn:sha1:4c444772e50e31f51b3940683a47abff19492bd2
in rasops(9) to allow selecting larger fonts when available.
Summary of the changes:
- Enable spleen8x16 for all architectures, replacing bold8x16_iso1.
- Enable spleen12x24 on all arches but sparc64, replacing gallant12x22.
- Enable spleen16x32 and spleen32x64 on amd64, i386, and arm64 for
GENERIC kernels.
- Modify the font selection logic in rasops(9) so the 16x32 and 32x64
fonts are selected if at least 120 columns can be displayed. Screens
with widths equal or larger than 1920px will use the 16x32 font, and
screens with widths equal or larger than 3840px the 32x64 one.
OK kettenis@, ratchov@, deraadt@
Remove the rasops24_erasecols and rasops24_eraserows functions from2018-12-26T11:33:57Zfcambusfcambus@openbsd.org2018-12-26T11:33:57Zurn:sha1:710cf26786bf3f0d9a3eccf100c922d585962099
rasops(9).
We only build rasops24 functions on amd64 (for EFI support in QEMU) and
on armv7 and arm64, and we can safely use the generic functions on those
platforms, like we do for all other color depths. No other platform uses
rasops24, Miod explains why here [1].
No performance regression observed when testing with QEMU in EFI mode.
[1] https://marc.info/?l=openbsd-ppc&m=118664346819989&w=2
OK kettenis@
Only clear the character backing store when the RI_CLEAR flag is set.2018-09-22T17:40:57Zketteniskettenis@openbsd.org2018-09-22T17:40:57Zurn:sha1:03c8b0ac2f7aef649efec39dca24f98fab5770e8
ok deraadt@
Add an interface that allows drivers to claim a framebuffer and check2018-08-27T09:30:07Zketteniskettenis@openbsd.org2018-08-27T09:30:07Zurn:sha1:2723123cafb705c78b5251329bdd932ca6b834d9
whether another driver has already claimed a framebuffer. Use this in
radeondrm(4) and simplefb(4) to prevent the latter from attaching if
radeondrm(4) is attached to the hardware that provides the framebuffer
set up by the firmware.
ok mlarkin@
The current rasops cursor implementation simply inverts the appropriate2018-08-25T12:23:45Zketteniskettenis@openbsd.org2018-08-25T12:23:45Zurn:sha1:55e28768a49ac85d8784c354b500776502a32922
framebuffer pixels by doing an XOR with an all-ones bit pattern. This
means the code has to read from the framebuffer which can be very slow.
Add an implementation that simply redraws the character covered by the
cursor with the foreground and background color swapped. While this
doesn't necessarily have the same visual result, most people probably
won't notice the difference (let's see). Use this implementation when
the RI_WRONLY or the RI_VCONS flags are set.
ok fcambus@