#
303975 |
|
11-Aug-2016 |
gjb |
Copy stable/11@r303970 to releng/11.0 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, and rename it to RC1.
Update __FreeBSD_version.
Use the quarterly branch for the default FreeBSD.conf pkg(8) repo and the dvd1.iso packages population.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
302408 |
|
08-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
298433 |
|
21-Apr-2016 |
pfg |
sys: use our roundup2/rounddown2() macros when param.h is available.
rounddown2 tends to produce longer lines than the original code and when the code has a high indentation level it was not really advantageous to do the replacement.
This tries to strike a balance between readability using the macros and flexibility of having the expressions, so not everything is converted.
|
#
295883 |
|
22-Feb-2016 |
skra |
As <machine/vm.h> is included from <vm/vm.h>, there is no need to include it explicitly when <vm/vm.h> is already included.
Reviewed by: alc, kib Differential Revision: https://reviews.freebsd.org/D5380
|
#
295880 |
|
22-Feb-2016 |
skra |
As <machine/pmap.h> is included from <vm/pmap.h>, there is no need to include it explicitly when <vm/pmap.h> is already included.
Reviewed by: alc, kib Differential Revision: https://reviews.freebsd.org/D5373
|
#
286809 |
|
15-Aug-2015 |
marcel |
Improve support for Macs that have a stride not equal to the horizonal resolution (width). In those cases fb_bpp ended up completely wrong -- as in 6 bytes per pixel or something like that. Since we already have a way to calculate fb_depth given the masks and fb_bpp is effectively the same as fb_depth, all we need to do is make sure fb_bpp is rounded to the next multiple of the number of bits in a byte -- we assume we can divide by the number of bits in a byte throughout vt(4). While here: - simplify how we calculate fb_depth. - use fb_bpp instead of fb_depth to calculate fb_stride; we know we can divide fb_bpp. - don't limit fb_width and fb_height by VT_FB_DEFAULT_WIDTH and VT_FB_DEFAULT_HEIGHT (resp.). Those constants have not relation to the size of the frame buffer.
This at least fixes "lower-resolution" Macs. We're talking 1280x1024 or so. There still is a problem with 27" Macs, which typically have a horizontal resolution over 2K.
PR: 193745 (partial) Ok'd by: emaste@
|
#
286667 |
|
12-Aug-2015 |
marcel |
Better support memory mapped console devices, such as VGA and EFI frame buffers and memory mapped UARTs.
1. Delay calling cninit() until after pmap_bootstrap(). This makes sure we have PMAP initialized enough to add translations. Keep kdb_init() after cninit() so that we have console when we need to break into the debugger on boot. 2. Unfortunately, the ATPIC code had be moved as well so as to avoid a spurious trap #30. The reason for which is not known at this time. 3. In pmap_mapdev_attr(), when we need to map a device prior to the VM system being initialized, use virtual_avail as the KVA to map the device at. In particular, avoid using the direct map on amd64 because we can't demote by virtue of not being able to allocate yet. Keep track of the translation. Re-use the translation after the VM has been initialized to not waste KVA and to satisfy the assumption in uart(4) that the handle returned for the low-level console is the same as later returned when the device is probed and attached. 4. In pmap_unmapdev() remove the mapping from the table when called pre-init. Otherwise keep the mapping. During bus probe and attach device resources are mapped and unmapped multiple times, which would have us destroy the mapping used by the low-level console. 5. In pmap_init(), set pmap_initialized to signal that we're not pre-init anymore. On amd64, bring the direct map in sync with the translations created at that time. 6. Implement bus_space_map() and bus_space_unmap() for real: when the tag corresponds to memory space, call the corresponding pmap_mapdev() and pmap_unmapdev() functions to construct and actual handle. 7. In efifb.c and vt_vga.c, remove the crutches and hacks and simply call pmap_mapdev_attr() or bus_space_map() as desired.
Notes: 1. uart(4) already used bus_space_map() during low-level console setup but since serial ports have traditionally been I/O port based, the lack of a proper implementation for said function was not a problem. It has always supported memory mapped UARTs for low-level consoles by setting hw.uart.console accordingly. 2. The use of the direct map on amd64 without setting caching attributes has been a bigger problem than previously thought. This change has the fortunate (and unexpected) side-effect of fixing various EFI frame buffer problems (though not all).
PR: 191564, 194952
Special thanks to: 1. XipLink, Inc -- generously donated an Intel Bay Trail E3800 based eval board (ADLE3800PC). 2. The FreeBSD Foundation, in particular emaste@ -- for UEFI support in general and testing. 3. Everyone who tested the proposed for PR 191564. 4. jhb@ and kib@ for being a soundboard and applying a clue bat if so needed.
|
#
285911 |
|
27-Jul-2015 |
marius |
- Nuke dupe $FreeBSD$. - Fix whitespace.
MFC after: 3 days
|
#
276405 |
|
30-Dec-2014 |
royger |
Partially revert "vt: register the memory regions used by the vt drivers"
Revert the EFI part of r276064 until I can test it properly on a real EFI system. This was causing problems to people booting using UEFI and vt.
Reported by: O. Hartmann <ohartman@zedat.fu-berlin.de>
|
#
276064 |
|
22-Dec-2014 |
royger |
vt: register the memory regions used by the vt drivers
Current VT drivers don't register the memory regions they use with the nexus. This patch makes vt_vga and vt_efifb register the memory regions they use.
This is needed (at least) for Xen support, since the FreeBSD kernel will try to use the holes in the memory map to map memory from other domains and setup it's grant table.
Sponsored by: Citrix Systems R&D Reported by: sbruno Tested by: emaste Reviewed by: ray PR: 195537 Differential Revision: https://reviews.freebsd.org/D1291
|
#
271684 |
|
16-Sep-2014 |
dumbbell |
vt(4): Use vt_fb_drawrect() and vt_fb_setpixel() in all vt_fb-derivative
Review: https://reviews.freebsd.org/D789 Reviewed by: nwhitehorn Approved by: nwhitehorn MFC after: 2 days
|
#
270431 |
|
23-Aug-2014 |
dumbbell |
vt(4): Add vd_bitblt_bmp_t callback
The code was already there in all backends, we just expose it. This is used to display the splash screen.
MFC after: 1 week
|
#
270411 |
|
23-Aug-2014 |
dumbbell |
vt_fb: Implement vd_bitblt_text_t for vt_fb and derivatives
MFC after: 1 week
|
#
269783 |
|
10-Aug-2014 |
dumbbell |
vt(4): Colors are indexed against a console palette, not a VGA palette
Rename vt_generate_vga_palette() to vt_generate_cons_palette() and change it to build a palette where the color index is the same than in terminal escape codes, not the VGA index. That's what TCHAR_CREATE() uses and passes to vt(4).
The main differences between both orders are: o Blue and red are swapped (1 <-> 4) o Yellow and cyan are swapped (3 <-> 6)
The problem remained unnoticed, because the RGB bit indexes passed to vt_generate_vga_palette() were reversed. This inversion was cancelled by the colors inversions in the generated palette. For instance, red (0xff0000) and blue (0x0000ff) have bytes in opposite order, but were swapped in the palette. But after changing the value of blue (see last paragraph), the modified color was in fact the red one.
This commit includes a fix to creator_vt.c, submitted by Nathan Whitehorn: fb_cmsize is set to 16. Before this, the generated palette would be overwritte. This fixes colors on sparc64 with a Creator3D adapter.
While here, tune the palette to better match console colors and improve the readability (especially the dark blue).
Submitted by: nwhitehorn (fix to creator_vt.c) MFC after: 1 week
|
#
269685 |
|
07-Aug-2014 |
nwhitehorn |
Retire vd_maskbitbltchr. The same functionality can be obtained by testing for mask != NULL in vd_bitbltchr, which all implementations of vd_bitbltchr() were doing anyway.
|
#
269620 |
|
06-Aug-2014 |
nwhitehorn |
Retire various intertwined bits of fbd(4) and vt_fb, in particular the pixel modification indirection. No actual drivers use it and those that might (e.g. creatorfb) use custom implementations of vd_bitbltchr().
|
#
268772 |
|
16-Jul-2014 |
nwhitehorn |
Allow efifb to be used with xf86-video-scfb. This is important for EFI systems without either a CSM or real graphics drivers, such as my Lenovo Haswell laptop.
This provides working X with the small complication of a console cursor permanently overlaid on the upper-left corner of the screen that will be dealt with later.
Also remove some redundant screen clearing.
|
#
268624 |
|
14-Jul-2014 |
nwhitehorn |
On my Lenovo laptop, the firmware maps the EFI framebuffer with MTRRs set to uncacheable. This leads to execrable console performance. Once PMAP is up, remap the framebuffer as write-combining. This reduces boot time on my laptop by 60% when booting with EFI.
MFC after: 2 weeks
|
#
265397 |
|
05-May-2014 |
ray |
Switch fb and efifb drivers to use names and new vt(4) driver probe method.
Sponsored by: The FreeBSD Foundation
|
#
263826 |
|
27-Mar-2014 |
emaste |
Update EFI framebuffer handoff from loader
Sponsored by: The FreeBSD Foundation
|
#
263183 |
|
14-Mar-2014 |
emaste |
Use the existence of module metadata to indicate framebuffer presence
|
#
262785 |
|
05-Mar-2014 |
ray |
Add efifb driver. Driver uses the data passed by UEFI compatible loader/BIOS and enable to use framebuffer created by those loader.
|